ad hoc bon thèse

TTHHÈÈSSEE

En vue de l'obtention du

DDOOCCTTOORRAATT DDEE LL’’UUNNIIVVEERRSSIITTÉÉ DDEE TTOOUULLOOUUSSEE

Délivré par l'Université Toulouse III - Paul Sabatier Discipline ou spécialité : Informatique

Jury

Président du jury Michel Diaz Directeur de recherche, LAAS-CNRS (Toulouse) Rapporteur Francine Krief Professeur, ENSEIRB (Bordeaux) Rapporteur Pascal Lorenz Professeur, Université de Haute Alsace (Colmar) Examinateur Zoubir Mammeri Professeur, Université Paul Sabatier (Toulouse) Rapporteur Pascale Minet Chargée de Recherche, INRIA (Rocquencourt) Examinateur Patrick Sénac Enseignant-chercheur, ISAE (Toulouse)

Ecole doctorale : Mathématiques, Informatique et Télécommunications de Toulouse Unité de recherche : Institut de Recherche en Informatique de Toulouse – UMR 5505

Directeur de Thèse : Zoubir Mammeri

Présentée et soutenue par David Espès Le 27 novembre 2008

Titre : Protocoles de routage réactifs pour l’optimisation de

bande passante et la garantie de délai dans les réseaux

ad hoc mobiles

À ma famil le, à mes amis…

i

Remerciements

Une thèse est l’accomplissement de travaux de recherche de plusieurs années. Ce travail, bien

qu’enrichissant, n’est pas tous les jours évident à entreprendre. Le soutien des proches et des collègues

de travail permet de faire avancer ce travail, même dans les moments les plus difficiles.

Je tiens à remercier tout particulièrement Zoubir Mammeri pour m’avoir accueilli dans son équipe et

pour ses conseils avisés. Je le remercie pour toute la patience dont il a su faire preuve (durant la

relecture des papiers ou de la thèse par exemple) mais également de son soutien dans les moments

délicats. Un grand MERCI !

Je tiens également à remercier les membres de mon jury : Michel Diaz, Francine Krief, Pascal Lorenz,

Pascale Minet et Patrick Sénac de l’intérêt porté à nos travaux de recherche.

Je tiens à remercier l’ensemble de l’équipe ASTRE, et tout particulièrement les collègues et amis de la

composante réseau. Merci à Cédric Teyssié pour son soutien, son aide et ses conseils. Merci à tous

ceux et toutes celles qui ont partagés mon bureau. Les anciens qui ont maintenant quitté le milieu

universitaire (Anne Millet, David Doose) ainsi que les petits nouveaux (Jonathan Petit, Mahboub Bali).

Un grand merci aux membres de l’équipe SIERA : François Barrère (qui m’a permis de parfaire mes

connaissances au niveau physique et liaison), Abdelmalek Benzekri, Julien Broisin, Thierry Desprats

(grâce à qui mes connaissances en géographie se sont améliorées), Michel Kamel, Romain Laborde

(trop lent sur Parc Baby), Daniel Marquié et Philippe Vidal pour m’avoir aidé à réaliser mes premiers

pas dans l’enseignement (et ceci dans divers horizons MIAGE, L2 informatique et IUT).

Merci à tous mes amis de la fac (Claire, Chaouki, Sam, Marie, Xav, Aurélie, les deux Antoine, Samy,

Sophie, Lucie) et à ceux rencontrés durant les années de thèse (Samir, Nop, JC, Souad, Armelle).

Merci d’avoir partagé mon quotidien : le rutage, les soirées jeux, la danse …

Merci à tous mes amis de Plaisance : Yann Lebras, Julien Orvoen, Florent Bernard, Cédric Colombier,

Sophie Gregorio, Cédric Delannoy et David Jougla. Malgré la distance qui nous sépare aujourd’hui, ça

ne m’empêchera pas de franchir la frontière de la garonne (rive gauche) pour continuer à venir vous

voir et passer quelques jours en votre compagnie.

Sur un plan plus personnel, je tiens à remercier tout particulièrement mes parents, ma sœur et tous les

membres de ma famille. Je les remercie pour leur soutien de tous les jours, leur compréhension dans

les moments difficiles. Sans eux, certains jours auraient été bien plus noir.

Encore un grand MERCI à toutes et à tous !

iii

Résumé

Nos travaux se situent dans le contexte des réseaux MANETs (Mobile Ad Hoc NETorks) qui

constituent une catégorie de réseaux sans fil pouvant être déployés rapidement, multi-sauts et sans

infrastructure. Les réseaux MANETs permettent la communication entre utilisateurs d’applications

mobiles diverses (applications collaboratives, urgences, militaires, embarquées…).

Cependant, ces réseaux souffrent d’inconvénients à la fois liés aux caractéristiques du medium de

transmission (partage du canal de transmission, faible débit…), mais également aux protocoles de

routage (dissémination de l’information, sélection d’un chemin…). Ces limites rendent difficile le

support des applications multimédia et temps réel (telles que la vidéoconférence, la vidéo à la

demande, la VoIP…). Ces applications requièrent le respect de contraintes de Qualité de Service (QoS)

telles que la bande passante et le délai.

Le but de nos travaux est d’optimiser la bande passante disponible d’un réseau MANET pour

permettre l’utilisation d’applications fortement consommatrices en bande passante. Comme un réseau

MANET est multi-saut, l’influence des protocoles de routage sur les performances du réseau est

déterminante. Trois axes ont été étudiés pour augmenter la bande passante utile des réseaux MANETs :

réduction des collisions, réduction des informations de routage et garantie de la bande passante et du

délai.

Mots-clés : Réseaux ad hoc, routage, routage à QoS, applications temps-réel, bande passante, délai

v

Table des Matières

Remerciements ....................................................................................................................................... i

Résumé .................................................................................................................................................. iii

Table des Matières................................................................................................................................. v

Table des Figures .................................................................................................................................. ix

Introduction ........................................................................................................................................... 1

1 Introduction aux Réseaux Mobiles Ad hoc (MANETs) ................................................................ 5

1.1 Contexte des travaux ..................................................................................................................... 6

1.2 Les réseaux mobiles ad hoc (MANETs) ....................................................................................... 7

1.2.1 Caractéristiques des réseaux MANETs ................................................................................. 8

1.2.2 Contraintes liées aux réseaux MANETs................................................................................ 9

1.3 Réseaux IEEE 802.11 ................................................................................................................. 10

1.3.1 IEEE 802.11 mode infrastructure / mode ad hoc ................................................................ 10

1.3.2 La couche physique ............................................................................................................. 11

1.3.3 Sous-couche MAC .............................................................................................................. 12

1.3.4 Accès au canal de manière distribuée .................................................................................. 13

1.3.4.1 Mode DCF ................................................................................................................... 13

1.3.4.2 Mode DCF avec RTS/CTS .......................................................................................... 15

1.4 Accès au canal sans contention ................................................................................................... 17

1.5 Modèles de mobilité .................................................................................................................... 18

1.6 Discussion ................................................................................................................................... 19

2 Routage Meilleur effort dans les réseaux MANETs .................................................................... 21

2.1 Type de dissémination de l’information de routage .................................................................... 23

2.1.1 Protocoles de routage Proactifs ........................................................................................... 23

2.1.1.1 Protocole DSDV .......................................................................................................... 24

2.1.1.2 OLSR ........................................................................................................................... 25

2.1.1.3 Autres protocoles proactifs .......................................................................................... 25

2.1.2 Protocoles Réactifs .............................................................................................................. 26

2.1.2.1 Protocole AODV ......................................................................................................... 27

2.1.2.2 Protocole DSR ............................................................................................................. 28

2.1.2.3 Autres protocoles réactifs ............................................................................................ 29

2.1.3 Protocoles Hybrides ............................................................................................................ 30

2.1.3.1 Protocole ZRP .............................................................................................................. 31

2.1.3.2 Autres protocoles hybrides .......................................................................................... 32

2.2 Hiérarchisation du réseau ............................................................................................................ 32

2.2.1 Cluster ................................................................................................................................. 33

2.2.2 Réseaux à backbone ............................................................................................................ 34

2.2.3 Protocoles de routage hiérarchiques .................................................................................... 35

vi

2.3 Protocoles utilisant des informations de localisation .................................................................. 37

2.3.1 Protocole LAR ..................................................................................................................... 38

2.3.2 Protocole DREAM .............................................................................................................. 39

2.3.3 Autres protocoles à localisation .......................................................................................... 40

2.4 Discussion ................................................................................................................................... 42

3 Routage à Qualité de Service dans les réseaux MANETs ........................................................... 45

3.1 Routage à QoS ............................................................................................................................ 46

3.2 Métriques de QoS ........................................................................................................................ 48

3.2.1 Modèles d’estimation .......................................................................................................... 49

3.2.2 Estimation de bande passante disponible ............................................................................ 49

3.2.2.1 Méthode de Kazantsidis et Gerla ................................................................................. 50

3.2.2.2 Méthode de Lee et al. .................................................................................................. 51

3.2.3 Estimation de délai .............................................................................................................. 51

3.2.3.1 Modèle d’estimation de délai à sonde ......................................................................... 52

3.2.3.2 Modèle d’estimation de délai de bout en bout de Chen ............................................... 52

3.3 Complexité des algorithmes ........................................................................................................ 52

3.4 Fonction poids ............................................................................................................................. 54

3.5 Qualité de Service dans les protocoles de routage existants ....................................................... 55

3.5.1 Protocoles de routage à QoS indépendants de la méthode d’accès au support ................... 56

3.5.2 Protocoles de routage à QoS dépendants de la méthode d’accès au support....................... 59

3.6 Discussion ................................................................................................................................... 64

4 Optimisation de la bande passante disponible ............................................................................. 67

4.1 Bande passante : une ressource critique ...................................................................................... 67

4.1.1 Paramètres influant sur la diminution de la bande passante ................................................ 68

4.1.2 Protocole de routage : élément essentiel dans la gestion de la bande passante ................... 70

4.2 Collisions : causes et conséquences ............................................................................................ 71

4.2.1 Causes.................................................................................................................................. 71

4.2.1.1 Nombre de nœuds voisins ............................................................................................ 78

4.2.1.2 Débit de transmission .................................................................................................. 80

4.2.1.3 Charge d’un lien .......................................................................................................... 81

4.2.1.4 Influence de la longueur d’un chemin ......................................................................... 84

4.2.2 Conséquences ...................................................................................................................... 85

4.3 Protocole de routage .................................................................................................................... 86

4.3.1 Fonction poids numéro 1 ..................................................................................................... 87

4.3.1.1 Métriques utilisées ....................................................................................................... 87

4.3.1.2 Fonction poids utilisée ................................................................................................. 88

4.3.2 Fonction poids numéro 2 ..................................................................................................... 90

4.3.2.1 Métriques ..................................................................................................................... 90

4.3.2.2 Fonction poids utilisée ................................................................................................. 91

4.3.3 Phase de découverte de route .............................................................................................. 92

4.3.3.1 Algorithme du nœud source......................................................................................... 93

4.3.3.2 Algorithme du nœud intermédiaire .............................................................................. 94

vii

4.3.3.3 Algorithme du nœud de destination ............................................................................. 95

4.3.4 Maintenance des routes ....................................................................................................... 96

4.3.5 Analyse de performance ...................................................................................................... 96

4.4 Discussion ................................................................................................................................. 104

5 Approches de Réduction de la charge due aux informations de contrôle ............................... 107

5.1 Détermination de la position de la destination .......................................................................... 109

5.1.1 Protocole de localisation de la destination ........................................................................ 110

5.1.1.1 Phase de découverte de la destination ....................................................................... 110

5.1.1.2 Phase de maintenance ................................................................................................ 113

5.1.1.3 Analyse de performance ............................................................................................ 114

5.1.1.4 Discussion .................................................................................................................. 118

5.2 Réduction de l’espace de recherche .......................................................................................... 119

5.2.1 Forme géométrique triangulaire ........................................................................................ 119

5.2.2 Forme géométrique en cerf-volant .................................................................................... 124

5.2.3 Protocole de découverte de route ...................................................................................... 129

5.2.4 Complexité en messages ................................................................................................... 130

5.2.5 Simulations ........................................................................................................................ 131

5.2.5.1 Discussion .................................................................................................................. 134

5.3 Protocoles utilisant une recherche de parcours en profondeur .................................................. 135

5.3.1 Propriétés de la zone de recherche .................................................................................... 135

5.3.2 Protocole optimal .............................................................................................................. 138

5.3.2.1 Phase de découverte des routes.................................................................................. 139


5.3.2.3 Complexité en termes de message ............................................................................. 141

5.3.3 Protocole conciliant taux de découverte des routes et dissémination d’informations de

routage ........................................................................................................................................ 142

5.3.3.1 Phase de découverte des routes.................................................................................. 143


5.3.3.3 Complexité en termes de messages ........................................................................... 145

5.3.4 Simulations ........................................................................................................................ 145

5.4 Discussion ................................................................................................................................. 148

6 Protocole de routage pour l’optimisation de bande passante sous des contraintes : délai et bande passante ................................................................................................................................... 149

6.1 Garantie du délai : un besoin ..................................................................................................... 149

6.2 Facteurs impactant la bande passante lors de réservation de slots ............................................ 151

6.2.1.1 Impact de la réservation d’un slot sur les nœuds voisins ........................................... 152

6.2.2 Problème de routage .......................................................................................................... 153

6.2.2.1 Impact d’un chemin sur les nœuds voisins ................................................................ 154

6.2.3 Bande passante surconsommée ......................................................................................... 159

6.3 Optimisation de la bande passante sous contraintes de délai et bande passante ....................... 160

6.3.1 Métriques ........................................................................................................................... 160

6.3.2 Fonction poids ................................................................................................................... 161

6.3.3 Principe du protocole......................................................................................................... 162

viii

6.3.4 Algorithme ........................................................................................................................ 163

6.3.5 Analyse de performances .................................................................................................. 166

6.4 Discussion ................................................................................................................................. 169

7 Conclusion et perspectives ........................................................................................................... 171

7.1 Contributions ............................................................................................................................. 171

7.2 Expérience ................................................................................................................................. 173

7.3 Critiques et orientations futures ................................................................................................ 173

Bibliographie ...................................................................................................................................... 175

Annexes .............................................................................................................................................. 187

I Compléments ............................................................................................................................ 189

ix

Table des Figures

Figure 1-1 : Couche Physique IEEE 802.11 .......................................................................................... 11

Figure 1-2 : Exemple d’accès au médium pour 3 stations ..................................................................... 14

Figure 1-3 : Partage du canal par trois stations avec la méthode RTS/CTS .......................................... 15

Figure 1-4 : Problèmes des nœuds cachés ............................................................................................. 16

Figure 1-5 : L’utilisation du mécanisme RTS/CTS n’empêche pas la totalité des collisions. .............. 17

Figure 1-6 : Structure d’une fenêtre TDMA de M slots de données par fenêtre, pour un réseau de N

nœuds. ........................................................................................................................................... 17

Figure 2-1 : Différents types de protocoles de routage Meilleur Effort ................................................ 22

Figure 2-2 : Topologie d’un réseau de clusters ..................................................................................... 33

Figure 2-3 : Topologie d’un réseau de Backbone .................................................................................. 34

Figure 3-1 : Exemple de graphe associé à un réseau ............................................................................. 47

Figure 4-1 : Intervalle de temps durant lequel peut se produire une collision. a) X commence à

transmettre alors que Y a déjà commencé à transmettre. b) Y commence à transmettre alors que X

a déjà commencé à transmettre. .................................................................................................... 73

Figure 4-2 : Intervalle de temps durant lequel une collision est susceptible de se produire dans le cas

de nœuds cachés. .......................................................................................................................... 74

Figure 4-3 : Sélection d’un chemin possédant moins de voisins pour le protocole de routage optimal

comparé au protocole de plus court chemin. ................................................................................ 79

Figure 4-4 : Temps d’émission d’une trame IEEE 802.11b .................................................................. 80

Figure 4-5 : Charge transmise en fonction de la charge soumise sur le médium pour des nœuds ayant

un débit de transmission égal à 1 Mbps ou à 2 Mbps. .................................................................. 82

Figure 4-6 : Nombre de collisions subies par le réseau en fonction du débit total des nœuds avec un

débit de transmission égal à 1 Mbps ou 2 Mbps. .......................................................................... 83

Figure 4-7 : Nombre de paquets supprimés en fonction du débit total des nœuds avec un débit de

transmission égal à 1 Mbps ou 2 Mbps ........................................................................................ 84

Figure 4-8 : Organigramme exécuté par un nœud source ..................................................................... 94

Figure 4-9 : Organigramme utilisé par un nœud intermédiaire. L’encadré en pointillé met en valeur la

partie différente de notre protocole comparé au protocole AODV............................................... 95

Figure 4-10 : Organigramme utilisé par la destination. L’encadré en pointillé met en valeur la partie

différente de notre protocole comparé au protocole AODV. ........................................................ 95

Figure 4-11 : Bande passante consommée par les paquets de données en fonction du nombre de nœuds

présents sur le réseau. La taille des paquets est de 512 octets. ..................................................... 97


présents sur le réseau. La taille des paquets est de 1500 octets. ................................................... 98


présents sur le réseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%)

des nœuds ont un débit de 1Mbps (respectivement 11Mbps, 54Mbps). ....................................... 98

x

Figure 4-14 : Bande passante ayant subi des collisions en fonction du nombre de nœuds présents sur le

réseau. La taille des paquets est de 512 octets. ............................................................................. 99


réseau. La taille des paquets est de 1500 octets. ........................................................................... 99


réseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des nœuds ont

un débit de 1Mbps (respectivement 11Mbps, 54Mbps). ............................................................ 100

Figure 4-17 : Bande passante consommée par les requêtes en fonction du nombre de nœuds présents

sur le réseau. La taille des paquets est de 512 octets. ................................................................. 101


sur le réseau. La taille des paquets est de 1500 octets. ............................................................... 101


sur le réseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des

nœuds ont un débit de 1Mbps (respectivement 11Mbps, 54Mbps). ........................................... 102

Figure 4-20 : Bande passante consommée par les paquets de données en fonction de la mobilité des

nœuds. Le réseau est composé de 50 nœuds et la taille des paquets est de 512 octets. .............. 102

Figure 4-21 : Bande passante ayant subi des collisions en fonction de la mobilité des nœuds. Le réseau

est composé de 50 nœuds et la taille des paquets est de 512 octets. ........................................... 103

Figure 4-22 : Bande passante consommée par les requêtes en fonction de la mobilité des nœuds. Le

réseau est composé de 50 nœuds et la taille des paquets est de 512 octets. ................................ 104

Figure 5-1 : Organigramme utilisé par le nœud source pour déterminer la position de la destination.

L’encadré en pointillé met en valeur la partie différente de notre protocole comparé au protocole

AODV. ........................................................................................................................................ 111


partie différente de notre protocole comparé au protocole AODV............................................. 112


différente de notre protocole comparé au protocole AODV. ...................................................... 113

Figure 5-4 : Nombre de requêtes de localisation échangées en fonction du nombre de nœuds avec une

mobilité des nœuds de 5m/s. ....................................................................................................... 115

Figure 5-5 : Nombre de requêtes de localisation échangées en fonction de la mobilité des nœuds pour

deux topologies différentes (une composée de 50 nœuds, l’autre composée de 100 nœuds). .... 116

Figure 5-6 : Temps d’obtention de la position d’un nœud destination en fonction du nombre de nœuds

du réseau ..................................................................................................................................... 117

Figure 5-7 : Temps d’obtention de la position d’un nœud destination en fonction de la mobilité des

nœuds pour deux topologies (une composée de 50 noeuds, l’autre composée de 100 nœuds). . 118

Figure 5-8 : Zone de recherche de forme triangulaire ......................................................................... 120

Figure 5-9 : Zone de recherche en forme de cerf-volant ..................................................................... 125

Figure 5-10 : Organigramme utilisé par un nœud intermédiaire ......................................................... 130

Figure 5-11 : Pourcentage d’échec à la détermination d’une route en fonction du nombre de nœuds du

réseau. ......................................................................................................................................... 132

Figure 5-12 : Pourcentage d’échec à trouver une route suivant l’angle utilisé pour calculer la taille de

la zone de recherche. .................................................................................................................. 133

Figure 5-13 : Nombre moyen de requêtes nécessaires à la découverte d’une route ............................ 133

xi

Figure 5-14 : Nombre moyen de requêtes par connexion en fonction de la taille de la zone de

recherche ..................................................................................................................................... 134

Figure 5-15 : Zone de recherche avec un angle α aigu (a) et un angle α obtus (b) ............................. 136

Figure 5-16 : Organigramme utilisé par le nœud source. L’encadré en pointillé met en valeur la partie


Figure 5-17 : Echec de la découverte d’une route alors qu’une existe. ............................................... 143



Figure 5-19 : Pourcentage d’échec à la découverte d’une route .......................................................... 146

Figure 5-20 : Nombre requêtes transmises sur le réseau pour la découverte des chemins .................. 147

Figure 5-21 : Nombre moyen de requêtes pour la détermination d’un chemin ................................... 147

Figure 6-1 : Nombre de slots réservés suivant la position d’un nœud sur un chemin ......................... 152

Figure 6-2 : Impact de chemins différents sur un réseau de 8 nœuds. a) Impact du chemin le plus court.

b) Impact du chemin optimal. ..................................................................................................... 155

Figure 6-3 : Impact d’un chemin sur les nœuds voisins avec la réservation de 2 slots par nœud traversé.

.................................................................................................................................................... 157

Figure 6-4 : Organigramme utilisé par le nœud source ....................................................................... 164

Figure 6-5 : Organigramme utilisé par un nœud intermédiaire j ......................................................... 165

Figure 6-6 : Organigramme utilisé par le nœud destination ................................................................ 166

Figure 6-7 : Bande passante surconsommée par le protocole LD comparé à notre protocole ............ 167

Figure 6-8 : Bande passante nécessaire à l’obtention des routes ......................................................... 168

Figure 6-9 : Bande passante utilisée par les paquets de données ........................................................ 168

Figure 6-10 : Nombre de slots restés libres en fin de simulation en fonction du nombre de nœuds. .. 169

Figure A-1 : Organigramme du nœud source ...................................................................................... 190

Figure A-2 : Organigramme d’un nœud intermédiaire ........................................................................ 191

Figure A-3 : Organigramme d’un nœud destination ........................................................................... 192

1

Introduction

1. Contexte

Avec le développement constant des technologies, l’utilisation des systèmes d’information s’est

transformée. Elle s’exprime notamment par un besoin de mobilité des utilisateurs. Les réseaux filaires

ne pouvant assurer une telle flexibilité d’utilisation, les réseaux sans fil, et WiFi (Wireless Fidelity) en

particulier, ont permis de combler une partie de ce manque. Les utilisateurs peuvent ainsi se déplacer

librement avec leur terminal mobile (ordinateur, téléphone, PDA…) tout en restant connectés à leur

réseau personnel ou d’entreprise. L’utilisation de terminaux mobiles impose l’emploi d’une

infrastructure (points d’accès) parfois coûteuse ou difficile à implanter. De fait, cette solution n’est pas

toujours envisageable. Par conséquent, des réseaux mobiles dépourvus d’infrastructure ont été

déployés. Ces réseaux sont plus connus sous le nom de réseaux ad hoc mobiles ou MANETs (Mobile

Area NETworks).

Un réseau MANET est un réseau sans fil capable de s’organiser sans infrastructure définie

préalablement. Un tel réseau est composé de stations mobiles ou nœuds qui peuvent communiquer

directement entre eux s’ils sont situés à portée radio. La portée des stations étant relativement limitée,

le déploiement d’un réseau à grande échelle nécessite que le réseau MANET soit multi-saut, c'est-à-

dire que des stations intermédiaires fassent office de point de relais. Les réseaux MANETs, grâce à

leur auto-organisation, et à l’absence d’infrastructure, peuvent facilement être déployés dans de

nombreux domaines comme l’embarqué (intégré récemment dans le secteur automobile pour accroître

la sécurité des usagers en les informant d’éventuels obstacles sur leur itinéraire), lors d’opérations de

secours (sauvetage en mer, en zones sinistrées…) ou lors d’opérations militaires. Les réseaux

MANETs se caractérisent également par leurs faibles ressources sur la totalité de la ligne de

communication. Cela se traduit par une autonomie limitée, car les stations sont généralement

alimentées à l’aide de batteries, et par une puissance relativement faible du fait de la compacité des

équipements emportés. De plus, la capacité des liens sans fil s’avère relativement limitée offrant par

conséquent un débit modeste comparé aux réseaux filaires.

Les utilisateurs de réseaux MANETs souhaitent avoir les mêmes services que ceux offerts par les

réseaux filaires. En d’autres termes, les applications utilisées dans les réseaux filaires doivent être

fonctionnelles sur les réseaux ad hoc, en particulier, les applications multimédia et temps-réel

(vidéoconférence, téléphonie sur internet, vidéo sur demande…). Les ressources limitées des réseaux

MANETs rendent complexes le support de telles applications qui nécessite des ressources importantes

(notamment la bande passante). De nombreux facteurs, au niveau physique (collisions par exemple) ou

par le fonctionnement de certaines couches (couche réseau par exemple), réduisent la bande passante

de ces réseaux. Nous focalisons nos travaux sur l’augmentation de la bande passante utile des réseaux

MANETs.

2

Le protocole de routage dissémine des informations de routage nécessaires à l’obtention et à la

maintenance des routes. Suivant le type de dissémination de l’information, ces protocoles peuvent être

répertoriés en trois grandes classes : proactifs, réactifs et hybrides. L’étude de ces différentes

approches nous a permis d’orienter nos travaux sur les protocoles de routage réactifs. Les protocoles

de routage réactifs diffusent des informations de routage seulement sur demande. De fait, nous avons

choisi de baser nos contributions sur l’amélioration du protocole de routage réactif AODV (Ad hoc

On-Demand Distance Vector routing).

Le protocole de routage doit intervenir sur les facteurs réduisant la bande passante utile du réseau. La

bande passante utile d’un réseau est réduite par la présence des collisions. Le protocole de routage est

lui-même responsable de la diminution de la bande passante utile d’un réseau. Ces informations sont

nécessaires à la détermination et à la maintenance des routes.

2. Contributions

Notre première contribution est de proposer un protocole de routage réduisant le nombre de collisions.

Les collisions entraînent une consommation excessive de la bande passante disponible du réseau. Dans

les réseaux MANETs, un nœud émetteur détecte la présence d’une collision seulement s’il ne reçoit

pas un acquittement, durant un temps d’attente donné, à son paquet de données. Lors de la détection

d’une collision, le nœud émetteur retransmet son paquet de données. Les retransmissions nécessaires à

la réception correcte d’un paquet consomment de la bande passante. De même, ces retransmissions

successives augmentent le délai de bout en bout d’un paquet de données. La présence d’un tel retard

peut avoir des répercussions néfastes sur le fonctionnement des applications multimédia ou temps-réel.

Après avoir mis en évidence les différents facteurs (nombre de nœuds voisins, délai de transmission

d’un paquet, charge d’un lien et délai de propagation) intervenant sur l’occurrence de collision, nous

proposons un protocole de routage réduisant les collisions. Le protocole de routage utilise une fonction

poids dépendante de trois facteurs (la capacité d’un lien, la bande passante disponible et le nombre de

voisins) pour déterminer la qualité d’une route. Sélectionner un lien sur sa capacité de transmission

permet d’influer sur le délai de transmission d’un paquet. Plus la capacité de transmission est

importante, plus le temps de transmission d’un paquet est faible. La bande passante disponible d’un

lien permet d’évaluer sa charge. Un lien saturé limite le nombre de paquets échangés et accroît le

nombre de collisions. Le nombre de voisins influe directement sur la probabilité d’obtenir une

collision. Plus le nombre de voisins est important, plus les risques de collision croissent.

La surconsommation de bande passante lors de la création des routes est notre second axe de recherche.

Lors de la détermination d’une route par un protocole de routage réactif, certaines informations de

routage ne sont pas nécessaires. Les informations transmises dans le sens opposé de la destination,

sont, bien souvent inutiles. L’efficacité du protocole de routage peut être améliorée en contrôlant la

dissémination des informations de routage. L’espace dans lequel est disséminée l’information de

routage est, ainsi, réduit. Une telle réduction de l’espace de recherche nécessite la connaissance de la

localisation du nœud destination. Le premier défi est donc de localiser la destination.

3

Afin de localiser la position de la destination, nous proposons un protocole utilisant un réseau à

backbone. Un réseau à backbone utilise deux types de nœuds pour communiquer : les nœuds de

backbone et les nœuds normaux. Les nœuds de backbone forment une dorsale sans fil centralisant les

informations de localisation sur le réseau MANET. Le réseau à backbone décharge le réseau ad hoc de

l’échange des informations de localisation. La position d’un nœud destination est rapidement

déterminée par un léger échange sur le réseau MANET. Pour éviter de déterminer à chaque rupture de

route la position du nœud destination, il peut propager périodiquement, au nœud source, des

informations concernant sa mobilité (vitesse, direction, position…). Ces informations sont transmises

à travers le réseau à backbone pour en diminuer l’impact sur le réseau MANET.

En connaissant la position de la destination, le protocole de routage peut dorénavant réduire l’espace

de recherche. Une réduction de l’espace de recherche réduit les informations de routage nécessaires à

la détermination d’une route. En contrepartie, les risques de ne pas trouver une route sont plus

importants. Nous proposons deux protocoles de routage effectuant une recherche de parcours en

profondeur. Ainsi, la taille de l’espace de recherche du protocole de routage est agrandie lorsqu’une

route n’a pas pu être trouvée. Le premier protocole de routage proposé est optimal c'est-à-dire qu’une

route est trouvée s’il en existe une. Chaque nœud faisant partie de la zone de recherche propage la

requête. Si la tentative échoue à trouver une route, la zone de recherche est agrandie et la source

propage une nouvelle requête. Chaque nœud ayant reçu une requête lors d’une tentative précédente la

retransmet. Le deuxième protocole de routage est non optimal c'est-à-dire qu’un chemin peut ne pas

être trouvé même s’il en existe un. Dans ce protocole, chaque nœud de la zone de recherche ne

transmet qu’une seule fois le paquet quelque soit la tentative réalisée.

Pour certaines applications temps-réel et/ou multimédia, l’augmentation de la bande passante n’est pas

toujours suffisante. Certaines applications nécessitent le respect de contraintes de qualité de service

(QoS) telles que le délai et la bande passante. Pour permettre le respect de telles contraintes, une

méthode de réservation de bande passante doit être utilisée. Dans une méthode d’accès au support

comme CSMA/CA, la réservation est très difficile à cause de la présence de collisions. Des méthodes

sans contention, telles que TDMA, sont plus adaptées pour permettre le respect des contraintes de QoS.

La méthode TDMA divise le temps d’accès au support de communication en slots. Un nœud peut

réserver en émission un slot uniquement s’il ne l’utilise pas déjà et si aucun de ses nœuds voisins ne

l’a réservé en réception. De même, un nœud peut réserver un slot en réception uniquement s’il ne

l’utilise pas et si aucun de ses nœuds voisins ne l’a réservé en émission. La réservation d’un slot par un

nœud impacte donc les nœuds voisins puisqu’ils ne peuvent pas réserver un tel slot. Ces contraintes

sur la réservation des slots réduisent, par conséquent, la bande passante utile du réseau mais

empêchent l’apparition de collisions.

Nous proposons un protocole de routage permettant de diminuer le nombre de slots impactés par la

réservation des slots lors de la création d’une nouvelle route. Pour cela, une fonction poids, pénalisant

de manière exponentielle le nombre de voisins rencontré par un chemin et de manière linéaire la

contrainte de délai, est utilisée. Les paquets de routage sont propagés par un nœud si la demande de

création de route est nouvelle ou si le poids de la sous-route est plus faible que la sous-route

précédente.

4

3. Organisation du mémoire

Ce mémoire de thèse est organisé en six chapitres. Le premier présente les réseaux MANETs dans un

contexte général et les réseaux ad hoc IEEE 802.11. Le second chapitre se focalise sur les protocoles

de routage Meilleur Effort. Nous y étudions notamment AODV sur lequel nos travaux sont basés. Le

troisième chapitre présente la notion de qualité de service, et les protocoles de routage à QoS

garantissant les contraintes de délai ou de bande passante. Le quatrième chapitre présente un protocole

de routage réduisant l’impact des collisions sur le réseau. Le cinquième chapitre se focalise sur la

diminution des informations de routage en utilisant des informations de localisation. Le sixième

chapitre présente un protocole de routage à QoS pour l’optimisation de la bande passante avec le

respect des contraintes de délai et de bande passante. Notre travail se termine par une conclusion et

une présentation de quelques perspectives pour la poursuite de ce travail.

5

1 Introduction aux Réseaux Mobiles Ad hoc (MANETs)

L’explosion des communications téléphoniques ou informatiques dans les années 90 a conduit à une

utilisation toujours plus croissante des réseaux de communication. Initialement de simples supports de

communication, les réseaux sont aujourd’hui devenus des enjeux majeurs pour l’avenir. L’apparition

d’internet et son succès, la démocratisation des terminaux (ordinateurs, PDA, téléphones portables,

boitiers triple-play…) sont autant de facteurs qui changent notre mode de vie. Ce changement s’est

aussi opéré dans notre relation avec les moyens de communication. De sédentaire, l’utilisation devient

de plus en plus mobile (téléphones, ordinateurs portables…) mais aussi embarquée au sein de

véhicules. Cette mobilité est un enjeu important des réseaux d’aujourd’hui et de demain. De fait, les

réseaux ont dû s’adapter à cette nouvelle donne. Nos travaux s’inscrivent dans cette optique

d’utilisation de mobiles.

Parallèlement à ces changements, de nouvelles utilisations sont apparues. Ces utilisations

transparaissent dans les termes multimédia et temps-réel. Actuellement, tout réseau sans fil doit, en

plus d’offrir un moyen de communication, respecter les contraintes qui lui sont imposées par les

applications. Il doit offrir un débit suffisamment élevé et doit pouvoir être facilement et rapidement

déployé. Les terminaux doivent être également légers.

Nous positionnons le contexte de notre étude sur les besoins de mobilité des utilisateurs et sur leur

besoin d’utiliser des applications contraintes ou fortement consommatrices en bande passante. Ce

chapitre a pour objectif de présenter les réseaux ad hoc mobiles et plus précisément les réseaux ad hoc

mobiles IEEE 802.11. Les modèles de mobilité sont aussi évoqués en fin de chapitre. Nous conclurons

enfin ce chapitre par une critique sur l’adéquation de ces réseaux ad hoc à notre contexte.

6

1.1 Contexte des travaux

Dans un monde toujours plus interconnecté, le besoin de communiquer librement ne se dément pas.

Les réseaux filaires souffrent de leur manque de flexibilité au regard des besoins de mobilité des

utilisateurs. Les réseaux sans fil se positionnent en alternative des réseaux filaires sur ce point. En effet,

les réseaux sans fil imposent moins de contraintes de déploiement et de mobilité que leurs homologues

filaires. De fait, l’utilisation de réseaux sans fil est entrée dans la vie courante de la majorité des

utilisateurs. Ces réseaux se retrouvent dans toutes les sphères des équipements électroniques habituels :

micro-informatique, téléphones portables, consoles de jeux, appareils multimédia, etc.

Les utilisateurs souhaitent pouvoir profiter de leur réseau sans fil quelque soit les situations dans

lesquelles ils se trouvent. Les réseaux mobiles ad hoc ont été conçus dans cette optique. Généralement,

ce type de réseau est mis en œuvre lorsqu’une infrastructure sans fil est difficilement envisageable ou

indisponible. De même, lors de l’utilisation de courte durée ou soudaine de certaines applications, il

est aisé d’utiliser un tel type de réseaux car il est facilement déployable et auto-organisé. Son faible

coût participe à son succès.

Les habitudes des utilisateurs ne doivent pas être modifiées par l’utilisation d’un réseau sans fil. De

fait, les réseaux sans fil doivent fournir les mêmes besoins, le respect des mêmes contraintes que leurs

homologues filaires. Les applications multimédia et temps-réel ne doivent pas, non plus, souffrir de la

présence d’un environnement mobile. Les domaines d’applications des réseaux sans fil ad hoc sont

nombreux et nous pouvons citer les applications suivantes :

• Applications collaboratives : Les utilisateurs professionnels ont besoin d’applications

particulières lors d’échanges entre collaborateurs. Ainsi, au cours de réunions ou de

conférences, ces utilisateurs peuvent ressentir le besoin de former dans n’importe quel lieu un

réseau pour s’échanger des informations, ou faire une vidéoconférence entre bureaux voisins.

Les réseaux ad hoc sont bien appropriés à ces besoins.

• Jeux Vidéo : Les réseaux sans fil sont bien adaptés pour permettre l’échange d’informations

entre applications personnelles. Ainsi, pour les utilisateurs voulant jouer en réseau, il est facile

et à faible coût de déployer un réseau ad hoc.

• Urgences : Lors de catastrophes d’origine naturelles (comme les tremblements de terre, les

tsunamis, les feux de forêt ou d’habitations…) ou non, les infrastructures préexistantes

peuvent ne pas être opérationnelles compliquant d’autant plus les besoins de communications

des moyens de secours. Les réseaux sans fil, par leur compacité et leur rapidité de déploiement,

permettent aux différentes équipes de secours d’établir rapidement des liaisons et d’échanger

des informations.

• Militaires : Lors d’interventions en milieu hostile, il peut être difficile ou trop encombrant

d’utiliser un réseau à infrastructure. Les réseaux sans fil sont parfaitement bien adaptés à ce

type d’environnement où les déplacements restent peu rapides et peu soutenus. A titre

d’exemple, le département militaire Américain a développé le projet SLICE (Soldier Level

7

Integrated Communications Environment) pour permettre la communication des soldats lors

d’interventions militaires. L’idée sous-jacente est que chaque soldat soit équipé d’un

ordinateur portable relié à un casque et un microphone. Le projet SLICE est censé créer un

réseau sans fil ad hoc permettant le transfert de la voix entre différents soldats.

• Systèmes embarqués : Un bon exemple, pour l’utilisation des réseaux sans fil dans les

applications embarquées est le projet V2V (Vehicle to Vehicle). En effet, un consortium de

constructeurs automobiles s’est focalisé sur l’échange d’informations entre véhicules

automobiles afin d’améliorer la sécurité des usagers de la route. Le but de ce projet est de faire

communiquer, entre eux, au moyen d’un réseau et ce de manière transparente, plusieurs

véhicules proches. En cas de danger (accident, bouchon, brusque ralentissement…), le premier

véhicule détectant ce danger prévient les autres véhicules. Chacun de ces derniers véhicules

informant à leur tour d’autres véhicules que les conditions de circulation ont évolué. Le

conducteur est à ce moment là prévenu par un voyant lumineux ou sonore du danger et de la

conduite à adopter.

• Réseaux de capteurs : Les réseaux de capteurs sont des réseaux sans fil dont les équipements

se déplacent très peu, et dont la durée de vie des batteries est limitée. Ces équipements peu

coûteux permettent de fournir par exemple des informations sur la température à différents

endroits d’une chambre froide, le niveau d’ensoleillement d’une pièce, la santé des animaux

dans un zoo…

Le contexte de nos travaux est celui des réseaux sans fil ad hoc pour les domaines d’applications

collaboratives, d’urgences et vidéo-ludiques. Les applications les plus représentatives de ces domaines

concernent les applications multimédia et temps-réel. Dans le même contexte, nous restreignons à une

surface d’environ 1km² (par exemple un campus universitaire) la superficie des réseaux étudiés.

1.2 Les réseaux mobiles ad hoc (MANETs)

Un réseau mobile ad hoc ou réseau MANET est un réseau sans fil capable de s’organiser sans

infrastructure définie préalablement. Un tel réseau est composé de stations mobiles ou nœuds qui

peuvent communiquer directement entre eux s’ils sont situés à portée radio.

Un réseau MANET n’est pas lié à une technologie de communication sans fil particulière. De

nombreuses technologies sans fil permettent le déploiement d’un réseau MANET : les réseaux sans fil

personnels (WPAN) avec les réseaux de type Bluetooth [Bluetooth] et Zibgee [Zigbee], les réseaux

sans fil locaux (WLAN) avec IEEE 802.11 (ou WiFi [WiFi]) et HyperLan de type 1 [ETSI 98-1]. La

surface d’1 km² de notre contexte d’étude écarte les réseaux de type WPAN. De plus, nous avons

choisi de nous restreindre aux réseaux IEEE 802.11 du fait de leur fort déploiement.

Les réseaux MANETs possèdent de nombreuses contraintes (cf. §1.2.2) liées à leurs caractéristiques

(cf. §1.2.1). Pour que les réseaux MANETs soient utilisables pour le support de flux multimédia et

8

temps-réel, il est nécessaire d’apporter des solutions sur certaines de ses limitations. Les réseaux

MANETs offrent, donc, un axe de recherche intéressant.

1.2.1 Caractéristiques des réseaux MANETs

Un réseau mobile ad hoc (réseau MANET) possède des caractéristiques particulières [RFC 2501]

comparé aux autres réseaux sans fil :

• Mobile : Les stations ne sont pas fixes dans les réseaux MANETs. Elles peuvent se déplacer et

sont entièrement indépendantes. A tout moment, de nouvelles stations peuvent joindre le

réseau ou le quitter. Le changement de la topologie d’un réseau MANET dans le temps est un

élément primordial.

• Sans fil : Les stations d’un réseau MANET utilisent un support sans fil pour communiquer

entre elles. Elles partagent le même média lors des échanges d’informations. De fait, ce

partage et ses conséquences (collisions, réservation de ressources…) sont autant d’éléments à

prendre en compte.

• Sans infrastructure : Par nature, les réseaux MANETs ne dépendent pas d’une architecture

fixe. Ils peuvent donc être facilement déployés.

• Auto-organisé et distribué : Les réseaux MANETs ne disposent pas de point central pour

coordonner ou centraliser les échanges. De fait, ces réseaux doivent s’auto-organiser afin

d’opérer. De plus, l’absence de centralisation demande à chaque acteur du réseau de participer

au bon fonctionnement du réseau (distribution).

• Multi-saut : Comme la portée des stations est limitée, il peut s’avérer nécessaire que des

stations agissent en tant que pont intermédiaire pour transmettre un paquet d’une source vers

une destination. Par conséquent, les nœuds d’un réseau MANET agissent en tant que routeur

et relayent les paquets qu’ils reçoivent pour participer au routage multi-saut.

• Ressources limitées : Les ressources limitées touchent toute la chaîne de communication d’un

réseau MANET en commençant par les nœuds jusqu’aux liens de communication. Les

terminaux étant mobiles, ils fonctionnent principalement sur batterie. La mobilité contraint

également la puissance embarquée. La capacité des liens sans fil s’avère aussi limitée

comparativement aux réseaux filaires. De même, le taux d’erreur est bien plus élevé que dans

un réseau filaire.

• Temporaire et rapidement déployable : Ce type de réseau est intrinsèquement temporaire et

rapidement déployable. Il n’a pas pour but de remplacer un réseau à infrastructure mais de le

compléter ou de le remplacer lorsque nécessaire.

9

1.2.2 Contraintes liées aux réseaux MANETs

Les caractéristiques des réseaux ad hoc impliquent des contraintes spécifiques [DHA 05-1] sur leur

fonctionnement et donc leurs performances. Les principaux problèmes susceptibles d’être rencontrés

dans un environnement mobile et ad-hoc peuvent être regroupés en deux catégories selon la source du

problème :

1) Limitations dues au support de transmission :

• Partage du support de transmission : Les stations mobiles opèrent sur la même bande de

fréquence. Le partage du support de transmission peut engendrer des collisions. Ce problème

est lié également à la diffusion des signaux.

• Taux d’erreur élevé : Les réseaux sans fil utilisent des ondes radio pour communiquer. Ces

ondes ne peuvent pour autant s’affranchir des contraintes liées à leur medium de transmission,

l’air. Les perturbations électromagnétiques, solaires ou les obstacles affectent les signaux

transmis et sont de fait source de taux d’erreur en bit particulièrement élevés.

• Capacité des liens variables : Les réseaux sans fil doivent aussi faire face à la variabilité de

leur support de transmission. De fait, les caractéristiques et performances des liens entre deux

stations varient constamment. Ainsi, certains liens bidirectionnels, peuvent voir leurs

performances chuter et devenir des liens unidirectionnels.

• Faible débit : La modestie des débits des réseaux sans fil est un élément souvent mis en avant.

Comparés à certains réseaux filaires, les débits peuvent paraitre faibles. Et dans le cadre de

transferts multimédia nécessitant des échanges de données soutenus, ces débits peuvent ainsi

poser problème.

• Variation de la qualité du signal : Le canal ne cesse de changer avec le temps. En effet, les

conditions extérieures peuvent modifier les caractéristiques de ce canal, par exemple la pluie

peut accroître le taux d’affaiblissement de la liaison sans fil. De même, l’apparition

d’obstacles peut modifier le canal augmentant le nombre de trajets entre une source et une

destination.

• Sécurité : Les signaux étant diffusés, ils peuvent être écoutés par toute station mobile se

trouvant dans la même zone de couverture. La confidentialité de certaines informations

nécessite l’utilisation de mécanismes de sécurité adéquats.

2) Limitations dues aux stations mobiles :

• Faible puissance : Les stations mobiles sont la plupart du temps conçues pour une utilisation

mobile. De fait, elles se doivent d’être légères, de petite taille et surtout doivent être capables

de fonctionner de manière autonome (sur batterie). La prise en compte de tous ces éléments

participe à la faible puissance de l’électronique embarquée.

10

• Durée d’utilisation restreinte : Les batteries ont une durée de vie limitée. De fait, le temps

d’utilisation nomade d’une station est contraint par la capacité de sa batterie mais aussi par la

puissance demandée (ressources processeur ou transmissions sans fil). Il est nécessaire de

trouver un juste milieu entre ces composantes.

• Rayon d’action : La zone de couverture est fonction de la puissance d’émission que peut

fournir une station. Le standard IEEE 802.11 définit la puissance maximale à 100mW.

Réduire la puissance d’émission, pour notamment économiser de l’énergie, peut engendrer des

liens unidirectionnels.

• Modification de la topologie du réseau avec le temps : Les stations pouvant être en constant

déplacement, la topologie du réseau évolue également. Le voisinage d’un nœud peut varier

continuellement : à tout moment des stations peuvent joindre ou quitter le réseau. La

modification de la topologie est directement fonction de la vitesse de déplacement des stations

et du rayon d’action du réseau. Avec un déplacement rapide et soutenu de l’ensemble des

stations, la topologie ne cesse d’évoluer.

• Altération des signaux : Le déplacement des stations modifie la fréquence des signaux reçus

par effet Doppler. Ainsi, à haute vitesse les signaux peuvent s’avérer incompréhensibles.

Le contexte de notre étude permet la cohabitation d’applications multimédia ou temps-réel fortement

consommatrices en bande passante avec un environnement mobile ad hoc. Nous investiguons, par

conséquent, dans la suite de nos travaux les contraintes suivantes : le faible débit, la capacité des liens

variables et la modification de la topologie du réseau avec le temps.

1.3 Réseaux IEEE 802.11

La norme IEEE 802.11 [IEEE 99-1] couvre les deux premières couches du modèle OSI, c'est-à-dire la

couche physique (niveau 1) et la couche liaison de données (niveau 2). La couche physique diffère

suivant le standard IEEE 802.11 utilisé. Ainsi, des débits variables pourront être atteints selon le

standard utilisé (par exemple les standards IEEE 802.11g [IEEE 03-1] et IEEE 802.11a [IEEE 99-2]

permettent d’atteindre 54Mb/s comparé aux 11Mb/s du standard IEEE 802.11b [IEEE 99-1]). Les

nouveaux standards sont rétro compatibles avec les standards précédents à l’exception notable du

802.11a. Ainsi le standard IEEE 802.11g permet d’atteindre un débit théorique maximal de 54Mb/s

mais également les débits 11Mb/s, 5.5 Mb/s, 2Mb/s et 1Mb/s.

1.3.1 IEEE 802.11 mode infrastructure / mode ad hoc

Le réseau IEEE 802.11 permet l’interconnexion de terminaux sans l’utilisation de câble. Deux modes

sont configurables pour permettre un dialogue entre stations distantes, le premier est le mode à

infrastructure, le second étant le mode ad-hoc.

11

Dans le mode à infrastructure, les communications sont centralisées par un point d’accès. Ainsi

lorsqu’une station veut communiquer avec son homologue, les données doivent au préalable transiter

par le point d’accès qui les retransmet après un certain délai. Le mode ad hoc est un mode bien moins

complexe que le mode à infrastructure. Il permet la communication entre deux machines si chacune

appartient à la zone de couverture de l’autre. La zone de couverture d’une station est la zone dans

laquelle toute autre station peut correctement recevoir les données transmises.

1.3.2 La couche physique

La couche physique définit les aspects électriques, mécaniques et fonctionnels de l’accès au canal de

communication, ainsi que les protocoles d’échange de données via le réseau. Elle assure entre autres,

les relations entre les couches supérieures et le matériel.

Cette couche est divisée en deux sous couches : la sous-couche PLCP (Physical Layer Convergence

Protocol) est chargée de l’écoute du support et de la signalisation vers la couche MAC ; La sous-

couche PMD (Physical Medium Dependent) se focalise sur l’encodage des données et la modulation.

Figure 1-1 : Couche Physique IEEE 802.11

Nous présentons dans cette section uniquement les aspects de la sous-couche PMD et plus précisément

les aspects de modulation. Les modulations employées par la couche physique des différentes normes

IEEE 802.11 sont représentées sur la figure 1-1. La norme physique initiale 802.11 (ratifiée en 1997)

propose deux types de transmission à modulation de fréquence (FHSS et DSSS) associés à une

modulation de phase et une technique de transmission à infrarouge (IR) utilisée surtout en milieu

industriel. Avec l’apparition des standards (IEEE 802.11a et IEEE 802.11g), une autre modulation de

fréquence (OFDM) a été adoptée accroissant les débits offerts.

• Infrarouge (IR) : Le mode de communication par infrarouge est simple, peu réglementé et peu

coûteux. En utilisant un faisceau de lumière, ce mode est basé sur l’utilisation des mêmes

fréquences que celles utilisées par les fibres optiques.

12

• Etalement de spectre avec saut de fréquence (FHSS) : Au départ utilisé par les militaires afin

de chiffrer les communications, cette technique de modulation est assez répandue (depuis la

standardisation des séquences de fréquences) car elle permet de remédier aux problèmes

d’interférences. Cette technique modifie la fréquence de la porteuse d’après une séquence de

sauts. En fait, l’émetteur change de fréquence d’émission de façon périodique et suivant une

séquence préétablie.

• Etalement de spectre à séquence directe (DSSS) : Cette technique de modulation de fréquence

est appelée à étalement de spectre car l’information est directement modulée par un code de

débit beaucoup plus important. Le signal résultant occupe donc une bande passante très

importante.

• Multiplexage par répartition orthogonale de fréquence (OFDM) : Cette technique est apparue

après le constat que plus un symbole est long plus les interférences inter symboles sont

moindres. La technique OFDM divise la bande de fréquence initiale en canaux qui sont eux-

mêmes divisés en un nombre important de sous canaux. C’est la transmission en parallèle de

plusieurs sous canaux à faible débit qui va créer un seul canal à haut débit.

1.3.3 Sous-couche MAC

La sous-couche MAC caractérise l’accès au médium de façon commune aux différentes normes IEEE

802.11. Elle met en œuvre les fonctionnalités nécessaires pour la réalisation d’une transmission

correcte point à point :

• détection d’erreur (CRC),

• retransmission en cas de perte ou de trame erronée,

• envoi d’accusé de réception,

• fragmentation des données.

La sous-couche MAC permet deux types d’accès au canal :

• PCF (Point Coordination Control) : Ce type d’accès est centralisé. Ainsi, un équipement tiers

(point d’accès ou station de base) doit faire office de maître distribuant à tour de rôle l’accès

au canal aux stations connectées. Une station ne peut émettre que si elle est autorisée et ne

peut recevoir que si elle est sélectionnée. Ce type d’accès au canal a été développé pour

transmettre du trafic avec des contraintes temporelles (vidéo à la demande, visioconférence…).

Le mode PCF est particulièrement bien adapté au mode infrastructure de la norme IEEE

802.11.

• DCF (Distributed Coordination Function) : Dans ce mode, l’accès se fait par compétition.

Chaque station essaye d’obtenir le support lorsqu’elle doit transmettre des données.

13

Contrairement au mode PCF, ce type d’accès au canal peut être utilisé à la fois par le mode

infrastructure et le mode ad hoc.

Étant donné que nous nous focalisons sur le mode ad hoc et que PCF se concentre sur le mode

infrastructure, nous ne détaillerons pas plus avant ce mode dans ce document. Nous nous attacherons

seulement au mode d’accès DCF.

1.3.4 Accès au canal de manière distribuée

Le protocole d’accès au canal de la norme IEEE 802.11 est CSMA/CA (Canal Sense Multiple Access/

Collision Avoidance). Ce protocole s’est fortement inspiré du protocole filaire IEEE 802.3

(CSMA/CD) [IEEE 85-1]. CSMA/CA est une technique d’accès aléatoire au support avec écoute au

préalable de la porteuse, qui permet d’écouter le support de transmission avant d’émettre. Ainsi, la

transmission est effectuée uniquement si le support est libre diminuant ainsi le risque de collisions. Ce

risque est réduit mais n’est pas pour autant nul. Contrairement à CSMA/CD (où chaque nœud écoute

le support pendant qu’il transmet l’information pour détecter collision), la détection de collisions n’est

guère possible dans les réseaux sans fil, car l’émetteur est incapable d’écouter le support tout en

transmettant son information. Par conséquent, le récepteur doit prévenir l’émetteur que la transmission

s’est correctement passée. Ainsi après la réception d’une trame de données, le récepteur acquitte celle-

ci si aucun problème (collision, perte, erreur de transmission…) n’a eu lieu durant la transmission. A

la bonne réception de l’acquittement, l’émetteur en déduit que la transmission s’est correctement

déroulée.

Pour répondre à des problèmes de partage du support, deux modes sont disponibles dans la norme

IEEE 802.11 pour accéder au canal de manière distribué : le mode DCF et le mode optionnel DCF-

RTS/CTS (mode DCF avec l’ajout de requêtes RTS/CTS).

1.3.4.1 Mode DCF

Le protocole DCF est basé sur le protocole MACAW (Multiple Access Collision Avoidance Wireless)

[BHA 94-1]. Il utilise différents intervalles de temps pour discriminer l’accès au support des stations.

Ainsi une station souhaitant transmettre un acquittement a un temps d’accès au support plus faible

qu’une station voulant émettre une trame de données. Pour cela, un ensemble d’intervalles de temps

est spécifié par le protocole DCF. Ces intervalles sont des multiples d’un intervalle de base IFS

(InterFrame Spacing) :

• Short InterFrame Space (SIFS) : représente le plus faible intervalle de temps disponible dans

le protocole DCF. Par conséquent, il possède la plus forte priorité. Il est utilisé pour séparer

les différentes trames transmises au sein d’un même dialogue (par exemple entre une trame de

données et son acquittement).

• DCF InterFrame Space (DIFS) : correspond au temps d’attente utilisé pour l’écoute préalable

du canal avant toute transmission de trame de données.

14

• Extended InterFrame Space (EIFS) : c’est le plus long des temps d’attente. Il est uniquement

utilisé par une station lorsqu’elle reçoit une trame indéchiffrable. Elle doit attendre pendant un

EIFS avant l’envoi d’une autre trame.

Le fonctionnement du protocole DCF est relativement simple. Lorsqu’un nœud désire transmettre une

trame, il s’assure tout d’abord que le médium soit libre durant un temps DIFS plus long que SIFS afin

de donner une priorité absolue aux acquittements. Le cas échéant, il effectue la transmission, puis

attend l’acquittement correspondant de la part du récepteur. L’absence de réception de cet

acquittement provoque la retransmission de la trame et ce processus est répété jusqu’au succès de

l’opération ou jusqu’à atteindre le nombre maximal de retransmission. Dans ce dernier cas, la trame

est détruite.

Si l’émetteur constate que le médium est déjà occupé lorsqu’il souhaite transmettre, il reporte sa

transmission jusqu’à la libération du support. Toutefois, si plusieurs nœuds sont en attente de la fin

d’une même transmission, elles ne doivent pas commencer à émettre au même moment, sans quoi une

collision surviendrait irrémédiablement. C’est pourquoi lorsque le canal radio se libère, tout émetteur

désirant accéder au médium attend un temps aléatoire en plus du temps DIFS. Chaque émetteur

potentiel tire de façon uniforme un nombre aléatoire (appelé backoff) dans un intervalle de temps

appelé fenêtre de contention. Cette valeur est ensuite décrémentée d’une unité à chaque intervalle de

temps passé sans que le support ne soit occupé. La première station à atteindre la valeur 0 émet alors

sa trame. Les autres nœuds suspendent le processus qui est repris dès la fin de la transmission. Un

nœud voulant émettre plusieurs trames en séquence doivent passer par une procédure d’attente

aléatoire entre deux trames afin de ne pas monopoliser le support.

Figure 1-2 : Exemple d’accès au médium pour 3 stations

L’exemple de la figure 1-2 met en scène trois stations à portée de communication. A l’instant t0, le

nœud A est en train d’émettre, les deux autres attendent la libération du canal. A l’instant t1, la

transmission est terminée, les deux émetteurs (B et C) patientent un temps DIFS avant de commencer

à décrémenter leur backoff. Après sa transmission, le nœud A rentre en compétition avec les autres

nœuds puisqu’il possède encore une trame à transmettre. Il tire le plus petit nombre aléatoire et gagne

la contention à t2. Le processus de décrémentation est alors suspendu pour les deux autres et reprendra

15

à t3. Le nœud B sera alors le premier à gagner la contention car son backoff restant est plus petit que

celui de C.

1.3.4.2 Mode DCF avec RTS/CTS

Cette méthode d’accès [ISS 03-1] au support est proposée en option dans la norme IEEE 802.11. Cette

méthode permet à une station d’obtenir la totalité du support pendant le temps de la transmission de

ses données. Les collisions peuvent ainsi être évitées durant les transmissions. Pour cela, il y a une

période d’accès au support avec contention, c'est-à-dire qu’il y a compétition entre les stations pour

obtenir l’exclusivité du canal. Pour que cette méthode d’accès fonctionne, il est nécessaire que toutes

les stations connaissent ce mode d’accès. Il n’est pas obligatoire que toutes les stations utilisent ce

mode d’accès, d’autres ont la possibilité d’utiliser la méthode DCF.

Figure 1-3 : Partage du canal par trois stations avec la méthode RTS/CTS

Pour éviter d’éventuelles collisions, les stations voulant transmettre une trame de données émettent

une trame RTS (Request To Send) après une écoute préalable du support durant DIFS unités de temps

et de l’attente du backoff. Lorsque le récepteur reçoit cette trame, il émet à son tour une trame CTS

(Clear To Send) avec une attente de SIFS secondes après la réception du RTS. Les trames RTS et CTS

initialisent le vecteur d’allocation du réseau (NAV) avec la durée durant laquelle le médium sera

occupé. Les nœuds réceptionnant une de ces deux trames retarderont ainsi la transmission de leurs

données de la durée exprimée dans le RTS ou le CTS. De fait, les nœuds dans le voisinage de

l’émetteur et du récepteur ne peuvent entrer en collision pendant la phase de transmission de données.

Cette période est nommée période sans contention. Le fonctionnement de ce mécanisme est illustré par

la figure 1-3.

Le mécanisme RTS/CTS participe à la réduction de l’impact des collisions puisqu’elles n’affectent

que les trames courtes (RTS et CTS). Par contre, il n’est pas systématiquement utilisé. L’échange des

RTS et CTS ajoute un surcoût à chaque trame de données, réduisant d’autant le débit utile du canal de

transmission. Ces trames étant transmises à un débit de 2Mbit/s afin de garantir une certaine

RTS

CTS

Données

ACK

NAV (RTS)

NAV (CTS)

SIFS

SIFS

SIFS

DIFS

Accès au médium retardé

Emetteur

Récepteur

16

compatibilité avec la première version du standard, la durée de cet échange est de 564 μs

(TRTS + TCTS + 2×SIFS), soit le temps nécessaire pour transmettre 6 204 bits à un débit de 11 Mbit/s. Ce

mécanisme s’avère assez coûteux pour une utilisation systématique. Les cartes d’interface proposent

en général de n’utiliser ce mécanisme que pour des trames excédant une taille RTSThreshold

(paramétrable).

Figure 1-4 : Problèmes des nœuds cachés

L’utilisation de cette technique d’accès permet de résoudre certains problèmes présents dans le mode

DCF (tel que le problème des nœuds cachés [FUL 97-1]). Ce problème est illustré sur la figure 1-4.

Les nœuds A et C étant séparés par une cloison, ils ne se voient pas. Le nœud C n’entendant pas que A

est en train de transmettre, elle considère que le support est libre ce qui en réalité n’est pas le cas. Les

transmissions des deux trames créent des collisions lors du recouvrement des deux zones de

couverture de ces stations au niveau du nœud B. En utilisant, la méthode d’accès au support DCF avec

RTS/CTS, le nœud C ne recevrait pas la trame RTS puisqu’elle n’est pas dans la zone de couverture

de A mais recevrait la trame de réponse CTS. En recevant cette trame de réponse, elle connaît

dorénavant le temps durant lequel le support sera occupé. C peut ainsi retarder sa transmission et

éviter les collisions.

Ce mécanisme ne permet tout de même pas de résoudre l’ensemble du problème des nœuds cachés

[CHA 04-1]. En effet, le mécanisme RTS/CTS échoue avec le réseau représenté sur la figure 1-5. Soit

le nœud A, le premier nœud à vouloir acquérir le support. Il commence par émettre une trame RTS

pour demander cette acquisition. Le nœud C, n’étant pas dans la zone de couverture de A, ne peut

entendre cette trame. Le nœud B voyant que cette trame lui est destinée répond par une trame CTS. A

CLOISON

A

C

B

17

ce même instant, le nœud C émet une trame RTS en destination de D. Il ne peut comprendre le CTS

émis par B puisqu’il est en train d’émettre. La transmission entre C et D peut par conséquent avoir lieu.

Une collision survient, par conséquent, au niveau de B. Ce type de situation est tout de même

relativement rare, puisqu’il est nécessaire que le CTS du nœud B et le RTS du nœud C soient émis

dans le même laps de temps.

Figure 1-5 : L’utilisation du mécanisme RTS/CTS n’empêche pas la totalité des collisions.

1.4 Accès au canal sans contention

Le mode DCF de la norme IEEE 802.11 (avec l’ajout ou non des paquets RTS/CTS) ne peut empêcher

la présence de collisions. De fait, la bande passante utile du réseau est ainsi réduite. Les collisions

augmentent le délai de bout en bout des paquets de données. Les données de certaines applications

nécessitent le respect d’un délai. Des méthodes d’accès sans-contention ont ainsi été proposées. La

méthode d’accès TDMA (Time Division Multiple Access) [JAW 05-1] est largement utilisée dans les

réseaux pour garantir à un utilisateur l’accès unique au support à un instant donné.

Dans un environnement synchronisé de type TDMA, la bande passante requise par une application est

représentée par le nombre de slots nécessaires à réserver dans la fenêtre TDMA. Chaque lien, d’une

route, doit réserver un nombre de slots pour satisfaire les besoins d’un flux. Lorsqu’un flux arrive à

son terme, les slots réservés sont libérés. Ils peuvent être ainsi réutilisés par d’autres flux.

Figure 1-6 : Structure d’une fenêtre TDMA de M slots de données par fenêtre, pour un réseau de N

nœuds.

18

Une fenêtre TDMA est composée d’une phase de contrôle et d’une phase de données (figure 3-2).

Chaque nœud, dans le réseau, possède un slot de contrôle qui lui est désigné (slots de contrôle 1 à N

dans l’exemple). Les nœuds les utilisent pour transmettre leurs informations de contrôle telles que les

trames de synchronisation, les informations de routage… Cependant, les nœuds sont en compétition

pour acquérir un ou plusieurs slots de données libres (slots de données 1 à M dans l’exemple).

Trois règles doivent être respectées pour réserver un slot [LIA 02-1]. L’utilisation de ces règles permet

d’éviter les collisions lors de transmissions simultanées. Elles permettent également de résoudre

entièrement le problème des nœuds cachés (cf. §1.3.4.2). Un slot t est considéré libre et réservable,

pour envoyer des données d’un nœud A à un nœud B, si les conditions suivantes sont respectées :

• Le slot t n’est pas déjà réservé en réception ou en émission, par le nœud A ou B.

• Le slot t n’est réservé en réception par aucun nœud C situé à un saut du nœud A.

• Le slot t n’est réservé en émission par aucun nœud C situé à un saut du nœud B.

Si à tout instant ces trois règles sont respectées, le réseau reste exempt de collisions. L’évitement des

collisions permet de maitriser pleinement la bande passante réservée et le délai d’un paquet. Cette

méthode d’accès au support est particulièrement bien adaptée au respect des contraintes de QoS des

applications temps-réel et multimédia.

1.5 Modèles de mobilité

La mobilité dans les réseaux ad hoc est un point délicat à traiter. Le déplacement des stations rompt les

liaisons avec les voisins et complexifie la gestion du multi-saut dans les réseaux ad hoc. En effet, les

routes entre deux stations doivent constamment s’adapter au changement de la topologie pour

maintenir la continuité de la communication.

Prévoir le déplacement des stations peut aider à connaître les instants où une station va rompre la

liaison avec ses voisins et ainsi permettre avant que cela ne se produise de déterminer un autre chemin.

Deux types de modèles de mobilité sont généralement observés : modèles de mobilité par entité et

modèles de mobilité par groupe.

Dans un premier temps, nous présentons les principaux modèles de mobilité généralement utilisés

pour représenter le déplacement d’une seule entité :

• Random Walk [ZON 97-1] : Ce modèle vise à représenter le caractère imprévisible des

mouvements d’une station. Un nœud mobile se déplace de sa position initiale vers une

nouvelle position en sélectionnant aléatoirement une direction et une vitesse.

• Random WayPoint (RWP) [BET 02-1] : Tous les nœuds sont uniformément répartis dans

l’espace de mobilité. Les nœuds alternent successivement les temps de pause et de

19

déplacement. Un nœud immobile, durant une certaine période fixée, détermine une destination

et une vitesse aléatoire et s’y rend.

• Random Direction [ROY 01-1] : Ce modèle essaye de pallier le problème de RWP dont les

nœuds ont tendance à se regrouper vers le centre. Dans ce modèle, un certain nombre de

nœuds qui se dirigent vers le centre sont redirigés en bordure de l’espace de simulation.

• Brownian Motion [TUR 01-1] : Tous les éléments (direction, vitesse, temps de pause) de ce

modèle sont entièrement aléatoires. Chaque nœud se déplace jusqu’à atteindre sa destination

après une période d’attente calculée aléatoirement.

• Manhattan Grid [ETSI 98-1] : Ce modèle représente le déplacement dans une ville avec des

rues toutes perpendiculaires les unes aux autres. Chaque nœud mobile commence à un point

aléatoire d’une rue. Puis il se déplace jusqu’à sa destination à une vitesse prédéfinie. Une fois

la destination atteinte, il fait une pause avant de reproduire le processus. Chaque nœud se

déplace horizontalement ou verticalement.

Nous présentons maintenant les principaux modèles de mobilité par groupe. Dans ces modèles, il n’est

plus question du déplacement d’un seul nœud mais d’un ensemble de nœuds. Les modèles sont les

suivants :

• Pursue Model (PM) [CAM 02-1] : Ce modèle représente un ensemble de nœuds traquant un

nœud spécifique appelé chef. Un nœud particulier dans chaque groupe agit comme le chef et

se déplace suivant un modèle de mouvement particulier (généralement RWP). Les nœuds

restants du groupe se déplacent vers le chef avec une vitesse aléatoire.

• Reference Point Group Mobility (RPGM) [HON 99-1] : Ce modèle représente le déplacement

aléatoire de groupes entre eux ainsi que le déplacement aléatoire des nœuds dans chaque

groupe. Chaque groupe possède un comportement mobile propre. Chaque groupe possède un

centre « logique » que les nœuds du groupe suivent lors de leurs déplacements.

• Nomadic Community [SAN 99-1] : Ce modèle représente des groupes de nœuds mobiles qui

se déplacent collectivement d’un point à un autre. Dans chaque groupe, les nœuds possèdent

un espace qui leur est propre. Ils peuvent se déplacer à leur guise dans cet espace.

1.6 Discussion

Les réseaux sans fil connaissent une importante croissance et l’apparition de nouveaux besoins, des

utilisateurs, pose de nouveaux challenges. Dans ce chapitre, nous avons exposé le contexte de nos

travaux (cf. §1.1) qui se concentrent sur les applications multimédia, temps réel en environnement

mobile. Dans nos objectifs, la mobilité est un paramètre important. Il nous a paru que les réseaux ad

hoc répondent mieux à nos attentes. De fait, le contexte de notre étude se base sur les réseaux

MANETs et profite de leurs caractéristiques : mobilité, autonomie et auto-organisation.

20

De nombreuses technologies sont susceptibles d’agir dans un mode ad hoc. Dans nos travaux, nous

avons fait le choix d’opérer sur des réseaux à l’échelle d’un campus (environ 1km²). Du fait de leur

forte implantation à l’heure actuelle, nous avons choisi d’employer le mode ad hoc des réseaux IEEE

802.11.

Dans ce chapitre, nous avons présenté les réseaux IEEE 802.11 (cf. §1.3), et particulièrement leur

mode ad hoc. Nous avons exposé les caractéristiques et contraintes de ces réseaux (cf. §1.2). L’étude

de leurs performances dans des environnements mobiles suppose l’utilisation de modèles de mobilité

permettant une simulation du mouvement des nœuds dans le temps (cf. §1.4).

La forte consommation de bande passante des applications multimédia et temps-réel, combinée aux

caractéristiques et contraintes des réseaux MANETs, limite leur utilisation conjointe. Les différents

protocoles employés dans les réseaux MANETs utilisent, par ou pour leur fonctionnement, une partie

de cette bande passante.

Dans un contexte ad-hoc, les communications se font par paires. Lorsque deux nœuds trop éloignés

souhaitent communiquer, ils ont besoin de nœuds relais permettant le transfert de leurs données sur le

chemin les séparant. Pour permettre ces relais, certains nœuds du réseau doivent agir comme des

routeurs, et, à ce titre, déployer des protocoles de routage permettant de découvrir et de maintenir des

routes entre les acteurs du réseau.

Notre objectif est d’optimiser la bande passante disponible pour les applications en environnement ad-

hoc multi-saut. La réponse à cet objectif implique que les protocoles de routage doivent tenir compte

des spécificités des réseaux sans fil ad hoc (cf. §1.2.2) : faible débit, capacité des liens variables,

modification de la topologie du réseau avec le temps, et partage du support de transmission. Deux

points sont étudiés dans la suite de notre contribution :

- L’étude du fonctionnement des principaux protocoles de routage existant dans les réseaux ad

hoc et constater s’ils mettent en œuvre des mécanismes pour préserver la bande passante des

MANETs. Cette étude répond à notre critère de mobilité et à l’amélioration de la bande

passante des réseaux MANETs (cf. §2. Routage Meilleur effort dans les réseaux MANETs).

- L’étude des paramètres de qualité de service dont les applications ont besoin et étudier

l’adéquation des protocoles de routage à supporter de telles contraintes. Ce second point

répond à notre critère de qualité (cf. §3. Routage à Qualité de Service dans les réseaux

MANETs).

21

2 Routage Meilleur effort dans

les réseaux MANETs

Les réseaux ad hoc étant de nature multi-sauts, le protocole de routage détermine une route entre un

nœud source et un nœud destination. De par la faible bande passante offerte par les réseaux ad hoc et

du fait de la diffusion des données, les protocoles de routage actuellement utilisés dans les réseaux

filaires ne peuvent être utilisés, sans modifications, dans les réseaux MANETs. De fait, de nouveaux

protocoles de routage ont dû être développés.

Pour être réellement opérationnel dans un environnement mobile, le protocole de routage prend en

compte trois phases :

1) Dissémination de l’information de routage : Elle permet de connaître suffisamment d’éléments sur

la topologie pour choisir un chemin atteignant le nœud de destination. Suivant la quantité

d’informations échangées, les nœuds obtiennent une vue plus ou moins précise de la topologie du

réseau. Le protocole de routage se voit dans l’obligation d’optimiser l’envoi de ces informations, car

elles sont fortement consommatrices en bande passante.

2) Sélection du chemin : Une fois les informations de routage obtenues, le protocole de routage peut

sélectionner une route parmi l’ensemble obtenu en fonction de certains critères. Pour les protocoles

Meilleur effort (« Best Effort »), le critère est de minimiser le nombre de sauts du chemin. Ainsi,

parmi l’ensemble des routes qui lui sont proposées, le protocole choisit celle traversant le plus faible

nombre de nœuds. Les routes choisies doivent être dépourvues de boucles. La présence de boucles

rend inefficace le chemin sélectionné puisque le paquet ne pourra pas atteindre la destination

consommant inutilement de la bande passante. En effet, un paquet de données transitant sur un chemin,

possédant une boucle, va tourner en rond tant que la boucle est présente. Pour éviter qu’un paquet de

22

données tourne indéfiniment, le paquet est détruit lorsqu’il atteint la limite imposée par le champ TTL

présent dans le protocole IP. Un protocole de routage peut créer deux sortes de boucles : les boucles

temporaires et les boucles permanentes [CRK 89-1]. Les premières ont lieu pendant le transfert d’un

message de routage. Durant ce temps, des stations peuvent être mises à jour et d’autres non, d’où la

possible apparition d’une boucle. Elle dure au maximum la durée de traversée du réseau par un

message de routage. Les boucles permanentes, quant à elles, sont dues au phénomène du bouclage à

l’infini [IET 93-1]. Ces boucles peuvent consommer énormément de bande passante.

3) Maintenance des routes : Dans un environnement mobile, la topologie du réseau ne cesse d’évoluer

avec le temps. De fait, les routes sont amenées à changer avec le déplacement des nœuds. Une route

doit éviter de rester longtemps interrompue, car les paquets ne pourraient atteindre leur destination. Le

protocole de routage doit donc tenir compte de ces changements et mettre à jour les routes qui

viennent à être coupées.

Dans ce chapitre, nous présentons les protocoles de routage meilleur effort les plus répandus. De tels

protocoles de routage optimisent uniquement le nombre de sauts. Ils sont censés trouver le chemin

ayant le plus faible nombre de sauts entre une source et une destination données. Le nombre de sauts

désigne le nombre de nœuds traversés par les paquets pour atteindre une destination.

Figure 2-1 : Différents types de protocoles de routage Meilleur Effort

Il est possible de classer les protocoles de routage suivant trois critères (figure 2-1) [XIA 02-1] : le

type de dissémination de l’information de contrôle, la hiérarchie utilisée et l’utilisation d’information

de localisation.

23

Trois types de protocoles de routage peuvent être répertoriés suivant la façon dont ils disséminent

l’information de contrôle : les protocoles proactifs, les protocoles réactifs et les protocoles hybrides

[MEH 03-1], [MAU 01-1], [BEL 99-1]. Dans un protocole proactif, chaque nœud échange

périodiquement sa connaissance de la topologie du réseau avec ses nœuds voisins. Un protocole réactif

émet des informations de routage uniquement lors de la création d’une route. Les protocoles hybrides

font un mixe entre les deux types précédents. A faible distance ils disséminent leur connaissance de la

topologie (protocole proactif) et pour des routes à une distance supérieure l’information de routage est

échangée seulement lorsque l’obtention d’une route est nécessaire (protocole réactif).

Les protocoles de routage peuvent également être classés suivant un autre critère : le type de leur

hiérarchie. En effet, un protocole de routage peut ou non utiliser une hiérarchisation des nœuds dans le

réseau. Un protocole utilisant une hiérarchie sépare les nœuds en plusieurs niveaux. Un nœud de

niveau supérieur peut contrôler les nœuds se trouvant plus bas dans l’arbre de hiérarchie.

Le dernier critère pour classer les protocoles de routage est l’utilisation d’informations de localisation

pour trouver une route. Les informations de localisation sont échangées entre les nœuds pour connaître

la position géographique des autres nœuds du réseau. La position géographique d’un nœud peut être

obtenue en utilisant les coordonnées GPS [GPS] par exemple. Connaître la position des autres nœuds

permet de diriger les informations de routage vers la position de la destination. Le nombre

d’informations utilisées, à la détermination d’une route, est donc diminué. Une telle diminution

préserve la bande passante, ressource rare dans les réseaux MANETs.

2.1 Type de dissémination de l’information de routage

Un des aspects qui a suscité de nombreux débats et travaux concerne le nombre de routes qu’un nœud

doit conserver dans sa table de routage. En effet, un nœud doit-il mémoriser les routes pour atteindre

tous les nœuds destinations, ou seulement garder trace des routes pour atteindre les nœuds destinations

sur lesquels un intérêt est porté. Par conséquent, trois types de protocoles de routage se sont distingués

suivant la manière dont les routes sont maintenues dans les tables de routage et l’information de

routage est disséminée. Dans les protocoles proactifs, les nœuds maintiennent une route vers chaque

nœud du réseau. De même, ils émettent périodiquement des informations de routage à leurs voisins.

Les nœuds, exécutant un protocole réactif, maintiennent seulement les routes actives (les routes qui

sont utilisées). Ils émettent des informations de routage uniquement lorsqu’une route a besoin d’être

trouvée. Les protocoles hybrides utilisent un mélange des deux précédents types.

2.1.1 Protocoles de routage Proactifs

Chaque nœud, employant un protocole de routage proactif, conserve la route nécessaire pour atteindre

n’importe quel autre nœud du réseau. Chaque nœud maintient une table de routage contenant les

informations nécessaires (par exemple le prochain nœud sur le chemin…) pour atteindre un autre

nœud du réseau. En consultant sa table de routage, un nœud peut à tout instant transmettre un paquet

de données vers un autre nœud du réseau.

24

Des mises à jour périodiques de l’état de la topologie gardent effectives les routes présentes dans la

table de routage. Les performances de ce type de protocoles souffrent du trafic additionnel nécessaire

au maintient de l’état des routes. Pour conserver des routes valides, le rafraîchissement des

informations sur la topologie dépend de la mobilité des nœuds du réseau MANET. Si le

rafraîchissement est trop élevé, comparé à l’évolution de la topologie, le nombre d’informations de

routage émises sur le réseau est trop important, consommant inutilement de la bande passante. A

contrario s’il est trop faible, les tables de routage ne sont pas suffisamment mises à jour, rendant les

informations qu’elles contiennent obsolètes. Pour un fonctionnement optimal de ce type de protocoles,

un compromis entre l’échange des informations de routage et la prise en compte de l’évolution de la

topologie doit être trouvé.

Dans un premier temps, nous présentons les protocoles DSDV et OLSR. Ces protocoles sont les

protocoles proactifs les plus répandus dans la littérature. Le protocole DSDV est une référence de part

son ancienneté, alors que le protocole OLSR est le seul représentant standardisé des protocoles

proactifs.

2.1.1.1 Protocole DSDV

L’algorithme de routage proactif étudié dans cette partie est l’algorithme de routage Destination-

Sequenced Distance-Vector (DSDV) [PER 94-1]. Il est basé sur l’algorithme du vecteur de distance

utilisé dans RIP [RFC 2453]. Le protocole à vecteur de distance permet de limiter l’échange des

messages de contrôle de la topologie uniquement aux voisins d’un nœud. Ce point est extrêmement

important pour préserver la bande passante disponible sur le réseau.

Le protocole DSDV utilise les propriétés de la diffusion pour transmettre les informations de routage.

En effet, le grand avantage de la diffusion est qu’une trame émise par une station est entendue par

l’ensemble de ses voisins. Périodiquement, chaque station diffuse l’ensemble de sa table de routage

suivie d’un numéro pour dater l’information. Ce numéro est appelé numéro de séquence. A partir de

deux numéros de séquence, il est possible de déterminer quelle information est la plus récente. La

table de routage d’un nœud contient les informations liées à chaque route (adresse de destination,

nombre de nœuds pour joindre cette destination et numéro de séquence de la destination).

A la réception de ces informations, les voisins mettent à jour leur table de routage en suivant un

schéma bien précis. Toute entrée de la table de routage est mise à jour, seulement, si l’information

reçue est plus récente, ou si elle a le même âge mais possède un nombre de nœuds plus faible. A terme,

le protocole DSDV fournit pour chaque destination, la route qui possède le plus faible nombre de

nœuds.

Pour être un protocole de routage complet, le protocole DSDV doit maintenir l’état des chemins. Pour

cela, les nœuds détectent les ruptures de lien. Chaque nœud émet, périodiquement, ses informations de

routage à l’ensemble de ses voisins. Si pendant un certain temps, un nœud ne reçoit plus les

informations de routage d’un nœud voisin c’est que ce dernier ne fait plus partie de son voisinage. Un

lien coupé affecte l’ensemble des routes utilisant ce lien. Un nœud, décelant une coupure, diffuse un

paquet contenant l’ensemble des destinations ne pouvant plus être atteint à travers ce lien. Tout nœud,

25

recevant un tel paquet, le propage immédiatement pour faire connaître au plus vite le changement de

topologie. Un des problèmes de cet algorithme est qu’il réagit trop lentement aux mauvaises nouvelles.

La destination doit prendre connaissance d’une coupure pour transmettre une mise à jour de la

topologie.

2.1.1.2 OLSR

Le protocole Optimized Link State Routing (OLSR) a été standardisé en 2003 [RFC 3626]. Son

fonctionnement est basé sur l’algorithme à état de liens [RFC 2328]. Un nœud du protocole à état de

liens diffuse sa connaissance des voisins à l’ensemble de la topologie. De nombreux changements ont

dû y être apportés pour être exploitable dans un réseau ad hoc. La bande passante étant limitée la

diffusion de ses voisins à l’ensemble des nœuds du réseau est bien trop coûteuse. Le protocole OLSR

prend en compte les spécificités de la diffusion (un paquet émis est reçu par l’ensemble des nœuds

dans son voisinage immédiat) pour réduire le nombre de paquets nécessaires à l’échange de la

topologie.

Chaque nœud doit déterminer l’ensemble de ses voisins. Pour cela périodiquement, ils transmettent

des paquets, dits Hello, pour se faire connaître. Ce type de paquet comprend la totalité de la base de

liens connue par l’émetteur du paquet. La base de liens d’un nœud regroupe l’ensemble des nœuds lui

ayant transmis un paquet Hello. A la réception des paquets Hello, chaque nœud dans le réseau connaît

les nœuds situés dans son voisinage immédiat mais également à deux sauts.

Une fois les voisins découverts, les nœuds peuvent échanger les informations sur leur voisinage pour

former la topologie du réseau. Cette fonction est attribuée à des nœuds particuliers sélectionnés parmi

ses voisins à un saut. Ces nœuds sont appelés relais multipoints (MPRs) et sont les seuls capables de

transmettre les informations de routage. Chaque nœud sélectionne un ensemble de MPRs relayant les

informations de routage à l’ensemble des nœuds situés à deux sauts. Chaque MPR transmet,

périodiquement, la liste des nœuds qui l’ont choisi comme MPR. Un tel paquet est, seulement, relayé

par les nœuds sélectionnés en tant que MPRs.

Une fois la topologie connue par l’ensemble des nœuds du réseau, il suffit d’appliquer un algorithme,

de type Dijkstra, pour déterminer les routes vers l’ensemble des nœuds distants. Chaque nœud connaît,

ainsi, les routes les plus courtes vers les autres nœuds du réseau.

2.1.1.3 Autres protocoles proactifs

Dans un souci d’économie de bande passante, nous étudions les protocoles proactifs GSR, FSR, WRP

et STAR. Ils se distinguent des autres protocoles proactifs, de part leur méthode de dissémination de

l’information. L’échange des informations de routage fluctue avec la stabilité du réseau ou

l’éloignement des nœuds, réduisant la quantité d’informations échangées.

Le protocole Global State Routing (GSR) [CHE 98-1] est basé sur le protocole à état de liens. Il

diffère du protocole à état de liens par sa façon à propager sa connaissance du réseau. Un nœud diffuse,

seulement à ses voisins, sa connaissance de la topologie du réseau. De fait, le surcoût (overhead) est

drastiquement réduit comparé aux protocoles à état de liens. Par contre pour des réseaux relativement

26

denses, la taille de la topologie est importante. Dans ce cas, le nombre de paquets de contrôle échangés

devient conséquent.

Le protocole Fisheye State Routing (FSR) [GER 02-1] est basé sur le protocole GSR. Pour réduire le

nombre de messages de contrôle et surtout leur taille, un nœud transmet plus souvent sa connaissance

de la topologie située à proximité que celle dont les nœuds sont éloignés. Il part d’un constat de

société où chaque être humain connaît parfaitement les personnes qui habitent dans leur quartier, et

uniquement les noms des villages et villes lorsqu’il s’en éloigne. Un paquet de données arrive

correctement à destination malgré les états imprécis du réseau, puisqu’au fur et à mesure qu’il se

rapproche de la destination, la connaissance de la topologie se précise.

Le protocole Wireless Routing Protocol (WRP) [MUR 95-1] est un protocole de routage à vecteur de

distance. Les vecteurs de distance sont, uniquement, émis lorsque des changements sur la topologie du

réseau surviennent. Ces mises à jour doivent être acquittées par la totalité des nœuds voisins (détectant

ainsi une perte éventuelle). Pour détecter ces changements, les nœuds transmettent périodiquement des

paquets pour se faire connaître dans leur voisinage.

Le protocole Source-Tree Adaptative Routing (STAR) [GAR 99-1] est basé sur le protocole à état de

liens. Chaque routeur maintient un arbre contenant l’ensemble des routes préférées pour joindre les

destinations. Ce protocole réduit la quantité d’informations de contrôle échangées en éliminant les

mises à jour périodiques du protocole à état de liens. L’envoie de son arbre n’est pas fait

périodiquement, il est réalisé uniquement lors de changements importants sur le réseau (détection

d’une nouvelle destination, rupture d’un lien…). Cette approche évite les mises à jour périodiques. Ce

protocole est performant lors du passage à de vastes réseaux car il maîtrise le nombre de messages de

contrôle transmis.

2.1.2 Protocoles Réactifs

Les protocoles de routage réactifs (ou sur demande) ne maintiennent une route que si elle est utilisée.

Lorsqu’un nœud source a besoin de transmettre des données vers un nœud destination, il doit au

préalable déterminer une route. Pour cela, des informations de contrôle sont transmises sur le réseau.

Comparés aux protocoles proactifs qui conservent les routes vers l’ensemble des stations du réseau

dans leur table de routage, les protocoles réactifs ne conservent que les routes qui ont une utilité. Par

conséquent, la taille des tables de routage contenues en mémoire est moins importante que pour les

protocoles proactifs.

Trouver une route, lorsque la source en a besoin, crée une latence avant de l’obtenir. Pour certaines

applications nécessitant un minimum de réactivité, ce délai peut être problématique. Ce délai n’est

seulement occasionné au début de l’échange d’information (lors de l’établissement de la route) ou

lorsqu’une route est rompue (lors du déplacement d’un nœud par exemple). Durant le laps de temps où

le protocole de routage détermine la route nécessaire, les paquets provenant de la couche supérieure

sont conservés en mémoire.

27

Dans un premier temps, nous présentons les protocoles réactifs AODV et DSR. Ces protocoles sont les

protocoles réactifs ayant le plus de chances d’être utilisés dans les réseaux MANET du fait qu’ils

soient standardisés.

2.1.2.1 Protocole AODV

Le protocole de routage Ad hoc On-Demand distance Vector (AODV) [RFC 3561] permet le maintien

des routes utilisées. En fait, si le changement de statut d’un lien n’affecte pas une communication,

aucun échange entre les nœuds n’est donc nécessaire. Les effets des changements de topologie sont

ainsi localisés seulement aux routes rencontrant ces modifications et non à la globalité du réseau. Ce

protocole est opérationnel seulement dans un environnement où les liens sont symétriques. Ce

protocole met en œuvre différentes opérations pour réaliser et maintenir le routage : gestion de la

connectivité locale, phase de découverte des routes, maintenance des routes.

La fonctionnalité de gestion de la connectivité locale est appliquée par les nœuds de la manière

suivante. Chaque nœud émet périodiquement un paquet, nommé Hello. A la réception de ce paquet,

les nœuds apprennent la présence des nœuds voisins. La connectivité locale est modifiée dans les cas

suivants : un nœud reçoit un paquet Hello transmis par un nouveau voisin ou un nœud ne reçoit plus

de paquets Hello durant un laps de temps défini.

La phase de découverte des routes par le protocole AODV est la suivante (cf. Annexe I pour les

organigrammes des nœuds). A la réception d’un paquet de données par la source, elle vérifie dans sa

table de routage si une route existe jusqu’à la destination. Si elle existe, le paquet est transmis vers le

prochain nœud sinon la phase de découverte des routes est engagée. Le paquet est mis en file d’attente

le temps d’obtenir une route puis la source diffuse une requête de création de routes, nommée RREQ.

A la réception d’un paquet RREQ, un nœud met à jour la route inverse en direction de la source. Le

nœud vérifie, ensuite, s’il connaît une route vers la destination. S’il en possède une, il envoie une

requête de réponse, nommée RREP, en direction de la source. Sinon, il diffuse la requête RREQ à ses

voisins. Lorsque la requête RREP transite vers la source, chaque nœud sur le chemin inverse met à

jour sa table de routage avec, comme prochain nœud, l’adresse du nœud qui a émis la requête RREP.

Le temporisateur de cette entrée dans la table de routage est mis à jour. Ce temporisateur indique

qu’une route est toujours active s’il est non nul.

Pour chaque destination d’intérêt, un nœud maintient une unique entrée dans sa table de routage qui

contient les champs suivants : adresse de la destination, numéro de séquence de la destination,

prochain nœud sur le chemin vers la destination, nombre de sauts et d’autres paramètres relatifs à la

route. L’utilisation du numéro de séquence permet de « dater » la route et d’éviter la présence de

boucles. Si deux routes existent entre un nœud et la destination, le nœud conserve la route la plus

récente. Si les deux routes sont découvertes simultanément, la route avec le plus faible nombre de

sauts est conservée.

La phase de découverte des routes peut, aussi, être réalisée en utilisant une recherche de parcours en

largeur. La source positionne, lors de la première tentative de recherche de route, le champ TTL de la

requête RREQ à la valeur TTL_DEBUT. Elle positionne le temporisateur, d’attente d’un paquet RREP,

28

à la valeur TEMPS_TRAVERSE millisecondes. La valeur TEMPS_TRAVERSE est calculée avec la

formule suivante :

( ) NOEUDTRAVERSETEMPSCONGESTIONTEMPSTTLTRAVERSETEMPS ___2_ ×+×= (2-1)

où TEMPS_TRAVERSE_NOEUD est le temps moyen estimé de la traversée d’un saut par un paquet et

TEMPS_CONGESTION est un temps supplémentaire au cas où la requête RREP est retardée due à une

congestion.

Si le temporisateur initialisé à TEMPS_TRAVERSE arrive à échéance, c'est-à-dire que la source n’a

pas reçu de réponse RREP dans le temps imparti, la source diffuse une nouvelle requête RREQ avec le

champ TTL incrémenté avec la valeur TTL_INCREMENT. Ceci est réalisé jusqu’à que le TTL atteigne

un certain seuil. Dans un tel cas, le TTL est positionné avec le diamètre du réseau, et la phase de

découverte des routes devient identique à celle présentée précédemment. Après chaque tentative, le

temporisateur d’attente d’une réponse RREP est positionné avec une valeur de TEMPS_TRAVERSE

millisecondes.

Le nombre de sauts conservé dans une entrée invalidée de la table de routage (à cause d’un temps

d’inactivité trop élevé par exemple, de perte de route…) indique le dernier nombre de sauts connu

pour atteindre cette destination dans la table de routage. Lorsqu’une nouvelle route vers cette

destination est requise, le TTL dans la requête RREQ est initialisé à ce nombre de sauts plus

TTL_INCREMENT.

La phase de maintenance des chemins est réalisée en plusieurs étapes. La première étape consiste en la

détection de la perte d’un chemin. Quand un nœud sur un chemin établi se déplace, les routes passant

par ce nœud peuvent être rompues. Les nœuds en amont, détectant la perte de connectivité,

préviennent les sources affectées en émettant une requête d’erreur, notée RERR. A la réception de ce

paquet, le nœud source engage la deuxième étape de la maintenance des routes. Il entame une nouvelle

phase de découverte des routes, si un chemin est toujours nécessaire.

2.1.2.2 Protocole DSR

Le protocole Dynamic Source Routing (DSR) a été standardisé en 2007 [RFC 4728]. Son

fonctionnement est très proche du protocole AODV à la grande différence qu’il fournit dans les

paquets de données l’ensemble des nœuds permettant d’atteindre une destination (routage par la

source). Cet ajout dans les paquets de données accroît le surcoût et consomme un peu plus de bande

passante. A contrario, ces informations lui permettent de gérer l’asymétrie des liens présents dans le

réseau. En effet, un paquet de données peut prendre une route différente de son acquittement. Le

fonctionnement basique de DSR s’avère assez simple à mettre en œuvre. Il met en place uniquement

deux phases : la phase de découverte des routes, et la phase de maintenance de ces mêmes chemins.

Le fonctionnement de la découverte des routes est le suivant. Un nœud source initie une requête de

découverte des routes (Route Request) lorsqu’un paquet de la couche supérieure lui provient et qu’il

ne possède pas de route vers sa destination. Le nœud source avant de transmettre la requête de route

29

ajoute son adresse dans le champ route du paquet ainsi qu’un identifiant, l’adresse source et l’adresse

de destination. Lorsqu’un nœud intermédiaire reçoit une requête de route, il vérifie tout d’abord s’il a

déjà reçu la requête. Pour cela, il utilise les champs adresse source, adresse destination et identifiant

qui permettent d’identifier de manière unique une requête de route. Si une telle requête a déjà été reçue,

elle est supprimée. Dans le cas où la requête lui est destinée, il l’acquitte en envoyant une requête de

réponse (Route Reply) confirmant le chemin « source-destination », sinon il la propage en ajoutant,

dans le champ chemin, son identifiant.

Le protocole DSR prend en compte les liens unidirectionnels. Par conséquent, le chemin « destination-

source » peut être différent du chemin « source-destination ». A la réception d’une requête de

découverte des routes, le nœud de destination vérifie s’il possède déjà une route en direction de la

source. S’il en connaît une, il transmet la réponse sur cette route. Dans le cas contraire, il doit en

déterminer une. Pour cela, il réutilise le fonctionnement de la découverte des routes énoncé plus haut.

A la seule différence qu’il intègre le paquet de réponse (contenant la route entre la source et la

destination) à sa propre requête de route. Une fois que la source reçoit la requête de route, elle extrait

le chemin pour joindre la destination et l’ajoute dans sa table de routage. Elle envoie un paquet de

réponse à la destination sur ce chemin, confirmant le chemin « destination-source ».

L’opération de maintenance consiste dans un premier temps à déterminer si un lien est rompu. Cette

opération peut être réalisée par la sous-couche MAC. Si au bout d’un certain nombre d’émissions

aucun acquittement n’est reçu, le lien peut être considéré comme coupé. Un nœud détectant la rupture

prévient l’ensemble des sources avec un paquet d’erreur (Route Error). A la réception d’un tel paquet,

les sources déterminent une nouvelle route si aucune autre n’est connue.

2.1.2.3 Autres protocoles réactifs

De nombreux autres protocoles réactifs ont été développés ces dernières années. En particulier, nous

pouvons cités LMR, TORA, AOMDV, BSR et ABR. Ces protocoles proposent un axe intéressant dans

la préservation de la bande passante. La phase de maintenance des routes rétablit une route lorsqu’elle

est interrompue. Cette maintenance engendre un coût en nombre de messages échangés et donc en

bande passante consommée. Ces protocoles proposent des solutions pour diminuer l’impact d’une

rupture de route sur la bande passante du réseau.

Le protocole de routage Light-weight Mobile Routing (LMR) [COR 95-1] est un protocole de routage

réactif qui utilise la diffusion pour déterminer les routes. Les nœuds, dans LMR, maintiennent de

multiples routes pour chaque destination. Maintenir plusieurs routes rend le protocole de routage

moins sensible aux changements de topologie. En effet, il n’est pas systématiquement nécessaire de

déterminer une route qui engendre un certain délai. Dans LMR si une autre route est disponible, elle

est utilisée. Par contre, ce protocole peut produire temporairement des routes invalides avec la

présence de boucles.

Le protocole de routage Temporally Ordered Routing Algorithm (TORA) [PAR 97-1] est basé sur le

protocole LMR. De fait, il détermine plusieurs routes pour joindre une destination. L’avantage de

TORA comparé à LMR est qu’il obtient plus rapidement une nouvelle route lors de la rupture d’un

30

lien. En effet, lorsqu’un nœud détecte un lien coupé et qu’il n’a plus aucune route pour joindre la

destination, il doit en déterminer une nouvelle. Le protocole TORA réalise cette opération dans un laps

de temps plus court que LMR. Contrairement à LMR, TORA ne nécessite pas de confirmation lors de

l’obtention d’une nouvelle route.

Le protocole de routage On-Demand Multipath Vector Routing in Ad Hoc Networks (AOMDV)

[MAR 01-1] est basé sur le protocole AODV. Il détermine plusieurs chemins qui sont soit disjoints par

leurs nœuds, soit disjoints par les liens qu’ils traversent. Deux chemins sont disjoints par les nœuds

traversés si les nœuds sont différents deux à deux. Deux chemins seront disjoints vis-à-vis des liens si

les liens traversés sont différents deux à deux. Utiliser des chemins disjoints permet à la rupture d’un

lien d’être répercutée sur un seul chemin. Les autres chemins restent donc opérationnels et peuvent

être empruntés.

Le protocole de routage Backup Source Routing (BSR) [GUO 01-1] est basé sur le protocole DSR. Il

évite de mettre en place la phase de découverte des chemins après la rupture d’un lien. Pour cela, les

nœuds maintiennent le chemin principal le plus court mais également un chemin de secours plus stable.

Lorsque le chemin principal n’est plus opérationnel, les paquets empruntent le chemin de secours

réduisant le temps de latence engendré lors du calcul d’un nouveau chemin.

Le protocole Associativity-Based Routing (ABR) [TOH 96-1] privilégie les nœuds les plus stables.

Pour déterminer cette stabilité, chaque nœud émet périodiquement des balises à ses voisins pour faire

connaître sa présence. Un nœud calcule la stabilité d’un voisin en fonction du temps qu’il passe dans

son voisinage. Lors de la rupture d’un lien, le nœud affecté essaye de rétablir les chemins coupés et

ainsi d’éviter aux sources de réaliser une nouvelle phase de découverte des routes.

2.1.3 Protocoles Hybrides

Dans un souci de préserver la bande passante, les protocoles de routage hybrides combinent les

avantages des protocoles proactifs et réactifs. Lorsqu’il faut traverser un grand nombre de nœuds, les

protocoles réactifs deviennent plus intéressants au niveau de la consommation en bande passante.

Excepté la latence qui augmente, ce type de protocoles fournit de nombreux avantages pour les

topologies avec un nombre élevé de nœuds. En effet, l’entretien des routes est beaucoup plus facile,

car seulement les routes utilisées ont besoin d’être mises à jour lors d’une modification de la topologie.

Les protocoles proactifs sont plus performants dans des réseaux ayant un faible nombre de nœuds. En

effet, ils connaissent à tout moment au moins une topologie partielle du réseau, et donc peuvent

déterminer immédiatement le prochain nœud en direction de la destination. Aucune latence au niveau

de l’émetteur ne se fait donc ressentir. La consommation de bande passante est dans ce cas

relativement minime car peu de stations sont présentes dans le réseau.

Les protocoles hybrides vont donc tirer avantage de ces deux protocoles. Un nœud va utiliser, dans son

proche entourage, un algorithme de routage proactif. Ainsi, chaque nœud a une connaissance globale

de son voisinage. Puis à l’extérieur de son entourage immédiat, il va utiliser un algorithme de routage

réactif. Ce type d’algorithme s’inspire du comportement humain, c'est-à-dire que nous avons une

31

bonne connaissance du quartier où l’on habite, mais plus on s’en éloigne, plus on ne connaît que les

axes pour atteindre notre lieu de destination, et pas ce qui l’entoure.

Nous présentons dans un premier temps le protocole hybride ZRP qui est le protocole hybride le plus

référencé dans la littérature. Nous présentons, ensuite, deux protocoles hybrides ZHLS et SHARP qui

diffèrent de ZRP par l’échange des informations de routage vers les zones extérieures (InterZone) et

par la formation des zones.

2.1.3.1 Protocole ZRP

Le protocole de routage hybride le plus répandu est le protocole Zone Routing Protocol (ZRP)

[HAS 99-1]. Ce protocole découpe la topologie du réseau en deux zones. La première zone est celle

dans le voisinage de chaque nœud, elle est appelée Intrazone. En fait, c’est l’ensemble des nœuds qui

se trouvent à un nombre de sauts inférieur ou égal à Hmax. La seconde zone est la zone extérieure à un

nœud, appelée Interzone, c'est-à-dire l’ensemble des nœuds qui se trouvent à un nombre de sauts

supérieur à Hmax.

Pour déterminer le chemin pour joindre une destination, deux protocoles de routage vont être

employés suivant la zone dans laquelle se trouve la destination. Ainsi, si la destination se situe dans

l’Intrazone, le protocole de routage proactif Intrazone Routing Protocol (IARP) est utilisé. Si la

destination est extérieure à cette zone, le protocole de routage réactif Interzone Routing Protocol

(IERP) est employé.

Le protocole de routage IARP est basé sur un protocole à état de liens. Chaque nœud diffuse,

périodiquement, sa connaissance de ses voisins. A l’aide des informations diffusées, les nœuds

construisent la topologie et déterminent les routes vers les nœuds situés à proximité. Pour éviter que la

diffusion des paquets de contrôle se propage sur la totalité du réseau, la source met le champ TTL à la

valeur de Hmax, le nombre de saut maximum auquel se limite l’Intrazone. Chaque fois qu’un nœud

reçoit un tel paquet, il met à jour sa table de routage puis décrémente de 1 le champ TTL du paquet. Si

ce champ est égal à 0 le paquet est supprimé sinon il est propagé.

Lorsque le nœud source ne connaît pas de chemin vers la destination, c’est qu’elle ne se trouve pas

dans l’Intrazone. Il utilise le protocole IERP pour déterminer un chemin jusqu’à elle. Le protocole

IERP est responsable uniquement des communications entre les différentes zones. La source

détermine un ensemble de nœuds frontières à son Intrazone. Elle utilise ces nœuds pour déterminer un

chemin jusqu’à la destination, tout en réduisant le délai et le surcoût pris par la recherche. Lors de la

réception de la requête de demande de création de route, les nœuds frontières ajoutent leur identifiant

dans l’entête de la requête. Ensuite, deux procédures sont appliquées selon que ces nœuds connaissent

une route vers la destination ou pas :

• La destination est dans l’Intrazone d’un nœud frontière : une réponse est envoyée à la

destination en prenant le chemin inverse contenu dans l’entête de la requête.

• La destination ne se situe pas dans l’Intrazone d’un nœud frontière : la requête est propagée à

l’ensemble de ses nœuds frontières et l’opération recommence jusqu’à déterminer un chemin.

32

2.1.3.2 Autres protocoles hybrides

Nous présentons deux protocoles hybrides ZHLS et SHARP. Ces protocoles réduisent le trafic de

contrôle pour déterminer une route avec un nœud situé dans l’InterZone.

Le protocole Zone-Based Hierarchical Link State Protocol (ZHLS) [JOA 99-1] comme ZRP allie une

recherche proactive dans l’Intrazone et une recherche réactive dans l’Interzone. Il suppose que le

réseau est divisé en zones qui ne se chevauchent pas. La taille des zones est fonction de la rapidité de

déplacement des nœuds présents sur le réseau, du nombre de nœud présent dans la topologie, du rayon

de transmission de chaque nœud… Dans l’Intrazone, ZHLS utilise le protocole à état de liens pour

déterminer l’ensemble des nœuds qui la composent. Connaissant la topologie, chaque nœud détermine

les routes pour joindre l’ensemble des nœuds de sa zone. Le routage dans l’interzone consiste, dans un

premier temps, à déterminer les nœuds frontières faisant liaison avec les zones voisines. Lorsqu’une

zone a déterminé celles qui l’entourent, la totalité des nœuds du réseau propage cette information. De

fait, chaque nœud détermine un chemin vers les autres zones du réseau. Lors de la recherche d’une

route dont la destination est située dans l’InterZone, la source interroge l’ensemble des zones du

réseau pour déterminer à quelle zone appartient la destination. Une fois la zone identifiée, la source

peut envoyer vers cette zone des paquets de données qui arriveront à destination. Ce protocole réduit

le nombre d’informations de contrôle échangé pour déterminer un chemin. Par contre, il suppose que

le réseau est déjà divisé en zones qui ne se chevauchent pas.

Le protocole Sharp Hybrid Adaptive Routing Protocol (SHARP) [RAM 03-1] régule les informations

de routage échangées par les protocoles proactif et réactif en adaptant dynamiquement l’Intrazone

autour d’un nœud. Chaque nœud définit le nombre de nœuds dans son Intrazone en fonction du trafic

qu’il reçoit.

2.2 Hiérarchisation du réseau

Les réseaux ad hoc sont structurés hiérarchiquement en différenciant les nœuds présents sur le réseau.

Il est possible de voir la hiérarchisation des nœuds comme un arbre hiérarchique dans une entreprise.

Les nœuds les plus hauts dans la hiérarchie dirigent les nœuds se trouvant en dessous. Les nœuds les

plus bas dans la hiérarchie dépendent directement de leur supérieur hiérarchique. Ainsi, les nœuds se

voient affectés des fonctions différentes suivant leur place dans la hiérarchie. Les réseaux ad hoc sont

structurés hiérarchiquement sous forme de clusters. Nous détaillons dans un premier temps les réseaux

de clusters, puis un sous-ensemble de ce type de réseau, les réseaux à backbone.

33

2.2.1 Cluster

Figure 2-2 : Topologie d’un réseau de clusters

Les réseaux de clusters sont un découpage du réseau en un ensemble de petits groupes gérés par des

chefs de groupe [GER-95]. Ils peuvent être aisément représentés par la figure 2-2. Le chef de groupe,

appelé aussi clusterhead, gère l’ensemble des nœuds qui sont directement connectés à lui. Parmi cet

ensemble, on peut distinguer les passerelles qui font le lien avec un autre cluster des nœuds normaux

qui sont rattachés uniquement au chef de groupe. Le chef de groupe se voit affecter de nombreux rôles

tels que décider quelle station peut accéder au support, diffuser les tables de routage pour réduire le

surcoût, gérer la qualité de service …

Les réseaux de clusters doivent dans un premier temps former la structure du réseau en élisant les

chefs de groupes. Par la suite, il est nécessaire de maintenir cette hiérarchisation pour le bon

fonctionnement du réseau. L’élection des chefs de groupe se fait de manière distribuée. Au début,

l’ensemble des nœuds se trouvent à la base de la hiérarchie. Par la suite, les nœuds vont élire leurs

chefs de groupe suivant l’un des critères suivants, le numéro d’identifiant [EPH-87] ou le degré des

nœuds [PAR-94]. Dans ces deux algorithmes, seul le critère sur le choix du chef de groupe diffère. La

façon de sélectionner un chef de groupe reste la même.

Les nœuds étant en mouvement, un chef de groupe peut rompre la connectivité avec les nœuds qui lui

sont rattachés. De même, il peut cesser de fonctionner car la station peut s’éteindre ou ne plus avoir

suffisamment d’énergie pour réaliser ce rôle. Lors de la perte de connectivité, cet ensemble de nœuds

doit élire un nouveau chef de groupe. Pour cela, il suffit de réappliquer l’algorithme de plus faible

identifiant ou de plus fort degré de connectivité sur l’ensemble des nœuds sans chef de groupe. Pour

vérifier, la connectivité entre un chef de groupe et les nœuds qui lui sont rattachés, des paquets de

contrôle sont échangés périodiquement.

34

2.2.2 Réseaux à backbone

Les réseaux à dorsales sans fil (ou réseaux à backbone) sont un découpage de la topologie du réseau en

un ensemble de groupes distincts [RUB-01]. Un réseau mobile de backbone est composé d’un réseau

de backbone (Bnet), d’un réseau d’accès (Anet) et d’un réseau ad hoc normal. Il est possible de voir

cette hiérarchisation sur la figure 2-3.

Figure 2-3 : Topologie d’un réseau de Backbone

Un réseau mobile à backbone a pour particularité d’avoir deux types différents de nœuds qui se

différencient en fonction de leurs caractéristiques. Ainsi, les nœuds à grandes capacités servent à la

formation du réseau à backbone. Ils sont appelés nœuds de backbone (BN) s’ils forment la dorsale ou

nœuds de backbone capable (BCN) s’ils sont éligibles pour la formation de la dorsale. Ces nœuds ont

pour particularité d’avoir une capacité importante de fonctionnement, en offrant des ressources

processeur et des capacités mémoire importantes. De même, ils possèdent deux modules sans fil

fonctionnant sur des fréquences différentes (l’un à faible puissance, et l’autre à puissance élevé). Le

module à faible puissance est utilisé pour fonctionner avec les stations du réseau ad hoc (nommées RN)

alors que l’autre module est employé pour la communication entre les nœuds de la dorsale (les BNs).

Du fait que ces deux modules opèrent sur des fréquences différentes, ils n’interfèreront pas entre eux.

La formation de la dorsale (Bnet) est réalisée en sélectionnant un ensemble de BCNs, [GER-04],

[MER-04], [RUB-99] et [RUB-05], permettant de couvrir le plus large ensemble de stations ad hoc.

Les BCNs sélectionnés deviennent par la suite des BNs et forment la dorsale. Le choix du BCN se fait

généralement sur l’ensemble de ses caractéristiques (grande capacité, puissance processeur élevée,

autonomie importante…). Un BCN qui n’est pas associé avec un nœud du réseau ad hoc (RN) diffuse

périodiquement son identifiant et ses caractéristiques à l’ensemble de ses voisins en utilisant son

module de transmission à faible puissance. Un BCN est converti en BN, si ses caractéristiques sont les

plus élevées parmi les BCN non associés dans le voisinage. Les RNs se trouvant à un saut s’associent

dorénavant à lui s’ils ne sont pas associés à un autre BN. Les BNs sont interconnectés entre eux par le

module à forte puissance de transmission.

35

2.2.3 Protocoles de routage hiérarchiques

Nous présentons dans cette section quelques protocoles de routage hiérarchique. Ces protocoles

diffèrent dans la manière de hiérarchiser le réseau et dans l’échange des informations de contrôle. Les

protocoles CGSR, HSR, CBRP, MMWN et LANMAR divisent le réseau en clusters (cf. §2.2.1). Les

protocoles OSR, PSR et NTDR divisent le réseau en backbone (cf. §2.2.2).

Le protocole Clusterhead Gateway Switch Routing (CGSR) [CHI 97-1] utilise une hiérarchisation du

réseau en clusters pour router les paquets. Chaque nœud est rattaché à une tête de cluster. Cette tête de

cluster contrôle l’affectation du médium à une station et l’ensemble des communications entre clusters

passe par lui. Chaque nœud maintient deux tables, une table CM contenant pour chaque nœud du

réseau la tête de cluster auquel il est rattaché, et une table de routage contenant le prochain nœud vers

chaque tête de cluster. La table CM est diffusée périodiquement par chaque nœud. Le protocole de

routage DSDV est utilisé pour calculer la table de routage vers chaque tête de cluster. Les paquets sont

routés alternativement entre les têtes de cluster et les passerelles. Ce protocole réduit la taille de la

table de routage diffusée car uniquement les entrées en direction des têtes de cluster sont conservées.

Par contre, le surcoût pour maintenir les clusters est important.

Le protocole Hierarchical State Routing (HSR) [PEI 99-1] est basé sur le protocole à état de lien. Le

réseau est divisé en clusters avec une hiérarchie multiple. Le premier niveau de la hiérarchie

correspond à la division en clusters présentée dans le paragraphe §2.2.1. Les autres niveaux de la

hiérarchie sont formés des têtes de cluster des niveaux précédents. Chaque niveau hiérarchique est

découpé en clusters. L’ensemble des têtes de cluster d’un niveau hiérarchique élisent une tête de

cluster à laquelle elles deviennent affiliées. Le niveau hiérarchique le plus élevé est composé d’une

seule tête de cluster. Une fois la hiérarchie multiple composée, chaque nœud du niveau physique

obtient une adresse hiérarchique de la forme <sous-réseau, hôte>. Le champ sous-réseau est composé

du chemin de la hiérarchie la plus haute jusqu’au nœud lui-même. Par ce découpage en adresses

hiérarchiques une route peut, aisément, être trouvée.

Le protocole Multimedia Mobile Wireless Networks (MMWN) [KAS 97-1] utilise une hiérarchisation

du réseau en clusters pour connaître la localisation des nœuds. Chaque cluster emploie un gestionnaire

de localisation (LM), qui gère la localisation pour chaque groupe auquel il est associé. L’avantage de

MMWN est que seulement les LMs échangent les informations de localisation, donc le surcoût

engendré par les informations de routage est réduit comparé aux protocoles proactifs traditionnels

(DSDV, WRP…). Cependant, la gestion de la localisation est fortement liée à la hiérarchisation du

réseau, rendant la mise à jour et la recherche des informations de localisation complexes. Cette

complexité est due au fait que les messages de recherche de localisation naviguent à travers l’arbre

hiérarchisé des LMs.

Le protocole Cluster Based Routing (CBRP) [JIA 99-1] utilise une hiérarchisation du réseau en

clusters pour réduire le nombre d’informations de routage échangées. Une fois la hiérarchisation du

réseau réalisée, les têtes de cluster connaissent les nœuds qui leur sont rattachées ainsi que les

passerelles pour joindre les clusters adjacents. Lorsqu’un nœud a besoin de déterminer une route, elle

envoie une requête de création de routes (RREQ) à sa tête de cluster uniquement. A la réception de ce

36

paquet, elle le propage à l’ensemble des têtes de cluster l’entourant après avoir ajouté son identifiant

dans l’entête de la requête. Lorsque la tête de cluster détecte que la destination est un de ses membres,

il envoie un paquet de réponse à la source en inversant le chemin contenu dans le paquet RREQ. A la

réception d’un paquet de réponse, les têtes de cluster ne peuvent faire partie de l’ensemble des

chemins qui traversent leur cluster. Dans un tel cas, ils deviendraient des goulets d’étranglement. Par

conséquent, ils essaient de faire passer le trafic en priorité par les nœuds qui leurs sont affiliés.

Les protocoles de routage Optimal Spine Routing (OSR) et Partial-knowledge Spine Routing (PSR)

[RAG 98-1] utilisent une hiérarchisation particulière en backbone, appelée Spine, pour déterminer et

maintenir les chemins. Une hiérarchisation en Spine diffère de la hiérarchisation habituelle en

backbone par le fait que seulement le trafic de contrôle traverse le backbone. Le protocole OSR est

basé sur le protocole à état de liens. Chaque nœud du Spine transmet la connaissance des nœuds de

son cluster aux autres membres du Spine. Un chemin entre une source et une destination peut aisément

être trouvé par chaque nœud du Spine une fois la topologie connue. Chaque source consultera son

nœud de backbone pour connaître la route vers la destination. Le protocole PSR diffère du protocole

précédent sur le fait que chaque nœud du Spine a connaissance d’une partie de la topologie. Cette

partie est composée des nœuds qui sont stables sur le réseau, c'est-à-dire les nœuds qui rompent très

peu de liens avec leur voisinage. Cette connaissance partielle permet de diminuer la taille des

messages d’état de liens échangés sur le Spine.

Le protocole LANdMark Ad hoc Routing (LANMAR) [PEI 00-1] s’inspire fortement du principe du

protocole FSR. Seules les informations concernant la topologie d’une zone proche (limitée à un certain

nombre de sauts) sont échangées périodiquement avec les voisins. De même, uniquement les chemins

pour joindre les nœuds de cette zone proche sont conservés dans la table de routage. Ce principe réduit

la quantité d’informations échangées entre les nœuds et la taille de la table de routage facilitant un

passage à l’échelle. Les nœuds sont divisés en groupe possédant des affinités fortes. Ainsi ces nœuds

sont censés se déplacer le plus possible ensemble. Un chef de groupe est élu pour chaque groupe et

chaque nœud d’un groupe est identifié par une adresse de sous-réseau particulière. Périodiquement,

chaque nœud transmet un vecteur de distance avec la distance le séparant de chaque chef de groupe.

Une fois ces informations diffusées, chaque nœud peut déterminer le chemin pour atteindre les

différents chefs de groupe. Lorsqu’un paquet doit être transmis sur le réseau, la source regarde si la

destination se trouve dans sa zone proche. Si c’est le cas un chemin est donc connu. Si elle ne s’y

trouve pas, le paquet est transmis vers le chef de groupe du sous-réseau auquel appartient la

destination. Au fur et à mesure que le paquet s’approche de ce chef de groupe, les informations

connues sur les nœuds du groupe augmentent. Le paquet peut à un moment ne plus être dirigé vers le

groupe mais vers la destination elle-même.

Le système Near Term Digital Radio (NTDR) [RUP 97-1] crée une hiérarchie en backbone du

réseau. Chaque nœud affilié à un nœud de backbone correspond à une zone. Le protocole de routage

employé dans chaque zone est le protocole Open Shortest Path First (OSPF) généralement utilisé sur

internet pour permettre le routage à l’intérieur de systèmes autonomes. C’est un protocole à état de

liens. Les informations sur les voisins d’un nœud sont échangées périodiquement par ce dernier ou lors

d’un changement de topologie. A la réception de ces informations, chaque nœud les propage à ses

voisins. Ainsi chaque nœud a connaissance de la topologie. Les informations ne sortent pas du

37

système autonome. Ainsi le nœud de backbone fait le relais vers les autres systèmes autonomes.

L’échange des informations de routage entre Anets se fait simplement. Chaque nœud de backbone

génère des états de liens récapitulatifs de sa propre zone et les transmet aux autres nœuds de backbone.

Ainsi, chaque nœud de backbone peut déterminer une route vers l’ensemble des nœuds extérieurs à

son propre système autonome.

2.3 Protocoles utilisant des informations de localisation

Echanger des informations de contrôle pour déterminer les routes consomme de la bande passante.

Cette ressource se faisant rare dans les réseaux ad hoc, le protocole de routage doit tout mettre en

œuvre pour minimiser ces échanges. Pour cela, une solution consiste à réduire ces informations en

précisant la direction vers laquelle se dirigent les informations de contrôle. En fait, en connaissant la

position de la destination, les paquets qui vont à l’opposé de la destination ou au-delà de la position de

la destination, sont généralement peu utiles. Dans ce cas, faire en sorte que ces paquets ne se

propagent pas dans de mauvaise direction et soient plus centrés vers la position de la destination

constitue le point clé des protocoles utilisant des informations de localisation.

Pour déterminer sa position chaque station embarque un récepteur de positionnement, tel que le GPS

(Global Positioning System) [GPS] ou prochainement Galileo. Aujourd’hui les équipements de

positionnement sont petits et extrêmement légers. En effet, un récepteur GPS se compose d’une puce

GPS et d’une antenne. Le fonctionnement d’un système de positionnement est très proche du principe

de triangulation. La constellation de satellites est conçue de telle manière que chaque récepteur voit à

tout moment à n’importe quel endroit du globe 4 satellites. Les récepteurs déterminent la distance les

séparant de chaque satellite et peuvent former une sphère centrée sur chacun de ces satellites.

L’intersection de ces sphères indique la position où se situe le récepteur. La position du récepteur ainsi

connue permet de déterminer ses coordonnées cartésiennes géocentriques (X, Y, Z) ou ses coordonnées

géographiques (latitude, longitude).

La source doit connaître la position de la destination pour orienter convenablement ses informations de

contrôle. Pour cela, un système de localisation peut être employé comme GLS (Grid Location Service)

[LI 00-1]. GLS utilise des serveurs de localisation pour maintenir la connaissance de la localisation de

chaque nœud. Ainsi lorsqu’une source souhaite contacter une destination, elle va au préalable

consulter le serveur de location de la destination le plus proche pour obtenir cette information. Chaque

nœud détermine un ensemble de serveurs de localisation répartis dans le réseau. Le réseau est divisé

en sections carrées qui sont découpées aux alentours d’un nœud, et deviennent de moins en moins

affinées lorsqu’on s’en éloigne. Les serveurs de localisation sont répartis dans ces zones. Plus on est

proche d’un nœud, plus le nombre de serveurs sélectionnés devient important. Plus on s’en éloigne,

plus le nombre de serveurs devient rare. Chaque nœud met à jour périodiquement sa position dans les

serveurs de localisation sélectionnés. La mise à jour est plus soutenue dans les serveurs proches que

dans ceux éloignés. En fait, elle est fonction du déplacement du nœud. S’il ne se déplace que très peu

il met à jour uniquement les serveurs proches, s’il se déplace beaucoup il met à jour la totalité de ses

38

serveurs de localisation. Lorsqu’un nœud nécessite de connaître la position d’un nœud destination, il

suffit de contacter les serveurs de localisation choisis par cette destination.

Dans un premier temps, nous présentons deux protocoles géographiques LAR et DREAM. Nous

présentons le protocole LAR puisqu’il sera employé comme protocole de comparaison dans la suite de

nos travaux. Le protocole DREAM diffère des protocoles de routage traditionnels par les informations

qu’il conserve dans se table de routage qui contient les informations de localisation et non le prochain

nœud permettant de joindre la destination. Nous présentons, par la suite, d’autres protocoles de

routage GPSR, GRID, CAMA, GRA, GDSR qui sont souvent référencés dans la littérature.

2.3.1 Protocole LAR

Le protocole Location-Aided Routing (LAR) [KO 98-1] est basé sur un protocole réactif. Il propose

deux schémas pour réduire les informations de contrôle. Pour cela, chaque schéma va réduire l’espace

de recherche en fonction de la connaissance de la position de la destination ainsi que d’autres

paramètres comme sa vitesse et le temps de rafraîchissement de l’information. Par réduction de

l’espace de recherche, le nombre de nœuds dans cet espace susceptible de transmettre un paquet de

contrôle s’avère bien moins important que dans la totalité du réseau ad hoc. Par conséquent, les deux

schémas du protocole LAR réduisent l’espace de recherche, et seuls les nœuds faisant partie de cet

espace peuvent transmettre les informations de contrôle.

Lorsqu’un nœud a besoin de déterminer une route vers la destination, il a besoin de connaître sa

position pour réduire l’espace de recherche. Dans les deux schémas du protocole LAR, lorsque la

position de la destination n’est pas connue, le protocole diffuse une requête de création de route à la

totalité du réseau. Une fois une route trouvée, la destination insère dans sa requête de confirmation de

route sa position ainsi que des paramètres tels que la vitesse, le temps où la réponse est effectuée, le

sens de déplacement… Le protocole de routage LAR est pleinement utilisé lorsqu’une liaison sur un

chemin est rompue. Connaissant à un instant t0 la position de la destination et sa vitesse, il peut

déterminer à un instant t1 la zone où elle se situe.

Schéma 1 : À partir de la dernière position de la destination (au temps t0) et de sa vitesse v, la source

détermine une zone probable où doit se situer la destination. En effet, si la destination ne se déplace

que dans un sens, elle peut se trouver dans un cercle de rayon v(t1 – t0). La source détermine à partir de

sa position (Xs, Ys) et du cercle où est susceptible de se trouver la destination une zone rectangulaire

qui fera office de zone de recherche dans laquelle sont déterminées les routes. Cette zone rectangulaire

est donc la plus petite zone pouvant contenir la source et le cercle susceptible de recevoir la

destination.

Une fois la zone rectangulaire calculée par la source, elle ajoute dans sa requête de création de route,

les coins du rectangle. Lorsqu’un nœud reçoit la requête, il peut déterminer à partir de sa position s’il

se trouve ou non dans cette zone. S’il s’y trouve, il traite la requête et la diffuse à ses voisins. Dans le

cas où elle est extérieure à cette zone la requête est supprimée réduisant ainsi le nombre

d’informations de contrôle échangées.

39

Schéma 2 : La distance entre un nœud et la destination est l’élément déterminant dans la propagation

d’une requête. Un nœud ne transmet la requête que si sa distance à la destination est plus faible que la

distance à la destination du nœud qui lui a transmis la requête.

Lorsque la source veut envoyer un paquet à un nœud D et qu’elle ne connaît pas une route vers D, elle

émet une requête de détermination de route en y insérant la position de la destination et sa distance

DISTS vis-à-vis de cette dernière. Quand un nœud I reçoit cette requête, il détermine s’il doit la traiter

et la retransmettre ou non. Pour cela, il détermine sa propre distance à la destination DISTI et vérifie si

elle est inférieure à la distance du nœud J qui a transmis le paquet avec la formule : DISTJ + δ ≥ DISTI.

Le paramètre δ permet d’ajuster l’expansion de la zone de recherche. En l’augmentant, il peut ainsi

être employé pour accroître la chance de trouver une route.

Dans ces deux schémas, une route peut ne pas être trouvée. Cet échec peut être dû soit à une zone de

recherche trop petite, soit parce que les paramètres sur lesquels la création de la zone est basée sont

erronés ou tout simplement plus à jour. Un tel échec se révèle des plus dommageables, car le but

premier d’un protocole de routage est de trouver une route si elle existe. Pour pallier ce problème, la

source utilise un protocole réactif plus conventionnel tel que AODV ou DSR lors d’un tel échec.

2.3.2 Protocole DREAM

Le protocole de routage Distance Routing Effect Algorithm for Mobility (DREAM) [BAS 98-1]

change la manière de concevoir les protocoles de routage. Les tables de routage ne contiennent pas le

prochain nœud ou le chemin pour joindre une destination mais les informations de localisation de

chaque nœud. Lorsqu’un nœud veut transmettre un paquet de données, il utilise les informations de

localisation concernant la destination dans sa table et envoie le paquet uniquement dans sa direction.

Ce protocole repose donc principalement sur l’échange des informations de localisation entre les

nœuds. Pour cela, il réduit ces informations suivant deux constats :

• La distance : Deux nœuds éloignés ressentent moins leur déplacement respectif que deux

nœuds proches. Par conséquent, chaque nœud a besoin de mettre à jour sa localisation moins

souvent vis-à-vis des nœuds éloignés.

• La mobilité : Tout nœud qui se déplace doit mettre à jour sa position. Cela doit être fait

souvent d’autant plus qu’il se déplace rapidement.

Chaque nœud émet périodiquement les informations de position le concernant (ses coordonnées, sa

vitesse…). Pour réguler la distance de propagation de ses messages de contrôle, chaque nœud marque

le paquet par une certaine distance. Lorsqu’un nœud le reçoit, il calcule la distance que le paquet a

voyagé. Si elle est plus grande que celle marquée dans le paquet, il est supprimé, sinon il est propagé.

Ces paquets sont transmis d’autant plus souvent que la distance marquée est faible. La fréquence à

laquelle les nœuds émettent les paquets de contrôle est fonction de la vitesse de déplacement du nœud

lui-même. Plus il se déplace rapidement, plus il transmet souvent les informations sur sa position.

40

Lorsqu’un nœud a besoin d’envoyer un paquet à un autre nœud, il détermine l’ensemble des voisins

permettant d’atteindre la destination avec une probabilité p. Il déclenche un temporisateur et émet le

paquet. Lorsqu’un nœud reçoit un paquet, il vérifie s’il en est le destinataire. Si tel est le cas, il regarde

si le paquet est un acquittement ou un paquet de données. Chaque nœud destination acquitte un paquet

de données pour permettre à la source de savoir qu’il est correctement arrivé à destination. Si le même

paquet arrive plusieurs fois à destination, elle acquitte à chaque réception ce paquet pour rendre le

protocole plus robuste (en cas de perte d’acquittement). S’il n’est pas la destination et qu’il est dans la

direction de la destination, il propage ce paquet.

Chaque nœud recevant un paquet et se trouvant dans la direction de la destination calcule les voisins

auxquels transmettre le paquet. Pour cela, il extrait de sa table de localisation, les paramètres de

mobilité et de position concernant la destination. Ces paramètres sont t0, le temps de mise à jour de

l’information, la distance r le séparant de la destination, la vitesse de la destination v et l’angle entre

l’axe des abscisses et la droite passant par lui et la destination γ. Le nœud peut facilement en déduire

les voisins dont leurs positions se situent dans l’espace représenté par l’intervalle [γ-α, γ+α]. α est

déterminé par la formule suivante : α = arcsin v(t1-t0)/r

En connaissant la densité de probabilité de la vitesse de la destination, il est possible de calculer un α

tel que la probabilité de trouver la destination dans la direction [γ-α, γ+α] soit ≥ p avec 0<p≤1. Pour

cela, il revient à déterminer la probabilité telle que P(x≤(t1-t0)v) ≥ p.

Si la source ne reçoit pas d’acquittement dans un laps de temps défini, le temporisateur déclenché à

l’envoi du paquet arrive à expiration. Dans ce cas, elle retransmet le paquet. Cet acquittement et le fait

qu’un paquet de données prend plusieurs chemins ajoutent une surcharge au protocole DREAM.

2.3.3 Autres protocoles à localisation

Dans cette section, nous présentons différents protocoles géographiques qui diffèrent dans la manière

dont ils routent les informations de routage et dont ils réduisent l’espace de recherche. Les protocoles

GPSR et GRA sont particuliers puisqu’ils n’utilisent pas de table de routage pour transmettre les

paquets jusqu’à la destination. Les protocoles GRID et GDSR sont intéressants dans la façon dont ils

réduisent l’espace de recherche. Le protocole CAMA est assez particulier. Il utilise un ensemble de

techniques et leurs possibilités pour réduire le nombre d’informations de contrôle échangées.

Le protocole Greedy Perimeter Stateless Routing (GPSR) [KAR 00-1] utilise deux modes bien

distincts pour router les paquets. Les routes pour chaque paquet sont calculées à la volée donc aucune

table de routage n’est maintenue. Seules les connaissances de la position des nœuds voisins et de la

destination sont nécessaires. Par conséquent, chaque nœud échange périodiquement sa position avec

ses voisins. Dans le premier mode, un nœud recevant un paquet le propage au nœud le plus proche de

la destination dans son voisinage. Lorsque ce mode ne peut être employé (par exemple aucun nœud

n’est plus proche de la destination que soi-même), le nœud forme un graphe planaire de son voisinage.

Il emprunte ce graphe en restant le plus possible dans la direction de la destination. Un nœud réutilise

41

le premier mode, lorsqu’il trouve un nœud dont la distance à la destination est plus petite que la

distance à la destination du nœud ayant changé initialement de mode.

Le protocole GRID [LIA 01-1] prend son nom dans la façon dont le réseau est découpé (sous forme de

grille). Le réseau est divisé en zones carrées de taille égale. Dans chaque zone, un nœud est élu comme

chef. Les informations de contrôle pour la détermination d’une route sont propagées uniquement par le

chef de chaque zone. Lorsqu’un nœud veut créer une route, il diffuse une requête. Seuls les chefs de

zone sont susceptibles de la relayer. Ainsi, le nombre de messages de contrôle est réduit au nombre de

chefs dans le réseau. Lorsque la destination reçoit la requête, elle transmet une réponse en direction de

la source au chef lui ayant transmis la requête. Cette réponse contient en plus la position de la source

ainsi que sa vitesse de déplacement. Un chemin dont les nœuds intermédiaires sont uniquement des

chefs de groupe est déterminé. GRID diffère énormément par son adaptation aux changements de

route. Une route est rompue si un chef de groupe quitte une zone. Avant de quitter la zone, il diffuse le

contenu de sa table de routage. Ainsi, lors de l’élection d’un autre nœud comme chef de zone, ce

dernier connaît la table de routage de son prédécesseur et peut continuer le routage des paquets. Si

c’est la source ou la destination qui rompent le chemin, la source rétablit un chemin en réduisant le

nombre de chefs de groupe visités en fonction de la dernière position connue de la destination.

Le protocole Cellular Aided Mobile Ad hoc (CAMA) [BHA 04-1] centralise l’ensemble des

informations sur un ou plusieurs serveurs distribués. Ces serveurs sont reliés aux réseaux

téléphoniques sans fil (GSM, UMTS…). Par conséquent, chaque station embarque un

émetteur/récepteur ad hoc et un émetteur/récepteur cellulaire. Périodiquement, chaque station envoie

sa position à un serveur CAMA de localisation en utilisant sa liaison cellulaire. Le serveur possède

ainsi l’ensemble des informations sur la topologie du réseau ad hoc et peut par conséquent déterminer

les chemins vers les autres nœuds. Lors de l’émission d’un paquet, si la source ne connaît pas une

route vers la destination, elle consulte, grâce à sa liaison cellulaire, le serveur CAMA pour obtenir la

totalité de la route.

Le protocole Geographical Routing Algorithm (GRA) [JAI 01-1] utilise une vue locale du réseau pour

acheminer les paquets jusqu’à la destination. Chaque nœud suppose connaître la position de ses

voisins et la position de la destination. Lorsqu’un nœud veut transmettre un paquet, il le dirige vers le

nœud voisin le plus proche de la destination. Tout nœud recevant le paquet fait de même jusqu’à ce

qu’il atteigne la destination. Un problème survient lorsqu’un nœud est lui-même le nœud le plus

proche de la destination. Dans ce cas, il ne peut pas transférer le paquet à un nœud voisin, et le paquet

n’atteindra jamais la destination. Dans ce cas, le protocole GRA utilise un protocole réactif

quelconque pour établir une route entre ce nœud et la destination.

Le protocole Global positionning Dynamic Source Routing (GDSR) [BOU 02-1] réduit l’espace de

recherche emprunté par les requêtes de création de route pour en réduire le nombre. Il est basé sur le

protocole DSR et en modifie l’impact en réduisant le nombre de nœuds qui relayent les requêtes.

Chaque nœud doit connaître la position de ses voisins. La contrepartie de cette connaissance est

l’accroissement des informations de contrôle. Lorsqu’un nœud reçoit une requête, il calcule pour

chaque nœud de son voisinage J, l’angle α=∧

IXJ formé entre le nœud I lui ayant transmis la requête,

42

lui-même X et J. Si pour au moins un voisin α > θ (avec θ une valeur donnée) alors le nœud

retransmet la requête. Dans le cas où l’ensemble des voisins forme un angle inférieur ou égal à θ, la

requête est supprimée.

2.4 Discussion

De nombreux protocoles de routage meilleur effort ont été proposés ces dernières années. Ces

protocoles peuvent être classés suivant trois critères : la dissémination de l’information de routage

(cf. §2.1), la hiérarchisation du réseau (cf. §2.2) et l’utilisation d’éléments de localisation (cf. §2.3).

Le trafic résiduel, engendré par les informations de routage, réduit la bande passante du réseau et peut

créer des collisions. Cette diminution de la bande passante du réseau restreint le nombre de flux

pouvant transiter sur le réseau ou la bande passante qu’ils peuvent utiliser. De nombreuses méthodes

ont donc été apportées pour réduire l’impact des informations de routage sur la bande passante du

réseau.

En fonction de la méthode de dissémination de l’information de routage, les protocoles de routage

utilisent des méthodes particulières pour limiter le nombre d’informations échangées. Les protocoles

proactifs (cf. §2.1.1) essaient de réduire le nombre d’informations de routage échangées sur le réseau

en utilisant l’optimisation de relais multipoints comme le protocole OLSR, ou en jouant sur la

fréquence des échanges de la topologie locale comme le protocole FSR par exemple. Les protocoles

réactifs (cf. §2.1.2), quant à eux, réduisent les informations nécessaires au routage en diminuant

l’impact sur la bande passante de la perte d’une route. Pour cela, les nœuds maintiennent plusieurs

routes dans leur table de routage, comme AOMDV par exemple, ou privilégient les chemins les plus

stables, comme ABR par exemple. La réduction des informations de routage des protocoles proactifs

et réactifs bénéficie, également, aux protocoles hybrides (cf. §2.1.3) puisqu’ils combinent ces deux

types de protocoles pour déterminer une route.

Les protocoles de routage peuvent utiliser une hiérarchisation du réseau (cf. §2.2) pour réduire le

nombre d’informations de routage. Cette hiérarchisation, utilisée par les protocoles CBRP, OSR et

PSR, réduit le nombre de nœuds concernés par ces informations. De même, certains protocoles

hiérarchiques, par exemple CGSR, réduisent la taille des tables de routage transmises par les nœuds,

réduisant la bande passante consommée.

Les protocoles, utilisant des informations de localisation (cf. §2.3), sont également un moyen de

réduire la bande passante consommée par la découverte des routes. Bien souvent, les protocoles de

localisation sont des protocoles réactifs et opèrent donc par flux. Ces protocoles diminuent le nombre

d’informations de routage en connaissant la position de la destination. Ils peuvent ainsi réduire le

nombre de nœuds du réseau transmettant les paquets de routage comme par exemple les protocoles

LAR et DREAM. Une réduction de l’espace de recherche peut entraîner l’échec de détection d’une

route. Ainsi, il est toujours nécessaire de combiner cette méthode de recherche avec un autre protocole

de routage.

43

Les protocoles OLSR, AODV et DSR sont les seuls protocoles standardisés dans les réseaux

MANETs. De fait, ces protocoles sont les protocoles de routage implémentés en priorité dans les

équipements supportant les réseaux MANETs. Le contexte de nos travaux est l’utilisation

d’applications multimédia ou temps-réel, fortement consommatrices en bande passante, dans un

environnement mobile ad hoc. Nous choisissons de baser nos travaux sur le protocole AODV puisqu’il

propose, en tant que protocole réactif, une gestion par flux. Ce protocole est donc bien adapté à notre

contexte puisqu’il permet l’obtention d’une route pour chaque flux en fonction de leurs critères. Notre

choix aurait pu se porter sur le protocole réactif DSR. Opérant seulement sur les liens symétriques, le

protocole DSR a un léger surcoût en bande passante (notamment avec l’utilisation de deux fois la

phase de découverte des routes et l’ajout des nœuds du chemin dans l’entête de la requête) comparé à

AODV. Travaillant dans un tel environnement, nous basons nos travaux sur le protocole AODV.

L’ensemble des protocoles, présentés dans ce chapitre, limite les informations de routage nécessaire à

la découverte ou à la maintenance d’une route. Par contre, aucun n’agit sur d’autres facteurs

consommateurs en bande passante. De fait, aucun protocole de routage ne prend en compte les

collisions subies par le réseau. Les collisions entre paquets sont pénalisantes puisqu’elles diminuent la

bande passante utile du réseau et accroissent le délai de bout en bout des paquets.

Dans le but d’optimiser la bande passante des réseaux MANETs, nos travaux se portent, par la suite,

sur :

• La réduction des collisions (cf. §4. Optimisation de la bande passante disponible) : les collisions

entraînent retransmissions et délais. Le protocole de routage doit limiter au maximum cet effet en

évitant les routes saturées. Une route encombrée ne peut accepter de nouveaux flux sans créer de

collisions.

• Le routage géographique (cf. §5. Approches de Réduction de la charge due aux informations de

contrôle) : les protocoles de routage géographique réduisent l’espace de recherche pour diminuer le

nombre de nœuds qui transmettent des informations de routage. En connaissant la position de la

destination, ils peuvent diriger ces paquets de routage directement vers la destination. Réduire

l’espace de recherche peut entrainer un échec à la découverte d’une route même si une existe. Les

protocoles de routage géographique combinent deux types de protocole pour pallier ce problème. Le

premier est utilisé pour chercher une route en réduisant l’espace de recherche, le second (qui diffuse

généralement l’information de routage sur la totalité du réseau comme le protocole AODV) en cas

d’échec du premier. Il est envisageable d’opérer plus en douceur, en utilisant un parcours en

profondeur dont l’espace de recherche est agrandi lors d’échecs successifs à la découverte d’une route.

45

3 Routage à Qualité de Service dans les réseaux MANETs

Avec la montée en puissance des systèmes informatiques, les services offerts aux utilisateurs se sont

multipliés. Du simple traitement de texte dans les années 1980, l’informatique aujourd’hui se veut

multimédia, communicante, omniprésente et mobile. Avec l’avènement du multimédia, images, sons

et vidéos sont maintenant indissociables. Et l’internet ne fait qu’accentuer cet état de fait. D’autre part,

en parallèle à l’application de l’informatique dans les domaines multimédia, son incursion dans

d’autres secteurs a été non moins importante. Ainsi, des systèmes informatiques ont été implantés dans

les systèmes industriels pour la commande de processus, leur surveillance ou d’autres fonctions encore.

L’informatique est aussi implantée dans les systèmes embarqués : aviation, automobile, secteur

maritime… Certains secteurs plus sensibles encore car touchant à la sécurité humaine, ont aussi

intégré les outils informatiques comme par exemple dans la gestion de centrales nucléaires. Mais

disposer de systèmes performants n’implique par forcément que les systèmes offrent à tous leurs

utilisateurs la qualité qu’ils attendent. C’est à ce paradigme que la qualité de service tend à répondre.

Avec l’apparition de nouvelles technologies et de nouveaux moyens de communication, la mobilité

des terminaux n’a cessé de croître. Les utilisateurs veulent ainsi pouvoir se défaire des réseaux filaires

tout en continuant à utiliser les services et les applications auxquels ils étaient habitués. Une telle

évolution des besoins doit être totalement transparente pour l’utilisateur. Ce dernier ne doit pas pâtir

des problèmes inhérents aux réseaux sans fil. Les protocoles de routage meilleur effort, actuellement

en place dans les réseaux MANETs, ne sont pas suffisants pour garantir une certaine qualité de service

(QoS) [QoS] aux utilisateurs. Ces protocoles doivent évoluer et prendre en compte les contraintes

imposées par les applications. Les protocoles de routage à QoS ont ainsi fait leur apparition dans les

réseaux MANETs prenant en compte de nombreuses contraintes de QoS telles que le délai, la bande

passante, la fiabilité, l’économie d’énergie…

46

Combiner mobilité et QoS n’est tout de même pas une mince affaire. La notion de qualité de service a

dû être modifiée dans les réseaux sans fil comparé à celle des réseaux filaires. Dans les réseaux filaires,

les applications temps-réel et multimédia [STA 88-1], nécessitant une garantie des contraintes de QoS,

sont classées en deux domaines distincts :

• Applications aux contraintes dures : les applications aux contraintes dures sont définies de la façon

suivante. Si une opération de l’application rompt une contrainte imposée, elle est considérée

comme sans effet. Dans le pire des cas, le nom respect d’une contrainte peut rendre le système

instable voir inopérant (ex : capteur de température dans un réacteur nucléaire, aide au freinage

dans une voiture, capteur de pression dans un avion, …).

• Applications aux contraintes souples : Ces applications tolèrent une certaine période de temps

durant laquelle les contraintes de QoS ne sont pas honorées. Cependant, la satisfaction de la QoS

est quantifiée par le rapport entre le temps total d’interruption de la QoS et le temps total de

connexion. Ce rapport doit toujours être au dessus d’un seuil spécifié pour respecter les besoins de

QoS (ex : vidéoconférence, VoIP, vidéo à la demande, …).

Dans les réseaux MANETs, il est extrêmement difficile de prendre en compte des applications avec

des contraintes de QoS dures. L’environnement dynamique des réseaux MANETs rend l’état du réseau

instable [JAW 05-1], pouvant à tout moment ne plus respecter les contraintes imposées durant un

certain laps de temps. La notion de garantie de QoS, dans les réseaux MANETs, a ainsi évolué pour

offrir aux applications temps-réel et multimédia deux types de QoS, la QoS souple et la QoS

adaptative [JAW 04-1]. La QoS adaptative introduit le concept de QoS dynamique où les applications

ne fournissent plus une seule valeur par contrainte de QoS mais un ensemble de valeurs. L’utilisation

de la QoS adaptative fournit plus de flexibilité au système et permet au réseau d’adapter les ressources

allouées par les applications suivant les ressources disponibles dans le réseau.

Dans ce chapitre, nous donnons dans un premier temps la définition du routage à QoS. Par la suite,

nous présentons les caractéristiques des métriques de QoS et les modèles d’estimation qui leur sont

associés. Une troisième partie met en avant la complexité rencontrée par les algorithmes de routage à

QoS alors que l’utilité des fonctions poids est présentée dans une quatrième partie. Enfin, différents

protocoles de routage ainsi que leurs méthodes d’accès au support sont présentées. Ce chapitre se

conclut par une discussion sur l’importance des protocoles de routage à QoS.

3.1 Routage à QoS

Pour fournir un service de qualité, l’ensemble de la pile de protocoles utilisé par les équipements du

réseau doit supporter cette qualité de service. Le protocole de routage à QoS est donc indissociable des

autres protocoles pour garantir une QoS de bout en bout. Le protocole de routage à QoS est tout de

même l’élément central du maintien de la QoS dans un réseau [MOH 03-1], [HAN 07-1], [RED 06-1].

Un réseau MANET étant multi-sauts, une route (si elle existe) doit être trouvée entre le nœud source et

le nœud destination. Cette route doit, de plus, garantir les contraintes de QoS imposées par

l’application. Le protocole de routage à QoS permet la détermination d’une telle route. Pour cela, le

47

protocole de routage détermine une route en se basant sur les informations collectées par les nœuds du

réseau.

Les informations collectées sont rattachées aux contraintes de QoS que le réseau doit respecter. Par

exemple, des informations sur le délai entre nœuds voisins seront collectées lorsqu’une application

désire la garantie d’un délai de bout en bout.

Un réseau est modélisé par un graphe G(V, E) où V représente l’ensemble des nœuds du réseau et E

l’ensemble des arcs liant deux nœuds entre eux. Dans un réseau MANET, chaque équipement mobile

représente un nœud du réseau. Chaque liaison radio, entre deux nœuds voisins, représente un arc.

Chaque arc <u, v> est muni d’un poids noté w(<u, v>) exprimé à l’aide d’une ou plusieurs métriques

de QoS. Le poids w(<u, v>) est un vecteur de n composantes (n est le nombre de métriques de QoS) :

w(<u, v>) = [w1(<u, v>), w2(<u, v>), …, wn(<u, v>)].

Figure 3-1 : Exemple de graphe associé à un réseau

La figure 3-1 montre la représentation d’un graphe associé à un réseau. Les métriques utilisées sont le

délai et la bande passante disponible. Les contraintes imposées par l’application sont le délai de bout

en bout (noté ∆D) et la bande passante requise (notée ∆B). Le protocole de routage doit déterminer une

route entre les nœuds S et D garantissant ces deux contraintes. Sur ce réseau, l’ensemble des routes

entre S et D peuvent garantir le délai mais une seule (la route S, A, B, D) peut garantir la bande

passante requise par l’application.

48

Dans un réseau MANET, les nœuds sont en perpétuel mouvement. La topologie du graphe change

donc constamment, en fonction de l’arrivée de nœuds, de la rupture des liens, du départ d’autres

nœuds… Le poids des arcs évolue également et doit, par conséquent, lui aussi être mis à jour. Pour

cela, des modèles d’estimation peuvent être employés. Ces modèles fournissent une approximation du

poids des métriques de QoS.

3.2 Métriques de QoS

Les métriques de routage [WAN 96-1] sont la représentation des liens d'un réseau, elles ont une

implication majeure non seulement sur la complexité des chemins à trouver, mais également sur la

portée des conditions de QoS qui peuvent être supportées. Pour être pleinement fonctionnelles, les

métriques doivent tenir compte des facteurs suivants :

• Pour l’ensemble des métriques sélectionnées, des algorithmes performants doivent être mis en

place lors de la recherche d’une route. La complexité de ces algorithmes doit être comparable à celle

des algorithmes de routage utilisés communément.

• Les métriques doivent refléter les caractéristiques basiques du réseau. Les informations, qu’elles

apportent, doivent si possible supporter les besoins basiques en QoS. Les services, fournis par le

réseau, sont fonction des métriques supportées par le réseau. Donc, les métriques déterminent la

qualité de service apportée par le réseau. Par exemple, si les métriques d’un réseau sont la bande

passante disponible et le coût, la qualité de service est sujette à ces deux métriques.

• Les métriques doivent être orthogonales entre elles. Chaque métrique doit être décorrélée des autres

afin d’éviter les informations redondantes. Les informations redondantes introduisent des

interdépendances entre les métriques diminuant l’efficacité des algorithmes de routage.

Pour se représenter la qualité d’un chemin, l’algorithme de routage calcule le poids de la métrique du

chemin chaque fois qu’un lien lui est ajouté. La façon de calculer ce poids diffère suivant la métrique

qui est employée. Soit wi(<vi, vj>) le poids de la ième métrique sur le lien <vi, vj> et

P=⟨v1, v2, …………, vn-1, vn⟩. Ainsi, les métriques sont divisées en trois grandes classes : Additive,

Multiplicative, Concave.

• Une métrique est additive si : wi(P) = wi(<v1, v2>)+ wi(<v2, v3>)+…………+ wi(<vn-1, vn>).

Exemple de métriques additives : délai, coût, nombre de sauts.

• Une métrique est multiplicative si : wi(P) = wi(<v1, v2>) × wi(<v2, v3>) ×…………× wi(<vn-1, vn>).

Exemple de métriques multiplicatives : fiabilité, disponibilité.

49

• Une métrique est concave si : wi(P) = min{wi(<v1, v2>), wi(<v2, v3>), …………, wi(<vn-1, vn>)}.

Exemple de métriques concaves : bande passante.

3.2.1 Modèles d’estimation

Les protocoles de routage à QoS ont besoin d’informations sur les liens d’un réseau pour sélectionner

le chemin correspondant le mieux aux critères imposés par une application. Ces informations sont

obtenues à l’aide de mesures et d’estimations. Les modèles d’estimations de métriques de QoS jouent

un rôle important dans la détermination des chemins. En effet, plus le modèle est proche de la réalité,

plus justes sont les décisions de routage. De par les variations dans le temps d’un réseau ad hoc, un

modèle représentant, avec justesse, l’état d’un réseau MANET n’existe pas.

Les modèles d’estimations se distinguent, entre eux, suivant le type de méthode utilisée pour collecter

les informations qui les entourent. Pour déterminer une métrique donnée, un modèle d’estimation peut

échanger ou non des données avec l’environnement qui l’entoure. Dans le cas où des données sont

échangées, le modèle d’estimation est dit intrusif. L’utilisation d’un modèle de ce type accroît la

charge d’un réseau MANET, mais fournit bien souvent des résultats plus justes. Un modèle

d’estimation n’interagissant pas avec les autres nœuds du réseau MANET est dit non-intrusif. Un

nœud d’un réseau MANET, employant ce type de modèle, détermine l’état du réseau uniquement avec

les informations qu’il peut collecter à partir de son propre état et de l’environnement qui l’entoure.

Les modèles d’estimation peuvent déterminer l’état de nombreuses métriques, telles que la bande

passante disponible, le délai, le taux d’erreur, l’énergie dépensée … Les applications multimédia et

temps-réel étant principalement sensibles aux contraintes de bande passante et de délai de bout en bout,

nous nous intéressons par la suite uniquement aux modèles estimant ces deux métriques.

3.2.2 Estimation de bande passante disponible

De nombreuses solutions ont été proposées pour déterminer la bande passante disponible en fonction

de la méthode d’accès au support utilisées. Des modèles d’estimations ont été notamment proposés

pour des méthodes d’accès sans contention, telles que TDMA [DU 04-1] ou CDMA-o-TDMA

[CHE 04-1], [CHE 97-1] et [LIN 99-1], et des méthodes d’accès avec contention, telles que

CSMA/CA [CAN 99-1], [KAZ 02-1], [LEE 06-1], [CHE 06-1] et [MEL 00-1]. Des modèles prenant

aussi en compte les interférences entre nœuds ont été proposés [CHE 05-1] et [YAN 05-1]. Ces

modèles tiennent comptent non seulement du trafic des nœuds dans le voisinage immédiat, mais

également du trafic des nœuds hors voisinage immédiat c'est-à-dire les nœuds se situant dans la zone

d’écoute (carrier-sense range).

Nous détaillons dans cette partie seulement deux modèles d’estimation de bande passante disponible.

Le premier modèle est celui proposé par Kazantsidis et Gerla [KAZ 02-1] alors que le deuxième

modèle est celui proposé par Lee et al. [LEE 06-1].

50

3.2.2.1 Méthode de Kazantsidis et Gerla

Cette méthode est basée sur la méthode d’accès au support de communication DCF d’IEEE 802.11. Il

fournit à la couche réseau un ensemble de mesures issues de la couche MAC et LLC. La bande

passante disponible, noté BDi, j, entre deux nœuds voisins i et j est donnée par la fonction suivante :

BDi ,j = (1 – u)*B i, ,j (3-1)

avec u l’utilisation de la file d’attente dans la couche de liaison de données et Bi, ,j la bande passante

du lien <i, j>.

Pour déterminer la bande passante disponible sur un lien, il est d’abord nécessaire d’estimer la bande

passante du lien. Chaque nœud estime, passivement, la bande passante avec ses voisins. La bande

passante consommée par un paquet, de taille S bits, est calculée avec :

∑=

++++=

R

rrTbRTovTcaTsTq

SBP

1

*)(

(3-2)

avec Tq le temps d’attente en file d’attente, Ts le temps de transmission du paquet, Tca la phase

d’évitement de collision, Tov le temps ajouté par le surcoût (ex. RTS/CTS, ACK, entête et délai de

propagation), R le nombre de retransmissions et Tbr le temps de backoff pour la rème retransmission.

La bande passante consommée par un paquet dépend de la taille de paquet, du délai passé en file

d’attente, de la valeur du backoff et du nombre de retransmissions. Pour obtenir une valeur

représentative de la bande passante sur un lien, une fenêtre de 32 paquets est utilisée. La bande

passante d’un lien est donnée par la formule suivante :

Bi, ,j = Moyenne(BPk, k = 1, …, 32)

D’après l’équation (3-1), reste à déterminer le temps d’utilisation de la file d’attente de la couche

liaison de données. Ce temps est obtenu à partir du temps où la file d’attente est vide, noté TempsVide,

durant la fenêtre de transmission des 32 paquets, noté TempsFenêtre. L’estimation de l’utilisation de la

file d’attente de la sous-couche LLC est calculée par :

reTempsFenêt

TempsVideu −= 1 (3-3)

A partir des formules (3-1) et (3-3), la bande passante disponible sur le lien <i, j> est :

jiji BreTempsFenêt

TempsVideBD ,, ×= (3-4)

51

3.2.2.2 Méthode de Lee et al.

Lee et al. [LEE 06-1] proposent une méthode passive d’estimation de la bande passante disponible. La

bande passante disponible est estimée en fonction du temps libre sur le support sans fil. La bande

passante disponible, notée DB, est calculée avec :

DB = C *TauxLibre

avec C la capacité du lien sans fil et TauxLibre le taux durant lequel le support est libre.

Pour obtenir le taux durant lequel le support est libre, les nœuds définissent localement le temps durant

lequel le support est occupé. Pour un nœud i, le support est considéré occupé s’il se trouve dans un des

trois états suivants :

• Emission : le nœud i émet un paquet à l’un de ses voisins

• Réception : le nœud i reçoit un paquet de ses voisins

• Support réservé : un nœud voisin a déclaré le support réservé en positionnant le vecteur

d’allocation du réseau (NAV) au temps de la transmission du paquet et de la réception de son

acquittement.

Par conséquent, le temps d’occupation d’un lien l (noté Tl) à un nœud i est : Tl = TEi + TRi + TVi avec

TEi la somme des temps d’émission du nœud i à ses voisins, TRi la somme des temps où le nœud i

reçoit un paquet et TVi la somme des temps durant lesquels un nœud voisin a réservé le support. A

partir du temps d’occupation, le taux durant lequel le support est libre peut être facilement calculé :

TempsTotal

TTauxLibre l−= 1

avec TempsTotal la période de temps durant laquelle le support est monitoré.

3.2.3 Estimation de délai

Les applications multimédia nécessitent très souvent le respect d’un délai borné de bout en bout.

L’estimation du délai, entre nœuds voisins ou de bout en bout d’un chemin, est dans ce cas

indispensable.

De nombreuses solutions ont été apportées pour estimer le délai. Des modèles estiment le délai de bout

en bout tels que [CHE 99-1] ou [XUE 03-1]. D’autres modèles [BAD 03-1], [MUN 02-1],

[ROM 05-1], [VER 00-1] et [BAR 01-1] estiment le délai d’un lien. Des modèles probabilistes de

délai de lien ont aussi été développés [SHE 01-1], [MER 05-1], [OZD 04-1] et [TIC 04-1]. Ces

modèles probabilistes sont souvent liés au fonctionnement de CSMA/CA, et tiennent compte des flux

qui traversent un nœud ou ses voisins. Ces modèles analytiques utilisent une distribution des flux

52

particulière (généralement l’arrivée des paquets suit la loi de Poisson) et une file d’attente particulière

(M/G/1/K, G/G/1…) afin d’estimer le temps de service d’un paquet dans la file d’attente de l’émetteur.

Dans cette partie, nous présentons deux modèles, un modèle d’estimation du délai d’un lien par sonde

[BAD 03-1], [MUN 02-1] et le modèle d’estimation de bout en bout de Chen [CHE 99-1].

3.2.3.1 Modèle d’estimation de délai à sonde

Dans [BAD 03-1], [MUN 02-1], les auteurs présentent un modèle simpliste et facile à mettre en

œuvre. Ce modèle estime le délai d’un lien en calculant la différence de temps s’écoulant entre la

création d’un paquet Hello et la réception de ce dernier par le destinataire. L’émission d’un tel paquet

Hello ne doit pas être prioritaire sur les paquets de données. Le fait de rester en file d’attente permet de

tenir compte du temps passé en file d’attente par un paquet de données et de ne pas se limiter au temps

de transmission et de propagation du paquet.

Comme pour l’ensemble des modèles simplistes, ceux-ci possèdent des défauts. Les nœuds doivent

être synchronisés entre eux. Comme le délai est calculé en faisant la différence entre le temps de

réception du paquet et son temps de création, les nœuds voisins doivent avoir des horloges

synchronisées pour ne pas fausser l’estimation du délai. De plus les paquets Hello étant diffusés, les

collisions ne sont pas prises en compte. Le délai estimé reste, sensiblement, constant quelque soit la

charge à la réception.

3.2.3.2 Modèle d’estimation de délai de bout en bout de Chen

Chen et al. ont proposé un modèle d’estimation du délai de bout en bout pour le protocole TBP

(Ticket-Based Probing QoS routing protocol) [CHE 99-1]. Les nœuds ne conservent pas le délai

estimé pour atteindre un nœud distant, mais la variation du délai. Pour un chemin P, cette variation est

calculée à partir de la formule suivante :

( ) AncienP

NouveauP

AncienP

NouveauP DDDD ∆−∆××−+∆×=∆ βαα 1 (3-5)

où NouveauPD∆ (respectivement Ancien

PD∆ ) désigne la nouvelle (respectivement l’ancienne) valeur

estimée de la variation du délai du chemin P. Les paramètres α (α < 1) et β (β > 1) sont ajustables.

Connaître la variation du délai permet la sélection des chemins les plus stables, c'est-à-dire les chemins

les plus aptes à fournir la QoS demandée.

3.3 Complexité des algorithmes

Les protocoles de routage à une métrique, telle que le nombre de sauts par exemple, sont bien connus

et sont largement utilisés dans les réseaux MANETs (cf. §2). La plupart de ces protocoles déterminent

la route optimale (possédant le plus faible nombre de sauts par exemple) en un temps raisonnable et

avec un nombre de messages échangés contrôlés. En effet, tout type de problème de routage, à une

53

seule métrique, possède une complexité polynomiale. Ce type de problèmes peut être résolu en

utilisant l’algorithme de Dijkstra ou de Bellman-Ford.

Généralement, les protocoles de routage à QoS doivent eux tenir compte de plusieurs métriques. Le

problème est donc tout autre. Les problèmes de routage à QoS peuvent être multiples :

• respect de contraintes de QoS multiples : les algorithmes de routage à QoS résolvent, dans un tel

cas, le problème MCP (« Multi-Constraint Path) [KO 98-1], [MAS 06-1]. Dans un tel problème,

chaque lien du réseau, noté <u, v>, est caractérisé par un poids

w(<u, v>) = [w1(<u, v>), w2(<u, v>), …, wm(<u, v>)] qui est un vecteur de m composantes (m étant

le nombre de métriques de QoS). La résolution d’un tel problème consiste à trouver un chemin P

qui satisfait l’équation suivante pour toutes les contraintes Ci exprimées sur les m métrique de QoS :

( ) ( ) miCvuwPw iPvu

ii ,,1 ,,,

Kp =><= ∑>∈<

(3-6)

où p est équivalent à ≤ pour une métrique additive ou multiplicative et ≥ pour une métrique

concave.

• optimisation de multiples contraintes : les algorithmes de routage à QoS doivent, dans ce cas,

trouver un chemin optimisant la totalité des métriques de QoS. L’algorithme de routage doit par

conséquent retourner un chemin P respectant la propriété suivante :

( ){ } ( ) ( ) ( ) ( )∑∑>∈<>∈<

><=><=∈∀∧−∈∀',,

,', ,,,1,'Pxw

iiPvu

ii xwwPwvuwPwmiPdsPP pK (3-7)

où P(s, d) représente l’ensemble des chemins entre s et d.

• respect de multiples contraintes et optimisation d’un autre critère : ce problème de routage à QoS

est appelé MCOP (Multi-Constraint Optimal Path). Le chemin trouvé doit respecter l’ensemble des

m contraintes de QoS et optimiser un critère m+1. Notons P’(s, d) l’ensemble des chemins entre les

nœuds s et d respectant l’équation (3-6). Le chemin P∈ P’(s, d) doit respecter la propriété suivante :

( ){ } ( ) ( )' ,,'' 11 PwPwPdsPP mm ++−∈∀ p (3-8)

La complexité des algorithmes de routage à QoS est un critère fondamental. Lorsque le problème est

NP-complet, le temps de résolution ou le nombre de messages échangés par l’algorithme croît

exponentiellement avec l’augmentation du nombre de nœuds présents dans le réseau. Un algorithme

de routage à QoS peut facilement devenir inefficace, surtout si la topologie change fréquemment

comme dans les réseaux MANETs.

Il a été prouvé dans [WAN 96-2] que le problème MCP est NP-complet lorsque les contraintes sont

additives, multiplicatives ou un ensemble des deux. Des méthodes approximatives sont dans ce cas

employées pour diminuer la complexité. Une méthode de filtrage peut être utilisée fonctionnant de la

manière suivante. Lorsque plusieurs chemins sont obtenus entre deux nœuds s et d satisfaisant une

54

première métrique (telle que la bande passante par exemple), un sous-ensemble de ces chemins est

éliminé en optimisant une seconde métrique et ainsi de suite jusqu’à avoir filtré pour l’ensemble des

métriques de QoS. L’utilisation d’une fonction poids combinant un ensemble de métrique de QoS peut

aussi être utilisée pour réduire la complexité des problèmes de routage à QoS. Une telle méthode

permet dans bien des cas de s’approcher de la solution optimale, rendant ce type d’algorithme

particulièrement efficace. L’utilisation d’une fonction poids combinant plusieurs métriques est donc,

dans de nombreux cas, la solution la plus appropriée.

3.4 Fonction poids

L’utilisation d’une fonction poids, pour la recherche d’un chemin, ne permet pas de trouver un chemin

optimal, mais permet de s’en rapprocher. Dans le cas de problèmes NP-complets, il est nécessaire de

trouver un compromis entre efficacité et rapidité ou nombre de messages échangés. Une fonction

poids permet de mixer plusieurs métriques, pour donner seulement une combinaison de l’ensemble. En

utilisant une telle fonction poids, le problème devient polynomial. En effet, il est possible d’appliquer

l’algorithme de Dijkstra ou Bellman-Ford [COR 90-1] sur une telle combinaison.

Les fonctions poids peuvent être classifiées en deux types : les fonctions poids linéaires et les

fonctions poids non linéaires. Une fonction poids est dite linéaire, pour un graphe G(V, E), si elle

respecte la condition suivante : ∀P1 = <s, v1, …, vn, d> ∧ P2 = <s, u1, …, um, d> | w(P1) ≤ w(P2) ⇒

∀<d, t>∈E, w(P1 || <d, t>) ≤ w(P2 || <d, t>) où || est la concaténation d’un lien à un chemin. Une

fonction poids est non linéaire si elle ne respecte pas la condition précédente.

Dans bien des cas, une fonction poids linéaire ne permet pas de s’approcher suffisamment de la

solution optimale. Par contre, elle est très simple à mettre en place. La fonction poids linéaire la plus

facile à exploiter est une fonction poids de type w(P) = αC(P) + β D (P) où α et β sont paramétrables

et C(P) (respectivement D(P)) représente le coût du chemin (respectivement le délai du chemin).

Les fonctions poids non linéaires combinent également plusieurs métriques. Ce type de fonction

apporte bien souvent plus de possibilités pour s’approcher des besoins désirés. Ainsi, il est possible en

utilisant ce type de fonction de pénaliser exponentiellement une métrique alors qu’une autre varie

linéairement le long du chemin. Un exemple de fonction poids non linéaire est le suivant :

( ) ( )( ) ( )PLPD

PBPw

×= . L’algorithme, qui utilise cette fonction poids, trouve un chemin dont la qualité est

un compromis entre bande passante disponible B(P) élevée, un délai D(P) et un taux de perte L(P)

faibles.

L’utilisation d’une fonction poids dépend du contexte dans lequel elle doit opérer. Elle est l’élément

déterminant dans la sélection d’un chemin. Quelque soit le type de fonction poids utilisée, elle doit

s’approcher au mieux du chemin optimal, pour être pleinement efficace. Pour cela, elle doit être

élaborée avec minutie pour s’adapter pleinement aux besoins désirés.

55

3.5 Qualité de Service dans les protocoles de routage

existants

Pour assurer une bande passante à un flux, le protocole de routage à QoS peut réserver ou non la bande

passante désirée. Les mécanismes de réservation de bande passante allouent une quantité de bande

passante sur un chemin. Ces mécanismes sont étroitement liés à la méthode d’accès au support utilisée.

Lorsque la méthode d’accès au support est sans contention telle que TDMA [LIN 99-1], CDMA-o-

TDMA [LIN 99-2], le mécanisme de réservation [JAW 04-2], [JAW 05-2] assure la bande passante

désirée et borne facilement le délai de bout en bout, car le support est exempt de collisions. Avec une

méthode d’accès avec contentions telle que DCF (cf. §1.3.4.1), le trafic qui traverse le réseau est plus

ou moins quantifiable du fait de la réservation de ressources [YAN 05-1], [CHE 05-1]. Une

quantification précise du trafic reste tout de même difficile à estimer à cause de la présence de

collisions. L’utilisation d’un mécanisme de contrôle d’admission de flux permet d’estimer l’impact de

la présence d’un nouveau flux dans l’environnement d’un nœud. Dans un tel environnement, le délai

de bout en bout est plus difficile à estimer. La réservation de bande passante, quelque soit la méthode

d’accès au support utilisée, permet l’acheminement des paquets en respectant, dans un certain seuil, la

bande passante désirée par l’application le temps de la durée de vie du chemin.

La nature instable des réseaux ad hoc (mobilité, fluctuations de la capacité des liens…) empêche

parfois la réservation de bande passante de répondre aux besoins de QoS. Des protocoles de routage

[KAZ 02-1], [MUN 02-1] optent pour une approche optimiste de la QoS sans aucune réservation.

Chaque nœud effectue des mesures et réalise des estimations sur des métriques telles que la bande

passante et le délai. Tant que le chemin sélectionné respecte les contraintes de QoS, les paquets

transitent sur ce chemin. Si pendant un intervalle de temps les contraintes de QoS ne sont plus

respectées, le nœud source se charge de trouver un autre chemin.

Pour fournir la QoS désirée, les protocoles de routage peuvent être dépendants ou indépendants de la

méthode d’accès au support sous-jacente. Pour offrir la QoS demandée, un protocole de routage

dépendant de la méthode d’accès au support est indissociable de cette dernière. De fait, ce type de

protocole est intimement lié à la couche MAC. Un protocole de routage indépendant de la méthode

d’accès offre plus de souplesse que les protocoles dépendant. Ils peuvent être adaptés sur n’importe

quelle méthode d’accès utilisée. Par contre, ces protocoles supposent l’utilisation d’un mécanisme de

réservation de ressource s’il est nécessaire (puisque le mécanisme de réservation de ressource est lié à

la méthode d’accès).

Nous présentons un ensemble de protocoles de routage à QoS classé suivant la dépendance du

protocole à la méthode d’accès du support. Les différents protocoles présentés garantissent

uniquement la bande passante, uniquement le délai, ou la bande passante et le délai.

56

3.5.1 Protocoles de routage à QoS indépendants de la méthode

d’accès au support

Nous présentons 12 protocoles de routage à QoS garantissant les contraintes de bande passante et/ou

de délai. Ces protocoles sont indépendants de la méthode d’accès au support sous-jacente. Le

tableau 3-1 résume ces différents protocoles en fonction des métriques de QoS supportées, s’ils

utilisent ou non un mécanisme de réservation de ressource et s’ils proposent des modèles d’estimations

des métriques de QoS.

Protocole Type Métrique de QoS Réservation de ressource

Modèles d’estimation de métriques de QoS

AAQR Réactif Garantie délai,

optimisation stabilité

Oui Non

ADQR Réactif Garantie Bande passante,

optimisation stabilité

Oui Non

BWR Hybride et

géographique

Garantie bande passante

et optimisation nombre

de sauts

Oui Non

DLR Hybride et

géographique

Garantie délai et

optimisation nombre de

sauts

Oui Non

DSARP Réactif Garantie délai, réduit

gigue

Non Non

GAMAN Réactif Garantie délai,

optimisation taux de

perte des paquets

Oui Non

ODCR Géographique

/ Hybride

Garantie du délai,

optimisation nombre de

sauts

Oui Non

QOLSR Proactif Garantie du délai ou de la

bande passante

Non Non

QoS-AODV Réactif Garantie du délai et/ou de Oui Non

57

la bande passante

QoS-ASR Réactif Garantie Bande passante

et délai, amélioration

stabilité, occupation des

files d’attente

Oui Non

QRMP Réactif Garantie Bande passante

et délai avec optimisation

de la stabilité des routes

Oui Non

TBP Réactif Garantie Bande passante

et/ou délai, optimisation

du coût

Oui/non Oui

Tableau 3-1 : Protocoles de routage à QoS, indépendants de la méthode d’accès au support,

garantissant la bande passante et/ou le délai

Dans [WAN 05-1], le protocole réactif AAQR est proposé utilisant le protocole RTP (Real-time

Transport Protocol) pour garantir les contraintes de délai d’un flux. Lors de la phase de découverte des

routes, la destination choisit la route la plus stable parmi l’ensemble des routes possibles (c’est-à-dire

parmi les routes garantissant le délai). La stabilité d’une route est calculée en fonction de la variance

du délai rencontré par un paquet sur un lien du chemin. Plus cette variance est faible, plus les nœuds

composant un lien bougent peu.

Le protocole ADQR [HWA 03-1] propose un protocole réactif retournant de multiples chemins

disjoints lors d’une recherche de route. La source sélectionne l’ensemble le plus stable parmi les

chemins dont la bande passante cumulée respecte la contrainte de bande passante. La stabilité des liens

d’un chemin est calculée en fonction de la puissance des signaux reçus.

Le protocole BWR [ZHA 04-1] est un protocole de routage hybride à QoS utilisant des informations

géographiques permettant la réduction des informations de routage échangées lors de la recherche

d’une route. Le protocole utilise deux protocoles distincts, le premier est un protocole de routage

proactif permettant d’acquérir la route possédant le plus faible nombre de sauts vers n’importe quel

nœud du réseau. De même, ce protocole permet de récupérer les informations de localisation de

chaque nœud du réseau. Lorsqu’un flux nécessite d’établir une connexion demandant une certaine

bande passante, un protocole réactif prend le relai déterminant une route garantissant la bande passante.

Si plusieurs routes permettent une telle garantie, la source choisit celle possédant le plus faible nombre

de sauts.

Le protocole DLR [ZHA 04-1] est un protocole hybride à QoS. Il utilise un protocole proactif pour

déterminer à tout instant les chemins vers l’ensemble des nœuds du réseau. Le chemin retourné, pour

un nœud, est le chemin possédant le plus faible nombre de sauts. Lorsqu’un flux nécessite un chemin

respectant un certain délai, le protocole compare la borne du délai à celle du chemin possédant le plus

faible nombre de sauts. Si cette borne est supérieure un chemin optimal est trouvé. Dans le cas

58

contraire, un protocole réactif est mis en œuvre pour trouver un chemin dont le délai respecte la

contrainte imposée. La dissémination des informations de routage par ce protocole réactif est restreinte

à une certaine zone géographique. Seuls les nœuds dans cette zone transmettent les informations de

routage.

Le protocole DSARP [SHE 03-1] différencie deux types de trafic, le trafic meilleur effort et le trafic

temps-réel. Un mécanisme de contrôle d’admission est utilisé pour garantir que le trafic meilleur effort

ne perturbe pas le trafic temps-réel. Lorsque le trafic n’a aucune contrainte de temps, le protocole DSR

est utilisé pour déterminer les routes. Par contre lorsque des contraintes de délai sont imposées par

l’application, un algorithme différent est appliqué. Lors de la phase de construction des routes, la

destination envoie un paquet de réponse, RREP, à chaque requête reçue. Les nœuds recevant un

paquet RREP ajoute dans l’entête le nombre de paquets en attente de transmission. Le nœud source, à

la réception de multiples réponses, sélectionne plusieurs chemins et répartit la charge du flux (en

fonction du nombre de paquets en attente de transmission sur chaque chemin choisi) sur le réseau.

Le protocole GAMAN [BAR 03-1] détermine une route à partir d’une vue du réseau. La construction

d’une route est réalisée sur demande. Le protocole utilise un algorithme génétique pour trouver les

chemins. Cet algorithme privilégie les chemins en fonction d’un taux d’arrivée élevé de paquets et un

délai faible. L’algorithme génétique suit un cycle composé des opérations suivantes : détermination

d’une population, évaluation des performances, sélection des individus et l’application d’opérations

génétiques. Un tel algorithme converge rapidement vers une route optimale dans un environnement

peu peuplé mais devient peu efficace dans de larges réseaux.

Le protocole ODCR [ZHA 05-1] propose un protocole de routage hybride et géographique. Chaque

nœud émet périodiquement, à ses voisins, un vecteur contenant l’ensemble des nœuds avec lequel il

possède un chemin ainsi que la distance les séparant. Chaque nœud peut ainsi déterminer la route

possédant le plus faible nombre de sauts vers l’ensemble des nœuds du réseau. Lorsqu’un flux

nécessite une route garantissant un certain délai, il vérifie dans un premier temps si la route pour

joindre la destination respecte la contrainte de délai. Si tel est le cas, la route possédant le plus faible

nombre de sauts correspond. Sinon, la source diffuse dans le réseau une requête de création de route.

Seuls les nœuds présents dans une certaine zone de recherche comprenant la source et la destination

peuvent transmettre une telle requête limitant de ce fait la surcharge engendrée par les informations de

routage. La destination sélectionne la route avec le coût le plus faible parmi les routes trouvées

garantissant le délai.

Le protocole QOLSR [MUN 02-1] est un protocole de routage proactif basé sur le protocole OLSR.

Ce protocole permet de garantir la bande passante ou le délai. Un mécanisme d’admission de contrôle

est utilisé pour éviter qu’un nouveau flux dégrade la QoS des flux déjà présents. Le mécanisme de

contrôle d’admission analyse la bande passante disponible pour permettre la sélection d’un MPR par

un nouveau nœud.

Le protocole QoS-AODV [PER 00-1] est un protocole réactif basé sur le protocole AODV. Ce

protocole permet la garantie du délai et/ou de la bande passante. Un nœud intermédiaire relaie une

requête RREQ si la bande passante disponible est supérieure à celle des chemins préalablement reçus

59

ou si le délai est inférieur à celui des chemins préalablement reçu. Si le délai ou la bande passante du

chemin ne respecte par une de ces contraintes la requête RREQ est supprimée.

Le protocole QoS-ASR [LAB 02-1] est un protocole réactif à QoS. Lors de la sélection des chemins,

un nœud retransmet une requête de routage seulement si la bande passante disponible est suffisante

pour accepter le flux, et le délai est inférieur à la borne imposée. Si ces contraintes sont respectées une

fonction poids est utilisée pour déterminer la qualité du chemin. Si la qualité du chemin est inférieur à

un certain seuil, la requête est transmise à son voisinage. Cette fonction poids tient compte de

nombreux paramètres, comme le taux d’utilisation des files d’attentes, la stabilité de lien, la bande

passante disponible et le délai de transmission.

Le protocole QRMP [WAN 01-1] est un protocole de routage à QoS réactif. Ce protocole garantit la

bande passante et le délai d’un chemin. Chaque nœud, à la réception d’une requête, ajoute des

informations concernant sa mobilité (vitesse, sens de déplacement…). A la réception des différents

paquets de routage, la destination détermine la route la plus stable. La stabilité d’une route est

déterminée par le temps durant lequel cette route reste valide. Ce temps représente le temps minimal

de connectivité sur un lien du chemin.

Le protocole TBP [CHE 99-1] est un protocole de routage réactif. Il permet de garantir le délai ou la

bande passante en optimisant le coût du chemin. Lorsqu’un nœud source désire trouver une route, il

émet une sonde qui porte une quantité totale de tickets. Il y a deux types de tickets : les verts pour

maximiser la probabilité de trouver un chemin avec le plus faible coût et les jaunes pour déterminer le

chemin avec le plus faible délai ou la plus grande bande passante disponible. A la réception d’une

sonde, un nœud intermédiaire décide, en fonction de son état, si la sonde doit être divisée en fonction

du nombre de tickets et vers quels voisins, les nouvelles sondes doivent être propagées.

3.5.2 Protocoles de routage à QoS dépendants de la méthode d’accès

au support

Nous présentons 15 protocoles de routage à QoS garantissant les contraintes de bande passante et/ou

de délai. Ces protocoles sont dépendants de la méthode sous-jacente d’accès au support. Le

tableau 3-2 résume ces différents protocoles en fonction des métriques de QoS supportées, le type de

méthode d’accès au support utilisé, s’ils utilisent ou non un mécanisme de réservation de ressource,

s’ils proposent des modèles d’estimations des métriques de QoS et s’ils prennent en compte les

interférences à deux sauts.

Le critère des interférences à deux sauts ne concernent seulement les protocoles dépendant d’une

méthode d’accès au support avec contention. En effet, un nœud détecte que le support est occupé si la

force du signal est supérieure à un seuil, nommé Carrier-Sense Threshold. Ce seuil a une sensibilité

plus importante que la puissance requise pour la compréhension d’une trame. Un tel seuil est

positionné de telle manière qu’un nœud détecte que le support est occupé lors de la transmission d’une

trame par un nœud situé à deux sauts. De fait, un nœud voit sa bande passante réduite par un nœud

situé à deux sauts. Une méthode d’accès sans contention, telles que TDMA ou CDMA, n’est pas

60

concernée par ce problème puisque l’accès au support est régi par les slots et non par l’écoute du

support.

Protocole Type Métrique de

QoS

Type de méthode

d’accès

Réservation

de

ressource

Modèles

d’est. de

métriques

de QoS

Interférences

à 2 sauts

AQOR Réactif Garantie BP et

délai

Méthodes d’accès

avec contention

Oui Oui Non

CAAODV réactif Garantie BP IEEE 802.11 Oui Oui Oui

CACP Réactif Garantie BP IEEE 802.11 Oui Oui Oui

CBCCR Hiér. -

Proactif

Garantie BP CDMA-o-TDMA Oui Oui Non concerné

CCBR Proactif Garantie BP CDMA-o-TDMA Oui Oui Non concerné

CEDAR Hiér. -

réactif

Garantie BP IEEE 802.11 Oui Non Non

CLMCQR Réactif Garantie délai,

BP et de la

fiabilité

IEEE 802.11 Non Non Non

D-LAOR Réactif Garantie du

délai et optim.

nombre de sauts

IEEE 802.11 Non Non Non

IAR Hybride Garantie BP IEEE 802.11 ou

TDMA

Oui Non Oui / (Non

concerné pour

TDMA)

LS-MPR Réactif Garantie BP CDMA-o-TDMA Oui Oui Non concerné

MCNRP Hiér. -

Réactif

Garantie BP TDMA Oui Oui Non concerné

NSR Proactif Garantie BP et

métriques

calculées à

partir des nœuds

et états de lien

TDMA Oui Non Non concerné

61

ODQOS Réactif Garantie BP,

optim. délai et

nombre de sauts

TDMA Oui Non Non concerné

QGUM Géo. /

Réactif

Garantie du

délai, BP et taux

d’erreur de

paquets

IEEE 802.11 ou

TDMA

Oui Non Non concerné

QoSOLSR Proactif Garantie de BP IEEE 802.11 Oui Oui Oui

Tableau 3-2 : Protocoles de routage à QoS, dépendants de la méthode d’accès au support, garantissants

la bande passante et/ou le délai (Hiér : Hiérarchique, Géo : Géographique, BP : Bande Passante,

Optim : Optimisation, CDMA-o-TDMA : CDMA over TDMA).

Le protocole AQOR [XUE 03-1] est un protocole de routage réactif utilisant un accès au canal

distribué. Il propose une méthode pour déterminer la bande passante disponible et le délai de bout en

bout d’un chemin. A partir de ces informations, le protocole détermine les routes respectant les

contraintes de bande passante et de délai imposées par un flux.

Le protocole CAAODV [CHE 05-1] propose un protocole réactif basé sur le protocole AODV. La

bande passante disponible sur un médium partagé est estimée par l’émission de paquets Hello par

chaque nœud du réseau. Ces paquets Hello comprennent la bande passante consommée par les nœuds

situés dans le voisinage proche et dans le voisinage à 2 sauts. Grâce à une telle estimation de bande

passante, le protocole de routage trouve une route pouvant fournir les besoins de bande passante requis

par un flux.

Dans [YAN 05-1], le protocole CACP est présenté. Ce protocole de routage réactif permet la garantie

de la bande passante avec une méthode d’accès au support distribuée. Un modèle pour déterminer la

bande passante disponible sur le médium est proposé. Il détermine la bande passante consommée par

la présence d’un nouveau flux et les nœuds avec lesquels le flux peut interférer sont alertés d’une telle

présence lors de la phase de découverte des routes. Un flux est accepté sur le réseau uniquement si les

nœuds avec lesquels il interfère possèdent suffisamment de bande passante pour que ce flux ne

dégrade pas les flux déjà en place. Un contrôle d’admission est donc mis en place sur les nœuds,

pouvant refuser un nouveau flux même si ce dernier ne les traverse pas.

Dans [CHE 97-1], le protocole CBCCR et une estimation de la capacité du canal sont présentés. Les

auteurs proposent que le réseau soit hiérarchisé en clusters. Les nœuds du réseau utilisent une méthode

d’accès au médium de type CDMA-o-TDMA. Chaque nœud groupé dans le même cluster possède le

même code. Un protocole de routage proactif, basé sur DSDV, est utilisé pour déterminer le nombre

de slots disponibles entre deux nœuds du réseau. L’utilisation de codes différents entre clusters permet

de simplifier ce calcul de bande passante. Une passerelle reliant deux clusters voit ses slots divisés

entre les deux clusters. En effet, devant changer de code, les slots ne peuvent être communs. Comme

une passerelle est un nœud intermédiaire sur un chemin, le nombre de slots est facile à calculer

62

puisque le nombre de slots libres sur le lien entre un nœud et une passerelle correspond au nombre de

slots susceptibles d’être réservés.

Le protocole CCBR [LIN 99-1] propose un algorithme calculant la bande passante disponible pour un

chemin. Cet algorithme adapte l’algorithme proposé dans le protocole CBCCR dans un environnement

non hiérarchisé. Pour fonctionner, il nécessite l’utilisation d’un réseau dont la méthode d’accès au

support est CDMA-o-TDMA. La capacité d’un chemin est exprimée en termes de slots libres. Le

protocole DSDV est utilisé pour déterminer les routes. Les informations de routage sont utilisées pour

rafraîchir les slots libres dans la table de routage. L’algorithme de CCBR calcule la meilleure

combinaison de slots libres sur un chemin retournant ainsi la bande passante maximum disponible sur

un tel chemin. Lorsqu’un flux nécessite la réservation de slots en direction d’un nœud destination, la

source consulte sa table de routage. Si le nombre de slots est suffisant, une phase de réservation est

entreprise sur le chemin.

Le protocole CEDAR [SIV 99-1] est un protocole hiérarchique. Les nœuds du réseau forment un

réseau à backbone. Lors de la recherche d’une route à QoS, le nœud backbone du nœud source

cherche une route vers le nœud backbone du nœud destination. Pour cela, un protocole réactif est

utilisé. Des informations d’état sur la topologie du réseau sont propagées seulement quand des seuils

sont atteints. Quand la bande passante croît, l’information traverse lentement le réseau. Par contre,

lorsque la bande passante d’un lien décroît, l’information traverse rapidement le réseau évitant ainsi à

des nœuds de choisir un tel lien alors que la bande passante n’est plus disponible.

L’heuristique CLMCQR [FAN 04-1] propose à partir d’une vue du réseau de déterminer les chemins

respectant des contraintes de bande passante, de délai et de fiabilité. Pour cela, l’algorithme Dijkstra

ou Bellman-Ford est appliqué au réseau avec une fonction poids mixant ces trois paramètres. Les liens

du réseau ayant une bande passante disponible inférieure à la bande passante requise sont retirés du

réseau (donc ils ne sont pas considérés lors du calcul d’une route). La fiabilité d’un lien est

transformée en métrique additive en utilisant un logarithme et combiné au délai. La combinaison de

ces deux métriques permet la sélection du chemin.

Le protocole D-LAOR [SON 03-1] est un protocole de routage réactif. Il permet de garantir le délai en

optimisant le nombre de sauts du chemin. A la réception d’une requête RREQ, un nœud intermédiaire

retransmet un paquet RREQ lorsque le délai et le nombre de sauts du chemin sont plus faibles que

ceux des chemins préalablement reçus.

Le protocole IAR [GUP 05-1] est un protocole de routage hybride permettant d’assurer à un flux une

certaine quantité de bande passante. Chaque nœud émet périodiquement un état des liens qui est

propagé sur la totalité du réseau. Ainsi, chaque nœud possède une vue du réseau. Lorsqu’une route a

besoin d’être trouvée, le nœud source utilise différents algorithmes (avec des contraintes différentes)

déterminant un ensemble de routes de bout en bout. Un paquet d’allocation est envoyé sur chacun de

ces chemins. Un tel paquet est propagé seulement si un nœud peut réserver la bande passante requise.

A la réception de tels paquets, la destination choisit la meilleure route suivant l’un des critères

suivants : la route ayant le plus de bande passante ou la route avec le plus faible coût.

63

Le protocole LS-MPR [CHE 04-1] est un protocole de routage à QoS réactif. Il utilise la méthode

d’accès au médium CDMA-o-TDMA pour réserver la bande passante. Ce protocole retourne un

ensemble de chemins dont la bande passante cumulée permet le respect de la contrainte de bande

passante. La destination est l’élément déterminant les chemins susceptibles de convenir aux besoins.

Pour cela, elle détermine les slots à réserver de bout en bout des chemins évitant ainsi un quelconque

conflit entre slots lors de la réservation. Un tel conflit interrompt la réservation des ressources puisque

la réservation ne peut être assurée de bout en bout.

Le protocole MCNRP [DU 04-1] est un protocole de routage hiérarchique. Ce protocole utilise

l’hétérogénéité des caractéristiques des nœuds pour les diviser en classe. Ainsi, un réseau à bakbone

est formé avec les nœuds possédant une bande passante élevée et une portée conséquente. Seuls ces

nœuds peuvent transmettre les informations de routage réduisant de ce fait la surcharge en paquets de

routage. Ce protocole garantit la bande passante requise par un flux sur un chemin. Pour cela, un

mécanisme de réservation de ressource particulier est utilisé permettant de pouvoir réserver les slots de

bout en bout si cela s’avère possible.

Dans NSR [STI 04-1], chaque nœud maintient les informations le concernant ainsi que l’espace qui

l’entoure. Pour réaliser la fonction de routage, un nœud émet périodiquement au reste du réseau les

informations le concernant. L’intervalle de temps avec lequel ces informations sont propagées devient

plus grand avec l’augmentation de la distance. Une telle connaissance de l’état des nœuds du réseau

permet à un nœud de déterminer la présence de connectivité avec un autre nœud du réseau ainsi que la

perte de connectivité si le modèle de propagation est connu. Le routage à QoS est réalisé à partir

d’états imprécis du réseau. En déduisant les liens entre paires de nœuds à partir de leurs états, un nœud

peut facilement calculer une route en utilisant, par exemple, l’algorithme de Dijkstra. Les métriques de

routage peuvent être multiples et sont déduites pour un lien en fonction des états des nœuds (ainsi que

de leurs voisins) qui le composent.

Le protocole ODQOS [HO 02-1] est un protocole de routage à QoS réactif. Il garantit la bande

passante requise par un flux sur un chemin. Ce protocole dépend d’un accès au médium TDMA pour

réaliser la sélection et la réservation des slots. Ce protocole considère chaque trame TDMA

distinctement. Ainsi, il peut réserver les slots sur des trames différentes. Lors de la sélection des

chemins, la destination sélectionne le chemin possédant le plus faible délai de bout en bout. Ce délai

est calculé en fonction des slots réservés. Si plusieurs chemins possèdent le même délai, le chemin

possédant le moins de sauts est choisi. Le problème de ce protocole est que la totalité des slots libres

sont réservés durant la phase de découverte des routes. Ils sont libérés lors de la confirmation

d’acquisition d’une route.

Le protocole QGUM [ABD 06-1] propose un protocole de routage géographique basé sur le protocole

GPRS. Ce protocole de routage s’adapte aussi bien à une méthode d’accès avec contention que sans

contention. Un mécanisme de contrôle d’admission est mis en place sur chaque nœud pour vérifier que

le nœud sélectionné lors de la phase de découverte des routes respecte les contraintes de délai, de

bande passante et de taux d’erreur de paquets. Ce protocole de routage choisit le nœud le plus proche

de la destination pouvant relayer l’information. Chaque nœud applique cette méthode de sélection du

prochain nœud. Si un nœud ne peut respecter les contraintes imposées, l’application est prévenue d’un

64

tel échec et recommence la découverte des routes en ôtant le nœud le plus proche de la destination

précédemment sélectionnée.

Le protocole QoSOLSR [NGU 07-1] est un protocole de routage proactif. Il est basé sur le protocole

OLSR. Périodiquement, chaque nœud obtient le chemin ayant la plus grande bande passante

disponible vers les autres nœuds du réseau. Pour satisfaire les contraintes d’un nouveau flux, le nœud

source calcule la bande passante de bout en bout requise par ce flux. Si la bande passante disponible

est supérieure à la bande passante requise, le flux est accepté. Les paquets, des flux acceptés, sont

forcés à suivre la route sélectionnée par le nœud source. La route reste inchangée jusqu’à qu’un lien

soit rompu. Un mécanisme de contrôle d’admission empêche que les flux meilleur efforts empiètent

sur la bande passante réservée par les flux à QoS.

3.6 Discussion

De par la nature variable du médium et le déplacement des nœuds, la gestion de la qualité de service,

dans les réseaux MANETs, n’est pas chose aisée. Durant une communication, le protocole de routage

à QoS est un élément déterminant dans la découverte et la maintenance de chemins garantissant des

contraintes de QoS.

Les applications multimédia nécessitent entre autres une garantie de bande passante et du délai. De

nombreux protocoles de routage, permettant de garantir au moins l’une de ces métriques, ont été

proposés ces dernières années. Ces protocoles peuvent être proactifs, réactifs ou hybrides. Les

protocoles proactifs mettent à jour régulièrement leur table de routage par l’envoi périodique

d’informations de routage sur le réseau. Pour garantir à un flux la QoS demandée, un mécanisme

adapté pour la réservation de ressources doit être utilisé. En effet, il doit permettre une gestion par flux,

en maintenant dans une table (pour la durée de la communication) le chemin sélectionné à l’instant où

le flux requiert un chemin. Le mécanisme de réservation de ressources évolue en fonction de l’arrivée

des flux c'est-à-dire qu’il réserve la bande passante nécessaire sur demande. Une telle réservation

engendre un délai supplémentaire pour réserver la bande passante d’un nouveau flux. Les protocoles

réactifs possèdent, quant à eux, une gestion de la QoS sur demande. Ils cherchent une route lorsqu’un

nouveau flux se présente. Le mécanisme de réservation de ressources peut facilement être couplé au

mécanisme de découverte des routes. Ce type de protocole est donc pleinement efficace avec un

mécanisme de réservation de ressources puisqu’aucun délai supplémentaire n’est engendré par la

réservation. Du fait d’une gestion par flux, les protocoles réactifs sont moins dépendants des métriques

de QoS que les protocoles proactifs. De fait, un protocole de routage réactif peut trouver une route

avec le plus faible délai pour une application donnée et une route avec le plus faible taux d’erreur pour

un autre type d’application. Avec la garantie de la QoS, les protocoles proactifs et réactifs souffrent,

tout de même, d’une maintenance délicate des routes. La gestion de la perte des routes est également

réalisée par flux. La rupture d’un lien engendre souvent la perte des routes de plusieurs flux. De fait, le

réseau peut subir une congestion temporaire le temps de rétablir l’ensemble des flux. Les protocoles

hybrides sélectionnent périodiquement une route optimisant une métrique et gèrent réactivement la

QoS par flux. Ce type de protocole s’adapte mieux aux besoins des flux que les protocoles proactifs

65

mais le nombre de paquets de routage échangés est bien supérieur à celui échangés par les protocoles

proactifs. Contrairement aux protocoles proactifs qui souffrent d’un délai en cas de réservation de

ressources, les protocoles hybrides souffrent d’un délai en cas de réservation de ressources mais aussi

en cas de recherche sur-demande de route si la route obtenue périodiquement ne convient pas. Vis-à-

vis des protocoles réactifs, les protocoles hybrides émettent moins de paquets de routage uniquement

si la route obtenue périodiquement respecte les contraintes du flux, sinon ce nombre est plus important.

Les utilisateurs nécessitant toujours plus de qualité, la bande passante requise par les applications

multimédia et temps-réel n’a cessé de croître. Les différents protocoles présentés dans ce chapitre

permettent la garantie de contraintes telles que la bande passante ou le délai. Par contre, très peu de ces

protocoles influent sur les paramètres pénalisant la bande passante du réseau. Les protocoles tels que

QGUM, ODCR ou BWR utilisent un routage géographique pour réduire le nombre de paquets de

routage échangés lors de la création d’une route. Diminuer les informations de routage est un moyen

d’augmenter la bande passante disponible du réseau. De même, les protocoles, comme ADQR ou

AAQR, sélectionnent les routes les plus stables garantissant les contraintes de QoS. Augmenter la

durée de vie d’une route, réduit le nombre de paquets nécessaires à la maintenance des routes en place.

Le protocole de routage à QoS doit tout mettre en œuvre pour accroître la bande passante disponible

du réseau. Avec l’augmentation de la bande passante disponible dans le réseau, le nombre de flux

acceptés par le réseau est plus important, ou les flux peuvent consommer une bande passante plus

importante.

Les différents protocoles, que nous proposons dans les chapitres suivants, ont pour but principal

l’accroissement de la bande passante du réseau. Nos protocoles utilisent une gestion par flux, pour

connaître au mieux les besoins en QoS désirés par un flux. Ainsi, les protocoles proposés sont de type

réactif.

67

4 Optimisation de la bande

passante disponible

4.1 Bande passante : une ressource critique

De nos jours, le besoin en bande passante des applications ne cessent de croître. En effet, proposant

toujours plus de fonctionnalités aux utilisateurs, ce besoin s’avère croissant. Le domaine d’application

des réseaux ad hoc s’étend aussi bien à des applications peu consommatrices en bande passante qu’à

des applications fortement consommatrices. La bande passante de ce type de réseaux est

particulièrement limitée. Actuellement, avec la norme IEEE 802.11g le débit maximal s’élève à

54 Mbits/s. Ce débit reste très faible comparé aux débits que peuvent atteindre les réseaux filaires

(plusieurs centaines de Gbits/s avec la fibre optique).

Pour supporter le plus grand nombre d’applications sur un réseau ad hoc, il est nécessaire d’optimiser

au maximum la bande passante. Le support de transmission étant partagé entre la totalité des stations,

des collisions peuvent subvenir, engendrant une perte en bande passante non négligeable. En effet,

lorsqu’une collision est détectée, les stations émettrices doivent réémettre leurs paquets. La

retransmission a tendance à augmenter la bande passante consommée et par conséquent accroître le

nombre de collisions.

Les collisions sont un handicap pour les réseaux à support partagé. A 85% de sa charge maximale, un

réseau IEEE 802.11 ad hoc (dépourvu de stations cachées) tend vers sa bande passante utile maximale

(environ 74% de la bande passante du réseau) [HAD 99-1]. En effet avec une telle charge, les

collisions entre les stations deviennent particulièrement importantes engendrant un fort délai dans la

transmission des paquets (le temps pour acquérir le support est important) et le débordement des files

68

d’attente (avec la suppression des paquets les plus récents). Des mécanismes peuvent être employés

pour réduire l’impact des collisions. En effet, le mécanisme RTS/CTS permet de diminuer l’impact

des collisions créées par le phénomène des nœuds cachés. Les collisions s’appliquent ainsi sur des

trames plus courtes réduisant d’autant la bande passante consommée lors des retransmissions. Ce

mécanisme, certes essentiel, agit lorsque les collisions se sont produites. Il serait intéressant d’opérer

avant que de telles collisions se produisent. Ainsi, la bande passante est préservée, et peut être affectée

à l’utilisation par d’autres flux. Réduire les collisions rend, de fait, le mécanisme RTS/CTS

(consommateur en bande passante) moins indispensable.

4.1.1 Paramètres influant sur la diminution de la bande passante

Les réseaux sans fil sont soumis à de nombreux paramètres impactant la bande passante utile. La

bande passante des réseaux sans fil peut être détériorée à la fois soit par des phénomènes physiques

dont sont dispensés généralement les réseaux filaires, soit par les fonctionnalités des protocoles

employés. Nous nous intéressons dans ce chapitre principalement aux paramètres pouvant être pris en

compte par les protocoles de la couche réseau. Ainsi, les paramètres consommateurs en bande passante

liés par exemple aux protocoles implantés dans la couche 2 des réseaux IEEE 802.11 (temps d’accès

au support, informations de topologie échangées…) ne seront pas détaillés.

Les phénomènes physiques opérant sur la qualité des informations échangées sont liées aux

caractéristiques du médium, l’air, et au partage de ce support. Lorsqu’une station désire émettre des

informations, elle module ses données avant de les envoyer. Les ondes électromagnétiques, liées aux

différents signaux, se perturbent mutuellement. Ces perturbations vont ainsi accroître le taux d’erreurs

et le nombre de collisions.

Le taux d’erreurs est lié aux caractéristiques du canal de transmission. Le canal de transmission peut

être plus ou moins sensible à des bruits électromagnétiques extérieurs (bruit thermique, bruit

d’intermodulation, bruit impulsif …) comme aux propagations multitrajets entrainant une plus ou

moins bonne réception des signaux. Lorsque l’information est démodulée, l’information numérique

obtenue peut être erronée et différente de celle initialement transmise. Le contrôle d’erreurs implanté

au niveau liaison de données du standard IEEE 802.11 permet de détecter de telles erreurs et de les

isoler. Une trame erronée est par conséquent supprimée, à charge de l’émetteur de la retransmettre. Ne

recevant pas d’acquittement de la part du récepteur, l’émetteur suppose qu’une collision est survenue.

Une collision entre deux émissions survient lorsque les stations émettrices sont situées à portée radio

d’un des récepteurs. Les transmissions se perturbant, le récepteur est incapable de les différencier. Les

stations émettrices doivent ainsi retransmettre leurs trames.

Le taux d’erreur important des réseaux sans fil et le nombre de collisions subies par les trames de

données sont autant de facteurs réduisant la bande passante utile des réseaux ad hoc. Le protocole de

routage peut lors de la découverte des routes éviter celles qui subissent beaucoup de collisions (ajouter

du trafic supplémentaire ne ferait qu’accroître le nombre de collisions) ou celles qui ont un taux

d’erreurs important.

69

Les facteurs physiques ne sont pas les seuls à influer sur la diminution de la bande passante utile du

réseau. Le protocole de routage lui-même est un facteur consommant de la bande passante. En effet,

les stations échangent entre elles des informations de routage pour pouvoir acheminer les paquets de

données entre deux stations. Plusieurs tâches affectées aux protocoles de routage sont plus ou moins

consommatrices en bande passante suivant les méthodes utilisées. Ainsi, le protocole de routage

doit assumer les tâches suivantes :

– Contrôle de la topologie : pour conserver la cohérence des routes déjà existantes, les stations

ont besoin de savoir si la connectivité avec leurs voisins est toujours établie. La détection de

la perte d’un lien doit être prise en compte par le protocole de routage qui doit recréer une

route si le besoin s’en fait ressentir, rôle généralement dévolu à la partie maintenance des

routes. Une station employant le protocole de routage AODV peut utiliser deux méthodes

pour détecter la création ou la perte d’un lien vis-à-vis des voisins vers lesquels elle doit

propager des paquets de données. La première méthode qu’utilise AODV est l’envoi

périodique de paquets HELLO. Ces paquets annoncent à l’ensemble du voisinage d’un nœud

sa présence. L’avantage de ce type de technique intrusive est que les stations sont capables de

connaître la création ou la perte d’un lien assez rapidement. La réactivité de cette technique

dépend principalement de la fréquence d’envoi de ces paquets. Par contre, ils ont un coût non

négligeable sur la bande passante utile du réseau. Une deuxième méthode utilise la couche de

niveau inférieur pour connaître l’état d’un lien. En effet, lorsque la couche MAC échoue à

transmettre un certain nombre de fois le même paquet, c’est-à-dire que la station ne reçoit pas

d’acquittement annonçant la bonne réception du paquet, elle prévient la couche réseau pour

l’avertir de la perte du lien. Cette méthode est moins consommatrice en bande passante que

son homologue tout en assurant une faible latence dans la détection de la perte du lien.

– Calcul de routes : le protocole de routage détermine les routes en émettant sur le réseau des

informations de routage. Suivant le type de protocole utilisé, proactif ou réactif, les nœuds

peuvent émettre ces informations périodiquement ou seulement lorsque le besoin d’une

nouvelle route se fait ressentir. Par exemple, une station utilisant le protocole AODV diffuse à

l’ensemble de ses voisins un paquet de demande de création de route RREQ. Chaque nœud

recevant ce paquet le retransmet s’il ne connaît pas de route vers la destination. L’émission de

tels paquets doit être contrôlée car ils consomment également de la bande passante. De tels

paquets peuvent également créer des collisions avec les nœuds voisins. Pourtant de nombreux

paquets RREQ ne sont pas réellement utiles à la création d’un chemin. La plupart du temps,

les paquets RREQ transmis dans la direction opposée à celle de la destination ne servent pas à

la création d’une route. De même, les paquets RREQ diffusés au-delà de la destination n’ont

pas de réelle utilité dans une grande majorité des cas.

– Maintenance des routes : le protocole de routage doit prendre en compte les changements de

topologie dus aux déplacements des nœuds. Par conséquent, les routes évoluent avec le temps.

Les protocoles de routage de type proactif adaptent les routes vers les autres nœuds du réseau

grâce à l’échange périodique des paquets de contrôle. Cette adaptation au réseau n’a pas de

réel surcoût puisque c’est les mêmes informations de routage utilisées que celles pour la

découverte des chemins. Par contre, il en est tout autrement avec les protocoles de type réactif.

70

Ces protocoles doivent prévenir les nœuds sources, dont les chemins sont rompus, qu’ils

doivent en recréer d’autres si le besoin s’en fait ressentir. Par exemple, le protocole AODV

envoie des paquets RERR en direction de chaque source où la perte d’un chemin a été

détectée. Ces paquets supplémentaires engendrent un coût relativement faible sur la

consommation de bande passante car ce sont des paquets unicast et non diffusés comme lors

de la recherche de chemin.

De nombreux paramètres influent sur la diminution de la bande passante utile. La réduction de

l’impact d’un ou plusieurs de ces paramètres permet d’accroître la bande passante utile et par

conséquent le nombre de paquets de données qui peuvent transiter sur le réseau. Le protocole de

routage est relativement bien adapté à la réalisation de cette tâche car c’est lui qui choisit les chemins

par lesquels vont passer les paquets de données. Nous nous attachons principalement, dans ce chapitre,

à réduire le nombre de collisions dans le réseau, car les collisions jouent un rôle important dans la

diminution de la bande passante utile. Surtout, que les collisions surviennent lorsque la charge du

réseau commence à devenir importante, sachant que c’est à ce moment que le manque en bande

passante utile se fait le plus ressentir. Les collisions amplifient cette diminution de la bande passante

utile dû fait des retransmissions qu’elles engendrent.

4.1.2 Protocole de routage : élément essentiel dans la gestion de la

bande passante

Le protocole de routage est l’élément, de par sa tâche, le mieux disposé à déterminer une route, tout en

ayant comme objectif l’optimisation de la bande passante. Le protocole de routage utilise une ou

plusieurs métriques pour déterminer la qualité d’un chemin à emprunter. La bande passante utile du

réseau étant consommée par de nombreux éléments, le protocole de routage doit faire son maximum

pour essayer d’optimiser celle-ci. Le protocole de routage AODV sur lequel nous allons baser nos

travaux, utilise le nombre de sauts comme métrique. Il ne permet pas de retourner le chemin possédant

le plus faible nombre de nœuds mais un chemin qui s’en rapproche. Les informations qu’il échange

lors de la détermination de la route ont un impact sur la bande passante du réseau. Plus le nombre

d’informations de routage échangées est important, plus la bande passante du réseau est employée

pour la transmission de telles informations. Par conséquent, la bande passante utile dévolue au

transfert de données devient faible. Le protocole de routage doit trouver un juste milieu entre

dissémination d’informations d’état et bande passante consommée.

Les protocoles de routage réactifs, comme AODV, émettent des informations de routage, seulement

lorsque la nécessité de trouver une nouvelle route se fait ressentir, ou lors de la rupture d’un chemin.

Ces informations échangées sont susceptibles de créer des collisions.

Dans ce chapitre, nous allons principalement essayer de diminuer les collisions qui peuvent subvenir

dans le réseau. Pour cela, les protocoles de routage sont bien adaptés pour réaliser cette tâche. En effet,

ils peuvent éviter les chemins déjà surchargés et choisir des chemins où le trafic est plus fluide.

Prendre le chemin le plus court n’est pas toujours la solution idéale. En effet, un nœud d’un tel chemin

peut s’avérer être submergé par le trafic de ses voisins. Accroître le trafic traversant un tel nœud

71

n’engendrerait qu’un surplus de collisions impactant les nœuds voisins ainsi qu’une augmentation

conséquente du temps passé par les paquets en file d’attente. Emprunter des chemins dont le nombre

de collisions est déjà important n’a tendance qu’à accroître le trafic et par conséquent augmenter

encore plus le nombre de collisions. L’idée pour diminuer les collisions et le temps d’attente des

paquets est d’utiliser des chemins moins encombrés. Employer de tels chemins revient à utiliser les

itinéraires « bis » comme dans la vie réelle lorsqu’un bouchon est présent sur une route par exemple.

Nous proposons dans ce chapitre deux protocoles de routage réactifs. Ces deux protocoles s’attachent

à diminuer le nombre de collisions subies par le réseau et ainsi augmenter sa bande passante utilisable

(throughput). Le premier protocole opère directement sur les collisions en tenant compte du taux de

collisions des chemins sélectionnés. Le deuxième protocole essaie d’agir sur les causes des collisions.

Il évite les chemins qui seraient susceptibles d’accroître les collisions subies par le réseau.

4.2 Collisions : causes et conséquences

Dans ce chapitre, nous mettons en évidence les paramètres influant sur le nombre de collisions. Le

protocole de routage doit en tenir compte pour en diminuer ce nombre. Une diminution des collisions

permet d’augmenter la bande passante utile du réseau. Dans un premier point, nous donnerons les

causes des collisions, en calculant la probabilité d’obtenir au moins une collision lors de l’émission

d’un paquet. A partir de cela, nous mettons en avant les différentes causes opérant sur les collisions.

Le deuxième point consiste à donner les conséquences des collisions sur les performances du réseau.

4.2.1 Causes

Les collisions se produisent sur un support partagé lorsque plusieurs émetteurs transmettent leurs

données en même temps. Si ces émetteurs se trouvent à portée radio d’un des récepteurs, ce récepteur

ne peut pas récupérer les données initiales. Une transmission se produit correctement lorsqu’un

récepteur reçoit les données c'est-à-dire qu’elles sont exemptes d’erreurs et de collisions. L’émetteur

sait qu’un paquet a été convenablement reçu, par son destinataire, lors de la réception d’un

acquittement. Lorsque l’émetteur ne reçoit pas d’acquittement dans un temps donné après la

transmission d’une trame, il suppose qu’un problème a eu lieu. L’émetteur doit par conséquent

réémettre la trame. Les collisions ne sont pas les seules causes d’une retransmission. En effet, les

irrégularités du support (apparition d’erreurs lors du transfert d’une trame, perte d’une trame…)

peuvent empêcher le récepteur de transmettre un acquittement. Dans ce chapitre, nous considérons

uniquement les collisions.

Nous distinguons par la suite deux types de nœuds, le nœud émetteur et les nœuds perturbateurs. Un

nœud est dit émetteur s’il transmet une trame à un nœud distant. Les nœuds perturbateurs empêchent

la bonne réception des données par la destination. Les nœuds perturbateurs doivent être dans le

voisinage direct du nœud récepteur (c'est-à-dire à 1 saut) pour qu’il y ait collision. De même, la

72

transmission des trames par le nœud émetteur et les nœuds perturbateurs doivent avoir lieu quasi

simultanément.

Un réseau MANET peut être représenté par un graphe G(V, E) avec V l’ensemble des nœuds du réseau

et E l’ensemble des liens entre ces nœuds. Un nœud X appartient au voisinage d’un nœud Y s’il existe

un lien <X, Y> appartenant à E. L’ensemble des nœuds appartenant au voisinage d’un nœud X est noté

N(X). Considérons A et B deux nœuds appartenant à V. Un paquet transmis par A au nœud B, à un

instant t, subit une collision si un nœud X appartenant à V tel qu’il existe un lien <X, B> appartenant à

E transmet un paquet à un instant compris dans l’intervalle [t-α, t+β] (avec α, β des durées différentes

ou égales). Par conséquent, le nœud perturbateur X peut se situer :

– dans le voisinage de A (et obligatoirement dans celui de B).

– dans le voisinage du nœud B (mais pas dans celui de A).

Par conséquent, il est donc possible de distinguer deux types de nœuds perturbateurs dans l’occurrence

de collision :

1) nœuds dans le voisinage direct de l’émetteur :

Un nœud situé à un saut du nœud émetteur peut créer une collision s’il respecte la propriété 4-1.

Propriété 4-1 : L’ensemble des nœuds voisins à un saut d’un nœud émetteur X pouvant créer

des collisions sur un lien <X, Y> est égal à N(X)∩N(Y). Cet ensemble est noté N1Saut(X, Y).

Démonstration :

Pour qu’un nœud Z situé à un saut d’un nœud émetteur X soit susceptible de commettre une collision

sur un lien <X, Y>, il est nécessaire qu’un paquet émis par le nœud Z soit aussi entendu par le nœud Y.

Par conséquent, le nœud Z doit être situé à un saut du nœud Y, c’est-à-dire qu’il doit faire partie de son

voisinage.

Donc Z appartient à l’ensemble des nœuds communs au voisinage de X et de Y.

�

Les nœuds dans le voisinage direct d’un nœud émetteur possèdent un intervalle de temps relativement

restreint pour créer une collision. En effet, lorsqu’un nœud entend que le support est occupé il retarde

sa transmission jusqu’à que le support devienne à nouveau libre. Par conséquent, l’intervalle de temps,

durant lequel les collisions peuvent apparaître, est fonction du délai de propagation entre ces deux

nœuds. Le délai de propagation entre un nœud X et un nœud Y est noté d(X, Y). La propriété 4-2

énonce l’intervalle de temps de collisions pour les nœuds présents dans le voisinage direct du nœud

émetteur.

73

Propriété 4-2 : Un nœud X émettant son paquet à un instant t0 subit une collision sur un lien

<X, Y> si un nœud Z∈N1Saut(X, Y) transmet un paquet dans l’intervalle de temps

[t0-d(X,Z), t0+d(X,Z)].

Un nœud X peut créer une collision avec un nœud Y transmettant son paquet à un temps t si X transmet

le paquet avant Y et que Y n’a pas encore reçu la trame de X ou que Y transmette son paquet avant X et

que ce dernier n’a pas encore reçu la trame de Y avant de transmettre la sienne. Ces deux cas de figure

sont représentés sur la figure 4-1. Dans cet exemple, une station émettrice X transmet un paquet à

l’instant t0. Une station Y perturbe la transmission de X si Y transmet son paquet dans l’intervalle de

temps [t0-d(X,Y), t0] (figure 4-1 a)) ou [t0, t0+d(X,Y)] (figure 4-1 b)). La fenêtre de collision pour des

nœuds à 1 saut est l’intervalle de temps [t0-d(X,Y), t0+d(X,Y)].

Figure 4-1 : Intervalle de temps durant lequel peut se produire une collision. a) X commence à

transmettre alors que Y a déjà commencé à transmettre. b) Y commence à transmettre alors que X a

déjà commencé à transmettre.

2) nœuds situés à 2 sauts de l’émetteur :

Un nœud situé à deux sauts d’un nœud émetteur peut créer une collision s’il respecte la propriété 4-3.

Propriété 4-3 : L’ensemble des nœuds voisins à deux sauts d’un nœud émetteur X pouvant

créer une collision sur un lien <X, Y> est égal à {Z | ∀Z, Z ∈ N(Y) ∧ Z∉ N(X)}. Cet ensemble

est noté N2Sauts(X, Y).

Démonstration :

Un nœud Z n’appartenant pas au voisinage d’un nœud émetteur X est susceptible de générer des

collisions sur un lien <X, Y> s’il est entendu par le nœud Y c'est-à-dire qu’il fait partie du voisinage de

74

Y.

Par conséquent, Z doit appartenir au voisinage du nœud Y sans appartenir au voisinage du nœud X.

�

Lorsque les nœuds émetteurs sont séparés par un nœud intermédiaire (récepteur pour au moins un des

deux nœuds), ils ne sont pas capables de s’écouter mutuellement s’ils transmettent des données. Ce

phénomène s’appelle le problème des nœuds cachés. Par conséquent, contrairement au cas à un seul

saut, l’intervalle de temps pour l’occurrence d’une collision n’est plus fonction du délai de

propagation. En effet, ces nœuds émetteurs détectent que le support est libre avant de transmettre leur

trame, même si une autre trame est émise. La propriété 4-4 énonce un tel cas de figure.

Propriété 4-4 : Un nœud X émettant un paquet à un instant t0 sur un lien <X, Y> subit une

collision si un nœud Z∈ N2Sauts(X, Y) transmet un paquet dans l’intervalle de temps

[t0- Tpmax, t0+ Tpmax] où Tpmax est le temps maximal de transmission d’un paquet.

Soit deux nœuds X et Y séparés par 2 sauts. Une collision se produit si un nœud X émet un paquet

avant le nœud Y et Y transmet durant la transmission de ce paquet. Le nœud récepteur est par

conséquent incapable de déchiffrer les données réceptionnées. De même, si un nœud X transmet un

paquet après un nœud Y, il y a collision si X débute sa transmission à n’importe quel moment de

l’envoi de la trame émise par Y. Ce cas de figure est représenté sur la figure 4-2.

Figure 4-2 : Intervalle de temps durant lequel une collision est susceptible de se produire dans le cas

de nœuds cachés.

Au final, l’intervalle de temps durant lequel peut se produire une collision diffère suivant que les

nœuds perturbateurs se situent à un saut du nœud émetteur ou qu’ils se situent à deux sauts. Diminuer

le nombre de collisions revient à réduire la probabilité qu’un paquet subisse une collision. Déterminer

une telle probabilité permet de mettre en évidence les paramètres influant sur l’accroissement des

collisions.

Pour déterminer la probabilité pour un paquet de subir au moins une collision, il s’avère nécessaire de

connaître la loi d’arrivée des paquets ainsi que la probabilité qu’une collision soit créée par un voisin

direct et à deux sauts. Pour cela, nous différencions deux cas suivant que l’arrivée entre deux paquets

75

est périodique ou variable. Par la suite, nous supposons que le nœud émetteur X transmet un paquet au

temps t0, qu’un nœud Z (Z∈ N1Sauts(X, Y) ou à Z∈ N2Sauts(X, Y)) n’a pas de paquet en file d’attente et

qu’il a correctement réussi à émettre un paquet au temps tZ, avec tZ < t0. Si le nœud Z n’a jamais émis

de paquet alors tZ = 0. Nous faisons ces hypothèses de départ car nous souhaitons observer les

paramètres agissant sur la probabilité d’avoir une collision indépendamment des collisions précédentes

(dont le temps de transmission entre deux transmissions successives du même paquet est fonction du

temps d’attente backoff). Pour le nœud Z, le calcul du temps séparant l’arrivée d’un paquet à un autre

commence au temps tZ. Donc le nœud Z se base sur un repère temporel décalé de tZ par rapport au

nœud X. Dans un tel cas, l’intervalle de temps de collision est [(t0-tZ)-d(X,Z), (t0-tZ)+d(X,Z)] pour un

voisin à un saut et [(t0-tZ)- Tpmax, (t0-tZ)+ Tpmax] pour un nœud Z situé à deux sauts du nœud émetteur.

1) Trafic périodique :

Nous supposons que l’arrivée entre deux paquets est périodique. Pour un nœud Z, la période entre

deux paquets est notée Tz. Ainsi l’arrivée du kème paquet est donnée par la formule suivante :

tz(k) = k ×Tz

où k∈ IN

La probabilité qu’a un nœud Z situé dans le voisinage direct d’un nœud X de créer une collision sur le

lien <X, Y> est donnée par la propriété 4-5.

Propriété 4-5 : La probabilité P1Saut(Z) qu’un nœud émetteur X ayant transmis un paquet à

l’instant t0 subisse une collision d’un nœud Z∈N1Sauts(X, Y) est la suivante :

( ) ( ) ( ) ( ) ( ) ( )[ ] +−∈+

=sinon 0

, si 1 001

X,Zd-ttX,Zd-ttTtZP ZZzz

Saut .

La probabilité qu’a un nœud Z situé dans le voisinage direct d’un nœud X de créer une collision sur le

lien <X, Y> est donnée par la propriété 4-6.


l’instant t0 subisse une collision d’un nœud Z∈N2Sauts(X, Y) est la suivante :

( ) ( ) ( ) ( )[ ] +−−−∈+

=sinon 0

, si 1 max0max02

TpttTpttTtZP ZZzz

Saut où Tpmax le temps

maximal de transmission d’un paquet.

76

2) Trafic variable :

Nous supposons que l’arrivée entre deux paquets suit une loi exponentielle avec un taux d’arrivée égal

à λ. Une fonction f suivant une loi exponentielle d’arrivée λ est représentée par l’équation suivante :

( )

<≥

=−

0 , 0

0 ,

x

xexf

xλλ (4-1)

Il reste à déterminer la probabilité qu’a un nœud dans le voisinage direct à engendrer une collision

ainsi que la probabilité qu’à un nœud à deux sauts de générer une collision sur un lien <X,Y>. Ces

probabilités sont énoncées par la propriété 4-7 et propriété 4-8.


l’instant t0 subisse une collision d’un nœud Z situé à un saut est la suivante :

( ) ( ) ( ) ( )( )ZXdZXdttSaut eeeZP Z ,,

10 λλλ −−− −⋅= .

Démonstration :

Un nœud Z peut créer une collision avec le nœud émetteur X sur le lien <X, Y> s’il transmet dans

l’intervalle de temps [(t0-tZ)-d(X,Z), (t0-tZ)+d(X,Z)] (propriété 4-2). Par conséquent, la probabilité

d’avoir une collision entre ces deux nœuds dépend du temps de transmission du paquet par le nœud Z.

La probabilité d’avoir une telle collision est le fait d’émettre dans un tel intervalle est la suivante :

( )( ) ( ) ( ) ( )( )

[ ]( ) ( )( ) ( )

( ) ( )

( ) ( )

( ) ( ) ( )( )ZXdZXdtt

ZXdtt

ZXdtt

ZXdtt

ZXdtttt

ZZ

Saut

eee

edte

ZXdtttZXdtttP

ZP

Z

Z

Z

Z

Z

,,

,

,

,

,

00

1

0

0

0

0

0

,,

λλλ

λλλ−−−

+−

−−

+−−−

−−

−

−=

+−≤∧−−≥

= ∫

�


l’instant t0 subisse une collision d’un nœud Z situé à un saut est la suivante :

( ) ( ) ( )maxmax02

TpTpttSaut eeeZP Z λλλ −−− −⋅= avec Tpmax le temps maximal de transmission d’un

paquet.

Démonstration :

Un nœud Z à deux sauts d’un émetteur X peut créer une collision sur le lien <X, Y> s’il transmet dans

l’intervalle de temps [(t0-tZ)- Tpmax, (t0-tZ)+ Tpmax] (propriété 4-4). Par conséquent, la probabilité

77

d’avoir une collision entre ces deux nœuds dépend du temps de transmission du paquet par le nœud Z.

La probabilité d’avoir une telle collision est le fait d’émettre dans un tel intervalle est la suivante :

( )( ) ( )( )

[ ]( )( )

( )

( )

( ) ( )maxmax0

max0

max0

max0

max0

max0max0

2

TpTptt

Tptt

Tptt

Tptt

Tptttt

ZZ

Saut

eee

edte

TptttTptttP

ZP

Z

Z

Z

Z

Z

λλλ

λλλ−−−

+−

−−

+−−−

−−

−

−=

+−≤∧−−≥

= ∫

�

A partir de la propriété 4-5 et propriété 4-6 ou de la propriété 4-7 et propriété 4-8, la probabilité qu’un

paquet subisse au moins une collision peut être calculée. Cette probabilité représente la transmission

d’un paquet par un nœud dans le voisinage direct ou à deux sauts du nœud émetteur. Les chances

qu’un paquet subisse au moins une collision sont données par la propriété suivante :

Propriété 4-9 : La probabilité qu’un paquet émis par un nœud X subisse au moins une collision

sur un lien <X, Y> est égale à ( ) ( )( ) ( )( )( )( )

−⋅−−= ∏ ∏

∈∀ ∈∀YXNi YXNiSautSautC iPiPXP

, ,21

1 2

111

Démonstration :

Pour calculer la probabilité p qu’un paquet subisse au moins une collision lors de sa transmission, il

suffit d’obtenir la probabilité q qu’un paquet ne subisse aucune collision durant sa transmission. En

effet, p=1-q.

Par conséquent, la probabilité qu’un paquet ne subisse aucune collision lors de sa transmission, est

qu’aucun nœud appartenant à N1Saut(X, Y) ne transmette dans l’intervalle de temps [t0-d(X,Z), t0+d(X,Z)]

et qu’aucun nœud appartenant à N2Saut(X, Y) ne transmette dans l’intervalle de temps [t0- Tpmax, t0+

Tpmax]. La probabilité qu’aucun nœud ne transmette dans l’intervalle de temps [(t0-tZ)-d(X,Z), (t0-

tZ)+d(X,Z)] est égale à ( )( )( )

∏∈∀

−YXNi

Saut

Saut

iP,

1

1

1 . De même, la probabilité qu’aucun nœud ne transmette

dans l’intervalle de temps [(t0-tZ)- Tpmax, (t0-tZ)+ Tpmax] est égale à ( )( )( )

∏∈∀

−YXNi

Saut

Saut

iP,

2

2

1 .

La probabilité qu’un paquet ne subisse aucune collision durant sa transmission revient à calculer la

probabilité qu’aucun nœud qu’il soit à un saut ou à deux sauts ne transmette dans l’intervalle de temps

correspondant à la création d’une collision. Donc q= ( )( )( )

( )( )( )

∏∏∈∀∈∀

−⋅−YXNi

SautYXNi

Saut

SautSaut

iPiP,

2,

1

21

11 .

Il reste plus qu’à en déduire PC(X) = p = 1-q = ( )( )( )

( )( )( )

−⋅−− ∏∏

∈∀∈∀ YXNiSaut

YXNiSaut

SautSaut

iPiP,

2,

1

21

111 .

�

78

A partir de la propriété 4-9, il est possible de déduire les différents paramètres influant sur le nombre

de collisions. En effet, plus la probabilité d’obtenir au moins une collision est élevée plus grand est le

nombre de collisions sur le réseau. Les différents paramètres agissant sur la création des collisions

sont :

– le nombre de nœuds voisins (à un saut ou deux sauts)

– le délai de transmission du paquet (fonction de sa longueur et de la capacité du support de

transmission)

– Taux d’arrivée des paquets et espacement entre les paquets (charge du lien)

– le délai de propagation

Dans la suite, nous n’intégrons pas le délai de propagation à cause de son importance négligeable dans

le contexte de nos travaux. Nous nous concentrons par conséquent sur le nombre de nœuds dans le

voisinage du nœud émetteur, le délai de transmission du paquet et la charge d’un lien.

Lorsqu’un paquet veut aller d’un point source vers un point de destination, il emprunte une route

s’étendant sur plusieurs sauts c'est-à-dire traversant plusieurs liens. Par conséquent suivant la longueur

du chemin emprunté par les paquets, le comportement du réseau peut varier. La longueur du chemin

sera donc le dernier paramètre dont nous tiendrons compte pour diminuer le nombre de collisions dans

un réseau MANET.

4.2.1.1 Nombre de nœuds voisins

Le nombre de nœuds voisins d’un lien joue un rôle important sur la réussite de la transmission. En

effet, lorsque le nombre de nœuds voisins est important la probabilité d’obtenir une collision croît.

Bien entendu, le nombre de nœuds à deux sauts du nœud émetteur est plus dommageable sur la

réussite de transmission du paquet car l’intervalle de temps durant lequel peut se produire une

collision est plus élevé. Le fait que les nœuds voisins interviennent sur la probabilité de collision peut

facilement être démontré à partir de la propriété 4-9. En effet, lorsque le nombre de nœuds à un saut

ou à deux sauts tend vers l’infini, la probabilité d’avoir une collision est logiquement égale à 1.

Démonstration :

D’après la propriété 4-9, PC(X) = ( )( )( )

( )( )( )

−⋅−− ∏∏


YXNiSaut

SautSaut

iPiP,

2,

1

21

111 . A partir de ce résultat,

nous en déduisons l’évolution de la probabilité sur un lien <X, Y> lorsque |N1Saut(X, Y)| → ∞ ou

|N2Saut(X, Y)| → ∞.

Dans le cas où N1Saut(X, Y) →∞ :

79

Comme 0≤P1Saut(i)≤1 alors ( )( )( )

01,

1

1

→−∏∈∀ YXNi

Saut

Saut

iP donc ( )( )( )

( )( )( )

011,

2,

1

21

→

−⋅− ∏∏


YXNiSaut

SautSaut

iPiP

Par conséquent PC(X) = 1.

Dans le cas où N2Saut(X, Y) →∞ :

Comme 0≤P1Saut(i)≤1 alors ( )( )( )

01,

2

2

→−∏∈∀ YXNi

Saut

Saut

iP donc ( )( )( )

( )( )( )

011,

2,

1

21

→

−⋅− ∏∏


YXNiSaut

SautSaut

iPiP

Par conséquent PC(X) = 1.

�

Le protocole de routage doit donc tenir compte du nombre de nœuds voisins des liens lorsqu’il choisit

sa route. Le protocole de routage choisissant le plus court chemin (SP) ou le protocole AODV ne

tiennent pas compte d’un tel critère. Par conséquent, ces protocoles peuvent utiliser un chemin dont les

nœuds d’un lien se situent dans une zone dense étant de ce fait plus sujets aux collisions.

Figure 4-3 : Sélection d’un chemin possédant moins de voisins pour le protocole de routage optimal

comparé au protocole de plus court chemin.

80

Le protocole de routage optimal doit prendre le chemin dont la somme des nœuds voisins est la plus

faible. Le protocole de routage retournant le chemin possédant le moins de sauts (SP) et le protocole

de routage AODV ne tiennent pas compte de ce critère. L’exemple de la figure 4-3 compare les

chemins retournés entre le protocole de routage optimal et le protocole de routage SP. Dans cet

exemple, un réseau de 10 nœuds est utilisé. Un chemin doit être créé entre le nœud S et D en utilisant

deux protocoles différents, le protocole optimal et le protocole SP. Le protocole SP retourne un

chemin de deux sauts <S, C, D>. Ce chemin possède comme nœuds voisins la totalité des nœuds

présents sur le réseau c'est-à-dire 10 nœuds. Le chemin retourné par le protocole optimal possède trois

sauts <S, A, B, D>. Le nombre de voisins de ce chemin s’élève à 7 nœuds (S, A, B, D, E, C et H). Par

conséquent, choisir le chemin le plus court ne permet pas toujours d’avoir le nombre de voisins le plus

faible.

4.2.1.2 Débit de transmission

Le débit de transmission joue aussi un rôle important sur l’apparition de collisions. Dans un réseau

MANET de type IEEE 802.11, plusieurs standards se côtoient. En effet, les standards les plus récents

sont compatibles avec les anciens standards. On considère un nœud X possédant une carte IEEE

802.11g avec un débit théorique de 54Mbps, et un nœud Y possédant une carte compatible seulement

avec le premier standard IEEE 802.11 avec un débit théorique de 2Mbps. Lorsque le nœud X transmet

un paquet sur le lien <X, Y> il doit obligatoirement transmettre ce paquet à un débit de 2Mbps pour

qu’il puisse être correctement compris par Y. Le débit de transmission sur un lien <X, Y> noté C<X, Y>

est calculé avec la formule suivante :

C<X, Y> = min(CX, CY) (4-2)

Figure 4-4 : Temps d’émission d’une trame IEEE 802.11b

Lors de l’émission d’un paquet, la couche MAC IEEE 802.11b ajoute un entête au paquet reçu de 30

octets et un CRC de 4 octets. Ensuite, la couche physique ajoute à son tour un entête de 192µs ou 96µs

à la trame qu’il reçoit de la couche MAC. La figure 4-4 montre ces différents temps. Le temps

d’émission d’une trame est fonction de sa taille et du débit de transmission du lien sur lequel il est

transmis. En supposant deux nœuds X et Y avec un débit de transmission respectif CX, CY, on peut

déduire à partir de la formule (4-2) le temps de transmission d’un paquet de taille S (noté tS) sur le lien

<X, Y> avec la formule suivante :

><

++=YX

E C

SSt

,

34192)( (4-3)

81

A partir de l’équation (4-3), on peut déterminer le temps d’émission pour un paquet S de taille 1500

octets suivant différents débits de transmission sur le lien. Le tableau suivant donne ces temps.

Le Tableau 1 montre que le temps d’émission d’un paquet se dégrade rapidement avec la diminution

du débit de transmission. Emprunter un lien ayant un débit de transmission faible va empêcher durant

un laps de temps important les autres stations dans le voisinage direct du nœud émetteur de transmettre

un quelconque paquet. Si ces nœuds ont un débit de transmission bien plus élevé, la bande passante

disponible du réseau en pâtira car une grande partie de la bande passante ne sera utilisée que pour

émettre un paquet.

Le temps d’émission d’un paquet influe aussi sur les collisions. En effet, l’intervalle de temps où peut

se produire une collision est plus important pour les nœuds situés à deux sauts du nœud émetteur

(propriété 4-9).

Débit de transmission Temps d’émission du paquet

11 Mbps 1,307 ms

5.5 Mbps 2,423 ms

2 Mbps 6,328 ms

1 Mbps 12,464 ms

Tableau 4-1 : Temps d’émission d’un paquet de 1500 octets en fonction de différents débits de

transmission.

Le protocole de routage optimal doit ainsi privilégier les liens possédant un débit de transmission

élevé. Choisir de telles routes permet une augmentation de la bande passante utile du réseau et une

diminution de la probabilité de subir une collision lors de l’émission d’un paquet.

4.2.1.3 Charge d’un lien

La charge d’un lien impacte aussi le nombre de collisions. De fait, les collisions apparaissent plus

fréquemment sur un lien surchargé (propriété 4-9). Pour étudier l’effet de la charge d’un lien sur la

création des collisions, nous avons réalisé des simulations à l’aide du simulateur NS-2. Pour cela, nous

avons simulé un réseau composé de 4 nœuds qui sont tous interconnectés entre eux. Trois des nœuds

envoient la même quantité d’informations sur le quatrième nœud. Les nœuds ne bougent pas, car le but

de ces simulations est de voir l’effet de la charge d’un lien sur les collisions dans le pire des cas. Les

nœuds se trouvant tous à portée radio, le problème des nœuds cachés ne se pose pas ici. Chaque nœud

émetteur utilise un trafic de type CBR dont la taille des paquets est égale à 512 octets. La durée des

simulations est de 2000 secondes.

82

Figure 4-5 : Charge transmise en fonction de la charge soumise sur le médium pour des nœuds ayant

un débit de transmission égal à 1 Mbps ou à 2 Mbps.

Les simulations ont été réalisées en utilisant deux débits de transmission différents. Dans le premier

cas, le débit de transmission est de 1 Mbps et dans le second, il s’élève à 2 Mbps. Utiliser différents

débits de transmission permet de valider les résultats quelque soit le type de standard IEEE utilisé. Le

débit total du réseau représente la somme des débits d’émission de paquets de chaque nœud.

Nous étudions différents paramètres (le nombre de paquets émis, le nombre de collisions subies, le

nombre de paquets supprimés) en fonction du débit total transmis sur le réseau. La figure 4-5 compare

la charge transmise en fonction de la charge soumise sur le réseau.

Avec un débit de transmission de 1 Mbps, la bande passante émise croît linéairement jusqu’à une

charge atteignant 750 Kbps. Le fait que la pente croit plus vite entre 150 Kbps et 300 Kbps est dû au

fait qu’on double la charge alors que la même échelle est conservée. Par contre, à partir de 750 Kbps,

le nombre de paquets émis stagne. Le réseau a atteint sa charge maximale, il ne peut transmettre plus

de paquets. En effet, l’obtention du support est de plus en plus difficile à acquérir puisque chaque

nœud émetteur essaie d’y accéder en même temps, ou voit son émission retardée du fait que le support

soit déjà occupé. La bande passante émise ne diminue pas lorsque la charge maximale du réseau est

atteinte car le nombre de nœuds en contention est trop faible. Ainsi dans un tel réseau, le temps de

backoff joue correctement son rôle car chaque nœud attend un temps aléatoire différent des autres.

Avec un débit de transmission de 2 Mbps, la bande passante émise croît linéairement jusqu’à atteindre

une charge de 1200 Kbps. A partir de cette charge, le réseau a atteint sa capacité maximale

d’acceptation des paquets. Comparé au débit de transmission à 1 Mbps qui atteint sa capacité

maximale à 75% du débit de transmission, le réseau atteint ici sa capacité maximale à 60% du débit de

transmission. La diminution de la capacité maximale peut s’expliquer du fait qu’à 2 Mbps, les nœuds

envoient toujours l’entête de la couche physique (PLCP Preamble et PLCP Header) à 1 Mbps

réduisant légèrement l’efficacité du réseau. En accroissant le débit de transmission des nœuds, ce

phénomène est encore plus marqué.

0

200

400

600

800

1000

1200

1400

1600

30 60 90 120 150 300 450 600 750 900 1150 1200 1350 1500 1650

Ch

arg

e tr

ansm

ise

(Kb

ps)

83

Figure 4-6 : Nombre de collisions subies par le réseau en fonction du débit total des nœuds avec un

débit de transmission égal à 1 Mbps ou 2 Mbps.

La figure 4-6 représente l’évolution du nombre de collisions sur le réseau en fonction du débit total

supporté. Dans un premier temps, nous étudions les résultats pour un débit de transmission de 1 Mbps.

Lorsque la charge est faible, le nombre de collisions subies par le réseau est proche de 0. Chaque nœud

peut accéder à son tour facilement au support, outre les quelques transmissions se produisant en même

temps créant quelques collisions. A partir de 600 Kbps, le nombre de collisions commence à croître à

cause de la charge du réseau. A partir de 750 Kbps, le réseau s’effondre d’un coup. Il a atteint sa

capacité maximale entrainant de ce fait un nombre important de collisions. Au-delà de 750 Kbps, le

nombre de collisions reste inchangé puisque le nombre transmis de paquet reste identique (figure 4-5).

Pour un débit de transmission de 2 Mbps, les mêmes constats peuvent être faits. A faible charge, les

collisions sont quasiment inexistantes, alors qu’elles atteignent un seuil lorsque la charge du réseau est

maximale.

Le dernier schéma (figure 4-7) reflète l’état du réseau suivant le nombre de paquets supprimés. La

suppression des paquets intervient lorsque la file d’attente contenant les paquets de la couche réseau

est pleine. Lorsqu’un nœud ne peut pas accéder au support, la taille de la file de ses paquets en attente

croît. La file utilisée lors de ces simulations est une file FIFO, c’est-à-dire que le premier arrivé est le

premier sorti. Pour chaque nœud, la taille de la file d’attente est de 50 paquets. Lorsque cette file

d’attente déborde, les derniers paquets arrivés sont supprimés. Dans un premier temps, les résultats

sont interprétés pour un débit de transmission de 1 Mbps. Jusqu’à 600 Kbps, la file d’attente reste vide.

Le réseau peut supporter la charge qu’il reçoit et la longueur de la file d’attente suffit pour contenir les

paquets pendant que le support est occupé. Par contre à partir de 750 Kbps, la file d’attente ne peut

plus contenir le trafic émis par le nœud. Dans un tel cas, les paquets sont supprimés puisque le support

est difficilement accessible et le nombre de collisions élevés entrainant d’importantes retransmissions.

Les retransmissions diminuent la bande passante utile du réseau. Au-delà de 750 Kbps, le réseau étant

saturé le nombre de paquets supprimés est plus important puisqu’il arrive à chaque nœud un nombre

plus important de paquets à émettre. Les mêmes interprétations peuvent être faites pour un débit de

0

2

4

6

8

10

12

14

30 60 90 120 150 300 450 600 750 900 1150 1200 1350 1500 1650

1 Mbps

2 Mbps

Débit (Kbps)

84

transmission de 2 Mbps. Les paquets commencent à être supprimés à partir de 1,2 Mbps (lorsque la

charge du réseau est maximale).

Figure 4-7 : Nombre de paquets supprimés en fonction du débit total des nœuds avec un débit de

transmission égal à 1 Mbps ou 2 Mbps

Comme le réseau ne peut accepter un plus grand nombre de paquets transmis, les paquets supprimés

ne cessent de croître avec l’augmentation du débit des flux.

Ces simulations ont confirmé les résultats obtenus en calculant la probabilité d’obtenir une collision.

En effet, lorsque la charge d’un lien croît, les collisions sur le voisinage deviennent problématiques.

Les simulations ont montré que l’apparition des collisions débute à partir d’un certain seuil. Pour un

réseau à 1Mbps (respectivement 2Mbps), ce seuil est atteint pour une charge de 750Kbps

(respectivement 1,2Mbps). A partir de 60% du débit de transmission d’un lien, les collisions

deviennent trop importantes. Emprunter de tels liens ne fait qu’augmenter le nombre de paquets

supprimés en file d’attente. Le protocole de routage doit donc éviter à tout prix les liens qui sont

proches de la saturation.

4.2.1.4 Influence de la longueur d’un chemin

Dans certains cas, prendre le chemin le plus court peut revenir au même que sélectionner le chemin

ayant le plus faible nombre de voisins. En effet, lorsque les nœuds sont uniformément distribués dans

le réseau, chaque nœud possède quasiment le même nombre moyen de nœuds dans son voisinage.

Pour déterminer le nombre de nœuds moyens dans son voisinage direct, il faut au préalable calculer la

probabilité qu’un nœud se situe dans la zone de couverture d’un autre nœud. Pour cela, on suppose

que les nœuds sont uniformément répartis dans une zone dont la surface est notée AG. La probabilité

qu’un nœud x se situe dans la zone de couverture de rayon R d’un nœud i (noté Ai) est donnée par la

formule suivante :

0

200

400

600

800

1000

1200

30 60 90 120 150 300 450 600 750 900 1150 1200 1350 1500 1650

Paq

uet

s su

ppri

més

(K

bp

s)

85

( )G

i

G

Gii A

A

A

AAAxP =∩=∈ (4-4)

où Ai ⊂ AG

En connaissant la probabilité qu’un nœud soit dans la zone de couverture d’un nœud i, le nombre

moyen de nœuds dans le voisinage de i peut être calculé. Pour un réseau composé de N nœuds, on peut

déduire de l’équation (4-4) que le nombre moyen de nœuds N(i) dans Ai. N(i) est calculé grâce à la

formule suivante :

N(i) = N⋅P(x∈Ai) (4-5)

Par conséquent d’après la formule (4-5), si on suppose que tous les nœuds sont identiques c'est-à-dire

qu’ils possèdent le même rayon R et que le nœud n’est pas situé en bordure de zone, alors le nombre

moyen de nœuds dans son voisinage est le même.

Lorsque les nœuds sont uniformément répartis dans la zone où ils se situent, le protocole de routage

optimal peut choisir le plus court chemin plutôt que le chemin possédant le plus faible nombre de

voisins. Souvent pour déterminer le nombre de voisins, il est nécessaire d’utiliser des informations de

gestion du voisinage diminuant de ce fait la bande passante utile du réseau. Dans de telles

circonstances, une telle solution est donc à privilégier.

4.2.2 Conséquences

Les collisions ont de fâcheuses conséquences sur le bon comportement d’un réseau MANET. Elles

réduisent la bande passante disponible du réseau. Comme une collision entraine la retransmission de la

trame, jusqu’à un certain seuil, elle entraine donc une diminution de la bande passante disponible ainsi

qu’une augmentation du délai d’attente des paquets suivants. En effet, les paquets en file d’attente

doivent patienter un certain laps de temps avant que leur tour n’arrive. Les collisions augmentent donc

ce laps de temps.

Le temps pour transmettre correctement un paquet de données tTC est fonction de nombreux facteurs.

En premier lieu, ce temps doit tenir compte du temps de transmission du paquet. Le temps de

transmission tS est le temps mis pour transmettre l’ensemble des bits du paquet. Ce temps est fonction

de la capacité du canal. De même, ce temps doit prendre en compte le temps d’évitement de collision

tCA (tel que par exemple DIFS pour écouter que le support est libre), ainsi que le temps de détection de

non réception d’un acquittement tCD. Une collision est détectée lorsque le nœud émetteur ne reçoit pas

d’acquittement, ainsi il doit attendre un certain laps de temps après la transmission de la totalité de la

trame pour recevoir l’acquittement (SIFS + temps de propagation). S’il n’est pas reçu dans un tel laps

de temps c’est qu’une collision est survenue. Enfin, il doit tenir compte du temps ajouté par le surcoût

toverhead entrainé par l’utilisation des paquets RTS/CTS s’ils sont utilisés ainsi que du backoff TB qui est

un surcoût de temps entre deux retransmissions consécutives. Le temps pour transmettre correctement

un paquet peut donc être donné par la formule suivante, en supposant qu’il nécessite R transmissions

[KAZ 02-1] :

86

( ) ( ) ∑=

+⋅+++=R

rroverheadCDCASTC TBRttttpt

1

(4-6)

Il est possible à partir de l’équation (4-6) d’obtenir la bande passante nécessaire à la transmission

correcte d’un paquet de données de taille S. Cette bande passante est représentée par la formule

suivante :

( ) ( )pt

SpnteBandePassa

TC

= (4-7)

La formule (4-7) montre que les collisions jouent un rôle important dans la consommation de bande

passante d’un réseau MANET. Il est par conséquent important de diminuer un tel nombre lorsque la

charge du réseau s’avère raisonnable pour accroître la bande passante disponible et diminuer le temps

passé en file d’attente par un paquet.

Un paquet en file d’attente doit attendre la transmission de la totalité des paquets qui sont avant lui

avant de pouvoir être transmis. En supposant une file d’attente maximale de q paquets, le temps

d’attente maximal d’un paquet est représenté par la formule suivante :

( ) ( )∑ ∑= =

+⋅+++=q

i

R

rrioverheadCDCAS

i

TBRttttpD1 1

(4-8)

où Ri est le nombre de transmission du ième paquet.

L’équation (4-8) montre bien l’impact que peuvent avoir les collisions sur le délai passé en file

d’attente par un paquet lors de la réception d’une rafale. Le délai en attente d’un paquet varie

énormément entre un support subissant peu de collisions et un support très collisionné.

4.3 Protocole de routage

Dans cette section, nous proposons un protocole de routage [ESP 06-1] dans le but d’améliorer la

bande passante d’un réseau MANET. Un flux de données est formé par les paquets possédant le même

couple (source, destination). Quand un flux traverse un chemin P, il interagit avec les flux dans le

proche voisinage des nœuds qui composent P (cf. §4.2.1.1). Offrir une bande passante plus élevée aux

différents flux traversant le réseau permet un meilleur fonctionnement d’application « gourmande » en

bande passante, ou permet d’accepter plus de flux.

Pour accroître la bande passante, notre protocole de routage améliore la bande passante saturée du

réseau [WAN 02-1]. La bande passante saturée BS est la bande passante minimale sur un lien quand

tous les flux traversant ce lien ont la même bande passante. Elle est représentée sur un graphe G(V, E)

par la fonction suivante :

=>∈<∀ +

+i

ii

isii N

bBE 1,

1 min ,v,v (4-9)

87

où bi,i+1 la capacité du lien <vi, vi+1> et Ni le nombre de flux traversant ce lien.

Un protocole de routage doit maximiser cette bande passante pour être vraiment efficace. La bande

passante saturée est maximisée si le protocole de routage retourne la bande passante saturée la plus

élevée, notée Bmax. Bmax peut être obtenue à partir de la formule suivante :

( )nRs

Rs BBB ,...,max 1

max = avec R1,…,Rn l’ensemble des protocoles de routage dépourvus de boucle pour

un réseau donné, et kRsB est la bande passante saturée retournée par le protocole Rk..

Par conséquent, le protocole Ri qui retourne Bmax est appelé protocole optimal [WAN 02-1]. La

complexité pour trouver le protocole qui maximise la bande passante saturée est NP-difficile

[KLE 99-1]. Ce problème est appelé le problème Optimal de la classe de trafic Premium pour un

protocole de Routage (OPR). Dans les réseaux MANETs, les collisions peuvent interagir avec les

paquets transmis et la capacité d’un lien est fonction du débit de transmission des nœuds du lien

(cf. §4.2.1.2). Par conséquent nous modifions la définition de la bande passante saturée de telle

manière que les collisions soient prises en compte. La bande passante saturée est dorénavant

représentée avec la formule suivante :

( )

−=∈∀ >+<

+i

cii

isii N

BCBVvv 1,

1 min ,, (4-10)

où C<i, i+1> le débit de transmission du lien <i, i+1>, Ni le nombre de flux traversant le lien <i, i+1> et

Bc la bande passante consommée par les collisions.

Nous proposons un protocole de routage basé sur AODV. Durant la phase de découverte des routes,

notre protocole de routage sélectionne un chemin à partir d’une fonction poids. Cette fonction poids a

la particularité de diminuer le nombre de collisions. De fait, notre protocole augmente la bande

passante du réseau. Nous proposons deux fonctions poids permettant d’agir sur les facteurs générant

des collisions. La première fonction poids se base sur la bande passante collisionnée subie par un

nœud pour sélectionner les chemins. La deuxième fonction poids se base sur de nombreux facteurs

pour réduire la bande passante consommée par les collisions.

4.3.1 Fonction poids numéro 1

La fonction poids numéro 1 permet de réduire la bande passante consommée par les collisions. Elle

utilise différentes métriques pour réaliser cet objectif. Cette fonction poids combine l’ensemble de ces

métriques pour sélectionner un chemin. La fonction poids obtenue est non-linéaire.

4.3.1.1 Métriques utilisées

Notre protocole utilise une fonction poids pour déterminer la qualité des chemins. Cette fonction

utilise trois sortes de métriques : le débit de transmission, la bande passante ayant subi des collisions et

88

le nombre de nœuds. Ces trois métriques sont connues sans nécessiter l’échange d’informations de

contrôle sur la gestion des voisins. Ces métriques sont calculées comme suit :

– Débit de transmission ou capacité d’un lien : la capacité d’un lien est donnée par l’équation (4-2)

(cf. §4.2.1.2).

– Bande passante consommée par les collisions : dans le standard IEEE 802.11, les nœuds détectent

une collision si un acquittement n’est pas reçu après la transmission d’un paquet de données. Nous

utilisons cette méthode pour calculer la bande passante ayant subi des collisions. Quand un paquet est

envoyé, l’acquittement doit être reçu dans une durée tCD = 2tp + tSIFS + tACK secondes, où tp est le temps

de propagation entre les deux nœuds, tSIFS le temps inter-trame le plus faible et tACK le temps pour

transmettre l’acquittement. Par conséquent, un nœud émetteur détecte la présence d’une collision s’il

ne reçoit pas d’acquittement au bout de tCD unités de temps. Les paquets de contrôle subissant des

collisions (RREQ, RREP, …) ne sont pas comptabilisés puisque ce type de paquets est diffusé et le

nœud émetteur n’attend pas d’acquittement.

D’après la formule (4-7) (cf. §4.2.2), on peut déduire la bande passante ayant subi des collisions pour

chaque paquet k de la façon suivante :

( ) ( ) ( )

=

>+−×+++= ∑

−

=

1 si 0

1 si

1 1

1

k

kR

rrkoverheadCDCAS

k

coll

R

R

TBRtttt

S

kBandwidthk

k (4-11)

où Sk est la taille du paquet k et Rk le nombre de retransmission.

Par conséquent, si un nœud vi transmet m paquets par seconde, la bande passante ayant subi des

collisions pour ce nœud est calculée avec la formule suivante :

( )∑=

=m

kcollcoll kBandwidthBandwidth

1

(4-12)

– Nombre de nœuds : cette métrique est largement employée par le protocole de routage AODV. Elle

représente le nombre de nœuds d’un chemin. Pour un chemin P=(v1, … ,vn), le nombre de nœud est

nombre_nœud =−= 1P n-1.

4.3.1.2 Fonction poids utilisée

La fonction poids utilisée est fonction de différents paramètres vus au chapitre §4.2.1 pour diminuer le

nombre de collisions et augmenter la bande passante saturée du réseau.

Dans un premier temps, notre fonction poids tient compte de la capacité du lien. Emprunter un lien de

capacité plus importante permet de réduire le nombre de collisions et surtout permet de transmettre

plus de paquets dans la même unité de temps que pour un lien de capacité plus faible. Dans [MA 97-1],

89

les auteurs utilisent une fonction, qui appliquée à l’algorithme de Dijkstra, donne le chemin possédant

la bande passante la plus élevée. Pour un chemin P=(v1, …, vn), cette fonction est la suivante :

( ) ∑−

= +=

1

1 1,

1w

n

i iibP (4-13)

où bi,i+1 la capacité nominale du lien (vi, vi+1).

Cette fonction permet de déterminer le chemin avec la plus grande capacité. Cette fonction poids est

un premier pas pour agir sur les collisions (cf. §4.2.1.2). Mais elle n’est pas suffisante.

Notre fonction poids doit aussi prendre en compte le nombre de nœuds du chemin (cf. §4.2.1.4). Notre

fonction poids pénalise linéairement les chemins en fonction de leur longueur. La fonction poids de la

formule (4-13) est modifiée, en conséquence, pour prendre en compte ce critère :

( ) ∑−

= +=

1

1 1, w

n

i iib

iP (4-14)

Réduire la longueur du chemin a un impact sur le nombre de collisions. La charge du lien est aussi un

élément important dont il faut tenir compte (cf. §4.2.1.3). Le nombre de paquets subissant des

collisions augmentent, à partir d’un certain seuil, exponentiellement avec l’augmentation de la charge

du réseau. Par conséquent, un flux traversant un chemin saturé (c'est-à-dire possédant un nombre

important de collisions) voit ses paquets émis collisionnés ou supprimés à cause d’une file d’attente

des paquets pleine. Sur un chemin, le nœud qui a subi le plus de collisions, c'est-à-dire qui a la bande

passante ayant subie des collisions la plus importante, est le nœud qui limite le bon fonctionnement du

chemin.

Pour un chemin P, le rapport entre la bande passante ayant subi des collisions et la capacité du lien est

noté PBc et calculé avec la formule suivante :

∀Ρ=(v1,…,vn),

=

− nn

ncc

c b

b

b

bPB

,12,1

2

,,max K (4-15)

où icb désigne la bande passante ayant subi des collisions du nœud vi et bi,i+1 la capacité du lien

<vi, vi+1>.

Le calcul de PBc en l’état actuel ne peut pas pénaliser directement le chemin. En fait, une fonction

exponentielle f(PBc) doit pénaliser la fonction poids et f(PBc)∈[1,∞[. f(PBc)=1 quand le chemin n’a

subi aucune collision (aucune pénalisation n’est apportée par les collisions) et ( ) ∞→cPBf quand le

chemin traverse un nœud dont la bande passante ayant subi des collisions est égale à la capacité du

lien. La fonction suivante correspond à ces critères et est donc appropriée :

90

∀Ρ=(v1,…,vn), ( )c

c PBPBf

−=

1

1 (4-16)

Ainsi, la fonction poids de l’équation (4-14) peut être modifiée de telle façon qu’elle pénalise

exponentiellement le nombre de collisions subies par un nœud. Pour un chemin P=(v1,…,vn), la

fonction poids utilisée est la suivante :

( )

−

=

−

−

= +∑

nn

ncc

n

i ii

b

b

b

b

b

i

P

,12,1

2

1

1 1,

,,max1

w

K

(4-17)

A partir d’une telle fonction, le protocole de routage est capable de déterminer une route dont la

présence d’un nouveau flux a peu d’impact sur le nombre de collisions (tant que la charge du réseau

est raisonnable).

Initialement, rien ne laissait envisager que l’utilisation d’une telle fonction poids soit moins

performante que le protocole AODV lui-même. Les simulations réalisées (cf. §4.3.5) ont mis en

évidence qu’une pénalisation exponentielle de la bande passante ayant subi des collisions est bien

souvent inefficace. En effet, la bande passante ayant subi des collisions est un mauvais indicateur de la

charge d’un lien. En outre, lorsque des collisions apparaissent le lien est déjà en surcharge. De fait, la

bande passante ayant subi des collisions commence à croître alors que la charge du lien est déjà

importante. Devant un tel problème, nous avons mis en place une seconde fonction poids prenant en

compte les facteurs causant des collisions (cf. §4.2.1).

4.3.2 Fonction poids numéro 2

La fonction poids numéro 2 permet, aussi, de réduire la bande passante consommée par les collisions.

Elle agit sur les différents facteurs causant des collisions (cf. §4.2.1). Différentes métriques sont

utilisées pour représenter ces facteurs. Cette fonction poids est non-linéaire.

4.3.2.1 Métriques

La fonction poids numéro 2 utilise trois métriques pour sélectionner un chemin. Ces trois métriques

sont : la bande passante disponible, la capacité d’un lien et le nombre de nœuds voisins. La bande

passante disponible peut être obtenue à partir d’un modèle d’estimation non-intrusif, de même que la

capacité d’un lien. Par contre pour qu’un nœud détermine ses voisins, un modèle intrusif doit être

utilisé pour être suffisamment représentatif à tout instant. Ces métriques sont calculées comme suit :

– Bande passante disponible : la bande passante disponible est obtenue à partir de la méthode

d’estimation de Kazantsidis et al [KAZ 02-1]. Cette méthode fournit à la couche réseau la bande

passante disponible à partir de mesures de la couche MAC et LLC. La bande passante disponible est

91

obtenue à partir du taux d’utilisation de la file d’attente employée par la couche LLC. Le temps durant

lequel la file d’attente est vide représente le temps de non-utilisation du support. La bande passante

disponible sur un lien <i, i+1> est notée bdi, i+1.

– Capacité d’un lien : la capacité d’un lien est obtenue à partir de l’équation (4-2) (cf. §4.2.1.2). La

capacité d’un lien <i, i+1> est notée C<i, i+1>.

– Nombre de nœuds voisins : chaque nœud du réseau détermine le nombre de nœuds situés dans son

voisinage en échangeant périodiquement des paquets HELLO. Chaque nœud maintient une table des

nœuds voisins. A la réception d’un paquet HELLO émis par X, un nœud ajoute dans sa table des

nœuds voisins l’identifiant de X. Si un nœud ne reçoit plus de paquet HELLO d’un de ses voisins

durant un certain laps de temps, le lien est rompu et la table des nœuds voisins est mise à jour. Le

nombre de nœuds voisins d’un nœud i est noté N1(i).

4.3.2.2 Fonction poids utilisée

La fonction poids utilisée agit sur les différents facteurs provoquants des collisions. L’objectif de cette

fonction poids est d’accroître la bande passante du réseau.

Dans un premier temps, la fonction poids numéro 2 détermine la charge d’un chemin. La charge d’un

chemin est obtenue grâce à la bande passante disponible sur chaque lien d’un chemin. Plus la bande

passante disponible d’un lien est proche de 0, plus la charge du lien est importante. Un lien avec la

bande passante disponible la plus faible d’un chemin est le lien bloquant.

La charge d’un lien joue un rôle important dans l’occurrence d’une collision (cf. §4.2.1.3). De fait, la

fonction poids doit sélectionner le chemin avec la bande passante disponible la plus élevée. La

fonction poids suivante permet de retourner le chemin avec la bande passante disponible la plus

élevée :

( ) ∑−

= +

=1

1 1

1n

i i,ibdPw (4-18)

Lorsque la charge d’un lien atteint un certain seuil, le lien est tellement surchargé que les nœuds

génèrent de nombreuses collisions (cf. §4.2.1.3). Tout lien dont la charge dépasse ce seuil doit être

évité. La fonction poids de la formule (4-18) est modifiée pour tenir compte de ce critère :

( )

∞

∆>>+<∀= +

−

= +∑

sinon

,1, si 1

1,

1

1 1ii

n

i i,i

bdiibdPw (4-19)

où ∆ est le seuil de charge qu’un lien du chemin ne doit pas dépasser.

La capacité d’un lien joue un rôle particulièrement important dans le temps d’occupation du support

pour la transmission d’un paquet de données. Il est important de privilégier les liens avec un débit de

transmission élevé. La bande passante disponible d’un lien est pénalisée en fonction de sa capacité. Le

92

facteur pénalisant d’un lien <i, i+1>, noté αi, i+1, est fonction du débit de transmission avec

αi, i+1(54Mbps) > αi, i+1(11Mbps) > αi, i+1(5,5Mbps) > αi, i+1(2Mbps) > αi, i+1(1Mbps). La fonction poids

de la formule (4-19) est modifiée pour prendre en compte ce facteur :

( )

∞

∆>>+<∀×= +

−

= ++∑

sinon

,1, si 1

1,

1

1 11,ii

n

i i,iii

bdiibdPf α (4-20)

Le dernier facteur pris en compte par la fonction poids numéro 2 est le nombre de nœuds voisins. La

fonction poids est pénalisée en fonction du cumul du nombre de nœuds voisins de chaque nœud

composant le chemin. La fonction poids numéro 2 utilisée par notre protocole de routage est la

suivante :

( ) ( ) ( ) ( )

∞

∆>>+<∀×

×=×= +

−

= ++==∑∑∑

sinon

,1, si 1

1,

1

1 11,11

11 ii

n

i i,iii

n

i

n

i

bdiibd

iNPfiNPw α (4-21)

Cette fonction poids tient compte des différents facteurs causant des collisions. Le protocole de

routage utilise cette fonction poids pour sélectionner un chemin lors de la phase de découverte des

routes.

4.3.3 Phase de découverte de route

La phase de découverte de route consiste à trouver un chemin entre un nœud source et un nœud

destination. Pour cela, le nœud source émet une requête de création de route, RREQ, et attend la

réception d’une requête de confirmation, RREP. Notre protocole de routage est basé sur le protocole

AODV, dans la façon dont il dissémine l’information de routage et du fait qu’il utilise les mêmes

tables (table des chemins inverses et table de routage) que le protocole AODV. Notre protocole se

distingue du protocole AODV par les informations contenues dans les requêtes RREQ et RREP ainsi

que les champs composant les entrées des tables.

Pour un sous-chemin P=(v1,…,vn), une requête RREQ émise par le nœud vn dans notre protocole

contient les champs suivants :

– Adresse source

– Adresse de destination

– Numéro de séquence source (noté nss)

– Capacité de vn

– PBc (cf. équation (4-15)) si fonction poids numéro 1 ou f(P) (cf. équation (4-20)) si fonction

poids numéro 2

93

– Nombre de sauts si fonction poids numéro 1 sinon nombre de voisins des nœuds du chemin

A la réception d’une requête RREQ, le nœud source conserve dans la table inverse des chemins le

couple (adresse source, adresse destination), le numéro de séquence source et le poids le plus faible.

Une requête RREP qui est transmise par un nœud X contient les paramètres suivants :

– Adresse source

– Adresse de destination

– nss

– poids

– Capacité de X

Quand un nœud Y reçoit une requête RREP (transmise par un nœud X), il met à jour sa table de

routage avec le couple d’adresses, le nss, et le débit de transmission B (cf. équation (4-2)). Les paquets

de données reçus par Y dont le prochain nœud est X sont transmis à une vitesse B.

La phase de découverte des routes nécessite l’utilisation de trois algorithmes suivant la position des

nœuds sur le chemin (nœud source, nœud intermédiaire et nœud destination).

4.3.3.1 Algorithme du nœud source

La figure 4-8 donne l’organigramme utilisé par le nœud source pour la découverte d’une route. S’il ne

possède pas déjà une route, il transmet une requête RREQ après avoir initialisé ses champs. Pour cela,

si la fonction poids numéro 1 est utilisée, le nombre de sauts est initialisé à 1 et PBc est initialisé à 0. Si

la fonction poids numéro 2 est utilisée, le nombre de voisins est initialisé au nombre de voisins de la

source, et f(P) est initialisé à 0. Dans les deux cas, le nœud source ajoute sa capacité de transmission.

Il déclenche un temporisateur Trep et attend une réponse RREP lui confirmant qu’une route est

trouvée. Si Trep arrive à échéance, aucune route n’a été trouvée. Dans ce cas, il refait sa tentative

Nrpmax fois au maximum. S’il reçoit une réponse RREP, il commence à envoyer les paquets en attente

sur ce chemin. Le nœud source peut recevoir plusieurs réponses RREP. Dans un tel cas, il sélectionne

toujours le chemin ayant le plus faible poids.

94

Figure 4-8 : Organigramme exécuté par un nœud source

4.3.3.2 Algorithme du nœud intermédiaire

L’algorithme exécuté par un nœud intermédiaire est formalisé par l’organigramme de la figure 4-9. A

la réception d’une requête RREQ, le nœud intermédiaire vérifie si la route inverse (route en direction

de la source) est plus récente ou de même âge mais avec un poids plus faible. Dans ces deux cas, le

nœud met à jour sa table des chemins inverses et propage la requête RREQ après avoir mis à jour ses

champs.

A la réception d’une réponse RREP, le nœud met à jour sa table de routage (en y ajoutant la route si

nécessaire) si le poids de la route est plus faible ou la route est plus récente. Il consulte sa table des

chemins inverses pour obtenir le nœud à qui propager la réponse RREP et la propage. Dans le cas où

la route est obsolète, la requête est supprimée.

Traitement des données

DEBUT

- Créer un RREQ

- Générer un nouveau

numéro de séquence

- Mettre à jour les champs

de la requête

- Diffuser RREQ

- Armer le temporisateur

Trep

RREP reçu?- Arrêter Trep

- Envoyer les

données

oui

non

Trep expiré?

nonoui

Nrp++

Nrp Nrpmax?oui

non

Informer la couche supérieure

Phase de

traitement des

données

Transmission des

données

RERR reçu?

une route?

oui non

oui non

95


partie différente de notre protocole comparé au protocole AODV.

4.3.3.3 Algorithme du nœud de destination


différente de notre protocole comparé au protocole AODV.

96

L’algorithme employé par la destination est présenté par la figure 4-10. A la réception d’une requête

RREQ, la destination vérifie que la route obtenue est plus récente ou possède un poids plus faible.

Dans ces deux cas, la destination met à jour sa table des chemins inverses et envoie une réponse RREP

en direction de la source. Si la requête RREQ est obsolète, elle est supprimée.

4.3.4 Maintenance des routes

La phase de maintenance des routes est identique à celle utilisée par le protocole AODV. Lorsqu’un

nœud détecte la rupture d’un lien, il émet en direction des sources (dont le trafic le traverse) un paquet

de notification de la rupture RERR. A la réception de ce paquet, un nœud intermédiaire supprime de sa

table de routage la ligne vers les directions affectées. Lorsqu’un nœud source reçoit un tel paquet, elle

recrée les routes si nécessaire.

4.3.5 Analyse de performance

Pour vérifier le comportement de notre protocole de routage, nous analysons ses performances par

simulation. Le simulateur employé est le simulateur NS-2. Les simulations sont effectuées en

comparant l’efficacité de notre protocole avec les protocoles AODV et AODV avec gestion de

l’environnement (nommé AODV Hello). Notre protocole utilisant la fonction poids numéro 1

(respectivement numéro 2) est noté protocole 1 (respectivement protocole 2).

Nous simulons ces protocoles sur différentes topologies où le nombre de nœuds présents sur le réseau

varie. Les nœuds possèdent différents débits de transmission. Par défaut, 50% (respectivement 20% et

30%) des nœuds possèdent un débit de 1 Mbps (respectivement 11 Mbps et 54 Mbps). Les requêtes

RREQ (nécessaires à la découverte d’une route) et les paquets Hello (nécessaires aux protocoles

AODV Hello et au protocole 2) sont échangés à 1 Mbps. Ces paquets ne sont pas comptabilisés dans

la bande passante ayant subi des collisions puisqu’un nœud émetteur n’est capable de détecter une

collision uniquement s’il ne reçoit pas d’acquittement. Les collisions relevées dans nos simulations

portent seulement sur les paquets de données échangés ou relayés. La durée des simulations est de 500

secondes. La simulation utilise un modèle de communication dans lequel la moitié des nœuds

communiquent avec l’autre moitié. Chaque flux possède un débit de 20Kbps.

Les protocoles AODV Hello et numéro 2 utilisent une gestion locale de l’environnement.

Périodiquement, les nœuds échangent un paquet Hello. Dans nos simulations, les nœuds échangent

toutes les 2 secondes un paquet Hello. La rupture d’un lien est détectée lorsqu’un nœud ne reçoit plus

de paquets Hello durant 6 secondes. Les deux autres protocoles sont prévenus par la couche MAC

lorsqu’un paquet n’a pas pu être transmis durant un certain nombre de fois. Le nombre de

retransmissions s’élève à 4 avant de détecter qu’un lien est interrompu.

Dans un premier temps, les simulations sont effectuées sur une topologie où les nœuds sont fixes.

Nous faisons ce choix pour mettre en évidence le comportement de notre protocole suivant différents

paramètres (taille des paquets, variation du débit des nœuds) sans que la mobilité vienne interférer.

Pour vérifier l’efficacité de notre protocole, trois paramètres (la bande passante utilisée par les paquets

97

de données, la bande passante ayant subi des collisions et la bande passante consommée par les

paquets RREQ) révèlent l’efficacité d’un protocole.


présents sur le réseau. La taille des paquets est de 512 octets.

La figure 4-11 donne l’évolution de la bande passante utilisée par les paquets de données en fonction

du nombre de nœuds et donc de la charge (puisque le nombre de flux transitant sur le réseau est moitié

moindre que le nombre de nœuds présents sur le réseau). Jusqu’à 100 nœuds, la bande passante ne

cesse de croître. Le protocole 2 est plus efficace que les autres protocoles. Par contre, le protocole 1

est moins efficace que les autres. Lorsque la charge augmente, la bande passante pour les protocoles

AODV, AODV Hello et le protocole 1 a atteint un seuil voir régresse très légèrement à cause des

chemins empruntés avec un plus faible débit. Par contre, la bande passante du protocole 2 croît

toujours pour atteindre 1 Mbps de plus qu’AODV et AODV Hello (lorsque 200 nœuds sont présents

sur le réseau).

Le manque d’efficacité du protocole 1 montre que la bande passante ayant subi des collisions n’est pas

le critère adéquat pour pénaliser un chemin. En effet, le nombre de collisions évolue très différemment

avec la charge présente sur le réseau. Lorsque la charge est faible, le nombre de collisions l’est aussi.

Lorsque la charge atteint un certain seuil, le nombre de collisions croît rapidement. Dans un tel cas, le

chemin accepté peut créer un goulet d’étranglement réduisant le nombre de paquets de données. Le

nombre de collisions d’un lien n’est donc pas un bon indicateur de la charge présente sur ce lien.

La figure 4-12 présente l’évolution de la bande passante utilisée par les paquets de données (de taille

1500 octets) en fonction du nombre de nœuds présents sur le réseau. Chaque flux du réseau possède un

débit de 20 Kbps. De fait, au lieu de transmettre 3 paquets par seconde comme dans la simulation

précédente (figure 4-14), un seul paquet est transmis. Le protocole 2 est bien plus efficace que les

autres protocoles puisqu’il sélectionne des chemins avec une capacité plus importante. La transmission

d’un paquet de 1500 octets sur un lien de 54 Mbps est bien plus rapide puisqu’il ne nécessite la

transmission d’un seul entête (transmis en un temps constant de 192 µs quelque soit le débit du lien).

Privilégier les liens possédant une capacité de transmission disponible importante accroît la bande

passante disponible du réseau confortant nos attentes initiales.

0

500

1000

1500

2000

2500

3000

3500

4000

30 50 75 100 150 200

Ban

de

pas

sante

con

som

mée

par

les

paq

uet

s de

don

née

s (K

bps)

98


présents sur le réseau. La taille des paquets est de 1500 octets.

La figure 4-13 donne l’évolution de la bande passante nécessaire à la transmission des paquets de

données en fonction du nombre de nœuds présents sur le réseau. 50% (respectivement 30% et 20%)

des nœuds ont une capacité de 54 Mbps (respectivement 11 Mbps et 1 Mbps). La bande passante du

réseau augmente pour chacun des protocoles. En effet, le nombre important de nœuds, dont le débit est

de 54 Mbps, profite à l’ensemble des protocoles. Le nombre de paquets échangés par le nœud source

est fonction de sa capacité. En effet, un nœud source, dont le débit de transmission est de 1 Mbps,

limite le nombre de paquets sur un chemin. La réduction du nombre de nœuds, dont le débit est de

1 Mbps, augmente le nombre de paquets échangés. Le protocole 2, prenant les chemins avec une

capacité élevée, est efficace dans un tel environnement. Par contre, les protocoles AODV et AODV

Hello peuvent traverser un nœud dont la capacité est un goulet d’étranglement.


présents sur le réseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des

nœuds ont un débit de 1Mbps (respectivement 11Mbps, 54Mbps).

La bande passante ayant subi des collisions est le deuxième critère pris en compte pour montrer

l’efficacité d’un protocole.

0

500

1000

1500

2000

2500

3000

3500

4000

4500

30 50 75 100 150 200

0

1000

2000

3000

4000

5000

6000

7000

30 50 75 100 150 200

99

La figure 4-14 donne le nombre de collisions en fonction du nombre de nœuds présents sur le réseau.

Bien que le protocole 2 augmente la bande passante utile du réseau, il crée moins de collisions que le

protocole AODV Hello jusqu’à 200 nœuds. A 200 nœuds, le protocole 2 n’est pas limité par le seuil

atteint par les autres protocoles. De fait, le nombre de collisions croît et est supérieur à celui du

protocole AODV Hello. Le protocole AODV et le protocole 1 créent moins de collisions car le

nombre de paquets de données échangés est plus faible que pour les deux autres protocoles.


réseau. La taille des paquets est de 512 octets.

L’augmentation de la taille des paquets (figure 4-15) ne modifie pas le comportement des protocoles

comparé à la figure précédente. Le protocole 2 crée moins de collisions que le protocole AODV Hello.

Lorsque l’écart entre la bande passante des paquets de données échangés devient plus important (au-

delà de 150 nœuds), le protocole 2 crée plus de collisions que les autres protocoles.


réseau. La taille des paquets est de 1500 octets.

La figure 4-16 illustre la variation de la bande passante ayant subi des collisions avec l’augmentation

de la capacité des nœuds. Le protocole 2 est, dans ce cas, particulièrement efficace. Bien qu’il

0

500

1000

1500

2000

2500

30 50 75 100 150 200

0

500

1000

1500

2000

2500

3000

30 50 75 100 150 200

AODV

AODV Hello

Protocole 1

Protocole 2

Nombre de nœuds

100

fournisse une bande passante utile plus importante, la bande passante ayant subi des collisions est plus

faible que celle des autres protocoles. Le protocole 2 est particulièrement performant dans un tel

environnement.


réseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des nœuds ont un

débit de 1Mbps (respectivement 11Mbps, 54Mbps).

Le dernier critère pour mettre en évidence l’efficacité de notre protocole est la bande passante

nécessaire à la découverte et à la maintenance des routes.

La bande passante consommée par les requêtes est présentée sur la figure 4-17. Le protocole 2

nécessite moins de paquets RREQ que les autres protocoles. En fait, les protocoles avec une gestion

locale de l’environnement sont moins sujets à la perte erronée d’un lien. Le protocole AODV et le

protocole 1 détectent la perte d’un lien lorsqu’un paquet subit 4 échecs de transmissions successives.

Avec les collisions, ce scénario se produit assez souvent et augmente le nombre de requêtes

nécessaires à la maintenance d’une route pourtant toujours active. Les paquets Hello souffrent moins

de ce phénomène. Bien que les nœuds transmettent ces paquets dans un intervalle de temps assez

proche les uns des autres, ils subissent moins de collisions. Ainsi, les nœuds détectent moins souvent

qu’un lien est rompu alors qu’en réalité il est toujours actif. Comparé au protocole AODV Hello, les

nœuds du protocole 2 créent moins de collisions à la fois sur les paquets de données et sur les paquets

RREQ et Hello. Lors de l’établissement d’une route, le protocole 2 nécessite plus de paquets RREQ à

la détermination d’une route que les protocoles AODV et AODV Hello (un nœud ne peut transmettre

qu’une seule fois un paquet RREQ). Sur la durée de la simulation, le protoocle 2 transmet moins de

paquets RREQ, car il détecte moins souvent la perte erronée d’un lien. De fait, il compense largement

le surplus de paquets RREQ nécessaires à la détermination d’une route.

Le protocole 1 nécessite un nombre conséquent de requêtes RREQ pour maintenir et déterminer les

routes. Bien qu’il détecte aussi souvent que le protocole AODV la perte d’un lien, le nombre de

requêtes nécessaires à la détermination d’une route est en moyenne 1,5 fois plus important qu’avec le

0

500

1000

1500

2000

2500

3000

3500

30 50 75 100 150 200

101

protocole AODV. La bande passante consommée par les requêtes RREQ est un des facteurs qui réduit

drastiquement l’efficacité du protocole 1.


sur le réseau. La taille des paquets est de 512 octets.


sur le réseau. La taille des paquets est de 1500 octets.

La figure 4-18 illustre le comportement des protocoles lorsque la taille des paquets est de 1500 octets.

La bande passante consommée par les paquets RREQ suit la même progression que lorsque les

paquets ont une taille de 512 octets. Tout de même, le protocole 2 étant plus performant avec de longs

paquets, la bande passante nécessaire à l’obtention et à la maintenance des routes est plus faible que

pour des paquets de 512 octets. En effet, le nombre de collisions étant plus faible, la perte d’une route

est moins fréquente.

La figure 4-19 met en avant la bande passante ayant subi des collisions lorsque la capacité des nœuds

est plus importante. Avec une capacité des nœuds plus importante, la charge maximale du réseau est

0

500

1000

1500

2000

2500

30 50 75 100 150 200

0

200

400

600

800

1000

1200

1400

1600

1800

2000

30 50 75 100 150 200

102

supérieure. De fait, le nombre de collisions est diminué et réduit la détection d’une fausse perte d’un

lien. Le protocole 2 nécessite une bande passante moindre pour établir et maintenir les chemins.


sur le réseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des nœuds ont

un débit de 1Mbps (respectivement 11Mbps, 54Mbps).

Pour vérifier l’efficacité de notre protocole, nous considérons en dernier lieu le critère de la mobilité.

L’environnement de simulation reste identique à celui des simulations précédentes. Les nœuds

utilisent un modèle RWP (cf. §1.4) pour effectuer un déplacement. Entre chaque déplacement, les

nœuds ont un temps de pause de 200 secondes.

Figure 4-20 : Bande passante consommée par les paquets de données en fonction de la mobilité des

nœuds. Le réseau est composé de 50 nœuds et la taille des paquets est de 512 octets.

La figure 4-20 montre la bande passante consommée par les paquets de données exempts de collisions.

A faible mobilité (2 m/s et 5 m/s), le protocole 2 est très efficace et peu affecté par la mobilité des

nœuds. A mobilité plus élevé, le protocole 2 est moins efficace. Il suit la courbe du protocole AODV

0

500

1000

1500

2000

2500

30 50 75 100 150 200

Ban

de

pas

san

te c

on

som

mée

par

les

req

uêt

es R

RE

Q (

Kbp

s)

0

200

400

600

800

1000

1200

1400

1600

2 5 10 15 20

Ban

de

pas

san

te u

tili

sée

par

les

paq

uet

s de

do

nnée

s (K

bp

s)

103

Hello. Au-delà de 10 m/s, le protocole 2 a une bande passante plus faible que celle du protocole

AODV Hello. Les protocoles utilisant une gestion locale de l’environnement sont moins réactifs que

les protocoles basés sur les informations de la couche MAC pour déceler la rupture d’un lien. En effet,

en utilisant les informations fournies par la couche MAC, il ne faut que 1 seconde pour détecter la

rupture d’un lien. Avec l’utilisation d’une gestion locale de l’environnement, la détection de la rupture

d’un lien a lieu au bout de 6 secondes. Durant ce laps de temps les paquets continuent d’être transmis

sans pouvoir être reçus. Pour permettre au protocole AODV Hello et au protocole 2 d’être plus

efficaces dans un environnement hautement mobile, le temps entre l’échange de deux paquets Hello

doit être plus faible.

Figure 4-21 : Bande passante ayant subi des collisions en fonction de la mobilité des nœuds. Le réseau

est composé de 50 nœuds et la taille des paquets est de 512 octets.

La figure 4-21 montre l’évolution de la bande passante ayant subi des collisions en fonction de la

mobilité des nœuds. Quelle que soit la mobilité des nœuds, les nœuds utilisant le protocole 2 crée

moins de collisions que les nœuds utilisant le protocole AODV Hello. Par contre, la bande passante

ayant subi des collisions est plus importante que celle avec le protocole AODV et le protocole 1. Cela

s’explique principalement à cause des paquets émis alors qu’un lien est rompu. Durant le laps de

temps précédent la détection de la rupture d’un lien, il continue à émettre. Ne recevant pas

d’acquittement, il suppose que le paquet a subi une collision et le retransmet. De fait, la charge du

réseau augmente et le nombre de collisions croît.

La figure 4-22 met en évidence la bande passante consommée par les paquets RREQ en fonction de la

mobilité des nœuds du réseau. Le protocole 2 a la bande passante la plus faible lorsque les nœuds sont

faiblement mobiles. Lorsque la mobilité croît, le nombre de requêtes est plus important qu’avec le

protocole AODV Hello. Le protocole 2 nécessite plus de requêtes pour déterminer une route. Dans un

tel environnement, la détection de la rupture d’un lien est peu erronée (contrairement à un

environnement à faible mobilité). De fait dans un environnement à faible mobilité, la bande passante

requise par les informations de routage du protocole 2, est plus importante que celle du protocole

AODV.

0

50

100

150

200

250

300

350

400

450

2 5 10 15 20

104

Figure 4-22 : Bande passante consommée par les requêtes en fonction de la mobilité des nœuds. Le

réseau est composé de 50 nœuds et la taille des paquets est de 512 octets.

4.4 Discussion

La bande passante consommée par les collisions réduit la bande passante du réseau. Les collisions

entraînent des retransmissions et accroissent le délai d’attente des paquets de données (cf. §4.2.2). Le

protocole de routage doit tout mettre en œuvre pour en diminuer l’impact. Pour cela, le protocole de

routage doit prendre en compte les facteurs influant sur l’occurrence d’une collision.

Dans un premier temps, nous avons identifié ces facteurs. Ces facteurs sont (cf. §4.2.1) : le nombre de

nœuds voisins, le débit de transmission et la charge du lien. Dans un environnement où les nœuds sont

uniformément répartis, la longueur du chemin est aussi un facteur.

Nous proposons un protocole de routage, basé sur le protocole AODV, pour diminuer le nombre de

collisions et leur impact sur le réseau (cf. §4.3). Pour cela, nous avons proposé deux fonctions poids

pénalisant différents facteurs pour réduire les collisions.

La première fonction poids utilise trois métriques pour sélectionner un chemin : le nombre de sauts, la

bande passante collisionnée d’un nœud et le débit de transmission (capacité). Cette fonction pénalise

exponentiellement les liens dont la bande passante collisionnée est importante. Les simulations ont

révélé que les facteurs utilisés par cette fonction poids ne sont pas adaptés pour accroître la bande

passante utile du réseau. Bien qu’une telle fonction sélectionne les chemins avec la capacité la plus

élevée, ce paramètre n’est pas suffisant pour en améliorer pleinement l’efficacité. De plus, la bande

passante ayant subi des collisions est un mauvais indicateur de la charge d’un lien. Bien souvent,

lorsque les collisions surviennent, le lien est déjà surchargé. Ajouter un flux augmente le nombre de

collisions et va à l’encontre de ce qui est souhaité.

Après avoir mis en évidence que la combinaison de certains facteurs n’augmente pas la bande passante

utile du réseau, nous proposons une seconde fonction poids. Elle prend en compte les facteurs

favorisant l’occurrence de collisions. Cette fonction poids utilise trois métriques : le débit de

0

10

20

30

40

50

60

70

2 5 10 15 20

Ban

de

pas

san

te c

on

som

mée

par

les

req

uêt

es R

RE

Q (

Kbp

s)

105

transmission, la bande passante disponible et le nombre de nœuds voisins. Elle sélectionne les chemins

les moins chargés en fonction de la bande passante disponible. Plus la bande passante disponible est

importante, plus la charge traversant le lien est faible. Le temps de transmission d’un paquet est

fonction du débit de transmission du nœud. De fait, un paquet transmis avec un faible débit de

transmission occupe plus longtemps le support. Durant l’occupation du support, les nœuds voisins ne

peuvent pas transmettre même s’ils possèdent un débit bien supérieur. Notre fonction poids pénalise ce

facteur pour utiliser en priorité les chemins avec le débit le plus élevé. Le nombre de nœuds voisins est

le dernier facteur pris en compte par cette fonction poids. Un flux impacte non seulement les nœuds

qu’il traverse mais aussi leurs voisins. Prendre un chemin avec un nombre de voisins important

augmente la charge sur l’ensemble de ses voisins et réduit d’autant la bande passante disponible du

réseau.

Pour montrer l’efficacité de notre protocole et des fonctions poids qui lui sont adjointes, le

comportement de notre protocole est simulé, dans différents environnements. La deuxième fonction

est efficace dans un environnement peu mobile. La bande passante utile du réseau est plus élevée que

celle des protocoles de routage AODV et AODV Hello. Dans un environnement mobile plus

dynamique, notre protocole de routage combiné à la fonction poids numéro 2 est moins efficace que le

protocole AODV. La détection de la rupture d’un lien est plus longue avec une gestion locale de

l’environnement qu’avec les informations fournies par la couche MAC. Pour être pleinement

opérationnel, il est nécessaire de trouver un équilibre entre le surcoût (overhead) et l’efficacité. En

effet, une gestion plus réactive augmente la charge sur le réseau, alors qu’une gestion trop lente

diminue l’efficacité du protocole de routage.

Le nombre de requêtes échangées par les nœuds utilisant notre protocole de routage combiné à la

fonction poids numéro 2 est plus faible dans la totalité des environnements de simulation. Tout de

même, notre protocole nécessite plus de paquets RREQ nécessaires. Cette augmentation des

informations de routage peut avoir un effet néfaste comme dans le cas du protocole 1. Le protocole 2

est moins sensible à cela, puisqu’il compense en détectant moins souvent une rupture erronée d’un lien.

Réduire de telles informations augmente la bande passante disponible du réseau. Nous nous attachons

dans le chapitre suivant à en diminuer le coût.

107

5 Approches de Réduction de la charge due aux informations

de contrôle

De nombreux facteurs influent sur la consommation de la bande passante utile d’un réseau MANET

(cf. §4). Les collisions ne sont pas le seul paramètre à prendre en compte. En effet, les informations de

routage jouent un rôle important dans la diminution de la bande passante du réseau. Pour déterminer

une route, entre un nœud source et un nœud destination, les nœuds du réseau ont besoin

d’informations de routage pour trouver un tel chemin. Les protocoles de routage réactifs émettent ces

informations uniquement lorsque la nécessité d’obtenir une route se fait ressentir (création ou

maintenance). Les protocoles proactifs envoient périodiquement des informations de routage

permettant d’avoir une vue plus ou moins globale du réseau et ainsi à tout moment connaître les routes

vers l’ensemble des nœuds du réseau.

Les informations de routage consomment de la bande passante, réduisant de ce fait la bande passante

utile du réseau. Cette diminution réduit la quantité de données transmises sur le réseau et augmente le

nombre de collisions. Ces informations étant généralement diffusées sur le réseau, elles ne sont pas

retransmises réduisant leur impact sur le réseau. Malgré cela, le protocole de routage doit contrôler les

informations de routage échangées. Dans la suite de ce chapitre, nous nous intéressons uniquement

aux protocoles de routage réactifs et aux méthodes permettant la diminution des informations de

routage.

108

De nombreuses manières permettent de réduire les informations de routage. En effet, les protocoles

réactifs échangent des informations de routage durant la phase de découverte d’une route mais aussi

durant la phase de maintenance des routes. Pour réduire les informations de routage, différents

protocoles peuvent être utilisés. Les points suivants donnent un ensemble non exhaustif des approches

couramment employées pour diminuer le nombre des informations de routage échangées :

– Stabilité des routes : Le déplacement des nœuds dans le réseau entraîne des ruptures sur les

chemins déjà établis. Le nœud source est prévenu de telles coupures et doit rétablir la

connexion avec la destination. Pour cela, il recrée une route en échangeant des informations de

routage. L’accroissement de la vitesse de déplacement de certains nœuds rend les routes

particulièrement instables et crée de nombreuses transmissions pour maintenir les routes

établies. Lors de la création d’une route, le protocole de routage peut privilégier les nœuds

stables (les nœuds dont la connectivité avec ses voisins évoluent très peu dans le temps).

Choisir des routes plus stables diminue le nombre d’informations de routage nécessaire à leur

maintenance.

– Réduction de l’espace de recherche : Un protocole de routage réactif propage, lors de la

création d’une route, les informations de routage sur la totalité du réseau. Nombreuses sont ces

informations à ne pas être utilisées pour la création d’une route. Généralement, les nœuds qui

ne sont pas situés entre la source et la destination sont rarement utilisés dans la création des

routes. La propagation des informations de routage par de tels nœuds ne fait qu’augmenter le

trafic sur le réseau. Le protocole de routage doit empêcher que ces nœuds transmettent des

informations de routage. La réduction de l’espace de recherche limite à un ensemble de nœuds

la propagation des informations de routage. Cette réduction nécessite la connaissance de la

position de la destination par le nœud source. Généralement, un protocole de routage,

réduisant l’espace de recherche, est conjointement utilisé avec un protocole de détermination

de la position de la destination.

– Utilisation de multiples chemins : Lors de la phase de découverte des routes, un protocole de

routage peut retourner différents chemins pour accroître la durée de connectivité entre deux

nœuds. En effet, lors de la rupture d’un chemin, le nœud source peut choisir un autre chemin

évitant une éventuelle phase de découverte des nœuds. Ce procédé permet de réduire le

nombre d’informations de routage échangées généralement lors des changements de topologie.

Pour être particulièrement efficace, les protocoles utilisant cette méthode doivent trouver de

multiples chemins distincts. Deux types de distinction des chemins existent : les distinctions

en nœud et en lien. Deux chemins sont considérés distincts en nœud s’ils n’ont aucun nœud en

commun (à part la source et la destination). De même, les chemins sont distincts en lien, si les

chemins retournés traversent tous des liens différents. Trouver des chemins distincts empêche

que la rupture d’un lien impacte plusieurs chemins pour un couple (source, destination).

– Utilisation de topologies particulières : L’utilisation de topologies particulières peut réduire le

nombre d’informations nécessaires à la découverte d’une route. Certains nœuds de cette

topologie peuvent centraliser les informations d’une partie du réseau et sont les seuls à

échanger les informations de routage lors de la découverte des routes. Par exemple, supposons

109

un réseau de clusters (cf. §2.2.1). Les nœuds d’un même cluster sont affiliés à une tête de

cluster. Chaque tête de cluster connaît les nœuds qui lui sont affiliés. Lorsqu’un nœud

nécessite la création d’une route, il envoie une requête de création de route à sa tête de cluster.

Une tête de cluster recevant un tel paquet sait si la destination lui est affiliée ou non. Si la

destination est directement joignable, elle confirme un chemin en direction de la source. Dans

le cas contraire, la tête de cluster propage la requête à ses passerelles qui transmettent la

requête aux passerelles ou aux têtes de cluster auxquelles elles sont reliées.

Dans la suite de ce chapitre, nos travaux portent sur la réduction de l’espace de recherche. Dans un

premier temps, nous proposons un protocole pour déterminer la position de la destination. Pour cela,

nous utilisons une topologie de réseau à backbone. Ensuite, des méthodes pour réduire l’espace de

recherche sont proposées et étudiées. Deux protocoles de routage utilisant une recherche de parcours

en profondeur sont fournis et leur efficacité est montrée à l’aide de simulations.

5.1 Détermination de la position de la destination

Un nœud source doit connaître la position de la destination pour réduire l’espace de recherche dans

lequel sont propagées les informations de routage. Chaque nœud a donc besoin de connaître sa

position géographique par rapport aux autres nœuds du réseau. Pour cela, un récepteur GPS (Global

Positionning System) [PAR 83-1], [GPS] peut être utilisé pour récupérer ses coordonnées. Les

récepteurs GPS sont aujourd’hui suffisamment légers et petits pour être embarqués dans n’importe

quel équipement. Chaque nœud détermine ses coordonnées (X, Y) dans une zone donnée.

Des protocoles de gestion de la localisation ont été proposés dans la littérature (tels que [LI 00-1] et

[BLA 01-1]) pour permettre à un nœud de connaître la position des autres nœuds dans le réseau. Dans

GLS [LI 00-1], un modèle de serveur distribué est décrit. Dans ce modèle, une station définit d’autres

nœuds dans une certaine zone comme ses serveurs de localisation. Chaque station envoie

périodiquement ses informations de localisation à ses serveurs de localisation. Les autres nœuds du

réseau peuvent ainsi connaître la position d’une station en interrogeant les serveurs de localisation de

cette station. Une autre approche est abordée dans [BLA 01-1]. Chaque nœud définit une zone

virtuelle, noté VHR (Virtual Home Region), avec un centre fixe. Chaque nœud envoie ses

informations de localisation à son VHR. Lorsqu’un nœud veut en contacter un autre, il contacte

d’abord son VHR pour obtenir sa position. Dans ces deux méthodes, les nœuds nécessitent de

connaître approximativement la couverture du réseau. Le surcout en paquets engendré par les

informations de localisation s’avère assez important dans ces protocoles.

Le protocole de localisation doit déterminer la position de la destination à moindre coût. Nous

proposons une méthode différente des deux précédentes pour obtenir à moindre coût la position de la

destination. Pour réaliser cela, nous utilisons un réseau à backbone (cf. §2.2.2) pour déterminer la

position d’une station. Les informations relatives à la détermination de la position d’un nœud sont

transmises sur le réseau à backbone réduisant, de fait, les informations échangées sur le réseau

MANET. Le débit accepté par le réseau à backbone est relativement faible du fait de sa fréquence de

fonctionnement. En effet, ce type de réseau possède une portée élevée (donc une fréquence de

110

fonctionnement relativement faible) pour convenablement connecter les nœuds de backbone entre eux.

Il n’est donc pas envisageable d’utiliser le réseau à backbone pour échanger la totalité des données

transitant généralement sur le réseau MANET. La cohabitation est donc particulièrement intéressante.

5.1.1 Protocole de localisation de la destination

Dans cette partie, nous proposons un protocole pour déterminer à moindre coût la position d’un nœud

dans le réseau [ESP 06-2]. Pour cela, notre protocole est découpé en deux parties. La première

consiste à trouver le nœud de destination et à l’interroger pour obtenir sa position. La deuxième partie

est une phase de maintenance de la connectivité entre le nœud source et le nœud destination à travers

le réseau à backbone. Conserver une telle connectivité permet de recevoir périodiquement la position

de la destination et d’établir plus rapidement une nouvelle route vers ce nœud en cas de rupture de la

route utilisée.

5.1.1.1 Phase de découverte de la destination

Le protocole de localisation doit déterminer la position d’un nœud destination sans impacter outre

mesure le réseau ad hoc. Dès lors, les paquets nécessaires à déterminer la destination sont propagés

principalement sur le réseau à backbone. Chaque nœud de backbone maintient une liste des nœuds qui

lui sont affiliés.

Quand un nœud source souhaite créer une route avec un nœud destination, il doit au préalable

déterminer sa position. Le principe de notre protocole est de propager les requêtes de localisation sur

le réseau à backbone. Quand un nœud du réseau de backbone trouve la destination dans la liste des

nœuds qui lui sont associés, il demande au nœud destination de donner sa position à la source. Le

nœud source, respectivement destination, peut être de deux types : un nœud ad hoc normal ou un nœud

du backbone. Le fonctionnement du protocole est différent suivant le type de nœuds.

L’algorithme utilisé par la source pour déterminer la position de la destination est donné par la

figure 5-1. Le nœud source crée une requête LREQ pour déterminer la position de la destination. Cette

requête contient les champs suivants : adresse source, numéro de séquence source, adresse de

destination, numéro de séquence de destination, identifiant de la requête, champ réparation. Le champ

de réparation est mis à 0 lors de la recherche d’une localisation. L’utilisation des numéros de séquence

permet la datation des informations de routage et empêche la création de boucle (cf. §2.1.2.1). Si le

nœud source est un nœud sur le réseau ad hoc, il doit envoyer la requête au nœud de backbone auquel

il est affilié. Dans le cas où le nœud source est lui-même un nœud de backbone (BN), il peut

directement diffuser la requête sur le réseau à backbone. Une fois la requête émise, il déclenche un

temporisateur Trep durant lequel il doit recevoir une réponse. Si le temporisateur arrive à échéance, le

nœud source recrée une requête et réessaie d’obtenir la position de la destination. Si au bout d’un

certain nombre de tentatives il n’obtient toujours pas la position de la destination, il détermine la route

sans utiliser la position de la destination. Dans ce cas, une réduction de l’espace de recherche ne peut

être envisagée.

111

Figure 5-1 : Organigramme utilisé par le nœud source pour déterminer la position de la destination.

L’encadré en pointillé met en valeur la partie différente de notre protocole comparé au protocole

AODV.

L’algorithme exécuté par un nœud intermédiaire est fourni par la figure 5-2. Chaque nœud du réseau

maintient une table de localisation. Cette table permet de déterminer pour un nœud donné le prochain

nœud auquel envoyer ses paquets pour lui propager sa position. Cette table contient les champs

suivants : adresse de destination, numéro de séquence, adresse du prochain nœud.

Lorsqu’un nœud intermédiaire reçoit une requête LREQ, il vérifie en premier lieu s’il l’a déjà reçue. Si

tel est le cas, il supprime cette requête. Sinon, il met à jour sa table de localisation pour joindre la

source, et adapte son fonctionnement suivant que le nœud destination lui est affilié ou non. Lorsque le

nœud destination est affilié à ce nœud intermédiaire, il envoie la requête au nœud de destination pour

informer ce dernier de retourner, au nœud source, sa position. Dans le cas où le nœud destination ne

lui est pas affilié, il propage la requête sur le réseau à backbone.

112

A la réception d’un paquet de réponse de localisation, noté LREP, le nœud intermédiaire regarde dans

sa table de routage le nœud suivant pour joindre le nœud source et lui émet la requête. En même,

temps, il ajoute dans sa table de localisation le nœud suivant pour joindre la destination. Ainsi, une

route dans le sens source-destination et une route dans le sens destination-source sont conservées dans

la table de localisation.


partie différente de notre protocole comparé au protocole AODV.

La figure 5-3 donne l’algorithme utilisé par le nœud destination. Lorsqu’il reçoit une requête LREQ, il

met à jour sa table de localisation pour joindre la source. Il envoie ensuite au nœud lui ayant transmis

la requête LREQ, une réponse LREP avec le champ réparation positionné à 0. Une requête LREP est

formée par les champs suivants : adresse source, adresse destination, numéro de séquence de

destination, champ réparation et les coordonnées géographiques de la destination. Le nœud destination

déclenche un temporisateur Ta permettant l’envoi périodique de ses coordonnées géographiques au

nœud source.

A la réception d’une réponse LREP, le nœud source connaît à cet instant la position géographique de

la destination. Il peut alors engager le processus de création de route sur le réseau ad hoc en limitant

l’espace de recherche. En cas de rupture de route, la source utilise les dernières coordonnées

géographiques du nœud destination pour restreindre l’espace de recherche.

Lorsque le nœud destination ne reçoit plus, pendant un certain laps de temps, de paquets de données

provenant d’un nœud source, il cesse de lui envoyer sa position.

113

Le protocole de localisation n’a pas pour vocation de choisir le chemin le plus court sur le réseau à

backbone. Le but premier de ce protocole est d’être suffisamment réactif pour obtenir le plus

rapidement possible les coordonnées géographiques du nœud destination. En effet, le temps d’obtenir

ces coordonnées n’est pas négligeable. Par conséquent, ce retard engendré par la recherche de la

position du nœud destination doit être aussi faible que possible.



5.1.1.2 Phase de maintenance

Par un paquet de mouvement noté MOVP, le nœud destination informe à intervalle régulier le nœud

source de sa position. Ce paquet contient les coordonnées géographiques de la destination et

éventuellement des paramètres tels que la vitesse, le sens de déplacement … Ainsi en cas de rupture de

route, la source a une position suffisamment récente de la destination pour éviter d’utiliser la phase de

localisation de la destination. Une telle méthode évite le délai engendré par la détermination de la

position du nœud destination.

Pour transmettre périodiquement les paquets MOVP, la destination peut utiliser deux méthodes. La

première méthode consiste à diffuser un paquet MOVP sur le réseau à backbone. A la réception de ce

paquet par un nœud de backbone, il vérifie sa liste des nœuds affiliés. Si le nœud source en fait partie,

il lui transmet le paquet. Si le nœud de backbone a déjà reçu un tel paquet MOVP, il le supprime.

Cette méthode s’avère particulièrement facile à mettre en œuvre car même si la topologie du réseau

backbone change, le paquet MOVP parvient toujours à un nœud de backbone auquel la source est

affiliée. Par contre, cette méthode consomme beaucoup de bande passante sur le réseau à backbone, du

fait de la diffusion du paquet.

La deuxième méthode est d’utiliser la conservation des routes de localisation entre le nœud destination

et le nœud source (cf. figure 5-2). Chaque nœud maintient une table de localisation dans laquelle est

DEBUT

LREQ déjà reçu ?

non

ouiSupprimer

la requête

- Mettre à jour l’entrée de la table de

localisation pour le nœud source

- Créer une requête LREP

- Initialiser les champs de LREP

- Emettre LREP

- Déclencher un temporisateur Ta

LREQ reçu ?

oui

Ta expiré ?non

non

oui

- Envoyer au nœud source sa position

- Réarmer Ta

114

conservé le prochain nœud pour joindre un nœud source. Ainsi, la destination peut envoyer

périodiquement un paquet MOVP au nœud suivant de sa table de localisation pour informer la source

de sa position courante. Le problème de cette méthode est qu’avec le déplacement des nœuds, la

topologie du réseau à backbone peut évoluer avec le temps. Il est nécessaire d’avoir des mécanismes

de réparation des routes pour maintenir l’échange des paquets MOVP entre le nœud destination et

source.

Suivant le changement de la topologie du réseau à backbone, il est nécessaire d’avoir un mécanisme

de restauration des routes de localisation. Un changement sur la topologie du backbone peut affecter

un nœud source comme un nœud destination. En effet, un nœud source ou destination peuvent

s’affilier à un autre nœud du réseau à backbone. La topologie du backbone peut, aussi, changer (c'est-

à-dire qu’un lien sur le réseau backbone peut être rompu, coupant les routes en places).

Lorsqu’un nœud source change d’affiliation, l’ancien nœud de backbone X, auquel il était affilié,

reçoit toujours les paquets de la destination. Le nœud de backbone X crée une route avec la source.

Pour cela, il diffuse un paquet LREQ avec un champ réparation égal à 1. A la réception d’un paquet

LREQ dont le champ réparation est activé, le nœud de backbone (auquel la source est affiliée) répond

à sa place. Une route est dorénavant établie entre la source et la destination.

Lorsqu’un nœud destination change d’affiliation, il doit recréer une route avec les nœuds sources

auxquels il envoie des informations de localisation. Pour cela, il crée un paquet LREQ pour chaque

source avec le champ réparation positionné à 1. La route entre la destination et la source est ainsi

rétablie et la destination peut recommencer à envoyer ses informations de localisation.

Quand un nœud de backbone détecte une coupure, une requête de réparation de route (LERR) est

envoyée aux nœuds transmettant les informations de localisation. Une requête LERR contient

l’ensemble des nœuds qui ne sont plus joignables. A la réception d’une requête LERR, les nœuds

recréent une route avec les nœuds sources (dont la rupture a interrompu la réception des paquets

MOVP) en émettant un paquet LREQ dont le champ réparation est positionné à 1.

5.1.1.3 Analyse de performance

Pour simuler le comportement de notre protocole, nous utilisons le simulateur NS-2. Nous comparons

notre protocole de localisation avec un protocole utilisant un serveur de localisation fixe. Dans un tel

protocole chaque nœud du réseau connaît l’adresse du serveur fixe et lui envoie toutes les 3 secondes

un paquet contenant sa localisation. Chaque nœud établit et maintient une route avec ce serveur de

localisation avant tout envoi de paquet de localisation. Pour obtenir une position, le nœud contacte le

serveur de localisation. Notre protocole utilise une topologie en backbone. Pour maintenir cette

topologie, l’ensemble des nœuds du réseau diffuse un paquet Hello toutes les 3 secondes pour la

gestion du backbone. Ce paquet permet la prise en compte de l’arrivée de nouveaux nœuds et aussi la

maintenance de la topologie en identifiant la perte d’affiliation avec un nœud de backbone (quand le

nœud de backbone sort de la zone de couverture d’un nœud par exemple …). Chaque nœud

destination envoie périodiquement (toutes les 3 secondes) sa position au nœud source pour éviter une

éventuelle phase de demande de position lors de la perte d’une route.

115

Le réseau est composé d’un nombre variable de nœuds selon la simulation effectuée. Lorsque ce n’est

pas précisé, les nœuds se déplacent à une vitesse maximale de 5m/s. Le rayon de couverture d’un

nœud ad hoc est de 150 mètres. Le rayon de couverture d’un nœud de backbone est de 300 mètres. Les

nœuds sont répartis dans une zone carrée de 1000m de côté. Ils utilisent pour se déplacer le modèle

RWP (cf. §1.4) avec un temps de pause de 200 secondes entre déplacements. Ils possèdent une vitesse

de transmission de 2Mb/s. La simulation utilise un modèle de communication dans lequel la moitié des

nœuds communiquent avec l’autre moitié. Pour simuler notre protocole, 20% des nœuds sont

susceptibles d’être élus nœuds du backbone. Ces nœuds possèdent deux fréquences de fonctionnement,

une fréquence conventionnelle pour le réseau ad hoc et une autre fréquence pour les échanges entre

nœuds du backbone. Chaque nœud du réseau est au moins affilié à un nœud de backbone ou est un

nœud de backbone. La durée d’une simulation est de 500 secondes.

Dans un premier temps, nous comparons le surplus d’informations nécessaires à l’obtention d’une

position. Pour cela, les simulations montrent le nombre de requêtes échangées sur la totalité du réseau

dans différents environnements.

Figure 5-4 : Nombre de requêtes de localisation échangées en fonction du nombre de nœuds avec une

mobilité des nœuds de 5m/s.

La figure 5-4 montre l’évolution du nombre de requêtes suivant l’augmentation du nombre de nœuds.

On remarque que les deux protocoles évoluent assez linéairement. Le serveur de location fixe possède

un nombre de requêtes bien plus important que notre protocole (environ trois fois plus). Ce nombre

s’explique du fait que chaque nœud du réseau doit établir et maintenir une connexion avec le serveur

de location pour mettre à jour sa position. Le nombre de sauts moyens pour joindre ce serveur est

assez élevé (en moyenne 3,4 sauts pour un réseau de 100 nœuds) augmentant grandement le nombre

de requêtes. Notre protocole, quant à lui, gère la demande de position réactivement. Les nœuds du

réseau n’ont pas besoin de préciser leur position périodiquement. Seules les destinations envoient

périodiquement leur position à leurs sources. La grande majorité des informations transitent sur le

réseau à backbone engendrant un faible surcoût. En effet, les destinations envoient toutes les 3

secondes leur position. Cette gestion de la localisation de la destination utilise seulement (en moyenne)

0

10

20

30

40

50

60

70

10 30 50 75 100 150

Ban

de

pas

sante

néc

essa

ire

à l’

obte

nti

on

des

posi

tions

(Kb

/s)

116

1,6 message par mise à jour de la position. En effet, la plupart des messages transitent à travers le

réseau à backbone. Lors de la création d’une route, la source demande la position de la destination à

travers le backbone. L’obtention de la position est réalisée, au maximum, en 4 messages. En effet, les

messages de localisation sont échangés sur le réseau ad hoc uniquement entre le nœud source,

(respectivement destination), et son nœud de backbone. Donc lorsque les nœuds source et destination

sont des nœuds ad hoc normaux, un message est émis par la source pour demander la localisation, un

message est émis par le nœud de backbone auquel la source est affiliée, un message est envoyé en

réponse par la destination, et enfin la réponse est propagée à la source par son nœud de backbone.

Avec le faible surcoût pour obtenir et maintenir les positions des nœuds de destination, notre protocole

passe facilement à l’échelle avec l’augmentation du nombre de nœuds.

La figure 5-5 montre l’évolution du nombre de requêtes de localisation en fonction de la mobilité des

nœuds du réseau. La surcharge en requête évolue lentement avec la vitesse des nœuds. Avec le serveur

de location fixe, chaque nœud du réseau doit maintenir une route avec le serveur de location. Avec

l’augmentation de la vitesse des nœuds, les ruptures de chemins avec le serveur de localisation sont

plus fréquentes entraînant une augmentation du nombre de requêtes nécessaires à la localisation.

L’évolution des chemins reste toutefois limitée dans nos simulations à cause du temps de pause qui

s’élève à 200 secondes entre déplacements. Avec un temps de pause beaucoup plus faible, le nombre

de requêtes de localisation augmenterait encore plus avec l’accroissement de la vitesse des nœuds. La

vitesse des nœuds a un faible impact avec notre protocole. En effet, les routes sont rompues comme

pour le serveur de localisation mais la maintenance des routes est réalisée, principalement, sur le

réseau à backbone. De même, avec une portée de transmission plus importante pour les nœuds du

backbone, la stabilité du réseau à backbone est plus grande et moins sensible aux ruptures de liaison

entre nœuds de backbone.

Figure 5-5 : Nombre de requêtes de localisation échangées en fonction de la mobilité des nœuds pour

deux topologies différentes (une composée de 50 nœuds, l’autre composée de 100 nœuds).

La figure 5-6 met en évidence l’augmentation du temps d’obtention de la position d’un nœud

destination en fonction de la charge du réseau. En effet avec l’augmentation du nombre de nœuds dans

0

10

20

30

40

50

60

70

0 2 5 10 15 20

117

le réseau, la charge du réseau augmente puisque le nombre de flux est égal à la moitié du nombre de

nœuds présents dans le réseau. Le temps d’obtention de la position de la destination est assez faible

puisque la connectivité est non assurée lorsque le nombre de nœuds est trop faible (inférieur à 30

nœuds). Ainsi, la charge est moins importante qu’elle ne devrait l’être dans ces deux scénarios.

L’obtention de la position d’une destination souffre peu de l’attente de la libération du support. Par

contre dans les scénarios pour lesquels le nombre de nœuds est supérieur à 30, la totalité des

connexions sont établies. Les nœuds doivent attendre un moment en file d’attente avant d’acquérir le

support. Notre protocole souffre moins de cette surcharge puisque seulement deux nœuds sur le

chemin la subisse. En outre à l’aller de la demande de position, seulement le nœud source (qui envoie

la demande à son nœud de backbone) et le nœud de backbone (auquel la destination est affiliée)

souffrent de cette attente. Entre ces deux nœuds, les messages transitent sur le réseau à backbone (avec

une faible surcharge car seuls les messages de localisation transitent à travers ce réseau). De même

pour la réponse à la demande de position, seulement la destination et le nœud de backbone (auquel est

affiliée la source) attendent durant un certain temps l’acquisition du support de transmission. Avec le

serveur de location fixe, chaque nœud du chemin (entre la source et le serveur de location) souffre de

l’attente de l’acquisition du support. Le délai est, par conséquent, plus important. Les simulations ont

également mis en évidence que notre protocole souffre d’un délai légèrement plus important lorsque le

nœud source, le nœud destination et le serveur de location sont tous situés à portée radio. Ce point de

faiblesse n’est pas mis en évidence par les résultats de simulation car ce cas est assez rare et le temps

obtenu est une moyenne entre les différents temps d’obtention d’une position. Ce surplus de temps

s’explique par le fait que même si la source et la destination sont situées à un saut, la source envoie sa

demande de position au nœud du backbone auquel elle est affiliée. Dans le cas du serveur fixe, la

source demande directement la position au serveur de localisation qui se situe à un saut.

Figure 5-6 : Temps d’obtention de la position d’un nœud destination en fonction du nombre de nœuds

du réseau

La figure 5-7 met en évidence l’évolution du temps en fonction de la mobilité et de la charge du réseau.

Ce temps est mis en évidence sur deux topologies différentes (une composée de 50 nœuds, l’autre de

0

0,5

1

1,5

2

2,5

10 30 50 75 100 150

118

100 nœuds). Pour une topologie de 100 nœuds, la courbe évolue assez linéairement. Le temps

d’obtention de la position de la destination croît quelque soit le protocole de localisation utilisé. Notre

protocole a un temps plus faible pour les mêmes raisons que celles exprimées sur la figure 5-6. En

utilisant notre protocole, la plupart des messages transitent sur le réseau à backbone qui est moins

surchargé. Pour la topologie de 100 nœuds, la charge sur le réseau étant bien plus importante, le délai

(pour les deux protocoles) est bien plus important au départ. Les courbes suivent, également, une

progression linéaire, même si elle est plus lente que sur la topologie formée de 50 nœuds. Notre

protocole possède un délai moins important dans l’ensemble des situations.

Figure 5-7 : Temps d’obtention de la position d’un nœud destination en fonction de la mobilité des

nœuds pour deux topologies (une composée de 50 noeuds, l’autre composée de 100 nœuds).

5.1.1.4 Discussion

Nous avons proposé un protocole de localisation réactif. Ce protocole récupère la position d’un nœud

destination en utilisant un réseau à backbone. La formation et la maintenance d’un tel réseau permet

de réduire les informations de localisation.

Les résultats de simulation ont montré que notre protocole est efficace. Il diminue grandement le

nombre de requêtes comparé à un protocole de localisation basé sur un serveur fixe de localisation. Le

nombre de requêtes nécessaires au fonctionnement de notre protocole est très faible. La surcharge la

plus importante est la mise en place et la maintenance de la topologie du réseau à backbone. Pour cela,

il est nécessaire que les nœuds se fassent connaître de leurs voisins, en transmettant périodiquement

des paquets Hello. Même avec un tel surplus, notre protocole transmet bien moins de requêtes.

Notre protocole est moins sensible aux déplacements des nœuds. En effet, la mobilité des nœuds

nécessite la maintenance des routes. Cette maintenance consomme de la bande passante et accroît la

charge du réseau augmentant le délai d’obtention d’une position. En utilisant le réseau à backbone qui

est peu chargé (car seul les paquets de localisation le traversent), notre protocole offre un délai bien

plus faible pour l’obtention d’une position.

0

0,5

1

1,5

2

2,5

0 2 5 10 15 20

Serveur de location

fixe (50 nœuds)

Notre protocole

(50 nœuds)

Serveur de location

fixe (100 nœuds)

Notre protocole

(100 nœuds)

Mobilité des nœuds (m/s)

119

5.2 Réduction de l’espace de recherche

L’espace de recherche est la zone du réseau dans laquelle sont propagées les informations de routage.

Lors de la phase de découverte des routes, le nœud source émet un paquet RREQ. Avec le protocole

AODV, les paquets RREQ sont propagés à l’ensemble des nœuds du réseau. En connaissant la

position de la destination, le protocole peut limiter la zone de recherche aux nœuds situés entre le

nœud source et le nœud destination. Une réduction de l’espace de recherche diminue généralement le

nombre d’informations de routage nécessaires à l’obtention d’une route.

Dans cette partie, nous étudions deux formes géométriques distinctes. La première consiste en

l’utilisation d’une forme triangulaire [ESP 07-1] alors que la seconde correspond à une forme en

cerf-volant [ESP 07-2]. Ensuite, nous donnons un protocole, basé sur AODV, pouvant réduire l’espace

de recherche en fonction des formes précédentes. Enfin, des simulations sont réalisées pour montrer

l’efficacité de notre protocole.

5.2.1 Forme géométrique triangulaire

L’espace de recherche est défini par une forme géométrique triangulaire (figure 5-8). Seuls les nœuds

situés à l’intérieur de cette zone transmettent les informations de routage. Initialement, le nœud source

S connaît seulement sa position et celle du nœud destination D. Certains paramètres comme l’angle

α = DSCet la longueur β (se trouvant dans le prolongement de la droite SD) sont fournis par le nœud

source.

La zone de recherche est délimitée par un triangle isocèle CSC’ avec un angle égal à 2α et une hauteur

de longueur SD + β, où β est une marge permettant d’accroître la chance d’atteindre D. Chaque nœud

recevant une requête RREQ doit déterminer s’il se situe dans la zone de recherche et ainsi s’il doit la

retransmettre. Pour cela, divers paramètres doivent être calculés tels que la valeur de θ (représentant

l’angle entre la normale et la médiane du triangle), les coordonnées de δ (point situé sur la médiane à

une distance β de D)et celles de C et C’.

Dans la suite, nous supposons que XS ≠XD (Xi représente l’abscisse d’un point i) et nous limitons α

tel que α< 90°. Cette limitation de α est réalisée pour que les requêtes soient bien propagées en

direction de la destination.

Pour déterminer la zone de recherche, il est nécessaire de calculer les coordonnées des points C et C’.

Les points C et C’ ont pour projection orthogonale le point δ sur la droite SD. En connaissant l’angle α

et les coordonnées du point δ, les coordonnées des points C et C’ peuvent être facilement obtenues. La

première chose à faire est de trouver les coordonnées du point δ. Par commodité, nous notons

Y = aX + b (avec Xs ≠ XD) la droite passant par les points S et D. En fait, la formule de cette droite est

donnée par l’équation suivante :SD

SDDS

SD

SD

XX

XYXYX

XX

YYY

−−

+−−

=

120

Figure 5-8 : Zone de recherche de forme triangulaire

– Déterminer les coordonnées du point δ :

Deux cas doivent être distingués lors du calcul des coordonnées du point δ (selon que le coefficient

directeur a est nul ou non). La propriété 5-1 fournit les coordonnées de δ lorsque a est non nul et la

propriété 5-3 lorsqu’il est nul.

Deux points se situent sur la droite Y à une distance β du point D. La propriété 5-1 calcule les

coordonnées de ces deux points.

Propriété 5-1 : Soit une droite Y = aX + b avec a ≠0 traversant les points S et D,

∃ ( )

)1²(2

²21 +

∆−++−=a

baXYaY DD

δ , ( )

)1²(2

²22 +

∆+++−=a

baXYaY DD

δ | Yδ1, Yδ2 sont

les ordonnées des points séparés par une distance β avec le point D, où

( )

( )

++++−

+−

++=∆

²2

²²²²²²1²4

²²4

bbaX

XaYaaa

baXYa

D

DD

DD

β .

Démonstration :

Soit une droite Y = aX+b, avec a ≠0, passant par les points S et D ; un point δ se situe à une distance,

d’un point D, égale à β si :

(XD - Xδ)² + (YD - Yδ)² =β ²

De plus le point δ a les coordonnées situées sur la droite Y donc : Yδ = aXδ + b.

121

On peut déduire, de ces deux équations, le système suivant :

( ) ( )

+==−+−

baXY

YYXX DD

δδ

δδ β ²²²

Pour trouver Yδ en fonction de YD et XD, il est nécessaire de résoudre l’équation suivante :

( ) ( ) 0221 =++++−++−+ b²baX²a²X²a²Ya²β²YbaXa²Y²Ya² DDDδDDδ

A partir de cette équation, on calcule ∆ avec la formule suivante :

( ) ( )( )²2²²²²²²1²4²4 2 bbaXXaYaaabaXYa DDDDD ++++−+−++=∆ β

∆ est ≥ 0 car les coordonnées du point δ se situent dans l’ensemble des réels.

Il ne reste plus qu’à déterminer les solutions de l’équation pour trouver les ordonnées possibles du

point δ :

( ))1²(2

²21 +

∆−++−=a

baXYaY DD

δ

( ))1²(2

²22 +

∆+++−=a

baXYaY DD

δ

�

D’après la propriété 5-1, il est possible de déduire la valeur de l’ordonnée de δ suivant la pente de la

droite Y avec a ≠0 et de la position des nœuds S et D. La propriété 5-2 donne la valeur de Yδ.

Propriété 5-2 : ∃ Yδ ∈{ }21, δδ YY | si XD>XS ∧ a>0 ∨ XD<XS ∧ a<0, Yδ >YD sinon Yδ <YD.

La propriété 5-2 définit dans le cas général l’ordonnée d’un point δ se situant à une distance β d’un

point D. Tout de même, deux cas particuliers sont possibles, lorsque la droite Y est horizontale c'est-à-

dire ∀X, Y = b et lorsque la droite Y est verticale c'est-à-dire que ∀Y, X = b. La propriété 5-3 donne

l’abscisse du point δ pour une droite Y horizontale et la propriété 5-4 donne l’ordonnée du point δ pour

une droite Y verticale.

Propriété 5-3 : Soit une droite Y =b passant par les points distincts S et D, ∃ Xδ1 =XD -β et

Xδ2 =XD +β | Xδ1, Xδ2 qui sont les abscisses des points avec une distance β à D. Si XD >XS ⇒

Xδ =XD +β sinon si XD <XS ⇒ Xδ =XD -β

122

Propriété 5-4 : Soit une droite X=b passant par les points distincts S et D, si YD >YS ⇒

Yδ =YD +β, sinon si YD <YS ⇒ Yδ =YD -β

Le théorème 5-1 regroupe les propriétés 5-2, 5-3 et 5-4 pour donner les coordonnées d’un point δ se

situant à une distance β du point D.

Théorème 5-1 : Soit deux points distincts S et D, un point δ situé sur la droite Y = aX + b à une

distance β de D a les coordonnées (Xδ, Yδ) suivantes : si a ≠0 et XD ≠XS : a

bYX

−= δ

δ et Yδ

(donnée par la propriété 5-2) sinon si a = 0 Xδ (donnée par la propriété 5-3) et Yδ =b sinon

Xδ = XS et Yδ (donnée par la propriété 5-4).

– Déterminer les coordonnées des points C et C’ :

Pour plus de lisibilité, nous différencions le cas où Y est une droite verticale des deux autres cas (cas

général et cas où a = 0). La propriété 5-5 donne les coordonnées des points C et C’ dans le cas d’une

droite Y verticale et la propriété 5-6 retourne les coordonnées des points C et C’ dans les deux autres

cas.

Propriété 5-5 : Soit une droite X =b passant par les points S et D, le point C a les coordonnées :

αδδ tanSXXC += YC = Yδ

Le point C’ a les coordonnées :

αδδ tan' SXXC −= YC ’ = Yδ

avec ( ) ( ) βδ +−+−= 22SDSD YYXXS (Sδ est la distance séparant S de δ) et

−=SD

XX SDarccosθ .

Propriété 5-6 : Soit une droite Y = aX + b passant par les points S et D, le point C a les

coordonnées suivantes :

+

≥−=

sinon tantan

0a si tantan

θαδθαδ

δ

δ

SX

SXXC

θαδδ costanSYYC +=

123

Le point C’ a les coordonnées :

−

≥+=

sinon tantan

0a si tantan ' θαδ

θαδ

δ

δ

SX

SXXC

θαδδ costan' SYYC −=

A la réception d’une requête, chaque nœud du réseau peut déterminer la zone de recherche en

calculant les coordonnées des points C et C’ grâce à la propriété 5-5 et à la propriété 5-6. Après qu’il

ait calculé la zone de recherche, il doit pouvoir déterminer s’il se situe à l’intérieur de cette zone. Un

nœud peut transmette un paquet RREQ si ses coordonnées se situent entre les droites SC, SC’ and CC’.

Cette zone est notée SCC’. Cette fois encore, nous différencions le cas où les nœuds S et D ont la

même abscisse des deux autres cas. Le théorème 5-2 donne les conditions à respecter pour qu’un nœud

se situe dans la zone de recherche de S et D avec XS =XD. Le théorème 5-3 fournit les conditions à

respecter pour qu’un nœud soit dans la zone de recherche dans les deux autres cas.

Théorème 5-2 : Soit un nœud source S et un nœud destination D distincts avec XS =XD, un nœud

avec les coordonnées (X, Y) est situé dans SCC’ si ses coordonnées respectent les conditions

suivantes :

Si YD > YS alors VRAIYYbXaYbXaY C =≤∧+≥∧+≥ )()()( 2211

Sinon si YD <YS alors VRAIYYbXaYbXaY C =≥∧+≤∧+≤ )()()( 2211

avec SC

SC

XX

YYa

−−

=1 , SC

SCCS

XX

XYXYb

−−

=1 et SC

SC

XX

YYa

−−

='

'2 ,

SC

SCCS

XX

XYXYb

−−

='

''2

Théorème 5-3 : Soit un nœud source S et un nœud destination D distincts avec une droite

Y = aX + b, un nœud avec les coordonnées (X, Y) se situe dans SCC’ s’il respecte les trois

conditions suivantes :

En fonction de la droite SC, il est correctement positionné si :

( ) ( )( ) ( )( ) ( )

+≤<∧>+≥

<∧=≤>∧=≥

sinon

00 si

si

si

11

111

bXaY

aabXaY

XXXXXX

XXXXXX

SDSCC

SDSCC

En fonction de la droite SC’, il est correctement situé si :

124

( ) ( )( ) ( )( ) ( )

+≥<∧>+≤

<∧=≤>∧=≥

sinon

00 si

si

si

22

222

''

''

bXaY

aabXaY

XXXXXX

XXXXXX

SDSCC

SDSCC

En fonction de la droite CC’:

Quand XD >XS :

+≥>+≤

=≤

sinon

0 si

si

33

33

'

bXaY

abXaY

XXXX CCC

avec '

'3

CC

CC

XX

YYa

−−= and

'

''3

CC

CCCC

XX

XYXYb

−−=

Quand XD < XS :

+≤>+≥

=≥

sinon

0 si

si

33

33

'

bXaY

abXaY

XXXX CCC

Le théorème 5-2 vérifie uniquement qu’un nœud est bien situé entre les axes de la zone de recherche.

Du fait de son évidence, une démonstration de ce théorème n’est pas donnée.

5.2.2 Forme géométrique en cerf-volant

La deuxième forme géométrique utilisée dans ce chapitre pour diminuer l’espace de recherche est une

forme en cerf-volant. Contrairement à celle utilisée dans la première partie, cette forme est bien plus

effilée que la première réduisant d’autant le nombre de requêtes échangées par les nœuds. En effet, il

est nécessaire d’avoir un angle important à l’extrémité de la source car il faut toucher un nombre de

nœuds important. Une fois au centre (les nœuds se trouvant à la moitié de la distance), la réduction de

l’espace vers la destination est compréhensible. Plus les nœuds sont proches de la destination, plus ils

peuvent être précis pour atteindre la destination. Une telle forme géographique est représentée sur la

figure 5-9. Lors de la recherche d’une route le nœud source propose deux angles α et β. La droite,

passant par le nœud source S et le nœud destination D, forme un axe de symétrie pour cette forme

géographique.

125

Figure 5-9 : Zone de recherche en forme de cerf-volant

Par la suite, nous limitons les angles α et β à l’intervalle ]0, 90°[. Nous faisons une telle limitation car

l’utilisation d’angles plus grands rend la zone de recherche trop proche de celle d’AODV. De fait, si

les zones de recherche sont comparables, il est plus judicieux d’utiliser directement le protocole

AODV. Le repère cartésien sur lequel est basé les coordonnées GPS est noté R et il a une base b

composé des vecteurs ir

et jr

. Pour simplifier les calculs permettant de déterminer si un nœud se

situe dans l’espace de recherche, nous changeons le repère cartésien et le notons R’. R’ est un repère

cartésien d’origine S et de base ( )vubrr

,'= . Le vecteur ur

(respectivement vr

) forme un angle θ avec

ir

(respectivement jr

). Le vecteur ur

est un vecteur unitaire d’origine S. Il possède le même sens et la

même direction que le vecteur SD. Le vecteur vr

est orthogonal au vecteur ur

. Par conséquent, la

base b’ est une base orthonormée. Le repère R’ est défini par la propriété 5-7 en fonction du repère R.

Propriété 5-7 : Soit un repère cartésien ( )jiRrr

,,0= , il existe un repère cartésien ( )vuSRrr

,,'=

avec jYiXOS SS

rr+= , jiu

rrr sin cos θθ += et jiv

rrr cos sin θθ +−= où �,i uθ =

r r.

La valeur de θ évolue suivant le positionnement du nœud source et destination dans le plan. Pour

déterminer mathématiquement les frontières de la zone de recherche et ainsi pouvoir déterminer si un

nœud se trouve à l’intérieur de cette zone, il est nécessaire d’obtenir une valeur de θ. La propriété 5-8

exprime cette valeur en degrés.

Propriété 5-8 : uirr

,=θ prend différentes valeurs suivant le positionnement des nœuds

source et destination. En effet, le vecteur SD est colinéaire à ur

.

ir

jr

vr

ur

126

( ) ( )

( ) ( )

( ) ( )

−−

<∧≤

−+

>∧<

−−

>∧≥

−

=

sinon arccos360

sisinon arccos180

sisinon arccos180

si arccos

SD

XX

YYXXSD

XX

YYXXSD

XX

YYXXSD

XX

SD

SDSDSD

SDSDSD

SDSDSD

θ

avec ( ) ( )22SDSD YYXXSD −+−=

Les coordonnées GPS des nœuds se situent dans le repère R. Un nœud doit par conséquent pouvoir

déduire de son repère initial R, ses coordonnées dans le repère R’. Chaque nœud recevant une requête

doit réaliser la même opération pour les coordonnées du nœud source et destination. La propriété 5-9

permet d’exprimer les coordonnées d’un point quelconque M dans le repère R’.

Propriété 5-9 : Soit un point M avec les coordonnées (X, Y) dans le repère R, il a les

coordonnées (X’, Y’) dans le repère R’ telles que :

( ) ( ) θθ sincos' SS YYXXX −+−=

( ) ( ) θθ cossin' SS YYXXY −+−=

Démonstration :

Soit deux repères orthonormés R=(0,b) avec b=(ir

, jr

) et R’=(S,b’) avec b’=(ur

, vr

). D’après la

propriété 5-7, jYiXOS SS

rr+= , jiu

rrr sin cos θθ += et jiv

rrr cos sin θθ +−= , la matrice de

changement de base (notée P) de la base b à la base b’ est donnée par la formule suivante :

−=

θθθθ

cossin

sincosP

Soit un point M quelconque dans un R-espace vectoriel :

127

SMOSOM +=

L’expression de cette égalité dans la base b est la suivante :

avec (X’, Y’) les coordonnées du point M dans R’.

++=−+=

⇒θθ

θθcos'sin'

sin'cos'

YXYY

YXXX

S

S

Pour trouver X’ et Y’ suivant X et Y, le système suivant est résolu :

+=−

−=−

θθθθθθθθθθ

cossin'sin'sinsin

cossin'cos'coscos2

2

YXYY

YXXX

S

S

( ) θθθθθθ sinsincoscossincos' 22SS YYXXX −+−=+⇒

Donc ( ) ( ) θθ sincos' SS YYXXX −+−=

De la même manière :

+=−

+−=+−

θθθθθθθθθθ

2

2

cos'cossin'coscos

sin'cossin'sinsin

YXYY

YXXX

S

S

Donc ( ) ( ) θθ cossin' SS YYXXY −+−=

�

La figure dans R’ a un axe de symétrie qui est l’axe des abscisses. Par conséquent, tout point dans

l’espace SCD a son symétrique dans l’espace SC’D. Un point se situe dans l’espace SCDC’ s’il est

dans SCD ou si son symétrique, suivant l’axe des abscisses, est dans SCD. Déterminer les

coordonnées du point C permet de déterminer l’espace SCD. Pour déterminer les coordonnées du

point C, il est nécessaire de déterminer les coordonnées du point δ. En effet, δ est la projection

orthogonale de C sur l’axe des abscisses. Donc ukSr=δ avec k∈R (ensemble des réels). Le

lemme 5-1 permet de déterminer les coordonnées du point δ.

−+

=

'

'

cossin

sincos

Y

X

Y

X

Y

X

S

S

θθθθ

128

Lemme 5-1 : δ a les coordonnées suivantes dans R’ :

0' ,tantan

tan'' =

+×= δδ βα

βYXX D

Démonstration :

DSSD δδ +=

βαβδ

βαδβδ

βδαδ

tantan

tan

tantantan

tantan

+⋅=⇒

⋅=⋅+⋅⇒

⋅=⋅

SDS

SDSS

DS

�

A partir du lemme 5-1, les coordonnées du point C dans R’ peuvent être facilement déduites. Le point

C a les coordonnées suivantes : X’ C = X’δ, Y’ C = X’δ⋅tanα

En connaissant les coordonnées du point C, chaque nœud du réseau peut ainsi déterminer la partie

SCD de la zone de recherche. A partir de cela, un nœud doit pouvoir savoir s’il se situe dans cette zone

ou non. Pour déterminer si un nœud quelconque se situe dans la zone de recherche, nous définissons

un endomorphisme retournant son symétrique par rapport à l’axe des abscisses. Nous appelons F cet

endomorphisme d’un R-espace vectoriel E. F est défini par :

vxux

E

vxuxX

EFrrrr

2121

:

−→→

+=

Un nœud peut propager une requête s’il se situe dans l’espace de recherche SCDC’. Par conséquent,

un nœud M quelconque est dans cet espace s’il se trouve dans SCD ou son symétrique est dans SCD.

Un nœud M de coordonnées (X’, Y’) dans R’ est dans SCD si ses coordonnées respectent le système

suivant :

+≤+≤

≥

22

11

''

''

0'

bXaY

bXaY

Y (5-1)

où SC

SC

XX

YYa

''

''1 −

−= , SC

SCCS

XX

XYXYb

''

''''1 −

−= ,

DC

DC

XX

YYa

''

''2 −

−= ,

DC

DCCD

XX

XYXYb

''

''''2 −

−= .

129

Le théorème 5-4 permet de déterminer si un nœud quelconque se situe dans l’espace de recherche. Si

tel est le cas, ce nœud peut relayer les informations de routage.

Théorème 5-4 : Un nœud M de coordonnées (X’, Y’) dans R’ est dans l’espace de recherche si

X’, Y’ respecte l’équation (5-1) ou ( )SMF respecte l’équation (5-1).

5.2.3 Protocole de découverte de route

Le protocole que nous proposons est basé sur le protocole AODV. Son fonctionnement en est très

proche. A la différence du protocole AODV, un nœud vérifie s’il est situé dans la zone de recherche

avant de transmettre un paquet RREQ.

Lorsqu’un nœud source a besoin de créer une route vers un nœud destination, il détermine en premier

lieu sa position (cf. §5.1). Si aucune information de localisation ne lui parvient dans un certain laps de

temps, il conclut que la destination ne peut pas être localisée à travers le réseau à backbone. Dans un

tel cas, la source tente d’établir une route avec la destination en utilisant le protocole AODV c'est-à-

dire que la source diffuse une requête RREQ à l’ensemble des nœuds du réseau. Si le nœud source S a

déterminé les coordonnées (XD, YD) de la destination D, il crée une requête RREQ. La requête RREQ,

transmise par notre protocole, est différente de celle d’AODV. Elle contient des champs

supplémentaires qui sont les suivant : coordonnées du nœud source, coordonnées du nœud destination,

valeur de α, valeur de β (dans le cas d’une forme en cerf-volant).

Quand un nœud intermédiaire I reçoit une requête RREQ (figure 5-10), il calcule l’espace de

recherche. S’il détermine qu’il se situe à l’intérieur de cet espace (avec le théorème 5-2 ou le

théorème 5-3 pour une forme triangulaire, ou le théorème 5-4 pour une forme en cerf-volant) il

transmet la requête RREQ. Un nœud ayant déjà reçu une requête RREQ supprime la requête.

Notre protocole réduit le nombre de nœuds qui transmettent des informations de routage. De fait, il est

possible qu’aucune route ne soit trouvée s’il en existe une. Pour éviter un tel cas, un temporisateur est

positionné par la source lors de l’envoi de la requête RREQ. A l’expiration du temporisateur, le nœud

source peut réaliser une nouvelle tentative ou utiliser le protocole AODV. En fait, les valeurs de α ou

β peuvent être choisies pour privilégier le coût ou la probabilité d’obtention d’une route. Plus α ou β

sont élevés, plus l’espace de recherche est grand (et plus le nombre d’informations de routage est

important).

130

Figure 5-10 : Organigramme utilisé par un nœud intermédiaire

5.2.4 Complexité en messages

Dans cette section, nous analysons le nombre d’informations de routage échangées lors de la création

d’une route par notre protocole de routage, suivant qu’il utilise une zone de recherche triangulaire ou

en forme de cerf-volant. Nous étudions la complexité de notre protocole dans le pire des cas et dans le

cas moyen.

Dans le pire des cas, notre protocole possède la même complexité que le protocole AODV. En effet,

lorsque la totalité des nœuds du réseau sont dans la zone de recherche, ils transmettent chacun, une

seule fois, un paquet RREQ. Par conséquent, pour N nœuds dans le réseau, le nombre de messages

transmis est de N-1 car seule la destination n’en transmet pas.

Le nombre moyen d’informations de routage échangées lors de la recherche d’une route est fonction

du nombre moyen de nœuds transmettant ces informations. Pour cela, nous supposons que N nœuds

sont uniformément répartis dans le réseau. Un nœud se trouve dans la zone de recherche de forme

DEBUT

RREQ reçu d’un nœud I ?

oui

non

Déjà reçu un RREQ ?

oui non

- Créer une

nouvelle route

dans la table des

chemins inverses

nss identique mais chemin

inverse plus court ?

Supprimer

la requête

- Mettre à jour l’entrée de la table des chemins inverses

correspondant à la destination

- Diffuser la requête

RREP reçu?

non

oui

une entrée dans la table de

routage pour la destination

ouinon

- Créer une nouvelle

entrée dans la table de

routage

- Mettre à jour l’entrée


Suis-je dans l’espace de

recherche ?

Supprimer

la requête

oui

nss plus récent ?

oui non

oui non

- Mettre à jour l’entrée de la

table des chemins inverses

- Supprimer la requête

non

- Transmettre le RREP au nœud précédent

contenu dans la table des chemins inverses

pour la destination

131

triangulaire SCC’ (respectivement de forme en cerf-volant SCDC’) si sa position est dans SCC’

(respectivement SCDC’). Nous notons AZR la surface faisant l’intersection entre la zone de recherche et

la surface globale du réseau. Pour une zone de recherche triangulaire (respectivement en forme de

cerf-volant) AZR = ASCC’ (respectivement AZR = ASCDC’).

La probabilité que la position d’un nœud quelconque M soit dans la zone de recherche est :

( )( )G

ZR

A

AZRMposP =∈

avec AG la surface globale du réseau.

Comme les nœuds source et destination sont toujours situés dans la zone de recherche, au moins deux

nœuds sont dans la zone de recherche. Le nombre moyen de nœuds situés dans la zone de recherche,

note K, est :

( ) ( ) 2(2 +∈⋅−= ZRMposPNK (5-2)

D’après l’équation (5-2), si les nœuds possèdent au moins un lien avec un autre nœud (différent de la

destination), le nombre de messages RREQ moyen échangé est égal à K-1.

5.2.5 Simulations


l’efficacité de notre protocole aux protocoles AODV et LAR (cf. §2.3.1). Notre protocole utilisant la

forme géométrique en triangle (respectivement en cerf-volant) est appelé protocole 1 (respectivement

protocole 2). L’angle α prend comme valeur par défaut 20°. Dans nos simulations, la valeur de l’angle

β du protocole 2 est la même que la valeur de l’angle α. La distance δ est toujours nulle quelque soit le

protocole.

Pour la réalisation de ces simulations, nous utilisons les mêmes hypothèses que celles utilisées dans le

paragraphe §5.1.1.3. Le réseau est composé d’un nombre variable de nœuds suivant la simulation

effectuée. Les nœuds se déplacent à 5m/s. Le rayon de couverture d’un nœud ad hoc est de 150mètres.

Les nœuds sont répartis dans une zone carrée de 1000m de côté. Ils utilisent pour se déplacer le

modèle RWP (cf. §1.4) avec un temps de pause de 200 secondes entre déplacements. Le débit du

réseau est de 2Mb/s. La simulation utilise un modèle de communication dans lequel la moitié des

nœuds communiquent avec l’autre moitié. La durée d’une simulation est de 500 secondes.

Dans un premier temps, nous comparons la réussite à déterminer une route pour chacun de ces

protocoles. Suivant le nombre de nœuds, le pourcentage de découverte de route évolue. Le protocole

AODV est le seul protocole capable dans ces simulations à pouvoir toujours retourner une route s’il en

existe une.

132

La figure 5-11 montre le comportement des 4 protocoles à déterminer une route. Lorsque le nombre de

nœuds est faible, l’ensemble des protocoles a des difficultés à trouver une route. Pour 10 et 30 nœuds

répartis dans le réseau, les nœuds sont bien trop dispersés pour qu’un nombre important de routes

soient trouvées. Dans ces deux scénarios, les protocoles 1 et 2 sont incapables de déterminer une route.

Le protocole LAR suit la progression du protocole AODV. Avec l’augmentation du nombre de nœuds,

le pourcentage de découverte d’une route croît. Le protocole AODV trouve toujours une route à partir

d’un nombre de nœuds égal à 50. Le protocole LAR fait très souvent de même. Toutefois, on peut

constater qu’à 150 et 200 nœuds, il possède un pourcentage très faible d’échec à l’obtention de routes.

Bien que ce protocole soit très proche d’AODV, il n’est pas fiable à 100%. Pour nos protocoles, le

pourcentage de découverte d’une route croît avec l’augmentation du nombre de nœuds. En effet, nos

protocoles sont efficaces dans des environnements denses. Le protocole 2 a un pourcentage d’échec

supérieur à notre protocole 1 à cause de sa plus petite zone de recherche. A partir de 150 nœuds, nos

protocoles trouvent quasiment toujours une route s’il en existe une.

Figure 5-11 : Pourcentage d’échec à la détermination d’une route en fonction du nombre de nœuds du

réseau.

La figure 5-12 montre l’évolution du pourcentage d’échec à la détermination d’une route en fonction

de la taille de la zone de recherche. On remarque qu’avec l’accroissement de l’angle α, le pourcentage

d’échec diminue plus vite. Ainsi pour α = 30°, le protocole 1 trouve toujours une route à partir de 100

nœuds. Le protocole 2, ayant une zone de recherche plus restreinte que celle du protocole 1, a toujours

plus de difficultés à trouver une route. Pour un angle α égal à 10°, l’angle est bien trop resserré pour

être efficace même dans des environnements denses.

0

20

40

60

80

100

120

10 30 50 75 100 150 200

Ech

ec à

tro

uver

une

route

(%

)

133

Figure 5-12 : Pourcentage d’échec à trouver une route suivant l’angle utilisé pour calculer la taille de

la zone de recherche.

Figure 5-13 : Nombre moyen de requêtes nécessaires à la découverte d’une route

Le pourcentage d’échec à déterminer une route étant différent pour nos protocoles, l’intérêt de

comparer le nombre de requêtes sur l’ensemble des simulations n’a que peu d’intérêt. Nous comparons,

par conséquent, le nombre moyen de requêtes requises à la détermination d’une connexion. La figure

5-13 donne le nombre moyen de requêtes par connexion pour l’ensemble des protocoles simulés. Le

protocole AODV possède un nombre moyen de requêtes assez important. Pour chaque découverte de

route, l’ensemble des nœuds du réseau (privé de la destination) relaient le paquet RREQ transmis par

la source. Ainsi pour une topologie de 100 nœuds, le nombre de requêtes nécessaires à la

détermination d’une route est de 99. Tout de même, ce nombre moyen est plus élevé, car il tend vers

130 pour 100 nœuds. En fait, il est possible que le protocole AODV échoue à trouver une route, lors

de la première tentative, dans un environnement plus ou moins chargé. En effet, les paquets RREQ

transmis peuvent subir des collisions. Du fait de leur diffusion, ces paquets ne sont pas retransmis.

Ainsi, le protocole AODV effectue, après un certain temps d’attente, une nouvelle tentative. Ce

constat accroît le nombre de requêtes du protocole AODV. Nos deux protocoles sont plus performants

0

20

40

60

80

100

120

10 30 50 75 100 150 200

0

50

100

150

200

250

300

350

10 30 50 75 100 150 200

AODV

Protocole 1

(alpha =20°)

Protocole 2

(alpha = 20°)

LAR

Nombre de nœuds

134

que le protocole LAR dans tous les scénarios. Le protocole 2 est particulièrement performant à cause

de sa zone de recherche très restreinte.

La figure 5-14 montre le nombre moyen de requêtes en fonction de la taille de la zone de recherche.

Le nombre moyen de requêtes croît avec la taille de la zone de recherche (dépend de l’angle α).

Quelque soit l’angle sélectionné (10, 20 ou 30°), nos deux protocoles génèrent moins de requêtes que

le protocole LAR. Avec l’accroissement de la densité du réseau, le nombre de requêtes croît. En effet,

plus la zone de recherche est grande, plus le nombre de nœuds qui relaient les paquets de routage est

important.

Figure 5-14 : Nombre moyen de requêtes par connexion en fonction de la taille de la zone de

recherche

5.2.5.1 Discussion

Le but premier d’un protocole de routage est de déterminer une route s’il en existe une. Nos deux

protocoles, bien qu’efficaces en termes de paquets de routage échangés, possèdent un taux d’échec

d’obtention de routes bien trop important. Utiliser un angle α initial plus important permet de pallier à

ce problème, mais ce n’est pas une solution. En effet, utiliser un angle α de départ plus grand fait

tendre le nombre de requêtes utilisées vers celui du protocole AODV.

Tout de même, les formes géométriques proposées sont efficaces dans des environnements denses.

Dans de tels environnements, une route est, quasiment toujours, trouvée. Les formes géométriques

sont bien adaptées à ces environnements, car elles centrent directement les paquets de routage vers la

destination.

Le protocole de routage proposé ne peut donc pas être employé efficacement dans les réseaux

MANETs. Il est nécessaire d’y apporter des modifications pour qu’il puisse déterminer une route

quelque soit la densité de l’environnement dans lequel les nœuds se situent.

0

10

20

30

40

50

60

10 30 50 75 100 150 200

135

5.3 Protocoles utilisant une recherche de parcours en

profondeur

Les protocoles, réduisant l’espace de recherche, diminuent le nombre d’informations de contrôle

nécessaire à la découverte d’une route. En effet, seulement les nœuds susceptibles de fournir une route

vers la destination transmettent des requêtes de création de route. Une réduction de l’espace de

recherche peut engendrer dans certains cas un échec lors de la découverte des routes même si une

route existe. Le but premier d’un protocole de routage est de trouver une route s’il en existe une. Les

résultats obtenus (cf. §5.2.5) montrent qu’avec un faible espace de recherche l’échec de trouver une

route est important.

Nous proposons dans ce chapitre deux protocoles de routage utilisant une recherche de parcours en

profondeur [ESP 07-3]. Le but d’une telle recherche est d’accroître la taille de la zone de recherche en

cas d’échec lors de la découverte d’une route. Un tel type de protocole permet ainsi d’optimiser le

nombre d’informations de routage, tout en assurant la découverte d’une route s’il en existe une. Le

protocole AODV utilise une recherche de parcours en largeur (cf. §2.1.2.1) c'est-à-dire qu’il réalise

une dissémination de l’information en largeur. Lorsqu’une route n’est pas trouvée lors d’une tentative,

il accroit le nombre de sauts qu’une requête RREQ peut atteindre. Nos deux protocoles sont différents

puisqu’ils proposent une dissémination de l’information en profondeur. Lors d’une tentative, si aucune

route n’est trouvée, le protocole accroît l’espace de recherche en largeur augmentant ainsi le taux de

réussite de découverte d’une route.

Le premier protocole est un protocole de routage optimal (il garantit de découvrir une route s’il en

existe une). Ce protocole permet de diminuer le nombre d’informations de routage nécessaires à la

découverte d’une route dans bien des cas.

Le deuxième protocole de routage est un protocole optimisant le nombre d’informations de routage.

Ce protocole est parfois dans l’incapacité de retourner une route, même s’il en existe une. Mais un tel

cas est particulièrement rare voir inexistant.

Des simulations permettent de comparer ces deux protocoles avec le protocole AODV utilisant une

recherche de parcours en largeur et le protocole AODV lui-même. Ces comparaisons sont réalisées

suivant plusieurs critères : le nombre d’informations de routage échangées, le nombre de tentatives

pour trouver une route et le taux de réussite à déterminer une route.

5.3.1 Propriétés de la zone de recherche

Le protocole AODV, avec un parcours de recherche en largeur, limite la dissémination des

informations de contrôle en profondeur. En supposant que le nœud source connait la position de la

destination, il peut déterminer la distance le séparant de la destination. Si la totalité des nœuds du

réseau utilisent le même rayon de couverture, le nombre de sauts maximal, noté NHmax, séparant la

source de la destination est connu. A partir de NHmax, le protocole AODV (utilisant un parcours de

136

recherche en largeur) peut être amélioré. Pour cela, le nœud source doit initier, pour joindre la

destination, l’envoi d’un paquet RREQ avec un TTL égal à NHmax.

Le protocole AODV dissémine l’information à la totalité des nœuds présents dans un rayon équivalent

à un certain nombre de sauts. Par conséquent, la dissémination de cette information est propagée à des

nœuds situés à l’opposé de la position de la destination. Ces nœuds interviennent rarement dans la

découverte d’une route. Pour être efficace, le protocole doit envoyer les informations de routage

uniquement dans la direction de la destination.

Dans la suite de cette section, l’espace de recherche est restreint à la forme représentée par la figure

5-15. L’espace de recherche est fonction de deux paramètres variables α et δ. Lorsqu’une tentative

échoue à trouver une route, ces paramètres sont accrus pour augmenter la taille de l’espace de

recherche. Seuls les nœuds présents dans l’espace de recherche sont susceptibles de transmettre une

requête RREQ de découverte des routes.

Figure 5-15 : Zone de recherche avec un angle α aigu (a) et un angle α obtus (b)

Les agrandissements successifs de l’espace de recherche influent sur le délai d’obtention d’une route.

Pour que le protocole soit suffisamment réactif, les paramètres α et δ doivent croître rapidement entre

deux tentatives. Ils suivent donc une croissance exponentielle.

Pour déterminer une valeur de α ∈ ]0,180°], lors de la ième tentative, nous utilisons la formule suivante :

°≥°=

−

−

180 si 180 1

1

starti

starti

iαθ

αθα (5-3)

avec αStart la valeur de α lors de la 1ère tentative (c'est-à-dire pour i=1) et θ un facteur qui permet

d’accroître exponentiellement la valeur de α.

Lorsque α = 180°, notre algorithme doit explorer la totalité du réseau, c'est-à-dire qu’il possède la

même zone de recherche que le protocole AODV. De fait, la valeur de δ dépend, intrinsèquement, de

la valeur du paramètre α. Pour calculer la valeur de δ, nous supposons que le réseau a une distance

137

maximale égale à Dmax et que les nœuds possèdent le même rayon de couverture R. La valeur de δ

varie de façon exponentielle avec le nombre de tentatives nécessaires à l’obtention d’une route. Lors

de la ième tentative, δi suit la progression donnée par l’équation suivante :

°<

=−

sinon

180 si

max

1

D

αRi

i

γδ (5-4)

avec δ1=δStart et γ ∈ N (ensemble des entiers naturels).

Pour conserver la compatibilité avec le protocole IP, il est nécessaire de définir un TTL dans l’entête

des paquets IP. Le TTL n’est pas le paramètre limitant la zone de recherche. En effet, seuls les nœuds

situés dans la zone de recherche transmettent les requêtes RREQ. Nous limitons le TTL avec le

nombre de nœuds maximum sur la droite SD si α est un angle aigu (α∈[0, 90°[), sinon le TTL est égal

à la valeur DIAMETRE_RESEAU (nombre maximal de sauts possible sur le réseau).

Pour déterminer la valeur du TTL, il est nécessaire de calculer le nombre de sauts maximal sur une

distance iSDDist δ+= . Dist représente la distance maximale, lors de la ième tentative, sur la droite

SD lorsque α ∈ [0, 90°[. Le nombre de sauts, lors de la ième tentative, est borné par l’équation suivante :

12+×

≤≤

R

DistNH

R

Dist (5-5)

Démonstration :

La borne inférieure (le cas le plus favorable) est facilement obtenue. Elle correspond au cas où chaque

nœud du chemin est au bord de la zone de couverture du nœud précédent. Ainsi, deux nœuds du

chemin sont séparés par une distance égale au rayon de la zone de couverture R. De fait, le nombre de

sauts minimal sur un tel chemin est égal à

R

Dist.

Le calcul de la borne supérieure représente le pire cas d’un chemin P=<v1, v2, v3, …, vn>. Pour obtenir

le nombre de sauts maximal sur une distance Dist, il est nécessaire d’obtenir la distance minimale que

peut avoir un sous-chemin P’=<vi,vi+1,vi+2>. La distance minimale d’un tel sous-chemin est

représentée quand la distance séparant vi de vi+1 est égale à ε et la distance séparant vi de vi+2 est égale

à R + ε. Ainsi, le nœud vi+1 doit relayer le paquet de vi pour qu’il atteigne vi+2. Par conséquent, le

nombre de saut est égal à 2 lorsque ε→0. Le nombre de sauts maximum sur une distance Dist est donc

majoré par 12+×

R

Dist .

Ainsi, le nombre de sauts est borné par : 12+×

≤≤

R

DistNH

R

Dist.

�

138

Lorsque α∈[0, 90°[, nous majorons TTLi avec la formule suivante 12+×

=R

DistTTLi . Dans bien

des cas, cette valeur est bien trop élevée car elle représente, dans le pire des cas, le nombre de sauts

présents sur une distance égale à Dist. Il est impossible de déterminer un nombre de sauts plus précis

sans connaître la topologie du réseau.

Le TTL sert également à définir le temps d’attente de la source, noté TEMPS_TRAVERSE, pour

détecter un éventuel échec lors de la recherche d’une route. Le temps d’attente est donné par la

formule suivante :

TEMPS_TRAVERSE = 2 × (TTL + TEMPS_ATTENTE) × TEMPS_ NŒUD (5-6)

avec TEMPS_ATTENTE un paramètre qui augmente le temps d’échéance en cas de congestion sur un

nœud, et TEMPS_NOEUD une estimation du temps moyen de la traversée d’un saut par un paquet.

5.3.2 Protocole optimal

Le premier protocole proposé est optimal (il retourne une route s’il en existe une). Ce protocole réduit

en moyenne le nombre de requêtes nécessaires à l’obtention d’une route. Il est basé sur le protocole

AODV. De fait, il utilise deux tables (une table des chemins inverses, une table de routage) contenant

les mêmes champs que le protocole AODV.

Les champs de la requête RREQ par contre diffèrent de ceux utilisés par le protocole AODV. Les

différents champs sont : adresse source, numéro de séquence source, position du nœud source, adresse

de destination, numéro de séquence de destination, position du nœud destination, identifiant de requête,

nombre de sauts, valeur de α et la valeur de δ. La surcharge rajoutée dans l’entête des requêtes est,

donc, faible.

Notre protocole diffère de AODV par sa gestion de l’espace de recherche. Lors d’une tentative si la

source ne trouve pas de route, elle agrandit cette zone en augmentant la valeur des paramètres α et δ

(cf. équation (5-3) et équation (5-4)). Le paramètre α est le paramètre limitant. Au delà de 180°, le

nœud source interrompt sa recherche. Si aucune route n’a été trouvée, alors aucune route n’existe. A

partir de la valeur de αSTART, le nombre maximal de tentatives réalisées par le protocole, (noté z), est

donné par l’équation suivante :

( ) ( )ln 180 ln1

lnSTARTz

αθ

− = +

(5-7)

Démonstration :

On désire trouver un entier z tel que la valeur de αz est égale à 180°. De fait,

139

( ) ( ) ( )

( ) ( )( ) 1

ln

ln180ln

180lnln1ln

180

180

1

1

1

+

−=

=⋅−=

=

==

−

−

−

θα

αθθ

αθ

αθα

START

START

z

START

z

STARTz

z

z

z

�

Le protocole est découpé en deux phases. La première phase consiste en la découverte des routes. La

deuxième consiste en leur maintenance.

5.3.2.1 Phase de découverte des routes

La figure 5-16 donne l’organigramme utilisé par le nœud source pour la découverte d’une route. Si

elle ne possède pas déjà une route, elle transmet une requête RREQ après avoir initialisé ces champs.

Pour cela, la source insère dans la requête ses coordonnées géographiques ainsi que les coordonnées

de la destination. Elle initialise le nombre de sauts, la valeur de α à αSTART et enfin la valeur de δ à

δSTART. Elle génère un nouveau numéro de séquence source et un nouvel identifiant de requête et met à

jour la requête en conséquence. En fonction de la distance la séparant de la destination et de la valeur

de δ, elle calcule le temps d’attente nécessaire à une nouvelle tentative (cf. équation (5-6)). Elle

initialise le temporisateur Trep à cette valeur et le déclenche lors de la diffusion de la requête. Elle se

met ensuite en attente d’une réponse RREP. Si une telle réponse arrive avant l’échéance du

temporisateur alors une route est trouvée et elle peut commencer à émettre ses données. Par contre, si

le temporisateur arrive à échéance aucune route n’a été trouvée. Dans un tel cas, elle accroît la zone

recherche en augmentant la valeur de α (cf. équation (5-3)) et δ (cf. équation (5-4)). Elle génère un

nouveau numéro de séquence et un nouvel identifiant de requête car cette recherche est totalement

indépendante de la précédente. Ainsi, les nœuds intermédiaires ayant déjà reçu une requête RREQ

d’une tentative précédente peuvent traiter cette requête car son identifiant est différent. Lorsque α

atteint 180°, la requête explore l’ensemble de l’espace de recherche. Si aucune route n’est trouvée,

alors aucune route entre la source et la destination n’existe. Le nœud source prévient la couche

supérieure de son échec.

140



L’algorithme utilisé par un nœud intermédiaire est identique à l’algorithme proposé sur la figure 5-10

(cf. §5.2.3). Lorsqu’un nœud intermédiaire reçoit une requête RREQ, il met à jour sa table des

chemins inverses pour la destination ou crée une entrée si aucune n’existe. La table des chemins

inverses est mise à jour seulement si le numéro de séquence source de la requête reçue est plus récent

ou qu’il est identique mais que le nombre de sauts le séparant de la source est plus faible. Ensuite, il

vérifie s’il a déjà reçu la requête. Si une requête a déjà été reçue (c'est-à-dire qu’il a déjà reçu une

requête RREQ avec le même identifiant de requête) alors il la supprime. Dans le cas inverse, il

détermine s’il se situe dans la zone de recherche. Si tel est le cas, il transmet cette requête sinon il l’a

supprime.


DEBUT

- Créer un RREQ

- Générer un nouvel

identifiant de requête




de la requête

- Initialiser i

- Initialiser temporisateur

Trep=TEMPS_TRAVERSE


- Déclencher Trep

oui

non

Trep expiré?non

oui

- i++

- Calculer αi

- Calculer δi

- Calculer le TTL

- Créer un RREQ




identifiant de requête

- Mettre à jour la requête


Informer la couche

supérieure

Traitement des

données

une route?

oui non

RREP reçu ?

RERR reçu?

Transfert des

données

oui non

i > NbreMaximalTentativeoui

141

A la réception d’un paquet RREP, le nœud intermédiaire met à jour sa table de routage si le numéro de

séquence de la destination est plus récent que celui contenu dans sa table de routage ou s’il est

identique mais avec un nombre de sauts plus faible. Il interroge ensuite sa table des chemins inverses

pour savoir vers quel nœud il doit envoyer le paquet RREP, pour qu’elle joigne le nœud source.


La phase de maintenance reste très proche de celle utilisée par le protocole AODV. Lorsqu’un nœud

détecte la rupture d’un lien, il émet à l’ensemble des nœuds sources, dont la route vers un nœud

destination passe par lui, un paquet RERR. A la réception d’un tel paquet, un nœud source recrée une

route en utilisant la phase de découverte (cf. §5.3.2.1).

Si le nœud source utilise notre protocole à localisation (cf. §5.1.1), il connaît une position relativement

récente de la destination pour recréer une route sans rechercher ses coordonnées géographiques. Par

contre, si un autre protocole de localisation est utilisé, la destination peut envoyer périodiquement sa

position (ainsi que sa vitesse de déplacement, sa direction…) au nœud source dans un paquet de

déplacement. Un tel paquet peut prendre la route contenue dans la table des chemins inverses pour

rejoindre le nœud source.

5.3.2.3 Complexité en termes de message

Dans cette partie, nous analysons la complexité en nombre de messages transmis par notre protocole.

La complexité est calculée dans deux cas. Le premier cas consiste au pire cas, c’est-à-dire le nombre

maximal de messages échangés par les nœuds. Le second cas donne le nombre moyen de messages

échangés par les nœuds du réseau avec notre protocole. Dans ces deux cas, notre protocole de routage

est fonction du nombre de nœuds présent dans la zone de recherche.

Dans le pire cas, le calcul du nombre de messages échangés par les nœuds lors d’une recherche de

route se base sur le nombre maximal de tentatives possibles. En effet, plus le nombre de tentatives est

important plus le nombre de requêtes échangées l’est également. Le nombre maximal de tentatives est

noté z (cf. équation (5-7)).

Par la suite nous supposons que le réseau possède N nœuds. Dans le pire des cas, lors des z-1

tentatives aucune route n’est trouvée. Une route est trouvée lors de la zème tentative. Pour qu’une route

ne soit pas trouvée, il est nécessaire que la destination ne reçoive aucune requête RREQ. Pour cela, il

faut qu’au moins un nœud (outre la destination) soit en dehors de la zone de recherche. Dans le pire

cas, ce nœud est le seul à pouvoir créer une route avec la destination. Par conséquent dans les z-1

premières tentatives, deux nœuds ne transmettent jamais de requête la destination et le nœud

empêchant la découverte d’une route. A partir d’un tel constat, le calcul du nombre de messages dans

le pire cas est donné par l’équation suivante :

( ) 121

+−×≤ NzNM PireCas (5-8)

Dans le deuxième cas, nous calculons le nombre de messages maximum lorsque N nœuds sont

142

uniformément répartis dans le réseau. Nous notons SAi la zone de recherche lors de la ième tentative. Un

nœud est situé dans SAi si sa position se trouve dans la zone de recherche. La probabilité P(i × α)

qu’un nœud M soit situé dans la zone de recherche lors de la ième tentative est :

( ) ( )( )G

SA

i A

ASAMposPiP i=∈=×α (5-9)

où AG la taille globale du réseau et iSAA l’intersection entre la zone de recherche de la ième tentative et

la zone globale du réseau.

La source et la destination sont toujours dans SA, par conséquent il y a toujours au moins deux nœuds

dans la zone de recherche. En moyenne le nombre de nœuds dans SAi, noté Ki, est :

( ) ( ) 22 +×⋅−= αiPNKi (5-10)

Comme la destination ne transmet jamais de paquet RREQ, lors de chaque tentative Ki-1 paquets sont

transmis. Le nombre maximal de messages échangés par les nœuds dans le pire cas lorsque les nœuds

sont uniformément répartis est :

( ) ( )( )∑=

+×⋅−=z

i

onUniformeDistributi iPNNM1

1 12 α (5-11)

5.3.3 Protocole conciliant taux de découverte des routes et

dissémination d’informations de routage

Nous proposons dans cette partie un protocole non optimal à la différence du premier protocole. Ce

protocole allie parfaitement un faible nombre d’informations de routage nécessaires à la découverte

d’une route et taux d’obtention d’une route. Lors de l’accroissement de la zone de recherche, seuls les

nœuds n’ayant pas reçu de requête durant les tentatives précédentes peuvent propager les requêtes

RREQ (s’ils sont situés dans la zone de recherche). Une route peut ne pas être découverte lorsqu’un

nœud ayant une route avec la destination ne peut être joint uniquement par un nœud dans la zone de

recherche d’une tentative précédente (figure 5-17). Dans cet exemple, un nœud source S souhaite

obtenir une route pour le nœud destination D. Lors de la première tentative (formalisé par la zone de

recherche 1) seul 2 nœuds (nœuds B et C) transmettent la requête RREQ car ils sont situés dans la

zone de recherche. Lors de la deuxième tentative (zone de recherche 2) aucun nœud ne fait la jointure

avec le nœud A qui est le seul nœud à pouvoir créer une route avec la destination. En effet, les deux

nœuds dans la zone de recherche 1 ne peuvent pas émettre la requête reçue lors de la deuxième

tentative puisqu’ils en ont déjà émis une lors de la première. Le nœud A ne sera par conséquent jamais

averti de la demande d’une route pour joindre D. L’obtention d’une route échouera quelque soit le

nombre de tentatives.

143

Figure 5-17 : Echec de la découverte d’une route alors qu’une existe.

Ce protocole est basé sur le protocole AODV. Par conséquent, il utilise deux tables (une table des

chemins inverses et une table de routage) contenant les mêmes champs que le protocole AODV.

Comme pour le protocole optimal, les champs de la requête RREQ diffèrent de ceux utilisés par le

protocole AODV. Les différents champs sont : adresse source, numéro de séquence source, position

du nœud source, adresse de destination, numéro de séquence de destination, position du nœud

destination, identifiant de requête, nombre de sauts, valeur de α et valeur de δ.

Ce protocole est divisé en deux phases. La première est la phase de découverte de route, alors que la

seconde est la phase de maintenance.

5.3.3.1 Phase de découverte des routes

L’algorithme utilisé par le nœud source est présenté sur la figure 5-18. Il diffère légèrement de

l’algorithme proposé pour le protocole optimal. En effet cette fois, les nœuds intermédiaires ne doivent

transmettre qu’une seule requête quelque soit la tentative. Lorsque le nœud source désire trouver une

route vers un nœud destination, ile crée une requête RREQ et génère un nouvel identifiant de requête

et un nouveau numéro de séquence. Quelque soit la tentative, le numéro de séquence source et

l’identifiant de requête restent inchangés. Il initialise ensuite les champs avec les valeurs suivantes :

nombre de sauts à 1, la valeur de α à αSTART et la valeur de δ à δSTART. Enfin elle arme le temporisateur

Trep, après avoir défini le temps d’attente nécessaire à une nouvelle tentative (cf. équation (5-6)). Si

un paquet RREP arrive avant l’échéance de Trep alors une route est trouvée. Sinon, il agrandit

l’espace de recherche la valeur de α (cf. équation (5-3)) et la valeur de δ (cf. équation (5-4)). Une

nouvelle requête RREQ est transmise en conservant le même identifiant de requête et le même numéro

de séquence source.

144



A la réception d’une requête RREQ, le nœud intermédiaire a le même fonctionnement qu’un nœud

intermédiaire du protocole optimal. Dans un premier temps, il compare les identifiants de requête

reçue avec l’identifiant de la requête. Si un des identifiants correspond à l’identifiant de la requête,

dans ce cas il l’a déjà reçu et la supprime après avoir mis à jour, si nécessaire, sa table des chemins

inverses. Dans le cas inverse, il vérifie qu’il se situe dans la zone de recherche et si tel est le cas il

diffuse la requête après avoir mis à jour sa table des chemins inverses. La grande différence avec le

protocole optimal est que l’identifiant de la requête change lors de chaque tentative. Ainsi, un nœud

intermédiaire ne traite qu’une seule requête RREQ quelque soit la tentative.


La phase de maintenance est identique à celle proposée par le protocole AODV. Lorsqu’un nœud

détecte la rupture d’un lien, il informe les nœuds sources, dont les communications passent par lui, des

145

nœuds destination dont la route est rompue. Pour cela, un paquet RERR est envoyé. A la réception

d’un paquet RERR, le nœud source recrée les routes si c’est nécessaire.

5.3.3.3 Complexité en termes de messages

Deux cas sont utilisés pour présenter la complexité en termes de messages échangés par les nœuds

présents dans le réseau. Ces nœuds utilisent le protocole présenté dans le paragraphe §5.3.3. Le

premier cas détermine le nombre de messages dans le pire des cas. Le deuxième cas détermine le

nombre de messages échangés dans le pire des cas lorsque les nœuds sont uniformément répartis dans

le réseau.

On suppose par la suite que N nœuds sont présents dans le réseau. Avec ce protocole, chaque nœud du

réseau (excepté la destination et la source) transmet une seule fois une requête RREQ. Par contre, le

nœud source transmet lors de chaque tentative une requête RREQ. Le nombre maximal de tentatives

est noté z (cf. équation (5-7)). La formule suivante donne le nombre de messages échangés dans le pire

cas :

zNNM PireCas +−= 22 (5-12)

Dans le cas d’une distribution uniforme des nœuds dans le réseau, les nœuds présents dans la zone de

recherche et qui peuvent transmettre le paquet RREQ, lors de la ième tentative, sont les nœuds présents

dans la zone de recherche de la ième tentative privée des nœuds présents dans la zone de recherche de la

i-1ème tentative. Nous notons iSA la surface SAi moins la surface SAi-1 (c'est-à-dire 1−∩= iii SASASA )

avec SA0 = 0. La probabilité qu’un nœud quelconque M n’ait transmis aucune requête et qu’il se situe

dans la ième zone de recherche est :

( ) ( )( )G

SAi

A

ASAMposPiP i=∈=×α (5-13)

Par conséquent lorsque les nœuds sont uniformément répartis dans le réseau, le nombre de messages

échangés est le suivant :

( ) ( )( ) ( ) ( ) zzPNiPNNMz

i

onUniformeDistributi +×⋅−=+×⋅−=∑=

αα 2121

2 (5-14)

5.3.4 Simulations


l’efficacité de nos protocoles avec le protocole AODV avec ou sans recherche de parcours en largeur.

Nos protocoles sont le protocole optimal (cf. §5.3.2) et le protocole sous-optimal (cf. §5.3.3). Nos

deux protocoles utilisent un angle α initial égal à 20°. Pour le protocole AODV avec parcours en

largeur, l’incrémentation du TTL est de 2 à chaque nouvelle tentative.

146

Le réseau est composé d’un nombre variable de nœuds suivant la simulation effectuée. Les nœuds se

déplacent à 5m/s. Le rayon de couverture d’un nœud ad hoc est de 150mètres. Les nœuds sont répartis

dans une zone carrée de 1000m de côté. Ils utilisent pour se déplacer le modèle RWP (cf. §1.4) avec

un temps de pause de 200 secondes entre déplacements. Le débit du réseau est de 2Mb/s. La

simulation utilise un modèle de communication dans lequel la moitié des nœuds communiquent avec

l’autre moitié. La durée d’une simulation est de 500 secondes.

Tout d’abord, nous vérifions que nos protocoles présentent le même pourcentage d’échec d’obtention

d’une route que le protocole AODV. La figure 5-19 montre le pourcentage d’échec en fonction du

nombre de nœuds présents sur le réseau. Lorsque la topologie du réseau possède un nombre de nœuds

trop faible pour permettre une connectivité acceptable entre les nœuds, les différents protocoles ont le

même taux d’échec. A partir de 75 nœuds, l’ensemble des protocoles trouvent toujours une route. Par

contre pour 50 nœuds, le protocole sous optimal échoue à trouver certaines routes. Il a 15% d’échec à

déterminer une route.

Figure 5-19 : Pourcentage d’échec à la découverte d’une route

La figure 5-20 donne le nombre de requêtes échangées pour déterminer une route suivant différentes

topologies de réseau. Le protocole AODV est le protocole qui retourne le plus grand nombre de

requêtes. La découverte d’une route n’est pas toujours immédiate, ainsi le protocole AODV peut faire

plusieurs tentatives avant de déterminer une route. La diffusion des paquets de routage sur le réseau

entraîne de nombreuses collisions qui obligent la source à réitérer sa recherche et ainsi augmente

grandement le nombre de requêtes. Le protocole AODV avec parcours en largeur possède également

un nombre conséquent de requêtes échangées. En fait, ce protocole est très efficace lorsque la source

est proche de la destination. Par contre, lorsqu’ils sont éloignés, le nombre de requêtes échangées

devient important. Avec une moyenne de 3.5 sauts séparant la source et la destination, le protocole

nécessite au moins trois tentatives pour trouver une route. Sur des réseaux denses, ces différentes

tentatives sont très coûteuses. Par contre, ce protocole est beaucoup moins sensible aux déplacements

des nœuds que le protocole AODV. En effet, la source conserve le nombre de tentatives qu’il lui a

fallu pour déterminer la destination. Lorsqu’une route est rompue, la source peut ajuster au mieux le

TTL du paquet et ainsi retrouver une route efficacement. Tout de même, nos protocoles utilisent bien

moins de paquets de routage pour déterminer une route. Le protocole optimal est particulièrement

0

20

40

60

80

100

120

10 30 50 75 100 150 200

Ech

ec d

e déc

ouver

te d

’une

route

(%

)

147

performant. Il utilise 6 fois moins de paquets de routage pour déterminer un chemin. Bien que le

protocole sous-optimal ne peut pas être comparé sur l’ensemble des topologies (puisque pour 50

nœuds, il n’arrive pas à déterminer toutes les routes), sur les topologies avec un nombre de nœuds

supérieur à 50 il opère efficacement. En effet, le nombre de paquets de routage est très faible. Il réduit

de près de 9 fois le nombre de paquets de routage échangés comparé au protocole AODV.

Figure 5-20 : Nombre requêtes transmises sur le réseau pour la découverte des chemins

La figure 5-21 met en évidence le nombre moyen de requêtes nécessaires à l’obtention d’une route, en

fonction du nombre de nœuds du réseau. Nous calculons ce nombre moyen uniquement lors de la

première recherche de route pour chaque connexion. Cela évite au protocole AODV avec parcours en

largeur d’avoir une connaissance plus ou moins juste du nombre de sauts séparant la source de la

destination. Les deux modes du protocole AODV ont des nombres moyens de requêtes assez proches.

Nos deux protocoles ont un nombre moyen de requêtes extrêmement faible (environ le quart du

nombre de nœuds composant le réseau pour le protocole optimal).

Figure 5-21 : Nombre moyen de requêtes pour la détermination d’un chemin

0

10000

20000

30000

40000

50000

60000

70000

80000

10 30 50 75 100 150 200

AODV

AODV avec

parcours en largeur

Protocole Optimal

Protocole sous-optimal

Nombre de nœuds

No

mbre

de

requ

êtes

0

50

100

150

200

250

300

350

10 30 50 75 100 150 200

148

5.4 Discussion

De nombreux protocoles de routage réduisent l’espace de recherche en supposant connaître la position

de la destination. Déterminer la position de la destination ne doit pas consommer plus de bande

passante qu’avec l’utilisation d’un protocole ne réduisant pas l’espace de recherche. Notre protocole

de localisation de la destination utilise une topologie du réseau en backbone. Les informations de

localisation transitent sur ce réseau pour éviter de consommer de la bande passante sur le réseau ad

hoc sous-jacent. Notre protocole de localisation est efficace puisqu’il ne transmet que très peu

d’informations de localisation sur le réseau ad hoc. Les seuls paquets de localisation échangés sont les

paquets provenant de la source ou de la destination d’un flux ou des nœuds de backbone qui leur sont

affiliés. De même, le protocole est peu sensible aux mouvements des nœuds puisque les changements

du réseau à backbone ne sont pas répercutés sur le réseau ad hoc.

L’obtention de la destination avec un faible coût permet d’envisager l’utilisation de protocoles

réduisant l’espace de recherche. Nous proposons un protocole qui réduit l’espace de recherche utilisant

deux formes géométriques (une forme triangulaire et une forme en cerf-volant). L’utilisation d’un tel

protocole réduit grandement le nombre de paquets de routage nécessaires à l’obtention d’une route.

Par contre, ce protocole possède l’inconvénient de n’être efficace que dans un environnement

particulièrement dense en nœuds. Dans les environnements où les nœuds sont plus dispersés, l’échec à

retourner une route est bien trop élevé pour rendre notre protocole pleinement utile. Pour résoudre un

tel problème, nous avons proposé deux protocoles qui utilisent un parcours en profondeur. En cas

d’échec lors de la découverte d’une route, la zone de recherche est agrandie. Parmi ces deux

protocoles, le premier est optimal (il retourne une route s’il en existe une) alors que le second

privilégie le nombre d’informations échangées sur l’optimalité. Bien entendu, pour que le second

protocole soit utilisable, il doit retourner quasiment à chaque recherche une route. Les deux protocoles

s’avèrent très efficaces. Le protocole optimal nécessite un faible nombre de requêtes pour déterminer

une route. Le protocole sous-optimal retourne très souvent une route, même si de rares fois ce n’est

pas le cas. Il nécessite très peu de paquets de routage pour déterminer une route. Il est, tout

particulièrement, efficace dans les environnements denses. Pour combler la sous-optimalité de ce

protocole, il peut être combiné, les rares fois où il échoue, à notre protocole optimal.

149

6 Protocole de routage pour l’optimisation de bande

passante sous des

contraintes : délai et bande

passante

Dans ce chapitre, nous nous intéressons à un problème que les protocoles de routage doivent résoudre

pour supporter les applications temps-réel et multimédia. Ce problème, noté DBCONT (Delay and

Bandwidth Constrained Optimal Network Throughput), consiste en la garantie du délai et de la bande

passante tout en optimisant cette dernière. Ce problème est NP-complet. Nous proposons, donc, une

solution pour s’approcher au mieux de la solution optimale d’un tel problème.

6.1 Garantie du délai : un besoin

Le nombre d’applications nécessitant une garantie en termes de délai ne cesse de croître tous les jours.

Ces applications temps-réel touchent l’ensemble des domaines professionnels et personnels. Elles

peuvent être employées aussi bien dans des environnements critiques, comme par exemple la gestion

150

de la chaleur d’un réacteur nucléaire, ou le contrôle de la répartition du freinage sur les différentes

roues d’une voiture, que dans des environnements moins contraignants, comme pour la téléphonie sur

internet ou les jeux en ligne. Les applications temps-réel sont donc répertoriées traditionnellement

dans deux catégories différentes :

– Applications temps-réel critiques : le traitement d’une opération après sa date limite

d’exécution est considéré comme une défaillance pouvant entraîner dans le pire des cas le

disfonctionnement du système.

– Applications temps-réel souples : ce type d’applications tolère un certain retard dans le temps

d’exécution. Si tel est le cas, l’application est susceptible de réduire la qualité qu’elle

nécessitait, à la base, pour pallier à ces retards.

L’environnement des réseaux ad hoc est difficilement adapté aux applications temps-réel critiques. En

effet, du fait de la mobilité des nœuds, des ressources limitées, des propriétés du support de

transmission et du manque d’un point central administrant les transmissions, garantir les contraintes

imposées par les applications temps-réel est une tâche difficile dans un tel environnement. Le

protocole de routage, lors du transfert des paquets sur un chemin de plusieurs nœuds, doit tenir compte

de ces paramètres pour garantir une certaine qualité de service aux applications temps-réel (cf. §3).

A cause de la difficulté à supporter la QoS dans un environnement aussi dynamique, l’utilisation des

réseaux MANETs, pour le transfert de données provenant d’applications temps-réel strictes, ne peut

être encore envisagée. Du fait du déplacement des stations mobiles sur un réseau MANET, les routes

peuvent être interrompues pendant un certain laps de temps. En fait, lors de la rupture d’un lien,

l’algorithme de routage doit trouver une route garantissant les contraintes de délai. Durant le temps de

rétablissement des routes, des paquets peuvent voir leur échéance arriver à terme, et par conséquent ils

ne sont pas traités dans les temps par la destination. Il en est de même avec le taux d’erreurs élevé du

support. Le temps de retransmettre un paquet pour qu’il arrive indemne à la destination, peut entrainer

le dépassement de l’échéance imposée. Ces dépassements sont non tolérés pour des applications

temps-réel critiques.

Les réseaux MANETs sont mieux adaptés aux applications temps-réel souples. Deux méthodes

peuvent être employées pour assurer une QoS aux applications temps-réel souples, la QoS souple et la

QoS adaptative. Une QoS souple indique que durant une certaine période de temps, la QoS spécifiée

peut ne plus être honorée. Ainsi, des paquets peuvent arriver en retard sans bloquer le fonctionnement

de l’application. La satisfaction des utilisateurs est quantifiée par le temps durant lequel le service est

interrompu sur le temps total durant lequel le service est fourni. La QoS adaptative introduit le concept

de QoS dynamique, c’est-à-dire que l’application ne spécifie pas un seul contrat de QoS mais plusieurs.

Ainsi, lorsque le contrat initial ne peut plus être respecté, le réseau change de contrat et en choisit un

moins contraignant. L’utilisation de la QoS dynamique donne plus de flexibilité au système et permet

au réseau d’ajuster la bande passante allouée à une application en fonction des ressources qui sont

disponibles.

151

Dans ce chapitre, nous nous intéressons nos travaux aux applications nécessitant la garantie de deux

contraintes, le délai et la bande passante. Ces contraintes se retrouvent dans la plupart des applications

temps-réel comme la vidéoconférence, la téléphonie sur internet… Les réseaux MANETs pouvant être

employés pour des opérations diverses (secours, militaires,…) (cf. §1), il est important de pouvoir

garantir le bon fonctionnement de telles applications. En effet, elles sont particulièrement employées

dans de tels contextes.

Le protocole de routage est un élément déterminant dans l’obtention de routes garantissant ces deux

contraintes. En effet lors de la phase de sélection des routes, il doit écarter les chemins ne garantissant

pas une de ces contraintes. De même, sélectionner le chemin (respectant les contraintes de bande

passante et de délai) possédant le plus faible délai de bout en bout n’est pas toujours le choix le plus

judicieux. Qu’un paquet de données arrive avec un faible délai ou un délai un peu plus important est,

dans bien des cas, peu dommageable. Le principal est qu’un tel paquet respecte son échéance. Tout en

respectant les contraintes imposées par une application, le protocole de routage doit privilégier la

sélection d’un chemin impactant peu la bande passante utile du réseau. Accroître la bande passante

utile du réseau peut soit augmenter le nombre de flux traversant le réseau ou soit augmenter la bande

passante requise par les flux (cf. §4.1).

Le partage du support rend difficile le respect de la contrainte de délai. La présence de collisions et le

temps variable d’acquisition du support retardent les paquets de données. De fait, une méthode d’accès

au support avec contention est difficilement utilisable pour des applications temps-réel ou multimédia.

Les méthodes d’accès au support sans contention sont bien mieux adaptées pour de telles applications

(cf. §3.5). Les travaux réalisés dans ce chapitre utilisent la méthode TDMA (cf. §3.5.1) pour accéder

au support sans contention. La méthode d’accès au support TDMA divise le support en tranche (slots).

Le long d’un chemin, des slots sont réservés pour garantir une bande passante exempte de collisions.

6.2 Facteurs impactant la bande passante lors de réservation

de slots

La bande passante est un facteur sensible dans les réseaux MANETs. En effet, elle est particulièrement

faible. Il est donc nécessaire que le réseau l’optimise au maximum pour permettre au plus grand

nombre de flux d’accéder au réseau (cf. §4.1). Pour éviter les collisions, la réservation d’un slot (avec

la méthode d’accès TDMA) est possible si les conditions suivantes sont respectées : l’émetteur ou le

récepteur n’émettent ou ne reçoivent pas, aucun nœud voisin de l’émetteur ne reçoit dans ce slot,

aucun nœud voisin du récepteur n’émet dans ce slot.

Un tel mécanisme affecte les nœuds voisins du nœud émetteur et du nœud récepteur. De fait, ces

nœuds ne peuvent pas réutiliser pleinement (un nœud voisin du nœud émetteur ne peut qu’émettre

alors qu’un nœud voisin du nœud récepteur ne peut que recevoir des données) ces slots pour échanger

des données. Par conséquent, plus le nombre de nœuds impactés est important, plus la bande passante

disponible du réseau est faible. Le protocole de routage est l’élément essentiel qui permet de contrôler

cette bande passante consommée. En effet, il peut intervenir sur le chemin emprunté ainsi que sur les

152

slots réservés. Le protocole de routage doit intervenir sur le nombre de nœuds influencés, par la

présence d’un nouveau flux, tout en retournant à la fois un chemin qui garantit le délai et la bande

passante demandés par l’application.

Le protocole de routage doit donc trouver un chemin qui garantit à la fois les contraintes de délai et de

bande passante tout en essayant d’optimiser la bande passant utile du réseau. Le protocole de routage

est donc confronté au problème DBCONT. Ce problème étant NP-complet, les protocoles essaient au

mieux de s’approcher de la solution optimale.

6.2.1.1 Impact de la réservation d’un slot sur les nœuds voisins

Un nœud réserve un nombre différent de slots suivant sa position dans un chemin. En effet, un nœud

réserve :

− 1 slot en émission si ce nœud est la source

− 1 slot en réception et 1 slot en émission si c’est un nœud intermédiaire

− 1 slot en réception si ce nœud est la destination

En effet, lors de la réservation des slots par un nœud intermédiaire i, il doit réserver autant de slots en

réception (qui sont les mêmes que les slots réservés en émission par le nœud i-1) que de slots en

émission (qui sont les mêmes que les slots réservés en réception par le nœud i+1). Seuls les nœuds

sources et destinations n’ont besoin de faire qu’une réservation. La source réserve seulement des slots

en émission alors que la destination réserve uniquement des slots en réception.

Figure 6-1 : Nombre de slots réservés suivant la position d’un nœud sur un chemin

La figure 6-1 montre le nombre de réservation suivant la position d’un nœud sur un chemin. Le nœud

S crée un chemin avec le nœud D. Un slot est réservé le long de ce chemin. Le nœud S a besoin de

transmettre uniquement les paquets, donc il réserve un slot en émission. Le nœud de destination D ne

fait que recevoir des paquets de données donc il réserve un slot en réception. Le nœud intermédiaire I

reçoit les données transmises par le nœud S donc réserve ce slot en réception et relaie les données vers

la destination donc réserve un slot en émission.

153

Pour déterminer l’impact d’un nœud sur ses voisins, nous calculons le nombre de nœuds présents dans

son voisinage. En fonction de sa place dans un chemin, nous déduisons ainsi le nombre de slots

influencés par le nœud. Nous définissons les notions de slots influencés (noté SI), slots influencés en

réception (noté SIR) et slots influencés en émission (noté SIE).

Le nombre de slots influencés par un nœud i est fonction de sa place dans le chemin et du nombre de

slots requis par l’application. La propriété 6-1 calcule le nombre de slots influencés SI par le nœud X

avec N nœuds dans son entourage et k slots à réserver le long du chemin.

Propriété 6-1 : Pour k slots à réserver, le nombre de slots influencés SI(X), par le nœud X avec

un voisinage de N nœuds, est le suivant :

SI(X) = k×(N-1) si x est la source du chemin

SI(X) = 2 k×(N-1) si x est un nœud intermédiaire

SI(X) = k×(N-1) si x est la destination du chemin

A partir de la propriété 6.1, on peut déduire le nombre de slots influencés en réception par un nœud

x par la fonction suivante :

SIR(X) = N-1 si X est la source ou un nœud intermédiaire

SIR(X) = 0 si X est la destination

De même, le nombre de slots influencés en émission par un nœud X, SIE(X), se calcule de la même

manière que précédemment en intervertissant la source et la destination.

La détermination de l’impact d’un nœud sur son voisinage, nous permet de poser le problème de

routage lié à la réservation de slots à travers les nœuds d’un chemin.

6.2.2 Problème de routage

Nombre de protocoles de routage actuels, garantissant le délai, ne se soucie guère d’optimiser la bande

passante. Pour trouver un chemin garantissant une certaine contrainte de délai et une quantité de bande

passante, ils choisissent en règle générale le chemin ayant le plus faible délai pouvant réserver le

nombre de slots désirés par l’application. Un des paramètres à optimiser pour accroître la bande

passante disponible du réseau est le nombre de nœuds influencés par un chemin. En effet, plus les

nœuds d’un tel chemin ont un nombre important de voisins, plus le nombre de slots influencés est

important.

154

Le slot i d’un nœud X est influencé par la réservation d’un slot i (par le nœud Y) de trois manières :

− En réception : le slot i du nœud X ne peut dorénavant plus recevoir de données, il peut réutiliser ce

slot uniquement en émission.

− En émission : le slot i du nœud X n’est plus capable d’émettre des données. Ce slot est utilisable

par X uniquement en réception de données.

− En émission et réception : c’est le cas le plus critique. Le slot i du nœud X ne peut être réutilisé.

Le chemin le plus court n’est pas forcément le chemin impactant le moins les nœuds voisins. Ce cas

est illustré sur la figure 6-2. Soit un réseau MANET de 8 nœuds. Le nœud S désire obtenir un chemin

vers le nœud D. L’application impose au réseau de réserver un slot de bout en bout. Pour cela, de

nombreux chemins garantissent la contrainte imposée. Parmi ces chemins, le chemin <S, E, D> est le

chemin possédant le plus faible nombre de sauts (figure 6-2 a). Le nœud E étant un élément central du

réseau, il va impacter un nombre important de nœuds voisins. En effet, chaque slot réservé par lui

impacte 7 nœuds (S, A, B, D, E, F, G). Le nœud S réserve le slot 1 en émission. Le nœud E réserve le

slot 1 en réception. La réservation sur le lien <S, E> impacte en tout 6 nœuds. La réservation du slot 1,

en émission, par le nœud S empêche les nœuds A et F de recevoir. La réservation du slot 1 en

réception, par le nœud C, empêche les nœuds A, B, C, D, F, G d’émettre des données. Ainsi, un tel lien

impacte fortement les nœuds voisins puisque 2 slots sont influencés en émission et réception (slot 1 de

A et F) et 4 slots sont influencés en émission (slot 1 de B, C, D et G). Le chemin impacte, en tout, 12

slots (4 slots sont influencés en émission et réception, 4 slots sont influencés en émission et 4 slots

sont influencés en réception). La figure 6-2 b) montre, pour le même réseau, l’influence des slots par

le chemin <S, F, G, D>. Le nœud S réserve le slot 1 en émission. Il influe en réception sur les nœuds A

et E. Le nœud E réserve en réception le slot 1. Il influe en émission sur le slots 1 des nœuds E et G. La

réservation d’un slot sur le lien <S, E> influe en émission et réception le slot 1 du nœud E, en émission

le slot 1 du nœud G et en réception sur le slot 1 du nœud A. De fait, un tel lien impacte faiblement ses

nœuds voisins. Le chemin <S, F, G, D> influe en tout sur 8 slots (2 slots sont influencés en émission et

réception, 3 slots sont influencés en émission et 3 slots sont influencés en réception). Bien que le

chemin <S, E, F, D> soit plus long, il influence bien moins de slots que le chemin <S, C, D>. Par

conséquent, la bande passante disponible du réseau est plus importante en passant par le chemin

<S, E, F, D>.

Maintenant que le problème est posé, il est nécessaire de déterminer l’impact qu’a un chemin sur ses

nœuds voisins (un nœud est voisin d’un chemin s’il est voisin d’un nœud du chemin).

6.2.2.1 Impact d’un chemin sur les nœuds voisins

Chaque nœud d’un chemin influe sur son voisinage. De fait, les nœuds d’un chemin interagissent tous

avec leur voisinage. Le voisinage d’un chemin est composé des voisins des nœuds qui composent le

chemin.

Nous présentons l’impact d’un chemin dans deux cas. Le premier est le cas général. Le deuxième cas

est un cas particulier où les nœuds sont uniformément distribués dans l’espace de recherche.

155

Figure 6-2 : Impact de chemins différents sur un réseau de 8 nœuds. a) Impact du chemin le plus court.

b) Impact du chemin optimal.

SD

A B C

Chemin utilisé

2 3 4 5 6 7 81

E

F

2 3 4 5 6 7 81 2 3 4 5 6 7 81

2 3 4 5 6 7 81

2 3 4 5 6 7 812 3 4 5 6 7 81

2 3 4 5 6 7 81

Slot réservé en émission

Slot réservé en réceptionSlot influencé en

réception

Slot influencé en

émission

Slot influencé en

émission et réception

a)

SD

AB C

2 3 4 5 6 7 81

E

F

2 3 4 5 6 7 81 2 3 4 5 6 7 81

2 3 4 5 6 7 81

2 3 4 5 6 7 812 3 4 5 6 7 81

2 3 4 5 6 7 81

b)

2 3 4 5 6 7 81

2 3 4 5 6 7 81

G

G

156

6.2.2.1.1 Cas général

La réservation de slots sur un chemin empêche les nœuds voisins à ce chemin d’utiliser (du moins

partiellement) les slots réservés. Le chemin peut donc avoir un impact plus ou moins important sur son

voisinage. Le protocole de routage doit retourner le chemin avec le plus faible impact.

Pour déterminer l’impact d’un flux, il est nécessaire de calculer le nombre de slots qui sont influencés

par ce flux. Nous calculons l’influence du chemin, noté CI, en fonction de l’influence des nœuds

(composant le chemin) sur leur voisinage. Soit un chemin P=<v1, …, vN> dont chaque nœud vi possède

Ni voisins. Le nombre de slots réservés sur le chemin est de k slots. L’influence du chemin est donné

par la formule suivante :

( ) ( ) ( )1121)(1

21 −×+−×+−×≤ ∑

−

=N

N

ii NkNkNkPCI (6-1)

Démonstration :

Soit un chemin P=<v1, …, vN> de N nœuds qui a réservé k slots pour un flux donné.

Le nœud source a besoin seulement d’émettre les paquets de données donc il a besoin de réservés k

slots en émission et pour chaque slot réservé, il influe en réception sur chaque nœud voisin (donc

k×(N1-1) puisque le nœud v2 n’est pas influencé puisqu’il reçoit).

La destination, quant à elle, reçoit uniquement les paquets de données. Elle a donc besoin de réserver k

slots en réception. Elle influe en réception sur chaque nœud voisin sauf le nœud précédent du chemin

puisqu’il utilise les mêmes slots pour émettre les données (donc k×(NN-1) slots influencés).

Les nœuds intermédiaires permettent la propagation des paquets sur le chemin. Par conséquent, ils

reçoivent les paquets et doivent les retransmettre. Donc, ils doivent réserver k slots en réception et k

slots en émission. Chaque nœud intermédiaire i influe sur 2×k×(Ni-1) slots.

La valeur CI(P) est bornée puisqu’un nœud voisin du chemin peut être voisin de plusieurs nœuds du

chemin. Pour peu que le slot réservé soit identique, il n’est influencé qu’une seule fois. Pour qu’un tel

cas se produise, il est nécessaire que le nœud influencé soit voisin de deux nœuds du chemin séparé au

moins de deux sauts.

Par conséquent : ( ) ( ) ( )1121)(1

21 −×+−×+−×≤ ∑

−

=N

N

ii NkNkNkPCI

�

A partir de l’équation (6-1), on peut représenter l’impact en émission d’un chemin (noté CIE) et

l’impact en réception d’un chemin (noté CIR). Donc pour un chemin P=<v1, …, vN> de N nœuds qui a

réservé k slots pour un flux donné, CIE(P) et CIR(P) sont obtenus à partir des équations suivantes :

157

( ) ( )11)(1

2

−×+−×≤∑−

=N

N

ii NkNkPCIE

( ) ( )∑−

=−×+−×≤

1

21 11)(

N

iiNkNkPCIR

Considérons le réseau présenté sur la figure 6-3. Ce réseau est composé de 9 nœuds. Deux slots sont

réservés le long du chemin <S, F, D>. L’impact du chemin CI(<S, F, D>) représente l’ensemble des

slots qui sont influencés (que ce soit en émission, en réception ou en émission et réception) sur le

chemin. CI(<S, F, D>) = 24 alors que la borne maximale est de 28 slots influencés. Cette différence

s’explique par les slots qui sont influencés en émission et réception (4 slots). Par contre,

CIE(<S, F, D>) = CIR(<S, F, D>) = 14 puisque dans ce cas l’ensemble des slots influencés en

émission (respectivement en réception) sont distincts.

Figure 6-3 : Impact d’un chemin sur les nœuds voisins avec la réservation de 2 slots par nœud traversé.

S

D

A

B C

HG

F

E

1 2 3 4 5 6 7 81 2 3 4 5 6 7 8

1 2 3 4 5 6 7 81 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

Chemin utiliséSlot réservé en émission

Slot réservé en réceptionSlot influencé en

réception

Slot influencé en

émission

Slot influencé en

émission et réception

158

6.2.2.1.2 Nœuds uniformément distribués

Lorsque les nœuds sont uniformément répartis dans le réseau, déterminer le chemin avec le plus faible

nombre de voisins revient à trouver le chemin composé du plus faible nombre de nœuds. En

considérant que les nœuds possèdent le même rayon de couverture, le nombre moyen de nœuds

présents dans le voisinage est le même pour tous les nœuds du réseau.

Pour déterminer le nombre de slots influencés par un chemin P, il faut déterminer la probabilité qu’un

nœud soit dans le voisinage d’un autre. De fait, une fois cette probabilité calculée, il est possible de

représenter le nombre de nœuds présents dans le voisinage d’un autre nœud.

Pour déterminer la probabilité qu’un nœud se trouve dans la zone de couverture d’un autre nœud, il est

nécessaire de connaître la portée du nœud (son rayon de couverture) ainsi que la surface AG de la zone

où se situent les nœuds. Cette probabilité est déterminée pour des nœuds uniformément répartis dans

AG. La probabilité qu’un nœud x se situe dans la zone de couverture de rayon R d’un autre nœud i noté

A i peut être donnée par la formule suivante :

( )G

i

G

Gii A

A

A

AAAxP =∩=∈ (6-2)

où Ai ⊂ AG

En connaissant la probabilité qu’un nœud soit dans la zone de couverture d’un autre nœud i, le nombre

moyen de nœuds dans le voisinage de i est déterminé. Pour un réseau composé de N nœuds, on déduit

de l’équation (6-2) le nombre moyen de nœuds N(i) dans Ai. N(i) est calculé grâce à la formule

suivante :

N(i) = N⋅P(x∈Ai)

En considérant que le rayon de couverture est le même pour tous les nœuds du réseau, chaque nœud a

la même probabilité qu’un nœud appartienne à son voisinage. Ainsi, l’ensemble des nœuds du réseau

ont le même nombre moyen de voisins. Ce nombre est noté NV.

Le nombre de slots influencés par un chemin P=<v1, …, vn> peut être maintenant déterminé. Chaque

nœud du chemin va influencer les nœuds voisins par les slots qu’il réserve. La source n’influence

seulement en émission les nœuds voisins, la destination seulement les nœuds voisins en réception,

alors que les nœuds intermédiaires influence les nœuds voisins en émission et réception. A partir de

l’équation (6-1), on déduit le nombre de slots influencés par le chemin P avec l’équation suivante :

( ) ( )112)( −×−×≤ NVNkPCI (6-3)

On déduit de l’équation (6-3) l’impact en émission et en réception du chemin P :

( ) ( )11)( −×−×≤ NVNkPCIE

159

( ) ( )11)( −×−×≤ NVNkPCIR

Dans le cas de nœuds uniformément répartis dans le réseau, ces différentes formules montrent que

l’impact d’un chemin sur les nœuds voisins est fonction de deux facteurs :

– La portée : lorsque la portée croît, la probabilité moyenne d’avoir un nœud dans son voisinage croît

également. De fait, avec l’augmentation de la portée d’un nœud, le nombre de nœuds influencés est

plus important.

– La longueur du chemin : la sélection du chemin le plus court impacte, en moyenne, le moins de

nœuds voisins. En effet, plus la longueur du chemin est grande, plus ce chemin impacte un nombre

important de nœuds voisins.

Dans ce cas particulier, la résolution du problème DBCONT revient à sélectionner le chemin avec le

plus faible nombre de nœuds (tout en garantissant la contrainte du délai et de la bande passante). Ainsi,

si notre protocole de routage est fonction du nombre de nœuds voisins pour sélectionner un chemin, il

retourne le chemin le plus court dans ce cas particulier. De fait, avec une telle répartition des nœuds

dans le réseau, le chemin le plus court et le chemin sélectionné par notre protocole ont la même

efficacité.

6.2.3 Bande passante surconsommée

Pour être pleinement efficace, le protocole de routage doit retourner un chemin ayant le plus faible

impact sur les nœuds voisins à ceux du chemin. Les slots influencés sont une perte de bande passante

qui ne peut pas être utilisée par d’autres flux. De fait, nous définissons la notion de slots sur-employés,

SSE, qui est le nombre de slots influencés par le chemin P. Le nombre de slots sur-employés par le

chemin P est donné par la formule suivante :

SSE(P) = CI(P) (6-4)

A partir du nombre de slots sur-employés par un chemin, il est possible de déterminer la bande

passante perdue. Nous définissons la bande passante surconsommée comme la bande passante utile

perdue par les slots influencés. La bande passante surconsommée est notée BS. Plus cette bande

passante est faible, plus le protocole de routage est performant. Pour déterminer BS, on suppose que

l’ensemble des nœuds du réseau ait la même capacité C et que la durée d’une trame TDMA, T, dure le

même temps. La trame TDMA est divisée en slots de même durée TS.

Le calcul de BS, pour un chemin P, est donné par la formule suivante :

( ) ( ) CTPSSET

PB ss ⋅⋅⋅= 1 (6-5)

160

La valeur T

1 donne le nombre de trames TDMA par unité de temps. SSE(P) représente le nombre de

slots surconsommés et TS la taille d’un slot. La valeur ( ) STPSSET

⋅⋅1 représente la durée consommée

par l’ensemble des slots sur-utilisés. Par conséquent, il suffit de multiplier ce temps à la capacité des

nœuds pour obtenir la bande passante surconsommée Bs(P) pour le chemin P.

Pour être pleinement efficace, notre protocole de routage doit sélectionner un chemin avec la plus

faible bande passante surconsommée. De fait, les caractéristiques de ce protocole et la fonction poids

employée sont les deux éléments essentiels pour y parvenir.

6.3 Optimisation de la bande passante sous contraintes de

délai et bande passante

Nous proposons un protocole de routage interagissant avec la couche MAC pour sélectionner un

chemin. Notre protocole de routage interroge la couche MAC pour calculer les métriques nécessaires à

la détermination d’une route. L’interaction entre les couches réseau et MAC permet aussi de réaliser la

réservation de bande passante nécessaire au bon fonctionnement de l’application durant la phase de

découverte des routes. La phase de réservation peut être découplée de la phase de découverte des

routes c'est-à-dire que rien n’empêche qu’elle ait lieu une fois qu’une route est trouvée. Découpler la

phase de réservation de la phase de découverte des routes accroît le délai d’attente avant de pouvoir

utiliser la route. De fait, nous faisons le choix de combiner ces deux opérations.

Notre protocole de routage garantit les contraintes de délai et de bande passante. Il permet également

de sélectionner le chemin, respectant ces contraintes, avec le plus faible impact sur les nœuds voisins.

La bande passante préservée est ainsi disponible pour d’autres flux.

La mobilité des nœuds peut perturber le respect des contraintes imposées par chaque flux. En effet, le

délai ou la bande passante peuvent varier avec les changements de topologie et ne plus respecter leurs

contraintes. Lorsqu’une route ne respecte plus les contraintes imposées, le protocole de routage doit

sélectionner une nouvelle route respectant les besoins des flux. De même, le protocole de routage doit

continuellement prendre en compte les changements de topologie du réseau occasionnant la rupture

d’une ou plusieurs routes.

6.3.1 Métriques

Notre protocole utilise une fonction poids pour déterminer la qualité des chemins. Cette fonction

utilise trois sortes de métriques : le délai, le nombre de slots disponibles et le nombre de nœuds voisins.

Ces trois métriques sont calculées par notre protocole de routage. Notre protocole de routage utilise les

informations qui lui sont fournies par la couche MAC pour déterminer de telles métriques. Ces

métriques sont calculées comme suit :

161

– Le délai : le délai de bout en bout est fonction des slots choisis par chaque nœud du chemin. Pour

déterminer le délai de bout en bout, la liste de slots choisis est conservée dans l’entête des paquets de

routage.

– Le nombre de slots disponibles : pour connaître le nombre de slots disponibles, la couche réseau

interroge la couche MAC. En effet, périodiquement les nœuds échangent entre eux des paquets de

contrôle contenant la liste des slots qu’ils utilisent en émission et en réception. L’échange de tels

paquets permet le respect des trois règles nécessaires à l’évitement de collisions (cf. §3.5.1).

– Le nombre de nœuds voisins : le nombre de nœuds voisins est également obtenu en interrogeant la

couche MAC. Lors de la réception d’un paquet périodique permettant la cohérence de la méthode

d’accès TDMA, le nœud conserve dans une table des voisins l’identifiant de l’émetteur. Si pendant

une certaine durée, un nœud ne reçoit plus de paquet périodique d’un autre nœud c’est qu’ils ne sont

plus dans le même voisinage. Le nombre de nœuds voisins à un nœud vi est noté N1(vi).

Notre protocole de routage n’a pas besoin d’échanger d’informations pour calculer la valeur des

métriques. Il utilise les échanges nécessaires à la couche MAC, pour conserver sa cohérence, dans le

but d’obtenir les informations adéquates pour déterminer la valeur des métriques utilisées.

6.3.2 Fonction poids

Pour réduire la complexité du problème DBCONT, le protocole de routage ne doit pas retourner le

chemin le plus court (respectant les contraintes de délai et de bande passante), mais un chemin qui se

rapproche le plus du chemin optimal. Pour se faire, le protocole de routage doit utiliser une fonction

poids lors de la recherche des chemins.

Deux types de fonctions poids sont couramment utilisés : les fonctions poids linéaires et non-linéaires.

Nous choisissons d’utiliser une fonction poids non-linéaire dans notre protocole de routage. Une telle

fonction permet de privilégier une métrique sur les autres. L’avantage de privilégier une métrique sur

les autres implique que la fonction poids retourne un chemin qui favorise cette métrique.

Notre fonction poids doit privilégier la métrique du nombre de nœuds voisins du chemin par rapport

aux métriques de bande passante et de délai. Nous pouvons réduire notre fonction à l’utilisation de

deux métriques, le nombre de nœuds voisins du chemin et le délai. En effet, le protocole de routage ne

doit pas prendre le chemin avec la plus forte bande passante disponible. Le principal est que la bande

passante disponible du chemin respecte la contrainte de bande passante.

Pour privilégier le nombre de nœuds voisins par rapport au délai du chemin, le protocole de routage

doit pénaliser de manière plus importante le nombre de nœuds voisins d’un chemin que son délai.

Deux solutions peuvent être envisagées pour y parvenir :

– Pénaliser de manière exponentielle le nombre de nœuds voisins d’un chemin et de manière

proportionnelle le délai du chemin.

162

– Pénaliser de manière proportionnelle le nombre de nœuds voisins d’un chemin et pénaliser de

manière logarithmique le délai du chemin.

Nous faisons le chois d’utiliser la deuxième méthode. Le délai du chemin ne devant jamais excéder le

délai imposé, la fonction poids doit retourner 0 lorsque le délai est quasiment nul et tendre vers l’infini

lorsque le délai est strictement supérieur à la contrainte du délai. Par conséquent, il nécessite de

trouver une fonction logarithmique respectant un tel critère. La fonction suivante correspond à nos

attentes :

( )

+∆>∞

+∆≤

∆−

=>=<∑

−

=+

ε

ε

D

D

D

n

iii

n

PD

PD

vvDvvPf

)( avec

)( avec ),(

1

1ln

,..., 1

11

1 (6-6)

En effet, cette fonction respecte parfaitement la contrainte de délai imposée. Lorsque D(P) > ∆D alors

f(P)→∞. Pour D(P)=0 alors f(P)=0.

Maintenant reste à trouver une fonction poids qui pénalise également le nombre de nœuds voisins d’un

chemin. La fonction poids doit pénaliser plus fortement le nombre de nœuds voisins que le délai du

chemin. Un chemin qui ne respecte pas la contrainte de bande passante doit, également, posséder un

poids qui tend vers l’infini. La fonction poids w(P) pour un chemin P=<v1, …, vn> correspond à ces

attentes :

w(P) = w(<v1,…,vn>) = ( ) ( )PfvNn

ii ⋅∑

=11

= ( )

<∃∨∆>∞

∆≤

∆−

⋅∑

∑ −

=+

=

kjiNSjiPD

PDvvD

vN

D

D

D

n

iii

n

ii

),( ,)( avec

)( avec ),(

1

1ln

1

11

11 (6-7)

où NS(i, j) est le nombre de slots disponibles sur le lien (i,j).

6.3.3 Principe du protocole

Basé sur AODV, notre protocole doit apporter des modifications dans l’entête des paquets de routage

échangés ainsi que dans les tables de routage maintenues par l’ensemble des nœuds du réseau. Pour

propager les caractéristiques du chemin emprunté, les contraintes de délai et de bande passante,

163

l’entête des paquets de routage est modifié. Notre protocole effectue une gestion par flux. De fait, il

conserve dans sa table de routage le prochain nœud pour le couple (source, destination).

Notre protocole de routage émet des paquets RREQ pour propager l’information de routage à travers

le réseau. Les paquets RREQ possèdent dans leur entête des paramètres déjà présents dans le protocole

AODV tels que : l’adresse IP source, le numéro de séquence source et l’adresse de destination.

L’entête de ces paquets est complété par les métriques liées au chemin ainsi qu’aux contraintes à

respecter. Les métriques sont le délai du chemin et le nombre de nœuds voisins de ce chemin. Les

contraintes sont la borne du délai et le nombre de slots à réserver. Les slots susceptibles d’être réservés

sont conservés également dans l’entête du paquet. En effet, comme le délai du chemin est directement

lié au choix des slots, ils doivent être conservés pour pouvoir calculer le délai au plus juste. Pour

conserver une cohérence dans le délai du chemin, ces slots sont réservés lors de la confirmation d’une

route. Pour cela, les slots sélectionnés sur un lien (i, j), notés S(i,j), sont mémorisés dans le champ

Liste des Slots, noté LS, de la requête RREQ.

Le paquet de confirmation de routes RREP comporte dans son entête, l’adresse de la destination,

l’adresse de la source, le numéro de séquence de la destination, le poids du chemin et la liste des slots

LS.

Chaque nœud du réseau maintient deux tables : la table inverse des chemins et la table de routage. La

table inverse des chemins comporte les champs suivants : adresse source, numéro de séquence source,

adresse de destination, numéro de séquence de destination, poids du chemin. Dans la table de routage,

sont maintenus les champs suivants : l’adresse source, le numéro de séquence source, l’adresse de

destination, le numéro de séquence de destination, le poids du chemin et le prochain nœud.

Le fonctionnement de notre protocole de routage est différent suivant la position du nœud dans le

chemin (nœud source, nœud intermédiaire et nœud destination).

6.3.4 Algorithme

Le fonctionnement du nœud source est présenté sur l’organigramme de la figure 6-4. Le nœud source

crée un paquet RREQ et initialise ses champs. Le champ délai est initialisé à 0, le champ nombre de

nœuds voisins est égal au nombre de nœuds présent dans le voisinage du nœud source et la liste des

slots est mise à NULL. Les bornes de délai et de bande passante sont aussi initialisées. Le nœud source

émet la requête RREQ puis se met en attente après avoir armé le temporisateur Trep. Si Trep arrive à

échéance, la source n’a reçu aucune confirmation de route. Elle réitère sa demande de création de

route jusqu’à atteindre le seuil Nrpmax. Lorsque ce seuil est atteint, le nœud source prévient la couche

supérieure qu’il n’a pas pu trouver une route. S’il reçoit un paquet RREP avant l’expiration de Trep, il

vérifie si les slots contenus dans LS sont libres. Dans le cas où ils le sont, il les réserve et une route est

trouvée. Après avoir arrêté Trep, il peut commencer à transmettre ses données.

164

Figure 6-4 : Organigramme utilisé par le nœud source

Le fonctionnement d’un nœud intermédiaire j est donné par l’organigramme de la figure 6-5. Lorsque

le nœud j reçoit un paquet RREQ d’un nœud i, il vérifie dans un premier temps si le nombre de slots

disponibles sur le lien (i, j), noté SD(i, j), est supérieur à la borne de bande passante requise ∆B. Si

SD(i, j) est supérieur ou égal à la borne, il réserve le nombre de slots requis dans le vecteur S(i, j).

Après avoir déterminé le délai du chemin entre la source et lui, il vérifie que ce délai ne dépasse pas la

borne du délai ∆D. Si cette borne est respectée, il calcule le poids du chemin et met à jour sa table des

chemins inverses si besoin.

A la réception d’un paquet RREP émis par un nœud i, le nœud j vérifie en premier lieu qu’il peut

réserver les slots contenus dans LS sur le lien (j, i) et sur le lien (nœud_précédent, j). Si ces slots sont

disponibles, il les réserve après avoir mis à jour sa table de routage. Il transmet le paquet RREP au

nœud nœud_pécédent après avoir retiré de LS les slots à réserver sur le lien (j, i).


DEBUT

- Créer un RREQ



- Initialiser LS


de la requête

- Diffuser RREQ

- Armer le temporisateur

Trep

RREP reçu

d’un nœud i ?

- Arrêter Trep

- Réserver les

slots LS(source, i)

- Envoyer les

données

oui

non

Trep expiré?

nonoui

Nrp++

Nrp Nrpmax?oui

non

Informer la couche supérieure

Phase de

traitement des

données

Transmission des

données

RERR reçu ?

une route ?

oui non

oui non

Les slots

LS(source, i)

sont-ils libres ?

Supprimer

la requête

non

oui

- Libérer les

slots

165

Figure 6-5 : Organigramme utilisé par un nœud intermédiaire j

Le fonctionnement du nœud destination est donné par l’organigramme de la figure 6-6. A la réception

d’un paquet RREQ, le nœud destination calcule le nombre de slots disponibles et le délai du chemin.

S’il peut sélectionner un nombre de slots correspondant à la bande passante requise et le délai du

chemin respecte la contrainte du délai, il arme un temporisateur Ta si ce n’est pas déjà fait. Le

temporisateur Ta permet au nœud destination d’attendre un certain temps avant d’émettre une

confirmation RREP. Cela lui permet de recevoir plusieurs paquets RREQ et de choisir le chemin avec

le plus faible poids. En effet, il peut recevoir de nombreuses requêtes RREQ venant de chemins

différents. Si la destination transmet un paquet RREP à la réception de la première requête garantissant

les contraintes imposées, le chemin de plus faible poids peut ne pas être sélectionné. De même, de

multiples requêtes RREP ne doivent être émises car sur le chemin de confirmation, les slots contenus

dans la requête RREP sont réservés. Transmettre plusieurs requêtes RREP engendre de multiples

réservations, réduisant d’autant la bande passante du réseau. Lorsque le temporisateur Ta arrive à

expiration, il réserve les slots en commun avec le nœud précédent et émet une réponse avec la liste des

slots à réserver sur le chemin. Tout paquet RREQ qui arrive après expiration du temporisateur Ta est

supprimé.

166

Figure 6-6 : Organigramme utilisé par le nœud destination

6.3.5 Analyse de performances

Pour vérifier le comportement de notre protocole de routage, nous analysons ses performances par

simulation. Le simulateur employé est le simulateur NS-2. Les simulations sont effectuées en

comparant l’efficacité de notre protocole avec le protocole de routage de plus faible délai (noté LD).

Le protocole de routage LD retourne le chemin de plus faible délai qui respecte la contrainte de bande

167

passante. Si ce protocole ne trouve pas de route, alors aucune route ne respecte les contraintes

imposées.

Nous simulons ces protocoles sur différentes topologies où le nombre de nœuds présents sur le réseau

varie. Les nœuds possèdent tous un débit de transmission de 11 Mbps. La méthode d’accès au support

est TDMA. Les nœuds échangent toutes les secondes leur table de slots réservés en émission et

réception. Chaque nœud connaît ainsi ses voisins et les slots qu’ils ont réservés. L’ensemble des

nœuds sont synchronisés durant nos simulations. Ainsi le début de chaque fenêtre TDMA a lieu au

même instant. La taille d’un slot est de 700 octets. Il y a 5 fenêtres TDMA par seconde. Chaque nœud

du réseau possède un slot de contrôle. Le nombre de slots de données diminue avec l’augmentation du

nombre de nœuds dans le réseau. Le nombre de slots par fenêtre TDMA est de 350 slots. La durée des

simulations est de 500 secondes. La simulation utilise un modèle de communication dans lequel la

moitié des nœuds communiquent avec l’autre moitié. Chaque connexion nécessite la réservation d’un

slot de bout en bout du chemin. Chaque flux possède un débit de 20Kbps.

Dans un premier temps, nous déterminons la bande passante surconsommée moyenne par le protocole

LD comparé à notre protocole. Pour cela, nous utilisons l’équation (6-4) pour déterminer le nombre de

slots impactés par le protocole LD et notre protocole. L’équation (6-5) permet de déduire, à partir de la

valeur SSE(PLD) (respectivement SSE(PNotre Protocole)), la bande passante surconsommée par le protocole

LD (respectivement par notre protocole). La figure 6-7 montre son évolution en fonction du nombre de

nœuds sur le réseau. La bande passante surconsommée par les deux protocoles croît avec

l’augmentation du nombre de nœuds sur le réseau. Lorsque le nombre de nœuds présents est de 150, la

différence de bande passante surconsommée par le protocole LD est de 800 Kbps. A partir de 150

nœuds, l’impact stagne. Lorsque 200 nœuds sont présents, bien que le nombre de nœuds subissant un

impact est plus important, il l’est autant pour le protocole LD que pour notre protocole.

Figure 6-7 : Bande passante surconsommée par le protocole LD comparé à notre protocole

L’évolution du nombre de paquets RREQ nécessaires à l’obtention d’une route est représentée sur la

figure 6-8. Le nombre de connexions augmente avec le nombre de nœuds présents sur le réseau. De

fait, la bande passante nécessaire à l’obtention des routes croît avec le nombre de nœuds. Notre

protocole nécessite plus de paquets RREQ que le protocole LD pour choisir les chemins. En effet,

0

1000

2000

3000

4000

5000

6000

7000

8000

30 50 75 100 150 200

168

même si le chemin possède le plus faible délai, son impact sur les nœuds voisins n’est pas forcément

le moins important. La différence de bande passante commence à se ressentir à partir de 150 nœuds.

Tout de même, elle reste relativement faible.

Figure 6-8 : Bande passante nécessaire à l’obtention des routes

Un autre critère de comparaison est la bande passante utilisée par les paquets de données (figure 6-9).

Quelque soit le nombre de nœuds présents sur le réseau, cette bande passante est identique pour les

deux protocoles. Ceci met en évidence que les chemins déterminés par les deux protocoles de routage

ont, souvent, le même nombre de sauts.

Figure 6-9 : Bande passante utilisée par les paquets de données

Le dernier critère de comparaison est le nombre de slots libres en réception et en émission

(figure 6-10). Notre protocole retourne un nombre de slots libres plus important (que celui retourné par

le protocole LD) dans l’ensemble des scénarios réalisés. Il est d’autant plus performant lorsque le

nombre de nœuds est important (par conséquent lorsque la charge du réseau est importante). De fait, à

partir de 150 nœuds, notre protocole propose environ 1000 slots libres supplémentaires que le

0

20

40

60

80

100

120

140

160

30 50 75 100 150 200

Ban

de

pas

san

te c

on

som

mée

par

les

paq

uet

s

RR

EQ

(K

b/s

)

0

500

1000

1500

2000

2500

30 50 75 100 150 200

169

protocole LD. Ces slots libres peuvent être réutilisés pour faire passer des flux supplémentaires, ou

pour accroître la bande passante des flux déjà en place sur le réseau.

Figure 6-10 : Nombre de slots restés libres en fin de simulation en fonction du nombre de nœuds.

6.4 Discussion

Les applications multimédia et temps-réel nécessitent que le réseau respecte certaines contraintes pour

fournir une communication de qualité. Les contraintes de telles applications sont nombreuses : bande

passante, délai, fiabilité… Dans cette section, nous nous sommes focalisés sur la garantie de la bande

passante et du délai.

Le support des applications multimédia et temps-réel est plus complexe dans les réseaux mobiles du

fait de la mobilité des nœuds et du partage du support de transmission. Les méthodes d’accès au

support conventionnelles, CSMA/CA par exemple, ne peuvent apportées la garantie nécessaire au

respect des contraintes de QoS. Nos travaux utilisent la méthode sans contention TDMA. Cette

méthode d’accès divise le support de communication en intervalles de temps. En respectant un certain

nombre de règles, les nœuds du réseau peuvent transmettre sans créer de collisions. En effet, un nœud

ne peut transmettre (respectivement recevoir), dans un intervalle de temps qu’il n’utilise pas,

seulement si aucun nœud voisin ne reçoit (respectivement n’émet) durant cet intervalle de temps.

Ainsi, la transmission ou la réception d’un paquet par un nœud influe sur le comportement des nœuds

voisins.

10

15

20

25

30

35

30 50 75 100 150 200

Nom

bre

de

slo

ts l

ibre

s (m

illi

ers)

170

Les protocoles de routage, garantissant la bande passante et le délai, n’optimisent pas la bande

passante des réseaux MANETs. Nous avons traité le problème DBCONT (Delay and Bandwidth

Constrained Optimal Network Throughput). Ce problème est NP-complet.

Le protocole de routage est l’élément essentiel dans l’optimisation de la bande passante du réseau. Les

nœuds du chemin sélectionnés doivent influer le moins possible sur les autres nœuds du réseau. Notre

protocole de routage utilise une fonction poids garantissant les contraintes de bande passante et de

délai. Cette fonction pénalise fortement les chemins en fonction du nombre de nœuds présents dans le

voisinage.

La réalisation de simulations a mis en évidence l’efficacité de notre protocole. Nous avons comparé

notre protocole au protocole de plus faible délai (LD). Cette comparaison montre que les nœuds du

chemin sélectionné par notre protocole influent moins sur leurs voisins que ceux du protocole LD. De

fait, les intervalles de temps laissés libres par notre protocole peuvent être affectés à d’autres flux.

171

7 Conclusion et perspectives

Ces dernières années, le besoin en mobilité des usagers n’est plus à démontrer. Les réseaux MANETs

permettent aux usagers de communiquer tout en se déplaçant librement. Ces réseaux doivent pouvoir

supporter les mêmes applications que les réseaux filaires et cela de façon transparente. Les

applications multimédia et temps-réel sont fortement consommatrices en bande passante. Les

contributions de nos travaux se sont focalisées sur l’augmentation de la bande passante utile des

réseaux MANETs. Pour répondre à cette problématique, nous avons décidé d’opérer au niveau réseau,

où le protocole de routage est l’élément essentiel dans la sélection des chemins. Pour parvenir à notre

objectif, nous avons mis en évidence les facteurs de la couche réseau ayant un impact sur la bande

passante du réseau. Nous tenons aussi compte des collisions. De fait, nos travaux s’orientent selon

trois axes : la diminution des collisions, une dissémination efficace de l’information de routage et le

support d’applications contraintes par la bande passante et le délai. Relever ce défi suppose

l’appréhension de nombreuses notions : la notion de réseaux sans fil et principalement celle des

réseaux MANETs, la notion de Qualité de Service et des applications contraintes et les différents

protocoles de routage qu’ils soient Meilleur Effort ou à QoS. Nous organisons cette conclusion en trois

parties. Dans un premier temps, nous présentons nos contributions dans le cadre des protocoles de

routage augmentant la bande passante utile d’un réseau MANET. Dans un second temps, nous tirons

les enseignements de nos travaux. Dans un dernier temps, nous critiquons ces résultats et présentons

les orientations futures de ce travail.

7.1 Contributions

Dans notre première contribution, nous nous sommes attachés au problème des collisions. Du fait des

retransmissions, les collisions réduisent la bande passante utile d’un réseau. Elles accroissent, aussi, le

délai de bout en bout des paquets de données. Nous avons isolé différents facteurs jouant un rôle sur

l’occurrence de collision : le nombre de nœuds voisins, le délai de transmission d’un paquet, la charge

172

d’un lien et le délai de propagation. Nous avons proposé deux fonctions poids pour réduire le nombre

de collisions. La première fonction poids combine trois métriques pour sélectionner un chemin (la

bande passante ayant subi des collisions, le nombre de sauts d’un chemin et la capacité d’un lien).

Bien que l’efficacité de cette fonction poids ne réponde pas pleinement à nos attentes, les résultats

obtenus furent riches d’enseignements. La bande passante saturée est une notion souvent utilisée dans

les réseaux filaires pour vérifier l’efficacité d’un protocole de routage. Elle n’est pas représentative de

leur efficacité dans les réseaux sans fil. Notre fonction poids augmente la bande passante saturée du

réseau. Dans un scénario pratique, le nombre de requêtes échangés par notre protocole de routage met

à mal l’efficacité réelle de cette fonction poids. De plus, la bande passante ayant subi des collisions

réagit trop lentement à l’augmentation de la charge du lien. Lorsque cette mesure augmente le lien a

déjà atteint sa limite de transmission.

A partir de tels constats, nous avons proposé une seconde fonction poids. Cette fonction poids

combine trois métriques pour déterminer un chemin (la bande passante disponible, la capacité d’un

lien et le nombre de nœuds voisins). Pour mesurer les métriques, cette fonction poids nécessite une

gestion locale de l’environnement par le protocole de routage. Nous avons proposé un protocole de

routage auquel est combinée la deuxième fonction poids. L’efficacité de notre protocole de routage est

évaluée par simulation. Notre protocole est comparé aux protocoles AODV et AODV avec une gestion

locale de l’environnement (noté AODV Hello). Les simulations montrent que les protocoles de

routage avec une gestion locale de l‘environnement sont moins sensibles aux collisions. Les collisions

peuvent entraîner la détection de la perte d’un lien alors qu’il est toujours actif. En réduisant les

collisions, notre protocole est moins sensible à ce phénomène que les protocoles AODV et AODV

Hello. De fait, la bande passante utilisée pour la création et la maintenance des routes est plus faible

avec notre protocole qu’avec les autres. Dans les meilleures circonstances et comparé aux autres

protocoles, notre protocole de routage augmente la bande passante utile du réseau de 50% comparé

aux protocoles AODV et AODV Hello. L’efficacité de notre protocole de routage diminue avec

l’accroissement de la mobilité des nœuds. Les protocoles utilisant une gestion locale de

l’environnement mettent plus de temps pour détecter la perte d’un lien. De fait avec l’accroissement de

la mobilité, la bande passante utile de notre protocole et du protocole AODV Hello diminue plus vite

qu’avec le protocole AODV.

Notre deuxième contribution s’attache à diminuer le nombre d’informations de routage nécessaires à

la détermination d’une route. Les informations de routage sont dirigées seulement en direction de la

destination. Pour diriger ces informations vers la destination, le protocole de routage doit connaître la

position de la destination. Nous proposons un protocole de localisation qui détermine avec un faible

coût sur le réseau MANET la position d’un nœud. Un réseau à backbone est utilisé pour mener cette

tâche à bien. Les informations de position transitent principalement sur le réseau à backbone réduisant

le coût de tels échanges sur le réseau MANET. Par simulation, notre protocole de localisation est

comparé à un protocole de localisation utilisant un serveur fixe. Quelque soit la mobilité et le nombre

de nœuds présents sur le réseau, la surcharge de notre protocole sur le réseau MANET est bien plus

faible que celle du serveur fixe. Le délai d’obtention de la position d’un nœud est de même plus faible.

Pour réduire les informations de routage, nous proposons deux protocoles effectuant une recherche de

parcours en profondeur. Le premier protocole de routage est un protocole optimal. De fait, il détermine

173

une route s’il en existe une. Ce protocole accroît la zone de recherche lorsqu’une tentative pour

déterminer une route échoue. Lors de chaque tentative, l’ensemble des nœuds retransmettent les

informations de routage. Le deuxième protocole est non optimal. Lors d’une nouvelle tentative, seuls

les nœuds n’ayant pas participé à la tentative précédente peuvent relayer les informations de routage.

Ces deux protocoles sont comparés aux protocoles AODV et AODV avec une recherche de parcours

en largeur. En moyenne, nos deux protocoles utilisent près de 6 fois moins d’informations de routage

que le protocole AODV pour déterminer une route. Le deuxième protocole nécessite moins

d’informations de routage que notre premier protocole pour trouver une route. Par contre, les risques

(bien que faibles) de ne pas trouver de routes sont plus importants avec ce protocole. Nos deux

protocoles sont particulièrement efficaces lorsque la densité du réseau est élevée.

Notre dernière contribution s’applique à augmenter la bande passante utile dans un réseau tout en

garantissant des contraintes de délai et bande passante. La garantie de telles contraintes nécessite la

réservation de ressources. Nous utilisons la méthode d’accès au support TDMA pour garantir la bande

passante requise par les applications. Lorsqu’un flux réserve un ensemble de slots, une telle

réservation influe sur les voisins des nœuds du chemin. La sélection d’un chemin dont les nœuds

influent fortement sur leurs voisins réduit d’autant la bande passante utile du réseau. Nous proposons

un protocole de routage dont les nœuds d’un chemin influent le moins possible sur les nœuds présents

sur le réseau. Notre protocole pénalise plus fortement le nombre de voisins des nœuds d’un chemin par

rapport au délai à respecter. Nous comparons l’efficacité de notre protocole avec le protocole

sélectionnant le chemin de plus faible délai (noté LD). Notre protocole a un impact moins important

que le protocole LD sur le nombre de voisins du chemin sélectionné. Le nombre de slots restant libres

est donc plus important avec notre protocole. Il peut donc accepter un plus grand nombre de flux.

7.2 Expérience

Notre expérience dans la conception de nos approches nous a apporté nombre de leçons. En premier

lieu, la comparaison de nombreux protocoles de routage est une tâche difficile à effectuer du fait des

solutions souvent très différentes apportées pour résoudre les problèmes de routage. Les protocoles de

routage doivent se focaliser sur un problème particulier pour être réellement efficaces. Ensuite, pour

résoudre efficacement un problème donné, les facteurs sur lesquels doivent intervenir le protocole de

routage ne sont pas forcément évidents à isoler. Il est nécessaire de réaliser une approche minutieuse,

pour former une fonction poids combinant ces différents facteurs. Enfin, la réalisation de simulations

permet de confronter les protocoles de routage proposés avec les protocoles existants. Cette phase est

importante car un protocole de routage peut avoir un fonctionnement imprévu dans un scénario réel.

7.3 Critiques et orientations futures

Si les contributions apportées dans le cadre de nos travaux ont résolu certains problèmes, quelques

points restent à étudier. Ces points sont autant d’orientations futures dans la continuité de nos travaux.

174

Nous distinguons trois types d’orientations futures selon le temps estimé pour leur réalisation. Des

exemples d’orientations à court terme sont :

• Une première orientation est de proposer une solution générale pour notre protocole garantissant le

délai. Du fait, qu’il nécessite une couche MAC divisé en slot, il n’est guère dépendant du protocole

d’accès au support sous-jacent. Il serait intéressant de proposer une solution cross-layer pour profiter

pleinement des avantages de notre protocole de routage.

• Un point intéressant serait aussi d’étendre notre protocole optimal réalisant une recherche de

parcours en profondeur (cf. §5) pour qu’il passe encore plus efficacement à l’échelle. Lors d’une

nouvelle tentative de découverte de route, seuls les nœuds en bordure de zone de recherche sont utiles

à la transmission des informations de routage. Le nombre d’informations de routage échangées par

notre protocole peut être réduit.

• Une autre orientation serait l’amélioration du protocole de routage garantissant le délai et la bande

passante (cf. §6) pour qu’il retourne le chemin de plus faible délai au cas où aucune route n’est trouvée

avec notre fonction poids.

Nous donnons aussi trois autres orientations à moyen terme à donner à nos travaux :

• Le premier point prévoie de combiner les approches de réduction du nombre de collision et de

gestion de l’espace de recherche pour fournir une solution complète. Cette solution devrait permettre

de tirer profit des avantages de ces deux solutions et d’en combler les inconvénients.

• Notre protocole de routage réduisant le nombre de collisions perd en efficacité avec

l’accroissement de la mobilité des nœuds. Il serait intéressant que notre protocole de routage

sélectionne plusieurs routes lors d’une recherche pour le rendre plus réactif lors de la coupure d’un

lien.

• Nos protocoles de routage augmentant la bande passante disponible doivent avoir un impact positif

sur la consommation énergétique des nœuds. En effet, note protocole de routage réduisant les

collisions (cf. §4) diminue le nombre de retransmissions. De fait, les nœuds consomment moins

d’énergie pour transmettre correctement un paquet. Nos protocoles réduisant les informations de

routage (cf. §5) nécessitent moins d’informations de routage pour obtenir une route. De fait, la phase

de découverte des routes a un impact réduit sur la consommation énergétique des nœuds.

Enfin, dans une optique à plus long terme, un point très intéressant à aborder est de simuler nos

différentes approches dans des environnements plus aléatoires que le simple modèle de mobilité RWP.

Ainsi, des modèles de mobilité de groupes peuvent être utilisés pour simuler les protocoles des

chapitres 4 et 6. Ces protocoles pénalisent le nombre de nœuds voisins d’un chemin. Ces protocoles

doivent être plus efficaces pour de tels modèles de mobilité. De même, il peut être envisagé une

expérimentation sur des équipements réels permettant l’évalutation de nos protocoles dans des

conditions réelles.

175

Bibliographie

[ABD 06-1] A. Abdrabou and W. Zhuang, “A position-based qos routing scheme for UWB

mobile ad hoc networks”, IEEE J. Select. Areas Commun., vol. 24, pp. 850.856,

Apr. 2006.

[BAD 03-1] H. Badis, A. Munaretto, K. Al Agha and G. Pujolle. “Qos for Ad Hoc Networking

Based on Multiple Metrics : Bandwith and Delay”. In IEEE international

conference on Mobile and Wireless CommunicationsNetworks (MWCN 2003),

2003.

[BAR 01-1] M. Barry, A. T. Campbll and A. Veres. “Distributed Control Algorithms for

Service Differentiation in Wireless Packet Networks”. In IEEE INFOCOM 2001,

pp. 582–590, 2001.

[BAR 03-1] L. Barolli, A. Koyama, and N. Shiratori, “A QoS routing method for ad-hoc

networks based on genetic algorithm”, in Proc. 14th Int. Wksp. Database and

Expert Systems Applications, pp. 175-179, Sep. 2003.

[BAS 98-1] S. Basagni, I. Chlamtac, V. R. Syrotiuk, and B. A. Woodward, ”A distance routing

effect algorithm for mobility (DREAM),” in ACM/IEEE International Conference

on Mobile Computing and Networking (Mobicom98), 1998,pages 76 - 84

[BEL 99-1] Belding-Royer, E.M., and C.-K. Toh,. “A review of current routing protocols for

ad-hoc mobile wireless networks”, IEEE Personal Communications Magazine, pp.

46–55, 1999

[BET 02-1] C. Bettstetter, H. Hartenstein, and X. Pérez-Costa, “Stochastic Properties of the

Random Waypoint Mobility Model: Epoch Length, Direction Distribution, and Cell

Change Rate,” ACM MSWiM’02, 2002

176

[BHA 04-1] B. Bhargava, X. Wu, Y. Lu, and W. Wang, “Integrating heterogeneous wireless

technologies: a cellular aided mobile ad hoc network (CAMA)”. Mobile Networks

and Applications v9, pp. 393-408, 2004.

[BHA 94-1] Vaduvur Bhargavan, Alan Demers, Scott Shenker, et Lixia Zhang, “MACAW: a

media access protocol for wireless LAN’s”, In Proceedings of the conference on

Communciations architectures, protocols and applications (ACM Sigcomm’94), pp.

212-225, August 1994

[BLA 01-1] L. Blazevic, L. Buttyan, S. Capkun, S. Giordano, J. Hubaux, and J. Le Boudec,

"Self-Organization in Mobile Ad Hoc Networks: The Approach of Terminodes,"

IEEE Communications Magazine, June 2001.

[Bluetooth] Bluetooth Special Interest Group, http://www.bluetooth.org/.

[BOU 02-1] Azzedine Boukerche, Vaidya Sheetal, Myongsu Choe, "A Route Discovery

Optimization Scheme Using GPS System," 35th Annual Simulation

Symposium, 2002

[CAM 02-1] T. Camp, J. Boleng, and V. Davies, “A Survey of Mobility Models for Ad hoc

Network Research,” Wireless Communication and Mobile Computing (WCMC),

Special issue on Mobile Ad hoc Networking Research Trends and Applications,

vol. 2, no. 5, pp. 483-502, 2002

[CAN 99-1] Cansever D.H., Michelson A.M., Levesque A.H., “ Quality of Service Support in

Mobile ad-hoc IP Networks”, IEEE Military Communications Conferences,

Atlantic City, USA, pp. 30-34, October 1999.

[CHA 04-1] C. Chaudet, Thèse à l’Institut National des Sciences Appliquées de Lyon, “Autour

de la réservation de bande passante dans les réseaux ad hoc”, September 2004.

[CHE 04-1] Y. S. Chen, Y. C. Tseng, J. P. Sheu, and P. H. Kuo, “An on-demand, link-state,

multi-path QoS routing in a wireless mobile ad-hoc network”, Computer

communication, vol 27, no. 1, pp.27-40, Jan, 2004.

[CHE 05-1] L. Chen and W. Heinzelman, “QoS-aware routing based on bandwidth estimation

for mobile ad hoc networks”, IEEE J. Select. Areas Commun., vol. 23, pp. 561.572,

Mar. 2005.

[CHE 06-1] Chen C., Pei C., An L., “Available Bandwidth Estimation in IEEE 802.11b

Network Based on Non-Intrusive Measurement”, Seventh IEEE International

Conference on Parallel and Distributed Computing, Applications and Technologies,

2006.

[CHE 97-1] T.-W. Chen, J. T. Tsai, and M. Gerta, ”QoS routing performance in multihop,

multimedia, wireless networks”, in Proc. IEEE 6th Int. Conf. Universal Personal

Communications, vol. 2, pp. 557-561, Oct 1997.

[CHE 98-1] T.-W. Chen, M. Gerla, “Global state routing: a new routing scheme for ad-hoc

wireless networks”, in: Proceedings of the IEEE ICC, 1998.

177

[CHE 99-1] S. Chen, K. Nahrstedt, “Distributed Quality-of-Service Routing in Ad Hoc

Networks”, IEEE Journal on Selected Areas in Communications, pp. 1488-1504,

August 1999.

[CHI 97-1] C.-C. Chiang, “Routing in clustered multihop mobile wireless networks with fading

channel”, in: Proceedings of IEEE SICON, April 1997, pp. 197–211.

[COR 90-1] T.H. Cormen, C.E. Leiserson et R.L. Rivest, Introduction to Algorithms, The MIT

Press and McGraw-Hill Book Company, 1990.

[COR 95-1] M.S. Corson, A. Ephremides, “A distributed routing algorithm for mobile wireless

networks”, ACM/Baltzer Wireless Networks 1 (1) (1995) 61–81.

[CRK 89-1] C. Cheng, R. Riley, S. Kumar et J.J. Garcia-Luna-Aceves. A Loop-Free Bellman-

Ford Routing Protocol without Bouncing Effect. ACM SIGCOMM’89. Sept 1989

[DHA 05-1] S. Dhar, MANET: Applications, Issues and Challenges for the Future, International

Journal of Business Data Communications and Networking, Vol. 1, No. 2, April -

June 2005, Pages 66-92.

[DU 04-1] X. Du, “QoS Routing Based on Multi-Class Nodes for Mobile Ad Hoc Networks,”

Ad Hoc Networks, Elsevier, Vol. 2, Issue 3, pp 241–254, July 2004.

[EPH-87] Anthony Ephremikdes, Jeffrey E. Wieselthier and Dennis J. Baker, “A Design

concept for reliable mobile radio networks with frequency hopping signalling”, in

Proceedings of IEEE, 1987

[ESP 06-1] David Espes, Zoubir Mammeri. “Routing Algorithm to Increase throughput in Ad

hoc Networks”, 5th IEEE International Conference on Networking (ICN’06),

Mauritius, 23/04/2006-28/04/2006, IEEE, p. 1-6, 2006.

[ESP 06-2] David Espes, Zoubir Mammeri. “Backbone-based Location-Aided Routing

Algorithm to Reduce Control packets of AODV protocol”, International conference

on Mobile Technology, Applications and Systems, Bangkok, Thailand, 25/10/2006-

27/10/2006, ACM, p. 1-6, octobre 2006.

[ESP 07-1] David Espes, Cédric Teyssié. “Approach for Reducing Control Packets in AODV-

based MANETs”, IEEE 4th European Conference on Universal Multiservice

Networks, Toulouse, France, 14/02/2007-16/02/2007, IEEE, p. 1-10, février 2007.

[ESP 07-2] David Espes, Zoubir Mammeri. “Improvement of AODV Routing in Dense

networks”, IEEE International Symposium on a World of Wireless, Mobile and

Multimedia Networks Helsinki, Finland, 18-21 June 2007.

[ESP 07-3] David Espes, Zoubir Mammeri. “Adaptive expanding search methods to improve

AODV Protocol”. 16th IST Mobile & Wireless Communications Summit.

Budapest, Hungary 1-5 July 2007.

[ETSI 98-1] ETSI, Universal Mobile Telecommunications System (UMTS), “Selection

Procedures for the Choice of Radio Transmission Technologies of the UMTS,”

Technical Report, TR 101 112 v 3.2.0 (1998)

178

[ETSI 98-1] ETSI BRAN. “High Performance Radio Local Area Network (HIPERLAN) Type 1

– Functional specification”, July 1998.

[FAN 04-1] Z. Fan, “QoS routing using lower layer information in ad hoc networks”, in Proc.

Personal, Indoor and Mobile Radio Communications Conf., pp. 135-139, Sep.

2004.

[FUL 97-1] C. Fullmer et J.J. Garcia-Luna-Aceves. “Solutions to Hidden Terminal Problems in

Wireless Networks”. Proceedings of ACM SIGCOMM'97, 1997

[GAR 99-1] J.J. Garcia-Luna-Aceves, C. Marcelo Spohn, “Source-tree routing in wireless

networks”, in: Proceedings of the Seventh Annual International Conference on

Network Protocols Toronto, Canada, October 1999, p. 273.

[GER 02-1] M. Gerla, “Fisheye state routing protocol (FSR) for ad hoc networks”, Internet

Draft, draft-ietf-manet-aodv-03.txt, work in progress, 2002.

[GER-04] M. Gerla and K. Xu, “Topology management of hierarchical mobile ad hoc

networks”, In Resource Management in Wireless Networking, Kluwer Academic

Publisher, 2004

[GER-95] M. Gerla and J. T.-C. Tsai, “Multicluster, Mobile Multimedia Radio Networks”,

Wireless networks, 1995

[GPS] Navstar GPS operation, http://tycho.usno.navy.mil/ gpsinfo.html.

[GUO 01-1] S. Guo and O. Yang, “Backup Source Routing in Wireless Ad Hoc Networks,” Int'l

Conf. Software, Telecomm., and Computer Networks (SoftCOM), pp. 295-302,

Oct. 2001.

[GUP 05-1] R. Gupta, Z. Jia, T. Tung, and J. Walrand, “Interference-aware qos routing

(IQRouting) for ad-hoc networks”, in Proc. Global Telecommunications Conf., vol.

5, pp. 2599.2604, Nov. 2005.

[HAD 99-1] Z. Hadzi-Velkov and L. Gavrilovska, “Performance of the IEEE 802.11 Wireless

LANs and Influence of Hidden Terminals”, TELSIKS’99, Yugoslavia, October

1999.

[HAN 07-1] L. Hanzo and R. Tafazolli, “A survey of QoS routing solutions for mobile ad hoc

networks”, IEEE Communi. Surv. and Tutor., vol. 9, no. 2, pp. 50–70, 2007.

[HAS 99-1] Z.J. Hass, R. Pearlman, “Zone routing protocol for ad-hoc networks”, Internet

Draft, draft-ietf-manet-zrp-02.txt, work in progress, 1999.

[HO 02-1] Y.-K. Ho , R.-S. Liu, “A Novel Routing Protocol for Supporting QoS for Ad Hoc

Mobile Wireless Networks”, Wireless Personal Communications: An International

Journal, v.22 n.3, p.359-385, September 2002.

[HON 99-1] X. Hong, M. Gerla, G. Pei, and C. Chiang, “A group mobility model for ad hoc

wireless networks,” In proceedings of the ACM International workshop on

Modeling and Simulation of Wireless and Mobile Systems (MSWiM), August 1999

179

[HWA 03-1] Y. Hwang, P. Varshney, “An adaptive Q o S routing protocol with dispersity for

ad-hoc networks”. In Proc. the 36th Annual Hawaii International Conference on

System Sciences, January 2003, pp.302-311.

[IEEE 03-1] IEEE Standard for Information Technology – Telecommunications and Information

Exchange between Systems. “Local and Metropolitan Area Network – Specific

Requirements – Part 11 : Wireless LAN Medium Access Control (MAC) and

Physical Layer (PHY) Specifications — Further Higher-Speed Physical Layer

Extension in the 2.4 GHz Band”, 2003.

[IEEE 85-1] IEEE Computer Society Std 802.3-1985. “Carrier Sense Multiple Access with

Collision Detection (CSMA/CD) Access Method and Physical Layer

Specifications”, The Institue of Electrical and Electronics Engineers, 1985.




Physical Layer (PHY) Specifications”, 1997.




Physical Layer (PHY) Specifications — Higher-speed physical layer extension in

the 2.4 GHz band”, 1999.




Physical Layer (PHY) Specifications — High-speed physical layer in the 5 GHz

band”, 1999.

[IET 02-1] The Zone Routing Protocol (ZRP) for Ad Hoc Networks. Z. Haas, M. Pearlman, P.

Samar. IETF Internet Draft. Jul 2002.

[IET 81-1] Internet Protocol. RFC 791, Internet Engineering Task Force. Sept 1981

[IET 93-1] G. Malkin. RIP Version 2-Carrying Additional Information. RFC 1388. Internet

Engineering Task Force. January 1993

[ISS 03-1] T. Issariyakul, E. Hossain et D. Kim. “Medium access control protocols for

wireless mobile ad hoc networks: issues and approaches”. WCMC, vol. 3, Dec

2003

[JAI 01-1] R. Jain, A. Puri, and R. Sengupta. “Geographical routing using partial information

for wireless ad hoc networks”. IEEE Personal Communications, 8(1):48--57,

February 2001.

[JAW 04-1] I. Jawhar and J. Wu, “Quality of Service Routing in Mobile Ad Hoc Networks”,

Resource Management in Wireless Networking, 2004.

180

[JAW 04-2] I. Jawhar and J. Wu. “A race-free bandwidth reservation protocol for QoS routing

in mobile ad hoc networks”. Proc. of the 37th Annual Hawaii International

Conference on System Sciences (HICSS’04), IEEE Computer Society, 2004.

[JAW 05-1] I. Jawhar and J. Wu, “QoS Support in TDMA-Based Mobile Ad Hoc Networks”, J.

Comput. Sci. Technol, 20(6), pp. 797-810, 2005.

[JAW 05-2] I. Jawhar and J. Wu. “A dynamic range resource reservation protocol for QoS

support in wireless networks”. Proc. of the 3rd ACS/IEEE International Conference

on Computer Systems and Applications (AICCSA-05), January 2005.

[JIA 99-1] M. Jiang, J. Ji, Y.C. Tay, “Cluster based routing protocol”, Internet Draft, draft-ietf-

manet-cbrp-spec-01.txt, work in progress, 1999.

[JOA 99-1] M. Joa-Ng, I.-T. Lu, “A peer-to-peer zone-based two-level link state routing for

mobile ad hoc networks”, IEEE Journal on Selected Areas in Communications 17,

pp. 1415–1425, 1999.

[KAR 00-1] B. Karp and H. T. Kung, ”GPSR: Greedy Perimeter Stateless Routing for Wireless

Networks,” Proc. 6th Annual International Conference on Mobile Computing and

Networking (MobiCom 2000), Boston, MA, USA, 2000, pp. 243-254.

[KAS 97-1] K.K. Kasera, R. Ramanathan, “A location management protocol for hierarchically

organised multihop mobile wireless networks”, in: Proceedings of the IEEE

ICUPC_97, San Diego, CA, October 1997, pp. 158–162.

[KAZ 02-1] Kazantsidis M., Gerla M., “End to End versus Explicit Feedback Measurement in

802.11 Networks”, Seventh International Symposium on Computers and

Communications, Taormina, Italy, pp. 429-434, July 2002.

[KLE 99-1] J. Kleinberg, Y. Rabani and E. Tardos, “Fairness in routing and load balancing”,

40th Annual Symposium on Foundations of Computer Science, 1999, pp. 568-578.

[KO 98-1] Y.-B. Ko and N. H. Vaidya, ”Location-aided routing (LAR) in mobile ad hoc

networks”, in ACM/IEEE International Conference on Mobile Computing and

Networking (Mobicom98), 1998, pages 66-75.

[LAB 02-1] Labiod H., Quidelleur, “QoS-ASR: An Adaptive Source Routing Protocol with

QoS Support in Multihop Mobile Wireless Networks”. IEEE VTC’02, pp. 1978-

1982. 2002.

[LEE 06-1] Lee H.K., Hall V., Yum K.H., Kim K.L., Kim E.J., “Bandwidth Estimation in

Wireless LANs for Multimedia Streaming Services”, IEEE International

Conference on Multimedia and Expo, pp. 1181-1184, 2006.

[LI 00-1] J. Li, J. Jannotti, D. S. J. De Couto, D. R. Karger, and R. Morris. A scalable

location service for geographic ad hoc routing. In MOBICOM 2000, PP. 120-130,

Boston, USA, 2000.

[LIA 01-1] Wen-Hwa Liao, Tu-Chee Tseng, and Jang-Ping Sheu, “GRID: A Fully Location-

Aware Routing Protocol for Mobile Ad Hoc Networks”, Telecommunication

Systems, 2001.

181

[LIA 02-1] W. H. Liao, Y. C. Tseng and K. P. Shih, “A TDMA-based bandwidth reservation

protocol for QoS routing in a wireless mobile ad hoc network”, IEEE International

Conference on Communications, ICC 2002, 2002.

[LIN 99-1] C. R. Lin and J.-S. Liu, “Qos routing in ad hoc wireless networks”, IEEE J. Select.

Areas Commun., vol. 17, pp. 1426-1438, Aug. 1999.

[LIN 99-2] C. R. Lin, “Admission control in time-slotted multihop mobile networks”, IEEE

Journal on Selected Areas in Communications, 1999.

[MA 97-1] Q. Ma and P. Stennkiste, “On path selection for traffic with bandwidth guarantees”,

5th IEEE ICNP’97, October 1997, pp. 191-202.

[MAR 01-1] M. K. Marina, and S. R.Das, “On-demand Multipath Distance Vector Routing for

Ad Hoc Networks,” Proc. of 9th IEEE Int. Conf. On Network Protocols, pp.14-23,

2001.

[MAS 06-1] X. Masip-Bruin et al., « Research challenges in QoS routing », Computer

Communications, 19(5), pp. 563-581, 2006.

[MAU 01-1] M. Mauve, J. Widmer and H. Hartenstein, “A survey on position-based routing in

mobile ad hoc networks”, IEEE Network Magazine. v15 i6, 2001, pp. 30–39.

[MEH 03-1] Mehran Abolhasan, Tadeusz Wysocki, and Eryk Dutkiewicz. “A review of routing

protocols for mobile ad hoc networks”. Technical report, Telecommunication and

Information Research Institute, Australia, 2003.

[MEL 00-1] Melander B., Bjorkman M., Gunningberg P., “A New End-to-End Probing and

Analysis Method for Estimating Bandwidth Bottlenecks”, IEEE Global

Telecommunication Conference, San Francisco, USA, pp. 415-420, November

2000.

[MER 05-1] Amina Meraihi Naimi. Délai et Routage dans les réseaux ad hoc 802.11. PhD

thesis, Université de Versaille Saint-Quentin-En-Yvelines, 2005.

[MER-04] R. Meraihi, G. Le Grand, N. Puech, M. Riguidel and S. Tohmé, “improving ad hoc

network performance with backbone topology control”, In VTC Fall 2004, USA,

September 2004

[MOH 03-1] P. Mohapatra, J. Li, and C. Gui, "QoS in Mobile Ad Hoc Networks," IEEE

Wireless Comm., June 2003, pp. 44-53.

[MUN 02-1] A. Munaretto, H. Badis, K . AL agha and G. Pujolle. “A Link-state QoS Routing

Protocol for Ad Hoc Networks”. In IEEE MWCN’02 : International Workshop On

Mobile and Wireless Communications Networks, Sweden, September 2002.

[MUR 95-1] S. Murthy J.J. Garcia-Luna-Aceves, “A routing protocol for packet radio

networks”, in: Proceedings of the First Annual ACM International Conference on

Mobile Computing and Networking, Berkeley, CA, 1995, pp. 86–95.

[NGU 07-1] D. Q. Nguyen, P. Minet, “Quality of Service Routing in a MANET with OLSR”,

JUCS, Journal of Universal Computer Science, Vol. 13, No. 1, pp. 55-86, March

2007.

182

[OZD 04-1] Mustafa Ozdemir, A. Bruce McDonald. “An M/MGI/1/K Queing Model for IEEE

802.11 Ad hoc Networks”. In PE-WASUN’04, Italy, October 2004.

[PAR 83-1] B. Parkinson and S. Gilbert, “Navstar: global positioning system – ten years later”,

Proceedings of IEEE, pp. 1177-1186, 1983.

[PAR 97-1] V.D. Park, M.S. Corson, “A highly adaptive distributed routing algorithm for

mobile wireless networks”, in: Proceedings of INFOCOM, April 1997.

[PAR-94] Abhay K. Parekh, “Selecting routers in ad-hoc wirelees networks”, in ITS, 1994

[PEI 00-1] G. Pei, M. Gerla and X. Hong, LANMAR: Landmark Routing for Large Scale.

Wireless Ad Hoc Networks with Group Mobility, Proc. IEEE/ACM Mobi-HOC

2000, Boston, MA, Aug. 2000, pp. 11-18.

[PEI 99-1] G. Pei, M. Gerla, X. Hong, C. Chiang, “A wireless hierarchical routing protocol

with group mobility”, in: Proceedings of Wireless Communications and

Networking, New Orleans, 1999.

[PER 00-1] Charles E. Perkins, Elizabeth M. Royer, and Samir R. Das. "Quality of Service in

Ad hoc On-Demand Distance Vector Routing". IETF Internet Draft, draft-ietf-

manet-qos-00.txt, July 2000 (Work in Progress).

[PER 94-1] C.E. Perkins, T.J. Watson, Highly dynamic destination sequenced distance vector

routing (DSDV) for mobile computers, in: ACM SIGCOMM_94 Conference on

Communications Architectures, London, UK, 1994.

[QoS] Recommendation E800. Terms and Definitions Related to QoS and Network

Performance Including Dependability. Août 1994. TeIecommunication

Standardization Sector of ITU-T.

[RAG 98-1] Raghupathy Sivakumar, Bevan Das, and Vaduvur Bharghavan, “Spine Routing in

Ad hoc Networks”. ACM/Baltzer Publications Cluster Computing Journal, Special

Issue on Mobile Computing, 1998

[RAM 03-1] Ramasubramanian, Z.J. Haas, and E.G. Sirer, “SHARP: A Hybrid Adaptive

Routing Protocol for Mobile Ad Hoc Networks,” Proc. MOBIHOC Conf. 2003, pp.

303-314, June 2003.

[RED 06-1] T. Bheemarjuna Reddy et al., “Quality of Service Provisioning in Ad Hoc Wireless

Networks: A Survey of Issues and Solutions,” Ad Hoc Networks, vol. 4, no. 1, Jan.

2006, pp. 83–124.

[RFC 2328] J. Moy, RFC 2328, “OSPF Version 2”, 1998

[RFC 2453] G. Malkin, RFC 2453, “RIP Version 2”, 1998.

[RFC 2501] S. Corson and J. Macker, RFC 2501, “Mobile Ad hoc Networking (MANET):

Routing Protocol Performance Issues and Evaluation Considerations”, January

1999.

[RFC 3561] C. Perkins, E. Belding-Royer and S. Das, RFC 3561, “Ad hoc On-Demand

Distance Vector (AODV) Routing”, July 2003.

183

[RFC 3626] T. Clausen, P. Jacquet, RFC 3626, “Optimized Link State Routing Protocol

(OLSR)”, 2003.

[RFC 4728] D. Johnson, Y. Hu, D. Maltz, RFC 4728, “The Dynamic Source Routing Protocol

(DSR) for Mobile Ad Hoc Networks for IPv4”, February 2007.

[ROM 05-1] L. Romdhani, C. Bonnet, “A Cross-Layer On-Demand Routing Protocol for Delay-

Sensitive Applications”, 16th IEEE Annual International Symposium on Personal

Indoor and Mobile Radio Communications, Berlin, September 2005.

[ROY 01-1] E. Royer, P.M. Melliar-Smith, and L. Moser, “An Analysis of the Optimum Node

Density for Ad hoc Mobile Networks,” Proceedings of IEEE ICC, 2001

[RUB-01] I. Rubin, A. Behzad, R. Zhang, H. Luo and E. Caballero, “TBONE: A Mobile-

Backbone Protocol for Ad Hoc Wireless Networks”, MMNS 2001, pp. 215-221

[RUB-05] I. Rubin, A. Behzad, H.-J. Ju, R. Zhang, X. Huang, Y. Liu, R. Khalaf and J. Hsu,

“Ad hoc Wireless Networks with Mobile Backbone”, chapter 9 Kluwer, 2005

[RUB-99] I. Rubin, X. Huang, Y. C. Liu and H.-J. Ju, “A distributed stable backbone

maintenance protocol in wireless ad hoc networks”, In International Workshop on

Discrete Algorithms and Methods for mobile Computing and Communications

(DIAL’M), Seattle, USA, August 1999

[RUP 97-1] R. Ruppe, S. Griswald and R. Martin, “Near term digital radio (NTDR) system”, in:

Proc. IEEE MILCOM 97, Monterey, October 1997.

[SAN 99-1] M. Sanchez and P. Manzoni, “A Java-based ad-hoc networks simulator,” SCS

Western Multiconference, San Francisco, California, January 1999

[SHE 01-1] S.-T. Sheu, J. Chen, “A Novel Delay-Oriented Shortest Path Routing Protocol for

Mobile Ad hoc Networks”, IEEE International Conference on Communications, pp.

1930-1934, 2001.

[SHE 03-1] M. Sheng, J. Li, and Y. Shi, “Routing protocol with QoS guarantees for ad-hoc

network”, Electronics Letters, vol. 39, pp. 143-145, Jan. 2003.

[SIV 99-1] R. Sivakumar, P. Sinha, and V. Bharghavan, “CEDAR: a coreextraction distributed

ad hoc routing algorithm”, IEEE J. Select. Areas Commun., vol. 17, pp. 1454.1465,

Aug. 1999.

[SON 03-1] J.H. Song, V.W.S Wong and V.C.M. Leung, “Load-Aware On-demand Routing

(LAOR) Protocol for Mobile Ad-hoc networks”, in Proc. IEEE VTC Spring’03,

Jeju, Korea, Apr. 2003.

[STA 88-1] J. A. Stankovic, “Misconceptions About Real Time Computing”, IEEE Computer,

Volume 21, Number 10, October 1998

[STI 04-1] J. Stine and G. de Veciana, ”A paradigm for quality of service in wireless ad hoc

networks using synchronous signalling and node states”, IEEE J. Select. Areas

Commun., vol. 22, pp. 1301-1321, Sep. 2004.

184

[TIC 04-1] Omesh Tickoo and Biplab Sikdar. Queueing Analysis and Delay Mitigation in

IEEE 802.11 Random Access MAC based Wireless Networks. In IEEE Infocom,

2004.

[TOH 96-1] C. Toh, “A novel distributed routing protocol to support ad-hoc mobile

computing”, in: IEEE 15th Annual International Phoenix Conf., 1996, pp. 480–486.

[TUR 01-1] D. Turgut, S. K. Das, and M. Chatterjee, “Longevity of Routes in Mobile Ad hoc

Networks,” Proceedings of IEEE VTC-spring’01, 2001

[VER 00-1] A. Veres, A. Campbell, M. Barry and L-H SUN. “Supporting Service

Differentation in Wireless Packet Networks Using Distributed Control”, IEEE

Journal on Selected Areas in Communications, 19 :10, October 2000.

[WAN 02-1] J. Wang and K. Nahrstedt, “Hop-by-Hop Routing Algorithm for Premium-class

Traffic in Diffserv Networks”, INFOCOM 2002, June 2002

[WAN 01-1] J. Wang, Y. Tang, S. Deng, J. Chen, “QoS routing with mobility prediction in

MANET” . In 2001 IEEE Pacific Rim Conference on Communications, Computers

and Signal Processing, 2001, PACRIM , pp. 357-360, August 2001.

[WAN 05-1] M. Wang and G.-S. Kuo, ”An application-aware QoS routing scheme with

improved stability for multimedia applications in mobile ad hoc networks”, in Proc.

IEEE Vehicular Technology Conf., pp. 1901.1905, Sep. 2005.

[WAN 96-1] Zhen Wang et Jon Crowcroft, “Quality of service routing for supporting

multimedia applications”, IEEE Journal on Selected Areas in Communications,

1996.

[WAN 96-2] Z. Wang and J. Crowcroft. “Qos routing for supporting resource reservation”. IEEE

Journal on selected areas in communications, 14:1228–1234, 1996.

[WiFi] WiFI Alliance. http://wi-fi.org/.

[XIA 02-1] Xiaoyan Hong, Kaixin Xu, and Mario Gerla. Scalable routing protocols for mobile

ad hoc networks. 2002.

[XUE 03-1] Q. Xue and A. Ganz, ”Ad hoc QoS on-demand routing (AQOR) in mobile ad hoc

networks,” ACDEMIC PRESS: Journal of Parallel and Distributed Computing, vol.

41, pp. 120-124, June 2003.

[YAN 05-1] Y. Yang and R. Kravets, “Contention-aware admission control for ad hoc

networks”, IEEE Trans. Mobile Comput., vol. 4, pp. 363-377, Aug 2005.

[ZHA 04-1] B. Zhang and H.T. Mouftah, “QoS Routing through Alternate Paths in Wireless Ad

Hoc Networks,” Int'l J. Comm. Systems, vol. 17, no. 3, pp. 233-252, Mar. 2004.

[ZHA 05-1] B. Zhang and H. T. Mouftah, “QoS routing for wireless ad hoc networks: problems,

algorithms and protocols”, IEEE Commun. Mag., vol. 43, pp. 110.117, Oct. 2005.

[Zigbee] Zigbee Alliance, http://www.zigbee.org/.

185

[ZON 97-1] M. Zonoozi and P. Dassanayake, “User Mobility Modeling and Characterization of

Mobility Patterns,” IEEE Journal on Selected Areas on Communication, vol. 15,

pp: 1239-1252, September 1997.

Annexes

189

I Compléments

A.1.1 Protocole de routage AODV A la réception d’un paquet de routage, le fonctionnement d’un nœud, exécutant le protocole AODV,

est différent suivant sa position dans le chemin. De fait, les organigrammes des nœuds sont donnés

pour le protocole AODV avec émission d’une réponse RREP seulement par le nœud de destination.

190

A.1.1.1 Organigramme du nœud source

Figure A-1 : Organigramme du nœud source


DEBUT

- Crée un RREQ


identifiant de diffusion

- Génère un nouveau


- Met à jour les champs

de la requête

- Diffuse RREQ

- Arme le temporisateur

Trep

RREP reçu?- Arrête Trep

- Envoie les

données

oui

non

Trep expiré?

nonoui

Nrp++

Nrp Nrpmax?oui

non

Informe la couche supérieure

Direction la

phase de

traitement des

données

Data transmission

RERR received?

yes no

191

A.1.1.2 Organigramme d’un nœud intermédiaire

Figure A-2 : Organigramme d’un nœud intermédiaire

DEBUT

RREQ reçu d’un nœud i?

oui

non

Déjà reçu un RREQ pour la

paire (source, id_diffusion) ?

oui

non

- Créer une

nouvelle entrée

dans la table des

chemins inverses

Supprimer

la requête


de la table des chemins

inverses correspondant

au nœud source

RREP reçu?

non

oui

une entrée dans la table de

routage pour le nœud

destination?

ouinon

nsd plus récent

ou identique mais

meilleur poids ?

- Créer une nouvelle

entrée dans la table

de routage

oui non

- Transmettre le RREP au nœud

précédent contenu dans la table

des chemins inverses pour le

nœud source

Supprimer

la requête

une entrée dans la table des

chemins inverses pour le

nœud source?

ouinon

nss plus récent

ou identique mais

meilleur poids ?


de la requête


oui non

Supprimer

la requête

192

A.1.1.3 Organigramme du nœud destination

Figure A-3 : Organigramme d’un nœud destination

193

Throughput optimization and delay guarantee for reactive routing

protocols in ad hoc networks

Abstract:

Mobile ad-hoc networks (MANETs) are a specific king of wireless networks that can be quickly

deployed without pre-existing infrastructures. They are used in different contexts such as collaborative,

medical, military or embedded applications.

However, MANETs rise new challenges when they are used to support multimedia or real time

applications (e.g., videoconference, VoIP, Video on Demand, etc) that require constraints on Quality

of Service like the delay or the bandwidth. Indeed, these networks undergo drawbacks due to both the

characteristics of the transmission medium (transmission medium sharing, low bandwidth, etc) and the

routing protocols (information diffusion, path calculation, etc).

The goal of our work is to optimize the bandwidth throughput in order to support multimedia and real

time applications. Because MANETs are multihops, the impact of the routing protocols is crucial.

Three axes have been investigated to increase the bandwidth in MANETs: reduction of the collisions,

reduction of the routing information and guarantee of the bandwidth and the delay.

Keywords: MANETs, routing, QoS routing, real-time application, throughput, delay

Protocoles de routage réactifs pour l’optimisation

de bande passante et la grantie de délai

dans les réseaux ad hoc mobiles

Par David ESPÈS

Directeur de thèse : Zoubir MAMMERI

Soutenue à l’Université Toulouse III – Paul Sabatier le 27 novembre 2008

Nos travaux se situent dans le contexte des réseaux MANETs (Mobile Ad Hoc NETorks) qui constituent une

catégorie de réseaux sans fil pouvant être déployés rapidement, multi-sauts et sans infrastructure. Les réseaux

MANETs permettent la communication entre utilisateurs d’applications mobiles diverses (applications

collaboratives, urgences, militaires, embarquées…).

Cependant, ces réseaux souffrent d’inconvénients à la fois liés aux caractéristiques du medium de transmission

(partage du canal de transmission, faible débit…), mais également aux protocoles de routage (dissémination de

l’information, sélection d’un chemin…). Ces limites rendent difficile le support des applications multimédia et

temps réel (telles que la vidéoconférence, la vidéo à la demande, la VoIP…). Ces applications requièrent le

respect de contraintes de Qualité de Service (QoS) telles que la bande passante et le délai.

Le but de nos travaux est d’optimiser la bande passante disponible d’un réseau MANET pour permettre

l’utilisation d’applications fortement consommatrices en bande passante. Comme un réseau MANET est multi-

saut, l’influence des protocoles de routage sur les performances du réseau est déterminante. Trois axes ont été

étudiés pour augmenter la bande passante utile des réseaux MANETs : réduction des collisions, réduction des

informations de routage et garantie de la bande passante et du délai.

Mots-clés : Réseaux ad hoc, routage, routage à QoS, applications temps-réel, bande passante, délai

Spécialité : Informatique

Institut de Recherche en Informatique de Toulouse – UMR 5505 Université Paul Sabatier ,

118 route de Narbonne

31062 Toulouse

CEDEX 9

ad hoc bon thèse

Documents

bande passante et

proches et

toutes et tous

et tout particulirement

routage et garantie

collgues et amis

ma sur et tous

l2 informatique et iut