Le routage de l’information dans les réseauxvéhiculaires mobiles

Mémoire

Olivier Rivaton

Maîtrise en informatiqueMaître ès sciences (M.Sc.)

Québec, Canada

© Olivier Rivaton, 2016

Résumé

Les réseaux véhiculaires mobiles, ou Vehicular Ad-hoc NETworks (VANETs), existentdepuis les années 80, mais sont de plus en plus développés depuis quelques annéesdans différentes villes à travers le monde. Ils constituent un apport d’informations auxréseaux routiers grâce à la mise en place de communications entre ses constituants :principalement les véhicules, mais aussi certaines infrastructures de bords de routesliées directement aux automobilistes (feux de circulation, parcomètres, infrastructuresspécialisées pour les VANETs et bien d’autres). L’ajout des infrastructures apporte unsupport fixe à la dissémination des informations dans le réseau. Le principal objectif dece type de réseau est d’améliorer la sécurité routière, les conditions de circulations, etd’apporter aux conducteurs et aux passagers quelques applications publicitaires ou dedivertissement. Pour cela, il est important de faire circuler l’information de la manièrela plus efficace possible entre les différents véhicules. L’utilisation des infrastructurespour la simulation de ces réseaux est bien souvent négligée. En effet, une grande partiedes protocoles présentés dans la littérature simulent un réseau ad-hoc avec des nœudsse déplaçant plus rapidement et selon une carte définie. Cependant, ils ne prennentpas en compte les spécificités même d’un réseau véhiculaire mobile. Le routage del’information dans les réseaux véhiculaires mobiles utilise les infrastructures de façoncertes opportuniste, mais à terme, les infrastructures seront très présentes dans les villeset sur les autoroutes. C’est pourquoi nous nous sommes concentrés dans ce mémoireà l’étude des variations des différentes métriques du routage de l’information lors del’ajout d’infrastructures sur une autoroute avec l’utilisation du protocole de routageAODV. De plus, nous avons modifié le protocole AODV afin d’obliger les messages àemprunter le chemin passant par les infrastructures si celles-ci sont disponibles. Lesrésultats présentés sont encourageants, et nous montrent qu’il est important de simulerles réseaux VANETs de manière complète, en considérant les infrastructures.

iii

Abstract

Vehicular Ad-hoc NETwork (VANET) were created in the early 80’s but have beendevelopped for the last few years in many cities around the world. They add informa-tions to the road network by including wireless communications between its component.Mainly the vehicles, but also numerous RoadSide Units (RSU) which are directly in re-lation with the road network (traffic light, meter, but also specialized units and more).The addition of RSUs help the network to disseminate the informations across the net-work. The main goal of this type of networks is to improve road safety and road traffic,as well as providing driver and passengers with advertisement and entertainment ap-plications. In order to accomplish these aims, a good routing of the information in thiskind of networks is a key. Unfortunately, the use of the RSUs in the simulations ofVANETs is often missed. Indeed, the major parts of research on the matter of routingin VANETs are a simulation of a mobile ad-hoc network with only some improvements: controlled movement of faster nodes. They do not use the full description of a ve-hicular ad-hoc network. The routing in these networks use RSU in an opportunisticway but in the end, the RSUs should be deployed massively so they have to be ack-owledged. In this research, we concentrate on the study of the variations of routingmetrics when RSUs are added to the simulations. The routing protocol used is AODV,and we present a modification of it, to force messages to use the path which containsRSU(s) if they exist. The results are encouraging and show us that in the simulationof a real vehicular ad-hoc networks, it is important to consider the roadside units.

v

Table des matières

Résumé iii

Abstract v

Table des matières vii

Liste des tableaux ix

Liste des figures xi

Remerciements xix

1 Introduction 11.1 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Objectifs de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Caractérisation des VANETs 72.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Caractéristiques intrinsèques . . . . . . . . . . . . . . . . . . . 92.1.3 Technologies de transmission et de diffusion . . . . . . . . . . 92.1.4 Diffusion de données . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Contextes d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Applications de sécurité publique . . . . . . . . . . . . . . . . 132.2.2 Coordination du trafic automobile . . . . . . . . . . . . . . . . 142.2.3 Gestion du trafic routier . . . . . . . . . . . . . . . . . . . . . 142.2.4 Applications de confort . . . . . . . . . . . . . . . . . . . . . 15

2.3 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Modèle de Mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Environnement de Mobilité : . . . . . . . . . . . . . . . . . . 182.4.2 Modèles analytiques : . . . . . . . . . . . . . . . . . . . . . . 192.4.3 Modèles physiques : . . . . . . . . . . . . . . . . . . . . . . . 212.4.4 Modèles empiriques et pilotés par les données : . . . . . . . . 21

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vii

3 Analyse du problème de routage 233.1 Protocoles de routages dans les VANETs . . . . . . . . . . . . . . . . 23

3.1.1 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.2 Protocoles Unicast Ad-hoc et leurs adaptations pour les VA-

NETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.3 Protocoles Unicast de groupe . . . . . . . . . . . . . . . . . . 273.1.4 Protocoles Unicast basé sur la position . . . . . . . . . . . . . 283.1.5 Protocoles Broadcast . . . . . . . . . . . . . . . . . . . . . . . 313.1.6 Protocoles Multicast et Geocast . . . . . . . . . . . . . . . . . 32

3.2 Principe de fonctionnement du protocole AODV . . . . . . . . . . . . 323.3 Paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.1 Métriques d’environnement . . . . . . . . . . . . . . . . . . . . 353.3.2 Métriques de performances . . . . . . . . . . . . . . . . . . . . 363.3.3 Modèle de trafic . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.4 Modèle de propagation . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Formulation du problème . . . . . . . . . . . . . . . . . . . . . . . . . 403.5 Analyse des solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Mise en œuvre et résultats 494.1 Modification du protocole AODV . . . . . . . . . . . . . . . . . . . . 49

4.1.1 Présentation de notre solution et Justification . . . . . . . . . 494.1.2 Environnement de simulation . . . . . . . . . . . . . . . . . . 534.1.3 Configuration des paramètres d’entrées . . . . . . . . . . . . . 54

4.2 Plan d’expérience et présentation des résultats . . . . . . . . . . . . . 594.2.1 Plan d’expérience . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5 Conclusion 795.1 Synthèse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.3 Travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Bibliographie 83

A Programmes 91A.1 Script tcl détaillé pour un réseau de noeuds mobiles avec ns2 . . . . . 91A.2 Pseudo-code du fichier d’automatisation des simulations . . . . . . . . 95A.3 Extrait d’un fichier trace produit par Ns-2 . . . . . . . . . . . . . . . 96

A.3.1 Extrait du fichier . . . . . . . . . . . . . . . . . . . . . . . . . 96A.3.2 Légende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.4 Fichier awk : Traitement pour le PDR . . . . . . . . . . . . . . . . . 97

B Résultats 99

viii

Liste des tableaux

4.1 Paramètres de simulation d’un VANET . . . . . . . . . . . . . . . . . . . 574.2 Paramètres fixes de la simulation . . . . . . . . . . . . . . . . . . . . . . 644.3 Paramètres variables de la simulation . . . . . . . . . . . . . . . . . . . . 644.4 Longueur de la flotte en fonction du nombre de véhicules. . . . . . . . . . 72

ix

Liste des figures

1.1 Illustration d’un MANET . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Type de communication dans les VANETs . . . . . . . . . . . . . . . . . 3

2.1 Bandes allouées pour les VANETs aux États-Unis . . . . . . . . . . . . . 112.2 Bandes allouées pour les VANETs en Europe . . . . . . . . . . . . . . . . 112.3 Aide au stationnement grâce aux VANETs . . . . . . . . . . . . . . . . . 162.4 Principaux projets de déploiements et de tests . . . . . . . . . . . . . . . 18

3.1 Les différents types de routages . . . . . . . . . . . . . . . . . . . . . . . 253.2 Classifications des protocoles de routages dans les VANETs. . . . . . . . 263.3 Cluster-based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Greedy Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 Face Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.6 GPCR Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7 Méthode de construction d’une route . . . . . . . . . . . . . . . . . . . . 333.8 Principe de détection d’un lien défaillant . . . . . . . . . . . . . . . . . . 343.11 Modèle de propagation Two-ray ground. . . . . . . . . . . . . . . . . . . 403.9 Traitement des messages RREQ . . . . . . . . . . . . . . . . . . . . . . . 473.10 Traitement des messages RREP . . . . . . . . . . . . . . . . . . . . . . . 48

4.1 Traitement des messages RREQ modifié . . . . . . . . . . . . . . . . . . 514.2 Traitement des messages RREP modifié . . . . . . . . . . . . . . . . . . 524.3 Processus de simulation d’un VANET avec SUMO et NS-2 . . . . . . . . 544.4 Exemple de configuration des nœuds avec SUMO . . . . . . . . . . . . . 554.5 Exemple de configuration d’une liaison avec SUMO . . . . . . . . . . . . 554.6 Visualisation d’une autoroute grâce à l’interface graphique de SUMO . . 564.7 Interface Graphique de Ns-2, Nam . . . . . . . . . . . . . . . . . . . . . 584.8 Distance de communication . . . . . . . . . . . . . . . . . . . . . . . . . 624.9 Exemple d’ajout d’un nœud fixe . . . . . . . . . . . . . . . . . . . . . . . 634.10 Positionnement d’un RSU . . . . . . . . . . . . . . . . . . . . . . . . . . 634.11 Positionnement de deux RSUs . . . . . . . . . . . . . . . . . . . . . . . . 634.12 Positionnement de trois RSUs . . . . . . . . . . . . . . . . . . . . . . . . 634.13 Positionnement de quatre RSUs . . . . . . . . . . . . . . . . . . . . . . . 644.14 Réaction des différents protocoles à l’augmentation du nombre de RSUs

en terme de délais de bout en bout . . . . . . . . . . . . . . . . . . . . . 66

xi

4.15 Réaction des différents protocoles à l’augmentation du nombre de RSUsen terme de ratio de livraison des paquets . . . . . . . . . . . . . . . . . 67

4.16 Réaction des différents protocoles à l’augmentation du nombre de RSUsen terme de nombre de sauts moyen de bout en bout . . . . . . . . . . . 68

4.17 Réaction des différents protocoles à l’augmentation du nombre de RSUsen terme de charge du réseau moyen . . . . . . . . . . . . . . . . . . . . 69

4.18 Évolution des délais de bout en bout en fonction du nombre de véhiculesdans le cas où il y a trois RSUs . . . . . . . . . . . . . . . . . . . . . . . 70

4.19 Évolution du PDR en fonction du nombre de véhicule dans le cas où il ya trois RSUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.20 Évolution du nombre de sauts moyen en fonction du nombre de véhiculedans le cas où il y a trois RSUs . . . . . . . . . . . . . . . . . . . . . . . 72

4.21 Évolution de la charge du réseau moyen en fonction du nombre de véhi-cules dans le cas où il y a trois RSUs . . . . . . . . . . . . . . . . . . . . 73

4.22 Délai moyen de bout en bout en fonction de la vitesse dans le cas où il ya 200 véhicules et trois RSUs . . . . . . . . . . . . . . . . . . . . . . . . 74

4.23 PDR moyen en fonction de la vitesse dans le cas où il y a 200 véhiculeset trois RSUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.24 Nombre de sauts moyen en fonction de la vitesse dans le cas où il y a200 véhicules et trois RSUs . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.25 Charge du réseau moyen en fonction de la vitesse dans le cas où il y a200 véhicules et trois RSUs . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.1 Résultats avec 0 RSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100B.2 Résultats avec 1 RSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101B.3 Résultats avec 2 RSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102B.4 Résultats avec 3 RSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103B.5 Résultats avec 4 RSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

xii

Sigles et Acronymes

Symbols (glossaries)

3G 3e Génération.

4G 4e Génération.

A

A-STAR Anchor-based Street and Traffic Aware Routing.

AODV Ad-hoc On-Demand Distance Vector Routing.

C

C-Vet UCLA Campus Vehicular Testbed.

C2C-CC "Car 2 Car Communication Consortium".

CAR Connectivity Aware Routing protocol.

CarTel Car Telecommunications.

CBQ Class Based Queuing.

CBR Constant Bit Rate.

CCH Control Channel.

COIN Clustering for Open Inter-vehicular communication Networks.

D

DIR Diagonal Intersection based Routing protocol.

DRR Deficit Round Robin.

DSDV Dynamic destination-Sequenced Distance Vector.

DSR Dynamic Source Routing.

DSRC Dedicated Short Range Communications.

DV-CAST Distributed Vehicular Broadcast.

xiii

E

ESRI Environmental Systems Research Institute.

F

FCC Federal Communications Commission.

FIFO First In First Out.

FQ Fair Queuing.

FTP File Transfer Protocol.

G

GPCR Greedy Perimeter Coordinator Routing.

GPS Global Positioning System.

GPSR Greedy Perimeter Stateless Routing.

H

HV-TRADE History-enhanced V-TRADE.

I

I2V Infrastructure to Vehicule.

IEEE Institute of Electrical and Electronics Engineers.

ITS Intelligent Transport System.

IVG Inter Vehicular Geocast.

J

JoBS Joint Buffer Management Scheduling.

JSK Association of Electronic Technology for Automobile Traffic and Driving.

L

LORA_CBF Location Routing Algorithm with Cluster-Based Flooding.

LTE Long Term Evolution.

M

MAC Media Access Control.

MANET Mobile ad-hoc Network.

xiv

MGRP Mobile Gateway Routing Protocol.

MIBR Mobile Infrastructure Based VANET Routing protocol.

MIT Massachusetts Institute of Technology.

MMTS Multi-agent Microscopic Traffic Simulator.

N

Nam Network Animator.

NCTU Université Nationale Chiao-Tung.

NRO Normalized Routing Overhead.

NS-2 The Network Simulator 2.

O

OLSR Optimized Link State Routing Protocol.

ORBIT Open-Access Research Testbed for Next-Generation Wireless Networks.

OSI Open System Interconnection.

P

PDR Packet Delivery Ratio.

PR-AODV Predicted AODV.

R

RD Random Direction Model.

RED Random Early Discard buffer management.

RPGM Reference Point Group Mobility model.

RSU Roadside Units.

RTP Real-time Transfer Protocol.

RW Random Walk.

RWP Random Waypoint.

S

SADV Static-node-assisted Adaptative data Dissemination in Vehicular networks.

SCH Service Channel.

SIMPS Sociological InteractionMobility for Population Simulation.

xv

SJTU Shanghai Jiao Tong University.

SLAW Self-Similar Least-Action Walk.

SRB Secure Ring Broadcasting Routing Protocol.

SUMO Simulation of Urban Mobility.

T

TCP Transmission Control Protocol.

TIGER Topologically Integrated Geographic Encoding and Referencing.

TraNS Traffic and Network Simulation Environment.

U

UCLA University of California, Los Angeles.

UDP User Datagram Protocol.

UMASS University of Massachusetts.

V

V-TRADE Vector-based TRAcking DEtection.

V2I Vehicle to Infrastructure.

V2V Vehicle to Vehicle.

VANET Vehicular Ad-hoc NETwork.

VeiNS Vehicles in Network Simulation.

W

WAVE Wireless Access in Vehicular Environment.

WiMax Worldwide Interoperability for Microwave Access.

WSN Wireless Sensor Networks.

Z

ZOF Zone of Forawarding.

ZOR Zone of Relevance.

xvi

Je dédie ce mémoire à France età mes parents

xvii

Remerciements

J’aimerais remercier les personnes qui m’ont accompagné tout au long de la réalisationde ce mémoire.

Dans un premier temps, mon directeur de recherche, M. Ronald Beaubrun qui a su meguider, m’accompagner et être toujours disponible lorsque j’en avait besoin.

Ensuite, j’aimerais remercier mon école en France, l’ECAM Rennes, ainsi que l’Univer-sité Laval, et tout le personnel encadrant, qui m’ont permis grâce à la mise en placede leur échange, de participer à ce programme. Je remercie en particulier Mme Hé-lène Crunel et M. Nadir Belkhiter qui ont mis en place le double diplôme en GénieInformatique l’année de mon arrivée au Québec.

Je remercie aussi mes amis, français et québécois, pour tout les moments partagés aucours de ces deux années de recherches et de rédaction. J’ai pu grâce à eux être enmesure d’allier travail et loisir afin de garder un rythme de vie équilibré. Je remercieégalement la société LeLynx.fr dans laquelle j’ai effectué mon stage de fin d’études. J’aipu grâce à eux finaliser la rédaction de ce mémoire tout en mettant un premier piedsdans le monde professionel.

Finalement, je remercie ma famille, Andrée-Claire et Franck Rivaton ainsi que Violaine,Adèle et Éléonore, qui m’ont soutenu, poussé et encouragé tout au long de mes études,en France et au Québec.

xix

Chapitre 1

Introduction

Le nombre de véhicules en circulation est de plus en plus important. En 2010, nousavons dépassé le milliard de voitures sur les routes, et l’augmentation est en moyennede 35 millions par an [1]. Liés à cette croissance constante, les accidents de la route fontpartie des dix principales causes de mortalité dans le monde [2]. Afin de réagir à cette si-tuation, l’amélioration de la sécurité routière est devenue une préoccupation. C’est danscet esprit que sont apparues un certain nombre de recherches qui visent non seulement àréduire le nombre de morts sur les routes et à améliorer les conditions de la circulation,mais aussi à diminuer les embouteillages et la pollution [3]. Les réseaux véhiculairesmobiles, mieux connus sous le nom de Vehicular Ad-hoc NETwork (VANET), se sontfixés ces objectifs. Ce domaine de recherche intéresse aussi bien les universitaires que lesindustriels de l’automobile et les grandes entreprises de l’innovation (comme Google),qui travaillent actuellement sur trois projets majeurs [4] :

1. Assistance à la conduite (self-parking, aide au dépassement, radar anticollision,régulateur de vitesse, etc.) ;

2. Réseaux de communication entre les véhicules ;

3. Voitures autonomes.

Ce sont les réseaux de communications entre les véhicules et plus particulièrement leroutage de l’information qui nous intéressent dans ce mémoire. Pour acheminer lesinformations d’un véhicule à un autre à travers un réseau composé de beaucoup devéhicules, se déplaçant à des vitesses atteignant 160 km/h, il est nécessaire d’effectuerun routage rapide et efficace de l’information.

Dans cette introduction, la Section 1.1 donne un aperçu des réseaux véhiculairesmobiles, ainsi que du routage de l’information dans ces réseaux. Ensuite, la Section 1.2

1

établit les éléments de la problématique. La Section 1.3 présentera les objectifs de cemémoire, alors que la Section 1.4 présentera son organisation.

1.1 Concepts de base

Un réseau véhiculaire mobile est un réseau de type ad-hoc. Un réseau ad-hoc estcapable de se mettre en place de façon autonome, c’est-à-dire sans l’aide d’aucuneinfrastructure préparée à l’avance [3]. Les communications se font alors directemententre les différents nœuds du réseau. On distingue deux types de réseaux mobiles ad-hoc : les Mobile ad-hoc Networks (MANETs), illustrés à la Figure 1.1, et les VANETs.Les MANETs sont les plus connus. Ils sont utilisés pour établir des communicationsde façon rapide et autonome dans des zones démunies de toute couverture de réseau(comme par exemple, en cas de catastrophe naturelle ou dans une zone de combats).Les VANETs sont utilisés pour établir des communications entre tous les véhicules quicirculent sur les routes. Mais, les VANETs ne sont pas des réseaux purement ad-hoc.Ils peuvent utiliser, de façon opportuniste, les communications avec des infrastructures,permettant ainsi un accès à d’autres réseaux et donc aussi, à Internet. Les différentesinfrastructures utilisées dans le cadre des VANETs sont appelées «Unités de Bords deRoutes», de l’anglais Roadside Units (RSU) [5]. Ces unités peuvent être des feux decirculation, des parcomètres, ou toute autre borne placée au bord de la route.

Figure 1.1 – Illustration d’un MANET

On distingue dans les VANETs deux types de communications : les communicationsentre les véhicules, Vehicle to Vehicle (V2V), et les communications entre les véhiculeset les RSUs, Vehicle to Infrastructure (V2I) ou Infrastructure to Vehicule (I2V). L’utili-sation des RSUs offre un accès à Internet ou à des bases de données locales, permettantde la publicité ciblée en fonction de la localisation du véhicule. Les communications V2Iet I2V sont utilisées idéalement en tout temps. Seulement, lors de certaines situations

2

particulières (en cas d’urgence, ou lors d’absence de RSU dans la zone de transmission),le réseau utilise les communications ad-hoc. Les véhicules peuvent être en mesure d’ac-céder au réseau via les RSUs, mais choisiront les communications ad-hoc plutôt queV2I, si cette dernière est trop gourmande, trop chère, ou inadéquate.

Afin d’illustrer ces différents concepts, la Figure 1.2 nous montre deux véhiculesqui s’échangent des données. Ces données sont, par exemple, du contenu multimédiavolumineux. Dans ce cas, on préfère donc la connexion stable allant du véhicule 1 auRSU, puis du RSU au véhicule 2, ou dans le sens inverse. Ce sont des communicationsV2I et I2V. Cette connexion permet d’accéder à du contenu supplémentaire, car le RSUest généralement relié à Internet. Cependant, lors de la rencontre de l’obstacle par leVéhicule 1, le message d’urgence sera transféré de façon ad-hoc directement du véhicule1 au véhicule 2, ce qui permettra un délai de transmission plus court que si le messageété passé par le RSU : c’est une communication V2V.

Figure 1.2 – Type de communication dans les VANETs

Les VANETs peuvent utiliser différentes technologies de communication : les com-munications issues des réseaux mobiles, comme par exemple la 3e Génération (3G),la 4e Génération (4G), ainsi que les technologies Wi-Fi et Worldwide Interoperabilityfor Microwave Access (WiMax). Cependant, ils utiliseront en priorité une technologie

3

Wi-Fi qui a été développée spécialement pour être utilisé dans ce type de réseau : latechnologie Dedicated Short Range Communications (DSRC).

Le routage est une méthode d’acheminement des informations vers la bonne desti-nation à travers un réseau de connexion donnée. Il consiste à assurer une stratégie quigarantit, à tous moments, un établissement de routes qui soient correctes et efficacesentre n’importe quelle paire de nœuds appartenant au réseau. L’objectif du routagede l’information est d’assurer l’échange des messages d’une manière continue. Vu leslimitations des réseaux ad-hoc, la construction des routes doit être faite avec un mi-nimum de contrôle et de consommation de la bande passante [6]. En prenant de plusen considération les caractéristiques des réseaux véhiculaires mobiles, il est importantde minimiser à la fois les délais d’acheminement et les pertes des messages échangésentre les véhicules. Dans ce contexte, le réseau doit être robuste et avoir un temps d’at-tente très court : il doit être capable de survivre à la grande mobilité et doit pouvoirtransférer rapidement les messages du véhicule source vers le véhicule destinataire. Afinde réduire les délais des messages les plus importants, on peut catégoriser les types demessages qui transitent sur le réseau, non pas en deux groupes (les messages de sécuritépour le conducteur et les «messages commerciaux» pour les passagers), mais en plu-sieurs sous-catégories au sein de ces deux groupes, afin de pouvoir gérer efficacement leréseau. Les messages les plus importants, qui relèvent de la sécurité et de la préventiondes accidents, seront alors envoyés en priorité.

