développement et démonstration de services destinés...

50
Rapport de stage de fin d’étude (TN10) Étudiant : Mathieu MAX Semestre : GI06, Génie Informatique Suiveur U.T.C. : Bertrand Ducourthial Filière : SRI, Systèmes et Réseaux Informatiques Développement et démonstration de services destinés aux réseaux de véhicules Entreprise : France Télécom Recherche & Développement Lieu : Site d’Orange Labs à Lannion (22) Maître de stage : Sidi-Mohammed Senouci

Upload: phungliem

Post on 11-Sep-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

Rapport de stage de fin d’étude (TN10) Étudiant : Mathieu MAX Semestre : GI06, Génie Informatique Suiveur U.T.C. : Bertrand Ducourthial Filière : SRI, Systèmes et Réseaux Informatiques

Développement et démonstration de services destinés aux réseaux de véhicules

Entreprise : France Télécom Recherche & Développement Lieu : Site d’Orange Labs à Lannion (22) Maître de stage : Sidi-Mohammed Senouci

Page 2: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

2/50

Remerciements

Je tiens à remercier tout particulièrement toutes les personnes qui m'ont accompagné durant ce stage de fin d’étude :

♦ Sidi-Mohammed SENOUCI, mon maître de stage, pour m’avoir accueilli au sein de France Télécom R&D, pour son amabilité et l’intérêt porté au travail accompli ;

♦ Mohamed Oussama Cherif, doctorant à France Télécom R&D et chef du projet relatif

au stage, pour sa sympathie et toute l’assistance dont il a fait preuve ;

♦ Bertrand Durcourthial, mon suiveur U.T.C. et responsable du projet Airplug, pour son aide et sa disponibilité tout au long du stage ;

♦ Sofiane Khalfallah, doctorant à l’U.T.C., pour sa convivialité et pour sa contribution

au stage avec Airplug/NS ;

♦ Anthony Buisset, stagiaire à l’U.T.C. auprès de Bertrand Durcouthial, pour sa sollicitude et l’aide apportée à notre projet ;

♦ Toutes les autres personnes rencontrées à France Télécom : ingénieurs, employés

administratifs, doctorants et autres stagiaires comme moi.

Page 3: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

3/50

Sommaire Remerciements ........................................................................................................................... 2

Sommaire ................................................................................................................................... 3

Résumé technique ...................................................................................................................... 5

Introduction ................................................................................................................................ 6

I. Présentation de l’entreprise ................................................................................................. 6

1. Le groupe France Télécom .............................................................................................. 6

2. La division Recherche & Développement ...................................................................... 7

3. Le laboratoire CORE/M2I ............................................................................................... 8

4. L’unité de recherche et développement R2A .................................................................. 8

5. Le projet VANET ............................................................................................................ 8

II. Présentation du stage ........................................................................................................... 9

1. Contexte .......................................................................................................................... 9

a. Les réseaux de véhicules ............................................................................................. 9

b. Les différentes sortes d’applications prévues ............................................................ 10

c. Les problèmes à résoudre .......................................................................................... 10

2. Objectif .......................................................................................................................... 11

3. Calendrier de travail ...................................................................................................... 12

III. Description des services envisagés ............................................................................... 14

1. Conditions sur le choix d’un service ............................................................................. 14

2. Quelques idées de services… ........................................................................................ 14

3. Services effectivement envisagés .................................................................................. 15

a. Diffusion d’informations locales ............................................................................... 15

b. Transport partagé ....................................................................................................... 17

4. Choix d’un service et pré-requis ................................................................................... 20

IV. État de l’art sur la diffusion optimisée dans les réseaux de véhicules .......................... 21

1. Problématiques de la diffusion dans les réseaux véhiculaires ....................................... 21

2. Diffusion de messages normaux (non critiques) ........................................................... 22

3. Diffusion de messages d’urgence .................................................................................. 28

V. Proposition d’un nouveau protocole de diffusion ............................................................. 35

1. La plate-forme de communications inter-véhiculaires : AIRPLUG ............................. 35

Page 4: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

4/50

a. Les raisons du choix de la plate-forme d’implémentation ........................................ 35

b. L’architecture de la suite logicielle Airplug .............................................................. 35

2. Description du protocole ............................................................................................... 37

a. Présentation et description sommaire ........................................................................ 37

b. Fonctionnement détaillé de l’algorithme ................................................................... 38

c. Quelques exemples de fonctionnement ..................................................................... 39

d. Diagramme de représentation de l’algorithme .......................................................... 40

3. Discussion de la solution proposée ............................................................................... 41

VI. Simulation du protocole développé ............................................................................... 42

1. De l’intérêt de simuler ................................................................................................... 42

2. Le simulateur NS-2 (Network Simulator v2) ................................................................ 42

3. Le modèle de mobilité utilisé ........................................................................................ 43

4. Les métriques de performance retenues ........................................................................ 43

5. Résultats des simulations .............................................................................................. 44

a. Taux de diffusion en fonction de la vitesse ............................................................... 44

b. Taux de diffusion en fonction du temps .................................................................... 45

c. Taux de diffusion en fonction de la densité ............................................................... 45

d. Taux de non réémission à la réception d’un message ............................................... 46

e. Analyse des résultats ................................................................................................. 46

VII. Service de diffusion d’annonces ................................................................................... 48

Conclusion ................................................................................................................................ 49

Bibliographie ............................................................................................................................ 50

Page 5: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

5/50

Résumé technique

Depuis plusieurs années, les communications inter-véhiculaires présentent un intérêt croissant pour de nombreux acteurs, dont les opérateurs de télécommunication. C'est que les réseaux de véhicules ad hoc laissent entrevoir de prometteuses perspectives quant au développement d'applications et de services divers, en dehors de ceux liés à la sécurité routière. En raison des problèmes inhérents à la nature dynamique de ces réseaux, la disponibilité d'un service de diffusion revêt une grande importance pour nombre d'applications. La diffusion d’annonces, service qui a été réalisé au cours du stage, repose essentiellement sur l’existence d’un protocole de diffusion efficace pour être fonctionnel. Un service de diffusion a donc été réalisé, impliquant une réflexion sur des problématiques comme la rapidité et la fiabilité de la propagation multi-saut, l'optimisation de l'usage des ressources, la maximisation du taux de véhicules atteints dans un contexte où ceux-ci ne sont peut-être pas encore tous dotés d'un moyen de communication... Le simulateur de réseau NS-2 a permis d'évaluer les performances de la solution développée, avant de faire des tests sur route en conditions réelles.

Page 6: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

6/50

Introduction En l’espace d’un demi-siècle, le développement des technologies de communication s’est considérablement accéléré au point même que les télécommunications sont aujourd’hui omniprésentes dans notre quotidien. Pour permettre aux individus de communiquer toujours plus librement, à tout instant, et à distance, les communications sans fils ont ainsi pénétré au cœur de notre vie avec la téléphonie mobile 3G ou encore l’accès à Internet haut-débit via le Wi-Fi. Certains prédisent un futur dans lequel tous les objets qui nous entourent seront capables de communiquer entre eux et de se connecter à Internet. Tout comme les réseaux d’ordinateurs avant eux, les réseaux de véhicules actuellement à l’étude apparaissent comme une nouvelle étape majeure dans cette évolution. Les perspectives en matière d’amélioration de la sécurité, de meilleure efficacité des transports et de nouveaux services sont importantes.

Ce stage s’intéresse au développement de services pour les réseaux de véhicules, et ce rapport présente le travail effectué. La section I commence par présenter le groupe France Télécom ainsi que le service dans lequel s’est déroulé le stage, ce dernier et son contexte étant présentés plus en détail dans la section II. La section III présente les services envisagés pour un développement éventuel. La section IV dresse un état de l’art de la diffusion optimisée dans les réseaux de véhicules. La section V détaille un protocole de diffusion développé (pour servir de base à de futurs services), dont les performances sont évaluées dans la section VI consacrée aux simulations. Enfin, la section VII présente brièvement le service de diffusion d’annonces pour lequel tout cela a été fait.

***

I. Présentation de l’entreprise

1. Le groupe France Télécom

Historiquement, France Télécom est une entreprise issue de près d’un siècle de développement des télécommunications en France. Le nom apparaît pour la première fois le 1er janvier 1988, lorsque la Direction Générale des Télécommunications (DGT) adopte le nom « France Télécom ». Le changement de statut de cette administration s’est poursuivi de façon progressive jusqu’à sa transformation en société anonyme dans le courant des années 1990. Par la suite, la nouvelle entreprise a procédé de nombreuses acquisitions (et de cessions de temps à autre) dont Orange plc au début des années 2000 qui a été regroupée avec d’autres activités de l’entreprise pour former la filiale Orange.

Page 7: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

7/50

Aujourd’hui, le groupe est un des principaux opérateurs de télécommunications dans

le monde. Il sert 186 millions de clients dans 30 pays au 30 juin 2009, dont plus de deux tiers sous la marque Orange, et a réalisé un chiffre d'affaires de 53,5 milliards d'euros en 2008. Il compte 125,5 millions de clients de téléphonie mobile partout dans le monde et 13,4 millions de clients ADSL en Europe. Il emploie entre 100 000 et 200 000 personnes dans le monde. Orange est devenue la marque unique du groupe pour l’Internet, la télévision et la téléphonie tandis qu’Orange Business Services est apparue en 2006 spécifiquement pour les offres de produits et services aux entreprises et aux administrations publiques.

L'achèvement du plan NExT (Nouvelle Expérience des Télécoms) qui a couvert les années 2006 à 2008 confirme la réussite de la profonde transformation entreprise par France Télécom-Orange. Ce plan visait entre autres à faire de France Télécom un opérateur de référence en matière de télécommunications sur un plan international et assainir la situation financière du groupe, à réaliser la convergence des services (téléphonie fixe et mobile, Internet, TV par ADSL, etc.) pour unifier l’offre au client, et à faire d’Orange la marque unique du groupe (qui se souvient encore de Wanadoo ?).

Le nouveau plan Orange 2012 confirme la validité de la stratégie menée et adapte les modes d'action pour atteindre un objectif financier ambitieux en matière de flux de trésorerie généré par ses activités. Les actions mises en œuvre dans ce cadre s'organisent autour de trois grands axes : simplifier la vie de ses clients, développer l’agilité du groupe dans l’exercice de ses métiers et inscrire la performance dans la durée. Le plan devrait s’accompagner d’un niveau d’investissement soutenu, d’environ 12% du chiffre d’affaire.

2. La division Recherche & Développement

Les centres de R&D, qui ont pris le nom d’Orange Labs en 2006, constituent le réseau mondial d’innovation du groupe France Télécom-Orange. Ils ne regroupent pas moins de 5000 collaborateurs (chercheurs, ingénieurs, commerciaux). Chacun de ces centres est intégré à son environnement local afin d’anticiper les avancées technologiques et l’évolution des usages partout dans le monde et de délivrer des produits et services simples à utiliser au bon moment et dans le bon pays. La R&D, répartie sur quatre continents, est ainsi la source principale d’innovation pour le groupe avec plus de 8500 brevets à son actif. Ses missions principales sont :

• de développer de nouveaux produits et services de qualité pour le groupe, • de dégager de nouvelles sources de croissance à fort potentiel, • d’anticiper les révolutions techniques et d’usage partout dans le monde, • d’imaginer dès maintenant les solutions du futur, en anticipant les enjeux à long terme.

Page 8: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

8/50

3. Le laboratoire CORE/M2I

« Multimedia networks for non-conversational fixed/mobile services : Image, Internet » (M2I) : dirigé par Xavier Hatrisse, a pour mission d’étudier, pour les réseaux fixes et mobiles, l’ingénierie des services non conversationnels : accès à Internet et services de diffusion de l’image. Il définit, sélectionne, évalue, valide et participe à l’intégration des équipements réseaux nécessaires à ces services. Le laboratoire met en œuvre des compétences sur les équipements et architectures des réseaux de collecte fixe et mobile, de commande de ressources (plates-formes de commande et sondes applicatives) et d’authentification comptage (chaîne RADIUS et ses extensions, plates-formes de facturation à l’acte, traitement du nomadisme dans le réseau). Il apporte une expertise aux entités du groupe France Télécom afin de leur permettre de réaliser les évolutions des réseaux et des services de collecte dans un souci de qualité, sécurité et d’optimisation des investissements, charges et chiffre d’affaires.

4. L’unité de recherche et développement R2A

