Pierre Carrier

Gilles Abramovici

Laurent J Lewis

M W C Dharma-Wardana

Electronic and Optical Properties of Si/SiO 2 Superlattices from First Principles : Role of Interfaces

The observation of intense luminescence in Si/SiO 2 superlattices (SLs) has lead to new theoretical research on silicon-based materials. We have performed first-principles calculations using three Si/SiO 2 SL models in order to examine the role of interfaces on the electronic structure and optical properties. The first two models are derived directly from crystalline structures and have simple interfaces. These models have been studied using the full-potential, linearized-augmented-plane-wave method, in the local-density-approximation (LDA). The optical absorption within the interband transition theory (excluding excitonic effects) have been deduced. The Si(001)-SiO 2 interface structure is shown to affect the optical behaviour. Following these observations, we have considered a more realistic, fully-relaxed model. The projector-augmented-wave method under the LDA is used to perform the structural relaxation as well as band structure and optical calculations. The role of confinement on the energy gap is studied by inserting additional silicon slabs into the supercell. Direct energy gaps are observed and the energy gap is found to decrease with increasing silicon slab thickness, as observed experimentally. The role of the interface has been considered in more details by studying the contribution to the energy gap of Si atoms having different oxidation patterns; partially oxidized Si atoms at the interface, as well as Si atoms inside the Si layer, are shown to contribute to the transitions at the energy gap.

INTRODUCTION

Lu et al [1], and many others [2] have reported enhanced luminescence in the visible part of the spectrum of Si/SiO 2 superlattices (SLs). A shift of the energy spectrum towards the blue is observed when the thickness of the Si layers is reduced from 6 to 2 nm. In contrast to porous silicon [3], Si/SiO 2 SLs present the advantage of being stable, with no significant decrease of the luminescence observed with time. From this experiment, it can be inferred that confinement plays a major role on the optical enhancement of SLs. However, confinement cannot explain the whole optical mechanism. It has been observed in experiments by Kanemitsu [4], and from first-principles calculations performed by Kageshima [5], that the Si(001)-SiO 2 interface plays as well, a non-negligible role on the optical properties of the SLs. It is worth noticing that Si and SiO 2 are both already standard components of MOSFETs and other devices where the Si(001)-SiO 2 interface is of great interest; optical properties of Si(001)/SiO 2 SLs and their Si(001)-SiO 2 interfaces can give insights on the (single) MOSFET interface structure [6].

Motivated by these promising experimental observations, and to provide insight into the microscopic physics associated with the luminescence efficiency of Si based devices, we have carried out detailed first-principles investigations of the electronic and optical properties of Si/SiO 2 SLs. The electronic-structure calculations were carried out within two approaches: the full-potential, linearized-augmented-plane-wave (LAPW) method implemented in the WIEN97 package [START_REF] Blaha | WIEN97[END_REF] and the projector-augmented wave (PAW) approach [8] implemented in the VASP package [START_REF] Kresse | Improved and updated Unix version of the original copyrighted VASP/VAMP code, which[END_REF]. Determination of the optical variables, such as the dielectric function (ε) and the absorption coefficient (α), are carried out within the interband theory (excluding excitonic effects which are important only at very small carrier densities) [START_REF] Yu | Fundamentals of Semiconductors[END_REF].

MODELS

Three models (and some modifications of these) are considered. The first two are constructed by superposing the diamond-Si structure onto the β-cristobalite SiO 2 (Fd3m group) structure. They differ in the way dangling bonds are satisfied at the interfaces: the double-bond model (DBM) proposed by Herman and Batra [START_REF] Herman | The Physics of SiO 2 and its Interfaces[END_REF] and depicted in figure 1(a) has double Si=O bonds at the interfaces; the bridged-oxygen model (BOM) introduced by Tit and Dharmawardana [START_REF] Tit | [END_REF], and shown in figure 1(b), has one oxygen that bridges two Si atoms at the interfaces, with Si-O-Si angles of °144 (as measured in silica). The resulting unit cell dimensions are based on experimental lattice constants. The BOM has 21 atoms while the DBM has 23.

The third model is based on a Si(001)-SiO 2 interface study performed by Pasquarello et al [START_REF] Pasquarello | The initial Si/SiO 2 structure used here to generate the FRMs is the 'Model III' described[END_REF]; the SL structure is obtained by applying a symmetry-rotation operation of the supercell; this gives rise to the so-called partially relaxed structure (PRM) used by Tran, Tit and Dharmawardana [14]; a final relaxation leads to the fully relaxed model (FRM). In order to assess the effect of confinement on the energy spectrum, two additional layers of crystalline Si atoms have been introduced in the supercell, thus varying the thickness of the Si-slab from ~0.8nm,

RESULTS and DISCUSSION

The nature of the energy gap is direct in both the FRM2 and FRM3, on the whole Γ-Ζ axis of the Brillouin zone, but nearly direct for the FRM1 (with only 0.12 eV between the direct and indirect energy gap at Γ). The values of the energy gaps are 0.99 eV, 0.81 eV and 0.68 eV for the FRM1, FRM2 and FRM3, respectively. The position of the minimum gap transition is thus blue shifted with increasing confinement. Energy bands are dispersionless in all growth axis of the BZ, which shows that the confinement is not due to impurity states; it is due to the quantum nature of the electronic states, in a periodic layer. Dispersionless energy bands are as well observed in both the DBM and the BOM. Their band gaps are nearly direct (0.86 eV for the DBM and 1.5 eV for the BOM). However, gap states are observed in the BOM, showing that complete relaxation of the structures are necessary to get realistic optical results, as further discussed below. In order to get a complete picture of all possible transition probabilities, calculation of the imaginary part of the dielectric function has been performed, using the Fermi Golden Rule and the interband approach [START_REF] Yu | Fundamentals of Semiconductors[END_REF]. The integration in the BZ is done by summing over all tetrahedra [15]. Figure 2 shows the overall picture of the z component of the dielectric function. The shift towards the blue with increasing confinement is indeed visible and for all the FRMs, the functions slowly increase, starting from their respective band gaps, and then remain significantly higher than that of c-Si, around 2 eV. The onset for c-Si happens only at 2.52 eV. It is well known that the LDA and interband approaches lower the first (of two) main peak of the dielectric function for c-Si; interacting electron-hole calculations (using e.g. the Bethe-Salpeter equations) would capture this peak (see for instance [16]). However, such calculations are prohibitive for the models considered here. As a result, electron-hole interactions would enhance the effects for c-Si as well as for the FRMs and this would lead to the same conclusion that the optical properties are higher for all the SL models as compared to c-Si.

In order to understand the role played by the interfaces on the optical properties of the SLs, AA4.10.3 Given these observations, we undertook a detailed analysis of the interface structure of the FRM. Si atoms can have five possible oxidation states -if nearest-neighbours only are taken into account. Figure 4 shows the five tetrahedra and the corresponding bondlengths, as they appear in the FRM1. We define the interface to be formed by all Si atoms having suboxide bonds (Si +1 , Si +2 , Si +3 ). Experiments have shown [17] that suboxide Si atoms at the Si/SiO 2 interface are almost equally distributed -with a slightly higher distribution for the (Si +3 ) atoms. The interface of the FRMs have been constructed assuming, for simplicity, an equal distribution of the suboxide Si atoms.

The Si-O bondlengths and Si-O-Si angles at the interface of the BOM have been shown to affect the optical properties. This is confirmed by noticing that the Si-Si and Si-O bondlengths

(Si 0 ) (Si +1 ) (Si +2 ) (Si +3 ) (Si +4 )
Figure 4 : Five oxidation states of Si atoms in the FRM1, calculated from the PAW method. The bondlengths do not differ greatly in the FRM2 and FRM3. The suboxide Si atoms (Si +1 , Si +2 and Si +3 ) define the interface.

AA4.10.4 of the suboxide Si atoms of the fully relaxed structures are greatly modified (see figure 4): the Si-Si and Si-O bondlengths of the (Si +1 ), (Si +2 ) and (Si +3 ) atoms in figure 4 depart from the Si-Si bondlengths of (Si 0 ) being normally ~2.35c, as well as the Si-O bondlengths of (Si +4 ), being normally ~1.61c. Simple counting of the different oxidation states in the three FRMs can account for the influence of the interface on the energy gap. (Recall that the FRM2 and FRM3 were constructed by introducing additional bulk Si layers in the FRM1 supercell). The proportion of Si 0 atoms, from the FRM1 to the FRM2 and finally to the FRM3, increases from 38.5% to 53%, and finally to 62%, respectively. This is, of course, related to the confinement. On the other hand, the proportion of suboxide Si atoms at the interface decreases from 23% to 18% and finally to 14%, respectively. Thus, the interfaces of the FRM1 represent about a 1/4 of the whole system, while for the FRM3, they represent about 1/7 of the whole system. In order to quantify furthermore the importance of interfaces, we have determined the density of s-states and p-states (s-DOS; p-DOS) of a Si +1 atom (at the interface) and compared it to the DOS of Si 0 and Si +4 atoms in the center of their respective layers (see figure 4 for the definition of index Si m ). We conclude from figure 5 that Si atoms at the interface (Si +1 ) contribute to the optical transitions at the energy gap, as well as Si 0 atoms inside the silicon layer do -since their s-and p-DOS are both non-zero at the gap with similar variation of their respective DOS. Furthermore, Si +4 in the silica layer do not contribute to the energy gap, but still, contribute to the confinement of the silicon layer. Thus, in addition to Si 0 atoms in the Si layer, the interface contributes to the optical transitions in the SLs. A quantitative evaluation of the role of suboxide Si atoms on the energy gap is under investigation.

