Dans cette section, nous pr´esentons tout d’abord les cinq protocoles utilis´es pour notre comparaison syst`eme avec CBL-OLSR. Quatre de ces protocoles ont d´ej`a une mod´elisation d´evelopp´ee par OPNET Ri-verbed Modeler. Ce sont deux protocoles r´eactifs, Ad-hoc On Demand Distance Vector Protocol (AODV) [44] et Dynamic Source Routing (DSR) [193], et deux protocoles proactifs, Optimized Link State
Rou-ting protocol (OLSR) [31] (section 2.5.1) et Geographic Routing Protocol (GRP) [53] (section 1.3.1.1).
Par ailleurs, la mod´elisation sous OPNET du protocole QoS - Optimized Link State Routing protocol (QOLSR) de l’article [114], notre cinqui`eme protocole de comparaison, a ´et´e mise `a notre disposition
par son auteur. Nous expliquons alors les sc´enarios de communication cr´e´es pour cette ´evaluation com-parative, puis les m´etriques applicatives de performance avant de produire notre analyse des r´esultats obtenus.
5.1.1 Pr´esentation des protocoles et sp´ecification de leurs param´etrages
5.1.1.1 AODV
Le protocole AODV [44] est un protocole r´eactif. Ses param`etres par d´efaut sont repris dans le ta-bleau 5.1.
Les nœuds de communication AODV envoient des messages HELLO afin d’effectuer une maintenance des routes actives `a une fr´equence d´efinie par le param`etre Hello interval. Si aucune route n’est active, aucun message HELLO n’est envoy´e (pas de d´etection du voisinage). Lorsqu’un nœud n’a pas re¸cu de message HELLO d’un nœud voisin durant une p´eriode sup´erieure `a Hello loss, il supprime ce dernier de sa table de routage. Le syst`eme de recherche de route par l’envoi de paquets RREQ/RREP est utilis´e (section 1.2.4.2). Une optimisation est effectu´ee quant `a l’envoi du paquet de recherche de route RREQ. Le paquet est d’abord envoy´e au voisinage proche avec un TTL (section 2.5.1) fix´e par le param`etre TTL start. Si le nœud source ne re¸coit pas de r´eponse apr`es une dur´ee RingTraversalTime, il incr´emente la valeur du TTL de TTL increment (dans la limite du seuil maximal de TTL threshold, sinon, en cas de d´epassement de ce seuil, le TTL est fix´e par le param`etre Net diameter ), puis il renvoie un paquet de recherche de route. La dur´ee RingTraversalTime est d´efinie par l’´equation 5.1 :
RingTraversalTime = 2 ∗ NodeTraversalTime ∗ (TTL + Timeoutbuffer) (5.1)
o`u N odeT raversalT ime est la dur´ee de traitement du paquet et Timeoutbuffer un temporisateur qui permet de prendre en compte le temps suppl´ementaire en cas de congestion du m´edium de communication. Une limite d’envoi du mˆeme paquet de recherche de route est fix´ee par le param`etre Route request retries. Pour ´eviter la saturation du m´edium, le d´ebit maximum des paquets de recherche de routes est limit´e par le param`etre Route error rate limit. Lorsqu’un nœud est un relais interm´ediaire d’une route, il enregistre la route trouv´ee vers le destinataire dans une table de routage. Cet enregistrement est supprim´e au bout d’une dur´ee de route inactive Active route timeout. Enfin, si l’option Local repair est active, un nœud interm´ediaire se rendant compte que la liaison avec le nœud interm´ediaire suivant est rompue peut envoyer des paquets de recherche de route pour retrouver une route alternative. Si cette option n’est pas activ´ee, le nœud interm´ediaire envoie un paquet au nœud source pour le pr´evenir de la rupture de la liaison et dans ce cas, le nœud source cherchera une route alternative.
TABLEAU 5.1 – Param`etres par d´efaut du protocole AODV [44]
Attributs Valeurs Attributs Valeurs
Route request retries 5 TTL start 1
Route request rate limit 10 paquets/s TTL increment 2 Active route timeout 3 s TTL threshold 7 Hello interval uniform(1 ; 1,1 s) Local repair active Packet queue size infinity Hello loss 2 s Net diameter 35 sauts Addressing mode IPV4 Node traversal time 0,04 s Timeout buffer 2 Route error rate limit 10 paquets/s
5.1.1.2 DSR
Le protocole DSR [44] est un protocole de routage r´eactif. Son param´etrage par d´efaut est pr´esent´e dans le tableau 5.2. Le syst`eme de recherche de route est tr`es proche de celui de AODV, except´e le fait que chaque nœud interm´ediaire relayant un paquet de recherche de route RREQ l’enrichit de son identifiant. Avec cette liste, le nœud destinataire connaˆıt l’ensemble des nœuds relais interm´ediaires par lesquels le
destination du nœud source. Comme AODV, il offre ´egalement une option de r´eparation de route locale et d’envoi de paquets RREQ limit´e au voisinage proche. Ces deux options sont d´esactiv´ees par d´efaut.
TABLEAU 5.2 – Param`etres par d´efaut du protocole DSR [193]
Attributs Valeur Attributs Valeur
D´ecouverte de routes : Maintenance de routes :
Request table size 64 nœuds Max buffer size 50 paquets Req. table identifiers 16 Hold off time 0,25 s Req. retransmission. 16 Maint. Retransmis. 2
Max. Req. period 10 s Ack. timer 0,5 s
Non-propagating Req. d´esactiv´e Send Buffer :
GratuitousReply timer 1 s Max. Buffer size infini Enregistrement de routes : Buffer timeout 30 s Max Cached routes infinity
Route Cache timeout 300 s Packet salvaging active
Route Cache export d´esactiv´e Broadcast jitter uniform(0 ; 0,01) s
5.1.1.3 OLSR
Le protocole proactif OLSR [31] ayant d´ej`a ´et´e d´ecrit en section 2.5.1, nous ne rappelons ici que les param`etres du protocole utilis´es par d´efaut au moyen du tableau 5.3.
Attribut Valeur par d´efaut Willingness d´efaut
Hello interval 2 s
TC interval 5 s
Neighbor hold time 6 s (3*Hello interval ) Topology hold time 15 s (3*TC interval ) Duplicate message hold time 30 s
Adressing IPV4
TABLEAU 5.3 – Param`etres par d´efaut du protocole OLSR [31]
5.1.1.4 QOLSR
Le protocole QOLSR [114] est une adaptation de OLSR qui prend en compte la qualit´e des liaisons entre les nœuds du r´eseau `a l’aide des m´etriques de d´elais, d´ebit et pertes de paquets. Chaque nœud ajoute, dans les messages HELLO envoy´es par le protocole OLSR, la date courante, qui sert aux calculs des m´etriques de d´elai et de d´ebit, et sa position g´eographique, qui intervient dans la d´etermination du taux de perte de paquets qui est pour QOLSR fonction de la distance entre les nœuds. Ces trois m´etriques `a QoS entrent en compte dans le choix des nœuds MPR : les nœuds qui maximise la fonction de score de [114] d´efinie comme une moyenne pond´er´ee du d´elai, du d´ebit, du taux de perte des paquets et du Willingness sont prioritairement choisis comme MPR. Les autres param`etres de ce protocole sont identiques `a ceux d’OLSR.
5.1.1.5 GRP
Le protocole proactif g´eographique GRP [53], d´ej`a ´evoqu´e en section 1.3.1.1, utilise la m´ethode de routage gloutonne en association avec une division hi´erarchique du r´eseau en zones rectangulaires. Ses param`etres utilis´es par d´efaut sont rappel´es dans le tableau 5.4.
Pour ce protocole GRP [53], les tables de routage des nœuds d’une mˆeme zone comportent la position exacte des nœuds de cette zone. Pour les nœuds voisins situ´es hors de cette zone, seul le num´ero de la zone du nœud de niveau hi´erarchique sup´erieur est enregistr´e dans ces tables de routage. Ainsi, si un
TABLEAU 5.4 – Param`etres par d´efaut du protocole GRP [53]
Attributs Valeur Attributs Valeur
Hello interval 5 s Backtrack activ´e Neighbor expiry time 10 s Route export d´esactiv´e Distance moved 1000 m Number of initial floods 1 Position request timer 5 s Quadrant size 2 km
nœud de la zone Aa1 a des voisins en zones Aa2, Aa3 et Aa4, le nœud de la zone Aa1 m´emorise dans sa table de routage le fait que chacun de ses voisins est situ´e en zone Aa.
Les paquets HELLO transmis contiennent la position des nœuds. Pour limiter le trafic de routage des paquets HELLO, un nœud n’envoie sa nouvelle position que dans l’un des cas suivants : 1) il a parcouru une certaine distance (param`etre Distance moved ), 2) il a chang´e de zone, 3) il n’a plus envoy´e sa position depuis une certaine dur´ee d´efinie par un seuil temporel (param`etre HELLO interval ). Selon le cas, la port´ee g´eographique de la transmission de ces paquets est ainsi limit´ee. Dans les cas 1) et 2), l’information est propag´ee aux nœuds de la zone de niveau hi´erarchique sup´erieur commune `a l’ancienne et `
a la nouvelle zone ; dans le cas 3), sa port´ee est limit´ee aux voisins imm´ediats (`a un saut). La suppression d’un nœud des tables de routage des nœuds d’une zone est par ailleurs r´ealis´ee lorsqu’un nœud voisin n’a plus ´emis de paquets durant une p´eriode (param`etre Neighbour expired time).
Au moment de l’envoi d’un paquet applicatif, lorsque le nœud destinataire est connu, dans la table de routage du nœud ´emetteur, comme faisant partie de la mˆeme zone (Ba1 par exemple), alors la m´ethode de routage gloutonne est utilis´ee. S’il est situ´e dans une autre zone que celle du nœud ´emetteur, alors ce dernier transmet le paquet `a un voisin de la zone de niveau hi´erarchique sup´erieur (Ba dans cet exemple). Ce nœud voisin sert alors de serveur de localisation. Lorsque le paquet atteint un optimum local, il est renvoy´e au nœud interm´ediaire pr´ec´edent si l’option Backtrack est active. Le nœud cherche alors un autre nœud du r´eseau pour atteindre la destination et s’il n’en trouve pas, il retourne le paquet `a l’exp´editeur.
5.1.2 D´efinition du trafic applicatif, des sc´enarios de communication et du
param´etrage de OPNET Riverbed Modeler
Notre objectif est de comparer notre proposition CBL-OLSR aux protocoles de routage mentionn´es ci-dessus. Nous nous int´eressons en particulier aux applications de s´ecurit´e (section 3.7) relatives aux v´ehicules autonomes qui sont un v´eritable challenge pour les VANETs en termes de d´elais et de bande passante. Dans ce type d’applications de s´ecurit´e, les fonctions embarqu´ees (capteurs, g´eolocalisation, perception ´elargie, etc.) n´ecessitent l’envoi p´eriodique de variables (telles la vitesse, l’acc´el´eration et la position) pour leur fonctionnement. L’application pr´esent´ee ici est conforme aux pr´econisations de l’IEEE pour les communications en environnement v´ehiculaire [10]. Elle se d´ecline ainsi : des paquets de 300 octets sont envoy´es `a une fr´equence de 10 Hz.
`
A partir de cette d´efinition applicative, nous avons d´efini trois sc´enarios d’´evaluation (Sa1, Sa2 et Sa3) qui utilisent tous les trois le r´eseau routier et la densit´e de v´ehicules pr´ec´edemment d´efinis pour le sc´enario S5 (tableau 3.6). Sa1, Sa2 et Sa3 se distinguent par le nombre de nœuds concern´es par l’envoi et la r´eception du trafic applicatif en mode de communication multicast (section 1.2.3). Ces nœuds sont choisis al´eatoirement une fois avant l’ex´ecution d’un sc´enario d’´evaluation donn´e. Ainsi, pour un sc´enario, les simulations des six protocoles sont r´ealis´es sur le mˆeme panel de nœuds, ´emetteurs et r´ecepteurs. Dans le sc´enario Sa1, 10 nœuds source sont choisis correspondant `a un taux de p´en´etration de 5% des v´ehicules communicants sur un total de 205 nœuds ; dans le sc´enario Sa2, 15 nœuds sont choisis soit un taux de p´en´etration de 7,5% ; et enfin dans le sc´enario Sa3, 20 nœuds soit un taux de p´en´etration de 10%. Chaque sc´enario a ´et´e ex´ecut´e 10 fois avec des valeurs diff´erentes de seed pour l’initialisation du g´en´erateur de nombre al´eatoire du logiciel OPNET Riverbed Modeler pour ´eviter qu’une s´equence particuli`ere de nombres al´eatoires ne favorise un des protocoles.
Les simulations de cette section commencent `a la date t’=200 s pour que le r´eseau soit compl`etement charg´e en v´ehicules. Nous avons d´eclench´e l’´emission du trafic applicatif 30 s apr`es l’initialisation du r´eseau (soit `a t’=230 s) pour laisser le temps aux nœuds d’effectuer la d´ecouverte de leur voisinage. Puis,
le trafic applicatif est stopp´e 30 s apr`es son d´eclenchement (soit `a la date t’=260 s). Dans la suite de la section 5.1, nous fixerons comme r´ef´erence temporelle t=0 `a la date de t’=200 s de mani`ere `a ce que l’activation du trafic applicatif intervienne sur les courbes de r´esultats `a t=30 s.
Nous gardons pour ces simulations les valeurs des param`etres d’OPNET Riverbed Modeler telles que d´efinies dans les tableaux 3.11 et 3.9.
5.1.3 M´etriques de performance
Les m´etriques de performance applicatives (Ma - M´etriques applicatives) utilis´ees pour cette ´evaluation sont les suivantes :
− Ma1 : Charge du r´eseau, le d´ebit en bit/s des messages envoy´es sur le r´eseau ; − Ma2 : D´ebit du r´eseau, le d´ebit en bit/s des messages re¸cus sur le r´eseau ;
− Ma3 : Trafic de routage envoy´e, le d´ebit en bit/s des messages de routage envoy´es et retransmis sur le r´eseau ;
− Ma4 : Trafic de routage re¸cu, le d´ebit en bit/s des messages de routage re¸cus sur le r´eseau ; − Ma5 : Retransmission, le taux de retransmission des messages ;
− Ma6 : Nb saut, le nombre de sauts effectu´es par un message (nombre de nœuds relais interm´e-diaires) ;
− Ma7 : D´elai WLAN, le d´elai de transmission de bout-en-bout d’une trame en ms ; − Ma8 : D´elai d’acc`es au m´edium en ms.
Ces m´etriques sont communes `a l’´etude des protocoles de routage consid´er´es dans ce chapitre. Pour la section 5.1, la valeur retenue pour chaque m´etrique est la moyenne des valeurs de la m´etrique obtenues pour chacune des 10 simulations r´ealis´ee avec un seed diff´erent.
5.1.4 Analyse des r´esultats – sc´enario applicatif Sa2
Apr`es activation du trafic applicatif, `a t=30 s, la charge du r´eseau (Ma1) augmente de mani`ere importante pour tous les protocoles de routage (figure 5.1). Cette charge de trafic inclut les messages de routage et d’application envoy´es par les 15 nœuds source du sc´enario Sa2 ainsi que les messages retransmis par les nœuds relais. Durant l’envoi des messages applicatifs (entre t=30 s et t=60 s), le protocole OLSR a la charge la plus faible avec une moyenne de 4,8 Mbit/s (tableau G.2 en annexe G), puis viennent les protocoles AODV et CBL-OLSR avec une moyenne respective de 8 et 8,2 Mbit/s. Ensuite vient le protocole GRP avec une charge moyenne de 9,9 Mbit/s. Enfin, les deux protocoles QOLSR et DSR pr´esentent la charge la plus ´elev´ee avec des moyennes respectivement de 15 Mbit/s et 18 Mbit/s. Notons que la charge du r´eseau est sup´erieure pour les protocoles QOLSR et DSR `a la limite de la bande passante fix´ee dans les simulations (12 Mbit/s). En effet, cette limite n’est valable que localement `a une zone de port´ee donn´ee, ici de 500 m, et non `a l’´echelle du r´eseau routier simul´e de 5 km. Pour un mˆeme trafic applicatif, les protocoles de routage n’ont pas la mˆeme gestion de la charge du r´eseau, passant du simple au triple. Notre proposition CBL-OLSR se classe en troisi`eme position par rapport `a la charge du r´eseau pour le sc´enario Sa2.
Le profil de l’´evolution de la charge du r´eseau au cours du temps de simulation est ´egalement int´eressant `a ´etudier. Les protocoles proactifs OLSR et CBL-OLSR pr´esentent une augmentation de la charge entre t=30 s et t=35 s due au d´elai d’acc`es au m´edium qui augmente lorsque l’application est activ´ee (m´etrique Ma8, figure 5.9). Puis nous observons une petite diminution et une stabilisation entre t=35 s et t=60 s. Les protocoles QOLSR et GRP ont une charge tr`es stable durant l’envoi des messages applicatifs. La charge des deux protocoles r´eactifs AODV et DSR est moins stable ´etant donn´e l’utilisation des requˆetes RREQ/RREP. Pour le protocole DSR, on remarque un d´elai de 5 s `a 10 s avant stabilisation de la charge `
a sa valeur moyenne. Ce d´elai est li´e `a la recherche de route r´eactive. Le syst`eme TTL du protocole AODV permet de limiter ce d´elai. De plus, pour ce protocole, le pic de charge maximale lors de l’envoi des requˆetes RREQ/RREP est limit´e `a l’aide du param`etre Route request rate limit. Apr`es l’arrˆet de l’envoi des messages applicatifs, la charge du r´eseau devrait ˆetre ´egale au trafic de routage envoy´e et ainsi revenir `a l’´etat avant t=30 s. En regardant conjointement la figure 5.1 et 5.3, nous observons que c’est le cas pour tous les protocoles proactifs (CBL-OLSR, OLSR, QOLSR et GRP). Ce n’est pas le cas pour les