L'Unité de Recherche et Développement (URD) R2A, partie du laboratoire M2I, dirigé par Yvon Gourhant a pour thème les « Réseaux Adaptables, traitements Applicatifs et réseaux spontanés » (R2A) qui regroupe les réseaux auto-organisés tels que les réseaux pair à pair et multi-sauts. L'URD développe, évalue et intègre les technologies des réseaux adaptatifs (routeurs logiciel, réseaux actifs et programmables). De plus, elle se concentre sur les réseaux ad hoc et réseaux de véhicules: amélioration des protocoles de routage, qualité de service, plateforme de tests et implémentations.

5. Le projet VANET

Le projet VANET est rattaché au laboratoire M2I et a pour objectif d’étudier la complémentarité des réseaux de véhicules par rapport au réseau 3G de l’opérateur. Il y a neuf contributeurs dans le projet et qui font partie de différentes équipes à France Telecom R&D : Lannion, Issy-les-Moulineaux, Pologne et Tokyo.

Page 9: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

9/50

II. Présentation du stage

1. Contexte

a. Les réseaux de véhicules

Depuis plusieurs années, les communications inter-véhiculaires (I.V.C.) présentent un intérêt croissant pour de nombreux acteurs tels que les centres de recherche scientifique et les constructeurs automobiles mais aussi les opérateurs de télécommunication à l’instar de France Télécom. En effet, l’émergence des technologies de réseaux sans fils comme la téléphonie mobile ou le Wi-Fi et les travaux d’étude sur les réseaux dynamiques ont fait apparaître le concept des réseaux de véhicules comme un domaine d’application potentiellement très prometteur. En dotant les véhicules mais également les infrastructures routières et urbaines de moyens de communication, les nouveaux réseaux ainsi créés pourraient alors permettre le déploiement de nombreuses applications et de services divers, appelés systèmes de transport intelligents (I.T.S.). Selon le type des communications mises en œuvre dans le cadre d’un service, plusieurs configurations peuvent être distinguées :

• Communications de véhicule à véhicule (V2V) : dans ce cas, le réseau de véhicules est un cas particulier de réseau dynamique où la mobilité des nœuds est restreinte car elle doit se conformer au plan de l’infrastructure routière, ce qui peut être mis à profit pour améliorer le fonctionnement d’un service.

• Communications de véhicule à infrastructure (V2I) : dans ce cas, les véhicules communiquent avec des unités d’infrastructures fixes qui peuvent être les panneaux routiers, des bornes implantées le long des routes, etc.

• Communications hybrides : ce dernier cas consiste en l’utilisation conjointe des deux types de communication évoqués précédemment ; il est très intéressant car il permet par exemple d’étendre la portée limitée des unités d’infrastructures en se servant des véhicules comme des relais, évitant ainsi la multiplication coûteuse de ces unités.

De nombreuses études de faisabilité ont déjà été réalisées afin de déterminer si une norme quelconque de la suite actuelle des normes IEEE 802.11, initialement conçues pour des réseaux d’ordinateurs sans mobilité, pouvait être utilisée de manière efficace en mode ad hoc sur les réseaux de véhicules. Les résultats sont plutôt concluants et une future norme 802.11p spécifiquement conçue pour ces réseaux doit voir le jour après 2010. Une plage de fréquences radio a déjà officiellement été attribuée par les autorités pour ces nouvelles communications.

Figure 1: Types de communications inter-véhicules

Page 10: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

10/50

b. Les différentes sortes d’applications prévues

Les applications envisagées sur les réseaux de véhicules sont diverses et peuvent être regroupées et classées selon les objectifs par rapport auxquels elles sont conçues :

• Les applications de sécurité routière : elles ont pour but d’améliorer la sécurité routière pour réduire le nombre d’accidents et de morts sur les routes (alertes en cas d’accident ou de conditions de circulation dangereuses telles que : ralentissement ponctuel, embouteillage, travaux, intempéries, etc., système de prévention des collisions, assistance lors de manœuvres délicates comme les dépassements, etc.).

• Les applications de gestion du trafic routier : elles ont pour but d’optimiser l’usage de du réseau routier pour en améliorer la gestion (transport de marchandises, gestion intelligente des carrefours, orientation du flux de véhicules pour éviter la formation de bouchons, meilleure gestion des autoroutes, etc.).

• Les applications de confort sur la route : celles-ci ont pour objectif de rendre l’usage de la route plus facile, plus agréable et moins monotone pour les conducteurs mais également leurs passagers (systèmes de navigation routière, estimation des temps de trajet, divertissement à bord via des applications distribuées, obtention d’informations sur les services locaux, suivi de véhicules, etc.).

Il est utile de remarquer que selon le type d’application considérée, les besoins peuvent ne pas être les mêmes. Par exemple, la propagation d’un message d’urgence doit être quelque chose de rapide, alors que ce n’est pas nécessaire pour la propagation d’un message publicitaire, ce dernier cas pouvant par contre nécessiter de consommer davantage de bande passante.

Cette liste n’est bien sûr pas exhaustive et peut être affinée mais elle donne une idée de l’intérêt que peuvent représenter les réseaux de véhicules. D’ailleurs, les applications ayant rapport à la sécurité routière et, dans une moindre mesure, à la gestion du trafic routier, sont celles qui intéressent le plus les États et les incitent à aller dans le sens du développement de ces réseaux. Les projets concernant les réseaux de véhicules et le développement d’applications sont très nombreux (voir la bibliographie en fin de rapport).

c. Les problèmes à résoudre

Les réseaux de véhicules sont des réseaux dynamiques au sein desquels la mobilité est très forte en raison de la vitesse des véhicules. Il en résulte des changements de topologie très fréquents du fait que des véhicules entrent ou sortent du réseau continuellement, ou plus simplement en raison des changements de position des véhicules les uns par rapport aux autres. Ceci entraîne une connectivité partielle ou intermittente entre les véhicules du réseau qui ne va pas sans poser de nombreux problèmes. Le phénomène de partitionnement (ou fragmentation) du réseau peut fréquemment apparaître, d’autant plus que seule une faible proportion des véhicules seront effectivement équipés d’un moyen de communication lorsque

Page 11: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

11/50

la mise en place de ces réseaux débutera, ce qui oblige tous les acteurs impliqués à réfléchir à une introduction graduelle du marché pour fournir des services fonctionnels malgré cela. Un autre aspect à prendre en compte est que les véhicules communiqueront en utilisant le même canal ; une attention particulière doit donc être portée aux problèmes de collisions qui peuvent survenir dans les environnements à forte densité de circulation.

En raison de leurs propriétés particulières, les réseaux de véhicules présentent donc un certain nombre de problématiques qui sont autant de défis à résoudre pour développer un ensemble de protocoles permettant d’assurer le bon fonctionnement des futurs services :

• Routage des données : les protocoles de routage doivent faire face aux problèmes de connectivité qui sont inévitables. De nouvelles solutions sont donc développées pour mettre en place des protocoles de routage adaptés aux réseaux de véhicules.

• Diffusion : il est nécessaire d’élaborer des protocoles de diffusion adaptés pour pallier les problèmes de connectivité (en ayant recours au multi-saut, par exemple) et de partitionnement, mais aussi pour éviter les problèmes de congestion du canal de communication.

• Auto-organisation : il s’agit de tirer parti des propriétés des réseaux de véhicules (qui sont par nature décentralisés et initialement désorganisés) pour pouvoir en dégager une structure globale relativement stable permettant de déployer des services plus simplement et avec une meilleure efficacité.

• Sécurité des communications : il s’agit là d’un défi très important ; l’absence de toute sécurité dans la suite de protocoles TCP/IP pour les réseaux d’ordinateurs classiques est bien connue, et il convient pour les réseaux véhiculaires d’assurer au contraire une grande sécurité étant donné les domaines d’applications envisagés, ne serait-ce que la sécurité routière.

2. Objectif

L’objectif de ce stage, tel qu’il avait été défini avant mon arrivée à France Télécom R&D, était de développer deux services à déployer sur un réseau de véhicules : un service de covoiturage et un service de parking intelligent. Ces deux services devaient être construits en utilisant une plate-forme de communications inter-véhicules qui avait été développée par un ancien stagiaire. Il était également envisagé que les services en question mettent en œuvre une collecte de données provenant des véhicules du réseau et relayées au sein de celui-ci jusqu’à des sites chargés de traiter les données. Il s’agissait par exemple de propager les informations sur les déplacements prévus des conducteurs pour pouvoir proposer une offre de covoiturage. Au terme du stage, une démonstration réelle à petite échelle avec quelques voitures embarquant des ordinateurs portables munis de cartes Wi-Fi et de récepteurs GPS montrerait le fonctionnement effectif de ces services.

Page 12: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

12/50

En réalité, le sujet précis du stage n’était pas encore parfaitement arrêté et consistait à développer un ou plusieurs services à déployer sur un réseau de véhicules, avec l’objectif d’en faire une petite démonstration réelle en ville qui serait présentée sous forme d’une vidéo. En revanche, les services à développer, la plate-forme de communications inter-véhicules à utiliser et les sous-services pré-requis à mettre éventuellement en place (mécanisme de collecte, de routage, de diffusion, etc.) n’étaient pas définis à mon arrivée et il a donc d’abord fallu étudier ce qu’il allait être possible de faire avant de commencer. Les différentes étapes du stage peuvent donc être résumées ainsi :

1) Identifier quelques services applicatifs utiles pouvant faire l'objet d'une petite démonstration réelle qui ne nécessiterait que peu de moyens, choisir parmi ceux-ci lesquels seraient effectivement développés, déterminer quels pré-requis (sous-services) sont nécessaires à leur développement et rédiger quelques spécifications fonctionnelles sommaires.

2) Choisir une plate-forme de communication inter-véhicules adaptée au développement de services applicatifs et commencer par implémenter les pré-requis nécessaires à la mise en place de ces services.

3) Implémenter les services retenus sur la plate-forme choisie et procéder à un test en conditions réelles avec quelques véhicules et réaliser une petite vidéo de présentation de l’expérience menée.

3. Calendrier de travail

Le stage s’est déroulé sur une durée de six mois allant du 2 février 2009 au 31 juillet 2009, dans les locaux du site de France Télécom R&D situé à Lannion. Voici le calendrier prévisionnel des différentes étapes du stage tel qu’il a été défini au cours de la première semaine de travail :

Étapes principales Février Mars Avril Mai Juin Juillet

Identification de services démontrables

Spécifications fonctionnelles des services retenus

État de l'art sur la diffusion de données

Prise en main d’Airplug

Décision du service à implémenter

Développement des services retenus

Préparation et démonstration réelle sur route

Rédaction du rapport de stage

Page 13: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

13/50

Et voici le calendrier qui présente les différentes phases qui ont effectivement eu lieu et les dates auxquelles elles se sont déroulées. La description précise de ce à quoi correspondent les différentes étapes indiquées sera effectuée tout au long de ce rapport.

Étapes principales Février Mars Avril Mai Juin Juillet

Identification de services démontrables

Spécifications fonctionnelles des services retenus

État de l'art sur la diffusion de données

Prise en main d’Airplug

Décision du service à implémenter

Développement d’un service de diffusion

Simulation du service de diffusion développé

Dév. d’une application de diffusion d’annonces

Tests réels réalisés et filmés à Lannion

Démonstration réelle sur route à Compiègne

Rédaction du rapport de stage

Page 14: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

14/50

III. Description des services envisagés

1. Conditions sur le choix d’un service

Les services qui pourraient être développés pour les réseaux véhiculaires sont a priori très nombreux, mais ils ne peuvent néanmoins pas tous être l’objet d’une démonstration réelle à France Télécom R&D car les moyens sont limités. Il faudrait une organisation rigoureuse, une logistique importante et une vaste zone de circulation pour un test de grande envergure. Or les moyens à disposition ne le permettent pas en raison du faible nombre de personnes disponibles ; de plus, le nombre d’ordinateurs, de cartes 802.11 et de récepteurs GPS n’est pas non plus illimité. Il faut donc tenir compte de cette contrainte dans le choix des services à implémenter en vue d’une démonstration réelle. L’idéal serait de trouver un ou plusieurs services qui pourraient tirer parti des capacités de communications (3G/3G+) du réseau déjà existant de l’opérateur (France Télécom). Il n’y a en effet pas de raison que les moyens de communications des véhicules soient limités au seul Wi-Fi ; ceux-ci peuvent également embarquer des dispositifs de communication radio de type 3G/3G+ ou autre. De plus, le système 3G/3G+ accessible partout peut être utilisé pour pallier le problème du faible taux d’équipement des véhicules lors de l’introduction des réseaux véhiculaires, et il peut également servir pour la mise en place des infrastructures routières communicantes afin d’éviter la construction d’un nouveau réseau pour les systèmes V2I. Dans un tel contexte, les opérateurs de télécommunications apparaissent comme un partenaire indispensable dans l’établissement des réseaux véhiculaires et trouveront dans ceux-ci une extension naturelle de leur propre réseau leur permettant de déployer de nouveaux services sans passer par des investissements coûteux. Néanmoins, il faut veiller à ce que ces nouveaux services n’entrent pas en concurrence avec ceux déjà existants proposés avec le seul réseau de l’opérateur, à moins qu’ils ne permettent une réduction des coûts de fonctionnement.