CONCLUSIONS

Using first-principles calculations, we have studied three models for the Si/SiO 2 superlattices; two simple crystalline structures and one fully relaxed structure. Direct energy gaps in the fully relaxed models are obtained and a blue shift of the optical response (the dielectric function) with confinement is observed. The bondlengths of the three partially oxidized Si atoms at the interface (bonded to 1,2 and 3 oxygen atoms) are shown to be modified when compared to their bulk counterparts. Interface atoms, as well as atoms inside the silicon confined layer are shown to contribute to the transitions at the bandgap, and thus, to the optical response (and its blue shift). AA4.10.5

Figure 1 . 2 Figure 2 .

 122 Figure 1. The three supercell models : (a) the double-bond; (b) the bridged-oxygen with a °144 Si-O-Si bridge angle at the interface; and (c) the fully relaxed (FRM1).

Figure 3 .

 3 Figure 3. Absorption of the DBM and BOM as compared to bulk Si and bulk SiO 2 . The role of the interface can be appreciated from the differences at the onset.

Figure 5 :

 5 Figure 5 : s-DOS and p-DOS (in the FRM3) of one Si +1 at the interface compared to Si 0 and Si +4 atoms in the center of their respective layers (see the text).

ACKNOWLEDGMENTS

It is a pleasure to thank Cristiano Luis Dias, Ralf Meyer and Michel Côté for useful discussions. This work is supported by grants from the Natural Sciences and Engineering Research Council (NSERC) of Canada and the Fonds pour la formation de chercheurs et l'aide à la recherche (FCAR) of the Province of Québec. We are indebted to the Réseau québécois de calcul de haute performance (RQCHP) for generous allocations of computer resources.


Thibault Cholez

Isabelle Chrisment

Olivier Festor

Fighting against paedophile activities in the KAD P2P network

Fighting against paedophile activities in the KAD P2P network

Thibault Cholez, Isabelle Chrisment and Olivier Festor MADYNES -INRIA Nancy Grand Est, France {thibault.cholez,isabelle.chrisment,olivier.festor}@loria.fr Abstract. In this poster, we present a solution to fight against paedophile activities in KAD. Our distributed architecture can monitor and act on paedophile contents in a very efficient way by controlling keywords and files. Early results on the real network demonstrate the applicability of our approach.

Keywords: Honeypot, KAD, DHT 1 Motivation KAD is a part of the eMule software and one of the major file sharing P2P networks (∼ 3 millions of simultaneous users). KAD uses a structured architecture called Distributed Hash Table (DHT) to allow users to retrieve a specific file from keywords and the possible sources for a file. Observing users and controlling contents in KAD are real technical challenges:

-Each file and keyword is published on dozens of peers on the DHT, in order to keep the information available. -As paedophile contents can be referenced through normal keywords, monitoring only files can lead to false positive (normal users considered as paedophiles). -Attracting users with Honeypots (fake files) is resource consuming because popular files need to show a high number of sources. -Recent protection mechanisms inserted in KAD mitigate the Sybil attack (insertion of many fake peers from a single computer to disturb the network).

Our features to fight against paedophile activities

Thanks to our specific distributed architecture exploiting some KAD weaknesses, we can provide several features helping to study and fight against paedophile activities on that network. Being given the hash of specific contents, we can do:

-Passive monitoring: we transparently monitor all the requests sent to the targeted contents in the network. We can discover all the new published files for a given keyword and all the peers sharing a file.

-Eclipsing content: we eclipse entries of the DHT to remove the targeted contents from the network and prevent users from accessing it. -Index poisoning: we poison the DHT references with very attractive fake files showing a high number of sources. -Promoting Honeypots: we attract the final download requests for the controlled files towards our Honeypots.

By attracting all the publications and searchs of paedophile contents (keywords and our architecture can assess and control the paedophile behavior from the initial search of keyword to the final download.

Experiments

To test our solution, we eclipsed the good references for the keyword "spiderman" and poisoned them with 4 fake files for one day. The results in figure 1 and2 show that our architecture is effective and the importance to control the number of sources to build an efficient Honeypot. Our upcoming work consists to deploy our architecture to specifically study and fight against paedophile activities.

Fig. 1 .

 1 Fig. 1. Results of a search for "spiderman" under eclipse and poison (4 fake files)

Acknowledgment: This work is funded by the French ANR Research Project MAPE(Measurement and Analysis of Peer-to-peer Exchanges for pedocriminality fighting and traffic profiling), under contract ANR-07-TLCOM-24.


N Patrinopoulou

I Daramouskas

V Lappas

V Kostopoulos

A M Veytia

C A Badea

J Ellerbroek

J Hoekstra

V De Vries

J Van Ham

E Sunil

P Menendez

Ponte Alonso

J Pedrero Gonzalez

D Bereziat

A Vidosavljevic

L Sedov

Metropolis II: Investigating the Future Shape of Air Traffic Control in Highly Dense Urban Airspace

Keywords: Separation management, Flight planning, U-Space, Unmanned Traffic Management (UTM), BlueSky ATC Simulator, Urban Airspace, Degree of Centralisation

Metropolis II aims to provide insights in what is needed to enable high-density urban air operations. It does this by investigating the foundation for U-space U3/U4 services. The final goal is to provide a unified approach for strategic deconfliction, tactical deconfliction, and dynamic capacity management. Highly-dense operations in constrained urban airspace will likely require a degree of complexity that does not exist in modern-day air traffic management. The expected high traffic demand will require a shared use of the airspace instead of assigning exclusive use of blocks of the airspace to some flights. A unified approach for traffic management is needed because at high-densities, airspace design, flight planning, and separation management become increasingly interdependent. Metropolis II builds upon the results of the first Metropolis project. Three concepts with a varying degree of centralisation will be compared using simulations. (1) The centralised concept will take a global approach for separation management. (2) The decentralised concept aims to give the individual agents separation responsibility. (3) The hybrid concept tries to combine a centralised strategic planning agent with a robust tactical separation strategy.

I. INTRODUCTION

The overload of ground transportation in urban environments has created the need for research on urban aerial transportation, which should be designed to accommodate an increasing amount of air traffic. Parcel delivery demand is expected to rise in the future to millions of flights per year [START_REF] Doole | Estimation of traffic density from drone-based delivery in very low level urban airspace[END_REF]. Research has been performed in previous projects for urban airspace navigation, most notably the CORUS project [START_REF]U-space Concept of Operations[END_REF], which looked at airspace structuring when aircraft would fly above all buildings in a city. However, that might not be feasible in cities with very tall buildings (e.g. New York). On top of that, flying above streets can increase the societal acceptability by lowering the impact on noise, privacy and perceived third party risk, when not part of the traffic.

Thus, the scope of Metropolis II [START_REF]Metropolis II[END_REF] is to study and develop methodologies to provide an Unmanned Traffic Management (UTM) solution for mixed airspace (open and constrained), which includes airspace design, flight planning, and separation management. The main research question of Metropolis II may be summed up as; How does the degree of centralisation of an Unmanned Traffic Management system including airspace design, flight planning, and separation management affects the system's performance? To answer that question three individual concepts have been designed; centralised, hybrid and decentralised, each with a different degree of centralisation. The three concepts are presented in sections II, III, and IV, respectively.

In high traffic densities, we believe that the design of the airspace, the flight planning, and the separation management should not be treated as separate problems. Such a system should include a concurrent design of the three subsystems. Thus, each concept was independently designed from each other, ensuring that the subsystems were best suited to each design philosophy.

All concepts were designed considering a set of common elements and requirements, such that the experimental results may be comparable. The concepts were provided with the basic airspace rules for which to design. The airspace was designed suitable for a realistic city structure and was separated into a constrained area, in which the aircraft were confined to flying above the existing street network, and an open area, in which the aircraft do not need to follow predetermined paths. The concepts are evaluated using the same traffic scenarios. The experimental method employed in Metropolis II is presented in section V.

II. THE CENTRALISED CONCEPT

The centralised concept focuses on strategic deconfliction and flight planning, which are conducted pre-flight by a central entity. The central entity has access to global data concerning the information about the requested flights, the planned flights, and the real-time tracking data of enroute aircraft. For that purpose, a centralised deconfliction algorithm was developed, responsible for producing flight plans based on the requested departure time and the origin and destination coordinates. In this concept, a flight plan is a 4-dimensional trajectory describing the longitude, latitude and altitude and time. Each of the produced flight plans has a fixed altitude, with the exception of the takeoff and landing segments.

Within the centralised concept, the designed airspace structure may be described as a bi-directional graph. For the constrained airspace the geometry of the graph is set by the street network while for the open airspace the area is divided into hexagonal tiles, each representing one node of the graph, as shown in Fig. 1. Turning costs are added to the produced graph with the method described in [START_REF] Winter | Modeling Costs of Turns in Route Planning[END_REF]. The whole airspace (open and constrained) is divided into 16 flight layers, following the recommendations of the Metropolis project [START_REF] Sunil | Metropolis: Relating Airspace Structure and Capacity for Extreme Traffic Densities[END_REF]. Each aircraft is assigned to one of the layers for the entirety of its flight depending on its origin and destination (based on the bearing of the 2-dimensional vector connecting the origin to the destination) or a layer selected from the deconfliction algorithm presented below.

Flight planning and strategic deconfliction are conducted using two different methodologies depending on the demand. For low demand, the flight plan for every aircraft is computed initially without considering the other aircraft, using the A* algorithm. Then, flight plans are checked for conflicts using a quick simulation. The detected aircraft pairs causing a conflict are used to create a conflict graph, with the aircraft as vertices and the edges representing the detected conflict between two aircraft. To resolve the conflicts, some aircraft are assigned to different layers, by formulating the problem as a graph colouring problem [START_REF] Duchamp | Air traffic deconfliction using sum coloring[END_REF], [START_REF] Duchamp | Density-Adapting Layers towards PBN for UTM[END_REF].

The high demand methodology is utilised for aircraft densities in which the low demand approach fails to reach a solution. The high demand methodology is an addition to the low demand methodology and it is called to resolve the remaining conflicts. For the aircraft, for which a solution was not found, the algorithm searches for the optimal path based on the availability of the airspace. A timeexpanded network (TEN) [START_REF] Silver | Time-expanded decision networks: A framework for designing evolvable complex systems[END_REF] is created for each layer, where each possible aircraft movement is represented by an edge. Having removed the edges that would lead to a conflict, the shortest path in the graph may be found. The Dijkstra algorithm is used for the graph search in the timeexpanded network. After a flight plan has been produced, it does not incur any changes and it is considered as an obstacle for later-planned flight plans.

In nominal conditions, a centralised concept, as the one presented here, does not need to contain a tactical separation management system, since all conflicts have been resolved pre-flight. However, different types of uncertainties could cause the aircraft to deviate from their designed paths and create a possible conflict. For this reason, a centralised tactical deconfliction system is included and has the responsibility to detect conflicts and recompute aircraft trajectories to resolve them.

III. THE HYBRID CONCEPT

The hybrid concept combines centralised and decentralised components to achieve separation management. The development of the hybrid concept was conducted in three stages: (1) the design of the airspace structure, (2) the design of the centralised pre-flight strategic separation management, and (3) the design of the during flight tactical separation. In ideal conditions, the first two stages should be able to provide a safe and efficient solution for the requested flights. However, due to uncertainties, the aircraft may not be able to follow the designed route in the exact computed time, causing conflicts, which are resolved in the third stage. In order to prevent the tactical separation management from having a negative effect on the efficiency and safety of the flights computed from the strategic plan, the two act on different dimensions; strategic uses horizontal resolution and tactical uses vertical resolution.

The developed airspace structure is described as a 3dimensional directional graph. In constrained airspace, the graph follows the street network, while in open airspace a radial grid is created, as shown in Figure 2. The vertical axis is separated into layers. Two types of layers are used: cruising layers (mostly used for the strategic separation management) and resolution layers (mostly used for the tactical separation management). The two types of layers alternate and create a stack of layers, as presented in Figure 3. The direction of cruising layers alternates as the altitude increases. The vertical edges of the graph are bi-directional, allowing ascending and descending.

The centralised pre-flight strategic separation management is responsible for computing conflict-free paths while optimising for the length of the path and it obeys to rules imposed from the above presented airspace structure. Since it is centralised, the central entity computing the initial flight plans has access to information concerning all flights to be planned. The strategic conflict resolution algorithm in use is time-based (i.e. the edges and nodes of the graph will appear as occupied for certain time steps if they are in use from previously computed flight plans) and contains four steps:

1) Flight plans with earlier desired departure time are prioritised and computed first.("First come, first served") 2) For each aircraft the shortest route is found using the Dijkstra search algorithm. 3) Search for a conflict-free flight plan in the lowest layer and if that fails repeat the process for higher layers. The length of the route computed at step 2 is used as a baseline to compare the optimality of the solution found. 4) For the aircraft that a solution was not found, a delay in their departure time is imposed. The decentralised tactical separation management acts during flight and acts in two levels: the conflict detection, resolution and trajectory recovery level and the route replanning level. The conflict detection, resolution and trajectory recovery level is responsible for detecting nearfuture conflicts, designing a manoeuvre for the aircraft to resolve the conflict and after the conflict has been averted, initialises the trajectory recovery sequence to return the aircraft to its initial trajectory in a safe manner. The resolution layers may be used for the conflict resolution manoeuvres. The route replanning level is requested to recompute a flight plan in case the corresponding flight plan becomes impractical due to airspace closures or changes.

