Espes David

T
T
H
H
S
S
E
E
En vue de l'obtention du

D DO OC CT TO OR RA AT T D DE E L L U UN NI IV VE ER RS SI IT T D DE E T TO OU UL LO OU US SE E

Dlivr par l'Universit Toulouse III - Paul Sabatier
Discipline ou spcialit : Informatique

Jury
Prsident 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 Charge de Recherche, INRIA (Rocquencourt)
Examinateur Patrick Snac Enseignant-chercheur, ISAE (Toulouse)

Ecole doctorale : Mathmatiques, Informatique et Tlcommunications de Toulouse
Unit de recherche : Institut de Recherche en Informatique de Toulouse UMR 5505
Directeur de Thse : Zoubir Mammeri
Prsente et soutenue par David Esps
Le 27 novembre 2008

Titre : Protocoles de routage ractifs pour loptimisation de
bande passante et la garantie de dlai dans les rseaux
ad hoc mobiles

ma fami l l e, mes ami s

i
Remerciements
Une thse est laccomplissement de travaux de recherche de plusieurs annes. Ce travail, bien
quenrichissant, nest pas tous les jours vident entreprendre. Le soutien des proches et des collgues
de travail permet de faire avancer ce travail, mme dans les moments les plus difficiles.
Je tiens remercier tout particulirement Zoubir Mammeri pour mavoir accueilli dans son quipe et
pour ses conseils aviss. Je le remercie pour toute la patience dont il a su faire preuve (durant la
relecture des papiers ou de la thse par exemple) mais galement de son soutien dans les moments
dlicats. Un grand MERCI !
Je tiens galement remercier les membres de mon jury : Michel Diaz, Francine Krief, Pascal Lorenz,
Pascale Minet et Patrick Snac de lintrt port nos travaux de recherche.
Je tiens remercier lensemble de lquipe ASTRE, et tout particulirement les collgues et amis de la
composante rseau. Merci Cdric Teyssi pour son soutien, son aide et ses conseils. Merci tous
ceux et toutes celles qui ont partags 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 lquipe SIERA : Franois Barrre (qui ma permis de parfaire mes
connaissances au niveau physique et liaison), Abdelmalek Benzekri, Julien Broisin, Thierry Desprats
(grce qui mes connaissances en gographie se sont amliores), Michel Kamel, Romain Laborde
(trop lent sur Parc Baby), Daniel Marqui et Philippe Vidal pour mavoir aid raliser mes premiers
pas dans lenseignement (et ceci dans divers horizons MIAGE, L2 informatique et IUT).
Merci tous mes amis de la fac (Claire, Chaouki, Sam, Marie, Xav, Aurlie, les deux Antoine, Samy,
Sophie, Lucie) et ceux rencontrs durant les annes de thse (Samir, Nop, JC, Souad, Armelle).
Merci davoir partag mon quotidien : le rutage, les soires jeux, la danse
Merci tous mes amis de Plaisance : Yann Lebras, Julien Orvoen, Florent Bernard, Cdric Colombier,
Sophie Gregorio, Cdric Delannoy et David Jougla. Malgr la distance qui nous spare aujourdhui, a
ne mempchera pas de franchir la frontire 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 particulirement mes parents, ma sur et tous les
membres de ma famille. Je les remercie pour leur soutien de tous les jours, leur comprhension dans
les moments difficiles. Sans eux, certains jours auraient t bien plus noir.
Encore un grand MERCI toutes et tous !

iii
Rsum
Nos travaux se situent dans le contexte des rseaux MANETs (Mobile Ad Hoc NETorks) qui
constituent une catgorie de rseaux sans fil pouvant tre dploys rapidement, multi-sauts et sans
infrastructure. Les rseaux MANETs permettent la communication entre utilisateurs dapplications
mobiles diverses (applications collaboratives, urgences, militaires, embarques).
Cependant, ces rseaux souffrent dinconvnients la fois lis aux caractristiques du medium de
transmission (partage du canal de transmission, faible dbit), mais galement aux protocoles de
routage (dissmination de linformation, slection dun chemin). Ces limites rendent difficile le
support des applications multimdia et temps rel (telles que la vidoconfrence, la vido la
demande, la VoIP). Ces applications requirent le respect de contraintes de Qualit de Service (QoS)
telles que la bande passante et le dlai.
Le but de nos travaux est doptimiser la bande passante disponible dun rseau MANET pour
permettre lutilisation dapplications fortement consommatrices en bande passante. Comme un rseau
MANET est multi-saut, linfluence des protocoles de routage sur les performances du rseau est
dterminante. Trois axes ont t tudis pour augmenter la bande passante utile des rseaux MANETs :
rduction des collisions, rduction des informations de routage et garantie de la bande passante et du
dlai.
Mots-cls : Rseaux ad hoc, routage, routage QoS, applications temps-rel, bande passante, dlai

v
Table des Matires
Remerciements ....................................................................................................................................... i
Rsum .................................................................................................................................................. iii
Table des Matires................................................................................................................................. v
Table des Figures .................................................................................................................................. ix
Introduction ........................................................................................................................................... 1
1 Introduction aux Rseaux Mobiles Ad hoc (MANETs) ................................................................ 5
1.1 Contexte des travaux ..................................................................................................................... 6
1.2 Les rseaux mobiles ad hoc (MANETs) ....................................................................................... 7
1.2.1 Caractristiques des rseaux MANETs ................................................................................. 8
1.2.2 Contraintes lies aux rseaux MANETs................................................................................ 9
1.3 Rseaux 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 Accs au canal de manire distribue .................................................................................. 13
1.3.4.1 Mode DCF ................................................................................................................... 13
1.3.4.2 Mode DCF avec RTS/CTS .......................................................................................... 15
1.4 Accs au canal sans contention ................................................................................................... 17
1.5 Modles de mobilit .................................................................................................................... 18
1.6 Discussion ................................................................................................................................... 19
2 Routage Meilleur effort dans les rseaux MANETs .................................................................... 21
2.1 Type de dissmination de linformation 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 Ractifs .............................................................................................................. 26
2.1.2.1 Protocole AODV ......................................................................................................... 27
2.1.2.2 Protocole DSR ............................................................................................................. 28
2.1.2.3 Autres protocoles ractifs ............................................................................................ 29
2.1.3 Protocoles Hybrides ............................................................................................................ 30
2.1.3.1 Protocole ZRP .............................................................................................................. 31
2.1.3.2 Autres protocoles hybrides .......................................................................................... 32
2.2 Hirarchisation du rseau ............................................................................................................ 32
2.2.1 Cluster ................................................................................................................................. 33
2.2.2 Rseaux backbone ............................................................................................................ 34
2.2.3 Protocoles de routage hirarchiques .................................................................................... 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 rseaux MANETs ........................................................... 45
3.1 Routage QoS ............................................................................................................................ 46
3.2 Mtriques de QoS ........................................................................................................................ 48
3.2.1 Modles destimation .......................................................................................................... 49
3.2.2 Estimation de bande passante disponible ............................................................................ 49
3.2.2.1 Mthode de Kazantsidis et Gerla ................................................................................. 50
3.2.2.2 Mthode de Lee et al. .................................................................................................. 51
3.2.3 Estimation de dlai .............................................................................................................. 51
3.2.3.1 Modle destimation de dlai sonde ......................................................................... 52
3.2.3.2 Modle destimation de dlai 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 indpendants de la mthode daccs au support ................... 56
3.5.2 Protocoles de routage QoS dpendants de la mthode daccs 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 Paramtres influant sur la diminution de la bande passante ................................................ 68
4.1.2 Protocole de routage : lment essentiel dans la gestion de la bande passante ................... 70
4.2 Collisions : causes et consquences ............................................................................................ 71
4.2.1 Causes.................................................................................................................................. 71
4.2.1.1 Nombre de nuds voisins ............................................................................................ 78
4.2.1.2 Dbit de transmission .................................................................................................. 80
4.2.1.3 Charge dun lien .......................................................................................................... 81
4.2.1.4 Influence de la longueur dun chemin ......................................................................... 84
4.2.2 Consquences ...................................................................................................................... 85
4.3 Protocole de routage .................................................................................................................... 86
4.3.1 Fonction poids numro 1 ..................................................................................................... 87
4.3.1.1 Mtriques utilises ....................................................................................................... 87
4.3.1.2 Fonction poids utilise ................................................................................................. 88
4.3.2 Fonction poids numro 2 ..................................................................................................... 90
4.3.2.1 Mtriques ..................................................................................................................... 90
4.3.2.2 Fonction poids utilise ................................................................................................. 91
4.3.3 Phase de dcouverte de route .............................................................................................. 92
4.3.3.1 Algorithme du nud source......................................................................................... 93
4.3.3.2 Algorithme du nud intermdiaire .............................................................................. 94

vii
4.3.3.3 Algorithme du nud de destination ............................................................................. 95
4.3.4 Maintenance des routes ....................................................................................................... 96
4.3.5 Analyse de performance ...................................................................................................... 96
4.4 Discussion ................................................................................................................................. 104
5 Approches de Rduction de la charge due aux informations de contrle ............................... 107
5.1 Dtermination de la position de la destination .......................................................................... 109
5.1.1 Protocole de localisation de la destination ........................................................................ 110
5.1.1.1 Phase de dcouverte 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 Rduction de lespace de recherche .......................................................................................... 119
5.2.1 Forme gomtrique triangulaire ........................................................................................ 119
5.2.2 Forme gomtrique en cerf-volant .................................................................................... 124
5.2.3 Protocole de dcouverte 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 Proprits de la zone de recherche .................................................................................... 135
5.3.2 Protocole optimal .............................................................................................................. 138
5.3.2.1 Phase de dcouverte des routes.................................................................................. 139
5.3.2.3 Complexit en termes de message ............................................................................. 141
5.3.3 Protocole conciliant taux de dcouverte des routes et dissmination dinformations de
routage ........................................................................................................................................ 142
5.3.3.1 Phase de dcouverte des routes.................................................................................. 143
5.3.3.3 Complexit en termes de messages ........................................................................... 145
5.3.4 Simulations ........................................................................................................................ 145
5.4 Discussion ................................................................................................................................. 148
6 Protocole de routage pour loptimisation de bande passante sous des contraintes : dlai et
bande passante ................................................................................................................................... 149
6.1 Garantie du dlai : un besoin ..................................................................................................... 149
6.2 Facteurs impactant la bande passante lors de rservation de slots ............................................ 151
6.2.1.1 Impact de la rservation dun slot sur les nuds voisins ........................................... 152
6.2.2 Problme de routage .......................................................................................................... 153
6.2.2.1 Impact dun chemin sur les nuds voisins ................................................................ 154
6.2.3 Bande passante surconsomme ......................................................................................... 159
6.3 Optimisation de la bande passante sous contraintes de dlai et bande passante ....................... 160
6.3.1 Mtriques ........................................................................................................................... 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 Exprience ................................................................................................................................. 173
7.3 Critiques et orientations futures ................................................................................................ 173
Bibliographie ...................................................................................................................................... 175
Annexes .............................................................................................................................................. 187
I Complments ............................................................................................................................ 189

ix
Table des Figures
Figure 1-1 : Couche Physique IEEE 802.11 .......................................................................................... 11
Figure 1-2 : Exemple daccs au mdium pour 3 stations ..................................................................... 14
Figure 1-3 : Partage du canal par trois stations avec la mthode RTS/CTS .......................................... 15
Figure 1-4 : Problmes des nuds cachs ............................................................................................. 16
Figure 1-5 : Lutilisation du mcanisme RTS/CTS nempche pas la totalit des collisions. .............. 17
Figure 1-6 : Structure dune fentre TDMA de M slots de donnes par fentre, pour un rseau de N
nuds. ........................................................................................................................................... 17
Figure 2-1 : Diffrents types de protocoles de routage Meilleur Effort ................................................ 22
Figure 2-2 : Topologie dun rseau de clusters ..................................................................................... 33
Figure 2-3 : Topologie dun rseau de Backbone .................................................................................. 34
Figure 3-1 : Exemple de graphe associ un rseau ............................................................................. 47
Figure 4-1 : Intervalle de temps durant lequel peut se produire une collision. a) X commence
transmettre alors que Y a dj commenc transmettre. b) Y commence transmettre alors que X
a dj commenc transmettre. .................................................................................................... 73
Figure 4-2 : Intervalle de temps durant lequel une collision est susceptible de se produire dans le cas
de nuds cachs. .......................................................................................................................... 74
Figure 4-3 : Slection dun chemin possdant moins de voisins pour le protocole de routage optimal
compar au protocole de plus court chemin. ................................................................................ 79
Figure 4-4 : Temps dmission dune trame IEEE 802.11b .................................................................. 80
Figure 4-5 : Charge transmise en fonction de la charge soumise sur le mdium pour des nuds ayant
un dbit de transmission gal 1 Mbps ou 2 Mbps. .................................................................. 82
Figure 4-6 : Nombre de collisions subies par le rseau en fonction du dbit total des nuds avec un
dbit de transmission gal 1 Mbps ou 2 Mbps. .......................................................................... 83
Figure 4-7 : Nombre de paquets supprims en fonction du dbit total des nuds avec un dbit de
transmission gal 1 Mbps ou 2 Mbps ........................................................................................ 84
Figure 4-8 : Organigramme excut par un nud source ..................................................................... 94
Figure 4-9 : Organigramme utilis par un nud intermdiaire. Lencadr en pointill met en valeur la
partie diffrente de notre protocole compar au protocole AODV............................................... 95
Figure 4-10 : Organigramme utilis par la destination. Lencadr en pointill met en valeur la partie
diffrente de notre protocole compar au protocole AODV. ........................................................ 95
Figure 4-11 : Bande passante consomme par les paquets de donnes en fonction du nombre de nuds
prsents sur le rseau. La taille des paquets est de 512 octets. ..................................................... 97
prsents sur le rseau. La taille des paquets est de 1500 octets. ................................................... 98
prsents sur le rseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%)
des nuds ont un dbit de 1Mbps (respectivement 11Mbps, 54Mbps). ....................................... 98

x
Figure 4-14 : Bande passante ayant subi des collisions en fonction du nombre de nuds prsents sur le
rseau. La taille des paquets est de 512 octets. ............................................................................. 99
rseau. La taille des paquets est de 1500 octets. ........................................................................... 99
rseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des nuds ont
un dbit de 1Mbps (respectivement 11Mbps, 54Mbps). ............................................................ 100
Figure 4-17 : Bande passante consomme par les requtes en fonction du nombre de nuds prsents
sur le rseau. La taille des paquets est de 512 octets. ................................................................. 101
sur le rseau. La taille des paquets est de 1500 octets. ............................................................... 101
sur le rseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des
nuds ont un dbit de 1Mbps (respectivement 11Mbps, 54Mbps). ........................................... 102
Figure 4-20 : Bande passante consomme par les paquets de donnes en fonction de la mobilit des
nuds. Le rseau est compos de 50 nuds 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 nuds. Le rseau
est compos de 50 nuds et la taille des paquets est de 512 octets. ........................................... 103
Figure 4-22 : Bande passante consomme par les requtes en fonction de la mobilit des nuds. Le
rseau est compos de 50 nuds et la taille des paquets est de 512 octets. ................................ 104
Figure 5-1 : Organigramme utilis par le nud source pour dterminer la position de la destination.
Lencadr en pointill met en valeur la partie diffrente de notre protocole compar au protocole
AODV. ........................................................................................................................................ 111
partie diffrente de notre protocole compar au protocole AODV............................................. 112
diffrente de notre protocole compar au protocole AODV. ...................................................... 113
Figure 5-4 : Nombre de requtes de localisation changes en fonction du nombre de nuds avec une
mobilit des nuds de 5m/s. ....................................................................................................... 115
Figure 5-5 : Nombre de requtes de localisation changes en fonction de la mobilit des nuds pour
deux topologies diffrentes (une compose de 50 nuds, lautre compose de 100 nuds). .... 116
Figure 5-6 : Temps dobtention de la position dun nud destination en fonction du nombre de nuds
du rseau ..................................................................................................................................... 117
Figure 5-7 : Temps dobtention de la position dun nud destination en fonction de la mobilit des
nuds pour deux topologies (une compose de 50 noeuds, lautre compose de 100 nuds). . 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 nud intermdiaire ......................................................... 130
Figure 5-11 : Pourcentage dchec la dtermination dune route en fonction du nombre de nuds du
rseau. ......................................................................................................................................... 132
Figure 5-12 : Pourcentage dchec trouver une route suivant langle utilis pour calculer la taille de
la zone de recherche. .................................................................................................................. 133
Figure 5-13 : Nombre moyen de requtes ncessaires la dcouverte dune route ............................ 133

xi
Figure 5-14 : Nombre moyen de requtes 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 nud source. Lencadr en pointill met en valeur la partie
Figure 5-17 : Echec de la dcouverte dune route alors quune existe. ............................................... 143
Figure 5-19 : Pourcentage dchec la dcouverte dune route .......................................................... 146
Figure 5-20 : Nombre requtes transmises sur le rseau pour la dcouverte des chemins .................. 147
Figure 5-21 : Nombre moyen de requtes pour la dtermination dun chemin ................................... 147
Figure 6-1 : Nombre de slots rservs suivant la position dun nud sur un chemin ......................... 152
Figure 6-2 : Impact de chemins diffrents sur un rseau de 8 nuds. a) Impact du chemin le plus court.
b) Impact du chemin optimal. ..................................................................................................... 155
Figure 6-3 : Impact dun chemin sur les nuds voisins avec la rservation de 2 slots par nud travers.
.................................................................................................................................................... 157
Figure 6-4 : Organigramme utilis par le nud source ....................................................................... 164
Figure 6-5 : Organigramme utilis par un nud intermdiaire j ......................................................... 165
Figure 6-6 : Organigramme utilis par le nud destination ................................................................ 166
Figure 6-7 : Bande passante surconsomme par le protocole LD compar notre protocole ............ 167
Figure 6-8 : Bande passante ncessaire lobtention des routes ......................................................... 168
Figure 6-9 : Bande passante utilise par les paquets de donnes ........................................................ 168
Figure 6-10 : Nombre de slots rests libres en fin de simulation en fonction du nombre de nuds. .. 169
Figure A-1 : Organigramme du nud source ...................................................................................... 190
Figure A-2 : Organigramme dun nud intermdiaire ........................................................................ 191
Figure A-3 : Organigramme dun nud destination ........................................................................... 192

1
Introduction
1. Contexte
Avec le dveloppement constant des technologies, lutilisation des systmes dinformation sest
transforme. Elle sexprime notamment par un besoin de mobilit des utilisateurs. Les rseaux filaires
ne pouvant assurer une telle flexibilit dutilisation, les rseaux sans fil, et WiFi (Wireless Fidelity) en
particulier, ont permis de combler une partie de ce manque. Les utilisateurs peuvent ainsi se dplacer
librement avec leur terminal mobile (ordinateur, tlphone, PDA) tout en restant connects leur
rseau personnel ou dentreprise. Lutilisation de terminaux mobiles impose lemploi dune
infrastructure (points daccs) parfois coteuse ou difficile implanter. De fait, cette solution nest pas
toujours envisageable. Par consquent, des rseaux mobiles dpourvus dinfrastructure ont t
dploys. Ces rseaux sont plus connus sous le nom de rseaux ad hoc mobiles ou MANETs (Mobile
Area NETworks).
Un rseau MANET est un rseau sans fil capable de sorganiser sans infrastructure dfinie
pralablement. Un tel rseau est compos de stations mobiles ou nuds qui peuvent communiquer
directement entre eux sils sont situs porte radio. La porte des stations tant relativement limite,
le dploiement dun rseau grande chelle ncessite que le rseau MANET soit multi-saut, c'est--
dire que des stations intermdiaires fassent office de point de relais. Les rseaux MANETs, grce
leur auto-organisation, et labsence dinfrastructure, peuvent facilement tre dploys dans de
nombreux domaines comme lembarqu (intgr rcemment dans le secteur automobile pour accrotre
la scurit des usagers en les informant dventuels obstacles sur leur itinraire), lors doprations de
secours (sauvetage en mer, en zones sinistres) ou lors doprations militaires. Les rseaux
MANETs se caractrisent galement par leurs faibles ressources sur la totalit de la ligne de
communication. Cela se traduit par une autonomie limite, car les stations sont gnralement
alimentes laide de batteries, et par une puissance relativement faible du fait de la compacit des
quipements emports. De plus, la capacit des liens sans fil savre relativement limite offrant par
consquent un dbit modeste compar aux rseaux filaires.
Les utilisateurs de rseaux MANETs souhaitent avoir les mmes services que ceux offerts par les
rseaux filaires. En dautres termes, les applications utilises dans les rseaux filaires doivent tre
fonctionnelles sur les rseaux ad hoc, en particulier, les applications multimdia et temps-rel
(vidoconfrence, tlphonie sur internet, vido sur demande). Les ressources limites des rseaux
MANETs rendent complexes le support de telles applications qui ncessite des ressources importantes
(notamment la bande passante). De nombreux facteurs, au niveau physique (collisions par exemple) ou
par le fonctionnement de certaines couches (couche rseau par exemple), rduisent la bande passante
de ces rseaux. Nous focalisons nos travaux sur laugmentation de la bande passante utile des rseaux
MANETs.

2
Le protocole de routage dissmine des informations de routage ncessaires lobtention et la
maintenance des routes. Suivant le type de dissmination de linformation, ces protocoles peuvent tre
rpertoris en trois grandes classes : proactifs, ractifs et hybrides. Ltude de ces diffrentes
approches nous a permis dorienter nos travaux sur les protocoles de routage ractifs. Les protocoles
de routage ractifs diffusent des informations de routage seulement sur demande. De fait, nous avons
choisi de baser nos contributions sur lamlioration du protocole de routage ractif AODV (Ad hoc
On-Demand Distance Vector routing).
Le protocole de routage doit intervenir sur les facteurs rduisant la bande passante utile du rseau. La
bande passante utile dun rseau est rduite par la prsence des collisions. Le protocole de routage est
lui-mme responsable de la diminution de la bande passante utile dun rseau. Ces informations sont
ncessaires la dtermination et la maintenance des routes.

2. Contributions
Notre premire contribution est de proposer un protocole de routage rduisant le nombre de collisions.
Les collisions entranent une consommation excessive de la bande passante disponible du rseau. Dans
les rseaux MANETs, un nud metteur dtecte la prsence dune collision seulement sil ne reoit
pas un acquittement, durant un temps dattente donn, son paquet de donnes. Lors de la dtection
dune collision, le nud metteur retransmet son paquet de donnes. Les retransmissions ncessaires
la rception correcte dun paquet consomment de la bande passante. De mme, ces retransmissions
successives augmentent le dlai de bout en bout dun paquet de donnes. La prsence dun tel retard
peut avoir des rpercussions nfastes sur le fonctionnement des applications multimdia ou temps-rel.
Aprs avoir mis en vidence les diffrents facteurs (nombre de nuds voisins, dlai de transmission
dun paquet, charge dun lien et dlai de propagation) intervenant sur loccurrence de collision, nous
proposons un protocole de routage rduisant les collisions. Le protocole de routage utilise une fonction
poids dpendante de trois facteurs (la capacit dun lien, la bande passante disponible et le nombre de
voisins) pour dterminer la qualit dune route. Slectionner un lien sur sa capacit de transmission
permet dinfluer sur le dlai de transmission dun paquet. Plus la capacit de transmission est
importante, plus le temps de transmission dun paquet est faible. La bande passante disponible dun
lien permet dvaluer sa charge. Un lien satur limite le nombre de paquets changs et accrot le
nombre de collisions. Le nombre de voisins influe directement sur la probabilit dobtenir une
collision. Plus le nombre de voisins est important, plus les risques de collision croissent.
La surconsommation de bande passante lors de la cration des routes est notre second axe de recherche.
Lors de la dtermination dune route par un protocole de routage ractif, certaines informations de
routage ne sont pas ncessaires. Les informations transmises dans le sens oppos de la destination,
sont, bien souvent inutiles. Lefficacit du protocole de routage peut tre amliore en contrlant la
dissmination des informations de routage. Lespace dans lequel est dissmine linformation de
routage est, ainsi, rduit. Une telle rduction de lespace de recherche ncessite la connaissance de la
localisation du nud destination. Le premier dfi est donc de localiser la destination.

3
Afin de localiser la position de la destination, nous proposons un protocole utilisant un rseau
backbone. Un rseau backbone utilise deux types de nuds pour communiquer : les nuds de
backbone et les nuds normaux. Les nuds de backbone forment une dorsale sans fil centralisant les
informations de localisation sur le rseau MANET. Le rseau backbone dcharge le rseau ad hoc de
lchange des informations de localisation. La position dun nud destination est rapidement
dtermine par un lger change sur le rseau MANET. Pour viter de dterminer chaque rupture de
route la position du nud destination, il peut propager priodiquement, au nud source, des
informations concernant sa mobilit (vitesse, direction, position). Ces informations sont transmises
travers le rseau backbone pour en diminuer limpact sur le rseau MANET.
En connaissant la position de la destination, le protocole de routage peut dornavant rduire lespace
de recherche. Une rduction de lespace de recherche rduit les informations de routage ncessaires
la dtermination dune 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 lespace de recherche du protocole de routage est agrandie lorsquune
route na pas pu tre trouve. Le premier protocole de routage propos est optimal c'est--dire quune
route est trouve sil en existe une. Chaque nud faisant partie de la zone de recherche propage la
requte. Si la tentative choue trouver une route, la zone de recherche est agrandie et la source
propage une nouvelle requte. Chaque nud ayant reu une requte lors dune tentative prcdente la
retransmet. Le deuxime protocole de routage est non optimal c'est--dire quun chemin peut ne pas
tre trouv mme sil en existe un. Dans ce protocole, chaque nud de la zone de recherche ne
transmet quune seule fois le paquet quelque soit la tentative ralise.
Pour certaines applications temps-rel et/ou multimdia, laugmentation de la bande passante nest pas
toujours suffisante. Certaines applications ncessitent le respect de contraintes de qualit de service
(QoS) telles que le dlai et la bande passante. Pour permettre le respect de telles contraintes, une
mthode de rservation de bande passante doit tre utilise. Dans une mthode daccs au support
comme CSMA/CA, la rservation est trs difficile cause de la prsence de collisions. Des mthodes
sans contention, telles que TDMA, sont plus adaptes pour permettre le respect des contraintes de QoS.
La mthode TDMA divise le temps daccs au support de communication en slots. Un nud peut
rserver en mission un slot uniquement sil ne lutilise pas dj et si aucun de ses nuds voisins ne
la rserv en rception. De mme, un nud peut rserver un slot en rception uniquement sil ne
lutilise pas et si aucun de ses nuds voisins ne la rserv en mission. La rservation dun slot par un
nud impacte donc les nuds voisins puisquils ne peuvent pas rserver un tel slot. Ces contraintes
sur la rservation des slots rduisent, par consquent, la bande passante utile du rseau mais
empchent lapparition de collisions.
Nous proposons un protocole de routage permettant de diminuer le nombre de slots impacts par la
rservation des slots lors de la cration dune nouvelle route. Pour cela, une fonction poids, pnalisant
de manire exponentielle le nombre de voisins rencontr par un chemin et de manire linaire la
contrainte de dlai, est utilise. Les paquets de routage sont propags par un nud si la demande de
cration de route est nouvelle ou si le poids de la sous-route est plus faible que la sous-route
prcdente.

4

3. Organisation du mmoire
Ce mmoire de thse est organis en six chapitres. Le premier prsente les rseaux MANETs dans un
contexte gnral et les rseaux 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 bass. Le
troisime chapitre prsente la notion de qualit de service, et les protocoles de routage QoS
garantissant les contraintes de dlai ou de bande passante. Le quatrime chapitre prsente un protocole
de routage rduisant limpact des collisions sur le rseau. Le cinquime chapitre se focalise sur la
diminution des informations de routage en utilisant des informations de localisation. Le sixime
chapitre prsente un protocole de routage QoS pour loptimisation de la bande passante avec le
respect des contraintes de dlai et de bande passante. Notre travail se termine par une conclusion et
une prsentation de quelques perspectives pour la poursuite de ce travail.

5
1 Introduction aux Rseaux
Mobiles Ad hoc (MANETs)
Lexplosion des communications tlphoniques ou informatiques dans les annes 90 a conduit une
utilisation toujours plus croissante des rseaux de communication. Initialement de simples supports de
communication, les rseaux sont aujourdhui devenus des enjeux majeurs pour lavenir. Lapparition
dinternet et son succs, la dmocratisation des terminaux (ordinateurs, PDA, tlphones portables,
boitiers triple-play) sont autant de facteurs qui changent notre mode de vie. Ce changement sest
aussi opr dans notre relation avec les moyens de communication. De sdentaire, lutilisation devient
de plus en plus mobile (tlphones, ordinateurs portables) mais aussi embarque au sein de
vhicules. Cette mobilit est un enjeu important des rseaux daujourdhui et de demain. De fait, les
rseaux ont d sadapter cette nouvelle donne. Nos travaux sinscrivent dans cette optique
dutilisation de mobiles.
Paralllement ces changements, de nouvelles utilisations sont apparues. Ces utilisations
transparaissent dans les termes multimdia et temps-rel. Actuellement, tout rseau sans fil doit, en
plus doffrir un moyen de communication, respecter les contraintes qui lui sont imposes par les
applications. Il doit offrir un dbit suffisamment lev et doit pouvoir tre facilement et rapidement
dploy. Les terminaux doivent tre galement lgers.
Nous positionnons le contexte de notre tude sur les besoins de mobilit des utilisateurs et sur leur
besoin dutiliser des applications contraintes ou fortement consommatrices en bande passante. Ce
chapitre a pour objectif de prsenter les rseaux ad hoc mobiles et plus prcisment les rseaux ad hoc
mobiles IEEE 802.11. Les modles de mobilit sont aussi voqus en fin de chapitre. Nous conclurons
enfin ce chapitre par une critique sur ladquation de ces rseaux ad hoc notre contexte.

6
1.1 Contexte des travaux
Dans un monde toujours plus interconnect, le besoin de communiquer librement ne se dment pas.
Les rseaux filaires souffrent de leur manque de flexibilit au regard des besoins de mobilit des
utilisateurs. Les rseaux sans fil se positionnent en alternative des rseaux filaires sur ce point. En effet,
les rseaux sans fil imposent moins de contraintes de dploiement et de mobilit que leurs homologues
filaires. De fait, lutilisation de rseaux sans fil est entre dans la vie courante de la majorit des
utilisateurs. Ces rseaux se retrouvent dans toutes les sphres des quipements lectroniques habituels :
micro-informatique, tlphones portables, consoles de jeux, appareils multimdia, etc.
Les utilisateurs souhaitent pouvoir profiter de leur rseau sans fil quelque soit les situations dans
lesquelles ils se trouvent. Les rseaux mobiles ad hoc ont t conus dans cette optique. Gnralement,
ce type de rseau est mis en uvre lorsquune infrastructure sans fil est difficilement envisageable ou
indisponible. De mme, lors de lutilisation de courte dure ou soudaine de certaines applications, il
est ais dutiliser un tel type de rseaux car il est facilement dployable et auto-organis. Son faible
cot participe son succs.
Les habitudes des utilisateurs ne doivent pas tre modifies par lutilisation dun rseau sans fil. De
fait, les rseaux sans fil doivent fournir les mmes besoins, le respect des mmes contraintes que leurs
homologues filaires. Les applications multimdia et temps-rel ne doivent pas, non plus, souffrir de la
prsence dun environnement mobile. Les domaines dapplications des rseaux sans fil ad hoc sont
nombreux et nous pouvons citer les applications suivantes :
Applications collaboratives : Les utilisateurs professionnels ont besoin dapplications
particulires lors dchanges entre collaborateurs. Ainsi, au cours de runions ou de
confrences, ces utilisateurs peuvent ressentir le besoin de former dans nimporte quel lieu un
rseau pour schanger des informations, ou faire une vidoconfrence entre bureaux voisins.
Les rseaux ad hoc sont bien appropris ces besoins.
Jeux Vido : Les rseaux sans fil sont bien adapts pour permettre lchange dinformations
entre applications personnelles. Ainsi, pour les utilisateurs voulant jouer en rseau, il est facile
et faible cot de dployer un rseau ad hoc.
Urgences : Lors de catastrophes dorigine naturelles (comme les tremblements de terre, les
tsunamis, les feux de fort ou dhabitations) ou non, les infrastructures prexistantes
peuvent ne pas tre oprationnelles compliquant dautant plus les besoins de communications
des moyens de secours. Les rseaux sans fil, par leur compacit et leur rapidit de dploiement,
permettent aux diffrentes quipes de secours dtablir rapidement des liaisons et dchanger
des informations.
Militaires : Lors dinterventions en milieu hostile, il peut tre difficile ou trop encombrant
dutiliser un rseau infrastructure. Les rseaux sans fil sont parfaitement bien adapts ce
type denvironnement o les dplacements restent peu rapides et peu soutenus. A titre
dexemple, le dpartement militaire Amricain a dvelopp le projet SLICE (Soldier Level

7
Integrated Communications Environment) pour permettre la communication des soldats lors
dinterventions militaires. Lide sous-jacente est que chaque soldat soit quip dun
ordinateur portable reli un casque et un microphone. Le projet SLICE est cens crer un
rseau sans fil ad hoc permettant le transfert de la voix entre diffrents soldats.
Systmes embarqus : Un bon exemple, pour lutilisation des rseaux sans fil dans les
applications embarques est le projet V2V (Vehicle to Vehicle). En effet, un consortium de
constructeurs automobiles sest focalis sur lchange dinformations entre vhicules
automobiles afin damliorer la scurit des usagers de la route. Le but de ce projet est de faire
communiquer, entre eux, au moyen dun rseau et ce de manire transparente, plusieurs
vhicules proches. En cas de danger (accident, bouchon, brusque ralentissement), le premier
vhicule dtectant ce danger prvient les autres vhicules. Chacun de ces derniers vhicules
informant leur tour dautres vhicules que les conditions de circulation ont volu. Le
conducteur est ce moment l prvenu par un voyant lumineux ou sonore du danger et de la
conduite adopter.
Rseaux de capteurs : Les rseaux de capteurs sont des rseaux sans fil dont les quipements
se dplacent trs peu, et dont la dure de vie des batteries est limite. Ces quipements peu
coteux permettent de fournir par exemple des informations sur la temprature diffrents
endroits dune chambre froide, le niveau densoleillement dune pice, la sant des animaux
dans un zoo
Le contexte de nos travaux est celui des rseaux sans fil ad hoc pour les domaines dapplications
collaboratives, durgences et vido-ludiques. Les applications les plus reprsentatives de ces domaines
concernent les applications multimdia et temps-rel. Dans le mme contexte, nous restreignons une
surface denviron 1km (par exemple un campus universitaire) la superficie des rseaux tudis.
1.2 Les rseaux mobiles ad hoc (MANETs)
Un rseau mobile ad hoc ou rseau MANET est un rseau sans fil capable de sorganiser sans
infrastructure dfinie pralablement. Un tel rseau est compos de stations mobiles ou nuds qui
peuvent communiquer directement entre eux sils sont situs porte radio.
Un rseau MANET nest pas li une technologie de communication sans fil particulire. De
nombreuses technologies sans fil permettent le dploiement dun rseau MANET : les rseaux sans fil
personnels (WPAN) avec les rseaux de type Bluetooth [Bluetooth] et Zibgee [Zigbee], les rseaux
sans fil locaux (WLAN) avec IEEE 802.11 (ou WiFi [WiFi]) et HyperLan de type 1 [ETSI 98-1]. La
surface d1 km de notre contexte dtude carte les rseaux de type WPAN. De plus, nous avons
choisi de nous restreindre aux rseaux IEEE 802.11 du fait de leur fort dploiement.
Les rseaux MANETs possdent de nombreuses contraintes (cf. 1.2.2) lies leurs caractristiques
(cf. 1.2.1). Pour que les rseaux MANETs soient utilisables pour le support de flux multimdia et

8
temps-rel, il est ncessaire dapporter des solutions sur certaines de ses limitations. Les rseaux
MANETs offrent, donc, un axe de recherche intressant.
1.2.1 Caractristiques des rseaux MANETs
Un rseau mobile ad hoc (rseau MANET) possde des caractristiques particulires [RFC 2501]
compar aux autres rseaux sans fil :
Mobile : Les stations ne sont pas fixes dans les rseaux MANETs. Elles peuvent se dplacer et
sont entirement indpendantes. A tout moment, de nouvelles stations peuvent joindre le
rseau ou le quitter. Le changement de la topologie dun rseau MANET dans le temps est un
lment primordial.
Sans fil : Les stations dun rseau MANET utilisent un support sans fil pour communiquer
entre elles. Elles partagent le mme mdia lors des changes dinformations. De fait, ce
partage et ses consquences (collisions, rservation de ressources) sont autant dlments
prendre en compte.
Sans infrastructure : Par nature, les rseaux MANETs ne dpendent pas dune architecture
fixe. Ils peuvent donc tre facilement dploys.
Auto-organis et distribu : Les rseaux MANETs ne disposent pas de point central pour
coordonner ou centraliser les changes. De fait, ces rseaux doivent sauto-organiser afin
doprer. De plus, labsence de centralisation demande chaque acteur du rseau de participer
au bon fonctionnement du rseau (distribution).
Multi-saut : Comme la porte des stations est limite, il peut savrer ncessaire que des
stations agissent en tant que pont intermdiaire pour transmettre un paquet dune source vers
une destination. Par consquent, les nuds dun rseau MANET agissent en tant que routeur
et relayent les paquets quils reoivent pour participer au routage multi-saut.
Ressources limites : Les ressources limites touchent toute la chane de communication dun
rseau MANET en commenant par les nuds jusquaux liens de communication. Les
terminaux tant mobiles, ils fonctionnent principalement sur batterie. La mobilit contraint
galement la puissance embarque. La capacit des liens sans fil savre aussi limite
comparativement aux rseaux filaires. De mme, le taux derreur est bien plus lev que dans
un rseau filaire.
Temporaire et rapidement dployable : Ce type de rseau est intrinsquement temporaire et
rapidement dployable. Il na pas pour but de remplacer un rseau infrastructure mais de le
complter ou de le remplacer lorsque ncessaire.

9
1.2.2 Contraintes lies aux rseaux MANETs
Les caractristiques des rseaux ad hoc impliquent des contraintes spcifiques [DHA 05-1] sur leur
fonctionnement et donc leurs performances. Les principaux problmes susceptibles dtre rencontrs
dans un environnement mobile et ad-hoc peuvent tre regroups en deux catgories selon la source du
problme :
1) Limitations dues au support de transmission :
Partage du support de transmission : Les stations mobiles oprent sur la mme bande de
frquence. Le partage du support de transmission peut engendrer des collisions. Ce problme
est li galement la diffusion des signaux.
Taux derreur lev : Les rseaux sans fil utilisent des ondes radio pour communiquer. Ces
ondes ne peuvent pour autant saffranchir des contraintes lies leur medium de transmission,
lair. Les perturbations lectromagntiques, solaires ou les obstacles affectent les signaux
transmis et sont de fait source de taux derreur en bit particulirement levs.
Capacit des liens variables : Les rseaux sans fil doivent aussi faire face la variabilit de
leur support de transmission. De fait, les caractristiques et performances des liens entre deux
stations varient constamment. Ainsi, certains liens bidirectionnels, peuvent voir leurs
performances chuter et devenir des liens unidirectionnels.
Faible dbit : La modestie des dbits des rseaux sans fil est un lment souvent mis en avant.
Compars certains rseaux filaires, les dbits peuvent paraitre faibles. Et dans le cadre de
transferts multimdia ncessitant des changes de donnes soutenus, ces dbits peuvent ainsi
poser problme.
Variation de la qualit du signal : Le canal ne cesse de changer avec le temps. En effet, les
conditions extrieures peuvent modifier les caractristiques de ce canal, par exemple la pluie
peut accrotre le taux daffaiblissement de la liaison sans fil. De mme, lapparition
dobstacles peut modifier le canal augmentant le nombre de trajets entre une source et une
destination.
Scurit : Les signaux tant diffuss, ils peuvent tre couts par toute station mobile se
trouvant dans la mme zone de couverture. La confidentialit de certaines informations
ncessite lutilisation de mcanismes de scurit adquats.
2) Limitations dues aux stations mobiles :
Faible puissance : Les stations mobiles sont la plupart du temps conues pour une utilisation
mobile. De fait, elles se doivent dtre lgres, de petite taille et surtout doivent tre capables
de fonctionner de manire autonome (sur batterie). La prise en compte de tous ces lments
participe la faible puissance de llectronique embarque.

10
Dure dutilisation restreinte : Les batteries ont une dure de vie limite. De fait, le temps
dutilisation nomade dune station est contraint par la capacit de sa batterie mais aussi par la
puissance demande (ressources processeur ou transmissions sans fil). Il est ncessaire de
trouver un juste milieu entre ces composantes.
Rayon daction : La zone de couverture est fonction de la puissance dmission que peut
fournir une station. Le standard IEEE 802.11 dfinit la puissance maximale 100mW.
Rduire la puissance dmission, pour notamment conomiser de lnergie, peut engendrer des
liens unidirectionnels.
Modification de la topologie du rseau avec le temps : Les stations pouvant tre en constant
dplacement, la topologie du rseau volue galement. Le voisinage dun nud peut varier
continuellement : tout moment des stations peuvent joindre ou quitter le rseau. La
modification de la topologie est directement fonction de la vitesse de dplacement des stations
et du rayon daction du rseau. Avec un dplacement rapide et soutenu de lensemble des
stations, la topologie ne cesse dvoluer.
Altration des signaux : Le dplacement des stations modifie la frquence des signaux reus
par effet Doppler. Ainsi, haute vitesse les signaux peuvent savrer incomprhensibles.
Le contexte de notre tude permet la cohabitation dapplications multimdia ou temps-rel fortement
consommatrices en bande passante avec un environnement mobile ad hoc. Nous investiguons, par
consquent, dans la suite de nos travaux les contraintes suivantes : le faible dbit, la capacit des liens
variables et la modification de la topologie du rseau avec le temps.
1.3 Rseaux IEEE 802.11
La norme IEEE 802.11 [IEEE 99-1] couvre les deux premires couches du modle OSI, c'est--dire la
couche physique (niveau 1) et la couche liaison de donnes (niveau 2). La couche physique diffre
suivant le standard IEEE 802.11 utilis. Ainsi, des dbits 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 datteindre 54Mb/s compar aux 11Mb/s du standard IEEE 802.11b [IEEE 99-1]). Les
nouveaux standards sont rtro compatibles avec les standards prcdents lexception notable du
802.11a. Ainsi le standard IEEE 802.11g permet datteindre un dbit thorique maximal de 54Mb/s
mais galement les dbits 11Mb/s, 5.5 Mb/s, 2Mb/s et 1Mb/s.
1.3.1 IEEE 802.11 mode infrastructure / mode ad hoc
Le rseau IEEE 802.11 permet linterconnexion de terminaux sans lutilisation de cble. 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 centralises par un point daccs. Ainsi
lorsquune station veut communiquer avec son homologue, les donnes doivent au pralable transiter
par le point daccs qui les retransmet aprs un certain dlai. 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 lautre. La zone de couverture dune station est la zone dans
laquelle toute autre station peut correctement recevoir les donnes transmises.
1.3.2 La couche physique
La couche physique dfinit les aspects lectriques, mcaniques et fonctionnels de laccs au canal de
communication, ainsi que les protocoles dchange de donnes via le rseau. Elle assure entre autres,
les relations entre les couches suprieures et le matriel.
Cette couche est divise en deux sous couches : la sous-couche PLCP (Physical Layer Convergence
Protocol) est charge de lcoute du support et de la signalisation vers la couche MAC ; La sous-
couche PMD (Physical Medium Dependent) se focalise sur lencodage des donnes et la modulation.

Figure 1-1 : Couche Physique IEEE 802.11
Nous prsentons dans cette section uniquement les aspects de la sous-couche PMD et plus prcisment
les aspects de modulation. Les modulations employes par la couche physique des diffrentes normes
IEEE 802.11 sont reprsentes sur la figure 1-1. La norme physique initiale 802.11 (ratifie en 1997)
propose deux types de transmission modulation de frquence (FHSS et DSSS) associs une
modulation de phase et une technique de transmission infrarouge (IR) utilise surtout en milieu
industriel. Avec lapparition des standards (IEEE 802.11a et IEEE 802.11g), une autre modulation de
frquence (OFDM) a t adopte accroissant les dbits offerts.
Infrarouge (IR) : Le mode de communication par infrarouge est simple, peu rglement et peu
coteux. En utilisant un faisceau de lumire, ce mode est bas sur lutilisation des mmes
frquences que celles utilises par les fibres optiques.

12
Etalement de spectre avec saut de frquence (FHSS) : Au dpart utilis par les militaires afin
de chiffrer les communications, cette technique de modulation est assez rpandue (depuis la
standardisation des squences de frquences) car elle permet de remdier aux problmes
dinterfrences. Cette technique modifie la frquence de la porteuse daprs une squence de
sauts. En fait, lmetteur change de frquence dmission de faon priodique et suivant une
squence prtablie.
Etalement de spectre squence directe (DSSS) : Cette technique de modulation de frquence
est appele talement de spectre car linformation est directement module par un code de
dbit beaucoup plus important. Le signal rsultant occupe donc une bande passante trs
importante.
Multiplexage par rpartition orthogonale de frquence (OFDM) : Cette technique est apparue
aprs le constat que plus un symbole est long plus les interfrences inter symboles sont
moindres. La technique OFDM divise la bande de frquence initiale en canaux qui sont eux-
mmes diviss en un nombre important de sous canaux. Cest la transmission en parallle de
plusieurs sous canaux faible dbit qui va crer un seul canal haut dbit.
1.3.3 Sous-couche MAC
La sous-couche MAC caractrise laccs au mdium de faon commune aux diffrentes normes IEEE
802.11. Elle met en uvre les fonctionnalits ncessaires pour la ralisation dune transmission
correcte point point :
dtection derreur (CRC),
retransmission en cas de perte ou de trame errone,
envoi daccus de rception,
fragmentation des donnes.
La sous-couche MAC permet deux types daccs au canal :
PCF (Point Coordination Control) : Ce type daccs est centralis. Ainsi, un quipement tiers
(point daccs ou station de base) doit faire office de matre distribuant tour de rle laccs
au canal aux stations connectes. Une station ne peut mettre que si elle est autorise et ne
peut recevoir que si elle est slectionne. Ce type daccs au canal a t dvelopp pour
transmettre du trafic avec des contraintes temporelles (vido la demande, visioconfrence).
Le mode PCF est particulirement bien adapt au mode infrastructure de la norme IEEE
802.11.
DCF (Distributed Coordination Function) : Dans ce mode, laccs se fait par comptition.
Chaque station essaye dobtenir le support lorsquelle doit transmettre des donnes.

13
Contrairement au mode PCF, ce type daccs 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 dtaillerons pas plus avant ce mode dans ce document. Nous nous attacherons
seulement au mode daccs DCF.
1.3.4 Accs au canal de manire distribue
Le protocole daccs au canal de la norme IEEE 802.11 est CSMA/CA (Canal Sense Multiple Access/
Collision Avoidance). Ce protocole sest fortement inspir du protocole filaire IEEE 802.3
(CSMA/CD) [IEEE 85-1]. CSMA/CA est une technique daccs alatoire au support avec coute au
pralable de la porteuse, qui permet dcouter le support de transmission avant dmettre. Ainsi, la
transmission est effectue uniquement si le support est libre diminuant ainsi le risque de collisions. Ce
risque est rduit mais nest pas pour autant nul. Contrairement CSMA/CD (o chaque nud coute
le support pendant quil transmet linformation pour dtecter collision), la dtection de collisions nest
gure possible dans les rseaux sans fil, car lmetteur est incapable dcouter le support tout en
transmettant son information. Par consquent, le rcepteur doit prvenir lmetteur que la transmission
sest correctement passe. Ainsi aprs la rception dune trame de donnes, le rcepteur acquitte celle-
ci si aucun problme (collision, perte, erreur de transmission) na eu lieu durant la transmission. A
la bonne rception de lacquittement, lmetteur en dduit que la transmission sest correctement
droule.
Pour rpondre des problmes de partage du support, deux modes sont disponibles dans la norme
IEEE 802.11 pour accder au canal de manire distribu : le mode DCF et le mode optionnel DCF-
RTS/CTS (mode DCF avec lajout de requtes 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 diffrents intervalles de temps pour discriminer laccs au support des stations.
Ainsi une station souhaitant transmettre un acquittement a un temps daccs au support plus faible
quune station voulant mettre une trame de donnes. Pour cela, un ensemble dintervalles de temps
est spcifi par le protocole DCF. Ces intervalles sont des multiples dun intervalle de base IFS
(InterFrame Spacing) :
Short InterFrame Space (SIFS) : reprsente le plus faible intervalle de temps disponible dans
le protocole DCF. Par consquent, il possde la plus forte priorit. Il est utilis pour sparer
les diffrentes trames transmises au sein dun mme dialogue (par exemple entre une trame de
donnes et son acquittement).
DCF InterFrame Space (DIFS) : correspond au temps dattente utilis pour lcoute pralable
du canal avant toute transmission de trame de donnes.

14
Extended InterFrame Space (EIFS) : cest le plus long des temps dattente. Il est uniquement
utilis par une station lorsquelle reoit une trame indchiffrable. Elle doit attendre pendant un
EIFS avant lenvoi dune autre trame.
Le fonctionnement du protocole DCF est relativement simple. Lorsquun nud dsire transmettre une
trame, il sassure tout dabord que le mdium soit libre durant un temps DIFS plus long que SIFS afin
de donner une priorit absolue aux acquittements. Le cas chant, il effectue la transmission, puis
attend lacquittement correspondant de la part du rcepteur. Labsence de rception de cet
acquittement provoque la retransmission de la trame et ce processus est rpt jusquau succs de
lopration ou jusqu atteindre le nombre maximal de retransmission. Dans ce dernier cas, la trame
est dtruite.
Si lmetteur constate que le mdium est dj occup lorsquil souhaite transmettre, il reporte sa
transmission jusqu la libration du support. Toutefois, si plusieurs nuds sont en attente de la fin
dune mme transmission, elles ne doivent pas commencer mettre au mme moment, sans quoi une
collision surviendrait irrmdiablement. Cest pourquoi lorsque le canal radio se libre, tout metteur
dsirant accder au mdium attend un temps alatoire en plus du temps DIFS. Chaque metteur
potentiel tire de faon uniforme un nombre alatoire (appel backoff) dans un intervalle de temps
appel fentre de contention. Cette valeur est ensuite dcrmente dune unit chaque intervalle de
temps pass sans que le support ne soit occup. La premire station atteindre la valeur 0 met alors
sa trame. Les autres nuds suspendent le processus qui est repris ds la fin de la transmission. Un
nud voulant mettre plusieurs trames en squence doivent passer par une procdure dattente
alatoire entre deux trames afin de ne pas monopoliser le support.

Figure 1-2 : Exemple daccs au mdium pour 3 stations
Lexemple de la figure 1-2 met en scne trois stations porte de communication. A linstant t
0
, le
nud A est en train dmettre, les deux autres attendent la libration du canal. A linstant t
1
, la
transmission est termine, les deux metteurs (B et C) patientent un temps DIFS avant de commencer
dcrmenter leur backoff. Aprs sa transmission, le nud A rentre en comptition avec les autres
nuds puisquil possde encore une trame transmettre. Il tire le plus petit nombre alatoire et gagne
la contention t
2
. Le processus de dcrmentation est alors suspendu pour les deux autres et reprendra

15
t
3
. Le nud 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 mthode daccs [ISS 03-1] au support est propose en option dans la norme IEEE 802.11. Cette
mthode permet une station dobtenir la totalit du support pendant le temps de la transmission de
ses donnes. Les collisions peuvent ainsi tre vites durant les transmissions. Pour cela, il y a une
priode daccs au support avec contention, c'est--dire quil y a comptition entre les stations pour
obtenir lexclusivit du canal. Pour que cette mthode daccs fonctionne, il est ncessaire que toutes
les stations connaissent ce mode daccs. Il nest pas obligatoire que toutes les stations utilisent ce
mode daccs, dautres ont la possibilit dutiliser la mthode DCF.

Figure 1-3 : Partage du canal par trois stations avec la mthode RTS/CTS
Pour viter dventuelles collisions, les stations voulant transmettre une trame de donnes mettent
une trame RTS (Request To Send) aprs une coute pralable du support durant DIFS units de temps
et de lattente du backoff. Lorsque le rcepteur reoit cette trame, il met son tour une trame CTS
(Clear To Send) avec une attente de SIFS secondes aprs la rception du RTS. Les trames RTS et CTS
initialisent le vecteur dallocation du rseau (NAV) avec la dure durant laquelle le mdium sera
occup. Les nuds rceptionnant une de ces deux trames retarderont ainsi la transmission de leurs
donnes de la dure exprime dans le RTS ou le CTS. De fait, les nuds dans le voisinage de
lmetteur et du rcepteur ne peuvent entrer en collision pendant la phase de transmission de donnes.
Cette priode est nomme priode sans contention. Le fonctionnement de ce mcanisme est illustr par
la figure 1-3.
Le mcanisme RTS/CTS participe la rduction de limpact des collisions puisquelles naffectent
que les trames courtes (RTS et CTS). Par contre, il nest pas systmatiquement utilis. Lchange des
RTS et CTS ajoute un surcot chaque trame de donnes, rduisant dautant le dbit utile du canal de
transmission. Ces trames tant transmises un dbit de 2Mbit/s afin de garantir une certaine
RTS
CTS
Donnes
ACK
NAV (RTS)
NAV (CTS)
SIFS
SIFS
SIFS
DIFS
Accs au mdium retard
Emetteur
Rcepteur

16
compatibilit avec la premire version du standard, la dure de cet change est de 564 s
(T
RTS
+ T
CTS
+ 2SIFS), soit le temps ncessaire pour transmettre 6 204 bits un dbit de 11 Mbit/s. Ce
mcanisme savre assez coteux pour une utilisation systmatique. Les cartes dinterface proposent
en gnral de nutiliser ce mcanisme que pour des trames excdant une taille RTSThreshold
(paramtrable).

Figure 1-4 : Problmes des nuds cachs
Lutilisation de cette technique daccs permet de rsoudre certains problmes prsents dans le mode
DCF (tel que le problme des nuds cachs [FUL 97-1]). Ce problme est illustr sur la figure 1-4.
Les nuds A et C tant spars par une cloison, ils ne se voient pas. Le nud C nentendant pas que A
est en train de transmettre, elle considre que le support est libre ce qui en ralit nest pas le cas. Les
transmissions des deux trames crent des collisions lors du recouvrement des deux zones de
couverture de ces stations au niveau du nud B. En utilisant, la mthode daccs au support DCF avec
RTS/CTS, le nud C ne recevrait pas la trame RTS puisquelle nest pas dans la zone de couverture
de A mais recevrait la trame de rponse CTS. En recevant cette trame de rponse, elle connat
dornavant le temps durant lequel le support sera occup. C peut ainsi retarder sa transmission et
viter les collisions.
Ce mcanisme ne permet tout de mme pas de rsoudre lensemble du problme des nuds cachs
[CHA 04-1]. En effet, le mcanisme RTS/CTS choue avec le rseau reprsent sur la figure 1-5. Soit
le nud A, le premier nud vouloir acqurir le support. Il commence par mettre une trame RTS
pour demander cette acquisition. Le nud C, ntant pas dans la zone de couverture de A, ne peut
entendre cette trame. Le nud B voyant que cette trame lui est destine rpond par une trame CTS. A
CLOISON
A
C
B

17
ce mme instant, le nud C met une trame RTS en destination de D. Il ne peut comprendre le CTS
mis par B puisquil est en train dmettre. La transmission entre C et D peut par consquent avoir lieu.
Une collision survient, par consquent, au niveau de B. Ce type de situation est tout de mme
relativement rare, puisquil est ncessaire que le CTS du nud B et le RTS du nud C soient mis
dans le mme laps de temps.

Figure 1-5 : Lutilisation du mcanisme RTS/CTS nempche pas la totalit des collisions.
1.4 Accs au canal sans contention
Le mode DCF de la norme IEEE 802.11 (avec lajout ou non des paquets RTS/CTS) ne peut empcher
la prsence de collisions. De fait, la bande passante utile du rseau est ainsi rduite. Les collisions
augmentent le dlai de bout en bout des paquets de donnes. Les donnes de certaines applications
ncessitent le respect dun dlai. Des mthodes daccs sans-contention ont ainsi t proposes. La
mthode daccs TDMA (Time Division Multiple Access) [JAW 05-1] est largement utilise dans les
rseaux pour garantir un utilisateur laccs unique au support un instant donn.
Dans un environnement synchronis de type TDMA, la bande passante requise par une application est
reprsente par le nombre de slots ncessaires rserver dans la fentre TDMA. Chaque lien, dune
route, doit rserver un nombre de slots pour satisfaire les besoins dun flux. Lorsquun flux arrive
son terme, les slots rservs sont librs. Ils peuvent tre ainsi rutiliss par dautres flux.

Figure 1-6 : Structure dune fentre TDMA de M slots de donnes par fentre, pour un rseau de N
nuds.

18
Une fentre TDMA est compose dune phase de contrle et dune phase de donnes (figure 3-2).
Chaque nud, dans le rseau, possde un slot de contrle qui lui est dsign (slots de contrle 1 N
dans lexemple). Les nuds les utilisent pour transmettre leurs informations de contrle telles que les
trames de synchronisation, les informations de routage Cependant, les nuds sont en comptition
pour acqurir un ou plusieurs slots de donnes libres (slots de donnes 1 M dans lexemple).
Trois rgles doivent tre respectes pour rserver un slot [LIA 02-1]. Lutilisation de ces rgles permet
dviter les collisions lors de transmissions simultanes. Elles permettent galement de rsoudre
entirement le problme des nuds cachs (cf. 1.3.4.2). Un slot t est considr libre et rservable,
pour envoyer des donnes dun nud A un nud B, si les conditions suivantes sont respectes :
Le slot t nest pas dj rserv en rception ou en mission, par le nud A ou B.
Le slot t nest rserv en rception par aucun nud C situ un saut du nud A.
Le slot t nest rserv en mission par aucun nud C situ un saut du nud B.
Si tout instant ces trois rgles sont respectes, le rseau reste exempt de collisions. Lvitement des
collisions permet de maitriser pleinement la bande passante rserve et le dlai dun paquet. Cette
mthode daccs au support est particulirement bien adapte au respect des contraintes de QoS des
applications temps-rel et multimdia.
1.5 Modles de mobilit
La mobilit dans les rseaux ad hoc est un point dlicat traiter. Le dplacement des stations rompt les
liaisons avec les voisins et complexifie la gestion du multi-saut dans les rseaux ad hoc. En effet, les
routes entre deux stations doivent constamment sadapter au changement de la topologie pour
maintenir la continuit de la communication.
Prvoir le dplacement des stations peut aider connatre les instants o une station va rompre la
liaison avec ses voisins et ainsi permettre avant que cela ne se produise de dterminer un autre chemin.
Deux types de modles de mobilit sont gnralement observs : modles de mobilit par entit et
modles de mobilit par groupe.
Dans un premier temps, nous prsentons les principaux modles de mobilit gnralement utiliss
pour reprsenter le dplacement dune seule entit :
Random Walk [ZON 97-1] : Ce modle vise reprsenter le caractre imprvisible des
mouvements dune station. Un nud mobile se dplace de sa position initiale vers une
nouvelle position en slectionnant alatoirement une direction et une vitesse.
Random WayPoint (RWP) [BET 02-1] : Tous les nuds sont uniformment rpartis dans
lespace de mobilit. Les nuds alternent successivement les temps de pause et de

19
dplacement. Un nud immobile, durant une certaine priode fixe, dtermine une destination
et une vitesse alatoire et sy rend.
Random Direction [ROY 01-1] : Ce modle essaye de pallier le problme de RWP dont les
nuds ont tendance se regrouper vers le centre. Dans ce modle, un certain nombre de
nuds qui se dirigent vers le centre sont redirigs en bordure de lespace de simulation.
Brownian Motion [TUR 01-1] : Tous les lments (direction, vitesse, temps de pause) de ce
modle sont entirement alatoires. Chaque nud se dplace jusqu atteindre sa destination
aprs une priode dattente calcule alatoirement.
Manhattan Grid [ETSI 98-1] : Ce modle reprsente le dplacement dans une ville avec des
rues toutes perpendiculaires les unes aux autres. Chaque nud mobile commence un point
alatoire dune rue. Puis il se dplace jusqu sa destination une vitesse prdfinie. Une fois
la destination atteinte, il fait une pause avant de reproduire le processus. Chaque nud se
dplace horizontalement ou verticalement.
Nous prsentons maintenant les principaux modles de mobilit par groupe. Dans ces modles, il nest
plus question du dplacement dun seul nud mais dun ensemble de nuds. Les modles sont les
suivants :
Pursue Model (PM) [CAM 02-1] : Ce modle reprsente un ensemble de nuds traquant un
nud spcifique appel chef. Un nud particulier dans chaque groupe agit comme le chef et
se dplace suivant un modle de mouvement particulier (gnralement RWP). Les nuds
restants du groupe se dplacent vers le chef avec une vitesse alatoire.
Reference Point Group Mobility (RPGM) [HON 99-1] : Ce modle reprsente le dplacement
alatoire de groupes entre eux ainsi que le dplacement alatoire des nuds dans chaque
groupe. Chaque groupe possde un comportement mobile propre. Chaque groupe possde un
centre logique que les nuds du groupe suivent lors de leurs dplacements.
Nomadic Community [SAN 99-1] : Ce modle reprsente des groupes de nuds mobiles qui
se dplacent collectivement dun point un autre. Dans chaque groupe, les nuds possdent
un espace qui leur est propre. Ils peuvent se dplacer leur guise dans cet espace.
1.6 Discussion
Les rseaux sans fil connaissent une importante croissance et lapparition 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 multimdia, temps rel en environnement
mobile. Dans nos objectifs, la mobilit est un paramtre important. Il nous a paru que les rseaux ad
hoc rpondent mieux nos attentes. De fait, le contexte de notre tude se base sur les rseaux
MANETs et profite de leurs caractristiques : mobilit, autonomie et auto-organisation.

20
De nombreuses technologies sont susceptibles dagir dans un mode ad hoc. Dans nos travaux, nous
avons fait le choix doprer sur des rseaux lchelle dun campus (environ 1km). Du fait de leur
forte implantation lheure actuelle, nous avons choisi demployer le mode ad hoc des rseaux IEEE
802.11.
Dans ce chapitre, nous avons prsent les rseaux IEEE 802.11 (cf. 1.3), et particulirement leur
mode ad hoc. Nous avons expos les caractristiques et contraintes de ces rseaux (cf. 1.2). Ltude
de leurs performances dans des environnements mobiles suppose lutilisation de modles de mobilit
permettant une simulation du mouvement des nuds dans le temps (cf. 1.4).
La forte consommation de bande passante des applications multimdia et temps-rel, combine aux
caractristiques et contraintes des rseaux MANETs, limite leur utilisation conjointe. Les diffrents
protocoles employs dans les rseaux 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 nuds trop loigns
souhaitent communiquer, ils ont besoin de nuds relais permettant le transfert de leurs donnes sur le
chemin les sparant. Pour permettre ces relais, certains nuds du rseau doivent agir comme des
routeurs, et, ce titre, dployer des protocoles de routage permettant de dcouvrir et de maintenir des
routes entre les acteurs du rseau.
Notre objectif est doptimiser la bande passante disponible pour les applications en environnement ad-
hoc multi-saut. La rponse cet objectif implique que les protocoles de routage doivent tenir compte
des spcificits des rseaux sans fil ad hoc (cf. 1.2.2) : faible dbit, capacit des liens variables,
modification de la topologie du rseau avec le temps, et partage du support de transmission. Deux
points sont tudis dans la suite de notre contribution :
- Ltude du fonctionnement des principaux protocoles de routage existant dans les rseaux ad
hoc et constater sils mettent en uvre des mcanismes pour prserver la bande passante des
MANETs. Cette tude rpond notre critre de mobilit et lamlioration de la bande
passante des rseaux MANETs (cf. 2. Routage Meilleur effort dans les rseaux MANETs).
- Ltude des paramtres de qualit de service dont les applications ont besoin et tudier
ladquation des protocoles de routage supporter de telles contraintes. Ce second point
rpond notre critre de qualit (cf. 3. Routage Qualit de Service dans les rseaux
MANETs).

21
2 Routage Meilleur effort dans
les rseaux MANETs
Les rseaux ad hoc tant de nature multi-sauts, le protocole de routage dtermine une route entre un
nud source et un nud destination. De par la faible bande passante offerte par les rseaux ad hoc et
du fait de la diffusion des donnes, les protocoles de routage actuellement utiliss dans les rseaux
filaires ne peuvent tre utiliss, sans modifications, dans les rseaux MANETs. De fait, de nouveaux
protocoles de routage ont d tre dvelopps.
Pour tre rellement oprationnel dans un environnement mobile, le protocole de routage prend en
compte trois phases :
1) Dissmination de linformation de routage : Elle permet de connatre suffisamment dlments sur
la topologie pour choisir un chemin atteignant le nud de destination. Suivant la quantit
dinformations changes, les nuds obtiennent une vue plus ou moins prcise de la topologie du
rseau. Le protocole de routage se voit dans lobligation doptimiser lenvoi de ces informations, car
elles sont fortement consommatrices en bande passante.
2) Slection du chemin : Une fois les informations de routage obtenues, le protocole de routage peut
slectionner une route parmi lensemble obtenu en fonction de certains critres. Pour les protocoles
Meilleur effort ( Best Effort ), le critre est de minimiser le nombre de sauts du chemin. Ainsi,
parmi lensemble des routes qui lui sont proposes, le protocole choisit celle traversant le plus faible
nombre de nuds. Les routes choisies doivent tre dpourvues de boucles. La prsence de boucles
rend inefficace le chemin slectionn puisque le paquet ne pourra pas atteindre la destination
consommant inutilement de la bande passante. En effet, un paquet de donnes transitant sur un chemin,
possdant une boucle, va tourner en rond tant que la boucle est prsente. Pour viter quun paquet de

22
donnes tourne indfiniment, le paquet est dtruit lorsquil atteint la limite impose par le champ TTL
prsent dans le protocole IP. Un protocole de routage peut crer deux sortes de boucles : les boucles
temporaires et les boucles permanentes [CRK 89-1]. Les premires ont lieu pendant le transfert dun
message de routage. Durant ce temps, des stations peuvent tre mises jour et dautres non, do la
possible apparition dune boucle. Elle dure au maximum la dure de traverse du rseau par un
message de routage. Les boucles permanentes, quant elles, sont dues au phnomne du bouclage
linfini [IET 93-1]. Ces boucles peuvent consommer normment de bande passante.
3) Maintenance des routes : Dans un environnement mobile, la topologie du rseau ne cesse dvoluer
avec le temps. De fait, les routes sont amenes changer avec le dplacement des nuds. 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 coupes.
Dans ce chapitre, nous prsentons les protocoles de routage meilleur effort les plus rpandus. De tels
protocoles de routage optimisent uniquement le nombre de sauts. Ils sont censs trouver le chemin
ayant le plus faible nombre de sauts entre une source et une destination donnes. Le nombre de sauts
dsigne le nombre de nuds traverss par les paquets pour atteindre une destination.

Figure 2-1 : Diffrents types de protocoles de routage Meilleur Effort
Il est possible de classer les protocoles de routage suivant trois critres (figure 2-1) [XIA 02-1] : le
type de dissmination de linformation de contrle, la hirarchie utilise et lutilisation dinformation
de localisation.

23
Trois types de protocoles de routage peuvent tre rpertoris suivant la faon dont ils dissminent
linformation de contrle : les protocoles proactifs, les protocoles ractifs et les protocoles hybrides
[MEH 03-1], [MAU 01-1], [BEL 99-1]. Dans un protocole proactif, chaque nud change
priodiquement sa connaissance de la topologie du rseau avec ses nuds voisins. Un protocole ractif
met des informations de routage uniquement lors de la cration dune route. Les protocoles hybrides
font un mixe entre les deux types prcdents. A faible distance ils dissminent leur connaissance de la
topologie (protocole proactif) et pour des routes une distance suprieure linformation de routage est
change seulement lorsque lobtention dune route est ncessaire (protocole ractif).
Les protocoles de routage peuvent galement tre classs suivant un autre critre : le type de leur
hirarchie. En effet, un protocole de routage peut ou non utiliser une hirarchisation des nuds dans le
rseau. Un protocole utilisant une hirarchie spare les nuds en plusieurs niveaux. Un nud de
niveau suprieur peut contrler les nuds se trouvant plus bas dans larbre de hirarchie.
Le dernier critre pour classer les protocoles de routage est lutilisation dinformations de localisation
pour trouver une route. Les informations de localisation sont changes entre les nuds pour connatre
la position gographique des autres nuds du rseau. La position gographique dun nud peut tre
obtenue en utilisant les coordonnes GPS [GPS] par exemple. Connatre la position des autres nuds
permet de diriger les informations de routage vers la position de la destination. Le nombre
dinformations utilises, la dtermination dune route, est donc diminu. Une telle diminution
prserve la bande passante, ressource rare dans les rseaux MANETs.
2.1 Type de dissmination de linformation de routage
Un des aspects qui a suscit de nombreux dbats et travaux concerne le nombre de routes quun nud
doit conserver dans sa table de routage. En effet, un nud doit-il mmoriser les routes pour atteindre
tous les nuds destinations, ou seulement garder trace des routes pour atteindre les nuds destinations
sur lesquels un intrt est port. Par consquent, trois types de protocoles de routage se sont distingus
suivant la manire dont les routes sont maintenues dans les tables de routage et linformation de
routage est dissmine. Dans les protocoles proactifs, les nuds maintiennent une route vers chaque
nud du rseau. De mme, ils mettent priodiquement des informations de routage leurs voisins.
Les nuds, excutant un protocole ractif, maintiennent seulement les routes actives (les routes qui
sont utilises). Ils mettent des informations de routage uniquement lorsquune route a besoin dtre
trouve. Les protocoles hybrides utilisent un mlange des deux prcdents types.
2.1.1 Protocoles de routage Proactifs
Chaque nud, employant un protocole de routage proactif, conserve la route ncessaire pour atteindre
nimporte quel autre nud du rseau. Chaque nud maintient une table de routage contenant les
informations ncessaires (par exemple le prochain nud sur le chemin) pour atteindre un autre
nud du rseau. En consultant sa table de routage, un nud peut tout instant transmettre un paquet
de donnes vers un autre nud du rseau.

24
Des mises jour priodiques de ltat de la topologie gardent effectives les routes prsentes dans la
table de routage. Les performances de ce type de protocoles souffrent du trafic additionnel ncessaire
au maintient de ltat des routes. Pour conserver des routes valides, le rafrachissement des
informations sur la topologie dpend de la mobilit des nuds du rseau MANET. Si le
rafrachissement est trop lev, compar lvolution de la topologie, le nombre dinformations de
routage mises sur le rseau est trop important, consommant inutilement de la bande passante. A
contrario sil est trop faible, les tables de routage ne sont pas suffisamment mises jour, rendant les
informations quelles contiennent obsoltes. Pour un fonctionnement optimal de ce type de protocoles,
un compromis entre lchange des informations de routage et la prise en compte de lvolution de la
topologie doit tre trouv.
Dans un premier temps, nous prsentons les protocoles DSDV et OLSR. Ces protocoles sont les
protocoles proactifs les plus rpandus dans la littrature. Le protocole DSDV est une rfrence de part
son anciennet, alors que le protocole OLSR est le seul reprsentant standardis des protocoles
proactifs.
2.1.1.1 Protocole DSDV
Lalgorithme de routage proactif tudi dans cette partie est lalgorithme de routage Destination-
Sequenced Distance-Vector (DSDV) [PER 94-1]. Il est bas sur lalgorithme du vecteur de distance
utilis dans RIP [RFC 2453]. Le protocole vecteur de distance permet de limiter lchange des
messages de contrle de la topologie uniquement aux voisins dun nud. Ce point est extrmement
important pour prserver la bande passante disponible sur le rseau.
Le protocole DSDV utilise les proprits de la diffusion pour transmettre les informations de routage.
En effet, le grand avantage de la diffusion est quune trame mise par une station est entendue par
lensemble de ses voisins. Priodiquement, chaque station diffuse lensemble de sa table de routage
suivie dun numro pour dater linformation. Ce numro est appel numro de squence. A partir de
deux numros de squence, il est possible de dterminer quelle information est la plus rcente. La
table de routage dun nud contient les informations lies chaque route (adresse de destination,
nombre de nuds pour joindre cette destination et numro de squence de la destination).
A la rception de ces informations, les voisins mettent jour leur table de routage en suivant un
schma bien prcis. Toute entre de la table de routage est mise jour, seulement, si linformation
reue est plus rcente, ou si elle a le mme ge mais possde un nombre de nuds plus faible. A terme,
le protocole DSDV fournit pour chaque destination, la route qui possde le plus faible nombre de
nuds.
Pour tre un protocole de routage complet, le protocole DSDV doit maintenir ltat des chemins. Pour
cela, les nuds dtectent les ruptures de lien. Chaque nud met, priodiquement, ses informations de
routage lensemble de ses voisins. Si pendant un certain temps, un nud ne reoit plus les
informations de routage dun nud voisin cest que ce dernier ne fait plus partie de son voisinage. Un
lien coup affecte lensemble des routes utilisant ce lien. Un nud, dcelant une coupure, diffuse un
paquet contenant lensemble des destinations ne pouvant plus tre atteint travers ce lien. Tout nud,

25
recevant un tel paquet, le propage immdiatement pour faire connatre au plus vite le changement de
topologie. Un des problmes de cet algorithme est quil ragit trop lentement aux mauvaises nouvelles.
La destination doit prendre connaissance dune 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 lalgorithme tat de liens [RFC 2328]. Un nud du protocole tat de
liens diffuse sa connaissance des voisins lensemble de la topologie. De nombreux changements ont
d y tre apports pour tre exploitable dans un rseau ad hoc. La bande passante tant limite la
diffusion de ses voisins lensemble des nuds du rseau est bien trop coteuse. Le protocole OLSR
prend en compte les spcificits de la diffusion (un paquet mis est reu par lensemble des nuds
dans son voisinage immdiat) pour rduire le nombre de paquets ncessaires lchange de la
topologie.
Chaque nud doit dterminer lensemble de ses voisins. Pour cela priodiquement, ils transmettent
des paquets, dits Hello, pour se faire connatre. Ce type de paquet comprend la totalit de la base de
liens connue par lmetteur du paquet. La base de liens dun nud regroupe lensemble des nuds lui
ayant transmis un paquet Hello. A la rception des paquets Hello, chaque nud dans le rseau connat
les nuds situs dans son voisinage immdiat mais galement deux sauts.
Une fois les voisins dcouverts, les nuds peuvent changer les informations sur leur voisinage pour
former la topologie du rseau. Cette fonction est attribue des nuds particuliers slectionns parmi
ses voisins un saut. Ces nuds sont appels relais multipoints (MPRs) et sont les seuls capables de
transmettre les informations de routage. Chaque nud slectionne un ensemble de MPRs relayant les
informations de routage lensemble des nuds situs deux sauts. Chaque MPR transmet,
priodiquement, la liste des nuds qui lont choisi comme MPR. Un tel paquet est, seulement, relay
par les nuds slectionns en tant que MPRs.
Une fois la topologie connue par lensemble des nuds du rseau, il suffit dappliquer un algorithme,
de type Dijkstra, pour dterminer les routes vers lensemble des nuds distants. Chaque nud connat,
ainsi, les routes les plus courtes vers les autres nuds du rseau.
2.1.1.3 Autres protocoles proactifs
Dans un souci dconomie de bande passante, nous tudions les protocoles proactifs GSR, FSR, WRP
et STAR. Ils se distinguent des autres protocoles proactifs, de part leur mthode de dissmination de
linformation. Lchange des informations de routage fluctue avec la stabilit du rseau ou
lloignement des nuds, rduisant la quantit dinformations changes.
Le protocole Global State Routing (GSR) [CHE 98-1] est bas sur le protocole tat de liens. Il
diffre du protocole tat de liens par sa faon propager sa connaissance du rseau. Un nud diffuse,
seulement ses voisins, sa connaissance de la topologie du rseau. De fait, le surcot (overhead) est
drastiquement rduit compar aux protocoles tat de liens. Par contre pour des rseaux relativement

26
denses, la taille de la topologie est importante. Dans ce cas, le nombre de paquets de contrle changs
devient consquent.
Le protocole Fisheye State Routing (FSR) [GER 02-1] est bas sur le protocole GSR. Pour rduire le
nombre de messages de contrle et surtout leur taille, un nud transmet plus souvent sa connaissance
de la topologie situe proximit que celle dont les nuds sont loigns. Il part dun constat de
socit o chaque tre humain connat parfaitement les personnes qui habitent dans leur quartier, et
uniquement les noms des villages et villes lorsquil sen loigne. Un paquet de donnes arrive
correctement destination malgr les tats imprcis du rseau, puisquau fur et mesure quil se
rapproche de la destination, la connaissance de la topologie se prcise.
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
rseau surviennent. Ces mises jour doivent tre acquittes par la totalit des nuds voisins (dtectant
ainsi une perte ventuelle). Pour dtecter ces changements, les nuds transmettent priodiquement des
paquets pour se faire connatre 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 lensemble des routes prfres pour joindre les
destinations. Ce protocole rduit la quantit dinformations de contrle changes en liminant les
mises jour priodiques du protocole tat de liens. Lenvoie de son arbre nest pas fait
priodiquement, il est ralis uniquement lors de changements importants sur le rseau (dtection
dune nouvelle destination, rupture dun lien). Cette approche vite les mises jour priodiques. Ce
protocole est performant lors du passage de vastes rseaux car il matrise le nombre de messages de
contrle transmis.
2.1.2 Protocoles Ractifs
Les protocoles de routage ractifs (ou sur demande) ne maintiennent une route que si elle est utilise.
Lorsquun nud source a besoin de transmettre des donnes vers un nud destination, il doit au
pralable dterminer une route. Pour cela, des informations de contrle sont transmises sur le rseau.
Compars aux protocoles proactifs qui conservent les routes vers lensemble des stations du rseau
dans leur table de routage, les protocoles ractifs ne conservent que les routes qui ont une utilit. Par
consquent, la taille des tables de routage contenues en mmoire est moins importante que pour les
protocoles proactifs.
Trouver une route, lorsque la source en a besoin, cre une latence avant de lobtenir. Pour certaines
applications ncessitant un minimum de ractivit, ce dlai peut tre problmatique. Ce dlai nest
seulement occasionn au dbut de lchange dinformation (lors de ltablissement de la route) ou
lorsquune route est rompue (lors du dplacement dun nud par exemple). Durant le laps de temps o
le protocole de routage dtermine la route ncessaire, les paquets provenant de la couche suprieure
sont conservs en mmoire.

27
Dans un premier temps, nous prsentons les protocoles ractifs AODV et DSR. Ces protocoles sont les
protocoles ractifs ayant le plus de chances dtre utiliss dans les rseaux MANET du fait quils
soient standardiss.
2.1.2.1 Protocole AODV
Le protocole de routage Ad hoc On-Demand distance Vector (AODV) [RFC 3561] permet le maintien
des routes utilises. En fait, si le changement de statut dun lien naffecte pas une communication,
aucun change entre les nuds nest donc ncessaire. Les effets des changements de topologie sont
ainsi localiss seulement aux routes rencontrant ces modifications et non la globalit du rseau. Ce
protocole est oprationnel seulement dans un environnement o les liens sont symtriques. Ce
protocole met en uvre diffrentes oprations pour raliser et maintenir le routage : gestion de la
connectivit locale, phase de dcouverte des routes, maintenance des routes.
La fonctionnalit de gestion de la connectivit locale est applique par les nuds de la manire
suivante. Chaque nud met priodiquement un paquet, nomm Hello. A la rception de ce paquet,
les nuds apprennent la prsence des nuds voisins. La connectivit locale est modifie dans les cas
suivants : un nud reoit un paquet Hello transmis par un nouveau voisin ou un nud ne reoit plus
de paquets Hello durant un laps de temps dfini.
La phase de dcouverte des routes par le protocole AODV est la suivante (cf. Annexe I pour les
organigrammes des nuds). A la rception dun paquet de donnes par la source, elle vrifie dans sa
table de routage si une route existe jusqu la destination. Si elle existe, le paquet est transmis vers le
prochain nud sinon la phase de dcouverte des routes est engage. Le paquet est mis en file dattente
le temps dobtenir une route puis la source diffuse une requte de cration de routes, nomme RREQ.
A la rception dun paquet RREQ, un nud met jour la route inverse en direction de la source. Le
nud vrifie, ensuite, sil connat une route vers la destination. Sil en possde une, il envoie une
requte de rponse, nomme RREP, en direction de la source. Sinon, il diffuse la requte RREQ ses
voisins. Lorsque la requte RREP transite vers la source, chaque nud sur le chemin inverse met
jour sa table de routage avec, comme prochain nud, ladresse du nud qui a mis la requte RREP.
Le temporisateur de cette entre dans la table de routage est mis jour. Ce temporisateur indique
quune route est toujours active sil est non nul.
Pour chaque destination dintrt, un nud maintient une unique entre dans sa table de routage qui
contient les champs suivants : adresse de la destination, numro de squence de la destination,
prochain nud sur le chemin vers la destination, nombre de sauts et dautres paramtres relatifs la
route. Lutilisation du numro de squence permet de dater la route et dviter la prsence de
boucles. Si deux routes existent entre un nud et la destination, le nud conserve la route la plus
rcente. Si les deux routes sont dcouvertes simultanment, la route avec le plus faible nombre de
sauts est conserve.
La phase de dcouverte des routes peut, aussi, tre ralise en utilisant une recherche de parcours en
largeur. La source positionne, lors de la premire tentative de recherche de route, le champ TTL de la
requte RREQ la valeur TTL_DEBUT. Elle positionne le temporisateur, dattente dun paquet RREP,

28
la valeur TEMPS_TRAVERSE millisecondes. La valeur TEMPS_TRAVERSE est calcule avec la
formule suivante :
( ) NOEUD TRAVERSE TEMPS CONGESTION TEMPS TTL TRAVERSE TEMPS _ _ _ 2 _ + =
(2-1)
o TEMPS_TRAVERSE_NOEUD est le temps moyen estim de la traverse dun saut par un paquet et
TEMPS_CONGESTION est un temps supplmentaire au cas o la requte RREP est retarde due une
congestion.
Si le temporisateur initialis TEMPS_TRAVERSE arrive chance, c'est--dire que la source na
pas reu de rponse RREP dans le temps imparti, la source diffuse une nouvelle requte RREQ avec le
champ TTL incrment avec la valeur TTL_INCREMENT. Ceci est ralis jusqu que le TTL atteigne
un certain seuil. Dans un tel cas, le TTL est positionn avec le diamtre du rseau, et la phase de
dcouverte des routes devient identique celle prsente prcdemment. Aprs chaque tentative, le
temporisateur dattente dune rponse RREP est positionn avec une valeur de TEMPS_TRAVERSE
millisecondes.
Le nombre de sauts conserv dans une entre invalide de la table de routage ( cause dun temps
dinactivit trop lev par exemple, de perte de route) indique le dernier nombre de sauts connu
pour atteindre cette destination dans la table de routage. Lorsquune nouvelle route vers cette
destination est requise, le TTL dans la requte RREQ est initialis ce nombre de sauts plus
TTL_INCREMENT.
La phase de maintenance des chemins est ralise en plusieurs tapes. La premire tape consiste en la
dtection de la perte dun chemin. Quand un nud sur un chemin tabli se dplace, les routes passant
par ce nud peuvent tre rompues. Les nuds en amont, dtectant la perte de connectivit,
prviennent les sources affectes en mettant une requte derreur, note RERR. A la rception de ce
paquet, le nud source engage la deuxime tape de la maintenance des routes. Il entame une nouvelle
phase de dcouverte des routes, si un chemin est toujours ncessaire.
2.1.2.2 Protocole DSR
Le protocole Dynamic Source Routing (DSR) a t standardis en 2007 [RFC 4728]. Son
fonctionnement est trs proche du protocole AODV la grande diffrence quil fournit dans les
paquets de donnes lensemble des nuds permettant datteindre une destination (routage par la
source). Cet ajout dans les paquets de donnes accrot le surcot et consomme un peu plus de bande
passante. A contrario, ces informations lui permettent de grer lasymtrie des liens prsents dans le
rseau. En effet, un paquet de donnes peut prendre une route diffrente de son acquittement. Le
fonctionnement basique de DSR savre assez simple mettre en uvre. Il met en place uniquement
deux phases : la phase de dcouverte des routes, et la phase de maintenance de ces mmes chemins.
Le fonctionnement de la dcouverte des routes est le suivant. Un nud source initie une requte de
dcouverte des routes (Route Request) lorsquun paquet de la couche suprieure lui provient et quil
ne possde pas de route vers sa destination. Le nud source avant de transmettre la requte de route

29
ajoute son adresse dans le champ route du paquet ainsi quun identifiant, ladresse source et ladresse
de destination. Lorsquun nud intermdiaire reoit une requte de route, il vrifie tout dabord sil a
dj reu la requte. Pour cela, il utilise les champs adresse source, adresse destination et identifiant
qui permettent didentifier de manire unique une requte de route. Si une telle requte a dj t reue,
elle est supprime. Dans le cas o la requte lui est destine, il lacquitte en envoyant une requte de
rponse (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 consquent, le chemin destination-
source peut tre diffrent du chemin source-destination . A la rception dune requte de
dcouverte des routes, le nud de destination vrifie sil possde dj une route en direction de la
source. Sil en connat une, il transmet la rponse sur cette route. Dans le cas contraire, il doit en
dterminer une. Pour cela, il rutilise le fonctionnement de la dcouverte des routes nonc plus haut.
A la seule diffrence quil intgre le paquet de rponse (contenant la route entre la source et la
destination) sa propre requte de route. Une fois que la source reoit la requte de route, elle extrait
le chemin pour joindre la destination et lajoute dans sa table de routage. Elle envoie un paquet de
rponse la destination sur ce chemin, confirmant le chemin destination-source .
Lopration de maintenance consiste dans un premier temps dterminer si un lien est rompu. Cette
opration peut tre ralise par la sous-couche MAC. Si au bout dun certain nombre dmissions
aucun acquittement nest reu, le lien peut tre considr comme coup. Un nud dtectant la rupture
prvient lensemble des sources avec un paquet derreur (Route Error). A la rception dun tel paquet,
les sources dterminent une nouvelle route si aucune autre nest connue.
2.1.2.3 Autres protocoles ractifs
De nombreux autres protocoles ractifs ont t dvelopps ces dernires annes. En particulier, nous
pouvons cits LMR, TORA, AOMDV, BSR et ABR. Ces protocoles proposent un axe intressant dans
la prservation de la bande passante. La phase de maintenance des routes rtablit une route lorsquelle
est interrompue. Cette maintenance engendre un cot en nombre de messages changs et donc en
bande passante consomme. Ces protocoles proposent des solutions pour diminuer limpact dune
rupture de route sur la bande passante du rseau.
Le protocole de routage Light-weight Mobile Routing (LMR) [COR 95-1] est un protocole de routage
ractif qui utilise la diffusion pour dterminer les routes. Les nuds, 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 nest pas systmatiquement ncessaire de
dterminer une route qui engendre un certain dlai. Dans LMR si une autre route est disponible, elle
est utilise. Par contre, ce protocole peut produire temporairement des routes invalides avec la
prsence de boucles.
Le protocole de routage Temporally Ordered Routing Algorithm (TORA) [PAR 97-1] est bas sur le
protocole LMR. De fait, il dtermine plusieurs routes pour joindre une destination. Lavantage de
TORA compar LMR est quil obtient plus rapidement une nouvelle route lors de la rupture dun

30
lien. En effet, lorsquun nud dtecte un lien coup et quil na plus aucune route pour joindre la
destination, il doit en dterminer une nouvelle. Le protocole TORA ralise cette opration dans un laps
de temps plus court que LMR. Contrairement LMR, TORA ne ncessite pas de confirmation lors de
lobtention dune 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 dtermine plusieurs chemins qui sont soit disjoints par
leurs nuds, soit disjoints par les liens quils traversent. Deux chemins sont disjoints par les nuds
traverss si les nuds sont diffrents deux deux. Deux chemins seront disjoints vis--vis des liens si
les liens traverss sont diffrents deux deux. Utiliser des chemins disjoints permet la rupture dun
lien dtre rpercute sur un seul chemin. Les autres chemins restent donc oprationnels et peuvent
tre emprunts.
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 dcouverte des chemins aprs la rupture dun lien. Pour cela, les
nuds maintiennent le chemin principal le plus court mais galement un chemin de secours plus stable.
Lorsque le chemin principal nest plus oprationnel, les paquets empruntent le chemin de secours
rduisant le temps de latence engendr lors du calcul dun nouveau chemin.
Le protocole Associativity-Based Routing (ABR) [TOH 96-1] privilgie les nuds les plus stables.
Pour dterminer cette stabilit, chaque nud met priodiquement des balises ses voisins pour faire
connatre sa prsence. Un nud calcule la stabilit dun voisin en fonction du temps quil passe dans
son voisinage. Lors de la rupture dun lien, le nud affect essaye de rtablir les chemins coups et
ainsi dviter aux sources de raliser une nouvelle phase de dcouverte des routes.
2.1.3 Protocoles Hybrides
Dans un souci de prserver la bande passante, les protocoles de routage hybrides combinent les
avantages des protocoles proactifs et ractifs. Lorsquil faut traverser un grand nombre de nuds, les
protocoles ractifs deviennent plus intressants 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 nuds. En effet, lentretien des routes est beaucoup plus facile,
car seulement les routes utilises ont besoin dtre mises jour lors dune modification de la topologie.
Les protocoles proactifs sont plus performants dans des rseaux ayant un faible nombre de nuds. En
effet, ils connaissent tout moment au moins une topologie partielle du rseau, et donc peuvent
dterminer immdiatement le prochain nud en direction de la destination. Aucune latence au niveau
de lmetteur ne se fait donc ressentir. La consommation de bande passante est dans ce cas
relativement minime car peu de stations sont prsentes dans le rseau.
Les protocoles hybrides vont donc tirer avantage de ces deux protocoles. Un nud va utiliser, dans son
proche entourage, un algorithme de routage proactif. Ainsi, chaque nud a une connaissance globale
de son voisinage. Puis lextrieur de son entourage immdiat, il va utiliser un algorithme de routage
ractif. Ce type dalgorithme sinspire du comportement humain, c'est--dire que nous avons une

31
bonne connaissance du quartier o lon habite, mais plus on sen loigne, plus on ne connat que les
axes pour atteindre notre lieu de destination, et pas ce qui lentoure.
Nous prsentons dans un premier temps le protocole hybride ZRP qui est le protocole hybride le plus
rfrenc dans la littrature. Nous prsentons, ensuite, deux protocoles hybrides ZHLS et SHARP qui
diffrent de ZRP par lchange des informations de routage vers les zones extrieures (InterZone) et
par la formation des zones.
2.1.3.1 Protocole ZRP
Le protocole de routage hybride le plus rpandu est le protocole Zone Routing Protocol (ZRP)
[HAS 99-1]. Ce protocole dcoupe la topologie du rseau en deux zones. La premire zone est celle
dans le voisinage de chaque nud, elle est appele Intrazone. En fait, cest lensemble des nuds qui
se trouvent un nombre de sauts infrieur ou gal H
max
. La seconde zone est la zone extrieure un
nud, appele Interzone, c'est--dire lensemble des nuds qui se trouvent un nombre de sauts
suprieur H
max
.
Pour dterminer le chemin pour joindre une destination, deux protocoles de routage vont tre
employs suivant la zone dans laquelle se trouve la destination. Ainsi, si la destination se situe dans
lIntrazone, le protocole de routage proactif Intrazone Routing Protocol (IARP) est utilis. Si la
destination est extrieure cette zone, le protocole de routage ractif Interzone Routing Protocol
(IERP) est employ.
Le protocole de routage IARP est bas sur un protocole tat de liens. Chaque nud diffuse,
priodiquement, sa connaissance de ses voisins. A laide des informations diffuses, les nuds
construisent la topologie et dterminent les routes vers les nuds situs proximit. Pour viter que la
diffusion des paquets de contrle se propage sur la totalit du rseau, la source met le champ TTL la
valeur de H
max
, le nombre de saut maximum auquel se limite lIntrazone. Chaque fois quun nud
reoit un tel paquet, il met jour sa table de routage puis dcrmente de 1 le champ TTL du paquet. Si
ce champ est gal 0 le paquet est supprim sinon il est propag.
Lorsque le nud source ne connat pas de chemin vers la destination, cest quelle ne se trouve pas
dans lIntrazone. Il utilise le protocole IERP pour dterminer un chemin jusqu elle. Le protocole
IERP est responsable uniquement des communications entre les diffrentes zones. La source
dtermine un ensemble de nuds frontires son Intrazone. Elle utilise ces nuds pour dterminer un
chemin jusqu la destination, tout en rduisant le dlai et le surcot pris par la recherche. Lors de la
rception de la requte de demande de cration de route, les nuds frontires ajoutent leur identifiant
dans lentte de la requte. Ensuite, deux procdures sont appliques selon que ces nuds connaissent
une route vers la destination ou pas :
La destination est dans lIntrazone dun nud frontire : une rponse est envoye la
destination en prenant le chemin inverse contenu dans lentte de la requte.
La destination ne se situe pas dans lIntrazone dun nud frontire : la requte est propage
lensemble de ses nuds frontires et lopration recommence jusqu dterminer un chemin.

32
2.1.3.2 Autres protocoles hybrides
Nous prsentons deux protocoles hybrides ZHLS et SHARP. Ces protocoles rduisent le trafic de
contrle pour dterminer une route avec un nud situ dans lInterZone.
Le protocole Zone-Based Hierarchical Link State Protocol (ZHLS) [JOA 99-1] comme ZRP allie une
recherche proactive dans lIntrazone et une recherche ractive dans lInterzone. Il suppose que le
rseau est divis en zones qui ne se chevauchent pas. La taille des zones est fonction de la rapidit de
dplacement des nuds prsents sur le rseau, du nombre de nud prsent dans la topologie, du rayon
de transmission de chaque nud Dans lIntrazone, ZHLS utilise le protocole tat de liens pour
dterminer lensemble des nuds qui la composent. Connaissant la topologie, chaque nud dtermine
les routes pour joindre lensemble des nuds de sa zone. Le routage dans linterzone consiste, dans un
premier temps, dterminer les nuds frontires faisant liaison avec les zones voisines. Lorsquune
zone a dtermin celles qui lentourent, la totalit des nuds du rseau propage cette information. De
fait, chaque nud dtermine un chemin vers les autres zones du rseau. Lors de la recherche dune
route dont la destination est situe dans lInterZone, la source interroge lensemble des zones du
rseau pour dterminer quelle zone appartient la destination. Une fois la zone identifie, la source
peut envoyer vers cette zone des paquets de donnes qui arriveront destination. Ce protocole rduit
le nombre dinformations de contrle chang pour dterminer un chemin. Par contre, il suppose que
le rseau est dj divis en zones qui ne se chevauchent pas.
Le protocole Sharp Hybrid Adaptive Routing Protocol (SHARP) [RAM 03-1] rgule les informations
de routage changes par les protocoles proactif et ractif en adaptant dynamiquement lIntrazone
autour dun nud. Chaque nud dfinit le nombre de nuds dans son Intrazone en fonction du trafic
quil reoit.
2.2 Hirarchisation du rseau
Les rseaux ad hoc sont structurs hirarchiquement en diffrenciant les nuds prsents sur le rseau.
Il est possible de voir la hirarchisation des nuds comme un arbre hirarchique dans une entreprise.
Les nuds les plus hauts dans la hirarchie dirigent les nuds se trouvant en dessous. Les nuds les
plus bas dans la hirarchie dpendent directement de leur suprieur hirarchique. Ainsi, les nuds se
voient affects des fonctions diffrentes suivant leur place dans la hirarchie. Les rseaux ad hoc sont
structurs hirarchiquement sous forme de clusters. Nous dtaillons dans un premier temps les rseaux
de clusters, puis un sous-ensemble de ce type de rseau, les rseaux backbone.

33
2.2.1 Cluster

Figure 2-2 : Topologie dun rseau de clusters
Les rseaux de clusters sont un dcoupage du rseau en un ensemble de petits groupes grs par des
chefs de groupe [GER-95]. Ils peuvent tre aisment reprsents par la figure 2-2. Le chef de groupe,
appel aussi clusterhead, gre lensemble des nuds qui sont directement connects lui. Parmi cet
ensemble, on peut distinguer les passerelles qui font le lien avec un autre cluster des nuds normaux
qui sont rattachs uniquement au chef de groupe. Le chef de groupe se voit affecter de nombreux rles
tels que dcider quelle station peut accder au support, diffuser les tables de routage pour rduire le
surcot, grer la qualit de service
Les rseaux de clusters doivent dans un premier temps former la structure du rseau en lisant les
chefs de groupes. Par la suite, il est ncessaire de maintenir cette hirarchisation pour le bon
fonctionnement du rseau. Llection des chefs de groupe se fait de manire distribue. Au dbut,
lensemble des nuds se trouvent la base de la hirarchie. Par la suite, les nuds vont lire leurs
chefs de groupe suivant lun des critres suivants, le numro didentifiant [EPH-87] ou le degr des
nuds [PAR-94]. Dans ces deux algorithmes, seul le critre sur le choix du chef de groupe diffre. La
faon de slectionner un chef de groupe reste la mme.
Les nuds tant en mouvement, un chef de groupe peut rompre la connectivit avec les nuds qui lui
sont rattachs. De mme, il peut cesser de fonctionner car la station peut steindre ou ne plus avoir
suffisamment dnergie pour raliser ce rle. Lors de la perte de connectivit, cet ensemble de nuds
doit lire un nouveau chef de groupe. Pour cela, il suffit de rappliquer lalgorithme de plus faible
identifiant ou de plus fort degr de connectivit sur lensemble des nuds sans chef de groupe. Pour
vrifier, la connectivit entre un chef de groupe et les nuds qui lui sont rattachs, des paquets de
contrle sont changs priodiquement.

34
2.2.2 Rseaux backbone
Les rseaux dorsales sans fil (ou rseaux backbone) sont un dcoupage de la topologie du rseau en
un ensemble de groupes distincts [RUB-01]. Un rseau mobile de backbone est compos dun rseau
de backbone (Bnet), dun rseau daccs (Anet) et dun rseau ad hoc normal. Il est possible de voir
cette hirarchisation sur la figure 2-3.

Figure 2-3 : Topologie dun rseau de Backbone
Un rseau mobile backbone a pour particularit davoir deux types diffrents de nuds qui se
diffrencient en fonction de leurs caractristiques. Ainsi, les nuds grandes capacits servent la
formation du rseau backbone. Ils sont appels nuds de backbone (BN) sils forment la dorsale ou
nuds de backbone capable (BCN) sils sont ligibles pour la formation de la dorsale. Ces nuds ont
pour particularit davoir une capacit importante de fonctionnement, en offrant des ressources
processeur et des capacits mmoire importantes. De mme, ils possdent deux modules sans fil
fonctionnant sur des frquences diffrentes (lun faible puissance, et lautre puissance lev). Le
module faible puissance est utilis pour fonctionner avec les stations du rseau ad hoc (nommes RN)
alors que lautre module est employ pour la communication entre les nuds de la dorsale (les BNs).
Du fait que ces deux modules oprent sur des frquences diffrentes, ils ninterfreront pas entre eux.
La formation de la dorsale (Bnet) est ralise en slectionnant 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 slectionns deviennent par la suite des BNs et forment la dorsale. Le choix du BCN se fait
gnralement sur lensemble de ses caractristiques (grande capacit, puissance processeur leve,
autonomie importante). Un BCN qui nest pas associ avec un nud du rseau ad hoc (RN) diffuse
priodiquement son identifiant et ses caractristiques lensemble de ses voisins en utilisant son
module de transmission faible puissance. Un BCN est converti en BN, si ses caractristiques sont les
plus leves parmi les BCN non associs dans le voisinage. Les RNs se trouvant un saut sassocient
dornavant lui sils ne sont pas associs un autre BN. Les BNs sont interconnects entre eux par le
module forte puissance de transmission.

35
2.2.3 Protocoles de routage hirarchiques
Nous prsentons dans cette section quelques protocoles de routage hirarchique. Ces protocoles
diffrent dans la manire de hirarchiser le rseau et dans lchange des informations de contrle. Les
protocoles CGSR, HSR, CBRP, MMWN et LANMAR divisent le rseau en clusters (cf. 2.2.1). Les
protocoles OSR, PSR et NTDR divisent le rseau en backbone (cf. 2.2.2).
Le protocole Clusterhead Gateway Switch Routing (CGSR) [CHI 97-1] utilise une hirarchisation du
rseau en clusters pour router les paquets. Chaque nud est rattach une tte de cluster. Cette tte de
cluster contrle laffectation du mdium une station et lensemble des communications entre clusters
passe par lui. Chaque nud maintient deux tables, une table CM contenant pour chaque nud du
rseau la tte de cluster auquel il est rattach, et une table de routage contenant le prochain nud vers
chaque tte de cluster. La table CM est diffuse priodiquement par chaque nud. Le protocole de
routage DSDV est utilis pour calculer la table de routage vers chaque tte de cluster. Les paquets sont
routs alternativement entre les ttes de cluster et les passerelles. Ce protocole rduit la taille de la
table de routage diffuse car uniquement les entres en direction des ttes de cluster sont conserves.
Par contre, le surcot pour maintenir les clusters est important.
Le protocole Hierarchical State Routing (HSR) [PEI 99-1] est bas sur le protocole tat de lien. Le
rseau est divis en clusters avec une hirarchie multiple. Le premier niveau de la hirarchie
correspond la division en clusters prsente dans le paragraphe 2.2.1. Les autres niveaux de la
hirarchie sont forms des ttes de cluster des niveaux prcdents. Chaque niveau hirarchique est
dcoup en clusters. Lensemble des ttes de cluster dun niveau hirarchique lisent une tte de
cluster laquelle elles deviennent affilies. Le niveau hirarchique le plus lev est compos dune
seule tte de cluster. Une fois la hirarchie multiple compose, chaque nud du niveau physique
obtient une adresse hirarchique de la forme <sous-rseau, hte>. Le champ sous-rseau est compos
du chemin de la hirarchie la plus haute jusquau nud lui-mme. Par ce dcoupage en adresses
hirarchiques une route peut, aisment, tre trouve.
Le protocole Multimedia Mobile Wireless Networks (MMWN) [KAS 97-1] utilise une hirarchisation
du rseau en clusters pour connatre la localisation des nuds. Chaque cluster emploie un gestionnaire
de localisation (LM), qui gre la localisation pour chaque groupe auquel il est associ. Lavantage de
MMWN est que seulement les LMs changent les informations de localisation, donc le surcot
engendr par les informations de routage est rduit compar aux protocoles proactifs traditionnels
(DSDV, WRP). Cependant, la gestion de la localisation est fortement lie la hirarchisation du
rseau, 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 larbre
hirarchis des LMs.
Le protocole Cluster Based Routing (CBRP) [JIA 99-1] utilise une hirarchisation du rseau en
clusters pour rduire le nombre dinformations de routage changes. Une fois la hirarchisation du
rseau ralise, les ttes de cluster connaissent les nuds qui leur sont rattaches ainsi que les
passerelles pour joindre les clusters adjacents. Lorsquun nud a besoin de dterminer une route, elle
envoie une requte de cration de routes (RREQ) sa tte de cluster uniquement. A la rception de ce

36
paquet, elle le propage lensemble des ttes de cluster lentourant aprs avoir ajout son identifiant
dans lentte de la requte. Lorsque la tte de cluster dtecte que la destination est un de ses membres,
il envoie un paquet de rponse la source en inversant le chemin contenu dans le paquet RREQ. A la
rception dun paquet de rponse, les ttes de cluster ne peuvent faire partie de lensemble des
chemins qui traversent leur cluster. Dans un tel cas, ils deviendraient des goulets dtranglement. Par
consquent, ils essaient de faire passer le trafic en priorit par les nuds qui leurs sont affilis.
Les protocoles de routage Optimal Spine Routing (OSR) et Partial-knowledge Spine Routing (PSR)
[RAG 98-1] utilisent une hirarchisation particulire en backbone, appele Spine, pour dterminer et
maintenir les chemins. Une hirarchisation en Spine diffre de la hirarchisation habituelle en
backbone par le fait que seulement le trafic de contrle traverse le backbone. Le protocole OSR est
bas sur le protocole tat de liens. Chaque nud du Spine transmet la connaissance des nuds de
son cluster aux autres membres du Spine. Un chemin entre une source et une destination peut aisment
tre trouv par chaque nud du Spine une fois la topologie connue. Chaque source consultera son
nud de backbone pour connatre la route vers la destination. Le protocole PSR diffre du protocole
prcdent sur le fait que chaque nud du Spine a connaissance dune partie de la topologie. Cette
partie est compose des nuds qui sont stables sur le rseau, c'est--dire les nuds qui rompent trs
peu de liens avec leur voisinage. Cette connaissance partielle permet de diminuer la taille des
messages dtat de liens changs sur le Spine.
Le protocole LANdMark Ad hoc Routing (LANMAR) [PEI 00-1] sinspire fortement du principe du
protocole FSR. Seules les informations concernant la topologie dune zone proche (limite un certain
nombre de sauts) sont changes priodiquement avec les voisins. De mme, uniquement les chemins
pour joindre les nuds de cette zone proche sont conservs dans la table de routage. Ce principe rduit
la quantit dinformations changes entre les nuds et la taille de la table de routage facilitant un
passage lchelle. Les nuds sont diviss en groupe possdant des affinits fortes. Ainsi ces nuds
sont censs se dplacer le plus possible ensemble. Un chef de groupe est lu pour chaque groupe et
chaque nud dun groupe est identifi par une adresse de sous-rseau particulire. Priodiquement,
chaque nud transmet un vecteur de distance avec la distance le sparant de chaque chef de groupe.
Une fois ces informations diffuses, chaque nud peut dterminer le chemin pour atteindre les
diffrents chefs de groupe. Lorsquun paquet doit tre transmis sur le rseau, la source regarde si la
destination se trouve dans sa zone proche. Si cest le cas un chemin est donc connu. Si elle ne sy
trouve pas, le paquet est transmis vers le chef de groupe du sous-rseau auquel appartient la
destination. Au fur et mesure que le paquet sapproche de ce chef de groupe, les informations
connues sur les nuds du groupe augmentent. Le paquet peut un moment ne plus tre dirig vers le
groupe mais vers la destination elle-mme.
Le systme Near Term Digital Radio (NTDR) [RUP 97-1] cre une hirarchie en backbone du
rseau. Chaque nud affili un nud de backbone correspond une zone. Le protocole de routage
employ dans chaque zone est le protocole Open Shortest Path First (OSPF) gnralement utilis sur
internet pour permettre le routage lintrieur de systmes autonomes. Cest un protocole tat de
liens. Les informations sur les voisins dun nud sont changes priodiquement par ce dernier ou lors
dun changement de topologie. A la rception de ces informations, chaque nud les propage ses
voisins. Ainsi chaque nud a connaissance de la topologie. Les informations ne sortent pas du

37
systme autonome. Ainsi le nud de backbone fait le relais vers les autres systmes autonomes.
Lchange des informations de routage entre Anets se fait simplement. Chaque nud de backbone
gnre des tats de liens rcapitulatifs de sa propre zone et les transmet aux autres nuds de backbone.
Ainsi, chaque nud de backbone peut dterminer une route vers lensemble des nuds extrieurs
son propre systme autonome.
2.3 Protocoles utilisant des informations de localisation
Echanger des informations de contrle pour dterminer les routes consomme de la bande passante.
Cette ressource se faisant rare dans les rseaux ad hoc, le protocole de routage doit tout mettre en
uvre pour minimiser ces changes. Pour cela, une solution consiste rduire ces informations en
prcisant la direction vers laquelle se dirigent les informations de contrle. En fait, en connaissant la
position de la destination, les paquets qui vont loppos de la destination ou au-del de la position de
la destination, sont gnralement peu utiles. Dans ce cas, faire en sorte que ces paquets ne se
propagent pas dans de mauvaise direction et soient plus centrs vers la position de la destination
constitue le point cl des protocoles utilisant des informations de localisation.
Pour dterminer sa position chaque station embarque un rcepteur de positionnement, tel que le GPS
(Global Positioning System) [GPS] ou prochainement Galileo. Aujourdhui les quipements de
positionnement sont petits et extrmement lgers. En effet, un rcepteur GPS se compose dune puce
GPS et dune antenne. Le fonctionnement dun systme de positionnement est trs proche du principe
de triangulation. La constellation de satellites est conue de telle manire que chaque rcepteur voit
tout moment nimporte quel endroit du globe 4 satellites. Les rcepteurs dterminent la distance les
sparant de chaque satellite et peuvent former une sphre centre sur chacun de ces satellites.
Lintersection de ces sphres indique la position o se situe le rcepteur. La position du rcepteur ainsi
connue permet de dterminer ses coordonnes cartsiennes gocentriques (X, Y, Z) ou ses coordonnes
gographiques (latitude, longitude).
La source doit connatre la position de la destination pour orienter convenablement ses informations de
contrle. Pour cela, un systme 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 nud. Ainsi lorsquune source souhaite contacter une destination, elle va au pralable
consulter le serveur de location de la destination le plus proche pour obtenir cette information. Chaque
nud dtermine un ensemble de serveurs de localisation rpartis dans le rseau. Le rseau est divis
en sections carres qui sont dcoupes aux alentours dun nud, et deviennent de moins en moins
affines lorsquon sen loigne. Les serveurs de localisation sont rpartis dans ces zones. Plus on est
proche dun nud, plus le nombre de serveurs slectionns devient important. Plus on sen loigne,
plus le nombre de serveurs devient rare. Chaque nud met jour priodiquement sa position dans les
serveurs de localisation slectionns. La mise jour est plus soutenue dans les serveurs proches que
dans ceux loigns. En fait, elle est fonction du dplacement du nud. Sil ne se dplace que trs peu
il met jour uniquement les serveurs proches, sil se dplace beaucoup il met jour la totalit de ses

38
serveurs de localisation. Lorsquun nud ncessite de connatre la position dun nud destination, il
suffit de contacter les serveurs de localisation choisis par cette destination.
Dans un premier temps, nous prsentons deux protocoles gographiques LAR et DREAM. Nous
prsentons le protocole LAR puisquil sera employ comme protocole de comparaison dans la suite de
nos travaux. Le protocole DREAM diffre des protocoles de routage traditionnels par les informations
quil conserve dans se table de routage qui contient les informations de localisation et non le prochain
nud permettant de joindre la destination. Nous prsentons, par la suite, dautres protocoles de
routage GPSR, GRID, CAMA, GRA, GDSR qui sont souvent rfrencs dans la littrature.
2.3.1 Protocole LAR
Le protocole Location-Aided Routing (LAR) [KO 98-1] est bas sur un protocole ractif. Il propose
deux schmas pour rduire les informations de contrle. Pour cela, chaque schma va rduire lespace
de recherche en fonction de la connaissance de la position de la destination ainsi que dautres
paramtres comme sa vitesse et le temps de rafrachissement de linformation. Par rduction de
lespace de recherche, le nombre de nuds dans cet espace susceptible de transmettre un paquet de
contrle savre bien moins important que dans la totalit du rseau ad hoc. Par consquent, les deux
schmas du protocole LAR rduisent lespace de recherche, et seuls les nuds faisant partie de cet
espace peuvent transmettre les informations de contrle.
Lorsquun nud a besoin de dterminer une route vers la destination, il a besoin de connatre sa
position pour rduire lespace de recherche. Dans les deux schmas du protocole LAR, lorsque la
position de la destination nest pas connue, le protocole diffuse une requte de cration de route la
totalit du rseau. Une fois une route trouve, la destination insre dans sa requte de confirmation de
route sa position ainsi que des paramtres tels que la vitesse, le temps o la rponse est effectue, le
sens de dplacement Le protocole de routage LAR est pleinement utilis lorsquune liaison sur un
chemin est rompue. Connaissant un instant t
0
la position de la destination et sa vitesse, il peut
dterminer un instant t
1
la zone o elle se situe.
Schma 1 : partir de la dernire position de la destination (au temps t
0
) et de sa vitesse v, la source
dtermine une zone probable o doit se situer la destination. En effet, si la destination ne se dplace
que dans un sens, elle peut se trouver dans un cercle de rayon v(t
1
t
0
). La source dtermine partir de
sa position (X
s
, Y
s
) et du cercle o est susceptible de se trouver la destination une zone rectangulaire
qui fera office de zone de recherche dans laquelle sont dtermines 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 calcule par la source, elle ajoute dans sa requte de cration de route,
les coins du rectangle. Lorsquun nud reoit la requte, il peut dterminer partir de sa position sil
se trouve ou non dans cette zone. Sil sy trouve, il traite la requte et la diffuse ses voisins. Dans le
cas o elle est extrieure cette zone la requte est supprime rduisant ainsi le nombre
dinformations de contrle changes.

39
Schma 2 : La distance entre un nud et la destination est llment dterminant dans la propagation
dune requte. Un nud ne transmet la requte que si sa distance la destination est plus faible que la
distance la destination du nud qui lui a transmis la requte.
Lorsque la source veut envoyer un paquet un nud D et quelle ne connat pas une route vers D, elle
met une requte de dtermination de route en y insrant la position de la destination et sa distance
DIST
S
vis--vis de cette dernire. Quand un nud I reoit cette requte, il dtermine sil doit la traiter
et la retransmettre ou non. Pour cela, il dtermine sa propre distance la destination DIST
I
et vrifie si
elle est infrieure la distance du nud J qui a transmis le paquet avec la formule : DIST
J
+ DIST
I
.
Le paramtre permet dajuster lexpansion de la zone de recherche. En laugmentant, il peut ainsi
tre employ pour accrotre la chance de trouver une route.
Dans ces deux schmas, une route peut ne pas tre trouve. Cet chec peut tre d soit une zone de
recherche trop petite, soit parce que les paramtres sur lesquels la cration de la zone est base sont
errons ou tout simplement plus jour. Un tel chec se rvle des plus dommageables, car le but
premier dun protocole de routage est de trouver une route si elle existe. Pour pallier ce problme, la
source utilise un protocole ractif plus conventionnel tel que AODV ou DSR lors dun tel chec.
2.3.2 Protocole DREAM
Le protocole de routage Distance Routing Effect Algorithm for Mobility (DREAM) [BAS 98-1]
change la manire de concevoir les protocoles de routage. Les tables de routage ne contiennent pas le
prochain nud ou le chemin pour joindre une destination mais les informations de localisation de
chaque nud. Lorsquun nud veut transmettre un paquet de donnes, 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 lchange des informations de localisation entre les
nuds. Pour cela, il rduit ces informations suivant deux constats :
La distance : Deux nuds loigns ressentent moins leur dplacement respectif que deux
nuds proches. Par consquent, chaque nud a besoin de mettre jour sa localisation moins
souvent vis--vis des nuds loigns.
La mobilit : Tout nud qui se dplace doit mettre jour sa position. Cela doit tre fait
souvent dautant plus quil se dplace rapidement.
Chaque nud met priodiquement les informations de position le concernant (ses coordonnes, sa
vitesse). Pour rguler la distance de propagation de ses messages de contrle, chaque nud marque
le paquet par une certaine distance. Lorsquun nud le reoit, il calcule la distance que le paquet a
voyag. Si elle est plus grande que celle marque dans le paquet, il est supprim, sinon il est propag.
Ces paquets sont transmis dautant plus souvent que la distance marque est faible. La frquence
laquelle les nuds mettent les paquets de contrle est fonction de la vitesse de dplacement du nud
lui-mme. Plus il se dplace rapidement, plus il transmet souvent les informations sur sa position.

40
Lorsquun nud a besoin denvoyer un paquet un autre nud, il dtermine lensemble des voisins
permettant datteindre la destination avec une probabilit p. Il dclenche un temporisateur et met le
paquet. Lorsquun nud reoit un paquet, il vrifie sil en est le destinataire. Si tel est le cas, il regarde
si le paquet est un acquittement ou un paquet de donnes. Chaque nud destination acquitte un paquet
de donnes pour permettre la source de savoir quil est correctement arriv destination. Si le mme
paquet arrive plusieurs fois destination, elle acquitte chaque rception ce paquet pour rendre le
protocole plus robuste (en cas de perte dacquittement). Sil nest pas la destination et quil est dans la
direction de la destination, il propage ce paquet.
Chaque nud 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 paramtres de
mobilit et de position concernant la destination. Ces paramtres sont t
0
, le temps de mise jour de
linformation, la distance r le sparant de la destination, la vitesse de la destination v et langle entre
laxe des abscisses et la droite passant par lui et la destination . Le nud peut facilement en dduire
les voisins dont leurs positions se situent dans lespace reprsent par lintervalle [-, +]. est
dtermin par la formule suivante : = arcsin v(t
1
-t
0
)/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<p1. Pour
cela, il revient dterminer la probabilit telle que P(x(t
1
-t
0
)v) p.
Si la source ne reoit pas dacquittement dans un laps de temps dfini, le temporisateur dclench
lenvoi du paquet arrive expiration. Dans ce cas, elle retransmet le paquet. Cet acquittement et le fait
quun paquet de donnes prend plusieurs chemins ajoutent une surcharge au protocole DREAM.
2.3.3 Autres protocoles localisation
Dans cette section, nous prsentons diffrents protocoles gographiques qui diffrent dans la manire
dont ils routent les informations de routage et dont ils rduisent lespace de recherche. Les protocoles
GPSR et GRA sont particuliers puisquils nutilisent pas de table de routage pour transmettre les
paquets jusqu la destination. Les protocoles GRID et GDSR sont intressants dans la faon dont ils
rduisent lespace de recherche. Le protocole CAMA est assez particulier. Il utilise un ensemble de
techniques et leurs possibilits pour rduire le nombre dinformations de contrle changes.
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 calcules la vole donc aucune
table de routage nest maintenue. Seules les connaissances de la position des nuds voisins et de la
destination sont ncessaires. Par consquent, chaque nud change priodiquement sa position avec
ses voisins. Dans le premier mode, un nud recevant un paquet le propage au nud le plus proche de
la destination dans son voisinage. Lorsque ce mode ne peut tre employ (par exemple aucun nud
nest plus proche de la destination que soi-mme), le nud forme un graphe planaire de son voisinage.
Il emprunte ce graphe en restant le plus possible dans la direction de la destination. Un nud rutilise

41
le premier mode, lorsquil trouve un nud dont la distance la destination est plus petite que la
distance la destination du nud ayant chang initialement de mode.
Le protocole GRID [LIA 01-1] prend son nom dans la faon dont le rseau est dcoup (sous forme de
grille). Le rseau est divis en zones carres de taille gale. Dans chaque zone, un nud est lu comme
chef. Les informations de contrle pour la dtermination dune route sont propages uniquement par le
chef de chaque zone. Lorsquun nud veut crer une route, il diffuse une requte. Seuls les chefs de
zone sont susceptibles de la relayer. Ainsi, le nombre de messages de contrle est rduit au nombre de
chefs dans le rseau. Lorsque la destination reoit la requte, elle transmet une rponse en direction de
la source au chef lui ayant transmis la requte. Cette rponse contient en plus la position de la source
ainsi que sa vitesse de dplacement. Un chemin dont les nuds intermdiaires sont uniquement des
chefs de groupe est dtermin. GRID diffre normment 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 llection dun autre nud comme chef de zone, ce
dernier connat la table de routage de son prdcesseur et peut continuer le routage des paquets. Si
cest la source ou la destination qui rompent le chemin, la source rtablit un chemin en rduisant le
nombre de chefs de groupe visits en fonction de la dernire position connue de la destination.
Le protocole Cellular Aided Mobile Ad hoc (CAMA) [BHA 04-1] centralise lensemble des
informations sur un ou plusieurs serveurs distribus. Ces serveurs sont relis aux rseaux
tlphoniques sans fil (GSM, UMTS). Par consquent, chaque station embarque un
metteur/rcepteur ad hoc et un metteur/rcepteur cellulaire. Priodiquement, chaque station envoie
sa position un serveur CAMA de localisation en utilisant sa liaison cellulaire. Le serveur possde
ainsi lensemble des informations sur la topologie du rseau ad hoc et peut par consquent dterminer
les chemins vers les autres nuds. Lors de lmission dun paquet, si la source ne connat pas une
route vers la destination, elle consulte, grce 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 rseau pour
acheminer les paquets jusqu la destination. Chaque nud suppose connatre la position de ses
voisins et la position de la destination. Lorsquun nud veut transmettre un paquet, il le dirige vers le
nud voisin le plus proche de la destination. Tout nud recevant le paquet fait de mme jusqu ce
quil atteigne la destination. Un problme survient lorsquun nud est lui-mme le nud le plus
proche de la destination. Dans ce cas, il ne peut pas transfrer le paquet un nud voisin, et le paquet
natteindra jamais la destination. Dans ce cas, le protocole GRA utilise un protocole ractif
quelconque pour tablir une route entre ce nud et la destination.
Le protocole Global positionning Dynamic Source Routing (GDSR) [BOU 02-1] rduit lespace de
recherche emprunt par les requtes de cration de route pour en rduire le nombre. Il est bas sur le
protocole DSR et en modifie limpact en rduisant le nombre de nuds qui relayent les requtes.
Chaque nud doit connatre la position de ses voisins. La contrepartie de cette connaissance est
laccroissement des informations de contrle. Lorsquun nud reoit une requte, il calcule pour
chaque nud de son voisinage J, langle =
IXJ form entre le nud I lui ayant transmis la requte,

42
lui-mme X et J. Si pour au moins un voisin > (avec une valeur donne) alors le nud
retransmet la requte. Dans le cas o lensemble des voisins forme un angle infrieur ou gal , la
requte est supprime.
2.4 Discussion
De nombreux protocoles de routage meilleur effort ont t proposs ces dernires annes. Ces
protocoles peuvent tre classs suivant trois critres : la dissmination de linformation de routage
(cf. 2.1), la hirarchisation du rseau (cf. 2.2) et lutilisation dlments de localisation (cf. 2.3).
Le trafic rsiduel, engendr par les informations de routage, rduit la bande passante du rseau et peut
crer des collisions. Cette diminution de la bande passante du rseau restreint le nombre de flux
pouvant transiter sur le rseau ou la bande passante quils peuvent utiliser. De nombreuses mthodes
ont donc t apportes pour rduire limpact des informations de routage sur la bande passante du
rseau.
En fonction de la mthode de dissmination de linformation de routage, les protocoles de routage
utilisent des mthodes particulires pour limiter le nombre dinformations changes. Les protocoles
proactifs (cf. 2.1.1) essaient de rduire le nombre dinformations de routage changes sur le rseau
en utilisant loptimisation de relais multipoints comme le protocole OLSR, ou en jouant sur la
frquence des changes de la topologie locale comme le protocole FSR par exemple. Les protocoles
ractifs (cf. 2.1.2), quant eux, rduisent les informations ncessaires au routage en diminuant
limpact sur la bande passante de la perte dune route. Pour cela, les nuds maintiennent plusieurs
routes dans leur table de routage, comme AOMDV par exemple, ou privilgient les chemins les plus
stables, comme ABR par exemple. La rduction des informations de routage des protocoles proactifs
et ractifs bnficie, galement, aux protocoles hybrides (cf. 2.1.3) puisquils combinent ces deux
types de protocoles pour dterminer une route.
Les protocoles de routage peuvent utiliser une hirarchisation du rseau (cf. 2.2) pour rduire le
nombre dinformations de routage. Cette hirarchisation, utilise par les protocoles CBRP, OSR et
PSR, rduit le nombre de nuds concerns par ces informations. De mme, certains protocoles
hirarchiques, par exemple CGSR, rduisent la taille des tables de routage transmises par les nuds,
rduisant la bande passante consomme.
Les protocoles, utilisant des informations de localisation (cf. 2.3), sont galement un moyen de
rduire la bande passante consomme par la dcouverte des routes. Bien souvent, les protocoles de
localisation sont des protocoles ractifs et oprent donc par flux. Ces protocoles diminuent le nombre
dinformations de routage en connaissant la position de la destination. Ils peuvent ainsi rduire le
nombre de nuds du rseau transmettant les paquets de routage comme par exemple les protocoles
LAR et DREAM. Une rduction de lespace de recherche peut entraner lchec de dtection dune
route. Ainsi, il est toujours ncessaire de combiner cette mthode de recherche avec un autre protocole
de routage.

43
Les protocoles OLSR, AODV et DSR sont les seuls protocoles standardiss dans les rseaux
MANETs. De fait, ces protocoles sont les protocoles de routage implments en priorit dans les
quipements supportant les rseaux MANETs. Le contexte de nos travaux est lutilisation
dapplications multimdia ou temps-rel, fortement consommatrices en bande passante, dans un
environnement mobile ad hoc. Nous choisissons de baser nos travaux sur le protocole AODV puisquil
propose, en tant que protocole ractif, une gestion par flux. Ce protocole est donc bien adapt notre
contexte puisquil permet lobtention dune route pour chaque flux en fonction de leurs critres. Notre
choix aurait pu se porter sur le protocole ractif DSR. Oprant seulement sur les liens symtriques, le
protocole DSR a un lger surcot en bande passante (notamment avec lutilisation de deux fois la
phase de dcouverte des routes et lajout des nuds du chemin dans lentte de la requte) compar
AODV. Travaillant dans un tel environnement, nous basons nos travaux sur le protocole AODV.
Lensemble des protocoles, prsents dans ce chapitre, limite les informations de routage ncessaire
la dcouverte ou la maintenance dune route. Par contre, aucun nagit sur dautres facteurs
consommateurs en bande passante. De fait, aucun protocole de routage ne prend en compte les
collisions subies par le rseau. Les collisions entre paquets sont pnalisantes puisquelles diminuent la
bande passante utile du rseau et accroissent le dlai de bout en bout des paquets.
Dans le but doptimiser la bande passante des rseaux MANETs, nos travaux se portent, par la suite,
sur :
La rduction des collisions (cf. 4. Optimisation de la bande passante disponible) : les collisions
entranent retransmissions et dlais. Le protocole de routage doit limiter au maximum cet effet en
vitant les routes satures. Une route encombre ne peut accepter de nouveaux flux sans crer de
collisions.
Le routage gographique (cf. 5. Approches de Rduction de la charge due aux informations de
contrle) : les protocoles de routage gographique rduisent lespace de recherche pour diminuer le
nombre de nuds qui transmettent des informations de routage. En connaissant la position de la
destination, ils peuvent diriger ces paquets de routage directement vers la destination. Rduire
lespace de recherche peut entrainer un chec la dcouverte dune route mme si une existe. Les
protocoles de routage gographique combinent deux types de protocole pour pallier ce problme. Le
premier est utilis pour chercher une route en rduisant lespace de recherche, le second (qui diffuse
gnralement linformation de routage sur la totalit du rseau comme le protocole AODV) en cas
dchec du premier. Il est envisageable doprer plus en douceur, en utilisant un parcours en
profondeur dont lespace de recherche est agrandi lors dchecs successifs la dcouverte dune route.

45
3 Routage Qualit de Service
dans les rseaux MANETs
Avec la monte en puissance des systmes informatiques, les services offerts aux utilisateurs se sont
multiplis. Du simple traitement de texte dans les annes 1980, linformatique aujourdhui se veut
multimdia, communicante, omniprsente et mobile. Avec lavnement du multimdia, images, sons
et vidos sont maintenant indissociables. Et linternet ne fait quaccentuer cet tat de fait. Dautre part,
en parallle lapplication de linformatique dans les domaines multimdia, son incursion dans
dautres secteurs a t non moins importante. Ainsi, des systmes informatiques ont t implants dans
les systmes industriels pour la commande de processus, leur surveillance ou dautres fonctions encore.
Linformatique est aussi implante dans les systmes embarqus : aviation, automobile, secteur
maritime Certains secteurs plus sensibles encore car touchant la scurit humaine, ont aussi
intgr les outils informatiques comme par exemple dans la gestion de centrales nuclaires. Mais
disposer de systmes performants nimplique par forcment que les systmes offrent tous leurs
utilisateurs la qualit quils attendent. Cest ce paradigme que la qualit de service tend rpondre.
Avec lapparition de nouvelles technologies et de nouveaux moyens de communication, la mobilit
des terminaux na cess de crotre. Les utilisateurs veulent ainsi pouvoir se dfaire des rseaux filaires
tout en continuant utiliser les services et les applications auxquels ils taient habitus. Une telle
volution des besoins doit tre totalement transparente pour lutilisateur. Ce dernier ne doit pas ptir
des problmes inhrents aux rseaux sans fil. Les protocoles de routage meilleur effort, actuellement
en place dans les rseaux 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
imposes par les applications. Les protocoles de routage QoS ont ainsi fait leur apparition dans les
rseaux MANETs prenant en compte de nombreuses contraintes de QoS telles que le dlai, la bande
passante, la fiabilit, lconomie dnergie

46
Combiner mobilit et QoS nest tout de mme pas une mince affaire. La notion de qualit de service a
d tre modifie dans les rseaux sans fil compar celle des rseaux filaires. Dans les rseaux filaires,
les applications temps-rel et multimdia [STA 88-1], ncessitant une garantie des contraintes de QoS,
sont classes en deux domaines distincts :
Applications aux contraintes dures : les applications aux contraintes dures sont dfinies de la faon
suivante. Si une opration de lapplication rompt une contrainte impose, elle est considre
comme sans effet. Dans le pire des cas, le nom respect dune contrainte peut rendre le systme
instable voir inoprant (ex : capteur de temprature dans un racteur nuclaire, aide au freinage
dans une voiture, capteur de pression dans un avion, ).
Applications aux contraintes souples : Ces applications tolrent une certaine priode de temps
durant laquelle les contraintes de QoS ne sont pas honores. Cependant, la satisfaction de la QoS
est quantifie par le rapport entre le temps total dinterruption de la QoS et le temps total de
connexion. Ce rapport doit toujours tre au dessus dun seuil spcifi pour respecter les besoins de
QoS (ex : vidoconfrence, VoIP, vido la demande, ).
Dans les rseaux MANETs, il est extrmement difficile de prendre en compte des applications avec
des contraintes de QoS dures. Lenvironnement dynamique des rseaux MANETs rend ltat du rseau
instable [JAW 05-1], pouvant tout moment ne plus respecter les contraintes imposes durant un
certain laps de temps. La notion de garantie de QoS, dans les rseaux MANETs, a ainsi volu pour
offrir aux applications temps-rel et multimdia 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. Lutilisation
de la QoS adaptative fournit plus de flexibilit au systme et permet au rseau dadapter les ressources
alloues par les applications suivant les ressources disponibles dans le rseau.
Dans ce chapitre, nous donnons dans un premier temps la dfinition du routage QoS. Par la suite,
nous prsentons les caractristiques des mtriques de QoS et les modles destimation qui leur sont
associs. Une troisime partie met en avant la complexit rencontre par les algorithmes de routage
QoS alors que lutilit des fonctions poids est prsente dans une quatrime partie. Enfin, diffrents
protocoles de routage ainsi que leurs mthodes daccs au support sont prsentes. Ce chapitre se
conclut par une discussion sur limportance des protocoles de routage QoS.
3.1 Routage QoS
Pour fournir un service de qualit, lensemble de la pile de protocoles utilis par les quipements du
rseau 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
mme llment central du maintien de la QoS dans un rseau [MOH 03-1], [HAN 07-1], [RED 06-1].
Un rseau MANET tant multi-sauts, une route (si elle existe) doit tre trouve entre le nud source et
le nud destination. Cette route doit, de plus, garantir les contraintes de QoS imposes par
lapplication. Le protocole de routage QoS permet la dtermination dune telle route. Pour cela, le

47
protocole de routage dtermine une route en se basant sur les informations collectes par les nuds du
rseau.
Les informations collectes sont rattaches aux contraintes de QoS que le rseau doit respecter. Par
exemple, des informations sur le dlai entre nuds voisins seront collectes lorsquune application
dsire la garantie dun dlai de bout en bout.
Un rseau est modlis par un graphe G(V, E) o V reprsente lensemble des nuds du rseau et E
lensemble des arcs liant deux nuds entre eux. Dans un rseau MANET, chaque quipement mobile
reprsente un nud du rseau. Chaque liaison radio, entre deux nuds voisins, reprsente un arc.
Chaque arc <u, v> est muni dun poids not w(<u, v>) exprim laide dune ou plusieurs mtriques
de QoS. Le poids w(<u, v>) est un vecteur de n composantes (n est le nombre de mtriques de QoS) :
w(<u, v>) = [w
1
(<u, v>), w
2
(<u, v>), , w
n
(<u, v>)].

Figure 3-1 : Exemple de graphe associ un rseau
La figure 3-1 montre la reprsentation dun graphe associ un rseau. Les mtriques utilises sont le
dlai et la bande passante disponible. Les contraintes imposes par lapplication sont le dlai de bout
en bout (not
D
) et la bande passante requise (note
B
). Le protocole de routage doit dterminer une
route entre les nuds S et D garantissant ces deux contraintes. Sur ce rseau, lensemble des routes
entre S et D peuvent garantir le dlai mais une seule (la route S, A, B, D) peut garantir la bande
passante requise par lapplication.

48
Dans un rseau MANET, les nuds sont en perptuel mouvement. La topologie du graphe change
donc constamment, en fonction de larrive de nuds, de la rupture des liens, du dpart dautres
nuds Le poids des arcs volue galement et doit, par consquent, lui aussi tre mis jour. Pour
cela, des modles destimation peuvent tre employs. Ces modles fournissent une approximation du
poids des mtriques de QoS.
3.2 Mtriques de QoS
Les mtriques de routage [WAN 96-1] sont la reprsentation des liens d'un rseau, elles ont une
implication majeure non seulement sur la complexit des chemins trouver, mais galement sur la
porte des conditions de QoS qui peuvent tre supportes. Pour tre pleinement fonctionnelles, les
mtriques doivent tenir compte des facteurs suivants :
Pour lensemble des mtriques slectionnes, des algorithmes performants doivent tre mis en
place lors de la recherche dune route. La complexit de ces algorithmes doit tre comparable celle
des algorithmes de routage utiliss communment.
Les mtriques doivent reflter les caractristiques basiques du rseau. Les informations, quelles
apportent, doivent si possible supporter les besoins basiques en QoS. Les services, fournis par le
rseau, sont fonction des mtriques supportes par le rseau. Donc, les mtriques dterminent la
qualit de service apporte par le rseau. Par exemple, si les mtriques dun rseau sont la bande
passante disponible et le cot, la qualit de service est sujette ces deux mtriques.
Les mtriques doivent tre orthogonales entre elles. Chaque mtrique doit tre dcorrle des autres
afin dviter les informations redondantes. Les informations redondantes introduisent des
interdpendances entre les mtriques diminuant lefficacit des algorithmes de routage.

Pour se reprsenter la qualit dun chemin, lalgorithme de routage calcule le poids de la mtrique du
chemin chaque fois quun lien lui est ajout. La faon de calculer ce poids diffre suivant la mtrique
qui est employe. Soit w
i
(<v
i
, v
j
>) le poids de la i
me
mtrique sur le lien <v
i
, v
j
> et
P=v
1
, v
2
, , v
n-1
, v
n
. Ainsi, les mtriques sont divises en trois grandes classes : Additive,
Multiplicative, Concave.
Une mtrique est additive si : w
i
(P) = w
i
(<v
1
, v
2
>)+ w
i
(<v
2
, v
3
>)+ + w
i
(<v
n-1
, v
n
>).
Exemple de mtriques additives : dlai, cot, nombre de sauts.

Une mtrique est multiplicative si : w
i
(P) = w
i
(<v
1
, v
2
>) w
i
(<v
2
, v
3
>) w
i
(<v
n-1
, v
n
>).
Exemple de mtriques multiplicatives : fiabilit, disponibilit.

49
Une mtrique est concave si : w
i
(P) = min{w
i
(<v
1
, v
2
>), w
i
(<v
2
, v
3
>), , w
i
(<v
n-1
, v
n
>)}.
Exemple de mtriques concaves : bande passante.
3.2.1 Modles destimation
Les protocoles de routage QoS ont besoin dinformations sur les liens dun rseau pour slectionner
le chemin correspondant le mieux aux critres imposs par une application. Ces informations sont
obtenues laide de mesures et destimations. Les modles destimations de mtriques de QoS jouent
un rle important dans la dtermination des chemins. En effet, plus le modle est proche de la ralit,
plus justes sont les dcisions de routage. De par les variations dans le temps dun rseau ad hoc, un
modle reprsentant, avec justesse, ltat dun rseau MANET nexiste pas.
Les modles destimations se distinguent, entre eux, suivant le type de mthode utilise pour collecter
les informations qui les entourent. Pour dterminer une mtrique donne, un modle destimation peut
changer ou non des donnes avec lenvironnement qui lentoure. Dans le cas o des donnes sont
changes, le modle destimation est dit intrusif. Lutilisation dun modle de ce type accrot la
charge dun rseau MANET, mais fournit bien souvent des rsultats plus justes. Un modle
destimation ninteragissant pas avec les autres nuds du rseau MANET est dit non-intrusif. Un
nud dun rseau MANET, employant ce type de modle, dtermine ltat du rseau uniquement avec
les informations quil peut collecter partir de son propre tat et de lenvironnement qui lentoure.
Les modles destimation peuvent dterminer ltat de nombreuses mtriques, telles que la bande
passante disponible, le dlai, le taux derreur, lnergie dpense Les applications multimdia et
temps-rel tant principalement sensibles aux contraintes de bande passante et de dlai de bout en bout,
nous nous intressons par la suite uniquement aux modles estimant ces deux mtriques.
3.2.2 Estimation de bande passante disponible
De nombreuses solutions ont t proposes pour dterminer la bande passante disponible en fonction
de la mthode daccs au support utilises. Des modles destimations ont t notamment proposs
pour des mthodes daccs sans contention, telles que TDMA [DU 04-1] ou CDMA-o-TDMA
[CHE 04-1], [CHE 97-1] et [LIN 99-1], et des mthodes daccs avec contention, telles que
CSMA/CA [CAN 99-1], [KAZ 02-1], [LEE 06-1], [CHE 06-1] et [MEL 00-1]. Des modles prenant
aussi en compte les interfrences entre nuds ont t proposs [CHE 05-1] et [YAN 05-1]. Ces
modles tiennent comptent non seulement du trafic des nuds dans le voisinage immdiat, mais
galement du trafic des nuds hors voisinage immdiat c'est--dire les nuds se situant dans la zone
dcoute (carrier-sense range).
Nous dtaillons dans cette partie seulement deux modles destimation de bande passante disponible.
Le premier modle est celui propos par Kazantsidis et Gerla [KAZ 02-1] alors que le deuxime
modle est celui propos par Lee et al. [LEE 06-1].

50
3.2.2.1 Mthode de Kazantsidis et Gerla
Cette mthode est base sur la mthode daccs au support de communication DCF dIEEE 802.11. Il
fournit la couche rseau un ensemble de mesures issues de la couche MAC et LLC. La bande
passante disponible, not BD
i, j
, entre deux nuds voisins i et j est donne par la fonction suivante :
BD
i ,j
= (1 u)*B
i, ,j
(3-1)
avec u lutilisation de la file dattente dans la couche de liaison de donnes et B
i, ,j
la bande passante
du lien <i, j>.
Pour dterminer la bande passante disponible sur un lien, il est dabord ncessaire destimer la bande
passante du lien. Chaque nud estime, passivement, la bande passante avec ses voisins. La bande
passante consomme par un paquet, de taille S bits, est calcule avec :
=
+ + + +
=
R
r
r
Tb R Tov Tca Ts Tq
S
BP
1
* ) (
(3-2)
avec Tq le temps dattente en file dattente, Ts le temps de transmission du paquet, Tca la phase
dvitement de collision, Tov le temps ajout par le surcot (ex. RTS/CTS, ACK, entte et dlai de
propagation), R le nombre de retransmissions et Tb
r
le temps de backoff pour la r
me
retransmission.
La bande passante consomme par un paquet dpend de la taille de paquet, du dlai pass en file
dattente, de la valeur du backoff et du nombre de retransmissions. Pour obtenir une valeur
reprsentative de la bande passante sur un lien, une fentre de 32 paquets est utilise. La bande
passante dun lien est donne par la formule suivante :
B
i, ,j
= Moyenne(BP
k
, k = 1, , 32)
Daprs lquation (3-1), reste dterminer le temps dutilisation de la file dattente de la couche
liaison de donnes. Ce temps est obtenu partir du temps o la file dattente est vide, not TempsVide,
durant la fentre de transmission des 32 paquets, not TempsFentre. Lestimation de lutilisation de la
file dattente de la sous-couche LLC est calcule par :
re TempsFent
TempsVide
u =1 (3-3)
A partir des formules (3-1) et (3-3), la bande passante disponible sur le lien <i, j> est :
j i j i
B
re TempsFent
TempsVide
BD
, ,
= (3-4)

51
3.2.2.2 Mthode de Lee et al.
Lee et al. [LEE 06-1] proposent une mthode passive destimation de la bande passante disponible. La
bande passante disponible est estime en fonction du temps libre sur le support sans fil. La bande
passante disponible, note DB, est calcule 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 nuds dfinissent localement le temps durant
lequel le support est occup. Pour un nud i, le support est considr occup sil se trouve dans un des
trois tats suivants :
Emission : le nud i met un paquet lun de ses voisins
Rception : le nud i reoit un paquet de ses voisins
Support rserv : un nud voisin a dclar le support rserv en positionnant le vecteur
dallocation du rseau (NAV) au temps de la transmission du paquet et de la rception de son
acquittement.
Par consquent, le temps doccupation dun lien l (not T
l
) un nud i est : T
l
= TE
i
+ TR
i
+ TV
i
avec
TE
i
la somme des temps dmission du nud i ses voisins, TR
i
la somme des temps o le nud i
reoit un paquet et TV
i
la somme des temps durant lesquels un nud voisin a rserv le support. A
partir du temps doccupation, le taux durant lequel le support est libre peut tre facilement calcul :
TempsTotal
T
TauxLibre
l
=1
avec TempsTotal la priode de temps durant laquelle le support est monitor.
3.2.3 Estimation de dlai
Les applications multimdia ncessitent trs souvent le respect dun dlai born de bout en bout.
Lestimation du dlai, entre nuds voisins ou de bout en bout dun chemin, est dans ce cas
indispensable.
De nombreuses solutions ont t apportes pour estimer le dlai. Des modles estiment le dlai de bout
en bout tels que [CHE 99-1] ou [XUE 03-1]. Dautres modles [BAD 03-1], [MUN 02-1],
[ROM 05-1], [VER 00-1] et [BAR 01-1] estiment le dlai dun lien. Des modles probabilistes de
dlai de lien ont aussi t dvelopps [SHE 01-1], [MER 05-1], [OZD 04-1] et [TIC 04-1]. Ces
modles probabilistes sont souvent lis au fonctionnement de CSMA/CA, et tiennent compte des flux
qui traversent un nud ou ses voisins. Ces modles analytiques utilisent une distribution des flux

52
particulire (gnralement larrive des paquets suit la loi de Poisson) et une file dattente particulire
(M/G/1/K, G/G/1) afin destimer le temps de service dun paquet dans la file dattente de lmetteur.
Dans cette partie, nous prsentons deux modles, un modle destimation du dlai dun lien par sonde
[BAD 03-1], [MUN 02-1] et le modle destimation de bout en bout de Chen [CHE 99-1].
3.2.3.1 Modle destimation de dlai sonde
Dans [BAD 03-1], [MUN 02-1], les auteurs prsentent un modle simpliste et facile mettre en
uvre. Ce modle estime le dlai dun lien en calculant la diffrence de temps scoulant entre la
cration dun paquet Hello et la rception de ce dernier par le destinataire. Lmission dun tel paquet
Hello ne doit pas tre prioritaire sur les paquets de donnes. Le fait de rester en file dattente permet de
tenir compte du temps pass en file dattente par un paquet de donnes et de ne pas se limiter au temps
de transmission et de propagation du paquet.
Comme pour lensemble des modles simplistes, ceux-ci possdent des dfauts. Les nuds doivent
tre synchroniss entre eux. Comme le dlai est calcul en faisant la diffrence entre le temps de
rception du paquet et son temps de cration, les nuds voisins doivent avoir des horloges
synchronises pour ne pas fausser lestimation du dlai. De plus les paquets Hello tant diffuss, les
collisions ne sont pas prises en compte. Le dlai estim reste, sensiblement, constant quelque soit la
charge la rception.
3.2.3.2 Modle destimation de dlai de bout en bout de Chen
Chen et al. ont propos un modle destimation du dlai de bout en bout pour le protocole TBP
(Ticket-Based Probing QoS routing protocol) [CHE 99-1]. Les nuds ne conservent pas le dlai
estim pour atteindre un nud distant, mais la variation du dlai. Pour un chemin P, cette variation est
calcule partir de la formule suivante :
( )
Ancien
P
Nouveau
P
Ancien
P
Nouveau
P
D D D D + = 1 (3-5)
o
Nouveau
P
D (respectivement
Ancien
P
D ) dsigne la nouvelle (respectivement lancienne) valeur
estime de la variation du dlai du chemin P. Les paramtres ( < 1) et ( > 1) sont ajustables.
Connatre la variation du dlai permet la slection des chemins les plus stables, c'est--dire les chemins
les plus aptes fournir la QoS demande.
3.3 Complexit des algorithmes
Les protocoles de routage une mtrique, telle que le nombre de sauts par exemple, sont bien connus
et sont largement utiliss dans les rseaux MANETs (cf. 2). La plupart de ces protocoles dterminent
la route optimale (possdant le plus faible nombre de sauts par exemple) en un temps raisonnable et
avec un nombre de messages changs contrls. En effet, tout type de problme de routage, une

53
seule mtrique, possde une complexit polynomiale. Ce type de problmes peut tre rsolu en
utilisant lalgorithme de Dijkstra ou de Bellman-Ford.
Gnralement, les protocoles de routage QoS doivent eux tenir compte de plusieurs mtriques. Le
problme est donc tout autre. Les problmes de routage QoS peuvent tre multiples :
respect de contraintes de QoS multiples : les algorithmes de routage QoS rsolvent, dans un tel
cas, le problme MCP ( Multi-Constraint Path) [KO 98-1], [MAS 06-1]. Dans un tel problme,
chaque lien du rseau, not <u, v>, est caractris par un poids
w(<u, v>) = [w
1
(<u, v>), w
2
(<u, v>), , w
m
(<u, v>)] qui est un vecteur de m composantes (m tant
le nombre de mtriques de QoS). La rsolution dun tel problme consiste trouver un chemin P
qui satisfait lquation suivante pour toutes les contraintes C
i
exprimes sur les m mtrique de QoS :
( ) ( ) m i C v u w P w
i
P v u
i i
, , 1 , ,
,
K p = > < =

> <
(3-6)
o p est quivalent pour une mtrique additive ou multiplicative et pour une mtrique
concave.
optimisation de multiples contraintes : les algorithmes de routage QoS doivent, dans ce cas,
trouver un chemin optimisant la totalit des mtriques de QoS. Lalgorithme de routage doit par
consquent retourner un chemin P respectant la proprit suivante :
( ) { } ( ) ( ) ( ) ( )

> < > <
> < = > < =
' , ,
, ' , , , , 1 , '
P x w
i i
P v u
i i
x w w P w v u w P w m i P d s P P p K (3-7)
o P(s, d) reprsente lensemble des chemins entre s et d.
respect de multiples contraintes et optimisation dun autre critre : ce problme de routage QoS
est appel MCOP (Multi-Constraint Optimal Path). Le chemin trouv doit respecter lensemble des
m contraintes de QoS et optimiser un critre m+1. Notons P(s, d) lensemble des chemins entre les
nuds s et d respectant lquation (3-6). Le chemin P P(s, d) doit respecter la proprit suivante :
( ) { } ( ) ( ) ' , , ' '
1 1
P w P w P d s P P
m m + +
p (3-8)

La complexit des algorithmes de routage QoS est un critre fondamental. Lorsque le problme est
NP-complet, le temps de rsolution ou le nombre de messages changs par lalgorithme crot
exponentiellement avec laugmentation du nombre de nuds prsents dans le rseau. Un algorithme
de routage QoS peut facilement devenir inefficace, surtout si la topologie change frquemment
comme dans les rseaux MANETs.
Il a t prouv dans [WAN 96-2] que le problme MCP est NP-complet lorsque les contraintes sont
additives, multiplicatives ou un ensemble des deux. Des mthodes approximatives sont dans ce cas
employes pour diminuer la complexit. Une mthode de filtrage peut tre utilise fonctionnant de la
manire suivante. Lorsque plusieurs chemins sont obtenus entre deux nuds s et d satisfaisant une

54
premire mtrique (telle que la bande passante par exemple), un sous-ensemble de ces chemins est
limin en optimisant une seconde mtrique et ainsi de suite jusqu avoir filtr pour lensemble des
mtriques de QoS. Lutilisation dune fonction poids combinant un ensemble de mtrique de QoS peut
aussi tre utilise pour rduire la complexit des problmes de routage QoS. Une telle mthode
permet dans bien des cas de sapprocher de la solution optimale, rendant ce type dalgorithme
particulirement efficace. Lutilisation dune fonction poids combinant plusieurs mtriques est donc,
dans de nombreux cas, la solution la plus approprie.
3.4 Fonction poids
Lutilisation dune fonction poids, pour la recherche dun chemin, ne permet pas de trouver un chemin
optimal, mais permet de sen rapprocher. Dans le cas de problmes NP-complets, il est ncessaire de
trouver un compromis entre efficacit et rapidit ou nombre de messages changs. Une fonction
poids permet de mixer plusieurs mtriques, pour donner seulement une combinaison de lensemble. En
utilisant une telle fonction poids, le problme devient polynomial. En effet, il est possible dappliquer
lalgorithme de Dijkstra ou Bellman-Ford [COR 90-1] sur une telle combinaison.
Les fonctions poids peuvent tre classifies en deux types : les fonctions poids linaires et les
fonctions poids non linaires. Une fonction poids est dite linaire, pour un graphe G(V, E), si elle
respecte la condition suivante : P
1
= <s, v
1
, , v
n
, d> P
2
= <s, u
1
, , u
m
, d> | w(P
1
) w(P
2
)
<d, t>E, w(P
1
|| <d, t>) w(P
2
|| <d, t>) o || est la concatnation dun lien un chemin. Une
fonction poids est non linaire si elle ne respecte pas la condition prcdente.
Dans bien des cas, une fonction poids linaire ne permet pas de sapprocher suffisamment de la
solution optimale. Par contre, elle est trs simple mettre en place. La fonction poids linaire la plus
facile exploiter est une fonction poids de type w(P) = C(P) + D(P) o et sont paramtrables
et C(P) (respectivement D(P)) reprsente le cot du chemin (respectivement le dlai du chemin).
Les fonctions poids non linaires combinent galement plusieurs mtriques. Ce type de fonction
apporte bien souvent plus de possibilits pour sapprocher des besoins dsirs. Ainsi, il est possible en
utilisant ce type de fonction de pnaliser exponentiellement une mtrique alors quune autre varie
linairement le long du chemin. Un exemple de fonction poids non linaire est le suivant :
( )
( )
( ) ( ) P L P D
P B
P w
=
. Lalgorithme, qui utilise cette fonction poids, trouve un chemin dont la qualit est
un compromis entre bande passante disponible B(P) leve, un dlai D(P) et un taux de perte L(P)
faibles.
Lutilisation dune fonction poids dpend du contexte dans lequel elle doit oprer. Elle est llment
dterminant dans la slection dun chemin. Quelque soit le type de fonction poids utilise, elle doit
sapprocher au mieux du chemin optimal, pour tre pleinement efficace. Pour cela, elle doit tre
labore avec minutie pour sadapter pleinement aux besoins dsirs.

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 rserver ou non la bande
passante dsire. Les mcanismes de rservation de bande passante allouent une quantit de bande
passante sur un chemin. Ces mcanismes sont troitement lis la mthode daccs au support utilise.
Lorsque la mthode daccs au support est sans contention telle que TDMA [LIN 99-1], CDMA-o-
TDMA [LIN 99-2], le mcanisme de rservation [JAW 04-2], [JAW 05-2] assure la bande passante
dsire et borne facilement le dlai de bout en bout, car le support est exempt de collisions. Avec une
mthode daccs avec contentions telle que DCF (cf. 1.3.4.1), le trafic qui traverse le rseau est plus
ou moins quantifiable du fait de la rservation de ressources [YAN 05-1], [CHE 05-1]. Une
quantification prcise du trafic reste tout de mme difficile estimer cause de la prsence de
collisions. Lutilisation dun mcanisme de contrle dadmission de flux permet destimer limpact de
la prsence dun nouveau flux dans lenvironnement dun nud. Dans un tel environnement, le dlai
de bout en bout est plus difficile estimer. La rservation de bande passante, quelque soit la mthode
daccs au support utilise, permet lacheminement des paquets en respectant, dans un certain seuil, la
bande passante dsire par lapplication le temps de la dure de vie du chemin.
La nature instable des rseaux ad hoc (mobilit, fluctuations de la capacit des liens) empche
parfois la rservation de bande passante de rpondre aux besoins de QoS. Des protocoles de routage
[KAZ 02-1], [MUN 02-1] optent pour une approche optimiste de la QoS sans aucune rservation.
Chaque nud effectue des mesures et ralise des estimations sur des mtriques telles que la bande
passante et le dlai. Tant que le chemin slectionn respecte les contraintes de QoS, les paquets
transitent sur ce chemin. Si pendant un intervalle de temps les contraintes de QoS ne sont plus
respectes, le nud source se charge de trouver un autre chemin.
Pour fournir la QoS dsire, les protocoles de routage peuvent tre dpendants ou indpendants de la
mthode daccs au support sous-jacente. Pour offrir la QoS demande, un protocole de routage
dpendant de la mthode daccs au support est indissociable de cette dernire. De fait, ce type de
protocole est intimement li la couche MAC. Un protocole de routage indpendant de la mthode
daccs offre plus de souplesse que les protocoles dpendant. Ils peuvent tre adapts sur nimporte
quelle mthode daccs utilise. Par contre, ces protocoles supposent lutilisation dun mcanisme de
rservation de ressource sil est ncessaire (puisque le mcanisme de rservation de ressource est li
la mthode daccs).
Nous prsentons un ensemble de protocoles de routage QoS class suivant la dpendance du
protocole la mthode daccs du support. Les diffrents protocoles prsents garantissent
uniquement la bande passante, uniquement le dlai, ou la bande passante et le dlai.

56
3.5.1 Protocoles de routage QoS indpendants de la mthode
daccs au support
Nous prsentons 12 protocoles de routage QoS garantissant les contraintes de bande passante et/ou
de dlai. Ces protocoles sont indpendants de la mthode daccs au support sous-jacente. Le
tableau 3-1 rsume ces diffrents protocoles en fonction des mtriques de QoS supportes, sils
utilisent ou non un mcanisme de rservation de ressource et sils proposent des modles destimations
des mtriques de QoS.
Protocole Type Mtrique de QoS Rservation
de ressource
Modles
destimation de
mtriques de
QoS
AAQR Ractif Garantie dlai,
optimisation stabilit
Oui Non
ADQR Ractif Garantie Bande passante,
optimisation stabilit
Oui Non
BWR Hybride et
gographique
Garantie bande passante
et optimisation nombre
de sauts
Oui Non
DLR Hybride et
gographique
Garantie dlai et
optimisation nombre de
sauts
Oui Non
DSARP Ractif Garantie dlai, rduit
gigue
Non Non
GAMAN Ractif Garantie dlai,
optimisation taux de
perte des paquets
Oui Non
ODCR Gographique
/ Hybride
Garantie du dlai,
optimisation nombre de
sauts
Oui Non
QOLSR Proactif Garantie du dlai ou de la
bande passante
Non Non
QoS-AODV Ractif Garantie du dlai et/ou de Oui Non

57
la bande passante
QoS-ASR Ractif Garantie Bande passante
et dlai, amlioration
stabilit, occupation des
files dattente
Oui Non
QRMP Ractif Garantie Bande passante
et dlai avec optimisation
de la stabilit des routes
Oui Non
TBP Ractif Garantie Bande passante
et/ou dlai, optimisation
du cot
Oui/non Oui
Tableau 3-1 : Protocoles de routage QoS, indpendants de la mthode daccs au support,
garantissant la bande passante et/ou le dlai
Dans [WAN 05-1], le protocole ractif AAQR est propos utilisant le protocole RTP (Real-time
Transport Protocol) pour garantir les contraintes de dlai dun flux. Lors de la phase de dcouverte des
routes, la destination choisit la route la plus stable parmi lensemble des routes possibles (cest--dire
parmi les routes garantissant le dlai). La stabilit dune route est calcule en fonction de la variance
du dlai rencontr par un paquet sur un lien du chemin. Plus cette variance est faible, plus les nuds
composant un lien bougent peu.
Le protocole ADQR [HWA 03-1] propose un protocole ractif retournant de multiples chemins
disjoints lors dune recherche de route. La source slectionne lensemble le plus stable parmi les
chemins dont la bande passante cumule respecte la contrainte de bande passante. La stabilit des liens
dun chemin est calcule en fonction de la puissance des signaux reus.
Le protocole BWR [ZHA 04-1] est un protocole de routage hybride QoS utilisant des informations
gographiques permettant la rduction des informations de routage changes lors de la recherche
dune route. Le protocole utilise deux protocoles distincts, le premier est un protocole de routage
proactif permettant dacqurir la route possdant le plus faible nombre de sauts vers nimporte quel
nud du rseau. De mme, ce protocole permet de rcuprer les informations de localisation de
chaque nud du rseau. Lorsquun flux ncessite dtablir une connexion demandant une certaine
bande passante, un protocole ractif prend le relai dterminant une route garantissant la bande passante.
Si plusieurs routes permettent une telle garantie, la source choisit celle possdant le plus faible nombre
de sauts.
Le protocole DLR [ZHA 04-1] est un protocole hybride QoS. Il utilise un protocole proactif pour
dterminer tout instant les chemins vers lensemble des nuds du rseau. Le chemin retourn, pour
un nud, est le chemin possdant le plus faible nombre de sauts. Lorsquun flux ncessite un chemin
respectant un certain dlai, le protocole compare la borne du dlai celle du chemin possdant le plus
faible nombre de sauts. Si cette borne est suprieure un chemin optimal est trouv. Dans le cas

58
contraire, un protocole ractif est mis en uvre pour trouver un chemin dont le dlai respecte la
contrainte impose. La dissmination des informations de routage par ce protocole ractif est restreinte
une certaine zone gographique. Seuls les nuds dans cette zone transmettent les informations de
routage.
Le protocole DSARP [SHE 03-1] diffrencie deux types de trafic, le trafic meilleur effort et le trafic
temps-rel. Un mcanisme de contrle dadmission est utilis pour garantir que le trafic meilleur effort
ne perturbe pas le trafic temps-rel. Lorsque le trafic na aucune contrainte de temps, le protocole DSR
est utilis pour dterminer les routes. Par contre lorsque des contraintes de dlai sont imposes par
lapplication, un algorithme diffrent est appliqu. Lors de la phase de construction des routes, la
destination envoie un paquet de rponse, RREP, chaque requte reue. Les nuds recevant un
paquet RREP ajoute dans lentte le nombre de paquets en attente de transmission. Le nud source,
la rception de multiples rponses, slectionne plusieurs chemins et rpartit la charge du flux (en
fonction du nombre de paquets en attente de transmission sur chaque chemin choisi) sur le rseau.
Le protocole GAMAN [BAR 03-1] dtermine une route partir dune vue du rseau. La construction
dune route est ralise sur demande. Le protocole utilise un algorithme gntique pour trouver les
chemins. Cet algorithme privilgie les chemins en fonction dun taux darrive lev de paquets et un
dlai faible. Lalgorithme gntique suit un cycle compos des oprations suivantes : dtermination
dune population, valuation des performances, slection des individus et lapplication doprations
gntiques. Un tel algorithme converge rapidement vers une route optimale dans un environnement
peu peupl mais devient peu efficace dans de larges rseaux.
Le protocole ODCR [ZHA 05-1] propose un protocole de routage hybride et gographique. Chaque
nud met priodiquement, ses voisins, un vecteur contenant lensemble des nuds avec lequel il
possde un chemin ainsi que la distance les sparant. Chaque nud peut ainsi dterminer la route
possdant le plus faible nombre de sauts vers lensemble des nuds du rseau. Lorsquun flux
ncessite une route garantissant un certain dlai, il vrifie dans un premier temps si la route pour
joindre la destination respecte la contrainte de dlai. Si tel est le cas, la route possdant le plus faible
nombre de sauts correspond. Sinon, la source diffuse dans le rseau une requte de cration de route.
Seuls les nuds prsents dans une certaine zone de recherche comprenant la source et la destination
peuvent transmettre une telle requte limitant de ce fait la surcharge engendre par les informations de
routage. La destination slectionne la route avec le cot le plus faible parmi les routes trouves
garantissant le dlai.
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 dlai. Un mcanisme dadmission de contrle
est utilis pour viter quun nouveau flux dgrade la QoS des flux dj prsents. Le mcanisme de
contrle dadmission analyse la bande passante disponible pour permettre la slection dun MPR par
un nouveau nud.
Le protocole QoS-AODV [PER 00-1] est un protocole ractif bas sur le protocole AODV. Ce
protocole permet la garantie du dlai et/ou de la bande passante. Un nud intermdiaire relaie une
requte RREQ si la bande passante disponible est suprieure celle des chemins pralablement reus

59
ou si le dlai est infrieur celui des chemins pralablement reu. Si le dlai ou la bande passante du
chemin ne respecte par une de ces contraintes la requte RREQ est supprime.
Le protocole QoS-ASR [LAB 02-1] est un protocole ractif QoS. Lors de la slection des chemins,
un nud retransmet une requte de routage seulement si la bande passante disponible est suffisante
pour accepter le flux, et le dlai est infrieur la borne impose. Si ces contraintes sont respectes une
fonction poids est utilise pour dterminer la qualit du chemin. Si la qualit du chemin est infrieur
un certain seuil, la requte est transmise son voisinage. Cette fonction poids tient compte de
nombreux paramtres, comme le taux dutilisation des files dattentes, la stabilit de lien, la bande
passante disponible et le dlai de transmission.
Le protocole QRMP [WAN 01-1] est un protocole de routage QoS ractif. Ce protocole garantit la
bande passante et le dlai dun chemin. Chaque nud, la rception dune requte, ajoute des
informations concernant sa mobilit (vitesse, sens de dplacement). A la rception des diffrents
paquets de routage, la destination dtermine la route la plus stable. La stabilit dune route est
dtermine par le temps durant lequel cette route reste valide. Ce temps reprsente le temps minimal
de connectivit sur un lien du chemin.
Le protocole TBP [CHE 99-1] est un protocole de routage ractif. Il permet de garantir le dlai ou la
bande passante en optimisant le cot du chemin. Lorsquun nud source dsire 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 cot et les jaunes pour dterminer le
chemin avec le plus faible dlai ou la plus grande bande passante disponible. A la rception dune
sonde, un nud intermdiaire dcide, en fonction de son tat, si la sonde doit tre divise en fonction
du nombre de tickets et vers quels voisins, les nouvelles sondes doivent tre propages.
3.5.2 Protocoles de routage QoS dpendants de la mthode daccs
au support
Nous prsentons 15 protocoles de routage QoS garantissant les contraintes de bande passante et/ou
de dlai. Ces protocoles sont dpendants de la mthode sous-jacente daccs au support. Le
tableau 3-2 rsume ces diffrents protocoles en fonction des mtriques de QoS supportes, le type de
mthode daccs au support utilis, sils utilisent ou non un mcanisme de rservation de ressource,
sils proposent des modles destimations des mtriques de QoS et sils prennent en compte les
interfrences deux sauts.
Le critre des interfrences deux sauts ne concernent seulement les protocoles dpendant dune
mthode daccs au support avec contention. En effet, un nud dtecte que le support est occup si la
force du signal est suprieure un seuil, nomm Carrier-Sense Threshold. Ce seuil a une sensibilit
plus importante que la puissance requise pour la comprhension dune trame. Un tel seuil est
positionn de telle manire quun nud dtecte que le support est occup lors de la transmission dune
trame par un nud situ deux sauts. De fait, un nud voit sa bande passante rduite par un nud
situ deux sauts. Une mthode daccs sans contention, telles que TDMA ou CDMA, nest pas

60
concerne par ce problme puisque laccs au support est rgi par les slots et non par lcoute du
support.

Protocole Type Mtrique de
QoS
Type de mthode
daccs
Rservation
de
ressource
Modles
dest. de
mtriques
de QoS
Interfrences
2 sauts
AQOR Ractif Garantie BP et
dlai
Mthodes daccs
avec contention
Oui Oui Non
CAAODV ractif Garantie BP IEEE 802.11 Oui Oui Oui
CACP Ractif Garantie BP IEEE 802.11 Oui Oui Oui
CBCCR Hir. -
Proactif
Garantie BP CDMA-o-TDMA Oui Oui Non concern
CCBR Proactif Garantie BP CDMA-o-TDMA Oui Oui Non concern
CEDAR Hir. -
ractif
Garantie BP IEEE 802.11 Oui Non Non
CLMCQR Ractif Garantie dlai,
BP et de la
fiabilit
IEEE 802.11 Non Non Non
D-LAOR Ractif Garantie du
dlai 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 Ractif Garantie BP CDMA-o-TDMA Oui Oui Non concern
MCNRP Hir. -
Ractif
Garantie BP TDMA Oui Oui Non concern
NSR Proactif Garantie BP et
mtriques
calcules
partir des nuds
et tats de lien
TDMA Oui Non Non concern

61
ODQOS Ractif Garantie BP,
optim. dlai et
nombre de sauts
TDMA Oui Non Non concern
QGUM Go. /
Ractif
Garantie du
dlai, BP et taux
derreur 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, dpendants de la mthode daccs au support, garantissants
la bande passante et/ou le dlai (Hir : Hirarchique, Go : Gographique, BP : Bande Passante,
Optim : Optimisation, CDMA-o-TDMA : CDMA over TDMA).
Le protocole AQOR [XUE 03-1] est un protocole de routage ractif utilisant un accs au canal
distribu. Il propose une mthode pour dterminer la bande passante disponible et le dlai de bout en
bout dun chemin. A partir de ces informations, le protocole dtermine les routes respectant les
contraintes de bande passante et de dlai imposes par un flux.
Le protocole CAAODV [CHE 05-1] propose un protocole ractif bas sur le protocole AODV. La
bande passante disponible sur un mdium partag est estime par lmission de paquets Hello par
chaque nud du rseau. Ces paquets Hello comprennent la bande passante consomme par les nuds
situs dans le voisinage proche et dans le voisinage 2 sauts. Grce 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 prsent. Ce protocole de routage ractif permet la garantie
de la bande passante avec une mthode daccs au support distribue. Un modle pour dterminer la
bande passante disponible sur le mdium est propos. Il dtermine la bande passante consomme par
la prsence dun nouveau flux et les nuds avec lesquels le flux peut interfrer sont alerts dune telle
prsence lors de la phase de dcouverte des routes. Un flux est accept sur le rseau uniquement si les
nuds avec lesquels il interfre possdent suffisamment de bande passante pour que ce flux ne
dgrade pas les flux dj en place. Un contrle dadmission est donc mis en place sur les nuds,
pouvant refuser un nouveau flux mme si ce dernier ne les traverse pas.
Dans [CHE 97-1], le protocole CBCCR et une estimation de la capacit du canal sont prsents. Les
auteurs proposent que le rseau soit hirarchis en clusters. Les nuds du rseau utilisent une mthode
daccs au mdium de type CDMA-o-TDMA. Chaque nud group dans le mme cluster possde le
mme code. Un protocole de routage proactif, bas sur DSDV, est utilis pour dterminer le nombre
de slots disponibles entre deux nuds du rseau. Lutilisation de codes diffrents entre clusters permet
de simplifier ce calcul de bande passante. Une passerelle reliant deux clusters voit ses slots diviss
entre les deux clusters. En effet, devant changer de code, les slots ne peuvent tre communs. Comme
une passerelle est un nud intermdiaire sur un chemin, le nombre de slots est facile calculer

62
puisque le nombre de slots libres sur le lien entre un nud et une passerelle correspond au nombre de
slots susceptibles dtre rservs.
Le protocole CCBR [LIN 99-1] propose un algorithme calculant la bande passante disponible pour un
chemin. Cet algorithme adapte lalgorithme propos dans le protocole CBCCR dans un environnement
non hirarchis. Pour fonctionner, il ncessite lutilisation dun rseau dont la mthode daccs au
support est CDMA-o-TDMA. La capacit dun chemin est exprime en termes de slots libres. Le
protocole DSDV est utilis pour dterminer les routes. Les informations de routage sont utilises pour
rafrachir les slots libres dans la table de routage. Lalgorithme de CCBR calcule la meilleure
combinaison de slots libres sur un chemin retournant ainsi la bande passante maximum disponible sur
un tel chemin. Lorsquun flux ncessite la rservation de slots en direction dun nud destination, la
source consulte sa table de routage. Si le nombre de slots est suffisant, une phase de rservation est
entreprise sur le chemin.
Le protocole CEDAR [SIV 99-1] est un protocole hirarchique. Les nuds du rseau forment un
rseau backbone. Lors de la recherche dune route QoS, le nud backbone du nud source
cherche une route vers le nud backbone du nud destination. Pour cela, un protocole ractif est
utilis. Des informations dtat sur la topologie du rseau sont propages seulement quand des seuils
sont atteints. Quand la bande passante crot, linformation traverse lentement le rseau. Par contre,
lorsque la bande passante dun lien dcrot, linformation traverse rapidement le rseau vitant ainsi
des nuds de choisir un tel lien alors que la bande passante nest plus disponible.
Lheuristique CLMCQR [FAN 04-1] propose partir dune vue du rseau de dterminer les chemins
respectant des contraintes de bande passante, de dlai et de fiabilit. Pour cela, lalgorithme Dijkstra
ou Bellman-Ford est appliqu au rseau avec une fonction poids mixant ces trois paramtres. Les liens
du rseau ayant une bande passante disponible infrieure la bande passante requise sont retirs du
rseau (donc ils ne sont pas considrs lors du calcul dune route). La fiabilit dun lien est
transforme en mtrique additive en utilisant un logarithme et combin au dlai. La combinaison de
ces deux mtriques permet la slection du chemin.
Le protocole D-LAOR [SON 03-1] est un protocole de routage ractif. Il permet de garantir le dlai en
optimisant le nombre de sauts du chemin. A la rception dune requte RREQ, un nud intermdiaire
retransmet un paquet RREQ lorsque le dlai et le nombre de sauts du chemin sont plus faibles que
ceux des chemins pralablement reus.
Le protocole IAR [GUP 05-1] est un protocole de routage hybride permettant dassurer un flux une
certaine quantit de bande passante. Chaque nud met priodiquement un tat des liens qui est
propag sur la totalit du rseau. Ainsi, chaque nud possde une vue du rseau. Lorsquune route a
besoin dtre trouve, le nud source utilise diffrents algorithmes (avec des contraintes diffrentes)
dterminant un ensemble de routes de bout en bout. Un paquet dallocation est envoy sur chacun de
ces chemins. Un tel paquet est propag seulement si un nud peut rserver la bande passante requise.
A la rception de tels paquets, la destination choisit la meilleure route suivant lun des critres
suivants : la route ayant le plus de bande passante ou la route avec le plus faible cot.

63
Le protocole LS-MPR [CHE 04-1] est un protocole de routage QoS ractif. Il utilise la mthode
daccs au mdium CDMA-o-TDMA pour rserver la bande passante. Ce protocole retourne un
ensemble de chemins dont la bande passante cumule permet le respect de la contrainte de bande
passante. La destination est llment dterminant les chemins susceptibles de convenir aux besoins.
Pour cela, elle dtermine les slots rserver de bout en bout des chemins vitant ainsi un quelconque
conflit entre slots lors de la rservation. Un tel conflit interrompt la rservation des ressources puisque
la rservation ne peut tre assure de bout en bout.
Le protocole MCNRP [DU 04-1] est un protocole de routage hirarchique. Ce protocole utilise
lhtrognit des caractristiques des nuds pour les diviser en classe. Ainsi, un rseau bakbone
est form avec les nuds possdant une bande passante leve et une porte consquente. Seuls ces
nuds peuvent transmettre les informations de routage rduisant 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
mcanisme de rservation de ressource particulier est utilis permettant de pouvoir rserver les slots de
bout en bout si cela savre possible.
Dans NSR [STI 04-1], chaque nud maintient les informations le concernant ainsi que lespace qui
lentoure. Pour raliser la fonction de routage, un nud met priodiquement au reste du rseau les
informations le concernant. Lintervalle de temps avec lequel ces informations sont propages devient
plus grand avec laugmentation de la distance. Une telle connaissance de ltat des nuds du rseau
permet un nud de dterminer la prsence de connectivit avec un autre nud du rseau ainsi que la
perte de connectivit si le modle de propagation est connu. Le routage QoS est ralis partir
dtats imprcis du rseau. En dduisant les liens entre paires de nuds partir de leurs tats, un nud
peut facilement calculer une route en utilisant, par exemple, lalgorithme de Dijkstra. Les mtriques de
routage peuvent tre multiples et sont dduites pour un lien en fonction des tats des nuds (ainsi que
de leurs voisins) qui le composent.
Le protocole ODQOS [HO 02-1] est un protocole de routage QoS ractif. Il garantit la bande
passante requise par un flux sur un chemin. Ce protocole dpend dun accs au mdium TDMA pour
raliser la slection et la rservation des slots. Ce protocole considre chaque trame TDMA
distinctement. Ainsi, il peut rserver les slots sur des trames diffrentes. Lors de la slection des
chemins, la destination slectionne le chemin possdant le plus faible dlai de bout en bout. Ce dlai
est calcul en fonction des slots rservs. Si plusieurs chemins possdent le mme dlai, le chemin
possdant le moins de sauts est choisi. Le problme de ce protocole est que la totalit des slots libres
sont rservs durant la phase de dcouverte des routes. Ils sont librs lors de la confirmation
dacquisition dune route.
Le protocole QGUM [ABD 06-1] propose un protocole de routage gographique bas sur le protocole
GPRS. Ce protocole de routage sadapte aussi bien une mthode daccs avec contention que sans
contention. Un mcanisme de contrle dadmission est mis en place sur chaque nud pour vrifier que
le nud slectionn lors de la phase de dcouverte des routes respecte les contraintes de dlai, de
bande passante et de taux derreur de paquets. Ce protocole de routage choisit le nud le plus proche
de la destination pouvant relayer linformation. Chaque nud applique cette mthode de slection du
prochain nud. Si un nud ne peut respecter les contraintes imposes, lapplication est prvenue dun

64
tel chec et recommence la dcouverte des routes en tant le nud le plus proche de la destination
prcdemment slectionne.
Le protocole QoSOLSR [NGU 07-1] est un protocole de routage proactif. Il est bas sur le protocole
OLSR. Priodiquement, chaque nud obtient le chemin ayant la plus grande bande passante
disponible vers les autres nuds du rseau. Pour satisfaire les contraintes dun nouveau flux, le nud
source calcule la bande passante de bout en bout requise par ce flux. Si la bande passante disponible
est suprieure la bande passante requise, le flux est accept. Les paquets, des flux accepts, sont
forcs suivre la route slectionne par le nud source. La route reste inchange jusqu quun lien
soit rompu. Un mcanisme de contrle dadmission empche que les flux meilleur efforts empitent
sur la bande passante rserve par les flux QoS.
3.6 Discussion
De par la nature variable du mdium et le dplacement des nuds, la gestion de la qualit de service,
dans les rseaux MANETs, nest pas chose aise. Durant une communication, le protocole de routage
QoS est un lment dterminant dans la dcouverte et la maintenance de chemins garantissant des
contraintes de QoS.
Les applications multimdia ncessitent entre autres une garantie de bande passante et du dlai. De
nombreux protocoles de routage, permettant de garantir au moins lune de ces mtriques, ont t
proposs ces dernires annes. Ces protocoles peuvent tre proactifs, ractifs ou hybrides. Les
protocoles proactifs mettent jour rgulirement leur table de routage par lenvoi priodique
dinformations de routage sur le rseau. Pour garantir un flux la QoS demande, un mcanisme
adapt pour la rservation de ressources doit tre utilis. En effet, il doit permettre une gestion par flux,
en maintenant dans une table (pour la dure de la communication) le chemin slectionn linstant o
le flux requiert un chemin. Le mcanisme de rservation de ressources volue en fonction de larrive
des flux c'est--dire quil rserve la bande passante ncessaire sur demande. Une telle rservation
engendre un dlai supplmentaire pour rserver la bande passante dun nouveau flux. Les protocoles
ractifs possdent, quant eux, une gestion de la QoS sur demande. Ils cherchent une route lorsquun
nouveau flux se prsente. Le mcanisme de rservation de ressources peut facilement tre coupl au
mcanisme de dcouverte des routes. Ce type de protocole est donc pleinement efficace avec un
mcanisme de rservation de ressources puisquaucun dlai supplmentaire nest engendr par la
rservation. Du fait dune gestion par flux, les protocoles ractifs sont moins dpendants des mtriques
de QoS que les protocoles proactifs. De fait, un protocole de routage ractif peut trouver une route
avec le plus faible dlai pour une application donne et une route avec le plus faible taux derreur pour
un autre type dapplication. Avec la garantie de la QoS, les protocoles proactifs et ractifs souffrent,
tout de mme, dune maintenance dlicate des routes. La gestion de la perte des routes est galement
ralise par flux. La rupture dun lien engendre souvent la perte des routes de plusieurs flux. De fait, le
rseau peut subir une congestion temporaire le temps de rtablir lensemble des flux. Les protocoles
hybrides slectionnent priodiquement une route optimisant une mtrique et grent ractivement la
QoS par flux. Ce type de protocole sadapte mieux aux besoins des flux que les protocoles proactifs

65
mais le nombre de paquets de routage changs est bien suprieur celui changs par les protocoles
proactifs. Contrairement aux protocoles proactifs qui souffrent dun dlai en cas de rservation de
ressources, les protocoles hybrides souffrent dun dlai en cas de rservation de ressources mais aussi
en cas de recherche sur-demande de route si la route obtenue priodiquement ne convient pas. Vis--
vis des protocoles ractifs, les protocoles hybrides mettent moins de paquets de routage uniquement
si la route obtenue priodiquement respecte les contraintes du flux, sinon ce nombre est plus important.
Les utilisateurs ncessitant toujours plus de qualit, la bande passante requise par les applications
multimdia et temps-rel na cess de crotre. Les diffrents protocoles prsents dans ce chapitre
permettent la garantie de contraintes telles que la bande passante ou le dlai. Par contre, trs peu de ces
protocoles influent sur les paramtres pnalisant la bande passante du rseau. Les protocoles tels que
QGUM, ODCR ou BWR utilisent un routage gographique pour rduire le nombre de paquets de
routage changs lors de la cration dune route. Diminuer les informations de routage est un moyen
daugmenter la bande passante disponible du rseau. De mme, les protocoles, comme ADQR ou
AAQR, slectionnent les routes les plus stables garantissant les contraintes de QoS. Augmenter la
dure de vie dune route, rduit le nombre de paquets ncessaires la maintenance des routes en place.
Le protocole de routage QoS doit tout mettre en uvre pour accrotre la bande passante disponible
du rseau. Avec laugmentation de la bande passante disponible dans le rseau, le nombre de flux
accepts par le rseau est plus important, ou les flux peuvent consommer une bande passante plus
importante.
Les diffrents protocoles, que nous proposons dans les chapitres suivants, ont pour but principal
laccroissement de la bande passante du rseau. Nos protocoles utilisent une gestion par flux, pour
connatre au mieux les besoins en QoS dsirs par un flux. Ainsi, les protocoles proposs sont de type
ractif.

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 crotre. En effet, proposant
toujours plus de fonctionnalits aux utilisateurs, ce besoin savre croissant. Le domaine dapplication
des rseaux ad hoc stend aussi bien des applications peu consommatrices en bande passante qu
des applications fortement consommatrices. La bande passante de ce type de rseaux est
particulirement limite. Actuellement, avec la norme IEEE 802.11g le dbit maximal slve
54 Mbits/s. Ce dbit reste trs faible compar aux dbits que peuvent atteindre les rseaux filaires
(plusieurs centaines de Gbits/s avec la fibre optique).
Pour supporter le plus grand nombre dapplications sur un rseau ad hoc, il est ncessaire doptimiser
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 ngligeable. En effet,
lorsquune collision est dtecte, les stations mettrices doivent rmettre leurs paquets. La
retransmission a tendance augmenter la bande passante consomme et par consquent accrotre le
nombre de collisions.
Les collisions sont un handicap pour les rseaux support partag. A 85% de sa charge maximale, un
rseau IEEE 802.11 ad hoc (dpourvu de stations caches) tend vers sa bande passante utile maximale
(environ 74% de la bande passante du rseau) [HAD 99-1]. En effet avec une telle charge, les
collisions entre les stations deviennent particulirement importantes engendrant un fort dlai dans la
transmission des paquets (le temps pour acqurir le support est important) et le dbordement des files

68
dattente (avec la suppression des paquets les plus rcents). Des mcanismes peuvent tre employs
pour rduire limpact des collisions. En effet, le mcanisme RTS/CTS permet de diminuer limpact
des collisions cres par le phnomne des nuds cachs. Les collisions sappliquent ainsi sur des
trames plus courtes rduisant dautant la bande passante consomme lors des retransmissions. Ce
mcanisme, certes essentiel, agit lorsque les collisions se sont produites. Il serait intressant doprer
avant que de telles collisions se produisent. Ainsi, la bande passante est prserve, et peut tre affecte
lutilisation par dautres flux. Rduire les collisions rend, de fait, le mcanisme RTS/CTS
(consommateur en bande passante) moins indispensable.
4.1.1 Paramtres influant sur la diminution de la bande passante
Les rseaux sans fil sont soumis de nombreux paramtres impactant la bande passante utile. La
bande passante des rseaux sans fil peut tre dtriore la fois soit par des phnomnes physiques
dont sont dispenss gnralement les rseaux filaires, soit par les fonctionnalits des protocoles
employs. Nous nous intressons dans ce chapitre principalement aux paramtres pouvant tre pris en
compte par les protocoles de la couche rseau. Ainsi, les paramtres consommateurs en bande passante
lis par exemple aux protocoles implants dans la couche 2 des rseaux IEEE 802.11 (temps daccs
au support, informations de topologie changes) ne seront pas dtaills.
Les phnomnes physiques oprant sur la qualit des informations changes sont lies aux
caractristiques du mdium, lair, et au partage de ce support. Lorsquune station dsire mettre des
informations, elle module ses donnes avant de les envoyer. Les ondes lectromagntiques, lies aux
diffrents signaux, se perturbent mutuellement. Ces perturbations vont ainsi accrotre le taux derreurs
et le nombre de collisions.
Le taux derreurs est li aux caractristiques du canal de transmission. Le canal de transmission peut
tre plus ou moins sensible des bruits lectromagntiques extrieurs (bruit thermique, bruit
dintermodulation, bruit impulsif ) comme aux propagations multitrajets entrainant une plus ou
moins bonne rception des signaux. Lorsque linformation est dmodule, linformation numrique
obtenue peut tre errone et diffrente de celle initialement transmise. Le contrle derreurs implant
au niveau liaison de donnes du standard IEEE 802.11 permet de dtecter de telles erreurs et de les
isoler. Une trame errone est par consquent supprime, charge de lmetteur de la retransmettre. Ne
recevant pas dacquittement de la part du rcepteur, lmetteur suppose quune collision est survenue.
Une collision entre deux missions survient lorsque les stations mettrices sont situes porte radio
dun des rcepteurs. Les transmissions se perturbant, le rcepteur est incapable de les diffrencier. Les
stations mettrices doivent ainsi retransmettre leurs trames.
Le taux derreur important des rseaux sans fil et le nombre de collisions subies par les trames de
donnes sont autant de facteurs rduisant la bande passante utile des rseaux ad hoc. Le protocole de
routage peut lors de la dcouverte des routes viter celles qui subissent beaucoup de collisions (ajouter
du trafic supplmentaire ne ferait quaccrotre le nombre de collisions) ou celles qui ont un taux
derreurs important.

69
Les facteurs physiques ne sont pas les seuls influer sur la diminution de la bande passante utile du
rseau. Le protocole de routage lui-mme 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
donnes entre deux stations. Plusieurs tches affectes aux protocoles de routage sont plus ou moins
consommatrices en bande passante suivant les mthodes utilises. Ainsi, le protocole de routage
doit assumer les tches suivantes :
Contrle de la topologie : pour conserver la cohrence des routes dj existantes, les stations
ont besoin de savoir si la connectivit avec leurs voisins est toujours tablie. La dtection de
la perte dun lien doit tre prise en compte par le protocole de routage qui doit recrer une
route si le besoin sen fait ressentir, rle gnralement dvolu la partie maintenance des
routes. Une station employant le protocole de routage AODV peut utiliser deux mthodes
pour dtecter la cration ou la perte dun lien vis--vis des voisins vers lesquels elle doit
propager des paquets de donnes. La premire mthode quutilise AODV est lenvoi
priodique de paquets HELLO. Ces paquets annoncent lensemble du voisinage dun nud
sa prsence. Lavantage de ce type de technique intrusive est que les stations sont capables de
connatre la cration ou la perte dun lien assez rapidement. La ractivit de cette technique
dpend principalement de la frquence denvoi de ces paquets. Par contre, ils ont un cot non
ngligeable sur la bande passante utile du rseau. Une deuxime mthode utilise la couche de
niveau infrieur pour connatre ltat dun lien. En effet, lorsque la couche MAC choue
transmettre un certain nombre de fois le mme paquet, cest--dire que la station ne reoit pas
dacquittement annonant la bonne rception du paquet, elle prvient la couche rseau pour
lavertir de la perte du lien. Cette mthode est moins consommatrice en bande passante que
son homologue tout en assurant une faible latence dans la dtection de la perte du lien.
Calcul de routes : le protocole de routage dtermine les routes en mettant sur le rseau des
informations de routage. Suivant le type de protocole utilis, proactif ou ractif, les nuds
peuvent mettre ces informations priodiquement ou seulement lorsque le besoin dune
nouvelle route se fait ressentir. Par exemple, une station utilisant le protocole AODV diffuse
lensemble de ses voisins un paquet de demande de cration de route RREQ. Chaque nud
recevant ce paquet le retransmet sil ne connat pas de route vers la destination. Lmission de
tels paquets doit tre contrle car ils consomment galement de la bande passante. De tels
paquets peuvent galement crer des collisions avec les nuds voisins. Pourtant de nombreux
paquets RREQ ne sont pas rellement utiles la cration dun chemin. La plupart du temps,
les paquets RREQ transmis dans la direction oppose celle de la destination ne servent pas
la cration dune route. De mme, les paquets RREQ diffuss au-del de la destination nont
pas de relle utilit dans une grande majorit des cas.
Maintenance des routes : le protocole de routage doit prendre en compte les changements de
topologie dus aux dplacements des nuds. Par consquent, les routes voluent avec le temps.
Les protocoles de routage de type proactif adaptent les routes vers les autres nuds du rseau
grce lchange priodique des paquets de contrle. Cette adaptation au rseau na pas de
rel surcot puisque cest les mmes informations de routage utilises que celles pour la
dcouverte des chemins. Par contre, il en est tout autrement avec les protocoles de type ractif.

70
Ces protocoles doivent prvenir les nuds sources, dont les chemins sont rompus, quils
doivent en recrer dautres si le besoin sen fait ressentir. Par exemple, le protocole AODV
envoie des paquets RERR en direction de chaque source o la perte dun chemin a t
dtecte. Ces paquets supplmentaires engendrent un cot relativement faible sur la
consommation de bande passante car ce sont des paquets unicast et non diffuss comme lors
de la recherche de chemin.
De nombreux paramtres influent sur la diminution de la bande passante utile. La rduction de
limpact dun ou plusieurs de ces paramtres permet daccrotre la bande passante utile et par
consquent le nombre de paquets de donnes qui peuvent transiter sur le rseau. Le protocole de
routage est relativement bien adapt la ralisation de cette tche car cest lui qui choisit les chemins
par lesquels vont passer les paquets de donnes. Nous nous attachons principalement, dans ce chapitre,
rduire le nombre de collisions dans le rseau, car les collisions jouent un rle important dans la
diminution de la bande passante utile. Surtout, que les collisions surviennent lorsque la charge du
rseau commence devenir importante, sachant que cest 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 quelles engendrent.
4.1.2 Protocole de routage : lment essentiel dans la gestion de la
bande passante
Le protocole de routage est llment, de par sa tche, le mieux dispos dterminer une route, tout en
ayant comme objectif loptimisation de la bande passante. Le protocole de routage utilise une ou
plusieurs mtriques pour dterminer la qualit dun chemin emprunter. La bande passante utile du
rseau tant consomme par de nombreux lments, le protocole de routage doit faire son maximum
pour essayer doptimiser celle-ci. Le protocole de routage AODV sur lequel nous allons baser nos
travaux, utilise le nombre de sauts comme mtrique. Il ne permet pas de retourner le chemin possdant
le plus faible nombre de nuds mais un chemin qui sen rapproche. Les informations quil change
lors de la dtermination de la route ont un impact sur la bande passante du rseau. Plus le nombre
dinformations de routage changes est important, plus la bande passante du rseau est employe
pour la transmission de telles informations. Par consquent, la bande passante utile dvolue au
transfert de donnes devient faible. Le protocole de routage doit trouver un juste milieu entre
dissmination dinformations dtat et bande passante consomme.
Les protocoles de routage ractifs, comme AODV, mettent des informations de routage, seulement
lorsque la ncessit de trouver une nouvelle route se fait ressentir, ou lors de la rupture dun chemin.
Ces informations changes sont susceptibles de crer des collisions.
Dans ce chapitre, nous allons principalement essayer de diminuer les collisions qui peuvent subvenir
dans le rseau. Pour cela, les protocoles de routage sont bien adapts pour raliser cette tche. En effet,
ils peuvent viter les chemins dj surchargs et choisir des chemins o le trafic est plus fluide.
Prendre le chemin le plus court nest pas toujours la solution idale. En effet, un nud dun tel chemin
peut savrer tre submerg par le trafic de ses voisins. Accrotre le trafic traversant un tel nud

71
nengendrerait quun surplus de collisions impactant les nuds voisins ainsi quune augmentation
consquente du temps pass par les paquets en file dattente. Emprunter des chemins dont le nombre
de collisions est dj important na tendance qu accrotre le trafic et par consquent augmenter
encore plus le nombre de collisions. Lide pour diminuer les collisions et le temps dattente des
paquets est dutiliser des chemins moins encombrs. Employer de tels chemins revient utiliser les
itinraires bis comme dans la vie relle lorsquun bouchon est prsent sur une route par exemple.
Nous proposons dans ce chapitre deux protocoles de routage ractifs. Ces deux protocoles sattachent
diminuer le nombre de collisions subies par le rseau et ainsi augmenter sa bande passante utilisable
(throughput). Le premier protocole opre directement sur les collisions en tenant compte du taux de
collisions des chemins slectionns. Le deuxime protocole essaie dagir sur les causes des collisions.
Il vite les chemins qui seraient susceptibles daccrotre les collisions subies par le rseau.
4.2 Collisions : causes et consquences

Dans ce chapitre, nous mettons en vidence les paramtres influant sur le nombre de collisions. Le
protocole de routage doit en tenir compte pour en diminuer ce nombre. Une diminution des collisions
permet daugmenter la bande passante utile du rseau. Dans un premier point, nous donnerons les
causes des collisions, en calculant la probabilit dobtenir au moins une collision lors de lmission
dun paquet. A partir de cela, nous mettons en avant les diffrentes causes oprant sur les collisions.
Le deuxime point consiste donner les consquences des collisions sur les performances du rseau.
4.2.1 Causes
Les collisions se produisent sur un support partag lorsque plusieurs metteurs transmettent leurs
donnes en mme temps. Si ces metteurs se trouvent porte radio dun des rcepteurs, ce rcepteur
ne peut pas rcuprer les donnes initiales. Une transmission se produit correctement lorsquun
rcepteur reoit les donnes c'est--dire quelles sont exemptes derreurs et de collisions. Lmetteur
sait quun paquet a t convenablement reu, par son destinataire, lors de la rception dun
acquittement. Lorsque lmetteur ne reoit pas dacquittement dans un temps donn aprs la
transmission dune trame, il suppose quun problme a eu lieu. Lmetteur doit par consquent
rmettre la trame. Les collisions ne sont pas les seules causes dune retransmission. En effet, les
irrgularits du support (apparition derreurs lors du transfert dune trame, perte dune trame)
peuvent empcher le rcepteur de transmettre un acquittement. Dans ce chapitre, nous considrons
uniquement les collisions.
Nous distinguons par la suite deux types de nuds, le nud metteur et les nuds perturbateurs. Un
nud est dit metteur sil transmet une trame un nud distant. Les nuds perturbateurs empchent
la bonne rception des donnes par la destination. Les nuds perturbateurs doivent tre dans le
voisinage direct du nud rcepteur (c'est--dire 1 saut) pour quil y ait collision. De mme, la

72
transmission des trames par le nud metteur et les nuds perturbateurs doivent avoir lieu quasi
simultanment.
Un rseau MANET peut tre reprsent par un graphe G(V, E) avec V lensemble des nuds du rseau
et E lensemble des liens entre ces nuds. Un nud X appartient au voisinage dun nud Y sil existe
un lien <X, Y> appartenant E. Lensemble des nuds appartenant au voisinage dun nud X est not
N(X). Considrons A et B deux nuds appartenant V. Un paquet transmis par A au nud B, un
instant t, subit une collision si un nud X appartenant V tel quil existe un lien <X, B> appartenant
E transmet un paquet un instant compris dans lintervalle [t-, t+] (avec , des dures diffrentes
ou gales). Par consquent, le nud perturbateur X peut se situer :
dans le voisinage de A (et obligatoirement dans celui de B).
dans le voisinage du nud B (mais pas dans celui de A).
Par consquent, il est donc possible de distinguer deux types de nuds perturbateurs dans loccurrence
de collision :
1) nuds dans le voisinage direct de lmetteur :
Un nud situ un saut du nud metteur peut crer une collision sil respecte la proprit 4-1.
Proprit 4-1 : Lensemble des nuds voisins un saut dun nud metteur X pouvant crer
des collisions sur un lien <X, Y> est gal N(X)N(Y). Cet ensemble est not N
1Saut
(X, Y).
Dmonstration :
Pour quun nud Z situ un saut dun nud metteur X soit susceptible de commettre une collision
sur un lien <X, Y>, il est ncessaire quun paquet mis par le nud Z soit aussi entendu par le nud Y.
Par consquent, le nud Z doit tre situ un saut du nud Y, cest--dire quil doit faire partie de son
voisinage.
Donc Z appartient lensemble des nuds communs au voisinage de X et de Y.

Les nuds dans le voisinage direct dun nud metteur possdent un intervalle de temps relativement
restreint pour crer une collision. En effet, lorsquun nud entend que le support est occup il retarde
sa transmission jusqu que le support devienne nouveau libre. Par consquent, lintervalle de temps,
durant lequel les collisions peuvent apparatre, est fonction du dlai de propagation entre ces deux
nuds. Le dlai de propagation entre un nud X et un nud Y est not d(X, Y). La proprit 4-2
nonce lintervalle de temps de collisions pour les nuds prsents dans le voisinage direct du nud
metteur.

73
Proprit 4-2 : Un nud X mettant son paquet un instant t
0
subit une collision sur un lien
<X, Y> si un nud ZN
1Saut
(X, Y) transmet un paquet dans lintervalle de temps
[t
0
-d(X,Z), t
0
+d(X,Z)].
Un nud X peut crer une collision avec un nud Y transmettant son paquet un temps t si X transmet
le paquet avant Y et que Y na pas encore reu la trame de X ou que Y transmette son paquet avant X et
que ce dernier na pas encore reu la trame de Y avant de transmettre la sienne. Ces deux cas de figure
sont reprsents sur la figure 4-1. Dans cet exemple, une station mettrice X transmet un paquet
linstant t
0
. Une station Y perturbe la transmission de X si Y transmet son paquet dans lintervalle de
temps [t
0
-d(X,Y), t
0
] (figure 4-1 a)) ou [t
0
, t
0
+d(X,Y)] (figure 4-1 b)). La fentre de collision pour des
nuds 1 saut est lintervalle de temps [t
0
-d(X,Y), t
0
+d(X,Y)].

Figure 4-1 : Intervalle de temps durant lequel peut se produire une collision. a) X commence
transmettre alors que Y a dj commenc transmettre. b) Y commence transmettre alors que X a
dj commenc transmettre.

2) nuds situs 2 sauts de lmetteur :
Un nud situ deux sauts dun nud metteur peut crer une collision sil respecte la proprit 4-3.
Proprit 4-3 : Lensemble des nuds voisins deux sauts dun nud metteur X pouvant
crer une collision sur un lien <X, Y> est gal {Z | Z, Z N(Y) Z N(X)}. Cet ensemble
est not N
2Sauts
(X, Y).
Dmonstration :
Un nud Z nappartenant pas au voisinage dun nud metteur X est susceptible de gnrer des
collisions sur un lien <X, Y> sil est entendu par le nud Y c'est--dire quil fait partie du voisinage de

74
Y.
Par consquent, Z doit appartenir au voisinage du nud Y sans appartenir au voisinage du nud X.

Lorsque les nuds metteurs sont spars par un nud intermdiaire (rcepteur pour au moins un des
deux nuds), ils ne sont pas capables de scouter mutuellement sils transmettent des donnes. Ce
phnomne sappelle le problme des nuds cachs. Par consquent, contrairement au cas un seul
saut, lintervalle de temps pour loccurrence dune collision nest plus fonction du dlai de
propagation. En effet, ces nuds metteurs dtectent que le support est libre avant de transmettre leur
trame, mme si une autre trame est mise. La proprit 4-4 nonce un tel cas de figure.
Proprit 4-4 : Un nud X mettant un paquet un instant t
0
sur un lien <X, Y> subit une
collision si un nud Z N
2Sauts
(X, Y) transmet un paquet dans lintervalle de temps
[t
0
- Tp
max
, t
0
+ Tp
max
] o Tp
max
est le temps maximal de transmission dun paquet.
Soit deux nuds X et Y spars par 2 sauts. Une collision se produit si un nud X met un paquet
avant le nud Y et Y transmet durant la transmission de ce paquet. Le nud rcepteur est par
consquent incapable de dchiffrer les donnes rceptionnes. De mme, si un nud X transmet un
paquet aprs un nud Y, il y a collision si X dbute sa transmission nimporte quel moment de
lenvoi de la trame mise par Y. Ce cas de figure est reprsent sur la figure 4-2.

Figure 4-2 : Intervalle de temps durant lequel une collision est susceptible de se produire dans le cas
de nuds cachs.
Au final, lintervalle de temps durant lequel peut se produire une collision diffre suivant que les
nuds perturbateurs se situent un saut du nud metteur ou quils se situent deux sauts. Diminuer
le nombre de collisions revient rduire la probabilit quun paquet subisse une collision. Dterminer
une telle probabilit permet de mettre en vidence les paramtres influant sur laccroissement des
collisions.
Pour dterminer la probabilit pour un paquet de subir au moins une collision, il savre ncessaire de
connatre la loi darrive des paquets ainsi que la probabilit quune collision soit cre par un voisin
direct et deux sauts. Pour cela, nous diffrencions deux cas suivant que larrive entre deux paquets

75
est priodique ou variable. Par la suite, nous supposons que le nud metteur X transmet un paquet au
temps t
0
, quun nud Z (Z N
1Sauts
(X, Y) ou Z N
2Sauts
(X, Y)) na pas de paquet en file dattente et
quil a correctement russi mettre un paquet au temps t
Z
, avec t
Z
< t
0
. Si le nud Z na jamais mis
de paquet alors t
Z
= 0. Nous faisons ces hypothses de dpart car nous souhaitons observer les
paramtres agissant sur la probabilit davoir une collision indpendamment des collisions prcdentes
(dont le temps de transmission entre deux transmissions successives du mme paquet est fonction du
temps dattente backoff). Pour le nud Z, le calcul du temps sparant larrive dun paquet un autre
commence au temps t
Z
. Donc le nud Z se base sur un repre temporel dcal de t
Z
par rapport au
nud X. Dans un tel cas, lintervalle de temps de collision est [(t
0
-t
Z
)-d(X,Z), (t
0
-t
Z
)+d(X,Z)] pour un
voisin un saut et [(t
0
-t
Z
)- Tp
max
, (t
0
-t
Z
)+ Tp
max
] pour un nud Z situ deux sauts du nud metteur.
1) Trafic priodique :
Nous supposons que larrive entre deux paquets est priodique. Pour un nud Z, la priode entre
deux paquets est note T
z
. Ainsi larrive du k
me
paquet est donne par la formule suivante :
t
z
(k) = k T
z

o k IN
La probabilit qua un nud Z situ dans le voisinage direct dun nud X de crer une collision sur le
lien <X, Y> est donne par la proprit 4-5.
Proprit 4-5 : La probabilit P
1Saut
(Z) quun nud metteur X ayant transmis un paquet
linstant t
0
subisse une collision dun nud ZN
1Sauts
(X, Y) est la suivante :
( )
( ) ( ) ( ) ( ) ( ) [ ]
+ +
=
sinon 0
, si 1
0 0
1
X,Z d -t t X,Z d -t t T t
Z P
Z Z z z
Saut
.
La probabilit qua un nud Z situ dans le voisinage direct dun nud X de crer une collision sur le
lien <X, Y> est donne par la proprit 4-6.
2Saut
linstant t
0
subisse une collision dun nud ZN
2Sauts
(X, Y) est la suivante :
( )
( ) ( ) ( ) [ ]
+ +
=
sinon 0
, si 1
max 0 max 0
2
Tp t t Tp t t T t
Z P
Z Z z z
Saut
o Tp
max
le temps
maximal de transmission dun paquet.

76
2) Trafic variable :
Nous supposons que larrive entre deux paquets suit une loi exponentielle avec un taux darrive gal
. Une fonction f suivant une loi exponentielle darrive est reprsente par lquation suivante :
( )
<
0 , 0
0 ,
x
x e
x f
x
(4-1)

Il reste dterminer la probabilit qua un nud dans le voisinage direct engendrer une collision
ainsi que la probabilit qu un nud deux sauts de gnrer une collision sur un lien <X,Y>. Ces
probabilits sont nonces par la proprit 4-7 et proprit 4-8.
1Saut
linstant t
0
subisse une collision dun nud Z situ un saut est la suivante :
( )
( ) ( ) ( )
( )
Z X d Z X d t t
Saut
e e e Z P
Z
, ,
1
0

= .
Dmonstration :
Un nud Z peut crer une collision avec le nud metteur X sur le lien <X, Y> sil transmet dans
lintervalle de temps [(t
0
-t
Z
)-d(X,Z), (t
0
-t
Z
)+d(X,Z)] (proprit 4-2). Par consquent, la probabilit
davoir une collision entre ces deux nuds dpend du temps de transmission du paquet par le nud Z.
La probabilit davoir une telle collision est le fait dmettre dans un tel intervalle est la suivante :
( )
( ) ( ) ( ) ( ) ( )
[ ]
( ) ( )
( ) ( )
( ) ( )
( ) ( )
( ) ( ) ( )
( )
Z X d Z X d t t
Z X d t t
Z X d t t
Z X d t t
Z X d t t
t t
Z Z
Saut
e e e
e dt e
Z X d t t t Z X d t t t P
Z P
Z
Z
Z
Z
Z
, ,
,
,
,
,
0 0
1
0
0
0
0
0
, ,

+

+

=
+
=

2Saut
linstant t
0
subisse une collision dun nud Z situ un saut est la suivante :
( )
( )
( )
max max 0
2
Tp Tp t t
Saut
e e e Z P
Z

= avec Tp
max
le temps maximal de transmission dun
paquet.
Dmonstration :
Un nud Z deux sauts dun metteur X peut crer une collision sur le lien <X, Y> sil transmet dans
lintervalle de temps [(t
0
-t
Z
)- Tp
max
, (t
0
-t
Z
)+ Tp
max
] (proprit 4-4). Par consquent, la probabilit

77
davoir une collision entre ces deux nuds dpend du temps de transmission du paquet par le nud Z.
La probabilit davoir une telle collision est le fait dmettre dans un tel intervalle est la suivante :
( )
( ) ( ) ( )
[ ]
( )
( )
( )
( )
( )
( )
max max 0
max 0
max 0
max 0
max 0
max 0 max 0
2
Tp Tp t t
Tp t t
Tp t t
Tp t t
Tp t t
t t
Z Z
Saut
e e e
e dt e
Tp t t t Tp t t t P
Z P
Z
Z
Z
Z
Z

+

+

=
+
=

A partir de la proprit 4-5 et proprit 4-6 ou de la proprit 4-7 et proprit 4-8, la probabilit quun
paquet subisse au moins une collision peut tre calcule. Cette probabilit reprsente la transmission
dun paquet par un nud dans le voisinage direct ou deux sauts du nud metteur. Les chances
quun paquet subisse au moins une collision sont donnes par la proprit suivante :
Proprit 4-9 : La probabilit quun paquet mis par un nud X subisse au moins une collision
sur un lien <X, Y> est gale ( ) ( ) ( ) ( ) ( )
( ) ( )
|
|
\
|
=

Y X N i Y X N i
Saut Saut C
i P i P X P
, ,
2 1
1 2
1 1 1
Dmonstration :
Pour calculer la probabilit p quun paquet subisse au moins une collision lors de sa transmission, il
suffit dobtenir la probabilit q quun paquet ne subisse aucune collision durant sa transmission. En
effet, p=1-q.
Par consquent, la probabilit quun paquet ne subisse aucune collision lors de sa transmission, est
quaucun nud appartenant N
1Saut
(X, Y) ne transmette dans lintervalle de temps [t
0
-d(X,Z), t
0
+d(X,Z)]
et quaucun nud appartenant N
2Saut
(X, Y) ne transmette dans lintervalle de temps [t
0
- Tp
max
, t
0
+
Tp
max
]. La probabilit quaucun nud ne transmette dans lintervalle de temps [(t
0
-t
Z
)-d(X,Z), (t
0
-
t
Z
)+d(X,Z)] est gale ( ) ( )
( )
Y X N i
Saut
Saut
i P
,
1
1
1 . De mme, la probabilit quaucun nud ne transmette
dans lintervalle de temps [(t
0
-t
Z
)- Tp
max
, (t
0
-t
Z
)+ Tp
max
] est gale
( ) ( )
( )
Y X N i
Saut
Saut
i P
,
2
2
1
.
La probabilit quun paquet ne subisse aucune collision durant sa transmission revient calculer la
probabilit quaucun nud quil soit un saut ou deux sauts ne transmette dans lintervalle de temps
correspondant la cration dune collision. Donc q= ( ) ( )
( )
( ) ( )
( )

Y X N i
Saut
Y X N i
Saut
Saut Saut
i P i P
,
2
,
1
2 1
1 1 .
Il reste plus qu en dduire P
C
(X) = p = 1-q = ( ) ( )
( )
( ) ( )
( )
|
|
\
|

Y X N i
Saut
Y X N i
Saut
Saut Saut
i P i P
,
2
,
1
2 1
1 1 1 .

78
A partir de la proprit 4-9, il est possible de dduire les diffrents paramtres influant sur le nombre
de collisions. En effet, plus la probabilit dobtenir au moins une collision est leve plus grand est le
nombre de collisions sur le rseau. Les diffrents paramtres agissant sur la cration des collisions
sont :
le nombre de nuds voisins ( un saut ou deux sauts)
le dlai de transmission du paquet (fonction de sa longueur et de la capacit du support de
transmission)
Taux darrive des paquets et espacement entre les paquets (charge du lien)
le dlai de propagation
Dans la suite, nous nintgrons pas le dlai de propagation cause de son importance ngligeable dans
le contexte de nos travaux. Nous nous concentrons par consquent sur le nombre de nuds dans le
voisinage du nud metteur, le dlai de transmission du paquet et la charge dun lien.
Lorsquun paquet veut aller dun point source vers un point de destination, il emprunte une route
stendant sur plusieurs sauts c'est--dire traversant plusieurs liens. Par consquent suivant la longueur
du chemin emprunt par les paquets, le comportement du rseau peut varier. La longueur du chemin
sera donc le dernier paramtre dont nous tiendrons compte pour diminuer le nombre de collisions dans
un rseau MANET.
4.2.1.1 Nombre de nuds voisins
Le nombre de nuds voisins dun lien joue un rle important sur la russite de la transmission. En
effet, lorsque le nombre de nuds voisins est important la probabilit dobtenir une collision crot.
Bien entendu, le nombre de nuds deux sauts du nud metteur est plus dommageable sur la
russite de transmission du paquet car lintervalle de temps durant lequel peut se produire une
collision est plus lev. Le fait que les nuds voisins interviennent sur la probabilit de collision peut
facilement tre dmontr partir de la proprit 4-9. En effet, lorsque le nombre de nuds un saut
ou deux sauts tend vers linfini, la probabilit davoir une collision est logiquement gale 1.
Dmonstration :
Daprs la proprit 4-9, P
C
(X) = ( ) ( )
( )
( ) ( )
( )
|
|
\
|

Y X N i
Saut
Y X N i
Saut
Saut Saut
i P i P
,
2
,
1
2 1
1 1 1 . A partir de ce rsultat,
nous en dduisons lvolution de la probabilit sur un lien <X, Y> lorsque |N
1Saut
(X, Y)| ou
|N
2Saut
(X, Y)| .
Dans le cas o N
1Saut
(X, Y) :

79
Comme 0P
1Saut
(i)1 alors
( ) ( )
( )
0 1
,
1
1

Y X N i
Saut
Saut
i P
donc
( ) ( )
( )
( ) ( )
( )
0 1 1
,
2
,
1
2 1
|
|
\
|

Y X N i
Saut
Y X N i
Saut
Saut Saut
i P i P

Par consquent P
C
(X) = 1.
Dans le cas o N
2Saut
(X, Y) :
Comme 0P
1Saut
(i)1 alors
( ) ( )
( )
0 1
,
2
2

Y X N i
Saut
Saut
i P
donc
( ) ( )
( )
( ) ( )
( )
0 1 1
,
2
,
1
2 1
|
|
\
|

Y X N i
Saut
Y X N i
Saut
Saut Saut
i P i P

Par consquent P
C
(X) = 1.

Le protocole de routage doit donc tenir compte du nombre de nuds voisins des liens lorsquil choisit
sa route. Le protocole de routage choisissant le plus court chemin (SP) ou le protocole AODV ne
tiennent pas compte dun tel critre. Par consquent, ces protocoles peuvent utiliser un chemin dont les
nuds dun lien se situent dans une zone dense tant de ce fait plus sujets aux collisions.

Figure 4-3 : Slection dun chemin possdant 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 nuds voisins est la plus
faible. Le protocole de routage retournant le chemin possdant le moins de sauts (SP) et le protocole
de routage AODV ne tiennent pas compte de ce critre. Lexemple de la figure 4-3 compare les
chemins retourns entre le protocole de routage optimal et le protocole de routage SP. Dans cet
exemple, un rseau de 10 nuds est utilis. Un chemin doit tre cr entre le nud S et D en utilisant
deux protocoles diffrents, le protocole optimal et le protocole SP. Le protocole SP retourne un
chemin de deux sauts <S, C, D>. Ce chemin possde comme nuds voisins la totalit des nuds
prsents sur le rseau c'est--dire 10 nuds. Le chemin retourn par le protocole optimal possde trois
sauts <S, A, B, D>. Le nombre de voisins de ce chemin slve 7 nuds (S, A, B, D, E, C et H). Par
consquent, choisir le chemin le plus court ne permet pas toujours davoir le nombre de voisins le plus
faible.
4.2.1.2 Dbit de transmission
Le dbit de transmission joue aussi un rle important sur lapparition de collisions. Dans un rseau
MANET de type IEEE 802.11, plusieurs standards se ctoient. En effet, les standards les plus rcents
sont compatibles avec les anciens standards. On considre un nud X possdant une carte IEEE
802.11g avec un dbit thorique de 54Mbps, et un nud Y possdant une carte compatible seulement
avec le premier standard IEEE 802.11 avec un dbit thorique de 2Mbps. Lorsque le nud X transmet
un paquet sur le lien <X, Y> il doit obligatoirement transmettre ce paquet un dbit de 2Mbps pour
quil puisse tre correctement compris par Y. Le dbit de transmission sur un lien <X, Y> not C
<X, Y>

est calcul avec la formule suivante :
C
<X, Y>
= min(C
X
, C
Y
) (4-2)

Figure 4-4 : Temps dmission dune trame IEEE 802.11b
Lors de lmission dun paquet, la couche MAC IEEE 802.11b ajoute un entte au paquet reu de 30
octets et un CRC de 4 octets. Ensuite, la couche physique ajoute son tour un entte de 192s ou 96s
la trame quil reoit de la couche MAC. La figure 4-4 montre ces diffrents temps. Le temps
dmission dune trame est fonction de sa taille et du dbit de transmission du lien sur lequel il est
transmis. En supposant deux nuds X et Y avec un dbit de transmission respectif C
X
, C
Y
, on peut
dduire partir de la formule (4-2) le temps de transmission dun paquet de taille S (not t
S
) sur le lien
<X, Y> avec la formule suivante :
> <
+
+ =
Y X
E
C
S
S t
,
34
192 ) ( (4-3)

81
A partir de lquation (4-3), on peut dterminer le temps dmission pour un paquet S de taille 1500
octets suivant diffrents dbits de transmission sur le lien. Le tableau suivant donne ces temps.
Le Tableau 1 montre que le temps dmission dun paquet se dgrade rapidement avec la diminution
du dbit de transmission. Emprunter un lien ayant un dbit de transmission faible va empcher durant
un laps de temps important les autres stations dans le voisinage direct du nud metteur de transmettre
un quelconque paquet. Si ces nuds ont un dbit de transmission bien plus lev, la bande passante
disponible du rseau en ptira car une grande partie de la bande passante ne sera utilise que pour
mettre un paquet.
Le temps dmission dun paquet influe aussi sur les collisions. En effet, lintervalle de temps o peut
se produire une collision est plus important pour les nuds situs deux sauts du nud metteur
(proprit 4-9).
Dbit de transmission Temps dmission 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 dmission dun paquet de 1500 octets en fonction de diffrents dbits de
transmission.
Le protocole de routage optimal doit ainsi privilgier les liens possdant un dbit de transmission
lev. Choisir de telles routes permet une augmentation de la bande passante utile du rseau et une
diminution de la probabilit de subir une collision lors de lmission dun paquet.
4.2.1.3 Charge dun lien
La charge dun lien impacte aussi le nombre de collisions. De fait, les collisions apparaissent plus
frquemment sur un lien surcharg (proprit 4-9). Pour tudier leffet de la charge dun lien sur la
cration des collisions, nous avons ralis des simulations laide du simulateur NS-2. Pour cela, nous
avons simul un rseau compos de 4 nuds qui sont tous interconnects entre eux. Trois des nuds
envoient la mme quantit dinformations sur le quatrime nud. Les nuds ne bougent pas, car le but
de ces simulations est de voir leffet de la charge dun lien sur les collisions dans le pire des cas. Les
nuds se trouvant tous porte radio, le problme des nuds cachs ne se pose pas ici. Chaque nud
metteur utilise un trafic de type CBR dont la taille des paquets est gale 512 octets. La dure des
simulations est de 2000 secondes.

82

Figure 4-5 : Charge transmise en fonction de la charge soumise sur le mdium pour des nuds ayant
un dbit de transmission gal 1 Mbps ou 2 Mbps.
Les simulations ont t ralises en utilisant deux dbits de transmission diffrents. Dans le premier
cas, le dbit de transmission est de 1 Mbps et dans le second, il slve 2 Mbps. Utiliser diffrents
dbits de transmission permet de valider les rsultats quelque soit le type de standard IEEE utilis. Le
dbit total du rseau reprsente la somme des dbits dmission de paquets de chaque nud.
Nous tudions diffrents paramtres (le nombre de paquets mis, le nombre de collisions subies, le
nombre de paquets supprims) en fonction du dbit total transmis sur le rseau. La figure 4-5 compare
la charge transmise en fonction de la charge soumise sur le rseau.
Avec un dbit de transmission de 1 Mbps, la bande passante mise crot linairement jusqu une
charge atteignant 750 Kbps. Le fait que la pente croit plus vite entre 150 Kbps et 300 Kbps est d au
fait quon double la charge alors que la mme chelle est conserve. Par contre, partir de 750 Kbps,
le nombre de paquets mis stagne. Le rseau a atteint sa charge maximale, il ne peut transmettre plus
de paquets. En effet, lobtention du support est de plus en plus difficile acqurir puisque chaque
nud metteur essaie dy accder en mme temps, ou voit son mission retarde du fait que le support
soit dj occup. La bande passante mise ne diminue pas lorsque la charge maximale du rseau est
atteinte car le nombre de nuds en contention est trop faible. Ainsi dans un tel rseau, le temps de
backoff joue correctement son rle car chaque nud attend un temps alatoire diffrent des autres.
Avec un dbit de transmission de 2 Mbps, la bande passante mise crot linairement jusqu atteindre
une charge de 1200 Kbps. A partir de cette charge, le rseau a atteint sa capacit maximale
dacceptation des paquets. Compar au dbit de transmission 1 Mbps qui atteint sa capacit
maximale 75% du dbit de transmission, le rseau atteint ici sa capacit maximale 60% du dbit de
transmission. La diminution de la capacit maximale peut sexpliquer du fait qu 2 Mbps, les nuds
envoient toujours lentte de la couche physique (PLCP Preamble et PLCP Header) 1 Mbps
rduisant lgrement lefficacit du rseau. En accroissant le dbit de transmission des nuds, ce
phnomne 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
C
h
a
r
g
e

t
r
a
n
s
m
i
s
e

(
K
b
p
s
)

83

Figure 4-6 : Nombre de collisions subies par le rseau en fonction du dbit total des nuds avec un
dbit de transmission gal 1 Mbps ou 2 Mbps.
La figure 4-6 reprsente lvolution du nombre de collisions sur le rseau en fonction du dbit total
support. Dans un premier temps, nous tudions les rsultats pour un dbit de transmission de 1 Mbps.
Lorsque la charge est faible, le nombre de collisions subies par le rseau est proche de 0. Chaque nud
peut accder son tour facilement au support, outre les quelques transmissions se produisant en mme
temps crant quelques collisions. A partir de 600 Kbps, le nombre de collisions commence crotre
cause de la charge du rseau. A partir de 750 Kbps, le rseau seffondre dun 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 dbit de transmission de 2 Mbps, les mmes constats peuvent tre faits. A faible charge, les
collisions sont quasiment inexistantes, alors quelles atteignent un seuil lorsque la charge du rseau est
maximale.
Le dernier schma (figure 4-7) reflte ltat du rseau suivant le nombre de paquets supprims. La
suppression des paquets intervient lorsque la file dattente contenant les paquets de la couche rseau
est pleine. Lorsquun nud ne peut pas accder au support, la taille de la file de ses paquets en attente
crot. La file utilise lors de ces simulations est une file FIFO, cest--dire que le premier arriv est le
premier sorti. Pour chaque nud, la taille de la file dattente est de 50 paquets. Lorsque cette file
dattente dborde, les derniers paquets arrivs sont supprims. Dans un premier temps, les rsultats
sont interprts pour un dbit de transmission de 1 Mbps. Jusqu 600 Kbps, la file dattente reste vide.
Le rseau peut supporter la charge quil reoit et la longueur de la file dattente suffit pour contenir les
paquets pendant que le support est occup. Par contre partir de 750 Kbps, la file dattente ne peut
plus contenir le trafic mis par le nud. Dans un tel cas, les paquets sont supprims puisque le support
est difficilement accessible et le nombre de collisions levs entrainant dimportantes retransmissions.
Les retransmissions diminuent la bande passante utile du rseau. Au-del de 750 Kbps, le rseau tant
satur le nombre de paquets supprims est plus important puisquil arrive chaque nud un nombre
plus important de paquets mettre. Les mmes interprtations peuvent tre faites pour un dbit 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
Dbit (Kbps)

84
transmission de 2 Mbps. Les paquets commencent tre supprims partir de 1,2 Mbps (lorsque la
charge du rseau est maximale).

Figure 4-7 : Nombre de paquets supprims en fonction du dbit total des nuds avec un dbit de
transmission gal 1 Mbps ou 2 Mbps
Comme le rseau ne peut accepter un plus grand nombre de paquets transmis, les paquets supprims
ne cessent de crotre avec laugmentation du dbit des flux.
Ces simulations ont confirm les rsultats obtenus en calculant la probabilit dobtenir une collision.
En effet, lorsque la charge dun lien crot, les collisions sur le voisinage deviennent problmatiques.
Les simulations ont montr que lapparition des collisions dbute partir dun certain seuil. Pour un
rseau 1Mbps (respectivement 2Mbps), ce seuil est atteint pour une charge de 750Kbps
(respectivement 1,2Mbps). A partir de 60% du dbit de transmission dun lien, les collisions
deviennent trop importantes. Emprunter de tels liens ne fait quaugmenter le nombre de paquets
supprims en file dattente. 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 dun chemin
Dans certains cas, prendre le chemin le plus court peut revenir au mme que slectionner le chemin
ayant le plus faible nombre de voisins. En effet, lorsque les nuds sont uniformment distribus dans
le rseau, chaque nud possde quasiment le mme nombre moyen de nuds dans son voisinage.
Pour dterminer le nombre de nuds moyens dans son voisinage direct, il faut au pralable calculer la
probabilit quun nud se situe dans la zone de couverture dun autre nud. Pour cela, on suppose
que les nuds sont uniformment rpartis dans une zone dont la surface est note A
G
. La probabilit
quun nud x se situe dans la zone de couverture de rayon R dun nud i (not A
i
) est donne 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
P
a
q
u
e
t
s

s
u
p
p
r
i
m
s

(
K
b
p
s
)

85
( )
G
i
G
G i
i
A
A
A
A A
A x P =
= (4-4)
o A
i
A
G

En connaissant la probabilit quun nud soit dans la zone de couverture dun nud i, le nombre
moyen de nuds dans le voisinage de i peut tre calcul. Pour un rseau compos de N nuds, on peut
dduire de lquation (4-4) que le nombre moyen de nuds N(i) dans A
i
. N(i) est calcul grce la
formule suivante :
N(i) = NP(xA
i
) (4-5)
Par consquent daprs la formule (4-5), si on suppose que tous les nuds sont identiques c'est--dire
quils possdent le mme rayon R et que le nud nest pas situ en bordure de zone, alors le nombre
moyen de nuds dans son voisinage est le mme.
Lorsque les nuds sont uniformment rpartis dans la zone o ils se situent, le protocole de routage
optimal peut choisir le plus court chemin plutt que le chemin possdant le plus faible nombre de
voisins. Souvent pour dterminer le nombre de voisins, il est ncessaire dutiliser des informations de
gestion du voisinage diminuant de ce fait la bande passante utile du rseau. Dans de telles
circonstances, une telle solution est donc privilgier.
4.2.2 Consquences
Les collisions ont de fcheuses consquences sur le bon comportement dun rseau MANET. Elles
rduisent la bande passante disponible du rseau. Comme une collision entraine la retransmission de la
trame, jusqu un certain seuil, elle entraine donc une diminution de la bande passante disponible ainsi
quune augmentation du dlai dattente des paquets suivants. En effet, les paquets en file dattente
doivent patienter un certain laps de temps avant que leur tour narrive. Les collisions augmentent donc
ce laps de temps.
Le temps pour transmettre correctement un paquet de donnes t
TC
est fonction de nombreux facteurs.
En premier lieu, ce temps doit tenir compte du temps de transmission du paquet. Le temps de
transmission t
S
est le temps mis pour transmettre lensemble des bits du paquet. Ce temps est fonction
de la capacit du canal. De mme, ce temps doit prendre en compte le temps dvitement de collision
t
CA
(tel que par exemple DIFS pour couter que le support est libre), ainsi que le temps de dtection de
non rception dun acquittement t
CD
. Une collision est dtecte lorsque le nud metteur ne reoit pas
dacquittement, ainsi il doit attendre un certain laps de temps aprs la transmission de la totalit de la
trame pour recevoir lacquittement (SIFS + temps de propagation). Sil nest pas reu dans un tel laps
de temps cest quune collision est survenue. Enfin, il doit tenir compte du temps ajout par le surcot
t
overhead
entrain par lutilisation des paquets RTS/CTS sils sont utiliss ainsi que du backoff TB qui est
un surcot de temps entre deux retransmissions conscutives. Le temps pour transmettre correctement
un paquet peut donc tre donn par la formule suivante, en supposant quil ncessite R transmissions
[KAZ 02-1] :

86
( ) ( )

=
+ + + + =
R
r
r overhead CD CA S TC
TB R t t t t p t
1
(4-6)
Il est possible partir de lquation (4-6) dobtenir la bande passante ncessaire la transmission
correcte dun paquet de donnes de taille S. Cette bande passante est reprsente par la formule
suivante :
( )
( ) p t
S
p nte BandePassa
TC
= (4-7)
La formule (4-7) montre que les collisions jouent un rle important dans la consommation de bande
passante dun rseau MANET. Il est par consquent important de diminuer un tel nombre lorsque la
charge du rseau savre raisonnable pour accrotre la bande passante disponible et diminuer le temps
pass en file dattente par un paquet.
Un paquet en file dattente doit attendre la transmission de la totalit des paquets qui sont avant lui
avant de pouvoir tre transmis. En supposant une file dattente maximale de q paquets, le temps
dattente maximal dun paquet est reprsent par la formule suivante :
( ) ( )

= =
+ + + + =
q
i
R
r
r i overhead CD CA S
i
TB R t t t t p D
1 1
(4-8)
o R
i
est le nombre de transmission du i
me
paquet.
Lquation (4-8) montre bien limpact que peuvent avoir les collisions sur le dlai pass en file
dattente par un paquet lors de la rception dune rafale. Le dlai en attente dun paquet varie
normment entre un support subissant peu de collisions et un support trs collisionn.
4.3 Protocole de routage
Dans cette section, nous proposons un protocole de routage [ESP 06-1] dans le but damliorer la
bande passante dun rseau MANET. Un flux de donnes est form par les paquets possdant le mme
couple (source, destination). Quand un flux traverse un chemin P, il interagit avec les flux dans le
proche voisinage des nuds qui composent P (cf. 4.2.1.1). Offrir une bande passante plus leve aux
diffrents flux traversant le rseau permet un meilleur fonctionnement dapplication gourmande en
bande passante, ou permet daccepter plus de flux.
Pour accrotre la bande passante, notre protocole de routage amliore la bande passante sature du
rseau [WAN 02-1]. La bande passante sature B
S
est la bande passante minimale sur un lien quand
tous les flux traversant ce lien ont la mme bande passante. Elle est reprsente sur un graphe G(V, E)
par la fonction suivante :
|
|
\
|
= > <
+
+
i
i i
i
s i i
N
b
B E
1 ,
1
min , v , v
(4-9)

87
o b
i,i+1
la capacit du lien <v
i
, v
i+1
> et N
i
le nombre de flux traversant ce lien.
Un protocole de routage doit maximiser cette bande passante pour tre vraiment efficace. La bande
passante sature est maximise si le protocole de routage retourne la bande passante sature la plus
leve, note B
max
. B
max
peut tre obtenue partir de la formule suivante :
( )
n
R
s
R
s
B B B ,..., max
1
max
= avec R
1
,,R
n
lensemble des protocoles de routage dpourvus de boucle pour
un rseau donn, et
k
R
s
B est la bande passante sature retourne par le protocole R
k
..
Par consquent, le protocole R
i
qui retourne B
max
est appel protocole optimal [WAN 02-1]. La
complexit pour trouver le protocole qui maximise la bande passante sature est NP-difficile
[KLE 99-1]. Ce problme est appel le problme Optimal de la classe de trafic Premium pour un
protocole de Routage (OPR). Dans les rseaux MANETs, les collisions peuvent interagir avec les
paquets transmis et la capacit dun lien est fonction du dbit de transmission des nuds du lien
(cf. 4.2.1.2). Par consquent nous modifions la dfinition de la bande passante sature de telle
manire que les collisions soient prises en compte. La bande passante sature est dornavant
reprsente avec la formule suivante :
( )
|
|
\
|
=
> + <
+
i
c i i
i
s i i
N
B C
B V v v
1 ,
1
min , , (4-10)
o C
<i, i+1>
le dbit de transmission du lien <i, i+1>, N
i
le nombre de flux traversant le lien <i, i+1> et
B
c
la bande passante consomme par les collisions.
Nous proposons un protocole de routage bas sur AODV. Durant la phase de dcouverte des routes,
notre protocole de routage slectionne un chemin partir dune fonction poids. Cette fonction poids a
la particularit de diminuer le nombre de collisions. De fait, notre protocole augmente la bande
passante du rseau. Nous proposons deux fonctions poids permettant dagir sur les facteurs gnrant
des collisions. La premire fonction poids se base sur la bande passante collisionne subie par un
nud pour slectionner les chemins. La deuxime fonction poids se base sur de nombreux facteurs
pour rduire la bande passante consomme par les collisions.
4.3.1 Fonction poids numro 1
La fonction poids numro 1 permet de rduire la bande passante consomme par les collisions. Elle
utilise diffrentes mtriques pour raliser cet objectif. Cette fonction poids combine lensemble de ces
mtriques pour slectionner un chemin. La fonction poids obtenue est non-linaire.
4.3.1.1 Mtriques utilises
Notre protocole utilise une fonction poids pour dterminer la qualit des chemins. Cette fonction
utilise trois sortes de mtriques : le dbit de transmission, la bande passante ayant subi des collisions et

88
le nombre de nuds. Ces trois mtriques sont connues sans ncessiter lchange dinformations de
contrle sur la gestion des voisins. Ces mtriques sont calcules comme suit :
Dbit de transmission ou capacit dun lien : la capacit dun lien est donne par lquation (4-2)
(cf. 4.2.1.2).
Bande passante consomme par les collisions : dans le standard IEEE 802.11, les nuds dtectent
une collision si un acquittement nest pas reu aprs la transmission dun paquet de donnes. Nous
utilisons cette mthode pour calculer la bande passante ayant subi des collisions. Quand un paquet est
envoy, lacquittement doit tre reu dans une dure t
CD
= 2t
p
+ t
SIFS
+ t
ACK
secondes, o t
p
est le temps
de propagation entre les deux nuds, t
SIFS
le temps inter-trame le plus faible et t
ACK
le temps pour
transmettre lacquittement. Par consquent, un nud metteur dtecte la prsence dune collision sil
ne reoit pas dacquittement au bout de t
CD
units de temps. Les paquets de contrle subissant des
collisions (RREQ, RREP, ) ne sont pas comptabiliss puisque ce type de paquets est diffus et le
nud metteur nattend pas dacquittement.
Daprs la formule (4-7) (cf. 4.2.2), on peut dduire la bande passante ayant subi des collisions pour
chaque paquet k de la faon suivante :
( ) ( ) ( )
=
>
+ + + + =

=
1 si 0
1 si
1
1
1
k
k
R
r
r k overhead CD CA S
k
coll
R
R
TB R t t t t
S
k Bandwidth
k
k
(4-11)
o S
k
est la taille du paquet k et R
k
le nombre de retransmission.
Par consquent, si un nud v
i
transmet m paquets par seconde, la bande passante ayant subi des
collisions pour ce nud est calcule avec la formule suivante :
( )
=
=
m
k
coll coll
k Bandwidth Bandwidth
1
(4-12)
Nombre de nuds : cette mtrique est largement employe par le protocole de routage AODV. Elle
reprsente le nombre de nuds dun chemin. Pour un chemin P=(v
1
, ,v
n
), le nombre de nud est
nombre_nud = = 1 P n-1.
4.3.1.2 Fonction poids utilise
La fonction poids utilise est fonction de diffrents paramtres vus au chapitre 4.2.1 pour diminuer le
nombre de collisions et augmenter la bande passante sature du rseau.
Dans un premier temps, notre fonction poids tient compte de la capacit du lien. Emprunter un lien de
capacit plus importante permet de rduire le nombre de collisions et surtout permet de transmettre
plus de paquets dans la mme unit de temps que pour un lien de capacit plus faible. Dans [MA 97-1],

89
les auteurs utilisent une fonction, qui applique lalgorithme de Dijkstra, donne le chemin possdant
la bande passante la plus leve. Pour un chemin P=(v
1
, , v
n
), cette fonction est la suivante :
( )

=
+
=
1
1
1 ,
1
w
n
i
i i
b
P
(4-13)
o b
i,i+1
la capacit nominale du lien (v
i
, v
i+1
).
Cette fonction permet de dterminer 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 nest pas suffisante.
Notre fonction poids doit aussi prendre en compte le nombre de nuds du chemin (cf. 4.2.1.4). Notre
fonction poids pnalise linairement les chemins en fonction de leur longueur. La fonction poids de la
formule (4-13) est modifie, en consquence, pour prendre en compte ce critre :
( )

=
+
=
1
1
1 ,
w
n
i
i i
b
i
P
(4-14)
Rduire la longueur du chemin a un impact sur le nombre de collisions. La charge du lien est aussi un
lment important dont il faut tenir compte (cf. 4.2.1.3). Le nombre de paquets subissant des
collisions augmentent, partir dun certain seuil, exponentiellement avec laugmentation de la charge
du rseau. Par consquent, un flux traversant un chemin satur (c'est--dire possdant un nombre
important de collisions) voit ses paquets mis collisionns ou supprims cause dune file dattente
des paquets pleine. Sur un chemin, le nud qui a subi le plus de collisions, c'est--dire qui a la bande
passante ayant subie des collisions la plus importante, est le nud 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 PB
c
et calcul avec la formule suivante :
=(v
1
,,v
n
),
|
|
\
|
=
n n
n
c c
c
b
b
b
b
PB
, 1 2 , 1
2
, , max K
(4-15)
o
i
c
b dsigne la bande passante ayant subi des collisions du nud v
i
et b
i,i+1
la capacit du lien
<v
i
, v
i+1
>.
Le calcul de PB
c
en ltat actuel ne peut pas pnaliser directement le chemin. En fait, une fonction
exponentielle f(PB
c
) doit pnaliser la fonction poids et f(PB
c
)[1,[. f(PB
c
)=1 quand le chemin na
subi aucune collision (aucune pnalisation nest apporte par les collisions) et ( )
c
PB f quand le
chemin traverse un nud dont la bande passante ayant subi des collisions est gale la capacit du
lien. La fonction suivante correspond ces critres et est donc approprie :

90
=(v
1
,,v
n
),
( )
c
c
PB
PB f
=
1
1
(4-16)

Ainsi, la fonction poids de lquation (4-14) peut tre modifie de telle faon quelle pnalise
exponentiellement le nombre de collisions subies par un nud. Pour un chemin P=(v
1
,,v
n
), la
fonction poids utilise est la suivante :
( )
|
|
\
|
=
+
n n
n
c c
n
i
i i
b
b
b
b
b
i
P
, 1 2 , 1
2
1
1
1 ,
, , max 1
w
K
(4-17)
A partir dune telle fonction, le protocole de routage est capable de dterminer une route dont la
prsence dun nouveau flux a peu dimpact sur le nombre de collisions (tant que la charge du rseau
est raisonnable).
Initialement, rien ne laissait envisager que lutilisation dune telle fonction poids soit moins
performante que le protocole AODV lui-mme. Les simulations ralises (cf. 4.3.5) ont mis en
vidence quune pnalisation 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 dun lien. En outre, lorsque des collisions apparaissent le lien est dj en surcharge. De fait, la
bande passante ayant subi des collisions commence crotre alors que la charge du lien est dj
importante. Devant un tel problme, 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 numro 2
La fonction poids numro 2 permet, aussi, de rduire la bande passante consomme par les collisions.
Elle agit sur les diffrents facteurs causant des collisions (cf. 4.2.1). Diffrentes mtriques sont
utilises pour reprsenter ces facteurs. Cette fonction poids est non-linaire.
4.3.2.1 Mtriques
La fonction poids numro 2 utilise trois mtriques pour slectionner un chemin. Ces trois mtriques
sont : la bande passante disponible, la capacit dun lien et le nombre de nuds voisins. La bande
passante disponible peut tre obtenue partir dun modle destimation non-intrusif, de mme que la
capacit dun lien. Par contre pour quun nud dtermine ses voisins, un modle intrusif doit tre
utilis pour tre suffisamment reprsentatif tout instant. Ces mtriques sont calcules comme suit :
Bande passante disponible : la bande passante disponible est obtenue partir de la mthode
destimation de Kazantsidis et al [KAZ 02-1]. Cette mthode fournit la couche rseau la bande
passante disponible partir de mesures de la couche MAC et LLC. La bande passante disponible est

91
obtenue partir du taux dutilisation de la file dattente employe par la couche LLC. Le temps durant
lequel la file dattente est vide reprsente le temps de non-utilisation du support. La bande passante
disponible sur un lien <i, i+1> est note bd
i, i+1
.
Capacit dun lien : la capacit dun lien est obtenue partir de lquation (4-2) (cf. 4.2.1.2). La
capacit dun lien <i, i+1> est note C
<i, i+1>
.
Nombre de nuds voisins : chaque nud du rseau dtermine le nombre de nuds situs dans son
voisinage en changeant priodiquement des paquets HELLO. Chaque nud maintient une table des
nuds voisins. A la rception dun paquet HELLO mis par X, un nud ajoute dans sa table des
nuds voisins lidentifiant de X. Si un nud ne reoit plus de paquet HELLO dun de ses voisins
durant un certain laps de temps, le lien est rompu et la table des nuds voisins est mise jour. Le
nombre de nuds voisins dun nud i est not N
1
(i).
4.3.2.2 Fonction poids utilise
La fonction poids utilise agit sur les diffrents facteurs provoquants des collisions. Lobjectif de cette
fonction poids est daccrotre la bande passante du rseau.
Dans un premier temps, la fonction poids numro 2 dtermine la charge dun chemin. La charge dun
chemin est obtenue grce la bande passante disponible sur chaque lien dun chemin. Plus la bande
passante disponible dun lien est proche de 0, plus la charge du lien est importante. Un lien avec la
bande passante disponible la plus faible dun chemin est le lien bloquant.
La charge dun lien joue un rle important dans loccurrence dune collision (cf. 4.2.1.3). De fait, la
fonction poids doit slectionner le chemin avec la bande passante disponible la plus leve. La
fonction poids suivante permet de retourner le chemin avec la bande passante disponible la plus
leve :
( )

= +
=
1
1 1
1
n
i i,i
bd
P w (4-18)
Lorsque la charge dun lien atteint un certain seuil, le lien est tellement surcharg que les nuds
gnrent de nombreuses collisions (cf. 4.2.1.3). Tout lien dont la charge dpasse ce seuil doit tre
vit. La fonction poids de la formule (4-18) est modifie pour tenir compte de ce critre :
( )
> > + <

=
+
= +
sinon
, 1 , si
1
1 ,
1
1 1
i i
n
i i,i
bd i i
bd P w
(4-19)
o est le seuil de charge quun lien du chemin ne doit pas dpasser.
La capacit dun lien joue un rle particulirement important dans le temps doccupation du support
pour la transmission dun paquet de donnes. Il est important de privilgier les liens avec un dbit de
transmission lev. La bande passante disponible dun lien est pnalise en fonction de sa capacit. Le

92
facteur pnalisant dun lien <i, i+1>, not
i, i+1
, est fonction du dbit 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 modifie pour prendre en compte ce facteur :
( )
> > + <

=
+
= + +
sinon
, 1 , si
1
1 ,
1
1 1 1 ,
i i
n
i i,i i i
bd i i
bd P f (4-20)
Le dernier facteur pris en compte par la fonction poids numro 2 est le nombre de nuds voisins. La
fonction poids est pnalise en fonction du cumul du nombre de nuds voisins de chaque nud
composant le chemin. La fonction poids numro 2 utilise par notre protocole de routage est la
suivante :
( )
( ) ( ) ( )
> > + <
=
=
+
= + + = =

sinon
, 1 , si
1
1 ,
1
1 1 1 , 1
1
1
1 i i
n
i i,i i i
n
i
n
i
bd i i
bd
i N P f i N
P w (4-21)
Cette fonction poids tient compte des diffrents facteurs causant des collisions. Le protocole de
routage utilise cette fonction poids pour slectionner un chemin lors de la phase de dcouverte des
routes.
4.3.3 Phase de dcouverte de route
La phase de dcouverte de route consiste trouver un chemin entre un nud source et un nud
destination. Pour cela, le nud source met une requte de cration de route, RREQ, et attend la
rception dune requte de confirmation, RREP. Notre protocole de routage est bas sur le protocole
AODV, dans la faon dont il dissmine linformation de routage et du fait quil utilise les mmes
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 requtes RREQ et RREP ainsi
que les champs composant les entres des tables.
Pour un sous-chemin P=(v
1
,,v
n
), une requte RREQ mise par le nud v
n
dans notre protocole
contient les champs suivants :
Adresse source
Adresse de destination
Numro de squence source (not nss)
Capacit de v
n

PB
c
(cf. quation (4-15)) si fonction poids numro 1 ou f(P) (cf. quation (4-20)) si fonction
poids numro 2

93
Nombre de sauts si fonction poids numro 1 sinon nombre de voisins des nuds du chemin
A la rception dune requte RREQ, le nud source conserve dans la table inverse des chemins le
couple (adresse source, adresse destination), le numro de squence source et le poids le plus faible.
Une requte RREP qui est transmise par un nud X contient les paramtres suivants :
Adresse source
Adresse de destination
nss
poids
Capacit de X
Quand un nud Y reoit une requte RREP (transmise par un nud X), il met jour sa table de
routage avec le couple dadresses, le nss, et le dbit de transmission B (cf. quation (4-2)). Les paquets
de donnes reus par Y dont le prochain nud est X sont transmis une vitesse B.
La phase de dcouverte des routes ncessite lutilisation de trois algorithmes suivant la position des
nuds sur le chemin (nud source, nud intermdiaire et nud destination).
4.3.3.1 Algorithme du nud source
La figure 4-8 donne lorganigramme utilis par le nud source pour la dcouverte dune route. Sil ne
possde pas dj une route, il transmet une requte RREQ aprs avoir initialis ses champs. Pour cela,
si la fonction poids numro 1 est utilise, le nombre de sauts est initialis 1 et PB
c
est initialis 0. Si
la fonction poids numro 2 est utilise, le nombre de voisins est initialis au nombre de voisins de la
source, et f(P) est initialis 0. Dans les deux cas, le nud source ajoute sa capacit de transmission.
Il dclenche un temporisateur Trep et attend une rponse RREP lui confirmant quune route est
trouve. Si Trep arrive chance, aucune route na t trouve. Dans ce cas, il refait sa tentative
Nrp
max
fois au maximum. Sil reoit une rponse RREP, il commence envoyer les paquets en attente
sur ce chemin. Le nud source peut recevoir plusieurs rponses RREP. Dans un tel cas, il slectionne
toujours le chemin ayant le plus faible poids.

94

Figure 4-8 : Organigramme excut par un nud source
4.3.3.2 Algorithme du nud intermdiaire
Lalgorithme excut par un nud intermdiaire est formalis par lorganigramme de la figure 4-9. A
la rception dune requte RREQ, le nud intermdiaire vrifie si la route inverse (route en direction
de la source) est plus rcente ou de mme ge mais avec un poids plus faible. Dans ces deux cas, le
nud met jour sa table des chemins inverses et propage la requte RREQ aprs avoir mis jour ses
champs.
A la rception dune rponse RREP, le nud met jour sa table de routage (en y ajoutant la route si
ncessaire) si le poids de la route est plus faible ou la route est plus rcente. Il consulte sa table des
chemins inverses pour obtenir le nud qui propager la rponse RREP et la propage. Dans le cas o
la route est obsolte, la requte est supprime.
Traitement des donnes
DEBUT
- Crer un RREQ
- Gnrer un nouveau
numro de squence
- Mettre jour les champs
de la requte
- Diffuser RREQ
- Armer le temporisateur
Trep
RREP reu?
- Arrter Trep
- Envoyer les
donnes
oui
non
Trep expir?
non
oui
Nrp++
Nrp Nrp
max
?
oui
non
Informer la couche suprieure
Phase de
traitement des
donnes
Transmission des
donnes
RERR reu?
une route?
oui non
oui non

95

partie diffrente de notre protocole compar au protocole AODV.
4.3.3.3 Algorithme du nud de destination

diffrente de notre protocole compar au protocole AODV.

96
Lalgorithme employ par la destination est prsent par la figure 4-10. A la rception dune requte
RREQ, la destination vrifie que la route obtenue est plus rcente ou possde un poids plus faible.
Dans ces deux cas, la destination met jour sa table des chemins inverses et envoie une rponse RREP
en direction de la source. Si la requte RREQ est obsolte, elle est supprime.
4.3.4 Maintenance des routes
La phase de maintenance des routes est identique celle utilise par le protocole AODV. Lorsquun
nud dtecte la rupture dun lien, il met en direction des sources (dont le trafic le traverse) un paquet
de notification de la rupture RERR. A la rception de ce paquet, un nud intermdiaire supprime de sa
table de routage la ligne vers les directions affectes. Lorsquun nud source reoit un tel paquet, elle
recre les routes si ncessaire.
4.3.5 Analyse de performance
Pour vrifier le comportement de notre protocole de routage, nous analysons ses performances par
simulation. Le simulateur employ est le simulateur NS-2. Les simulations sont effectues en
comparant lefficacit de notre protocole avec les protocoles AODV et AODV avec gestion de
lenvironnement (nomm AODV Hello). Notre protocole utilisant la fonction poids numro 1
(respectivement numro 2) est not protocole 1 (respectivement protocole 2).
Nous simulons ces protocoles sur diffrentes topologies o le nombre de nuds prsents sur le rseau
varie. Les nuds possdent diffrents dbits de transmission. Par dfaut, 50% (respectivement 20% et
30%) des nuds possdent un dbit de 1 Mbps (respectivement 11 Mbps et 54 Mbps). Les requtes
RREQ (ncessaires la dcouverte dune route) et les paquets Hello (ncessaires aux protocoles
AODV Hello et au protocole 2) sont changs 1 Mbps. Ces paquets ne sont pas comptabiliss dans
la bande passante ayant subi des collisions puisquun nud metteur nest capable de dtecter une
collision uniquement sil ne reoit pas dacquittement. Les collisions releves dans nos simulations
portent seulement sur les paquets de donnes changs ou relays. La dure des simulations est de 500
secondes. La simulation utilise un modle de communication dans lequel la moiti des nuds
communiquent avec lautre moiti. Chaque flux possde un dbit de 20Kbps.
Les protocoles AODV Hello et numro 2 utilisent une gestion locale de lenvironnement.
Priodiquement, les nuds changent un paquet Hello. Dans nos simulations, les nuds changent
toutes les 2 secondes un paquet Hello. La rupture dun lien est dtecte lorsquun nud ne reoit plus
de paquets Hello durant 6 secondes. Les deux autres protocoles sont prvenus par la couche MAC
lorsquun paquet na pas pu tre transmis durant un certain nombre de fois. Le nombre de
retransmissions slve 4 avant de dtecter quun lien est interrompu.
Dans un premier temps, les simulations sont effectues sur une topologie o les nuds sont fixes.
Nous faisons ce choix pour mettre en vidence le comportement de notre protocole suivant diffrents
paramtres (taille des paquets, variation du dbit des nuds) sans que la mobilit vienne interfrer.
Pour vrifier lefficacit de notre protocole, trois paramtres (la bande passante utilise par les paquets

97
de donnes, la bande passante ayant subi des collisions et la bande passante consomme par les
paquets RREQ) rvlent lefficacit dun protocole.

prsents sur le rseau. La taille des paquets est de 512 octets.
La figure 4-11 donne lvolution de la bande passante utilise par les paquets de donnes en fonction
du nombre de nuds et donc de la charge (puisque le nombre de flux transitant sur le rseau est moiti
moindre que le nombre de nuds prsents sur le rseau). Jusqu 100 nuds, la bande passante ne
cesse de crotre. 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 rgresse trs lgrement cause des
chemins emprunts avec un plus faible dbit. Par contre, la bande passante du protocole 2 crot
toujours pour atteindre 1 Mbps de plus quAODV et AODV Hello (lorsque 200 nuds sont prsents
sur le rseau).
Le manque defficacit du protocole 1 montre que la bande passante ayant subi des collisions nest pas
le critre adquat pour pnaliser un chemin. En effet, le nombre de collisions volue trs diffremment
avec la charge prsente sur le rseau. Lorsque la charge est faible, le nombre de collisions lest aussi.
Lorsque la charge atteint un certain seuil, le nombre de collisions crot rapidement. Dans un tel cas, le
chemin accept peut crer un goulet dtranglement rduisant le nombre de paquets de donnes. Le
nombre de collisions dun lien nest donc pas un bon indicateur de la charge prsente sur ce lien.
La figure 4-12 prsente lvolution de la bande passante utilise par les paquets de donnes (de taille
1500 octets) en fonction du nombre de nuds prsents sur le rseau. Chaque flux du rseau possde un
dbit de 20 Kbps. De fait, au lieu de transmettre 3 paquets par seconde comme dans la simulation
prcdente (figure 4-14), un seul paquet est transmis. Le protocole 2 est bien plus efficace que les
autres protocoles puisquil slectionne des chemins avec une capacit plus importante. La transmission
dun paquet de 1500 octets sur un lien de 54 Mbps est bien plus rapide puisquil ne ncessite la
transmission dun seul entte (transmis en un temps constant de 192 s quelque soit le dbit du lien).
Privilgier les liens possdant une capacit de transmission disponible importante accrot la bande
passante disponible du rseau confortant nos attentes initiales.
0
500
1000
1500
2000
2500
3000
3500
4000
30 50 75 100 150 200
B
a
n
d
e

p
a
s
s
a
n
t
e

c
o
n
s
o
m
m
e

p
a
r

l
e
s

p
a
q
u
e
t
s

d
e

d
o
n
n
e
s

(
K
b
p
s
)

98

prsents sur le rseau. La taille des paquets est de 1500 octets.
La figure 4-13 donne lvolution de la bande passante ncessaire la transmission des paquets de
donnes en fonction du nombre de nuds prsents sur le rseau. 50% (respectivement 30% et 20%)
des nuds ont une capacit de 54 Mbps (respectivement 11 Mbps et 1 Mbps). La bande passante du
rseau augmente pour chacun des protocoles. En effet, le nombre important de nuds, dont le dbit est
de 54 Mbps, profite lensemble des protocoles. Le nombre de paquets changs par le nud source
est fonction de sa capacit. En effet, un nud source, dont le dbit de transmission est de 1 Mbps,
limite le nombre de paquets sur un chemin. La rduction du nombre de nuds, dont le dbit est de
1 Mbps, augmente le nombre de paquets changs. Le protocole 2, prenant les chemins avec une
capacit leve, est efficace dans un tel environnement. Par contre, les protocoles AODV et AODV
Hello peuvent traverser un nud dont la capacit est un goulet dtranglement.

prsents sur le rseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des
nuds ont un dbit de 1Mbps (respectivement 11Mbps, 54Mbps).
La bande passante ayant subi des collisions est le deuxime critre pris en compte pour montrer
lefficacit dun 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 nuds prsents sur le rseau.
Bien que le protocole 2 augmente la bande passante utile du rseau, il cre moins de collisions que le
protocole AODV Hello jusqu 200 nuds. A 200 nuds, le protocole 2 nest pas limit par le seuil
atteint par les autres protocoles. De fait, le nombre de collisions crot et est suprieur celui du
protocole AODV Hello. Le protocole AODV et le protocole 1 crent moins de collisions car le
nombre de paquets de donnes changs est plus faible que pour les deux autres protocoles.

rseau. La taille des paquets est de 512 octets.
Laugmentation de la taille des paquets (figure 4-15) ne modifie pas le comportement des protocoles
compar la figure prcdente. Le protocole 2 cre moins de collisions que le protocole AODV Hello.
Lorsque lcart entre la bande passante des paquets de donnes changs devient plus important (au-
del de 150 nuds), le protocole 2 cre plus de collisions que les autres protocoles.

rseau. La taille des paquets est de 1500 octets.
La figure 4-16 illustre la variation de la bande passante ayant subi des collisions avec laugmentation
de la capacit des nuds. Le protocole 2 est, dans ce cas, particulirement efficace. Bien quil
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 nuds

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 particulirement performant dans un tel
environnement.

rseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des nuds ont un
dbit de 1Mbps (respectivement 11Mbps, 54Mbps).
Le dernier critre pour mettre en vidence lefficacit de notre protocole est la bande passante
ncessaire la dcouverte et la maintenance des routes.
La bande passante consomme par les requtes est prsente sur la figure 4-17. Le protocole 2
ncessite moins de paquets RREQ que les autres protocoles. En fait, les protocoles avec une gestion
locale de lenvironnement sont moins sujets la perte errone dun lien. Le protocole AODV et le
protocole 1 dtectent la perte dun lien lorsquun paquet subit 4 checs de transmissions successives.
Avec les collisions, ce scnario se produit assez souvent et augmente le nombre de requtes
ncessaires la maintenance dune route pourtant toujours active. Les paquets Hello souffrent moins
de ce phnomne. Bien que les nuds transmettent ces paquets dans un intervalle de temps assez
proche les uns des autres, ils subissent moins de collisions. Ainsi, les nuds dtectent moins souvent
quun lien est rompu alors quen ralit il est toujours actif. Compar au protocole AODV Hello, les
nuds du protocole 2 crent moins de collisions la fois sur les paquets de donnes et sur les paquets
RREQ et Hello. Lors de ltablissement dune route, le protocole 2 ncessite plus de paquets RREQ
la dtermination dune route que les protocoles AODV et AODV Hello (un nud ne peut transmettre
quune seule fois un paquet RREQ). Sur la dure de la simulation, le protoocle 2 transmet moins de
paquets RREQ, car il dtecte moins souvent la perte errone dun lien. De fait, il compense largement
le surplus de paquets RREQ ncessaires la dtermination dune route.
Le protocole 1 ncessite un nombre consquent de requtes RREQ pour maintenir et dterminer les
routes. Bien quil dtecte aussi souvent que le protocole AODV la perte dun lien, le nombre de
requtes ncessaires la dtermination dune route est en moyenne 1,5 fois plus important quavec le
0
500
1000
1500
2000
2500
3000
3500
30 50 75 100 150 200

101
protocole AODV. La bande passante consomme par les requtes RREQ est un des facteurs qui rduit
drastiquement lefficacit du protocole 1.

sur le rseau. La taille des paquets est de 512 octets.

sur le rseau. 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 consomme par les paquets RREQ suit la mme progression que lorsque les
paquets ont une taille de 512 octets. Tout de mme, le protocole 2 tant plus performant avec de longs
paquets, la bande passante ncessaire lobtention 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 dune route
est moins frquente.
La figure 4-19 met en avant la bande passante ayant subi des collisions lorsque la capacit des nuds
est plus importante. Avec une capacit des nuds plus importante, la charge maximale du rseau 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
suprieure. De fait, le nombre de collisions est diminu et rduit la dtection dune fausse perte dun
lien. Le protocole 2 ncessite une bande passante moindre pour tablir et maintenir les chemins.

sur le rseau. La taille des paquets est de 512 octets et 20% (respectivement 30%, 50%) des nuds ont
un dbit de 1Mbps (respectivement 11Mbps, 54Mbps).
Pour vrifier lefficacit de notre protocole, nous considrons en dernier lieu le critre de la mobilit.
Lenvironnement de simulation reste identique celui des simulations prcdentes. Les nuds
utilisent un modle RWP (cf. 1.4) pour effectuer un dplacement. Entre chaque dplacement, les
nuds ont un temps de pause de 200 secondes.

Figure 4-20 : Bande passante consomme par les paquets de donnes en fonction de la mobilit des
nuds. Le rseau est compos de 50 nuds et la taille des paquets est de 512 octets.
La figure 4-20 montre la bande passante consomme par les paquets de donnes exempts de collisions.
A faible mobilit (2 m/s et 5 m/s), le protocole 2 est trs efficace et peu affect par la mobilit des
nuds. 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
B
a
n
d
e

p
a
s
s
a
n
t
e

c
o
n
s
o
m
m
e

p
a
r

l
e
s

r
e
q
u
t
e
s

R
R
E
Q

(
K
b
p
s
)
0
200
400
600
800
1000
1200
1400
1600
2 5 10 15 20
B
a
n
d
e

p
a
s
s
a
n
t
e

u
t
i
l
i
s
e

p
a
r

l
e
s

p
a
q
u
e
t
s

d
e

d
o
n
n
e
s

(
K
b
p
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 lenvironnement sont moins ractifs que
les protocoles bass sur les informations de la couche MAC pour dceler la rupture dun lien. En effet,
en utilisant les informations fournies par la couche MAC, il ne faut que 1 seconde pour dtecter la
rupture dun lien. Avec lutilisation dune gestion locale de lenvironnement, la dtection de la rupture
dun lien a lieu au bout de 6 secondes. Durant ce laps de temps les paquets continuent dtre transmis
sans pouvoir tre reus. Pour permettre au protocole AODV Hello et au protocole 2 dtre plus
efficaces dans un environnement hautement mobile, le temps entre lchange de deux paquets Hello
doit tre plus faible.

Figure 4-21 : Bande passante ayant subi des collisions en fonction de la mobilit des nuds. Le rseau
est compos de 50 nuds et la taille des paquets est de 512 octets.
La figure 4-21 montre lvolution de la bande passante ayant subi des collisions en fonction de la
mobilit des nuds. Quelle que soit la mobilit des nuds, les nuds utilisant le protocole 2 cre
moins de collisions que les nuds 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
sexplique principalement cause des paquets mis alors quun lien est rompu. Durant le laps de
temps prcdent la dtection de la rupture dun lien, il continue mettre. Ne recevant pas
dacquittement, il suppose que le paquet a subi une collision et le retransmet. De fait, la charge du
rseau augmente et le nombre de collisions crot.
La figure 4-22 met en vidence la bande passante consomme par les paquets RREQ en fonction de la
mobilit des nuds du rseau. Le protocole 2 a la bande passante la plus faible lorsque les nuds sont
faiblement mobiles. Lorsque la mobilit crot, le nombre de requtes est plus important quavec le
protocole AODV Hello. Le protocole 2 ncessite plus de requtes pour dterminer une route. Dans un
tel environnement, la dtection de la rupture dun lien est peu errone (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 consomme par les requtes en fonction de la mobilit des nuds. Le
rseau est compos de 50 nuds et la taille des paquets est de 512 octets.
4.4 Discussion
La bande passante consomme par les collisions rduit la bande passante du rseau. Les collisions
entranent des retransmissions et accroissent le dlai dattente des paquets de donnes (cf. 4.2.2). Le
protocole de routage doit tout mettre en uvre pour en diminuer limpact. Pour cela, le protocole de
routage doit prendre en compte les facteurs influant sur loccurrence dune collision.
Dans un premier temps, nous avons identifi ces facteurs. Ces facteurs sont (cf. 4.2.1) : le nombre de
nuds voisins, le dbit de transmission et la charge du lien. Dans un environnement o les nuds sont
uniformment rpartis, 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 rseau (cf. 4.3). Pour cela, nous avons propos deux fonctions poids
pnalisant diffrents facteurs pour rduire les collisions.
La premire fonction poids utilise trois mtriques pour slectionner un chemin : le nombre de sauts, la
bande passante collisionne dun nud et le dbit de transmission (capacit). Cette fonction pnalise
exponentiellement les liens dont la bande passante collisionne est importante. Les simulations ont
rvl que les facteurs utiliss par cette fonction poids ne sont pas adapts pour accrotre la bande
passante utile du rseau. Bien quune telle fonction slectionne les chemins avec la capacit la plus
leve, ce paramtre nest pas suffisant pour en amliorer pleinement lefficacit. De plus, la bande
passante ayant subi des collisions est un mauvais indicateur de la charge dun lien. Bien souvent,
lorsque les collisions surviennent, le lien est dj surcharg. Ajouter un flux augmente le nombre de
collisions et va lencontre de ce qui est souhait.
Aprs avoir mis en vidence que la combinaison de certains facteurs naugmente pas la bande passante
utile du rseau, nous proposons une seconde fonction poids. Elle prend en compte les facteurs
favorisant loccurrence de collisions. Cette fonction poids utilise trois mtriques : le dbit de
0
10
20
30
40
50
60
70
2 5 10 15 20
B
a
n
d
e

p
a
s
s
a
n
t
e

c
o
n
s
o
m
m
e

p
a
r

l
e
s

r
e
q
u
t
e
s

R
R
E
Q

(
K
b
p
s
)

105
transmission, la bande passante disponible et le nombre de nuds voisins. Elle slectionne les chemins
les moins chargs 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 dun paquet est
fonction du dbit de transmission du nud. De fait, un paquet transmis avec un faible dbit de
transmission occupe plus longtemps le support. Durant loccupation du support, les nuds voisins ne
peuvent pas transmettre mme sils possdent un dbit bien suprieur. Notre fonction poids pnalise ce
facteur pour utiliser en priorit les chemins avec le dbit le plus lev. Le nombre de nuds voisins est
le dernier facteur pris en compte par cette fonction poids. Un flux impacte non seulement les nuds
quil traverse mais aussi leurs voisins. Prendre un chemin avec un nombre de voisins important
augmente la charge sur lensemble de ses voisins et rduit dautant la bande passante disponible du
rseau.
Pour montrer lefficacit de notre protocole et des fonctions poids qui lui sont adjointes, le
comportement de notre protocole est simul, dans diffrents environnements. La deuxime fonction
est efficace dans un environnement peu mobile. La bande passante utile du rseau est plus leve que
celle des protocoles de routage AODV et AODV Hello. Dans un environnement mobile plus
dynamique, notre protocole de routage combin la fonction poids numro 2 est moins efficace que le
protocole AODV. La dtection de la rupture dun lien est plus longue avec une gestion locale de
lenvironnement quavec les informations fournies par la couche MAC. Pour tre pleinement
oprationnel, il est ncessaire de trouver un quilibre entre le surcot (overhead) et lefficacit. En
effet, une gestion plus ractive augmente la charge sur le rseau, alors quune gestion trop lente
diminue lefficacit du protocole de routage.
Le nombre de requtes changes par les nuds utilisant notre protocole de routage combin la
fonction poids numro 2 est plus faible dans la totalit des environnements de simulation. Tout de
mme, notre protocole ncessite plus de paquets RREQ ncessaires. Cette augmentation des
informations de routage peut avoir un effet nfaste comme dans le cas du protocole 1. Le protocole 2
est moins sensible cela, puisquil compense en dtectant moins souvent une rupture errone dun lien.
Rduire de telles informations augmente la bande passante disponible du rseau. Nous nous attachons
dans le chapitre suivant en diminuer le cot.

107
5 Approches de Rduction de la
charge due aux informations
de contrle
De nombreux facteurs influent sur la consommation de la bande passante utile dun rseau MANET
(cf. 4). Les collisions ne sont pas le seul paramtre prendre en compte. En effet, les informations de
routage jouent un rle important dans la diminution de la bande passante du rseau. Pour dterminer
une route, entre un nud source et un nud destination, les nuds du rseau ont besoin
dinformations de routage pour trouver un tel chemin. Les protocoles de routage ractifs mettent ces
informations uniquement lorsque la ncessit dobtenir une route se fait ressentir (cration ou
maintenance). Les protocoles proactifs envoient priodiquement des informations de routage
permettant davoir une vue plus ou moins globale du rseau et ainsi tout moment connatre les routes
vers lensemble des nuds du rseau.
Les informations de routage consomment de la bande passante, rduisant de ce fait la bande passante
utile du rseau. Cette diminution rduit la quantit de donnes transmises sur le rseau et augmente le
nombre de collisions. Ces informations tant gnralement diffuses sur le rseau, elles ne sont pas
retransmises rduisant leur impact sur le rseau. Malgr cela, le protocole de routage doit contrler les
informations de routage changes. Dans la suite de ce chapitre, nous nous intressons uniquement
aux protocoles de routage ractifs et aux mthodes permettant la diminution des informations de
routage.

108
De nombreuses manires permettent de rduire les informations de routage. En effet, les protocoles
ractifs changent des informations de routage durant la phase de dcouverte dune route mais aussi
durant la phase de maintenance des routes. Pour rduire les informations de routage, diffrents
protocoles peuvent tre utiliss. Les points suivants donnent un ensemble non exhaustif des approches
couramment employes pour diminuer le nombre des informations de routage changes :
Stabilit des routes : Le dplacement des nuds dans le rseau entrane des ruptures sur les
chemins dj tablis. Le nud source est prvenu de telles coupures et doit rtablir la
connexion avec la destination. Pour cela, il recre une route en changeant des informations de
routage. Laccroissement de la vitesse de dplacement de certains nuds rend les routes
particulirement instables et cre de nombreuses transmissions pour maintenir les routes
tablies. Lors de la cration dune route, le protocole de routage peut privilgier les nuds
stables (les nuds dont la connectivit avec ses voisins voluent trs peu dans le temps).
Choisir des routes plus stables diminue le nombre dinformations de routage ncessaire leur
maintenance.
Rduction de lespace de recherche : Un protocole de routage ractif propage, lors de la
cration dune route, les informations de routage sur la totalit du rseau. Nombreuses sont ces
informations ne pas tre utilises pour la cration dune route. Gnralement, les nuds qui
ne sont pas situs entre la source et la destination sont rarement utiliss dans la cration des
routes. La propagation des informations de routage par de tels nuds ne fait quaugmenter le
trafic sur le rseau. Le protocole de routage doit empcher que ces nuds transmettent des
informations de routage. La rduction de lespace de recherche limite un ensemble de nuds
la propagation des informations de routage. Cette rduction ncessite la connaissance de la
position de la destination par le nud source. Gnralement, un protocole de routage,
rduisant lespace de recherche, est conjointement utilis avec un protocole de dtermination
de la position de la destination.
Utilisation de multiples chemins : Lors de la phase de dcouverte des routes, un protocole de
routage peut retourner diffrents chemins pour accrotre la dure de connectivit entre deux
nuds. En effet, lors de la rupture dun chemin, le nud source peut choisir un autre chemin
vitant une ventuelle phase de dcouverte des nuds. Ce procd permet de rduire le
nombre dinformations de routage changes gnralement lors des changements de topologie.
Pour tre particulirement efficace, les protocoles utilisant cette mthode doivent trouver de
multiples chemins distincts. Deux types de distinction des chemins existent : les distinctions
en nud et en lien. Deux chemins sont considrs distincts en nud sils nont aucun nud en
commun ( part la source et la destination). De mme, les chemins sont distincts en lien, si les
chemins retourns traversent tous des liens diffrents. Trouver des chemins distincts empche
que la rupture dun lien impacte plusieurs chemins pour un couple (source, destination).
Utilisation de topologies particulires : Lutilisation de topologies particulires peut rduire le
nombre dinformations ncessaires la dcouverte dune route. Certains nuds de cette
topologie peuvent centraliser les informations dune partie du rseau et sont les seuls
changer les informations de routage lors de la dcouverte des routes. Par exemple, supposons

109
un rseau de clusters (cf. 2.2.1). Les nuds dun mme cluster sont affilis une tte de
cluster. Chaque tte de cluster connat les nuds qui lui sont affilis. Lorsquun nud
ncessite la cration dune route, il envoie une requte de cration de route sa tte de cluster.
Une tte de cluster recevant un tel paquet sait si la destination lui est affilie ou non. Si la
destination est directement joignable, elle confirme un chemin en direction de la source. Dans
le cas contraire, la tte de cluster propage la requte ses passerelles qui transmettent la
requte aux passerelles ou aux ttes de cluster auxquelles elles sont relies.
Dans la suite de ce chapitre, nos travaux portent sur la rduction de lespace de recherche. Dans un
premier temps, nous proposons un protocole pour dterminer la position de la destination. Pour cela,
nous utilisons une topologie de rseau backbone. Ensuite, des mthodes pour rduire lespace de
recherche sont proposes et tudies. Deux protocoles de routage utilisant une recherche de parcours
en profondeur sont fournis et leur efficacit est montre laide de simulations.
5.1 Dtermination de la position de la destination
Un nud source doit connatre la position de la destination pour rduire lespace de recherche dans
lequel sont propages les informations de routage. Chaque nud a donc besoin de connatre sa
position gographique par rapport aux autres nuds du rseau. Pour cela, un rcepteur GPS (Global
Positionning System) [PAR 83-1], [GPS] peut tre utilis pour rcuprer ses coordonnes. Les
rcepteurs GPS sont aujourdhui suffisamment lgers et petits pour tre embarqus dans nimporte
quel quipement. Chaque nud dtermine ses coordonnes (X, Y) dans une zone donne.
Des protocoles de gestion de la localisation ont t proposs dans la littrature (tels que [LI 00-1] et
[BLA 01-1]) pour permettre un nud de connatre la position des autres nuds dans le rseau. Dans
GLS [LI 00-1], un modle de serveur distribu est dcrit. Dans ce modle, une station dfinit dautres
nuds dans une certaine zone comme ses serveurs de localisation. Chaque station envoie
priodiquement ses informations de localisation ses serveurs de localisation. Les autres nuds du
rseau peuvent ainsi connatre la position dune station en interrogeant les serveurs de localisation de
cette station. Une autre approche est aborde dans [BLA 01-1]. Chaque nud dfinit une zone
virtuelle, not VHR (Virtual Home Region), avec un centre fixe. Chaque nud envoie ses
informations de localisation son VHR. Lorsquun nud veut en contacter un autre, il contacte
dabord son VHR pour obtenir sa position. Dans ces deux mthodes, les nuds ncessitent de
connatre approximativement la couverture du rseau. Le surcout en paquets engendr par les
informations de localisation savre assez important dans ces protocoles.
Le protocole de localisation doit dterminer la position de la destination moindre cot. Nous
proposons une mthode diffrente des deux prcdentes pour obtenir moindre cot la position de la
destination. Pour raliser cela, nous utilisons un rseau backbone (cf. 2.2.2) pour dterminer la
position dune station. Les informations relatives la dtermination de la position dun nud sont
transmises sur le rseau backbone rduisant, de fait, les informations changes sur le rseau
MANET. Le dbit accept par le rseau backbone est relativement faible du fait de sa frquence de
fonctionnement. En effet, ce type de rseau possde une porte leve (donc une frquence de

110
fonctionnement relativement faible) pour convenablement connecter les nuds de backbone entre eux.
Il nest donc pas envisageable dutiliser le rseau backbone pour changer la totalit des donnes
transitant gnralement sur le rseau MANET. La cohabitation est donc particulirement intressante.
5.1.1 Protocole de localisation de la destination
Dans cette partie, nous proposons un protocole pour dterminer moindre cot la position dun nud
dans le rseau [ESP 06-2]. Pour cela, notre protocole est dcoup en deux parties. La premire
consiste trouver le nud de destination et linterroger pour obtenir sa position. La deuxime partie
est une phase de maintenance de la connectivit entre le nud source et le nud destination travers
le rseau backbone. Conserver une telle connectivit permet de recevoir priodiquement la position
de la destination et dtablir plus rapidement une nouvelle route vers ce nud en cas de rupture de la
route utilise.
5.1.1.1 Phase de dcouverte de la destination
Le protocole de localisation doit dterminer la position dun nud destination sans impacter outre
mesure le rseau ad hoc. Ds lors, les paquets ncessaires dterminer la destination sont propags
principalement sur le rseau backbone. Chaque nud de backbone maintient une liste des nuds qui
lui sont affilis.
Quand un nud source souhaite crer une route avec un nud destination, il doit au pralable
dterminer sa position. Le principe de notre protocole est de propager les requtes de localisation sur
le rseau backbone. Quand un nud du rseau de backbone trouve la destination dans la liste des
nuds qui lui sont associs, il demande au nud destination de donner sa position la source. Le
nud source, respectivement destination, peut tre de deux types : un nud ad hoc normal ou un nud
du backbone. Le fonctionnement du protocole est diffrent suivant le type de nuds.
Lalgorithme utilis par la source pour dterminer la position de la destination est donn par la
figure 5-1. Le nud source cre une requte LREQ pour dterminer la position de la destination. Cette
requte contient les champs suivants : adresse source, numro de squence source, adresse de
destination, numro de squence de destination, identifiant de la requte, champ rparation. Le champ
de rparation est mis 0 lors de la recherche dune localisation. Lutilisation des numros de squence
permet la datation des informations de routage et empche la cration de boucle (cf. 2.1.2.1). Si le
nud source est un nud sur le rseau ad hoc, il doit envoyer la requte au nud de backbone auquel
il est affili. Dans le cas o le nud source est lui-mme un nud de backbone (BN), il peut
directement diffuser la requte sur le rseau backbone. Une fois la requte mise, il dclenche un
temporisateur Trep durant lequel il doit recevoir une rponse. Si le temporisateur arrive chance, le
nud source recre une requte et ressaie dobtenir la position de la destination. Si au bout dun
certain nombre de tentatives il nobtient toujours pas la position de la destination, il dtermine la route
sans utiliser la position de la destination. Dans ce cas, une rduction de lespace de recherche ne peut
tre envisage.

111

Figure 5-1 : Organigramme utilis par le nud source pour dterminer la position de la destination.
Lencadr en pointill met en valeur la partie diffrente de notre protocole compar au protocole
AODV.
Lalgorithme excut par un nud intermdiaire est fourni par la figure 5-2. Chaque nud du rseau
maintient une table de localisation. Cette table permet de dterminer pour un nud donn le prochain
nud auquel envoyer ses paquets pour lui propager sa position. Cette table contient les champs
suivants : adresse de destination, numro de squence, adresse du prochain nud.
Lorsquun nud intermdiaire reoit une requte LREQ, il vrifie en premier lieu sil la dj reue. Si
tel est le cas, il supprime cette requte. Sinon, il met jour sa table de localisation pour joindre la
source, et adapte son fonctionnement suivant que le nud destination lui est affili ou non. Lorsque le
nud destination est affili ce nud intermdiaire, il envoie la requte au nud de destination pour
informer ce dernier de retourner, au nud source, sa position. Dans le cas o le nud destination ne
lui est pas affili, il propage la requte sur le rseau backbone.

112
A la rception dun paquet de rponse de localisation, not LREP, le nud intermdiaire regarde dans
sa table de routage le nud suivant pour joindre le nud source et lui met la requte. En mme,
temps, il ajoute dans sa table de localisation le nud suivant pour joindre la destination. Ainsi, une
route dans le sens source-destination et une route dans le sens destination-source sont conserves dans
la table de localisation.

partie diffrente de notre protocole compar au protocole AODV.
La figure 5-3 donne lalgorithme utilis par le nud destination. Lorsquil reoit une requte LREQ, il
met jour sa table de localisation pour joindre la source. Il envoie ensuite au nud lui ayant transmis
la requte LREQ, une rponse LREP avec le champ rparation positionn 0. Une requte LREP est
forme par les champs suivants : adresse source, adresse destination, numro de squence de
destination, champ rparation et les coordonnes gographiques de la destination. Le nud destination
dclenche un temporisateur Ta permettant lenvoi priodique de ses coordonnes gographiques au
nud source.
A la rception dune rponse LREP, le nud source connat cet instant la position gographique de
la destination. Il peut alors engager le processus de cration de route sur le rseau ad hoc en limitant
lespace de recherche. En cas de rupture de route, la source utilise les dernires coordonnes
gographiques du nud destination pour restreindre lespace de recherche.
Lorsque le nud destination ne reoit plus, pendant un certain laps de temps, de paquets de donnes
provenant dun nud source, il cesse de lui envoyer sa position.

113
Le protocole de localisation na pas pour vocation de choisir le chemin le plus court sur le rseau
backbone. Le but premier de ce protocole est dtre suffisamment ractif pour obtenir le plus
rapidement possible les coordonnes gographiques du nud destination. En effet, le temps dobtenir
ces coordonnes nest pas ngligeable. Par consquent, ce retard engendr par la recherche de la
position du nud destination doit tre aussi faible que possible.

5.1.1.2 Phase de maintenance
Par un paquet de mouvement not MOVP, le nud destination informe intervalle rgulier le nud
source de sa position. Ce paquet contient les coordonnes gographiques de la destination et
ventuellement des paramtres tels que la vitesse, le sens de dplacement Ainsi en cas de rupture de
route, la source a une position suffisamment rcente de la destination pour viter dutiliser la phase de
localisation de la destination. Une telle mthode vite le dlai engendr par la dtermination de la
position du nud destination.
Pour transmettre priodiquement les paquets MOVP, la destination peut utiliser deux mthodes. La
premire mthode consiste diffuser un paquet MOVP sur le rseau backbone. A la rception de ce
paquet par un nud de backbone, il vrifie sa liste des nuds affilis. Si le nud source en fait partie,
il lui transmet le paquet. Si le nud de backbone a dj reu un tel paquet MOVP, il le supprime.
Cette mthode savre particulirement facile mettre en uvre car mme si la topologie du rseau
backbone change, le paquet MOVP parvient toujours un nud de backbone auquel la source est
affilie. Par contre, cette mthode consomme beaucoup de bande passante sur le rseau backbone, du
fait de la diffusion du paquet.
La deuxime mthode est dutiliser la conservation des routes de localisation entre le nud destination
et le nud source (cf. figure 5-2). Chaque nud maintient une table de localisation dans laquelle est
DEBUT
LREQ dj reu ?
non
oui Supprimer
la requte
- Mettre jour lentre de la table de
localisation pour le nud source
- Crer une requte LREP
- Initialiser les champs de LREP
- Emettre LREP
- Dclencher un temporisateur Ta
LREQ reu ?
oui
Ta expir ?
non
non
oui
- Envoyer au nud source sa position
- Rarmer Ta

114
conserv le prochain nud pour joindre un nud source. Ainsi, la destination peut envoyer
priodiquement un paquet MOVP au nud suivant de sa table de localisation pour informer la source
de sa position courante. Le problme de cette mthode est quavec le dplacement des nuds, la
topologie du rseau backbone peut voluer avec le temps. Il est ncessaire davoir des mcanismes
de rparation des routes pour maintenir lchange des paquets MOVP entre le nud destination et
source.
Suivant le changement de la topologie du rseau backbone, il est ncessaire davoir un mcanisme
de restauration des routes de localisation. Un changement sur la topologie du backbone peut affecter
un nud source comme un nud destination. En effet, un nud source ou destination peuvent
saffilier un autre nud du rseau backbone. La topologie du backbone peut, aussi, changer (c'est-
-dire quun lien sur le rseau backbone peut tre rompu, coupant les routes en places).
Lorsquun nud source change daffiliation, lancien nud de backbone X, auquel il tait affili,
reoit toujours les paquets de la destination. Le nud de backbone X cre une route avec la source.
Pour cela, il diffuse un paquet LREQ avec un champ rparation gal 1. A la rception dun paquet
LREQ dont le champ rparation est activ, le nud de backbone (auquel la source est affilie) rpond
sa place. Une route est dornavant tablie entre la source et la destination.
Lorsquun nud destination change daffiliation, il doit recrer une route avec les nuds sources
auxquels il envoie des informations de localisation. Pour cela, il cre un paquet LREQ pour chaque
source avec le champ rparation positionn 1. La route entre la destination et la source est ainsi
rtablie et la destination peut recommencer envoyer ses informations de localisation.
Quand un nud de backbone dtecte une coupure, une requte de rparation de route (LERR) est
envoye aux nuds transmettant les informations de localisation. Une requte LERR contient
lensemble des nuds qui ne sont plus joignables. A la rception dune requte LERR, les nuds
recrent une route avec les nuds sources (dont la rupture a interrompu la rception des paquets
MOVP) en mettant un paquet LREQ dont le champ rparation 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 nud du rseau connat ladresse du serveur fixe et lui envoie toutes les 3 secondes
un paquet contenant sa localisation. Chaque nud tablit et maintient une route avec ce serveur de
localisation avant tout envoi de paquet de localisation. Pour obtenir une position, le nud contacte le
serveur de localisation. Notre protocole utilise une topologie en backbone. Pour maintenir cette
topologie, lensemble des nuds du rseau diffuse un paquet Hello toutes les 3 secondes pour la
gestion du backbone. Ce paquet permet la prise en compte de larrive de nouveaux nuds et aussi la
maintenance de la topologie en identifiant la perte daffiliation avec un nud de backbone (quand le
nud de backbone sort de la zone de couverture dun nud par exemple ). Chaque nud
destination envoie priodiquement (toutes les 3 secondes) sa position au nud source pour viter une
ventuelle phase de demande de position lors de la perte dune route.

115
Le rseau est compos dun nombre variable de nuds selon la simulation effectue. Lorsque ce nest
pas prcis, les nuds se dplacent une vitesse maximale de 5m/s. Le rayon de couverture dun
nud ad hoc est de 150 mtres. Le rayon de couverture dun nud de backbone est de 300 mtres. Les
nuds sont rpartis dans une zone carre de 1000m de ct. Ils utilisent pour se dplacer le modle
RWP (cf. 1.4) avec un temps de pause de 200 secondes entre dplacements. Ils possdent une vitesse
de transmission de 2Mb/s. La simulation utilise un modle de communication dans lequel la moiti des
nuds communiquent avec lautre moiti. Pour simuler notre protocole, 20% des nuds sont
susceptibles dtre lus nuds du backbone. Ces nuds possdent deux frquences de fonctionnement,
une frquence conventionnelle pour le rseau ad hoc et une autre frquence pour les changes entre
nuds du backbone. Chaque nud du rseau est au moins affili un nud de backbone ou est un
nud de backbone. La dure dune simulation est de 500 secondes.
Dans un premier temps, nous comparons le surplus dinformations ncessaires lobtention dune
position. Pour cela, les simulations montrent le nombre de requtes changes sur la totalit du rseau
dans diffrents environnements.

Figure 5-4 : Nombre de requtes de localisation changes en fonction du nombre de nuds avec une
mobilit des nuds de 5m/s.
La figure 5-4 montre lvolution du nombre de requtes suivant laugmentation du nombre de nuds.
On remarque que les deux protocoles voluent assez linairement. Le serveur de location fixe possde
un nombre de requtes bien plus important que notre protocole (environ trois fois plus). Ce nombre
sexplique du fait que chaque nud du rseau 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 rseau de 100 nuds) augmentant grandement le nombre
de requtes. Notre protocole, quant lui, gre la demande de position ractivement. Les nuds du
rseau nont pas besoin de prciser leur position priodiquement. Seules les destinations envoient
priodiquement leur position leurs sources. La grande majorit des informations transitent sur le
rseau backbone engendrant un faible surcot. 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
B
a
n
d
e

p
a
s
s
a
n
t
e

n
c
e
s
s
a
i
r
e

o
b
t
e
n
t
i
o
n

d
e
s

p
o
s
i
t
i
o
n
s

(
K
b
/
s
)

116
1,6 message par mise jour de la position. En effet, la plupart des messages transitent travers le
rseau backbone. Lors de la cration dune route, la source demande la position de la destination
travers le backbone. Lobtention de la position est ralise, au maximum, en 4 messages. En effet, les
messages de localisation sont changs sur le rseau ad hoc uniquement entre le nud source,
(respectivement destination), et son nud de backbone. Donc lorsque les nuds source et destination
sont des nuds ad hoc normaux, un message est mis par la source pour demander la localisation, un
message est mis par le nud de backbone auquel la source est affilie, un message est envoy en
rponse par la destination, et enfin la rponse est propage la source par son nud de backbone.
Avec le faible surcot pour obtenir et maintenir les positions des nuds de destination, notre protocole
passe facilement lchelle avec laugmentation du nombre de nuds.
La figure 5-5 montre lvolution du nombre de requtes de localisation en fonction de la mobilit des
nuds du rseau. La surcharge en requte volue lentement avec la vitesse des nuds. Avec le serveur
de location fixe, chaque nud du rseau doit maintenir une route avec le serveur de location. Avec
laugmentation de la vitesse des nuds, les ruptures de chemins avec le serveur de localisation sont
plus frquentes entranant une augmentation du nombre de requtes ncessaires la localisation.
Lvolution des chemins reste toutefois limite dans nos simulations cause du temps de pause qui
slve 200 secondes entre dplacements. Avec un temps de pause beaucoup plus faible, le nombre
de requtes de localisation augmenterait encore plus avec laccroissement de la vitesse des nuds. La
vitesse des nuds 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 ralise, principalement, sur le
rseau backbone. De mme, avec une porte de transmission plus importante pour les nuds du
backbone, la stabilit du rseau backbone est plus grande et moins sensible aux ruptures de liaison
entre nuds de backbone.

Figure 5-5 : Nombre de requtes de localisation changes en fonction de la mobilit des nuds pour
deux topologies diffrentes (une compose de 50 nuds, lautre compose de 100 nuds).
La figure 5-6 met en vidence laugmentation du temps dobtention de la position dun nud
destination en fonction de la charge du rseau. En effet avec laugmentation du nombre de nuds dans
0
10
20
30
40
50
60
70
0 2 5 10 15 20

117
le rseau, la charge du rseau augmente puisque le nombre de flux est gal la moiti du nombre de
nuds prsents dans le rseau. Le temps dobtention de la position de la destination est assez faible
puisque la connectivit est non assure lorsque le nombre de nuds est trop faible (infrieur 30
nuds). Ainsi, la charge est moins importante quelle ne devrait ltre dans ces deux scnarios.
Lobtention de la position dune destination souffre peu de lattente de la libration du support. Par
contre dans les scnarios pour lesquels le nombre de nuds est suprieur 30, la totalit des
connexions sont tablies. Les nuds doivent attendre un moment en file dattente avant dacqurir le
support. Notre protocole souffre moins de cette surcharge puisque seulement deux nuds sur le
chemin la subisse. En outre laller de la demande de position, seulement le nud source (qui envoie
la demande son nud de backbone) et le nud de backbone (auquel la destination est affilie)
souffrent de cette attente. Entre ces deux nuds, les messages transitent sur le rseau backbone (avec
une faible surcharge car seuls les messages de localisation transitent travers ce rseau). De mme
pour la rponse la demande de position, seulement la destination et le nud de backbone (auquel est
affilie la source) attendent durant un certain temps lacquisition du support de transmission. Avec le
serveur de location fixe, chaque nud du chemin (entre la source et le serveur de location) souffre de
lattente de lacquisition du support. Le dlai est, par consquent, plus important. Les simulations ont
galement mis en vidence que notre protocole souffre dun dlai lgrement plus important lorsque le
nud source, le nud destination et le serveur de location sont tous situs porte radio. Ce point de
faiblesse nest pas mis en vidence par les rsultats de simulation car ce cas est assez rare et le temps
obtenu est une moyenne entre les diffrents temps dobtention dune position. Ce surplus de temps
sexplique par le fait que mme si la source et la destination sont situes un saut, la source envoie sa
demande de position au nud du backbone auquel elle est affilie. 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 dobtention de la position dun nud destination en fonction du nombre de nuds
du rseau
La figure 5-7 met en vidence lvolution du temps en fonction de la mobilit et de la charge du rseau.
Ce temps est mis en vidence sur deux topologies diffrentes (une compose de 50 nuds, lautre de
0
0,5
1
1,5
2
2,5
10 30 50 75 100 150

118
100 nuds). Pour une topologie de 100 nuds, la courbe volue assez linairement. Le temps
dobtention de la position de la destination crot quelque soit le protocole de localisation utilis. Notre
protocole a un temps plus faible pour les mmes raisons que celles exprimes sur la figure 5-6. En
utilisant notre protocole, la plupart des messages transitent sur le rseau backbone qui est moins
surcharg. Pour la topologie de 100 nuds, la charge sur le rseau tant bien plus importante, le dlai
(pour les deux protocoles) est bien plus important au dpart. Les courbes suivent, galement, une
progression linaire, mme si elle est plus lente que sur la topologie forme de 50 nuds. Notre
protocole possde un dlai moins important dans lensemble des situations.

Figure 5-7 : Temps dobtention de la position dun nud destination en fonction de la mobilit des
nuds pour deux topologies (une compose de 50 noeuds, lautre compose de 100 nuds).
5.1.1.4 Discussion
Nous avons propos un protocole de localisation ractif. Ce protocole rcupre la position dun nud
destination en utilisant un rseau backbone. La formation et la maintenance dun tel rseau permet
de rduire les informations de localisation.
Les rsultats de simulation ont montr que notre protocole est efficace. Il diminue grandement le
nombre de requtes compar un protocole de localisation bas sur un serveur fixe de localisation. Le
nombre de requtes ncessaires au fonctionnement de notre protocole est trs faible. La surcharge la
plus importante est la mise en place et la maintenance de la topologie du rseau backbone. Pour cela,
il est ncessaire que les nuds se fassent connatre de leurs voisins, en transmettant priodiquement
des paquets Hello. Mme avec un tel surplus, notre protocole transmet bien moins de requtes.
Notre protocole est moins sensible aux dplacements des nuds. En effet, la mobilit des nuds
ncessite la maintenance des routes. Cette maintenance consomme de la bande passante et accrot la
charge du rseau augmentant le dlai dobtention dune position. En utilisant le rseau backbone qui
est peu charg (car seul les paquets de localisation le traversent), notre protocole offre un dlai bien
plus faible pour lobtention dune position.
0
0,5
1
1,5
2
2,5
0 2 5 10 15 20
Serveur de location
fixe (50 nuds)
Notre protocole
(50 nuds)
Serveur de location
fixe (100 nuds)
Notre protocole
(100 nuds)
Mobilit des nuds (m/s)

119
5.2 Rduction de lespace de recherche
Lespace de recherche est la zone du rseau dans laquelle sont propages les informations de routage.
Lors de la phase de dcouverte des routes, le nud source met un paquet RREQ. Avec le protocole
AODV, les paquets RREQ sont propags lensemble des nuds du rseau. En connaissant la
position de la destination, le protocole peut limiter la zone de recherche aux nuds situs entre le
nud source et le nud destination. Une rduction de lespace de recherche diminue gnralement le
nombre dinformations de routage ncessaires lobtention dune route.
Dans cette partie, nous tudions deux formes gomtriques distinctes. La premire consiste en
lutilisation dune 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 rduire lespace
de recherche en fonction des formes prcdentes. Enfin, des simulations sont ralises pour montrer
lefficacit de notre protocole.
5.2.1 Forme gomtrique triangulaire
Lespace de recherche est dfini par une forme gomtrique triangulaire (figure 5-8). Seuls les nuds
situs lintrieur de cette zone transmettent les informations de routage. Initialement, le nud source
S connat seulement sa position et celle du nud destination D. Certains paramtres comme langle
= DSC et la longueur (se trouvant dans le prolongement de la droite SD) sont fournis par le nud
source.
La zone de recherche est dlimite par un triangle isocle CSC avec un angle gal 2 et une hauteur
de longueur SD + , o est une marge permettant daccrotre la chance datteindre D. Chaque nud
recevant une requte RREQ doit dterminer sil se situe dans la zone de recherche et ainsi sil doit la
retransmettre. Pour cela, divers paramtres doivent tre calculs tels que la valeur de (reprsentant
langle entre la normale et la mdiane du triangle), les coordonnes de (point situ sur la mdiane
une distance de D)et celles de C et C.
Dans la suite, nous supposons que X
S
X
D
(X
i
reprsente labscisse dun point i) et nous limitons
tel que < 90. Cette limitation de est ralise pour que les requtes soient bien propages en
direction de la destination.
Pour dterminer la zone de recherche, il est ncessaire de calculer les coordonnes des points C et C.
Les points C et C ont pour projection orthogonale le point sur la droite SD. En connaissant langle
et les coordonnes du point , les coordonnes des points C et C peuvent tre facilement obtenues. La
premire chose faire est de trouver les coordonnes du point . Par commodit, nous notons
Y = aX + b (avec X
s
X
D
) la droite passant par les points S et D. En fait, la formule de cette droite est
donne par lquation suivante :
S D
S D D S
S D
S D
X X
X Y X Y
X
X X
Y Y
Y
=

120

Figure 5-8 : Zone de recherche de forme triangulaire

Dterminer les coordonnes du point :
Deux cas doivent tre distingus lors du calcul des coordonnes du point (selon que le coefficient
directeur a est nul ou non). La proprit 5-1 fournit les coordonnes de lorsque a est non nul et la
proprit 5-3 lorsquil est nul.
Deux points se situent sur la droite Y une distance du point D. La proprit 5-1 calcule les
coordonnes de ces deux points.
Proprit 5-1 : Soit une droite Y = aX + b avec a 0 traversant les points S et D,

( )
) 1 ( 2
2
1
+
+ +
=
a
b aX Y a
Y
D D
,
( )
) 1 ( 2
2
2
+
+ + +
=
a
b aX Y a
Y
D D
| Y
1
, Y
2
sont
les ordonnes des points spars par une distance avec le point D, o
( )
( )
|
|
\
|
+ +
+ +
+
+ +
=
2

1 4
4
b b aX
X a Y a a
a
b aX Y a
D
D D
D D
.
Dmonstration :
Soit une droite Y = aX+b, avec a 0, passant par les points S et D ; un point se situe une distance,
dun point D, gale si :
(X
D
- X
) + (Y
D
- Y
) =
De plus le point a les coordonnes situes sur la droite Y donc : Y

= aX

+ b.

121
On peut dduire, de ces deux quations, le systme suivant :
( ) ( )
+ =
= +
b aX Y
Y Y X X
D D

Pour trouver Y
en fonction de Y
D
et X
D
, il est ncessaire de rsoudre lquation suivante :
( ) ( ) 0 2 2 1 = + + + + + + + b b aX aX aY a Y b aX aY Y a
D D D D D

A partir de cette quation, on calcule avec la formule suivante :
( ) ( )( ) 2 1 4 4
2
b b aX X a Y a a a b aX Y a
D D D D D
+ + + + + + + =
est 0 car les coordonnes du point se situent dans lensemble des rels.
Il ne reste plus qu dterminer les solutions de lquation pour trouver les ordonnes possibles du
point :
( )
) 1 ( 2
2
1
+
+ +
=
a
b aX Y a
Y
D D

( )
) 1 ( 2
2
2
+
+ + +
=
a
b aX Y a
Y
D D

Daprs la proprit 5-1, il est possible de dduire la valeur de lordonne de suivant la pente de la
droite Y avec a 0 et de la position des nuds S et D. La proprit 5-2 donne la valeur de Y
.
Proprit 5-2 : Y

{ }
2 1
,

Y Y | si X
D
>X
S
a>0 X
D
<X
S
a<0, Y
>Y
D
sinon Y

<Y
D
.
La proprit 5-2 dfinit dans le cas gnral lordonne dun point se situant une distance dun
point D. Tout de mme, 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 proprit 5-3 donne
labscisse du point pour une droite Y horizontale et la proprit 5-4 donne lordonne du point pour
une droite Y verticale.
Proprit 5-3 : Soit une droite Y =b passant par les points distincts S et D, X
1
=X
D
- et
X
2
=X
D
+ | X
1
, X
2
qui sont les abscisses des points avec une distance D. Si X
D
>X
S

X

=X
D
+ sinon si X
D
<X
S
X

=X
D
-

122
Proprit 5-4 : Soit une droite X=b passant par les points distincts S et D, si Y
D
>Y
S

Y
=Y
D
+, sinon si Y
D
<Y
S
Y

=Y
D
-
Le thorme 5-1 regroupe les proprits 5-2, 5-3 et 5-4 pour donner les coordonnes dun point se
situant une distance du point D.
Thorme 5-1 : Soit deux points distincts S et D, un point situ sur la droite Y = aX + b une
distance de D a les coordonnes (X
, Y
) suivantes : si a 0 et X
D
X
S
:
a
b Y
X

=

et Y

(donne par la proprit 5-2) sinon si a = 0 X
(donne par la proprit 5-3) et Y
=b sinon
X
=

X
S
et Y
(donne par la proprit 5-4).

Dterminer les coordonnes des points C et C :
Pour plus de lisibilit, nous diffrencions le cas o Y est une droite verticale des deux autres cas (cas
gnral et cas o a = 0). La proprit 5-5 donne les coordonnes des points C et C dans le cas dune
droite Y verticale et la proprit 5-6 retourne les coordonnes des points C et C dans les deux autres
cas.
Proprit 5-5 : Soit une droite X =b passant par les points S et D, le point C a les coordonnes :

tan S X X
C
+ = Y
C
= Y

Le point C a les coordonnes :

tan
'
S X X
C
= Y
C
= Y

avec ( ) ( ) + + =
2 2
S D S D
Y Y X X S (S est la distance sparant S de ) et
|
\
|
=
SD
X X
S D
arccos
.

Proprit 5-6 : Soit une droite Y = aX + b passant par les points S et D, le point C a les
coordonnes suivantes :
+

=
sinon tan tan
0 a si tan tan

S X
S X
X
C

cos tan S Y Y
C
+ =

123
Le point C a les coordonnes :
+
=
sinon tan tan
0 a si tan tan
'

S X
S X
X
C

cos tan
'
S Y Y
C
=
A la rception dune requte, chaque nud du rseau peut dterminer la zone de recherche en
calculant les coordonnes des points C et C grce la proprit 5-5 et la proprit 5-6. Aprs quil
ait calcul la zone de recherche, il doit pouvoir dterminer sil se situe lintrieur de cette zone. Un
nud peut transmette un paquet RREQ si ses coordonnes se situent entre les droites SC, SC and CC.
Cette zone est note SCC. Cette fois encore, nous diffrencions le cas o les nuds S et D ont la
mme abscisse des deux autres cas. Le thorme 5-2 donne les conditions respecter pour quun nud
se situe dans la zone de recherche de S et D avec X
S
=X
D
. Le thorme 5-3 fournit les conditions
respecter pour quun nud soit dans la zone de recherche dans les deux autres cas.
Thorme 5-2 : Soit un nud source S et un nud destination D distincts avec X
S
=X
D
, un nud
avec les coordonnes (X, Y) est situ dans SCC si ses coordonnes respectent les conditions
suivantes :
Si Y
D
> Y
S
alors VRAI Y Y b X a Y b X a Y
C
= + + ) ( ) ( ) (
2 2 1 1

Sinon si Y
D
<Y
S
alors VRAI Y Y b X a Y b X a Y
C
= + + ) ( ) ( ) (
2 2 1 1

avec
S C
S C
X X
Y Y
a
=
1
,
S C
S C C S
X X
X Y X Y
b
=
1
et
S C
S C
X X
Y Y
a
=
'
'
2
,
S C
S C C S
X X
X Y X Y
b
=
'
' '
2

Thorme 5-3 : Soit un nud source S et un nud destination D distincts avec une droite
Y = aX + b, un nud avec les coordonnes (X, Y) se situe dans SCC sil respecte les trois
conditions suivantes :
En fonction de la droite SC, il est correctement positionn si :
( ) ( )
( ) ( )
( ) ( )
+
< > +
< =
> =
sinon
0 0 si
si
si
1 1
1 1 1
b X a Y
a a b X a Y
X X X X X X
X X X X X X
S D S C C
S D S C C

En fonction de la droite SC, il est correctement situ si :

124
( ) ( )
( ) ( )
( ) ( )
+
< > +
< =
> =
sinon
0 0 si
si
si
2 2
2 2 2
' '
' '
b X a Y
a a b X a Y
X X X X X X
X X X X X X
S D S C C
S D S C C

En fonction de la droite CC:
Quand X
D
>X
S
:
+
> +
=
sinon
0 si
si
3 3
3 3
'
b X a Y
a b X a Y
X X X X
C C C

avec
'
'
3
C C
C C
X X
Y Y
a
= and
'
' '
3
C C
C C C C
X X
X Y X Y
b
=
Quand X
D
< X
S
:
+
> +
=
sinon
0 si
si
3 3
3 3
'
b X a Y
a b X a Y
X X X X
C C C

Le thorme 5-2 vrifie uniquement quun nud est bien situ entre les axes de la zone de recherche.
Du fait de son vidence, une dmonstration de ce thorme nest pas donne.
5.2.2 Forme gomtrique en cerf-volant
La deuxime forme gomtrique utilise dans ce chapitre pour diminuer lespace de recherche est une
forme en cerf-volant. Contrairement celle utilise dans la premire partie, cette forme est bien plus
effile que la premire rduisant dautant le nombre de requtes changes par les nuds. En effet, il
est ncessaire davoir un angle important lextrmit de la source car il faut toucher un nombre de
nuds important. Une fois au centre (les nuds se trouvant la moiti de la distance), la rduction de
lespace vers la destination est comprhensible. Plus les nuds sont proches de la destination, plus ils
peuvent tre prcis pour atteindre la destination. Une telle forme gographique est reprsente sur la
figure 5-9. Lors de la recherche dune route le nud source propose deux angles et . La droite,
passant par le nud source S et le nud destination D, forme un axe de symtrie pour cette forme
gographique.

125

Figure 5-9 : Zone de recherche en forme de cerf-volant
Par la suite, nous limitons les angles et lintervalle ]0, 90[. Nous faisons une telle limitation car
lutilisation dangles plus grands rend la zone de recherche trop proche de celle dAODV. De fait, si
les zones de recherche sont comparables, il est plus judicieux dutiliser directement le protocole
AODV. Le repre cartsien sur lequel est bas les coordonnes GPS est not R et il a une base b
compos des vecteurs i
r
et j
r
. Pour simplifier les calculs permettant de dterminer si un nud se
situe dans lespace de recherche, nous changeons le repre cartsien et le notons R. R est un repre
cartsien dorigine S et de base ( ) v u b
r r
, ' = . Le vecteur u
r
(respectivement v
r
) forme un angle avec
i
r
(respectivement j
r
). Le vecteur u
r
est un vecteur unitaire dorigine S. Il possde le mme sens et la
mme direction que le vecteur SD. Le vecteur v
r
est orthogonal au vecteur u
r
. Par consquent, la
base b est une base orthonorme. Le repre R est dfini par la proprit 5-7 en fonction du repre R.
Proprit 5-7 : Soit un repre cartsien ( ) j i R
r r
, , 0 = , il existe un repre cartsien ( ) v u S R
r r
, , ' =
avec j Y i X OS
S S
r r
+ = , j i u
r r
r
sin cos + = et j i v
r r
r
cos sin + = o
, i u =
r
r
.
La valeur de volue suivant le positionnement du nud source et destination dans le plan. Pour
dterminer mathmatiquement les frontires de la zone de recherche et ainsi pouvoir dterminer si un
nud se trouve lintrieur de cette zone, il est ncessaire dobtenir une valeur de . La proprit 5-8
exprime cette valeur en degrs.
Proprit 5-8 : u i
r
r
, = prend diffrentes valeurs suivant le positionnement des nuds
source et destination. En effet, le vecteur SD est colinaire u
r
.
i
r
j
r
v
r
u
r

126
( ) ( )
( ) ( )
( ) ( )
|
|
|
\
|

<
|
|
|
\
|

+
> <
|
|
|
\
|

>
|
|
|
\
|

=
sinon arccos 360
si sinon arccos 180
si sinon arccos 180
si arccos
SD
X X
Y Y X X
SD
X X
Y Y X X
SD
X X
Y Y X X
SD
X X
S D
S D S D
S D
S D S D
S D
S D S D
S D

avec ( ) ( )
2 2
S D S D
Y Y X X SD + =

Les coordonnes GPS des nuds se situent dans le repre R. Un nud doit par consquent pouvoir
dduire de son repre initial R, ses coordonnes dans le repre R. Chaque nud recevant une requte
doit raliser la mme opration pour les coordonnes du nud source et destination. La proprit 5-9
permet dexprimer les coordonnes dun point quelconque M dans le repre R.
Proprit 5-9 : Soit un point M avec les coordonnes (X, Y) dans le repre R, il a les
coordonnes (X, Y) dans le repre R telles que :
( ) ( ) sin cos '
S S
Y Y X X X + =
( ) ( ) cos sin '
S S
Y Y X X Y + =
Dmonstration :
Soit deux repres orthonorms R=(0,b) avec b=( i
r
, j
r
) et R=(S,b) avec b=( u
r
, v
r
). Daprs la
proprit 5-7, j Y i X OS
S S
r r
+ = , j i u
r r
r
sin cos + = et j i v
r r
r
cos sin + = , la matrice de
changement de base (note P) de la base b la base b est donne par la formule suivante :
|
|
\
|
=

cos sin
sin cos
P
Soit un point M quelconque dans un R-espace vectoriel :

127
SM OS OM + =
Lexpression de cette galit dans la base b est la suivante :

avec (X, Y) les coordonnes du point M dans R.
+ + =
+ =

cos ' sin '
sin ' cos '
Y X Y Y
Y X X X
S
S

Pour trouver X et Y suivant X et Y, le systme suivant est rsolu :
+ =
=

cos sin ' sin ' sin sin
cos sin ' cos ' cos cos
2
2
Y X Y Y
Y X X X
S
S

( ) sin sin cos cos sin cos '
2 2
S S
Y Y X X X + = +
Donc ( ) ( ) sin cos '
S S
Y Y X X X + =
De la mme manire :
+ =
+ = +

2
2
cos ' cos sin ' cos cos
sin ' cos sin ' sin sin
Y X Y Y
Y X X X
S
S

Donc ( ) ( ) cos sin '
S S
Y Y X X Y + =

La figure dans R a un axe de symtrie qui est laxe des abscisses. Par consquent, tout point dans
lespace SCD a son symtrique dans lespace SCD. Un point se situe dans lespace SCDC sil est
dans SCD ou si son symtrique, suivant laxe des abscisses, est dans SCD. Dterminer les
coordonnes du point C permet de dterminer lespace SCD. Pour dterminer les coordonnes du
point C, il est ncessaire de dterminer les coordonnes du point . En effet, est la projection
orthogonale de C sur laxe des abscisses. Donc u k S
r
= avec kR (ensemble des rels). Le
lemme 5-1 permet de dterminer les coordonnes du point .

|
|
\
|
|
|
\
|
+
|
|
\
|
=
|
|
\
|
'
'
cos sin
sin cos
Y
X
Y
X
Y
X
S
S

128
Lemme 5-1 : a les coordonnes suivantes dans R :
0 ' ,
tan tan
tan
' ' =
+
=

Y X X
D

Dmonstration :
D S SD + =

tan tan
tan
tan tan tan
tan tan
+
=
= +
=
SD S
SD S S
D S

A partir du lemme 5-1, les coordonnes du point C dans R peuvent tre facilement dduites. Le point
C a les coordonnes suivantes : X
C
= X
, Y
C
= X
tan
En connaissant les coordonnes du point C, chaque nud du rseau peut ainsi dterminer la partie
SCD de la zone de recherche. A partir de cela, un nud doit pouvoir savoir sil se situe dans cette zone
ou non. Pour dterminer si un nud quelconque se situe dans la zone de recherche, nous dfinissons
un endomorphisme retournant son symtrique par rapport laxe des abscisses. Nous appelons F cet
endomorphisme dun R-espace vectoriel E. F est dfini par :
v x u x
E
v x u x X
E F
r r
r r
2 1
2 1
:

+ =

Un nud peut propager une requte sil se situe dans lespace de recherche SCDC. Par consquent,
un nud M quelconque est dans cet espace sil se trouve dans SCD ou son symtrique est dans SCD.
Un nud M de coordonnes (X, Y) dans R est dans SCD si ses coordonnes respectent le systme
suivant :

+
+
2 2
1 1
' '
' '
0 '
b X a Y
b X a Y
Y
(5-1)
o
S C
S C
X X
Y Y
a
' '
' '
1
= ,
S C
S C C S
X X
X Y X Y
b
' '
' ' ' '
1
= ,
D C
D C
X X
Y Y
a
' '
' '
2
=
,
D C
D C C D
X X
X Y X Y
b
' '
' ' ' '
2
= .

129
Le thorme 5-4 permet de dterminer si un nud quelconque se situe dans lespace de recherche. Si
tel est le cas, ce nud peut relayer les informations de routage.
Thorme 5-4 : Un nud M de coordonnes (X, Y) dans R est dans lespace de recherche si
X, Y respecte lquation (5-1) ou ( ) SM F respecte lquation (5-1).
5.2.3 Protocole de dcouverte de route
Le protocole que nous proposons est bas sur le protocole AODV. Son fonctionnement en est trs
proche. A la diffrence du protocole AODV, un nud vrifie sil est situ dans la zone de recherche
avant de transmettre un paquet RREQ.
Lorsquun nud source a besoin de crer une route vers un nud destination, il dtermine 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 localise travers le rseau backbone. Dans un
tel cas, la source tente dtablir une route avec la destination en utilisant le protocole AODV c'est--
dire que la source diffuse une requte RREQ lensemble des nuds du rseau. Si le nud source S a
dtermin les coordonnes (X
D
, Y
D
) de la destination D, il cre une requte RREQ. La requte RREQ,
transmise par notre protocole, est diffrente de celle dAODV. Elle contient des champs
supplmentaires qui sont les suivant : coordonnes du nud source, coordonnes du nud destination,
valeur de , valeur de (dans le cas dune forme en cerf-volant).
Quand un nud intermdiaire I reoit une requte RREQ (figure 5-10), il calcule lespace de
recherche. Sil dtermine quil se situe lintrieur de cet espace (avec le thorme 5-2 ou le
thorme 5-3 pour une forme triangulaire, ou le thorme 5-4 pour une forme en cerf-volant) il
transmet la requte RREQ. Un nud ayant dj reu une requte RREQ supprime la requte.
Notre protocole rduit le nombre de nuds qui transmettent des informations de routage. De fait, il est
possible quaucune route ne soit trouve sil en existe une. Pour viter un tel cas, un temporisateur est
positionn par la source lors de lenvoi de la requte RREQ. A lexpiration du temporisateur, le nud
source peut raliser une nouvelle tentative ou utiliser le protocole AODV. En fait, les valeurs de ou
peuvent tre choisies pour privilgier le cot ou la probabilit dobtention dune route. Plus ou
sont levs, plus lespace de recherche est grand (et plus le nombre dinformations de routage est
important).

130

Figure 5-10 : Organigramme utilis par un nud intermdiaire
5.2.4 Complexit en messages
Dans cette section, nous analysons le nombre dinformations de routage changes lors de la cration
dune route par notre protocole de routage, suivant quil 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 possde la mme complexit que le protocole AODV. En effet,
lorsque la totalit des nuds du rseau sont dans la zone de recherche, ils transmettent chacun, une
seule fois, un paquet RREQ. Par consquent, pour N nuds dans le rseau, le nombre de messages
transmis est de N-1 car seule la destination nen transmet pas.
Le nombre moyen dinformations de routage changes lors de la recherche dune route est fonction
du nombre moyen de nuds transmettant ces informations. Pour cela, nous supposons que N nuds
sont uniformment rpartis dans le rseau. Un nud se trouve dans la zone de recherche de forme
DEBUT
RREQ reu dun nud I ?
oui
non
Dj reu un RREQ ?
oui non
- Crer une
nouvelle route
dans la table des
chemins inverses
nss identique mais chemin
inverse plus court ?
Supprimer
la requte
- Mettre jour lentre de la table des chemins inverses
correspondant la destination
- Diffuser la requte
RREP reu?
non
oui
une entre dans la table de
routage pour la destination
oui non
- Crer une nouvelle
entre dans la table de
routage
- Mettre jour lentre
Suis-je dans lespace de
recherche ?
Supprimer
la requte
oui
nss plus rcent ?
oui non
oui non
- Mettre jour lentre de la
table des chemins inverses
- Supprimer la requte
non
- Transmettre le RREP au nud prcdent
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 A
ZR
la surface faisant lintersection entre la zone de recherche et
la surface globale du rseau. Pour une zone de recherche triangulaire (respectivement en forme de
cerf-volant) A
ZR
= A
SCC
(respectivement A
ZR
= A
SCDC
).
La probabilit que la position dun nud quelconque M soit dans la zone de recherche est :
( ) ( )
G
ZR
A
A
ZR M pos P =
avec A
G
la surface globale du rseau.
Comme les nuds source et destination sont toujours situs dans la zone de recherche, au moins deux
nuds sont dans la zone de recherche. Le nombre moyen de nuds situs dans la zone de recherche,
note K, est :
( ) ( )
(
2 ( 2 + = ZR M pos P N K (5-2)
Daprs lquation (5-2), si les nuds possdent au moins un lien avec un autre nud (diffrent de la
destination), le nombre de messages RREQ moyen chang est gal K-1.
5.2.5 Simulations
lefficacit de notre protocole aux protocoles AODV et LAR (cf. 2.3.1). Notre protocole utilisant la
forme gomtrique en triangle (respectivement en cerf-volant) est appel protocole 1 (respectivement
protocole 2). Langle prend comme valeur par dfaut 20. Dans nos simulations, la valeur de langle
du protocole 2 est la mme que la valeur de langle . La distance est toujours nulle quelque soit le
protocole.
Pour la ralisation de ces simulations, nous utilisons les mmes hypothses que celles utilises dans le
paragraphe 5.1.1.3. Le rseau est compos dun nombre variable de nuds suivant la simulation
effectue. Les nuds se dplacent 5m/s. Le rayon de couverture dun nud ad hoc est de 150mtres.
Les nuds sont rpartis dans une zone carre de 1000m de ct. Ils utilisent pour se dplacer le
modle RWP (cf. 1.4) avec un temps de pause de 200 secondes entre dplacements. Le dbit du
rseau est de 2Mb/s. La simulation utilise un modle de communication dans lequel la moiti des
nuds communiquent avec lautre moiti. La dure dune simulation est de 500 secondes.
Dans un premier temps, nous comparons la russite dterminer une route pour chacun de ces
protocoles. Suivant le nombre de nuds, le pourcentage de dcouverte de route volue. Le protocole
AODV est le seul protocole capable dans ces simulations pouvoir toujours retourner une route sil en
existe une.

132
La figure 5-11 montre le comportement des 4 protocoles dterminer une route. Lorsque le nombre de
nuds est faible, lensemble des protocoles a des difficults trouver une route. Pour 10 et 30 nuds
rpartis dans le rseau, les nuds sont bien trop disperss pour quun nombre important de routes
soient trouves. Dans ces deux scnarios, les protocoles 1 et 2 sont incapables de dterminer une route.
Le protocole LAR suit la progression du protocole AODV. Avec laugmentation du nombre de nuds,
le pourcentage de dcouverte dune route crot. Le protocole AODV trouve toujours une route partir
dun nombre de nuds gal 50. Le protocole LAR fait trs souvent de mme. Toutefois, on peut
constater qu 150 et 200 nuds, il possde un pourcentage trs faible dchec lobtention de routes.
Bien que ce protocole soit trs proche dAODV, il nest pas fiable 100%. Pour nos protocoles, le
pourcentage de dcouverte dune route crot avec laugmentation du nombre de nuds. En effet, nos
protocoles sont efficaces dans des environnements denses. Le protocole 2 a un pourcentage dchec
suprieur notre protocole 1 cause de sa plus petite zone de recherche. A partir de 150 nuds, nos
protocoles trouvent quasiment toujours une route sil en existe une.

Figure 5-11 : Pourcentage dchec la dtermination dune route en fonction du nombre de nuds du
rseau.
La figure 5-12 montre lvolution du pourcentage dchec la dtermination dune route en fonction
de la taille de la zone de recherche. On remarque quavec laccroissement de langle , le pourcentage
dchec diminue plus vite. Ainsi pour = 30, le protocole 1 trouve toujours une route partir de 100
nuds. Le protocole 2, ayant une zone de recherche plus restreinte que celle du protocole 1, a toujours
plus de difficults trouver une route. Pour un angle gal 10, langle est bien trop resserr pour
tre efficace mme dans des environnements denses.
0
20
40
60
80
100
120
10 30 50 75 100 150 200
E
c
h
e
c

t
r
o
u
v
e
r

u
n
e

r
o
u
t
e

(
%
)

133

Figure 5-12 : Pourcentage dchec trouver une route suivant langle utilis pour calculer la taille de
la zone de recherche.

Figure 5-13 : Nombre moyen de requtes ncessaires la dcouverte dune route
Le pourcentage dchec dterminer une route tant diffrent pour nos protocoles, lintrt de
comparer le nombre de requtes sur lensemble des simulations na que peu dintrt. Nous comparons,
par consquent, le nombre moyen de requtes requises la dtermination dune connexion. La figure
5-13 donne le nombre moyen de requtes par connexion pour lensemble des protocoles simuls. Le
protocole AODV possde un nombre moyen de requtes assez important. Pour chaque dcouverte de
route, lensemble des nuds du rseau (priv de la destination) relaient le paquet RREQ transmis par
la source. Ainsi pour une topologie de 100 nuds, le nombre de requtes ncessaires la
dtermination dune route est de 99. Tout de mme, ce nombre moyen est plus lev, car il tend vers
130 pour 100 nuds. En fait, il est possible que le protocole AODV choue trouver une route, lors
de la premire 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, aprs un certain temps dattente, une nouvelle tentative. Ce
constat accrot le nombre de requtes 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 nuds

134
que le protocole LAR dans tous les scnarios. Le protocole 2 est particulirement performant cause
de sa zone de recherche trs restreinte.
La figure 5-14 montre le nombre moyen de requtes en fonction de la taille de la zone de recherche.
Le nombre moyen de requtes crot avec la taille de la zone de recherche (dpend de langle ).
Quelque soit langle slectionn (10, 20 ou 30), nos deux protocoles gnrent moins de requtes que
le protocole LAR. Avec laccroissement de la densit du rseau, le nombre de requtes crot. En effet,
plus la zone de recherche est grande, plus le nombre de nuds qui relaient les paquets de routage est
important.

Figure 5-14 : Nombre moyen de requtes par connexion en fonction de la taille de la zone de
recherche
5.2.5.1 Discussion
Le but premier dun protocole de routage est de dterminer une route sil en existe une. Nos deux
protocoles, bien quefficaces en termes de paquets de routage changs, possdent un taux dchec
dobtention de routes bien trop important. Utiliser un angle initial plus important permet de pallier
ce problme, mais ce nest pas une solution. En effet, utiliser un angle de dpart plus grand fait
tendre le nombre de requtes utilises vers celui du protocole AODV.
Tout de mme, les formes gomtriques proposes sont efficaces dans des environnements denses.
Dans de tels environnements, une route est, quasiment toujours, trouve. Les formes gomtriques
sont bien adaptes 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 rseaux
MANETs. Il est ncessaire dy apporter des modifications pour quil puisse dterminer une route
quelque soit la densit de lenvironnement dans lequel les nuds 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, rduisant lespace de recherche, diminuent le nombre dinformations de contrle
ncessaire la dcouverte dune route. En effet, seulement les nuds susceptibles de fournir une route
vers la destination transmettent des requtes de cration de route. Une rduction de lespace de
recherche peut engendrer dans certains cas un chec lors de la dcouverte des routes mme si une
route existe. Le but premier dun protocole de routage est de trouver une route sil en existe une. Les
rsultats obtenus (cf. 5.2.5) montrent quavec un faible espace de recherche lchec 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 dune telle recherche est daccrotre la taille de la zone de recherche en
cas dchec lors de la dcouverte dune route. Un tel type de protocole permet ainsi doptimiser le
nombre dinformations de routage, tout en assurant la dcouverte dune route sil en existe une. Le
protocole AODV utilise une recherche de parcours en largeur (cf. 2.1.2.1) c'est--dire quil ralise
une dissmination de linformation en largeur. Lorsquune route nest pas trouve lors dune tentative,
il accroit le nombre de sauts quune requte RREQ peut atteindre. Nos deux protocoles sont diffrents
puisquils proposent une dissmination de linformation en profondeur. Lors dune tentative, si aucune
route nest trouve, le protocole accrot lespace de recherche en largeur augmentant ainsi le taux de
russite de dcouverte dune route.
Le premier protocole est un protocole de routage optimal (il garantit de dcouvrir une route sil en
existe une). Ce protocole permet de diminuer le nombre dinformations de routage ncessaires la
dcouverte dune route dans bien des cas.
Le deuxime protocole de routage est un protocole optimisant le nombre dinformations de routage.
Ce protocole est parfois dans lincapacit de retourner une route, mme sil en existe une. Mais un tel
cas est particulirement 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-mme. Ces comparaisons sont ralises
suivant plusieurs critres : le nombre dinformations de routage changes, le nombre de tentatives
pour trouver une route et le taux de russite dterminer une route.
5.3.1 Proprits de la zone de recherche
Le protocole AODV, avec un parcours de recherche en largeur, limite la dissmination des
informations de contrle en profondeur. En supposant que le nud source connait la position de la
destination, il peut dterminer la distance le sparant de la destination. Si la totalit des nuds du
rseau utilisent le mme rayon de couverture, le nombre de sauts maximal, not NH
max
, sparant la
source de la destination est connu. A partir de NH
max
, le protocole AODV (utilisant un parcours de

136
recherche en largeur) peut tre amlior. Pour cela, le nud source doit initier, pour joindre la
destination, lenvoi dun paquet RREQ avec un TTL gal NH
max
.
Le protocole AODV dissmine linformation la totalit des nuds prsents dans un rayon quivalent
un certain nombre de sauts. Par consquent, la dissmination de cette information est propage des
nuds situs loppos de la position de la destination. Ces nuds interviennent rarement dans la
dcouverte dune 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, lespace de recherche est restreint la forme reprsente par la figure
5-15. Lespace de recherche est fonction de deux paramtres variables et . Lorsquune tentative
choue trouver une route, ces paramtres sont accrus pour augmenter la taille de lespace de
recherche. Seuls les nuds prsents dans lespace de recherche sont susceptibles de transmettre une
requte RREQ de dcouverte des routes.

Figure 5-15 : Zone de recherche avec un angle aigu (a) et un angle obtus (b)
Les agrandissements successifs de lespace de recherche influent sur le dlai dobtention dune route.
Pour que le protocole soit suffisamment ractif, les paramtres et doivent crotre rapidement entre
deux tentatives. Ils suivent donc une croissance exponentielle.
Pour dterminer une valeur de ]0,180], lors de la i
me
tentative, nous utilisons la formule suivante :
180 si 180
1
1
start
i
start
i
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
daccrotre exponentiellement la valeur de .
Lorsque = 180, notre algorithme doit explorer la totalit du rseau, c'est--dire quil possde la
mme zone de recherche que le protocole AODV. De fait, la valeur de dpend, intrinsquement, de
la valeur du paramtre . Pour calculer la valeur de , nous supposons que le rseau a une distance

137
maximale gale Dmax et que les nuds possdent le mme rayon de couverture R. La valeur de
varie de faon exponentielle avec le nombre de tentatives ncessaires lobtention dune route. Lors
de la i
me
tentative,
i
suit la progression donne par lquation suivante :
<
=
sinon
180 si
max
1
D
R
i
i
(5-4)
avec
1
=
Start
et N (ensemble des entiers naturels).
Pour conserver la compatibilit avec le protocole IP, il est ncessaire de dfinir un TTL dans lentte
des paquets IP. Le TTL nest pas le paramtre limitant la zone de recherche. En effet, seuls les nuds
situs dans la zone de recherche transmettent les requtes RREQ. Nous limitons le TTL avec le
nombre de nuds 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 rseau).
Pour dterminer la valeur du TTL, il est ncessaire de calculer le nombre de sauts maximal sur une
distance
i
SD Dist + = . Dist reprsente 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 lquation suivante :
1 2 +
(

(
(
(
R
Dist
NH
R
Dist
(5-5)
Dmonstration :
La borne infrieure (le cas le plus favorable) est facilement obtenue. Elle correspond au cas o chaque
nud du chemin est au bord de la zone de couverture du nud prcdent. Ainsi, deux nuds du
chemin sont spars 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 suprieure reprsente le pire cas dun chemin P=<v
1
, v
2
, v
3
, , v
n
>. Pour obtenir
le nombre de sauts maximal sur une distance Dist, il est ncessaire dobtenir la distance minimale que
peut avoir un sous-chemin P=<v
i
,v
i+1
,v
i+2
>. La distance minimale dun tel sous-chemin est
reprsente quand la distance sparant v
i
de v
i+1
est gale et la distance sparant v
i
de v
i+2
est gale
R + . Ainsi, le nud v
i+1
doit relayer le paquet de vi pour quil atteigne v
i+2
. Par consquent, le
nombre de saut est gal 2 lorsque 0. Le nombre de sauts maximum sur une distance Dist est donc
major par
1 2 +
(
R
Dist
.
Ainsi, le nombre de sauts est born par : 1 2 +
(

(
(
(
R
Dist
NH
R
Dist
.

138
Lorsque [0, 90[, nous majorons TTL
i
avec la formule suivante 1 2 +
(
=
R
Dist
TTL
i
. Dans bien
des cas, cette valeur est bien trop leve car elle reprsente, dans le pire des cas, le nombre de sauts
prsents sur une distance gale Dist. Il est impossible de dterminer un nombre de sauts plus prcis
sans connatre la topologie du rseau.
Le TTL sert galement dfinir le temps dattente de la source, not TEMPS_TRAVERSE, pour
dtecter un ventuel chec lors de la recherche dune route. Le temps dattente est donn par la
formule suivante :
TEMPS_TRAVERSE = 2 (TTL + TEMPS_ATTENTE) TEMPS_ NUD (5-6)
avec TEMPS_ATTENTE un paramtre qui augmente le temps dchance en cas de congestion sur un
nud, et TEMPS_NOEUD une estimation du temps moyen de la traverse dun saut par un paquet.
5.3.2 Protocole optimal
Le premier protocole propos est optimal (il retourne une route sil en existe une). Ce protocole rduit
en moyenne le nombre de requtes ncessaires lobtention dune 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 mmes champs que le protocole AODV.
Les champs de la requte RREQ par contre diffrent de ceux utiliss par le protocole AODV. Les
diffrents champs sont : adresse source, numro de squence source, position du nud source, adresse
de destination, numro de squence de destination, position du nud destination, identifiant de requte,
nombre de sauts, valeur de et la valeur de . La surcharge rajoute dans lentte des requtes est,
donc, faible.
Notre protocole diffre de AODV par sa gestion de lespace de recherche. Lors dune tentative si la
source ne trouve pas de route, elle agrandit cette zone en augmentant la valeur des paramtres et
(cf. quation (5-3) et quation (5-4)). Le paramtre est le paramtre limitant. Au del de 180, le
nud source interrompt sa recherche. Si aucune route na t trouve, alors aucune route nexiste. A
partir de la valeur de
START
, le nombre maximal de tentatives ralises par le protocole, (not z), est
donn par lquation suivante :
( ) ( ) ln 180 ln
1
ln
START
z

(
= +
(
(
(5-7)

Dmonstration :
On dsire trouver un entier z tel que la valeur de
z
est gale 180. De fait,

139
( ) ( ) ( )
( ) ( )
( )
1
ln
ln 180 ln
180
ln ln 1 ln
180
180
1
1
1
+
(
(
(

=
|
|
\
|
= =
=
= =

START
START
z
START
z
START
z
z
z
z

Le protocole est dcoup en deux phases. La premire phase consiste en la dcouverte des routes. La
deuxime consiste en leur maintenance.
5.3.2.1 Phase de dcouverte des routes
La figure 5-16 donne lorganigramme utilis par le nud source pour la dcouverte dune route. Si
elle ne possde pas dj une route, elle transmet une requte RREQ aprs avoir initialis ces champs.
Pour cela, la source insre dans la requte ses coordonnes gographiques ainsi que les coordonnes
de la destination. Elle initialise le nombre de sauts, la valeur de
START
et enfin la valeur de
START
. Elle gnre un nouveau numro de squence source et un nouvel identifiant de requte et met
jour la requte en consquence. En fonction de la distance la sparant de la destination et de la valeur
de , elle calcule le temps dattente ncessaire une nouvelle tentative (cf. quation (5-6)). Elle
initialise le temporisateur Trep cette valeur et le dclenche lors de la diffusion de la requte. Elle se
met ensuite en attente dune rponse RREP. Si une telle rponse arrive avant lchance du
temporisateur alors une route est trouve et elle peut commencer mettre ses donnes. Par contre, si
le temporisateur arrive chance aucune route na t trouve. Dans un tel cas, elle accrot la zone
recherche en augmentant la valeur de (cf. quation (5-3)) et (cf. quation (5-4)). Elle gnre un
nouveau numro de squence et un nouvel identifiant de requte car cette recherche est totalement
indpendante de la prcdente. Ainsi, les nuds intermdiaires ayant dj reu une requte RREQ
dune tentative prcdente peuvent traiter cette requte car son identifiant est diffrent. Lorsque
atteint 180, la requte explore lensemble de lespace de recherche. Si aucune route nest trouve,
alors aucune route entre la source et la destination nexiste. Le nud source prvient la couche
suprieure de son chec.

140

Lalgorithme utilis par un nud intermdiaire est identique lalgorithme propos sur la figure 5-10
(cf. 5.2.3). Lorsquun nud intermdiaire reoit une requte RREQ, il met jour sa table des
chemins inverses pour la destination ou cre une entre si aucune nexiste. La table des chemins
inverses est mise jour seulement si le numro de squence source de la requte reue est plus rcent
ou quil est identique mais que le nombre de sauts le sparant de la source est plus faible. Ensuite, il
vrifie sil a dj reu la requte. Si une requte a dj t reue (c'est--dire quil a dj reu une
requte RREQ avec le mme identifiant de requte) alors il la supprime. Dans le cas inverse, il
dtermine sil se situe dans la zone de recherche. Si tel est le cas, il transmet cette requte sinon il la
supprime.
DEBUT
- Crer un RREQ
- Gnrer un nouvel
identifiant de requte
- Gnrer un nouveau
numro de squence
de la requte
- Initialiser i
- Initialiser temporisateur
Trep=TEMPS_TRAVERSE
- Dclencher Trep
oui
non
Trep expir?
non
oui
- i++
- Calculer
i
- Calculer
i
- Calculer le TTL
- Crer un RREQ
- Gnrer un nouveau
numro de squence
- Gnrer un nouvel
identifiant de requte
- Mettre jour la requte
Informer la couche
suprieure
Traitement des
donnes
une route?
oui non
RREP reu ?
RERR reu?
Transfert des
donnes
oui non
i > NbreMaximalTentative
oui

141
A la rception dun paquet RREP, le nud intermdiaire met jour sa table de routage si le numro de
squence de la destination est plus rcent que celui contenu dans sa table de routage ou sil est
identique mais avec un nombre de sauts plus faible. Il interroge ensuite sa table des chemins inverses
pour savoir vers quel nud il doit envoyer le paquet RREP, pour quelle joigne le nud source.
La phase de maintenance reste trs proche de celle utilise par le protocole AODV. Lorsquun nud
dtecte la rupture dun lien, il met lensemble des nuds sources, dont la route vers un nud
destination passe par lui, un paquet RERR. A la rception dun tel paquet, un nud source recre une
route en utilisant la phase de dcouverte (cf. 5.3.2.1).
Si le nud source utilise notre protocole localisation (cf. 5.1.1), il connat une position relativement
rcente de la destination pour recrer une route sans rechercher ses coordonnes gographiques. Par
contre, si un autre protocole de localisation est utilis, la destination peut envoyer priodiquement sa
position (ainsi que sa vitesse de dplacement, sa direction) au nud source dans un paquet de
dplacement. Un tel paquet peut prendre la route contenue dans la table des chemins inverses pour
rejoindre le nud 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 calcule dans deux cas. Le premier cas consiste au pire cas, cest--dire le nombre
maximal de messages changs par les nuds. Le second cas donne le nombre moyen de messages
changs par les nuds du rseau avec notre protocole. Dans ces deux cas, notre protocole de routage
est fonction du nombre de nuds prsent dans la zone de recherche.
Dans le pire cas, le calcul du nombre de messages changs par les nuds lors dune 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 requtes changes lest galement. Le nombre maximal de tentatives est
not z (cf. quation (5-7)).
Par la suite nous supposons que le rseau possde N nuds. Dans le pire des cas, lors des z-1
tentatives aucune route nest trouve. Une route est trouve lors de la z
me
tentative. Pour quune route
ne soit pas trouve, il est ncessaire que la destination ne reoive aucune requte RREQ. Pour cela, il
faut quau moins un nud (outre la destination) soit en dehors de la zone de recherche. Dans le pire
cas, ce nud est le seul pouvoir crer une route avec la destination. Par consquent dans les z-1
premires tentatives, deux nuds ne transmettent jamais de requte la destination et le nud
empchant la dcouverte dune route. A partir dun tel constat, le calcul du nombre de messages dans
le pire cas est donn par lquation suivante :
( ) 1 2
1
+ N z NM
PireCas
(5-8)
Dans le deuxime cas, nous calculons le nombre de messages maximum lorsque N nuds sont

142
uniformment rpartis dans le rseau. Nous notons SA
i
la zone de recherche lors de la i
me
tentative. Un
nud est situ dans SA
i
si sa position se trouve dans la zone de recherche. La probabilit P(i )
quun nud M soit situ dans la zone de recherche lors de la i
me
tentative est :
( ) ( ) ( )
G
SA
i
A
A
SA M pos P i P
i
= = (5-9)
o A
G
la taille globale du rseau et
i
SA
A lintersection entre la zone de recherche de la i
me
tentative et
la zone globale du rseau.
La source et la destination sont toujours dans SA, par consquent il y a toujours au moins deux nuds
dans la zone de recherche. En moyenne le nombre de nuds dans SA
i
, not K
i
, est :
( ) ( ) 2 2 + = i P N K
i
(5-10)
Comme la destination ne transmet jamais de paquet RREQ, lors de chaque tentative K
i
-1 paquets sont
transmis. Le nombre maximal de messages changs par les nuds dans le pire cas lorsque les nuds
sont uniformment rpartis est :
( ) ( ) ( )
=
+ =
z
i
onUniforme Distributi
i P N NM
1
1
1 2 (5-11)

5.3.3 Protocole conciliant taux de dcouverte des routes et
dissmination dinformations de routage
Nous proposons dans cette partie un protocole non optimal la diffrence du premier protocole. Ce
protocole allie parfaitement un faible nombre dinformations de routage ncessaires la dcouverte
dune route et taux dobtention dune route. Lors de laccroissement de la zone de recherche, seuls les
nuds nayant pas reu de requte durant les tentatives prcdentes peuvent propager les requtes
RREQ (sils sont situs dans la zone de recherche). Une route peut ne pas tre dcouverte lorsquun
nud ayant une route avec la destination ne peut tre joint uniquement par un nud dans la zone de
recherche dune tentative prcdente (figure 5-17). Dans cet exemple, un nud source S souhaite
obtenir une route pour le nud destination D. Lors de la premire tentative (formalis par la zone de
recherche 1) seul 2 nuds (nuds B et C) transmettent la requte RREQ car ils sont situs dans la
zone de recherche. Lors de la deuxime tentative (zone de recherche 2) aucun nud ne fait la jointure
avec le nud A qui est le seul nud pouvoir crer une route avec la destination. En effet, les deux
nuds dans la zone de recherche 1 ne peuvent pas mettre la requte reue lors de la deuxime
tentative puisquils en ont dj mis une lors de la premire. Le nud A ne sera par consquent jamais
averti de la demande dune route pour joindre D. Lobtention dune route chouera quelque soit le
nombre de tentatives.

143

Figure 5-17 : Echec de la dcouverte dune route alors quune existe.
Ce protocole est bas sur le protocole AODV. Par consquent, il utilise deux tables (une table des
chemins inverses et une table de routage) contenant les mmes champs que le protocole AODV.
Comme pour le protocole optimal, les champs de la requte RREQ diffrent de ceux utiliss par le
protocole AODV. Les diffrents champs sont : adresse source, numro de squence source, position
du nud source, adresse de destination, numro de squence de destination, position du nud
destination, identifiant de requte, nombre de sauts, valeur de et valeur de .
Ce protocole est divis en deux phases. La premire est la phase de dcouverte de route, alors que la
seconde est la phase de maintenance.
5.3.3.1 Phase de dcouverte des routes
Lalgorithme utilis par le nud source est prsent sur la figure 5-18. Il diffre lgrement de
lalgorithme propos pour le protocole optimal. En effet cette fois, les nuds intermdiaires ne doivent
transmettre quune seule requte quelque soit la tentative. Lorsque le nud source dsire trouver une
route vers un nud destination, ile cre une requte RREQ et gnre un nouvel identifiant de requte
et un nouveau numro de squence. Quelque soit la tentative, le numro de squence source et
lidentifiant de requte restent inchangs. 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, aprs avoir dfini le temps dattente ncessaire une nouvelle tentative (cf. quation (5-6)). Si
un paquet RREP arrive avant lchance de Trep alors une route est trouve. Sinon, il agrandit
lespace de recherche la valeur de (cf. quation (5-3)) et la valeur de (cf. quation (5-4)). Une
nouvelle requte RREQ est transmise en conservant le mme identifiant de requte et le mme numro
de squence source.

144

A la rception dune requte RREQ, le nud intermdiaire a le mme fonctionnement quun nud
intermdiaire du protocole optimal. Dans un premier temps, il compare les identifiants de requte
reue avec lidentifiant de la requte. Si un des identifiants correspond lidentifiant de la requte,
dans ce cas il la dj reu et la supprime aprs avoir mis jour, si ncessaire, sa table des chemins
inverses. Dans le cas inverse, il vrifie quil se situe dans la zone de recherche et si tel est le cas il
diffuse la requte aprs avoir mis jour sa table des chemins inverses. La grande diffrence avec le
protocole optimal est que lidentifiant de la requte change lors de chaque tentative. Ainsi, un nud
intermdiaire ne traite quune seule requte RREQ quelque soit la tentative.
La phase de maintenance est identique celle propose par le protocole AODV. Lorsquun nud
dtecte la rupture dun lien, il informe les nuds sources, dont les communications passent par lui, des

145
nuds destination dont la route est rompue. Pour cela, un paquet RERR est envoy. A la rception
dun paquet RERR, le nud source recre les routes si cest ncessaire.
5.3.3.3 Complexit en termes de messages
Deux cas sont utiliss pour prsenter la complexit en termes de messages changs par les nuds
prsents dans le rseau. Ces nuds utilisent le protocole prsent dans le paragraphe 5.3.3. Le
premier cas dtermine le nombre de messages dans le pire des cas. Le deuxime cas dtermine le
nombre de messages changs dans le pire des cas lorsque les nuds sont uniformment rpartis dans
le rseau.
On suppose par la suite que N nuds sont prsents dans le rseau. Avec ce protocole, chaque nud du
rseau (except la destination et la source) transmet une seule fois une requte RREQ. Par contre, le
nud source transmet lors de chaque tentative une requte RREQ. Le nombre maximal de tentatives
est not z (cf. quation (5-7)). La formule suivante donne le nombre de messages changs dans le pire
cas :
z N NM
PireCas
+ = 2
2
(5-12)
Dans le cas dune distribution uniforme des nuds dans le rseau, les nuds prsents dans la zone de
recherche et qui peuvent transmettre le paquet RREQ, lors de la i
me
tentative, sont les nuds prsents
dans la zone de recherche de la i
me
tentative prive des nuds prsents dans la zone de recherche de la
i-1
me
tentative. Nous notons i SA la surface SA
i
moins la surface SA
i-1
(c'est--dire
1
=
i i
i SA SA SA )
avec SA
0
= 0. La probabilit quun nud quelconque M nait transmis aucune requte et quil se situe
dans la i
me
zone de recherche est :
( ) ( ) ( )
G
SA
i
A
A
SA M pos P i P
i
= = (5-13)
Par consquent lorsque les nuds sont uniformment rpartis dans le rseau, le nombre de messages
changs est le suivant :
( ) ( ) ( ) ( ) ( ) z z P N i P N NM
z
i
onUniforme Distributi
+ = + =
=
2 1 2
1
2
(5-14)
5.3.4 Simulations
lefficacit 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, lincrmentation du TTL est de 2 chaque nouvelle tentative.

146
Le rseau est compos dun nombre variable de nuds suivant la simulation effectue. Les nuds se
dplacent 5m/s. Le rayon de couverture dun nud ad hoc est de 150mtres. Les nuds sont rpartis
dans une zone carre de 1000m de ct. Ils utilisent pour se dplacer le modle RWP (cf. 1.4) avec
un temps de pause de 200 secondes entre dplacements. Le dbit du rseau est de 2Mb/s. La
simulation utilise un modle de communication dans lequel la moiti des nuds communiquent avec
lautre moiti. La dure dune simulation est de 500 secondes.
Tout dabord, nous vrifions que nos protocoles prsentent le mme pourcentage dchec dobtention
dune route que le protocole AODV. La figure 5-19 montre le pourcentage dchec en fonction du
nombre de nuds prsents sur le rseau. Lorsque la topologie du rseau possde un nombre de nuds
trop faible pour permettre une connectivit acceptable entre les nuds, les diffrents protocoles ont le
mme taux dchec. A partir de 75 nuds, lensemble des protocoles trouvent toujours une route. Par
contre pour 50 nuds, le protocole sous optimal choue trouver certaines routes. Il a 15% dchec
dterminer une route.

Figure 5-19 : Pourcentage dchec la dcouverte dune route
La figure 5-20 donne le nombre de requtes changes pour dterminer une route suivant diffrentes
topologies de rseau. Le protocole AODV est le protocole qui retourne le plus grand nombre de
requtes. La dcouverte dune route nest pas toujours immdiate, ainsi le protocole AODV peut faire
plusieurs tentatives avant de dterminer une route. La diffusion des paquets de routage sur le rseau
entrane de nombreuses collisions qui obligent la source ritrer sa recherche et ainsi augmente
grandement le nombre de requtes. Le protocole AODV avec parcours en largeur possde galement
un nombre consquent de requtes changes. En fait, ce protocole est trs efficace lorsque la source
est proche de la destination. Par contre, lorsquils sont loigns, le nombre de requtes changes
devient important. Avec une moyenne de 3.5 sauts sparant la source et la destination, le protocole
ncessite au moins trois tentatives pour trouver une route. Sur des rseaux denses, ces diffrentes
tentatives sont trs coteuses. Par contre, ce protocole est beaucoup moins sensible aux dplacements
des nuds que le protocole AODV. En effet, la source conserve le nombre de tentatives quil lui a
fallu pour dterminer la destination. Lorsquune route est rompue, la source peut ajuster au mieux le
TTL du paquet et ainsi retrouver une route efficacement. Tout de mme, nos protocoles utilisent bien
moins de paquets de routage pour dterminer une route. Le protocole optimal est particulirement
0
20
40
60
80
100
120
10 30 50 75 100 150 200
E
c
h
e
c

d
e

d
c
o
u
v
e
r
t
e

d
u
n
e

r
o
u
t
e

(
%
)

147
performant. Il utilise 6 fois moins de paquets de routage pour dterminer un chemin. Bien que le
protocole sous-optimal ne peut pas tre compar sur lensemble des topologies (puisque pour 50
nuds, il narrive pas dterminer toutes les routes), sur les topologies avec un nombre de nuds
suprieur 50 il opre efficacement. En effet, le nombre de paquets de routage est trs faible. Il rduit
de prs de 9 fois le nombre de paquets de routage changs compar au protocole AODV.

Figure 5-20 : Nombre requtes transmises sur le rseau pour la dcouverte des chemins
La figure 5-21 met en vidence le nombre moyen de requtes ncessaires lobtention dune route, en
fonction du nombre de nuds du rseau. Nous calculons ce nombre moyen uniquement lors de la
premire recherche de route pour chaque connexion. Cela vite au protocole AODV avec parcours en
largeur davoir une connaissance plus ou moins juste du nombre de sauts sparant la source de la
destination. Les deux modes du protocole AODV ont des nombres moyens de requtes assez proches.
Nos deux protocoles ont un nombre moyen de requtes extrmement faible (environ le quart du
nombre de nuds composant le rseau pour le protocole optimal).

Figure 5-21 : Nombre moyen de requtes pour la dtermination dun 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 nuds
N
o
m
b
r
e

d
e

r
e
q
u
t
e
s
0
50
100
150
200
250
300
350
10 30 50 75 100 150 200

148
5.4 Discussion
De nombreux protocoles de routage rduisent lespace de recherche en supposant connatre la position
de la destination. Dterminer la position de la destination ne doit pas consommer plus de bande
passante quavec lutilisation dun protocole ne rduisant pas lespace de recherche. Notre protocole
de localisation de la destination utilise une topologie du rseau en backbone. Les informations de
localisation transitent sur ce rseau pour viter de consommer de la bande passante sur le rseau ad
hoc sous-jacent. Notre protocole de localisation est efficace puisquil ne transmet que trs peu
dinformations de localisation sur le rseau ad hoc. Les seuls paquets de localisation changs sont les
paquets provenant de la source ou de la destination dun flux ou des nuds de backbone qui leur sont
affilis. De mme, le protocole est peu sensible aux mouvements des nuds puisque les changements
du rseau backbone ne sont pas rpercuts sur le rseau ad hoc.
Lobtention de la destination avec un faible cot permet denvisager lutilisation de protocoles
rduisant lespace de recherche. Nous proposons un protocole qui rduit lespace de recherche utilisant
deux formes gomtriques (une forme triangulaire et une forme en cerf-volant). Lutilisation dun tel
protocole rduit grandement le nombre de paquets de routage ncessaires lobtention dune route.
Par contre, ce protocole possde linconvnient de ntre efficace que dans un environnement
particulirement dense en nuds. Dans les environnements o les nuds sont plus disperss, lchec
retourner une route est bien trop lev pour rendre notre protocole pleinement utile. Pour rsoudre un
tel problme, nous avons propos deux protocoles qui utilisent un parcours en profondeur. En cas
dchec lors de la dcouverte dune route, la zone de recherche est agrandie. Parmi ces deux
protocoles, le premier est optimal (il retourne une route sil en existe une) alors que le second
privilgie le nombre dinformations changes sur loptimalit. Bien entendu, pour que le second
protocole soit utilisable, il doit retourner quasiment chaque recherche une route. Les deux protocoles
savrent trs efficaces. Le protocole optimal ncessite un faible nombre de requtes pour dterminer
une route. Le protocole sous-optimal retourne trs souvent une route, mme si de rares fois ce nest
pas le cas. Il ncessite trs peu de paquets de routage pour dterminer une route. Il est, tout
particulirement, 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
loptimisation de bande
passante sous des
contraintes : dlai et bande
passante
Dans ce chapitre, nous nous intressons un problme que les protocoles de routage doivent rsoudre
pour supporter les applications temps-rel et multimdia. Ce problme, not DBCONT (Delay and
Bandwidth Constrained Optimal Network Throughput), consiste en la garantie du dlai et de la bande
passante tout en optimisant cette dernire. Ce problme est NP-complet. Nous proposons, donc, une
solution pour sapprocher au mieux de la solution optimale dun tel problme.
6.1 Garantie du dlai : un besoin
Le nombre dapplications ncessitant une garantie en termes de dlai ne cesse de crotre tous les jours.
Ces applications temps-rel touchent lensemble des domaines professionnels et personnels. Elles
peuvent tre employes aussi bien dans des environnements critiques, comme par exemple la gestion

150
de la chaleur dun racteur nuclaire, ou le contrle de la rpartition du freinage sur les diffrentes
roues dune voiture, que dans des environnements moins contraignants, comme pour la tlphonie sur
internet ou les jeux en ligne. Les applications temps-rel sont donc rpertories traditionnellement
dans deux catgories diffrentes :
Applications temps-rel critiques : le traitement dune opration aprs sa date limite
dexcution est considr comme une dfaillance pouvant entraner dans le pire des cas le
disfonctionnement du systme.
Applications temps-rel souples : ce type dapplications tolre un certain retard dans le temps
dexcution. Si tel est le cas, lapplication est susceptible de rduire la qualit quelle
ncessitait, la base, pour pallier ces retards.
Lenvironnement des rseaux ad hoc est difficilement adapt aux applications temps-rel critiques. En
effet, du fait de la mobilit des nuds, des ressources limites, des proprits du support de
transmission et du manque dun point central administrant les transmissions, garantir les contraintes
imposes par les applications temps-rel est une tche difficile dans un tel environnement. Le
protocole de routage, lors du transfert des paquets sur un chemin de plusieurs nuds, doit tenir compte
de ces paramtres pour garantir une certaine qualit de service aux applications temps-rel (cf. 3).
A cause de la difficult supporter la QoS dans un environnement aussi dynamique, lutilisation des
rseaux MANETs, pour le transfert de donnes provenant dapplications temps-rel strictes, ne peut
tre encore envisage. Du fait du dplacement des stations mobiles sur un rseau MANET, les routes
peuvent tre interrompues pendant un certain laps de temps. En fait, lors de la rupture dun lien,
lalgorithme de routage doit trouver une route garantissant les contraintes de dlai. Durant le temps de
rtablissement des routes, des paquets peuvent voir leur chance arriver terme, et par consquent ils
ne sont pas traits dans les temps par la destination. Il en est de mme avec le taux derreurs lev du
support. Le temps de retransmettre un paquet pour quil arrive indemne la destination, peut entrainer
le dpassement de lchance impose. Ces dpassements sont non tolrs pour des applications
temps-rel critiques.
Les rseaux MANETs sont mieux adapts aux applications temps-rel souples. Deux mthodes
peuvent tre employes pour assurer une QoS aux applications temps-rel souples, la QoS souple et la
QoS adaptative. Une QoS souple indique que durant une certaine priode de temps, la QoS spcifie
peut ne plus tre honore. Ainsi, des paquets peuvent arriver en retard sans bloquer le fonctionnement
de lapplication. La satisfaction des utilisateurs est quantifie 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, cest--dire que lapplication ne spcifie pas un seul contrat de QoS mais plusieurs.
Ainsi, lorsque le contrat initial ne peut plus tre respect, le rseau change de contrat et en choisit un
moins contraignant. Lutilisation de la QoS dynamique donne plus de flexibilit au systme et permet
au rseau dajuster la bande passante alloue une application en fonction des ressources qui sont
disponibles.

151
Dans ce chapitre, nous nous intressons nos travaux aux applications ncessitant la garantie de deux
contraintes, le dlai et la bande passante. Ces contraintes se retrouvent dans la plupart des applications
temps-rel comme la vidoconfrence, la tlphonie sur internet Les rseaux MANETs pouvant tre
employs pour des oprations diverses (secours, militaires,) (cf. 1), il est important de pouvoir
garantir le bon fonctionnement de telles applications. En effet, elles sont particulirement employes
dans de tels contextes.
Le protocole de routage est un lment dterminant dans lobtention de routes garantissant ces deux
contraintes. En effet lors de la phase de slection des routes, il doit carter les chemins ne garantissant
pas une de ces contraintes. De mme, slectionner le chemin (respectant les contraintes de bande
passante et de dlai) possdant le plus faible dlai de bout en bout nest pas toujours le choix le plus
judicieux. Quun paquet de donnes arrive avec un faible dlai ou un dlai un peu plus important est,
dans bien des cas, peu dommageable. Le principal est quun tel paquet respecte son chance. Tout en
respectant les contraintes imposes par une application, le protocole de routage doit privilgier la
slection dun chemin impactant peu la bande passante utile du rseau. Accrotre la bande passante
utile du rseau peut soit augmenter le nombre de flux traversant le rseau 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 dlai. La prsence de collisions et le
temps variable dacquisition du support retardent les paquets de donnes. De fait, une mthode daccs
au support avec contention est difficilement utilisable pour des applications temps-rel ou multimdia.
Les mthodes daccs au support sans contention sont bien mieux adaptes pour de telles applications
(cf. 3.5). Les travaux raliss dans ce chapitre utilisent la mthode TDMA (cf. 3.5.1) pour accder
au support sans contention. La mthode daccs au support TDMA divise le support en tranche (slots).
Le long dun chemin, des slots sont rservs pour garantir une bande passante exempte de collisions.
6.2 Facteurs impactant la bande passante lors de rservation
de slots
La bande passante est un facteur sensible dans les rseaux MANETs. En effet, elle est particulirement
faible. Il est donc ncessaire que le rseau loptimise au maximum pour permettre au plus grand
nombre de flux daccder au rseau (cf. 4.1). Pour viter les collisions, la rservation dun slot (avec
la mthode daccs TDMA) est possible si les conditions suivantes sont respectes : lmetteur ou le
rcepteur nmettent ou ne reoivent pas, aucun nud voisin de lmetteur ne reoit dans ce slot,
aucun nud voisin du rcepteur nmet dans ce slot.
Un tel mcanisme affecte les nuds voisins du nud metteur et du nud rcepteur. De fait, ces
nuds ne peuvent pas rutiliser pleinement (un nud voisin du nud metteur ne peut qumettre
alors quun nud voisin du nud rcepteur ne peut que recevoir des donnes) ces slots pour changer
des donnes. Par consquent, plus le nombre de nuds impacts est important, plus la bande passante
disponible du rseau est faible. Le protocole de routage est llment essentiel qui permet de contrler
cette bande passante consomme. En effet, il peut intervenir sur le chemin emprunt ainsi que sur les

152
slots rservs. Le protocole de routage doit intervenir sur le nombre de nuds influencs, par la
prsence dun nouveau flux, tout en retournant la fois un chemin qui garantit le dlai et la bande
passante demands par lapplication.
Le protocole de routage doit donc trouver un chemin qui garantit la fois les contraintes de dlai et de
bande passante tout en essayant doptimiser la bande passant utile du rseau. Le protocole de routage
est donc confront au problme DBCONT. Ce problme tant NP-complet, les protocoles essaient au
mieux de sapprocher de la solution optimale.
6.2.1.1 Impact de la rservation dun slot sur les nuds voisins
Un nud rserve un nombre diffrent de slots suivant sa position dans un chemin. En effet, un nud
rserve :
1 slot en mission si ce nud est la source
1 slot en rception et 1 slot en mission si cest un nud intermdiaire
1 slot en rception si ce nud est la destination
En effet, lors de la rservation des slots par un nud intermdiaire i, il doit rserver autant de slots en
rception (qui sont les mmes que les slots rservs en mission par le nud i-1) que de slots en
mission (qui sont les mmes que les slots rservs en rception par le nud i+1). Seuls les nuds
sources et destinations nont besoin de faire quune rservation. La source rserve seulement des slots
en mission alors que la destination rserve uniquement des slots en rception.

Figure 6-1 : Nombre de slots rservs suivant la position dun nud sur un chemin
La figure 6-1 montre le nombre de rservation suivant la position dun nud sur un chemin. Le nud
S cre un chemin avec le nud D. Un slot est rserv le long de ce chemin. Le nud S a besoin de
transmettre uniquement les paquets, donc il rserve un slot en mission. Le nud de destination D ne
fait que recevoir des paquets de donnes donc il rserve un slot en rception. Le nud intermdiaire I
reoit les donnes transmises par le nud S donc rserve ce slot en rception et relaie les donnes vers
la destination donc rserve un slot en mission.

153
Pour dterminer limpact dun nud sur ses voisins, nous calculons le nombre de nuds prsents dans
son voisinage. En fonction de sa place dans un chemin, nous dduisons ainsi le nombre de slots
influencs par le nud. Nous dfinissons les notions de slots influencs (not SI), slots influencs en
rception (not SIR) et slots influencs en mission (not SIE).
Le nombre de slots influencs par un nud i est fonction de sa place dans le chemin et du nombre de
slots requis par lapplication. La proprit 6-1 calcule le nombre de slots influencs SI par le nud X
avec N nuds dans son entourage et k slots rserver le long du chemin.
Proprit 6-1 : Pour k slots rserver, le nombre de slots influencs SI(X), par le nud X avec
un voisinage de N nuds, 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 nud intermdiaire
SI(X) = k(N-1) si x est la destination du chemin
A partir de la proprit 6.1, on peut dduire le nombre de slots influencs en rception par un nud
x par la fonction suivante :
SIR(X) = N-1 si X est la source ou un nud intermdiaire
SIR(X) = 0 si X est la destination
De mme, le nombre de slots influencs en mission par un nud X, SIE(X), se calcule de la mme
manire que prcdemment en intervertissant la source et la destination.
La dtermination de limpact dun nud sur son voisinage, nous permet de poser le problme de
routage li la rservation de slots travers les nuds dun chemin.
6.2.2 Problme de routage
Nombre de protocoles de routage actuels, garantissant le dlai, ne se soucie gure doptimiser la bande
passante. Pour trouver un chemin garantissant une certaine contrainte de dlai et une quantit de bande
passante, ils choisissent en rgle gnrale le chemin ayant le plus faible dlai pouvant rserver le
nombre de slots dsirs par lapplication. Un des paramtres optimiser pour accrotre la bande
passante disponible du rseau est le nombre de nuds influencs par un chemin. En effet, plus les
nuds dun tel chemin ont un nombre important de voisins, plus le nombre de slots influencs est
important.

154
Le slot i dun nud X est influenc par la rservation dun slot i (par le nud Y) de trois manires :
En rception : le slot i du nud X ne peut dornavant plus recevoir de donnes, il peut rutiliser ce
slot uniquement en mission.
En mission : le slot i du nud X nest plus capable dmettre des donnes. Ce slot est utilisable
par X uniquement en rception de donnes.
En mission et rception : cest le cas le plus critique. Le slot i du nud X ne peut tre rutilis.
Le chemin le plus court nest pas forcment le chemin impactant le moins les nuds voisins. Ce cas
est illustr sur la figure 6-2. Soit un rseau MANET de 8 nuds. Le nud S dsire obtenir un chemin
vers le nud D. Lapplication impose au rseau de rserver un slot de bout en bout. Pour cela, de
nombreux chemins garantissent la contrainte impose. Parmi ces chemins, le chemin <S, E, D> est le
chemin possdant le plus faible nombre de sauts (figure 6-2 a). Le nud E tant un lment central du
rseau, il va impacter un nombre important de nuds voisins. En effet, chaque slot rserv par lui
impacte 7 nuds (S, A, B, D, E, F, G). Le nud S rserve le slot 1 en mission. Le nud E rserve le
slot 1 en rception. La rservation sur le lien <S, E> impacte en tout 6 nuds. La rservation du slot 1,
en mission, par le nud S empche les nuds A et F de recevoir. La rservation du slot 1 en
rception, par le nud C, empche les nuds A, B, C, D, F, G dmettre des donnes. Ainsi, un tel lien
impacte fortement les nuds voisins puisque 2 slots sont influencs en mission et rception (slot 1 de
A et F) et 4 slots sont influencs en mission (slot 1 de B, C, D et G). Le chemin impacte, en tout, 12
slots (4 slots sont influencs en mission et rception, 4 slots sont influencs en mission et 4 slots
sont influencs en rception). La figure 6-2 b) montre, pour le mme rseau, linfluence des slots par
le chemin <S, F, G, D>. Le nud S rserve le slot 1 en mission. Il influe en rception sur les nuds A
et E. Le nud E rserve en rception le slot 1. Il influe en mission sur le slots 1 des nuds E et G. La
rservation dun slot sur le lien <S, E> influe en mission et rception le slot 1 du nud E, en mission
le slot 1 du nud G et en rception sur le slot 1 du nud A. De fait, un tel lien impacte faiblement ses
nuds voisins. Le chemin <S, F, G, D> influe en tout sur 8 slots (2 slots sont influencs en mission et
rception, 3 slots sont influencs en mission et 3 slots sont influencs en rception). Bien que le
chemin <S, E, F, D> soit plus long, il influence bien moins de slots que le chemin <S, C, D>. Par
consquent, la bande passante disponible du rseau est plus importante en passant par le chemin
<S, E, F, D>.
Maintenant que le problme est pos, il est ncessaire de dterminer limpact qua un chemin sur ses
nuds voisins (un nud est voisin dun chemin sil est voisin dun nud du chemin).
6.2.2.1 Impact dun chemin sur les nuds voisins
Chaque nud dun chemin influe sur son voisinage. De fait, les nuds dun chemin interagissent tous
avec leur voisinage. Le voisinage dun chemin est compos des voisins des nuds qui composent le
chemin.
Nous prsentons limpact dun chemin dans deux cas. Le premier est le cas gnral. Le deuxime cas
est un cas particulier o les nuds sont uniformment distribus dans lespace de recherche.

155

Figure 6-2 : Impact de chemins diffrents sur un rseau de 8 nuds. a) Impact du chemin le plus court.
b) Impact du chemin optimal.
S
D
A
B C
Chemin utilis
2 3 4 5 6 7 8 1
E
F
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 1
Slot rserv en mission
Slot rserv en rception
Slot influenc en
rception
Slot influenc en
mission
Slot influenc en
mission et rception
a)
S
D
A
B C
2 3 4 5 6 7 8 1
E
F
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 1
b)
2 3 4 5 6 7 8 1
2 3 4 5 6 7 8 1
G
G

156
6.2.2.1.1 Cas gnral
La rservation de slots sur un chemin empche les nuds voisins ce chemin dutiliser (du moins
partiellement) les slots rservs. 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 dterminer limpact dun flux, il est ncessaire de calculer le nombre de slots qui sont influencs
par ce flux. Nous calculons linfluence du chemin, not CI, en fonction de linfluence des nuds
(composant le chemin) sur leur voisinage. Soit un chemin P=<v
1
, , v
N
> dont chaque nud v
i
possde
N
i
voisins. Le nombre de slots rservs sur le chemin est de k slots. Linfluence du chemin est donn
par la formule suivante :
( ) ( ) ( ) 1 1 2 1 ) (
1
2
1
+ +

=
N
N
i
i
N k N k N k P CI (6-1)
Dmonstration :
Soit un chemin P=<v
1
, , v
N
> de N nuds qui a rserv k slots pour un flux donn.
Le nud source a besoin seulement dmettre les paquets de donnes donc il a besoin de rservs k
slots en mission et pour chaque slot rserv, il influe en rception sur chaque nud voisin (donc
k(N
1
-1) puisque le nud v
2
nest pas influenc puisquil reoit).
La destination, quant elle, reoit uniquement les paquets de donnes. Elle a donc besoin de rserver k
slots en rception. Elle influe en rception sur chaque nud voisin sauf le nud prcdent du chemin
puisquil utilise les mmes slots pour mettre les donnes (donc k(N
N
-1) slots influencs).
Les nuds intermdiaires permettent la propagation des paquets sur le chemin. Par consquent, ils
reoivent les paquets et doivent les retransmettre. Donc, ils doivent rserver k slots en rception et k
slots en mission. Chaque nud intermdiaire i influe sur 2k(N
i
-1) slots.
La valeur CI(P) est borne puisquun nud voisin du chemin peut tre voisin de plusieurs nuds du
chemin. Pour peu que le slot rserv soit identique, il nest influenc quune seule fois. Pour quun tel
cas se produise, il est ncessaire que le nud influenc soit voisin de deux nuds du chemin spar au
moins de deux sauts.
Par consquent : ( ) ( ) ( ) 1 1 2 1 ) (
1
2
1
+ +

=
N
N
i
i
N k N k N k P CI

A partir de lquation (6-1), on peut reprsenter limpact en mission dun chemin (not CIE) et
limpact en rception dun chemin (not CIR). Donc pour un chemin P=<v
1
, , v
N
> de N nuds qui a
rserv k slots pour un flux donn, CIE(P) et CIR(P) sont obtenus partir des quations suivantes :

157
( ) ( ) 1 1 ) (
1
2
+

=
N
N
i
i
N k N k P CIE
( ) ( )
=
+
1
2
1
1 1 ) (
N
i
i
N k N k P CIR
Considrons le rseau prsent sur la figure 6-3. Ce rseau est compos de 9 nuds. Deux slots sont
rservs le long du chemin <S, F, D>. Limpact du chemin CI(<S, F, D>) reprsente lensemble des
slots qui sont influencs (que ce soit en mission, en rception ou en mission et rception) sur le
chemin. CI(<S, F, D>) = 24 alors que la borne maximale est de 28 slots influencs. Cette diffrence
sexplique par les slots qui sont influencs en mission et rception (4 slots). Par contre,
CIE(<S, F, D>) = CIR(<S, F, D>) = 14 puisque dans ce cas lensemble des slots influencs en
mission (respectivement en rception) sont distincts.

Figure 6-3 : Impact dun chemin sur les nuds voisins avec la rservation de 2 slots par nud travers.
S
D
A
B
C
H G
F
E
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
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 rserv en mission
Slot rserv en rception
Slot influenc en
rception
Slot influenc en
mission
Slot influenc en
mission et rception

158
6.2.2.1.2 Nuds uniformment distribus
Lorsque les nuds sont uniformment rpartis dans le rseau, dterminer le chemin avec le plus faible
nombre de voisins revient trouver le chemin compos du plus faible nombre de nuds. En
considrant que les nuds possdent le mme rayon de couverture, le nombre moyen de nuds
prsents dans le voisinage est le mme pour tous les nuds du rseau.
Pour dterminer le nombre de slots influencs par un chemin P, il faut dterminer la probabilit quun
nud soit dans le voisinage dun autre. De fait, une fois cette probabilit calcule, il est possible de
reprsenter le nombre de nuds prsents dans le voisinage dun autre nud.
Pour dterminer la probabilit quun nud se trouve dans la zone de couverture dun autre nud, il est
ncessaire de connatre la porte du nud (son rayon de couverture) ainsi que la surface A
G
de la zone
o se situent les nuds. Cette probabilit est dtermine pour des nuds uniformment rpartis dans
A
G
. La probabilit quun nud x se situe dans la zone de couverture de rayon R dun autre nud i not
A
i
peut tre donne par la formule suivante :
( )
G
i
G
G i
i
A
A
A
A A
A x P =
= (6-2)
o A
i
A
G

En connaissant la probabilit quun nud soit dans la zone de couverture dun autre nud i, le nombre
moyen de nuds dans le voisinage de i est dtermin. Pour un rseau compos de N nuds, on dduit
de lquation (6-2) le nombre moyen de nuds N(i) dans A
i
. N(i) est calcul grce la formule
suivante :
N(i) = NP(xA
i
)
En considrant que le rayon de couverture est le mme pour tous les nuds du rseau, chaque nud a
la mme probabilit quun nud appartienne son voisinage. Ainsi, lensemble des nuds du rseau
ont le mme nombre moyen de voisins. Ce nombre est not NV.
Le nombre de slots influencs par un chemin P=<v
1
, , v
n
> peut tre maintenant dtermin. Chaque
nud du chemin va influencer les nuds voisins par les slots quil rserve. La source ninfluence
seulement en mission les nuds voisins, la destination seulement les nuds voisins en rception,
alors que les nuds intermdiaires influence les nuds voisins en mission et rception. A partir de
lquation (6-1), on dduit le nombre de slots influencs par le chemin P avec lquation suivante :
( ) ( ) 1 1 2 ) ( NV N k P CI (6-3)
On dduit de lquation (6-3) limpact en mission et en rception du chemin P :
( ) ( ) 1 1 ) ( NV N k P CIE

159
( ) ( ) 1 1 ) ( NV N k P CIR
Dans le cas de nuds uniformment rpartis dans le rseau, ces diffrentes formules montrent que
limpact dun chemin sur les nuds voisins est fonction de deux facteurs :
La porte : lorsque la porte crot, la probabilit moyenne davoir un nud dans son voisinage crot
galement. De fait, avec laugmentation de la porte dun nud, le nombre de nuds influencs est
plus important.
La longueur du chemin : la slection du chemin le plus court impacte, en moyenne, le moins de
nuds voisins. En effet, plus la longueur du chemin est grande, plus ce chemin impacte un nombre
important de nuds voisins.
Dans ce cas particulier, la rsolution du problme DBCONT revient slectionner le chemin avec le
plus faible nombre de nuds (tout en garantissant la contrainte du dlai et de la bande passante). Ainsi,
si notre protocole de routage est fonction du nombre de nuds voisins pour slectionner un chemin, il
retourne le chemin le plus court dans ce cas particulier. De fait, avec une telle rpartition des nuds
dans le rseau, le chemin le plus court et le chemin slectionn par notre protocole ont la mme
efficacit.
6.2.3 Bande passante surconsomme
Pour tre pleinement efficace, le protocole de routage doit retourner un chemin ayant le plus faible
impact sur les nuds voisins ceux du chemin. Les slots influencs sont une perte de bande passante
qui ne peut pas tre utilise par dautres flux. De fait, nous dfinissons la notion de slots sur-employs,
SSE, qui est le nombre de slots influencs par le chemin P. Le nombre de slots sur-employs par le
chemin P est donn par la formule suivante :
SSE(P) = CI(P) (6-4)
A partir du nombre de slots sur-employs par un chemin, il est possible de dterminer la bande
passante perdue. Nous dfinissons la bande passante surconsomme comme la bande passante utile
perdue par les slots influencs. La bande passante surconsomme est note B
S
. Plus cette bande
passante est faible, plus le protocole de routage est performant. Pour dterminer B
S
, on suppose que
lensemble des nuds du rseau ait la mme capacit C et que la dure dune trame TDMA, T, dure le
mme temps. La trame TDMA est divise en slots de mme dure T
S
.
Le calcul de B
S
, pour un chemin P, est donn par la formule suivante :
( ) ( ) C T P SSE
T
P B
s s
=
1
(6-5)

160
La valeur
T
1
donne le nombre de trames TDMA par unit de temps. SSE(P) reprsente le nombre de
slots surconsomms et T
S
la taille dun slot. La valeur ( )
S
T P SSE
T

1
reprsente la dure consomme
par lensemble des slots sur-utiliss. Par consquent, il suffit de multiplier ce temps la capacit des
nuds pour obtenir la bande passante surconsomme B
s
(P) pour le chemin P.
Pour tre pleinement efficace, notre protocole de routage doit slectionner un chemin avec la plus
faible bande passante surconsomme. De fait, les caractristiques de ce protocole et la fonction poids
employe sont les deux lments essentiels pour y parvenir.
6.3 Optimisation de la bande passante sous contraintes de
dlai et bande passante
Nous proposons un protocole de routage interagissant avec la couche MAC pour slectionner un
chemin. Notre protocole de routage interroge la couche MAC pour calculer les mtriques ncessaires
la dtermination dune route. Linteraction entre les couches rseau et MAC permet aussi de raliser la
rservation de bande passante ncessaire au bon fonctionnement de lapplication durant la phase de
dcouverte des routes. La phase de rservation peut tre dcouple de la phase de dcouverte des
routes c'est--dire que rien nempche quelle ait lieu une fois quune route est trouve. Dcoupler la
phase de rservation de la phase de dcouverte des routes accrot le dlai dattente avant de pouvoir
utiliser la route. De fait, nous faisons le choix de combiner ces deux oprations.
Notre protocole de routage garantit les contraintes de dlai et de bande passante. Il permet galement
de slectionner le chemin, respectant ces contraintes, avec le plus faible impact sur les nuds voisins.
La bande passante prserve est ainsi disponible pour dautres flux.
La mobilit des nuds peut perturber le respect des contraintes imposes par chaque flux. En effet, le
dlai ou la bande passante peuvent varier avec les changements de topologie et ne plus respecter leurs
contraintes. Lorsquune route ne respecte plus les contraintes imposes, le protocole de routage doit
slectionner une nouvelle route respectant les besoins des flux. De mme, le protocole de routage doit
continuellement prendre en compte les changements de topologie du rseau occasionnant la rupture
dune ou plusieurs routes.
6.3.1 Mtriques
Notre protocole utilise une fonction poids pour dterminer la qualit des chemins. Cette fonction
utilise trois sortes de mtriques : le dlai, le nombre de slots disponibles et le nombre de nuds voisins.
Ces trois mtriques sont calcules par notre protocole de routage. Notre protocole de routage utilise les
informations qui lui sont fournies par la couche MAC pour dterminer de telles mtriques. Ces
mtriques sont calcules comme suit :

161
Le dlai : le dlai de bout en bout est fonction des slots choisis par chaque nud du chemin. Pour
dterminer le dlai de bout en bout, la liste de slots choisis est conserve dans lentte des paquets de
routage.
Le nombre de slots disponibles : pour connatre le nombre de slots disponibles, la couche rseau
interroge la couche MAC. En effet, priodiquement les nuds changent entre eux des paquets de
contrle contenant la liste des slots quils utilisent en mission et en rception. Lchange de tels
paquets permet le respect des trois rgles ncessaires lvitement de collisions (cf. 3.5.1).
Le nombre de nuds voisins : le nombre de nuds voisins est galement obtenu en interrogeant la
couche MAC. Lors de la rception dun paquet priodique permettant la cohrence de la mthode
daccs TDMA, le nud conserve dans une table des voisins lidentifiant de lmetteur. Si pendant
une certaine dure, un nud ne reoit plus de paquet priodique dun autre nud cest quils ne sont
plus dans le mme voisinage. Le nombre de nuds voisins un nud v
i
est not N
1
(v
i
).
Notre protocole de routage na pas besoin dchanger dinformations pour calculer la valeur des
mtriques. Il utilise les changes ncessaires la couche MAC, pour conserver sa cohrence, dans le
but dobtenir les informations adquates pour dterminer la valeur des mtriques utilises.
6.3.2 Fonction poids
Pour rduire la complexit du problme DBCONT, le protocole de routage ne doit pas retourner le
chemin le plus court (respectant les contraintes de dlai 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 utiliss : les fonctions poids linaires et non-linaires.
Nous choisissons dutiliser une fonction poids non-linaire dans notre protocole de routage. Une telle
fonction permet de privilgier une mtrique sur les autres. Lavantage de privilgier une mtrique sur
les autres implique que la fonction poids retourne un chemin qui favorise cette mtrique.
Notre fonction poids doit privilgier la mtrique du nombre de nuds voisins du chemin par rapport
aux mtriques de bande passante et de dlai. Nous pouvons rduire notre fonction lutilisation de
deux mtriques, le nombre de nuds voisins du chemin et le dlai. 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 privilgier le nombre de nuds voisins par rapport au dlai du chemin, le protocole de routage
doit pnaliser de manire plus importante le nombre de nuds voisins dun chemin que son dlai.
Deux solutions peuvent tre envisages pour y parvenir :
Pnaliser de manire exponentielle le nombre de nuds voisins dun chemin et de manire
proportionnelle le dlai du chemin.

162
Pnaliser de manire proportionnelle le nombre de nuds voisins dun chemin et pnaliser de
manire logarithmique le dlai du chemin.
Nous faisons le chois dutiliser la deuxime mthode. Le dlai du chemin ne devant jamais excder le
dlai impos, la fonction poids doit retourner 0 lorsque le dlai est quasiment nul et tendre vers linfini
lorsque le dlai est strictement suprieur la contrainte du dlai. Par consquent, il ncessite de
trouver une fonction logarithmique respectant un tel critre. La fonction suivante correspond nos
attentes :
( )
+ >
+
|
|
|
|
|
|
|
\
|
= > =<
=
+
D
D
D
n
i
i i
n
P D
P D
v v D
v v P f
) ( avec
) ( avec
) , (
1
1
ln
,...,
1
1
1
1
(6-6)
En effet, cette fonction respecte parfaitement la contrainte de dlai impose. Lorsque D(P) >
D
alors
f(P). Pour D(P)=0 alors f(P)=0.
Maintenant reste trouver une fonction poids qui pnalise galement le nombre de nuds voisins dun
chemin. La fonction poids doit pnaliser plus fortement le nombre de nuds voisins que le dlai du
chemin. Un chemin qui ne respecte pas la contrainte de bande passante doit, galement, possder un
poids qui tend vers linfini. La fonction poids w(P) pour un chemin P=<v
1
, , v
n
> correspond ces
attentes :
w(P) = w(<v
1
,,v
n
>) =
( ) ( ) P f v N
n
i
i

=1
1

=
( )
< >

|
|
|
|
|
|
|
\
|

=
+
=
k j i NS j i P D
P D
v v D
v N
D
D
D
n
i
i i
n
i
i
) , ( , ) ( avec
) ( avec
) , (
1
1
ln
1
1
1
1
1
(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 lentte des paquets de routage
changs ainsi que dans les tables de routage maintenues par lensemble des nuds du rseau. Pour
propager les caractristiques du chemin emprunt, les contraintes de dlai et de bande passante,

163
lentte des paquets de routage est modifi. Notre protocole effectue une gestion par flux. De fait, il
conserve dans sa table de routage le prochain nud pour le couple (source, destination).
Notre protocole de routage met des paquets RREQ pour propager linformation de routage travers
le rseau. Les paquets RREQ possdent dans leur entte des paramtres dj prsents dans le protocole
AODV tels que : ladresse IP source, le numro de squence source et ladresse de destination.
Lentte de ces paquets est complt par les mtriques lies au chemin ainsi quaux contraintes
respecter. Les mtriques sont le dlai du chemin et le nombre de nuds voisins de ce chemin. Les
contraintes sont la borne du dlai et le nombre de slots rserver. Les slots susceptibles dtre rservs
sont conservs galement dans lentte du paquet. En effet, comme le dlai du chemin est directement
li au choix des slots, ils doivent tre conservs pour pouvoir calculer le dlai au plus juste. Pour
conserver une cohrence dans le dlai du chemin, ces slots sont rservs lors de la confirmation dune
route. Pour cela, les slots slectionns sur un lien (i, j), nots S(i,j), sont mmoriss dans le champ
Liste des Slots, not LS, de la requte RREQ.
Le paquet de confirmation de routes RREP comporte dans son entte, ladresse de la destination,
ladresse de la source, le numro de squence de la destination, le poids du chemin et la liste des slots
LS.
Chaque nud du rseau maintient deux tables : la table inverse des chemins et la table de routage. La
table inverse des chemins comporte les champs suivants : adresse source, numro de squence source,
adresse de destination, numro de squence de destination, poids du chemin. Dans la table de routage,
sont maintenus les champs suivants : ladresse source, le numro de squence source, ladresse de
destination, le numro de squence de destination, le poids du chemin et le prochain nud.
Le fonctionnement de notre protocole de routage est diffrent suivant la position du nud dans le
chemin (nud source, nud intermdiaire et nud destination).
6.3.4 Algorithme
Le fonctionnement du nud source est prsent sur lorganigramme de la figure 6-4. Le nud source
cre un paquet RREQ et initialise ses champs. Le champ dlai est initialis 0, le champ nombre de
nuds voisins est gal au nombre de nuds prsent dans le voisinage du nud source et la liste des
slots est mise NULL. Les bornes de dlai et de bande passante sont aussi initialises. Le nud source
met la requte RREQ puis se met en attente aprs avoir arm le temporisateur Trep. Si Trep arrive
chance, la source na reu aucune confirmation de route. Elle ritre sa demande de cration de
route jusqu atteindre le seuil Nrp
max
. Lorsque ce seuil est atteint, le nud source prvient la couche
suprieure quil na pas pu trouver une route. Sil reoit un paquet RREP avant lexpiration de Trep, il
vrifie si les slots contenus dans LS sont libres. Dans le cas o ils le sont, il les rserve et une route est
trouve. Aprs avoir arrt Trep, il peut commencer transmettre ses donnes.

164

Figure 6-4 : Organigramme utilis par le nud source
Le fonctionnement dun nud intermdiaire j est donn par lorganigramme de la figure 6-5. Lorsque
le nud j reoit un paquet RREQ dun nud i, il vrifie dans un premier temps si le nombre de slots
disponibles sur le lien (i, j), not SD(i, j), est suprieur la borne de bande passante requise
B
. Si
SD(i, j) est suprieur ou gal la borne, il rserve le nombre de slots requis dans le vecteur S(i, j).
Aprs avoir dtermin le dlai du chemin entre la source et lui, il vrifie que ce dlai ne dpasse pas la
borne du dlai
D
. Si cette borne est respecte, il calcule le poids du chemin et met jour sa table des
chemins inverses si besoin.
A la rception dun paquet RREP mis par un nud i, le nud j vrifie en premier lieu quil peut
rserver les slots contenus dans LS sur le lien (j, i) et sur le lien (nud_prcdent, j). Si ces slots sont
disponibles, il les rserve aprs avoir mis jour sa table de routage. Il transmet le paquet RREP au
nud nud_pcdent aprs avoir retir de LS les slots rserver sur le lien (j, i).
DEBUT
- Crer un RREQ
- Gnrer un nouveau
numro de squence
- Initialiser LS
de la requte
- Diffuser RREQ
- Armer le temporisateur
Trep
RREP reu
dun nud i ?
- Arrter Trep
- Rserver les
slots LS(source, i)
- Envoyer les
donnes
oui
non
Trep expir?
non
oui
Nrp++
Nrp Nrp
max
?
oui
non
Informer la couche suprieure
Phase de
traitement des
donnes
Transmission des
donnes
RERR reu ?
une route ?
oui non
oui non
Les slots
LS(source, i)
sont-ils libres ?
Supprimer
la requte
non
oui
- Librer les
slots

165

Figure 6-5 : Organigramme utilis par un nud intermdiaire j
Le fonctionnement du nud destination est donn par lorganigramme de la figure 6-6. A la rception
dun paquet RREQ, le nud destination calcule le nombre de slots disponibles et le dlai du chemin.
Sil peut slectionner un nombre de slots correspondant la bande passante requise et le dlai du
chemin respecte la contrainte du dlai, il arme un temporisateur Ta si ce nest pas dj fait. Le
temporisateur Ta permet au nud destination dattendre un certain temps avant dmettre 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 requtes RREQ venant de chemins
diffrents. Si la destination transmet un paquet RREP la rception de la premire requte garantissant
les contraintes imposes, le chemin de plus faible poids peut ne pas tre slectionn. De mme, de
multiples requtes RREP ne doivent tre mises car sur le chemin de confirmation, les slots contenus
dans la requte RREP sont rservs. Transmettre plusieurs requtes RREP engendre de multiples
rservations, rduisant dautant la bande passante du rseau. Lorsque le temporisateur Ta arrive
expiration, il rserve les slots en commun avec le nud prcdent et met une rponse avec la liste des
slots rserver sur le chemin. Tout paquet RREQ qui arrive aprs expiration du temporisateur Ta est
supprim.

166

Figure 6-6 : Organigramme utilis par le nud destination
6.3.5 Analyse de performances
Pour vrifier le comportement de notre protocole de routage, nous analysons ses performances par
simulation. Le simulateur employ est le simulateur NS-2. Les simulations sont effectues en
comparant lefficacit de notre protocole avec le protocole de routage de plus faible dlai (not LD).
Le protocole de routage LD retourne le chemin de plus faible dlai qui respecte la contrainte de bande

167
passante. Si ce protocole ne trouve pas de route, alors aucune route ne respecte les contraintes
imposes.
Nous simulons ces protocoles sur diffrentes topologies o le nombre de nuds prsents sur le rseau
varie. Les nuds possdent tous un dbit de transmission de 11 Mbps. La mthode daccs au support
est TDMA. Les nuds changent toutes les secondes leur table de slots rservs en mission et
rception. Chaque nud connat ainsi ses voisins et les slots quils ont rservs. Lensemble des
nuds sont synchroniss durant nos simulations. Ainsi le dbut de chaque fentre TDMA a lieu au
mme instant. La taille dun slot est de 700 octets. Il y a 5 fentres TDMA par seconde. Chaque nud
du rseau possde un slot de contrle. Le nombre de slots de donnes diminue avec laugmentation du
nombre de nuds dans le rseau. Le nombre de slots par fentre TDMA est de 350 slots. La dure des
simulations est de 500 secondes. La simulation utilise un modle de communication dans lequel la
moiti des nuds communiquent avec lautre moiti. Chaque connexion ncessite la rservation dun
slot de bout en bout du chemin. Chaque flux possde un dbit de 20Kbps.
Dans un premier temps, nous dterminons la bande passante surconsomme moyenne par le protocole
LD compar notre protocole. Pour cela, nous utilisons lquation (6-4) pour dterminer le nombre de
slots impacts par le protocole LD et notre protocole. Lquation (6-5) permet de dduire, partir de la
valeur SSE(P
LD
) (respectivement SSE(P
Notre Protocole
)), la bande passante surconsomme par le protocole
LD (respectivement par notre protocole). La figure 6-7 montre son volution en fonction du nombre de
nuds sur le rseau. La bande passante surconsomme par les deux protocoles crot avec
laugmentation du nombre de nuds sur le rseau. Lorsque le nombre de nuds prsents est de 150, la
diffrence de bande passante surconsomme par le protocole LD est de 800 Kbps. A partir de 150
nuds, limpact stagne. Lorsque 200 nuds sont prsents, bien que le nombre de nuds subissant un
impact est plus important, il lest autant pour le protocole LD que pour notre protocole.

Figure 6-7 : Bande passante surconsomme par le protocole LD compar notre protocole
Lvolution du nombre de paquets RREQ ncessaires lobtention dune route est reprsente sur la
figure 6-8. Le nombre de connexions augmente avec le nombre de nuds prsents sur le rseau. De
fait, la bande passante ncessaire lobtention des routes crot avec le nombre de nuds. Notre
protocole ncessite 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
mme si le chemin possde le plus faible dlai, son impact sur les nuds voisins nest pas forcment
le moins important. La diffrence de bande passante commence se ressentir partir de 150 nuds.
Tout de mme, elle reste relativement faible.

Figure 6-8 : Bande passante ncessaire lobtention des routes
Un autre critre de comparaison est la bande passante utilise par les paquets de donnes (figure 6-9).
Quelque soit le nombre de nuds prsents sur le rseau, cette bande passante est identique pour les
deux protocoles. Ceci met en vidence que les chemins dtermins par les deux protocoles de routage
ont, souvent, le mme nombre de sauts.

Figure 6-9 : Bande passante utilise par les paquets de donnes
Le dernier critre de comparaison est le nombre de slots libres en rception et en mission
(figure 6-10). Notre protocole retourne un nombre de slots libres plus important (que celui retourn par
le protocole LD) dans lensemble des scnarios raliss. Il est dautant plus performant lorsque le
nombre de nuds est important (par consquent lorsque la charge du rseau est importante). De fait,
partir de 150 nuds, notre protocole propose environ 1000 slots libres supplmentaires que le
0
20
40
60
80
100
120
140
160
30 50 75 100 150 200
B
a
n
d
e

p
a
s
s
a
n
t
e

c
o
n
s
o
m
m
e

p
a
r

l
e
s

p
a
q
u
e
t
s

R
R
E
Q

(
K
b
/
s
)
0
500
1000
1500
2000
2500
30 50 75 100 150 200

169
protocole LD. Ces slots libres peuvent tre rutiliss pour faire passer des flux supplmentaires, ou
pour accrotre la bande passante des flux dj en place sur le rseau.

Figure 6-10 : Nombre de slots rests libres en fin de simulation en fonction du nombre de nuds.
6.4 Discussion
Les applications multimdia et temps-rel ncessitent que le rseau respecte certaines contraintes pour
fournir une communication de qualit. Les contraintes de telles applications sont nombreuses : bande
passante, dlai, fiabilit Dans cette section, nous nous sommes focaliss sur la garantie de la bande
passante et du dlai.
Le support des applications multimdia et temps-rel est plus complexe dans les rseaux mobiles du
fait de la mobilit des nuds et du partage du support de transmission. Les mthodes daccs au
support conventionnelles, CSMA/CA par exemple, ne peuvent apportes la garantie ncessaire au
respect des contraintes de QoS. Nos travaux utilisent la mthode sans contention TDMA. Cette
mthode daccs divise le support de communication en intervalles de temps. En respectant un certain
nombre de rgles, les nuds du rseau peuvent transmettre sans crer de collisions. En effet, un nud
ne peut transmettre (respectivement recevoir), dans un intervalle de temps quil nutilise pas,
seulement si aucun nud voisin ne reoit (respectivement nmet) durant cet intervalle de temps.
Ainsi, la transmission ou la rception dun paquet par un nud influe sur le comportement des nuds
voisins.
10
15
20
25
30
35
30 50 75 100 150 200
N
o
m
b
r
e

d
e

s
l
o
t
s

l
i
b
r
e
s

(
m
i
l
l
i
e
r
s
)

170
Les protocoles de routage, garantissant la bande passante et le dlai, noptimisent pas la bande
passante des rseaux MANETs. Nous avons trait le problme DBCONT (Delay and Bandwidth
Constrained Optimal Network Throughput). Ce problme est NP-complet.
Le protocole de routage est llment essentiel dans loptimisation de la bande passante du rseau. Les
nuds du chemin slectionns doivent influer le moins possible sur les autres nuds du rseau. Notre
protocole de routage utilise une fonction poids garantissant les contraintes de bande passante et de
dlai. Cette fonction pnalise fortement les chemins en fonction du nombre de nuds prsents dans le
voisinage.
La ralisation de simulations a mis en vidence lefficacit de notre protocole. Nous avons compar
notre protocole au protocole de plus faible dlai (LD). Cette comparaison montre que les nuds du
chemin slectionn par notre protocole influent moins sur leurs voisins que ceux du protocole LD. De
fait, les intervalles de temps laisss libres par notre protocole peuvent tre affects dautres flux.

171
7 Conclusion et perspectives
Ces dernires annes, le besoin en mobilit des usagers nest plus dmontrer. Les rseaux MANETs
permettent aux usagers de communiquer tout en se dplaant librement. Ces rseaux doivent pouvoir
supporter les mmes applications que les rseaux filaires et cela de faon transparente. Les
applications multimdia et temps-rel sont fortement consommatrices en bande passante. Les
contributions de nos travaux se sont focalises sur laugmentation de la bande passante utile des
rseaux MANETs. Pour rpondre cette problmatique, nous avons dcid doprer au niveau rseau,
o le protocole de routage est llment essentiel dans la slection des chemins. Pour parvenir notre
objectif, nous avons mis en vidence les facteurs de la couche rseau ayant un impact sur la bande
passante du rseau. Nous tenons aussi compte des collisions. De fait, nos travaux sorientent selon
trois axes : la diminution des collisions, une dissmination efficace de linformation de routage et le
support dapplications contraintes par la bande passante et le dlai. Relever ce dfi suppose
lapprhension de nombreuses notions : la notion de rseaux sans fil et principalement celle des
rseaux MANETs, la notion de Qualit de Service et des applications contraintes et les diffrents
protocoles de routage quils soient Meilleur Effort ou QoS. Nous organisons cette conclusion en trois
parties. Dans un premier temps, nous prsentons nos contributions dans le cadre des protocoles de
routage augmentant la bande passante utile dun rseau MANET. Dans un second temps, nous tirons
les enseignements de nos travaux. Dans un dernier temps, nous critiquons ces rsultats et prsentons
les orientations futures de ce travail.
7.1 Contributions
Dans notre premire contribution, nous nous sommes attachs au problme des collisions. Du fait des
retransmissions, les collisions rduisent la bande passante utile dun rseau. Elles accroissent, aussi, le
dlai de bout en bout des paquets de donnes. Nous avons isol diffrents facteurs jouant un rle sur
loccurrence de collision : le nombre de nuds voisins, le dlai de transmission dun paquet, la charge

172
dun lien et le dlai de propagation. Nous avons propos deux fonctions poids pour rduire le nombre
de collisions. La premire fonction poids combine trois mtriques pour slectionner un chemin (la
bande passante ayant subi des collisions, le nombre de sauts dun chemin et la capacit dun lien).
Bien que lefficacit de cette fonction poids ne rponde pas pleinement nos attentes, les rsultats
obtenus furent riches denseignements. La bande passante sature est une notion souvent utilise dans
les rseaux filaires pour vrifier lefficacit dun protocole de routage. Elle nest pas reprsentative de
leur efficacit dans les rseaux sans fil. Notre fonction poids augmente la bande passante sature du
rseau. Dans un scnario pratique, le nombre de requtes changs par notre protocole de routage met
mal lefficacit relle de cette fonction poids. De plus, la bande passante ayant subi des collisions
ragit trop lentement laugmentation de la charge du lien. Lorsque cette mesure augmente le lien a
dj atteint sa limite de transmission.
A partir de tels constats, nous avons propos une seconde fonction poids. Cette fonction poids
combine trois mtriques pour dterminer un chemin (la bande passante disponible, la capacit dun
lien et le nombre de nuds voisins). Pour mesurer les mtriques, cette fonction poids ncessite une
gestion locale de lenvironnement par le protocole de routage. Nous avons propos un protocole de
routage auquel est combine la deuxime fonction poids. Lefficacit de notre protocole de routage est
value par simulation. Notre protocole est compar aux protocoles AODV et AODV avec une gestion
locale de lenvironnement (not AODV Hello). Les simulations montrent que les protocoles de
routage avec une gestion locale de lenvironnement sont moins sensibles aux collisions. Les collisions
peuvent entraner la dtection de la perte dun lien alors quil est toujours actif. En rduisant les
collisions, notre protocole est moins sensible ce phnomne que les protocoles AODV et AODV
Hello. De fait, la bande passante utilise pour la cration et la maintenance des routes est plus faible
avec notre protocole quavec les autres. Dans les meilleures circonstances et compar aux autres
protocoles, notre protocole de routage augmente la bande passante utile du rseau de 50% compar
aux protocoles AODV et AODV Hello. Lefficacit de notre protocole de routage diminue avec
laccroissement de la mobilit des nuds. Les protocoles utilisant une gestion locale de
lenvironnement mettent plus de temps pour dtecter la perte dun lien. De fait avec laccroissement de
la mobilit, la bande passante utile de notre protocole et du protocole AODV Hello diminue plus vite
quavec le protocole AODV.
Notre deuxime contribution sattache diminuer le nombre dinformations de routage ncessaires
la dtermination dune route. Les informations de routage sont diriges seulement en direction de la
destination. Pour diriger ces informations vers la destination, le protocole de routage doit connatre la
position de la destination. Nous proposons un protocole de localisation qui dtermine avec un faible
cot sur le rseau MANET la position dun nud. Un rseau backbone est utilis pour mener cette
tche bien. Les informations de position transitent principalement sur le rseau backbone rduisant
le cot de tels changes sur le rseau 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 nuds prsents sur le rseau, la surcharge de notre protocole sur le rseau MANET est bien plus
faible que celle du serveur fixe. Le dlai dobtention de la position dun nud est de mme plus faible.
Pour rduire 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 dtermine

173
une route sil en existe une. Ce protocole accrot la zone de recherche lorsquune tentative pour
dterminer une route choue. Lors de chaque tentative, lensemble des nuds retransmettent les
informations de routage. Le deuxime protocole est non optimal. Lors dune nouvelle tentative, seuls
les nuds nayant pas particip la tentative prcdente peuvent relayer les informations de routage.
Ces deux protocoles sont compars aux protocoles AODV et AODV avec une recherche de parcours
en largeur. En moyenne, nos deux protocoles utilisent prs de 6 fois moins dinformations de routage
que le protocole AODV pour dterminer une route. Le deuxime protocole ncessite moins
dinformations 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 particulirement efficaces lorsque la densit du rseau est leve.
Notre dernire contribution sapplique augmenter la bande passante utile dans un rseau tout en
garantissant des contraintes de dlai et bande passante. La garantie de telles contraintes ncessite la
rservation de ressources. Nous utilisons la mthode daccs au support TDMA pour garantir la bande
passante requise par les applications. Lorsquun flux rserve un ensemble de slots, une telle
rservation influe sur les voisins des nuds du chemin. La slection dun chemin dont les nuds
influent fortement sur leurs voisins rduit dautant la bande passante utile du rseau. Nous proposons
un protocole de routage dont les nuds dun chemin influent le moins possible sur les nuds prsents
sur le rseau. Notre protocole pnalise plus fortement le nombre de voisins des nuds dun chemin par
rapport au dlai respecter. Nous comparons lefficacit de notre protocole avec le protocole
slectionnant le chemin de plus faible dlai (not LD). Notre protocole a un impact moins important
que le protocole LD sur le nombre de voisins du chemin slectionn. 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 Exprience
Notre exprience dans la conception de nos approches nous a apport nombre de leons. En premier
lieu, la comparaison de nombreux protocoles de routage est une tche difficile effectuer du fait des
solutions souvent trs diffrentes apportes pour rsoudre les problmes de routage. Les protocoles de
routage doivent se focaliser sur un problme particulier pour tre rellement efficaces. Ensuite, pour
rsoudre efficacement un problme donn, les facteurs sur lesquels doivent intervenir le protocole de
routage ne sont pas forcment vidents isoler. Il est ncessaire de raliser une approche minutieuse,
pour former une fonction poids combinant ces diffrents facteurs. Enfin, la ralisation de simulations
permet de confronter les protocoles de routage proposs avec les protocoles existants. Cette phase est
importante car un protocole de routage peut avoir un fonctionnement imprvu dans un scnario rel.
7.3 Critiques et orientations futures
Si les contributions apportes dans le cadre de nos travaux ont rsolu certains problmes, quelques
points restent tudier. Ces points sont autant dorientations futures dans la continuit de nos travaux.

174
Nous distinguons trois types dorientations futures selon le temps estim pour leur ralisation. Des
exemples dorientations court terme sont :
Une premire orientation est de proposer une solution gnrale pour notre protocole garantissant le
dlai. Du fait, quil ncessite une couche MAC divis en slot, il nest gure dpendant du protocole
daccs au support sous-jacent. Il serait intressant de proposer une solution cross-layer pour profiter
pleinement des avantages de notre protocole de routage.
Un point intressant serait aussi dtendre notre protocole optimal ralisant une recherche de
parcours en profondeur (cf. 5) pour quil passe encore plus efficacement lchelle. Lors dune
nouvelle tentative de dcouverte de route, seuls les nuds en bordure de zone de recherche sont utiles
la transmission des informations de routage. Le nombre dinformations de routage changes par
notre protocole peut tre rduit.
Une autre orientation serait lamlioration du protocole de routage garantissant le dlai et la bande
passante (cf. 6) pour quil retourne le chemin de plus faible dlai au cas o aucune route nest trouve
avec notre fonction poids.
Nous donnons aussi trois autres orientations moyen terme donner nos travaux :
Le premier point prvoie de combiner les approches de rduction du nombre de collision et de
gestion de lespace de recherche pour fournir une solution complte. Cette solution devrait permettre
de tirer profit des avantages de ces deux solutions et den combler les inconvnients.
Notre protocole de routage rduisant le nombre de collisions perd en efficacit avec
laccroissement de la mobilit des nuds. Il serait intressant que notre protocole de routage
slectionne plusieurs routes lors dune recherche pour le rendre plus ractif lors de la coupure dun
lien.
Nos protocoles de routage augmentant la bande passante disponible doivent avoir un impact positif
sur la consommation nergtique des nuds. En effet, note protocole de routage rduisant les
collisions (cf. 4) diminue le nombre de retransmissions. De fait, les nuds consomment moins
dnergie pour transmettre correctement un paquet. Nos protocoles rduisant les informations de
routage (cf. 5) ncessitent moins dinformations de routage pour obtenir une route. De fait, la phase
de dcouverte des routes a un impact rduit sur la consommation nergtique des nuds.
Enfin, dans une optique plus long terme, un point trs intressant aborder est de simuler nos
diffrentes approches dans des environnements plus alatoires que le simple modle de mobilit RWP.
Ainsi, des modles de mobilit de groupes peuvent tre utiliss pour simuler les protocoles des
chapitres 4 et 6. Ces protocoles pnalisent le nombre de nuds voisins dun chemin. Ces protocoles
doivent tre plus efficaces pour de tels modles de mobilit. De mme, il peut tre envisag une
exprimentation sur des quipements rels permettant lvalutation de nos protocoles dans des
conditions relles.

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. 582590, 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.
4655, 1999
[BET 02-1] C. Bettstetter, H. Hartenstein, and X. Prez-Costa, Stochastic Properties of the
Random Waypoint Mobility Model: Epoch Length, Direction Distribution, and Cell
Change Rate, ACM MSWiM02, 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 LANs, In Proceedings of the conference on
Communciations architectures, protocols and applications (ACM Sigcomm94), 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, Thse lInstitut National des Sciences Appliques de Lyon, Autour
de la rservation de bande passante dans les rseaux 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. 197211.
[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) 6181.
[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 SIGCOMM89. 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 241254, 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 (ICN06),
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, Cdric 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, fvrier 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, TELSIKS99, 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. 5070, 2007.
[HAS 99-1] Z.J. Hass, R. Pearlman, Zone routing protocol for ad-hoc networks, Internet
Draft, draft-ietf-manet-zrp-02.txt, work in progress, 1999.
[HO 02-1] Y.-K. Ho , R.-S. Liu, A Novel Routing Protocol for Supporting QoS for Ad Hoc
Mobile Wireless Networks, Wireless Personal Communications: An International
Journal, v.22 n.3, p.359-385, September 2002.
[HON 99-1] X. Hong, M. Gerla, G. Pei, and C. Chiang, A group mobility model for ad hoc
wireless networks, In proceedings of the ACM International workshop on
Modeling and Simulation of Wireless and Mobile Systems (MSWiM), August 1999

179
[HWA 03-1] Y. Hwang, P. Varshney, An adaptive Q o S routing protocol with dispersity for
ad-hoc networks. In Proc. the 36th Annual Hawaii International Conference on
System Sciences, January 2003, pp.302-311.
[IEEE 03-1] IEEE Standard for Information Technology Telecommunications and Information
Exchange between Systems. Local and Metropolitan Area Network Specific
Requirements Part 11 : Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications Further Higher-Speed Physical Layer
Extension in the 2.4 GHz Band, 2003.
[IEEE 85-1] IEEE Computer Society Std 802.3-1985. Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) Access Method and Physical Layer
Specifications, The Institue of Electrical and Electronics Engineers, 1985.
Physical Layer (PHY) Specifications, 1997.
Physical Layer (PHY) Specifications Higher-speed physical layer extension in
the 2.4 GHz band, 1999.
Physical Layer (PHY) Specifications High-speed physical layer in the 5 GHz
band, 1999.
[IET 02-1] The Zone Routing Protocol (ZRP) for Ad Hoc Networks. Z. Haas, M. Pearlman, P.
Samar. IETF Internet Draft. Jul 2002.
[IET 81-1] Internet Protocol. RFC 791, Internet Engineering Task Force. Sept 1981
[IET 93-1] G. Malkin. RIP Version 2-Carrying Additional Information. RFC 1388. Internet
Engineering Task Force. January 1993
[ISS 03-1] T. Issariyakul, E. Hossain et D. Kim. Medium access control protocols for
wireless mobile ad hoc networks: issues and approaches. WCMC, vol. 3, Dec
2003
[JAI 01-1] R. Jain, A. Puri, and R. Sengupta. Geographical routing using partial information
for wireless ad hoc networks. IEEE Personal Communications, 8(1):48--57,
February 2001.
[JAW 04-1] I. Jawhar and J. Wu, Quality of Service Routing in Mobile Ad Hoc Networks,
Resource Management in Wireless Networking, 2004.

180
[JAW 04-2] I. Jawhar and J. Wu. A race-free bandwidth reservation protocol for QoS routing
in mobile ad hoc networks. Proc. of the 37
th
Annual Hawaii International
Conference on System Sciences (HICSS04), 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. 14151425, 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. 158162.
[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 VTC02, 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 ICNP97, 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. 3039.
[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. Dlai et Routage dans les rseaux 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 MWCN02 : 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. 8695.
[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-WASUN04, 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. Aot 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. 83124.
[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, 16
th
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
(DIALM), 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 Spring03,
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. 480486.
[TUR 01-1] D. Turgut, S. K. Das, and M. Chatterjee, Longevity of Routes in Mobile Ad hoc
Networks, Proceedings of IEEE VTC-spring01, 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:12281234, 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 Complments
A.1.1 Protocole de routage AODV
A la rception dun paquet de routage, le fonctionnement dun nud, excutant le protocole AODV,
est diffrent suivant sa position dans le chemin. De fait, les organigrammes des nuds sont donns
pour le protocole AODV avec mission dune rponse RREP seulement par le nud de destination.

190
A.1.1.1 Organigramme du nud source

Figure A-1 : Organigramme du nud source
DEBUT
- Cre un RREQ
- Gnrer un nouvel
identifiant de diffusion
- Gnre un nouveau
numro de squence
- Met jour les champs
de la requte
- Diffuse RREQ
- Arme le temporisateur
Trep
RREP reu?
- Arrte Trep
- Envoie les
donnes
oui
non
Trep expir?
non
oui
Nrp++
Nrp Nrp
max
?
oui
non
Informe la couche suprieure
Direction la
phase de
traitement des
donnes
Data transmission
RERR received?
yes no

191
A.1.1.2 Organigramme dun nud intermdiaire

Figure A-2 : Organigramme dun nud intermdiaire

DEBUT
RREQ reu dun nud i?
oui
non
Dj reu un RREQ pour la
paire (source, id_diffusion) ?
oui
non
- Crer une
nouvelle entre
dans la table des
chemins inverses
Supprimer
la requte
de la table des chemins
inverses correspondant
au nud source
RREP reu?
non
oui
une entre dans la table de
routage pour le nud
destination?
oui non
nsd plus rcent
ou identique mais
meilleur poids ?
- Crer une nouvelle
entre dans la table
de routage
oui non
- Transmettre le RREP au nud
prcdent contenu dans la table
des chemins inverses pour le
nud source
Supprimer
la requte
une entre dans la table des
chemins inverses pour le
nud source?
oui non
nss plus rcent
ou identique mais
meilleur poids ?
de la requte
oui non
Supprimer
la requte

192
A.1.1.3 Organigramme du nud destination

Figure A-3 : Organigramme dun nud 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 ractifs pour loptimisation
de bande passante et la grantie de dlai
dans les rseaux ad hoc mobiles

Par David ESPS

Directeur de thse : Zoubir MAMMERI
Soutenue lUniversit Toulouse III Paul Sabatier le 27 novembre 2008

Nos travaux se situent dans le contexte des rseaux MANETs (Mobile Ad Hoc NETorks) qui constituent une
catgorie de rseaux sans fil pouvant tre dploys rapidement, multi-sauts et sans infrastructure. Les rseaux
MANETs permettent la communication entre utilisateurs dapplications mobiles diverses (applications
collaboratives, urgences, militaires, embarques).
Cependant, ces rseaux souffrent dinconvnients la fois lis aux caractristiques du medium de transmission
(partage du canal de transmission, faible dbit), mais galement aux protocoles de routage (dissmination de
linformation, slection dun chemin). Ces limites rendent difficile le support des applications multimdia et
temps rel (telles que la vidoconfrence, la vido la demande, la VoIP). Ces applications requirent le
respect de contraintes de Qualit de Service (QoS) telles que la bande passante et le dlai.
Le but de nos travaux est doptimiser la bande passante disponible dun rseau MANET pour permettre
lutilisation dapplications fortement consommatrices en bande passante. Comme un rseau MANET est multi-
saut, linfluence des protocoles de routage sur les performances du rseau est dterminante. Trois axes ont t
tudis pour augmenter la bande passante utile des rseaux MANETs : rduction des collisions, rduction des
informations de routage et garantie de la bande passante et du dlai.

Mots-cls : Rseaux ad hoc, routage, routage QoS, applications temps-rel, bande passante, dlai

Spcialit : Informatique

Institut de Recherche en Informatique de Toulouse UMR 5505
Universit Paul Sabatier ,
118 route de Narbonne
31062 Toulouse
CEDEX 9

Espes David

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Espes David

Încărcat de

Drepturi de autor:

Formate disponibile

T

IXJ form entre le nud I lui ayant transmis la requte,

> > + <

> > + <

> > + <

(donne par la proprit 5-3) et Y

(donne par la proprit 5-4).

S-ar putea să vă placă și