Un aspect important des VANETs qui ne sera pas pris en compte dans ce mémoire estla sécurité. Le réseau se doit d’être verrouillé afin qu’aucune personne mal intentionnéene puisse envoyer de faux messages d’urgence qui pourraient mener à des résultatsdangereux.

1.2 Problématique

Le routage de l’information dans les réseaux véhiculaires mobiles n’est pas un pro-blème simple [5]. En effet, les VANETs sont des réseaux spontanés qui doivent être enmesure de se mettre en place de façon autonome. De plus, les VANETs sont utilisés pourl’amélioration de la sécurité routière, c’est-à-dire pour la prévention et la diminutiondes accidents de la route. Dans ce contexte, les messages qui transitent sur le réseause doivent d’être délivrés dans des délais courts et sans perte. Afin de répondre à cesproblèmes, les chercheurs ont développé un certain nombre de méthodes de routage de

4

l’information [7–26]. Toutefois, la plupart de ces protocoles ne prennent pas en compteles différentes spécificités qu’implique un réseau véhiculaire mobile et ne sont souventefficaces que dans des situations particulières. En effet, un VANET doit être efficace enville, en campagne et sur autoroute, dans des situations d’embouteillages, de circulationfluide, mais aussi dans les situations d’urgences.

Un autre aspect important des VANETs qui est souvent négligé lors de l’établissementde protocoles de routage est sa possibilité de communiquer via les infrastructures debords de routes. Les Réseaux véhiculaires mobiles sont souvent pris pour des réseauxpurement ad-hoc lors des simulations [7–21]. Ainsi, pour transmettre efficacement lesmessages vers leurs destinataires, il faut être en mesure d’exploiter les deux types decommunications : V2V et V2I. Quelques protocoles proposent ce type de routage [22–25], mais ces derniers sont souvent peu développés malgré des résultats prometteurs.

1.3 Objectifs de recherche

Dans ce mémoire, nous visons à concevoir et à mettre en place une méthode deroutage qui permettra de minimiser les délais de transmission et les pertes de messagesdans les VANETs. De manière plus précise, nous visons les objectifs suivants :

1. Étudier les spécifications des réseaux véhiculaires mobiles afin de comprendre etd’identifier le mieux possible les différents défis et enjeux du routage de l’infor-mation dans ces réseaux ;

2. Identifier, à travers une étude complète des méthodes et protocoles de routage,les différents critères d’évaluation de performances, afin de distinguer les pointsforts et points faibles de ces protocoles, dans le contexte d’un réseau véhiculairemobile ;

3. Proposer une méthode de routage répondant au mieux à la problématique etévaluer ses performances.

1.4 Organisation du mémoire

Le mémoire est composé de cinq chapitres. Le deuxième chapitre va présenter demanière générale les réseaux véhiculaires mobiles et leurs spécifications. Le troisièmechapitre va se concentrer sur les aspects de routage de l’information. Après une rapideprésentation de ce qu’est un protocole de routage, ce chapitre approfondira les aspects

5

du routage de l’information liés aux réseaux véhiculaires mobiles. Le quatrième chapitreprésentera notre mise en œuvre ainsi que les résultats obtenus au cours de cette maitrise.Le mémoire sera conclu par le cinquième chapitre.

6

Chapitre 2

Caractérisation des VANETs

Ce chapitre, divisé en quatre sections, caractérise les VANETs. Il présente dans la pre-mière section les réseaux véhiculaires mobiles de manière générale, à travers un rapidehistorique, quelques caractéristiques particulières et une présentation des technologiesde transmission et de diffusion utilisées dans les VANETs. Ensuite, la seconde sectionexpose les différentes possibilités d’applications de ces réseaux. La troisième sectionprésente les étapes de déploiement, et la quatrième et dernière section va conclure cechapitre en faisant un aperçu des modèles de mobilités dans les VANETs.

2.1 Présentation générale

2.1.1 Historique

C’est au début des années 80 que les premières études, portant sur des communi-cations entre véhicules et infrastructure, ont été menées au Japon à travers le projetJSK (Abbréviation japonaise pour "Association of Electronic Technology for Automo-bile Traffic and Driving") [27]. Plus tard, d’autres projets ont été créés aux États-Uniset en Europe [5]. La motivation première de ces projets a toujours été l’améliorationde la sécurité routière et la diminution du nombre de morts sur les routes. Ce n’estque plus tard que les applications de type commercial sont venues s’ajouter à l’équa-tion. La recherche sur ces réseaux a vraiment commencé à croitre au début des années2000, avec la création de projets tels que «CarTalk 2000» en Europe [28], «AdvanceSafety Vehicle 3» au Japon [29], et «Vehicle Safety Communication» aux États-Unis[30]. Des ateliers et conférences internationales ont ensuite été créés afin de rassemblerles industriels et les universitaires pour échanger sur leurs projets. En Europe, plu-

7

sieurs constructeurs d’automobiles se sont rassemblés pour créer une organisation à butnon lucratif ayant pour but principal d’augmenter la sécurité routière : le "Car 2 CarCommunication Consortium" (C2C-CC) [31]. Cette organisation rassemble maintenantun très grand nombre de membres et travaille en coopération avec les organismes decertifications et de standardisations européens afin de développer le déploiement desréseaux véhiculaires mobiles.

En 2009, l’Institute of Electrical and Electronics Engineers (IEEE), a publié le stan-dard 802.11p qui définit l’accès sans fil dans les réseaux véhiculaires mobiles (WirelessAccess in Vehicular Environment (WAVE)) [32].

Très vite, les chercheurs se sont intéressés à un nouveau type d’adressage et de rou-tage des paquets de données [3, 33, 34]. Plutôt que d’utiliser la méthode IP, il a été misen place une méthode géographique appelée GeoCast, basée sur les standards DSRCet IEEE 802.11, pour fournir une communication multi-sauts sans fil, et ce, sans l’aided’infrastructure (par comparaison avec le Global Positioning System (GPS) qui néces-site un réseaux de satellite, à ne pas confondre avec les infrastructure de bords de routeou RSU). GeoCast permet ainsi d’étendre les communications de courte portée, four-nie par DSRC, à des communications multi-sauts. Geocast a d’abord été conçu pourles MANETs, mais a très vite été étendu à d’autres réseaux tels que les VANETs, lesréseaux de senseurs sans fil, Wireless Sensor Networks (WSN), ou les réseaux maillés(Mesh Networks) [33]. Ce type d’adressage est en effet bien adapté aux réseaux mobilesdynamiques, ayant des changements de topologies fréquents, avec ou sans infrastruc-ture, et supportant des connexions intermittentes.

Ce concept a été introduit vers la fin des années 80 [35]. Ce n’est que quelquesannées plus tard qu’il a été présenté en conférence [36], puis au début des années 2000,le protocole de routage Greedy Perimeter Stateless Routing (GPSR) [10] devint un despremiers algorithmes de routage utilisant ce type d’adressage et de routage des données.Depuis, il revient dans beaucoup d’autres protocoles et projets de recherche industriels,académiques et de standardisation [31, 37–40].

8

2.1.2 Caractéristiques intrinsèques

Les réseaux véhiculaires mobiles ont les caractéristiques intrinsèques suivantes [3, 5,34] :

1. Ils sont très dynamiques. En effet, le réseau doit pouvoir gérer des véhicules al-lant de 0 à 160 km/h. Ainsi si deux véhicules sont en sens inverse et qu’ils roulenttous les deux à des vitesses excessives, le temps d’inter-connexion pourra être trèscourt.

2. Leurs environnements sont très variés. L’environnement peut être une route, uneautoroute, ou une ville (beaucoup plus complexe). De plus, une situation d’embou-teillage peut mener à l’encombrement du réseau, tandis qu’une route de campagnepeut conduire à la disparition des liens du réseau, surtout la nuit.

3. Leur mobilité peut être prédite et modélisée. En effet, la circulation sur une routeou une autoroute est facilement prévisible, car le véhicule doit en général restersur la route. Connaissant la position actuelle du véhicule et sa vitesse, il est ainsipossible de prédire la position du véhicule, à condition de connaitre la carte del’environnement.

4. Ils n’ont pas de problème d’énergie ou de stockage. Les équipements du réseauétant installés dans le véhicule, il n’y a pas de problème lié à la durée de vie duréseau. De plus, on peut installer dans les véhicules des systèmes de stockagespour conserver des cartes, ou tout autre type de données susceptibles de servirau fonctionnement du réseau.

2.1.3 Technologies de transmission et de diffusion

Les réseaux véhiculaires mobiles sont en théorie capables d’utiliser un grand nombrede technologies de transmission, dont celles issues des 3e génération (3G) et 4e généra-tion (4G, Long Term Evolution (LTE)) de téléphonie mobile, le Wi-Fi, le WiMax, et leDSRC/WAVE [33]. Les réseaux mis en place pour les véhicules peuvent utiliser une ouplusieurs de ces technologies. Nous allons décrire les principales technologies ci-dessousen terminant par la plus utilisée dans les VANETs : DSRC/WAVE.

9

3G et 4G LTE

Les VANETs utilisent les connexions ad-hoc. Afin de pouvoir se connecter au réseauglobal, et donc à Internet, le réseau cellulaire mobile peut être utilisé. Ce dernier utiliseun certain nombre de transmissions, parmi lesquelles : 3G, 4G, LTE. Ces technologiesde transmission sont plus ou moins performantes, et leurs débits théoriques dépendentfortement de la mobilité des utilisateurs. Ainsi, puisque les réseaux véhiculaires mobilessont hautement dynamiques, ces technologies sont peu adaptées. De plus la nécessitéd’appartenance au réseau, via une carte SIM, et donc un forfait avec un opérateur, n’estpas intéressante.

Wi-Fi et WiMax

Les technologies Wi-Fi et WiMax, à travers les standards 802.11 et 802.16, peuventêtre utilisés dans les VANETs. Un protocole Wi-Fi, 802.11p, a été établi spécialementpour les VANETs, il est pris en compte par la technologie DSRC. De son côté, WiMaxpermet une transmission portant sur une zone géographique étendue. Il reste donc inté-ressant comme moyen de communication entre les véhicules et les infrastructures, afinde permettre un accès à Internet au réseau ad-hoc formé par les véhicules. CependantWiMax n’est pas non plus idéal dans les situations de très grande mobilité. C’est pour-quoi on pourra l’utiliser pour les infrastructures, mais on préfèrera DSRC/WAVE pourles véhicules. Cela peut poser des problèmes de mise en place, les véhicules nécessitantun bloc de réception/transmission capable d’utiliser à la fois DSRC/WAVE et WiMax.

DSRC/WAVE

La technologie DSRC/WAVE est déjà utilisée pour certaines applications liées à l’au-tomobile, tel que le payement électronique des péages sans s’arrêter. Nous allons présen-ter en détail cette technologie. Les communications dédiées à courtes portées, DSRC,ont été créées spécialement pour les réseaux véhiculaires mobiles. Elles regroupent lesstandards WAVE ainsi que la norme 802.11p, qui est la norme Wi-Fi pour les réseauxvéhiculaires mobiles. WAVE regroupe les standards IEEE 1609.x (1,2,3 et 4), qui sontles standards des couches 2, 3, 4 et 7 du modèle Open System Interconnection (OSI).IEEE 802.11p [32], gère la couche Physique (couche 1) de ce même modèle. Ils sontdéveloppés spécialement pour les réseaux véhiculaires mobiles, en fonction des spéci-fications citées ci-dessus (Véhicules rapides, jusqu’à 160 km/h, portés de transmissionallant de 300 à 1000 mètres, temps de latence faible [moins de 50 ms], et débit théoriqueallant jusqu’à 6 Mbps).

10

Des bandes dédiées ont été allouées par les organismes de certification aux États-Unis et en Europe. Malheureusement, ces bandes ne sont pas compatibles les unes avecles autres. Aux États-Unis, 75 MHz ont été alloués autour des fréquences de 9 GHz,et en Europe, 25 MHz ont été alloués autour de cette même bande. Ces bandes sontreprésentées sur les figures 2.1 et 2.2. Au Japon, 80 MHz ont été alloués autour de labande 5,8 GHz.

Figure 2.1 – Bandes allouées pour les VANETs aux États-Unis

Figure 2.2 – Bandes allouées pour les VANETs en Europe

Spécification de bandes en Amérique du Nord.

Aux États-Unis, l’allocation a été attribuée par la Federal Communications Com-mission (FCC). La bande allouée est large de 75 MHz autour de la fréquence 5.9 GHz(5.850 GHz à 5.925 GHz ). Comme on peut le voir sur la Figure 2.1, la largeur descanaux est de 10 MHz, et les débits possibles sur ces canaux vont de 3 à 27 Mbps.Cependant les canaux 174 et 176 ainsi que les canaux 180 et 182 peuvent être utilisésconjointement, afin de former les canaux 175 et 181, et ainsi pouvoir accéder à un débitde données allant jusqu’à 54 Mbps. Le canal de service 172 est en réalité réservé en casde danger vital (Critical Safety of Life), et le canal 184 est un canal de puissance élevépour la sécurité publique (High Power Public Safety).

11

2.1.4 Diffusion de données

Dans les paragraphes précédents, nous avons pu constater l’importance de l’échanged’information entre les différents véhicules, afin de détecter et de prédire les situationshasardeuses. La diffusion de données dans un réseau consiste à envoyer l’informationà tous les nœuds qui sont à portée, à la différence d’une transmission qui n’envoiel’information qu’à certains nœuds, sélectionnés à l’avance. Lors de diffusion de données,le paramètre à prendre en compte est la minimisation de la charge du réseau, afin derelier rapidement et de manière fiable les zones ciblées. Ce système est différent duroutage de l’information, qui lui concerne la découverte des routes, leurs maintenancesainsi que leurs optimisations.

La diffusion de données rencontre dans les VANETs plusieurs défis majeurs. En effet,les protocoles et la conception des systèmes des VANETs doivent être capables de faireface aux problèmes d’évolutivité et de connectivité. Le réseau doit être en mesure degérer correctement un réseau très chargé, mais aussi de pouvoir maintenir la connectivitélorsque presque aucun véhicule n’est présent. De plus, il doit être capable d’effectuer lepassage de l’une de ces situations à l’autre aisément.

Comme on a pu le voir précédemment, il est nécessaire de catégoriser les messagesdans le réseau. Ce processus ne permet donc pas de garantir une bande passante pourtous les nœuds du réseau. En cas de nécessité, si cela concerne la sécurité, un nœudpeut être déconnecté du réseau. Ces mécanismes sont essentiels pour la sécurité de tous,mais il faut être conscient que sans aucune application de confort, le développementdes VANETs ne serait pas possible. Afin d’optimiser la diffusion de données sur leréseau, la gestion de la bande passante doit être elle aussi étudiée. Ce n’est pas toujoursraisonnable de réduire l’usage du réseau afin de réserver une certaine bande passanteaux messages de sécurité. Pour cela les systèmes se doivent d’être adaptatifs, et le réseaudynamique.

Il existe plusieurs autres leviers sur lesquels on peut jouer afin d’améliorer la diffusionde l’information :

— Adapter la sélection et la transmission des nœuds ;

— Ajuster la puissance de transmission ;

— Ajuster les contraintes de durée de vie et de validité géographique des messages ;

12

— Prioriser les paquets pendant l’accès au support (Media Access Control (MAC)),en créant des messages de donnés périodiques en cas d’incident, pour informer lesnœuds proches de sa vitesse, sa direction, son accélération, etc.

2.2 Contextes d’utilisation

On peut distinguer dans les réseaux véhiculaires mobiles quatre grands types d’uti-lisations : applications de sécurité publique, coordination du trafic automobile, gestiondu trafic routier et applications de confort [5]. Cette section va les détailler.

2.2.1 Applications de sécurité publique

Le rôle des applications de sécurité publique est d’améliorer la sécurité routière, enpermettant d’éviter les accidents et les morts sur les routes. Ces applications se doiventd’être rapides et fiables. Elles doivent être en mesure de faire suivre l’information à tousles véhicules dans une certaine zone, appelée zone de pertinence ou Zone of Relevance(ZOR). On distingue deux types d’applications : application d’évitement de collisionscoopératives, et messages d’avertissement d’urgence.

L’évitement des collisions coopératives a pour but d’éviter les collisions en chaineset les possibilités de collisions en cas de dépassement sur les autoroutes, ainsi queles collisions frontales sur les autres routes. Il est extrêmement nécessaire pour cesapplications d’être très rapide (temps de latence devant être inférieur à 100 ms), ce quin’est pas facile à mettre en œuvre. Idéalement ces applications devraient être capablesde prévenir toutes collisions entre véhicules équipés.

Les messages d’avertissement d’urgence peuvent être instantanés ou à long terme. Lesmessages instantanés disparaissent après leurs diffusions à tous les véhicules présentsdans la ZOR, tandis que les messages à long terme restent présents dans la ZOR tant quele danger est présent. Ces messages ont un niveau de priorité moins élevé et nécessitentdonc des temps de latence moins courts. Cependant des problèmes apparaissent lorsquela ZOR est, soit surchargée, soit vide. En effet en cas de ZOR surchargé, les messages seperdent, se rencontrent ou encore se bloquent, ce qui mène à une surcharge du réseau.Dans le cas où, aucun véhicule ne transite à travers la ZOR et qu’aucune infrastructuren’est à portée, il faut alors être en mesure de prévoir une méthode de maintien dumessage dans le réseau afin qu’il ne disparaisse pas.

13

Ces applications devraient être pour la plupart en mesure d’accéder aux commandeset autres capteurs du véhicule afin de les utiliser à des fins de survies. Par exemple, encas de freinage d’urgence, le temps de réaction du système est plus court que le tempsde réaction du chauffeur. La voiture devrait être en mesure de freiner automatiquement.Ces applications sont importantes dans les réseaux véhiculaires mobiles et doivent êtremises en place par les développeurs du réseau, mais aussi par les manufacturiers. Ellesprésentent un fort taux de danger en cas de piratage du réseau, il est donc extrêmementimportant que ces applications soient hautement sécurisées. Ce point n’est cependantpas abordé dans ce mémoire.

2.2.2 Coordination du trafic automobile

Les applications de coordination du trafic automobile sont les applications d’assis-tances à la conduite. C’est l’analyse de l’environnement qui entoure le véhicule afind’apporter des informations supplémentaires au conducteur. Par exemple, lorsque leconducteur enclenche un flasheur sur autoroute, le système serait en mesure d’alerterle conducteur en cas de présence d’un autre véhicule sur la voie adjacente.

Malheureusement les études menées dans ce domaine utilisent très rarement les stan-dards des réseaux véhiculaires mobiles, et préfèrent des communications plus spécifiquesde très courte portée.

2.2.3 Gestion du trafic routier

Les applications de gestion du trafic routier ont deux objectifs. Le premier est d’ap-porter au conducteur des informations concernant le trafic routier autour de lui ou dansun endroit précis. Ce sont des applications de planification permettant d’emprunter letrajet le plus court vers la destination du véhicule, en prenant en compte le trafic, lesdifférentes routes ainsi que les obstacles ou accidents potentiellement présents sur letrajet. Le principe est le même que pour un GPS avec l’aide des informations, en tempsréel, de tout le réseau. Le deuxième objectif est d’apporter une assistance au niveau desintersections. En effet, en milieu urbain, c’est au niveau des intersections qu’il y a leplus d’accidents (que ce soit avec d’autres véhicules ou bien avec des piétons) [41]. Il y adonc beaucoup de recherche effectuée à ce sujet, surtout au niveau de la communicationavec les feux de circulation. Ces recherches sont menées dans un premier temps, afind’avertir le conducteur de l’état du feu lorsqu’il s’en approche, ainsi que de permettreà la voiture de freiner toute seule en cas de négligence de la part du conducteur. Mais

14

on pourrait aussi imaginer le contrôle des feux par les véhicules d’urgences. C’est uneapplication que l’on retrouve d’ailleurs déjà dans certaines villes [42].

2.2.4 Applications de confort

Les applications de confort sont développées principalement pour divertir les passa-gers, mais aussi à des fins publicitaires et d’information.

Les applications de divertissements permettent et/ou nécessitent un accès Internet.Cet accès peut être effectué à des points stratégiques, comme les stations essences, ouen remontant le réseau jusqu’à un RSU qui serait connecté. En plus de permettre laconnexion Internet, il serait possible par exemple de télécharger du contenu payant,comme des jeux, de la musique ou des vidéos à ces points stratégiques et de pouvoir lespartager ensuite sur le réseau. C’est donc l’accès à Internet, le partage et la messagerieinter-véhicule ou encore les jeux en réseau ou hors ligne, qui seraient permis sur leréseau.

Les applications publicitaires sont destinées aux commerciaux présents sur les bordsdes routes. Ainsi, les hôtels, restaurants, stations essences et autres commerces pour-raient annoncer aux véhicules, dans un certain rayon autour de leur commerce, leurprésence à proximité. Les utilisateurs pourraient ainsi, lorsque nécessaires, consulterle type de commerce présent autour d’eux et sélectionner celui correspondant à leursbesoins.

Ces applications peuvent aussi être informatives. Par exemple, on trouve des appli-cations de gestion du stationnement, en ville ou dans un stationnement sous-terrain,afin d’informer le conducteur des places disponibles prêt de sa position via les donnéesfournies par un RSU [43]. Ce concept est illustré à la Figure 2.3.

2.3 Déploiement

Afin de pouvoir considérer un réseau véhiculaire mobile complet, il faut que tousles véhicules soient munis d’équipements de réception et de transmission, ainsi qued’équipements de calcul et de positionnement GPS. Dans ce contexte, les constructeursautomobiles développent de plus en plus de véhicules possédant au moins un GPS etun certain nombre de capteurs, tels que des radars de recul, de position, et d’autrestechnologies d’aide à la conduite. C’est la première étape de la mise en place des réseaux

15

Figure 2.3 – Aide au stationnement grâce aux VANETs

véhiculaires mobiles. La deuxième étape, qui est déjà en cours de réalisation, est la miseen place du réseau à petite échelle dans plusieurs villes à travers le monde. Ces réseauxsont pour l’instant réservés aux véhicules des services publics (par exemple les voituresde police, de pompier et les transports en commun). Les RSUs sont déployés en petitequantité dans des endroits profitables à ce genre de véhicules (comme les arrêts de bus),et certaines applications parallèles voient déjà le jour. Il y a par exemple la vérificationdu payement de stationnement via les parcomètres qui sont connectés aux réseaux ouencore l’interaction via une application mobile avec les utilisateurs de transports encommun, permettant aux usagers d’obtenir des informations d’horaires ou de retardsen temps réel. L’étape ultime est de mettre en place le réseau pour l’ensemble desautomobilistes. Cette étape ne peut être réalisée que si les manufacturiers mettent envente des véhicules équipés, et si les consommateurs acceptent de les acheter.

Les pays et les industrielles ont mis en place un certain nombre de projets visant à dé-ployer les réseaux véhiculaires mobiles. Ces projets sont nés rapidement après le débutdes recherches sur les réseaux véhiculaires mobiles, et ce en Europe, aux États-Unis etau Japon. La Figure 2.4 présente les principaux projets. De plus, plusieurs universitésont déployé des projets à grande échelle. La plupart sont plus des bancs d’essai que devéritables déploiements. On citera principalement le projet UCLA Campus VehicularTestbed (C-Vet) [44], créé à la University of California, Los Angeles (UCLA),Open-Access Research Testbed for Next-Generation Wireless Networks (ORBIT) [45] à laRutgers University (New Jersey), Car Telecommunications (CarTel) [46] au Massachu-setts Institute of Technology (MIT), Diesel Net [47] à la University of Massachusetts

