protocole de routage géo-multipoint hybride et mécanisme d’acheminement de...
Post on 16-Sep-2018
219 Views
Preview:
TRANSCRIPT
Année 2010
Institut National des Sciences Appliquées de Lyon Bâtiment Blaise Pascal, Campus de la Doua, 69621 Villeurbanne Cedex, France
InfoMaths : Informatique et Mathématiques
THÈSE DE DOCTORAT
Protocole de routage géo-multipoint hybride et mécanisme d’acheminement de données pour les réseaux ad hoc de véhicules
(VANETs)
Pour l’obtention du
Grade de Docteur (spécialité informatique)
Par
Talar Atéchian
(Date de la soutenance : vendredi 24 septembre 2010) Commission d’examen composée de :
Rapporteurs : HAMEURLAIN Abdelkader Pr (IRIT – Université Paul Sabatier, Toulouse) MOSTEFAOUI Ahmed Dr HdR (LIFC – Université Franche-Comté) Examinateurs : PINON Jean-Marie Pr (LIRIS - INSA de Lyon) YETONGNON Kokou Pr (Le2i – Université de Bourgogne) CHBEIR Richard Dr (Le2i – Université de Bourgogne) GHOBRIL Paul Dr (Université Antonine, Beyrouth, Liban) NAJJAR Faiza Dr (École Nationale des Sciences de
l’informatique, Tunis, Tunisie) Directeur : BRUNIE Lionel Pr (LIRIS- INSA de Lyon)
RÉSUMÉ
Les réseaux ad hoc mobiles (MANET) sont des réseaux sans infrastructure fixe composés
d’entités mobiles (appelées aussi nœuds). Les nœuds dans les réseaux MANETs communiquent
entre eux à travers une communication radio. La communication entre les nœuds s’établit d’une
manière directe lorsque les nœuds sont à portée radio l’un de l’autre : nous parlons alors d’une
communication à un saut. Cependant, une communication multi-sauts peut également être
établie entre des nœuds distants (c’est-à-dire des nœuds hors de portée radio), par
l’intermédiaire des nœuds mobiles disponibles dans le réseau.
Dans les années 2000, les réseaux ad hoc ont été déployés dans des environnements fortement
dynamiques et utilisés, en particulier, pour la communication inter-véhicules (VANETs –
Vehicular Ad hoc Networks). Les systèmes de transport intelligents (STI) ont été les premières
applications déployées dans les réseaux ad hoc de véhicules. Récemment, des applications
multimédias ont été également conçues pour les VANETs. Ces applications visent à partager
des données multimédias entre les véhicules. Cependant, en raison de la forte mobilité des
véhicules, le transfert de données multimédias sur les chemins de communication offre un
risque important d’être interrompu. Ces ruptures de transfert de données affaiblissent la qualité
de service et le bon fonctionnement des applications multimédias.
Dans le cadre de cette thèse, nous nous intéressons à l’étude de l’impact de la mobilité sur les
applications de transfert de données volumineuses dans les VANETs. Ces applications sont
composées de transactions de type requête/réponse. Le mécanisme de routage mis en œuvre
dans ces échanges repose sur les deux phases suivantes : (1) une phase de dissémination de
requêtes, (2) une phase de transfert de données en réponse. Chacune de ces deux phases
nécessite un routage adapté afin de garantir une bonne qualité de service.
Nous proposons un protocole de routage géo-multipoint hybride, appelé DG-CastoR (Direction-
based GeoCast Routing). Le protocole DG-CastoR offre une double fonctionnalité. En premier
lieu, pour chaque requête disséminée, DG-CastoR propose un mécanisme de construction
implicite d’un overlay (appelé colonie), c’est-à-dire un recouvrement virtuel de la topologie
physique du réseau constitué des nœuds qui peuvent contribuer à répondre à la requête. La
colonie possède une topologie en étoile centrée sur le nœud source de la requête. Grâce à cette
topologie virtuelle, le chemin de routage des données est facilement détecté et construit. En
pratique, les nœuds candidats pour adhérer à la colonie, sont sélectionnés selon leur trajectoire
future. Dans ce contexte, nous proposons une nouvelle méthode de recherche de voisinages
proches appelée TQ – Trajectory Queries. Cette méthode, grâce aux mesures de similarité
spatio-temporelle des trajectoires, sélectionne parmi les véhicules du réseau, ceux capables de
garantir une durée de connectivité compatible avec les contraintes de l’application. La seconde
fonctionnalité de DG-CastoR concerne la dissémination multipoint de la requête vers les nœuds
appartenant à la colonie construite. Il s’agit, en pratique, d’une dissémination sélective du
paquet vers un ensemble défini de destinataires.
Dans la deuxième partie de notre travail, nous proposons une application de gestion de données
conçue spécialement pour les réseaux ad hoc mobiles, appelée : CoFFee - Cooperative and
inFrastructure-Free peer-to-peer. Grâce aux services de gestion de données, CoFFee améliore le
transfert des données et assure un usage optimisé de la bande passante partagée.
Ainsi, notre approche répond à la problématique de la qualité de service des applications de
transfert de données à deux niveaux. Au niveau de la couche réseau (niveau 3), le protocole de
routage DG-CastoR assure une fiabilité des chemins de routage. Au niveau de la couche
applicative (niveau 7), l’application CoFFee garantit un bon usage de la bande passante.
Nous avons évalué nos principales contributions par des séries d’expérimentations. En premier
lieu, nous avons étudié la précision du calcul de similarité spatio-temporelle mis en oeuvr dans
la méthode TQ. Ensuite, nous avons évalué le protocole DG-CastoR et avons mis en œuvre les
améliorations du transfert de données apportées par l’application CoFFee. Ces expérimentations
confirment l’intérêt des approches proposées.
Mots clés : Réseaux ad hoc de véhicules (VANET), Informatique mobile, routage
géographique/multipoint, réseaux overlay, acheminement bout-à-bout de données multimédias,
qualité de service, communication radio.
TABLE DES MATIÈRES
Page
CHAPITRE 1 : INTRODUCTION ET MOTIVATION
1.1 INTRODUCTION ................................................................................................................ 1 1.2 EXEMPLES DE CAS D’UTILISATION ............................................................................ 6 1.3 PROBLÉMATIQUE ET PRINCIPALES CONTRIBUTIONS ........................................... 9
1.3.1 Problématique ........................................................................................................ 9 1.3.2 DG-CastoR : Protocole de routage géo-multipoint hybride .................................. 9 1.3.3 CoFFee : Une application de gestion de données dans les VANETs .................. 10
1.4 ORGANISATION DU MANUSCRIT .............................................................................. 11
CHAPITRE 2 : LES PROTOCOLES DE ROUTAGE - UN ÉTAT DE L'ART 2.1 INTRODUCTION .............................................................................................................. 15 2.2 DISSÉMINATION DE REQUÊTES : PROTOCOLES DE ROUTAGE MULTIPOINTS ET GÉOGRAPHIQUES .............................................................................................................. 17
2.2.1 Protocoles de routage multipoints ....................................................................... 17 2.2.2 Protocoles de routage géographiques ................................................................. 22
2.3 PROTOCOLES DE ROUTAGE UNICAST POUR LE TRANSFERT DES DONNÉES 29 2.3.1 Protocoles de routage unicast .............................................................................. 29 2.3.2 Protocoles unicast hybrides ................................................................................. 37 2.3.3 Protocoles unicast tolérants aux délais ................................................................ 38 2.3.4 Protocoles de routage intégrant la qualité de service .......................................... 40
2.4 DISCUSSION ET CONCLUSION .................................................................................... 43
CHAPITRE 3 : TQ : RECHERCHE DE TRAJECTOIRES PROCHES 3.1 INTRODUCTION .............................................................................................................. 53 3.2 RECHERCHE DE VOISINAGES PROCHES .................................................................. 55
3.2.1 Modélisation des trajectoires futures des véhicules ............................................ 57 3.2.2 Calcul de la similarité spatio-temporelle ............................................................. 59 3.2.3 Synchronisation des trajectoires par interpolation linéaire.................................. 63 3.2.4 Calcul de la distance entre deux trajectoires ....................................................... 65 3.2.5 Calcul de l’intervalle de connectivité – CI .......................................................... 71
3.3 CONCLUSION .................................................................................................................. 72
CHAPITRE 4 : DG-CastoR : UN PROTOCOLE DE ROUTAGE GÉO-MULTIPOINT HYBRIDE 4.1 INTRODUCTION .............................................................................................................. 75 4.2 FONCTIONNEMENT GLOBAL DU PROTOCOLE GÉO-MULTIPOINT : DG-CastoR 79 4.3 MÉCANISMES DE CONSTRUCTION DE COLONIES ET DE DISSÉMINATION DE REQUÊTES ................................................................................................................................. 83
4.3.1 Échange périodique de paquets d’information .................................................... 83 4.3.2 Mécanisme d’adhésion à la colonie ..................................................................... 88 4.3.3 Routage de requête dans la colonie ..................................................................... 90
4.4 TOPOLOGIE ÉTOILE DE LA COLONIE ....................................................................... 91 4.4.1 Gestion des colonies dans le réseau overlay ........................................................ 92 4.4.2 États des liens dans le réseau overlay .................................................................. 94
4.5 CONCLUSION .................................................................................................................. 97
CHAPITRE 5 : CoFFee : APPLICATION DE GESTION DE DONNÉES 5.1 INTRODUCTION ............................................................................................................ 103 5.2 PARTIONNEMENT DES DONNÉES MULTIMÉDIAS ............................................... 106 5.3 GESTION DE LA DISTRIBUTION DES DONNÉES ................................................... 108
5.3.1 Catégorisation des nœuds dans une colonie ...................................................... 108 5.3.2 Estimation de la durée de transmission (ETD) .................................................. 109 5.3.3 ALGORITHMES D’AMÉLIORATION DE PARTAGE DE DONNÉES ....... 110
Cette procédure peut être intégrée dans la fonction Libre. ........................................................ 116 5.4 AMÉLIORATION DE L’OCCUPATION DE LA BANDE PASSANTE ...................... 116 5.5 CONCLUSION ET DISCUSSION .................................................................................. 119
CHAPITRE 6 : EXPÉRIMENTATIONS ET RÉSULTATS 6.1 INTRODUCTION ............................................................................................................ 121 6.2 Évaluation de la méthode Trajectory Query (TQ) ........................................................... 122
6.2.1 Analyse du pourcentage de voisinages proche retourné .................................... 123 6.2.2 Analyse des durées de connectivité calculées ................................................... 125
6.3 ÉVALUATION DU PROTOCOLE DG-CastoR et CoFFee ........................................... 126 6.3.1 Configuration de l’environnement et les paramètres d’entrées ......................... 126 6.3.2 Mesure du pourcentage de transfert complet du fichier par rapport à la taille du
fichier 128 6.3.3 Mesure du pourcentage de transfert complet du fichier avec CoFFee : variation
de nombre de nœuds libres (Blank) ................................................................................... 131 6.4 DISCUSSION .................................................................................................................. 132 CHAPITRE 7 : CONCLUSION ET PERSPECTIVES 7.1 CONCLUSION ................................................................................................................ 135 7.2 PERSPECTIVES .............................................................................................................. 136
ANNEXE Annexe A ................................................................................................................................... 141 LE STANDARD IEEE802.11 MAC : Aperçu général ............................................................. 141 Trace de mobilité en formt GPX ............................................................................................... 143
TABLE DES FIGURES Page
Figure 1: Communication Véhicule-à-Infrastructure (VàI) .................................................................. 3 Figure 2 : Communication Véhicule-à-Véhicule (VàV) ....................................................................... 3 Figure 3 : Communication multi-sauts inter-véhicules ......................................................................... 5 Figure 4 : Trajectoires des véhicules dans une ville ............................................................................. 7 Figure 5 : Chemin de routage multi-sauts entre deux nœuds distants ................................................ 16 Figure 6 : Catégorisation des protocoles de routage ........................................................................... 17 Figure 7 : Mécanisme d'adhésion au groupe multicast dans MAODV ............................................... 20 Figure 8 : Mécanisme de transmission dans le protocole LAR géographique .................................... 24 Figure 9: Zone de retransmission BOX .............................................................................................. 25 Figure 10 : Zone de retransmission E-BOX ....................................................................................... 25 Figure 11 : Différentes méthodes de retransmission dans le protocole GAMER géographique ........ 26 Figure 12 : Mécanisme de retransmission dans le protocole hiérarchique GeoGRID ........................ 27 Figure 13 : Mécanisme de découverte des chemins de routage (DSR) .............................................. 33 Figure 14 : Retransmission du paquet dans le protocole GPSR ......................................................... 34 Figure 15 : Hiérarchisation dans le protocole de routage HSR........................................................... 36 Figure 16 : Mécanisme de routage dans le protocole VADD ............................................................. 39 Figure 17 : Tracé d’une trajectoire à précisions différentes ............................................................... 58 Figure 18 : La timeline d'une trajectoire ............................................................................................. 59 Figure 19 : Sous-Intervalle commun [SI-, SI+] des trajectoires Tq et Tp .............................................. 60 Figure 20 : Connectivité des trajectoires (distance Euclidienne) ........................................................ 62 Figure 21 : Interpolation linéaire des positionnements de la trajectoire Tp ........................................ 64 Figure 22 : Calcul de la distance entre deux segments (de trajectoires) ............................................. 65 Figure 23 : Distance Euclidienne des segments [AB] et [CD] ........................................................... 67 Figure 24 : Triangle (ACD') avec M variant sur [CD'] ....................................................................... 68 Figure 25 : Cas où C appartient au segment [D'H] et D’ appartient à [HC]. ...................................... 70
Figure 26: Cas des points A, C et D' alignés ...................................................................................... 70 Figure 27 : Chemin de routage construit pour la dissémination et le transfert des données ............... 76 Figure 28 : Représentation du lien logique et les liens physiques équivalents ................................... 78 Figure 29 : Fonctionnement global du protocole DG-CastoR ............................................................ 80 Figure 30 : Topologie étoile de la colonie de "S" ............................................................................... 82 Figure 31 : Topologie étoile de la colonie .......................................................................................... 93 Figure 32 : Communication unicast directe dans les colonies ............................................................ 95 Figure 33: Topologie étoile de la colonie ......................................................................................... 105 Figure 34 : Partitionnement hiérarchique du fichier F ...................................................................... 107 Figure 35 : Carte routière et rayon de transmission radio ................................................................. 123 Figure 36: Pourcentage de voisinages proches TQ retournés ........................................................... 124 Figure 37 : Variation de la durée de connectivité ............................................................................. 126 Figure 38 : Pourcentage du transfert complet des données ............................................................... 129 Figure 39 : Pourcentage de transfert des fragments pour un parcours de 10 min ............................. 130 Figure 40 : Pourcentage de transfert des fragments pour un parcours de 20 min ............................. 131 Figure 41 : Pourcentage de transfert des fragments pour un parcours de 10 min ............................. 131 Figure 42 : Pourcentage de transfert en fonction de nombre de nœuds libres dans l'overlay ........... 132
-1-
CHAPITRE 1
INTRODUCTION ET MOTIVATION
1.1 INTRODUCTION
Les réseaux ad hoc mobiles (MANET) sont des réseaux sans infrastructure fixe, composés
d’entités mobiles, appelées aussi nœuds. Ces nœuds communiquent entre eux directement sans
l’intervention de points d’accès stationnaires. Dans les années 2000, les réseaux ad hoc mobiles
ont été déployés en particulier dans des environnements fortement dynamiques tels que les
réseaux inter-véhicules (VANETs - Vehicular Ad hoc Networks).
Les premières applications conçues pour les VANETs ont concerné la sécurité routière
(systèmes de transports intelligents (STI)). L’objectif majeur de ces applications est de fournir
aux véhicules présents dans le réseau, des informations utiles concernant l’état de la circulation
routière (info trafic). FleetNet (2001) [1] a été le premier projet STI pour les VANETs. Plus
tard,d’autres projets ont également été conçus comme CarTALK 2000 [2], PReVENT [3],
NOW (Network on Wheels) [4, 5], etc. Actuellement, les réseaux VANETs attirent l’attention
de grands constructeurs d’automobiles comme Volvo, BMW, Renault, Mercedes-Benz et
beaucoup d’autres. Dans ce contexte, le consortium Car2Car (C2C) [6], réunissant la plupart des
Introduction et Motivation
-2-
constructeurs d’automobiles européens, travaille pour définir et promouvoir des standards pour
les technologies sans fil de véhicules.
Aux États-Unis, la Commission Fédérale des Communications (FCC) a alloué en 1999 un
spectre de 75 Mhz entre les fréquences 5.850 Ghz et 5.925 Ghz [7]. Ce spectre est divisé en 7
canaux de 10 Mhz chacun, dont un canal appelé canal de contrôle (Control Channel – CCH)
réservé spécialement pour les Systèmes de Transports Intelligents (STI). Les 6 canaux restants
sont utilisés pour d’autres types d’applications (exemple : les applications multimédias). Ces
canaux sont appelés canaux de services (Service Channels – SCH).
Le standard WAVE (Wireless Access in Vehicular Environment) décrit l’ensemble des
standards IEEE 1609.x (.1/.2/.3/.4) déployés au niveau de la couche MAC (niveau 2) et de la
couche réseau (niveau 3) du modèle OSI. Au niveau de la couche physique (niveau 1), c’est le
standard IEEE 802.11p qui est utilisé. L’ensemble de WAVE et IEEE 802.11p, forme le
standard DSRC (Dedicated Short Range Communication) [8].
DSRC est actuellement considéré comme le standard le plus approprié pour les communications
sans fil dans les réseaux ad hoc de véhicules. Grâce au standard DSRC, il est possible d’établir
une communication véhicule-à-véhicule (VàV) ainsi qu’une communication véhicule-à-
infrastructure (VàI). Le standard DSRC est compatible avec les contraintes des réseaux de
véhicules fortement dynamiques. En effet, il offre une fiabilité de communication ainsi qu’une
faible latence lors de l’établissement de la communication. Les caractéristiques de DSRC sont :
(i) il supporte une vitesse des véhicules dépassant 200km/h, (ii) il offre une portée radio variant
entre 300 et 1000 mètres, (iii) il garantit un temps de latence pour l’établissement de la
communication ne dépassant pas 50 ms, enfin, (iv) il permet un débit théorique (bande passante)
atteignant 6 Mbps.
Le standard DSRC utilise deux catégories d’entités pour les communications VàV et VàI : RSU
(Road Side Units) et OBU (On Board Units). Les RSUs sont des points d’accès stationnaires
placés dans le réseau routier. Ils jouent le rôle de nœuds intermédiaires pour interconnecter les
Introduction et Motivation
-3-
véhicules. En revanche, les OBUs sont les véhicules mobiles dans le réseau routier. Un réseau
VANET est généralement composé d’un ensemble d’OBUs et de RSUs (Figure 1).
Figure 1: Communication Véhicule-à-Infrastructure (VàI)
Néanmoins, il est également possible d’établir une communication véhicule-à-véhicule
uniquement via des OBUs, sans avoir recours à des bornes stationnaires RSU (Figure 2).
Figure 2 : Communication Véhicule-à-Véhicule (VàV)
La communication inter-véhicules s’effectue grâce à la connectivité radio inter-véhicules. Le
rayon de transmission radio est déterminé selon le standard de communication sans fil utilisé.
Plusieurs terminologies peuvent être utilisées pour désigner un rayon de couverture radio. Dans
cette thèse, les termes « zone de transmission », « rayon de transmission » et « portée radio »
sont les plus souvent utilisés. Une communication inter-véhicules est dite directe (ou à un-saut)
lorsque les deux nœuds, source et destinataire, sont à portée radio l’un de l’autre.Deux nœuds
Introduction et Motivation
-4-
sont dits distants lorsqu’ils ne sont pas à portée radio l’un de l’autre. Ces nœuds peuvent
cependant communiquer par une communication dite multi-sauts. Ainsi, une communication
multi-sauts est assurée par un ensemble de nœuds intermédiaires participant à la construction
d’un chemin de communication (ou chemin de routage) reliant les deux nœuds en question.
Dans cette thèse, nous nous intéressons en particulier à l’étude des applications d’échange de
données volumineuses (exemple : applications multimédias) dans les VANETs. Contrairement
aux systèmes de transport intelligents (STI) qui sont en phase d’industrialisation, les
applications multimédias sont encore en cours d’étude [9, 10, 11, 12]. L’objectif de ces deux
types d’application est différent. Le principal objectif des systèmes de transport intelligents est
de prévenir les véhicules des accidents routiers ou de fournir aux véhicules présents dans le
réseau, des informations concernant l’état de la circulation. La transmission des données dans ce
type d’application s’effectue par une propagation du message vers une région bien définie,
appelée aussi région cible (exemple : région d’un accident sur une autoroute). Les paquets sont
généralement textuels, de petite taille et ne nécessitent donc pas une bande passante large pour
assurer une transmission bout-à-bout réussie. Enfin, les messages sont envoyés de manière
proactive, sans demande explicite du destinataire (envoi dit « push »), ce qui explique
qu’aucune réponse ne soit attendue en retour.
En revanche, les applications d’échange de données volumineuses sont généralement
composées de deux phases de transactions (requête/réponses). La dissémination de la requête
dans le réseau est ainsi suivie d’une phase de transfert des données recherchées. De plus, ces
applications nécessitent de garantir une qualité de service (QoS). En pratique, la qualité de
service des applications d’échange de données déployées dans des environnements fortement
dynamiques, doit être assurée au niveau de deux couches : la couche réseau et la couche
application. Les conditions pour garantir une QoS au niveau de la couche réseau sont :
l’acheminement bout-à-bout réussi des paquets, la réduction de la perte des paquets, ainsi que la
réduction des délais de transmission. En revanche, la QoS au niveau applicatif concerne la
gestion des données ainsi que l’usage approprié de la bande passante partagée. Ces conditions
Introduction et Motivation
-5-
deviennent particulièrement problématiques dans les réseaux ad hoc de véhicules fortement
dynamiques. Les contraintes importantes à considérer dans les réseaux VANETs sont :
• La forte mobilité des véhicules dans le réseau : Dans l’exemple de la Figure 3, le
nœud « S » est la source et le nœud « D » est le destinataire. Le chemin multi-sauts
reliant les nœuds distants « S » et « D » est construit par les nœuds intermédiaires « A »
et « B ». Un tel chemin de routage doit être maintenu jusqu’à l’achèvement du transfert
bout-à-bout des paquets. Les données à transmettre sur le chemin de routage étant
lourdes (exemple : données multimédias de grande taille), ce transfert nécessite une
durée de communication relativement importante. Or, en raison de la forte mobilité des
véhicules, le maintien du chemin de routage peut nécessiter des reconfigurations
fréquentes (remplacement ou ajout des nœuds intermédiaires) ; ces reconfigurations
rendent la procédure de maintien très complexe.
Figure 3 : Communication multi-sauts inter-véhicules
Introduction et Motivation
-6-
• Le partage de la bande passante : la capacité de la bande passante attribuée aux
véhicules s’affaiblit lors de surcharges. D’une part, une surcharge du réseau peut être due à
une trop forte densité des véhicules dans le réseau (nombre de communications simultanées
très grand). D’autre part, une surcharge peut être la conséquence d’un usage non approprié
de la bande passante (transmission de données redondantes, pertes de paquets, etc.)
Dans ce contexte, pour mieux présenter les problématiques que nous souhaitons étudier dans
cette thèse, nous présentons dans ce qui suit, deux cas d’utilisation concernant des applications
multimédias pour les VANETs.
1.2 EXEMPLES DE CAS D’UTILISATION
• Système de partage de données multimédias :
Jean conduit son véhicule en ville pour aller à son bureau ; il reçoit sur son téléphone (PDA) un
message d’un ami l’invitant à assister au concert d’un artiste. Intéressé, il souhaite télécharger
via une communication pair-à-pair une des chansons de cet artiste. Malheureusement, il réalise
qu’il est en dehors de la zone de couverture d’une connexion 3G. Il établit alors une connexion
ad hoc avec d’autres véhicules qui sont dans son voisinage.
Jean génère sa demande sous forme d’une requête textuelle1. La requête est propagée vers tous
les véhicules du réseau VANET. Ce scénario est représenté dans la Figure 4. Nous représentons
les trajectoires des 6 véhicules dans le réseau, V1 représentant le véhicule de Jean. Nous
1 Les questions d’interface utilisateur ne sont pas abordées dans cette thèse.
Introduction et Motivation
-7-
supposons que tous les véhicules sont équipés d’un système de navigation qui peut également
fournir une estimation des trajectoires futures des véhicules. Une méthode classique est de
propager la requête de manière « broadcast » (diffusion globale) vers tous les véhicules, c’est-à-
dire vers les véhicules V2, V3, V4, V5 et V6.
Figure 4 : Trajectoires des véhicules dans une ville
Considérons que les véhicules V3 et V4 possèdent la (ou les) réponse(s) à la requête de Jean. Un
mécanisme de transfert de données est nécessaire pour que le téléphone de Jean (V1) puisse
récupérer les données des véhicules V3 et V4. Le véhicule V4 selon sa trajectoire future prévue,
s’éloigne du véhicule V1. Après une certaine durée, les véhicules V1 et V4 ne seront donc plus à
Introduction et Motivation
-8-
portée radio l’un de l’autre. Pour que le véhicule V4 puisse transmettre les données au véhicule
V1, un chemin de routage est donc nécessaire.
Les questions qui se posent sont : comment choisir les véhicules intermédiaires adéquats pour
construire un chemin de routage fiable entre le véhicule V1 et le véhicule V4 ? Dans un réseau
fortement dynamique, quel mécanisme faut-il adopter pour maintenir un chemin de
communication fiable tout au long du transfert de données sans avoir recours à des
reconfigurations fréquentes du chemin de routage ?
• Applications interactives temps-réel (multi-joueurs) :
Considérons maintenant que Jean part en vacances de Lyon à Nice en voiture avec sa famille.
C’est une période de départ en vacances, la densité de la circulation est forte, ce qui provoque
un embouteillage sur l’autoroute. Son fils, Patrick, s’ennuie ; il souhaite lancer une requête dans
le réseau ad hoc vers des véhicules au voisinage de la voiture de son père, pour chercher des
passagers dans d’autres véhicules qui souhaiteraient jouer à un jeu. Sa demande est diffusée
vers tous les véhicules afin que les utilisateurs intéressés se connectent à l’interface du jeu.
De la même manière que pour l’application de partage de données multimédias, l’application
multi-joueurs nécessite une connectivité stable. De plus, une contrainte supplémentaire
s’impose dans ce type d’application : l’interactivité et la synchronisation des interfaces. Ces
applications sont de type continu et l’état de l’application change en temps réel, ce qui nécessite
une mise à jour continue et un échange fiable d’informations en temps réel sur la bande
passante. Ainsi, une large capacité de la bande passante est nécessaire pour diminuer les délais
de transmission et assurer par la suite la synchronisation des interfaces.
Il est indispensable lors de la mise en œuvre d’une application de transfert de données
volumineuses d’assurer une connectivité stable, afin de garantir une transmission fiable des
données tout en réduisant les délais et la surcharge de la bande passante. Cette qualité de service
(QoS) impose de travailler au niveau de la couche réseau (niveau 3) et de la couche application
(niveau 7).
Introduction et Motivation
-9-
1.3 PROBLÉMATIQUE ET PRINCIPALES CONTRIBUTIONS
1.3.1 Problématique
Dans cette thèse, nous étudions la communication inter-véhicules dans les applications de
partage de données volumineuses (exemple : applications multimédias). En premier lieu, notre
étude se concentre sur les problèmes liés à la fiabilité des chemins de transfert de données
(routage des paquets au niveau de la couche réseau). Nous nous intéressons également à la
gestion des données à transmettre dans le réseau. Un mécanisme de gestion de données au
niveau de la couche application est en effet nécessaire pour garantir une amélioration de
l’utilisation de la bande passante. L’ensemble de ces deux études vise à garantir une qualité de
service au niveau de la couche réseau aussi bien qu’au niveau de la couche application. Les
principales contributions de cette thèse sont brièvement présentées ci-dessous.
1.3.2 DG-CastoR : Protocole de routage géo-multipoint hybride
Un nouveau protocole de routage géo-multipoint hybride, appelé DG-CastoR (Direction-based
GeoCast Routing) est proposé dans cette thèse. Le protocole DG-CastoR offre une double
fonctionnalité. Pour chaque requête disséminée dans le réseau, le protocole DG-CastoR
construit de manière implicite un réseau overlay, appelé colonie. Par définition, il s’agit d’un
recouvrement virtuel partiel de la topologie physique du réseau. D’autre part, DG-CastoR
propose un mécanisme de dissémination géo-multipoint de la requête dans la colonie construite.
• Construction de la colonie : Dans les réseaux ad hoc fortement dynamiques, la
communication inter-véhicules est difficile à maintenir. Les véhicules sont des entités
mobiles, caractérisées chacun par leur vitesse et leur direction dans le réseau routier.
Face à ce défi, DG-CastoR propose de construire un overlay implicite (colonie)
Introduction et Motivation
-10-
comportant des nœuds capables d’assurer une communication fiable avec le nœud
source de la requête. La topologie de la colonie est en étoile centrée sur le nœud source.
Pour la construction de la colonie, nous proposons de mettre en œuvre une méthode de
recherche de voisinages proches, appelée TQ (Trajectory Queries). La méthode TQ,
grâce aux mesures de similarité spatio-temporelle, sélectionne parmi un ensemble de
nœuds, ceux capables de rencontrer le nœud source et d’assurer une connectivité
compatible avec les contraintes de l’application.
• Dissémination de la requête dans la colonie : Ce mécanisme assure la propagation de
la requête uniquement aux nœuds appartenant à la colonie virtuelle construite.
L’avantage de ce mécanisme est qu’il évite la propagation épidémique de la requête
dans un environnement fortement dynamique comme un VANET.
1.3.3 CoFFee : Une application de gestion de données dans les
VANETs La deuxième principale contribution est un travail réalisé en collaboration avec Zeina
Torbey, doctorante au LIRIS membre de notre équipe (DRIM). CoFFee - Cooperative and
inFrastructure-Free peer-to-peer network fonctionne au niveau de la couche application.
CoFFee offre des services de gestion de données conçus spécialement pour : (i) faciliter le
transfert de données de grande taille, (ii) augmenter la disponibilité des données dans le réseau,
ainsi que (iii) améliorer l’usage de la bande passante. Nous proposons principalement deux
types de services de gestion de données : un service de suppression de données (pruning) et un
service de réplication réactive (réplication). Le service de suppression sert à éliminer du flux de
données à transmettre, les données fréquentes dans le réseau (données facilement trouvées ou
redondantes). À l’inverse du service de suppression, le service de réplication réactive sert à
répliquer à la demande les données rares (données peu présentes dans le réseau).
Introduction et Motivation
-11-
1.4 ORGANISATION DU MANUSCRIT
Avant d’exposer ces différentes contributions, nous présentons, dans le chapitre 2, une étude
synthétique des protocoles de routage appliqués dans les réseaux ad hoc mobiles et notamment
les réseaux ad hoc de véhicules. Dans ce contexte, nous classifions les protocoles en deux
principales catégories : les protocoles multipoints et géographiques, adaptés à la dissémination
de requêtes et les protocoles unicast adaptés au transfert de données entre deux nœuds source et
destinataire.
Les contributions sont divisées en deux parties : la première partie comporte les étapes de la
construction de la colonie et de dissémination de requêtes. Le chapitre 3 présente la méthode TQ
de recherche de voisinages proches. Dans ce chapitre, nous présentons les différentes étapes
nécessaires pour mesurer la similarité spatio-temporelle des trajectoires et calculer la durée de
connectivité.
Le protocole de routage géo-multipoint DG-CastoR est détaillé dans le chapitre 4. Dans ce
chapitre, nous décrivons les différentes étapes de construction de la colonie ainsi que le
mécanisme de dissémination de la requête vers les nœuds appartenant à la colonie construite.
La deuxième partie des contributions, l’application de gestion de données CoFFee est présentée
dans le chapitre 5.
Dans le chapitre 6, nous présentons deux séries d’expérimentations que nous avons conduites
pour valider nos contributions. En premier lieu, nous analysons la performance de la méthode
TQ en termes de précision du calcul de la similarité spatio-temporelle ainsi que de nombre de
voisinages proches retournés d’après les mesures de similarité. Ces résultats sont ensuite utilisés
dans une seconde série d’expérimentations de validation du protocole DG-CastoR. Enfin, la
performance du protocole DG-CastoR est mesurée en intégrant l’application de gestion de
données CoFFee.
Introduction et Motivation
-12-
Finalement, nous concluons ce rapport dans le chapitre 7 et comme perspectives, nous
proposons un certain nombre d’améliorations du protocole DG-CastoR et de l’application
CoFFee.
-15-
CHAPITRE 2
LES PROTOCOLES DE ROUTAGE
DES RÉSEAUX AD HOC
UN ÉTAT DE L’ART
2.1 INTRODUCTION
Un VANET (Vehicular Ad hoc Network) est un réseau sans infrastructure fixe, constitué
d’un ensemble de véhicules dénommés nœuds mobiles. Ces nœuds établissent entre eux une
communication dite à un-saut lorsqu’ils sont à portée radio l’un de l’autre. Une communication
dite multi-sauts peut également être établie entre deux nœuds distants (nœuds n’étant pas dans
une même zone de transmission (Figure5)). Une communication multi-sauts est réalisable grâce
à la mise en place d’un chemin de routage reliant le nœud source au nœud destinataire et
impliquant un ou des nœuds intermédiaires, dits aussi nœuds relais.
État de l’art
-16-
Les chemins de routage multi-sauts peuvent être construits par des protocoles de routage de
types variés, qui permettent d’assurer la transmission des paquets vers un (ou des) nœud(s)
destinataire(s).
Dans l’exemple de la Figure 5, un chemin de communication multi-sauts est établi entre le
nœud source ‘A’ et le nœud destination ‘C’, qui sont des nœuds distants. Cette communication
est établie par l’intermédiaire du nœud relais ‘B’ ; celui-ci étant à portée radio à la fois du nœud
‘A’ et du nœud ‘C’.
Figure 5 : Chemin de routage multi-sauts entre deux nœuds distants
Dans ce chapitre, notre analyse se focalise sur les protocoles de routage les plus adaptés aux
applications de transfert de données volumineuses pour les réseaux ad hoc de véhicules. Dans ce
contexte, nous proposons une classification de ces protocoles en deux grandes catégories :
• Les protocoles de routage multipoints et géographiques (1ère catégorie). Ces protocoles
peuvent être mis en œuvre dans la phase de la dissémination de requêtes.
• Les protocoles de routage unicast pour le transfert de données volumineuses (2ème
catégorie). Dans le même contexte, des protocoles unicast sensibles à la qualité de
service sont également étudiés. Ces protocoles, outre la transmission unicast des
État de l’art
-17-
paquets, prennent en considération la qualité de service (délais de transmission, usage de
la bande passante, etc.), nécessaire pour les applications multimédias.
La Figure 6 montre les différentes catégories et les sous-catégories des protocoles de routage.
Figure 6 : Catégorisation des protocoles de routage
En raison du grand nombre de protocoles proposés dans la littérature, nous présentons par la
suite, une étude comparative synthétique, tout en soulignant les avantages et les limitations de
chaque type de protocole.
2.2 DISSÉMINATION DE REQUÊTES : PROTOCOLES DE
ROUTAGE MULTIPOINTS ET GÉOGRAPHIQUES
2.2.1 Protocoles de routage multipoints
Les protocoles de routage multipoints peuvent être eux-mêmes structurés en deux sous-
catégories (Figure 6). La première sous-catégorie concerne les protocoles multipoints de niveau
État de l’art
-18-
IP (détaillés dans la section 2.2.1.1), déployés au niveau de la couche réseau. L’objectif des
protocoles multipoints IP est de transmettre une seule copie d’un paquet vers un ensemble de
récepteurs appartenant au groupe multipoint. Ces protocoles ont connu un succès important dans
les applications multi-utilisateurs (vidéoconférence, télé-enseignement, etc.), où l’objectif
principal est de diffuser la même information, en temps réel, à un ensemble d’utilisateurs. La
deuxième sous-catégorie de protocoles multipoints (détaillée dans la section 2.2.1.2), est
déployée au niveau de la couche application du modèle OSI. Ces derniers sont appelés
protocoles multipoints applicatifs (ou overlay). Par définition, un réseau overlay est un
recouvrement virtuel de la topologie physique, où les nœuds sont interconnectés entre eux par
des liens logiques. Le mécanisme de routage dans les réseaux overlays s’effectue alors au
niveau de la couche application, grâce aux protocoles de routage multipoint overlays.
Dans ce qui suit, nous détaillons tout d’abord les protocoles multipoint niveau IP et applicatif.
2.2.1.1 Protocoles de routage multipoints niveau IP
Le routage multipoint IP consiste à envoyer une seule copie du paquet vers un ensemble de
nœuds appartenant au même groupe multipoint. Par définition, un groupe multipoint est
représenté sous la forme d’un arbre de transmission, tel que les nœuds appartenant à cet arbre
sont connectés entre eux par des liens physiques (niveau réseau). L’arbre de transmission peut
comporter un seul nœud source, lorsque l’objectif est de transmettre le paquet depuis un seul
nœud émetteur vers plusieurs destinataires (one-to-many). Toutefois, il est possible également
que l’arbre de transmission comporte plusieurs nœuds sources émetteurs de paquets vers
plusieurs nœuds destinataires (many-to-many).
État de l’art
-19-
L’arbre de transmission des protocoles multipoints IP, comporte outre le (ou les) nœud(s)
source(s), des nœuds membres du groupe multipoint ainsi que des nœuds membres de l’arbre de
transmission (dits aussi nœuds routeurs). Les nœuds routeurs servent uniquement à router les
paquets vers les nœuds du groupe multipoint, ils ne sont donc pas des entités du groupe
multipoint ; leur importance apparaît principalement lorsque le nœud source et les nœuds du
groupe multipoint sont distants au niveau des liens physiques. Il s’agit alors d’une
communication multi-sauts, établie entre le nœud source et les nœuds du groupe multipoint,
par l’intermédiaire des nœuds routeurs. La construction de l’arbre de transmission peut se faire
selon deux topologies différentes, la topologie arborescente (Tree-based) et la topologie maillée
(Mesh-based) [13, 14, 15, 16, 17]. Cependant, pour établir une communication à l’intérieur de
l’arbre de transmission, une phase de découverte des chemins de routage est nécessaire. La
découverte des chemins de routage à l’intérieur de l’arbre de transmission, se fait en mode
réactif ou en mode proactif. Le mode réactif consiste à découvrir les chemins de routage en
temps réel, lorsqu’un nœud en fait la demande. En revanche, le protocole multipoint proactif
évite la phase de découverte des chemins, car les chemins sont établis au préalable ; chaque
nœud maintient alors une table de routage contenant les chemins reliant les nœuds sources à
tous les nœuds destinataires.
Après avoir présenté le principe général de fonctionnement des protocoles multipoints niveau
IP, dans ce qui suit, nous détaillons les principaux exemples de ce type de protocole. Ainsi, nous
analysons leurs avantages et leurs limitations par rapport aux environnements VANET et aux
objectifs visés dans cette thèse.
MAODV – Multicast On-Demand Distance Vector Protocol [13] est un exemple de protocole
de routage multipoint IP réactif basé sur une topologie arborescente. L’adhésion au groupe
multipoint dans ce protocole se fait de la manière suivante : un nœud du réseau (exemple le
nœud 5 dans la Figure 7) diffuse une demande de découverte de routes, appelée Route Request
(RREQ). Le récepteur de ce message s’il appartient au groupe multipoint déjà existant, répond
au message sinon il retransmet le message vers d’autres nœuds dans le réseau (exemple : nœuds
1 et 2). Pour répondre à la demande, un message de réponse appelé Route Response (RREP) est
État de l’art
-20-
envoyé vers le nœud qui souhaite adhérer au groupe multipoint. En effet, pour conserver la
connectivité entre les nœuds formant l’arbre de transmission, chaque nœud maintient les
chemins de transmission dans sa table de routage multipoint (Multicast Route Table). Le
premier nœud du groupe multipoint devient le leader du groupe, responsable de mettre à jour
l’état des liens dans l’arbre. Le maintien de l’arbre de transmission s’effectue par des messages
de contrôles diffusés périodiquement dans le réseau ; ce maintien périodique est désigné sous le
terme mise-à-jour Soft dans la littérature [13].
Figure 7 : Mécanisme d'adhésion au groupe multicast dans MAODV
Le routage dans les protocoles multipoints IP réactifs ODMRP [14] et FGMP [15] s’effectue
dans un arbre de transmission à topologie maillée. L’avantage majeur d’une topologie maillée
réside dans la multiplicité des chemins de routage. Plusieurs chemins sont possibles pour relier
un nœud source à un nœud destinataire. Ainsi, si une panne intervient au niveau du chemin
choisi, un chemin alternatif est directement sélectionné pour réparer la panne et continuer la
retransmission du paquet vers la destination. En outre, il n’est pas indispensable d’appliquer un
maintien périodique de l’arbre de transmission ; une réparation du lien s’effectue quand le nœud
détecte une disjonction au niveau de l’arbre de transmission. Une disjonction peut notamment se
État de l’art
-21-
produire lorsqu’un nœud du groupe multipoint quitte le réseau ad hoc. Ce type de maintien des
chemins de routage est reconnu par mise-à-jour Hard.
En conclusion, les arbres de transmission construits dans les protocoles multipoints IP sont
constitués d’un ensemble de nœuds connectés au niveau de la couche réseau (par des liens
physiques). Pour conserver la fiabilité des chemins de routage dans l’arbre de transmission, ces
protocoles proposent des mécanismes de mise-à-jour. Cependant, lorsque l’environnement
étudié est fortement dynamique tel que les VANETs, le réseau physique subit des
partitionnements et des changements fréquents de la topologie, ce qui engendre des opérations
de maintien et de reconfiguration très fréquentes des chemins de routage. Les mises-à-jour
augmentent le coût de gestion du réseau (overhead) et affaiblissent par la suite la performance
du protocole.
2.2.1.2 Protocoles de routage multipoints applicatifs (overlays)
Les protocoles de routage overlays multipoints fonctionnent au niveau applicatif [16, 17]. Le
mécanisme de routage s’effectue au sein d’un groupe multipoint comportant des nœuds
connectés logiquement entre eux. Chaque lien logique de la topologie virtuelle correspond à un
chemin unicast physique au niveau de la couche réseau ; cela explique que lors du routage, le
chemin de communication physique sous-jacent équivalent au chemin logique est utilisé.
Cependant, la performance du protocole multipoint s’affaiblit et l’overhead au niveau de la
couche réseau augmente lorsque les liens logiques ne correspondent pas aux liens physiques. En
effet, le routage multipoint risque de provoquer des transmissions multiples du même paquet sur
un lien physique, des pertes de paquets sur des chemins de routage discontinus, une complexité
de reconfiguration des chemins de routage alternatifs, etc. Les travaux récents pour la
construction d’overlays multipoints ont démontré l’importance d’exploiter les informations
provenant de la couche réseau.
État de l’art
-22-
Le protocole multipoint PAST-DM [16] se base sur une topologie arborescente. Au moment de
la construction du groupe multipoint, l’état des liens physiques sous-jacents est pris en
considération. Pour conserver la pertinence des chemins de routage, un mécanisme de mise-à-
jour est proposé. Ce mécanisme permet d’adapter la topologie virtuelle à l’état physique des
liens. ALMA [17] est un protocole similaire au protocole PAST-DM. Lorsqu’un nœud souhaite
adhérer à un groupe multipoint existant, il cherche dans son voisinage les nœuds appartenant à
ce groupe ; il envoie alors un message d’adhésion et devient un nœud descendant dans l’arbre
de transmission. Le maintien de l’arbre de transmission se fait par la diffusion périodique de
messages de contrôle entre les nœuds descendants et leurs ascendants directs. De plus, pour
conserver la cohérence entre les liens physiques et logiques, chaque nœud analyse la qualité du
lien physique le reliant à son nœud ascendant. Le RTT (Round-Trip-Time) du chemin physique
est calculé ; lorsque la valeur de RTT dépasse un certain seuil, le nœud descendant cherche un
nœud meilleur (avec un RTT plus petit) pour établir une liaison.
Les protocoles multipoints mentionnés dans la littérature sont difficiles à adapter aux réseaux ad
hoc fortement dynamiques. La raison essentielle est la forte mobilité des véhicules qui engendre
un changement très fréquent de la topologie physique du réseau. Or, les coûts de maintenance et
de reconfiguration sont élevés. Ainsi, à l’instar des protocoles multipoints niveau IP, les
protocoles overlays multipoints mentionnés dans la littérature ne sont pas envisageables pour les
réseaux VANETs.
2.2.2 Protocoles de routage géographiques
Les protocoles de routage géographiques sont les plus adaptés pour les réseaux ad hoc de
véhicules, puisque le mécanisme de routage se base sur les données géographiques des nœuds.
Dans ces protocoles, la destination est représentée par une région déterminée, appelée aussi
région cible. Tout nœud, à l’intérieur de la région cible, reçoit le paquet lors de sa diffusion dans
État de l’art
-23-
celle-ci. Les protocoles de routage géographiques comportent deux étapes : la première étape
consiste à retransmettre le paquet sur un chemin de routage construit à l’intérieur d’une zone
déterminée, appelée zone de retransmission (Forwarding Zone). La deuxième étape consiste à
diffuser le paquet aux nœuds à l’intérieur de la région cible (Geocast Region). La différence
majeure entre les différents protocoles mentionnés dans la littérature apparaît surtout dans le
mécanisme de retransmission des paquets. Dans ce qui suit, les principaux protocoles de routage
géographiques sont donc expliqués.
Comme dans les protocoles multipoints, la découverte de chemins dans les protocoles
géographiques peut s’effectuer en mode réactif ou en mode proactif. DREAM - Distance
Routing Effect Algorithm for Mobility [18, 19], est un exemple de protocole géographique
proactif. Chaque nœud dans le réseau maintient une table de localisation. Cette table comporte
les données géographiques des nœuds du voisinage. La table de localisation est mise à jour
grâce aux messages de contrôles diffusés périodiquement dans le réseau. Lors de la
retransmission des paquets, le nœud source consulte sa table de localisation et envoie le paquet
vers les nœuds dans la direction de la destination. À l’inverse, le protocole géographique LAR
[20] est réactif (Figure 8). La phase de transmission des paquets est précédée par un mécanisme
de découverte des chemins reliant le nœud source à la zone de diffusion. Précisons que la
diffusion des messages de découverte de chemins est limitée à une zone de retransmission
déterminée.
État de l’art
-24-
Figure 8 : Mécanisme de transmission dans le protocole LAR géographique
La différence principale entre le protocole LAR réactif et le protocole DREAM proactif apparaît
dans l’étape de retransmission des paquets. L’espace de retransmission dans LAR est réduit
comparé au protocole DREAM ; cela diminue le coût de retransmission des paquets dans le
réseau.
Le protocole géographique GRUV [21] propose une approche basée sur la retransmission
maillée dans la zone de retransmission, tout en prenant en considération également
l’infrastructure du réseau routier. Le paquet est routé sur plusieurs chemins redondants dans la
topologie maillée pour atteindre la destination. L’objectif est de router d’abord le paquet vers un
seul nœud appartenant à la région géographique cible. À partir de cette étape, le paquet est
diffusé à tous les nœuds appartenant à la même région (c’est-à-dire en broadcast). Trois
approches dynamiques de retransmission sont proposées pour construire une zone de
retransmission bien adaptée à la mobilité et la vitesse des nœuds. Ces approches sont : BOX, E-
BOX et FLOOD. La zone de retransmission BOX (illustrée dans la Figure 9), correspond au
rectangle minimum (MBR - Minimum Bounding Rectangle) qui recouvre la position du nœud
État de l’art
-25-
source ainsi que la région géographique cible. E-BOX (Figure 10) et FLOOD proposent une
extension de la zone BOX.
Figure 9: Zone de retransmission BOX
Figure 10 : Zone de retransmission E-BOX
GAMER [22] est un protocole similaire à GRUV en terme de construction adaptée de la zone de
retransmission. GAMER adopte également trois approches pour représenter la zone de
retransmission : l’approche CONE, CORRIDOR et FLOOD, illustrées dans la Figure 11.
L’approche CONE, consiste à construire un chemin en forme de cône entre le nœud source et la
région géographique cible. La construction s’effectue par la propagation de paquets
JOIN_DEMAND dans le réseau. CORRIDOR et FLOOD sont des zones plus larges que CONE.
État de l’art
-26-
Retransmission Flood
Retransmission Corridor
Retransmission Cone
Figure 11 : Différentes méthodes de retransmission dans le protocole GAMER géographique
Une autre catégorie de routage géographique met en place des protocoles géographiques
hiérarchiques. Dans ces protocoles, le réseau est décomposé en zones (ou cellules) ; chaque
zone est constituée de 3 types de nœuds : les nœuds routeurs, les nœuds dénommés clusterheads
(ou leaders) et les nœuds membres appartenant à la zone n’ayant aucun rôle spécifique. Par
définition, dans chaque cellule, un seul nœud clusterhead est élu ; les clusterheads des cellules
sont les seuls à participer au mécanisme de routage dans le réseau. En effet, la retransmission
des paquets s’effectue sur des chemins de routage construits uniquement par des nœuds
clusterheads jusqu’à atteindre la zone géographique déterminée. GeoGrid [23] est un autre
exemple de ce type de protocole ; GeoGrid est une extension du protocole GRID [24] conçu
pour les réseaux ad hoc mobiles (Figure 12). Les clusterheads (Gateways dans la terminologie
GRID) participent seuls au mécanisme de routage. Ils sont responsables de découvrir le chemin
de retransmission des paquets, de retransmettre les paquets vers les clusterheads des cellules du
voisinage et, enfin, de maintenir le chemin de routage.
État de l’art
-27-
Figure 12 : Mécanisme de retransmission dans le protocole hiérarchique GeoGRID
Certains protocoles spécifiques pour les réseaux ad hoc de véhicules, prennent en considération,
outre les données géographiques des véhicules, la carte du réseau routier. GyTAR - Greedy
Traffic Aware Routing [25] est un exemple de ce type de protocole. La structure des routes est
prise en compte dans le mécanisme de routage. Ainsi, les intersections des routes sont
considérées comme des points potentiels pour la construction et la maintien du chemin de
routage. Le protocole GyTAR est composé de deux méthodes : (1) Une méthode permettant le
choix dynamique et progressif des intersections des routes (anchor-based), (2) un mécanisme de
routage glouton amélioré pour l’envoi des paquets entre deux intersections choisies. Dans
GyTAR, l’état de la circulation routière est également pris en considération lors du mécanisme
de routage. Les routes les plus denses sont considérées optimales pour relayer le paquet dans la
direction du véhicule destinataire. Similaire au protocole GyTAR, le protocole A-STAR
(Anchor-Based Street and Traffic Aware Routing) [26] prend également en considération la
carte routière (static map) ainsi que l’état de la circulation (dynamic real-time map). Le chemin
le plus court est calculé par l’algorithme de Dijkstra. Basé sur le même principe que les
protocoles GyTAR et A-STAR, le protocole CAR (Connectivity Aware Routing) [27], route le
État de l’art
-28-
paquet en mode point-à-point vers le véhicule destinataire, par l’intermédiaire des véhicules
relais (dits anchor nodes).
Les protocoles de routage géographiques sont les mieux adaptés aux réseaux fortement
dynamiques. Certains protocoles, outre les localisations géographiques des véhicules, prennent
en considération l’infrastructure du réseau routier. Le mécanisme de routage adopté dans ces
protocoles est composé d’une étape de retransmission des paquets dans une zone de
retransmission et d’une étape de diffusion des paquets dans une région géographique
déterminée. Néanmoins, les applications de transfert de données volumineuses déployées dans
un réseau fortement dynamique nécessitent une communication fiable entre les nœuds pendant
la transmission des données. Mais, aucune zone géographique déterminée n’est nécessaire. Ceci
nous mène à conclure que les protocoles géographiques répondent seulement partiellement à la
problématique étudiée.
Dans le tableau récapitulatif ci-dessous, nous présentons les protocoles multipoints étudiés dans
ce chapitre. L’objectif est d’évaluer et de comparer leur adaptation aux environnements mobiles
fortement dynamiques. Nous pouvons remarquer que les protocoles à topologie arborescente
nécessitent des reconfigurations des chemins de routage très fréquentes. En revanche, le
maintien des chemins dans les protocoles à topologie maillée est moins fréquent, en raison de la
multiplicité des chemins reliant le nœud source aux nœuds destinataires.
En conclusion, les protocoles multipoints basés sur la topologie de la carte routière (road-based)
et les protocoles géographiques en général, sont bien adaptés aux réseaux ad hoc de véhicules,
dans la mesure où ils minimisent le nombre de reconfigurations des chemins de routage.
Table 1: Tableau Récapitulatif des protocoles multipoints et géographiques
Protocole de routage Type Topologie Reconfiguration des chemins de routage
MAODV IP multipoint Tree-based - -
ODMRP / FGMP IP multipoints Mesh-based -
État de l’art
-29-
PAST-DM Overlay multipoint Tree-based - -
ALMA Overlay multipoint Tree-based -
DREAM / LAR Géographiques Tree-based -
GRUV / GAMER Géographique Mesh-based -
GeoGrid Géographique Cell-based +
GyTAR/ A-Star/ CAR Géographiques Road-based +
- - Très fréquente - Fréquente + Rare
2.3 PROTOCOLES DE ROUTAGE UNICAST POUR LE
TRANSFERT DES DONNÉES
2.3.1 Protocoles de routage unicast
La seconde catégorie de protocoles étudiée concerne les protocoles de routage de type unicast
[28, 29, 30, 31, 32]. En effet, dans les applications de transfert de données volumineuses
(exemple : applications multimédias) pour les VANETs, le routage unicast est utilisé pour le
transfert des données (en réponse à une requête généralement transmise en multicast). L’objectif
des protocoles unicast est de transmettre des paquets depuis un nœud source vers un seul nœud
destinataire (donc à travers un seul chemin multi-sauts). Deux mécanismes de routage unicast
sont envisageables dans les réseaux ad hoc mobiles. Le premier mécanisme basique consiste à
router les paquets en mode multi-sauts à travers un chemin de routage pré-établi entre les nœuds
source et destination. Le second mécanisme est applicable dans les réseaux tolérants aux délais
(DTN2). Dans ce cas, le routage est réalisé grâce aux techniques « Carry-and-Forward » sur le
2 DTN : Delay Tolerant Network
État de l’art
-30-
chemin de routage de la manière suivante : le nœud maintient le paquet tant qu’il ne détecte pas
un nœud convenable dans son voisinage capable de retransmettre le paquet. Ce mécanisme
augmente les délais de transmission par rapport au routage multi-sauts classique. En revanche,
les risques de perte des paquets lors de la retransmission sont réduits.
Comme pour les catégories multipoints et géographiques, dans les protocoles unicast, deux
mécanismes de construction des chemins de routage sont proposés : le mode proactif et le mode
réactif. Nous détaillons et nous synthétisons dans ce qui suit les principaux protocoles de
routage réactifs et proactifs. À ces deux mécanismes s’ajoute un troisième, les protocoles de
routage hybrides, regroupant à la fois les approches réactive et proactive.
2.3.1.1 Protocoles unicast réactifs
AODV (On Demand Distance Vector) [28] est un protocole de routage réactif ; ainsi, les
chemins sont découverts et maintenus à la demande. Lorsqu’un nœud souhaite envoyer des
données à un nœud destinataire, la première étape consiste à diffuser (broadcast) à tous les
nœuds du réseau un message RREQ de découverte du chemin de routage. Un nœud, à la
réception du message (RREQ), consulte sa table de routage ; s’il détecte un chemin le reliant au
nœud destination, il ajoute son adresse dans le chemin de routage et retransmet le message
(RREQ) vers le nœud suivant. Simultanément, il envoie un message de confirmation (RREP) au
nœud source ; ce message l’informe de sa participation à la construction du chemin de
routage. Le chemin de routage est représenté comme une chaîne de nœuds reliant le nœud
source au nœud destinataire. Chaque nœud intermédiaire pointe vers le nœud suivant et
précédent par deux pointeurs appelés respectivement pointeur suivant et pointeur précédent. La
chaîne construite par les pointeurs suivants sert à transférer les paquets de la source au
destinataire. En revanche, la chaîne de retour est pointée par les pointeurs précédents pour
retourner au nœud source les réponses de confirmation ou d’acquittement de réception des
État de l’art
-31-
paquets. Le protocole AODV fonctionne d’une manière distribuée : chaque nœud intermédiaire
maintient uniquement ses pointeurs précédents et suivants, au lieu de maintenir la chaîne du
chemin entier (shared-based). La deuxième étape du protocole AODV consiste à maintenir le
chemin de routage jusqu’à la fin de la transmission. Pour le maintien du chemin, le protocole
utilise trois différents types de messages : (1) le message route time-out, diffusé lorsqu’aucune
activité n’est remarquée sur le chemin pendant un certain temps ; (2) le message Hello,
généralement diffusé sur le réseau pour détecter la présence des nœuds dans le voisinage direct.
De plus, le message Hello permet de maintenir les pointeurs précédents et suivants afin de
maintenir le chemin stable durant le transfert des paquets ; enfin, (3) le message route-error
diffusé sur le chemin lors de la détection d’une rupture de liens dans le chemin.
Un inconvénient du protocole réactif AODV apparaît lors du maintien des chemins de routage.
Chaque nœud est responsable de maintenir la paire de pointeurs précédent et suivant qui le
relient respectivement aux nœuds précédent et suivant de la chaîne. Ce maintien est assuré
jusqu’à ce que les nœuds reçoivent le message d’acquittement, précisant la bonne réception des
paquets par le nœud destinataire. Une congestion par surcharge de mises-à-jour apparaît
lorsqu’un nœud assure le maintien de plusieurs chemins reliant différents destinataires. Une
telle congestion est due notamment aux messages Hello diffusés périodiquement sur le chemin
pour maintenir les liens. De plus, la construction réactive des chemins de routage augmente les
délais de transmission des paquets. DSR (Dynamic Source Routing) [31] est un autre protocole
de routage réactif. Il possède un mécanisme de routage différent de celui du protocole AODV.
En effet, dans le protocole de routage DSR (Figure 13), l’entête du paquet transmis par le nœud
expéditeur contient l’adresse de tous les nœuds intermédiaires ainsi que l’adresse du nœud
destinataire (source-initiated). Similaire à la majorité des protocoles de routage réactifs, le
mécanisme du protocole DSR repose sur deux procédures essentielles : la découverte et le
maintien du chemin de routage lors du transfert des paquets. En effet, lorsqu’un nœud source
souhaite envoyer un paquet à un nœud destinataire, il vérifie, dans sa table de routage la
présence d’un chemin de routage ; lorsqu’un chemin est détecté, la phase de découverte du
chemin est rapidement achevée et le nœud source envoie le paquet dans le réseau. Par contre, si
État de l’art
-32-
aucun chemin convenable n’est détecté, le nœud source diffuse à tous les nœuds du réseau une
demande de construction du chemin (RREQ). Pour chaque retransmission du paquet entre les
nœuds intermédiaires, l’adresse du nœud, recevant le paquet, est ajoutée dans l’entête du paquet
(Figure 13).
Protocole DSR : Découverte de
chemin de routage
Étape 1 :
Les noeuds 1 et 5 sont respectivement les noeuds source et destinataire. La table de routage du noeud source est vide, donc aucun chemin n’est défini vers le noeud 5. Le noeud 1 diffuse RREQ. Ensuite, la demande est transmise jusqu’au noeud 5 par l’intermédiaire des noeuds 2, 4 (puisque aucun de ces noeuds intérmediaires ne connaît de route vers 5). En revanche, le noeud 3 ayant dans sa table de routage le chemin, il ne retransmet pas la requête RREQ vers les noeuds voisins.
État de l’art
-33-
Étape 2 :
Le chemin de routage découvert est envoyé au nœud source (RREP). Il sera ajouté dans l’entête du paquet à envoyer au nœud 5.
Le nœud 1 reçoit deux chemins, un émis par le nœud destinataire 5, et un émis par le nœud 3, ayant dans sa table un chemin le reliant à 5.
Figure 13 : Mécanisme de découverte des chemins de routage (DSR)
La mobilité des nœuds dans les réseaux ad hoc fortement dynamiques empêche les protocoles
unicast de fonctionner proprement. En effet, la forte mobilité des véhicules provoque un
changement rapide de la topologie du réseau et engendre une rupture du chemin de routage.
Pour remédier à ce problème, des protocoles de routage unicast adaptés aux VANETs ont été
proposés; ces protocoles se basent sur les positionnements géographiques des véhicules. Un des
mécanismes de routage de paquets proposé consiste à découvrir le chemin de routage par un
algorithme glouton (greedy forwarding algorithm). L’algorithme de routage glouton permet de
router le paquet vers un nœud voisin géographiquement proche du nœud destinataire. GPSR
[32] est un exemple caractéristique des protocoles basés sur un algorithme de routage glouton
(Figure 14). Chaque nœud dans le réseau maintient dans sa table de voisinage la localisation
ainsi que l’identifiant des nœuds dans son voisinage direct. Mentionnons que ces informations
géographiques sont collectées grâce aux messages de signalisation envoyés périodiquement
dans le réseau. Lors du routage des paquets, le nœud retransmetteur consulte sa table de
voisinage et choisit le nœud le plus proche de la destination.
La Figure 14 illustre un exemple d’exécution du protocole GPSR.
État de l’art
-34-
Le protocole GPSR
Les noeuds S et D sont
respectivement les noeuds source et
destinataire. S, d’après l’algorithme
glouton, choisit dans sa zone de
transmission radio, le noeud le plus
proche de D (il choisit alors le noeud
o). Le même algorithme se repète
entre les noeuds p et q. Lorsque le
paquet atteint le noeud q, celui ci
envoie directement au noeud
destinataire D.
Figure 14 : Retransmission du paquet dans le protocole GPSR
2.3.1.2 Protocoles unicast proactifs
Les protocoles de routage unicast proactifs se basent sur un principe commun, celui de
maintenir une table de routage comportant, au préalable, tous les chemins possibles pour
atteindre le(s) nœud(s) destinataire(s). DSDV (Destination-Sequenced Distance Vector) [33] est
un exemple de protocole unicast proactif. Chaque nœud dans le réseau maintient une table de
routage. Cette table comporte les informations suivantes : la liste de tous les nœuds destinataires
possibles, le nombre de sauts nécessaires pour atteindre chaque destination, enfin, le numéro de
séquence (SN) qui correspond à une destination. Chaque nœud envoie sa table de routage à tous
les nœuds de son voisinage lorsqu’un changement se produit. En effet, la table de routage est
mise à jour selon deux paramètres : le temps et l’évènement. Pour chaque mécanisme de mise à
jour, le numéro de séquence est incrémenté pour différencier les anciennes des nouvelles routes.
État de l’art
-35-
Dans le protocole DSDV, le nœud attend la prochaine mise à jour initiée par la destination,
avant de mettre à jour l’entrée associée vers cette destination dans la table de routage.
Cependant, ce mécanisme d’attente ralentit le fonctionnement du protocole et diminue sa
performance.
Le protocole GSR (Global State Routing) [34] est similaire au protocole DSDV décrit
précédemment en termes de mise à jour de la table de routage. Dans le protocole GSR, chaque
nœud maintient essentiellement la liste de voisinages, la table de la topologie du réseau, la table
des nœuds suivants (Next hop nodes) qui contient l’adresse du nœud suivant, retransmetteur du
paquet vers chaque nœud destinataire ; enfin la table de distance comportant le chemin le plus
court vers chaque destination (distance calculée par l’algorithme de Dijkstra). Lors d’un
changement des états des liens dans le réseau et grâce aux messages de contrôle diffusés dans le
réseau, toutes les tables maintenues sont mises à jour. Mentionnons également que les mises-à-
jour sont appliquées uniquement lorsque le numéro de séquence est supérieur au numéro de
séquence précédemment sauvegardée dans la table.
Certains protocoles se basent sur la décomposition du réseau en zones, ils sont alors appelés
protocoles de routage hiérarchiques. Le protocole HSR (Hierarchical State Routing) [35]
(Figure 15) est un des exemples les plus significatifs des protocoles proactifs hiérarchiques.
État de l’art
-36-
Figure 15 : Hiérarchisation dans le protocole de routage HSR
Dans HSR, le réseau est partitionné en un ensemble de groupes, dont l’union forme le réseau
entier. Dans chaque groupe, un nœud est élu responsable pour gérer le groupe et assurer la
communication avec d’autres représentants des autres groupes. Dans la décomposition en
groupes, nous distinguons 3 types de nœuds : des nœuds représentants de groupe (appelés aussi
ClusterHeads), des nœuds liaison qui relient deux groupes, et des nœuds internes n’ayant aucun
rôle spécifique au sein du groupe. À partir de cette décomposition, deux niveaux hiérarchiques
sont détectés. Le niveau 0 comporte les groupes (i.e. les nœuds internes, les nœuds liaisons ainsi
que les nœuds représentants) ; il s’agit donc de la topologie physique du réseau. Le niveau 1
comporte les nœuds représentants reliés virtuellement. Grâce à cette décomposition
hiérarchique, pour chaque nœud du niveau 0, une adresse hiérarchique HID est attribuée (HID =
<adresse du groupe niveau 1, adresse du groupe niveau 0, adresse du nœud>). La transmission
des paquets se fait en fonction de la hiérarchie, autrement dit, selon le HID du nœud. Le nœud
émetteur envoie le paquet vers le nœud supérieur dans la hiérarchie puis, ce dernier retransmet
État de l’art
-37-
le paquet au nœud de liaison, qui à son tour retransmet le paquet vers le représentant du groupe
auquel le nœud destinataire appartient.
2.3.2 Protocoles unicast hybrides
Une troisième catégorie de protocoles unicast concerne les protocoles hybrides, qui mettent en
place simultanément un routage proactif est un routage réactif. Les protocoles ZRP [36, 37 ] et
CBRP [38, 39] appartiennent à cette catégorie. ZRP se base essentiellement sur une notion de
zone. Une zone regroupe l'ensemble des nœuds se trouvant à une distance maximum de X-sauts
du nœud de référence. Le routage au sein d'une zone routage (intrazone) se fait de manière
proactive à l'aide d'un protocole à état de liens. Le routage vers des nœuds extérieurs à cette
zone routage (interzone) s’effectue, lui, de manière réactive. Nous distinguons donc deux
procédures : IARP et IERP respectivement pour les routages intrazone et interzone. Un second
exemple de routage unicast hybride est le protocole CBRP. Dans ce protocole, le réseau est
décomposé en groupes (clusters). Chaque cluster est constitué des nœuds clusterheads, des
nœuds gateways (ou nœuds routeurs) ainsi que des nœuds basiques. Le rôle des clusterheads est
d’abord de découvrir les chemins de routage, puis de retransmettre les paquets vers la
destination, et enfin de maintenir les chemins de routage. Les nœuds gateways possèdent dans
leur voisinage deux ou plusieurs clusterheads. Lorsque deux clusterheads veulent communiquer,
les nœuds gateways jouent le rôle de nœud relais pour assurer la retransmission des paquets
entre les clusterheads. L’aspect réactif du protocole CBRP apparaît lorsqu’un nœud souhaite
envoyer des données à un nœud destinataire ; il diffuse alors une requête de demande de chemin
uniquement aux représentants des groupes, autrement dit, aux clusterheads. Le représentant du
groupe lorsqu’il reçoit la demande, vérifie si le nœud destinataire est dans le groupe, sinon il
retransmet la demande aux représentants des groupes voisins.
État de l’art
-38-
Le mécanisme de découverte du chemin de routage dans les protocoles proactifs est plus rapide
puisque les chemins de routage possibles entre les nœuds du réseau sont établis au préalable, ce
qui n’est pas le cas dans les protocoles réactifs où les chemins sont établis à la demande.
Cependant, dans les VANETs, en raison de la forte mobilité des véhicules, il est difficile de
prévoir et d’établir des chemins de routage au préalable.
Les applications de transfert de données volumineuses nécessitent une communication fiable
afin de garantir un acheminement bout-à-bout des données. Aucun des protocoles réactifs,
proactifs ou même ceux qui se basent sur les données géographiques ne peut fournir une
solution satisfaisante face à cette problématique. En effet, ces protocoles, pour qu’ils soient
adaptés aux réseaux VANETs, nécessitent l’exécution fréquente de mécanismes de
maintenance sur les chemins de routage ; ces mécanismes provoquent un overhead considérable
dans le réseau lorsqu’ils sont appliqués à des intervalles de temps très courts.
Les protocoles unicast tolérants aux délais sont une autre catégorie de protocoles unicast ; ces
protocoles prennent en considération la fiabilité de la communication grâce à la technique de
retransmission « Carry-And-Forward ». Dans ce qui suit, les principaux protocoles unicast
tolérants aux délais sont détaillés.
2.3.3 Protocoles unicast tolérants aux délais
Plusieurs protocoles de routage unicast tolérants aux délais ont été étudiés dans la littérature [10,
40, 41, 42, 43, 44]. Le protocole VADD [10] est un protocole de routage unicast basé sur le
principe « Carry-and-Forward », adapté aux réseaux tolérants aux délais. Comme les protocoles
de routage unicast classiques, VADD route les paquets dans la direction de la destination. Il faut
cependant noter que le routage mis en œuvre ne concerne que les destinations stationnaires
(restaurant, hôpital, etc.). Le mécanisme de routage se base, d’une part sur les positionnements
État de l’art
-39-
courants des véhicules dans le voisinage ; d’autre part, sur l’état de la circulation dans le réseau
routier. Dans VADD (Figure 16), les routes les plus denses de véhicules sont considérées
comme les chemins optimaux pour le routage des paquets (chemin (A-C-D-B) - les points A et
B sont respectivement les points source et destination) ; le chemin (A-B) pourtant
géographiquement le plus court n’est pas pris en considération.
Figure 16 : Mécanisme de routage dans le protocole VADD
Toutefois, il n’est pas toujours prévisible d’estimer le comportement des véhicules et les
changements de l’état de la circulation dans un réseau routier ; les nœuds peuvent à tout instant
changer de direction et sortir du chemin de routage. Dans ce cas, le véhicule garde le paquet et
cherche un nœud retransmetteur capable de relayer avec succès le paquet. Les résultats
d’expérimentations [10] montrent que la performance du protocole VADD diminue lorsque
l’état de la circulation devient fluide (nombre de véhicules relais diminuant sur le chemin de
retransmission). Dans ce contexte, dans le protocole SADV [40], des nœuds statiques sont
placés dans le réseau routier pour faciliter et améliorer le routage des paquets vers la
destination. Lorsqu’une panne apparaît, le nœud statique garde le paquet et le retransmet au
véhicule appartenant au chemin optimal (i.e. le chemin le plus dense).
GeOpps [44] est un autre protocole de routage opportuniste tolérant aux délais. GeOpps est dit
opportuniste car il réduit les délais de transmission ; la retransmission d’un paquet s’effectue en
État de l’art
-40-
effet entre les nœuds capables de router le plus rapidement possible les paquets vers une région
géographique prédéfinie. Par hypothèse, chaque véhicule connaît l’adresse de la destination du
paquet ainsi que sa propre trajectoire récupérée par un système de géo-positionnement, par
exemple de type GPS. S’appuyant sur ces informations, chaque véhicule calcule les
coordonnées du point le plus proche de la destination par rapport à sa trajectoire ainsi que la
durée nécessaire pour atteindre la destination. Le mécanisme de retransmission et la sélection du
nœud relais suivant, se base essentiellement, sur la durée minimale estimée pour arriver au point
destination.
Les protocoles unicast tolérants aux délais sont les plus prometteurs et les plus adaptés pour les
réseaux ad hoc de véhicules, en raison de leur mécanisme de « Carry-and-Forward » des
paquets. En revanche, dans le cas du protocole SADV, des points stationnaires sont déployés
dans le réseau pour relayer les paquets dans la direction de la destination lorsqu’une panne
intervient sur le chemin de routage. Dans les autres protocoles tolérants aux délais, la
destination est stationnaire (VADD) ou elle appartient à une région statique déterminée
(GeOpps).
Rappelons que l’environnement considéré dans cette thèse ne comporte aucun point stationnaire
facilitant le routage ; de plus, les points source et destinataire sont des véhicules mobiles dans le
réseau. Ainsi, les protocoles mentionnés dans la littérature offrent des solutions partielles et pas
totalement appropriées aux hypothèses considérées et à la problématique étudiée dans cette
thèse.
2.3.4 Protocoles de routage intégrant la qualité de service
La qualité de service (Quality of Service - QoS) est une condition importante à prendre en
considération dans les applications de transfert de données volumineuses [48, 49]. Plusieurs
État de l’art
-41-
définitions ont été proposées pour décrire la qualité de service. Pour certains [46, 47], la qualité
de service est reliée aux contraintes physiques, telles que la capacité de la bande passante, le
délai de transmission ainsi que les pertes de paquets. Pour d’autres [45], la qualité de service est
reliée à la couche application, autrement dit, à la gestion de données à transmettre dans le
réseau.
Différents protocoles prenant en compte la QoS pour le transfert de données dans les réseaux ad
hoc ont été proposés dans la littérature [45, 46, 47]. Généralement, lorsqu’un nœud souhaite
transmettre des données dans le réseau, un flux de données est préparé au niveau de la couche
application (niveau 7) du modèle OSI, puis celui-ci est envoyé à la couche transport (niveau 4).
C’est à ce niveau, que les paquets sont partitionnés et mis dans une file d’attente. Par défaut, les
paquets sont transmis selon la méthode FIFO (First In First Out). Cependant, dans [45], les
auteurs proposent de transmettre les paquets dans le réseau par ordre de priorité. La méthode,
appelée SBPN (Send Best Packet Next), prend en considération le temps d’expiration des
paquets en fonction de la valeur de RTT3 (Round Trip Time). Dans SBPN, les paquets de type
audio sont classés prioritaires par rapport aux paquets de type vidéo.
Des protocoles de routage intégrant les contraintes de QoS physiques, spécialement la
disponibilité de la bande passante, ont été également proposés dans la littérature. Le protocole
QASR – Quality-Aware Source Routing [46] en est un exemple ; QASR est une amélioration du
protocole DSR (protocole unicast réactif, présenté section 2.3.1.1). Son rôle est de maintenir un
chemin de routage tout en respectant les contraintes QoS de la bande passante. Le protocole de
routage DSR se base sur l’utilisation de la technique « routage source ». Cette technique permet
de définir au préalable le chemin de routage entre le nœud source et le nœud destinataire avant
de débuter la transmission des données, d’où la dénomination de « routage source ». Ainsi, tout
nœud recevant le paquet, le retransmet vers les nœuds dont l’adresse figure dans le chemin de
routage. Pour construire le chemin de routage, le nœud qui souhaite transmettre des données à
un nœud destinataire inonde le réseau par des messages RREQ. Chaque nœud capable de
3 Le RTT est le délai estimé pour transmettre un paquet depuis un nœud source vers un nœud destinataire avec un retour d’un acquittement vers le nœud source à la réception du paquet envoyé
État de l’art
-42-
contribuer à la retransmission du paquet, ajoute son adresse dans le paquet RREQ et le
retransmet aux nœuds suivants. À l’arrivée du message RREQ vers la destination, un message
RREP est envoyé sur le même chemin vers le nœud source (chemin de retour inverse). Comme
pour le mécanisme de routage de DSR, le protocole QASR diffuse des messages RREQ ;
cependant, une contrainte s’ajoute lors de la construction du chemin de routage ; chaque nœud
vérifie la disponibilité de la bande passante par rapport à la bande passante souhaitée pour
transmettre les données sans délai supplémentaire. Si la condition est respectée, le nœud
participe à la retransmission du paquet, sinon il rejette la demande. Dans la même catégorie, Q-
AODV [47] a été proposée pour améliorer la performance du protocole réactif AODV réactif
(section 2.3.1.1). Comme dans QASR, le chemin de routage est choisi selon la disponibilité de
la bande passante des nœuds participant au mécanisme de retransmission du paquet vers le
destinataire.
Dans la Table 2, nous analysons l’adaptation des protocoles unicast aux réseaux fortement
dynamiques en termes de fréquence de reconfiguration des chemins de routage. Nous
remarquons que les protocoles unicast tolérants aux délais sont les plus adaptés. En effet, les
reconfigurations des chemins sont rares grâce aux techniques de transmission « Carry-And-
Forward ».
Table 2 : Tableau récapitulatif des protocoles réactifs, proactifs et tolérants aux délais
Protocole de routage Type Reconfiguration des chemins de routage
AODV/ DSR Réactif - - GPSR Réactif (adapté au VANET) + DSDV / GSR Proactif - - HSR Proactif - VADD / GeOpps / SADV Tolérants aux délais + - - Très fréquente - Fréquente + Rare
État de l’art
-43-
2.4 DISCUSSION ET CONCLUSION
Dans ce chapitre, nous avons étudié les protocoles de routage proposés pour les réseaux ad hoc
mobiles, réseaux de véhicules (VANETs) en particulier. Notre analyse est focalisée plus
particulièrement sur la performance et la pertinence de ces protocoles pour les applications de
transfert de données volumineuses (exemple : applications multimédias) dans les réseaux ad hoc
de véhicules. Une application de transfert de données, comme nous l’avons mentionné
auparavant, est composée de deux phases de routage de paquets. La première phase met en
œuvre la dissémination de la requête dans le réseau ; alors que la deuxième phase est réservée
au transfert des données recherchées. L’objectif des deux phases étant différent, il est donc
nécessaire de proposer deux mécanismes différents de routage, chacun adapté à l’objectif visé.
Ainsi, la requête est disséminée vers un ensemble de nœuds dans le but d’élargir l’espace de
recherche. Nous avons donc ici besoin d’un routage multipoint. À l’inverse, pour le transfert de
données, les paquets sont adressés à un seul nœud (nœud source émetteur de la requête) ; un
routage unicast est donc nécessaire.
Un protocole de routage, pour qu’il soit adapté aux applications de transfert de données
volumineuses, doit répondre aux conditions suivantes :
• La transmission de données multimédias nécessite un chemin de communication fiable ;
en conséquence, le protocole de routage assurant le lien entre les nœuds doit prendre en
considération la forte mobilité des véhicules.
• Afin de réduire la surcharge dans le réseau, les mécanismes de maintien et de
reconfiguration du chemin de routage ne doivent pas être appliqués trop fréquemment et
d’une manière périodique.
État de l’art
-44-
• La qualité de service doit être également prise en considération lors du transfert de
données de grande taille sur le chemin de routage (bonne utilisation de la bande
passante, perte des paquets, etc).
Certains protocoles mentionnés dans la littérature répondent partiellement aux critères définis ;
par contre, d’autres sont totalement inadaptés aux environnements fortement dynamiques et/ou
aux applications de transfert de données volumineuses. Dans la Table 3 ci-dessous, nous
synthétisons les performances des différentes classes de protocoles pour la gestion
d’applications de transfert de données déployées dans un VANET.
Table 3 : Tableau comparatif des protocoles de routage
Protocoles Coût de
maintenance
Fiabilité de communication
Utilisation de la bande passante
Application de transfert de
données volumineuses
Multipoints arborescence/maillé
+ + + Diffusion requête
Géographiques + + - Diffusion requête
Unicast réactifs/proactifs
- - - Transfert de données
Unicast tolérants aux délais
+ + + + Transfert de données
Unicast Qualité de Service
+ + + + Transfert de données
- négligé + partiellement considéré ++ considéré
Les protocoles unicast réactifs/proactifs, lorsqu’ils sont utilisés dans les réseaux ad hoc de
véhicules, provoquent une surcharge dans le réseau à cause des mises à jour fréquentes des
État de l’art
-45-
chemins de routage. La discontinuité du chemin de routage due à la mobilité des véhicules est
en outre mal prise en charge par ces protocoles. Les protocoles de routage unicast tolérants aux
délais apportent une solution intéressante au problème de rupture de chemin de connectivité des
nœuds, ceci grâce aux mécanismes « Carry-and-Forward ».
Les protocoles unicast peuvent être utilisés pour le transfert des données volumineuses. Il s’agit
ici de pouvoir assurer non seulement un acheminement bout-à-bout et une communication
fiable, mais également garantir une bonne qualité de service et faire un bon usage de la bande
passante. En effet, lorsque la bande passante est utilisée d’une manière cohérente, les délais de
transmission ainsi que le taux de perte des paquets seront considérablement réduits. Certains
protocoles mentionnés dans ce chapitre appartiennent à la catégorie « Protocoles unicast
intégrant la qualité de service »; la performance de ces protocoles est cependant focalisée
uniquement sur l’usage de la bande passante, sans une attention particulière concernant la
fiabilité de la communication.
Les protocoles multipoints et géographiques sont prioritairement utilisés pour la dissémination
de la requête dans le réseau. Cependant, il n’est pas concevable, pour des raisons de
performance, de construire le groupe multipoint (overlay) de manière aléatoire en laissant le
choix aux nœuds d’adhérer au groupe. Un groupe multipoint doit être construit selon des
critères précis pour éviter les mises à jour fréquentes et réduire par la suite la surcharge dans le
réseau. Une solution intéressante est proposée dans les protocoles de routage géographiques,
dans lesquels le mécanisme de routage est basé sur les données géographiques des nœuds.
Cependant, dans ces protocoles, le paquet est routé de manière multipoint vers un ensemble de
véhicules appartenant à une même région géographique. Cette approche ne correspond pas aux
contraintes des applications de transfert de données volumineuses, puisque le nœud destinataire
des données est un nœud mobile qui peut être amené à changer de région. À l’inverse, la
connaissance des localisations futures des véhicules peut être très utile pour le traitement de la
requête et l’envoi des données.
État de l’art
-46-
Dans ce travail de thèse, nous proposons un nouveau protocole de routage spécialement conçu
pour les applications de transfert de données volumineuses dans les VANETs. DG-CastoR
(Direction-based GeoCast Routing) est un protocole géo-multipoint tolérant aux délais. Ainsi,
DG-CastoR regroupe les fonctionnalités des deux catégories de protocoles : le routage
multipoint est appliqué pour envoyer une requête vers un ensemble sélectionné de nœuds. Ces
nœuds sont choisis par rapport à leurs localisations géographiques (trajectoires futures). De
plus, dans la seconde phase de l’application, un mécanisme de type « Carry-and-Forward » est
utilisé pour assurer le transfert des données en mode unicast entre les nœuds du groupe
multipoint et le nœud source de la requête.
-51-
Première Partie
Méthode de recherche de voisinages proches et mécanisme de construction de
colonie (overlay)
-53-
CHAPITRE 3
TQ : RECHERCHE DE TRAJECTOIRES PROCHES
3.1 INTRODUCTION
L’évolution des réseaux de communication sans fil et des équipements de géo-
positionnement comme le standard GPS4 ont contribué au succès des applications fondées sur la
localisation géographique des unités mobiles. Les services de proximité sont parmi les
applications les plus répandues. L’objectif de ces applications est de retourner, suite à la
demande de l’utilisateur, des POI5 situés à proximité de sa localisation géographique (tels que
4 GPS : Global Positionning System 5 POI : Point of Interests – Points d’intérêt
Recherche de Voisinages Proches
-54-
hôpitaux, restaurants, hôtels, etc). Les applications existantes fonctionnent essentiellement dans
les architectures cellulaires comme les architecture GSM/GPRS6 et UMTS7. Ces systèmes de
communication font appel à des stations de base. Ces stations appelés aussi points d’accès
gèrent l'ensemble des communications au sein d'une même zone géographique. Ces points
d’accès sont à leur tour connectés à des systèmes de distribution (backbone). Ainsi, chaque
nœud du réseau (utilisateur mobile) communique ses informations géographiques (position,
vitesse, etc.) à un serveur centralisé. Ces informations collectées à partir de différents nœuds
mobiles sont utilisées pour offrir un service particulier aux nœuds du réseau.
Les services basés sur la localisation (LBS8) ont trouvé un succès également dans les réseaux ad
hoc, et plus particulièrement, dans les réseaux ad hoc de véhicules. Les véhicules mobiles
peuvent diffuser des requêtes spatiales pour demander des services stationnaires de proximité
(tels que l’adresse d’un restaurant, l’adresse du plus proche hôpital, etc) [50, 51, 52, 53]. Les
nœuds mobiles peuvent également rechercher d’autres véhicules mobiles à proximité de leur
localisation géographique [54, 55, 56, 57]. L’intérêt de cette approche est d’améliorer la
communication entre les véhicules, de manière autonome, sans l’intervention de points d’accès.
La recherche de voisinages proches est intéressante spécialement dans les réseaux sans
infrastructure comme les VANETs. Des véhicules, grâce à une communication Véhicule-à-
Véhicule, peuvent alors s’échanger des données (exemple : informations touristiques, photos ou
vidéo d’une ville, etc.) ou des informations relatives au réseau routier (info trafic, météo, etc.).
La communication Véhicule-à-Véhicule (VàV) est établie facilement puisqu’elle ne nécessite
aucune installation d’équipements ni d’infrastructure. En revanche, une telle communication
nécessite une fiabilité des liens pour garantir une bonne qualité de service à l’application. Une
communication VàV est dite fiable lorsque la connectivité entre les nœuds est stable tout au
long de la communication. Cette condition de connectivité est nécessaire dans les applications
6 GSM/GPRS : Global System for Mobile Communications 7 UMTS : Universal Mobile Telecommunication System 8 LBS : Location-Based Services
Recherche de Voisinages Proches
-55-
de transfert de données volumineuses qui requièrent une communication fiable lors du transfert
de données multimédias de grande taille.
Les méthodes de recherche de voisinages proches peuvent être classifiées en deux catégories :
la première catégorie regroupe les méthodes de recherche de k-voisins proches (exemple de
requête : « Je cherche les 3 restaurants les plus proches de ma localisation courante ») [50, 51].
La seconde catégorie appelée requêtes à intervalle (Range Queries) consiste à trouver les voisins
proches dans une zone définie de recherche (exemple de requête : « Je cherche tous les
restaurants à moins de 3km de ma localisation géographique courante ») [56, 57].
Dans ce chapitre, nous proposons une nouvelle méthode de recherche de voisinages proches
appelée TQ – Trajectory Queries. Cette méthode appartient à la catégorie requêtes à intervalle.
La zone de recherche dans la méthode TQ correspond à la trajectoire du nœud source, appelée
aussi trajectoire requête. Grâce à des mesures de similarité spatio-temporelle, la méthode TQ
permet de trouver l’ensemble des véhicules (nœuds) dont la trajectoire est similaire à la
trajectoire requête considérée.
3.2 RECHERCHE DE VOISINAGES PROCHES Dans cette thèse, nous adoptons l’hypothèse que tous les véhicules dans le réseau sont équipés
d’un système de navigation. Nous supposons que le système de navigation retourne, lorsque les
coordonnées du point de départ et l’adresse de la destination lui sont fournies, l’itinéraire futur
du véhicule. Cet itinéraire, qui correspond à la trajectoire future du véhicule, peut être récupéré
dans un format standardisé de type KML [58] ou GPX [59].
Généralement, les systèmes de navigation retournent les coordonnées ellipsoïdiques des
positionnements. Ces coordonnées sont représentées par la longitude, la latitude et l’altitude. La
mesure de similarité spatio-temporelle proposée dans cette thèse utilise pour des raisons de
simplification des calculs, les coordonnées cartésiennes des positionnements de la trajectoire
Recherche de Voisinages Proches
-56-
dans un plan 2D. Dans ce contexte, des méthodes de transformation doivent être appliquées afin
de transformer les données ellipsoïdiques récupérées en coordonnées cartésiennes [60]. Dans ce
qui suit, les points le long des trajectoires sont représentés par leurs coordonnées cartésiennes
(x,y).
Avant d’expliquer en détail les différentes étapes du calcul de la similarité spatio-temporelle,
nous présentons, dans la table 4, tous les symboles utilisés dans ce chapitre et donnons leur
description.
Table 4 : Tableau récapitulatif des symboles de TQ
Symboles Description
T= {<Pi,ti> …} Trajectoire du véhicule, composée de couple <pi, ti>
Pi Point représenté par ses coordonnées cartésiennes (xi,yi) dans un plan 2D
[ , ]I I I− += Intervalle de temps de la trajectoire, tels que I- et I+ sont respectivement les bornes
inférieure et supérieure de l’intervalle.
, , ,[ , ]p q p q p qSI SI SI− +=
Sous-intervalle commun entre deux trajectoires comparées.
, , ,[ , ]p q p q p qSI SI SI− += représente le sous-intervalle des trajectoires Tp et Tq
δ δ représente le temps écoulé (période) entre deux positionnements successifs
enregistrés Pi et Pi+1 dans la trajectoire
ECD Durée de connectivité estimée (Estimated Connectivity Duration). Elle est calculée à
partir des mesures de similarité spatio-temporelle
Recherche de Voisinages Proches
-57-
3.2.1 Modélisation des trajectoires futures des véhicules
Une trajectoire est définie par un tracé reliant un point de départ à un point d’arrivée. Le tracé
comporte un ensemble de points, appelés les positionnements d’un véhicule sur la trajectoire
parcourue. Les positionnements sont déterminés à des instants précis. Les positionnements
futurs des véhicules sont représentés sous forme de triplets , ,i i ix y t< > , représentant
respectivement les coordonnées cartésiennes (xi, yi) d’un point et l’instant (ti) d’enregistrement
du positionnement. Une trajectoire est donc définie comme suit :
0 0 1 1 2 2{ , , , , , ,..., , }n nT p t p t p t p t= < > < > < > < >
Où chaque point pi indique une position future du véhicule ; i [0.. ], ,i i in p x y∀ ∈ = < >
Une trajectoire est limitée par un intervalle de temps noté : [ , ]I I I− += , où I - et I+ indiquent
respectivement les bornes inférieure et supérieure de l’intervalle « I » (I-=t0,I+=tn)
3.2.1.1 La période « δ »
Les positionnements futurs d’une trajectoire sont déterminés à des intervalles de temps réguliers
qui peuvent être différents d’une trajectoire de véhicule à une autre. Nous définissons donc un
paramètre appelé période, désigné par δ. La période représente le temps écoulé entre deux
positionnements successifs. La période varie selon la vitesse d’un véhicule. Si un véhicule se
déplace vite, la distance parcourue entre deux instants ti et ti+1 est grande. Pour garantir une
bonne précision de la trajectoire, il est donc nécessaire de diminuer la période (δ)9 entre ti et ti+1.
9 δ correspond de fait à la période d’échantillonnage de la position du véhicule
Recherche de Voisinages Proches
-58-
En pratique, nous proposons de déterminer la période selon deux paramètres : (i) la vitesse (V)
du véhicule et (ii) la précision spatiale souhaitée (α).
( )( )
( / )
( / ) ms
m s
RVα
δ = ( *)Nα ∈ (1)
« R » étant le rayon de transmission radio, supposé constant pour tous les véhicules.
En clair, nous souhaitons garantir une certaine précision spatiale (nous parlons aussi de
résolution spatiale). La vitesse du véhicule étant connue, nous calculons la période δ qui
correspond à la précision souhaitée.
La plus faible précision (α = 1) correspond à une distance parcourue par le véhicule, entre deux
positionnements, égale à R. Cependant, cette distance peut être diminuée en fonction de la
précision (α). La précision est supposée constante pour toute la trajectoire et elle est considérée
grande lorsque la valeur de α est supérieure ou égale à 3. Une faible précision (exemple : α = 1)
risque d’engendrer des erreurs d’appariement entre la trajectoire tracée et la carte géographique.
La Figure 17, montre les positionnements enregistrés pour une même vitesse mais à des
précisions différentes :
(a) Faible précision
(b) Grande précision
Figure 17 : Tracé d’une trajectoire à précisions différentes
Recherche de Voisinages Proches
-59-
Outre la précision (α), le second paramètre à considérer dans le calcul de la période est la
variation de la vitesse. Un véhicule mobile dans un réseau routier accélère ou décélère selon
l’état de la circulation routière. D’après la relation (1), la période est inversement
proportionnelle à la vitesse.
La timeline d’une trajectoire représente les instants où les positionnements sont enregistrés.
L’intervalle entre deux instants (c’est-à-dire la période δ) varie en fonction de la vitesse.
Figure 18 : La timeline d'une trajectoire
La timeline de la Figure 18 montre les positionnements enregistrés à des périodes différentes,
ceci, selon la vitesse du véhicule. Pour une précision (α) constante quatre valeurs de δ sont
définies correspondant à 0 1 2 3, , ,V V V V
Nous pouvons noter que la période est inversement proportionnelle à la vitesse. (exemple :
2 1 2 1|| || || ||, alors, V V δ δ> <
3.2.2 Calcul de la similarité spatio-temporelle
3.2.2.1 Calcul de la similarité temporelle Par définition, une similarité temporelle est effective lorsque deux véhicules sont présents à un
même intervalle de temps dans le réseau.
Recherche de Voisinages Proches
-60-
Pour mesurer la similarité temporelle, nous comparons les intervalles de temps de deux
trajectoires futures étudiées.
Pour mieux présenter la méthode de mesure de similarité, considérons l’exemple de deux
trajectoires Trq et Trp dont les intervalles de temps respectifs sont Iq et Ip :
0 0 1 1 2 2{ , , , , , ,..., , }q q q qq n nT p t p t p t p t= < > < > < > < > avec 0[ , ] [ , ]q q q nI I I t t− += =
0 0 1 1 2 2{ , ' , , ' , , ' ,..., , ' }p p p pp m mT p t p t p t p t= < > < > < > < > avec 0[ , ] [ ' , ' ]p p p mI I I t t− += =
Lorsque ( )q pI I+ −≤ ou ( )q pI I− +≥ aucune similarité n’est détectée, puisque les deux intervalles n’ont aucun tronçon de durée commun. Dans tous les autres cas possibles, le sous-intervalle commun composé des deux bornes inférieure et supérieure, respectivement, SI- et SI+, est identifié comme suit :
( , ) ( , )q p q pSI Max I I et SI Min I I− − − + + += =
Figure 19 : Sous-Intervalle commun [SI-, SI+] des trajectoires Tq et Tp
Recherche de Voisinages Proches
-61-
Dans l’exemple de la Figure 19, le sous-intervalle commun des trajectoires Trq et Trp est : 0 11[ , ] [ ' , ]SI SI SI t t− += =
L’algorithme ci-dessous présente la fonction de calcul de la similarité temporelle : Fonction Similarité_Temporelle(Ip, Iq)
Cet algorithme mesure la similarité temporelle des deux intervalles. Il retourne le sous-intervalle commun SIp,q = [SI-, SI+]
Entrées :
[ , ]q q qI I I− += : l’intervalle de la trajectoire Tq
[ , ]p p pI I I− += : l’intervalle de la trajectoire Tq
Sortie : SIp,q = [SI-, SI+] : le sous-intervalle commun
Début 1. Si ( ( )q pI I+ −≤ ou ( )q pI I− +≥ ) Alors 2. Similarité = False 3. SI- = null et SI+ = null 4. Sinon 5. Similarité = True 6. SI- = Max( ,q pI I− − ) et SI+ = Min( ,q pI I+ + ) 7. Fin Si 8. Retourner (SI-, SI+)
Fin
3.2.2.2 Calcul de la similarité spatiale
La seconde étape de calcul de la similarité est de mesurer la similarité spatiale des trajectoires.
Dans notre travail, l’objectif de la mesure de la similarité spatiale est de calculer la durée de
connectivité entre deux véhicules (durée nécessaire pour communiquer et échanger des
données). Cette distance est calculée par la distance Euclidienne. En effet, lorsque la distance
Recherche de Voisinages Proches
-62-
Euclidienne entre deux positionnements est inférieure au rayon de transmission radio (R), les
deux véhicules sont à portée radio l’un de l’autre et donc ils peuvent communiquer. Deux
véhicules peuvent circuler sur deux routes différentes (parallèles par exemple) mais ils peuvent
cependant communiquer si la distance Euclidienne entre ces deux véhicules est inférieure au
rayon de transmission radio (Figure 2010).
Figure 20 : Connectivité des trajectoires (distance Euclidienne)
La distance Euclidienne de deux points mi et mj est calculée par la formule suivante :
2 1/2
1( , ) ( ( ) )
k k
n
E i j i jk
d m m m m=
= −∑ . Lorsque ( , )E i jd m m < R (R étant le rayon de transmission radio
supposé constant pour tous les véhicules), les véhicules peuvent communiquer à un saut
puisqu’ils sont à portée radio l’un de l’autre.
10 L’illustration montre une approximation du rayon de transmission. La communication pouvant être perturbée par des bâtiments ou des émissions électromagnétiques ou autre.
Recherche de Voisinages Proches
-63-
3.2.3 Synchronisation des trajectoires par interpolation
linéaire Dans un réseau ad hoc décentralisé, les nœuds sont autonomes ; ceci explique que la période
« δ » considérée n’est pas uniforme pour tous les nœuds du réseau. Or, pour mesurer la distance
euclidienne, il est nécessaire que les positionnements des deux trajectoires soient synchronisés
(pris aux mêmes instants).
Ainsi, pour mesurer la similarité spatiale des trajectoires des véhicules, il est nécessaire d’abord
de synchroniser les périodes puis de calculer les positions approximatives pour la période
commune adoptée. La synchronisation est effectuée par interpolation linéaire.
3.2.3.1 Interpolation linéaire des trajectoires
Par définition, l’interpolation linéaire permet de calculer les coordonnées d’un point situé entre
deux autres points dont les coordonnées sont connues. Dans notre approche, l’interpolation
linéaire est toujours appliquée en fonction des instants déterminés dans la trajectoire du nœud
requête.
L’interpolation linéaire s’applique dans le sous-intervalle commun fermé , , ,[ , ]p q p q p qSI SI SI− += .
Pour chaque instant (ti) de la trajectoire requête Tq, tel que , , , ,[ , ] { , }i p q p q p q p qt SI SI SI SI− + − +∈ ∪ ,
nous calculons par interpolation linéaire les points correspondants situés sur la trajectoire Tp.
Les positions interpolées sont calculées comme suit :
Soit (ti)0..n les instants de la trajectoire Tq tels que , ,[ , ]i p q p qt SI SI− +∈ Soit (tj)0..m les instants de la trajectoire Tp tels que , ,[ , ]j p q p qt SI SI− +∈
Soit (Pj)0..m les points de la trajectoire Tp (le point Pj correspond à l’instant tj).
Recherche de Voisinages Proches
-64-
Soit '0..( )i nP les points obtenus par interpolation, tels que '
iP est le point de la trajectoire Tp
correspondant à l’instant ti
Soit 0..( )i i nt t∈ . S’il existe 0..( )j j mt t∈ tel que i jt t= , alors 'i jP P= .
Sinon, soit jt tel que 1,i j jt t t + ∈ alors '1( )i j i j j jP P t t P P+= + −
Pour les bornes inférieure et supérieure, le même calcul est réalisé en indiquant les instants de Tp (et de Tq) immédiatement précédent l’intervalle , ,[ , ]p q p qSI SI− +
Figure 21 : Interpolation linéaire des positionnements de la trajectoire Tp
À l’issue de l’interpolation linéaire nous obtenons la trajectoire 0 1' { ' , ' ,... ' }p nT P P P= Dans l’exemple de la Figure 21, l’interpolation est appliquée aux positionnements de la
trajectoire Tp. L’ensemble de (n) positionnements interpolés 0 1' { ' , ' ,... ' }p nT P P P= sont calculés
pour les instants suivants : 0 3 4 5 6 7 8 9 10 11, ,{ , , , , , , , , , }p q j i i i i i i i i p q iSI t t t t t t t t t SI t− += =
La communication est toujours établie avec un nœud (véhicule) source d’une requête. Ainsi, en
pratique, nous mesurons la similarité toujours par rapport à la trajectoire et aux périodes δ du
Recherche de Voisinages Proches
-65-
nœud source. Cependant, une alternative serait d’appliquer l’interpolation linéaire par rapport à
la trajectoire ayant la plus grande vitesse (c’est-à-dire petites périodes δ). Cette méthode
méthode présente l’avantage que l’interpolation linéaire s’appliquant à des périodes courtes, elle
garantit une précision élevée des calculs. Cependant, lorsque le nombre de points augmente, la
complexité de l’algorithme de calcul de la similarité spatio-temporelle augmente.
3.2.4 Calcul de la distance entre deux trajectoires
À l’issue de l’interpolation linéaire, la distance entre les deux trajectoires T’p (la trajectoire
interpolée) et Tq est calculée de la manière suivante : la distance Euclidienne est calculée pour
chaque paire de segments<S q, S p>.
Tel que,
Sq représente un segment de la trajectoire Tq, composé de deux positionnements <Qi, Qi+1>. Aux
mêmes instants, Sp représente un segment de la trajectoire T’p, composé de deux
positionnements <P’i, P’i+1>.(Figure 22)
Figure 22 : Calcul de la distance entre deux segments (de trajectoires)
Recherche de Voisinages Proches
-66-
Théorème :
Soit deux segments <P’i, P’i+1>.et <Qi, Qi+1>, tels que P’i (resp. Qi) est le point de la trajectoire
T’p correspondant à l’instant ti (resp. P’i+1 et Qi+1 correspondant à l’instant ti+1).
Soit [ ]1,i it t t +∈ . Soit P’(t) (resp. Q(t)) le point de la trajectoire T’p (resp. Tq) à t.
[ ]'
1'1 1
Si ( , )alors , , ( '( ), ( ))
et ( , )i i
i ii i
d P Q Rt t t d P t Q t R
d P Q R +
+ +
< ∀ ∈ <<
Où d dénote la distance euclidienne.
Démonstration
Soit[Qi, Qi+1] le premier segment, et [P’i, P’i+1] le second segment. Nous supposons que les segments sont définis sur l’intervalle fermé [ti, ti+1].
Nous définissons 1
i
i i
t tt t
τ+
−=
−et nous ramenons l’intervalle [ti, ti+1], par transformation affine à
[0,1].
Notons P(t) la position sur le segment [P’i, P’i+1] à l’instant (t), t=0..1 avec P(0) = P’i, et P(1) =
P’i+1. De la même manière, notons Q(t) la position au même instant (t) ; Q(t) appartient au
segment [Qi, Qi+1] ; Q(0) = Qi ; Q(1) = Qi+1.
Par hypothèse : '( , )i id P Q R< et '
1 1( , )i id P Q R+ + < (i.e. la distance entre les deux véhicules aux
instants 0 et 1 est inférieure à R)
On cherche à démontrer que : ( ) ( ) ( ) ( )[0;1] || || ( , )t t t tt P Q d P Q R∀ ∈ = <
(i.e. la distance entre les
deux véhicules est inférieure à R quel que soit t=0..1.
Recherche de Voisinages Proches
-67-
Étape 1 :
Remarque : pour simplifier la démonstration, on notera ci-dessous P (resp. Q)en lieu et place de
P(t) (resp. Q(t)).
De même, on notera A et B en lieu et place de Qi,et Qi+1respectivement et C et D en lieu et
place de P’i, P’i+1 respectivement.
Figure 23 : Distance Euclidienne des segments [AB] et [CD]
Soit t ∈ [0,1] fixé.
D’après la relation de Chasles :
= PQ PA AC CQ+ +
(équation 1) Or on a :
= .
CQ = .
AP t AB
t CD
Donc :
= - . .PQ t AB AC t CD+ +
= .( )PQ t CD AB AC− +
(équation 2)
Recherche de Voisinages Proches
-68-
= .PQ AC t k+
où k CD AB= −
Il nous faut donc montrer :
|| ||AC tk R+ <
(équation 3)
Soit D’ tel que 'DD
.= BA
. On a
– ’ ’k CD AB CD BA CD DD CD= = + = + =
L’équation (3) devient : || ' ||AC tCD R+ <
avec t=0..1 (équation 4)
Soit M le point du segment 'CD
tel que 'CM tCD=
. L’équation (4) devient :
|| ||AC CM R+ <
Soit || ||AM R<
pour tout M situé sur le segment [CD’] (équation 5)
Étape 2 :
Soit H la projection orthogonale de A sur la droite (CD’). (Figure 24)
Supposons dans un premier temps, [ ]1M M CH= ∈
Figure 24 : Triangle (ACD') avec M variant sur [CD']
Recherche de Voisinages Proches
-69-
D’après le théorème de Pythagore :
2 2 21 1AH HM AM+ =
2 21,Or HM HC< Donc,
2 2 21AH HC AM+ > (1)
De même, d’après le théorème de Pythagore : 2 2 2AH HC AC+ = (2)
D’après (1) et (2) : 2 21AC AM> c’est-à-dire 1AM AM AC= <
Supposons désormais que [ ]2 'M M D H= ∈
De la même manière que précédemment : 2 2 22 2AM AH HM= +
2 2 22 2
2 2 2 2 22
Donc ' car '
Soit ' car ' ' (Théorème de Pythagore)
AM AH HD HM HDAM AD AD AH HD
< + <
< = +
Donc, 2 'AM AM AD= < Dans les deux cas, on a donc ( , ')AM Max AC AD< Remarque :
Dans le cas où C (resp. D’) [ ]'D H∈ (resp. [HC]), la preuve reste valide:
Recherche de Voisinages Proches
-70-
Figure 25 : Cas où C appartient au segment [D'H] et D’ appartient à [HC].
En effet, pour tout [ ]'M CD∈ , [ ]'M D H∈ et donc AM<AD’ (cf. 2ème hypothèse traitée ci-dessus) (resp. AM<AC)
Cas dégénéré : A,C,D’ alignés (Figure 26)
Figure 26: Cas des points A, C et D' alignés
Cas1 : A à gauche de C (point A1) alors [ ]' < 'M CD AM AD∀ ∈
Cas 2: A à droite de D’ (point A1) alors [ ]' < M CD AM AC∀ ∈
Cas 3: A entre C et D’ (point A2) alors [ ]' < M CD AM AC∀ ∈ (M entre C et A) ou AM<AD’
(M entre A et D’).
Recherche de Voisinages Proches
-71-
Donc, dans tous les cas AM<Max(AC,AD’)
3.2.5 Calcul de l’intervalle de connectivité – CI
L’intervalle de connectivité (CI), représente l’union des intervalles de connectivité entre deux
nœuds. Pour la simplicité, nous considérons uniquement le plus grand intervalle de connectivité.
( )SI
jj SI
CI Max CI+
−=
=
À partir de l’intervalle de connectivité (CI) de borne inférieure CI- et de borne supérieure CI+, la
durée de connectivité (ECD) est calculée (CI+ - CI-).
Fonction Similarité_Spatiale(Tp, Tq)
Cet algorithme mesure la similarité spatiale de deux trajectoires. Il retourne la durée de connectivité notée ECD et l’intervalle de connectivité notée CI. Entrées:
Tp = {<p0, tp0>, <p1, tp1>, ..., <pn, tpn>} Tq = {<q0, tq0>, <q1, tq1>, ..., <qm, tqm>}
Sortie :
ECD : la durée de connectivité estimée CI : Intervalle de connectivité
Début
1. (SI-, SI+) = Similarité_Temporelle([tp0, tpn], [tq0, tqm]) 2. Si (SI- < > Null et SI+ < > Null) Alors 3. T’ = Interpolation_linéaire(Tq, Tp) = {<p’0, t’p0>, <p’1, t’p1>, ..., <p’n, t’n>} 4. // T’ = Interpolation linéaire de Tp par rapport à la trajectoire Tq) 5. Initialisation Tab similarité [i] // pour tout i allant de 0 à n, initialisation i = 0 ; 6. Pour tout i = 0 à n-1 Faire 7. // Calcul de la similarité entre (pi, pi+1) et (p’i, p’i+1) 8. D(pi, p’i) = la distance Euclidienne des points pi, p’i 9. D(pi+1, p’i+1) = la distance Euclidienne des points pi+1, p’i+1
Recherche de Voisinages Proches
-72-
10. // Calculer la distance Maximale de deux distances D(pi, p’i) et D(pi+1, p’i+1) 11. DMax = Max(D(pi, p’i) D(pi+1, p’i+1)) 12. Si DMax < R Alors // R = rayon de transmission radio 13. Similarité[i] = 1 14. Fin Si 15. Pour tout 16. Fin Si 17. (i_début, i_fin) = Extraire du tableau Similarité [ ], la série de ‘1’ contigus la plus longue 18. CI = [tpi_fin - tpi_debut] // les instants de début et de la fin de la connectivité 19. ECD = tpi_fin - tpi_debut 20. Retourner (ECD, CI)
Fin
3.3 CONCLUSION
Dans ce chapitre, nous avons présenté une nouvelle approche de calcul de voisinages
proches. Nous avons appelé cette méthode de voisinages proches, TQ (Trajectory Queries).
La durée de connectivité dans la méthode TQ est calculée grâce aux mesures de similarité
spatio-temporelles des trajectoires futures. La méthode TQ permet de trouver un ensemble de
nœuds capables de garantir une communication fiable dans des réseaux fortement dynamiques.
L’avantage de la méthode TQ apparaît dans le mécanisme de construction des chemins de
routage (chapitre 4 suivant). En effet, la construction des chemins ne s’effectuera pas d’une
manière aléatoire, mais à partir des nœuds garantissant une durée de connectivité acceptable
pour assurer une communication fiable avec le véhicule source (émetteur de la requête).
Dans le chapitre suivant, nous présentons en détail le protocole de routage géo-multipoint DG-
CastoR. L’objectif principal du protocole DG-CastoR est de disséminer les requêtes vers un
Recherche de Voisinages Proches
-73-
ensemble de nœuds appartenant aux TQ, c’est-à-dire, capables d’assurer une communication
fiable et d’une durée significative avec le véhicule source.
-75-
CHAPITRE 4
DG-CastoR : UN PROTOCOLE DE
ROUTAGE GÉO-MULTIPOINT HYBRIDE
4.1 INTRODUCTION
Dans les VANETs, la communication véhicule-à-véhicule (VàV) est rendue nécessaire
en l’absence d’infrastructure ou d’unités stationnaires. Néanmoins, le maintien d’une
communication véhicule-à-véhicule est difficile en raison de la forte mobilité des véhicules
(appelés aussi nœuds) dans le réseau. Outre une forte mobilité, les nœuds dans un VANET
risquent de quitter le réseau d’une manière spontanée ; ce qui peut provoquer une rupture du
chemin de routage et donc une discontinuité de la communication.
DG-CastoR : Protocole Géo-Multipoint Hybride
-76-
Dans ce chapitre, nous nous intéressons à l’étude de l’impact de la mobilité sur la
communication inter-véhicules. Notre étude se focalise plus particulièrement sur les problèmes
de communication caractéristiques des applications de transfert de données volumineuses.
L’objectif principal de ces applications est de transférer des données de grande taille entre les
véhicules. Or, pour un transfert abouti, une communication fiable est nécessaire entre les
véhicules émetteur/récepteur.
De plus, rappelons également qu’une application de partage de données volumineuses
(exemple : application multimédia) est composée de deux étapes de routage de paquets (Figure
25). La première étape consiste à disséminer la demande (Requête) dans le réseau (chemin S-A-
B-D); cette étape est ensuite suivie du transfert de données (Réponse) sur le chemin de routage
inverse (chemin (D-B-A-S) dans la Figure 25).
Figure 27 : Chemin de routage construit pour la dissémination et le transfert des données
La dissémination atteint un ensemble de nœuds (donc suit plusieurs chemins de routage) ; tandis
que la réponse ne suit qu’un seul chemin.
Dans un réseau ad hoc de véhicules, une communication multi-sauts présente les problèmes
suivants :
• Le chemin de routage multi-sauts doit être maintenu jusqu’à la fin du transfert des
données. Les données à transférer étant de grande taille, la transmission nécessite une
durée non négligeable. Cette durée peut être estimée en considérant à la taille du fichier
et à la capacité disponible de la bande passante.
DG-CastoR : Protocole Géo-Multipoint Hybride
-77-
• Les chemins de routage multi-sauts construits dans les réseaux VANETs risquent de
s’interrompre en raison de la forte mobilité des véhicules. Ainsi, des mécanismes de
maintien de la connectivité sont nécessaires pour assurer la fiabilité de la communication
entre les véhicules impliqués. Or, les mécanismes de maintien et de reconfiguration, s’ils
sont appliqués trop souvent, provoquent une surcharge dans le réseau (envoi périodique
des paquets de contrôle sur les chemins de routage).
En résumé, un protocole de routage adapté aux réseaux ad hoc de véhicules doit donc garantir
une communication fiable dans les deux sens de routage (requête/réponse), tout en réduisant le
nombre de mises-à-jour sur les chemins de routage.
Dans ce cadre, face à ce défi, nous proposons un nouveau protocole géo-multipoint hybride,
baptisé DG-CastoR (Direction-based Geocast Routing) [61, 62]. Pour chaque requête à
disséminer dans le réseau, le protocole DG-CastoR construit une colonie de nœuds capables de
communiquer directement avec le nœud source de la requête. Par définition, une colonie est un
recouvrement virtuel (overlay) partiel de la topologie physique du réseau. À l’issue de la
construction de la colonie, la dissémination s’effectue alors uniquement vers les nœuds
appartenant à la colonie.
La colonie construite par DG-CastoR comporte le nœud source ainsi qu’un ensemble de nœuds
capables d’assurer une communication fiable avec le nœud source (nœuds appartenant aux TQ).
Les nœuds appartenant à la colonie sont appelés agents et le nœud source de la requête est
appelé maître agent. L’importance de la colonie apparaît durant la phase de transmission des
données. En effet, les agents étant reliés par un lien logique avec le maître agent, ils sont alors
facilement localisés dans un environnement fortement dynamique.
La colonie, pour qu’elle soit adaptée aux réseaux fortement dynamiques, prend en compte deux
points importants lors de sa construction :
1. Chaque chemin de routage virtuel construit au niveau applicatif correspond à un chemin
physique équivalent au niveau réseau. Dans l’exemple de la Figure 26, les nœuds « S »
DG-CastoR : Protocole Géo-Multipoint Hybride
-78-
et « D » sont interconnectés par un lien logique direct au niveau overlay. Cependant, un
paquet envoyé de « S » pour atteindre le nœud « D », parcourt le chemin de routage
établi au niveau réseau composé des nœuds (S-A-B-D).
Figure 28 : Représentation du lien logique et les liens physiques équivalents
En raison de la forte mobilité des nœuds dans un VANET, les chemins de routage
subissent des reconfigurations fréquentes. Cet aspect dynamique complexifie le routage
au niveau des liens physiques. Par conséquent, il est important que le protocole de
routage appliqué dans l’overlay (colonie dans ce travail) prenne en considération la
topologie physique du réseau.
2. Le second point important à considérer lors de la construction de la colonie est le
maintien des liens virtuels de la topologie overlay. Pour réduire des reconfigurations trop
fréquentes des liens logiques, la mobilité des nœuds doit être prise en compte, a priori,
afin de garantir une construction stable de la colonie, dans un réseau fortement
dynamique.
DG-CastoR : Protocole Géo-Multipoint Hybride
-79-
Comme nous verrons dans les sections suivantes, la colonie construite par le protocole DG-
CastoR répond à ces deux points soulevés ci-haut. D’une part, la topologie physique est prise en
considération ; d’autre part, aucune reconfiguration n’est nécessaire lorsqu’un nœud quitte la
colonie.
4.2 FONCTIONNEMENT GLOBAL DU PROTOCOLE GÉO-
MULTIPOINT : DG-CastoR
La colonie proposée dans cette thèse est construite lors de la dissémination d’une requête
dans le réseau VANET (Figure 27). La requête est envoyée à un ensemble de nœuds
sélectionnés selon des critères précis. Une diffusion épidémique de la requête est ainsi évitée.
Dans DG-CastoR, l’ensemble des nœuds récepteurs de la requête appartiennent aux TQ du
nœud source. Rappelons que les nœuds appartenant aux TQ sont ceux dont la trajectoire est
proche de celle du nœud source, c’est-à-dire dont la durée de connectivité future estimée est
supérieure à la durée de connectivité minimale11. Ces nœuds sont donc candidats pour
communiquer à un-saut avec le nœud source dans un futur proche. La sélection de ces nœuds à
partir de la table de voisinage direct s’effectue grâce aux mesures de similarité spatio-
temporelles détaillées dans le chapitre 3.
Dans les réseaux ad hoc, chaque nœud connaît ses voisins directs, c’est-à-dire ceux dans son
rayon de transmission radio. Ainsi, la table de voisinage de chaque nœud comporte les
informations des voisins directs (identificateurs). Dans cette thèse, nous supposons que les
nœuds s’échangent également les informations géographiques (trajectoires futures des nœud).
11 La durée minimale peut être calculée en fonction des contraintes imposées par l’application (exemple : type du fichier multimédia à transmettre (audio, vidéo, image), ainsi que en fonction de la capacité de la bande passante.
DG-CastoR : Protocole Géo-Multipoint Hybride
-80-
La table de voisinage d’un nœud comporte alors les identificateurs ainsi que les informations
géographiques des nœuds voisins directs. (L’échange des paquets périodiques est détaillé dans
la section 4.3.1).
Figure 29 : Fonctionnement global du protocole DG-CastoR
Afin de mieux expliquer le fonctionnement global du protocole de routage DG-CastoR,
considérons l’exemple de la Figure 27. À partir du nœud source « S », la construction de la
colonie est déclenchée. Le nœud source « S » consulte alors sa table de voisinage, pour
sélectionner les TQ. La table de voisinage est composée essentiellement des identificateurs
(Node_ID) et des informations géographiques (MobilityInfo) des nœuds voisins. Supposons que
les nœuds 2 et 3 soient les seuls nœuds dans la table de voisinage de « S » capables de
communiquer à un-saut avec le nœud source « S » pendant une durée acceptable. Les nœuds 2
et 3 reçoivent alors une invitation d’adhésion à la colonie ; cette invitation est tout de suite
suivie de l’envoi de la requête. Les nœuds récepteurs de la requête, appelés « agents » (tous
membres de la colonie), jouent le rôle d’agents retransmetteurs (forwarders) et suivent la même
démarche de dissémination de la requête. L’objectif de cette retransmission est d’élargir
l’espace de recherche et donc d’augmenter le nombre d’agents dans la colonie. Dans l’exemple
DG-CastoR : Protocole Géo-Multipoint Hybride
-81-
de la Figure 27, l’agent 3, retransmetteur de la requête, choisit d’après sa table de voisinage les
TQ, ici les nœuds 4, 6 et 7 (même structure de table de voisinage que celle du nœud « S »).
Précisons que les similarités sont mesurées toujours par rapport à la trajectoire du nœud source.
La retransmission de la requête continue dans le réseau jusqu’à ce qu’aucune similarité de
trajectoire ne soit détectée (c’est-à-dire TQ= ø).
La topologie de la colonie se présente en forme d’étoile centrée sur le nœud source émetteur de
la requête. Nous appelons ce nœud « maître agent » (Figure 28). Ainsi, les agents sont
directement reliés au maître agent par un lien logique. La construction de la colonie s’effectue
d’une manière implicite. En effet, la requête étant diffusée (par retransmission) dans le réseau,
le maître agent ne connaît pas les agents de sa colonie, puisqu’aucune réponse de confirmation
d’adhésion ou de réception n’est retournée au maître agent. Par contre, les agents savent s’ils
appartiennent à la colonie du maître agent (colonie identifiée par l’identificateur du maître agent
et l’identificateur de la colonie mentionnés dans le message d’adhésion reçu). D’où l’aspect
implicite de la topologie étoile de la colonie.
DG-CastoR : Protocole Géo-Multipoint Hybride
-82-
Figure 30 : Topologie étoile de la colonie de "S"
La communication entre le maître agent et l’agent s’établit en mode unicast à un saut, lorsque le
maître agent et l’agent deviennent à portée radio l’un de l’autre, c’est-à-dire au moment où
l’agent détecte la présence du maître agent dans son voisinage direct.
Dans la section suivante, nous présentons en détail les étapes de la construction d’une colonie
ainsi que le mécanisme de dissémination d’une requête vers les nœuds appartenant à cette
colonie.
DG-CastoR : Protocole Géo-Multipoint Hybride
-83-
4.3 MÉCANISMES DE CONSTRUCTION DE COLONIES ET
DE DISSÉMINATION DE REQUÊTES
Le mécanisme de construction de colonie s’effectue via la diffusion d’une invitation d’adhésion.
Cette invitation s’adresse aux nœuds appartenant aux TQ (c’est-à-dire, les nœuds dont la
trajectoire est proche de la trajectoire du nœud source). Il est donc nécessaire pour sélectionner
à partir de la table de voisinage les nœuds candidats, de connaître leurs données géographiques
futures.
4.3.1 Échange périodique de paquets d’information
Un VANET est un réseau décentralisé dans lequel chaque nœud se comporte d’une manière
autonome. Par hypothèse, nous supposons que les nœuds ont une connaissance partielle de la
topologie du réseau, donc chaque nœud connaît seulement ses voisins directs (nœuds à portée
radio). Toutefois, d’autres informations utiles peuvent être échangées pour améliorer la
communication entre les nœuds dans un environnement fortement dynamique. En particulier,
nous proposons que les véhicules s’échangent aussi leurs données géographiques (trajectoires)
futures récupérées d’un système de navigation. Cette hypothèse concernant la récupération de
données géographiques est aujourd’hui réaliste, puisque quasiment tous les véhicules neufs sont
(ou seront dans un futur proche) équipés d’un système de géo-localisation.
Les informations géographiques des nœuds sont échangées entre les véhicules à portée radio
(voisinage direct). Dans ce contexte, nous introduisons le paquet de diffusion GeoInfo qui se
présente sous deux types : GeoInfo-0 (Type 0) et GeoInfo-1 (Type 1).
DG-CastoR : Protocole Géo-Multipoint Hybride
-84-
• GeoInfo-0 : contient uniquement les informations géographiques futures du nœud
considéré. Ces informations sont échangées périodiquement entre les nœuds qui sont
en voisinage direct. Les informations extraites du paquet GeoInfo-0, sont collectées
et sauvegardées dans la table de voisinage du véhicule concerné.
• GeoInfo-1 : comporte, outre les informations géographiques futures du nœud, les
informations nécessaires à la construction de la colonie.
4.3.1.1 Le paquet de diffusion périodique GeoInfo Type 0
Le paquet GeoInfo Type 0 (GeoInfo-0) est diffusé avec une limite de propagation de 1 (TTL12
=1), c’est-à-dire adressée uniquement aux nœuds à portée radio du nœud émetteur. Les champs
du paquet GeoInfo-0 sont :
• Type : type du paquet GeoInfo. Ce champ comporte la valeur ‘0’ou ‘1’, pour déterminer
le type des paquets GeoInfo-0 ou GeoInfo-1 respectivement.
• Sender_ID : identificateur unique du nœud émetteur du paquet (exemple : adresse MAC
unique)
• GeoInfo_Interval : nombre de secondes à attendre avant de retransmettre le paquet aux
nœuds dans la zone de transmission (envoi périodique du paquet)
• ColoniesList [Colonie_ID] : liste des identificateurs des colonies déjà construites
auxquelles le nœud émetteur du paquet appartient. Chaque colonie possède un
identificateur unique Colonie_ID.
Si le nœud émetteur du paquet est le nœud source de la requête, ayant déclenché la
création de la colonie Colonie_ID, un indicateur (flag) est ajouté dans le champ
ColoniesList [Colonie_ID, flag]. Cet indicateur, s’il est mis à 1 indique que le nœud
12 TTL : Time To Live
DG-CastoR : Protocole Géo-Multipoint Hybride
-85-
source est en cours de recherche des données réponses à sa requête. En revanche, si
l’indicateur est mis à ‘0’ soit: (1) le nœud source reçoit la totalité des données
recherchées, soit (2) le nœud source annule sa demande.
• MobilityInfo (Traj, Tstamps, Interval [S,E]) : informations géographiques du nœud
émetteur, incluant sa trajectoire (Traj) ; les périodes (Tstamps)13 qui représentent le
temps écoulé entre deux positionnements de trajectoires successifs enregistrés ; enfin,
l’intervalle de temps de la trajectoire (Interval) comportant un temps de début (S)14 et un
temps de fin (E)15.
Extraites du paquet GeoInfo, ces informations sont sauvegardées dans la table de voisinage pour
être utilisées, plus tard, dans le mécanisme de construction de colonies ainsi que lors de la
dissémination de requêtes.
Ainsi, la table de voisinage comporte les champs suivants : Sender_ID, MobilityInfo et
ColoniesList [Colonie_ID].
4.3.1.2 Le paquet de diffusion périodique GeoInfo Type 1
Le paquet GeoInfo-1 sert à la construction des colonies. C’est grâce à ce paquet que l’invitation
d’adhésion à une colonie est lancée par le nœud source puis propagée dans le réseau.
Cependant, pour réduire le nombre de paquets diffusés dans le réseau, nous proposons d’utiliser
le même paquet GeoInfo-0 en ajoutant les informations supplémentaires nécessaires pour la
construction de la colonie. Nous parlons donc de paquet GeoInfo de Type 1, ou simplement
13 Tstamps correspondent à δ dans le chapitre 3 14 S correspond à I- dans le chapitre 3 15 E correspond à I+ dans le chapitre 3
DG-CastoR : Protocole Géo-Multipoint Hybride
-86-
GeoInfo-1. Le format du paquet, comporte outre les champs du paquet GeoInfo-0, les champs
suivants :
• Colonie_ID : identificateur unique de la colonie dont l’initiateur est le nœud source.
• CJoin_Req : Invitation d’adhésion à la colonie, adressée aux nœuds appartenant à la liste
CMembersList.
• CMembersList [Node_ID] : comporte les identificateurs des nœuds appartenant à la liste
TQ (ces nœuds sont sélectionnés à partir des mesures de similarité spatio-temporelle des
trajectoires).
• MobilityInfo_Src (Src_ID, Src_Tstamps, Src_Traj, Src_Interval [S, E]) : informations
géographiques du nœud source. Chaque nœud, à la réception de l’invitation d’adhésion à
la colonie, joue le rôle de nœud retransmetteur et participe à la retransmission du paquet
vers les nœuds qui sont dans son voisinage direct. Les informations géographiques
(MobilityInfo_Src) du nœud source sont utilisées par le nœud retransmetteur pour
sélectionner dans sa table de voisinage les nœuds TQ du nœud source (nœuds dont la
trajectoire est proche de celle du nœud source).
Contrairement aux paquets GeoInfo-0 envoyés périodiquement à chaque GeoInfo_Interval,
GeoInfo-1 est diffusé une seule fois vers les nœuds qui sont à portée radio du nœud source (ou
éventuellement du nœud retransmetteur). Les informations ajoutées dans le paquet GeoInfo-1,
servent uniquement à la construction de la colonie. Il n’est donc pas nécessaire d’envoyer
l’invitation d’adhésion périodiquement aux nœuds qui ont déjà reçu l’invitation, et qui ont déjà
adhéré à la colonie. Ainsi, la valeur de GeoInfo_Interval est mise à 0.
Par ailleurs, lorsque l’émetteur du paquet GeoInfo-1 correspond au nœud source (initiateur de la
construction de la colonie), le champ MobilityInfo_Src (Src_ID, Src_Traj, Src_Tsamps,
Src_Interval [S, E]) reste vide pour réduire les redondances d’information dans le même paquet
(ces informations sont déjà mentionnées dans le paquet, par les champs Sender_ID et
MobilityInfo).
DG-CastoR : Protocole Géo-Multipoint Hybride
-87-
Nous présentons dans ce qui suit, les algorithmes de sélection des TQ et de génération du paquet
GeoInfo-1.
Fonction Générer_GeoInfo-1(SenderNeighborTable, SrcNode, μ) Cet algorithme est exécuté par le nœud source (SrcNode) pour générer le message GeoInfo-1 utilisé pour
Fonction TQ (SenderNeighborTable, SrcNode, μ) Cet algorithme est d’abord exécuté par le nœud source de la requête ; ensuite il est exécuté par chaque nœud à la réception du message GeoInfo-1. Il détermine parmi les nœuds voisins du nœud exécutant l’algorithme (i.e. les nœuds présents dans sa SenderNeighborTable), ceux ayant une trajectoire proche de la trajectoire du nœud source. Il retourne la liste TQ constituée de ces nœuds.
Entrées : SenderNeighborTable[Node(ID, MobilityInfo[Traj,Tstamps Interval], ColoniesList[Colonie_ID])] : Table de voisinage du nœud exécutant l’algorithme SrcNode(ID, MobilityInfo[Traj, Tstamps Interval,]) : Nœud source de la requête μ : durée de connectivité minimale tolérée
Sortie : TQ : liste des candidats à l’adhésion à la colonie créée par le nœud source (SrcNode) Début
1. TQ = ø // initialisation de la liste TQ 2. // Construction de la liste TQ 3. Pour tout Node dans SenderNeighborTable Faire 4. // Calculer la durée de connectivité à l’aide des mesures de similarité spatio-temporelle 5. // présentées dans le chapitre 3. 6. ECD = Similarité_Spatiale(Node.MobilityInfo, SrcNode.MobilityInfo) 7. Si ECD > μ Alors 8. Ajouter Node.ID dans la liste TQ 9. Fin Si 10. Fin Pour tout 11. Retourner TQ
Fin
DG-CastoR : Protocole Géo-Multipoint Hybride
-88-
la construction de la colonie. Cet algorithme retourne, le message GeoInfo-1 à transmettre aux nœuds voisins directs du nœud source.
Entrées :
SenderNeighborTable[Node(ID, MobilityInfo[Traj,Interval,Tstamps], ColoniesList[Colonie_ID])] : Table de voisinage du nœud source exécutant l’algorithme SrcNode(ID, MobilityInfo[Traj, Interval, Tstamps]) : Nœud source de la requête μ : durée de connectivité minimale tolérée
Sortie :
GeoInfo-1 : message GeoInfo-1
Début
1. // Génération du paquet GeoInfo-1 2. Colonie_ID = Generate_uniqueID; //générer un identificateur unique de la colonie 3. Type = 1 ; // Type = 1 correspond au paquet GeoInfo-1 4. GeoInfo_Interval = 0 // paquet envoyé une seule fois, intervalle = 0 5. CMembersList = TQ (SenderNeighborTable, SrcNode, μ) 6. // liste des candidats retournés par la fonction TQ 7. Construire Msg GeoInfo-1 (Type, SenderNode_ID, SenderNodeMobilityInfo, GeoInfo_Interval,
ColonieList, Colonie_ID, CMembersList, CJoin_Req, MobilityInfo_Src) 8. // CJoin_Req : flag de valeur 0 ou 1 qui détermine l’adhésion (1) ou le rejet (0) du paquet 9. Retourner GeoInfo-1 // Fin génération du message GeoInfo-1
Fin
4.3.2 Mécanisme d’adhésion à la colonie Un nœud, quand il reçoit le paquet GeoInfo-1, rejoint la colonie (i.e. il devient agent dans la
colonie) seulement lorsque son identificateur figure dans la liste CMembersList. L’identificateur
de la colonie (Colonie_ID) est ensuite ajouté à la liste ColoniesList du nœud adhérant (agent).
L’agent modifie alors les informations dans le paquet avant de le retransmettre aux nœuds dans
son voisinage direct : - l’identificateur de l’émetteur est remplacé par l’identificateur de l’agent
retransmetteur, - les identificateurs des nœuds dans le champ CMembersList sont également
modifiés et remplacés par les nœuds présents dans la table de voisinage du nœud agent qui
appartiennent à TQ, (rappel : la recherche des TQ s’effectue toujours par rapport aux données
géographiques du nœud source (maître agent)).
DG-CastoR : Protocole Géo-Multipoint Hybride
-89-
En raison de la diffusion broadcast de l’invitation d’adhésion, nous distinguons deux catégories
de nœuds récepteurs du paquet GeoInfo-1 : les récepteurs passifs et les retransmetteurs. Les
nœuds récepteurs passifs n’adhérent pas à la colonie puisque leur identificateur ne figure pas
dans la liste CMembersList, et ils ne retransmettent donc pas le paquet vers d’autres nœuds du
réseau. Par contre, les retransmetteurs sont les nœuds actifs qui adhérent à la colonie (i.e. ils
deviennent agents) et se chargent de retransmettre l’invitation d’adhésion (retransmission du
paquet GeoInfo-1). Ainsi, nous limitons la retransmission uniquement entre les nœuds
appartenant à l’ensemble de TQ. Il est généralement possible que le réseau VANET comporte
un grand nombre de nœuds ; une telle approche certes peut occasionner de perdre quelques
nœuds intéressants, mais elle limite beaucoup l’overhead.
Nous récapitulons dans l’algorithme ci-dessous, les étapes d’adhésion à la colonie.
Procédure PréRetransmissionMessage (GeoInfo-1, SenderNeighborTable, Node, μ)
Cet algorithme est exécuté par le nœud Node à la réception du message GeoInfo-1. Le nœud adhère ou non à la colonie, puis, en cas d’adhésion, les champs SenderNode et CMembersList du message, c’est-à-dire, à l’issue de l’exécution de la procédure PréRetransmissionMessage, le message modifié est diffusé en broadcast (i.e. vers tous les nœuds à un saut)
Entrées :
Node(ID, MobilityInfo[Traj, Tstamps, Interval], ColoniesList[Colonie_ID]) // nœud exécutant l’algorithme μ : durée minimale tolérée de connectivité
Entrée/ Sortie :
GeoInfo-1(Type, SenderNode_ID, SenderNodeMobilityInfo, GeoInfo_Interval, ColonieList,
Colonie_ID, CMembersList, CJoin_Req, MobilityInfo_Src)
//paquet GeoInfo-1 envoyé par le SrcNode à Node éventuellement modifié pour être retransmis
Début
1. Si (Node.ID ∈ GeoInfo-1.CMembersList) et (Count (Node.ColoniesList < 2)) Alors
2. // nous limitons à 2 le nombre de colonies à lesquelles le nœud peut adhérer simultanément
3. Ajouter GeoInfo-1.Colonie_ID dans Node.ColoniesList //adhérer à la colonie
4. // Modifier le paquet GeoInfo-1 avant de le retransmettre aux voisins directs (à un saut)
DG-CastoR : Protocole Géo-Multipoint Hybride
-90-
5. CMembersList = TQ (NodeNeighborTable, SrcNode, μ)
6. // la liste CMembersList contient les TQ sélectionnés de la table de voisinage du Node
7. // Modifier le message GeoInfo-1
8. GeoInfo-1.sender_ID = Node.ID
9. GeoInfo-1.CMembersList = CMembersList
10. GeoInfo-1.MobilityInfo_Src = Node(ID, MobilityInfo[Traj, Tstamps, Interval])
11. // les champs du message GeoInfo-1 (lignes 8,9, 10) sont présentés dans le chapitre 3
12. Sinon
13. Rejeter le paquet GeoInfo-1
14. Fin Si
Fin
4.3.3 Routage de requête dans la colonie
Les étapes de construction de la colonie et le routage de la requête s’effectuent d’une manière
simultanée et progressive dans le réseau. En effet, le nœud source (ou retransmetteur), après
avoir diffusé le paquet GeoInfo-1, envoie la requête aux nœuds appartenant à la liste
CMembersList. Ces nœuds à portée radio du nœud émetteur (source ou retransmetteur)
appartiennent à la même colonie en construction (nœuds TQ).
Lorsque le nœud émetteur de la requête est le nœud source, il génère un nouveau paquet
requête. En revanche, lorsque le nœud émetteur est un retransmetteur, le paquet requête reçu est
routé vers les nœuds récepteurs (seul l’identificateur du nœud émetteur est modifié dans l’entête
du paquet requête).
Le nœud appartenant à la colonie construite, à l’issue de l’exécution de la requête, prépare les
données qui répondent à la requête. Le nœud peut contenir la globalité du fichier, des fragments
du fichier ou aucune réponse correspondante à la requête. Dans tous les cas possible, le nœud
DG-CastoR : Protocole Géo-Multipoint Hybride
-91-
reste dans la colonie. Dans le chapitre 5 suivant, nous attribuons à chacun de ces nœuds un rôle
dans la colonie (Application CoFFee).
4.4 TOPOLOGIE ÉTOILE DE LA COLONIE
Le protocole DG-CastoR construit une colonie pour chaque requête disséminée dans le réseau.
Construite au niveau de la couche application, une colonie est composée d’un ensemble de
nœuds capables de contribuer à la réponse à une requête précise (il s’agit donc d’un sous-
ensemble des nœuds appartenant à l’ensemble TQ). Nous distinguons deux catégories de
nœuds : le nœud source de la requête appelé maître agent (m) et les autres nœuds appelés agents
(a) qui appartiennent à la colonie et sont donc reliés d’une liaison logique avec le maître agent
(m) de la colonie. Nous représentons une colonie comme suit :
{ | ( , , )} { }C a r m a p m= ∃ ∪
Où r (m,a,p) est un triplet composé du maître agent (m), de l’agent (a) et du poids (p) de la
liaison entre m et a. Une valeur de p = 1 signifie que les nœuds m et a sont à portée radio l’un
de l’autre, donc le lien entre les deux nœuds est un lien physique. À l’inverse, lorsque la valeur
de p est supérieure à 1, le lien entre les nœuds m et a est un lien logique (i.e. multi-sauts au
niveau physique), p étant le nombre de sauts.
Par exemple : p = 3 signifie que les nœuds m et a sont distants de 3sauts.
Au fur et à mesure que le maître agent m s’approche de l’agent a, la valeur de p diminue et le
transfert des données est lancé lorsque p devient égal à 1.
La colonie que nous venons de proposer dans cette thèse possède une topologie différente de
celles des overlays couramment adoptés dans les travaux de recherche existants (Tree-based,
Mesh-based).
DG-CastoR : Protocole Géo-Multipoint Hybride
-92-
La topologie de la colonie est en effet centrée sur le nœud source de la requête, (maître agent de
la colonie), qui est également l’initiateur de la construction de la colonie. La construction de la
colonie s’effectue en outre d’une manière implicite. En effet, le maître agent ne possède pas une
vue globale de la colonie construite (c’est-à-dire aucun message de confirmation d’adhésion
n’est retourné au maître agent). En revanche, d’après les informations du maître agent
mentionnées dans le paquet GeoInfo-1, les agents, à l’issue de l’adhésion à la colonie, créant un
lien logique avec le maître agent, ce lien logique exprime le fait qu’ils peuvent être amenés à
transmettre des données au maître agent en réponse à sa future requête. Ainsi, lorsqu’un agent
détecte la présence du maître agent dans sa zone de transmission radio, une communication
unicast direct est établie pour la transmission de données.
Toutefois, il est possible qu’un agent (ou le maître agent) rencontre dans son voisinage direct
d’autres agents appartenant à la même colonie. En effet, grâce à l’échange du paquet GeoInfo-0
(diffusion périodique du paquet vers les nœuds en voisinage direct), les colonies à lesquelles
l’agent appartient sont identifiées dans le champ ColoniesList[Colonie_ID]. Ainsi, les agents
(éventuellement le maître agent) peuvent avoir une vue partielle de la colonie.
4.4.1 Gestion des colonies dans le réseau overlay La dissémination de plusieurs requêtes dans le réseau, engendre la construction de plusieurs
colonies. Ainsi, un nœud peut appartenir simultanément à deux ou plusieurs colonies. Ce nœud
est alors appelé nœud pont, créant un maillage des colonies (Figure 29).
DG-CastoR : Protocole Géo-Multipoint Hybride
-93-
Figure 31 : Topologie étoile de la colonie
Nous introduisons quelques propriétés pour mieux présenter la structure maillée de la colonie :
• Un agent a peut devenir un agent pont ap de seulement deux colonies simultanément.
Nous proposons cette contrainte pour minimiser la charge processeur sur l’agent ainsi
que la charge sur la bande passante provoquée par le transfert de données.
• Un nœud peut être à la fois maître agent (m) dans une colonie et agent (a) dans une autre
colonie simultanément.
• Un nœud peut être maître agent (m) dans une seule colonie. En effet, lors de la
construction de la colonie, les données géographiques uniquement sont prises en
considération. Ainsi, un nœud qui lancerait simultanément plusieurs demandes de
construction de colonies, obtiendrait pratiquement la même colonie.
• Les agents appartenant à la même colonie peuvent communiquer et collaborer lorsqu’un
lien physique les relie (c’est-à-dire lorsqu’ils sont à portée radio l’un de l’autre). Dans ce
travail de thèse, aucune communication multi-sauts n’est utilisée.
• Un nœud source d’une requête de recherche d’information qui envoie sa demande sur le
réseau déclenche la construction d’une nouvelle colonie, et en devient le maître agent.
DG-CastoR : Protocole Géo-Multipoint Hybride
-94-
• Les nœuds mobiles adhèrent à une colonie lorsqu’ils reçoivent une requête. Le rôle
d’agent leur est alors attribué.
• Une colonie est construite pour un objectif précis, elle sera détruite dans l’un des cas
suivants :
o Lorsque le maître agent quitte le réseau (i.e lorsqu’il se déconnecte spontanément
du réseau – caractéristique majeure des réseaux ad hoc). Les agents considèrent
la colonie détruite lorsqu’ils ne rencontrent pas le maître agent à l’instant estimé
de la communication (cf. ‘Intervalle de connectivité’ – chapitre 3).
o Lorsque le maître agent annule sa demande (requête d’annulation).
o Lorsque le maître agent a reçu l’intégralité du fichier recherché, i.e. lorsque
l’objectif est atteint.
Dans les deux derniers cas mentionnés, la valeur du flag est mise à 0
ColoniesList[Colonie_ID, flag = 0] (section 4.3.1.1)
• Un nœud agent a peut quitter la colonie après avoir rencontré le nœud source (maître
agent) ; il peut également quitter la colonie d’une manière spontanée (caractéristique
majeure des réseaux ad hoc) ou lorsque le temps d’attente estimé (EWT expliqué dans
la section 4.4.2) est expiré. Ainsi, la dégradation de la colonie se fait au fur et à mesure
que le maître agent rencontre les agents de sa colonie.
4.4.2 États des liens dans le réseau overlay
L’algorithme de routage dans le protocole DG-CastoR, appliqué au niveau de la couche
application (niveau 7), prend en considération la topologie physique du réseau (niveau 3). Basé
sur ce principe, nous déduisons deux états de lien dans la topologie étoile que nous proposons :
physique (niveau 3) et logique (niveau 7).
DG-CastoR : Protocole Géo-Multipoint Hybride
-95-
Dans notre approche, le transfert de données se fait en communication directe (à un saut). Ceci
explique que la communication débute lorsque l’agent et le maître agent sont à portée radio l’un
de l’autre. Tous les agents dans une même colonie ont une durée de connectivité (supérieure à
un seuil ‘µ16’) avec le maître agent ; ces communications s’établissent au fur et à mesure que le
maître agent rencontre les agents de la colonie. (Figure 30).
Figure 32 : Communication unicast directe dans les colonies
Les nœuds agents d’une colonie peuvent avoir une estimation du moment de la transition d’état
d’un lien de logique à physique. Nous proposons d’utiliser deux valeurs d’estimation : - EWT
16 Le seuil µ indique la durée minimale de connectivité tolérée. Il peut être calculé en fonction de la taille du fichier recherché ainsi que de la capacité effective de la bande passante.
DG-CastoR : Protocole Géo-Multipoint Hybride
-96-
(Estimated Waiting Time), indique le temps d’attente estimé - ECD (Estimated Communication
Duration), indique la durée de connectivité estimée.
• EWT Estimated Waiting Time : C’est le temps d’attente estimé pour la transition du lien
virtuel en lien physique. Ce temps est calculé à partir de l’instant courant jusqu’à
l’instant où les deux nœuds (maître agent et agent) deviennent à portée radio l’un de
l’autre.
EWT = |Tdébut_connectivité – Tcourant_système|
Tdébut_connectivité est calculé par la méthode TQ (Chapitre 3).
• ECD Estimated Connectivity Duration : C’est la durée de connectivité directe entre le
nœud agent et le maître agent de la colonie. Cette durée est estimée par la mesure de
similarité spatio-temporelle de trajectoires (décrite dans Chapitre 3).
Les agents appartenant à une colonie attendent une durée EWT (Estimated Waiting Time) pour
commencer la communication avec le maître agent. Précisons que le transfert des données ne
commence qu’une fois la communication réellement établie. Cependant, plusieurs tentatives
peuvent être nécessaires, les trajectoires réelles des véhicules peuvent différer des trajectoires
estimés, utilisés lors du calcul de TQ (les premières tentatives de connexion sont, en pratique
réalisés quelques instants avant Tdébut_connectivité). Le type d’échange de données, que nous
proposons, entre deux nœuds est de type opportuniste, puisque l’agent attend l’instant
convenable pour lancer le transfert. Nous utilisons l’expression Carry, Wait et Send impliquant
respectivement que l’agent maintient les données (Carry), attend le changement de l’état du lien
de logique en physique (Wait), pour ensuite commencer le transfert direct avec le nœud maître
agent (Send).
Les avantages de la communication en mode unicast direct mise en œuvre sont :
• Ce type de communication directe entre les nœuds agent et maître agent minimise le
nombre d’opérations de maintien et les mises-à-jour des chemins de routage.
DG-CastoR : Protocole Géo-Multipoint Hybride
-97-
• Il garantit également un acheminement bout-à-bout des paquets réduisant ainsi les
risques de perte des paquets sur les chemins de routage multi-sauts.
• Il minimise l’usage de la bande passante, éliminant les envois multi-sauts.
Comme pour sa construction, la destruction d’une colonie est de même progressive. En effet,
lorsque la durée de la communication entre l’agent et le maître agent d’une même colonie est
épuisée, cela signifie que le nœud a fini sa mission dans la colonie. Comme nous l’avons
mentionné, la construction de la colonie est faite pour un but précis, donc la colonie a une nature
ad hoc, elle est dédiée à une mission particulière, celle de répondre à la requête et par la suite de
transférer les données recherchées. Sur un plan conceptuel, rien n’interdit d’utiliser une colonie
pour traiter plusieurs requêtes issues du même nœud source (un agent de la colonie peut
répondre à une ou plusieurs de ces requête). Cela impose cependant une complexification des
structures de données manipulées (non abordée dans cette thèse).
4.5 CONCLUSION
Les VANETs sont des environnements très dynamiques dans lesquels la topologie du réseau
subit des changements fréquents. La durée de connectivité entre les véhicules est réduite en
raison de leur forte mobilité dans le réseau. Ceci engendre des ruptures de liens sur les chemins
de routage, provoquant des pertes de paquets et une réduction de la qualité de service lors du
routage, essentiellement lorsque les paquets à envoyer sont de grande taille (par exemple
données multimédias).
Dans ce chapitre, nous avons présenté un protocole géo-multipoint hybride fondé sur la notion
de colonie (une colonie regroupe l’ensemble des nœuds ayant, dans le futur, une connectivité
significative avec le nœud de la requête), et un mécanisme de traitement de la requête
(dissémination de la requête puis transfert des données selon un mode Carry-Wait-Send) dans la
colonie construite. L’objectif principal de la construction de la colonie est de maintenir la
connectivité entre les nœuds d’une manière implicite (nœuds interconnectés par des liens
DG-CastoR : Protocole Géo-Multipoint Hybride
-98-
logiques). L’originalité de notre approche réside dans la construction implicite de la colonie. En
effet, le maître agent ne connaît pas les agents de sa colonie, puisque aucun message de
confirmation d’adhésion n’est retourné au maître agent. Il n’a donc pas une vue globale de la
structure de la colonie. Cependant, chaque nœud à l’issue de l’adhésion à la colonie crée à son
niveau, un lien logique avec le maître agent. Ainsi, la topologie de la colonie est en forme
d’étoile centrée sur le nœud source.
Un agent (ou maître agent) peut cependant avoir une vue partielle de la colonie lorsqu’il
rencontre dans son voisinage direct, des nœuds appartenant à la même colonie (grâce à l’envoi
périodique des paquets de gestion du réseau).
La colonie construite par le protocole DG-CastoR est adaptée aux réseaux fortement
dynamiques. En effet, les agents candidats à adhérer la colonie sont choisis par rapport à leurs
données géographiques (méthode TQ) de telle manière que chaque nœud possède une durée de
connectivité significative avec le maître agent de la colonie. De plus, la topologie étoile de la
colonie ne nécessite pas de mises-à-jour des liens lorsqu’un agent quitte la colonie.
Cette approche permet la communication fiable entre les nœuds tout en réduisant la complexité
du routage et en supprimant les reconfigurations de chemins de routage.
-103-
CHAPITRE 5
CoFFee : GESTION DE DONNÉES POUR LES RÉSEAUX AD HOC
5.1 INTRODUCTION
Les systèmes pair-à-pair (P2P – peer-to-peer) décentralisés ont rencontré un large succès
en tant qu’alternatives aux systèmes centralisés client/serveur traditionnels. À l’inverse des
systèmes centralisés, l’avantage majeur des systèmes décentralisés est que les données et les
ressources ne sont pas localisées sur un seul nœud (dit serveur), mais réparties sur plusieurs
nœuds participants. Les nœuds dans un système pair-à-pair décentralisé sont appelés des nœuds
servants, ce que signifie que chaque nœud joue à la fois le rôle de client et de serveur. Parmi les
systèmes pair-à-pair décentralisés les plus connus, citons, par exemple, GNutella [63], Chord
[64], CAN [65] et Freenet [66].
L’adaptation des systèmes pair-à-pair aux réseaux ad hoc exige principalement d’étudier
l’aspect dynamique du réseau, la limitation de la bande passante ainsi que les contraintes
d’énergie. Le protocole DG-CastoR (Chapitre 4) fournit un mécanisme de routage de requêtes et
CoFFee : Application de Gestion de Données
-104-
d’échange de données très efficace, spécialement conçu pour les VANETs.qui constituent une
classe spécifique de réseaux ad hoc pair-à-pair.
Néanmoins, l’acheminement bout-à-bout des données dans un système pair-à-pair ne dépend
pas uniquement du protocole de routage mais également de l’usage de la bande passante lors de
la transmission des données. Par exemple, lorsque la bande passante n’est pas utilisée
correctement, des collisions peuvent survenir, ce qui diminue la performance du protocole de
routage de données.
Dans ce chapitre, nous présentons une nouvelle application de gestion de la qualité de service,
baptisée CoFFee – Cooperative and inFrastructure-Free peer-to-peer [67]. CoFFee est basé sur
la coopération des nœuds dans la même colonie (construite par DG-CastoR) pour assurer la
qualité de service (QoS) lors de la transmission. Grâce au CoFFee, les nœuds d’une colonie
coopèrent (1) pour éviter les transmissions de données redondantes, (2) pour augmenter la
disponibilité des données rares (données peu présentes dans le réseau), enfin, (3) pour réduire la
charge sur la bande passante.
Dans ce cadre, CoFFee s’appuie sur deux services de coopération appliqués sur les flux de
données (par définition, les flux de données contiennent des fragments de données qui
répondent à la requête traitée): (1) un service de suppression du flux de données d’un agent
(nœud appartenant à une colonie), les paquets ayant déjà été transmis au nœud source par
d’autres agents de la même colonie ; (2) un service de réplication des données considérées
comme rares dans le réseau.
Plus précisément, l’application CoFFee est située au niveau de la couche application du modèle
OSI. Elle fonctionne dans les colonies construites par le protocole DG-CastoR. Tous les nœuds
disposant de l’application CoFFee peuvent coopérer pour améliorer l’acheminement des
données. Cette coopération est assurée entre les nœuds appartenant à la même colonie,
autrement dit, les nœuds qui répondent à une même requête. Avant d’expliquer en détail les
services de coopération dans CoFFee, illustrons la problématique traitée par la Figure 31. La
colonie en forme d’étoile, comporte 5 membres (A1, A2, A3, A4 et A5) reliés tous par un lien
CoFFee : Application de Gestion de Données
-105-
virtuel avec le nœud source MA1 (maître agent) excepté le nœud A1 qui est à portée radio du
nœud source (lien physique). D’après l’algorithme de transmission de données, chaque nœud
appartenant à la colonie prépare le flux de données qu’il doit transmettre à MA1 et attend la
transition de l’état du lien de virtuel à physique : c’est en effet à cet instant que les deux nœuds
(agent et maître agent) peuvent débuter le transfert du flux de données en mode unicast direct
(mode Carry-Wait-Send).
Figure 33: Topologie étoile de la colonie
Cependant, il est possible que la durée de transmission du flux de données dépasse la durée de
connectivité avec le maître agent durant la communication unicast. Appelons la durée de
transmission des données ETD – Estimated Transmission Duration et la durée de connectivité
ECD –Estimated Connectivity Duration (cette durée est fournie par les mesures de similarité
spatio-temporelle expliquées dans le chapitre 3). Lorsque, ECD dépasse ETD l’agent ne peut
pas transmettre la totalité des données du flux de données; cette rupture de transmission entraîne
une perte des données, réduisant clairement la qualité de service.
CoFFee : Application de Gestion de Données
-106-
C’est ici que CoFFee intervient. Grâce aux services proposés, le volume des données dans le
flux d’un agent peut être réduit selon les données dans les flux de données des agents
appartenant à la même colonie. Cette réduction de données contribue à la transmission de la
totalité des données au maître agent pendant la durée de connectivité estimée (ECD). Cette
amélioration est avantageuse non seulement pour l’acheminement des données bout-à-bout,
mais aussi pour favoriser l’usage de la bande passante lors de la transmission des paquets
(réduction des transmissions redondantes).
5.2 PARTIONNEMENT DES DONNÉES MULTIMÉDIAS
Les données multimédias sont des fichiers de grande taille ; il est donc difficile de
transmettre un fichier entier d’un nœud à un autre. Pour améliorer le mécanisme de transmission
des données, nous proposons de partitionner le fichier en plusieurs fragments disjoints comme
dans le système BitTorrent [68]. Cependant, le partitionnement du fichier dans le système
BitTorrent s’effectue à un seul niveau, autrement dit, le fichier est équitablement partitionné en
fragments (torrent).
Le type de partitionnement que nous adoptons dans notre travail se base sur le principe de
hiérarchisation à plusieurs niveaux, qui est simple et dynamique. Par défaut, un fichier F est
partitionné équitablement en N fragments (au niveau 0). Chaque fragment est transféré comme
un paquet indépendant vers le nœud destinataire.
Ces fragments peuvent être de nouveau partitionnés en M sous-fragments si nécessaire, lorsque
le nœud émetteur détecte une surcharge sur la bande passante ou une durée insuffisante pour
transférer de gros fragments. Nous supposons, tout d’abord, que M=N-1, puis, en cas de besoin
d’un nouveau partitionnement, nous décrémentons M de 1.
CoFFee : Application de Gestion de Données
-107-
D’autres techniques plus complexes de fragmentation de données multimédias peuvent aussi
être adoptées [69,70,71], mais elles ne sont pas abordées dans cette thèse.
Le fichier entier F représente la racine de l’arborescence (niveau 0) (voir Figure 32). Il est
subdivisé en N fragments, telle que la valeur de N est définie par rapport à la taille du fichier.
Elle sera décrémentée de 1 pour chaque sous-niveau. Ainsi, les descendants de chaque fragment
du niveau 1 sont subdivisés en N-1 sous-fragments. Les fragments feuilles de l’arborescence
sont divisés en N-k sous-fragments ( 2N k− ≥ ). Nous limitons la subdivision des fragments à
deux pour faciliter le mécanisme de réassemblage des fragments à la réception.
Dans l’exemple de la Figure 34, la valeur de N est fixée à 4 (nombre de fragments toléré au
niveau 1). F est donc subdivisé en 4 fragments (F1, F2, F3, F4). Ces fragments sont à leur tour
partitionnés en N-1 sous-fragments au niveau 2 ([F11, F12, F13], [F21, F22, F23], [F31, F32, F33],
[F41, F42, F43]). Au niveau 3, nous atteignons la valeur N-2=2, ce qui signifie que chaque
fragment du niveau 2 (exemple : F11) est subdivisé en 2 fragments ([F111, F112],…). La
subdivision s’arrête au niveau 3 avec N-k =2.
Figure 34 : Partitionnement hiérarchique du fichier F
Tous les fragments comportent un entête contenant un identificateur unique formé de
l’identificateur du fichier entier et de la position du fragment dans l’arborescence. Au
réassemblage, ces informations sont utilisées pour reconstituer le fichier.
CoFFee : Application de Gestion de Données
-108-
Dans l’exemple de la Figure 34, le fragment ascendant de F13 est le fragment F1. Les
descendants du fragment F3 sont F31, F32.
5.3 GESTION DE LA DISTRIBUTION DES DONNÉES
5.3.1 Catégorisation des nœuds dans une colonie
Les agents d’une même colonie sont classés en 3 catégories :
• Les agents racines (Root) : sont les agents contenant l’intégralité du fichier recherché
(réponse complète).
• Les agents porteurs (Holder) : sont ceux qui possèdent des fragments du fichier
recherché (réponse partielle).
• Les agents libres (Blank) : sont les agents qui ne possèdent aucune donnée répondant à
la requête. La présence des agents libres dans la colonie justifie la manière dont la
colonie est construite. En effet, les agents d’une colonie sont capables de communiquer
directement (mode unicast direct d’un saut) avec le nœud source sans un futur proche,
indépendamment du fait que les agents possèdent ou non le fichier recherché.
Les agents dits racines ou porteurs, comportent respectivement l’intégralité ou des fragments du
fichier recherché. Lorsqu’un agent est capable de transmettre la totalité du fichier, il attend que
l’état du lien avec le maître agent de sa colonie change de virtuel en physique ; puis il
commence le transfert des fragments en mode unicast direct (un-saut). En revanche, lorsque le
temps estimé de transfert des données dépasse la durée estimée de connectivité avec le maître
agent ; l’agent, racine ou porteur, va coopérer avec d’autres agents appartenant à la même
colonie. La coopération s’effectue de la manière suivante : les agents appartenant à la même
colonie, lorsqu’ils sont en voisinage direct, s’échangent les métadonnées de leur flux de
CoFFee : Application de Gestion de Données
-109-
données ; ainsi, chaque nœud aura une connaissance partielle des données existantes dans la
colonie. Grâce à cette information, l’agent peut appliquer les services d’amélioration lorsque
ECD < ETD.
5.3.2 Estimation de la durée de transmission (ETD)
La durée de transmission estimée représente la durée nécessaire au transfert du flux de données
depuis le nœud agent vers le maître agent de la colonie. Le transfert commence lorsque le lien
entre les deux devient un lien physique. Il s’agit d’une estimation, puisque la durée est calculée
par rapport à la capacité théorique de la bande passante et non pas par rapport à sa capacité
effective à l’instant de la transmission.
Ainsi, l’ETD entre le récepteur (R) et l’émetteur (E), notée ETD(R,E) est calculée par la formule
suivante :
1( )
( , )
n
ii
Max
SizeFETD R E
C==∑
où SizeFi représente la taille de chaque fragment dans le flux de données, et n représente le
nombre de fragments et CMax est la capacité effective de la bande passante et non pas sa capacité
théorique (6 Mbps pour IEEE802.11p). Cependant, une atténuation de la capacité de la bande
passante peut être provoquée par des surcharges (appelées aussi overhead) sur le canal ; ces
surcharges sont principalement provoquées par les messages de contrôles des protocoles de
routage, les protocoles de transport ainsi que par les messages de contrôle du support de la
couche liaison MAC.
CoFFee : Application de Gestion de Données
-110-
5.3.3 ALGORITHMES D’AMÉLIORATION DE PARTAGE DE
DONNÉES
Les algorithmes d’amélioration de partage de données représentés par les services de
suppression et de réplication sont appliqués sur les flux de données des agents. Comme nous
l’avons mentionné, grâce à l’échange des métadonnées entre les agents d’une même colonie, les
agents peuvent avoir une connaissance des données existantes dans la colonie, et la par suite
réduire du flux de données les fragments redondants. Les services d’amélioration sont appliqués
avant que l’agent rencontre le maître agent.
Dans ce qui suit, nous utilisons le terme Blist pour désigner le flux de données de l’agent. La
Blist contient des fragments de données répondant à la requête du maître agent de la colonie.
La Blist comporte des fragments différents selon le type de l’agent: s’il s’agit d’un agent
Racine, la Blist contient alors l’intégralité du fichier (niveau 0 de l’arborescence de
partitionnement) ; chaque fragment comporte dans son entête l’identificateur du fichier, ainsi
que sa position dans l’arborescence. La Blist de l’agent Porteur comporte un ensemble de
fragments de l’arborescence sans tenir compte du niveau de partitionnement. Enfin, la Blist d’un
agent Libre est vide ; l’agent libre est cependant un agent potentiel pour coopérer avec d’autres
agents de la même colonie (son rôle apparaît surtout dans l’action de réplication, section
5.3.3.2).
Avant de décrire en détail les services d’amélioration du partage des données, nous présentons
dans ce qui suit, les informations échangées entre les agents d’une même colonie, lorsqu’ils sont
à portée radio l’un de l’autre :
• La liste des identificateurs des fragments du fichier recherché possédés par l’agent
• La durée de connectivité estimée (ECD) avec le maître agent,
CoFFee : Application de Gestion de Données
-111-
• Le temps estimé de début de la communication, c’est-à-dire l’instant de la transition du
lien virtuel en lien physique (l’instant où l’agent et le maître agent seront à portée radio
l’un de l’autre).
Cet échange se fait uniquement entre les agents voisins concernés. Les nœuds appartenant à la
même colonie sont détectés grâce à l’identificateur de la colonie (Colonie_ID). Les informations
concernant les flux de données des agents de la même colonie sont sauvegardées dans la table
de voisinage.
Lorsqu’un agent détecte que la durée de transmission du flux de données estimée dépasse la
durée de connectivité avec l’agent maître, il consulte sa table de voisinage pour appliquer les
services d’amélioration (suppression et/ou réplication) sur son propre flux de données (son
Blist)
5.3.3.1 Services de suppression de fragments du flux de données :
Prune / DivideAndPrune
Le service prune élimine du flux de données tous les fragments transférables par d’autres
agents de la même colonie. Elle participe ainsi à l’amélioration de l’usage de la bande passante
en évitant la transmission des données d’une manière redondante.
Pour procéder au service de suppression des fragments, pour chaque fragment de Blist nous
recherchons dans la table de voisinage (parmi les agents de la même colonie) :
• Si le même fragment est transférable par un autre agent ai telle que ETD < ECD, ou
• Si le fragment ascendante est transférable, ou
• Si tous les fragments descendants sont transférables.
Lorsqu’une de ces 3 conditions est vérifiée, le fragment est supprimé du Blist.
CoFFee : Application de Gestion de Données
-112-
Il est probable qu’aucune de ces 3 conditions ne soit vérifiée, nous proposons alors un sous-
service de suppression, DivideAndPrune. Ce service subdivise d’abord le fragment en N-m sous-
fragments si seulement 2N m− ≥ (divide), ensuite le service de suppression est appliqué
(Prune).
Le service de suppression des fragments est présenté dans l’algorithme ci-dessous.
Procedure Suppression(Blist, NeighborTable, IdCol, Q)
Cet algorithme est exécuté lorsque la durée estimée de transmission du flux de données notée ETD dépasse la durée estimée de connectivité avec le nœud source notée ECD. Pour tout fragment dans sa Blist, le nœud exécutant l’algorithme cherche dans sa table de voisinage les nœuds qui contiennent et qui peuvent transmettre le fragment. Dans ce cas, le fragment est supprimé de la Blist du nœud (d’où une réduction de la durée estimée de transmission du flux de données). La procédure de suppression s’arrête lorsque ETD < ECD ou lorsque plus aucune suppression n’est possible.
Entrées :
NeighborTable (Node[ID, Blist, Colonie_ID]) : Table de voisinage du nœud N
IdCol : identificateur de la colonie
Q : nœud source de la requête
Entrée/Sortie :
Blist: Flux de données du noeud N
Début
1. TBlist = N.Blist // TBlist est une liste temporaire contenant tous les fragments de N.Blist
2. Tant que (ETD(N.Blist) > ECD(N,Q) Faire
3. // ECD(N,Q) retourne la durée de connectivité entre le nœud N et le nœud source Q
4. F = RetirerPremierFragment (TBlist)
5. Pour tout Node dans NeighborTable tel que Node.Colonie_ID = IdCol Faire
6. FragmentsTrouvés=((Chercher dans Node.Blist le fragment F ou le fragment ascendant de F
7. ou tous les fragments descendants du fragment F))
8. // cf. Schéma de partitionnement d’un fichier (fragments ascendants/descendants)
9. Si FragmentsTrouvés Alors
10. Supprimer F de N.Blist
11. Break // sortir de la boucle Pour tout Node
12. Fin Si
CoFFee : Application de Gestion de Données
-113-
13. Fin Pour tout
14. Fin Tant que
15. Retourner Blist
Fin
L’exécution de l’algorithme s’arrête lorsque ETD ≤ECD ou lorsque TBlist = ø c’est-à-dire lorsque tous les fragments ont été examinés
5.3.3.2 Services de réplication des fragments du flux de données :
Replicate / DivideAndReplicate Le mécanisme de réplication des données s’applique lorsque l’agent détecte qu’il possède dans
son flux de données des fragments rares ou peu disponibles chez d’autres agents. Un fragment
est détecté rare grâce à l’échange de la liste des identificateurs des fragments entres les nœuds
appartenant à la même colonie. L’intérêt du mécanisme de réplication est d’augmenter la
disponibilité des données dans le réseau. Dans CoFFee, un nœud (agent) procède à la réplication
lorsque strictement ces deux conditions sont vérifiées :
• le fragment est rare dans le réseau, et
• la durée de transmission du flux de données dépasse la durée de connectivité (le
fragment ne peut être transféré par cet agent).
La première étape de la réplication consiste à chercher des agents libres appartenant à la même
colonie. Ceci est réalisé grâce à l’échange périodique de la liste des identificateurs des données
entre les agents à portée radio et agents de la même colonie. Ainsi, un agent peut connaître la
Blist des agents dans son voisinage.
Les agents libres sont des agents qui a priori peuvent potentiellement récupérer des réplicas.
Nous distinguons deux états pour les agents libres : les agents disponibles complètement et ceux
disponibles partiellement.
CoFFee : Application de Gestion de Données
-114-
En effet, une condition nécessaire pour placer un réplica est d’avoir une durée de connectivité
suffisante entre les deux agents. De plus, une autre condition est que l’instant de connectivité
des deux agents doit précéder l’instant du début de communication avec le maître agent.
L’état de disponibilité complète signifie que la durée de connectivité entre l’agent souhaitant
déposer le réplica et l’agent libre est suffisante par rapport à la durée de transmission. Par
conséquent, le réplica peut être entièrement transféré en mode unicast direct vers l’agent libre,
c’est le service Replicate. Néanmoins, lorsque la durée de connectivité est insuffisante (état de
‘disponibilité partielle’), l’agent met en œuvre le service DivideAndReplicate : il divise le
fragment rare en sous-fragments d’après la structure de partitionnement du fichier et il ne
réplique qu’une partie des sous-fragments sur l’agent libre.
Avant de présenter l’algorithme de réplication, l’algorithme récursif ci-dessous détaille le
mécanisme de recherche d’agent libre dans la colonie.
Fonction Libre(NeighborTable, IdCol, Fragment)
Cet algorithme est exécuté par un nœud de la colonie pour chercher dans son voisinage direct un nœud libre. L’algorithme s’il trouve un nœud libre renvoie ce nœud et son état (‘disponible’, ‘partiel’) ; s’il ne trouve pas de nœud libre renvoie le nœud Null et la valeur d’état ‘non disponible’.
Entrées : NeighborTable (Node[ID, Blist, Colonie_ID]) : Table de voisinage du nœud exécutant l’algorithme IdCol : identifiant de la colonie Q : nœud source N : nœud exécutant l’algorithme Sorties: B : le nœud libre retourné ou Null Status : l’état du nœud libre (‘disponible ou ‘partiel) ou ‘not disponible’ si aucun nœud libre n’est trouvé Entrée/Sortie : Fragment : valeurs retournées – F ou f (fragment de F) ou Null
Début
1 Si Fragment = Null Alors 2 B = Null 3 Status = ‘non disponible’ 4 // renvoie de B, status et Fragment de valeurs nulles 5 Sinon
CoFFee : Application de Gestion de Données
-115-
6 Pour chaque Node dans NeighborTable tel que NodeColonie_ID = IdCol 7 Si Node.Blist = vide Alors 8 Si (ECD(N,Q) > ETD(F)) et (ECD(N,Node) > ETD(F)) et 9 (STC(Node,Q) après ETC(Node,N)) Alors 10 Status = 'Available' // capable de recevoir le fragment F 11 B = Node 12 Fragment = F 13 Break 14 // ECD(B,Q) retourne la durée de connectivité entre B et Q (idem pour ECD(N,B)) 15 // STC(B,Q) retourne le temps de début de la communication entre B et Q (Start time) 16 // ETC(B,N) retourne le temps de fin de la communication entre B et H (End time) 17 Sinon Si status < > ‘disponible’ Alors 18 f = diviser(F) // f étant un sous-fragment de F selon le schéma de partitionnement 19 (B, status, Fragment) = Libre (NeighborTable, IdCol, Fragment) 20 Si Status = ‘disponible’ Alors 21 Status = ‘partiel’ // modifier l’état 22 Fin Si 23 Fin Si 24 Fin Si 25 Fin Pour chaque 26 Fin Si 27 Retourner (B, status, Fragment)
Fin
Ci-dessous, l’algorithme de réplication de données (F) sur un nœud libre (B)
Procédure Réplication (F, N, B)
Cet algorithme est exécuté lorsqu’un nœud libre est retourné par la fonction libre. Il permet de placer le réplica F sur le nœud libre, donc l’ajouter dans sa Blist (B.Blist). Ce même fragment F est ensuite supprimé de la Blist du nœud N (exécuteur de l’algorithme).
Entrées :
F : Fragment à répliquer
N : Nœud qui exécute la réplication
B : Nœud libre // B est retourné par la fonction Libre.
Début
1. N.Blist - = F
2. B.Blist + = F
Fin
CoFFee : Application de Gestion de Données
-116-
Cette procédure peut être intégrée dans la fonction Libre.
5.4 AMÉLIORATION DE L’OCCUPATION DE LA BANDE
PASSANTE
La capacité de la bande passante est limitée dans les réseaux ad hoc. Le partage de la bande
passante par plusieurs nœuds provoque une atténuation de sa capacité et réduit par la suite la
qualité de service (par exemple : transfert incomplet des données, perte de paquets). De
nombreuses études proposent des algorithmes pour le partage du support de communication en
fonction de l’activité des nœuds dans le réseau (on parle d’allocation dynamique de la bande
passante). Dans ce travail, nous supposons que la bande passante est partagée équitablement
sans tenir compte de l’activité de chaque agent. Pour le standard IEEE 802.11p, la capacité
maximale est de 6 Mbps. Cette capacité maximale reste théorique puisque la bande passante est
susceptible d’être utilisée simultanément par plusieurs nœuds du réseau. Nous parlerons plus
loin de capacité effective attribuée au nœud à un instant « t » précis.
La qualité de service diminue également lorsque le chemin de routage entre le nœud source et le
nœud destinataire est long (plusieurs sauts). Notre proposition d’échanges de données se base
sur la communication unicast direct entre le nœud source et le nœud destinataire. Cette méthode
est avantageuse pour deux raisons essentielles: (1) elle permet de réduire la perte des paquets
sur le chemin de routage, puisque les paquets sont directement transmis entre les nœuds
concernés et un acquittement est envoyé au nœud émetteur lors de la réception des paquets ; (2)
elle permet également de ne pas abuser de la bande passante des nœuds voisins. À l’opposé,
dans une communication multi-sauts, lors de la retransmission des paquets sur le chemin de
CoFFee : Application de Gestion de Données
-117-
routage, la capacité de la bande passante des nœuds intermédiaires est utilisée, ce qui diminue la
capacité du réseau et augmente le délai lorsqu’un nœud souhaite émettre des données.
Pour conserver la bande passante du réseau, nous avons limité le nombre de colonies auxquelles
un agent peut appartenir à deux. En clair, nous supposons qu’un agent traite au maximum deux
requêtes pendant une même période de temps.
Dans l’application CoFFee, chaque agent calcule la durée de transmission des paquets de son
flux de données. Cette durée calculée est basée sur la capacité maximale théorique de la bande
passante. Lorsque la durée de transmission ETD dépasse la durée de communication ECD
directe avec le maître agent de la colonie, l’agent applique les services d’amélioration décrits
précédemment (DivideAndPrune, DivideAndReplicate), afin de supprimer de son flux de
données certains fragments. Dans CoFFee, la durée de transmission est estimée a priori, afin de
décider quels services d’amélioration mettre en œuvre. La durée estimée de transmission,
appelée EsTD est calculée comme suit :
Taille des paquets dans le flux de donnéesCapacité de la bande passantesE TD
théorique= ∑
EsTD correspond à ETD définie dans la section 5.3.2
Néanmoins, le débit réel de transmission dépend de la condition effective courante de la bande
passante. Lorsqu’une collision intervient, le débit diminue, entraînant l’augmentation de la
durée EsTD. Nous définissons la durée de transmission effective, EffTD, comme suit :
Taille des paquets dans le flux de donnéesCapacité de la bande passanteffE TD
disponible= ∑
La capacité disponible ou effective de la bande passante (BP disponible) est calculée comme
suit :
BP BP - BP disponible théorique utilisée=
CoFFee : Application de Gestion de Données
-118-
où, BP utilisée présente l’utilisation de la bande passante à l’instant (t).
Dans les meilleures conditions, lorsque la bande passante est totalement libre, EffTD est égale à
EsTD, sinon, ff sE TD E TD≤ .
Il est toutefois difficile de connaître l’état de la bande passante au moment de la transmission du
paquet. Ceci dépend surtout de la densité des nœuds dans le réseau ainsi que de leur activité sur
la bande passante. Cependant, des études d’estimation de la bande passante ont été proposées
[72, 73, 74] afin de garantir une qualité de service lors de la transmission des paquets. Une des
méthodes consiste à écouter la bande passante pendant un intervalle de temps et à estimer sa
disponibilité. La méthode est appelée ABE - Available Bandwidth Estimation [72] ; grâce à
l’échange périodique des paquets Hello entre les nœuds en voisinage direct, chaque nœud a une
connaissance partielle de l’état de la bande passante. Ainsi, le nœud est capable de calculer plus
précisément la durée de transmission nécessaire pour transférer la totalité du flux de données.
Dans l’application CoFFee, en premier lieu, l’agent prépare le flux de données (sa Blist), selon
la capacité de la bande passante maximale théorique attribuée. Si pour cette valeur maximale, la
durée de communication dépasse la durée de transmission, le nœud applique les actions
d’amélioration pour minimiser la taille du flux de données, et ainsi garantir un acheminement
bout-à-bout réussi. La première étape consiste à appliquer l’action de suppression, suivi de
l’action de réplication si nécessaire. Cependant, comme nous l’avons déjà mentionné, la
capacité théorique peut subir une atténuation à cause des collisions et des transmissions
simultanées sur la bande passante partagée. Afin d’améliorer encore plus l’acheminement des
paquets, et grâce aux méthodes d’estimation de la capacité disponible de la bande passante, le
nœud écoute le support et selon la capacité de la bande passante disponible, il peut être amené à
reprendre les actions d’amélioration, si nécessaire.
CoFFee : Application de Gestion de Données
-119-
5.5 CONCLUSION ET DISCUSSION
La qualité de service (QoS) est un concept important de gestion du réseau qui a pour but
d’optimiser les ressources du réseau, en vue d’optimiser le routage et l’acheminement bout-à-
bout des paquets, l’usage de la bande passante et la diminution des délais de transmission
L’application CoFFee a pour but d’assurer une qualité de service au niveau de la gestion du flux
de données. Dans ce contexte, CoFFee offre deux services d’amélioration des flux de données :
Un service de suppression et un service de réplication réactive. Le service de suppression
permet de supprimer dans le flux de données, les fragments de données redondantes dans le
réseau. En revanche, le service de réplication augmente la disponibilité des données rares dans
le réseau.
Les services de suppression et de réplication permettent d’optimiser l’usage de la bande
passante puisqu’ils contribuent à réduire le volume du flux de données.
CoFFee se différencie des systèmes pair-à-pair existants par sa fonctionnalité complètement
décentralisée et ad hoc. La décision de procéder aux services d’amélioration est
prise localement par le nœud agent. En effet, les actions sont appliquées avant que le maître
agent rencontre le nœud source pour débuter la communication. Le mécanisme de gestion des
données proposé dans CoFFee améliore ainsi l’usage de la bande passante afin de garantir un
acheminement bout-à-bout réussi des paquets.
-121-
CHAPITRE 6
EXPÉRIMENTATIONS ET RÉSULTATS
6.1 INTRODUCTION
Ce chapitre comporte deux séries d’expérimentations pour évaluer les principales contributions
de cette thèse. En premier lieu, nous étudions la précision de la méthode Trajectory Query (TQ).
À partir de la trajectoire requête d’un nœud source (trajectoire représentant l’intervalle espace-
temps de la recherche) et grâce à la mesure de similarité spatio-temporelle, la méthode TQ
sélectionne l’ ensemble des nœuds capables de communiquer avec le nœud source pendant au
moins une durée minimale tolérée (β).
Expérimentations et Résultats
-122-
Les paramètres étudiés dans cette première partie sont ensuite utilisés dans la seconde partie des
simulations dont l’objectif est d’évaluer le protocole de routage géo-multipoint DG-CastoR et
l’application CoFFee pour la gestion de flux de données.
6.2 Évaluation de la méthode Trajectory Query (TQ)
La méthode TQ joue un rôle important dans le mécanisme de construction de colonies du
protocole DG-CastoR. En effet, les nœuds qui vérifient les conditions définies dans les mesures
de similarité spatio-temporelle sont considérés comme ceux capables de garantir une
communication fiable avec le nœud source.
Une trajectoire future est un tracé composé d’un ensemble de positionnements. Ces
positionnements sont déterminés à des intervalles de temps différents. En fonction de la période
δ définie en fonction de la relation distance/vitesse (cf. chapitre 3). Pour déterminer la valeur de
la période, les deux paramètres précision (α) et la vitesse (V) sont utilisés.
La vitesse des véhicules dans un réseau routier dépend des caractéristiques du réseau (connues
par la carte routière) ainsi que de la densité des véhicules dans le réseau. Dans un réseau routier
d’une ville, la vitesse d’un véhicule change fréquemment (feux de circulation routière, forte
densité des véhicules, etc.). À l’inverse, sur une autoroute, la vitesse d’un véhicule reste
pratiquement constante.
Pour étudier la précision de notre méthode de similarité spatio-temporelle, nous avons utilisé un
échantillon de traces de trajectoires collectées à partir de la page web http://www.gpsies.com.
Ce site offre la possibilité de tracer des trajectoires sur une vraie carte géographique. Ensuite,
les positionnements de la trajectoire tracée sont récupérés en format standard (GPX, KML, etc).
Un exemple des traces récupérées en format GPX est joint en annexe (cf. Annexe B).
Les positionnements des trajectoires collectées sont déterminés par leurs coordonnées
ellipsoïdiques. Or la méthode TQ utilise les coordonnées cartésiennes. Pour transformer les
Expérimentations et Résultats
-123-
coordonnées ellipsoïdiques en coordonnées cartésiennes, nous utilisons les paramètres du
système WGS84 (World Geodetic System 1984). Ce système géodésique est en effet considéré
comme une référence standard pour la cartographie [75].
Les paramètres du système WGS84 sont :
Demi grand axe a = 6 378 137,0 m
Applatissement f = 1/298,257 222 101
6.2.1 Analyse du pourcentage de voisinages proche retourné
Nous appliquons la méthode de recherche de voisinages proches (Trajectory Queries) sur un
échantillon de 20 trajectoires; tel que pour chaque vitesse considérée, 20 trajectoires aléatoires
sont tracées. Ces trajectoires ont été tracées sur la carte géographique de la manière suivante : le
point de départ de chaque trajectoire appartient à une zone de rayon 300 m ; tel que le centre de
la zone est le point de départ de la trajectoire requête (Figure 33). L’objectif de cette évaluation
basique est d’analyser la différence de la précision des calculs de similarité spatio-temporelle
effectués à des périodes différentes.
Figure 35 : Carte routière et rayon de transmission radio
Expérimentations et Résultats
-124-
Pour chaque paire de trajectoires, la durée de connectivité est calculée. Une durée de
connectivité supérieure ou égale à un seuil fixé (1 min dans les expérimentations) est considérée
une durée acceptable pour établir une communication entre les deux véhicules.
Nous étudions la précision de la méthode TQ pour 3 vitesses différentes (50km/h, 90km/h et
120km/h). Le parcours total des trajectoires est fixé pour 10 min (à partir d’un point de départ
jusqu’une destination). Nous varions la précision (α) entre 1 et 4.
Figure 36: Pourcentage de voisinages proches TQ retournés
Pour chaque vitesse considérée, 20 cas sont étudiés. Nous présentons les résultats dans le graphe
de la Figure 34. Nous analysons la performance de la méthode en fonction de la précision et la
vitesse considérées. Les valeurs marquées montrent le pourcentage de voisinages proches
retournés (durée de connectivité supérieure à 1min). Pour une précision faible (α=1), nous
remarquons une augmentation de 20% de voisinages proches (entre les vitesse 50 et 120 km/h).
En revanche, pour les mêmes trajectoires, lorsque la précision augmente (α =4), le pourcentage
de voisinages proches retournés est à peu égal pour toutes les vitesses considérées.
Expérimentations et Résultats
-125-
Ces résultats nous mènent à conclure que, lorsque la précision (α) est grande, le nombre de
voisinages proches retournés est globalement égal pour toute vitesse considérée. En effet, les
précisions des calculs de similarité spatio-temporelles sont élevées.
En revanche, le nombre de positionnements pour chacune des trajectoires augmente lorsque la
précision augmente. La complexité de l’algorithme de calcul de la similarité spatiale est d’ordre
O(n2). La distance est calculée pour chaque paire de segments (Chapitre 3). En effet, la
complexité de l’algorithme augmente lorsque la période considérée est petite. D’autre part, la
précision des calculs de similarité retourne de meilleurs résultats lorsque la précision est grande.
Dans un travail futur, pour une meilleure évaluation de la méthode TQ, nous appliquons les
mesures de similarité spatio-temporelle sur des traces de mobilité récupérées de la base de
données géographique TIGER [76].
6.2.2 Analyse des durées de connectivité calculées
Dans cette section, nous avons effectué une étude également sur un échantillon de 20
trajectoires. L’objectif de ces expérimentations est d’analyser les durées de connectivité
calculées. Nous avons considéré trois durées de parcours des trajectoires (10 min, 20 min et 40
min). La vitesse des véhicules est fixée à 50 km/h (vitesse considérée dans une ville), nous
calculons la durée de connectivité pour des valeurs de précision (α) allant de 1 à 4.
Expérimentations et Résultats
-126-
Figure 37 : Variation de la durée de connectivité
Pour chaque durée de parcours globale des trajectoires, 20 cas sont étudiés. Le graphe de la
Figure 35 montre la variation des durées de connectivité. Pour un parcours de 10 min, la durée
varie entre 1min (seuil minimal toléré) et 4 min. La durée de connectivité est grande lorsque la
précision est grande.
6.3 ÉVALUATION DU PROTOCOLE DG-CastoR et CoFFee
6.3.1 Configuration de l’environnement et les paramètres d’entrées
OMNet++ [77] est un simulateur d’événement conçu pour la modélisation des réseaux ; il
est basé sur le langage de programmation C++.OMNet++ est utilisé dans cette partie des
simulations. L’environnement que nous étudions comporte 50 nœuds mobiles. Le rayon de
transmission radio est fixé à 100 pixels et l’environnement est de (8000x800) pixels.
Nous procédons à partir de l’étape où la colonie est déjà construite, comportant donc les 50
nœuds. Pour chaque nœud, nous attribuons les paramètres d’entrées suivants :
Expérimentations et Résultats
-127-
• Le temps estimé d’établir une communication à un-saut (EWT – Estimated Waiting
Time) : l’instant de début de la communication varie en fonction de la durée totale de la
trajectoire requête parcourue. Par exemple, lorsque le parcours est 10 min, les EWT des
nœuds varient entre 1 min et 10 min (même raisonnement pour les parcours de 20 min et
40 min).
• Durée de connectivité (CD) : Basé sur les résultats des expérimentations de la première
partie, nous varions la durée de connectivité entre 1 min et 4 min (Figure 35).
• Durée de transmission des données (TD) : Pour chaque nœud, nous attribuons un flux de
données. Ce flux de données comporte des fragments du fichier à transmettre au nœud
source. La durée de transmission (TD) présente alors la durée totale de transmission de
toutes les données dans le flux de données. Le fichier multimédia étant partitionné
équitablement, la taille du fragment unitaire est fixée à 25 Mo.
Dans ces expérimentations, le transfert des données s’effectue selon la méthode
d’ordonnancement FIFO (First In, First Out). En effet, le premier paquet dans le flux de
données est le premier envoyé. Le transfert continue tant que la durée de connectivité (CD) ne
dépasse pas la durée de transmission des données (TD). Rappelons que le protocole DG-CastoR
n’applique pas la gestion de flux de données.
Table 5 : Tableau récapitulatif des paramètres d'entrées
Nombre de nœuds 50 Rayon de transmission 100 pixels Environnement (8000x800) pixels Durée de connectivité Variant entre 1min et 4min Capacité de la bande passante 3 Mbps (6 Mbps théorique) Taille du fragment unitaire 25 Mo Nombre d’itérations (simulations) 30
Expérimentations et Résultats
-128-
Nous appliquons la distribution uniforme pour les fragments. En effet, chaque fragment a une
probabilité 1/n d’être choisi parmi les n fragments composant le fichier entier. La valeur de n
dépend de la taille complète du fichier (taille du fragment fixé à 25 Mo).
La distribution des durées de connectivité s’effectue selon les résultats de la section 6.2.2. Pour
un parcours de 10 min, par exemple, une durée de connectivité de 1 min est attribuée à 70% des
50 nœuds dans le réseau, une durée de 2 min à 17% des nœuds, une durée de 3 min à 9% des
nœuds, enfin, une durée de 4 min à 4% des nœuds. Nous appliquons la même manière de
distribution (résultats du graphe de la Figure 35) pour les parcours de 20 min et de 40 min.
6.3.2 Mesure du pourcentage de transfert complet du fichier par
rapport à la taille du fichier
Le pourcentage de transfert du fichier représente le nombre de fragments obtenus par rapport au
nombre total de fragments nécessaires pour visionner un fichier multimédia. Un transfert 100%
implique un acheminement bout-à-bout réussi d’un fichier complet. Dans cette partie, nous
mesurons alors le pourcentage du transfert complet d’un fichier multimédia pour différentes
tailles de fichiers (300 Mo, 600 Mo, 700 Mo et 900 Mo) ; tels que chaque fichier est partitionné
à un ensemble de fragments de tailles équitables (25 Mo chacun).
Nous répétons le processus de transfert des fragments 30 fois. Pour chaque itération, nous
redistribuons les fragments et les durées de connectivité aux 50 nœuds du réseau. Le graphe de
la Figure 36 montre les moyennes des résultats obtenus après 30 itérations.
Lorsque la taille du fichier est 300 Mo (12 fragments de 25 Mo chacun), la moyenne des
transferts complets (i.e. transfert de tous les fragments du fichier complet) est 100%. D’après les
Expérimentations et Résultats
-129-
résultats du graphe de la Figure 36, le pourcentage de transfert complet décroit lorsque la taille
du fichier augmente et la durée de connectivité diminue.
Figure 38 : Pourcentage du transfert complet des données
Le transfert bout-à-bout réussi dépend de la taille du fichier ainsi que de la durée de connectivité
entre les nœuds. Lorsque la durée de connectivité des nœuds est grande c’est-à-dire variant entre
2 min et 4 min, selon les expérimentations (Figure 35), le pourcentage de transfert complet est
plus satisfaisant quelque soit la taille du fichier considérée. Par contre, pour une durée ne
dépassant pas 1 min, le transfert est satisfaisant seulement lorsque la taille du fichier est petite
(300 Mo dans cette série d’expérimentations).
D’autre part, nous concluons aussi que lorsque la taille du fichier recherchée n’est pas grande, il
est plus concevable de lancer la requête sur un parcours court (exemple 10 min), puisque les
résultats peuvent être satisfaisants. De plus, ceci réduit également la complexité de l’algorithme
de similarité spatio-temporelle O(n2).
L’acheminement bout-à-bout réussi ne dépend pas seulement du protocole de routage, mais
aussi de la gestion des données au niveau applicatif. Dans ce contexte, pour améliorer le
Expérimentations et Résultats
-130-
transfert de données multimédias, nous avons appliqué les services d’amélioration (suppression
et réplication) proposés dans l’application de gestion de données CoFFee.
Comme à la section 6.4.2, nous appliquons une distribution uniforme des fragments dans le
réseau. Nous mesurons d’abord la performance de l’application CoFFee pour les durées de
connectivité d’un parcours de 10 min (Figure 35).
Dans la section précédente, un transfert est considéré incomplet lorsque la durée de connectivité
(CD) dépasse la durée de transmission des fragments attribués au noeud. Dans le graphe de la
Figure 35, nous remarquons une amélioration des pourcentages de transfert.
Figure 39 : Pourcentage de transfert des fragments pour un parcours de 10 min
Nous appliquons maintenant les services d’amélioration pour les durées du parcours de 20 min
et 40 min respectivement. En moyenne, nous remarquons une augmentation de 20% du
pourcentage de transfert complet des fragments pour la durée de parcours de 20 min (Figure
38). Une augmentation de 10% est détectée pour la durée de 40 min (Figure 39).
Expérimentations et Résultats
-131-
Figure 40 : Pourcentage de transfert des fragments pour un parcours de 20 min
Figure 41 : Pourcentage de transfert des fragments pour un parcours de 10 min
6.3.3 Mesure du pourcentage de transfert complet du fichier avec
CoFFee : variation de nombre de nœuds libres (Blank)
Nous mesurons maintenant, le pourcentage de transfert des données, lorsque nous varions le
nombre de nœuds libres (Blank nodes) dans le réseau. Les résultats son présentés dans la Figure
Expérimentations et Résultats
-132-
40. Nous remarquons que lorsque le nombre des nœuds libres représentent 10% des 50 nœuds
du réseau, le transfert atteint jusqu’à 75%. Le résultat est alors satisfaisant. En revanche, la
performance de CoFFee diminue lorsque 50% des nœuds de la colonie sont des nœuds libres.
Figure 42 : Pourcentage de transfert en fonction de nombre de nœuds libres dans l'overlay
La colonie construite par le protocole DG-CastoR seulement selon la mobilité des nœuds ; cela
implique qu’il est possible d’avoir une colonie où le nombre de nœuds libres est élevé. Dans ce
contexte, il est possible d’appliquer une méthode de réplication proactive (anticipée) pour
augmenter la disponibilité des données dans le réseau [78] (Thèse de Zeina Torbey).
6.4 DISCUSSION Dans ce chapitre, nous avons analysé les performances de nos principales contributions de cette
thèse. Nos simulations ont été effectuées sur des petits échantillons de données. Selon les cas
étudiés, nous avons analysé les résultats obtenus. Les résultats de la méthode de recherche de
voisinages proches (TQ) montrent une meilleure performance des calculs de similarité spatio-
temporelle lorsque les délais considérés sont petits. Cependant, il est nécessaire de prendre en
Expérimentations et Résultats
-133-
considération également la complexité de l’algorithme des calculs de similarité, qui est de
l’ordre O(n2).
La deuxième partie des simulations met en place l’étude de la performance du protocole DG-
CastoR et l’application CoFFee. Le transfert bout-à-bout réussi des fragments dépend de la
taille du fichier ainsi que de la durée de connectivité entre les nœuds émetteur/récepteur. Nous
remarquons que DG-CastoR sans une gestion des données assure des résultats satisfaisants pour
une taille de fichier inférieure à 600 Mo. Au-delà de cette taille, CoFFee améliore le transfert
grâce aux services de suppression et de réplication des fragments.
Une dernière série d’expérimentations concerne particulièrement la variation du nombre de
nœuds libres (blank nodes) dans la colonie. D’après les résultats obtenus, lorsque le nombre de
nœuds libres dépasse 20% de nœuds de la colonie, le transfert des données dans la colonie ne
retourne pas des résultats satisfaisants. Pour remédier à ce problème, un mécanisme de
réplication des données est nécessaire pour augmenter la disponibilité des données dans le
réseau.
-135-
CHAPITRE 7
CONCLUSION ET PERSPECTIVES
7.1 CONCLUSION
Une application de transfert de données volumineuses, pour qu’elle soit adaptée aux contraintes
des réseaux ad hoc de véhicules fortement dynamiques, nécessite de garantir une qualité de
service essentiellement au niveau de la couche réseau, c’est-à-dire en termes de routage et
d’acheminement bout-à-bout des données.
Dans ce cadre, nous avons proposé un nouveau protocole de routage géo-multipoint hybride,
appelé DG-CastoR. Le protocole DG-CastoR est spécialement conçu pour des applications de
transfert de données de grande taille dans des VANETs. Le mécanisme de routage de DG-
CastoR s’appuie sur l’analyse de la mobilité des véhicules. Dans ce contexte, une méthode de
recherche de trajectoires proches, appelée TQ a été proposée. L’objectif de la méthode TQ est
de sélectionner parmi les nœuds du réseau, ceux capables de communiquer pendant une durée
significative avec le nœud source de la requête. À partir de ces nœuds sélectionnés, DG-CastoR
Conclusion et Perspectives
-136-
construit une colonie pour chaque requête disséminée dans le réseau. Par définition, une colonie
est un recouvrement virtuel (overlay) partiel de la topologie physique du réseau. Les nœuds
appartenant à la colonie sont appelés agents. Pour conserver le lien entre les agents et le nœud
source, appelé maître agent, une topologie étoile implicite à été proposée ; cette topologie est
centrée sur maître agent. Ainsi, chaque agent de la colonie est relié par un lien logique avec le
maître agent de la colonie. Le transfert de données entre les agents et le maître agent s’effectue
en mode unicast direct. En effet, la communication s’établit à l’issue de la transition du lien
logique en lien physique (c’est-à-dire lorsque l’agent et le maître agent sont à portée radio).
Pour valider le protocole DG-CastoR, des séries de simulations ont été effectuées pour une
vitesse égale à 50km/h et pour des durées de parcours des trajectoires variables (10min, 20min
et 40min). Les résultats obtenus montrent que la taille du fichier à rechercher doit correspondre
à la durée du parcours Ainsi, pour un fichier de taille 300Mo, une durée de parcours de 10min
est suffisante pour transférer la totalité du fichier (Figure 36).
Outre la qualité de service de la couche réseau assurée par le protocole DG-CastoR, il est
également indispensable de prendre en considération la gestion du flux de données au niveau de
la couche application. Dans ce contexte, la seconde principale contribution de cette thèse est
l’application CoFFee, issue d’un travail de collaboration avec Zeina Torbey (doctorante LIRIS,
membre de l’équipe DRIM). CoFFee est une application de gestion de données ; elle offre deux
principaux services de gestion du flux de données, en particulier, un service de suppression des
données redondantes et un service de réplication des données rares. Grâce à ces services, le
volume du flux de données est réduit, et ainsi, la transmission de données est optimisée.
Les résultats des expérimentations ont montré l’amélioration apportée par CoFFee sur le
mécanisme de routage du protocole DG-CastoR. Les deux approches sont donc
complémentaires pour garantir une bonne qualité de service aux applications de transfert de
données volumineuses dans les VANETs.
7.2 PERSPECTIVES
Conclusion et Perspectives
-137-
Le protocole DG-CastoR
• Routage multi-sauts de données Le transfert de données de grande taille en mode multi-sauts est à prendre en considération dans
le protocole DG-CastoR. Dans son état actuel, le transfert de données s’effectue en mode
unicast (à un-saut), lorsque le maître agent et l’agent d’une même colonie deviennent à portée
radio l’un de l’autre. Afin de réduire les délais de transmission ainsi que les délais d’attente,
nous envisageons de développer un routage multi-sauts dans la colonie.
Grâce à la structure de la colonie (overlay implicite), une procédure de construction des chemins
de routage peut être mise en place par l’intermédiaire des agents appartenant à la même colonie.
Considérons le cas où la durée d’attente estimée (EWT – section 4.4.2) est grande. Pour que les
données soient transmises rapidement vers le maître agent (sans attendre l’écoulement de la
durée EWT), l’agent de la colonie peut déclencher une demande de construction d’un chemin de
routage multi-sauts par l’intermédiaire des agents de la colonie. Dans ce contexte, les durées de
connectivité (déjà calculées – chapitre 3) peuvent être étudiées pour sélectionner parmi les
agents de la colonie, ceux capables de construire un chemin de routage fiable vers l’agent
maître.
• Composition et exécution de services dans les VANETs Nous proposons un travail de collaboration avec Yaser Fawaz (ancien doctorant au LIRIS et
membre de notre équipe DRIM). Dans son travail de thèse, un intergiciel, baptisé ConAMi [79,
80] a été proposé pour la composition et l’exécution de services, dans un contexte d’adaptation
de contenu. Ce travail vise en particulier les réseaux décentralisés ad hoc. Pour assurer une
exécution fiable du flux de tâches, le ‘Time-To-Leave’ du service est considéré lors de la
détermination de la composition optimale de services. Dans ce contexte, nous proposons
d’intégrer les fonctionnalités de composition de services et de tolérance aux pannes de ConAMi,
avec les mécanismes de création et de gestion des colonies mis en œuvre par le protocole géo-
multipoint DG-CastoR. ConAMi évalue le Time-To-Leave d’une manière primitive alors que la
Conclusion et Perspectives
-138-
méthode TQ se base sur les données géographiques des nœuds. Grâce au mécanisme de DG-
CastoR, il est possible d’avoir une estimation assez précise des instants où les nœuds peuvent
communiquer. Cela permet de faire une planification des tâches et une optimisation de
ConAMi. Dans ce même contexte, nous proposons également d’étudier l’explicitation de la
structure de la colonie. Il s’agit en pratique, lors de l’adhésion de l’agent à la colonie, d’envoyer
un message de confirmation (feedback) vers le maître agent. Ainsi, ce denier aura une vision
globale de la colonie pour mettre en œuvre la planification des tâches avec chaque agent de sa
colonie.
L’application CoFFee
• Ordonnancement des fragments par priorité Dans la première version de CoFFee, nous avons adopté la méthode d’ordonnancement FIFO
pour le transfert de fragments de données. Pour optimiser le transfert de données, nous
proposons de transférer les données par ordre de priorité.
Deux méthodes peuvent être mises en place : (1) Une première méthode consiste à considérer
prioritaires les fragments rares présents dans le flux de données, par rapport aux autres
fragments, (2) une seconde méthode consiste à considérer prioritaires les fragments de grande
taille par rapport aux fragments plus petits.
• Estimation de la capacité courante de la bande passante Également, nous souhaitons munir CoFFee d’une prédiction future de la capacité de la bande
passante courante. Dans la version actuelle de CoFFee, la gestion des données est fondée sur la
capacité théorique de la bande passante ce qui ne reflète pas l’état réel de celle-ci.
Conclusion et Perspectives
-139-
Nous envisageons de développer une méthode d’estimation de la bande passante fondée sur 2
paramètres : La densité des véhicules ainsi que le nombre de requêtes soumises dans le réseau.
-141-
Annexe A
LE STANDARD IEEE802.11 MAC : Aperçu général
IEEE 802.11 est le standard utilisé pour les communications sans fil. Il se situe au niveau de la
couche physique PHY et de la couche MAC du modèle OSI. Le standard 802.11 a été amélioré,
ce qui explique la variété d’amendements (IEEE 802.11a, IEEE 802.11g, IEEE 802.11p, etc.).
Ces amendements diffèrent surtout au niveau de la couche physique (portée radio, fréquence,
capacité de la bande passante).
Au niveau de la couche MAC, le protocole IEEE 802.11 (contrôle d’accès au support) a comme
fonction de réguler la transmission des paquets sur le support. Le mécanisme d’accès est appelé
DCF (Distributed Coordination Function) basé sur le protocole CSMA/CA. CSMA fonctionne
comme suit : un nœud souhaitant émettre un paquet écoute d’abord le support de transmission.
Lorsque le support est occupé, la transmission est différée puisque un autre nœud est en cours
d’émission de paquets sur le support. Lorsque le support devient libre, le nœud est autorisé
d’émettre.
Malgré le mécanisme de contrôle du support, il est possible que deux nœuds écoutent
simultanément le support, repèrent qu’il est vide et émettent des paquets simultanément sur le
support, ce qui conduit à de possibles collisions. Pour éviter ces collisions de paquets, 802.11
utilise un mécanisme d’esquive de collision (Collision Avoidance) ainsi que le principe
d’accusé de réception (ACK) comme suit : un nœud souhaitant transmettre, écoute le support ;
s’il est libre, le nœud attend un temps spécifique appelé DIFS (Distributed Inter Frame Space)
avant de transmettre le paquet. Le nœud récepteur, à la réception du paquet envoie un
acquittement ACK qui indique au nœud émetteur qu’aucune collision n’a eu lieu. Si le nœud
émetteur ne reçoit pas l’acquittement, il retransmet le paquet.
-142-
Pour réduire les collisions de paquets, le standard 802.11 définit un mécanisme de « Virtual
Carrier Sense ». Lorsqu’un nœud souhaite émettre des paquets, il transmet d’abord un paquet de
contrôle appelé RTS (Request To Send) vers le nœud récepteur ; ce dernier, si le support est
libre, répond par un paquet de contrôle appelé CTS (Clear To Send).
Tous les nœuds recevant soit le RTS, soit le CTS, déclencheront leur indicateur de « Virtual
Carrier Sense », appelé NAV (Network Allocation Vector), pour une certaine durée, et
utiliseront cette information pour le Carrier Sense physique pour écouter le support.
Le standard 802.11 offre plusieurs canaux de communication. L’amendement IEEE802.11p
(amendement en cours d’évaluation) utilisé surtout pour les communications inter-véhicules
dans les VANETs, possède 7 canaux réservés, dont un canal appelé Control Channel (CCH)
réservé pour les systèmes de transports intelligents ; les 6 canaux restants, appelés Service
Channel (SCH) sont utilisés pour l’échange de données ; un exemple typique de l’utilisation des
canaux SCH sont les systèmes pair-à-pair pour le partage de données multimédias.
Malgré la multitude de canaux attribués, le protocole IEEE802.11 MAC ne tolère pas d’écouter
plus qu’un seul canal en même temps, (on parle de protocole MAC uni-canal single-channel).
Ceci signifie qu’un nœud ne peut transmettre ou recevoir de données sur deux canaux
simultanément.
-143-
Annexe B
Trace de mobilité en formt GPX <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpsies="http://www.gpsies.com/GPX/1/0" creator="GPSies http://www.gpsies.com - GPSies.com" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.gpsies.com/GPX/1/0 http://www.gpsies.com/gpsies.xsd"> <metadata> <name>GPSies.com</name> <copyright author="GPSies.com" /> <link href="http://www.gpsies.com/"> <text>GPSies.com on GPSies.com</text> </link> <time>2010-07-23T20:06:25Z</time> </metadata> <trk> <name>GPSies.com on GPSies.com</name> <trkseg> <trkpt lat="45.78420070" lon="4.899630090"> <ele>172.00000</ele> <time>2010-07-23T20:06:25Z</time> </trkpt> <trkpt lat="45.78425680" lon="4.899694470"> <ele>172.00000</ele> <time>2010-07-23T20:06:28Z</time> </trkpt> <trkpt lat="45.78430260" lon="4.899677030"> <ele>172.00000</ele> <time>2010-07-23T20:06:30Z</time> </trkpt> <trkpt lat="45.78435120" lon="4.899761520"> <ele>172.00000</ele> <time>2010-07-23T20:06:33Z</time> </trkpt> </trkseg> </trk> </gpx>
-145-
BIBLIOGRAPHIE
[1]. HARTENSTEIN Hannes, BOCHOW Bernd, EBNER André, et al. Position-aware ad hoc wireless networks for inter-vehicle communications: the Fleetnet project. In : 2nd ACM International Symposium on Mobile ad hoc Networking & Computing, pp. 259-262, 2001.
[2]. Cartalk Project. http://www.cartalk2000.net. European Inter-vehicle project. 2000. (dernière visite juillet 2010).
[3]. PreVENT project. http://www.prevent-ip.org. European Inter-vehicle project. (dernière visite juillet 2010).
[4]. NOW : Network On Wheels project. http://www.network-on-wheels.de. European Inter-Vehicule project. 2004. (dernière visite juillet 2010).
[5]. FESTAG A. NOECKER G. STRASSBERGER M., et al. ‘Now – Network on Wheels’ : Project Objectives, Technology and Achievements. In : 5th International Workshop on Intelligent Transportation (WIT), pp.211-216. Hamburg, Germany, March 2008.
[6]. Car-To-Car Consortium. http://www.car-2-car.org. (dernière visite juillet 2010).
[7]. Commission Fédérale des Communications (FCC). http://wireless.fcc.gov. (dernière visite juillet 2010).
[8]. Dedicated Short Range Communication (DSRC). http://www.leearmstrong.com/DSRC/DSRCHomeset.htm. (dernière visite juillet 2010).
[9]. ABUELELA Mahmoud, OLARIU Stephan, ZIPPER :A Zero-Infrastructure Peer-to-peer System for VANET. In : 3rd ACM Workshop on Wireless Multimedia Networking and Performance Modeling, pp. 2-8, 2007.
[10]. ZHAO Jing, CAO Guohong, VADD :Vehicle-Assisted Data Delivery in Vehicular Ad Hoc Networks. In : Vehicular Technology, IEEE, pp. 1910-1922, 2008.
-146-
[11]. GHANDEHARIZADEH Shahram, KAPADIA Shyam, et al. PAVAN : A Policy Framework for Content Availability in Vehicular Ad Hoc Networks. In : 1st ACM International Workshop on Vehicular Ad Hoc Networks, pp. 57-65, 2004.
[12]. ZRAR GHAFOUR Kayhan, ABU BAKAR Kamalrulnizam, Inter-Vehicle Communication Protocols for Multimedia Transmission. In : International MultiConference of Engineers and Computer Scientists, pp. 841-845, 2010.
[13]. ROYER M. Elizabeth, PERKINS E. Charles, Multicast Ad Hoc On-Demand Distance Vector (MAODV) Routing, <draft-ietf-manet-maodv-00.txt>, juillet 2000.
[14]. DAREHSHOORZADEH Amir, DEHGHAN Mehdi, et al. Quality of Service Support for ODMRP Multicast Routing in Ad Hoc Networks. In : Ad-Hoc, Mobile, and Wireless Networks, pp. 237-247, 2007.
[15]. CHIANG Ching-Chuan, GERLA Mario, ZHANG Lixia, Forwarding Group Multicast Protocol (FGMP) for Multihop, mobile wireless networks. In : Cluster Computing, pp. 187-196, 1998.
[16]. HOCHOONG Cho, SANG-HO Lee, et al. Efficient Overlay Multicast Protocol in Mobile Ad hoc Networks. In : 65th Vehicular Technology Conference, IEEE, pp. 51-55, 2007.
[17]. GE Min, KRISHNAMURTHY V. Srikanth, FALOUTSOS Michalis, Application Versus Network Layer Multicasting in Ad hoc Networks : The ALMA Routing Protocol. In : Ad Hoc Networks, pp. 283-300, 2006.
[18]. BESAGNI S., CHLAMTAC I., SYROTIUK V.R., WOODWARD B.A., A Distance Routing Effect Algorithm for Mobility (DREAM), In: MOBICOM, 1999.
[19]. BAKHOUYA M., GABET J., WACK M., Performance Evaluation of DREAM Protocol for Inter-Vehicle Communication. In : Wireless Vitae, IEEE, 2009.
[20]. KO young-Bae, VAIDYA Nitin H., Location-Aided Routing (LAR) in Mobile Ad hoc Networks. In : 4th annual IEEE/ACM Conference on Wireless Networks, pp.307-321, July 2000.
-147-
[21]. ZHANG G. et al., Geocast Routing in Urban Vehicular Ad Hoc Networks. In : Computer and Information Science, Verlag Springer, pp. 23-31, 2009.
[22]. CAMP T., LIU Y., An Adaptive Mesh-Based Protocol for Geocast Routing. In: Parallel and Distributed Computing : Special Issue on Routing in Mobile ans Wireless Ad Hoc Networks, pp. 196-213, 2003.
[23]. LIAO W.-H., et al., GeoGRID : A Geocasting Protocol for Mobile Ad Hoc Networks Based on GRID, In : Journal Internet Technology, pp. 23-32, 2000.
[24]. LIAO W.-H., TSENG Y.-C., SHEU J.-P., GRID : A Fully Location-Aware Routing Protocol for Mobile Ad-hoc Networks. In : Telecommunication Systems, pp. 37-60, 2001.
[25]. JERBI Moez, MERAIHI Rabah, et al., GyTAR : improved Greedy Traffic Aware
Routing Protocol for Vehicular Ad hoc Networks in City Environments. In : 3rd ACM International Workshop on Vehicular Ad hoc Networks, pp. 88-89, Los Angeles, USA, 2006.
[26]. SEET Boon-Chong, GENPING Liu, LEE Bu-Sung, et al., A-STAR : A Mobile Ad hoc Routing Strategy for Metropolis Vehicular Communications. In : International IFIT-TC6 Networking Conference, pp. 989-999, Greece, 2004.
[27]. NAUMOV Valery, GROSS Thomas, Connectivity-Aware Routing (CAR) in Vehicular Ad-hoc Networks. In : 26th International IEEE Conference on Computer Communications (INFOCOM), pp. 1919-1927, 2007.
[28]. ROYER Elizabeth , PERKINS Charles, An Implementation Study of the AODV
Routing Protocol . In : IEEE Wireless Communications and Networking Conference, pp. 90-100, Chicago, IL. September 2000.
[29]. RAJAGOPALAN Sundaram, SHEN Chien-Chung. ANSI: A Swarm Intelligence-based unicast routing. In: Journal of Systems Architecture, 2006.
-148-
[30]. SHREE Murthy, GARCIA-LUNA-AVECES J.J., An Efficient Routing Protocol for Wireless Networks. In: Journal on Mobile Networks and Applications, Special Issue on Routing in Mobile Communication Networks, pp. 183-197, ACM,1996.
[31]. ONHSON David, MALTZ David, BROCH Josh, DSR: The dynamic source routing protocol for multihop wireless ad hoc networks. In : ad hoc networking, pp. 139-172, 2000.
[32]. KARP B., KUNG H.T., GPSR : Greedy Perimeter Stateless Routing for Wireless Networks. In : 6th International Conference on Mobile computing and networking MobiCom, pp. 243-254, Boston, USA, 2000.
[33]. PERKINS Charles, BHAGWAT Pravin, Highly Dynamic Destination-Sequenced Distance Vector Routing (DSDV) for Mobile Computers. In : ACM Conference on Communications Architectures, Protocols and Applications, SIGCOMM, pp. 234-244, London, UK, 1994.
[34]. CHEN Tsu-Wei, Gerla Mario, Global State Routing : A New Routing Scheme for Ad-hoc Wireless Networks. In : IEEE Internal Conference on Communications, ICC, pp.171-175, 1998.
[35]. JOA-NG M., LU I.-T., A Peer-to-Peer zone-based two-level link state routing for mobile Ad-hoc Networks, In : IEEE Journal on Selected Areas in Communications, Special Issue on Ad-Hoc Networks, pp.1415-25, 1999.
[36]. HAAS J. Zygmunt, PEARLMAN R. Marc, The Zone Routing Protocol (ZRP) for Ad hoc Networks, <draft-ietf-manet-zone-zrp-00>, 1997.
[37]. LAKHTARIA Kamaljit, PATEL Paresh. Analyzing Zone Routing Protocol in MANET Applying Authentic Parameter, In: Global Journal of Computer Science and Technology, pp. 114-118, June 2010.
[38]. MINGLIANG Jiang, JINYANG Li, YONG Chiang Tay, Cluster Based Routing Protocol (CBRP), <draft-ietf-manet-cbrp-spec-00>, 1998.
-149-
[39]. YU J.Y., CHONG P.H.J., ZHANG M., Performance of Efficient CBRP in Mobile Ad Hoc Networks. In: 68th Vehicular Technology Conference (VTC), pp. 1-7, 2008.
[40]. DING Yong, WANG Chen, Xiao Li. A Static-Node Assisted Adaptive Routing in Vehicular Networks. In: 4th ACM International workshop on Vehicular Ad hoc Networks, pp. 59-68, 2007.
[41]. LUO Jie, GU Xinxing, et al., A Mobile Infrastructure Based VANET Routing in the Urban Environment. In: International Conference on Communications and Mobile Computing, pp. 432-437, 2010.
[42]. WU Hao, FUJIMOTO Richard, GUENSLER Randall, et al. MDDV: A Mobility-Centric Data Dissemination Algorithm for Vehicular Networks. In : 1st ACM International workshop on Vehicular Ad hoc Networks, pp. 47-56, USA, 2004.
[43]. LEE Kevin C., LEE Uichin, GERLA Mario, TO-GO: Topology-assist Geo-Opportunistic Routing in Urban Vehicular Grids. In : 6th International Conference on Wireless On-Demand Network Systems and Services, pp. 9-16, 2009.
[44]. LEONTIADIS Ilias, MASCOLO Cecilia, GeOpps:Geographical Opportunistic Routing for Vehicular Networks. In: IEEE International Symposium World of Wireless, Mobile and Multimedia Networks (WoWMoM), pp. 1-6, 2007.
[45]. MCDONALD I.A, NELSON R. Application-level QoS: Improving video conferencing quality through sending the best packet next. In : International Journal of Internet Protocol Technology, pp. 24-31, 2009.
[46]. CHAUHAN G., NANDI S., QoS Aware Stable Path Routing (QASR) Protocol for MANETs. In : 1st International Conference on Emerging Trends in Engineering and Technology (ICETET), pp. 202-207, 2008.
-150-
[47]. GULLIVER Yihai Zhang. Quality of Service for Ad hoc On-Demand Distance Vector Routing. In : International IEEE Conference on Wireless and Mobile Computing, Networking And Communications, pp. 192-196, 2005.
[48]. SHERWOOD R., BRAUD R., BHATTACHARJEE B., Slurpie : A Cooperative Bulk Data Transfer Protocol. In : International IEEE Conference INFOCOM, pp. 941-951, 2004.
[49]. NANDAN Alok, DAS Shirshanka, PAU Giovanni, et al., Cooperative Downloading in Vehicular Ad-Hoc Wireless Networks. In : 2nd Annual Conference on Wireless On-Demand Network Systems and Services, pp. 32-41, 2005.
[50]. TAO Yufei, PAPADIAS Dimitris, SHEN Qiongmao. Continuous Nearest Neighbor Search. In : 28th International Conference on Very Large Data Bases (VLDB), pp. 287-298, 2002.
[51]. SONG Zhexuan, ROUSSOPOULOS Nick. K-Nearest Neighbor Search for Moving Query Point. In : 7th International Symposium on Advances in Spatial and Temporal Databases, pp. 79-96, 2001.
[52]. HU Haibo, LEE Dik Lun. Range Nearest-Neighbor Query. In: IEEE Transactions on Knowledge and Data Engineering, pp. 78-91, 2006.
[53]. LEE Ken C.K., LEE Wang-Chien, LEONG Hong Va. Nearest Surrounder Queries. In: 22nd International Conference on Data Engineering, pp. 85, 2006.
[54]. TIAN Xia, DONGHUI Zhang, Continuous Reverse Nearest Neighbor Monitoring. In: 22nd International Conference on Data Engineering, pp. 77, 2006.
[55]. JENSEN S. Christian, KOLAR Jan, PEDERSON Torben Bach, et al., Nearest Neighbor Queries in Road Networks. In :11th ACM International Symposium on Advances in Geographic Information Systems, pp. 1-8, 2003.
-151-
[56]. MOURATIDIS Kyriakos, YIU Man Lung, PAPADIAS Dimitris, et al., Continuous Nearest Neighbor Monitoring in Road Networks. In : 32rd International Conference on Very Large Data Bases (VLDB), 2006.
[57]. FLATLAND Robin, STEWART Charles, Extending Range Queries and Nearest Neighbors. In : Computational Geometry, pp. 3-24, 2000.
[58]. KML : Keyhole Markup Language. http://code.google.com/intl/fr/apis/kml/documentation/kml_tut.html. (dernière visite juillet 2010).
[59]. GPX: GPS Exchange Format. http://www.topografix.com/gpx.asp. (dernière visite juillet 2010).
[60]. Geomatics : http://geomatics.ladetto.ch (dernière visite juillet 2010).
[61]. ATECHIAN Talar, BRUNIE Lionel, DG-CastoR for Query Packets Dissemination
in VANET. In: 5th International IEEE Conference on Mobile Ad Hoc and Sensor Systems (MASS), pp. 547-552, 2008.
[62]. ATECHIAN Talar, BRUNIE Lionel, DG-CastoR : Direction-based Geocast
Routing protocol for VANET. In : International Conference on Telecommunications Networks and Systems TNS, Amsterdam, 2008.
[63]. STUTZBACH Daniel, REJAIE Reza, Characterizing the Two-Tier Gnutella
Topology. In : ACM SIGMETRICS Performance Evaluation Review, pp. 402-403, 2005.
[64]. STOICA Ion, MORRIS Robert, LIBEN-NOWELL David, et al. Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications. In: IEEE/ACM Transactions on Networking (TON), pp. 17-32, 2003.
[65]. RATNASAMY Sylvia, FRANCIS Paul, HANDLEY Mark, et al. A Scalable Content-Addressable Network. In: International Conference on Applications,
-152-
Technologies, Architectures and Protocols for Computer Communications, pp. 161-172, 2001.
[66]. CLARKE I., SANDBERG O., et al., Freenet: A distributed anonymous information storage and retrieval system. In : Workshop on Design Issues in Anonymity and Unobservability, pp. 311-320, 2000.
[67]. ATECHIAN Talar, TORBEY Zeina, BENNANI Nadia, BRUNIE Lionel. CoFFee: Cooperative and InFrastructure-Free Peer-to-Peer System for VANET. In : 9th International IEEE Conference on ITS Telecommunication, pp. 510-515, 2009.
[68]. POUWELSE Johan, GARBACKI Pawel, EPEMA Dick, SIPS Henk, The Bittorent P2P File-Sharing System: Measurements and Analysis. In : 4th International Workshop IPTPS, pp. 205-216, 2005.
[69]. SAAD Samir, TEKLI Joe, CHBEIR Richard, YETOGNON Kokou. Towards
Multimedia Fragmentation. In: 10th European Conference on Advances in Databases and Information Systems, ADBIS, pp. 415-429, 2006.
[70]. WANG S.Y., BHARGAVA B. A Fragmentation Scheme for Multimedia Traffic in
Active Networks. In: 17th IEEE Symposium on Reliable Distributed Systems, pp. 437, 1998.
[71]. MOUSTEFAOUI Ahmed, BRUNIE Lionel. SIRSALE: Un Système d’indexation et
de recherché de séquences audiovisuelles à large échelle. In : Gestion des données multimédias, pp. 283-309, 2004.
[72]. SARR C., CHAUDET C., CHELIUS G., GUERIN-LASSOUS I., Available Bandwidth Estimation for IEEE802.11-based Ad Hoc Networks. Rapport de Recherche, version 2, 2007.
[73]. ZHAO H., GARCIA-PALACIOA E., Rethinking Available Bandwidth Estimation in IEEE 802.11-based Ad Hoc Networks. In: Electronics Letters, pp. 211-213, 2009.
-153-
[74]. TORRENT-MORENO Marc, SANTI Paolo, HARTENSTEIN Hannes, Fair Sharing of Bandwidth in VANETs. In : 2nd ACM International Workshop on Vehicular Ad hoc Networks, pp. 49-58, 2005.
[75]. WGS84 : World Geodetic System 1984. http://www.dqts.net. (dernière visite juillet 2010).
[76]. TIGER : Topologically Integrated Geographic Encoding and Referencing System. http://www.census.gov/geo/www/tiger (dernière visite juillet 2010).
[77]. OMNeT++ : A Discrete Event Simulation Environment. http://www.omnetpp.org. (dernière visite juillet 2010).
[78]. TORBEY Zeina, BENNANI N. COQUIL D. BRUNIE L. CreaM: User-Centric
Replication Model for Mobile Environments. In: International workshop on Mobile P2P data Management, Security and Trust (M-PDMST), in conjuction with 11th International Conference on Mobile Data Management, 2010. (à paraître).
[79]. FAWAZ Y., BERHE G. BRUNIE L. et al. Efficient Execution of Service
Composition for Content Adaptation in Pervasive Computing. In: International Journal of Digital Multimedia Broadcasting. 2008.
[80]. FAWAZ Y. NEGASH A. BRUNIE L. SCUTURICI V. ConAMi: Collaboration-
Based Content Adaptation Middleware for Pervasive Computing Environment. In: IEEE International Conference on Pervasive Services, pp. 189-192, 2007.
top related