IV. THE DECENTRALISED CONCEPT

In the decentralised concept the responsibility of designing the flight plan and taking the actions to maintain the separation distance lies to each individual agent. The agents do not have any information about the flight plans of other agents and they are not able to include strategic separation techniques while designing their flight plans, very similar to road traffic.

The decentralised concept may be broken down into the development of four subsystems: airspace structure, flight planning, flow control (traffic control from central entity) and tactical separation management.

The airspace structure was developed in the scope of minimising the probability of conflicts. In the design of the airspace structure for the constrained airspace an additional objective was considered; a turning aircraft should not have a major impact on the cruise flow. To respect both objectives the constrained airspace structure contains only one-way streets with the traffic being distributed into layers. The design contains cruise layers, turn layers and empty layers, the types of the layers alternate while the altitude increases, as shown in Figure 4. Under nominal circumstances the aircraft cruise along a street using a cruise layer and use turn layers only for turning (changing streets). Cruise layers of intersecting streets should not be allocated in the same altitude, which created the need for the existence of the empty layers. The streets were grouped into two categories based on their bearing, creating groups of semi-parallel streets, in order to allocate the altitude of the cruise layers in each street, seen in Figure 5. After that, the directionality of each street was selected using a genetic algorithm to optimise the graph's connectivity.The airspace structure for the open airspace utilises the results from the first Metropolis project [START_REF] Sunil | Metropolis: Relating Airspace Structure and Capacity for Extreme Traffic Densities[END_REF] and it vertically separates traffic based on the heading of the aircraft.

For the decentralised concept, the calculation of the flight plans can be described as a path planning problem with known and static obstacles and dynamic costs. To solve the path planning problem, we created a graph describing the whole airspace. For the constrained airspace the graph design was obvious and was based on the streets' structure, while for the open airspace a graph was created using cell decomposition techniques [START_REF] Galceran | A survey on coverage path planning for robotics[END_REF]. The outcome of the cell decomposition algorithm is presented in Figure 6. The D* Lite algorithm [START_REF] Koenig | D*lite[END_REF] was selected as the path planning algorithm to compute the shortest path on the designed graph. The main reason D* Lite was selected is the algorithm's ability to recompute the path on-line, which offers a significant advantage for the decentralised concept as the aircraft replan every time a new geovector is imposed from the central entity as described in the next paragraph. The decentralised concept also contains a central entity, which gathers the aircraft's position data and computes the traffic densities in the traffic groups. Depending on the computed traffic density, the central entity applies geovectors [START_REF] Hoekstra | Geovectoring: Reducing Traffic Complexity to Increase the Capacity of UAV airspace[END_REF] in the traffic groups in the form of speed limits. In a real world implementation the central entity would also be responsible for the authorisation process and for approving a requested flight plan with the agent providing the flight start time, origin and destination coordinates.

As stated at the beginning of the section, the decentralised concept relies only on tactical separation to resolve conflicts, which signifies the importance of tactical separation in this case. The proposed tactical separation algorithm is speed-based and allows only for vertical manoeuvres. The conflict resolution algorithm is called from a conflict detection algorithm which detects the conflicts and classifies them as one of the following three types: overtake, horizontal and vertical.

The main attributes of each concept and the and differences between them are summarised in Table I.

V. EXPERIMENTAL METHOD

The Metropolis II project aims at studying the performance of different centralisation levels on flight management and separation management in the urban airspace. To conduct that study three different concepts have been developed, as presented in the above sections. The three concepts were designed to abide to a set of commonly defined requirements, which remains constant for all tested scenario.

• Cylindrical airspace volume (8 kilometre radius, 500 feet height) • Constrained airspace street network and buildings.

• Open airspace with geofenced areas.

• Traffic pattern and density including priority and loitering missions. • Two types of vertical take-off and landing (VTOL) vehicles with 20 and 30 knots cruising speeds respectively.

• Uncertainties (wind and rogue aircraft, not adhering to the rules). They are tested in a set of scenarios via simulation using the BlueSky Open Air Traffic Simulator [START_REF] Hoekstra | Bluesky ATC simulator project: an open data and open source approach[END_REF] and their performance is evaluated using a set of predefined metrics. The following subsections provide an introduction to the simulation software in use and present the scenarios used for the experiment, as well as the experiment variables. The performance of each concept is evaluated using as set of 35 metrics across 5 categories: access and equity, capacity, efficiency, environment, safety and priority.

A. Simulation software