2. Quelques idées de services… Nous avons envisagé différents services au début du stage, en examinant pour chacun s’il était possible d’en faire une démonstration réelle à petit échelle. Voici par exemple deux de ces services (les autres ne seront pas évoqués pour des raisons de confidentialité) :

� Diffusion d’annonces publicitaires et/ou pratiques locales : des bornes diffusent en permanence des annonces indiquant quels services se trouvent à proximité (parkings, stations-service, restaurants, cinémas, attractions touristiques, etc.) et ces annonces sont propagées via le réseau de véhicules. Ce service ne pose pas de problème particulier de démontrabilité et peut être réalisé avec peu de moyens.

Page 15: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

15/50

� Maintien de la distance de sécurité entre deux véhicules : il s’agit d’un service très simple lié à la sécurité routière et qui pourrait facilement faire l’objet d’une petite démonstration avec quelques véhicules communicants munis de GPS.

3. Services effectivement envisagés

Parmi l’ensemble des services envisagés, deux types de services ont été retenus : l’un concerne la diffusion d’informations locales et l’autre touche au concept de transport partagé. Plusieurs services différents ont été imaginés dans chacun de ces deux cas.

a. Diffusion d’informations locales

L’objectif de ce service est de fournir aux automobilistes et à leurs passagers des informations locales utiles d’ordre pratique et/ou publicitaire dans un environnement semi-urbain. Pour cela, une borne diffuse en permanence une ou plusieurs annonces donnant des informations :

- d'info-trafic renseignant sur les conditions de circulation, - sur les parkings à proximité avec le nombre de places libres restantes, - sur les stations de distribution de carburant alentour (tarifs, horaires d’ouverture, etc.), - sur les hôtels (prix des chambres, promotions spéciales, etc.) - sur les restaurants (compositions des menus, prix, promotions, etc.) - sur les cinémas (tarifs et réductions, films à l’affiche, horaires des séances, etc.) - sur les magasins du centre commercial (promotions, soldes, etc.), - sur les musées et attractions touristiques (horaires d’ouverture, expositions, etc.) - etc.

Pour accroitre la portée limitée de la borne (sans trop s'en éloigner toutefois, car une

information sur un service situé à 100 km ne présente aucun intérêt pour l’automobiliste), les annonces sont relayées au sein du réseau de véhicules, dans la limite d'une certaine distance, par un mécanisme de diffusion adapté. Ceci permet ainsi d'augmenter la zone de couverture de la borne, permettant d’éviter d’en multiplier le nombre à chaque coin de rue.

Le mode d'exploitation de la borne de diffusion permet d'entrevoir deux approches donnant la possibilité d'imaginer des services quelque peu différents. Dans la première approche, une borne est utilisée pour diffuser plusieurs informations qui n’ont pas forcément de liens entre elles, c’est-à-dire indépendantes les unes des autres. Dans ce cas, une ou plusieurs bornes de ce type pourraient être implantées dans une région urbaine de manière à couvrir l’ensemble de la zone.

Page 16: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

16/50

Dans la seconde approche, la borne n'est utilisée que pour diffuser une et une seule information. Elle serait donc exclusivement réservée à un service unique et située à proximité immédiate de celui-ci. Dans ce cas, de nombreuses bornes devraient donc être implantées, disséminées un peu partout dans une région urbaine donnée, chaque service disposant de sa propre borne.

Quelques services que l’on pourrait mettre en œuvre pour en faire une véritable démonstration sont les suivants :

Diffusion d'annonces publicitaires et/ou pratiques : Plutôt fondé sur la première approche, ce service consiste principalement à diffuser des annonces publicitaires. La borne diffuse périodiquement un certain nombre de messages publicitaires concernant les magasins et divers commerces des environs, et ces messages sont relayés via le réseau de véhicules pour être diffusés dans les limites d’une zone de couverture

Figure 2: Une borne de diffusion s'occupe de diffuser plusieurs informations distinctes

Figure 3: Chaque borne de diffusion s'occupe d'une et une seule information

Page 17: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

17/50

centrée sur la borne. Ils sont affichés sur l'écran du conducteur lorsqu'il circule dans à l'intérieur de cette zone. La borne peut être considérée comme une sorte d'espace publicitaire à vendre ; le principe étant le même que celui d'un grand panneau publicitaire implanté sur le bord de la route, à la différence que les véhicules touchés ne sont pas seulement ceux qui passent à côté, mais tous ceux qui se trouvent dans la zone de couverture. Les annonces sont susceptibles d’intéresser toute personne ne connaissant pas bien la région (comme les personnes en déplacement, les touristes, etc.) puisqu'elles permettent d’avoir une vision globale des services que l’on trouve à proximité. Les voitures individuelles ne sont pas les seules à être ciblées par ce service ; les informations diffusées peuvent en effet être affichées à bord des taxis, des transports en communs, etc.

Diffusion d'informations pratiques non commerciales : Ce service est en fait une variante du service précédent sauf qu’il concerne la diffusion d'informations pratiques utiles et non pas commerciales (état du trafic routier, zones de travaux, déviations et itinéraires recommandés, localisation de tous les parkings à proximité, informations touristiques, etc.). Ce service peut néanmoins être fusionné avec le service précédent pour fournir une application plus complète.

Diffusion du nombre de places libres dans les parkings : Plutôt fondé sur la deuxième approche cette fois-ci, ce service est destiné à permettre aux automobilistes qui recherchent une place de stationnement de connaître au fur et à mesure qu'ils approchent d'un parking la disponibilité des places à l'intérieur de celui-ci. Ce genre d’information est parfois affiché de nos jours sur des panneaux de direction, mais le temps d’arriver au parking, la situation peut être totalement différente de ce qu’indiquaient les panneaux. Dans le cas de ce service, une borne de diffusion est implantée près de chaque parking et transmet périodiquement aux véhicules passant à proximité le nombre de places restantes et la position du parking. Cette information est ensuite relayée via le réseau de véhicules pour être diffusée au plus grand nombre de véhicules qui se trouvent dans une zone de couverture centrée sur le parking. Lorsqu'un automobiliste souhaite se garer dans un parking où il reste des places libres, il se dirige vers celui-ci et reçoit ainsi au fur et à mesure qu'il s'approche les différents messages d'information mis à jours diffusés successivement par la borne. Il peut ainsi se faire une idée sur l'évolution du taux de remplissage du parking et prendre une décision si nécessaire pour aller vers un autre parking. Bien sûr, les messages reçus ne sont affichées que s'ils sont pertinents, c'est-à-dire encore récents (moins d'une minute). Les véhicules concernés par ce service sont les voitures individuelles uniquement.

b. Transport partagé

Pour ce genre de service, deux manières d'utiliser le réseau de véhicules sont envisagées pour permettre à des personnes de se déplacer en commun. La première approche est pensée pour fournir un service de déplacement dans l'immédiat en effectuant une

Page 18: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

18/50

recherche localisée d'un moyen de transport n'importe où dans le réseau de véhicules, tandis que la seconde permet d'envisager un déplacement immédiat ou différé en collectant depuis le réseau de véhicules les déplacements effectués par certains automobilistes afin de les mettre à disposition pour consultation dans une base de donnée.

Dans la première approche, un piéton transmet une demande de déplacement directement aux véhicules qui l'entourent en indiquant sa position actuelle et la destination souhaitée. Cette demande est relayée à partir des premiers véhicules qui l'ont reçue pour être diffusée au sein du réseau de véhicules dans une zone plus étendue mais néanmoins limitée et centrée sur la personne. Un véhicule intéressé peut accepter la demande en renvoyant une réponse au piéton.

Dans la deuxième approche, des informations sur des offres de déplacements sont remontées depuis les véhicules vers un serveur centralisé. Les personnes souhaitant trouver une solution de déplacement consultent ensuite la base de données du serveur. Les trois premiers services présentés ci-dessous sont basés sur la première approche mais diffèrent quelque peu dans leur domaine d’application. Les deux premiers services peuvent également s'appliquer aux Autolib's (un projet de service de location horaire de véhicules électriques en libre service reposant sur le même principe que les Vélib's).

Figure 4: Cas d’une demande de transport immédiat

Figure 5: Cas d’un demande de transport différée

Page 19: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

19/50

Avant toute chose, il faut remarquer que les services décrits nécessiteraient l'utilisation d'un protocole de routage qui permette une communication de bout en bout à chaque fois que le piéton et un véhicule donné ont besoin de communiquer directement. Cependant, afin d'éviter l'utilisation d'un protocole de routage pour des raisons de simplicité, une réponse positive d'un véhicule à l'intention du piéton peut simplement être diffusée dans le réseau de véhicules. De cette manière, le piéton reçoit celle-ci et les autres véhicules qui circulent éventuellement dans la zone sont également informés du traitement de la requête du piéton. Taxi partagé : Pour ce service, la demande de déplacement du piéton est en fait une demande de course immédiate par un taxi. Les seuls véhicules destinataires de la requête sont donc les taxis. Lorsqu'un chauffeur de taxi estime qu'il peut venir chercher la personne, il renvoie une réponse qui est routée jusqu'au piéton via le réseau de véhicules. Le piéton confirme ensuite qu'il accepte la proposition en diffusant un message indiquant son choix (ce qui permet d'informer tous les taxis de la zone), toujours via le réseau de véhicules (et pour un taxi donné, le fait de ne pas recevoir une confirmation passé un certain délai implique que le piéton a déjà trouvé un taxi). Covoiturage immédiat : Pour ce service, la demande de déplacement du piéton est considérée comme une demande de « covoiturage immédiat ». Les véhicules ciblés par la requête sont les véhicules individuels. Le principe de fonctionnement est exactement le même que dans le précédent service concernant le taxi partagé (seuls les véhicules ciblés diffèrent). Si un automobiliste accepte la demande, il renvoie une réponse au piéton via le réseau de véhicules. Le piéton confirme qu'il accepte la proposition en diffusant son choix, toujours via le réseau de véhicules ou par téléphone. La demande de covoiturage est renouvelée un certain nombre de fois tant que le piéton n'a pas mis fin à l'application. Remarque : il s'agirait plutôt d'un service à déployer dans une zone à forte densité de circulation (comme un centre d’affaires, un centre ville, etc.) où de nombreux véhicules doivent être équipés d'un moyen de communication inter-véhiculaire (sinon le piéton n'a que peu de chances d’obtenir une réponse). Transport multi-modal : Ce service se propose d'englober et d'étendre les deux premiers services évoqués ci-dessus (taxi partagé et covoiturage immédiat). La demande de déplacement émise par le piéton contient des critères précis (destination, temps d'attente, prix, etc.) et touche tout type de véhicule (taxi, véhicule individuel, bus, tramway, Autolib's, etc.).

Page 20: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

20/50

Enfin, ce quatrième service est quant à lui basé sur la deuxième approche : Taxi partagé : Les taxis d'un secteur font remonter les différentes courses prévues via le réseau de véhicules jusqu'à un serveur central qui alimente une base de données journalière ou hebdomadaire, permettant à des personnes de consulter les courses à venir et éventuellement de s'y joindre.

4. Choix d’un service et pré-requis

Après avoir étudié quels services il pourrait être intéressant de développer et d’en faire une démonstration réelle, le choix s’est finalement porté sur le service de diffusion d’annonces d’ordre publicitaire et/ou pratique car celui-ci était déjà pressenti dès le début du stage et intéressait l’ensemble des partenaires du projet. Cependant, pour pouvoir mettre en œuvre un tel service, il faut commencer par développer un sous-service de diffusion sur lequel le service de diffusion d’annonces pourra s’appuyer. En d’autres termes, il faut d’abord mettre au point un mécanisme de diffusion qui serait utilisé comme une couche à part entière dans une pile protocolaire adaptée aux réseaux de véhicules.

Avant de procéder au développement de ce mécanisme de diffusion, il a fallu commencer par établir un état de l’art sur la diffusion optimisée dans les réseaux de véhicules : c’est le sujet abordé dans la partie suivante.

Figure 6: Nécessité d'un service de diffusion sous-jacent pour les applications

Page 21: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

21/50

IV. État de l’art sur la diffusion optimisée dans les réseaux de véhicules

1. Problématiques de la diffusion dans les réseaux véhiculaires

Pour les réseaux de véhicules, la disponibilité d'un service de diffusion est d’une grande importance pour de nombreuses applications. Il s’agit de pouvoir transmettre depuis une source donnée un même message au plus grand nombre de véhicules situés dans une zone. Les propriétés particulières des réseaux de véhicules nécessitent de concevoir des protocoles de diffusion spécifiques, adaptés à ce milieu. Comme les réseaux de véhicules fonctionnent en mode ad hoc et que la portée du moyen de communication utilisé est limitée, il faut le plus souvent avoir recours à des stratégies de diffusion multi-saut, en utilisant les véhicules pour relayer l’information afin de satisfaire la portée désirée de la diffusion. La diffusion est un phénomène localisé : les messages diffusés ont une importance relative à la zone depuis laquelle ils sont émis. Plus le message s’éloigne de son point d’origine, moins il revêt d’importance pour les véhicules qui le reçoivent. La diffusion est également un phénomène temporel : le message perd de son importance au fur et à mesure que le temps passé depuis son émission augmente. Les protocoles de diffusion s’attachent donc à limiter la propagation du message dans l’espace et dans le temps. En raison des propriétés des réseaux de véhicules énoncées dans la partie II.1.c, les protocoles de diffusion sont confrontés à de nombreux problèmes. L’inondation est la méthode de diffusion la plus simple car elle consiste à faire en sorte que chaque véhicule qui reçoit le message le retransmette une fois à la première réception. Cependant, elle cause inutilement une consommation excessive de bande passante, et chaque véhicule va recevoir le même message de nombreuses fois. Il en résulte une situation où le nombre de collisions est très élevé, ce qui finalement ne favorise pas la diffusion du message. Ce problème est connu sous le nom de la « tempête de diffusion » (the broadcast storm problem). Les protocoles de diffusion doivent donc faire attention à optimiser l’usage des ressources. De plus, et malgré les problèmes liés à la nature dynamique du réseau, ils doivent s’efforcer de garantir au mieux la rapidité et la fiabilité de la propagation du message, afin de maximiser le taux de véhicules atteints. Le phénomène de partitionnement du réseau est un obstacle également car il rompt la chaîne de sauts du message ; certains protocoles considèrent que tous les véhicules sont dotés d’un moyen de communication tandis que d’autres tiennent compte du fait que le taux d’équipement peut être faible. En parcourant la littérature consacrée aux méthodes de diffusion (hors protocoles de routage) dans les réseaux de véhicules, il est possible de discerner deux types de diffusion dont les contraintes ne sont pas les mêmes : elles concernent d’un côté les messages

Page 22: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

22/50

d’urgences (par exemple émis par des applications liées à la sécurité routière, comme les alertes d’accident, etc.) et de l’autre les messages non critiques (par exemple émis par des applications de divertissement, comme des annonces publicitaires, etc.).

2. Diffusion de messages normaux (non critiques)

A) DDT (Distance Defer Transfert)

La méthode proposée dans l’article [DDT] contient une idée que l’on retrouve dans de nombreux autres protocoles. Cette idée, résumée dans le nom du protocole (« distance defer transfert »), consiste à faire relayer le message à diffuser uniquement par les véhicules les plus éloignés de l'émetteur. Pour ce faire, l'idée de base est que tout véhicule récepteur du message attende d'abord un délai inversement proportionnel à la distance qui le sépare de l'émetteur avant d’effectuer la retransmission. Ainsi, les véhicules plutôt éloignés de l'émetteur retransmettent toujours avant les véhicules plus proches de celui-ci. Ceci permet de diffuser le message le plus rapidement possible. Mais ce n’est pas tout. Comme les véhicules intermédiaires reçoivent le même message plusieurs fois (une fois de l’émetteur initial et une fois de la part du retransmetteur), ils peuvent décider d’annuler leur propre retransmission dans le cas où la zone où ils se situent a déjà été entièrement couverte par la diffusion physique du message. Ceci permet ainsi d’optimiser l’usage des ressources en économisant la bande passante. Une hypothèse implicite de ce protocole est que la vitesse de transmission des messages est très grande devant celle des véhicules, de sorte que la topologie du réseau reste relativement stable durant la phase d'attente.

L’article ne donne pas d’exemple de formule pour déterminer le temps d'attente avant retransmission. Le fonctionnement de l'algorithme de diffusion DDT est le suivant :

1) Un véhicule A émet un message à diffuser à tous ses voisins en indiquant sa position GPS dans l'en-tête du message. 2) Lorsqu'un véhicule B reçoit le message, il calcule un temps d'attente inversement proportionnel à la distance entre A et lui-même. 3) Durant le temps d'attente, le véhicule B enregistre les positions de tous les véhicules qui lui transmettent le même message. 4) À l'expiration du délai, le véhicule B détermine si la plupart de sa propre zone de retransmission a été suffisamment couverte par ses voisins. Si tel est le cas, la retransmission du message serait redondante et est donc abandonnée*. Sinon, B retransmet le message en appliquant le même protocole.

