DSR

N d'ordre: 2381
THESE
prsente
pour obtenir
LE TITRE DE DOCTEUR DE L'INSTITUT NATIONAL POLYTECHNIQUE DE TOULOUSE
cole doctorale: Ecole Doctorale d'Informatique et Tlcommunications

Spcialit: RTSA
Par
Titre de la thse
Farid
CSR
JADDI
une extension hirarchique adaptative
du protocole de routage ad hoc DSR
Soutenue le
2511 0/06
devant le jury compos de :
M.
DIAZ Michel
Prsident
Mme.
PAILLASSA Batrice
Directeur de thse
Mme.
MINET Pascale
Rapporteur
Mme.
KANCHANASUT Kanchana
Rapporteur
M.
FRABOUL Christian
Membre
CSR: une extension hirarchique adaptative du

protocole de routage ad hoc DSR
Farid JADDI
Thse dirige par Batrice PAILLASSA
Remerciements
Je tiens remercier tout dabord Kanchana Kanchanasut et Pascale Minet
pour avoir accept dexaminer mon manuscrit. Je vous suis notamment reconnaissant pour lintrt que vous avez manifest lgard de mon travail. Dautre
part, les remarques de Pascale Minet mont particulirement aid prendre du
recul sur mon travail et amliorer la qualit et la clart du mmoire et de la
soutenance. Je tiens aussi remercier Michel Diaz pour avoir assur la charge
de prsident du jury. Je suis conscient de son emploi du temps trs charg et
lattention quil a porte mon manuscrit et ma soutenance me touche dautant
plus. Un grand merci Christian Fraboul pour la considration quil a porte
ma thse ds le dbut, pour sa prsence la soutenance et pour sa relecture du
manuscrit. Pour en terminer avec les membres du jury, last but not the least,
je remercie trs chaleureusement Batrice Paillassa tant pour ses qualits humaines et professionnelles que jai pu apprcies tout au long de ma thse. Je te
sais gr davoir accepter ma manire de fonctionner et de mavoir fait voir du
pays ! Je te suis trs reconnaissant pour tout ce que tu mas appris et pour ton
encadrement hors pair.
Passons maintenant au labo dont les membres ont largement contribu
faire de ma thse un moment mmorable (pour moi !). Aprs trois ans lN7, je
suis pass de lautre ct du miroir telle Alice et les enseignants se sont mtamorphoss en collgues. Un grand merci Julien dont jai pu apprcier la fulgurante
ascension, Manu le beau blond qui finira srement patron de karaok, Riadh
pour ses judicieux conseils en NS et Jrome pour sa bonne humeur. Je remercie
aussi Andr-Luquioh pour son euro parler, pour sa verve, pour son historique
du regrett Shangha et pour sa capacit (jallais presque dire son don ...)
transformer toute anecdote ou parole anodines en vnement ! Le labo ne serait
pas ce quil est sans Sylvie la fois pierre angulaire et piment de ce notable
tablissement : efficace, attentionne, pimpante et marrante ! Jessaierai de te
dbaucher ds que je gagnerai plus dun keuro ...
Le labo ne serait pas aussi vivant sans le sang neuf qui lirrigue, sans son
armada de thsards. Je remercie ple-mle Alex et Rahim (lalliance du feu et
de la glace), Hussein et son sang-froid, Nico le spcialiste du Latex, Cholatip et
son abngation, pour tous les bons moments passs ensemble. Merci lquipe
du petit london toujours prte tout tourner en drision : JP et son dsormais
mythique esprit critique, Vincent M. avec lequel la fusion est plus quimminente, Vincent H. le poussin qui est devenu top gun, Florent lhomme animal
i
ii
tour tour glouton, puma et chauda-dog, Wil le papounet et le leader de la
black-basse cour. Je noublie pas Garmy la princesse peul, toujours en manque
de dessert, qui prend la vie du ct bon ainsi que Mathieu mon petit canard (qui
a des hongrois dans sa baignoire) et dont limmense gnrosit et intelligence me
laissent souvent pantois mais toujours avec le sourire. Avec Sakunatchan, mon
acolyte de bureau, lchange culturel France-Thalande a t plus que positif et
enrichissant, surtout ne perd jamais ton indboulonnable sourire !
La thse ne se serait pas si bien passe sans lappui de ma famille et je remercie pour raisons diplomatiques mes parents et mes frres Youssef aka Chucky
et Samir alias frite lhuile dolive. Un petit coucou aux amis : Sue Hlne la
danseuse invtre, Mel B spcialiste en th et chocolat chaud, Eldridge qui reprsente la gwadada, Franky aka Lock Ho le roi du jeu de mots, Laurent loncle
Bives des amriques dont le dpart a traumatis Toulouse et le chti ncureuil
volant qui ma fait planer pour un vol malheureusement trop court.
Un grand merci vous tous !
Table des matires

Introduction
1 Introduction au routage dans les rseaux Ad hoc

1.1 Notions de rseaux ad hoc . . . . . . . . . . . . . .
1.1.1 Historique . . . . . . . . . . . . . . . . . . .
1.1.2 Technologies radio . . . . . . . . . . . . . .
1.1.2.1 802.11 . . . . . . . . . . . . . . . .
1.1.2.2 Bluetooth . . . . . . . . . . . . . .
1.1.2.3 HiperLAN . . . . . . . . . . . . .
1.1.2.4 Dploiement . . . . . . . . . . . .
1.1.3 Caractristiques et contraintes . . . . . . .
1.2 Principe du routage . . . . . . . . . . . . . . . . .
1.2.1 Problmatique du routage . . . . . . . . . .
1.2.2 Classification des protocoles de routage . .
1.2.3 Exemples de protocoles de 1re gnration .
1.2.3.1 DSDV . . . . . . . . . . . . . . .
1.2.3.2 TORA . . . . . . . . . . . . . . .
1.2.3.3 AODV . . . . . . . . . . . . . . .
1.3 DSR . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Procdures DSR . . . . . . . . . . . . . . .
1.3.1.1 Dcouverte de routes . . . . . . .
1.3.1.2 Maintenance de routes . . . . . . .
1.3.2 Optimisations . . . . . . . . . . . . . . . . .
1.3.2.1 Dcouverte de routes . . . . . . .
1.3.2.2 Maintenance de routes . . . . . . .
1.3.2.3 Option Flow State . . . . . . . . .
1.3.2.4 Gestion du cache . . . . . . . . . .
1.4 Axes de recherche sur le routage ad hoc . . . . . .
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
6
7
7
8
8
9
9
11
11
11
13
13
13
14
16
16
16
16
17
17
18
18
18
20
21
2 Evaluation de performances
22
2.1 Notions de performances du routage . . . . . . . . . . . . . . . . 23
2.1.1 Mesures externes de lefficacit . . . . . . . . . . . . . . . 23
2.1.2 Mesures internes de lefficacit . . . . . . . . . . . . . . . 23
iii
TABLE DES MATIRES
2.2
2.3
2.4
2.5
iv
2.1.3 Paramtres dvaluation . . . . . . . . . . . . . . . . .

2.1.4 Environnements de simulation . . . . . . . . . . . . .
Modles de mobilit . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Modle Random Waypoint . . . . . . . . . . . . . . .
2.2.2 Modle RPGM . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Influence du modle de simulation . . . . . . . . . . .
2.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . .
Rsultats dvaluation des protocoles de routage . . . . . . .
2.3.1 Etude de lquipe Monarch . . . . . . . . . . . . . . .
2.3.2 Etude de lquipe Ericsson . . . . . . . . . . . . . . .
2.3.3 Problmes de performances de DSR et AODV . . . . .
Problmatique du passage lchelle . . . . . . . . . . . . . .
2.4.1 Limitations de la diffusion . . . . . . . . . . . . . . . .
2.4.2 Etudes du passage lchelle . . . . . . . . . . . . . .
2.4.2.1 Dfinitions du groupe ANS . . . . . . . . . .
2.4.2.2 Travaux analytiques sur le passage lchelle
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Mthodes dadaptation dans les rseaux ad

3.1 Notions dadaptation . . . . . . . . . . . . .
3.2 Adaptation la mobilit . . . . . . . . . .
3.2.1 Mtriques de mobilit . . . . . . . .
3.2.2 Choix dune mtrique de mobilit . .
3.3 Routage adapt la taille du rseau . . . .
3.3.1 C-DSR . . . . . . . . . . . . . . . . .
3.3.2 Protocoles de routage hybrides . . .
3.3.2.1 ZRP . . . . . . . . . . . . .
3.3.2.2 IZR . . . . . . . . . . . . .
3.3.3 Routage bas sur la position . . . .
3.3.3.1 Service de localisation . . .
3.3.3.2 Routage des donnes . . .
3.3.4 Protocoles proactifs . . . . . . . . .
3.3.4.1 TBRPF . . . . . . . . . . .
3.3.4.2 OLSR . . . . . . . . . . . .
3.3.5 Connected Dominating Sets . . . .
3.4 Mthodes de clustering . . . . . . . . . . .
3.4.1 Critre dlection des Cluster Head .
3.4.1.1 Identifiant . . . . . . . . .
3.4.1.2 Connectivit . . . . . . . .
3.4.1.3 Mobilit . . . . . . . . . . .
3.4.1.4 Poids . . . . . . . . . . . .
3.4.1.5 Combinaison de critres . .
3.4.2 Taille des clusters . . . . . . . . . . .
3.4.3 Contrle du nombre de Cluster Head
3.4.4 Routage . . . . . . . . . . . . . . . .
3.5 Mthode dadaptation du routage . . . . .
hoc
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
26
27
28
29
30
31
31
32
33
37
37
38
38
40
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
44
45
45
48
49
49
51
51
52
53
54
55
56
56
57
58
61
62
62
63
65
66
66
67
68
69
71
TABLE DES MATIRES

3.5.1
3.5.2
3.6
Approche propose . . . . . . . . . .
Mtriques dadaptation . . . . . . .
3.5.2.1 Mobilit . . . . . . . . . . .
3.5.2.2 Densit . . . . . . . . . . .
3.5.2.3 Principes de notre mthode
Conclusion . . . . . . . . . . . . . . . . . .
v
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
dadaptation
. . . . . . . .
4 Hirarchisation adaptative du protocole DSR

4.1 Notre approche . . . . . . . . . . . . . . . . . . .
4.1.1 Clusterisation du routage source : CSR .
4.1.2 Architecture de clusters . . . . . . . . . .
4.2 Procdures CSR . . . . . . . . . . . . . . . . . .
4.2.1 Routage CSR . . . . . . . . . . . . . . . .
4.2.1.1 Dcouverte de routes . . . . . .
4.2.1.2 Maintenance de routes . . . . . .
4.2.2 Procdures de clustering . . . . . . . . . .
4.2.2.1 Mise en place du niveau 0-Cell .
4.2.2.2 Maintenance du niveau 0-Cell .
4.2.2.3 Mise en place du niveau 1-Server
4.2.2.4 Maintenance du niveau 1-Server
4.3 Adaptation du mode de routage . . . . . . . . .
4.3.1 Changements de mode . . . . . . . . . . .
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
. 79
. 79
. 82
. 84
. 84
. 84
. 89
. 89
. 90
. 91
. 92
. 97
. 99
. 99
. 101
5 Evaluation de loptimisation CSR

5.1 Validation des principes CSR . . . . . . . . . . . . . . . . . . . .
5.1.1 Optimisation du routage . . . . . . . . . . . . . . . . . . .
5.1.1.1 Modle de simulation . . . . . . . . . . . . . . .
5.1.1.2 Rsultats . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Procdures de clustering . . . . . . . . . . . . . . . . . . .
5.1.2.1 Modle de simulation . . . . . . . . . . . . . . .
5.1.2.2 Rsultats . . . . . . . . . . . . . . . . . . . . . .
5.2 Comparaison de performances de lextension CSR avec les protocoles de 1re gnration . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Modle de simulation . . . . . . . . . . . . . . . . . . . .
5.2.2 Intrt du changement adaptatif du mode de routage . . .
5.2.3 Influence de la densit et de la mobilit . . . . . . . . . .
5.2.4 Influence de la charge de trafic . . . . . . . . . . . . . . .
5.2.5 Dure de la dcouverte de route . . . . . . . . . . . . . . .
5.3 Comparaison de performances de lextension CSR avec un protocole de 2me gnration . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Modle de simulation . . . . . . . . . . . . . . . . . . . .
5.3.2 Influence de la densit . . . . . . . . . . . . . . . . . . . .
5.3.3 Influence de la mobilit . . . . . . . . . . . . . . . . . . .
5.4 Etude de la stabilit du changement de mode adaptatif . . . . . .
5.4.1 Temps pass dans chacun des modes . . . . . . . . . . . .
71
72
72
73
74
77
102
103
103
103
104
105
105
106
109
109
109
111
113
114
116
116
116
118
122
122
TABLE DES MATIRES
5.5
vi
5.4.2 Dure de la transition . . . . . . . . . . . . . . . . . . . . 126

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Conclusions et perspectives
129
Bibliographie
132
Table des figures

1.1
1.2
Exemple de rseaux ad hoc . . . . . . . . . . . . . . . . . . . . .

Dcouverte de routes AODV et DSR . . . . . . . . . . . . . . . .
6
15
2.1
2.2
2.3
2.4
Dplacement dun nud selon le modle Random Waypoint . . .

Principe du modle RPGM . . . . . . . . . . . . . . . . . . . . .
ees
Rapport T rafDonn
ic de contr
ole pour 10 connexions . . . . . . . . . . .
Donn
ees
Rapport T raf ic de controle pour 10 connexions pour diffrentes densits de nuds . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ees
Rapport T rafDonn
ic de contr
ole pour 20 connexions pour une densit de
100 nuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
29
33
3.1
3.2
3.3
Exemple de formation de clusters . . . . . . . . . . . . . . . . . .

Compatibilit entre les modes de routage . . . . . . . . . . . . .
Modes de routage . . . . . . . . . . . . . . . . . . . . . . . . . .
61
74
75
4.1
4.2
4.3
Modle CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dcouverte de Routes CSR . . . . . . . . . . . . . . . . . . . . .
Procdure denregistrement global . . . . . . . . . . . . . . . . .
82
85
92
2.5
5.1
5.2
5.3
5.4
5.5
36
37
Rapports des efficacits sur 2 topologies pour diffrentes densits 105

Trafic de contrle par nud pour les procdures de niveau 0-Cell 107
Trafic de contrle par nud pour la procdure dlection du Serveur108
ees
Rapport T rafDonn
ic de contr
ole pour 10 connexions . . . . . . . . . . . 110
Donn
ees
Rapport T raf ic de controle pour 10 connexions pour diffrentes densits de nuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
ees
5.6 Rapport T rafDonn
ic de contr
ole pour 20 connexions pour une densit de
100 nuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.7 Dure de la dcouverte de route selon la procdure utilise . . . . 115
5.8 Dure moyenne des dcouvertes de route DSR et CSR . . . . . . 115
ees
ic de contr
ole pour 10 connexions . . . . . . . . . . . 117
Donn
ees recues
5.10 Rapport Donnees emises pour 10 connexions . . . . . . . . . . . . 118
ees
ic de contr
ole pour 10 connexions pour diffrentes densits de nuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
vii
TABLE DES FIGURES

Donn
ees recues
5.12 Rapport Donn
ees emises pour 10 connexions pour diffrentes densits de nuds . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13 Pourcentage de temps dans chaque mode de routage pour 10 connexions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.14 Pourcentage de nuds en mode CSR pour 10 connexions et pour
diffrentes densits de nuds . . . . . . . . . . . . . . . . . . . .
5.15 Dure de la transition DSR -> CSR selon le statut . . . . . . . .
viii
121
123
125
126
Liste des tableaux

1.1
Caractristiques des principaux protocoles de routage ad hoc . .
12
3.1
Caractristiques des services de localisation tudis . . . . . . . .
55
4.1
4.2
4.3
4.4
4.5
En-tte fixe DSR . . . . . . . . . .

Format doption DSR . . . . . . .
Options CSR . . . . . . . . . . . .
Table Mobile - Cluster Head . . . .
Table Cluster Head - Cluster Head
79
80
81
83
83
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Acronymes
AA : Avec Architecture
ARC : Adaptive Routing using Clusters
ARCH : Adaptive Routing using Clustered Hierarchies
ANS : Ad hoc Network Scaling
AODV : Ad hoc On-demand Distance Vector
BRP : Bordercast Resolution Protocol
BPSK : Binary Phase Shift Keying
CBR : Constant Bit Rate
CBRP : Cluster Based Routing Protocol
CDS : Connected Dominating Set
C-DSR : Cellular DSR
CH : Cluster Head
CHCH : Cluster Head - Cluster Head table
CSMA/CA : Carrier Sense Multiple Access / Collision Avoidance
CSMA/CD : Carrier Sense Multiple Access / Collision Detection
CSR : Cluster Source Routing
CTS : Clear To Send
DCA : Distributed Clustering Algorithm
DCF : Distributed Coordination Function
DMAC : Distributed Mobility-Adaptive Clustering
DREAM : Distance Routing Effect Algorithm for Mobility
DSDV : Destination-Sequenced Distance-Vector
DSR : Dynamic Source Routing
DYMO : Dynamic MANET On-demand
DARPA : Defense Advanced Research Projects Agency
ETSI : European Telecommunications Standards Institute
GLS : Grid Location Service
x
LISTE DES TABLEAUX

GPS : Global Positioning System
HCC : Highest-Connectivity degree Clustering
IARP : Intra-Zone Routing Protocol
IBM : International Business Machines
IEEE : Institute of Electrical and Electronics Engineers
IERP : Inter-Zone Routing Protocol
IETF : Internet Engineering Task Force
IP : Internet Protocol
IRTF : Internet Research Task Force
IZR : Independent Zone Routing
LCA : Lowest-ID Cluster Algorithm
LCC : Least Cluster Change
LQSR : Link Quality Source Routing
MAC : Medium Access Control
MANET : Mobile Adhoc NETworks
MCH : Mobile - Cluster Head table
MIMO : Multiple Input Multiple Output
MONARCH : MObile Network ARCHitectures
MPR : MultiPoint Relay
NIB : Neighborhood Information Base
NS : Network Simulator
OSPF : Open Short Path First
OLSR : Optimized Link State Routing Protocol
PCF : Point Coordination Function
PDR : Packet Delivery Ratio
PRNET : Packet Radio NETworks
QAM : Quadrature Amplitude Modulation
QNAP : Queueing Network Analysis Package
RFC : Request For Comments
RIP : Routing Information Protocol
RLS : Reactive Location Service
RN : Reported Node set
RPGM : Reference Point Group Model
RTS : Request To Send
SA : Sans Architecture
SMF : Simplified Multicast Forwarding
xi
LISTE DES TABLEAUX

SURAN : SUrvivable RAdio Networks
TBPRF : Topology Dissemination Based on Reverse-Path Forwarding
TC : Topology Control
TCP : Transmission Control Protocol
TIB : Topology Information Base
TORA : Temporally Ordered Routing Algorithm
TTL : Time To Live
VCS : Virtual Carrier Sense
VPR : Virtual Paths Routing
WCA : Weighted Clustering Algorithm
WLAN : Wireless Local Area Network
WMAN : Wireless Metropolitan Area Network
WPAN : Wireless Personal Area Network
ZRP : Zone Routing Protocol
xii
Introduction
Motivation
Un rseau ad hoc est constitu dun ensemble dunits mobiles communiquant via un mdium radio et ne requiert ni infrastructure fixe ni administration centralise. Il se forme de manire spontane et provisoire ds que plusieurs
nuds mobiles se trouvent porte radio les uns des autres. Lorsque le rseau
est tendu, certains nuds peuvent se comporter comme des routeurs afin de
permettre la communication entre des units mobiles hors de porte immdiate.
Les rseaux ad hoc prsentent des caractristiques diffrentes des rseaux
filaires. Tout dabord, le medium de communication offre une bande passante
limite par rapport aux rseaux filaires. Les units mobiles disposent de ressources matrielles limites et htrognes en terme de batterie et de puissance
de calcul. Enfin, la mobilit des nuds gnre une topologie dynamique.
Les protocoles de routage doivent donc sajuster aux contraintes particulires des rseaux ad hoc. En premier lieu, un protocole de routage doit tre
efficace en bande passante utilise. Dautre part, les ressources matrielles limites des quipements mobiles excluent les algorithmes exigeants en capacit de
mmoire et de traitement. Enfin, un protocole de routage ad hoc doit sadapter
rapidement aux changements de topologie.
Nous pouvons dfinir deux gnrations de protocoles. La premire gnration propose des mcanismes simples pour lobtention et la maintenance des
informations de routage. La deuxime gnration vise ladaptation et loptimisation du routage par rapport des conditions particulires comme le passage
lchelle ou lconomie dnergie.
Parmi les protocoles de premire gnration, DSR (Dynamic Source Routing)
est lun des plus tudis. Comme son nom lindique, le DSR est un protocole de
routage par la source. Lmetteur des donnes doit fournir la route (la liste des
nuds traverser) ncessaire pour atteindre la destination. La route source est
prsente dans len-tte de chaque paquet de donnes. DSR est un protocole de
routage ractif : une route nest calcule que si cest ncessaire la communication entre deux nuds. La dcouverte des routes DSR est base sur linondation
du rseau. La station source diffuse un paquet de requte qui va atteindre tous
les nuds du rseau. La destination recherche rpond alors la source pour
lui fournir la route.
1
INTRODUCTION
Daprs les diffrentes valuations de performance que nous avons tudies,

DSR est un des protocoles de premire gnration les plus performants en termes
de dlai, dacheminement des donnes et de minimisation du trafic de contrle.
Ces mmes tudes montrent aussi les difficults de passage lchelle du protocole DSR lorsque le nombre de nuds et la charge du rseau augmentent.
Les difficults de passage lchelle du DSR viennent principalement de
lusage de linondation pour dcouvrir les routes. Linondation consomme de la
bande passante car tous les nuds doivent rediffuser les paquets reus. De plus,
la diffusion de paquets pose des problmes de collision et de redondance.
Les algorithmes de clustering font partie des solutions proposes pour permettre le passage lchelle des protocoles de routage ad hoc par rapport la
taille du rseau. Cette famille de solutions est particulirement intressante car
elle repose sur une architecture virtuelle : elle est par consquent souple et facile
mettre en uvre. Les algorithmes de clustering sappuient sur le partitionnement des nuds du rseau en groupes (clusters). Un leader (appel Cluster
Head) est choisi dans chaque groupe et sert identifier les clusters.
Les protocoles bass sur linondation comme le DSR sont bien adapts aux
petits rseaux tandis que les solutions hirarchiques, comme les algorithmes
de clustering, savrent plus efficaces sur des rseaux de taille plus grande. La
taille dun rseau ad hoc varie au gr des fusions et des partitionnements de
rseaux. Cest pourquoi il nous a paru intressant de combiner les avantages
des deux approches (inondation et routage hirarchique) afin daugmenter les
performances du routage. Par ailleurs, pour de nombreuses applications comme
les applications militaires, des phases de faible mobilit et de forte mobilit sont
observables. Dans ces conditions, un protocole hirarchique sera utilis lors des
priodes de faible mobilit alors quun protocole bas sur linondation sera plus
indiqu durant les priodes de forte mobilit.
Ces observations ont motiv lapproche que nous proposons dans cette thse :
elle consiste adapter le mode de routage (plat ou hirarchique) selon les conditions du rseau en termes de mobilit et de densit de nuds.
Contributions
Dans cette thse, nous proposons dadapter le mode de routage selon les
changements des conditions du rseau. Nous prsentons une mthode gnrale
dadaptation du mode de routage et nous la mettons en uvre en nous basant
sur le protocole DSR. Lextension CSR (Cluster Source Routing) que nous avons
dveloppe permet le passage lchelle du protocole DSR par rapport la taille
du rseau et la mobilit des nuds et ce de manire adaptative. Lobjectif de
notre proposition est de transfrer la dcouverte de routes un niveau suprieur
de larchitecture de clusters : le chef de groupe de niveau suprieur agit comme
un cache de routes central et la dcouverte de routes seffectue par des communications directes entre Cluster Heads. Chaque nud a la capacit de changer
de mode de routage (DSRCSR) selon ses critres dadaptation (mobilit et
densit).
INTRODUCTION
Les procdures CSR sont totalement transparentes et assurent la compatibilit entre les nuds DSR et les nuds CSR. Nous conservons le format de
paquet DSR et les procdures de clustering sont mises en place grce au mcanisme doption du DSR. Des codes doptions appropris sont choisis pour
permettre le traitement des paquets CSR par les nuds DSR lorsque cela est
ncessaire.
Pour permettre le changement de mode de routage, nous dfinissons une
mtrique de mobilit et une mtrique de densit. Ces mtriques sont calcules
priodiquement et individuellement par chaque nud.
Nous avons spcifi les procdures de routage et de clustering de notre extension. Ces procdures ont ensuite t implantes sous lenvironnement de simulation ns2 pour permettre lvaluation de performances de lextension CSR.
Nous avons compar les performances du CSR avec celles des protocoles prconiss par lIETF. Tout dabord, nous montrons la faisabilit et lintrt du
changement adaptatif du mode de routage. Nous tudions ensuite le passage
lchelle par rapport la taille du rseau et la charge de trafic. Nous tudions
finalement la stabilit du changement de mode de routage.
Organisation de la thse
La thse est organise en cinq chapitres.
Dans le premier chapitre, nous prcisons le concept de rseau ad hoc. Nous
prsentons les principes du routage dans les rseaux ad hoc et dtaillons le protocole DSR.
Dans le chapitre 2, nous introduisons les notions dvaluation de performances du routage ad hoc : les diffrents paramtres et mtriques dvaluation
sont prsents. Par la suite, nous dtaillons deux modles de mobilit et analysons des rsultats dvaluation portant sur les protocoles dcrits dans le chapitre
prcdent. Nous concluons sur la problmatique du passage lchelle du routage dans les rseaux ad hoc.
Dans le chapitre 3, nous prcisons les notions dadaptation dans les rseaux
ad hoc. Nous prsentons tout dabord diffrentes mtriques pour adapter le routage par rapport la mobilit et proposons une mtrique de mobilit. Nous
exposons ensuite diffrentes solutions qui permettent le passage lchelle du
routage par rapport la taille du rseau. Parmi ces solutions, les algorithmes
de clustering sont plus particulirement dtaills. Nous prsentons alors notre
mthode gnrale dadaptation du mode de routage en fonction des conditions
du rseau.
Dans le chapitre 4, nous appliquons notre mthode sur un exemple en nous
basant sur le protocole DSR. Nous proposons notre extension hirarchique nomme CSR. Les procdures de routage et de clustering de notre proposition sont
INTRODUCTION
ensuite dtailles. Nous terminons cette partie en expliquant les mcanismes

dauto-adaptation du mode de routage proposs par le CSR.
Dans le chapitre 5, nous valuons les performances de notre proposition.
Nous validons le principe doptimisation du routage ainsi que les procdures de
clustering. Notre proposition est ensuite compare aux protocoles prconiss par
lIETF. Lintrt et la stabilit du changement adaptatif du mode de routage
sont analyss.
Pour terminer, nous exposons nos conclusions et perspectives notre travail
tant au niveau du routage quau niveau de ladaptation.
Chapitre 1
Introduction au routage dans

les rseaux Ad hoc
Sommaire
1.1
Notions de rseaux ad hoc . . . . . . . . . .

1.1.1 Historique . . . . . . . . . . . . . . . . . . .
1.1.2 Technologies radio . . . . . . . . . . . . . .
1.1.3 Caractristiques et contraintes . . . . . . .
1.2 Principe du routage . . . . . . . . . . . . .
1.2.1 Problmatique du routage . . . . . . . . . .
1.2.2 Classification des protocoles de routage . .
1.2.3 Exemples de protocoles de 1re gnration .
1.3
DSR . . . . . . . . . .
1.3.1 Procdures DSR .
1.3.2 Optimisations . . .
1.4 Axes de recherche sur
1.5 Conclusion . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
le routage ad hoc .
. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
7
9
11
. 11
. 11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 13
.
16
. . 16
. . 17
.
20
.
21
.
.
.
Dans ce premier chapitre, nous prcisons les notions de base des rseaux ad
hoc. Nous prsentons les principales caractristiques des rseaux ad hoc ainsi
que les contraintes qui en dcoulent. Nous nous intressons plus prcisment
la problmatique du routage. Les principes du routage dans les rseaux ad
hoc sont exposs. Nous prsentons ensuite les principaux protocoles plats de
premire gnration. Nous dtaillons plus prcisment le protocole DSR car
il constitue la base des exprimentations que nous mnerons dans les derniers
chapitres.
CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC6
Fig. 1.1 Exemple de rseaux ad hoc
1.1
1.1.1
Notions de rseaux ad hoc

Historique
Le concept de rseau maill sans fil (wireless mesh network ) consiste crer
un rseau dcentralis o chaque nud est connect plusieurs autres nuds
assurant ainsi une plus grande fiabilit. Les architectures de rseaux maills sans
fil peuvent tre regroupes en trois catgories [AW05] :
Rseaux maills infrastructure : le cur de rseau (backbone) est constitu de routeurs, nuds ddis, communiquant entre eux via un medium
radio. Les clients qui sont porte radio dun routeur peuvent accder au
rseau.
Rseaux maills clients : cest un rseau pair pair form par les clients.
Cela signifie que les nuds clients participent la configuration et au
routage dans le rseau. Dans ce type de rseau, il ny a pas de nuds
ddis au routage.
Rseaux maills hybrides : cest une combinaison des deux architectures
prcdentes : un client peut accder au rseau grce un routeur ou en
se connectant via les autres clients. Cette architecture mixte amliore la
connectivit et la couverture du rseau.
Les rseaux maills clients sont un cas particulier de rseaux maills sans fil
aussi appels rseaux ad hoc.
Un rseau ad hoc est constitu dun ensemble dunits mobiles communiquant via un mdium radio et qui ne requiert ni infrastructure fixe ni administration centralise [HGJ+ 99].

Historiquement, le concept de rseaux ad hoc a t introduit par la DARPA
(Defense Advanced Research Projects Agency) sous le nom de PRNET (Packet
Radio NETworks) en 1972 [KGBK78, JT87]. La DARPA continua travailler sur
cette problmatique au cours des annes 80 pour rpondre aux besoins militaires
en matire de rseaux mobiles sans fil (projet SURAN)[Bey90].
Un rseau ad hoc se forme de manire spontane et provisoire ds que plusieurs nuds mobiles se trouvent porte radio les uns des autres. Lorsque le
rseau est tendu, certains nuds peuvent se comporter comme des routeurs
afin de permettre la communication entre des units mobiles hors de porte
immdiate (voir Figure 1.1).
La facilit de dploiement des rseaux ad hoc savre particulirement utile
lorsque la mise en place dune infrastructure fixe serait trop coteuse, trop
longue voire impossible :
au cours doprations militaires, leur dploiement ex nihilo permet leur
utilisation sur un champ de bataille.
les rseaux de secours (emergency networks) facilitent la mise en place
rapide de moyens dassistance lors de catastrophes naturelles (sismes,
inondations, incendies, . . .)
le partage dinformations entre partenaires au cours dun meeting, dune
confrence ou dans un hall daroport peut seffectuer aisment.
lemploi de rseaux ad hoc permet dtendre la couverture dun rseau
sans fil utilisant des points daccs (rseaux maills sans fil hybrides).
le dploiement de rseaux de capteurs (sensor networks) permet dobserver
et de surveiller lenvironnement [ASSC02].
1.1.2
Technologies radio
La mise en uvre dun rseau ad hoc peut sappuyer sur diffrentes technologies de transmission radio : 802.11, Bluetooth et HiperLAN. Les standards 802.11 et Hiperlan dcrivent les caractristiques dun rseau local sans
fil (WLAN) et Bluetooth qualifie un type de rseau personnel sans fil (WPAN).
1.1.2.1
802.11
Le standard 802.11 a t normalis par lIEEE en 1997. Il dfinit deux modes

de fonctionnement :
le mode infrastructure ou PCF (Point Coordination Function) dans lequel
un point daccs fixe est ncessaire la communication entre deux mobiles.
Le point daccs sert de relais entre les nuds.
le mode ad hoc ou DCF (Distributed Coordination Function) dans lequel
les nuds peuvent communiquer sans point daccs ds lors quils sont
porte radio les uns des autres.
Dans un rseau radio en mode ad hoc, lmetteur ne peut dtecter au cours de sa
transmission lventuel brouillage de ses donnes par une mission concurrente.
Lutilisation dune mthode daccs de type CSMA/CD (Carrier Sense Multiple
Access / Collision Detection), comme dans les rseaux locaux Ethernet [IEE85],

savre donc impossible dans ce contexte. La mthode daccs au medium dans
les rseaux 802.11 est de type CSMA/CA (Collision Avoidance).
Une station souhaitant transmettre coute le support. Si le medium est libre
(dcision sur temporisation), elle transmet immdiatement. Sinon, elle coute
le canal jusqu ce quil soit libre. Lorsquil devient disponible, un algorithme
de back-off, dfini dans [IEE97], permet de rsoudre laccs si plusieurs stations
veulent transmettre en mme temps. La destination envoie un acquittement pour
confirmer la rception des donnes lmetteur. Le mcanisme de rservation
du canal VCS (Virtual Carrier Sense) est bas sur lenvoi dune trame RTS
(Request To Send) par lmetteur et CTS (Clear To Send) par le rcepteur. Ce
mcanisme est utilis pour rsoudre le problme de la station cache (hidden
node problem) qui survient lorsque deux nuds qui ne peuvent pas sentendre
(tant hors de porte directe) tentent dmettre vers la mme destination. Cette
rservation explicite du medium permet dviter les collisions lorsque la taille des
donnes transmettre est importante et quune retransmission serait coteuse.
Les dbits thoriquement atteignables varient de 11 Mbps (802.11b) 54
Mbps (802.11a/g) pour les produits actuellement dploys. La future norme
802.11n (prvue en 2007) devrait proposer un dbit thorique de 540 Mbps avec
une porte dune centaine de mtres lintrieur de locaux grce la technologie MIMO (Multiple Input Multiple Output) qui permet dutiliser plusieurs
antennes tant au niveau de lmetteur quau niveau du rcepteur. La technologie
MIMO sappuie sur les multi-trajets ds aux rflexions du signal, qui sont gnralement considrs comme une perturbation, pour atteindre des dbits plus
importants. Les propositions relatives aux rseaux maills sans fil, manant de
diffrents consortiums dindustriels, seront tudies dans le standard 802.11s et
devraient aboutir une norme courant 2007.
1.1.2.2
Bluetooth
Bluetooth fut propos par Eriksson en 1994 et appuy par la suite (en 1998)
par un consortium dindustriels (Nokia, IBM, Motorola, . . .) [Cha01]. Cette proposition fut intgre par lIEEE au sein du groupe 802.15 qui traite des rseaux
personnels WPAN (Wireless Personal Area Network). La technologie Bluetooth
est peu onreuse grce la forte intgration sur une unique puce. En contrepartie, la porte de transmission (quelques mtres) et les dbits atteignables (1
Mbps) sont faibles compars aux solutions 802.11 et HiperLAN.
1.1.2.3
HiperLAN
Le standard HiperLAN fut dvelopp par lETSI (European Telecommunications Standards Institute). Deux versions compatibles, HiperLAN1 (jusqu 20
Mbps) et HiperLan2 (jusqu 54 Mbps), ont vu le jour [hip95]. Hiperlan propose,
comme la norme 802.11, un mode infrastructure et un mode ad hoc. Hiperlan
fut soutenu par de nombreux industriels au sein du projet HIPERCOM mais
labsence de dveloppement par ces mmes industriels laissa le 802.11 comme
seule solution sur le march. Cependant, la conception dHiperlan a influenc

les fonctionnalits disponibles dans la norme 802.11. Par exemple, la possibilit
de fonctionnement en mode ad hoc du 802.11 fut hrite du standard Hiperlan.
1.1.2.4
Dploiement
Actuellement, de nombreuses implantations relles de rseaux ad hoc ont t