The simulations will be performed with BlueSky [START_REF] Hoekstra | Bluesky ATC simulator project: an open data and open source approach[END_REF], an open air traffic control simulator, available on GitHub [START_REF]Bluesky: The open source air traffic simulator[END_REF]. BlueSky is an open source simulator originally developed for conventional air traffic simulations, and permits the open publication of source code and results. It was essential that the selected simulation software for Metropolis II is open source, to enable project-specific additions and modifications. Therefore, an important part of Metropolis II was to extend BlueSky for urban air traffic simulations. The major developments from Metropolis II are:

1) Autopilot modifications to ensure aircraft closely follow their intended path between buildings and perform turns safely. 2) Inclusion of building polygons as geofences.

3) Bulk waypoint processing. 4) Visualisation of urban maps (Fig. 7). Each concept has developed their own plugins to ensure that the simulations follow the rules set by the specific concept.

B. Traffic scenarios

The selected simulation environment is based on the city map of Vienna and is a mixture of two types of airspace: constrained airspace and open airspace, creating an overall cylindrical experimental area with a radius of 8 kilometres and a height of 500 feet. The constrained airspace represents the city centre and while flying in it the aircraft should follow the street network of the city. The open (unconstrained) airspace surrounds the constrained airspace and represents the outer part of the city. The open airspace includes some no fly zones, which the aircraft are not allowed to use during their flight. Aircraft in the open airspace may fly in any trajectory that does not violate the no fly zones. In order to create a variety of experimental setups, a set of traffic scenarios has been created. These seek to simulate various types of missions (e.g., point to point, hub and spoke), several traffic density levels, as well as vehicles with different cruise velocities. Two vertical take-off and landing (VTOL) aircraft were included, based on the DJI Matrice 600: one with a cruise speed of 20 knots, and another with a cruise speed of 30 knots. The produced traffic scenarios differentiate in the experimental variables described in the next subsection.

C. Experiment variables

Four experimental variables were selected: traffic demand level, mission mix, wind and rogue aircraft. Each traffic scenario is created by selecting a value for each of the experimental variables.

The traffic demand level indicates the number of requested flights and may take one of the five different values, each representing a different percentage of the maximum estimated demand. The number of requested flights corresponding to each of the values was calculated based on the estimated yearly demand of Vienna using a regression and an interpolation analysis with input data for the area, the population, the average annual gross salary and parcel market data [START_REF] Bowes | 2.0 Shaping our next century of growth[END_REF], [START_REF] Doole | Estimation of traffic density from drone-based delivery in very low level urban airspace[END_REF].

The mission mix describes the allocation of the mission types as a percentage of the overall flight number of the scenario. The main mission types considered are parcel delivery and food delivery. Food delivery missions have a higher variety of origins and destinations, while parcel deliveries tend to origin from a smaller set of distribution centres. In every mission mix a small number of loitering and emergency missions are added. The particularity of the loitering mission is that they apply dynamic geofences (no fly zones) around their area of mission, while the emergency missions are announced shortly before the requested departure time.

The wind and rogue aircraft variables are described as uncertainties, as they are the ones generating non-nominal conditions. These experimental variables have two values ON or OFF.

VI. DISCUSSION

Metropolis II is currently ongoing, however, some points of interest have already appeared from our research so far. Here we intend to present the main challenges we encountered while developing the three concepts and some remarks generated from the progress of our research.

Constrained airspace poses challenges not present in open airspace. It severely limits the total airspace volume since aircraft must fly between streets to avoid buildings. This severely reduces the total capacity as compared to open airspace. One goal of the simulations is to create traffic densities that stress the capacity to their limit. This is meant to stress the strategic planning capacity of both the centralised and hybrid concepts. Moreover, the limited vertical space makes tactical conflict resolution more difficult because of the reduced space. This will stress the tactical separation solutions of the hybrid and decentralised concepts. However, it is expected to affect the decentralised concept more as aircraft do not have a globally deconflicted path.

Another interesting discussion is about how the concepts will respond to the uncertainties of wind and rogue aircraft. Wind uncertainties are expected to disturb the strategic plan of the centralised and hybrid concepts. Wind uncertainty will slow and speed up drones across the airspace and potentially create conflicts that the strategic planning did not foresee. The wind will stress the tactical separations solutions of the centralised and hybrid concepts. For the decentralised concept, the wind is expected to have a smaller effect on the number of conflicts because the task of solving conflicts is designed to be originally in the tactical side. Rogue aircraft may have similar effects on the safety of all the concepts. Also, rogue aircraft have the potential to create head-on conflicts that the concepts try to avoid with their airspace structure.

The last remark to mention is the time and memory complexity required for each concept implementation. To start with the decentralised concept, the concept was designed to allocate most of the computational load to separate agents according to common decentralised architectures. In order to evaluate the concept, it had to be tested in simulation, which runs using one core of one computer. It quickly become clear that testing an initially designed distributed system in one computational unit as a single thread program requires a great amount of time and memory optimisation. To resolve that problem, the decentralised concept's code was greatly optimised and a part of the data required as simulation input was pre-computed. While the computational cost of the decentralised concept was a hurdle to overcome for the simulation requirements, it would not be presented while designing for a realworld system in which the computational load could actually be allocated among agents. So, reduction of the computational load might not be of the same importance for the decentralised concept as it is for the centralised and hybrid. Both of the later concepts when applied to a real-world situation, they would be required to conduct the total of the flight planning and strategic separation management in one central entity. When designing such a system, someone should consider the time limitations set from the system requirements and the memory limitation set from the computational unit in use and the effect on the capacity of the system.

VII. CONCLUSION

The use of the urban airspace for transportation purposes is anticipated to be in high demand in the near future. Operational concepts and airspace configurations need to be researched, in order to design safe and efficient urban UTM systems. Metropolis II seeks to contribute to the research for U-space U3/U4 services that are crucial to support high urban air traffic densities. This paper presents the main research goals of the Metropolis II project and the experimental methodology followed to achieve them. Three concepts with varying levels of centralisation regarding flight planning and separation management have been designed as part of the project. The concepts have been introduced in sections II, III, and IV and each of them includes an airspace structure design, flight planning and separation management (strategic and/or tactical depending on the type of concept). The concepts were developed for a city which contained open and constrained airspace. The evaluation of the performance of the concepts will be conducted with simulations on a variety of traffic scenarios, as explained in section V.

As described in this paper, several lessons have been learnt already from designing, implementing and prototyping the concepts. The simulations planned are likely to generate a great amount of measurements, which will be used to create the data for around 35 metrics. These will be used in a trade-off analysis to select the most promising of the three concepts. As the final part of the project, the selected concept will be presented in a realworld demonstration.

The final results of the simulations conducted for the project are still under the processing stage and will be uploaded at https://doi.org/10.4121/19700002 when finalised.

Fig. 1 :

 1 Fig. 1: Centralised concept airspace structure, with hexagonal cells in open airspace. The red polygons are geofences areas of open airspace.

Fig. 2 :

 2 Fig. 2: The radial network used within the hybrid concept for open airspace navigation.

Fig. 3 :

 3 Fig. 3: The layered airspace structure used within the hybrid concept for constrained airspace navigation, with cruise layers (green) and deconfliction layers (yellow).

Fig. 4 :

 4 Fig. 4: The layered airspace structure used by the decentralised concept in constrained airspace to minimise the conflicts between cruising aircraft at intersections.

Fig. 5 :

 5 Fig. 5: Overview of the constrained airspace structure used within the decentralised concept, with red and blue streets having different cruise layer height allocations.

Fig. 6 :

 6 Fig. 6: A section of the open airspace with the cells used from the decentralised concept. The no fly zones are the filled in blue polygons. The cells are delineated with black edges and the centre points of the cells are represented with red dots.

Fig. 7 :

 7 Fig. 7: BlueSky showing simulated traffic in Vienna.

TABLE I :

 I Overview of the main difference between the three concepts and their properties.

	Features	Centralised	Hybrid	Decentralised
	Open Airspace	Hexagonal cells Radial grid	Polygonal cells
	Strategic	Yes	Yes		No
	separation
	Main	Strategic	Strategic and	Tactical
	separation		Tactical
	management
	method
	Central entity	Flight planning,	Flight planning	Traffic density
	responsibility	strategic sepa-	and	strategic	measurement
		ration and tacti-	separation	and imposing
		cal separation			geovectors
	Global knowl-	Yes	Yes		No
	edge of flights

ACKNOWLEDGEMENTS

This research has received funding from the SESAR Joint Undertaking under the European Union's Horizon 2020 research and innovation programme under grant agreement No 892928 (Metropolis II).


Philippe Graff

Xavier Marchal

Thibault Cholez

Bertrand Mathieu
email: bertrand2.mathieu@orange.com

Olivier Festor

Efficient Identification of Cloud Gaming Traffic at the Edge

Keywords: Low Latency Traffic, Traffic Classification, Cloud Gaming, Machine Learning, Virtualized Network Function

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