(*) Chaque message à diffuser contient également un identifiant de message ainsi qu'un champ correspondant à une durée d’existence maximale (TTL). Le véhicule B effectue bel et

Page 23: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

23/50

bien la retransmission du message lorsque les trois conditions suivantes sont satisfaites : (a) le TTL est toujours positif, (b) la région non couverte de sa zone de transmission dépasse un certain seuil et (c) B n'a encore jamais reçu ce message auparavant. Le problème de ce protocole est que chaque véhicule ne retransmet le message qu’au plus une seule fois, ce qui le rend peu fiable lorsque le trafic routier est faible ou que le réseau de véhicules est partitionné.

B) TRADE (TRAck DEtection)

L’article [DDT] présente également un second protocole de diffusion. Dans celui-ci, chaque véhicule est censé connaître les positions de tous ses voisins directs (celles-ci peuvent être obtenues, par exemple, grâce à l'échange périodique de messages succincts contenant l'information de position fournie par le GPS) et analyse leurs mouvement pour pouvoir les classer dans différents groupes et choisir un nombre restreint de véhicules parmi ceux-ci pour la retransmission du message. Le choix des véhicules qui vont retransmettre le message est donc ici actif, alors qu’il était passif dans le cas de DDT.

Concrètement, un véhicule A chargé de retransmettre un message choisit d'abord judicieusement lesquels de ces voisins seront ensuite chargés de faire de même à leur tour. Pour cela, le véhicule A classe ses voisins dans différents groupes selon leur direction par rapport à lui. Pour établir ce classement, le protocole prévoit le maintien de trois vecteurs qui sont (pour chaque véhicule B voisin de A) :

1) le vecteur allant de la précédente position de A à sa position actuelle, 2) le vecteur allant de la précédente position de B à sa position actuelle, 3) le vecteur allant de la position actuelle de A à la position actuelle de B

En comparant les angles que font ces différents vecteurs entre eux, le véhicule A est en mesure de déterminer si son voisin B est sur la même route que lui, et si tel est le cas, s'ils circulent dans le même sens ou pas. Le fonctionnement de l'algorithme de diffusion TRADE est alors le suivant :

1) Le véhicule A classe tous ses voisins dans les différents groupes de direction en utilisant les informations de position GPS les plus récentes dont il dispose. 2) A sélectionne ensuite les véhicules les plus éloignés qui circulent sur la même route que lui, ainsi que tous les véhicules qui circulent sur une route différente. 3) Pour retransmettre un message à diffuser, le véhicule A transmet à ses voisins le message avec la liste des véhicules sélectionnés. 4) Lorsqu'un véhicule B reçoit le message à diffuser, il détermine s'il est chargé de le retransmettre à son tour*. Si tel est le cas, il applique le même protocole, sinon, il ne fait rien.

Page 24: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

24/50

(*) Chaque message à diffuser contient également un identifiant de message ainsi qu'un champ correspondant à une durée d’existence maximale (TTL). Le véhicule B effectue bel et bien la retransmission du message lorsque les trois conditions suivantes sont satisfaites : (a) le TTL est toujours positif, (b) son identifiant est présent dans la liste jointe au message et (c) B n'a encore jamais reçu ce message auparavant.

La sélection des voisins peut résulter de différentes stratégies selon les contraintes associées à la diffusion du message : nombre minimal de véhicules à atteindre, usage limité de la bande passante, etc. Le principal inconvénient de ce protocole est l’émission périodique des messages par tous les véhicules, ce qui est assez délicat lors d’un passage à l’échelle.

C) SODAD (Segment-Oriented Data Abstraction and Dissemination)

Les auteurs de [SODAD] donnent une nouvelle méthode présentée comme passable à l'échelle de dissémination d'information dans les réseaux de véhicules. Elle est conçue pour pouvoir assurer une diffusion efficace même si le taux d'équipement des véhicules est faible (moins de 3 %) et est pensée avant tout pour les applications de confort.

L'idée de base du protocole SODAD consiste à construire localement des informations structurées pour les transmettre ensuite de véhicule à véhicule au moyen d'une simple diffusion locale périodique. Il n'y a pas de propagation multi-saut ici : deux véhicules ne s'échangent ces informations que lorsqu'ils passent à proximité l'un de l'autre. La transmission et la réception des messages sont complètement séparées.

1) Construction locale d'une information structurée : Chaque véhicule est supposé disposer d'une carte routière numérique sur laquelle les routes sont divisées en segments de différentes tailles (selon le type de route et le niveau de détail requis par l'application considérée) qui possèdent chacun un identifiant unique. Les véhicules comme les unités d’infrastructure sont susceptibles de générer de l’information à diffuser. Au niveau d’un véhicule circulant sur un segment donné, lors de la réception d’informations nouvelles, une fonction d'agrégation est appliquée aux données reçues et le résultat est marqué avec le numéro du segment ainsi qu'une date globale fournie par le GPS. Cette information structurée ainsi construite et relative à un segment donné peut être appelée « information de segment ».

2) Dissémination des informations : Les informations de segment reçues par un véhicule sont enregistrées dans une base de données. À la réception d'un nouveau message contenant des informations de segment, les précédentes informations de segment stockées sont mises à jour en comparant leurs dates avec celles des informations de segment reçues.

Page 25: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

25/50

Selon la date globale et le segment actuel sur lequel circule le véhicule, l'application sélectionne les informations de segment les plus pertinentes à retransmettre – inutile en effet de donner des informations relatives à un segment trop éloigné ou bien trop anciennes (la base de données doit d'ailleurs être régulièrement mise à jour pour cela).

En résumé, un véhicule qui dispose d’informations de segment utiles effectue une diffusion périodique de celles-ci pour les transmettre aux véhicules capables de les recevoir (équipés d'un moyen de communication inter-véhiculaire) qui à leur tour mettent à jour leurs propres informations de segment et ainsi de suite... Il faut noter que ce sont les applications qui sont responsables de la retransmission régulière des informations qui les concernent. La figure suivante montre que c’est grâce à la diffusion locale périodique que le taux de véhicules atteints par la dissémination est maximal. Le véhicule B parvient à transmettre son message, même au véhicule A trop éloigné de lui, par l'intermédiaire du véhicule C.

Les auteurs donnent également une méthode, appelée la « diffusion adaptative », pour

moduler la période de retransmission. En effet, l'émission périodique d'un message risque de surcharger le réseau de temps à autre si la période de retransmission reste constamment égale à une valeur donnée quelque soit les circonstances. Les auteurs proposent donc de moduler dynamiquement cette période par une approche heuristique afin d'éviter une éventuelle surcharge du réseau. Cette approche consiste tout simplement à augmenter le délai si les informations de segment reçues dans un message sont plutôt anciennes par rapport à celles conservées dans la base de données du véhicule et inversement diminuer le délai si au contraire elles diffèrent peu.

D) UMB (Urban Mutli-Hop Broadcast)

Les auteurs d’[UMB] proposent un protocole conçu pour éviter à la fois les problèmes de tempête de diffusion, de station cachée et de fiabilité quant la propagation multi-saut dans un environnement urbain encombré de bâtiments. Le protocole utilise pour cela une version

Figure 7: Dissémination maximale de l'information dans SODAD

Page 26: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

26/50

modifiée de la couche d'accès IEEE 802.11 adaptée au contexte des réseaux de véhicules. Il comporte deux mécanismes que les auteurs appellent la diffusion directionnelle et la diffusion aux intersections. L'idée du mécanisme du protocole DDT se retrouve dans le premier. Chaque véhicule est supposé embarqué un appareil GPS et une carte routière numérique.