16

(UMASS), ShangaiGrid [48] en collaboration avec la Shanghai Jiao Tong University(SJTU) et le gouvernement de Shanghai, ainsi que Vanet Testbed [49] à l’UniversitéNationale Chiao-Tung (NCTU) à Taïwan.

Tous ces projets ont l’objectif commun de mettre en place le futur système de trans-port intelligent (Intelligent Transport System (ITS)). En effet, si les réseaux véhiculairesmobiles ont été d’abord conçus pour permettre les communications entre les véhicules,ils seront aussi utiles pour faire la collecte d’information tirée de tous les capteurs,présents ou non dans nos véhicules. C’est le concept de «véhicule intelligent». Cettenouvelle catégorie de véhicules serait équipée de capteurs en tout genre, capable d’ana-lyser, de comprendre et de réagir en fonction de l’environnement qui les entoure. En plusd’apporter des mesures de sécurité (freinage d’urgence automatique ou encore blocagedu volant lors d’un changement de file sur autoroute si la file est occupée), ces véhi-cules seront en mesure de récolter des informations de pollution, de météo, et d’autresdonnées en tout genre, afin de les analyser.

Les véhicules sont équipés d’un ou plusieurs transmetteurs. Pour la plupart des pro-jets, les véhicules sont équipés de deux émetteurs, un réservé pour émettre sur le canalde contrôle, ou Control Channel (CCH) en anglais, et le deuxième pour émettre sur lescanaux de services, appelés Service Channel (SCH) en anglais. De plus, ils sont équipésd’un ordinateur de bord afin de pouvoir traiter l’information. Sur les bancs d’essai, tousces équipements sont souvent installés dans le coffre ou à la place du siège passager. Unconvertisseur de puissance est la plupart du temps nécessaire afin de pouvoir fournirsuffisamment d’énergie aux différents équipements. Les véhicules d’essais ont souventà leur bord un écran de contrôle. On peut facilement imaginer que l’ordinateur dédiéau réseau sera intégré à l’ordinateur de bord, et l’écran de contrôle sera une fonctionde l’afficheur de cet ordinateur, à travers une interface personne-machine simple etconviviale.

2.4 Modèle de Mobilité

Dans cette section, nous allons commencer par présenter les environnements pourlesquelles les modèles de mobilité doivent être développés. Nous présenterons ensuite lesprincipaux modèles qui peuvent être séparés en trois groupes : les modèles analytiques,les modèles physiques ainsi que les modèles empiriques et pilotés par les données.

17

Figure 2.4 – Principaux projets de déploiements et de tests

2.4.1 Environnement de Mobilité :

Les environnements de mobilité se divisent en deux parties : les autoroutes et lesvilles. Sur les autoroutes, les automobilistes ne peuvent se déplacer que dans deuxdirections sur plusieurs voies. On peut regrouper les automobilistes et considérer desnœuds entrants et sortants au niveau des intersections. Les RSUs doivent être puissantset bidirectionnels. Dans les villes, le modèle de mobilité est différent, les véhiculespeuvent tourner très souvent, les unités de bords de routes (RSUs) sont beaucoup plusprésentes (à condition de considérer un réseau grandement déployé avec des RSUs surchaque feu de circulation, parcomètres, et autres infrastructures). On peut cependantidentifier ici encore des patrons de déplacement, en fonction des heures de la journée

18

ou encore des statistiques de circulations.

Afin d’être le plus réaliste possible, un modèle de mobilité doit être en mesure deconnaitre le nombre de voies de chaque route ainsi que leurs directions. De plus, lavitesse, l’accélération et la décélération des véhicules doivent aussi être considérées enfonction du type de route sur lesquels les véhicules circulent. Ensuite, les modèles demobilités doivent prendre en compte l’heure de la journée ainsi que la météo, afin desimuler l’état du trafic dans ces conditions. Le modèle de mobilité devrait aussi êtrecapable de prendre en compte les obstacles à la mobilité, mais aussi à la communicationsans fil, présents sur le réseau. On pense en premier lieu à l’effet gratte-ciel qui empêchela bonne diffusion du signal GPS dans les grandes villes. Enfin, le modèle ne doit passe contenter de prendre en considération seulement les véhicules automobiles. En effet,les conducteurs réagissent à l’environnement qui les entoure : en cas d’obstacle sur laroute ou de confrontation avec des piétons, par exemple.

2.4.2 Modèles analytiques :

Les modèles analytiques sont divisés en deux groupes, les modèles individuels ainsique les modèles de groupes.

1. Modèles individuels :

a) Dans le modèle de mobilité Random Waypoint (RWP), les nœuds bougentaléatoirement, n’importe où, sans aucune restriction. La destination, la vi-tesse ainsi que la direction sont choisies aléatoirement, indépendamment pourchaque nœud. Ces choix sont effectués toutes les x secondes, avec x choisialéatoirement, ou bien lorsqu’un nœud a atteint la destination précédente.Dans ce modèle très simpliste, les nœuds ont tendance à se rassembler ou àpasser régulièrement par le centre de la carte. De plus, aucune route ne peutêtre simulée dans ce modèle. C’est un des modèles les plus simples et facilea implémenter de la littérature.

b) Random Walk (RW) est une version discrète de mouvement Brownien (Mou-vement aléatoire d’une grosse particule dans un fluide). Dans ce modèle onpeut placer des frontières sur lesquelles les particules rebondissent, cepen-dant, il subit les mêmes problèmes que RWP.

c) Random Direction Model (RD) est une amélioration du modèle RWP. Cemodèle évite le phénomène de rassemblement/passage par le centre. Dans cecas la vitesse, direction et destination ne sont pas choisie aléatoirement dans

19

le temps, ils sont reconfigurés aléatoirement une fois que le nœud a atteintsa destination ou bien lorsqu’il a atteint un des bords de la carte. Le choixde la destination, de la vitesse et de la direction sont choisis ici en fonctiondu nombre des voisins.

d) Restricted RWP permet de simuler un modèle un peu plus réaliste. Des zonessont définies, correspondant à des villes. Chaque nœud se déplace alors unnombre de fois aléatoire dans une ville suivant le RW, puis change de villeet recommence.

e) Les modèles basés sur des graphes utilisent des mouvements par contraintes.Le véhicule ne peut se déplacer que selon les arêtes et les bords définis par lacarte. Cela permet une bonne simulation des villes, des routes entre les villes,des autoroutes, etc. C’est donc très intéressant pour simuler le réseau routier.De plus dans ce cas, les trajectoires des nœuds se limitent naturellement auxroutes fréquemment utilisées. Pour Graph-based, le véhicule choisit le cheminle plus court entre sa position et sa destination, et s’y déplace suivant lescontraintes du graphe.

f) Dans le modèle Freeway, la vitesse du nœud dépend du nœud situé devantlui, et ne peut pas être plus grande que cette dernière. Une fois sur une voie,le véhicule ne peut pas en changer. C’est donc un modèle assez limité.

g) Dans le modèle Manhattan les nœuds se déplacent sur une grille et possèdentune probabilité de tourner à droite ou à gauche égale (25 %). Les 50 %restants sont la probabilité de continuer tout droit. Ce modèle subit lesmêmes contraintes de vitesses que le modèle Freeway. C’est un modèle trèsconnu de la littérature pour les réseaux véhiculaires mobiles.

h) Dans le modèle Obstacle, les véhicules se déplacent suivant Restricted RWPdans un graphe défini en fonction des bâtiments présents. Cependant desaméliorations sont à apporter à ce modèle afin que les véhicules ne puissentpas se retrouver au milieu d’un bâtiment.

2. Modèles de groupes :

a) Exponentially Corellated créé des mouvements aléatoires en vitesse, desti-nation et direction, non plus individuellement, mais par groupe. C’est unmodèle très simpliste.

b) Le modèle Colonne définit une ou plusieurs références parmi les nœuds duréseau. Les autres nœuds du réseau se déplacent alors suivant un modèle

20

singulier autour de la référence la plus proche. Les références ne se déplacentque vers l’avant, d’où le nom de Colonne.

c) Dans le modèle de Communauté Nomade, les nœuds se déplacent autourd’une seule référence qui se déplace sur la carte suivant un modèle singulier.Le déplacement se fait donc en groupe sur la carte.

d) Le modèle Purse utilise une référence, suivie par le groupe qui essaye de larattraper à la manière de Policier / Voleur. La référence se déplace là encoresuivant un modèle singulier.

e) Reference Point Group Mobility model (RPGM) est la référence la plus in-téressante des modèles de groupes. Une hiérarchie existe au sein des nœudsdu réseau. Chaque groupe possède plusieurs références dont une agit commecentre logistique de groupe. Elle contrôle le mouvement de toutes les autresréférences du groupe. Les autres nœuds se déplacent de manière singulièreautour d’une référence. Ce modèle est très utilisé dans la littérature.

2.4.3 Modèles physiques :

Les modèles physiques sont des modèles qui ont été observés dans la réalité et modé-lisés afin de créer un modèle fidèle à la réalité. Ces modèles ont surtout été développéspour les mouvements de populations (piétons). On peut en citer plusieurs : HeterogenousRandom Walk, Sociological InteractionMobility for Population Simulation (SIMPS),Self-Similar Least-Action Walk (SLAW), etc. Par exemple, SIMPS utilise deux modesde déplacement ; le mode sociable, et le mode isolation. En fonction de l’état du nœud, ilva être attiré ou repoussé par les autres nœuds à la manière d’un aimant. Ces modèles nesont pas très intéressants pour les réseaux véhiculaires mobiles, car ils reflètent plus lesdéplacements des piétons que ceux de véhicules. On peut tout de même noter le Modèlede la colonie de fourmis, qui est un modèle copiant le comportement des fourmis quicherchent de la nourriture. Ce modèle a été aussi testé pour un protocole de routage [50].

2.4.4 Modèles empiriques et pilotés par les données :

Les modèles énoncés précédemment sont trop simplistes pour permettre aux cher-cheurs de faire des simulations réalistes. Il était cependant important de les présentercar ils sont souvent utilisés comme modèle de base dans les simulateurs existants.

21

Les modèles les plus utilisés par les chercheurs pour les réseaux véhiculaires mobilessont les modèles empiriques, créés à partir de jeux de données de déplacement enre-gistrés sur les routes. Il existe plusieurs bases de données qui permettent d’accéder àce genre de renseignement. Une des plus connues en Amérique du Nord est la basede données Topologically Integrated Geographic Encoding and Referencing (TIGER),entretenue par l’US Census Bureau [51]. Ces données sont extraites du monde réel avecdes contraintes graphiques. La littérature propose de plus en plus de simulateurs demobilité. Cependant le principal problème est qu’ils sont de plus en plus difficiles àutiliser et à configurer du fait de la complexité du problème. En effet, énormément deparamètres sont à prendre en compte si l’on veut pouvoir recréer un modèle suffisam-ment réaliste. Récemment, un nouveau type de rendu de la mobilité très réaliste estapparu, obtenu à travers le Multi-agent Microscopic Traffic Simulator (MMTS), qui estcapable de simuler le trafic public et privé à travers des cartes très réalistes de routesrégionales de la Suisse [52, 53].

2.5 Conclusion

Dans ce chapitre, nous avons vu les caractéristiques principales et spécifiques desréseaux véhiculaires mobiles. Nous avons détaillé les technologies de transmissions, lescontextes d’applications, et aussi présenté des concepts plus généraux tels que la modé-lisation des communications dans les VANETs ou les concepts de mobilité, qui seronttrès importants lors des phases de développement et de tests.

Le chapitre suivant va nous présenter une analyse complète du problème de routagede l’information dans les réseaux véhiculaires mobiles.

22

Chapitre 3

Analyse du problème de routage

Dans ce chapitre, nous effectuons une analyse du problème de routage de l’informa-tion dans les réseaux véhiculaires mobiles (VANETs). Nous allons donc introduire lesprotocoles de routages que l’on retrouve principalement dans la littérature. Ensuite,afin de préparer le lecteur au Chapitre 4, qui présente la mise en œuvre et les résultats,nous allons présenter le principe de fonctionnement du protocole que nous avons utilisépour notre recherche, et nous analyserons ensuite les paramètres à prendre en comptelors de l’établissement ou l’évaluation d’un protocole de routage : les métriques d’envi-ronnement et de performances ainsi que les modèles de trafic et de propagation. Nousprésenterons ensuite une formulation du problème ainsi qu’une analyse des solutions.

3.1 Protocoles de routages dans les VANETs

Afin de présenter les principaux protocoles de routages dans les VANETs, nous avonschoisi de commencer par faire une classification des différents protocoles existant dansla littérature. La section suivante présente donc ces différentes méthodes de routagesintroduisant ainsi les cinq sections suivantes, qui développe les quelques protocoles quenous avons choisi de présenter. En effet, un grand nombre de protocoles de routageexistent dans la littérature [26, 54–59], nous n’avons donc pas pu tous les retenir. C’estaussi dans ce but que nous avons choisi de commencer par une classification.

23

3.1.1 Classification

La classification que nous vous présentons est illustrée à la Figure 3.2. Cependant,elle est issue d’une première analyse du routage de l’information, qui est la suivante :le routage de l’information consiste à diriger les messages du nœud source vers le oules nœuds destinataires, à travers le réseau. Les communications peuvent se faire dedeux manières différentes, directement avec un seul saut (single-hop) ou par étape avecplusieurs sauts (multi-hop). Avec un seul saut, la source et la destination sont en faitconnectées directement l’un avec l’autre, tandis qu’avec plusieurs sauts, la communica-tion se fait via l’intermédiaire des nœuds positionnés entre la source et la destination.Chaque fois que le message passe d’un nœud à un autre, il se déplace d’un saut. Lorsd’une communication multi-sauts, le chemin est choisi en fonction de divers facteurs telque sa longueur, sa bande passante, ou encore sa durée de vie. Cela est valable pourn’importe quel type de routage qui seront présentés ci-dessous.

Ensuite, il existe deux classes de protocoles de routage :

1. le routage Proactif : Les nœuds maintiennent en permanence des tables de routageafin de connaitre la topologie du réseau en tout temps ;

2. le routage Réactif : Les nœuds construisent une table de routage seulement lors-qu’un nœud voisin en fait la demande ou qu’il doit démarrer une transmission.Ils ne connaissent donc pas la topologie du réseau lorsqu’ils sont inactifs.

On peut noter que des techniques de type hybrides existent, par exemple, le protocoleZRP (Zone Routing Protocol) [60]. Ce protocole crée des groupes d’utilisateurs. Leroutage se fait de façon réactive au sein du groupe, et il se fait de façon proactive entreles différents groupes. Ces classes de protocoles coexistent au sein des différents typesde routage, mais nous remarquerons pour les VANETs que c’est le routage réactif quiest le plus utilisé.

Les différents types de routages sont les suivants :

1. le routage Unicast : l’information transite d’un nœud source vers un nœud desti-nataire ;

2. le routage Multicast/Geocast : l’information est transmise d’un nœud source versplusieurs nœuds destinataires précis (Multicast), ou a tous les destinataires pré-sents dans une zone géographique donnée (Geocast) ;

3. le routage de type Broadcast : L’information du nœud source est envoyée à tousles nœuds présents autour de ce dernier.

24

La Figure 3.1 résume ces concepts.

(a) Unicast (b) Multicast

(c) Geocast (d) Broadcast

Figure 3.1 – Les différents types de routages

Ainsi, nous avons divisé les différents protocoles de routages dans les VANETs sui-vant les trois grands types de routage, et nous avons distingué aux protocoles unicasts,en fonction des spécificités des réseaux véhiculaires mobiles et des protocoles qui ontété créés pour eux, trois sous-catégories : les protocoles Ad-hoc, les protocoles baséssur la position et les protocoles de groupes. Dans toutes ces catégories de routage, lasource a été définie unique vers un ou plusieurs destinataire (one-to-many). Cependant,il est possible dans certains cas qu’un nombre multiple de nœuds sources émettent despaquets de données à plusieurs destinations (many-to-many). Ce type de transmission

25

est utile pour le téléchargement de données volumineuses, ou par l’utilisation d’appli-cations spécifiques, comme pour la visioconférence par exemple. Les sections suivantesvont présenter un aperçu des principaux protocoles que l’on retrouve dans chacune deces catégories (cf. Figure 3.2).

Figure 3.2 – Classifications des protocoles de routages dans les VANETs.

3.1.2 Protocoles Unicast Ad-hoc et leurs adaptations pour les

VANETs

Dans la littérature, quatre protocoles reviennent de façon récurrente lorsque l’onparle de réseau ad-hoc mobile. Deux sont proactifs, Dynamic destination-SequencedDistance Vector (DSDV) [61] et Optimized Link State Routing Protocol (OLSR) [62],et les deux autres sont réactifs, Ad-hoc On-Demand Distance Vector Routing (AODV)[63] et Dynamic Source Routing (DSR) [64]. Nous allons maintenant les décrire.

DSDV : Utilisation de l’algorithme de Bellman-Ford afin de trouver le chemin optimaldu nœud source au nœud destinataire. La mise à jour des tables se fait en fonction dutemps (de façon périodique grâce à des timers), ou en fonction d’événement (mauvaisdébit de connexion, délais trop élevés, liens qui disparaissent).

OLSR : Ce protocole définit des nœuds qu’il nomme «multi-relais», seuls ces nœuds pos-sèdent les tables de routage complètes. Cela réduit la diffusion excessive et le gaspillagede la bande passante par rapport au protocole DSDV.

AODV : Ce protocole a été développé pour les MANETs. Lorsqu’un nœud doit com-mencer une transmission, AODV diffuse un paquet de découverte de façon broadcast.La destination va utiliser le chemin emprunté par le premier paquet de découverte qui

26

l’a atteint. Il envoie alors un paquet réponse afin d’annoncer ce chemin à la source.L’envoi de données peut alors commencer. En cas de disparition d’un lien sur le cheminchoisi, un paquet d’erreur est généré.

DSR : Reprends le principe de DSDV (notamment l’algorithme de Bellman-Ford), maisconstruis les tables de routages de façon réactive, et se basent sur l’état des liens. Eneffet, la modification de la table se fait seulement lorsque l’état des liens varie. De plus,il copie l’ID des nœuds traversé dans l’en-tête du message, permettant ainsi au messagede retrouver son chemin vers la source. Il peut ainsi choisir des routes alternatives s’illes considère comme meilleures, et possède ainsi une réactivité plus rapide que celled’AODV en cas de perte de liaison avec un nœud.

Par la suite, les chercheurs ont tenté d’améliorer les performances des protocolesprésentés précédemment afin de mieux les adapter aux réseaux véhiculaires mobiles quiprésentent des spécificités qui leurs sont propres. En effet, DSDV, OLSR, AODV etDSR présentent des performances pour les VANETs qui sont assez pauvres. Ainsi, desprotocoles tels que Predicted AODV (PR-AODV) et PR-AODVM (M pour maximisé)[7] ont été créés. Ces protocoles sont des modifications du protocole AODV pour lesVANETs. Ils utilisent les informations de localisation ainsi que de vitesse des différentsvéhicules afin d’évaluer la durée de vie du lien. Cela permet ainsi au réseau de créer unenouvelle route avant la fin de vie du lien, contrairement au protocole AODV qui attendraque la liaison soit coupée avant de rechercher une nouvelle route. PR-AODVM choisitla route avec la plus grande durée de vie, différemment de PR-AODV qui choisirait defaçon plus classique la route la plus courte ou la plus rapide. On constate une netteaugmentation des paquets délivrés grâce à ces protocoles, cependant ils sont dépendantsde la validité de la prédiction de la durée de vie du lien. Or le réseau est très dynamique,la prédiction n’est donc pas toujours facile à calculer et peut donc être faussée.

3.1.3 Protocoles Unicast de groupe

Le routage par groupe, aussi appelé «Cluster-based Routing» est une technique effi-cace sur les autoroutes. Elle consiste à créer des sous-réseaux virtuels tel que le montrela Figure 3.3 [54]. Chaque groupe élit à sa tête un nœud leader, qui va s’occuper degérer la coordination et le management de communications inter et intra-groupes. Dansun groupe, les communications ne peuvent être que directes (1-hop).

27

Figure 3.3 – Cluster-based Routing

Les deux principaux protocoles basés sur les groupes dans les VANETs sont Clusteringfor Open Inter-vehicular communication Networks (COIN) [8] ainsi que le protocoleLocation Routing Algorithm with Cluster-Based Flooding (LORA_CBF) [9]. COINélit la tête du groupe en fonctions des données de déplacement du véhicule et prendsen compte la distance entre les véhicules. Le deuxième, LORA_CBF défini, en plus destêtes de groupes, des nœuds ponts. Ces nœuds sont chargés de faire la liaison entre lesdifférents groupes, tandis que le nœud tête ne gère que la distribution du message dansle groupe. Cela permet une augmentation de la mobilité. Cette méthode est adaptéeaux grands réseaux, à la différence d’AODV et DSR.

Les protocoles de routage par groupe sont donc souvent de bonne qualité, à unecondition ; que le réseau ne soit pas trop dynamique, c’est-à-dire sur autoroute. Eneffet, en ville, il est difficile de maintenir les différents groupes. Les protocoles d’accueild’un nouveau membre sont gourmands en coût de gestion du réseau (overhead).

3.1.4 Protocoles Unicast basé sur la position

L’idée de protocole basé sur la position pour les VANETs vient naturellement lorsquel’on considère leurs spécificités. En effets, les déplacements des véhicules sont limités parles routes et l’environnement. On peut donc sans trop de difficulté effectuer un grapheen deux dimensions en utilisant les données de positionnement des véhicules afin detrouver le meilleur chemin de routage de l’information entre la source et la destination.Dans les VANETs, la plupart des protocoles utilisent les données de position. Commeon a pu le voir ci-dessus, les protocoles provenant des réseaux ad-hoc sont améliorés enajoutant les données de positionnement des véhicules. On a donc voulu tirer avantagedes spécificités des VANETs en exploitant les coordonnées GPS ainsi que l’utilisationde modèles de mobilités et autres capteurs «on-board». Cette section décrit quelques

28

protocoles dont les algorithmes se basent sur les données GPS afin de transmettrel’information dans le réseau.

Le protocole basé sur la position le plus connue est GPSR [10]. Il repose sur deuxalgorithmes différents : le routage «gourmand» (de l’anglais «Greedy»), qui consiste àenvoyer l’information non pas au nœud le plus proche, ni au dernier nœud dans la zonede transmission, mais au nœud situé le plus proche de la destination ; soit le nœud Esur la Figure 3.4 [65].

Figure 3.4 – Greedy Routing

On appelle «minimum local» un nœud qui ne possède pas d’intermédiaire plus prochede la destination que lui-même. En cas de minimum local, GPSR fait appel au FaceRouting, qui transmet l’information de la source à la destination en essayant de resterle plus proche possible de la ligne imaginaire tirée entre la source et la destination, telque le montre la Figure 3.5 [65].

Figure 3.5 – Face Routing

29

Beaucoup de protocoles utilisés dans les VANETs se basent sur le concept de routagegourmand apporté par GPSR, et tentent d’en améliorer les performances.