CG was initially thought of in the late 2000s [START_REF] Ross | Cloud computing's killer app: Gaming[END_REF]. The principle is to decouple the player's device from the rendering hardware through the network. Games controls are sent through the Internet to a computer or console located in a datacenter to which the game is deployed and returns the multimedia flow. Early versions failed to gain traction because of limited network performance and slow encoding. Since then, network technologies have evolved and now offer higher bandwidth and lower delays. Several enterprises have launched Cloud Gaming platforms in the past few years, such as Google Stadia (STD), Nvidia GeForce Now (GFN), Microsoft Xbox Cloud Gaming (XC), Sony Playstation Now (PSN) or Amazon Luna. However, this type of traffic is still highly demanding for current network infrastructure. These networks are required to maintain several constraints such as high bandwidth, low delay and low jitter. Failing to which the Quality of Experience (QoE) can degrade significantly. To limit latency, some enterprises implement their own advanced mechanisms, such as Outatime [START_REF] Lee | Outatime: Using speculation to enable low-latency continuous interaction for mobile cloud gaming[END_REF] or Stadia's negative latency algorithms [START_REF] Carrascosa | Cloud-gaming: Analysis of google stadia traffic[END_REF]. On the opposite, some solutions do not even leverage congestion control mechanisms to limit latency increase caused by degraded network conditions [START_REF] Graff | An Analysis of Cloud Gaming Platforms Behavior under Different Network Constraints[END_REF], which can negatively affect user experience. Most implement endto-end mechanisms that take often too much time to detect and react to network issues, leaving the service hard to play with stuttering experienced at the user side, at least during transient phases. The main cause of latency is due to the bufferbloat phenomenon [START_REF] Briscoe | Reducing internet latency: A survey of techniques and their merits[END_REF], [START_REF] Genin | Where in the internet is congestion?[END_REF] that occurs at the edge of the network, resulting in problematic queues. Large buffers are indeed placed at the edge to cope with variations in network capacity, especially in cellular networks. The problem is that these buffers are often full, which adds significant and fluctuating delays.

Meanwhile, new network technologies propose to optimize queuing in network equipment. L4S [START_REF] Briscoe | Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture[END_REF] is one of the most promising solutions. Two queues are defined: one for the common traffic and one for the low-latency (LL) traffic. The LL queue forwards packets with higher priority, respecting a low delay (in the order of 1 ms). Both queues are coupled so as the LL queue does not starve the classic one. In the L4S architecture, a classifier defines in which queue to forward the current packet. Currently, this classification only relies on the ECN bit in the IP header of the packet. It is purely declarative by the end-host and not protected. It has been proven to be vulnerable to misconfigurations or malicious behaviors [START_REF] Bommisetti | Extended ecn mechanism to mitigate ecn-based attacks[END_REF], [START_REF] Laraba | Defeating Protocol Abuse with P4: Application to Explicit Congestion Notification[END_REF]. Any application/endpoint can cheat and set this bit to "1" to be processed by the network as a LL traffic. To avoid this, we advocate the use of an intelligent classifier, which will be able to analyze and detect the LL behavior of the sessions transiting via the L4S node. CG being a LL service, we investigate the network behavior and patterns of this traffic in order to be able to classify it as a LL application. Moreover, since this classification should be done in real-time by a Virtual Network Function (VNF), an efficient method is defined to classify the flows at the edge. The contributions of this paper are the following:

• We select flow-level features and evaluate three Machine Learning (ML) models that aim to detect CG traffic among other high-bitrate UDP applications. The best models provide excellent results (98.5% accuracy); The remainder of this paper is organized as follows. Section II presents the related work on CG platforms and on traffic classification. Then, section III describes our dataset creation. Section IV details the features' creation from raw data. We then present the ML models used. Section V focuses on hyper-parameters fine-tuning. Once done, we evaluate our models' performance in section VI. Section VII presents the implementation of our CG classifier as micro-services. Finally, we discuss the obtained results in Section VIII and conclude this study in Section IX.

II. RELATED WORK A. Cloud Gaming

In [START_REF] Di Domenico | A network analysis on cloud gaming: Stadia, geforce now and psnow[END_REF], Di Domenico & al. study 3 of the biggest CG platforms: STD, GFN and PSN, while [START_REF] Carrascosa | Cloud-gaming:analysis of google stadia traffic[END_REF] made an emphasis on STD. They highlight the different protocols used before and during a game session. All these three platforms transport data over UDP. STD and GFN rely on the Real-time Transport Protocol (RTP) to stream audio and video. PSN uses a proprietary protocol. It is also emphasized that several flows are multiplexed on a single UDP port for STD and PSN. The GFN platform, on the other hand, uses several port pairs. In addition, communications are secured by the Datagram Transport Layer Security (DTLS). The diversity of transport protocols and the use of encryption make it a non-obvious task to classify CG traffic. It can be considered as a special case of encrypted traffic classification.

Another difficulty is that CG traffic is highly sensitive to network conditions. This creates traffic variations to which the ML model must be robust. In [START_REF] Graff | An Analysis of Cloud Gaming Platforms Behavior under Different Network Constraints[END_REF], [START_REF] Suznjevic | Analysis and qoe evaluation of cloud gaming service adaptation under different network conditions: The case of nvidia geforce now[END_REF], the authors alter the network conditions (available bandwidth, latency, jitter and packet loss) and observe the consequences on CG traffic. In [START_REF] Suznjevic | Analysis and qoe evaluation of cloud gaming service adaptation under different network conditions: The case of nvidia geforce now[END_REF], the authors focus on the GFN platform. The authors emphasize that the bit rate drops sharply as soon as latency is introduced. Moreover, the platform takes a long time to resume to a normal state. So, there would be a wrong estimation of the available bandwidth, based on the Round Trip Time (RTT). The QoE is highly impacted by this phenomenon. In [START_REF] Graff | An Analysis of Cloud Gaming Platforms Behavior under Different Network Constraints[END_REF], the four main CG platforms are studied, namely STD, GFN, PSN and XC. Network constraints are enforced at several levels of intensity and are applied before and during a game session. The authors point out that the four platforms exhibit different behaviors when facing network constraints, reacting with variable intensity. They report that CG platforms may have difficulties stabilizing their bit rate after a sudden network change and take a long time to recover once the network returns to a normal state. Even worse, PSN is blind to the added latency.

B. Encrypted Traffic Classification

Traffic classification is a critical task for network operators. The objective is to gain insights of the traffic transiting in their networks. This allows them to better configure the network to meet security or performance requirements. In our case, our goal is to classify CG traffic so as to minimize packet latency. There are several ways to perform network traffic classification. The "Port based" approach consists in matching the TCP/UDP port numbers used with the default application ports given by the Internet Assigned Numbers Authority (IANA). Because most applications use dynamic port numbers, which is the case of CG applications [START_REF] Di Domenico | A network analysis on cloud gaming: Stadia, geforce now and psnow[END_REF], this approach is now obsolete. In our case, we can at least filter some well-known UDP applications with a standardized port number, like for example DNS (port 53), to classify only relevant traffic. The "Payload based" approach consists in studying the payload of the packets [START_REF] Lee | High performance payload signature-based internet traffic classification system[END_REF]. This approach provides good results but suffers from two major downsides; its high computational cost and its inability to handle encrypted traffic that represents the great majority of traffic nowadays. According to [START_REF] Shah | The challenges of inspecting encrypted network traffic[END_REF], the proportion of encrypted traffic reaches 85% and is still growing. In our case, CG traffic is indeed encrypted with DTLS [START_REF] Carrascosa | Cloud-gaming:analysis of google stadia traffic[END_REF].

A third approach consists in considering the statistical properties of the different network flows to be classified and learning them automatically with ML methods. The authors of [START_REF] Velan | A survey of methods for encrypted traffic classification and analysis[END_REF] made a survey on methods for encrypted traffic classification. They note that supervised machine learning methods based on statistical features tend to perform well but regret the lack of study considering TLS traffic instead of SSH and the availability of labeled datasets. A recent study [START_REF] Brissaud | Transparent and service-agnostic monitoring of encrypted web traffic[END_REF] deals with encrypted HTTP/2 traffic. The goal is to filter traffic when a prohibited keyword is searched instead of filtering the whole website and without leaking the exact keyword. To do this, they extract characteristics from the traffic such as TLS connection statistics, record sizes, etc. and use a Random Forest classifier. Their approach achieves a good accuracy, but it depends on the service being monitored. Studies such as [START_REF] Akbari | A look behind the curtain: Traffic classification in an increasingly encrypted web[END_REF]- [START_REF] Wei | Deep learning model under complex network and its application in traffic detection and analysis[END_REF] proposed Deep Learning (DL) models which provide good results for classifying different types of services (video streaming, social networks, web, emails, etc.) and applications (Youtube, Netflix, Facebook, Instagram, etc.), both with HTTP/2 and QUIC (Quick UDP Internet Connections) traffic. Other approaches rely on representation learning. In [START_REF] Wei | Deep learning model under complex network and its application in traffic detection and analysis[END_REF]- [START_REF] Shapira | FlowPic: A generic representation for encrypted traffic classification and applications identification[END_REF], the authors use image recognition techniques to perform classification. They convert raw data into a 2D image. Each image is then submitted to a Convolutional Neural Network (CNN). The output layer consists of as many neurons as there are classes to predict. In [START_REF] Wang | Malware traffic classification using convolutional neural network for representation learning[END_REF], the researchers distinguish two scenarios. In the first one, a binary classifier is applied to determine whether it is malware traffic and followed by two 10-classes classifiers designed to identify sub-classes of malware and normal traffic. The second scenario consists of a single 20class classifier, able to classify all types of traffic at once. In [START_REF] Shapira | FlowPic: A generic representation for encrypted traffic classification and applications identification[END_REF], the authors propose a CNN architecture composed of 7 layers. The 2D image representing a flow is made from packet sizes and packet arrival times. In their study, they just consider unidirectional flows, defined by a 5-tuple. When doing traffic categorization on regular encrypted traffic sessions (non-VPN traffic), their model is outperformed by a simple Decision Tree classifier.

