Vous êtes sur la page 1sur 152

N d’ordre

Année 2003

Thèse

Étude du standard IEEE 802.11 dans le cadre


des réseaux ad hoc : de la simulation à
l’expérimentation.

Présentée devant
L’Institut National des Sciences Appliquées de Lyon

pour obtenir
Le grade de docteur

Par
Dominique Dhoutaut

À soutenir le 11 Décembre 2003 devant la Commission d’examen

Jury MM.
S. Amarger Deputy Laboratory Manager (Hitachi, Sophia-Antipolis)
A. Duda Professeur (ENSIMAG, Grenoble)
I. Guerin-Lassous Chargée de recherche (INRIA)
P. Jacquet Directeur de recherche (INRIA, Rocquencourt)
G. Pujolle Professeur (Université Paris VI)
F. Spies Professeur (Université de Franche-Comté)
S. Ubéda Professeur (INSA de Lyon)
Les réseaux ad-hoc sont auto-organisés et ne reposent sur aucune infrastructure fixe. Les
éléments les composant sont en général reliés par radio, potentiellement mobiles, et peuvent être
amenés à entrer ou sortir du réseau à tout moment. Ces réseaux sont caractérisés par la capacité
de chaque participant d’agir à la fois comme client et comme routeur du réseau. Si un émetteur
n’est pas à portée directe de la machine destination, les informations devront être transmises de
proche en proche, le long d’un chemin établi et maintenu par le réseau en cas de modification de
la topologie (ces réseaux sont d’ailleurs qualifiés de multi-sauts).
Le domaine des réseaux ad-hoc est vaste et récent. Un travail conséquent est actuellement
effectué dans le groupe MANET de l’IETF dans le but de normaliser un ou des protocoles de
routage pour ces réseaux. Ces travaux, ainsi que de nombreux autres portants sur des protocoles
de plus haut niveau (qualité de service, découverte de services, ...) s’appuient sur des simulations
utilisant en particulier la norme 802.11 de l’IEEE.
Mon travail porte sur l’utilisation de cette norme comme support pour les réseaux ad-hoc,
domaine pour lequel elle n’a pas été prévue à l’origine.
– Dans un premier temps, j’ai réalisé de nombreuses simulations avec le simulateur de réseaux
NS2. Elles m’ont en particulier permis de montrer que de graves problèmes d’équité au niveau
de l’accès au médium pouvaient apparaı̂tre. Dans de nombreuses situations typiques des
réseaux ad-hoc certains mobiles peuvent voir leur accès fortement réduit ; ceci a un impact
direct sur les applications, mais aussi sur les protocoles de routages eux mêmes, et risque de
provoquer un effondrement du réseau.
– J’ai donc travaillé à la compréhension et l’analyse de ces problèmes mis en lumière par la
simulation. En sus de problèmes déjà largement étudiés dans la littérature (par exemple les
nœuds cachés), le fait que dans un réseau ad-hoc des mobiles puissent se gêner les uns les
autres sans pour autant avoir de moyen de communiquer apporte de nombreuses contraintes
supplémentaires. L’étude (par la théorie et la simulation) de ces contraintes et de leurs in-
teractions avec certains mécanismes prévus par la norme 802.11 m’ont logiquement amené a
proposer des solutions aux problèmes d’équité. Certaines solutions s’affranchissent de toute
communication entre les mobiles se gênant potentiellement. D’autres solutions essaient de
tirer parti d’une connaissance d’une région plus étendue que le voisinage direct pour obtenir
des résultats s’approchant de l’idéal.
– Mais au fur et à mesure que ma compréhension de la norme 802.11 et des phénomènes liés à son
utilisation dans les réseaux ad-hoc s’étoffait, il m’est apparu que la réalité était plus complexe.
En environnement réel, des phénomènes physiques non présents dans les simulations entrent
en jeu. Afin de mieux les cerner, et afin de mieux savoir ce qu’il est possible d’attendre de la
norme 802.11 dans notre contexte, j’ai donc mené de nombreuses expérimentations à l’aide
d’outils que j’ai développés. Dans un premier temps, ces mesures ont porté sur des scénarios
simples permettant d’extraire les caractéristiques principales de 802.11. Ces mesures ont ainsi
permis de mettre en lumière des problèmes jusqu’alors présentés de façon théorique par la
communauté (par exemple le problème des ”zones grise”), mais également d’autres jusqu’alors
ignorés ou non pris en compte.
– Dans un deuxième temps, j’ai mené des expérimentations sur des scénarios plus complexes
et typiques des réseaux ad-hoc (sauts multiples, interférences entres mobiles ne pouvant pas
communiquer entre eux,...). Ces expérimentations ont d’une part confirmé les problèmes sou-
levés par certaines simulations, et d’autre part m’ont permis d’implémenter, de tester et de
valider les solutions aux problèmes d’équité que j’avais proposées précédemment.
Table des matières

1 Les réseaux ad hoc 10


1.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Problèmes et contraintes spécifiques des réseaux radio . . . . . . . . . . . . . . . . . 10
1.3 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Routage hiérarchique ou plat . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2 Etat de liens ou vecteur de distance . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.3 Les différentes familles de protocoles de routage MANET . . . . . . . . . . . 15
1.3.4 Description de quelques protocoles de routage représentatifs . . . . . . . . . . 16

2 Présentation de 802.11 20
2.1 Les autres normes de réseaux locaux sans fil. . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 HiperLAN 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 HiperLAN 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Introduction à 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 La couche physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 La couche MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1 Description du mode DCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.2 Description du mode PCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 La sécurité des informations : la Wired Equivalent Privacy (WEP) . . . . . . . . . . 34
2.6 Les trames 802.11b et le débit utile 802.11b . . . . . . . . . . . . . . . . . . . . . . . 36

3 Particularités de 802.11 dans un contexte ad hoc 40


3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Le problème des nœuds cachés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Le problème des nœuds exposés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Le problème de la zone grise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5 Partage du canal entre des flux à vitesses différentes . . . . . . . . . . . . . . . . . . 43
3.6 TCP et 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7 Capacité théorique en fonction la topologie (grille, chaı̂ne) . . . . . . . . . . . . . . . 44
3.8 Equité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Conclusion et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3
I Simulations logicielles de réseaux ad-hoc 46

4 Simulations : introduction et scénarios de prise en main 47


4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Objectifs initiaux des simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Présentation de Network Simulator 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Les différents modèles de propagation radio sous NS2 . . . . . . . . . . . . . 49
4.3.2 La gestion des interférences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Traitements des résultats et outils d’analyse . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Prise en mains et premières simulations . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.1 Portée de communication et débit . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.2 Interférences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Scénarios ”avancés” 60
5.1 Introduction et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Trois paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Sauts multiples en configuration de chaı̂ne . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 La chaı̂ne fixe et la paire de perturbateurs . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5 Le problème de l’asymétrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.6 Conclusion sur ces simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Quelques solutions aux problèmes d’équité dans les réseaux ad hoc 72


6.1 Une solution historique et locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Une solution étendue géographiquement . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.1 Point de départ et algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.2 Quelques résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

II Expérimentations en environnement réel 83

7 Objectifs des mesures et moyens mis en œuvre 84


7.1 Introduction et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2 Les environnements de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.1 Travaux antérieurs basés sur des mesures . . . . . . . . . . . . . . . . . . . . 85
7.2.2 Ad hoc Protocol Evaluation (APE) . . . . . . . . . . . . . . . . . . . . . . . . 85
7.3 Description de l’outil forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.3.1 Architecture du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3.2 Format des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.3.3 Les commandes disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8 Les premières mesures 92


8.1 Justifications des données mesurées. . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.2 Le débit en fonction de la taille des paquets . . . . . . . . . . . . . . . . . . . . . . . 92
8.2.1 La fragmentation à 1500 octets . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2.2 L’impact du WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2.3 Hormis les problèmes pré-cités, des débits très proches de la théorie . . . . . 95
8.3 Partage du canal entre nœuds à portée de communication . . . . . . . . . . . . . . . 96
8.3.1 Deux flux (combinaisons d’émetteurs et récepteurs) . . . . . . . . . . . . . . . 96
8.3.2 Flux multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.4 Les mesures de portée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.4.1 L’environnement et le outils de mesure . . . . . . . . . . . . . . . . . . . . . . 99
8.4.2 Les résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

9 Les outils d’analyse avancée 104


9.1 Les chronogrammes en environnement réel . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2 Le problème de la synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3 Résolution du problème de la synchronisation . . . . . . . . . . . . . . . . . . . . . . 107
9.3.1 Les différentes approches, les systèmes existants . . . . . . . . . . . . . . . . . 107
9.3.2 Premières constatations et méthode simple . . . . . . . . . . . . . . . . . . . 109
9.3.3 Deuxième méthode : approximation de la dérive des horloges par une droite
affine par morceaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.3.4 Troisième méthode : le pèlerin synchronisateur . . . . . . . . . . . . . . . . . 114

10 Les scénarios ”avancés” 117


10.1 Les deux paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.2 Les trois paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3 La chaı̂ne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3.1 Le scénario, les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3.2 Le déploiement et le déroulement de l’expérience . . . . . . . . . . . . . . . . 122
10.3.3 Les résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

11 Mise en pratique du malus 134


11.1 Choix de l’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5
Introduction

Point de départ et sujet de thèse


A l’heure où les communications téléphoniques sans fil se sont imposées de façon indéniable,
et où les réseaux locaux radio connaissent un essor fulgurant, de nouvelles applications de ces
technologies apparaissent sans cesse. Ces sont les militaires qui ont été les premiers intéressés par
des technologies de communication radio fonctionnant de proche en proche et restant fonctionnelles
en cas de mobilité ou de perte de certains éléments routeurs. Dans [1], on apprend que dès le début
des années 1970, les techniques de commutation de paquets ont inspiré le développement par le
DARPA1 des Packet Radio Network (PRNET). Ces réseaux disposaient déjà d’une architecture
distribuée, partageaient dynamiquement le canal de diffusion par une combinaison des protocoles
Aloha et CSMA, et se servaient de la répétition des paquets pour élargir la zone de couverture
globale. Par la suite, en 1983, les Survivable Radio Networks (SURAN) furent développés par
le DARPA. L’objectif était de passer outre les principales limitations des PRNet (en particulier
permettre le passage à des réseaux comportant énormément de nœuds, gérant la sécurité, gérant
l’énergie, et offrant des capacités de calcul suffisantes pour supporter des protocoles évolués). Mais
les recherches sur ces réseaux restaient exclusivement militaires. Les applications civiles de ces
réseaux appelés ad hoc n’apparurent que beaucoup plus tard, vers la fin des années 1990. Parmi les
applications actuellement les plus en vogue destinées aux réseaux ad hoc, en sus de celles à usage
militaire, on peut citer par exemple :
– le déploiement de réseaux dans des environnements où les infrastructures fixes ne sont plus
opérationnelles (sur les lieux de catastrophes naturelles ou autres) ;
– le déploiement de réseaux de capteurs dans des environnements hostiles ou difficiles d’accès.
Un tel réseau s’auto-configure en fonction des ressources énergétiques restantes et de la dis-
tribution géographique des nœuds (disséminations initiale par largage par exemple, qui les
place de manière assez aléatoire) ;
– l’extension de réseaux dotés d’infrastructures : lorsqu’un 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 intermédiaires pour les atteindre et ainsi se rattacher à
l’ensemble du réseau.
Ces recherches sur les réseaux ad hoc dans le domaine civil n’ont en fait véritablement pris
leur essor qu’avec l’arrivée des premières technologies radio bon marché : principalement la norme
IEEE2 802.11 et ses diverses extensions. La norme 802.11 est conçue avant tout pour bâtir des
réseaux autour d’une infrastructure fixe de bornes radio reliées entre elles par un réseau câblé.
1
Defense Advanced Research Projects Agency
2
Institute of Electrical and Electronics Engineers, http ://www.ieee.org

6
Mais la méthode d’accès au canal qu’elle propose par défaut fonctionne de manière totalement
distribuée, c’est la Distributed Coordination Function (DCF). Cette dernière, alliée au coût modéré
des équipements, a joué un rôle primordial pour l’utilisation de 802.11 dans un contexte ad hoc.
Elle peut en effet être utilisée directement et laisse les chercheurs se concentrer sur les couches
supérieures.
Ces recherches se sont cristallisées en particulier sous la forme d’un groupe de travail à
l’IETF3 : le groupe MANET (Mobile Ad hoc NETworks [2]). Les problématiques de ce type de
réseaux sont nombreuses et substantiellement différentes de celles des mondes filaire ou même
cellulaire (pas d’infrastructure fixe ni même d’assurance d’avoir des voisins, mobilité possible de
tous les éléments et donc absence de plan d’allocation géographique des fréquences, etc.). Le
groupe MANET travaille essentiellement à l’élaboration de protocoles de routage adaptés (lorsque
l’on cherche à communiquer avec un mobile qui n’est pas à portée directe, il va falloir être capable
de trouver des mobiles intermédiaires qui vont relayer le message). Mais les couches les plus basses
(physique et d’accès au médium) aussi bien que les couches plus élevées (jusqu’aux applications)
nécessitent elles aussi des retouches plus ou moins importantes. Par exemple, l’absence d’éléments
fixes empêche de centraliser certaines tâche, et rend l’utilisation de méthodes d’accès au canal
telles que TDMA (Time Division Multiple Access) ardues. De même, puisque le réseau peut parfois
se partitionner, les applications n’ont pas toujours accès aux mêmes ressources, et doivent donc
utiliser des caches ou prendre toutes autres mesures qu’elles jugent utiles pour fournir un service
le moins dégradé possible.

De part sa diffusion et son faible coût, 802.11 sert de support à de très nombreux travaux dans
le domaine des réseaux ad hoc (que ce soit au niveau du routage, de la qualité de service ou encore
des applications). Mais cette norme n’a néanmoins pas été conçue pour ce type d’utilisation puisque
les réseaux à stations de base sont le contexte qu’elle cible réellement. Il apparaı̂t que certains de
ses comportements dans un cadre purement ad hoc ne sont finalement pas bien connus. C’est à
l’étude de ces comportements et leurs interactions avec les couches supérieures qu’est vouée cette
thèse.

Contributions et organisation du document


Nos travaux se situent au niveau de l’interaction entre les protocoles spécifiques des réseaux
ad hoc et les couches MAC (Medium Access Control) et physique sur lesquelles ils s’appuient.
Le chapitre 1 introduit les réseaux ad hoc et le chapitre 2 présente la norme 802.11. Pour
les réseaux ad hoc, les différentes familles de protocoles de routage sont présentées, accom-
pagnées d’un certains nombre d’exemples détaillés qui nous permettront par la suite de mieux
comprendre les effets qu’auront sur chacun d’entre eux les comportement des couches basses
utilisées dans un contexte ad hoc. La norme IEEE 802.11 quant à elle n’est bien sûr pas
complètement détaillée, mais les parties significatives et importantes pour notre travail le sont.
Il s’agit, en sus d’un aperçu des techniques utilisées par la couche physique radio, de tout ce
qui concerne la gestion distribuée de l’accès au canal radio, ainsi que certains points précis,
comme la gestion de la cryptographie ainsi que certaines particularités des extensions de 802.11
(802.11b notamment, qui introduit des débits plus élevés mais qui dispose d’aménagements pour
maintenir la compatibilité dont nous devront tenir compte plus tard). Le chapitre 3 quant à lui
3
l’Internet Engineering Task Force, http ://www.ietf.org

7
détaille les contraintes et particularités de l’utilisation de 802.11 dans un contexte purement ad hoc.

Notre contribution se présente 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 cherché à mettre en lumière certains problèmes bien spécifiques liés à l’utilisation de
802.11 dans un contexte ad hoc. Cette étude commence par une prise en main de l’outil de simulation
et la réalisation de scénarios simples mais néanmoins nécessaires, puis passe à des scénarios plus
spécifiques. Les conditions d’utilisation des réseaux ad hoc qui ont attiré notre attention sont celles
où le réseau est régulièrement traversé par des flux importants ; ces conditions nous semble en
effet hautement probables dans des réseaux utilisés pour accéder au web, transférer des fichiers ou
encore consulter des messageries. A travers quelques scénarios très caractéristiques (une chaı̂ne de
mobiles, une chaı̂ne et un couple de nœuds perturbateurs, trois paires de mobiles situés à diverses
distances), nous mettons en lumière des problèmes d’équité de l’accès au canal. Il apparaı̂t que dans
des situations malheureusement très communes dans des réseau ad hoc, certains mobiles peuvent
se trouver dans l’incapacité d’émettre, et cela du simple fait de l’activité combinée de certains de
leurs voisins.
A l’aide de divers outils, dont un système de visualisation produisant des chronogrammes
détaillés, nous analysons alors le problème et montrons qu’il trouve sa source dans le mécanisme
d’accès au médium de 802.11. Il n’a en effet pas été prévu pour fonctionner dans des situations
où, dans un ensemble de mobiles voisins, certains d’entre eux rencontrent plus de contention que
d’autres. Nous montrons également que le mécanisme EIFS de 802.11, conçu pour réduire les
chances de collision, est dans cette situation dommageable et amplifie les inégalité face à l’accès au
canal. Nous expliquons alors quels sont les effets sur les protocoles de niveau supérieur. Les pro-
tocoles de routages pâtissent en particulier des interruptions prolongées de communication que ces
problèmes déclenchent, les liens vont leur apparaı̂tre plus instables et ils vont consommer beaucoup
de ressources pour maintenir leurs tables de routage à jour.
Après avoir détaillé pourquoi certains sacrifices devraient nécessairement être faits pour réduire
ces problèmes, nous y proposons dans le chapitre 6 deux solutions. La première est basée sur
une pénalité. Cette pénalité est appliquée d’une manière particulière aux mobiles qui bloquent
leurs voisins en émettant trop et donne des résultats encourageants. Nous présentons ensuite une
seconde méthode, dans laquelle les mobiles diffusent des informations sur l’occupation du canal
perçue localement. Avec les informations transmises par leurs voisins, les nœuds cherchent à se
comporter de manière plus équitable. Des résultats intéressants seront également obtenus avec
cette technique.

Par des mesures réelles. Dans le chapitre 7, après en avoir justifié le choix face à des solutions
existantes, nous présentons le logiciel forwarding que nous avons écrit dans le but de faciliter la
réalisation d’expériences sur de véritables réseaux multi-sauts.
Dans le chapitre 8 nous utilisons forwarding pour vérifier que certains comportements prévus
par la simulation et le calcul se transposent effectivement dans la réalité. Il s’agit en particulier de
mesures sur les débits possibles en fonction de la taille des paquets, de l’effet de la cryptographie
WEP (Wired Equivalent Privacy), et de divers phénomènes lorsque le canal doit être partagé entre
un certain nombre de mobiles à portée de communication.

8
Dans le même chapitre, nous soulignons ensuite les limites des modèles utilisés dans les simula-
tions. En particulier, l’absence de gestion des débits multiples utilisés par 802.11 pour ses paquets
de contrôle et les données ainsi que la forme de la zone de couverture. Sous les simulateurs, les
modèles de propagation couramment utilisés (free-space, two-ray ground et shadowing) conduisent
à des zones de couverture circulaires centrées sur le mobile émetteur. Par des séries de mesures à
différentes distances, vitesses de transmission et orientations des cartes radio, nous montrons que
la réalité est bien différente. Nous fournissons des graphiques nous permettant d’estimer la portée
de communication des cartes en fonction des positions respectives des émetteurs et récepteurs. Ces
mêmes graphiques nous servent également à montrer l’effet des interférences qui se traduit par une
instabilité des liens, même en l’absence de mobilité.
Par des mesures en environnement réel à l’aide du logiciel que nous avons développé, nous
confirmons les problèmes mentionnés dans le premier point et en soulevons d’autres.

Par une analyse avancée des résultats des mesures. Les métriques habituellement utilisées
pour mesurer les performances des réseaux (débits, taux de perte, délais, ...) ont rapidement montré
leurs limites dans l’aide à la compréhension des phénomènes issus de l’utilisation des couches PHY et
MAC de 802.11 dans un contexte multi-sauts. La réalisation de chronogrammes précis s’était révélée
très utile lors de l’analyse des résultats de simulation. Aussi, dans le chapitre 9, nous présentons
une méthode qui permet de réaliser de tels graphiques à partir d’expériences réelles. Les problèmes
principaux lors du passage de la simulation à l’expérimentation sont essentiellement liés à l’absence
d’horloge globale et à une dérive trop rapide des horloges locales des mobiles. Une étude de cette
dérive est présentée et un mécanisme permettant d’en corriger les effets est proposée.
Dans le chapitre 10 nous réalisons des expériences mettant en œuvre des scénarios typiquement
ad hoc. Il s’agira de deux paires s’éloignant l’une de l’autre, du scénario des trois paires déjà étudié
par simulation et enfin d’une configuration de chaı̂ne. Les résultats de ces expériences confirmeront
les problèmes d’équité de l’accès au canal et la nécessité de mieux prendre en compte les couches
basses lors de la conception des protocoles de routage ad hoc.
Disposant alors de tous les outils nécessaires, nous implémentons dans le chapitre 11 le
mécanisme de pénalité décrit dans le chapitre 4. Certaines adaptations sont cependant nécessaires,
du fait de l’impossibilité de modifier la couche MAC, celle-ci étant codée dans une mémoire
embarquée sur les cartes réseau radio et non modifiable (il nous était tout du moins impossible
d’avoir accès à ses codes source qui ne sont pas ouverts). Les résultats encourageants obtenus sont
alors commentés et ouvrent des pistes pour des mécanismes plus élaborés et plus efficaces.

Cette thèse constitue un travail de trois ans qui a été réalisé au sein du LIP puis du CITI,
Isabelle Guerin-Lassous en a assuré l’encadrement au jour le jour durant toute la durée. Certains
des travaux présentés ici sont encore en cours, d’autres ont déjà fait l’objet de publications dans
des conférences internationales ([3, 4]) ou nationales ([5, 6]). Notons également la présentation de
certaines parties sous forme de poster à MS3G 2001, et la finalisation lors du début de la thèse de
[7, 8] qui concluaient des travaux effectués en DEA.

9
CHAPITRE
Les réseaux ad hoc
1
1.1 Objectifs
Les réseaux ad hoc auxquels nous nous sommes intéressés sont ceux décrits et étudiés par
le groupe de travail Mobile Ad-hoc NETworks (MANET) de l’Internet Engineering Task Force
(IETF). Une définition de ces réseaux est donnée formellement dans la RFC 2501 [9]. Il s’agit de
réseaux sans fil et sans infrastructure fixe, utilisant généralement le médium radio, et où chaque
nœud peut combiner les rôles de client et de routeur. Les réseaux ad-hoc sont auto-organisés, ce
qui implique que la connectivité doit être préservée autant que possible automatiquement lorsque
la topologie du réseau change (suite à l’apparition, la disparition ou au mouvement de certains
nœuds). Les premiers travaux sur ce type de réseaux ont été effectués dans une optique militaire
(la capacité à se reconfigurer et à rester opérationnel en cas de perte de certains mobiles étant
un avantage considérable) ; mais leur champ d’application est beaucoup plus vaste. Par exemple,
ces réseaux faciles à déployer peuvent être particulièrement utiles pour rétablir les communications
lorsque des catastrophes ont détruit les installations fixes existantes, on encore lorsque l’on désire
déployer un réseau de capteurs dans certains environnements hostiles.

1.2 Problèmes et contraintes spécifiques des réseaux radio


De par la nature du canal radio, un certain nombre de problèmes se posent qui ne trouvent pas
d’équivalent dans le monde filaire. On peut citer en particulier :
– Un débit plus faible par rapport à un équivalent filaire. Il faut donc que la gestion du
réseau occupe une part la plus réduite possible des maigres ressources en bande passante.
– Une atténuation rapide du signal en fonction de la distance (bien plus rapide que sur un
câble) qui induit l’impossibilité pour un émetteur de détecter une collision au moment même
où il transmet. Dans un réseau filaire, un émetteur sait qu’il y a collision quand le signal
qu’il lit sur le câble est différent de celui qu’il cherche à émettre. Dans un réseau radio, un
signal venant d’un autre nœud est tellement atténué par la distance qu’il ne provoquera que
des perturbations négligeables par rapport au signal émis localement. Par exemple, sur la
figure 1.1, au niveau du nœud B, le signal émis par B lui-même est de très loin supérieur à
celui qu’il reçoit du nœud A. Par conséquent, le signal du nœud A est complètement ignoré
par B qui croit qu’il n’y a pas de collision. Malheureusement, au niveau du nœud C, les deux
signaux ont des puissances comparables et il y a bien collision du point de vue du récepteur.
Seul un système d’acquittement peut garantir la bonne réception d’un message dans ce type
de contexte. Cette incapacité à détecter un signal étranger lorsque l’on émet nous-même rend

10
CHAPITRE 1. LES RÉSEAUX AD HOC

D
B
A

Fig. 1.1 – l’attenuation rapide du signal en fonction de la distance

donc le médium radio half-duplex, ce qui signifie que l’on ne peut pas émettre et recevoir en
même temps.
– Les interférences. Les liens radios ne sont pas isolés, et le nombre de canaux disponibles
est limité. Il faut donc se les partager. Les interférences peuvent être de natures diverses.
Par exemple, des émetteurs travaillant à des fréquences trop proches peuvent interférer
entre eux. L’environnement lui-même peut également produire des bruits parasites (certains
équipements électriques, certains moteurs, ...) qui interfèrent avec les communications. L’envi-
ronnement peut aussi déformer le signal et le rendre rapidement incompréhensible à cause des
phénomènes d’atténuation, de réflexion ou de chemins multiples (l’atténuation et la réflexion
varient en fonction des matériaux rencontrés ; le problème des chemins multiples apparaı̂t
lorsque des réflexions d’une même onde par des chemins différents arrivent de manière décalée
dans le temps au récepteur, se chevauchent, et forment un tout plus difficile à analyser). Ces
problèmes font que les taux d’erreurs de transmission dans les réseaux radio sont nettement
plus élevés que dans les réseaux filaires. Cela a un impact non négligeable sur les protocoles
de niveau supérieur. TCP en particulier va y être particulièrement vulnérable, car il va in-
terpréter les pertes de paquets comme étant dues à de la congestion sur le réseau. Quand TCP
détecte de la congestion, il cherche à l’atténuer en réduisant la taille de sa fenêtre d’émission
[10]. Malheureusement, dans le cas présent, c’est exactement l’inverse qu’il faudrait faire, les
paquets perdus doivent être ré-émis 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
gérant différemment la réduction de la taille de sa fenêtre.
Il faut ajouter également que des interférences ou des changements persistants dans l’envi-
ronnement vont conduire à une grande versatilité des liens, qui peuvent apparaı̂tre ou être
coupés de manière durable à tout moment.
– La puissance du signal. Non seulement elle est rapidement atténuée avec la distance, mais
elle est également limitée par des réglementations très strictes. Un émetteur ne peut donc
dépasser une certaine puissance à l’émission.
– L’energie. Les applications relatives aux réseaux sans fil ont en général un caractère nomade
et tirent leur autonomie de batteries. Emettre ou recevoir des données consomme de l’énergie
et l’on peut chercher à l’économiser en optimisant les protocoles de gestion du réseau. La
puissance d’émission a un impact important sur la quantité d’énergie utilisée et là encore on
essaie si possible de la limiter à ce qui est strictement nécessaire.
– Une faible sécurité. Il est facile ”d’espionner” un canal radio de manière passive. Les
protections ne pouvant pas se faire de manière physique (il est en général difficile d’empêcher
quelqu’un de placer discrètement une antenne réceptrice très sensible dans le voisinage), elle
devront être mises en place de manière logique, avec de la cryptographie ou éventuellement

11
CHAPITRE 1. LES RÉSEAUX AD HOC

des antennes très directionnelles. Mais le canal radio restera quoiqu’il en soit vulnérable à un
brouillage massif (attaque de type denial of service).
– La mobilité. De nombreuses applications des réseaux radio concernent des mobiles qui,
comme leur nom l’indique, sont amenés à se déplacer. Ceci va conduire à des changements
plus ou moins rapides de la topologie. Pour les gérer, des protocoles appropriés vont être
nécessaires.
Nous avons vu que le full-duplex était rendu impossible par l’atténuation trop rapide des signaux
en fonction de la distance. Pour pouvoir travailler sur un canal half-duplex, les communications
peuvent être multiplexées en temps (TDD : Time Division Duplex). En TDD, un nœud peut
transmettre durant certains slots et recevoir durant d’autres slots dans la même bande de fréquences.
Quand les débits deviennent très importants, le temps de passage d’un mode à l’autre devient
cependant non négligeable. Le multiplexage FDD (Frequency Division Duplex) permet quant à lui
d’émettre et de recevoir en même temps car on travaille alors sur plusieurs fréquences différentes.
Mais les équipements nécessaires sont plus complexes.
Dans les réseaux ad hoc, certaines des contraintes présentées précédemment sont accentuées et
d’autres apparaissent en supplément :
– L’impossibilité de mettre en place un plan d’allocation des fréquences limite la
réutilisation spatiale. Dans les réseaux radio utilisant des stations de base, on cherche à
attribuer des fréquences différentes aux stations voisines, évitant que les cellules ainsi créées
n’interfèrent entre elles. Dans les réseaux ad hoc, pour garantir la connectivité, comme il n’y
a pas d’infrastructure fixe et que tous les nœuds sont susceptibles de bouger ou de disparaı̂tre,
il est plus simple et moins coûteux de travailler avec une seule fréquence. On utilise alors un
multiplexage TDD. La réutilisation spatiale reste possible, mais un nœud qui émet empêche
l’accès au canal radio par tous les mobiles se trouvant dans un voisinage étendu autour de
lui.
– L’energie. Dans un réseau à stations de base, les dites stations sont en général alimentées sur
le secteur. Dans un réseau ad-hoc ces stations sont absentes. De plus, suivant la topologie du
réseau, certains mobiles peuvent se trouver dans des positions clef et assurer le routage pour
un grand nombre de flux (entre plusieurs sous-parties du réseau autrement indépendantes par
exemple). Ces nœuds peuvent être amenés à consommer très vite leurs ressources énergétiques.
Le trafic de contrôle peut également avoir un impact important. Comme un réseau ad-hoc
doit s’auto-organiser, cela signifie que d’une manière ou d’une autre il va y avoir un tra-
fic de contrôle dépendant de la mobilité dans le réseau. Plus la topologie changera vite et
profondément, plus la charge (et donc la consommation d’énergie) du trafic de contrôle sera
importante.
– La mobilité. L’impact d’une mobilité ”totale” est important à différents niveaux. Du point
de vue des couches basses (PHY et MAC), comme nous l’avons déjà souligné, il n’est d’une
part plus possible d’affecter des fréquences à des zones géographiques ; d’autre part, les
mécanismes d’accès au médium utilisant des horloges globales seront également inutilisables
(TDMA par exemple a besoin d’une grande synchronisation des horloges qui est impossible
dans ce contexte). A un niveau plus élevé, dans les réseaux à stations de base (en particulier
à grande échelle comme dans les réseaux de téléphonie mobile), le routage est effectué dans la
partie fixe du réseau. Dans le cas des réseaux ad hoc, l’ensemble du routage doit fonctionner
sur les mobiles et de façon totalement distribuée. Cela nécessite de nouveaux algorithmes et
les contraintes à leur réalisation sont plus importantes.

12
CHAPITRE 1. LES RÉSEAUX AD HOC

– La faible sécurité. Dans les réseaux ad hoc, non seulement les données sont vulnérables
comme dans tout réseau radio, mais consécutivement au point précédent, il en est de même
pour le trafic de contrôle et de gestion du routage [12, 13]. Les problématiques de la sécurité
dans les réseaux ad hoc sont donc très complexes, puisque l’on cherche à autoriser de nouveaux
mobiles à participer au réseau, tout en évitant des nœuds ”malins” qui détourneraient ou
perturberaient le fonctionnement même du routage.
– La qualité de service. De nombreuses applications ont besoin de certaines garanties re-
latives par exemple au débit, au délai ou encore à la gigue. Dans ces réseaux ad hoc, ces
garanties sont très difficiles à obtenir. Ceci est dû à la nature du canal radio d’une part (in-
terférences et taux d’erreur élevés) et au fait que des ”liens” entre des mobiles peuvent avoir
à se partager les ressources (alors qu’en filaire, deux liens sont par définition indépendants).
De ce fait, les protocoles de qualité de service habituels (par exemple IntServ / RSVP ou Diff-
Serv) ne sont pas utilisables directement dans le monde ad hoc et des solutions spécifiques
doivent être proposés [14, 15].

1.3 Routage
Les réseaux ad hoc que nous considérons sont multi-sauts. Il peut donc arriver qu’un mobile
veuille communiquer avec un autre qui n’est pas dans sa portée de communication directe. Les
messages vont devoir être transmis de proche en proche jusqu’à la destination : c’est ce que l’on
appelle le routage. La technique la plus basique est l’inondation, où chaque mobile ré-émet tous
les paquets qu’il reçoit pour la première fois. Evidemment, l’inondation consomme beaucoup de
ressources (bande passante et énergie) et n’est pas optimale. De nombreux protocoles de routage
ont donc été proposés pour rendre les communications multi-sauts plus efficaces (moins de ré-
émissions, chemins plus courts, etc.) que l’inondation basique.
Même si elle n’en constitue pas le fondement, la connaissance des protocoles de routage du monde
ad hoc est nécessaire au travail que nous avons mené. Nous allons voir plus loin que les phénomènes
des niveaux physique et MAC ont des impacts importants sur les protocoles de niveaux supérieurs.
Mais ces impacts varient grandement en fonction des techniques utilisées pour le routage.
Dans cette section, nous allons donc présenter certains des protocoles de routage développés
dans le cadre du groupe de travail MANET de l’IETF. Ces protocoles travaillent au niveau IP
et sont donc indépendants des couches physique et MAC. Le routage IP permet en particulier
une interconnectivité aisée avec toutes sortes d’autres réseaux ou matériels. Il est d’ailleurs pos-
sible d’utiliser ces protocoles pour fédérer en un seul réseau MANET des utilisateurs utilisant des
matériels différents (cartes radios de technologies diverses, réseaux filaires, etc.). Les protocoles
présentés sont parmi les plus représentatifs des diverses techniques utilisées pour le routage ad hoc.

1.3.1 Routage hiérarchique ou plat


Les protocoles de routage pour les réseaux ad hoc peuvent être classés suivant plusieurs critères.
Le premier d’entre eux concerne le type de vision qu’ils ont du réseau et les rôles qu’ils accordent
aux différents mobiles.
– Les protocoles de routage ”à plat” considèrent que tous les nœuds sont égaux (figure 1.2).
La décision d’un nœud de router des paquets pour un autre dépendra de sa position et pourra
être remise en cause au cours du temps.

13
CHAPITRE 1. LES RÉSEAUX AD HOC

P2

P1
P3

N2 N10
N7

N1
N3 N9
N5 N8
N2
N6
N7
N4 N11 N6
N1 N3 N4
N8
N5

Fig. 1.2 – Routage ”à plat” Fig. 1.3 – Routage hiérarchique

– Les protocoles de routage hiérarchique fonctionnent en confiant aux mobiles des rôles qui
varient de l’un à l’autre. Certains nœuds sont élus et assument des fonctions particulières qui
conduisent à une vision en plusieurs niveaux de la topologie du réseau. Par exemple, un mobile
pourra servir de passerelle pour un certain nombre de nœuds qui se seront attachés à lui. Le
routage en sera simplifié, puisqu’il se fera de passerelle à passerelle, jusqu’à celle directement
attachée au destinataire. Un exemple est donné sur la figure 1.3, où le nœud 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 s’y rattachent savent
que si le destinataire n’est pas dans leur voisinage direct, il suffit d’envoyer à la passerelle qui
se débrouillera). Dans les réseaux où certains nœuds s’avèrent très sédentaires et disposent
de suffisamment d’énergie (par exemple réseau d’ordinateurs portables mais où certains sont
reliés au secteur, stations de base disposées là pour garantir la connectivité, etc.) , ce type de
routage présente certains avantages.

1.3.2 Etat de liens ou vecteur de distance


Une autre classification, héritée du monde filaire, est possible pour les protocoles de routage :

Les protocoles à état de lien. Ils cherchent à maintenir dans chaque nœud une carte plus ou
moins complète du réseau où figurent les nœuds 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
capacité à pouvoir facilement trouver des routes alternatives lorsqu’un lien est rompu. Il est même
possible d’utiliser simultanément plusieurs routes vers une même destination, augmentant ainsi la
répartition de la charge et la tolérance aux pannes dans le réseau. En contre partie, si le réseau est
étendu, la quantité d’informations à stocker et diffuser peut devenir considérable.

Les protocoles à vecteur de distance. Plutôt que de maintenir une carte complète du réseau
(ce qui peut s’avérer extrêmement lourd), ces protocoles ne conservent que la liste des nœuds du
réseau et l’identité du voisin par lequel passer pour atteindre la destination par le chemin le plus
court. A chaque destination possible sont donc associés un next-hop et une distance. Si un voisin
nous envoie un paquet de contrôle dans lequel il indique être plus près d’une destination que le next-
hop que l’on utilisait jusqu’alors, alors il le remplace dans la table de routage. Un des inconvénients
de cette technique et qu’il n’est du coup plus possible de conserver plusieurs routes alternatives au
cas où celle qui est privilégiée serait rompue.

14
CHAPITRE 1. LES RÉSEAUX AD HOC

1.3.3 Les différentes familles de protocoles de routage MANET


Dans les travaux menés à l’IETF, plusieurs familles de protocoles se sont rapidement dégagées.
Chaque protocole peut ainsi être classifié en tant que réactif, proactif, ou hybride.

Les protocoles réactifs


Le principe des protocoles réactifs est de ne rien faire tant qu’une application ne demande pas
explicitement d’envoyer un paquet vers un nœud distant. Cela permet d’économiser de la bande
passante et de l’énergie. Lorsqu’un paquet doit être envoyé, le protocole de routage va rechercher
un chemin jusqu’à la destination. Une fois ce chemin trouvé, il est inscrit dans la table de routage
et peut être utilisé. En général, cette recherche se fait par inondation (un paquet de recherche
de route est transmis de proche en proche dans tout ou partie du réseau). L’avantage majeur de
cette méthode est qu’elle ne génère du trafic de contrôle que lorsqu’il est nécessaire. Les principales
contre-parties sont que l’inondation est un mécanisme coûteux qui va faire intervenir tous les nœuds
du réseau en très peu de temps et qu’il va y avoir un délai à l’établissement des routes.

Les protocoles proactifs


Le principe de base des protocoles proactifs est de maintenir à jour les tables de routage,
de sorte que lorsqu’une application désire envoyer un paquet à un autre mobile, une route soit
immédiatement connue. Dans le contexte des réseaux ad-hoc les nœuds peuvent apparaı̂tre ou
disparaı̂tre de manière aléatoire et la topologie même du réseau peut changer ; cela signifie qu’il va
falloir un échange continuel d’informations pour que chaque nœud ait une image à jour du réseau.
Les tables sont donc maintenues grâce à des paquets de contrôle, et il est possible d’y trouver
directement et à tout moment un chemin vers les destinations connues en fonctions de divers
critères. On peut par exemple privilégier les routes comportant peu de sauts, celles qui offrent
la meilleure bande passante, ou encore celles où le délai est le plus faible. L’avantage premier de
ce type de protocole est d’avoir les routes immédiatement disponibles quand les applications en
ont besoin, mais cela se fait au coût d’échanges réguliers de messages (consommation de bande
passante) qui ne sont certainement pas tous nécessaires (seules certaines routes seront utilisées par
les applications en général).

Les protocoles hybrides


Les protocoles hybrides combinent les approches réactive et proactive. Le principe est de
connaı̂tre 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 nœud qui n’est
pas dans cette zone, d’effectuer une recherche réactive à l’extérieur. Avec ce système, on dispose
immédiatement des routes dans notre voisinage proche, et lorsque la recherche doit être étendue
plus loin, elle en est optimisée (un nœud qui reçoit un paquet de recherche de route réactive va
tout de suite savoir si la destination est dans son propre voisinage. Si c’est le cas, il va pouvoir
répondre, et sinon il va propager de manière optimisée la demande hors de sa zone proactive). Selon
le type de traffic et de les routes demandées, ce type de protocole hybride peut cependant combiner
les désavantages des deux méthodes : échange de paquets de contrôle réguliers et inondation de
l’ensemble de réseau pour chercher une route vers un nœud éloigné.

15
CHAPITRE 1. LES RÉSEAUX AD HOC

1.3.4 Description de quelques protocoles de routage représentatifs


Les protocoles décrits par la suite sont issus du groupe de travail MANET de l’IETF. Ces
protocoles sont représentatifs de diverses techniques et sont les plus avancés sur la voie d’une
normalisation. AODV et OLSR font désormais l’objet d’une Request For Comment (RFC) tandis
que les autres en sont à des versions assez stabilisées de leur drafts.

Ad-hoc On Demand Distance Vector (AODV)


AODV [16] est un protocole basé sur le principe des vecteurs de distance et appartient à la famille
des protocoles réactifs. Les protocoles à vecteur de distance sont en général sujets au problème de
boucle et de comptage à l’infini de l’algorithme de Bellman-Ford qu’ils utilisent (certaines parties du
réseau se trouvent isolées du reste, et les nœuds les composant vont croire qu’ils peuvent atteindre les
nœuds desquels ils sont coupés en passant par leurs voisins. Il s’en suit un phénomène de bouclage
dans lequel les nœuds injoignables se voient attribuer des distances de plus en plus grandes).
Dans le cas d’AODV, ces problèmes sont résolus par l’utilisation de numéros de séquence pour les
messages de contrôle. Quand une application a besoin d’envoyer des paquets sur le réseau et qu’une
route est disponible dans la table de routage, AODV ne joue aucun rôle. S’il n’y a pas de route
disponible, il va par contre en rechercher une. Cette recherche commence par une inondation de
paquets Route Request (RREQ). Chaque nœud traversé 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 nœud intermédiaire qui connait lui-même une route valide jusqu’à la destination), alors un
paquet de réponse est généré (RREP) et il est envoyé par le chemin inverse, grâce aux informations
gardées dans les caches des nœuds traversés par les RREQ (voir figure 1.4). AODV dispose d’un
certain nombre de mécanismes optimisant son fonctionnement. L’inondation se fera par exemple
au premier essai dans un rayon limité autour de la source, et si aucun chemin n’est trouvé, alors
seulement elle sera étendue à une plus grande partie du réseau. En cas de rupture de certains liens,
AODV va essayer de reconstruire localement les routes affectées en trouvant des nœuds suppléants
(cette détection de rupture peut d’ailleurs se faire grâce à un mécanisme optionnel de paquets hello
diffusés aux voisins directs uniquement). Si une reconstruction locale n’est pas possible, alors les
nœuds concernés par la rupture des routes utilisant ce lien sont prévenus de sorte qu’ils pourront
relancer une nouvelle phase de reconstruction complète.

Dynamic Source Routing (DSR)


DSR [17] est un autre protocole réactif. Il se différencie des autres en particulier parce qu’il
pratique le source routing : l’émetteur précise dans l’en-tête de chaque paquet la liste des nœuds
qu’il devra traverser pour atteindre sa destination. Ce type de routage présente certains avantages
particulièrement intéressants ; il autorise en particulier la source à conserver dans sa table de routage
plusieurs chemins valides vers une même destination. Le choix du chemin emprunté pourra donc
être fait indépendamment pour chaque paquet, et permettre un meilleur équilibrage de la charge
du réseau ou une meilleure réactivité aux pannes / changements de topologie (plutôt que de tout
de suite en construire une nouvelle quand une route est brisée, on en a d’autres à disposition
immédiate). Dans la pratique, DSR est structuré en deux sous-parties complémentaires : la recherche
de route et la maintenance de route. La recherche de route se fait par inondation : un paquet de
recherche est diffusé de proche en proche jusqu’à la destination. Au fur et à mesure, les identifiants
des nœuds traversés sont ajoutés dans le paquet de recherche de route. Quand elle reçoit ce paquet,

16
CHAPITRE 1. LES RÉSEAUX AD HOC

Source Source

rreq (1) rreq (1)


rreq (1) rrep (4) rreq (1) rrep (4)
B B
rrep (4)

rreq (2) rreq (2)

A A
rrep (3) rrep (3)

rreq (2) rreq (2)


rrep (3)
D rreq (3) D
E rreq (3) E
rreq (2) rreq (2) rrep (2)

rreq (3) rreq (3)


rrep (2) rrep (2)
rreq (4) rreq (4)
C C rrep (1)
F F

rreq (4)
rreq (4)
rrep (1) rrep (1)
Dest. Dest.

Fig. 1.4 – Recherche de route par inondation Fig. 1.5 – Recherche de route par inondation
(AODV) (DSR)

la destination sait donc déjà quel chemin il a emprunté, et obtient ainsi (en l’inversant) la route
pour retourner à la source. A la réception par la destination de paquets de recherche ayant suivi des
chemins différents, la destination répond sur les chemins inverses, et la source aura ainsi finalement
plusieurs chemins valides pour l’atteindre (voir figure 1.5).

Optimized Link State Routing (OLSR)


OLSR [18] est un protocole proactif à état de liens. Afin de maintenir à jour les tables de
routage, chaque nœud implémentant OLSR diffuse régulièrement des informations sur son propre
voisinage. Ces informations sont suffisantes pour permettre à chaque nœud de reconstruire une
image du réseau et de trouver une route vers n’importe quelle destination. Mais contrairement à
des protocoles tels qu’OSPF, cette diffusion ne se fait pas par une simple inondation (où chaque
nœud retransmet simplement chaque nouveau paquet qu’il reçoit) ; OLSR optimise la diffusion
grâce au système des relais multi-points (Multi-Points Relays : MPR). Chaque nœud choisit dans
ses voisins directs un sous-ensemble minimal de nœuds qui lui permettent d’atteindre tous ses
voisins à deux sauts (voir figure 1.6). La diffusion des informations sur les liens utilisées pour le
routage se fait ensuite uniquement par les relais multi-points ; la couverture totale du réseau est
assurée tout en limitant sensiblement le nombre de ré-émissions. Afin de choisir ses relais multi-
points, un nœud a besoin de connaitre complètement la topologie de son voisinage à deux sauts ;
cela est réalisé grâce à l’envoi périodique 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 à état de liens. Chaque nœud maintient en
permanence un arbre dont il est la racine et qui fournit les chemins les plus courts pour tous les
autres nœuds du réseau. TBRPF est constitué de deux parties complémentaires : la découverte des
voisins et le routage proprement dit.

17
CHAPITRE 1. LES RÉSEAUX AD HOC

MPR
MPR

Source

MPR

Fig. 1.6 – Relais multipoints

La découverte des voisins est assurée par un mécanisme de paquets hello diffusés régulièrement
au voisinage direct. Ces paquets hello contiennent la liste des voisins du nœud, et permettent
ainsi de rapidement connaı̂tre la topologie complète du réseau à deux sauts. Il faut noter que
TBRPF emploie une technique de hello différentiels où seuls les changements de topologie sont
notifiés (diminuant ainsi la taille moyenne des paquets et autorisant leur envoi à une plus grande
fréquence).
La partie routage quant à elle est basée sur un échange des arbres de routage entre nœuds
voisins, conduisant progressivement à la diffusion de l’information dans l’ensemble du réseau.
Là encore cependant seules des parties d’arbres sont échangées. Normalement, un nœud ne
diffuse qu’un sous-arbre à deux niveaux dont il est la racine. Au premier niveau apparaissent les
liens vers tous les voisins directs du nœud, et au deuxième niveau un unique lien vers chaque
voisin à deux sauts (on peut noter ici une certaine similitude avec le mécanisme des relais
multi-points d’OLSR). En conjonction avec ce système de base, TBRPF peut également ajouter
des informations sur d’autre liens à l’arbre diffusé, avant de réagir plus vite en cas de changement
de la topologie. A noter enfin que dans un souci d’économie de bande passante, les sous-arbres et
les paquets hello sont regroupés autant que possible dans un même paquet (on parle d’agrégation
ou piggybacking puisque l’on profite des paquets hello pour envoyer en même temps les sous-arbres).

De nombreux autres protocoles de routage ont été proposés pour les réseaux ad hoc. [20]
en décrit un certain nombre en sus de ceux déjà mentionnés. Dans la catégorie des protocoles
construisant une topologie hiérarchique on peut citer Clusterhead Gateway Switch Routing
(CGSR) présenté dans [21]. Certains autre protocoles nécessitent l’emploi de matériels externes.
Par exemple Temporaly-Ordered Routing Algorithm (TORA) [22] a besoin que les mobiles
soient synchronisés. D’autres ([23],[24]) utilisent le système GPS pour estimer la direction
géographique de la destination et ne faire intervenir qu’une sous-partie du réseau dans la phase
de construction des routes. Alors que beaucoup de protocoles cherchent à minimiser le nombre de

18
CHAPITRE 1. LES RÉSEAUX AD HOC

sauts (minimum shortest path), certains protocoles enfin s’attachent à prendre d’autres critères
en considération. ABR (Associativity-Based Routing) [25] par exemple privilégie 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 à maxi-
miser la durée de vie du réseau en agissant sur la puissance d’émission de chaque mobile séparément.

Les réseaux ad hoc font partie d’un domaine de recherche qui n’a pris son essor que très
récemment. Le facteur qui a déclenché cet intérêt fut l’arrivée de technologies relativement bon
marché qui ont favorisé la conception et le déploiement de tels réseaux. Avant cela, ce domaine
était réservé aux militaires qui disposaient de moyens tout autres.
Les principales normes de réseaux sans fil qui sont à l’origine cet intérêt pour les réseaux ad
hoc sont HiperLAN 1 [28] et 2 [29], Bluetooth [30] et 802.11 [31] de l’IEEE.

19
CHAPITRE
Présentation de 802.11
2
Dans la seconde moitié des années 90, plusieurs normes pour les réseaux sans fils à portée limitée
on été développées (visant des usages à l’échelle du bureau ou du bâtiment). Leur arrivée à soulevé
un engouement nouveau pour les réseau radio multi-sauts, qui étaient jusqu’alors le domaine exclusif
des militaires. Dans ce chapitre, nous allons présenter ces différentes normes, et en particulier 802.11,
qui est désormais utilisée dans la plupart des travaux appliqués de la communauté ad hoc.

2.1 Les autres normes de réseaux locaux sans fil.


Bluetooth a plutôt pour objectif de faire disparaı̂tre les câble entre les divers équipements
numériques (périphériques d’ordinateurs tels que clavier, imprimantes, modems, ou encore appareils
photo numériques, PDA, walkmans, etc.). Les équipements bluetooth ont donc des portées et des
débits assez modestes, ainsi qu’une consommation électrique en rapport.
802.11 est conçue pour les réseaux locaux, en entreprise ou chez les particuliers. Cette norme
s’appuie sur des stations de base reliées à un réseau filaire qui fournir une infrastructure fixe et
reliant les utilisateurs mobiles aux ressources de l’entreprise (et éventuellement à l’Internet). Depuis
peu, 802.11 (et en particulier les cartes compatibles à son extension 802.11b) connaissent un succès
commercial considérable.
HiperLAN type 1 a été conçu comme le pendant européen de 802.11. Cette norme se veut assez
similaire dans son utilisation, mais certains choix technologiques ont été faits qui se démarquent
nettement de 802.11. Commercialement cependant HiperLAN est resté à l’état de prototype et n’est
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 débits aussi élevés et un certain nombre de fonctionnalités
supplémentaires. Mais là encore, il est à craindre qu’HiperLAN 2 ne soit jamais commercialisée à
grande échelle.

2.1.1 HiperLAN 1
High Performance Local Area Network type 1 (HiperLan 1) est un standard de l’European
Technical Standard Institute (ETSI). Il décrit le fonctionnement d’équipements travaillant dans la
bande des 5.15-5.30 GHz et permettant d’atteindre des débits de 23.5 Mbit/s sur une distance d’en-
viron 50 mètres. L’architecture est totalement décentralisée. Il n’y a pas de notion de point d’accès
mais les nœuds HiperLAN 1 peuvent cependant avoir des rôles de passerelles. Les caractéristiques
les plus marquantes d’HiperLAN 1 sont :

20
CHAPITRE 2. PRÉSENTATION DE 802.11

– le mécanisme d’accès au médium évolué, qui gère les priorités. Il est possible d’obtenir des
garanties de qualité de service, particulièrement utiles pour les flux multimédias par exemple ;
– la possibilité d’étendre le réseau au delà de la portée radio, par sauts successifs (fonctionne-
ment en cela très semblable aux réseaux ad hoc, des nœuds jouant le rôle d’intermédiaires
entres ceux qui sont trop loin pour communiquer directement).
Les fonctionnalités d’HiperLAN 1 sont organisées comme présenté sur la figure 2.1. Nous n’en-
trerons pas dans les détails de cette norme complexe, mais nous pouvons remarquer néanmoins que
le mécanisme d’accès au médium EY-NPMA (Elimination Yield-Non Preemptive Multiple Access)
est au cœur du système. C’est lui qui permet en particulier la gestion des priorités. Le fonction-
nement de EY-NPMA est particulièrement intéressant puisqu’il est prévu pour fonctionner dans
un contexte ad hoc. Nous allons donc le décrire plus en avant. Il fonctionne en trois phases et un
exemple est donné sur la figure 2.2 :
– La phase de priorité. Cinq niveaux de priorité sont définis par la norme (de 0 pour le
plus prioritaire à 4) et la phase de priorité est donc divisée en cinq slots. Au début d’un
nouveau cycle de transmission, tous les nœuds qui veulent accéder au canal vont envoyer un
burst de signalement, dont la date de début dépend de la priorité du paquet. Plus la priorité
est élevée, plus le burst commence tôt. Sur la figure, les nœuds A, C et D ont une priorité
de 2, et le nœud B a une priorité de 3. L’idée est d’écouter le canal tant que notre priorité
nous interdit d’émettre notre propre burst de signalement. Si l’on détecte de l’activité avant
d’avoir pu émettre, c’est que quelqu’un est plus prioritaire que nous, et l’on abandonne l’idée
de transmettre pour ce cycle. C’est le cas du nœud B sur la figure 2.2.
– La phase d’élimination. Il se peut que plusieurs nœuds veuillent émettre en même temps
des paquets de priorités identiques. Il faut donc les départager. Pour cela, chaque nœud va
poursuivre l’envoi de son burst de signalement pendant un nombre aléatoire de slots. Ce sera
celui qui aura tiré le plus grand nombre qui l’emportera. Dès que l’émission de notre burst est
terminée, nous écoutons le canal. Si nous y détectons de l’activité, c’est qu’un autre nœud a
tiré un plus grand nombre que nous, et nous abandonnons pour ce cycle. Sur la figure, c’est
le cas du nœud C .
– La phase d’écoute. Si toutefois il reste plusieurs nœuds en lice alors l’élimination va se
terminer dans la troisième phase. Un nombre aléatoire de slots est choisit. C’est celui qui
aura tiré le plus petit qui pourra transmettre. Chaque nœud attend pendant la durée qu’il a
déterminé, en écoutant le canal. Si il détecte de l’activité alors qu’il n’a pas fini d’attendre,
il sait que quelqu’un a tiré un plus petit nombre que lui et n’émettra pas durant ce cycle. Si
son attente se termine alors que le canal est toujours libre, alors il émet. Sur la figure, c’est
le nœud D qui l’emporte. Il faut noter que si le paquet est envoyé en point à point, il sera
acquitté par son récepteur (ici le nœud E).
Avec HiperLAN type 1, un mécanisme de routage multi-sauts est implanté. Les nœuds envoient
des paquets hello qui leur permettent de connaı̂tre leur voisinage. Ces informations de voisinage
sont propagées dans tout le réseau et permettent ainsi à un nœud d’en reconstruire la topologie.
C’est un protocole à état de lien qui utilise une système de relais multipoints pour optimiser les
diffusions d’informations.

21
CHAPITRE 2. PRÉSENTATION DE 802.11

n
tio
rité

ina

te
ou
rio

lim

'éc
ep

d'é

ed
ed

as
as
as

Ph
Ph
Ph
Couches supérieures
A

Système de cryptage B

C
Système de
connaissance Relayage et
du réseau Accès multiple
et gestion du
gestion des D DATA
informations
trafic multimédia
topologiques
Economie E ACK
d'énergie

Accusé de réception
fin du cycle Les trois phases
Couche physique (uniquement pour le trafic point
précédent de l'accès multiple à point)

Fig. 2.1 – Organisation d’Hiperlan 1 Fig. 2.2 – L’accès au canal avec EY-NPMA

2.1.2 HiperLAN 2
L’organisation générale d’HiperLAN type 2 est présentée sur la figure 2.3. On remarque en
premier lieu que la norme prévoit la compatibilité avec diverses technologies (TCP/IP bien sûr,
mais aussi ATM, UMTS et l’IEEE 1394 connue aussi sous le nom de Firewire).
HiperLAN type 2 est très différent dans son architecture d’HiperLAN type 1. Contrairement
au type 1, le type 2 est basé sur une centralisation poussée. Les points d’accès sont d’ailleurs
indifféremment appelés Access Points (AP) ou Central Controler (CC). Les points d’accès sont
reliés entre eux par une infrastructure réseau filaire ou non-filaire (qui doit simplement disposer
d’une interface adéquate dans HyperLAN 2, comme celles de la liste donnée précédemment). Les
mobiles s’attachent ensuite à ces points d’accès pour accéder aux ressources du réseau.
HiperLAN 2 peut aussi fonctionner sans infrastructure fixe. Dans ce cas, un mobile est élu pour
jouer le rôle de contrôleur central et les autres vont s’attacher à lui. Bien entendu, dans ce type
de configuration il n’est pas question de réseau ad hoc au sens où le groupe MANET l’entend.
Tout au plus, les mobiles pourront communiquer directement entre eux (un saut), ou alors par
l’intermédiaire du contrôleur central (deux sauts).
L’accès au médium reflète ces choix architecturaux, et c’est le contrôleur central qui décide de
l’ordonnancement des communications dans la zone qu’il gère. Ces communications se font grâce à
des trames de durée fixe (2 ms) qui sont elles-mêmes découpées en différents champs de longueur
variable et qui portent les informations de contrôle du point d’accès ou les données dans un sens ou
dans l’autre. Il faut noter également que la couche physique d’HiperLAN type 2 est très semblable
à la couche physique de 802.11a (qui sera présentée plus en détail dans la section dédiée à 802.11).
De part son architecture très ciblée, HiperLAN 2 est donc peu adapté aux réseaux ad hoc, et
nous ne détaillerons pas plus cette norme ici.

2.1.3 Bluetooth
Les réseaux Bluetooth ont été développé pour permettre la réalisation de réseaux personnels
(PAN : Personnal Area Network). Ces réseaux doivent permettre des communications à courte
portée, à des débits faibles ou moyens entre toute sorte d’équipements. Ils travaillent dans la bande

22
CHAPITRE 2. PRÉSENTATION DE 802.11

TCP/IP ATM / UMTS IEEE


B-ISDN 1394

Couche de convergence réseau (NC)

Couche liaison
(DLC)

Couche Physique

Fig. 2.3 – L’organisation générale d’HiperLAN type 2

ISM des 2.4 GHz à des puissances leur permettant d’atteindre des portées allant du mètre à la
centaine de mètres environ.
C’est le groupe de travail Bluetooth SIG (Bluetooth Special Interest Group) qui a élaboré les
spécifications de Bluetooth. Ce groupe de travail, au départ constitué de grosses sociétés de l’infor-
matique et des télécommunications telles qu’IBM, Ericsson, Intel ou Nokia, a rapidement pris de
l’ampleur et regroupe actuellement plus de 2500 sociétés.
Il faut noter que le Bluetooth SIG n’est pas le seul organisme produire des spécifications dans
ce domaine, le groupe de travail 802.15 de l’IEEE complétant et prolongeant ces travaux dans
plusieurs directions :
– Le sous-groupe 802.15.1. Il a pour rôle, en accord avec le Bluetooth SIG, de traduire les
spécifications Bluetooth en spécifications de type 802.
– Le sous-groupe 802.15.2. Il doit étudier les configurations des réseaux personnels et no-
tamment la coexistence de ces réseaux avec les réseaux locaux sans fils (du type de 802.11).
– Le sous-groupe 802.15.3. Il travaille sur les spécifications d’un réseau personnel à haut
débit (de l’ordre de 20 Mbit/s).
– Le sous groupe 802.15.4. Il étudie les spécifications pour des réseaux personnels à bas
débit (de l’ordre de 200 kbit/s).
Les réseaux Bluetooth sont construit de manière centralisée. Un maı̂tre élu peut prendre en
charge jusqu’à huit esclaves et forme ainsi un piconet. Dans un piconet, c’est le maı̂tre qui contrôle
toutes les transmissions. Les esclaves ne peuvent émettre des paquets que s’ils y ont été invités
par le maı̂tre. Ce dernier doit donc les interroger régulièrement pour savoir s’ils ont des données à
envoyer (polling).
Plusieurs piconets peuvent être reliés afin de former une structure plus grande appelée
scatternet (de l’anglais scatter, dispersé). A cette fin, les mobiles peuvent quitter temporairement
leur piconet pour aller s’attacher à un autre. La figure 2.4 donne un exemple de scatternet. Un
esclave alterne entre les piconets 1 et 2 afin d’en assurer la liaison et un mobile esclave du piconet
2 est aussi maı̂tre dans le piconet 3 (le processus de dé-association est réversible, il est possible de
quitter temporairement un piconet puis de le rejoindre à nouveau et de revenir à la situation initiale).

L’accès au médium dans Bluetooth est géré par intervalles de temps réguliers (slotted). Le slot
de base a une durée de 625 µs. Au niveau physique, Bluetooth fonctionne par sauts de fréquence
très rapides (jusqu’à 1600 sauts par seconde). La fréquence reste la même pour la durée d’un slot.
En général, sauf si le paquet à transmettre est trop long pour tenir sur un seul slot auquel cas il en
occupe plusieurs, la fréquence change après chaque slot selon un schéma cyclique.

23
CHAPITRE 2. PRÉSENTATION DE 802.11

Esclave
Esclave

Esclave

Maître
Maître dans P3
Maître Esclave

Esclave
dans P2

Esclave Esclave
Esclave Esclave

Piconet 1 (P1) Piconet 2 (P2) Piconet 3 (P3)

Scatternet

Fig. 2.4 – Un scatternet Bluetooth

Là encore nous n’entrerons pas plus en avant dans la description de la norme. Avec ses scatternet,
Bluetooth présente bel et bien une forme de réseau ad hoc multi-sauts. Mais du fait de l’utilisation
ciblée pour un usage personnel, ces réseaux restent assez statiques et leur étendue volontairement
limitée.

2.2 Introduction à 802.11


802.11 [31, 32] est une norme établie par l’IEEE. Elle décrit les couches physique et MAC
d’interfaces réseau radio et infra-rouge. Les débits possibles varient entre 1 et 54 Mbit/s suivant
les techniques et les éventuelles extensions de la norme employées. Les portées prévues varient
entre quelques dizaines et quelques centaines de mètres en fonction de la vitesse choisie et de
l’environnement. Cette norme cible deux contextes d’utilisation :
– Le mode ”infrastructure” (l’utilisation privilégiée de 802.11), où des stations de base
reliées entre elles par un réseau filaire assurent la couverture d’une certaine zone et prennent
en charge les mobiles dans leur voisinage (figure 2.5).
– Le mode appelé ad hoc, qui consiste en fait simplement à autoriser les communications
entre deux mobiles à portée l’un de l’autre, sans intervention de stations ou d’autres mobiles
extérieurs (figure 2.6).

La norme originelle 802.11 date de 1997 et décrit les couches physiques et MAC pour un débit
allant jusqu’à 2 Mbit/s en radio, dans la bande des 900MHz. Des extensions ont été publiées depuis
qui viennent lui ajouter des améliorations 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 débits
pouvant atteindre les 2 Mbit/s. Cette bande de fréquence est partagée avec d’autres types de
réseaux locaux sans fil (Bluetooth en particulier) ainsi que par diverses autres applications.
– 802.11b ajoute la description d’une couche physique améliorée proposant des débits de 5.5
et 11 Mbit/s en plus de ceux déjà supportés.

24
CHAPITRE 2. PRÉSENTATION DE 802.11

Station Station
de base de base

Fig. 2.5 – Réseau 802.11 en mode infrastruc-


ture Fig. 2.6 – Réseau 802.11 ad-hoc
802.11 Logical Link Control (LLC)
OSI Layer 2
Data Link Layer 802.11 Medium Access Control (MAC)

OSI Layer 1
FHSS DSSS IR Wi-Fi Wi-Fi5 ...
Physical Layer
802.11b 802.11a
(PHY)

Fig. 2.7 – Les couches et sous-couches OSI définies 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 (présentées succinctement dans la
section suivante) d’accès au canal.
– 802.11g utilise des technique OFDM similaires 802.11a, mais en restant dans la bande ISM
à 2.4GHz. Les débits possibles atteignent également les 54 Mbit/s tout en gardant la compa-
tibilité avec les équipements 802.11b.
– 802.11e cherche à améliorer 802.11 de façon à pouvoir donner des garanties de qualité de
service. Cette extension de la norme n’est pas encore finalisée.
– 802.11h cherche à mieux gérer la puissance d’émission et la sélection des canaux dans la
bande des 5 GHz suivant si l’on est à l’intérieur ou à l’extérieur de bâtiments. L’objectif est
d’être, à terme, mieux en accord avec les diverses législations (notamment européennes).
– 802.11i cherche à améliorer les mécanismes de sécurité et d’authentification ; ce travail n’est
pas encore finalisé non plus.
Afin de permettre la mise en place de ces différentes améliorations et de présenter aux couches
supérieures une interface très similaire à 802.3 (le célèbre Ethernet), 802.11 propose le modèle en
couches de la figure 2.7. La sous-couche LLC est l’interface ”visible” de 802.11, c’est par son in-
termédiaire que les grandes similitudes avec 802.3 sont possibles. La sous-couche d’accès au médium
(MAC) est spécifique à 802.11, mais reste la même quelles que soient les couches physiques em-
ployées en-dessous. Pour finir, un certain nombre de couches physiques sont définies. Originellement
seules une couche infra-rouge et une couche radio dans la bande des 900MHz étaient définies. La
couche physique radio proposait déjà plusieurs techniques de modulation (FHSS et DSSS, présentées
elles aussi dans la section suivante) à utiliser en fonction du débit désiré (qui pouvait aller jusqu’à
2 Mbit/s). Par la suite d’autres couches physiques améliorées ont été ajoutées. Les plus importantes
de ces couches PHY dans le contexte des réseaux ad hoc seront décrites dans la section suivante.

25
CHAPITRE 2. PRÉSENTATION DE 802.11

2.3 La couche physique


Initialement, le standard IEEE 802.11 permet l’utilisation de trois couches physiques différentes
(FHSS, DSSS et IR), auxquelles 802.11a a ajouté ODFM :
– FHSS : Frequency Hoping Spread Spectrum. La plupart des interférences nuisibles aux trans-
missions radio n’agissent en fait que sur des bandes de fréquence assez étroites. Si par mal-
chance de telles interférences ont lieu au moment ou l’on transmet, alors notre signal sera
fortement dégradé. Une technique pour protéger notre signal consiste à régulièrement changer
de fréquence (figure 2.8). Bien sûr les paquets envoyés sur la bande perturbée seront affectés,
mais ils ne représenteront plus qu’une minorité des transmissions et leur retransmission sera
moins coûteuse. L’émetteur et le récepteur doivent connaı̂tre à l’avance le séquencement des
sauts de fréquence, mais des informations portées par les paquets permettent à un mobile
s’attachant au réseau de savoir à partir d’un paquet qu’il reçoit où en est le déroulement de
la séquence.
– DSSS : Direct Sequence Spread Spectrum. Toujours pour lutter contre les interférences impor-
tantes mais n’affectant que des plages de fréquences assez étroites, il existe la technique de
l’étalement de spectre. Des manipulations sur le signal vont le faire occuper un spectre plus
large (on le multiplie par une séquence pseudo-aléatoire ayant certaines propriétés d’auto-
correlation). A la réception, une manipulation inverse est effectuée (figure 2.9). Cette tech-
nique est moins sensible aux interférences dues aux fréquences parasites à faible largeur spec-
trale.
– IR : Infra Red. Que l’on ne détaillera pas ici du fait de son absence totale du marché.
– OFDM : Orthogonal Frequency Division Multiplexing. Nous avons déjà mentionné le problème
des chemins multiples : lorsqu’un signal radio est émis, l’onde va se réfracter, se réfléchir et
donc se diviser sur les divers obstacles rencontrés. A l’arrivée plusieurs chemins pourront
avoir été empruntés, et leur temps de parcours n’étant pas forcément les mêmes, les multiples
réfractions / réflexions d’une même onde vont interférer entre elles. Plus la différence de
temps de parcours sera grande vis à vis de la durée de transmission totale du symbole, plus
les chances que des reflexions / réfractions de symboles consécutifs se chevauchent. Pour
augmenter le débit, l’approche traditionnelle consiste à réduire la durée d’un symbole, mais
cela augmente aussi les problèmes de chemin multiple. OFDM propose donc d’utiliser des
symboles plus longs, mais envoyés en parallèle. On peut dire pour résumer succinctement
cette méthode qu’en présence de chemins multiples, à débit total équivalent, l’agrégation d’un
certain nombre de canaux lents donne de meilleurs résultats qu’un seul canal très rapide.

A l’origine, la bande de fréquence utilisée était celle des 900MHz. Les extensions successives ont
ajouté d’autres couches physiques afin de permettre des débits de plus en plus élevés en radio.

802.11 (version de 1999) La version de 1999 de 802.11 a remplacé 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 été définis.
Suivant les réglementations, ils ne sont pas tous utilisables dans tous les pays (voir table 2.1).
Il n’est possible pour un émetteur ou un récepteur de ne travailler que sur un seul canal à la
fois. Disposer de plusieurs canaux permet donc de les affecter aux stations de base de manière à ce
que deux cellules voisines n’interfèrent pas entre elles (on améliore ainsi la réutilisation spatiale).
Un exemple est donné sur la figure 2.10.

26
CHAPITRE 2. PRÉSENTATION DE 802.11

Temps
Amplitude
Interférences
Message à Message fortement
Interférences dégradé par les
transmettre
interférences

Fréquence

Message peu
dégradé par les
interférences

Fréquence Etalement
de spectre
Transmission

Fig. 2.8 – Changer de fréquence


régulièrement pour réduire l’impact Fig. 2.9 – Etaler le spectre pour réduire l’impact de cer-
de certaines interférences taines interférences
Pays (organisme régulateur) Bandes de fréquence
Etats-Unis (FCC) 2.400 - 2.485 GHz
Europe (ETSI) 2.400 - 2.435 GHz
Japon (MKK) 2.471 - 2.497 GHz
France (ART) 2.400 - 2.454 GHz à 100 mW, 2.454 - 24835 GHz à 10 mW en extérieur
2400 - 2483.5 Ghz à 100mW en intérieur

Tab. 2.1 – Réglementations de la bande ISM

De plus, il faut préciser que ces canaux ne sont pas tous indépendants les uns des autres. Ils se
chevauchent en partie, comme présenté sur la figure 2.11. Il faut également noter que la bande ISM
tend à être saturée car de nombreux équipements l’utilisent (dont bluetooth, 802.11b et 802.11g).

802.11b 802.11b (qui travaille toujours dans la bande des 2.4GHz) a ajouté une couche DSSS
modifiée (High Rate DSSS) avec une modulation CCK (Complementary Code Keying) et définit
ainsi les vitesses de 5.5 et 11 Mbit/s. Le canaux restent les mêmes et la compatibilité est préservée
avec les modes à 1 et 2 Mbit/s. Afin de garantir l’interopérabilité des matériels 802.11b des différents
constructeurs, la WECA (Wireless Ethernet Compatibility Alliance1 ) a créé le label Wi-Fi. Les
1
www.weca.net

13
1

1 7
13

13 1

Fig. 2.10 – Le réutilisation spatiale grâce à un plan d’allocation des fréquences

27
CHAPITRE 2. PRÉSENTATION 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.28 GHz 5.30 GHz 5.32 GHz
5.35 GHz
5.15 GHz
200 MHz

Fig. 2.12 – Les 8 premiers canaux définis par 802.11a

produits estampillés Wi-Fi on été analysés grâce a des tests de compatibilité développés par la
WECA et leur interopérabilité est donc garantie.

802.11a 802.11a passe dans la bande UN-II des 5GHz en utilisant une technique OFDM (Ortho-
gonal Frequency Division Multiplexing). Cette fois-ci, 12 canaux disjoints de 20 MHz ont été définis
(voir figure 2.12 pour les 8 premiers, les 4 derniers étant dans les 5.7 GHz). La bande UN-II est
moins encombrée que la bande ISM. L’autre principal utilisateur de la bande UN-II est HiperLan
2, qui n’est pas répandu commercialement. 802.11a autorise des débits allant jusqu’à 54 Mbit/s,
mais cela se fait au détriment de la portée de communication qui n’excède pas quelques dizaines de
mètres aux débits les plus élevés. De façon similaire au label Wi-Fi des produits 802.11b, le label
Wi-Fi5 de la WECA garantit l’interopérabilité des produits 802.11 le portant.

802.11g 802.11g, publiée après 802.11a travaille dans la même bande ISM que 802.11b mais
utilise les mêmes techniques OFDM que 802.11a afin de permettre des débits allant également
jusqu’à 54 Mbit/s. Là aussi, la compatibilité est préservée avec 802.11b. Il faut cependant noter
que les débits maximums ne peuvent être obtenus qu’à courte portée et que si la station de base
et l’ensemble des mobiles de la cellule utilisent 802.11g.

La figure 2.13 récapitule les différentes technologies et débits possibles pour chacune d’entre
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 être utilisé par tous
les mobiles, et qui permet un accès équitable au canal radio sans aucune centralisation de la

28
CHAPITRE 2. PRÉSENTATION DE 802.11

802.11 802.11b 802.11a 802.11g

FHSS DSSS HR-DSSS OFDM OFDM

6 Mbit/s
9 Mbit/s
12 Mbit/s
Jusqu'à
1 Mbit/s 1 Mbit/s 5.5 Mbit/s 18 Mbit/s
54Mbit/s
2 Mbit/s 2 Mbit/s 11 Mbit/s 24 Mbit/s
36 Mbit/s
48 Mbit/s
54 Mbit/s

Fig. 2.13 – Récapitulatifs des technologies et des débits possibles

gestion de l’accès (mode totalement distribué). Ce mode peut aussi bien être utilisé lorsqu’il
n’y a pas de stations de base (mode ad hoc) que lorsqu’il 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 l’accès au canal dans leur zone de couverture pour les mobiles qui leur
sont rattachés.
Dans les réseaux ad hoc multi-sauts, il n’y a pas de stations de base fixes et c’est donc le
mode DCF qui sera employé. Le mode DCF va être décrit dans la sous-section suivante. Le mode
PCF sera néanmoins décrit brièvement lui aussi, dans la mesure où les mécanismes qu’il utilise
sont fondamentaux dans 802.11 et que leur compréhension apporte à la compréhension globale du
comportement de 802.11 dans le contexte des réseau ad hoc.

2.4.1 Description du mode DCF


Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA)
Dans le monde filaire, lorsqu’un émetteur envoie un signal sur le câble, il peut y lire en même
temps la valeur qui y est effectivement présente. Si jamais la valeur lue est différente de celle
que l’émetteur écrit, c’est qu’un autre émetteur est actif au même moment et qu’il y a collision.
Cette écoute du signal sur le câble au moment de l’émission est à la base de la méthode d’accès
CSMA/CD bien connue d’Ethernet. CSMA/CD permet de détecter une collision et le cas échéant
de retransmettre le paquet après un temps d’attente aléatoire.
En radio cependant, l’atténuation du signal en fonction de la distance est bien plus importante
que sur un câble. Au niveau d’un émetteur, le signal qu’il envoie va donc être reçu avec une
puissance très supérieure à un signal venant de n’importe quel autre mobile. Par exemple, sur la
figure 2.14 sont schématisées les puissances reçues réciproquement par deux émetteurs A et B. Un
signal émis localement est reçu avec une puissance tellement supérieure aux autres signaux qu’il les
occulte complètement. Du point de vue d’un émetteur, il n’y a donc jamais de collision en radio.
Evidemment le problème se pose au niveau du récepteur, où plusieurs signaux pourraient ainsi être
reçus simultanément avec des puissances comparables. Dans la pratique, des collisions se produisent
effectivement uniquement au niveau des récepteurs.
La première caractéristique de la couche MAC de 802.11 est donc d’utiliser des acquittements
pour détecter ces collisions et permettre la retransmission des paquets qui ont été perdus (en
l’absence d’acquittement, l’émetteur sait qu’il doit retransmettre).

29
CHAPITRE 2. PRÉSENTATION DE 802.11

Puissance perçue
Emis par A
Emis par B

A B Position

Fig. 2.14 – L’atténuation très rapide des signaux rend la détection de collision impossible

Il faut noter que 802.11 peut envoyer une trame à un récepteur spécifique (unicast) ou la
diffuser (broadcast). Dans le cas de la diffusion, il n’y a pas d’acquittement et des paquets peuvent
être perdus de manière tout à fait silencieuse (ce qui est logique, car chaque mobile ayant reçu le
paquet chercherait à envoyer l’acquittement au même moment et il y aurait une série de collisions
sur les acquittements).

En Ethernet, l’idée est d’observer l’état du canal avant d’émettre. Si le canal est libre, alors nous
pouvons envoyer notre trame (et si à ce moment-là nous détectons une collision, nous ré-émettons
la trame un peu plus tard, après une attente de durée aléatoire). Or nous venons de voir qu’en
radio il n’était pas possible de détecter directement les collisions. Par conséquent, le mécanisme
qui conditionne l’autorisation d’émettre sur le canal doit lui aussi être modifié par rapport à ce
qui se fait en 802.3. En effet, si nous nous contentions d’attendre que la canal devienne libre pour
émettre, alors si plusieurs mobiles étaient en attente d’émission, ils détecteraient tous le canal libre
et émettraient au même moment. Il y aurait collision au récepteur et il faudrait attendre que le
délai imparti pour le retour de l’acquittement soit écoulé pour s’en rendre compte, ceci pourrait
être relativement long.
L’idée retenue pour 802.11 est donc, lorsque le canal devient libre, d’attendre une période de
durée aléatoire supplémentaire appelée backoff avant d’émettre. Ce mécanisme s’applique lorsque
le canal devient libre aussi bien après une de nos propres émissions qu’après toute autre émission.
Ainsi, si plusieurs mobiles veulent émettre, il y a peu de chances pour qu’ils aient choisi la même
durée. Celui qui a choisi le plus petit backoff va commencer à émettre, et les autres vont alors
se rendre compte qu’il y a à nouveau de l’activité sur le canal et vont attendre. La figure 2.15
schématise ce qui se passe lorsque deux mobiles à portée de communication veulent émettre vers
un troisième et que le canal devient libre.
Lorsque le canal devient libre, avant toute chose, il faut qu’il le reste pour une période DIFS
(DCF Inter-Frame Space). Si le canal est resté libre durant toute cette période, alors les mobiles
qui veulent émettre choisissent un backoff aléatoire exprimé en un nombre de time slots d’une durée
fixe de 20 µs. Le backoff est choisit au hasard dans un intervalle appelé Contention Window (CW)
qui est par défaut [0 ;31] ; avec un time slot de 20 µs, le backoff va donc normalement être compris
entre 0 et 620 µs. Dans l’exemple de la figure 2.15, le mobile 1 a tiré 3 et le mobile 2 a tiré 5. Une
fois ce tirage effectué, tant que le canal reste libre, les mobiles décrémentent leur backoff. Dès que
l’un d’eux a terminé (ici le mobile 1), il émet. L’autre mobile, dès qu’il détecte le regain d’activité
sur le canal stoppe la décrémentation de son backoff et entre en période de defering.

30
CHAPITRE 2. PRÉSENTATION DE 802.11

off
ck
DIFS SIFS DIFS SIFS

ba
source 1 DATA

t
tan
ACK ACK
destination

res
off
off

ck
ck

ba
defering

ba
source 2 DATA

canal
autre occupé

Fig. 2.15 – Le backoff et le defering

Il faut noter que le temps de pause qui sépare un paquet de données de son acquittement est
appelé SIFS (Short Inter-Frame Space) et qu’il est plus court que DIFS. Le mobile en période de
defering ne pourra reprendre la décrémentation de son backoff que si le canal est à nouveau libre
pendant DIFS. Le fait que SIFS soit plus court empêche que la décrémentation ne reprenne de
manière inopportune entre les données et leur acquittement.
Lorsque les données du mobile 1 ont été acquittées et que DIFS s’est écoulé sans activité sur
le canal, le mobile 2 peut reprendre la décrémentation de son backoff. Ici, aucun autre mobile ne
vient l’empêcher de terminer et il peut donc finalement envoyer ses données.
Le mécanisme de backoff limite les risques de collision mais ne les supprime pas complètement.
Aussi, si une collision se produit quand même (détectée grâce à l’absence d’acquittement), un
nouveau backoff va être tiré au hasard. Mais à chaque collision consécutive, la taille de la fenêtre
va doubler afin de diminuer les chances que de telles collisions se répètent. La borne inférieure de
la Contention Window est toujours zéro, et la borne supérieure (dont les valeurs autorisées par la
norme ne sont que des puissances de 2 moins 1) va évoluer entre les valeurs aCWmin et aCWmax
définies par la norme. La borne supérieure de la fenêtre est ré-initialisée à aCWmin sitôt qu’un
paquet a été transmis correctement (ou lorsque les timers de ré-émission expirent). Un exemple
d’évolution de la fenêtre de contention est donné sur la figure 2.16.

Le mécanisme RTS/CTS
Nous avons vu que le mécanisme CSMA/CA cherche à éviter les collision en écoutant l’activité
sur le canal et en choisissant un délai aléatoire supplémentaire avant l’émission. Mais il existe une
famille de configuration où ce mécanisme est insuffisant. Il s’agit du problème des nœuds cachés
(figure 2.17) où deux émetteurs qui ne peuvent pas du tout s’entendre (en général à cause d’un
obstacle) veulent atteindre un même récepteur. Comme dans cette configuration un émetteur ne
détecte jamais l’activité de l’autre, il croit que le canal est toujours libre et émet dès qu’il a des
données disponibles. Les chances de collisions à répétition au niveau du récepteur sont très élevées.
802.11 propose un mécanisme utilisant des paquets de contrôle appelés Request To Send (RTS)
et Clear To Send (CTS) introduit par [33]. Un mobile qui veut émettre ne va plus directement
envoyer son gros paquet de données, mais plutôt un petit paquet RTS pour lequel les chances
de collision sont plus faibles. A ce paquet RTS, le destinataire va répondre par un petit paquet

31
CHAPITRE 2. PRÉSENTATION DE 802.11

aCWmax 255 255

127

63

31
15
aCWmin 7

Troisième retransmission
Deuxième retransmission
Première retransmission
Tentative initiale

Fig. 2.16 – Un exemple de backoff exponentiel

CTS qu’il diffuse à tout son voisinage. Les paquets RTS et CTS contiennent des informations qui
permettent de réserver le canal pour la durée de transmission des données qui vont suivre. Un
mobile qui reçoit un CTS alors qu’il n’a pas envoyé (ni même détecté de RTS) sait que quelqu’un
d’autre va émettre et doit donc attendre. Le mobile qui a envoyé le RTS sait, quand il reçoit le
CTS correspondant, que le canal a été réservé pour lui et qu’il peut émettre.
Au niveau des mobiles, la réservation du canal est implémentée grâce au Network Allocation
Vector (NAV). Dans chaque nœud, le NAV indique pour combien de temps le canal est utilisé par
quelqu’un d’autre, indépendamment de ce qui est physiquement perçu sur le canal (on parle aussi
de détection de porteuse ’logique’). Sur la figure 2.19 sont présentées les mises à jour du NAV au
niveau d’un mobile alors qu’une trame est échangée entre deux autres mobiles. Lorsque le nœud non
concerné par l’échange reçoit le RTS, il sait grâce aux informations contenues dans ce dernier pour
combien de temps il ne devra pas accéder lui-même au canal. Nous avons vu que dans certaines
configurations (par exemple celle de la figure 2.17), certains paquets ne sont pas reçus par tous
les mobiles potentiellement concernés. Les CTS et les paquets de données vont donc aussi devoir
porter les informations de durée, afin que leur réception puisse mettre le NAV à jour (un exemple
est donné dans la figure 2.18 où seul le CTS est reçu par le mobile de droite).

RTS (1)

CTS (2) CTS (2)

DATA (3)
ACK (4)

A B

Fig. 2.17 – Le problème des nœuds cachés Fig. 2.18 – L’échange RTS/CTS

32
CHAPITRE 2. PRÉSENTATION DE 802.11

SIFS SIFS SIFS DIFS

RTS DATA
source

CTS ACK
destination

autre NAV (RTS)

NAV (CTS)
Temps
NAV (DATA)

Fig. 2.19 – Le Network Allocation Vector (NAV)

Le mécanisme EIFS
Dans la configuration présentée sur la figure 6.13, le nœud de gauche (”autre”) détecte la
porteuse de l’émetteur sans pour autant comprendre ses messages (le signal est trop faible pour
être décodé, mais suffisamment fort pour être reconnu comme tel). Les paquets envoyés par le
récepteur ne sont quant à eux pas détectés du tout par le mobile de gauche. Dans cette situation,
802.11 impose l’utilisation d’un Extended Inter Frame Spacing(EIFS), afin d’éviter une collision
au niveau de l’émetteur au moment du CTS et de l’acquittement par le récepteur. La figure 2.21
détaille ce qui se passe : L’émetteur envoie tout d’abord un paquet de contrôle RTS. Ce paquet
est reçu par le récepteur, qui va y répondre par un CTS. Le mobile de gauche, lui, a détecté de
l’activité au moment du RTS mais sans comprendre le paquet. Le mécanisme de defering présenté
précédemment l’empêche d’émettre pendant l’envoi du RTS (canal occupé) et pendant une période
DIFS consécutive (on est toujours obligé d’attendre que la canal ait été libre pendant DIFS pour
émettre). Mais DIFS est plus court que SIFS+CTS. Si jamais le mobile de gauche avait terminé
de décrémenter son backoff trop vite, il aurait pu émettre pendant le CTS, causant une collision au
niveau de l’émetteur. Pour protéger le CTS (et de manière similaire l’acquittement), 802.11 impose
qu’un nœud doive attendre pendant un temps EIFS lorsque le canal redevient libre mais que le
paquet n’a pas été compris ; la longueur de EIFS étant suffisante pour que l’envoi du CTS ou de
l’ACK se déroule dans de bonnes conditions.

2.4.2 Description du mode PCF


Nous avons vu que le mode DCF permettait un fonctionnement totalement distribué de l’accès
au médium, mais que, afin de limiter le nombre des collisions, CSMA/CA avait recours à une durée
aléatoire avant l’émission de chaque paquet. Le temps passé à attendre représente autant de débit
effectif perdu. Aussi 802.11 propose en option un mécanisme centralisé qui permet d’obtenir un
meilleur taux d’utilisation du canal. C’est le mode basé sur la Point Coordination Fonction(PCF),
qui requiert l’utilisation de stations de base et de mobiles l’implémentant.
Le principe de base de la PCF est de centraliser la gestion de l’accès au médium d’une cellule.
C’est le point d’accès qui indiquera à chacun des mobiles qui lui sont rattachés quand ils doivent
émettre leurs paquets. Le backoff aléatoire devient ainsi en partie inutile. Durant toute la phase où

33
CHAPITRE 2. PRÉSENTATION DE 802.11

SIFS SIFS SIFS DIFS

CTS ACK
destination
Emetteur Récepteur

Autre

RTS DATA
source

autre defer EIFS defer EIFS

Temps
DIFS

Fig. 2.20 – Une configuration où l’EIFS est Fig. 2.21 – L’Extended Inter Frame Spacing
nécessaire (EIFS)
CFP CP CFP CP

Balise PCF DCF Balise PCF DCF

Fig. 2.22 – L’alternance des modes PCF et DCF

la station de base impose l’ordre des transmissions, il n’y a pas de contention pour l’accès au canal ;
on parle de Contention Free Period.
De plus, afin de préserver la compatibilité, dans chaque cycle de la PCF, une période de DCF
est conservée et permet aux mobiles n’implémentant pas la PCF de continuer à accéder au canal.
C’est la Contention Period (figure 2.22). La cohabitation entre les mobiles implémentant la PCF et
ceux ne l’implémentant pas est assurée grâce au temporisateur PIFS (PCF Inter Frame Spacing).
Durant la période sans contention, les trames ne sont en effet séparées que de périodes PIFS (ou
SIFS suivant les cas) qui sont toutes les deux plus courtes que DIFS. Grâce à ces temporisateurs,
un mobile n’implémentant pas la PCF ne risque donc pas de prendre la main durant la période
gérée par la station de base en mode PCF.
Il faut noter que pour l’instant, très peu de cartes implémentent la PCF (mais en général une
mise à jour du firmware embarqué dans les cartes et les stations de base sera possible).

2.5 La sécurité des informations : la Wired Equivalent Privacy (WEP)


Dans la section consacrée aux problèmes spécifiques des réseaux radio, nous avons signalé la
facilité avec laquelle il est possible pour un tiers d’écouter passivement les communications radio.
Afin de se prémunir contre ces écoutes passives, peu de moyens physiques existent (on peut essen-
tiellement chercher à faire en sorte que les signaux de nos stations de base ne soient reçus avec une
puissance suffisante que dans les zones que l’on contrôle, comme nos bureaux ou les hangars de
notre usine). Mais même un placement spécialement pensé des stations de base est mis en défaut
si ”l’espion” utilise une antenne à fort gain.
Le chiffrement des données est donc nécessaire si l’on recherche une certaine confidentialité.
802.11 décrit de ce fait une méthode de chiffrement : c’est la Wired Equivalent Provacy ou WEP,
qui peut être utilisée de manière optionnelle. Le système repose sur une clef secrète qui doit
être partagée par l’émetteur et le récepteur. La distribution de cette clef est en dehors du cadre

34
CHAPITRE 2. PRÉSENTATION DE 802.11

IV

Séquence pseudo-
Vecteur aléatoire de chiffrement
Graine
d'Initialisation (IV) RC4
(concaténation Partie
Clef secrète IV + clef) chiffrée

Message
en clair
Chiffrement
Algorithme d'intégrité (CRC) (OU exclusif)

Code de vérification Message


d'intégrité concaténé aux
données

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 d’authentification élaborés. Nous ne détaillerons pas ces systèmes qui sortent
également du cadre de ce travail, mais la compréhension du mécanisme de chiffrement aura son
importance, en particulier lorsque nous présenterons plus tard des résultats de mesures de débit réel.

Le principe du WEP est de combiner une séquence pseudo-aléatoire générée à partir de la


clef avec les données. Seul le récepteur qui connaı̂t aussi la clef pourra générer la même séquence
pseudo-aléatoire et décoder le message. La figure 2.23 donne les détails de ce chiffrement :
– Afin de renforcer la clef, on la combine avec un vecteur d’initialisation qui est changé à chaque
paquet. L’idée est d’éviter qu’une même clef soit utilisée souvent, et en particulier plusieurs
fois consécutives.
– La concaténation de la clef et du vecteur d’initialisation sert de graine pour l’algorithme RC4
qui va générer la séquence pseudo-aléatoire de bits.
– D’autre part, un code de redondance cyclique (CRC) est calculé sur les données, et y est
concaténé.
– Un OU exclusif est utilisé pour combiner la séquence pseudo-aléatoire et les données à chiffrer
(c’est le chiffrement proprement dit).
– Le vecteur d’initialisation est concaténé aux données chiffrées et le paquet est envoyé (l’IV
doit être en clair, le récepteur n’a pas de moyen de prévoir quelle sera sa valeur).
A la réception, le mobile connaı̂t déjà la clef secrète. Il lui adjoint le vecteur d’initialisation
qu’il trouve au début du paquet et génère la même séquence pseudo-aléatoire que celle qui a servi à
crypter. Avec un OU exclusif entre les données chiffrées et la séquence pseudo-aléatoire, il obtient
directement les données en clair. La vérification du CRC lui permet d’être sûr qu’aucune erreur ne
s’est produite et que sa clef était la bonne.

Au sujet de RC4, [34] nous apprend que c’est un algorithme basé sur des permutations. Une table
de 256 octets est initialisée avec la clef qui lui est fournie, et les éléments de la table vont ensuite
être permutés les uns les autres en fonction de leur valeur. Cet algorithme est réputé sûr et a en
outre l’avantage d’être très rapide (suivant le micro-processeur, entre 8 et 16 opérations simples sont
nécessaires pour produire un octet pseudo-aléatoire). Ceci est d’ailleurs particulièrement important
car les cartes réseau 802.11 n’embarquent pas en général des processeurs très puissants.

35
CHAPITRE 2. PRÉSENTATION DE 802.11

)
7 µs
µs)

µs)

µs)
(24.
620

192
1 MBits/s

(771
der
µs)

er (

data
2 MBits/s

hea
d
(50

off (

hea
Mac

Mac
S
11 MBits/s

s)
Phy
DIF

Bac

92 µ

µs)
1

(56
)

er (
0 µs
Emetteur

data
hea
S (1

ACK
Phy
SIF
Trame de données
987.7 µs
Récepteur

Acquittement

248 µs

1295.7 à 1915.7 µs

Temps

Fig. 2.24 – Une trame de données 802.11 à 11Mbits/s et son acquittement

2.6 Les trames 802.11b et le débit utile 802.11b


Dans la suite de nos travaux, lorsqu’il s’est agit d’effectuer des mesures avec des véritables
cartes, nous avons utilisé 802.11b. Nous détaillons donc ici plus en détail le fonctionnement et la
construction des trames, de manière à pouvoir comparer plus tard les débits pratiques aux débits
théoriques.

Sans détailler le contenu de chaque champ, il est tout de même important de savoir que les
paquets envoyés par 802.11 sur le médium radio comprennent plusieurs niveaux d’encapsulation.
Aux données venant des couches supérieurs, au moment de l’envoi, est ajoutée une en-tête MAC
ainsi qu’une en-tête physique. Les vitesses de transmission pour certaines de ces parties peuvent
varier. L’en-tête physique est envoyée à la vitesse constante de 1 Mbit/s. L’objectif est de permettre
sa réception par toute station utilisant une carte 802.11b (et ainsi permettre la cohabitation entre
la version d’origine et les versions plus rapides, 802.11g comprise).
L’en-tête MAC et les données sont envoyés à une vitesse négociée qui peut aller jusqu’à 54
Mbit/s avec 802.11g.
Les paquets de contrôle (RTS/CTS/ACK) sont envoyés quand à eux à des vitesses qui peuvent
encore être différentes. La norme indique que ces paquets doivent être envoyés à une vitesse choisie
dans la liste de celles qui vont permettre leur réception par tout autre mobile compatible. Mais
ces vitesses ne sont pas données explicitement. Dans la pratique, la plupart des constructeurs
permettent à leurs paquets de contrôle d’être envoyés à 2 Mbit/s et se replient sur 1 Mbit/s si les
taux d’échec sont trop importants. D’autres cependant proposent de les envoyer jusqu’à 11 Mbit/s,
proposant ainsi des performances supérieures à leurs concurrents lorsque les conditions sont idéales.
Comme les paquets de contrôle, les paquets envoyés en mode diffusion le sont à des vitesses choisies
dans la liste des vitesses ”compatibles”. Par défaut, la diffusion se fera donc à 2 Mbit/s. Il faut
noter enfin que c’est bien l’ensemble des paquets qui sont sujets à cette encapsulation et que même
les paquets de contrôle possèdent une en-tête physique qui est envoyée à 1 Mbit/s.

36
CHAPITRE 2. PRÉSENTATION DE 802.11

Si l’on décompose complètement l’envoi d’un paquet UDP de 1032 octets de données à 11
Mbits/s (figure 2.24), on observe (en considérant qu’il n’y a pas eu de collision ou de perte de
paquet avant et que le canal vient juste de se libérer) :
- Un temps d’attente fixe DIFS de 50 µs (compté à partir du moment où le canal devient libre)
- Un temps d’attente aléatoire (backoff) d’une durée comprise entre 0 et 31 time-slots de 20 µs
chacun (0 à 620 µs au total donc).
- L’envoi de la trame de données (qui dure ici 987.7 µs) décomposée en :
- L’en-tête physique de la trame, à 1 Mbit/s, qui dure 192 µs.
- L’en-tête MAC de la trame, à 11 Mbit/s, qui dure 24.7 µs.
- Les données proprement dites (ici 1032 octets de données application plus 28 octets
d’en-tête IP) envoyées à 11 Mbits/s, et qui durent 771 µs.
- Un temp d’attente fixe SIFS de 10 µs.
- L’acquittement, décomposé en :
- L’en-tête physique de la trame, à 1 Mbit/s, qui dure 192 µs.
- L’acquittement MAC, à 2 Mbits/s, qui dure 56 µs.
En utilisant ces paramètres, nous avons calculé les débits maximums possibles en fonction de
la taille des paquets. Il faut noter que dans la réalité, les paquets de grande taille peuvent être
fragmentés par les couches supérieures si elle croient avoir affaire à 802.3 (Ethernet, dont la taille
des trames ne dépasse pas 1500 octets environ). Dans nos calculs, nous avons donc tenu compte de
cette fragmentation. Les figures 2.25, 2.26 et 2.27 présentent les débits théoriques pour des vitesses
respectives d’émission physique des données de 11, 5.5 et 2 Mbit/s. Il faut noter que les courbes
présentées ont pour but d’être comparées dans la suite du document à des mesures réelles. Le lecteur
intéressé par les débits théoriques de 802.11 les trouvera dans [35] pour ses diverses extensions, mais
sans la prise en compte de la fragmentation cependant.

37
CHAPITRE 2. PRÉSENTATION DE 802.11

8e+06
11 Mbit/s
11 Mbit/s, fragmentation
7e+06 11 Mbit/s, RTS
11 Mbit/s, RTS, fragmentation

6e+06
debit en bits par secondes

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 – Débits maximums théoriques en fonction de la taille des paquets (à 11 Mbit/s)

8e+06
5.5 Mbit/s
5.5 Mbit/s, fragmentation
7e+06 5.5 Mbit/s, RTS
5.5 Mbit/s, RTS, fragmentation

6e+06
debit en bits par secondes

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.26 – Débits maximums théoriques en fonction de la taille des paquets (à 5.5 Mbit/s)

38
CHAPITRE 2. PRÉSENTATION DE 802.11

8e+06
2 Mbit/s
2 Mbit/s, fragmentation
7e+06 2 Mbit/s, RTS
2 Mbit/s, RTS, fragmentation

6e+06
debit en bits par secondes

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.27 – Débits maximums théoriques en fonction de la taille des paquets (à 2 Mbit/s)

39
CHAPITRE
Particularités de 802.11 dans
3 un contexte ad hoc

3.1 Introduction
802.11 a été conçu dans l’optique de réseaux d’entreprises ou de hot spots organisés autour de
stations de base. Nous avons vu que de part son faible coût, sa disponibilité (aussi bien commerciale
que dans les simulateurs) et par sa possibilité à être utilisé pour des réseaux multi-sauts par la simple
adjonction de protocoles de routage de niveau supérieur, 802.11 est devenu le support privilégié
pour l’étude des réseaux ad hoc. Mais un certain nombre de problèmes apparaissent, qui peuvent
être regroupés en plusieurs catégories :
– Des problèmes de topologie radio. Ils apparaissent lorsque les mobiles sont placés dans
des configurations bien spécifiques (des mobiles ne pouvant communiquer qu’avec certains de
leurs voisins, ou encore ne détectant les porteuses que de certains autres). Ces problèmes sont
connus depuis longtemps dans le contexte des réseaux à stations de base. 802.11 intègre des
solutions pour certains (les nœuds cachés) et en laisse d’autres de côté (les nœuds exposés
par exemple). Mais lors du passage à des réseaux multi-sauts, ces problèmes dévoilent de
nouvelles facettes qu’il est nécessaire de prendre en considération.
– Des problèmes liés aux débits multiples. 802.11 propose plusieurs vitesses de transmis-
sion parmi lesquelles les mobiles choisissent en fonction des conditions du canal (les vitesses les
plus basses sont plus tolérantes aux perturbations radio et permettent une meilleure portée).
Le fait de pouvoir utiliser plusieurs vitesses différentes va avoir des répercussions dans un
réseau ad hoc. D’une part en terme de débit, puisque des problèmes déjà connus dans les
réseaux à stations de base risquent d’y être magnifiés. Et d’autre part en terme de connec-
tivité, en particulier lorsque les protocoles de routage utilisent des paquets ayant une plus
grande portée que les données qui doivent être envoyées ensuite.
– Des problèmes d’équité entre des flux multiples et de débit total dans le réseau.
802.11 étant prévu pour fonctionner dans des configurations où la plupart des mobiles sont à
portée les uns des autres (ou dans le pire des cas voisins à deux sauts), ses performances dans
des configurations multi-sauts sont nettement en deçà des optimums théoriques, en terme de
débit et d’équité d’accès au canal.

3.2 Le problème des nœuds cachés


Le problème des nœuds cachés a été introduit dans le chapitre 2 en même temps que le
mécanisme RTS/CTS utilisé pour le corriger. Il faut cependant bien noter que dans le cadre prévu
par 802.11, ce problème n’apparaı̂t que dans une configuration comme celle de la figure 3.1, où deux
mobiles isolés l’un de l’autre, utilisant une même fréquence et attachés à une même station de base

40
CHAPITRE 3. PARTICULARITÉS DE 802.11 DANS UN CONTEXTE AD HOC

A B H

A B

Fig. 3.1 – Noeuds cachés simples C F G

ACK
A B C D E

D E

Fig. 3.2 – Noeuds cachés dans une chaı̂ne Fig. 3.3 – Multiples nœuds cachés

veulent émettre vers cette dernière en même temps. Dans ce contexte, le mécanisme de RTS/CTS
est effectivement efficace. Pour peu que la charge du réseau soit importante, [36, 37] ont montré par
le calcul et des simulations que le surcoût en terme de débit des RTS/CTS est plus que compensé
par le gain qu’il procure en évitant des collisions à répétition.
Dans un réseau ad hoc basé sur 802.11, nous avons vu que tous les mobiles devront travailler
sur la même fréquence s’ils veulent permettre une connectivité complète du réseau. De ce fait, les
situations de nœuds cachés vont être beaucoup plus nombreuses et plus fréquentes. La figure 3.2
donne un exemple de chaı̂ne à quatre sauts. A l’instant considéré, les mobiles B et D, qui ne s’en-
tendent pas du tout, veulent émettre. Il va donc y avoir collision au niveau du nœud C. Attention,
il faut bien noter que sous la plupart des simulateurs cette configuration ne se produira jamais car
les zones de détection de porteuse étant parfaitement circulaires et d’un rayon double de la zone
de communication, B se trouverait dans la zone de détection de porteuse de D et réciproquement.
Mais dans la réalité, l’expérience a montré que ce type de collision était tout à fait possible, nous
le verrons d’ailleurs par la suite. La figure 3.3 quant à elle, présente une configuration encore plus
complexe. Là encore, de nombreuses situations de collisions se présentent, du fait de l’utilisation par
tous les nœuds d’une seule et même fréquence. Le communications désirées sont (A→B), (D→E),
(C→F) et (H→G). Si ces transmissions avaient lieu en même temps, des collisions entre les données
pourraient se produire en B et en E, et, suivant la longueur des paquets, l’acquittement renvoyé par
F pourrait provoquer une collision en G avec les données venant de H. Ces constatations tendraient
à nous faire penser que l’utilisation des RTS/CTS serait la solution à ces problèmes. Malheureu-
sement les RTS/CTS sont aussi sujets à problèmes dans les réseau ad hoc. D’une part eux aussi
peuvent entrer en collision (par exemple, sur la figure 3.3, si les CTS de B et E ne sont pas reçus avec
une puissance suffisante en C pour être compris, alors C pourra émettre et éventuellement causer
des collisions en B et en E). D’autres configurations spécifiques posant problème sont également
décrites et analysées plus en détail dans [38] ou encore dans [39]. Nous verrons par ailleurs dans
nos propres simulations et expériences des situations où les RTS/CTS sont mis en défaut, lorsqu’ils
ne peuvent être compris correctement.

41
CHAPITRE 3. PARTICULARITÉS DE 802.11 DANS UN CONTEXTE AD HOC

A B C D

Fig. 3.4 – Le phénomène des nœuds exposés

Zone de communication à 11 Mbit/s

Zone de communication à 2 Mbit/s

Fig. 3.5 – Le phénomène de la zone grise

3.3 Le problème des nœuds exposés


Le problème des nœuds exposés apparaı̂t dans des configurations comme celle présentée sur
la figure 3.4. Ici, les nœuds B et C voudraient émettre respectivement vers A et D. En suivant le
mécanisme de la DCF, celui qui a tiré le plus petit backoff va accéder au canal et envoyer son paquet,
alors que l’autre détectera la porteuse du premier, et entrera en période de defering. Pourtant, si
B et C émettaient en même temps, le signal de B au niveau de A serait largement supérieur à celui
de C et suffisant pour une réception correcte. La situation serait l’inverse au niveau du nœud D,
qui recevrait correctement le paquet de C, malgré le léger bruit venant de B. Dans cette situation,
la DCF limite donc inutilement la bande passante totale du réseau. On peut noter que certains
travaux s’intéressent au problème, notamment [40] qui propose l’utilisation d’un mécanisme de
parallel RTS pour le résoudre en partie.

3.4 Le problème de la zone grise


Nous avons vu que 802.11b utilise des vitesses de transmissions de 1 ou 2 Mbit/s pour les
paquets qu’il diffuse, mais que les paquets envoyés en unicast peuvent l’être 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 diffusés par exemple). Ces paquets sont donc émis
à 2 Mbit/s et permettent de construire un certain nombre de routes dans le réseau. Mais lorsque
les données sont ensuite envoyées à 11 Mbit/s sur ces routes, comme la portée de communication
décroı̂t avec l’augmentation de la vitesse, il est possible que des mobiles pourtant à portée des
paquets de routage lents soient trop loin pour les paquets de données rapides. Il en découle que
les routes construites avec les paquets diffusés ne sont pas forcément exploitables à des débits plus

42
CHAPITRE 3. PARTICULARITÉS DE 802.11 DANS UN CONTEXTE AD HOC

élevés. La zone concernée (la soustraction de la zone ”rapide” à la zone ”lente” plus large) est
appelée ”zone grise” et ce problème avait été relevé théoriquement et expérimentalement dans [41].

3.5 Partage du canal entre des flux à vitesses différentes


En sus du phénomène des zones grises, l’utilisation des débits multiples que propose 802.11
conduit à d’autres problèmes. Lorsque des mobiles implémentant 802.11 rencontre de forts taux de
perte, la norme leur recommande de réduire leur vitesse d’émission (plus la vitesse est basse, plus
le signal est résistant aux interférences et est compréhensible loin de l’émetteur). Mais, comme il
l’est montré en détail dans [42], la méthode DCF d’accès au médium ne cherche pas à équilibrer les
débits de plusieurs flux en contention, mais plutôt à donner à chaque paquet des chances équitables
d’être envoyé. Lorsque certains paquets sont envoyés à des vitesses élevées et d’autres à des vitesses
lentes, cela va se traduire par une alternance plus ou moins régulière entre eux. Les mobiles émettant
leurs paquets très lentement vont donc ”capturer” le canal pendant la majorité du temps et faire
chuter le débit des autres mobiles qui ne prennent pourtant pas beaucoup de temps pour émettre
leurs propres paquets. Ainsi, dans un environnement de compétition entre plusieurs mobiles, si l’un
d’entre eux émet à 1 Mbit/s, même si tous les autres travaillent à 11 Mbit/s, leurs débit utile sera
très bas. Dans un environnement ad hoc, du fait du mécanisme de routage qui utilise en général les
paquets diffusés à 2 Mbit/s (comme noté au paragraphe 3.4), beaucoup de liens ainsi découverts
ne supporteront pas des débits élevées (5.5 ou 11 Mbit/s) et s’en tiendront au débit réduit de
2 Mbit/s. Les trafics sur les liens où le 11 Mbit/s est possible seront donc le plus souvent affectés
considérablement par ces autres liens plus lents.

3.6 TCP et 802.11


TCP est un protocole extrêmement utilisé dans le monde filaire. Afin de pouvoir utiliser direc-
tement dans les réseaux ad hoc les innombrables applications qui sont basées sur TCP, il faut que
les performances de ce dernier dans ce contexte soient suffisantes. Un certain nombres d’études ont
été conduites sur le comportement de TCP lorsqu’il est utilisé au-dessus de 802.11 [43, 10, 44] et
des problèmes conséquents sont apparus. Les auteurs de ces articles se sont intéressés à des confi-
gurations ad hoc diverses, parmi lesquelles la chaı̂ne se trouvaient à chaque fois. Ils ont utilisé des
simulateurs (Network Simulator 2 et Glomosim) et ont constaté les problèmes suivants :
– L’instabilité des connexions. Les flux TCP sont très souvent stoppés, et doivent reprendre
à chaque fois en passant par la phase de démarrage lent. Ces interruptions sont dues à la
détection de cassure de liens au niveaux MAC. Il a été montré que la taille de la fenêtre TCP
avait un impact très important sur ce problème, mais qu’il prend véritablement racine dans
la couche d’accès au médium.
– L’inégalité entre certains flux. Dans certaines configuration multi-sauts, alors que l’on voudrait
que plusieurs flux TCP se partagele canal, il arrive que certains d’entre eux ”capturent” le
canal et que d’autres soient complètement stoppés ou presque.
Malheureusement, bien qu’elles aient soulevé certains problèmes, ces études sont basées sur certaines
configurations où l’analyse des phénomènes et de leurs origines est rendu complexe par l’empile-
ment des protocoles et leurs diverses interactions. De plus, comme nous le verrons, ces problèmes
peuvent encore être classés en plusieurs catégories, la couche physique elle-même joue un rôle dans

43
CHAPITRE 3. PARTICULARITÉS DE 802.11 DANS UN CONTEXTE AD HOC

certains d’entre eux et en environnement réel, certains autres vont encore apparaı̂tre qui avaient
été totalement omis dans ces études.

3.7 Capacité théorique en fonction la topologie (grille, chaı̂ne)


Certains travaux se sont attachés à évaluer la capacité théorique (en terme de bande passante)
des réseaux ad hoc basés sur 802.11. [45] s’intéresse au trafic dans des topologies régulières (chaı̂ne
et grille de nœuds). Au travers de simulations, les auteurs montrent que 802.11 peine à offrir une
bande passante optimale dans ce type de configuration. Le premier nœud de la chaı̂ne cherche à
envoyer autant de paquets que possible (sa file d’attente est pleine en permanence). Les nœuds
situés plus loin sur la chaı̂ne ne peuvent envoyer des paquets que s’ils en ont préalablement reçu.
De plus, les premier nœuds (et en particulier le tout premier) ont moins de voisins avec qui entrer en
contention que ceux situés plus loin. Il en résulte que les premiers nœuds utilisent une grande part
de la bande passante pour envoyer des paquets que leurs successeurs ne pourront de toute façon pas
tous retransmettre du fait de la haute contention qu’ils recontrent. Dans ces conditions d’inégalité
de contention et de trafics offerts, la couche MAC de 802.11 ne peut pas produire l’ordonnancement
qui aurait donné le meilleur débit total.
Dans l’étude de la grille, le problème et confirmé. Il y apparaı̂t d’autre part que les schémas des
trafics vont avoir eux aussi un grand impact sur les performances globales (si les flux sont éloignés
les uns des autres, s’ils se croisent, etc.). A ce niveau, le type d’application va être très important,
tout comme les protocoles de routage utilisés.
Si les auteurs de [45] apportent une explication intéressante sur les faibles débits obtenus dans
des configurations régulières comme la chaı̂ne ou la grille, nous proposons néanmoins dans le cha-
pitre 4 notre propre évaluation et analyse de 802.11 dans une chaı̂ne de mobiles. Ce travail qui
aurait pu paraı̂tre redondant nous a en fait semblé nécessaire pour plusieurs raisons :
– Les mesures de base de 802.11 proposées dans [45] n’étaient pas cohérentes avec celles que
vous avions obtenues, et certains arguments avancés nous semblaient en contradiction avec
nos propres connaissances de NS2.
– Les outils avancés d’analyse que nous avions mis en place permettaient une évaluation plus
poussée que celle proposée dans [45].

3.8 Equité
Plusieurs travaux ont mis en lumière certains problèmes d’équité dans l’accès au médium radio
qui pouvaient survenir avec l’utilisation de 802.11. Le protocole MACAW [46], un des ancêtres
de 802.11 publié en 1994 (et qui avait d’ailleurs introduit l’utilisation des acquittements), avait
déjà remarqué le problème. Il proposait en particulier un mécanisme pour résoudre l’inégalité entre
mobiles qui provenait de l’utilisation du principe de Binary exponential Backoff dans l’ajustement
de la fenêtre de contention.
Dans [47], les auteurs présentent trois scénarios qui montrent une inégalité dans l’accès au
médium radio avec 802.11. Ils s’intéressent à l’inégalité par nœud ainsi qu’à l’inégalité par flux.
Ils expliquent que cette inégalité provient d’une asymétrie des zones de contention de mobiles. Si
intuitivement on sent bien que cette asymétrie va gêner fortement les mobiles connaissant le plus de
contention, les auteurs ne donnent pas d’explications détaillées du dysfonctionnement de 802.11 face
à cette asymétrie. En plus des problèmes d’asymétrie mentionnés par [47], les travaux de Bensaou

44
CHAPITRE 3. PARTICULARITÉS DE 802.11 DANS UN CONTEXTE AD HOC

et al. [38, 48] soulèvent un problème d’inégalité provenant de collisions répétées dans le cadre de
réseaux ad hoc particuliers.

3.9 Conclusion et positionnement


Cet état de l’art montre qu’un certain nombre de problèmes ont été mis en évidence avec
l’utilisation de 802.11 dans les réseaux ad hoc. Certains travaux ont été réalisés avant ma thèse (les
plus anciens vraiment spécifiques à ce contexte datant de 1999, les autres ayant été publiés au cours
de ma thèse, celle-ci ayant commencé en 2000). Chacun de ces travaux soulève une problématique
bien particulière mais aucun ne propose une analyse complète de 802.11 dans un cadre ad hoc.
Enfin, la majorité de ces travaux se basent sur des résultats de simulation (hormis [41, 42] qui
réalisent quelques expérimentations).
Dans cette thèse, nous avons essayé de mener un travail complet sur les performances de 802.11
dans les réseaux ad hoc. Nous avons tenté de dégager les scénarios de base qui permettent de
lister les différents problèmes soulevés et d’y apporter des explications ciblées. Grâce à ces simula-
tions, certains des phénomènes observés dans la littérature ont été retrouvés, tandis que d’autres
caractéristiques ont été dégagées.
Enfin, contrairement aux travaux existants, un long travail d’expérimentations de 802.11 dans un
contexte ad hoc a été réalisé au cours de cette thèse. Ce travail a permis d’une part de connaı̂tre les
performances réelles de 802.11, et d’autre part d’éclairer les problématiques sous un angle nouveau.

45
Première partie

Simulations logicielles de réseaux


ad-hoc

46
CHAPITRE
Simulations : introduction et
4 scénarios de prise en main

4.1 Introduction
La communauté ad-hoc concentre une grande part de son attention sur les protocoles de routage.
Cela était d’autant plus vrai au moment du début de ma thèse, alors que le groupe MANET de
l’IETF voyaient de nombreux nouveaux protocoles présentés, et qu’aucun d’entre eux n’était assez
stabilisé pour envisager une normalisation. Pour développer, tester et valider ces algorithmes, les
chercheurs se sont très rapidement tournés vers les simulateurs. Ceci est en premier lieu du à des
raisons pratiques. Il est peu commode de déployer un protocole sur un réseau réel composé d’un
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 matériel nécessaire (problème de coût et de logistique ...
et si l’on veut tester des scénarios présentant de la mobilité, de la ”main d’œuvre” est nécessaire).
Lorsque nous avons commencé ces travaux, notre laboratoire ne disposait d’aucun équipement
radio. C’est donc très logiquement que nous nous sommes nous aussi tournés vers la simulation.

4.2 Objectifs initiaux des simulations


Dans la seconde moitié des années 90, avec l’élaboration de plusieurs normes pour les réseaux
sans fils à portée limitée (visant des usages à l’échelle du bureau ou du bâtiment), un certain
nombre de simulateurs ont été développés 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 réseaux le plus utilisé par la communauté ad-hoc. Il est
gratuit et son code source est disponible ; autant d’avantages qui font qu’il est largement mis à
contribution par les chercheurs désireux d’évaluer les performances des protocoles de routage qu’ils
développent. Lorsque nous avons commencé à vouloir tester des heuristiques et divers algorithmes
se rapportant aux réseaux ad-hoc, c’est donc logiquement vers NS2 que nous nous sommes tournés.
L’installation ainsi que la prise en main du logiciel et des outils l’accompagnant a été relativement
aisée ; une fois la décision prise d’effectuer des simulations, nous avons donc pu rapidement nous
lancer dans nos premières simulations.
Dans un premier temps, et puisque que nous n’étions pas du tout familiers des réseaux sans
fils, ces simulations ont consisté en des scénarios simples, permettant de se faire une idée des
comportements de base des mobiles utilisant 802.11. Nous nous sommes par exemple intéressés
aux différents modèles de propagation disponibles ou aux débits et distances de communication
maximum.

47
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

Après cette étape de prise en main, nous nous sommes intéressés plus spécifiquement à des
scénarios typiques des réseaux ad-hoc (communication nécessitants plusieurs ”sauts” et problèmes
d’interférences).
Dans de nombreux articles ([53, 54, 55]) dont l’objectif est de vérifier que les protocoles de
routage arrivent bien à construire et maintenir les routes, les flux de données sont très faibles (en
général moins de 8 ou 10 paquets par seconde et par source, envoyés à une vitesse constante).
Dans ces articles, les modèles de mobilité jouent également un rôle très importants. Le Random
Waypoint, utilisé pour la première fois dans [56] puis plus tard raffiné dans [54] est certainement le
plus utilisé. Il consiste en :
– Le placement d’un certain nombre de mobiles (typiquement 50 à 100) dans une zone carrée
de laquelle ils ne peuvent sortir.
– L’affectation d’une position, d’une vitesse et d’une destination initiale à chaque mobile.
– La sélection aléatoire des émetteurs et de la destination de leurs paquets.
– Le déroulement proprement dit de la simulation, où à chaque fois que les mobiles atteignent
leur destination dans le carré, ils repartent vers une autre destination choisie aléatoirement
après un éventuel temps de pause.
Il faut noter que ce modèle assez simple a été sujet à critiques, notamment dans [57] où l’instabilité
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 aléatoirement, des mobiles vont
parfois choisir des destination lointaines et des vitesses très lentes, et il leur faudra énormément
de temps pour y arriver. Plus la simulation sera longue, plus le nombre de mobiles ”coincés” dans
cette situation va augmenter, et la proportion de mobiles ”lents” va croı̂tre de façon gênante.
Quoiqu’il en soit, il est clair que les performances de chaque protocole de routage dépendent
beaucoup des conditions d’utilisation (certains sont conçus pour fonctionner dans des petits réseaux
à forte mobilité, d’autres dans de grands réseaux, etc.). Pour pouvoir construire des modèles de
mobilité vraiment pertinents, il faudrait idéalement pouvoir disposer d’informations sur le contexte
dans lequel le réseau ad hoc sera réellement déployé , et ceci est généralement impossible.
Mais contrairement à ce que l’on rencontre en général dans la littérature, nous avons cherché
à voir ce qui se produisait quand le réseau arrivait à saturation. Nous ne cherchions pas à tester
les algorithmes de tel ou tel protocole de routage, nous voulions plutôt savoir ce qui se passerait
(en terme de débit, de connectivité et de délais) quand des flux très importants sont présents
entres certains mobiles dans un réseau ad-hoc. Ceci était motivé par l’idée que dans de nombreuses
circonstances, le trafic s’effectue plutôt par rafale (comme par exemple la navigation web, le transfert
de fichiers ou même la consultation d’e-mails). Dans nos scénarios, nous avons donc en général utilisé
des flux cherchant à occuper complètement la bande passante. Ces conditions de saturation sont
un élément important de nos travaux et les différencie d’une grande majorité de ceux effectués
précédemment et qui n’utilisaient que des flux très peu gourmands.

4.3 Présentation de Network Simulator 2


NS2 est un simulateur à événements discrets développé dans un but de recherche [58]. Il fournit
un environnement assez détaillé permettant entre autre de réaliser des simulations d’IP, TCP, du
routage et des protocoles multicast aussi bien sur des liens filaires que sans fil.
Network simulator 2 a été originellement développé en tant que variante du ”REAL network
simulator” en 1989, et a considérablement évolué au cours des années. En 1995, NS2 était développé

48
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

par le projet VINT. Actuellement, son développement est supporté par le DARPA à travers SAMAN
et par la NSF à travers CONSER, tout en incluant de nombreuses contributions extérieures, comme
en particulier les codes pour les réseaux sans fils des projets Daedalus de l’UCB et Monarch de la
CMU et de Sun Microsystems.
NS2 est écrit en C++ et en oTCL, et il est fourni avec divers outils d’analyse complémentaires
eux-mêmes écrits en C/C++ ou TCL/Tk.
NS2 implémente la version de 1997 de la norme 802.11. A ce titre, le débit maximum possible
est de 2 Mbit/s. Il faut noter également que ce logiciel est développé, corrigé et étendu au fur et
à mesure de l’apparition de nouveaux besoins (ou de la découverte d’erreurs). Ainsi, au cours du
déroulement de cette thèse, plusieurs versions se sont succédées, apportant leurs lots de corrections
et améliorations diverses.
Compte tenu de nos objectifs, nous avons bien sûr essentiellement mis à contribution la partie
IP/UDP/TCP en environnement sans fil. NS permet de positionner sur un plan virtuel des mobiles
équipés d’émetteurs radio, et il gère la mobilité de ces nœuds dans le temps. Pour qu’un paquet
émis sur une interface sans fil sous NS2 soit reçu, il faut qu’il arrive au destinataire avec un niveau
de signal supérieur à un certain seuil. Ce seuil est par défaut de 3.652 × 10−10 W, et nous l’avons
laissé à cette valeur pour toutes les simulations qui seront présentées par la suite.

4.3.1 Les différents modèles de propagation radio sous NS2


NS2 permet également de choisir parmi les modèles de propagation suivants, qui influeront en
particulier sur la manière dont seront atténués les signaux en fonction de la distance :
– Free space model : Ce modèle considère le cas idéal où il y a un seul chemin de propagation
entre l’émetteur et le récepteur et qu’il est en vue directe. H.T. Friis a présenté dans [59]
l’équation suivante pour calculer la puissance du signal reçu en environnement libre à une
distance d de l’émetteur.

Pt Gt Gr λ2
Pr (d) = (4.1)
(4π)2 d2 L
où Pt est la puissance d’émission, Gt et Gr les gains respectifs des antennes de l’émetteur
et du récepteur. L (avec L ≥ 1) est la perte du système, et λ est la longueur d’onde. Dans
nos simulations avec NS, nous prendrons toujours Gt = Gr = 1 et L = 1. Ce modèle de
propagation représente les zones de communication comme un cercle autour de l’émetteur.
Si un récepteur est dans ce cercle il reçoit tous les paquets, s’il est en dehors il n’en reçoit
aucun.
– Two-ray ground reflection model : En environnement réel, 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 à la fois le chemin direct et une réflexion sur le sol. Comme il est montré dans [60], ce
modèle donne des résultats plus justes que le modèle de propagation en espace libre quand
la distance est assez grande. La puissance reçue à une distance d est calculée de la manière
suivante :
Pt G t G r h t 2 h r 2
Pr (d) = (4.2)
d4 L
où ht et hr sont les hauteurs des antennes de transmission et de réception. Notez que l’équation
originelle dans [60] considère que L = 1. Afin que NS soit cohérent avec le modèle de propa-
gation en espace libre, L a été ajouté à l’équation.

49
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

Environnement β
En extérieur Espace libre 2
Zone urbaine obstruée 2.7 à 5
En intérieur En ligne de vue 1.6 à 1.8
Obstrué 4 à 6

Tab. 4.1 – Quelques valeurs typiques pour l’exposant d’atténuation β

L’équation précédente présente une décroissance de la puissance reçue en fonction de la dis-


tance plus rapide que l’équation (4.1). Cependant, pour des distances courtes, le modèle à
deux rayons ne donne pas de bons résultats (en raison d’oscillations causées par la combinai-
son constructive et destructive des deux rayons). Le modèle de propagation en espace libre
est donc utilisé à 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 ,
l’équation (4.1) est utilisée, et quand d > dc , on prend l’équation (4.2). A la distance seuil,
les équations (4.1) et (4.2) doivent donner les mêmes résultats ; la distance seuil dc peut donc
être calculée de la manière suivante :
4πht hr
dc = (4.3)
λ

– Shadowing model : Les modèles de propagation en espace libre ou utilisant deux rayons
calculent de manière déterministe la puissance reçue en fonction de la distance. Ils représentent
tous deux la zone de communication comme un cercle idéal. Dans la réalité, la puissance reçue
à une certaine distance varie de manière aléatoire, à cause des effets de propagation par des
chemins multiples. En fait, les deux modèles précédents calculent la puissance moyenne reçue
à une distance d. Le shadowing model est un modèle de propagation plus généraliste présenté
dans [60] et implanté dans NS2.
Le modèle ”shadowing” est composé de deux parties. La première est le modèle d’atténuation
en fonction de la distance, qui calcule la puissance moyenne reçue à une distance d, notée
Pr (d). Il utilise une distance courte comme référence, notée d0 . Pr (d) est calculée relativement
à Pr (d0 ) de la manière suivante :

Pr (d0 ) d

= (4.4)
Pr (d) d0
β est appelé l’exposant d’atténuation en fonction de la distance, et est généralement déterminé
de façon empirique par des mesures en environnement réel. D’après l’équation (4.1), on sait
qu’en espace libre β = 2. La table 4.1 donne quelques valeurs typiques de β. Les grandes
valeurs correspondent à une obstruction plus forte et donc à une décroissance plus rapide de
la puissance reçue en fonction de la distance. Pr (d0 ) peut être calculée à partir de l’équation
(4.1), en prenant par exemple d0 = 1 mètre.
L’atténuation en fonction de la distance est souvent mesurée en dB. A partir de l’équation
(4.4) nous avons
" #
Pr (d) d
 
= −10β log (4.5)
Pr (d0 ) dB
d0

50
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

Environnement σdB (dB)


En extérieur 4 à 12
Bureaux, séparations légère 7
Bureaux, murs 9.6
Usine, en ligne de vue 3 à 6
Usine, obstruée 6.8

Tab. 4.2 – Quelques valeurs typiques pour la déviation du shadowing σdB

La seconde partie du modèle shadowing reflète les variations de la puissance reçue à une
distance donnée. C’est une variable suivant une loi log-normale, c’est à dire dont la distribution
mesurée en dB est gaussienne. L’ensemble du modèle shadowing est représenté par
" #
Pr (d) d
 
= −10β log + XdB (4.6)
Pr (d0 ) dB
d0
où XdB est la variable aléatoire gaussienne dont la moyenne est zéro et l’écart type σdB . σdB
est appelé shadowing deviation, et est également obtenue par des mesures en environnement
réel. La table 4.2 donne quelques valeurs typiques pour σdB . L’équation (4.6) est aussi connue
sous le nom de log-normal shadowing model.
Le shadowing model étend le cercle idéal de communication à un modèle statistique plus riche ;
les nœuds ne peuvent communiquer qu’avec une certaine probabilité lorsqu’ils sont vers la
limite de portée.

4.3.2 La gestion des interférences


Le terme ”interférences” est souvent utilisé de façon générique, et recouvre en fait plusieurs
phénomènes qu’il est important de différencier. Avant tout, les conditions suivantes doivent être
remplies pour qu’un paquet puisse être reçu :
– La puissance du signal reçu doit dépasser un certain seuil (seuil de communication).
– Le rapport signal sur bruit ambiant doit être suffisamment grand (le signal doit être clairement
identifié, et non noyé dans le bruit).
Il existe un seuil de détection de porteuse. Si la puissance du signal est comprise entre ce seuil
et le seuil de communication, alors le message n’est pas compris mais l’activité sur le canal est
néanmoins détectée. Si l’on utilise le modèle two-ray ground (ou le modèle free-space), ces seuils
définissent donc deux zones autour d’un nœud. Si le récepteur est placé au centre de la figure 4.1,
alors un émetteur placé dans la zone interne (zone de communication) pourra lui envoyer des mes-
sages qui seront compris (en l’absence d’autres interférences). Si l’émetteur est placé dans la zone
externe (zone de détection de porteuse), la communication ne sera pas possible mais l’autre mobile
sera informé à chaque fois que l’émetteur accédera au canal. Si l’on utilise le modèle shadowing,
les deux zones sont également définies, mais leurs frontières sont ”floues” du fait du caractère
probabiliste du modèle. 802.11 impose qu’un mobile qui veut émettre doit d’abord s’assurer
qu’aucune autre communication n’est en cours dans son voisinage. Si une telle communication est
en cours, et si l’émetteur est suffisamment proche (c’est à dire dans la zone de communication)
du mobile qui voudrait lui aussi émettre, alors ce dernier a reçu l’en-tête du message et sait donc
(par l’intermédiaire de son Network Allocation Vector) pour combien de temps le canal doit encore
être occupé. Le nœud qui voulait émettre va donc attendre. Par contre, si le mobile qui veut

51
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

Zone de communication

Zone de détection de porteuse

Fig. 4.1 – Portée de communication et de détection de porteuse

aussi émettre est plus loin (dans la zone de détection de porteuse de l’émetteur) l’en-tête n’a pas
pu être comprise. Il est impossible dans ce cas de prévoir à l’avance quand on aura à nouveau
le droit d’émettre, il faut attendre que l’activité sur le canal disparaisse. Dans ces contextes,
les différents nœuds se gênent les uns les autres, et cela se traduit par un partage du canal entre eux.

Une fois ces précisions données, les différents facteurs à prendre en compte pour les interférences
sont :
– L’atténuation du signal en fonction de la distance et de l’environnement . C’est la prise en
compte uniquement de la distance dans le calcul d’atténuation qui donne sa forme circulaire
à la zone de couverture de la figure 4.1. C’est ce que fait NS2 (avec éventuellement un facteur
aléatoire supplémentaire dans le modèle shadowing).
– Le bruit ambiant est normalement la somme de tous les bruits perçus au niveau du
récepteur. Ce bruit de fond provient de l’environnement (passage de véhicules motorisés,
appareils bruiteurs divers, ...), mais aussi des autres mobiles du réseau. Sous NS2 il n’y a pas
de bruit de fond provenant de l’environnement, le signal reçu de l’émetteur est simplement
comparé à tour de rôle à chacune des autres sources du réseau actives à ce moment là. Ceci est
une limitation de NS2, car suivant les conditions, il se peut qu’aucune de ces sources de bruit
ne soit suffisante pour gêner la communication de manière indépendante, mais que leur somme
le soit. D’un manière générale, NS calcule donc une approximation du bruit qui est inférieure
à ce qu’elle devrait être. Il faut bien garder à l’esprit que si des problèmes d’interférences ap-
paraissent dans certains scénarios, l’impact de ces interférences en environnement réel serait
encore supérieur.

4.4 Traitements des résultats et outils d’analyse


NS2 écrit les résultats de ses simulations dans un fichier texte où chaque ligne correspond à
un événement qui s’est produit à un niveau ou à un autre de la pile protocolaire. Il est possible
de configurer NS2 de telle sorte qu’il ne garde une trace que de certains types d’événements (par
exemple tout ce qui concerne le routage, mais pas ce qui concerne la couche MAC). Ceci est en
particulier utilisé pour accélérer la simulation et réduire la taille du fichier.
Ce fichier texte peut porter en lui-même énormément d’informations. Mais pour extraire et
représenter de manière synthétique ces informations, il faut souvent appliquer de nombreux traite-

52
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

O 2

1 3

Fig. 4.2 – Scénario d’exemple pour le chronogramme

ments à ce fichier. Par exemple, si l’on veut calculer un débit sur un lien, il faut compter le nombre
de paquets transmis durant une certaine période entre certains nœuds et tenir compte de leur taille.
Comme l’ensemble des événements qui se sont produits se trouvent dans ce fichier et qu’ils ne sont
classés que par ordre chronologique, ceci peut se révéler pour le moins laborieux.
Ainsi, pour calculer les débits, on préfère plutôt agir au niveau du script TCL décrivant le
scénario. Certains objets utilisés dans les simulations sont capables de comptabiliser les paquets ou
les octets qui les traversent (comme ceux qui servent de récepteurs pour les flux TCP par exemple).
Ces informations peuvent être récupérées au niveau du script TCL, qui se charge alors de les écrire
dans un fichier.
Bien que ces deux techniques permettent déjà de récupérer énormément d’informations, ceci
n’a pas toujours été 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 détails que la simple
connaissance de l’échec ou de la réussite de la transmission d’un paquet au niveau MAC. Nous avons
donc ajouté du code dans NS2 qui nous permet, pour chaque nœud, de connaitre les moments où
il est en train :
– D’émettre sur le canal (toutes les émissions, les RTS/CTS et les acquittements seront donc
visibles séparéments).
– De décrémenter son backoff (avec des indications lorsque cette décrémentation est suspendue
puis reprise).
– D’attendre car son Network Allocaton Vector lui indique que le canal est occupé.
La configuration de cette nouvelle fonctionnalité se fait depuis le script TCL, et les informations
sont stockées dans des fichiers séparés du fichier de log principal de NS2. La visualisation se fait
grâce à un programme externe, qui représente graphiquement les informations sous la forme d’un
chronogramme.
Pour donner un exemple, nous considérons le scénario présenté sur la figure 4.2. Il y a deux
couples d’émetteur / récepteur situés juste à coté les uns des autres. Les nœuds 0 et 2 sont les
émetteurs, 1 et 3 sont les récepteurs. Les nœuds 0 et 2 cherchent à envoyer autant de paquets UDP
de 1000 octets que possible.
Le chronogramme est présenté sur la figure 4.3. Le temps est représenté de gauche à droite, son
échelle est indiquée en bas à gauche et à droite. Sur cette capture d’écran, nous avons zoomé de
façon à afficher uniquement ce qui se passait entre les secondes 11.023 et 11.04 de la simulation. Le
temps indiqué en bas au milieu correspond à la position du curseur de la souris (invisible sur cette
capture d’écran) ; il est souvent utile pour ”lire” directement les temps approximatifs des événements

53
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

Fig. 4.3 – Exemple de chronogramme partiel d’une simulation

dessinés. Les tirages d’un nouveau backoff ainsi que la fin de leur décrémentation sont signalés sur le
graphique par des petites barres verticales au bout des rectangles. Une barre en début d’un rectangle
de backoff indique qu’il vient d’être tiré au hasard et que sa décrémentation commence, une barre à
la fin indique qu’il a été décrémenté jusqu’à zéro et que l’émission va pouvoir commencer. L’absence
de barre verticale indique que la décrémentation a été temporairement stoppée ou qu’elle reprend.
Les douze fichiers de trace sont dessinés les uns en dessous des autres. Ici, on peut lire le
déroulement suivant de la simulation :
– Le nœud 2 est en train d’émettre (1). Le nœud 3 est en train de recevoir (ceci n’apparaı̂t pas
directement sur la figure, mais la présence d’un acquittement permettra ensuite de savoir si
cette communication s’est déroulée correctement), et les nœuds 0 et 1 savent qu’ils ne doivent
pas émettre (leur NAV leur indique que le canal est occupé).
– Le nœud 3 a fini de recevoir le paquet de données. Il retourne un acquittement (2). Les NAV
des nœuds 0 et 1 leur indiquent toujours qu’ils ne doivent pas émettre
– En (3), le canal devient libre. Les nœuds 0 et 2 veulent tous les deux émettre. Cette fois-là,
le nœud 2 a tiré un backoff très petit, dès qu’il a fini de le décrémenter, il émet un RTS
(4). Immédiatement, le nœud 0 détecte l’activité sur le canal et arrête de décrémenter son
backoff. Le RTS contenant la durée de la transmission de données qu’il annonce, cela permet
aux nœuds 0 et 1 de positionner leur NAV sitôt le RTS reçu.
– Le nœud 3 répond au RTS par un CTS (5), puis le nœud 2 y répond par l’envoi de ses
données, qui sont acquittées ... et ainsi de suite
Cet outil qui vient d’être présenté est simple d’utilisation. Grâce à lui nous serons par la suite
en mesure de réaliser une évaluation fine des scénarios simulés.

4.5 Prise en mains et premières simulations

54
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS 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 60.0000 80.0000 100.0000

Fig. 4.5 – Débits dans l’expérience des deux


mobiles s’éloignant (modèle free-space). En
Fig. 4.4 – Description de l’expérience des abscisse : distance en dizaines de mètres, en
deux mobiles s’éloignant ordonnée : débit en bits par seconde

1.8e+06 1.8e+06
modele two-ray ground sans RTS/CTS modele shadowing sans RTS/CTS
modele two-ray ground avec 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

debit en bits par seconde

1e+06 1e+06

800000 800000

600000 600000

400000 400000

200000 200000

0 0
0 100 200 300 400 500 600 700 0 100 200 300 400 500 600 700
distance en metres distance en metres

Fig. 4.6 – Débits en fonction de la distance avec Fig. 4.7 – Débit en fonction de la distance avec
le modèle two-ray ground. le modèle shadowing.

55
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS 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ée de communication et débit


Les toutes premières simulations réalisées ont pour but d’observer la portée et le débit de
l’implémentation de 802.11 disponible sous NS2. Les scénarios consistent à placer un émetteur et
un récepteur juste à coté l’un de l’autre. L’émetteur envoie un flux à débit constant de paquets UDP
de 1000 octets (il en envoie suffisamment pour saturer le canal). Progressivement, on déplace le
récepteur (figure 4.4). Nous effectuons cette simulation avec chacun des modèles de propagation pro-
posés, en utilisant à chaque fois AODV comme protocole de routage. Ces simulations nous servent
à comparer les modèles de propagation disponibles, et nous servent d’étalon pour les simulations
plus complexes qui vont suivre (nous rappelons que dans toutes ces simulations, le débit physique
simulé est de 2 Mbit/s, puisque c’est celui supporté par défaut par NS2). A chaque fois, nous avons
également effectué une simulation avec les RTS/CTS et une autre sans. Le débit maximum observé
sans utiliser les RTS/CTS est de 1.6 Mbit/s, et descend à environ 1.4 Mbit/s lorsqu’on les utilise.

Modèle free-space. Ce modèle de propagation est le plus simple proposé par NS2. Le débit obtenu
en fonction de la distance entre l’émetteur et le récepteur est présenté sur la figure 4.5. D’après ce
modèle, la puissance reçue diminue de manière continue avec la distance. Comme la réception d’un
paquet n’est possible que si la puissance est supérieure à un certain seuil, nous obtenons logiquement
une courbe où le débit est maximum jusqu’à une certaine distance (600 m) puis ensuite nul. Le
seuil de communication est la valeur par défaut de NS2 (3.652.1010 W). Dans la pratique, NS2
est passablement buggé , et au delà de 600 m, dans sa version 2.26, son comportement devient
imprévisible (débit non nul à très grande distance, variation au cours du temps à une distance fixe,
crash pur et simple de NS2, ...).

Modèle two-ray ground. Ce modèle de propagation est celui qui est généralement utilisé par la
communauté ad-hoc lorsqu’il s’agit de développer et tester des protocoles de routage. On observe
les résultats présentés sur la figure 4.6. On remarque que jusqu’à une certaine distance (250 mètres)
le débit est maximum, puis qu’au-delà les communications ne sont plus possibles du tout. Ceci est
tout à fait normal compte tenu du modèle de propagation utilisé. On remarque aussi l’impact sur le
débit de l’utilisation du mécanisme RTS/CTS. Dans ce scénario où l’on obtient un débit maximum

56
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

de 1.6 Mbit/s en leur absence, l’utilisation des RTS/CTS provoque une baisse du débit utile de
12% environ à 1.4 Mbit/s.

Modèle shadowing. Ce modèle est plus complexe que les précédents, il est probabiliste et utilise
aussi des informations récoltées sur le terrain. Le débit que l’on obtient avec lui en fonction de
la distance est présenté sur la figure 4.7. Le scénario est le même que précédemment (figure 4.4)
et les paramètres du modèle shadowing sont ceux par défaut ( β = 2.0, σdB = 4.0, d0 = 1 mètre
). Ce modèle de propagation donne, à partir d’une certaine distance, une probabilité de plus en
plus importante pour qu’un paquet soit perdu (signal trop atténué). Dans ce scénario, cela ce
traduit par une diminution progressive du débit, qui commence à baisser à partir de 250 mètres
environ, mais qui ne devient nul qu’au delà de 600 mètres. Avec le modèle shadowing, tout comme
avec le freespace, la portée de communication est très grande, nettement plus qu’avec le two-ray
ground. A courte distance, l’impact des RTS/CTS est le même qu’avec le modèle two-ray ground.
On remarque cependant que lorsque l’on utilise les RTS/CTS, lorsque la distance augmente, le
débit baisse beaucoup plus vite que quand on ne les utilise pas. Ceci est assez logique, puisque qu’il
suffit que l’un des paquets de contrôle soit perdu pour que la transmission échoue. Il faut également
noter que nous avons rencontré de nombreux ”plantages” de NS2 en utilisant ce modèle (sur la
figure 4.7, l’expérience sans RTS a en fait été arrêtée par un plantage du simulateur, qui n’a jamais
réussi à dépasser ce stade.
Sur les figures 4.8 et 4.9, on peut observer la distribution assez uniforme des pertes de paquets
engendrées par le modèle shadowing. Sur la figure 4.8, les nœuds ne sont espacés que d’une dizaine
de mètres. Il n’y a aucune perte de paquets, les paquets se suivent donc sans interruption sur le
canal, et un acquittement est envoyé pour chacun d’entre eux. Sur la figure 4.9, qui correspond à
une période où les deux nœuds sont déjà éloignés de 500 mètres, on remarque par contre qu’un
certain nombre de paquets de données ne sont pas acquittés, et même que parfois les paquets de
données ne sont plus envoyés (lorsque les acquittements eux-mêmes sont perdus, au bout d’un
certain nombre d’essais, la couche MAC notifie l’erreur à la couche supérieure, et un système de
timer va empêcher une tentative immédiate de retransmission). Sur les chronogrammes présentés,
c’est surtout la distribution dans les temps des acquittements manquants qui permet de bien
mettre en évidence la répartition assez homogène des erreurs de transmission avec le modèle
shadowing

Du fait que le modèle two-ray ground est utilisé en quasi exclusivité dans les simulations réalisées
dans la communauté ad-hoc, nous l’avons retenu pour la suite de nos travaux. Sauf mention
contraire, c’est donc ce modèle de propagation qui a été utilisé pour les simulations qui seront
présentées dans les paragraphes suivants.

4.5.2 Interférences
La seconde série de simulations avait pour objectif d’observer les interférences entre deux
émetteurs. Pour ce faire, nous avons utilisé quatre nœuds dans notre scénario, répartis en deux
paires. Au départ, tous les mobiles sont très proches les uns des autres, puis les deux paires vont
progressivement s’éloigner. Dans chaque paire, l’émetteur et le récepteur restent par contre très
proches (quelques mètres). Le trafic est un flux de paquets UDP de 1000 octets, envoyés aussi vite
que possible (on cherche à saturer la bande passante).

57
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS 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
debit en bits par secondes

debit en bits par secondes


1.2e+06
1e+06

1e+06

800000
800000

600000
600000

400000
400000

200000 200000
0 100 200 300 400 500 600 700 0 100 200 300 400 500 600 700
distance en metres distance en metres

Fig. 4.10 – Débit pour les deux paires Fig. 4.11 – Débit pour les deux paires
s’éloignant (sans RTS/CTS) s’éloignant (avec RTS/CTS)

Fig. 4.13 – Les deux paires ne


Fig. 4.12 – Les deux paires se comprennent plus mais se Fig. 4.14 – Les deux paires
s’entendent directement détectent sont totalement idépendantes

Fig. 4.15 – Chronogramme quand les paires sont en zone de communication

Fig. 4.16 – Chronogramme quand les paires sont en zone de détection de porteuse

58
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN

Les débits obtenus sur chacune des paires en fonction de la distance sont présentés sur les
figures 4.10 (sans RTS/CTS) et 4.11 (avec RTS/CTS). On remarque en premier lieu que l’utilisation
ou non du mécanisme de RTS/CTS ne change pratiquement rien à l’allure générale de la courbe.
Les RTS/CTS ne vont influer ici que sur le débit utile, qui est légèrement inférieur lorsqu’on les
utilise. On remarque ensuite la présence très nette de trois parties distinctes sur ces courbes.
– De 0 à 250 mètres, tous les mobiles sont à portée directe de communication les uns des
autres (figure 4.12). Le médium radio est partagé équitablement. Chaque paquet émis est
perçu par les trois autres mobiles qui peuvent en particulier mettre à jour leur NAV.
– De 250 à 550 mètres, les deux paires sont trop éloignées l’une de l’autre pour que le contenu
de leurs paquets soient compris (figure 4.13). Le NAV ne peut plus être mis à jour. Par contre,
le mécanisme de détection de porteuse est encore capable de déterminer quand des paquets
sont en cours de transmission dans l’autre paire. Cela ce traduit par un partage équitable
du médium, mais avec une plus grande instabilité dans cette répartition. Cette instabilité est
liée aux EIFS qui sont utilisés par les mobiles quand ils détectent de l’activité sur le canal.
Dans cette configuration, ils sont en particulier déclenchés dans une paire au moment où le
canal devient libre après l’émission d’un acquittement dans l’autre paire. Pour émettre son
prochain paquet, cette paire va devoir attendre un temps correspondant à EIFS+backoff, alors
que l’autre se contente de DIFS+backoff. DIFS+backoff étant statistiquement plus petit, il y
a une forte probabilité qu’un mobile émette un certain nombre de paquets avant que l’autre y
arrive et que la situation s’inverse. Ceci est particulièrement visible sur les figures 4.15 et 4.16.
Sur la figure 4.15 on voit que les deux nœuds accèdent au médium avec une alternance très
rapide (lorsque les émetteurs sont à portée de communication, un nœud n’émet en général pas
plus de deux ou trois paquets consécutifs avant de laisser la main). Sur la figure 4.16 où les
émetteurs sont par contre en zone de détection de porteuse, lorsqu’un nœud prend la main,
il la garde parfois pour un envoi comprenant jusqu’à une douzaine de paquets consécutifs.
– Au delà de 550 mètres, les deux paires sont totalement indépendantes (figure 4.14), chacun
des émetteurs occupe la totalité de la bande passante et transmet en continu.
Dans la phase de 200 à 550 mètres, les RTS/CTS n’ont aucun effet en dehors de la diminution
du débit utile que l’on avait déjà observé dans la première simulation. Ceci est tout à fait normal,
puisque l’on se place dans une configuration (entre 250 et 550 mètres) où les paquets RTS et CTS ne
peuvent pas plus être compris que les paquets de données (les signaux sont reçus avec une puissance
trop faible, les deux émetteurs sont dans la zone de détection de porteuse l’un de l’autre).

59
CHAPITRE
Scénarios ”avancés”
5
5.1 Introduction et objectifs
Nous avons étudié jusqu’à présent des configurations basiques, avec seulement deux mobiles
émetteurs. Les résultats obtenus vont nous servir maintenant à mieux comprendre les mécanismes
et les interactions qui se déroulent dans des scénarios plus complexes. Ces scénarios vont désormais
compter plus de mobiles, et les configurations vont être plus caractéristiques des réseaux ad hoc.
Nous nous intéresserons en premier lieu à la structure en chaı̂ne, qui est à la base même des
réseaux radio multi-sauts. Nous considérerons ensuite des configurations où certains mobiles sont
plus affectés par les interférences que d’autres. Et nous terminerons par une chaı̂ne perturbée de
manière inégale.

5.2 Trois paires


Le scénario que nous présentons maintenant à pour but de mettre en évidence certains problèmes
d’équité dans l’accès au médium avec 802.11. Nous utilisons six mobiles que nous plaçons comme
indiqué sur la figure 5.1 : ils sont tous initialement très proches les uns des autres. Les mobiles
sont répartis en trois paires d’émetteur / récepteur. Dans chaque paire, l’émetteur essaie d’envoyer
autant de paquets UDP de 1000 octets que possible à son récepteur (la file d’attente d’émission est
continuellement pleine). La vitesse de transmission est de 2 Mbit/s et le mécanisme RTS/CTS est
utilisé.
L’idée du scénario est de produire une situation typique des réseaux ad hoc où certains mobiles
sont plus soumis à des interférences que d’autres. Pour ce faire, au cours de la simulation, nous
déplaçons progressivement les paires extérieures à la vitesse constante de 25 mètres par seconde.
Au fur et à mesure du déroulement du scénario, les mobiles vont tout d’abord tous interférer les

Fig. 5.2 – Interférences non symétriques entre


Fig. 5.1 – Position initiale des 3 paires les 3 paires

60
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

uns avec les autres, puis les paires extérieures vont continuer à interférer avec la paire centrale mais
sans se gêner entre elles (figure 5.2), et enfin les trois paires vont être suffisamment éloignées les
unes des autres pour accéder au canal en même temps sans problème. Nous obtenons les débits
présentés sur la figure 5.3, ils peuvent être interprétés comme suit :
– De 0 à 5 secondes (les paires extérieures sont entre 0 et 125 mètres de la paire centrale),
les trois paires sont en contact ”direct” (elles sont à portée de communication les unes des
autres). Même si le réseau est saturé, comme les débits demandés sont identiques, la bande
passante est partagée de manière équitable (le débit utile maximal de 1.6 Mbit/s environ
divisé par 3).
– De 5 à 11 secondes (les paires extérieures sont désormais entre 125 et 275 mètres de la paire
centrale, mais surtout entre 250 et 550 mètres l’une de l’autre) les communications (et donc la
mise à jour du NAV grâce aux RTS/CTS) n’est plus possible entre les paires extérieures, mais
comme elles détectent réciproquement leurs porteuses, elle savent que le canal est utilisé et le
partage encore de manière assez équitable (environ un tiers chacune). Le canal est cependant
un peu moins bien partagé. La raison se trouve dans le phénomène décrit dans la simulation
des deux paires, au moment où elles sont dans les zones de détection de porteuse l’une de
l’autre. Le déclenchement des EIFS est à la base du phénomène d’instabilité.
– De 11 à 22 secondes (les paires extérieures sont entre 275 et 550 mètres de la paire centrale)
la paire centrale est dans une situation différente des deux autres paires. Elle détecte la
porteuse des deux paires extérieures, alors que ces dernières ne détectent chacune que celle
de la paire centrale. Dans ce contexte asymétrique, le mécanisme d’accès au canal présente
une faiblesse très nette. Dès que la paire centrale perd l’accès au canal, elle a énormément
de difficultés à le récupérer. Le débit de la paire centrale est quasiment nul durant cette
période, alors que celui des paires extérieures atteint le maximum possible. Ceci s’explique
de la façon suivante : la paire centrale ne peut émettre que lorsque les deux autres sont
silencieuses pendant une période suffisante. Mais les deux autres ne se gênent pas entre
elles, et il n’y a donc aucune raison pour qu’elles soient synchronisées. De ce fait, il n’y a
pas de raison pour que leurs périodes de backoff coı̈ncident. De plus, plus la charge utile des
paquets est importante, plus petites sont les chances pour que les backoff des paires extérieures
coı̈ncident. La figure 5.5 montre le décalage existant entre les périodes de silence des deux
paires extérieures. Le phénomène est encore amplifié par le mécanisme EIFS de 802.11. La
figure 5.4 présente ce qui se passe d’une façon simplifiée (pour des raisons de lisibilité l’échelle
de temps n’est pas respectée entre les différents éléments). On peut tout d’abord noter que
même si dans la réalité les différents mobiles ne commenceraient pas forcément de manière
synchronisée, le problème apparaı̂trait néanmoins au bout de quelques instants. En premier
lieu, le canal doit être libre pendant une période DIFS avant qu’un nœud décide d’essayer
de transmettre (figure 5.4a). Les nœuds attendent ensuite pendant une période de backoff
aléatoire (figure 5.4b). Comme l’émetteur de la première paire a terminé de décrémenter
son backoff et que le canal est toujours libre, il commence à transmettre, brouillant ainsi la
seconde paire qui entre alors en période de defering jusqu’à ce que le canal soit à nouveau
libre. Comme la troisième paire n’est pas gênée, elle peut terminer la décrémentation de son
backoff et commencer elle aussi à émettre (figure 5.4c). A cause de l’activité 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 période EIFS (qui est environ 6

61
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

DIFS
temps
DIFS (a)
temps
DIFS
temps

DIFS Backoff
temps
DIFS Backoff (b)
1.6e+06 temps
DIFS Backoff
temps
1.4e+06

debit dans la paire de gauche DIFS Backoff DATA


1.2e+06 debit dans la paire centrale
debit dans la paire de droite temps
DIFS Backoff Defer (c)
debit en bits par seconde

1e+06 temps
DIFS Backoff DATA
temps
800000

DIFS Backoff DATA DIFS


600000 temps
DIFS Backoff Defer EIFS (d)
temps
400000 DIFS Backoff DATA DIFS
temps
200000

DIFS Backoff DATA DIFS Backoff DATA


0 temps
5 10 15 20 25 30 DIFS Backoff Defer EIFS Defer (e)
temps en secondes temps
DIFS Backoff DATA DIFS Backoff
temps

Fig. 5.3 – Débit en fonction du temps dans le Fig. 5.4 – Détail du problème d’accès au
scénario des trois paires médium avec l’EIFS

fois plus longue qu’un DIFS). Entre temps, les deux autres paires ont déjà recommencé un
nouveau cycle (figure 5.4d) et tout recommence ... (figure 5.4e).
– Au delà de 22 secondes Les trois paires sont suffisamment éloignées les unes des autres.
Elles ne détectent plus les porteuses des autres et peuvent émettre en même temps au débit
maximum.
Il faut noter que pour la période problématique, l’amplification des problèmes par le mécanisme
des EIFS peut être quantifiée. Nous avons effectué une série de simulations en plaçant les trois
paires dans la position correspondant à la période des secondes 11 à 22 de la figure 5.3. Pour
certaines mesures, nous avons utilisé des EIFS ayant leur durée normale (364 µs) et dans d’autres
des EIFS ayant la même durée que les DIFS (50 µs). Nous avons également effectué ces simulations
an activant ou non les RTS/CTS. La figure 5.6 présente ces résultats :

Fig. 5.5 – Détails de la simulation entre les secondes 11 et 22

62
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

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

0.05

Central pair time-share (%)


0.04

0.03

0.02

0.01

0
700 800 900 1000 1100 1200 1300 1400
Packet size (bytes)

Fig. 5.6 – Proportion d’accès au canal pour la paire centrale en fonction de la taille des paquets et
de la durée de l’EIFS (période des secondes 11 à 22).

– Avec les EIFS ”normaux” (364µs), la paire centrale obtient aux alentours de 1% de la bande
passante. Si les nœuds utilisent les RTS/CTS, la paire centrale obtient un débit encore
légèrement inférieur.
– Avec des EIFS ”courts” (50µs, soit la même durée 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 défavorisée vis-à-vis des paires extérieures. Cette limitation vient
de l’effet de la non synchronisation des paires extérieurs dont nous avons parlé précédemment.
Là encore, les RTS/CTS ont un impact négatif pour le partage équitable, lorsqu’ils sont
activés, la paire centrale a plus de difficultés à accéder au canal que lorsqu’ils ne le sont
pas. On remarque enfin que les chances d’accès au canal de la paire centrale diminuent avec
l’augmentation de la taille des paquets. Plus les paquets sont longs, plus la proportion du
temps ou le canal est occupé (transmission de données ou de paquets de contrôle) par rapport
au temps ou le canal est libre (périodes de backoff, DIFS, EIFS) diminue. Par conséquent les
chances que les périodes de silence des paires extérieures coı̈ncident diminuent aussi.
Cette expérience met donc en évidence un problème d’inégalité important dans l’accès au
médium radio de 802.11.

5.3 Sauts multiples en configuration de chaı̂ne


Jusqu’alors nous nous sommes intéressés qu’à des configurations qui ne faisaient pas appel à la
capacité de routage des réseaux ad-hoc. Dans le scénario présenté sur la figure 5.7, nous cherchons
maintenant à voir ce qu’il se passe dans une chaı̂ne assez longue (comportant jusqu’à 7 sauts) si
l’émetteur envoie autant de données que possible.
Tout d’abord, il est important de comprendre que dans ce genre de scénario, le protocole de
routage utilisé a déjà un impact important. En effet, si des interférences ou des collisions au niveau
de 802.11 provoquent la perte de certains paquets nécessaires pour le routage voire des incapacités
totales de communication un peu longues entre certains mobiles, cela peut conduire le protocole
de routage à déclarer l’expiration de la route. Les timers et les mécanismes déclenchant ces expi-

63
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

Fig. 5.7 – La chaı̂ne à 8 nœuds

rations varient d’un protocole de routage à l’autre, et il en est de même pour les algorithmes de
reconstruction qu’une perte de route va déclencher.
Par exemple, dans notre scénario de chaı̂ne, en cas d’utilisation d’un protocole proactif, la perte
de paquets hello consécutifs peut provoquer la rupture de la route. Cela va déclencher une première
mise à jour en cascade des tables de routage. Quand les paquets hello sont ensuite à nouveaux reçus,
cela va provoquer une seconde mise à jour en cascade. Il y aura donc une période d’instabilité dans
l’état des tables de routage (où il n’y aura plus de route de bout en bout de la chaı̂ne), ainsi qu’une
charge éventuellement importante du réseau. Dans le cas d’un protocole réactif, la perte de paquets
de recherche de route peut amener l’émetteur à penser qu’il n’y a pas de route disponible du tout ;
et donc a attendre un nouvel essai initié par une couche supérieure pour à nouveau essayer de
trouver la route.
Cette mise en garde effectuée, revenons à la description du scénario. Il a consisté à faire transiter
des paquets sur une chaı̂ne de plus en plus longue (de 2 à 8 nœuds et donc de 1 à 7 sauts). Les nœuds
sont placés à 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 qu’un nœud peut communiquer
avec ses voisins de gauche et de droite, et que sa porteuse est détectée par les nœuds à deux sauts
et pas plus loin. Cela correspond évidemment à l’idée que l’on se fait d’une communication multi-
sauts dans un véritable réseau ad hoc, où les nœuds d’une route sont en général choisis de sorte à
minimiser si possible le nombre de sauts.
La figure 5.8 montre les débits mesurés sur la chaı̂ne en fonction du nombre de sauts. Le débit de
bout en bout diminue logiquement très vite lorsque l’on 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 nœuds sont impliqués. Dans les cas de
chaı̂nes assez longues, on remarque également un certaine instabilité du débit de bout en bout.
La figure 5.9 présente les chronogrammes d’émissions pour des chaı̂nes de 2 à 8 nœuds. Les
RTS/CTS n’étaient pas utilisés, seuls les données et leurs éventuels acquittements sont donc
représentés. 2 IF0 et 2 IF1 représentent les émissions par les nœuds 0 et 1 dans la chaı̂ne à un
saut, 3 IF0, 3 IF1 et 3 IF2 représentent les émissions par les nœuds 0, 1 et 2 dans la chaı̂ne à
deux saut et ainsi de suite. Cette partie du chronogramme correspond au tout début des échanges,
on y voit la forme en ’V’ particulière correspondant aux paquets RouteRequest et RouteReply qui
traversent la chaı̂ne de bout en bout pour construire la route. On remarque que ces paquets Rou-
teRequest et RouteReply ne sont pas acquittés (ils sont diffusés) mais que les paquets de données

64
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

1.8e+06
1 saut
2 sauts
3 sauts
1.6e+06 4 sauts
5 sauts
6 sauts
1.4e+06 7 sauts

1.2e+06
debit en bits par seconde

1e+06

800000

600000

400000

200000

0
0 10 20 30 40 50 60
temps en secondes

Fig. 5.8 – Débit sur la chaı̂ne de 2 à 8 nœuds (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 également que lorsque le nombre de sauts augmente, certains nœuds ont du mal à
accéder au médium. Par exemple, dans la chaı̂ne à 8 nœuds (dernière série), après la traversée
de la chaı̂ne complète par trois paquets de données, le nœud 1 monopolise le canal pendant une
douzaine de paquets (ces paquets sont bien reçus au nœud 2 comme le prouvent les acquittements
qu’il renvoie, mais il n’arrive pas ensuite à accéder au canal pour continuer à router ces paquets).
Ces effets sont causés par la combinaison de plusieurs facteurs : le nœud 0 a toujours des paquets
à envoyer et le nœud 1 est gêné par plus de mobiles que le nœud 0 (0 ne peut pas émettre en
même temps que 1 ou 2, 1 ne peut émettre en même temps que 0, 2 et 3). Sur ces chronogrammes,
il est également aisé de constater la réutilisation spatiale (si deux ou plus nœuds émettent à un
instant donné, c’est qu’ils sont suffisamment éloignés pour ne pas interférer ni même se détecter,
par exemple les nœuds 0 et 3 émettent parfois en même temps).
L’allure générale des chronogrammes pour les chaı̂nes assez longues (5 sauts ou plus) permet
de tout de suite saisir certaines informations confirmées par d’autres analyses des traces : dans
un scénario de chaı̂ne, avec un modèle de propagation two-rays ground, les paquets ont de fortes
chances d’être bloqués au niveau des 3 premiers nœuds ; mais s’ils atteignent le quatrième, alors
leur chance d’atteindre la destination finale est très importante. Ce blocage au niveau des premiers
nœuds est en fait dû aux difficultés d’accès au canal puisque la source essaie d’envoyer autant de
paquets que possible (et que comme nous l’avons mentionné, elle rencontre moins de contention
que les autres.) Plus loin sur la chaı̂ne le problème ne se pose plus car les nœuds ne cherchent à
émettre que ce qu’ils ont pu recevoir.

65
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

Fig. 5.9 – Chronogrammes de chaı̂nes de 2 à 8 nœuds

66
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

Nous avons ensuite effectué la même simulation mais en ajoutant l’utilisation des RTS/CTS.
Le débit de bout en bout obtenu en fonction du nombre de sauts est présenté sur la figure 5.10. Les
débits pour les chaı̂nes courtes (1, 2 et 3 sauts) sont assez similaires à ceux obtenus si l’on n’utilise
pas les RTS/CTS. Bien sûr, dans leurs cas, on observe une diminution du débit proportionnelle
au temps supplémentaire de transmission des paquets RTS/CTS (débits respectifs de 1.4, 0.7 et
0.4 Mbit/s respectivement). Mais lorsque la chaı̂ne continue de s’allonger, le débit 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 être particulièrement dommageables. Les chronogrammes
des figures 5.11 (sans RTS/CTS) et 5.12 (avec RTS/CTS) montrent que dans le cas de l’utilisation
des RTS/CTS, très peu de paquets arrivent à traverser la chaı̂ne de façon consécutive. Le nœud
0 envoie en quasi permanence des paquets au nœud 1, mais celui-ci n’arrive que rarement à les
faire suivre. On remarque également des coupures très fréquentes de la route, qui force AODV à
la reconstruire (ceci se voit très bien avec les formes en ”V” précédant les périodes où quelques
paquets arrivent à traverser la chaı̂ne complètement.
Les chronogrammes des figures 5.13 (sans RTS/CTS) et 5.14 (avec RTS/CTS) permettent de
voir plus en détail ce qui se passe. En l’absence de RTS/CTS, on remarque une forte réutilisation
spatiale, les nœuds situés à trois sauts ou plus l’en de l’autre pouvant en général émettre en même
temps. Avec les RTS/CTS maintenant, on remarque que c’est plus problématique. Sur la figure 5.14
par exemple, on voit que lorsque le nœud 3 accède au canal, le nœud 0 envoie plusieurs RTS qui ne
reçoivent pas de réponse de 1 (et de même, 1 envoie plusieurs RTS à 2 qui n’y répond pas quand 4
est en train d’envoyer des données).
Sur le chronogramme de la figure 5.15 (qui correspond à une autre période de la simulation
de la chaı̂ne de 8 nœuds avec RTS/CTS, on voit cependant que cette réutilisation spatiale peut
parfois avoir lieu. On voit bien en particulier sur cette figure les émissions en parallèle des mobiles
(0,4), (1,5) et (2,6). Ceci est d’ailleurs 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 chaı̂ne fixe et la paire de perturbateurs


Cette expérience montre l’impact dans un contexte plus réaliste du phénomène qui a été mis en
lumière dans le scénario précédent. La topologie est celle présentée sur la figure 5.16 : un flux UDP
à débit constant traverse une chaı̂ne de six mobiles (similaire à celle utilisée dans les premières
simulations, avec une distance de 200 mètres entre chaque nœud). Une paire de mobiles (entre
lesquels existe un autre flux à débit constant) est initialement située loin de la chaı̂ne (en dehors
de toute zone d’interférences). Les mobiles de la paire sont très proches l’un de l’autre (un mètre)
durant la totalité de la simulation. Les nœuds de la chaı̂ne restent fixes du début à la fin. Au fur
et à mesure de la simulation, la paire va se déplacer et va progressivement entrer puis ressortir de
la zone d’interférences des nœuds de la chaı̂ne.
La simulation a été effectuée pour différents débits demandés sur les deux flux (2000, 1333,
1000, 800, 400 et 200 kbit/s). Excepté pour des débits demandés de 200 kbit/s, le réseau est saturé
et la bande passante n’est pas suffisante pour délivrer la totalité des paquets demandés. Pour des
raisons de lisibilité la figure 5.17 ne présente qu’une moyenne des débits sur la chaı̂ne simulés en
fonction du temps. Le but de cette courbe est de donner une idée des phénomènes d’interférences
en fonction de la position des divers mobiles ; plus que les débits chiffrés, c’est la forme de la courbe
qui est importante ici. On remarque immédiatement un effet de symétrie. Au tout début et à la

67
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

1.8e+06
1 saut
2 sauts
3 sauts
1.6e+06 4 sauts
5 sauts
6 sauts
1.4e+06 7 sauts

1.2e+06
debit en bits par seconde

1e+06

800000

600000

400000

200000

0
0 10 20 30 40 50 60
temps en secondes

Fig. 5.10 – Débit sur la chaı̂ne de 2 à 8 nœuds (UDP, avec les RTS/CTS)

Fig. 5.11 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, sans les RTS/CTS), vue large

Fig. 5.12 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, avec les RTS/CTS), vue large

68
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

Fig. 5.13 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, sans les RTS/CTS), détail

Fig. 5.14 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, avec les RTS/CTS), détail

Fig. 5.15 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, avec les RTS/CTS), détail 2

69
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

350000

300000

250000

debit en bits par seconde


200000

150000

100000

50000

0
10 20 30 40 50
temps en secondes

Fig. 5.16 – Le scénario de la chaı̂ne et


du couple de perturbateurs Fig. 5.17 – Débit moyen sur la chaı̂ne

fin de la simulation, la paire perturbatrice est trop loin de la chaı̂ne pour la gêner, c’est là que l’on
observe logiquement le débit maximum. On remarque ensuite que lorsque la paire perturbatrice
est très proche de la chaı̂ne (partie centrale de la courbe, entre les secondes 25 et 45 environ), le
débit sur la chaı̂ne est réduit mais néanmoins existant. Et finalement on observe deux zones où le
flux sur la chaı̂ne est complètement stoppé ou presque (secondes 10 - 25 et 45 - 50). Ces périodes
correspondent aux moment où la paire perturbatrice est dans la zone de détection de porteuse des
nœuds centraux de la chaı̂ne. Le phénomène qui se produit alors est très proche de celui rencontré
dans la simulation des trois paires : les mobiles au centre de la chaı̂ne détectent les porteuses des
premiers mobiles de la chaı̂ne mais aussi celles de la paire perturbatrice. Ils sont dans la même
situation que la paire centrale dans le scénario des trois paires, puisque qu’à cet instant la paire
perturbatrice et les premiers mobiles de la chaı̂ne ne se gênent pas du tout et émettent de façon
désynchronisée.

5.5 Le problème de l’asymétrie


Les problèmes que nous avons mis en lumière dans les simulations précédentes sont ca-
ractéristiques des réseaux ad-hoc. L’effet le plus remarquable est l’incapacité pour certains
émetteurs d’accéder au canal radio. Contrairement aux problèmes d’équité mis en évidence dans
[44, 48] où l’inégalité provient de collisions répétées, l’inégalité mise en évidence ici provient de
l’impossibilité d’accéder au médium radio (certains mobiles ne peuvent pas s’exprimer). Ce type
de comportement se produit lorsqu’il existe une asymétrie dans les interférences entre les différents
mobiles. La notion d’asymétrie a été mentionnée dans [47], mais aucune explication de 802.11 face
à cette asymétrie n’a été apportée. Or le scénario des trois paires permet de bien comprendre
l’origine du problème. En effet, pour un mobile connaissant une contention plus importante, un
certain nombre d’autres mobiles en compétition avec lui ne se gênent pas du tout entre eux, et
leurs émissions ne sont donc pas synchronisées. Pour que le mobiles mis en défaut puisse accéder au

70
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”

canal, il faut que les périodes de silence des autres mobiles se recouvrent. Or la probabilité d’un tel
recouvrement est faible, et le mobile perçoit le canal comme occupé dès que l’un ou l’autre l’utilise.
Dans les configurations que nous avons présentées, les mobiles les plus exposés (la paire centrale
dans le scénario des des trois paires par exemple) perçoivent le canal occupé en quasi permanence, et
les mobiles ”gêneurs” le perçoivent presque tout le temps libre (ils continuent donc leurs émissions
de plus belle).
Ce problème n’est pas un problème de nœuds cachés et ne peut pas être résolu par le mécanisme
des RTS/CTS. En effet, les récepteurs des mobiles désynchronisés ne sont pas nécessairement les
mêmes et de plus les mobiles peuvent être trop loin les une des autres pour comprendre le contenu
des paquets de contrôle. Dans le contexte prévu par 802.11 (mobiles attachés à des stations de base
ou à portée directe de communication) le type d’asymétrie décrit précédemment ne se produit pas.
Soit les mobiles sont à portée de communication directe, soit ils sont reliés à une même station
de base et lorsqu’ils communiquent avec elle les RTS ou CTS qu’elle envoie suffisent à réserver
convenablement le canal et y permettre un accès équitable.

Nous avons vu également que le mécanisme des EIFS qui est sensé protéger les acquittements
pouvait amplifier le problème de l’asynchronisme que nous venons décrire. De même, nous avons
vu dans l’étude des résultats de la chaı̂ne que les RTS/CTS pouvaient avoir eu aussi un impact
particulièrement négatif dans le cadre de réseaux multi-sauts étendus.

5.6 Conclusion sur ces simulations


L’inégalité dans l’accès au médium radio rencontrée dans des configurations de base des réseaux
ad hoc a une impact fondamental sur les protocoles des couches supérieures. En effet, la plupart des
protocoles dans les réseaux ad hoc basent leur fonctionnement sur la connaissance des liens. Dès
qu’un lien apparaı̂t ou disparaı̂t, des informations sont mises à jour dans le réseau. Dans le cadre
d’un réseau fixe, si chaque mobile est en mesure de s’annoncer régulièrement les liens seront connus
et considérés comme stables, ce qui entraı̂nera peu de trafic de contrôle. Par contre, si certains
mobiles ne sont pas en mesure d’accéder régulièrement au médium, des liens vont apparaı̂tre et
disparaı̂tre de manière cyclique alors que ces liens existent bien physiquement ! Ceci entraı̂nera une
charge de trafic de contrôle non négligeable qui aurait pu être évitée si tous les mobiles avaient
pu émettre de manière équitable (ces cassures de lien répétées et le trafic de contrôle généré sont
particulièrement visibles dans le chronogramme de la chaı̂ne de 8 nœuds avec RTS/CTS, sur la
figure 5.10 et 5.14). Cela implique aussi que les protocoles de routage n’auront pas une bonne
vision du réseau puisqu’ils ne verront pas certains liens existants réellement. Ils n’auront donc
qu’une connaissance partielle de la topologie. Ils pourraient alors prendre des décisions adaptées
à la vision qu’ils ont alors qu’elles ne le sont peut-être pas à la topologie réelle. Enfin, une telle
inégalité implique que certaines communications ne pourront obtenir qu’un débit très faible voire
nul à certains moments.

71
CHAPITRE
Quelques solutions aux
6 problèmes d’équité dans les
réseaux ad hoc

Plusieurs solutions ont été proposées pour résoudre le problème d’équité dans l’accès au médium
radio.
MACAW [46] propose une gestion différente de la fenêtre de contention : l’idée est de ne pas
favoriser la station qui vient juste d’émettre comme le fait le Binary Exponential Backoff. Cette
solution concerne les problèmes d’inégalité provenant de collisions mais elle ne résoudra pas les
problèmes où certains mobiles n’accèdent pas du tout au médium.
Les solutions élaborées dans [47] se basent sur un graphe de contention des flux ce qui suppose
une connaissance globale du réseau ainsi que des flux acheminés dans le réseau. Cette solution est
donc difficile à implanter en pratique.
Les travaux de Bensaou et al. [48, 38] ont une approche de faisabilité puisqu’ils modifient 802.11
dans le but de garantir une meilleure équité. L’idée est que chaque mobile prenne en compte les
communications dans son voisinage à un saut afin de savoir s’il peut émettre beaucoup ou s’il
doit se ralentir. En comptant ses propres communications et les communications de ses voisins,
chaque mobile peut savoir s’il a émis plus ou moins que ses voisins. S’il a émis plus, il augmente
sa fenêtre de contention, ce qui lui permet statistiquement de ralentir ses émissions. S’il a émis
moins, il diminue sa fenêtre de contention, ce qui lui permet statistiquement d’augmenter ses
émissions. Avec ces modifications, le système doit alors se stabiliser sur une solution plus équitable.
L’idée est intéressante (même si l’algorithme n’a manifestement pas été correctement finalisé et
si quelques modifications simples l’amélioreraient), mais il ne permet d’équilibrer que des flux à
portée de communication. Or, comme dans le scénario des trois paires par exemple, les émetteurs
sont en zone de détection de porteuse et ne peuvent pas directement communiquer. Dans ces cas,
les solutions de Bensaou et al. ne s’appliquent pas.
Nous avons donc proposé dans un premier temps une solution qui essaye de résoudre le problème
d’équité quand les mobiles en compétition ne peuvent pas communiquer. Par la suite, nous avons
proposé une seconde solution, inspirée de celle de Bensaou et al., mais qui cherche à diffuser de
l’information dans son voisinage pour être plus efficace.

6.1 Une solution historique et locale


Un certain nombre de contraintes que nous nous étions fixées nous on conduit à élaborer cette
première solution. Ces contraintes étaient les suivantes :

72
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC
– Minimiser les changements à apporter à 802.11 (notre approche est assez pragmatique, il est
important à nos yeux de chercher une solution qui puisse être implémentée concrètement dans
des matériels existants).
– Garder la compatibilité avec les cartes 802.11 n’ayant pas été modifiées
– Fonctionner même lorsque les mobiles impliqués n’ont aucun moyen de communiquer, même
en passant par des intermédiaires
Sous nos contraintes il peut parfois être impossible de communiquer avec les mobiles qui nous
gênent ni même de les identifier. Il est également impossible pour un mobile de se rendre compte que
son activité, lorsqu’elle est cumulée à celles d’autres émetteurs, empêche d’autres mobiles d’accéder
au canal (par exemple, du point de vue des paires extérieures dans le scénario des trois paires, le
canal est toujours libre et elles en profitent logiquement pour émettre au débit maximum). Notre
solution consiste à chercher à pénaliser les mobiles qui transmettent beaucoup. De cette manière
on espère que lorsqu’ils seront forcés de se taire, les chances que les périodes de silence coı̈ncident
au niveau des mobiles gênés augmenteront et que ces derniers pourront enfin émettre.
La modification que nous proposons concerne le backoff et son calcul devient le suivant : au
niveau de chaque nœud le temps est découpé en périodes de longueur fixe (par exemple une
seconde). La situation est la même pour chaque nœud en début de période. Ensuite, à chaque
fois que le nœud gagne l’accès au canal et envoie un paquet, une pénalité est ajoutée au backoff
(le backoff pour les paquets suivants sera toujours aléatoire, mais statistiquement plus grand).
En dehors de cette pénalité, le calcul du backoff reste strictement identique à celui décrit dans
la norme. Nous avons soigneusement choisi la courbe de progression de la pénalité (ou malus)
qui est présentée sur la figure 6.1. Cette courbe est caractérisée par un premier plateau où le
malus est nul ou presque (”les premiers paquets ne sont pas pénalisés”), par une rampe assez
raide (”maintenant que l’on a déjà beaucoup parlé, il est temps de laisser de la place aux
autres”) et enfin par un plateau assez haut (si l’on continuait à augmenter la pénalité de manière
exponentielle, lorsqu’il n’y a qu’un seul flux, son débit serait trop pénalisé). Au début de chaque
cycle, le compteur est ré-initialisé et la pénalité redevient nulle. Dans ce système, les paramètres
qui peuvent être ajustés sont essentiellement la durée du cycle et la forme de la courbe de
progression de la pénalité. Il faut noter que nous n’avons pas essayé de favoriser les mobiles en
défaut en diminuant la borne maximale de leur fenêtre de contention en dessous du seuil cwMin
fixé par la norme. Nous pensions que la norme avait ses raisons d’avoir fixé cwMin à 31 et que
réduire cette valeur pourrait notamment augmenter de manière sensible les collisions dans le réseau.

Bien que cette méthode soit simple, elle donne des résultats tout à fait intéressants. Dans les
simulations, il est apparu que la probabilité pour un mobile d’être complètement ”écrasé” par ses
voisins non directs est beaucoup plus faible qu’avec 802.11 non modifiée.
La figure 6.2 montre les débits obtenus dans le scénario 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 détecte
les porteuses des deux paires extérieures sans pouvoir communiquer avec elles) l’accès au canal
n’est peut-être pas encore équiprobable pour les trois paires, mais que la paire centrale n’est plus
complètement étouffée par les deux autres (elle obtient un débit de 300 - 350 kbit/s, contre environ
800 kbit/s pour chacune des paires extérieures). Le principal inconvénient de la méthode est aussi
clairement visible sur cette courbe, puisque le débit maximum d’une paire lorsqu’elle ne subit pas
d’interférences est sévèrement limité (seulement environ 1 Mbit/s au delà de 22 secondes, alors que
sans malus on atteint 1.6 Mbit/s, soit une réduction de près de 40%). Comme nous augmentons

73
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

1.6e+06
paire de gauche
paire centrale
1.4e+06 paire de droite

1.2e+06

250

debit en bits par seconde


malus
1e+06

200
800000
Malus (en nombre de time slots)

150
600000

100 400000

200000
50

0
0 5 10 15 20 25
0 5 10 15 20 25 30
paquets envoyes depuis le debut du cycle
temps en secondes

Fig. 6.1 – Progression de la pénalité en Fig. 6.2 – La simulation des 3 paires en utilisant le
fonction du nombre de paquets envoyés mécanisme du malus

statistiquement le backoff, le nombre maximum de paquets qu’un mobile peut envoyer par seconde
diminue. Mais il faut garder à l’esprit que ce problème devient rapidement imperceptible lorsque le
nombre de flux en compétition à un instant donné pour l’accès au canal augmente. Sur la première
partie de la courbe (de 0 à 10 secondes), les trois flux sont en compétition et leur débit agrégé
est de 450×3 soit 1350 kbit/s ; avec trois flux en compétition, la perte de débit engendrée par le
mécanisme du malus passe donc déjà en-dessous des 20%.
Nous avons également testé notre système sur le scénario de la chaı̂ne et de la paire perturbatrice
(figure 5.16), mais avec des flux TCP à la place des flux UDP, et un débit demandé pour chacun
d’entre eux de 2 Mbit/s. Avec la version normale de 802.11, nous avons obtenu des résultats
désastreux (figure 6.3). Il faut bien garder à l’esprit que le caractère erratique de l’accès au médium
dans ces conditions empèche de nombreux acquittements de TCP d’arriver à temps, empêchant
ainsi parfois TOUTE progression de la communication. La version modifiée se comporte beaucoup
mieux (figure 6.4). Notons qu’en l’absence de contention, le débit sur la paire perturbatrice est
fortement affecté (périodes des secondes 0 à 10 et de 53 à la fin) puisque le mécanisme du malus le
fait passer de 1250 kbit/s à un peu moins de 950 kbit/s, mais que le débit sur la chaı̂ne ne change
pas (un peu plus de 200 kbit/s, avec ou sans malus). Comme nous l’avions déjà énoncé, l’effet
négatif du malus sur le débit décroı̂t très rapidement avec le nombre de mobiles en contention.
L’autre inconvénient principal de la méthode, qui n’apparaı̂t pas cette fois-ci sur les courbes, est
la tendance à produire des transferts par rafale, qui peuvent causer des problèmes à certains types
d’applications (multimédia utilisant des petits tampons en particulier, comme la téléphonie). Si un
émetteur ne rencontre pas beaucoup de difficultés pour accéder au canal et qu’il a beaucoup de
paquets en attente, il va les émettre à la suite les uns des autres jusqu’à ce que la pénalité devienne
non négligeable et le freine. Les émissions d’un tel mobile seront donc en majorité en début de
cycle. A ce propos, la taille de la fenêtre TCP a une importance : trop petite et TCP pensera qu’il
y a de la congestion lorsque le débit sera réduit par la pénalité ; il réagira en diminuant encore sa
fenêtre, ce qui est mauvais.

74
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

1.4e+06 1e+06
chaine
paire perturbatrice
900000
1.2e+06
800000

1e+06 chaine 700000


paire perturbatrice
DØbit (en bit par seconde)

DØbit (en bit par seconde)


600000
800000

500000

600000
400000

400000 300000

200000
200000
100000

0 0
0 10 20 30 40 50 60 0 10 20 30 40 50 60
Temps (en secondes) Temps (en secondes)

Fig. 6.3 – Débits dans la simulation de la chaı̂ne Fig. 6.4 – Débits dans la simulation de la chaı̂ne
et du perturbateur (TCP, 802.11 non modifié) et du perturbateur (TCP, 802.11 modifié)

Au niveau des amélioration possibles de ce système, on peut citer d’une part le changement
dans le comptage effectué. Plutôt que de compter les paquets indifféremment, il serait peut-être
plus judicieux de prendre en compte leur taille. En effet, en fonction des applications (telnet par
exemple) et des protocoles utilisés (TCP avec ses acquittements), il se peut qu’il y ait beaucoup de
paquets très petits à transferer. Ces dernier ferait très vite progresser le malus alors que finalement
ils ne gênent peut-être pas beaucoup les mobiles du voisinage. D’autre part, la courbe de progression
de la pénalité mériterait d’être étudiée plus en détail également. Sous sa forme actuelle elle donne
des résultats déjà très encourageants, mais nous avons le sentiment que ces derniers pourraient être
encore améliorés.
Remarquons finalement que ce système de pénalité sur le backoff permet bien l’inter-opérabilité
avec les mobiles utilisant des cartes 802.11 non modifiées. Les mobiles utilisant la version modifiée
seront un peu désavantagés en terme de débit possible, mais la communication restera possible.

6.2 Une solution étendue géographiquement


6.2.1 Point de départ et algorithme
Nous sommes partis des travaux de Bensaou et al. [48]. Chaque mobile effectue un comptage
des paquets en terme d’occupation du médium. Le nombre de paquets qu’il envoie est stocké dans
la variable Wi et le nombre de paquets envoyés par ses voisins est stocké dans la variable Wo . Les
variables Φi et Φo correspondent respectivement à l’allocation faite au nœud i et celle faite à ses
Wi
voisins. Ils définissent un index d’équité égal à W o
×Φ
Φi . La fenêtre de contention de chaque mobile
o

est alors ajustée de la manière suivante : chaque mobile double sa fenêtre de contention si son
index d’équité devient supérieur à une constante C, chaque mobile divise par deux sa fenêtre de
contention si son index d’équité devient inférieur à C1 , et chaque mobile ne fait rien si son index
d’équité est compris entre C1 et C.
Comme nous l’avons dit dans l’introduction de ce chapitre, l’algorithme proposé présente
quelques faiblesses. D’une part, le comptage des paquets est effectué de manière anarchique : cer-

75
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

A
D

Fig. 6.5 – La configuration à quatre nœuds

tains paquets sont comptés plusieurs fois sans aucune raison. D’autre part, l’index d’équité pour
chaque mobile devrait se stabiliser vers 1 or il se situe entre 2 et 4. Enfin, dans les scénarios pro-
posés, la taille des fenêtres de contention des mobiles se bloque à la taille maximale autorisée par
802.11, ce qui conduit à une perte de débit global importante.
Néanmoins les approches d’espionnage du médium et de faisabilité nous semblaient intéressantes.
Nous avons donc gardé le socle de l’algorithme présenté par Bensaou et al. et nous l’avons modifié
afin d’apporter un espionnage étendu et de réduire la perte globale de bande passante.

Un espionnage étendu Dans l’algorithme de départ, chaque mobile ne considère que les paquets
qui sont envoyés dans sa zone de communication. Or deux flux peuvent être en compétition même
si leurs émetteurs ne sont pas à portée de communication. Par exemple, dans la figure 6.5, les
émetteurs A et B ne se voient pas mais leurs flux associés sont en compétition. Par conséquent,
cette méthode ne permet pas à un mobile d’évaluer toux les flux qui sont en compétition avec le
flux dont il est émetteur.
Nous proposons donc que chaque mobile communique dans son acquittement (ou son CTS
quand il est actif) son estimation des communications voisines (Wo dans l’algorithme). Ceci va
permettre à l’émetteur d’un flux d’avoir une connaissance plus étendue des flux en compétition. Il
faut néanmoins faire attention à ne pas compter plusieurs fois les paquets. Pour cela, chaque mobile
doit faire un comptage séparé des paquets de mobiles voisins. Ensuite chaque mobile enverra dans
l’ACK ou le CTS la liste des mobiles connus comme étant voisins et le comptage Wo . Lorsque les
mobiles reçoivent cette information, ils n’ont plus qu’à retirer le comptage des mobiles déjà connus
d’eux du Wo reçu et mettre à jour leur nouveau Wo .
L’envoi de la liste des voisins peut être coûteux, c’est pourquoi nous proposons que seules les
entrées/sorties de cette liste soient intégrées dans le paquet ACK ou CTS.

Ajustement de la fenêtre de contention A partir des données de comptage, le calcul de l’index


d’équité intervient, puis en fonction de la valeur obtenue la fenêtre de contention est ajustée. Dans
l’algorithme de départ, nous avons remarqué que les changements dans la taille de la fenêtre étaient
brusques et ne prenaient pas le temps de vérifier qu’ils étaient profitables.
Nous proposons donc de modifier l’ajustement de la fenêtre de contention. Dans le cas où un
mobile lèse ses voisins, la fenêtre ne sera modifiée que si ces trois conditions sont remplies (le cas
où le mobile est lésé par ses voisins est symétrique) :
– L’index d’équité doit dépasser la valeur 1 augmentée d’une tolérance fixée ;
– La période d’adaptation de la fenêtre de contention actuelle doit être terminée ;

76
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

– L’évolution de l’index d’équité doit être supérieure à 0.9, ceci afin de rendre compte si la
situation s’est dégradée ou améliorée.
Si ces conditions sont remplies, la fenêtre de contention est multipliée par l’évolution de l’index
d’équité et de Wi , plutôt que par 2 (comme c’est le cas dans l’algorithme de base). On assure ainsi
que la fenêtre de contention est équilibrée et prend en compte l’évolution propre du débit du mobile.

6.2.2 Quelques résultats


Ce travail a été réalisé en fin de thèse, et je nous ne sommes malheureusement pas en mesure
d’apporter des résultats détaillés sur l’algorithme proposé. Néanmoins, quelques scénarios ont été
évalués afin de pouvoir comparer la version de base de Bensaou et al. et la version améliorée. Nous
avons effectué un certain nombre de simulation grâce à NS2.

Premier scénario à 2 paires. Le scénario utilisé est celui proposé initialement par Bensaou et
al. dans [48], il est présenté sur la figure 6.5. Dans ce scénario, il existe un flux entre A et C, ainsi
qu’un autre en B et D. Les trais en pointillés indiquent que B et C sont à portée de communication
mais ne s’envoient pas de paquets de données. Les flux de données sont constitués de paquets UDP
de 1000 octets. Le débit demandé par chacun des flux augmente avec le temps suivant la courbe
présentée sur la figure 6.6.
Sur la figure 6.7, on présente le débit de chacune des paires dans ce scénario si l’on utilise
802.11 tel qu’il est implanté dans NS2. A partir du moment où le débit demandé est suffisamment
important, on remarque le débit extrêmement faible entre A et B (de l’ordre de 100 kbit/s) alors
qu’il est une dizaine de fois plus important entre C et D (environ 1 Mbit/s). Le problème est détaillé
dans [48], il provient de l’utilisation des RTS/CTS. Dans ce scénario, A ne peut communiquer avec
B, ni même détecter sa porteuse. Lorsque A veut envoyer un paquet de données à 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 données à D,
il n’est pas gêné que si C a pu envoyer un CTS à A (et D n’étant à portée que de B, il peut
toujours répondre au RTS de ce dernier). A partir du moment où B arrive à envoyer un CTS, il
devient très difficile pour A d’obtenir un CTS permettant de lui envoyer des données, d’où les débits
déséquilibrés. Du fait des nombreux échecs de transmission que recontre le nœud A, sa fenêtre de
contention est en général très grande, comme on peut le voir sur la figure 6.8 (avec l’algorithme
de Binary Exponential Backoff, la taille de la fenêtre double à chaque echec, jusqu’à se stabiliser à
1031 time slots).
Dans [48], Bensaou et al. proposent une solution que nous avons implantée dans notre version de
NS2. Nous avons ensuite implanté la version modifié de cet algorithme décrite précédemment. Les
débits obtenus avec l’algorithme original de Bensaou et al. sont présentés sur la figure 6.9 et ceux
obtenus avec notre version le sont sur la figure 6.11. A partir du moment où le débit demandé est
suffisamment important, avec l’algorithme de Bensaou et al., le débit des deux flux est nettement
plus équitable qu’avec la version non modifiée de 802.11. Par contre, évoluant les deux entre 200
et 300 kbit/s, le débit agrégé est bien en dessous du débit maximum autorisé par le canal (dans
les même conditions, un flux ne connaissant aucune contention obtiendrait environ 1.4 Mbit/s).
L’explication de cette perte de bande passante tient dans les backoff qui sont statistiquement très
longs avec l’algorithme de Bensaou et al. La taille des fenêtres de contention sont présentées sur la
figure 6.10, et l’on peut voir qu’elles sont la plupart du temps à leur valeur maximale (1023 time
slots).

77
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

2e+06

debit demande en bits par seconde


1.5e+06

1e+06

500000

0
0 2 4 6 8 10 12 14 16
temps en secondes

Fig. 6.6 – Débit demandé sur chaque flux en fonction du temps

Les débits obtenus avec la modification que nous proposons sont présentés sur la figure 6.11. On
peut voir que l’équité entre les deux flux est très bien respectée, et qu’avec environ 300-350 kbit/s
chacun, les deux émetteurs utilisent plus de bande passante qu’avec l’algorithme originel de Bensaou
et al . Ceci est confirmé par les tailles des fenêtres de contention de A et de B qui sont beaucoup
plus équilibrée, comme le montre la figure 6.12.

Second scénario à 2 paires. Nous avons ensuite légèrement modifié le scénario. La configuration
de cette deuxième simulation est celle de la figure 6.13. Le nœud A envoie toujours des données à
C et le nœud B en envoie toujours à D. Les débits demandés en fonction du temps sont toujours
ceux de la figure 6.6. Mais cette fois ci, A est à portée de détection de porteuse de D. Les débits
obtenus avec la version normale de 802.11 pour les flux (A→C) et (B→D) sont présentés sur la
figure 6.14. On remarque une fois de plus une très forte inégalité dans les débits. Les tailles des
fenêtres de contention (figure 6.15) montrent bien que nous avons affaire à un problème d’accès
au médium et non de collision. En effet, les fenêtres de contention des deux émetteurs restent
très basses durant toute la durée de la simulation. La figure 6.16 détaille le phénomène qui se
produit, et qui a pour origine le mécanisme des EIFS. Nous rappelons que les EIFS ont pour but
de protéger les acquittements dans le cas où un mobile a perçu de l’activité sur le canal mais n’a
pas pu comprendre le paquet. Si ce paquet était un paquet de données, alors son destinataire doit
l’acquitter. Si le mobile qui a détecté l’activité sans la comprendre émettait 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 d’attendre un temps plus long, EIFS, suffisant pour que le
véritable destinataire du paquet envoie son propre acquittement. Dans ce scénario, B comprend
les paquets de A, et peut donc positionner son NAV correctement. Mais il ne peut que détecter
la porteuse sur les acquittements que D renvoie à B. De ce fait, à la fin d’un acquittement de D,
A passe en EIFS. Pendant ce temps, B peut tirer un nouveau backoff et le décrémenter au moins
en partie. Comme D comprend les CTS et ACK envoyés par C, D ne se trouve donc pas en EIFS
de façon symétrique. Il en résulte une forte inégalité dans l’accès au canal, puisque A a de grosses
difficultés à reprendre la main lorsqu’il la perd.

78
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

1.6e+06
A -> C (normal) A (normal)
B -> D (normal) B (normal)

1.4e+06 1000

1.2e+06

taille de la fenetre de contention


800
debit en bits par seconde

1e+06

600
800000

600000
400

400000

200
200000

0 0
0 2 4 6 8 10 12 14 16 0 2 4 6 8 10 12 14 16
temps en secondes temps en secondes

Fig. 6.7 – Débit dans le scénario des deux paires Fig. 6.8 – Taille de la fenêtre de contention
(802.11 normal) (802.11 normal)

1.6e+06
A -> C (bensaou) A (bensaou)
B -> D (bensaou) B (bensaou)

1.4e+06 1000

1.2e+06
taille de la fenetre de contention

800
debit en bits par seconde

1e+06

600
800000

600000
400

400000

200
200000

0 0
0 2 4 6 8 10 12 14 16 0 2 4 6 8 10 12 14 16
temps en secondes temps en secondes

Fig. 6.9 – Débit dans le scénario des deux paires Fig. 6.10 – Taille de la fenêtre de contention
(802.11 Bensaou) (802.11 Bensaou)

79
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

1.6e+06
A -> C (modif.) A (modif.)
B -> D (modif.) B (modif.)

1.4e+06 1000

1.2e+06

taille de la fenetre de contention


800
debit en bits par seconde

1e+06

600
800000

600000
400

400000

200
200000

0 0
0 2 4 6 8 10 12 14 16 0 2 4 6 8 10 12 14 16
temps en secondes temps en secondes

Fig. 6.11 – Débit dans le scénario des deux paires Fig. 6.12 – Taille de la fenêtre de contention
(802.11 modifié) (802.11 modifié)
D

Fig. 6.13 – La deuxième configuration à quatre nœuds

Nous avons ensuite testé l’algorithme de Bensaou et al (figure 6.17 pour le débit et figure 6.18
pour les fenêtres de contention). Sur ces figures, nous pouvons voir que cet algorithme ne donne
pas de bons résultats. Les fenêtres de contention restent en quasi permanence au minimum, et par
conséquent la situation est presque la même qu’avec 802.11 non modifié, c’est à dire une très grande
inégalité dans l’accès au canal.
Nous avons finalement utilisé notre propre algorithme (figure 6.19 pour le débit et figure 6.20
pour les fenêtres de contention). Nous voyons sur ces figures que grâce à une augmentation contrôlée
des fenêtre de contention, on arrive à obtenir des débits équitables et stables.

Conclusion Les résultats obtenus avec la modification que nous avons proposée de l’algorithme
de Bensaou et al. donne des résultats très encourageants. Non seulement il permet une bonne équité
dans des conditions qui tiennent 802.11 en échec, mais il permet aussi une meilleure utilisation de la
bande passante disponible. Notre algorithme a cependant certaines limitations. Pour fonctionner,

80
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

1.6e+06
A -> C (normal) A (normal)
B -> D (normal) B (normal)

1.4e+06 1000

1.2e+06

taille de la fenetre de contention


800
debit en bits par seconde

1e+06

600
800000

600000
400

400000

200
200000

0 0
0 2 4 6 8 10 0 2 4 6 8 10
temps en secondes temps en secondes

Fig. 6.14 – Débit dans le deuxième scénario des Fig. 6.15 – Taille de la fenêtre de contention
deux paires (802.11 normal) (802.11 normal)

B RTS DATA backoff RTS

D CTS ACK

A CS EIFS CS EIFS
NAV

Fig. 6.16 – L’origine du problème dans la deuxième configuration à quatre nœuds

1.6e+06
A -> C (bensaou) A (bensaou)
B -> D (bensaou) B (bensaou)

1.4e+06 1000

1.2e+06
taille de la fenetre de contention

800
debit en bits par seconde

1e+06

600
800000

600000
400

400000

200
200000

0 0
0 2 4 6 8 10 0 2 4 6 8 10
temps en secondes temps en secondes

Fig. 6.17 – Débit dans le deuxième scénario des Fig. 6.18 – Taille de la fenêtre de contention
deux paires (802.11 Bensaou) (802.11 Bensaou)

81
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC

1.6e+06
A -> C (modif.) A (modif.)
B -> D (modif.) B (modif.)

1.4e+06 1000

1.2e+06

taille de la fenetre de contention


800
debit en bits par seconde

1e+06

600
800000

600000
400

400000

200
200000

0 0
0 2 4 6 8 10 0 2 4 6 8 10
temps en secondes temps en secondes

Fig. 6.19 – Débit dans le deuxième scénario des Fig. 6.20 – Taille de la fenêtre de contention
deux paires (802.11 modifié) (802.11 modifié)

il a besoin d’ajouter des informations dans les RTS, qui doivent donc être utilisés (ce n’est pas
toujours le cas pour les paquets de données envoyés en unicast, et ne l’est jamais pour ceux diffusés).
Enfin, il faut noter qu’il existe toujours des conditions face auxquelles ce type d’algorithme est
impuissant. C’est 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 scénario des trois
paires que nous avions étudié précédemment.

82
Deuxième partie

Expérimentations en environnement
réel

83
CHAPITRE
Objectifs des mesures et
7 moyens mis en œuvre

7.1 Introduction et objectifs


Les iimplantations de 802.11 sous simulateurs sont en général partielles, et parfois incorrectes.
Une simulation détaillée de la couche MAC peut être particulièrement coûteuse et inappropriée
pour des simulations à grande échelle. Et une simulation détaillée de la couche physique serait
inexploitable la plupart du temps car bien trop complexe et donc trop lente (si l’on ne considère
pas la mobilité, certaines techniques peuvent néanmoins être employées [61, 62].
Le travail des concepteurs des simulateurs consiste entre autre à simplifier le code simulé tout
en faisant en sorte que son comportement reste suffisamment réaliste. Mais cette notion de réalisme
varie en fonction de l’utilisation. Par exemple la simulation de la diffusion d’une vidéo dans un
réseau à points d’accès (un flux de paquets ré-émis uniquement par les stations de base et où des
pertes sont acceptées) ne sera pas affectée de la même façon par le manque de détail dans la couche
physique que le fonctionnement d’un protocole de routage ad-hoc (où la perte de quelques paquets
peut considérablement altérer la vision de la topologie, et où la perte d’un paquet par nœud de la
chaı̂ne de transmission en prive tous les nœuds suivants). Par conséquent, et particulièrement dans
le contexte des réseaux ad hoc, les résultats obtenus par simulation peuvent être différents de ceux
obtenus dans la réalité. Or très peu d’expériences ont été réalisées en contexte ad hoc. De plus, les
rares expériences menées avaient pour but d’évaluer différents protocoles de routage et non 802.11.

Comme les cartes 802.11 sont disponibles sur le marché, et que les matériels nécessaires étaient
suffisamment abordables, nous avons donc décidé de mener des séries de mesures. Nous avons ainsi
pu mener une première évaluation de 802.11 en environnent ad hoc réel. Nous avons également pu
comparer les mesures réelles aux simulations et nous assurer que les hypothèses faites à partir des
simulations sur le comportement de 802.11 dans un réseau ad hoc étaient correctes.

7.2 Les environnements de mesure


Dans un permier temps, il nous fallait réaliser des expériences simples, permettant de vérifier
que les cartes se comportaient comme prévu dans des situations standards (mesures de débit sans
interférences extérieures, portée, etc.). Il nous fallait ensuite pouvoir mettre en place des scénarios
représentant des utilisations caractéristiques des réseaux ad-hoc (communications multi-saut en
particulier). Et il nous fallait enfin obtenir des traces suffisamment détaillées sur le déroulement
de ces scénarios pour pouvoir conclure sur l’impact de 802.11 à l’exclusion de tout autre protocole
(TCP/IP en particulier).

84
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN ŒUVRE

Si les simulations sont utilisées très largement dans les travaux sur les réseaux ad hoc, ce n’est
pas le cas des mesures en environnement réel. Cela vient du fait qu’il faut disposer du matériel
(les ordinateurs et les cartes réseau), mais aussi de la main d’œuvre. Autant il est aisé pour une
personne seule de développer et de conduire des simulations, autant cela s’avère difficile dès que
l’on cherche à reproduire dans la réalité des scénarios ad hoc.

7.2.1 Travaux antérieurs basés sur des mesures


Malgré la difficulté logistique de telles études, leur intérêt est certain, en particulier en tant que
complément des résultats des simulations. Plusieurs travaux, qui cherchent avant tout à évaluer
des protocoles de routage bien précis, mettent donc en œuvre des mesures réelles. Dans [63] et
[64] les auteurs évaluent DSR en utilisant quelques ordinateurs fixes et une demi-douzaine d’autres
embarqués dans des voitures se déplaçant sur le campus. Des récepteurs GPS (Global Positioning
System) sont utilisés pour connaı̂tre les positions précises de mobiles, et les données sont sauve-
gardées de manière à pouvoir être rejouées ensuite dans des simulations.
Dans [65], c’est ABR qui est évalué dans une configuration de un à trois sauts. Quatre mobiles
sont utilisés pour réaliser cette expérience. Ils sont cependant disposés à des distances maximales
de 50 mètres les uns de autres, les obstacles (bâtiments, arbres, etc.) empêchant le réseau d’être
entièrement maillé.
ODMRP quant à lui est évalué par des mesures réelles dans [66] grâce à sept ordinateurs
organisés dans des configurations multi-sauts. Dans certaines des expériences présentées, l’un des
ordinateurs se déplace d’ailleurs au cours de la mesure.

7.2.2 Ad hoc Protocol Evaluation (APE)


APE [67, 68] est un environnement dédié à l’évaluation des protocoles de routage des réseaux
ad hoc. Il est développé à l’université Uppsala en Suède où l’idée de le créer avait germé lorsqu’un
certain nombre d’étudiants avaient été équipés d’ordinateurs portables et de cartes réseau sans fil.
Le matériel et la main d’œuvre disponibles, il était en effet intéressant de les utiliser. APE est fourni
sous la forme d’une distribution Linux (RedHat) accompagnée d’un certain nombre d’utilitaires.
Les Wireless Tools [69] (un ensemble d’utilitaires permettant de configurer les cartes réseaux sans
fil et de récolter certaines informations sur leur fonctionnement telles que les niveaux de signal et
de bruit) sont utilisés pour configurer le matériel. Les cartes doivent être en particulier placées
en mode ad hoc (au sens de 802.11), et des adresses IP doivent être assignées à chaque machine.
L’objectif principal d’APE étant de permettre les comparaisons entre protocoles de routage, une
douzaine d’entre eux sont fournis directement (dont AODV, DSR, TORA, OLSR, TBRPF, etc.).
Afin de pouvoir mener à bien ces comparaisons, la reproductibilité des résultats est un élément
capital, aussi APE fournit-il un système permettant de régir par des scripts l’ensemble des actions.
Après une étape de synchronisation des horloges (une heure de déclenchement relative à l’heure de
début de la mesure est associée à chaque événement, d’où la nécessité d’une synchronisation au tout
début), les scripts contrôlant le déclenchement des différentes sources sont lancés. Les personnes
ayant en charge chacune des machines n’ont pas besoin de connaı̂tre les détails des scénarios ; des
informations elles aussi scriptées sont affichées pour leur donner les instructions de déplacement au
fur et à mesure.
Une fois une mesure terminée, les données sont centralisées sur une machine grâce à des uti-
litaires fournis. Un ensemble de programmes permet alors de traiter ces données et d’en tirer un

85
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN ŒUVRE

nombre important de métriques (taux de pertes de paquets, optimalité des routes, ...). Des outils
permettent également de générer des graphiques divers. Enfin, la notion de mobilité virtuelle est
définie et peut être calculée et affichée. Elle est calculée à partir des informations de niveau de signal
issues des Wireless Tools et les transpose en une information de distance perçue qui possède une
grande représentativité du scénario étudié (les mobiles dont on reçoit les paquets avec un niveau
de signal faible sont considérés comme loin).
Bien que virtuellement n’importe quelle application réseau puisse être utilisée, dans les articles
sur APE dont nous avons connaissance, les données envoyées sont des paquets ”ping” ICMP envoyés
à intervalles réguliers. Des flux avec des trafics si réduit sont couramment utilisés dans les simulation
destinées à tester les protocoles de routage (comme nous l’avons déjà mentionné dans le chapitre 4),
mais ne donne malheureusement pas forcément une bonne idée de ce qui se passe si le réseau est
ensuite chargé par une application quelconque.
Il faut noter que APE fournit aussi un utilitaire (mackill) permettant d’instaurer une topologie
virtuelle en forçant certaines machines à ignorer les paquets venants de certaines autres. Ceci est
particulièrement utile pour tester certains comportements des protocoles de routage sans avoir à
déplacer tous les mobiles dans la position multi-sauts adéquate. Ce mécanisme a une contrepartie
cependant : les effets des interférences (de l’environnement et des mobiles entre eux) sur les pro-
tocoles de routage ne seront pas forcément réalistes. Par exemple, il est possible de simuler une
chaı̂ne de 10 sauts en gardant tous les mobiles dans une seule pièce, mais il n’y aura alors aucune
réutilisation spatiale : un seul mobile pourra émettre à un instant donné .

7.3 Description de l’outil forwarding


Nous avons vu que les outils disponibles étaient surtout orientés sur l’évaluation de solutions
complètes (mobiles équipés 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. Plutôt que de chercher à
modifier des programmes existants, nous avons préféré développer un nouveau logiciel, qui se voulait
simple et spécialement adapté à nos mesures. Les caractéristiques retenues étaient les suivantes :

Un programme simple. Comme nous cherchions à réaliser quelque chose de simple, le pro-
gramme (appelé forwarding) a été écrit en langage C. Il fonctionne sous linux, et s’appuie sur les
wireless tools [69]. Pour des raisons pratiques, le programme a été installé sur un cdrom bootable
de linux, accompagné des outils nécessaires pour sauvegarder temporairement les résultats sur des
partitions aussi bien linux que windows. Il était ainsi assez aisé de réaliser nos mesures sur divers
portables, en fonction de ce que l’on pouvait emprunter le jour de l’expérience (dans certaines
mesures, nous avons utilisé jusqu’à 8 portables simultanément). A la fin de l’expérience, les fi-
chiers de résulats (qui pouvaient occuper plusieurs centaines de mega-octets) étaient centralisés
sur une machine fixe avant d’être dépouillés. A noter également que la version de linux sur le CD
était minimaliste, afin d’éviter des interférences avec des démons ou autres processus utilisant des
ressources.
Le programme lui-même, une fois lancé, présente une simple ligne de commande où l’utilisateur
peut à loisir configurer divers paramètres, afficher en temps réels des informations sur les paquets
reçus, et surtout démarrer ou arrêter des sources de données.

86
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN ŒUVRE

Pas de protocole de routage. Nos objectifs initiaux étaient entre autres de mesurer les in-
terférences entre nœuds voisins lorsque l’on réalise des communications multi-sauts, et nous comp-
tions pour cela nous appuyer sur les communications en mode diffusion (broadcast) des cartes 802.11.
L’idée était qu’au niveau de chaque nœud on pourrait ainsi recevoir et garder une trace des paquets
qui ne nous étaient pas réellement destinés et qui étaient néanmoins reçus avec suffisamment de
puissance. Ceci avait pour but de rendre l’analyse plus facile et plus complète.
Afin de gérer les communications multi-sauts, notre programme avait donc la charge d’effectuer
ou non une ré-émission des paquets, en fonction de règles établies préalablement à la mesure. Ces
règles de ré-émission (ou de routage statique) avaient comme autre objectif de nous libérer des
effets non désirables que les protocoles de routage normaux pouvaient provoquer dans nos mesures.
Comme nous nous concentrions sur l’étude de 802.11, les time-out, la sélection non contrôlée des
routes ou les paquets de contrôle générés par un protocole de routage auraient brouillé nos mesures
et rendu les résultas difficilement exploitables.
Ces règles de routages conditionnaient la ré-émission des paquets reçus en fonction d’identifiants
de flux portés par les paquets et / ou des nœuds desquels ils nous arrivaient (champ last-hop dans
l’entête des paquets).

Des flux UDP à débit constant. Là encore, nous voulions nous affranchir au maximum des pro-
tocoles supérieurs à 802.11 qui auraient pu masquer certains résultats. TCP en particulier présentait
de nombreux problèmes. D’une part il générait du traffic supplémentaire dans les deux sens (ac-
quittements et autres paquets de contrôle), mais en fonction de la taille des fenêtres d’émission et
de l’arrivée à temps ou non des acquittements, TCP risquait en plus de détecter une congestion du
réseau et d’y réagir en modifiant encore la taille de sa fenêtre. Il serait alors devenu particulièrement
difficile de savoir si un paquet quelconque avait été vraiment perdu suite à un problème au niveau
de 802.11 ou si on avait eu affaire à l’arrivée en retard d’un acquittement par exemple. Il aurait été
également très difficile avec seulement quelques machines de mesurer les effets de la saturation de
la bande passante physique (si TCP décide de très fortement réduire la taille de sa fenêtre suite à
quelques pertes interpretées comme de la congestion, alors le canal radio sera sous-utilisé).
Nous avons donc préféré n’utiliser qu’UDP, qui nous permet un bien meilleur contrôle des
paquets effectivement envoyés dans les air. Sur chaque nœud, jusqu’à 10 sources UDP à débit
constant peuvent être configurées. Chaque source se voit attribuer un numéro de flux unique à
l’échelle du réseau qui permet d’identifier les paquets de manière unique. La taille des paquets
envoyés ainsi que le débit de ces sources sont configurables de manière très précise.

Des fichiers de trace détaillés. Chaque réception de paquet par un nœud est consignée dans un
fichier de trace, avec la date locale précise du nœud ainsi que des informations diverses (numéro de
séquence, nom de l’émetteur originel, nom du dernier ré-émetteur (last-hop), taille, ...). Un fichier
de trace optionnel peut contenir des informations complémentaires sur le niveau de signal pour
chacun de ces paquets. Mais il s’agit de l’information retournée par le pilote de la carte 802.11 et
par conséquent elle n’est mise à jour qu’à chaque réception de paquet (cela signifie que forwarding
n’est pas capable d’indiquer le niveau de bruit ambiant en dehors des moment où il reçoit des
paquets, entre autres). Une fois les mesures terminées, les différents fichiers de trace sont regroupés
et combinés. Ensembles ils permettent de reconstituer l’historique précis de tout ce qui s’est passé
dans le réseau. Les problèmes d’horloge sont gérés par forwarding. Des outils de synchronisation lui
sont intégrés et seront détaillés par la suite.

87
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN ŒUVRE

Il faut noter que notre programme n’utilise pas de mécanisme particulièrement optimisé pour
la sauvegarde des informations au fur et à mesure de le l’expérience. Dans la pratique, dans les
pires cas un nœud n’avait à écrire que quelques dizaines de milliers d’octets par seconde. Ecrire
directement sur le disque (qui de toute façon dispose de tampons gérés par le système et de tampons
internes) était donc suffisant pour nos besoins. Nous n’avons pas utilisé de mécanisme avancé tel
que la sauvergarde dans un disque virtuel en mémoire vive, qui aurait de toute façon été trop petit
par rapport à la quantité de données récoltées dans certaines de nos mesures les plus longues.

7.3.1 Architecture du logiciel


Forwarding est un programme multi-threads. Au démarrage du programme un ensemble de
threads est initialisé.

L’un d’eux va servir pour les réceptions. Il est en attente constante de paquets venant du
réseau. Lorsqu’un paquet arrive, il applique des règles de filtrage (en particulier un nœud reçoit les
paquets qu’il a lui-même diffusé et il faut les éliminer), puis il inscrit ce paquet dans son fichier de
trace, avant de le traiter et éventuellement de le ré-émettre. Ce thread s’occupe aussi de la gestion
de l’interface avec l’utilisateur (affichage périodique d’informations et lecture des commandes au
clavier et / ou dans des scripts).

Les autres sont utilisés pour générer le traffic Le fait d’utiliser un thread séparé pour
chaque flux évite de mettre en place un système complexe d’ordonnanceur, mais en contre-partie
une légère latence peut être introduite à cause de changements de contexte. Heureusement son
impact est négligeable sur des machines comme celles que nous avons utilisées (au minimum des
Pentium II à 300 MHz).

Dans forwarding, le temps est compté en secondes à partir du lancement du programme. Par
exemple, on peut démarrer un flux à la seconde 100 et l’arrêter à la seconde 150. Evidemment,
puisque le programme n’est pas lancé exactement au même moment sur chacune des machines, il y
a une certaine désynchronisation. Ce problème est en partie résolu grâce à la possibilité de diffuser
un paquet spécial qui force un changement de la date locale au moment de sa réception. L’idée est
que lorsque qu’un paquet est diffusé, tous les nœuds du voisinage le reçoivent au même moment.
L’envoi de ce paquet appelé SYNC est une chose à faire au début de chaque mesure (si des paquets
ont été envoyés avant, il faudra les éliminer des traces car il ne seront pas dans la même échelle de
temps).
Il faut noter aussi que si le programme a été originellement conçu pour envoyer les paquets
en mode diffusion, il est néanmoins capable de les envoyer en unicast. Cela est en particulier
nécessaire lorsque l’on veut mesurer l’impact des acquittements, des RTS/CTS, ou des débits phy-
siques supérieurs à 2Mbit/s (la diffusion est limitée par la norme 802.11 à 2Mbit/s). Les commandes
de création de source ou de mise en place de règles de répétition prennent une adresse IP en pa-
ramètre optionnel. Mais de ce fait il est important qu’avant la mesure proprement dite tous les
nœuds aient été à portée de communication et que des paquets aient été échangés (ping rempli très
bien ce rôle). Cela permet à ARP construire sa table d’adresses MAC des cartes des autres nœuds
et évite que les requêtes ARP soient ensuite mêlées aux paquets de données.

88
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN ŒUVRE

0 4 8
Type Paquet Id Source

Id Destination Id Dernier Emetteur

Num. Seq. Emetteur Num. Seq. Flux

Numéro Flux Taille des Données

Fig. 7.1 – Format de l’en-tête utilisée par forwarding pour tous ses paquets

Nom de l’option Effet


-id détermine l’identifiant unique du nœud
-traceFile spécifie le nom du fichier de trace à utiliser
-qualityTraceFile active l’enregistrement des informations de niveau de signal et de bruit
-script démarre automatiquement le script spécifié après le lancement du programme
-traceSelfDiscard En mode diffusion, les nœuds reçoivent et éliminent leurs propres paquets.
Cette option permet de mémoriser quand même ces paquets.

Tab. 7.1 – Principales options de lancement

7.3.2 Format des paquets


Tous les paquets utilisés par forwarding partagent une en-tête commune (voir figure 7.1) où sont
décrits leur type (DATA ou les diverses variantes de paquets de contrôle ou de synchronisation),
leur source, leur destination, leurs numéros de séquence et leur taille. Cette en-tête a une taille
fixe de 32 octets et il faut noter que les tailles de paquets données sur les nombreuses courbes qui
seront présentées plus tard n’incluent pas toujours cette en-tête (l’inclusion ou non de l’en-tête dans
les valeurs mesurées sera précisée pour chaque courbe). Les nœuds sont identifiés sous forwarding
grâce à un numéro unique donné manuellement au lancement du programme. Lors du démarrage
d’une source de données, un numéro de flux est attribué manuellement à cette source et on peut
ainsi retrouver facilement tous ses paquets (pour les paquets de contrôle, le numéro de flux est
arbitrairement fixé à zéro). Deux numéros de séquence sont gérés : l’un est propre au nœud et est
incrémenté à chaque fois qu’il envoie un paquet, quel qu’en soit le type, l’autre est propre à chaque
flux, et n’est incrémenté que lors de l’envoi de paquets appartenant à ce flux. Le champ du dernier
émetteur est évidemment mis à jour à chaque ré-émission du paquet.
En plus de leur en-tête, les paquets comportent un champ de données (dont la taille est spécifiée
dans l’en-tête). Dans le cas des paquets de contrôle, ce champ contient une commande ou un résultat
d’exécution, dans le cas des paquets de données, ce champ est rempli de zéros pour constituer la
charge utile.

7.3.3 Les commandes disponibles


Un certain nombre d’options peuvent être spécifiées au lancement du programme, les plus
importantes sont présentées dans la table 7.1

89
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN ŒUVRE

Une fois le programme lancé, une ligne de commandes est présentée à l’utilisateur. Les princi-
pales commandes sont détaillées dans la table 7.2.
Avec forwarding nous avons donc à disposition un outil qui va nous permettre de tester des
scénarios sur des réseaux ad hoc et de mesurer les performances de 802.11 sans être perturbés par
les protocoles des couches supérieures.

90
CHAPITRE 7. OBJECTIFS DES MESURES ET MOYENS MIS EN ŒUVRE

Nom de la commande Description


sync [time] synchronise les horloges sur toutes les machines
à portée.
setTime time définit le temps local.
time affiche le temps local.
affichePaquetsRecus 0 | 1 chaque seconde, affiche combien de paquets ont
été reçus, de qui, et à quels flux ils appar-
tiennent.
pingAll diffuse un paquet ping auxquels tous les nœuds
doivent répondre par une paquet pong.
startCBR numSourceThread flowID idSource démarre un flux CBR. L’émetteur, la taille du
delay packetSize [destinationIP] paquet, le délai entre deux paquets consécutifs
et le numéro de flux doivent être spécifiés. Une
adresse IP optionnelle peut être utilisée pour
forcer l’envoi à un destinataire unique.
stopCBR numSourceThread numNode arrête un flux CBR spécifié par le numéro du
nœud et le numéro du thread source qui le
génère.
addForwardingRule idNode flowID IDLas- les paquets ayant le numéro de flux et l’iden-
tHop [destinationIP] tifiant de dernier nœud traversé identiques à
ceux spécifiés seront répétés. Une adresse IP
optionnelle permet de forcer la ré-émission vers
une cible unique.
deleteForwardingRule idNode flowID ID- efface une règle établie grâce à la commande
LastHop précédente.
execScript scriptName exécute le script spécifié.
execCommand shellCommand exécute la commande shell spécifiée.
setPhyTraceList adresses IP les wireless tools ne ”remontent” les informa-
tions de qualité de signal et de bruit que pour
les nœuds dont les adresses ont été spécifiées.

Tab. 7.2 – Les commandes les plus représentatives

91
CHAPITRE
Les premières mesures
8
Au fur et à mesure du développement de forwarding, nous avons réalisé des mesures ; elles
avaient le triple but de tester le programme, d’évaluer 802.11 dans un environnement ad hoc réel,
mais aussi de comparer à la réalité les simulations que nous avions réalisées auparavant avec Network
Simulator.

8.1 Justifications des données mesurées.


Par la suite, nous allons régulièrement présenter des courbes montrant différentes valeurs me-
surées au cours de nos expérimentations. Il est important de préciser de quelle manière ces valeurs
sont obtenues et, le cas échéant, calculées.

Les débits. Pour un flux donné nous avons vu que les paquets ont toujours la même taille.
Lorsque nous analysons les fichiers de trace, nous comptons le nombre de paquets par unité de
temps répondant à un même critère (au moins le numéro de flux, mais parfois plus, comme par
exemple le last-hop) et nous multiplions par la taille des paquets.

Les durées de transmission. Nous présenterons parfois des histogrammes décrivant la distri-
bution de la durée de transmission des paquets. Dans la pratique, nous n’avons pas de moyen de
mesurer directement une telle durée. Nous savons à quel moment l’application envoie le paquet au
pilote, et nous savons à quel moment le paquet est reçu par l’autre mobile ; par contre nous ne
savons pas à quel moment la carte 802.11 a réellement émis le paquet (si elle a trouvé le canal radio
occupé, elle a pu attendre un certain temps avant qu’il ne devienne libre pour elle). Pour réaliser les
histogrammes que nous présentons, nous nous sommes donc toujours placé dans une situation où
une seule source saturait complètement la bande passante, et où aucune interférence externe n’était
présente. Comme le canal était complètement saturé, il devenait possible de connaı̂tre la durée de
transmission en faisant la différence entre les dates de réception de deux paquets consécutifs.

8.2 Le débit en fonction de la taille des paquets


Notre toute première expérience consiste à mesurer le débit effectif dans la configuration
présentée sur la figure 8.1, où un émetteur envoie des paquets à un récepteur situé juste à coté
de lui.
Les paquets UDP comportent un champ de données d’une taille comprise entre 82 et 2532
octets, par incrément de 50 octets. La figure 8.2 présente les résultats des mesures pour différentes

92
CHAPITRE 8. LES PREMIÈRES MESURES

800000
11MBit/s avec WEP
11MBit/s sans WEP
5.5MBit/s
700000 2MBits/s
1MBits/s

600000

debit en octets par seconde


500000

400000

300000

200000

100000

0
0 500 1000 1500 2000 2500 3000
taille des paquets UDP
Fig. 8.1 – Configuration pour la
mesure du débit en fonction de la
taille des paquets (bande passante Fig. 8.2 – Débit utile en fonction de la taille des paquets
saturée) UDP

vitesses de transmission, ainsi que lorsque l’on utilise le système de cryptographie WEP (Wired
Equivalent Privacy) décrit la norme 802.11. Les observations sont les suivantes :

8.2.1 La fragmentation à 1500 octets


La première chose que l’on remarque est le phénomène de décrochement lorsque la taille des
paquets dépasse les 1500 octets. Ce phénomène est lié à la couche IP qui croit avoir affaire à une carte
Ethernet (802.3) et qui cherche à optimiser la taille des paquets pour éviter une refragmentation
(avec Ethernet, la taille maximale d’une trame est de 1500 octets environ, alors qu’avec 802.11 elle
est de 2432 octets). Ici, cette optimisation est malvenue et fait visiblement chuter le débit.

8.2.2 L’impact du WEP


On remarque en second l’impact de l’utilisation de la cryptographie WEP. A 11 Mbits/s, pour
des tailles de paquets supérieures à 1000 octets environ, les performances deviennent sensiblement
inférieures à ce qu’elles sont si on n’utilise pas le WEP (la courbe de débit paraı̂t écrêtée). Nous
avons réalisé de nombreuses expériences pour comprendre ce phénomène qui était tout à fait re-
productible mais qui ne concernait que les communications à 11 Mbits/s et pas celles aux débits
inférieurs. La source du problème apparaı̂t mieux lorsque l’on présente la distribution des durées de
transmission des paquets. La figure 8.3 montre deux histogrammes représentant chacun les durées
de transmissions pour une douzaine de milliers de paquets de 900 et de 1400 octets. La taille de
900 octets a été choisie car d’après la figure 8.2 les flux de paquets de cette taille ne subissent pas
de perte de débit dû au WEP. La distribution théorique est un rectangle (ce qui est normal étant
donné que la durée de transmission d’un paquet d’une certaine taille est composée d’une partie fixe
et du backoff qui est tiré de manière aléatoire et équiprobable entre deux bornes). La distribution
mesurée pour des paquets de 900 octets est proche de la distribution théorique. On peut juste
remarquer un biais du générateur aléatoire qui fait que les paquets ayant des backoffs très courts

93
CHAPITRE 8. LES PREMIÈRES MESURES

700
900 bytes packets
900 bytes packets (theoretical)
1400 bytes packets
1400 bytes packets (theoretical)
600

500
number of packets

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 durée de transmission d’une trame

sont un peu plus nombreux que la moyenne. A ce sujet on peut noter que des cartes présentant
ce type de biais bénéficie d’un débit légèrement supérieur à celui de carte ayant une distribution
plus équitable (en moyenne elles attendent en petit peu moins longtemps avant d’envoyer leurs
données). Par contre dans un environnement où toutes les cartes ont ce biais, cela va se traduire
par une hausse du taux de collision. Ceci est une chose à garder à l’esprit lorsque l’on compare les
performances des cartes de différents constructeurs.
Toujours d’aprè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 n’entre en jeu (vers 1400 octets).
La distribution des durées de transmission des paquets de 1432 octets reflète et permet d’expliquer
ce phénomène. La distribution théorique tout d’abord est logiquement décalée vers la droite (durée
de transmission en moyenne plus longue que celles de paquets de 1032 octets), puisque la partie
fixe de la durée de transmission d’un paquet dépend de sa taille. Mais on remarque tout de suite
deux sous-ensembles dans les durées de transmission effectives. Un certain nombre de paquets
ont été transmis en un temps conforme aux prévisions, mais les paquets du deuxième groupe ont
mis beaucoup plus de temps. De plus l’étalement du deuxième groupe (double de l’étalement du
premier) et sa position (deux fois plus loin) indiquent clairement que ces paquets n’ont étés reçus
qu’après une ré-émission (le backoff est tiré deux fois, d’où l’étalement double).
La raison profonde de cette ré-émission nous est pour l’instant inconnue, le mécanisme du WEP
n’étant pas sensé poser ce genre de problème. Malheureusement le WEP est implanté dans le BIOS
des cartes 802.11 et n’y ayant pas accès nous n’avons pas pu pousser plus loin nos investigations.
Peut-être ce problème se pose-t-il lorsque que le processeur embarqué sur la carte arrive à ses limites
(cryptage/décryptage de gros paquets au débit maximum supporté). Quoi qu’il en soit, dans la suite
de nos expérimentations nous avons décidé de ne plus utiliser le WEP.

94
CHAPITRE 8. LES PREMIÈRES MESURES

7e+06
11 MBit/s avec WEP mesure
11 MBit/s sans WEP mesure
11 Mbit/s theorie
5.5 MBit/s
6e+06 5.5 Mbit/s theorie
2 MBits/s
2 Mbit/s theorie

5e+06
Debit en bits par seconde

4e+06

3e+06

2e+06

1e+06

0
0 500 1000 1500 2000 2500 3000 3500
Taille des paquets UDP

Fig. 8.4 – Comparaison des débits théoriques et mésurés à différentes vitesses et en fonction de la
taille des paquets.

Remarquons que si sur la figure 8.2 l’effet négatif du WEP à 11 Mbit/s paraı̂t 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 divisés en un gros paquet
qui subit l’effet et d’un autre plus petit qui ne le subit pas.
Enfin, mais cela sera juste mentionné car en dehors du cadre de ce travail, il faut noter que le
niveau de sécurité du WEP est en réalité assez faible.

8.2.3 Hormis les problèmes pré-cités, des débits très proches de la théorie
Les débits mesurés sont donc extrêmement proches des débits calculés par la théorie, comme on
peut le voir sur la figure 8.4. Mais on peut cependant noter que les débits utiles sont très éloignés
des débits physiques. Cela est spécialement flagrant lorsque l’on utilise des paquets de petite taille
(le débit utile avec des paquets de 82 octets et plus de 7 fois inférieur au débit 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 débit diminue de 50% environ lorsque la taille passe de 1450
à 1500 octets)

95
CHAPITRE 8. LES PREMIÈRES MESURES

8.3 Partage du canal entre nœuds à portée de communication


8.3.1 Deux flux (combinaisons d’émetteurs et récepteurs)
Après nous être intéressés à la capacité du canal lorsqu’il n’y a qu’un seul émetteur, nous nous
sommes ensuite tournés vers des scénarios où plusieurs émetteurs proches les uns des autres sont
en contention pour l’accès au médium.
Nous avons tout d’abord utilisé quatre mobiles situés dans la même pièce (et donc à portée de
communication directe), et nous avons réalisé les diverses combinaisons de flux présentées sur la
figure 8.5. Les flux de données étaient constitués de paquets UDP de 1000 octets, envoyés aussi vite
que possible. Les cartes étaient configurées pour fonctionner à 11 Mbit/s sans utiliser de RTS/CTS.
Les résultats de cette expérience sont présentés sur la figure 8.6 et peuvent être interprétés de
la façon suivante (l’ordre n’est pas chronologique, mais présente les situations les plus simples en
premier) :
– secondes 175 à 195 : Il n’y a qu’un seul flux (de 3 vers 2), et donc aucune contention. On
obtient le débit maximum observé dans les expériences précédentes dans les mêmes conditions,
soit un petit peu plus de 600 paquets de 1000 octets par seconde.
– secondes 120 à 125 et 150 à 165 : Il n’y a qu’un seul flux (de 1 vers 2 cette fois-ci). On
obtient là encore le débit maximum.
– secondes 100 à 120 et 125 à 150 : Il y a deux flux en contention. On observe la même
chose que les récepteurs soient deux nœuds différents ou non. On remarque immédiatement
une différence de débit entre les deux flux (l’émetteur 1 accède un peu moins souvent au canal
que l’émetteur 2). Les cartes 802.11 utilisées étaient à priori les mêmes, et ce phénomène peut
probablement être imputé soit à l’hétérogénéité de nos machines, soit à des différences non
documentées entre nos cartes (de même marque et de même modèle). Il est important de
remarquer que la somme des deux flux simultanés est légèrement supérieure au débit obtenu
par un flux unique isolé. Ce phénomène s’explique par la décrémentation en parallèle des
backoffs sur chacun des émetteurs. En effet, lorsque dans ce scénario le canal devient initiale-
ment libre, les deux stations choisissent un backoff aléatoire et commencent à le décrémenter.
Dès que l’une d’elles a terminé, elle émet et bloque la décrementation de l’autre station.
Mais quand le canal redevriendra libre, l’autre station reprendra la décrémentation là où elle
s’était arrêtée (au lieu de tirer un nouveau backoff), et statistiquement finira donc rapidement
sa propre décrémentation. Finalement, on observe une diminution de la durée moyenne du
temps d’inactivité séparant deux trames (de sources différentes) sur le canal, et donc une
augmentation du débit.

8.3.2 Flux multiples


Dans ce scénario, nous avons observé l’activité sur le canal radio alors qu’un nombre croissant
de flux étaient en contention pour y accéder. Comme précédemment, les mesures ont été effectuées
avec des paquets UDP, les RTS/CTS n’étaient pas utilisés et le débit nominal était de 11 Mbit/s.
L’expérience est divisée en 7 phases (voir figure 8.7, où à chaque étape un flux supplémentaire est
activé), et où chaque phase est elle-même divisée en 5 périodes de 20 secondes où les flux sont
constitués de paquets d’une taille donnée (200, 500, 1000, 1400 et 2000 octets, dans cet ordre).
La figure 8.8 présente les débits agrégés en paquets par seconde (c’est à dire la somme des débits
des différents flux). Comme on pouvait s’y attendre, on voit bien que pour une étape donnée, plus

96
CHAPITRE 8. LES PREMIÈRES MESURES

700

600

number of packets received per second


1 2 1 2 1 2 2
500

3 4 3 3

400
1 −> 2

3 −> 2 3 −> 2
300

3 −> 4

200

0 120 125 150 165 175 195


time in seconds flow 1 -> 2
100 flow 3 -> 4
flow 3 -> 2
flow 3 -> 2
Fig. 8.5 – Deux paires à portée de 0
communication 100 120 140
time in seconds
160 180 200

Fig. 8.6 – Débit quand deux paires sont à portée de


communication

1400

1200
1
throughput in packets received per second

1000
201 301 401 501 601 701 801

2 3 4 5 6 7 8
800

201
600
301
401

501
400
601
701
801 200

time
0
1 flow 2 flows 3 flows 4 flows 5 flows 6 flows 7 flows

Fig. 8.7 – Un à sept flux simultanés number of simultaneous flows

Fig. 8.8 – Debits cumulés pour un à sept flux se parta-


geant le canal

97
CHAPITRE 8. LES PREMIÈRES MESURES

2000

1800

1600

1400

number of packets
1200

1000

800

600

400

200

0
0 0.0005 0.001 0.0015 0.002 0.0025 0.003 0.0035 0.004
time elapsed between 2 consecutives packets

Fig. 8.9 – Distribution des temps de transmission des paquets de 1000 octets lorsque 7 émetteurs
sont en contention

les paquets sont petits, plus ils sont nombreux à être envoyés au cours d’une seconde. Mais on
remarque aussi que lorsque le nombre d’émetteurs en contention augmente, le débit total augmente
lui aussi légèrement. Ceci est du au phénomène détaillé dans l’expérience précédente. Lorsque le
canal devient libre, tous les nœuds ont des paquets à envoyer, et décrémentent donc leur backoff
en parallèle. Plus il y a de flux en concurrence, plus les chances sont grandes que l’un d’eux ait un
backoff restant court, et donc que le canal soit rapidement réoccupé. L’effet est plus visibles avec
des paquets de petites tailles, puisqu’on en envoie plus par seconde et que l’on gagne ainsi du débit
sur chacun de leurs backoffs. Evidemment, ce phénomène est progressivement contrebalancé par les
collisions. Plus il y a de flux en contention, plus les chances sont grande que deux nœuds aient fini
en même temps de décrémenter leurs backoffs et émettent en même temps. A partir de cinq flux en
contention, le débit global n’augmente donc plus.
La figure 8.9 présente la distribution du temps séparant deux paquets consécutifs de 1000
octets lorsque 7 émetteurs sont en contention. Contrairement à ce que l’on avait pu observer dans
la figure 8.3 où il n’y avait qu’un seul flux et où la distribution était assez homogène, ici on voit un
regroupement des écarts vers les valeurs les plus basses (la durée minimale de transmission de nos
paquets, lorsque le backoff tiré est nul, est de 1300 µs environ, et d’un peu plus de 1900µs lorsque
qu’il est maximal et qu’il n’y a pas eu de collision avant). Ceci est tout à fait en adéquation avec
nos remarques précédents sur l’augmentation du débit lorsque le nombre de flux augmente.
En sus du pic principal, on remarque qu’un certain nombre de paquets on été transmis en un
temps environ doublé par rapport à la majorité (pic vers 2.5 ms). Ces paquets sont en fait ceux qui
ont subi une collision et qui ont du être réémis. Dans ce graphique, dans 93.25% des cas, le temps
séparant deux paquets consécutifs était de moins de 2000 µs. Cela signifie que le taux de collision
était finalement assez faible malgré la présence de 7 émetteurs (6.75% seulement des paquets ont
eu besoin d’une réémission).

8.4 Les mesures de portée


L’étape suivante dans l’analyse du comportement de 802.11 dans le contexte des réseaux ad-hoc
est l’étude de la portée de communication réelle. Nos objectifs à plus long terme étaient évidemment

98
CHAPITRE 8. LES PREMIÈRES MESURES

de réaliser des mesures dans des configurations typiquement ad-hoc telles qu’une chaı̂ne, et la portée
de communication est une donnée dont nous avons besoin pour préparer ces futures mesures.
Nous avons vu dans le chapitre qui leur est dédié que les simulateurs considèrent en général
que les zones de communication sont circulaires et centrées sur le mobile (avec des variantes, telle
que le modèle shadowing qui ajoute une probabilité de perte des paquets sur le bord de ce cercle).
Les expériences décrites dans ce chapitre avaient pour but de comparer la réalité avec ces résultats
théories.

8.4.1 L’environnement et le outils de mesure


Le matériel utilisé. Comme dans les autres expériences, nous utilisons forwarding sur des por-
tables PC démarrés avec notre CD de linux. Dès ces premières expériences en extérieur, il est
important de noter que le matériel joue un grand rôle. La longévité des batteries en particulier est
largement affectée par la température, et il faut en tenir compte lors de la conception des scénarios
de mesure et des scripts de commandes. Les cartes radio utilisées sont des cartes Orinoco ou Wave-
Lan de Lucent Technologies, elles émettent avec une puissance de 15 dBm et utilisent leurs antennes
intégrées.

L’environnement. L’environnement n’est jamais neutre ; comme ces mesures de portée sont
préparatoires pour des mesures sur des configurations véritablement ad hoc, nous avons choisi de
les effectuer en extérieur, dans un environnement suffisamment dégagé. Nous avions en effet effectué
des mesures préalables en intérieur, et il était rapidement apparu qu’il était impossible d’y mettre
en place une configuration avec une chaı̂ne d’une longueur supérieure à deux sauts (notre bâtiment
est trop petit, et il est impossible de placer des mobiles de telle sorte qu’ils ne puissent communiquer
qu’avec leurs voisins directs. Quoique nous fassions, chaque mobile peut atteindre n’importe quel
autre en deux sauts maximum).
L’endroit retenu pour nos expériences est une piste cyclable le long d’un 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
homogénéité dans l’environnement (bordé d’un coté par une route, de l’autre par un parc que l’on
surplombe de quelques mètres). Le muret nous fournit le support pour poser nos portables.

8.4.2 Les résultats


Afin d’évaluer la portée de communication de nos cartes, nous utilisons deux portables ini-
tialement très proches l’un de l’autre et que l’on éloigne par étapes successives. La vitesse de
transmission physique est de 11Mbit/s. A chaque étape, le mobile émetteur envoie à l’autre des
rafales consécutives de paquets de différentes tailles (200, 500, 1000 et 1400 octets) et qui durent
chacune une vingtaine de secondes. L’orientation des machine a un impact tout à fait remarquable
sur les résultats, et nous répétons donc nos mesures dans diverses positions. Les débits obtenus en
fonction de la distance, de la taille des paquets et de l’orientation des cartes sont présentés sur la
figure 8.12. Plusieurs remarques importantes peuvent êtres faites :
– En fonction de l’orientation des cartes, la portée de communication varie grandement (d’un
facteur supérieur à 2 entre la position la plus et la moins favorable). Cartes émettrices et
réceptrices dos à dos, le débit utile est déjà grandement affecté à une distance de 45 mèttres,

99
CHAPITRE 8. LES PREMIÈRES MESURES

route
terre-plein central
route

piste

muret

parc (en contre-bas)

Fig. 8.10 – L’environnement pour les mesures de


portée
Fig. 8.11 – L’environnement pour les mesures
de portée

alors que face à face il ne commence à baisser qu’à partir de 75 mètres et que les communi-
cations restent possibles jusqu’à 150 mètres environ. Sur les figures 8.14 et 8.15 sont indiqués
les niveau de signal et de bruit mesurés pour chacun des paquets correctement reçus. On re-
marque l’affaiblissement de la puissance du signal (de l’ordre de 10dBm en moyenne) lorsque
les antennes sont dos à dos (figure 8.14) plutôt que face à face (figure 8.15). Il faut noter
aussi que l’orientation de la carte réceptrice est tout aussi importante que celle de la carte
qui émet, comme on peut le voir avec les différences entre les mesures dans les positions 1 et
2 de la figure 8.12.
– A part à courte distance où l’on obtient bien celui prévu, une grande instabilité dans le débit
utile apparaı̂t. A une distance fixée (par exemple 90 mètres dans le cas des cartes face à face),
le débit varie grandement en fonction du temps. L’environnement réel est loin d’être stable
comme le prédisent les modèles simples de propagation dans les simulateurs. Là encore, cette
instabilité est confirmée par les niveaux de signal et de bruit mesurés (figures 8.14 et 8.15)
qui varient dans une plage de 10 dBm à une distance fixée.
– Pour chacune des distances, les mesures ont été effectuées avec 4 tailles de paquets différentes.
On aurait pu penser que les gros paquets seraient plus affectés que les petits par la qualité
du lien radio car ils durent plus longtemps et auraient ainsi plus de chances de subir des
interférences. La figure 8.13 présente les mêmes données que la figure 8.12, mais avec un
lissage (en ordonnée, on peut lire le nombre de paquets reçus par intervalle de 4 secondes
au lieu d’une seconde). A courte distance (15 à 60 mètres), on remarque que les débits en
paquets par seconde diminuent avec la taille des paquets de manière prévisible. Mais plus loin
(par exemple 90 ou 135 mètres), on se rend compte qu’il n’y a pas forcément de relation entre
la taille des paquets et le taux de perte. Ceci est important. On savait que les gros paquets
permettaient d’obtenir un débit utile supérieur à courte distance, mais il apparaı̂t aussi qu’ils
ne sont pas pénalisants quand la distance augmente et que les interférences deviennent sévères.
– Toujours sur la figure 8.12, on peut remarquer que le taux d’échec dans la réception reste
parfois stable pendant certaines périodes. Par exemple à 75 mètres dans la 5ème position,
il semble qu’au milieu de la phase d’envoi des paquets de 200 octets les interférences soient
subitement devenues plus fortes. Une observation attentive des résultats montre que ce type
de phénomène se produit à différentes échelles (parfois ce sont quelques paquets consécutifs

100
CHAPITRE 8. LES PREMIÈRES MESURES

débit en paquets reçus par seconde


1200
paquets de 200 octets
1000 paquets de 500 octets
paquets de 1000 octets
800 paquets de 1500 octets
600

Position 1 400
200
0
15m 30m 45m 60m 75m 90m 105m 120m 135m 150m
débit en paquets reçus par seconde distance en metres

1000
900 paquets de 200 octets
paquets de 500 octets
800 paquets de 1000 octets
700 paquets de 1500 octets
600
500
400
Position 2 300
200
100
0
15m 30m 45m 60m 75m
distance en metres
débit en paquets reçus par seconde

1000 paquets de 200 octets


900 paquets de 500 octets
800 paquets de 1000 octets
700 paquets de 1500 octets
600
500
400
Position 3 300
200
100
0
15m 30m 45m 60m 75m 90m 105m 120m 135m 150m
distance en metres
débit en paquets reçus par seconde

1000
900 paquets de 200 octets
paquets de 500 octets
800 paquets de 1000 octets
700 paquets de 1500 octets
600
500
400
Position 4 300
200
100
0
15m 30m 45m 60m 75m 90m 105m
distance en metres
débit en paquets reçus par seconde

1000
900 paquets de 200 octets
paquets de 500 octets
800 paquets de 1000 octets
700 paquets de 1500 octets
600
500
400
Position 5 300
200
100
0
15m 30m 45m 60m 75m 90m 105m
distance en metres

Fig. 8.12 – Débits mesurés en fonction de la distance, de la taille des paquets et de l’orientation
des antennes (vitesse d’émission 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 différent de ce que l’on 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 donnée.

La figure 8.16 présente quand à elle les débits mesurés lorsque la vitesse d’émission est forcée
à 2 Mbit/s. La tendance générale en fonction de l’orientation des cartes est sans surprise assez
semblable à ce que l’on avait observé à 11 Mbit/s. Lorsque les cartes sont face à face (position 3),
elles peuvent communiquer jusqu’à une distance nettement plus grande que lorsqu’elles sont dos à
dos (position 2), et la position 6 permet une portée intermédiaire. Mais si la tendance en fonction
de l’orientation est semblable, ce n’est pas le cas de la portée qui est logiquement beaucoup plus
grande. Cette fois-ci, des paquets peuvent être reçus jusqu’à 300 mètres environ si l’orientation est

101
CHAPITRE 8. LES PREMIÈRES MESURES

Fig. 8.13 – Débits lissés pour la position 3 et en fonction de la distance

Fig. 8.14 – Niveaux de signal et de bruit pour Fig. 8.15 – niveaux de signal et de bruit pour
la position 2 la position 3

102
CHAPITRE 8. LES PREMIÈRES MESURES

Position 2

Position 3

Position 6

Fig. 8.16 – Débits mesurés en fonction de la distance, de la taille des paquets et de l’orientation
des antennes (vitesse d’émission de 2 Mbit/s)

favorable (position 3). On peut noter également que la portée réelle reste quand même en général
très nettement inférieure à celle prévue par la simulation. Rappelons que pour un débit physique de
2 Mbit/s, le modèle freespace de NS2 prévoyait une portée de 600 mètres sans dégradation, que le
modèle shadowing prévoyait de ne pas avoir de dégradation avant 250 mètres et ensuite des pertes
de plus en plus importantes jusqu’à 700 mètres, et qu’enfin le modèle two-ray ground prévoyait que
jusqu’à 250 mètres on pourrait avoir le débit maximum et plus rien au-delà.
Tout comme on avait pu le voir à 11 Mbit/s, on observe enfin une certaine instabilité à partir
d’une 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 d’analyse avancée
9
Nous avons vu précédemment qu’un chronogramme pouvait être un bon outil pour analyser
finement ce qui se passe, en particulier dans un réseau ad hoc. Nous cherchons donc à reproduire
le même type de graphique que ceux obtenus pour les simulations sous Network Simulator.
Cependant, alors que NS dispose d’une horloge globale et commune à tous les mobiles simulés,
des problèmes se posent lorsque l’on passe à l’expérimentation en environnement réel. Les horloges
des différents portables ne sont pas synchronisées, et quelques expérimentations nous montrent
qu’elles dérivent les unes par rapport aux autres d’une manière que l’on ne peut négliger.
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éel


Les modifications que nous avons apportées à NS nous permettaient de récupérer directement
toutes les informations dont nous avions besoin pour tracer les chronogrammes. Par exemple, nous
avions les dates de début et de fin d’émission physique, les débuts, pauses, reprises, fins de backoffs,
les DIFS, etc. En environnement réel, nous ne disposons que de la date de réception des paquets et
de leur taille. Cependant, comme nous pouvons déduire la durée d’un paquet à partir de sa taille
et de la vitesse d’émission, il reste possible de construire un chronogramme utile bien qu’un peu
moins complet. Certaines précautions doivent être prises cependant, comme par exemple lorsque les
paquets sont envoyés en unicast et qu’il faut prendre en compte les acquittements qui n’apparaissent
pas dans les traces.

9.2 Le problème de la synchronisation


Dans forwarding, un mécanisme simple de synchronisation a été intégré très tôt. Il tire parti
d’une propriété des réseaux radio : tous les mobiles qui reçoivent un paquet diffusé savent qu’ils le
reçoivent à la même date (il n’y a pas de ré-émission, les délais de propagation des ondes sont tout
à fait négligeables dans ce contexte et le paquet envoyé par forwarding contient sa date d’émission,
ce qui permet d’ajuster les horloges des mobiles le recevant de façon à ce qu’elles soient toutes
synchronisées). Si ce mécanisme est suffisamment précis pour les mesures de débit, il ne l’est plus
lorsque l’on veut construire un chronogramme permettant de comparer précisément les dates de
réceptions des paquets sur plusieurs mobiles (les débits sont en général exprimés en octets par
seconde, des décalages de l’ordre du dixième de seconde ne sont pas vraiment gênants dans ce
contexte).

104
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Fig. 9.1 – Position des por-


tables pour la mesure de la
désynchronisation

Fig. 9.2 – Dérive des horloges en secondes (ordonnée)


pour environ 14h30 (abscisse)

En effet, les horloges des portables n’avancent pas exactement à la même vitesse. Nous avons
pu le vérifier en utilisant trois machines placées dans la configuration présentée sur la figure 9.1.
On commence l’expérience par l’envoi d’un message de synchronisation de forwarding, qui assure
qu’à sa réception les dates sur chacune des machines sont identiques. Puis l’émetteur se met à
diffuser des paquets de 1000 octets de données à une cadence régulière. A la réception de ces
paquets (numérotés), chaque récepteur l’estampille avec sa date locale. Nous soustrayons ensuite,
pour chaque paquet, sa date de réception sur l’un des mobiles à sa date de réception sur l’autre.
Idéalement, la différence devrait être nulle à chaque fois. Les paquets sont envoyés au rythme de
10 par seconde et la mesure a duré environ 14h30 (soit un peu plus de 520000 paquets). Comme
on peut le voir sur la figure 9.2, la différence est loin d’être nulle puisqu’au bout de 14h30, les deux
récepteurs sont désynchronisés de 6.5 secondes.
On remarque immédiatement l’apparente linéarité de cette courbe, mais également la présence
de décalages ponctuels plus et plus ou moins fréquents. Ces décalages apparaissent quand, sur l’un
des récepteurs, le processeur est occupé et le paquet est stocké quelques instants dans une mémoire
tampon avant d’être traité et estampillé. Comme le paquet est estampillé ”en retard”, il semble
être reçu à une date très différente vis-à-vis de l’autre récepteur. De tels écarts sont gênants pour
les calculs, mais heureusement forts rares (quelques dizaines pour plus de 500000 paquets envoyés)
et peuvent donc être éliminés avec un système de seuil. Si l’écart entre deux paquets consécutifs
est trop grand, on élimine le paquet ; on obtient ainsi la figure 9.3.
6.5 secondes de décalage en 14h30, cela correspond à environ 7.5 ms de décalage par minute.
La durée de transmission d’un paquet de 1000 octets à 2 Mbit/s est d’un peu plus de 4 ms ; on se
rend bien compte que cette dérive est trop importante pour être ignorée lors de la création de nos
chronogrammes et qu’il va falloir la corriger. La figure 9.4 montre le chronogramme représentant
les réceptions des paquets diffusés tous les 1/10 de seconde lorsqu’aucune correction de la dérive

105
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Fig. 9.3 – Dérive filtrée des horloges en secondes (ordonnée) pour environ 14h30 (abscisse)

Fig. 9.4 – Chronogramme de deux mobiles recevant des paquets diffusés lorsque la dérive des
horloges n’est pas corrigée

106
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Fig. 9.5 – Les strates et la redondance dans le système NTP

n’est appliquée ; le problème y est flagrant, les paquets devraient être reçus exactement en même
temps.

9.3 Résolution du problème de la synchronisation


9.3.1 Les différentes approches, les systèmes existants
La synchronisation des horloges est un problème important que l’on retrouve dans de nombreux
domaine, non seulement les réseaux, mais aussi les systèmes distribués ou les systèmes temps réels.
La synchronisation permet aux composants de maintenir leurs dates système suffisamment proches.
Sa précision dépend des algorithmes utilisés, mais aussi de la topologie ou de la structure du réseau,
des liens de communication, de la charge des machines, etc. Il existe de nombreuses méthodes qui
sont proposées à chaque fois pour des domaines d’application bien spécifiques.

NTP (Network Time Protocol) [70] C’est un protocole très connu dans la synchronisation des
horloges de machines reliées à l’Internet. NTP permet de synchroniser l’horloge d’un ordinateur avec
celle d’un serveur de référence. Le protocole est organisé de façon 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 synchronisée. Dans la pratique on ne dépasse guère
la couche 5.
Les serveurs de niveau 1 se synchronisent sur une source de référence (horloge, récepteur de
temps codé, récepteur GPS). Ces récepteurs décodant les signaux radio de transmission de l’heure
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 déclarés (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 inférieure. Ils n’ont pas à être déclarés ;
tout site peut installer un serveur de strate 3, à la condition de prévenir les administrateurs des sites
de strate inférieure officiels. Les serveurs de strate 4 sont en général, à l’usage d’un réseau local.
Et ainsi de suite pour les couches suivantes, jusqu’aux clients terminaux. Notons que les simples
clients ne sont pas autorisés avant la strate 3.
Comme il l’est mentionné dans [71], dans les réseaux sans fil de capteurs l’utilisation de NTP
s’avère difficile. Il faut un serveur de référence que toutes les machines puissent atteindre. Un réseau
ad hoc peut être partitionné pendant des périodes plus ou moins longues, ce qui pose problème. De
même, la précision que l’on peut espérer de NTP dans le cadre d’un réseau 802.11 est en-dessous
de nos besoin, du fait de l’incertitude sur la durée de transmission d’un paquet (backoff aléatoire,

107
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

collisions, pertes de paquets, ré-émissions par la couche MAC). Une solution à notre problème
aurait été d’installer un réseau filaire entre les machines de notre banc de test et de s’en servir
pour synchroniser les horloges avec NTP. On aurait ainsi pu obtenir une précision de l’ordre de la
milliseconde qui aurait été acceptable pour notre usage ; mais ce n’était techniquement pas possible
pour les expériences en extérieur et sur des distances un peu grandes.

Des méthodes généralistes Certains travaux (comme par exemple [72]) ont essayé de faire une
synthèse sur les recherches dans le domaine de la synchronisation des horloges. Les auteurs ont
classifié les algorithmes de synchronisation en faisant une évaluation sur leur type (déterministe,
statistique, probabiliste), de leur capacité à résister aux pannes (panne de processeur, d’horloge,
de lien ou de transmission, ...), de la procédure de synchronisation (qui peut être symétrique -tous
les ordinateurs jouant le même rôle - ou asymétrique - avec des serveurs par exemple). Les auteurs
divisent la synchronisation en trois étapes :
– Déterminer quand il faut synchroniser.
– Estimer les valeurs des horloges distantes.
– Corriger l’horloge locale après avoir estimé les horloges distantes.
Ces trois étapes sont assurées par trois blocs différents et les algorithmes sont également
classifiés en fonction des techniques utilisées dans chacun de ces blocs.

Néanmoins, ces travaux ne restent qu’au niveau de la présentation et de la classification des


algorithmes et ne spécifient pas leur domaines d’utilisation. Les performances de ces algorithmes
(précision de la synchronisation et nombre de messages à envoyer) dépendent de facteurs comme
la dérive maximale des horloges, le temps de transmission et la gigue des paquets, etc. De plus, ces
techniques ont des contraintes qui ne sont pas forcément compatibles avec notre contexte d’utili-
sation (par exemple elles peuvent nécessiter une connectivité complète du réseau, la présence d’un
système de distribution de temps (GPS), ...). Par conséquent, l’adaptation de ces techniques dans
notre contexte bien spécifique aurait été pour le moins hasardeuse et les résultats non garantis.

Synchronisation dans les réseaux de capteurs Le domaine des réseaux de capteurs [73]
a toujours connu des problèmes de synchronisation. Les applications déployées sur ces réseaux
impliquent souvent la fusion de données qui nécessite une synchronisation. Le protocole RBS (Re-
ference Broadcast Synchronization), décrit dans [71], peut atteindre une précision de 1 µs dans une
zone à un saut (tout les capteurs peuvent communiquer avec tous les autres). Son extension aux
réseaux multi-sauts se fait au prix d’une dégradation de la précision qui reste néanmoins de l’ordre
de la micro-seconde. Dans le contexte multi-sauts, RBS nécessite de maintenir une structure de
routage entre les zones de diffusion. Dans le cadre de notre travail, cela impliquerait d’introduire
un protocole de routage ce qui viendrait perturber les mesures fines de 802.11 réalisées dans les
scénarios.
Une synchronisation post facto est proposée dans [74] : une synchronisation est réalisée juste
après une communication. Le but est d’éviter une consommation d’énergie inutile pour une syn-
chronisation permanente mais non nécessaire. Néanmoins, cette synchronisation peut aussi avoir
un impact sur les mesures que nous voulons réaliser puisque chaque communication serait séparée
par une synchronisation.

108
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Une méthode spécifique L’auteur de [75] a présenté une solution pour la synchronisation des
horloges dans le domaine des réseaux ad hoc. Cette solution suppose que la dérivée de la date
locale d’une horloge C(t) en fonction du temps absolu est bornée :
1 − ρ ≤ ∆C/∆t ≤ 1 + ρ

Ces inégalités conduisent à une relation entre la date locale d’une machine et le temps absolu,
et vice-versa. Grâce à cette propriété et en représentant la date locale par un intervalle de temps,
les auteurs ont pu définir une loi permettant de transformer la date locale d’un machine en la date
locale d’une autre machine (toujours sous forme d’intervalle de temps) après une transmission et
en tenant compte de sa durée. Cette technique permet d’évaluer dans certains cas l’ordre des dates
locales [t1 , t2 ] < [t3 , t4 ] ou d’évaluer combien de temps s’est écoulé entre les événements [t1 , t2 ] et
[t3 , t4 ]. Cependant, il reste toujours de cas où l’on ne connaı̂t pas l’ordre des événements (quand
les intervalles se chevauchent).
La précision de cette méthode de synchronisation dépend du délai de transmission ainsi que du
nombre de sauts que la date locale à synchroniser doit traverser. Cela présente une limite lorsque
l’on veut obtenir une précision de l’ordre du dixième de milliseconde dans un réseau multi-sauts
basé sur 802.11b, où le délai de transmission n’est pas garanti (présence de backoff aléatoires) et où
le nombre de sauts peut être important. De plus, si le réseau est chargé au moment de l’échange des
paquets de synchronisation, alors les délais de transmission pourront être très fortement affectés
(retards pouvant dépasser les dizaine de millisecondes), et la précision de la synchronisation sera
trop faible.

9.3.2 Premières constatations et méthode simple


Sur la figure 9.3, on constate que la dérive des horloges semble linaire. Nous avons effectué
d’autres mesures, et si l’ampleur de la dérive varie (en fonction de l’ancienneté des machines en
particulier elle évolue entre 0.3 et 7.5 ms par minute), nous observons toujours des courbes qua-
siment linéaires. Rappelons que nous ne sommes pas spécialement intéressés par un algorithme de
synchronisation en temps réel des horloges. Nous voulons surtout pouvoir mener une analyse post-
mortem des résultats, et donc une synchronisation a posteriori (ou encore ”recalage” de fichiers de
trace) est tout à fait acceptable. Notre première approche consiste donc à considérer que la dérive
entre deux horloges est approximable par une droite. Ainsi il est possible de choisir une horloge
comme référence absolue, et de corriger grâce à des coefficients linéaires les horloges de toutes les
autres machines pour les ramener dans le même temps. Il suffit de calculer une fois pour chaque
machine le coefficient avec lequel elle dérive par rapport à la référence, puis d’appliquer ce coefficient
à chaque résultat de mesure.
Par exemple, on peut considèrer l’horloge A d’un mobile qui dérive de façon linéaire de 7 ms
par minute par rapport à l’horloge B d’un autre mobile choisie comme référence. La pente de la
droite sur la figure 9.6 est de 7.10−3 /60 en fonction de tA. Une date tAE d’un événement E fournie
par l’horloge A pourra être ramenée à la valeur

tBE = tAE × (1 − 7.10−3 /60) (9.1)


qui est la date de E dans le temps de référence.
Dans un but d’évaluation, nous avons appliqué cette méthode sur les données obtenues
précédemment afin d’ajuster les dates de réception des paquets diffusés. Le coefficient d’ajuste-

109
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

tA - t

t=0 tA
temps local

Fig. 9.6 – Un coefficient linéaire pour passer du temps local ou temps de référence

ment est calculé de la manière suivante : après filtrage des paquets ayant été reçus avec un temps
les séparant de leur prédécesseur s’écartant trop de la moyenne, nous prenons un point en début
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 calculé et appliqué, nous avons analysé l’erreur de synchronisation
résiduelle. L’erreur maximale était de l’ordre de 3.5 ms, avec une erreur moyenne proche de 2.4 ms.
Un distribution de l’erreur pour plus de 520000 paquets est présentée sur la figure 9.7. Cet histo-
gramme montre que l’écart de synchronisation, bien qu’énormément réduit, reste non négligeable
(beaucoup de paquets ont une erreur dépassant les 2 ms, à mettre en rapport avec les seulement
4 ms qui dure la transmission d’un paquet). De plus, les paquets présentant les erreurs les plus
importantes sont le plus nombreux. La méthode de l’approximation par une droite est très simple,
mais ne donne pas des résultats suffisamment précis et nous avons du développer une autre méthode
utilisant une droite affine par morceaux.

9.3.3 Deuxième méthode : approximation de la dérive des horloges par une


droite affine par morceaux
En reprenant les mesures précédentes (figure 9.3), plutôt que de calculer le coefficient direc-
teur d’une unique droite cherchant à approximer l’ensemble 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 même manière que précédemment (la
droite choisie est celle qui passe par le premier et le dernier point de l’intervalle). La précision de la
méthode est ainsi dépendante de la longueur que l’on choisit pour les tranches. Nous avons effectué
les calculs pour plusieurs longueurs différentes (pour un calcul donné, toutes les tranches ont la
même longueur). Les erreurs maximales et moyennes en fonction de la longueur des intervalles sont
présentées dans la table 9.1.
L’histogramme de la figure 9.8 présente la distribution de l’erreur de synchronisation de plus
de 520000 paquets si l’on 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 inférieure à 0.054 ms, les
erreurs importantes étant extrêmement minoritaires. Lorsque l’on prend en compte le fait que le
temps de transmission d’un paquet de 1000 octets est d’environ 5 ms à 2 Mbit/s et de 1.6 ms
à 11 Mbit/s, alors il apparaı̂t que l’utilisation de synchronisation toutes les 20 minutes environ
donnera des résultats suffisamment précis pour nos besoins. Il faut noter que la grande précision

110
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Fig. 9.7 – Distribution de l’erreur résiduelle avec l’approximation par une droite (nombre de paquets
en ordonnée, erreur en ms en abscisse)

Longueur de l’intervalle Erreur maximale Erreur moyenne


5 min 0.23 ms 0.38 µs
20 min 0.31 ms 4.4 µs
30 min 0.44 ms 10 µs
60 min 0.62 ms 30 µs

Tab. 9.1 – Précision de l’approximation par une droite affine par morceaux

111
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Fig. 9.8 – Distribution de l’erreur de synchronisation avec un intervalle de 20 minutes et sur environ
520000 paquets (nombre de paquets en ordonnée, erreur en abscisse)

de cette méthode vient de la propriété des réseaux radio que l’on exploite : plutôt que de chercher
à maintenir à jour l’heure sur chacune des machines en temps réel (comme le ferait NTP) grâce à
des échanges de paquets, nous utilisons le fait que lorsqu’un paquet est diffusé en radio, il est reçu
simultanément par toutes les machines environnantes.

D’un point de vue pratique, cette méthode de synchronisation des fichiers de trace fonctionne
de la manière suivante :
– Au début de la mesure, mise à zéro de l’horloge de toutes les machines (paquet de syn-
chronisation spécial de forwarding, qui nécessite que toutes les machines soient à portée de
communication à cet instant de celle qui envoie le paquet).
– Mesures diverses, pendant lesquelles les machines peuvent se déplacer, le réseau peut être
partitionné, etc.
– Toutes les 20 minutes environ, arrêt des mesures, regroupement de l’ensemble des machines
à portée de celle qui synchronise et diffusion par celle-ci d’un paquet qui sera reçu par toutes
les autres et qui délimitera ainsi un intervalle.
– Fin de la mesure, centralisation des fichiers de trace et ”recalage”.
La figure 9.9 présente le chronogramme obtenu lorsque l’on corrige la dérive des horloges avec
cette méthode. La synchronisation est bien meilleure, les données sont tout à fait utilisables.
Cette méthode a aussi été testée dans le scénario présenté sur la figure 9.10, où deux émetteurs
cherchent chacun à envoyer autant que possible de paquets de 1000 octets et saturent le canal. Le
chronogramme obtenu est présenté sur la figure 9.11
S’il reste du trafic de mesure dans le réseau lorsque les paquets de synchronisation sont diffusés,
il y a un risque que l’envoi de ces paquets soit retardé (phénomène de defering induit par 802.11),

112
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Fig. 9.9 – Chronogramme de deux mobiles recevant des paquets diffusés lorsque la dérive des
horloges est corrigée avec la deuxième méthode

Synchro

Data
Data

Fig. 9.10 – Disposition des mobiles pour l’évaluation de la synchronisation (deux sources de
données)

Fig. 9.11 – Chronogramme de deux mobiles diffusant des paquets lorsque la dérive des horloges est
corrigée avec la deuxième méthode

113
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

1 2 3 4 5

Fig. 9.12 – Le synchronisateur pèlerin visite régulièrement les autres mobiles et leur transmet la
bonne horloge

faussant ainsi un peu l’échelle de temps. Cependant, et c’est le plus important, même dans ce
cas l’ordonnancement de l’ensemble des paquets ne sera pas vraiment affecté ; pas plus que par la
dérive de l’horloge de la machine synchronisatrice. Le seul risque est plutôt que des paquets de
données entrent en collision au niveau de certains mobiles avec les paquets de synchronisation, et
la perte de ces paquets est beaucoup plus dommageable.

Rapporter régulièrement tous les portables à portée de communication du synchronisateur n’est


pas toujours aisé, en particulier lorsque l’on travaille sur des scénarios qui demandent un placement
précis de machines. Les déplacer 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 négligeable. De
plus cette phase de déplacement de toutes les machines peut demander un temps et une ”main
d’œuvre” considérables s’il y a beaucoup de machines. Hors c’est autant de temps pendant lequel
les batteries s’épuisent inutilement. Nous avons donc raffiné notre méthode.

9.3.4 Troisième méthode : le pèlerin synchronisateur


Nous avons vu qu’avec la méthode de l’approximation de la dérive des horloges par des droites af-
fines par morceaux, une durée d’une vingtaine de minutes était un bon compromis entre la précision
de la méthode et le travail occasionné. Cette fois-ci cependant, le moment venu, plutôt que de
déplacer toutes les machines vers le synchronisateur c’est le synchronisateur lui-même que nous
déplaçons (exemple d’un longue chaı̂ne sur la figure 9.12). La différence majeure avec la méthode
précédente tient dans le fait que, dans certaines topologies, aucun des paquets envoyés par le syn-
chronisateur ne pourra atteindre tous les mobiles à la fois. Il ne sera plus possible de comparer les
dates locales de réception d’un même paquet pour calculer la dérive relative des horloges.
La solution choisie consiste à faire porter par les paquets de synchronisation une information
horaire. En l’occurrence, ces paquets sont émis à une fréquence fixe et précise (par exemple toutes
les 5 secondes). Grâce au numéro de séquence du paquet, il est possible de calculer directement
l’heure de réception de ce paquet dans l’horloge de référence (en multipliant le numéro de séquence
par le temps séparant l’émission de deux paquets consécutifs). Il faut noter qu’ici l’horloge de
référence est donc l’horloge de la machine qui envoie les paquets de synchronisation.
Comme précédemment, la synchronisation des résultats se fait post-mortem ; une fois les fichiers
de trace regroupés, ils sont analysés et recalés. Nous appliquons toujours la méthode de l’approxi-
mation de la dérive des horloges par une droite affine par morceaux, mais cette fois-ci les segments
sont délimités par la réception de deux paquets de synchronisation consécutifs. La date de réception
du paquet de synchronisation de numéro de séquence zéro est l’origine du temps global. Si les pa-

114
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Espace de temps global

k*n1 k*n2 k*n3


R(t1-ts1)+(k*n1)
R(t2-ts2)+(k*n2)

t1 t2

ts1 ts2 ts3

Espace de temps local

Fig. 9.13 – Le passage d’une échelle de temps local à une échelle de temps global (méthode du
pélerin)

quets de synchronisation sont envoyés toutes les k secondes alors la date de réception (en temps
global) d’un paquet de synchronisation de numéro de séquence n est :

Tn = k × n (9.2)
Si ts1 et ts2 sont les dates locales de réception de deux paquets de synchronisation consécutifs
de numéros de séquence respectifs n1 et n2 , alors (ts2 − ts1 ) est le temps local qui s’est écoulé entre
les deux. Par définition de 9.2, le temps global écoulé entre les deux est :

k × (n2 − n1 ) (9.3)

Le rapport linéaire entre le temps global et le temps local est donc :


k × (n2 − n1 )
R= (9.4)
(ts2 − ts1 )
t−ts1 exprime le temps local écoulé entre la réception d’un paquet de données et celle du paquet
de synchronisation le précédant. Pour un paquet de données reçu à une date locale t comprise entre
ts1 et ts2 , le temps global T de réception de ce paquet est calculé de la manière suivante :

T = R × (t − ts1 ) + k × n1 (9.5)

Grâce à ces formules, nous pouvons projeter les dates de réception locales de tous les paquets
sur une échelle de temps global constituée par la réception des paquets de synchronisation. La
figure 9.13 donne un exemple de cette relation. Les temps locaux (estampillés à la réception des
paquets) sont indiqués dans la partie basse du schéma, les formules pour les convertir en temps sur
l’échelle globale sont indiqués dans la partie haute. Les paquets de synchronisation sont schématisés
par des traits verticaux épais, les paquets de données par des traits verticaux fins.
Il faut noter que cette méthode peut être améliorée afin de fournir des chronogrammes toujours
plus précis. En effet, telle que nous l’avons décrite, nous utilisons la propriété qu’un paquet radio
est reçu exactement au même moment par les mobiles à portée de communication, mais nous ne
nous servons que des paquets dits ”de synchronisation” qui sont envoyés assez peu souvent.
Au cours de la mesure, un grand nombre de paquets de données sont en général envoyés.
Si certains de ces paquets sont envoyés en mode diffusion, au moment de l’analyse des traces,
nous les retrouverons sûrement à plusieurs endroits. Là encore, on peut utiliser la propriété de

115
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE

Synchro Data

Fig. 9.14 – Disposition des mobiles pour l’évaluation de la synchronisation (une source de données)

Fig. 9.15 – Chronogramme de deux mobiles recevant des paquets diffusés lorsque la dérive des
horloges est corrigée avec la troisième méthode

simultanéité pour améliorer la synchronisation entre les différents mobiles qui ont reçu un même
paquet. En quelque sorte, ces paquets nous donnent des jalons intermédiaires entre les paquets de
synchronisation qui nous donnent eux-mêmes le temps absolu. Dans les sous-segments délimités par
tous ces paquets, nous appliquons toujours le mécanisme d’approximation par des droites affines
par morceaux.
Au final, cette méthode permet d’obtenir une très grande synchronisation des traces, compatible
avec nos besoins.
De part la nature de la méthode, pour la valider il a fallu utiliser la topologie présentée sur
la figure 9.14 (elle consiste à rependre celle présentée sur la figure 9.1 et à ajouter le mobile
synchronisateur). Il y a toujours deux mobiles récepteurs, mais en plus du mobile synchronisateur,
un autre mobile a été ajouté qui diffuse des données à la vitesse de 10 paquets de 1000 octets par
seconde. Ce sont la réception de ces données sur les deux mobiles récepteurs qui est présentée 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 scénario de la figure 9.10, les résultats sont également 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 dérive des horloges est
corrigée avec la troisième méthode

116
CHAPITRE
Les scénarios ”avancés”
0

10
Après avoir réalisé un certain nombre de mesures préparatoires et développé des outils de
synchronisation adéquats, nous avons pu passer à des mesures dans des scénarios plus complexes.
A des fins évidentes de comparaison, nous avons cherché à reproduire dans la réalité les scénarios
que nous avions utilisé lors de la phase de simulation. Les problèmes d’accès au canal seraient-ils
aussi sévères que les simulations et les calculs le laissent supposer ? Dans ce chapitre, nous allons
présenter les résultats obtenus pour des configurations à deux et trois paires ainsi que pour une
chaı̂ne comportant de 1 à 4 sauts.

10.1 Les deux paires


Jusqu’à présent, nous nous sommes intéressés à la portée effective des cartes 802.11. Dans
cette expérience, nous cherchons à mesurer jusqu’à quelle distance des mobiles peuvent détecter
réciproquement leurs porteuses et à partir de quand la réutilisation spatiale devient possible. Pour
ce faire, nous utilisons quatre mobiles répartis en 2 paires. Ces quatre mobiles sont initialement
très proches et au fur et à mesure de l’expérience nous allons éloigner les deux paires l’une de
l’autre comme indiqué sur la figure 10.1. L’orientation des cartes est également celle indiquée sur
la figure 10.1, c’est à dire sur les côtés par rapport au sens de déplacement, et non face-à-face ou
dos-à-dos. Dans la pratique nous éloignons les paires par étapes successives. Chaque étape 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 d’inactivité pendant lesquelles nous déplaçons les mobiles,
puis un nouveau cycle commence. La figure 10.2 décrit les combinaisons de flux pendant les phases
de transmission (nous rappelons que la diffusion se fait toujours à 2 Mbit/s, et qu’ici l’envoi en
unicast est configuré pour se faire à 11 Mbit/s) :
– 0 à 15 : Un flux à 11 Mbit/s dans la paire de droite et un flux à 2 Mbit/s dans celle de
gauche.
– 15 à 20 : Uniquement le flux à 2 Mbit/s dans la paire de gauche.
– 20 à 35 : Un flux à 2 Mbit/s dans chacune des paires.
– 35 à 40 : Un flux à 2 Mbit/s uniquement dans la paire de droite.
– 40 à 55 : Un flux à 11 Mbit/s dans la paire de gauche et un flux à 2 Mbit/s dans celle de
droite.
– 55 à 60 : Un flux à 11 Mbit/s uniquement dans la paire de gauche.
– 60 à 75 : Un flux à 11 Mbit/s dans chacune des paires.
La figure 10.3 présente les débits mesurés par le mobile 2 en fonction du temps. Comme chaque
phase de transmission se fait à une position donnée, puis que les mobiles sont déplacés durant les

117
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

25 secondes qui suivent, la légende 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
commençant par les plus simples :
– A 190 mètres : Les deux paires sont totalement indépendantes, aussi bien à 11 qu’à 2 Mbit/s.
Quelle que soit l’activité dans l’autre paire, le débit utile des flux unicast dépasse donc les
5 Mbit/s, ce qui est le maximum possible pour la taille de paquet utilisée. Il en est de même
avec le flux broadcast qui plafonne quant à lui aussi à son maximum, c’est à dire 1.6 Mbit/s
environ. Du fait de la distance, les paquets émis en mode diffusion par le mobile 3 ne sont
évidemment pas reçus du tout par le mobile 2.
– A courte distance (jusqu’à 58 mètres) : Les émetteurs doivent partager le canal. Plusieurs
situations se détachent :
– Deux flux broadcast simultanés (secondes 20 à 35 des cycles concernés) : ils obtiennent
chacun un peu plus de la moitié de ce qu’un aurait obtenu seul, soit environ 0.8 Mbit/s.
La raison pour laquelle il n’obtiennent pas juste la moitié est celle qui avait été donnée
lors de l’étude précédente de 1 à 7 flux simultanés : les backoff sont décrémentés en partie
simultanément et cela se traduit par un temps en moyenne inférieur entre deux paquets
consécutifs sur le canal.
– Deux flux unicast simultanés (secondes 60 à 75 des cycles concernés) : ils obtiennent
également chacun un peu plus de la moitié de ce qu’un aurait obtenu seul, soit pas loin de
3 Mbit/s.
– Un flux unicast et un flux broadcast simultanés (secondes 0-15 et 40-55) des cycles
concernés : ils se partagent le canal avec une probabilité d’accès égale. Cela se traduit
par un débit intermédiaire d’environ 1.3 Mbit/s pour chacun des flux. En effet, le flux à
2 Mbit/s envoie autant de paquets que celui à 11 Mbit/s. Ce dernier va donc se trouver
pénalisé par ce partage. Les deux flux vont obtenir le même débit alors que l’un d’eux est
sensé avoir un débit plus élevé. Ce phénomène a été relevé par [42].
– Entre 94 et 160 mètres : C’est dans cette région que les interférences se manifestent. On
remarque tout d’abord que l’on est désormais trop loin pour que le mobile 2 reçoive encore
correctement les paquets envoyés en mode diffusion par le mobile 3. A 94 mètres et un tout
petit peu à 120 mètres on reçoit néanmoins encore quelques uns de ces paquets, mais plus
aucun à 160 mètres. Puisque c’est à cette distance que les phénomè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 partagé. Le flux unicast n’obient en effet qu’environ
1.5 Mbit/s. Comme nous l’avons déjà dit, le flux broadcast n’est pas compris à cette distance
(et n’apparaı̂t pas sur la courbe, mais il est bel et bien détecté.)
– Lorsque le flux unicast local doit cohabiter avec le flux unicast distant (secondes 60 à 75
du cycle), il n’y a visiblement plus de partage du canal nécessaire, puisque le flux local est
au débit maximum.
– Le flux broadcast (secondes 20 à 55 du cycle) est lui aussi affecté par le flux broadcast
distant, mais dans une moindre mesure : on voit une instabilité assez nette tant que le
mobile distant émet à 2 Mbit/s, mais cette instabilité disparaı̂t lorsque le mobile distant
passe à 11 Mbit/s.
Dans [41], les auteurs présentent le problème de la zone grise. Ce problème apparaı̂t lorsque
les protocoles de routage utilisent des paquets diffusés à 2 Mbit/s pour construire les routes, et

118
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

      

           

      

1 −> 2 Unicast Broadcast Unicast


           

      

           

              
              

              

              

              

Broadcast Unicast
              

3 −> 4 











































0 15 20 35 40 55 60 75
time in seconds

Fig. 10.1 – Positions des deux paires Fig. 10.2 – Communications dans le schéma des paires
mobiles mobiles

6
unicast 1 -> 2
broadcast 1 -> 2
broadcast 3 -> 4

5
Throughput in Mb per second

0
very close 25.5m 58m 94.5m 119.75m 159.75m 189.75m
distance in meters

Fig. 10.3 – Paquets reçus par les 2 nœud récepteurs dans le scénario des deux paires mobiles

que les données sont ensuite envoyées à une vitesse supérieure (par exemple 11 Mbit/s). Comme
la portée diminue avec l’augmentation de la vitesse, il se peut que certaines routes soient valides à
2 Mbit/s mais ne soient pas utilisables à 11 Mbit/s. C’est la différence entre les zones de couverture
à différentes vitesses qui est appelée zone grise. Dans cette expérience des deux paires mobiles, nous
n’avons pas mesuré directement la zone grise. Nous avions bien un flux à 2 Mbit/s et une autre à
11 Mbit/s, mais ce dernier était en unicast et restait local dans chaque paire mobile, il ne pouvait
donc pas être compris par l’autre paire. Par contre, et en particulier à 160 mètres, l’extension du
problème de la zone grise à la zone de détection de porteuse est très visible. La portée de détection
de porteuse d’un flux à basse vitesse est nettement plus grande que celle d’un 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) n’obtiennent pas toute la bande passante : il y
a détection de la porteuse du flux à 2 Mbit/s dans l’autre paire et il y a donc partage du canal.
La portée de détection de porteuse du flux distant à 11 Mbit/s (secondes 40 à 75 du cycle) est elle
inférieure à 160 mètres. Les flux locaux à 2 et 11 Mbit/s ne détectent pas du tout son activité et
occupent la totalité de la bande passante.

119
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

10.2 Les trois paires


La configuration des trois paires que nous avons étudiée par simulation avait montré de graves
problèmes dans l’équité de l’accès au médium pour la paire centrale lorsqu’elle percevait en quasi
permanence le canal occupé par l’une ou l’autre des paires extérieures. A des fins de vérification,
nous avons donc cherché à reproduire cette configuration pour des mesures réelles. Pour des raisons
pratiques, nous avons travaillé en intérieur. En utilisant la topologie du bâtiment, il nous était en
effet plus facile de faire en sorte que les deux paires extérieures ne se gênent pas du tout entre
elles. Nous avons travaillé à 2 Mbit/s et sans RTS/CTS. Dans la configuration présentée sur la
figure 10.4, les paires extérieures pouvaient détecter la porteuse de la paire centrale (nous l’avons
vérifié en constatant un partage équitable du canal si l’on activait la paire centrale et seulement l’une
des paires extérieures à la fois), et les deux paires extérieures ne se gênaient pas (elles obtenaient
toutes les deux le débit maximum si elles étaient activées en même temps). Une fois toutes les
machines dans la position voulue, nous avons activé un flux dans chacune d’entre elles (comme à
l’accoutumée, afin de saturer le réseau, nous avons utilisé des flux de paquets UDP de 1000 octets
pour lesquels la file d’attente est toujours pleine).
Les débits mesurés sur chacune des paires sont présentés sur la figure 10.5. Il faut noter qu’à
partir de la seconde 925 environ, les émetteurs des paires centrale et gauche sont stoppés. On
observe très clairement les difficultés rencontrées par la paire centrale : son débit évolue entre 5 et
15% du débit des paires extérieures. On remarque également la présence d’une période (entre les
secondes 805 et 870 environ) où le débit sur la paire centrale est vraiment très faible (moins de 10
paquets par seconde, soit moins de 5% de la bande passante). Cette période correspond au moment
où le débit des paires extérieures est quasiment maximal. Le reste du temps, la paire de droite
semble partager la bande passante (d’une manière certes non-équitable) avec la paire centrale.
Après une étude détaillée et de nombreuses répétitions de l’expérience, nous avons déterminé que
ce partage venait en fait d’interférences au niveau de la paire de droite par une station de base
située à un autre étage du bâtiment (et sur laquelle nous n’avions pas de contrôle).

Cette expérience confirme donc de manière très nette les simulations. Dans certaines situations
où des mobiles sont gênés de façon asymétrique, certains mobiles utilisant 802.11 peuvent connaı̂tre
de grande difficultés pour accéder au canal. Comme nous l’avons déjà expliqué, ce problème ne
peut être réglé simplement, car ils est causé par la conjonction de l’activité de plusieurs mobiles
qui en empêchent ainsi d’autres d’accéder correctement au médium. Les mobiles qui émettent n’ont
d’ailleurs pas de moyen de savoir qu’ils gênent quelqu’un d’autre.

10.3 La chaı̂ne
10.3.1 Le scénario, les contraintes
La configuration que nous voulons tester est celle présentée sur la figure 10.6. L’environnement
de mesure est le boulevard précédemment décrit (chapitre 7). Nous utilisons cinq portables pour
réaliser la chaı̂ne, ainsi qu’un sixième qui joue le rôle de synchroniseur selon la méthode présentée
dans le chapitre précédent. Nous utilisons bien évidemment forwarding pour forcer la topologie
logique (le mobile 2 ré-émet tous les paquets qu’il reçoit de 1, le mobile 3 ré-émet tous ceux qu’il
reçoit de 2 et ainsi de suite). Afin de récolter un maximum de données, les transmissions se font en
mode diffusion, et donc à 2 Mbit/s. La diffusion permet de savoir, pour chaque paquet émis, à quels

120
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

Fig. 10.4 – Les disposition des mobiles pour l’expérience des trois paires

Fig. 10.5 – Les difficultés pour la paire centrale à accéder au canal

121
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

1 2 3 4 5

Fig. 10.6 – La chaı̂ne à 4 sauts et le synchronisateur

endroits il peut être reçu (en fonction des réceptions d’un même paquet, on reconstruit directement
la zone de communication du mobile qui a émit ce paquet).
Le premier problème rencontré réside dans la portée des émetteurs lorsqu’on les utilise à
2 Mbit/s. Dans le chapitre sur la portée, nous avons vu que le signal pouvait alors être reçu à
plus de 500 mètres. Mais le boulevard où nous effectuons les expérimentations ne mesure qu’un
kilomètre environ et nous n’avons pas à disposition un environnement homogène permettant di-
rectement l’expérience de la chaı̂ne (il nous faudrait une ligne droite d’au minimum deux ou trois
kilomètres). Nous avons avons donc décidé de réduire artificiellement la portée de nos émetteurs.
Pour cela nous utilisons du papier d’aluminium avec lequel nous entourons les antennes de nos
cartes (nos cartes Lucent ne permettaient pas de changer la puissance d’émission). Aussi empirique
et simpliste qu’elle puisse paraı̂tre, cette méthode est très efficace et permet de diviser la portée des
cartes par un facteur 5 à 10 suivant la quantité d’aluminium utilisé. Cette façon de procéder a un
intérêt majeur à nos yeux : elle nous permet d’effectuer la mesure de la chaı̂ne tout en la gardant à
une échelle significative du point de vue de l’environnement et des interférences. Il nous aurait été
possible d’utiliser des antennes externes modifiées pour avoir un gain très faible (techniquement,
en donnant une portée de l’ordre du mètre à nos carte il aurait été ainsi possible de réaliser l’en-
semble des mesures multi-sauts dans une seule pièce), mais un tel changement d’échelle du réseau
modifie profondément les effets de l’environnement sur l’expérience. Dans un réseau multi-sauts
à une échelle de quelques centaines de mètres, les conditions d’interférences de l’environnement
peuvent être très différentes d’un endroit à l’autre du réseau (passage d’une voiture, proximité d’un
équipement perturbateur, bâtiment qui réfléchit les ondes de certains émetteurs, portes fermées
ou ouvertes en intérieur, présence ou simplement passage de piétons, etc.). Un réseau miniature
(tenant dans une pièce) ne serait pas soumis aux mêmes phénomènes (la plupart des éléments
perturbateurs décrits précédemment affecteraient l’ensemble du réseau de manière uniforme).

10.3.2 Le déploiement et le déroulement de l’expérience


Afin de mieux rentabiliser notre temps (et la durée des batteries), l’expérience est conçue de
manière à mesurer en une seule fois les comportements sur des chaı̂nes à 1, 2, 3 et 4 sauts. Dans
un réseau ad hoc, une configuration de chaı̂ne apparaı̂t lorsque l’émetteur d’un paquet est trop
loin du destinataire et que des mobiles intermédiaires doivent relayer les données de proche en
proche. Les mobiles intermédiaires sont choisis par le protocole de routage et en général ils vont
l’être de manière à minimiser le nombre de sauts. Cela signifie que chaque mobile de la chaı̂ne
peut communiquer avec ses voisins directs, mais pas avec ses voisins à deux sauts. Forwarding nous
permet, en forçant le choix des routes, d’éviter toute instabilité dans leur choix qui pourrait être
liée au protocole de routage. Mais en contrepartie il faut nous assurer nous-même du placement des
mobiles. La chaı̂ne de notre expérience est donc construite progressivement. Le mobile 1 est placé

122
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

à une extrémité du boulevard et configuré pour émettre 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
l’éloigne jusqu’à ce que le débit qu’il en reçoit commence à baisser. En quelques minutes on arrive,
grâce à l’affichage du débit en temps réel et par des déplacements successifs, à la placer à la limite
de la zone dans laquelle la plupart des paquets émis par le mobile 1 sont reçus. On configure alors
le mobile 2 pour émettre lui aussi (à cette étape, on ne stoppe pas encore l’émission du mobile 1).
On peut alors placer le mobile 3 en fonction des flux venant de 1 et de 2. Quelques minutes sont
également nécessaires pour trouver une position dans laquelle on reçoit bien le mobile 2, mais pas
ou très peu le mobile 1. On peut alors démarrer l’émission sur le mobile 3 et stopper celle sur le
mobile 1 (pour économiser l’énergie) ; on place alors le mobile 4 ... et ainsi de suite.
Finalement, on arrive donc à placer les 5 mobiles de la chaı̂ne dans la configuration désirée. On
stoppe alors les flux restants et on effectue un passage de synchronisation avec le sixième mobile.

10.3.3 Les résultats


Nous avons réalisé deux fois cette expérience. Il aurait été préférable de la réaliser plus de fois
encore, mais la lourdeur de ce genre d’expérimentation est telle que cela n’a pas été possible.

Première mesure
Lors de la première mesure, une fois les mobiles placés comme décrit précédemment et la phase
de synchronisation initiale effectuée, nous démarrons le flux de données sur la chaı̂ne. Au départ,
il n’y a pas de répétition des paquets (un seul saut), et au fur et à mesure on allonge la chaı̂ne en
activant la répétition sur chacun des mobiles. Les paquets UDP font 1000 octets, ils sont envoyés
en mode diffusion, à 2 Mbit/s. Les débits mesurés sont présentés sur les figures 10.7 à 10.11. La
chronologie de l’activation des ré-émissions et l’interprétation des résultats est la suivante :
– 270 à 380 : Aucune répétition, seul le flux entre 1 et 2 existe, il obtient la totalité de la bande
passante, soit environ 1.6 Mbit/s de débit utile (figures 10.7 et 10.8) et est assez stable. On
remarque sur la figure 10.9 que certains paquets émis par 1 sont reçus en 3 (secondes 300 à 340
environ) mais qu’ils ne sont pas très nombreux. Ces paquets sont très intéressants et montrent
bien un problème spécifique aux réseaux ad hoc : la propension à subir des interférences par
rafales. Ces paquets reçus en 3 à partir de 1 auraient pu conduire un protocole de routage
à établir une route directe. Mais la durée de vie de cette route aurait été courte (30 à 40
secondes), et surtout aurait subit un taux de perte particulièrement élevée (90 à 95% environ).
– 380 à 540 : Le mobile 2 répète les paquets qu’il reçoit de 1 (la chaı̂ne passe à 2 sauts). Les flux
(1→2) et (2→3) doivent donc se partager le canal. Ce partage s’effectue assez bien au début
(partie de 380 à 490), comme l’atteste la figure 10.7. Pour cette partie tout d’abord, comme
le laissait présager l’expérience précédente des 2 à 7 flux en concurrence dans la même pièce,
on y voit que le débit agrégé de deux flux est dans ces conditions égal voire un peu supérieur
à un seul flux qui aurait toute la bande passante. On remarque cependant, toujours sur la
figure 10.7, qu’il y a quelques pertes : le débit du flux (2→3) est légèrement inférieur à celui
du flux (1→2) alors qu’idéalement ils devraient être identiques. Si l’on compare le flux venant
de 2 reçu en 2 et en 3 sur les figures 10.8 et 10.9, on constate que (2→2) est strictement égal
à (1→2) (les courbes sont superposées) et supérieur à (2→3). Ceci est tout à fait normal. En
fait, 2 reçoit lui-même les paquets qu’il diffuse quoiqu’il arrive sur le canal (les paquets sont
envoyés par forwarding à la couche IP, qui les envoie d’une part à la couche MAC, mais aussi

123
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

directement à forwarding puisqu’il s’agit d’une diffusion). On remarque enfin sur la figure 10.9
la présence de quelques paquets venant directement de 1 (secondes 380 à 400), alors que les
mobiles 4 et 5 n’ont jusqu’à présent perçu aucun paquet.
Les choses se gâtent cependant entre les secondes 490 et 540, où le flux (2→3) est brusquement
fortement affecté par des interférences externes : son débit devient très instable. Pour cette
partie, on voit que le débit reçu 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 (2→2) sur la figure 10.8). De ces deux
choses, on déduit donc que les paquets sont bien émis par 2 mais qu’ils ne sont pas reçus par 3
(s’ils n’étaient pas ré-émis par 2, le débit de (1→2) augmenterait avec la bande passante ainsi
libérée). Ceci souligne une fois de plus la tendance de certaines des interférences extérieures
à se produire par rafale.
– 540 à 700 : Le mobile 3 se met à répéter les paquets qu’il reçoit de 2 (et uniquement ceux-
là) ; la chaı̂ne passe ainsi à 3 sauts. On voit que de saut en saut, des paquets sont perdus
(figures 10.7 à 10.10), et que le débit effectif arrivant en 4 est faible (figure 10.10 : en moyenne
de 200 kbit/s alors qu’il devrait idéalement dépasser les 500 kbit/s) et extrêmement instable
(parfois quasiment nul pendant 5 à 10 secondes). On remarque, comme dans les simulations,
que le mobile qui génère les paquets (le mobile 1) occupe plus la bande passante qu’il ne le
devrait pour un accès équitable au médium. Lorsque des paquets sont perdus plus loin sur la
chaı̂ne, les mobiles qui auraient dû les ré-émettre peuvent se trouver dans une situation de
’famine’, et le mobile 1 qui lui a toujours sa file d’émission pleine en profite.
– 700 à 830 : Le mobile 4 se met à répéter les paquets qu’il reçoit de 3 ; la chaı̂ne passe à
4 sauts. Les observations sont semblables à celles de la chaı̂ne à 3 sauts : des paquets sont
perdus à chaque étape et le débit de bout en bout est à la fois faible est très instable. Entre
les secondes 780 et 800 environ, plus aucun trafic n’est même reçu en 4 (figure 10.11). On
remarque également (figure 10.8) que le flux (1→2) maintient le même débit que lorsqu’il y
avait un saut de moins ; il s’accapare une part de la bande passante de plus en plus importante
par rapport à ce qu’elle devrait être idéalement.
Une fois cette expérience de la chaı̂ne à 4 sauts réalisée, comme il nous restait suffisamment de
charge sur nos batteries, nous avons décidé de reproduire la même expérience, mais en unicast. La
vitesse de transmission reste de 2 Mbit/s (la changer aurait signifié la nécessité de replacer tous les
mobiles en conséquence, et nos batteries n’auraient pas tenu aussi longtemps). Passer en unicast
présente l’intérêt d’activer le mécanisme des acquittements (et donc de la détection des collisions ou
erreurs de transmission, avec la ré-émission qui s’en suit), mais a le désavantage de nous empêcher
de détecter les paquets qui ne nous sont pas explicitement envoyés. Les débits présentés sur les
figures 10.12 à 10.16 sont donc moins riches que celles de la phase en diffusion (pour des raisons
de facilité de lecture, les figures 10.13 à 10.16 reprennent chacune une courbe de la figure 10.12 de
façon séparée).
La chronologie de l’activation des ré-émission et leur interprétation est la suivante :
– 1140 à 1205 : Il n’y a pas de ré-émission, seul le flux (1→2) existe. Il utilise toute la bande
passante et le débit effectif dépasse les 1.5 Mbit/s (figures 10.12 et 10.13). Il est évidemment
inférieur au débit lors de la phase équivalente en diffusion, puisqu’il faut maintenant prendre
en compte les acquittements. La stabilité de l’unique flux est comparable celles de la phase
en diffusion, c’est-à-dire assez grande.
– 1205 à 1415 : Le mobile 2 se met à ré-émettre les paquets qu’il reçoit de 1 ; la chaı̂ne passe
à 2 sauts. Le canal est partagé équitablement (figure 10.12) et le débit de bout en bout est

124
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

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
debit en bits par seconde

1e+06

500000

0
300 400 500 600 700 800
temps en secondes

Fig. 10.7 – Débit de proche en proche sur la chaı̂ne (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
debit en bits par seconde

1e+06

500000

0
300 400 500 600 700 800
temps en secondes

Fig. 10.8 – Occupation du canal perçue par le nœud 2 (mesure 1, broadcast)

125
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

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
debit en bits par seconde

1e+06

500000

0
300 400 500 600 700 800
temps en secondes

Fig. 10.9 – Occupation du canal perçue par le nœud 3 (mesure 1, broadcast)

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
debit en bits par seconde

1e+06

500000

0
300 400 500 600 700 800
temps en secondes

Fig. 10.10 – Occupation du canal perçue par le nœud 4 (mesure 1, broadcast)

126
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

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
debit en bits par seconde

1e+06

500000

0
300 400 500 600 700 800
temps en secondes

Fig. 10.11 – Occupation du canal perçue par le nœud 5 (mesure 1, broadcast)

optimal ou presque, sauf entre les secondes 1240-1260 et 1380-1415 environ.


Entre 1240 et 1260, le mobile 2 ne ré-émet plus les paquets. Cela se voit à l’absence de
réception par 3 dans cette période (figure 10.14) et au débit du flux (1→2) qui augmente
subitement pour utiliser toute la bande passante disponible (figure 10.13).
Entre 1380 et 1415, les choses sont un peu plus mitigées, le débit de (1→2) augmente alors
que celui de (2→3) diminue, mais (2→3) 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 durée assez
longue (une vingtaine de secondes environ).
– 1415 à 1540 : Le mobile 3 se met à ré-émettre les paquets qu’il reçoit de 2 ; la chaı̂ne passe à
3 sauts. Le partage du canal est très équitable (figure 10.12) entre les flux (1→2) et (2→3). Il
l’est un peu moins avec (3→4) qui voit parfois son débit chuter de manière très importante.
Toujours sur la figure 10.12, la courbe de débit agrégé nous montre encore une fois assez bien
la tendance des interférences à se manisfester par rafales (chutes très importantes du débit
dans le réseau pour des durées de 5 à 20 secondes en général).
– 1540 à 1720 : On passe à 4 sauts. Le comportement est encore une fois très semblable à
celui de la chaı̂ne à 3 sauts mesuré juste avant. Les débits de (1→2) et (2→3) sont en général
très proches (figure 10.12), de même pour (3→4) et (4→5). La plupart des pertes se trouvent
au moment du passage de 3 à 4. Le débit de bout en bout obtenu dans la réalité sur la chaı̂ne
à quatre sauts est différent de celui obtenu par simulation (figure 10.17) D’une part il est
beaucoup plus instable. D’autre part il se situe en général autours de 250 kbit/s alors que les
simulations l’estimaient à 400 kbit/s. Dans la réalité, il n’a atteint qu’une fois la valeur de
400 kbit/s, et pour une durée assez courte (une dizaine de secondes environ).

127
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

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
debit en bits par seconde

1e+06

500000

0
1100 1200 1300 1400 1500 1600 1700
temps en secondes

Fig. 10.12 – Débit de proche en proche sur la chaı̂ne (mesure 1, unicast)

2e+06
de 1 recu en 2

1.5e+06
debit en bits par seconde

1e+06

500000

0
1100 1200 1300 1400 1500 1600 1700
temps en secondes

Fig. 10.13 – Occupation du canal perçue par le nœud 2 (mesure 1, unicast)

128
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

2e+06
de 2 recu en 3

1.5e+06
debit en bits par seconde

1e+06

500000

0
1100 1200 1300 1400 1500 1600 1700
temps en secondes

Fig. 10.14 – Occupation du canal perçue par le nœud 3 (mesure 1, unicast)

2e+06
de 3 recu en 4

1.5e+06
debit en bits par seconde

1e+06

500000

0
1100 1200 1300 1400 1500 1600 1700
temps en secondes

Fig. 10.15 – Occupation du canal perçue par le nœud 4 (mesure 1, unicast)

129
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

2e+06
de 4 recu en 5

1.5e+06
debit en bits par seconde

1e+06

500000

0
1100 1200 1300 1400 1500 1600 1700
temps en secondes

Fig. 10.16 – Occupation du canal perçue par le nœud 5 (mesure 1, unicast)

1.8e+06

1.6e+06

1.4e+06

1.2e+06
debit en bits par seconde

1e+06

800000

600000

400000

200000

0
0 10 20 30 40 50 60
temps en secondes

Fig. 10.17 – Débit de bout en bout simulé dans une chaı̂ne de quatre sauts (modèle two-ray ground)

130
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

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

debit en bits par seconde


1e+06

500000

0
1850 1900 1950 2000 2050 2100 2150 2200 2250
temps en secondes

Fig. 10.18 – Débit de proche en proche sur la chaı̂ne (mesure 2, broadcast)

Deuxième mesure
Nous avons cherché à reproduire l’expérience décrite précédemment. Le protocole expérimental
était identique (configuration et placement des machines), à l’exception de la chronologie de l’acti-
vation des ré-émissions. Cette fois-ci, la chaı̂ne commence entièrement formée (4 sauts), et au fur et
à mesure de l’expérience on stoppe des ré-émissions de façon à la raccourcir. A noter que dans cette
expérience, les batteries du mobile 1 se sont épuisées à la seconde 2240 environ et que la chaı̂ne
était alors constituée de 2 sauts (il n’y a pas de mesures à un seul saut dans cette expérience donc).
Les résultats sont présentés sur les figures 10.18 à 10.22 et la chronologie des désactivation des
retransmissions est la suivante :
– 1810 à 2050 : Les mobiles 2 à 4 ré-émettent les paquets qu’ils reçoivent de leur prédécesseur
direct, la chaı̂ne est composée de 4 sauts. Sur la figure 10.18, on voit que les débits des flux
(1→2) et (2→3) sont en général très proches l’un de l’autre, de même que (3→4) et (4→5),
mais que beaucoup de paquets ré-émis par 3 sont perdus à certains moments (différence très
visible entre (2→3) et (3→4) entre les secondes 1875-1895 et 2010-2050). Dans ces moments
où les mobiles 4 et 5 ne reçoivent que peu de paquets, on remarque que le débit sur (1→2)
et (2→3) n’augmente 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 reçus).
– 2050 à 2190 : Le mobile 4 a cessé de ré-émettre, la chaı̂ne n’est plus constituée que de 3
sauts. La encore, on constate (figure 10.18) que beaucoup de paquets sont émis par 3 mais
pas reçus par 4. On remarque bien aussi les périodes de 10 à 20 secondes pendant lesquelles
les interférences externes causent ces pertes en série.
– 2190 à 2240 : seul le mobile 2 ré-émet, la chaı̂ne ne fait plus que 2 sauts. Le partage du canal
est très équitable. On remarque très bien néanmoins une période où l’ensemble des mobiles
encore actifs sont affectés par des interférences (’trou’ dans le débit des flux (1→2) et (2→3)
au alentours des secondes 2230-2240).
La figure 10.23 présente un chronogramme du début de cette mesure obtenu avec la méthode
exposée précédemment. Nous rappelons que dans les chonogrammes construits comme celui ci à
partir de mesures réelles, ce sont les réceptions de paquet qui sont représentées ; chaque rectangle
correspond à un paquet reçu et compris, et sa couleur indique par quel mobile il a été émit. Au

131
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

2e+06 2e+06
de 1 recu en 2 de 1 recu en 3
de 2 recu en 2 de 2 recu en 3
de 3 recu en 2 de 3 recu en 3
de 4 recu en 2 de 4 recu en 3
debit aggrege debit aggrege

1.5e+06 1.5e+06
debit en bits par seconde

debit en bits par seconde


1e+06 1e+06

500000 500000

0 0
1850 1900 1950 2000 2050 2100 2150 2200 2250 1850 1900 1950 2000 2050 2100 2150 2200 2250
temps en secondes temps en secondes

Fig. 10.19 – Occupation du canal perçue par le Fig. 10.20 – Occupation du canal perçue par le
nœud 2 nœud 3
2e+06 2e+06
de 1 recu en 4 de 1 recu en 5
de 2 recu en 4 de 2 recu en 5
de 3 recu en 4 de 3 recu en 5
de 4 recu en 4 de 4 recu en 5
debit aggrege debit aggrege

1.5e+06 1.5e+06
debit en bits par seconde

debit en bits par seconde

1e+06 1e+06

500000 500000

0 0
1850 1900 1950 2000 2050 2100 2150 2200 2250 1850 1900 1950 2000 2050 2100 2150 2200 2250
temps en secondes temps en secondes

Fig. 10.21 – Occupation du canal perçue par le Fig. 10.22 – Occupation du canal perçue par le
nœud 4 nœud 5

132
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”

Fig. 10.23 – Chronogramme dans la chaı̂ne à 4 sauts (mesure 2, broadcast)

début du chronogramme, le mobile 2 reçoit 3 paquets consécutifs du mobile 1 (a), puis en ré-émet
un (b). Un peu plus tard, le mobile 3 ré-émet ce paquet (c). On remarque que les émissions des
mobiles 1, 2 et 3 n’ont jamais lieu en même temps : ils se partagent le canal. Mais lorsque le mobile
4 ré-émet un paquet (d), le mobile 1 peut émettre lui aussi : il y a réutilisation spatiale. On peut
voir également la perte de certains paquets : en (e), le mobile 3 émet un paquet qui n’est reçu qu’en
2, alors qu’il devrait aussi l’être en 4. En (f) enfin, on remarque la réception simultanée d’un paquet
émit par 2 en 3, et d’un paquet émit par 4 en 5. On savait depuis (d) que 3 était bien à portée de
4. Alors que ses deux voisins directs ont émit en même temps, le mobile 3 a donc été (cette fois-ci
tout du moins) en mesure de recevoir correctement un des deux messages.

Résumé et interprétation des résultats de l’expérience de la chaı̂ne


D’un manière générale, nous avons vu au travers des expériences que même dans des conditions
favorables (routage statique, flux UDP), le débit obtenu d’un bout à l’autre d’une chaı̂ne d’une
longueur pourtant raisonnable (4 sauts au plus) est assez problématique. L’analyse détaillée des
événements nous a permis de constater le rôle important des interférences liées à l’environnement.
Plutôt que de s’étaler d’une 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 périodes de
durées très variables (parfois quelques paquets consécutifs, parfois plus de communications pendant
30 secondes sur le lien). Lorsque les communications sont temporairement rompues sur un segment
de la chaı̂ne, les segments suivants se retrouvent rapidement en situation de ’famine’ : ils n’ont
plus de données à envoyer. Plus la chaı̂ne est longue, plus les chances qu’un segment soit rompu ou
gravement ’bruité’ à un instant donné sont grandes. C’est probablement ici que se situe le principal
enseignement que l’on peut retirer de cette série d’expériences : du fait des erreurs qui se produisent
souvent par rafales longues (plusieurs dizaines de secondes), les simulations sur-estiment en général
nettement les performances des configurations en chaı̂ne.

133
CHAPITRE
Mise en pratique du malus
1

11
Au cours de nos simulations, puis plus tard avec des mesures en environnement réel, nous
avons soulevé le problème de l’équité de l’accès au canal radio dans certaines configurations où les
interférences se faisaient de façon asymétrique. Les mobiles les plus gênés ne pouvaient pratiquement
jamais envoyer de paquets, car ils détectaient toujours le canal occupé. Nous avons analysé le
phénomène et montré qu’il était possible de l’atténuer avec un mécanisme de pénalités appliquées
aux mobiles qui émettaient trop de paquets par secondes. Afin de confirmer nos dires, nous avons
décidé d’implémenter ce mécanisme sur nos mobiles et de le tester.

11.1 Choix de l’implémentation


Le mécanisme du malus est très simple en lui-même. Le temps est découpé en cycles courts (une
seconde) et pour chaque paquet envoyé, une pénalité au backoff doit être ajoutée en fonction du
nombre de paquets que le mobile a déjà envoyé au cours du cycle. La pénalité est bien sûr remise
à zéro au début de chaque nouveau cycle.
La principale difficulté dans l’implémentation de cette méthode est que contrairement à ce que
nous avons pu faire sous simulateur, il ne nous est en fait pas possible de modifier le mécanisme de
backoff. Toute la couche MAC est codée dans une mémoire directement soudée sur la carte réseau
radio, et nous n’avons pas été en mesure d’en obtenir les codes sources.
Il nous a fallu trouver une solution de remplacement donnant des résultats comparables, au
moins dans le contexte de l’expérience 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 réseau. L’idée était de détourner les paquets juste avant qu’ils
ne soient envoyés à la carte réseau, de les faire attendre à notre convenance dans une file d’attente,
puis de les remettre dans le flux normal pour qu’ils soient émis dans les airs.
De cette manière, même sans contrôler directement le backoff, il est possible de réduire progres-
sivement le débit des mobiles qui cherchent à émettre trop vite.
Concrètement, l’implémentation de cet algorithme s’est faite avec un filtre de paquets. Un filtre
de paquets est un programme qui analyse les en-têtes des paquets au fur et à mesure qu’ils passent
et décide du devenir de l’ensemble du paquet en fonction de ce qu’il y trouve. Il peut décider de
détruire le paquet (DROP) et il disparaı̂t alors comme s’il n’avait jamais été reçu ; il peut aussi
l’accepter (ACCEPT) et le paquet continue son chemin ; mais il peut également en faire quelque
chose de plus compliqué. Sous linux, le filtrage se fait dans le noyau (le code peut être directement
intégré dans le noyau ou chargé sous forme de module), et il peut réaliser des fonctions diverses,
même si le principe expliqué précédemment reste valide.

134
CHAPITRE 11. MISE EN PRATIQUE DU MALUS

Réception
des paquets Emission
Décision de des paquets
routage FORWARD

INPUT OUTPUT

Processus local

Fig. 11.1 – Iptables et les différents points d’accroche

Le filtrage de paquet est en général utilisé pour les fonctions suivantes :


– Le contrôle : Il est possible d’autoriser certains types de trafic venant de certains sites et d’en
interdire d’autres (par exemple je ne veux pas que mon ordinateur envoie des requêtes HTTP
vers les adresses de doubleclick.net).
– La sécurité : Sur une passerelle, surtout si l’on n’est pas sûr de la configuration des machines
qui sont derrière, il peut être intéressant d’interdire complètement certains trafics venant de
l’Internet. Il est rassurant par exemple de savoir que quelle que soit la configuration de mes
machines sous windows, les requêtes d’accès à leurs fichiers seront bloquées au niveau de la
passerelle.
– Le monitoring : Si jamais des trafics suspects sont détectés, il est bon que l’information soit
remontée à l’administrateur.
Nous détournons 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 d’abord savoir comment
le filtrage de paquet fonctionne.

Le mécanisme de filtrage de paquet des noyaux 2.4 de Linux s’appelle Iptables [76]. Un certain
nombre de listes de règles appelées ”chaı̂nes” sont implémentées par défaut (INPUT, OUTPUT et
FORWARD), comme présentées sur la figure 11.1. Quand un paquet atteint une chaı̂ne, elle est
examinée pour décider du sort du paquet. Si la chaı̂ne dit DROP, alors il est détruit, et si elle dit
ACCEPT, alors il continue son chemin dans le diagramme. Chaque chaı̂ne est une liste de règles,
et si l’en-tête d’un paquet ne correspond pas à une règle, alors la règle suivante est examinée, et
ainsi de suite. Si aucune règle ne s’est avérée convenir au paquet, alors la règle par défaut de la
chaı̂ne est appliquée (par défaut configurée à ACCEPT).
Le fonctionnement des trois chaı̂nes est le suivant :
1. Quand un paquet arrive de l’interface réseau, le noyau regarde quelle est sa destination et
décide où il est envoyé (routage).
2. Si le paquet est destiné à la machine locale, alors il passe dans la chaı̂ne INPUT, et s’il est
accepté par celle-ci, alors il sera reçu par tout processus qui l’attend.
3. Si le routage est activé et si le paquet est destiné à une autre interface réseau, alors il passe
dans la chaı̂ne FORWARD et est envoyé si cette dernière l’accepte.
4. Finalement, lorsqu’un processus local veut envoyer un paquet sur le réseau, il doit d’abord
être accepté par la chaı̂ne OUTPUT avant d’aller vers l’interface à laquelle il est destiné
(notez que l’on parle bien ici d’interface physique d’entrée / sortie).

135
CHAPITRE 11. MISE EN PRATIQUE DU MALUS

Espace utilisateur

Application file d'attente delay

ip_queue

Noyau
Carte réseau
sans fil

Fig. 11.2 – Le programme delay et la file d’attente.

Les règles dans les chaı̂nes et les chaı̂nes elles-mêmes peuvent être ajoutées ou supprimées
en ligne de commande, grâce à l’utilitaire iptable. Cet utilitaire nous permet en particulier de
spécifier l’action à effectuer (c’est-à-dire la cible, ou encore TARGET) lorsqu’une règle s’applique à
un paquet. Les cibles les plus utilisées sont DROP et ACCEPT, mais nous allons plutôt nous servir
de QUEUE, qui permet, grâce au module ip queue, d’envoyer les paquets dans une file d’attente
spéciale dans l’espace utilisateur. Là, un programme spécialement écrit (delay) pourra aller les
chercher, et les renvoyer au noyau et à l’interface physique après les avoir éventuellement retenus
quelques temps (figure 11.2). Le programme delay retarde bien évidemment les paquets en suivant
l’algorithme du malus. Notons que pour obtenir une précision suffisante, nous avons dû utiliser
l’appel système nanosleep, et que de ce fait certaines précautions doivent être prises quant aux
autres processus fonctionnant au même instant sur les ordinateurs mobiles (pour que nanosleep
donne la meilleure précision, les règles d’ordonnancement des processus doivent être quelque peu
changées).
Il faut noter également que le mécanisme du malus doit être adapté pour pouvoir donner les
résultats attendus. En effet, comme on peut le voir sur la figure 11.3 dans la partie de gauche, si l’on
ajoute le malus à un niveau intermédiaire entre l’application (ici la source CBR) et la couche MAC,
alors le malus aura un effet moindre (voir nul) par rapport à s’il avait été appliqué directement
dans la couche MAC. Si le malus est appliqué dans netfilter, alors il peut y avoir un recouvrement
entre son temps de pause et l’envoi d’autres paquets par la couche MAC. L’objectif du système
de malus est d’augmenter le temps entre deux paquets consécutifs envoyés par un même mobile
sur le canal, et l’on voit ici qu’il n’y arrive pas lorsque le malus est petit. Si le malus pouvait être
appliqué directement dans la couche MAC, un tel recouvrement ne serait pas possible. Pour être
appliqué en dehors de la couche MAC, il faut donc que le malus tienne compte de la durée de
transmission du paquet (comme présenté sur la partie de droite de la figure 11.3). Pour cela, il
a besoin essentiellement de connaı̂tre la taille du paquet ainsi que la vitesse à laquelle il va être
envoyé. De cette façon, il est alors possible d’imposer le temps inter-trame désiré. Notons que sur
la figure, pour des raisons de lisibilité, le backoff aléatoire de la couche MAC n’est pas représenté
mais que le résultat final est le même.

11.2 Résultats
Nous avons réalisé à nouveau l’expérience des trois paires, de la manière déjà décrite (figure 11.5).
Les résultats sont présentés sur les figures 11.6 à 11.9 (pour des raisons de lisibilité, les figures 11.7
à 11.9 reprennent chacune une courbe de la figure 11.6). La pénalité appliquée est celle que nous

136
CHAPITRE 11. MISE EN PRATIQUE DU MALUS

ames ames ames ames


inter-tr inter-tr inter-tr inter-tr
temps temps temps temps
court court court court

1 2 3 4 5 6
CBR

malus malus malus malus


Netfilter
recouvrement entre le malus
et l'émission physique

1 2 3 4 5 6
MAC

temps inter-trames court malgré le malus Temps inter-trame de la longueur voulue

Fig. 11.3 – Adapter le malus pour qu’il puisse être appliqué ailleurs que dans la couche MAC

250
malus

200
Malus (en nombre de time slots)

150

100

50

0
0 5 10 15 20 25 30
paquets envoyes depuis le debut du cycle

Fig. 11.4 – La pénalité ”effective” appliqué en fonction du nombre de paquets envoyés

avions déjà utilisée lors des simulations (figure 11.4), corrigée à la volée de la manière décrite dans
la section précédente afin de prendre en compte la différence dans la manière de l’appliquer.
L’expérience s’est déroulée en plusieurs étapes, qui peuvent être décrites et analysées comme
suit :
– Secondes 100 à 900 : seules les deux paires extérieures sont actives et le malus n’est
pas encore utilisé. On remarque une certaine instabilité dans les débits. Le débit maximum
théorique est de 190 paquets de 1000 octets par seconde pour un émetteur seul et si aucune
contention ou collision n’a lieu. Jusqu’à la seconde 800 environ, la paire de gauche subit des
interférences assez visibles (qui affectent même la paire de droite vers la seconde 550). Ces
interférences sont en fait dues à une station de base située à une autre étage du bâtiment.
Nous avons simplement attendu que ces interférences cessent pour réaliser les mesures qui
nous intéressaient (les interférences cessent vers la seconde 800, il était alors midi et les
utilisateurs du réseau ont quitté les bureaux).
– Secondes 900 à 1350 : la troisième paire est activée. On se retrouve dans les mêmes condi-
tions que l’expérience précédente avec les trois paires (chapitre 10. La paire centrale n’accède
que très peu au canal radio (elle n’arrive à envoyer qu’entre 5 et 15 paquets par seconde

137
CHAPITRE 11. MISE EN PRATIQUE DU MALUS

Fig. 11.5 – Les disposition des mobiles pour l’expérience des trois paires

contre 180-190 pour chacune des paires extérieures). Cette étape est réalisée simplement à
des fins de confirmation du problème.
– Secondes 1350 à 1400 : la paire de droite est stoppée. L’objectif était de vérifier que
conformément aux prévisions, les deux paires restantes (gauche et centrale) se partageraient
le canal. On voit que c’est effectivement le cas, chacune obtenant environ 95-100 paquets par
seconde.
– Secondes 1400 à 1700 : on réactive la paire de doite, et on revient dans la même situation
problématique de la période 900-1350.
– Secondes 1700 à 2100 : on active le mécanisme du malus. La pair centrale voit alors ses
chances d’accès au canal augmenter de manière significative (son débit évolue désormais entre
60 et 70 paquets par seconde environ). Le débit des deux paires extérieures quand à lui est
logiquement réduit (il plafonne alors à environ 105-110 paquets par seconde). Notons que ces
résultats sont très proches de ceux prévus par la simulation.
– Secondes 2100 à 2300 : la paire centrale est stoppée, mais les paires extérieures continue
d’utiliser le malus. Leur débit continue de plafonner à environ 100 paquets par seconde. Ceci
avait également été prévu par le calcul et les simulations, c’est l’effet négatif du mécanisme du
malus dans les conditions où il est le plus visible. Les deux paires extérieures ne se gênent en
effet pas du tout, et le temps inter-trames supplémentaire imposé par la malus est ici inutile
et dommageable pour le débit. Notons bien cependant que c’est ici le pire cas, et que comme
nous l’avons vu, cet effet décroı̂t très rapidement avec l’augmentation du nombre de mobile
en contention.
Dans cette expérience, nous avons pu vérifier que le mécanisme du malus offrait bien les résultats
escomptés et que la paire centrale pouvait accéder au canal dans une proportion beaucoup plus
exploitable qu’avant. Le désavantage principal du mécanisme a également été souligné : diminu-
tion nette du débit maximum possible lorsqu’il n’y pas de contention. Nous rappelons que deux
autres désavantages existent : la tendance à transmettre par rafale ainsi qu’un retard (assez court
cependant), à l’envoi effectif des paquets.
Il est important de garder à l’esprit que dans une situation comme celle de cette expérience,
du fait de l’impossibilité d’établir 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 caractéristique en trois étapes) présente cependant assez peu de désavantages, pour
peu qu’il y ait plusieurs mobiles en contention.

138
CHAPITRE 11. MISE EN PRATIQUE DU MALUS

200
gauche
centrale
droite

150
paquets par seconde

100

50

0
0 500 1000 1500 2000 2500
temps en secondes

Fig. 11.6 – Expérience des trois paires avec le malus

200
gauche

150
paquets par seconde

100

50

0
0 500 1000 1500 2000 2500
temps en secondes

Fig. 11.7 – Expérience des trois paires avec le malus (paire de gauche)

139
CHAPITRE 11. MISE EN PRATIQUE DU MALUS

200
centrale

150
paquets par seconde

100

50

0
0 500 1000 1500 2000 2500
temps en secondes

Fig. 11.8 – Expérience des trois paires avec le malus (paire centrale)

200
droite

150
paquets par seconde

100

50

0
0 500 1000 1500 2000 2500
temps en secondes

Fig. 11.9 – Expérience des trois paires avec le malus (paire de droite)

140
Conclusions

Dans cette thèse, nous nous sommes intéressés au comportement de la norme IEEE 802.11
lorsqu’elle est utilisée pour réaliser des réseaux ad hoc. D’une manière générale, notre travail peut
être résumé en deux étapes principales : la mise en lumière de problèmes et l’analyse de leurs
impacts d’une part, ainsi que l’apport de solutions d’autre part.

La mise en lumière des problèmes et leurs impacts


Pour des raisons pratiques et historiques, nos travaux ont débuté par un grand nombre de
simulations. Les scénarios qui nous intéressaient étaient très caractéristiques des réseaux ad hoc
de par leur topologie (chaı̂nes de mobiles, paires mobiles, etc.) mais aussi par les trafics mis en
œuvre (des flux importants, à même de charger ponctuellement ou durablement le réseau comme le
feraient des applications réelles telles que la navigation sur le web, le transfert de fichiers ou même
la consultation de messageries).
Néanmoins, les simulateurs disponibles présentent un certain nombre de limitations. De plus,
très peu d’expériences ont été réalisées pour mesurer les impacts réels de 802.11 dans les réseaux
ad hoc. Nous sommes donc passés à une phase de vérification de mesures réelles. A cette fin nous
avons développé un outil appelé forwarding spécialement conçu pour permettre le déploiement et
l’évaluation de configurations typiquement ad hoc. Afin de nous permettre de nous concentrer
sur le comportement de 802.11, forwarding nous affranchit des couches supérieures. Pour cela, il
autorise le routage statique et met en œuvre des flux UDP, nous permettant ainsi de contrôler de
façon très précise l’émission et le cheminement de chaque paquet. En utilisant cet outil, nous avons
tout d’abord réalisé des expériences simples, puis nous avons mis en place des expériences plus
complexes. Ces dernières ont nécessité l’étude et le développement de mécanismes nous permettant
d’obtenir des traces parfaitement synchronisées à partir de nos différentes machines. Compte tenu
de la précision dont nous avions besoin, la dérive des horloges des ordinateurs est en effet telle que
nous ne pouvions l’ignorer. Des contraintes supplémentaires liées notamment au partitionnement
possible du réseau étaient également à prendre en compte. La méthode que nous avons proposée
remplit cependant parfaitement nos attentes.
Un certain nombre de caractéristiques de 802.11 ont peu être mises en évidence dans cette thèse.
Les principales sont les suivantes :

L’impact du WEP La cryptographie WEP de nos cartes présente une anomalie lorsque les
débits utilisés sont de 11Mb/s. Cela a une impact important sur le débit lorsque la taille des
paquets dépasse un certain seuil, puisque le débit obtenu est bien inférieur au débit attendu. Cette
anomalie a été mise en évide par expérimentation.

141
Le débit global Le débit global d’un réseau complet (tous les mobiles peuvent communiquer avec
tous les autres) augmente quand le nombre de mobiles en contention augmente. Cette caractéristique
a été mise en évidence par une expérimentation qui a montré que le débit aggrégé augmentait
lorsqu’on avait jusqu’à cinq mobiles en contention, puis il se stabilisait après (jusqu’à sept mobiles
utilisés). Ce fait provient du mécanime d’attente aléatoire de DFWMAC de 802.11 : lorsqu’un
mobile n’a pas pu émettre, il ne retire pas un nouveau backoff aléatoire mais utilise le backoff
restant.
Si on considère que, d’après les travaux de [77], le nombre optimal de voisins dans un réseau
ad hoc devrait être de l’ordre de six, cela impliquerait que le débit global est optimal dans chaque
zone de diffusion (où tous les mobiles peuvent communiquer avec tous les autres). Cela est bien sûr
vrai si on regarde chaque zone de diffusion indépendamment des autres. Mais il est beaucoup plus
difficile de prédire le débit global lorsque ces zones sont dépendantes les unes des autres.

La portée de communication Une différence de taille est à noter dans les portées de com-
munication obtenues par simulation et par expérimentation. En effet, la portée réelle (obtenue en
environnement extérieur) est très inférieure aux portées considérées dans NS2. De plus, les zones de
couverture sont loin d’être circulaires comme le suppose les modèles de propagation couramment
utilisés en simulation : il existe dans la réalité une zone où les communications sont très instables
et sujettent à des interférences liées à l’environnement se produisant de façon regroupées dans le
temps (par rafales). L’observation de tels comportement dans la réalité alors qu’ils ne sont pas pris
en compte dans les simulateurs (même dans le modèle shadowing qui est le plus réaliste proposé par
NS2) indique que ces derniers ont nécessairement une vision optimiste, et que leurs résultats sont
peut-être parfois bien loin de la réalité. Ceci est particulièrement problématique dans la mesure où
la perception que les simulateurs donnent de l’environnement radio aux concepteurs de protocoles
de routage influence ces derniers de façon certaine. Enfin, les expérimentations ont montré que
l’orientation des cartes, aussi bien au niveau du récepteur que de l’émetteur, avait un impact non
négligeable sur la portée de communication.

Les interférences par rafales Ce constat provient des deux points précédents et des expériences
réelles (notamment sur la chaı̂ne) Les communications sont perturbées par des interférences prove-
nant de l’environnement qui interviennent de manière groupée dans le temps. Pendant des périodes
de temps plus ou moins longues, le débit des communications devient faible, voire nul. Puis les com-
munications repartent normalement sans raison apparente. Ceci rend les résultats réels nettement
inférieurs aux prévisions par simulation.

Le mécanisme d’EIFS apporte une instabilité dans les débits Le mécanisme d’EIFS est
déclenché quand un mobile reçoit un signal qu’il n’est pas en mesure de comprendre mais qui
l’empêche d’émettre. L’EIFS est environ six fois plus important que le DIFS utilisé lors de l’envoi
“classique” de paquets, i.e. quand aucun signal interférant ne vient troubler les communications.
Or cette différence entre les valeurs de DIFS et de EIFS entraı̂ne une instabilité dans les débits. En
effet, lorsqu’un mobile réussit à prendre la main dans l’accès au médium, il va alors la garder pour
l’envoi de plusieurs paquets consécutifs, car le mobile gêné par ces communications doit attendre
plus longtemps avant de pouvoir accéder au médium. Cette instabilité a été mise en évidence par
simulation dans les scénarios des deux paires et des trois paires.
Le partage du médium en zone de détection de porteuse Si deux mobiles sont en zone
de détection de porteuse l’un de l’autre, ils doivent partager le médium radio, même s’ils sont trop
éloignés pour communiquer. Cette caractéristique a été mise en évidence par simulation et par
expérimentation dans les scénarios des deux paires et des trois paires. Elle s’explique aussi très bien
par le fonctionnement de 802.11. Elle a un impact très important au niveau de la qualité de service
dans de tels réseaux. En effet, si le but est d’offrir une garantie sur la bande passante, on voit qu’il
n’est plus possible de seulement se baser sur les communications voisines, mais qu’il faudra être en
mesure d’évaluer les communications s’effectuant dans la zone de détection de porteuse.
Dans NS2, la zone de détection de porteuse est deux fois plus grande que la zone de communi-
cations. Les expérimentations ont montré que cette zone était aussi de l’ordre de deux foix la zone
de communication mais qu’elle était aussi beaucoup plus instable. L’expérience sur une chaı̂ne de
mobiles montre que parfois cette zone devenait plus grande ou plus petite.

Les débits multiples 802.11b permet l’utilisation de débits multiples : les paquets de données
sont envoyés à 11Mb/s alors que les paquets de diffusion sont envoyés à 2Mb/s. De plus, 802.11
permet la dégradation de débit d’un flux si la communication n’est pas bonne. Plusieurs travaux
([42, 41]) ont montré que l’utilisation de débits multiples avaient des effets non négligeables. D’une
part, les protocoles de routage qui se basent sur des paquets en mode diffusion vont offrir une vision
erronée du voisinage aux mobiles. D’autre part, le partage équitable que 802.11 offre aux mobiles à
portée de communication va ralentir les mobiles à plus grand débit qui auront le même débit que
les mobiles plus lents. Ces caractéristiques ont été retrouvées par expérimentation.

Les problèmes d’équité Par simulation et expérimentation, des problèmes graves d’équité dans
l’accès au canal sont apparus, certains mobiles étant dans la quasi-impossibilité d’envoyer des
messages pendant des périodes de temps prolongées. L’analyse de ces problèmes (par simulation et
expérimentation, avec l’aide d’outils de visualisation tels que les chronogrammes et par le calcul)
nous a montré qu’ils trouvaient leur source dans la norme 802.11. Cette dernière a été conçue pour
des réseaux à stations de base. Dans les configurations particulières de réseaux ad hoc que nous
avons testées, elle est clairement mise en défaut. La nature du problème tient pour une bonne part
dans l’inégalité des mobiles faces aux interférences. 802.11 donne des chances comparables d’accès
au canal à des mobiles en compétition mais à portée de communication directe ou indirecte (deux
sauts, grâce aux RTS/CTS). Mais dans les configurations que nous avons présentées ces chances
sont faussées. En effet, certains mobiles vont subir une combinaison des activités de mobiles voisins
qui agissent indépendamment les uns des autres et qui indique à ce mobile que le canal est occupé
en permanence, et l’empêche donc de façon durable d’y accéder.
Ce problème a été mis en relief dans le scénario des trois paires aussi bien par simulation que
par expérimentation. Il se retrouve aussi dans le scénario de la chaı̂ne, mais il est combiné à d’autres
problématiques (comme des débits différents sur les mobiles par exemple).
L’impact de ces problèmes sur les applications mais également sur les protocoles de routage a été
souligné. Les émissions conjuguées de certains mobiles sont à même de causer dans leur voisinage
des cassures et des redécouvertes de routes à répétitions ; l’efficacité du routage s’en ressentant
grandement. Enfin, les protocoles ont une vision erronée du réseau et pourraient peut-être prendre
des décisions différentes s’ils disposaient de la topologie réelle.
Impact des EIFS sur l’équité . Comme nous l’avons vu par la simulation dans le scénario des
trois paires, l’utilisation des EIFS peut amplifier les inégalités dans l’accès au médium. Dans ce
scénario, la paire centrale accédait jusqu’à six fois moins souvent au canal que lorsqu’elle n’attendait
que DIFS après la fin d’une transmission erronée.

Les RTS/CTS Le mécanisme des RTS/CTS souvent prôné comme la solution aux problèmes des
nœuds cachés semble avoir des effets pas toujours positifs sur des scénarios plus complexes comme
la chaı̂ne de mobiles. Par simulation, nous avons vu que les débits sur la chaı̂ne était fortement
diminué lorsque les RTS/CTS étaient utilisés et que la communication était bien meilleure sans ce
mécanisme.

Les débits réels Les expériences ont montré que les débits réels obtenus dans les réseaux ad hoc
testés sont plus faibles que ceux obtenus par simulation.

L’étude de solutions
A partir du moment où les simulations ont soulevé les problèmes d’équité dont nous venons
de parler, nous y avons cherché des solutions. La nature du problème fait qu’il 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 émissions pose problème n’ont pas de moyen
de s’en rendre compte (parfois ces mobiles sont complètement hors de portée de communication
directe ou indirecte les uns des autres ainsi que des mobiles qu’ils empêchent d’accéder au canal).
Nous avons donc proposé une première solution basée sur des pénalités appliquées d’une manière
étudiée aux mobiles qui émettent beaucoup. Sous simulateur, cette méthode a donné des résultats
tout à fait satisfaisants, aussi bien dans les scénario des trois paires que dans celui de la chaı̂ne
perturbée. Le principal désavantage de la méthode est une chute du débit maximum possible en cas
d’absence de contention. Ce désavantage est cependant très vite limité et rendu imperceptible dès
que le nombre de mobiles en contention augmente E cette situation est finalement très probable
dans un réseau ad hoc, où beaucoup de mobiles vont devoir non seulement envoyer leurs propres
données, mais aussi celles d’autres nœuds pour lesquels ils routent des paquets.
A des fins de vérification, nous avons adapté le mécanisme de la pénalité à notre environnement
de mesure. Comme il n’était pas possible de modifier la couche MAC directement (ce qui aurait
été idéal, mais impossible du fait des codes sources fermés), nous avons utilisé un système de
remplacement. Ce dernier, basé sur le filtrage de paquets dans le noyau linux et leur retenue
temporaire dans l’espace utilisateur a nécessité quelques modifications dans notre algorithme, mais
a ensuite donné entière satisfaction. Dans le scénario des trois paires que nous avons reproduit une
nouvelle fois, la paire centrale pouvait enfin accéder au canal dans des proportions raisonnables.
Enfin, nous avons aussi amélioré une solution aux problèmes d’équité proposée par Bensaou
et al. Par un mécanisme simple (inclu dans l’acquittement ou le CTS) qui permet de prendre
en compte les communications distantes et par une meilleure stabilisation de l’algorithme, nous
proposons une solution qui donne une meilleure équité et qui permet de diminuer la perte de débit
global en bande passante.
Bilan
L’intérêt pour les réseaux ad hoc est récent. Les recherches dans ce domaine se sont concentrées
sur certains problèmes clefs, et en particulier sur le routage. Pour des raisons pratiques, au travers
de différents outils de simulation, ces nombreuses études s’appuient dans leur grande majorité sur
la norme 802.11.
L’originalité de nos travaux tient dans l’approche pragmatique que nous avons eue des réseaux
ad hoc. La pile de protocoles, du niveau physique jusqu’aux applications, même si elle présente des
similitudes avec celles des mondes filaires et cellulaires, a besoin d’adaptations spécifiques à tous
les niveaux. La couche MAC de 802.11, de part son fonctionnement totalement distribué, sert de
fondation pour la majorité des travaux du domaine ad hoc se voulant capables de fonctionner sur
les technologies radio grand public de ce début de millénaire. C’est donc d’une manière naturelle
que notre intérêt s’est porté sur elle et ses interactions avec les couches supérieures dans le contexte
ad hoc.
De part les problèmes que nous avons soulevés, nous avons montré que le choix des couches
basses et de la couche MAC en particulier étaient loin d’être neutres dans les réseaux ad hoc,
et qu’il y avait des interdépendances très fortes entre tous les niveaux de la pile de protocoles.
Ainsi, l’environnement et les situations topologiques propres aux réseaux ad hoc conduisent à des
interférences physiques, qui agissent sur la couche MAC, qui elle-même a un effet sur le fonction-
nement des protocoles de routage.
Notre étude de ces phénomènes et de leur impact est novatrice dans le sens où nous avons
cherché à les isoler spécifiquement, plutôt qu’à obtenir des résultats agrégés où les interactions
entres les couches MAC, PHY, routage, TCP et application sont entremêlés et finalement peut
exploitables.

Perspectives
Un certain nombre de topologies ad hoc qui posaient problème à 802.11 ont été mises à jour
dans nos travaux, mais la recherche de ces situations n’a pas été exhaustive et il est tout à fait
possible qu’il en existe d’autres qui soulèvent des problèmes particuliers. La recherche de l’ensemble
des situations problématiques, leur étude théorique et leur reconnaissance par des expériences nous
apparaı̂t donc comme un premier axe de travail dans la continuité de cette thèse ; d’autant plus
que nous pouvons désormais compter sur les outils que nous avons développés.
Les problèmes d’équité forment à eux seuls un domaine de recherche. Certaines études théoriques
existent déjà dans la littérature, mais beaucoup de travail reste à faire, aussi bien dans la classifica-
tion des définitions diverses de l’équité, que dans la proposition de solutions. Le lien peut être fait
également avec le point précédent : les problèmes spécifiques des réseaux ad hoc (de topologie et des
interférences qui y sont liées en particulier) peuvent être pris en compte pour définir l’équité et y
proposer des solutions adaptées. Les contraintes sont cependant nombreuses, comme la distribution
de l’algorithme qui est un point capital par exemple.
Le troisième axe de recherche concerne les interactions avec les couches supérieures, et le routage
en premier lieu. Dans cette thèse nous avons montré et expliqué un certain nombre d’impacts sur
le routage que peuvent avoir les couches basses, nous pensons qu’il faudrait maintenant capitaliser
ces résultats et s’en servir pour repenser et adapter la manière de router dans un réseau ad hoc.
Dans le domaine des simulateurs, la réalisation de couches physiques présentant les comportements
observés dans nos mesures nous semble un premier pas dans cette voie. Dans la communauté ad hoc,
les simulateurs ont un impact très important sur la conception des protocoles de routage. Au delà
du routage, les interactions avec TCP mériteraient également d’être revisitées, les performances
de TCP étant passablement mauvaises, aussi bien dans les simulations actuelles de réseaux ad
hoc (pourtant étonnamment optimistes, comme nous l’avons souligné) que dans les rares mesures
réelles.
Liste des acronymes

ACK ACKnowledgment
AP Access Point

BEB Binary Exponential Backoff


BPSK Binary Phase Shift Keying
BS Base Station
BSA Basic Service Area
BSS Basic Service Set

CA Collision Avoidance
CBR Constant Bit Rate
CCK Complementary Code Keying
CD Collision Detection
CDMA Code Division Multiple Access
CFP Contention Free Period
CP Contention Period
CRC Cyclic Redundancy Check
CSMA Carrier Sense Multiple Access
CTS Clear To Send
CW Contention Windows

DARPA Defense Advanced Research Projects


DCF Distributed Coordination Fonction
DIFS DCF Inter Frame Spacing
DSSS Direct Sequence Spread Spectrum

ETSI European Telecommmunications Standards Institute

FDD Frequency Division Duplex


FHSS Frequency Hopping Spread Spectrum

GPS Global Positioning System

HiperLAN High Performance European Radio LAN

147
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IFS Inter Frame Spacing
IP Internet Protocol
IR Infra-Red
ISM Industry, Scientific and Medical
IV Initialisation Vector

LAN Local Area Network


LLC Logical Link Control

MAC Medium Access Control


MANET Mobile Ad hoc NETwork

NAV Network Allocation Vector


NS Network Simulator

OFDM Orthogonal Frequency Division Multiplexing


OSI Open System Interconnection

PCF Point Coordination Fonction


PIFS Polling IFS
PRNET Packet Radio Network

QoS Quality of Service


QPSK Quadrature Phase Shift Keying

RTS Request To Send

SIFS Short IFS

TCP Transport Control Protocol


TDD Time Division Duplex
TDMA Time Division Multiple Access

UDP User Datagram Protocol


UN-II 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 (consulté 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), Bei-
jing, China, pages 1618–1622, september 2003.
[5] D. Dhoutaut and I. Guerin-Lassous. Impact d’un fort trafic en dehors de la zone de communication
dans une réseau ad-hoc multi-sauts. In Proceedings of ALGOTEL 2002, Mèze, France, pages 147–153,
mai 2002.
[6] D. Dhoutaut and I. Guerin-Lassous. Expérimentations 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 442–449, 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 219–230, 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 287–297, 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 Guérin Lassous. Bruit : Bandwidth reservation under interferences in-
fluence. In European Wireless 2002 (EW2002), pages pp. 466–472, 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/in-
notes/rfc3561.txt (consulté 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 1405–1413, 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 Int’l. 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 Broad-
cast Routing over MANET. In Proceedings of INC 2002, Plymouth, 2002.
[28] ETS 300 652 High Performance Radio Local Area Network (HiperLAN) type 1 - Functionnal Specifi-
cation.
[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ühlethaler Paul. 802.11 et les réseaux 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 134–140, 1990.
[34] Ronald L. Rivest. Rc4. Dans Bruce Schneier, Cryptographie Appliquée : protocoles, algorithmes et
codes source en C. 2e éd. 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, Université 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 25–29, 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 Nordstr”om, and Christian Tschudin. The gray zone problem in ieee 802.11b ba-
sed ad hoc networks. In ACM SIGMOBILE Mobile Computing and Communications Review, volume 6,
pages 104–105, 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 MMT’99, 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 LAN’s. In SIGCOMM, pages 212–225, 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 99–106. 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 Simulation Library (GloMoSim),
http ://pcl.cs.ucla.edu/projects/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 565–574, 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 85–97, 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 3–12, 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 214–218, 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. 992–997, 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) :21–29, 2000.
[66] S. Bae, S. Lee, and M. Gerla. Unicast Performance Analysis of the ODMRP in a Mobile Ad hoc Net-
work Testbed. In Proceedings of the IEEE International Conference on Communications and Networks
(ICCCN), Las Vegas, 2000.
[67] Erik Nordström. APE - a Large Scale Ad Hoc Network Testbed for Reproductible Performance Tests.
Master’s thesis, Uppsala University, 2002.
[68] H. Lundgren, D. Lundberg, J. Nielsen, E. Nordstrom, and C. Tschudin. A large-scale testbed for repro-
ducible ad hoc protocol evaluations. In proceedings of IEEE Wireless Communications and Networking
Conference, pages pp. 412–418, 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 Imple-
mentation, 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) :393–422, March 2002.
[74] Jeremy Elson and Deborah Estrin. Time Synchronization for Wireless Sensor Networks. In Procee-
dings of the Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile
Computing, pages 1965–1970, San Francisco, CA, USA, April 2001.
[75] Kay Römer. Time Synchronization in Ad Hoc Networks. In Proceedings of ACM MobiHoc, pages pp.
173–182, October 2001. Long Beach, CA.
[76] Paul Russell. Linux 2.4 packet filtering howto. http ://www.netfilter.org/unreliable-guides/packet-
filtering-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

Vous aimerez peut-être aussi