Le protocole Greedy Perimeter Coordinator Routing (GPCR) [11], place des nœudsappelés «Coordinateurs» aux intersections. Ainsi le message, une fois arrivé aux abordsde l’intersection, n’est plus envoyé de façon gourmande, mais au coordinateur. Celapermet d’éviter un grand nombre de situations de minimums locaux rencontrés avecGPSR. On remarque sur la Figure 3.6 [54], que N3 est un minimum local du protocoleGPSR. Grâce à GPCR, le message est envoyé à C1, le nœud coordinateur, qui lui n’estplus un minimum local.

Le protocole de routage GPSRJ+ [12] est basé lui aussi sur GPSR, mais il prend encompte les voisins de deuxième niveau. S’il existe un voisin allant vers la destination eta portée, le message lui est directement envoyé. Sinon, il utilise la méthode de GPSRde façon normale. Cela réduit le nombre de sauts lors des transmissions et augmente leratio de livraison des paquets. En revanche, ce protocole rencontre des problèmes avecles applications sensibles aux délais : cela prend du temps d’aller chercher et analyserles données des voisins de second niveau.

Figure 3.6 – GPCR Routing

Une autre technique de routage unicast dans les VANETs consiste à placer des«ancres» à des points stratégiques (intersection ou accidents par exemple). Ils néces-sitent donc une connaissance de la carte, ce qui peut être vu comme un inconvénient.Plusieurs protocoles utilisent cette technique, tel que Anchor-based Street and TrafficAware Routing (A-STAR) [13], Connectivity Aware Routing protocol (CAR) [15] ouencore Diagonal Intersection based Routing protocol (DIR) [14].

30

3.1.5 Protocoles Broadcast

Les protocoles basés sur la diffusion (broadcast) ne sélectionnent plus un nœud enparticulier à qui transmettre l’information. Elle est envoyée du nœud source vers tousles nœuds du réseau. Cette méthode est beaucoup utilisée dans les VANETs, et utilise leplus souvent la méthode d’inondation («flooding» en anglais). Cette méthode consisteà envoyer le message à tous les nœuds qui sont à portée de transmission, et chaquenœud réitère l’opération pendant un temps donné. L’inondation est efficace dans desréseaux de petite taille, mais mène rapidement à une surcharge du réseau lorsque celui-ci est grand. En effet, les messages sont envoyés et reçus plusieurs fois par les mêmesnœuds de façon tout à fait inutile. Les protocoles proposés pour les VANETs utilisentla méthode d’inondation, tout en essayant d’en corriger les inconvénients.

On peut citer ici le protocole BROADCOMM [16], qui crée des clusters temporaires,et les messages sont disséminés en n’utilisant l’inondation qu’entre les nœuds qui sontles têtes de groupes. Ces nœuds se chargent alors de retransmettre l’information au seinde leurs groupes respectifs.

D’autres, comme Vector-based TRAcking DEtection (V-TRADE) et History-enhancedV-TRADE (HV-TRADE) [17], utilisent la position ainsi que le mouvement des nœuds.Ils divisent le réseau en plusieurs petites zones et sélectionnent ensuite les nœuds auxfrontières de ces zones de transmission, puis les inondent en rapportant le message aucentre.

Un protocole qui n’utilise pas la méthode d’inondation est le protocole DistributedVehicular Broadcast (DV-CAST) [18]. Ce protocole contrôle l’état des véhicules voisins(données locales). Cela permet de connaître la vitesse et la direction des véhicules auxalentours.

Secure Ring Broadcasting Routing Protocol (SRB) [19] lui, réduit le nombre de trans-missions et augmente la stabilité des routes. Pour cela, il divise les véhicules du réseauen trois groupes en fonction de leurs distances au nœud qui transmet : les véhiculesprès, les véhicules loin et les véhicules à distance désirable. Il ne transmet l’informationqu’au véhicule appartenant à ce dernier groupe.

31

3.1.6 Protocoles Multicast et Geocast

Les protocoles Multicast / Geocast diffusent le message, non plus d’une source versun destinataire (Protocole Unicast), ou plusieurs destinataires (Protocole Multicast),mais d’une source vers une destination géographique. La zone desservie peut aller dequelques mètres à plusieurs kilomètres. Le plus souvent, la méthode utilisée sera l’inon-dation, mais de façon localisée dans la Zone of Relevance (ZOR). Là encore, la plupartdes protocoles tentent de réduire la surcharge du réseau causé par l’inondation. Nousprésentons ci-dessous quelques protocoles utilisant ces principes.

Le protocole Inter Vehicular Geocast (IVG) [20] met en place un temps d’attenteavant de rediffuser les messages. Si durant ce temps d’attente il ne reçoit pas à nouveauce même message, alors il le transmettra aux nœuds qui l’entourent. Ce temps d’attenteest proportionnel à la distance entre le nœud dont il a reçu le message et lui-même. Deplus, il limite le nombre de sauts qu’un message peut effectuer. Cached Geocast [21]ajoute des informations dans l’en-tête du message en cas de rencontre d’un minimumlocal. Cela permet d’éviter de repasser par cette route. Il prend en compte les change-ments fréquents de voisinages. Afin d’éviter la perte de connexion au moment ou unnœud sort de la zone de transmission du nœud source, le rayon de transmission réel estchoisi inférieur au rayon de transmission possible. Spatiotemporary Multicast/GeocastRouting Protocol [26], est un des seuls protocoles à utiliser en plus des variables dedistance et de déplacement, la variable temps. Ajouté à la ZOR, cette variable permetde transmettre les messages seulement si le véhicule est dans la ZOR à un temps t,sinon le message n’est pas transmis. Le même processus est mis en place pour la Zoneof Forawarding (ZOF) : zone dans laquelle les nœuds qui reçoivent le message sontautorisés à le retransmettre.

3.2 Principe de fonctionnement du protocole AODV

Le protocole Ad-hoc On-Demand Distance Vector Routing (AODV) [63], utilisequatre types de messages afin de construire et contrôler l’état des liens lors d’unecommunication : RREQ, RREP, HELLO et RERR. Le message de requête (RREQ) estdiffusé par le nœud source afin de découvrir le réseau. Le message de réponse (RREP)est initié par le nœud destination ou par un nœud qui connait le chemin jusqu’à ladestination afin de rapporter à la source les informations à propos du chemin choisi.Ce processus est illustré à la Figure 3.7. Ensuite, les messages HELLO permettent decontrôler l’état de chaque lien de la route établie. Les messages HELLO sont générés

32

seulement par les nœuds qui font déjà partie de cette route et ont une durée de vie d’unseul saut. Trois messages HELLO sont envoyés simultanément, de manière périodiqueentre chaque pair de nœuds de la route choisi. En cas de non-réception d’un de ces troismessages, le lien est considéré comme non-utilisable et un message d’erreur (RERR)est initié par le nœud qui l’a découvert. Ce concept est illustré à la Figure 3.8.

Figure 3.7 – Méthode de construction d’une route

Un paquet, qu’il soit de données ou de contrôle (par exemple les messages RREP etRREQ utiliser pour établir la route), possède un numéro d’identification unique. Cenuméro est dépendant du temps : le paquet avec le numéro le plus élevé est le paquetle plus récent. On appelle cela le numéro de séquence. Ce procédé est très utile pourle routage de l’information. Par exemple, si le nœud source reçoit plusieurs réponses,il choisira d’écouter celle qui possède la route la plus à jour (c’est-à-dire celle qui ale numéro de séquence le plus élevé). De plus, dans le cas de réseaux VANETs où lamobilité est élevée, et l’état des liens est souvent modifié, ce procédé est très utile.

Le protocole AODV utilise le principe des numéros de séquences afin de contrôler siles liens utilisés pour atteindre la destination sont suffisamment à jour. Chaque nœudpossède un numéro de séquence qu’il incrémente à chaque fois qu’il reçoit des informa-

33

Figure 3.8 – Principe de détection d’un lien défaillant

tions utiles de la part des messages RREQ, RREP ou RRER. Cela permet à chaquenœud du réseau de valider si la route qu’il connait vers la destination est bien la bonne.Lors de la réception d’un message RREQ ou RREP, les nœuds exécutent une série devérification afin de contrôler que la table de routage qu’il possède est la meilleure. Cesdécisions sont prises en fonction du numéro de séquence ainsi que du nombre de sautsentre le nœud et la destination. Les figures 3.9 et 3.10 présentent des organigrammesafin d’illustrer les décisions prises par un nœud lorsqu’il reçoit un de ces messages. Enrésumé, le nœud qui reçoit le message (A sur les figures) compare les données de satable de routage avec les données du message et agit ensuite en conséquence.

34

3.3 Paramètres

Afin de concevoir et d’évaluer les performances d’un protocole de routage, plusieursparamètres sont à prendre en compte. Ce sont les métriques d’environnement et deperformances, ainsi que le modèle de propagation et le modèle de trafic. Cette sectionva les détailler.

3.3.1 Métriques d’environnement

Les métriques d’environnement sont les paramètres qui définissent le contexte danslequel les véhicules circulent, ainsi que les éléments qui caractérisent leurs déplacements[66]. Cela prend en compte :

1. Le type de route (ville, autoroute, campagne) ;

2. Les obstacles au déplacement des véhicules (par exemple les arrêts ou les feux decirculation) ;

3. Les différents obstacles présents dans l’environnement de simulation (par exempleles bâtiments ou le paysage) ;

4. Les paramètres de déplacement des véhicules (comme leur vitesse, leur accéléra-tion et décélération, les limitations de vitesse, ou encore la densité de véhicules) ;

5. Les distances entre les véhicules ;

6. Les paramètres de sécurité (par exemple la décélération maximum et la distanced’arrêt d’un véhicule en cas d’urgence) ;

7. Les obstacles mobiles : un véhicule peut faire obstruction à la communicationentre deux autres véhicules.

Ces différentes métriques d’environnement sont des paramètres dont certains peuventêtre fixés pour toutes les simulations (comme le type de route ou les obstacles fixes)ou choisis pour chaque simulation (le nombre de véhicules et la vitesse de déplacementdes véhicules par exemple). Le point 7, lui, ne peut pas être fixé. C’est un paramètre àprendre en compte lors des simulations.

35

3.3.2 Métriques de performances

Afin d’évaluer correctement un protocole de routage, il est important de prendre encompte un certain nombre de métriques de performances. On peut les classer en deuxcatégories : les métriques de performances telles que le délai moyen de bout en bout, leratio de livraison des paquets et le débit, et les métriques de contrôle, tel que nombrede sauts moyen et le taux d’information de contrôle.

1. Le délai moyen de bout en bout, c’est-à-dire la mesure du délai entre l’envoidu message par le nœud source et sa réception par le nœud destinataire, est leparamètre principal que l’on vise à améliorer lors de l’évaluation d’un protocolede routage. Un bon protocole à des délais moyens de bout en bout qui sont lesplus bas possible. Le délai moyen de bout en bout d’un paquet i entre une pairede nœuds Source-Destinataire est :

D_AETEi = T_DataRi − T_DataSi (3.1)

Avec D_AETE le délai moyen de bout en bout, T_DataR le temps au momentde la réception du paquet par le nœud destinataire D, et T_DataS le temps aumoment de l’émission du paquet par le nœud source S. On fait ensuite la moyennepour chacun des paquets envoyés par chaque pair de nœuds tout au long de lasimulation, afin d’obtenir le délai moyen de bout en bout, soit :

D_AETE =1

N

N∑i=1

(T_DataRi − T_DataSi) (3.2)

Avec N, le nombre total de paquets reçus pendant la simulation.

2. Le taux de livraison des paquets : Packet Delivery Ratio (PDR) calcul le rapportentre le nombre de paquets reçus par le nœud destinataire et le nombre de paquetsenvoyés par le nœud source. Le PDR est compris entre 0 et 1. On le calcul pourchaque pair de nœuds Source-Destinataire puis on fait la moyenne. On peut lemultiplier par 100 si l’on souhaite obtenir un pourcentage. L’équation finale ducalcul du PDR est la suivante :

PDR =1

C

C∑1

nombre de paquets reçunombre de paquets envoyés

(3.3)

36

avec C le nombre de paires Source-Destination ayant communiqué pendant lasimulation.

3. Le débit (Throughput), correspond au ratio entre le nombre de paquets envoyéset le temps qui a été nécessaire à leurs transmissions. Afin de l’exprimer, on utilisela taille des paquets en bits. Le résultat est donc en bits/secondes. Le standardDSRC/WAVE annonce des débits théoriques allant de 3 à 27 Mbits/s dans unrayon de 1 000 m autour du véhicule source [32]. On calcul le débit moyen pourtoute la simulation à l’aide de la formule suivante :

Debit =n∑

i=1

taille du paquetitreception − temission

(3.4)

avec n, le nombre de paquets de données qui ont été reçus par les nœuds destina-taires.

4. Le coût de gestion du routage normalisé : Normalized Routing Overhead (NRO),est un ratio qui permet d’obtenir une bonne évaluation de la bande passanteutilisée par les paquets de données qui ont atteint leurs destinations. En effet,c’est le ratio du nombre de paquets de contrôle transmis par rapport au nombrede paquets de données reçus :

ρ =

∑Ni=1Ci∑N

i=1Ci +∑N

i=1Di

(3.5)

Avec i le numéro d’identification du paquet, Ci le paquet de contrôle i, Di lepaquet de données i ayant atteint la destination et ρ le coût de gestion normalisé.

5. Le nombre de sauts moyen entre la source et la destination. C’est la moyennedu nombre de sauts qu’il a été nécessaire de réaliser pour chaque paquet afind’effectuer le chemin entre la source et la destination, ou en d’autres termes, lenombre de nœuds que le paquet a traversé avant d’atteindre la destination.

Ces différentes métriques permettent d’évaluer de façon globale la validité d’un proto-cole de routage dans un réseau.

37

3.3.3 Modèle de trafic

Le trafic multimédia doit être généré par le simulateur. Dans un réseau, plusieursprotocoles sont utilisés en fonction du type de trafic nécessité par l’utilisateur (voix,données ou vidéo). Un des protocoles les plus connus est le protocole File Transfer Pro-tocol (FTP). Il est surtout utilisé afin de transférer des données entre les utilisateurs.Lors d’une simulation d’un réseau, un protocole très utilisé est le protocole ConstantBit Rate (CBR). Il génère un trafic constant que l’on peut choisir en fixant deux pa-ramètres : la taille des paquets émis, ainsi que le taux de transmission de ces paquets.Les performances obtenues avec ce protocole permettent de se faire une bonne idée desservices qui vont pouvoir être utilisés par le réseau simulé. Ce protocole est utilisé auniveau application du modèle OSI [67].

Au niveau de la couche transport de ce modèle, les protocoles Transmission ControlProtocol (TCP), User Datagram Protocol (UDP) ou encore Real-time Transfer Protocol(RTP) peuvent être modélisé avec le simulateur que nous utilisons. Tous ces protocolessont détaillés dans le manuel d’utilisation du simulateur [68].

Pour le modèle de file d’attente, les méthodes de gestions de file d’attente proposéespar le simulateur sont principalement : DropTail (First In First Out (FIFO)), RandomEarly Discard buffer management (RED), Class Based Queuing (CBQ), Fair Queuing(FQ), Deficit Round Robin (DRR), ou encore Joint Buffer Management Scheduling(JoBS). Ces méthodes ne seront pas décrites ici. Peu de protocoles nous donnent laméthode utilisée, et beaucoup utilisent la méthode la plus simple de FIFO qui consisteà envoyer en premier les paquets qui sont arrivés en premier.

Les modèles de la couche physique, de la couche liaison et de la sous-couche MAC sontaussi définis par le simulateur. Plusieurs modèles sont implémentés par le simulateurque nous utilisons.

Tous ces modèles sont détaillés dans le manuel d’utilisation du simulateur [68]. Lesmodèles utilisés sont détaillés à la Table 4.1.

38

3.3.4 Modèle de propagation

On trouve différents modèles de propagation dans la littérature. Il en résulte queplusieurs paramètres sont à prendre en compte afin de simuler un modèle réaliste. Dansun premier temps, la distance entre les véhicules est évidemment un paramètre de base àprendre en compte. Ensuite, il faut être en mesure de simuler les différents obstacles, quece soit les bâtiments qui annulent ou reflètent le signal, ou les arbres qui se contententde le réduire. Dans tous ces cas, un modèle d’atténuation doit être établi, et il estnécessaire de prendre en compte les spécificités des VANETs : les antennes émettriceset réceptrices sont dans les véhicules, donc plus près du sol que la plupart des autresantennes pour lesquelles des modèles similaires ont déjà été établis. Les trois modèles depropagation qui sont implémentés dans le simulateur que nous utiliserons par la suitesont Free space model, Two-ray ground reflection model et Shadowing model.

— Free space model (modèle de l’espace libre) est le modèle le plus simple. Il consi-dère que la transmission se fait de façon directe sans aucun obstacle, réflexionsou effets perturbateurs. Seule la distance entre l’émetteur et le transmetteur estprise en compte ;

— Two-ray ground reflection model (modèle à deux rayons, directs et par le sol)considère deux rayons, le rayon de transmission direct ainsi que le rayon qui seréfléchi sur le sol, comme le montre la Figure 3.11, à condition que les antennessoient séparées d’une distance minimale appelée distance de croisement. Avantcette distance, le modèle de propagation de l’espace libre est utilisé. La puissancedu signal prédite par ce modèle suit l’équation :

Pr(d) =

PeGeGrh

2eh

2r

d4Lif d ≥ crossover_dist

PeGeGrλ2

(4πd)2Lif d < crossover_dist

(3.6)

avec Pr(d) la puissance reçue calculée en fonction de la distance, Pe la puissanceémise, Ge, Gr, he et hr, respectivement le gain de l’antenne émettrice et réceptriceainsi que leurs hauteurs, L est le facteur de perte et d la distance entre les deuxantennes. λ est calculé en fonction de la fréquence f et de la célérité de l’onde ctel que :

λ =c

f(3.7)

39

et la distance de croisement est définit par :

crossover_dist =(4πhthr)

λ(3.8)

À titre indicatif, avec les paramètres de base du simulateur utilisé par notrerecherche, la distance de croisement est d’environ 86 m ;

— Shadowing model est le modèle de prise en compte des effets de masques. Laprobabilité pour un nœud de recevoir le message ne dépend plus seulement dela distance entre l’émetteur et le récepteur, mais aussi l’effet de perte de trajet(path lost model) qui met en jeu un paramètre aléatoire.

Figure 3.11 – Modèle de propagation Two-ray ground.

3.4 Formulation du problème

Afin de formuler le problème de routage de l’information dans un réseau véhiculairemobile, nous avons choisi dans un premier temps d’annoncer les notations que nousallons utiliser pour ensuite présenter les données et les variables du problème, puis lesobjectifs et finalement les contraintes.

Dans un article scientifique, la formulation du problème est souvent une étape quin’est pas effectuée, faute de place. On remarque alors que les environnements ne sontpas toujours propres aux VANETs. Certes, la mobilité des nœuds est augmentée, les vé-hicules suivent les routes définies par une carte tirée de la vie réelle, mais ces protocolesn’utilisent que trop rarement les communications de types Vehicle to Infrastructure(V2I). En effet, nous avons vu au Chapitre 2 que les VANETs sont des réseaux ad-hoc qui utilisent de manière opportuniste les communications avec des infrastructures,quand ces dernières sont disponibles. Il est donc nécessaire de prendre en compte la

40

réalité de déploiement des réseaux véhiculaires mobiles et de simuler un nombre raison-nable d’unités de bords de routes capables de retransmettre l’information et d’accéderà Internet. La formulation permet ainsi de bien définir le contexte du problème.

Pour formuler notre problème, les notations suivantes sont utilisées :

N : l’ensemble des n véhicules ;K : l’ensemble des k infrastructures ;c : la sensibilité de réception et de transmission des véhicules ;d : la sensibilité de réception et de transmission des RSUs ;l : la longueur de l’autoroute sur laquelle les véhicules circulent ;x : le nombre de voies des routes empruntées ;v : la vitesse des véhicules ;vmin : la vitesse minimum autorisée sur autoroute ;vmax : la vitesse maximum à laquelle les véhicules peuvent se déplacer ;p : le nombre de paquets généré par secondes par les véhicules sources ;b : la taille des paquets générés (en bit) ;L = (i, j)\i est connecté à j : la collection de m liens entre les pairesde nœuds qui communiquent entre eux ;D = Dl ∈ L : l’ensemble des débits des liens ;s : le nombre de sauts nécessaire au nœud i pour atteindre le nœud j ;tmoy : le délai de bout en bout moyen des paquets pour être acheminé des véhiculessources aux véhicules destinations ;tmax : le délai maximal acceptable ;PDR : le ratio de livraison des paquets (Packet Delivery Ratio) ;NRO : le taux d’information de contrôle.

Le problème de routage peut alors être formulé comme suit :

Étant donné :

c, l, x, L, p, b

En fonction de :

n, k, d, v

Les objectifs sont de :

— Réduire tmoy

— Améliorer le PDR

41

— Observer et prendre en compte s, D et NRO.

Sous les contraintes :

tmoy ≤ tmax (3.9)

vmin ≤ v ≤ vmax (3.10)

Les véhicules se déplacent sur l’autoroute (3.11)

Les infrastructure sont situé au bord de l’autoroute (3.12)

Selon ITU (International Telecommunication Unit), le délai maximum acceptablepour la plupart des applications est de 150 ms. Entre 150 et 400 ms, le délai est accep-table, mais gênant pour l’utilisateur. Ce type de délai peut être accepté à condition quesa durée soit limitée ou qu’il soit géré par l’application afin d’en réduire les effets né-fastes. Au-delà de 400 ms, les délais sont inacceptables pour la plupart des applications[69]. On pose donc dans notre recherche tmax = 400 ms.

Le plus souvent, les objectifs à réaliser consistent à améliorer les performances desmétriques d’un protocole par rapport aux métriques d’un ou plusieurs autres.

3.5 Analyse des solutions

L’analyse des solutions est définie ici. Les solutions proposées par la littérature n’ap-portent pas de réponses idéales à la formulation de notre problème. Les VANETs ontdes spécificités qui leurs sont propres. Les protocoles de routages de l’information créésafin d’optimiser les délais ainsi que le taux de livraison des paquets dans ce type deréseaux ne prends malheureusement en compte que trop peu souvent la totalité deces caractéristiques. C’est le cas par exemple des protocoles présentés dans ce chapitre[7–21, 26], notamment en ce qui concerne les différents types de communications dansles VANETs. En effet, ces protocoles sont créés pour les VANET mais n’exploitentpas leurs spécificités. Cependant, quelques protocoles répondent un peu plus à notreformulation. Ces protocoles utilisent les deux types de communications : V2V et V2I.Les RSUs sont donc partie intégrante de leurs simulations, et c’est cette spécificité,qui nous paraît essentielle à la réalisation d’un VANET, qui a retenu notre attention.Les solutions apportées par ces protocoles [22–25], sont analysées dans les paragraphessuivants.

42

Static-node-assisted Adaptative data Dissemination in Vehicular networks (SADV)[23], utilise le routage gourmand et redirige l’information à un RSU en cas de minimumlocal. Le RSU garde alors le message en mémoire jusqu’à ce qu’il détecte un cheminoptimal. Les délais de transmissions sont diminués et le ratio de livraison des messagesest augmenté. Les RSUs contiennent les informations de position des véhicules ainsique les cartes de l’environnement. Ce protocole est performant dans les situations «ex-trêmes» de circulation : dense et faible. Ici, Ding and Xiao utilisent le logiciel Matlabpour effectuer leur simulation. La sensibilité de tous les nœuds est de 200m pour 50,100, 150, 200, 250 et 300 véhicules se déplaçant entre 40 et 105 km/h, dans une aire de4000 m x 5000 m comportant 70 intersections. La taille des paquets de données est de1024 bytes, mais l’article ne donne pas de précision sur le type de paquets transmis.