No study so far has tried to classify CG traffic. Our goal is to define a relevant set of features and to evaluate different ML algorithms to select the most suitable to achieve efficient classification of CG flows and ensure an operational applicability.

III. DATASET CREATION

In this section we describe our dataset and how we built it. It was made available for the sake of reproducilibity 1 . It is composed of different network captures (pcap files) collected with Wireshark (v2.6.20) at the client side.

We have developed a first dataset, representative of Cloud Gaming traffic composed of the 4 main CG platforms available in Europe to date2 : STD, GFN, XC and PSN. We only considered full-fledged platforms where the service provider operates the servers in contrast to other CG services that must be instantiated by users like Steam Remote Play, Parsec, Moonlight, Rainway, among others. We made this choice because instantiating CG software by ourselves would result in numerous biases. Indeed, the chosen hardware, its location and the software configuration can have an impact on the performance. In our case, we use commercial services so that the collected traffic is representative (i.e., comes from shared servers, traverses Internet, etc.).

To have a complete dataset, we ensure to collect captures corresponding to different games, frame rates and video resolutions for each platform. Please note that CG platforms support different maximum resolution. For example, only STD allows a game to stream in 4K. According to the possibilities of each platform, we captured resolutions of 720p, 1080p, and 4K and frame rates of 30fps and 60fps. Among the types of games used during our network captures, there are Shooter games (First Person (FPS) and Third Person (TPS)), Platform games and Racing games. When possible, we also vary the input option; keyboard+mouse or controller. The type of input can indeed have an impact on the characteristics of the "clientto-server" traffic.

A second dataset representing "non-CG" (NCG) traffic focuses on high-bitrate applications transported over UDP. If protocol type and port number are not sufficient to detect CG traffic, they can at least be used to easily filter irrelevant traffic. We also neglect DNS traffic (UDP port 53) among the considered UDP applications. We consider 4 types of applications in the "non-CG" traffic class; Videoconferencing applications rely heavily on RTP for transport like CG. A Facebook navigation relies on the QUIC protocol, and therefore on UDP for the transport layer. QUIC is becoming a new standard [START_REF] Iyengar | QUIC: A UDP-Based Multiplexed and Secure Transport[END_REF] supposed to replace HTTP/2 overall. Because of the importance of this type of traffic, we believe it is interesting to take it into account.

Since CG platforms can heavily adapt their traffic to network conditions [START_REF] Graff | An Analysis of Cloud Gaming Platforms Behavior under Different Network Constraints[END_REF] and to ensure that our classifier is general enough to recognize CG traffic in all cases, we made another autonomous set of network captures by playing under degraded conditions. Figure 1 shows a representation of our testbed. We placed a network bridge between our gateway and the CG client, which alters the network conditions using tc-netem rules.

We altered latency, jitter, available bandwidth and packet loss on the downlink. For each platform, we start by applying our constraints, and then we launch a game session. We chose the following values that were used in [START_REF] Graff | An Analysis of Cloud Gaming Platforms Behavior under Different Network Constraints[END_REF] and proven sufficient to trigger the congestion control mechanisms of CG platforms.

• Latency: +20ms; • Jitter: +5ms; • Losses: +5%; • Bandwidth: 10Mbps; The resulting dataset is called "CG disrupted" (CGP).

Overall, we made 57 distinct captures accounting for 17GB of traces, 19 million packets and lasting 240 minutes.

IV. METHODOLOGY

In this section, we first present the features used to classify the data. Then, we focus on the classification methods. We start by presenting our baseline; "Thresholds classifier". This method classifies data according to the number of features falling between pre-defined thresholds. We then briefly describe the other two methods used; a Decision Tree (DT) classifier and a Random Forest (RF) classifier.

A. Considered Features

