Embed Size (px)
Citation preview
« GESTION DU TRAFIC ROUTIER URBAIN A L’AIDE DES
TECHNOLOGIES VANET ET WAVE »
par : RAFALISON Avotra
Année Universitaire : 2016 / 2017 N° d’ordre: 10/ STI/ TCO
UNIVERSITE D’ANTANANARIVO
----------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------
DEPARTEMENT TELECOMMUNICATION
MEMOIRE DE FIN D’ETUDE
en vue de l’obtention
du DIPLOME de MASTER
Titre : Ingénieur
Domaine : Sciences de l’Ingénieur
Mention : Télécommunication
Parcours : Systèmes et Traitement de l’Information (STI)
Soutenu le Mardi 10 Juillet 2018 devant la commission d’Examen composée de :
Président :
M. RAKOTOMALALA Mamy Alain
Examinateurs :
M. RANDRIAMITANTSOA Andry Auguste
M. RAJAONARISON Tianandrasana Roméo
M. RATSIMBAZAFY Andriamanga
Directeur de mémoire :
M. RASOLOMANANA Jean Fanomezantsoa
i
REMERCIEMENTS
Tout d’abord, j’aimerai rendre gloire à l’Eternel de m’avoir donné la force et la patience pour que
je puisse réaliser cet ouvrage.
Ensuite, je tiens à remercier les personnes sans qui, l’aboutissement de cette étude n’aurait pas vu
le jour, lesquelles sont :
Monsieur RAMANOELINA Armand René Panja, Professeur Titulaire, Président de l’univérsité
d’Antananarivo
Monsieur ANDRIANAHARISON Yvon, Professeur Titulaire, Responsable du domaine de
l’ingénieur de l’Ecole Supérieure Polytechnique d’Antananarivo ;
Monsieur RAKOTOMALALA Mamy Alain, Maitre de conférences et Chef de la mention
Télécommunication au sein de l’ESPA ; qui nous a aussi fait l’honneur de présider le jury de
soutenance de ce mémoire.
Je voudrais exprimer mes plus profondes reconnaissances et ma gratitude envers Monsieur
RASOLOMANANA Jean Fanomezantsoa, Maitre de conférences, Enseignant chercheur à l’ESPA,
qui m’a toujours épaulé et s’est montré attentif tout au long de la réalisation de ce mémoire ;
Je voudrais exprimer mes plus profondes reconnaissances et ma gratitude envers Monsieur
•M. RANDRIAMINTANTSOA Andry Auguste, Maitre de conferences
•M. RAJAONARISON Tianandrasana Roméo, Maitre de conferences
•M. RATSIMBAZAFY Andriamanga, Maitre de conferences
Qui nous ont consacré une partie de leurs précieux temps pour assister à la présentation de ce
mémoire ;
Tous les enseignants et tout le personnel de l’Ecole Supérieure Polytechnique d’Antananarivo, en
particulier ceux de la mention Télécommunication;
Tous les membres de ma famille, mes amis, mes collègues et tous ceux qui ont contribué de près ou
de loin à l’accomplissement de ce travail
Bref, je souhaite exprimer ma gratitude à tous ceux qui m’ont aidé et que Dieu comble le bonheur
dont ils ont besoin.
ii
TABLE DES MATIERES
REMERCIEMENTS ................................................................................................................................. i
TABLE DES MATIERES .......................................................................................................................... ii
NOTATIONS ET ABREVIATIONS ............................................................................................................. v
INTRODUCTION GENERALE .................................................................................................................. 1
CHAPITRE 1 FLUX DE TRAFIC ROUTIER .................................................................................................. 2
1.1 Introduction .............................................................................................................................. 2
1.2 Les variables du trafic routier ..................................................................................................... 2
1.2.1 Variables individuelles ........................................................................................................ 2
1.2.2 La vitesse individuelle et la longueur des véhicules ............................................................... 5
1.2.3 Relation entre la vitesse de flot, la concentration et le débit ................................................. 6
1.3 Congestion ............................................................................................................................... 12
1.3.1 Définitions de base et exemples ......................................................................................... 12
1.3.2 La congestion sur ville ........................................................................................................ 17
1.3.3 Congestions, bouchons, encombrements ............................................................................ 18
1.3.4 Mesure et caractérisation de la congestion ......................................................................... 18
1.3.5 Calculs simples en congestion ............................................................................................. 20
1.4 Conclusion : .............................................................................................................................. 22
CHAPITRE 2 LES RESEAUX VANET ET LA TECHNOLOGIES WAVE ............................................................ 23
2.1 Introduction ............................................................................................................................. 23
2.2 La technologie de communication WAVE ................................................................................... 23
2.3 Architecture d’un réseau véhiculaire ......................................................................................... 24
2.3.2 Les entités de communication ............................................................................................ 25
2.3.3 Les différents types d’application ....................................................................................... 26
2.4 Messagerie dans les réseaux VANET .......................................................................................... 27
2.4.1 Types de message .............................................................................................................. 27
2.5 Architecture de communication ................................................................................................ 28
2.5.2 Communication Véhicule à Véhicule V2V ............................................................................ 30
2.5.3 Communication Véhicule-Infrastructure V2I ........................................................................ 31
2.5.4 Hybride .............................................................................................................................. 32
2.6 Environnement de déploiement ................................................................................................ 33
2.6.1 Milieu urbain ..................................................................................................................... 33
2.6.2 Milieu autoroutier .............................................................................................................. 34
iii
2.7 Moyens d’accès ........................................................................................................................ 34
2.7.1 Systèmes de communication intra véhiculaires ................................................................... 35
2.7.2 Systèmes de communication extra véhiculaires ................................................................... 35
2.8 La bande DSRC .......................................................................................................................... 37
2.9 Architecture de communication WAVE .................................................................................. 38
2.10 Pile de protocole WAVE .......................................................................................................... 39
2.10.2 Couche PHY de WAVE et modulation OFDM ...................................................................... 40
2.10.3 Couche MAC et l’opération multicanal .............................................................................. 43
2.10.4 Le plan de gestion dans le standard WAVE ........................................................................ 49
2.11 Protocole de routage dans les réseaux VANET ......................................................................... 52
2.12 Standard de communication sans fils dans les réseaux véhiculaires .......................................... 52
2.12.1 IEEE 1609.4 et IEEE 802.11p .............................................................................................. 52
2.12.2 IEEE 1609.1 ...................................................................................................................... 53
2.12.3 IEEE 1609.2 ...................................................................................................................... 54
2.12.4 IEEE 1609.3 ...................................................................................................................... 55
2.13 Conclusion .............................................................................................................................. 55
CHAPITRE 3 APPLICATION DE VANET A LA GESTION DU TRAFIC ROUTIER ............................................. 56
3.1 Introduction ............................................................................................................................. 56
3.2 Techniques de dissémination .................................................................................................... 56
3.2.1 Stratégies de dissémination ............................................................................................... 57
3.2.2 Modèles incitatifs à la coopération ..................................................................................... 60
3.2.3 Modèles de confiance ........................................................................................................ 61
3.3 Contrôle du trafic routier urbain ............................................................................................... 62
3.3.1 Métriques et paramètres traditionnels ............................................................................... 62
3.3.2 Types de contrôles ............................................................................................................. 63
3.3.3 Modes de fonctionnement d’un contrôleur de feux ............................................................. 64
3.3.4 Les systèmes de régulation du trafic ................................................................................... 65
3.3.5 Les systèmes coopératifs .................................................................................................... 67
3.4 Les causes de la congestion routier............................................................................................ 68
3.5 Scenarii de coopération entre les différents entités VANET ........................................................ 69
3.5.1 Capteur sur la route ........................................................................................................... 69
3.5.2 Communication entre véhicule V2V .................................................................................... 70
3.5.3 Coopération avec des réseaux de télécommunication ......................................................... 71
3.6 Conclusion ................................................................................................................................ 72
iv
CHAPITRE 4 ILLUSTRATION DES COMMUNICATIONS DANS LES RESEAUX VANET .................................. 73
4.1 Introduction ............................................................................................................................. 73
4.2 Les Simulateurs de Réseaux Ad Hoc ........................................................................................... 73
4.2.1 Le simulateur NS-2 ............................................................................................................. 73
4.3 Simulateur de mobilité et de trafic routier ................................................................................. 76
4.3.1 SUMO ................................................................................................................................ 76
4.3.2 Interopérabilité entre NS-2 et SUMO .................................................................................. 78
4.3.3 Explication des script tcl ..................................................................................................... 78
4.3.4 Résultats de la simulation .................................................................................................. 81
4.3.5 Extraction des informations dans le fichier trace ................................................................. 85
4.3.6 EstiNet 9.0 ......................................................................................................................... 87
4.4 Conclusion ................................................................................................................................ 96
CONCLUSION GENERALE ..................................................................................................................... 97
ANNEXE 1 : Programme .tcl ................................................................................................................ 98
ANNEXE 2 : code xml utilisé par SUMO.............................................................................................. 108
BIBLIOGRAPHIE ................................................................................................................................ 110
FICHE DE RENSEIGNEMENT ............................................................................................................... 113
RESUME .............................................................................................................................................. 1
ABSTRACT ........................................................................................................................................... 1
v
NOTATIONS ET ABREVIATIONS
1. Minuscules latines
a(t) Accélération à l’instant t
d distance entre les deux boucles
dt Dérivée du temps
𝑑2𝑡 Dérivée second du temps
dV(t) Dérivée de la vitesse à l’instant t
dx(t) Dérivée de la position latérale à l’instant t
d2 Diagramme fondamental sur la tronçon 2
𝑑2𝑥(𝑡) Dérivée second de la position latérale à l’instant t
f congestion du carrefour
t Variable exprimant le temps
t(x) position du véhicule à chaque pas de temps
x Position longitudinale
y Position latérale
Z Hauteur
x(t) Position longitudinale à l’instant t
y(t) Position latérale à l’instant t
2. Minuscules grecques
𝜑𝑖 Phase du feu i
Λ Longueur de la boucle électromagnétique
𝜃𝑖 Le temps pendant lequel la boucle électromagnétique détecte un signal
𝜏 temps séparant la détection d’un véhicule par la première boucle de la
détection par la seconde
3. Majuscules latines
C cycle utile
D1 Diagramme fondamental sur la tronçon 1
L Longueur du bouchon
𝐾∆𝑥(𝑡) Concentration des véhicules situés entre x et x+∆x à un instant t
vi
𝐿𝑃𝐴→𝐵 distance entre l’entrée et la sortie du tronçon
𝐿𝑖 Longueur d’un véhicule i
Nb nombre de véhicules dans le bouchon
Qb débit de sortie du bouchon
𝑄𝑡(𝑥) Débit du trafic routier passant pendant une période ∆T en un point x
S débit de saturation
T la somme des temps perdus par cycle
Tb temps de traversée du bouchon
𝑇𝑑𝑖𝑠 Temps de dispersion du bouchon
𝑇𝑃𝐴→𝐵(𝑡) Temps de parcours individuel du point A vers B à l’instant t
𝑇𝑝𝑎𝑠𝑠𝑎𝑔𝑒(𝑋) Temps de passage d’un véhicule sur le point X
U Vitesse du flot
𝑉(𝑡) Vitesse à l’instant t
𝑉𝐴→𝐵(𝑡) Vitesse moyenne sur un tronçon
Vb vitesse dans le bouchon
𝑉𝑖 Vitesse d’un véhicule i
𝑉∆𝑥(𝑡) vitesse moyenne spatiale
𝑉∆𝑥(𝑥) vitesse moyenne temporelle
𝑋𝑖 Charge de la phase
W Pente du diagramme fondamental
4. Majuscules grecques
∆ demande sur une voie
Ω offre sur une voie
∆T Intervalle de temps
∆x Intervalle de distance
5. Abréviations
ABS Anti Blockier System
vii
ACID Application Class Identifier
ACM Application Context Mark
ACK ACKnowledge
ADAS Advanced Driver Assistance System
AODV Ad hoc On-demand Distance Vector
A-STAR Anchor-based Street and Traffic Aware Routing
ASTM American Society for Testing and Materials
AWT Average Waiting Time
BSS Basic Service Set
BRP Bordercast Resolution Protocol
CALM Communications Access for Land Mobiles
CapX Capacité d’une voie
CFP Contention Free Period
CP Cyclic Prefix
CP Contention Period
CRC Contrôle de Redondance Cyclique
CSI Channel State Information
CSMA Carrier Sens Multiplexing Access
CSMA-CA CSMA-Collision Avoidance
CSMA-CD CSMA-Collision Detection
CTS Clear To Send
CW Contention Window
DAA Durée d'Attente Aléatoire
DFWMAC-DCF Distributed Foundation Wireless MAC-Distributed Coordination Function
viii
DFWMAC-PCF DFWMAC-Point Coordination Function
DGPS Differential Global Positioning System
DIASER DIAlogue Standard pour les Equipements de Régulation
DIFS Distributed Inter Frame Space
DSR Dynamic Source Routing
DSRC Dedicated Short Range Communication
DSDV Destination-Sequenced Distance-Vector
DVB Digital Video Broadcasting
DVB-SH DVB-Satellite Handheld
EDGE Enhanced Data Rates for GSM Evolution
EIFS Extended IFS
ESP Electronic Stability Program
ETSI European Telecommunications Standards Institute
FCS frame check sequence
GLS Grid Location Service
GMR GEOMobile Radio Interface
GNSS Global Navigation Satellite System
GPS Global Positioning System
GPRS General Packet Radio Service
GPSR Greedy Perimeter Stateless Routing
GSM Global System for Mobile Communications
GSR Global State Routing
GyTAR improved Greedy Traffic-Aware Routing protocol
HSPA High Speed Packet Access
IARP IntrAzone Routing Protocol
ix
IEEE Institute of Electrical and Electronics Engineers
IERP IntErzone Routing Protocol
IETF Internet Engineering Task Force
IFS Inter Frame Space
IFFT Inverted Fast Fourier Transformer
IHM Interface Homme Machine
INRIA Institut National de la Recherche en Informatique et Automatique
IR Infrarouge
IVC Inter Vehicle Communication
IP Internet Protocol
LDW Local Danger Warning
LLC Logical Link Control
MAC Medium Access Control
MANET Mobile Ad hoc NETwork
MIB Management Information Base
MORA MOvement-based Routing Algorithm
MPR Multi-Point Relaying
NAV Network Allocation Vector
NDP Neighbour Discovery Protocol
NEMA National Electrical Manufacturers Association
NS-2 Network Simulator 2
OBU On-Board Unit
OFDM Orthogonal Frequency Division Multiplexing
OLSR Optimized Link State Routing
OTCL Object Tools Command Language
x
PATH Partners for Advanced Transit and Highways
PDU Packet Data Unit
PIFS PCF IFS
PLCP Physical Layer Convergence Protocol
PMD Physical Medium Access
PPDU Protocol Packet Data Unit
PPS Precise Pulse per Second
PSDU Protocol Service Data Unit
QAM Quatrature Amplitude Modulation
RCP Resource Command Processor
RFC Request For Comment
RM Resource Manager
RMA Resource Manager Applications
RREP Route Reply Message
RREQ Route Request Message
RERR Route Error Message
RSU Road Side Unit
RTK Real Time Kinematic
RTS Ready To Send
SIF Signal Field
SAP Service Access Point
SCATS Sydney Coordinated Adaptive Traffic System
SCOOT Split Cycle Offset Optimization Technique
SIFS short inter Frame Spacing
xi
SNR Signal to Noise Ratio
STI Système de Transport Intelligent
SUMO Simulation of Urban Mobility
TA Timing Advertisement
TIVb Temps Inter-Véhicule b
TCP Transmission Control Protocol
TO Temps d’occupation
TTL Time To Live
TRANSYT TRANSport SYSTem
TRL Trafic research laboratory, Angleterre
TSF Timing Synchronisation Function
UMB Urban Multi hop Broadcast Protocol
UDP User Datagram Protocol
UMB Urban Multi-hop Broadcast
UMTS Universal Mobile Telecomunication System
UTCS Urban Traffic Control Software
UTC Universal Time Coordinated
VADD Vehicle-Assisted Data Delivery
VANET Vehicular Ad hoc NETwork
VSA Vendor Specific Action
VSC Vendor Specific Content
VSN Vehicular Sensor Network
VoIP Voice Over IP
V2I Vehicle to Infrastructure
V2V Vehicle to Vehicle
WAVE Wireless Access for Vehicular Environnement
Wi-Fi Wireless Fidelity
WiMAX Worldwide Interoperability for Microwave Access
xii
WLAN Wireless Local Area Network
WME WAVE Management Entity
WSA WAVE Service Advertisement
WSM WAVE Short Message
WSMP WAVE Short Message Protocol
ZRP Zone Routing Protocol
1
INTRODUCTION GENERALE
Avec l’augmentation du nombre de véhicules en circulation, il devient impératif de gérer en
conséquence, le trafic routier. Parallèlement à cela, les réseaux mobiles et sans fil ont connu un essor
sans précédent ces dernières années. Il s’agit d’une part du déploiement de plusieurs générations
successives de réseaux de télécommunications essentiellement dédiés à la téléphonie puis plus
orientés vers le multimédia. D’autre part, les réseaux locaux sans fil sont rentrés dans la vie
quotidienne au travers de standards phares tels que WiFi, Bluetooth,WAVE.
Etant donné que la construction de nouvelles routes a ses limites, le déploiement de réseau entre
véhicule est une alternative à ne pas négliger pour contrôler la congestion sur le trafic routier de
façon dynamique mais offre aussi un allégeage par rapport au réseau de télécommunication sachant
que certaines données peuvent circuler à travers les réseaux véhiculaires.
Dans le premier chapitre de ce mémoire, nous aborderons les théories et les variables caractérisant
et concernant le trafic routier. Des notions seront explicitées de façon à ce que nous apprenions
d’avantages sur les causes, du point de vue théorique, des congestions sur les routes urbaines.
Dans le second chapitre, nous nous focaliserons sur les technologies VANET, WAVE et DSRC.
Ces dernières offrent la possibilité de faire communiquer des nœuds mobiles ou, dans notre cas, des
véhicules. Nous illustrerons les aspects techniques concernant ces réseaux notamment sur les
architectures en couches et ses diverses caractéristiques
Dans le troisième chapitre, nous verrons plus précisément l’intervention du réseau VANET dans la
gestion du trafic routier urbain. Nous verrons les différentes sortes d’informations que le réseau
distribue pour rendre fluide la circulation du trafic routier ainsi que les principaux protocoles de
routage utilisé dans les réseaux véhiculaires.
Dans le dernier chapitre, nous simulerons des cas d’utilisation des réseau VANET. Nous utiliserons
deux types de simulateur : un simulateur indépendant qui ne produit qu’un trafic routier et a besoin
d’un simulateur de réseau Ad Hoc pour être performant et un simulateur intégré comprenant à la
fois les deux cités précédemment.
2
CHAPITRE 1 FLUX DE TRAFIC ROUTIER
1.1 Introduction
De nos jours, se déplacer est devenu un aspect essentiel de la vie quotidienne : qu’il s’agisse de
transports en commun ou de véhicules personnels, le vaste réseau formé de ces moyens de
locomotion est immensément complexe à gérer. Sa gestion recouvre l’ensemble des techniques
humaines et automatisées permettant d’assurer la surveillance des transports, au mieux un gain de
performance dans l’acheminement des différents flux. Dans ce travail, nous nous attarderons sur le
cas du trafic routier urbain et de son contrôle par un réseau de capteurs sans fil [1]. Le trafic routier
est un phénomène complexe en raison du nombre élevé d’acteurs qui y participent. Le phénomène
le plus marquant dans le trafic routier est la congestion qui alimente de nombreuses discussions
d’usagers. Depuis une cinquantaine d’années, cependant, des théoriciens du trafic cherchent à
comprendre et quantifier les mécanismes à l’œuvre [2].
1.2 Les variables du trafic routier
1.2.1 Variables individuelles
1.2.1.1 Notion de trajectoire
Pour étudier le trafic, on peut s’intéresser à un véhicule choisi parmi les autres. Supposons que
toutes les dix secondes on puisse mesurer sa position avec une précision suffisante (par exemple
grâce à un système de type GPS embarqué), on pourra alors schématiser l’évolution du véhicule sur
la voie par la figure 1.01 [2].
Figure 1.01 : Evolution du véhicule sur la voie
3
On a repéré la position longitudinale x(t) á t=0, 10, 20 et 30 secondes. Ce véhicule a parcouru 40
mètres en 30 secondes, ce qui correspond à une vitesse d’un peu moins de 50 km/h. Ce véhicule
reste au centre de la voie de droite, sa position latérale y(t) n’est donc pas modifiée au cours de son
trajet. La trajectoire d’un véhicule est donc l’ensemble des points successifs de l’espace qu’il occupe
accompagné des instants t de passage en ces points. Chaque point de la trajectoire peut donc être
repéré dans un espace à quatre dimensions : (x, y, z ; t). Cependant on utilise plus généralement une
abscisse curviligne : x est la position longitudinale, y la position latérale et on néglige la hauteur [2].
1.2.1.2 Mesure de x(t)
On a coutume de s’intéresser uniquement à la position longitudinale x(t) par rapport à la voie. Ceci
est lié à l’appareil de mesure qui, historiquement, est un capteur de tours de roues. On résume donc
la voie à une droite, le long de laquelle on mesure la position. On parle donc couramment de
trajectoire dans un plan (x, t). On peut représenter ces mesures sur la figure 1.02. Remarquons au
passage que le véhicule étudié est resté immobile entre les instants t = 22s et t = 24s. On peut déduire
de l’information de cette figure la distance parcourue (environ 3 mètres) par le véhicule pendant une
seconde entre t = 4s et t = 5s par exemple [2].
Figure 1.02 : Trajectoire dans un plan (x, t)
4
A partir de cette mesure de la position à chaque seconde, on peut dessiner une trajectoire entre les
points mesurés x = x(t). Ceci est montré sur la figure 1.03-a à gauche. La pente de la droite séparant
deux mesures successives de la position est une mesure indirecte de la vitesse individuelle du
véhicule à partir de sa position. Si on dispose d’une mesure directe de la vitesse individuelle, on
peut tracer une trajectoire individuelle plus réaliste, par exemple celle de la figure ci-dessous à droite
1.03-b. Notons d’ailleurs au passage qu’en toute rigueur mathématique il faudrait disposer d’une
mesure de la position en continu [2].
Figure 1.03 : Trajectoire individuelle d’un véhicule
1.2.1.3 Mesure de t(x)
Si, au lieu de disposer d’une mesure embarquée de la position du véhicule à chaque pas de temps,
on place le long de la route des observateurs régulièrement espacés, chargés de mesurer les dates de
passage du véhicule qui nous intéresse, on associera les instants aux points de mesure. Ceci est
représenté sur la figure suivante. Ces deux méthodes de mesure, de la position du véhicule à
plusieurs instants successifs ou de la date de passage en plusieurs points régulièrement espacés d’une
route, permettent de mesurer le même phénomène (la progression d’un véhicule sur une route) de
deux manières complémentaires [2].
Figure 1.04 : Mesure de t(x)
5
1.2.1.4 Variables et caractéristiques d’un véhicule
En plus de la position à un instant et de la date de passage en un point, on peut mesurer la vitesse
(soit à un instant, soit en un point) ainsi que l’accélération. Ces variables sont relatives à l’évolution
du véhicule le long de la route. D’autres caractéristiques sont associées au véhicule : sa puissance
moteur, sa longueur, sa masse... ; ou au conducteur de ce véhicule : la destination finale de son
voyage, son type de conduite (plus ou moins agressive). D’autres caractéristiques encore sont liées
non pas à l’une ou l’autre des deux entités de ce couple mais au couple lui-même. On parle alors du
couple véhicule-conducteur. La vitesse désirée (la vitesse à laquelle le conducteur, connaissant les
caractéristiques de la machine, souhaite conduire en fonction de la nature de la route) est
typiquement une caractéristique du couple véhicule-conducteur. Voici la synthèse des définitions
ci-dessus [2].
La position d’un véhicule mesurée à un instant est notée x(t).
La vitesse d’un véhicule est la dérivée de la position par rapport au temps :
𝑉(𝑡) =𝑑𝑥(𝑡)
𝑑𝑡
(1.01)
L’accélération est la dérivée de la vitesse d’un véhicule par rapport au temps et donc la dérivée
seconde de la position par rapport au temps :
𝑎(𝑡) =𝑑𝑉(𝑡)
𝑑𝑡=
𝑑2𝑥(𝑡)
𝑑2𝑡
(1.02)
La trajectoire d’un véhicule est l’ensemble des points associés à la date de passage d’un véhicule.
Elle peut être représentée dans un plan (x, t), soit à partir de mesures à chaque pas de temps de la
position, soit à partir de mesures des instants de passage en des points régulièrement espacés de la
route [2].
1.2.2 La vitesse individuelle et la longueur des véhicules
Lorsqu’on dispose non pas d’une mais de deux boucles électromagnétiques placées à une distance
faible l’une de l’autre, on peut mesurer la longueur et la vitesse individuelle de chaque véhicule. Si
𝜏 est le temps séparant la détection d’un véhicule par la première boucle de la détection par la
6
seconde et si on connaît d, la distance entre les deux boucles, alors la vitesse individuelle se calcule
comme [2] :
𝑉 = 𝑑/𝜏 (1.03)
On peut alors calculer la longueur du véhicule à partir de 𝜆, la longueur de la boucle. En effet, θ, le
temps pendant lequel le véhicule occupe la boucle, est directement relié à la vitesse et à la longueur
par :
𝜃 = (𝐿 + 𝜆)/𝑉 (1.04)
𝐿 = 𝜃 × 𝑉 − 𝜆
Figure 1.05 : Niveau de signal sur deux boucles au moment de passage d’un
véhicule
1.2.3 Relation entre la vitesse de flot, la concentration et le débit
Le débit est égal au produit de la concentration et de la vitesse de flot 𝑄 = 𝐾 × 𝑈. La vitesse du flot
U est donc donnée par l’équation :
𝑈 = 𝑄/𝐾 (1.05)
Les équations 1.06 et 1.07 définissent deux types de vitesses moyennes :
7
• La vitesse moyenne spatiale :
𝑉∆𝑥(𝑡) =1
𝑀× ∑ 𝑉𝑗(𝑡)
𝑀
𝑗=1
(1.06)
• La vitesse moyenne temporelle :
𝑉∆𝑡(𝑥) =1
𝑁× ∑ 𝑉𝑖(𝑥)
𝑀
𝑖=1
(1.07)
1.2.3.1 Modélisation du trafic routier urbain
Un réseau routier est conçu afin de permettre à ses usagers de se déplacer d’un point à un autre.
Dans ce contexte, il est composé d’un ensemble de routes avec plus ou moins de voies, en fonction
des zones d’activités et des lieux d’habitation. Les croisements entre les routes étant inévitables en
milieu urbain, de par leur concentration, des intersections permettent de gérer les flux de véhicules
entrant en conflit, pour leur sécurité et afin d’éviter les interblocages et de permettre aux
automobilistes de changer de route. Ces intersections, ou dans certains cas des carrefours giratoires,
régulent le trafic et appliquent généralement des règles de priorité à droite ou sont équipés de feux
de circulation pour gérer les situations particulièrement dangereuses. Le réseau routier urbain peut
donc être vu comme étant une collection d’intersections, liées les unes aux autres par des routes,
auxquelles peuvent venir se greffer des éléments opérationnels (panneaux, feux de circulation, etc.).
Sur un réseau de plusieurs intersections, les axes sont généralement classifiés en artères principales
ou secondaires, en fonction de leur utilisation et de leur capacité. À titre d’exemple, une grille
d’intersections est représentée sur la figure ci-dessous. L’intersection centrale est située sur deux
axes (artères). Les numéros indiquent le nombre de sauts qui séparent cette intersection des autres
intersections. Ainsi, une ligne droite formée de plusieurs intersections consécutives et accueillant
une majorité du trafic disponible est désignée comme une artère principale, tandis que les autres
routes, accessibles sur chacune des intersections, sont désignées comme étant secondaires. Cette
différenciation est utile pour la coordination des feux de circulation, qui s’effectuent dans la majorité
des systèmes traditionnels sur les artères principales. Elle est également utile à la compréhension de
la formation des embouteillages, qui ont tendance à se former là où le trafic est plus fort [4].
8
Figure 1.06 : Illustration des intersections sur un trafic urbain
Décrire le trafic routier existant sur ce type de réseau est crucial. Non seulement, ce type d’étude
permet de planifier les évolutions à entreprendre sur le réseau routier, mais elle permet également,
de nos jours, de réaliser des simulations numériques permettant d’anticiper certaines difficultés,
telles que les embouteillages ou accidents. Le trafic routier a ainsi été décrit au travers de nombreux
modèles, notamment à partir des années 1930 où Greenshields et al se sont intéressés à étudier les
termes de densité, de capacité et de vitesse. La recherche de nouveaux modèles s’est ensuite
accélérée dans les années 1950. Greenshields et al se sont intéressés aux performances des
intersections routières. Chandler et al ont étudié le suivi de véhicules et les comportements que les
conducteurs peuvent avoir les uns par rapport aux autres. Lighthill et al ont, pour leur part, étudié
des notions de débit dès les années 1955, tandis que des travaux se basant sur la théorie des files
d’attente apparaissaient. Ces travaux ont, entre autres, défini des modèles et des notions
fondamentales de la gestion du trafic routier. Seulement, depuis leur publication, les conditions de
circulation ont grandement évolué, de même que les technologies et les théories touchant aux
mathématiques ou aux systèmes informatiques [4].
9
Figure 1.07 : Les quatre classes de modèles du trafic routier. De gauche à
droite : macroscopique, mesoscopique, microscopique et sub-microscopique
1.2.3.2 Modèles de simulation sub-microscopiques
Les modèles de simulation sub-microscopiques décrivent les caractéristiques des véhicules
individuels où le véhicule est divisé en plusieurs parties. Ces modèles permettent la description, à
un niveau de détail élevé, du fonctionnement des unités spécifiques du véhicule et de leurs
interactions. Ils permettent également de décrire de façon détaillée le comportement du véhicule par
exemple : freinage, changement de vitesse. Parmi ces modèles, nous pouvons citer le modèle sub-
microscopique SIMONE et le modèle MIXIC. Pour plus d’informations le lecteur pourra consulter
[3].
1.2.3.3 Modèles de simulation microscopiques
Les modèles de simulation microscopiques décrivent le comportement des véhicules pris
individuellement. Ces modèles incluent par exemple l’interaction entre les véhicules ou entre les
véhicules et l’autoroute. Durant une simulation, tous les véhicules individuels et leurs interactions
sont simulés en utilisant ces modèles. La combinaison de tous les résultats de toutes les simulations
des modèles de véhicules conduit à obtenir une image de la situation du trafic. Les deux types de
modèles microscopiques les plus importants sont les modèles décrivant le comportement de
véhicule-suiveur et le comportement de changement de voies (dépassement). Les deux
comportements sont généralement décrits comme une fonction de la distance et de la vitesse des
véhicules proches, et la vitesse désirée du véhicule actuel. Comme les véhicules sont modélisés
individuellement dans les modèles de trafic microscopiques, il est facile d’attribuer des
caractéristiques différentes à chaque véhicule. Ces caractéristiques peuvent être liées au style de la
10
conduite du conducteur, au type de véhicule, à sa destination et à la route choisie. Il existe de
nombreux simulateurs microscopiques. Pour la plupart, ils sont basés sur le concept de véhicule-
suiveur et intègrent le changement de voies. On peut citer quelques exemples de simulateurs
microscopiques : AIMSUN, Vissim, Paramics, FLEXSYT-II [3].
• Le modèle véhicule-suiveur décrit le comportement d’un véhicule à partir du comportement
de celui qui le précède estimer sur la base de l’espace ou du temps inter-véhiculaires. Ce
modèle utilise les paramètres spécifiques des véhicules et de la route. La capacité
d’accélération, l’agressivité du conducteur, la masse du véhicule sont des paramètres du
véhicule qui peuvent être utilisés dans ce type de modèle. La vitesse limite maximale et le
nombre de voies sont des paramètres spécifiques de l’autoroute. Ils influencent la façon par
laquelle le véhicule suit ses prédécesseurs. Certains de ces modèles exploitent la distance de
sécurité qui doit être maintenue avec le véhicule précédent. D’autres modélisent la réaction
d’un conducteur en réponse à un stimulus : par exemple, la décélération d’un véhicule peut
être une fonction de sa vitesse relative par rapport à celui qui le précède [3].
• Le modèle de dépassement décrit comment le conducteur décide de dépasser ou pas son
prédécesseur. Les propriétés du véhicule et du conducteur qui sont importantes dans le
modèle de dépassement comme par exemple : la vitesse désirée du conducteur et la capacité
d’accélération du véhicule. Le nombre de voies ainsi que l’interaction des véhicules sont des
paramètres importants qui influencent le conducteur dans sa prise de décision de dépasser le
véhicule qui le précède. La décision de dépasser dépend également de la différence de vitesse
qui existe entre les différentes voies, mais aussi de l’existence d’un espace disponible sur la
voie de destination [3].
D’autres types de modèles microscopiques existent comme par exemple les modèles des automates
cellulaires et les modèles de particule. Les modèles des automates cellulaires décrivent une route
comme une succession de cellules connectées entre elles. La taille de chaque cellule correspond
approximativement à la dimension des véhicules (typiquement 7,5 mètres). Un tel modèle
microscopique décrit d’une façon discrète les mouvements des véhicules et suppose que soit ajouté
à ces cellules un ensemble de règles régissant le passage des véhicules d’une cellule à une autre. Par
exemple, les véhicules ne sautent pas dans les cellules occupées (une cellule ne peut contenir qu’un
seul véhicule). La taille des cellules est choisie telle qu’un véhicule, avec une vitesse égale à une
unité, passe à la cellule suivante située en aval durant un seul pas de temps. Selon la vitesse du
11
véhicule, celui-ci peut sauter plusieurs cellules à chaque pas de simulation. L’évolution de la vitesse
du véhicule est décrite par deux processus déterministes : l’accélération vers la vitesse désirée et la
décélération pour éviter la collision avec le véhicule qui le précède. Un processus probabiliste est
généralement introduit dans ce type de modèle. Il concerne l’introduction d’une décélération
aléatoire censée exprimer l’incapacité des conducteurs à maintenir une vitesse constante en
l’absence d’un équipement de régulation de vitesse présent sur le véhicule. Bien que ce type de
modèle soit simple et rapide, pouvant reproduire les ondes de choc et la métastabilité du flux de
trafic, il est très difficile de le calibrer à partir des données de trafic [3].
1.2.3.4 Modèles mésoscopiques
Ces modèles ne s’intéressent pas aux véhicules pris individuellement mais plutôt à des groupes de
véhicules (ils décrivent le trafic à un niveau intermédiaire entre les modèles microscopiques et les
modèles macroscopiques) où leurs interactions sont décrites à un faible niveau de détail. Dans les
modèles mésoscopiques, le trafic est représenté par des groupes de véhicules (entités de trafic) qui
ont les mêmes caractéristiques, par exemple, la même origine, la même destination, la même vitesse
désirée. Trois types de modèles mésoscopiques existent, les modèles de distribution inter-
véhiculaires, les modèles de groupes (clusters) et quelques modèles mésoscopiques qui reposent sur
la théorie de la cinétique des gaz [3].
1.2.3.5 Modèles macroscopiques
Les modèles macroscopiques sont basés sur l’analogie entre le flux de trafic et le flux (liquide ou
gaz) circulant dans un canal. Ce sont des modèles qui utilisent des variables agrégées contenant des
informations issues de plusieurs véhicules pour décrire les situations du trafic sans distinguer les
parties qui le constituent. Dans ces modèles, les manœuvres individuelles, comme le changement
de voies, ne sont pas considérées. Typiquement, le modèle macroscopique définit la relation entre
trois variables agrégées : la densité de trafic K, la vitesse moyenne V et le flux (le débit) de trafic
Q. La densité de trafic est définie comme le nombre de véhicules par unité de distance et par voie,
exprimée généralement en véh/km/voie, alors que le flux de trafic ou l’intensité de trafic est défini
comme le nombre de véhicules qui passent en un point par unité de temps, exprimé en généralement
en véh/h comme on l’a vu précédemment. Les modèles macroscopiques peuvent être classés selon
le nombre d’équations différentielles partielles qui les constituent [3].
12
1.3 Congestion
1.3.1 Définitions de base et exemples
La congestion du trafic est une notion intuitivement simple mais dont l’analyse rigoureuse s’avère
en fait assez complexe. Une multitude de définitions coexistent à travers la littérature technique et
il est bien rare qu’elles soient équivalentes. Il est donc utile de repréciser les bases théoriques de la
congestion, de mettre en perspective les différentes définitions existantes, les conséquences qu’elles
entraînent et les calculs qu’il est possible de faire. Un lien entre définition, caractérisation et mesure
de la congestion sera également étudié.
Avant de définir les diverses notions de congestions, il est primordial de savoir ce qu’est le
diagramme fondamental. Nous avons vu plus haut les définitions d’un certain nombre de grandeurs
relatives au trafic :
• Le débit Q (nombre de véhicules passant pendant une période de temps donnée en un point)
[2] ;
• La concentration K (nombre de véhicules présents à un instant sur une longueur de route
donnée) [2]. On peut relier la concentration au taux d’occupation TO par la relation :
𝑇𝑂(𝑡 ⟶ 𝑡 + ∆𝑡) = 100 × (𝜆 + 𝐿) × 𝐾 (1.08)
Précisons que cette formule n’est rigoureusement vraie que si les longueurs des véhicules
sont identiques entre elles et égales à 𝛌 et que la boucle mesure L mètres [2];
• La vitesse du flot U (vitesse moyenne des véhicules présents à un instant sur une longueur
de route donnée) [2].
Ces différentes variables peuvent être mesurées par exemple à l’aide de boucles électromagnétiques
[2].
Nous avons également vu que ces trois variables sont reliées par la relation :
𝑄 = 𝐾 × 𝑈 (1.09)
1.3.1.1 Les deux zones fondamentales
Si on cherche à lier le débit à la concentration, on constate qu’il existe deux régimes différents :
• Lorsque la concentration est faible, on peut supposer que le débit qui passe en un point va
croître de manière presque linéaire. Si les véhicules ne sont pas contraints, alors plus ils sont
13
nombreux dans une zone de longueur constante située en amont d’un point donné
(concentration), plus ils seront nombreux à passer dans les minutes suivantes en ce point
(débit). Ceci est vrai jusqu’à ce que le débit atteigne la capacité de la voie. À ce moment-là,
en effet, il y a une contrainte qui s’oppose à l’écoulement libre des véhicules [2] ;
Au-delà du point de critique la congestion apparaît ; les contraintes subies par le trafic et qui se
reflètent par une limitation du débit du fait qu’il y a une limitation de la capacité de la voie en aval
par exemple, induisent une augmentation de la concentration. Donc, au-delà du point critique, plus
le débit passant en un point diminue, plus la concentration augmente. Ces deux régimes se traduisent
par les deux zones de la figure suivante. La zone de gauche est la zone de trafic fluide, la zone de
droite, la zone de congestion. Il est à noter que la forme générale de la courbe d’évolution du débit
en fonction de la concentration n’est qu’une forme parmi d’autres possibles [2].
Figure 1.08 : Diagramme fondamental
1.3.1.2 Les trois représentations du diagramme fondamental
Nous avons rappelé que le débit et la concentration sont reliés, en chaque point du réseau et en
chaque instant, par la vitesse du flot. On peut donc représenter la relation fondamentale de la figure
1.14 de trois manières différentes :
𝑄 = 𝐹1(𝐾) (1.10)
𝑉 = 𝐹2(𝑄) (1.11)
14
𝑉 = 𝐹3(𝐾) (1.12)
Ce sont ces trois manières différentes d’exprimer la même chose qui sont présentées sur la figure
suivante. Si on considère une autoroute à trois voies, le débit maximal ou la capacité sera
typiquement de 6 000 à 7 000 véh/h.
Figure 1.09 : Diagramme fondamental en fonction du débit, la concentration
et la vitesse du flot
1.3.1.3 Définition locale de la congestion
Sur une section de voie, comme nous l’avons vu précédemment, la considération du diagramme
fondamental donne une définition simple de la congestion : le trafic est dit congestionné s’il évolue
dans la partie droite du diagramme, c’est-à-dire si la concentration est supérieure à la concentration
critique (concentration correspondant au débit maximum). La figure ci-dessous présente le cas où
la relation fondamentale est ajustée par un triangle. Les auteurs ont envisagé des formes
triangulaires, paraboliques, exponentielles. A cause de la relation 𝑄 = 𝐾 × 𝑈, la vitesse du flot est
égale à la pente de la droite de chaque point. On a illustré les états de fluidité et de congestion avec
les deux états respectivement 1 et 2 [2].
15
Figure 1.10 : Relation fondamentale ajustée par un triangle
Cette définition rejoint celle des économistes, selon lesquels un système est congestionné lorsque
l’introduction d’un usager supplémentaire dégrade le niveau de service pour les autres. La partie
fluide du diagramme correspond ici à une vitesse constante, donc à un niveau de service constant,
alors qu’une augmentation de concentration dans la partie congestionnée du diagramme se traduit
par une diminution de vitesse, donc du niveau de service. Remarquons au passage que si même en
fluide la vitesse décroît lorsque la concentration augmente alors il y a congestion au sens des
économistes dès qu’il y a plus d’un usager sur un tronçon [2].
On peut noter que fluidité et congestion s’opposent toujours par l’allure du diagramme fondamental
dans ces deux zones : en fluidité, une augmentation de concentration correspond à un accroissement
de débit, en congestion, elle correspond à une diminution du débit. Pour expliciter la notion de
congestion et ses propriétés, il est nécessaire de définir deux autres notions, celles d’offre et de
demande en trafic [2].
1.3.1.4 Offre et demande en trafic
Le flux de trafic qui s’écoule à un instant donné sur une voie est toujours la résultante d’une
interaction entre deux éléments :
• Une demande de trafic, qui représente le trafic qui cherche à s’écouler et qui s’écoulerait s’il
n’était pas contraint. Cette notion est différente selon l’échelle à laquelle on se place : à
l’échelle d’un réseau, c’est la demande globale de déplacement qui souhaite utiliser le
réseau, à l’échelle locale d’un point précis sur une voie, ce sont les véhicules présents et qui
cherchent à s’écouler. Par exemple, la demande dans une file d’attente arrêtée à un feu rouge
16
est égale au débit maximum de la ligne de feu, c’est-à-dire au débit qui s’écoulerait si le feu
passait au vert [2] ;
• Une offre de trafic, correspondant aux possibilités d’écoulement de l’infrastructure ; là
encore, cette notion est dépendante de l’échelle : l’offre d’un réseau représente les flux qu’il
est globalement capable d’écouler, l’offre locale en un point représente le flux qui pourrait
s’écouler en ce point. C’est ainsi que l’offre au sein d’une file d’attente arrêtée à un feu est
nulle, chaque véhicule étant empêché d’avancer par celui qui le précède, le premier de la file
étant lui-même arrêté par le feu rouge. Au sein d’une file d’attente en mouvement, l’offre
est égale au débit au niveau de la tête de bouchon. En effet, chaque véhicule constitue une
gêne pour celui qui le suit et globalement l’offre en tout point est celle du point le plus
contraint en aval [2].
On peut ainsi, à partir du diagramme fondamental qui relie le débit à la concentration, construire
une courbe demande/concentration et une courbe offre/concentration. Le débit qu’on peut
considérer comme la demande satisfaite est ainsi égal au minimum de l’offre et de la demande.
Figure 1.11 : Offre et demande sur le trafic routier
17
Ceci permet de mieux comprendre la congestion. En situation fluide, tout le flux qui se présente
peut s’écouler et le débit est égal à la demande. En congestion au contraire, c’est bien l’offre qui
conditionne le débit. Une situation de congestion correspond ainsi à une situation où la demande est
supérieure à l’offre. En fin de congestion, après un incident ou au début de la période où le feu est
vert, la congestion se maintiendra tant que la nouvelle offre n’a pas duré assez longtemps pour
permettre l’évacuation totale de la file d’attente. On peut aussi noter que l’interaction demande/offre
est l’interaction entre une sollicitation amont et une contrainte aval [2].
La vision purement locale de la congestion qui est donnée ici ne peut pas être utilisée de la même
façon pour caractériser plus globalement une congestion sur route, c’est-à-dire pour un trafic
continu, et une congestion en ville, ou pour un trafic interrompu par des intersections avec ou sans
feu. Nous allons maintenant nous intéresser successivement à la congestion sur route en milieu
urbain avant de revenir sur les différents sens et synonymes de ce mot et de proposer des méthodes
simples de calculs pour caractériser la congestion [2].
1.3.2 La congestion sur ville
La définition locale de la congestion telle qu’elle a été donnée plus haut est bien entendu valide sur
un réseau de carrefours mais elle n’a guère de signification opérationnelle. En amont immédiat d’un
carrefour à feux par exemple, on observe des alternances rapides de congestion/fluidité selon la
couleur du feu, qui ne donnent aucune indication sur le caractère plus ou moins critique des
conditions d’écoulement du trafic. C’est en fait la notion d’offre qui perd ici son sens lorsque
l’échelle de temps est trop fine : l’offre traduit alors simplement la couleur du feu. Le choix d’une
échelle temporelle pertinente redonne leur sens aux différentes notions de ce chapitre. Si l’on intègre
en effet l’influence des feux en calculant offre et demande à l’échelle par exemple d’un cycle de
feux, on peut conserver la définition de la congestion déjà vue. Une entrée de carrefour est ainsi
considérée comme congestionnée si la demande est supérieure à l’offre [2].
1.3.2.1 Cas du carrefour à feux fixes
Sur un carrefour à feux fonctionnant en cycle fixe, on voit que l’offre définie ainsi dépend non
seulement de la capacité instantanée lorsque le feu est vert (ou débit de saturation S), mais aussi de
la proportion du temps λ où le feu est vert :
𝑂𝑓𝑓𝑟𝑒 = λS =𝐷𝑢𝑟é𝑒𝑉𝑒𝑟𝑡
𝐷𝑢𝑟é𝑒𝐶𝑦𝑐𝑙𝑒× 𝑆
(1.13)
18
Pour une demande ∆ on voit que le taux de saturation 𝑥 =∆
𝜆𝑆 peut donner une définition du niveau
de congestion du carrefour, celui-ci étant défini comme congestionné si x > 1.
1.3.3 Congestions, bouchons, encombrements
La littérature technique utilise de nombreux termes pour évoquer la congestion sans toujours les
définir, congestion bien sûre, mais aussi ralentissement, bouchon, saturation, encombrement. C’est
ainsi qu’une définition liée à la vitesse, considérant que la circulation sur autoroute est encombrée
si la vitesse est comprise entre 30 et 60 km/h, saturée en dessous de 30 km/h. La Dirif (Direction
interdépartementale des routes d’Île-de-France) définit quant à elle un bouchon comme « un
ralentissement de la circulation débutant lorsque la vitesse descend en dessous de 30 km/h et se
terminant lorsque la vitesse remonte au-delà de 60 km/h ». Il est clair que chacune de ces définitions
a un sens, et qu’elles correspondent à des usages ou des besoins différents. Dans la suite nous
utiliserons les termes suivants :
• Congestion pour caractériser une situation de trafic répondant à la définition donnée au début
de ce chapitre ;
• Bouchon pour caractériser une zone de congestion délimitée en aval par un point de
contrainte (la tête du bouchon) et en amont par une discontinuité de concentration (queue de
bouchon).
1.3.4 Mesure et caractérisation de la congestion
Les différentes définitions données au paragraphe précédent sont autant de façons possibles de
caractériser la congestion, sans qu’elles soient nécessairement toutes pertinentes
opérationnellement. Il existe par ailleurs d’autres méthodes de caractérisation, dont la liaison avec
la définition précise n’est pas toujours garantie. Un rapide panorama de l’ensemble est présenté ici.
1.3.4.1 Caractérisation de la congestion locale en trafic continu
a. Par la concentration
La caractérisation de la congestion qui découle le plus directement de sa définition consiste à
analyser la concentration. En un point où des mesures de débit et concentration (ou débit et taux
d’occupation) sont disponibles, le tracé de nuages de points débit fois concentration permet de
déterminer une concentration critique (ou un taux d’occupation critique) au-delà de laquelle le trafic
est congestionné. La valeur de ces seuils est très variable d’un lieu à l’autre, elle peut être sensible
à de multiples facteurs comme le taux de poids lourds. Elle est en général comprise, sur autoroute,
19
dans une fourchette de 15 à 25 % pour le taux d’occupation, mais peut être très inférieure dans
certains cas [2].
b. Par la vitesse
La définition donnée ci-dessus tend à considérer que toute situation où la vitesse est inférieure à la
vitesse critique est congestionnée. L’observation de données réelles croisant vitesse et concentration
ou vitesse et débit permet selon les cas de confirmer cette vision ou de l’infirmer selon les sites. On
considère le trafic comme « encombré » lorsque la vitesse est comprise entre 30 et 60 km/h, « saturé
» en dessous de 30 km/h. Ceci correspond à une définition en général restrictive par rapport à la
précédente, sauf sur des voies limitées à 60 km/h [2].
c. Par l’observation
Les calculs d’indicateurs de congestion sont souvent fondés sur une observation visuelle des
conditions de trafic par les opérateurs des centres de gestion de trafic. De plus, il arrive que des
opérateurs confrontent une vision issue de caméras placées en hauteur, qui donnent accès à une
vision plus spatiale et une mesure de vitesse issue des boucles électromagnétiques. Ces deux visions
ne sont pas toujours compatibles et peuvent donner lieu à des incompréhensions et à des
indéterminations. Ceci donne évidemment un caractère subjectif à la définition de la congestion, qui
peut être assez éloignée de définitions fondées sur des indicateurs quantitatifs [2].
1.3.4.2 De la caractérisation locale aux indicateurs de congestion
Comme le montre le paragraphe précédent, la caractérisation de la congestion locale est déjà une
opération difficile, qui est menée de façons très diverses selon les lieux, les exploitants et les niveaux
d’équipements des réseaux.
Cette caractérisation locale ne suffit cependant pas à constituer un indicateur de congestion. Celui-
ci doit en effet prendre en compte trois dimensions :
• L’extension géographique de la congestion ;
• Son extension temporelle ;
• Sa « dureté » qui déterminera, pour une extension géographique et temporelle donnée, le
retard plus ou moins grand subi par les usagers (elle est par exemple liée à la vitesse du flot
dans le bouchon). Notons au passage que les deux premières dimensions associées
correspondent à l’amplitude, c’est à dire au nombre de personnes touchées par la congestion.
20
1.3.4.3 Congestion d’un réseau de carrefour
La définition de la congestion sur un réseau de carrefours est trop complexe pour permettre une
caractérisation locale facile. De même, les indicateurs de type volume d’encombrement sont
difficilement transposables à ce type de milieu. Les temps passés et temps perdus sont plus
facilement calculables, mais on est plus loin encore que sur route d’indicateurs de congestion
universellement définis [2].
1.3.5 Calculs simples en congestion
Dans ce paragraphe on utilisera exclusivement les relations suivantes :
• La relation 𝑄 = 𝐾 × 𝑈
• Le diagramme fondamental 𝑄 = 𝐹1(𝐾) 𝑜𝑢 𝑈 = 𝐹3(𝐾) ce qui revient au même via la relation
précédente.
À noter que si la relation Q=K×U est utilisable sans restriction, le diagramme fondamental n’est
qu’une approximation grossière de la réalité, ce qui limite nécessairement la portée des calculs
théoriques. Ceux-ci sont néanmoins éclairants pour comprendre les mécanismes en œuvre et donner
quelques ordres de grandeur [2].
1.3.5.1 Vitesse, temps de traversée d’un bouchon
Figure 1.12 : Illustration de la pente W sur le diagramme fondamental
Soit un bouchon de longueur L à un instant donné, dont le débit de sortie est égal à Qb. On peut
mesurer la vitesse dans le bouchon de deux manières :
• Directement ;
21
• Ou indirectement par la connaissance de la concentration dans le bouchon Kb et du débit de
sortie : Vb = Qb/Kb.
À partir de cette vitesse moyenne Vb des véhicules dans le bouchon, on peut déduire de façon
évidente un temps de traversée du bouchon pour les véhicules qui rejoignent le bouchon à cet instant
:
𝑇𝑏 = 𝐿/𝑉𝑏 (1.14)
Ce temps est distinct de la durée d’existence du bouchon : le bouchon peut exister pendant une
période très longue, les véhicules le composant se renouvelant en permanence.
Si ni la vitesse Vb ni la concentration Kb ne sont connues, alors que le débit Qb de sortie du bouchon
l’est, on peut utiliser une estimation de la pente W et du nombre maximal de véhicules en file
d’attente (Kx) pour estimer la concentration dans le bouchon par la formule :
𝑄𝑏 = 𝑊 × (𝐾𝑥 − 𝐾) (1.15)
La valeur de la pente W est celle de la vitesse de propagation des ondes de congestion dans le trafic.
Des résultats de recherche récents ont montré que la valeur de W est de l’ordre de 15 à 20 km/h. On
peut estimer simplement la concentration maximale d’une voie, Kx, à partir de la distance moyenne
entre deux avants de véhicules à l’arrêt [2].
On en déduit, puisque nous sommes dans le cas où le débit est limité à Qb, la capacité de
l’infrastructure en aval du bouchon :
𝐾𝑏 = 𝐾𝑥 − (𝑄𝑏
𝑊)
(1.16)
À l’instant où le bouchon a une longueur de L, le nombre de véhicules dans le bouchon est donc de
Nb = Kb×L. À l’aval du bouchon, le temps qui sépare le passage de deux véhicules, TIVb est égal
à l’inverse du débit de sortie du bouchon Qb. Le temps de traversée du bouchon pour le véhicule
qui le rejoint à l’instant où sa longueur est L est donc :
𝑇𝑏 = 𝑁𝑏 × 𝑇𝐼𝑉𝑏 =𝐾𝑏 × 𝐿
𝑄𝑏
(1.17)
À noter qu’en rapprochant cette formule de la précédente, on retrouve la vitesse dans le bouchon :
22
𝑉𝑏 = 𝑄𝑏/𝐾𝑏 (1.18)
1.3.5.2 Temps de dissipation d’un bouchon
Considérons maintenant le cas où le bouchon de longueur initiale L, et de débit sortant Qb, est
alimenté en amont par un débit Q plus faible que Qb. La longueur de la file d’attente va maintenant
décroître, puisque plus de véhicules en sortent (Qb) qu’il n’y a de véhicules qui y rentrent (Q). La
concentration dans le bouchon est toujours Kb, reliée à Qb par le diagramme fondamental.
Le temps qu’il faille pour que le bouchon disparaisse, 𝑇𝑑𝑖𝑠, est tel que le nombre de véhicules soit
nul au bout de ce temps. Or le bouchon contient au départ Nb = Kb×L véhicules et pendant 𝑇𝑑𝑖𝑠 il
sera alimenté à l’amont par 𝑄 × 𝑇𝑑𝑖𝑠 véhicules, alors qu’à l’aval 𝑄𝑏 × 𝑇𝑑𝑖𝑠 véhicules le quitteront.
𝑁𝑏 + 𝑄 × 𝑇𝑑𝑖𝑠 − 𝑄𝑏 × 𝑇𝑑𝑖𝑠 = 0 (1.19)
Donc
𝐾𝑏 × 𝐿 + (𝑄 − 𝑄𝑏) × 𝑇𝑑𝑖𝑠 = 0
D’où :
𝑇𝑑𝑖𝑠 =𝐾𝑏 × 𝐿
𝑄𝑏 − 𝑄
(1.20)
1.4 Conclusion :
Au fil de ce chapitre, nous avons pu illustrer quelques définitions fondamentales concernant le trafic
routier mais surtout sur le trafic routier urbain ; des définitions qui nous sont très utiles pour avoir
une vision globale sur les divers acteurs et facteurs concernant le flux de trafic routier. Ce chapitre
porte aussi son attention sur les modélisations du trafic routier afin que nous puissions bien
comprendre les interactions sur les usagers des routes et les routes elles-mêmes. Les modélisations
sont essentielles pour pouvoir adapter une simulation adéquate de notre travail. Dans le second
chapitre, nous effectuerons une étude plus approfondie sur les réseaux véhiculaires et leurs milieux
ainsi qu’une partie entière consacrée à la technologie WAVE.
23
CHAPITRE 2 LES RESEAUX VANET ET LA TECHNOLOGIES WAVE
2.1 Introduction
Les réseaux ont connu dans les 3 dernières décennies un essor fulgurant marqué en particulier par
la généralisation des communications sans fil. Le succès de ces communications, porté dans un
premier temps par la transmission séparée de la voix et des données, puis dans un second temps par
toute la panoplie des applications multimédias, a été tel qu'en l'espace d'à peine une décennie, le
nombre de terminaux sans fil dans le monde a plus que supplanté le nombre de terminaux fixes. Du
point de vue des origines technologiques, les réseaux sans fil peuvent être répertoriés suivant deux
grandes familles, à savoir, les réseaux issus du monde des télécommunications (GSM, GPRS,
UMTS, etc.) et ceux issus du monde de l'informatique (Bluetooth, Wi-Fi, WiMax, etc.). Face à
l'imbrication et à la convergence de ces deux mondes, il est aujourd’hui plus pertinent d’établir une
classification de ces réseaux suivant des critères structurants beaucoup plus transversaux. Ainsi, si
on considère la structure opérationnelle des réseaux sans fil comme seul facteur différenciant,
alors on retrouve une classification dominée par 3 grandes familles d'architectures que sont:
les architectures de réseaux à infrastructure dans lesquelles les terminaux communiquent
obligatoirement par l'intermédiaire d'un nœud fixe relié au réseau filaire, les architectures de
réseaux Ad hoc dans lesquelles les terminaux communiquent directement entre eux ou
indirectement par l'intermédiaire d'autres terminaux, et les architectures hybrides ou ad-hoc
hybrides qui sont la résultante de la combinaison des 2 premières familles d'architectures.
2.2 La technologie de communication WAVE
Avant de commencer à décrire cette technologie, nous allons définir deux acronymes importants à
retenir dans l’architecture WAVE. On-Board Unit (OBU) et Road Side Unit (RSU). Les deux types
de communications sont pris en charge par cette technologie, comme dans le cas de Wi-Fi. La
communication avec infrastructure, dans laquelle l’interaction s’effectue entre une RSU et une
OBU, est connue sous le nom d’V2I ou Vehicle to Infrastructure. La communication de type ad-hoc
où les communications se déroulent entre OBUs est appelée « Vehicle to Vehicle (V2V) ». La figure
2.02 montre les composants de la technologie WAVE et les deux types de communication possibles
[1].
24
Figure 2.01 : Communication dans la technologie WAVE
WAVE utilise la norme IEEE 802.11p qui est assez similaire à la norme 802.11a. Son débit
minimum est de 3 Mbit/s et le maximum de 27 Mbit/s au niveau de la couche physique. Une RSU
dispose d’une portée d’environ 1000 mètres avec le débit minimum et la puissance maximale
autorisée. La norme ETSI (European Telecommunications Standards Institute) standardise les
allocations de canaux en Europe, tout comme la norme IEEE 1609 le fait aux États-Unis. Dans les
deux standards, il existe deux types de canaux : un canal de type contrôle et les autres de type
service. L’intermittence provoquée par le faible déploiement d’infrastructures liées à cette
technologie entraîne une latence importante pour les fichiers qui ne peuvent pas être reçus lors du
passage auprès d’une seule RSU, ou bien encore lorsque la transmission commence au moment de
la sortie du véhicule de l’aire de couverture. En 2013, le taux de pénétration reste toujours faible et
le prix des dispositifs élevé. Cependant, dans les années à venir, comme ce fut le cas avec le WiFi,
cette technique pourrait être largement utilisée. Il est important de souligner que la fréquence utilisée
est réservée aux réseaux de véhicules ce qui réduit les interférences. Le coût d’utilisation de
l’infrastructure pourrait être fonction de l’application. Pour les applications de sécurité routière, le
coût serait nul. Pour le téléchargement de mises à jour de cartes, le plus probable est que les
fournisseurs de cartes payent l’accès à l’infrastructure et l’utilisateur à l’abonnement. Ces coûts
seraient uniquement imputés lors d’une utilisation effective de l’infrastructure. En revanche,
l’utilisation de communications V2V pourrait être gratuite. En profitant du haut débit offert par le
802.11n, la technologie WiFi peut être un complément de la technologie WAVE. Les véhicules
possédant les deux interfaces (WiFi et WAVE) peuvent profiter d’une plus grande bande passante
et aussi d’un coût nul pour la communication V2V (ad-hoc) [5].
2.3 Architecture d’un réseau véhiculaire
Dans les réseaux véhiculaires sans fil ou VANET (Vehicular Ad hoc NETwork), les véhicules
(entités mobiles) s’organisent pour établir la communication entre eux et aussi entre entités fixes
disposés le long de la route. L’échange des données entre les véhicules est désigné sous le nom de
la communication en mode ad hoc que celui entre les véhicules et les entités fixes est connu sous
25
l’appellation de communication en mode infrastructure. Les VANET fonts parti de la famille des
réseaux MANET (mobile Ad Hoc Network) qui fonctionnent dans des réseaux à liaison point à
point sans infrastructure, c’est-à-dire que tout nœud constituant le réseau est un point d’accès. Dans
un réseau VANET les nœuds sont les véhicules intelligents appartenant au réseau [6].
Figure 2.02 : Communication V2V et V2I
2.3.2 Les entités de communication
Un réseau VANET est constitué principalement de trois entités : TA (Trusted Authority), OBU (On
Board Unit) et RSU (Road Side Unit). Les RSU ne s’emploient que lorsque le mode à infrastructure
est préféré à celui d’Ad-hoc
2.3.2.1 TA (Trusted Authority)
Dites CA (autorité de confiance). C’est une source d’authenticité de l’information. Elle assure la
gestion et l’enregistrement de toutes les entités sur le réseau (RSU et OBU). La TA est sensée
connaître toutes les vraies identités des véhicules et au besoin les divulguer pour les forces de
l’ordre. Aussi, la TA dans certains travaux se charge de la délivrance et l’attribution des certificats
et des pseudonymes de communications [6].
2.3.2.2 RSUs (Road Side Unit)
Ces entités sont les subordonnés des TA. Elles sont installées au bord des routes. Elles peuvent être
principalement, des feux de signalisation, des lampadaires ou autres. Leur principale responsabilité
est de soutenir la TA dans la gestion du trafic et des véhicules. Elles représentent des points d’accès
au réseau et aux différentes informations sur la circulation [6].
26
2.3.2.3 OBU (On Board Unit)
Ce sont des unités embarquées dans les véhicules intelligents, elles regroupent un ensemble de
composants matériels et logiciels de hautes technologies (GPS, radar, caméras, différents capteurs
et autres). Leurs rôles sont d’assurer la localisation, la réception, le calcul, le stockage et l’envoi des
données sur le réseau. Ce sont des émetteurs-récepteurs qui assurent la connexion du véhicule au
réseau [6].
2.3.3 Les différents types d’application
Les réseaux véhiculaires sans fil contribueront à réduire le nombre d’accidents sur les routes du fait
des différents services que peuvent bénéficier ces utilisateurs. En effet, de la communication entre
les diverses entités du réseau découlent trois types de services qui vont de la gestion du trafic routier
à l’amélioration du confort des usagers.
2.3.3.1 Application de gestion du trafic routier
Les applications de gestion de trafic sont axées sur l’amélioration des conditions de circulation dans
le but de réduire les embouteillages et les risques d’accidents. Elles fournissent aux conducteurs un
support technique leur permettant d’adapter leur parcours à la situation du trafic routier. Ces
applications visent à équilibrer la circulation des véhicules sur les routes pour une utilisation efficace
de la capacité des routes et des carrefours et à réduire par conséquent les pertes humaines, la durée
des voyages et la consommation d’énergie [6]. Notre travail se focalisera sur cette application.
2.3.3.2 Application de confort
Cette catégorie comporte toutes les applications qui participent au confort du conducteur et qui ne
relèvent pas de la gestion du trafic ni de la sécurité routière. Ces applications se présentent donc
entant que services fournis au conducteur. Parmi ces applications, citons les panneaux d’annonces
locales : d’ordre commercial comme les offres de restaurants, la présence de stations-service
proximité, ou culturel comme des informations touristiques relatives à la localisation du véhicule.
Il y a aussi des services télématiques comme le péage à distance sur autoroute, le paiement
automatique dans les stations-service (ce qui peut faciliter la vie des handicapés). Un autre type
d’application de confort est la communication à vocation de divertissement. Une offre de connexion
internet à bord avec vidéo à la demande en est un parfait exemple. À toutes ces applications
s’ajoutent aussi les communications point à point entre deux conducteurs qui voyagent ensemble.
Ils peuvent ainsi s’échanger des messages ou partager des données (vidéo, musique, itinéraires, jeux
27
en réseau). La vie des usagers pourra aussi être facilitée par le contrôle à distance de véhicule de
manière électronique (vérification du permis de conduire, contrôle technique, plaque
d’immatriculation) pour les services compétents (police, douane, gendarmerie) [6].
2.3.3.3 Application de sécurité du trafic routier
Ils visent à améliorer la sécurité des passagers sur les routes en avisant les véhicules de toute
situation dangereuse. Ces applications se basent en général sur une diffusion, périodique ou non, de
messages informatifs permettant aux conducteurs d’avoir une connaissance de l’état de la route et
des véhicules voisins. Des exemples répandus de services dans cette catégorie d’applications sont,
l’avertissement des collisions, les avertissements sur les conditions de la route, l’assistance
dépassement et changement de voie. Les services de prévention et de sécurité du trafic routier
permettent d’élargir le champ de vision des conducteurs. De plus, ces services qui ont un effet direct
sur les personnes et biens contribuent à la diminution du nombre d’accidents sur les routes et par
conséquent préserver la vie humaine. Un de ces services est déjà implémenté dans certaines voitures
actuelles. Il s’agit du service SOS qui en cas d’accident, envoie un message afin de prévenir le centre
secours le plus proche. Ceci facilite l’arrivée rapide de l’équipe de secours et ainsi prévenir d’un
carambolage [6].
2.4 Messagerie dans les réseaux VANET
Un réseau sans fil véhiculaire est un ensemble d’entités communicantes organisées selon une
architecture de communication. Ces entités embarquées peuvent rencontrer différents
environnements que ce soit urbain, ou autoroutier ayant leurs contraintes propres.
2.4.1 Types de message
Les entités formant un réseau sans fil véhiculaire vont générer et s’échanger des messages. En
fonction de l’application et du contexte environnemental, un véhicule peut envoyer ou recevoir un
message de contrôle, d’alerte ou autre [7].
2.4.1.1 Message de contrôle
Le message de contrôle est généré à intervalle régulier. Conventionnellement, chaque véhicule émet
un message de contrôle toutes les 100 ms. Ce message, appelé aussi « beacon », contient la position,
la vitesse, la direction et l’itinéraire du véhicule émetteur. Grâce aux messages de contrôle, chaque
véhicule se crée une vue locale de son voisinage. Le véhicule peut aussi prédire et anticiper des
28
situations accidentogènes ou de congestion. Le message de contrôle est l’équivalent du message
HELLO des protocoles de routage. Chaque véhicule se fait donc connaître de son voisinage direct.
Bien entendu, les messages de contrôle ne sont pas transférés et utilisent une diffusion à un saut.
Figure 2.03 : Contenues d’un message de contrôle
2.4.1.2 Message d’alerte
Le message d’alerte est généré lorsqu’un événement est détecté. Cela peut être la détection d’un
accident, d’un obstacle ou la réception d’un autre message d’alerte. Le message d’alerte doit être
émis à intervalle régulier afin d’assurer la pérennité de l’alerte. Ainsi le ou les véhicules désignés
pour la retransmission des messages émettront des alertes à instants réguliers. Les messages d’alerte
doivent donc être de taille réduite pour être transmis le plus rapidement possible. Les messages
contiennent en particulier les coordonnées du lieu de l'accident et les paramètres de la zone de
retransmission [7].
2.4.1.3 Autres messages
Ce type de message contient tous les messages qui ne sont pas des messages d’alerte ou de contrôle.
Ces messages ne sont généralement pas répétés à intervalle régulier. En effet, cela peut être par
exemple un message de transaction financière ou l’envoi de courrier électronique. Tous les messages
reçus seront stockés dans un « cache des messages récemment reçus ». Chaque message se verra
associer une durée de vie dans le cache [7].
2.5 Architecture de communication
Les systèmes de gestion de trafic conventionnels sont basés sur des infrastructures centralisées où
des caméras et des capteurs implantés sur la route collectent des informations sur la densité et l’état
du trafic. Ces informations sont transmises à une unité centrale pour les traiter et prendre les
29
décisions adéquates. De tels systèmes exhibent un coût de déploiement assez important et se
caractérisent par un temps de réaction de l’ordre de la minute pour le traitement et le transfert des
informations. Dans un contexte où le délai de transmission de l'information est vital et revêt une
importance majeure dans ce type de systèmes, ce délai est un véritable frein. De plus, les
équipements mis en place sur les routes nécessitent une maintenance périodique et chère. Par
conséquent, pour déployer un tel système à large échelle, un important investissement dans
l'infrastructure de communication et de capteurs est nécessaire. Cependant, avec le développement
rapide des technologies de communication sans fil, des systèmes de localisation et de collecte
d'information par capteurs, une nouvelle architecture décentralisée (ou semi-centralisée) basée sur
des communications véhicule-à-véhicule (V2V, Vehicle to Vehicle) suscite ces dernières années un
réel intérêt auprès de la communauté scientifique, des constructeurs automobiles et des opérateurs
Télécoms. Ce type d'architecture s'appuie sur un système distribué, autonome, et est formé par les
véhicules eux-mêmes sans l'aide d'une infrastructure fixe pour le relayage des données et des
messages. On parle dans ce cas d'un réseau ad hoc de véhicules (VANET, Vehicular Ad hoc
NETwork). Le VANET n'est autre qu'une application dédiée et spécifique des réseaux ad hoc
mobiles conventionnels (MANET, Mobile Ad hoc NETwork) La figure 2.04 donne un exemple
d’architecture réseau de DSRC. On remarque aussi la présence de deux types de communications
nommées V2V et V2I [7].
30
Figure 2.04 : Exemple d’architecture réseau de DSRC
2.5.2 Communication Véhicule à Véhicule V2V
L’architecture de communication inter-véhicules, V2V ou IVC pour Inter Vehicle Communication,
est composée uniquement d’OBU contenue dans des véhicules légers, des poids lourds ou des
véhicules de secours. Ils forment alors un réseau mobile sans avoir besoin d’un élément de
coordination centralisé. Cette situation est plausible et essentielle si certains équipements RSU
deviennent indisponibles (en panne ou hors de portée). Dans ce cas, le réseau doit continuer de
fonctionner. Les véhicules doivent alors collaborer pour assurer la disponibilité du service. Ce mode
de fonctionnement est communément appelé « ad hoc » et est utilisé par les VANETs. L’architecture
V2V en mode ad hoc peut aussi être utilisée dans les scénarios de diffusion d’alerte (freinage
d’urgence, collision, ralentissement, etc.) ou pour la conduite coopérative. En effet, dans le cadre
d’applications de sécurité routière, les réseaux à infrastructure montrent leurs limites, surtout en
termes de délai. Prenons l’exemple d’un véhicule en difficulté sur la chaussée qui diffuse un
31
message d’alerte. Il semble plus rapide d’envoyer l’information directement aux autres véhicules
plutôt que de la faire transiter par une station de base. Une autre raison de l’existence de ce type
d’architecture de communication vient du fait de la densité des réseaux routiers français. En effet,
le million de kilomètres de routes françaises nécessitent, par exemple, un nombre important de RSU,
ce qui entraîne un coût financier non négligeable. Même si les RSU sont déployés plus densément
que prévu, ils ne seront pas tous opérationnels durant la phase de déploiement incrémental. Les
communications V2V seront donc aussi utiles durant cette période d’installation. Nous comprenons
ainsi que le V2V joue un rôle primordial afin d’assurer une disponibilité du service. L’architecture
V2V permet les communications critiques (alerte de danger local entre plusieurs véhicules proches,
alerte d’un véhicule de secours se rapprochant, alerte de violation de feux tricolores). C’est pourquoi
nous nous intéressons à ce type d’architecture dans la suite de cette thèse [7].
2.5.3 Communication Véhicule-Infrastructure V2I
L’architecture Véhicule-vers-Infrastructure (V2I) est composée de RSU, auxquels les véhicules
accèdent pour les applications de sécurité, de gestion et de confort. Les RSU sont administrés par
un ou plusieurs organismes publics ou bien par des opérateurs autoroutiers. Un véhicule qui informe
le service de voirie au sujet d’un obstacle est un exemple de communication V2I. Dans cet exemple,
la communication est unidirectionnelle, du OBU vers le RSU. Nous parlons de I2V dans le cas de
communication Infrastructure-vers-Véhicule. Un panneau de signalisation équipé d’un RSU qui
envoie une information aux véhicules passant à proximité est un exemple de communication I2V.
Dans la suite, par V2I, nous englobons toutes les communications Véhicule-Infrastructure, quelle
que soit la direction du trafic de données [7]. La communication V2I est également connue sous le
nom de communication en mode infrastructure. Trois entités s’organisent pour établir ce type de
communication :
• OBU est l’ensemble de composant logiciel embarqué dans le véhicule. Il permet aux
véhicules de se localiser, de calculer et d’envoyer des données sur l’interface réseau.
• RSU est une entité installée au bord des routes, diffuse aux véhicules des informations sur
l’état du trafic et sur les conditions météorologiques. Elle peut être utilisée comme point
d’accès au réseau.
• CA ou centrale d’autorité gère le réseau et joue le rôle de serveur de stockage des données.
La CA délivre également des certificats et des clés ou pseudonymes de communication aux
véhicules.
32
Le mode de communication à infrastructure offre une meilleure connectivité et permet l’accès à
divers services comme l’internet. Cependant, le déploiement des entités fixes le long des routes est
très couteux ; d’où la combinaison des deux modes de communication dans les réseaux VANETs.
Aussi, la communication en mode infrastructure présente un temps de latence dans l’acheminement
des paquets.
2.5.4 Hybride
La combinaison de ces deux types d’architecture de communication permet d'obtenir une
architecture hybride intéressante. En effet, les portées des infrastructures étant limitées, l'utilisation
de véhicules comme relais permet d'étendre cette distance. Dans un but économique et en évitant de
multiplier les bornes à chaque coin de rue, l'utilisation de sauts par véhicules intermédiaires prend
toute son importance. Néanmoins, les communications inter-véhiculaires souffrent de problèmes de
routage lors de transmission longue distance. Dans de telles situations, l’accès à une infrastructure
peut améliorer les performances réseau. Nous comprenons donc la complémentarité des deux types
de communication et l’intérêt d‘une architecture hybride. Un cas particulier de l'architecture hybride
est le réseau VSN (Vehicular Sensor Network). En effet, ce type de réseau émerge en tant que
nouvelle architecture de réseaux de véhicules. Le VSN a pour objectif la collecte et la diffusion
proactive en temps réel des données relatives à l'environnement dans lequel évoluent les véhicules,
et ce, plus particulièrement en zone urbaine. En effet, les voitures sont munies de plus en plus de
capteurs de toutes catégories tels que les caméras, capteurs de pollution, capteurs de pluie, capteurs
d’état des pneumatiques, ESP (Electronic Stability Program), ABS (Anti Blockier System),
géolocalisation satellite. Les informations délivrées par ces équipements peuvent être utiles pour
l'obtention d'états sur le trafic routier, sur les places de parking disponibles, pour des informations
plus générales telles que la consommation moyenne de carburant et le taux de pollution, ou encore
pour des applications de surveillance grâce aux caméras embarquées sur des véhicules [7]. Ces trois
différents types de communications sont illustrés sur la figure 2.05.
33
Figure 2.05 : Types de communications dans les réseaux VANET
2.6 Environnement de déploiement
Le réseau routier est diversifié et propose plusieurs milieux de déplacement. Ces milieux se
différencient par leur localisation que ce soit urbain, périurbain, rural ou montagneux et par leurs
moyens autoroute, route départementale, route nationale, chemins communaux). En raison de leurs
spécificités, nous nous intéressons au milieu urbain et au milieu autoroutier [7].
2.6.1 Milieu urbain
Nous définissons le milieu urbain comme un réseau routier formé d’intersections et de points d’arrêt
(feux tricolores, stop, cédez le passage). Il s’agit d’un environnement où les ondes sont fortement
perturbées à cause de la forte présence de bâtiments notamment. Le milieu urbain se caractérise par
un modèle de mobilité complexe, une densité de véhicules importante et une vitesse réduite qui est
34
inférieure à 60 km/h. De plus, il y a déjà une infrastructure importante. Il semble donc facile
d’ajouter un équipement sur cette infrastructure afin de déployer les réseaux sans fil véhiculaires
(V2I). Dans ce milieu, les réseaux V2V sont aussi réalisables et présentent l’avantage d’éviter le
déploiement de RSU.
2.6.2 Milieu autoroutier
Le milieu autoroutier est caractérisé par une vitesse des véhicules importante, une forte densité et
une impossibilité de couvrir toutes les autoroutes avec des RSU. On y retrouve aussi une forte
diversité de véhicule. En raison de l’absence d’obstacles tels que des immeubles, cet environnement
semble moins perturbant pour les ondes radio. Néanmoins, il rencontre des problèmes d’étalement
Doppler à cause de la vitesse élevée. De plus, certaines solutions actuelles, comme l’analyse par
caméra numérique, sont perturbées par les poids lourds. En effet, ils gênent la vision des caméras,
mais sont aussi des obstacles perturbants pour les communications. Sur une autoroute, un simple
accident peut vite dégénérer à cause, en partie, de la vitesse. La vitesse élevée peut engendrer des
accidents plus graves, et soulève des contraintes de temps réel, de tolérance aux fautes et de fiabilité.
Les applications de sécurité du trafic routier y seront donc très utiles. [7].
2.7 Moyens d’accès
Afin de déployer les applications, nous faisons un tour d’horizon des technologies de
communication sans fil existantes. Ce tour d’horizon permet de présenter les caractéristiques des
technologies envisagées pour les VANETs. Il existe deux types de système possible :
• Les systèmes intra-véhiculaires composés de capteurs internes au véhicule et ne visant pas à
diffuser de l’information vers l’extérieur du véhicule.
• Les systèmes extravéhiculaires visant à l’échange d’informations entre une entité et son
environnement. Les systèmes extravéhiculaires sont divisés en trois sous-systèmes selon leur
utilisation :
Les systèmes de télécommunications, qui sont dominants dans le domaine des
communications mobiles, mais qui nécessitent une infrastructure. Ils sont particulièrement
utilisés pour les applications de confort de l’usager (Internet à bord, vidéoconférence, autres
services payants).
Les systèmes de radio diffusion (éventuellement numériques), qui proposent de l’information
de manière unidirectionnelle. Ils sont particulièrement utilisés pour les applications de gestion
du trafic routier.
35
Les réseaux informatiques extravéhiculaires, qui proposent des échanges directs
d’informations entre les entités. Ils sont particulièrement utilisés pour les communications
V2V et les applications de sécurité routière. Nous allons détailler chacun de ces systèmes.
2.7.1 Systèmes de communication intra véhiculaires
Nous définissons les systèmes intra-véhiculaires comme des systèmes ne visant pas à la diffusion
d’information à l’extérieur du véhicule. Les systèmes intra-véhiculaires sont composés de capteurs,
d’une plateforme de calcul et de réseaux filaires ou sans fil (Bluetooth, WiFi). Ces systèmes ont été
les premiers développés par les industriels. Chaque constructeur pouvait définir son propre système
sans devoir assurer l’interopérabilité avec les véhicules de marque concurrente. Ces systèmes sont
connus sous le nom de systèmes avancés d’aide à la conduite ou Advanced Driver Assistance
System (ADAS). Dans la première phase d'acquisition de connaissance sur l'environnement de
conduite, les systèmes actuels d'aide à la conduite utilisent deux sortes de capteur ou source
d'informations :
2.7.2 Systèmes de communication extra véhiculaires
Dans cette section, nous étudions les réseaux informatiques sans fil extravéhiculaires. Nous
détaillons quatre technologies : l’infrarouge, le WiMax, le Wi-Fi, et le DSRC.
2.7.2.1 WiMax
Le réseau sans fil métropolitain, WiMax, basé sur la norme IEEE 802.16, permet d’atteindre des
débits de 70 Mbit/s sur un rayon de 50 kilomètres. Avec un débit élevé et un délai modéré, le WiMax
est adapté pour l’accès à Internet. Sa version mobile, Mobile WiMax (basé sur le standard IEEE
802.16e), offre aussi une connectivité à moyenne et longue portée, mais adaptée pour des véhicules
à vitesse modérée. Les travaux de Aguado et al démontrent que le WiMax répond aux besoins des
applications temps réel comme la voix sur IP (VoIP) et la vidéo à la demande. Cela positionne
Mobile WiMax comme une solution compétitive dans le contexte des communications véhicule-à-
infrastructure. Mais le déploiement de cette technologie soulève tout de même un problème
d’installation. Contrairement à la 3G qui est déjà présente sur le territoire malgache, le WiMax
nécessite l’installation de stations de base. Cela aura donc un coût financier important. De plus, à
cause de ce besoin constant d’être à portée d’une station de base, le WiMax propose un délai trop
élevé pour les communications V2V [7].
36
2.7.2.2 Wi-Fi
Aujourd’hui, la technologie Wireless Fidélité(Wi-Fi) est devenue omniprésente dans les ordinateurs
portables, les téléphones portables ou les consoles de jeux. Grâce à cette démocratisation et le faible
coût de production, la technologie Wi-Fi est une technologie abordable pour le déploiement de
réseaux sans fil véhiculaires. Depuis la fin des années 1990, date d’apparition des premiers
équipements utilisant la technologie Wi-Fi sur le marché, trois spécifications de la couche physique
pour le standard IEEE 802.11 furent ajoutées afin d’accroitre la vitesse de transmission. La dernière
spécification en date est le 802.11n qui propose des débits théoriques de 300 Mbit/s.
Malheureusement, en pratique le surcoût du protocole réduit de moitié les débits potentiels de la
couche application. Cette dégradation de débit peut être pénalisante, surtout dans les réseaux
véhiculaires. À première vue, la couverture radio omnidirectionnelle de 400 mètres semble
suffisante pour maintenir une connectivité multi saut dans le milieu autoroutier ou urbain. Mais de
nombreux travaux de recherche ont démontrés qu’à cause des caractéristiques uniques des
VANETs, cette technologie ne peut pas être appliquée telle quelle. À plus forte raison dans le
contexte d’application de sécurité du trafic routier où le IEEE 802.11(g) affiche un taux de perte de
paquets élevé à vitesse élevée [7].
2.7.2.3 DSRC
Dedicated Short Range Communication (DSRC) regroupe un ensemble de technologies dédiées aux
communications véhiculaires. À l’origine, la technologie DSRC a été conçue pour répondre au
besoin de transactions financières électroniques ou le télépéage. C’était un modèle de
communication à courte portée de 4 à 10 mètres avec des débits inférieurs à 1 Mbit/s. Ensuite, le
standard DSRC a évolué à partir du IEEE 802.11a vers la norme IEEE 802.11p ou WAVE (Wireless
Access for Vehicular Environments) afin de répondre aux caractéristiques des VANETs. Le DSRC
propose un canal de communication spécialement conçu pour transmettre des messages de très haute
priorité à l'instar de certains messages critiques liés à la sécurité routière. Le WAVE présente aussi
des caractéristiques beaucoup plus adaptées à la mobilité comme des temps d'établissement de
connexion plus courts qui permettent l'envoi à la volée d'informations à des véhicules roulants à
grande vitesse. Il présente une bonne fiabilité avec un taux d’erreur de 10-6 à 160 km/h. La
technologie IEEE 802.11p est particulièrement adaptée pour les applications à portée moyenne et
37
sensibles au délai [5]. Le tableau ci-dessous représente les diverses caractéristiques des réseaux
informatiques cités plus haut.
WiMax Wi-Fi DSRC
Débit (Kbps) DL/UL : 4500-
22000
DL/UL : 54000 DL/UL : 3000-
27000
Portée
maximale
50 km 400 m 1 km
Aptitude à la
mobilité
Moyenne
70 km
Elevée
250 km/h
Elevée
300 km/h
Support trafic
temps réel
Oui Oui Oui
Latence (ms) 50 Selon
Implémentation
< 5
Mode de
transmission
V2I V2V, V2I V2V, V2I
Tableau 2.01: Comparaison entre les diverses technologies de communication
2.8 La bande DSRC
Pour mettre en place la communication entre les différentes entités dans les réseaux véhiculaires
sans fil, l'ASTM (American Society for Testing and Materials) a adopté en 2002, une norme de
communication appelée DSRC (Dedicated Short Range Communication), dont la couche physique
est basée sur la norme IEEE 802.11a. En 2003, l'IEEE s'inspirant des travaux de l'ASTM, a étendu
sa famille de standard 802.11 en y ajoutant le 802.11p [8].
DSRC regroupe un ensemble de technologies dédiées aux communications véhiculaires. Cette
technologie a évolué à partir de la norme IEEE 802.11a vers la norme IEEE 802.11p ou WAVE afin
de répondre aux caractéristiques des réseaux VANETs. Le DSRC œuvre dans la bande de fréquence
de 5.9 GHZ. Cette bande de fréquence est divisée en 7 canaux de 10 MHZ chacun. L'ensemble de
38
ces canaux se répartit fonctionnellement en 1 canal de contrôle et 6 canaux de services. Le canal de
contrôle est réservé à la transmission des messages de gestion du réseau et des messages très
importants tels que les messages liés à la sécurité routière. Les 6 autres canaux sont dédiés à la
transmission des données des services annoncés sur le canal de contrôle. La numérotation des
canaux commence de 172 à 184 en ne prenant que les nombres pairs. Le canal 178 représente le
canal de contrôle. L'étude comparative réalisée sur les technologies d'accès prouve que le DSRC
peut assurer le bon fonctionnement des applications de sécurité du trafic routier. Le DSRC propose
un débit (atteignant 27 Mbps) suffisant pour le volume de données transporté. Aussi avec une
latence faible (inférieur à 5 ms), la technologie DSRC supporte une forte mobilité (aptitude à la
mobilité élevée à 300 km/h) sur une portée maximale théorique de 1000 m, ainsi que le trafic de
données temps réel. Il s'adapte à tous les types de communication véhiculaires [8].
Figure 2.06 : Canaux DSRC
2.9 Architecture de communication WAVE
WAVE ou Wireless Access in Vehicular Environment est une nouvelle plateforme qui permet
d’offrir des services dédiés aux transports routiers. Cette technologie permet de réaliser des
communications entre des véhicules V2V mais elle permet aussi de faire dialoguer les équipements
routiers, disposés sur les bords de route, avec les véhicules V2I. Le canal de propagation est défini
par DSRC sur la bande de 5.9GHz. Cette bande est divisée en section de 10MHz et constitue ainsi
7 canaux dont les 6 sont alloués aux services et un canal pour le contrôle. La gestion de ces canaux
seront définies plus tard dans la norme IEEE 1609.4. WAVE utilise la norme IEEE 802.11p qui est
assez similaire à la norme 802.11a. Son débit minimum est de 3 Mbit/s et le maximum de 27 Mbit/s
au niveau de la couche physique. Une RSU dispose d’une portée d’environ 1000 mètres avec le
débit minimum et la puissance maximale autorisée. La norme ETSI standardise les allocations de
canaux en Europe, tout comme la norme IEEE 1609 le fait aux États-Unis. Dans les deux standards,
il existe deux types de canaux : un canal de type contrôle et les autres de type service [9].
Guard Band
Control CHannel
Service CHannel
39
L’intermittence provoquée par le faible déploiement d’infrastructures liées à cette technologie
entraîne une latence importante pour les fichiers qui ne peuvent pas être reçus lors du passage auprès
d’une seule RSU, ou bien encore lorsque la transmission commence au moment de la sortie du
véhicule de l’aire de couverture. En 2013, le taux de pénétration reste toujours faible et le prix des
dispositifs élevé. Cependant, dans les années à venir, comme ce fut le cas avec le Wifi, cette
technique pourrait être largement utilisée. Il est important de souligner que la fréquence utilisée est
réservée aux réseaux de véhicules ce qui réduit les interférences. Le coût d’utilisation de
l’infrastructure pourrait être fonction de l’application. Pour les applications de sécurité routière, le
coût serait nul. Pour le téléchargement de mises à jour de cartes, le plus probable est que les
fournisseurs de cartes payent l’accès à l’infrastructure et l’utilisateur l’abonnement. Ces coûts
seraient uniquement imputés lors d’une utilisation effective de l’infrastructure. En revanche,
l’utilisation de communications V2V pourrait être gratuite [9].
2.10 Pile de protocole WAVE
L’architecture en couche de la technologie WAVE est influencée par le modèle en couche OSI
(Open Systems Interconnection) de l’ISO (International Standardization Organization) et affiche
clairement une correspondance dans les diverses tâches effectuées par les couches.
Figure 2.07 : Architecture en couche de la technologie WAVE et modèle OSI
APPLICATION
PRESENTATION
LIAISON DE DONNEES
SESSION
TRANSPORT
PHYSIQUE
RESEAU
AP
PLI
CA
TIO
N
TRA
NSP
OR
T D
E D
ON
NEE
S
PHY
LLC
SERVICE RESEAU
MAC
COUCHE SUPERIEURE
LLC
LLC
LLC
LLC
40
Les différentes couches de WAVE sont fortement influencées par l’architecture du réseau
informatique Wi-Fi du fait que les couches PHY MAC (Medium Access Control) et LLC (Logical
Link Control) sont présentes. Sur la couche physique, WAVE propose WAVE PHY, et utilise la
norme IEEE 802.11p pour la gestion des canaux de transmission DSRC. Sur la couche MAC,
WAVE propose WAVE MAC et l’opération multi-canal s’appuyant sur la norme IEEE 802.11p et
IEEE 1609.4 que nous expliquerons plus tard. La couche LLC peut se basée souvent sur la norme
IEEE 1609.3 pour WAVE. Les couches de transport et réseau sont combinées en une couche mais
utilisent néanmoins des protocoles tels que UDP ou TCP pour le transport et IPv6 pour le réseau.
WAVE propose aussi WSMP (WAVE Short Message Protocol) combinant à la fois le transport et
le réseau. La norme utilisée pour cette couche est l’IEEE 1609.3. Enfin, pour la couche applicative
la norme IEEE 1609.1 sera utilisée. WAVE divise en deux l’utilitaire de cette architecture en couche
pour le plan de gestion et le trafic de données comme illustré sur la figure 2.08.
Figure 2.08 : Plan de gestion et de trafic de WAVE
2.10.2 Couche PHY de WAVE et modulation OFDM
La couche physique PHY représente une interface entre la couche MAC et l’agent qui permet
d’envoyer et de recevoir les trames. Elle est essentiellement responsable des spécifications
concernant les matériels, la conversion en train de bit, le codage et la formalisation des données. La
41
couche PHY de WAVE est similaire à celle du Wi-Fi qui est contrôlée par la norme IEEE 802.11a.
cette couche est divisée en deux sous couches comme illustrée sur la figure 2.11 [10].
Le premier est la sous couche PLCP (Physical Layer Convergence Protocol). Cette dernière est
responsable de la communication avec la couche supérieure MAC. Elle permet de convertir le
Packet Data Unit PDU venant de la couche MAC en symbole OFDM à transmettre ensuite sur canal
de propagation. La seconde sous couche est la PMD ou Physical Medium Access. Cette dernière
n’est autre qu’une interface pour la transmission physique comme le canal radio et la liaison fibre.
Ses taches consistent à faire le codage la modulation des données [10].
Figure 2.09 : Les sous couches de la couche PHY
2.10.2.2 Modulation OFDM
Le principe de la modulation OFDM est de découper la bande de fréquence du système en plusieurs
sous porteuses de nombre N. On reparti un flux binaire, sous forme de symbole, à un rythme 𝑇𝑑 sur
l’ensemble des sous-porteuses. On obtient par la suite un symbole OFDM de durée 𝑇𝑆 = 𝑁. 𝑇𝑑 . La
durée de 𝑇𝑆 doit être supérieure au délai maximal d’étalement de spectre d’où les interférences entre
symbole est limitée. Contrairement aux modulations mono-porteuses où les données sont émises en
série, ces systèmes reposent sur le principe de transmission par bloc. La modulation d’un bloc de
symboles (ce bloc constituant un symbole OFDM) est réalisée par une transformée de Fourier
inverse. Après modulation M-QAM, on obtient un symbole 𝐶𝑘 qui arrive en série sur l’entrée du
modulateur. Un premier bloc transforme les symboles 𝐶𝑘 série en parallèle puis transitent dans un
second bloc qui applique une transformée de Fourrier Rapide Inversée (IFFT) et on obtient par la
suite les symboles OFDM x(t) auxquels on ajoute le Cyclic Prefix (CP) pour éviter l’étalement de
spectre. Le CP contient une copie de la fin de ce même symbole et est aussi exploité pour la
synchronisation temporelle.
PHY
PLCP
PMD
42
𝑥(𝑡) = 1/𝑁 ∑ 𝐶𝑘𝑒𝑗2𝜋𝑘∆𝑓𝑡
𝑁−1
𝑘=0
(2.01)
Avec 𝑇𝑠 ≥ 𝑡 ≥ 0,
𝑇𝑠 : durée d’un symbole OFDM
∆𝑓 : Différence de fréquence entre les sous-porteuses
Figure 2.10 : Procédée de la modulation OFDM
Notons que l’ordre d’exécution de la modulation M-QAM et la conversion Série/Parallèle peut être
inversé ne causant aucun effet sur la modulation OFDM. Il en est de même pour l’intervalle de garde
et le convertisseur Parallèle/Série. Voici une figure récapitulant la transmission des données au
niveau de la couche PHY :
𝑥2
𝑥1
𝑥0
𝐶𝑁−1
𝐶1
𝐶0
𝐶2
𝑥𝑁−1
S/P IFFT P/S CP RF
M-
QAM .
.
.
.
.
.
.
.
43
Figure 2.11 : Transmission des données au niveau de la couche PHY
2.10.3 Couche MAC et l’opération multicanal
La couche MAC du protocole 802.11 offre un mécanisme de contrôle et de correction d'erreur
permettant de vérifier l'intégrité des trames grâce au champ FCS ou frame check sequence. Il s’agit
là d’une différence fondamentale avec le standard Ethernet. En effet Ethernet propose un système
de détection d'erreurs (CRC), mais ne propose pas de correction d'erreurs, cette tâche étant laissée
aux protocoles de transports de niveau supérieur (TCP). Dans un réseau sans fil le taux d’erreur est
plus élevé, c'est la raison pour laquelle un contrôle d'erreur a été intégré au niveau de la couche
liaison de données [11]. La couche MAC assure entre autres l’association du nœud au réseau, le
contrôle d’accès au support, le formatage des trames et adressage Contrôle d’erreur par CRC. Cette
couche gère aussi la fragmentation et réassemblage des trames, contrôle la qualité de service ainsi
que la gestion d’énergie, la Gestion de la mobilité et la sécurité. Le standard 802.11 utilise 3 types
de trames MAC qui sont la trame de donnée qui est employée pour la transmission des données, la
trame de contrôle et la trame de gestion pour gérer l’information au niveau MAC
2.10.3.1 Méthodes d’accès
Le standard 802.11 spécifie trois types de méthodes d’accès au niveau de la couche MAC :
Distributed Foundation Wireless-Distributed Coordination Function Carrier Sens Multiple Access
(DFWMAC-DCF CSMA/CA), DFWMAC-DCF with/Request To Send/Clear To Send
(DFWMAC-DCF w/RTS/CTS) et DFWMAC-Point Coordination Function (DFWMAC-PCF)
a. DFWMAC-DCF CSMA/CA
44
• Moins connu que le CSMA/CD (CSMA/Collision Detection), l’accès CSMA/CA (Carrier
Sense Multiple Access/Collision Avoidance) commence à être fortement utilisée dans les
réseaux Wi-Fi, c’est-à-dire les réseaux Ethernet sans fil IEEE 802.11. C’est une variante du
CSMA/CD, qui permet à la méthode CSMA de fonctionner lorsque la détection des
collisions n’est pas possible, comme dans l’hertzien. Son principe de fonctionnement
consiste à résoudre la contention avant que les données soient transmises en utilisant des
accusés de réception et des temporisateurs. Une station voulant transmettre écoute le
support, et s’il est occupé, la transmission est différée. Si le support est libre pour un temps
spécifique (appelé DIFS, Distributed Inter Frame Space, dans le standard), alors la station
est autorisée à transmettre après une durée tirée aléatoirement en se basant sur l'algorithme
de Backoff exponentiel. La station réceptrice va vérifier le CRC du paquet reçu et renvoie
un accusé de réception (ACK). La réception de l’ACK indiquera à l’émetteur qu’aucune
collision n’a eu lieu. Si l’émetteur ne reçoit pas l’accusé de réception, alors il retransmet le
fragment jusqu'à ce qu'il l’obtienne ou abandonne au bout d’un certain nombre de
retransmissions. C’est la couche MAC qui est informée des collisions par l’attente d’un
accusé de réception (ACK) pour chaque fragment transmis. Dans le cas de non réception
d'un ACK, la couche MAC retransmet le paquet sans avoir à passer par les couches
supérieures, ce qui engendrait des délais significatifs. La différence majeure entre
CSMA/CA et CSMA/CD est la possibilité de détection de collisions. Dans la technique
CSMA/CD, la collision est détectée à l'émission car les stations ont la possibilité de
continuer à écouter leurs transmissions en cours. En revanche, cette collision ne pourra pas
être détectée qu'au niveau du récepteur dans le cas du mécanisme CSMA/CA [11].
a. Temporisateur IFS
La norme 802.11 définit quatre types d'espace entre deux trames IFS (Inter Frame Space). Ils sont
classés du plus court au plus long :
• Le premier, le SIFS (Short IFS) est le plus court de tous. Il est utilisé pour la transmission
des trames ACK, CTS, réponse à un polling…et des rafales de trames issues d’une même
station.
• Le second PIFS (PCF IFS) est utilisé en mode PCF. Il permet aux transmissions PCF de
gagner l’accès au médium par l’utilisation d’un IFS plus petit que celui utilisé pour la
transmission des trames en DCF.
45
• Le troisième DIFS (DCF IFS) est le plus couramment utilisé (avec le SIFS). Il est utilisé en
mode DCF comme temps minimal d’attente avant transmission.
• Enfin, le quatrième et plus long EIFS (Extended IFS) est utilisé lorsqu’il y a détection de
collision. Ce temps relativement long par rapport aux autres IFS est utilisé comme inhibiteur
pour éviter des collisions en série.
Les valeurs des différents PIFS et DIFS sont calculées de la manière suivante :
PIFS=SIFS + Slot Time
DIFS= SIFS + 2 * Slot Time
Où Slot Time=durée minimale pour déterminer l'état du canal + temps aller-retour + temps de
propagation.
Figure 2.12 : Distribution des IFS
La valeur de SIFS est fixée par la couche physique et est calculée de telle façon que la station
émettrice sera capable de commuter en mode réception pour pouvoir décoder le paquet entrant. Ces
IFS permettent de définir des degrés de priorité. Lorsque plusieurs stations souhaitent émettre
simultanément, la station souhaitant émettre les trames les plus prioritaires comme les acquittements
pourra les envoyer en premier. Puis seront transmises d'autres trames jugées prioritaires comme
celles liées à l'administration réseau ou au trafic qui a des contraintes de délai. Enfin, les
informations les moins importantes concernant le trafic asynchrone seront émises après un temps
d'attente plus long [11].
b. DFWMAC-DCF w/RTS/CTS
Il peut tout de même survenir des collisions malgré l'algorithme de reprise après collision BEB et
l'acquittement des trames. Pour éviter surtout les problèmes des stations cachées et des trames
longues (où les transmissions coûtent du temps et la ressource spectrale), le standard définit un
46
mécanisme optionnel qui permet de faire des réservations de canal. Ce mécanisme est appelé écoute
virtuelle de porteuse [11].
Une station voulant émettre transmet d'abord un petit paquet de contrôle appelé RTS (Request To
Send), qui comprend la source, la destination, et la durée de transmission. La station destination
répond, si le canal est libre, avec un paquet de contrôle de réponse appelé CTS (Clear To Send) qui
inclura les mêmes informations sur la durée [11].
Toutes les stations écoutant soient la trame comprenant la demande de canal RTS, soit la trame de
réponse de réservation CTS, déclencheront leur indicateur de l'écoute virtuelle (Virtual Carrier
Sense) appelé NAV pour Network Allocation vector pour une certaine durée, et utiliseront cette
information avec la procédure d'écoute de support.
Grâce à l’envoi de la trame RTS, toutes les stations situées dans la couverture radio de la source
sont informées d’une transmission imminente et de sa durée éventuelle. Elles peuvent ainsi mettre
à jour leur NAV et passer en mode économie d’énergie pour la dite durée. Le CTS a le même rôle
d’annonce mais cette fois autour du récepteur. Ces deux trames sont courtes (20 octets pour RTS et
14 octets pour CTS) et rencontrent donc une faible probabilité de collisions [11].
La figure ci-dessous illustre le CSMA/CA avec les mécanismes RTS et CTS :
Figure 2.13 : Mécanisme RTS et CTS
c. DFWMAC-PCF
47
La PCF est une méthode optionnelle et donc peut être ou ne pas être implémentée dans les matériels
802.11. La PCF consiste en une gestion centralisée des ressources. C’est le point d’accès qui
ordonne les transmissions et distribue le droit à la parole. C’est par l’intermédiaire de trames
d’administration définies à cet effet qu’une sollicitation explicite est effectuée auprès d’une station
(mécanisme de polling) pour lui attribuer le droit à émettre.
PCF ne peut travailler seul, il utilise DCF. L’AP prend le contrôle du support et choisit les stations
qui peuvent transmettre. Il existe 2 périodes différents dans l’utilisation du DCF et du PCF lorsqu’il
travaille ensemble :
Le DCF est utilisé pendant le CP (Contention Period). La partie scrutation des stations ou polling
effectué par l’AP est exécutée pendant le CP. Au début de CFP (Contention Free Period),
l’utilisateur possède le monopole du support puisque à chaque début du CFP le nœud détecte si le
support est libre ou occupé. Si le support est libre après un temps PIFS, l’utilisateur envoie une
trame balise ou beacon. Cette balise inclue les paramètres d’initialisations des contentions Free.
Apres réception de la trame balise, la station initialise le temporisateur appelé NAV (Network
Allocation Vector). Dans la trame beacon se trouve un champ durée. Ce champ contient une valeur
à utiliser pendant la CFP. [11]
PCF est appelé mode d’accès contrôlé. En effet, le PC interroge à tour de rôle les stations. Une
station ne peut émettre qu’après autorisation. Le récepteur ne peut recevoir que si elle est
sélectionnée [11].
2.10.3.2 Opération multi-canal
Au niveau de la sous-couche supérieure MAC de la pile protocolaire WAVE, un mécanisme de
multi canal est proposé. Il divise un intervalle de synchronisation, d’une durée de 100 ms, en deux
temps égaux de 50 ms. Le premier d’entre eux est réservé à l’envoi de messages de sureté sur le
canal CCH (Control CHannel), dans le but de maximiser la réception de ces messages prioritaires,
ainsi qu’à la transmission des messages de gestion du réseau, pour ordonnancer le basculement entre
canaux par exemple. Durant le deuxième intervalle, les véhicules sont libres de choisir leur canal
d’écoute. Afin de permettre le changement de canal d’écoute, un intervalle de garde de 4 ms est
déclenché. Durant celui-ci, le canal est considéré comme occupé et aucun véhicule ne peut
transmettre de message [12].
48
Figure 2.14 : Opération multi canal sur les canaux CCH et SCH
2.10.3.3 Mécanisme de control d’accès EDCA
La sous-couche MAC du standard IEEE 802.11p utilise le mécanisme de contrôle d’accès EDCA
ou Enhanced Distributed Channel Access, proposé dans le standard IEEE 802.11e pour introduire
la différence de service lors de l’accès au canal, via l’utilisation de quatre catégorie d’accès (ACs).
Ces ACs sont : Voix, Vidéo, Best Effort pour les application standards et Background pour le reste
des applications. Cette dernière nécessite le moins de qualité de service. Ces categories sont aussi
nommées AC3, AC2, AC1 et AC0 dans l’ordre. Chacune d’elles dispose de ses propres valeurs de
paramètres pour la taille minimum et maximum de la fenetre de contention, 𝐶𝑊𝑚𝑖𝑛 et 𝐶𝑊𝑚𝑎𝑥, ainsi
que le nombre d’espacement temporel entre trames, AIFSN. Ces valeurs sont données dans le
tableau ci-dessous, où 𝐶𝑊𝑚𝑖𝑛 est égal à 15 et 𝐶𝑊𝑚𝑎𝑥 est égal à 1023 d’après le standard. La valeur
du paramètre AIFSN(AC) permet de calculer le temps qu’un message de catégorie AC doit attendre
avant de lancer son backoff, soit le temps Arbitration Inter-Frame Space (AIFS) calculé avec
l’équation ci-dessous, où la valeur de SIFS est égale à 32 us et la durée d’un slot time est égale à 13
us. Plus les valeurs de 𝐶𝑊𝑚𝑖𝑛[𝐴𝐶], 𝐶𝑊𝑚𝑎𝑥[𝐴𝐶] et AIFSN(AC) sont petites et plus la catégorie est
prioritaire car l’accès au canal est plus rapide [12].
AIFS[AC] = SIFS + AIFSN[AC]×SlotTime
49
Dans le standard IEEE 802.11p, la valeur du paramètre TXOPLimit est égale à 0 pour toutes les
catégories d’accès. Le paramètre TXOPLimit représente un intervalle de temps durant lequel un
véhicule a le droit d’émettre en continu les messages d’une même catégorie, sans repasser par un
contrôle d’accès au canal. Avec une valeur égale à zéro, les véhicules ne peuvent envoyer qu’un
seul message à la fois [12].
AC 𝐶𝑊𝑚𝑖𝑛[AC] 𝐶𝑊𝑚𝑎𝑥[AC] AIFSN[AC]
AC0 𝐶𝑊𝑚𝑖𝑛 𝐶𝑊𝑚𝑎𝑥 9
AC1 𝐶𝑊𝑚𝑖𝑛 𝐶𝑊𝑚𝑎𝑥 6
AC2 (𝐶𝑊𝑚𝑖𝑛 + 1)2 − 1 𝐶𝑊𝑚𝑎𝑥 3
AC3 (𝐶𝑊𝑚𝑖𝑛 + 1)4 − 1 (𝐶𝑊𝑚𝑎𝑥 + 1)2 − 1 2
Tableau 2.02: Tableau des fenêtres de contention
2.10.4 Le plan de gestion dans le standard WAVE
Le plan de gestion du standard IEEE 1609.4 s’occupe de la synchronisation en temps réel, le contrôle
de l’accès aux canaux, la réception des trames VSA (Vendor Specific Action), maintien du MIB
(Management Information Base), le changement de l’adresse MAC et l’accès aux autres services.
Les couches MAC et PHY incluent des entités de gestion appelées MAC sublayer Management
Entity pour la couche MAC et PHY Layer Management Entity MLME. Ces deux entités fournissent
des interfaces à travers lesquels les fonctions de gestion seront invoquées [9]. La figure suivante
définie la partie gestion du standard WAVE.
Figure 2.15 : Plan de gestion WAVE
WME
MLME Extension
MLME
PLME
50
a. MLME et PLME
Les services de gestion au niveau de la couche MAC jouent un rôle essentiel dans la norme IEEE
802.11 du fait qu’elles fournissent les fonctions concernant l’intégration des nœuds au niveau du
système. Ces principales fonctions se portent sur la synchronisation qui tend à trouver un WLAN et
d’y rester, la synchronisation interne ou TSF (Timing Synchronisation Function) utilisée pour la
gestion de la puissance, la coordination du PCF et la synchronisation au niveau de l’OFDM. La
génération de balise ou beacon signal est aussi assuré par le MLME. Le contrôle de la puissance
consiste à équilibrer au maximum le niveau de puissance par rapport aux exigences des nœuds et la
capacité en termes d’énergie. Pour se faire, des techniques sont employées pour optimiser au
maximum la consommation d’énergie dont le sleep-mode, periodic sleep, frame buffering, mesure
du trafic. MLME est aussi responsable des handover permettant d’associer un équipement OBU
d’une cellule à une autre. Enfin MLME fourni le MIB ou Management Information Base [9][13].
• Si un équipement WAVE demande à acceder à un canal, il doit tout d’abord se synchroniser
avec l’UTC Universal Time Coordinated time. Ce procédé peut être réalisé à partir d’une
source externe comme le GPS qui fournit un signal 1PPS (Precise Pulse per Second) qui est
utilisé pour mettre à jour le temps universel UTC de l’équipement WAVE. Pour les
équipements qui ne possède pas de GPS ils peuvent utiliser le TA ou Timing Advertisement
qui met à jour leurs temps internes basé sur le fournisseur du Timing Advertisement. La
transmission du TA commence au niveau de la MLME Extension. Cette dernière reçoit une
requête de la couche supérieure. Cette requête contient l’identifiant du canal, l’intervalle de
canal, l’adresse MAC du destinataire, et le taux de répétition sont optionnellement inclus.
La MLME Extension génère ensuite une requête pour envoyer le TA au MLME. Cette
requête est fournie selon le taux de répétition, et contient l’information nécessaire pour
l’équipement afin qu’il puisse mettre à jour son temps universel UTC. Aussi tôt que le
MLME reçoit la requête, il transmet une trame TA. Ce TA est reçu par la couche inferieure
et les données passent au MLME Extension qui, par la suite, génère son propre UTC basé
sur le TA.
• Le standard IEEE 1609.4 propose deux types de canaux : CCH ou Control Channel et SCH
ou Service Channel. Le CCH est utilisé pour le gestion des données prioritaires. Les SCH
sont utilisés pour les données à priorité moyen. Il existe un CCH et 6 SCH. 4 modes d’accès
51
sont proposés : le mode Continu, Alterné, Immédiat et étendue comme illustré sur la figure
2.16.
Figure 2.16 : Modes de distribution des canaux CCH et SCH
• Les Vendor Specific Action ou trame VSA Frames sont des trames de gestion définis
par le standard 802.11 et sont utilisés pour la transmission des WSA ou WAVE
Service Advertisement comme toutes les données de gestion. La transmission des
VSA se fait de la même manière que celle des TA. Le VSA est reçu depuis la couche
supérieure en forme de requête. Le champ réservé pour le VSA contient : le
Management ID, Organisation Identifier et le VSC ou Vendor Specific Content [9].
• Management Information Base ou MIB est géré par le PLME et contient les
informations concernant les entités 1609.4. le contenu de ces informations sont : la
‘capacité’ qui spécifie quels caractéristiques sont associés à l’equipement, la
commutation contenant la longueur du canal et de l’intervalle de garde, le table des
canaux qui contient les informations des canaux valides d’usage, la table EDCA
CCH contenant les informations sur les paramètre EDCA du CCH, la table EDCA
SCH contenant les informations sur les paramètres EDCA des canaux SCH, la table
de profil de transmission où on y trouve les informations sur les paramètres des
données IP sur le SCH et le Timing Information dont on peut retrouver les
informations sur l’UTC time [9].
52
2.11 Protocole de routage dans les réseaux VANET
Le routage joue un rôle très important dans les VANET puisque tous les services supportés, unicast
ou multicast, se basent sur des communication multi-saut pour l'acheminement des données. Les
transferts de fichiers et les jeux. Les communications multicast sont utilisées dans les applications
de sécurité et de gestion de trafic telles que l'avertissement de collision et le platooning ou
sectionnent. Pour réaliser les échanges, les protocoles de routage utilisent des informations locales,
sur le voisinage immédiat, ou globales, concernant tout le réseau, pour déterminer les nouds relais
qui participent à l'acheminement des données. Les communications unicast sont généralement
utilisées dans les applications de confort. Les réseaux véhiculaires ont comme caractéristique
principale une forte mobilité qui entraîne une topologie très dynamique. Cette caractéristique fait
que les protocoles de routage traditionnels des MANETS sont pour la plupart inadaptée aux
VANETS. En effet, dans les VANETS, la vitesse peut être beaucoup plus élevée que les MANETS
dans certains environnements de communication comme les autoroutes. Différentes solutions pour
le routage dans les réseaux VANET ont été proposées, nous distinguons deux classes de protocoles
de routage : les protocoles basés sur la Unicast (topologie) qui sont divisés en protocoles proactifs,
réactifs et hybrides et les protocoles basés sur la localisation (géographique) qui utilisent la position
physique des nœuds mobiles pour configurer le routage [14].
2.12 Standard de communication sans fils dans les réseaux véhiculaires
2.12.1 IEEE 1609.4 et IEEE 802.11p
Le standard IEEE 802.11p définit la couche physique du système DSRC. La technologie DSRC est
définie dans la bande de fréquence des 5.9 GHz sur une largeur de bande totale de 75 MHz (5.850
GHz – 5.925 GHz). Cette largeur de bande est segmentée en 7 canaux de 10 MHz chacun. Ces
canaux se répartissant fonctionnellement en 1 canal de contrôle (CCH) et 6 canaux de service (SCH),
chacun pouvant offrir des débits allant de 6 à 27 Mbit/s. Optionnellement, des canaux peuvent être
configurés sur une largeur de bande de 20 MHz, ce qui permet d'obtenir des débits pouvant aller
jusqu'à 54 Mbit/s. La portée de transmission d’un système DSRC peut atteindre les 1000 mètres. Le
standard IEEE 1609.4 définit l’organisation, l’ordonnancement et l’utilisation de ces différents
canaux. Le but de l’IEEE 1609.4 est de définir un mécanisme permettant à plusieurs équipements
(multicanaux) de se trouver, c’est-à-dire s’accorder sur le même canal au même moment afin de
pouvoir communiquer. Deux concepts sont utilisés : le rendez-vous et la répartition dans le temps
[7].
53
• Le canal de rendez-vous est un canal que chaque équipement doit consulter à intervalle régulier.
Le canal de contrôle (CCH) est le canal de rendez-vous du standard IEEE 1609.4. Les autres
canaux sont des canaux de services (SCH). Le canal de contrôle est notamment réservé à la
transmission des messages de gestion du réseau (basculement entre canaux, annonces de
services, etc.).
• Le concept de répartition dans le temps suppose que tous les équipements ont accès à une source
commune de temps afin d’être synchronisés. Cette source de temps est disponible dans des
systèmes globaux de positionnement comme le GPS. En l’absence de récepteur GPS, un
équipement peut être synchronisé en recevant des signaux de temps depuis un autre équipement.
Une fois les OBU synchronisés, l’IEEE 1609.4 impose un ordonnancement entre le CCH et les
SCH afin d’assurer un service garanti aux applications de sécurité routière et un service
minimum aux autres types d’applications.
Le standard IEEE 1609.4 a une forte relation avec le mécanisme EDCA de la sous-couche MAC.
EDCA (Enhanced Distributed Channel Access) est basé sur CSMA/CA et est utilisé dans les réseaux
WiFi supportant le standard IEEE 802.11e. EDCA assure un accès au support distribué et différencié
en utilisant huit niveaux de priorité utilisateurs pour quatre catégories d’accès (Voix, Video, Best
Effort, Background). Ce mécanisme permet ainsi d’attribuer une priorité à chaque message. Par
exemple, un message d’application de sécurité du trafic routier aura une priorité supérieure à celle
d’un message d’application de confort [7].
2.12.2 IEEE 1609.1
Le standard IEEE 1609.1 se positionne au niveau de la couche application et définit les formats de
messages et le mode de stockage des données utilisées par la couche application. Ce standard définit
un gestionnaire de ressources qui autorise des applications de l’équipement de bord de route (RSU)
à communiquer avec les On-Board Units(OBU) des véhicules à proximité. Il décrit trois composants
de la couche application qui seront inclus dans un OBU :
• Resource Manager Applications(RMA) : Entité distante qui utilise le RM pour communiquer
avec le RCP.
• Resource Manager(RM) : Le gestionnaire des ressources relaie le message du RMA vers le
RCP. Le RM assure les services qui permettent au RMA de contrôler les interfaces présentes
dans l’OBU.
54
• Resource Command Processor(RCP) : Il exécute les commandes données par le RMA et fournit
une réponse au RMA via le RM.
Lorsqu’une application (présente sur un OBU ou un RSU) veut envoyer une commande à un OBU,
le composant RMA envoie un message au RM. Le RM envoie la commande au RCP qui va
commander les OBU connectés. Le RCP enverra un message de réponse au RM afin de délivrer le
résultat. Le RM est donc le lien entre les applications d’un RSU (ou OBU) et les OBU d’autres
véhicules. La figure 2.17 représente les modules du standard IEEE 1609.1 [7].
Figure 2.17 : Modules du standard IEEE 1609.1
2.12.3 IEEE 1609.2
Le but de ce standard est de définir le format des messages sécurisés pour le système DSRC/WAVE.
Le standard spécifie les méthodes pour sécuriser les messages de gestion et d’application. Il décrit
aussi les procédures que doit accomplir le véhicule afin d’assurer les services de sécurité tels que
l’authenticité, la confidentialité, l’intégrité, ou la non-répudiation. Bien que chaque application ne
requiert pas forcément tous les services de sécurité, certains sont obligatoires. Par exemple, les
applications de sécurité routière n’ont pas besoin de confidentialité contrairement aux applications
de transactions financières. Pourtant ces deux types d’applications nécessitent l’authenticité du
55
véhicule et du message. Selon les services de sécurité déployés, le format de message est différent.
Par exemple, un message de transaction est signé et chiffré tandis que le message d’alerte est
seulement signé. Le IEEE 1609.2 protège ainsi les messages et les véhicules d’attaques comme
l’écoute clandestine, l’usurpation d’identité, l’altération, ou le rejeu de message [7].
2.12.4 IEEE 1609.3
Le standard 1609.3 définit le WAVE Short Message(WSM) et le protocole d’échange associé
WAVE Short Message Protocol(WSMP) afin d’assurer les fonctionnalités des couches réseau et
transport pour les applications de sécurité routière. Le 1609.3 définit aussi le message WAVE
Service Advertisement (WSA), qui est utilisé pour annoncer la disponibilité de services DSRC à
une localisation donnée. Un WSA peut par exemple être envoyé pour annoncer la présence d’un
service d’information trafic offert par un RSU.
La couche réseau utilise le protocole IPv6 pour ses caractéristiques de mobilité, de qualité de service
et son espace d’adressage important. En effet, cette dernière caractéristique est primordiale dans un
système avec plus de 500 millions de véhicules dans le monde. Le protocole IPv6 est utilisé pour
les applications financières par exemple. D’un autre côté, le protocole WSMP est présenté comme
une alternative à IPv6. Dans WSMP, les messages sont routés avec un identifiant de classe
d’application (Application Class IDentifier, ACID) et une marque de contexte applicatif
(Application Context Mark, ACM) en lieu et place de l’adresse IP et de l’identificateur de flux (flow
label). Le WSMP permet aussi le contrôle de la puissance de transmission, du canal et du débit. Les
applications de sécurité routière comme l’alerte de danger local (LDW) utilisent le WSMP car elles
nécessitent une latence faible.
Ce standard définit deux plans, le plan gestion et le plan de données. Dans le plan de données, les
données sont transmises en utilisant le protocole WSMP ou IPv6. Dans le plan de gestion, on y
trouve plusieurs services comme l'enregistrement de service DSRC (un RSU déclare assurer un
service de diffusion de vitesse maximale par exemple), ou la surveillance des canaux radio (afin de
choisir le canal le moins chargé) [7].
2.13 Conclusion
Dans ce chapitre, les technologies VANET et WAVE ont été mises en évidence de par leurs
caractéristiques, leurs spécificités ainsi que par leurs modes de fonctionnement. On a pu constater
que plusieurs entités indispensables constituaient le réseau VANET pour assurer la communication
56
entre les véhicules et les équipements sur les bords de routes. Pour la technologie WAVE, on a pu
relever des points essentiels concernant la bande de fréquence utilisée, l’architecture en couche ainsi
que les diverses normes et exigences que WAVE doit respecter afin d’assurer une communication
fluide adaptée à un réseau où certains nœuds sont en constant mouvement compte tenu que ceux-ci
sont des véhicules.
Au chapitre suivant, on va se focaliser sur l’intervention des réseaux VANET par rapport à la gestion
du trafic routier.
CHAPITRE 3 APPLICATION DE VANET A LA GESTION DU TRAFIC ROUTIER
3.1 Introduction
Les services VANET contribuent à l'amélioration du trafic routier en fournissant des informations
sur l'état des routes. Du contenu des messages échangés par les différentes entités du réseau, un
véhicule peut être informé de la circulation sur son trajet actuel ou futur. Le conducteur peut donc
décider de suivre une autre route lorsque le trafic est dense sur son trajet et éviter ainsi de la
congestion. Les services de gestion du trafic routier permettent de créer le passage pour les voitures
d'urgence, ou de proposer des itinéraires aux véhicules qui se dirigent dans une zone de congestion.
Même si un véhicule équipé d’un GPS et disposant d’une carte est capable, à lui seul, de calculer le
meilleur trajet à suivre, les performances de ces applications sont meilleures lorsque leurs mise à
jour sont en temps réel, soit lorsqu’un véhicule reçoit des informations d’actualité concernant le
trafic routier, de la part d’une unité de bords de route ou de celle des autres véhicules à proximité.
Ces applications ont pour but d’assister le conducteur lors de sa conduite. Leurs critères en termes
de qualité de services sont moins restrictifs que pour les applications de sureté, mais tout de même
similaires, à savoir, un certain taux de réception doit être garanti.
3.2 Techniques de dissémination
Une solution de dissémination efficace pour les VANETs doit absolument prendre en considération
les caractéristiques de ces dernières, comme la taille du réseau, la vitesse des véhicules, la connexion
intermittente du réseau qui cause son partitionnement en de nombreux ilots, ainsi que les différents
besoins des applications en termes de qualité de service. Dans la littérature, plusieurs stratégies ont
été proposées. Chacune d’elles, peut nécessiter un ou plusieurs sauts pour l’acheminement de ses
données, ainsi que le déploiement ou non d’infrastructure, comme les unités de bords de route
(RSUs). Néanmoins, toutes les stratégies se basent sur la coopération des véhicules du réseau pour
57
relayer les messages. C’est pour cette dernière raison qu’une multitude de modèles incitatifs ont été
proposés en parallèle aux stratégies de diffusion. En plus de la motivation des véhicules à coopérer,
il existe un deuxième mécanisme, complémentaire au précédent, dont l’objectif est d’attester de la
validité des messages reçus et d’exclure du réseau les véhicules dont le comportement est malicieux.
Ci-dessous, nous détaillerons les différentes stratégies de dissémination, les modèles incitatifs, ainsi
que les modèles de confiance existants. Ces trois éléments représentent pour nous un ensemble
complémentaire de mécanismes qui doivent être mis en place pour l’élaboration d’une solution
complète et efficace de dissémination de données dans les VANETs [12].
3.2.1 Stratégies de dissémination
3.2.1.1 Diffusion
L’une des approches les plus utilisées pour la dissémination de données dans les VANETs est celle
utilisant la diffusion. Elle peut être utilisée à un seul saut comme à plusieurs sauts. Un message
envoyé par un véhicule émetteur par diffusion est transmis à tous ses voisins directs, puis est
retransmis encore une fois par chacun de ses récepteurs, jusqu’à atteindre le (ou les) destinataire(s).
Cette approche ne nécessite aucune information préalable sur les voisins du véhicule, ce qui lui
permet d’ignorer l’inexistence ou l’inexactitude des informations sur la topologie du réseau. Elle
augmente le taux de délivrance et améliore la vitesse d’acheminement des données, car un véhicule
destinataire reçoit plusieurs copies du message, arrivant au travers de plusieurs routes. Néanmoins,
cette approche augmente aussi la compétition pour l’accès au canal de communication et l’utilisation
de la bande passante, ce qui ne lui permet pas le passage à l’échelle au risque de générer une forte
congestion du réseau. Les auteurs de l’étude proposent un protocole de diffusion multi-sauts pour
les environnements urbains, nommé UMB (Urban multi-hop broadcast protocol), lequel vise à
remédier aux problèmes liés à la diffusion massive. Pour l’envoi d’un message, un véhicule émetteur
l’envoie par diffusion à ses voisins directs, puis seul le véhicule le plus éloigné le rediffuse. À la
rencontre d’une intersection, des véhicules sont sélectionnés comme répéteurs et sont chargés de
rediffuser l’information sur les différents segments de l’intersection. Les auteurs de la solution
utilisent la même approche de dissémination. Un message est envoyé par diffusion afin d’atteindre
un certain groupe de véhicules. Cependant, à partir de la seconde transmission du message,
uniquement les véhicules sur les bords sont sélectionnés comme relayeurs. Les critères de sélection
des relayeurs dans ces deux approches concernent principalement leurs positions géographiques.
Ceci n’est pas suffisant pour répondre aux problématiques VANETs, comme par exemple
58
l’adaptation à la densité changeante du réseau, car aucune relation entre le nombre de relayeurs et
la densité n’est donnée [12].
Figure 3.01 : Stratégie de dissémination
3.2.1.2 Probabiliste
Ce type d’approche, tente de diminuer les messages redondants générés en calculant les probabilités
de rencontres entre deux véhicules avant de décider du chemin de dissémination d’une information,
sans pour autant nécessiter la connaissance de la topologie du réseau. Un véhicule utilisant cette
approche peut se baser sur ses connaissances du réseau, son historique de rencontres avec les autres
véhicules, ainsi que sur les informations qu’il a pu collecter sur la mobilité et les localisations des
autres véhicules du réseau. La solution utilise cette approche probabiliste, les décisions concernant
les choix des véhicules relayeurs pour la retransmission d’un message se basent sur les probabilités
de rencontres du (ou des) véhicule(s) destinataire(s). Alors que dans d’autres solutions, les véhicules
récepteurs d’un message calculent eux-mêmes leur probabilité de retransmission, en se basant sur
la distance les séparant du véhicule émetteur. Plus cette distance est grande plus leur probabilité de
retransmission est importante. Les auteurs de la solution utilisent le critère de la distance entre un
véhicule récepteur et un véhicule source pour calculer la probabilité de retransmission et y ajoutent
un paramètre concernant la densité locale du réseau, soit le nombre de voisins directes du véhicule
récepteur, afin de réduire le nombre de véhicules relayeurs lorsque la densité est forte.
59
3.2.1.3 Géographique
Cette approche de dissémination se base sur les informations de localisation des véhicules contenues
dans les messages de contrôle, diffusés périodiquement dans le réseau, lorsqu’elle suit une approche
pro-active, ou alors diffusés à la demande, lors d’une approche réactive. Chaque véhicule tient
régulièrement à jour une table contenant l’historique des localisations de ses voisins, afin de pouvoir
acheminer ses messages par le chemin le plus court et donc, réduire leur délai d’acheminement.
Pour ce fait, lors d’une dissémination, le véhicule le plus proche du (ou des) destinataire(s) est
sélectionné lors de chaque saut. Cette approche permet aussi de cibler un groupe de véhicules grâce
à leurs coordonnées géographiques, comme font les applications visant à avertir les conducteurs des
risques de collision en intersection, par exemple [12].
3.2.1.4 Orientée ressources du canal
Car les ressources du canal de communication sont limitées, l’accès au canal et l’allocation de ses
ressources deviennent un problème d’optimisation. Cependant, ce problème risque d’être très
délicate à résoudre à cause de toutes les variantes qui doivent être prises en considération et du peu
d’informations sur le réseau mises à la disposition du véhicule. Des solutions proposent alors des
algorithmes basés sur des heuristiques, qui propose un routage de données accès sur la prise en
compte de l’historique des rencontres du véhicule émetteur avec les autres véhicules du réseau. Cela
dans le but d’estimer les congestions potentielles ainsi que la densité du réseau, puis de les prendre
en considération afin d’améliorer le taux de délivrance et de limiter le nombre de messages
doublons. Chaque nœud tient une table avec des informations sur le débit et les conditions du canal
afin de choisir par quel nœud relayeur il est préférable de transmettre son message. Cependant, ces
solutions nécessitent des échanges de messages entre les véhicules pour maintenir un contrôle sur
l’utilisation des ressources du canal. Une autre solution consiste à améliorer le taux de réception des
messages d’urgences en leur allouant une partie de la bande passante disponible. Dans cette solution,
chaque nœud envoie en premier un signal sous forme d’impulsion, puis son message d’urgence.
3.2.1.5 Orientée priorité des messages
Pour répondre aux différents besoins en qualité de service des multiples applications des VANETs,
des solutions de dissémination proposent une adaptation de la dissémination par rapport à
l’importance du contenu des messages échangés. Afin de ne pas supprimer systématiquement tous
les nouveaux messages entrants en cas de congestion du réseau. Une solution remédie à ce problème
60
en fixant des priorités pour l’accès au canal de communication d’après les catégories d’accès ACs,
fixées par EDCA, pour chaque message. Une autre solution, alloue des jetons aux files d’attente
formées par les messages souhaitant l’accès au canal. Elle gère l’accès au canal en pondérant le
nombre de jetons offerts par rapport à la densité du canal et à la priorité des messages. Tout comme
cette dernière, une autre alternative ordonnance les messages à envoyer sur la base des ressources
disponibles du canal et de l’importance du message, en utilisant un système de files d’attentes où
une plus grande priorité est donnée aux messages les plus urgents [12].
3.2.2 Modèles incitatifs à la coopération
La plupart des solutions de dissémination considèrent la coopération des véhicules présents dans le
réseau comme acquise, ce qui n’est pas vérifié à cause de la présence potentielle de véhicules
égoïstes. Ces derniers préfèrent réserver leurs ressources uniquement pour leurs besoins personnels
et refusent donc les demandes de retransmission des messages de leurs voisins. Cette attitude baisse
l’efficacité des solutions à acheminer les données dans les VANETs. Pour cette raison, il est
primordial d’accompagner une solution de dissémination de données par un modèle incitatif à la
coopération, afin de s’assurer de la participation de tous les véhicules à la retransmission des
données. Trois approches peuvent être utilisées pour motiver les véhicules à coopérer [12] :
3.2.2.1 Le troc
Dans cette approche, chaque véhicule tient une table retraçant le comportement des autres véhicules
à son égard, un véhicule n’accepte de coopérer et de retransmettre le message d’un autre à la
condition de réciprocité que si ce dernier a déjà fait de même. Cependant, la forte mobilité des
véhicules et les changements fréquents de topologie dans les VANETs ne permettent pas
l’établissement de solides relations entre les véhicules, ce qui peut affaiblir les performances de
cette approche [12].
3.2.2.2 Les crédits virtuels
La majorité des modèles incitatifs utilisent des crédits virtuels qui servent à monétiser la coopération
des véhicules. Chaque transmission de message fait bénéficier le véhicule relayeur d’une
récompense donnée par le véhicule émetteur. Le maintien d’un tel système nécessite le déploiement
d’infrastructures ou la disposition dans les véhicules d’équipements spécifiques, afin de gérer le
calcul et la distribution des récompenses. Les limites de cette approche concernent le calcul des
61
coûts et récompenses, qui souvent peut être basé sur des estimations, ainsi que sur la distribution
des crédits, qui peut souffrir de la mobilité des véhicules.
3.2.2.3 Les modèles de réputation
Cette dernière approche mesure la coopération des véhicules à travers des réputations, chaque
véhicule relayant un message verra sa réputation mise à jour par le véhicule émetteur. Une réputation
de haute valeur ouvre l’accès à des privilèges sur le réseau. Tout comme l’approche basée sur le
troc, celle-ci souffre de la mobilité et des changements de topologie dans les VANETs qui ne
permettent pas la construction fiable de réputation [12].
3.2.3 Modèles de confiance
Les solutions proposées aux problématiques de dissémination de données dans les VANETs, se sont
souvent intéressées aux aspects quantitatifs pour améliorer le taux de délivrance et réduire les délais,
mais sans forcément évaluer la qualité des informations échangées. À cause de la présence de
véhicules malicieux dans ces réseaux, des messages altérés peuvent être disséminés. Les objectifs
d’un modèle de confiance consistent à établir des relations de confiance entre les membres d’un
réseau, de détecter et d’exclure les véhicules malicieux. Cependant, ces objectifs sont mis à mal à
cause du large espace où peut s’étaler un VANET, en plus de sa nature décentralisée, éparpillée,
ouverte et très dynamique. Une partie de ces modèles proposent des mécanismes de révocation par
l’utilisation de certificats, afin d’exclure les véhicules malicieux, mais pour se faire, ceci nécessite
l’existence d’infrastructures. Nous détaillons ci-dessous les trois approches utilisées pour la mise en
place d’un modèle de confiance ne nécessitant pas forcément d’infrastructure [12].
3.2.3.1 Orienté entité
Dans cette approche, la notion de confiance lors de la réception d’une information vise le véhicule
émetteur. La solution prône un modèle de confiance sociologique, celui-ci consiste à faire confiance
ou non à un autre véhicule d’après la situation où ils se trouvent, le niveau d’optimisme du véhicule,
ainsi que le système et les garanties que celui-ci propose. Une autre solution s’intéresse aussi à la
confiance accordée au véhicule émetteur, mais par l’utilisation de multiples aspects le concernant.
Cette solution attribue des rôles et des réputations à tous les véhicules du réseau, afin de pondérer
la véracité de leurs dires par ces deux valeurs [12].
62
3.2.3.2 Orienté donnée
À l’encontre de la première approche, celle-ci accorde de la confiance à un message par rapport à
son contenu, indépendamment de son émetteur. Les auteurs de l’étude proposent un modèle de
confiance basé sur cette approche afin de remédier aux problématiques liées aux connexions
éphémères dans les VANETs, qui empêchent l’établissement de liens de confiance entre les
véhicules. Pour ce faire, un véhicule consulte les rapports émis par les autres concernant une
information reçue avant de l’accepter ou de la refuser. Chacun de ces rapports est pondéré par
rapport à plusieurs métriques de confiance, comme son lieu et sa date d’émission. Ces rapports et
leur poids servent à décider du degré de confiance à accorder à l’information reçue [12].
3.2.3.3 Combiné
La troisième approche combine les deux premières. Elle utilise les degrés de confiance attribués aux
véhicules pour distribuer à son tour des degrés de confiance aux informations reçues. Une solution
consiste à instaure ainsi un nouveau modèle de réputation distribué. Chaque véhicule recevant un
message, y insère son avis sur la validité de son contenu avant de le retransmettre. Ces avis
permettent aux véhicules récepteurs de choisir le degré de confiance à donner au message et de
mettre à jour les réputations des autres véhicules par rapport aux avis donnés [12].
3.3 Contrôle du trafic routier urbain
Depuis les années 1960 et plus particulièrement au début des années 1970, les systèmes de
régulation du trafic se sont rapidement développés afin d’améliorer les conditions de mobilité, en
réduisant notamment les facteurs pouvant provoquer de l’attente et des embouteillages. L’apparition
progressive de systèmes de gestion centralisés, en charge des carrefours d’une zone géographique
donnée, s’est révélée déterminante. De plus, des recherches montrent un intérêt certain pour la
gestion du trafic, ceci dans le but de supprimer l’instabilité dans les flux de trafic et pour réduire le
niveau d’embouteillage. Les systèmes de régulation des accès (ramp metering), qui sont largement
déployés, montrent qu’une gestion active des feux de circulation peut réduire drastiquement les
embouteillages, même si des exemples en place, tels qu’à Minneapolis, sont contestés par les
conducteurs qui ont le sentiment d’attendre plus longtemps.
3.3.1 Métriques et paramètres traditionnels
La mise en place d’un système de transport intelligent nécessite, a priori, de connaître à la fois les
paramètres sur lesquels il peut jouer et les métriques à optimiser. D’une part, les paramètres sont
63
des valeurs qui régissent le fonctionnement du système. Le style de conduite dépend par exemple
en partie de l’utilisateur, mais a une influence majeure sur la manière dont peut réagir le système.
D’autre part, les métriques sont des valeurs qu’il est possible de mesurer sur le terrain, découlant du
comportement du réseau routier, de ses utilisateurs et de ses paramètres. Nous pouvons par exemple
citer le temps moyen d’attente (average waiting time –AWT), qui est généralement représentatif des
performances d’un système de gestion des feux de circulation. Notons que les paramètres et
métriques sont décomposés en deux échelles, l’une globale (ville, zone urbaine, système) et l’autre
locale (voie, route, intersection). Nous remarquons qu’utiliser une vision locale plutôt que globale
n’affecte que la manière dont un opérateur peut avoir accès aux informations. Il serait donc possible
de s’y fier et d’imaginer des algorithmes utilisant ces paramètres et métriques. Chaque échelle peut
également se décomposer en deux sous-ensembles : ce qui est en rapport avec et avec
l’infrastructure. Cette distinction est également importante car dans le cas des paramètres, un STI
subit généralement ceux en rapport avec l’utilisateur, tandis qu’il nous est possible de fixer ceux en
rapport avec l’infrastructure.
3.3.2 Types de contrôles
Au fil des années, les systèmes de régulation se sont diversifiés, et ont connu globalement trois
générations de contrôle. Aujourd’hui, ces générations peuvent être utilisées chacune en fonction des
moyens mis en place sur l’infrastructure, et de la connaissance de cette dernière :
• Première génération - contrôle à temps fixe : en fonction de l’heure et parfois du jour, le
système utilise un plan de feux prédéfini. Exemple : une configuration est appliquée le midi,
tandis qu’une plus souple et équitable pour l’ensemble des voies d’un carrefour est appliquée
la nuit. Classiquement, trois configurations existent : pointes du matin, de l’après-midi, et le
reste (hors pointes). Nous pouvons imaginer une formulation plus complète prenant en
compte des plans spécifiques aux heures de pointe.
• Deuxième génération - contrôle à temps dynamique - réactif : des détecteurs sont utilisés
afin de recueillir les données du trafic périodiquement (plusieurs minutes ou cycles). Ces
données sont ensuite utilisées pour mettre en place un plan de feux en réponse aux
informations reçues. Cette méthode est simple à mettre en place, mais nécessite toutefois
une très bonne connaissance du système afin d’être efficace. Il s’agit de la première méthode
à être apparue aux États-Unis à la fin des années 1980 avec l’apparition des UTCS (Urban
Traffic control software).
64
• Troisième génération - contrôle à temps réel - adaptatif : reprend le même principe que la
deuxième génération mais cette fois-ci en temps réel. Ce type de contrôle programme
dynamiquement les plans de feux en se servant des paramètres recueillis sur le terrain. Il est
possible de calculer des valeurs telles que le temps de cycle, les phases ou encore leur
ordonnancement. L’opération est effectuée de manière adaptative, c’est à dire en réaction
directe au trafic. L’avantage de cette méthode est qu’elle peut s’adapter à de multiples
situations, mais reste la plus compliquée à mettre en place car elle nécessité de cerner les
informations à utiliser, comment les utiliser et se baser sur des théories parfois coûteuses en
calculs ou mémoire.
3.3.3 Modes de fonctionnement d’un contrôleur de feux
Sur le terrain, les contrôleurs de feux peuvent être mis en place avec plusieurs modes de
fonctionnement.
Tout d’abord, les contrôles prédéterminés, où l’enchainement des phases s’effectue en marge du
trafic routier, c’est à dire toujours dans le même ordre et avec un temps prédéfini en fonction de
l’importance connue des voies. Les plans de feux mis en place peuvent être générés à l’avance : il
est commun que des méthodes d’optimisation souvent longues soient employées afin d’obtenir le
meilleur rendu possible. Il est en effet connu que trouver une séquence optimale pour un réseau de
plusieurs intersections est un problème.
Ensuite, les contrôles semi-adaptatifs, où des détecteurs sont mis sur certaines voies afin d’ajuster
des paramètres tels que les temps de feux ou encore l’ordonnancement des phases.
Enfin, les contrôles adaptatifs, qui découlent de l’émergence des nouvelles technologies et qui se
calibrent en temps réel ou quasi temps réel sur le trafic, à l’aide de détecteurs au sol ou caméras,
ainsi que de méthodes heuristiques. Le tableau 3.01 donne l’exemple d’un choix de mode, se basant
notamment sur l’état du trafic, c’est à dire la demande en trafic par rapport à la capacité. Elle est
notée par le rapport V/C (espace occupé (volume) sur capacité) [2].
Configuration du
réseau
Charge
d’intersection
(V/C)
2
phases
4
8
Croisement 0.80 prédéterminé semi-adaptatif Semi-adaptatif
65
>0.80 prédéterminé prédéterminé prédéterminé
Réseau dense 0.80 adaptatif Semi-adaptatif adaptatif
>0.80 prédéterminé Semi-adaptatif adaptatif
Tableau 3.01: Modes de fonctionnement d’un contrôleur de feux
Notons au passage l’existence du contrôle par ordinateur, où les phases sont ajustées à distance
depuis des centraux ou directement sur le contrôleur de feux (p. ex., influence en cas d’imprévus,
police, travaux).
3.3.4 Les systèmes de régulation du trafic
En Europe, trois grandes approches, complémentaires, de régulation du trafic routier se sont
principalement développées et sont représentatives de ce qui se fait à travers le monde.
3.3.4.1 L’approche Anglaise
La première approche, d’origine Anglaise, se base sur des principes mathématiques. Le modèle
TRANSYT (TRANSport SYSTem) est notamment né de cette démarche, puis a rapidement évolué
vers TRANSYT 7 avant de devenir le système SCOOT. Aujourd’hui, cette approche est l’une des
plus populaires et compte de nombreux autres systèmes de régulation. SCOOT et SCATS,
notamment, sont les deux principaux systèmes de gestion du trafic routier utilisés dans le monde.
SCOOT (Split Cycle Offset Optimization Technique) est un système de contrôle développé par le
TRL (Trafic research laboratory, Angleterre). À l’aide de détecteurs placés sur le terrain, SCOOT
se base notamment sur un indice de performance afin de générer des plans de feux en fonction de la
demande des utilisateurs. Cet indice est calculé par rapport au délai d’attente moyen, à la longueur
des files d’attente et des arrêts sur le réseau. Cet aspect dynamique est réalisé à l’aide d’un aller-
retour régulier de mesures et de décisions entre les équipements sur le terrain et un centre de
contrôle. Cette centralisation et ce suivi régulier de la circulation impliquent un passage à l’échelle
limité, car de gros besoins en calcul sont nécessaires et car tous les détecteurs doivent être
interconnectés. Cela limite leur déploiement aux plus grands carrefours. SCATS (Sydney
Coordinated Adaptive Traffic System) a été à l’origine développé pour Sydney et d’autres villes
Australiennes. Il utilise une notion de hiérarchie ce qui forme une certaine distribution sur le réseau.
En effet, entre le recueil des données sur le terrain et le centre de contrôle, des contrôleurs
intermédiaires sont insérés. Ceci permet d’alléger la charge globale du système et d’avoir un
66
contrôle découpé en plusieurs zones, l’ensemble des acteurs utilisant des communications
synchronisées. De manière similaire à SCOOT, ce système ajuste le temps des cycles et autres
paramètres en fonction des données recueillies afin de diminuer le délai et les arrêts. Il n’utilise
toutefois pas la même stratégie : les valeurs recueillies permettent la sélection de plans de feux parmi
une large bibliothèque, sur lesquels le système se base pour proposer des plans ajustés [4].
3.3.4.2 L’approche Allemande
La deuxième approche, d’origine Allemande, se base sur des coordinations horaires pointues. Cette
approche a su faire ses preuves et a essentiellement été mis en œuvre par Siemens jusqu’aux années
1990, notamment dans certains pays du nord de l’Europe où le style de conduite appelait à un trafic
plus régulier. Cette solution a été par la suite abandonnée au profit de systèmes tels que SCOOT [2].
3.3.4.3 L’approche Française
La troisième approche, d’origine Française, part d’un principe plus simple : "aucune machine ne
remplacera jamais ce qui est l’essence même de l’homme : l’esprit(...) et la compréhension" (Louis
V. Gerstner). Les modèles mathématiques sont ici mis de côté au profit de l’expérience humaine.
Les ingénieurs des ponts et chaussées mettent ainsi en place des stratégies au cas par cas. Sur Amiens
par exemple, ceci se fait par le biais de systèmes centraux développés par THALES. D’une manière
plus générale, ils mettent également en avant des systèmes de supervision des réseaux de transports.
Ce système, d’initiative Française, est destiné à intégrer et à traiter des données issues de part et
d’autres du réseau routier (trafic routier, stationnement, transport en commun, etc.), afin de fournir
des indicateurs ayant trait à la ponctualité (le retard), à la régularité (l’attente), à la fiabilité (la
vitesse), au trafic (la demande, le débit, la concentration), à la correspondance (les temps de
transfert), à l’environnement (l’émission de polluants) [4].
3.3.4.4 Recherche Européenne
Notons également que la recherche Européenne pousse à ce genre d’initiative, allant vers l’analyse
du trafic routier. Instant Mobility est, par exemple, un projet de recherche Européen étudiant la
manière dont peut être améliorée la mobilité urbaine et la gestion du trafic routier. Ce projet souhaite
notamment créer un écosystème entièrement connecté agrégeant les données de trafic en provenance
de diverses sources (transports publics, réseaux sociaux, flottes et camions commerciaux, etc.), afin
de proposer des informations et services aux automobilistes.
67
3.3.5 Les systèmes coopératifs
Un système coopératif est un réseau hybride où des acteurs mobiles coopèrent avec des acteurs
fixes. Ce type de réseau est prometteur, en premier lieu car les équipements de l’infrastructure
peuvent profiter des données d’un réseau véhiculaire (V2I – vehicle-to-infrastructure), et
inversement (I2V – infrastructure-to-vehicle). Ainsi, l’intelligence est répartie entre différents
éléments du réseau, fixes ou mobiles, ce qui permet de développer des applications qu’il aurait été
impossible de mettre en place autrement. Dans certains cas, nous parlons de systèmes interactifs
lorsque les véhicules peuvent échanger à la fois des données avec l’infrastructure, mais également
avec les autres véhicules. L’avantage est considérable, le traitement et la diffusion des informations
pouvant bénéficier de la mobilité des véhicules, ainsi qu’un appui de données. Ceci est représenté
par la figure 3.02.
Certaines initiatives, telles que CALM (Communications Access for Land Mobiles), ont pour but
de standardiser les communications dans ce type de réseaux. Le but de CALM est, notamment, de
rendre transparente et continue l’utilisation des protocoles de communication sans fil et des
interfaces de communications destinées à une large variété de scénario. Par exemple, utiliser
conjointement des réseaux cellulaires et des interfaces 802.11p ou 802.15.4 afin d’obtenir un réseau
étendu, réactif et favorisant la coopération entre les acteurs. CALM propose également des
orientations technologiques en termes d’architectures (V2V, V2I, etc.) et de protocoles (p.ex., IPv6).
68
Figure 3.02 : Système coopératif
3.4 Les causes de la congestion routier
La congestion routière est phénomène qui touche les grandes agglomérations mondiales. Elle
défavorise les activités socio-économiques. En effet, elle contribue à augmenter le temps des
automobilistes passés dans les files d’attente, la surconsommation de carburant, les risques
d’accidents et la pollution. D’un autre côté, elle réduit le volume du marché et l’accessibilité à
certaines activités économiques. Les principales causes des congestions sont :
• Le choix massif à la possession d’un véhicule au détriment du transport en commun qui
enregistre une chute prononcée, surtout pour les périodes de pointe du matin et après-midi.
Ceci explique en partie la pression exercée de plus sur le réseau routier de la métropole.
• L’augmentation du nombre d’industries manufacturières dans la plupart des villes,
augmente aussi le nombre de camions en circulation.
• La forte concentration des activités de camionnage dans les métropoles où se présente près
de 79% des emplois dans le secteur manufacturier, le commerce de gros et de détail sur 14%
du territoire. Ces activités provoquent la grande mobilité des camions.
69
• Le transport des marchandises est une tâche qui se fait principalement la semaine et le jour.
Plusieurs enquêtes réalisées auprès des générateurs de déplacements routiers de
marchandises ont démontré que la plupart des entreprises réalisait leurs activités du lundi
au vendredi. La réception et la livraison de marchandises débutent généralement entre 6h et
9h le matin et se terminent entre 16h et 18h le soir.
3.5 Scenarii de coopération entre les différents entités VANET
3.5.1 Capteur sur la route
L’utilisation de la boucle magnétique sur les routes que nous avons vue au premier chapitre est une
solution existante de nos jours pour avoir des données précises sur le flux de trafic routier. Ces
données seront utilisées par l’OBU de chaque voiture inclue dans le réseau VANET afin calculer la
trajectoire idéale pour d’un point A vers un point B. Néanmoins, cette solution a un cout très élevé
en terme d’installation et de maintenance ainsi que l’identité du véhicule ne peut être obtenu. Nous
pouvons observer sur la figure 3.03 la communication entre l’OBU de la voiture le RSU et la boucle
magnétique [16].
Figure 3.03 : Communication entre capteur OBU et Centre de gestion du
trafic
70
3.5.2 Communication entre véhicule V2V
3.5.2.1 Transmission d’informations sur le trafic routier
Les véhicules incluant les technologies de communication VANET peuvent se transmettre des
informations directement entre eux sans passer par les OBU. Elles partagent des informations sur la
vitesse moyenne des véhicules voisins calculée à l’aide des messages provenant d’autres véhicules.
Ces informations seront très précieuses pour une voiture qui se trouve en avale d’une congestion
afin qu’elle puisse recalculer la trajectoire qu’elle doit prendre pour atteindre son but. Cette
technique est efficace pour organiser la circulation sans l’aide d’agent posté sur un point stratégique.
Les messages de contrôles sont les messages utilisés pour ce genre de service. Comme nous l’avons
cité au deuxième chapitre, ces messages intègrent des Beacons qui indiquent des informations sur
la position, sa vitesse, son accélération et sa direction.
Figure 3.04 : Dispersion de messages de contrôle entre véhicules
3.5.2.2 Avertissement d’accident
Dans le cas d’un accident, les véhicules au sein du réseau VANET sont alertés du danger de collision
qui peut s’avérer dangereuse. Afin d’éviter qu’une autre collision ne se produisent, l’OBU à bord
du véhicule refait un calcul pour savoir si on peut contourner l’accident ou le choix d’un autre
chemin est une meilleure solution. La communication des données se fait à travers des messages
d’alertes [16].
71
Figure 3.05 : Dispersion de messages d’alerte
Pour étendre le message d’alerte au maximum, VANET fait recours au véhicules afin de les utiliser
en tant que répétiteur comme l’illustre la figure 3.06 :
Figure 3.06 : Avertissement d’accident à proximité
3.5.3 Coopération avec des réseaux de télécommunication
Un véhicule possède des informations pouvant aider les feux de signalisation d’adapter la durée de
chaque feu de signalisation en fonction du flux de trafic existant. Ces feux sont reliés aux véhicules
par le biais d’un réseau extérieur tel que les réseaux de télécommunication 3G/4G. prenons exemple
sur un carrefour à quatre chemins. Sur une voie, le flux de trafic est plus dense que sur les trois
autres. Les feux de signalisation tiennent compte des informations qu’ils reçoivent afin de réajuster
la durée du feu vert sur cette voie afin que le flux devienne plus fluide permettant ainsi de
rééquilibrer le trafic évitant ainsi une congestion [16].
72
Figure 3.07 : Coopération avec les réseaux extérieurs
3.6 Conclusion
Dans ce chapitre, nous pouvions observer les techniques de dissémination des informations dans les
réseaux VANET. La congestion sur le flux de trafic routier a été soulignée comme étant un facteur
bloquant à une circulation de véhicules que ce soit dans des zones urbaines ou sur les autoroutes.
Concernant notre travail nous nous somme focalisé sur les zones urbaines contenant des carrefours
et des points stratégiques où il était intéressant de lancer des études. La communication entre les
signalisations sur les bords de routes et les feux de signalisation ainsi que les capteurs installés sous
les routes sont aussi d’une aide conséquente. Ces types de communication nécessitent des
infrastructures externes aux véhicules et impliquent alors un cout assez considérable par rapport aux
services fournis en contrepartie.
Dans le chapitre suivant, nous retiendrons la solution incluant une communication entre les
véhicules V2V et entre les véhicules et les infrastructures V2I pour véhiculer les informations
nécessaires à la gestion du trafic sous forme de messages de contrôles. Nous retiendrons la
technologie WAVE pour assurer la partie technique au niveau de la communication à distance entre
les divers acteurs.
73
CHAPITRE 4 ILLUSTRATION DES COMMUNICATIONS DANS LES RESEAUX
VANET
4.1 Introduction
La mise en œuvre sur le terrain des réseaux VANETs est extrêmement coûteuse et difficile. Aussi,
la simulation est une étape nécessaire dans notre travail. Il existe plusieurs simulateurs de réseaux
Ad Hoc capables d’effectuer des simulations répondant aux critères des VANETs. Nous présentons
dans ce dernier chapitre quelques simulateurs pouvant répondre à ceux-ci. L’objectif de la
simulation est de reproduire les mêmes résultats que ceux que l’on obtiendrait en conditions réelles.
Un simulateur de réseau VANET réaliste se compose des éléments indispensables : un simulateur
de réseau regroupant les bases (réseaux) d’une simulation VANET et un simulateur de mobilité. Le
simulateur de mobilité génère des fichiers qui décrivent la mobilité des nœuds dans un
environnement, et qui sont transmis au simulateur de réseau Ad-Hoc. Bien que les deux simulateurs
soient indispensables à la simulation des réseaux VANETs, il n’y a aucun lien direct entre eux. L’un
des problèmes que l’on rencontre alors est l’interconnexion entre les simulateurs. Il existe cependant
des simulateurs intégrés qui regroupent les deux simulateurs au sein d’une même entité pour
répondre au mieux à ce problème.
4.2 Les Simulateurs de Réseaux Ad Hoc
Il n’y a pas de principe de fonctionnement standard pour les simulateurs de réseau Ad Hoc ou les
simulateurs de mobilité. Il existe plusieurs stratégies et architectures qui permettent de simuler un
réseau Ad Hoc. Chaque simulateur répond aux besoins de la simulation de réseau via des
architectures variées, en fonction des objectifs que se sont fixes leurs développeurs. Cependant, ils
ont tous le même but : reproduire le plus fidèlement possible le fonctionnement d’une pile
protocolaire [12].
4.2.1 Le simulateur NS-2
NS ou Network Simulator version 2 est un outil logiciel de simulation de réseaux informatiques. Il
est principalement bâti avec les idées de la conception par objets, de réutilisabilité du code et de
modularité. Il est devenu aujourd'hui un standard de référence en ce domaine. C'est un logiciel dans
le domaine public disponible sur l'Internet. Son utilisation est gratuite. Le logiciel est exécutable
tant sous Unix que sous Windows. Il s’agit d’un simulateur à évènements discrets disponibles
gratuitement et open source. L’ouverture du code source à la communauté a contribué à l’enrichir
de nouveaux protocoles et de nouvelles fonctions au fil du temps. Il permet à l’utilisateur de définir
74
un réseau et de simuler des communications entre les nœuds de ce réseau. La simulation doit d’abord
être saisie sous forme de fichier texte que NS-2 utilise pour produire un fichier trace contenant les
résultats [12]. NS-2 nécessite deux langages : OTcl (Object Tools Command Language) et C++ . À
travers le langage OTcl, l’utilisateur décrit les conditions de la simulation : topologie du réseau,
caractéristiques des liens physiques, protocoles utilises. C++ est implémenté afin de fournir des
détails sur les protocoles de simulation comme la manipulation des bits, la recherche et la résolution
des bugs tandis que tcl permet de configurer les paramètres de la simulation comme la
communication entre les nœuds, la mise en place d’un scenario ou encore le déplacement des nœuds.
La figure ci-dessous montre le déroulement d’une simulation sur NS-2 [12].
Figure 4.01 : Déroulement d’une simulation sur NS-2
4.2.1.2 Les composants de NS-2
Le simulateur NS-2 est adapté aux réseaux à commutation de paquets et à la réalisation de
simulations de grande taille. Il contient les fonctionnalités nécessaires à l’étude des algorithmes de
routage unicast ou multicast, des protocoles de transport, de session, de réservation, des services
intégrés et d’application. La liste des principaux composants disponibles dans le simulateur NS-2
est présentée dans le tableau 4.01.
75
Tableau 4.01: Principaux composants disponibles dans le simulateur NS-2
4.2.1.3 Modèle de mobilité
NS2 implémente deux modèles de mobilité. Le Random Waypoint Mobility Model est un modèle
qui génère un mouvement aléatoire du nœud qui choisit ensuite, aléatoirement, sa prochaine
destination. Aussi dans ce modèle, le nœud se déplace avec une vitesse aléatoire constante. Le
Trajectory based Mobility Model est modèle défini par un scénario dans lequel l’utilisateur précise
une destination et la vitesse de déplacement des nœuds. La vitesse de déplacement des nœuds est
constante [12].
4.2.1.4 Modèle de propagation dans NS-2
Les modèles de propagation implémentés dans NS2 ont pour objectif de prédire la puissance de
réception du signal des paquets. À la couche physique de chaque nœud, il existe un seuil de réception
du signal de paquets. Quand la puissance de réception du signal du paquet reçu par un nœud est
inférieure au seuil, le paquet est marqué comme erroné et il est abandonné dans la couche MAC
4.2.1.5 Scenario de simulation
Au début de la simulation, les nœuds sont positionnés dans un même coordonné après ils se
disperseront selon les coordonnées que l’on a attribuées à chacun et ensuite il y a une mobilité et
interconnexion entre les nœuds qui sont désignées a se communiqués en utilisant le protocole
AODV. A la fin de la simulation, on obtiendra des informations qui seront analyser et tracer à l’aide
d’un outil adéquat.
76
Figure 4.02 : Déroulement de la simulation
4.3 Simulateur de mobilité et de trafic routier
On trouve deux types de simulateurs de mobilité : les simulateurs indépendants et les simulateurs
intégrés. Les simulateurs indépendants génèrent uniquement la mobilité des réseaux VANETs. Il
faut en général leur associer des outils pour pouvoir exploiter cette mobilité dans un simulateur de
réseau Ad Hoc. Dans notre cas, NS-2 jouera le rôle de simulateur de réseau Ad Hoc. Les simulateurs
intégrés regroupent à la fois un simulateur de mobilité et un simulateur de réseau Ad Hoc, donc il
n’y a pas de problème de compatibilité [12]. EstiNet 9.0 est un bon exemple de simulateur intégré.
Nous utiliserons donc EstiNet 9.0 comme simulateur intégré pour avoir deux méthodes de
simulation différentes afin d’obtenir des résultats qu’on va comparer.
4.3.1 SUMO
SUMO (Simulation of Urban Mobility ) est un simulateur de mobilité open source. Il fait partie des
logiciels précurseurs du domaine et a ouvert la voie sur cette thématique. Il est complexe
d’utilisation mais permet de générer de la mobilité sur une zone géographique de la taille d’une
ville. Le but premier de SUMO est de pouvoir générer une mobilité basée sur des critères de décision
qui ne sont pas totalement aléatoires et qui imitent le comportement humain. Pour cela, SUMO
intègre plusieurs éléments dont notamment : un modèle de conducteur (CarDriver Model ), un
modèle de feux de croisement (Trafic Lights), et un format de fichier de sortie pour sauvegarder le
résultat de la simulation de mobilité. Le Car-Driver Model implémente dans SUMO permet à chaque
véhicule d’adapter sa vitesse en fonction des véhicules le précédant, évitant ainsi toute collision. Le
Trafic Lights donne des règles d’arrêt au carrefour qui évolue dans le temps. Le fichier de résultats
Script otcl
(.tcl)
Exécution de la
scripte par NS-2
Sortie (fichier
Trace et nam)
Visualisation de
la simulation par
nam
Traçage des
graphes
77
inclut les points de départ avec les vitesses et destinations initiales pour chaque nœud, ainsi que
toutes les modifications de comportement (changement de vitesse ou de destination). Ces
modifications sont sauvegardées chronologiquement par rapport au temps simulé [12].
4.3.1.1 OpenStreetMap
OpenStreetMap (OSM) est un projet qui a pour but de constituer une base de données
géographiques libre du monde permettant par exemple de créer des cartes sous licence libre, en
utilisant le système GPS et d'autres données libres. Il a été initié en juillet 2004 par Steve
Coast au University College de Londres1. Par l'utilisation de moyens informatiques basés
sur Internet qui permettent l'intervention et la collaboration de tout utilisateur volontaire,
OpenStreetMap relève de la géomatique 2.0 et est aussi une contribution à ce qui est appelé
la néogéographie, dont les outils composent le GeoWeb. Afin de faciliter la construction des routes
ainsi que les intersections sur un map donné, SUMO peut prendre un fichier provenant d’OSM et le
transformer en fichier xml directement utilisable. OpenStreetMap permet de dessiner un map selon
notre choix et de le télécharger en un fichier .osm.
Figure 4.03 : Site OpenStreetMap
78
4.3.2 Interopérabilité entre NS-2 et SUMO
Pour obtenir des trajectoires plus réaliste, NS-2 peut utiliser les fichiers de SUMO et les convertir
en fichier .tcl. Ce procédée se fait par les lignes de commande suivantes :
$]sumo -c map.sumo.cfg --fcd-output map.sumo.xml
$]python /usr/local/src/sumo-0.32.0/tools/traceExporter.py --fcd-input map.sumo.xml --ns2config-
output map.tcl --ns2mobility-output mobility.tcl --ns2activity-output activity.tcl
La première ligne de commande transforme le fichier utilisable par SUMO en un fichier .xml.
Ensuite ce dernier sera converti en un fichier lisible par NS-2 par l’intermédiaire d’un commande
python. Le fichier mobility.tcl est par la suite inclut dans le fichier principal pour qu’il prenne effet.
4.3.3 Explication des script tcl
L’édition du script de simulation peut se faire sur tous type d’éditeur de texte. Le début de notre
fichier sera marqué par l’initialisation de diverses variables pour configurer notre simulation comme
nous pouvons le constater ci-dessous :
Nous relevons sur ces commandes les paramètres concernant la couche physique de nos nœuds tels
que la bande de 5.9 GHz comme fréquence porteuse, la valeur des fenêtres de contention ou CW, le
type de modulation …
79
Ensuite, Chaque script de simulation doit contenir une ligne indiquant la création d’un objet
simulateur. La création de cet objet simulateur est assurée par la commande ci-dessous. On va créer
et ouvrir les dossiers qui vont contenir les traces de la simulation. Ces traces de simulation sont
utilisées pour la visualisation graphique et pour une interprétation graphique des résultats de la
simulation. On doit aussi créer la topographie de la simulation. La topographie de la simulation est
définie par une surface 221x249. Ensuite, il faut créer l’objet God (General Operation Director).
C’est un objet stockant les informations globales à propos de l’environnement. Et on définit 50 le
nombre des nœuds.
Nous définissons les nœuds IEEE 802.11p. Ceci se fait par les lignes de script suivantes :
80
Nous positionnons initialement les nœuds dans un coordonnées attribuées aleatoirement.
La destination des nœuds et la couleur marquant l’appartenance de ces derniers dans un réseau
VANET sont incluses dans des fichiers externes et que l’on appelle dans le fichier principal.
La configuration des agents TCP est donnée par les lignes de script suivantes :
Nous devrons configurer le début et la fin du transfert des donnés en suivant les lignes de code ci-
dessous :
Enfin, nous clôturerons la configuration de la simulation et par la suite l’exécution de cette dernière.
Ce dernier processus est aussi accompagné par la fermeture de la variable globale contenant la trace
de la simulation ainsi que de la réinitialisation des paramètres des nœuds.
81
4.3.4 Résultats de la simulation
4.3.4.1 Visualisation de la simulation par nam
Pour visualiser la simulation NS-2 propose un outil offrant une vue d’ensemble des différents nœuds
ainsi que la manipulation temporelle du déroulement de la simulation. Pour se faire, la commande
«nam vanet.nam » doit être exécuter depuis le terminal après laquelle une fenêtre s’ouvrira comme
illustrée sur la figure suivante :
Figure 4.04 : GUI nam
82
Pour lancer la simulation il suffit de cliquer sur le bouton «Play» et on aura après le déplacement
des nœuds ,l’interconnexion des nœuds et le transfert des données.
Figure 4.05 : Animation des noeuds
4.3.4.2 Analyse du fichier vanet.tr
Ce fichier contient plusieurs informations brutes. Voici le format d’un fichier vanet.tr [17]
s: sent
r: receive
Expected
duration of
packet
transmission
Sender
MAC
ID
Transmitter
MAC ID
Packet
Type
ID
Sender
Address
Port
Receiver
Address
Port
TTL Next
Hop
Address
event time node Trace
generated
by
Flags Packet
id
Packet
type
flag TCP
seq No;
ACK
No
s 48.533 _25_ MAC --- 9444 tcp [13a 27 19 800] ----
---
[25:1 39:0 30 39] 0 0
r 48.538 _39_ MAC --- 9444 tcp [13a 27 19 800] ----
---
[25:1 39:0 30 39] 1 0
Figure 4.06 : Format du fichier trace de NS-2
83
On y trouve dans
• Le premier champ les évènements qui peuvent être
r : paquet reçue
s : paquet envoyé
+ : mise en file d’attente du paquet
- : sortie de file d’attente du paquet
F : paquet transmis
D : paquet perdu
•Le deuxième champ contient l’instant où la transmission a commencer ou le récepteur a reçu le
paquet
•Le troisième champ indique le numéro du nœud
•Le quatrième champ MAC indique si le paquet concerne la couche MAC ; sa valeur est AGT si
c’est un paquet de la couche transport (par exemple tcp) paquet, ou RTR s’il s’agit du paquet
d'itinéraire. Il peut être IFQ pour les paquets de chute [17].
•Après les tirets c’est le numéro de séquence du paquet global.
•Dans le champ suivant vient plus d'informations sur le type de paquet (par exemple, tcp, ack, ou
udp).
•Les quatre numéros dans les premiers crochets concernent les informations de la couche MAC. Le
premier nombre hexadécimal précise la date prévue pour envoyer ces données sur le canal sans fil.
Le second nombre indiquera l’identifiant MAC du l’envoyeur et le troisième celui de la destination
[17].
•Le prochain nombre dans le deuxième crochet concernent les adresses IP source et destination ainsi
que le TTL (Time To Live) du paquet.
•Les troisièmes parenthèses concernent l'information du paquet TCP : son numéro de séquence et
numéro d’accusé de réception.
La figure suivante montre un exemple d’un fichier source après l’exécution du fichier .tcl :
84
Figure 4.07 : Fichier trace de la simulation
Plusieurs paramètres peuvent décrire les résultats de simulation et on parle dans ce cas de métriques
de performance, ou ils décrivent des variables ou des données d’entrées de simulation comme la
mobilité ou le taux de concentration (on parle de densité) dans une portion de la zone ou le réseau
est mis en place. Dans notre cas, le paramètre throughput ou le débit général entre les nœuds sera
exposé.
4.3.4.3 Débit
Le débit est le nombre de paquets qui passe à travers le canal dans une unité de temps donnée. Cette
performance métrique montre le nombre total de paquets qui ont été livré avec succès à partir du
nœud source au nœud de destination et elle peut être améliorée par augmentation de la densité de
nœud. Il y a deux représentations de débit ; l'un est la quantité de données transférées pendant la
période de temps exprimé en kilobits par seconde (Kbps). L'autre est le pourcentage de distribution
de paquet obtenu à partir d'un rapport de nombre de paquets de données envoyés et le nombre de
paquets de données reçus.
85
4.3.5 Extraction des informations dans le fichier trace
Pour extraire les informations utiles, il est nécessaire d’utiliser le langage awk. awk est un langage
de haut niveau qui fonctionne en lisant des données. Il a été conçu par trois développeurs : Alfred
Aho, Peter Weinberger et Bryan Kernighan. Des fichiers tels que les fichiers traces peuvent être
ainsi traitées par l'utilisateur ce dernier qui peut choisir de lire des données provenant de fichiers ou
du canal de l'entrée standard. Par conséquent, awk a pour but premier de jouer un rôle de filtre bien
qu'il ne se limite pas qu'à cela.
Voici les étapes à suivre :
• Ecrire un code awk pour extraire les throughput du fichier trace
• Exécuter la commande « awk -f throughput_1 vanet.tr > thr.xg pour avoir les informations
utiles contenues dans thr comme l’indique la figure suivante :
Figure 4.08 : Résultats du fichier thr.xg
Le tableau suivant recapitule les throughput en variant le nombre de nœuds et à des instants de
simulation t différent :
Nombre de nœuds Temps (s) Throughput(kbps)
20 502.46
60 502.46
30 90 502.46
120 502.46
150 502.46
20 502.52
60 501.92
35 90 501.92
120 501.92
86
150 501.59
20 502.54
60 500.88
40 90 500.88
120 500.88
150 500.01
20 502.54
60 500.65
45 90 500.65
120 500.65
150 500.33
20 502.59
60 500.50
50 90 500.50
120 500.50
150 500.44
Tableau 4.02: Liste des throughput
4.3.5.2 Graphes et interprétations des résultats
Après l’obtentions de ces résultats il est pratique de les représenter sous forme de courbe pour avoir
une vue plus concrète du throughput :
87
Figure 4.09 : Throughput sur plusieurs noeuds
4.3.6 EstiNet 9.0
Etinet est un simulateur intégré qui regroupe à la fois un simulateur de mobilité et un simulateur de
réseau Ad Hoc. EstiNet fournit un environnement GUI très intègre et professionnel dans lequel un
utilisateur peut facilement diriger selon ses besoin la simulation que ce soit au niveau des couches
qu’au niveau des nœuds. EstiNet supporte aussi bien les nœuds de communication filaire que les
nœuds de communication sans fil comme les concentrateurs, switch, router, hôte, IEEE
802.11(a/g/n) mode ad hoc et mode infrastructure. EstiNet gère les réseaux VANET (IEEE
802.11(p)) et OpenFlow [18].
4.3.6.1 Répartition du GUI
Il y a cinq zones remarquables au niveau du GUI :
(1) Menu Bar : Les menus dans la barre de menu permettent à l’utilisateur d'accéder à toutes les
opérations disponibles. Il existe 9 types de menus: File, Edit, G_Tools, N_Tools,G_Setting,
N_Setting, Simulation, View, and Help.
(2) User Control : Il fournit des icônes indiquant des fonctions de contrôle qui effectue ou modifie
la topologie du réseau.
500
500,5
501
501,5
502
502,5
503
0 20 40 60 80 100 120 140 160
Thro
ugh
pu
t(kb
ps)
temps(s)
courbes des débits
30 noeuds
35 noeuds
40 noeuds
45 noeuds
50 noeuds
88
(3) Network Node: Il supporte des nœuds de réseau afin de dessiner la topologie du réseau dans
zone de travail ou working area.
(4) working area: c’est dans cette zone que l'utilisateur pourrait construire et modifier la topologie
du réseau ainsi que la modification des propriétés des nœuds du réseau.
(5) Playback : Il fournit des boutons de commande de la réécoute pour afficher le résultat de la
simulation dans la zone de travail. Ces différentes zones sont illustrées sur la figure 4.07.
Figure 4.10 : Présentation du GUI
En plus, EstiNet adopte une architecture distribuée. Les principaux composants sont mise en
évidence sur la figure 4.08.
Il y a trois sections principales : GUI, Régulateur ou Dispatcher et Serveur de Simulation. GUI
fournit deux principaux traits : le déploiement de la topologie du réseau et la réécoute des résultats
de la simulation. Le régulateur ou dispatcher transfère la demande de la simulation ou commande
GUI au serveur de la Simulation et obtient des résultats de Serveur de la Simulation qu’il remet à
GUI. Le Serveur de la simulation reçoit la demande de la simulation ou commande par le
coordinateur, et transferts les résultats au régulateur via le coordinateur [18]
89
Figure 4.11 : Architecture d’EstiNet
4.3.6.2 Flux d’opération
EstiNet propose quatre modes de simulations.
a. D Mode Draw Topology
Dans cette mode, l'utilisateur pourrait déployer une topologie de réseau en choisissant un nœud
parmi les proposés et en le glissant dans la zone de travail sur la droite.
Figure 4.12 : Différents types de nœuds
Applications daemons coordinator GUI
Client Job
disptacher
Simulation Engine + Protocol Modules
Fedora Linux Kernel + Kernel Paches
90
b. E Mode : Edit Property
Quand l'utilisateur bascule en Mode E, le programme GUI cherchera automatiquement un sous-
réseau sous un réseau fixe. Il produira alors et assignera des adresses IP et adresses MAC à tous les
nœuds, lesquels appartiennent à la couches 3 des nœuds. Il produira aussi et assignera l'adresse
MAC à tous les nœuds en couches 2. Les hôtes, les switch, et routeurs opèrent principalement sur
la couche 3.
Figure 4.13 : Illustration du mode Edit
c. R Mode : Run Simulation
Quand l'utilisateur bascule en mode R, le GUI créera un répertoire “XXX.sim” et exporte dedans
des fichiers de configuration de la simulation qui contribues collectivement à la description au cas
de la simulation. Après la fin de la simulation, le GUI créera un répertoire “XXX.results” dans
lequel sont entreposés les résultats de la simulation. Le fichier “XXX” et le dossier de la topologie
ont le même nom.
91
Figure 4.14 : Illustration du mode Run
d. P Mode : Play Back
Le serveur de simulation renverra les dossiers du résultat de la simulation au niveau du GUI après
que la simulation soit finie. Le programme GUI entreposera ces dossiers dans des répertoire
“XXX.results” et migre automatiquement en mode playback.
Figure 4.15 : Illustration du mode Play Back
92
4.3.6.3 Présentations des composants VANET dans EstiNet 9.0
Onze interfaces de communications OBU sont supportées actuellement par EstiNet, y compris IEEE
802.11p/1609 agent-based vehicles, IEEE 802.11p module-based vehicles, les véhicules IEEE
802.11a/g en mode ad hoc, les véhicules IEEE 802.11a/g en mode infrastructure, les véhicules
IEEE802.11n en mode ad hoc, les véhicules IEEE, 802.11n en mode infrastructure, et autres
véhicules intégrant des interfaces multiples qui combinent plusieurs types de communications [19].
Figure 4.16 : Présentations des OBU
Un IEEE 802.11p/1609 RSU est un routeur, alors qu'un point d'accès IEEE 802.11a/g/n (AP) joue
le rôle d’un switch. En effet, le premier a une adresse IP spécifique et peut être utilisé pour
transmettre et recevoir des paquets Internet et les transférer des nœuds sous le réseau à IEEE les
802.11p/1609. La figure ci-dessous représente un RSU qui est relié à un hote qui est relié alors à
l'Internet.
Figure 4.17 : RSU
Le GUI permet de sélectionner des objets afin que nous puissions construire les portions de routes
selon notre besoin. Comme nous le montre la figure ci-dessous, trois objets sont proposés pour avoir
le modèle de route qu’on souhaite le premier est une voie à double sens, le second une intersection
et le dernier une voie à double sens qui voit sa capacité rétrécir.
Figure 4.18 : Présentation des objets pour construire une voie
93
4.3.6.4 Scénario de simulation
Pour notre simulation, nous avons choisis trois IEEE 802.11p/1609 agent-based vehicles un RSU
connecté à un hôte et une route composée d’une intersection et d’une voie à double sens. Pendant
les dix premières secondes, les nœuds 3 et 4 communiquent avec le RSU sur le bord de la route afin
d’illustrer la communication V2I. entre la dixième seconde et la vingtième seconde les nœuds 3 et
4 communiquent entre eux pour mettre en évidence la communication V2V. enfin le nœud 3 et 6 se
transmet des informations concernant l’état du trafic pour mettre en lumière l’intervention du réseau
VANET dans la gestion du trafic.
Figure 4.19 : Scénario de simulation
4.3.6.5 Graphes et interprétations des résultats de simulation sur EstiNet 9.0
Après que la simulation soit effectuée, EstiNet enregistre des fichiers .log dans le répertoire des
résultats de simulation. Un outil pour tracer des graphes est intégré dans le GUI permettant
directement d’interpréter les fichiers .log. EstiNet propose un fichier throughput pour visualiser les
débits de transmission des données entre deux nœuds.
94
a. Communication V2V
Les courbes 4.20 montre les débits de communications entre des véhicules sans l’intervention d’un
équipement de route respectant le scénario de simulation que nous avions fixé.
Figure 4.20 : Throughput node 3 et 4
Figure 4.21 : Throughput node 3 et 4
95
Dans les dix dernières secondes de la simulation, le nœud 3 envoie des informations au nœud 6 pour
le prévenir sur l’état du trafic routier. La figure 4.22 montre le throughput de ces nœuds :
Figure 4.22 : Throughput node 6 et 3
b. Communication V2I
Afin de récolter des informations sur l’état du trafic routier, les véhicules doivent communiquer
avec un équipement situé sur le bord de la route ou RSU. Dans notre cas, les nœuds 3 et 4 se trouvent
dans la zone de couverture du RSU. Voici les courbes démontrant les throughput entre les nœuds 3
et 2, ainsi qu’entre les nœuds 4 et 2 :
96
Figure 4.23 : Throughput entre node 2 et 3,4
4.4 Conclusion
Ce dernier chapitre nous a illustré les différentes façons de communications dans un réseau VANET.
Pour cela, des outils informatiques étaient indispensable. Les simulateurs de réseau Ad Hoc et de
trafic routier ont contribué à la construction de cette dernière partie. Néanmoins, les configurations
et réglages que nous avons réalisés étaient nécessaires pour adapter nos scénarii de simulation à
l’environnement que proposent les simulateurs. A la fin, nous avons pu analyser les résultats et en
tirer les informations utiles afin qu’on puisse tracer des courbes démontrant les communications
existantes entre les différents nœuds.
97
CONCLUSION GENERALE
Ce mémoire nous a permis d’affiner notre connaissance sur les lois et théories qui régissent le trafic
routier mais surtout il nous a apporté des précisions sur les réseaux véhiculaires. En effet nous avons
observé plusieurs aspects que ce soit par rapport à l’environnement de déploiement du réseau ou au
niveau de plus interne par rapport aux couches et protocoles utilisés. Ajoutant à cela que les réseaux
véhiculaires permettent de transmettre plusieurs types d’informations telles que des fichiers
multimédias, des fichiers voix et des différentes sortes de divertissements.
Le premier chapitre donne de précieuses précisions concernant le trafic routier mais surtout sur le
trafic routier urbain ; des définitions qui nous sont très utiles pour avoir une vision globale sur les
divers acteurs et facteurs concernant le flux de trafic routier. Ce chapitre porte aussi son attention
sur les modélisations du trafic routier afin que nous puissions bien comprendre les interactions sur
les usagers des routes et les routes elles-mêmes.
Le second chapitre porte son intérêt sur les technologies VANET et WAVE de par leurs
caractéristiques, leurs spécificités ainsi que par leurs modes de fonctionnement. Nous avons pu
constater que plusieurs entités indispensables constituaient le réseau VANET pour assurer la
communication entre les véhicules et les équipements sur les bords de routes.
Dans le troisième chapitre, nous pouvions observer les techniques de dissémination des informations
dans les réseaux VANET. La congestion sur le flux de trafic routier a été soulignée comme étant un
facteur bloquant à une circulation de véhicules que ce soit dans des zones urbaines ou sur les
autoroutes. Nous avons proposé une solution vis-à-vis du problème c’est-à-dire un avertissement
collectif entre les hôtes du réseau véhiculaire.
Le dernier chapitre nous a donné un point de vue plus concret de tous ce qui ont explicité
théoriquement dans les trois premiers chapitres. Cette partie montre des simulations plus ou moins
réalistes compte tenu des divers facteurs agissant sur les paramètres, que ce soit concernant
l’environnement de déploiement que sur les paramètres des acteurs du réseaux.
98
ANNEXE 1 : Programme .tcl
A.1 code source vanet.tcl
#initialisation des variables pour la configuration
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
Phy/WirelessPhyExt set freq_ 5.9e+9 ;#bande DSRC
Phy/WirelessPhyExt set noise_floor_ 1.26e-13 ;#-99 dBm pour une bande passante de
10MHz
Phy/WirelessPhyExt set PowerMonitorThresh_ 6.310e-14 ;#-102dBm sensibilité à la récéption
Phy/WirelessPhyExt set HeaderDuration_ 0.000040 ;#40 us
Phy/WirelessPhyExt set BasicModulationScheme_ OFDMA,
Phy/WirelessPhyExt set SINR_PreambleCapture_ 2.5118; ;# 4 dB
Phy/WirelessPhyExt set SINR_DataCapture_ 100.0; ;# 10 dB
Phy/WirelessPhyExt set trace_dist_ 1e3 ;# connexion jusqu'à 1 km
Mac/802_11Ext set CWMin_ 15
Mac/802_11Ext set CWMax_ 1023
Mac/802_11Ext set SlotTime_ 0.000013
Mac/802_11Ext set SIFS_ 0.000032
Mac/802_11Ext set ShortRetryLimit_ 7
Mac/802_11Ext set LongRetryLimit_ 4
Mac/802_11Ext set HeaderDuration_ 0.000040
Mac/802_11Ext set SymbolDuration_ 0.000008
Mac/802_11Ext set BasicModulationScheme_ OFDMA;
set val(mac) Mac/802_11 ;# norme de la couche MAC
set val(ifq) Queue/DropTail/PriQueue ;# type de file d'attente
99
set val(ll) LL ;# type de liaison entre couche
set val(ant) Antenna/OmniAntenna ;# model d'antenne
set val(ifqlen) 50 ;# paquet maximal en ifq
set val(nn) 49 ;# nombre de noeuds
set val(rp) AODV ;# protocole de routage
set opt(x) 221
set opt(y) 149
LL set bandwidth_1e+6;
Agent/TCP set sport_8080;
Agent/TCP set dport_8080;
Agent/TCP set packetSize_ 512;
#
======================================================================
# programme principal
#
======================================================================
# Initialisation des variables globales
#creation d'une nouvelle simulateur
set ns_[new Simulator]
#creation du fichier trace contenant les divers resultats de la simulation
set tracefd [open vanet.tr w]
$ns_ trace-all $tracefd
#creation du fichier .nam pour l'animation de la simulation
set namf [open vanet.nam w]
$ns_ namtrace-all-wireless $namf $opt(x) $opt(y)
#creation d'une nouvelle topologie
set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
create-god $val(nn)
100
# configuration des noeuds
$ns_ node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON
#creation des noeuds mobiles
for set i 0 $i < $val(nn) incr i
set node_($i) [$ns_ node]
$node_($i) random-motion 0
#coloration des noeuds integrant vanet et attribution de la mobilité des noeuds
source colornode.tcl
source mobility.tcl
# etablissement de connexion TCP entre les noeuds
set tcp [new Agent/TCP]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_(7) $tcp
$ns_ attach-agent $node_(4) $sink
101
$ns_ connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
set tcp1 [new Agent/TCP]
$tcp1 set class_ 2
set sink1 [new Agent/TCPSink]
$ns_ attach-agent $node_(4) $tcp1
$ns_ attach-agent $node_(2) $sink1
$ns_ connect $tcp1 $sink1
set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcp1
set tcp2 [new Agent/TCP]
$tcp2 set class_ 2
set sink2 [new Agent/TCPSink]
$ns_ attach-agent $node_(2) $tcp2
$ns_ attach-agent $node_(0) $sink2
$ns_ connect $tcp2 $sink2
set ftp2 [new Application/FTP]
$ftp2 attach-agent $tcp2
set tcp3 [new Agent/TCP]
$tcp3 set class_ 2
set sink3 [new Agent/TCPSink]
$ns_ attach-agent $node_(2) $tcp3
$ns_ attach-agent $node_(1) $sink3
$ns_ connect $tcp3 $sink3
set ftp3 [new Application/FTP]
$ftp3 attach-agent $tcp3
102
set tcp4 [new Agent/TCP]
$tcp4 set class_ 2
set sink4 [new Agent/TCPSink]
$ns_ attach-agent $node_(2) $tcp4
$ns_ attach-agent $node_(8) $sink4
$ns_ connect $tcp4 $sink4
set ftp4 [new Application/FTP]
$ftp4 attach-agent $tcp4
set tcp5 [new Agent/TCP]
$tcp5 set class_ 2
set sink5 [new Agent/TCPSink]
$ns_ attach-agent $node_(8) $tcp5
$ns_ attach-agent $node_(5) $sink5
$ns_ connect $tcp5 $sink5
set ftp5 [new Application/FTP]
$ftp5 attach-agent $tcp5
set tcp6 [new Agent/TCP]
$tcp6 set class_ 2
set sink6 [new Agent/TCPSink]
$ns_ attach-agent $node_(5) $tcp6
$ns_ attach-agent $node_(6) $sink6
$ns_ connect $tcp6 $sink6
set ftp6 [new Application/FTP]
$ftp6 attach-agent $tcp6
set tcp7 [new Agent/TCP]
$tcp7 set class_ 2
set sink7 [new Agent/TCPSink]
$ns_ attach-agent $node_(6) $tcp7
103
$ns_ attach-agent $node_(9) $sink7
$ns_ connect $tcp7 $sink7
set ftp7 [new Application/FTP]
$ftp7 attach-agent $tcp7
set tcp8 [new Agent/TCP]
$tcp8 set class_ 2
set sink8 [new Agent/TCPSink]
$ns_ attach-agent $node_(9) $tcp8
$ns_ attach-agent $node_(12) $sink8
$ns_ connect $tcp8 $sink8
set ftp8 [new Application/FTP]
$ftp8 attach-agent $tcp8
set tcp9 [new Agent/TCP]
$tcp9 set class_ 2
set sink9 [new Agent/TCPSink]
$ns_ attach-agent $node_(12) $tcp9
$ns_ attach-agent $node_(14) $sink9
$ns_ connect $tcp9 $sink9
set ftp9 [new Application/FTP]
$ftp9 attach-agent $tcp9
set tcp10 [new Agent/TCP]
$tcp10 set class_ 2
set sink10 [new Agent/TCPSink]
$ns_ attach-agent $node_(14) $tcp10
$ns_ attach-agent $node_(19) $sink10
$ns_ connect $tcp10 $sink10
set ftp10 [new Application/FTP]
$ftp10 attach-agent $tcp10
104
set tcp11 [new Agent/TCP]
$tcp11 set class_ 2
set sink11 [new Agent/TCPSink]
$ns_ attach-agent $node_(5) $tcp11
$ns_ attach-agent $node_(25) $sink11
$ns_ connect $tcp11 $sink11
set ftp11 [new Application/FTP]
$ftp11 attach-agent $tcp11
set tcp12 [new Agent/TCP]
$tcp12 set class_ 2
set sink12 [new Agent/TCPSink]
$ns_ attach-agent $node_(25) $tcp12
$ns_ attach-agent $node_(39) $sink12
$ns_ connect $tcp12 $sink12
set ftp12 [new Application/FTP]
$ftp12 attach-agent $tcp12
#debut et fin des flux tcp
$ns_ at 10.0 "$ftp start"
$ns_ at 20.0 "$ftp stop"
$ns_ at 10.0 "$ftp1 start"
$ns_ at 21.5 "$ftp1 stop"
$ns_ at 16.5 "$ftp2 start"
$ns_ at 18.5 "$ftp2 stop"
$ns_ at 17.8 "$ftp3 start"
$ns_ at 20.25 "$ftp3 stop"
105
$ns_ at 17.8 "$ftp4 start"
$ns_ at 21.25 "$ftp4 stop"
$ns_ at 18.68 "$ftp5 start"
$ns_ at 22.65 "$ftp5 stop"
$ns_ at 22.68 "$ftp6 start"
$ns_ at 74.00 "$ftp6 stop"
$ns_ at 22.68 "$ftp7 start"
$ns_ at 80.00 "$ftp7 stop"
$ns_ at 25.00 "$ftp8 start"
$ns_ at 80.00 "$ftp8 stop"
$ns_ at 27.68 "$ftp9 start"
$ns_ at 80.00 "$ftp9 stop"
$ns_ at 29.00 "$ftp10 start"
$ns_ at 100.00 "$ftp10 stop"
$ns_ at 38.50 "$ftp11 start"
$ns_ at 46.00 "$ftp11 stop"
$ns_ at 46.00 "$ftp12 start"
$ns_ at 50.00 "$ftp12 stop"
#reinitialisation des noeuds
for set i 0 $i < $val(nn) incr i
$ns_ at 150.0 "$node_($i) reset";
106
#arret de la simulation
$ns_ at 150.0 "stop"
$ns_ at 150.01 "puts \"NS EXITING...\" ; $ns_ halt"
proc stop
global ns_ tracefd
$ns_ flush-trace
close $tracefd
#debut de la simulation
puts "Starting Simulation..."
$ns_ run
A.1.2 code source colornode.tcl
$ns_ at 0.0 "$node_(4) label node4"
$ns_ at 0.0 "$node_(2) label node2"
$ns_ at 0.0 "$node_(7) label node7"
$ns_ at 0.0 "$node_(0) label node0"
$ns_ at 0.0 "$node_(1) label node1"
$ns_ at 0.0 "$node_(8) label node8"
$ns_ at 0.0 "$node_(5) label node5"
$ns_ at 0.0 "$node_(6) label node6"
$ns_ at 0.0 "$node_(9) label node9"
$ns_ at 0.0 "$node_(12) label node12"
$ns_ at 0.0 "$node_(14) label node14"
$ns_ at 0.0 "$node_(19) label node19"
$ns_ at 0.0 "$node_(25) label node25"
$ns_ at 0.0 "$node_(39) label node39"
$ns_ at 0.00 "$node_(4) add-mark m1 green circle"
107
$ns_ at 0.00 "$node_(2) add-mark m1 green circle"
$ns_ at 0.00 "$node_(7) add-mark m1 green circle"
$ns_ at 0.00 "$node_(0) add-mark m1 green circle"
$ns_ at 0.00 "$node_(1) add-mark m1 green circle"
$ns_ at 0.00 "$node_(8) add-mark m1 green circle"
$ns_ at 0.00 "$node_(5) add-mark m1 green circle"
$ns_ at 0.00 "$node_(6) add-mark m1 green circle"
$ns_ at 0.00 "$node_(9) add-mark m1 green circle"
$ns_ at 0.00 "$node_(12) add-mark m1 green circle"
$ns_ at 0.00 "$node_(14) add-mark m1 green circle"
$ns_ at 0.00 "$node_(19) add-mark m1 green circle"
$ns_ at 0.00 "$node_(25) add-mark m1 green circle"
$ns_ at 0.00 "$node_(39) add-mark m1 green circle"
108
ANNEXE 2 : code xml utilisé par SUMO
A.2.1 code source contenu dans le fichier vanet.sumo.xml
<?xml version="1.0" encoding="UTF-8"?>
<fcd-export xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://sumo.dlr.de/xsd/fcd_file.xsd">
<timestep time="1.00">
<vehicle id="1" x="130.01" y="145.50" angle="198.92" type="DEFAULT_VEHTYPE"
speed="0.00" pos="5.10" lane="-29079273_0" slope="0.00"/>
</timestep>
<timestep time="1.10">
<vehicle id="1" x="130.00" y="145.47" angle="198.92" type="DEFAULT_VEHTYPE"
speed="0.25" pos="5.12" lane="-29079273_0" slope="0.00"/>
</timestep>
<timestep time="1.20">
<vehicle id="1" x="129.98" y="145.43" angle="198.92" type="DEFAULT_VEHTYPE"
speed="0.49" pos="5.17" lane="-29079273_0" slope="0.00"/>
</timestep>
<timestep time="1.30">
<vehicle id="1" x="129.96" y="145.35" angle="198.92" type="DEFAULT_VEHTYPE"
speed="0.75" pos="5.25" lane="-29079273_0" slope="0.00"/>
</timestep>
<timestep time="1.40">
<vehicle id="1" x="129.93" y="145.26" angle="198.92" type="DEFAULT_VEHTYPE"
speed="0.98" pos="5.35" lane="-29079273_0" slope="0.00"/>
</timestep>
<timestep time="1.50">
<vehicle id="1" x="129.89" y="145.15" angle="198.92" type="DEFAULT_VEHTYPE"
speed="1.21" pos="5.47" lane="-29079273_0" slope="0.00"/>
</timestep>
<timestep time="1.60">
<vehicle id="1" x="129.84" y="145.01" angle="198.92" type="DEFAULT_VEHTYPE"
speed="1.46" pos="5.61" lane="-29079273_0" slope="0.00"/>
109
</timestep>
A.2.2 ligne de commande pour la conversion du fichier osm en fichier xml
$]netconvert --osm-files "fichier.osm" -o "fichier converti.net.xml"
copy /usr/local/src/sumo-0.32.0/data/typemap/osmPolyconvert.typ.xml metre dans le map dossier
$]polyconvert --osm-files "fichier.osm" --net-file "#.net.xml" --type-file osmPolyconvert.typ.xml -
o "fichier.poly.xml"
$]python /usr/local/src/sumo-0.32.0/tools/randomTrips.py -n vanet.net.xml -r vanet.rou.xml -e 50 -
l
110
BIBLIOGRAPHIE
[1] : S. Fayer « Contrôle du trafic routier urbain par un réseau fixe de capteurs sans fil »,
Département Informatique et Réseaux Groupe RMS : Réseaux, Mobilité et Services Mars 2012
date de consultation : 08 janvier 2018
[2] : C. Buisson-Jean Baptiste « Lesort Comprendre le trafic routier Méthodes et calculs »,
direction générale des Infrastructures, des Transports et de la Mer Certu Centre d’Etude sur les
réseaux, les Transports, l’urbanisme et les constructions publics consulté le 09 janvier 2018
[3] : K. Boumediene « Gestion de trafic : contrôle d’accès et limitation dynamique de la vitesse »,
Université d’Artois thèse en vue de l’obtention du doctorat Spécialité Génie Informatique et
Automatique consulté le 15 janvier 2018
[4] : S. Faye « Contrôle et gestion du trafic routier urbain par un réseau de capteurs sans fil »,
École doctorale Informatique, Télécommunications et Électronique (Paris) thèse pour obtenir le
grade de docteur délivré par telecom ParisTech Spécialité « Informatique et Réseaux » consulté
le 18 février 2018
[5] : D. Fabián « Téléchargement des Contenus dans les réseaux véhiculaires », Université de
Toulouse thèse en vue de l’obtention du Doctorat de L’Univérsité de Toulouse Délivré par
Institut National Polytechnique de Toulouse (INP Toulouse) Discipline ou Spécialité Réseaux,
Télécommunications, Systèmes et architecture (RTSA) consulté le 18 février 2018
111
[6] : B. Abdellah Kebbi Menad « Conception et Réalisation d’un simulateur dédie pour les
réseaux véhiculaires », Université Abderrahmane Mira de Béjaïa Faculté des Sciences Exactes
Département d’Informatique Mémoire de Master Professionnel consulté le 22 février 2018
[7] : J. Petit « Surcoût de l’authentification et du consensus dans la sécurité des réseaux sans fil
véhiculaires », Université de Toulouse Institut de Recherche en Informatique de Toulouse
consulté le 22 février 2018
[8] : A. Adigun « Gestion de l’anonymat et de la traçabilité dans les réseaux véhiculaires sans
fil » Université du QUEBEC à Trois-Rivières consulté le 29 février 2018
[9] : C. Christopher Mandy Jr “Implementation of the IEEE 1609.2 WAVE security services
standard”, A Thesis Submitted to the Faculty of The College of Engineering and Computer
Science in Partial Fulfillment of the Requirements for the Degree of Master of Science consulté
le 01 Mars 2018
[10] : A. Abdelgader, W. Lenan “The Physical Layer of the IEEE 802.11p W AVE
Communication Standard: The Specifications and Challenges”, Proceedings of the World
Congress on Engineering and Computer Science 2014 Vol II consulté le 02 Mars 2018
[11] : R. Avotra « etude du handover entre les réseau 4G LTE et le WiFi », mémoire de license
univérsité d’Antananrivo Ecole superieure Polytechnique d’Antananrivo en vue de l’obtention du
diplôme de license professionnel consulté le 04 Mars 2018
[12] : N. HADDADOU “Réseau ad hoc véhiculaires : vers une dissémination de données
efficace, coopérative et fiable”, Univérsité Pairs-Est Ecole Doctorale MSTIC consulté le 05 Mars
2018
[13] : D. Skellern «RRM Architectural Framework », Wireless Networking Business Unit Cisco
Systems Inc [email protected] consulté le 10 Mars 2018
[14] : A. Benchabana et R. Bensaci “Analyse des protocoles de routage dans les réseaux VANET”
Mémoire Master Académique Université Kasdi Merbah-Ouargla Faculté des Nouvelles
Technologies de l’Information et de la Communication consulté le 15 Mars 2018
[15] : A. Sulface « Simulation du trafic routier et communication inter-véhicules », Université
Laval Quebec Département D’Inormatique et de Génie Logiciel consulté le 20 Mars 2018
112
[16] : S.Hafid “Systèmes de Transport Intelligent :Réseau Véhiculaire”, Laboratoire des
réseaux de Communication Département d’Informatique et RechercheOpérationnelle Université
de Montréal consulté le 21 Mars 2018
[17] : B. Junot « comparaison de protocole de routage AODV et DSDV dans un réseau MANET »,
univérsité d’Antananrivo Ecole superieure Polytechnique d’Antananrivo mémoire de fin d’étude
en vue de l'obtention du diplome de Master consulté le 18 juin 2018
[18]: Produced and maintained by EstiNet Technologies Inc. Release Date: July 7, 2017 The GUI
User Manual for the EstiNet 9 .0 Network Simulator consulté le 20 juin 2018
[19]: Produced and maintained by EstiNet Technologies Inc Graphic User Interface (GUI) manual
VANET module of estinet simulator 9.0 V1.0
113
FICHE DE RENSEIGNEMENTS
Nom : RAFALISON
Prénom : Avotra
Adresse : VB III 036 Tongarivo Tanjombato
Antananarivo 102 Madagascar
0329251712/0341162036
[email protected]/[email protected]
Titre du mémoire :
« GESTION DU TRAFIC ROUTIER URBAIN A L’AIDE DES TECHNOLOGIES VANET ET
WAVE »
Nombres de pages : 112
Nombres de tableaux : 05
Nombre de figures : 59
Directeur de mémoire :
Nom : RASOLOMANANA
Prénoms : Jean Fanomezantsoa
Téléphone : 033 11 248 28
RESUME
En résumé, des précisions ont pu être apportées par rapport à la compréhension du trafic routier et
son environnement ainsi que sa gestion. De même, beaucoup de connaissances ont été récoltées
dans le domaine du réseau mobile sans fil tel que les VANET et les technologies qui l’accompagnent
à savoir WAVE et la bande DSRC. VANET permettent de croiser les besoins de partage
d’informations sur l’état du trafic routier urbain et son environnement avec les avantages de ces
réseaux. Bien que les réseaux véhiculaires offrent plusieurs services, nous avons consacré notre
ouvrage sur la gestion du trafic routier ainsi qu’à la simulation du trafic routier combinée à la
simulation du point de vue des réseaux Ad Hoc. Notons que trois simulateurs ont été sollicités
pendant ce travail à savoir SUMO, NS- 2 et EstiNet 9.0 afin que nous puissions combiner une
fiabilité de résultats de simulation avec des paramètres en termes de nombre de nœuds plus réalistes.
Mots clé : gestion, trafic, VANET, WAVE, réseau
ABSTRACT
In summary, some precisions have been brought in this work to understand the road traffic and its
environment as well as its management. In the same way, many of knowledge has been harvested
in the domain of the wireless mobile network as the VANET and the technologies that comes with
as WAVE and the DSRC band. VANET permit to cross the needs of sharing informations on the
state of the urban road traffic and its environment with the advantages of these networks. Although
the vehicular networks offer several services, we dedicated our work on the management of the road
traffic as well as to the simulation of the road traffic combined with the simulation of the Ad Hoc
networks. Let's note that three simulators have been solicited during this work like SUMO, NS - 2
and EstiNets 9.0 in the goal to combine a reliability of simulation results with parameters in terms
of number of node more realistic.
Key words : management, traffic, VANET, WAVE, network
