Figure 4.7: Validation croisée (k=5)
4.5
Jeu de données considéré
4.5.1 Pré-requis
Comme indiqué ci-dessus, nos modèles basés sur un apprentissage de type super- visé, requièrent une phase d’entraînement utilisant un jeu de données. Dans notre cadre d’étude, nous nous focalisons sur le cas de réseaux cellulaires LTE, dans un environne- ment urbain.
Afin d’évaluer les modèles proposés dans un cadre réaliste, il faut disposer d’un jeu de données respectant les exigences suivantes :
— R1 - Cellule réseau / NAP : Considérer des cellules avec des portées de communi- cation variées (petite et grande couverture). En plus, il est nécessaire de connaître les positions géographiques de ces entités pour pouvoir calculer la distance et l’angle d’arrivée.
— R2 - Trafic routier : Disposer de données de véhicules (vitesse, localisation) roulant dans la majorité des routes (principales et secondaires) couvertes par une cellule donnée.
— R3 - Taille du jeu de données : Une collecte de données pour une longue du- rée permettant d’explorer les variations temporelles des métriques mesurées, par exemple durant la journée (matin, midi, soir) ou durant la semaine (jours ou- vrables, week-end), etc.
4.5.2 Limites des jeux de données existants
Dans les réseaux cellulaires, particulièrement le réseau LTE, diverses campagnes de collecte de données ont été réalisées par la communauté scientifique dans le but de produire des jeux de données exploitables, par exemple pour étudier les performances de
ces réseaux. Cependant, très peu de ces jeux de données sont disponibles en accès libre. En plus, ils ne considèrent pas forcément une mobilité urbaine et ne disposent pas de tous les paramètres considérés par nos modèles.
Un récent jeu de données, qui est publiquement accessible et qui dispose de la majorité des métriques considérées, a été analysé. La collecte de données a été réalisée dans la ville de Cork (Irlande) pour différents scénarios de mobilité et auprès de deux opérateurs de téléphonie mobile (FAI). Cependant, ce jeu de données a quelques limites par rapport aux pré-requis listés ci-dessus :
— R1 - Différents types de cellules sont considérés, étant donné que la collecte est effectuée auprès de deux FAI. Cependant, les positions géographiques sont indis- ponibles pour certaines BS, limitant le calcul des deux features (Distance et angle d’arrivée) indispensables pour nos modèles.
— R2 - Différents scénarios de mobilité sont pris en compte durant la collecte (bus, voiture, train), et des données de mobilité sont disponibles (vitesse et position GPS du véhicule). Cependant, les mesures sont souvent effectuées pour le même trajet (travail - domicile), ce qui signifie que pour une cellule donnée, nous ne disposons que des mesures concernant une seule route.
— R3 - La collecte a été effectuée pendant une longue durée et durant différents jours de la semaine. Chaque trace correspond en moyenne à un trajet de 30 minutes par jour.
Ce jeu de données répond à la majorité des pré-requis. Cependant deux principales limitations restreignent son utilisation dans l’entraînement et l’évaluation de nos modèles. La première est relative au fait que les mesures sont effectuées en utilisant majoritairement la même trajectoire. La deuxième concerne le manque de quelques attributs. Par exemple, le nombre de véhicules actifs par cellule peut manquer, certaines positions géographiques de stations de bases ne sont pas disponibles, ce qui limite le calcul des attributs distance et angle d’arrivée.
4.5.3 Collecte de données
Étant donné qu’aucun jeu de données ne correspond pleinement à nos pré-requis, nous avons décidé de générer notre propre jeu de données. Des contraintes techniques et financières limitent la réalisation d’une compagne de collecte de données. Par consé- quent, nous nous sommes orientés vers une approche basée sur des outils de simula- tion/émulation de mobilité et réseaux LTE.
Nous avons utilisé le framework VEINS (VEhicles IN Simulation) [Sommer 2011]. C’est un des cadres de simulation (frameworks) les plus utilisés par la communauté pour la simulation des réseaux véhiculaires. Il est basé sur deux simulateurs bien établis : OMNeT++ [Varga 2008], un simulateur de réseau basé sur des événements, et SUMO [Krajzewicz 2012], un simulateur de trafic routier microscopique. Nous utilisons OMNET avec l’extension du réseau LTE basée sur SimuLTE afin de simuler la pile protocolaire
4.5. Jeu de données considéré 123
LTE (puissance du signal, décisions de handover, etc.), et le simulateur SUMO afin de si- muler la mobilité des véhicules. Le framework global permet de simuler une connectivité LTE pour les véhicules, roulant dans un environnement de mobilité réaliste.
Notre configuration de simulation (set-up) se compose de deux principales parties : la première concerne la mise en place du réseau LTE, tandis que la seconde concerne la mise en oeuvre de la mobilité des véhicules. Nous avons utilisé le scénario de mobi- lité LuST (Luxembourg SUMO Traffic) conçu par Codeca et al. [Codeca 2015]. Il est généré à l’aide de SUMO et est basé sur le réseau routier de la ville de Luxembourg. La trace reproduit le comportement de mobilité de près de 300 000 véhicules composés de différents types de véhicules (véhicules personnels, véhicules de transport public, etc.) dans une zone de 156 km2 pendant 24h. Dans notre étude, nous nous focalisons sur le scénario urbain. Pour cela, nous avons sélectionné une zone de 2,5*2,5 km dans le centre ville composée de routes résidentielles et artérielles, comme montré sur la figure 4.8a. Le nombre de véhicules roulant dans cette zone ainsi que leurs vitesse moyenne sont représentés respectivement en lignes bleues et rouges sur la figure 4.8b . Concernant le réseau LTE, nous avons utilisé les emplacements eNodeB d’un opérateur de réseau mobile luxembourgeois tels qu’indiqués par le projet LuST-LTE [Derrmann 2016] pour le scénario de mobilité LuST. Nous avons placé les 16 eNodeB de la zone sélectionnée, comme le montre la figure 4.8a. Pour les paramètres de simulation du réseau LTE, nous avons utilisé ceux fournis par défaut par le projet SimuLTE [Virdis 2015], par exemple, les procédures de handover implémentées dans SimuLTE [Virdis 2015] et décrites dans [Derrmann 2016], sont basées sur le SINR (Signal-to-Interference-and-Noise-Ratio) au lieu de RSRP (Reference Signal Received Power) et RSRQ (Reference Signal Received Quality) comme spécifié dans la norme pour les réseaux LTE.
(a) positions géographiques des BS (b) détails de mobilité
4.5.4 Description du jeu de données
Table 4.1: Features Collectés (c) et Générés (g)
Feature Description
(c) Vehicle Id Un identifiant unique par véhicule. (c) Vehicle posi-
tion
Coordonnées de position du véhicule (x,y), peuvent être converties en coordonnées GPS
(c) Speed (m/s) Vitesse du véhicule en m/s
(c) Serving Cell id L’identifiant de la cellule qui couvre le véhicule (c) Serving Cell
position
Coordonnées de position de la station (x,y), peuvent être converties en coordonnées GPS
(c) Timestamp of association (s)
L’horodatage où le véhicule s’est associé à un eNodeB
(c) Timestamp of dissociation (s)
L’horodatage où le véhicule s’est détaché d’un eNodeB
(c) Road_Id L’identifiant de la route (c) Line_Id L’identifiant de la ligne (g) Distance to
serving Cell (m)
Distance entre le véhicule et la station à laquelle il est at- taché ( D - Calculée en utilisant l’équation 4.1)
(g) Link duration (s)
Temps de connectivité entre un véhicule et une station de base donnée
(g) Cell load Nombre de véhicules sous la couverture d’une BS, à un instant donné
(g) Previous cell Dernier point d’attachement auquel un véhicule était connecté
(g) Next cell Prochain point d’attachement auquel un véhicule sera connecté
(g) Theta L’angle d’arrivée (θ - Calculé en utilisant l’équation 4.2)
Le Tableau 4.1 décrit les divers features de notre jeu de données. Nous en distinguons deux types :
— Collectés (C) : Ils sont collectés directement en utilisant le framework VEINS. Ils concernent principalement la mobilité des véhicules (vitesse, position, etc.) et les décisions de handovers (moment d’attachement, détachement, etc.)
4.5. Jeu de données considéré 125
— Générés (G) : Ils sont calculés à partir des features collectés, par exemple la durée du lien est calculée en utilisant la différence entre le moment d’attachement et le moment de détachement d’une BS, ou la distance et l’angle d’arrivée en utilisant les équations 4.1 4.2.
Nous avons effectué des mesures pour tous les véhicules roulant dans la zone sélec- tionnée pendant les 24h de mobilité. Le nombre total des véhicules est de 147554. Ce qui a engendré un jeu de données brut de 824774 observations, réparties sur les différentes stations de base, comme le montre la figure 4.9b. La portion de données générée par chaque station de base dépend principalement de l’emplacement de chaque BS, et de la densité du trafic dans chaque zone.
Les durées de vie des liens (LLT) varient d’une BS à l’autre, comme le montre la figure 4.10. Ces variations dépendent principalement de la portée de communication de chaque station de base (présentée dans la figure 4.9a), et le trafic routier dans chaque zone. Par exemple, en moyenne, les BS3 et BS2 ont enregistré des valeurs plus élevées que les BS9 et BS13. La raison principale est qu’elles couvrent une zone plus étendue.
Nous remarquons aussi à travers les distributions de durée de vie des liens, qu’on dis- pose de plusieurs profils de BS avec diverses caractéristiques, ce qui permet d’évaluer le modèle dans des conditions plus variées et réalistes.
(a) Couverture de chaque BS
(b) Poportion de données par BS
Figure 4.9: Couverture et proportion de données par BS
Afin de vérifier le réalisme des données collectées, nous comparons notre jeu de don- nées à celui réalisé dans la ville de Cork, présenté précédemment. Nous avons sélectionné les traces du scénario urbain (avec bus et voitures, pour les deux opérateurs) et nous avons calculé les durées de vie des liens (T) en nous basant sur les décisions de hando-
ver qui sont enregistrées avec une granularité d’une entrée par seconde. La figure 4.11
montre l’histogramme des valeurs de LLT inférieures à 300 secondes pour les deux jeux de données.
Figure 4.10: Diagramme en violon de la durée LLT (s) par BS (sans anomalies)
valeur représentent une grande partie des valeurs enregistrées. En particulier, dans le jeu de données réel, la plupart des durées de vie sont inférieures à 15s. Il est probable qu’une grande partie des mesures a été enregistrée sur des routes couvertes par de pe- tites cellules ou à des moments où les véhicules roulent à une grande vitesse, ce qui a généré plusieurs liens de petites valeurs. D’autre part, la différence de la forme des histogrammes peut être expliquée par la taille des jeux de données ainsi que les zones où les collectes ont été réalisées. En effet, l’ensemble des observations du jeu de données réel est d’environ 1500, comparé à 800 000 observations dans notre jeu de données. De plus, dans le jeu de données réel la collecte a été majoritairement réalisée sur le même trajet
(route principale couverte par les mêmes cellules), par rapport à notre collecte qui a été
réalisée sur une zone avec un nombre plus élevé de routes (principales et secondaires) couvertes par des cellules de diverses tailles.
Le jeu de données a été nettoyé (correction de valeurs manquantes, suppression des valeurs aberrantes (outliers), etc.) et mis a disposition de la communauté scientifique [git ].