Infrastructure Assisted Geo-Routing [22], utilise une représentation graphique duréseau qui peut être adapté à tous protocoles qui connaissent la topologie de la carte.Infrastructure Assisted Geo-Routing considère que tous les RSUs forment un seul nœud.En effet, ils sont tous connectés entre eux de façon filaire (idéalement) et possèdentdonc un temps de transmission entre eux qui est court. Cela permet aux algorithmesde prendre des décision de routage, sans perte de temps à calculer les distances, bandespassantes, etc. entre les différents RSUs. Cependant, ce protocole ne prend pas encompte les directions et densités de véhicules, qui pourrait lui permettre d’être plusperformant. Borsetti and Gozalvez utilisent The Network Simulator 2 (NS-2), le modèlede transmission est très complet, mais les puissances de transmissions simulées ne sontpas fournies. Les véhicules se déplacent entre 0 et 50 km/h dans une aire de 1000 m x1000 m de type Manhattan (intersection tous les 250 m). Le nombre de véhicules estexprimé en densité (véhicules/kilomètres/voies), allant de 2 à 12. Le nombre de RSUssimulé est 2 ou 4. Les auteurs comparent GSR, GSR avec 2 RSUs, GSR avec 4 RSUs,GPSR et CBF.

Le protocole Mobile Infrastructure Based VANET Routing protocol (MIBR) [24],considère que les bus sont équipés de matériel de réception et de transmission pluspuissant. Ils sont dans ce modèle équipés de récepteurs/transmetteurs WiMax qui per-met des débits et des rayons de transmissions plus élevés. Cependant, l’efficacité duWiMax en cas de grande mobilité est réduite. Les bus étant limités à une vitesse nedépassant souvent pas 90 km/h, le modèle est considéré comme réaliste. Les bus for-meraient donc entre eux un réseau backbone (partie du réseau supportant la grandemajorité du trafic grâce à ces performances de transmissions). Le protocole sélectionne

43

alors la route avec le minimum de sauts et passant par les nœuds les plus proches de ladestination. Cela améliore les performances du réseau, le ratio de livraison des paquets,ainsi que les débits et bandes passantes du réseau. Cependant, aucune infrastructurefixe n’est simulée. Luo et al. utilisent également NS-2 pour leur simulation. Le rayonde sensibilité des véhicules est de 150 m, et les bus possèdent soit la même sensibilité,soit deux canaux ayant une sensibilité de 150 et 300 m. La carte utilisée est réelle (Sudde Pékin) et de taille 1700 m x 1000 m. Les véhicules sont au nombre de 100, 150,200, 250 avec une proportion de bus de 20 %. Ils se déplacent entre 0 et 100 km/h.Les transmissions sont de type CBR, dont les paquets ont une taille de 512 bytes etle taux d’envoi des paquets est de 128 bytes/s. 20 communications sont générées parsimulation. Les simulations durent un total de 600 s. Le protocole comparé est GPSR.

Mobile Gateway Routing Protocol (MGRP) [25], va encore plus loin en intégrant auréseau backbone formé par les bus, les taxis, les véhicules de sécurités, les véhiculesprofessionnels, etc. Dans ce modèle, la communication se fait à l’aide des technologiesDSRC pour les communications V2V, et grâce à la 3G pour le réseau backbone. Deplus, un contrôleur connecté aux antennes du réseau 3G (Base station), optimise lescommunications. Les positions des véhicules et cartes de l’environnement sont aussiutilisées pour les améliorer. Ce protocole est proactif, ce qui est un de ses plus grandsdéfauts. Pan et al. utilisent là encore le simulateur NS-2 pour leur simulation. Les 150véhicules simulés se déplacent entre 40 et 90 km/h sur une carte de 1100 m x 1100 m.Ils utilisent 10 transmissions de type CBR avec des tailles de paquets de 512 bytes etla sensibilité de transmission des informations est de 250 m.

Les limitations que créent les protocoles présentés ci-dessus, et qui nous ont amenéà effectuer notre recherche sont les suivantes :

1. Les technologies de transmissions utilisées :Dans les réseaux véhiculaires mobiles, si on décide de suivre ce qu’il se fait dansla littérature pour ce type de réseaux, il est d’usage d’utiliser les communicationsDSRC/WAVE proposées par le standard IEEE 802.11p. Pour l’évaluation d’unprotocole de routage, l’utilisation exacte de cette technologie n’est pas essentielle,mais il reste préférable, si l’on veut rester dans l’idée d’un VANETs, de n’utiliserqu’un type de transmission. L’ajustement des puissances des différentes antennesémettrices (celles des véhicules et celles des infrastructures), peut être effectuécomme le font Luo et al. L’utilisation de plusieurs technologies de transmissions,

44

comme le font les auteurs de [25] ne semble pas être une mise en œuvre idéale desVANETs.

2. Le type de scénario simulé :Les protocoles présentés ci-dessus sont unicast, et ils utilisent les infrastructuresde communications dans des réseaux véhiculaires mobiles. Ce sont les principauxprotocoles connus de cette catégorie, et ils ne sont testés que dans des scénariosurbains. Il existe un grand nombre de protocoles plus récent qui opèrent dans lesréseaux véhiculaires mobiles sur autoroutes, mais ce ne sont pas des protocolesunicast. La plupart sont des protocoles broadcast qui tendent à résoudre les pro-blèmes dus au flooding engendré par ce type de routage. Seul [25] mets en place unscénario sur autoroutes, mais ne présente que très peu de résultats par rapportà ce scénario. C’est pourtant dans ces conditions, où les temps de trajets sontsouvent les plus longs, que les passagers seraient amenés à profiter des VANETsafin de communiquer avec les véhicules alentour à des fins de divertissement, touten assurant des délais de livraison suffisamment rapides pour être utilisés à desfins de sécurité routière.

3. Le manque d’information des paramètres de simulations :Chacun des protocoles présentés ci-dessus utilise plusieurs paramètres de simu-lations, et certains sont plus exhaustifs que d’autres, cependant on remarqueune tendance générale pour un manque d’information, menant à quelques doutesquant à la validité des résultats obtenus. Borsetti and Gozalvez et Ding and Xiaone fournissent pas d’informations sur le type de modélisation du trafic. De plus,Borsetti and Gozalvez ne fournissent pas la sensibilité de transmission des véhi-cules ni des infrastructures.

4. La modélisation des infrastructures :Lors de la définition d’un réseau véhiculaire mobile, on consent à utiliser des in-frastructures de communication fixes placées en bord de route, spécifiques auxcommunications pour les VANETs. Or, Luo et al. et Pan et al. utilisent des in-frastructures différentes. Luo et al. considère les bus comme infrastructure decommunication pour les VANETs, qui ne sont alors plus fixes. Ce type de solu-tion pourrait être un support supplémentaire aux infrastructures fixes, mais nedevrait pas être considéré comme un remplacement. De même, Pan et al. utiliseles bus et taxis comme véhicules intermédiaires pour atteindre des infrastructuresdu réseau cellulaire mobile, qui ne sont pas spécifique aux VANETs, et néces-site un coût de déploiement supplémentaire, obligeant ces véhicules «ponts» à semunir d’un abonnement adéquat.

45

5. La stratégie par rapport au routage avec les infrastructures :Kizilrmak and Torkamani-Azar ont montré dans leur recherche que le routagepar les infrastructures réduit les probabilités de collisions et donc augmente laprobabilité de réception des paquets, soit le ratio de livraison des paquets. Lastratégie utilisée par Luo et al. utilise cette stratégie avec les bus et montre desrésultats prometteurs. Pan et al. va utiliser les infrastructures à condition qu’unvéhicule «pont» se trouve sur le chemin du paquet entre la source et la destina-tion. Les auteurs de [22] et [23] utilisent des infrastructures fixes, mais ne nousinforment pas de la stratégie adoptée en condition normale de situation. En effet,Ding and Xiao nous explique que les véhicules qui ne trouvent pas de voisin déci-dera d’envoyer le paquet à l’infrastructure qui pourra le sauvegarder en attendantde trouver un nouveau véhicule se dirigeant vers la destination. C’est un cas decirculation extrême où la densité de véhicules est très faible, mais ce n’est pas uncas de condition normale de circulations.

46

04/12/2014 13:24

Page 1 sur 2https://cacoo.com/diagrams/editor/printsvg?index=0

Le noeud A reçoit un message RREQ

Faire suivre le message RREP

Envoyer un message RREP

Le Message RREQ a été reçu récemment

OULe noeud A est la

source

Le noeud A connait la

route vers la source

Le noeud A connait une route plus récente

OULa route à le même numéro

de séquence mais son nombre de sauts est moins

élevé

Créer une entrée pour la route inverse

Mettre à jour la route

Le noeud A est la

destination

Le noeud A connait une route à jour

vers la destination

Oui

Oui

Abandonner le paquet

Oui

Oui

Non

Non

Non

Non

Oui

Non

Figure 3.9 – Traitement des messages RREQ

47

������������� ����

�������������������

�����������

�������������������

����������������

�������������������

��� �����������

����� �����������

��������������

������ ��������

�����������

�����������������������

����������������

��

�������� ���� ! ��

�� ��������������� ����

������ "���������������

����������

#����� ������������

��� ������������

���������������

�������

���

���

���

$��

$��

$��

Figure 3.10 – Traitement des messages RREP

48

Chapitre 4

Mise en œuvre et résultats

Dans ce chapitre, nous allons présenter la mise en œuvre et les résultats de différentsscénarios pour le protocole AODV ainsi que notre modification du protocole, dans lecas d’une flotte se déplaçant le long d’une autoroute. Nous commencerons par présenternotre solution à la Section 4.1. Cette section se divisera en trois parties : en premier lieu,nous décrirons notre solution, nous justifierons notre choix, puis nous définirons l’envi-ronnement de simulation ainsi que les paramètres d’entrées. Ensuite, nous présenteronsnotre plan d’expérience, les résultats ainsi que leurs analyse à la Section 4.2.

4.1 Modification du protocole AODV

La solution que nous proposons consiste à mettre en œuvre une adaptation du proto-cole de routage AODV, initialement conçu pour les MANETs, dans le cas où le réseausimulé est un VANET. Pour cela, nous allons commencer par justifier notre solution,puis nous présenterons l’environnement de simulation que nous avons choisi d’utiliserpour notre travail, et enfin nous détaillerons la configuration des paramètres d’entrées.

4.1.1 Présentation de notre solution et Justification

Notre solution comporte deux parties, que nous allons dans un premier temps pré-senter, puis ensuite justifier.

Dans un premier temps nous proposons d’évaluer les performances d’AODV en fonc-tion du nombre de RSUs, mais aussi en fonction de la sensibilité des RSUs. Pour cela,nous ajoutons progressivement des RSUs à notre scénario, et nous effectuons les si-mulations avec deux paramètres de sensibilité différente pour les RSUs. Ensuite, nous

49

proposons d’apporter une modification au protocole qui consiste à obliger le passage desmessages par les infrastructures lorsque ces dernières sont disponibles. Cela se traduitpar la modification du traitement des messages de découvertes des routes RREQ etRREP, définis au chapitre précédent, par les nœuds qui les utilisent.

Les deux organigrammes des figures 4.1 et 4.2 nous montrent où ces changementssont effectués. On pourra comparer ces figures aux figures 3.9 et 3.10 qui sont lesorganigrammes du protocole AODV, lorsque ce dernier n’a pas subi de modifications.Au moment de vérifier la validité de la route, on choisira en priorité la route par laquelleune infrastructure est disponible, peu importe son numéro de séquence ou son nombrede sauts entre la source et la destination.

Nous avons pu remarquer dans les chapitres précédant que l’utilisation des RSUsdans les VANETs est trop souvent absente, alors qu’ils sont au cœur même de ce typede réseaux. Nous cherchons à montrer que ce type de communications apporte uneamélioration des performances. Pour cela, nous avons choisi de considérer une «flotte»de véhicule se déplaçant à vitesse élevée. C’est dans ce contexte que les échanges dedonnées entre usagers se feront le plus dans la vie réelle : lors des longs voyages où lesvéhicules passeront une grande partie du temps sur autoroute. Les passagers pourrontalors, pour se divertir, communiquer avec les véhicules voisins, ou encore accéder àInternet. Mais pour ce dernier point, l’utilisation des infrastructures est primordiale.Le réseau principal est ad-hoc ; il ne possède donc pas de connexion avec les réseauxextérieurs. Seules les communications avec les infrastructures peuvent permettre cetteinteraction.

50

������������� ����

�������������������

�����������

��������������

�����������

���������� �������

����

������������������

���������� ���

��

������������������

�����

�����������

�����������

������������

�����

���������������������

��

����������������������������

�����������

��

�������� ���� ! ���� ������

��"������ ���������� #�����

���������� ����������

$��������������������

�����������

������ �%����������

�����������

�������

�����������

�����������

������������

����� �%���

�������

�����������

���

���

�#�������������"���

���

���

&��

&��

&��

&��

���

&��

Figure 4.1 – Traitement des messages RREQ modifié

51

Figure 4.2 – Traitement des messages RREP modifié

52

4.1.2 Environnement de simulation

Afin de créer un simulateur de réseaux véhiculaires mobiles, il est nécessaire de pos-séder deux entités : un simulateur de mobilité, et un simulateur de réseau. Nous allonsprésenter la combinaison de simulateurs que nous avons utilisés afin de réaliser notrerecherche, c’est-à-dire le simulateur de mobilité Simulation of Urban Mobility (SUMO)dans sa version 0.21.0, couplé au simulateur de réseaux NS-2 dans sa version 2.35.Cette combinaison de simulateurs (toutes versions confondues) est très utilisée par lacommunauté scientifique dans le domaine de la recherche sur les réseaux mobiles (vé-hiculaires ou non). En effet, parmi les protocoles que nous avons cités au chapitre 3,GPSR, MGRP, MIBR, Cached Geocast, Infrastructure Assisted Georouting ou encorePR-AODV(M) utilisent NS-2 [7, 10, 11, 21, 22, 24, 25]. Nous détaillons ces deux simu-lateurs dans les paragraphes suivants.

SUMO [71] est un simulateur de mobilité, capable de simuler villes et autoroutes.Il prend en charge le changement de voies ainsi que la fonction de suivi des voitures.De plus, il permet l’importation de cartes provenant de TIGER [51], Google Earth ouencore Environmental Systems Research Institute (ESRI) [72]. SUMO peut être utiliséde façon autonome ou bien être couplé avec deux simulateurs de réseaux : NS-2 (pourformer Traffic and Network Simulation Environment (TraNS) [73]) et OMNET++[74](pour former Vehicles in Network Simulation (VeiNS) [75]). L’installation se fait viades modules souvent complexes à configurer.

NS-2 est un simulateur de réseau [68] connu, qui bénéficie d’une large communautéd’utilisateurs et de contributeurs, ce qui apporte une grande quantité de documentationset de tutoriels. Il est développé en langage C++ en faisant intervenir des scripts decommande de simulation Tcl/Tk (scripts d’interprétations, évitant la manipulation duC++ aux utilisateurs). Le code source du simulateur est en C++, mais les paramètresde simulations sont définit dans des scripts Tcl. La simulation est alors lancée en ligne decommande dans un terminal (ou console). Cela permet d’automatiser les simulations defaçon simple grâce à des scripts batch (suite d’instructions permettant de faire exécuterplusieurs commandes à la machine). Une interface graphique de visualisation, pouvantprésenter les résultats, est fournie avec la version 2.35 : Network Animator (Nam). Lesrésultats sont fournis de façon brute dans des fichiers textes qui peuvent être configurésen détail dans les fichiers Tcl. Le traitement des fichiers de résultats se fait à l’aide descripts externes, tels que des scripts awk (langage de traitement de lignes). Les résultatspeuvent alors être exportés dans tout type de logiciels, tel que Excel.

53

4.1.3 Configuration des paramètres d’entrées

Le processus de simulation d’un VANET se fait en plusieurs étapes, illustrées à laFigure 4.3. Dans un premier temps, SUMO nécessite des fichiers d’entrées au formatxml. Ces fichiers sont réunis dans un fichier de configuration dont le format est propreà SUMO : .sumo.cfg. Le fichier de sortie est alors au format xml. Il est ensuite traitépar un programme en langage Python (fourni par SUMO) qui permet de créer unfichier exploitable par NS-2 : un fichier tcl. Les fichiers d’entrées de NS-2 sont donc desfichiers tcl. À la fin de la simulation avec NS-2, il y a deux fichiers de sortie : un fichiercontenant la trace de toutes les communications entre les nœuds de la simulation (celuiavec l’extension .tr), et un fichier comportant les données de déplacement des nœudsdurant la simulation, et pouvant être exécuté dans l’interface graphique de NS-2 (lefichier avec l’extension .nam). Ce processus est détaillé dans les paragraphes suivants.

Figure 4.3 – Processus de simulation d’un VANET avec SUMO et NS-2

De manière plus précise, la mise en place d’une flotte de véhicules se déplaçant surune autoroute à plusieurs voies avec SUMO, ainsi que la simulation du réseau avecNS-2 se font en deux étapes. La première étape permet de mettre en place l’autoroute,ainsi que les véhicules qui y circulent, avec l’aide de SUMO. La deuxième est l’étape deconfiguration de NS-2 afin de paramétrer la simulation d’un réseau mobile. Ces deuxétapes sont détaillées ci-dessous.

54

1. Mise au point d’une simulation de mobilité avec SUMO :

Afin de créer une autoroute de longueur fixée avec un nombre de voies de notrechoix, il faut tout d’abord créer deux points situés à chaque extrémité de la routeet ensuite les relier par une «arête» à l’aide des deux fichiers route.nod.xml etroute.edg.xml. Ces fichiers sont présentés aux figures 4.4 et 4.5. Dans le fichierroute.nod.xml, on définit deux points : un à 0 m, et l’autre à 10 000 m. À laFigure 4.5, on lie ces deux points en définissant le nombre de voies (trois dans cetexemple), et la vitesse maximale autorisée (31 m/s dans cet exemple).

Figure 4.4 – Exemple de configuration des nœuds avec SUMO

Figure 4.5 – Exemple de configuration d’une liaison avec SUMO

Ensuite, on génère le fichier route.net.xml, en exécutant la commande netconvert.Cette commande normalise et combine les informations des fichiers route.nod.xmlet route.edg.xml. Elle est appelée avec les arguments suivants :

netconvert –node-files=route.nod.xml –edge-files=route.edg.xml–output-file=route.net.xml

À l’aide du fichier Python : randomTrips.py fourni par SUMO, on peut alors créerdes véhicules, définis sur nos routes de manière aléatoire. Ce fichier nous permetde choisir le nombre de véhicules à générer, ainsi que leur vitesse maximale.

55

Le fichier config.sumo.cfg va indiquer les fichiers à utiliser pour la simulation,ainsi que les temps de début et de fin de la simulation. C’est ce fichier que l’onexécute avec SUMO, avec les commandes sumo ou sumo-gui. La première nécessitequelques arguments supplémentaires afin de préciser le fichier de sortie que l’onveut que SUMO nous fournisse à la fin de la simulation. La deuxième permet devisualiser le scénario tel que le montre la Figure 4.6. On remarque que l’autoroutepossède trois voies avec plusieurs véhicules (triangles) qui se déplacent.

Figure 4.6 – Visualisation d’une autoroute grâce à l’interface graphique de SUMO

Les commandes suivantes permettent de créer le fichier de mobilité exploitablepar NS-2 :sumo -c config.sumo.cfg –fcd-output mobilite.xmlettraceExporter.py –fcd-input mobilite.xml –ns2mobility-output mobilite.tclLa première est la commande d’exécution de SUMO. Elle effectue la simulation etcrée un fichier de sortie du scénario : le fichier mobilite.xml. La deuxième convertitce dernier à l’aide du fichier Python traceExporter.py, fourni par SUMO, en unfichier exécutable par NS-2 : le fichier mobilite.tcl.

56

2. Mise au point d’une simulation d’un VANET avec NS-2 :

La mise en place d’une simulation avec des nœuds mobiles dans NS-2 comporteplusieurs étapes :

a) Définition des variables à utiliser pour la simulation : ce sont les paramètresde simulation qui sont présentés au Tableau 4.1 ;

b) Initialisation des variables globales et définitions des paramètres des fichiersde sortie ;

c) Configuration et création des nœuds mobiles ;

d) Ajout de la mobilité aux nœuds. Cela se fait en important le fichier derésultats de SUMO ;

e) Mise en place de la couche réseau du simulateur. Pour notre simulation, nousavons choisi d’implémenter une connexion de type CBR, avec une couche detransport TCP. Ce type de connexions est souvent utilisé pour la simulationdes VANETs [7, 23–25, 76] ;

f) Définition de la position initiale des nœuds ;

g) Procédure de fin et lancement de la simulation.

TABLEAU 4.1 – Paramètres de simulation d’un VANET

Paramètre ValeurType des canaux Channel/WirelessChannelModèle de Propagation Propagation/TwoRayGroundModèle de couche Physique Phy/WirelessPhyModèle de couche Mac Mac/802_11Modèle de file d’attente Queue/DropTail/PriQueueNombre maximal de paquets dans la filed’attente

50

Modèle de couche liaison LLModèle des antennes Antenna/OmniAntennaProtocole de routage AODV

Notre version d’AODV modifiéParamètre X,Y de la carte 10 000 x 100 (m)

Pour plus d’informations sur le fichier de configuration, l’Annexe A.1 présente unscript Tcl commenté pour un réseau de nœuds mobiles avec NS-2.

57

L’exécution de la simulation se fait grâce à la commande ns, suivie du fichier Tclà exécuter :

ns exemple.tcl

Cette commande exécute les étapes définies ci-dessus. Dans l’étape 2b, les fichiersde sorties de la simulation sont définis. Il s’agit d’un fichier de sortie : simulation.tr,ainsi que d’un fichier que l’on peut visualiser grâce à l’interface graphique de NS-2, Nam : le fichier simulation.nam. La Figure 4.7 présente une capture d’écrand’une simulation visualisée grâce à cet outil. Les cercles numérotés représentent lesvéhicules (ou nœuds mobiles). Les grands cercles représentent les paquets diffusésafin de prendre connaissance du réseau. Les petits points ()entre les nœuds 11 et 9ou encore les nœuds 6 et 5) représentent des paquets de données en transmission,tandis que les carrés tombant du nœud 2 représentent des paquets abandonnés.

Figure 4.7 – Interface Graphique de Ns-2, Nam

L’outil Nam est important lors de la phase de configuration du réseau, pourvérifier que les nœuds se déplacent bien selon les paramètres prédits. Une fois cesvérifications effectuées, il n’est plus indispensable de s’en servir.

58

4.2 Plan d’expérience et présentation des résultats

Dans cette section nous allons commencer par définir notre plan d’expérience, dans lebut de vous présenter ensuite nos résultats ainsi que l’analyse que nous en avons faites.

4.2.1 Plan d’expérience

Afin d’atteindre les objectifs que nous nous sommes fixés, nous avons défini un pland’expérience. Nous le présentons ci-dessous :

1. Prévoir plusieurs scénarios de mobilité (vitesse, nombre de véhicules) ;

2. Effectuer les premières simulations qui nous serviront d’étalons ;