menes telles que les rseaux maills crs par des associations de consommateurs (Paris, Londres, . . .) et utilisant un routage ad hoc. Les diffrents points
daccs communiquent entre eux par voie hertzienne et le routage seffectue via
le protocole OLSR [CJ03](voir partie 3.3.4.2). Lutilisation dun routage ad hoc
entre les points daccs permet une plus grande souplesse lorsque le maillage est
modifi (par lajout, le retrait ou le dplacement de points daccs). OLSR est
un des protocoles les plus utiliss dans le dploiement de rseaux ad hoc. Microsoft a dvelopp un protocole de routage pour rseaux maills sans fil appel
LQSR (Link Quality Source Routing) [DPZ04]. Ce protocole est une extension
du protocole DSR (Dynamic Source Routing) [JMY04] (voir partie 1.3). DSR
a t modifi pour prendre en compte la qualit du lien radio dans sa slection des routes. Des exprimentations ont eu lieu dans diffrentes universits
(en particulier dans luniversit dUppsala qui a lun des bancs dessais les plus
importants [TGLN05]) afin dvaluer les rseaux ad hoc en conditions relles.
LIEEE a aussi tudi des technologies sans fil fournissant une couverture
plus importante. La technologie 802.16 (WiMax) traite des rseaux mtropolitains sans fil (WMAN) utilisant des stations de base fixes pour proposer des
connexions haut dbit par voie hertzienne des terminaux mobiles. Le WiMax
rentre dans la famille des rseaux maills avec infrastructure.
Dans la suite de ce document, nous supposerons que les nuds utilisent une
technologie issue de la famille 802.11 car ce standard est le plus utilis dans le
dploiement de rseaux ad hoc.
1.1.3
Caractristiques et contraintes
Par rapport aux rseaux filaires, les rseaux ad hoc prsentent les caractristiques suivantes :
En premier lieu, les rseaux ad hoc possdent une bande passante limite. En effet, les units mobiles communiquent via un medium radio
partag. La capacit des liens est limite et variable. Contrairement aux
rseaux filaires, un rseau sans fil est sensible lattnuation du signal,
aux interfrences ainsi quaux multi-trajets. Ces limitations rduisent la
bande passante thoriquement disponible. De plus, des problmes inhrents aux rseaux diffusion locale, bass sur une mthode daccs de
type CSMA/CA, surviennent. Le problme de la station cache (voir partie 1.1.2.1) peut engendrer des collisions en srie car le medium apparait
comme libre pour chacun des metteurs. Une autre source de limitation
de la bande passante provient du problme de la station expose (exposed

node problem) : tous les nuds porte de transmission dun metteur ne
peuvent pas mettre durant la dure de la transmission.
Dautre part, les diffrents quipements mobiles disposent de ressources
matrielles limites et htrognes en terme de batterie, de puissance
de calcul et de capacit de stockage. Lnergie des nuds doit donc tre
utilise avec parcimonie afin daccrotre leur dure de vie. Lhtrognit
des nuds, en terme de puissance de transmission et donc de porte de
transmission, peut aussi gnrer des liens unidirectionnels.
La mobilit des nuds produit une topologie hautement dynamique.
Les dplacements des stations mobiles sont imprvisibles et influent fortement sur lacheminement des donnes dans le rseau. En effet, le mouvement dune station peut crer et/ou dtruire les liens radio existants et
provoquer le partitionnement ou la fusion de rseaux ad hoc.
1.2
1.2.1
Principe du routage
Problmatique du routage
Les protocoles de routage traditionnellement dploys dans les rseaux filaires savrent inadapts aux contraintes des rseaux ad hoc.
Tout dabord, la capacit des liens tant limite, un protocole de routage
ad hoc doit tre efficace en bande passante utilise. Il doit minimiser le trafic de contrle (overhead ) ncessaire ltablissement et la maintenance des
routes afin de rduire la charge sur le rseau. La nature des liens peut aussi tre
variable (unidirectionnelle ou bidirectionnelle) tant donn lhtrognit des
nuds et doit tre prise en compte par le protocole de routage. Les ressources
matrielles restreintes des units mobiles excluent les algorithmes exigeants en
capacit de mmoire et de traitement. Enfin, un protocole de routage ad hoc
doit sadapter rapidement aux changements relativement frquents dans la topologie. Lalgorithme dobtention dune route doit tre optimal en terme de
rapidit, doit prendre en compte la mobilit des nuds et rechercher la route
la plus courte en nombre de sauts. En effet, le dplacement des units mobiles peut remettre en cause la validit des informations de routage. Labsence
dinfrastructure ou dadministration fixes dans le rseau impose par ailleurs un
fonctionnement distribu.
De nombreux travaux de recherche sur des protocoles de routage adapts
aux rseaux ad hoc ont t mens ds la fin des annes 90. Nous pouvons dfinir
deux gnrations de protocoles :
la premire gnration propose des mcanismes simples pour lobtention
et la maintenance des informations de routage.
la deuxime gnration vise ladaptation et loptimisation du routage par
rapport des contraintes particulires (passage lchelle, conomie dnergie, . . .).
1.2.2
Classification des protocoles de routage
Le routage dans les rseaux ad hoc prsente de nombreux challenges pour la

communaut scientifique. Un grand nombre de protocoles fut propos.
Les protocoles de routage ddis aux rseaux ad hoc peuvent tre caractriss
par leur catgorie (protocoles proactifs, ractifs ou hybrides), leur architecture
(plate ou hirarchique) ainsi que par leur type dalgorithmes (voir tableau 1.1).
Catgories
le fonctionnement des protocoles proactifs repose sur ltablissement des
routes lavance (DSDV (Destination-Sequenced Distance-Vector) [PB94],
OLSR, TBRPF). Cela signifie que les routes sont tablies avant quil y
ait demande de transmission. La maintenance des routes est assure par
lchange priodique dinformations de routage entre les units mobiles.
Les informations de routage sont toujours disponibles mais en contrepartie,
le rseau est continuellement encombr par un trafic de contrle dont une
Catgorie
Nom
Architecture
Algorithme
Ractifs
DSR
AODV
Plat
Plat
Vecteur
Routage
de
source
distance
Protocoles
Proactifs
OLSR
TBRPF
Hirarchique Hirarchique
Etat de
lien
Etat de lien
Hybride
ZRP
Hirarchique
Combinaison
Tab. 1.1 Caractristiques des principaux protocoles de routage ad hoc

partie importante est inutile : celle concernant les routes non modifies
et/ou non utilises. La frquence de rafraichissement des informations est
alors un paramtre important. En effet, un compromis doit tre trouv
entre minimisation du trafic de contrle et pertinence des informations de
routage.
le routage ractif, quant lui, sappuie sur ltablissement des routes la
demande (AODV, DSR). Une route nest calcule que si cest ncessaire
la communication entre deux nuds. La dure dobtention dune route
est souvent plus longue que pour un protocole ractif car la recherche
dun chemin vers la destination commence uniquement lorsque la source
veut transmettre des donnes. Cependant, le trafic de contrle requis pour
obtenir une route est minimis car les mcanismes ne sont dploys quen
cas de besoin.
les protocoles de routage hybrides tentent de runir les avantages des
deux approches (ZRP (Zone Routing Protocol)[HP98], IZR (Independent
Zone Routing)[SPH04]). Traditionnellement, les nuds maintiennent des
informations de routage sur leur voisinage (la notion de voisinage diffre
selon les algorithmes) de manire proactive tandis que les informations
concernant lextrieur du voisinage sont obtenues la demande.
Architectures
dans un protocole plat, toutes les units mobiles ont les mmes fonctionnalits quant au routage (DSR, AODV).
un protocole hirarchique distinguera certains nuds qui auront des
fonctionnalits de routage tendues par rapport aux autres nuds du rseau (OLSR).
Algorithmes
lun des protocoles vecteur de distance les plus connus dans lInternet est RIP (Routing Information Protocol) [Mal98]. Les nuds utilisant
le routage vecteur de distance dans les rseaux ad hoc maintiennent
une table de routage o chaque entre comprend une destination, le prochain nud pour atteindre la destination et une mtrique (le nombre de
sauts pour atteindre la destination) (AODV, DSDV). Cette mtrique va
permettre la mise jour des tables de routage lors de lchange dinforma-

tions de routage entre nuds car chaque unit mobile va conserver la route
la plus courte en nombre de sauts. Le routage par saut est utilis : chaque
nud relaie le paquet de donnes en se basant sur ladresse destination et
sur sa table de routage.
lun des protocoles de routage tat de liens les plus utiliss dans lInternet est OSPF (Open Shortest Path First) [Moy98]. Le routage tat
de liens ncessite que chaque nud maintienne un arbre partiel ou complet de la topologie du rseau (TBRPF, OLSR). Les nuds changent des
messages Hellos afin de dcouvrir leurs voisins. Ensuite, les arbres (ou les
sous-arbres selon les algorithmes) de topologie sont diffuss dans le rseau
afin que chaque nud puisse calculer ses routes. Les protocoles tat de
liens utilisent un routage par saut.
une unit mobile utilisant le routage source va indiquer, dans chaque paquet de donnes transmis, la liste des nuds (identifis par leurs adresses
IP) traverser pour atteindre la destination. Le routage source est une
option IP rarement utilise dans les rseaux filaires.
Nous prsentons par la suite les protocoles plats de premire gnration DSDV,
TORA (Temporally-Ordered Routing Algorithm) [PC97], AODV et DSR qui
furent les premiers protocoles tudis par lIETF. Les solutions hirarchiques
telles que ZRP ou OLSR seront considres dans le chapitre 3.
1.2.3
Exemples de protocoles de 1re gnration
1.2.3.1
DSDV
DSDV (Destination-Sequenced Distance-Vector) est un protocole proactif

vecteur de distance utilisant le routage par saut [PB94]. Chaque entre de la
table de routage est compose dune destination, du prochain saut pour atteindre
la destination, dune mtrique correspondant au nombre de sauts pour atteindre
la destination ainsi que dun numro de squence associ. Le numro de squence,
assign par la destination, permet de garantir un routage sans boucle et de
sassurer de la fracheur des routes.
Lorsquun nud reoit de nouvelles informations de routage, il les compare
celles de sa table de routage. La nouvelle route vers une destination est prfre
si elle a un numro de squence plus lev ou si elle possde le mme numro de
squence et une mtrique infrieure.
La maintenance des informations de routage est assure par la transmission
de mises jour de manire priodique (suivant le principe des paquets Hello
dans OSPF) ainsi que lors de changements de topologie.
1.2.3.2
TORA
TORA (Temporally Ordered Routing Algorithm) a t propos par Park et

Corson [PC97]. Cest un protocole ractif caractris par sa raction locale aux

changements de topologie. Son nom traduit lhypothse selon laquelle tous les
nuds ont leurs horloges synchronises (par exemple, par GPS).
La dcouverte et la maintenance de route sont bases sur la cration dun
graphe acyclique orient entre la source et la destination. Si un des liens du
graphe devient dfaillant, le concept dinversion de liens permet de rtablir le
graphe localement.
Le but de TORA est de trouver des routes stables qui puissent tre rpares
rapidement et localement, le caractre optimal des routes tant secondaire. Il
conserve plusieurs routes vers la mme destination afin dviter de dployer le
mcanisme de dcouverte de route trop frquemment.
1.2.3.3
AODV
Le protocole AODV (Ad hoc On demand Distance Vector), propos par

Perkins et Belding-Royer, combine des mcanismes ractifs de dcouverte et
de maintenance de routes avec le routage par sauts, lutilisation de numros
de squence et la transmission priodique de paquets Hello propres DSDV
[PBRS03]. Chaque entre de la table de routage comprend, comme dans DSDV,
une adresse destination, le prochain saut pour atteindre la destination, une mtrique indiquant le nombre de sauts pour atteindre la destination et un numro
de squence. Le protocole AODV utilise un mcanisme de dcouverte de route
la demande et les routes sont maintenues grce des changes priodiques
entre les nuds.
Le mcanisme de dcouverte de AODV est analogue celui du DSR que
nous dtaillerons dans la partie suivante. Il est prsent sur la figure 1.2. Pour
obtenir une route vers la destination recherche, la source va diffuser un paquet
de requte contenant ladresse de la destination et le dernier numro de squence
connu pour cette destination (figure 1.2(a)). Chaque nud traitant la requte
stocke une route de retour vers la source (sous la forme du prochain saut
utiliser pour atteindre la source). Il renvoie une rponse de route sil est la
destination ou sil possde une route avec un numro de squence plus grand
que celui contenu dans la requte (figure 1.2(b)). Sinon, le nud rediffuse la
requte.
Une route est considre comme active tant que des paquets de donne transitent par cette route (le prochain saut correspondant est alors un voisin actif).
Lactivation de la route se fait par lenvoi dune rponse de route vers la source
qui contient un numro de squence plus lev. Lors de la propagation de la
rponse de route, chaque nud intermdiaire stocke une route vers la destination. Ainsi, la source peut commencer lenvoi de donnes ds la rception de
la rponse de route. Chaque paquet de donnes est rout uniquement selon le
champ adresse destination.
Lorsquune route nest plus utilise (dtection sur timer), elle est supprime
de la table de routage. La maintenance de routes sappuie sur lchange priodique de paquets Hello. Si un nud ne reoit plus de paquet Hello dun voisin
actif, le lien est considr comme dfaillant. Un paquet derreur de route est
alors diffus vers les voisins actifs et relay jusqu la source qui pourra initier

une nouvelle dcouverte de routes. Un nud met une erreur de route sil dtecte la dfaillance dun lien, sil doit relayer un paquet pour lequel il ne possde
pas de route active ou sil reoit une erreur de route dun voisin concernant lune
de ses routes actives.
AODV utilise des tables de routage distribues. Cela diminue loverhead par
paquet car chaque paquet est rout uniquement selon le champ adresse destination (routage par saut). De plus, les nuds doivent priodiquement mettre
des paquets Hello afin de maintenir la fracheur des informations de routage.
(a) Requte de la source
(b) Rponse de la destination
Fig. 1.2 Dcouverte de routes AODV et DSR
1.3
DSR
Le protocole DSR (Dynamic Source Routing) a t labor dans le cadre

du projet Monarch (MObile Network ARCHitectures) men par le dpartement
informatique de luniversit de Rice [Joh94, JM96, JMY04]. Comme son nom
lindique, DSR est un protocole de routage par la source. Lmetteur des donnes
doit fournir la route (la liste des nuds traverser) ncessaire pour atteindre le
destinataire. Le chemin complet entre la source et la destination est prsent dans
len-tte de chaque paquet de donne. Ainsi, les nuds intermdiaires relaient
le paquet selon la route indique.
DSR utilise un en-tte doptions qui peut tre inclus dans tout paquet IP
pour vhiculer le trafic de contrle. Cet en-tte DSR suit immdiatement lentte IP du paquet (dans IPv4) ou loption Saut-Par-Saut (Hop-By-Hop dfinie
dans IPv6) si elle est prsente. Une ou plusieurs options DSR peuvent suivre
len-tte DSR. Chaque option est caractrise par un type. Les plus utilises sont
loption Route Source (la liste de nuds traverser), Route Request (requte
de route), Route Reply (rponse de route) et Route Error (erreur de route). Si
un nud ne comprend pas le type dune option, il lignore.
Dans la suite, nous allons dtailler les procdures du DSR et les principales
optimisations.
1.3.1
Procdures DSR
DSR est un protocole de routage ractif qui sappuie sur deux mcanismes :
la dcouverte de routes (Route Discovery) et la maintenance de routes (Route
Maintenance).
1.3.1.1
Dcouverte de routes
Lorsquune unit mobile dsire mettre des donnes mais ne dispose daucune route vers la destination, elle dclenche une dcouverte de routes. Celle-ci
seffectue en inondant le rseau comme dans le protocole AODV que nous avons
vu prcdemment (figure 1.2).
La source diffuse un paquet de requte de route (Route Request) contenant
ladresse de la destination recherche, une liste dans laquelle les adresses des
nuds traverss sont conserves ainsi quun identifiant de requte. En recevant
une requte de route, un nud vrifie quil ne la pas dj traite grce lidentifiant de requte et en vrifiant que son adresse nest pas dj dans le chemin.
Il va alors senregistrer dans le chemin et la propager tous ses voisins. Lorsque
la destination de la requte est atteinte, elle renvoie un paquet de rponse de
route (Route Reply) vers la source en utilisant le chemin construit lors de la
propagation de la requte 1.2(b).
1.3.1.2
Maintenance de routes
Lorsquun nud initie ou relaie un paquet de donnes, il doit sassurer que

le nud suivant dans le chemin a effectivement reu le paquet. Le contrle de la

rception du paquet par le nud suivant se fait au niveau MAC (par exemple,
grce au mcanisme dacquittement du 802.11). Si la transmission savre impossible (le prochain saut sest dplac ou il y a trop de collisions), le mobile qui
a dtect la dfaillance envoie un paquet derreur (Route Error) vers la source,
indiquant quel nud est lorigine du problme. La source tronque alors les
routes de son cache contenant le lien erron. Si la source dispose dune autre
route vers la mme destination (grce des rponses de routes supplmentaires
issues de sa dcouverte de routes ou bien via un chemin obtenu par coute
des autres paquets), elle poursuit lmission avec sa nouvelle route. Dans le cas
contraire, elle effectue une nouvelle dcouverte de routes.
1.3.2
Optimisations
Lun des principaux avantages du DSR rside dans son fonctionnement purement ractif car les mcanismes de routage ne sont dploys quen cas de besoin,
rduisant ainsi la consommation de bande passante. Lutilisation du routage par
la source (toutes les informations ncessaires au routage dun paquet de donnes sont contenues dans celui-ci) permet dviter les boucles. De plus, de cette
faon, seule la source doit maintenir une route cohrente vers la destination et
aucune mmorisation nest ncessaire sur les nuds intermdiaires. Cependant,
lutilisation du routage source implique un overhead important par paquet de
donnes car la route est incluse dans chaque en-tte. De nombreuses optimisations ont t apportes lalgorithme initial du DSR. Les deux mcanismes
principaux du DSR (Dcouverte et Maintenance de route) ainsi que la gestion
du cache ont t amliors pour minimiser le trafic de contrle et accrotre les
performances du protocole. Les optimisations dcrites ci-aprs sont dfinies dans
le draft IETF du DSR (groupe MANET) [JMY04].
1.3.2.1
Dcouverte de routes
coute active (Snooping) : lorsquun nud transmet un paquet de donnes

ou quil coute le support, il peut enregistrer dans sa table de routage le
chemin prsent dans le paquet.
rponse du cache (Replying from Cache) : si un nud reoit une requte
de route pour laquelle il possde un chemin dans son cache, il renvoie
directement une rponse la source et ne rediffuse pas la requte. Ainsi,
la dcouverte de routes est acclre et la charge doverhead sur le rseau
est diminue.
limitation de la porte des requtes : cette optimisation consiste ajuster
le TTL du paquet IP qui contient la requte de route. Le but est dviter
linondation du rseau avec des paquets de requte. Deux techniques de
dcouverte de route en dcoulent :
rponse des voisins (Non-propagating Route Request) : quand un nud
entreprend une dcouverte de routes, il envoie en premier lieu une
requte en positionnant le TTL (du paquet IP qui la contient) 1,
afin quelle ne soit pas rediffuse par ses voisins. Si aucune rponse na

t reue aprs expiration dun timer, la source dclenche une requte
avec un TTL gal la taille maximale dune route. Cette optimisation
prvient linondation inutile du rseau quand un des voisins est la
destination recherche ou quil possde la route adquate.
recherche incrmentale (Expanding Ring Search) [JM96] : le nud commence par envoyer une requte de route Non-propagating avec un
TTL gal 1. Si le nud ne reoit pas de rponse, il double la valeur
du TTL lors de sa requte suivante. Il poursuit ce processus jusqu
ce quil reoive une rponse de route. Avec cette technique, le nud
explore progressivement le rseau pour ne pas inonder systmatiquement le rseau.
Les techniques visant limiter la porte des requtes de route peuvent galement
tre utilises dans le protocole AODV.
1.3.2.2
rcupration de route (Salvaging) : le nud dtectant linaccessibilit du

nud suivant consulte son cache la recherche dun autre chemin menant
la destination. Sil possde une route, il renvoie un message derreur vers
la source en prcisant les modifications apportes au chemin et il transmet
le paquet de donnes avec la nouvelle route. Sinon, le nud peut lancer
une dcouverte de route cible vers le nud destinataire. Ainsi, on vite
de repartir de la source.
annonce de route errone (Gratuitous Route Errors) : lorsquune source
reoit un message derreur de route, elle le joint sa nouvelle requte de
route. Ainsi, elle ne recevra pas de rponse contenant le chemin erron.
1.3.2.3
Option Flow State
Cette option permet davoir un relayage par saut comme dans le cas dAODV.
Elle est active par la source aprs la dcouverte de route. Le but est de mettre
en place un routage des paquets de donnes qui est bas sur un numro de flot
plutt que sur une route explicite. Les nuds intermdiaires de la route dcouverte vont relayer les paquets en utilisant ladresse source et le numro de flot
associ la route. Loverhead de routage par paquet est rduit car len-tte DSR
ne contient plus de route source.
1.3.2.4
Gestion du cache
La table de routage utilise par les stations sources est un cache qui mmorise
les routes sous la forme de chemins (liste de nuds traverser). De nombreuses
tudes ont analys linfluence de lalgorithme grant la table de routage des protocoles ractifs et en particulier du DSR. En effet, la gestion du cache de routes
est primordiale sur les performances dun protocole comme DSR. Selon la mobilit du rseau, les informations contenues dans la table de routage peuvent vite
se rvler errones. Ltude prsente dans [HJ00] dmontre que lutilisation de

caches mmorisant des liens plutt que des chemins est plus efficace et devrait
tre choisie dans la plupart des implantations. Elle propose un algorithme de
gestion de cache bas sur une table de routage de liens et sur une table de stabilit qui conserve la stabilit observe de chacun des nuds prsents dans le
cache. Lide est de prvoir la dure de vie de chacun des liens afin de minimiser
lutilisation dinformations primes. Plutt que de prvoir la stabilit des liens,
lalgorithme prsent dans [YK05] propose de propager, de manire proactive,
les changements de liens tous les nuds concerns de manire distribue.
Lutilisation de ces optimisations peut entrainer des performances variables
selon les conditions de rseau. Dans le cas de loptimisation sur la porte des
requtes de route, loverhead est rduit lorsque la destination recherche est
proche (en nombre de sauts) de la source. On vite ainsi linondation du rseau.
Cependant, si la destination est loigne ou inaccessible (en cas de partitionnement du rseau), loptimisation peut avoir leffet contraire car elle gnre de
multiples dcouvertes de route et augmente la dure dobtention dune route (les
dcouvertes successives sont dclenches sur expiration de timer). Loption Flow
State pour le routage par saut est utilisable seulement si tous les nuds intermdiaires de la route peuvent mettre en place cette optimisation. Elle impose
aussi une mmorisation des flux sur chaque nud intermdiaire.
1.4
Axes de recherche sur le routage ad hoc
En 1997, un groupe de travail de lIETF, nomm MANET [IET](Mobile Adhoc NETworks), fut mis en place afin dassurer la normalisation de protocoles
de routage bass sur IP et adapts aux spcificits des rseaux mobiles autoconfigurables sans infrastructure. Jusqu prsent, le groupe MANET a standardis
les protocoles AODV (Ad hoc On demand Distance Vector) [PBRS03], TBRPF
(Topology Dissemination Based on Reverse-Path Forwarding) [OTL04], OLSR
(Optimized Link State Routing Protocol) [CJ03] et DSR (Dynamic Source Routing) [JMY04]. Les protocoles DYMO (Dynamic MANET On-demand) [CP06]
et SMF (Simplified Multicast Forwarding) [Mac06] sont actuellement ltat de
drafts.
Hors du groupe de travail MANET, dautres problmatiques de routage ad
hoc sont activement tudies. Nous pouvons citer en particulier :
lconomie dnergie
Cette famille dalgorithmes de routage vise minimiser lutilisation des
batteries des nuds. En effet, la limitation dnergie est une des contraintes
principales des rseaux ad hoc (partie 1.1.3). Ainsi, le choix dune route
peut tre bas sur le niveau de batterie des nuds qui la composent. Une
autre approche consiste mettre en place des mcanismes de contrle de
la puissance de transmission de lmetteur. Les algorithmes de contrle
de topologie (Topology Control ) minimisent la consommation dnergie
tout en maintenant la connectivit du rseau : ces protocoles identifient
et mettent en veille les nuds redondants.
la qualit de service
Les caractristiques spcifiques des rseaux ont conduit llaboration de
mcanismes de qualit de service appropris. Les politiques mises en place
se concentrent sur les garanties de bande passante et de dlai de bout en
bout sur les routes slectionnes.
le passage lchelle
Le passage lchelle des protocoles de routage ad hoc par rapport au
nombre de nuds, la charge de trafic et la mobilit est abord en
dtail dans la partie 2.4. Le chapitre 3 exposera les solutions de routage
existantes pour permettre le passage lchelle.
les architectures cross-layer
Les informations des couches basses de la pile protocolaire sont utilises
pour amliorer le routage. Par exemple, le taux derreur de transmissions
du niveau MAC est pris en compte pour choisir les routes.
1.5
Conclusion
Les protocoles de routage doivent sadapter aux contraintes spcifiques des

rseaux ad hoc comme la limitation de la bande passante et la dynamicit de
la topologie. La problmatique du routage prsente de nombreux challenges et
constitue un sujet dtude trs ouvert. Dans ce chapitre, nous avons ralis un
tat de lart des premires solutions proposes par la communaut scientifique.
Dans le chapitre 2, nous analyserons les performances des protocoles dcrits dans ce chapitre en nous basant sur diffrentes tudes dont la ntre. Cette
analyse nous permettra de dterminer les points forts et les faiblesses des protocoles tudis. En particulier, nous dterminerons les conditions de rseau dans
lesquelles les protocoles de 1re gnration voient leurs performances se dgrader.
Chapitre 2
Evaluation de performances
Sommaire
2.1
2.2
2.3
2.4
2.5
Notions de performances du routage . . . . . . . .

2.1.1 Mesures externes de lefficacit . . . . . . . . . . .
2.1.2 Mesures internes de lefficacit . . . . . . . . . . .
2.1.3 Paramtres dvaluation . . . . . . . . . . . . . . .
2.1.4 Environnements de simulation . . . . . . . . . . .
Modles de mobilit . . . . . . . . . . . . . . . . . .
2.2.1 Modle Random Waypoint . . . . . . . . . . . . .
2.2.2 Modle RPGM . . . . . . . . . . . . . . . . . . . .
2.2.3 Influence du modle de simulation . . . . . . . . .
2.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . .
Rsultats dvaluation des protocoles de routage
2.3.1 Etude de lquipe Monarch . . . . . . . . . . . . .
2.3.2 Etude de lquipe Ericsson . . . . . . . . . . . . .
2.3.3 Problmes de performances de DSR et AODV . . .
Problmatique du passage lchelle . . . . . . .
2.4.1 Limitations de la diffusion . . . . . . . . . . . . . .
2.4.2 Etudes du passage lchelle . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
24
24
26
27
28
29
30
31
31
32
33
37
37
38
42
Nous avons vu dans le chapitre 1 que de nombreux protocoles de routage ad

hoc ont t proposs.
Pour effectuer lvaluation de performances de ces protocoles, des mtriques
de performances et des paramtres de simulation sont prsents dans la partie
2.1.
Parmi les paramtres de simulation, lun des plus critiques est la modlisation
de la mobilit des nuds : ce point sera abord dans la partie 2.2.
Nous prsentons dans la partie 2.3 nos rsultats dvaluation ainsi que ceux
fournis par la littrature.
22
CHAPITRE 2. EVALUATION DE PERFORMANCES
23
Les diffrentes tudes de performances montrent la difficult de passage

lchelle pour les protocoles de routage : cette problmatique sera tudie dans
la dernire partie de ce chapitre.
2.1
Notions de performances du routage
Limportance des mthodes dvaluation des protocoles de routage ad hoc fut

aborde ds le premier RFC publi par le groupe de travail MANET [CM99]. Les
mtriques quantitatives utilisables pour valuer un protocole sont prsentes par
Corson et Macker. La mesure externe de lefficacit du routage (comment la
performance du protocole est perue par les mcanismes utilisant le routage) est
spare de sa mesure interne (pour un mme niveau externe de performances,
deux algorithmes vont dployer des volumes doverhead diffrents).
2.1.1
Mesures externes de lefficacit
Les mesures externes de lefficacit dun protocole ad hoc regroupent :

le dlai de bout en bout
le dbit de bout en bout
le temps dacquisition dune route (uniquement dans le cas des protocoles
ractifs)
le pourcentage de segments reus hors squence (intressant du point de
vue de la couche transport car TCP ajuste sa fentre en cas darrives
dsordonnes de segments)
2.1.2
Mesures internes de lefficacit
Pour mesurer lefficacit interne du protocole, les mtriques suivantes sont

conseilles :
le nombre moyen de bits de donne transmis / nombre de bits de donne
reus
le nombre moyen de bits de contrle transmis / nombre de bits de donne
reus
le nombre moyen de paquets de contrle et de donne transmis / nombre
de paquets de donne reus
Cette dernire mtrique est particulirement intressante car elle mesure lefficacit du protocole en terme daccs au canal partag. En effet, laccs au medium
se rvle coteux dans les rseaux forte contention comme les rseaux ad hoc.
La mthode daccs CSMA/CA utilise des temporisations et des mcanismes de
rservation pour laccs au canal (partie 1.1.2.1). La transmission dune trame
peut ainsi tre retarde selon le nombre de stations en contention et lalgorithme
de back-off. De plus, la mthode CSMA/CA empche les nuds partageant le
mme espace de contention dmettre pendant la dure de la transmission (problme de la station expose, voir partie 1.1.3). La mesure du trafic de contrle
24
et de donne en nombre de paquets permet de prendre en compte limportance

de laccs au medium par rapport la taille des trames transmises.
2.1.3
Paramtres dvaluation
Les paramtres dvaluation sont aussi considrs dans le RFC 2501. En

effet, le grand nombre dapplications potentielles des rseaux ad hoc impose une
valuation du protocole dans plusieurs contextes diffrents (chaque contexte
tant dcrit par un ensemble de paramtres). Les paramtres retenus ici sont :
la taille du rseau (exprime en nombre de nuds)
la connectivit (le degr moyen dun nud o le degr reprsente le nombre
de voisins dun nud)
le taux de changement de la topologie (la vitesse laquelle la topologie
est modifie)
la mobilit (ce point soulve la question des modles de mobilit que nous
verrons dans la section 2.2)
le type de trafic
la capacit relle du lien (en prenant en compte les pertes dues laccs
multiple), le nombre de liens unidirectionnels
Un protocole de routage ad hoc doit fonctionner sur une gamme de contextes
trs varis comme le montrent les paramtres dcrits ci-dessus. Les performances
sont trs lies aux conditions de rseaux. Cest pour cela que la plupart des
quipes ont privilgi lvaluation par simulation lapproche formelle car la
modlisation mathmatique des environnements ad hoc (avec des paramtres
comme la mobilit) savre actuellement difficile exploiter.
2.1.4
Environnements de simulation
Les environnements de simulation les plus utiliss pour modliser les rseaux
ad hoc sont ns-2 [NS], OPNET [OPN] et GloMoSim [Glo] :
ns-2
Cest un environnement complet de simulation crit en C++ et Tcl dont
le code source est ouvert. Il offre un choix important de protocoles (de la
couche applicative jusqu la couche physique) permettant une grande libert de modlisation. ns-2 est actuellement lenvironnement de simulation
de rseaux le plus utilis par la communaut acadmique car il est totalement gratuit et permet limplantation de nouveaux modules. Cependant,
limplantation dun nouveau protocole se rvle complexe car elle requiert
une connaissance approfondie de loutil de simulation.
OPNET
Cest un outil commercial de modlisation et de simulation de rseaux trs
utilis dans la communaut industrielle. Il propose, comme ns-2, un trs
grand choix de protocoles. Cependant, OPNET est moins rpandu que
ns-2 dans les milieux acadmiques car il a un cot lev. Comme ns-2,
25
OPNET demande un certain temps de prise en main lorsquon souhaite

ajouter son propre module.
GloMoSim
Cest un environnement de simulation grande chelle pour les rseaux
mobiles sans fil. Il est crit en Parsec, un langage de programmation bas
sur le C qui permet la simulation dvnements discrets en parallle. GloMoSim a un nombre de modles plus faible que ns-2 et OPNET et la
communaut utilisant cet outil est plus restreinte.
Pour permettre la comparaison des rsultats de simulation entre diffrentes
quipes, lutilisation dun outil commun est prfrable. Ainsi, grce sa gratuit et son nombre important de modules, ns-2 est lun des outils de simulation
les plus utiliss. Les rsultats de simulation que nous prsenterons dans la partie
2.3 ont t obtenus sous lenvironnement ns-2.
Comme la plupart des quipes de recherches, nous avons choisi une valuation par scnarii pour prendre en compte les nombreux paramtres possibles
(taille du rseau, densit de nuds, type et charge de trafic, conditions de
mobilit, . . .) . Ainsi, linfluence de chacun des paramtres peut tre value
sparment.
2.2
26
Modles de mobilit
Lun des paramtres de simulations les plus critiques est la mobilit. En effet,
la manire de la modliser influence directement le comportement des protocoles
tudis. Le choix du modle de mobilit est primordial dans la simulation denvironnements mobiles : il doit tre suffisamment raliste afin de prendre en compte
le comportement des units mobiles et relativement simple pour ne pas gnrer
une charge de calcul trop importante. Il dpend principalement des applications simules et des scnarii utiliss. Par exemple, il peut servir reprsenter
le comportement des units mobiles dans une zone mtropolitaine, lors dune
confrence ou sur un terrain dopration militaire. Ce choix est critique dans
les MANET car les performances du protocole valu en dpendent fortement
comme cela a t dmontr dans [JLH+ 99, JWT02]. La reprsentation de la
mobilit varie normment selon les environnement considrs et de nombreux
modles de mobilit ont t mis au point pour couvrir les divers comportements
possibles.
Les modles de mobilit se divisent en deux catgories :
les modles individuels, o les dplacements de chaque nud sont dtermins indpendamment les uns des autres
les modles de groupe, qui prennent en compte la corrlation de dplacements entre certains nuds. Ces modles divisent les nuds en plusieurs
groupes et dfinissent une relation entre les units mobiles appartenant
un mme groupe.
De plus, il existe trois types de loi de mouvement : alatoire, dterministe et
hybride.
les modles alatoires prsentent des dplacements arbitraires et sans
contraintes denvironnement. Ce sont des modles simples mettre en
uvre et par consquent trs utiliss.
les modles dterministes, quant eux, sappuient sur des traces (comportements dutilisateurs observs dans des systmes rels). Cependant, les
rseaux ad hoc restent ltat mergent et trs peu de traces relles sont
disponibles.
des modles hybrides sont en cours dlaboration afin de raliser un
compromis entre simplicit et ralisme mais ils restent difficiles mettre
en place.
Parmi les modles individuels, nous pouvons citer les modles Random Waypoint, Random Direction, Boundless Simulation Area et Gauss-Markov. RPGM
(Reference Point Group Model) et les modles de Sanchez sont les modles de
mobilit de groupe les plus utiliss. Enfin, les modles Manhattan (reprsentant
le mouvement des nuds dans une zone urbaine) et Freeway (modlisant les
dplacements de vhicules sur un rseau routier) sont des modles hybrides bass sur lutilisation de cartes. Dans la suite, les modles Random Waypoint et
RPGM sont dcrits plus en dtail.
27
Fig. 2.1 Dplacement dun nud selon le modle Random Waypoint
2.2.1
Modle Random Waypoint
Ce modle a t mis au point et utilis par le groupe de recherche Monarch

[JM96]. Il est alatoire et comprend des temps de pause entre les changements
de direction et de vitesse. Le principe en est simple : au dbut de la simulation,
chaque unit mobile reste sur sa position pendant son temps de pause. A lexpiration de ce dlai, elle choisit alatoirement une nouvelle destination dans laire
de simulation. Chaque station choisit aussi une vitesse de dplacement (suivant
une loi uniforme) pour atteindre sa nouvelle destination. Une fois que lunit
mobile arrive cette position, le schma prcdent se rpte : attente pendant le
temps de pause, tir dune destination et dune vitesse. La figure 2.1 montre le dplacement dune unit mobile suivant le modle de mobilit Random Waypoint.
Le modle Random Waypoint est le modle de mobilit le plus employ
actuellement dans la simulation de rseaux ad hoc. Tout dabord, sa grande
simplicit de fonctionnement facilite sa mise en uvre. De plus, sa disponibilit
sur les environnements de simulation OPNET et surtout ns2, qui sont des environnements de simulation trs utiliss actuellement, a contribu sa popularit
et de nombreuses quipes de recherche lont adopt pour leurs simulations de
28
rseaux ad hoc.
Cependant, le modle Random Waypoint prsente certaines lacunes. Il est
sans mmoire, i.e la position et la vitesse passes ne sont pas prises en compte
lors de la dtermination dune nouvelle destination. Ceci peut conduire des
comportements irralistes comme des arrts brutaux ou des changements radicaux de direction. Dautres dfauts, plus inattendus, existent. Tout dabord, ce
modle ne permet pas datteindre un tat stable en terme de vitesse moyenne
(les nuds se dplacent de plus en plus lentement avec le temps) [YLN03].
Par consquent, cela peut conduire des rsultats errons, en particulier les
moyennes temporelles.
De plus, la rpartition alatoire initiale des units mobiles influe sur les
rsultats de simulation. Dans [CBD02], Boleng et Camp ont observ lvolution
du nombre de voisins au cours du temps. Ils constatent que le nombre moyen
de voisins par nud est trs variable au dbut de la simulation cause de la
rpartition initiale et conseillent la suppression du dbut de la simulation lors
de lexploitation des rsultats. Un comportement non dsir des nuds mobiles
a galement t mis en vidence, ils tendent passer frquemment par le centre
de la surface de simulation [RPSM01].
Ces limitations du modle Random Waypoint nous ont pouss considrer
un autre modle dans nos simulations, le modle RPGM.
2.2.2
Modle RPGM
Dans les applications possibles des MANET, la notion de groupe intervient

