Hyperviseur de Passerelles/Interfaces Sans Fil pour un Laboratoire Mobile de Nouvelle Génération

Hyperviseur de Passerelles/Interfaces Sans Fil pour un Laboratoire Mobile de Nouvelle Génération

Genèse des véhicules connectés

 Avec la demande « full option » pour les véhicules, les systèmes de contrôle et de régulation, qui premièrement étaient implémentés de façon mécanique, sont remplacés progressivement par des systèmes électroniques. Ces systèmes deviennent de plus en plus complexes avec l’intégration d’une multiplicité de capteurs, de systèmes de contrôles et d’interfaces exigeant beaucoup plus de bandes passantes. Ainsi, les véhicules modernes emploient généralement un nombre important de ECU (Electronic Control Units) où sont reliés un ensemble distribué et disparate de capteurs et d’actionneurs. Les ECU permettent l’échantillonnage et le traitement des données issues de ces capteurs et en même temps du transfert des commandes vers les actionneurs. Ainsi, on peut retrouver jusqu’à des centaines de capteurs servant à l’acquisition de données relatives à l’état des pièces mécaniques et électroniques, à la perception, à la mesure de grandeurs environnementales… Ces capteurs peuvent être regroupés suivant trois champs d’applications majeurs [1]– [3] : groupe motopropulseur, sureté et confort. Les ordinateurs de bords (OBU, On-Board Units) ont été, à la base, développés pour des applications de tracking via GPS. Cependant, les capacités de l’OBU ont vite évolué avec notamment la possibilité de recueillir les données de capteurs, et la possibilité de pouvoir communiquer avec des entités externes au véhicule. Ces nouvelles possibilités ont été exploitées pour le développement d’applications [4]–[6] pour les VANET (Vehicular Ad Hoc Network). Ces applications étaient principalement liées à la sécurité/sureté routière, à l’efficacité du trafic et d’assistance à la conduite. La génération suivante de OBU est dédiée aux ITS et introduit le concept de la communication V2X (Vehicle-to-Everywhere) qui intègre beaucoup plus de types d’interactions via les technologies DSRC/WiFi/LTE. L’IoV introduit la « cloudification » des véhicules par la création de nouveaux services cloud. La cinquième génération de réseaux mobiles (5G) est censée répondre au exigences de communications V2X [7], en permettant, entre autres, aux services cloud de s’approcher de la vision 4A (Anywhere, Anytime, by Anyone and Anything).  Un véhicule connecté diffère des autres types de véhicules de part sa capacité à non seulement pas pouvoir communiquer, mais de pouvoir le faire à travers différentes voies technologiques [8]. Un véhicule connecté est ainsi imaginé comme un modèle multicommunicant, appelé communication V2X. Ces véhicules accèdent, consomment, créent, enrichissent, dirigent et partagent l’information entre les individus, organismes, milieux d’affaires, infrastructures, et autres objets connectés. Selon les prévisions de Gartner [9], d’ici 2020, un véhicule sur cinq sera un véhicule connecté, soit environ un quart de milliard de véhicules. Par conséquent l’IoV occupera une place prédominante dans l’Internet des Objets (IoT, Internet of Things). Cet optimisme est réitéré dans un autre article de presse intitulé « Forget the Internet of Things : Here Comes the ‘Internet of Cars’ » [10], où T. Koslowski soutient que pour l’industrie automobile, connecter les véhicules est désormais le critère prédominant dans la phase d’innovation. Les consommateurs souhaitent accéder à l’information partout où ils se trouvent, même dans les véhicules. Ainsi, ils affichent un grand intérêt pour les fonctionnalités offertes par les véhicules connectés. On peut d’ailleurs citer la popularité et le succès des applications telles que Android Auto, Apple CarPlay ou encore Waze. En outre, un système d’exploitation dédié au véhicule sera opérationnel est en cours de développement ; il s’agit d’Android Automotive développé par Google. En somme, avec le concept de l’IoV, les véhicules sont en passe de devenir plus connectés, plus intelligents, et intégreront un riche écosystème de services et d’applications. 

Laboratoire Mobile de Nouvelle Génération 

