These

N dordre
Annee 2003
Thèse
Etude
du standard IEEE 802.11 dans le cadre
des r
eseaux ad hoc : de la simulation `
a
lexp
erimentation.
Presentee devant
LInstitut National des Sciences Appliquees de Lyon
pour obtenir
Le grade de docteur
Par
Dominique Dhoutaut
` soutenir le 11 Decembre 2003 devant la Commission dexamen
A
Jury MM.
S. Amarger
A. Duda
I. Guerin-Lassous
P. Jacquet
G. Pujolle
F. Spies
S. Ubeda
Deputy Laboratory Manager (Hitachi, Sophia-Antipolis)

Professeur (ENSIMAG, Grenoble)
Chargee de recherche (INRIA)
Directeur de recherche (INRIA, Rocquencourt)
Professeur (Universite Paris VI)
Professeur (Universite de Franche-Comte)
Professeur (INSA de Lyon)
Les reseaux ad-hoc sont auto-organises et ne reposent sur aucune infrastructure fixe. Les
elements les composant sont en general relies par radio, potentiellement mobiles, et peuvent etre
amenes à entrer ou sortir du reseau à tout moment. Ces reseaux sont caracterises par la capacite
de chaque participant dagir à la fois comme client et comme routeur du reseau. Si un emetteur
nest pas à portee directe de la machine destination, les informations devront etre transmises de
proche en proche, le long dun chemin etabli et maintenu par le reseau en cas de modification de
la topologie (ces reseaux sont dailleurs qualifies de multi-sauts).
Le domaine des reseaux ad-hoc est vaste et recent. Un travail consequent est actuellement
effectue dans le groupe MANET de lIETF dans le but de normaliser un ou des protocoles de
routage pour ces reseaux. Ces travaux, ainsi que de nombreux autres portants sur des protocoles
de plus haut niveau (qualite de service, decouverte de services, ...) sappuient sur des simulations
utilisant en particulier la norme 802.11 de lIEEE.
Mon travail porte sur lutilisation de cette norme comme support pour les reseaux ad-hoc,
domaine pour lequel elle na pas ete prevue à lorigine.
Dans un premier temps, jai realise de nombreuses simulations avec le simulateur de reseaux
NS2. Elles mont en particulier permis de montrer que de graves problèmes dequite au niveau
de laccès au medium pouvaient apparatre. Dans de nombreuses situations typiques des
reseaux ad-hoc certains mobiles peuvent voir leur accès fortement reduit ; ceci a un impact
direct sur les applications, mais aussi sur les protocoles de routages eux memes, et risque de
provoquer un effondrement du reseau.
Jai donc travaille à la comprehension et lanalyse de ces problèmes mis en lumière par la
simulation. En sus de problèmes dejà largement etudies dans la litterature (par exemple les
nuds caches), le fait que dans un reseau ad-hoc des mobiles puissent se gener les uns les
autres sans pour autant avoir de moyen de communiquer apporte de nombreuses contraintes
supplementaires. Letude (par la theorie et la simulation) de ces contraintes et de leurs interactions avec certains mecanismes prevus par la norme 802.11 mont logiquement amene a
proposer des solutions aux problèmes dequite. Certaines solutions saffranchissent de toute
communication entre les mobiles se genant potentiellement. Dautres solutions essaient de
tirer parti dune connaissance dune region plus etendue que le voisinage direct pour obtenir
des resultats sapprochant de lideal.
Mais au fur et à mesure que ma comprehension de la norme 802.11 et des phenomènes lies `
a son
utilisation dans les reseaux ad-hoc setoffait, il mest apparu que la realite etait plus complexe.
En environnement reel, des phenomènes physiques non presents dans les simulations entrent
en jeu. Afin de mieux les cerner, et afin de mieux savoir ce quil est possible dattendre de la
norme 802.11 dans notre contexte, jai donc mene de nombreuses experimentations à laide
doutils que jai developpes. Dans un premier temps, ces mesures ont porte sur des scenarios
simples permettant dextraire les caracteristiques principales de 802.11. Ces mesures ont ainsi
permis de mettre en lumière des problèmes jusqualors presentes de facon theorique par la
communaute (par exemple le problème des zones grise), mais egalement dautres jusqualors
ignores ou non pris en compte.
Dans un deuxième temps, jai mene des experimentations sur des scenarios plus complexes
et typiques des reseaux ad-hoc (sauts multiples, interferences entres mobiles ne pouvant pas
communiquer entre eux,...). Ces experimentations ont dune part confirme les problèmes souleves par certaines simulations, et dautre part mont permis dimplementer, de tester et de
valider les solutions aux problèmes dequite que javais proposees precedemment.
Table des mati`

eres
1 Les
1.1
1.2
1.3
r
eseaux ad hoc
Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problèmes et contraintes specifiques des reseaux radio . . . . . . .
Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Routage hierarchique ou plat . . . . . . . . . . . . . . . . .
1.3.2 Etat de liens ou vecteur de distance . . . . . . . . . . . . .
1.3.3 Les differentes familles de protocoles de routage MANET .
1.3.4 Description de quelques protocoles de routage representatifs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
13
13
14
15
16
2 Pr
esentation de 802.11
2.1 Les autres normes de reseaux locaux sans fil. . . . . . . .
2.1.1 HiperLAN 1 . . . . . . . . . . . . . . . . . . . . . .
2.1.2 HiperLAN 2 . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . .
2.2 Introduction à 802.11 . . . . . . . . . . . . . . . . . . . . .
2.3 La couche physique . . . . . . . . . . . . . . . . . . . . . .
2.4 La couche MAC . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Description du mode DCF . . . . . . . . . . . . . .
2.4.2 Description du mode PCF . . . . . . . . . . . . . .
2.5 La securite des informations : la Wired Equivalent Privacy
2.6 Les trames 802.11b et le debit utile 802.11b . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
(WEP)
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
20
22
22
24
26
28
29
33
34
36
3 Particularit
es de 802.11 dans un contexte ad hoc
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Le problème des nuds caches . . . . . . . . . . . . . . .
3.3 Le problème des nuds exposes . . . . . . . . . . . . . . .
3.4 Le problème de la zone grise . . . . . . . . . . . . . . . . .
3.5 Partage du canal entre des flux à vitesses differentes . . .
3.6 TCP et 802.11 . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Capacite theorique en fonction la topologie (grille, chane)
3.8 Equite . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Conclusion et positionnement . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
42
42
43
43
44
44
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Simulations logicielles de r
eseaux ad-hoc
46
4 Simulations : introduction et sc
enarios de prise en main
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Objectifs initiaux des simulations . . . . . . . . . . . . . . . .
4.3 Presentation de Network Simulator 2 . . . . . . . . . . . . . .
4.3.1 Les differents modèles de propagation radio sous NS2
4.3.2 La gestion des interferences . . . . . . . . . . . . . . .
4.4 Traitements des resultats et outils danalyse . . . . . . . . . .
4.5 Prise en mains et premières simulations . . . . . . . . . . . .
4.5.1 Portee de communication et debit . . . . . . . . . . .
4.5.2 Interferences . . . . . . . . . . . . . . . . . . . . . . .
5 Sc
enarios avanc
es
5.1 Introduction et objectifs . . . . . . . . . .
5.2 Trois paires . . . . . . . . . . . . . . . . .
5.3 Sauts multiples en configuration de chane
5.4 La chane fixe et la paire de perturbateurs
5.5 Le problème de lasymetrie . . . . . . . .
5.6 Conclusion sur ces simulations . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
47
48
49
51
52
54
56
57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
60
60
63
67
70
71
6 Quelques solutions aux probl`

emes d
equit
e dans les r
eseaux ad hoc
6.1 Une solution historique et locale . . . . . . . . . . . . . . . . . . . . . .
6.2 Une solution etendue geographiquement . . . . . . . . . . . . . . . . . .
6.2.1 Point de depart et algorithme . . . . . . . . . . . . . . . . . . . .
6.2.2 Quelques resultats . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
72
72
75
75
77
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Exp
erimentations en environnement r
eel
7 Objectifs des mesures et moyens mis en uvre

7.1 Introduction et objectifs . . . . . . . . . . . . . .
7.2 Les environnements de mesure . . . . . . . . . .
7.2.1 Travaux anterieurs bases sur des mesures
7.2.2 Ad hoc Protocol Evaluation (APE) . . . .
7.3 Description de loutil forwarding . . . . . . . . .
7.3.1 Architecture du logiciel . . . . . . . . . .
7.3.2 Format des paquets . . . . . . . . . . . .
7.3.3 Les commandes disponibles . . . . . . . .
83
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 Les premi`
eres mesures
8.1 Justifications des donnees mesurees. . . . . . . . . . . . . . .
8.2 Le debit en fonction de la taille des paquets . . . . . . . . . .
8.2.1 La fragmentation à 1500 octets . . . . . . . . . . . . .
8.2.2 Limpact du WEP . . . . . . . . . . . . . . . . . . . .
8.2.3 Hormis les problèmes pre-cites, des debits très proches
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
de la
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
theorie
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
84
84
85
85
86
88
89
89
.
.
.
.
.
92
92
92
93
93
95
8.3
8.4
9 Les
9.1
9.2
9.3
Partage du canal entre nuds à portee de communication .

8.3.1 Deux flux (combinaisons demetteurs et recepteurs) .
8.3.2 Flux multiples . . . . . . . . . . . . . . . . . . . . .
Les mesures de portee . . . . . . . . . . . . . . . . . . . . .
8.4.1 Lenvironnement et le outils de mesure . . . . . . . .
8.4.2 Les resultats . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
outils danalyse avanc

ee
Les chronogrammes en environnement reel . . . . . . . . . . . . . . . . .
Le problème de la synchronisation . . . . . . . . . . . . . . . . . . . . .
Resolution du problème de la synchronisation . . . . . . . . . . . . . . .
9.3.1 Les differentes approches, les systèmes existants . . . . . . . . . .
9.3.2 Premières constatations et methode simple . . . . . . . . . . . .
9.3.3 Deuxième methode : approximation de la derive des horloges par
affine par morceaux . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.4 Troisième methode : le pèlerin synchronisateur . . . . . . . . . .
10 Les sc
enarios avanc
es
10.1 Les deux paires . . . . . . . . . . . . . .
10.2 Les trois paires . . . . . . . . . . . . . .
10.3 La chane . . . . . . . . . . . . . . . . .
10.3.1 Le scenario, les contraintes . . .
10.3.2 Le deploiement et le deroulement
10.3.3 Les resultats . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
de lexperience
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
96
96
98
99
99
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
une droite
. . . . . .
. . . . . .
.
.
.
.
.
104
104
104
107
107
109
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 110
. 114
117
117
120
120
120
122
123
11 Mise en pratique du malus

134
11.1 Choix de limplementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.2 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Introduction
Point de d
epart et sujet de th`
ese
A lheure o`
u les communications telephoniques sans fil se sont imposees de facon indeniable,
et o`
u les reseaux locaux radio connaissent un essor fulgurant, de nouvelles applications de ces
technologies apparaissent sans cesse. Ces sont les militaires qui ont ete les premiers interesses par
des technologies de communication radio fonctionnant de proche en proche et restant fonctionnelles
en cas de mobilite ou de perte de certains elements routeurs. Dans [1], on apprend que dès le debut
des annees 1970, les techniques de commutation de paquets ont inspire le developpement par le
DARPA1 des Packet Radio Network (PRNET). Ces reseaux disposaient dejà dune architecture
distribuee, partageaient dynamiquement le canal de diffusion par une combinaison des protocoles
Aloha et CSMA, et se servaient de la repetition des paquets pour elargir la zone de couverture
globale. Par la suite, en 1983, les Survivable Radio Networks (SURAN) furent developpes par
le DARPA. Lobjectif etait de passer outre les principales limitations des PRNet (en particulier
permettre le passage à des reseaux comportant enormement de nuds, gerant la securite, gerant
lenergie, et offrant des capacites de calcul suffisantes pour supporter des protocoles evolues). Mais
les recherches sur ces reseaux restaient exclusivement militaires. Les applications civiles de ces
reseaux appeles ad hoc napparurent que beaucoup plus tard, vers la fin des annees 1990. Parmi les
applications actuellement les plus en vogue destinees aux reseaux ad hoc, en sus de celles à usage
militaire, on peut citer par exemple :
le deploiement de reseaux dans des environnements o`
u les infrastructures fixes ne sont plus
operationnelles (sur les lieux de catastrophes naturelles ou autres) ;
le deploiement de reseaux de capteurs dans des environnements hostiles ou difficiles daccès.
Un tel reseau sauto-configure en fonction des ressources energetiques restantes et de la distribution geographique des nuds (disseminations initiale par largage par exemple, qui les
place de manière assez aleatoire) ;
lextension de reseaux dotes dinfrastructures : lorsquun certain nombre de stations de base
fixes existent mais que certains mobiles se trouvent en dehors de leur zone de couverture et
cherchent à passer par des mobiles intermediaires pour les atteindre et ainsi se rattacher `
a
lensemble du reseau.
Ces recherches sur les reseaux ad hoc dans le domaine civil nont en fait veritablement pris
leur essor quavec larrivee des premières technologies radio bon marche : principalement la norme
IEEE2 802.11 et ses diverses extensions. La norme 802.11 est concue avant tout pour batir des
reseaux autour dune infrastructure fixe de bornes radio reliees entre elles par un reseau c
able.
1
2
Defense Advanced Research Projects Agency

Institute of Electrical and Electronics Engineers, http ://www.ieee.org
Mais la methode daccès au canal quelle propose par defaut fonctionne de manière totalement
distribuee, cest la Distributed Coordination Function (DCF). Cette dernière, alliee au co
ut modere
des equipements, a joue un role primordial pour lutilisation de 802.11 dans un contexte ad hoc.
Elle peut en effet etre utilisee directement et laisse les chercheurs se concentrer sur les couches
superieures.
Ces recherches se sont cristallisees en particulier sous la forme dun groupe de travail `
a
lIETF3 : le groupe MANET (Mobile Ad hoc NETworks [2]). Les problematiques de ce type de
reseaux sont nombreuses et substantiellement differentes de celles des mondes filaire ou meme
cellulaire (pas dinfrastructure fixe ni meme dassurance davoir des voisins, mobilite possible de
tous les elements et donc absence de plan dallocation geographique des frequences, etc.). Le
groupe MANET travaille essentiellement à lelaboration de protocoles de routage adaptes (lorsque
lon cherche à communiquer avec un mobile qui nest pas à portee directe, il va falloir etre capable
de trouver des mobiles intermediaires qui vont relayer le message). Mais les couches les plus basses
(physique et daccès au medium) aussi bien que les couches plus elevees (jusquaux applications)
necessitent elles aussi des retouches plus ou moins importantes. Par exemple, labsence delements
fixes empeche de centraliser certaines tache, et rend lutilisation de methodes daccès au canal
telles que TDMA (Time Division Multiple Access) ardues. De meme, puisque le reseau peut parfois
se partitionner, les applications nont pas toujours accès aux memes ressources, et doivent donc
utiliser des caches ou prendre toutes autres mesures quelles jugent utiles pour fournir un service
le moins degrade possible.
De part sa diffusion et son faible co
ut, 802.11 sert de support à de très nombreux travaux dans
le domaine des reseaux ad hoc (que ce soit au niveau du routage, de la qualite de service ou encore
des applications). Mais cette norme na neanmoins pas ete concue pour ce type dutilisation puisque
les reseaux à stations de base sont le contexte quelle cible reellement. Il apparat que certains de
ses comportements dans un cadre purement ad hoc ne sont finalement pas bien connus. Cest `
a
letude de ces comportements et leurs interactions avec les couches superieures quest vouee cette
thèse.
Contributions et organisation du document

Nos travaux se situent au niveau de linteraction entre les protocoles specifiques des reseaux
ad hoc et les couches MAC (Medium Access Control) et physique sur lesquelles ils sappuient.
Le chapitre 1 introduit les reseaux ad hoc et le chapitre 2 presente la norme 802.11. Pour
les reseaux ad hoc, les differentes familles de protocoles de routage sont presentees, accompagnees dun certains nombre dexemples detailles qui nous permettront par la suite de mieux
comprendre les effets quauront sur chacun dentre eux les comportement des couches basses
utilisees dans un contexte ad hoc. La norme IEEE 802.11 quant à elle nest bien s
ur pas
complètement detaillee, mais les parties significatives et importantes pour notre travail le sont.
Il sagit, en sus dun apercu des techniques utilisees par la couche physique radio, de tout ce
qui concerne la gestion distribuee de laccès au canal radio, ainsi que certains points precis,
comme la gestion de la cryptographie ainsi que certaines particularites des extensions de 802.11
(802.11b notamment, qui introduit des debits plus eleves mais qui dispose damenagements pour
maintenir la compatibilite dont nous devront tenir compte plus tard). Le chapitre 3 quant `
a lui
3
lInternet Engineering Task Force, http ://www.ietf.org
detaille les contraintes et particularites de lutilisation de 802.11 dans un contexte purement ad hoc.
Notre contribution se presente ensuite sous la forme de trois parties distinctes :
Par des simulations. Dans les chapitres 4 et 5, en utilisant le simulateur Network Simulator 2,
nous avons cherche à mettre en lumière certains problèmes bien specifiques lies à lutilisation de
802.11 dans un contexte ad hoc. Cette etude commence par une prise en main de loutil de simulation
et la realisation de scenarios simples mais neanmoins necessaires, puis passe à des scenarios plus
specifiques. Les conditions dutilisation des reseaux ad hoc qui ont attire notre attention sont celles
o`
u le reseau est regulièrement traverse par des flux importants ; ces conditions nous semble en
effet hautement probables dans des reseaux utilises pour acceder au web, transferer des fichiers ou
encore consulter des messageries. A travers quelques scenarios très caracteristiques (une chane de
mobiles, une chane et un couple de nuds perturbateurs, trois paires de mobiles situes à diverses
distances), nous mettons en lumière des problèmes dequite de laccès au canal. Il apparat que dans
des situations malheureusement très communes dans des reseau ad hoc, certains mobiles peuvent
se trouver dans lincapacite demettre, et cela du simple fait de lactivite combinee de certains de
leurs voisins.
A laide de divers outils, dont un système de visualisation produisant des chronogrammes
detailles, nous analysons alors le problème et montrons quil trouve sa source dans le mecanisme
daccès au medium de 802.11. Il na en effet pas ete prevu pour fonctionner dans des situations
o`
u, dans un ensemble de mobiles voisins, certains dentre eux rencontrent plus de contention que
dautres. Nous montrons egalement que le mecanisme EIFS de 802.11, concu pour reduire les
chances de collision, est dans cette situation dommageable et amplifie les inegalite face à laccès au
canal. Nous expliquons alors quels sont les effets sur les protocoles de niveau superieur. Les protocoles de routages patissent en particulier des interruptions prolongees de communication que ces
problèmes declenchent, les liens vont leur apparatre plus instables et ils vont consommer beaucoup
de ressources pour maintenir leurs tables de routage à jour.
Après avoir detaille pourquoi certains sacrifices devraient necessairement etre faits pour reduire
ces problèmes, nous y proposons dans le chapitre 6 deux solutions. La première est basee sur
une penalite. Cette penalite est appliquee dune manière particulière aux mobiles qui bloquent
leurs voisins en emettant trop et donne des resultats encourageants. Nous presentons ensuite une
seconde methode, dans laquelle les mobiles diffusent des informations sur loccupation du canal
percue localement. Avec les informations transmises par leurs voisins, les nuds cherchent `
a se
comporter de manière plus equitable. Des resultats interessants seront egalement obtenus avec
cette technique.
Par des mesures r
eelles. Dans le chapitre 7, après en avoir justifie le choix face à des solutions
existantes, nous presentons le logiciel forwarding que nous avons ecrit dans le but de faciliter la
realisation dexperiences sur de veritables reseaux multi-sauts.
Dans le chapitre 8 nous utilisons forwarding pour verifier que certains comportements prevus
par la simulation et le calcul se transposent effectivement dans la realite. Il sagit en particulier de
mesures sur les debits possibles en fonction de la taille des paquets, de leffet de la cryptographie
WEP (Wired Equivalent Privacy), et de divers phenomènes lorsque le canal doit etre partage entre
un certain nombre de mobiles à portee de communication.
Dans le meme chapitre, nous soulignons ensuite les limites des modèles utilises dans les simulations. En particulier, labsence de gestion des debits multiples utilises par 802.11 pour ses paquets
de controle et les donnees ainsi que la forme de la zone de couverture. Sous les simulateurs, les
modèles de propagation couramment utilises (free-space, two-ray ground et shadowing) conduisent
à des zones de couverture circulaires centrees sur le mobile emetteur. Par des series de mesures `
a
differentes distances, vitesses de transmission et orientations des cartes radio, nous montrons que
la realite est bien differente. Nous fournissons des graphiques nous permettant destimer la portee
de communication des cartes en fonction des positions respectives des emetteurs et recepteurs. Ces
memes graphiques nous servent egalement à montrer leffet des interferences qui se traduit par une
instabilite des liens, meme en labsence de mobilite.
Par des mesures en environnement reel à laide du logiciel que nous avons developpe, nous
confirmons les problèmes mentionnes dans le premier point et en soulevons dautres.
Par une analyse avanc
ee des r
esultats des mesures. Les metriques habituellement utilisees
pour mesurer les performances des reseaux (debits, taux de perte, delais, ...) ont rapidement montre
leurs limites dans laide à la comprehension des phenomènes issus de lutilisation des couches PHY et
MAC de 802.11 dans un contexte multi-sauts. La realisation de chronogrammes precis setait revelee
très utile lors de lanalyse des resultats de simulation. Aussi, dans le chapitre 9, nous presentons
une methode qui permet de realiser de tels graphiques à partir dexperiences reelles. Les problèmes
principaux lors du passage de la simulation à lexperimentation sont essentiellement lies à labsence
dhorloge globale et à une derive trop rapide des horloges locales des mobiles. Une etude de cette
derive est presentee et un mecanisme permettant den corriger les effets est proposee.
Dans le chapitre 10 nous realisons des experiences mettant en uvre des scenarios typiquement
ad hoc. Il sagira de deux paires seloignant lune de lautre, du scenario des trois paires dejà etudie
par simulation et enfin dune configuration de chane. Les resultats de ces experiences confirmeront
les problèmes dequite de laccès au canal et la necessite de mieux prendre en compte les couches
basses lors de la conception des protocoles de routage ad hoc.
Disposant alors de tous les outils necessaires, nous implementons dans le chapitre 11 le
mecanisme de penalite decrit dans le chapitre 4. Certaines adaptations sont cependant necessaires,
du fait de limpossibilite de modifier la couche MAC, celle-ci etant codee dans une memoire
embarquee sur les cartes reseau radio et non modifiable (il nous etait tout du moins impossible
davoir accès à ses codes source qui ne sont pas ouverts). Les resultats encourageants obtenus sont
alors commentes et ouvrent des pistes pour des mecanismes plus elabores et plus efficaces.
Cette thèse constitue un travail de trois ans qui a ete realise au sein du LIP puis du CITI,
Isabelle Guerin-Lassous en a assure lencadrement au jour le jour durant toute la duree. Certains
des travaux presentes ici sont encore en cours, dautres ont dejà fait lobjet de publications dans
des conferences internationales ([3, 4]) ou nationales ([5, 6]). Notons egalement la presentation de
certaines parties sous forme de poster `
a MS3G 2001, et la finalisation lors du debut de la thèse de
[7, 8] qui concluaient des travaux effectues en DEA.
CHAPITRE
1
1.1
Les r
eseaux ad hoc
Objectifs
Les reseaux ad hoc auxquels nous nous sommes interesses sont ceux decrits et etudies par
le groupe de travail Mobile Ad-hoc NETworks (MANET) de lInternet Engineering Task Force
(IETF). Une definition de ces reseaux est donnee formellement dans la RFC 2501 [9]. Il sagit de
reseaux sans fil et sans infrastructure fixe, utilisant generalement le medium radio, et o`
u chaque
nud peut combiner les roles de client et de routeur. Les reseaux ad-hoc sont auto-organises, ce
qui implique que la connectivite doit etre preservee autant que possible automatiquement lorsque
la topologie du reseau change (suite à lapparition, la disparition ou au mouvement de certains
nuds). Les premiers travaux sur ce type de reseaux ont ete effectues dans une optique militaire
(la capacite à se reconfigurer et à rester operationnel en cas de perte de certains mobiles etant
un avantage considerable) ; mais leur champ dapplication est beaucoup plus vaste. Par exemple,
ces reseaux faciles à deployer peuvent etre particulièrement utiles pour retablir les communications
lorsque des catastrophes ont detruit les installations fixes existantes, on encore lorsque lon desire
deployer un reseau de capteurs dans certains environnements hostiles.
1.2
Probl`
emes et contraintes sp
ecifiques des r
eseaux radio
De par la nature du canal radio, un certain nombre de problèmes se posent qui ne trouvent pas
dequivalent dans le monde filaire. On peut citer en particulier :
Un d
ebit plus faible par rapport à un equivalent filaire. Il faut donc que la gestion du
reseau occupe une part la plus reduite possible des maigres ressources en bande passante.
Une att
enuation rapide du signal en fonction de la distance (bien plus rapide que sur un
cable) qui induit limpossibilite pour un emetteur de detecter une collision au moment meme
o`
u il transmet. Dans un reseau filaire, un emetteur sait quil y a collision quand le signal
quil lit sur le cable est different de celui quil cherche à emettre. Dans un reseau radio, un
signal venant dun autre nud est tellement attenue par la distance quil ne provoquera que
des perturbations negligeables par rapport au signal emis localement. Par exemple, sur la
figure 1.1, au niveau du nud B, le signal emis par B lui-meme est de très loin superieur `
a
celui quil recoit du nud A. Par consequent, le signal du nud A est complètement ignore
par B qui croit quil ny a pas de collision. Malheureusement, au niveau du nud C, les deux
signaux ont des puissances comparables et il y a bien collision du point de vue du recepteur.
Seul un système dacquittement peut garantir la bonne reception dun message dans ce type
de contexte. Cette incapacite à detecter un signal etranger lorsque lon emet nous-meme rend
10

CHAPITRE 1. LES RESEAUX
AD HOC
A
C
Fig. 1.1 lattenuation rapide du signal en fonction de la distance
donc le medium radio half-duplex, ce qui signifie que lon ne peut pas emettre et recevoir en
meme temps.
Les interf
erences. Les liens radios ne sont pas isoles, et le nombre de canaux disponibles
est limite. Il faut donc se les partager. Les interferences peuvent etre de natures diverses.
Par exemple, des emetteurs travaillant à des frequences trop proches peuvent interferer
entre eux. Lenvironnement lui-meme peut egalement produire des bruits parasites (certains
equipements electriques, certains moteurs, ...) qui interfèrent avec les communications. Lenvironnement peut aussi deformer le signal et le rendre rapidement incomprehensible à cause des
phenomènes dattenuation, de reflexion ou de chemins multiples (lattenuation et la reflexion
varient en fonction des materiaux rencontres ; le problème des chemins multiples apparat
lorsque des reflexions dune meme onde par des chemins differents arrivent de manière decalee
dans le temps au recepteur, se chevauchent, et forment un tout plus difficile à analyser). Ces
problèmes font que les taux derreurs de transmission dans les reseaux radio sont nettement
plus eleves que dans les reseaux filaires. Cela a un impact non negligeable sur les protocoles
de niveau superieur. TCP en particulier va y etre particulièrement vulnerable, car il va interpreter les pertes de paquets comme etant dues à de la congestion sur le reseau. Quand TCP
detecte de la congestion, il cherche à lattenuer en reduisant la taille de sa fenetre demission
[10]. Malheureusement, dans le cas present, cest exactement linverse quil faudrait faire, les
paquets perdus doivent etre re-emis au plus vite. TCP Westwood [11] est une variante de
TCP qui cherche à corriger ce problème en estimant la bande passante de bout en bout et en
gerant differemment la reduction de la taille de sa fenetre.
Il faut ajouter egalement que des interferences ou des changements persistants dans lenvironnement vont conduire à une grande versatilite des liens, qui peuvent apparatre ou etre
coupes de manière durable à tout moment.
La puissance du signal. Non seulement elle est rapidement attenuee avec la distance, mais
elle est egalement limitee par des reglementations très strictes. Un emetteur ne peut donc
depasser une certaine puissance à lemission.
Lenergie. Les applications relatives aux reseaux sans fil ont en general un caractère nomade
et tirent leur autonomie de batteries. Emettre ou recevoir des donnees consomme de lenergie
et lon peut chercher à leconomiser en optimisant les protocoles de gestion du reseau. La
puissance demission a un impact important sur la quantite denergie utilisee et là encore on
essaie si possible de la limiter à ce qui est strictement necessaire.
Une faible s
ecurit
e. Il est facile despionner un canal radio de manière passive. Les
protections ne pouvant pas se faire de manière physique (il est en general difficile dempecher
quelquun de placer discrètement une antenne receptrice très sensible dans le voisinage), elle
devront etre mises en place de manière logique, avec de la cryptographie ou eventuellement
11

AD HOC
des antennes très directionnelles. Mais le canal radio restera quoiquil en soit vulnerable `
a un
brouillage massif (attaque de type denial of service).
La mobilit
e. De nombreuses applications des reseaux radio concernent des mobiles qui,
comme leur nom lindique, sont amenes à se deplacer. Ceci va conduire à des changements
plus ou moins rapides de la topologie. Pour les gerer, des protocoles appropries vont etre
necessaires.
Nous avons vu que le full-duplex etait rendu impossible par lattenuation trop rapide des signaux
en fonction de la distance. Pour pouvoir travailler sur un canal half-duplex, les communications
peuvent etre multiplexees en temps (TDD : Time Division Duplex). En TDD, un nud peut
transmettre durant certains slots et recevoir durant dautres slots dans la meme bande de frequences.
Quand les debits deviennent très importants, le temps de passage dun mode à lautre devient
cependant non negligeable. Le multiplexage FDD (Frequency Division Duplex) permet quant `
a lui
demettre et de recevoir en meme temps car on travaille alors sur plusieurs frequences differentes.
Mais les equipements necessaires sont plus complexes.
Dans les reseaux ad hoc, certaines des contraintes presentees precedemment sont accentuees et
dautres apparaissent en supplement :
Limpossibilit
e de mettre en place un plan dallocation des fr
equences limite la
reutilisation spatiale. Dans les reseaux radio utilisant des stations de base, on cherche `
a
attribuer des frequences differentes aux stations voisines, evitant que les cellules ainsi creees
ninterfèrent entre elles. Dans les reseaux ad hoc, pour garantir la connectivite, comme il ny
a pas dinfrastructure fixe et que tous les nuds sont susceptibles de bouger ou de disparatre,
il est plus simple et moins co
uteux de travailler avec une seule frequence. On utilise alors un
multiplexage TDD. La reutilisation spatiale reste possible, mais un nud qui emet empeche
laccès au canal radio par tous les mobiles se trouvant dans un voisinage etendu autour de
lui.
Lenergie. Dans un reseau à stations de base, les dites stations sont en general alimentees sur
le secteur. Dans un reseau ad-hoc ces stations sont absentes. De plus, suivant la topologie du
reseau, certains mobiles peuvent se trouver dans des positions clef et assurer le routage pour
un grand nombre de flux (entre plusieurs sous-parties du reseau autrement independantes par
exemple). Ces nuds peuvent etre amenes à consommer très vite leurs ressources energetiques.
Le trafic de controle peut egalement avoir un impact important. Comme un reseau ad-hoc
doit sauto-organiser, cela signifie que dune manière ou dune autre il va y avoir un trafic de controle dependant de la mobilite dans le reseau. Plus la topologie changera vite et
profondement, plus la charge (et donc la consommation denergie) du trafic de controle sera
importante.
La mobilit
e. Limpact dune mobilite totale est important à differents niveaux. Du point
de vue des couches basses (PHY et MAC), comme nous lavons dejà souligne, il nest dune
part plus possible daffecter des frequences à des zones geographiques ; dautre part, les
mecanismes daccès au medium utilisant des horloges globales seront egalement inutilisables
(TDMA par exemple a besoin dune grande synchronisation des horloges qui est impossible
dans ce contexte). A un niveau plus eleve, dans les reseaux à stations de base (en particulier
à grande echelle comme dans les reseaux de telephonie mobile), le routage est effectue dans la
partie fixe du reseau. Dans le cas des reseaux ad hoc, lensemble du routage doit fonctionner
sur les mobiles et de facon totalement distribuee. Cela necessite de nouveaux algorithmes et
les contraintes à leur realisation sont plus importantes.
12

AD HOC
La faible s
ecurit
e. Dans les reseaux ad hoc, non seulement les donnees sont vulnerables
comme dans tout reseau radio, mais consecutivement au point precedent, il en est de meme
pour le trafic de controle et de gestion du routage [12, 13]. Les problematiques de la securite
dans les reseaux ad hoc sont donc très complexes, puisque lon cherche à autoriser de nouveaux
mobiles à participer au reseau, tout en evitant des nuds malins qui detourneraient ou
perturberaient le fonctionnement meme du routage.
La qualit
e de service. De nombreuses applications ont besoin de certaines garanties relatives par exemple au debit, au delai ou encore à la gigue. Dans ces reseaux ad hoc, ces
garanties sont très difficiles à obtenir. Ceci est d
u à la nature du canal radio dune part (interferences et taux derreur eleves) et au fait que des liens entre des mobiles peuvent avoir
à se partager les ressources (alors quen filaire, deux liens sont par definition independants).
De ce fait, les protocoles de qualite de service habituels (par exemple IntServ / RSVP ou DiffServ) ne sont pas utilisables directement dans le monde ad hoc et des solutions specifiques
doivent etre proposes [14, 15].
1.3
Routage
Les reseaux ad hoc que nous considerons sont multi-sauts. Il peut donc arriver quun mobile
veuille communiquer avec un autre qui nest pas dans sa portee de communication directe. Les
messages vont devoir etre transmis de proche en proche jusquà la destination : cest ce que lon
appelle le routage. La technique la plus basique est linondation, o`
u chaque mobile re-emet tous
les paquets quil recoit pour la première fois. Evidemment, linondation consomme beaucoup de
ressources (bande passante et energie) et nest pas optimale. De nombreux protocoles de routage
ont donc ete proposes pour rendre les communications multi-sauts plus efficaces (moins de reemissions, chemins plus courts, etc.) que linondation basique.
Meme si elle nen constitue pas le fondement, la connaissance des protocoles de routage du monde
ad hoc est necessaire au travail que nous avons mene. Nous allons voir plus loin que les phenomènes
des niveaux physique et MAC ont des impacts importants sur les protocoles de niveaux superieurs.
Mais ces impacts varient grandement en fonction des techniques utilisees pour le routage.
Dans cette section, nous allons donc presenter certains des protocoles de routage developpes
dans le cadre du groupe de travail MANET de lIETF. Ces protocoles travaillent au niveau IP
et sont donc independants des couches physique et MAC. Le routage IP permet en particulier
une interconnectivite aisee avec toutes sortes dautres reseaux ou materiels. Il est dailleurs possible dutiliser ces protocoles pour federer en un seul reseau MANET des utilisateurs utilisant des
materiels differents (cartes radios de technologies diverses, reseaux filaires, etc.). Les protocoles
presentes sont parmi les plus representatifs des diverses techniques utilisees pour le routage ad hoc.
1.3.1
Routage hi
erarchique ou plat
Les protocoles de routage pour les reseaux ad hoc peuvent etre classes suivant plusieurs critères.
Le premier dentre eux concerne le type de vision quils ont du reseau et les roles quils accordent
aux differents mobiles.
Les protocoles de routage `
a plat considèrent que tous les nuds sont egaux (figure 1.2).
La decision dun nud de router des paquets pour un autre dependra de sa position et pourra
etre remise en cause au cours du temps.
13

AD HOC
P2
P1
P3
N2
N10
N7
N1
N3
N9
N5
N2
N6
N4
N11
N8
N6
N1
N8
N3
N7
N4
N5
Fig. 1.2 Routage à plat
Fig. 1.3 Routage hierarchique
Les protocoles de routage hi

erarchique fonctionnent en confiant aux mobiles des roles qui
varient de lun à lautre. Certains nuds sont elus et assument des fonctions particulières qui
conduisent à une vision en plusieurs niveaux de la topologie du reseau. Par exemple, un mobile
pourra servir de passerelle pour un certain nombre de nuds qui se seront attaches à lui. Le
routage en sera simplifie, puisquil se fera de passerelle à passerelle, jusquà celle directement
attachee au destinataire. Un exemple est donne sur la figure 1.3, o`
u le nud N3 passe par
les passerelles P1, P2 et P3 pour atteindre N7. Dans ce type de protocole, les passerelles
supportent la majeure partie de la charge du routage (les mobiles qui sy rattachent savent
que si le destinataire nest pas dans leur voisinage direct, il suffit denvoyer à la passerelle qui
se debrouillera). Dans les reseaux o`
u certains nuds savèrent très sedentaires et disposent
de suffisamment denergie (par exemple reseau dordinateurs portables mais o`
u certains sont
relies au secteur, stations de base disposees là pour garantir la connectivite, etc.) , ce type de
routage presente certains avantages.
1.3.2
Etat de liens ou vecteur de distance
Une autre classification, heritee du monde filaire, est possible pour les protocoles de routage :
Les protocoles `
a
etat de lien. Ils cherchent à maintenir dans chaque nud une carte plus ou
moins complète du reseau o`
u figurent les nuds et les liens les reliant. A partir de cette carte il
est possible de construire les tables de routage. Un des avantages de ce type de protocole est leur
capacite à pouvoir facilement trouver des routes alternatives lorsquun lien est rompu. Il est meme
possible dutiliser simultanement plusieurs routes vers une meme destination, augmentant ainsi la
repartition de la charge et la tolerance aux pannes dans le reseau. En contre partie, si le reseau est
etendu, la quantite dinformations à stocker et diffuser peut devenir considerable.
Les protocoles `
a vecteur de distance. Plutot que de maintenir une carte complète du reseau
(ce qui peut saverer extremement lourd), ces protocoles ne conservent que la liste des nuds du
reseau et lidentite du voisin par lequel passer pour atteindre la destination par le chemin le plus
court. A chaque destination possible sont donc associes un next-hop et une distance. Si un voisin
nous envoie un paquet de controle dans lequel il indique etre plus près dune destination que le nexthop que lon utilisait jusqualors, alors il le remplace dans la table de routage. Un des inconvenients
de cette technique et quil nest du coup plus possible de conserver plusieurs routes alternatives au
cas o`
u celle qui est privilegiee serait rompue.
14

AD HOC
1.3.3
Les diff
erentes familles de protocoles de routage MANET
Dans les travaux menes à lIETF, plusieurs familles de protocoles se sont rapidement degagees.
Chaque protocole peut ainsi etre classifie en tant que reactif, proactif, ou hybride.
Les protocoles r
eactifs
Le principe des protocoles reactifs est de ne rien faire tant quune application ne demande pas
explicitement denvoyer un paquet vers un nud distant. Cela permet deconomiser de la bande
passante et de lenergie. Lorsquun paquet doit etre envoye, le protocole de routage va rechercher
un chemin jusquà la destination. Une fois ce chemin trouve, il est inscrit dans la table de routage
et peut etre utilise. En general, cette recherche se fait par inondation (un paquet de recherche
de route est transmis de proche en proche dans tout ou partie du reseau). Lavantage majeur de
cette methode est quelle ne genère du trafic de controle que lorsquil est necessaire. Les principales
contre-parties sont que linondation est un mecanisme co
uteux qui va faire intervenir tous les nuds
du reseau en très peu de temps et quil va y avoir un delai à letablissement des routes.
Les protocoles proactifs
Le principe de base des protocoles proactifs est de maintenir à jour les tables de routage,
de sorte que lorsquune application desire envoyer un paquet à un autre mobile, une route soit
immediatement connue. Dans le contexte des reseaux ad-hoc les nuds peuvent apparatre ou
disparatre de manière aleatoire et la topologie meme du reseau peut changer ; cela signifie quil va
falloir un echange continuel dinformations pour que chaque nud ait une image à jour du reseau.
Les tables sont donc maintenues grace à des paquets de controle, et il est possible dy trouver
directement et à tout moment un chemin vers les destinations connues en fonctions de divers
critères. On peut par exemple privilegier les routes comportant peu de sauts, celles qui offrent
la meilleure bande passante, ou encore celles o`
u le delai est le plus faible. Lavantage premier de
ce type de protocole est davoir les routes immediatement disponibles quand les applications en
ont besoin, mais cela se fait au co
ut dechanges reguliers de messages (consommation de bande
passante) qui ne sont certainement pas tous necessaires (seules certaines routes seront utilisees par
les applications en general).
Les protocoles hybrides
Les protocoles hybrides combinent les approches reactive et proactive. Le principe est de
connatre notre voisinage de manière proactive jusquà une certaine distance (par exemple trois
ou quatre sauts), et si jamais une application cherche à envoyer quelque chose à un nud qui nest
pas dans cette zone, deffectuer une recherche reactive à lexterieur. Avec ce système, on dispose
immediatement des routes dans notre voisinage proche, et lorsque la recherche doit etre etendue
plus loin, elle en est optimisee (un nud qui recoit un paquet de recherche de route reactive va
tout de suite savoir si la destination est dans son propre voisinage. Si cest le cas, il va pouvoir
repondre, et sinon il va propager de manière optimisee la demande hors de sa zone proactive). Selon
le type de traffic et de les routes demandees, ce type de protocole hybride peut cependant combiner
les desavantages des deux methodes : echange de paquets de controle reguliers et inondation de
lensemble de reseau pour chercher une route vers un nud eloigne.
15

AD HOC
1.3.4
Description de quelques protocoles de routage repr

esentatifs
Les protocoles decrits par la suite sont issus du groupe de travail MANET de lIETF. Ces
protocoles sont representatifs de diverses techniques et sont les plus avances sur la voie dune
normalisation. AODV et OLSR font desormais lobjet dune Request For Comment (RFC) tandis
que les autres en sont à des versions assez stabilisees de leur drafts.
Ad-hoc On Demand Distance Vector (AODV)
AODV [16] est un protocole base sur le principe des vecteurs de distance et appartient à la famille
des protocoles reactifs. Les protocoles à vecteur de distance sont en general sujets au problème de
boucle et de comptage à linfini de lalgorithme de Bellman-Ford quils utilisent (certaines parties du
reseau se trouvent isolees du reste, et les nuds les composant vont croire quils peuvent atteindre les
nuds desquels ils sont coupes en passant par leurs voisins. Il sen suit un phenomène de bouclage
dans lequel les nuds injoignables se voient attribuer des distances de plus en plus grandes).
Dans le cas dAODV, ces problèmes sont resolus par lutilisation de numeros de sequence pour les
messages de controle. Quand une application a besoin denvoyer des paquets sur le reseau et quune
route est disponible dans la table de routage, AODV ne joue aucun role. Sil ny a pas de route
disponible, il va par contre en rechercher une. Cette recherche commence par une inondation de
paquets Route Request (RREQ). Chaque nud traverse par un RREQ en garde une trace dans
son cache et le retransmet. Quand les paquets de recherche de route arrivent à la destination (ou
à un nud intermediaire qui connait lui-meme une route valide jusquà la destination), alors un
paquet de reponse est genere (RREP) et il est envoye par le chemin inverse, grace aux informations
gardees dans les caches des nuds traverses par les RREQ (voir figure 1.4). AODV dispose dun
certain nombre de mecanismes optimisant son fonctionnement. Linondation se fera par exemple
au premier essai dans un rayon limite autour de la source, et si aucun chemin nest trouve, alors
seulement elle sera etendue à une plus grande partie du reseau. En cas de rupture de certains liens,
AODV va essayer de reconstruire localement les routes affectees en trouvant des nuds suppleants
(cette detection de rupture peut dailleurs se faire grace à un mecanisme optionnel de paquets hello
diffuses aux voisins directs uniquement). Si une reconstruction locale nest pas possible, alors les
nuds concernes par la rupture des routes utilisant ce lien sont prevenus de sorte quils pourront
relancer une nouvelle phase de reconstruction complète.
Dynamic Source Routing (DSR)
DSR [17] est un autre protocole reactif. Il se differencie des autres en particulier parce quil
pratique le source routing : lemetteur precise dans len-tete de chaque paquet la liste des nuds
quil devra traverser pour atteindre sa destination. Ce type de routage presente certains avantages
particulièrement interessants ; il autorise en particulier la source à conserver dans sa table de routage
plusieurs chemins valides vers une meme destination. Le choix du chemin emprunte pourra donc
etre fait independamment pour chaque paquet, et permettre un meilleur equilibrage de la charge
du reseau ou une meilleure reactivite aux pannes / changements de topologie (plutot que de tout
de suite en construire une nouvelle quand une route est brisee, on en a dautres à disposition
immediate). Dans la pratique, DSR est structure en deux sous-parties complementaires : la recherche
de route et la maintenance de route. La recherche de route se fait par inondation : un paquet de
recherche est diffuse de proche en proche jusquà la destination. Au fur et à mesure, les identifiants
des nuds traverses sont ajoutes dans le paquet de recherche de route. Quand elle recoit ce paquet,
16

AD HOC
Source
Source
rreq (1)
rreq (1)
rreq (1)
rrep (4)
rreq (1)
rrep (4)
rreq (2)
A
rrep (4)
rreq (2)
A
rrep (3)
rrep (3)
rreq (2)
rreq (2)
rrep (3)
D
rreq (3)
rreq (2)
rreq (3)
rreq (2)
rreq (3)
rrep (2)
rrep (2)
rreq (3)
rrep (2)
rreq (4)
C
rreq (4)
rrep (1)
C
F
F
rreq (4)
rrep (1)
rreq (4)
rrep (1)
Dest.
Fig. 1.4 Recherche de route par inondation

(AODV)
Dest.
Fig. 1.5 Recherche de route par inondation

(DSR)
la destination sait donc dejà quel chemin il a emprunte, et obtient ainsi (en linversant) la route
pour retourner à la source. A la reception par la destination de paquets de recherche ayant suivi des
chemins differents, la destination repond sur les chemins inverses, et la source aura ainsi finalement
plusieurs chemins valides pour latteindre (voir figure 1.5).
Optimized Link State Routing (OLSR)
OLSR [18] est un protocole proactif à etat de liens. Afin de maintenir à jour les tables de
routage, chaque nud implementant OLSR diffuse regulièrement des informations sur son propre
voisinage. Ces informations sont suffisantes pour permettre à chaque nud de reconstruire une
image du reseau et de trouver une route vers nimporte quelle destination. Mais contrairement `
a
des protocoles tels quOSPF, cette diffusion ne se fait pas par une simple inondation (o`
u chaque
nud retransmet simplement chaque nouveau paquet quil recoit) ; OLSR optimise la diffusion
grace au système des relais multi-points (Multi-Points Relays : MPR). Chaque nud choisit dans
ses voisins directs un sous-ensemble minimal de nuds qui lui permettent datteindre tous ses
voisins à deux sauts (voir figure 1.6). La diffusion des informations sur les liens utilisees pour le
routage se fait ensuite uniquement par les relais multi-points ; la couverture totale du reseau est
assuree tout en limitant sensiblement le nombre de re-emissions. Afin de choisir ses relais multipoints, un nud a besoin de connaitre complètement la topologie de son voisinage à deux sauts ;
cela est realise grace à lenvoi periodique de paquets hello contenant la liste des voisins à un saut
connus.
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
TBRPF [19] est un protocole de routage proactif à etat de liens. Chaque nud maintient en
permanence un arbre dont il est la racine et qui fournit les chemins les plus courts pour tous les
autres nuds du reseau. TBRPF est constitue de deux parties complementaires : la decouverte des
voisins et le routage proprement dit.
17

AD HOC
MPR
MPR
Source
MPR
Fig. 1.6 Relais multipoints
La decouverte des voisins est assuree par un mecanisme de paquets hello diffuses regulièrement
au voisinage direct. Ces paquets hello contiennent la liste des voisins du nud, et permettent
ainsi de rapidement connatre la topologie complète du reseau à deux sauts. Il faut noter que
TBRPF emploie une technique de hello differentiels o`
u seuls les changements de topologie sont
notifies (diminuant ainsi la taille moyenne des paquets et autorisant leur envoi à une plus grande
frequence).
La partie routage quant à elle est basee sur un echange des arbres de routage entre nuds
voisins, conduisant progressivement à la diffusion de linformation dans lensemble du reseau.
Là encore cependant seules des parties darbres sont echangees. Normalement, un nud ne
diffuse quun sous-arbre à deux niveaux dont il est la racine. Au premier niveau apparaissent les
liens vers tous les voisins directs du nud, et au deuxième niveau un unique lien vers chaque
voisin à deux sauts (on peut noter ici une certaine similitude avec le mecanisme des relais
multi-points dOLSR). En conjonction avec ce système de base, TBRPF peut egalement ajouter
des informations sur dautre liens à larbre diffuse, avant de reagir plus vite en cas de changement
de la topologie. A noter enfin que dans un souci deconomie de bande passante, les sous-arbres et
les paquets hello sont regroupes autant que possible dans un meme paquet (on parle dagregation
ou piggybacking puisque lon profite des paquets hello pour envoyer en meme temps les sous-arbres).
De nombreux autres protocoles de routage ont ete proposes pour les reseaux ad hoc. [20]
en decrit un certain nombre en sus de ceux dejà mentionnes. Dans la categorie des protocoles
construisant une topologie hierarchique on peut citer Clusterhead Gateway Switch Routing
(CGSR) presente dans [21]. Certains autre protocoles necessitent lemploi de materiels externes.
Par exemple Temporaly-Ordered Routing Algorithm (TORA) [22] a besoin que les mobiles
soient synchronises. Dautres ([23],[24]) utilisent le système GPS pour estimer la direction
geographique de la destination et ne faire intervenir quune sous-partie du reseau dans la phase
de construction des routes. Alors que beaucoup de protocoles cherchent à minimiser le nombre de
18

AD HOC
sauts (minimum shortest path), certains protocoles enfin sattachent à prendre dautres critères
en consideration. ABR (Associativity-Based Routing) [25] par exemple privilegie les liens les
plus stables (mobiles qui restent longtemps dans le voisinage les uns des autres). SSR (Signal
Stability Routing) [26] travaille à partir des informations de niveau de signal et [27] cherche à maximiser la duree de vie du reseau en agissant sur la puissance demission de chaque mobile separement.
Les reseaux ad hoc font partie dun domaine de recherche qui na pris son essor que très
recemment. Le facteur qui a declenche cet interet fut larrivee de technologies relativement bon
marche qui ont favorise la conception et le deploiement de tels reseaux. Avant cela, ce domaine
etait reserve aux militaires qui disposaient de moyens tout autres.
Les principales normes de reseaux sans fil qui sont à lorigine cet interet pour les reseaux ad
hoc sont HiperLAN 1 [28] et 2 [29], Bluetooth [30] et 802.11 [31] de lIEEE.
19
CHAPITRE
Pr
esentation de 802.11
Dans la seconde moitie des annees 90, plusieurs normes pour les reseaux sans fils à portee limitee
on ete developpees (visant des usages à lechelle du bureau ou du batiment). Leur arrivee à souleve
un engouement nouveau pour les reseau radio multi-sauts, qui etaient jusqualors le domaine exclusif
des militaires. Dans ce chapitre, nous allons presenter ces differentes normes, et en particulier 802.11,
qui est desormais utilisee dans la plupart des travaux appliques de la communaute ad hoc.
2.1
Les autres normes de r

eseaux locaux sans fil.
Bluetooth a plutot pour objectif de faire disparatre les cable entre les divers equipements
numeriques (peripheriques dordinateurs tels que clavier, imprimantes, modems, ou encore appareils
photo numeriques, PDA, walkmans, etc.). Les equipements bluetooth ont donc des portees et des
debits assez modestes, ainsi quune consommation electrique en rapport.
802.11 est concue pour les reseaux locaux, en entreprise ou chez les particuliers. Cette norme
sappuie sur des stations de base reliees à un reseau filaire qui fournir une infrastructure fixe et
reliant les utilisateurs mobiles aux ressources de lentreprise (et eventuellement à lInternet). Depuis
peu, 802.11 (et en particulier les cartes compatibles à son extension 802.11b) connaissent un succès
commercial considerable.
HiperLAN type 1 a ete concu comme le pendant europeen de 802.11. Cette norme se veut assez
similaire dans son utilisation, mais certains choix technologiques ont ete faits qui se demarquent
nettement de 802.11. Commercialement cependant HiperLAN est reste à letat de prototype et nest
jamais sorti des laboratoires de recherche.
HyperLan type 2 a pour but de concurrencer les versions les plus performantes de 802.11
(802.11a et 802.11g) en offrant des debits aussi eleves et un certain nombre de fonctionnalites
supplementaires. Mais là encore, il est à craindre quHiperLAN 2 ne soit jamais commercialisee `
a
grande echelle.
2.1.1
HiperLAN 1
High Performance Local Area Network type 1 (HiperLan 1) est un standard de lEuropean
Technical Standard Institute (ETSI). Il decrit le fonctionnement dequipements travaillant dans la
bande des 5.15-5.30 GHz et permettant datteindre des debits de 23.5 Mbit/s sur une distance denviron 50 mètres. Larchitecture est totalement decentralisee. Il ny a pas de notion de point daccès
mais les nuds HiperLAN 1 peuvent cependant avoir des roles de passerelles. Les caracteristiques
les plus marquantes dHiperLAN 1 sont :
20

CHAPITRE 2. PRESENTATION
DE 802.11
le mecanisme daccès au medium evolue, qui gère les priorites. Il est possible dobtenir des
garanties de qualite de service, particulièrement utiles pour les flux multimedias par exemple ;
la possibilite detendre le reseau au delà de la portee radio, par sauts successifs (fonctionnement en cela très semblable aux reseaux ad hoc, des nuds jouant le role dintermediaires
entres ceux qui sont trop loin pour communiquer directement).
Les fonctionnalites dHiperLAN 1 sont organisees comme presente sur la figure 2.1. Nous nentrerons pas dans les details de cette norme complexe, mais nous pouvons remarquer neanmoins que
le mecanisme daccès au medium EY-NPMA (Elimination Yield-Non Preemptive Multiple Access)
est au cur du système. Cest lui qui permet en particulier la gestion des priorites. Le fonctionnement de EY-NPMA est particulièrement interessant puisquil est prevu pour fonctionner dans
un contexte ad hoc. Nous allons donc le decrire plus en avant. Il fonctionne en trois phases et un
exemple est donne sur la figure 2.2 :
La phase de priorit
e. Cinq niveaux de priorite sont definis par la norme (de 0 pour le
plus prioritaire à 4) et la phase de priorite est donc divisee en cinq slots. Au debut dun
nouveau cycle de transmission, tous les nuds qui veulent acceder au canal vont envoyer un
burst de signalement, dont la date de debut depend de la priorite du paquet. Plus la priorite
est elevee, plus le burst commence tot. Sur la figure, les nuds A, C et D ont une priorite
de 2, et le nud B a une priorite de 3. Lidee est decouter le canal tant que notre priorite
nous interdit demettre notre propre burst de signalement. Si lon detecte de lactivite avant
davoir pu emettre, cest que quelquun est plus prioritaire que nous, et lon abandonne lidee
de transmettre pour ce cycle. Cest le cas du nud B sur la figure 2.2.
La phase d
elimination. Il se peut que plusieurs nuds veuillent emettre en meme temps
des paquets de priorites identiques. Il faut donc les departager. Pour cela, chaque nud va
poursuivre lenvoi de son burst de signalement pendant un nombre aleatoire de slots. Ce sera
celui qui aura tire le plus grand nombre qui lemportera. Dès que lemission de notre burst est
terminee, nous ecoutons le canal. Si nous y detectons de lactivite, cest quun autre nud a
tire un plus grand nombre que nous, et nous abandonnons pour ce cycle. Sur la figure, cest
le cas du nud C .
La phase d
ecoute. Si toutefois il reste plusieurs nuds en lice alors lelimination va se
terminer dans la troisième phase. Un nombre aleatoire de slots est choisit. Cest celui qui
aura tire le plus petit qui pourra transmettre. Chaque nud attend pendant la duree quil a
determine, en ecoutant le canal. Si il detecte de lactivite alors quil na pas fini dattendre,
il sait que quelquun a tire un plus petit nombre que lui et nemettra pas durant ce cycle. Si
son attente se termine alors que le canal est toujours libre, alors il emet. Sur la figure, cest
le nud D qui lemporte. Il faut noter que si le paquet est envoye en point à point, il sera
acquitte par son recepteur (ici le nud E).
Avec HiperLAN type 1, un mecanisme de routage multi-sauts est implante. Les nuds envoient
des paquets hello qui leur permettent de connatre leur voisinage. Ces informations de voisinage
sont propagees dans tout le reseau et permettent ainsi à un nud den reconstruire la topologie.
Cest un protocole à etat de lien qui utilise une système de relais multipoints pour optimiser les
diffusions dinformations.
21
Couches suprieures
ou
te
na
Ph
as
ed
'c
mi
'li
ed
B
C
Accs multiple
et gestion du
trafic multimdia
Relayage et
gestion des
informations
topologiques
Economie
d'nergie
DATA
Couche physique
Fig. 2.1 Organisation dHiperlan 1
2.1.2
as
Systme de cryptage
Systme de
connaissance
du rseau
Ph
Ph
as
ed
ep
rio
r
it
tio
DE 802.11
fin du cycle
prcdent
ACK
Les trois phases
de l'accs multiple
Accus de rception
(uniquement pour le trafic point
point)
Fig. 2.2 Laccès au canal avec EY-NPMA
HiperLAN 2
Lorganisation generale dHiperLAN type 2 est presentee sur la figure 2.3. On remarque en
premier lieu que la norme prevoit la compatibilite avec diverses technologies (TCP/IP bien s
ur,
mais aussi ATM, UMTS et lIEEE 1394 connue aussi sous le nom de Firewire).
HiperLAN type 2 est très different dans son architecture dHiperLAN type 1. Contrairement
au type 1, le type 2 est base sur une centralisation poussee. Les points daccès sont dailleurs
indifferemment appeles Access Points (AP) ou Central Controler (CC). Les points daccès sont
relies entre eux par une infrastructure reseau filaire ou non-filaire (qui doit simplement disposer
dune interface adequate dans HyperLAN 2, comme celles de la liste donnee precedemment). Les
mobiles sattachent ensuite à ces points daccès pour acceder aux ressources du reseau.
HiperLAN 2 peut aussi fonctionner sans infrastructure fixe. Dans ce cas, un mobile est elu pour
jouer le role de controleur central et les autres vont sattacher à lui. Bien entendu, dans ce type
de configuration il nest pas question de reseau ad hoc au sens o`
u le groupe MANET lentend.
Tout au plus, les mobiles pourront communiquer directement entre eux (un saut), ou alors par
lintermediaire du controleur central (deux sauts).
Laccès au medium reflète ces choix architecturaux, et cest le controleur central qui decide de
lordonnancement des communications dans la zone quil gère. Ces communications se font gr
ace `
a
des trames de duree fixe (2 ms) qui sont elles-memes decoupees en differents champs de longueur
variable et qui portent les informations de controle du point daccès ou les donnees dans un sens ou
dans lautre. Il faut noter egalement que la couche physique dHiperLAN type 2 est très semblable
à la couche physique de 802.11a (qui sera presentee plus en detail dans la section dediee à 802.11).
De part son architecture très ciblee, HiperLAN 2 est donc peu adapte aux reseaux ad hoc, et
nous ne detaillerons pas plus cette norme ici.
2.1.3
Bluetooth
Les reseaux Bluetooth ont ete developpe pour permettre la realisation de reseaux personnels
(PAN : Personnal Area Network). Ces reseaux doivent permettre des communications à courte
portee, à des debits faibles ou moyens entre toute sorte dequipements. Ils travaillent dans la bande
22

DE 802.11
TCP/IP
ATM /
B-ISDN
UMTS
IEEE
1394
Couche de convergence rseau (NC)
Couche liaison
(DLC)
Couche Physique
Fig. 2.3 Lorganisation generale dHiperLAN type 2
ISM des 2.4 GHz à des puissances leur permettant datteindre des portees allant du mètre `
a la
centaine de mètres environ.
Cest le groupe de travail Bluetooth SIG (Bluetooth Special Interest Group) qui a elabore les
specifications de Bluetooth. Ce groupe de travail, au depart constitue de grosses societes de linformatique et des telecommunications telles quIBM, Ericsson, Intel ou Nokia, a rapidement pris de
lampleur et regroupe actuellement plus de 2500 societes.
Il faut noter que le Bluetooth SIG nest pas le seul organisme produire des specifications dans
ce domaine, le groupe de travail 802.15 de lIEEE completant et prolongeant ces travaux dans
plusieurs directions :
Le sous-groupe 802.15.1. Il a pour role, en accord avec le Bluetooth SIG, de traduire les
specifications Bluetooth en specifications de type 802.
Le sous-groupe 802.15.2. Il doit etudier les configurations des reseaux personnels et notamment la coexistence de ces reseaux avec les reseaux locaux sans fils (du type de 802.11).
Le sous-groupe 802.15.3. Il travaille sur les specifications dun reseau personnel à haut
debit (de lordre de 20 Mbit/s).
Le sous groupe 802.15.4. Il etudie les specifications pour des reseaux personnels `
a bas
debit (de lordre de 200 kbit/s).
Les reseaux Bluetooth sont construit de manière centralisee. Un matre elu peut prendre en
charge jusquà huit esclaves et forme ainsi un piconet. Dans un piconet, cest le matre qui contr
ole
toutes les transmissions. Les esclaves ne peuvent emettre des paquets que sils y ont ete invites
par le matre. Ce dernier doit donc les interroger regulièrement pour savoir sils ont des donnees `
a
envoyer (polling).
Plusieurs piconets peuvent etre relies afin de former une structure plus grande appelee
scatternet (de langlais scatter, disperse). A cette fin, les mobiles peuvent quitter temporairement
leur piconet pour aller sattacher à un autre. La figure 2.4 donne un exemple de scatternet. Un
esclave alterne entre les piconets 1 et 2 afin den assurer la liaison et un mobile esclave du piconet
2 est aussi matre dans le piconet 3 (le processus de de-association est reversible, il est possible de
quitter temporairement un piconet puis de le rejoindre à nouveau et de revenir à la situation initiale).
Laccès au medium dans Bluetooth est gere par intervalles de temps reguliers (slotted). Le slot
de base a une duree de 625 s. Au niveau physique, Bluetooth fonctionne par sauts de frequence
très rapides (jusquà 1600 sauts par seconde). La frequence reste la meme pour la duree dun slot.
En general, sauf si le paquet à transmettre est trop long pour tenir sur un seul slot auquel cas il en
occupe plusieurs, la frequence change après chaque slot selon un schema cyclique.
23

DE 802.11
Esclave
Esclave
Esclave
Matre
Matre
Esclave
Matre
dans P3
Esclave
dans P2
Esclave
Esclave
Esclave
Piconet 1 (P1)
Piconet 2 (P2)
Esclave
Piconet 3 (P3)
Scatternet
Fig. 2.4 Un scatternet Bluetooth
Là encore nous nentrerons pas plus en avant dans la description de la norme. Avec ses scatternet,
Bluetooth presente bel et bien une forme de reseau ad hoc multi-sauts. Mais du fait de lutilisation
ciblee pour un usage personnel, ces reseaux restent assez statiques et leur etendue volontairement
limitee.
2.2
Introduction `
a 802.11
802.11 [31, 32] est une norme etablie par lIEEE. Elle decrit les couches physique et MAC
dinterfaces reseau radio et infra-rouge. Les debits possibles varient entre 1 et 54 Mbit/s suivant
les techniques et les eventuelles extensions de la norme employees. Les portees prevues varient
entre quelques dizaines et quelques centaines de mètres en fonction de la vitesse choisie et de
lenvironnement. Cette norme cible deux contextes dutilisation :
Le mode infrastructure (lutilisation privilegiee de 802.11), o`
u des stations de base
reliees entre elles par un reseau filaire assurent la couverture dune certaine zone et prennent
en charge les mobiles dans leur voisinage (figure 2.5).
Le mode appel
e ad hoc, qui consiste en fait simplement à autoriser les communications
entre deux mobiles à portee lun de lautre, sans intervention de stations ou dautres mobiles
exterieurs (figure 2.6).
La norme originelle 802.11 date de 1997 et decrit les couches physiques et MAC pour un debit
allant jusquà 2 Mbit/s en radio, dans la bande des 900MHz. Des extensions ont ete publiees depuis
qui viennent lui ajouter des ameliorations et des modes de fonctionnement plus performants. Les
principales extensions sont les suivantes :
802.11 (version de 1999) passe dans la bande ISM des 2.4 GHz, avec toujours des debits
pouvant atteindre les 2 Mbit/s. Cette bande de frequence est partagee avec dautres types de
reseaux locaux sans fil (Bluetooth en particulier) ainsi que par diverses autres applications.
802.11b ajoute la description dune couche physique amelioree proposant des debits de 5.5
et 11 Mbit/s en plus de ceux dejà supportes.
24

DE 802.11
Station
de base
Station
de base
Fig. 2.5 Reseau 802.11 en mode infrastructure
802.11 Logical Link Control (LLC)
OSI Layer 2
Data Link Layer
OSI Layer 1
Physical Layer
(PHY)
Fig. 2.6 Reseau 802.11 ad-hoc
802.11 Medium Access Control (MAC)

FHSS
DSSS
IR
Wi-Fi
Wi-Fi5
802.11b 802.11a
...
Fig. 2.7 Les couches et sous-couches OSI definies par 802.11
802.11a ajoute des modes encore plus rapides (jusquà 54 Mbit/s) en travaillant dans la
bande des 5GHz, mais en utilisant des techniques OFDM (presentees succinctement dans la
section suivante) daccès au canal.
802.11g utilise des technique OFDM similaires 802.11a, mais en restant dans la bande ISM
à 2.4GHz. Les debits possibles atteignent egalement les 54 Mbit/s tout en gardant la compatibilite avec les equipements 802.11b.
802.11e cherche à ameliorer 802.11 de facon à pouvoir donner des garanties de qualite de
service. Cette extension de la norme nest pas encore finalisee.
802.11h cherche à mieux gerer la puissance demission et la selection des canaux dans la
bande des 5 GHz suivant si lon est à linterieur ou à lexterieur de batiments. Lobjectif est
detre, à terme, mieux en accord avec les diverses legislations (notamment europeennes).
802.11i cherche à ameliorer les mecanismes de securite et dauthentification ; ce travail nest
pas encore finalise non plus.
Afin de permettre la mise en place de ces differentes ameliorations et de presenter aux couches
superieures une interface très similaire à 802.3 (le celèbre Ethernet), 802.11 propose le modèle en
couches de la figure 2.7. La sous-couche LLC est linterface visible de 802.11, cest par son intermediaire que les grandes similitudes avec 802.3 sont possibles. La sous-couche daccès au medium
(MAC) est specifique à 802.11, mais reste la meme quelles que soient les couches physiques employees en-dessous. Pour finir, un certain nombre de couches physiques sont definies. Originellement
seules une couche infra-rouge et une couche radio dans la bande des 900MHz etaient definies. La
couche physique radio proposait dejà plusieurs techniques de modulation (FHSS et DSSS, presentees
elles aussi dans la section suivante) à utiliser en fonction du debit desire (qui pouvait aller jusqu`
a
2 Mbit/s). Par la suite dautres couches physiques ameliorees ont ete ajoutees. Les plus importantes
de ces couches PHY dans le contexte des reseaux ad hoc seront decrites dans la section suivante.
25

DE 802.11
2.3
La couche physique
Initialement, le standard IEEE 802.11 permet lutilisation de trois couches physiques differentes
(FHSS, DSSS et IR), auxquelles 802.11a a ajoute ODFM :
FHSS : Frequency Hoping Spread Spectrum. La plupart des interferences nuisibles aux transmissions radio nagissent en fait que sur des bandes de frequence assez etroites. Si par malchance de telles interferences ont lieu au moment ou lon transmet, alors notre signal sera
fortement degrade. Une technique pour proteger notre signal consiste à regulièrement changer
de frequence (figure 2.8). Bien s
ur les paquets envoyes sur la bande perturbee seront affectes,
mais ils ne representeront plus quune minorite des transmissions et leur retransmission sera
moins co
uteuse. Lemetteur et le recepteur doivent connatre à lavance le sequencement des
sauts de frequence, mais des informations portees par les paquets permettent à un mobile
sattachant au reseau de savoir `
a partir dun paquet quil recoit o`
u en est le deroulement de
la sequence.
DSSS : Direct Sequence Spread Spectrum. Toujours pour lutter contre les interferences importantes mais naffectant que des plages de frequences assez etroites, il existe la technique de
letalement de spectre. Des manipulations sur le signal vont le faire occuper un spectre plus
large (on le multiplie par une sequence pseudo-aleatoire ayant certaines proprietes dautocorrelation). A la reception, une manipulation inverse est effectuee (figure 2.9). Cette technique est moins sensible aux interferences dues aux frequences parasites à faible largeur spectrale.
IR : Infra Red. Que lon ne detaillera pas ici du fait de son absence totale du marche.
OFDM : Orthogonal Frequency Division Multiplexing. Nous avons dejà mentionne le problème
des chemins multiples : lorsquun signal radio est emis, londe va se refracter, se reflechir et
donc se diviser sur les divers obstacles rencontres. A larrivee plusieurs chemins pourront
avoir ete empruntes, et leur temps de parcours netant pas forcement les memes, les multiples
refractions / reflexions dune meme onde vont interferer entre elles. Plus la difference de
temps de parcours sera grande vis à vis de la duree de transmission totale du symbole, plus
les chances que des reflexions / refractions de symboles consecutifs se chevauchent. Pour
augmenter le debit, lapproche traditionnelle consiste à reduire la duree dun symbole, mais
cela augmente aussi les problèmes de chemin multiple. OFDM propose donc dutiliser des
symboles plus longs, mais envoyes en parallèle. On peut dire pour resumer succinctement
cette methode quen presence de chemins multiples, à debit total equivalent, lagregation dun
certain nombre de canaux lents donne de meilleurs resultats quun seul canal très rapide.
A lorigine, la bande de frequence utilisee etait celle des 900MHz. Les extensions successives ont
ajoute dautres couches physiques afin de permettre des debits de plus en plus eleves en radio.
802.11 (version de 1999) La version de 1999 de 802.11 a remplace la bande des 900 MHz par
la bande ISM (2.4 GHz). Dans la bande ISM, 14 canaux radio de 20 MHz de largeur ont ete definis.
Suivant les reglementations, ils ne sont pas tous utilisables dans tous les pays (voir table 2.1).
Il nest possible pour un emetteur ou un recepteur de ne travailler que sur un seul canal `
a la
fois. Disposer de plusieurs canaux permet donc de les affecter aux stations de base de manière `
a ce
que deux cellules voisines ninterfèrent pas entre elles (on ameliore ainsi la reutilisation spatiale).
Un exemple est donne sur la figure 2.10.
26

DE 802.11
Temps
Amplitude
Interfrences
Message
transmettre
Interfrences
Message fortement
dgrad par les
interfrences
Frquence
Message peu
dgrad par les
interfrences
Etalement
de spectre
Frquence
Transmission
Fig. 2.8 Changer de frequence

regulièrement pour reduire limpact Fig. 2.9 Etaler le spectre pour reduire limpact de certaines interferences
de certaines interferences
Pays (organisme regulateur)
Etats-Unis (FCC)
Europe (ETSI)
Japon (MKK)
France (ART)
Bandes de frequence
2.400 - 2.485 GHz
2.400 - 2.435 GHz
2.471 - 2.497 GHz
2.400 - 2.454 GHz à 100 mW, 2.454 - 24835 GHz à 10 mW en exterieur
2400 - 2483.5 Ghz à 100mW en interieur
Tab. 2.1 Reglementations de la bande ISM
De plus, il faut preciser que ces canaux ne sont pas tous independants les uns des autres. Ils se
chevauchent en partie, comme presente sur la figure 2.11. Il faut egalement noter que la bande ISM
tend à etre saturee car de nombreux equipements lutilisent (dont bluetooth, 802.11b et 802.11g).
802.11b 802.11b (qui travaille toujours dans la bande des 2.4GHz) a ajoute une couche DSSS
modifiee (High Rate DSSS) avec une modulation CCK (Complementary Code Keying) et definit
ainsi les vitesses de 5.5 et 11 Mbit/s. Le canaux restent les memes et la compatibilite est preservee
avec les modes à 1 et 2 Mbit/s. Afin de garantir linteroperabilite des materiels 802.11b des differents
constructeurs, la WECA (Wireless Ethernet Compatibility Alliance1 ) a cree le label Wi-Fi. Les
1
www.weca.net
13
13
13
Fig. 2.10 Le reutilisation spatiale grace à un plan dallocation des frequences
27

DE 802.11
Canal 1
Canal 7
Canal 13
83 MHz
2.4 GHz
2.4835 GHz
Fig. 2.11 Le recouvrement des canaux dans la bande ISM
5.18 GHz
5.20 GHz
5.22 GHz
5.24 GHz
5.26 GHz
5.15 GHz
5.28 GHz
5.30 GHz
5.32 GHz
5.35 GHz
200 MHz
Fig. 2.12 Les 8 premiers canaux definis par 802.11a
produits estampilles Wi-Fi on ete analyses grace a des tests de compatibilite developpes par la
WECA et leur interoperabilite est donc garantie.
802.11a 802.11a passe dans la bande UN-II des 5GHz en utilisant une technique OFDM (Orthogonal Frequency Division Multiplexing). Cette fois-ci, 12 canaux disjoints de 20 MHz ont ete definis
(voir figure 2.12 pour les 8 premiers, les 4 derniers etant dans les 5.7 GHz). La bande UN-II est
moins encombree que la bande ISM. Lautre principal utilisateur de la bande UN-II est HiperLan
2, qui nest pas repandu commercialement. 802.11a autorise des debits allant jusquà 54 Mbit/s,
mais cela se fait au detriment de la portee de communication qui nexcède pas quelques dizaines de
mètres aux debits les plus eleves. De facon similaire au label Wi-Fi des produits 802.11b, le label
Wi-Fi5 de la WECA garantit linteroperabilite des produits 802.11 le portant.
802.11g 802.11g, publiee après 802.11a travaille dans la meme bande ISM que 802.11b mais
utilise les memes techniques OFDM que 802.11a afin de permettre des debits allant egalement
jusquà 54 Mbit/s. Là aussi, la compatibilite est preservee avec 802.11b. Il faut cependant noter
que les debits maximums ne peuvent etre obtenus quà courte portee et que si la station de base
et lensemble des mobiles de la cellule utilisent 802.11g.
La figure 2.13 recapitule les differentes technologies et debits possibles pour chacune dentre
elles.
2.4
La couche MAC
La couche MAC de 802.11 peut utiliser deux modes de fonctionnement.

Distributed Coordination Fonction (DCF) est un mode qui peut etre utilise par tous
les mobiles, et qui permet un accès equitable au canal radio sans aucune centralisation de la
28

DE 802.11
802.11
FHSS
1 Mbit/s
2 Mbit/s
802.11b
DSSS
1 Mbit/s
2 Mbit/s
802.11a
HR-DSSS
OFDM
5.5 Mbit/s
11 Mbit/s
6 Mbit/s
9 Mbit/s
12 Mbit/s
18 Mbit/s
24 Mbit/s
36 Mbit/s
48 Mbit/s
54 Mbit/s
802.11g
OFDM
Jusqu'
54Mbit/s
Fig. 2.13 Recapitulatifs des technologies et des debits possibles
gestion de laccès (mode totalement distribue). Ce mode peut aussi bien etre utilise lorsquil
ny a pas de stations de base (mode ad hoc) que lorsquil y en a (mode infrastructure).
Point Coordination Fonction (PCF) est un mode dans lequel les stations de base ont la
charge de la gestion de laccès au canal dans leur zone de couverture pour les mobiles qui leur
sont rattaches.
Dans les reseaux ad hoc multi-sauts, il ny a pas de stations de base fixes et cest donc le
mode DCF qui sera employe. Le mode DCF va etre decrit dans la sous-section suivante. Le mode
PCF sera neanmoins decrit brièvement lui aussi, dans la mesure o`
u les mecanismes quil utilise
sont fondamentaux dans 802.11 et que leur comprehension apporte à la comprehension globale du
comportement de 802.11 dans le contexte des reseau ad hoc.
2.4.1
Description du mode DCF
Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA)

Dans le monde filaire, lorsquun emetteur envoie un signal sur le cable, il peut y lire en meme
temps la valeur qui y est effectivement presente. Si jamais la valeur lue est differente de celle
que lemetteur ecrit, cest quun autre emetteur est actif au meme moment et quil y a collision.
Cette ecoute du signal sur le cable au moment de lemission est à la base de la methode daccès
CSMA/CD bien connue dEthernet. CSMA/CD permet de detecter une collision et le cas echeant
de retransmettre le paquet après un temps dattente aleatoire.
En radio cependant, lattenuation du signal en fonction de la distance est bien plus importante
que sur un cable. Au niveau dun emetteur, le signal quil envoie va donc etre recu avec une
puissance très superieure à un signal venant de nimporte quel autre mobile. Par exemple, sur la
figure 2.14 sont schematisees les puissances recues reciproquement par deux emetteurs A et B. Un
signal emis localement est recu avec une puissance tellement superieure aux autres signaux quil les
occulte complètement. Du point de vue dun emetteur, il ny a donc jamais de collision en radio.
Evidemment le problème se pose au niveau du recepteur, o`
u plusieurs signaux pourraient ainsi etre
recus simultanement avec des puissances comparables. Dans la pratique, des collisions se produisent
effectivement uniquement au niveau des recepteurs.
La première caracteristique de la couche MAC de 802.11 est donc dutiliser des acquittements
pour detecter ces collisions et permettre la retransmission des paquets qui ont ete perdus (en
labsence dacquittement, lemetteur sait quil doit retransmettre).
29

DE 802.11
Puissance perue
Emis par A
Emis par B
Position
Fig. 2.14 Lattenuation très rapide des signaux rend la detection de collision impossible
Il faut noter que 802.11 peut envoyer une trame à un recepteur specifique (unicast) ou la
diffuser (broadcast). Dans le cas de la diffusion, il ny a pas dacquittement et des paquets peuvent
etre perdus de manière tout à fait silencieuse (ce qui est logique, car chaque mobile ayant recu le
paquet chercherait à envoyer lacquittement au meme moment et il y aurait une serie de collisions
sur les acquittements).
En Ethernet, lidee est dobserver letat du canal avant demettre. Si le canal est libre, alors nous
pouvons envoyer notre trame (et si à ce moment-là nous detectons une collision, nous re-emettons
la trame un peu plus tard, après une attente de duree aleatoire). Or nous venons de voir quen
radio il netait pas possible de detecter directement les collisions. Par consequent, le mecanisme
qui conditionne lautorisation demettre sur le canal doit lui aussi etre modifie par rapport `
a ce
qui se fait en 802.3. En effet, si nous nous contentions dattendre que la canal devienne libre pour
emettre, alors si plusieurs mobiles etaient en attente demission, ils detecteraient tous le canal libre
et emettraient au meme moment. Il y aurait collision au recepteur et il faudrait attendre que le
delai imparti pour le retour de lacquittement soit ecoule pour sen rendre compte, ceci pourrait
etre relativement long.
Lidee retenue pour 802.11 est donc, lorsque le canal devient libre, dattendre une periode de
duree aleatoire supplementaire appelee backoff avant demettre. Ce mecanisme sapplique lorsque
le canal devient libre aussi bien après une de nos propres emissions quaprès toute autre emission.
Ainsi, si plusieurs mobiles veulent emettre, il y a peu de chances pour quils aient choisi la meme
duree. Celui qui a choisi le plus petit backoff va commencer à emettre, et les autres vont alors
se rendre compte quil y a à nouveau de lactivite sur le canal et vont attendre. La figure 2.15
schematise ce qui se passe lorsque deux mobiles à portee de communication veulent emettre vers
un troisième et que le canal devient libre.
Lorsque le canal devient libre, avant toute chose, il faut quil le reste pour une periode DIFS
(DCF Inter-Frame Space). Si le canal est reste libre durant toute cette periode, alors les mobiles
qui veulent emettre choisissent un backoff aleatoire exprime en un nombre de time slots dune duree
fixe de 20 s. Le backoff est choisit au hasard dans un intervalle appele Contention Window (CW)
qui est par defaut [0 ;31] ; avec un time slot de 20 s, le backoff va donc normalement etre compris
entre 0 et 620 s. Dans lexemple de la figure 2.15, le mobile 1 a tire 3 et le mobile 2 a tire 5. Une
fois ce tirage effectue, tant que le canal reste libre, les mobiles decrementent leur backoff. Dès que
lun deux a termine (ici le mobile 1), il emet. Lautre mobile, dès quil detecte le regain dactivite
sur le canal stoppe la decrementation de son backoff et entre en periode de defering.
30
SIFS
ba
DIFS
ck
off
DE 802.11
DIFS
SIFS
DATA
off
ACK
ba
ck
off
ck
ba
res
ACK
destination
defering
DATA
source 2
autre
tan
source 1
canal
occup
Fig. 2.15 Le backoff et le defering
Il faut noter que le temps de pause qui separe un paquet de donnees de son acquittement est
appele SIFS (Short Inter-Frame Space) et quil est plus court que DIFS. Le mobile en periode de
defering ne pourra reprendre la decrementation de son backoff que si le canal est à nouveau libre
pendant DIFS. Le fait que SIFS soit plus court empeche que la decrementation ne reprenne de
manière inopportune entre les donnees et leur acquittement.
Lorsque les donnees du mobile 1 ont ete acquittees et que DIFS sest ecoule sans activite sur
le canal, le mobile 2 peut reprendre la decrementation de son backoff. Ici, aucun autre mobile ne
vient lempecher de terminer et il peut donc finalement envoyer ses donnees.
Le mecanisme de backoff limite les risques de collision mais ne les supprime pas complètement.
Aussi, si une collision se produit quand meme (detectee grace à labsence dacquittement), un
nouveau backoff va etre tire au hasard. Mais à chaque collision consecutive, la taille de la fenetre
va doubler afin de diminuer les chances que de telles collisions se repètent. La borne inferieure de
la Contention Window est toujours zero, et la borne superieure (dont les valeurs autorisees par la
norme ne sont que des puissances de 2 moins 1) va evoluer entre les valeurs aCWmin et aCWmax
definies par la norme. La borne superieure de la fenetre est re-initialisee à aCWmin sitot quun
paquet a ete transmis correctement (ou lorsque les timers de re-emission expirent). Un exemple
devolution de la fenetre de contention est donne sur la figure 2.16.
Le m
ecanisme RTS/CTS
Nous avons vu que le mecanisme CSMA/CA cherche à eviter les collision en ecoutant lactivite
sur le canal et en choisissant un delai aleatoire supplementaire avant lemission. Mais il existe une
famille de configuration o`
u ce mecanisme est insuffisant. Il sagit du problème des nuds caches
(figure 2.17) o`
u deux emetteurs qui ne peuvent pas du tout sentendre (en general à cause dun
obstacle) veulent atteindre un meme recepteur. Comme dans cette configuration un emetteur ne
detecte jamais lactivite de lautre, il croit que le canal est toujours libre et emet dès quil a des
donnees disponibles. Les chances de collisions à repetition au niveau du recepteur sont très elevees.
802.11 propose un mecanisme utilisant des paquets de controle appeles Request To Send (RTS)
et Clear To Send (CTS) introduit par [33]. Un mobile qui veut emettre ne va plus directement
envoyer son gros paquet de donnees, mais plutot un petit paquet RTS pour lequel les chances
de collision sont plus faibles. A ce paquet RTS, le destinataire va repondre par un petit paquet
31

DE 802.11
255 255
aCWmax
127
63
31
aCWmin
15
Troisime retransmission
Deuxime retransmission
Premire retransmission
Tentative initiale
Fig. 2.16 Un exemple de backoff exponentiel
CTS quil diffuse à tout son voisinage. Les paquets RTS et CTS contiennent des informations qui
permettent de reserver le canal pour la duree de transmission des donnees qui vont suivre. Un
mobile qui recoit un CTS alors quil na pas envoye (ni meme detecte de RTS) sait que quelquun
dautre va emettre et doit donc attendre. Le mobile qui a envoye le RTS sait, quand il recoit le
CTS correspondant, que le canal a ete reserve pour lui et quil peut emettre.
Au niveau des mobiles, la reservation du canal est implementee grace au Network Allocation
Vector (NAV). Dans chaque nud, le NAV indique pour combien de temps le canal est utilise par
quelquun dautre, independamment de ce qui est physiquement percu sur le canal (on parle aussi
de detection de porteuse logique). Sur la figure 2.19 sont presentees les mises à jour du NAV au
niveau dun mobile alors quune trame est echangee entre deux autres mobiles. Lorsque le nud non
concerne par lechange recoit le RTS, il sait grace aux informations contenues dans ce dernier pour
combien de temps il ne devra pas acceder lui-meme au canal. Nous avons vu que dans certaines
configurations (par exemple celle de la figure 2.17), certains paquets ne sont pas recus par tous
les mobiles potentiellement concernes. Les CTS et les paquets de donnees vont donc aussi devoir
porter les informations de duree, afin que leur reception puisse mettre le NAV à jour (un exemple
est donne dans la figure 2.18 o`
u seul le CTS est recu par le mobile de droite).
RTS (1)
CTS (2)
CTS (2)
DATA (3)
ACK (4)
Fig. 2.18 Lechange RTS/CTS
Fig. 2.17 Le problème des nuds caches
32

DE 802.11
SIFS
source
destination
SIFS
RTS
SIFS
DIFS
DATA
CTS
autre
ACK
NAV (RTS)
NAV (CTS)
Temps
NAV (DATA)
Fig. 2.19 Le Network Allocation Vector (NAV)
Le m
ecanisme EIFS
Dans la configuration presentee sur la figure 6.13, le nud de gauche (autre) detecte la
porteuse de lemetteur sans pour autant comprendre ses messages (le signal est trop faible pour
etre decode, mais suffisamment fort pour etre reconnu comme tel). Les paquets envoyes par le
recepteur ne sont quant à eux pas detectes du tout par le mobile de gauche. Dans cette situation,
802.11 impose lutilisation dun Extended Inter Frame Spacing(EIFS), afin deviter une collision
au niveau de lemetteur au moment du CTS et de lacquittement par le recepteur. La figure 2.21
detaille ce qui se passe : Lemetteur envoie tout dabord un paquet de controle RTS. Ce paquet
est recu par le recepteur, qui va y repondre par un CTS. Le mobile de gauche, lui, a detecte de
lactivite au moment du RTS mais sans comprendre le paquet. Le mecanisme de defering presente
precedemment lempeche demettre pendant lenvoi du RTS (canal occupe) et pendant une periode
DIFS consecutive (on est toujours oblige dattendre que la canal ait ete libre pendant DIFS pour
emettre). Mais DIFS est plus court que SIFS+CTS. Si jamais le mobile de gauche avait termine
de decrementer son backoff trop vite, il aurait pu emettre pendant le CTS, causant une collision au
niveau de lemetteur. Pour proteger le CTS (et de manière similaire lacquittement), 802.11 impose
quun nud doive attendre pendant un temps EIFS lorsque le canal redevient libre mais que le
paquet na pas ete compris ; la longueur de EIFS etant suffisante pour que lenvoi du CTS ou de
lACK se deroule dans de bonnes conditions.
2.4.2
Description du mode PCF
Nous avons vu que le mode DCF permettait un fonctionnement totalement distribue de laccès
au medium, mais que, afin de limiter le nombre des collisions, CSMA/CA avait recours à une duree
aleatoire avant lemission de chaque paquet. Le temps passe à attendre represente autant de debit
effectif perdu. Aussi 802.11 propose en option un mecanisme centralise qui permet dobtenir un
meilleur taux dutilisation du canal. Cest le mode base sur la Point Coordination Fonction(PCF),
qui requiert lutilisation de stations de base et de mobiles limplementant.
Le principe de base de la PCF est de centraliser la gestion de laccès au medium dune cellule.
Cest le point daccès qui indiquera à chacun des mobiles qui lui sont rattaches quand ils doivent
emettre leurs paquets. Le backoff aleatoire devient ainsi en partie inutile. Durant toute la phase o`
u
33

DE 802.11
SIFS
SIFS
CTS
destination
Emetteur
SIFS
DIFS
ACK
Rcepteur
Autre
source
autre
RTS
defer
DATA
EIFS
DIFS
Balise
PCF
CP
DCF
EIFS
Temps
Fig. 2.21 LExtended Inter Frame Spacing

(EIFS)
Fig. 2.20 Une configuration o`

u lEIFS est
necessaire
CFP
defer
CFP
Balise
PCF
CP
DCF
Fig. 2.22 Lalternance des modes PCF et DCF
la station de base impose lordre des transmissions, il ny a pas de contention pour laccès au canal ;
on parle de Contention Free Period.
De plus, afin de preserver la compatibilite, dans chaque cycle de la PCF, une periode de DCF
est conservee et permet aux mobiles nimplementant pas la PCF de continuer à acceder au canal.
Cest la Contention Period (figure 2.22). La cohabitation entre les mobiles implementant la PCF et
ceux ne limplementant pas est assuree grace au temporisateur PIFS (PCF Inter Frame Spacing).
Durant la periode sans contention, les trames ne sont en effet separees que de periodes PIFS (ou
SIFS suivant les cas) qui sont toutes les deux plus courtes que DIFS. Grace à ces temporisateurs,
un mobile nimplementant pas la PCF ne risque donc pas de prendre la main durant la periode
geree par la station de base en mode PCF.
Il faut noter que pour linstant, très peu de cartes implementent la PCF (mais en general une
mise à jour du firmware embarque dans les cartes et les stations de base sera possible).
2.5
La s
ecurit
e des informations : la Wired Equivalent Privacy (WEP)
Dans la section consacree aux problèmes specifiques des reseaux radio, nous avons signale la
facilite avec laquelle il est possible pour un tiers decouter passivement les communications radio.
Afin de se premunir contre ces ecoutes passives, peu de moyens physiques existent (on peut essentiellement chercher à faire en sorte que les signaux de nos stations de base ne soient recus avec une
puissance suffisante que dans les zones que lon controle, comme nos bureaux ou les hangars de
notre usine). Mais meme un placement specialement pense des stations de base est mis en defaut
si lespion utilise une antenne à fort gain.
Le chiffrement des donnees est donc necessaire si lon recherche une certaine confidentialite.
802.11 decrit de ce fait une methode de chiffrement : cest la Wired Equivalent Provacy ou WEP,
qui peut etre utilisee de manière optionnelle. Le système repose sur une clef secrète qui doit
etre partagee par lemetteur et le recepteur. La distribution de cette clef est en dehors du cadre
34

DE 802.11
IV
Vecteur
d'Initialisation (IV)
Clef secrte
Graine
(concatnation
IV + clef)
RC4
Squence pseudoalatoire de chiffrement

Partie
chiffre
Message
en clair
Algorithme d'intgrit (CRC)
Chiffrement
(OU exclusif)
Code de vrification
d'intgrit concatn aux
donnes
Message
Fig. 2.23 Fonctionnement du chiffrement WEP
de la norme, et de nombreuses techniques existent, qui vont de la simple transmission de vive

voix à des serveurs dauthentification elabores. Nous ne detaillerons pas ces systèmes qui sortent
egalement du cadre de ce travail, mais la comprehension du mecanisme de chiffrement aura son
importance, en particulier lorsque nous presenterons plus tard des resultats de mesures de debit reel.
Le principe du WEP est de combiner une sequence pseudo-aleatoire generee à partir de la
clef avec les donnees. Seul le recepteur qui connat aussi la clef pourra generer la meme sequence
pseudo-aleatoire et decoder le message. La figure 2.23 donne les details de ce chiffrement :
Afin de renforcer la clef, on la combine avec un vecteur dinitialisation qui est change à chaque
paquet. Lidee est deviter quune meme clef soit utilisee souvent, et en particulier plusieurs
fois consecutives.
La concatenation de la clef et du vecteur dinitialisation sert de graine pour lalgorithme RC4
qui va generer la sequence pseudo-aleatoire de bits.
Dautre part, un code de redondance cyclique (CRC) est calcule sur les donnees, et y est
concatene.
Un OU exclusif est utilise pour combiner la sequence pseudo-aleatoire et les donnees à chiffrer
(cest le chiffrement proprement dit).
Le vecteur dinitialisation est concatene aux donnees chiffrees et le paquet est envoye (lIV
doit etre en clair, le recepteur na pas de moyen de prevoir quelle sera sa valeur).
A la reception, le mobile connat dejà la clef secrète. Il lui adjoint le vecteur dinitialisation
quil trouve au debut du paquet et genère la meme sequence pseudo-aleatoire que celle qui a servi `
a
crypter. Avec un OU exclusif entre les donnees chiffrees et la sequence pseudo-aleatoire, il obtient
directement les donnees en clair. La verification du CRC lui permet detre s
ur quaucune erreur ne
sest produite et que sa clef etait la bonne.
Au sujet de RC4, [34] nous apprend que cest un algorithme base sur des permutations. Une table
de 256 octets est initialisee avec la clef qui lui est fournie, et les elements de la table vont ensuite
etre permutes les uns les autres en fonction de leur valeur. Cet algorithme est repute s
ur et a en
outre lavantage detre très rapide (suivant le micro-processeur, entre 8 et 16 operations simples sont
necessaires pour produire un octet pseudo-aleatoire). Ceci est dailleurs particulièrement important
car les cartes reseau 802.11 nembarquent pas en general des processeurs très puissants.
35
s)
7 s
1 MBits/s
(771
data
s)
(56
192
s)
ACK
data
ead
(10
Phy
h
Trame de donnes
SIF
S
Emetteur
11 MBits/s
s)
Mac
2 MBits/s
er (
s)
192
er (
ead
hea
Mac
Phy
h
der
620
(0
koff
Bac
)
0 s
S (5
DIF
(24.
s)
DE 802.11
987.7 s
Rcepteur
Acquittement
248 s
1295.7 1915.7 s
Temps
Fig. 2.24 Une trame de donnees 802.11 à 11Mbits/s et son acquittement
2.6
Les trames 802.11b et le d

ebit utile 802.11b
Dans la suite de nos travaux, lorsquil sest agit deffectuer des mesures avec des veritables
cartes, nous avons utilise 802.11b. Nous detaillons donc ici plus en detail le fonctionnement et la
construction des trames, de manière à pouvoir comparer plus tard les debits pratiques aux debits
theoriques.
Sans detailler le contenu de chaque champ, il est tout de meme important de savoir que les
paquets envoyes par 802.11 sur le medium radio comprennent plusieurs niveaux dencapsulation.
Aux donnees venant des couches superieurs, au moment de lenvoi, est ajoutee une en-tete MAC
ainsi quune en-tete physique. Les vitesses de transmission pour certaines de ces parties peuvent
varier. Len-tete physique est envoyee à la vitesse constante de 1 Mbit/s. Lobjectif est de permettre
sa reception par toute station utilisant une carte 802.11b (et ainsi permettre la cohabitation entre
la version dorigine et les versions plus rapides, 802.11g comprise).
Len-tete MAC et les donnees sont envoyes à une vitesse negociee qui peut aller jusqu`
a 54
Mbit/s avec 802.11g.
Les paquets de controle (RTS/CTS/ACK) sont envoyes quand à eux à des vitesses qui peuvent
encore etre differentes. La norme indique que ces paquets doivent etre envoyes à une vitesse choisie
dans la liste de celles qui vont permettre leur reception par tout autre mobile compatible. Mais
ces vitesses ne sont pas donnees explicitement. Dans la pratique, la plupart des constructeurs
permettent à leurs paquets de controle detre envoyes à 2 Mbit/s et se replient sur 1 Mbit/s si les
taux dechec sont trop importants. Dautres cependant proposent de les envoyer jusquà 11 Mbit/s,
proposant ainsi des performances superieures à leurs concurrents lorsque les conditions sont ideales.
Comme les paquets de controle, les paquets envoyes en mode diffusion le sont à des vitesses choisies
dans la liste des vitesses compatibles. Par defaut, la diffusion se fera donc à 2 Mbit/s. Il faut
noter enfin que cest bien lensemble des paquets qui sont sujets à cette encapsulation et que meme
les paquets de controle possèdent une en-tete physique qui est envoyee à 1 Mbit/s.
36

DE 802.11
Si lon decompose complètement lenvoi dun paquet UDP de 1032 octets de donnees `
a 11
Mbits/s (figure 2.24), on observe (en considerant quil ny a pas eu de collision ou de perte de
paquet avant et que le canal vient juste de se liberer) :
- Un temps dattente fixe DIFS de 50 s (compte à partir du moment o`
u le canal devient libre)
- Un temps dattente aleatoire (backoff) dune duree comprise entre 0 et 31 time-slots de 20 s
chacun (0 à 620 s au total donc).
- Lenvoi de la trame de donnees (qui dure ici 987.7 s) decomposee en :
- Len-tete physique de la trame, à 1 Mbit/s, qui dure 192 s.
- Len-tete MAC de la trame, à 11 Mbit/s, qui dure 24.7 s.
- Les donnees proprement dites (ici 1032 octets de donnees application plus 28 octets
den-tete IP) envoyees à 11 Mbits/s, et qui durent 771 s.
- Un temp dattente fixe SIFS de 10 s.
- Lacquittement, decompose en :
- Len-tete physique de la trame, à 1 Mbit/s, qui dure 192 s.
- Lacquittement MAC, à 2 Mbits/s, qui dure 56 s.
En utilisant ces paramètres, nous avons calcule les debits maximums possibles en fonction de
la taille des paquets. Il faut noter que dans la realite, les paquets de grande taille peuvent etre
fragmentes par les couches superieures si elle croient avoir affaire à 802.3 (Ethernet, dont la taille
des trames ne depasse pas 1500 octets environ). Dans nos calculs, nous avons donc tenu compte de
cette fragmentation. Les figures 2.25, 2.26 et 2.27 presentent les debits theoriques pour des vitesses
respectives demission physique des donnees de 11, 5.5 et 2 Mbit/s. Il faut noter que les courbes
presentees ont pour but detre comparees dans la suite du document à des mesures reelles. Le lecteur
interesse par les debits theoriques de 802.11 les trouvera dans [35] pour ses diverses extensions, mais
sans la prise en compte de la fragmentation cependant.
37

DE 802.11
8e+06
11 Mbit/s
11 Mbit/s, fragmentation
11 Mbit/s, RTS
11 Mbit/s, RTS, fragmentation
7e+06
debit en bits par secondes
6e+06
5e+06
4e+06
3e+06
2e+06
1e+06
0
0
500
1000
1500
2000
2500
3000
taille des paquets (donnees UDP)
Fig. 2.25 Debits maximums theoriques en fonction de la taille des paquets (à 11 Mbit/s)
8e+06
5.5 Mbit/s
5.5 Mbit/s, fragmentation
5.5 Mbit/s, RTS
5.5 Mbit/s, RTS, fragmentation
7e+06
6e+06
5e+06
4e+06
3e+06
2e+06
1e+06
0
0
500
1000
1500
2000
2500
3000
Fig. 2.26 Debits maximums theoriques en fonction de la taille des paquets (à 5.5 Mbit/s)
38

DE 802.11
8e+06
2 Mbit/s
2 Mbit/s, fragmentation
2 Mbit/s, RTS
2 Mbit/s, RTS, fragmentation
7e+06
6e+06
5e+06
4e+06
3e+06
2e+06
1e+06
0
0
500
1000
1500
2000
2500
3000
Fig. 2.27 Debits maximums theoriques en fonction de la taille des paquets (à 2 Mbit/s)
39
CHAPITRE
3
3.1
Particularit
es de 802.11 dans
un contexte ad hoc
Introduction
802.11 a ete concu dans loptique de reseaux dentreprises ou de hot spots organises autour de
stations de base. Nous avons vu que de part son faible co
ut, sa disponibilite (aussi bien commerciale
que dans les simulateurs) et par sa possibilite à etre utilise pour des reseaux multi-sauts par la simple
adjonction de protocoles de routage de niveau superieur, 802.11 est devenu le support privilegie
pour letude des reseaux ad hoc. Mais un certain nombre de problèmes apparaissent, qui peuvent
etre regroupes en plusieurs categories :
Des probl`
emes de topologie radio. Ils apparaissent lorsque les mobiles sont places dans
des configurations bien specifiques (des mobiles ne pouvant communiquer quavec certains de
leurs voisins, ou encore ne detectant les porteuses que de certains autres). Ces problèmes sont
connus depuis longtemps dans le contexte des reseaux à stations de base. 802.11 intègre des
solutions pour certains (les nuds caches) et en laisse dautres de cote (les nuds exposes
par exemple). Mais lors du passage à des reseaux multi-sauts, ces problèmes devoilent de
nouvelles facettes quil est necessaire de prendre en consideration.
Des probl`
emes li
es aux d
ebits multiples. 802.11 propose plusieurs vitesses de transmission parmi lesquelles les mobiles choisissent en fonction des conditions du canal (les vitesses les
plus basses sont plus tolerantes aux perturbations radio et permettent une meilleure portee).
Le fait de pouvoir utiliser plusieurs vitesses differentes va avoir des repercussions dans un
reseau ad hoc. Dune part en terme de debit, puisque des problèmes dejà connus dans les
reseaux à stations de base risquent dy etre magnifies. Et dautre part en terme de connectivite, en particulier lorsque les protocoles de routage utilisent des paquets ayant une plus
grande portee que les donnees qui doivent etre envoyees ensuite.
Des probl`
emes d
equit
e entre des flux multiples et de d
ebit total dans le r
eseau.
802.11 etant prevu pour fonctionner dans des configurations o`
u la plupart des mobiles sont `
a
portee les uns des autres (ou dans le pire des cas voisins à deux sauts), ses performances dans
des configurations multi-sauts sont nettement en decà des optimums theoriques, en terme de
debit et dequite daccès au canal.
3.2
Le probl`
eme des nuds cach
es
Le problème des nuds caches a ete introduit dans le chapitre 2 en meme temps que le
mecanisme RTS/CTS utilise pour le corriger. Il faut cependant bien noter que dans le cadre prevu
par 802.11, ce problème napparat que dans une configuration comme celle de la figure 3.1, o`
u deux
mobiles isoles lun de lautre, utilisant une meme frequence et attaches à une meme station de base
40
DE 802.11 DANS UN CONTEXTE AD HOC

CHAPITRE 3. PARTICULARITES
A
A
Fig. 3.1 Noeuds caches simples
G
ACK
Fig. 3.3 Multiples nuds caches
Fig. 3.2 Noeuds caches dans une chane
veulent emettre vers cette dernière en meme temps. Dans ce contexte, le mecanisme de RTS/CTS
est effectivement efficace. Pour peu que la charge du reseau soit importante, [36, 37] ont montre par
le calcul et des simulations que le surco
ut en terme de debit des RTS/CTS est plus que compense
par le gain quil procure en evitant des collisions à repetition.
Dans un reseau ad hoc base sur 802.11, nous avons vu que tous les mobiles devront travailler
sur la meme frequence sils veulent permettre une connectivite complète du reseau. De ce fait, les
situations de nuds caches vont etre beaucoup plus nombreuses et plus frequentes. La figure 3.2
donne un exemple de chane à quatre sauts. A linstant considere, les mobiles B et D, qui ne sentendent pas du tout, veulent emettre. Il va donc y avoir collision au niveau du nud C. Attention,
il faut bien noter que sous la plupart des simulateurs cette configuration ne se produira jamais car
les zones de detection de porteuse etant parfaitement circulaires et dun rayon double de la zone
de communication, B se trouverait dans la zone de detection de porteuse de D et reciproquement.
Mais dans la realite, lexperience a montre que ce type de collision etait tout à fait possible, nous
le verrons dailleurs par la suite. La figure 3.3 quant à elle, presente une configuration encore plus
complexe. Là encore, de nombreuses situations de collisions se presentent, du fait de lutilisation par
tous les nuds dune seule et meme frequence. Le communications desirees sont (AB), (DE),
(CF) et (HG). Si ces transmissions avaient lieu en meme temps, des collisions entre les donnees
pourraient se produire en B et en E, et, suivant la longueur des paquets, lacquittement renvoye par
F pourrait provoquer une collision en G avec les donnees venant de H. Ces constatations tendraient
à nous faire penser que lutilisation des RTS/CTS serait la solution à ces problèmes. Malheureusement les RTS/CTS sont aussi sujets à problèmes dans les reseau ad hoc. Dune part eux aussi
peuvent entrer en collision (par exemple, sur la figure 3.3, si les CTS de B et E ne sont pas recus avec
une puissance suffisante en C pour etre compris, alors C pourra emettre et eventuellement causer
des collisions en B et en E). Dautres configurations specifiques posant problème sont egalement
decrites et analysees plus en detail dans [38] ou encore dans [39]. Nous verrons par ailleurs dans
nos propres simulations et experiences des situations o`
u les RTS/CTS sont mis en defaut, lorsquils
ne peuvent etre compris correctement.
41

A
Fig. 3.4 Le phenomène des nuds exposes
Zone de communication 11 Mbit/s
Zone de communication 2 Mbit/s
Fig. 3.5 Le phenomène de la zone grise
3.3
Le probl`
eme des nuds expos
es
Le problème des nuds exposes apparat dans des configurations comme celle presentee sur
la figure 3.4. Ici, les nuds B et C voudraient emettre respectivement vers A et D. En suivant le
mecanisme de la DCF, celui qui a tire le plus petit backoff va acceder au canal et envoyer son paquet,
alors que lautre detectera la porteuse du premier, et entrera en periode de defering. Pourtant, si
B et C emettaient en meme temps, le signal de B au niveau de A serait largement superieur à celui
de C et suffisant pour une reception correcte. La situation serait linverse au niveau du nud D,
qui recevrait correctement le paquet de C, malgre le leger bruit venant de B. Dans cette situation,
la DCF limite donc inutilement la bande passante totale du reseau. On peut noter que certains
travaux sinteressent au problème, notamment [40] qui propose lutilisation dun mecanisme de
parallel RTS pour le resoudre en partie.
3.4
Le probl`
eme de la zone grise
Nous avons vu que 802.11b utilise des vitesses de transmissions de 1 ou 2 Mbit/s pour les
paquets quil diffuse, mais que les paquets envoyes en unicast peuvent letre jusquà 11 Mbit/s. La
plupart des protocoles de routage utilisent la diffusion pour construire ou maintenir les routes (les
paquets Hello ou RouteRequest sont typiquement diffuses par exemple). Ces paquets sont donc emis
à 2 Mbit/s et permettent de construire un certain nombre de routes dans le reseau. Mais lorsque
les donnees sont ensuite envoyees à 11 Mbit/s sur ces routes, comme la portee de communication
decrot avec laugmentation de la vitesse, il est possible que des mobiles pourtant à portee des
paquets de routage lents soient trop loin pour les paquets de donnees rapides. Il en decoule que
les routes construites avec les paquets diffuses ne sont pas forcement exploitables à des debits plus
42

eleves. La zone concernee (la soustraction de la zone rapide à la zone lente plus large) est
appelee zone grise et ce problème avait ete releve theoriquement et experimentalement dans [41].
3.5
Partage du canal entre des flux `

a vitesses diff
erentes
En sus du phenomène des zones grises, lutilisation des debits multiples que propose 802.11
conduit à dautres problèmes. Lorsque des mobiles implementant 802.11 rencontre de forts taux de
perte, la norme leur recommande de reduire leur vitesse demission (plus la vitesse est basse, plus
le signal est resistant aux interferences et est comprehensible loin de lemetteur). Mais, comme il
lest montre en detail dans [42], la methode DCF daccès au medium ne cherche pas à equilibrer les
debits de plusieurs flux en contention, mais plutot à donner à chaque paquet des chances equitables
detre envoye. Lorsque certains paquets sont envoyes à des vitesses elevees et dautres à des vitesses
lentes, cela va se traduire par une alternance plus ou moins regulière entre eux. Les mobiles emettant
leurs paquets très lentement vont donc capturer le canal pendant la majorite du temps et faire
chuter le debit des autres mobiles qui ne prennent pourtant pas beaucoup de temps pour emettre
leurs propres paquets. Ainsi, dans un environnement de competition entre plusieurs mobiles, si lun
dentre eux emet à 1 Mbit/s, meme si tous les autres travaillent à 11 Mbit/s, leurs debit utile sera
très bas. Dans un environnement ad hoc, du fait du mecanisme de routage qui utilise en general les
paquets diffuses à 2 Mbit/s (comme note au paragraphe 3.4), beaucoup de liens ainsi decouverts
ne supporteront pas des debits elevees (5.5 ou 11 Mbit/s) et sen tiendront au debit reduit de
2 Mbit/s. Les trafics sur les liens o`
u le 11 Mbit/s est possible seront donc le plus souvent affectes
considerablement par ces autres liens plus lents.
3.6
TCP et 802.11
TCP est un protocole extremement utilise dans le monde filaire. Afin de pouvoir utiliser directement dans les reseaux ad hoc les innombrables applications qui sont basees sur TCP, il faut que
les performances de ce dernier dans ce contexte soient suffisantes. Un certain nombres detudes ont
ete conduites sur le comportement de TCP lorsquil est utilise au-dessus de 802.11 [43, 10, 44] et
des problèmes consequents sont apparus. Les auteurs de ces articles se sont interesses à des configurations ad hoc diverses, parmi lesquelles la chane se trouvaient à chaque fois. Ils ont utilise des
simulateurs (Network Simulator 2 et Glomosim) et ont constate les problèmes suivants :
Linstabilite des connexions. Les flux TCP sont très souvent stoppes, et doivent reprendre
à chaque fois en passant par la phase de demarrage lent. Ces interruptions sont dues `
a la
detection de cassure de liens au niveaux MAC. Il a ete montre que la taille de la fenetre TCP
avait un impact très important sur ce problème, mais quil prend veritablement racine dans
la couche daccès au medium.
Linegalite entre certains flux. Dans certaines configuration multi-sauts, alors que lon voudrait
que plusieurs flux TCP se partagele canal, il arrive que certains dentre eux capturent le
canal et que dautres soient complètement stoppes ou presque.
Malheureusement, bien quelles aient souleve certains problèmes, ces etudes sont basees sur certaines
configurations o`
u lanalyse des phenomènes et de leurs origines est rendu complexe par lempilement des protocoles et leurs diverses interactions. De plus, comme nous le verrons, ces problèmes
peuvent encore etre classes en plusieurs categories, la couche physique elle-meme joue un role dans
43

certains dentre eux et en environnement reel, certains autres vont encore apparatre qui avaient
ete totalement omis dans ces etudes.
3.7
Capacit
e th
eorique en fonction la topologie (grille, chane)
Certains travaux se sont attaches à evaluer la capacite theorique (en terme de bande passante)
des reseaux ad hoc bases sur 802.11. [45] sinteresse au trafic dans des topologies regulières (chane
et grille de nuds). Au travers de simulations, les auteurs montrent que 802.11 peine à offrir une
bande passante optimale dans ce type de configuration. Le premier nud de la chane cherche `
a
envoyer autant de paquets que possible (sa file dattente est pleine en permanence). Les nuds
situes plus loin sur la chane ne peuvent envoyer des paquets que sils en ont prealablement recu.
De plus, les premier nuds (et en particulier le tout premier) ont moins de voisins avec qui entrer en
contention que ceux situes plus loin. Il en resulte que les premiers nuds utilisent une grande part
de la bande passante pour envoyer des paquets que leurs successeurs ne pourront de toute facon pas
tous retransmettre du fait de la haute contention quils recontrent. Dans ces conditions dinegalite
de contention et de trafics offerts, la couche MAC de 802.11 ne peut pas produire lordonnancement
qui aurait donne le meilleur debit total.
Dans letude de la grille, le problème et confirme. Il y apparat dautre part que les schemas des
trafics vont avoir eux aussi un grand impact sur les performances globales (si les flux sont eloignes
les uns des autres, sils se croisent, etc.). A ce niveau, le type dapplication va etre très important,
tout comme les protocoles de routage utilises.
Si les auteurs de [45] apportent une explication interessante sur les faibles debits obtenus dans
des configurations regulières comme la chane ou la grille, nous proposons neanmoins dans le chapitre 4 notre propre evaluation et analyse de 802.11 dans une chane de mobiles. Ce travail qui
aurait pu paratre redondant nous a en fait semble necessaire pour plusieurs raisons :
Les mesures de base de 802.11 proposees dans [45] netaient pas coherentes avec celles que
vous avions obtenues, et certains arguments avances nous semblaient en contradiction avec
nos propres connaissances de NS2.
Les outils avances danalyse que nous avions mis en place permettaient une evaluation plus
poussee que celle proposee dans [45].
3.8
Equit
e
Plusieurs travaux ont mis en lumière certains problèmes dequite dans laccès au medium radio
qui pouvaient survenir avec lutilisation de 802.11. Le protocole MACAW [46], un des ancetres
de 802.11 publie en 1994 (et qui avait dailleurs introduit lutilisation des acquittements), avait
dejà remarque le problème. Il proposait en particulier un mecanisme pour resoudre linegalite entre
mobiles qui provenait de lutilisation du principe de Binary exponential Backoff dans lajustement
de la fenetre de contention.
Dans [47], les auteurs presentent trois scenarios qui montrent une inegalite dans laccès au
medium radio avec 802.11. Ils sinteressent à linegalite par nud ainsi quà linegalite par flux.
Ils expliquent que cette inegalite provient dune asymetrie des zones de contention de mobiles. Si
intuitivement on sent bien que cette asymetrie va gener fortement les mobiles connaissant le plus de
contention, les auteurs ne donnent pas dexplications detaillees du dysfonctionnement de 802.11 face
à cette asymetrie. En plus des problèmes dasymetrie mentionnes par [47], les travaux de Bensaou
44

et al. [38, 48] soulèvent un problème dinegalite provenant de collisions repetees dans le cadre de
reseaux ad hoc particuliers.
3.9
Conclusion et positionnement
Cet etat de lart montre quun certain nombre de problèmes ont ete mis en evidence avec
lutilisation de 802.11 dans les reseaux ad hoc. Certains travaux ont ete realises avant ma thèse (les
plus anciens vraiment specifiques à ce contexte datant de 1999, les autres ayant ete publies au cours
de ma thèse, celle-ci ayant commence en 2000). Chacun de ces travaux soulève une problematique
bien particulière mais aucun ne propose une analyse complète de 802.11 dans un cadre ad hoc.
Enfin, la majorite de ces travaux se basent sur des resultats de simulation (hormis [41, 42] qui
realisent quelques experimentations).
Dans cette thèse, nous avons essaye de mener un travail complet sur les performances de 802.11
dans les reseaux ad hoc. Nous avons tente de degager les scenarios de base qui permettent de
lister les differents problèmes souleves et dy apporter des explications ciblees. Grace à ces simulations, certains des phenomènes observes dans la litterature ont ete retrouves, tandis que dautres
caracteristiques ont ete degagees.
Enfin, contrairement aux travaux existants, un long travail dexperimentations de 802.11 dans un
contexte ad hoc a ete realise au cours de cette thèse. Ce travail a permis dune part de connatre les
performances reelles de 802.11, et dautre part declairer les problematiques sous un angle nouveau.
45
Premi`
ere partie
Simulations logicielles de r
eseaux
ad-hoc
46
CHAPITRE
4
4.1
Simulations : introduction et
sc
enarios de prise en main
Introduction
La communaute ad-hoc concentre une grande part de son attention sur les protocoles de routage.
Cela etait dautant plus vrai au moment du debut de ma thèse, alors que le groupe MANET de
lIETF voyaient de nombreux nouveaux protocoles presentes, et quaucun dentre eux netait assez
stabilise pour envisager une normalisation. Pour developper, tester et valider ces algorithmes, les
chercheurs se sont très rapidement tournes vers les simulateurs. Ceci est en premier lieu du `
a des
raisons pratiques. Il est peu commode de deployer un protocole sur un reseau reel compose dun
certain nombre de machines (en particulier dans une configuration multi-sauts), de faire quelques
essais, puis de recommencer en changeant quelques paramètres ou quelques morceaux de code. De
plus, peu de laboratoires disposaient du materiel necessaire (problème de co
ut et de logistique ...
et si lon veut tester des scenarios presentant de la mobilite, de la main duvre est necessaire).
Lorsque nous avons commence ces travaux, notre laboratoire ne disposait daucun equipement
radio. Cest donc très logiquement que nous nous sommes nous aussi tournes vers la simulation.
4.2
Objectifs initiaux des simulations
Dans la seconde moitie des annees 90, avec lelaboration de plusieurs normes pour les reseaux
sans fils à portee limitee (visant des usages à lechelle du bureau ou du batiment), un certain
nombre de simulateurs ont ete developpes conjointement. Nous pouvons par exemple citer Network
Simulator 2 [49] et son extension sans fil, OPNET [50] ou encore GloMoSim [51] / Qualnet [52].
NS2 est certainement le simulateur de reseaux le plus utilise par la communaute ad-hoc. Il est
gratuit et son code source est disponible ; autant davantages qui font quil est largement mis `
a
contribution par les chercheurs desireux devaluer les performances des protocoles de routage quils
developpent. Lorsque nous avons commence à vouloir tester des heuristiques et divers algorithmes
se rapportant aux reseaux ad-hoc, cest donc logiquement vers NS2 que nous nous sommes tournes.
Linstallation ainsi que la prise en main du logiciel et des outils laccompagnant a ete relativement
aisee ; une fois la decision prise deffectuer des simulations, nous avons donc pu rapidement nous
lancer dans nos premières simulations.
Dans un premier temps, et puisque que nous netions pas du tout familiers des reseaux sans
fils, ces simulations ont consiste en des scenarios simples, permettant de se faire une idee des
comportements de base des mobiles utilisant 802.11. Nous nous sommes par exemple interesses
aux differents modèles de propagation disponibles ou aux debits et distances de communication
maximum.
47

CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCENARIOS
DE PRISE EN MAIN
Après cette etape de prise en main, nous nous sommes interesses plus specifiquement `
a des
scenarios typiques des reseaux ad-hoc (communication necessitants plusieurs sauts et problèmes
dinterferences).
Dans de nombreux articles ([53, 54, 55]) dont lobjectif est de verifier que les protocoles de
routage arrivent bien à construire et maintenir les routes, les flux de donnees sont très faibles (en
general moins de 8 ou 10 paquets par seconde et par source, envoyes à une vitesse constante).
Dans ces articles, les modèles de mobilite jouent egalement un role très importants. Le Random
Waypoint, utilise pour la première fois dans [56] puis plus tard raffine dans [54] est certainement le
plus utilise. Il consiste en :
Le placement dun certain nombre de mobiles (typiquement 50 à 100) dans une zone carree
de laquelle ils ne peuvent sortir.
Laffectation dune position, dune vitesse et dune destination initiale à chaque mobile.
La selection aleatoire des emetteurs et de la destination de leurs paquets.
Le deroulement proprement dit de la simulation, o`
u à chaque fois que les mobiles atteignent
leur destination dans le carre, ils repartent vers une autre destination choisie aleatoirement
après un eventuel temps de pause.
Il faut noter que ce modèle assez simple a ete sujet à critiques, notamment dans [57] o`
u linstabilite
et la diminution progressive de la vitesse moyenne des mobiles en fonction du temps de simulation
est mise en lumière. Comme la destination et la vitesse sont choisis aleatoirement, des mobiles vont
parfois choisir des destination lointaines et des vitesses très lentes, et il leur faudra enormement
de temps pour y arriver. Plus la simulation sera longue, plus le nombre de mobiles coinces dans
cette situation va augmenter, et la proportion de mobiles lents va crotre de facon genante.
Quoiquil en soit, il est clair que les performances de chaque protocole de routage dependent
beaucoup des conditions dutilisation (certains sont concus pour fonctionner dans des petits reseaux
à forte mobilite, dautres dans de grands reseaux, etc.). Pour pouvoir construire des modèles de
mobilite vraiment pertinents, il faudrait idealement pouvoir disposer dinformations sur le contexte
dans lequel le reseau ad hoc sera reellement deploye , et ceci est generalement impossible.
Mais contrairement à ce que lon rencontre en general dans la litterature, nous avons cherche
à voir ce qui se produisait quand le reseau arrivait à saturation. Nous ne cherchions pas à tester
les algorithmes de tel ou tel protocole de routage, nous voulions plutot savoir ce qui se passerait
(en terme de debit, de connectivite et de delais) quand des flux très importants sont presents
entres certains mobiles dans un reseau ad-hoc. Ceci etait motive par lidee que dans de nombreuses
circonstances, le trafic seffectue plutot par rafale (comme par exemple la navigation web, le transfert
de fichiers ou meme la consultation de-mails). Dans nos scenarios, nous avons donc en general utilise
des flux cherchant à occuper complètement la bande passante. Ces conditions de saturation sont
un element important de nos travaux et les differencie dune grande majorite de ceux effectues
precedemment et qui nutilisaient que des flux très peu gourmands.
4.3
Pr
esentation de Network Simulator 2
NS2 est un simulateur à evenements discrets developpe dans un but de recherche [58]. Il fournit
un environnement assez detaille permettant entre autre de realiser des simulations dIP, TCP, du
routage et des protocoles multicast aussi bien sur des liens filaires que sans fil.
Network simulator 2 a ete originellement developpe en tant que variante du REAL network
simulator en 1989, et a considerablement evolue au cours des annees. En 1995, NS2 etait developpe
48

DE PRISE EN MAIN
par le projet VINT. Actuellement, son developpement est supporte par le DARPA à travers SAMAN
et par la NSF à travers CONSER, tout en incluant de nombreuses contributions exterieures, comme
en particulier les codes pour les reseaux sans fils des projets Daedalus de lUCB et Monarch de la
CMU et de Sun Microsystems.
NS2 est ecrit en C++ et en oTCL, et il est fourni avec divers outils danalyse complementaires
eux-memes ecrits en C/C++ ou TCL/Tk.
NS2 implemente la version de 1997 de la norme 802.11. A ce titre, le debit maximum possible
est de 2 Mbit/s. Il faut noter egalement que ce logiciel est developpe, corrige et etendu au fur et
à mesure de lapparition de nouveaux besoins (ou de la decouverte derreurs). Ainsi, au cours du
deroulement de cette thèse, plusieurs versions se sont succedees, apportant leurs lots de corrections
et ameliorations diverses.
Compte tenu de nos objectifs, nous avons bien s
ur essentiellement mis à contribution la partie
IP/UDP/TCP en environnement sans fil. NS permet de positionner sur un plan virtuel des mobiles
equipes demetteurs radio, et il gère la mobilite de ces nuds dans le temps. Pour quun paquet
emis sur une interface sans fil sous NS2 soit recu, il faut quil arrive au destinataire avec un niveau
de signal superieur à un certain seuil. Ce seuil est par defaut de 3.652 1010 W, et nous lavons
laisse à cette valeur pour toutes les simulations qui seront presentees par la suite.
4.3.1
Les diff
erents mod`
eles de propagation radio sous NS2
NS2 permet egalement de choisir parmi les modèles de propagation suivants, qui influeront en
particulier sur la manière dont seront attenues les signaux en fonction de la distance :
Free space model : Ce modèle considère le cas ideal o`
u il y a un seul chemin de propagation
entre lemetteur et le recepteur et quil est en vue directe. H.T. Friis a presente dans [59]
lequation suivante pour calculer la puissance du signal recu en environnement libre `
a une
distance d de lemetteur.
Pr (d) =
Pt Gt Gr 2
(4)2 d2 L
(4.1)
o`
u Pt est la puissance demission, Gt et Gr les gains respectifs des antennes de lemetteur
et du recepteur. L (avec L 1) est la perte du système, et est la longueur donde. Dans
nos simulations avec NS, nous prendrons toujours Gt = Gr = 1 et L = 1. Ce modèle de
propagation represente les zones de communication comme un cercle autour de lemetteur.
Si un recepteur est dans ce cercle il recoit tous les paquets, sil est en dehors il nen recoit
aucun.
Two-ray ground reflection model : En environnement reel, il est en fait peu probable
que le seul chemin de propagation soit le chemin direct. Le modèle two-ray ground considère
donc `
a la fois le chemin direct et une reflexion sur le sol. Comme il est montre dans [60], ce
modèle donne des resultats plus justes que le modèle de propagation en espace libre quand
la distance est assez grande. La puissance recue à une distance d est calculee de la manière
suivante :
Pt G t G r h t 2 h r 2
Pr (d) =
(4.2)
d4 L
o`
u ht et hr sont les hauteurs des antennes de transmission et de reception. Notez que lequation
originelle dans [60] considère que L = 1. Afin que NS soit coherent avec le modèle de propagation en espace libre, L a ete ajoute à lequation.
49

DE PRISE EN MAIN
Environnement
En exterieur Espace libre
Zone urbaine obstruee
En interieur En ligne de vue
Obstrue
2
2.7 à 5
1.6 à 1.8
4 à 6
Tab. 4.1 Quelques valeurs typiques pour lexposant dattenuation

Lequation precedente presente une decroissance de la puissance recue en fonction de la distance plus rapide que lequation (4.1). Cependant, pour des distances courtes, le modèle `
a
deux rayons ne donne pas de bons resultats (en raison doscillations causees par la combinaison constructive et destructive des deux rayons). Le modèle de propagation en espace libre
est donc utilise à la place de celui-ci quand d est suffisamment petit.
Pour ce modèle, nous avons donc besoin de calculer une distance seuil dc . Quand d < dc ,
lequation (4.1) est utilisee, et quand d > dc , on prend lequation (4.2). A la distance seuil,
les equations (4.1) et (4.2) doivent donner les memes resultats ; la distance seuil dc peut donc
etre calculee de la manière suivante :
dc =
4ht hr
(4.3)
Shadowing model : Les modèles de propagation en espace libre ou utilisant deux rayons
calculent de manière deterministe la puissance recue en fonction de la distance. Ils representent
tous deux la zone de communication comme un cercle ideal. Dans la realite, la puissance recue
à une certaine distance varie de manière aleatoire, à cause des effets de propagation par des
chemins multiples. En fait, les deux modèles precedents calculent la puissance moyenne recue
à une distance d. Le shadowing model est un modèle de propagation plus generaliste presente
dans [60] et implante dans NS2.
Le modèle shadowing est compose de deux parties. La première est le modèle dattenuation
en fonction de la distance, qui calcule la puissance moyenne recue à une distance d, notee
Pr (d). Il utilise une distance courte comme reference, notee d0 . Pr (d) est calculee relativement
à Pr (d0 ) de la manière suivante :
Pr (d0 )
=
Pr (d)
d
d0
(4.4)
est appele lexposant dattenuation en fonction de la distance, et est generalement determine

de facon empirique par des mesures en environnement reel. Daprès lequation (4.1), on sait
quen espace libre = 2. La table 4.1 donne quelques valeurs typiques de . Les grandes
valeurs correspondent à une obstruction plus forte et donc à une decroissance plus rapide de
la puissance recue en fonction de la distance. Pr (d0 ) peut etre calculee à partir de lequation
(4.1), en prenant par exemple d0 = 1 mètre.
Lattenuation en fonction de la distance est souvent mesuree en dB. A partir de lequation
(4.4) nous avons
"
Pr (d)
Pr (d0 )
= 10 log
dB
50
d
d0
(4.5)

DE PRISE EN MAIN
Environnement
En exterieur
Bureaux, separations legère
Bureaux, murs
Usine, en ligne de vue
Usine, obstruee
dB (dB)
4 à 12
7
9.6
3 à 6
6.8
Tab. 4.2 Quelques valeurs typiques pour la deviation du shadowing dB

La seconde partie du modèle shadowing reflète les variations de la puissance recue `
a une
distance donnee. Cest une variable suivant une loi log-normale, cest à dire dont la distribution
mesuree en dB est gaussienne. Lensemble du modèle shadowing est represente par
"
Pr (d)
Pr (d0 )
d
= 10 log
d0

dB
+ XdB
(4.6)
o`
u XdB est la variable aleatoire gaussienne dont la moyenne est zero et lecart type dB . dB
est appele shadowing deviation, et est egalement obtenue par des mesures en environnement
reel. La table 4.2 donne quelques valeurs typiques pour dB . Lequation (4.6) est aussi connue
sous le nom de log-normal shadowing model.
Le shadowing model etend le cercle ideal de communication à un modèle statistique plus riche ;
les nuds ne peuvent communiquer quavec une certaine probabilite lorsquils sont vers la
limite de portee.
4.3.2
La gestion des interf

erences
Le terme interferences est souvent utilise de facon generique, et recouvre en fait plusieurs
phenomènes quil est important de differencier. Avant tout, les conditions suivantes doivent etre
remplies pour quun paquet puisse etre recu :
La puissance du signal recu doit depasser un certain seuil (seuil de communication).
Le rapport signal sur bruit ambiant doit etre suffisamment grand (le signal doit etre clairement
identifie, et non noye dans le bruit).
Il existe un seuil de detection de porteuse. Si la puissance du signal est comprise entre ce seuil
et le seuil de communication, alors le message nest pas compris mais lactivite sur le canal est
neanmoins detectee. Si lon utilise le modèle two-ray ground (ou le modèle free-space), ces seuils
definissent donc deux zones autour dun nud. Si le recepteur est place au centre de la figure 4.1,
alors un emetteur place dans la zone interne (zone de communication) pourra lui envoyer des messages qui seront compris (en labsence dautres interferences). Si lemetteur est place dans la zone
externe (zone de detection de porteuse), la communication ne sera pas possible mais lautre mobile
sera informe à chaque fois que lemetteur accedera au canal. Si lon utilise le modèle shadowing,
les deux zones sont egalement definies, mais leurs frontières sont floues du fait du caractère
probabiliste du modèle. 802.11 impose quun mobile qui veut emettre doit dabord sassurer
quaucune autre communication nest en cours dans son voisinage. Si une telle communication est
en cours, et si lemetteur est suffisamment proche (cest à dire dans la zone de communication)
du mobile qui voudrait lui aussi emettre, alors ce dernier a recu len-tete du message et sait donc
(par lintermediaire de son Network Allocation Vector) pour combien de temps le canal doit encore
etre occupe. Le nud qui voulait emettre va donc attendre. Par contre, si le mobile qui veut
51

DE PRISE EN MAIN
Zone de communication
Zone de dtection de porteuse
Fig. 4.1 Portee de communication et de detection de porteuse
aussi emettre est plus loin (dans la zone de detection de porteuse de lemetteur) len-tete na pas
pu etre comprise. Il est impossible dans ce cas de prevoir à lavance quand on aura à nouveau
le droit demettre, il faut attendre que lactivite sur le canal disparaisse. Dans ces contextes,
les differents nuds se genent les uns les autres, et cela se traduit par un partage du canal entre eux.
Une fois ces precisions donnees, les differents facteurs à prendre en compte pour les interferences
sont :
Latt
enuation du signal en fonction de la distance et de lenvironnement . Cest la prise en
compte uniquement de la distance dans le calcul dattenuation qui donne sa forme circulaire
à la zone de couverture de la figure 4.1. Cest ce que fait NS2 (avec eventuellement un facteur
aleatoire supplementaire dans le modèle shadowing).
Le bruit ambiant est normalement la somme de tous les bruits percus au niveau du
recepteur. Ce bruit de fond provient de lenvironnement (passage de vehicules motorises,
appareils bruiteurs divers, ...), mais aussi des autres mobiles du reseau. Sous NS2 il ny a pas
de bruit de fond provenant de lenvironnement, le signal recu de lemetteur est simplement
compare à tour de role à chacune des autres sources du reseau actives à ce moment là. Ceci est
une limitation de NS2, car suivant les conditions, il se peut quaucune de ces sources de bruit
ne soit suffisante pour gener la communication de manière independante, mais que leur somme
le soit. Dun manière generale, NS calcule donc une approximation du bruit qui est inferieure
à ce quelle devrait etre. Il faut bien garder à lesprit que si des problèmes dinterferences apparaissent dans certains scenarios, limpact de ces interferences en environnement reel serait
encore superieur.
4.4
Traitements des r
esultats et outils danalyse
NS2 ecrit les resultats de ses simulations dans un fichier texte o`

u chaque ligne correspond `
a
un evenement qui sest produit à un niveau ou à un autre de la pile protocolaire. Il est possible
de configurer NS2 de telle sorte quil ne garde une trace que de certains types devenements (par
exemple tout ce qui concerne le routage, mais pas ce qui concerne la couche MAC). Ceci est en
particulier utilise pour accelerer la simulation et reduire la taille du fichier.
Ce fichier texte peut porter en lui-meme enormement dinformations. Mais pour extraire et
representer de manière synthetique ces informations, il faut souvent appliquer de nombreux traite52

DE PRISE EN MAIN
Fig. 4.2 Scenario dexemple pour le chronogramme
ments à ce fichier. Par exemple, si lon veut calculer un debit sur un lien, il faut compter le nombre
de paquets transmis durant une certaine periode entre certains nuds et tenir compte de leur taille.
Comme lensemble des evenements qui se sont produits se trouvent dans ce fichier et quils ne sont
classes que par ordre chronologique, ceci peut se reveler pour le moins laborieux.
Ainsi, pour calculer les debits, on prefère plutot agir au niveau du script TCL decrivant le
scenario. Certains objets utilises dans les simulations sont capables de comptabiliser les paquets ou
les octets qui les traversent (comme ceux qui servent de recepteurs pour les flux TCP par exemple).
Ces informations peuvent etre recuperees au niveau du script TCL, qui se charge alors de les ecrire
dans un fichier.
Bien que ces deux techniques permettent dejà de recuperer enormement dinformations, ceci
na pas toujours ete suffisant pour nos besoins. Comme nous cherchons à savoir ce qui se passe
aux niveaux MAC et physique, nous avions besoin en particulier de plus de details que la simple
connaissance de lechec ou de la reussite de la transmission dun paquet au niveau MAC. Nous avons
donc ajoute du code dans NS2 qui nous permet, pour chaque nud, de connaitre les moments o`
u
il est en train :
Demettre sur le canal (toutes les emissions, les RTS/CTS et les acquittements seront donc
visibles separements).
De decrementer son backoff (avec des indications lorsque cette decrementation est suspendue
puis reprise).
Dattendre car son Network Allocaton Vector lui indique que le canal est occupe.
La configuration de cette nouvelle fonctionnalite se fait depuis le script TCL, et les informations
sont stockees dans des fichiers separes du fichier de log principal de NS2. La visualisation se fait
grace à un programme externe, qui represente graphiquement les informations sous la forme dun
chronogramme.
Pour donner un exemple, nous considerons le scenario presente sur la figure 4.2. Il y a deux
couples demetteur / recepteur situes juste à cote les uns des autres. Les nuds 0 et 2 sont les
emetteurs, 1 et 3 sont les recepteurs. Les nuds 0 et 2 cherchent à envoyer autant de paquets UDP
de 1000 octets que possible.
Le chronogramme est presente sur la figure 4.3. Le temps est represente de gauche à droite, son
echelle est indiquee en bas à gauche et à droite. Sur cette capture decran, nous avons zoome de
facon à afficher uniquement ce qui se passait entre les secondes 11.023 et 11.04 de la simulation. Le
temps indique en bas au milieu correspond à la position du curseur de la souris (invisible sur cette
capture decran) ; il est souvent utile pour lire directement les temps approximatifs des evenements
53

DE PRISE EN MAIN
Fig. 4.3 Exemple de chronogramme partiel dune simulation
dessines. Les tirages dun nouveau backoff ainsi que la fin de leur decrementation sont signales sur le
graphique par des petites barres verticales au bout des rectangles. Une barre en debut dun rectangle
de backoff indique quil vient detre tire au hasard et que sa decrementation commence, une barre `
a
la fin indique quil a ete decremente jusquà zero et que lemission va pouvoir commencer. Labsence
de barre verticale indique que la decrementation a ete temporairement stoppee ou quelle reprend.
Les douze fichiers de trace sont dessines les uns en dessous des autres. Ici, on peut lire le
deroulement suivant de la simulation :
Le nud 2 est en train demettre (1). Le nud 3 est en train de recevoir (ceci napparat pas
directement sur la figure, mais la presence dun acquittement permettra ensuite de savoir si
cette communication sest deroulee correctement), et les nuds 0 et 1 savent quils ne doivent
pas emettre (leur NAV leur indique que le canal est occupe).
Le nud 3 a fini de recevoir le paquet de donnees. Il retourne un acquittement (2). Les NAV
des nuds 0 et 1 leur indiquent toujours quils ne doivent pas emettre
En (3), le canal devient libre. Les nuds 0 et 2 veulent tous les deux emettre. Cette fois-l`
a,
le nud 2 a tire un backoff très petit, dès quil a fini de le decrementer, il emet un RTS
(4). Immediatement, le nud 0 detecte lactivite sur le canal et arrete de decrementer son
backoff. Le RTS contenant la duree de la transmission de donnees quil annonce, cela permet
aux nuds 0 et 1 de positionner leur NAV sitot le RTS recu.
Le nud 3 repond au RTS par un CTS (5), puis le nud 2 y repond par lenvoi de ses
donnees, qui sont acquittees ... et ainsi de suite
Cet outil qui vient detre presente est simple dutilisation. Grace à lui nous serons par la suite
en mesure de realiser une evaluation fine des scenarios simules.
4.5
Prise en mains et premi`

eres simulations
54

DE PRISE EN MAIN
X Graph
Y x 106
1.7000
out0-sc00-1-rts.tr
1.6000
1.5000
1.4000
1.3000
1.2000
1.1000
1.0000
0.9000
0.8000
0.7000
0.6000
0.5000
0.4000
0.3000
0.2000
0.1000
0.0000
X
0.0000
20.0000
40.0000
80.0000
100.0000
Fig. 4.5 Debits dans lexperience des deux

mobiles seloignant (modèle free-space). En
abscisse : distance en dizaines de mètres, en
ordonnee : debit en bits par seconde
Fig. 4.4 Description de lexperience des

deux mobiles seloignant
1.8e+06
1.8e+06
modele two-ray ground sans RTS/CTS
modele two-ray ground avec RTS/CTS
modele shadowing sans RTS/CTS

modele shadowing avec RTS/CTS
1.6e+06
1.6e+06
1.4e+06
1.4e+06
1.2e+06
1.2e+06
debit en bits par seconde
60.0000
1e+06
800000
600000
1e+06
800000
600000
400000
400000
200000
200000
0
0
100
200
300
400
distance en metres
500
600
700
100
200
300
400
distance en metres
500
600
700
Fig. 4.6 Debits en fonction de la distance avec Fig. 4.7 Debit en fonction de la distance avec
le modèle two-ray ground.
le modèle shadowing.
55

DE PRISE EN MAIN
Fig. 4.8 Modèle shadowing, chronogramme à 100 m
Fig. 4.9 Modèle shadowing, chronogramme à 500 m (sans RTS/CTS)
4.5.1
Port
ee de communication et d
ebit
Les toutes premières simulations realisees ont pour but dobserver la portee et le debit de
limplementation de 802.11 disponible sous NS2. Les scenarios consistent à placer un emetteur et
un recepteur juste à cote lun de lautre. Lemetteur envoie un flux à debit constant de paquets UDP
de 1000 octets (il en envoie suffisamment pour saturer le canal). Progressivement, on deplace le
recepteur (figure 4.4). Nous effectuons cette simulation avec chacun des modèles de propagation proposes, en utilisant à chaque fois AODV comme protocole de routage. Ces simulations nous servent
à comparer les modèles de propagation disponibles, et nous servent detalon pour les simulations
plus complexes qui vont suivre (nous rappelons que dans toutes ces simulations, le debit physique
simule est de 2 Mbit/s, puisque cest celui supporte par defaut par NS2). A chaque fois, nous avons
egalement effectue une simulation avec les RTS/CTS et une autre sans. Le debit maximum observe
sans utiliser les RTS/CTS est de 1.6 Mbit/s, et descend à environ 1.4 Mbit/s lorsquon les utilise.
Mod`
ele free-space. Ce modèle de propagation est le plus simple propose par NS2. Le debit obtenu
en fonction de la distance entre lemetteur et le recepteur est presente sur la figure 4.5. Daprès ce
modèle, la puissance recue diminue de manière continue avec la distance. Comme la reception dun
paquet nest possible que si la puissance est superieure à un certain seuil, nous obtenons logiquement
une courbe o`
u le debit est maximum jusquà une certaine distance (600 m) puis ensuite nul. Le
seuil de communication est la valeur par defaut de NS2 (3.652.1010 W). Dans la pratique, NS2
est passablement bugge , et au delà de 600 m, dans sa version 2.26, son comportement devient
imprevisible (debit non nul à très grande distance, variation au cours du temps à une distance fixe,
crash pur et simple de NS2, ...).
Mod`
ele two-ray ground. Ce modèle de propagation est celui qui est generalement utilise par la
communaute ad-hoc lorsquil sagit de developper et tester des protocoles de routage. On observe
les resultats presentes sur la figure 4.6. On remarque que jusquà une certaine distance (250 mètres)
le debit est maximum, puis quau-delà les communications ne sont plus possibles du tout. Ceci est
tout à fait normal compte tenu du modèle de propagation utilise. On remarque aussi limpact sur le
debit de lutilisation du mecanisme RTS/CTS. Dans ce scenario o`
u lon obtient un debit maximum
56

DE PRISE EN MAIN
de 1.6 Mbit/s en leur absence, lutilisation des RTS/CTS provoque une baisse du debit utile de
12% environ à 1.4 Mbit/s.
Mod`
ele shadowing. Ce modèle est plus complexe que les precedents, il est probabiliste et utilise
aussi des informations recoltees sur le terrain. Le debit que lon obtient avec lui en fonction de
la distance est presente sur la figure 4.7. Le scenario est le meme que precedemment (figure 4.4)
et les paramètres du modèle shadowing sont ceux par defaut ( = 2.0, dB = 4.0, d0 = 1 mètre
). Ce modèle de propagation donne, `
a partir dune certaine distance, une probabilite de plus en
plus importante pour quun paquet soit perdu (signal trop attenue). Dans ce scenario, cela ce
traduit par une diminution progressive du debit, qui commence à baisser à partir de 250 mètres
environ, mais qui ne devient nul quau delà de 600 mètres. Avec le modèle shadowing, tout comme
avec le freespace, la portee de communication est très grande, nettement plus quavec le two-ray
ground. A courte distance, limpact des RTS/CTS est le meme quavec le modèle two-ray ground.
On remarque cependant que lorsque lon utilise les RTS/CTS, lorsque la distance augmente, le
debit baisse beaucoup plus vite que quand on ne les utilise pas. Ceci est assez logique, puisque quil
suffit que lun des paquets de controle soit perdu pour que la transmission echoue. Il faut egalement
noter que nous avons rencontre de nombreux plantages de NS2 en utilisant ce modèle (sur la
figure 4.7, lexperience sans RTS a en fait ete arretee par un plantage du simulateur, qui na jamais
reussi à depasser ce stade.
Sur les figures 4.8 et 4.9, on peut observer la distribution assez uniforme des pertes de paquets
engendrees par le modèle shadowing. Sur la figure 4.8, les nuds ne sont espaces que dune dizaine
de mètres. Il ny a aucune perte de paquets, les paquets se suivent donc sans interruption sur le
canal, et un acquittement est envoye pour chacun dentre eux. Sur la figure 4.9, qui correspond `
a
une periode o`
u les deux nuds sont dejà eloignes de 500 mètres, on remarque par contre quun
certain nombre de paquets de donnees ne sont pas acquittes, et meme que parfois les paquets de
donnees ne sont plus envoyes (lorsque les acquittements eux-memes sont perdus, au bout dun
certain nombre dessais, la couche MAC notifie lerreur à la couche superieure, et un système de
timer va empecher une tentative immediate de retransmission). Sur les chronogrammes presentes,
cest surtout la distribution dans les temps des acquittements manquants qui permet de bien
mettre en evidence la repartition assez homogène des erreurs de transmission avec le modèle
shadowing
Du fait que le modèle two-ray ground est utilise en quasi exclusivite dans les simulations realisees
dans la communaute ad-hoc, nous lavons retenu pour la suite de nos travaux. Sauf mention
contraire, cest donc ce modèle de propagation qui a ete utilise pour les simulations qui seront
presentees dans les paragraphes suivants.
4.5.2
Interf
erences
La seconde serie de simulations avait pour objectif dobserver les interferences entre deux
emetteurs. Pour ce faire, nous avons utilise quatre nuds dans notre scenario, repartis en deux
paires. Au depart, tous les mobiles sont très proches les uns des autres, puis les deux paires vont
progressivement seloigner. Dans chaque paire, lemetteur et le recepteur restent par contre très
proches (quelques mètres). Le trafic est un flux de paquets UDP de 1000 octets, envoyes aussi vite
que possible (on cherche à saturer la bande passante).
57

DE PRISE EN MAIN
paire de gauche
paire de droite
1.8e+06
1.6e+06
paire de gauche
paire de droite
1.6e+06
1.4e+06
1.4e+06
1.2e+06
1.2e+06
1e+06
800000
1e+06
800000
600000
600000
400000
400000
200000
200000
0
100
200
300
400
distance en metres
500
600
700
Fig. 4.10 Debit pour les deux paires

seloignant (sans RTS/CTS)
Fig. 4.12 Les deux paires

sentendent directement
100
200
300
400
distance en metres
500
600
700
Fig. 4.11 Debit pour les deux paires

seloignant (avec RTS/CTS)
Fig. 4.13 Les deux paires ne

se comprennent plus mais se
detectent
Fig. 4.14 Les deux paires

sont totalement idependantes
Fig. 4.15 Chronogramme quand les paires sont en zone de communication
Fig. 4.16 Chronogramme quand les paires sont en zone de detection de porteuse
58

DE PRISE EN MAIN
Les debits obtenus sur chacune des paires en fonction de la distance sont presentes sur les
figures 4.10 (sans RTS/CTS) et 4.11 (avec RTS/CTS). On remarque en premier lieu que lutilisation
ou non du mecanisme de RTS/CTS ne change pratiquement rien à lallure generale de la courbe.
Les RTS/CTS ne vont influer ici que sur le debit utile, qui est legèrement inferieur lorsquon les
utilise. On remarque ensuite la presence très nette de trois parties distinctes sur ces courbes.
De 0 `
a 250 m`
etres, tous les mobiles sont à portee directe de communication les uns des
autres (figure 4.12). Le medium radio est partage equitablement. Chaque paquet emis est
percu par les trois autres mobiles qui peuvent en particulier mettre à jour leur NAV.
De 250 `
a 550 m`
etres, les deux paires sont trop eloignees lune de lautre pour que le contenu
de leurs paquets soient compris (figure 4.13). Le NAV ne peut plus etre mis à jour. Par contre,
le mecanisme de detection de porteuse est encore capable de determiner quand des paquets
sont en cours de transmission dans lautre paire. Cela ce traduit par un partage equitable
du medium, mais avec une plus grande instabilite dans cette repartition. Cette instabilite est
liee aux EIFS qui sont utilises par les mobiles quand ils detectent de lactivite sur le canal.
Dans cette configuration, ils sont en particulier declenches dans une paire au moment o`
u le
canal devient libre après lemission dun acquittement dans lautre paire. Pour emettre son
prochain paquet, cette paire va devoir attendre un temps correspondant à EIFS+backoff, alors
que lautre se contente de DIFS+backoff. DIFS+backoff etant statistiquement plus petit, il y
a une forte probabilite quun mobile emette un certain nombre de paquets avant que lautre y
arrive et que la situation sinverse. Ceci est particulièrement visible sur les figures 4.15 et 4.16.
Sur la figure 4.15 on voit que les deux nuds accèdent au medium avec une alternance très
rapide (lorsque les emetteurs sont à portee de communication, un nud nemet en general pas
plus de deux ou trois paquets consecutifs avant de laisser la main). Sur la figure 4.16 o`
u les
emetteurs sont par contre en zone de detection de porteuse, lorsquun nud prend la main,
il la garde parfois pour un envoi comprenant jusquà une douzaine de paquets consecutifs.
Au del`
a de 550 m`
etres, les deux paires sont totalement independantes (figure 4.14), chacun
des emetteurs occupe la totalite de la bande passante et transmet en continu.
Dans la phase de 200 à 550 mètres, les RTS/CTS nont aucun effet en dehors de la diminution
du debit utile que lon avait dejà observe dans la première simulation. Ceci est tout à fait normal,
puisque lon se place dans une configuration (entre 250 et 550 mètres) o`
u les paquets RTS et CTS ne
peuvent pas plus etre compris que les paquets de donnees (les signaux sont recus avec une puissance
trop faible, les deux emetteurs sont dans la zone de detection de porteuse lun de lautre).
59
CHAPITRE
5
5.1
Sc
enarios avanc
es
Introduction et objectifs
Nous avons etudie jusquà present des configurations basiques, avec seulement deux mobiles
emetteurs. Les resultats obtenus vont nous servir maintenant à mieux comprendre les mecanismes
et les interactions qui se deroulent dans des scenarios plus complexes. Ces scenarios vont desormais
compter plus de mobiles, et les configurations vont etre plus caracteristiques des reseaux ad hoc.
Nous nous interesserons en premier lieu à la structure en chane, qui est à la base meme des
reseaux radio multi-sauts. Nous considererons ensuite des configurations o`
u certains mobiles sont
plus affectes par les interferences que dautres. Et nous terminerons par une chane perturbee de
manière inegale.
5.2
Trois paires
Le scenario que nous presentons maintenant à pour but de mettre en evidence certains problèmes
dequite dans laccès au medium avec 802.11. Nous utilisons six mobiles que nous placons comme
indique sur la figure 5.1 : ils sont tous initialement très proches les uns des autres. Les mobiles
sont repartis en trois paires demetteur / recepteur. Dans chaque paire, lemetteur essaie denvoyer
autant de paquets UDP de 1000 octets que possible à son recepteur (la file dattente demission est
continuellement pleine). La vitesse de transmission est de 2 Mbit/s et le mecanisme RTS/CTS est
utilise.
Lidee du scenario est de produire une situation typique des reseaux ad hoc o`
u certains mobiles
sont plus soumis à des interferences que dautres. Pour ce faire, au cours de la simulation, nous
deplacons progressivement les paires exterieures à la vitesse constante de 25 mètres par seconde.
Au fur et à mesure du deroulement du scenario, les mobiles vont tout dabord tous interferer les
Fig. 5.2 Interferences non symetriques entre

les 3 paires
Fig. 5.1 Position initiale des 3 paires

60
CHAPITRE 5. SCENARIOS
AVANCES
uns avec les autres, puis les paires exterieures vont continuer à interferer avec la paire centrale mais
sans se gener entre elles (figure 5.2), et enfin les trois paires vont etre suffisamment eloignees les
unes des autres pour acceder au canal en meme temps sans problème. Nous obtenons les debits
presentes sur la figure 5.3, ils peuvent etre interpretes comme suit :
De 0 `
a 5 secondes (les paires exterieures sont entre 0 et 125 mètres de la paire centrale),
les trois paires sont en contact direct (elles sont à portee de communication les unes des
autres). Meme si le reseau est sature, comme les debits demandes sont identiques, la bande
passante est partagee de manière equitable (le debit utile maximal de 1.6 Mbit/s environ
divise par 3).
De 5 `
a 11 secondes (les paires exterieures sont desormais entre 125 et 275 mètres de la paire
centrale, mais surtout entre 250 et 550 mètres lune de lautre) les communications (et donc la
mise à jour du NAV grace aux RTS/CTS) nest plus possible entre les paires exterieures, mais
comme elles detectent reciproquement leurs porteuses, elle savent que le canal est utilise et le
partage encore de manière assez equitable (environ un tiers chacune). Le canal est cependant
un peu moins bien partage. La raison se trouve dans le phenomène decrit dans la simulation
des deux paires, au moment o`
u elles sont dans les zones de detection de porteuse lune de
lautre. Le declenchement des EIFS est à la base du phenomène dinstabilite.
De 11 `
a 22 secondes (les paires exterieures sont entre 275 et 550 mètres de la paire centrale)
la paire centrale est dans une situation differente des deux autres paires. Elle detecte la
porteuse des deux paires exterieures, alors que ces dernières ne detectent chacune que celle
de la paire centrale. Dans ce contexte asymetrique, le mecanisme daccès au canal presente
une faiblesse très nette. Dès que la paire centrale perd laccès au canal, elle a enormement
de difficultes à le recuperer. Le debit de la paire centrale est quasiment nul durant cette
periode, alors que celui des paires exterieures atteint le maximum possible. Ceci sexplique
de la facon suivante : la paire centrale ne peut emettre que lorsque les deux autres sont
silencieuses pendant une periode suffisante. Mais les deux autres ne se genent pas entre
elles, et il ny a donc aucune raison pour quelles soient synchronisees. De ce fait, il ny a
pas de raison pour que leurs periodes de backoff concident. De plus, plus la charge utile des
paquets est importante, plus petites sont les chances pour que les backoff des paires exterieures
concident. La figure 5.5 montre le decalage existant entre les periodes de silence des deux
paires exterieures. Le phenomène est encore amplifie par le mecanisme EIFS de 802.11. La
figure 5.4 presente ce qui se passe dune facon simplifiee (pour des raisons de lisibilite lechelle
de temps nest pas respectee entre les differents elements). On peut tout dabord noter que
meme si dans la realite les differents mobiles ne commenceraient pas forcement de manière
synchronisee, le problème apparatrait neanmoins au bout de quelques instants. En premier
lieu, le canal doit etre libre pendant une periode DIFS avant quun nud decide dessayer
de transmettre (figure 5.4a). Les nuds attendent ensuite pendant une periode de backoff
aleatoire (figure 5.4b). Comme lemetteur de la première paire a termine de decrementer
son backoff et que le canal est toujours libre, il commence à transmettre, brouillant ainsi la
seconde paire qui entre alors en periode de defering jusquà ce que le canal soit à nouveau
libre. Comme la troisième paire nest pas genee, elle peut terminer la decrementation de son
backoff et commencer elle aussi à emettre (figure 5.4c). A cause de lactivite sur le canal venant
de la troisième paire, la deuxième doit rester plus longtemps en defering. Et quand le canal
redevient enfin libre, elle doit encore attendre pendant une periode EIFS (qui est environ 6
61
AVANCES
DIFS
temps
DIFS
(a)
temps
DIFS
temps
DIFS
Backoff
DIFS
Backoff
temps
(b)
temps
1.6e+06
DIFS
Backoff
temps
1.4e+06
debit dans la paire de gauche
debit dans la paire centrale
debit dans la paire de droite
1.2e+06
DIFS
Backoff DATA
DIFS
Backoff Defer
temps
(c)
temps
1e+06
DIFS
Backoff
DATA
temps
800000
DIFS
Backoff DATA
DIFS
Backoff Defer
DIFS
600000
temps
EIFS
(d)
temps
400000
DIFS
Backoff
DATA
DIFS
temps
200000
DIFS
Backoff DATA
DIFS Backoff
DATA
DIFS
Backoff Defer
EIFS
Defer
temps
0
5
10
15
temps en secondes
20
25
30
(e)
temps
DIFS
Backoff
DATA
DIFS Backoff
temps
Fig. 5.3 Debit en fonction du temps dans le

scenario des trois paires
Fig. 5.4 Detail du problème daccès au

medium avec lEIFS
fois plus longue quun DIFS). Entre temps, les deux autres paires ont dejà recommence un
nouveau cycle (figure 5.4d) et tout recommence ... (figure 5.4e).
Au del`
a de 22 secondes Les trois paires sont suffisamment eloignees les unes des autres.
Elles ne detectent plus les porteuses des autres et peuvent emettre en meme temps au debit
maximum.
Il faut noter que pour la periode problematique, lamplification des problèmes par le mecanisme
des EIFS peut etre quantifiee. Nous avons effectue une serie de simulations en placant les trois
paires dans la position correspondant à la periode des secondes 11 à 22 de la figure 5.3. Pour
certaines mesures, nous avons utilise des EIFS ayant leur duree normale (364 s) et dans dautres
des EIFS ayant la meme duree que les DIFS (50 s). Nous avons egalement effectue ces simulations
an activant ou non les RTS/CTS. La figure 5.6 presente ces resultats :
Fig. 5.5 Details de la simulation entre les secondes 11 et 22
62
AVANCES
0.07
2 Mb/s without RTS/CTS: DIFS vs. DIFS
2 Mb/s with RTS/CTS: DIFS vs. DIFS
2 Mb/s without RTS/CTS: EIFS vs. DIFS
2 Mb/s with RTS/CTS: EIFS vs. DIFS
0.06
Central pair time-share (%)
0.05
0.04
0.03
0.02
0.01
0
700
800
900
1000
1100
Packet size (bytes)
1200
1300
1400
Fig. 5.6 Proportion daccès au canal pour la paire centrale en fonction de la taille des paquets et
de la duree de lEIFS (periode des secondes 11 à 22).
Avec les EIFS normaux (364s), la paire centrale obtient aux alentours de 1% de la bande
passante. Si les nuds utilisent les RTS/CTS, la paire centrale obtient un debit encore
legèrement inferieur.
Avec des EIFS courts (50s, soit la meme duree que les DIFS), la paire centrale obtient
entre 5 et 6 fois plus de bande passante. Mais avec 5 ou 6% de la bande passante totale, elle
reste encore très largement defavorisee vis-à-vis des paires exterieures. Cette limitation vient
de leffet de la non synchronisation des paires exterieurs dont nous avons parle precedemment.
Là encore, les RTS/CTS ont un impact negatif pour le partage equitable, lorsquils sont
actives, la paire centrale a plus de difficultes à acceder au canal que lorsquils ne le sont
pas. On remarque enfin que les chances daccès au canal de la paire centrale diminuent avec
laugmentation de la taille des paquets. Plus les paquets sont longs, plus la proportion du
temps ou le canal est occupe (transmission de donnees ou de paquets de controle) par rapport
au temps ou le canal est libre (periodes de backoff, DIFS, EIFS) diminue. Par consequent les
chances que les periodes de silence des paires exterieures concident diminuent aussi.
Cette experience met donc en evidence un problème dinegalite important dans laccès au
medium radio de 802.11.
5.3
Sauts multiples en configuration de chane
Jusqualors nous nous sommes interesses quà des configurations qui ne faisaient pas appel `
a la
capacite de routage des reseaux ad-hoc. Dans le scenario presente sur la figure 5.7, nous cherchons
maintenant à voir ce quil se passe dans une chane assez longue (comportant jusquà 7 sauts) si
lemetteur envoie autant de donnees que possible.
Tout dabord, il est important de comprendre que dans ce genre de scenario, le protocole de
routage utilise a dejà un impact important. En effet, si des interferences ou des collisions au niveau
de 802.11 provoquent la perte de certains paquets necessaires pour le routage voire des incapacites
totales de communication un peu longues entre certains mobiles, cela peut conduire le protocole
de routage à declarer lexpiration de la route. Les timers et les mecanismes declenchant ces expi-
63
AVANCES
Fig. 5.7 La chane à 8 nuds
rations varient dun protocole de routage à lautre, et il en est de meme pour les algorithmes de
reconstruction quune perte de route va declencher.
Par exemple, dans notre scenario de chane, en cas dutilisation dun protocole proactif, la perte
de paquets hello consecutifs peut provoquer la rupture de la route. Cela va declencher une première
mise à jour en cascade des tables de routage. Quand les paquets hello sont ensuite à nouveaux recus,
cela va provoquer une seconde mise à jour en cascade. Il y aura donc une periode dinstabilite dans
letat des tables de routage (o`
u il ny aura plus de route de bout en bout de la chane), ainsi quune
charge eventuellement importante du reseau. Dans le cas dun protocole reactif, la perte de paquets
de recherche de route peut amener lemetteur à penser quil ny a pas de route disponible du tout ;
et donc a attendre un nouvel essai initie par une couche superieure pour à nouveau essayer de
trouver la route.
Cette mise en garde effectuee, revenons à la description du scenario. Il a consiste à faire transiter
des paquets sur une chane de plus en plus longue (de 2 à 8 nuds et donc de 1 à 7 sauts). Les nuds
sont places à 200 mètres les uns des autres. Dans la section 4.5.1, nous avons vu que dans le cas
du modèle two-ray ground, cela correspondait à un placement tel quun nud peut communiquer
avec ses voisins de gauche et de droite, et que sa porteuse est detectee par les nuds à deux sauts
et pas plus loin. Cela correspond evidemment à lidee que lon se fait dune communication multisauts dans un veritable reseau ad hoc, o`
u les nuds dune route sont en general choisis de sorte `
a
minimiser si possible le nombre de sauts.
La figure 5.8 montre les debits mesures sur la chane en fonction du nombre de sauts. Le debit de
bout en bout diminue logiquement très vite lorsque lon augmente le nombre de sauts (1.6 Mbit/s
avec un seul saut, 0.8 Mbit/s avec deux sauts, environ 0.55 Mbit/s avec un troisième) pour se
stabiliser aux alentours de 300 kbit/s lorsque plus de 4 nuds sont impliques. Dans les cas de
chanes assez longues, on remarque egalement un certaine instabilite du debit de bout en bout.
La figure 5.9 presente les chronogrammes demissions pour des chanes de 2 à 8 nuds. Les
RTS/CTS netaient pas utilises, seuls les donnees et leurs eventuels acquittements sont donc
representes. 2 IF0 et 2 IF1 representent les emissions par les nuds 0 et 1 dans la chane `
a un
saut, 3 IF0, 3 IF1 et 3 IF2 representent les emissions par les nuds 0, 1 et 2 dans la chane `
a
deux saut et ainsi de suite. Cette partie du chronogramme correspond au tout debut des echanges,
on y voit la forme en V particulière correspondant aux paquets RouteRequest et RouteReply qui
traversent la chane de bout en bout pour construire la route. On remarque que ces paquets RouteRequest et RouteReply ne sont pas acquittes (ils sont diffuses) mais que les paquets de donnees
64
AVANCES
1.8e+06
1 saut
2 sauts
3 sauts
4 sauts
5 sauts
6 sauts
7 sauts
1.6e+06
1.4e+06
1.2e+06
1e+06
800000
600000
400000
200000
0
0
10
20
30
temps en secondes
40
50
60
Fig. 5.8 Debit sur la chane de 2 à 8 nuds (UDP, pas de RTS/CTS)
eux le sont bien (les acquittements apparaissent sous la forme de traits fins, car ce sont des paquets
très courts).
On voit egalement que lorsque le nombre de sauts augmente, certains nuds ont du mal `
a
acceder au medium. Par exemple, dans la chane à 8 nuds (dernière serie), après la traversee
de la chane complète par trois paquets de donnees, le nud 1 monopolise le canal pendant une
douzaine de paquets (ces paquets sont bien recus au nud 2 comme le prouvent les acquittements
quil renvoie, mais il narrive pas ensuite à acceder au canal pour continuer à router ces paquets).
Ces effets sont causes par la combinaison de plusieurs facteurs : le nud 0 a toujours des paquets
à envoyer et le nud 1 est gene par plus de mobiles que le nud 0 (0 ne peut pas emettre en
meme temps que 1 ou 2, 1 ne peut emettre en meme temps que 0, 2 et 3). Sur ces chronogrammes,
il est egalement aise de constater la reutilisation spatiale (si deux ou plus nuds emettent `
a un
instant donne, cest quils sont suffisamment eloignes pour ne pas interferer ni meme se detecter,
par exemple les nuds 0 et 3 emettent parfois en meme temps).
Lallure generale des chronogrammes pour les chanes assez longues (5 sauts ou plus) permet
de tout de suite saisir certaines informations confirmees par dautres analyses des traces : dans
un scenario de chane, avec un modèle de propagation two-rays ground, les paquets ont de fortes
chances detre bloques au niveau des 3 premiers nuds ; mais sils atteignent le quatrième, alors
leur chance datteindre la destination finale est très importante. Ce blocage au niveau des premiers
nuds est en fait d
u aux difficultes daccès au canal puisque la source essaie denvoyer autant de
paquets que possible (et que comme nous lavons mentionne, elle rencontre moins de contention
que les autres.) Plus loin sur la chane le problème ne se pose plus car les nuds ne cherchent `
a
emettre que ce quils ont pu recevoir.
65
AVANCES
Fig. 5.9 Chronogrammes de chanes de 2 à 8 nuds
66
AVANCES
Nous avons ensuite effectue la meme simulation mais en ajoutant lutilisation des RTS/CTS.
Le debit de bout en bout obtenu en fonction du nombre de sauts est presente sur la figure 5.10. Les
debits pour les chanes courtes (1, 2 et 3 sauts) sont assez similaires à ceux obtenus si lon nutilise
pas les RTS/CTS. Bien s
ur, dans leurs cas, on observe une diminution du debit proportionnelle
au temps supplementaire de transmission des paquets RTS/CTS (debits respectifs de 1.4, 0.7 et
0.4 Mbit/s respectivement). Mais lorsque la chane continue de sallonger, le debit de bout en bout
devient vraiment très faible (moins de 100 kbit/s à partir de 5 sauts). Les RTS/CTS semble donc
dans ce contexte avoir un contre-effet et etre particulièrement dommageables. Les chronogrammes
des figures 5.11 (sans RTS/CTS) et 5.12 (avec RTS/CTS) montrent que dans le cas de lutilisation
des RTS/CTS, très peu de paquets arrivent à traverser la chane de facon consecutive. Le nud
0 envoie en quasi permanence des paquets au nud 1, mais celui-ci narrive que rarement `
a les
faire suivre. On remarque egalement des coupures très frequentes de la route, qui force AODV `
a
la reconstruire (ceci se voit très bien avec les formes en V precedant les periodes o`
u quelques
paquets arrivent à traverser la chane complètement.
Les chronogrammes des figures 5.13 (sans RTS/CTS) et 5.14 (avec RTS/CTS) permettent de
voir plus en detail ce qui se passe. En labsence de RTS/CTS, on remarque une forte reutilisation
spatiale, les nuds situes à trois sauts ou plus len de lautre pouvant en general emettre en meme
temps. Avec les RTS/CTS maintenant, on remarque que cest plus problematique. Sur la figure 5.14
par exemple, on voit que lorsque le nud 3 accède au canal, le nud 0 envoie plusieurs RTS qui ne
recoivent pas de reponse de 1 (et de meme, 1 envoie plusieurs RTS à 2 qui ny repond pas quand 4
est en train denvoyer des donnees).
Sur le chronogramme de la figure 5.15 (qui correspond à une autre periode de la simulation
de la chane de 8 nuds avec RTS/CTS, on voit cependant que cette reutilisation spatiale peut
parfois avoir lieu. On voit bien en particulier sur cette figure les emissions en parallèle des mobiles
(0,4), (1,5) et (2,6). Ceci est dailleurs en contradiction avec [45] qui utilisait aussi NS2 mais qui
ne semble avoir retenu que le cas de la figure 5.14.
5.4
La chane fixe et la paire de perturbateurs
Cette experience montre limpact dans un contexte plus realiste du phenomène qui a ete mis en
lumière dans le scenario precedent. La topologie est celle presentee sur la figure 5.16 : un flux UDP
à debit constant traverse une chane de six mobiles (similaire à celle utilisee dans les premières
simulations, avec une distance de 200 mètres entre chaque nud). Une paire de mobiles (entre
lesquels existe un autre flux à debit constant) est initialement situee loin de la chane (en dehors
de toute zone dinterferences). Les mobiles de la paire sont très proches lun de lautre (un mètre)
durant la totalite de la simulation. Les nuds de la chane restent fixes du debut à la fin. Au fur
et à mesure de la simulation, la paire va se deplacer et va progressivement entrer puis ressortir de
la zone dinterferences des nuds de la chane.
La simulation a ete effectuee pour differents debits demandes sur les deux flux (2000, 1333,
1000, 800, 400 et 200 kbit/s). Excepte pour des debits demandes de 200 kbit/s, le reseau est sature
et la bande passante nest pas suffisante pour delivrer la totalite des paquets demandes. Pour des
raisons de lisibilite la figure 5.17 ne presente quune moyenne des debits sur la chane simules en
fonction du temps. Le but de cette courbe est de donner une idee des phenomènes dinterferences
en fonction de la position des divers mobiles ; plus que les debits chiffres, cest la forme de la courbe
qui est importante ici. On remarque immediatement un effet de symetrie. Au tout debut et `
a la
67
AVANCES
1.8e+06
1 saut
2 sauts
3 sauts
4 sauts
5 sauts
6 sauts
7 sauts
1.6e+06
1.4e+06
1.2e+06
1e+06
800000
600000
400000
200000
0
0
10
20
30
temps en secondes
40
50
60
Fig. 5.10 Debit sur la chane de 2 à 8 nuds (UDP, avec les RTS/CTS)
Fig. 5.11 Chronogramme dans la chane à 8 nuds (UDP, sans les RTS/CTS), vue large
Fig. 5.12 Chronogramme dans la chane à 8 nuds (UDP, avec les RTS/CTS), vue large
68
AVANCES
Fig. 5.13 Chronogramme dans la chane à 8 nuds (UDP, sans les RTS/CTS), detail
Fig. 5.14 Chronogramme dans la chane à 8 nuds (UDP, avec les RTS/CTS), detail
Fig. 5.15 Chronogramme dans la chane à 8 nuds (UDP, avec les RTS/CTS), detail 2
69
AVANCES
350000
300000
250000
200000
150000
100000
50000
0
10
Fig. 5.16 Le scenario de la chane et

du couple de perturbateurs
20
30
temps en secondes
40
50
Fig. 5.17 Debit moyen sur la chane
fin de la simulation, la paire perturbatrice est trop loin de la chane pour la gener, cest là que lon
observe logiquement le debit maximum. On remarque ensuite que lorsque la paire perturbatrice
est très proche de la chane (partie centrale de la courbe, entre les secondes 25 et 45 environ), le
debit sur la chane est reduit mais neanmoins existant. Et finalement on observe deux zones o`
u le
flux sur la chane est complètement stoppe ou presque (secondes 10 - 25 et 45 - 50). Ces periodes
correspondent aux moment o`
u la paire perturbatrice est dans la zone de detection de porteuse des
nuds centraux de la chane. Le phenomène qui se produit alors est très proche de celui rencontre
dans la simulation des trois paires : les mobiles au centre de la chane detectent les porteuses des
premiers mobiles de la chane mais aussi celles de la paire perturbatrice. Ils sont dans la meme
situation que la paire centrale dans le scenario des trois paires, puisque quà cet instant la paire
perturbatrice et les premiers mobiles de la chane ne se genent pas du tout et emettent de facon
desynchronisee.
5.5
Le probl`
eme de lasym
etrie
Les problèmes que nous avons mis en lumière dans les simulations precedentes sont caracteristiques des reseaux ad-hoc. Leffet le plus remarquable est lincapacite pour certains
emetteurs dacceder au canal radio. Contrairement aux problèmes dequite mis en evidence dans
[44, 48] o`
u linegalite provient de collisions repetees, linegalite mise en evidence ici provient de
limpossibilite dacceder au medium radio (certains mobiles ne peuvent pas sexprimer). Ce type
de comportement se produit lorsquil existe une asymetrie dans les interferences entre les differents
mobiles. La notion dasymetrie a ete mentionnee dans [47], mais aucune explication de 802.11 face
à cette asymetrie na ete apportee. Or le scenario des trois paires permet de bien comprendre
lorigine du problème. En effet, pour un mobile connaissant une contention plus importante, un
certain nombre dautres mobiles en competition avec lui ne se genent pas du tout entre eux, et
leurs emissions ne sont donc pas synchronisees. Pour que le mobiles mis en defaut puisse acceder au
70
AVANCES
canal, il faut que les periodes de silence des autres mobiles se recouvrent. Or la probabilite dun tel
recouvrement est faible, et le mobile percoit le canal comme occupe dès que lun ou lautre lutilise.
Dans les configurations que nous avons presentees, les mobiles les plus exposes (la paire centrale
dans le scenario des des trois paires par exemple) percoivent le canal occupe en quasi permanence, et
les mobiles geneurs le percoivent presque tout le temps libre (ils continuent donc leurs emissions
de plus belle).
Ce problème nest pas un problème de nuds caches et ne peut pas etre resolu par le mecanisme
des RTS/CTS. En effet, les recepteurs des mobiles desynchronises ne sont pas necessairement les
memes et de plus les mobiles peuvent etre trop loin les une des autres pour comprendre le contenu
des paquets de controle. Dans le contexte prevu par 802.11 (mobiles attaches à des stations de base
ou à portee directe de communication) le type dasymetrie decrit precedemment ne se produit pas.
Soit les mobiles sont à portee de communication directe, soit ils sont relies à une meme station
de base et lorsquils communiquent avec elle les RTS ou CTS quelle envoie suffisent à reserver
convenablement le canal et y permettre un accès equitable.
Nous avons vu egalement que le mecanisme des EIFS qui est sense proteger les acquittements
pouvait amplifier le problème de lasynchronisme que nous venons decrire. De meme, nous avons
vu dans letude des resultats de la chane que les RTS/CTS pouvaient avoir eu aussi un impact
particulièrement negatif dans le cadre de reseaux multi-sauts etendus.
5.6
Conclusion sur ces simulations
Linegalite dans laccès au medium radio rencontree dans des configurations de base des reseaux
ad hoc a une impact fondamental sur les protocoles des couches superieures. En effet, la plupart des
protocoles dans les reseaux ad hoc basent leur fonctionnement sur la connaissance des liens. Dès
quun lien apparat ou disparat, des informations sont mises à jour dans le reseau. Dans le cadre
dun reseau fixe, si chaque mobile est en mesure de sannoncer regulièrement les liens seront connus
et consideres comme stables, ce qui entranera peu de trafic de controle. Par contre, si certains
mobiles ne sont pas en mesure dacceder regulièrement au medium, des liens vont apparatre et
disparatre de manière cyclique alors que ces liens existent bien physiquement ! Ceci entranera une
charge de trafic de controle non negligeable qui aurait pu etre evitee si tous les mobiles avaient
pu emettre de manière equitable (ces cassures de lien repetees et le trafic de controle genere sont
particulièrement visibles dans le chronogramme de la chane de 8 nuds avec RTS/CTS, sur la
figure 5.10 et 5.14). Cela implique aussi que les protocoles de routage nauront pas une bonne
vision du reseau puisquils ne verront pas certains liens existants reellement. Ils nauront donc
quune connaissance partielle de la topologie. Ils pourraient alors prendre des decisions adaptees
à la vision quils ont alors quelles ne le sont peut-etre pas à la topologie reelle. Enfin, une telle
inegalite implique que certaines communications ne pourront obtenir quun debit très faible voire
nul à certains moments.
71
CHAPITRE
Quelques
solutions
aux
probl`
emes d
equit
e dans les
r
eseaux ad hoc
Plusieurs solutions ont ete proposees pour resoudre le problème dequite dans laccès au medium
radio.
MACAW [46] propose une gestion differente de la fenetre de contention : lidee est de ne pas
favoriser la station qui vient juste demettre comme le fait le Binary Exponential Backoff. Cette
solution concerne les problèmes dinegalite provenant de collisions mais elle ne resoudra pas les
problèmes o`
u certains mobiles naccèdent pas du tout au medium.
Les solutions elaborees dans [47] se basent sur un graphe de contention des flux ce qui suppose
une connaissance globale du reseau ainsi que des flux achemines dans le reseau. Cette solution est
donc difficile à implanter en pratique.
Les travaux de Bensaou et al. [48, 38] ont une approche de faisabilite puisquils modifient 802.11
dans le but de garantir une meilleure equite. Lidee est que chaque mobile prenne en compte les
communications dans son voisinage à un saut afin de savoir sil peut emettre beaucoup ou sil
doit se ralentir. En comptant ses propres communications et les communications de ses voisins,
chaque mobile peut savoir sil a emis plus ou moins que ses voisins. Sil a emis plus, il augmente
sa fenetre de contention, ce qui lui permet statistiquement de ralentir ses emissions. Sil a emis
moins, il diminue sa fenetre de contention, ce qui lui permet statistiquement daugmenter ses
emissions. Avec ces modifications, le système doit alors se stabiliser sur une solution plus equitable.
Lidee est interessante (meme si lalgorithme na manifestement pas ete correctement finalise et
si quelques modifications simples lamelioreraient), mais il ne permet dequilibrer que des flux `
a
portee de communication. Or, comme dans le scenario des trois paires par exemple, les emetteurs
sont en zone de detection de porteuse et ne peuvent pas directement communiquer. Dans ces cas,
les solutions de Bensaou et al. ne sappliquent pas.
Nous avons donc propose dans un premier temps une solution qui essaye de resoudre le problème
dequite quand les mobiles en competition ne peuvent pas communiquer. Par la suite, nous avons
propose une seconde solution, inspiree de celle de Bensaou et al., mais qui cherche à diffuser de
linformation dans son voisinage pour etre plus efficace.
6.1
Une solution historique et locale
Un certain nombre de contraintes que nous nous etions fixees nous on conduit à elaborer cette
première solution. Ces contraintes etaient les suivantes :
72
DANS LES
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLEMES
DEQUIT
E
RESEAUX
AD HOC
Minimiser les changements à apporter à 802.11 (notre approche est assez pragmatique, il est
important à nos yeux de chercher une solution qui puisse etre implementee concrètement dans
des materiels existants).
Garder la compatibilite avec les cartes 802.11 nayant pas ete modifiees
Fonctionner meme lorsque les mobiles impliques nont aucun moyen de communiquer, meme
en passant par des intermediaires
Sous nos contraintes il peut parfois etre impossible de communiquer avec les mobiles qui nous
genent ni meme de les identifier. Il est egalement impossible pour un mobile de se rendre compte que
son activite, lorsquelle est cumulee à celles dautres emetteurs, empeche dautres mobiles dacceder
au canal (par exemple, du point de vue des paires exterieures dans le scenario des trois paires, le
canal est toujours libre et elles en profitent logiquement pour emettre au debit maximum). Notre
solution consiste à chercher à penaliser les mobiles qui transmettent beaucoup. De cette manière
on espère que lorsquils seront forces de se taire, les chances que les periodes de silence concident
au niveau des mobiles genes augmenteront et que ces derniers pourront enfin emettre.
La modification que nous proposons concerne le backoff et son calcul devient le suivant : au
niveau de chaque nud le temps est decoupe en periodes de longueur fixe (par exemple une
seconde). La situation est la meme pour chaque nud en debut de periode. Ensuite, à chaque
fois que le nud gagne laccès au canal et envoie un paquet, une penalite est ajoutee au backoff
(le backoff pour les paquets suivants sera toujours aleatoire, mais statistiquement plus grand).
En dehors de cette penalite, le calcul du backoff reste strictement identique à celui decrit dans
la norme. Nous avons soigneusement choisi la courbe de progression de la penalite (ou malus)
qui est presentee sur la figure 6.1. Cette courbe est caracterisee par un premier plateau o`
u le
malus est nul ou presque (les premiers paquets ne sont pas penalises), par une rampe assez
raide (maintenant que lon a dejà beaucoup parle, il est temps de laisser de la place aux
autres) et enfin par un plateau assez haut (si lon continuait à augmenter la penalite de manière
exponentielle, lorsquil ny a quun seul flux, son debit serait trop penalise). Au debut de chaque
cycle, le compteur est re-initialise et la penalite redevient nulle. Dans ce système, les paramètres
qui peuvent etre ajustes sont essentiellement la duree du cycle et la forme de la courbe de
progression de la penalite. Il faut noter que nous navons pas essaye de favoriser les mobiles en
defaut en diminuant la borne maximale de leur fenetre de contention en dessous du seuil cwMin
fixe par la norme. Nous pensions que la norme avait ses raisons davoir fixe cwMin à 31 et que
reduire cette valeur pourrait notamment augmenter de manière sensible les collisions dans le reseau.
Bien que cette methode soit simple, elle donne des resultats tout à fait interessants. Dans les
simulations, il est apparu que la probabilite pour un mobile detre complètement ecrase par ses
voisins non directs est beaucoup plus faible quavec 802.11 non modifiee.
La figure 6.2 montre les debits obtenus dans le scenario des trois paire en utilisant le malus de
la figure 6.1. On remarque que dans la zone centrale de la courbe (lorsque la paire centrale detecte
les porteuses des deux paires exterieures sans pouvoir communiquer avec elles) laccès au canal
nest peut-etre pas encore equiprobable pour les trois paires, mais que la paire centrale nest plus
complètement etouffee par les deux autres (elle obtient un debit de 300 - 350 kbit/s, contre environ
800 kbit/s pour chacune des paires exterieures). Le principal inconvenient de la methode est aussi
clairement visible sur cette courbe, puisque le debit maximum dune paire lorsquelle ne subit pas
dinterferences est sevèrement limite (seulement environ 1 Mbit/s au delà de 22 secondes, alors que
sans malus on atteint 1.6 Mbit/s, soit une reduction de près de 40%). Comme nous augmentons
73
DANS LES
DEQUIT
E
RESEAUX
AD HOC
1.6e+06
paire de gauche
paire centrale
paire de droite
1.4e+06
1.2e+06
250
malus
Malus (en nombre de time slots)
200
150
1e+06
800000
600000
400000
100
200000
50
0
5
0
0
10
15
20
paquets envoyes depuis le debut du cycle
25
30
10
15
temps en secondes
20
25
Fig. 6.1 Progression de la penalite en Fig. 6.2 La simulation des 3 paires en utilisant le
fonction du nombre de paquets envoyes mecanisme du malus
statistiquement le backoff, le nombre maximum de paquets quun mobile peut envoyer par seconde
diminue. Mais il faut garder à lesprit que ce problème devient rapidement imperceptible lorsque le
nombre de flux en competition à un instant donne pour laccès au canal augmente. Sur la première
partie de la courbe (de 0 à 10 secondes), les trois flux sont en competition et leur debit agrege
est de 4503 soit 1350 kbit/s ; avec trois flux en competition, la perte de debit engendree par le
mecanisme du malus passe donc dejà en-dessous des 20%.
Nous avons egalement teste notre système sur le scenario de la chane et de la paire perturbatrice
(figure 5.16), mais avec des flux TCP `
a la place des flux UDP, et un debit demande pour chacun
dentre eux de 2 Mbit/s. Avec la version normale de 802.11, nous avons obtenu des resultats
desastreux (figure 6.3). Il faut bien garder à lesprit que le caractère erratique de laccès au medium
dans ces conditions empèche de nombreux acquittements de TCP darriver à temps, empechant
ainsi parfois TOUTE progression de la communication. La version modifiee se comporte beaucoup
mieux (figure 6.4). Notons quen labsence de contention, le debit sur la paire perturbatrice est
fortement affecte (periodes des secondes 0 à 10 et de 53 à la fin) puisque le mecanisme du malus le
fait passer de 1250 kbit/s à un peu moins de 950 kbit/s, mais que le debit sur la chane ne change
pas (un peu plus de 200 kbit/s, avec ou sans malus). Comme nous lavions dejà enonce, leffet
negatif du malus sur le debit decrot très rapidement avec le nombre de mobiles en contention.
Lautre inconvenient principal de la methode, qui napparat pas cette fois-ci sur les courbes, est
la tendance à produire des transferts par rafale, qui peuvent causer des problèmes à certains types
dapplications (multimedia utilisant des petits tampons en particulier, comme la telephonie). Si un
emetteur ne rencontre pas beaucoup de difficultes pour acceder au canal et quil a beaucoup de
paquets en attente, il va les emettre à la suite les uns des autres jusquà ce que la penalite devienne
non negligeable et le freine. Les emissions dun tel mobile seront donc en majorite en debut de
cycle. A ce propos, la taille de la fenetre TCP a une importance : trop petite et TCP pensera quil
y a de la congestion lorsque le debit sera reduit par la penalite ; il reagira en diminuant encore sa
fenetre, ce qui est mauvais.
74
DANS LES
DEQUIT
E
RESEAUX
AD HOC
1.4e+06
1e+06
chaine
paire perturbatrice
900000
1.2e+06
800000
Dbit (en bit par seconde)
Dbit (en bit par seconde)
chaine
paire perturbatrice
1e+06
800000
600000
700000
600000
500000
400000
300000
400000
200000
200000
100000
0
0
0
10
20
30
Temps (en secondes)
40
50
60
10
20
30
Temps (en secondes)
40
50
60
Fig. 6.3 Debits dans la simulation de la chane Fig. 6.4 Debits dans la simulation de la chane
et du perturbateur (TCP, 802.11 non modifie)
et du perturbateur (TCP, 802.11 modifie)
Au niveau des amelioration possibles de ce système, on peut citer dune part le changement
dans le comptage effectue. Plutot que de compter les paquets indifferemment, il serait peut-etre
plus judicieux de prendre en compte leur taille. En effet, en fonction des applications (telnet par
exemple) et des protocoles utilises (TCP avec ses acquittements), il se peut quil y ait beaucoup de
paquets très petits à transferer. Ces dernier ferait très vite progresser le malus alors que finalement
ils ne genent peut-etre pas beaucoup les mobiles du voisinage. Dautre part, la courbe de progression
de la penalite meriterait detre etudiee plus en detail egalement. Sous sa forme actuelle elle donne
des resultats dej`
a très encourageants, mais nous avons le sentiment que ces derniers pourraient etre
encore ameliores.
Remarquons finalement que ce système de penalite sur le backoff permet bien linter-operabilite
avec les mobiles utilisant des cartes 802.11 non modifiees. Les mobiles utilisant la version modifiee
seront un peu desavantages en terme de debit possible, mais la communication restera possible.
6.2
6.2.1
Une solution
etendue g
eographiquement
Point de d
epart et algorithme
Nous sommes partis des travaux de Bensaou et al. [48]. Chaque mobile effectue un comptage
des paquets en terme doccupation du medium. Le nombre de paquets quil envoie est stocke dans
la variable Wi et le nombre de paquets envoyes par ses voisins est stocke dans la variable Wo . Les
variables i et o correspondent respectivement à lallocation faite au nud i et celle faite `
a ses
Wi
o
voisins. Ils definissent un index dequite egal à W
.
La
fen
e
tre
de
contention
de
chaque
mobile
i
o
est alors ajustee de la manière suivante : chaque mobile double sa fenetre de contention si son
index dequite devient superieur à une constante C, chaque mobile divise par deux sa fenetre de
contention si son index dequite devient inferieur à C1 , et chaque mobile ne fait rien si son index
dequite est compris entre C1 et C.
Comme nous lavons dit dans lintroduction de ce chapitre, lalgorithme propose presente
quelques faiblesses. Dune part, le comptage des paquets est effectue de manière anarchique : cer75
DANS LES
DEQUIT
E
RESEAUX
AD HOC
B
A
D
Fig. 6.5 La configuration à quatre nuds
tains paquets sont comptes plusieurs fois sans aucune raison. Dautre part, lindex dequite pour
chaque mobile devrait se stabiliser vers 1 or il se situe entre 2 et 4. Enfin, dans les scenarios proposes, la taille des fenetres de contention des mobiles se bloque à la taille maximale autorisee par
802.11, ce qui conduit à une perte de debit global importante.
Neanmoins les approches despionnage du medium et de faisabilite nous semblaient interessantes.
Nous avons donc garde le socle de lalgorithme presente par Bensaou et al. et nous lavons modifie
afin dapporter un espionnage etendu et de reduire la perte globale de bande passante.
Un espionnage
etendu Dans lalgorithme de depart, chaque mobile ne considère que les paquets
qui sont envoyes dans sa zone de communication. Or deux flux peuvent etre en competition meme
si leurs emetteurs ne sont pas à portee de communication. Par exemple, dans la figure 6.5, les
emetteurs A et B ne se voient pas mais leurs flux associes sont en competition. Par consequent,
cette methode ne permet pas à un mobile devaluer toux les flux qui sont en competition avec le
flux dont il est emetteur.
Nous proposons donc que chaque mobile communique dans son acquittement (ou son CTS
quand il est actif) son estimation des communications voisines (Wo dans lalgorithme). Ceci va
permettre à lemetteur dun flux davoir une connaissance plus etendue des flux en competition. Il
faut neanmoins faire attention à ne pas compter plusieurs fois les paquets. Pour cela, chaque mobile
doit faire un comptage separe des paquets de mobiles voisins. Ensuite chaque mobile enverra dans
lACK ou le CTS la liste des mobiles connus comme etant voisins et le comptage Wo . Lorsque les
mobiles recoivent cette information, ils nont plus quà retirer le comptage des mobiles dejà connus
deux du Wo recu et mettre à jour leur nouveau Wo .
Lenvoi de la liste des voisins peut etre co
uteux, cest pourquoi nous proposons que seules les
entrees/sorties de cette liste soient integrees dans le paquet ACK ou CTS.
Ajustement de la fen
etre de contention A partir des donnees de comptage, le calcul de lindex
dequite intervient, puis en fonction de la valeur obtenue la fenetre de contention est ajustee. Dans
lalgorithme de depart, nous avons remarque que les changements dans la taille de la fenetre etaient
brusques et ne prenaient pas le temps de verifier quils etaient profitables.
Nous proposons donc de modifier lajustement de la fenetre de contention. Dans le cas o`
u un
mobile lèse ses voisins, la fenetre ne sera modifiee que si ces trois conditions sont remplies (le cas
o`
u le mobile est lese par ses voisins est symetrique) :
Lindex dequite doit depasser la valeur 1 augmentee dune tolerance fixee ;
La periode dadaptation de la fenetre de contention actuelle doit etre terminee ;
76
DANS LES
DEQUIT
E
RESEAUX
AD HOC
Levolution de lindex dequite doit etre superieure à 0.9, ceci afin de rendre compte si la
situation sest degradee ou amelioree.
Si ces conditions sont remplies, la fenetre de contention est multipliee par levolution de lindex
dequite et de Wi , plutot que par 2 (comme cest le cas dans lalgorithme de base). On assure ainsi
que la fenetre de contention est equilibree et prend en compte levolution propre du debit du mobile.
6.2.2
Quelques r
esultats
Ce travail a ete realise en fin de thèse, et je nous ne sommes malheureusement pas en mesure
dapporter des resultats detailles sur lalgorithme propose. Neanmoins, quelques scenarios ont ete
evalues afin de pouvoir comparer la version de base de Bensaou et al. et la version amelioree. Nous
avons effectue un certain nombre de simulation grace à NS2.
Premier sc
enario `
a 2 paires. Le scenario utilise est celui propose initialement par Bensaou et
al. dans [48], il est presente sur la figure 6.5. Dans ce scenario, il existe un flux entre A et C, ainsi
quun autre en B et D. Les trais en pointilles indiquent que B et C sont à portee de communication
mais ne senvoient pas de paquets de donnees. Les flux de donnees sont constitues de paquets UDP
de 1000 octets. Le debit demande par chacun des flux augmente avec le temps suivant la courbe
presentee sur la figure 6.6.
Sur la figure 6.7, on presente le debit de chacune des paires dans ce scenario si lon utilise
802.11 tel quil est implante dans NS2. A partir du moment o`
u le debit demande est suffisamment
important, on remarque le debit extremement faible entre A et B (de lordre de 100 kbit/s) alors
quil est une dizaine de fois plus important entre C et D (environ 1 Mbit/s). Le problème est detaille
dans [48], il provient de lutilisation des RTS/CTS. Dans ce scenario, A ne peut communiquer avec
B, ni meme detecter sa porteuse. Lorsque A veut envoyer un paquet de donnees à C, il commence
par lui envoyer un RTS. Mais C entend les messages de B, et si jamais B est en train de transmettre,
C ne va pas pouvoir renvoyer de CTS à A. A contrario, quand B veut envoyer des donnees `
a D,
il nest pas gene que si C a pu envoyer un CTS à A (et D netant à portee que de B, il peut
toujours repondre au RTS de ce dernier). A partir du moment o`
u B arrive à envoyer un CTS, il
devient très difficile pour A dobtenir un CTS permettant de lui envoyer des donnees, do`
u les debits
desequilibres. Du fait des nombreux echecs de transmission que recontre le nud A, sa fenetre de
contention est en general très grande, comme on peut le voir sur la figure 6.8 (avec lalgorithme
de Binary Exponential Backoff, la taille de la fenetre double à chaque echec, jusquà se stabiliser `
a
1031 time slots).
Dans [48], Bensaou et al. proposent une solution que nous avons implantee dans notre version de
NS2. Nous avons ensuite implante la version modifie de cet algorithme decrite precedemment. Les
debits obtenus avec lalgorithme original de Bensaou et al. sont presentes sur la figure 6.9 et ceux
obtenus avec notre version le sont sur la figure 6.11. A partir du moment o`
u le debit demande est
suffisamment important, avec lalgorithme de Bensaou et al., le debit des deux flux est nettement
plus equitable quavec la version non modifiee de 802.11. Par contre, evoluant les deux entre 200
et 300 kbit/s, le debit agrege est bien en dessous du debit maximum autorise par le canal (dans
les meme conditions, un flux ne connaissant aucune contention obtiendrait environ 1.4 Mbit/s).
Lexplication de cette perte de bande passante tient dans les backoff qui sont statistiquement très
longs avec lalgorithme de Bensaou et al. La taille des fenetres de contention sont presentees sur la
figure 6.10, et lon peut voir quelles sont la plupart du temps à leur valeur maximale (1023 time
slots).
77
DANS LES
DEQUIT
E
RESEAUX
AD HOC
debit demande en bits par seconde
2e+06
1.5e+06
1e+06
500000
0
0
8
10
temps en secondes
12
14
16
Fig. 6.6 Debit demande sur chaque flux en fonction du temps
Les debits obtenus avec la modification que nous proposons sont presentes sur la figure 6.11. On
peut voir que lequite entre les deux flux est très bien respectee, et quavec environ 300-350 kbit/s
chacun, les deux emetteurs utilisent plus de bande passante quavec lalgorithme originel de Bensaou
et al . Ceci est confirme par les tailles des fenetres de contention de A et de B qui sont beaucoup
plus equilibree, comme le montre la figure 6.12.
Second sc
enario `
a 2 paires. Nous avons ensuite legèrement modifie le scenario. La configuration
de cette deuxième simulation est celle de la figure 6.13. Le nud A envoie toujours des donnees `
a
C et le nud B en envoie toujours à D. Les debits demandes en fonction du temps sont toujours
ceux de la figure 6.6. Mais cette fois ci, A est à portee de detection de porteuse de D. Les debits
obtenus avec la version normale de 802.11 pour les flux (AC) et (BD) sont presentes sur la
figure 6.14. On remarque une fois de plus une très forte inegalite dans les debits. Les tailles des
fenetres de contention (figure 6.15) montrent bien que nous avons affaire à un problème daccès
au medium et non de collision. En effet, les fenetres de contention des deux emetteurs restent
très basses durant toute la duree de la simulation. La figure 6.16 detaille le phenomène qui se
produit, et qui a pour origine le mecanisme des EIFS. Nous rappelons que les EIFS ont pour but
de proteger les acquittements dans le cas o`
u un mobile a percu de lactivite sur le canal mais na
pas pu comprendre le paquet. Si ce paquet etait un paquet de donnees, alors son destinataire doit
lacquitter. Si le mobile qui a detecte lactivite sans la comprendre emettait tout de suite lorsque le
canal devient libre, alors il pourrait provoquer une collision avec cet acquittement. 802.11 impose
donc aux mobiles dans cette situation dattendre un temps plus long, EIFS, suffisant pour que le
veritable destinataire du paquet envoie son propre acquittement. Dans ce scenario, B comprend
les paquets de A, et peut donc positionner son NAV correctement. Mais il ne peut que detecter
la porteuse sur les acquittements que D renvoie à B. De ce fait, à la fin dun acquittement de D,
A passe en EIFS. Pendant ce temps, B peut tirer un nouveau backoff et le decrementer au moins
en partie. Comme D comprend les CTS et ACK envoyes par C, D ne se trouve donc pas en EIFS
de facon symetrique. Il en resulte une forte inegalite dans laccès au canal, puisque A a de grosses
difficultes à reprendre la main lorsquil la perd.
78
DANS LES
DEQUIT
E
RESEAUX
AD HOC
1.6e+06
A -> C (normal)
B -> D (normal)
A (normal)
B (normal)
1.4e+06
1000
taille de la fenetre de contention
1.2e+06
1e+06
800000
600000
800
600
400
400000
200
200000
0
0
8
10
temps en secondes
12
14
16
8
10
temps en secondes
12
14
16
Fig. 6.7 Debit dans le scenario des deux paires Fig. 6.8 Taille de la fenetre de contention
(802.11 normal)
(802.11 normal)
1.6e+06
A -> C (bensaou)
B -> D (bensaou)
A (bensaou)
B (bensaou)
1.4e+06
1000
1.2e+06
1e+06
800000
600000
800
600
400
400000
200
200000
0
0
8
10
temps en secondes
12
14
16
8
10
temps en secondes
12
14
16
(802.11 Bensaou)
(802.11 Bensaou)
79
DANS LES
DEQUIT
E
RESEAUX
AD HOC
1.6e+06
A -> C (modif.)
B -> D (modif.)
A (modif.)
B (modif.)
1.4e+06
1000
1.2e+06
1e+06
800000
600000
800
600
400
400000
200
200000
0
0
8
10
temps en secondes
12
14
16
8
10
temps en secondes
12
14
16
(802.11 modifie)
(802.11 modifie)
D
B
C
Fig. 6.13 La deuxième configuration à quatre nuds
Nous avons ensuite teste lalgorithme de Bensaou et al (figure 6.17 pour le debit et figure 6.18
pour les fenetres de contention). Sur ces figures, nous pouvons voir que cet algorithme ne donne
pas de bons resultats. Les fenetres de contention restent en quasi permanence au minimum, et par
consequent la situation est presque la meme quavec 802.11 non modifie, cest à dire une très grande
inegalite dans laccès au canal.
Nous avons finalement utilise notre propre algorithme (figure 6.19 pour le debit et figure 6.20
pour les fenetres de contention). Nous voyons sur ces figures que grace à une augmentation contr
olee
des fenetre de contention, on arrive à obtenir des debits equitables et stables.
Conclusion Les resultats obtenus avec la modification que nous avons proposee de lalgorithme
de Bensaou et al. donne des resultats très encourageants. Non seulement il permet une bonne equite
dans des conditions qui tiennent 802.11 en echec, mais il permet aussi une meilleure utilisation de la
bande passante disponible. Notre algorithme a cependant certaines limitations. Pour fonctionner,
80
DANS LES
DEQUIT
E
RESEAUX
AD HOC
1.6e+06
A -> C (normal)
B -> D (normal)
A (normal)
B (normal)
1.4e+06
1000
1.2e+06
1e+06
800000
600000
800
600
400
400000
200
200000
0
0
4
6
temps en secondes
10
4
6
temps en secondes
10
Fig. 6.14 Debit dans le deuxième scenario des Fig. 6.15 Taille de la fenetre de contention
deux paires (802.11 normal)
(802.11 normal)
B
D
RTS
DATA
backoff
CTS
RTS
ACK
C
A
CS
EIFS
CS
EIFS
NAV
Fig. 6.16 Lorigine du problème dans la deuxième configuration à quatre nuds
1.6e+06
A -> C (bensaou)
B -> D (bensaou)
A (bensaou)
B (bensaou)
1.4e+06
1000
1.2e+06
1e+06
800000
600000
800
600
400
400000
200
200000
0
0
4
6
temps en secondes
10
4
6
temps en secondes
10
deux paires (802.11 Bensaou)
(802.11 Bensaou)
81
DANS LES
DEQUIT
E
RESEAUX
AD HOC
1.6e+06
A -> C (modif.)
B -> D (modif.)
A (modif.)
B (modif.)
1.4e+06
1000
1.2e+06
1e+06
800000
600000
800
600
400
400000
200
200000
0
0
4
6
temps en secondes
10
4
6
temps en secondes
10
deux paires (802.11 modifie)
(802.11 modifie)
il a besoin dajouter des informations dans les RTS, qui doivent donc etre utilises (ce nest pas
toujours le cas pour les paquets de donnees envoyes en unicast, et ne lest jamais pour ceux diffuses).
Enfin, il faut noter quil existe toujours des conditions face auxquelles ce type dalgorithme est
impuissant. Cest le cas notamment lorsque les mobiles qui sont en contention ne sont pas en
mesure de communiquer les uns avec les autres, comme par exemple dans le scenario des trois
paires que nous avions etudie precedemment.
82
Deuxi`
eme partie
Exp
erimentations en environnement
r
eel
83
CHAPITRE
7
7.1
Objectifs des mesures

moyens mis en uvre
et
Introduction et objectifs
Les iimplantations de 802.11 sous simulateurs sont en general partielles, et parfois incorrectes.
Une simulation detaillee de la couche MAC peut etre particulièrement co
uteuse et inappropriee
pour des simulations à grande echelle. Et une simulation detaillee de la couche physique serait
inexploitable la plupart du temps car bien trop complexe et donc trop lente (si lon ne considère
pas la mobilite, certaines techniques peuvent neanmoins etre employees [61, 62].
Le travail des concepteurs des simulateurs consiste entre autre à simplifier le code simule tout
en faisant en sorte que son comportement reste suffisamment realiste. Mais cette notion de realisme
varie en fonction de lutilisation. Par exemple la simulation de la diffusion dune video dans un
reseau à points daccès (un flux de paquets re-emis uniquement par les stations de base et o`
u des
pertes sont acceptees) ne sera pas affectee de la meme facon par le manque de detail dans la couche
physique que le fonctionnement dun protocole de routage ad-hoc (o`
u la perte de quelques paquets
peut considerablement alterer la vision de la topologie, et o`
u la perte dun paquet par nud de la
chane de transmission en prive tous les nuds suivants). Par consequent, et particulièrement dans
le contexte des reseaux ad hoc, les resultats obtenus par simulation peuvent etre differents de ceux
obtenus dans la realite. Or très peu dexperiences ont ete realisees en contexte ad hoc. De plus, les
rares experiences menees avaient pour but devaluer differents protocoles de routage et non 802.11.
Comme les cartes 802.11 sont disponibles sur le marche, et que les materiels necessaires etaient
suffisamment abordables, nous avons donc decide de mener des series de mesures. Nous avons ainsi
pu mener une première evaluation de 802.11 en environnent ad hoc reel. Nous avons egalement pu
comparer les mesures reelles aux simulations et nous assurer que les hypothèses faites à partir des
simulations sur le comportement de 802.11 dans un reseau ad hoc etaient correctes.
7.2
Les environnements de mesure
Dans un permier temps, il nous fallait realiser des experiences simples, permettant de verifier
que les cartes se comportaient comme prevu dans des situations standards (mesures de debit sans
interferences exterieures, portee, etc.). Il nous fallait ensuite pouvoir mettre en place des scenarios
representant des utilisations caracteristiques des reseaux ad-hoc (communications multi-saut en
particulier). Et il nous fallait enfin obtenir des traces suffisamment detaillees sur le deroulement
de ces scenarios pour pouvoir conclure sur limpact de 802.11 à lexclusion de tout autre protocole
(TCP/IP en particulier).
84
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN UVRE

Si les simulations sont utilisees très largement dans les travaux sur les reseaux ad hoc, ce nest
pas le cas des mesures en environnement reel. Cela vient du fait quil faut disposer du materiel
(les ordinateurs et les cartes reseau), mais aussi de la main duvre. Autant il est aise pour une
personne seule de developper et de conduire des simulations, autant cela savère difficile dès que
lon cherche à reproduire dans la realite des scenarios ad hoc.
7.2.1
Travaux ant
erieurs bas
es sur des mesures
Malgre la difficulte logistique de telles etudes, leur interet est certain, en particulier en tant que
complement des resultats des simulations. Plusieurs travaux, qui cherchent avant tout à evaluer
des protocoles de routage bien precis, mettent donc en uvre des mesures reelles. Dans [63] et
[64] les auteurs evaluent DSR en utilisant quelques ordinateurs fixes et une demi-douzaine dautres
embarques dans des voitures se deplacant sur le campus. Des recepteurs GPS (Global Positioning
System) sont utilises pour connatre les positions precises de mobiles, et les donnees sont sauvegardees de manière à pouvoir etre rejouees ensuite dans des simulations.
Dans [65], cest ABR qui est evalue dans une configuration de un à trois sauts. Quatre mobiles
sont utilises pour realiser cette experience. Ils sont cependant disposes à des distances maximales
de 50 mètres les uns de autres, les obstacles (batiments, arbres, etc.) empechant le reseau detre
entièrement maille.
ODMRP quant à lui est evalue par des mesures reelles dans [66] grace à sept ordinateurs
organises dans des configurations multi-sauts. Dans certaines des experiences presentees, lun des
ordinateurs se deplace dailleurs au cours de la mesure.
7.2.2
Ad hoc Protocol Evaluation (APE)
APE [67, 68] est un environnement dedie à levaluation des protocoles de routage des reseaux
ad hoc. Il est developpe à luniversite Uppsala en Suède o`
u lidee de le creer avait germe lorsquun
certain nombre detudiants avaient ete equipes dordinateurs portables et de cartes reseau sans fil.
Le materiel et la main duvre disponibles, il etait en effet interessant de les utiliser. APE est fourni
sous la forme dune distribution Linux (RedHat) accompagnee dun certain nombre dutilitaires.
Les Wireless Tools [69] (un ensemble dutilitaires permettant de configurer les cartes reseaux sans
fil et de recolter certaines informations sur leur fonctionnement telles que les niveaux de signal et
de bruit) sont utilises pour configurer le materiel. Les cartes doivent etre en particulier placees
en mode ad hoc (au sens de 802.11), et des adresses IP doivent etre assignees à chaque machine.
Lobjectif principal dAPE etant de permettre les comparaisons entre protocoles de routage, une
douzaine dentre eux sont fournis directement (dont AODV, DSR, TORA, OLSR, TBRPF, etc.).
Afin de pouvoir mener à bien ces comparaisons, la reproductibilite des resultats est un element
capital, aussi APE fournit-il un système permettant de regir par des scripts lensemble des actions.
Après une etape de synchronisation des horloges (une heure de declenchement relative à lheure de
debut de la mesure est associee à chaque evenement, do`
u la necessite dune synchronisation au tout
debut), les scripts controlant le declenchement des differentes sources sont lances. Les personnes
ayant en charge chacune des machines nont pas besoin de connatre les details des scenarios ; des
informations elles aussi scriptees sont affichees pour leur donner les instructions de deplacement au
fur et à mesure.
Une fois une mesure terminee, les donnees sont centralisees sur une machine grace à des utilitaires fournis. Un ensemble de programmes permet alors de traiter ces donnees et den tirer un
85

nombre important de metriques (taux de pertes de paquets, optimalite des routes, ...). Des outils
permettent egalement de generer des graphiques divers. Enfin, la notion de mobilite virtuelle est
definie et peut etre calculee et affichee. Elle est calculee à partir des informations de niveau de signal
issues des Wireless Tools et les transpose en une information de distance percue qui possède une
grande representativite du scenario etudie (les mobiles dont on recoit les paquets avec un niveau
de signal faible sont consideres comme loin).
Bien que virtuellement nimporte quelle application reseau puisse etre utilisee, dans les articles
sur APE dont nous avons connaissance, les donnees envoyees sont des paquets ping ICMP envoyes
à intervalles reguliers. Des flux avec des trafics si reduit sont couramment utilises dans les simulation
destinees à tester les protocoles de routage (comme nous lavons dejà mentionne dans le chapitre 4),
mais ne donne malheureusement pas forcement une bonne idee de ce qui se passe si le reseau est
ensuite charge par une application quelconque.
Il faut noter que APE fournit aussi un utilitaire (mackill) permettant dinstaurer une topologie
virtuelle en forcant certaines machines à ignorer les paquets venants de certaines autres. Ceci est
particulièrement utile pour tester certains comportements des protocoles de routage sans avoir `
a
deplacer tous les mobiles dans la position multi-sauts adequate. Ce mecanisme a une contrepartie
cependant : les effets des interferences (de lenvironnement et des mobiles entre eux) sur les protocoles de routage ne seront pas forcement realistes. Par exemple, il est possible de simuler une
chane de 10 sauts en gardant tous les mobiles dans une seule pièce, mais il ny aura alors aucune
reutilisation spatiale : un seul mobile pourra emettre à un instant donne .
7.3
Description de loutil forwarding
Nous avons vu que les outils disponibles etaient surtout orientes sur levaluation de solutions
complètes (mobiles equipes de cartes radio utilisant des protocoles de routage ad hoc et faisant
fonctionner de vraies applications). Puisque nous voulions isoler les effets de 802.11 de ceux des
autres couches, cela ne correspondaient pas vraiment à nos besoins. Plutot que de chercher `
a
modifier des programmes existants, nous avons prefere developper un nouveau logiciel, qui se voulait
simple et specialement adapte à nos mesures. Les caracteristiques retenues etaient les suivantes :
Un programme simple. Comme nous cherchions à realiser quelque chose de simple, le programme (appele forwarding) a ete ecrit en langage C. Il fonctionne sous linux, et sappuie sur les
wireless tools [69]. Pour des raisons pratiques, le programme a ete installe sur un cdrom bootable
de linux, accompagne des outils necessaires pour sauvegarder temporairement les resultats sur des
partitions aussi bien linux que windows. Il etait ainsi assez aise de realiser nos mesures sur divers
portables, en fonction de ce que lon pouvait emprunter le jour de lexperience (dans certaines
mesures, nous avons utilise jusquà 8 portables simultanement). A la fin de lexperience, les fichiers de resulats (qui pouvaient occuper plusieurs centaines de mega-octets) etaient centralises
sur une machine fixe avant detre depouilles. A noter egalement que la version de linux sur le CD
etait minimaliste, afin deviter des interferences avec des demons ou autres processus utilisant des
ressources.
Le programme lui-meme, une fois lance, presente une simple ligne de commande o`
u lutilisateur
peut à loisir configurer divers paramètres, afficher en temps reels des informations sur les paquets
recus, et surtout demarrer ou arreter des sources de donnees.
86

Pas de protocole de routage. Nos objectifs initiaux etaient entre autres de mesurer les interferences entre nuds voisins lorsque lon realise des communications multi-sauts, et nous comptions pour cela nous appuyer sur les communications en mode diffusion (broadcast) des cartes 802.11.
Lidee etait quau niveau de chaque nud on pourrait ainsi recevoir et garder une trace des paquets
qui ne nous etaient pas reellement destines et qui etaient neanmoins recus avec suffisamment de
puissance. Ceci avait pour but de rendre lanalyse plus facile et plus complète.
Afin de gerer les communications multi-sauts, notre programme avait donc la charge deffectuer
ou non une re-emission des paquets, en fonction de règles etablies prealablement à la mesure. Ces
règles de re-emission (ou de routage statique) avaient comme autre objectif de nous liberer des
effets non desirables que les protocoles de routage normaux pouvaient provoquer dans nos mesures.
Comme nous nous concentrions sur letude de 802.11, les time-out, la selection non controlee des
routes ou les paquets de controle generes par un protocole de routage auraient brouille nos mesures
et rendu les resultas difficilement exploitables.
Ces règles de routages conditionnaient la re-emission des paquets recus en fonction didentifiants
de flux portes par les paquets et / ou des nuds desquels ils nous arrivaient (champ last-hop dans
lentete des paquets).
Des flux UDP `
a d
ebit constant. Là encore, nous voulions nous affranchir au maximum des protocoles superieurs à 802.11 qui auraient pu masquer certains resultats. TCP en particulier presentait
de nombreux problèmes. Dune part il generait du traffic supplementaire dans les deux sens (acquittements et autres paquets de controle), mais en fonction de la taille des fenetres demission et
de larrivee à temps ou non des acquittements, TCP risquait en plus de detecter une congestion du
reseau et dy reagir en modifiant encore la taille de sa fenetre. Il serait alors devenu particulièrement
difficile de savoir si un paquet quelconque avait ete vraiment perdu suite à un problème au niveau
de 802.11 ou si on avait eu affaire à larrivee en retard dun acquittement par exemple. Il aurait ete
egalement très difficile avec seulement quelques machines de mesurer les effets de la saturation de
la bande passante physique (si TCP decide de très fortement reduire la taille de sa fenetre suite `
a
quelques pertes interpretees comme de la congestion, alors le canal radio sera sous-utilise).
Nous avons donc prefere nutiliser quUDP, qui nous permet un bien meilleur controle des
paquets effectivement envoyes dans les air. Sur chaque nud, jusquà 10 sources UDP à debit
constant peuvent etre configurees. Chaque source se voit attribuer un numero de flux unique `
a
lechelle du reseau qui permet didentifier les paquets de manière unique. La taille des paquets
envoyes ainsi que le debit de ces sources sont configurables de manière très precise.
Des fichiers de trace d
etaill
es. Chaque reception de paquet par un nud est consignee dans un
fichier de trace, avec la date locale precise du nud ainsi que des informations diverses (numero de
sequence, nom de lemetteur originel, nom du dernier re-emetteur (last-hop), taille, ...). Un fichier
de trace optionnel peut contenir des informations complementaires sur le niveau de signal pour
chacun de ces paquets. Mais il sagit de linformation retournee par le pilote de la carte 802.11 et
par consequent elle nest mise à jour quà chaque reception de paquet (cela signifie que forwarding
nest pas capable dindiquer le niveau de bruit ambiant en dehors des moment o`
u il recoit des
paquets, entre autres). Une fois les mesures terminees, les differents fichiers de trace sont regroupes
et combines. Ensembles ils permettent de reconstituer lhistorique precis de tout ce qui sest passe
dans le reseau. Les problèmes dhorloge sont geres par forwarding. Des outils de synchronisation lui
sont integres et seront detailles par la suite.
87

Il faut noter que notre programme nutilise pas de mecanisme particulièrement optimise pour
la sauvegarde des informations au fur et à mesure de le lexperience. Dans la pratique, dans les
pires cas un nud navait à ecrire que quelques dizaines de milliers doctets par seconde. Ecrire
directement sur le disque (qui de toute facon dispose de tampons geres par le système et de tampons
internes) etait donc suffisant pour nos besoins. Nous navons pas utilise de mecanisme avance tel
que la sauvergarde dans un disque virtuel en memoire vive, qui aurait de toute facon ete trop petit
par rapport à la quantite de donnees recoltees dans certaines de nos mesures les plus longues.
7.3.1
Architecture du logiciel
Forwarding est un programme multi-threads. Au demarrage du programme un ensemble de

threads est initialise.
Lun deux va servir pour les r
eceptions. Il est en attente constante de paquets venant du
reseau. Lorsquun paquet arrive, il applique des règles de filtrage (en particulier un nud recoit les
paquets quil a lui-meme diffuse et il faut les eliminer), puis il inscrit ce paquet dans son fichier de
trace, avant de le traiter et eventuellement de le re-emettre. Ce thread soccupe aussi de la gestion
de linterface avec lutilisateur (affichage periodique dinformations et lecture des commandes au
clavier et / ou dans des scripts).
Les autres sont utilis
es pour g
en
erer le traffic Le fait dutiliser un thread separe pour
chaque flux evite de mettre en place un système complexe dordonnanceur, mais en contre-partie
une legère latence peut etre introduite à cause de changements de contexte. Heureusement son
impact est negligeable sur des machines comme celles que nous avons utilisees (au minimum des
Pentium II à 300 MHz).
Dans forwarding, le temps est compte en secondes à partir du lancement du programme. Par
exemple, on peut demarrer un flux à la seconde 100 et larreter à la seconde 150. Evidemment,
puisque le programme nest pas lance exactement au meme moment sur chacune des machines, il y
a une certaine desynchronisation. Ce problème est en partie resolu grace à la possibilite de diffuser
un paquet special qui force un changement de la date locale au moment de sa reception. Lidee est
que lorsque quun paquet est diffuse, tous les nuds du voisinage le recoivent au meme moment.
Lenvoi de ce paquet appele SYNC est une chose à faire au debut de chaque mesure (si des paquets
ont ete envoyes avant, il faudra les eliminer des traces car il ne seront pas dans la meme echelle de
temps).
Il faut noter aussi que si le programme a ete originellement concu pour envoyer les paquets
en mode diffusion, il est neanmoins capable de les envoyer en unicast. Cela est en particulier
necessaire lorsque lon veut mesurer limpact des acquittements, des RTS/CTS, ou des debits physiques superieurs à 2Mbit/s (la diffusion est limitee par la norme 802.11 à 2Mbit/s). Les commandes
de creation de source ou de mise en place de règles de repetition prennent une adresse IP en paramètre optionnel. Mais de ce fait il est important quavant la mesure proprement dite tous les
nuds aient ete à portee de communication et que des paquets aient ete echanges (ping rempli très
bien ce role). Cela permet à ARP construire sa table dadresses MAC des cartes des autres nuds
et evite que les requetes ARP soient ensuite melees aux paquets de donnees.
88

0
Type Paquet
Id Source
Id Destination
Id Dernier Emetteur
Num. Seq. Emetteur
Num. Seq. Flux
Numro Flux
Taille des Donnes
Fig. 7.1 Format de len-tete utilisee par forwarding pour tous ses paquets
Nom de loption
-id
-traceFile
-qualityTraceFile
-script
-traceSelfDiscard
Effet
determine lidentifiant unique du nud
specifie le nom du fichier de trace à utiliser
active lenregistrement des informations de niveau de signal et de bruit
demarre automatiquement le script specifie après le lancement du programme
En mode diffusion, les nuds recoivent et eliminent leurs propres paquets.
Cette option permet de memoriser quand meme ces paquets.
Tab. 7.1 Principales options de lancement
7.3.2
Format des paquets
Tous les paquets utilises par forwarding partagent une en-tete commune (voir figure 7.1) o`
u sont
decrits leur type (DATA ou les diverses variantes de paquets de controle ou de synchronisation),
leur source, leur destination, leurs numeros de sequence et leur taille. Cette en-tete a une taille
fixe de 32 octets et il faut noter que les tailles de paquets donnees sur les nombreuses courbes qui
seront presentees plus tard nincluent pas toujours cette en-tete (linclusion ou non de len-tete dans
les valeurs mesurees sera precisee pour chaque courbe). Les nuds sont identifies sous forwarding
grace à un numero unique donne manuellement au lancement du programme. Lors du demarrage
dune source de donnees, un numero de flux est attribue manuellement à cette source et on peut
ainsi retrouver facilement tous ses paquets (pour les paquets de controle, le numero de flux est
arbitrairement fixe à zero). Deux numeros de sequence sont geres : lun est propre au nud et est
incremente `
a chaque fois quil envoie un paquet, quel quen soit le type, lautre est propre à chaque
flux, et nest incremente que lors de lenvoi de paquets appartenant à ce flux. Le champ du dernier
emetteur est evidemment mis à jour à chaque re-emission du paquet.
En plus de leur en-tete, les paquets comportent un champ de donnees (dont la taille est specifiee
dans len-tete). Dans le cas des paquets de controle, ce champ contient une commande ou un resultat
dexecution, dans le cas des paquets de donnees, ce champ est rempli de zeros pour constituer la
charge utile.
7.3.3
Les commandes disponibles
Un certain nombre doptions peuvent etre specifiees au lancement du programme, les plus
importantes sont presentees dans la table 7.1
89

Une fois le programme lance, une ligne de commandes est presentee à lutilisateur. Les principales commandes sont detaillees dans la table 7.2.
Avec forwarding nous avons donc à disposition un outil qui va nous permettre de tester des
scenarios sur des reseaux ad hoc et de mesurer les performances de 802.11 sans etre perturbes par
les protocoles des couches superieures.
90
Nom de la commande
sync [time]
Description
synchronise les horloges sur toutes les machines
à portee.
definit le temps local.
affiche le temps local.
chaque seconde, affiche combien de paquets ont
ete recus, de qui, et à quels flux ils appartiennent.
diffuse un paquet ping auxquels tous les nuds
doivent repondre par une paquet pong.
demarre un flux CBR. Lemetteur, la taille du
paquet, le delai entre deux paquets consecutifs
et le numero de flux doivent etre specifies. Une
adresse IP optionnelle peut etre utilisee pour
forcer lenvoi à un destinataire unique.
arrete un flux CBR specifie par le numero du
nud et le numero du thread source qui le
genère.
les paquets ayant le numero de flux et lidentifiant de dernier nud traverse identiques `
a
ceux specifies seront repetes. Une adresse IP
optionnelle permet de forcer la re-emission vers
une cible unique.
efface une règle etablie grace à la commande
precedente.
execute le script specifie.
execute la commande shell specifiee.
les wireless tools ne remontent les informations de qualite de signal et de bruit que pour
les nuds dont les adresses ont ete specifiees.
setTime time
time
affichePaquetsRecus 0 | 1
pingAll
startCBR numSourceThread flowID idSource
delay packetSize [destinationIP]
stopCBR numSourceThread numNode
addForwardingRule idNode flowID IDLastHop [destinationIP]
deleteForwardingRule idNode flowID IDLastHop

execScript scriptName
execCommand shellCommand
setPhyTraceList adresses IP
Tab. 7.2 Les commandes les plus representatives
91
CHAPITRE
Les premi`
eres mesures
Au fur et à mesure du developpement de forwarding, nous avons realise des mesures ; elles
avaient le triple but de tester le programme, devaluer 802.11 dans un environnement ad hoc reel,
mais aussi de comparer à la realite les simulations que nous avions realisees auparavant avec Network
Simulator.
8.1
Justifications des donn

ees mesur
ees.
Par la suite, nous allons regulièrement presenter des courbes montrant differentes valeurs mesurees au cours de nos experimentations. Il est important de preciser de quelle manière ces valeurs
sont obtenues et, le cas echeant, calculees.
Les d
ebits. Pour un flux donne nous avons vu que les paquets ont toujours la meme taille.
Lorsque nous analysons les fichiers de trace, nous comptons le nombre de paquets par unite de
temps repondant à un meme critère (au moins le numero de flux, mais parfois plus, comme par
exemple le last-hop) et nous multiplions par la taille des paquets.
Les dur
ees de transmission. Nous presenterons parfois des histogrammes decrivant la distribution de la duree de transmission des paquets. Dans la pratique, nous navons pas de moyen de
mesurer directement une telle duree. Nous savons à quel moment lapplication envoie le paquet au
pilote, et nous savons à quel moment le paquet est recu par lautre mobile ; par contre nous ne
savons pas à quel moment la carte 802.11 a reellement emis le paquet (si elle a trouve le canal radio
occupe, elle a pu attendre un certain temps avant quil ne devienne libre pour elle). Pour realiser les
histogrammes que nous presentons, nous nous sommes donc toujours place dans une situation o`
u
une seule source saturait complètement la bande passante, et o`
u aucune interference externe netait
presente. Comme le canal etait complètement sature, il devenait possible de connatre la duree de
transmission en faisant la difference entre les dates de reception de deux paquets consecutifs.
8.2
Le d
ebit en fonction de la taille des paquets
Notre toute première experience consiste à mesurer le debit effectif dans la configuration
presentee sur la figure 8.1, o`
u un emetteur envoie des paquets à un recepteur situe juste `
a cote
de lui.
Les paquets UDP comportent un champ de donnees dune taille comprise entre 82 et 2532
octets, par increment de 50 octets. La figure 8.2 presente les resultats des mesures pour differentes
92
`
CHAPITRE 8. LES PREMIERES
MESURES
800000
11MBit/s avec WEP
11MBit/s sans WEP
5.5MBit/s
2MBits/s
1MBits/s
700000
debit en octets par seconde
600000
500000
400000
300000
200000
100000
0
0
Fig. 8.1 Configuration pour la

mesure du debit en fonction de la
taille des paquets (bande passante
saturee)
500
1000
1500
taille des paquets UDP
2000
2500
3000
Fig. 8.2 Debit utile en fonction de la taille des paquets

UDP
vitesses de transmission, ainsi que lorsque lon utilise le système de cryptographie WEP (Wired
Equivalent Privacy) decrit la norme 802.11. Les observations sont les suivantes :
8.2.1
La fragmentation `
a 1500 octets
La première chose que lon remarque est le phenomène de decrochement lorsque la taille des
paquets depasse les 1500 octets. Ce phenomène est lie à la couche IP qui croit avoir affaire à une carte
Ethernet (802.3) et qui cherche à optimiser la taille des paquets pour eviter une refragmentation
(avec Ethernet, la taille maximale dune trame est de 1500 octets environ, alors quavec 802.11 elle
est de 2432 octets). Ici, cette optimisation est malvenue et fait visiblement chuter le debit.
8.2.2
Limpact du WEP
On remarque en second limpact de lutilisation de la cryptographie WEP. A 11 Mbits/s, pour

des tailles de paquets superieures à 1000 octets environ, les performances deviennent sensiblement
inferieures `
a ce quelles sont si on nutilise pas le WEP (la courbe de debit parat ecretee). Nous
avons realise de nombreuses experiences pour comprendre ce phenomène qui etait tout à fait reproductible mais qui ne concernait que les communications à 11 Mbits/s et pas celles aux debits
inferieurs. La source du problème apparat mieux lorsque lon presente la distribution des durees de
transmission des paquets. La figure 8.3 montre deux histogrammes representant chacun les durees
de transmissions pour une douzaine de milliers de paquets de 900 et de 1400 octets. La taille de
900 octets a ete choisie car daprès la figure 8.2 les flux de paquets de cette taille ne subissent pas
de perte de debit d
u au WEP. La distribution theorique est un rectangle (ce qui est normal etant
donne que la duree de transmission dun paquet dune certaine taille est composee dune partie fixe
et du backoff qui est tire de manière aleatoire et equiprobable entre deux bornes). La distribution
mesuree pour des paquets de 900 octets est proche de la distribution theorique. On peut juste
remarquer un biais du generateur aleatoire qui fait que les paquets ayant des backoffs très courts
93
`
MESURES
700
900 bytes packets
900 bytes packets (theoretical)
1400 bytes packets
1400 bytes packets (theoretical)
600
number of packets
500
400
300
200
100
0
0
0.0005
0.001
0.0015
0.002
0.0025
0.003
0.0035
0.004
0.0045
0.005
0.0055
time elapsed since last packet (in seconds)
Fig. 8.3 Effet du WEP sur la duree de transmission dune trame
sont un peu plus nombreux que la moyenne. A ce sujet on peut noter que des cartes presentant
ce type de biais beneficie dun debit legèrement superieur à celui de carte ayant une distribution
plus equitable (en moyenne elles attendent en petit peu moins longtemps avant denvoyer leurs
donnees). Par contre dans un environnement o`
u toutes les cartes ont ce biais, cela va se traduire
par une hausse du taux de collision. Ceci est une chose à garder à lesprit lorsque lon compare les
performances des cartes de differents constructeurs.
Toujours daprès la figure 8.2, des problèmes apparaissent pour les paquets de plus de 1000
octets et sont le plus importants juste avant que la fragmentation nentre en jeu (vers 1400 octets).
La distribution des durees de transmission des paquets de 1432 octets reflète et permet dexpliquer
ce phenomène. La distribution theorique tout dabord est logiquement decalee vers la droite (duree
de transmission en moyenne plus longue que celles de paquets de 1032 octets), puisque la partie
fixe de la duree de transmission dun paquet depend de sa taille. Mais on remarque tout de suite
deux sous-ensembles dans les durees de transmission effectives. Un certain nombre de paquets
ont ete transmis en un temps conforme aux previsions, mais les paquets du deuxième groupe ont
mis beaucoup plus de temps. De plus letalement du deuxième groupe (double de letalement du
premier) et sa position (deux fois plus loin) indiquent clairement que ces paquets nont etes recus
quaprès une re-emission (le backoff est tire deux fois, do`
u letalement double).
La raison profonde de cette re-emission nous est pour linstant inconnue, le mecanisme du WEP
netant pas sense poser ce genre de problème. Malheureusement le WEP est implante dans le BIOS
des cartes 802.11 et ny ayant pas accès nous navons pas pu pousser plus loin nos investigations.
Peut-etre ce problème se pose-t-il lorsque que le processeur embarque sur la carte arrive à ses limites
(cryptage/decryptage de gros paquets au debit maximum supporte). Quoi quil en soit, dans la suite
de nos experimentations nous avons decide de ne plus utiliser le WEP.
94
`
MESURES
7e+06
11 MBit/s avec WEP mesure

11 MBit/s sans WEP mesure
11 Mbit/s theorie
5.5 MBit/s
5.5 Mbit/s theorie
2 MBits/s
2 Mbit/s theorie
6e+06
Debit en bits par seconde
5e+06
4e+06
3e+06
2e+06
1e+06
0
0
500
1000
1500
2000
Taille des paquets UDP
2500
3000
3500
Fig. 8.4 Comparaison des debits theoriques et mesures à differentes vitesses et en fonction de la
taille des paquets.
Remarquons que si sur la figure 8.2 leffet negatif du WEP à 11 Mbit/s parat moins sensible
pour les paquets de plus de 1500 octets que pour ceux de 1500 octets ou un peu moins, cela est
simplement du au fait que ces paquets UDP de plus de 1500 octets sont divises en un gros paquet
qui subit leffet et dun autre plus petit qui ne le subit pas.
Enfin, mais cela sera juste mentionne car en dehors du cadre de ce travail, il faut noter que le
niveau de securite du WEP est en realite assez faible.
8.2.3
Hormis les probl`

emes pr
e-cit
es, des d
ebits tr`
es proches de la th
eorie
Les debits mesures sont donc extremement proches des debits calcules par la theorie, comme on
peut le voir sur la figure 8.4. Mais on peut cependant noter que les debits utiles sont très eloignes
des debits physiques. Cela est specialement flagrant lorsque lon utilise des paquets de petite taille
(le debit utile avec des paquets de 82 octets et plus de 7 fois inferieur au debit utile avec des paquets
de 1432 octets) ou que la fragmentation à 1500 octets force la division de gros paquets en un paquet
de 1500 et en un autre plus petit (le debit diminue de 50% environ lorsque la taille passe de 1450
à 1500 octets)
95
`
MESURES
8.3
8.3.1
Partage du canal entre nuds `

a port
ee de communication
Deux flux (combinaisons d
emetteurs et r
ecepteurs)
Après nous etre interesses à la capacite du canal lorsquil ny a quun seul emetteur, nous nous
sommes ensuite tournes vers des scenarios o`
u plusieurs emetteurs proches les uns des autres sont
en contention pour laccès au medium.
Nous avons tout dabord utilise quatre mobiles situes dans la meme pièce (et donc à portee de
communication directe), et nous avons realise les diverses combinaisons de flux presentees sur la
figure 8.5. Les flux de donnees etaient constitues de paquets UDP de 1000 octets, envoyes aussi vite
que possible. Les cartes etaient configurees pour fonctionner à 11 Mbit/s sans utiliser de RTS/CTS.
Les resultats de cette experience sont presentes sur la figure 8.6 et peuvent etre interpretes de
la facon suivante (lordre nest pas chronologique, mais presente les situations les plus simples en
premier) :
secondes 175 `
a 195 : Il ny a quun seul flux (de 3 vers 2), et donc aucune contention. On
obtient le debit maximum observe dans les experiences precedentes dans les memes conditions,
soit un petit peu plus de 600 paquets de 1000 octets par seconde.
secondes 120 `
a 125 et 150 `
a 165 : Il ny a quun seul flux (de 1 vers 2 cette fois-ci). On
obtient là encore le debit maximum.
secondes 100 `
a 120 et 125 `
a 150 : Il y a deux flux en contention. On observe la meme
chose que les recepteurs soient deux nuds differents ou non. On remarque immediatement
une difference de debit entre les deux flux (lemetteur 1 accède un peu moins souvent au canal
que lemetteur 2). Les cartes 802.11 utilisees etaient à priori les memes, et ce phenomène peut
probablement etre impute soit à lheterogeneite de nos machines, soit à des differences non
documentees entre nos cartes (de meme marque et de meme modèle). Il est important de
remarquer que la somme des deux flux simultanes est legèrement superieure au debit obtenu
par un flux unique isole. Ce phenomène sexplique par la decrementation en parallèle des
backoffs sur chacun des emetteurs. En effet, lorsque dans ce scenario le canal devient initialement libre, les deux stations choisissent un backoff aleatoire et commencent à le decrementer.
Dès que lune delles a termine, elle emet et bloque la decrementation de lautre station.
Mais quand le canal redevriendra libre, lautre station reprendra la decrementation là o`
u elle
setait arretee (au lieu de tirer un nouveau backoff), et statistiquement finira donc rapidement
sa propre decrementation. Finalement, on observe une diminution de la duree moyenne du
temps dinactivite separant deux trames (de sources differentes) sur le canal, et donc une
augmentation du debit.
8.3.2
Flux multiples
Dans ce scenario, nous avons observe lactivite sur le canal radio alors quun nombre croissant
de flux etaient en contention pour y acceder. Comme precedemment, les mesures ont ete effectuees
avec des paquets UDP, les RTS/CTS netaient pas utilises et le debit nominal etait de 11 Mbit/s.
Lexperience est divisee en 7 phases (voir figure 8.7, o`
u à chaque etape un flux supplementaire est
active), et o`
u chaque phase est elle-meme divisee en 5 periodes de 20 secondes o`
u les flux sont
constitues de paquets dune taille donnee (200, 500, 1000, 1400 et 2000 octets, dans cet ordre).
La figure 8.8 presente les debits agreges en paquets par seconde (cest à dire la somme des debits
des differents flux). Comme on pouvait sy attendre, on voit bien que pour une etape donnee, plus
96
`
MESURES
700
number of packets received per second
600
2
3
1 > 2
3 > 2
3 > 2
3 > 4
120
125
150
165
175
500
400
300
200
195
time in seconds
flow 1 -> 2
flow 3 -> 4
flow 3 -> 2
flow 3 -> 2
100
Fig. 8.5 Deux paires à portee de

communication
0
100
120
140
160
180
200
time in seconds
Fig. 8.6 Debit quand deux paires sont à portee de

communication
1400
1200
201
2
301
3
401
501 601
701
throughput in packets received per second
801
7
201
301
401
501
601
701
801
1000
800
600
400
200
time
0
1 flow
Fig. 8.7 Un à sept flux simultanes
2 flows
3 flows
4 flows
5 flows
number of simultaneous flows
6 flows
7 flows
Fig. 8.8 Debits cumules pour un à sept flux se partageant le canal
97
`
MESURES
2000
1800
1600
number of packets
1400
1200
1000
800
600
400
200
0
0
0.0005
0.001
0.0015
0.002
0.0025
0.003
time elapsed between 2 consecutives packets
0.0035
0.004
Fig. 8.9 Distribution des temps de transmission des paquets de 1000 octets lorsque 7 emetteurs
sont en contention
les paquets sont petits, plus ils sont nombreux à etre envoyes au cours dune seconde. Mais on
remarque aussi que lorsque le nombre demetteurs en contention augmente, le debit total augmente
lui aussi legèrement. Ceci est du au phenomène detaille dans lexperience precedente. Lorsque le
canal devient libre, tous les nuds ont des paquets à envoyer, et decrementent donc leur backoff
en parallèle. Plus il y a de flux en concurrence, plus les chances sont grandes que lun deux ait un
backoff restant court, et donc que le canal soit rapidement reoccupe. Leffet est plus visibles avec
des paquets de petites tailles, puisquon en envoie plus par seconde et que lon gagne ainsi du debit
sur chacun de leurs backoffs. Evidemment, ce phenomène est progressivement contrebalance par les
collisions. Plus il y a de flux en contention, plus les chances sont grande que deux nuds aient fini
en meme temps de decrementer leurs backoffs et emettent en meme temps. A partir de cinq flux en
contention, le debit global naugmente donc plus.
La figure 8.9 presente la distribution du temps separant deux paquets consecutifs de 1000
octets lorsque 7 emetteurs sont en contention. Contrairement à ce que lon avait pu observer dans
la figure 8.3 o`
u il ny avait quun seul flux et o`
u la distribution etait assez homogène, ici on voit un
regroupement des ecarts vers les valeurs les plus basses (la duree minimale de transmission de nos
paquets, lorsque le backoff tire est nul, est de 1300 s environ, et dun peu plus de 1900s lorsque
quil est maximal et quil ny a pas eu de collision avant). Ceci est tout à fait en adequation avec
nos remarques precedents sur laugmentation du debit lorsque le nombre de flux augmente.
En sus du pic principal, on remarque quun certain nombre de paquets on ete transmis en un
temps environ double par rapport à la majorite (pic vers 2.5 ms). Ces paquets sont en fait ceux qui
ont subi une collision et qui ont du etre reemis. Dans ce graphique, dans 93.25% des cas, le temps
separant deux paquets consecutifs etait de moins de 2000 s. Cela signifie que le taux de collision
etait finalement assez faible malgre la presence de 7 emetteurs (6.75% seulement des paquets ont
eu besoin dune reemission).
8.4
Les mesures de port

ee
Letape suivante dans lanalyse du comportement de 802.11 dans le contexte des reseaux ad-hoc
est letude de la portee de communication reelle. Nos objectifs à plus long terme etaient evidemment
98
`
MESURES
de realiser des mesures dans des configurations typiquement ad-hoc telles quune chane, et la portee
de communication est une donnee dont nous avons besoin pour preparer ces futures mesures.
Nous avons vu dans le chapitre qui leur est dedie que les simulateurs considèrent en general
que les zones de communication sont circulaires et centrees sur le mobile (avec des variantes, telle
que le modèle shadowing qui ajoute une probabilite de perte des paquets sur le bord de ce cercle).
Les experiences decrites dans ce chapitre avaient pour but de comparer la realite avec ces resultats
theories.
8.4.1
Lenvironnement et le outils de mesure
Le mat
eriel utilis
e. Comme dans les autres experiences, nous utilisons forwarding sur des portables PC demarres avec notre CD de linux. Dès ces premières experiences en exterieur, il est
important de noter que le materiel joue un grand role. La longevite des batteries en particulier est
largement affectee par la temperature, et il faut en tenir compte lors de la conception des scenarios
de mesure et des scripts de commandes. Les cartes radio utilisees sont des cartes Orinoco ou WaveLan de Lucent Technologies, elles emettent avec une puissance de 15 dBm et utilisent leurs antennes
integrees.
Lenvironnement. Lenvironnement nest jamais neutre ; comme ces mesures de portee sont
preparatoires pour des mesures sur des configurations veritablement ad hoc, nous avons choisi de
les effectuer en exterieur, dans un environnement suffisamment degage. Nous avions en effet effectue
des mesures prealables en interieur, et il etait rapidement apparu quil etait impossible dy mettre
en place une configuration avec une chane dune longueur superieure à deux sauts (notre batiment
est trop petit, et il est impossible de placer des mobiles de telle sorte quils ne puissent communiquer
quavec leurs voisins directs. Quoique nous fassions, chaque mobile peut atteindre nimporte quel
autre en deux sauts maximum).
Lendroit retenu pour nos experiences est une piste cyclable le long dun boulevard proche du
campus (voir la figure 8.10 pour la disposition et la figure 8.11 pour la photographie). Le principal
avantage de ce lieu est la ligne de vue directe (environ 1km en ligne droite), avec une certaine
homogeneite dans lenvironnement (borde dun cote par une route, de lautre par un parc que lon
surplombe de quelques mètres). Le muret nous fournit le support pour poser nos portables.
8.4.2
Les r
esultats
Afin devaluer la portee de communication de nos cartes, nous utilisons deux portables initialement très proches lun de lautre et que lon eloigne par etapes successives. La vitesse de
transmission physique est de 11Mbit/s. A chaque etape, le mobile emetteur envoie à lautre des
rafales consecutives de paquets de differentes tailles (200, 500, 1000 et 1400 octets) et qui durent
chacune une vingtaine de secondes. Lorientation des machine a un impact tout à fait remarquable
sur les resultats, et nous repetons donc nos mesures dans diverses positions. Les debits obtenus en
fonction de la distance, de la taille des paquets et de lorientation des cartes sont presentes sur la
figure 8.12. Plusieurs remarques importantes peuvent etres faites :
En fonction de lorientation des cartes, la portee de communication varie grandement (dun
facteur superieur à 2 entre la position la plus et la moins favorable). Cartes emettrices et
receptrices dos à dos, le debit utile est dejà grandement affecte à une distance de 45 mèttres,
99
`
MESURES
route
terre-plein central
route
piste
muret
parc (en contre-bas)
Fig. 8.10 Lenvironnement pour les mesures de

portee
Fig. 8.11 Lenvironnement pour les mesures
de portee
alors que face à face il ne commence à baisser quà partir de 75 mètres et que les communications restent possibles jusquà 150 mètres environ. Sur les figures 8.14 et 8.15 sont indiques
les niveau de signal et de bruit mesures pour chacun des paquets correctement recus. On remarque laffaiblissement de la puissance du signal (de lordre de 10dBm en moyenne) lorsque
les antennes sont dos à dos (figure 8.14) plutot que face à face (figure 8.15). Il faut noter
aussi que lorientation de la carte receptrice est tout aussi importante que celle de la carte
qui emet, comme on peut le voir avec les differences entre les mesures dans les positions 1 et
2 de la figure 8.12.
A part à courte distance o`
u lon obtient bien celui prevu, une grande instabilite dans le debit
utile apparat. A une distance fixee (par exemple 90 mètres dans le cas des cartes face à face),
le debit varie grandement en fonction du temps. Lenvironnement reel est loin detre stable
comme le predisent les modèles simples de propagation dans les simulateurs. Là encore, cette
instabilite est confirmee par les niveaux de signal et de bruit mesures (figures 8.14 et 8.15)
qui varient dans une plage de 10 dBm à une distance fixee.
Pour chacune des distances, les mesures ont ete effectuees avec 4 tailles de paquets differentes.
On aurait pu penser que les gros paquets seraient plus affectes que les petits par la qualite
du lien radio car ils durent plus longtemps et auraient ainsi plus de chances de subir des
interferences. La figure 8.13 presente les memes donnees que la figure 8.12, mais avec un
lissage (en ordonnee, on peut lire le nombre de paquets recus par intervalle de 4 secondes
au lieu dune seconde). A courte distance (15 à 60 mètres), on remarque que les debits en
paquets par seconde diminuent avec la taille des paquets de manière previsible. Mais plus loin
(par exemple 90 ou 135 mètres), on se rend compte quil ny a pas forcement de relation entre
la taille des paquets et le taux de perte. Ceci est important. On savait que les gros paquets
permettaient dobtenir un debit utile superieur à courte distance, mais il apparat aussi quils
ne sont pas penalisants quand la distance augmente et que les interferences deviennent sevères.
Toujours sur la figure 8.12, on peut remarquer que le taux dechec dans la reception reste
parfois stable pendant certaines periodes. Par exemple à 75 mètres dans la 5ème position,
il semble quau milieu de la phase denvoi des paquets de 200 octets les interferences soient
subitement devenues plus fortes. Une observation attentive des resultats montre que ce type
de phenomène se produit à differentes echelles (parfois ce sont quelques paquets consecutifs
100
Position 5
600
400
200
0
dbit en paquets reus par seconde
Position 4
800
1000
900
800
700
600
500
400
300
200
100
0
Position 3
paquets de 200 octets

1000
1000
900
800
700
600
500
400
300
200
100
0
Position 2
1200
1000
900
800
700
600
500
400
300
200
100
0
Position 1
`
MESURES
1000
900
800
700
600
500
400
300
200
100
0
15m
30m
45m
60m
75m
90m
distance en metres
105m
120m
135m
150m

15m
30m
45m
distance en metres
60m
75m

15m
30m
45m
60m
75m
90m
distance en metres
105m
120m
135m
150m

15m
30m
45m
60m
distance en metres
75m
90m
105m

15m
30m
45m
60m
distance en metres
75m
90m
105m
Fig. 8.12 Debits mesures en fonction de la distance, de la taille des paquets et de lorientation
des antennes (vitesse demission de 11 Mbit/s)
qui sont perdus, parfois plusieurs dizaines voire centaines). Ce type de comportement ou les
erreurs de transmission arrivent par rafale est different de ce que lon peut observer avec les
modèles classiques de propagation dans les simulateurs. Au mieux, le modèle shadowing va
produire par exemple un taux de perte non nul mais stable à une distance donnee.
La figure 8.16 presente quand à elle les debits mesures lorsque la vitesse demission est forcee
à 2 Mbit/s. La tendance generale en fonction de lorientation des cartes est sans surprise assez
semblable à ce que lon avait observe à 11 Mbit/s. Lorsque les cartes sont face à face (position 3),
elles peuvent communiquer jusquà une distance nettement plus grande que lorsquelles sont dos `
a
dos (position 2), et la position 6 permet une portee intermediaire. Mais si la tendance en fonction
de lorientation est semblable, ce nest pas le cas de la portee qui est logiquement beaucoup plus
grande. Cette fois-ci, des paquets peuvent etre recus jusquà 300 mètres environ si lorientation est
101
`
MESURES
Fig. 8.13 Debits lisses pour la position 3 et en fonction de la distance
Fig. 8.15 niveaux de signal et de bruit pour

la position 3
Fig. 8.14 Niveaux de signal et de bruit pour

la position 2
102
`
MESURES
Position 2
Position 3
Position 6
Fig. 8.16 Debits mesures en fonction de la distance, de la taille des paquets et de lorientation
des antennes (vitesse demission de 2 Mbit/s)
favorable (position 3). On peut noter egalement que la portee reelle reste quand meme en general
très nettement inferieure à celle prevue par la simulation. Rappelons que pour un debit physique de
2 Mbit/s, le modèle freespace de NS2 prevoyait une portee de 600 mètres sans degradation, que le
modèle shadowing prevoyait de ne pas avoir de degradation avant 250 mètres et ensuite des pertes
de plus en plus importantes jusquà 700 mètres, et quenfin le modèle two-ray ground prevoyait que
jusquà 250 mètres on pourrait avoir le debit maximum et plus rien au-delà.
Tout comme on avait pu le voir à 11 Mbit/s, on observe enfin une certaine instabilite à partir
dune certaine distance (au-delà de 200 mètres pour la position 3, au-delà de 100 mètres pour la
position 6).
103
CHAPITRE
Les outils danalyse avanc

ee
Nous avons vu precedemment quun chronogramme pouvait etre un bon outil pour analyser
finement ce qui se passe, en particulier dans un reseau ad hoc. Nous cherchons donc à reproduire
le meme type de graphique que ceux obtenus pour les simulations sous Network Simulator.
Cependant, alors que NS dispose dune horloge globale et commune à tous les mobiles simules,
des problèmes se posent lorsque lon passe à lexperimentation en environnement reel. Les horloges
des differents portables ne sont pas synchronisees, et quelques experimentations nous montrent
quelles derivent les unes par rapport aux autres dune manière que lon ne peut negliger.
Afin de produire des chronogrammes utilisables, il nous est donc indispensable de comprendre,
quantifier et corriger ces problèmes.
9.1
Les chronogrammes en environnement r

eel
Les modifications que nous avons apportees à NS nous permettaient de recuperer directement
toutes les informations dont nous avions besoin pour tracer les chronogrammes. Par exemple, nous
avions les dates de debut et de fin demission physique, les debuts, pauses, reprises, fins de backoffs,
les DIFS, etc. En environnement reel, nous ne disposons que de la date de reception des paquets et
de leur taille. Cependant, comme nous pouvons deduire la duree dun paquet à partir de sa taille
et de la vitesse demission, il reste possible de construire un chronogramme utile bien quun peu
moins complet. Certaines precautions doivent etre prises cependant, comme par exemple lorsque les
paquets sont envoyes en unicast et quil faut prendre en compte les acquittements qui napparaissent
pas dans les traces.
9.2
Le probl`
eme de la synchronisation
Dans forwarding, un mecanisme simple de synchronisation a ete integre très tot. Il tire parti
dune propriete des reseaux radio : tous les mobiles qui recoivent un paquet diffuse savent quils le
recoivent à la meme date (il ny a pas de re-emission, les delais de propagation des ondes sont tout
à fait negligeables dans ce contexte et le paquet envoye par forwarding contient sa date demission,
ce qui permet dajuster les horloges des mobiles le recevant de facon à ce quelles soient toutes
synchronisees). Si ce mecanisme est suffisamment precis pour les mesures de debit, il ne lest plus
lorsque lon veut construire un chronogramme permettant de comparer precisement les dates de
receptions des paquets sur plusieurs mobiles (les debits sont en general exprimes en octets par
seconde, des decalages de lordre du dixième de seconde ne sont pas vraiment genants dans ce
contexte).
104

CHAPITRE 9. LES OUTILS DANALYSE AVANCEE
Fig. 9.1 Position des portables pour la mesure de la

desynchronisation
Fig. 9.2 Derive des horloges en secondes (ordonnee)

pour environ 14h30 (abscisse)
En effet, les horloges des portables navancent pas exactement à la meme vitesse. Nous avons
pu le verifier en utilisant trois machines placees dans la configuration presentee sur la figure 9.1.
On commence lexperience par lenvoi dun message de synchronisation de forwarding, qui assure
quà sa reception les dates sur chacune des machines sont identiques. Puis lemetteur se met `
a
diffuser des paquets de 1000 octets de donnees à une cadence regulière. A la reception de ces
paquets (numerotes), chaque recepteur lestampille avec sa date locale. Nous soustrayons ensuite,
pour chaque paquet, sa date de reception sur lun des mobiles à sa date de reception sur lautre.
Idealement, la difference devrait etre nulle à chaque fois. Les paquets sont envoyes au rythme de
10 par seconde et la mesure a dure environ 14h30 (soit un peu plus de 520000 paquets). Comme
on peut le voir sur la figure 9.2, la difference est loin detre nulle puisquau bout de 14h30, les deux
recepteurs sont desynchronises de 6.5 secondes.
On remarque immediatement lapparente linearite de cette courbe, mais egalement la presence
de decalages ponctuels plus et plus ou moins frequents. Ces decalages apparaissent quand, sur lun
des recepteurs, le processeur est occupe et le paquet est stocke quelques instants dans une memoire
tampon avant detre traite et estampille. Comme le paquet est estampille en retard, il semble
etre recu à une date très differente vis-à-vis de lautre recepteur. De tels ecarts sont genants pour
les calculs, mais heureusement forts rares (quelques dizaines pour plus de 500000 paquets envoyes)
et peuvent donc etre elimines avec un système de seuil. Si lecart entre deux paquets consecutifs
est trop grand, on elimine le paquet ; on obtient ainsi la figure 9.3.
6.5 secondes de decalage en 14h30, cela correspond à environ 7.5 ms de decalage par minute.
La duree de transmission dun paquet de 1000 octets à 2 Mbit/s est dun peu plus de 4 ms ; on se
rend bien compte que cette derive est trop importante pour etre ignoree lors de la creation de nos
chronogrammes et quil va falloir la corriger. La figure 9.4 montre le chronogramme representant
les receptions des paquets diffuses tous les 1/10 de seconde lorsquaucune correction de la derive
105

Fig. 9.3 Derive filtree des horloges en secondes (ordonnee) pour environ 14h30 (abscisse)
Fig. 9.4 Chronogramme de deux mobiles recevant des paquets diffuses lorsque la derive des
horloges nest pas corrigee
106

Fig. 9.5 Les strates et la redondance dans le système NTP
nest appliquee ; le problème y est flagrant, les paquets devraient etre recus exactement en meme
temps.
9.3
9.3.1
R
esolution du probl`
eme de la synchronisation
Les diff
erentes approches, les syst`
emes existants
La synchronisation des horloges est un problème important que lon retrouve dans de nombreux
domaine, non seulement les reseaux, mais aussi les systèmes distribues ou les systèmes temps reels.
La synchronisation permet aux composants de maintenir leurs dates système suffisamment proches.
Sa precision depend des algorithmes utilises, mais aussi de la topologie ou de la structure du reseau,
des liens de communication, de la charge des machines, etc. Il existe de nombreuses methodes qui
sont proposees à chaque fois pour des domaines dapplication bien specifiques.
NTP (Network Time Protocol) [70] Cest un protocole très connu dans la synchronisation des
horloges de machines reliees à lInternet. NTP permet de synchroniser lhorloge dun ordinateur avec
celle dun serveur de reference. Le protocole est organise de facon arborescente. La synchronisation
se fait donc couche par couche, ou strate (voir figure 9.5). On distingue 16 niveaux de couches, le
16ème niveau correspondant à une horloge non synchronisee. Dans la pratique on ne depasse guère
la couche 5.
Les serveurs de niveau 1 se synchronisent sur une source de reference (horloge, recepteur de
temps code, recepteur GPS). Ces recepteurs decodant les signaux radio de transmission de lheure
par les sites officiels. Les serveurs de strate 2 se synchronisent sur les serveurs de strate 1, et suivant
les configurations, entre eux. Les serveurs des strates 1 et 2 sont officiels et declares (exemples pour la
strate 2 : ntp.univ-lyon1.fr, bernina.ethz.ch, biofiz.mf.uni-lj.si, ntp0.strath.ac.uk, ntp1.strath.ac.uk).
Les serveurs de strate 3 se synchronisent sur ceux de strate inferieure. Ils nont pas à etre declares ;
tout site peut installer un serveur de strate 3, à la condition de prevenir les administrateurs des sites
de strate inferieure officiels. Les serveurs de strate 4 sont en general, à lusage dun reseau local.
Et ainsi de suite pour les couches suivantes, jusquaux clients terminaux. Notons que les simples
clients ne sont pas autorises avant la strate 3.
Comme il lest mentionne dans [71], dans les reseaux sans fil de capteurs lutilisation de NTP
savère difficile. Il faut un serveur de reference que toutes les machines puissent atteindre. Un reseau
ad hoc peut etre partitionne pendant des periodes plus ou moins longues, ce qui pose problème. De
meme, la precision que lon peut esperer de NTP dans le cadre dun reseau 802.11 est en-dessous
de nos besoin, du fait de lincertitude sur la duree de transmission dun paquet (backoff aleatoire,
107

collisions, pertes de paquets, re-emissions par la couche MAC). Une solution à notre problème
aurait ete dinstaller un reseau filaire entre les machines de notre banc de test et de sen servir
pour synchroniser les horloges avec NTP. On aurait ainsi pu obtenir une precision de lordre de la
milliseconde qui aurait ete acceptable pour notre usage ; mais ce netait techniquement pas possible
pour les experiences en exterieur et sur des distances un peu grandes.
Des m
ethodes g
en
eralistes Certains travaux (comme par exemple [72]) ont essaye de faire une
synthèse sur les recherches dans le domaine de la synchronisation des horloges. Les auteurs ont
classifie les algorithmes de synchronisation en faisant une evaluation sur leur type (deterministe,
statistique, probabiliste), de leur capacite à resister aux pannes (panne de processeur, dhorloge,
de lien ou de transmission, ...), de la procedure de synchronisation (qui peut etre symetrique -tous
les ordinateurs jouant le meme role - ou asymetrique - avec des serveurs par exemple). Les auteurs
divisent la synchronisation en trois etapes :
Determiner quand il faut synchroniser.
Estimer les valeurs des horloges distantes.
Corriger lhorloge locale après avoir estime les horloges distantes.
Ces trois etapes sont assurees par trois blocs differents et les algorithmes sont egalement
classifies en fonction des techniques utilisees dans chacun de ces blocs.
Neanmoins, ces travaux ne restent quau niveau de la presentation et de la classification des
algorithmes et ne specifient pas leur domaines dutilisation. Les performances de ces algorithmes
(precision de la synchronisation et nombre de messages à envoyer) dependent de facteurs comme
la derive maximale des horloges, le temps de transmission et la gigue des paquets, etc. De plus, ces
techniques ont des contraintes qui ne sont pas forcement compatibles avec notre contexte dutilisation (par exemple elles peuvent necessiter une connectivite complète du reseau, la presence dun
système de distribution de temps (GPS), ...). Par consequent, ladaptation de ces techniques dans
notre contexte bien specifique aurait ete pour le moins hasardeuse et les resultats non garantis.
Synchronisation dans les r
eseaux de capteurs Le domaine des reseaux de capteurs [73]
a toujours connu des problèmes de synchronisation. Les applications deployees sur ces reseaux
impliquent souvent la fusion de donnees qui necessite une synchronisation. Le protocole RBS (Reference Broadcast Synchronization), decrit dans [71], peut atteindre une precision de 1 s dans une
zone à un saut (tout les capteurs peuvent communiquer avec tous les autres). Son extension aux
reseaux multi-sauts se fait au prix dune degradation de la precision qui reste neanmoins de lordre
de la micro-seconde. Dans le contexte multi-sauts, RBS necessite de maintenir une structure de
routage entre les zones de diffusion. Dans le cadre de notre travail, cela impliquerait dintroduire
un protocole de routage ce qui viendrait perturber les mesures fines de 802.11 realisees dans les
scenarios.
Une synchronisation post facto est proposee dans [74] : une synchronisation est realisee juste
après une communication. Le but est deviter une consommation denergie inutile pour une synchronisation permanente mais non necessaire. Neanmoins, cette synchronisation peut aussi avoir
un impact sur les mesures que nous voulons realiser puisque chaque communication serait separee
par une synchronisation.
108

Une m
ethode sp
ecifique Lauteur de [75] a presente une solution pour la synchronisation des
horloges dans le domaine des reseaux ad hoc. Cette solution suppose que la derivee de la date
locale dune horloge C(t) en fonction du temps absolu est bornee :
1 C/t 1 +
Ces inegalites conduisent à une relation entre la date locale dune machine et le temps absolu,
et vice-versa. Grace à cette propriete et en representant la date locale par un intervalle de temps,
les auteurs ont pu definir une loi permettant de transformer la date locale dun machine en la date
locale dune autre machine (toujours sous forme dintervalle de temps) après une transmission et
en tenant compte de sa duree. Cette technique permet devaluer dans certains cas lordre des dates
locales [t1 , t2 ] < [t3 , t4 ] ou devaluer combien de temps sest ecoule entre les evenements [t1 , t2 ] et
[t3 , t4 ]. Cependant, il reste toujours de cas o`
u lon ne connat pas lordre des evenements (quand
les intervalles se chevauchent).
La precision de cette methode de synchronisation depend du delai de transmission ainsi que du
nombre de sauts que la date locale à synchroniser doit traverser. Cela presente une limite lorsque
lon veut obtenir une precision de lordre du dixième de milliseconde dans un reseau multi-sauts
base sur 802.11b, o`
u le delai de transmission nest pas garanti (presence de backoff aleatoires) et o`
u
le nombre de sauts peut etre important. De plus, si le reseau est charge au moment de lechange des
paquets de synchronisation, alors les delais de transmission pourront etre très fortement affectes
(retards pouvant depasser les dizaine de millisecondes), et la precision de la synchronisation sera
trop faible.
9.3.2
Premi`
eres constatations et m
ethode simple
Sur la figure 9.3, on constate que la derive des horloges semble linaire. Nous avons effectue
dautres mesures, et si lampleur de la derive varie (en fonction de lanciennete des machines en
particulier elle evolue entre 0.3 et 7.5 ms par minute), nous observons toujours des courbes quasiment lineaires. Rappelons que nous ne sommes pas specialement interesses par un algorithme de
synchronisation en temps reel des horloges. Nous voulons surtout pouvoir mener une analyse postmortem des resultats, et donc une synchronisation a posteriori (ou encore recalage de fichiers de
trace) est tout à fait acceptable. Notre première approche consiste donc à considerer que la derive
entre deux horloges est approximable par une droite. Ainsi il est possible de choisir une horloge
comme reference absolue, et de corriger grace à des coefficients lineaires les horloges de toutes les
autres machines pour les ramener dans le meme temps. Il suffit de calculer une fois pour chaque
machine le coefficient avec lequel elle derive par rapport à la reference, puis dappliquer ce coefficient
à chaque resultat de mesure.
Par exemple, on peut considèrer lhorloge A dun mobile qui derive de facon lineaire de 7 ms
par minute par rapport à lhorloge B dun autre mobile choisie comme reference. La pente de la
droite sur la figure 9.6 est de 7.103 /60 en fonction de tA. Une date tAE dun evenement E fournie
par lhorloge A pourra etre ramenee à la valeur
tBE = tAE (1 7.103 /60)
(9.1)
qui est la date de E dans le temps de reference.

Dans un but devaluation, nous avons applique cette methode sur les donnees obtenues
precedemment afin dajuster les dates de reception des paquets diffuses. Le coefficient dajuste-
109

tA - t
t=0
tA
temps local
Fig. 9.6 Un coefficient lineaire pour passer du temps local ou temps de reference
ment est calcule de la manière suivante : après filtrage des paquets ayant ete recus avec un temps
les separant de leur predecesseur secartant trop de la moyenne, nous prenons un point en debut
de courbe, un autre en fin de courbe, et nous calculons le coefficient directeur de la droite passant
par ces deux points.
Une fois le coefficient calcule et applique, nous avons analyse lerreur de synchronisation
residuelle. Lerreur maximale etait de lordre de 3.5 ms, avec une erreur moyenne proche de 2.4 ms.
Un distribution de lerreur pour plus de 520000 paquets est presentee sur la figure 9.7. Cet histogramme montre que lecart de synchronisation, bien quenormement reduit, reste non negligeable
(beaucoup de paquets ont une erreur depassant les 2 ms, à mettre en rapport avec les seulement
4 ms qui dure la transmission dun paquet). De plus, les paquets presentant les erreurs les plus
importantes sont le plus nombreux. La methode de lapproximation par une droite est très simple,
mais ne donne pas des resultats suffisamment precis et nous avons du developper une autre methode
utilisant une droite affine par morceaux.
9.3.3
Deuxi`
eme m
ethode : approximation de la d
erive des horloges par une
droite affine par morceaux
En reprenant les mesures precedentes (figure 9.3), plutot que de calculer le coefficient directeur dune unique droite cherchant à approximer lensemble de la courbe, nous travaillons sur des
segments plus ou moins longs. Pour chacun de ces intervalles, nous approximons la courbe par
une droite dont nous calculons le coefficient directeur de la meme manière que precedemment (la
droite choisie est celle qui passe par le premier et le dernier point de lintervalle). La precision de la
methode est ainsi dependante de la longueur que lon choisit pour les tranches. Nous avons effectue
les calculs pour plusieurs longueurs differentes (pour un calcul donne, toutes les tranches ont la
meme longueur). Les erreurs maximales et moyennes en fonction de la longueur des intervalles sont
presentees dans la table 9.1.
Lhistogramme de la figure 9.8 presente la distribution de lerreur de synchronisation de plus
de 520000 paquets si lon choisit un intervalle de 20 minutes entre deux points de synchronisation ;
on y voit que la plupart de paquets (95.6% du total) ont une erreur inferieure à 0.054 ms, les
erreurs importantes etant extremement minoritaires. Lorsque lon prend en compte le fait que le
temps de transmission dun paquet de 1000 octets est denviron 5 ms à 2 Mbit/s et de 1.6 ms
à 11 Mbit/s, alors il apparat que lutilisation de synchronisation toutes les 20 minutes environ
donnera des resultats suffisamment precis pour nos besoins. Il faut noter que la grande precision
110

Fig. 9.7 Distribution de lerreur residuelle avec lapproximation par une droite (nombre de paquets
en ordonnee, erreur en ms en abscisse)
Longueur de lintervalle
5 min
20 min
30 min
60 min
Erreur maximale
0.23 ms
0.31 ms
0.44 ms
0.62 ms
Erreur moyenne
0.38 s
4.4 s
10 s
30 s
Tab. 9.1 Precision de lapproximation par une droite affine par morceaux
111

Fig. 9.8 Distribution de lerreur de synchronisation avec un intervalle de 20 minutes et sur environ
520000 paquets (nombre de paquets en ordonnee, erreur en abscisse)
de cette methode vient de la propriete des reseaux radio que lon exploite : plutot que de chercher
à maintenir à jour lheure sur chacune des machines en temps reel (comme le ferait NTP) gr
ace `
a
des echanges de paquets, nous utilisons le fait que lorsquun paquet est diffuse en radio, il est recu
simultanement par toutes les machines environnantes.
Dun point de vue pratique, cette methode de synchronisation des fichiers de trace fonctionne
de la manière suivante :
Au debut de la mesure, mise à zero de lhorloge de toutes les machines (paquet de synchronisation special de forwarding, qui necessite que toutes les machines soient à portee de
communication à cet instant de celle qui envoie le paquet).
Mesures diverses, pendant lesquelles les machines peuvent se deplacer, le reseau peut etre
partitionne, etc.
Toutes les 20 minutes environ, arret des mesures, regroupement de lensemble des machines
à portee de celle qui synchronise et diffusion par celle-ci dun paquet qui sera recu par toutes
les autres et qui delimitera ainsi un intervalle.
Fin de la mesure, centralisation des fichiers de trace et recalage.
La figure 9.9 presente le chronogramme obtenu lorsque lon corrige la derive des horloges avec
cette methode. La synchronisation est bien meilleure, les donnees sont tout à fait utilisables.
Cette methode a aussi ete testee dans le scenario presente sur la figure 9.10, o`
u deux emetteurs
cherchent chacun à envoyer autant que possible de paquets de 1000 octets et saturent le canal. Le
chronogramme obtenu est presente sur la figure 9.11
Sil reste du trafic de mesure dans le reseau lorsque les paquets de synchronisation sont diffuses,
il y a un risque que lenvoi de ces paquets soit retarde (phenomène de defering induit par 802.11),
112

horloges est corrigee avec la deuxième methode
Synchro
Data
Data
Fig. 9.10 Disposition des mobiles pour levaluation de la synchronisation (deux sources de
donnees)
Fig. 9.11 Chronogramme de deux mobiles diffusant des paquets lorsque la derive des horloges est
corrigee avec la deuxième methode
113

1
Fig. 9.12 Le synchronisateur pèlerin visite regulièrement les autres mobiles et leur transmet la
bonne horloge
faussant ainsi un peu lechelle de temps. Cependant, et cest le plus important, meme dans ce
cas lordonnancement de lensemble des paquets ne sera pas vraiment affecte ; pas plus que par la
derive de lhorloge de la machine synchronisatrice. Le seul risque est plutot que des paquets de
donnees entrent en collision au niveau de certains mobiles avec les paquets de synchronisation, et
la perte de ces paquets est beaucoup plus dommageable.
Rapporter regulièrement tous les portables à portee de communication du synchronisateur nest
pas toujours aise, en particulier lorsque lon travaille sur des scenarios qui demandent un placement
precis de machines. Les deplacer pour les remettre ensuite en place peut poser problème, une erreur
de replacement de quelques centimètres ayant parfois un impact tout à fait non negligeable. De
plus cette phase de deplacement de toutes les machines peut demander un temps et une main
duvre considerables sil y a beaucoup de machines. Hors cest autant de temps pendant lequel
les batteries sepuisent inutilement. Nous avons donc raffine notre methode.
9.3.4
Troisi`
eme m
ethode : le p`
elerin synchronisateur
Nous avons vu quavec la methode de lapproximation de la derive des horloges par des droites affines par morceaux, une duree dune vingtaine de minutes etait un bon compromis entre la precision
de la methode et le travail occasionne. Cette fois-ci cependant, le moment venu, plutot que de
deplacer toutes les machines vers le synchronisateur cest le synchronisateur lui-meme que nous
deplacons (exemple dun longue chane sur la figure 9.12). La difference majeure avec la methode
precedente tient dans le fait que, dans certaines topologies, aucun des paquets envoyes par le synchronisateur ne pourra atteindre tous les mobiles à la fois. Il ne sera plus possible de comparer les
dates locales de reception dun meme paquet pour calculer la derive relative des horloges.
La solution choisie consiste à faire porter par les paquets de synchronisation une information
horaire. En loccurrence, ces paquets sont emis à une frequence fixe et precise (par exemple toutes
les 5 secondes). Grace au numero de sequence du paquet, il est possible de calculer directement
lheure de reception de ce paquet dans lhorloge de reference (en multipliant le numero de sequence
par le temps separant lemission de deux paquets consecutifs). Il faut noter quici lhorloge de
reference est donc lhorloge de la machine qui envoie les paquets de synchronisation.
Comme precedemment, la synchronisation des resultats se fait post-mortem ; une fois les fichiers
de trace regroupes, ils sont analyses et recales. Nous appliquons toujours la methode de lapproximation de la derive des horloges par une droite affine par morceaux, mais cette fois-ci les segments
sont delimites par la reception de deux paquets de synchronisation consecutifs. La date de reception
du paquet de synchronisation de numero de sequence zero est lorigine du temps global. Si les pa-
114

Espace de temps global
k*n1
k*n2
R(t1-ts1)+(k*n1)
k*n3
R(t2-ts2)+(k*n2)
t1
t2
ts1
ts2
ts3
Espace de temps local
Fig. 9.13 Le passage dune echelle de temps local à une echelle de temps global (methode du
pelerin)
quets de synchronisation sont envoyes toutes les k secondes alors la date de reception (en temps
global) dun paquet de synchronisation de numero de sequence n est :
Tn = k n
(9.2)
Si ts1 et ts2 sont les dates locales de reception de deux paquets de synchronisation consecutifs
de numeros de sequence respectifs n1 et n2 , alors (ts2 ts1 ) est le temps local qui sest ecoule entre
les deux. Par definition de 9.2, le temps global ecoule entre les deux est :
k (n2 n1 )
(9.3)
Le rapport lineaire entre le temps global et le temps local est donc :

R=
k (n2 n1 )
(ts2 ts1 )
(9.4)
tts1 exprime le temps local ecoule entre la reception dun paquet de donnees et celle du paquet
de synchronisation le precedant. Pour un paquet de donnees recu à une date locale t comprise entre
ts1 et ts2 , le temps global T de reception de ce paquet est calcule de la manière suivante :
T = R (t ts1 ) + k n1
(9.5)
Grace à ces formules, nous pouvons projeter les dates de reception locales de tous les paquets
sur une echelle de temps global constituee par la reception des paquets de synchronisation. La
figure 9.13 donne un exemple de cette relation. Les temps locaux (estampilles à la reception des
paquets) sont indiques dans la partie basse du schema, les formules pour les convertir en temps sur
lechelle globale sont indiques dans la partie haute. Les paquets de synchronisation sont schematises
par des traits verticaux epais, les paquets de donnees par des traits verticaux fins.
Il faut noter que cette methode peut etre amelioree afin de fournir des chronogrammes toujours
plus precis. En effet, telle que nous lavons decrite, nous utilisons la propriete quun paquet radio
est recu exactement au meme moment par les mobiles à portee de communication, mais nous ne
nous servons que des paquets dits de synchronisation qui sont envoyes assez peu souvent.
Au cours de la mesure, un grand nombre de paquets de donnees sont en general envoyes.
Si certains de ces paquets sont envoyes en mode diffusion, au moment de lanalyse des traces,
nous les retrouverons s
urement à plusieurs endroits. Là encore, on peut utiliser la propriete de
115

Data
Synchro
Fig. 9.14 Disposition des mobiles pour levaluation de la synchronisation (une source de donnees)
horloges est corrigee avec la troisième methode
simultaneite pour ameliorer la synchronisation entre les differents mobiles qui ont recu un meme
paquet. En quelque sorte, ces paquets nous donnent des jalons intermediaires entre les paquets de
synchronisation qui nous donnent eux-memes le temps absolu. Dans les sous-segments delimites par
tous ces paquets, nous appliquons toujours le mecanisme dapproximation par des droites affines
par morceaux.
Au final, cette methode permet dobtenir une très grande synchronisation des traces, compatible
avec nos besoins.
De part la nature de la methode, pour la valider il a fallu utiliser la topologie presentee sur
la figure 9.14 (elle consiste à rependre celle presentee sur la figure 9.1 et à ajouter le mobile
synchronisateur). Il y a toujours deux mobiles recepteurs, mais en plus du mobile synchronisateur,
un autre mobile a ete ajoute qui diffuse des donnees à la vitesse de 10 paquets de 1000 octets par
seconde. Ce sont la reception de ces donnees sur les deux mobiles recepteurs qui est presentee sur
le chronogramme 9.15. On voit que cette fois-ci, la synchronisation est vraiment très bonne, notre
objectif est atteint.
Dans le cadre du scenario de la figure 9.10, les resultats sont egalement très bons, comme on
peut le voir sur le chronogramme 9.16
Fig. 9.16 Chronogramme de deux mobiles diffusant des paquets lorsque la derive des horloges est
corrigee avec la troisième methode
116
CHAPITRE
0
10
Les sc
enarios avanc
es
Après avoir realise un certain nombre de mesures preparatoires et developpe des outils de
synchronisation adequats, nous avons pu passer à des mesures dans des scenarios plus complexes.
A des fins evidentes de comparaison, nous avons cherche à reproduire dans la realite les scenarios
que nous avions utilise lors de la phase de simulation. Les problèmes daccès au canal seraient-ils
aussi sevères que les simulations et les calculs le laissent supposer ? Dans ce chapitre, nous allons
presenter les resultats obtenus pour des configurations à deux et trois paires ainsi que pour une
chane comportant de 1 à 4 sauts.
10.1
Les deux paires
Jusquà present, nous nous sommes interesses à la portee effective des cartes 802.11. Dans
cette experience, nous cherchons à mesurer jusquà quelle distance des mobiles peuvent detecter
reciproquement leurs porteuses et à partir de quand la reutilisation spatiale devient possible. Pour
ce faire, nous utilisons quatre mobiles repartis en 2 paires. Ces quatre mobiles sont initialement
très proches et au fur et à mesure de lexperience nous allons eloigner les deux paires lune de
lautre comme indique sur la figure 10.1. Lorientation des cartes est egalement celle indiquee sur
la figure 10.1, cest à dire sur les cotes par rapport au sens de deplacement, et non face-à-face ou
dos-à-dos. Dans la pratique nous eloignons les paires par etapes successives. Chaque etape dure 75
secondes pendant lesquelles nous effectuons des mesures pour plusieurs combinaisons de flux et de
vitesses de transmission (nous utilisons toujours des paquets UDP de 1000 octets). Ces 75 secondes
sont à chaque fois suivies de 25 secondes dinactivite pendant lesquelles nous deplacons les mobiles,
puis un nouveau cycle commence. La figure 10.2 decrit les combinaisons de flux pendant les phases
de transmission (nous rappelons que la diffusion se fait toujours à 2 Mbit/s, et quici lenvoi en
unicast est configure pour se faire à 11 Mbit/s) :
0 `
a 15 : Un flux à 11 Mbit/s dans la paire de droite et un flux à 2 Mbit/s dans celle de
gauche.
15 `
a 20 : Uniquement le flux à 2 Mbit/s dans la paire de gauche.
20 `
a 35 : Un flux à 2 Mbit/s dans chacune des paires.
35 `
a 40 : Un flux à 2 Mbit/s uniquement dans la paire de droite.
40 `
a 55 : Un flux à 11 Mbit/s dans la paire de gauche et un flux à 2 Mbit/s dans celle de
droite.
55 `
a 60 : Un flux à 11 Mbit/s uniquement dans la paire de gauche.
60 `
a 75 : Un flux à 11 Mbit/s dans chacune des paires.
La figure 10.3 presente les debits mesures par le mobile 2 en fonction du temps. Comme chaque
phase de transmission se fait à une position donnee, puis que les mobiles sont deplaces durant les
117
CHAPITRE 10. LES SCENARIOS

AVANCES
25 secondes qui suivent, la legende de la figure en abscisse indique directement les distances. Cette
figure porte de nombreuses informations et nous allons la commenter en trois parties distinctes en
commencant par les plus simples :
A 190 m`
etres : Les deux paires sont totalement independantes, aussi bien à 11 quà 2 Mbit/s.
Quelle que soit lactivite dans lautre paire, le debit utile des flux unicast depasse donc les
5 Mbit/s, ce qui est le maximum possible pour la taille de paquet utilisee. Il en est de meme
avec le flux broadcast qui plafonne quant à lui aussi à son maximum, cest à dire 1.6 Mbit/s
environ. Du fait de la distance, les paquets emis en mode diffusion par le mobile 3 ne sont
evidemment pas recus du tout par le mobile 2.
A courte distance (jusqu`
a 58 m`
etres) : Les emetteurs doivent partager le canal. Plusieurs
situations se detachent :
Deux flux broadcast simultanes (secondes 20 à 35 des cycles concernes) : ils obtiennent
chacun un peu plus de la moitie de ce quun aurait obtenu seul, soit environ 0.8 Mbit/s.
La raison pour laquelle il nobtiennent pas juste la moitie est celle qui avait ete donnee
lors de letude precedente de 1 à 7 flux simultanes : les backoff sont decrementes en partie
simultanement et cela se traduit par un temps en moyenne inferieur entre deux paquets
consecutifs sur le canal.
Deux flux unicast simultanes (secondes 60 à 75 des cycles concernes) : ils obtiennent
egalement chacun un peu plus de la moitie de ce quun aurait obtenu seul, soit pas loin de
3 Mbit/s.
Un flux unicast et un flux broadcast simultanes (secondes 0-15 et 40-55) des cycles
concernes : ils se partagent le canal avec une probabilite daccès egale. Cela se traduit
par un debit intermediaire denviron 1.3 Mbit/s pour chacun des flux. En effet, le flux `
a
2 Mbit/s envoie autant de paquets que celui à 11 Mbit/s. Ce dernier va donc se trouver
penalise par ce partage. Les deux flux vont obtenir le meme debit alors que lun deux est
sense avoir un debit plus eleve. Ce phenomène a ete releve par [42].
Entre 94 et 160 m`
etres : Cest dans cette region que les interferences se manifestent. On
remarque tout dabord que lon est desormais trop loin pour que le mobile 2 recoive encore
correctement les paquets envoyes en mode diffusion par le mobile 3. A 94 mètres et un tout
petit peu à 120 mètres on recoit neanmoins encore quelques uns de ces paquets, mais plus
aucun à 160 mètres. Puisque cest à cette distance que les phenomènes sont les plus visibles,
nous nous attardons sur chacune des combinaisons de flux à une distance de 160 mètres :
Lorsque le flux unicast local doit cohabiter avec le flux broadcast distant (secondes 0-15 du
cycle), on remarque que le canal est partage. Le flux unicast nobient en effet quenviron
1.5 Mbit/s. Comme nous lavons dejà dit, le flux broadcast nest pas compris à cette distance
(et napparat pas sur la courbe, mais il est bel et bien detecte.)
Lorsque le flux unicast local doit cohabiter avec le flux unicast distant (secondes 60 `
a 75
du cycle), il ny a visiblement plus de partage du canal necessaire, puisque le flux local est
au debit maximum.
Le flux broadcast (secondes 20 à 55 du cycle) est lui aussi affecte par le flux broadcast
distant, mais dans une moindre mesure : on voit une instabilite assez nette tant que le
mobile distant emet à 2 Mbit/s, mais cette instabilite disparat lorsque le mobile distant
passe à 11 Mbit/s.
Dans [41], les auteurs presentent le problème de la zone grise. Ce problème apparat lorsque
les protocoles de routage utilisent des paquets diffuses à 2 Mbit/s pour construire les routes, et
118

AVANCES

1 > 2
Unicast

Broadcast
15
20
35

Broadcast
3 > 4

Unicast

Unicast
40
55
60
75
time in seconds
Fig. 10.1 Positions des deux paires Fig. 10.2 Communications dans le schema des paires
mobiles
mobiles
6
unicast 1 -> 2
broadcast 1 -> 2
broadcast 3 -> 4
Throughput in Mb per second
0
very close
25.5m
58m
94.5m
distance in meters
119.75m
159.75m
189.75m
Fig. 10.3 Paquets recus par les 2 nud recepteurs dans le scenario des deux paires mobiles
que les donnees sont ensuite envoyees à une vitesse superieure (par exemple 11 Mbit/s). Comme
la portee diminue avec laugmentation de la vitesse, il se peut que certaines routes soient valides `
a
2 Mbit/s mais ne soient pas utilisables `
a 11 Mbit/s. Cest la difference entre les zones de couverture
à differentes vitesses qui est appelee zone grise. Dans cette experience des deux paires mobiles, nous
navons pas mesure directement la zone grise. Nous avions bien un flux à 2 Mbit/s et une autre `
a
11 Mbit/s, mais ce dernier etait en unicast et restait local dans chaque paire mobile, il ne pouvait
donc pas etre compris par lautre paire. Par contre, et en particulier à 160 mètres, lextension du
problème de la zone grise à la zone de detection de porteuse est très visible. La portee de detection
de porteuse dun flux à basse vitesse est nettement plus grande que celle dun flux plus rapide
(11 Mbit/s). De ce fait, à 160 mètres, durant les secondes 0 à 35 du cycle, on voit très bien que les
flux locaux (aussi bien à 11 Mbit/s quà 2 Mbit/s) nobtiennent pas toute la bande passante : il y
a detection de la porteuse du flux à 2 Mbit/s dans lautre paire et il y a donc partage du canal.
La portee de detection de porteuse du flux distant à 11 Mbit/s (secondes 40 à 75 du cycle) est elle
inferieure à 160 mètres. Les flux locaux à 2 et 11 Mbit/s ne detectent pas du tout son activite et
occupent la totalite de la bande passante.
119

AVANCES
10.2
Les trois paires
La configuration des trois paires que nous avons etudiee par simulation avait montre de graves
problèmes dans lequite de laccès au medium pour la paire centrale lorsquelle percevait en quasi
permanence le canal occupe par lune ou lautre des paires exterieures. A des fins de verification,
nous avons donc cherche à reproduire cette configuration pour des mesures reelles. Pour des raisons
pratiques, nous avons travaille en interieur. En utilisant la topologie du batiment, il nous etait en
effet plus facile de faire en sorte que les deux paires exterieures ne se genent pas du tout entre
elles. Nous avons travaille à 2 Mbit/s et sans RTS/CTS. Dans la configuration presentee sur la
figure 10.4, les paires exterieures pouvaient detecter la porteuse de la paire centrale (nous lavons
verifie en constatant un partage equitable du canal si lon activait la paire centrale et seulement lune
des paires exterieures à la fois), et les deux paires exterieures ne se genaient pas (elles obtenaient
toutes les deux le debit maximum si elles etaient activees en meme temps). Une fois toutes les
machines dans la position voulue, nous avons active un flux dans chacune dentre elles (comme `
a
laccoutumee, afin de saturer le reseau, nous avons utilise des flux de paquets UDP de 1000 octets
pour lesquels la file dattente est toujours pleine).
Les debits mesures sur chacune des paires sont presentes sur la figure 10.5. Il faut noter qu`
a
partir de la seconde 925 environ, les emetteurs des paires centrale et gauche sont stoppes. On
observe très clairement les difficultes rencontrees par la paire centrale : son debit evolue entre 5 et
15% du debit des paires exterieures. On remarque egalement la presence dune periode (entre les
secondes 805 et 870 environ) o`
u le debit sur la paire centrale est vraiment très faible (moins de 10
paquets par seconde, soit moins de 5% de la bande passante). Cette periode correspond au moment
o`
u le debit des paires exterieures est quasiment maximal. Le reste du temps, la paire de droite
semble partager la bande passante (dune manière certes non-equitable) avec la paire centrale.
Après une etude detaillee et de nombreuses repetitions de lexperience, nous avons determine que
ce partage venait en fait dinterferences au niveau de la paire de droite par une station de base
situee à un autre etage du batiment (et sur laquelle nous navions pas de controle).
Cette experience confirme donc de manière très nette les simulations. Dans certaines situations
o`
u des mobiles sont genes de facon asymetrique, certains mobiles utilisant 802.11 peuvent connatre
de grande difficultes pour acceder au canal. Comme nous lavons dejà explique, ce problème ne
peut etre regle simplement, car ils est cause par la conjonction de lactivite de plusieurs mobiles
qui en empechent ainsi dautres dacceder correctement au medium. Les mobiles qui emettent nont
dailleurs pas de moyen de savoir quils genent quelquun dautre.
10.3
La chane
10.3.1
Le sc
enario, les contraintes
La configuration que nous voulons tester est celle presentee sur la figure 10.6. Lenvironnement
de mesure est le boulevard precedemment decrit (chapitre 7). Nous utilisons cinq portables pour
realiser la chane, ainsi quun sixième qui joue le role de synchroniseur selon la methode presentee
dans le chapitre precedent. Nous utilisons bien evidemment forwarding pour forcer la topologie
logique (le mobile 2 re-emet tous les paquets quil recoit de 1, le mobile 3 re-emet tous ceux quil
recoit de 2 et ainsi de suite). Afin de recolter un maximum de donnees, les transmissions se font en
mode diffusion, et donc à 2 Mbit/s. La diffusion permet de savoir, pour chaque paquet emis, `
a quels
120

AVANCES
Fig. 10.4 Les disposition des mobiles pour lexperience des trois paires
Fig. 10.5 Les difficultes pour la paire centrale à acceder au canal
121

AVANCES
1
Fig. 10.6 La chane à 4 sauts et le synchronisateur
endroits il peut etre recu (en fonction des receptions dun meme paquet, on reconstruit directement
la zone de communication du mobile qui a emit ce paquet).
Le premier problème rencontre reside dans la portee des emetteurs lorsquon les utilise `
a
2 Mbit/s. Dans le chapitre sur la portee, nous avons vu que le signal pouvait alors etre recu `
a
plus de 500 mètres. Mais le boulevard o`
u nous effectuons les experimentations ne mesure quun
kilomètre environ et nous navons pas à disposition un environnement homogène permettant directement lexperience de la chane (il nous faudrait une ligne droite dau minimum deux ou trois
kilomètres). Nous avons avons donc decide de reduire artificiellement la portee de nos emetteurs.
Pour cela nous utilisons du papier daluminium avec lequel nous entourons les antennes de nos
cartes (nos cartes Lucent ne permettaient pas de changer la puissance demission). Aussi empirique
et simpliste quelle puisse paratre, cette methode est très efficace et permet de diviser la portee des
cartes par un facteur 5 à 10 suivant la quantite daluminium utilise. Cette facon de proceder a un
interet majeur à nos yeux : elle nous permet deffectuer la mesure de la chane tout en la gardant `
a
une echelle significative du point de vue de lenvironnement et des interferences. Il nous aurait ete
possible dutiliser des antennes externes modifiees pour avoir un gain très faible (techniquement,
en donnant une portee de lordre du mètre à nos carte il aurait ete ainsi possible de realiser lensemble des mesures multi-sauts dans une seule pièce), mais un tel changement dechelle du reseau
modifie profondement les effets de lenvironnement sur lexperience. Dans un reseau multi-sauts
à une echelle de quelques centaines de mètres, les conditions dinterferences de lenvironnement
peuvent etre très differentes dun endroit à lautre du reseau (passage dune voiture, proximite dun
equipement perturbateur, batiment qui reflechit les ondes de certains emetteurs, portes fermees
ou ouvertes en interieur, presence ou simplement passage de pietons, etc.). Un reseau miniature
(tenant dans une pièce) ne serait pas soumis aux memes phenomènes (la plupart des elements
perturbateurs decrits precedemment affecteraient lensemble du reseau de manière uniforme).
10.3.2
Le d
eploiement et le d
eroulement de lexp
erience
Afin de mieux rentabiliser notre temps (et la duree des batteries), lexperience est concue de
manière à mesurer en une seule fois les comportements sur des chanes à 1, 2, 3 et 4 sauts. Dans
un reseau ad hoc, une configuration de chane apparat lorsque lemetteur dun paquet est trop
loin du destinataire et que des mobiles intermediaires doivent relayer les donnees de proche en
proche. Les mobiles intermediaires sont choisis par le protocole de routage et en general ils vont
letre de manière à minimiser le nombre de sauts. Cela signifie que chaque mobile de la chane
peut communiquer avec ses voisins directs, mais pas avec ses voisins à deux sauts. Forwarding nous
permet, en forcant le choix des routes, deviter toute instabilite dans leur choix qui pourrait etre
liee au protocole de routage. Mais en contrepartie il faut nous assurer nous-meme du placement des
mobiles. La chane de notre experience est donc construite progressivement. Le mobile 1 est place
122

AVANCES
a` une extremite du boulevard et configure pour emettre un flux à vitesse maximale (ici des paquets
UDP de 1000 octets). Le mobile 2 est mis en route. Initialement il est proche du mobile 1, et on
leloigne jusquà ce que le debit quil en recoit commence à baisser. En quelques minutes on arrive,
grace à laffichage du debit en temps reel et par des deplacements successifs, à la placer à la limite
de la zone dans laquelle la plupart des paquets emis par le mobile 1 sont recus. On configure alors
le mobile 2 pour emettre lui aussi (à cette etape, on ne stoppe pas encore lemission du mobile 1).
On peut alors placer le mobile 3 en fonction des flux venant de 1 et de 2. Quelques minutes sont
egalement necessaires pour trouver une position dans laquelle on recoit bien le mobile 2, mais pas
ou très peu le mobile 1. On peut alors demarrer lemission sur le mobile 3 et stopper celle sur le
mobile 1 (pour economiser lenergie) ; on place alors le mobile 4 ... et ainsi de suite.
Finalement, on arrive donc à placer les 5 mobiles de la chane dans la configuration desiree. On
stoppe alors les flux restants et on effectue un passage de synchronisation avec le sixième mobile.
10.3.3
Les r
esultats
Nous avons realise deux fois cette experience. Il aurait ete preferable de la realiser plus de fois
encore, mais la lourdeur de ce genre dexperimentation est telle que cela na pas ete possible.
Premi`
ere mesure
Lors de la première mesure, une fois les mobiles places comme decrit precedemment et la phase
de synchronisation initiale effectuee, nous demarrons le flux de donnees sur la chane. Au depart,
il ny a pas de repetition des paquets (un seul saut), et au fur et à mesure on allonge la chane en
activant la repetition sur chacun des mobiles. Les paquets UDP font 1000 octets, ils sont envoyes
en mode diffusion, à 2 Mbit/s. Les debits mesures sont presentes sur les figures 10.7 à 10.11. La
chronologie de lactivation des re-emissions et linterpretation des resultats est la suivante :
270 `
a 380 : Aucune repetition, seul le flux entre 1 et 2 existe, il obtient la totalite de la bande
passante, soit environ 1.6 Mbit/s de debit utile (figures 10.7 et 10.8) et est assez stable. On
remarque sur la figure 10.9 que certains paquets emis par 1 sont recus en 3 (secondes 300 `
a 340
environ) mais quils ne sont pas très nombreux. Ces paquets sont très interessants et montrent
bien un problème specifique aux reseaux ad hoc : la propension à subir des interferences par
rafales. Ces paquets recus en 3 `
a partir de 1 auraient pu conduire un protocole de routage
à etablir une route directe. Mais la duree de vie de cette route aurait ete courte (30 `
a 40
secondes), et surtout aurait subit un taux de perte particulièrement elevee (90 à 95% environ).
380 `
a 540 : Le mobile 2 repète les paquets quil recoit de 1 (la chane passe à 2 sauts). Les flux
(12) et (23) doivent donc se partager le canal. Ce partage seffectue assez bien au debut
(partie de 380 à 490), comme latteste la figure 10.7. Pour cette partie tout dabord, comme
le laissait presager lexperience precedente des 2 à 7 flux en concurrence dans la meme pièce,
on y voit que le debit agrege de deux flux est dans ces conditions egal voire un peu superieur
à un seul flux qui aurait toute la bande passante. On remarque cependant, toujours sur la
figure 10.7, quil y a quelques pertes : le debit du flux (23) est legèrement inferieur `
a celui
du flux (12) alors quidealement ils devraient etre identiques. Si lon compare le flux venant
de 2 recu en 2 et en 3 sur les figures 10.8 et 10.9, on constate que (22) est strictement egal
à (12) (les courbes sont superposees) et superieur à (23). Ceci est tout à fait normal. En
fait, 2 recoit lui-meme les paquets quil diffuse quoiquil arrive sur le canal (les paquets sont
envoyes par forwarding à la couche IP, qui les envoie dune part à la couche MAC, mais aussi
123

AVANCES
directement à forwarding puisquil sagit dune diffusion). On remarque enfin sur la figure 10.9
la presence de quelques paquets venant directement de 1 (secondes 380 à 400), alors que les
mobiles 4 et 5 nont jusquà present percu aucun paquet.
Les choses se gatent cependant entre les secondes 490 et 540, o`
u le flux (23) est brusquement
fortement affecte par des interferences externes : son debit devient très instable. Pour cette
partie, on voit que le debit recu en 2 à partir de 1 ne change pas (figure 10.7 et 10.8) et que
ces paquets sont transmis à la couche MAC de 2 (flux (22) sur la figure 10.8). De ces deux
choses, on deduit donc que les paquets sont bien emis par 2 mais quils ne sont pas recus par 3
(sils netaient pas re-emis par 2, le debit de (12) augmenterait avec la bande passante ainsi
liberee). Ceci souligne une fois de plus la tendance de certaines des interferences exterieures
à se produire par rafale.
540 `
a 700 : Le mobile 3 se met à repeter les paquets quil recoit de 2 (et uniquement ceuxlà) ; la chane passe ainsi à 3 sauts. On voit que de saut en saut, des paquets sont perdus
(figures 10.7 à 10.10), et que le debit effectif arrivant en 4 est faible (figure 10.10 : en moyenne
de 200 kbit/s alors quil devrait idealement depasser les 500 kbit/s) et extremement instable
(parfois quasiment nul pendant 5 à 10 secondes). On remarque, comme dans les simulations,
que le mobile qui genère les paquets (le mobile 1) occupe plus la bande passante quil ne le
devrait pour un accès equitable au medium. Lorsque des paquets sont perdus plus loin sur la
chane, les mobiles qui auraient d
u les re-emettre peuvent se trouver dans une situation de
famine, et le mobile 1 qui lui a toujours sa file demission pleine en profite.
700 `
a 830 : Le mobile 4 se met à repeter les paquets quil recoit de 3 ; la chane passe `
a
4 sauts. Les observations sont semblables à celles de la chane à 3 sauts : des paquets sont
perdus à chaque etape et le debit de bout en bout est à la fois faible est très instable. Entre
les secondes 780 et 800 environ, plus aucun trafic nest meme recu en 4 (figure 10.11). On
remarque egalement (figure 10.8) que le flux (12) maintient le meme debit que lorsquil y
avait un saut de moins ; il saccapare une part de la bande passante de plus en plus importante
par rapport à ce quelle devrait etre idealement.
Une fois cette experience de la chane à 4 sauts realisee, comme il nous restait suffisamment de
charge sur nos batteries, nous avons decide de reproduire la meme experience, mais en unicast. La
vitesse de transmission reste de 2 Mbit/s (la changer aurait signifie la necessite de replacer tous les
mobiles en consequence, et nos batteries nauraient pas tenu aussi longtemps). Passer en unicast
presente linteret dactiver le mecanisme des acquittements (et donc de la detection des collisions ou
erreurs de transmission, avec la re-emission qui sen suit), mais a le desavantage de nous empecher
de detecter les paquets qui ne nous sont pas explicitement envoyes. Les debits presentes sur les
figures 10.12 à 10.16 sont donc moins riches que celles de la phase en diffusion (pour des raisons
de facilite de lecture, les figures 10.13 à 10.16 reprennent chacune une courbe de la figure 10.12 de
facon separee).
La chronologie de lactivation des re-emission et leur interpretation est la suivante :
1140 `
a 1205 : Il ny a pas de re-emission, seul le flux (12) existe. Il utilise toute la bande
passante et le debit effectif depasse les 1.5 Mbit/s (figures 10.12 et 10.13). Il est evidemment
inferieur au debit lors de la phase equivalente en diffusion, puisquil faut maintenant prendre
en compte les acquittements. La stabilite de lunique flux est comparable celles de la phase
en diffusion, cest-à-dire assez grande.
1205 `
a 1415 : Le mobile 2 se met à re-emettre les paquets quil recoit de 1 ; la chane passe
à 2 sauts. Le canal est partage equitablement (figure 10.12) et le debit de bout en bout est
124

AVANCES
2e+06
de 1 recu en 2
de 2 recu en 3
de 3 recu en 4
de 4 recu en 5
debit aggrege
1.5e+06
1e+06
500000
0
300
400
500
600
temps en secondes
700
800
Fig. 10.7 Debit de proche en proche sur la chane (mesure 1, broadcast)
2e+06
de 1 recu en 2
de 2 recu en 2
de 3 recu en 2
de 4 recu en 2
debit aggrege
1.5e+06
1e+06
500000
0
300
400
500
600
temps en secondes
700
800
Fig. 10.8 Occupation du canal percue par le nud 2 (mesure 1, broadcast)
125

AVANCES
2e+06
de 1 recu en 3
de 2 recu en 3
de 3 recu en 3
de 4 recu en 3
debit aggrege
1.5e+06
1e+06
500000
0
300
400
500
600
temps en secondes
700
800
2e+06
de 1 recu en 4
de 2 recu en 4
de 3 recu en 4
de 4 recu en 4
debit aggrege
1.5e+06
1e+06
500000
0
300
400
500
600
temps en secondes
700
800
126

AVANCES
2e+06
de 1 recu en 5
de 2 recu en 5
de 3 recu en 5
de 4 recu en 5
debit aggrege
1.5e+06
1e+06
500000
0
300
400
500
600
temps en secondes
700
800
optimal ou presque, sauf entre les secondes 1240-1260 et 1380-1415 environ.

Entre 1240 et 1260, le mobile 2 ne re-emet plus les paquets. Cela se voit à labsence de
reception par 3 dans cette periode (figure 10.14) et au debit du flux (12) qui augmente
subitement pour utiliser toute la bande passante disponible (figure 10.13).
Entre 1380 et 1415, les choses sont un peu plus mitigees, le debit de (12) augmente alors
que celui de (23) diminue, mais (23) ne devient pas nul. Dans ces deux cas, on assiste
donc à une capture partielle ou totale du canal par le mobile 1, et ce pour une duree assez
longue (une vingtaine de secondes environ).
1415 `
a 1540 : Le mobile 3 se met à re-emettre les paquets quil recoit de 2 ; la chane passe `
a
3 sauts. Le partage du canal est très equitable (figure 10.12) entre les flux (12) et (23). Il
lest un peu moins avec (34) qui voit parfois son debit chuter de manière très importante.
Toujours sur la figure 10.12, la courbe de debit agrege nous montre encore une fois assez bien
la tendance des interferences à se manisfester par rafales (chutes très importantes du debit
dans le reseau pour des durees de 5 à 20 secondes en general).
1540 `
a 1720 : On passe à 4 sauts. Le comportement est encore une fois très semblable `
a
celui de la chane à 3 sauts mesure juste avant. Les debits de (12) et (23) sont en general
très proches (figure 10.12), de meme pour (34) et (45). La plupart des pertes se trouvent
au moment du passage de 3 à 4. Le debit de bout en bout obtenu dans la realite sur la chane
à quatre sauts est different de celui obtenu par simulation (figure 10.17) Dune part il est
beaucoup plus instable. Dautre part il se situe en general autours de 250 kbit/s alors que les
simulations lestimaient à 400 kbit/s. Dans la realite, il na atteint quune fois la valeur de
400 kbit/s, et pour une duree assez courte (une dizaine de secondes environ).
127

AVANCES
2e+06
de 1 recu en 2
de 2 recu en 3
de 3 recu en 4
de 4 recu en 5
debit aggrege
1.5e+06
1e+06
500000
0
1100
1200
1300
1400
1500
temps en secondes
1600
1700
Fig. 10.12 Debit de proche en proche sur la chane (mesure 1, unicast)
2e+06
de 1 recu en 2
1.5e+06
1e+06
500000
0
1100
1200
1300
1400
1500
temps en secondes
1600
1700
Fig. 10.13 Occupation du canal percue par le nud 2 (mesure 1, unicast)
128

AVANCES
2e+06
de 2 recu en 3
1.5e+06
1e+06
500000
0
1100
1200
1300
1400
1500
temps en secondes
1600
1700
2e+06
de 3 recu en 4
1.5e+06
1e+06
500000
0
1100
1200
1300
1400
1500
temps en secondes
1600
1700
129

AVANCES
2e+06
de 4 recu en 5
1.5e+06
1e+06
500000
0
1100
1200
1300
1400
1500
temps en secondes
1600
1700
1.8e+06
1.6e+06
1.4e+06
1.2e+06
1e+06
800000
600000
400000
200000
0
0
10
20
30
temps en secondes
40
50
60
Fig. 10.17 Debit de bout en bout simule dans une chane de quatre sauts (modèle two-ray ground)
130

AVANCES
2e+06
de 1 recu en 2
de 2 recu en 3
de 3 recu en 4
de 4 recu en 5
debit aggrege
1.5e+06
1e+06
500000
0
1850
1900
1950
2000
2050
temps en secondes
2100
2150
2200
2250
Fig. 10.18 Debit de proche en proche sur la chane (mesure 2, broadcast)
Deuxi`
eme mesure
Nous avons cherche à reproduire lexperience decrite precedemment. Le protocole experimental
etait identique (configuration et placement des machines), à lexception de la chronologie de lactivation des re-emissions. Cette fois-ci, la chane commence entièrement formee (4 sauts), et au fur et
à mesure de lexperience on stoppe des re-emissions de facon à la raccourcir. A noter que dans cette
experience, les batteries du mobile 1 se sont epuisees à la seconde 2240 environ et que la chane
etait alors constituee de 2 sauts (il ny a pas de mesures à un seul saut dans cette experience donc).
Les resultats sont presentes sur les figures 10.18 à 10.22 et la chronologie des desactivation des
retransmissions est la suivante :
1810 `
a 2050 : Les mobiles 2 à 4 re-emettent les paquets quils recoivent de leur predecesseur
direct, la chane est composee de 4 sauts. Sur la figure 10.18, on voit que les debits des flux
(12) et (23) sont en general très proches lun de lautre, de meme que (34) et (45),
mais que beaucoup de paquets re-emis par 3 sont perdus à certains moments (difference très
visible entre (23) et (34) entre les secondes 1875-1895 et 2010-2050). Dans ces moments
o`
u les mobiles 4 et 5 ne recoivent que peu de paquets, on remarque que le debit sur (12)
et (23) naugmente pas pour autant ... ceci est du au fait que le mobile 3 envoie accède lui
aussi au canal (mais simplement peu de ses paquets sont recus).
2050 `
a 2190 : Le mobile 4 a cesse de re-emettre, la chane nest plus constituee que de 3
sauts. La encore, on constate (figure 10.18) que beaucoup de paquets sont emis par 3 mais
pas recus par 4. On remarque bien aussi les periodes de 10 à 20 secondes pendant lesquelles
les interferences externes causent ces pertes en serie.
2190 `
a 2240 : seul le mobile 2 re-emet, la chane ne fait plus que 2 sauts. Le partage du canal
est très equitable. On remarque très bien neanmoins une periode o`
u lensemble des mobiles
encore actifs sont affectes par des interferences (trou dans le debit des flux (12) et (23)
au alentours des secondes 2230-2240).
La figure 10.23 presente un chronogramme du debut de cette mesure obtenu avec la methode
exposee precedemment. Nous rappelons que dans les chonogrammes construits comme celui ci `
a
partir de mesures reelles, ce sont les receptions de paquet qui sont representees ; chaque rectangle
correspond à un paquet recu et compris, et sa couleur indique par quel mobile il a ete emit. Au
131

AVANCES
2e+06
2e+06
de 1 recu en 3
de 2 recu en 3
de 3 recu en 3
de 4 recu en 3
debit aggrege
de 1 recu en 2
de 2 recu en 2
de 3 recu en 2
de 4 recu en 2
debit aggrege
1.5e+06
1.5e+06
1e+06
1e+06
500000
500000
0
1850
1900
1950
2000
2050
2100
2150
2200
1850
2250
1900
1950
2000
2050
2100
2150
2200
2250
temps en secondes
temps en secondes
Fig. 10.19 Occupation du canal percue par le Fig. 10.20 Occupation du canal percue par le
nud 3
nud 2
2e+06
2e+06
de 1 recu en 4
de 2 recu en 4
de 3 recu en 4
de 4 recu en 4
debit aggrege
de 1 recu en 5
de 2 recu en 5
de 3 recu en 5
de 4 recu en 5
debit aggrege
1.5e+06
1.5e+06
1e+06
500000
1e+06
500000
0
1850
1900
1950
2000
2050
temps en secondes
2100
2150
2200
2250
1850
1900
1950
2000
2050
temps en secondes
2100
2150
2200
2250
Fig. 10.21 Occupation du canal percue par le Fig. 10.22 Occupation du canal percue par le
nud 4
nud 5
132

AVANCES
Fig. 10.23 Chronogramme dans la chane à 4 sauts (mesure 2, broadcast)
debut du chronogramme, le mobile 2 recoit 3 paquets consecutifs du mobile 1 (a), puis en re-emet
un (b). Un peu plus tard, le mobile 3 re-emet ce paquet (c). On remarque que les emissions des
mobiles 1, 2 et 3 nont jamais lieu en meme temps : ils se partagent le canal. Mais lorsque le mobile
4 re-emet un paquet (d), le mobile 1 peut emettre lui aussi : il y a reutilisation spatiale. On peut
voir egalement la perte de certains paquets : en (e), le mobile 3 emet un paquet qui nest recu quen
2, alors quil devrait aussi letre en 4. En (f) enfin, on remarque la reception simultanee dun paquet
emit par 2 en 3, et dun paquet emit par 4 en 5. On savait depuis (d) que 3 etait bien à portee de
4. Alors que ses deux voisins directs ont emit en meme temps, le mobile 3 a donc ete (cette fois-ci
tout du moins) en mesure de recevoir correctement un des deux messages.
R
esum
e et interpr
etation des r
esultats de lexp
erience de la chane
Dun manière generale, nous avons vu au travers des experiences que meme dans des conditions
favorables (routage statique, flux UDP), le debit obtenu dun bout à lautre dune chane dune
longueur pourtant raisonnable (4 sauts au plus) est assez problematique. Lanalyse detaillee des
evenements nous a permis de constater le role important des interferences liees à lenvironnement.
Plutot que de setaler dune manière homogène dans le temps, elles arrivent par rafales. Cela
se traduit par des coupures plus ou moins complètes de communication pendant des periodes de
durees très variables (parfois quelques paquets consecutifs, parfois plus de communications pendant
30 secondes sur le lien). Lorsque les communications sont temporairement rompues sur un segment
de la chane, les segments suivants se retrouvent rapidement en situation de famine : ils nont
plus de donnees à envoyer. Plus la chane est longue, plus les chances quun segment soit rompu ou
gravement bruite à un instant donne sont grandes. Cest probablement ici que se situe le principal
enseignement que lon peut retirer de cette serie dexperiences : du fait des erreurs qui se produisent
souvent par rafales longues (plusieurs dizaines de secondes), les simulations sur-estiment en general
nettement les performances des configurations en chane.
133
CHAPITRE
1
11
Mise en pratique du malus
Au cours de nos simulations, puis plus tard avec des mesures en environnement reel, nous
avons souleve le problème de lequite de laccès au canal radio dans certaines configurations o`
u les
interferences se faisaient de facon asymetrique. Les mobiles les plus genes ne pouvaient pratiquement
jamais envoyer de paquets, car ils detectaient toujours le canal occupe. Nous avons analyse le
phenomène et montre quil etait possible de lattenuer avec un mecanisme de penalites appliquees
aux mobiles qui emettaient trop de paquets par secondes. Afin de confirmer nos dires, nous avons
decide dimplementer ce mecanisme sur nos mobiles et de le tester.
11.1
Choix de limpl
ementation
Le mecanisme du malus est très simple en lui-meme. Le temps est decoupe en cycles courts (une
seconde) et pour chaque paquet envoye, une penalite au backoff doit etre ajoutee en fonction du
nombre de paquets que le mobile a dejà envoye au cours du cycle. La penalite est bien s
ur remise
à zero au debut de chaque nouveau cycle.
La principale difficulte dans limplementation de cette methode est que contrairement à ce que
nous avons pu faire sous simulateur, il ne nous est en fait pas possible de modifier le mecanisme de
backoff. Toute la couche MAC est codee dans une memoire directement soudee sur la carte reseau
radio, et nous navons pas ete en mesure den obtenir les codes sources.
Il nous a fallu trouver une solution de remplacement donnant des resultats comparables, au
moins dans le contexte de lexperience des trois paires.
Comme nous ne pouvions agir sur les couches les plus basses (PHY et MAC), nous avons choisi
de travailler au niveau de la couche reseau. Lidee etait de detourner les paquets juste avant quils
ne soient envoyes à la carte reseau, de les faire attendre à notre convenance dans une file dattente,
puis de les remettre dans le flux normal pour quils soient emis dans les airs.
De cette manière, meme sans controler directement le backoff, il est possible de reduire progressivement le debit des mobiles qui cherchent à emettre trop vite.
Concrètement, limplementation de cet algorithme sest faite avec un filtre de paquets. Un filtre
de paquets est un programme qui analyse les en-tetes des paquets au fur et à mesure quils passent
et decide du devenir de lensemble du paquet en fonction de ce quil y trouve. Il peut decider de
detruire le paquet (DROP) et il disparat alors comme sil navait jamais ete recu ; il peut aussi
laccepter (ACCEPT) et le paquet continue son chemin ; mais il peut egalement en faire quelque
chose de plus complique. Sous linux, le filtrage se fait dans le noyau (le code peut etre directement
integre dans le noyau ou charge sous forme de module), et il peut realiser des fonctions diverses,
meme si le principe explique precedemment reste valide.
134
CHAPITRE 11. MISE EN PRATIQUE DU MALUS

Rception
des paquets
Dcision de
routage
FORWARD
INPUT
Emission
des paquets
OUTPUT
Processus local
Fig. 11.1 Iptables et les differents points daccroche
Le filtrage de paquet est en general utilise pour les fonctions suivantes :

Le controle : Il est possible dautoriser certains types de trafic venant de certains sites et den
interdire dautres (par exemple je ne veux pas que mon ordinateur envoie des requetes HTTP
vers les adresses de doubleclick.net).
La securite : Sur une passerelle, surtout si lon nest pas s
ur de la configuration des machines
qui sont derrière, il peut etre interessant dinterdire complètement certains trafics venant de
lInternet. Il est rassurant par exemple de savoir que quelle que soit la configuration de mes
machines sous windows, les requetes daccès à leurs fichiers seront bloquees au niveau de la
passerelle.
Le monitoring : Si jamais des trafics suspects sont detectes, il est bon que linformation soit
remontee à ladministrateur.
Nous detournons un peu le filtre de paquets de son usage habituel pour le faire retenir les
paquets qui le traversent. Pour comprendre comment nous faisons, il faut dabord savoir comment
le filtrage de paquet fonctionne.
Le mecanisme de filtrage de paquet des noyaux 2.4 de Linux sappelle Iptables [76]. Un certain
nombre de listes de règles appelees chanes sont implementees par defaut (INPUT, OUTPUT et
FORWARD), comme presentees sur la figure 11.1. Quand un paquet atteint une chane, elle est
examinee pour decider du sort du paquet. Si la chane dit DROP, alors il est detruit, et si elle dit
ACCEPT, alors il continue son chemin dans le diagramme. Chaque chane est une liste de règles,
et si len-tete dun paquet ne correspond pas à une règle, alors la règle suivante est examinee, et
ainsi de suite. Si aucune règle ne sest averee convenir au paquet, alors la règle par defaut de la
chane est appliquee (par defaut configuree à ACCEPT).
Le fonctionnement des trois chanes est le suivant :
1. Quand un paquet arrive de linterface reseau, le noyau regarde quelle est sa destination et
decide o`
u il est envoye (routage).
2. Si le paquet est destine à la machine locale, alors il passe dans la chane INPUT, et sil est
accepte par celle-ci, alors il sera recu par tout processus qui lattend.
3. Si le routage est active et si le paquet est destine à une autre interface reseau, alors il passe
dans la chane FORWARD et est envoye si cette dernière laccepte.
4. Finalement, lorsquun processus local veut envoyer un paquet sur le reseau, il doit dabord
etre accepte par la chane OUTPUT avant daller vers linterface à laquelle il est destine
(notez que lon parle bien ici dinterface physique dentree / sortie).
135

Espace utilisateur
Application
file d'attente
delay
ip_queue
Noyau
Carte rseau
sans fil
Fig. 11.2 Le programme delay et la file dattente.
Les règles dans les chanes et les chanes elles-memes peuvent etre ajoutees ou supprimees
en ligne de commande, grace à lutilitaire iptable. Cet utilitaire nous permet en particulier de
specifier laction à effectuer (cest-à-dire la cible, ou encore TARGET) lorsquune règle sapplique `
a
un paquet. Les cibles les plus utilisees sont DROP et ACCEPT, mais nous allons plutot nous servir
de QUEUE, qui permet, grace au module ip queue, denvoyer les paquets dans une file dattente
speciale dans lespace utilisateur. Là, un programme specialement ecrit (delay) pourra aller les
chercher, et les renvoyer au noyau et à linterface physique après les avoir eventuellement retenus
quelques temps (figure 11.2). Le programme delay retarde bien evidemment les paquets en suivant
lalgorithme du malus. Notons que pour obtenir une precision suffisante, nous avons d
u utiliser
lappel système nanosleep, et que de ce fait certaines precautions doivent etre prises quant aux
autres processus fonctionnant au meme instant sur les ordinateurs mobiles (pour que nanosleep
donne la meilleure precision, les règles dordonnancement des processus doivent etre quelque peu
changees).
Il faut noter egalement que le mecanisme du malus doit etre adapte pour pouvoir donner les
resultats attendus. En effet, comme on peut le voir sur la figure 11.3 dans la partie de gauche, si lon
ajoute le malus à un niveau intermediaire entre lapplication (ici la source CBR) et la couche MAC,
alors le malus aura un effet moindre (voir nul) par rapport à sil avait ete applique directement
dans la couche MAC. Si le malus est applique dans netfilter, alors il peut y avoir un recouvrement
entre son temps de pause et lenvoi dautres paquets par la couche MAC. Lobjectif du système
de malus est daugmenter le temps entre deux paquets consecutifs envoyes par un meme mobile
sur le canal, et lon voit ici quil ny arrive pas lorsque le malus est petit. Si le malus pouvait etre
applique directement dans la couche MAC, un tel recouvrement ne serait pas possible. Pour etre
applique en dehors de la couche MAC, il faut donc que le malus tienne compte de la duree de
transmission du paquet (comme presente sur la partie de droite de la figure 11.3). Pour cela, il
a besoin essentiellement de connatre la taille du paquet ainsi que la vitesse à laquelle il va etre
envoye. De cette facon, il est alors possible dimposer le temps inter-trame desire. Notons que sur
la figure, pour des raisons de lisibilite, le backoff aleatoire de la couche MAC nest pas represente
mais que le resultat final est le meme.
11.2
R
esultats
Nous avons realise à nouveau lexperience des trois paires, de la manière dejà decrite (figure 11.5).
Les resultats sont presentes sur les figures 11.6 à 11.9 (pour des raisons de lisibilite, les figures 11.7
à 11.9 reprennent chacune une courbe de la figure 11.6). La penalite appliquee est celle que nous
136

ames
ames
inter-tr
inter-tr
temps
temps
court
court
CBR
temps
malus
malus
ames
ames
inter-tr
inter-tr
temps
court
court
malus
malus
Netfilter
recouvrement entre le malus
et l'mission physique
MAC
Temps inter-trame de la longueur voulue
temps inter-trames court malgr le malus
Fig. 11.3 Adapter le malus pour quil puisse etre applique ailleurs que dans la couche MAC
250
malus
Malus (en nombre de time slots)
200
150
100
50
0
0
10
15
20
paquets envoyes depuis le debut du cycle
25
30
Fig. 11.4 La penalite effective applique en fonction du nombre de paquets envoyes
avions dejà utilisee lors des simulations (figure 11.4), corrigee à la volee de la manière decrite dans
la section precedente afin de prendre en compte la difference dans la manière de lappliquer.
Lexperience sest deroulee en plusieurs etapes, qui peuvent etre decrites et analysees comme
suit :
Secondes 100 `
a 900 : seules les deux paires exterieures sont actives et le malus nest
pas encore utilise. On remarque une certaine instabilite dans les debits. Le debit maximum
theorique est de 190 paquets de 1000 octets par seconde pour un emetteur seul et si aucune
contention ou collision na lieu. Jusquà la seconde 800 environ, la paire de gauche subit des
interferences assez visibles (qui affectent meme la paire de droite vers la seconde 550). Ces
interferences sont en fait dues à une station de base situee à une autre etage du batiment.
Nous avons simplement attendu que ces interferences cessent pour realiser les mesures qui
nous interessaient (les interferences cessent vers la seconde 800, il etait alors midi et les
utilisateurs du reseau ont quitte les bureaux).
Secondes 900 `
a 1350 : la troisième paire est activee. On se retrouve dans les memes conditions que lexperience precedente avec les trois paires (chapitre 10. La paire centrale naccède
que très peu au canal radio (elle narrive à envoyer quentre 5 et 15 paquets par seconde
137
Fig. 11.5 Les disposition des mobiles pour lexperience des trois paires
contre 180-190 pour chacune des paires exterieures). Cette etape est realisee simplement `
a
des fins de confirmation du problème.
Secondes 1350 `
a 1400 : la paire de droite est stoppee. Lobjectif etait de verifier que
conformement aux previsions, les deux paires restantes (gauche et centrale) se partageraient
le canal. On voit que cest effectivement le cas, chacune obtenant environ 95-100 paquets par
seconde.
Secondes 1400 `
a 1700 : on reactive la paire de doite, et on revient dans la meme situation
problematique de la periode 900-1350.
Secondes 1700 `
a 2100 : on active le mecanisme du malus. La pair centrale voit alors ses
chances daccès au canal augmenter de manière significative (son debit evolue desormais entre
60 et 70 paquets par seconde environ). Le debit des deux paires exterieures quand à lui est
logiquement reduit (il plafonne alors à environ 105-110 paquets par seconde). Notons que ces
resultats sont très proches de ceux prevus par la simulation.
Secondes 2100 `
a 2300 : la paire centrale est stoppee, mais les paires exterieures continue
dutiliser le malus. Leur debit continue de plafonner à environ 100 paquets par seconde. Ceci
avait egalement ete prevu par le calcul et les simulations, cest leffet negatif du mecanisme du
malus dans les conditions o`
u il est le plus visible. Les deux paires exterieures ne se genent en
effet pas du tout, et le temps inter-trames supplementaire impose par la malus est ici inutile
et dommageable pour le debit. Notons bien cependant que cest ici le pire cas, et que comme
nous lavons vu, cet effet decrot très rapidement avec laugmentation du nombre de mobile
en contention.
Dans cette experience, nous avons pu verifier que le mecanisme du malus offrait bien les resultats
escomptes et que la paire centrale pouvait acceder au canal dans une proportion beaucoup plus
exploitable quavant. Le desavantage principal du mecanisme a egalement ete souligne : diminution nette du debit maximum possible lorsquil ny pas de contention. Nous rappelons que deux
autres desavantages existent : la tendance à transmettre par rafale ainsi quun retard (assez court
cependant), à lenvoi effectif des paquets.
Il est important de garder à lesprit que dans une situation comme celle de cette experience,
du fait de limpossibilite detablir des communications entre les trois paires, toute solution passait
par un sacrifice de la bande passante maximale. La solution que nous avons choisi (le malus avec
sa progression caracteristique en trois etapes) presente cependant assez peu de desavantages, pour
peu quil y ait plusieurs mobiles en contention.
138
200
gauche
centrale
droite
paquets par seconde
150
100
50
0
0
500
1000
1500
temps en secondes
2000
2500
Fig. 11.6 Experience des trois paires avec le malus
200
gauche
paquets par seconde
150
100
50
0
0
500
1000
1500
temps en secondes
2000
2500
Fig. 11.7 Experience des trois paires avec le malus (paire de gauche)
139
200
centrale
paquets par seconde
150
100
50
0
0
500
1000
1500
2000
2500
temps en secondes
Fig. 11.8 Experience des trois paires avec le malus (paire centrale)
200
droite
paquets par seconde
150
100
50
0
0
500
1000
1500
temps en secondes
2000
2500
Fig. 11.9 Experience des trois paires avec le malus (paire de droite)
140
Conclusions
Dans cette thèse, nous nous sommes interesses au comportement de la norme IEEE 802.11
lorsquelle est utilisee pour realiser des reseaux ad hoc. Dune manière generale, notre travail peut
etre resume en deux etapes principales : la mise en lumière de problèmes et lanalyse de leurs
impacts dune part, ainsi que lapport de solutions dautre part.
La mise en lumi`
ere des probl`
emes et leurs impacts
Pour des raisons pratiques et historiques, nos travaux ont debute par un grand nombre de
simulations. Les scenarios qui nous interessaient etaient très caracteristiques des reseaux ad hoc
de par leur topologie (chanes de mobiles, paires mobiles, etc.) mais aussi par les trafics mis en
uvre (des flux importants, à meme de charger ponctuellement ou durablement le reseau comme le
feraient des applications reelles telles que la navigation sur le web, le transfert de fichiers ou meme
la consultation de messageries).
Neanmoins, les simulateurs disponibles presentent un certain nombre de limitations. De plus,
très peu dexperiences ont ete realisees pour mesurer les impacts reels de 802.11 dans les reseaux
ad hoc. Nous sommes donc passes à une phase de verification de mesures reelles. A cette fin nous
avons developpe un outil appele forwarding specialement concu pour permettre le deploiement et
levaluation de configurations typiquement ad hoc. Afin de nous permettre de nous concentrer
sur le comportement de 802.11, forwarding nous affranchit des couches superieures. Pour cela, il
autorise le routage statique et met en uvre des flux UDP, nous permettant ainsi de controler de
facon très precise lemission et le cheminement de chaque paquet. En utilisant cet outil, nous avons
tout dabord realise des experiences simples, puis nous avons mis en place des experiences plus
complexes. Ces dernières ont necessite letude et le developpement de mecanismes nous permettant
dobtenir des traces parfaitement synchronisees à partir de nos differentes machines. Compte tenu
de la precision dont nous avions besoin, la derive des horloges des ordinateurs est en effet telle que
nous ne pouvions lignorer. Des contraintes supplementaires liees notamment au partitionnement
possible du reseau etaient egalement à prendre en compte. La methode que nous avons proposee
remplit cependant parfaitement nos attentes.
Un certain nombre de caracteristiques de 802.11 ont peu etre mises en evidence dans cette thèse.
Les principales sont les suivantes :
Limpact du WEP La cryptographie WEP de nos cartes presente une anomalie lorsque les
debits utilises sont de 11Mb/s. Cela a une impact important sur le debit lorsque la taille des
paquets depasse un certain seuil, puisque le debit obtenu est bien inferieur au debit attendu. Cette
anomalie a ete mise en evide par experimentation.
141
Le d
ebit global Le debit global dun reseau complet (tous les mobiles peuvent communiquer avec
tous les autres) augmente quand le nombre de mobiles en contention augmente. Cette caracteristique
a ete mise en evidence par une experimentation qui a montre que le debit aggrege augmentait
lorsquon avait jusquà cinq mobiles en contention, puis il se stabilisait après (jusquà sept mobiles
utilises). Ce fait provient du mecanime dattente aleatoire de DFWMAC de 802.11 : lorsquun
mobile na pas pu emettre, il ne retire pas un nouveau backoff aleatoire mais utilise le backoff
restant.
Si on considère que, daprès les travaux de [77], le nombre optimal de voisins dans un reseau
ad hoc devrait etre de lordre de six, cela impliquerait que le debit global est optimal dans chaque
zone de diffusion (o`
u tous les mobiles peuvent communiquer avec tous les autres). Cela est bien s
ur
vrai si on regarde chaque zone de diffusion independamment des autres. Mais il est beaucoup plus
difficile de predire le debit global lorsque ces zones sont dependantes les unes des autres.
La port
ee de communication Une difference de taille est à noter dans les portees de communication obtenues par simulation et par experimentation. En effet, la portee reelle (obtenue en
environnement exterieur) est très inferieure aux portees considerees dans NS2. De plus, les zones de
couverture sont loin detre circulaires comme le suppose les modèles de propagation couramment
utilises en simulation : il existe dans la realite une zone o`
u les communications sont très instables
et sujettent à des interferences liees à lenvironnement se produisant de facon regroupees dans le
temps (par rafales). Lobservation de tels comportement dans la realite alors quils ne sont pas pris
en compte dans les simulateurs (meme dans le modèle shadowing qui est le plus realiste propose par
NS2) indique que ces derniers ont necessairement une vision optimiste, et que leurs resultats sont
peut-etre parfois bien loin de la realite. Ceci est particulièrement problematique dans la mesure o`
u
la perception que les simulateurs donnent de lenvironnement radio aux concepteurs de protocoles
de routage influence ces derniers de facon certaine. Enfin, les experimentations ont montre que
lorientation des cartes, aussi bien au niveau du recepteur que de lemetteur, avait un impact non
negligeable sur la portee de communication.
Les interf
erences par rafales Ce constat provient des deux points precedents et des experiences
reelles (notamment sur la chane) Les communications sont perturbees par des interferences provenant de lenvironnement qui interviennent de manière groupee dans le temps. Pendant des periodes
de temps plus ou moins longues, le debit des communications devient faible, voire nul. Puis les communications repartent normalement sans raison apparente. Ceci rend les resultats reels nettement
inferieurs aux previsions par simulation.
Le m
ecanisme dEIFS apporte une instabilit
e dans les d
ebits Le mecanisme dEIFS est
declenche quand un mobile recoit un signal quil nest pas en mesure de comprendre mais qui
lempeche demettre. LEIFS est environ six fois plus important que le DIFS utilise lors de lenvoi
classique de paquets, i.e. quand aucun signal interferant ne vient troubler les communications.
Or cette difference entre les valeurs de DIFS et de EIFS entrane une instabilite dans les debits. En
effet, lorsquun mobile reussit à prendre la main dans laccès au medium, il va alors la garder pour
lenvoi de plusieurs paquets consecutifs, car le mobile gene par ces communications doit attendre
plus longtemps avant de pouvoir acceder au medium. Cette instabilite a ete mise en evidence par
simulation dans les scenarios des deux paires et des trois paires.
Le partage du m
edium en zone de d
etection de porteuse Si deux mobiles sont en zone
de detection de porteuse lun de lautre, ils doivent partager le medium radio, meme sils sont trop
eloignes pour communiquer. Cette caracteristique a ete mise en evidence par simulation et par
experimentation dans les scenarios des deux paires et des trois paires. Elle sexplique aussi très bien
par le fonctionnement de 802.11. Elle a un impact très important au niveau de la qualite de service
dans de tels reseaux. En effet, si le but est doffrir une garantie sur la bande passante, on voit quil
nest plus possible de seulement se baser sur les communications voisines, mais quil faudra etre en
mesure devaluer les communications seffectuant dans la zone de detection de porteuse.
Dans NS2, la zone de detection de porteuse est deux fois plus grande que la zone de communications. Les experimentations ont montre que cette zone etait aussi de lordre de deux foix la zone
de communication mais quelle etait aussi beaucoup plus instable. Lexperience sur une chane de
mobiles montre que parfois cette zone devenait plus grande ou plus petite.
Les d
ebits multiples 802.11b permet lutilisation de debits multiples : les paquets de donnees
sont envoyes à 11Mb/s alors que les paquets de diffusion sont envoyes à 2Mb/s. De plus, 802.11
permet la degradation de debit dun flux si la communication nest pas bonne. Plusieurs travaux
([42, 41]) ont montre que lutilisation de debits multiples avaient des effets non negligeables. Dune
part, les protocoles de routage qui se basent sur des paquets en mode diffusion vont offrir une vision
erronee du voisinage aux mobiles. Dautre part, le partage equitable que 802.11 offre aux mobiles `
a
portee de communication va ralentir les mobiles à plus grand debit qui auront le meme debit que
les mobiles plus lents. Ces caracteristiques ont ete retrouvees par experimentation.
Les probl`
emes d
equit
e Par simulation et experimentation, des problèmes graves dequite dans
laccès au canal sont apparus, certains mobiles etant dans la quasi-impossibilite denvoyer des
messages pendant des periodes de temps prolongees. Lanalyse de ces problèmes (par simulation et
experimentation, avec laide doutils de visualisation tels que les chronogrammes et par le calcul)
nous a montre quils trouvaient leur source dans la norme 802.11. Cette dernière a ete concue pour
des reseaux à stations de base. Dans les configurations particulières de reseaux ad hoc que nous
avons testees, elle est clairement mise en defaut. La nature du problème tient pour une bonne part
dans linegalite des mobiles faces aux interferences. 802.11 donne des chances comparables daccès
au canal à des mobiles en competition mais à portee de communication directe ou indirecte (deux
sauts, grace aux RTS/CTS). Mais dans les configurations que nous avons presentees ces chances
sont faussees. En effet, certains mobiles vont subir une combinaison des activites de mobiles voisins
qui agissent independamment les uns des autres et qui indique à ce mobile que le canal est occupe
en permanence, et lempeche donc de facon durable dy acceder.
Ce problème a ete mis en relief dans le scenario des trois paires aussi bien par simulation que
par experimentation. Il se retrouve aussi dans le scenario de la chane, mais il est combine à dautres
problematiques (comme des debits differents sur les mobiles par exemple).
Limpact de ces problèmes sur les applications mais egalement sur les protocoles de routage a ete
souligne. Les emissions conjuguees de certains mobiles sont à meme de causer dans leur voisinage
des cassures et des redecouvertes de routes à repetitions ; lefficacite du routage sen ressentant
grandement. Enfin, les protocoles ont une vision erronee du reseau et pourraient peut-etre prendre
des decisions differentes sils disposaient de la topologie reelle.
Impact des EIFS sur l

equit
e . Comme nous lavons vu par la simulation dans le scenario des
trois paires, lutilisation des EIFS peut amplifier les inegalites dans laccès au medium. Dans ce
scenario, la paire centrale accedait jusquà six fois moins souvent au canal que lorsquelle nattendait
que DIFS après la fin dune transmission erronee.
Les RTS/CTS Le mecanisme des RTS/CTS souvent prone comme la solution aux problèmes des
nuds caches semble avoir des effets pas toujours positifs sur des scenarios plus complexes comme
la chane de mobiles. Par simulation, nous avons vu que les debits sur la chane etait fortement
diminue lorsque les RTS/CTS etaient utilises et que la communication etait bien meilleure sans ce
mecanisme.
Les d
ebits r
eels Les experiences ont montre que les debits reels obtenus dans les reseaux ad hoc
testes sont plus faibles que ceux obtenus par simulation.
L
etude de solutions
A partir du moment o`
u les simulations ont souleve les problèmes dequite dont nous venons
de parler, nous y avons cherche des solutions. La nature du problème fait quil semble difficile de
proposer une solution qui ne fasse pas de sacrifice en terme de bande passante. Dans de nombreuses
configurations, les mobiles dont la conjonction des emissions pose problème nont pas de moyen
de sen rendre compte (parfois ces mobiles sont complètement hors de portee de communication
directe ou indirecte les uns des autres ainsi que des mobiles quils empechent dacceder au canal).
Nous avons donc propose une première solution basee sur des penalites appliquees dune manière
etudiee aux mobiles qui emettent beaucoup. Sous simulateur, cette methode a donne des resultats
tout à fait satisfaisants, aussi bien dans les scenario des trois paires que dans celui de la chane
perturbee. Le principal desavantage de la methode est une chute du debit maximum possible en cas
dabsence de contention. Ce desavantage est cependant très vite limite et rendu imperceptible dès
que le nombre de mobiles en contention augmente E cette situation est finalement très probable
dans un reseau ad hoc, o`
u beaucoup de mobiles vont devoir non seulement envoyer leurs propres
donnees, mais aussi celles dautres nuds pour lesquels ils routent des paquets.
A des fins de verification, nous avons adapte le mecanisme de la penalite à notre environnement
de mesure. Comme il netait pas possible de modifier la couche MAC directement (ce qui aurait
ete ideal, mais impossible du fait des codes sources fermes), nous avons utilise un système de
remplacement. Ce dernier, base sur le filtrage de paquets dans le noyau linux et leur retenue
temporaire dans lespace utilisateur a necessite quelques modifications dans notre algorithme, mais
a ensuite donne entière satisfaction. Dans le scenario des trois paires que nous avons reproduit une
nouvelle fois, la paire centrale pouvait enfin acceder au canal dans des proportions raisonnables.
Enfin, nous avons aussi ameliore une solution aux problèmes dequite proposee par Bensaou
et al. Par un mecanisme simple (inclu dans lacquittement ou le CTS) qui permet de prendre
en compte les communications distantes et par une meilleure stabilisation de lalgorithme, nous
proposons une solution qui donne une meilleure equite et qui permet de diminuer la perte de debit
global en bande passante.
Bilan
Linteret pour les reseaux ad hoc est recent. Les recherches dans ce domaine se sont concentrees
sur certains problèmes clefs, et en particulier sur le routage. Pour des raisons pratiques, au travers
de differents outils de simulation, ces nombreuses etudes sappuient dans leur grande majorite sur
la norme 802.11.
Loriginalite de nos travaux tient dans lapproche pragmatique que nous avons eue des reseaux
ad hoc. La pile de protocoles, du niveau physique jusquaux applications, meme si elle presente des
similitudes avec celles des mondes filaires et cellulaires, a besoin dadaptations specifiques à tous
les niveaux. La couche MAC de 802.11, de part son fonctionnement totalement distribue, sert de
fondation pour la majorite des travaux du domaine ad hoc se voulant capables de fonctionner sur
les technologies radio grand public de ce debut de millenaire. Cest donc dune manière naturelle
que notre interet sest porte sur elle et ses interactions avec les couches superieures dans le contexte
ad hoc.
De part les problèmes que nous avons souleves, nous avons montre que le choix des couches
basses et de la couche MAC en particulier etaient loin detre neutres dans les reseaux ad hoc,
et quil y avait des interdependances très fortes entre tous les niveaux de la pile de protocoles.
Ainsi, lenvironnement et les situations topologiques propres aux reseaux ad hoc conduisent `
a des
interferences physiques, qui agissent sur la couche MAC, qui elle-meme a un effet sur le fonctionnement des protocoles de routage.
Notre etude de ces phenomènes et de leur impact est novatrice dans le sens o`
u nous avons
cherche à les isoler specifiquement, plutot quà obtenir des resultats agreges o`
u les interactions
entres les couches MAC, PHY, routage, TCP et application sont entremeles et finalement peut
exploitables.
Perspectives
Un certain nombre de topologies ad hoc qui posaient problème à 802.11 ont ete mises `
a jour
dans nos travaux, mais la recherche de ces situations na pas ete exhaustive et il est tout `
a fait
possible quil en existe dautres qui soulèvent des problèmes particuliers. La recherche de lensemble
des situations problematiques, leur etude theorique et leur reconnaissance par des experiences nous
apparat donc comme un premier axe de travail dans la continuite de cette thèse ; dautant plus
que nous pouvons desormais compter sur les outils que nous avons developpes.
Les problèmes dequite forment à eux seuls un domaine de recherche. Certaines etudes theoriques
existent dejà dans la litterature, mais beaucoup de travail reste à faire, aussi bien dans la classification des definitions diverses de lequite, que dans la proposition de solutions. Le lien peut etre fait
egalement avec le point precedent : les problèmes specifiques des reseaux ad hoc (de topologie et des
interferences qui y sont liees en particulier) peuvent etre pris en compte pour definir lequite et y
proposer des solutions adaptees. Les contraintes sont cependant nombreuses, comme la distribution
de lalgorithme qui est un point capital par exemple.
Le troisième axe de recherche concerne les interactions avec les couches superieures, et le routage
en premier lieu. Dans cette thèse nous avons montre et explique un certain nombre dimpacts sur
le routage que peuvent avoir les couches basses, nous pensons quil faudrait maintenant capitaliser
ces resultats et sen servir pour repenser et adapter la manière de router dans un reseau ad hoc.
Dans le domaine des simulateurs, la realisation de couches physiques presentant les comportements
observes dans nos mesures nous semble un premier pas dans cette voie. Dans la communaute ad hoc,
les simulateurs ont un impact très important sur la conception des protocoles de routage. Au del`
a
du routage, les interactions avec TCP meriteraient egalement detre revisitees, les performances
de TCP etant passablement mauvaises, aussi bien dans les simulations actuelles de reseaux ad
hoc (pourtant etonnamment optimistes, comme nous lavons souligne) que dans les rares mesures
reelles.
Liste des acronymes

ACK
AP
ACKnowledgment
Access Point
BEB
BPSK
BS
BSA
BSS
Binary Exponential Backoff

Binary Phase Shift Keying
Base Station
Basic Service Area
Basic Service Set
CA
CBR
CCK
CD
CDMA
CFP
CP
CRC
CSMA
CTS
CW
Collision Avoidance
Constant Bit Rate
Complementary Code Keying
Collision Detection
Code Division Multiple Access
Contention Free Period
Contention Period
Cyclic Redundancy Check
Carrier Sense Multiple Access
Clear To Send
Contention Windows
DARPA
DCF
DIFS
DSSS
Defense Advanced Research Projects

Distributed Coordination Fonction
DCF Inter Frame Spacing
Direct Sequence Spread Spectrum
ETSI
European Telecommmunications Standards Institute
FDD
FHSS
Frequency Division Duplex

Frequency Hopping Spread Spectrum
GPS
Global Positioning System
HiperLAN
High Performance European Radio LAN
147
IEEE
IETF
IFS
IP
IR
ISM
IV
Institute of Electrical and Electronics Engineers

Internet Engineering Task Force
Inter Frame Spacing
Internet Protocol
Infra-Red
Industry, Scientific and Medical
Initialisation Vector
LAN
LLC
Local Area Network

Logical Link Control
MAC
MANET
Medium Access Control

Mobile Ad hoc NETwork
NAV
NS
Network Allocation Vector

Network Simulator
OFDM
OSI
Orthogonal Frequency Division Multiplexing

Open System Interconnection
PCF
PIFS
PRNET
Point Coordination Fonction

Polling IFS
Packet Radio Network
QoS
QPSK
Quality of Service
Quadrature Phase Shift Keying
RTS
Request To Send
SIFS
Short IFS
TCP
TDD
TDMA
Transport Control Protocol

Time Division Duplex
Time Division Multiple Access
UDP
UN-II
User Datagram Protocol

Unlicensed National Information Infrastructure
WEP
Wired Equivalent Privacy
148
Bibliographie
[1] James A. Freebersyser and Barry Leiner. Ad-hoc networking, chapter A DoD Perspective on Mobile Ad
Hoc Networks in Charles E. Perkins Ad-hoc networking. London, Addison Wesley, 2000.
[2] The IETF Mobile Ad hoc NETworks working group [en ligne].
Disponible sur
http ://www.ietf.org/html.charters/manet-charter.html (consulte le 5/12/2003).
[3] D. Dhoutaut and I. Guerin-Lassous. Impact of heavy trafic beyond communication range in multi-hops
ad-hoc networks. In Proceedings of International Network Conference 2002. University of Plymouth,
UK, 2002.
[4] D. Dhoutaut and I. Guerin-Lassous. Experiments with 802.11 in ad-hoc configurations. In 14th IEEE
International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2003), Beijing, China, pages 16181622, september 2003.
[5] D. Dhoutaut and I. Guerin-Lassous. Impact dun fort trafic en dehors de la zone de communication
dans une reseau ad-hoc multi-sauts. In Proceedings of ALGOTEL 2002, Mèze, France, pages 147153,
mai 2002.
[6] D. Dhoutaut and I. Guerin-Lassous. Experimentations avec 802.11 dans des configurations ad-hoc. In
Proceedings of ALGOTEL 2003, Banyuls sur mer, France, mai 2003.
[7] D. Dhoutaut and D. Laiymani. A corba-based architecture for parallel applications : experimentations
with the wz matrix factorization. In Proceedings of the first IEEE/ACM Internatianol Symposium on
Cluster Computing and the Grid, Brisbane, Asutralia, pages 442449, 2001.
[8] D. Dhoutaut and D. Laiymani. A corba-based architecture for parallel applications : experimentations
with the wz matrix factorization. ACM SigApp, Applied Computing Review, 10(1), 2002. to appear.
[9] S. Corson. RFC 2501, Mobile Ad hoc Networking (MANET) : Routing Protocol Performance Issues
and Evaluation Considerations.
[10] Gavin Holland and Nitin H. Vaidya. Analysis of TCP performance over mobile ad hoc networks. In
Mobile Computing and Networking, pages 219230, 1999.
[11] Saverio Mascolo, Claudio Casetti, Mario Gerla, M. Y. Sanadidi, and Ren Wang. TCP westwood :
Bandwidth estimation for enhanced transport over wireless links. In Mobile Computing and Networking,
pages 287297, 2001.
[12] Vesa Karpijoki. Security in Ad Hoc Networks. In Proceedings of the Helsinki University of Technology,
2000. seminar on network security.
[13] Janne Lundberg. Routing Security in Ad Hoc Networks. citeseer.nj.nec.com/400961.html.
[14] Shigang Chen and Klara Nahrstedt. A distributed quality-of-service routing in ad-hoc networks. IEEE
Journal on Selected Areas in Communications, 17(8), August 1999.
[15] Claude Chaudet and Isabelle Guerin Lassous. Bruit : Bandwidth reservation under interferences influence. In European Wireless 2002 (EW2002), pages pp. 466472, Florence, Italy, February 2002.
[16] S. Das C. Perkins, E. Belding-Royer. RFC 3561, Ad hoc On-Demand Distance Vector (AODV)
Routing [en ligne], 2003. Memo. The Internet Society. Disponible sur : ftp ://ftp.rfc-editor.org/innotes/rfc3561.txt (consulte le 5/12/2003).
149
BIBLIOGRAPHIE
[17] Yih-Chun Hu David B. Johnson, David A. Maltz. The Dynamic Source Routing Protocol for Mobile
Ad Hoc Networks (DSR) (draft IETF), 2003.
[18] Philippe Jacquet Thomas Clausen. RFC 3626, Optimized Link State Routing Protocol (OLSR), 2003.
[19] M. Lewis R. Ogier, F. Templin. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(draft IETF), 2003.
[20] E. Royer and C. Toh. A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks.
In IEEE Personal Communications., April 1999.
[21] C. Chiang, H. Wu, W. Liu, and M. Gerla. Routing in Clustered Multihop, Mobile Wireless Networks.
In Mobile Wireless Networks, The IEEE Singapore International Conference on Networks, 1997.
[22] Vincent D. Park and M. Scott Corson. A Highly Adaptive Distributed Routing Algorithm for Mobile
Wireless Networks. In INFOCOM (3), pages 14051413, 1997.
[23] S. Giordano, I. Stojmenovic, and L. Blazevie. Position based routing algorithms for ad hoc networks :
a taxonomy, July 2001. http : / /www.site.uottawa.ca/-ivan/routing-survey.pdf.
[24] D. Camara and A.F. Loureiro. A novel routing algorithm for ad hoc networks. In Proc. HICSS, Hawaii,
2000.
[25] C-K Toh. A Novel Distributed Routing Protocol To Support Ad-Hoc Mobile Computing. In IEEE 15th
Annual Intl. Phoenix Conf. Comp. and Commun, 1996.
[26] R. Dube, C. Rais, K. Wang, and S. Tripathi. Signal stability based adaptive routing (SSA) for ad hoc
mobile networks. In Signal stability based adaptive routing (SSA) for ad hoc mobile networks, IEEE
Personal Communication., february 1997.
[27] I. Kang and R.Poovendran. On Lifetime Extension and Route Stabilization of Energy-Efficient Broadcast Routing over MANET. In Proceedings of INC 2002, Plymouth, 2002.
[28] ETS 300 652 High Performance Radio Local Area Network (HiperLAN) type 1 - Functionnal Specification.
[29] ETS 101 475, ETS 101 761, ETS 101 762, ETS 101 493, ETS 101 763 : High Performance Radio Local
Area Network (HiperLAN) type 2.
[30] Bluetooth, http ://www.bluetooth.com.
[31] IEEE Computer Society LAN MAN Standard Committee. Wireless Lan Media Access Control (MAC)
and Physical Layer (PHY) Specifications, 1999.
[32] M
uhlethaler Paul. 802.11 et les reseaux sans fil. Paris, Eyrolles, 2002. 281 p.
[33] P. Karn. MACA - a new channel access method for packet radio. In ARRL/CRRL Amateur Radio 9th
Computer Networking Conference, pages 134140, 1990.
[34] Ronald L. Rivest. Rc4. Dans Bruce Schneier, Cryptographie Appliquee : protocoles, algorithmes et
codes source en C. 2e ed. Paris : Vuibert, 2001, page 419-420.
[35] Jangeun Jun, Pushkin Peddabachagari, and Mihail L. Sichitiu. Theoretical Maximum Throughput
of IEEE 802.11 and its Applications. In Proceedings of IEEE International Symposium on network
communications, 2003. Cambridge, MA, pp. 249-256.
[36] W. Moh, D. Yao, and K. Makki. Wireless LAN : Study of hidden terminal effect and multimedia
support. In Proceeding of Computer Communications and Networks, October 1998. Lafayette, LA.
[37] Amir Qayyum. Analysis and Evaluation of channel access schemes and routing protocols in wireless
LAN. PhD thesis, Universite de Paris-Sud, 2000.
[38] Y. Wang and B. Bensaou. Achieving Fairness in IEEE 802.11 DFWMAC with Variable Packet Lengths.
In IEEE Global Telecommunications Conference (GLOBECOM) 2001, pages 2529, San Antonio, Texas,
U.S.A, November 2001.
[39] C-K Toh. Ad hoc Mobile Wireless Networks : protocols and systems. Upper Saddle River, N.J. : Prentice
Hall, 2002. 302 p.
150
BIBLIOGRAPHIE
[40] Aravind Velayutham and Haoli Wang. Solution to the exposed node problem of 802.11 in wireless
ad-hoc networks. http ://www.cs.iastate.edu/vel/research/E-MAC.pdf.
[41] Henrik Lundgren, Erik Nordstrom, and Christian Tschudin. The gray zone problem in ieee 802.11b based ad hoc networks. In ACM SIGMOBILE Mobile Computing and Communications Review, volume 6,
pages 104105, July 2002.
[42] Martin Heusse, Frank Rousseau, Gilles Berger-Sabbatel, and Andrzej Duda. Performance Anomaly of
802.11b. In Proceedings of INFOCOM 2003, San Francisco, 2003.
[43] K. Tang and M. Gerla. Fair Sharing of MAC under TCP in Wireless Ad Hoc Networks. In Proceedings
of IEEE MMT99, Venice, Italy, October 1999.
[44] Shugong Xu and Tarek Saadawi. Does the IEEE 802.11 MAC Protocol Work Well in Multihop Wireless
Ad hoc Networks ? IEEE Communications Magazine, june 2001.
[45] J. Li, C. Blake, D. S. J. De Couto, H. I. Lee, and R. Morris. Capacity of Ad Hoc Wireless Networks.
In In the Proceedings of the 7th ACM International Conference on Mobile Computing and Networking,
Rome, Italy, July 2001.
[46] Vaduvur Bharghavan, Alan J. Demers, Scott Shenker, and Lixia Zhang. MACAW : A media access
protocol for wireless LANs. In SIGCOMM, pages 212225, 1994.
[47] T. Nandagopal, T. Kim, X. Gao, and V. Bharghavan. Achieving MAC Layer Fairness in Wireless Packet
Networks. In Proceedings of the ACM Mobicom, Boston, MA, USA, August 2000.
[48] Brahim Bensaou, Yu Wang, and Chi Chung Ko. Fair medium access in 802.11 based wireless ad-hoc
networks. In Proceedings of the 1st ACM international symposium on Mobile ad hoc networking and
computing, pages 99106. IEEE Press, 2000. Boston, Massachusetts.
[49] Network simulator 2, http ://www.isi.edu/nsnam/ns/.
[50] Opnet modeler, http ://www.mil3.com.
[51] Global
Mobile
Information
Systems
http ://pcl.cs.ucla.edu/projects/glomosim/.
Simulation
Library
(GloMoSim),
[52] Qualnet, http ://www.qualnet.com.

[53] Sung-Ju Lee, William Su, Julian Hsu, Mario Gerla, and Rajive Bagrodia. A Performance Comparison
Study of Ad Hoc Wireless Multicast Protocols. In INFOCOM (2), pages 565574, 2000.
[54] Josh Broch, David A. Maltz, David B. Johnson, Yih-Chun Hu, and Jorjeta Jetcheva. A Performance
Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols. In Mobile Computing and
Networking, pages 8597, 1998.
[55] Samir Ranjan Das, Charles E. Perkins, and Elizabeth E. Royer. Performance Comparison of Two
On-demand Routing Protocols for Ad Hoc Networks. In INFOCOM (1), pages 312, 2000.
[56] David B Johnson and David A Maltz. Dynamic Source Routing in Ad Hoc Wireless Networks. In
Imielinski and Korth, editor, Mobile Computing, volume 353. Kluwer Academic Publishers, 1996.
[57] Jungkeun Yoon, Mingyan Liu, and Brian Noble. Random Waypoint Considered Harmful, 2003.
[58] Kevin Fall and Kannan Varadhan. The NS manual, 2003. The VINT project.
[59] H.T. Friis. A note on a simple transmission formula. Proc. IRE, 34, 1946.
[60] T. S. Rappaport. Wireless communications, principles and practice. Upper Saddle River, N.J. : Prentice
Hall, 1996. 641 p.
[61] R.A. Valenzuela. Ray tracing approach to predicting indoor wireless transmission. In Proceedings of
the 43rd IEEE Vehicular Technology Conference, pages 214218, May 1993. Secaucus, NJ, USA.
[62] J.M. Gorce, E. Jullo, and K. Runser. An adaptative multi-resolution algorithm for 2D simulations of
indoor propagation. In Proceedings of the 12th International Conference on Antennas and Propagation,
Exeter, UK, April 2003. IEE.
151
BIBLIOGRAPHIE
[63] D. Maltz, J. Broch, and D. Johnson. Experiences designing and building a multi-hop wireless ad hoc
network testbed. Technical report, School of Computer Science, Carnegie Mellon University, Pittsburgh,
Pennsylvania, March 1999. Technical Report CMU-CS-99-116.
[64] D. Maltz, J. Broch, and D. Johnson. Quantitative Lessons from a Full-Scale Multi-Hop Wireless Ad
Hoc Network Testbed. In Proceedings of WCNC 2000, pages pp. 992997, September 2000. Chicago,
IL, USA.
[65] C.-K. Toh, Richard Chen, Minar Delwar, and Donald Allen. Experimenting with an ad hoc wireless
network on campus : insights and experiences. ACM SIGMETRICS Performance Evaluation Review,
28(3) :2129, 2000.
[66] S. Bae, S. Lee, and M. Gerla. Unicast Performance Analysis of the ODMRP in a Mobile Ad hoc Network Testbed. In Proceedings of the IEEE International Conference on Communications and Networks
(ICCCN), Las Vegas, 2000.
[67] Erik Nordstr
om. APE - a Large Scale Ad Hoc Network Testbed for Reproductible Performance Tests.
Masters thesis, Uppsala University, 2002.
[68] H. Lundgren, D. Lundberg, J. Nielsen, E. Nordstrom, and C. Tschudin. A large-scale testbed for reproducible ad hoc protocol evaluations. In proceedings of IEEE Wireless Communications and Networking
Conference, pages pp. 412418, March 2002. Orlando.
[69] Jean Tourrilhes. The wireless tools for linux. http ://www.hpl.hp.com/personal/Jean Tourrilhes/Linux/Tools.html.
[70] David L. Mills. Global States and Time in Distributed Systems, chapter Internet Time Synchronization :
The Network Time protocol. IEEE Computer Society Press, 1994.
[71] Jeremy Elson, Lewis Girod, and Deborah Estrin. Fine-Grained Network Time Synchronization using
Reference Broadcasts. In Proceedings of the Fifth Symposium on perating Systems Design and Implementation, Boston, MA, USA, December 2002.
[72] Anceaume Emmanuelle and Puaut Isabelle. Performance evaluation of clock synchronization algorithms.
Technical Report 1208, INRIA, 1998.
[73] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci. Wireless Sensor Networks : A Survey.
Computer Nteworks, 38(4) :393422, March 2002.
[74] Jeremy Elson and Deborah Estrin. Time Synchronization for Wireless Sensor Networks. In Proceedings of the Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile
Computing, pages 19651970, San Francisco, CA, USA, April 2001.
[75] Kay Romer. Time Synchronization in Ad Hoc Networks. In Proceedings of ACM MobiHoc, pages pp.
173182, October 2001. Long Beach, CA.
[76] Paul Russell. Linux 2.4 packet filtering howto. http ://www.netfilter.org/unreliable-guides/packetfiltering-HOWTO/packet-filtering-HOWTO.linuxdoc.html.
[77] L. Kleinrock and J. Silvester. Optimum transmission radii for packet radio networks or why six is a
magic number. In Proc. IEEE National Telecommunications Conference, 1978.
152

These

Transféré par

Informations du document

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

These

Transféré par

Droits d'auteur :

Formats disponibles

N dordre

Deputy Laboratory Manager (Hitachi, Sophia-Antipolis)

Table des mati`

6 Quelques solutions aux probl`

7 Objectifs des mesures et moyens mis en uvre

Partage du canal entre nuds `a portee de communication .

outils danalyse avanc

11 Mise en pratique du malus

Defense Advanced Research Projects Agency

Contributions et organisation du document

lInternet Engineering Task Force, http ://www.ietf.org

Fig. 1.1 lattenuation rapide du signal en fonction de la distance

Fig. 1.2 Routage `a plat

Fig. 1.3 Routage hierarchique

Les protocoles de routage hi

Etat de liens ou vecteur de distance

Description de quelques protocoles de routage repr

Fig. 1.4 Recherche de route par inondation

Fig. 1.5 Recherche de route par inondation

Fig. 1.6 Relais multipoints

Les autres normes de r

Fig. 2.1 Organisation dHiperlan 1

Fig. 2.2 Lacc`es au canal avec EY-NPMA

Couche de convergence rseau (NC)

Fig. 2.3 Lorganisation generale dHiperLAN type 2

Fig. 2.4 Un scatternet Bluetooth

Fig. 2.5 Reseau 802.11 en mode infrastructure

802.11 Logical Link Control (LLC)

Fig. 2.6 Reseau 802.11 ad-hoc

802.11 Medium Access Control (MAC)

Fig. 2.7 Les couches et sous-couches OSI definies par 802.11

Fig. 2.8 Changer de frequence

Tab. 2.1 Reglementations de la bande ISM

Fig. 2.10 Le reutilisation spatiale grace `a un plan dallocation des frequences

Fig. 2.11 Le recouvrement des canaux dans la bande ISM

Fig. 2.12 Les 8 premiers canaux definis par 802.11a

La couche MAC de 802.11 peut utiliser deux modes de fonctionnement.

Fig. 2.13 Recapitulatifs des technologies et des debits possibles

Description du mode DCF

Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA)

Fig. 2.15 Le backoff et le defering

Fig. 2.16 Un exemple de backoff exponentiel

Fig. 2.18 Lechange RTS/CTS

Fig. 2.17 Le probl`eme des nuds caches

Fig. 2.19 Le Network Allocation Vector (NAV)

Description du mode PCF

Fig. 2.21 LExtended Inter Frame Spacing

Fig. 2.20 Une configuration o`

Fig. 2.22 Lalternance des modes PCF et DCF

Squence pseudoalatoire de chiffrement

Fig. 2.23 Fonctionnement du chiffrement WEP

de la norme, et de nombreuses techniques existent, qui vont de la simple transmission de vive

Fig. 2.24 Une trame de donnees 802.11 `a 11Mbits/s et son acquittement

Les trames 802.11b et le d

debit en bits par secondes

taille des paquets (donnees UDP)

debit en bits par secondes

debit en bits par secondes

taille des paquets (donnees UDP)

DE 802.11 DANS UN CONTEXTE AD HOC

Fig. 3.1 Noeuds caches simples

Fig. 3.3 Multiples nuds caches

Fig. 3.2 Noeuds caches dans une chane

DE 802.11 DANS UN CONTEXTE AD HOC