de nombreuses reprises (quipes de secours, dtachements militaires, confrences
). Les modles de mobilit individuels sont inadapts la simulation de ces
scnarii car les mouvements des units mobiles sont indpendants les uns des
autres. Dans les modles de groupe, lensemble des nuds est divis en plusieurs
groupes et il existe une relation entre les dplacements des units appartenant
un mme groupe.
Les modles de Sanchez sont des modles de mobilit de groupe [CBD02].
Trois modles sont dfinis et chacun reprsente une application bien prcise :
le modle en colonne reproduit une recherche dobjets ou de personnes
(battue pour retrouver un disparu). Les membres dun groupe forment
une ligne et se dplacent suivant le mme vecteur de dplacement.
le modle de poursuite : il sert modliser un ensemble de nuds la
recherche dune cible (des officiers de police cherchant apprhender un
suspect). Les membres du groupe suivent les dplacements de la cible.
le modle de la communaut nomade reprsente les mouvements dun ensemble de nuds qui se dplacent ensemble. Les membres du groupe se
dplacent autour dun point de rfrence commun au groupe.
Le modle RPGM a t dfini par lquipe de Gerla [HGPC99] et il permet de
reproduire tous les modles de Sanchez.
RPGM modlise aussi bien les dplacements des groupes que les dplacements des units mobiles au sein dun mme groupe. Il utilise la notion de centre
29
Fig. 2.2 Principe du modle RPGM

logique pour dterminer le dplacement du groupe (position, vitesse, direction).
Le fonctionnement de RPGM est schmatis sur la figure 2.2.
Chaque nud possde un point de rfrence qui suit le mouvement du centre
logique du groupe. A lintrieur dun mme groupe, tous les points de rfrence
connatront un dplacement identique. Dans un second temps, chaque unit
mobile va se dplacer alatoirement dans le voisinage (un rayon maximal est
spcifi) de son point de rfrence.
Le chemin suivi par le centre logique est caractris par une suite de points de
contrle qui correspondent des intervalles de temps donns. Lutilisation dune
squence de points de contrle, qui peut tre obtenue partir de donnes relles
(cartes, . . .), permet de gnrer de nombreux scnarii. Laire de simulation peut
tre partitionne en assignant un groupe chaque rgion (modle In-Place). Des
groupes peuvent excuter des tches diffrentes dans la mme aire de simulation
et tre amens se croiser (modle Overlap).
2.2.3
Influence du modle de simulation
Le choix du modle de mobilit influe sur les rsultats de simulation. Lutilisation de diffrents modles permet didentifier les concordances de rsultats.
Etude Monarch : Hu et Johnson ont ralis une tude portant sur la comparaison de diffrents algorithmes de gestion de cache. Ils ont fait intervenir
30
plusieurs modles de mobilit dans la phase de simulation [HJ00]. On retrouve notamment les modles de groupe crs par Sanchez et le modle
Random Waypoint. De cette valuation de performances qui fait intervenir plusieurs modles de mobilit, il ressort que leur choix est trs li au
type dapplication simule. Ici, pour prouver les diffrentes gestions du
cache, il fallait des modles avec un degr de mobilit lev mais aussi une
certaine connectivit dans le rseau. Certains modles de groupe, comme
le modle de poursuite, gnrent des partitions du rseau frquentes et
savraient inadapts. Les rsultats concordants sur plusieurs modles de
mobilit assurent une plus grande robustesse de lalgorithme de cache en
fonction des conditions de mobilit.
Etude Toilers : une tude du groupe Toilers effectue une comparaison plus
pousse de diffrents modles de mobilit [CBD02]. Elle regroupe les modles Random Walk, Random Waypoint, Random Direction et RPGM.
Pour ce dernier, on distingue deux sous-modles : dans le premier, les
communications seront exclusivement inter-groupes (RPGM inter) alors
que dans le second la moiti du trafic sera ddie la communication
intra-groupe et lautre moiti la communication inter-groupes (RPGM
inter-intra). Le protocole utilis pour comparer ces diffrents modles est
DSR. Les performances du protocole varient normment en fonction du
modle de mobilit, prouvant son influence dans lvaluation. Le choix
dun modle est li au type dapplications : par exemple, RPGM offre de
meilleurs rsultats quand la communication lintrieur dun groupe est
importante.
2.2.4
Conclusion
Le choix du modle de mobilit a un impact certain sur lvaluation dun

protocole ddi aux MANET, et plus particulirement pour un protocole de
routage. Random Waypoint savre tre un modle quasi-obligatoire (malgr
ses nombreux dfauts) vu sa popularit. Pour pouvoir comparer les rsultats de
simulation issus de diffrentes tudes, il convient dutiliser ce modle. Le modle
RPGM apparait comme le modle de groupe le plus gnral et le plus complet
(les modles de Sanchez sont entirement reproductibles partir de RPGM). Il
permet par ailleurs de couvrir un grand nombre dapplications non ralisables
avec le modle Random Waypoint.
2.3
31
Rsultats dvaluation des protocoles de routage
De nombreuses tudes ont t menes afin de comparer les performances des

diffrents protocoles de premire gnration dcrits dans le chapitre prcdent.
Les trois tudes prsentes dans cette partie ont t menes sous lenvironnement
de simulation ns-2. Elles sont exposes dans lordre chronologique de leur parution. Nous rappelons que les principales caractristiques des protocoles tudis
dans cette partie sont regroupes dans le tableau ??.
2.3.1
Etude de lquipe Monarch
Une des premires valuations de performances sur diffrents protocoles de

routage ad hoc a t mene par lquipe Monarch [BMJ+ 98]. Elle prsente les
comportements relatifs de quatre protocoles : DSDV (proactif), TORA, DSR
et AODV (ractifs). Lenvironnement de simulation est ns-2 et le modle de
mobilit utilis est Random Waypoint. Le choix des paramtres a t repris par
de nombreuses quipes. Les sources de trafic sont de type CBR (Constant Bit
Rate) et le nombre de sources est variable (10, 20 et 30). Le nombre de nuds
est fix 50 et le temps de simulation est de 900 secondes. Laire de simulation
est de 1500m x 300m. Les liens sont considrs comme bidirectionnels.
Les critres de performances tudis sont :
le packet delivery ratio (PDR) : cest le rapport entre le nombre de messages mis au niveau application par les sources CBR et le nombre de
messages applicatifs reus au niveau des destinations.
le trafic de contrle : il doit tre le plus faible possible pour optimiser la
bande passante du rseau. Il est mesur en nombre de transmissions de
paquet de contrle.
la pertinence du chemin : cest la diffrence entre le chemin pris par les
donnes et le chemin le plus court existant entre la source et la destination.
Cela montre la capacit du protocole trouver les routes les plus efficaces
en termes de nombre de nuds intermdiaires.
Le facteur de mobilit est une grandeur permettant de quantifier la mobilit au
cours de la simulation. Le facteur de mobilit choisi ici pour comparer les quatre
protocoles est le temps de pause (paramtre dentre du modle de mobilit
Random Waypoint). Le temps de pause prend les valeurs : 0, 30, 60, 120, 300,
600 et 900s.
Lquipe Monarch a obtenu les rsultats suivants :
AODV et DSR sont les plus efficaces en terme de PDR quel que soit le
nombre de sources de trafic.
AODV et DSR utilisent moins de trafic de contrle par rapport TORA
et DSDV. DSR savre plus performant quAODV, surtout forte mobilit
(temps de pause = 0). Cependant, il faut rappeler que loverhead est mesur en nombre de paquets. Or, len-tte DSR est de taille non ngligeable
car il contient toute la route que le paquet doit suivre.
32
Si on raisonne en charge, alors AODV devient meilleur, sauf en cas de

forte mobilit (temps de pause = 0).
Les protocoles les plus performants quant la pertinence du chemin sont
DSDV et DSR. De plus, contrairement TORA et AODV, ce critre est
relativement indpendant du degr de mobilit.
Globalement, les rsultats sont favorables au protocole DSR, et dans une moindre
mesure au protocole AODV.
Cette tude a servi de base de nombreuses simulations. A ce titre, elle
a t conteste sur de nombreux points. En premier lieu, le degr de mobilit
choisi nest pas forcment reprsentatif de la dynamique du rseau. Le trafic de
contrle aurait d tre compar au trafic de donnes vhicul par le protocole.
En effet, un protocole peut gnrer plus doverhead mais acheminer plus de
donnes. En ce sens, le rapport du volume de contrle sur le volume de donnes
aurait t plus judicieux (voir partie 2.1). Pour finir, le critre de distance pour
dfinir la pertinence du chemin est assez rducteur (aucun rsultat relatif aux
dlais nest prsent).
2.3.2
Etude de lquipe Ericsson
Cette tude [JLH+ 99] est particulirement intressante car, outre lutilisation
de Random Waypoint pour les scnarii alatoires, elle emploie des scnarii plus
ralistes pour reprsenter des applications plus spcifiques :
confrence (les nuds sont considrs comme ayant une faible mobilit)
couverture dvnements (forte mobilit)
catastrophe (nuds lents et nuds plus rapides attachs des vhicules).
Les protocoles de routage DSDV, AODV et DSR sont compars selon un nouveau facteur de mobilit qui traduit la vitesse relative des nuds (ce facteur est
calcul partir du scnario de mobilit). Les sources de trafic sont CBR et sont
au nombre de 15. Le nombre de nuds est fix 50 dans une aire de simulation
carre de 1000m x 1000m. Le dbit dmission des sources est de 5, 10, 15 et 20
paquets/s.
Les critres de performances prsents sont :
le dlai de bout en bout
le dbit de donnes reues
loverhead de routage en nombre de paquets et en terme de bits
Les rsultats obtenus par lquipe Ericsson confirme lavantage des protocoles
DSR et AODV sur DSDV, comme cela avait t montr par ltude prcdente.
En effet, leurs performances en terme de dlai et de dbit sont largement suprieures que ce soit sur les scnarii alatoires ou sur les scnarii ralistes. DSR
et AODV ont quasiment le mme comportement sur lensemble des scnarii.
Cependant, ltude montre que DSR se comporte mieux que AODV lorsque la
charge de trafic est faible alors que la tendance sinverse lorsque la charge devient leve (AODV a alors de meilleures performances). En effet, loverhead en
bits du DSR est suprieur celui dAODV lorsque la charge de trafic est grande
cause de lutilisation du routage source. Au contraire, le protocole AODV a
Figure 2.3: Rapport
Donn
ees
T raf ic de contr
ole
33
pour 10 connexions
loverhead en bits le plus faible des protocoles considrs, car seule ladresse
de destination est incluse dans les paquets de donnes, mais en contrepartie il
affiche un overhead en terme de paquets lev d lmission priodique de paquets Hello. Ce trafic priodique le pnalise donc sur les configurations faible
charge. Lutilisation de scnarii plus ralistes a permis de conforter lefficacit
des protocoles DSR et AODV sur le protocole DSDV quelque soit le contexte
considr.
2.3.3
Problmes de performances de DSR et AODV
Les tudes prcdentes ont rvl que les protocoles DSR et AODV prsentaient les meilleures performances parmi les protocoles de premire gnration.
Sappuyant sur ces rsultats, nous avons compar plus en dtail les performances
des protocoles AODV et DSR.
Nous avons utilis lenvironnement de simulation ns2 (version 2.27) pour
effectuer notre tude de performances. Nous utilisons les implantations des protocoles DSR et AODV intgres ns2. Au niveau MAC, nous utilisons le modle
802.11 implant par le groupe Monarch. Nous gardons les valeurs par dfaut des
paramtres de ce modle.
La porte de transmission de chaque nud est fixe 150 m.
Nous fixons la dure de simulation 1000s.
Laire de simulation est de 1000m x 1000m.
Nous avons effectu des simulations pour 50, 100 et 150 nuds.
Le modle de mobilit est Random Waypoint. La vitesse maximale de
dplacements des nuds est limite 20 m/s et nous avons utilis des
temps de pause de 100, 200, 300, 400 et 500s.
34
Le trafic de donnes est de type CBR (Constant Bit Rate) et le dbit

dmission est de 4 paquets/s.
Pour comparer les performances relatives des deux protocoles, nous calculons
les critres de performances suivants :
T raf ic de contr
ole : le nombre de paquets de contrle transmis. Nous prenons en compte chaque transmission du paquet si la communication seffectue sur plusieurs sauts.
Donn
ees : le nombre de paquets de donnes reus.
ees
Charge de donn
ees normalis
ee : elle est dfinie comme T rafDonn
ic de contr
ole .
Ce critre de performances constitue une mesure interne de lefficacit du
protocole (voir partie 2.1.2).
Le trafic de contrle et de donnes est mesur en termes de paquets comme pour
ltude Monarch.
Les rsultats que nous avons obtenu sont les suivants.
Nous observons dans un premier temps la charge de donnes normalise en
fonction de la densit de nuds (Figure 2.3). 10 connexions sont mises en place.
Chaque point calcul reprsente une moyenne sur 50 scnarii de mobilit (10
scnarii pour chaque temps de pause).
Pour 50 nuds, les protocoles DSR et AODV prsentent des performances
trs proches mme si celles de DSR sont lgrement suprieures. Cette diffrence
est de au trafic de contrle priodique gnr par le protocole AODV : les nuds
AODV mettent priodiquement des messages Hello (voir partie 1.2.3.3).
Pour 100 nuds, la diffrence entre DSR et AODV saccentue. En effet, le
nombre de connexions reste fixe tandis que le nombre de nuds augmente : le
trafic de contrle ncessaire ltablissement des routes est quivalent dans les
deux protocoles mais le trafic de contrle priodique dAODV augmente.
Pour 150 nuds, la tendance sinverse : la diffrence entre DSR et AODV
diminue. La politique de maintenance de routes dAODV savre plus efficace et
compense le trafic priodique. Cependant, DSR prsente toujours de meilleures
performances.
ees
DSR savre plus performant quAODV en terme de rapport T rafDonn
ic de contr
ole
quelle que soit la densit de nuds, mme si lcart est faible.
La figure 2.4 prsente la charge de donnes normalise en fonction du temps
de pause (paramtre de mobilit). Le critre de performance est calcul sur diffrentes configurations de densit (50, 100 et 150 nuds). Chaque point calcul
reprsente une moyenne sur 10 scnarii de mobilit.
Nous observons tout dabord que DSR obtient de meilleures performances
faible mobilit (temps de pause = 500s) quelle que soit le nombre de nuds :
le trafic de contrle priodique dAODV pnalise ce protocole lorsque les mcanismes de dcouverte de route sont peu utiliss. Lorsque la mobilit augmente,
les mcanismes de routage sont plus utiliss. La politique de maintenance de
routes dAODV est plus efficace. De plus, la politique de cache du DSR est coteuse lorsque la mobilit est grande : la source essaye toutes les routes disponibles
vers la destination avant de recourir la procdure de dcouverte de route. Ce
35
comportement gnre de nombreuses erreurs de routes. Ainsi, la diffrence entre

DSR et AODV tend diminuer lorsque la mobilit augmente : AODV savre
mme plus performant que DSR forte mobilit (temps de pause < 200s) pour
les densits de 50 et 150 nuds.
Les protocoles DSR et AODV voient leurs performances diminuer lorsque la
densit de nuds augmente.
Nous avons compar les performances relatives des protocoles DSR et AODV
avec une charge de trafic plus importante : le nombre de connexions est fix
20. La figure 2.5 montre la charge de donnes normalise en fonction du temps
de pause pour une densit de 100 nuds.
Pour la mme densit, DSR est plus performant lorsque le nombre de connexions
est faible mme si la diffrence diminue lorsque la mobilit augmente (voir figure
2.4(b)). Lorsque le nombre de sources augmente, la diffrence entre les deux protocoles diminue. AODV prsente mme de meilleures performances que DSR
forte mobilit (temps de pause = 100s).
Le protocole AODV passe relativement mieux lchelle que DSR par rapport la charge de trafic.
Les rsultats obtenus sont confirms par ltude de lquipe Perkins sur 50
et 100 nuds qui montre les difficults des deux protocoles, en particulier DSR,
lorsque le nombre de nuds et la charge du rseau augmentent [DPR00].
36
(a) 50 nuds
(b) 100 nuds
(c) 150 nuds
Figure 2.4: Rapport

sits de nuds
Donn
ees
T raf ic de contr
ole
pour 10 connexions pour diffrentes den-
Figure 2.5: Rapport

100 nuds
2.4
2.4.1
Donn
ees
T raf ic de contr
ole
37
pour 20 connexions pour une densit de
Problmatique du passage lchelle

Limitations de la diffusion
Les rseaux ad hoc reposent sur des technologies proposant un canal radio partag. Ce type de medium est bien adapt lutilisation de la diffusion
(broadcast) ds lors que lon veut transmettre un message tous ses voisins.
De nombreux protocoles de routage ad hoc emploient le mcanisme de diffusion
afin de mettre en place et de maintenir les chemins de communication. En particulier, les protocoles ractifs comme DSR et AODV sappuient sur la diffusion
lors de leur procdure de dcouverte de routes qui vise inonder le rseau de
paquets de requte. Ainsi, chaque nud rediffuse le paquet de requte reu
lensemble de ses voisins. Lutilisation de linondation gnre un certain nombre
de problmes [TNCS02] :
redondance : un nud recevra et devra traiter plusieurs fois le mme
paquet car ses voisins vont le rediffuser.
collision : dans la mthode daccs CSMA/CA du 802.11, il ny a pas de
mcanisme de rservation du medium de type RTS/CTS pour la diffusion
de trames multipoint. Les collisions sont donc possibles. De plus, labsence
de mcanisme dacquittement pour les trames diffuses peut mener des
collisions rptes.
contention : tous les voisins dun nud vont rediffuser le paquet diffus
au mme instant et leurs communications vont entrer en concurrence pour
laccs au canal.
manque de fiabilit : en labsence de mcanisme dacquittement, on ne
38
peut tre sr que tous les nuds aient t atteints.

consommation de la bande passante : linondation du rseau implique
que tous les nuds ayant reu le paquet vont le rediffuser leur tour,
consommant ainsi normment de bande passante.
Tous ces problmes sont accentus sur des configurations de rseaux denses. En
effet, les collisions et la redondance dinformations augmentent avec le nombre
de voisins. Linondation du rseau, si elle est acceptable sur des rseaux de petite
taille, devient rapidement trs coteuse en terme de trafic de contrle sur des
rseaux denses et de grande taille. Dautre part, si le nombre de connexions est
important, les mcanismes bass sur linondation (comme la dcouverte de route
des protocoles ractifs) seront sollicits trs frquemment. Ds lors, le passage
lchelle dun protocole de routage utilisant linondation devient difficile.
2.4.2
Etudes du passage lchelle
La notion de passage lchelle dun protocole est particulirement importante dans les rseaux ad hoc. La ncessit de mettre au point des algorithmes
permettant le passage lchelle est impose par les contraintes ad hoc :
labsence dadministration centralise rend difficile toute planification ou
dimensionnement du rseau.
dans le cas des protocoles ractifs, la diffusion consomme beaucoup de
bande passante.
les ressources des units mobiles (en termes de batterie, de mmoire, . . .)
restreignent les algorithmes gourmands en mmoire et en calcul.
le dynamisme du rseau peut faire changer les conditions dutilisation.
Le nombre de nuds peut augmenter trs rapidement via la fusion de
diffrents rseaux ad hoc. Dans le domaine des rseaux de capteurs, le
nombre de nuds peut potentiellement atteindre le million. De plus, les
dplacements des units mobiles peuvent impliquer une densit de nuds
accrue.
lorsque la mobilit des nuds ou le nombre de connexions augmentent, les
mcanismes de routage sont utiliss plus souvent et leur consommation en
bande passante peut augmenter trs rapidement.
Nous verrons dans cette partie les diffrentes caractrisations du passage
lchelle proposes par le groupe ANS (Ad hoc Networks Scaling) de lIRTF
[IRT] ainsi que les tudes analytiques de cette problmatique.
2.4.2.1
Dfinitions du groupe ANS
Le passage lchelle (scalability) dun protocole de routage dans les rseaux