Le recours aux Laboratoires Mobiles (LM) vient répondre aux besoins exprimés par les acteurs de l’industrie, gouvernement, médecine, armée, organismes de recherche… La première génération de LM fonctionnait à base d’un ensemble d’équipements de relève mobiles tractés le plus souvent par des véhicules. Ces équipements étaient composés d’ordinateurs, de système de stockage, de systèmes de communication et d’un ensemble d’instruments de mesure embarqués. Le véhicule peut aussi communiquer avec un réseau de capteurs sans fil (WSN, Wireless Sensor Network), dans ce cas précis le terme Data MULE (Mobile Ubiquitous LAN Extension) [11] est associé au véhicule. La transmission des données se fait via un réseau tolérant aux délais (DTN, Delay-Tolerant Networking). Le DTN s’appuie sur des connectivités alternatives (réseaux mobiles, WiMAX, satellites…), et est surtout adapté pour les zones à faible densité réseau. L’avantage de ce type de LM réside sur leurs faibles coûts de déploiement, par contre aucune « intelligence » n’est intégrée au véhicule, qui d’ailleurs est considéré comme une « mule ». Introduction 3 Les réseaux de capteurs véhiculaires (VSN, Vehicular Sensor Networks) [12], [13] sont un nouveau paradigme réseau qui hérite du concept de VANET et de WSN. Cela confère au VSN des propriétés uniques telles que le changement dynamique des zones d’intérêts, la collecte de données issues du véhicule lui-même et de son environnement immédiat. Plus récemment, le VSN s’est dissous dans un autre nouveau concept beaucoup plus large et plus prometteur ; il s’agit de l’IoV. Ce dernier s’appuie sur l’IoT pour faire évoluer le véhicule d’un simple nœud dans les VANET en une plateforme intelligente capable d’apprendre, de penser et de comprendre les systèmes cyberphysiques par lui-même [14]–[16]. Dans [17], les auteurs posent les principaux challenges à relever dans les réseaux de capteurs intelligents (ISN, Intelligent Sensors Network). Ainsi, en se basant sur le concept de l’ISN, l’intelligence des réseaux de capteurs peut être atteinte de quatre façons : la sensibilité spatiale, la sensibilité de donnée, la sensibilité de groupe et la sensibilité de contexte. Dans [18], le concept de sensibilité spatiale collective a été développé pour les systèmes d’information et de communication par le biais de trois entités : Self, Others et Environment. Le concept de Laboratoire Mobile de Nouvelle Génération peut être considéré comme étant la combinaison des concepts suscités. Lorsque les véhicules connectés sont transformés en LM, ils pourront tirer parti de leur mobilité pour étendre le domaine d’observation d’un phénomène. La technologie pouvant gérer efficacement les données générées et en même temps orchestrer l’ensemble des services/applications en lien avec l’IoV sera sans doute le Cloud Computing [19], [20]. Le Sensing as a Service (S2 aaS), terme utilisé pour la première fois par Sheng et al. [21], est à l’origine conçu pour offrir des services liés à l’exploitation des capteurs incorporés dans les smartphones. Ce concept pourrait aussi être élargi pour pouvoir aussi gérer les données de capteurs automobiles. L’usage de véhicules comme capteurs mobiles présente plusieurs avantages comme décrits dans [2] : très grande variété de capteurs, quasi-absence de contraintes d’énergie, possibilité d’embarquer des ordinateurs puissants, capacité de stockage élevée… En outre, la collecte de données s’effectue de façon continue et automatique. En effet, partout où il y a des routes, des véhicules y circulent et pourront y collecter des données. On se retrouve donc avec une diversité spatiotemporelle des données collectées. Comparé au déploiement de capteurs dédiés (fixes), l’usage de véhicules comme capteurs mobiles est beaucoup plus avantageux. En effet, les capteurs fixes nécessitent un lourd investissement et un long temps de déploiement. En outre, ces capteurs sont restreints à couvrir une petite zone d’observation, contrairement aux véhicules qui tireront parti de leur mobilité pour couvrir une plus grande zone. Un autre avantage est le bas coût d’acquisition des données. En effet, tout le dispositif nécessaire (capteurs, réseau interne, unité de traitement…) pour le bon fonctionnement du Laboratoire Mobile de Nouvelle Génération est déjà incorporé dans le véhicule.

Problématique et challenges