3. Ajouter les nœuds fixes afin de simuler les infrastructures des VANETs et définirles différents scénarios en modifiant le nombre d’infrastructures ;

4. Augmenter la zone de couverture des infrastructures en modifiant leurs sensibili-tés ;

5. Effectuer les simulations avec les infrastructures pour les protocoles de routagedisponible dans NS-2 ;

6. Modifier le protocole AODV afin de choisir de router les messages par les infra-structures lorsque ces dernières sont disponibles ;

7. Effectuer les simulations avec ce nouveau protocole ;

8. Analyser les résultats.

Nous allons désormais commencer par décrire notre implémentation des fichiers descénario, puis nous détaillerons la mise au point ainsi que l’exécution des programmes.

Implémentation des fichiers de scénario

L’implémentation des fichiers de scénario a été effectuée en plusieurs étapes. Dansun premier temps, nous avons effectué la modification de la sensibilité de réception desvéhicules et des RSUs afin qu’ils correspondent aux valeurs que nous avons choisiespour notre scénario. Ensuite, nous avons ajouté les RSUs aux fichiers de simulations.Ces étapes sont définies dans les points suivants. Les valeurs choisies sont justifiées àla section 4.2.1.

1. Modification de la sensibilité de réception des véhicules et des RSUs :Les paramètres du modèle Phy/WirelessPhy de NS-2 sont les suivants :

59

CPThresh_ 10 . 0 // S eu i l de capture (dB)CSThresh_ 1 .559e−11 // S eu i l de decouverte (Watt)RXThresh_ 3 .652e−10 // S eu i l de r e c ep t i on (Watt)bandwidth_ 2e6 // Bande passante (Hz)Pt_ 0 .28183815 // Puissance de Transmiss ion (Watt)freq_ 914 e+6 // Frequence u t i l i s e (Hz)L_ 1 . 0 // Coe f i c i e n t de per t e du c i r c u i t rad io

En résumé, lors de la réception d’un paquet, NS-2 calcule la puissance Pr du si-gnal reçu par les nœuds grâce aux informations qu’il contient. Si Pr est inférieureà CSThresh_, le récepteur ne peut pas détecter le paquet. Si CSThresh < Pr <RXThresh_, le paquet est détecté et il peut être correctement reçu. De plus, leRapport Signal Interférence (SIR) du paquet doit être supérieur à CPThresh_.Quand plusieurs paquets arrivent en même temps au récepteur, seulement le pre-mier paquet est reçu correctement, à condition que son Pr soit supérieur à celuides autres paquets, d’au moins CPThresh_.

Les antennes sont omnidirectionnelles. Leurs paramètres sont :

X_ 0 //Y_ 0 // Coordonnees (X,Y,Z ) de l ’ antenneZ_ 1 . 5 //Gt_ 1 . 0 // Gain de l ’ antenne en t ransmi s s i onGr_ 1 . 0 // Gain de l ’ antenne en r e c ep t i on

Seul les paramètres Z_, Gt_ et Gr_ sont réellement utilisés, X_ et Y_ étantredéfinis pour chaque nœud en fonction de sa position. Chacun des véhicules estdonc équipé d’une antenne omnidirectionnelle étant positionnée à une hauteur de1,5 m, ce qui correspond en moyenne à la hauteur à laquelle les antennes sontplacées sur une voiture.

Afin de mesurer le rayon de couverture d’un véhicule dans les conditions normalesde simulation avec NS-2, on peut réaliser une simulation test en connectant deuxnœuds qu’on éloigne d’un certain pas à chaque itération. En mesurant le débit,défini au Chapitre 3, qui correspond au ratio entre le nombre de paquets transmiset le temps qui a été nécessaire à leurs transmissions, on est en mesure de savoirsi la connexion se fait ou non. Initialement, les nœuds dans NS-2 sont configuréspour recevoir l’information si la distance entre les deux nœuds est inférieure ouégale à 250 m. Les protocoles de la littérature que nous avons étudiés utilisentdifférentes valeurs pour leur rayon de transmission, allant de 150 à 500 m. Nous

60

avons choisi une valeur intermédiaire de 300 m, qui semble être une valeur rai-sonnable et correspondante à nos expérimentations. Cao and Wu [77] étudientle rapport entre densités de véhicule et rayon de transmission efficace. Pour unréseau ni trop dense ni trop épars, 300 m est un bon compromis. Afin d’appli-quer cela, on modifie le paramètre RXThresh_, que l’on calcule grâce à un fichierprenant en compte le modèle de propagation, fourni par NS-2 (/ns-2.35/indep-utils/propagation/threshold.cc). Les paramètres d’entrées sont les paramètres dumodèle physique WirelesPhy et du modèle d’antenne OmniAntenna. On trouvealors une valeur en Watt de RXThresh_. Pour 300 m, cette valeur est :

RXThresh_ = 1.76149.10−10 (4.1)

On peut effectuer une vérification grâce à l’expérimentation présentée au débutdu paragraphe. Le graphique obtenu à la Figure 4.8 montre qu’avant 300 m, latransmission existe : le débit est non-nul. Au-delà de cette valeur, elle ne se faitplus : le débit est nul. La Figure 4.8 nous permet aussi de voir que le modèle detransmission TwoRayGround utilisé est simpliste. En effet, le débit est constant,quel que soit l’écart entre la source et la destination. Un modèle plus complexefournirait une courbe décroissante en fonction de la distance.

Le même type de calcul et vérification a été effectué pour permettre aux RSUsd’avoir un rayon de transmission de 600 m. La valeur de RXThresh_, pour 600m, est :

RXThresh_ = 1.10093.10−11 (4.2)

Afin que cette dernière valeur fournisse un graphique similaire à celui de la Figure4.8, nous devons modifier un dernier paramètre. En effet, un paramètre de NS-2,nommé «Carrier Sense Threshold» (CSThresh_), permet au simulateur de ne paseffectuer de calcul au-delà d’une certaine distance entre les paquets et les nœuds,afin de ne pas surcharger les simulations. Cette valeur est similaire au RXThresh_et est configuré par défaut pour ne plus effectuer de calcul à partir de 550m autourde chaque nœud. Or, lorsque l’on modifie le rayon de transmission des RSUs pourleur donner une valeur de 600 m, on se retrouve alors face à une incohérence.On doit donc modifier la valeur de ce «threshold» afin de permettre à NS-2 dedécouvrir les paquets à la distance de transmission choisie pour les RSUs. Nousavons donc modifié cette valeur afin qu’elle corresponde à une distance de 800 m,soit :

CSThresh_800 = 3.48341.10−12 (4.3)

61

Figure 4.8 – Distance de communication

2. Ajout des RSUs à la simulation :Les scénarios de mobilité ont été créés pour 50, 100 et 200 véhicules mobiles,comme dans la plupart des articles de la littérature [10, 12, 21, 23–25, 63]. Lesvitesses utilisées sont 80, 110 et 130 km/h, 80 km/h étant la vitesse minimaleautorisée sur certaines autoroutes, tandis que 110 et 130 km/h sont les vitessesmaximales autorisées sur certaines autoroutes [7, 10, 23–25]. Afin de rajouter desnœuds fixes à la simulation, on rajoute des nœuds de façon manuelle dans lefichier mobilite.tcl en ajoutant les lignes de la Figure 4.9 pour chaque nouveaunœud. Ces nouveaux nœuds sont fixes et leurs positionnements sont présentés auxfigures 4.10, 4.11, 4.12 et 4.13, avec respectivement 1, 2, 3 ou 4 RSUs. Le nombrede RSUs ne va pas au-delà de quatre, car dans ces conditions, ils sont disposés à2 km les uns des autres, ce qui est déjà très optimiste comme déploiement pourune autoroute réelle. De plus, au-delà de six RSUs, ils peuvent alors communiquerdirectement entre eux, et les communications pourraient se faire d’un véhicule àun autre, en ne passant que par les RSUs, ce qui n’est pas réaliste.

62

Figure 4.9 – Exemple d’ajout d’un nœud fixe

Figure 4.10 – Positionnement d’un RSU

Figure 4.11 – Positionnement de deux RSUs

Figure 4.12 – Positionnement de trois RSUs

Mise au point et exécution des programmes

La mise au point des programmes se fait par la configuration pour chaque simulationdes différents paramètres, puis par l’exécution des programmes grâce à un script bash.Cela est détaillé dans les paragraphes suivants.

63

Figure 4.13 – Positionnement de quatre RSUs

Les paramètres des simulations sont présentés aux Tableaux 4.2 et 4.3. Chaque pairede Source-Destination est choisie de manière aléatoire. Les résultats sont calculés àpartir d’une moyenne de 10 simulations. Le pseudo-code du fichier bash que nous avonsutilisé pour automatiser les simulations est présenté à l’annexe A.2.

TABLEAU 4.2 – Paramètres fixes de la simulation

Paramètre ValeurLongueur de la route 10 kmNombre de voies 3 voiesType de communication CBRTaille des paquets 512 bytesTaux de transmission 32 paquets par secondeNombre de communicationssimultanées 5

TABLEAU 4.3 – Paramètres variables de la simulation

Paramètre ValeurNombre de véhicules 50, 100, 200Vitesse des véhicules (km/h) 80, 110, 130Temps de simulation (secondes) 396 à 683, en fonction du nombre

de véhicules et de leurs vitessesDurée de communication Variable en fonction de la vitesse :

du kilomètre 1 au kilomètre 9Distance de communications Véhicules Infrastructures(en mètres) 300 300, 600

Les fichiers produits par chaque simulation ont un format spécial. Des extraits avecune légende sont présentés à l’annexe A.3. Ces données doivent donc être traitées afinde pouvoir en exploiter les informations utiles, et ainsi calculer les valeurs des métriquesde performances. On procède à ce traitement à l’aide d’un fichier awk. Le fichier awk

64

ayant traité les informations pour le calcul du PDR est présenté à l’annexe A.4. Afind’avoir une meilleure clarté, les résultats sont présentés sous forme de courbes effectuéesgrâce à un tableur Excel.

4.2.2 Résultats

Les résultats présentés sont divisés en trois parties suivant les différents points dé-finis par le plan d’expérience. Pour chacun de ces résultats, nous évaluons dans unpremier temps la courbe du protocole AODV qui nous sert d’étalon quant aux résultatsque nous obtenons avec les deux autres versions. Nous modifions ensuite les rayons depropagation du signal des RSU afin de les comparer aux résultats obtenus précédem-ment. Finalement, nous ajoutons les performances de notre version modifiée d’AODV.L’analyse complète des résultats est effectuée dans la Section suivante.

Sur tous les graphiques, nous pourrons observer trois courbes :

1. La courbe pour le protocole AODV avec une sensibilité de 300 m pour les RSUs,appelé «AODV 300» ;

2. La courbe pour le protocole AODV avec une sensibilité de 600 m pour les RSUs,appelé «AODV 600» ;

3. La courbe pour le protocole AODV modifié pour router l’information via les RSUsen priorité, appelé «AODVmod 600».

Les métriques présentées sont les suivantes :

— Le délai moyen de bout en bout : le temps moyen qu’un paquet a mis pour allerd’un véhicule source à un véhicule destination ;

— Le ratio de livraison des paquets ou PDR : le nombre de paquets moyen envoyépar un véhicule source qui a été reçu par le véhicule de destination ;

— Le nombre de sauts moyen que les paquets ont dû effectuer entre le véhicule sourceet le véhicule destination ;

— La charge du réseau utilisé en moyenne par chaque communication au cours dela simulation.

La présentation de ces métriques est inspirée de différents articles scientifiques citéstout au long de ce mémoire [7, 12, 18, 22–25]. Ces métriques sont définies plus en détaildans le Chapitre 3.

Les trois séries de résultats que nous allons présenter sont les suivantes :

65

1. La première présente les résultats concernant la réaction des protocoles AODVpour 0, 1, 2, 3 et 4 RSUs. Cette partie montre que les protocoles de routageévalués sont très sensibles au nombre de RSUs présents lors des simulations. LesRSUs tendent à améliorer les performances des protocoles de routage, mais il estaussi important de les placer avec parcimonie.

Les courbes qui sont présentées aux figures 4.14, 4.15, 4.16 et 4.17 présententrespectivement les résultats pour les délais, le PDR, le nombre de sauts moyensainsi que la charge du réseau, en fonction du nombre de RSUs. Nous étudions icil’influence du nombre de RSUs sur les performances des protocoles simulés. Ainsi,nous avons utilisé les valeurs moyennes pour 50, 100 et 200 véhicules aux vitessesde 80, 110 et 130 km/h. Nous observons donc des valeurs moyennes pour un totalde 9 scénarios simulés.

Figure 4.14 – Réaction des différents protocoles à l’augmentation du nombre de RSUsen terme de délais de bout en bout

2. La deuxième série présente les résultats par rapport au nombre de véhiculesconstituant la flotte. Cette partie montre les performances des protocoles évaluésen fonction du nombre de véhicules présents lors des simulations. Cela permetde montrer les performances des protocoles évaluées pour une densité de véhi-cules donnée. Dans la première partie des résultats, nous avons remarqué queles meilleures performances sont atteintes avec l’utilisation de trois RSUs. Cette

66

Figure 4.15 – Réaction des différents protocoles à l’augmentation du nombre de RSUsen terme de ratio de livraison des paquets

hypothèse est justifiée dans la Section 4.2.3. Les figures 4.18, 4.19, 4.20 et 4.21présentent respectivement les résultats en termes de délai, PDR, nombre de sautsmoyens et charge du réseau, en fonction du nombre de véhicules simulés (50, 100ou 200). Sur ces courbes, nous utilisons les valeurs moyennes pour les vitesses de80, 110 et 130 km/h.

3. Les derniers résultats montrent la réaction des protocoles par rapport à la vitessedes véhicules. Cette partie permet d’analyser les résultats pour des véhicules allantde la vitesse minimale autorisée à la vitesse maximale autorisée sur certainesautoroutes. Nous présentons les résultats pour les trois variations du protocoleAODV. Ce sont les résultats pour 200 véhicules avec trois RSUs. Les figures 4.22,4.23, 4.24 et 4.25 présentent donc chacune des métriques de performances utiliséesprécédemment, pour les vitesses de 80, 110 et 130 km/h.

La totalité des résultats ne pouvant pas être affichée dans cette section, nous avonsdécidé de présenter les plus significatifs. Les tableaux complets de résultats sont cepen-dant disponibles à l’annexe B.

67

Figure 4.16 – Réaction des différents protocoles à l’augmentation du nombre de RSUsen terme de nombre de sauts moyen de bout en bout

4.2.3 Analyse

Dans l’analyse des résultats, nous étudions les performances du protocole AODVet des adaptations que nous y avons effectuées, en fonction des quatre métriques deperformances utilisées dans notre recherche. Pour rappel, ces métriques sont : le délaide bout en bout et le pourcentage de livraison des paquets (PDR), qui sont les deuxmétriques principales qui caractérisent un protocole de routage, ainsi que le nombremoyen de sauts de bout en bout et la charge du réseau, qui permettent de compléterl’analyse. Dans cette section, nous allons analyser l’impact de ces paramètres sur lesprotocoles simulés en quatre points :

1. L’influence du nombre de RSU sur les protocoles simulés ;

2. La réaction des protocoles à l’augmentation de la sensibilité des RSU ;

3. La réaction des protocoles au nombre de véhicules de la flotte ;

4. La réaction des protocoles à la vitesse des véhicules.

Nous pouvons observer l’influence du nombre de RSU sur les protocoles simulés surles figures 4.14 à 4.17. Pour cette première partie de l’analyse, seule la courbe «AODV

68

Figure 4.17 – Réaction des différents protocoles à l’augmentation du nombre de RSUsen terme de charge du réseau moyen

300» nous intéresse. Les valeurs pour ces courbes nous serviront d’étalons pour la suitede notre travail puisqu’elles utilisent le protocole AODV fourni par NS-2, sans aucunemodification. On pourra remarquer par la suite que les deux autres courbes suivent lesmêmes tendances. Nous pouvons observer sur ces courbes qu’avec l’augmentation dunombre de RSU, les délais de bout en bout diminuent, le pourcentage de livraison despaquets augmente, le nombre moyen de sauts diminue et la charge du réseau augmente.

Ces résultats respectent l’idée que nous nous faisions de la réaction du protocole àl’augmentation du nombre de RSU. En effet, en ajoutant des nœuds fixes au réseau, lesvéhicules peuvent s’aider de ces infrastructures fixes afin de router l’information de façonplus rapide et plus fiable, ce qui réduit le nombre de sauts mais augmente le pourcentaged’informations de contrôle, car il y a plus de nœuds, donc plus d’informations de routageà partager sur le réseau. Et c’est bien ce que nous observons en général pour ces quatrecourbes. Nous observons cependant que pour trois RSUs, les courbes de délais de bouten bout, de PDR et de nombre de sauts moyen de bout en bout ne suivent pas latendance générale (cela se produit également pour 2 RSU sur la courbe du PDR). Celasemble être dû à notre choix de placement des RSUs au bord de la route. Pour troisRSUs, le placement ne semble pas optimal pour ce protocole. Ce sera d’ailleurs avec

69

Figure 4.18 – Évolution des délais de bout en bout en fonction du nombre de véhiculesdans le cas où il y a trois RSUs

trois RSUs que les améliorations apportées par nos modifications seront les meilleures.

Par ailleurs, la réaction des protocoles à l’augmentation de la sensibilité des RSUfournit aussi les résultats attendus. Nous pouvons en effet observer, sur les figures 4.14à 4.17, que la courbe «AODV 600» montre, à quelques exceptions près, de meilleursrésultats que la courbe «AODV 300», pour ce qui concerne les délais de bout en bout,le pourcentage de livraison des paquets, le nombre de sauts moyens et le pourcentaged’information de contrôle. En effet, les délais diminuent, le pourcentage de livraisondes paquets augmente, le nombre de sauts moyen diminue, alors que le pourcentaged’information de contrôle diminue. Ces résultats sont cohérents. En effet, en augmentantla sensibilité des RSUs, ces derniers ont la possibilité de recevoir et de renvoyer lespaquets sur une distance plus importante, ce qui réduit le nombre de sauts moyen,c’est-à-dire le nombre de nœuds intermédiaires lors de la transmission entre les sourceset les destinations. Les délais ainsi que le nombre d’informations de contrôle sont doncdiminués. Les paquets traversant moins de nœuds ont alors moins de chance d’êtreperdus, ce qui augmente le pourcentage de livraison des paquets.

Nous pouvons aussi remarquer sur ces figures les résultats pour notre protocole AODVmodifié : «AODVmod 600». Pour ce protocole, les RSUs ont la même sensibilité que

70

Figure 4.19 – Évolution du PDR en fonction du nombre de véhicule dans le cas où ily a trois RSUs

pour les courbes «AODV 600» et le protocole AODV a été modifié afin d’envoyer enpriorité les messages aux RSUs. La réaction de ce protocole en fonction du nombre deRSU est la même que pour les deux autres protocoles simulés. Cependant, nous pouvonsobserver que les performances de la courbes «AODVmod 600» sont meilleures que lesperformances de la courbe «AODV 300», mais elles ne sont pas toujours meilleuresque les performances de la courbe «AODV 600». Cela s’explique par les paramètresaléatoires de notre simulation (distance au RSU au moment du début des transmissions,choix arbitraire du placement des RSU ainsi que la longueur de la flotte de véhicules quivarie en fonction du nombre et de la vitesse des véhicules). Cela permet de conclure quela réaction des protocoles est optimale dans des conditions bien spécifiques. Ainsi, dansla configuration que nous avons choisie pour notre simulation, les meilleurs résultatssont obtenus avec trois RSUs.

Les résultats concernant l’évolution des protocoles simulés par rapport à la taille dela flotte sont présentés, pour les quatre métriques étudiés, aux figures 4.18 à 4.21. Nousnous attendions à observer sur ces courbes une augmentation des délais de bout en boutavec le nombre de véhicules, une diminution du PDR, une augmentation du nombrede sauts moyen de bout en bout, ainsi qu’une augmentation du taux d’information

71

Figure 4.20 – Évolution du nombre de sauts moyen en fonction du nombre de véhiculedans le cas où il y a trois RSUs

de contrôle. En effet, plus il y a de véhicules, plus les véhicules choisis aléatoirementcomme Source et comme Destination ont la possibilité d’être éloignés. Dans ce cas,les délais de bout en bout augmentent, le PDR diminue, alors que le nombre de sautsmoyen et le taux d’information de contrôle augmentent. Cependant, pour les courbesconcernant les délais moyens de bout en bout et le PDR, les résultats sont amélioréspour 100 véhicules par rapport à 50 véhicules, puis détériorés entre 100 et 200 véhicules(ces résultats contre intuitifs peuvent être expliqués par le Tableau 4.4).

TABLEAU 4.4 – Longueur de la flotte en fonction du nombre de véhicules.

Longueur de la flotteNombre de Véhicules (varie proportionnellement en fonction

de la vitesse des véhicules)80km/h - 130km/h

50 1.0 - 1.4 km100 2.5 - 3.4 km200 6.4 - 8.0 km

En effet, selon la Figure 4.12, la distance entre les RSUs est de 2 km. Pour 50 véhicules,la flotte ne peut être connectée à deux RSUs en même temps. Pour 100 véhicules, cetteconnexion à deux RSUs devient possible. L’ajout d’un deuxième, voire un troisième

72

Figure 4.21 – Évolution de la charge du réseau moyen en fonction du nombre devéhicules dans le cas où il y a trois RSUs

RSU connecté à la flotte en même temps montre une amélioration des résultats, malgréune flotte plus grande. Cela nous permet de conclure qu’il est important d’étudier leplacement des RSUs sur les routes en fonction des tailles moyennes des flottes. Entre100 et 200 véhicules, avec une connexion de ces flottes à plusieurs RSUs, les résultatssuivent bien les prédictions effectuées plus tôt.

Les valeurs étant des moyennes des résultats obtenues à 80, 110 et 130 km/h, les diffé-rentes courbes sont très proches les unes des autres. Nous pouvons voir que la diminutiondes délais de bout en bout, l’augmentation du PDR, la diminution du nombre de sautsmoyens et la diminution du taux d’information de contrôle sont assez nettes entre lescourbes «AODVmod 600» et «AODV 300», mais cela n’est pas toujours le cas pour lescourbes «AODV 600» et «AODVmod 600». On tend cependant à remarquer que plus lataille de la flotte est grande, plus l’amélioration de chacune des métriques est notable.

Pour terminer, nous allons analyser l’influence de la vitesse des véhicules sur lesperformances des protocoles simulés, ce qui est illustré aux figures 4.22 à 4.25. Lesrésultats étudiés ici sont pour 200 véhicules, car c’est pour cette taille de la flotte queles améliorations des résultats étaient les plus flagrantes. Les résultats pour chacunedes autres tailles de flottes sont similaires, avec des écarts plus ou moins grands entre

73

Figure 4.22 – Délai moyen de bout en bout en fonction de la vitesse dans le cas où ily a 200 véhicules et trois RSUs