ad hoc peut tre dfini comme son aptitude conserver son efficacit lorsque
certains paramtres du rseau (nombre de nuds, charge de trafic, mobilit, . . .)
augmentent trs fortement. Cette dfinition permet seulement de caractriser le
passage lchelle dun protocole en termes qualitatifs. Pour permettre lvaluation voire la comparaison de diffrents algortihmes, le groupe ANS de lIRTF a
39
pour but dtablir un cadre gnral pour tudier le passage lchelle dans les
rseaux ad hoc. Les principaux objectifs sont de dfinir les mtriques ncessaires
lvaluation (appeles mtriques primaires), des critres (appels paramtres
indpendants) permettant de mesurer les performances et la stabilit des algorithmes considrs ainsi quune caractrisation du contexte de dploiement
(traduit par un vecteur de paramtres environnementaux) [ASH03].
les mtriques primaires reprennent les mesures externes de lefficacit
vues dans la partie 2.1 (dlai, dbit, . . .) et y rajoutent les ressources
matrielles (puissance de la batterie, mmoire, puissance de calcul).
les paramtres indpendants retenus sont le nombre de nuds, la densit de nuds, la charge de trafic ainsi que la mobilit.
les paramtres environnementaux dfinissent les conditions oprationnelles du rseau et regroupent, entre autres, laire de dploiement, la prsence dun rseau filaire, le modle de trafic et les caractristiques matrielles des nuds. Ils reprsentent lenvironnement dvaluation.
Lefficacit dun algorithme svanouit quand au moins une des mtriques
primaires devient arbitrairement grande lorsquun paramtre indpendant
tend vers linfini. La notion darbitrairement grande peut tre prcise selon
le type dalgorithme considr. Le groupe dfinit plusieurs types de passage
lchelle, toujours en fonction dun certain triplet (environnement, paramtre
indpendant, mtrique(s) primaire(s)) :
le passage lchelle absolu : lefficacit du protocole ne svanouit pas
lorsque le paramtre indpendant tend vers linfini. Le passage lchelle
absolu implique des rsultats asymptotiques, qui sont difficiles obtenir
dans de nombreux cas. Par exemple, un protocole de routage permet un
passage lchelle absolu si son trafic de contrle ne dpasse pas la charge
maximale supporte par le rseau lorsque le nombre de nuds tend vers
linfini.
le passage lchelle relatif : une mthode E1 passe mieux lchelle
1)
quune mthode E2 si limP I m(E
m(E2 ) = 0 o m(Ei ) est une mtrique
primaire de la mthode Ei et PI un paramtre indpendant. Cette notion
permet la comparaison de mthodes.
le passage lchelle optimal : une mthode E1 passe optimalement
lchelle si elle passe mieux lchelle que nimporte quelle mthode,
toujours par rapport un certain triplet (environnement, PI, MP). Le
passage lchelle optimal dfinit le meilleur passage lchelle possible,
tant donn (E, PI, MP).
le passage lchelle relatif faible : Etant donn un paramtre indpendant variant sur lintervalle [a,M], une mthode E1 passe faiblement
1 (M))m(E1 (a))
mieux lchelle quune mthode E2 si m(E
m(E2 (M))m(E2 (a)) < 1. Elle est intressante car certains paramtres indpendants ne peuvent dpasser une
valeur seuil. Dans ce cas, il est plus facile dtudier le passage lchelle
sur un intervalle fini.
40
Ces diffrents degrs de passage lchelle permettent de caractriser un protocole ou la comparaison de plusieurs protocoles selon les outils disponibles.
Lorsque lapproche formelle est possible, le passage lchelle absolu ou optimal
peut tre obtenu. Dans une tude par simulation, le passage lchelle relatif
faible sera plus appropri.
2.4.2.2
Travaux analytiques sur le passage lchelle
Gupta et Kumar ont effectu une tude thorique du passage lchelle qui
analyse le dbit de bout en bout de chaque nud L lorsque le nombre de nuds
N dans le rseau devient trs grand [GK00].
Cette tude considre deux modles de rseau : le modle arbitraire et le
modle alatoire.
le modle arbitraire considre que tous les nuds sont disposs sans restriction dans la surface du rseau (un disque). Il ny a aucune restriction
sur les puissances de transmission, le type de trafic ainsi que sur le protocole de routage.
le modle alatoire suppose une distribution uniforme des nuds dans
la surface du rseau, le type de trafic est alatoire et la puissance de
transmission est fixe afin dassurer la connectivit du rseau quand le
nombre de nuds tend vers linfini.
Dans les deux modles, tous les nuds sont considrs comme statiques. De plus,
les auteurs considrent deux modles de rception : le modle niveau protocole
et le modle niveau physique.
le modle niveau protocole suppose quune transmission choue si le rcepteur est dans les zones de couverture de deux metteurs.
le modle niveau physique est plus proche de la rception dans les rseaux
ad hoc rels : la transmission est russie si le rapport signal sur bruit et
interfrence dpasse un certain seuil.
Sur le modle de rception niveau protocole, le dbit L varie en ( 1N ) pour
le modle de rseau arbitraire et en ( 1
) pour le modle de rseau
N log(N )
alatoire. Avec le modle de rception niveau physique, en considrant que le

facteur dattnuation li la propagation > 2 , le dbit L varie en ( 11 )
N
pour le modle de rseau arbitraire et en ( 1N ) pour le modle alatoire. Cette

tude montre que le dbit de bout en bout de chaque nud L tend vers 0 lorsque
le nombre de nuds N tend vers linfini.
Quel que soit le protocole de routage utilis, les auteurs montrent que le
passage lchelle absolu par rapport taille du rseau nest pas possible.
Ltude de Graussgloser et Tse part des rsultats de ltude prcdente en
modifiant leur modle de rseau alatoire [GT02]. Le modle de rception au
niveau physique prend dsormais en compte le gain de traitement afin de rduire
les interfrences. Les positions des nuds suivent un processus ergodique stationnaire avec une distribution uniforme dans la surface du rseau alors que les
nuds taient statiques dans le modle de [GK00]. Enfin, les auteurs supposent
41
que les paires source-destination ne changent pas et des dlais de bout en bout
trs longs sont acceptables. A partir de ce modle plus favorable, lexistence
dune politique dordonnancement et de routage permettant de transmettre un
paquet jusqu sa destination en moins de deux sauts est dmontre. Cela permet au dbit de bout en bout de chaque nud de varier en (1)quand le nombre
de nuds N tend vers linfini.
Santivanez et al. [SMSR02] se sont intresss au cas particulier du passage
lchelle des protocoles de routage ad hoc. Pour raliser leur tude analytique,
ils dfinissent le critre de trafic de contrle complet (total overhead ) qui servira
de base lvaluation du passage lchelle de plusieurs protocoles de routage.
Un facteur de passage lchelle du rseau est propos, fonction de la charge
minimale du rseau et des paramtres considrs. Les paramtres de passage
lchelle considrs sont le nombre de nuds, la mobilit et le trafic.
Cette tude dmontre les difficults de passage lchelle quelle que soit la
catgorie de routage (ractif, proactif ou hybride).
2.5
42
Conclusion
Les rseaux ad hoc possdent des contraintes fortes (bande passante et ressource matrielles limites, dynamisme de la topologie) qui dcoulent de leur
architecture distribue ainsi que des mthodes daccs utilises. Ces contraintes
particulires ont ncessit la mise au point de protocoles de routage ad hoc
ddis. Au vu des valuations menes par diffrentes quipes, les protocoles de
1re gnration AODV et DSR offrent de trs bonnes performances, en ce qui
concernent le dbit et le dlai de bout en bout, sur des rseaux de petite taille
(de lordre de la centaine de nuds) et des charges de rseau faibles. Cependant,
si la taille du rseau est importante, DSR et AODV voient leurs performances
dcroitre trs rapidement, en particulier pour DSR. Nous avons explicit leur
difficult de passage lchelle par rapport la taille du rseau et la charge
par simulation : elle provient essentiellement de leur mcanisme dacquisition de
routes car il est bas sur linondation du rseau avec des paquets de contrle. Les
tudes analytiques menes sur la problmatique du passage lchelle montrent
galement les limitations des protocoles de 1re gnration.
Nous verrons dans le chapitre suivant les solutions qui peuvent tre envisages pour amliorer ces performances et permettre le passage lchelle des
protocoles de routage ad hoc.
Chapitre 3
Mthodes dadaptation dans

les rseaux ad hoc
Sommaire
3.1
3.2
3.3
3.4
3.5
3.6
Notions dadaptation . . . . . . . . . . . . .
Adaptation la mobilit . . . . . . . . . . .
3.2.1 Mtriques de mobilit . . . . . . . . . . . .
3.2.2 Choix dune mtrique de mobilit . . . . . .
Routage adapt la taille du rseau . . .
3.3.1 C-DSR . . . . . . . . . . . . . . . . . . . . .
3.3.2 Protocoles de routage hybrides . . . . . . .
3.3.3 Routage bas sur la position . . . . . . . .
3.3.4 Protocoles proactifs . . . . . . . . . . . . .
3.3.5 Connected Dominating Sets . . . . . . . .
Mthodes de clustering . . . . . . . . . . .
3.4.1 Critre dlection des Cluster Head . . . . .
3.4.2 Taille des clusters . . . . . . . . . . . . . . .
3.4.3 Contrle du nombre de Cluster Head . . .
3.4.4 Routage . . . . . . . . . . . . . . . . . . . .
Mthode dadaptation du routage . . . . .
3.5.1 Approche propose . . . . . . . . . . . . . .
3.5.2 Mtriques dadaptation . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
45
45
48
49
49
51
53
56
58
61
62
67
68
69
71
71
72
77
Dans le chapitre 2, nous avons vu que les protocoles de routage de premire gnration comme AODV et DSR ont des difficults pour maintenir leurs
performances lorsque les conditions du rseau changent.
Dans ce chapitre, nous nous intressons aux moyens qui permettent aux
protocoles de routage de sadapter aux changements de rseau afin damliorer
43
CHAPITRE 3. MTHODES DADAPTATION DANS LES RSEAUX AD HOC44

leurs performances. Parmi les dynamiques du rseau, la mobilit des nuds et la
taille du rseau influencent directement les performances des protocoles. Aprs
avoir caractris ladaptation dans les rseaux ad hoc dans la partie 3.1, nous
prsenterons les mcanismes de base qui permettent de sadapter par rapport
la mobilit du rseau dans la partie 3.2. Nous verrons ensuite les solutions de
2me gnration proposes pour permettre le passage lchelle par rapport
la taille du rseau dans la partie 3.3. Parmi celles-ci, les mthodes de clustering
seront plus particulirement analyses dans la partie 3.4. Nous prsenterons
alors notre mthode dadaptation du routage dans la partie 3.5.
3.1
Notions dadaptation
Nous pouvons distinguer deux types dadaptation dun protocole dans les
rseaux ad hoc :
adaptation aux conditions du rseau : un protocole est choisi car ses caractristiques conviennent lapplication choisie. Par exemple, un protocole
proactif sera efficace dans des rseaux de grande taille et mobilit faible.
auto-adaptation aux conditions du rseau : un protocole dtecte les conditions du rseau et ajuste son comportement selon elles.
Quel que soit le type dadaptation envisage, elle seffectue par rapport un ou
plusieurs paramtres du rseau. Les paramtres dadaptation les plus courants
sont :
la qualit du lien : Lin et al. proposent dans [LKL05] dadapter la
transmission des donnes et le routage selon les conditions du canal. Ils
utilisent un codage canal adaptatif et une technique de modulation qui
permettent aux utilisateurs de changer dynamiquement leur dbit de donnes en ajustant le niveau de protection aux erreurs. La qualit du lien est
estime grce au rapport signal--bruit mesur sur des symboles pilotes.
Quand le lien est de bonne qualit, lmetteur utilise une modulation avec
un plus grand nombre de bits (par ex, 16QAM) et un taux de correction
derreurs plus lev afin de maximiser le dbit sur le lien. Si on dtecte
un lien de faible qualit, lmetteur emploie un nombre de bits plus petit
pour moduler le signal (par ex, BPSK) et un taux de correction derreurs
plus faible pour assurer la transmission avec un dbit faible. La qualit
de lien permet aussi de dclencher des mcanismes de recouvrement de
route (global ou local) lorsque le dbit disponible ne satisfait les besoins
en bande passante.
la mobilit : de nombreuses mtriques permettant destimer la mobilit
des nuds ont t proposes. La dfinition donne la mobilit dpend de
la couche dutilisation (routage, MAC, . . .). Nous tudierons les mtriques
de mobilit et leurs applications dans la partie 3.2.
la taille du rseau et la densit de nuds : la densit de nuds et le
nombre de nuds dans le rseau sont deux notions diffrentes mais sont
souvent considres en mme temps. La densit dcrit la concentration des
nuds dans une aire donne (information locale) tandis que le nombre de

nuds dans le rseau est une mesure globale. De nombreuses solutions
ont t proposes pour permettre le passage lchelle des protocoles de
routage par rapport ces paramtres :
les architectures hybrides (C-DSR)
les protocoles hybrides (ZRP, IZR)
les protocoles proactifs (TBRPF, OLSR)
les protocoles bass sur la position des nuds
les protocoles bass sur des backbones virtuels (Connected Dominating
Sets, Clustering)
Nous dtaillerons ces diffrentes approches dans les parties 3.3 et 3.4.
3.2
Adaptation la mobilit
La mobilit des nuds peut tre dfinie et calcule de diffrentes manires.

Nous prsentons dans cette partie les principales mtriques de mobilit et leurs
utilisations.
3.2.1
Mtriques de mobilit
Vitesse relative
Johansson et al. prsentent une mtrique de mobilit base sur la vitesse
relative entre les nuds[JLH+ 99]. Soit l(x, t) la position du nud x
linstant t, la vitesse relative entre 2 nuds x et y linstant t est dfinie
comme :
v(x, y, t) =
d(l(x, t) l(y, t))

dt
La mesure de mobilit entre deux nuds est alors dfinie comme la vitesse
relative moyenne entre x et y sur la priode T .
Z
1
Mxy =
| v(x, y, t) | dt
T t0 tt0 +T
Chaque nud doit connaitre sa position via un mcanisme de localisation
comme le GPS. Lunit mobile doit obtenir priodiquement la position des
autres nuds pour pouvoir calculer la mtrique de mobilit. Une mesure
de mobilit base sur la vitesse relative est difficile calculer dans un
dploiement rel du protocole car tous les nuds doivent possder un
mcanisme de localisation.
Link change rate
Boleng utilise la frquence de changements de liens pour valuer la mobilit
[Bol01]. Le calcul de cette mtrique est simple et totalement distribu.
Diffrents critres de performances comme le dlai de bout en bout et
le pdr sont tudis en fonction de la frquence de changements de liens.
Lauteur montre que la frquence de changements de liens est lie la

performance relative dun protocole de routage : si la frquence est leve,
le protocole sera moins efficace. Cependant, la frquence de changements
de liens ne caractrise pas prcisment la performance du protocole.
Link duration
Boleng, Navidi and Camp visent amliorer la frquence de changements
de liens en prenant en compte la dure de vie des liens. Ils proposent la
dure moyenne de lien comme mtrique de mobilit [JWT02]. Lapproche
consiste pondrer le nombre de changements de liens par la stabilit des
liens. La dure dun lien est dfinie comme la priode pendant laquelle 2
nuds sont porte radio lun de lautre. Chaque unit mobile peut calculer sa dure moyenne de lien en moyennant les dures de lien constates
avec ses voisins.
La dure moyenne de lien permet de fournir une mtrique locale de la
mobilit. Elle est facilement calculable si les nuds changent priodiquement des messages avec leurs voisins (par exemple, des messages Hello).
Les auteurs prouvent que leur mtrique capture la mobilit des nuds
en observant les critres de performances usuels en fonction de la dure
moyenne de lien : le pdr augmente avec la dure de lien, le dlai de bout
en bout et le trafic de contrle diminuent lorsque la dure de lien augmente. Ces rsultats sont conformes aux comportements que lon attend
des critres de performances en fonction de la mobilit.
Eloignement
La proposition de Kwak, Song et Miller repose sur une fonction dloignement[KSM03].
Lloignement entre les nuds i et j est dfini comme :
Rij (t) = F (dij (t))
o F est une fonction de la distance sparant i et j, dij (t). Plusieurs
conditions sur F doivent tre runies : F doit tre croissante, borne et
plus sensible au mouvement lorsque lloignement est proche du rayon
de transmission. Les auteurs utilisent une fonction F rpondant leurs
critres mais nimporte quelle autre fonction F peut tre utilise pour
dfinir lloignement. Cette libert dans le choix de F rend la mesure de
mobilit adaptable selon lapplication choisie.
La mesure de la mobilit des autres nuds vue par le nud i, Mi (t), est
dfinie par :
Mi (t) =
N 1
1 X d
| F (dij (t)) |
N 1 j=0 dt
o N est le nombre de nuds. La mesure de mobilit globale est alors

calcule comme :
N 1
1 X
M (t) =
Mi (t)
N i=0

La mesure de mobilit globale est value sur des scnarii obtenus via
diffrents modles de mobilit comme Random Waypoint ou RPGM. Les
rsultats de simulation montrent une relation linaire entre la mesure de
mobilit globale et la frquence de changements de liens.
Predicted link status
Jiang et al. proposent de prdire le statut du lien (disponible ou non)
pour une certaine priode de temps Tp . L(Tp ) est la probabilit que le
lien soit disponible pendant la priode Tp . Les auteurs supposent que les
mouvements des nuds peuvent tre diviss en diffrentes poques. Durant chacune de ces poques, la vitesse et la direction de dplacement du
nud sont supposes constantes. Pour simplifier le calcul de la probabilit
L(Tp ), les auteurs supposent que la distribution des poques suit une loi
exponentielle. L(Tp ) peut tre calcul en dploiement rel si chaque nud
mesure la priode pendant laquelle le lien est disponible.
Les auteurs utilisent la prdiction du statut du lien pour amliorer la
gestion du cache DSR. Lorsquun nud reoit un paquet, il doit prdire
Tp et estimer L(Tp ) pour le lien entre lui et lmetteur du paquet. Les
paramtres estims doivent alors tre propags au prochain saut. Pour
cela, un champ dun octet est ajout len-tte DSR. Il indique jusqu
quand le lien sera disponible (heure courante + L(Tp ).Tp ). La dure de vie
du lien dans le cache est alors gale L(Tp ).Tp . Ainsi, si le mme lien est
stock dans plusieurs nuds, il sera supprim simultanment des caches
des nuds concerns. De cette manire, les caches de lien contiennent
moins dinformations primes. Lutilisation de la prdiction de lien dans
la gestion du cache amliore notamment les performances du DSR en
termes de trafic de contrle et de dlai de bout en bout.
Diffrentiel de routes
Hu et Johnson utilisent une nouvelle mtrique qui dpend du protocole
DSR[HJ00]. Les auteurs calculent le nombre de changements de route entre
les units mobiles pour valuer la mobilit globale du rseau. Le nombre de
changements de routes entre deux nuds est le nombre minimum de fois
o les deux stations devraient changer de route afin que leur connectivit
soit toujours assure.
VPR (Virtual Paths Routing)
Altahi et Richard utilisent la table de routage pour valuer la mobilit[AR04].
Une entre est supprime du cache lorsquun chemin est rompu. La rupture
dun chemin rvle la mobilit de certains nuds. Les auteurs proposent
de comptabiliser priodiquement le nombre dentres supprimes du cache
pour calculer leur mtrique de mobilit. N est le nombre dentres supprimes du cache depuis le dernier calcul. C est le nombre dentres dans le
cache. Lindicateur de mobilit M est alors obtenu :
M=
N
C

Les auteurs utilisent cette mtrique pour ajuster la dure de vie des entres de la table de routage. Si un nud a supprim au moins une entre
depuis le dernier calcul de la mtrique, il doit diminuer la dure de vie des
entres de sa table de routage. Lajustement de la dure de vie des entres
est proportionnel la mtrique de mobilit M . Si aucune entre na t
supprime depuis le dernier ajustement, le nud augmente la dure de vie
des entres de son cache.
3.2.2
Choix dune mtrique de mobilit
Les mtriques de mobilit peuvent tre utilises pour :

le choix des chemins : dans la plupart des protocoles de routage ad hoc,
le critre de slection des routes est le nombre de sauts (DSR, AODV,
. . .). Cependant, choisir la route la plus stable en terme de mobilit peut
accrotre la dure de vie du chemin. Des routes plus stables permettent
dutiliser moins souvent les procdures de dcouverte de routes.
la gestion du cache : lalgorithme de gestion de la table de routage a
une grande importance sur les performances des protocoles ractifs comme
DSR (voir partie 1.3.2.4). Les entres primes entrainent un trafic inutile
et retardent le dclenchement de la dcouverte de routes. Ajuster la dure
de vie des entres du cache en fonction de la mobilit permet de damliorer
la fraicheur des routes utilises.
la mise en place de clusters : les algorithmes de clustering visent
mettre en place une architecture virtuelle. La stabilit de cette architecture constitue un critre de performance important. Certains algorithmes
utilisent des critres de mobilit comme le statut des liens pour mettre en
place larchitecture (partie 3.4.1.3).
Les dfinitions de la mobilit sont trs diffrentes selon lutilisation vise. Certaines sappuient sur les caractristiques relatives dun mobile par rapport aux
autres (vitesse relative, loignement). Du point de vue du routage, les mtriques
bases sur la notion de lien semblent les plus intressantes. En effet, le dplacement ou la panne dun mobile ont un effet quivalent pour les nuds voisins :
la rupture dun lien.
Certaines mtriques de mobilit sont calcules grce des missions priodiques de chaque nud (Link change rate, Link duration, . . .). Cette mthode
permet chaque nud davoir une estimation de sa mtrique rgulirement.
Ainsi, la mesure de la mobilit est plus prcise. Cependant, lmission priodique de paquets gnre un surplus de trafic de contrle quand elle nest pas
ncessaire au fonctionnement dun protocole. Les protocoles AODV et OLSR
peuvent calculer les mtriques bases sur des changes priodiques : leur fonctionnement requiert un change priodique de messages Hello. Ces messages
servent sassurer de la qualit et de la symtrie des liens.
En revanche, aucun change priodique nest intgr au protocole DSR. Les
informations de routage sont alors utilises pour avoir une estimation de la
mobilit. Le trafic de contrle peut tre gnr par la mobilit des nuds. Par

exemple, lenvoi dun paquet Route Error indique la rupture du chemin. Les
ruptures de lien se rpercutent sur la table de routage. La gestion de la table de
routage permet alors de mesurer la mobilit comme dans le VPR.
Le choix dune mtrique de mobilit dpend essentiellement des informations
disponibles au niveau routage. Si lchange priodique de paquets est intgr au
fonctionnement du protocole, il permet de calculer de nombreuses mtriques.
Sinon, les informations de routage comme le trafic de contrle ou la gestion de
la table permettent davoir une estimation de la mobilit sans gnrer de trafic
de contrle supplmentaire.
3.3
Routage adapt la taille du rseau
Pour les rseaux de grande taille, une simple adaptation des variables du
protocole de routage nest pas suffisante. En effet, les protocoles de premire
gnration utilisent des procdures bases sur linondation du rseau et ne sont
pas adapts aux rseaux de grande taille. Ainsi, des solutions ddies ont t
proposes pour rpondre au passage lchelle du routage dans les rseaux ad
hoc. Ces solutions permettent aussi un meilleur passage lchelle lorsque la
charge de trafic augmente. Nous prsentons dans cette partie les principales
solutions proposes par la communaut scientifique.
3.3.1
C-DSR
Le protocole C-DSR (Cellular DSR) est une extension du protocole DSR

[JHP+ 03]. Il permet le passage lchelle du DSR dans le cas des rseaux maills
hybrides. Le dploiement de C-DSR sappuie sur une architecture appele Ad
Hoc City et compose de :
stations de base fixes : chaque station de base gre les routeurs mobiles
prsents dans sa cellule. La taille de la cellule nest pas dtermine par la
porte de transmission mais par le nombre de sauts partir de la station
de base (paramtre fixe pour lensemble du rseau not h).
routeurs sans fil mobiles : ils sont implants sur des vhicules. Les routeurs
mobiles grent les utilisateurs mobiles porte radio.
utilisateurs mobiles : les utilisateurs mobiles utilisant le rseau ne participent pas au relayage des donnes. Lassociation entre les utilisateurs
mobiles et les routeurs mobiles nest pas considre par la proposition.
Les paquets provenant dun utilisateur mobile sont achemins travers les routeurs mobiles jusqu la station de base la plus proche en nombre de sauts de
la source. La station de base peut alors router les paquets vers Internet ou vers
la station de base la plus proche de la destination. Si la source et la destination
sont toutes les deux dans le rseau Ad Hoc City, les paquets peuvent tre achemins par les routeurs mobiles sans passer par les stations de base si le chemin
est plus court.
Localisation des routeurs mobiles

Une des stations de base, appele registre de localisation mobile, conserve
une base centrale de localisation des routeurs mobiles. Chaque routeur
est localis grce la station de base laquelle il est associ. Chaque
station de base mmorise les informations de localisation reues dans un
cache de localisation pour rduire le nombre de requtes vers le registre
de localisation.
La position des routeurs mobiles est obtenue grce la surveillance des
paquets de contrle envoys lors des procdures de dcouverte et de maintenance de route de C-DSR. Lorsquune station de base reoit une requte
de route ou une rponse de route provenant dun routeur mobile, elle la relaie au registre de localisation pour mettre jour la base centrale. La route
DSR contenue dans le paquet permet aussi un enregistrement implicite des
nuds intermdiaires. Si un routeur mobile ncessaire la transmission
de paquets est absent de la base centrale, le registre de localisation initie une dcouverte de route partir dune ou plusieurs stations de base
(mcanismes de paging).
Dcouverte de route
Lorsquun routeur mobile dsire mettre des donnes, il cherche une route
vers la destination ou vers une station de base dans sa table de routage.
Une route vers une station de base est choisie si le nombre de sauts entre
le routeur et la station de base est infrieur ou gal h (taille dune
cellule). Sinon, si le routeur ne dispose daucune route vers la destination,
il dclenche une dcouverte de routes DSR en diffusant une requte de
route porte limite (TTL gal h) :
lorsquune station de base reoit la requte de route :
1. elle rpond la source en utilisant la route construite lors du relayage de la requte.
2. elle relaie la requte jusquau registre de localisation pour lenregistrement de la source.
si la destination recherche reoit la requte de route, elle renvoie une
rponse de route comme dans le protocole DSR de base.
Lorsque le routeur souhaite mettre des donnes, il choisit entre les routes
reues en rponse (provenant de la (ou des) station(s) de base et/ou de la
destination) la meilleure en terme de nombre de sauts.
Gestion des paquets de donnes niveau station de base
Lorsquune station de base reoit un paquet de donnes, elle cherche une
route vers la destination dans son cache de localisation. Si une telle route
existe, elle supprime la route prsente dans len-tte et relaie les donnes
jusqu la station de base associe la destination. Sinon, elle mmorise
le paquet et fait une requte vers le registre de localisation. Le registre de
localisation rpond la station de base si lentre est prsente dans sa base
centrale. Sinon, il dclenche une dcouverte de route partir des stations
de base pour localiser la destination.

La solution C-DSR est propose dans un contexte de dploiement trs prcis.
Cette extension permet le passage lchelle du DSR mais ncessite la prsence
dune infrastructure fixe pour pouvoir fonctionner.
3.3.2
Protocoles de routage hybrides
3.3.2.1
ZRP
Le protocole ZRP (Zone Routing Protocol) est un protocole de routage hybride combinant des mcanismes ractifs et proactifs [Haa97, HP98, HPS03]. Il
a t mis au point par lquipe de Haas de luniversit de Cornell. Chaque nud
possde une zone de routage, dlimite par un nombre de sauts partir du nud
considr (rayon de la zone). La zone de routage regroupe tous les nuds dont
la distance en nombre de sauts est infrieure ou gale au rayon de la zone. Le
fonctionnement de ZRP sappuie sur trois protocoles :
le protocole IARP (Intra-Zone Routing Protocol) : cest un protocole
proactif qui permet chaque nud de connaitre la topologie de sa zone
de routage (comme OLSR par exemple).
le protocole IERP (Inter-Zone Routing Protocol) : cest un protocole ractif pour dcouvrir les routes vers les nuds externes la zone de routage
(comme DSR ou AODV).
le protocole BRP (Bordercast Resolution Protocol) : il est utilis en association avec le protocole IERP. Au lieu dutiliser la diffusion classique,
ce protocole permet de ne relayer la requte de route dun nud quaux
nuds priphriques de sa zone (connus grce lIARP). Les nuds priphriques de la zone sont les nuds situs une distance en nombre de
sauts gale au rayon de la zone.
Dcouverte de route
Lorsquun nud a un paquet mettre, il consulte les tables de routage
de ses protocoles IARP et IERP. Sil ne trouve pas de route vers la destination, il va dclencher une dcouverte de route IERP et mettre une
requte de route.
La requte est relaye jusquaux nuds priphriques (grce au protocole
BRP) qui vont vrifier si la destination est dans leur zone ou sil possde
une route valide :
si un nud priphrique possde une route, il renvoie une rponse de
route la source.
sinon, il va relayer la requte aux nuds priphriques de sa zone.
ZRP peut tre considr comme un cadre de routage modulaire :
un protocole de routage proactif tat de liens peut tre adapt pour tre
utilis comme IARP.
nimporte quel protocole ractif peut tre utilis comme IERP.
seul le protocole BRP est interne ZRP
Les performances du protocole ZRP sont dpendantes de la taille de la zone de
routage. Dans ZRP, tous les nuds du rseau doivent possder le mme rayon de

zone. Un petit rayon de zone sera adapt aux rseaux trs mobiles tandis quun
rayon plus grand conviendra aux rseaux peu mobiles. Le besoin dadaptation du
rayon de la zone selon les conditions de rseaux amena lquipe dHaas proposer
un protocole adaptatif appel IZR (Independent Zone Routing) [SPH04].
3.3.2.2
IZR
Le protocole IZR (Independent Zone Routing) est une extension du protocole ZRP. Il permet ladaptation du rayon de la zone de routage de manire
distribue. Chaque nud dcide individuellement du rayon de sa zone de routage. Les nuds du rseau peuvent donc avoir des rayons de zone diffrents,
contrairement ZRP. Lide dIZR est dadapter le rayon de la zone de routage
daprs les conditions de mobilit qui peuvent varier en fonction du temps et
selon les rgions du rseau.
Une zone dmission (Send Zone) est dfinie pour chaque nud. Elle correspond tous les nuds auxquels le nud doit transmettre des informations
de routage proactives. Cette zone a t introduite pour que les nuds puissent
avoir des rayons diffrents (dans ZRP, zone dmission et zone de routage sont
confondues).
Les mcanismes de routage dIZR sont similaires ceux de ZRP. Ils ont t
adapts afin de prendre en compte des tailles de zone de routage diffrentes.
IZR adapte le rayon de la zone de routage en combinant deux algorithmes :
Min-Searching : La taille de la zone de routage est itrativement incrmente ou dcrmente jusqu ce quun minimum local en terme de
trafic de contrle soit atteint. Le trafic de contrle passant par le nud
est mesur sur un certain intervalle de temps. Lalgorithme Min-Searching
converge lorsque C(R) < C(R1) et C(R) < C(R+1) o C(R) reprsente
le trafic de contrle mesur pour un rayon de zone gal R sauts.
Estimation Adaptative du Trafic : lorsque le rayon de zone est plus
grand que le rayon optimal, le trafic de contrle est essentiellement constitu de paquets proactifs. Si le rayon de zone est infrieur au rayon optimal,
le trafic sera principalement constitu de requtes ractives. Lalgorithme
traf ic r
eactif
dEstimation Adaptative du Trafic compare le rapport traf
ic proactif reu
sur un intervalle de temps avec un seuil de rfrence :
traf ic r
eactif
traf
ic proactif > seuil : le rayon de zone est incrment pour rduire la
prdominance du trafic ractif.
traf ic r
eactif
traf
ic proactif < seuil : le rayon de zone est dcrment pour diminuer
la prdominance du trafic proactif.
Initialement, lalgorithme Min-Searching est appliqu en partant dun rayon
de zone gal 1. Une fois quun minimum du trafic de contrle est atteint,
traf ic r
eactif
le seuil de rfrence est initialis avec le rapport traf
ic proactif correspondant.
LEstimation Adaptative du Trafic va alors ajuster dynamiquement le rayon de
la zone en se basant sur le seuilde rfrence dtermin au cours de lexcution
de lalgorithme Min-Searching.
Lextension IZR apporte lauto-adaptation au protocole ZRP. Ladaptation
de la zone de routage se fait de manire distribue et se base sur la quantit de

trafic de contrle ractif et proactif reu. Cependant, lestimation du rayon de
zone optimal est complexe.
3.3.3
Routage bas sur la position
Cette classe de protocoles utilise la position gographique des nuds pour

prendre des dcisions de routage. Cela suppose que chaque nud peut dterminer individuellement sa propre position. Lun des mcanismes les plus utiliss
pour obtenir sa position est le GPS (Global Positioning System) [Get93]. La
dcision de routage chaque nud est base sur les positions de la destinations et des voisins. Typiquement, le paquet est relay vers le voisin qui est le
plus proche (en distance) de la destination. Chaque nud informe ses voisins
de sa propre position en mettant priodiquement des balises. La position de la
destination peut tre obtenue grce un service de localisation.
Les algorithmes de routage bass sur la position ne requiert pas de mcanismes de dcouverte et de maintenance de route. Les nuds nont pas besoin
de stocker de table de routage ni de transmettre des paquets pour maintenir
de telles tables. Cette caractristique est trs intressante dans les rseaux
trs forte mobilit o les informations de routage primes rduisent les performances. De plus, le routage bas sur la position permet de distribuer facilement des paquets tous les nuds dune zone gographique donne (geocasting)
[NI97].
Le routage bas sur la position peut tre divis en deux services : le service
de localisation et le routage des paquets de donnes.
Service de localisation
Il consiste faire correspondre lidentifiant du nud (gnralement ladresse
IP) avec sa position gographique. Il est utilis par la source de paquets de
donnes afin de localiser la destination. Les nuds intermdiaires peuvent
avoir recours ce mcanisme pour estimer plus prcisment la position de
la destination. Un service de localisation peut tre caractris par :
son mode de mise jour : ractif, proactif ou hybride.
sa structure : plate ou hirarchique.
son type de stockage des positions : certains-pour-certains (some-forsome), certains-pour-tous (some-for-all ), tous-pour-certains (all-for-some)
ou tous-pour-tous (all-for-all ).
Routage
La localisation de la destination est incluse dans len-tte de chacun des paquets de donnes pour permettre leur acheminement. Si un nud possde
une estimation plus prcise de la position de la destination, il peut choisir
de mettre jour la localisation prsente dans len-tte avant de le relayer.
Les algorithmes de routage peuvent tre diviss en trois catgories :
greedy routing : le nud relaie le paquet son voisin le plus proche
de la destination.
inondation dirige (directed flooding) : le nud relaie le paquet
plusieurs de ses voisins les plus proches de la destination

hirarchique : une hirarchie est mise en place pour permettre le passage lchelle. Diffrents algorithmes de routages, bass ou non sur la
position, peuvent tre utiliss selon le niveau dans la hirarchie.
3.3.3.1
Service de localisation
Ractif
Les service de localisation ractifs, comme RLS (Reactive Location Service), sont bass sur linondation du rseau. Lorsquun nud veut localiser une destination, il diffuse une requte de localisation dans le rseau.
La porte de la requte peut tre limite et incrmente progressivement
selon les algorithmes (de type expanding ring search). Les services de localisation ractifs ont les mmes problmes de passage lchelle que les
protocoles ractifs cause du cot li linondation du rseau. Ce type
dalgorithme possde une structure plate et un stockage des positions de
type tous-pour-certains : tous les nuds possdent les positions des units
mobiles pour lesquelles ils ont fait des recherches.
Proactif
Basagni et al. proposent dans [BCSW98] un mcanisme proactif la structure plate nomm DREAM (Distance Routing Effect Algorithm for Mobility). Ils utilisent une approche de stockage des positions de type touspour-tous i.e chaque nud conserve la localisation de tous les autres nuds
du rseau. Chaque nud peut ajuster :
la frquence laquelle il met des mises jour sur sa position : la vitesse
de dplacement peut tre calcule car le nud connait ses positions
successives. Si sa vitesse de dplacement augmente, le nud envoie des
mises jour plus rapproches.
la porte (en nombre de sauts) de ses mises jour : les mises jour
porte maximale sont envoyes moins frquemment que les mises jour
vers les voisins. Les nuds loigns ont une estimation moins prcise de
la position du nud que ses voisins. Lorsque quun paquet est relay
vers une destination, les nuds intermdiaires ont une localisation plus
prcise de la destination et peuvent mettre jour len-tte.
DREAM permet un meilleur passage lchelle que les services ractifs.
Cependant, le rseau est inond lorsquun nud informe les units
mobiles loignes de sa position.
Hybride
Li et al. ont tudi un service hirarchique appel GLS (Grid Location Service) [LJC+ 00]. Laire de rseau est divise en une hirarchie de carrs :
chaque carr dordre N contient quatre carrs dordre (N-1). Un carr
dordre 1 possde une taille comparable la porte radio dun nud.
Chaque nud possde des informations de localisation sur certains autres
nuds : lapproche est tous-pour-certains. Chaque nud conserve les positions de tous les nuds qui sont dans le mme carr dordre 1. La table

Nom
Mise jour
Architecture
Stockage des positions
RLS
Ractive
Plate
tous-pour-certains
DREAM
Proactive
Plate
tous-pour-tous
GLS
Hybride
Hirarchique
tous-pour-certains
Tab. 3.1 Caractristiques des services de localisation tudis

est construite grce des missions priodiques de mise jour limites
la taille du carr dordre 1.
Chaque unit mobile slectionne les nuds qui vont possder sa localisation (ses serveurs de localisation) en se basant sur lidentifiant. Il envoie sa
position au nud ayant lidentifiant (suprieur au sien) le plus faible dans
chacun des trois autres carrs dordre 1 qui font partie du mme carr
dordre 2. Le mcanisme est rpt aux niveaux suprieurs : les nuds
ayant lidentifiant (suprieur au sien) le plus faible dans chacun des trois
autres carrs dordre 2 environnants sont choisis pour conserver la position
du nud. Le processus sachve lorsque tout le rseau est couvert.
Lorsquun nud souhaite connaitre la position dune destination donne, il envoie une requte, parmi les nuds dont il connait la localisation, au nud qui
possde lidentifiant le plus proche du nud recherch. Si le nud ne connait pas
la position du nud recherch, il connaitra un nud possdant un identifiant
plus proche de la destination localiser et lui relayera la requte. La recherche
se termine lorsque la localisation du nud est dcouverte.
Un nud na pas besoin de connaitre ladresse de ses serveurs de localisation. Linformation de position est relaye aux nuds ayant lidentifiant le plus
proche par un mcanisme similaire la recherche de position. Linformation de
localisation est distribue dans le rseau car chaque nud possde ses propres
serveurs de localisation. GLS passe mieux lchelle que DREAM grce la
distribution des informations de position et lutilisation dune hirarchie.
Les caractristiques des services de localisation prsents dans cette partie
sont rsumes dans le tableau 3.1.
3.3.3.2
Routage des donnes
Greedy routing
Lorsqun nud reoit un paquet de donnes, il le relaie un de ses voisins
( un saut) plus proche de la destination. Plusieurs voisins peuvent tre
plus proches de la destination que le nud actuel. Ds lors, diffrentes
stratgies existent pour choisir le prochain saut :
relayer le paquet au nud qui est le plus proche en terme de distance de
la destination. Cette technique minimise le nombre de sauts mais gnre
des chemins plus fragiles : le rayon de transmission entre les nuds est
lev ce qui augmente les risques de collision.
parmi les nuds plus proches de la destination, on choisit le nud tant
le plus proche de lmetteur. Les transmissions entre nuds se font sur

des portes courtes ce qui rduit les risques de collision. En contrepartie,
le nombre de sauts ncessaire au relayage est plus grand.
Inondation dirige
Lorsquun nud reoit un paquet de donnes, il le relaie tous ses voisins
qui sont situs dans la mme direction que la destination. Linondation
dirige est plus robuste que le greedy routing mais son cot en trafic de
contrle est plus lev (problme de passage lchelle). Cest le type de
routage utilis dans DREAM.
Routage hirarchique
Les protocoles hirarchiques utilisent une combinaison de protocoles selon le niveau. Gnralement, un protocole traditionnel (par exemple, un
protocole proactif vecteur de distance) est employ au niveau local (le
niveau le plus faible dans la hirarchie). Un protocole bas sur la position
est alors utilis pour le routage de niveau suprieur (par exemple, une
mthode de greedy routing).
3.3.4
Protocoles proactifs
3.3.4.1
TBRPF
Le protocole TBRPF (Topology Dissemination Based on Reverse-Path Forwarding) [OTL04] est un protocole proactif tat de liens. Il utilise le routage
par saut en choisissant le chemin le plus court jusqu la destination. Chaque
nud construit un arbre en se basant sur des informations de topologie partielles
et en utilisant une variante de lalgorithme de Dijkstra. Cet arbre contient les
plus courts chemins vers tous les nuds atteignables.
TBRPF repose sur deux mcanismes :
Dcouverte des voisins
Les nuds changent priodiquement des messages Hello diffrentiels
avec leurs voisins. Un message Hello ne contient que les changements dtat
de liens qui se sont produits depuis lmission du message Hello prcdent
pour rduire la taille des informations changes.
Dcouverte de la topologie
Les nuds changent priodiquement une partie de leur arbre de topologie
appele sous-arbre report avec leurs voisins. Les changements dans le
sous-arbre report (suppression ou ajout de liens) sont propags grce
aux messages de topologie diffrentiels. Les messages de topologie diffrentiels peuvent tre inclus dans le mme paquet que le message Hello chang
lors de la dcouverte de voisins afin de rduire le trafic de contrle.
Pour calculer son sous-arbre report, chaque nud doit slectionner un ensemble
de nuds parmi ses voisins appel lensemble des nuds reports (reported
node set RN). Un nud M inclut un nud N dans son RN si le nud M estime
quun de ses voisins va le choisir comme le prochain saut dans le plus court
chemin vers N. Pour faire cette estimation, le nud M calcule les plus courts

chemins vers ses voisins jusqu deux sauts grce aux messages Hello changs
lors de la dcouverte de voisins. Le sous-arbre report est lensemble des nuds
joignables partir des nuds inclus dans RN : il contient tous les liens tels que
lune des extrmits appartienne RN.
3.3.4.2
OLSR
Le protocole OLSR (Optimized Link State Routing Protocol) [CJ03] est un

protocole de routage proactif tat de liens. Il a t propos par lINRIA dans
le cadre du projet Hipercom. OLSR constitue une optimisation des protocoles
tat de liens traditionnels :
il permet de rduire le trafic de contrle ncessaire lchange dinformations sur ltat des liens. Le trafic de contrle, habituellement diffus dans
les protocoles tat de liens, nest relay que par des nuds choisis, les
MPR (MultiPoint Relays ou relais multipoint).
La taille des messages de contrle est rduite car chaque nud dclare
uniquement les liens avec ses voisins layant choisi comme relais multipoint.
Chaque nud choisit ses relais multipoints parmi ses voisins un saut. Les liens
entre un nud et ses MPR doivent tre bidirectionnels. Lensemble des relais
multipoints dun nud lui permet de couvrir tous les voisins deux sauts. Les
MPR dun nud sont chargs de relayer ses paquets de contrle pour rduire le
nombre de retransmissions redondantes.
Tout comme TBRPF, le fonctionnement du protocole OLSR repose sur deux
mcanismes : la dtection des voisins et la dcouverte de topologie.
Dtection des voisins
Chaque nud diffuse priodiquement un message Hello dans son voisinage
un saut. Ce message contient la liste des voisins un saut et indique
lesquels font partie des relais multipoints du nud. Un champ du message
Hello nomm willingness exprime la volont du nud relayer du trafic
pour dautres nuds.
Chaque nud stocke les informations de voisinage reues dans une base
dinformation NIB (Neighborhood Information Base). Cette base contient
des informations sur :
les voisins un saut, leur willingness et ltat du lien : lien unidirectionnel, lien bidirectionnel, MPR (ce qui implique un lien bidirectionnel)
ou perdu
les voisins deux sauts : liens bidirectionnels entre les voisins un saut
et les voisins deux sauts.
les relais multipoints
les slecteurs de relais multipoint : tous les nuds qui lont slectionn
comme relais multipoint.
Chaque nud slectionne individuellement ses relais multipoints en se
basant sur les informations de la base NIB. Les paquets provenant des
slecteurs de relais multipoint sont retransmis lorsquils sont reus pour
la premire fois.

Dcouverte de topologie
Chaque nud qui a t choisi comme relais multipoint diffuse priodiquement un message TC (Topology Control ) dans lensemble du rseau. Ce
message indique les nuds ayant slectionn la source du message comme
relais multipoint. Les messages TC sont traits par tous les nuds mais
ne sont relays que par les relais multipoint afin de minimiser linondation
du rseau.
Chaque nud maintient une table de topologie TIB (Topology Information
Base) qui contient les informations topologiques du rseau obtenues grce
aux messages TC. Cette table mmorise pour chaque adresse destination
dans le rseau :
ladresse dun voisin un saut de la destination (gnralement un relais
multipoint de la destination)
un numro de squence
une dure de vie : lentre est supprime de la table lexpiration de la
dure de vie
Routage OLSR
OLSR sappuie sur un routage par saut. La table de routage est calcule
grce aux informations de voisinages et de topologies. Elle est mise jour
lorsque les informations de voisinage et de topologie sont modifies (ajout,
modification ou suppression dune entre des tables NIB ou TIB). Chaque
entre de la table de routage contient :
une adresse destination
ladresse du prochain saut pour atteindre la destination
la distance en nombre de sauts entre le nud et la destination
linterface par laquelle le prochain saut est accessible
La construction de la table de routage sappuie sur un algorithme de calcul
du plus court chemin (comme lalgorithme de Dijkstra). Lalgorithme de
calcul est appliqu sur lensemble :
des liens avec des voisins symtriques (lien bidirectionnel) un saut.
des liens (dest_addr, next_addr) contenus dans la table de topologie
et tels que dest_addr est ladresse dune destination et next_addr est
ladresse dun relais multipoint de la destination.
Le protocole OLSR convient aux rseaux denses avec un grand nombre de nuds
car le concept des relais multipoint fonctionne bien dans ces conditions de rseau.
3.3.5
Connected Dominating Sets
Un CDS (Connected Dominating Set) est un sous-ensemble des nuds du

rseau tel que tout nud du rseau appartient au CDS (nud dominant ) ou est
voisin dun nud appartenant au CDS (nud domin). Un k-CDS est un CDS
o les nuds domins se trouvent au plus k sauts dun nud dominant. Le but
des CDS est de former une architecture virtuelle (un backbone) pour faciliter
le routage et rduire les effets de linondation du rseau. Dterminer un CDS

minimal (MCDS) est un problme NP-complet. Les paramtres considrer
pour mettre en place un CDS sont la complexit en message et la stabilit par
rapport aux dplacements des nuds.
Il existe diffrentes techniques de construction de CDS. Wu et Lou fournissent une classification des algorithmes CDS utiliss pour le broadcast [WL03] :
construction globale
Ces algorithmes utilisent des informations provenant de tout le rseau.
Das, Sivakumar et Bhargavan proposent un algorithme global o les nuds
ont connaissance de toute la topologie [DSB97]. Le processus de construction colore en noir les membres du CDS (nuds dominants) et en gris les
nuds couverts (nuds domins). Initialement, tous les nuds sont colors en blanc. Le nud du rseau ayant le degr le plus grand est color
en noir et ses voisins sont colors en gris. Parmi les nuds colors en gris,
celui qui a le plus de voisins colors en blanc est choisi pour appartenir au
CDS : il est color en noir et ses voisins sont colors en gris. Le mcanisme
de slection se poursuit jusqu ce quil ny ait plus de nuds colors en
blanc. Cet algorithme peut tre implant de manire distribue. Une procdure dlection choisit le nud ayant le degr le plus grand comme racine
du CDS. Ce type dalgorithme ne peut pas tre maintenu localement. Tout
changement dans le CDS doit tre diffus dans tout le rseau.
construction quasi-globale
La construction du CDS est base sur des informations globales partielles.
Alzoubi, Wan et Frieder ont propos un algorithme de construction sappuyant sur un arbre de recouvrement [AWF02]. Larbre est mis en place
partir dune racine choisie par lection. Lide consiste slectionner lensemble des nuds dominants en parcourant larbre puis interconnecter
cet ensemble pour obtenir le CDS. La maintenance locale du CDS nest pas
possible car le dplacement des nuds peut dclencher la reconstruction
de larbre de recouvrement.
construction quasi-locale
Ces algorithmes utilisent principalement des informations locales.
Des informations globales partielles sont exploites de manire occasionnelle. Les algorithmes de clustering rentrent dans cette catgorie. Ils sont
dtaills dans la partie 3.4.
construction locale
Ces algorithmes utilisent seulement des informations locales pour mettre
en place le CDS. Les choix locaux ne se rpercutent pas sur le reste de
larchitecture.
Wu et Li ont propos une technique de marquage utilisant une construction locale [WL99]. Initialement, tous les nuds sont colors en blanc. Un
nud se colore en noir sil a au moins deux voisins qui ne sont pas directement connects. Les nuds colors en noir forment un ensemble dominant
connect. Cependant, le CDS peut comporter des redondances. Wu et Li
ont mis en place 2 rgles pour retirer les nuds redondants du CDS :
rgle 1 : un nud noir u devient blanc si un nud noir voisin v possde
un identifiant plus grand que u et que lensemble des voisins de u est

inclus dans lensemble des voisins de v. u est couvert par v.
rgle 2 : un nud noir u devient blanc sil existe 2 nuds connects v et
w qui possdent des identifiants plus grands que u et tels que les voisins
de u sont inclus dans lunion des voisins de v et w. u est couvert v et
w.
Les approches globales et quasi-globales permettent dobtenir des CDS proches
du CDS minimum. Cependant, la maintenance locale de larchitecture nest
pas possible : chaque changement dans le CDS doit tre diffus dans tout le
rseau. De plus, la complexit en message est fonction de la taille du rseau. Les
algorithmes globaux et quasi-globaux conviennent donc aux rseaux ayant une
mobilit faible. Le cot en trafic de contrle devient important si les nuds se
dplacent souvent.
Les algorithmes locaux et quasi-locaux construisent des CDS qui contiennent
plus de nuds redondants. Cependant, des mcanismes de suppression des
nuds redondants sont mis en place pour sapprocher du CDS minimum. De
plus, larchitecture peut tre maintenue localement ce qui rend ces algorithmes
plus robustes la mobilit. La complexit en message est indpendante de la
taille du rseau. Les algorithmes locaux et quasi-locaux sont donc les plus adapts aux rseaux ad hoc.
Les algorithmes de clustering construisent des CDS locaux ou quasi-locaux
en gnrant peu de trafic de contrle et nous les dtaillerons dans la partie
suivante.
Fig. 3.1 Exemple de formation de clusters
3.4
Mthodes de clustering
Dans la partie prcdente, nous avons vu de nombreuses solutions qui permettent le passage lchelle. Parmi ces mthodes, celles qui construisent une
architecture virtuelle sont intressantes car elles possdent une grande facilit
de dploiement. Les algorithmes de clustering font partie de cette famille et
possdent la particularit de reposer sur des algortihmes gnralement simples.
Les algorithmes de clustering reposent sur le partitionnement des nuds du
rseau en groupes (clusters). Un leader (appel Cluster Head ) est choisi dans
chaque groupe et sert identifier les clusters. Les nuds appartenant plus
dun cluster sont des passerelles. Les passerelles permettent linterconnexion et
la communication inter-cluster. Un CDS est alors form par les Cluster Heads et
les passerelles. La construction du CDS est quasi-locale car le choix dun Cluster
Head peut se rpercuter sur les choix des autres Cluster Heads. Un exemple de
formation en cluster est prsent sur la figure 3.1.
Les diffrents algorithmes de clustering se distinguent principalement par :
le critre dlection du Cluster Head (par exemple, ladresse des nuds
ou leur nombre de voisins).
la taille des groupes : gnralement exprime en nombre de sauts partir
du Cluster Head.
le contrle du nombre de Cluster Head .
le routage
Un routage hirarchique est effectu grce larchitecture mise en place.
3.4.1
Critre dlection des Cluster Head
3.4.1.1
Identifiant
LCA (Lowest-ID Cluster Algorithm)

Baker et al. proposent une architecture de clustering pour rseaux mobiles
radio dans [EWB87].
Chaque nud possde un identifiant unique qui sert de critre dlection.
Un nud peut prendre trois statuts diffrents : Cluster Head, Passerelle
et Nud.
La mise en place des clusters seffectue par lmission de messages vers le
voisinage un saut. Initialement, tous les nuds ont un statut de N ud.
Chaque nud met priodiquement un message de mise en place, contenant son identifiant. Ce message contient aussi les identifiants des voisins
dont on a reu un message de mise en place. Cela permet de dtecter les
voisins avec lesquels des liens bidirectionnels sont tablis.
1. Si le nud a lidentifiant le plus petit parmi ses voisins, il devient
Cluster Head et dclare son statut.
2. Sinon, le nud attend que ses voisins, dont lidentifiant est plus petit
que le sien, dclarent leur statut.
(a) Si un des voisins ayant un identifiant plus petit se dclare Cluster
Head, le nud dclare son status de N ud. Si le nud entend
plus dun Cluster Head, il se dclare Passerelle.
(b) Si tous les voisins ayant un identifiant plus petit se dclarent
N ud, le nud se dclare Cluster Head.
Les clusters sont recouvrants : les nuds qui appartiennent plusieurs
clusters servent de passerelles. Utiliser lidentifiant comme critre de slection des Cluster Head est une des mthodes les plus simples pour mettre
en place larchitecture. Les nuds ayant un identifiant faible ont tendance
rester Cluster Head plus longtemps. Cela contribue la stabilit de la
structure si ces nuds sont peu mobiles. Au contraire, si les nuds ayant
un identifiant faible sont trs mobiles, larchitecture sera instable.
Adaptive Clustering
Larchitecture de clustering dcrite par Lin et Gerla dans [LG97] vise
amliorer lallocation de ressources (rutilisation spatiale et partage de la
bande passante dans chaque cluster) plutt que le routage. Les auteurs
utilisent une version modifie de lalgorithme Lowest-ID. Chaque nud
possde un identifiant unique et connat les identifiants de ses voisins.
1. Si le nud a lidentifiant le plus petit parmi ses voisins, il devient
Cluster Head et dclare son statut ses voisins.
2. Sinon, le nud attend que ses voisins, dont lidentifiant est plus petit
que le sien, dclarent leur statut.

(a) Parmi les voisins ayant un identifiant plus petit qui se dclarent
Cluster Head, le nud choisit le Cluster Head ayant lidentifiant
le plus petit et diffuse son statut de N ud.
(b) Si tous les voisins ayant un identifiant plus petit se dclarent
Chaque unit mobile conserve lensemble des membres de son cluster. Les
clusters ne sont pas recouvrants car chaque nud adhre un unique
cluster. Lorsque les clusters sont forms, le rle de Cluster Head disparait
car selon les auteurs, les Cluster Head devraient remplir des fonctions
supplmentaires qui gnrent une consommation accrue dnergie pour les
nuds slectionns.
En cas de mobilit, le nud ayant le plus grand nombre de voisins et ses
voisins restent dans le cluster. Les autres nuds doivent changer de cluster.Pour maintenir les clusters, chaque nud doit connaitre son voisinage
deux sauts. Lorsquun nud y sort du voisinage deux sauts de x :
Si le nud ayant le plus grand nombre de voisins est toujours un saut,
x reste dans son cluster et enlve y de son cluster.
Sinon, x change de cluster.
Le nud ayant le plus grand nombre de voisins joue implicitement le rle
de Cluster Head.
3.4.1.2
Connectivit
Parekh
Lalgorithme propos par Parkh dans [Par94] vise slectionner les nuds
les plus connects comme Cluster Head. Le critre dlection utilis est le
degr (nombre de voisins). Des algorithmes pour la mise en place des
clusters sont prsents (synchrones ou bass sur des vnements). Chaque
nud peut avoir lun des statuts : Non-Couvert, Couvert ou Cluster Head.
Un nud Non-Couvert est un nud qui na pas de Cluster Head. Lide
gnrale est dinclure successivement dans lensemble des Cluster Head le
nud ayant le plus grand nombre de voisins Non-Couvert.
Les messages indiquant le statut des Cluster Head sont relays dans le
rseau afin que chaque nud mette jour son ensemble de Cluster Head.
La complexit en message des algorithmes proposs est plus importante
que pour lalgorithme Lowest-ID.
Highest-Connectivity degree
Tsai et Gerla proposent une version modifie de lalgorithme de Parekh
dans [GT95], appele HCC (Highest-Connectivity degree Clustering). Le
critre dlection reste le nombre de voisins mais la complexit en message
est rduite.
La mise en place des clusters seffectue par lmission de messages vers le
voisinage un saut. Initialement, tous les nuds ont un statut de N ud.
Chaque nud met priodiquement un message de mise en place, contenant son identifiant et les identifiants de ses voisins.

Un nud se dclare Cluster Head sil est le nud ayant le plus grand
degr parmi ses voisins Non-Couvert. En cas dgalit, le nud ayant le
plus petit identifiant devient Cluster Head.
Sinon, le nud attend que ses voisins de degr plus grand annoncent
leur statut :
1. si un des voisins ayant un degr plus grand se dclare Cluster Head,
le nud dclare son status de N ud. Si le nud entend plus dun
Cluster Head, il se dclare Passerelle.
2. si tous les voisins ayant un degr plus grand se dclarent N ud, le
nud se dclare Cluster Head.
Tsai et Gerla ont montr que lalgorithme Lowest-ID est plus performant
que lalgorithme Highest-connectivity degree en terme de stabilit des clusters. En effet, le nombre de voisins peut varier frquemment selon la mobilit des nuds. Cependant, le choix des nuds les plus connects comme
Cluster Head permet de diminuer le nombre de Cluster Head.
Density metric
Le degr dun nud varie selon les dplacements de ses voisins et nest pas
un critre trs stable. A partir de ce constat, Mitton et Fleury proposent
une nouvelle mtrique permettant dabsorber les changements minimes de
topologie [Mit06]. La mtrique de densit dun nud, appele k-densit, est
fonction du nombre de nuds et des liens existants dans son k-voisinage.
Elle est dfinie comme le rapport entre le nombre de liens et le nombre
de nuds dans le k-voisinage. Les auteurs considrent aussi la mobilit
relative de chaque nud dans leur algorithme de clustering. Les nuds
trop mobiles ne participent pas lalgorithme de clustering car cela impliquerait de nombreuses reconstructions des clusters. La mobilit relative
dun nud peut tre obtenue en observant la stabilit de son k-voisinage
au cours du temps.
La mise en place de larchitecture seffectue par mission de messages dans
le k-voisinage.
1. Priodiquement, chaque nud peu mobile calcule sa densit et la
diffuse dans son voisinage.
2. Chaque nud compare sa densit avec celle de ses voisins :
(a) sil possde la plus grande densit, il devient Cluster Head. En
cas dgalit, le nud ayant t lu au tour prcdent sera choisi,
sinon le nud de plus petit identifiant sera prfr.
(b) sinon, il choisit comme pre dans larbre de clustering son voisin
de plus forte densit. Tous les nuds qui appartiennent au mme
arbre appartiennent au mme cluster.
Pour recentrer les Cluster Heads dans leurs clusters respectifs, tout nud
voisin dun Cluster Head doit adhrer son cluster. De plus, si un nud est
voisin de plusieurs Cluster Heads, les clusters concerns doivent fusionner

et le Cluster Head de plus forte densit conserve son rle dans le nouveau
cluster. Ainsi, les Cluster Heads sont distants dau moins trois sauts. Les
clusters mis en place sont non recouvrants et peuvent avoir des tailles
diffrentes.
3.4.1.3
Mobilit
MOBIC
Basu et al. proposent un protocole de clustering appel MOBIC [BKL01]
qui utilise un algorithme identique Lowest-ID et HCC. Le critre de
slection des Cluster Head est la mobilit relative dun nud. Lobjectif
est de choisir les nuds les moins mobiles comme Cluster Head pour avoir
une plus grande stabilit.
La mtrique de mobilit est calcule grce lmission priodique de messages Hello. La puissance du signal reu est fonction de la distance entre
lmetteur et le rcepteur. Chaque nud mesure la puissance du signal
reu avec chacun de ses voisins et calcule le rapport de la puissance reue
avec celle mesure lors de lmission prcdente. La mobilit relative du
nud est obtenue en calculant la variance de lensemble des rapports des
voisins. Les auteurs ont compar leur algorithme de clustering avec la version de lalgorithme Lowest-ID prsente dans [CWLG97] et montrent que
leur technique construit des clusters plus stables (le taux de changements
de Cluster Heads est plus faible pour MOBIC).
(, t) Cluster
La proposition de McDonald et Znati sinspire des concepts de ZRP [MZ99].
Un routage proactif est utilis lintrieur dun mme cluster et un routage
ractif est dploy entre les clusters. La mtrique de mobilit utilise pour
mettre en place les clusters est la disponibilit du chemin. Cette mtrique
repose sur un modle probabiliste :
la disponibilit de lien est dfinie comme la probabilit quun lien existera entre deux nuds linstant t0 + t sachant quun tel lien existe
linstant t. Elle est obtenue en supposant que les mouvements des nuds
suivent un modle de mobilit stochastique dfini par les auteurs.
un chemin (, t) est un chemin qui sera disponible linstant t0 + t avec
une probabilit > . La disponibilit du chemin est dfinie comme le
produit des disponibilits de lien entre les nuds qui compose le chemin.
Les ruptures de lien sont supposes indpendantes.
Chaque membre dun cluster dispose de chemins (, t) avec tous les autres
membres du cluster. Ainsi, la taille des clusters augmente lorsque la mobilit est faible et diminue lors des priodes de forte mobilit.
Initialement, un nud nappartenant aucun cluster tente dadhrer au
cluster dun des ses voisins. Grce au trafic proactif intra-cluster, le nud :
identifie le cluster auquel appartient chacun de ses voisins.
value la disponibilit de lien avec chacun de ses voisins.

Les voisins dtectent le nud non-couvert et lui transmettent les informations topologiques relatives leurs clusters respectifs. Le nud peut alors
dterminer sil satisfait les critres (, t) pour rejoindre un cluster. Sil
possde un chemin (, t) vers chacun des membres dun cluster, le nud
non-couvert intgre ce cluster. Sil ne peut rejoindre aucun des clusters de
ses voisins, le nud cre son propre cluster. Les clusters sont maintenus
grce au trafic proactif intra-cluster.
Les valeurs optimales des paramtres et t sont trs difficiles dterminer. Des grandes valeurs de t impliquent des clusters plus stables mais
rendent la borne plus difficile atteindre pour des conditions de mobilit
donnes. De plus, le comportement de lalgorithme dpend fortement du
modle de mobilit probabiliste.
3.4.1.4
Poids
DCA/DMAC
Basagni propose dans [Bas99] les algorithmes de clustering DCA (Distributed Clustering Algorithm) et DMAC (Distributed Mobility-Adaptive
Clustering). Lalgorithme DCA convient pour les rseaux quasi-statiques
tandis que lalgorithme DMAC est adapt aux environnements mobiles. De
nombreux algorithmes de clustering sinspirent de lalgorithme Lowest-ID
en modifiant uniquement le critre de slection des Cluster Head. Lauteur
propose donc un poids gnrique dont le choix dpend de limplantation
choisie. Dans les propositions DCA et DMAC, le choix des Cluster Head
est bas sur un poids (un rel positif) reprsentant la stabilit du nud.
Ce poids peut tre dfini par exemple par linverse de la vitesse de dplacement. Les membres dun cluster sont un saut du Cluster Head.
3.4.1.5
Combinaison de critres
WCA
Lalgorithme de clustering WCA (Weighted Clustering Algorithm) propos par Chatterjee, Das et Turgut prend en compte plusieurs mtriques
pour choisir les Cluster Heads [CDT02]. Le critre de slection correspond
la somme pondre de quatre critres :
la diffrence de degr v est la diffrence entre le nombre de voisins de
v et une constante correspondant au nombre de voisins idal pour un
Cluster Head. Elle traduit la connectivit.
Dv est la somme des distances entre v et ses voisins. Les distances
peuvent tre estimes en utilisant la puissance du signal reu ou laide
dun GPS. Dv est li la consommation dnergie car une puissance
de transmission plus leve est ncessaire pour communiquer grande
distance.
Mv est la vitesse relative de v. Elle est obtenue partir des coordonnes
de v entre deux instants t et (t 1). Cette mtrique exprime la mobilit
du nud.

Pv est le temps cumul durant lequel v a agi comme Cluster Head. Il
mesure la quantit de batterie consomme.
Le critre de slection Wv est alors calcul par la formule :
Wv = w1 v + w2 Dv + w3 Mv + w4 Pv
Le nud ayant le critre Wv le plus petit est choisi comme Cluster Head
suivant lalgorithme LCA. Les facteurs de pondration wi sont choisis selon
lapplication. Ainsi, dans un rseau de capteurs, lconomie des batteries
est un paramtre critique pour la dure de vie du rseau et le poids de Pv
peut tre plus important.
3.4.2
Taille des clusters
Les algorithmes proposs prcdemment mettent en place des clusters 1

saut. Ainsi, tous les membres du cluster sont porte directe du Cluster Head.
Le concept a t gnralis aux k -clusters : les membres du cluster sont situs
au plus k sauts du Cluster Head.
k-hop clustering
Les auteurs de [NGS03] ont tendu lalgorithme de clustering Lowest-ID
de Lin et Gerla [LG97] pour construire des k -clusters. Chaque unit mobile
connait ses voisins k sauts (k -voisins).
1. Si le nud a lidentifiant le plus petit parmi ses k -voisins, il devient
Cluster Head et dclare son statut ses k-voisins (son paquet a un
TTL gal k ).
2. Sinon, le nud attend que ses k-voisins, dont lidentifiant est plus
petit que le sien, dclarent leur statut.
(a) Parmi les k-voisins ayant un identifiant plus petit qui se dclarent
Cluster Head, le nud choisit le Cluster Head ayant lidentifiant
le plus petit et diffuse son statut de N ud ses k-voisins.
(b) Si tous les k-voisins ayant un identifiant plus petit se dclarent
Les auteurs de [NGS03] proposent aussi une extension de lalgorithme
Highest-Connectivity degree aux k -clusters. Les Cluster Heads sont choisis selon leur k -degr (le nombre de voisins situs au plus k sauts) et
lidentifiant est utilis en cas dgalit. Les procdures de maintenance de
larchitecture reprennent celles dcrites par [LG97].
Max-min D-clusters
Amis et al. ont mis au point une heuristique pour construire des k -clusters
[APHV00]. Le critre de slection des Cluster Heads est lidentifiant. La
mise en place de larchitecture se droule en trois phases :

1. Floodmax : Cette phase se droule en k tapes. A chaque tape, une
unit mobile diffuse vers ses voisins un saut le plus grand identifiant
entendu (WINNER) lors des tapes prcdentes de Floodmax. La
variable WINNER est initialise avec lidentifiant du nud.
2. Floodmin : Cette phase se droule en k tapes. A chaque tape, une
unit mobile diffuse vers ses voisins un saut le plus petit identifiant
entendu (WINNER) lors des tapes prcdentes de Floodmin. La
variable WINNER est initialise avec la valeur collecte lors de la
dernire tape de Floodmax.
3. la slection des Cluster Heads seffectue grce aux identifiants collects lors des deux premires phases :
si on a reu son propre identifiant lors de la deuxime phase, on
devient Cluster Head.
sinon, chaque nud choisit son Cluster Head parmi les identifiants
reus lors des phases 1 et 2 (le plus petit identifiant est retenu).
sinon, on choisit le nud de plus grand identifiant parmi ceux
entendus lors de la premire phase.
Cet algorithme construit des Max-Min k -clusters non recouvrants, en rfrence aux phases Floodmax et Floodmin. Une fois les Cluster Heads
choisis, chaque nud diffuse lidentifiant de son Cluster Head ses voisins. Ainsi, chaque nud peut savoir sil joue le rle de passerelle. Les
auteurs montrent un meilleur passage lchelle par rapport la densit
de nuds que lalgorithme LCA. Cependant, ils ne prsentent pas de mcanisme de maintenance de clusters par rapport la mobilit. De plus,
la dure de mise en place des clusters (2.k tapes) peut tre importante
selon la valeur de k.
3.4.3
Contrle du nombre de Cluster Head
Le dplacement dun nud peut induire des ractions en chane qui ncessitent une remise en place de larchitecture de clusters. Les algorithmes de
base comme Lowest-ID ou Highest-Connectivity Degree choisissent un nouveau
Cluster Head ds que les membres du cluster changent. Certains algorithmes
de clustering essaient de minimiser le nombre de changements de Cluster Heads
afin damliorer la stabilit des clusters.
LCC
Gerla et son quipe furent parmi les premiers traiter le problme en
proposant lagorithme LCC (Least Cluster Change) [CWLG97]. La mise
en place des clusters suit lalgorithme LCA ou Highest-Connectivity Degree. Lorsque des membres (non Cluster Heads) dun cluster se dplacent,
larchitecture de clusters reste inchange. Lorsque deux Cluster Heads se
retrouvent porte radio, celui qui possde le critre de slection le plus
faible (lID le plus grand ou le degr le plus petit) abandonne son rle
de Cluster Head et devient membre du cluster. Les units mobiles qui se

retrouvent sans Cluster Head relancent la procdure de mise en place. Le
mcanisme de maintenance LCC est lun des plus utiliss dans les algorithmes de clustering.
MOBIC
Les auteurs de MOBIC ont adapt le mcanisme LCC pour gagner en
stabilit [BKL01]. Lorsquun Cluster Head A dtecte un Cluster Head B
avec un meilleur critre porte radio, il arme un timer. A nabandonne
son rle que si B est toujours porte radio lexpiration du timer. Ainsi,
larchitecture des clusters nest pas modifie si les Cluster Heads restent
voisins pendant un court espace de temps.
ARC
Belding-Royer met en vidence dans [BR02] un des effets ngatifs du mcanisme LCC : lorsque un Cluster Head abandonne son rle, certains nuds
se retrouvent Non-Couverts et initient llection dun nouveau Cluster
Head. Cet vnement peut dclencher des changement de Cluster Heads
en rafale et rendre larchitecture de clusters instable. Dans le protocole
ARC (Adaptive Routing using Clusters), un Cluster Head abandonne son
rle si les membres de son cluster constituent un sous-ensemble dun autre
cluster. Un Cluster Head sait que son cluster E est un sous ensemble du
cluster F si tous les membres de E sont des passerelles vers le Cluster
Head de F . Lavantage de cette approche est quaucun nud membre de
son cluster ne se retrouve Non-Couvert. En contrepartie, le nombre de
Cluster Heads peut tre plus grand que dans le cas de LCC.
3.4.4
Routage
ARC/ARCH
Belding-Royer dcrit deux algorithmes de clustering pour le routage dans
[BR03] : ARC (Adaptive Routing using Clusters) et ARCH (Adaptive
Routing using Clustered Hierarchies). ARC construit une hirarchie de
clusters un niveau et ARCH construit une architecture multi-niveaux.
La mise en place des clusters est base sur lidentifiant comme lalgorithme
Lowest-ID. La maintenance de larchitecture est assure par lchange priodique de messages Hello indiquant le statut des nuds. Le contrle
du nombre de Cluster Heads a t dcrit dans la partie 3.4.3 : un Cluster Head abandonne son rle si les membres de son cluster constituent un
sous-ensemble dun autre cluster. Loriginalit des protocoles ARC/ARCH
est lutilisation dun adressage hirarchique pour router les donnes. La
motivation de lauteur vient de la faiblesse de ladressage plat par rapport
aux ruptures de liens. ARC dfinit plusieurs passerelles (si elles existent)
pour interconnecter deux clusters. La route utilise est alors compose
de ladresse source, des Cluster Heads intermdiaires et de ladresse destination. Cette route hirarchique est plus robuste aux changements de
topologie car le passage par une passerelle donne nest pas impos.

Les nuds ordinaires maintiennent une table o sont mmorises les adresses
des Cluster Heads situs un saut (Cluster Head Table). Chaque Cluster
Head maintient :
une table regroupant les adresses des membres de son cluster
une table contenant les adresses des Cluster Heads voisins ainsi que les
passerelles pour les atteindre.
Le protocole est utilis en conjonction avec un protocole de routage ractif (dans [BR03], lauteur choisit AODV). Le Cluster Head sert de reprsentant pour les membres de son cluster. Ainsi, seuls les Cluster Heads
traitent les paquets de contrle AODV. Les nuds ordinaires se contentent
de relayer ou de diffuser les paquets de contrle selon leur type (unicast
ou broadcast). Le Cluster Head communique chacune des passerelles
les routes quelle doit connaitre. En cas de rupture de route, le Cluster
Head slectionne une autre passerelle pour rparer le chemin ou initie une
dcouverte de route AODV si aucune passerelle nest prsente.
CBRP
Jiang, Li et Tay proposent un algorithme de clustering qui met en place
des 1-clusters [JLT99]. La formation des clusters est base sur lalgorithme
Lowest-ID. Chaque nud maintient :
une table des voisins qui mmorise les adresses et les rles des voisins
(Nud ou Cluster Head).
une table des clusters adjacents qui contient les adresses des Cluster
Heads voisins ainsi que les passerelles pour les joindre.
Tous les nuds mettent priodiquement des messages Hello qui contiennet la table des voisins et la table des clusters adjacents. Chaque Cluster
Head maintient les informations concernant les membres de son cluster.
Les routes entre les diffrents clusters sont dcouvertes laide des informations maintenues par les Cluster Heads. Le routage CBRP est bas sur
le routage source comme DSR. La route est compose de ladresse source,
de la liste des Cluster Heads intermdiaires et de ladresse destination.
La dcouverte de route seffectue la demande. Lorsquun nud source
S recherche un nud destination D, il met une requte de route. Cette
requte de route contient des entres Cluster Head Voisin/Passerelle indiquant les adresses des Cluster Heads voisins (y compris celle de son Cluster
Head) ainsi que les passerelles pour les atteindre.
Lorsquun Nud intermdiaire reoit une requte de route :
si D est son voisin, il relaie la requte jusqu D.
sil est indiqu comme passerelle, il relaie la requte jusquau Cluster
Head correspondant.
sinon, il dtruit la requte.
Lorsquun Cluster Head reoit une requte de route :
sil a dj trait cette requte, il la dtruit.
sinon il enregistre son adresse dans la liste des Cluster Heads intermdiaires :

1. si D est son voisin direct ou 2 sauts, il relaie la requte jusqu D.
2. sinon, le Cluster Head parcourt sa table des clusters adjacents. Si
le Cluster Head adjacent nest ni dans la liste des Cluster Heads
voisins, ni dans la liste des Cluster Heads intermdiaires, il rajoute
une entre Cluster Head Voisin/Passerelle dans la requte. Aprs
avoir parcouru sa table, le Cluster Head diffuse la requte.
Lorsque la destination D est atteinte, elle renvoie une rponse de route
qui contient la liste des Cluster Heads intermdiaires et un champ route
calcule. Lors du relayage de la rponse, chaque Cluster Head intermdiaire
remplit une partie de la route calcule en se basant sur sa table des clusters
adjacents.
3.5
3.5.1
Mthode dadaptation du routage

Approche propose
Nous avons vu dans le chapitre 2 que les protocoles de routage bass sur
linondation ont des difficults de passage lchelle par rapport la taille du
rseau. De nombreuses solutions pour permettre le passage lchelle par rapport la taille du rseau ont t prsentes dans ce chapitre. Parmi ces solutions,
les algorithmes de clustering construisent une architecture virtuelle pour faciliter
le routage. Les algorithmes de clustering permettent une mise en place locale qui
requiert peu de trafic de contrle. De plus, ils ne ncessitent aucun quipement
supplmentaire sur les nuds comme un systme de localisation GPS.
Les protocoles de premire gnration tels DSR ou AODV sont bien adapts
aux petits rseaux car les routes sont recherches la demande. De plus, le trafic
de contrle gnr par linondation du rseau ne pnalise pas les performances
de ces protocoles lorsque le nombre de nuds est faible. Les protocoles bass
sur linondation sont aussi les plus adapts aux conditions de forte mobilit.
Les solutions hirarchiques, quant elles, savrent plus performantes sur
les rseaux de grande taille. Cependant, leurs performances se dgradent rapidement en cas de forte mobilit : lavantage dutiliser une architecture pour le
routage ne compense pas le cot de la mise en place et de la maintenance de
larchitecture virtuelle
Nous avons vu que les solutions bass sur linondation et les solutions hirarchiques ont des domaines de performance diffrents en fonction de la mobilit
des nuds et de la taille du rseau. Cependant, les conditions du rseau peuvent
changer rapidement et de manire imprvisible. Prenons pour exemples des applications classiques des rseaux ad hoc : les oprations militaires et les rseaux
de secours. Lorsque des troupes ou des quipes mdicales sont dployes dans
une zone tendue, il est possible que plusieurs rseaux ad hoc de petite taille
se forment. Ces petits rseaux peuvent ensuite nen former quun seul lorsque
les diffrents groupes rejoignent un mme lieu (camp de base, centre mdical).
Ainsi, la taille du rseau peut varier au gr des fusions et/ou des partitionnements de rseaux. De la mme manire, les conditions de mobilit peuvent

voluer selon la mission effectue. Lors de la recherche de blesss, les quipes
mdicales sont amenes se dplacer frquemment. Leurs dplacements sont
moins nombreux lors de la prise en charge des blesss.
Nous proposons de combiner les avantages des protocoles bass sur linondation et des protocoles bass sur une hirarchie en fonction des conditions en
termes de mobilit et de densit [JP06]. Le type de routage utilis (inondation
ou hirarchique) dpendra de la mobilit et de la densit. Le routage hirarchique Avec Architecture (AA) sera utilis lorsque la densit est leve et que
la mobilit est faible. Le routage plat Sans Architecture (SA) sera plus indiqu
dans des conditions de densit faible ou de mobilit forte.
Ladaptation du mode de routage doit tre distribue car aucune administration centralise nest disponible dans les rseaux ad hoc. Chaque nud mobile
doit valuer les conditions de mobilit et de densit du rseau pour adapter son
mode de routage. Lhypothse dune adaptation distribue impose une compatibilit entre les deux modes de routage. En effet, deux nuds peuvent se trouver
dans des modes de routage diffrents un instant donn. La communication
entre deux nuds dans des modes diffrents doit rester possible. Par consquent, le choix dune extension hirarchique dun protocole plat est prfrable
lutilisation de deux protocoles distincts.
Nous prsentons dans cette partie une mthode pour adapter dynamiquement le mode de routage (plat ou hirarchique) selon les conditions de rseau.
Tout dabord, nous nous intresserons aux mtriques de mobilit et de densit
qui permettent le changement de mode. Nous dcrirons ensuite les principes de
notre mthode dadaptation. Un exemple de mise en uvre de notre mthode
dadaptation sera tudi dans le chapitre 4.
3.5.2
Mtriques dadaptation
3.5.2.1
Mobilit
Dans notre processus dadaptation, la mtrique de mobilit est ncessaire

pour dclencher le changement de mode de routage. Elle est aussi utilise pour
la mise en place de larchitecture ainsi que pour lajustement de timers.
Nous avons prsent diffrentes mtriques de mobilit dans la partie 3.2. Le
choix de la mtrique de mobilit est li aux caractristiques du protocole de
routage plat :
changes priodiques de paquets : de nombreuses mtriques comme
Link change rate ou Link duration peuvent tre calcules grce des
missions priodiques. Par exemple, le protocole AODV utilise des missions priodiques de messages Hello dans son fonctionnement.
pas dchanges priodiques de paquets : nous devons alors utiliser les
informations de routage disponibles. Lutilisation du trafic de contrle ou
la gestion de la table de routage fournissent une valuation de la mobilit
sans trafic de contrle supplmentaire. En effet, la minimisation du trafic
de contrle est un des objectifs principaux de notre mthode dadapta-

tion. Dans le cas du protocole DSR, les paquets Route Error indiquent
par exemple des ruptures de lien.
Dans lexemple dapplication de notre mthode expos dans le chapitre suivant,
nous utilisons comme protocole plat le protocole DSR. Nous proposons dutiliser
le nombre derreurs de routes DSR gnres par un nud comme mtrique de
mobilit. Un paquet derreur de route est mis par un nud lorsquil ne peut
transmettre un paquet au prochain saut. Le choix de cette mtrique a t motiv
par trois points :
minimisation du trafic de contrle : le calcul de notre mtrique de
mobilit ne doit pas gnrer de trafic de contrle supplmentaire. En effet,
la minimisation du trafic de contrle est un des objectifs dun protocole
de routage ad hoc. La mtrique de mobilit doit tre obtenue en utilisant
les mcanismes intgrs au protocole DSR comme les erreurs de route.
notion de lien : une erreur de route est gnre lorsquun nud constate
quun lien nest plus disponible. Une dfinition de la mobilit lie la
rupture de lien est intressante du point de vue du routage.
dfinition lie au trafic : les erreurs de route concernent les liens qui
sont utilises pour vhiculer du trafic de donnes. Le mouvement dun
nud qui ne vhicule pas de trafic de donnes est sans incidence sur le
routage.
3.5.2.2
Densit
Dans notre processus dadaptation, la mtrique de densit est ncessaire

pour dclencher le changement de mode de routage. Nous lutilisons aussi pour
la mise en place de la hirarchie.
Une mtrique de densit globale est une mtrique qui fournit une estimation
du nombre total de nuds dans le rseau. Cependant, le calcul dune telle mtrique ncessite un trafic de contrle important et la minimisation du trafic de
contrle est une de nos priorits. Ainsi, nous nous sommes concentrs sur une
estimation locale de la densit.
Lestimation locale de la densit est fournie par le nombre de voisins (nuds
avec lesquels un nud possde un lien radio). Cependant, cette mtrique peut
tre obtenue de diffrentes manires selon les caractristiques du protocole :
changes priodiques de paquets : le nombre de voisins peut tre
obtenu grce des missions priodiques. Par exemple, le protocole AODV
utilise des missions priodiques de messages Hello pour remplir une table
de voisins.
pas dchanges priodiques de paquets : nous devons utiliser les informations de routage disponibles. La gestion de la table de routage fournit
une valuation du nombre de voisins sans trafic de contrle supplmentaire. En effet, la minimisation du trafic de contrle est un des objectifs
principaux de notre mthode dadaptation. Dans le cas du protocole DSR,
le cache de routes permet de connaitre les nuds avec lesquels on possde
un lien radio et ainsi de calculer le nombre de voisins.
station AA
Routage SA
station SA
Routage SA
Routage AA
Routage SA
station AA
station SA
AA: Avec Architecture, SA: Sans Architecture

Fig. 3.2 Compatibilit entre les modes de routage
3.5.2.3
Principes de notre mthode dadaptation
Notre mthode dadaptation est indpendante du choix des mtriques de

mobilit et de densit. Nous notons Mobilit et Densit les mtriques qui fournissent les estimations de mobilit et de densit.
Chaque nud peut tre dans un mode de routage plat Sans Architecture
(SA) ou dans un mode de routage hirarchique Avec Architecture (AA).
Dans le mode AA, des procdures sont spcifies afin de mettre en place
larchitecture : certains nuds sont choisis pour remplir des fonctions de routage supplmentaires. Ces procdures sont lies au protocole de routage utilis
en mode SA. Cependant, deux rgles doivent tre appliques pour obtenir un
modle ouvert :
1. deux nuds dans des modes de routage diffrents doivent pouvoir communiquer. Par consquent, le mme format de paquet doit tre utilis dans
les deux modes.
2. le mode de routage Avec Architecture est une extension du mode de routage Sans Architecture. Les paquets de routage du mode AA sont vhiculs
par une option du protocole SA. Les paquets de routage AA sont traits
comme des paquets de routage SA par les nuds en mode SA alors quils
sont traits comme des paquets de routage AA par les nuds en mode
AA. Les changes entre les nuds dans des modes diffrents sont rsums

(D > D_forte et M < M_faible) ou
(D_faible < D < D_forte et M_faible < M < M_forte
et paquet AA reu)
Mode Avec Architecture
Mode AA
oprationnel
D < D_faible ou
M > M_forte
Erreur AA
D_faible < D < D_forte

ou
M_forte > M > M_faible
Nb_ERROR > MAX

Mode Transition Adaptative
Mode Sans Architecture
Erreur AA ou
non(AA oprationnel)
D < D_faible ou
M > M_forte
(D > D_forte et M < M_faible) ou
(D_faible < D < D_forte et M_faible < M < M_forte
et paquet AA reu)
D: Densit ; M:Mobilit
Fig. 3.3 Modes de routage

dans la figure 3.2.
Chaque unit mobile adapte son mode de routage de manire autonome en
fonction de sa Mobilit et de sa Densit. Un nud qui utilise lextension AA
peut exprimenter trois modes (voir figure 3.3) :
Sans Architecture
Cest le mode de dmarrage pour chaque nud. Lunit mobile utilise les
procdures de routage du protocole plat Sans Architecture. Elle calcule
priodiquement sa Mobilit et sa Densit. Ainsi chaque nud peut dtecter les conditions de rseau favorables un changement de mode (faible
Mobilit et forte Densit). Si les conditions de mobilit et de densit sont
convenables, le nud rentre dans le mode Transition Adaptative. Nous
avons dfini deux seuils de changement de mode pour la Mobilit (Mf aible
< Mf orte ) et la Densit (Df aible < Df orte ).
M obilit
e > Mf orte ou Densit
e < Df aible : la station mobile reste en
mode Sans Architecture car la Mobilit est forte et/ou la Densit faible.
M obilit
e Mf orte et Densit
e Df aible : la station mobile passe du
mode Sans Architecture au mode Transition Adaptative si elle reoit
un paquet de routage AA. La Mobilit et la Densit ont des valeurs
moyennes. Cette transition a t dfinie pour favoriser le passage en
mode AA. En effet, la valeur de la mtrique de mobilit peut osciller
autour des seuils selon la dfinition choisie. Pour que le mode de routage
AA soit performant, il faut que le plus de noeuds possible bascule en
mode AA durant la mme priode.
M obilit
e Mf aible et Densit
e Df orte : la station mobile passe du
mode Sans Architecture au mode Transition Adaptative car la Mobilit
est faible et la Densit est forte.
Transition Adaptative
La station mobile utilise les procdures de routage du protocole plat Sans

Architecture. Cependant, les procdures du mode de routage Avec Architecture sont excutes pour mettre en place larchitecture hirarchique. Le
routage Sans Architecture et la mise en place du mode AA sont effectus
en parallle pour permettre la transition entre les deux modes. Ainsi, le
routage est oprationnel mme durant la phase de transition.
Si les procdures AA parviennent mettre en place larchitecture, le nud
passe en mode de routage Avec Architecture. Dans le cas contraire, le nud
repasse en mode Sans Architecture.
Le mode Transition Adaptative permet aussi de grer le recouvrement
derreurs du mode hirarchique. Si une erreur se produit dans le mode Avec
Architecture, le nud peut utiliser le routage Sans Architecture pendant
le recouvrement de larchitecture.
Avec Architecture
Le nud utilise les procdures de routage du mode Avec Architecture. Les
procdures hirarchiques AA sont utilises pour maintenir larchitecture.
En cas derreur, le nud passe en mode Transition Adaptative pour recouvrer larchitecture. Le nud passe en mode Sans Architecture si les
dynamiques de rseau ne sont plus favorables au mode hirarchique (Mobilit trop forte et/ou Densit trop faible).
3.6
Conclusion
Afin damliorer les performances des protocoles de routage, nous avons analys les mcanismes dadaptation du routage. La mthode dadaptation que
nous prconisons permet un fonctionnement dynamique des protocoles selon les
conditions de mobilit et de taille du rseau.
De nombreux travaux de routage se sont focaliss sur loptimisation des solutions de routage hirarchiques. Loriginalit de notre approche est doptimiser
les performances de routage en considrant le routage hirarchique comme un
mode de fonctionnement du protocole dans des conditions de rseau donnes.
Les units mobiles adoptent un mode de fonctionnement plat en cas de changements de conditions de rseau.
Nous verrons dans le chapitre suivant comment mettre en uvre notre approche en nous basant sur le protocole DSR.
Chapitre 4
Hirarchisation adaptative du
protocole DSR
Sommaire
4.1
Notre approche . . . . . . . . . . . . . . . . .
4.1.1 Clusterisation du routage source : CSR . .
4.1.2 Architecture de clusters . . . . . . . . . . .
4.2 Procdures CSR . . . . . . . . . . . . . . . .
4.2.1 Routage CSR . . . . . . . . . . . . . . . . .
4.2.2 Procdures de clustering . . . . . . . . . . .
4.3 Adaptation du mode de routage . . . . . .
4.3.1 Changements de mode . . . . . . . . . . . .
4.4 Conclusion . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
82
84
. 84
. 89
99
. 99
101
.
.
Nous avons prsent dans le chapitre prcdent les principes de notre mthode dadaptation du mode de routage. Notre proposition repose sur lutilisation dun mode de routage plat ou hirarchique selon les conditions de mobilit
et de densit du rseau. Nous allons prsenter dans ce chapitre un exemple de
mise en uvre de notre mthode.
Pour appliquer notre mthode dadaptation du mode de routage, nous avons
choisi le protocole DSR comme mode de routage plat Sans Architecture.
DSR est un protocole standardis et il possde un mcanisme doptions qui
facilite lajout de nouveaux paquets au protocole.
En nous basant sur DSR, nous avons dfini une extension hirarchique de ce
protocole que nous appelons CSR (Cluster Source Routing). Cette extension
constituera le mode de routage hirarchique Avec Architecture. Parmi
les solutions hirarchiques possibles, nous avons choisi de dfinir un algorithme
de clustering. Les algorithmes de clustering que nous avons vu prcdemment
sont adapts notre mthode car ils sappuient sur une architecture virtuelle,
78
CHAPITRE 4. HIRARCHISATION ADAPTATIVE DU PROTOCOLE DSR79

0
7
En-tte suivant
15
Rserv
31
Longueur charge utile
Tab. 4.1 En-tte fixe DSR

gnrent un trafic de contrle faible et sont simples mettre en uvre. Nous
avons spcifi toutes les procdures de routage et de clustering de lextension
CSR.
Pour dclencher le changement de mode entre les deux mode de routage, nous
avons propos deux mtriques. Notre mtrique de mobilit est le nombre
de paquets derreurs de route gnrs. Notre mtrique de densit est
le nombre de voisins 1 saut estim grce au cache de routes.
Dans ce chapitre, nous dmontrons la faisabilit de notre mthode dadaptation.
4.1
4.1.1
Notre approche
Clusterisation du routage source : CSR
Les dynamiques du rseau peuvent voluer rapidement. Ainsi, nous proposons de combiner les avantages des protocoles bass sur linondation et des protocoles bass sur une hirarchie en fonction des conditions en termes de mobilit
et de densit. Le type de routage utilis (inondation ou hirarchique) dpendra
de la mobilit et de la densit.
Les rseaux ad hoc ne disposent daucune infrastructure centralise. Ainsi,
chaque nud doit adapter de manire individuelle et dynamique son mode de
routage en se basant sur ses mtriques dadaptation. Deux nuds peuvent se
trouver dans des modes de routage diffrents un instant donn. Par consquent, la compatibilit et la transparence entre les modes de routage sont des
conditions qui doivent tre ncessairement remplies par lextension que nous
prsentons.
Nous proposons une extension hirarchique du protocole DSR que nous appelons CSR (Cluster Source Routing) [JP04, JP05]. Lobjectif de notre extension
est de permettre le passage lchelle du protocole DSR par rapport la taille
du rseau. Pour cela, nous mettons en place une architecture de clusters pour faciliter le routage et viter linondation du rseau lors des dcouvertes de routes.
Le chef du cluster de plus haut niveau agit comme un cache de routes centralis
et traite les requtes de route provenant des autres nuds du rseau. La dcouverte de routes est alors effectue via des communications unicast entre les
chefs de clusters. Loriginalit de notre approche rside dans ladaptation distribue du mode de routage (plat ou hirarchique) selon les conditions du rseau :
chaque nud adapte son mode de routage de manire autonome en fonction de
ses critres dadaptation (Mobilit et Densit).
Pour permettre la compatibilit entre les deux modes, le format de paquet

0
7
Type doption
15
Longueur
31
................................
Tab. 4.2 Format doption DSR

du DSR est conserv. Ainsi, les nuds en mode DSR et CSR peuvent communiquer. Len-tte DSR est situ immdiatement aprs len-tte IP du paquet. Il
est compos dun en-tte fixe de 4 octets suivi dune ou plusieurs options DSR
(Route Request, Route Reply, Route Error, Source Route, . . .). Len-tte fixe
est compos dun champ En-tte suivant identique au champ Protocole de
len-tte IPv4, dun champ Rserv qui nest pas utilis pour linstant et dun
champ Longueur charge utile qui indique la taille de la partie option DSR
(voir Figure 4.1). Chaque nouvelle option dbute par un champ Type doption
qui permet didentifier loption et un champ Longueur qui indique la taille en
octets de loption (voir Figure 4.2).
Nous avons attribu aux options CSR des codes doption pour que les nuds
DSR natifs traitent le paquet si ncessaire. Le draft du protocole DSR spcifie le
comportement des nuds DSR natifs en prsence dune option de type inconnu :
si le premier bit du champ Type doption est positionn 1, le nud
renvoie un paquet DSR Route Error la source du paquet. Le type de
lerreur de route indique que loption nest pas supporte. Sinon, il poursuit
le traitement de loption.
le nud examine alors les deux bits suivant du champ Type doption :
les deux bits sont positionns 00 : le nud ignore cette option et
continue le traitement des options suivantes ventuelles.
les deux bits sont positionns 01 : le nud supprime loption du paquet
et continue le traitement des options suivantes.
les deux bits sont positionns 10 : le nud marque loption en positionnant le premier bit du champ Type doption 1. Il ignore alors
loption et continue le traitement des options suivantes.
les deux bits sont positionns 11 : le nud supprime le paquet.
Les trois premiers bits du champ Type doption seront positionns 000 ou
011 selon le traitement souhait. Typiquement, les nuds DSR natifs vont :
soit relayer les paquets contenant une option CSR jusquaux nuds qui
peuvent les traiter (Type doption = 000).
soit supprimer un paquet CSR qui ne peuvent pas traiter (Type doption
= 011).
Nous prsentons dans le tableau 4.3 les diffrentes options que nous avons rajout pour implanter lextension CSR.
Jusqu prsent, seuls les codes doption de 0 7 ainsi que les codes 128 et
129 sont utiliss par le protocole DSR. Lutilisation des options que nous avons
rajoutes sera dtaille dans la partie 4.2.
Nom
CSR Route
Request
CSR Forward
Route Request
CSR Route
Reply
CSR Server
Query
CSR Server
Query Reply
CSR Status
CSR Registration
Request
CSR Registration
Reply
CSR Election
CSR Server
Presence
Code doption
Utilisation
Procdures de routage
0110 0000 (96)
Requte de Route CSR
Nud S Cluster Head CS
0000 1000 (8)
Relayage de la Requte de Route
Cluster Head CS Serveur
0000 1001 (9)
Rponse de Route CSR
Serveur Nud S
0000 1010 (10)
Localisation dune destination D
Serveur Cluster Heads Ci
0000 1011 (11)
Rponse Localisation D
Cluster Head CD Serveur
Procdures de clustering
0110 0001 (97)
Maintenance de la Cellule de Ci
Cluster Head Ci Nuds
0000 1100 (12)
Demande denregistrement
Cluster Head Ci Serveur
0000 1101 (13)
Rponse denregistrement
Serveur Cluster Head Ci
0000 1110 (14)
Election du Serveur
Cluster Head Ci Cluster Heads Ci
0000 1111 (15)
Maintenance Serveur
Serveur Cluster Heads Ci
Tab. 4.3 Options CSR
Fig. 4.1 Modle CSR
4.1.2
Architecture de clusters
Le rseau est divis selon une architecture de clusters deux niveaux (Figure
4.1). Le premier niveau est la cellule (cluster 0-cell). Chaque nud qui appartient
une cellule est situ porte radio directe du chef de cellule (Cluster Head).
La communication entre les cellules seffectue par le biais de passerelles. Le
deuxime niveau de cluster regroupe un ensemble de cellules (cluster 1-server).
Le chef de ce cluster est appel Server. Chaque nud peut exprimenter quatre
statuts :
Indfini : le nud na pas encore obtenu de statut valide. Il utilise le
protocole DSR natif.
Nud : cest un nud qui utilise le mode CSR. Il peut mettre des
requtes de route CSR.
Cluster Head : cest un chef de cluster de niveau 0-cell.
Serveur : cest le chef de cluster de niveau 1-server. Ses informations de
routage sont stockes dans deux tables :
table Mobile - Cluster Head (MCH) : les nuds localiss sont

Cluster Heads
S
C1
C2
C3
C4
N1
N4
N4
N8
N 10
Membres de la cellule
N2
N1
N2
N5
N3
N5
N7
Tab. 4.4 Table Mobile - Cluster Head

Cluster Heads
S
C1
C2
C3
C4
Chemins
N1
C1
N2
C2
N1
S
N5
C3
N4
C2
N2
S
N4
C1
N 7 N 10 C 4
N5
C1
N 10 N 7 C 2
Tab. 4.5 Table Cluster Head - Cluster Head

regroups par cellule. Les cellules sont identifies par les Cluster Heads.
Dans notre exemple, les membres de la cellule du Cluster Head C1 sont
les nuds N1 , N4 et N5 (voir Tableau 4.4).
table Cluster Head - Cluster Head (CHCH) : cest un cache qui
conserve les liens existants entre chaque Cluster Head et ses Cluster
Heads voisins. Les Cluster Heads voisins dun Cluster Head Ci sont
les Cluster Heads situs 2 ou 3 sauts du Cluster Head Ci . La table
CHCH permet ainsi dobtenir les routes entre les Cluster Heads. Dans
notre exemple, le Cluster Head C1 a pour voisins le Serveur et les
Cluster Heads C2 et C3 (voir Tableau 4.5).
4.2
Procdures CSR
Les procdures ncessaires au fonctionnement de lextension CSR sont divises en deux catgories :
les procdures de routage : elles servent la dcouverte et la maintenance de routes.
les procdures de clustering : elles servent la mise en place et la
maintenance de larchitecture virtuelle.
Nous prsenterons dans la suite ces procdures en indiquant les formats de
paquets utiliss.
4.2.1
Routage CSR
4.2.1.1
Dcouverte de routes
La dcouverte de routes CSR vise amliorer le mcanisme de dcouverte de

routes DSR en terme de trafic de contrle ncessaire. Larchitecture de clusters
est utilise pour viter linondation du rseau.
Recherche locale DSR
Lorsquun Nud source S souhaite mettre un paquet de donnes vers un
nud destination D, il consulte son cache de routes. Si la route recherche
est manquante, S diffuse localement une requte de route conformment
loption Non-propagating Route Request du protocole DSR (voir partie
1.3.2.1).
Len-tte fixe DSR est suivi dune option DSR Route Request. Le TTL
du paquet IP est positionn 1.
Loption Non-propagating Route Request est utilise dans lhypothse o
un des voisins possde la route recherche. Elle est intressante car chaque
Nud est voisin dau moins un Cluster Head. Or, les Cluster Heads acquirent des informations de routage plus compltes via leurs communications vers le Serveur. Si la station S reoit une rponse dun de ses voisins,
elle met jour son cache et commence mettre. Len-tte du paquet est
de la forme suivante :
0
7
Type doption=2
15
Longueur
Adresse Cible
31
Identification
(a) Requte de Route CSR
(b) Rponse de Route CSR
(c) Localisation de la destination par le Serveur
Figure 4.2: Dcouverte de Routes CSR

Recherche globale CSR
1. Emission de la requte : si le Nud S ne reoit pas de rponse
de ses voisins, il dclenche une dcouverte de route CSR. Len-tte
fixe DSR est suivi dune option CSR Route Request. Les trois
premiers bits du champ Type doption sont positionns 011 : les
nuds DSR natifs et les Nuds CSR ne traitent pas le paquet. Nous
choisissons donc un code doption gal 96. Le TTL du paquet IP
est positionn 1 pour atteindre seulement les Cluster Heads situs
un saut. Loption CSR Route Request est identique loption Route
Request du DSR si ce nest quelle est traite uniquement par les
Cluster Heads. Elle contient ladresse de la destination recherche
D ainsi quun numro didentification de la requte. Sur la Figure
4.2(a), le Nud S diffuse localement un paquet CSR Route Request.
Len-tte du paquet est de la forme suivante :
0
15
Longueur
Adresse Cible = @D
Type doption=96
31
Identification
2. Relayage de la requte par le Cluster Head : lorsquun Cluster

Head Ci reoit un paquet CSR Route Request, il relaie la requte
jusquau Serveur. Sur la Figure 4.2(a), le Cluster Head B relaie la requte de route jusquau Serveur C. Le Cluster Head possde la route
pour atteindre le Serveur via la procdure Dcouverte de Topologie
que nous dtaillerons dans la partie 4.2.2.4. Le Cluster Head insre
une option DSR Source Route qui contient le chemin jusquau
Serveur (code doption = 7) et une option CSR Forward Route
Request. Les trois premiers bits du champ Type doption de loption CSR Forward Route Request sont positionns 000 : les nuds
DSR natifs et les Nuds CSR ignorent loption. Nous choisissons un
code doption gal 8 pour loption CSR Forward Route Request.
Loption CSR Forward Route Request reprend les champs Identification et Adresse Cible du paquet CSR Route Request. Le TTL est
positionn MAX_HOPS (constante fixe 16 sauts dans le draft
DSR). Plusieurs Cluster Heads peuvent relayer la mme requte vers
le Serveur. Len-tte du paquet est de la forme suivante :
0
7
Type doption=7
15
Longueur
Adresse[1]=@S
Adresse[2]=@C i
..............
Adresse_Serveur
31
Flags
Sauts

Type doption=8
Longueur
Adresse Cible=@D
Identification
3. Traitement de la requte par le Serveur : lorsque le Serveur

reoit un paquet CSR Route Request, il met jour sa table MCH : le
Nud S est localis dans la cellule du Cluster Head C S . Le Serveur
vrifie quil na pas dj trait cette requte en contrlant le numro
didentification de la requte. Si le Serveur a dj trait cette requte,
le paquet est dtruit. Sinon, le Serveur consulte sa table MCH pour
trouver la localisation du nud destination D :
(a) si la destination D est prsente dans la table, le Serveur construit
le chemin entre la source S et la destination D. Pour cela, il utilise sa table CHCH et construit le chemin entre le Cluster Head
associ S, C S , et le Cluster Head associ D, C D . S et D
peuvent tous deux appartenir plusieurs cellules. Dans ce cas, le
Serveur choisit la route qui comporte le moins de sauts si aucune
politique de qualit de service nest dploye. Si le Serveur ne
peut construire de chemin entre S et D, il passe ltape 3b. Sinon, le Serveur renvoie un paquet comportant une option DSR
Source Route et une option CSR Route Reply . Sur la Figure
4.2(b), le Serveur C renvoie une rponse de route vers le Nud
S. Loption DSR Source Route contient le chemin entre le Serveur et le nud S. Loption CSR Route Reply contient la route
entre S et D et les trois premiers bits du champ Type doption
de loption CSR Route Reply sont positionns 000. Nous choisissons un code doption gal 9 pour loption CSR Route Reply.
0
7
Type doption=7
Type doption=9
15
Longueur
Adresse_Serveur
Adresse[2]
..............
Adresse[N]=@S
Longueur
Adresse[1]=@S
Adresse[2]
..............
Adresse[N]=@D
31
Flags
Sauts
Rserv
(b) Si la destination nest pas prsente dans la table MCH, le Serveur interroge tous les Cluster Heads quil connait pour localiser
la destination D (Figure 4.2(c)). Pour chaque Cluster Head C i
prsent dans la table CHCH :

le Serveur construit le chemin entre le Cluster Head C i et lui.
le Serveur envoie un paquet comportant une option DSR Source
Route et une option CSR Server Query . Loption DSR
Source Route contient la route entre le Serveur et le Cluster
Head C i . Loption CSR Server Query contient ladresse de la
source S, ladresse de la destination recherche D et lidentifiant du paquet CSR Route Request. Nous choisissons un code
doption gal 10 pour loption CSR Server Query.
0
15
Type doption=7
Longueur
Adresse_Serveur
Adresse[2]
..............
Adresse[N]=@C i
Type doption=10
Longueur
Adresse Source=@S
Adresse Cible=@D
31
Flags
Sauts
Identification
Lorsquil reoit un paquet Server Query, le Cluster Head diffuse

localement une requte de route conformment loption Nonpropagating Route Request du protocole DSR pour rechercher la
destination D. Si le Cluster Head reoit une rponse de la part
de D, il envoie un paquet comportant une option DSR Source
Route et une option CSR Server Query Reply . Loption
DSR Source Route contient la route entre le Cluster Head et le
Serveur. Loption CSR Server Query Reply contient ladresse de
la source S, ladresse de la destination recherche D et lidentifiant du paquet CSR Server Query. Chaque Cluster Head qui
localise la destination recherche dans sa cellule envoie un paquet
CSR Server Query Reply. Nous choisissons un code doption gal
11 pour loption CSR Server Query Reply.
0
15
Type doption=7
Longueur
Adresse[1]=C i
Adresse[2]
..............
Adresse[N]=@S
Type doption=11
Longueur
Adresse Source=@S
Adresse Cible=@D
31
Flags
Sauts
Identification

En recevant un paquet CSR Server Query Reply dun Cluster
Head C D , le Serveur met jour sa table MCH : le nud D est
localis dans la cellule du Cluster Head C D . Il vrifie quil na pas
dj trait cette requte en contrlant le numro didentification
de la requte. Si le Serveur a dj trait cette requte, le paquet
est dtruit. Sinon, le Serveur effectue ltape 3a.
4. Rception de la rponse de route : lorsque le nud source S reoit la rponse de route, il met jour son cache et commence lmission des donnes. Si S ne reoit pas de rponse de route, il dclenche
une dcouverte de routes DSR globale. Il diffuse un paquet contenant une option DSR Route Request. Le TTL du paquet IP est
positionn la valeur maximale.
4.2.1.2
Les ruptures de chemin sont dtectes via le mcanisme derreur de route

du DSR (voir partie 1.3.1.2).Lorsquun nud dtecte que le prochain saut est
inaccessible, il envoie un paquet contenant une option DSR Route Error vers
la source du paquet. Les nuds intermdiaires utilisent lerreur de route pour
mettre jour leurs caches de routes.
Les Cluster Heads appliquent un traitement supplmentaire aux erreurs de
route relayes ou reues : ils vrifient si leur chemin vers le Serveur est toujours
valide. Si lerreur de route rend le chemin vers le Serveur invalide, le Cluster Head
applique la procdure Topology Discovery pour retrouver un nouveau chemin
(partie 4.2.2.4).
Lorsque la source du paquet reoit une erreur de route, elle met jour son
cache et cherche une nouvelle route pour acheminer les donnes. Si aucune route
nest disponible dans le cache, le nud source initie une dcouverte de routes
CSR. Le paquet contient une option CSR Route Request et une option DSR
Route Error . Ainsi, le Serveur pourra mettre jour son cache et supprimer le
lien erron de ses tables MCH et CHCH.
4.2.2
Ces procdures servent mettre en place et maintenir larchitecture des

clusters. Pour choisir les chefs de clusters (Cluster Heads et Serveur), nous utilisons une mtrique de densit et une mtrique de mobilit (voir partie 3.2).
Nous avons choisi les mtriques selon diffrents critres. Tout dabord, le calcul
des mtriques ne doit gnrer aucun trafic de contrle supplmentaire. La minimisation du trafic de contrle est en effet un de nos critres pour permettre le
passage lchelle du DSR.
La mtrique de mobilit est base sur la notion de rupture de lien : lorsquun
nud narrive pas transmettre un paquet au prochain saut, il gnre un paquet
DSR contenant une option DSR Route Error . Chaque nud comptabilise le
nombre de paquets DSR Route Error quil gnre. Notre mtrique de mobilit
est donc le nombre de paquets DSR Route Error gnrs.

Une mtrique de densit globale nest calculable quen contrepartie dun
trafic de contrle important. Nous nous sommes donc intresss une mesure
locale de la densit. Nous avons choisi le nombre de voisins estim partir du
cache de routes. Cette mesure est moins prcise que lestimation reposant sur
lchange priodique de messages Hello mais elle est plus conomique en terme
de trafic de contrle.
Dans la suite, les mtriques de mobilit et de densit seront respectivement
notes Mobilit et Densit.
Les mtriques de mobilit et de densit choisies sont utilises pour lire
les chefs de clusters. Les nuds les plus connects et les moins mobiles sont
slectionns.
4.2.2.1
Mise en place du niveau 0-Cell
Chaque nud dbute la procdure de mise en place de la cellule avec un

statut Indfini. Pour mettre en place larchitecture de clusters CSR, chaque
nud doit tout dabord obtenir un statut de Nud ou de Cluster Head.
Procedure GetStatus
La mise en place des cellules est base sur lalgorithme Highest-Connectivity
Degree qui permet de minimiser le nombre de clusters et de rduire ainsi
le trafic de contrle. Cependant, de faon augmenter la stabilit de larchitecture, nous utilisons les mtriques de mobilit et de densit comme
critres dlection.
Un nud utilise la procdure GetStatus pour mettre en place ou pour rtablir larchitecture. Chaque nud possdant un statut Indfini va diffuser
localement un paquet de statut. Le paquet comporte une option CSR
Status.
Loption CSR Status contient le statut du nud (Indfini) et les valeurs de
ses critres dlection (Mobilit et Densit). Le champ OP indique si le
mode de routage CSR est oprationnel. Les trois premiers bits du champ
Type doption sont positionns 011. Nous choisissons un code doption
gal 97 pour loption CSR Status. La variable candidat est positionne
vrai. Une fois le paquet de statut mis, le nud attend pendant une
priode GetStatus.
0
7
Type doption=97
15
Longueur
Statut
OP
Densit
31
Mobilit
En recevant un paquet de statut, chaque nud vrifie son mode de routage

et le cas chant son statut :
mode CSR et statut Indfini : le nud contrle le statut du paquet :
statut du paquet = Cluster Head : le nud prend le statut de Nud
et quitte la procdure.

statut du paquet = Indfini : le nud compare ses critres dlection
avec ceux contenus dans le paquet. Les valeurs de Densit sont compares. En cas dgalit, les valeurs de Mobilit sont compares. En
cas dgalit sur les deux critres, le plus petit identifiant est prfr.
Si les critres du paquet sont meilleurs, le nud positionne sa variable
candidat faux.
mode CSR et statut diffrent de Indfini : le nud dtruit le paquet.
mode DSR : le nud contrle ses critres dadaptation conformment
au processus de changement de mode (voir partie 4.3). Si les valeurs de
Mobilit et de Densit permettent le passage en CSR, le nud dbute
la procdure GetStatus.
mode DSR natif : les nuds qui ne supportent pas lextension CSR
dtruisent le paquet.
A lexpiration du timer GetStatus :
si le nud a localement les meilleurs critres dlection (candidat =
vrai), il prend le statut de Cluster Head. Il diffuse alors dans sa cellule
un paquet comportant une option CSR Status. Loption CSR Status
contient le statut du nud (Cluster Head) et les valeurs de ses critres
dlection (Mobilit et Densit).
si le nud na pas les meilleurs critres dlection (candidat = faux),
il arme une temporisation en attendant un paquet de statut provenant
dun Cluster Head :
si un paquet de statut provenant dun Cluster Head est reu, le nud
prend le statut de Nud et quitte la procdure.
lexpiration de la temporisation, si le nud na pas reu de paquet
provenant dun Cluster Head, il se dclare lui-mme Cluster Head. Il
diffuse alors dans sa cellule un paquet de statut indiquant son rle.
4.2.2.2
Maintenance du niveau 0-Cell
Chaque Cluster Head diffuse priodiquement un paquet CSR Status pour

maintenir sa cellule. Le timer de maintenance est ajust selon la Mobilit. Si la
Mobilit augmente, le Cluster Head diminue la valeur de son timer de maintenance. Si la mobilit diminue, le Cluster Head augmente la valeur de son timer.
Le paquet de statut contient, outre le statut et les mtriques, la valeur du timer
de maintenance.
Lorsquun Nud reoit un paquet de statut dun Cluster Head, il rarme
son timer de Statut : la valeur du timer de Statut est gale 2 fois la valeur du
timer de maintenance pour tolrer la perte dun paquet de Statut. Si un Nud
na pas reu de paquet provenant dun Cluster Head lexpiration de son timer
de statut, il prend le statut Indfini et applique la procdure GetStatus.
Nous utilisons lalgorithme de contrle des Cluster Heads appel LCC (Least
Cluster Change) qui a t dtaill dans la partie 3.4.3. Si un Cluster Head reoit
un paquet de statut provenant dun autre Cluster Head, il compare sa Densit
avec celle contenue dans le paquet. En cas dgalit sur les Densits, les valeurs
Fig. 4.3 Procdure denregistrement global

de Mobilit sont compares. En cas dgalit sur les deux critres, le plus petit
identifiant est prfr :
si le Cluster Head possde des critres plus faibles que ceux du paquet, il
abandonne son rle de Cluster Head et prend le statut de Nud.
si le Cluster Head possde des critres plus forts que ceux du paquet, il
attend lexpiration de son timer de maintenance pour diffuser un paquet
de statut.
Lalgorithme de contrle LCC assure que les Cluster Heads sont loigns dau
moins 2 sauts.
4.2.2.3
Mise en place du niveau 1-Server
Nous dcrivons ici les procdures qui permettent de mettre en place le niveau de cluster 1-Server. Seuls les Cluster Heads et le Serveur participent
ces procdures de manire active. Les Nuds CSR et les nuds DSR natifs se
contentent de relayer les paquets si ncessaire.
Enregistrement global des Cluster Heads
Lorsquun nud est lu Cluster Head lissue de la procdure GetStatus,
il doit senregistrer auprs du Serveur (Figure 4.3). Cette procdure a

plusieurs objectifs :
le Cluster Head peut vrifier la prsence du Serveur.
il obtient un chemin vers le Serveur.
le Serveur peut localiser le Cluster Head par rapport ses Cluster Heads
voisins. Les Cluster Heads voisins dun Cluster Head Ci sont les Cluster
Heads situs 2 ou 3 sauts du Cluster Head Ci .
Le Cluster Head C diffuse localement un paquet comportant une option
DSR Route Request et une option CSR Registration Request. Sur
la Figure 4.3, le Cluster Head A diffuse localement une requte denregistrement (tape 1).
La destination cible de loption DSR Route Request contient ladresse prdfinie pour identifier le Serveur. Il existe un certain nombre dadresses
IP non routables dans les standards IPv4 et IPv6. Pour IPv4, nous choisissons ladresse ADDR_SRV = 10.0.0.0 comme adresse prdfinie pour
le Serveur car elle ne sera jamais attribue. Ainsi, lorsquun nud reoit
une option DSR Route Request ayant ADDR_SRV comme adresse destination cible, nous savons que le nud ne rpondra pas et se contentera
de relayer la requte.
Loption CSR Registration Request indique que le Cluster Head attend
une rponse de la part du Serveur (champ Reply = vrai) et rpte le
champ Identification de loption DSR Route Request . Les trois premiers bits du champ Type doption de loption CSR Registration Request sont positionns 000. Ainsi, les Nuds CSR et les nuds DSR
natifs se contentent de relayer le paquet conformment loption DSR
Route Request et ne traitent pas loption CSR Registration Request. Nous
choisissons un code doption gal 12. Le paquet denregistrement vise
atteindre les Cluster Heads voisins. Le TTL du paquet IP est fix 3 car
les Cluster Heads sont loigns dau plus 3 sauts.
0
7
15
Type doption=2
Longueur
Identification
Adresse Cible = ADDR_SRV
Type doption=12
Reply
Longueur
31
Identification
Lorsquun Cluster Head voisin D reoit un paquet CSR Registration Request de C :

sil ne possde pas de route jusquau Serveur : il dtruit le paquet.
sil possde une route jusquau Serveur : il va relayer la demande denregistrement jusquau Serveur. Pour cela, il concatne la route entre
C et D avec la route entre D et le Serveur. La route entre C et D
est construite lors du relayage de la demande denregistrement grce
loption Route Request. D obtient la route jusquau Serveur lors de la
rponse denregistrement.

Le Cluster Head D met un paquet comportant une option DSR Source
Route et une option CSR Registration Request. Loption DSR
Source Route contient la route entre C et le Serveur. Loption CSR
Registration Request nest pas modifie. Sur la Figure 4.3, les Cluster
Heads B et C relaient la requte de A (tape 2).
0
15
Longueur
Flags
Adresse[1]=C C
Adresse[2]=Ni
Adresse[1]=C D
..............
Adresse[N]=Adresse_Serveur
Type doption=7
Type doption=12
Reply
Longueur
31
Sauts
Identification
Lorsque le Serveur reoit un paquet Registration Request provenant de

C :
il met jour sa table CHCH en insrant si ncessaire le Cluster Head
C. Il rajoute aussi le lien existant entre les Cluster Heads C et D.
il met jour sa table MCH en insrant si ncessaire le Cluster Head C.
Il rajoute le nud Ni dans les cellules de C et D.
il vrifie le numro didentification contenu dans loption CSR Registration Request. Sil na jamais trait cette requte, il rpond la demande denregistrement. Il envoie un paquet comportant une option
DSR Source Route et une option CSR Registration Reply vers
C. Sur la Figure 4.3, le Serveur S rpond la requte denregistrement
de A (tape 3).Nous choisissons un code doption gal 13 pour loption CSR Registration Reply. Loption DSR Source Route contient la
route entre le Serveur et C. Le champ Identification de loption CSR
Registration Reply reprend le numro didentification du paquet CSR
Registration Request. Le champ OP indique si le mode de routage
CSR est oprationnel.
0
7
15
Type doption=7
Longueur
Flags
Adresse[1]=Adresse_Serveur
Adresse[2]
..............
Adresse[N]=C C
Type doption=13
OP
Longueur
31
Sauts
Identification

Lorsque le Cluster Head C reoit une option CSR Registration Reply, il
mmorise la route jusquau Serveur ainsi que la date de rception de la
rponse.
Le Cluster Head C dtecte lchec de la procdure denregistrement global
sur expiration de timer. 3 checs denregistrement conscutifs sont interprts comme une absence de Serveur. Le Cluster Head dclenche alors
une lection de Serveur.
Election du Serveur
Le Serveur est lu parmi les Cluster Heads : le choix du Serveur est bas
sur la Densit et la Mobilit. Au dbut de la procdure, chaque Cluster
Head initialise ses variables :
Densit_candidat et Mobilit_candidat avec ses valeurs de Densit et
de Mobilit
Adresse_candidat avec son adresse
Lorsquun Cluster Head C i dclenche une lection de Serveur, il diffuse
un paquet comportant une option DSR Route Request et une option
CSR Election et arme son timer dlection. La destination cible de loption DSR Route Request contient ladresse prdfinie pour identifier le
Serveur, ADDR_SRV. Les trois premiers bits du champ Type doption
de loption CSR Election sont positionns 000. Ainsi, les Nuds CSR
et les nuds DSR natifs se contentent de relayer le paquet conformment
loption DSR Route Request et ne traitent pas loption CSR Election.
Nous choisissons un code doption gal 14 pour loption CSR Election.
Loption CSR Election contient ladresse, la Densit et la Mobilit du candidat. Le TTL du paquet IP est positionn 3 car on cherche atteindre
les Cluster Heads voisins. Les Cluster Heads voisins relaieront le paquet
CSR Election si ncessaire. Le trafic de contrle ncessaire llection du
Serveur est ainsi rduit.
0
7
15
Type doption=2
Longueur
Identification
Type doption=14
Longueur
Densit
Adresse Candidat = C i
31
Mobilit
Lorsquun Cluster Head C j reoit un paquet dlection, il vrifie le numro

didentification. Si le paquet a dj t trait, il le supprime. Sinon, il
compare la date de rception de la dernire CSR Registration Reply du
Serveur avec la date courante. Si la diffrence est infrieure la valeur
du timer de maintenance, le Cluster Head ne participe pas llection et
dtruit le paquet. Sinon, il arme son timer dlection si celui-ci est inactif
(premier paquet Election reu). Il compare sa variable Densit_candidat
avec la Densit contenue dans le paquet. En cas dgalit, les valeurs de

Mobilit_candidat et de Mobilit sont compares. En cas dgalit sur les
deux critres, le plus petit identifiant entre la variable Adresse_candidat
et ladresse du candidat du paquet CSR Election est prfr.
Si le Cluster Head possde des meilleurs critres dlection, il supprime
le paquet.
Si le candidat du paquet est meilleur, le Cluster Head C j met jour ses
variables Densit_candidat, Mobilit_candidat et Adresse_candidat
avec les valeurs contenues dans le paquet CSR Election et rarme son
timer dlection. Le Cluster Head mmorise aussi la route jusquau candidat qui est contenue dans loption DSR Route Request.
Une fois ses variables mises jour, le Cluster Head va propager le paquet CSR Election. Il ajoute son adresse dans le champ Route de
loption DSR Route Request et positionne le TTL du paquet 3 pour
relayer le paquet dlection aux Cluster Heads voisins. Le champ Route de loption DSR Route Request contient les adresses des nuds qui
ont relay la requte.
0
7
15
Type doption=2
Longueur
Identification
Adresse[1]=N1
Adresse[2]=C j
Type doption=14
Longueur
Densit
Adresse Candidat = C i
31
Mobilit
Lorsque son timer dlection expire, chaque Cluster Head compare lAdresse_candidat
avec son adresse :
si les adresses sont diffrentes, le Cluster Head applique la procdure
denregistrement global dcrite prcdemment.
si les adresses sont identiques, le Cluster Head se dclare Serveur. Il diffuse alors dans le rseau un paquet comportant une option DSR Route
Request et une option CSR Server Presence. La destination cible
de loption DSR Route Request contient ladresse prdfinie pour identifier le Serveur, ADDR_SRV. Les trois premiers bits du champ Type
doption de loption CSR Server Presence sont positionns 000. Ainsi,
les Nuds CSR et les nuds DSR natifs se contentent de relayer le paquet conformment loption Route Request et ne traitent pas loption
CSR Server Presence. Nous choisissons un code doption gal 15 pour
loption CSR Server Presence. Loption CSR Server Presence contient
ladresse, la Densit et la Mobilit du Serveur. Le TTL du paquet IP
est positionn 3 pour atteindre les Cluster Heads voisins.

0
7
15
31
Type doption=2
Longueur
Identification
Type doption=15
Longueur
Densit
Mobilit
Adresse Serveur
Le paquet de prsence sert rsoudre les conflits dans lventualit o

plusieurs Cluster Heads se dclarent Serveur. En effet, si la connectivit
nest pas maintenue pendant la dure de llection, il est possible que le
paquet dlection du meilleur candidat natteigne pas tous les Cluster
Heads.
Lorsquun Cluster Head reoit un paquet CSR Server Presence, il compare sa variable Adresse_candidat avec lAdresse du Serveur contenue
dans le paquet :
si elles sont identiques, le Cluster Head relaie le paquet de prsence
comme un paquet dlection. Il ajoute son adresse dans le champ
Route de loption DSR Route Request et positionne le TTL du
paquet 3. Loption Server Presence nest pas modifie.
sinon, les critres dlection sont compars. Si le candidat du paquet est meilleur, le Cluster Head met jour ses variables Densit_candidat, Mobilit_candidat et Adresse_candidat avec les valeurs contenues dans le paquet CSR Server Presence. Il applique la
procdure denregistrement global pour se signaler son nouveau Serveur et relaie le paquet Server Presence. Il ajoute son adresse dans le
champ Route de loption DSR Route Request et positionne le TTL
du paquet 3. Loption CSR Server Presence nest pas modifie.
Lorsquun Serveur S1 reoit un paquet CSR Server Presence de S2 , il
compare les critres dlection du paquet avec les siens. Si ses critres
dlection sont meilleurs, S1 diffuse son tour un paquet CSR Server
Presence. Sinon, S1 abandonne son rle de Serveur et devient Cluster
Head. Il relaie le paquet CSR Server Presence et senregistre auprs du
Serveur S2 .
4.2.2.4
Maintenance du niveau 1-Server
Enregistrement Direct
Priodiquement, le Cluster Head senregistre directement auprs du Serveur. Il envoie un paquet comportant une option DSR Source Route et
une option CSR Registration Request. Le champ Route de loption
DSR Source Route contient le chemin jusquau Serveur. Le champ Reply
de loption CSR Registration Request est positionn vrai.

0
15
Longueur
Flags
Adresse[1]=C
Adresse[2]
..............
Adresse[N]=Adresse_Serveur
Type doption=7
Type doption=12
Reply
Longueur
31
Sauts
Identification
Lenregistrement direct permet de sassurer de la validit de la route jusquau Serveur et de la prsence du Serveur. Lchec denregistrement direct
est dtect sur expiration de timer. Aprs 2 checs denregistrement direct,
le Cluster Head applique la procdure Dcouverte de Topologie.
Si le Cluster Head reoit un paquet DSR Route Error conscutif sa
requte denregistrement, cela signifie que la route vers le Serveur nest
plus valide. Le Cluster Head applique alors la procdure Dcouverte de
Topologie pour retrouver un chemin vers le Serveur.
Dcouverte de Topologie
Priodiquement, chaque Cluster Head applique la procdure denregistrement global. De cette manire, le Serveur peut mettre jour ses informations de routage stockes dans ses tables. La dure du timer de dcouverte
de topologie est proportionnelle la dure du timer de maintenance de la
cellule. Le Cluster Head envoie un paquet comportant une option DSR
Route Request et une option CSR Registration Request. Le champ
Reply de loption CSR Registration Request est positionn faux : le
Cluster Head nattend pas de rponse du Serveur.
La procdure Dcouverte de Topologie est aussi utilise pour retrouver
un chemin vers le Serveur. Lorsquun Cluster Head reoit un paquet DSR
Route Error, il vrifie si la route vers le Serveur est toujours valide. Si
la route vers le Serveur nest plus valide, le Cluster Head applique la
procdure denregistrement global. Le paquet denregistrement contient
une option DSR Route Error , une option DSR Route Request et
une option CSR Registration Request. Le Serveur peut mettre jour
ses tables en traitant loption DSR Route Error. Le champ Reply de
loption CSR Registration Request est positionn vrai car le Cluster
Head attend une rponse du Serveur. Ainsi, il obtient un chemin vers le
Serveur lorsquil reoit le paquet Registration Reply.
4.3
Adaptation du mode de routage
Nous avons choisi dadapter le mode de routage en fonction des conditions

de mobilit et de densit du rseau. Les conditions du rseau sont estimes grce
deux mtriques :
notre mtrique de mobilit est le nombre de paquets Route Error gnrs
et sera note Mobilit dans la suite.
notre mtrique de densit est le nombre de voisins estim via le cache de
routes et sera note Densit dans la suite.
La mtrique de mobilit que nous avons choisie est dpendante du protocole
utilis et du trafic de donnes qui transite par le rseau. Ainsi, lestimation de
la mobilit peut tre errone aprs une longue priode dinactivit de trafic et
ncessite une priode dajustement. Un travail sur les mtriques de mobilit
pourrait permettre de trouver des mtriques plus fiables que celle que nous
utilisons. Dailleurs, une de nos perspectives de recherche consiste observer
limpact du changement de dfinition des mtriques sur le comportement de
lextension CSR afin doptimiser les performances de routage de CSR.
La mtrique que nous utilisons prsente lavantage dtre simple calculer
et ne requiert pas de trafic de contrle supplmentaire. Elle permet de montrer,
malg ses dfauts, les principes et les avantages de notre mthode.
4.3.1
Changements de mode
Conformment la mthode dadaptation prsente dans le chapitre 3, chaque

nud supportant lextension CSR peut exprimenter 3 modes :
DSR : cest le mode de routage Sans Architecture.
DSR+ : cest le mode Transition Adaptative entre le mode de routage Sans
Architecture et le mode de routage Avec Architecture.
CSR : cest le mode de routage Avec Architecture.
Chaque nud peut changer de mode de routage de manire autonome (voir
Figure 3.3).
Nous prsentons ici les caractristiques du changement de mode qui sont
dpendantes du mode Avec Architecture utilis. Les autres mcanismes de changements de mode sont conformes ceux prsents dans la partie 3.5.2.3.
Calcul des mtriques
Le nud calcule ses mtriques dadaptation quand :
il arme son timer de statut.
il reoit un paquet comportant une option CSR.
Lorsque les mtriques dadaptation sont trs proches des seuils dadaptation, un nud peut changer trs frquemment de mode de routage et osciller entre les deux modes. Pour viter ce comportement, lorsquun nud
change de mode de routage, il arme un timer de stabilit (la valeur de ce
timer est gale trois fois la valeur par dfaut du timer de statut). Jusqu

lexpiration de ce timer, un nud ne peut pas changer de mode mme si
ses mtriques le permettent.
Transitions
Lorsquun nud passe du mode de routage DSR au mode de routage
DSR+, il dclenche les procdures pour mettre en place larchitecture de
clustering :
tout dabord, le nud utilise la procdure GetStatus pour obtenir un
statut de Nud CSR ou de Cluster Head.
les Cluster Heads senregistrent auprs du Serveur. Les Cluster Heads
peuvent dclencher la procdure dlection du Serveur si celui-ci est inaccessible.
Si les procdures de clustering russissent, le nud passe en mode CSR :
une fois lu, le Serveur arme un timer et attend les demandes denregistrement des Cluster Heads. Lorsque le timer expire, le Serveur est
oprationnel pour rpondre aux requtes de route. En effet, les demandes denregistrement fournissent les informations de routage ncessaires pour remplir les tables du Serveur. Lorsquil rpond aux demandes
denregistrement, le Serveur indique sil est oprationnel dans la rponse
denregistrement (champ OP dans loption CSR Registration Reply
positionn 1).
lorsquun Cluster Head reoit une rponse denregistrement, il contrle
le champ OP de loption CSR Registration Reply .
Si le champ OP indique que le Serveur est oprationnel, le Cluster
Head positionne sa variable Csr_Routing vrai. Il positionnera le
champ OP de loption CSR Status 1 dans le prochain paquet de
maintenance quil mettra.
Si le Serveur nest pas oprationnel, le Cluster Head arme un timer et
passe en mode oprationnel lexpiration de ce timer. Il positionne alors
sa variable Csr_Routing vrai : il peut dsormais relayer les requtes
de route CSR vers le Serveur.
un Nud passe en mode CSR lorsquil reoit un paquet comportant
une option CSR Status dont le champ OP est positionn 1. Il peut
alors faire des requtes de route CSR.
Si les procdures de clustering chouent, le nud passe en mode DSR :
si le Serveur ne possde aucun Cluster Head enregistr dans ses tables
aprs 3 expirations conscutives du timer denregistrement, il abandonne
son rle et passe en mode DSR. En effet, cela signifie quil ny a pas de
Cluster Head ou que la mobilit des nuds empche leur enregistrement.
aprs 3 checs de la procdure dlection du Serveur, le Cluster Head
abandonne son rle et passe en mode DSR.
si un Nud na pas reu de paquet CSR Status avec le champ OP
positionn 1 au bout de 3 paquets CSR Status conscutifs, il passe
en mode DSR.
4.4
Conclusion
Dans ce chapitre, nous avons appliqu notre mthode dadaptation du mode

de routage. Pour cela, nous avons propos et dfini une extension de routage
hirarchique en nous basant sur le protocole DSR. Cette extension, que nous
appelons CSR, sappuie sur une architecture de clusters pour raliser un routage
hirarchique. Elle adapte son mode de routage selon la mobilit et la densit du
rseau.
Nous avons spcifi lensemble des procdures de routage et de clustering de
lextension CSR. Nous avons aussi indiqu le moyen dimplanter ces procdures
en dfinissant le format des diffrents paquets.
Dans le chapitre suivant, nous tudierons les performances de lextension
CSR pour montrer son intrt par rapport aux protocoles prconiss par lIETF.
Chapitre 5
Evaluation de loptimisation
CSR
Sommaire
5.1
5.2
5.3
5.4
5.5
Validation des principes CSR . . . . . . . . . . . . 103

5.1.1 Optimisation du routage . . . . . . . . . . . . . . . . 103
5.1.2 Procdures de clustering . . . . . . . . . . . . . . . . 105
Comparaison de performances de lextension CSR
avec les protocoles de 1re gnration . . . . . . 109
5.2.1 Modle de simulation . . . . . . . . . . . . . . . . . 109
5.2.2 Intrt du changement adaptatif du mode de routage 109
5.2.3 Influence de la densit et de la mobilit . . . . . . . 111
5.2.4 Influence de la charge de trafic . . . . . . . . . . . . 113
5.2.5 Dure de la dcouverte de route . . . . . . . . . . . . 114
Comparaison de performances de lextension CSR
avec un protocole de 2me gnration . . . . . . . 116
5.3.1 Modle de simulation . . . . . . . . . . . . . . . . . 116
5.3.2 Influence de la densit . . . . . . . . . . . . . . . . . 116
5.3.3 Influence de la mobilit . . . . . . . . . . . . . . . . 118
Etude de la stabilit du changement de mode adaptatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.4.1 Temps pass dans chacun des modes . . . . . . . . . 122
5.4.2 Dure de la transition . . . . . . . . . . . . . . . . . 126
Conclusion . . . . . . . . . . . . . . . . . . . . . . . 128
Dans le chapitre prcdent, nous avons montr la faisabilit de notre mthode

dadaptation en dfinissant lextension CSR. Dans ce chapitre, nous montrons
le gain de performances apport par notre extension auto-adaptative.
102
CHAPITRE 5. EVALUATION DE LOPTIMISATION CSR
103
Nous avons valu les performances de lextension que nous proposons en

quatre tapes :
1. tout dabord, nous avons valid les principes de lextension CSR (partie
5.1) :
loptimisation du routage en sappuyant sur une architecture de clusters.
la mise en place et la maintenance de larchitecture
2. nous avons ensuite compar notre extension avec les protocoles de 1re
gnration qui sont standardiss ce jour : DSR et AODV. Cette tude
vise montrer que notre optimisation amliore le passage lchelle du
routage dans les rseaux ad hoc (partie 5.2).
3. nous avons par la suite compar notre extension avec le protocole de 2me
gnration OLSR. OLSR est un des protocoles de routage les plus utiliss
actuellement. Il est de plus normalis lIETF.
4. notre extension sappuie sur un changement adaptatif du mode de routage.
La stabilit et lefficacit de cette adaptation sont analyses dans la partie
5.4.
Dans la partie 2.2, nous avons dcrit en dtail deux modles de mobilit : Random Waypoint et RPGM. Ces deux modles ont t utiliss dans notre tude.
Cependant, le modle RPGM a t utilis uniquement pour valider le comportement global de lextension CSR. Il permet de simuler des scnarii de mobilit
plus prvisibles grce lutilisation des points de contrle. Ainsi, nous avons
pu observer les performances de CSR par rapport au comportement que nous
attendions.
5.1
Validation des principes CSR
Dans cette partie, nous validons les principes de lextension CSR
5.1.1
Optimisation du routage
5.1.1.1
Modle de simulation
Nous avons utilis lenvironnement de simulation QNAP2 pour valider loptimisation du routage [VP84]. QNAP2 est un environnement de simulation bas
sur la thorie des files dattente. Nous lavons choisi car il permet une modlisation rapide de notre problme. Ainsi, nous pouvons valider le principe de la
dcouverte de routes CSR.
Nous avons choisi des sources de trafic de type CBR (Constant Bit Rate). La
mobilit des destinations est modlise par une probabilit de mouvement : la
destination est accessible selon cette probabilit. Chaque point calcul reprsente
une moyenne sur 10 simulations. Nous avons calcul un intervalle de confiance
95% pour chacun des critres de performances observs : les intervalles relatifs
sont infrieurs 1%.
104
Nous dfinissons un degr de connectivit : il correspond au nombre de Cluster Heads voisins que chaque Cluster Head peut atteindre. Le degr de connectivit moyen nous permet de caractriser le nombre de chemins distincts dans
une topologie donne. Deux topologies diffrentes ont t utilises pour notre
valuation : la topologie connectivit faible a un degr de connectivit moyen
gal 2 et la topologie connectivit forte a un degr de connectivit moyen
gal 4.
Dans notre tude, le nombre de nuds par cluster prend les valeurs 3, 4 et
5. Tous les liens sont considrs bidirectionnels.
Pour comparer le protocole DSR et lextension CSR, nous avons observ les
mtriques suivantes :
T raf ic de contr
Donn
Donn
ees
Ef f icacit
e : elle est dfinie comme Donnees+T
raf ic de contr
ole .
5.1.1.2
Rsultats
Le trafic de contrle dploy par chacune des procdures de dcouverte de

routes varie en fonction des conditions du rseau (mobilit, densit, . . .). Parmi
celles-ci, nous nous sommes intresss la densit de nuds et au nombre de
chemins distincts dans la topologie.
Pour montrer linfluence de ces dynamiques du rseau, nous avons effectu
des simulations en utilisant deux topologies diffrentes et en faisant varier la
CSR
densit de nuds. La Figure 5.1 montre le rapport des efficacits DSR
en fonction de la mobilit.
Nous observons tout dabord le protocole DSR natif a de meilleures performances avec une topologie faible connectivit et une densit faible. Cependant, lextension CSR devient plus efficace lorsque la densit de nuds augmente. Lamlioration observe est plus importante encore sur la topologie
forte connectivit.
La procdure de dcouverte de routes DSR repose sur linondation du rseau avec des paquets de requtes. Ainsi, le trafic de contrle ncessaire une
dcouverte de route est de lordre de n, o n est le nombre total de nuds dans
le rseau. En effet, chaque nud, except la destination recherche, va diffuser
le paquet de requte.
La procdure de dcouverte de route CSR sappuie sur linterrogation du
Serveur. Le trafic de contrle ncessaire une dcouverte de route dpend du
nombre de Cluster Heads et de la distance moyenne, en nombre de sauts, entre
une station et le Serveur.
La topologie connectivit faible possde peu de chemins distincts. Ainsi,
faible densit, DSR et CSR ont des performances voisines. Cependant, lorsque
la densit de nuds augmente :
le trafic de contrle du CSR naugmente pas car le nombre de Cluster
Heads et la distance moyenne Nud-Serveur restent constants
105
densit de nuds : < <

Fig. 5.1 Rapports des efficacits sur 2 topologies pour diffrentes densits
le trafic de contrle du DSR augmente car le nombre total de nuds n
augmente
Linfluence du nombre de chemins distincts est illustre par les rsultats obtenus
sur la topologie connectivit forte. Lorsque le nombre de chemins distincts
augmente, lutilisation de linondation est plus coteuse en trafic de contrle.
Lutilisation du cache central du Serveur permet aussi une minimisation du
trafic de contrle lorsque le nombre de chemins distincts est grand.
Lutilisation de loptimisation de routage CSR savre plus intressante sur
des configurations de rseau denses.
5.1.2
Nous valuons dans cette partie le trafic de contrle gnr par les procdures
de clustering. Cela permet de dterminer les conditions de rseau dans lesquelles
lutilisation de lextension CSR est intressante.
5.1.2.1
Modle de simulation

valuer les procdures de clustering. Au niveau MAC, nous utilisons le modle
La porte de transmission de chaque nud est de 150 m.
la dure de simulation est fixe 1000s.
106

Le modle de mobilit est Random Waypoint. La vitesse de dplacements
des nuds varie de 1 m/s 20 m/s et nous avons utilis un temps de pause
de 30s.
dmission est de 4 paquets/s.
Pour valuer les procdures de clustering, nous calculons la mtrique suivante :
T raf ic de contr
Chaque point calcul reprsente une moyenne sur 10 scnarii de mobilit diffrents.
5.1.2.2
Rsultats
Notre tude se concentre sur le trafic de contrle gnr par les procdures
de mise en place et de maintenance de larchitecture.
La Figure 5.2 montre le trafic de contrle gnr par les procdures de niveau 0-Cell en fonction de la vitesse des nuds. Nous observons le trafic de
contrle pour 3 densits de nuds diffrentes. Pour permettre la comparaison,
nous considrons le trafic de contrle moyen par nud.
Tout dabord, on remarque que le trafic de contrle par nud reste quasiment
constant en fonction de la mobilit, quelle que soit la densit considre. Cela
montre que les cellules restent relativement stables par rapport la mobilit des
nuds.
Nous pouvons constater que le trafic de contrle ncessaire ltablissement
et la maintenance de larchitecture diminue lorsque la densit de nuds augmente : le gain est de 50% quand on passe de 50 100 nuds et de 20% lorsquon
passe de 100 150 nuds.
La mise en place et la maintenance des cellules ncessitent moins de trafic
de contrle lorsque la densit de nuds augmente.
La Figure 5.3 prsente le trafic de contrle gnr par la procdure dlection
du Serveur en fonction de la densit de nuds. Les rsultats ont t obtenus avec
une vitesse de dplacement moyenne (10 m/s). Le trafic de contrle introduit
par llection du Serveur diminue lorsque la densit de nuds augmente. Cela
confirme le rsultat obtenu prcdemment : la mise en place et la maintenance
de larchitecture est plus avantageuse dans des conditions de forte densit de
nuds.
Nous avons observ le trafic de contrle gnr par la procdure dlection
du Serveur avec des conditions de mobilit varies et nous avons obtenu la mme
tendance : llection du Serveur est ralise rapidement par rapport la mobilit
des nuds. Ainsi, la mobilit des nuds naffecte pas de manire importante la
procdure dlection.
107
overhead of 0cell cluster formation and maintenance per node as a function of mobility
60
50 nodes
100 nodes
150 nodes
50
overhead per node
40
30
20
10
10
max speed
12
14
16
18
20
Fig. 5.2 Trafic de contrle par nud pour les procdures de niveau 0-Cell
108
2.5
overhead per node
1.5
0.5
20
40
60
80
100
120
140
160
180
200
density in number of nodes
Fig. 5.3 Trafic de contrle par nud pour la procdure dlection du Serveur
5.2
109
Comparaison de performances de lextension

CSR avec les protocoles de 1re gnration
Dans cette partie, nous considrons lensemble des procdures de routage et

de clustering du CSR. Nous comparons les protocoles de 1re gnration DSR et
AODV avec lextension CSR sous diffrentes conditions de mobilit, de densit
et de charge de trafic.
5.2.1
Modle de simulation

effectuer notre tude de performances. Nous utilisons les implantations des protocoles DSR et AODV intgres ns2. Au niveau MAC, nous utilisons le modle
des nuds varie de 1 m/s 20 m/s et nous avons utilis des temps de
pause de 100, 200, 300, 400 et 500s.
dmission est de 4 paquets/s. Nous avons effectu des simulations pour
10 et 20 sources de trafic.
Pour comparer les performances relatives des protocoles, nous calculons les mtriques suivantes :
T raf ic de contr
Donn
ees
Charge de donn
ees normalis
ic de contr
ole .
protocole (voir partie 2.1.2).
Lanalyse du comportement relatif du DSR par rapport AODV est expose
dans la partie 2.3.3 et ne sera pas reprise dans cette partie.
5.2.2
Intrt du changement adaptatif du mode de routage
Nous avons tout dabord vrifi lintrt du changement adaptatif du mode

de routage. Pour cela, nous considrons deux versions de lextension CSR :
NA-CSR (Non Adaptive CSR) : cette version implante toutes les procdures CSR except le changement adaptatif du mode de routage. Les
Figure 5.4: Rapport
Donn
ees
T raf ic de contr
ole
110
pour 10 connexions
nuds restent en mode CSR quelles que soient les conditions de Mobilit
et de Densit.
A-CSR (Adaptive CSR) : cette version implante toutes les procdures CSR
y compris le changement adaptatif du mode de routage. Des seuils de changement de mode pour chaque mtrique dadaptation ont t dfinis dans la
partie 4.3.1. Notre mtrique de Mobilit est le nombre derreurs de route
gnres et notre mtrique de Densit est le nombre de voisins. Les valeurs
des seuils sont les suivantes : Mf aible = 2, Mf orte = 4, Df aible = 2 et
Df orte = 5 .
La Figure 5.4 montre la charge de donnes normalise en fonction de la
densit de nuds pour les protocoles DSR et AODV et pour les versions NACSR et A-CSR de lextension CSR. 10 connexions sont mises en place. Chaque
point calcul reprsente une moyenne sur 50 scnarii de mobilit (10 scnarii
pour chaque temps de pause).
Pour une densit de 50 nuds, NA-CSR est le moins performant : la densit
de nuds est trop faible pour utiliser un protocole hirarchique. Les performances de A-CSR sont trs proches de celles du protocole DSR : les simulations
montrent que la majorit des nuds ont bascul en mode de routage DSR.
Cependant, certains Nuds CSR dtectent des conditions locales favorables
un changement de mode (DSR CSR ). Ce comportement gnre un trafic
de contrle supplmentaire qui explique que les performances de A-CSR sont
lgrement infrieures celles du DSR (0,05% dcart relatif).
Pour une densit de 100 nuds, les performances de NA-CSR sont meilleures
que celles dAODV mais restent infrieures celles de DSR et A-CSR. Ces
111
derniers ont des charges de donnes normalises proches mme si DSR reste
suprieur (0,09 % dcart relatif).
Pour une densit de 150 nuds, NA-CSR et A-CSR prsentent de meilleures
performances que AODV et DSR. Cela indique que les conditions de rseau en
terme de densit sont plus favorables un routage hirarchique qu un routage
plat : les versions de lextension CSR passent mieux lchelle par rapport
la densit de nuds. Les performances dA-CSR sont lgrement infrieures
celles de NA-CSR mais largement suprieures celles du DSR (50 % dcart
relatif).
Nous pouvons remarquer que la charge de donnes normalise dA-CSR est
toujours comprise entre celles de NA-CSR et du DSR. NA-CSR et DSR reprsentent les deux comportements extrmes : routage purement hirarchique et
routage purement plat. De plus, A-CSR a toujours un comportement proche du
mode de routage le plus performant quelle que soit la densit : DSR pour 50 et
100 nuds, NA-CSR pour 150 nuds.
Les simulations montrent que A-CSR russit dtecter les conditions de
rseau et adapter dynamiquement son mode de routage pour raliser de
meilleures performances.
Dans la suite, nous tudierons plus prcisement les performances de la version
A-CSR que nous notons CSR.
5.2.3
Influence de la densit et de la mobilit
La Figure 5.5 prsente la charge de donnes normalise en fonction du temps

de pause (paramtre de mobilit). Le critre de performance est calcul sur diffrentes configurations de densit (50, 100 et 150 nuds). Chaque point calcul
reprsente une moyenne sur 10 scnarii de mobilit. Nous utilisons 10 connexions
pour cet ensemble de simulations.
Pour une densit de 50 nuds, DSR et CSR ont des performances trs
proches (Figure 5.5(a)). La densit est faible et la majorit des Nuds CSR restent en mode de routage DSR. Lcart le plus grand se produit pour la mobilit
la plus faible (temps de pause = 500s) : les conditions de mobilit sont adquates et les Nuds CSR qui dtectent une densit suffisante changent de mode
(DSR CSR ). Ces changements de mode gnrent un trafic de contrle supplmentaire. Lorsque la mobilit augmente, les conditions de rseau sont moins
favorables un changement de mode : il y a moins de Nuds CSR qui basculent
en mode CSR et lcart entre DSR et CSR est rduit.
112
(a) 50 nuds
(b) 100 nuds
(c) 150 nuds
Figure 5.5: Rapport

sits de nuds
Donn
ees
T raf ic de contr
ole
Figure 5.6: Rapport

100 nuds
Donn
ees
T raf ic de contr
ole
113
pour 20 connexions pour une densit de
Nous observons le mme comportement pour une densit de 100 nuds (Figure 5.5(b)). DSR et CSR ont des comportements similaires et lcart diminue
lorsque la mobilit augmente. La densit de nuds est dsormais plus favorable
un routage hirarchique. Cependant, le gain de performance d loptimisation de routage CSR ne compense pas compltement le cot de la mise en place
et de la maintenance de larchitecture de clusters car le nombre de connexions
est faible et la procdure de dcouverte de routes est peu utilise.
Pour une densit de 150 nuds, CSR prsente de meilleures performances
que DSR ou AODV mme faible mobilit (Figure 5.5(c)). Les conditions de
densit sont plus favorables un routage hirarchique qu un routage plat :
la majorit des Nuds CSR basculent en mode de routage CSR. Lcart de
performances entre CSR et DSR augmente avec la mobilit : une forte mobilit
entraine un plus grand nombre de requtes de routes. Le gain de performance
lie loptimisation de routage CSR est alors plus visible.
5.2.4
Influence de la charge de trafic
Nous avons compar les performances relatives des protocoles DSR, AODV
et de lextension CSR lorsque la charge de trafic augmente. Le nombre de
connexions est dsormais fix 20. La Figure 5.6 montre la charge de donnes
normalise en fonction du temps de pause pour une densit de 100 nuds.
Lextension CSR prsente de meilleures performances que les protocoles
AODV et DSR. Lcart entre CSR et DSR augmente avec la mobilit. Ces
rsultats doivent tre compars ceux prsents sur la Figure 5.5(b). Avec 10
connexions, DSR prsente une meilleure charge de donnes normalise que lex-
114
tension CSR. Cette tendance sinverse avec 20 connexions : CSR prsente alors
de meilleures performances que DSR. Avec 20 connexions, le nombre de dcouvertes de routes est plus important : le gain de performance d loptimisation
de routage CSR est plus important que le cot de la mise en place et de la
maintenance de larchitecture de clusters. Lintrt de larchitecture de clusters
est plus important lorsque lutilisation de cette architecture augmente.
Lextension CSR passe mieux lchelle que les protocoles DSR et AODV
par rapport la charge de trafic.
5.2.5
Dure de la dcouverte de route
Nous tudions dans cette partie la dure de la dcouverte de route selon le

type de routage utilis. Nous reprenons le modle de simulation dcrit prcdemment. Nous illustrons la dure de dcouverte de routes sur une configuration de
150 noeuds, un temps de pause de 300 secondes et pour 10 sources de trafic.
La Figure 5.7 indique la dure de dcouverte de route selon la procdure
utilise :
dcouverte CSR et rponse directe du Serveur : lorsque le Serveur reoit
la requte de route CSR, la destination recherche est dj localise. Le
Serveur rpond donc directement la source de la requte.
dcouverte CSR et recherche de la destination par le Serveur : lorsque
le Serveur reoit la requte de route CSR, la destination recherche nest
pas localise. Le Serveur interroge donc les Cluster Heads et attend une
rponse de localisation. Il rpond alors la source de la requte.
dcouverte DSR : la source inonde le rseau avec des paquets de requte
et attend la rponse de route de la destination recherche.
Nous constatons tout dabord que la rponse directe est en moyenne beaucoup
plus rapide que les deux autres types de recherche. Lacheminement de la requte
et de la rponse se droule en mode unicast : le mcanisme de back-off est moins
souvent activ que dans le cas de la diffusion. Ce type de recherche est aussi plus
fiable : en transmission unicast, on peut utiliser un mcanisme de rservation
du medium.
Les dures de dcouverte de route CSR avec recherche et DSR sont voisines.
Il faut cependant noter que la recherche CSR bnficie des avantages de lunicast
et requiert moins de trafic de contrle que la recherche DSR.
Dans notre tude, il apparait que la dcouverte avec rponse CSR directe est
utilise dans 70% des cas, la dcouverte avec recherche CSR dans 20% des cas et
la dcouverte DSR dans les 10% de cas restants. Ce comportement montre que le
Serveur possde une bonne connaissance de la topologie et de la composition des
cellules via les procdures de mise en place et de maintenance de larchitecture.
Ainsi, il na pas recours son mcanisme de recherche dans la majorit des cas.
Cette tude pourrait tre approfondie en sintressant aux mcanismes de
gestion des caches du Serveur et constitue une perspective de poursuite de nos
travaux.
La Figure 5.8 illustre le temps moyen de dcouverte de routes CSR par rapport au DSR. Nous observons que la dure moyenne dune dcouverte de routes
115
Figure 5.7: Dure de la dcouverte de route selon la procdure utilise
Figure 5.8: Dure moyenne des dcouvertes de route DSR et CSR

CSR est largement infrieure celle dune dcouverte DSR. Comme nous lavons
indiqu prcdemment, la dcouverte CSR avec rponse directe du Serveur est
largement plus utilise que la dcouverte avec localisation (70% / 20 %). Grce
lutilisation du mode unicast, la dcouverte de routes CSR est plus rapide que
la dcouverte de routes DSR sur des configurations de rseau denses.
5.3
116
Comparaison de performances de lextension

CSR avec un protocole de 2me gnration
Nous comparons le protocole de 2me gnration OLSR avec lextension CSR

sous diffrentes conditions de mobilit et de densit.
5.3.1
Modle de simulation
Nous reprenons le modle de simulation prsent dans la partie 5.2.1. Nous

utilisons limplantation du protocole OLSR ralise par lINRIA dans le cadre
du projet Hipercom (version oolsr-0.99.15). Nous avons effectu des simulations
pour 10 sources de trafic.
Pour comparer les performances relatives des protocoles, nous calculons les
mtriques suivantes :
T raf ic de contr
Donn
ees
Charge de donn
ees normalis
ic de contr
ole .
protocole.
Donn
ees recues
P acket Delivery Ratio : il est dfini comme Donn
ees emises . Ce critre de
performances constitue une mesure externe de lefficacit du protocole.
5.3.2
Influence de la densit
Les critres de performance sont calculs sur diffrentes configurations de

densit (50, 100 et 150 nuds). Chaque point calcul reprsente une moyenne
sur 50 scnarii de mobilit (10 scnarii pour chaque temps de pause).
La figure 5.9 prsente la charge de donnes normalise en fonction de la
densit de nuds. Lextension CSR prsente de meilleures performances que
ees
OLSR quelle que soit la densit de nuds : son rapport T rafDonn
ic de contr
ole est 2
3 plus grand que celui dOLSR.
OLSR est un protocole purement proactif : il maintient toutes les routes
priodiquement. CSR est une extension hybride (proactive et ractive) du protocole DSR. Ainsi, le trafic de contrle gnr par OLSR est plus important
que celui du CSR. Lcart le plus important se produit sur une configuration
de 50 nuds : les nuds CSR sont principalement en mode de routage DSR
et utilisent des procdures de dcouverte et de maintenance de routes purement ractives. La diffrence se rduit lorsque la densit de nuds augmente
mais les performances internes de CSR restent largement suprieures celles du
protocole OLSR.
La figure 5.10 montre le P acket Delivery Ratio en fonction de la densit
Donn
ees recues
de nuds. Le rapport Donn
ees emises constitue une mesure externe des perfor-
Figure 5.9: Rapport
Donn
ees
T raf ic de contr
ole
117
pour 10 connexions
mances dun protocole : les rsultats obtenus sont rapprocher de ceux obtenus
sur la figure 5.9.
Pour 50 nuds, CSR prsente de meilleures performances quOLSR (le P DR
du CSR est suprieur de 18%). De plus, CSR affiche des performances accrues
tout en consommant moins de bande passante : comme nous lavons vu prcdemment, la charge de donnes normalise du CSR est meilleure que celle
dOLSR (Figure 5.9). Pour 50 nuds, la plupart des nuds CSR sont en mode
de routage DSR qui est plus adapt quOLSR des rseaux de petite taille.
Linondation ponctuelle du rseau est alors la technique de dcouverte de routes
la plus efficace.
Sur une configuration de 100 nuds, les deux protocoles prsentent des P DR
quivalents. Cependant, la charge de donnes normalise du CSR est toujours
meilleure. La densit du rseau augmente et les conditions de rseau sont plus
favorables pour le protocole OLSR. CSR prsente cependant des performances
globales (internes et externes) plus intressantes.
Pour 150 nuds, la tendance sinverse : OLSR prsente de meilleures performances que CSR (le P DR dOLSR est suprieur de 8%). Cependant, en
contrepartie, OLSR consomme plus de 2 fois plus de bande passante. La densit de nuds et la taille de rseau sont particulirement adaptes au protocole
OLSR qui prsente de meilleures performances dans des rseaux denses et de
grande taille [CJ03]. Cependant, lextension CSR possde des performances externes proches de celles dOLSR tout en maintenant une efficacit interne plus
importante.
Figure 5.10: Rapport
5.3.3
Donn
ees recues
Donn
ees emises
118
pour 10 connexions
Influence de la mobilit
Les critres de performances sont calculs sur diffrentes configurations de

densit (50, 100 et 150 nuds). Chaque point calcul reprsente une moyenne
sur 10 scnarii de mobilit.
La Figure 5.11 prsente la charge de donnes normalise en fonction du temps
de pause (paramtre de mobilit).
ees
Pour 50 nuds, le rapport T rafDonn
ic de contr
ole du CSR est meilleur que celui
dOLSR quelle que soit la mobilit (Figure 5.11(a)). Cependant, le comportement des deux protocoles en fonction de la mobilit est diffrent : le trafic de
contrle du CSR augmente avec la mobilit alors que celui dOLSR reste relativement stable. En effet, OLSR est un protocole proactif et sa quantit de
trafic de contrle dploye ne dpend pas de la mobilit. Les nuds CSR sont en
grande majorit en mode de routage DSR qui est purement ractif : lorsque la
mobilit augmente, les ruptures de liens deviennent plus frquentes et les nuds
ont recours plus souvent au mcanisme de dcouverte de routes. Cela explique
pourquoi le trafic de contrle du CSR augmente avec la mobilit.
La mme tendance est observable sur une configuration de 100 nuds (Figure
5.11(b)). La charge de donnes normalise du CSR est toujours meilleure que
celle dOLSR. Cependant, le trafic de contrle dOLSR reste stable tandis que
celui du CSR augmente avec la mobilit. Laugmentation du trafic de contrle
du CSR est moins importante que pour la configuration de 50 nuds. En effet,
le trafic de contrle est partag entre trafic ractif et trafic proactif.
Les rsultats obtenus pour 150 nuds confirment le comportement dj observ sur les deux protocoles.
119
(a) 50 nuds
(b) 100 nuds
(c) 150 nuds

sits de nuds
Donn
ees
T raf ic de contr
ole
120
La figure 5.12 montre le P acket Delivery Ratio en fonction de la mobilit

Donn
ees recues
pour diffrentes densits de nuds. Le rapport Donn
ees emises constitue une
mesure externe des performances dun protocole : les rsultats obtenus sont
rapprocher de ceux obtenus sur la figure 5.11.
Pour 50 nuds, lextension CSR prsente de meilleures performances quOLSR.
La diffrence saccentue avec la mobilit. En effet, la mobilit pose plus de problmes lorsque le comportement du protocole est purement proactif : les informations de routage transmises priodiquement aux nuds OLSR sont plus
souvent errones. CSR affiche aussi de meilleures performances internes comme
nous lavons vu sur les rsultats prcdents.
Une configuration de 100 nuds est plus favorable au protocole OLSR car
la densit de nud est plus importante. Ainsi, le protocole OLSR possde un
meilleur P DR faible mobilit. Cependant, la tendance sinverse lorsque la
mobilit augmente : la diffrence entre les deux algorithmes de routage diminue
et CSR devient meilleur lorsque le temps de pause est infrieur 300s. Le
P DR dOLSR est plus dpendant de la mobilit que celui du protocole CSR.
En effet, ce dernier adapte son mode de routage selon la mobilit. De plus, les
performances internes du CSR sont meilleures que celles dOLSR.
Pour 150 nuds, les conditions de densit sont adaptes un routage pureDonn
ees recues
ment hirarchique : le protocole OLSR prsente un meilleur rapport Donn
ees emises
que CSR. Cependant, comme sur les configurations de densit prcdentes, on
retrouve une diminution de lcart entre les deux algorithmes lorsque la mobilit
augmente. Les P DR sont mme gaux pour un temps de pause de 100s. De plus,
les performances internes du CSR restent meilleures quelle que soit la mobilit.
121
(a) 50 nuds
(b) 100 nuds
(c) 150 nuds

de nuds
Donn
ees recues
Donn
ees emises
pour 10 connexions pour diffrentes densits
5.4
5.4.1
122
Etude de la stabilit du changement de mode

adaptatif
Temps pass dans chacun des modes
Dans cette partie, nous tudions le changement adaptatif du mode de routage

plus en dtail. Nous reprenons le modle de simulation prsent dans la partie
5.2.1.
tudier le changement de mode. Nous utilisons limplantation du protocole DSR
intgre ns2. Au niveau MAC, nous utilisons le modle 802.11 implant par
le groupe Monarch. Nous gardons les valeurs par dfaut des paramtres de ce
modle.
des nuds varie de 1 m/s 20 m/s et nous avons utilis des temps de
pause de 100, 200, 300, 400 et 500s.
dmission est de 4 paquets/s. Nous avons effectu des simulations pour
10 sources de trafic.
Pour valuer la stabilit du changement de mode, nous calculons les mtriques
suivantes :
P ourcentage de temps pass
e en mode DSR : nous additionnons le temps
pass dans le mode de routage DSR pour lensemble des nuds. La mtrique est alors obtenue en divisant la somme du temps pass en mode
DSR par le nombre de
nuds N multipli par le temps de simulation T :
PN 1
t dsri
pourcentageDSR = i=0
.
N T
P ourcentage de temps pass
e en mode CSR : nous additionnons le temps
pass dans le mode de routage CSR pour lensemble des nuds. La mtrique est alors obtenue en divisant la somme du temps pass en mode
CSR par le nombre de
nuds N multipli par le temps de simulation T :
PN 1
i=0 t csri
pourcentageCSR =
.
N T
N ombre de noeuds en mode CSR a
` un instant t : Nous suivons lvolution
au cours du temps du nombre de nuds en mode CSR. La mtrique est
obtenue en divisant le nombre de nuds en mode CSR par le nombre total de nuds. Ainsi, nous pouvons comparer les rsultats obtenus sur des
densits de nuds diffrentes.
La Figure 5.13 montre le pourcentage de temps pass par un nud dans
chacun des modes de routage en fonction de la densit de nuds. 10 connexions
sont mises en place. Chaque point calcul reprsente une moyenne sur 50 scnarii
de mobilit (10 scnarii pour chaque temps de pause). Les nuds dbutent la
123
Figure 5.13: Pourcentage de temps dans chaque mode de routage pour 10 connexions
simulation en mode DSR conformment au processus dadaptation (voir partie
4.3.1).
Le pourcentage de temps pass en mode CSR augmente avec la densit de
nud.
Pour une densit de 50 nuds, un nud passe en moyenne moins de 7%
du temps en mode CSR. La densit globale du rseau est faible. La majorit
des nuds reste donc en mode de routage DSR. Cependant, les mouvements
des nuds peuvent crer des zones de forte densit locale. Ainsi, les nuds qui
dtectent des conditions locales favorables au routage hirarchique basculent en
mode CSR.
Pour une densit de 100 nuds, le temps pass en mode CSR est quasiment
gal au temps pass en mode DSR (48% - 52%). La densit globale du rseau
est plus forte que dans le cas prcdent. Ainsi, plus de nuds exprimentent le
mode de routage CSR. Les conditions de mobilit et de densit du rseau dans
les simulations sont proches des seuils dadaptation.
Pour une densit de 150 nuds, le temps pass en mode CSR est de 66%.
La densit globale du rseau est forte. Lorsque un nud dtecte des conditions
de rseau favorables au CSR, il adapte son mode de routage. La mobilit des
nuds peut entrainer le changement de mode inverse mais la densit est assez
forte pour maintenir la majorit des nuds en mode CSR.
Les rsultats prcdents ont t obtenus en ralisant une moyenne sur de nombreux scnarii. Ils permettent dobserver que lutilisation du mode hirarchique
augmente avec la densit. Ce comportement est conforme nos attentes. Cependant, il convient de vrifier que les nuds ragissent globalement de manire
identique aux changements de conditions de rseau. En effet, le mode de routage
124
CSR ncessite quune majorit de nuds soient en mode CSR pour raliser un
routage efficace.
Par consquent, nous avons tudi lvolution au cours du temps du nombre
de nuds en mode CSR. Pour chaque densit de nuds, nous avons observ
le nombre de nuds en mode CSR pour une mobilit faible (temps = 500s),
une mobilit moyenne (temps de pause = 300s) et une mobilit forte (temps de
pause = 100s).
Pour une densit de 50 nuds, nous constatons que le pourcentage de nuds
en mode CSR reste globalement infrieur 5% quelle que soit la mobilit (Figure
5.14(a)). Certains pics apparaissent cependant: pour un temps de pause gal
300s, on remarque un pic aprs 300s de simulation qui correspond au premier
dplacement des nuds.
Pour une densit de 100 nuds, le nombre de nuds en CSR dpasse les
60% aprs le premier dplacement des nuds quel que soit le temps de pause
(Figure 5.14(b)).
Pour une densit de 150 nuds, le nombre de nuds en CSR dpasse 60 %
aprs lactivation des sources de trafic (entre 30s et 70s). Cependant on constate
une augmentation du nombre de nuds en CSR aprs chaque dplacement des
nuds quel que soit le temps de pause (Figure 5.14(c)).
Deux phnomnes expliquent laugmentation du nombre de nuds en mode
CSR aprs un dplacement de nuds:
le dplacement des nuds modifie les conditions de rseau en terme de mobilit. Les auteurs de [CBD02] ont notamment remarqu un comportement
imprvu du modle de mobilit Random Waypoint: lorsque les nuds se
dplacent, il ont tendance passer par le centre de laire de simulation.
Aprs un dplacement de nuds, on peut assister un regroupement de
nuds au centre de laire de simulation qui augmente la densit de nuds.
la mobilit des nuds implique un trafic de contrle important (Erreurs de
route, Requtes de route). La pertinence de lestimation de la mtrique de
densit dpend du trafic, de donnes ou de contrle, qui traverse le rseau.
En effet, la Densit est dfinie comme le nombre de voisins obtenus via le
cache de routes: lorsque le trafic est important, chaque nud obtient plus
dinformations sur ses voisins. Laccroissement de la mobilit des nuds
permet donc une meilleure estimation de la mtrique de densit.
125
(a) 50 nuds
(b) 100 nuds
(c) 150 nuds
Figure 5.14: Pourcentage de nuds en mode CSR pour 10 connexions et pour

diffrentes densits de nuds
126
Figure 5.15: Dure de la transition DSR -> CSR selon le statut
5.4.2
Dure de la transition
Le temps pass dans le mode Transition Adaptative permet de mesurer la ractivit de lextension aux changements des conditions du rseau. Plus ce temps
est court, plus lutilisation du mode de routage adquat sera rapide. Nous
rappelons toutefois quun mode de routage oprationnel, le routage DSR, est
constamment disponible dans le mode Transition Adaptative.
Nous reprenons le modle de simulation dcrit prcdemment. Nous illustrons la dure de transition sur une configuration de 150 noeuds, un temps de
pause de 300 secondes et pour 10 sources de trafic.
La Figure 5.15 montre le temps pass en mode Transition Adaptative selon
le statut obtenu par le noeud lissue de la transition. Nous observons ici la
transition du mode DSR vers le mode CSR. La dure absolue de la transition na
pas de porte en elle-mme car elle dpend des valeurs des timers associs aux
procdures CSR. En effet, les valeurs des timers ont t fixes de manire arbitraire car notre objectif premier tait dillustrer les principes de notre mthode
dadaptation.
Nous observons tout dabord que le temps pass en mode Transition Adaptative augmente avec la position dans la hirarchie: les Noeuds CSR passent le
moins de temps dans la phase de transition tandis que le Serveur a la dure de
transition la plus leve. Ainsi, la dure de transition est relativement faible
pour la majorit des noeuds (les Noeuds CSR).
Dans le cas des Noeuds CSR, plusieurs vnements peuvent dclencher le
passage en mode Transition Adaptative:
le noeud reoit un message de maintenance de son Cluster Head indiquant
que le mode CSR est oprationnel. Dans ce cas, le passage en mode de
127
routage CSR Avec Architecture est immdiat.

le noeud reoit un autre message CSR. Le temps de passage dpend alors
du processus de transition de ses voisins.
Un Cluster Head quitte le mode Transition Adaptative pour le mode Avec Architecture lorsque le Serveur rpond sa demande denregistrement. Sa dure de transition dpend aussi de ltat de larchitecture. Si larchitecture est
dj en place, le passage est relativement rapide car il ne requiert que la phase
denregistrement. Si larchitecture est en phase de mise en place ou de maintenance, la dure de transition sera plus longue (enregistrement et lection).
Le Serveur quitte le mode Transition Adaptative pour le mode Avec Architecture lorsquau moins trois Cluster Heads se sont enregistrs. A priori, la dure
de transition du Serveur devrait donc tre voisine de celle des Cluster Heads.
Cependant, il faut noter que la transition du Serveur vers le mode Avec Architecture requiert obligatoirement la phase denregistrement (le Cluster Head
essaie de senregistrer auprs du Serveur avant de conclure son absence) et la
phase dlection. Ces phases introduisent une latence supplmentaire et ne sont
pas toujours ncessaires dans le cas des Cluster Heads.
5.5
128
Conclusion
La comparaison de performances entre CSR et les protocoles de premire gnration montre que CSR permet le passage lchelle du routage par rapport la
taille du rseau et la charge de trafic. Nous avons aussi montr lintrt
du changement dynamique du mode de routage en comparant lextension CSR
adaptative avec une version non adaptative de CSR.
En comparant CSR et OLSR, nous avons observ que CSR a des performances proches de celles dOLSR en terme dacheminement de donnes. Cependant, CSR consomme moins de bande passante pour atteindre ce niveau de performances. CSR prsente mme de meilleures performances sur des rseaux de
petite taille.
Par ailleurs, ltude de la stabilit du changement de mode montre que le
temps pass par chaque nud en mode CSR augmente avec la densit. De plus,
les nuds ragissent de manire homogne aux changement des conditions du
rseau.
Conclusions et perspectives
Dans cette thse, nous avons tudi lauto-adaptation du mode de routage
dans les rseaux ad hoc en fonction des conditions du rseau. Notre objectif
tait damliorer les performances du routage sur des domaines de densit et de
mobilit plus tendus que les protocoles proposs jusqu prsent.
Les travaux que nous avons exposs montrent quil nexiste actuellement pas
de protocole de routage qui soit adapt toutes les conditions de mobilit et de
densit. De ce fait, ladaptation du mode de routage nous a paru une solution
trs intressante. Ltude mene sur les protocoles de routage de 1re gnration
nous a montr leurs limitations de passage lchelle par rapport la taille du
rseau.
Nous avons dfini une mthode gnrale dadaptation du mode de routage
qui peut tre applique tout protocole de routage ractif. Cette mthode sappuie sur lestimation de deux dynamiques du rseau : la mobilit et la densit.
Nous proposons dutiliser un protocole plat lorsque la mobilit est forte ou la
densit faible et dutiliser un protocole hirarchique pendant les priodes de
faible mobilit et de forte densit.
Notre mthode dadaptation repose sur les principes de transparence et de
compatibilit : deux nuds dans des modes de routage diffrents doivent pouvoir
communiquer entre eux. Pour mettre en uvre notre mthode, nous proposons
donc de dvelopper une extension hirarchique dun protocole plutt que dutiliser deux protocoles distincts.
Pour dmontrer la faisabilit de notre mthode dadaptation, nous lavons
applique en nous basant sur le protocole DSR. Lextension hirarchique que
nous avons dveloppe sappelle le CSR (Cluster Source Routing) et sappuie
sur une hirarchie de clusters. Nous avons dfini les procdures de routage et
de clustering de notre extension. Le format des paquets CSR a t clairement
explicit pour permettre une implantation relle de lextension CSR.
Nous avons galement dfini des mtriques dadaptation de mobilit et de
densit. Lensemble des procdures CSR a t implant sur lenvironnement de
simulation ns2 pour valider le fonctionnement de notre extension.
Nous avons ralis une tude de performances du CSR en le comparant aux
principaux protocoles de routage prconiss par lIETF.
Tout dabord, nous avons compar lextension CSR aux protocoles de 1re
gnration DSR et AODV. Nous avons ainsi montr que notre extension permettait le passage lchelle du routage dans les rseaux ad hoc par rapport
129
CONCLUSIONS ET PERSPECTIVES
130
la taille du rseau.
Nous avons ensuite compar les performances de notre proposition avec lun
des protocoles de 2me gnration les plus utiliss, OLSR. Notre tude montre
que notre extension adaptative ralise des performances proches dOLSR en
termes de P acket Delivery Ratio tout en consommant beaucoup moins de bande
passante pour le trafic de contrle. De plus, lextension CSR possde un meilleur
P DR sur des rseaux de petite taille (50 nuds).
Nous avons termin notre tude de performances en valuant la stabilit du
changement adaptatif du mode de routage : les nuds CSR sadaptent bien aux
conditions de densit et de mobilit du rseau. De plus, les nuds ragissent de
manire homogne aux changements de conditions du rseau.
De nombreuses applications peuvent bnficier du gain apport par lextension CSR :
les applications militaires : lors dun dploiement sur un champ doprations, lutilisation dun protocole adaptatif peut tre profitable. Typiquement, les soldats sont diviss en petits groupes ou units pour couvrir le
champ doprations. Ces petits groupes se dplacent souvent et la connectivit entre les groupes nest pas garantie. Le protocole DSR est alors
particulirement adapt ces conditions de petits rseaux forte mobilit. Les units se regroupent ensuite au centre doprations. La densit
de noeuds est alors plus leve et la mobilit est rduite : CSR constitue
alors le mode de routage le plus appropri cette configuration de rseau
.
les rseaux de secours : lextension CSR convient au dploiement dun
rseau ad hoc aprs une catastrophe de type sisme ou inondation. Les
phases de mobilit et de densit sont similaires celles des applications
militaires. Les quipes de secours se dploient en petits groupes pour rechercher les blesss et utilisent DSR car les rseaux sont de petite taille
et prsentent une forte mobilit. Les blesss sont ensuite transports au
centre de soins : la mobilit est plus rduite et la densit de noeuds augmente, le mode de routage CSR est alors le plus adapt.
les rseaux maills sans fil mtropolitains : ce type de rseau ad hoc est traditionnellement dploy par des associations de consommateurs. De nombreux vnements peuvent modifier la connectivit du rseau et la taille du
rseau. Par exemple, la panne, le dplacement, la suppression ou lajout
dun routeur mobile peuvent gnrer des fusions ou des partitionnements
de rseaux. Pour rpondre ces changements de conditions de rseau,
lutilisation dune extension adaptative comme CSR est particulirement
indique.
Les travaux que nous avons effectus dans cette thse nous ouvrent de nombreuses perspectives de recherche.
En premier lieu, de nombreux paramtres de notre mthode dadaptation
peuvent tre tudis plus en dtail.
CONCLUSIONS ET PERSPECTIVES
131
Nous envisageons dobserver limpact du changement de dfinition des mtriques sur le comportement de notre extension. En effet, lestimation des conditions de rseau, en particulier la mobilit, est un sujet trs actif de la recherche
sur les rseaux ad hoc. Par exemple, des informations de mobilit et de densit
issues des couches basses peuvent tre obtenues en utilisant des mcanismes
cross layer et ne ncessitent aucun trafic de contrle supplmentaire.
Les seuils dadaptation relatifs aux mtriques peuvent aussi tre affins. Dans
cette thse, les seuils dadaptation ont t fixs de manire arbitraire car notre
but tait dillustrer le comportement gnral de lextension CSR. Cependant,
dans une optique doptimisation du CSR, des seuils plus prcis pourraient tre
obtenus par des simulations pousses ou par une tude analytique.
Lalgorithme de gestion des caches du Serveur reste aussi un sujet intressant tudier plus en dtail. Cette tude sinscrirait, comme ltude des seuils
dadaptation, dans une optique doptimisation de lextension CSR.
Dans cette thse, nous nous sommes focaliss sur la minimisation du trafic
de contrle afin damliorer les performances du routage. Cependant, la mise en
place dun Serveur ouvrent des perspectives dapplications aux mcanismes de
qualit de service en particulier dans le choix des chemins et la rpartition de
la charge.
Il serait galement intressant dimplmenter lextension CSR pour observer
son comportement dans des conditions de dploiement relles. Limplantation
de CSR que nous avons effectue sur ns2 facilitera le dploiement rel de CSR :
lensemble des procdures et le format des paquets ont t spcifis en dtail.
La phase dimplmentation permettra par la suite de raliser le prototypage de
lextension CSR.
Nous avons tudi lauto-adaptation du routage aux conditions de rseaux.
De faon plus globale, lauto-adaptation des protocoles peut stendre toutes
les couches de la pile de protocole (Application, Transport, MAC et Physique).
En effet, labsence dadministration et le fonctionnement distribu rend lautoadaptation particulirement intressante dans les rseaux ad hoc.
Bibliographie
[APHV00] Amis (A.), Prakash (R.), Huynh (D.) et Vuong (T.). Max-min dcluster formation in wireless ad hoc networks. Dans : INFOCOM
(1), pp. 3241. mars 2000.
[AR04]
Altalhi (A.) et Richard (G.). Virtual paths routing : A highly

dynamic routing protocol for ad hoc wireless networks. Dans : Proceedings of the PerCom Workshops, pp. 8186. mars 2004.
[ASH03]
Arpacioglu (O.), Small (T.) et Haas (Z.). Notes on Scalability of

Wireless Ad Hoc Networks. Internet-draft, IRTF, dcembre 2003.
[ASSC02]
Akyildiz (I.), Su (W.), Sankarasubramaniam (Y.) et Cayirci (E.).

A survey on sensor networks. IEEE Communications Magazine,
vol. 40, n 8, aot 2002, pp. 102114.
Akyildiz (I.) et Wang (X.). A survey on wireless mesh networks.
IEEE Radio Communications, vol. 43, n 9, septembre 2005, pp. 23
30.
[AW05]
[AWF02]
Alzoubi (K.), Wan (P.) et Frieder (O.). New distributed algorithm for connected dominating set in wireless networks. Dans :
Proceedings of HICSS, pp. 38493855. janvier 2002.
[Bas99]
Basagni (S.). Distributed clustering for ad hoc networks. Dans :

ISPAN. pp. 310315. Washington, juin 1999.
[BCSW98] Basagni (S.), Chlamatac (I.), Syrotiuk (V.) et Woodward (B.).

A distance routing effect algorithm for mobility (dream). Dans :
Mobicom, pp. 7684. octobre 1998.
[Bey90]
Beyer (D.). Accomplishments of the darpa suran program. Dans :

MILCOM, pp. 855862. dcembre 1990.
[BKL01]
Basu (P.), Khan (N.) et Little (T.). A mobility based metric for
clustering in mobile ad hoc networks. Dans : Distributed Computing
Systems Workshop, pp. 413418. avril 2001.
[BMJ+ 98] Broch (J.), Maltz (D.), Johnson (D.), Hu (Y-C) et Jetcheva (J.).
A performance comparison of multi-hop wireless ad hoc network
routing protocols. Dans : Proceedings of Mobicom, pp. 8597.
octobre 1998.
132
BIBLIOGRAPHIE
133
[Bol01]
Boleng (J.). Normalizing mobility characteristics and enabling

adaptive protocols for ad hoc networks. Dans : Proceedings of LANMAN, pp. 912. mars 2001.
[BR02]
Belding-Royer (E.). Hierarchical routing in ad hoc mobile networks. Wireless Communications and Mobile Computing, vol. 2, n
5, aot 2002, pp. 515532.
[BR03]
Belding-Royer (E.). Multi-level hierarchies for scalable ad hoc

routing. Wireless Networks, vol. 9, n 5, septembre 2003, pp. 461
478.
[CBD02]
Camp (T.), Boleng (J.) et Davies (V.). A survey of mobility

models for ad hoc network research. Wireless Communications and
Mobile Computing, vol. 2, n 5, 2002, pp. 483502.
[CDT02]
Chatterjee (M.), Das (S.) et Turgut (D.). Wca : a weighted clustering algorithm for mobile ad hoc networks. Journal of Cluster
Computing, vol. 5, n 2, avril 2002, pp. 193204.
[Cha01]
Chatschik (B.). An overview of the bluetooth wireless technology.

IEEE Communications Magazine, vol. 39, n 12, dcembre 2001, pp.
8694.
[CJ03]
Clausen (T.) et Jacquet (P.). Optimized Link State Routing Protocol (OLSR). RFC n 3626, IETF, octobre 2003.
[CM99]
Corson (S.) et Macker (J.). Mobile Ad hoc Networking (MANET) : Routing Protocol Performance Issues and Evaluation Considerations. RFC n 2501, IETF, janvier 1999.
[CP06]
Chakeres (I.) et Perkins (C.). Dynamic MANET On-demand

(DYMO) Routing. Internet-draft, IETF, mars 2006.
[CWLG97] Chiang (C.), Wu (H.), Liu (W.) et Gerla (M.). Routing in clustered multihop, mobile wireless networks with fading channel. Dans :
SICON97, pp. 197211. avril 1997.
[DPR00]
Das (S. Ranjan), Perkins (C.) et Royer (E.). Performance comparison of two on-demand routing protocols for ad hoc networks.
Dans : INFOCOM (1), pp. 312. mars 2000.
[DPZ04]
Draves (R.), Padhye (J.) et Zill (B.). Routing in multi-radio, multihop wireless mesh networks. Dans : Proceedings of ACM MobiCom,
pp. 114128. septembre 2004.
[DSB97]
Das (B.), Sivakumar (R.) et Bharghavan (V.). Routing in ad-hoc

networks using a virtual backbone. Dans : Proceedings of ICCCN,
p. 1. septembre 1997.
[EWB87]
Ephremides (A.), Wieselthier (J.) et Baker (D.). A design concept

for reliable mobile radio networks with frequency hopping signaling.
Proceedings of the IEEE, vol. 75, n 1, janvier 1987, pp. 5673.
[Get93]
Getting (I.). The global positioning system. IEEE Spectrum,

vol. 30, n 12, dcembre 1993, pp. 3647.
BIBLIOGRAPHIE
134
[GK00]
Gupta (Piyush) et Kumar (P. R.). The capacity of wireless networks. IEEE Transactions on Information Theory, vol. 46, n2, mars
2000, pp. 388404.
[Glo]
GloMoSim.
Le
simulateur
http ://pcl.cs.ucla.edu/projects/glomosim/.
[GT95]
Gerla (M.) et Tsai (J.). Multicluster, mobile, multimedia radio

network. Journal of Wireless Networks, vol. 1, n 3, aot 1995, pp.
255265.
[GT02]
Grossglauser (M.) et Tse (D.). Mobility increases the capacity of

wireless networks. IEEE/ACM Transactions on Networking, vol. 10,
n 4, avril 2002, pp. 477486.
Haas (Z.). A new routing protocol for the reconfigurable wireless
networks. Dans : ICUPC, pp. 562566. octobre 1997.
[Haa97]
glomosim
[HGJ+ 99] Haas (Z.), Gerla (M.), Johnson (D.), Perkins (C.), Pursley (M.),
Steenstrup (M.) et Toh (C.). Special issue on wireless ad hoc networks. IEEE Journal on Selected Areas in Communications, vol. 17,
n 8, aot 1999.
[HGPC99] Hong (X.), Gerla (M.), Pei (G.) et Chiang (C.). A group mobility
model for ad hoc wireless networks. Dans : ACM/IEEE MSWiM,
pp. 5360. aot 1999.
[hip95]
Hiperlan Functional Specification. Draft ets 300 652, ETSI, juillet

1995.
[HJ00]
Hu (Y-C) et Johnson (D.). Caching strategies in on-demand routing protocols for wireless ad hoc networks. Dans : Proceedings of
the ACM Mobicom. aot 2000.
[HP98]
Haas (Z.J.) et Pearlman (M.R.). The performance of a new routing

protocol for the reconfigurable wireless networks. Dans : ICC, pp.
156160. juin 1998.
[HPS03]
Haas (Z.), Pearlman (M.) et Samar (P.). The Zone Routing Protocol (ZRP) for Ad Hoc Networks. Internet-draft, IETF, juillet
2003.
[IEE85]
IEEE Computer Society LAN MAN Standards Committee. IEEE

Standard 802.3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.
Ieee std 802.3, IEEE, 1985.
[IEE97]
IEEE Computer Society LAN MAN Standards Committee. Wireless LAN medium access control (MAC) and physical layer (PHY)
specifications. Ieee std 802.11, IEEE, 1997.
[IET]
IETF.
The
manet
group
http :www.ietf.org/html.charters/manet-charter.html.
[IRT]
IRTF. The irtf rrg ad hoc network systems research subgroup :

http ://www.flarion.com/ans-research/.
BIBLIOGRAPHIE
135
[JHP+ 03]
Jetcheva (J.G.), Hu (Y.), PalChaudhuri (S.), Saha (A.K.) et Johnson (D.B.). Design and evaluation of a metropolitan area multitier
wireless ad hoc network architecture. Dans : 5th IEEE Workshop
on Mobile Computing Systems & Applications (WMCSA), pp. 32
43. octobre 2003.
[JLH+ 99]
Johansson (P.), Larsson (T.), Hedman (N.), Mielczarek (B.) et Degermark (M.). Scenario-based performance analysis of routing
protocols for mobile ad-hoc networks. Dans : MobiCom. pp. 195
206. New York, aot 1999.
[JLT99]
Jiang (M.), Li (J.) et Tay (Y.). Cluster Based Routing Protocol

(CBRP). Internet Draft - draft-ietf-manet-cbrp-spec-01.txt n3561,
IETF, juillet 1999.
[JM96]
Johnson (D.) et Maltz (D.). Dynamic source routing in ad hoc

wireless networks. Dans : Mobile Computing, d. par Imielinski et
Korth. Kluwer Academic Publishers, 1996.
[JMY04]
Johnson (D.), Maltz (D.) et Y.Hu. The Dynamic Source Routing

Protocol for Mobile Ad Hoc Networks. Internet-draft, IETF, juillet
2004.
[Joh94]
Johnson (D.). Routing in ad hoc networks of mobile hosts. Dans :

Workshop on Mobile Computing Systems and Applications, pp. 158
163. Santa Cruz, CA, U.S., dcembre 1994.
[JP04]
Jaddi (Farid) et Paillassa (Batrice). A Cluster Procedure for the

Dynamic Source Routing Protocol in Ad Hoc Networks . Dans : 3rd
Annual Mediterranean Ad Hoc Networking Workshop, Med-Hoc-Net
2004 , Bodrum (Turquie). p. 553. ., 27-30 juin 2004.
[JP05]
Jaddi (F.) et Paillassa (B.). An adaptive hierarchical extension of

the dsr : The cluster source routing. Dans : SAWN. mai 2005.
[JP06]
Jaddi (F.) et Paillassa (B.). Mobility and density self-adaptive routing strategies in ad hoc networks. Dans : Proceedings of LOCANMASS - To appear. october 2006.
[JT87]
Jubin (J.) et Tornow (J.). The darpa packet radio network protocols. Proceedings of the IEEE, vol. 75, n 1, janvier 1987, pp. 2132.
[JWT02]
J.Boleng, W.Navidi et T.Camp. Metrics to enable adaptive protocols for mobile ad hoc networks. Dans : Proceedings of ICWN.
2002.
[KGBK78] Kahn (R.), Gronemeyer (S.), Burchfiel (J.) et Kunzelman (R.).

Advances in packet radio technology. Proceedings of the IEEE,
vol. 66, n 11, novembre 1978, pp. 14681496.
[KSM03]
Kwak (B.), Song (N.) et Miller (L.). A standard measure of mobility for evaluating mobile ad hoc network performance. IEICE
Transactions on Communications, vol. E, n 86-B, novembre 2003,
pp. 32363243.
BIBLIOGRAPHIE
[LG97]
[LJC+ 00]
[LKL05]
[Mac06]
[Mal98]
136
Lin (C.) et Gerla (M.). Adaptive clustering for mobile wireless networks. IEEE Journal on Selected Areas in Communications, vol. 15,
n 7, septembre 1997, pp. 12651275.
Li (J.), Jannotti (J.), Couto (D. De), Karger (D.) et Morris (R.).
A scalable location service for geographic ad hoc routing. Dans :
Mobicom, pp. 120130. avril 2000.
Lin (X.), Kwok (Y.) et Lau (V.). A quantitative comparison of ad
hoc routing protocols with and without channel adaptation. IEEE
Transactions on Mobile Computing, vol. 4, n 2, mars 2005, pp. 111
128.
Macker (J.). Simplified Multicast Forwarding for MANET.
Internet-draft, IETF, mars 2006.
Malkin (G.). RIP Version 2. RFC n2453, IETF, novembre 1998.
[Mit06]
Mitton (N.). Auto-organisation des rseaux sans fil multi-sauts

grande chelle. Thse de PhD, Institut National des Sciences
Appliques de Lyon, 2006.
[Moy98]
[MZ99]
Moy (J.). OSPF Version 2. RFC n 2328, IETF, avril 1998.

MCDonald (A.) et Znati (T.). A mobility-based framework for
adaptive clustering in wireless networks. IEEE journal on selected
areas in communications, vol. 17, n 8, 1999, pp. 14661486.
Nocetti (F.), Gonzalez (J.) et Stojmenovic (I.). Connectivity based
k-hop clustering in wireless networks. Telecommunication Systems,
vol. 22, n 1-4, 2003, pp. 205220.
[NGS03]
[NI97]
Navas (J.) et Imielinski (T.). Geographic addressing and routing.

Dans : MOBICOM. septembre 1997.
[NS]
NS. Le simulateur ns-2 : http ://www.isi.edu/nsnam/ns/.
[OPN]
[OTL04]
OPNET. Le simulateur opnet : http ://www.opnet.com.

Ogier (R.), Templin (F.) et Lewis (M.). Topology Dissemination
Based on Reverse-Path Forwarding (TBRPF). RFC n3684, IETF,
fvrier 2004.
[Par94]
Parekh (A.K.). Selecting routers in ad hoc wireless networks.

Dans : SBT/IEEE ITS . 1994.
[PB94]
Perkins (C.) et Bhagwat (P.). Highly dynamic destinationsequenced distance-vector routing (dsdv) for mobile computers.
Dans : ACM Conference on Communications Architectures, Protocols and Applications, SIGCOMM 94, London, UK. ACM, pp.
234244. ACM, aot 1994.
[PBRS03] Perkins (C.), Belding-Royer (E.) et S.Das. Ad hoc On demand
Distance Vector (AODV) Routing. RFC n 3561, IETF, 2003.
[PC97]
Park (V.) et Corson (M.). A highly adaptive distributed routing
algorithm for mobile wireless networks. Dans : INFOCOM. p. 1405.
Washington, DC, USA, avril 1997.
BIBLIOGRAPHIE
137
[RPSM01] Royer (E.), P.Melliar-Smith et Moser (L.). An analysis of the

optimum node density for ad hoc mobile networks. Dans : ICC,
pp. 857861. 2001.
[SMSR02] Santivanez (C.), McDonald (B.), Stavrakakis (I.) et Ramanathan
(R.). On the scalability of ad hoc routing protocols. Dans : Proceedings of INFOCOM. juin 2002.
[SPH04]
Samar (P.), Pearlman (M.R.) et Haas (Z.J.). Independent zone

routing : an adaptive hybrid routing framework for ad hoc wireless
networks. Dans : IEEE/ACM Transactions on Networking. aot
2004.
[TGLN05] Tschudin (C.), Gunningberg (P.), Lundgren (H.) et Nordstrm (E.).

Lessons from experimental manet research. Ad Hoc Networks,
vol. 3, n 2, 2005, pp. 221233.
[TNCS02] Tseng (Y.), Ni (S.), Chen (Y.) et Sheu (J.). The broadcast storm
problem in a mobile ad hoc network. Wireless Networks, vol. 8, n
2-3, mars 2002, pp. 153167.
[VP84]
Veran (M.) et Potier (D.). Qnap 2 : A portable environment for

queueing networks modelling. Dans : Int. Conf. Modelling Techniques Tools Performance Analysis, pp. 2563. mai 1984.
[WL99]
Wu (J.) et Li (H.). On calculating connected dominating sets for

efficient routing in ad hoc wireless networks. Dans : Proceedings of
DIALM, pp. 714. aot 1999.
[WL03]
Wu (J.) et Lou (W.). Forward node set based broadcast in clustered mobile ad hoc networks. Wireless Communications and Mobile
Computing, vol. 3, n 2, 2003, pp. 141154.
[YK05]
Yu (X.) et Kedem (Z.). A distributed adaptive cache update algorithm for the dynamic source routing protocol. Dans : INFOCOM,
pp. 730739. mars 2005.
[YLN03]
Yoon (J.), Liu (M.) et Noble (B.). Random waypoint considered

harmful. Dans : INFOCOM, pp. 13121321. 2003.
RESUME
La facilit de dploiement des rseaux ad hoc s'avre utile lorsque la

mise en place d'une infrastructure est impossible.
L'objectif du routage est de trouver les chemins tout en considrant les
contraintes de
bande passante et de dynamicit de la topologie.
Le routage dans les rseaux ad hoc
prsente de nombreux challenges dus
tant aux contraintes technologiques qu'aux diffrents contextes

applicatifs.
Aprs avoir analys les problmatiques inhrentes au routage dans les
rseaux ad hoc,
nous nous intressons en particulier au passage
l'chelle des protocoles de routage qui constitue un sujet d'tude trs

ouvert.
Par ailleurs,
l'absence d'administration centralise dans un rseau ad
hoc et le changement dynamique et imprvisible

(mobilit des noeuds,
taille du rseau)
des conditions de rseau
contraignent les units mobiles
une certaine autonome et une plus grande ractivit.
Nous introduisons alors la notion d'adaptation aux conditions de rseau.

Nous nous concentrons sur l'valuation des conditions en termes de
mobilit et de densit afin de pouvoir adapter le mode de routage.
Nous proposons en premier lieu une mthode d'auto-adaptation du mode de
routage
densit.
(plat ou hirarchique)
en fonction de la mobilit et de la
Nous ralisons une tude dtaille des mtriques de mobilit.
Les mtriques utilises pour l'adaptation,
les modes de routages ainsi
que les transitions entre les modes ont t dfinis.

L'objectif est double:
amliorer le passage l'chelle des protocoles
plats et utiliser le mode de routage le plus performant en fonction des

conditions de rseau.
Nous avons par la suite montr la faisabilit de notre mthode en
proposant une extension hirarchique du protocole plat DSR que nous
avons nomme CSR.
Nous avons spcifi les procdures de routage et de clustering du CSR et
les avons implante de manire dtaille sous ns2.
Nous avons men une
tude de performances du CSR en le comparant aux protocoles prconiss

par l'IETF
(DSR,
AODV et OLSR).
Notre tude montre l'intrt de l'adaptation du mode de routage afin

d'amliorer les performances du routage.
Une tude dtaille du changement de mode montre que les units mobiles
implmentant le CSR ragissent correctement et de manire homogne aux
changements de conditions du rseau.
MOTS CLE :
clustering
rseaux ad hoc,
routage,
adaptation,
mobilit,
densit,

DSR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DSR

Transféré par

Droits d'auteur :

Formats disponibles

N d'ordre: 2381

cole doctorale: Ecole Doctorale d'Informatique et Tlcommunications

une extension hirarchique adaptative

du protocole de routage ad hoc DSR

devant le jury compos de :

CSR: une extension hirarchique adaptative du

Thse dirige par Batrice PAILLASSA

Table des matires

1 Introduction au routage dans les rseaux Ad hoc

TABLE DES MATIRES

2.1.3 Paramtres dvaluation . . . . . . . . . . . . . . . . .

3 Mthodes dadaptation dans les rseaux ad

TABLE DES MATIRES

4 Hirarchisation adaptative du protocole DSR

5 Evaluation de loptimisation CSR

TABLE DES MATIRES

5.4.2 Dure de la transition . . . . . . . . . . . . . . . . . . . . 126

Table des figures

Exemple de rseaux ad hoc . . . . . . . . . . . . . . . . . . . . .

Dplacement dun nud selon le modle Random Waypoint . . .

Exemple de formation de clusters . . . . . . . . . . . . . . . . . .

Rapports des efficacits sur 2 topologies pour diffrentes densits 105

TABLE DES FIGURES

Liste des tableaux

Caractristiques des principaux protocoles de routage ad hoc . .

Caractristiques des services de localisation tudis . . . . . . . .

En-tte fixe DSR . . . . . . . . . .

LISTE DES TABLEAUX

LISTE DES TABLEAUX

Daprs les diffrentes valuations de performance que nous avons tudies,

ensuite dtailles. Nous terminons cette partie en expliquant les mcanismes

Introduction au routage dans

Notions de rseaux ad hoc . . . . . . . . . .

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC6

Fig. 1.1 Exemple de rseaux ad hoc

Notions de rseaux ad hoc

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC7

Le standard 802.11 a t normalis par lIEEE en 1997. Il dfinit deux modes

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC8

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC9

Actuellement, de nombreuses implantations relles de rseaux ad hoc ont t

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC10

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC11

Classification des protocoles de routage

Le routage dans les rseaux ad hoc prsente de nombreux challenges pour la

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC12

Tab. 1.1 Caractristiques des principaux protocoles de routage ad hoc

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC13

Exemples de protocoles de 1re gnration

DSDV (Destination-Sequenced Distance-Vector) est un protocole proactif

TORA (Temporally Ordered Routing Algorithm) a t propos par Park et

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC14

Le protocole AODV (Ad hoc On demand Distance Vector), propos par

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC15

(a) Requte de la source

(b) Rponse de la destination

Fig. 1.2 Dcouverte de routes AODV et DSR

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC16

Le protocole DSR (Dynamic Source Routing) a t labor dans le cadre

Lorsquun nud initie ou relaie un paquet de donnes, il doit sassurer que

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC17

coute active (Snooping) : lorsquun nud transmet un paquet de donnes

CHAPITRE 1. INTRODUCTION AU ROUTAGE DANS LES RSEAUX AD HOC18