Les premiers modèles de communication pour les véhicules ont été pensés à l’origine pour supporter des applications de sécurité routière. De ce fait, le VANET est proposé pour permettre aux véhicules de pouvoir communiquer directement entre eux sans passer par l’intermédiaire d’une infrastructure. Le VANET s’appuie essentiellement sur la technologie DSRC (Dedicated ShortRange Communications) et la norme 802.11p. Toutefois, l’adoption de la technologie DSRC a été retardée en raison de sa faible évolutivité et des difficultés de communication imposées par les environnements à forte mobilité et à topologie hautement dynamique [24], [25]. Notons également que le modèle de communication des Laboratoires Mobiles de Nouvelle Génération est un modèle orienté cloud, or les VANET ne peuvent pas fournir des services et applications à portées globales et durables. En effet, les entités impliquées sont temporaires, aléatoires, instables et à usage local [15]. En outre, les exigences des LM peuvent dépasser les limites de ce que les dispositifs et protocoles de communication actuels sont en mesure de fournir [26], [27]. Le déploiement à large échelle des Laboratoires Mobiles de Nouvelle Génération soulève quelques questions, à savoir : Introduction 6 Comment transformer un véhicule connecté en un Laboratoire Mobile de Nouvelle Génération ? Quel(s) modèle(s) de communication faut-il proposer pour répondre aux besoins de communication des services/applications des LM ? Quel(s) modèle(s) de communication faut-il proposer pour faciliter la transformation et l’intégration des données issues des capteurs automobiles en connaissances utiles ? Quel(s) modèle(s) réseau faut-il proposer pour assurer un échange optimal des données entre les LM et les autres entités impliqués ? La première entrave pour le développement des LM réside sur la nature très intégrée des technologies automobiles. Par exemple, le type exact de bus et les protocoles varient considérablement selon les fabricants, et même entre les différents modèles de véhicule de la même marque. Il est nécessaire de trouver un système générique capable d’interagir avec les différents sous-systèmes de capteurs et de communication. Un modèle de communication décrit la manière dont les données sont échangées entre les différentes parties, exemple : peer-to-peer, client-serveur, publish-subscribe… Le choix d’un modèle de communication impactera sur les performances des applications, la facilité à effectuer différentes transactions, la fiabilité des services… Quant à un modèle réseau, il s’agit d’un ensemble de techniques de transmission de données via des réseaux de communication et les protocoles associés. Ainsi, les contraintes de la communication véhiculaire devront nécessairement être prises en compte dans la proposition de schémas de mobilité/handover, de techniques de gestion du flux… Un autre défi à prendre en compte est l’étude de faisabilité des modèles via le prototypage. En effet, dans la littérature, la majorité des travaux se limitent à de nouvelles propositions théoriques et ne prennent pas en compte les problèmes d’implémentation. En fait, la faisabilité de la mise en œuvre des communications V2X et ses défis restent une question de recherche pertinente. Dans cette thèse, nous nous proposons de répondre à l’enjeu de l’exploitation du potentiel informatique, de communication et de capture des véhicules pour des fins de Laboratoire Mobile de Nouvelle Génération. Ainsi, le premier objectif est de proposer des modèles de LM qui permettront d’exploiter de façon optimale les données de capteurs. Le but est d’étendre les services des véhicules connectés vers des applications liées à l’environnement, au climat, à l’agrométéorologie, à la santé, à la vidéosurveillance… Le second objectif est de proposer des modèles réseaux répondant aux exigences des modèles de communications qui seront proposés. Cela requiert la proposition d’algorithmes capables de fournir à l’ordinateur de bord et aux infrastructures de la route toute l’intelligence nécessaire pour prendre la meilleure décision quant à l’utilisation des ressources réseau et le maintien d’une Introduction 7 bonne connectivité. Cela pourrait se faire grâce un hyperviseur1 de passerelles/interfaces sans fil. Un hyperviseur permet d’avoir une vue globale du réseau, une connaissance des modèles de communication employés, et enfin avoir un contrôle sur l’ensemble des interfaces de communication du véhicule. 

Table des matières