les courbes. Nous observons pour ces courbes les mêmes comportements que pour lescourbes précédentes. En effet, la vitesse des véhicules modifiant la taille de la flotte, lemême raisonnement que pour le nombre de véhicules peut être effectué ici ; en parti-culier, notons que le taux d’information de contrôle augmente bien avec la vitesse desvéhicules. En effet, les véhicules se déplaçant à plus grande vitesse, les routes établiespar les protocoles changent plus souvent. Le taux d’information de contrôle en est doncaugmenté. De même, le nombre de sauts moyen diminue, car les véhicules traversentde plus en plus rapidement les zones sans RSU. Les routes étant de plus en plus sou-vent remises en cause à cause de la vitesse, AODV va pouvoir choisir la route avecles RSUs dès que ces derniers seront a portée. Là encore, les performances de notreprotocole, identifié par «AODVmod 600», sont en général meilleures que celles de laversion d’AODV avec les RSUs ayant la même sensibilité que les véhicules. Cependant,nous remarquons que dans certains cas, la version avec une sensibilité de 600 m pourles RSUs d’AODV montre des résultats plus complexe a analyser sans plus de données.

74

Figure 4.23 – PDR moyen en fonction de la vitesse dans le cas où il y a 200 véhiculeset trois RSUs

Il en résulte les conclusions suivantes :

— L’ajout de RSUs sur le bord des autoroutes améliore les résultats des protocolessimulés de 0.1 à 0.9 seconde pour les délais de bout en bout, de 0 à 1 % pourla livraison des paquets, diminuant jusqu’à 0.15 saut moyen de bout en bout,tout en augmentant le taux d’information de contrôle de 1 % maximum. Entenant compte du fait qu’AODV n’est à la base pas un protocole conçu pourles réseaux véhiculaires mobiles, de telles améliorations laissent à penser qu’unplacement idéal des RSUs, dans une simulation ayant comme protocole de routageun protocole plus adapté aux VANETs, avec les modifications présentées dansnotre travail, apporterait des résultats plus convaincants.

— Pour ce qui est de l’augmentation de la sensibilité des RSUs par rapport à lasensibilité de réception des véhicules, les résultats montrent que les délais de bouten bout diminuent de 0.1 à 0.5 seconde et le PDR augmente de 0.25 à 1 %. De plus,les métriques de contrôle, soit le nombre moyen de sauts et le taux d’informationsde contrôle, sont elles aussi améliorées par rapport au protocole de base (jusqu’à0.1 saut moyen de bout en bout et 0.5 % d’information de contrôle).

— L’étude des résultats concernant le nombre de véhicules qui forment la flotte estdépendante du positionnement des RSUs. De manière générale, l’augmentation du

75

Figure 4.24 – Nombre de sauts moyen en fonction de la vitesse dans le cas où il y a200 véhicules et trois RSUs

nombre de véhicules fait baisser les performances des trois variations du protocoleAODV, et cela se confirme pour le plus grand nombre de véhicules que nous avonssimulés, c’est-à-dire : 200.

— Par rapport à la mobilité, les protocoles «AODV 600» et «AODVmod 600» amé-liorent encore une fois les performances d’AODV dans sa version «AODV 300».

— L’ensemble des résultats montre que les modifications respectives du paramètrede sensibilité des RSUs et du protocole AODV entrainent une amélioration desrésultats.

76

Figure 4.25 – Charge du réseau moyen en fonction de la vitesse dans le cas où il y a200 véhicules et trois RSUs

77

Chapitre 5

Conclusion

Après avoir présenté et analysé les résultats de notre recherche, il nous revient main-tenant de conclure le mémoire. Dans cette conclusion, nous présenterons une synthèsedes résultats, puis nous préciserons les différentes limitations de notre travail, ce quinous amènera à discuter des travaux futurs.

5.1 Synthèse des résultats

Dans un premier temps, nous avons étudié les caractéristiques des réseaux véhiculairesmobiles. Nous avons effectué un état de l’art de ce type de réseaux afin d’en comprendreau mieux les enjeux. Pour cela, nous avons détaillé les caractéristiques spécifiques desVANETs, nous avons étudié les technologies qu’ils utilisent, puis nous avons détaillé lesdifférentes applications qu’il est possible de mettre en place à travers ces réseaux. Enfin,nous avons présenté les différentes possibilités de déploiement de tels réseaux, ainsi queles modèles de mobilité présents dans la littérature afin d’effectuer leurs simulations.

Ensuite, nous avons analysé le problème de routage dans les réseaux véhiculaires mo-biles. Pour cela, nous avons identifié les principaux protocoles utilisés par la littératureafin d’en dégager leurs différents points forts et points faibles. Grâce à l’étude réaliséeprécédemment, nous avons pu remarquer que l’utilisation d’infrastructures de bords deroute a été trop peu retrouvée dans l’évaluation des protocoles de la littérature. Eneffet, sans ces infrastructures, un VANET n’est en fait qu’un MANET, possédant cer-taines restrictions de mobilité sur la carte et des vitesses de déplacement élevées. Certes,les VANETs doivent être en mesure d’effectuer le routage de l’information lorsque lesinfrastructures ne sont pas disponibles. Cependant, un des défis majeurs de ces ré-

79

seaux est l’optimisation de l’utilisation de ces infrastructures lorsque ces dernières sontdisponibles.

Nous avons donc décidé, dans un premier temps, de nous baser sur le protocole AODV,et nous avons choisi de simuler un environnement concret de la vie réelle : une au-toroute à plusieurs voies, là où les applications commerciales des VANETs seront lesplus utilisées. C’est lors de longs trajets que les utilisateurs seront les plus enclins à lavolonté de se divertir. Nous avons alors voulu étudier la réaction du protocole de rou-tage, en obligeant les messages à passer par les RSUs lorsque ceux-ci sont disponibles.Nous avons étudié les métriques de performances en fonction du nombre de RSUs, dunombre de véhicules et de leur vitesse. Afin de pouvoir réaliser cela, nous avons étu-dié en détail le protocole AODV. Puis, nous avons présenté les différentes métriquesd’environnement et de performances, ainsi que les modèles de trafic et de propagationutilisés. Nous avons pu alors établir notre formulation du problème de routage dansles réseaux véhiculaires mobiles et analyser les différentes solutions rencontrées dans lalittérature.

Nous avons donc, à partir de cette analyse, présenté notre solution. Nous avons simuléAODV dans deux conditions : avec les RSUs ayant une sensibilité de réception et detransmission de 300 m et de 600 m, alors que les véhicules ont dans tous les cas lasensibilité minimum de 300 m. Le protocole introduit est simulé avec une sensibilité desRSUs de 600 m. Ce protocole est une modification d’AODV, obligeant les messages àpasser par les RSUs lorsque ceux-ci sont à leur portée. Ainsi, nous avons pu observerla réaction du protocole AODV à :

— L’ajout de RSUs le long de la route ;

— La sensibilité de transmission des RSUs ;

— Le routage des messages par les RSUs, lorsque ceux-ci sont disponibles.

Dans notre contexte de simulation, les meilleures performances sont obtenues avec troisRSUs. Cette observation nous a permis de nous rendre compte de l’importance dupositionnement des RSUs tout au long de la route, en fonction du nombre de véhiculesqui y circulent, ainsi que de leurs vitesses moyennes. Dans le cas concret d’une autorouteréelle, les véhicules ont tendance, à quelques exceptions près, à rouler aux vitessesautorisées. Enfin, nous avons pu constater que l’amélioration des performances, pourchacune des métriques étudiées, atteint jusqu’à 0.1 s pour les délais de bout en bout,1% pour le PDR, 0.1 saut moyen par communication et 0.5% pour le taux d’information

80

de contrôle, en moyenne pour les flottes de 50, 100 et 200 véhicules se déplaçant à unevitesse constante de 80, 110 et 130 km/h.

5.2 Limitations

Nous avons identifié trois principales limitations de notre travail. D’abord, plusieursparamètres de notre simulation, tels que le modèle de propagation Two-Ray-Ground,l’utilisation de la bande de fréquence proposée par NS-2, la longueur de l’autoroutesimulée, ainsi que son nombre de voies, ont été choisis de manière simpliste. En effet, lemodèle Two-Ray-Ground ne prend en compte que les communications sans fil directes,ou avec réflexion par le sol, alors que les communications réelles prennent en comptebien plus de paramètres. De plus, la bande de fréquences utilisée par NS-2 n’est pas àla longueur d’onde de la bande de fréquences conçue pour les VANETs. Les différentstypes de canaux ne sont pas simulés (canaux de service et canaux de contrôle), et lesmessages simulés lors de notre recherche sont seulement destinés aux applications deconfort. La longueur de la route est quant à elle très limitée en comparaison à uneautoroute que l’on peut trouver dans la réalité, pouvant mesurer des centaines, voiredes milliers de kilomètres.

Ensuite, nos résultats se basent sur une flotte qui se déplace le long de la route àune vitesse constante. Cela se base sur le postulat que les véhicules présents sur lesroutes roulent à peu près aux limites de vitesse en vigueur. Notre simulation ne prenden plus en compte que les déplacements sur autoroutes. Les circulations en ville et encampagne ne sont donc pas non plus simulées.

Enfin, notre recherche ne porte que sur le protocole AODV. Plusieurs autres pro-tocoles de routage provenant des MANETs pourraient être adaptés aux VANETs. Deplus, l’adaptation de protocoles de la littérature, destinés aux VANETs, mais n’ayantpas été simulés dans le cadre de notre recherche pourrait surement nous amener àdes conclusions intéressantes. Beaucoup de ces protocoles spécifiques aux VANETs neprennent en effet pas en compte les postulats de base proposés par notre recherche afind’effectuer leurs simulations.

81

5.3 Travaux futurs

Les travaux futurs consistent en premier lieu à améliorer la pertinence de nos résul-tats. En effet, les résultats présentés dépendent de beaucoup de paramètres de simula-tions qui ne sont pas toujours des plus précis. L’utilisation d’un modèle de propagationréaliste ainsi que de données provenant de la vie réelle pour ce qui est du tracé del’autoroute simulée, ainsi que des véhicules qui y circulent serait un premier pas versl’obtention de résultats au plus proche de la réalité. Les données récoltées pourraientprovenir, dans un premier temps, d’un tronçon d’autoroute choisi au préalable. Ainsi,l’utilisation de données réelles permettrait l’obtention de résultats plus pertinents, maisaussi l’étude du positionnement des RSU, de leur nombre ainsi que de leur rayon depropagation par rapport au rayon de propagation choisi pour les véhicules mobiles. Unetelle étude permettrait très certainement d’optimiser les résultats d’un grand nombrede protocoles de routage dans ce type de réseau. De plus, la simulation du réseauvéhiculaire mobile prenant en compte la technologie de transmission propre aux VA-NET, DSRC/WAVE, prenant en compte chacune de ces spécificités (canaux de services,canaux de contrôle, mais aussi les différents types de messages qui peuvent y être diffu-sés), nous permettrait d’avoir des résultats plus réalistes. Enfin, l’application de notresolution à plusieurs autres protocoles de routage, en particulier ceux conçus plus spé-cialement pour les VANETs pourrait être faite. Une étude comparative pourrait alorsêtre réalisée. De plus, le choix d’un nouveau simulateur pourrait être une option envi-sageable, dans la mesure où NS-2 est peu intuitif et son utilisation dans le cas d’ajoutde nouveaux protocoles de routage demande un temps de développement important.

82

Bibliographie

[1] Le Monde. http ://ecologie.blog.lemonde.fr/2011/08/26/un-milliard-de-voitures-dans-le-monde-la-chine-fait-la-course-en-tete/. Le Monde, 2011.

[2] OMS. http ://www.who.int/mediacentre/factsheets/fs310/fr/. Organisatin Mon-diale de la Santée, 2013.

[3] Xin Wang, editor. Mobile Ad-Hoc Networks : Applications. INTECH, January2011.

[4] Stefano Basagni, Marco Conti, Silvia Giordano, and Ivan Stojmenovic. Mobile AdHoc Networking : The Cutting Edge Directions, chapter 14 - 19. Wiley - IEEEPRESS, 2nd edition, March 2013.

[5] Hassnaa Moustafa and Yan Zhang, editors. Vehicular Networks : Techniques,Standards and Applications. CRC Press, 2009.

[6] Fatima AMEZA. Les technologies sans fil : Le routage dans les réseaux ad hoc(olsr et aodv). Master’s thesis, Université de Bejaia, 2007.

[7] Vinod Namboodiri, Manish Agarwal, and Lixin Gao. A study on the feasibilityof mobile gateways for vehicular ad-hoc networks. In Proceedings of the 1st ACMInternational Workshop on Vehicular Ad Hoc Networks, VANET ’04, pages 66–75,New York, NY, USA, 2004. ACM.

[8] J. Blum, A. Eskandarian, and L. Hoffman. Mobility management in ivc networks.In Intelligent Vehicles Symposium, 2003. Proceedings. IEEE, pages 150–155, June2003.

[9] R. A. Santos, A. Edwards, R. M. Edwards, and N. L. Seed. Performance evalua-tion of routing protocols in vehicular ad-hoc networks. Int. J. Ad Hoc UbiquitousComput., 1(1/2) :80–91, November 2005.

83

[10] B. N. Karp and H. T. Kung. Gpsr : Greedy perimeter stateless routing for wirelessnetworks. In 6th ACM/IEEE International Conference on Mobile Computing andNetworking (MobiCom), pages 243–254, Boston, MA, August 2000.

[11] Christian Lochert, Martin Mauve, Holger F¨ ussler, and Hannes Hartenstein. Geo-graphic routing in city scenarios. SIGMOBILE Mob. Comput. Commun. Rev., 9(1) :69–72, January 2005.

[12] K.C. Lee, J. Haerri, Uichin Lee, and M. Gerla. Enhanced perimeter routing forgeographic forwarding protocols in urban vehicular scenarios. In Globecom Work-shops, 2007 IEEE, pages 1–10, November 2007.

[13] Genping Liu, Bu-Sung Lee, Boon-Chong Seet, Chuan-Heng Foh, Kai-Juan Wong,and Keok-Kee Lee. A routing strategy for metropolis vehicular communications. InHyun-Kook Kahng and Shigeki Goto, editors, Information Networking. NetworkingTechnologies for Broadband and Mobile Networks, volume 3090 of Lecture Notes inComputer Science, pages 134–143. Springer Berlin Heidelberg, 2004. ISBN 978-3-540-23034-2.

[14] Yuh-Shyan Chen and Ci-Yi Lin, Yun-Wei adn Pan. Dir : diagonal-intersection-based routing protocol for vehicular ad hoc networks. Telecommunication Systems,46(4) :299, April 2011.

[15] V. Naumov and T.R. Gross. Connectivity-aware routing (car) in vehicular ad-hocnetworks. In INFOCOM 2007. 26th IEEE International Conference on ComputerCommunications. IEEE, pages 1919–1927, May 2007.

[16] M. Durresi, A. Durresi, and L. Barolli. Emergency broadcast protocol for inter-vehicle communications. In Parallel and Distributed Systems, 2005. Proceedings.11th International Conference on, volume 2, pages 402–406, July 2005.

[17] Min-Te Sun, Wu chi Feng, Ten-Hwang Lai, K. Yamada, H. Okada, and K. Fuji-mura. Gps-based message broadcast for adaptive inter-vehicle communications.In Vehicular Technology Conference, 2000. IEEE-VTS Fall VTC 2000. 52nd, vo-lume 6, pages 2685–2692 vol.6, 2000.

[18] O. Tonguz, N. Wisitpongphan, Fan Bai, P. Mudalige, and V. Sadekar. Broadcastingin vanet. In 2007 Mobile Networking for Vehicular Environments, pages 7–12, May2007.

84

[19] Rainer Baumann and Eth Zurich. Vanet : Vehicular ad hoc networks. In Master’sthesis, 2004.

[20] A. Bachir and A. Benslimane. A multicast protocol in ad hoc networks inter-vehiclegeocast. In Vehicular Technology Conference, 2003. VTC 2003-Spring. The 57thIEEE Semiannual, volume 4, pages 2456–2460 vol.4, April 2003.

[21] C. Maihofer and R. Eberhardt. Geocast in vehicular environments : caching andtransmission range control for improved efficiency. In Intelligent Vehicles Sympo-sium, 2004 IEEE, pages 951–956, June 2004.

[22] D. Borsetti and J. Gozalvez. Infrastructure-assisted geo-routing for cooperativevehicular networks. In Vehicular Networking Conference (VNC), 2010 IEEE, pages255–262, December 2010.

[23] Yong Ding and Li Xiao. Sadv : Static-node-assisted adaptive data disseminationin vehicular networks. Vehicular Technology, IEEE Transactions on, 59(5) :2445–2455, June 2010.

[24] Jie Luo, Xinxing Gu, Tong Zhao, and Wei Yan. A mobile infrastructure basedvanet routing protocol in the urban environment. In Communications and MobileComputing (CMC), 2010 International Conference on, volume 3, pages 432–437,April 2010.

[25] H Pan, R Jan, A Jeng, C Chen, and H Tseng. Mobile-gateway routing for vehicularnetworks. In IEEE VTSI APWCS, August 2011.

[26] Baraa T. Sharef, Raed A. Alsaqour, and Mahamod Ismail. Vehicular communi-cation ad hoc routing protocols : A survey. Journal of Network and ComputerApplications, 40(0) :363 – 396, 2014.

[27] H. Fujii, M. Akiyama, and K. Tokuda. Inter-vehicle communications protocol forgroup cooperative driving. In Vehicular Technology Conference, 1999. VTC 1999- Fall. IEEE VTS 50th, volume 4, pages 2228–2232 vol.4, 1999.

[28] Car Talk 2000. http ://www.cartalk2000.net. Car Talk 2000, 2000.

[29] Igor Paromtchik and Christian Laugier. The advanced safety vehicle programme,1996.

[30] US Despartment of Transportation. http ://www.dot.gov. US Department of Trans-portation, 2014.

85

[31] C2C. http ://www.car-to-car.org. Projet Car 2 Car, 2008 - 2014.

[32] IEEE Standard for Information technology - Telecommunications and informationexchange between systems - Local and metropolitan area network - Specific require-ment, Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer(PHY) Specifications, Amendment 6 : Wireless Access in Vehicular Environments.IEEE Computer Society, 2010.

[33] Raychaudhuri Dipankar and Mario Gerla. Emerging Wireless Technologies and theFuture Mobile Internet. Cambridge University Press, 2011.

[34] Marion Berbineau, Magnus Jonsson, Jean-Marie Bonnin, Soumaya Cherkaoui, Ma-rina Aguado, Cristina Rico-Garcia, Hassan Ghannoum, Rashid Mehmood, andAlexey Vinel (Eds.), editors. Communication Technologies for Vehicles. Springer,May 2013.

[35] G. Finn. Routing and addressing problems in large metropolitan-scale internet-works. Technical report, University of Southern California, March 1987.

[36] J.C. Navas and T. Imielinski. Geocast—geographic addressing and routing. In3rd ACM/IEEE International Conference on Mobile Computing and Networking(MobiCom), pages 66–76, Budapest, Hungary, September 1997.

[37] Safespot. http ://www.safespot-eu.org. Projet Safespot Europe, 2006 - 2010.

[38] GEONET. http ://www.geonet-project.eu. GEONET Projet, 2008 - 20014.

[39] ETSI-TC. http ://www.etsi.org. ETSI Technical Committee ITS, 2014.

[40] ISO-TC. http ://www.isotc204.com. ISO Technical Committee 204 Working Group16, 2014.

[41] Transports Canada Sécurité routière et réglementation automobile avec l’appui del’Agence de la santé publique du Canada. Sécurité routière au canada. TechnicalReport TP 15145 F, Gouvernement du Canada, 2011.

[42] New South Wales Government. http ://www.scats.com.au. New South Wales Go-vernment, 2014.

[43] Projet SmartPark. http ://smartpark.epfl.ch. Projet SmartPark : Parking MadeEasy, 2014.

86

[44] UCLA. http ://cvet.cs.ucla.edu. UCLA (University of California, Los Angeles),2014.

[45] Rutgers University. http ://www.winlab.rutgers.edu/docs/focus/ORBIT.html. Rut-gers University (New Jersay), 2004-2013.

[46] MIT. http ://cartel.csail.mit.edu/doku.php. MIT (Massachusetts Institute of Tech-nology), 2011.

[47] UMass. https ://dome.cs.umass.edu/umassdieselnet. UMass (University of Mas-sachusetts, 2014.

[48] Minglu Li, Min-You Wu, Ying Li, Jian Cao, Linpeng Huang, Qianni Deng, Xin-hua Lin, Changjun Jiang, Weiqin Tong, Yadong Gui, Aoying Zhou, Xinhong Wu,and Shui Jiang. Shanghaigrid : an information service grid. Concurrency andComputation : Practice and Experience, 18(1) :111–135, 2006.

[49] Lien-Wu Chen, Kun-Ze Syue, and Yu-Chee Tseng. Vs3 : A vehicular surveillanceand sensing system for security applications. In Mobile Adhoc and Sensor Systems,2009. MASS ’09. IEEE 6th International Conference on, pages 1071–1073, October2009.

[50] V. A. Gajbhiye and R. W. Jasutkar. Biologicaly inspired routing protocol forvehicular adhoc network. In Advanced Infocomm Technology (ICAIT), 2013 6thInternational Conference on, pages 202 – 206, July 2013.

[51] US Census Bureau. http ://www.census.gov/geo/maps-data/data/tiger.html. USDepartment of Commerce, 2014.

[52] Valery Naumov, Rainer Baumann, and Thomas Gross. An evaluation of inter-vehicle ad hoc networks based on realistic vehicular traces. In Proceedings of the7th ACM International Symposium on Mobile Ad Hoc Networking and Computing,pages 108–119, New York, NY, USA, 2006. ACM.

[53] Bryan Raney, Andreas Voellmy, Nurhan Cetin, Milenko Vrtic, and Kai Nagel.Towards a microscopic traffic simulation of all of switzerland, 2002.

[54] Fan Li and Yu Wang. Routing in vehicular ad hoc networks : A survey. VehicularTechnology Magazine, IEEE, 2(2) :12–22, June 2007. ISSN 1556-6072. doi : 10.1109/MVT.2007.912927.

87

[55] Sardar Muhammad Bilal, Carlos Jesus Bernardos, and Carmen Guerrero. Position-based routing in vehicular networks : A survey. J. Netw. Comput. Appl., 36(2) :685–697, March 2013.

[56] E. Spaho, L. Barolli, G. Mino, F. Xhafa, and V. Kolici. Vanet simulators : Asurvey on mobility and routing protocols. In Broadband and Wireless Computing,Communication and Applications (BWCCA), 2011 International Conference on,pages 1–10, October 2011. doi : 10.1109/BWCCA.2011.11.

[57] Yun-Wei Lin, Yuh-Shyan Chen, and Sing ling lee. Routing protocols in vehicularad hoc networks : A survey and future perspectives. Journal of information Scienceand Engineering, 26(3) :913, May 2010.

[58] Kevin C. Lee, Lee Uichin, and Mario Gerla. Survey of routing protocols in vehicularad hoc networks. In IGI Global, editor, Advances in Vehicular Ad-Hoc Networks :Developments and Challenges, 2010.

[59] Pooja Duddalwar, Atul Deshmukh, and S. S. Dorle. A comparative study of rou-ting protocol in vehicular ad hoc network. International Journal of EmergingTechnology and Advanced Engineering, 2(3) :71–76, March 2012.

[60] Z.J. Haas. A new routing protocol for the reconfigurable wireless networks. InUniversal Personal Communications Record, 1997. Conference Record., 1997 IEEE6th International Conference on, volume 2, pages 562–566 vol.2, Oct 1997. doi :10.1109/ICUPC.1997.627227.