1) La diffusion directionnelle avec le mécanisme RTB/CTB La diffusion directionnelle tient compte du fait que les véhicules circulent seulement selon des axes routiers connus. Pour diffuser un message dans une certaine direction, le véhicule émetteur charge le véhicule le plus éloigné dans cette direction de faire suivre le message. Pour sélectionner ce véhicule, le protocole divise la portion de route couverte par la portée de transmission du véhicule porteur du message en segments de longueurs égales. S'il y a plus d'un véhicule dans le dernier segment dans la direction de diffusion, le processus est réitéré avec une longueur de segment plus courte et ainsi de suite. Si cela s'avère toujours insuffisant après un certain nombre d'itérations, un choix au hasard est opéré entre tous les véhicules du dernier segment. Pour pallier le problème de la station cachée, un mécanisme du type RTS/CTS est appliqué, adapté ici sous le nom RTB/CTB (Request To Broadcast / Clear To Broadcast). Le véhicule porteur du message émet un d'abord paquet RTB. Chaque véhicule récepteur calcule sa distance par rapport à l'émetteur, puis émet un fort signal de brouillage (black-burst) durant un temps discret dont le nombre d'unités temporelles (time slots) est proportionnel à cette distance. À l'issue de cette phase, chaque véhicule écoute le canal de communication : s'il est libre, cela signifie que son brouillage a duré le plus longtemps, donc qu'il est un des plus éloignés de l'émetteur du RTB. Il répond alors en envoyant un paquet CTB. Les autres véhicules moins éloignés ont nécessairement trouvé le canal occupé, et donc se taisent. Si une collision a lieu au niveau du véhicule source, celui-ci en déduit qu'il s'agit de plusieurs CTB envoyés par les différents véhicules situés dans le dernier segment. La procédure est alors réitérée comme cela a déjà été dit. La phase ultime ayant recours au hasard, utilise en fait la même méthode de brouillage entre les derniers véhicules avec des temps de brouillage choisis au hasard. Si le véhicule source reçoit un CTB correctement décodé, il émet le message à faire suivre en indiquant l'identifiant du véhicule qui a émis le CTB. Ce dernier est alors responsable de faire

Figure 8: Le mécanisme RTB/CTB

Page 27: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

27/50

suivre le message dans la direction de diffusion. Avant cela, il doit répondre avec un paquet ACK pour assurer le besoin de fiabilité. Si le véhicule source ne reçoit pas d'ACK, il recommence la procédure d'élection depuis le début.

2) La diffusion aux intersections avec les répéteurs Lorsqu'une intersection se trouve sur le chemin du message diffusé, il faudrait amorcer de nouvelles diffusions directionnelles dans chaque direction possible. Pour cela, un équipement spécial appelé « répéteur » est supposé être mis en place à chaque intersection. De par sa position, un répéteur peut émettre sans problème d'obstacle dans toutes les directions de l'intersection. Lorsqu'un véhicule responsable de la diffusion d'un message arrive à portée d'un répéteur (ce qu'il sait grâce au GPS et à la carte routière numérique), il établit une communication point-à-point classique selon le protocole IEEE 802.11 (avec RTS/CTS) pour transmettre le message au répéteur. Ce dernier lance alors de nouvelles diffusions directionnelles dans toutes les autres directions, et si possible, il transmet également le message aux autres répéteurs qui sont à sa portée. Il est possible qu'un chemin relie plusieurs répéteurs dans une boucle, pouvant causer une diminution de la bande passante disponible lorsqu'un même message traverse plusieurs fois les mêmes segments de route. Pour éviter cela, le protocole utilise un mécanisme de mise en cache des identifiants de message au niveau des répéteurs, qui peuvent alors stopper les rediffusions redondantes.

E) RBM (Role-Based Multicast)

Le protocole proposé dans [RBM] adopte un fonctionnement similaire à celui de DDT mais cherche à corriger le problème de partitionnement des réseaux véhiculaires. Pour chaque message en cours de diffusion, chaque véhicule maintient deux listes distinctes qui sont : a) la liste N de ses voisins directs et b) la liste S des véhicules qui lui ont envoyé le message en question (les véhicules sont supposés être identifiés de façon unique). La mise à jour de la liste N est assurée par un mécanisme de notification (prévenant de l’arrivée ou du départ d’un véhicule dans le voisinage) provenant d’une couche de liaison de données qui maintient en permanence une liste des voisins directs. La mise à jour de la liste S s’effectue quant à elle à chaque nouvelle réception du message. Lorsqu’un véhicule reçoit un nouveau message, si le contenu de ses listes N et S est tel qu’il existe des voisins qui n’ont pas encore envoyé le message (N privé de S est différent de l’ensemble vide), alors le véhicule entre dans une phase « d’attente avant retransmission ». Comme dans DDT, le temps d’attente impliqué est inversement proportionnel à la distance qui le sépare de l’émetteur. Bien sûr, la mise à jour des listes N et S continue pendant le temps d’attente. Si la situation n’a pas changée à l’expiration, le véhicule retransmet le message, sinon (N privé de S est vide, i.e. tous les véhicules voisins ont envoyé le message) il passe

Page 28: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

28/50

dans une phase « d’attente de voisin » : le message sera réémis dès qu’un nouveau voisin surgira dans le voisinage.

F) MDDV (Mobility-Centric Data Dissemination algorithm for Vehicular networks)

Les auteurs de [MDDV] ont conçu une solution pour la dissémination de données qui prend en compte le phénomène de partitionnement. Elle est conçue de manière à tirer parti de la mobilité des véhicules, et combine les notions de diffusion opportuniste, de diffusion basée sur la trajectoire et de diffusion géographique. La méthode proposée est présentée dans le cas où un message doit être acheminé vers une zone géographique donnée alors qu’il est émis en dehors de cette zone. Cette méthode ne requiert pas la connaissance de la position des véhicules dans le processus d’acheminement du message. Le réseau routier est modélisé sous forme d’un graphe orienté dans lequel les segments de route sont représentés par les arcs et les intersections par les nœuds. Chaque arc se voit attribuer un poids permettant de caractériser la rapidité de propagation potentielle du message le long du segment routier correspondant, qui dépend notamment en grande partie de la densité de circulation. Étant donné cette modélisation, le protocole tente d’acheminer le message vers la zone de destination en suivant le chemin dont la somme des poids des arcs est la plus petite possible. Tout ceci implique que chaque véhicule dispose d’une carte routière numérique comportant de telles données. Les véhicules sont supposés avoir connaissance de leurs voisins directs via un quelconque mécanisme intégré dans une couche de la pile protocolaire du réseau véhiculaire. Le message est propagé de véhicule en véhicule le long du chemin déterminé par tout un groupe de véhicules responsables (un seul serait peu fiable) qui évolue au cours du temps. La bonne propagation du message est assurée par des informations stockées dans son en-tête (positions successives du message au cours du temps) nécessaires « pour qu’il aille dans la bonne direction ». La transmission de véhicule en véhicule se fait de manière opportuniste grâce à la connaissance du voisinage.

3. Diffusion de messages d’urgence

La diffusion de message d’urgence est soumise à des contraintes très fortes de rapidité de propagation et de maximisation du taux de véhicules atteints, quitte à occuper toutes les ressources nécessaires au détriment d’autres applications moins importantes. Nous allons exposer ici certaines solutions développées pour ce type de diffusion.

A) MHVB (Multi-Hop Vehicular Broadcast) Ce protocole consiste à inonder une zone géographique avec un message d'urgence tout en veillant à limiter les risques de collision et l'utilisation de la bande passante.

Page 29: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

29/50

Pour cela, la diffusion du message au sein du réseau de véhicules suit une méthode similaire au protocole DDT à la différence que chaque véhicule qui reçoit le message continue par la suite à l'émettre périodiquement tant qu'il n'est pas trop éloigné de son émetteur originel. Les délais d'attente entre les retransmissions sont modulés en fonction de l'environnement (densité véhiculaire, distance à l'émetteur). Lorsqu'un véhicule doit diffuser un message d'urgence, il émet celui-ci périodiquement en indiquant sa position originelle (à la première émission) dans l'en-tête du message. Lorsqu'un autre véhicule reçoit le message à diffuser (après un ou plusieurs sauts), il suit les étapes suivantes :

1) Il enregistre le message reçu dans sa base de données locale. 2) Il calcule la distance qui le sépare de l'émetteur originel (celui qui a envoyé le message pour la première fois). Si cette distance est supérieure à un certain seuil, la procédure s'arrête ici. 3) Il calcule la distance qui le sépare de l'émetteur (celui dont il a reçu le message). 4) Il attend un temps d'attente calculé de telle sorte que les véhicules les plus éloignés de l'émetteur retransmettent le message plus tôt que les véhicules plus proches. 5) S'il reçoit le même message d'un ou plusieurs autres véhicules, il détermine leurs positions relatives par rapport à lui-même, calcule une zone de non-retransmission, et s'il se trouve à l'intérieur de celle-ci, il annule sa propre retransmission. Sinon, il retransmet le message périodiquement.

Étant donné un retransmetteur, la forme de la zone de non-retransmission est la suivante :

Pour améliorer l'efficacité de la méthode, chaque véhicule module sa période d'attente entre deux retransmissions en fonction de la densité de circulation. Pour cela, il compte le nombre de véhicules qui l'entourent et détecte s'il se trouve dans une zone congestionnée en vérifiant les trois conditions suivantes :

1) Le nombre de véhicules dénombrés excède un certain seuil. 2) Le nombre de véhicules dénombrés au devant et le nombre de véhicules dénombrés à

l'arrière excèdent tous deux un certain seuil. 3) La vitesse du véhicule est inférieure à un certain seuil.

Figure 9: Forme de la zone de non-retransmission dans MHVB

Page 30: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

30/50

Lorsque ces trois conditions sont remplies, le véhicule modifie sa période d'attente par défaut avec une nouvelle valeur inversement proportionnelle au nombre de véhicules dénombrés. Ainsi, plus la circulation devient dense, plus la période d'attente va augmenter, permettant ainsi de réduire l'utilisation de la bande passante et le risque de collisions. L’inconvénient de ce protocole est que de nombreux véhiculent vont retransmettre le message périodiquement, ce qui augmente fortement la charge du réseau.

B) Disseminating messages among highly mobile hosts based on IVC

Le système proposé par les auteurs de [BRI00] rappelle le protocole DDT et est prévu pour la diffusion de message d’avertissement de danger. Les auteurs considèrent une couche intermédiaire de traitement des messages au-dessus de la couche MAC de la norme IEEE 802.11. Cette couche gère une liste des messages reçus récemment pour déterminer si un message a déjà reçu ou non, ce qui a des chances de se produire dans une approche de diffusion multi-saut. Si un message a déjà été reçu une fois, il est totalement ignoré. Pour éviter le problème de la tempête de diffusion (qui perturbe le mécanisme de CSMA), chaque récepteur d'un message à diffuser attend un certain temps avant de retransmettre le message. Le message contenant la position de son émetteur (obtenue avec un GPS), le récepteur connaît la distance qui le sépare de celui-ci et son temps d'attente est alors donné par la formule :

Ainsi, les principaux véhiculent participant à la propagation rapide du message sont ceux situés à la frontière de la zone de réception. Un seuil exprimé en nombre de sauts permet de limiter le nombre de fois que le message est retransmis. Le protocole ne prend pas en compte l’éventuel partitionnement du réseau et la limitation de la propagation du message sur le nombre de sauts ne semble pas toujours pertinente.

C) STEID (Spatio-Temporal Emergency Information Dissemination)

Le protocole décrit par les auteurs de [STEID] est conçu pour diffuser rapidement un message d’alerte à tout véhicule passant dans une zone bien définie durant toute la durée de validité de cette alerte. Il se propose d’assurer une fiabilité spatio-temporelle maximale (c’est-à-dire que tous les véhicules censés recevoir une alerte donnée la reçoivent bien et dans un temps borné).

Figure 10: Formule de calcul du temps d'attente avant retransmission

Page 31: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

31/50

Le protocole fonctionne sur une architecture hydride constituée de groupes de véhicules (communicants entre eux par WiFi) connectés à des serveurs externes via un réseau cellulaire (3G) comme l’illustre la figure ci-dessous. Le but de ce système est de s’affranchir du problème de partitionnement des réseaux de véhicules et d’utiliser les communications inter-véhiculaires pour diffuser un message de façon économique.