INTRODUCTION
1. GENESE DES VEHICULES CONNECTES
2. LABORATOIRE MOBILE DE NOUVELLE GENERATION
3. PROBLEMATIQUE ET CHALLENGES
4. METHODOLOGIE
5. STRUCTURE DE LA THESE ET CONTRIBUTIONS .
CHAPITRE 1 : CONCEPT DE LABORATOIRE MOBILE DE NOUVELLE GENERATION ET COMMUNICATION VEHICULAIRE
1.1. STRUCTURATION D’UN LABORATOIRE MOBILE DE NOUVELLE GENERATION
1.1.1. Variété de capteurs pour le LM
1.1.1.1. Mesure de grandeurs environnementales
1.1.1.2. Les systèmes de perception : état trafic et vidéosurveillance
1.1.2. Sémantique des capteurs
1.1.2.1. Contexte et propriétés de contexte
1.1.2.2. Modélisation des données de capteurs avec l’ontologie SSN
1.1.3. Réseau intravéhiculaire
1.1.3.1. Communication à base de bus
1.1.3.2. Ethernet pour l’automobile
1.2. INTRODUCTION A LA COMMUNICATION VEHICULAIRE
1.2.1. Caractéristiques de communication
1.2.2. Modèle de mobilité
1.2.2.1. Facteurs d’influences de la mobilité
1.2.2.2. Méthodes de prédiction de trajectoire
1.3. VEHICULAR AD HOC NETWORK
1.3.1. Architecture des VANET
1.3.1.1. Les principaux composants
1.3.1.2. Architecture de communication
1.3.2. Protocoles de routage
1.3.3. Classification des applications des VANET
1.3.4. Standards de communication
1.4. RESEAUX DE CAPTEURS VEHICULAIRES
1.4.1. Concept
1.4.2. Méthodes de dissémination et d’agrégation de données
1.4.2.1. Dissémination de données
1.4.2.2. Agrégation de données
1.4.3. Applications
1.5. INTERNET DES VEHICULES
1.5.1. Concept
1.5.2. Véhicule connecté
1.5.2.1. Véhicule intelligent
1.5.2.2. Communication V2X
1.5.2.3. Principaux défis
1.5.3. IoV et Cloud Computing
1.5.3.1. Modèles Cloud pour l’IoV
1.5.3.2. Sensing as a Service : S2aaS
1.5.3.3. Du Cloud Computing au Fog Computing
1.6. CONCLUSION
CHAPITRE 2 : GESTION DE LA MOBILITE ET DU FLUX DANS LE CONTEXTE DES RESEAUX VEHICULAIRES
2.1. LA MOBILITE DANS LE CONTEXTE DES RESEAUX VEHICULAIRES
2.1.1. Mobilité et communication V2I
2.1.2. Mobilité et communication V2V
2.2. SCHEMAS DE HANDOVER BASES SUR LE STANDARD 802.P
2.2.1. Revue des schémas de handover pour le standard 802.p
2.2.2. Discussion sur les schémas de handover 802.p/WAVE
2.3. SCHEMAS DE MOBILITE BASES SUR IP POUR LES RESEAUX VEHICULAIRES
2.3.1. Le protocole IPv6 dans WAVE
2.3.2. Revue des schémas de mobilité IP pour WAVE
2.3.2.1. Véhicule considéré comme un terminal
2.3.2.2. Véhicule considéré comme un réseau mobile
2.3.3. Discussion sur la solution IP pour WAVE
2.4. SCHEMAS DE MOBILITE BASES SUR HIP
2.4.1. Présentation du protocole HIP
2.4.1.1. Un nouvel espace de nom
2.4.1.2. Une nouvelle couche de protocole
2.4.1.3. HIP Base Exchange
2.4.1.4. L’extension RVS
2.4.2. La mobilité dans HIP
2.4.3. Revue des schémas de mobilité HIP pour WAVE
2.4.4. Discussion sur la solution HIP pour WAVE
2.5. SCHEMAS DE MOBILITE ET D’OPTIMISATION RESEAU BASES SUR LE SDN
2.5.1. Software-Defined Networking
2.5.1.1. Architecture SDN
2.5.1.2. OpenFlow
2.5.2. Revue des architectures SDN pour les réseaux véhiculaires
2.5.2.1. Idée de base : Software-Defined VANET
2.5.2.2. Architecture distribuée grâce au Fog Computiing
2.5.2.3. Algorithmes d’optimisation du trafic
2.5.2.4. Schémas de routage
2.6. CONCLUSION
CHAPITRE 3 : PROPOSITION D’UN MODELE DE LM A BASE D’UN VEHICULE VU COMME UN TERMINAL COMMUNICANT SIMPLE
3.1. MODELE DE TERMINAL COMMUNICANT MOBILE
3.1.1. Caractéristiques et défis des Laboratoires Mobiles
3.1.2. Proposition de modèle de Laboratoire Mobile
3.2. ARCHITECTURE DE COMMUNICATION BASEE SUR HIP
3.2.1. Description de l’architecture du domaine
3.2.2. Authentification et droit d’accès
3.3. SCHEMA DE MOBILITE PROPOSE : HIPDISSAS
3.3.1. Présentation de schéma HIPDISASS
3.3.1.1. Description globale
3.3.1.2. HIPDISASS et la micromobilité
3.3.1.3. HIPDISASS et la macromobilité
3.3.1.4. Transport des paquets HIPDISASS
3.3.2. Evaluation analytique de la latence du handover
3.3.2.1. Cas de la micromobilité
3.3.2.2. Cas de la macromobilité
3.4. RESULTATS EXPERIMENTAUX
3.4.1. Tests de performance du protocole HIP
3.4.2. Tests de performance des schémas de mobilité proposés
3.4.3. Evaluation du HIPDISASS
3.5. CONCLUSION
CHAPITRE 4 : PROPOSITION D’UN MODELE DE LM A BASE D’UN VEHICULE VU COMME UNE PLATEFORME COMMUNICANTE INTELLIGENTE .
4.1. MODELE DE RESEAU DE CAPTEURS VEHICULAIRE INTELLIGENT
4.1.1. Modèle fonctionnel du IVSN
4.1.2. Pistes d’implémentation
4.1.3. Application: Sensing as a Service (S2aaS)
4.2. MODELE SENSING AS A SERVICE : PREMIERE PROPOSITION
4.2.1. Modèle fonctionnel
4.2.2. Modèle formel
4.2.3. Optimisations réseau
4.2.3.1. Méthode 1 : évitement des pertes de paquets
4.2.3.2. Méthode 2 : mise en cache des données de capture
4.2.3.3. Méthode 3 : capteurs zombies
4.2.3.4. Méthode 4 : méthode1 + méthode3
4.2.4. Etude de performance des méthodes d’optimisation proposées
4.2.4.1. Description de la simulation
4.2.4.2. Résultats et discussion
4.2.5. Analyse qualitative
4.3. MODELE SENSING AS A SERVICE : SECONDE PROPOSITION .
4.3.1. Modèle fonctionnel
4.3.2. Modèle formel
4.3.3. Optimisation réseaux
4.3.3.1. Réduction de la charge réseau : mise en cache de données
4.3.3.2. Réduction de la charge réseau : prise de décision distribuée
4.3.3.3. Réduction de la latence : prise de décision distribuée
4.3.4. Analyse qualitative
4.4. EXEMPLE D’APPLICATION PRATIQUE DU S2AAS
4.4.1. Principe de fonctionnement du service DBAQ-Routing
4.4.2. Simulation d’un cas d’utilisation
4.5. GUIDE D’IMPLEMENTATION SUR ANDROID AUTOMOTIVE
4.5.1. Architecture d’Android Automotive
4.5.2. Proposition d’extensions sur l’architecture d’Android Automotive
4.5.2.1. L’API CarSensorManagerS2aaS
4.5.2.2. 2aaS App
4.6. CONCLUSION
CHAPITRE 5 : PROTOTYPAGE D’UN RESEAU SDN VEHICULAIRE
5.1. PROPOSITION D’UNE ARCHITECTURE RESEAU VEHICULAIRE SDN
5.1.1. Description de l’architecture
5.1.1.1. La couche fog
5.1.1.2. Le backbone SDN
5.1.1.3. La couche des contrôleurs
5.1.2. Stratégie d’association flux/interface
5.1.3. Détails du prototypage du réseau SDN
5.1.3.1. Déploiement du SDNBACKBONE
5.1.3.2. Déploiement du SDNRAN
5.1.3.3. Déploiement du SDNVANET
5.2. SCHEMAS DE ROUTAGE DU SDNBACKBONE
5.2.1. Description des schémas de routage
5.2.1.1. Routage basé sur le nombre de sauts (weight=hop)
5.2.1.2. Routage basé sur la bande passante libre (weight=bw)
5.2.1.3. Routage basé sur la latence (weight=lat)
5.2.2. Proposition de fonctionnalités additionnelles pour PureSDN
5.2.2.1. Proposition d’une fonction de commutation
5.2.2.2. Proposition d’une fonction de diffusion des paquets DHCP
5.2.3. Evaluation des performances
5.2.3.1. Détails des expérimentations
5.2.3.2. Résultats et discussion
5.3. SCHEMAS DE MOBILITE DU SDNRAN
5.3.1. Mobilité gérée par le Contrôleur SDNRAN
5.3.1.1. Schémas de mobilité réactifs
5.3.1.2. Schéma de mobilité proactif
5.3.2. Mobilité gérée par l’hyperviseur de passerelles/interfaces sans fil
5.3.3. Evaluation des performances des schémas de mobilité
5.3.3.1. Détails des expérimentations
5.3.3.2. Performance des schémas de mobilité gérés par le SDNRAN
5.3.3.3. Performance du schéma de mobilité géré par l’hyperviseur
5.4. SCHEMAS DE ROUTAGE DU SDNVANET
5.4.1. Geocast (V2V)
5.4.2. Routage unicast (V2I)
5.4.3. Evaluation de performances des schémas de routage V2V et V2I
5.4.3.1. Description de la simulation
5.4.3.2. Taux de délivrance de paquets
5.4.3.3. Charge réseau due au routage
5.5. CONCLUSION
CONCLUSION GENERALE
REFERENCES
ANNEXES

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *