Post on 10-Aug-2015
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.2 Phase de maintenance ................................................................................................ 141
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.2 Phase de maintenance ................................................................................................ 144
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
Figure 4-12 : 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 1500 octets. ................................................... 98
Figure 4-13 : 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 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
Figure 4-15 : 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 1500 octets. ........................................................................... 99
Figure 4-16 : 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 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
Figure 4-18 : 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 1500 octets. ............................................................... 101
Figure 4-19 : 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 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
Figure 5-2 : 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............................................. 112
Figure 5-3 : Organigramme utilisé par la destination. L’encadré en pointillé met en valeur la partie
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
différente de notre protocole comparé au protocole AODV. ...................................................... 140
Figure 5-17 : Echec de la découverte d’une route alors qu’une existe. ............................................... 143
Figure 5-18 : Organigramme utilisé par le nœud source. L’encadré en pointillé met en valeur la partie
différente de notre protocole comparé au protocole AODV. ...................................................... 144
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.
Propriété 4-6 : La probabilité P2Saut(Z) qu’un nœud émetteur X ayant transmis un paquet à
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.
Propriété 4-7 : 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 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
,,
λλλ
λλλ−−−
+−
−−
+−−−
−−
−
−=
+−≤∧−−≥
= ∫
�
Propriété 4-8 : La probabilité P2Saut(Z) qu’un nœud émetteur X ayant transmis un paquet à
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
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
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
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
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.
4.3.3.3 Algorithme du nœud de destination
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.
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.
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.
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
Figure 4-12 : 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 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.
Figure 4-13 : 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 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.
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.
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.
Figure 4-15 : 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 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.
Figure 4-16 : 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 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.
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.
Figure 4-18 : 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 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.
Figure 4-19 : 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 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.
Figure 5-2 : 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.
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.
Figure 5-3 : Organigramme utilisé par la destination. L’encadré en pointillé met en valeur la partie
différente de notre protocole comparé au protocole AODV.
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
- 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
Pour simuler le comportement de notre protocole, nous utilisons le simulateur NS-2. Nous comparons
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
Figure 5-16 : Organigramme utilisé par le nœud source. L’encadré en pointillé met en valeur la partie
différente de notre protocole comparé au protocole AODV.
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.
Traitement des données
DEBUT
- Créer un RREQ
- Générer un nouvel
identifiant de requête
- Générer un nouveau
numéro de séquence
- Mettre à jour les champs
de la requête
- Initialiser i
- Initialiser temporisateur
Trep=TEMPS_TRAVERSE
- Diffuser la requête
- Déclencher Trep
oui
non
Trep expiré?non
oui
- i++
- Calculer αi
- Calculer δi
- Calculer le TTL
- Créer un RREQ
- Générer un nouveau
numéro de séquence
- Générer un nouvel
identifiant de requête
- Mettre à jour la requête
- Diffuser 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.
5.3.2.2 Phase de maintenance
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
Figure 5-18 : Organigramme utilisé par le nœud source. L’encadré en pointillé met en valeur la partie
différente de notre protocole comparé au protocole AODV.
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.
5.3.3.2 Phase de maintenance
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
Pour simuler le comportement de notre protocole, nous utilisons le simulateur NS-2. Nous comparons
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).
Traitement des données
DEBUT
- Créer un RREQ
- Générer un nouveau
numéro de séquence
- Initialiser LS
- Mettre à jour les champs
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.
[IEEE 97-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”, 1997.
[IEEE 99-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 — Higher-speed physical layer extension in
the 2.4 GHz band”, 1999.
[IEEE 99-2] 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 — 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
Traitement des données
DEBUT
- Crée un RREQ
- Générer un nouvel
identifiant de diffusion
- Génère un nouveau
numéro de séquence
- 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
- Mettre à jour l’entrée
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 ?
- Mettre à jour les champs
de la requête
- Diffuser 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