La formation des groupes repose sur la diffusion périodique de messages HELLO contenant des informations sur l’émetteur telles que sa route, sa position et son sens de circulation. Chaque véhicule maintient une liste de ses voisins directs circulant sur la même route et dans le même sens. Après cette phase de découverte de voisinage, un groupe est constitué et un chef de groupe est élu. Celui-ci détermine le serveur responsable de la zone dans laquelle il circule, s’enregistre auprès de celui-ci, récupère un identifiant de groupe et informe les autres véhicules du groupe. Le chef de groupe diffuse régulièrement ces informations mises à jour. Si un seul véhicule ne reçoit plus de nouvelles, il lance une nouvelle élection. Lorsqu’un véhicule du groupe souhaite émettre un message d’alerte, il ne passe pas par le chef de groupe mais s’adresse directement au serveur en utilisant les coordonnées qui ont été indiquées par le chef de groupe après l’enregistrement (ceci permet d’éviter de surcharger le chef de groupe pour la création de messages d’alertes). Le rôle du chef de groupe est d’envoyer régulièrement au serveur un message d’activité et de récupérer au passage une liste des messages d’alerte en cours sur la région. Il diffuse ensuite chaque message d’alerte au sein du groupe en utilisant la même méthode que DDT. Pour s’assurer que tous les véhicules reçoivent bien tous les messages d’alertes, les messages HELLO contiennent des informations supplémentaires permettant de synchroniser les listes de messages d’alertes de tous les véhicules du groupe. Un inconvénient notable de ce protocole est le recours à la diffusion périodique de messages. De plus, les auteurs n’indiquent aucun algorithme d’élection du chef de groupe, ce qui n’est pourtant pas trivial.

D) DPP (Directional Propagation Protocol)

La méthode proposée ici concerne la propagation de messages d’avertissement sur une autoroute. Il s'agit d'une méthode purement ad hoc, c'est-à-dire qu'il n'y aucun recours à une quelconque unité d'infrastructure. Elle utilise la direction voulue pour la transmission des

Figure 11: Architecture hybride mise en œuvre dans STEID

Page 32: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

32/50

données et celles des véhicules pour propager l'information. Elle est constituée de trois éléments : un protocole de transfert de garde (Custody Transfer Protocol – CTP), un protocole de routage inter-groupe et un protocole de routage intra-groupe (cluster). La méthode a recours au mécanisme « garder et faire suivre » (store-and-forward) pour pallier le phénomène de partitionnement des réseaux de véhicules. Le protocole utilise le phénomène de regroupement des véhicules sur un axe routier en considérant l'application d'un algorithme distribué de formation et de maintenance de groupes. À l'intérieur d'un groupe, un véhicule de tête (header) et un véhicule de queue (trailer) sont élus et chargés de la bonne propagation de l'information. Lorsqu'un véhicule intermédiaire veut propager un message, ce dernier est routé jusqu'au véhicule de tête ou de queue selon la direction de propagation souhaitée. Néanmoins, tout message transmis par un véhicule est communiqué à tous les membres de son groupe.

Les messages à propager sont conservés par les véhicules de tête et/ou de queue et retransmis régulièrement pendant une période indéterminée, jusqu'à ce que soit reçu un acquittement de la part du groupe suivant (dans la direction indiquée). À ce moment, la garde du message est implicitement transférée d'un groupe à l'autre. Les règles précises de ce mécanisme ne sont pas expliquées davantage. Les groupes allant en sens inverse peuvent servir d'intermédiaires mais n'obtiennent jamais la garde du message.

Le routage inter-groupe de l'information est supposé être réalisé par un algorithme distribué reposant sur des attributs adjoints aux messages. Ces attributs sont choisis par l'application, il peut s'agir de la direction souhaitée, la caractérisation des véhicules destinataires, TTL, etc. Les auteurs présentent ainsi une solution globale pour propager de l'information, mais sans rentrer dans les détails. S'ils donnent quelques références pour la formation des groupes et le mécanisme de transfert de garde, ils ne précisent pas en revanche comment peuvent être élus les véhicules de tête et de queue. Pour le transfert de garde, ils évoquent des règles à retrouver dans un travail ultérieur. Le routage intra-groupe n'est pas détaillé, mais il est supposé que les

Figure 12: Les véhicules sont organisés en groupes

Figure 13: Communications entre les groupes de véhicules

Page 33: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

33/50

communications de bout-en-bout sont possibles au sein d'un groupe. Pour le routage inter-groupe, ils décrivent un algorithme simple en fin d'article.

E) OAPB (Optimized Adaptative Broadcast Scheme)

Les auteurs de [OAPB] proposent une méthode de diffusion de messages d’urgence censée éviter le problème de la « tempête de diffusion ». Dans un protocole comme DDT, la sélection des véhicules qui retransmettent effectivement le message est fondée sur la distance qui les séparent de l’émetteur. Dans [OAPB], une stratégie de sélection différente est mise en place afin d’écarter un maximum de véhicules de l’acte de retransmission. Selon les auteurs, leur méthode permettrait d’obtenir un taux de véhicules atteints de l’ordre de 90-100% à 400 mètres de l’émetteur. La stratégie utilisée est basée sur l’attribution d’une probabilité de retransmission à chaque véhicule récepteur. La valeur de cette probabilité n’est cependant pas la même pour tous les véhicules : chaque véhicule calcule sa propre probabilité de retransmission qui dépend directement de son voisinage local à deux sauts (obtenu en supposant l’émission périodique de messages HELLO). En effet, les formules qui déterminent la valeur de cette probabilité (données dans l’article) utilisent le nombre de voisins à un seul saut, celui à deux sauts global et via chacun des voisins à un seul saut. Il peut arriver que ces nombres soient identiques pour plusieurs véhicules ; dans ce cas, pour éviter qu’ils retransmettent le message au même moment, un mécanisme dérivé de DDT est mis en place pour éviter cela. Celui-ci utilise une formule différente propre à [OAPB] pour le calcul du temps d’attente avant retransmission. Les simulations réalisées par les auteurs se sont limitées à 40 véhicules maximum, ce qui ne paraît pas très réaliste. D’autre part, l’émission périodique de messages HELLO consomme des ressources non négligeables.

F) ODAM (Optimized Dissemination of Alarm Messages)

Les auteurs de [ODAM] proposent un protocole conçu pour la diffusion de messages d’alerte généralisant le concept de DDT et censé pallier le phénomène de partitionnement du réseau de véhicules, éviter de recourir à la détermination du voisinage (aspect présent dans d’autres solutions) et être d’une grande fiabilité malgré tout. La solution proposée consiste à diffuser le message selon le mécanisme de DDT ; une formule pour le calcul du temps d’attente avant retransmission, similaire à celle de [BRI00], est donnée dans l’article. Lorsqu’un véhicule retransmet le message, il devient ce que les auteurs appellent « relai » et continue de l’émettre périodiquement jusqu’à ce qu’il reçoive le même message d’un véhicule situé derrière lui. Le message est diffusé dans des zones restreintes dites « zones à risque » qui sont, comme le montre la figure ci-dessous, les demi-portions de routes sur lesquelles les véhicules circulent en direction de l’incident ayant causé le message d’alerte.

Page 34: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

34/50

Le problème est que la nécessité de faire retransmettre périodiquement le message par certains véhicules s’avère délicat pour le passage à l’échelle ; de plus, la restriction de la zone de diffusion limite les applications potentielles du protocole.

*** Il existe encore de nombreux algorithmes de diffusion optimisée dans les réseaux de véhicules. Cependant, la réalisation d’un état de l’art plus complet nécessiterait la rédaction d’un rapport entièrement consacré à cela. Par la présentation de quelques protocoles, nous espérons avoir fourni une bonne représentation des techniques de diffusion qui peuvent être mises en œuvre dans les réseaux de véhicules.

Figure 14: Diffusion limitée aux zones à risque

Page 35: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

35/50

V. Proposition d’un nouveau protocole de diffusion

Beaucoup de protocoles présentés dans cet état de l’art sont prévus pour la diffusion de messages d’urgences, ou bien prennent souvent ce cas comme exemple. Pour notre service de diffusion d’annonces (cf. partie III), nous avons décidé de développer notre propre solution de diffusion pour les réseaux de véhicules, à l’attention des applications de confort. Nous aurions pu reprendre le protocole de [SODAD] explicitement conçu pour cela, mais le fait que chaque véhicule diffuse périodiquement ses informations ne nous paraissait pas convaincant en cas de passage à grande échelle.

1. La plate-forme de communications inter-véhiculaires : AIRPLUG

a. Les raisons du choix de la plate-forme d’implémentation

Avant de procéder à la conception et au développement proprement dit, nous avons du choisir une plateforme de communications inter-véhiculaires qui serait utilisée pour mettre en œuvre les services (dont notre protocole de diffusion) une fois qu’ils seraient développés. Pour cela, nous avions le choix entre deux plateformes différentes. La première, Carman (CAR-based Mobile Ad hoc Networks), a été développée à France Télécom et améliorée notamment par certains des stagiaires qui m’ont précédé. La seconde, Caremba, a quant à elle été conçue à l’Université de Technologie de Compiègne et comprend une suite logicielle appelée Airplug, développée par Bertrand Durcourthial. Notre choix s’est porté sur la plate-forme utilisée à l’U.T.C. pour plusieurs raisons : la suite logicielle Airplug qui y est associée permet de développer aisément de nouveaux protocoles et applications en mode utilisateur. De plus, il est possible de tester rapidement et de manière simple le fonctionnement décentralisé de ceux-ci sur une seule et même machine comme s’ils étaient exécutés sur des machines différentes, mais sans passer par un simulateur. Le nombre de nœuds est alors limité par la charge induite mais ceci est très utile pour effectuer un prototypage avant de faire de véritables simulations à plus grande échelle avec de nombreux nœuds. Enfin, j’avais pour ma part déjà réalisé une application destinée à fonctionner avec Airplug (un service de formation de groupe) dans le cadre du projet de l’U.V. SR05 sur les algorithmes répartis, ce qui permettait de gagner un peu de temps.

b. L’architecture de la suite logicielle Airplug

La suite logicielle Airplug a été conçue pour procéder à des expérimentations sur les réseaux de véhicules. Elle est constituée d’un programme central (airplug) et de tout un ensemble d’applications. Le rôle du programme central est de gérer les communications entre les différentes applications embarquées, que celles-ci s’exécutent à bord d’un même véhicule (communications locales) ou bien à bord de véhicules distincts (communications distantes).

Page 36: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

36/50

Le fonctionnement est relativement simple : les applications se connectent à airplug et ne dialoguent qu’avec lui en écrivant sur leur sortie standard et en lisant leur entrée standard. Chaque application, de même qu’airplug, s’exécute dans son propre processus et possède donc ses propres ressources. Les applications peuvent demander à airplug de recevoir les messages émis par une autre application (GPS par exemple), d’effectuer une requête et d’en attendre la réponse, etc. Et c’est airplug qui s’occupe d’accéder au réseau si nécessaire, via des sockets utilisant divers protocoles de communication. Les avantages induits par cette architecture sont multiples :

- les applications n’ont pas à s’occuper elles-mêmes de l’accès au réseau, - les applications restent totalement indépendantes les unes des autres et le plantage de

l’une d’entre elles n’affectent ni les autres, ni même airplug, ce qui garantit une grande robustesse fonctionnelle,

- il n’y a aucun langage de programmation particulier qui est imposé, une application doit simplement se servir de son entrée et de sa sortie standard pour être compatible avec airplug,

- la gestion du réseau par le seul programme airplug permet diverses optimisations qui bénéficient ensuite à toutes les applications et au fonctionnement général du réseau.

Pour de plus amples informations sur Airplug, voir la bibliographie à la fin de ce rapport.

Figure 15: Architecture d'Airplug

Page 37: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

37/50

2. Description du protocole

a. Présentation et description sommaire

Nous proposons un algorithme de diffusion optimisée pour les réseaux de véhicules que nous utiliserons comme un service de diffusion pour les applications de confort que nous envisageons de développer par la suite. Cet algorithme purement ad hoc (même si l’émission initiale peut être faite par un élément d’infrastructure) prend en compte le phénomène de partitionnement des réseaux de véhicules, qui est d’autant plus important lorsque le taux d’équipement des véhicules est faible. Or le succès des services qui seront développées pour les réseaux de véhicules dépendra fortement de leur capacité à fonctionner correctement malgré ce problème, et celui-ci se posera inévitablement, au moins au début. Dans notre protocole, un message est émis depuis une source et se propage dans toutes les directions alentour à l’intérieur d’une zone circulaire limitée centrée sur le point d’origine. Nous supposons que chaque véhicule embarque un GPS afin de connaître en permanence sa position ainsi qu’une carte routière numérique donnant à tout instant l’identifiant de la route sur laquelle il circule. Enfin, ce protocole ne requiert aucune connaissance de voisinage. Le long d’une seule et même route, un message est propagé dans chaque sens de circulation. Et pour chaque sens de circulation, cette propagation se fait uniquement par les véhicules qui circulent dans ce même sens. Le message est donc relayé « vers l’avant » de véhicule en véhicule qui circulent les uns derrière les autres dans la même direction. Lorsqu’un véhicule reçoit le message, il s’apprête donc à le retransmettre dans le cas où il circule dans le même sens que son émetteur et devant celui-ci. Le cas échéant, la propagation s’effectue alors en reprenant le même principe que DDT : le véhicule calcule un temps d’attente inversement proportionnel à la distance qui le sépare de l’émetteur, et s’il n’a pas reçu avant l’expiration de ce temps d’attente le même message provenant d’un véhicule circulant là encore dans le même sens et situé devant lui, il procède alors à sa réémission. De plus, lorsqu’un véhicule réémet le message, il écoute le canal de communication dans l’attente d’un « écho » afin de s’assurer qu’un autre véhicule devant lui a retransmis le message à son tour. Si ce n’est pas le cas, le véhicule continue de réémettre périodiquement le message jusqu’à obtenir un écho. La route sur laquelle circule le message peut être croisée par une autre (en clair, il s’agit d’une intersection). Pour ce cas, une condition supplémentaire est ajoutée afin que le message puisse se propager dans toutes les directions : un véhicule s’apprête à retransmettre un message s’il circule dans le même sens que l’émetteur et devant lui, ou bien si l’émetteur est situé sur une route différente. Ainsi, les véhicules qui circulent sur l’autre route vont commencer eux aussi à propager le message le long de leur propre route.