For each network conversation between two IP addresses, we compute several features per time window. We choose to not consider port numbers to benefit from a higher level of abstraction. Indeed, some platforms use multiple ports to stream audio and video, while other rely on application level or RTP multiplexing (SSRC (Synchronization Source) [START_REF] Graff | An Analysis of Cloud Gaming Platforms Behavior under Different Network Constraints[END_REF], [START_REF] Di Domenico | A network analysis on cloud gaming: Stadia, geforce now and psnow[END_REF].

Because CG traffic is by nature asymmetric (player's commands in one direction and multimedia flow in the other one), we differentiate the statistics from the server-to-client direction (downlink) from those from the client-to-server direction (uplink). We compute the 6 following statistics for each direction of traffic separately:

1) mean packet size; 2) standard deviation of packet sizes; 3) average Inter-Arrival Times (IAT); 4) standard deviation of IATs; 5) total number of packets; 6) total size of application data; We expect to have large packet sizes on the downlink to transport multimedia streams and small packets sizes on the uplink (user's inputs). IATs should exhibit frequent and regular patterns. In the downstream direction, they are driven by the constant number of frames per second (30fps or 60fps). In the upstream direction, they depend on the user's commands probing frequency. The standard deviation of IATs should be therefore lower than for other flows with a bursty traffic pattern like standard video streaming. The amount of data exchanged by direction should allow to differentiate from Video Conferencing that has lower bandwidth and refresh frequency requirements and a different type of information sent on the uplink (video vs commands).

Moreover, these features are computed over a predefined period. To do so, we divide the capture duration into three windows of 33ms, 66ms and 100ms. This is to ensure that at least one video frame is transmitted in a window at the lowest framerate (30fps). We will evaluate the impact of the different window durations on classification performance.

The data are represented as a vector X of features extracted per window i, and a vector Y composed of the associated binary labels (CG:True or non-CG:False). Each element X[i] is composed of 12 features (6 statistics in the server-to-client direction + 6 statistics in the client-to-server direction). We will refer to these elements as instances throughout our study. The purpose of the classifier C is to decide whether or not an element is associated with CG traffic. A good classification would result in

pred i = Y [i]. ∀i, C : X[i] → pred i ∈ {T rue, F alse} (1)

B. Classification methods

We have developed a first simple classifier "Thresholds classifier". It is a baseline that relies on thresholds defined over the features. To configure them, we analyze the training set and observe the distribution of the 12 traffic features. We then compute the 1 st and 3 rd quartiles for each of them. This gives a lower bound Q 1,j and a upper bound Q 3,j for each feature j. When classifying an item, we compare each feature to its related thresholds; Q 1,j and Q 3,j . The final decision is made depending on the total number of features being between the thresholds. If this number is above a certain value (it is a hyperparameter to be evaluated), the item is classified as CG.

The second model is a DT Classifier [START_REF] Safavian | A survey of decision tree classifier methodology[END_REF]. The tree is built during the training phase. Each of its nodes corresponds to a test on one of the 12 features. In our case, it consists in comparing a feature's value to a certain threshold. The thresholds are defined to obtain two homogeneous subsets. Each of these subsets is representative of a label. By default, the algorithm aims at minimizing the Gini index. That criterion is the probability of incorrectly classifying a random data point if it was labeled based on the class distribution. Then, the principle of classification consists in moving along the tree until reaching a leaf, each leaf being associated with a label. We are then able to classify the element considered.

Finally, a RF Classifier is considered. It trains several DTs in parallel and then aggregates the decisions of all its DTs to perform the final classification.

V. HYPER-PARAMETERS TUNING

Our goal is to set some hyper-parameters in a way that balances the classification performance and the computation cost to achieve real time classification. First, we evaluate the impact of the duration of the time window from which statistical features are calculated (see Section IV-A). Then we focus on the hyper-parameters of the 3 classification methods we consider. We seek to optimize Accuracy because we want to avoid a normal flow to be misclassified as a low-latency one and disturb the L4S queue.

A. Impact of the window size

We keep the default hyper-parameters listed in Table I for the DT and RF classifiers and perform a 5-fold cross validation on the whole training set while considering the different window sizes. The training set fairly represents both classes and even CG platforms or applications within a class. The accuracy is reported in Figure 2. For the DT classifier, we get the lowest results for a window size of 33ms. However, we only lose approximately 1% of accuracy compared to the 66ms and 100ms window sizes. In the case of the RF classifier, the results are slightly better. There is no real difference between the results achieved with the different window sizes (even if the lowest result is found for a window size of 33 ms, the difference is insignificant: less than 0.5%). We will therefore choose a window size of 33ms, which allows us to determine as quickly as possible the type of traffic we are dealing with and evaluate more instances per second.

B. Hyper-parameters of the ML models

The first hyper-parameter we consider is the number of features that must fall between the thresholds defined by their 1st and 3rd quartiles to predict CG. We noticed that we could not require that all 12 features satisfy these constraints. Indeed, in this case, the classifier never recognizes CG traffic with the approximated thresholds we defined. We can see in Figure 3 the evolution of Precision, Recall, F1-Score and Accuracy according to the number of constraints to satisfy. We note that if the number of constraints is too small, the classifier tends to always label the traffic as CG. The Precision is then equivalent to the proportion of CG traffic in the testing set (≈ 50%). Conversely, when the number of constraints to be satisfied approaches 12, the Precision increases at the expense of Recall. This means that there are few false positives, but many false negatives. In other words, a large number of CG instances are not recognized, which is a drawback. Therefore, it is necessary to find a compromise in the choice of the parameter. As mentioned in the beginning of the section, we seek to maximize Accuracy. The value maximizing Accuracy is the best compromise between Precision and Recall. We can see in Fig. 3 that with 5 constraints, the Accuracy and F1-Score are maximized. With this value, we have a Precision of ≈ 82% and a Recall of ≈ 70%.

As the RF classifier is made of several DTs, both classifiers share several hyper-parameters. We find max depth, that establishes the maximum depth of a tree. It constitutes an upper bound on the number of tests before classifying an item. max leaf nodes limits the total number of leaves composing a tree. criterion is the function that establishes the quality of a split. We let the default value, which is gini. This metric measures the dispersion of the classes inside a node. max features defines the total number of features to be taken into account for each split. These features are chosen randomly. The rest of the hyper-parameters affect the splitting phase. min impurity decrease is the lowest impurity decrease that a split must satisfy. min samples leaf and min samples split constitute the minimum number of samples in a leaf (resp. node). Then, these last two hyper-parameters are specific to the RF classifier;

• n estimators: the total number of DTs composing the RF classifier. A large number improves the robustness of the samples randomly taken in the dataset (random sampling with replacement). We consider the four following parameters: max depth, max features, n estimators and bootstrap. We decided to study the first three of them because they are related to the complexity of the models, and so their capacity to achieve real time classification. The others will be set to their default values (see Table I). We chose max depth and n estimators because they have a direct impact on the classifiers complexity. Furthermore, the greater the depth of the tree, the greater the risk of over-fitting the training data. To ensure that the trees do not go to deep, we limit their sizes with max depth. By limiting the number of features on which the models are trained, max features also limits the risk of over-fitting. We have set a list of values for each of these hyper-parameters. It is then a matter of testing the models for each combination. For that, we used Grid search to try all the possibilities. This step is computationally expensive. We can see in Table II the values that we have retained for the 4 chosen hyperparameters.

Because our goal is to perform live traffic classification, it is interesting to further investigate the maximum depth to find a compromise between tree depth (that affects the computation cost) and performance gain on Accuracy. As one would expect, both curves exhibit an asymptote. After a certain depth, the gains on Accuracy are negligible. For the DT classifier, we notice that from a maximum depth of 10, the Accuracy stabilizes. For the RF classifier, the same maximum depth could be chosen. For a maximum depth fixed at 10, we have an Accuracy above 98%. It is therefore possible to maintain a high Accuracy while reducing the maximum depth suggested in Table II.

VI. EVALUATION OF ML MODELS

To evaluate the performance of our classifiers, hyperparameters are set to the values maximizing Accuracy for a window size of 33ms, as defined in the previous section. Only the max-depth is fixed at 10. New samples are used for this final evaluation. DT and RF models are built thanks to the scikit-learn [START_REF] Pedregosa | Scikitlearn: Machine learning in Python[END_REF] machine learning library.

A. Normal testing set

The data we use to train the models was acquired under "normal" network conditions. We take care to balance the representation of the CG and NCG instances. Thus, we start with a base of 3356 instances for each traffic class. We then apply K-Fold cross Validation (KFV) on this dataset, with K=5. We can see on Table III The scores obtained by the Thresholds classifier are average at best, justifying the use of more advanced ML methods whose added value is clear. We see for example that the Thresholds classifier has 20% less Accuracy than the DT or RF classifiers. On the opposite, DT and RF achieve excellent classification results, with a reported accuracy of respectively 98.5% and 99.6%. Note that the three other metrics Precision, Recall and F1-Score have same compelling value, ensuring a well-balanced classification without noticeable weakness.

B. Disrupted testing set

In this subsection, we want to evaluate if our models are general enough to classify CG traffic captured in degraded network conditions and so to perform well under all circumstances. We keep the previous models trained on with data captured under "normal" network conditions but we will use traces captured under disrupted network conditions for testing. More precisely, we start by distributing NCG instances uniformly through the training and testing sets. We then add "normal" CG instances to the training set and "perturbed" CG instances to the testing set. We also make sure that NCG and CGP are equally represented in the latter. More specifically, the testing set consists of 1882 instances of disturbed CG traffic versus 1882 instances of "non-CG" traffic, all applications type considered.

Our results are shown in Table IV and the corresponding confusion matrices in Table V. The first column represents the labels to recognize and the last row shows the predictions made by the two models. The lower left corner of each matrix corresponds to the total number of False Negatives (FN). On the other hand, the upper right corner represents the False Positives (FP). For each label, we show its ratio of good predictions and wrong predictions. For example, considering CG traffic, the DT classifier has 91.66% good predictions (resp. 8.34% wrong predictions). From these two matrices, we can calculate the performance metrics given in Table IV. If we compare Tables III andIV, we can notice a slight decrease in Accuracy (not more than 6%) for the DT and RF classifiers. However, these results are still good, suggesting that our models are general enough to recognize CG traffic under various network conditions.

But our approach can provide even better results when we add some "perturbed" CG instances to the training data set. The evaluation applied to the same testing set now gives F1 scores of 97.5% for the DT classifier and 98.8% for the RF classifier. So, helping the model to learn the range of adaptation of CG traffic reduces the performance decrease from 6% to 1% when classifying such perturbed CG traffic.

In consideration of all these results, we finally retain the DT classifier. Not only are its results equivalent to those of the RF classifier, but it is also much less complex to execute (we have indeed seen in Table II that a RF classifier should be made up of 119 DTs) and the gain in classification performance is not worth it. Overall, the excellent classification performance can be explained by the fact that CG traffic has specific patterns that are well captured through by the 12 features we selected. It is thus easy for our classifier to recognize CG traffic. This is a finding of the paper. The risk of overfitting is minimal for several reasons: 1) DT is a simple model that is less subject to overfitting, 2) we limit the maximum tree depth to 10 using pre-prunning, 3) we use a small number of features, 4) we use K-fold cross-validation, and 5) the high accuracy is confirmed by the disrupted dataset whose traces were not

VII. IMPLEMENTATION OF VNFS TO PERFORM LIVE

CLASSIFICATION

In this section, we present our micro-service architecture to implement the DT classifier. The source code is available and released in open-source 3 . We assessed that the classification performance achieved by our live classifier implementation is in compliance with the results of the DT model in Table III and will focus our evaluation of the implementation on its capacity to handle a high traffic load.

A. Micro-service architecture of the classifier

The first micro-service facing the traffic is a probe that listens to a given network interface. For each network conversation between two IP addresses, a report is created every 33ms. A report includes the 12 features described in Section IV-A and the IP address pair concerned. Each report is sent in a single UDP packet. The probe is written in C++, and the code is open-source 4 . The load-balancer listens to the probe's reports and is responsible for distributing the load among the different compute nodes. We distribute the load by applying a round robin strategy, but another method can be easily implemented. In our testbed, the probe and the loadbalancer are executed on the same machine and communicate via the loopback interface. However, they are designed to be executed on different hosts. In fact, our micro-service architecture makes it possible to either run the compute nodes at the edge or in a cloud-provider datacenter, depending on the resources/space available. The compute nodes execute the DT model and are responsible for determining whether the received report is a CG report or not. Once the classification is done, the result is sent to the last component of the chain. The aggregator finally associates each IP address pair with the set of its predictions. At the end of the chain, we associate to each IP address pair the percentage of reports classified as CG. The whole architecture is illustrated in Figure 4.

B. Performance Evaluation

We divide our evaluation into two parts. We start by evaluating the probe that observes network traffic to generate features. Then, we evaluate the components that classify the reports generated by the probe. The server used for this experiment is Gbps aggregated. We use one dedicated core for the probe and one per classifier instance. The load balancer and aggregator share a core with the system. 1) Probe Evaluation: To evaluate the network performance of our probe, we deployed iperf instances on two servers generating bidirectional traffic. Only one of these servers runs the probe. Most of the given results are not limited by the probe itself, but by the CPU load induced by the iperf instances to generate traffic.

Regarding the throughput, we report around 30 Gbps of traffic captured by the PF PACKET socket (only the first 82 bytes of each packet are captured by our probe), using ∼60% of a CPU core for the capture thread (excluding features computation). Since the probe does not capture the packet payload by focusing only on header parsing, the performance is the same for large and small packets.

The number of packets processed per second is around ∼2.80 Mpps with similar CPU usage. Regarding how many windows per second the probe can handle, we fixed the global throughput to 10 Gbps, that is today a classical bandwidth seen on access networks. It can handle 1000 flows at 10 Mbps without suffering losses. This costs ∼70% of the parse thread and ∼37% of the compute thread to generate a bit more than 29100 reports/s. We also tested 2000 flows of 5 Mbps. Here, traffic generation induces so much load that it is difficult to distinguish the bottleneck. Without reporting any loss, the probe sends up to 49800 reports/s. However, the parse thread is at 100% and the compute thread at ∼70% of CPU usage. All cores assigned to iperf instances exceed 94% CPU usage.

