Protocole de routage géo-multipoint hybride et mécanisme d’acheminement de...

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


-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


-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


-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


-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.


-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 à


-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).


-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)


-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).


-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.


-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.

État de l’art

-47-

État de l’art

-48-

-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


-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


-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


-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


-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


-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.


-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


-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


-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.


-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).


-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


-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)


-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.


-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)


-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']


-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:


-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’).


-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


-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


-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.

-74-

.

-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.


-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 »


-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.


-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.


-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


-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.


-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.


-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).


-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


-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


-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).


-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


-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)).


-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)


-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


-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).


-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).


-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.


-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).


-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.


-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.


-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


-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.


-99-

-101-

Deuxième Partie

Application de gestion de données pour les réseaux ad hoc

-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


-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.


-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.


-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.


-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


-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.


-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,


-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.


-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


-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.


-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


-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


-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


-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=


-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.


-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.


-120-

-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

http://www.gpsies.com/


-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


-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.


-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.


-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 :


-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


-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


-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


-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).


-131-



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


-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


-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.


-134-

-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


-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


-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.


-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.


-140-

-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.

http://www.cartalk2000.net/

-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.

Protocole de routage géo-multipoint hybride et mécanisme d’acheminement de...

Documents

Transcript of Protocole de routage géo-multipoint hybride et mécanisme d’acheminement de...