[61] Charles E. Perkins and Pravin Bhagwat. Highly dynamic destination-sequenceddistance-vector routing (dsdv) for mobile computers. In SIGCOMM ’94 Procee-dings of the conference on Communications architectures, protocols and applica-tions, pages 234 – 244, 1994.

[62] P. Jacquet, P. Muhlethaler, T. Clausen, A. Laouiti, A. Qayyum, and L. Viennot.Optimized link state routing protocol for ad hoc networks. In Multi Topic Confe-rence, 2001. IEEE INMIC 2001. Technology for the 21st Century. Proceedings.IEEE International, pages 62–68, 2001. doi : 10.1109/INMIC.2001.995315.

[63] C.E. Perkins and E.M. Royer. Ad-hoc on-demand distance vector routing. In Mo-bile Computing Systems and Applications, 1999. Proceedings. WMCSA ’99. SecondIEEE Workshop on, pages 90–100, February 1999.

88

[64] David B. Johnson and David A. Maltz. Dynamic source routing in ad hoc wirelessnetworks. In Mobile Computing, pages 153–181. Kluwer Academic Publishers,1996.

[65] Wikipédia. http ://www.wikipédia.fr. Wikipédia, 2014.

[66] Xin Wang, editor. Mobile Ad-Hoc Networks : Applications, chapter 5. INTECH,January 2011.

[67] ISO. Open systems interconnection (osi). ISO 35.100, International Organizationfor Standardization, Geneva, Switzerland, 1993.

[68] The NS Manual. http ://www.isi.edu/nsnam/ns/doc/everything.html. A Colla-boration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC.,November 2011.

[69] International Telecommunication Union. Itu-t recommendation g.114, one waytransmission time. In In International Conference on Dynamics in Logistics 2007(LDIC 2007), Lect. Notes in Comp. Sciences. ITU, 2003.

[70] Refik Caglar Kizilrmak and Mastaneh Torkamani-Azar. Reducing collision pro-bability with multihop diversity for vehicle-to-roadside networks. In 2013 IEEESymposium on Wireless Technology and Applications (ISWTA), pages 17 – 22,September 2013.

[71] ITS. http ://www.dlr.de. Institute of Transportation System at the German Ae-rospace Center, 2014.

[72] ESRI. http ://esri.com/data/data-maps. ESRI, 2014.

[73] M. Piórkowski, M. Raya, A. Lezama Lugo, P. Papadimitratos, M. Grossglauser,and J.-P. Hubaux. Trans : Realistic joint traffic and network simulator for vanets.SIGMOBILE Mob. Comput. Commun. Rev., 12(1) :31–33, January 2008.

[74] Omnet++. http ://www.omnetpp.org. Omnet++ Simulator framework, 2014.

[75] D.o.C.S. http ://veins.car2x.org/. D.o.C.S. Veins project University of Erlangen.,2014.

[76] Jing Zhao and Guohong Cao. Vadd : Vehicle-assisted data delivery in vehicularad hoc networks. In INFOCOM 2006. 25th IEEE International Conference onComputer Communications. Proceedings, pages 1–12, April 2006.

89

[77] Ting Cao and Min-You Wu. Value analysis of transmission distance in urban vehi-cular networks. In Proceedings of the 2nd International Conference on ComputerScience and Electronics Engineering. Atlantis Press, 2013.

ss

90

Annexe A

Programmes

A.1 Script tcl détaillé pour un réseau de noeuds

mobiles avec ns2

# ==========================================================#De f i n i t i on# ==========================================================# type de cana lset va l ( chan ) Channel/WirelessChannel# Modele de propagat ion Radioset va l ( prop ) Propagation /TwoRayGround# Modele Physet va l ( n e t i f ) Phy/WirelessPhy# Modele MACset va l (mac) Mac/802_11# Modele de f i l e d ’ a t t e n t eset va l ( i f q ) Queue/DropTail /PriQueue# Modele de couche l i a i s o nset va l ( l l ) LL# Modele des antennesset va l ( ant ) Antenna/OmniAntenna# Nombre Maximum de packe t s dans l a f i l e d ’ a t t e n t eset va l ( i f q l e n ) 50# Nombre de noeuds mob i l e sset va l (nn) 2

91

# Protoco l e de routageset va l ( rp ) AODV# Dimension X de l a ca r t eset va l ( x ) 500# Dimension Y de l a ca r t eset va l ( y ) 500# Temps de f i n de s imu la t i onset va l ( stop ) 20

# ==========================================================# I n i t i a l i s a t i o n des v a r i a b l e s g l o b a l e s# ==========================================================set ns_ [ new Simulator ]$ns_ use−newtraceset t r a c e f d [open r e s u l t s . t r w]set namtrace [open simwrls−aodv.nam w]

$ns_ t ra c e−a l l $ t r a c e f d$ns_ namtrace−al l−wire less $namtrace $va l ( x ) $va l ( y )

# ==================================================# Mise en p lace de l a ca r t e# ==================================================set topo [ new Topography ]$topo l o ad_f l a t g r i d $va l ( x ) $va l ( y )

# ==================================================# Creat ion du Di r ec t eur General des Operation# ==================================================create−god $va l (nn )

# ==================================================# Creat ion du cana l ( impose par ns−2 )# ==================================================set chan_1 [ new $va l ( chan ) ]

92

# ==========================================================# Conf igura t ion e t c r ea t i on des noeuds mobi l e s# ==========================================================$ns_ node−config −adhocRouting $va l ( rp ) \

−llType $va l ( l l ) \−macType $va l (mac) \−ifqType $va l ( i f q ) \− ifqLen $va l ( i f q l e n ) \−antType $va l ( ant ) \−propType $va l ( prop ) \−phyType $va l ( n e t i f ) \−channel $chan_1 \−topoInstance $topo \−agentTrace ON \−routerTrace ON \−macTrace ON \−movementTrace ON

for { set i 0} { $ i < $val (nn) } { incr i } {set node_( $ i ) [ $ns_ node ]$node_( $ i ) random−motion 0

}

# ==========================================================# Ajout de l a mob i l i t e des noeuds (SUMO)# ==========================================================source " . / m o b i l i t e . t c l "

# ==========================================================# Mise en p l ace d ’ une connect ion CBR# entre l e noeud 0 e t l e noeud 1# ==========================================================

set k 0

set udp_( $k ) [ new Agent/UDP]

93

$ns_ attach−agent $node_ (0) $udp_( $k )set null_ ( $k ) [ new Agent/Nul l ]$ns_ attach−agent $node_ (1) $null_ ( $k )set cbr_ ( $k ) [ new Appl i ca t ion / T r a f f i c /CBR]$cbr_ ( $k ) set packetSize_ 512$cbr_ ( $k ) set rate_ 130kb$cbr_ ( $k ) attach−agent $udp_( $k )$ns_ connect $udp_( $k ) $null_ ( $k )$ns_ at 0 . 0 "$cbr_ ( $k ) ␣ s t a r t "$ns_ at 20 . 0 "$cbr_ ( $k ) ␣ stop "

# ==========================================================# De f i n i t i on de l a p o s i t i o n i n i t i a l e des noeuds dans Nam# ==========================================================for { set i 0} { $ i < $va l (nn)} { incr i } {

# 30 d e f i n e s the node s ize for nam$ns_ init ia l_node_pos $node_( $ i ) 20

}

# ==========================================================# Ind iquer aux noeuds quand l a s imu la t i on se termine# ==========================================================for { set i 0} { $ i < $va l (nn) } { incr i } {

$ns_ at $va l ( stop ) "$node_( $ i ) ␣ r e s e t " ;}

# ==========================================================# Mettre f i n a Nam et a l a Simulat ion# ==========================================================$ns_ at $va l ( stop ) "$ns_␣nam−end−wireless␣ $va l ( stop ) "$ns_ at $va l ( stop ) " stop "proc stop {} {

global ns_ t r a c e f d namtrace$ns_ f lu sh− t raceclose $ t r a c e f dclose $namtrace

94

#Execute nam on the trace f i l e#exec nam simwrls−aodv.namexit 0

}

# ==========================================================# Lancer# ==========================================================$ns_ run

A.2 Pseudo-code du fichier d’automatisation des

simulations

while Le nombre de simulation souhaité n’est pas atteint doChoix des 5 paires de Source-Destination grace a une fonction aleatoire;foreach Protocoles de routage do

foreach Sensibilitée de transmission des RSU doforeach Nombre de RSU do

foreach Nombre de véhicules doforeach Vitesses do

Faire la simulation avec les bon paramètres;Traiter les resultats avec le scripts awk;

end

end

end

end

end

end

Pour 10 simulations, 2 protocoles de routages (AODV et AODV-mod), 2 sensibilitée desRSU (300 et 600m), 5 nombre de RSU différents (0, 1, 2, 3 et 4), 3 nombre de véhicules(50, 100 et 200) et 3 vitesses (80, 110 et 130 km/h), 1800 simulations sont produitesgrâce au script d’automatisation (bash) que nous avons utilisé pour notre recherche.

95

A.3 Extrait d’un fichier trace produit par Ns-2

A.3.1 Extrait du fichier

% Exemple dun paquet envoyes −t 0 .000000000 −Hs 0 −Hd −2 −Ni 0 −Nx 0 .10 −Ny 0 .00 −Nz 0 .00−Ne −1.000000 −Nl AGT −Nw −−− −Ma 0 −Md 0 −Ms 0 −Mt 0 −Is 0 . 0−Id 1 . 0 −It cbr −Il 512 −If 0 −Ii 0 −Iv 32 −Pn cbr −Pi 0−Pf 0 −Po 0

% Exemple dun paquet recur −t 0 .000000000 −Hs 0 −Hd −2 −Ni 0 −Nx 0 .10 −Ny 0 .00 −Nz 0 .00−Ne −1.000000 −Nl RTR −Nw −−− −Ma 0 −Md 0 −Ms 0 −Mt 0 −Is 0 . 0−Id 1 . 0 −It cbr −Il 512 −If 0 −Ii 0 −Iv 32 −Pn cbr −Pi 0−Pf 0 −Po 0

% Exemple dun paquet dropped −t 2 .961723077 −Hs 0 −Hd −2 −Ni 0 −Nx 0 .10 −Ny 0 .00 −Nz 0 .00−Ne −1.000000 −Nl RTR −Nw IFQ −Ma 0 −Md 0 −Ms 0 −Mt 0 −Is 0 . 0−Id 1 . 0 −It cbr −Il 532 −If 0 −Ii 30 −Iv 30 −Pn cbr −Pi 30−Pf 0 −Po 0

A.3.2 Légende

Informations Généraless : événement (s : envoi, r : réception, d : drop, f : retransmission)t : temps (en secondes)

Informations du prochain nœudHs : Id du prochain nœudHd : Destination du prochain nœud

Propriétées du nœudNi : Id du nœud courantNx, Ny, Nz : coordonnées du nœud dans l’espaceNe : Niveau d’énergie du nœudNl : Niveau réseau ( AGT : Application, RTR : Réseau, MAC : Liaison, etc...)Nw : Raison si drop

96

Informations du niveau MAC du nœudMa : DuréeMd : Adresse ethernet de la destinationMs : Adresse ethernet de la sourceMt : Type de l’adresse ethernet

Informations du niveau IP du nœudIs : Adresse du port de la sourceId : Adresse du port de la destinationIt : Type du paquetIl : Taille du paquetIf : Id du fluxIi : Id uniqueIv : valeur du TTL

Informations spécifiques au type du paquet (ici CBR)Pn : Type du paquetPi : Numéro de séquence du paquet de type CBRPf : Nombre de fois que le paquet de type CBR a été retransmisPo : Nombre optimal de retransmissions

A.4 Fichier awk : Traitement pour le PDR

#!/ usr / b in /awk −fBEGIN{

PDR = 0}

{# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−# Recuperat ion des va l e u r s# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

event = $1 # evenementl e v e l = $19 # niveau reseau

# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−# Le niveau reseau e s t AGT e t i l s ’ a g i t d ’ une t ransmiss ion# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

97

i f ( event ==" s " && l e v e l =="AGT" ){packets_sent++;

}# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−# Le niveau reseau e s t AGT e t i l s ’ a g i t d ’ une r e c ep t i on# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

e l s e i f ( event==" r " && l e v e l=="AGT" ){packets_rece ived++;

}}

END{PDR = ( packets_rece ived / packets_sent ) ;print PDR;

}

98

Annexe B

Résultats

Les résultats sont divisés en cinq tableaux qui sont des captures d’écran des donnéesdans excel. Chaque tableau donne les résultats obtenus pour un nombre de RSU fixe.

99

Sensibilité Protocole RSU Vehicules Vitesses PDR Delai Hop RO300 AODV 0 50 80 0,5255 1,2889 2,9289 0,2581300 AODV 0 50 110 0,5019 1,0417 3,2738 0,2643300 AODV 0 50 130 0,5257 0,9057 3,2852 0,287300 AODV 0 100 80 0,5292 0,8515 3,2103 0,4129300 AODV 0 100 110 0,4891 0,8404 3,8514 0,4238300 AODV 0 100 130 0,5307 0,7871 3,6755 0,4134300 AODV 0 200 80 0,3581 1,7485 5,9161 0,5312300 AODV 0 200 110 0,3745 1,3844 5,3971 0,5605300 AODV 0 200 130 0,3631 1,4949 5,4603 0,5812600 AODV 0 50 80 0,5255 1,2889 2,9289 0,2581600 AODV 0 50 110 0,5019 1,0417 3,2738 0,2643600 AODV 0 50 130 0,5257 0,9057 3,2852 0,287600 AODV 0 100 80 0,5292 0,8515 3,2103 0,4129600 AODV 0 100 110 0,4891 0,8404 3,8514 0,4238600 AODV 0 100 130 0,5307 0,7871 3,6755 0,4134600 AODV 0 200 80 0,3581 1,7485 5,9161 0,5312600 AODV 0 200 110 0,3745 1,3844 5,3971 0,5605600 AODV 0 200 130 0,3631 1,4949 5,4603 0,5812600 AODVDmod 0 50 80 0,5255 1,2889 2,9289 0,2581600 AODVDmod 0 50 110 0,5019 1,0417 3,2738 0,2643600 AODVDmod 0 50 130 0,5257 0,9057 3,2852 0,287600 AODVDmod 0 100 80 0,5314 0,8372 3,2016 0,4114600 AODVDmod 0 100 110 0,4891 0,8404 3,8514 0,4238600 AODVDmod 0 100 130 0,5383 0,7732 3,6895 0,3993600 AODVDmod 0 200 80 0,3715 1,5478 5,7746 0,5329600 AODVDmod 0 200 110 0,3693 1,3873 5,4419 0,5576600 AODVDmod 0 200 130 0,3662 1,4881 5,4532 0,5782

Figure B.1 – Résultats avec 0 RSU

100

Sensibilité Protocole RSU Vehicules Vitesses PDR Delai Hop RO300 AODV 1 50 80 0,5239 1,2986 2,9432 0,2587300 AODV 1 50 110 0,5033 1,0202 3,274 0,2709300 AODV 1 50 130 0,5192 0,8964 3,2901 0,2975300 AODV 1 100 80 0,5303 0,8452 3,2145 0,4168300 AODV 1 100 110 0,4892 0,8615 3,817 0,4244300 AODV 1 100 130 0,5252 0,8237 3,7456 0,4107300 AODV 1 200 80 0,3664 1,7439 5,7896 0,535300 AODV 1 200 110 0,3726 1,3208 5,405 0,5621300 AODV 1 200 130 0,3802 1,3614 5,2362 0,5831600 AODV 1 50 80 0,5274 1,2268 2,9219 0,2558600 AODV 1 50 110 0,5032 1,0197 3,2684 0,2747600 AODV 1 50 130 0,5166 0,9181 3,3122 0,2924600 AODV 1 100 80 0,5358 0,8171 3,2024 0,4167600 AODV 1 100 110 0,4921 0,8311 3,8287 0,4184600 AODV 1 100 130 0,5293 0,7272 3,6595 0,4213600 AODV 1 200 80 0,3708 1,5856 5,6775 0,5351600 AODV 1 200 110 0,375 1,3287 5,3671 0,5659600 AODV 1 200 130 0,3779 1,3995 5,3222 0,579600 AODVDmod 1 50 80 0,52 1,2638 2,9503 0,2577600 AODVDmod 1 50 110 0,5024 0,9996 3,2711 0,2734600 AODVDmod 1 50 130 0,5203 0,8906 3,2754 0,2957600 AODVDmod 1 100 80 0,5295 0,8972 3,218 0,4124600 AODVDmod 1 100 110 0,4893 0,822 3,8083 0,4179600 AODVDmod 1 100 130 0,5279 0,7345 3,6608 0,4158600 AODVDmod 1 200 80 0,3607 1,6938 5,8233 0,5345600 AODVDmod 1 200 110 0,3688 1,3162 5,4398 0,5602600 AODVDmod 1 200 130 0,3742 1,361 5,2815 0,5787

Figure B.2 – Résultats avec 1 RSU

101

Sensibilité Protocole RSU Vehicules Vitesses PDR Delai Hop RO300 AODV 2 50 80 0,5283 1,195 2,8919 0,2667300 AODV 2 50 110 0,4955 1,0806 3,328 0,2639300 AODV 2 50 130 0,517 0,9038 3,27 0,2958300 AODV 2 100 80 0,528 0,8041 3,1971 0,4254300 AODV 2 100 110 0,4867 0,8122 3,7904 0,4298300 AODV 2 100 130 0,5299 0,8366 3,7198 0,4033300 AODV 2 200 80 0,3647 1,6238 5,7415 0,5352300 AODV 2 200 110 0,3653 1,281 5,3631 0,5731300 AODV 2 200 130 0,3817 1,2235 5,1415 0,5871600 AODV 2 50 80 0,5217 1,2619 2,9547 0,2518600 AODV 2 50 110 0,5043 1,0466 3,2716 0,2697600 AODV 2 50 130 0,5214 0,9321 3,3019 0,2909600 AODV 2 100 80 0,5388 0,7415 3,1286 0,421600 AODV 2 100 110 0,5003 0,7733 3,7499 0,4277600 AODV 2 100 130 0,5295 0,8171 3,6694 0,4079600 AODV 2 200 80 0,3655 1,5893 5,8082 0,537600 AODV 2 200 110 0,3754 1,3768 5,3488 0,5536600 AODV 2 200 130 0,3739 1,3587 5,2639 0,5866600 AODVDmod 2 50 80 0,5288 1,273 2,9297 0,2533600 AODVDmod 2 50 110 0,5014 1,0387 3,2666 0,2638600 AODVDmod 2 50 130 0,5192 0,971 3,2699 0,2933600 AODVDmod 2 100 80 0,5398 0,7738 3,1509 0,4213600 AODVDmod 2 100 110 0,4906 0,7852 3,7777 0,4304600 AODVDmod 2 100 130 0,5343 0,7195 3,6949 0,4104600 AODVDmod 2 200 80 0,366 1,6069 5,7301 0,5301600 AODVDmod 2 200 110 0,3671 1,3874 5,3645 0,5552600 AODVDmod 2 200 130 0,3715 1,4721 5,2983 0,5863

Figure B.3 – Résultats avec 2 RSU

102

Sensibilité Protocole RSU Vehicules Vitesses PDR Delai Hop RO300 AODV 3 50 80 0,5297 1,2296 2,9048 0,2633300 AODV 3 50 110 0,495 1,07 3,3285 0,2732300 AODV 3 50 130 0,5119 0,9464 3,3085 0,2963300 AODV 3 100 80 0,5301 0,8133 3,1748 0,426300 AODV 3 100 110 0,4894 0,7782 3,774 0,4252300 AODV 3 100 130 0,5286 0,7389 3,65 0,412300 AODV 3 200 80 0,3553 1,6374 5,9276 0,543300 AODV 3 200 110 0,3734 1,2664 5,3518 0,5663300 AODV 3 200 130 0,3753 1,4121 5,2815 0,5781600 AODV 3 50 80 0,5207 1,1967 2,9413 0,262600 AODV 3 50 110 0,4996 1,0348 3,2838 0,2646600 AODV 3 50 130 0,5144 0,9561 3,3014 0,2944600 AODV 3 100 80 0,5384 0,7619 3,1845 0,4122600 AODV 3 100 110 0,4947 0,7802 3,7742 0,4243600 AODV 3 100 130 0,5342 0,7063 3,6467 0,4149600 AODV 3 200 80 0,3707 1,4666 5,4575 0,5414600 AODV 3 200 110 0,3778 1,2792 5,2388 0,5653600 AODV 3 200 130 0,3815 1,2405 5,1584 0,5843600 AODVDmod 3 50 80 0,518 1,2356 2,9648 0,2551600 AODVDmod 3 50 110 0,5071 0,9995 3,2698 0,2737600 AODVDmod 3 50 130 0,5238 0,9445 3,2934 0,2886600 AODVDmod 3 100 80 0,5425 0,7416 3,1529 0,4166600 AODVDmod 3 100 110 0,4977 0,7762 3,751 0,4268600 AODVDmod 3 100 130 0,5339 0,768 3,7068 0,4047600 AODVDmod 3 200 80 0,3792 1,3342 5,4336 0,5369600 AODVDmod 3 200 110 0,3773 1,2459 5,289 0,5534600 AODVDmod 3 200 130 0,3771 1,2991 5,1155 0,5762

Figure B.4 – Résultats avec 3 RSU

103

Sensibilité Protocole RSU Vehicules Vitesses PDR Delai Hop RO300 AODV 4 50 80 0,5247 1,2298 2,9208 0,2464300 AODV 4 50 110 0,5171 0,9522 3,2344 0,2756300 AODV 4 50 130 0,5145 0,9055 3,234 0,3095300 AODV 4 100 80 0,5296 0,7859 3,1993 0,416300 AODV 4 100 110 0,49 0,8175 3,7469 0,4374300 AODV 4 100 130 0,5287 0,7882 3,7092 0,4184300 AODV 4 200 80 0,3706 1,4608 5,5926 0,5399300 AODV 4 200 110 0,3602 1,2583 5,5254 0,5755300 AODV 4 200 130 0,379 1,4244 5,2479 0,5841600 AODV 4 50 80 0,5284 1,2057 2,8786 0,2596600 AODV 4 50 110 0,5226 1,0163 3,2268 0,2642600 AODV 4 50 130 0,5251 0,9071 3,2707 0,2902600 AODV 4 100 80 0,5351 0,7779 3,1577 0,4237600 AODV 4 100 110 0,4963 0,8074 3,7976 0,4292600 AODV 4 100 130 0,5314 0,7786 3,6727 0,3988600 AODV 4 200 80 0,3898 1,2654 5,1787 0,5461600 AODV 4 200 110 0,3858 1,2512 5,1459 0,5715600 AODV 4 200 130 0,3851 1,445 5,163 0,5797600 AODVDmod 4 50 80 0,535 1,2221 2,8925 0,2525600 AODVDmod 4 50 110 0,5194 0,9994 3,236 0,2652600 AODVDmod 4 50 130 0,5271 0,8728 3,2444 0,3005600 AODVDmod 4 100 80 0,5355 0,7622 3,1695 0,4175600 AODVDmod 4 100 110 0,4883 0,8256 3,7809 0,4295600 AODVDmod 4 100 130 0,5287 0,8322 3,8634 0,3915600 AODVDmod 4 200 80 0,3751 1,544 5,4671 0,5354600 AODVDmod 4 200 110 0,3669 1,2678 5,3616 0,57600 AODVDmod 4 200 130 0,3788 1,369 5,1962 0,5838

Figure B.5 – Résultats avec 4 RSU

104