Page 38: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

38/50

b. Fonctionnement détaillé de l’algorithme

Au travers de la description précédente, nous pouvons distinguer deux sortes de véhicules : ceux qui retransmettent le message périodiquement (dans l’attente d’un écho) et ceux qui ne le font pas (car ils ont eu un écho). Étant donné un message, un véhicule se trouve donc toujours dans l’un des deux états suivants par rapport à celui-ci : soit il est « responsable du suivi » de ce message et dans ce cas il le retransmet périodiquement, soit il n’en est pas responsable et dans ce cas, il ne fait rien. Si le message est inconnu, le véhicule agit de la même façon que s’il était dans le deuxième état (ce qui revient à dire qu’un véhicule ne connaissant pas un certain message ne fait rien de ce message, ce qui est donc cohérent). Les véhicules assurant le « suivi » du message permettent de pallier le problème potentiel du partitionnement du réseau de véhicules. Le fonctionnement de l'algorithme peut être décrit plus formellement de cette façon : 1) Un véhicule ou une unité d’infrastructure A émet un message à diffuser à tous ses voisins directs en indiquant sa position GPS dans l'en-tête du message. 2) Lorsqu'un véhicule B reçoit le message : a) Si le message est inconnu ou que B n’est pas responsable de son suivi, et que l’émetteur A est situé derrière B, sur la même route et circule dans le même sens ou bien si A est situé sur une route différente de B et que le message est effectivement inconnu, ou encore si le message est inconnu et émis par son émetteur originel, alors B calcule un temps d'attente inversement proportionnel à la distance entre A et lui-même. b) Si B est actuellement responsable du suivi du message, et que l’émetteur A est situé devant B, sur la même route et circule dans le même sens, alors B cède la responsabilité du suivi du message à A car celui-ci est « mieux placé ». 3) Durant le temps d'attente, si le véhicule B reçoit le même message d’un autre véhicule situé devant lui, sur la même route et circulant dans le même sens, alors il renonce à prendre la responsabilité du suivi du message et annule la retransmission prévue en 2)-a). 4) À l'expiration du délai, si le véhicule B n’a pas annulé sa retransmission du message, alors il le réémet et en prend la responsabilité du suivi en le réémettant périodiquement jusqu’à se retrouver dans la situation 2)-b). (*) Chaque message à diffuser contient entre autres un champ contenant l’identifiant unique associé au message, un champ indiquant la distance maximale d’éloignement par rapport à l’émetteur originel et un champ correspondant à une durée d’existence maximale (TTL). À chaque fois qu’il est question de réémettre le message, le véhicule s’assure qu’il n’est pas trop éloigné de l’émetteur originel et que la durée d’existence du message n’est pas excédée.

Page 39: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

39/50

c. Quelques exemples de fonctionnement

Voici deux situations qui illustrent le fonctionnement du protocole :

Considérons six véhicules A, B, C, D, E et F circulant à 90 km/h sauf F qui circule à 50 km/h. Une borne émet un message que les véhicules A, B et C reçoivent. Tous trois s’apprêtent à le réémettre car la borne est l’émetteur originel du message. C réémet en premier car il est le plus éloigné de la borne. Comme C circule sur la même route, devant et dans le même sens qu’eux, A et B annulent leurs réémissions. D s’apprête à réémettre le message de C car il circule sur la même route, devant et dans le même sens que C, ce qu’il fait. À la réception de « l’écho » de D, C ne s’occupe plus du message. D ne recevant pas d’écho, devient responsable du suivi du message et le réémet périodiquement. A, B et C, situés derrière D, ne réémettent plus le message. Lorsque D croise E, E reçoit le message de D, en prend note mais ne le réémet pas car il ne circule pas dans le même sens que D. Lorsque D rattrape F (qui circule moins vite), F reçoit le message, le réémet et en devient responsable. D recevant l’écho de F situé devant, lui cède cette responsabilité. Lorsque D dépasse F, et reçoit le message réémis une nouvelle fois par F, il le réémet (car situé cette fois devant F) et en reprend ainsi la responsabilité. On voit donc que le véhicule responsable du suivi du message est toujours le plus éloigné dans le sens de propagation.

Considérons maintenant le cas d’un carrefour où un véhicule A arrive et diffuse un message. Tous les véhicules s’apprêtent à réémettre sauf C car il circule dans le sens contraire de A. E réémet mais cela n’annule pas la réémission de F car F est situé devant E, ni celles des autres véhicules situés sur une route différente (B) ou en sens contraire (D). B réémet donc et prend la responsabilité du suivi du message à A. F réémet et il se produit la même chose par rapport à E. Et enfin D réémet et devient responsable du suivi du message lui aussi. Ainsi les véhicules qui assurent le

suivi du message sont maintenant B, D et F dans les trois directions du carrefour depuis la route d’où vient A.

Page 40: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

40/50

d. Diagramme de représentation de l’algorithme

Le diagramme suivant représente le fonctionnement de l’algorithme décrit :

Figure 16: Diagramme de fonctionnement de l'algorithme de notre protocole de diffusion

Page 41: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

41/50

3. Discussion de la solution proposée Nous passons discutons ici des avantages et des inconvénients du protocole :

• Tout d’abord, notre protocole présente quelques similitudes avec celui présenté dans [ODAM] à la différence qu’il n’est pas conçu pour la diffusion de messages d’urgence, que la zone de diffusion n’est pas restreinte et que l’on intègre la notion de route.

• La présence de véhicules qui rediffusent périodiquement le message est un point délicat pour le passage à grande échelle mais cela est nécessaire pour remédier au problème éventuel du partitionnement du réseau de véhicules. De plus, notre protocole cherche à limiter au maximum le nombre de ces véhicules en tentant de les restreindre aux véhicules de tête sur chaque route et dans chaque sens de circulation.

• Un autre problème est que notre protocole ne peut pas tenir compte des éventuels changements de direction des véhicules aux intersections, ce qui peut parfois compromettre la bonne propagation du message dans toutes les directions. Mais, de par son fonctionnement, le protocole tente de couvrir au mieux la plus large zone possible. Il faut également noter que rien n’empêche le message de repasser par des routes sur lesquelles il s’est déjà propagé (ceci en raison du fait que le réseau routier présente de nombreuses boucles) mais ceci est plutôt bénéfique car de nouveaux véhicules n’ayant pas encore reçu le message peuvent arriver sur ces routes à tout moment. Un message diffusé peut donc passer et repasser d’une manière a priori aléatoire (selon le comportement des véhicules responsables de son suivi) sur les mêmes routes permettant de « balayer régulièrement » la zone de couverture de la diffusion afin de maximiser le taux de véhicules atteints.

• Pour le calcul du temps d’attente avant retransmission, nous avons repris la formule de [BRI00] dans notre implémentation (mais le choix d’une autre formule est totalement libre). Celle-ci présente l’inconvénient que tous les véhicules situés au-delà de la portée moyenne supposée du moyen de communication et qui parviennent néanmoins à recevoir le message vont tous tenter de le retransmettre immédiatement, ce qui peut entraîner des collisions.

• Notre protocole ne propose rien pour éviter le problème de la station cachée comme dans [UMB] et ne tient pas compte de l’éventuelle asymétrie des liens de communications qui peut poser problème dans le passage de responsabilité du suivi d’un message (pas d’écho reçu alors qu’un véhicule au devant a bien réémis le message, etc.).

• Nous n’avons pas donné de formule pour la période de réémission du message par les véhicules responsables de son suivi, et par la suite cette donnée est restée constante dans notre implémentation du protocole. Néanmoins, un tel paramètre devrait être modulé en fonction de la densité de circulation afin d’optimiser l’usage de la bande passante et de réduire les collisions éventuelles (en augmentant la période pour réémettre moins souvent lorsque la circulation est dense). Il devrait également être modulé en fonction de la vitesse des véhicules afin de s’assurer que lorsqu’un véhicule réémettant périodiquement un message en croise un autre, ce dernier ne peut pas passer à côté sans avoir reçu le message au moins une fois (la période devrait donc être d’autant plus grande que la vitesse des véhicules est faible).

Page 42: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

42/50

VI. Simulation du protocole développé

1. De l’intérêt de simuler

La simulation est une phase essentielle lors de l’élaboration d’un nouveau protocole de réseau. Elle permet de concevoir, d’implémenter et de valider un nouveau protocole (tout du moins sur un plan théorique) en procurant un moyen de le tester à moindre coût et d’anticiper les problèmes susceptibles de se poser et ainsi de corriger et d’optimiser son fonctionnement de manière à ce qu’il réponde parfaitement aux besoins qui ont conduit à sa création. Elle permet notamment d’étudier l’influence du facteur d’échelle, ce qui est très important dans le cas des réseaux de véhicules. La simulation permet également de comparer les performances de différents protocoles entre elles, de mesurer la portée des améliorations apportées à un protocole donné, etc. Elle n’est cependant qu’un outil d’étude et ne prouve donc pas d’une manière absolue l’efficacité d’un protocole dans des conditions réelles, qui doit encore être vérifiée par la pratique. Néanmoins, en multipliant les scénarios de simulation, il est possible d’avoir une assez bonne idée de la qualité d’un protocole.

2. Le simulateur NS-2 (Network Simulator v2)

Le simulateur NS-2 est un simulateur de réseaux à événements discrets, distribué en tant que logiciel libre disponible gratuitement sur le site web : http://www.isi.edu/nsnam/ns/. Il a été créé en 1989 comme une variante du simulateur REAL network simulator déjà existant mais a considérablement évolué depuis cette date. Son caractère libre permet l’’ajout très rapide de nombreux modèles correspondant à des technologies nouvelles par toute personne ou organisation voulant contribuer au projet. Pour cette raison, il est très fortement apprécié dans le monde de la recherche sur les réseaux, à qui il est d’ailleurs destiné. NS-2 est un simulateur de réseaux orienté objet. Son cœur est écrit en C++ pour atteindre une rapidité d’exécution maximale tandis que son utilisation repose sur le langage de script Tcl (en fait une variante orientée objet : OTcl) pour faciliter la commande des simulations. Par le biais de ce langage, l’utilisateur définit un simulateur, un réseau, des nœuds, des liens de communications et leurs caractéristiques, les protocoles utilisés, etc. ; tout cela en suivant le paradigme objet de NS-2. NS-2 est accompagné de nombreux outils dont nam (Network Animator) qui permet de rejouer graphiquement le déroulement d’une simulation (déplacements des nœuds, transferts de données, émissions de paquets, etc.) à partir du fichier de sortie prévu pour cela. Outre ses qualités indéniables, nous avons fait le choix de ce simulateur pour la raison suivante : l’implémentation de notre protocole de diffusion dans le cadre d’une utilisation

Page 43: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

43/50

avec airplug a été réalisée en Tcl/Tk et il est assez facile, moyennant un certain nombre de modifications rationnelles, de réutiliser ce code directement sous NS-2. Pour cela, un nouvel agent de routage représentant le comportement d’airplug a été ajouté dans NS-2 par Sofiane Khalfallah, qui travaille à l’U.T.C. comme doctorant. Ce projet s’appelle Airplug/NS.

3. Le modèle de mobilité utilisé