2) Classifier Evaluation: For this experiment, we replayed the probe's reports at predefined rates. Each experiment lasts 30 seconds. The columns in Table VI gives respectively the number of reports sent per second, the number of classification nodes deployed, and the number of reports processed per second by the live classifier. Ideally, this value should be equal to the value of the first column. To achieve a classification rate of 10.000 reports per second, a second compute node must be added. The same observation can be made when moving to a throughput of 20.000 reports per second, going from 2 to 3 classification nodes. We can see that for 30.000 reports sent per second, only 68.5% of the reports are processed when 3 classification nodes are deployed. When we go from 3 to 4 classification nodes, we notice that the processing speed increases by 24.6%. However, 8% of the reports are not classified, and a 5th additional node is required. Globally, the improvement of the classification speed brought by the addition of a compute node scales almost linearly with the number of nodes, which was expected. Please note that the classification time per window is the same for all window sizes (33ms, 66ms, 100ms), since it just considers the 12 features. In addition, the overhead of the window size on the probe is negligible. Of course, the smaller the size, the more samples are to be classified per second, which requires more computing power.

To conclude, we can say that our live classifier can efficiently process traffic on-the-fly. Based on our two-levels performance evaluation, it appears that the entire solution can support 1.000 parallel flows of 10 Mbps on a low-end x86 server if we instantiate 5 classification services in parallel.

VIII. DISCUSSION

Like all machine learning approaches, our models may be biased due to the dataset, despite carefully building the models. It would be interesting to further extend our datasets, especially in regards to the diversity of applications in the Non-Cloud Gaming dataset.

Considering the fast identification of CG traffic (33ms windows), we can imagine ways to stabilize and strengthen the classification decision by observing the traffic during a longer period (a few seconds) and taking the majority label among reports. The traffic between two IP addresses can also be periodically re-evaluated at a frequency to be defined (for instance every minute). This will also save resources from the live classifier to process in priority new starting flows.

The live classifier presented in Section VII follows a VNF (Virtualized Network Function) approach. The solution is built to be run in containers within a NFV architecture (Network Function Virtualization). The network performance of the probe could be improved by leveraging the DPDK technology (Data Plane Development Kit, a set of libraries and drivers that accelerates packet processing in Linux applications) if needed. The compute nodes should be automatically scaled according to the current load level by the NFV orchestrator in use, for instance Kubernetes.

Another approach would consist in doing all the processing in a programmable switch (e.g an Intel Tofino) thanks to the P4 (Programming Protocol-independent Packet Processors) language [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF]. The advantage of this language is that a program can be written once and compiled according to the targeted network hardware. Recent advances in P4 programming have shown that it is possible to implement simple ML models like a DT in P4. In [START_REF] Xiong | Do switches dream of machine learning? toward in-network classification[END_REF], the authors present a method to map trained machine learning models to match-action pipelines. It is therefore possible to use our trained DT classifier to do live classification directly on the data plane. Nevertheless, we must face the inherent limitations of the P4 language, but also those of the targeted network equipment. Among P4 inherent constraints, we can highlight that it does not contain any type for representing floating point numbers. Therefore, our mean and variance calculations will have to be approximated, which may impact the classification performance of the model. A re-training of the ML model considering the various approximations imposed by P4 seems to be inevitable if we want to classify from a P4 switch. Using P4 and programmable switches to do classification seems to be more optimal than using VNFs. Indeed, the switch itself would calculate the features, do the classification, and drive the AQM.

Please note that the classification result could be propagated by Diffserv. Therefore, it would be possible to trigger specific network treatments in the core network, for instance by selecting routes based on the latency criteria. However, the expected gain would be limited to a slight and constant latency reduction and may not be worth the effort. It is more important to help solving the bufferbloat problem at the edge since it can add unpredictable latency increase and variation, or even packet drops.

IX. CONCLUSION

The main motivation behind this work was to classify CG traffic to make it benefit from the low-latency queue, as defined by the L4S architecture. This can reduce latency perturbations that degrade the QoS at the edge of the network. We have presented and evaluated three models (Thresholds, DT, RF classifiers) to detect CG traffic from other high bitrate UDPbased applications. They rely on 12 features extracted from network flows. Our results showed that CG traffic is specific enough to allow excellent classification results with the DT model. We selected this model because of its high identification accuracy (98.5%), its ability to recognize CG traffic under degraded network conditions, and its lower complexity compared to RF. We also proposed and evaluated a full implementation of the classifier as a micro-service architecture that can be deployed as VNFs (regarding the NFV paradigm) to efficiently classify CG traffic at the edge. Our implementation is scalable, can easily process 10Gb/s of medium-sized flow on a low-end x86 server. The dataset composed of full packet captures of CG traffic and other UDP applications used for this study is available for the community, as well as the source code of the micro-service implementation.

Our future work will integrate our classifier with a L4S architecture and evaluate the gain for CG platforms to respect latency requirements under limiting network conditions. Because we use simple features and models, we will also consider implementing our classifier directly in the data plane, leveraging the P4 programmable network technology. We will evaluate the benefit of this approach compared to the microservice architecture.

Fig. 1 :

 1 Fig. 1: Testbed to collect network traffic

Fig. 2 :Fig. 3 :

 23 Fig. 2: Impact of Window size and Maximum depth on the Accuracy of DT (left) and RF (right) models

Figure 2 (

 2 right) shows the accuracy that is achieved according to the

  different performance metrics related to CG recognition. A correct classification of a CG element constitutes a True Positive (TP). The values displayed were obtained by averaging the scores obtained by each KFV iteration.

Fig. 4 :

 4 Fig. 4: Micro-service architecture of the live classifier

  We propose a high performance VNF implementation of our classifier as micro services. It can classify network flows at line rate (more than 10Gb/s). The code is also open source.

• We publicly release a dataset composed of network traces (pcap files) of the four main CG platforms, and other services running on UDP; •

TABLE I :

 I DT & RF default hyper-parameters

	Hyper-Parameter DT	RF	Testing Range
	max depth	15	20	[2; 24]
	max features	8	3	[1; 12]
	n estimators	-	119	[80; 119]
	bootstrap	-	F alse	{T rue; F alse}

TABLE III :

 III CG traffic classification, normal conditions maximum depth value of DT and RF classifiers, respectively.

TABLE IV :

 IV CG traffic classification, disrupted testing set

		DT		RF
	True NCG 1753 (93.15%) 129 (6.85%)	1793 (95.27%) 89 (4.73%)
	Label CG 157 (8.34%)	1725 (91.66%) 98 (5.21%)	1784 (94.79%)
	NCG	CG	NCG	CG
		Predicted label

TABLE V :

 V Confusion Matrix of DT and RF classifiers for a disrupted testing set

TABLE VI :

 VI Performance evaluation of the DT classifier microservice an Arch Linux system with two CPU Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz(released in 2012). Each CPU has 8 physical cores. The network link used has a capacity of 2x10

https://cloud-gaming-traces.lhs.loria.fr/data.html

November 2022

https://github.com/mosaico-anr/CG Classifier

https://github.com/Nayald/probe-CG-detection

ACKNOWLEDGMENT

This work is partially funded by the French ANR MO-SAICO project, No ANR-19-CE25-0012.


Modeling and estimation for biological plants

Dyhia Bouhadjra

To cite this version:

  Dyhia Bouhadjra. Modeling and estimation for biological plants. Engineering Sciences [physics]. Université de Lorraine; Università degli studi (Gênes, Italie), 2022. English. NNT : 2022LORR0215. tel-04015434 Ce document est le fruit d'un long travail approuvé par le jury de soutenance et mis à disposition de l'ensemble de la communauté universitaire élargie. Il est soumis à la propriété intellectuelle de l'auteur. Ceci implique une obligation de citation et de référencement lors de l'utilisation de ce document. D'autre part, toute contrefaçon, plagiat, reproduction illicite encourt une poursuite pénale. Contact bibliothèque : ddoc-theses-contact@univ-lorraine.fr (Cette adresse ne permet pas de contacter les auteurs) LIENS THÈSE de DOCTORAT DE L'UNIVERSITÉ DE LORRAINE en cotutelle avec : l'Université de Gênes, Italie Ecole Doctorale : IAEM Présentée et soutenue publiquement le 15 décembre 2022 pour l'obtention du : Doctorat de l'Université de Lorraine Spécialité Automatique, Traitement du Signal et des Images, Génie Informatique par Dyhia Bouhadjra Modélisation, et estimation pour des systèmes biologiques Devant le jury composé de : Mauro GAGGERO Maître de conférences, Conseil national de la recherche d'Italie Dalil ICHALAL Professeur, IBISC, Université d'Evry Val d'Essonne -Université Paris Saclay Patrizia BAGNERNI Maître de conférences, DIME, Université de Gênes Ali ZEMOUCHE Maître de conférences, CRAN, Universite de Lorraine Angelo

Code de la Propriété Intellectuelle. articles L 122. 4 Code de la Propriété Intellectuelle. articles L 335.2-L 335.10 http://www.cfcopies.com/V2/leg/leg_droi.php http://www.culture.gouv.fr/culture/infos-pratiques/droits/protection.htm