La représentation de la mobilité est très importante pour les simulations de réseaux de véhicules. Pour être la plus possible conforme à la réalité, elle doit prendre en compte les mouvements des nœuds selon des routes prédéfinies, la vitesse importante de ceux-ci, les phénomènes de dépassements, de bouchons, etc. Le modèle de mobilité que nous avons choisi est une représentation qui correspond plus ou moins à ce que l’on peut observer un environnement urbain. Il s’agit d’une architecture routière du type « quartier de Manhattan », à savoir un entrecroisement de routes parfaitement droites et perpendiculaires les unes aux autres. Les nœuds se déplacent aléatoirement en suivant ces routes. Ils ralentissent aux abords des intersections tandis qu’ils accélèrent en dehors. Ils n’ont pas tous la même vitesse, ce qui fait que certains en dépassent d’autres fréquemment. Ce modèle a été mis en œuvre par Mohamed Oussama Cherif, un doctorant de France Télécom qui effectue une thèse sur l’auto-organisation dans les réseaux de véhicules. En ce qui concerne NS-2, il s’agissait concrètement de produire un fichier d’entrée représentant les mouvements des nœuds. Dans le format requis par NS-2, ce fichier contenait les positions des nœuds à la date initiale, et une série d’indications à des dates quelconques de la forme : « le nœud se déplace vers tel point de la carte à telle vitesse ». Ceci est très pratique et évite d’avoir à calculer et indiquer soi-même les positions des nœuds au cours du temps. Ici, on indique juste une direction et une vitesse à chaque date voulue, et c’est NS-2 qui détermine lui-même les coordonnées successives des nœuds au cours du temps. À noter que cela n’empêche absolument pas d’obtenir la position d’un nœud à tout instant.

4. Les métriques de performance retenues Les métriques de performance que nous avons étudiées sont les suivantes :

• le taux de diffusion du message en fonction de la vitesse des nœuds, du temps et de la densité de circulation ;

• le taux de non réémission d’un message suite à chaque réception de celui-ci ; le but étant de mesurer l’économie réalisée en terme d’usage des ressources par rapport à une situation où chaque véhicule effectue systématiquement une réémission à chaque fois qu’il reçoit un message.

Page 44: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

44/50

5. Résultats des simulations

Nous avons simulés trois protocoles pour tenter de mesurer l’intérêt de notre approche. Il s’agit du protocole DDT décrit dans la section IV, d’un protocole dérivé au nom de code DDT+SNF qui est en fait DDT modifié de manière à ce que les véhicules au bout de la « chaîne de sauts » continuent de réémettre périodiquement le message jusqu’à le transmettre à un autre véhicule (SNF veut dire store-and-forward) mais il n’y aucune condition portant sur le fait que les véhicules circulent sur la même route ou pas, ni par rapport à leur sens de circulation et leurs positions relatives, et enfin DDT+SNF+ROUTES qui est en fait notre protocole décrit dans la section V, et qui a été a posteriori nommé Road-Oriented Broadcast (ROB). Pour chacun de ces protocoles, le temps d’attente maximal avant retransmission d’un message reçu a été fixé à 500 ms et la période de retransmission à 10 secondes. Dans chacun des cas de simulation suivants, la zone de couverture de la diffusion englobe la totalité de la carte, et le temps de diffusion n’a pas été limité, car nous ne faisons pas de mesures par rapport à ces paramètres, aussi nous avons configuré les choses ainsi afin que ceux-ci ne soient pas limitant dans le processus de diffusion.

a. Taux de diffusion en fonction de la vitesse

La densité est de 200 véhicules dans un espace de 2000m x 2000m et on s’intéresse au taux de véhicules qui ont reçu le message après une minute de diffusion, en faisant varier la vitesse de 30 à 110 km/h.

Figure 17: Taux de diffusion en fonction de la vitesse (en km/h)

Page 45: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

45/50

b. Taux de diffusion en fonction du temps

La densité est de 200 véhicules roulant à une vitesse moyenne maximale de 70 km/h dans un espace de 2000m x 2000m et on s’intéresse au taux de véhicules qui ont reçu le message après différents laps de temps de diffusion, allant de 20 à 100 secondes.

c. Taux de diffusion en fonction de la densité

La vitesse moyenne maximale est de 70 km/h dans un espace de 2000m x 2000m et on s’intéresse au taux de véhicules qui ont reçu le message après une minute de diffusion pour différentes valeurs de la densité de circulation, allant de 100 à 300 véhicules.

Figure 18: Taux de diffusion en fonction du temps (en secondes)

Figure 19: Taux de diffusion en fonction de la densité (en nombre de véhicules)

Page 46: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

46/50

d. Taux de non réémission à la réception d’un message

La densité est de 200 véhicules dans un espace de 2000m x 2000m roulant à une vitesse moyenne maximale de 50 km/h et on s’intéresse au taux de non réémission du message suite à une réception au moment où le taux de diffusion atteint 70%.

e. Analyse des résultats

Sur les trois courbes, nous pouvons observer que le protocole DDT de base est assez insuffisant. Ceci s’explique par le fait qu’il ne propose pas aucune solution pour pallier le problème du partitionnement du réseau de véhicules.

• La première courbe montre que son efficacité diminue fortement avec la vitesse des véhicules. En effet, lorsque les véhicules circulent vite, ils passent très rapidement les axes routiers et ont tendance à se concentrer au niveau des intersections où la vitesse est limitée, ce qui accentue – sinon provoque – le partitionnement du réseau.

• La deuxième courbe montre qu’une fois la diffusion de DDT terminée dans la partition où le message est émis, il n’y plus rien à attendre. Du temps supplémentaire ne change rien.

• La troisième courbe révèle le même problème. Plus la densité de véhicules est faible, plus le réseau est fragmenté et plus DDT se révèle peu efficace. DDT est un bon protocole pour la diffusion dans une partition mais il ne suffit pas à lui seul. Pour avoir un intérêt, il doit être mis en œuvre dans une solution plus globale comme [STEID] ou bien intégrer un mécanisme de diffusion opportuniste périodique ou non. Après cela, on constate qu’entre « DDT+SNF » et notre protocole, c’est ce dernier qui s’en sort le mieux et semble même bien « tenir le coup » comme le montre la première courbe où il se maintient alors que l’efficacité de DDT+SNF diminue un peu avec la vitesse. Avec DDT+SNF, le premier véhicule qui réémet au niveau d’une intersection provoque l’annulation de la réémission de tous les autres véhicules, ce qui « saborde » la diffusion dans toutes les autres directions. Ce phénomène est d’autant plus handicapant lorsque la vitesse est

Figure 20: Taux de non réémission à la réception d’un message

Page 47: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

47/50

grande et les véhicules concentrés aux intersections : il vaut mieux en effet dans une telle situation ne pas « gâcher » les occasions de répandre le message dans toutes les directions. Ceci explique sans doute que notre protocole donne de meilleurs résultats sur les trois courbes en étant le seul à toujours dépasser les 90%, même s’il faut bien avouer qu’avec un peu plus de retransmetteurs périodiques, il est normal que les résultats soient meilleurs.

Le diagramme montre quant à lui que DDT et DDT+SNF optimisent bien l’usage des ressources du réseau, alors que notre protocole est en retrait, même s’il évite tout de même près d’une retransmission sur deux, ce qui est déjà assez bien. La différence notable entre DDT+SNF et notre protocole, malgré la composante commune de retransmission périodique, s’explique par le fait que DDT+SNF ne « s’encombre » pas de conditions à la deuxième réception d’un message sur le point d’être retransmis : c’est l’annulation pure et simple qui prévaut alors qu’elle n’est pas systématique dans notre protocole, d’où la différence. Les résultats de notre protocole sont donc meilleurs, mais la charge du réseau est sans doute légèrement plus importante. Cependant, il faut garder à l’idée qu’il s’agit évidemment d’un compromis, relativement acceptable pour rendre la diffusion plus efficace.

Page 48: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

48/50

VII. Service de diffusion d’annonces

Le service de diffusion d’annonces a finalement été développé en s’appuyant sur le protocole de diffusion développé. L’interface de ce service, développé en Tcl/Tk est la suivante :

Elle intègre une carte routière qui montre la position du véhicule. À côté, un menu permet à l’utilisateur d’accéder à des informations sur les services locaux, ces informations étant reçues via le réseau de véhicules après diffusion par une borne et notifiées dans l’interface sous la forme d’un clignotement temporaire de l’entrée concernée dans le menu. L’affichage des informations sur un service sélectionné dans le menu se fait dans une zone dédiée en bas. Sous le menu, une autre zone affiche en boucle un résumé des différents services disponibles. Un point qu’il est important de signaler est qu’un tel service de diffusion d’annonces ne présente d’intérêt que s’il apparaît comme un service d’information sur des services locaux liés à des problématiques d’automobiliste (Où trouver une place pour se garer ? Où faire le plein d’essence ? Quelles sont les conditions de circulation ?, etc.). Aussi, les premières entrées du menu sont consacrées aux informations de ce type, et les informations de type publicitaire viennent seulement s’ajouter à la suite, afin de ne pas être perçues comme une forme d’agression commerciale. Elles sont restent secondaires tout en étant bien présentes.

Figure 21: Interface du service de diffusion d'annonces

Page 49: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

49/50

Le protocole de diffusion a fait l’objet de plusieurs démonstrations à Lannion et à Compiègne qui ont permis de produire plusieurs vidéos de présentation dans lesquelles cette interface apparaît pour montrer la réception des messages publicitaires au niveau utilisateur.

***

Conclusion Ce stage de fin d’étude m’a donné l’occasion d’améliorer mes compétences techniques dans le domaine des réseaux, et également en méthodologie de conduite de projet. Il a élargi ma vision même de ce qui se trouve derrière le terme de « réseau », et j’ai pu constater que les différentes sortes de technologies de réseaux existantes pouvaient être combinées de manière complémentaire afin de permettre la mise en œuvre de nouveaux services. J’ai également été imprégné du travail d’ingénieur au cours de ce stage, et la chance que j’ai eu de pouvoir passer du temps dans un véritable centre de R&D m’a permis de voir comment étaient anticipées, développées, et améliorées les solutions qui rendent notre vie toujours plus pratique.

Le domaine des réseaux de véhicules possède un grand potentiel de développement et leur mise en œuvre est déjà en marche depuis un moment. Après ce stage, j’ai hâte de voir, en tant qu’utilisateur, comment notre vie sera affectée une fois qu’ils seront déployés, et la place qu’occupera France Télécom dans ce domaine.

Page 50: Développement et démonstration de services destinés …senouci.net/download/Stages/Rapport_Max.pdf · En raison des problèmes inhérents à la nature dynamique de ces réseaux,

50/50

Bibliographie À propos de France Télécom-Orange : http://www.francetelecom.com/fr_FR/ Liste de nombreux projets concernant les réseaux de véhicules, recensés sur le site de CVIS : http://www.cvisproject.org/en/links/ À propos d’Airplug :

- B. Ducourthial et S. Khalfallah, « A platform for road experiments », janvier 2005.

- B. Ducourthial, « About efficiency in wireless communication frameworks on vehicular networks », 2007.

- S. Khalfallah, M. Jerbi, M.O. Cherif, S.-M. Senouci et B. Ducourthial « Expérimentations des communications inter-véhicules », décembre 2007. [DDT] M.-T. Sun, W.-C. Feng, T.-H. Lai, K. Yamad et H. Okada, « GPS-Based Message Broadcast for Adaptive Inter-vehicle Communications », VTC Fall 2000. [SODAD] L. Wischhof, A. Ebner, et H. Rohling, « Information Dissemination in Self-Organizing Intervehicle Networks », mars 2005. [UMB] G. Korkmaz et E. Ekici, « Urban Multi-Hop Broadcast Protocol for Inter-Vehicle Communication Systems », octobre 2004. [RBM] L. Briesemeister et G. Hommel, « Role-Based Multicast in Highly Mobile but Sparsely Connected Ad Hoc Networks », 2000.

[MDDV] H. Wu, R. Fujimoto, R. Guensler et M. Hunter, « MDDV: A Mobility-Centric Data Dissemination Algorithm for Vehicular Networks », 2004. [MHVB] M.N. Mariyasagayam, T. Osafune, M. Lenardi, « Enhanced Multi-Hop Vehicular Broadcast (MHVB) for Active Safety Applications », 2007. [BRI00] L. Briesemeister, L. Schäfers et G. Hommel, « Disseminating Messages among Highly Mobile Hosts based on Inter-Vehicle Communication », octobre 200. [STEID] J. Nyouonta et C. Borcea, « STEID: A Protocol for Emergency Information Dissemination in Vehicular Networks », 2006. [DPP] T.D.C. Little et A. Agarwal, « An Information Propagation Scheme for VANETs », septembre 2005. [OAPB] H. Alshaer et E. Horlait, « An optimized adaptive broadcast scheme for Inter-vehicle communication », mai 2005. [ODAM] A. Benslimane, « Optimized Dissemination of Alarm Messages in Vehicular Ad-Hoc Networks (VANET) », 2004. Le site officiel du simulateur de réseaux NS-2 : http://www.isi.edu/nsnam/ns/