These PDF

N d’ordre
Année 2003
Thèse
Étude du standard IEEE 802.11 dans le cadre

des réseaux ad hoc : de la simulation à
l’expérimentation.
Présentée devant
L’Institut National des Sciences Appliquées de Lyon
pour obtenir
Le grade de docteur
Par
Dominique Dhoutaut
À soutenir le 11 Dé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 Chargée de recherche (INRIA)
P. Jacquet Directeur de recherche (INRIA, Rocquencourt)
G. Pujolle Professeur (Université Paris VI)
F. Spies Professeur (Université de Franche-Comté)
S. Ubéda Professeur (INSA de Lyon)
Les réseaux ad-hoc sont auto-organisés et ne reposent sur aucune infrastructure fixe. Les
éléments les composant sont en général reliés par radio, potentiellement mobiles, et peuvent être
amenés à entrer ou sortir du réseau à tout moment. Ces réseaux sont caractérisés par la capacité
de chaque participant d’agir à la fois comme client et comme routeur du réseau. Si un émetteur
n’est pas à portée directe de la machine destination, les informations devront être transmises de
proche en proche, le long d’un chemin établi et maintenu par le réseau en cas de modification de
la topologie (ces réseaux sont d’ailleurs qualifiés de multi-sauts).
Le domaine des réseaux ad-hoc est vaste et récent. Un travail conséquent est actuellement
effectué dans le groupe MANET de l’IETF dans le but de normaliser un ou des protocoles de
routage pour ces réseaux. Ces travaux, ainsi que de nombreux autres portants sur des protocoles
de plus haut niveau (qualité de service, dé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 réseaux ad-hoc,
domaine pour lequel elle n’a pas été prévue à l’origine.
– Dans un premier temps, j’ai réalisé de nombreuses simulations avec le simulateur de réseaux
NS2. Elles m’ont en particulier permis de montrer que de graves problèmes d’équité au niveau
de l’accès au médium pouvaient apparaı̂tre. Dans de nombreuses situations typiques des
réseaux ad-hoc certains mobiles peuvent voir leur accès fortement réduit ; ceci a un impact
direct sur les applications, mais aussi sur les protocoles de routages eux mêmes, et risque de
provoquer un effondrement du réseau.
– J’ai donc travaillé à la compréhension et l’analyse de ces problèmes mis en lumière par la
simulation. En sus de problèmes déjà largement étudiés dans la littérature (par exemple les
nœuds cachés), le fait que dans un réseau ad-hoc des mobiles puissent se gêner les uns les
autres sans pour autant avoir de moyen de communiquer apporte de nombreuses contraintes
supplémentaires. L’étude (par la théorie et la simulation) de ces contraintes et de leurs in-
teractions avec certains mécanismes prévus par la norme 802.11 m’ont logiquement amené a
proposer des solutions aux problèmes d’équité. Certaines solutions s’affranchissent de toute
communication entre les mobiles se gênant potentiellement. D’autres solutions essaient de
tirer parti d’une connaissance d’une région plus étendue que le voisinage direct pour obtenir
des résultats s’approchant de l’idéal.
– Mais au fur et à mesure que ma compréhension de la norme 802.11 et des phénomènes liés à son
utilisation dans les réseaux ad-hoc s’étoffait, il m’est apparu que la réalité était plus complexe.
En environnement réel, des phénomènes physiques non pré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 mené de nombreuses expérimentations à l’aide
d’outils que j’ai développés. Dans un premier temps, ces mesures ont porté sur des scénarios
simples permettant d’extraire les caractéristiques principales de 802.11. Ces mesures ont ainsi
permis de mettre en lumière des problèmes jusqu’alors présentés de façon théorique par la
communauté (par exemple le problème des ”zones grise”), mais également d’autres jusqu’alors
ignorés ou non pris en compte.
– Dans un deuxième temps, j’ai mené des expérimentations sur des scénarios plus complexes
et typiques des réseaux ad-hoc (sauts multiples, interférences entres mobiles ne pouvant pas
communiquer entre eux,...). Ces expérimentations ont d’une part confirmé les problèmes sou-
levés par certaines simulations, et d’autre part m’ont permis d’implémenter, de tester et de
valider les solutions aux problèmes d’équité que j’avais proposées précédemment.
Table des matières
1 Les réseaux ad hoc 10

1.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Problèmes et contraintes spécifiques des réseaux radio . . . . . . . . . . . . . . . . . 10
1.3 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Routage hiérarchique ou plat . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2 Etat de liens ou vecteur de distance . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.3 Les différentes familles de protocoles de routage MANET . . . . . . . . . . . 15
1.3.4 Description de quelques protocoles de routage représentatifs . . . . . . . . . . 16
2 Présentation de 802.11 20
2.1 Les autres normes de ré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 à 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 sécurité des informations : la Wired Equivalent Privacy (WEP) . . . . . . . . . . 34
2.6 Les trames 802.11b et le débit utile 802.11b . . . . . . . . . . . . . . . . . . . . . . . 36
3 Particularités de 802.11 dans un contexte ad hoc 40

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Le problème des nœuds cachés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Le problème des nœuds exposés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Le problème de la zone grise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5 Partage du canal entre des flux à vitesses différentes . . . . . . . . . . . . . . . . . . 43
3.6 TCP et 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7 Capacité théorique en fonction la topologie (grille, chaı̂ne) . . . . . . . . . . . . . . . 44
3.8 Equité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Conclusion et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3
I Simulations logicielles de réseaux ad-hoc 46
4 Simulations : introduction et scénarios de prise en main 47

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Objectifs initiaux des simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Présentation de Network Simulator 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Les différents modèles de propagation radio sous NS2 . . . . . . . . . . . . . 49
4.3.2 La gestion des interférences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Traitements des résultats et outils d’analyse . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Prise en mains et premières simulations . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.1 Portée de communication et débit . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.2 Interférences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Scénarios ”avancé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 problème de l’asymétrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.6 Conclusion sur ces simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 Quelques solutions aux problèmes d’équité dans les réseaux ad hoc 72

6.1 Une solution historique et locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Une solution étendue géographiquement . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.1 Point de départ et algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.2 Quelques résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
II Expérimentations en environnement ré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 antérieurs basé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 premières mesures 92

8.1 Justifications des données mesurées. . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.2 Le débit en fonction de la taille des paquets . . . . . . . . . . . . . . . . . . . . . . . 92
8.2.1 La fragmentation à 1500 octets . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2.2 L’impact du WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2.3 Hormis les problèmes pré-cités, des débits très proches de la théorie . . . . . 95
8.3 Partage du canal entre nœuds à portée de communication . . . . . . . . . . . . . . . 96
8.3.1 Deux flux (combinaisons d’émetteurs et récepteurs) . . . . . . . . . . . . . . . 96
8.3.2 Flux multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.4 Les mesures de portée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.4.1 L’environnement et le outils de mesure . . . . . . . . . . . . . . . . . . . . . . 99
8.4.2 Les résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9 Les outils d’analyse avancée 104

9.1 Les chronogrammes en environnement réel . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2 Le problème de la synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3 Résolution du problème de la synchronisation . . . . . . . . . . . . . . . . . . . . . . 107
9.3.1 Les différentes approches, les systèmes existants . . . . . . . . . . . . . . . . . 107
9.3.2 Premières constatations et méthode simple . . . . . . . . . . . . . . . . . . . 109
9.3.3 Deuxième méthode : approximation de la dérive des horloges par une droite
affine par morceaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.3.4 Troisième méthode : le pèlerin synchronisateur . . . . . . . . . . . . . . . . . 114
10 Les scénarios ”avancés” 117

10.1 Les deux paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.2 Les trois paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3 La chaı̂ne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3.1 Le scénario, les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3.2 Le déploiement et le déroulement de l’expérience . . . . . . . . . . . . . . . . 122
10.3.3 Les résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11 Mise en pratique du malus 134

11.1 Choix de l’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5
Introduction
Point de départ et sujet de thèse

A l’heure où les communications téléphoniques sans fil se sont imposées de façon indéniable,
et où les réseaux locaux radio connaissent un essor fulgurant, de nouvelles applications de ces
technologies apparaissent sans cesse. Ces sont les militaires qui ont été les premiers intéressés par
des technologies de communication radio fonctionnant de proche en proche et restant fonctionnelles
en cas de mobilité ou de perte de certains éléments routeurs. Dans [1], on apprend que dès le début
des années 1970, les techniques de commutation de paquets ont inspiré le développement par le
DARPA1 des Packet Radio Network (PRNET). Ces réseaux disposaient déjà d’une architecture
distribuée, partageaient dynamiquement le canal de diffusion par une combinaison des protocoles
Aloha et CSMA, et se servaient de la répétition des paquets pour élargir la zone de couverture
globale. Par la suite, en 1983, les Survivable Radio Networks (SURAN) furent développés par
le DARPA. L’objectif était de passer outre les principales limitations des PRNet (en particulier
permettre le passage à des réseaux comportant énormément de nœuds, gérant la sécurité, gérant
l’énergie, et offrant des capacités de calcul suffisantes pour supporter des protocoles évolués). Mais
les recherches sur ces réseaux restaient exclusivement militaires. Les applications civiles de ces
réseaux appelés ad hoc n’apparurent que beaucoup plus tard, vers la fin des années 1990. Parmi les
applications actuellement les plus en vogue destinées aux réseaux ad hoc, en sus de celles à usage
militaire, on peut citer par exemple :
– le déploiement de réseaux dans des environnements où les infrastructures fixes ne sont plus
opérationnelles (sur les lieux de catastrophes naturelles ou autres) ;
– le déploiement de réseaux de capteurs dans des environnements hostiles ou difficiles d’accès.
Un tel réseau s’auto-configure en fonction des ressources énergétiques restantes et de la dis-
tribution géographique des nœuds (disséminations initiale par largage par exemple, qui les
place de manière assez aléatoire) ;
– l’extension de réseaux doté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 à passer par des mobiles intermédiaires pour les atteindre et ainsi se rattacher à
l’ensemble du réseau.
Ces recherches sur les réseaux ad hoc dans le domaine civil n’ont en fait véritablement pris
leur essor qu’avec l’arrivée des premières technologies radio bon marché : principalement la norme
IEEE2 802.11 et ses diverses extensions. La norme 802.11 est conçue avant tout pour bâtir des
réseaux autour d’une infrastructure fixe de bornes radio reliées entre elles par un réseau câblé.
1
Defense Advanced Research Projects Agency
2
Institute of Electrical and Electronics Engineers, http ://www.ieee.org
6
Mais la méthode d’accès au canal qu’elle propose par défaut fonctionne de manière totalement
distribuée, c’est la Distributed Coordination Function (DCF). Cette dernière, alliée au coût modéré
des équipements, a joué un rôle primordial pour l’utilisation de 802.11 dans un contexte ad hoc.
Elle peut en effet être utilisée directement et laisse les chercheurs se concentrer sur les couches
supérieures.
Ces recherches se sont cristallisées en particulier sous la forme d’un groupe de travail à
l’IETF3 : le groupe MANET (Mobile Ad hoc NETworks [2]). Les problématiques de ce type de
réseaux sont nombreuses et substantiellement différentes de celles des mondes filaire ou même
cellulaire (pas d’infrastructure fixe ni même d’assurance d’avoir des voisins, mobilité possible de
tous les éléments et donc absence de plan d’allocation géographique des fréquences, etc.). Le
groupe MANET travaille essentiellement à l’élaboration de protocoles de routage adaptés (lorsque
l’on cherche à communiquer avec un mobile qui n’est pas à portée directe, il va falloir être capable
de trouver des mobiles intermédiaires qui vont relayer le message). Mais les couches les plus basses
(physique et d’accès au médium) aussi bien que les couches plus élevées (jusqu’aux applications)
nécessitent elles aussi des retouches plus ou moins importantes. Par exemple, l’absence d’éléments
fixes empêche de centraliser certaines tâche, et rend l’utilisation de méthodes d’accès au canal
telles que TDMA (Time Division Multiple Access) ardues. De même, puisque le réseau peut parfois
se partitionner, les applications n’ont pas toujours accès aux mêmes ressources, et doivent donc
utiliser des caches ou prendre toutes autres mesures qu’elles jugent utiles pour fournir un service
le moins dégradé possible.
De part sa diffusion et son faible coût, 802.11 sert de support à de très nombreux travaux dans
le domaine des réseaux ad hoc (que ce soit au niveau du routage, de la qualité de service ou encore
des applications). Mais cette norme n’a néanmoins pas été conçue pour ce type d’utilisation puisque
les réseaux à stations de base sont le contexte qu’elle cible réellement. Il apparaı̂t que certains de
ses comportements dans un cadre purement ad hoc ne sont finalement pas bien connus. C’est à
l’étude de ces comportements et leurs interactions avec les couches supérieures qu’est vouée cette
thèse.
Contributions et organisation du document

Nos travaux se situent au niveau de l’interaction entre les protocoles spécifiques des réseaux
ad hoc et les couches MAC (Medium Access Control) et physique sur lesquelles ils s’appuient.
Le chapitre 1 introduit les réseaux ad hoc et le chapitre 2 présente la norme 802.11. Pour
les réseaux ad hoc, les différentes familles de protocoles de routage sont présentées, accom-
pagnées d’un certains nombre d’exemples détaillés qui nous permettront par la suite de mieux
comprendre les effets qu’auront sur chacun d’entre eux les comportement des couches basses
utilisées dans un contexte ad hoc. La norme IEEE 802.11 quant à elle n’est bien sûr pas
complètement détaillée, mais les parties significatives et importantes pour notre travail le sont.
Il s’agit, en sus d’un aperçu des techniques utilisées par la couche physique radio, de tout ce
qui concerne la gestion distribuée de l’accès au canal radio, ainsi que certains points précis,
comme la gestion de la cryptographie ainsi que certaines particularités des extensions de 802.11
(802.11b notamment, qui introduit des débits plus élevés mais qui dispose d’aménagements pour
maintenir la compatibilité dont nous devront tenir compte plus tard). Le chapitre 3 quant à lui
3
l’Internet Engineering Task Force, http ://www.ietf.org
7
détaille les contraintes et particularités de l’utilisation de 802.11 dans un contexte purement ad hoc.
Notre contribution se pré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 cherché à mettre en lumière certains problèmes bien spécifiques liés à l’utilisation de
802.11 dans un contexte ad hoc. Cette étude commence par une prise en main de l’outil de simulation
et la réalisation de scénarios simples mais néanmoins nécessaires, puis passe à des scénarios plus
spécifiques. Les conditions d’utilisation des réseaux ad hoc qui ont attiré notre attention sont celles
où le réseau est régulièrement traversé par des flux importants ; ces conditions nous semble en
effet hautement probables dans des réseaux utilisés pour accéder au web, transférer des fichiers ou
encore consulter des messageries. A travers quelques scénarios très caractéristiques (une chaı̂ne de
mobiles, une chaı̂ne et un couple de nœuds perturbateurs, trois paires de mobiles situés à diverses
distances), nous mettons en lumière des problèmes d’équité de l’accès au canal. Il apparaı̂t que dans
des situations malheureusement très communes dans des réseau ad hoc, certains mobiles peuvent
se trouver dans l’incapacité d’émettre, et cela du simple fait de l’activité combinée de certains de
leurs voisins.
A l’aide de divers outils, dont un système de visualisation produisant des chronogrammes
détaillés, nous analysons alors le problème et montrons qu’il trouve sa source dans le mécanisme
d’accès au médium de 802.11. Il n’a en effet pas été prévu pour fonctionner dans des situations
où, dans un ensemble de mobiles voisins, certains d’entre eux rencontrent plus de contention que
d’autres. Nous montrons également que le mécanisme EIFS de 802.11, conçu pour réduire les
chances de collision, est dans cette situation dommageable et amplifie les inégalité face à l’accès au
canal. Nous expliquons alors quels sont les effets sur les protocoles de niveau supérieur. Les pro-
tocoles de routages pâtissent en particulier des interruptions prolongées de communication que ces
problèmes déclenchent, les liens vont leur apparaı̂tre plus instables et ils vont consommer beaucoup
de ressources pour maintenir leurs tables de routage à jour.
Après avoir détaillé pourquoi certains sacrifices devraient nécessairement être faits pour réduire
ces problèmes, nous y proposons dans le chapitre 6 deux solutions. La première est basée sur
une pénalité. Cette pénalité est appliquée d’une manière particulière aux mobiles qui bloquent
leurs voisins en émettant trop et donne des résultats encourageants. Nous présentons ensuite une
seconde méthode, dans laquelle les mobiles diffusent des informations sur l’occupation du canal
perçue localement. Avec les informations transmises par leurs voisins, les nœuds cherchent à se
comporter de manière plus équitable. Des résultats intéressants seront également obtenus avec
cette technique.
Par des mesures réelles. Dans le chapitre 7, après en avoir justifié le choix face à des solutions
existantes, nous présentons le logiciel forwarding que nous avons écrit dans le but de faciliter la
réalisation d’expériences sur de véritables réseaux multi-sauts.
Dans le chapitre 8 nous utilisons forwarding pour vérifier que certains comportements prévus
par la simulation et le calcul se transposent effectivement dans la réalité. Il s’agit en particulier de
mesures sur les débits possibles en fonction de la taille des paquets, de l’effet de la cryptographie
WEP (Wired Equivalent Privacy), et de divers phénomènes lorsque le canal doit être partagé entre
un certain nombre de mobiles à portée de communication.
8
Dans le même chapitre, nous soulignons ensuite les limites des modèles utilisés dans les simula-
tions. En particulier, l’absence de gestion des débits multiples utilisés par 802.11 pour ses paquets
de contrôle et les données ainsi que la forme de la zone de couverture. Sous les simulateurs, les
modèles de propagation couramment utilisés (free-space, two-ray ground et shadowing) conduisent
à des zones de couverture circulaires centrées sur le mobile émetteur. Par des séries de mesures à
différentes distances, vitesses de transmission et orientations des cartes radio, nous montrons que
la réalité est bien différente. Nous fournissons des graphiques nous permettant d’estimer la portée
de communication des cartes en fonction des positions respectives des émetteurs et récepteurs. Ces
mêmes graphiques nous servent également à montrer l’effet des interférences qui se traduit par une
instabilité des liens, même en l’absence de mobilité.
Par des mesures en environnement réel à l’aide du logiciel que nous avons développé, nous
confirmons les problèmes mentionnés dans le premier point et en soulevons d’autres.
Par une analyse avancée des résultats des mesures. Les métriques habituellement utilisées
pour mesurer les performances des réseaux (débits, taux de perte, délais, ...) ont rapidement montré
leurs limites dans l’aide à la compréhension des phénomènes issus de l’utilisation des couches PHY et
MAC de 802.11 dans un contexte multi-sauts. La réalisation de chronogrammes précis s’était révélée
très utile lors de l’analyse des résultats de simulation. Aussi, dans le chapitre 9, nous présentons
une méthode qui permet de réaliser de tels graphiques à partir d’expériences réelles. Les problèmes
principaux lors du passage de la simulation à l’expérimentation sont essentiellement liés à l’absence
d’horloge globale et à une dérive trop rapide des horloges locales des mobiles. Une étude de cette
dérive est présentée et un mécanisme permettant d’en corriger les effets est proposée.
Dans le chapitre 10 nous réalisons des expériences mettant en œuvre des scénarios typiquement
ad hoc. Il s’agira de deux paires s’éloignant l’une de l’autre, du scénario des trois paires déjà étudié
par simulation et enfin d’une configuration de chaı̂ne. Les résultats de ces expériences confirmeront
les problèmes d’équité de l’accès au canal et la nécessité de mieux prendre en compte les couches
basses lors de la conception des protocoles de routage ad hoc.
Disposant alors de tous les outils nécessaires, nous implémentons dans le chapitre 11 le
mécanisme de pénalité décrit dans le chapitre 4. Certaines adaptations sont cependant nécessaires,
du fait de l’impossibilité de modifier la couche MAC, celle-ci étant codée dans une mémoire
embarquée sur les cartes réseau radio et non modifiable (il nous était tout du moins impossible
d’avoir accès à ses codes source qui ne sont pas ouverts). Les résultats encourageants obtenus sont
alors commentés et ouvrent des pistes pour des mécanismes plus élaborés et plus efficaces.
Cette thèse constitue un travail de trois ans qui a été réalisé au sein du LIP puis du CITI,
Isabelle Guerin-Lassous en a assuré l’encadrement au jour le jour durant toute la durée. Certains
des travaux présentés ici sont encore en cours, d’autres ont déjà fait l’objet de publications dans
des conférences internationales ([3, 4]) ou nationales ([5, 6]). Notons également la présentation de
certaines parties sous forme de poster à MS3G 2001, et la finalisation lors du début de la thèse de
[7, 8] qui concluaient des travaux effectués en DEA.
9
CHAPITRE
Les réseaux ad hoc
1
1.1 Objectifs
Les réseaux ad hoc auxquels nous nous sommes intéressés sont ceux décrits et étudiés par
le groupe de travail Mobile Ad-hoc NETworks (MANET) de l’Internet Engineering Task Force
(IETF). Une définition de ces réseaux est donnée formellement dans la RFC 2501 [9]. Il s’agit de
réseaux sans fil et sans infrastructure fixe, utilisant généralement le médium radio, et où chaque
nœud peut combiner les rôles de client et de routeur. Les réseaux ad-hoc sont auto-organisés, ce
qui implique que la connectivité doit être préservée autant que possible automatiquement lorsque
la topologie du réseau change (suite à l’apparition, la disparition ou au mouvement de certains
nœuds). Les premiers travaux sur ce type de réseaux ont été effectués dans une optique militaire
(la capacité à se reconfigurer et à rester opérationnel en cas de perte de certains mobiles étant
un avantage considérable) ; mais leur champ d’application est beaucoup plus vaste. Par exemple,
ces réseaux faciles à déployer peuvent être particulièrement utiles pour rétablir les communications
lorsque des catastrophes ont détruit les installations fixes existantes, on encore lorsque l’on désire
déployer un réseau de capteurs dans certains environnements hostiles.
1.2 Problèmes et contraintes spécifiques des réseaux radio

De par la nature du canal radio, un certain nombre de problèmes se posent qui ne trouvent pas
d’équivalent dans le monde filaire. On peut citer en particulier :
– Un débit plus faible par rapport à un équivalent filaire. Il faut donc que la gestion du
réseau occupe une part la plus réduite possible des maigres ressources en bande passante.
– Une atténuation rapide du signal en fonction de la distance (bien plus rapide que sur un
câble) qui induit l’impossibilité pour un émetteur de détecter une collision au moment même
où il transmet. Dans un réseau filaire, un émetteur sait qu’il y a collision quand le signal
qu’il lit sur le câble est différent de celui qu’il cherche à émettre. Dans un réseau radio, un
signal venant d’un autre nœud est tellement atténué par la distance qu’il ne provoquera que
des perturbations négligeables par rapport au signal émis localement. Par exemple, sur la
figure 1.1, au niveau du nœud B, le signal émis par B lui-même est de très loin supérieur à
celui qu’il reçoit du nœud A. Par conséquent, le signal du nœud A est complètement ignoré
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 récepteur.
Seul un système d’acquittement peut garantir la bonne réception d’un message dans ce type
de contexte. Cette incapacité à détecter un signal étranger lorsque l’on émet nous-même rend
10
CHAPITRE 1. LES RÉSEAUX AD HOC
D
B
A
Fig. 1.1 – l’attenuation rapide du signal en fonction de la distance
donc le médium radio half-duplex, ce qui signifie que l’on ne peut pas émettre et recevoir en
même temps.
– Les interférences. Les liens radios ne sont pas isolés, et le nombre de canaux disponibles
est limité. Il faut donc se les partager. Les interférences peuvent être de natures diverses.
Par exemple, des émetteurs travaillant à des fréquences trop proches peuvent interférer
entre eux. L’environnement lui-même peut également produire des bruits parasites (certains
équipements électriques, certains moteurs, ...) qui interfèrent avec les communications. L’envi-
ronnement peut aussi déformer le signal et le rendre rapidement incompréhensible à cause des
phénomènes d’atténuation, de réflexion ou de chemins multiples (l’atténuation et la réflexion
varient en fonction des matériaux rencontrés ; le problème des chemins multiples apparaı̂t
lorsque des réflexions d’une même onde par des chemins différents arrivent de manière décalée
dans le temps au récepteur, se chevauchent, et forment un tout plus difficile à analyser). Ces
problèmes font que les taux d’erreurs de transmission dans les réseaux radio sont nettement
plus élevés que dans les réseaux filaires. Cela a un impact non négligeable sur les protocoles
de niveau supérieur. TCP en particulier va y être particulièrement vulnérable, car il va in-
terpréter les pertes de paquets comme étant dues à de la congestion sur le réseau. Quand TCP
détecte de la congestion, il cherche à l’atténuer en réduisant la taille de sa fenêtre d’émission
[10]. Malheureusement, dans le cas présent, c’est exactement l’inverse qu’il faudrait faire, les
paquets perdus doivent être ré-émis au plus vite. TCP Westwood [11] est une variante de
TCP qui cherche à corriger ce problème en estimant la bande passante de bout en bout et en
gérant différemment la réduction de la taille de sa fenêtre.
Il faut ajouter également que des interférences ou des changements persistants dans l’envi-
ronnement vont conduire à une grande versatilité des liens, qui peuvent apparaı̂tre ou être
coupés de manière durable à tout moment.
– La puissance du signal. Non seulement elle est rapidement atténuée avec la distance, mais
elle est également limitée par des réglementations très strictes. Un émetteur ne peut donc
dépasser une certaine puissance à l’émission.
– L’energie. Les applications relatives aux réseaux sans fil ont en général un caractère nomade
et tirent leur autonomie de batteries. Emettre ou recevoir des données consomme de l’énergie
et l’on peut chercher à l’économiser en optimisant les protocoles de gestion du réseau. La
puissance d’émission a un impact important sur la quantité d’énergie utilisée et là encore on
essaie si possible de la limiter à ce qui est strictement nécessaire.
– Une faible sécurité. Il est facile ”d’espionner” un canal radio de manière passive. Les
protections ne pouvant pas se faire de manière physique (il est en général difficile d’empêcher
quelqu’un de placer discrètement une antenne réceptrice très sensible dans le voisinage), elle
devront être mises en place de manière logique, avec de la cryptographie ou éventuellement
11
des antennes très directionnelles. Mais le canal radio restera quoiqu’il en soit vulnérable à un
brouillage massif (attaque de type denial of service).
– La mobilité. De nombreuses applications des réseaux radio concernent des mobiles qui,
comme leur nom l’indique, sont amenés à se déplacer. Ceci va conduire à des changements
plus ou moins rapides de la topologie. Pour les gérer, des protocoles appropriés vont être
nécessaires.
Nous avons vu que le full-duplex était rendu impossible par l’atténuation trop rapide des signaux
en fonction de la distance. Pour pouvoir travailler sur un canal half-duplex, les communications
peuvent être multiplexé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 même bande de fréquences.
Quand les débits deviennent très importants, le temps de passage d’un mode à l’autre devient
cependant non négligeable. Le multiplexage FDD (Frequency Division Duplex) permet quant à lui
d’émettre et de recevoir en même temps car on travaille alors sur plusieurs fréquences différentes.
Mais les équipements nécessaires sont plus complexes.
Dans les réseaux ad hoc, certaines des contraintes présentées précédemment sont accentuées et
d’autres apparaissent en supplément :
– L’impossibilité de mettre en place un plan d’allocation des fréquences limite la
réutilisation spatiale. Dans les réseaux radio utilisant des stations de base, on cherche à
attribuer des fréquences différentes aux stations voisines, évitant que les cellules ainsi créées
n’interfèrent entre elles. Dans les réseaux ad hoc, pour garantir la connectivité, 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 coûteux de travailler avec une seule fréquence. On utilise alors un
multiplexage TDD. La réutilisation spatiale reste possible, mais un nœud qui émet empêche
l’accès au canal radio par tous les mobiles se trouvant dans un voisinage étendu autour de
lui.
– L’energie. Dans un réseau à stations de base, les dites stations sont en général alimentées sur
le secteur. Dans un réseau ad-hoc ces stations sont absentes. De plus, suivant la topologie du
ré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 réseau autrement indépendantes par
exemple). Ces nœuds peuvent être amenés à consommer très vite leurs ressources énergétiques.
Le trafic de contrôle peut également avoir un impact important. Comme un réseau ad-hoc
doit s’auto-organiser, cela signifie que d’une manière ou d’une autre il va y avoir un tra-
fic de contrôle dépendant de la mobilité dans le réseau. Plus la topologie changera vite et
profondément, plus la charge (et donc la consommation d’énergie) du trafic de contrôle sera
importante.
– La mobilité. L’impact d’une mobilité ”totale” est important à différents niveaux. Du point
de vue des couches basses (PHY et MAC), comme nous l’avons déjà souligné, il n’est d’une
part plus possible d’affecter des fréquences à des zones géographiques ; d’autre part, les
mécanismes d’accès au médium utilisant des horloges globales seront également inutilisables
(TDMA par exemple a besoin d’une grande synchronisation des horloges qui est impossible
dans ce contexte). A un niveau plus élevé, dans les réseaux à stations de base (en particulier
à grande échelle comme dans les réseaux de téléphonie mobile), le routage est effectué dans la
partie fixe du réseau. Dans le cas des réseaux ad hoc, l’ensemble du routage doit fonctionner
sur les mobiles et de façon totalement distribuée. Cela nécessite de nouveaux algorithmes et
les contraintes à leur réalisation sont plus importantes.
12
– La faible sécurité. Dans les réseaux ad hoc, non seulement les données sont vulnérables
comme dans tout réseau radio, mais consécutivement au point précédent, il en est de même
pour le trafic de contrôle et de gestion du routage [12, 13]. Les problématiques de la sécurité
dans les réseaux ad hoc sont donc très complexes, puisque l’on cherche à autoriser de nouveaux
mobiles à participer au réseau, tout en évitant des nœuds ”malins” qui détourneraient ou
perturberaient le fonctionnement même du routage.
– La qualité de service. De nombreuses applications ont besoin de certaines garanties re-
latives par exemple au débit, au délai ou encore à la gigue. Dans ces réseaux ad hoc, ces
garanties sont très difficiles à obtenir. Ceci est dû à la nature du canal radio d’une part (in-
terférences et taux d’erreur élevés) et au fait que des ”liens” entre des mobiles peuvent avoir
à se partager les ressources (alors qu’en filaire, deux liens sont par définition indépendants).
De ce fait, les protocoles de qualité de service habituels (par exemple IntServ / RSVP ou Diff-
Serv) ne sont pas utilisables directement dans le monde ad hoc et des solutions spécifiques
doivent être proposés [14, 15].
1.3 Routage
Les réseaux ad hoc que nous considérons sont multi-sauts. Il peut donc arriver qu’un mobile
veuille communiquer avec un autre qui n’est pas dans sa portée de communication directe. Les
messages vont devoir être transmis de proche en proche jusqu’à la destination : c’est ce que l’on
appelle le routage. La technique la plus basique est l’inondation, où chaque mobile ré-émet tous
les paquets qu’il reçoit pour la première fois. Evidemment, l’inondation consomme beaucoup de
ressources (bande passante et énergie) et n’est pas optimale. De nombreux protocoles de routage
ont donc été proposés pour rendre les communications multi-sauts plus efficaces (moins de ré-
émissions, chemins plus courts, etc.) que l’inondation basique.
Même si elle n’en constitue pas le fondement, la connaissance des protocoles de routage du monde
ad hoc est nécessaire au travail que nous avons mené. Nous allons voir plus loin que les phénomènes
des niveaux physique et MAC ont des impacts importants sur les protocoles de niveaux supérieurs.
Mais ces impacts varient grandement en fonction des techniques utilisées pour le routage.
Dans cette section, nous allons donc présenter certains des protocoles de routage développés
dans le cadre du groupe de travail MANET de l’IETF. Ces protocoles travaillent au niveau IP
et sont donc indépendants des couches physique et MAC. Le routage IP permet en particulier
une interconnectivité aisée avec toutes sortes d’autres réseaux ou matériels. Il est d’ailleurs pos-
sible d’utiliser ces protocoles pour fédérer en un seul réseau MANET des utilisateurs utilisant des
matériels différents (cartes radios de technologies diverses, réseaux filaires, etc.). Les protocoles
présentés sont parmi les plus représentatifs des diverses techniques utilisées pour le routage ad hoc.
1.3.1 Routage hiérarchique ou plat

Les protocoles de routage pour les réseaux ad hoc peuvent être classés suivant plusieurs critères.
Le premier d’entre eux concerne le type de vision qu’ils ont du réseau et les rôles qu’ils accordent
aux différents mobiles.
– Les protocoles de routage ”à plat” considèrent que tous les nœuds sont égaux (figure 1.2).
La décision d’un nœud de router des paquets pour un autre dépendra de sa position et pourra
être remise en cause au cours du temps.
13
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 ”à plat” Fig. 1.3 – Routage hiérarchique
– Les protocoles de routage hiérarchique fonctionnent en confiant aux mobiles des rôles qui
varient de l’un à l’autre. Certains nœuds sont élus et assument des fonctions particulières qui
conduisent à une vision en plusieurs niveaux de la topologie du réseau. Par exemple, un mobile
pourra servir de passerelle pour un certain nombre de nœuds qui se seront attachés à lui. Le
routage en sera simplifié, puisqu’il se fera de passerelle à passerelle, jusqu’à celle directement
attachée au destinataire. Un exemple est donné sur la figure 1.3, où 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 à la passerelle qui
se débrouillera). Dans les réseaux où certains nœuds s’avèrent très sédentaires et disposent
de suffisamment d’énergie (par exemple réseau d’ordinateurs portables mais où certains sont
reliés au secteur, stations de base disposées là pour garantir la connectivité, etc.) , ce type de
routage présente certains avantages.
1.3.2 Etat de liens ou vecteur de distance

Une autre classification, héritée du monde filaire, est possible pour les protocoles de routage :
Les protocoles à état de lien. Ils cherchent à maintenir dans chaque nœud une carte plus ou
moins complète du réseau où 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
capacité à pouvoir facilement trouver des routes alternatives lorsqu’un lien est rompu. Il est même
possible d’utiliser simultanément plusieurs routes vers une même destination, augmentant ainsi la
répartition de la charge et la tolérance aux pannes dans le réseau. En contre partie, si le réseau est
étendu, la quantité d’informations à stocker et diffuser peut devenir considérable.
Les protocoles à vecteur de distance. Plutôt que de maintenir une carte complète du réseau
(ce qui peut s’avérer extrêmement lourd), ces protocoles ne conservent que la liste des nœuds du
réseau et l’identité du voisin par lequel passer pour atteindre la destination par le chemin le plus
court. A chaque destination possible sont donc associés un next-hop et une distance. Si un voisin
nous envoie un paquet de contrôle dans lequel il indique être plus prè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 inconvénients
de cette technique et qu’il n’est du coup plus possible de conserver plusieurs routes alternatives au
cas où celle qui est privilégiée serait rompue.
14
1.3.3 Les différentes familles de protocoles de routage MANET

Dans les travaux menés à l’IETF, plusieurs familles de protocoles se sont rapidement dégagées.
Chaque protocole peut ainsi être classifié en tant que réactif, proactif, ou hybride.
Les protocoles réactifs

Le principe des protocoles ré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’économiser de la bande
passante et de l’énergie. Lorsqu’un paquet doit être envoyé, le protocole de routage va rechercher
un chemin jusqu’à la destination. Une fois ce chemin trouvé, il est inscrit dans la table de routage
et peut être utilisé. En général, cette recherche se fait par inondation (un paquet de recherche
de route est transmis de proche en proche dans tout ou partie du réseau). L’avantage majeur de
cette méthode est qu’elle ne génère du trafic de contrôle que lorsqu’il est nécessaire. Les principales
contre-parties sont que l’inondation est un mécanisme coûteux qui va faire intervenir tous les nœuds
du réseau en très peu de temps et qu’il va y avoir un délai à l’établissement des routes.
Les protocoles proactifs

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

Les protocoles hybrides combinent les approches réactive et proactive. Le principe est de
connaı̂tre notre voisinage de manière proactive jusqu’à une certaine distance (par exemple trois
ou quatre sauts), et si jamais une application cherche à envoyer quelque chose à un nœud qui n’est
pas dans cette zone, d’effectuer une recherche réactive à l’extérieur. Avec ce système, on dispose
immédiatement des routes dans notre voisinage proche, et lorsque la recherche doit être étendue
plus loin, elle en est optimisée (un nœud qui reçoit un paquet de recherche de route réactive va
tout de suite savoir si la destination est dans son propre voisinage. Si c’est le cas, il va pouvoir
répondre, et sinon il va propager de manière optimisée la demande hors de sa zone proactive). Selon
le type de traffic et de les routes demandées, ce type de protocole hybride peut cependant combiner
les désavantages des deux méthodes : échange de paquets de contrôle réguliers et inondation de
l’ensemble de réseau pour chercher une route vers un nœud éloigné.
15
1.3.4 Description de quelques protocoles de routage représentatifs

Les protocoles décrits par la suite sont issus du groupe de travail MANET de l’IETF. Ces
protocoles sont représentatifs de diverses techniques et sont les plus avancés sur la voie d’une
normalisation. AODV et OLSR font désormais l’objet d’une Request For Comment (RFC) tandis
que les autres en sont à des versions assez stabilisées de leur drafts.
Ad-hoc On Demand Distance Vector (AODV)

AODV [16] est un protocole basé sur le principe des vecteurs de distance et appartient à la famille
des protocoles réactifs. Les protocoles à vecteur de distance sont en général sujets au problème de
boucle et de comptage à l’infini de l’algorithme de Bellman-Ford qu’ils utilisent (certaines parties du
réseau se trouvent isolées du reste, et les nœuds les composant vont croire qu’ils peuvent atteindre les
nœuds desquels ils sont coupés en passant par leurs voisins. Il s’en suit un phénomè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 problèmes sont résolus par l’utilisation de numéros de séquence pour les
messages de contrôle. Quand une application a besoin d’envoyer des paquets sur le réseau et qu’une
route est disponible dans la table de routage, AODV ne joue aucun rô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 traversé par un RREQ en garde une trace dans
son cache et le retransmet. Quand les paquets de recherche de route arrivent à la destination (ou
à un nœud intermédiaire qui connait lui-même une route valide jusqu’à la destination), alors un
paquet de réponse est généré (RREP) et il est envoyé par le chemin inverse, grâce aux informations
gardées dans les caches des nœuds traversés par les RREQ (voir figure 1.4). AODV dispose d’un
certain nombre de mécanismes optimisant son fonctionnement. L’inondation se fera par exemple
au premier essai dans un rayon limité autour de la source, et si aucun chemin n’est trouvé, alors
seulement elle sera étendue à une plus grande partie du réseau. En cas de rupture de certains liens,
AODV va essayer de reconstruire localement les routes affectées en trouvant des nœuds suppléants
(cette détection de rupture peut d’ailleurs se faire grâce à un mécanisme optionnel de paquets hello
diffusés aux voisins directs uniquement). Si une reconstruction locale n’est pas possible, alors les
nœuds concernés par la rupture des routes utilisant ce lien sont prévenus de sorte qu’ils pourront
relancer une nouvelle phase de reconstruction complète.
Dynamic Source Routing (DSR)

DSR [17] est un autre protocole réactif. Il se différencie des autres en particulier parce qu’il
pratique le source routing : l’émetteur précise dans l’en-tête de chaque paquet la liste des nœuds
qu’il devra traverser pour atteindre sa destination. Ce type de routage présente certains avantages
particulièrement intéressants ; il autorise en particulier la source à conserver dans sa table de routage
plusieurs chemins valides vers une même destination. Le choix du chemin emprunté pourra donc
être fait indépendamment pour chaque paquet, et permettre un meilleur équilibrage de la charge
du réseau ou une meilleure réactivité aux pannes / changements de topologie (plutôt que de tout
de suite en construire une nouvelle quand une route est brisée, on en a d’autres à disposition
immédiate). Dans la pratique, DSR est structuré en deux sous-parties complémentaires : la recherche
de route et la maintenance de route. La recherche de route se fait par inondation : un paquet de
recherche est diffusé de proche en proche jusqu’à la destination. Au fur et à mesure, les identifiants
des nœuds traversés sont ajoutés dans le paquet de recherche de route. Quand elle reçoit ce paquet,
16
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 déjà quel chemin il a emprunté, et obtient ainsi (en l’inversant) la route
pour retourner à la source. A la réception par la destination de paquets de recherche ayant suivi des
chemins différents, la destination ré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 à état de liens. Afin de maintenir à jour les tables de
routage, chaque nœud implémentant OLSR diffuse régulièrement des informations sur son propre
voisinage. Ces informations sont suffisantes pour permettre à chaque nœud de reconstruire une
image du réseau et de trouver une route vers n’importe quelle destination. Mais contrairement à
des protocoles tels qu’OSPF, cette diffusion ne se fait pas par une simple inondation (où chaque
nœud retransmet simplement chaque nouveau paquet qu’il reçoit) ; OLSR optimise la diffusion
grâce au systè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 à deux sauts (voir figure 1.6). La diffusion des informations sur les liens utilisées pour le
routage se fait ensuite uniquement par les relais multi-points ; la couverture totale du réseau est
assurée tout en limitant sensiblement le nombre de ré-émissions. Afin de choisir ses relais multi-
points, un nœud a besoin de connaitre complètement la topologie de son voisinage à deux sauts ;
cela est réalisé grâce à l’envoi périodique de paquets hello contenant la liste des voisins à un saut
connus.
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

TBRPF [19] est un protocole de routage proactif à é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 réseau. TBRPF est constitué de deux parties complémentaires : la découverte des
voisins et le routage proprement dit.
17
MPR
MPR
Source
MPR
Fig. 1.6 – Relais multipoints
La découverte des voisins est assurée par un mécanisme de paquets hello diffusés régulièrement
au voisinage direct. Ces paquets hello contiennent la liste des voisins du nœud, et permettent
ainsi de rapidement connaı̂tre la topologie complète du réseau à deux sauts. Il faut noter que
TBRPF emploie une technique de hello différentiels où seuls les changements de topologie sont
notifiés (diminuant ainsi la taille moyenne des paquets et autorisant leur envoi à une plus grande
fréquence).
La partie routage quant à elle est basée sur un échange des arbres de routage entre nœuds
voisins, conduisant progressivement à la diffusion de l’information dans l’ensemble du réseau.
Là encore cependant seules des parties d’arbres sont échangées. Normalement, un nœud ne
diffuse qu’un sous-arbre à deux niveaux dont il est la racine. Au premier niveau apparaissent les
liens vers tous les voisins directs du nœud, et au deuxième niveau un unique lien vers chaque
voisin à deux sauts (on peut noter ici une certaine similitude avec le mécanisme des relais
multi-points d’OLSR). En conjonction avec ce système de base, TBRPF peut également ajouter
des informations sur d’autre liens à l’arbre diffusé, avant de réagir plus vite en cas de changement
de la topologie. A noter enfin que dans un souci d’économie de bande passante, les sous-arbres et
les paquets hello sont regroupés autant que possible dans un même paquet (on parle d’agrégation
ou piggybacking puisque l’on profite des paquets hello pour envoyer en même temps les sous-arbres).
De nombreux autres protocoles de routage ont été proposés pour les réseaux ad hoc. [20]
en décrit un certain nombre en sus de ceux déjà mentionnés. Dans la catégorie des protocoles
construisant une topologie hiérarchique on peut citer Clusterhead Gateway Switch Routing
(CGSR) présenté dans [21]. Certains autre protocoles nécessitent l’emploi de matériels externes.
Par exemple Temporaly-Ordered Routing Algorithm (TORA) [22] a besoin que les mobiles
soient synchronisés. D’autres ([23],[24]) utilisent le système GPS pour estimer la direction
géographique de la destination et ne faire intervenir qu’une sous-partie du réseau dans la phase
de construction des routes. Alors que beaucoup de protocoles cherchent à minimiser le nombre de
18
sauts (minimum shortest path), certains protocoles enfin s’attachent à prendre d’autres critères
en considération. ABR (Associativity-Based Routing) [25] par exemple privilégie les liens les
plus stables (mobiles qui restent longtemps dans le voisinage les uns des autres). SSR (Signal
Stability Routing) [26] travaille à partir des informations de niveau de signal et [27] cherche à maxi-
miser la durée de vie du réseau en agissant sur la puissance d’émission de chaque mobile séparément.
Les réseaux ad hoc font partie d’un domaine de recherche qui n’a pris son essor que très
récemment. Le facteur qui a déclenché cet intérêt fut l’arrivée de technologies relativement bon
marché qui ont favorisé la conception et le déploiement de tels réseaux. Avant cela, ce domaine
était réservé aux militaires qui disposaient de moyens tout autres.
Les principales normes de réseaux sans fil qui sont à l’origine cet intérêt pour les réseaux ad
hoc sont HiperLAN 1 [28] et 2 [29], Bluetooth [30] et 802.11 [31] de l’IEEE.
19
CHAPITRE
Présentation de 802.11
2
Dans la seconde moitié des années 90, plusieurs normes pour les réseaux sans fils à portée limitée
on été développées (visant des usages à l’échelle du bureau ou du bâtiment). Leur arrivée à soulevé
un engouement nouveau pour les réseau radio multi-sauts, qui étaient jusqu’alors le domaine exclusif
des militaires. Dans ce chapitre, nous allons présenter ces différentes normes, et en particulier 802.11,
qui est désormais utilisée dans la plupart des travaux appliqués de la communauté ad hoc.
2.1 Les autres normes de réseaux locaux sans fil.

Bluetooth a plutôt pour objectif de faire disparaı̂tre les câble entre les divers équipements
numériques (périphériques d’ordinateurs tels que clavier, imprimantes, modems, ou encore appareils
photo numériques, PDA, walkmans, etc.). Les équipements bluetooth ont donc des portées et des
débits assez modestes, ainsi qu’une consommation électrique en rapport.
802.11 est conçue pour les réseaux locaux, en entreprise ou chez les particuliers. Cette norme
s’appuie sur des stations de base reliées à un réseau filaire qui fournir une infrastructure fixe et
reliant les utilisateurs mobiles aux ressources de l’entreprise (et éventuellement à l’Internet). Depuis
peu, 802.11 (et en particulier les cartes compatibles à son extension 802.11b) connaissent un succès
commercial considérable.
HiperLAN type 1 a été conçu comme le pendant européen de 802.11. Cette norme se veut assez
similaire dans son utilisation, mais certains choix technologiques ont été faits qui se démarquent
nettement de 802.11. Commercialement cependant HiperLAN est resté à l’é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 débits aussi élevés et un certain nombre de fonctionnalités
supplémentaires. Mais là encore, il est à craindre qu’HiperLAN 2 ne soit jamais commercialisée à
grande é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 décrit le fonctionnement d’équipements travaillant dans la
bande des 5.15-5.30 GHz et permettant d’atteindre des débits de 23.5 Mbit/s sur une distance d’en-
viron 50 mètres. L’architecture est totalement décentralisée. Il n’y a pas de notion de point d’accès
mais les nœuds HiperLAN 1 peuvent cependant avoir des rôles de passerelles. Les caractéristiques
les plus marquantes d’HiperLAN 1 sont :
20
CHAPITRE 2. PRÉSENTATION DE 802.11
– le mécanisme d’accès au médium évolué, qui gère les priorités. Il est possible d’obtenir des
garanties de qualité de service, particulièrement utiles pour les flux multimédias par exemple ;
– la possibilité d’étendre le réseau au delà de la portée radio, par sauts successifs (fonctionne-
ment en cela très semblable aux réseaux ad hoc, des nœuds jouant le rôle d’intermédiaires
entres ceux qui sont trop loin pour communiquer directement).
Les fonctionnalités d’HiperLAN 1 sont organisées comme présenté sur la figure 2.1. Nous n’en-
trerons pas dans les détails de cette norme complexe, mais nous pouvons remarquer néanmoins que
le mécanisme d’accès au médium EY-NPMA (Elimination Yield-Non Preemptive Multiple Access)
est au cœur du système. C’est lui qui permet en particulier la gestion des priorités. Le fonction-
nement de EY-NPMA est particulièrement intéressant puisqu’il est prévu pour fonctionner dans
un contexte ad hoc. Nous allons donc le décrire plus en avant. Il fonctionne en trois phases et un
exemple est donné sur la figure 2.2 :
– La phase de priorité. Cinq niveaux de priorité sont définis par la norme (de 0 pour le
plus prioritaire à 4) et la phase de priorité est donc divisée en cinq slots. Au début d’un
nouveau cycle de transmission, tous les nœuds qui veulent accéder au canal vont envoyer un
burst de signalement, dont la date de début dépend de la priorité du paquet. Plus la priorité
est élevée, plus le burst commence tôt. Sur la figure, les nœuds A, C et D ont une priorité
de 2, et le nœud B a une priorité de 3. L’idée est d’écouter le canal tant que notre priorité
nous interdit d’émettre notre propre burst de signalement. Si l’on détecte de l’activité avant
d’avoir pu émettre, c’est que quelqu’un est plus prioritaire que nous, et l’on abandonne l’idée
de transmettre pour ce cycle. C’est le cas du nœud B sur la figure 2.2.
– La phase d’élimination. Il se peut que plusieurs nœuds veuillent émettre en même temps
des paquets de priorités identiques. Il faut donc les départager. Pour cela, chaque nœud va
poursuivre l’envoi de son burst de signalement pendant un nombre aléatoire de slots. Ce sera
celui qui aura tiré le plus grand nombre qui l’emportera. Dès que l’émission de notre burst est
terminée, nous écoutons le canal. Si nous y détectons de l’activité, c’est qu’un autre nœud a
tiré 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’écoute. Si toutefois il reste plusieurs nœuds en lice alors l’élimination va se
terminer dans la troisième phase. Un nombre aléatoire de slots est choisit. C’est celui qui
aura tiré le plus petit qui pourra transmettre. Chaque nœud attend pendant la durée qu’il a
déterminé, en écoutant le canal. Si il détecte de l’activité alors qu’il n’a pas fini d’attendre,
il sait que quelqu’un a tiré un plus petit nombre que lui et n’émettra pas durant ce cycle. Si
son attente se termine alors que le canal est toujours libre, alors il émet. Sur la figure, c’est
le nœud D qui l’emporte. Il faut noter que si le paquet est envoyé en point à point, il sera
acquitté par son récepteur (ici le nœud E).
Avec HiperLAN type 1, un mécanisme de routage multi-sauts est implanté. Les nœuds envoient
des paquets hello qui leur permettent de connaı̂tre leur voisinage. Ces informations de voisinage
sont propagées dans tout le réseau et permettent ainsi à un nœud d’en reconstruire la topologie.
C’est un protocole à état de lien qui utilise une système de relais multipoints pour optimiser les
diffusions d’informations.
21
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’accès au canal avec EY-NPMA
2.1.2 HiperLAN 2
L’organisation générale d’HiperLAN type 2 est présentée sur la figure 2.3. On remarque en
premier lieu que la norme prévoit la compatibilité avec diverses technologies (TCP/IP bien sûr,
mais aussi ATM, UMTS et l’IEEE 1394 connue aussi sous le nom de Firewire).
HiperLAN type 2 est très différent dans son architecture d’HiperLAN type 1. Contrairement
au type 1, le type 2 est basé sur une centralisation poussée. Les points d’accès sont d’ailleurs
indifféremment appelés Access Points (AP) ou Central Controler (CC). Les points d’accès sont
reliés entre eux par une infrastructure réseau filaire ou non-filaire (qui doit simplement disposer
d’une interface adéquate dans HyperLAN 2, comme celles de la liste donnée précédemment). Les
mobiles s’attachent ensuite à ces points d’accès pour accéder aux ressources du réseau.
HiperLAN 2 peut aussi fonctionner sans infrastructure fixe. Dans ce cas, un mobile est élu pour
jouer le rôle de contrôleur central et les autres vont s’attacher à lui. Bien entendu, dans ce type
de configuration il n’est pas question de réseau ad hoc au sens où le groupe MANET l’entend.
Tout au plus, les mobiles pourront communiquer directement entre eux (un saut), ou alors par
l’intermédiaire du contrôleur central (deux sauts).
L’accès au médium reflète ces choix architecturaux, et c’est le contrôleur central qui décide de
l’ordonnancement des communications dans la zone qu’il gère. Ces communications se font grâce à
des trames de durée fixe (2 ms) qui sont elles-mêmes découpées en différents champs de longueur
variable et qui portent les informations de contrôle du point d’accès ou les données dans un sens ou
dans l’autre. Il faut noter également que la couche physique d’HiperLAN type 2 est très semblable
à la couche physique de 802.11a (qui sera présentée plus en détail dans la section dédiée à 802.11).
De part son architecture très ciblée, HiperLAN 2 est donc peu adapté aux réseaux ad hoc, et
nous ne détaillerons pas plus cette norme ici.
2.1.3 Bluetooth
Les réseaux Bluetooth ont été développé pour permettre la réalisation de réseaux personnels
(PAN : Personnal Area Network). Ces réseaux doivent permettre des communications à courte
portée, à des débits faibles ou moyens entre toute sorte d’équipements. Ils travaillent dans la bande
22
TCP/IP ATM / UMTS IEEE

B-ISDN 1394
Couche de convergence réseau (NC)
Couche liaison
(DLC)
Couche Physique
Fig. 2.3 – L’organisation générale d’HiperLAN type 2
ISM des 2.4 GHz à des puissances leur permettant d’atteindre des portées allant du mètre à la
centaine de mètres environ.
C’est le groupe de travail Bluetooth SIG (Bluetooth Special Interest Group) qui a élaboré les
spécifications de Bluetooth. Ce groupe de travail, au départ constitué de grosses sociétés de l’infor-
matique et des télécommunications telles qu’IBM, Ericsson, Intel ou Nokia, a rapidement pris de
l’ampleur et regroupe actuellement plus de 2500 sociétés.
Il faut noter que le Bluetooth SIG n’est pas le seul organisme produire des spécifications dans
ce domaine, le groupe de travail 802.15 de l’IEEE complétant et prolongeant ces travaux dans
plusieurs directions :
– Le sous-groupe 802.15.1. Il a pour rôle, en accord avec le Bluetooth SIG, de traduire les
spécifications Bluetooth en spécifications de type 802.
– Le sous-groupe 802.15.2. Il doit étudier les configurations des réseaux personnels et no-
tamment la coexistence de ces réseaux avec les réseaux locaux sans fils (du type de 802.11).
– Le sous-groupe 802.15.3. Il travaille sur les spécifications d’un réseau personnel à haut
débit (de l’ordre de 20 Mbit/s).
– Le sous groupe 802.15.4. Il étudie les spécifications pour des réseaux personnels à bas
débit (de l’ordre de 200 kbit/s).
Les réseaux Bluetooth sont construit de manière centralisée. Un maı̂tre élu peut prendre en
charge jusqu’à huit esclaves et forme ainsi un piconet. Dans un piconet, c’est le maı̂tre qui contrôle
toutes les transmissions. Les esclaves ne peuvent émettre des paquets que s’ils y ont été invités
par le maı̂tre. Ce dernier doit donc les interroger régulièrement pour savoir s’ils ont des données à
envoyer (polling).
Plusieurs piconets peuvent être reliés afin de former une structure plus grande appelée
scatternet (de l’anglais scatter, dispersé). A cette fin, les mobiles peuvent quitter temporairement
leur piconet pour aller s’attacher à 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 dé-association est réversible, il est possible de
quitter temporairement un piconet puis de le rejoindre à nouveau et de revenir à la situation initiale).
L’accès au médium dans Bluetooth est géré par intervalles de temps réguliers (slotted). Le slot
de base a une durée de 625 µs. Au niveau physique, Bluetooth fonctionne par sauts de fréquence
très rapides (jusqu’à 1600 sauts par seconde). La fréquence reste la même pour la durée d’un slot.
En général, sauf si le paquet à transmettre est trop long pour tenir sur un seul slot auquel cas il en
occupe plusieurs, la fréquence change après chaque slot selon un schéma cyclique.
23
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
Là encore nous n’entrerons pas plus en avant dans la description de la norme. Avec ses scatternet,
Bluetooth présente bel et bien une forme de réseau ad hoc multi-sauts. Mais du fait de l’utilisation
ciblée pour un usage personnel, ces réseaux restent assez statiques et leur étendue volontairement
limitée.
2.2 Introduction à 802.11

802.11 [31, 32] est une norme établie par l’IEEE. Elle décrit les couches physique et MAC
d’interfaces réseau radio et infra-rouge. Les débits possibles varient entre 1 et 54 Mbit/s suivant
les techniques et les éventuelles extensions de la norme employées. Les portées prévues varient
entre quelques dizaines et quelques centaines de mètres en fonction de la vitesse choisie et de
l’environnement. Cette norme cible deux contextes d’utilisation :
– Le mode ”infrastructure” (l’utilisation privilégiée de 802.11), où des stations de base
reliées entre elles par un réseau filaire assurent la couverture d’une certaine zone et prennent
en charge les mobiles dans leur voisinage (figure 2.5).
– Le mode appelé ad hoc, qui consiste en fait simplement à autoriser les communications
entre deux mobiles à portée l’un de l’autre, sans intervention de stations ou d’autres mobiles
extérieurs (figure 2.6).
La norme originelle 802.11 date de 1997 et décrit les couches physiques et MAC pour un débit
allant jusqu’à 2 Mbit/s en radio, dans la bande des 900MHz. Des extensions ont été publiées depuis
qui viennent lui ajouter des amé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 débits
pouvant atteindre les 2 Mbit/s. Cette bande de fréquence est partagée avec d’autres types de
réseaux locaux sans fil (Bluetooth en particulier) ainsi que par diverses autres applications.
– 802.11b ajoute la description d’une couche physique améliorée proposant des débits de 5.5
et 11 Mbit/s en plus de ceux déjà supportés.
24
Station Station
de base de base
Fig. 2.5 – Réseau 802.11 en mode infrastruc-

ture Fig. 2.6 – Ré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 définies par 802.11
– 802.11a ajoute des modes encore plus rapides (jusqu’à 54 Mbit/s) en travaillant dans la
bande des 5GHz, mais en utilisant des techniques OFDM (présentées succinctement dans la
section suivante) d’accès au canal.
– 802.11g utilise des technique OFDM similaires 802.11a, mais en restant dans la bande ISM
à 2.4GHz. Les débits possibles atteignent également les 54 Mbit/s tout en gardant la compa-
tibilité avec les équipements 802.11b.
– 802.11e cherche à améliorer 802.11 de façon à pouvoir donner des garanties de qualité de
service. Cette extension de la norme n’est pas encore finalisée.
– 802.11h cherche à mieux gérer la puissance d’émission et la sélection des canaux dans la
bande des 5 GHz suivant si l’on est à l’intérieur ou à l’extérieur de bâtiments. L’objectif est
d’être, à terme, mieux en accord avec les diverses législations (notamment européennes).
– 802.11i cherche à améliorer les mécanismes de sécurité et d’authentification ; ce travail n’est
pas encore finalisé non plus.
Afin de permettre la mise en place de ces différentes améliorations et de présenter aux couches
supérieures une interface très similaire à 802.3 (le célèbre Ethernet), 802.11 propose le modèle en
couches de la figure 2.7. La sous-couche LLC est l’interface ”visible” de 802.11, c’est par son in-
termédiaire que les grandes similitudes avec 802.3 sont possibles. La sous-couche d’accès au médium
(MAC) est spécifique à 802.11, mais reste la même quelles que soient les couches physiques em-
ployées en-dessous. Pour finir, un certain nombre de couches physiques sont définies. Originellement
seules une couche infra-rouge et une couche radio dans la bande des 900MHz étaient définies. La
couche physique radio proposait déjà plusieurs techniques de modulation (FHSS et DSSS, présentées
elles aussi dans la section suivante) à utiliser en fonction du débit désiré (qui pouvait aller jusqu’à
2 Mbit/s). Par la suite d’autres couches physiques améliorées ont été ajoutées. Les plus importantes
de ces couches PHY dans le contexte des réseaux ad hoc seront décrites dans la section suivante.
25
2.3 La couche physique

Initialement, le standard IEEE 802.11 permet l’utilisation de trois couches physiques différentes
(FHSS, DSSS et IR), auxquelles 802.11a a ajouté ODFM :
– FHSS : Frequency Hoping Spread Spectrum. La plupart des interférences nuisibles aux trans-
missions radio n’agissent en fait que sur des bandes de fréquence assez étroites. Si par mal-
chance de telles interférences ont lieu au moment ou l’on transmet, alors notre signal sera
fortement dégradé. Une technique pour protéger notre signal consiste à régulièrement changer
de fréquence (figure 2.8). Bien sûr les paquets envoyés sur la bande perturbée seront affectés,
mais ils ne représenteront plus qu’une minorité des transmissions et leur retransmission sera
moins coûteuse. L’émetteur et le récepteur doivent connaı̂tre à l’avance le séquencement des
sauts de fréquence, mais des informations portées par les paquets permettent à un mobile
s’attachant au réseau de savoir à partir d’un paquet qu’il reçoit où en est le déroulement de
la séquence.
– DSSS : Direct Sequence Spread Spectrum. Toujours pour lutter contre les interférences impor-
tantes mais n’affectant que des plages de fréquences assez étroites, il existe la technique de
l’étalement de spectre. Des manipulations sur le signal vont le faire occuper un spectre plus
large (on le multiplie par une séquence pseudo-aléatoire ayant certaines propriétés d’auto-
correlation). A la réception, une manipulation inverse est effectuée (figure 2.9). Cette tech-
nique est moins sensible aux interférences dues aux fréquences parasites à faible largeur spec-
trale.
– IR : Infra Red. Que l’on ne détaillera pas ici du fait de son absence totale du marché.
– OFDM : Orthogonal Frequency Division Multiplexing. Nous avons déjà mentionné le problème
des chemins multiples : lorsqu’un signal radio est émis, l’onde va se réfracter, se réfléchir et
donc se diviser sur les divers obstacles rencontrés. A l’arrivée plusieurs chemins pourront
avoir été empruntés, et leur temps de parcours n’étant pas forcément les mêmes, les multiples
réfractions / réflexions d’une même onde vont interférer entre elles. Plus la différence de
temps de parcours sera grande vis à vis de la durée de transmission totale du symbole, plus
les chances que des reflexions / réfractions de symboles consécutifs se chevauchent. Pour
augmenter le débit, l’approche traditionnelle consiste à réduire la durée d’un symbole, mais
cela augmente aussi les problèmes de chemin multiple. OFDM propose donc d’utiliser des
symboles plus longs, mais envoyés en parallèle. On peut dire pour résumer succinctement
cette méthode qu’en présence de chemins multiples, à débit total équivalent, l’agrégation d’un
certain nombre de canaux lents donne de meilleurs résultats qu’un seul canal très rapide.
A l’origine, la bande de fréquence utilisée était celle des 900MHz. Les extensions successives ont
ajouté d’autres couches physiques afin de permettre des débits de plus en plus élevés en radio.
802.11 (version de 1999) La version de 1999 de 802.11 a remplacé la bande des 900 MHz par
la bande ISM (2.4 GHz). Dans la bande ISM, 14 canaux radio de 20 MHz de largeur ont été définis.
Suivant les réglementations, ils ne sont pas tous utilisables dans tous les pays (voir table 2.1).
Il n’est possible pour un émetteur ou un récepteur de ne travailler que sur un seul canal à la
fois. Disposer de plusieurs canaux permet donc de les affecter aux stations de base de manière à ce
que deux cellules voisines n’interfèrent pas entre elles (on améliore ainsi la réutilisation spatiale).
Un exemple est donné sur la figure 2.10.
26
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 fréquence

régulièrement pour réduire l’impact Fig. 2.9 – Etaler le spectre pour réduire l’impact de cer-
de certaines interférences taines interférences
Pays (organisme régulateur) Bandes de fré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 à 100 mW, 2.454 - 24835 GHz à 10 mW en extérieur
2400 - 2483.5 Ghz à 100mW en intérieur
Tab. 2.1 – Réglementations de la bande ISM
De plus, il faut préciser que ces canaux ne sont pas tous indépendants les uns des autres. Ils se
chevauchent en partie, comme présenté sur la figure 2.11. Il faut également noter que la bande ISM
tend à être saturée car de nombreux équipements l’utilisent (dont bluetooth, 802.11b et 802.11g).
802.11b 802.11b (qui travaille toujours dans la bande des 2.4GHz) a ajouté une couche DSSS
modifiée (High Rate DSSS) avec une modulation CCK (Complementary Code Keying) et définit
ainsi les vitesses de 5.5 et 11 Mbit/s. Le canaux restent les mêmes et la compatibilité est préservée
avec les modes à 1 et 2 Mbit/s. Afin de garantir l’interopérabilité des matériels 802.11b des différents
constructeurs, la WECA (Wireless Ethernet Compatibility Alliance1 ) a créé le label Wi-Fi. Les
1
www.weca.net
13
1
1 7
13
13 1
Fig. 2.10 – Le réutilisation spatiale grâce à un plan d’allocation des fréquences
27
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 définis par 802.11a
produits estampillés Wi-Fi on été analysés grâce a des tests de compatibilité développés par la
WECA et leur interopérabilité 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 été définis
(voir figure 2.12 pour les 8 premiers, les 4 derniers étant dans les 5.7 GHz). La bande UN-II est
moins encombrée que la bande ISM. L’autre principal utilisateur de la bande UN-II est HiperLan
2, qui n’est pas répandu commercialement. 802.11a autorise des débits allant jusqu’à 54 Mbit/s,
mais cela se fait au détriment de la portée de communication qui n’excède pas quelques dizaines de
mètres aux débits les plus élevés. De façon similaire au label Wi-Fi des produits 802.11b, le label
Wi-Fi5 de la WECA garantit l’interopérabilité des produits 802.11 le portant.
802.11g 802.11g, publiée après 802.11a travaille dans la même bande ISM que 802.11b mais
utilise les mêmes techniques OFDM que 802.11a afin de permettre des débits allant également
jusqu’à 54 Mbit/s. Là aussi, la compatibilité est préservée avec 802.11b. Il faut cependant noter
que les débits maximums ne peuvent être obtenus qu’à courte portée et que si la station de base
et l’ensemble des mobiles de la cellule utilisent 802.11g.
La figure 2.13 récapitule les différentes technologies et dé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 être utilisé par tous
les mobiles, et qui permet un accès équitable au canal radio sans aucune centralisation de la
28
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 – Récapitulatifs des technologies et des débits possibles
gestion de l’accès (mode totalement distribué). Ce mode peut aussi bien être utilisé 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’accès au canal dans leur zone de couverture pour les mobiles qui leur
sont rattachés.
Dans les réseaux ad hoc multi-sauts, il n’y a pas de stations de base fixes et c’est donc le
mode DCF qui sera employé. Le mode DCF va être décrit dans la sous-section suivante. Le mode
PCF sera néanmoins décrit brièvement lui aussi, dans la mesure où les mécanismes qu’il utilise
sont fondamentaux dans 802.11 et que leur compréhension apporte à la compréhension globale du
comportement de 802.11 dans le contexte des réseau ad hoc.
2.4.1 Description du mode DCF

Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA)
Dans le monde filaire, lorsqu’un émetteur envoie un signal sur le câble, il peut y lire en même
temps la valeur qui y est effectivement présente. Si jamais la valeur lue est différente de celle
que l’émetteur écrit, c’est qu’un autre émetteur est actif au même moment et qu’il y a collision.
Cette écoute du signal sur le câble au moment de l’émission est à la base de la méthode d’accès
CSMA/CD bien connue d’Ethernet. CSMA/CD permet de détecter une collision et le cas échéant
de retransmettre le paquet après un temps d’attente aléatoire.
En radio cependant, l’atténuation du signal en fonction de la distance est bien plus importante
que sur un câble. Au niveau d’un émetteur, le signal qu’il envoie va donc être reçu avec une
puissance très supérieure à un signal venant de n’importe quel autre mobile. Par exemple, sur la
figure 2.14 sont schématisées les puissances reçues réciproquement par deux émetteurs A et B. Un
signal émis localement est reçu avec une puissance tellement supérieure aux autres signaux qu’il les
occulte complètement. Du point de vue d’un émetteur, il n’y a donc jamais de collision en radio.
Evidemment le problème se pose au niveau du récepteur, où plusieurs signaux pourraient ainsi être
reçus simultanément avec des puissances comparables. Dans la pratique, des collisions se produisent
effectivement uniquement au niveau des récepteurs.
La première caractéristique de la couche MAC de 802.11 est donc d’utiliser des acquittements
pour détecter ces collisions et permettre la retransmission des paquets qui ont été perdus (en
l’absence d’acquittement, l’émetteur sait qu’il doit retransmettre).
29
Puissance perçue
Emis par A
Emis par B
A B Position
Fig. 2.14 – L’atténuation très rapide des signaux rend la détection de collision impossible
Il faut noter que 802.11 peut envoyer une trame à un récepteur spécifique (unicast) ou la
diffuser (broadcast). Dans le cas de la diffusion, il n’y a pas d’acquittement et des paquets peuvent
être perdus de manière tout à fait silencieuse (ce qui est logique, car chaque mobile ayant reçu le
paquet chercherait à envoyer l’acquittement au même moment et il y aurait une série de collisions
sur les acquittements).
En Ethernet, l’idée est d’observer l’état du canal avant d’émettre. Si le canal est libre, alors nous
pouvons envoyer notre trame (et si à ce moment-là nous détectons une collision, nous ré-émettons
la trame un peu plus tard, après une attente de durée aléatoire). Or nous venons de voir qu’en
radio il n’était pas possible de détecter directement les collisions. Par conséquent, le mécanisme
qui conditionne l’autorisation d’émettre sur le canal doit lui aussi être modifié par rapport à ce
qui se fait en 802.3. En effet, si nous nous contentions d’attendre que la canal devienne libre pour
émettre, alors si plusieurs mobiles étaient en attente d’émission, ils détecteraient tous le canal libre
et émettraient au même moment. Il y aurait collision au récepteur et il faudrait attendre que le
délai imparti pour le retour de l’acquittement soit écoulé pour s’en rendre compte, ceci pourrait
être relativement long.
L’idée retenue pour 802.11 est donc, lorsque le canal devient libre, d’attendre une période de
durée aléatoire supplémentaire appelée backoff avant d’émettre. Ce mécanisme s’applique lorsque
le canal devient libre aussi bien après une de nos propres émissions qu’après toute autre émission.
Ainsi, si plusieurs mobiles veulent émettre, il y a peu de chances pour qu’ils aient choisi la même
durée. Celui qui a choisi le plus petit backoff va commencer à émettre, et les autres vont alors
se rendre compte qu’il y a à nouveau de l’activité sur le canal et vont attendre. La figure 2.15
schématise ce qui se passe lorsque deux mobiles à portée de communication veulent émettre vers
un troisième et que le canal devient libre.
Lorsque le canal devient libre, avant toute chose, il faut qu’il le reste pour une période DIFS
(DCF Inter-Frame Space). Si le canal est resté libre durant toute cette période, alors les mobiles
qui veulent émettre choisissent un backoff aléatoire exprimé en un nombre de time slots d’une durée
fixe de 20 µs. Le backoff est choisit au hasard dans un intervalle appelé Contention Window (CW)
qui est par défaut [0 ;31] ; avec un time slot de 20 µs, le backoff va donc normalement être compris
entre 0 et 620 µs. Dans l’exemple de la figure 2.15, le mobile 1 a tiré 3 et le mobile 2 a tiré 5. Une
fois ce tirage effectué, tant que le canal reste libre, les mobiles décrémentent leur backoff. Dès que
l’un d’eux a terminé (ici le mobile 1), il émet. L’autre mobile, dès qu’il détecte le regain d’activité
sur le canal stoppe la décrémentation de son backoff et entre en période de defering.
30
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 sépare un paquet de données de son acquittement est
appelé SIFS (Short Inter-Frame Space) et qu’il est plus court que DIFS. Le mobile en période de
defering ne pourra reprendre la décrémentation de son backoff que si le canal est à nouveau libre
pendant DIFS. Le fait que SIFS soit plus court empêche que la décrémentation ne reprenne de
manière inopportune entre les données et leur acquittement.
Lorsque les données du mobile 1 ont été acquittées et que DIFS s’est écoulé sans activité sur
le canal, le mobile 2 peut reprendre la décrémentation de son backoff. Ici, aucun autre mobile ne
vient l’empêcher de terminer et il peut donc finalement envoyer ses données.
Le mécanisme de backoff limite les risques de collision mais ne les supprime pas complètement.
Aussi, si une collision se produit quand même (détectée grâce à l’absence d’acquittement), un
nouveau backoff va être tiré au hasard. Mais à chaque collision consécutive, la taille de la fenêtre
va doubler afin de diminuer les chances que de telles collisions se répètent. La borne inférieure de
la Contention Window est toujours zéro, et la borne supérieure (dont les valeurs autorisées par la
norme ne sont que des puissances de 2 moins 1) va évoluer entre les valeurs aCWmin et aCWmax
définies par la norme. La borne supérieure de la fenêtre est ré-initialisée à aCWmin sitôt qu’un
paquet a été transmis correctement (ou lorsque les timers de ré-émission expirent). Un exemple
d’évolution de la fenêtre de contention est donné sur la figure 2.16.
Le mécanisme RTS/CTS
Nous avons vu que le mécanisme CSMA/CA cherche à éviter les collision en écoutant l’activité
sur le canal et en choisissant un délai aléatoire supplémentaire avant l’émission. Mais il existe une
famille de configuration où ce mécanisme est insuffisant. Il s’agit du problème des nœuds cachés
(figure 2.17) où deux émetteurs qui ne peuvent pas du tout s’entendre (en général à cause d’un
obstacle) veulent atteindre un même récepteur. Comme dans cette configuration un émetteur ne
détecte jamais l’activité de l’autre, il croit que le canal est toujours libre et émet dès qu’il a des
données disponibles. Les chances de collisions à répétition au niveau du récepteur sont très élevées.
802.11 propose un mécanisme utilisant des paquets de contrôle appelés Request To Send (RTS)
et Clear To Send (CTS) introduit par [33]. Un mobile qui veut émettre ne va plus directement
envoyer son gros paquet de données, mais plutôt un petit paquet RTS pour lequel les chances
de collision sont plus faibles. A ce paquet RTS, le destinataire va répondre par un petit paquet
31
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 à tout son voisinage. Les paquets RTS et CTS contiennent des informations qui
permettent de réserver le canal pour la durée de transmission des données qui vont suivre. Un
mobile qui reçoit un CTS alors qu’il n’a pas envoyé (ni même détecté de RTS) sait que quelqu’un
d’autre va émettre et doit donc attendre. Le mobile qui a envoyé le RTS sait, quand il reçoit le
CTS correspondant, que le canal a été réservé pour lui et qu’il peut émettre.
Au niveau des mobiles, la réservation du canal est implémentée grâce au Network Allocation
Vector (NAV). Dans chaque nœud, le NAV indique pour combien de temps le canal est utilisé par
quelqu’un d’autre, indépendamment de ce qui est physiquement perçu sur le canal (on parle aussi
de détection de porteuse ’logique’). Sur la figure 2.19 sont présentées les mises à jour du NAV au
niveau d’un mobile alors qu’une trame est échangée entre deux autres mobiles. Lorsque le nœud non
concerné par l’échange reçoit le RTS, il sait grâce aux informations contenues dans ce dernier pour
combien de temps il ne devra pas accéder lui-même au canal. Nous avons vu que dans certaines
configurations (par exemple celle de la figure 2.17), certains paquets ne sont pas reçus par tous
les mobiles potentiellement concernés. Les CTS et les paquets de données vont donc aussi devoir
porter les informations de durée, afin que leur réception puisse mettre le NAV à jour (un exemple
est donné dans la figure 2.18 où seul le CTS est reçu par le mobile de droite).
RTS (1)
CTS (2) CTS (2)
DATA (3)
ACK (4)
A B
Fig. 2.17 – Le problème des nœuds cachés Fig. 2.18 – L’échange RTS/CTS
32
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 mécanisme EIFS
Dans la configuration présentée sur la figure 6.13, le nœud de gauche (”autre”) détecte la
porteuse de l’émetteur sans pour autant comprendre ses messages (le signal est trop faible pour
être décodé, mais suffisamment fort pour être reconnu comme tel). Les paquets envoyés par le
récepteur ne sont quant à eux pas détecté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’éviter une collision
au niveau de l’émetteur au moment du CTS et de l’acquittement par le récepteur. La figure 2.21
détaille ce qui se passe : L’émetteur envoie tout d’abord un paquet de contrôle RTS. Ce paquet
est reçu par le récepteur, qui va y répondre par un CTS. Le mobile de gauche, lui, a détecté de
l’activité au moment du RTS mais sans comprendre le paquet. Le mécanisme de defering présenté
précédemment l’empêche d’émettre pendant l’envoi du RTS (canal occupé) et pendant une période
DIFS consécutive (on est toujours obligé d’attendre que la canal ait été libre pendant DIFS pour
émettre). Mais DIFS est plus court que SIFS+CTS. Si jamais le mobile de gauche avait terminé
de décrémenter son backoff trop vite, il aurait pu émettre pendant le CTS, causant une collision au
niveau de l’émetteur. Pour protéger le CTS (et de maniè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 été compris ; la longueur de EIFS étant suffisante pour que l’envoi du CTS ou de
l’ACK se déroule dans de bonnes conditions.
2.4.2 Description du mode PCF

Nous avons vu que le mode DCF permettait un fonctionnement totalement distribué de l’accès
au médium, mais que, afin de limiter le nombre des collisions, CSMA/CA avait recours à une durée
aléatoire avant l’émission de chaque paquet. Le temps passé à attendre représente autant de débit
effectif perdu. Aussi 802.11 propose en option un mécanisme centralisé qui permet d’obtenir un
meilleur taux d’utilisation du canal. C’est le mode basé sur la Point Coordination Fonction(PCF),
qui requiert l’utilisation de stations de base et de mobiles l’implémentant.
Le principe de base de la PCF est de centraliser la gestion de l’accès au médium d’une cellule.
C’est le point d’accès qui indiquera à chacun des mobiles qui lui sont rattachés quand ils doivent
émettre leurs paquets. Le backoff aléatoire devient ainsi en partie inutile. Durant toute la phase où
33
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 où l’EIFS est Fig. 2.21 – L’Extended Inter Frame Spacing
né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’accès au canal ;
on parle de Contention Free Period.
De plus, afin de préserver la compatibilité, dans chaque cycle de la PCF, une période de DCF
est conservée et permet aux mobiles n’implémentant pas la PCF de continuer à accéder au canal.
C’est la Contention Period (figure 2.22). La cohabitation entre les mobiles implémentant la PCF et
ceux ne l’implémentant pas est assurée grâce au temporisateur PIFS (PCF Inter Frame Spacing).
Durant la période sans contention, les trames ne sont en effet séparées que de périodes PIFS (ou
SIFS suivant les cas) qui sont toutes les deux plus courtes que DIFS. Grâce à ces temporisateurs,
un mobile n’implémentant pas la PCF ne risque donc pas de prendre la main durant la période
gérée par la station de base en mode PCF.
Il faut noter que pour l’instant, très peu de cartes implémentent la PCF (mais en général une
mise à jour du firmware embarqué dans les cartes et les stations de base sera possible).
2.5 La sécurité des informations : la Wired Equivalent Privacy (WEP)

Dans la section consacrée aux problèmes spécifiques des réseaux radio, nous avons signalé la
facilité avec laquelle il est possible pour un tiers d’écouter passivement les communications radio.
Afin de se prémunir contre ces écoutes passives, peu de moyens physiques existent (on peut essen-
tiellement chercher à faire en sorte que les signaux de nos stations de base ne soient reçus avec une
puissance suffisante que dans les zones que l’on contrôle, comme nos bureaux ou les hangars de
notre usine). Mais même un placement spécialement pensé des stations de base est mis en défaut
si ”l’espion” utilise une antenne à fort gain.
Le chiffrement des données est donc nécessaire si l’on recherche une certaine confidentialité.
802.11 décrit de ce fait une méthode de chiffrement : c’est la Wired Equivalent Provacy ou WEP,
qui peut être utilisée de manière optionnelle. Le système repose sur une clef secrète qui doit
être partagée par l’émetteur et le récepteur. La distribution de cette clef est en dehors du cadre
34
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 à des serveurs d’authentification élaborés. Nous ne détaillerons pas ces systèmes qui sortent
également du cadre de ce travail, mais la compréhension du mécanisme de chiffrement aura son
importance, en particulier lorsque nous présenterons plus tard des résultats de mesures de débit réel.
Le principe du WEP est de combiner une séquence pseudo-aléatoire générée à partir de la

clef avec les données. Seul le récepteur qui connaı̂t aussi la clef pourra générer la même séquence
pseudo-aléatoire et décoder le message. La figure 2.23 donne les détails de ce chiffrement :
– Afin de renforcer la clef, on la combine avec un vecteur d’initialisation qui est changé à chaque
paquet. L’idée est d’éviter qu’une même clef soit utilisée souvent, et en particulier plusieurs
fois consécutives.
– La concaténation de la clef et du vecteur d’initialisation sert de graine pour l’algorithme RC4
qui va générer la séquence pseudo-aléatoire de bits.
– D’autre part, un code de redondance cyclique (CRC) est calculé sur les données, et y est
concaténé.
– Un OU exclusif est utilisé pour combiner la séquence pseudo-aléatoire et les données à chiffrer
(c’est le chiffrement proprement dit).
– Le vecteur d’initialisation est concaténé aux données chiffrées et le paquet est envoyé (l’IV
doit être en clair, le récepteur n’a pas de moyen de prévoir quelle sera sa valeur).
A la réception, le mobile connaı̂t déjà la clef secrète. Il lui adjoint le vecteur d’initialisation
qu’il trouve au début du paquet et génère la même séquence pseudo-aléatoire que celle qui a servi à
crypter. Avec un OU exclusif entre les données chiffrées et la séquence pseudo-aléatoire, il obtient
directement les données en clair. La vérification du CRC lui permet d’être sûr qu’aucune erreur ne
s’est produite et que sa clef était la bonne.
Au sujet de RC4, [34] nous apprend que c’est un algorithme basé sur des permutations. Une table
de 256 octets est initialisée avec la clef qui lui est fournie, et les éléments de la table vont ensuite
être permutés les uns les autres en fonction de leur valeur. Cet algorithme est réputé sûr et a en
outre l’avantage d’être très rapide (suivant le micro-processeur, entre 8 et 16 opérations simples sont
nécessaires pour produire un octet pseudo-aléatoire). Ceci est d’ailleurs particulièrement important
car les cartes réseau 802.11 n’embarquent pas en général des processeurs très puissants.
35
)
7 µs
µs)
µs)
µs)
(24.
620
192
1 MBits/s
(771
der
µs)
er (
0à
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 données 802.11 à 11Mbits/s et son acquittement
2.6 Les trames 802.11b et le débit utile 802.11b

Dans la suite de nos travaux, lorsqu’il s’est agit d’effectuer des mesures avec des véritables
cartes, nous avons utilisé 802.11b. Nous détaillons donc ici plus en détail le fonctionnement et la
construction des trames, de manière à pouvoir comparer plus tard les débits pratiques aux débits
théoriques.
Sans détailler le contenu de chaque champ, il est tout de même important de savoir que les
paquets envoyés par 802.11 sur le médium radio comprennent plusieurs niveaux d’encapsulation.
Aux données venant des couches supérieurs, au moment de l’envoi, est ajoutée une en-tête MAC
ainsi qu’une en-tête physique. Les vitesses de transmission pour certaines de ces parties peuvent
varier. L’en-tête physique est envoyée à la vitesse constante de 1 Mbit/s. L’objectif est de permettre
sa ré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-tête MAC et les données sont envoyés à une vitesse négociée qui peut aller jusqu’à 54
Mbit/s avec 802.11g.
Les paquets de contrôle (RTS/CTS/ACK) sont envoyés quand à eux à des vitesses qui peuvent
encore être différentes. La norme indique que ces paquets doivent être envoyés à une vitesse choisie
dans la liste de celles qui vont permettre leur réception par tout autre mobile compatible. Mais
ces vitesses ne sont pas données explicitement. Dans la pratique, la plupart des constructeurs
permettent à leurs paquets de contrôle d’être envoyés à 2 Mbit/s et se replient sur 1 Mbit/s si les
taux d’échec sont trop importants. D’autres cependant proposent de les envoyer jusqu’à 11 Mbit/s,
proposant ainsi des performances supérieures à leurs concurrents lorsque les conditions sont idéales.
Comme les paquets de contrôle, les paquets envoyés en mode diffusion le sont à des vitesses choisies
dans la liste des vitesses ”compatibles”. Par défaut, la diffusion se fera donc à 2 Mbit/s. Il faut
noter enfin que c’est bien l’ensemble des paquets qui sont sujets à cette encapsulation et que même
les paquets de contrôle possèdent une en-tête physique qui est envoyée à 1 Mbit/s.
36
Si l’on décompose complètement l’envoi d’un paquet UDP de 1032 octets de données à 11
Mbits/s (figure 2.24), on observe (en considérant qu’il n’y a pas eu de collision ou de perte de
paquet avant et que le canal vient juste de se libérer) :
- Un temps d’attente fixe DIFS de 50 µs (compté à partir du moment où le canal devient libre)
- Un temps d’attente aléatoire (backoff) d’une durée comprise entre 0 et 31 time-slots de 20 µs
chacun (0 à 620 µs au total donc).
- L’envoi de la trame de données (qui dure ici 987.7 µs) décomposée en :
- L’en-tête physique de la trame, à 1 Mbit/s, qui dure 192 µs.
- L’en-tête MAC de la trame, à 11 Mbit/s, qui dure 24.7 µs.
- Les données proprement dites (ici 1032 octets de données application plus 28 octets
d’en-tête IP) envoyées à 11 Mbits/s, et qui durent 771 µs.
- Un temp d’attente fixe SIFS de 10 µs.
- L’acquittement, décomposé en :
- L’en-tête physique de la trame, à 1 Mbit/s, qui dure 192 µs.
- L’acquittement MAC, à 2 Mbits/s, qui dure 56 µs.
En utilisant ces paramètres, nous avons calculé les débits maximums possibles en fonction de
la taille des paquets. Il faut noter que dans la réalité, les paquets de grande taille peuvent être
fragmentés par les couches supérieures si elle croient avoir affaire à 802.3 (Ethernet, dont la taille
des trames ne dé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 présentent les débits théoriques pour des vitesses
respectives d’émission physique des données de 11, 5.5 et 2 Mbit/s. Il faut noter que les courbes
présentées ont pour but d’être comparées dans la suite du document à des mesures réelles. Le lecteur
intéressé par les débits théoriques de 802.11 les trouvera dans [35] pour ses diverses extensions, mais
sans la prise en compte de la fragmentation cependant.
37
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 – Débits maximums théoriques en fonction de la taille des paquets (à 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
5e+06
4e+06
3e+06
2e+06
1e+06
0
0 500 1000 1500 2000 2500 3000
Fig. 2.26 – Débits maximums théoriques en fonction de la taille des paquets (à 5.5 Mbit/s)
38
8e+06
2 Mbit/s
2 Mbit/s, fragmentation
7e+06 2 Mbit/s, RTS
2 Mbit/s, RTS, fragmentation
6e+06
5e+06
4e+06
3e+06
2e+06
1e+06
0
0 500 1000 1500 2000 2500 3000
Fig. 2.27 – Débits maximums théoriques en fonction de la taille des paquets (à 2 Mbit/s)
39
CHAPITRE
Particularités de 802.11 dans
3 un contexte ad hoc
3.1 Introduction
802.11 a été conçu dans l’optique de réseaux d’entreprises ou de hot spots organisés autour de
stations de base. Nous avons vu que de part son faible coût, sa disponibilité (aussi bien commerciale
que dans les simulateurs) et par sa possibilité à être utilisé pour des réseaux multi-sauts par la simple
adjonction de protocoles de routage de niveau supérieur, 802.11 est devenu le support privilégié
pour l’étude des réseaux ad hoc. Mais un certain nombre de problèmes apparaissent, qui peuvent
être regroupés en plusieurs catégories :
– Des problèmes de topologie radio. Ils apparaissent lorsque les mobiles sont placés dans
des configurations bien spécifiques (des mobiles ne pouvant communiquer qu’avec certains de
leurs voisins, ou encore ne détectant les porteuses que de certains autres). Ces problèmes sont
connus depuis longtemps dans le contexte des réseaux à stations de base. 802.11 intègre des
solutions pour certains (les nœuds cachés) et en laisse d’autres de côté (les nœuds exposés
par exemple). Mais lors du passage à des réseaux multi-sauts, ces problèmes dévoilent de
nouvelles facettes qu’il est nécessaire de prendre en considération.
– Des problèmes liés aux dé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 tolérantes aux perturbations radio et permettent une meilleure portée).
Le fait de pouvoir utiliser plusieurs vitesses différentes va avoir des répercussions dans un
réseau ad hoc. D’une part en terme de débit, puisque des problèmes déjà connus dans les
réseaux à stations de base risquent d’y être magnifiés. Et d’autre part en terme de connec-
tivité, en particulier lorsque les protocoles de routage utilisent des paquets ayant une plus
grande portée que les données qui doivent être envoyées ensuite.
– Des problèmes d’équité entre des flux multiples et de débit total dans le réseau.
802.11 étant prévu pour fonctionner dans des configurations où la plupart des mobiles sont à
portée les uns des autres (ou dans le pire des cas voisins à deux sauts), ses performances dans
des configurations multi-sauts sont nettement en deçà des optimums théoriques, en terme de
débit et d’équité d’accès au canal.
3.2 Le problème des nœuds cachés

Le problème des nœuds cachés a été introduit dans le chapitre 2 en même temps que le
mécanisme RTS/CTS utilisé pour le corriger. Il faut cependant bien noter que dans le cadre prévu
par 802.11, ce problème n’apparaı̂t que dans une configuration comme celle de la figure 3.1, où deux
mobiles isolés l’un de l’autre, utilisant une même fréquence et attachés à une même station de base
40
CHAPITRE 3. PARTICULARITÉS DE 802.11 DANS UN CONTEXTE AD HOC
A B H
A B
Fig. 3.1 – Noeuds cachés simples C F G
ACK
A B C D E
D E
Fig. 3.2 – Noeuds cachés dans une chaı̂ne Fig. 3.3 – Multiples nœuds cachés
veulent émettre vers cette dernière en même temps. Dans ce contexte, le mécanisme de RTS/CTS
est effectivement efficace. Pour peu que la charge du réseau soit importante, [36, 37] ont montré par
le calcul et des simulations que le surcoût en terme de débit des RTS/CTS est plus que compensé
par le gain qu’il procure en évitant des collisions à répétition.
Dans un réseau ad hoc basé sur 802.11, nous avons vu que tous les mobiles devront travailler
sur la même fréquence s’ils veulent permettre une connectivité complète du réseau. De ce fait, les
situations de nœuds cachés vont être beaucoup plus nombreuses et plus fréquentes. La figure 3.2
donne un exemple de chaı̂ne à quatre sauts. A l’instant considéré, les mobiles B et D, qui ne s’en-
tendent pas du tout, veulent é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 détection de porteuse étant parfaitement circulaires et d’un rayon double de la zone
de communication, B se trouverait dans la zone de détection de porteuse de D et réciproquement.
Mais dans la réalité, l’expérience a montré que ce type de collision était tout à fait possible, nous
le verrons d’ailleurs par la suite. La figure 3.3 quant à elle, présente une configuration encore plus
complexe. Là encore, de nombreuses situations de collisions se présentent, du fait de l’utilisation par
tous les nœuds d’une seule et même fréquence. Le communications désirées sont (A→B), (D→E),
(C→F) et (H→G). Si ces transmissions avaient lieu en même temps, des collisions entre les données
pourraient se produire en B et en E, et, suivant la longueur des paquets, l’acquittement renvoyé par
F pourrait provoquer une collision en G avec les données venant de H. Ces constatations tendraient
à nous faire penser que l’utilisation des RTS/CTS serait la solution à ces problèmes. Malheureu-
sement les RTS/CTS sont aussi sujets à problèmes dans les ré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 reçus avec
une puissance suffisante en C pour être compris, alors C pourra émettre et éventuellement causer
des collisions en B et en E). D’autres configurations spécifiques posant problème sont également
décrites et analysées plus en détail dans [38] ou encore dans [39]. Nous verrons par ailleurs dans
nos propres simulations et expériences des situations où les RTS/CTS sont mis en défaut, lorsqu’ils
ne peuvent être compris correctement.
41
A B C D
Fig. 3.4 – Le phénomène des nœuds exposés
Zone de communication à 11 Mbit/s
Zone de communication à 2 Mbit/s
Fig. 3.5 – Le phénomène de la zone grise
3.3 Le problème des nœuds exposés

Le problème des nœuds exposés apparaı̂t dans des configurations comme celle présentée sur
la figure 3.4. Ici, les nœuds B et C voudraient émettre respectivement vers A et D. En suivant le
mécanisme de la DCF, celui qui a tiré le plus petit backoff va accéder au canal et envoyer son paquet,
alors que l’autre détectera la porteuse du premier, et entrera en période de defering. Pourtant, si
B et C émettaient en même temps, le signal de B au niveau de A serait largement supérieur à celui
de C et suffisant pour une réception correcte. La situation serait l’inverse au niveau du nœud D,
qui recevrait correctement le paquet de C, malgré le léger bruit venant de B. Dans cette situation,
la DCF limite donc inutilement la bande passante totale du réseau. On peut noter que certains
travaux s’intéressent au problème, notamment [40] qui propose l’utilisation d’un mécanisme de
parallel RTS pour le résoudre en partie.
3.4 Le problè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 envoyés en unicast peuvent l’être jusqu’à 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 diffusés par exemple). Ces paquets sont donc émis
à 2 Mbit/s et permettent de construire un certain nombre de routes dans le réseau. Mais lorsque
les données sont ensuite envoyées à 11 Mbit/s sur ces routes, comme la portée de communication
décroı̂t avec l’augmentation de la vitesse, il est possible que des mobiles pourtant à portée des
paquets de routage lents soient trop loin pour les paquets de données rapides. Il en découle que
les routes construites avec les paquets diffusés ne sont pas forcément exploitables à des débits plus
42
élevés. La zone concernée (la soustraction de la zone ”rapide” à la zone ”lente” plus large) est
appelée ”zone grise” et ce problème avait été relevé théoriquement et expérimentalement dans [41].
3.5 Partage du canal entre des flux à vitesses différentes

En sus du phénomène des zones grises, l’utilisation des débits multiples que propose 802.11
conduit à d’autres problèmes. Lorsque des mobiles implémentant 802.11 rencontre de forts taux de
perte, la norme leur recommande de réduire leur vitesse d’émission (plus la vitesse est basse, plus
le signal est résistant aux interférences et est compréhensible loin de l’émetteur). Mais, comme il
l’est montré en détail dans [42], la méthode DCF d’accès au médium ne cherche pas à équilibrer les
débits de plusieurs flux en contention, mais plutôt à donner à chaque paquet des chances équitables
d’être envoyé. Lorsque certains paquets sont envoyés à des vitesses élevées et d’autres à des vitesses
lentes, cela va se traduire par une alternance plus ou moins régulière entre eux. Les mobiles émettant
leurs paquets très lentement vont donc ”capturer” le canal pendant la majorité du temps et faire
chuter le débit des autres mobiles qui ne prennent pourtant pas beaucoup de temps pour émettre
leurs propres paquets. Ainsi, dans un environnement de compétition entre plusieurs mobiles, si l’un
d’entre eux émet à 1 Mbit/s, même si tous les autres travaillent à 11 Mbit/s, leurs débit utile sera
très bas. Dans un environnement ad hoc, du fait du mécanisme de routage qui utilise en général les
paquets diffusés à 2 Mbit/s (comme noté au paragraphe 3.4), beaucoup de liens ainsi découverts
ne supporteront pas des débits élevées (5.5 ou 11 Mbit/s) et s’en tiendront au débit réduit de
2 Mbit/s. Les trafics sur les liens où le 11 Mbit/s est possible seront donc le plus souvent affectés
considérablement par ces autres liens plus lents.
3.6 TCP et 802.11

TCP est un protocole extrêmement utilisé dans le monde filaire. Afin de pouvoir utiliser direc-
tement dans les réseaux ad hoc les innombrables applications qui sont basées sur TCP, il faut que
les performances de ce dernier dans ce contexte soient suffisantes. Un certain nombres d’études ont
été conduites sur le comportement de TCP lorsqu’il est utilisé au-dessus de 802.11 [43, 10, 44] et
des problèmes conséquents sont apparus. Les auteurs de ces articles se sont intéressés à des confi-
gurations ad hoc diverses, parmi lesquelles la chaı̂ne se trouvaient à chaque fois. Ils ont utilisé des
simulateurs (Network Simulator 2 et Glomosim) et ont constaté les problèmes suivants :
– L’instabilité des connexions. Les flux TCP sont très souvent stoppés, et doivent reprendre
à chaque fois en passant par la phase de démarrage lent. Ces interruptions sont dues à la
détection de cassure de liens au niveaux MAC. Il a été montré que la taille de la fenêtre TCP
avait un impact très important sur ce problème, mais qu’il prend véritablement racine dans
la couche d’accès au médium.
– L’inégalité 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 complètement stoppés ou presque.
Malheureusement, bien qu’elles aient soulevé certains problèmes, ces études sont basées sur certaines
configurations où l’analyse des phénomè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 problèmes
peuvent encore être classés en plusieurs catégories, la couche physique elle-même joue un rôle dans
43
certains d’entre eux et en environnement réel, certains autres vont encore apparaı̂tre qui avaient
été totalement omis dans ces études.
3.7 Capacité théorique en fonction la topologie (grille, chaı̂ne)

Certains travaux se sont attachés à évaluer la capacité théorique (en terme de bande passante)
des réseaux ad hoc basés sur 802.11. [45] s’intéresse au trafic dans des topologies régulières (chaı̂ne
et grille de nœuds). Au travers de simulations, les auteurs montrent que 802.11 peine à offrir une
bande passante optimale dans ce type de configuration. Le premier nœud de la chaı̂ne cherche à
envoyer autant de paquets que possible (sa file d’attente est pleine en permanence). Les nœuds
situés plus loin sur la chaı̂ne ne peuvent envoyer des paquets que s’ils en ont préalablement reçu.
De plus, les premier nœuds (et en particulier le tout premier) ont moins de voisins avec qui entrer en
contention que ceux situés plus loin. Il en ré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 façon pas
tous retransmettre du fait de la haute contention qu’ils recontrent. Dans ces conditions d’inégalité
de contention et de trafics offerts, la couche MAC de 802.11 ne peut pas produire l’ordonnancement
qui aurait donné le meilleur débit total.
Dans l’étude de la grille, le problème et confirmé. Il y apparaı̂t d’autre part que les schémas des
trafics vont avoir eux aussi un grand impact sur les performances globales (si les flux sont éloignés
les uns des autres, s’ils se croisent, etc.). A ce niveau, le type d’application va être très important,
tout comme les protocoles de routage utilisés.
Si les auteurs de [45] apportent une explication intéressante sur les faibles débits obtenus dans
des configurations régulières comme la chaı̂ne ou la grille, nous proposons néanmoins dans le cha-
pitre 4 notre propre évaluation et analyse de 802.11 dans une chaı̂ne de mobiles. Ce travail qui
aurait pu paraı̂tre redondant nous a en fait semblé nécessaire pour plusieurs raisons :
– Les mesures de base de 802.11 proposées dans [45] n’étaient pas cohérentes avec celles que
vous avions obtenues, et certains arguments avancés nous semblaient en contradiction avec
nos propres connaissances de NS2.
– Les outils avancés d’analyse que nous avions mis en place permettaient une évaluation plus
poussée que celle proposée dans [45].
3.8 Equité
Plusieurs travaux ont mis en lumière certains problèmes d’équité dans l’accès au médium radio
qui pouvaient survenir avec l’utilisation de 802.11. Le protocole MACAW [46], un des ancêtres
de 802.11 publié en 1994 (et qui avait d’ailleurs introduit l’utilisation des acquittements), avait
déjà remarqué le problème. Il proposait en particulier un mécanisme pour résoudre l’inégalité entre
mobiles qui provenait de l’utilisation du principe de Binary exponential Backoff dans l’ajustement
de la fenêtre de contention.
Dans [47], les auteurs présentent trois scénarios qui montrent une inégalité dans l’accès au
médium radio avec 802.11. Ils s’intéressent à l’inégalité par nœud ainsi qu’à l’inégalité par flux.
Ils expliquent que cette inégalité provient d’une asymétrie des zones de contention de mobiles. Si
intuitivement on sent bien que cette asymétrie va gêner fortement les mobiles connaissant le plus de
contention, les auteurs ne donnent pas d’explications détaillées du dysfonctionnement de 802.11 face
à cette asymétrie. En plus des problèmes d’asymétrie mentionnés par [47], les travaux de Bensaou
44
et al. [38, 48] soulèvent un problème d’inégalité provenant de collisions répétées dans le cadre de
réseaux ad hoc particuliers.
3.9 Conclusion et positionnement

Cet état de l’art montre qu’un certain nombre de problèmes ont été mis en évidence avec
l’utilisation de 802.11 dans les réseaux ad hoc. Certains travaux ont été réalisés avant ma thèse (les
plus anciens vraiment spécifiques à ce contexte datant de 1999, les autres ayant été publiés au cours
de ma thèse, celle-ci ayant commencé en 2000). Chacun de ces travaux soulève une problématique
bien particulière mais aucun ne propose une analyse complète de 802.11 dans un cadre ad hoc.
Enfin, la majorité de ces travaux se basent sur des résultats de simulation (hormis [41, 42] qui
réalisent quelques expérimentations).
Dans cette thèse, nous avons essayé de mener un travail complet sur les performances de 802.11
dans les réseaux ad hoc. Nous avons tenté de dégager les scénarios de base qui permettent de
lister les différents problèmes soulevés et d’y apporter des explications ciblées. Grâce à ces simula-
tions, certains des phénomènes observés dans la littérature ont été retrouvés, tandis que d’autres
caractéristiques ont été dégagées.
Enfin, contrairement aux travaux existants, un long travail d’expérimentations de 802.11 dans un
contexte ad hoc a été réalisé au cours de cette thèse. Ce travail a permis d’une part de connaı̂tre les
performances réelles de 802.11, et d’autre part d’éclairer les problématiques sous un angle nouveau.
45
Première partie
Simulations logicielles de réseaux

ad-hoc
46
CHAPITRE
Simulations : introduction et
4 scénarios de prise en main
4.1 Introduction
La communauté ad-hoc concentre une grande part de son attention sur les protocoles de routage.
Cela était d’autant plus vrai au moment du début de ma thèse, alors que le groupe MANET de
l’IETF voyaient de nombreux nouveaux protocoles présentés, et qu’aucun d’entre eux n’était assez
stabilisé pour envisager une normalisation. Pour développer, tester et valider ces algorithmes, les
chercheurs se sont très rapidement tournés vers les simulateurs. Ceci est en premier lieu du à des
raisons pratiques. Il est peu commode de déployer un protocole sur un réseau réel composé d’un
certain nombre de machines (en particulier dans une configuration multi-sauts), de faire quelques
essais, puis de recommencer en changeant quelques paramètres ou quelques morceaux de code. De
plus, peu de laboratoires disposaient du matériel nécessaire (problème de coût et de logistique ...
et si l’on veut tester des scénarios présentant de la mobilité, de la ”main d’œuvre” est nécessaire).
Lorsque nous avons commencé ces travaux, notre laboratoire ne disposait d’aucun équipement
radio. C’est donc très logiquement que nous nous sommes nous aussi tournés vers la simulation.
4.2 Objectifs initiaux des simulations

Dans la seconde moitié des années 90, avec l’élaboration de plusieurs normes pour les réseaux
sans fils à portée limitée (visant des usages à l’échelle du bureau ou du bâtiment), un certain
nombre de simulateurs ont été développé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 réseaux le plus utilisé par la communauté ad-hoc. Il est
gratuit et son code source est disponible ; autant d’avantages qui font qu’il est largement mis à
contribution par les chercheurs désireux d’évaluer les performances des protocoles de routage qu’ils
développent. Lorsque nous avons commencé à vouloir tester des heuristiques et divers algorithmes
se rapportant aux réseaux ad-hoc, c’est donc logiquement vers NS2 que nous nous sommes tournés.
L’installation ainsi que la prise en main du logiciel et des outils l’accompagnant a été relativement
aisée ; une fois la décision prise d’effectuer des simulations, nous avons donc pu rapidement nous
lancer dans nos premières simulations.
Dans un premier temps, et puisque que nous n’étions pas du tout familiers des réseaux sans
fils, ces simulations ont consisté en des scénarios simples, permettant de se faire une idée des
comportements de base des mobiles utilisant 802.11. Nous nous sommes par exemple intéressés
aux différents modèles de propagation disponibles ou aux débits et distances de communication
maximum.
47
CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCÉNARIOS DE PRISE EN MAIN
Après cette étape de prise en main, nous nous sommes intéressés plus spécifiquement à des
scénarios typiques des réseaux ad-hoc (communication nécessitants plusieurs ”sauts” et problèmes
d’interférences).
Dans de nombreux articles ([53, 54, 55]) dont l’objectif est de vérifier que les protocoles de
routage arrivent bien à construire et maintenir les routes, les flux de données sont très faibles (en
général moins de 8 ou 10 paquets par seconde et par source, envoyés à une vitesse constante).
Dans ces articles, les modèles de mobilité jouent également un rôle très importants. Le Random
Waypoint, utilisé pour la première fois dans [56] puis plus tard raffiné dans [54] est certainement le
plus utilisé. Il consiste en :
– Le placement d’un certain nombre de mobiles (typiquement 50 à 100) dans une zone carrée
de laquelle ils ne peuvent sortir.
– L’affectation d’une position, d’une vitesse et d’une destination initiale à chaque mobile.
– La sélection aléatoire des émetteurs et de la destination de leurs paquets.
– Le déroulement proprement dit de la simulation, où à chaque fois que les mobiles atteignent
leur destination dans le carré, ils repartent vers une autre destination choisie aléatoirement
après un éventuel temps de pause.
Il faut noter que ce modèle assez simple a été sujet à critiques, notamment dans [57] où l’instabilité
et la diminution progressive de la vitesse moyenne des mobiles en fonction du temps de simulation
est mise en lumière. Comme la destination et la vitesse sont choisis aléatoirement, des mobiles vont
parfois choisir des destination lointaines et des vitesses très lentes, et il leur faudra énormément
de temps pour y arriver. Plus la simulation sera longue, plus le nombre de mobiles ”coincés” dans
cette situation va augmenter, et la proportion de mobiles ”lents” va croı̂tre de façon gênante.
Quoiqu’il en soit, il est clair que les performances de chaque protocole de routage dépendent
beaucoup des conditions d’utilisation (certains sont conçus pour fonctionner dans des petits réseaux
à forte mobilité, d’autres dans de grands réseaux, etc.). Pour pouvoir construire des modèles de
mobilité vraiment pertinents, il faudrait idéalement pouvoir disposer d’informations sur le contexte
dans lequel le réseau ad hoc sera réellement déployé , et ceci est généralement impossible.
Mais contrairement à ce que l’on rencontre en général dans la littérature, nous avons cherché
à voir ce qui se produisait quand le réseau arrivait à saturation. Nous ne cherchions pas à tester
les algorithmes de tel ou tel protocole de routage, nous voulions plutôt savoir ce qui se passerait
(en terme de débit, de connectivité et de délais) quand des flux très importants sont présents
entres certains mobiles dans un réseau ad-hoc. Ceci était motivé par l’idée que dans de nombreuses
circonstances, le trafic s’effectue plutôt par rafale (comme par exemple la navigation web, le transfert
de fichiers ou même la consultation d’e-mails). Dans nos scénarios, nous avons donc en général utilisé
des flux cherchant à occuper complètement la bande passante. Ces conditions de saturation sont
un élément important de nos travaux et les différencie d’une grande majorité de ceux effectués
précédemment et qui n’utilisaient que des flux très peu gourmands.
4.3 Présentation de Network Simulator 2

NS2 est un simulateur à événements discrets développé dans un but de recherche [58]. Il fournit
un environnement assez détaillé permettant entre autre de ré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 été originellement développé en tant que variante du ”REAL network
simulator” en 1989, et a considérablement évolué au cours des années. En 1995, NS2 était développé
48
par le projet VINT. Actuellement, son développement est supporté par le DARPA à travers SAMAN
et par la NSF à travers CONSER, tout en incluant de nombreuses contributions extérieures, comme
en particulier les codes pour les réseaux sans fils des projets Daedalus de l’UCB et Monarch de la
CMU et de Sun Microsystems.
NS2 est écrit en C++ et en oTCL, et il est fourni avec divers outils d’analyse complémentaires
eux-mêmes écrits en C/C++ ou TCL/Tk.
NS2 implémente la version de 1997 de la norme 802.11. A ce titre, le débit maximum possible
est de 2 Mbit/s. Il faut noter également que ce logiciel est développé, corrigé et étendu au fur et
à mesure de l’apparition de nouveaux besoins (ou de la découverte d’erreurs). Ainsi, au cours du
déroulement de cette thèse, plusieurs versions se sont succédées, apportant leurs lots de corrections
et améliorations diverses.
Compte tenu de nos objectifs, nous avons bien sûr essentiellement mis à contribution la partie
IP/UDP/TCP en environnement sans fil. NS permet de positionner sur un plan virtuel des mobiles
équipés d’émetteurs radio, et il gère la mobilité de ces nœuds dans le temps. Pour qu’un paquet
émis sur une interface sans fil sous NS2 soit reçu, il faut qu’il arrive au destinataire avec un niveau
de signal supérieur à un certain seuil. Ce seuil est par défaut de 3.652 × 10−10 W, et nous l’avons
laissé à cette valeur pour toutes les simulations qui seront présentées par la suite.
4.3.1 Les différents modèles de propagation radio sous NS2

NS2 permet également de choisir parmi les modèles de propagation suivants, qui influeront en
particulier sur la manière dont seront atténués les signaux en fonction de la distance :
– Free space model : Ce modèle considère le cas idéal où il y a un seul chemin de propagation
entre l’émetteur et le récepteur et qu’il est en vue directe. H.T. Friis a présenté dans [59]
l’équation suivante pour calculer la puissance du signal reçu en environnement libre à une
distance d de l’émetteur.
Pt Gt Gr λ2
Pr (d) = (4.1)
(4π)2 d2 L
où Pt est la puissance d’émission, Gt et Gr les gains respectifs des antennes de l’émetteur
et du récepteur. L (avec L ≥ 1) est la perte du système, et λ est la longueur d’onde. Dans
nos simulations avec NS, nous prendrons toujours Gt = Gr = 1 et L = 1. Ce modèle de
propagation représente les zones de communication comme un cercle autour de l’émetteur.
Si un récepteur est dans ce cercle il reçoit tous les paquets, s’il est en dehors il n’en reçoit
aucun.
– Two-ray ground reflection model : En environnement réel, il est en fait peu probable
que le seul chemin de propagation soit le chemin direct. Le modèle two-ray ground considère
donc à la fois le chemin direct et une réflexion sur le sol. Comme il est montré dans [60], ce
modèle donne des résultats plus justes que le modèle de propagation en espace libre quand
la distance est assez grande. La puissance reçue à une distance d est calculée de la manière
suivante :
Pt G t G r h t 2 h r 2
Pr (d) = (4.2)
d4 L
où ht et hr sont les hauteurs des antennes de transmission et de réception. Notez que l’équation
originelle dans [60] considère que L = 1. Afin que NS soit cohérent avec le modèle de propa-
gation en espace libre, L a été ajouté à l’équation.
49
Environnement β
En extérieur Espace libre 2
Zone urbaine obstruée 2.7 à 5
En intérieur En ligne de vue 1.6 à 1.8
Obstrué 4 à 6
Tab. 4.1 – Quelques valeurs typiques pour l’exposant d’atténuation β
L’équation précédente présente une décroissance de la puissance reçue en fonction de la dis-

tance plus rapide que l’équation (4.1). Cependant, pour des distances courtes, le modèle à
deux rayons ne donne pas de bons résultats (en raison d’oscillations causées par la combinai-
son constructive et destructive des deux rayons). Le modèle de propagation en espace libre
est donc utilisé à la place de celui-ci quand d est suffisamment petit.
Pour ce modèle, nous avons donc besoin de calculer une distance seuil dc . Quand d < dc ,
l’équation (4.1) est utilisée, et quand d > dc , on prend l’équation (4.2). A la distance seuil,
les équations (4.1) et (4.2) doivent donner les mêmes résultats ; la distance seuil dc peut donc
être calculée de la manière suivante :
4πht hr
dc = (4.3)
λ
– Shadowing model : Les modèles de propagation en espace libre ou utilisant deux rayons
calculent de manière déterministe la puissance reçue en fonction de la distance. Ils représentent
tous deux la zone de communication comme un cercle idéal. Dans la réalité, la puissance reçue
à une certaine distance varie de manière aléatoire, à cause des effets de propagation par des
chemins multiples. En fait, les deux modèles précédents calculent la puissance moyenne reçue
à une distance d. Le shadowing model est un modèle de propagation plus généraliste présenté
dans [60] et implanté dans NS2.
Le modèle ”shadowing” est composé de deux parties. La première est le modèle d’atténuation
en fonction de la distance, qui calcule la puissance moyenne reçue à une distance d, notée
Pr (d). Il utilise une distance courte comme référence, notée d0 . Pr (d) est calculée relativement
à Pr (d0 ) de la manière suivante :
β
Pr (d0 ) d

= (4.4)
Pr (d) d0
β est appelé l’exposant d’atténuation en fonction de la distance, et est généralement déterminé
de façon empirique par des mesures en environnement réel. D’après l’équation (4.1), on sait
qu’en espace libre β = 2. La table 4.1 donne quelques valeurs typiques de β. Les grandes
valeurs correspondent à une obstruction plus forte et donc à une décroissance plus rapide de
la puissance reçue en fonction de la distance. Pr (d0 ) peut être calculée à partir de l’équation
(4.1), en prenant par exemple d0 = 1 mètre.
L’atténuation en fonction de la distance est souvent mesurée en dB. A partir de l’équation
(4.4) nous avons
" #
Pr (d) d

= −10β log (4.5)
Pr (d0 ) dB
d0
50
Environnement σdB (dB)

En extérieur 4 à 12
Bureaux, séparations légère 7
Bureaux, murs 9.6
Usine, en ligne de vue 3 à 6
Usine, obstruée 6.8
Tab. 4.2 – Quelques valeurs typiques pour la déviation du shadowing σdB
La seconde partie du modèle shadowing reflète les variations de la puissance reçue à une
distance donnée. C’est une variable suivant une loi log-normale, c’est à dire dont la distribution
mesurée en dB est gaussienne. L’ensemble du modèle shadowing est représenté par
" #
Pr (d) d

= −10β log + XdB (4.6)
Pr (d0 ) dB
d0
où XdB est la variable aléatoire gaussienne dont la moyenne est zéro et l’écart type σdB . σdB
est appelé shadowing deviation, et est également obtenue par des mesures en environnement
réel. La table 4.2 donne quelques valeurs typiques pour σdB . L’équation (4.6) est aussi connue
sous le nom de log-normal shadowing model.
Le shadowing model étend le cercle idéal de communication à un modèle statistique plus riche ;
les nœuds ne peuvent communiquer qu’avec une certaine probabilité lorsqu’ils sont vers la
limite de portée.
4.3.2 La gestion des interférences

Le terme ”interférences” est souvent utilisé de façon générique, et recouvre en fait plusieurs
phénomènes qu’il est important de différencier. Avant tout, les conditions suivantes doivent être
remplies pour qu’un paquet puisse être reçu :
– La puissance du signal reçu doit dépasser un certain seuil (seuil de communication).
– Le rapport signal sur bruit ambiant doit être suffisamment grand (le signal doit être clairement
identifié, et non noyé dans le bruit).
Il existe un seuil de dé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’activité sur le canal est
néanmoins détectée. Si l’on utilise le modèle two-ray ground (ou le modèle free-space), ces seuils
définissent donc deux zones autour d’un nœud. Si le récepteur est placé au centre de la figure 4.1,
alors un émetteur placé dans la zone interne (zone de communication) pourra lui envoyer des mes-
sages qui seront compris (en l’absence d’autres interférences). Si l’émetteur est placé dans la zone
externe (zone de détection de porteuse), la communication ne sera pas possible mais l’autre mobile
sera informé à chaque fois que l’émetteur accédera au canal. Si l’on utilise le modèle shadowing,
les deux zones sont également définies, mais leurs frontières sont ”floues” du fait du caractère
probabiliste du modèle. 802.11 impose qu’un mobile qui veut é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’émetteur est suffisamment proche (c’est à dire dans la zone de communication)
du mobile qui voudrait lui aussi émettre, alors ce dernier a reçu l’en-tête du message et sait donc
(par l’intermédiaire de son Network Allocation Vector) pour combien de temps le canal doit encore
être occupé. Le nœud qui voulait émettre va donc attendre. Par contre, si le mobile qui veut
51
Zone de communication
Zone de détection de porteuse
Fig. 4.1 – Portée de communication et de détection de porteuse
aussi émettre est plus loin (dans la zone de détection de porteuse de l’émetteur) l’en-tête n’a pas
pu être comprise. Il est impossible dans ce cas de prévoir à l’avance quand on aura à nouveau
le droit d’émettre, il faut attendre que l’activité sur le canal disparaisse. Dans ces contextes,
les différents nœuds se gênent les uns les autres, et cela se traduit par un partage du canal entre eux.
Une fois ces précisions données, les différents facteurs à prendre en compte pour les interférences
sont :
– L’atté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’atténuation qui donne sa forme circulaire
à la zone de couverture de la figure 4.1. C’est ce que fait NS2 (avec éventuellement un facteur
aléatoire supplémentaire dans le modèle shadowing).
– Le bruit ambiant est normalement la somme de tous les bruits perçus au niveau du
récepteur. Ce bruit de fond provient de l’environnement (passage de véhicules motorisés,
appareils bruiteurs divers, ...), mais aussi des autres mobiles du réseau. Sous NS2 il n’y a pas
de bruit de fond provenant de l’environnement, le signal reçu de l’émetteur est simplement
comparé à tour de rôle à chacune des autres sources du réseau actives à ce moment là. Ceci est
une limitation de NS2, car suivant les conditions, il se peut qu’aucune de ces sources de bruit
ne soit suffisante pour gêner la communication de manière indépendante, mais que leur somme
le soit. D’un manière générale, NS calcule donc une approximation du bruit qui est inférieure
à ce qu’elle devrait être. Il faut bien garder à l’esprit que si des problèmes d’interférences ap-
paraissent dans certains scénarios, l’impact de ces interférences en environnement réel serait
encore supérieur.
4.4 Traitements des résultats et outils d’analyse

NS2 écrit les résultats de ses simulations dans un fichier texte où chaque ligne correspond à
un événement qui s’est produit à un niveau ou à 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’événements (par
exemple tout ce qui concerne le routage, mais pas ce qui concerne la couche MAC). Ceci est en
particulier utilisé pour accélérer la simulation et réduire la taille du fichier.
Ce fichier texte peut porter en lui-même énormément d’informations. Mais pour extraire et
représenter de manière synthétique ces informations, il faut souvent appliquer de nombreux traite-
52
O 2
1 3
Fig. 4.2 – Scénario d’exemple pour le chronogramme
ments à ce fichier. Par exemple, si l’on veut calculer un débit sur un lien, il faut compter le nombre
de paquets transmis durant une certaine période entre certains nœuds et tenir compte de leur taille.
Comme l’ensemble des événements qui se sont produits se trouvent dans ce fichier et qu’ils ne sont
classés que par ordre chronologique, ceci peut se révéler pour le moins laborieux.
Ainsi, pour calculer les débits, on préfère plutôt agir au niveau du script TCL décrivant le
scénario. Certains objets utilisés dans les simulations sont capables de comptabiliser les paquets ou
les octets qui les traversent (comme ceux qui servent de récepteurs pour les flux TCP par exemple).
Ces informations peuvent être récupérées au niveau du script TCL, qui se charge alors de les écrire
dans un fichier.
Bien que ces deux techniques permettent déjà de récupérer énormément d’informations, ceci
n’a pas toujours été suffisant pour nos besoins. Comme nous cherchons à savoir ce qui se passe
aux niveaux MAC et physique, nous avions besoin en particulier de plus de détails que la simple
connaissance de l’échec ou de la réussite de la transmission d’un paquet au niveau MAC. Nous avons
donc ajouté du code dans NS2 qui nous permet, pour chaque nœud, de connaitre les moments où
il est en train :
– D’émettre sur le canal (toutes les émissions, les RTS/CTS et les acquittements seront donc
visibles séparéments).
– De décrémenter son backoff (avec des indications lorsque cette décrémentation est suspendue
puis reprise).
– D’attendre car son Network Allocaton Vector lui indique que le canal est occupé.
La configuration de cette nouvelle fonctionnalité se fait depuis le script TCL, et les informations
sont stockées dans des fichiers séparés du fichier de log principal de NS2. La visualisation se fait
grâce à un programme externe, qui représente graphiquement les informations sous la forme d’un
chronogramme.
Pour donner un exemple, nous considérons le scénario présenté sur la figure 4.2. Il y a deux
couples d’émetteur / récepteur situés juste à coté les uns des autres. Les nœuds 0 et 2 sont les
émetteurs, 1 et 3 sont les récepteurs. Les nœuds 0 et 2 cherchent à envoyer autant de paquets UDP
de 1000 octets que possible.
Le chronogramme est présenté sur la figure 4.3. Le temps est représenté de gauche à droite, son
échelle est indiquée en bas à gauche et à droite. Sur cette capture d’écran, nous avons zoomé de
façon à afficher uniquement ce qui se passait entre les secondes 11.023 et 11.04 de la simulation. Le
temps indiqué en bas au milieu correspond à la position du curseur de la souris (invisible sur cette
capture d’écran) ; il est souvent utile pour ”lire” directement les temps approximatifs des événements
53
Fig. 4.3 – Exemple de chronogramme partiel d’une simulation
dessinés. Les tirages d’un nouveau backoff ainsi que la fin de leur décrémentation sont signalés sur le
graphique par des petites barres verticales au bout des rectangles. Une barre en début d’un rectangle
de backoff indique qu’il vient d’être tiré au hasard et que sa décrémentation commence, une barre à
la fin indique qu’il a été décrémenté jusqu’à zéro et que l’émission va pouvoir commencer. L’absence
de barre verticale indique que la décrémentation a été temporairement stoppée ou qu’elle reprend.
Les douze fichiers de trace sont dessinés les uns en dessous des autres. Ici, on peut lire le
déroulement suivant de la simulation :
– Le nœud 2 est en train d’émettre (1). Le nœud 3 est en train de recevoir (ceci n’apparaı̂t pas
directement sur la figure, mais la présence d’un acquittement permettra ensuite de savoir si
cette communication s’est déroulée correctement), et les nœuds 0 et 1 savent qu’ils ne doivent
pas émettre (leur NAV leur indique que le canal est occupé).
– Le nœud 3 a fini de recevoir le paquet de données. Il retourne un acquittement (2). Les NAV
des nœuds 0 et 1 leur indiquent toujours qu’ils ne doivent pas émettre
– En (3), le canal devient libre. Les nœuds 0 et 2 veulent tous les deux émettre. Cette fois-là,
le nœud 2 a tiré un backoff très petit, dès qu’il a fini de le décrémenter, il émet un RTS
(4). Immédiatement, le nœud 0 détecte l’activité sur le canal et arrête de décrémenter son
backoff. Le RTS contenant la durée de la transmission de données qu’il annonce, cela permet
aux nœuds 0 et 1 de positionner leur NAV sitôt le RTS reçu.
– Le nœud 3 répond au RTS par un CTS (5), puis le nœud 2 y répond par l’envoi de ses
données, qui sont acquittées ... et ainsi de suite
Cet outil qui vient d’être présenté est simple d’utilisation. Grâce à lui nous serons par la suite
en mesure de réaliser une évaluation fine des scénarios simulés.
4.5 Prise en mains et premières simulations
54
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 – Débits dans l’expérience des deux

mobiles s’éloignant (modèle free-space). En
Fig. 4.4 – Description de l’expérience des abscisse : distance en dizaines de mètres, en
deux mobiles s’éloignant ordonnée : dé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
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 – Débits en fonction de la distance avec Fig. 4.7 – Débit en fonction de la distance avec
le modèle two-ray ground. le modèle shadowing.
55
Fig. 4.8 – Modèle shadowing, chronogramme à 100 m
Fig. 4.9 – Modèle shadowing, chronogramme à 500 m (sans RTS/CTS)
4.5.1 Portée de communication et débit

Les toutes premières simulations réalisées ont pour but d’observer la portée et le débit de
l’implémentation de 802.11 disponible sous NS2. Les scénarios consistent à placer un émetteur et
un récepteur juste à coté l’un de l’autre. L’émetteur envoie un flux à débit constant de paquets UDP
de 1000 octets (il en envoie suffisamment pour saturer le canal). Progressivement, on déplace le
récepteur (figure 4.4). Nous effectuons cette simulation avec chacun des modèles de propagation pro-
posés, en utilisant à chaque fois AODV comme protocole de routage. Ces simulations nous servent
à comparer les modèles de propagation disponibles, et nous servent d’étalon pour les simulations
plus complexes qui vont suivre (nous rappelons que dans toutes ces simulations, le débit physique
simulé est de 2 Mbit/s, puisque c’est celui supporté par défaut par NS2). A chaque fois, nous avons
également effectué une simulation avec les RTS/CTS et une autre sans. Le débit maximum observé
sans utiliser les RTS/CTS est de 1.6 Mbit/s, et descend à environ 1.4 Mbit/s lorsqu’on les utilise.
Modèle free-space. Ce modèle de propagation est le plus simple proposé par NS2. Le débit obtenu
en fonction de la distance entre l’émetteur et le récepteur est présenté sur la figure 4.5. D’après ce
modèle, la puissance reçue diminue de manière continue avec la distance. Comme la réception d’un
paquet n’est possible que si la puissance est supérieure à un certain seuil, nous obtenons logiquement
une courbe où le débit est maximum jusqu’à une certaine distance (600 m) puis ensuite nul. Le
seuil de communication est la valeur par défaut de NS2 (3.652.1010 W). Dans la pratique, NS2
est passablement buggé , et au delà de 600 m, dans sa version 2.26, son comportement devient
imprévisible (débit non nul à très grande distance, variation au cours du temps à une distance fixe,
crash pur et simple de NS2, ...).
Modèle two-ray ground. Ce modèle de propagation est celui qui est généralement utilisé par la
communauté ad-hoc lorsqu’il s’agit de développer et tester des protocoles de routage. On observe
les résultats présentés sur la figure 4.6. On remarque que jusqu’à une certaine distance (250 mètres)
le débit est maximum, puis qu’au-delà les communications ne sont plus possibles du tout. Ceci est
tout à fait normal compte tenu du modèle de propagation utilisé. On remarque aussi l’impact sur le
débit de l’utilisation du mécanisme RTS/CTS. Dans ce scénario où l’on obtient un débit maximum
56
de 1.6 Mbit/s en leur absence, l’utilisation des RTS/CTS provoque une baisse du débit utile de
12% environ à 1.4 Mbit/s.
Modèle shadowing. Ce modèle est plus complexe que les précédents, il est probabiliste et utilise
aussi des informations récoltées sur le terrain. Le débit que l’on obtient avec lui en fonction de
la distance est présenté sur la figure 4.7. Le scénario est le même que précédemment (figure 4.4)
et les paramètres du modèle shadowing sont ceux par défaut ( β = 2.0, σdB = 4.0, d0 = 1 mètre
). Ce modèle de propagation donne, à partir d’une certaine distance, une probabilité de plus en
plus importante pour qu’un paquet soit perdu (signal trop atténué). Dans ce scénario, cela ce
traduit par une diminution progressive du débit, qui commence à baisser à partir de 250 mètres
environ, mais qui ne devient nul qu’au delà de 600 mètres. Avec le modèle shadowing, tout comme
avec le freespace, la portée de communication est très grande, nettement plus qu’avec le two-ray
ground. A courte distance, l’impact des RTS/CTS est le même qu’avec le modèle two-ray ground.
On remarque cependant que lorsque l’on utilise les RTS/CTS, lorsque la distance augmente, le
dé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 contrôle soit perdu pour que la transmission échoue. Il faut également
noter que nous avons rencontré de nombreux ”plantages” de NS2 en utilisant ce modèle (sur la
figure 4.7, l’expérience sans RTS a en fait été arrêtée par un plantage du simulateur, qui n’a jamais
réussi à dépasser ce stade.
Sur les figures 4.8 et 4.9, on peut observer la distribution assez uniforme des pertes de paquets
engendrées par le modèle shadowing. Sur la figure 4.8, les nœuds ne sont espacés que d’une dizaine
de mètres. Il n’y a aucune perte de paquets, les paquets se suivent donc sans interruption sur le
canal, et un acquittement est envoyé pour chacun d’entre eux. Sur la figure 4.9, qui correspond à
une période où les deux nœuds sont déjà éloignés de 500 mètres, on remarque par contre qu’un
certain nombre de paquets de données ne sont pas acquittés, et même que parfois les paquets de
données ne sont plus envoyés (lorsque les acquittements eux-mêmes sont perdus, au bout d’un
certain nombre d’essais, la couche MAC notifie l’erreur à la couche supérieure, et un système de
timer va empêcher une tentative immédiate de retransmission). Sur les chronogrammes présentés,
c’est surtout la distribution dans les temps des acquittements manquants qui permet de bien
mettre en évidence la répartition assez homogène des erreurs de transmission avec le modèle
shadowing
Du fait que le modèle two-ray ground est utilisé en quasi exclusivité dans les simulations réalisées
dans la communauté ad-hoc, nous l’avons retenu pour la suite de nos travaux. Sauf mention
contraire, c’est donc ce modèle de propagation qui a été utilisé pour les simulations qui seront
présentées dans les paragraphes suivants.
4.5.2 Interférences
La seconde série de simulations avait pour objectif d’observer les interférences entre deux
émetteurs. Pour ce faire, nous avons utilisé quatre nœuds dans notre scénario, répartis en deux
paires. Au départ, tous les mobiles sont très proches les uns des autres, puis les deux paires vont
progressivement s’éloigner. Dans chaque paire, l’émetteur et le récepteur restent par contre très
proches (quelques mètres). Le trafic est un flux de paquets UDP de 1000 octets, envoyés aussi vite
que possible (on cherche à saturer la bande passante).
57
paire de gauche
paire de droite
1.8e+06 1.6e+06
paire de gauche
paire de droite
1.6e+06
1.4e+06
1.4e+06
1.2e+06

1.2e+06
1e+06
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 – Débit pour les deux paires Fig. 4.11 – Débit pour les deux paires
s’éloignant (sans RTS/CTS) s’é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 détectent sont totalement idépendantes
Fig. 4.15 – Chronogramme quand les paires sont en zone de communication
Fig. 4.16 – Chronogramme quand les paires sont en zone de détection de porteuse
58
Les débits obtenus sur chacune des paires en fonction de la distance sont présenté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 mécanisme de RTS/CTS ne change pratiquement rien à l’allure générale de la courbe.
Les RTS/CTS ne vont influer ici que sur le débit utile, qui est légèrement inférieur lorsqu’on les
utilise. On remarque ensuite la présence très nette de trois parties distinctes sur ces courbes.
– De 0 à 250 mètres, tous les mobiles sont à portée directe de communication les uns des
autres (figure 4.12). Le médium radio est partagé équitablement. Chaque paquet émis est
perçu par les trois autres mobiles qui peuvent en particulier mettre à jour leur NAV.
– De 250 à 550 mètres, les deux paires sont trop éloignées l’une de l’autre pour que le contenu
de leurs paquets soient compris (figure 4.13). Le NAV ne peut plus être mis à jour. Par contre,
le mécanisme de détection de porteuse est encore capable de déterminer quand des paquets
sont en cours de transmission dans l’autre paire. Cela ce traduit par un partage équitable
du médium, mais avec une plus grande instabilité dans cette répartition. Cette instabilité est
liée aux EIFS qui sont utilisés par les mobiles quand ils détectent de l’activité sur le canal.
Dans cette configuration, ils sont en particulier déclenchés dans une paire au moment où le
canal devient libre après l’émission d’un acquittement dans l’autre paire. Pour émettre son
prochain paquet, cette paire va devoir attendre un temps correspondant à EIFS+backoff, alors
que l’autre se contente de DIFS+backoff. DIFS+backoff étant statistiquement plus petit, il y
a une forte probabilité qu’un mobile émette un certain nombre de paquets avant que l’autre y
arrive et que la situation s’inverse. Ceci est particulièrement visible sur les figures 4.15 et 4.16.
Sur la figure 4.15 on voit que les deux nœuds accèdent au médium avec une alternance très
rapide (lorsque les émetteurs sont à portée de communication, un nœud n’émet en général pas
plus de deux ou trois paquets consécutifs avant de laisser la main). Sur la figure 4.16 où les
émetteurs sont par contre en zone de détection de porteuse, lorsqu’un nœud prend la main,
il la garde parfois pour un envoi comprenant jusqu’à une douzaine de paquets consécutifs.
– Au delà de 550 mètres, les deux paires sont totalement indépendantes (figure 4.14), chacun
des émetteurs occupe la totalité de la bande passante et transmet en continu.
Dans la phase de 200 à 550 mètres, les RTS/CTS n’ont aucun effet en dehors de la diminution
du débit utile que l’on avait déjà observé dans la première simulation. Ceci est tout à fait normal,
puisque l’on se place dans une configuration (entre 250 et 550 mètres) où les paquets RTS et CTS ne
peuvent pas plus être compris que les paquets de données (les signaux sont reçus avec une puissance
trop faible, les deux émetteurs sont dans la zone de détection de porteuse l’un de l’autre).
59
CHAPITRE
Scénarios ”avancés”
5
5.1 Introduction et objectifs
Nous avons étudié jusqu’à présent des configurations basiques, avec seulement deux mobiles
émetteurs. Les résultats obtenus vont nous servir maintenant à mieux comprendre les mécanismes
et les interactions qui se déroulent dans des scénarios plus complexes. Ces scénarios vont désormais
compter plus de mobiles, et les configurations vont être plus caractéristiques des réseaux ad hoc.
Nous nous intéresserons en premier lieu à la structure en chaı̂ne, qui est à la base même des
réseaux radio multi-sauts. Nous considérerons ensuite des configurations où certains mobiles sont
plus affectés par les interférences que d’autres. Et nous terminerons par une chaı̂ne perturbée de
manière inégale.
5.2 Trois paires

Le scénario que nous présentons maintenant à pour but de mettre en évidence certains problèmes
d’équité dans l’accès au médium avec 802.11. Nous utilisons six mobiles que nous plaçons comme
indiqué sur la figure 5.1 : ils sont tous initialement très proches les uns des autres. Les mobiles
sont répartis en trois paires d’émetteur / récepteur. Dans chaque paire, l’émetteur essaie d’envoyer
autant de paquets UDP de 1000 octets que possible à son récepteur (la file d’attente d’émission est
continuellement pleine). La vitesse de transmission est de 2 Mbit/s et le mécanisme RTS/CTS est
utilisé.
L’idée du scénario est de produire une situation typique des réseaux ad hoc où certains mobiles
sont plus soumis à des interférences que d’autres. Pour ce faire, au cours de la simulation, nous
déplaçons progressivement les paires extérieures à la vitesse constante de 25 mètres par seconde.
Au fur et à mesure du déroulement du scénario, les mobiles vont tout d’abord tous interférer les
Fig. 5.2 – Interférences non symétriques entre

Fig. 5.1 – Position initiale des 3 paires les 3 paires
60
CHAPITRE 5. SCÉNARIOS ”AVANCÉS”
uns avec les autres, puis les paires extérieures vont continuer à interférer avec la paire centrale mais
sans se gêner entre elles (figure 5.2), et enfin les trois paires vont être suffisamment éloignées les
unes des autres pour accéder au canal en même temps sans problème. Nous obtenons les débits
présentés sur la figure 5.3, ils peuvent être interprétés comme suit :
– De 0 à 5 secondes (les paires extérieures sont entre 0 et 125 mètres de la paire centrale),
les trois paires sont en contact ”direct” (elles sont à portée de communication les unes des
autres). Même si le réseau est saturé, comme les débits demandés sont identiques, la bande
passante est partagée de manière équitable (le débit utile maximal de 1.6 Mbit/s environ
divisé par 3).
– De 5 à 11 secondes (les paires extérieures sont désormais entre 125 et 275 mètres de la paire
centrale, mais surtout entre 250 et 550 mètres l’une de l’autre) les communications (et donc la
mise à jour du NAV grâce aux RTS/CTS) n’est plus possible entre les paires extérieures, mais
comme elles détectent réciproquement leurs porteuses, elle savent que le canal est utilisé et le
partage encore de manière assez équitable (environ un tiers chacune). Le canal est cependant
un peu moins bien partagé. La raison se trouve dans le phénomène décrit dans la simulation
des deux paires, au moment où elles sont dans les zones de détection de porteuse l’une de
l’autre. Le déclenchement des EIFS est à la base du phénomène d’instabilité.
– De 11 à 22 secondes (les paires extérieures sont entre 275 et 550 mètres de la paire centrale)
la paire centrale est dans une situation différente des deux autres paires. Elle détecte la
porteuse des deux paires extérieures, alors que ces dernières ne détectent chacune que celle
de la paire centrale. Dans ce contexte asymétrique, le mécanisme d’accès au canal présente
une faiblesse très nette. Dès que la paire centrale perd l’accès au canal, elle a énormément
de difficultés à le récupérer. Le débit de la paire centrale est quasiment nul durant cette
période, alors que celui des paires extérieures atteint le maximum possible. Ceci s’explique
de la façon suivante : la paire centrale ne peut émettre que lorsque les deux autres sont
silencieuses pendant une période suffisante. Mais les deux autres ne se gênent pas entre
elles, et il n’y a donc aucune raison pour qu’elles soient synchronisées. De ce fait, il n’y a
pas de raison pour que leurs pé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 extérieures
coı̈ncident. La figure 5.5 montre le décalage existant entre les périodes de silence des deux
paires extérieures. Le phénomène est encore amplifié par le mécanisme EIFS de 802.11. La
figure 5.4 présente ce qui se passe d’une façon simplifiée (pour des raisons de lisibilité l’échelle
de temps n’est pas respectée entre les différents éléments). On peut tout d’abord noter que
même si dans la réalité les différents mobiles ne commenceraient pas forcément de manière
synchronisée, le problème apparaı̂trait néanmoins au bout de quelques instants. En premier
lieu, le canal doit être libre pendant une période DIFS avant qu’un nœud décide d’essayer
de transmettre (figure 5.4a). Les nœuds attendent ensuite pendant une période de backoff
aléatoire (figure 5.4b). Comme l’émetteur de la première paire a terminé de décrémenter
son backoff et que le canal est toujours libre, il commence à transmettre, brouillant ainsi la
seconde paire qui entre alors en période de defering jusqu’à ce que le canal soit à nouveau
libre. Comme la troisième paire n’est pas gênée, elle peut terminer la décrémentation de son
backoff et commencer elle aussi à émettre (figure 5.4c). A cause de l’activité sur le canal venant
de la troisième paire, la deuxième doit rester plus longtemps en defering. Et quand le canal
redevient enfin libre, elle doit encore attendre pendant une période EIFS (qui est environ 6
61
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)
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 – Débit en fonction du temps dans le Fig. 5.4 – Détail du problème d’accès au
scénario des trois paires médium avec l’EIFS
fois plus longue qu’un DIFS). Entre temps, les deux autres paires ont déjà recommencé un
nouveau cycle (figure 5.4d) et tout recommence ... (figure 5.4e).
– Au delà de 22 secondes Les trois paires sont suffisamment éloignées les unes des autres.
Elles ne détectent plus les porteuses des autres et peuvent émettre en même temps au débit
maximum.
Il faut noter que pour la période problématique, l’amplification des problèmes par le mécanisme
des EIFS peut être quantifiée. Nous avons effectué une série de simulations en plaçant les trois
paires dans la position correspondant à la période des secondes 11 à 22 de la figure 5.3. Pour
certaines mesures, nous avons utilisé des EIFS ayant leur durée normale (364 µs) et dans d’autres
des EIFS ayant la même durée que les DIFS (50 µs). Nous avons également effectué ces simulations
an activant ou non les RTS/CTS. La figure 5.6 présente ces résultats :
Fig. 5.5 – Détails de la simulation entre les secondes 11 et 22
62
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’accès au canal pour la paire centrale en fonction de la taille des paquets et
de la durée de l’EIFS (période des secondes 11 à 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 débit encore
légèrement inférieur.
– Avec des EIFS ”courts” (50µs, soit la même duré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 très largement défavorisée vis-à-vis des paires extérieures. Cette limitation vient
de l’effet de la non synchronisation des paires extérieurs dont nous avons parlé précédemment.
Là encore, les RTS/CTS ont un impact négatif pour le partage équitable, lorsqu’ils sont
activés, la paire centrale a plus de difficultés à accéder au canal que lorsqu’ils ne le sont
pas. On remarque enfin que les chances d’accè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 occupé (transmission de données ou de paquets de contrôle) par rapport
au temps ou le canal est libre (périodes de backoff, DIFS, EIFS) diminue. Par conséquent les
chances que les périodes de silence des paires extérieures coı̈ncident diminuent aussi.
Cette expérience met donc en évidence un problème d’inégalité important dans l’accès au
médium radio de 802.11.
5.3 Sauts multiples en configuration de chaı̂ne

Jusqu’alors nous nous sommes intéressés qu’à des configurations qui ne faisaient pas appel à la
capacité de routage des réseaux ad-hoc. Dans le scénario présenté sur la figure 5.7, nous cherchons
maintenant à voir ce qu’il se passe dans une chaı̂ne assez longue (comportant jusqu’à 7 sauts) si
l’émetteur envoie autant de données que possible.
Tout d’abord, il est important de comprendre que dans ce genre de scénario, le protocole de
routage utilisé a déjà un impact important. En effet, si des interférences ou des collisions au niveau
de 802.11 provoquent la perte de certains paquets nécessaires pour le routage voire des incapacités
totales de communication un peu longues entre certains mobiles, cela peut conduire le protocole
de routage à déclarer l’expiration de la route. Les timers et les mécanismes déclenchant ces expi-
63
Fig. 5.7 – La chaı̂ne à 8 nœuds
rations varient d’un protocole de routage à l’autre, et il en est de même pour les algorithmes de
reconstruction qu’une perte de route va déclencher.
Par exemple, dans notre scénario de chaı̂ne, en cas d’utilisation d’un protocole proactif, la perte
de paquets hello consécutifs peut provoquer la rupture de la route. Cela va déclencher une première
mise à jour en cascade des tables de routage. Quand les paquets hello sont ensuite à nouveaux reçus,
cela va provoquer une seconde mise à jour en cascade. Il y aura donc une période d’instabilité dans
l’état des tables de routage (où il n’y aura plus de route de bout en bout de la chaı̂ne), ainsi qu’une
charge éventuellement importante du réseau. Dans le cas d’un protocole réactif, la perte de paquets
de recherche de route peut amener l’émetteur à penser qu’il n’y a pas de route disponible du tout ;
et donc a attendre un nouvel essai initié par une couche supérieure pour à nouveau essayer de
trouver la route.
Cette mise en garde effectuée, revenons à la description du scénario. Il a consisté à faire transiter
des paquets sur une chaı̂ne de plus en plus longue (de 2 à 8 nœuds et donc de 1 à 7 sauts). Les nœuds
sont placés à 200 mètres les uns des autres. Dans la section 4.5.1, nous avons vu que dans le cas
du modèle two-ray ground, cela correspondait à un placement tel qu’un nœud peut communiquer
avec ses voisins de gauche et de droite, et que sa porteuse est détectée par les nœuds à deux sauts
et pas plus loin. Cela correspond évidemment à l’idée que l’on se fait d’une communication multi-
sauts dans un véritable réseau ad hoc, où les nœuds d’une route sont en général choisis de sorte à
minimiser si possible le nombre de sauts.
La figure 5.8 montre les débits mesurés sur la chaı̂ne en fonction du nombre de sauts. Le débit de
bout en bout diminue logiquement trè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 troisième) pour se
stabiliser aux alentours de 300 kbit/s lorsque plus de 4 nœuds sont impliqués. Dans les cas de
chaı̂nes assez longues, on remarque également un certaine instabilité du débit de bout en bout.
La figure 5.9 présente les chronogrammes d’émissions pour des chaı̂nes de 2 à 8 nœuds. Les
RTS/CTS n’étaient pas utilisés, seuls les données et leurs éventuels acquittements sont donc
représentés. 2 IF0 et 2 IF1 représentent les émissions par les nœuds 0 et 1 dans la chaı̂ne à un
saut, 3 IF0, 3 IF1 et 3 IF2 représentent les émissions par les nœuds 0, 1 et 2 dans la chaı̂ne à
deux saut et ainsi de suite. Cette partie du chronogramme correspond au tout début des échanges,
on y voit la forme en ’V’ particuliè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 acquittés (ils sont diffusés) mais que les paquets de données
64
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
1e+06
800000
600000
400000
200000
0
0 10 20 30 40 50 60
temps en secondes
Fig. 5.8 – Débit sur la chaı̂ne de 2 à 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
très courts).
On voit également que lorsque le nombre de sauts augmente, certains nœuds ont du mal à
accéder au médium. Par exemple, dans la chaı̂ne à 8 nœuds (dernière série), après la traversée
de la chaı̂ne complète par trois paquets de données, le nœud 1 monopolise le canal pendant une
douzaine de paquets (ces paquets sont bien reçus au nœud 2 comme le prouvent les acquittements
qu’il renvoie, mais il n’arrive pas ensuite à accéder au canal pour continuer à router ces paquets).
Ces effets sont causés par la combinaison de plusieurs facteurs : le nœud 0 a toujours des paquets
à envoyer et le nœud 1 est gêné par plus de mobiles que le nœud 0 (0 ne peut pas émettre en
même temps que 1 ou 2, 1 ne peut émettre en même temps que 0, 2 et 3). Sur ces chronogrammes,
il est également aisé de constater la réutilisation spatiale (si deux ou plus nœuds émettent à un
instant donné, c’est qu’ils sont suffisamment éloignés pour ne pas interférer ni même se détecter,
par exemple les nœuds 0 et 3 émettent parfois en même temps).
L’allure générale des chronogrammes pour les chaı̂nes assez longues (5 sauts ou plus) permet
de tout de suite saisir certaines informations confirmées par d’autres analyses des traces : dans
un scénario de chaı̂ne, avec un modèle de propagation two-rays ground, les paquets ont de fortes
chances d’être bloqués au niveau des 3 premiers nœuds ; mais s’ils atteignent le quatrième, alors
leur chance d’atteindre la destination finale est très importante. Ce blocage au niveau des premiers
nœuds est en fait dû aux difficultés d’accès au canal puisque la source essaie d’envoyer autant de
paquets que possible (et que comme nous l’avons mentionné, elle rencontre moins de contention
que les autres.) Plus loin sur la chaı̂ne le problème ne se pose plus car les nœuds ne cherchent à
émettre que ce qu’ils ont pu recevoir.
65
Fig. 5.9 – Chronogrammes de chaı̂nes de 2 à 8 nœuds
66
Nous avons ensuite effectué la même simulation mais en ajoutant l’utilisation des RTS/CTS.
Le débit de bout en bout obtenu en fonction du nombre de sauts est présenté sur la figure 5.10. Les
débits pour les chaı̂nes courtes (1, 2 et 3 sauts) sont assez similaires à ceux obtenus si l’on n’utilise
pas les RTS/CTS. Bien sûr, dans leurs cas, on observe une diminution du débit proportionnelle
au temps supplémentaire de transmission des paquets RTS/CTS (débits respectifs de 1.4, 0.7 et
0.4 Mbit/s respectivement). Mais lorsque la chaı̂ne continue de s’allonger, le débit de bout en bout
devient vraiment très faible (moins de 100 kbit/s à partir de 5 sauts). Les RTS/CTS semble donc
dans ce contexte avoir un contre-effet et être particuliè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, très peu de paquets arrivent à traverser la chaı̂ne de façon consécutive. Le nœud
0 envoie en quasi permanence des paquets au nœud 1, mais celui-ci n’arrive que rarement à les
faire suivre. On remarque également des coupures très fréquentes de la route, qui force AODV à
la reconstruire (ceci se voit très bien avec les formes en ”V” précédant les périodes où quelques
paquets arrivent à traverser la chaı̂ne complètement.
Les chronogrammes des figures 5.13 (sans RTS/CTS) et 5.14 (avec RTS/CTS) permettent de
voir plus en détail ce qui se passe. En l’absence de RTS/CTS, on remarque une forte réutilisation
spatiale, les nœuds situés à trois sauts ou plus l’en de l’autre pouvant en général émettre en même
temps. Avec les RTS/CTS maintenant, on remarque que c’est plus problématique. Sur la figure 5.14
par exemple, on voit que lorsque le nœud 3 accède au canal, le nœud 0 envoie plusieurs RTS qui ne
reçoivent pas de réponse de 1 (et de même, 1 envoie plusieurs RTS à 2 qui n’y répond pas quand 4
est en train d’envoyer des données).
Sur le chronogramme de la figure 5.15 (qui correspond à une autre période de la simulation
de la chaı̂ne de 8 nœuds avec RTS/CTS, on voit cependant que cette réutilisation spatiale peut
parfois avoir lieu. On voit bien en particulier sur cette figure les émissions en parallè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 expérience montre l’impact dans un contexte plus réaliste du phénomène qui a été mis en
lumière dans le scénario précédent. La topologie est celle présentée sur la figure 5.16 : un flux UDP
à débit constant traverse une chaı̂ne de six mobiles (similaire à celle utilisée dans les premières
simulations, avec une distance de 200 mètres entre chaque nœud). Une paire de mobiles (entre
lesquels existe un autre flux à débit constant) est initialement située loin de la chaı̂ne (en dehors
de toute zone d’interférences). Les mobiles de la paire sont très proches l’un de l’autre (un mètre)
durant la totalité de la simulation. Les nœuds de la chaı̂ne restent fixes du début à la fin. Au fur
et à mesure de la simulation, la paire va se déplacer et va progressivement entrer puis ressortir de
la zone d’interférences des nœuds de la chaı̂ne.
La simulation a été effectuée pour différents débits demandés sur les deux flux (2000, 1333,
1000, 800, 400 et 200 kbit/s). Excepté pour des débits demandés de 200 kbit/s, le réseau est saturé
et la bande passante n’est pas suffisante pour délivrer la totalité des paquets demandés. Pour des
raisons de lisibilité la figure 5.17 ne présente qu’une moyenne des débits sur la chaı̂ne simulés en
fonction du temps. Le but de cette courbe est de donner une idée des phénomènes d’interférences
en fonction de la position des divers mobiles ; plus que les débits chiffrés, c’est la forme de la courbe
qui est importante ici. On remarque immédiatement un effet de symétrie. Au tout début et à la
67
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
1e+06
800000
600000
400000
200000
0
0 10 20 30 40 50 60
temps en secondes
Fig. 5.10 – Débit sur la chaı̂ne de 2 à 8 nœuds (UDP, avec les RTS/CTS)
Fig. 5.11 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, sans les RTS/CTS), vue large
Fig. 5.12 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, avec les RTS/CTS), vue large
68
Fig. 5.13 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, sans les RTS/CTS), détail
Fig. 5.14 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, avec les RTS/CTS), détail
Fig. 5.15 – Chronogramme dans la chaı̂ne à 8 nœuds (UDP, avec les RTS/CTS), détail 2
69
350000
300000
250000

200000
150000
100000
50000
0
10 20 30 40 50
temps en secondes
Fig. 5.16 – Le scénario de la chaı̂ne et

du couple de perturbateurs Fig. 5.17 – Débit moyen sur la chaı̂ne
fin de la simulation, la paire perturbatrice est trop loin de la chaı̂ne pour la gêner, c’est là que l’on
observe logiquement le débit maximum. On remarque ensuite que lorsque la paire perturbatrice
est très proche de la chaı̂ne (partie centrale de la courbe, entre les secondes 25 et 45 environ), le
débit sur la chaı̂ne est réduit mais néanmoins existant. Et finalement on observe deux zones où le
flux sur la chaı̂ne est complètement stoppé ou presque (secondes 10 - 25 et 45 - 50). Ces périodes
correspondent aux moment où la paire perturbatrice est dans la zone de détection de porteuse des
nœuds centraux de la chaı̂ne. Le phénomène qui se produit alors est très proche de celui rencontré
dans la simulation des trois paires : les mobiles au centre de la chaı̂ne détectent les porteuses des
premiers mobiles de la chaı̂ne mais aussi celles de la paire perturbatrice. Ils sont dans la même
situation que la paire centrale dans le scénario des trois paires, puisque qu’à cet instant la paire
perturbatrice et les premiers mobiles de la chaı̂ne ne se gênent pas du tout et émettent de façon
désynchronisée.
5.5 Le problème de l’asymétrie

Les problèmes que nous avons mis en lumière dans les simulations précédentes sont ca-
ractéristiques des réseaux ad-hoc. L’effet le plus remarquable est l’incapacité pour certains
émetteurs d’accéder au canal radio. Contrairement aux problèmes d’équité mis en évidence dans
[44, 48] où l’inégalité provient de collisions répétées, l’inégalité mise en évidence ici provient de
l’impossibilité d’accéder au médium radio (certains mobiles ne peuvent pas s’exprimer). Ce type
de comportement se produit lorsqu’il existe une asymétrie dans les interférences entre les différents
mobiles. La notion d’asymétrie a été mentionnée dans [47], mais aucune explication de 802.11 face
à cette asymétrie n’a été apportée. Or le scénario des trois paires permet de bien comprendre
l’origine du problème. En effet, pour un mobile connaissant une contention plus importante, un
certain nombre d’autres mobiles en compétition avec lui ne se gênent pas du tout entre eux, et
leurs émissions ne sont donc pas synchronisées. Pour que le mobiles mis en défaut puisse accéder au
70
canal, il faut que les périodes de silence des autres mobiles se recouvrent. Or la probabilité d’un tel
recouvrement est faible, et le mobile perçoit le canal comme occupé dès que l’un ou l’autre l’utilise.
Dans les configurations que nous avons présentées, les mobiles les plus exposés (la paire centrale
dans le scénario des des trois paires par exemple) perçoivent le canal occupé en quasi permanence, et
les mobiles ”gêneurs” le perçoivent presque tout le temps libre (ils continuent donc leurs émissions
de plus belle).
Ce problème n’est pas un problème de nœuds cachés et ne peut pas être résolu par le mécanisme
des RTS/CTS. En effet, les récepteurs des mobiles désynchronisés ne sont pas nécessairement les
mêmes et de plus les mobiles peuvent être trop loin les une des autres pour comprendre le contenu
des paquets de contrôle. Dans le contexte prévu par 802.11 (mobiles attachés à des stations de base
ou à portée directe de communication) le type d’asymétrie décrit précédemment ne se produit pas.
Soit les mobiles sont à portée de communication directe, soit ils sont reliés à une même station
de base et lorsqu’ils communiquent avec elle les RTS ou CTS qu’elle envoie suffisent à réserver
convenablement le canal et y permettre un accès équitable.
Nous avons vu également que le mécanisme des EIFS qui est sensé protéger les acquittements
pouvait amplifier le problème de l’asynchronisme que nous venons décrire. De même, nous avons
vu dans l’étude des résultats de la chaı̂ne que les RTS/CTS pouvaient avoir eu aussi un impact
particulièrement négatif dans le cadre de réseaux multi-sauts étendus.
5.6 Conclusion sur ces simulations

L’inégalité dans l’accès au médium radio rencontrée dans des configurations de base des réseaux
ad hoc a une impact fondamental sur les protocoles des couches supérieures. En effet, la plupart des
protocoles dans les réseaux ad hoc basent leur fonctionnement sur la connaissance des liens. Dès
qu’un lien apparaı̂t ou disparaı̂t, des informations sont mises à jour dans le réseau. Dans le cadre
d’un réseau fixe, si chaque mobile est en mesure de s’annoncer régulièrement les liens seront connus
et considérés comme stables, ce qui entraı̂nera peu de trafic de contrôle. Par contre, si certains
mobiles ne sont pas en mesure d’accéder régulièrement au médium, des liens vont apparaı̂tre et
disparaı̂tre de manière cyclique alors que ces liens existent bien physiquement ! Ceci entraı̂nera une
charge de trafic de contrôle non négligeable qui aurait pu être évitée si tous les mobiles avaient
pu émettre de manière équitable (ces cassures de lien répétées et le trafic de contrôle généré sont
particuliè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 réseau puisqu’ils ne verront pas certains liens existants réellement. Ils n’auront donc
qu’une connaissance partielle de la topologie. Ils pourraient alors prendre des décisions adaptées
à la vision qu’ils ont alors qu’elles ne le sont peut-être pas à la topologie réelle. Enfin, une telle
inégalité implique que certaines communications ne pourront obtenir qu’un débit très faible voire
nul à certains moments.
71
CHAPITRE
Quelques solutions aux
6 problèmes d’équité dans les
réseaux ad hoc
Plusieurs solutions ont été proposées pour résoudre le problème d’équité dans l’accès au médium
radio.
MACAW [46] propose une gestion différente de la fenêtre de contention : l’idée est de ne pas
favoriser la station qui vient juste d’émettre comme le fait le Binary Exponential Backoff. Cette
solution concerne les problèmes d’inégalité provenant de collisions mais elle ne résoudra pas les
problèmes où certains mobiles n’accèdent pas du tout au médium.
Les solutions élaborées dans [47] se basent sur un graphe de contention des flux ce qui suppose
une connaissance globale du réseau ainsi que des flux acheminés dans le réseau. Cette solution est
donc difficile à implanter en pratique.
Les travaux de Bensaou et al. [48, 38] ont une approche de faisabilité puisqu’ils modifient 802.11
dans le but de garantir une meilleure équité. L’idée est que chaque mobile prenne en compte les
communications dans son voisinage à un saut afin de savoir s’il peut é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 émis plus ou moins que ses voisins. S’il a émis plus, il augmente
sa fenêtre de contention, ce qui lui permet statistiquement de ralentir ses émissions. S’il a émis
moins, il diminue sa fenêtre de contention, ce qui lui permet statistiquement d’augmenter ses
émissions. Avec ces modifications, le système doit alors se stabiliser sur une solution plus équitable.
L’idée est intéressante (même si l’algorithme n’a manifestement pas été correctement finalisé et
si quelques modifications simples l’amélioreraient), mais il ne permet d’équilibrer que des flux à
portée de communication. Or, comme dans le scénario des trois paires par exemple, les émetteurs
sont en zone de dé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 proposé dans un premier temps une solution qui essaye de résoudre le problème
d’équité quand les mobiles en compétition ne peuvent pas communiquer. Par la suite, nous avons
proposé une seconde solution, inspirée de celle de Bensaou et al., mais qui cherche à diffuser de
l’information dans son voisinage pour être plus efficace.
6.1 Une solution historique et locale

Un certain nombre de contraintes que nous nous étions fixées nous on conduit à élaborer cette
première solution. Ces contraintes étaient les suivantes :
72
CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLÈMES D’ÉQUITÉ DANS LES
RÉSEAUX AD HOC
– Minimiser les changements à apporter à 802.11 (notre approche est assez pragmatique, il est
important à nos yeux de chercher une solution qui puisse être implémentée concrètement dans
des matériels existants).
– Garder la compatibilité avec les cartes 802.11 n’ayant pas été modifiées
– Fonctionner même lorsque les mobiles impliqués n’ont aucun moyen de communiquer, même
en passant par des intermédiaires
Sous nos contraintes il peut parfois être impossible de communiquer avec les mobiles qui nous
gênent ni même de les identifier. Il est également impossible pour un mobile de se rendre compte que
son activité, lorsqu’elle est cumulée à celles d’autres émetteurs, empêche d’autres mobiles d’accéder
au canal (par exemple, du point de vue des paires extérieures dans le scénario des trois paires, le
canal est toujours libre et elles en profitent logiquement pour émettre au débit maximum). Notre
solution consiste à chercher à pénaliser les mobiles qui transmettent beaucoup. De cette manière
on espère que lorsqu’ils seront forcés de se taire, les chances que les périodes de silence coı̈ncident
au niveau des mobiles gênés augmenteront et que ces derniers pourront enfin émettre.
La modification que nous proposons concerne le backoff et son calcul devient le suivant : au
niveau de chaque nœud le temps est découpé en périodes de longueur fixe (par exemple une
seconde). La situation est la même pour chaque nœud en début de période. Ensuite, à chaque
fois que le nœud gagne l’accès au canal et envoie un paquet, une pénalité est ajoutée au backoff
(le backoff pour les paquets suivants sera toujours aléatoire, mais statistiquement plus grand).
En dehors de cette pénalité, le calcul du backoff reste strictement identique à celui décrit dans
la norme. Nous avons soigneusement choisi la courbe de progression de la pénalité (ou malus)
qui est présentée sur la figure 6.1. Cette courbe est caractérisée par un premier plateau où le
malus est nul ou presque (”les premiers paquets ne sont pas pénalisés”), par une rampe assez
raide (”maintenant que l’on a déjà beaucoup parlé, il est temps de laisser de la place aux
autres”) et enfin par un plateau assez haut (si l’on continuait à augmenter la pénalité de manière
exponentielle, lorsqu’il n’y a qu’un seul flux, son débit serait trop pénalisé). Au début de chaque
cycle, le compteur est ré-initialisé et la pénalité redevient nulle. Dans ce système, les paramètres
qui peuvent être ajustés sont essentiellement la durée du cycle et la forme de la courbe de
progression de la pénalité. Il faut noter que nous n’avons pas essayé de favoriser les mobiles en
défaut en diminuant la borne maximale de leur fenêtre de contention en dessous du seuil cwMin
fixé par la norme. Nous pensions que la norme avait ses raisons d’avoir fixé cwMin à 31 et que
réduire cette valeur pourrait notamment augmenter de manière sensible les collisions dans le réseau.
Bien que cette méthode soit simple, elle donne des résultats tout à fait intéressants. Dans les
simulations, il est apparu que la probabilité pour un mobile d’être complètement ”écrasé” par ses
voisins non directs est beaucoup plus faible qu’avec 802.11 non modifiée.
La figure 6.2 montre les débits obtenus dans le scé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 détecte
les porteuses des deux paires extérieures sans pouvoir communiquer avec elles) l’accès au canal
n’est peut-être pas encore équiprobable pour les trois paires, mais que la paire centrale n’est plus
complètement étouffée par les deux autres (elle obtient un débit de 300 - 350 kbit/s, contre environ
800 kbit/s pour chacune des paires extérieures). Le principal inconvénient de la méthode est aussi
clairement visible sur cette courbe, puisque le débit maximum d’une paire lorsqu’elle ne subit pas
d’interférences est sévèrement limité (seulement environ 1 Mbit/s au delà de 22 secondes, alors que
sans malus on atteint 1.6 Mbit/s, soit une réduction de près de 40%). Comme nous augmentons
73
RÉSEAUX AD HOC
1.6e+06
paire de gauche
paire centrale
1.4e+06 paire de droite
1.2e+06
250

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 pénalité en Fig. 6.2 – La simulation des 3 paires en utilisant le
fonction du nombre de paquets envoyés mécanisme du malus
statistiquement le backoff, le nombre maximum de paquets qu’un mobile peut envoyer par seconde
diminue. Mais il faut garder à l’esprit que ce problème devient rapidement imperceptible lorsque le
nombre de flux en compétition à un instant donné pour l’accès au canal augmente. Sur la première
partie de la courbe (de 0 à 10 secondes), les trois flux sont en compétition et leur débit agrégé
est de 450×3 soit 1350 kbit/s ; avec trois flux en compétition, la perte de débit engendrée par le
mécanisme du malus passe donc déjà en-dessous des 20%.
Nous avons également testé notre système sur le scénario de la chaı̂ne et de la paire perturbatrice
(figure 5.16), mais avec des flux TCP à la place des flux UDP, et un débit demandé pour chacun
d’entre eux de 2 Mbit/s. Avec la version normale de 802.11, nous avons obtenu des résultats
désastreux (figure 6.3). Il faut bien garder à l’esprit que le caractère erratique de l’accès au médium
dans ces conditions empèche de nombreux acquittements de TCP d’arriver à temps, empêchant
ainsi parfois TOUTE progression de la communication. La version modifiée se comporte beaucoup
mieux (figure 6.4). Notons qu’en l’absence de contention, le débit sur la paire perturbatrice est
fortement affecté (périodes des secondes 0 à 10 et de 53 à la fin) puisque le mécanisme du malus le
fait passer de 1250 kbit/s à un peu moins de 950 kbit/s, mais que le débit sur la chaı̂ne ne change
pas (un peu plus de 200 kbit/s, avec ou sans malus). Comme nous l’avions déjà énoncé, l’effet
négatif du malus sur le débit décroı̂t très rapidement avec le nombre de mobiles en contention.
L’autre inconvénient principal de la méthode, qui n’apparaı̂t pas cette fois-ci sur les courbes, est
la tendance à produire des transferts par rafale, qui peuvent causer des problèmes à certains types
d’applications (multimédia utilisant des petits tampons en particulier, comme la téléphonie). Si un
émetteur ne rencontre pas beaucoup de difficultés pour accéder au canal et qu’il a beaucoup de
paquets en attente, il va les émettre à la suite les uns des autres jusqu’à ce que la pénalité devienne
non négligeable et le freine. Les émissions d’un tel mobile seront donc en majorité en début de
cycle. A ce propos, la taille de la fenêtre TCP a une importance : trop petite et TCP pensera qu’il
y a de la congestion lorsque le débit sera réduit par la pénalité ; il réagira en diminuant encore sa
fenêtre, ce qui est mauvais.
74
RÉ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 – Débits dans la simulation de la chaı̂ne Fig. 6.4 – Débits dans la simulation de la chaı̂ne
et du perturbateur (TCP, 802.11 non modifié) et du perturbateur (TCP, 802.11 modifié)
Au niveau des amélioration possibles de ce système, on peut citer d’une part le changement
dans le comptage effectué. Plutôt que de compter les paquets indifféremment, il serait peut-être
plus judicieux de prendre en compte leur taille. En effet, en fonction des applications (telnet par
exemple) et des protocoles utilisés (TCP avec ses acquittements), il se peut qu’il y ait beaucoup de
paquets très petits à transferer. Ces dernier ferait très vite progresser le malus alors que finalement
ils ne gênent peut-être pas beaucoup les mobiles du voisinage. D’autre part, la courbe de progression
de la pénalité mériterait d’être étudiée plus en détail également. Sous sa forme actuelle elle donne
des résultats déjà très encourageants, mais nous avons le sentiment que ces derniers pourraient être
encore améliorés.
Remarquons finalement que ce système de pénalité sur le backoff permet bien l’inter-opérabilité
avec les mobiles utilisant des cartes 802.11 non modifiées. Les mobiles utilisant la version modifiée
seront un peu désavantagés en terme de débit possible, mais la communication restera possible.
6.2 Une solution étendue géographiquement

6.2.1 Point de dé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 médium. Le nombre de paquets qu’il envoie est stocké dans
la variable Wi et le nombre de paquets envoyés par ses voisins est stocké dans la variable Wo . Les
variables Φi et Φo correspondent respectivement à l’allocation faite au nœud i et celle faite à ses
Wi
voisins. Ils définissent un index d’équité égal à W o
×Φ
Φi . La fenêtre de contention de chaque mobile
o
est alors ajustée de la manière suivante : chaque mobile double sa fenêtre de contention si son
index d’équité devient supérieur à une constante C, chaque mobile divise par deux sa fenêtre de
contention si son index d’équité devient inférieur à C1 , et chaque mobile ne fait rien si son index
d’équité est compris entre C1 et C.
Comme nous l’avons dit dans l’introduction de ce chapitre, l’algorithme proposé présente
quelques faiblesses. D’une part, le comptage des paquets est effectué de manière anarchique : cer-
75
RÉSEAUX AD HOC
A
D
Fig. 6.5 – La configuration à quatre nœuds
tains paquets sont comptés plusieurs fois sans aucune raison. D’autre part, l’index d’équité pour
chaque mobile devrait se stabiliser vers 1 or il se situe entre 2 et 4. Enfin, dans les scénarios pro-
posés, la taille des fenêtres de contention des mobiles se bloque à la taille maximale autorisée par
802.11, ce qui conduit à une perte de débit global importante.
Néanmoins les approches d’espionnage du médium et de faisabilité nous semblaient intéressantes.
Nous avons donc gardé le socle de l’algorithme présenté par Bensaou et al. et nous l’avons modifié
afin d’apporter un espionnage étendu et de réduire la perte globale de bande passante.
Un espionnage étendu Dans l’algorithme de départ, chaque mobile ne considère que les paquets
qui sont envoyés dans sa zone de communication. Or deux flux peuvent être en compétition même
si leurs émetteurs ne sont pas à portée de communication. Par exemple, dans la figure 6.5, les
émetteurs A et B ne se voient pas mais leurs flux associés sont en compétition. Par conséquent,
cette méthode ne permet pas à un mobile d’évaluer toux les flux qui sont en compétition avec le
flux dont il est é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 à l’émetteur d’un flux d’avoir une connaissance plus étendue des flux en compétition. Il
faut néanmoins faire attention à ne pas compter plusieurs fois les paquets. Pour cela, chaque mobile
doit faire un comptage séparé des paquets de mobiles voisins. Ensuite chaque mobile enverra dans
l’ACK ou le CTS la liste des mobiles connus comme étant voisins et le comptage Wo . Lorsque les
mobiles reçoivent cette information, ils n’ont plus qu’à retirer le comptage des mobiles déjà connus
d’eux du Wo reçu et mettre à jour leur nouveau Wo .
L’envoi de la liste des voisins peut être coûteux, c’est pourquoi nous proposons que seules les
entrées/sorties de cette liste soient intégrées dans le paquet ACK ou CTS.
Ajustement de la fenêtre de contention A partir des données de comptage, le calcul de l’index

d’équité intervient, puis en fonction de la valeur obtenue la fenêtre de contention est ajustée. Dans
l’algorithme de départ, nous avons remarqué que les changements dans la taille de la fenêtre étaient
brusques et ne prenaient pas le temps de vérifier qu’ils étaient profitables.
Nous proposons donc de modifier l’ajustement de la fenêtre de contention. Dans le cas où un
mobile lèse ses voisins, la fenêtre ne sera modifiée que si ces trois conditions sont remplies (le cas
où le mobile est lésé par ses voisins est symétrique) :
– L’index d’équité doit dépasser la valeur 1 augmentée d’une tolérance fixée ;
– La période d’adaptation de la fenêtre de contention actuelle doit être terminée ;
76
RÉSEAUX AD HOC
– L’évolution de l’index d’équité doit être supérieure à 0.9, ceci afin de rendre compte si la
situation s’est dégradée ou améliorée.
Si ces conditions sont remplies, la fenêtre de contention est multipliée par l’évolution de l’index
d’équité et de Wi , plutôt que par 2 (comme c’est le cas dans l’algorithme de base). On assure ainsi
que la fenêtre de contention est équilibrée et prend en compte l’évolution propre du débit du mobile.
6.2.2 Quelques résultats

Ce travail a été réalisé en fin de thèse, et je nous ne sommes malheureusement pas en mesure
d’apporter des résultats détaillés sur l’algorithme proposé. Néanmoins, quelques scénarios ont été
évalués afin de pouvoir comparer la version de base de Bensaou et al. et la version améliorée. Nous
avons effectué un certain nombre de simulation grâce à NS2.
Premier scénario à 2 paires. Le scénario utilisé est celui proposé initialement par Bensaou et
al. dans [48], il est présenté sur la figure 6.5. Dans ce scénario, il existe un flux entre A et C, ainsi
qu’un autre en B et D. Les trais en pointillés indiquent que B et C sont à portée de communication
mais ne s’envoient pas de paquets de données. Les flux de données sont constitués de paquets UDP
de 1000 octets. Le débit demandé par chacun des flux augmente avec le temps suivant la courbe
présentée sur la figure 6.6.
Sur la figure 6.7, on présente le débit de chacune des paires dans ce scénario si l’on utilise
802.11 tel qu’il est implanté dans NS2. A partir du moment où le débit demandé est suffisamment
important, on remarque le débit extrê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 problème est détaillé
dans [48], il provient de l’utilisation des RTS/CTS. Dans ce scénario, A ne peut communiquer avec
B, ni même détecter sa porteuse. Lorsque A veut envoyer un paquet de données à 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. A contrario, quand B veut envoyer des données à D,
il n’est pas gêné que si C a pu envoyer un CTS à A (et D n’étant à portée que de B, il peut
toujours répondre au RTS de ce dernier). A partir du moment où B arrive à envoyer un CTS, il
devient très difficile pour A d’obtenir un CTS permettant de lui envoyer des données, d’où les débits
déséquilibrés. Du fait des nombreux échecs de transmission que recontre le nœud A, sa fenêtre de
contention est en général très grande, comme on peut le voir sur la figure 6.8 (avec l’algorithme
de Binary Exponential Backoff, la taille de la fenêtre double à chaque echec, jusqu’à se stabiliser à
1031 time slots).
Dans [48], Bensaou et al. proposent une solution que nous avons implantée dans notre version de
NS2. Nous avons ensuite implanté la version modifié de cet algorithme décrite précédemment. Les
débits obtenus avec l’algorithme original de Bensaou et al. sont présentés sur la figure 6.9 et ceux
obtenus avec notre version le sont sur la figure 6.11. A partir du moment où le débit demandé est
suffisamment important, avec l’algorithme de Bensaou et al., le débit des deux flux est nettement
plus équitable qu’avec la version non modifiée de 802.11. Par contre, évoluant les deux entre 200
et 300 kbit/s, le débit agrégé est bien en dessous du débit maximum autorisé par le canal (dans
les mê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 très
longs avec l’algorithme de Bensaou et al. La taille des fenêtres de contention sont présentées sur la
figure 6.10, et l’on peut voir qu’elles sont la plupart du temps à leur valeur maximale (1023 time
slots).
77
RÉ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 – Débit demandé sur chaque flux en fonction du temps
Les débits obtenus avec la modification que nous proposons sont présentés sur la figure 6.11. On
peut voir que l’équité entre les deux flux est très bien respectée, et qu’avec environ 300-350 kbit/s
chacun, les deux émetteurs utilisent plus de bande passante qu’avec l’algorithme originel de Bensaou
et al . Ceci est confirmé par les tailles des fenêtres de contention de A et de B qui sont beaucoup
plus équilibrée, comme le montre la figure 6.12.
Second scénario à 2 paires. Nous avons ensuite légèrement modifié le scénario. La configuration
de cette deuxième simulation est celle de la figure 6.13. Le nœud A envoie toujours des données à
C et le nœud B en envoie toujours à D. Les débits demandés en fonction du temps sont toujours
ceux de la figure 6.6. Mais cette fois ci, A est à portée de détection de porteuse de D. Les débits
obtenus avec la version normale de 802.11 pour les flux (A→C) et (B→D) sont présentés sur la
figure 6.14. On remarque une fois de plus une très forte inégalité dans les débits. Les tailles des
fenêtres de contention (figure 6.15) montrent bien que nous avons affaire à un problème d’accès
au médium et non de collision. En effet, les fenêtres de contention des deux émetteurs restent
très basses durant toute la durée de la simulation. La figure 6.16 détaille le phénomène qui se
produit, et qui a pour origine le mécanisme des EIFS. Nous rappelons que les EIFS ont pour but
de protéger les acquittements dans le cas où un mobile a perçu de l’activité sur le canal mais n’a
pas pu comprendre le paquet. Si ce paquet était un paquet de données, alors son destinataire doit
l’acquitter. Si le mobile qui a détecté l’activité sans la comprendre é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
véritable destinataire du paquet envoie son propre acquittement. Dans ce scénario, B comprend
les paquets de A, et peut donc positionner son NAV correctement. Mais il ne peut que détecter
la porteuse sur les acquittements que D renvoie à B. De ce fait, à la fin d’un acquittement de D,
A passe en EIFS. Pendant ce temps, B peut tirer un nouveau backoff et le décrémenter au moins
en partie. Comme D comprend les CTS et ACK envoyés par C, D ne se trouve donc pas en EIFS
de façon symétrique. Il en résulte une forte inégalité dans l’accès au canal, puisque A a de grosses
difficultés à reprendre la main lorsqu’il la perd.
78
RÉ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
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 – Débit dans le scénario des deux paires Fig. 6.8 – Taille de la fenê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
800
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
(802.11 Bensaou) (802.11 Bensaou)
79
RÉSEAUX AD HOC
1.6e+06
A -> C (modif.) A (modif.)
B -> D (modif.) B (modif.)
1.4e+06 1000
1.2e+06

800
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
(802.11 modifié) (802.11 modifié)
D
Fig. 6.13 – La deuxième configuration à quatre nœuds
Nous avons ensuite testé l’algorithme de Bensaou et al (figure 6.17 pour le débit et figure 6.18
pour les fenêtres de contention). Sur ces figures, nous pouvons voir que cet algorithme ne donne
pas de bons résultats. Les fenêtres de contention restent en quasi permanence au minimum, et par
conséquent la situation est presque la même qu’avec 802.11 non modifié, c’est à dire une très grande
inégalité dans l’accès au canal.
Nous avons finalement utilisé notre propre algorithme (figure 6.19 pour le débit et figure 6.20
pour les fenêtres de contention). Nous voyons sur ces figures que grâce à une augmentation contrôlée
des fenêtre de contention, on arrive à obtenir des débits équitables et stables.
Conclusion Les résultats obtenus avec la modification que nous avons proposée de l’algorithme
de Bensaou et al. donne des résultats très encourageants. Non seulement il permet une bonne équité
dans des conditions qui tiennent 802.11 en échec, mais il permet aussi une meilleure utilisation de la
bande passante disponible. Notre algorithme a cependant certaines limitations. Pour fonctionner,
80
RÉSEAUX AD HOC
1.6e+06
A -> C (normal) A (normal)
B -> D (normal) B (normal)
1.4e+06 1000
1.2e+06

800
1e+06
600
800000
600000
400
400000
200
200000
0 0
0 2 4 6 8 10 0 2 4 6 8 10
Fig. 6.14 – Débit dans le deuxième scénario des Fig. 6.15 – Taille de la fenê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 problème dans la deuxième configuration à quatre nœuds
1.6e+06
A -> C (bensaou) A (bensaou)
B -> D (bensaou) B (bensaou)
1.4e+06 1000
1.2e+06
800
1e+06
600
800000
600000
400
400000
200
200000
0 0
0 2 4 6 8 10 0 2 4 6 8 10
deux paires (802.11 Bensaou) (802.11 Bensaou)
81
RÉSEAUX AD HOC
1.6e+06
A -> C (modif.) A (modif.)
B -> D (modif.) B (modif.)
1.4e+06 1000
1.2e+06

800
1e+06
600
800000
600000
400
400000
200
200000
0 0
0 2 4 6 8 10 0 2 4 6 8 10
deux paires (802.11 modifié) (802.11 modifié)
il a besoin d’ajouter des informations dans les RTS, qui doivent donc être utilisés (ce n’est pas
toujours le cas pour les paquets de données envoyés en unicast, et ne l’est jamais pour ceux diffusé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 scénario des trois
paires que nous avions étudié précédemment.
82
Deuxième partie
Expérimentations en environnement
ré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 général partielles, et parfois incorrectes.
Une simulation détaillée de la couche MAC peut être particulièrement coûteuse et inappropriée
pour des simulations à grande échelle. Et une simulation détaillée de la couche physique serait
inexploitable la plupart du temps car bien trop complexe et donc trop lente (si l’on ne considère
pas la mobilité, certaines techniques peuvent néanmoins être employées [61, 62].
Le travail des concepteurs des simulateurs consiste entre autre à simplifier le code simulé tout
en faisant en sorte que son comportement reste suffisamment réaliste. Mais cette notion de réalisme
varie en fonction de l’utilisation. Par exemple la simulation de la diffusion d’une vidéo dans un
réseau à points d’accès (un flux de paquets ré-émis uniquement par les stations de base et où des
pertes sont acceptées) ne sera pas affectée de la même façon par le manque de détail dans la couche
physique que le fonctionnement d’un protocole de routage ad-hoc (où la perte de quelques paquets
peut considérablement altérer la vision de la topologie, et où la perte d’un paquet par nœud de la
chaı̂ne de transmission en prive tous les nœuds suivants). Par conséquent, et particulièrement dans
le contexte des réseaux ad hoc, les résultats obtenus par simulation peuvent être différents de ceux
obtenus dans la réalité. Or très peu d’expériences ont été réalisées en contexte ad hoc. De plus, les
rares expériences menées avaient pour but d’évaluer différents protocoles de routage et non 802.11.
Comme les cartes 802.11 sont disponibles sur le marché, et que les matériels nécessaires étaient
suffisamment abordables, nous avons donc décidé de mener des séries de mesures. Nous avons ainsi
pu mener une première évaluation de 802.11 en environnent ad hoc réel. Nous avons également pu
comparer les mesures réelles aux simulations et nous assurer que les hypothèses faites à partir des
simulations sur le comportement de 802.11 dans un réseau ad hoc étaient correctes.
7.2 Les environnements de mesure

Dans un permier temps, il nous fallait réaliser des expériences simples, permettant de vérifier
que les cartes se comportaient comme prévu dans des situations standards (mesures de débit sans
interférences extérieures, portée, etc.). Il nous fallait ensuite pouvoir mettre en place des scénarios
représentant des utilisations caractéristiques des réseaux ad-hoc (communications multi-saut en
particulier). Et il nous fallait enfin obtenir des traces suffisamment détaillées sur le déroulement
de ces scénarios pour pouvoir conclure sur l’impact de 802.11 à 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 utilisées très largement dans les travaux sur les réseaux ad hoc, ce n’est
pas le cas des mesures en environnement réel. Cela vient du fait qu’il faut disposer du matériel
(les ordinateurs et les cartes réseau), mais aussi de la main d’œuvre. Autant il est aisé pour une
personne seule de développer et de conduire des simulations, autant cela s’avère difficile dès que
l’on cherche à reproduire dans la réalité des scénarios ad hoc.
7.2.1 Travaux antérieurs basés sur des mesures

Malgré la difficulté logistique de telles études, leur intérêt est certain, en particulier en tant que
complément des résultats des simulations. Plusieurs travaux, qui cherchent avant tout à évaluer
des protocoles de routage bien précis, mettent donc en œuvre des mesures réelles. Dans [63] et
[64] les auteurs évaluent DSR en utilisant quelques ordinateurs fixes et une demi-douzaine d’autres
embarqués dans des voitures se déplaçant sur le campus. Des récepteurs GPS (Global Positioning
System) sont utilisés pour connaı̂tre les positions précises de mobiles, et les données sont sauve-
gardées de manière à pouvoir être rejouées ensuite dans des simulations.
Dans [65], c’est ABR qui est évalué dans une configuration de un à trois sauts. Quatre mobiles
sont utilisés pour réaliser cette expérience. Ils sont cependant disposés à des distances maximales
de 50 mètres les uns de autres, les obstacles (bâtiments, arbres, etc.) empêchant le réseau d’être
entièrement maillé.
ODMRP quant à lui est évalué par des mesures réelles dans [66] grâce à sept ordinateurs
organisés dans des configurations multi-sauts. Dans certaines des expériences présentées, l’un des
ordinateurs se déplace d’ailleurs au cours de la mesure.
7.2.2 Ad hoc Protocol Evaluation (APE)

APE [67, 68] est un environnement dédié à l’évaluation des protocoles de routage des réseaux
ad hoc. Il est développé à l’université Uppsala en Suède où l’idée de le créer avait germé lorsqu’un
certain nombre d’étudiants avaient été équipés d’ordinateurs portables et de cartes réseau sans fil.
Le matériel et la main d’œuvre disponibles, il était en effet intéressant de les utiliser. APE est fourni
sous la forme d’une distribution Linux (RedHat) accompagnée d’un certain nombre d’utilitaires.
Les Wireless Tools [69] (un ensemble d’utilitaires permettant de configurer les cartes réseaux sans
fil et de récolter certaines informations sur leur fonctionnement telles que les niveaux de signal et
de bruit) sont utilisés pour configurer le matériel. Les cartes doivent être en particulier placées
en mode ad hoc (au sens de 802.11), et des adresses IP doivent être assignées à chaque machine.
L’objectif principal d’APE é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 à bien ces comparaisons, la reproductibilité des résultats est un élément
capital, aussi APE fournit-il un système permettant de régir par des scripts l’ensemble des actions.
Après une étape de synchronisation des horloges (une heure de déclenchement relative à l’heure de
début de la mesure est associée à chaque événement, d’où la nécessité d’une synchronisation au tout
début), les scripts contrôlant le déclenchement des différentes sources sont lancés. Les personnes
ayant en charge chacune des machines n’ont pas besoin de connaı̂tre les détails des scénarios ; des
informations elles aussi scriptées sont affichées pour leur donner les instructions de déplacement au
fur et à mesure.
Une fois une mesure terminée, les données sont centralisées sur une machine grâce à des uti-
litaires fournis. Un ensemble de programmes permet alors de traiter ces données et d’en tirer un
85
nombre important de métriques (taux de pertes de paquets, optimalité des routes, ...). Des outils
permettent également de générer des graphiques divers. Enfin, la notion de mobilité virtuelle est
définie et peut être calculée et affichée. Elle est calculée à partir des informations de niveau de signal
issues des Wireless Tools et les transpose en une information de distance perçue qui possède une
grande représentativité du scénario étudié (les mobiles dont on reçoit les paquets avec un niveau
de signal faible sont considérés comme loin).
Bien que virtuellement n’importe quelle application réseau puisse être utilisée, dans les articles
sur APE dont nous avons connaissance, les données envoyées sont des paquets ”ping” ICMP envoyés
à intervalles réguliers. Des flux avec des trafics si réduit sont couramment utilisés dans les simulation
destinées à tester les protocoles de routage (comme nous l’avons déjà mentionné dans le chapitre 4),
mais ne donne malheureusement pas forcément une bonne idée de ce qui se passe si le réseau est
ensuite chargé par une application quelconque.
Il faut noter que APE fournit aussi un utilitaire (mackill) permettant d’instaurer une topologie
virtuelle en forçant certaines machines à ignorer les paquets venants de certaines autres. Ceci est
particulièrement utile pour tester certains comportements des protocoles de routage sans avoir à
déplacer tous les mobiles dans la position multi-sauts adéquate. Ce mécanisme a une contrepartie
cependant : les effets des interférences (de l’environnement et des mobiles entre eux) sur les pro-
tocoles de routage ne seront pas forcément réalistes. Par exemple, il est possible de simuler une
chaı̂ne de 10 sauts en gardant tous les mobiles dans une seule pièce, mais il n’y aura alors aucune
réutilisation spatiale : un seul mobile pourra émettre à un instant donné .
7.3 Description de l’outil forwarding

Nous avons vu que les outils disponibles étaient surtout orientés sur l’évaluation de solutions
complètes (mobiles équipé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 à nos besoins. Plutôt que de chercher à
modifier des programmes existants, nous avons préféré développer un nouveau logiciel, qui se voulait
simple et spécialement adapté à nos mesures. Les caractéristiques retenues étaient les suivantes :
Un programme simple. Comme nous cherchions à réaliser quelque chose de simple, le pro-
gramme (appelé forwarding) a été écrit en langage C. Il fonctionne sous linux, et s’appuie sur les
wireless tools [69]. Pour des raisons pratiques, le programme a été installé sur un cdrom bootable
de linux, accompagné des outils nécessaires pour sauvegarder temporairement les résultats sur des
partitions aussi bien linux que windows. Il était ainsi assez aisé de réaliser nos mesures sur divers
portables, en fonction de ce que l’on pouvait emprunter le jour de l’expérience (dans certaines
mesures, nous avons utilisé jusqu’à 8 portables simultanément). A la fin de l’expérience, les fi-
chiers de résulats (qui pouvaient occuper plusieurs centaines de mega-octets) étaient centralisés
sur une machine fixe avant d’être dépouillés. A noter également que la version de linux sur le CD
était minimaliste, afin d’éviter des interférences avec des démons ou autres processus utilisant des
ressources.
Le programme lui-même, une fois lancé, présente une simple ligne de commande où l’utilisateur
peut à loisir configurer divers paramètres, afficher en temps réels des informations sur les paquets
reçus, et surtout démarrer ou arrêter des sources de données.
86
Pas de protocole de routage. Nos objectifs initiaux étaient entre autres de mesurer les in-
terférences entre nœuds voisins lorsque l’on ré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’idée était qu’au niveau de chaque nœud on pourrait ainsi recevoir et garder une trace des paquets
qui ne nous étaient pas réellement destinés et qui étaient néanmoins reçus avec suffisamment de
puissance. Ceci avait pour but de rendre l’analyse plus facile et plus complète.
Afin de gérer les communications multi-sauts, notre programme avait donc la charge d’effectuer
ou non une ré-émission des paquets, en fonction de règles établies préalablement à la mesure. Ces
règles de ré-émission (ou de routage statique) avaient comme autre objectif de nous libérer des
effets non désirables que les protocoles de routage normaux pouvaient provoquer dans nos mesures.
Comme nous nous concentrions sur l’étude de 802.11, les time-out, la sélection non contrôlée des
routes ou les paquets de contrôle générés par un protocole de routage auraient brouillé nos mesures
et rendu les résultas difficilement exploitables.
Ces règles de routages conditionnaient la ré-émission des paquets reçus en fonction d’identifiants
de flux portés par les paquets et / ou des nœuds desquels ils nous arrivaient (champ last-hop dans
l’entête des paquets).
Des flux UDP à débit constant. Là encore, nous voulions nous affranchir au maximum des pro-
tocoles supérieurs à 802.11 qui auraient pu masquer certains résultats. TCP en particulier présentait
de nombreux problèmes. D’une part il générait du traffic supplémentaire dans les deux sens (ac-
quittements et autres paquets de contrôle), mais en fonction de la taille des fenêtres d’émission et
de l’arrivée à temps ou non des acquittements, TCP risquait en plus de détecter une congestion du
réseau et d’y réagir en modifiant encore la taille de sa fenêtre. Il serait alors devenu particulièrement
difficile de savoir si un paquet quelconque avait été vraiment perdu suite à un problème au niveau
de 802.11 ou si on avait eu affaire à l’arrivée en retard d’un acquittement par exemple. Il aurait été
également très difficile avec seulement quelques machines de mesurer les effets de la saturation de
la bande passante physique (si TCP décide de très fortement réduire la taille de sa fenêtre suite à
quelques pertes interpretées comme de la congestion, alors le canal radio sera sous-utilisé).
Nous avons donc préféré n’utiliser qu’UDP, qui nous permet un bien meilleur contrôle des
paquets effectivement envoyés dans les air. Sur chaque nœud, jusqu’à 10 sources UDP à débit
constant peuvent être configurées. Chaque source se voit attribuer un numéro de flux unique à
l’échelle du réseau qui permet d’identifier les paquets de manière unique. La taille des paquets
envoyés ainsi que le débit de ces sources sont configurables de manière très précise.
Des fichiers de trace détaillés. Chaque réception de paquet par un nœud est consignée dans un
fichier de trace, avec la date locale précise du nœud ainsi que des informations diverses (numéro de
séquence, nom de l’émetteur originel, nom du dernier ré-émetteur (last-hop), taille, ...). Un fichier
de trace optionnel peut contenir des informations complémentaires sur le niveau de signal pour
chacun de ces paquets. Mais il s’agit de l’information retournée par le pilote de la carte 802.11 et
par conséquent elle n’est mise à jour qu’à chaque réception de paquet (cela signifie que forwarding
n’est pas capable d’indiquer le niveau de bruit ambiant en dehors des moment où il reçoit des
paquets, entre autres). Une fois les mesures terminées, les différents fichiers de trace sont regroupés
et combinés. Ensembles ils permettent de reconstituer l’historique précis de tout ce qui s’est passé
dans le réseau. Les problèmes d’horloge sont gérés par forwarding. Des outils de synchronisation lui
sont intégrés et seront détaillés par la suite.
87
Il faut noter que notre programme n’utilise pas de mécanisme particulièrement optimisé pour
la sauvegarde des informations au fur et à mesure de le l’expérience. Dans la pratique, dans les
pires cas un nœud n’avait à écrire que quelques dizaines de milliers d’octets par seconde. Ecrire
directement sur le disque (qui de toute façon dispose de tampons gérés par le système et de tampons
internes) était donc suffisant pour nos besoins. Nous n’avons pas utilisé de mécanisme avancé tel
que la sauvergarde dans un disque virtuel en mémoire vive, qui aurait de toute façon été trop petit
par rapport à la quantité de données récoltées dans certaines de nos mesures les plus longues.
7.3.1 Architecture du logiciel

Forwarding est un programme multi-threads. Au démarrage du programme un ensemble de
threads est initialisé.
L’un d’eux va servir pour les réceptions. Il est en attente constante de paquets venant du
réseau. Lorsqu’un paquet arrive, il applique des règles de filtrage (en particulier un nœud reçoit les
paquets qu’il a lui-même diffusé et il faut les éliminer), puis il inscrit ce paquet dans son fichier de
trace, avant de le traiter et éventuellement de le ré-émettre. Ce thread s’occupe aussi de la gestion
de l’interface avec l’utilisateur (affichage périodique d’informations et lecture des commandes au
clavier et / ou dans des scripts).
Les autres sont utilisés pour générer le traffic Le fait d’utiliser un thread séparé pour
chaque flux évite de mettre en place un système complexe d’ordonnanceur, mais en contre-partie
une légère latence peut être introduite à cause de changements de contexte. Heureusement son
impact est négligeable sur des machines comme celles que nous avons utilisées (au minimum des
Pentium II à 300 MHz).
Dans forwarding, le temps est compté en secondes à partir du lancement du programme. Par
exemple, on peut démarrer un flux à la seconde 100 et l’arrêter à la seconde 150. Evidemment,
puisque le programme n’est pas lancé exactement au même moment sur chacune des machines, il y
a une certaine désynchronisation. Ce problème est en partie résolu grâce à la possibilité de diffuser
un paquet spécial qui force un changement de la date locale au moment de sa réception. L’idée est
que lorsque qu’un paquet est diffusé, tous les nœuds du voisinage le reçoivent au même moment.
L’envoi de ce paquet appelé SYNC est une chose à faire au début de chaque mesure (si des paquets
ont été envoyés avant, il faudra les éliminer des traces car il ne seront pas dans la même échelle de
temps).
Il faut noter aussi que si le programme a été originellement conçu pour envoyer les paquets
en mode diffusion, il est néanmoins capable de les envoyer en unicast. Cela est en particulier
nécessaire lorsque l’on veut mesurer l’impact des acquittements, des RTS/CTS, ou des débits phy-
siques supérieurs à 2Mbit/s (la diffusion est limitée par la norme 802.11 à 2Mbit/s). Les commandes
de création de source ou de mise en place de règles de répétition prennent une adresse IP en pa-
ramètre optionnel. Mais de ce fait il est important qu’avant la mesure proprement dite tous les
nœuds aient été à portée de communication et que des paquets aient été échangés (ping rempli très
bien ce rôle). Cela permet à ARP construire sa table d’adresses MAC des cartes des autres nœuds
et évite que les requêtes ARP soient ensuite mêlées aux paquets de données.
88
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-tête utilisée par forwarding pour tous ses paquets
Nom de l’option Effet

-id détermine l’identifiant unique du nœud
-traceFile spécifie le nom du fichier de trace à utiliser
-qualityTraceFile active l’enregistrement des informations de niveau de signal et de bruit
-script démarre automatiquement le script spécifié après le lancement du programme
-traceSelfDiscard En mode diffusion, les nœuds reçoivent et éliminent leurs propres paquets.
Cette option permet de mémoriser quand même ces paquets.
Tab. 7.1 – Principales options de lancement
7.3.2 Format des paquets

Tous les paquets utilisés par forwarding partagent une en-tête commune (voir figure 7.1) où sont
décrits leur type (DATA ou les diverses variantes de paquets de contrôle ou de synchronisation),
leur source, leur destination, leurs numéros de séquence et leur taille. Cette en-tête a une taille
fixe de 32 octets et il faut noter que les tailles de paquets données sur les nombreuses courbes qui
seront présentées plus tard n’incluent pas toujours cette en-tête (l’inclusion ou non de l’en-tête dans
les valeurs mesurées sera précisée pour chaque courbe). Les nœuds sont identifiés sous forwarding
grâce à un numéro unique donné manuellement au lancement du programme. Lors du démarrage
d’une source de données, un numéro de flux est attribué manuellement à cette source et on peut
ainsi retrouver facilement tous ses paquets (pour les paquets de contrôle, le numéro de flux est
arbitrairement fixé à zéro). Deux numéros de séquence sont gérés : l’un est propre au nœud et est
incrémenté à chaque fois qu’il envoie un paquet, quel qu’en soit le type, l’autre est propre à chaque
flux, et n’est incrémenté que lors de l’envoi de paquets appartenant à ce flux. Le champ du dernier
émetteur est évidemment mis à jour à chaque ré-émission du paquet.
En plus de leur en-tête, les paquets comportent un champ de données (dont la taille est spécifiée
dans l’en-tête). Dans le cas des paquets de contrôle, ce champ contient une commande ou un résultat
d’exécution, dans le cas des paquets de données, ce champ est rempli de zéros pour constituer la
charge utile.
7.3.3 Les commandes disponibles

Un certain nombre d’options peuvent être spécifiées au lancement du programme, les plus
importantes sont présentées dans la table 7.1
89
Une fois le programme lancé, une ligne de commandes est présentée à l’utilisateur. Les princi-
pales commandes sont détaillées dans la table 7.2.
Avec forwarding nous avons donc à disposition un outil qui va nous permettre de tester des
scénarios sur des réseaux ad hoc et de mesurer les performances de 802.11 sans être perturbés par
les protocoles des couches supérieures.
90
Nom de la commande Description

sync [time] synchronise les horloges sur toutes les machines
à portée.
setTime time définit le temps local.
time affiche le temps local.
affichePaquetsRecus 0 | 1 chaque seconde, affiche combien de paquets ont
été reçus, de qui, et à quels flux ils appar-
tiennent.
pingAll diffuse un paquet ping auxquels tous les nœuds
doivent répondre par une paquet pong.
startCBR numSourceThread flowID idSource démarre un flux CBR. L’émetteur, la taille du
delay packetSize [destinationIP] paquet, le délai entre deux paquets consécutifs
et le numéro de flux doivent être spécifiés. Une
adresse IP optionnelle peut être utilisée pour
forcer l’envoi à un destinataire unique.
stopCBR numSourceThread numNode arrête un flux CBR spécifié par le numéro du
nœud et le numéro du thread source qui le
génère.
addForwardingRule idNode flowID IDLas- les paquets ayant le numéro de flux et l’iden-
tHop [destinationIP] tifiant de dernier nœud traversé identiques à
ceux spécifiés seront répétés. Une adresse IP
optionnelle permet de forcer la ré-émission vers
une cible unique.
deleteForwardingRule idNode flowID ID- efface une règle établie grâce à la commande
LastHop précédente.
execScript scriptName exécute le script spécifié.
execCommand shellCommand exécute la commande shell spécifiée.
setPhyTraceList adresses IP les wireless tools ne ”remontent” les informa-
tions de qualité de signal et de bruit que pour
les nœuds dont les adresses ont été spécifiées.
Tab. 7.2 – Les commandes les plus représentatives
91
CHAPITRE
Les premières mesures
8
Au fur et à mesure du développement de forwarding, nous avons réalisé des mesures ; elles
avaient le triple but de tester le programme, d’évaluer 802.11 dans un environnement ad hoc réel,
mais aussi de comparer à la réalité les simulations que nous avions réalisées auparavant avec Network
Simulator.
8.1 Justifications des données mesurées.

Par la suite, nous allons régulièrement présenter des courbes montrant différentes valeurs me-
surées au cours de nos expérimentations. Il est important de préciser de quelle manière ces valeurs
sont obtenues et, le cas échéant, calculées.
Les débits. Pour un flux donné nous avons vu que les paquets ont toujours la même taille.
Lorsque nous analysons les fichiers de trace, nous comptons le nombre de paquets par unité de
temps répondant à un même critère (au moins le numéro de flux, mais parfois plus, comme par
exemple le last-hop) et nous multiplions par la taille des paquets.
Les durées de transmission. Nous présenterons parfois des histogrammes décrivant la distri-
bution de la durée de transmission des paquets. Dans la pratique, nous n’avons pas de moyen de
mesurer directement une telle durée. Nous savons à quel moment l’application envoie le paquet au
pilote, et nous savons à quel moment le paquet est reçu par l’autre mobile ; par contre nous ne
savons pas à quel moment la carte 802.11 a réellement émis le paquet (si elle a trouvé le canal radio
occupé, elle a pu attendre un certain temps avant qu’il ne devienne libre pour elle). Pour réaliser les
histogrammes que nous présentons, nous nous sommes donc toujours placé dans une situation où
une seule source saturait complètement la bande passante, et où aucune interférence externe n’était
présente. Comme le canal était complètement saturé, il devenait possible de connaı̂tre la durée de
transmission en faisant la différence entre les dates de réception de deux paquets consécutifs.
8.2 Le débit en fonction de la taille des paquets

Notre toute première expérience consiste à mesurer le débit effectif dans la configuration
présentée sur la figure 8.1, où un émetteur envoie des paquets à un récepteur situé juste à coté
de lui.
Les paquets UDP comportent un champ de données d’une taille comprise entre 82 et 2532
octets, par incrément de 50 octets. La figure 8.2 présente les résultats des mesures pour différentes
92
CHAPITRE 8. LES PREMIÈ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 débit en fonction de la
taille des paquets (bande passante Fig. 8.2 – Débit utile en fonction de la taille des paquets
saturée) UDP
vitesses de transmission, ainsi que lorsque l’on utilise le système de cryptographie WEP (Wired
Equivalent Privacy) décrit la norme 802.11. Les observations sont les suivantes :
8.2.1 La fragmentation à 1500 octets

La première chose que l’on remarque est le phénomène de décrochement lorsque la taille des
paquets dépasse les 1500 octets. Ce phénomène est lié à la couche IP qui croit avoir affaire à une carte
Ethernet (802.3) et qui cherche à optimiser la taille des paquets pour é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 dé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 supérieures à 1000 octets environ, les performances deviennent sensiblement
inférieures à ce qu’elles sont si on n’utilise pas le WEP (la courbe de débit paraı̂t écrêtée). Nous
avons réalisé de nombreuses expériences pour comprendre ce phénomène qui était tout à fait re-
productible mais qui ne concernait que les communications à 11 Mbits/s et pas celles aux débits
inférieurs. La source du problème apparaı̂t mieux lorsque l’on présente la distribution des durées de
transmission des paquets. La figure 8.3 montre deux histogrammes représentant chacun les durées
de transmissions pour une douzaine de milliers de paquets de 900 et de 1400 octets. La taille de
900 octets a été choisie car d’après la figure 8.2 les flux de paquets de cette taille ne subissent pas
de perte de débit dû au WEP. La distribution théorique est un rectangle (ce qui est normal étant
donné que la durée de transmission d’un paquet d’une certaine taille est composée d’une partie fixe
et du backoff qui est tiré de manière aléatoire et équiprobable entre deux bornes). La distribution
mesurée pour des paquets de 900 octets est proche de la distribution théorique. On peut juste
remarquer un biais du générateur aléatoire qui fait que les paquets ayant des backoffs très courts
93
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 durée de transmission d’une trame
sont un peu plus nombreux que la moyenne. A ce sujet on peut noter que des cartes présentant
ce type de biais bénéficie d’un débit légèrement supérieur à celui de carte ayant une distribution
plus équitable (en moyenne elles attendent en petit peu moins longtemps avant d’envoyer leurs
données). Par contre dans un environnement où toutes les cartes ont ce biais, cela va se traduire
par une hausse du taux de collision. Ceci est une chose à garder à l’esprit lorsque l’on compare les
performances des cartes de différents constructeurs.
Toujours d’après la figure 8.2, des problè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 durées de transmission des paquets de 1432 octets reflète et permet d’expliquer
ce phénomène. La distribution théorique tout d’abord est logiquement décalée vers la droite (durée
de transmission en moyenne plus longue que celles de paquets de 1032 octets), puisque la partie
fixe de la durée de transmission d’un paquet dépend de sa taille. Mais on remarque tout de suite
deux sous-ensembles dans les durées de transmission effectives. Un certain nombre de paquets
ont été transmis en un temps conforme aux prévisions, mais les paquets du deuxième groupe ont
mis beaucoup plus de temps. De plus l’étalement du deuxième groupe (double de l’étalement du
premier) et sa position (deux fois plus loin) indiquent clairement que ces paquets n’ont étés reçus
qu’après une ré-émission (le backoff est tiré deux fois, d’où l’étalement double).
La raison profonde de cette ré-émission nous est pour l’instant inconnue, le mécanisme du WEP
n’étant pas sensé poser ce genre de problème. Malheureusement le WEP est implanté dans le BIOS
des cartes 802.11 et n’y ayant pas accès nous n’avons pas pu pousser plus loin nos investigations.
Peut-être ce problème se pose-t-il lorsque que le processeur embarqué sur la carte arrive à ses limites
(cryptage/décryptage de gros paquets au débit maximum supporté). Quoi qu’il en soit, dans la suite
de nos expérimentations nous avons décidé de ne plus utiliser le WEP.
94
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 débits théoriques et mésurés à différentes vitesses et en fonction de la
taille des paquets.
Remarquons que si sur la figure 8.2 l’effet négatif du WEP à 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 divisé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 mentionné car en dehors du cadre de ce travail, il faut noter que le
niveau de sécurité du WEP est en réalité assez faible.
8.2.3 Hormis les problèmes pré-cités, des débits très proches de la théorie
Les débits mesurés sont donc extrêmement proches des débits calculés par la théorie, comme on
peut le voir sur la figure 8.4. Mais on peut cependant noter que les débits utiles sont très éloignés
des débits physiques. Cela est spécialement flagrant lorsque l’on utilise des paquets de petite taille
(le débit utile avec des paquets de 82 octets et plus de 7 fois inférieur au débit utile avec des paquets
de 1432 octets) ou que la fragmentation à 1500 octets force la division de gros paquets en un paquet
de 1500 et en un autre plus petit (le débit diminue de 50% environ lorsque la taille passe de 1450
à 1500 octets)
95
8.3 Partage du canal entre nœuds à portée de communication

8.3.1 Deux flux (combinaisons d’émetteurs et récepteurs)
Après nous être intéressés à la capacité du canal lorsqu’il n’y a qu’un seul émetteur, nous nous
sommes ensuite tournés vers des scénarios où plusieurs émetteurs proches les uns des autres sont
en contention pour l’accès au médium.
Nous avons tout d’abord utilisé quatre mobiles situés dans la même pièce (et donc à portée de
communication directe), et nous avons réalisé les diverses combinaisons de flux présentées sur la
figure 8.5. Les flux de données étaient constitués de paquets UDP de 1000 octets, envoyés aussi vite
que possible. Les cartes étaient configurées pour fonctionner à 11 Mbit/s sans utiliser de RTS/CTS.
Les résultats de cette expérience sont présentés sur la figure 8.6 et peuvent être interprétés de
la façon suivante (l’ordre n’est pas chronologique, mais présente les situations les plus simples en
premier) :
– secondes 175 à 195 : Il n’y a qu’un seul flux (de 3 vers 2), et donc aucune contention. On
obtient le débit maximum observé dans les expériences précédentes dans les mêmes conditions,
soit un petit peu plus de 600 paquets de 1000 octets par seconde.
– secondes 120 à 125 et 150 à 165 : Il n’y a qu’un seul flux (de 1 vers 2 cette fois-ci). On
obtient là encore le débit maximum.
– secondes 100 à 120 et 125 à 150 : Il y a deux flux en contention. On observe la même
chose que les récepteurs soient deux nœuds différents ou non. On remarque immédiatement
une différence de débit entre les deux flux (l’émetteur 1 accède un peu moins souvent au canal
que l’émetteur 2). Les cartes 802.11 utilisées étaient à priori les mêmes, et ce phénomène peut
probablement être imputé soit à l’hétérogénéité de nos machines, soit à des différences non
documentées entre nos cartes (de même marque et de même modèle). Il est important de
remarquer que la somme des deux flux simultanés est légèrement supérieure au débit obtenu
par un flux unique isolé. Ce phénomène s’explique par la décrémentation en parallèle des
backoffs sur chacun des émetteurs. En effet, lorsque dans ce scénario le canal devient initiale-
ment libre, les deux stations choisissent un backoff aléatoire et commencent à le décrémenter.
Dès que l’une d’elles a terminé, elle émet et bloque la décrementation de l’autre station.
Mais quand le canal redevriendra libre, l’autre station reprendra la décrémentation là où elle
s’était arrêtée (au lieu de tirer un nouveau backoff), et statistiquement finira donc rapidement
sa propre décrémentation. Finalement, on observe une diminution de la durée moyenne du
temps d’inactivité séparant deux trames (de sources différentes) sur le canal, et donc une
augmentation du débit.
8.3.2 Flux multiples

Dans ce scénario, nous avons observé l’activité sur le canal radio alors qu’un nombre croissant
de flux étaient en contention pour y accéder. Comme précédemment, les mesures ont été effectuées
avec des paquets UDP, les RTS/CTS n’étaient pas utilisés et le débit nominal était de 11 Mbit/s.
L’expérience est divisée en 7 phases (voir figure 8.7, où à chaque étape un flux supplémentaire est
activé), et où chaque phase est elle-même divisée en 5 périodes de 20 secondes où les flux sont
constitués de paquets d’une taille donnée (200, 500, 1000, 1400 et 2000 octets, dans cet ordre).
La figure 8.8 présente les débits agrégés en paquets par seconde (c’est à dire la somme des débits
des différents flux). Comme on pouvait s’y attendre, on voit bien que pour une étape donnée, plus
96
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 à portée de 0
communication 100 120 140
time in seconds
160 180 200
Fig. 8.6 – Débit quand deux paires sont à porté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 à sept flux simultanés number of simultaneous flows
Fig. 8.8 – Debits cumulés pour un à sept flux se parta-

geant le canal
97
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 émetteurs
sont en contention
les paquets sont petits, plus ils sont nombreux à être envoyés au cours d’une seconde. Mais on
remarque aussi que lorsque le nombre d’émetteurs en contention augmente, le débit total augmente
lui aussi légèrement. Ceci est du au phénomène détaillé dans l’expérience précédente. Lorsque le
canal devient libre, tous les nœuds ont des paquets à envoyer, et décrémentent donc leur backoff
en parallè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 réoccupé. 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 débit
sur chacun de leurs backoffs. Evidemment, ce phénomène est progressivement contrebalancé par les
collisions. Plus il y a de flux en contention, plus les chances sont grande que deux nœuds aient fini
en même temps de décrémenter leurs backoffs et émettent en même temps. A partir de cinq flux en
contention, le débit global n’augmente donc plus.
La figure 8.9 présente la distribution du temps séparant deux paquets consécutifs de 1000
octets lorsque 7 émetteurs sont en contention. Contrairement à ce que l’on avait pu observer dans
la figure 8.3 où il n’y avait qu’un seul flux et où la distribution était assez homogène, ici on voit un
regroupement des écarts vers les valeurs les plus basses (la durée minimale de transmission de nos
paquets, lorsque le backoff tiré 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 à fait en adéquation avec
nos remarques précédents sur l’augmentation du débit lorsque le nombre de flux augmente.
En sus du pic principal, on remarque qu’un certain nombre de paquets on été transmis en un
temps environ doublé par rapport à la majorité (pic vers 2.5 ms). Ces paquets sont en fait ceux qui
ont subi une collision et qui ont du être réémis. Dans ce graphique, dans 93.25% des cas, le temps
séparant deux paquets consécutifs était de moins de 2000 µs. Cela signifie que le taux de collision
était finalement assez faible malgré la présence de 7 émetteurs (6.75% seulement des paquets ont
eu besoin d’une réémission).
8.4 Les mesures de portée

L’étape suivante dans l’analyse du comportement de 802.11 dans le contexte des réseaux ad-hoc
est l’étude de la portée de communication réelle. Nos objectifs à plus long terme étaient évidemment
98
de réaliser des mesures dans des configurations typiquement ad-hoc telles qu’une chaı̂ne, et la portée
de communication est une donnée dont nous avons besoin pour préparer ces futures mesures.
Nous avons vu dans le chapitre qui leur est dédié que les simulateurs considèrent en général
que les zones de communication sont circulaires et centrées sur le mobile (avec des variantes, telle
que le modèle shadowing qui ajoute une probabilité de perte des paquets sur le bord de ce cercle).
Les expériences décrites dans ce chapitre avaient pour but de comparer la réalité avec ces résultats
théories.
8.4.1 L’environnement et le outils de mesure

Le matériel utilisé. Comme dans les autres expériences, nous utilisons forwarding sur des por-
tables PC démarrés avec notre CD de linux. Dès ces premières expériences en extérieur, il est
important de noter que le matériel joue un grand rôle. La longévité des batteries en particulier est
largement affectée par la température, et il faut en tenir compte lors de la conception des scénarios
de mesure et des scripts de commandes. Les cartes radio utilisées sont des cartes Orinoco ou Wave-
Lan de Lucent Technologies, elles émettent avec une puissance de 15 dBm et utilisent leurs antennes
intégrées.
L’environnement. L’environnement n’est jamais neutre ; comme ces mesures de portée sont
préparatoires pour des mesures sur des configurations véritablement ad hoc, nous avons choisi de
les effectuer en extérieur, dans un environnement suffisamment dégagé. Nous avions en effet effectué
des mesures préalables en intérieur, et il était rapidement apparu qu’il était impossible d’y mettre
en place une configuration avec une chaı̂ne d’une longueur supérieure à deux sauts (notre bâ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 expé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
homogénéité dans l’environnement (bordé d’un coté par une route, de l’autre par un parc que l’on
surplombe de quelques mètres). Le muret nous fournit le support pour poser nos portables.
8.4.2 Les résultats

Afin d’évaluer la portée de communication de nos cartes, nous utilisons deux portables ini-
tialement très proches l’un de l’autre et que l’on éloigne par étapes successives. La vitesse de
transmission physique est de 11Mbit/s. A chaque étape, le mobile émetteur envoie à l’autre des
rafales consécutives de paquets de différentes tailles (200, 500, 1000 et 1400 octets) et qui durent
chacune une vingtaine de secondes. L’orientation des machine a un impact tout à fait remarquable
sur les résultats, et nous répétons donc nos mesures dans diverses positions. Les débits obtenus en
fonction de la distance, de la taille des paquets et de l’orientation des cartes sont présentés sur la
figure 8.12. Plusieurs remarques importantes peuvent êtres faites :
– En fonction de l’orientation des cartes, la portée de communication varie grandement (d’un
facteur supérieur à 2 entre la position la plus et la moins favorable). Cartes émettrices et
réceptrices dos à dos, le débit utile est déjà grandement affecté à une distance de 45 mèttres,
99
route
terre-plein central
route
piste
muret
parc (en contre-bas)
Fig. 8.10 – L’environnement pour les mesures de

portée
Fig. 8.11 – L’environnement pour les mesures
de portée
alors que face à face il ne commence à baisser qu’à partir de 75 mètres et que les communi-
cations restent possibles jusqu’à 150 mètres environ. Sur les figures 8.14 et 8.15 sont indiqués
les niveau de signal et de bruit mesurés pour chacun des paquets correctement reçus. On re-
marque l’affaiblissement de la puissance du signal (de l’ordre de 10dBm en moyenne) lorsque
les antennes sont dos à dos (figure 8.14) plutôt que face à face (figure 8.15). Il faut noter
aussi que l’orientation de la carte réceptrice est tout aussi importante que celle de la carte
qui émet, comme on peut le voir avec les différences entre les mesures dans les positions 1 et
2 de la figure 8.12.
– A part à courte distance où l’on obtient bien celui prévu, une grande instabilité dans le débit
utile apparaı̂t. A une distance fixée (par exemple 90 mètres dans le cas des cartes face à face),
le débit varie grandement en fonction du temps. L’environnement réel est loin d’être stable
comme le prédisent les modèles simples de propagation dans les simulateurs. Là encore, cette
instabilité est confirmée par les niveaux de signal et de bruit mesurés (figures 8.14 et 8.15)
qui varient dans une plage de 10 dBm à une distance fixée.
– Pour chacune des distances, les mesures ont été effectuées avec 4 tailles de paquets différentes.
On aurait pu penser que les gros paquets seraient plus affectés que les petits par la qualité
du lien radio car ils durent plus longtemps et auraient ainsi plus de chances de subir des
interférences. La figure 8.13 présente les mêmes données que la figure 8.12, mais avec un
lissage (en ordonnée, on peut lire le nombre de paquets reçus par intervalle de 4 secondes
au lieu d’une seconde). A courte distance (15 à 60 mètres), on remarque que les débits en
paquets par seconde diminuent avec la taille des paquets de manière prévisible. Mais plus loin
(par exemple 90 ou 135 mètres), on se rend compte qu’il n’y a pas forcé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 débit utile supérieur à courte distance, mais il apparaı̂t aussi qu’ils
ne sont pas pénalisants quand la distance augmente et que les interférences deviennent sévères.
– Toujours sur la figure 8.12, on peut remarquer que le taux d’échec dans la réception reste
parfois stable pendant certaines périodes. Par exemple à 75 mètres dans la 5ème position,
il semble qu’au milieu de la phase d’envoi des paquets de 200 octets les interférences soient
subitement devenues plus fortes. Une observation attentive des résultats montre que ce type
de phénomène se produit à différentes échelles (parfois ce sont quelques paquets consécutifs
100
débit en paquets reçus par seconde

1200
paquets de 200 octets
1000 paquets de 500 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
600
500
400
Position 2 300
200
100
0
15m 30m 45m 60m 75m
distance en metres

600
500
400
Position 3 300
200
100
0
15m 30m 45m 60m 75m 90m 105m 120m 135m 150m
distance en metres
1000
600
500
400
Position 4 300
200
100
0
15m 30m 45m 60m 75m 90m 105m
distance en metres
1000
600
500
400
Position 5 300
200
100
0
15m 30m 45m 60m 75m 90m 105m
distance en metres
Fig. 8.12 – Débits mesurés en fonction de la distance, de la taille des paquets et de l’orientation
des antennes (vitesse d’é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 différent de ce que l’on peut observer avec les
modèles classiques de propagation dans les simulateurs. Au mieux, le modèle shadowing va
produire par exemple un taux de perte non nul mais stable à une distance donnée.
La figure 8.16 présente quand à elle les débits mesurés lorsque la vitesse d’émission est forcée
à 2 Mbit/s. La tendance générale en fonction de l’orientation des cartes est sans surprise assez
semblable à ce que l’on avait observé à 11 Mbit/s. Lorsque les cartes sont face à face (position 3),
elles peuvent communiquer jusqu’à une distance nettement plus grande que lorsqu’elles sont dos à
dos (position 2), et la position 6 permet une portée intermédiaire. Mais si la tendance en fonction
de l’orientation est semblable, ce n’est pas le cas de la portée qui est logiquement beaucoup plus
grande. Cette fois-ci, des paquets peuvent être reçus jusqu’à 300 mètres environ si l’orientation est
101
Fig. 8.13 – Débits lissé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
Position 2
Position 3
Position 6
Fig. 8.16 – Débits mesurés en fonction de la distance, de la taille des paquets et de l’orientation
des antennes (vitesse d’émission de 2 Mbit/s)
favorable (position 3). On peut noter également que la portée réelle reste quand même en général
très nettement inférieure à celle prévue par la simulation. Rappelons que pour un débit physique de
2 Mbit/s, le modèle freespace de NS2 prévoyait une portée de 600 mètres sans dégradation, que le
modèle shadowing prévoyait de ne pas avoir de dégradation avant 250 mètres et ensuite des pertes
de plus en plus importantes jusqu’à 700 mètres, et qu’enfin le modèle two-ray ground prévoyait que
jusqu’à 250 mètres on pourrait avoir le débit maximum et plus rien au-delà.
Tout comme on avait pu le voir à 11 Mbit/s, on observe enfin une certaine instabilité à partir
d’une certaine distance (au-delà de 200 mètres pour la position 3, au-delà de 100 mètres pour la
position 6).
103
CHAPITRE
Les outils d’analyse avancée
9
Nous avons vu précédemment qu’un chronogramme pouvait être un bon outil pour analyser
finement ce qui se passe, en particulier dans un réseau ad hoc. Nous cherchons donc à reproduire
le même type de graphique que ceux obtenus pour les simulations sous Network Simulator.
Cependant, alors que NS dispose d’une horloge globale et commune à tous les mobiles simulés,
des problèmes se posent lorsque l’on passe à l’expérimentation en environnement réel. Les horloges
des différents portables ne sont pas synchronisées, et quelques expérimentations nous montrent
qu’elles dérivent les unes par rapport aux autres d’une manière que l’on ne peut négliger.
Afin de produire des chronogrammes utilisables, il nous est donc indispensable de comprendre,
quantifier et corriger ces problèmes.
9.1 Les chronogrammes en environnement réel

Les modifications que nous avons apportées à NS nous permettaient de récupérer directement
toutes les informations dont nous avions besoin pour tracer les chronogrammes. Par exemple, nous
avions les dates de début et de fin d’émission physique, les débuts, pauses, reprises, fins de backoffs,
les DIFS, etc. En environnement réel, nous ne disposons que de la date de réception des paquets et
de leur taille. Cependant, comme nous pouvons déduire la durée d’un paquet à partir de sa taille
et de la vitesse d’émission, il reste possible de construire un chronogramme utile bien qu’un peu
moins complet. Certaines précautions doivent être prises cependant, comme par exemple lorsque les
paquets sont envoyés en unicast et qu’il faut prendre en compte les acquittements qui n’apparaissent
pas dans les traces.
9.2 Le problème de la synchronisation

Dans forwarding, un mécanisme simple de synchronisation a été intégré très tôt. Il tire parti
d’une propriété des réseaux radio : tous les mobiles qui reçoivent un paquet diffusé savent qu’ils le
reçoivent à la même date (il n’y a pas de ré-émission, les délais de propagation des ondes sont tout
à fait négligeables dans ce contexte et le paquet envoyé par forwarding contient sa date d’émission,
ce qui permet d’ajuster les horloges des mobiles le recevant de façon à ce qu’elles soient toutes
synchronisées). Si ce mécanisme est suffisamment précis pour les mesures de débit, il ne l’est plus
lorsque l’on veut construire un chronogramme permettant de comparer précisément les dates de
réceptions des paquets sur plusieurs mobiles (les débits sont en général exprimés en octets par
seconde, des décalages de l’ordre du dixième de seconde ne sont pas vraiment gênants dans ce
contexte).
104
CHAPITRE 9. LES OUTILS D’ANALYSE AVANCÉE
Fig. 9.1 – Position des por-

tables pour la mesure de la
désynchronisation
Fig. 9.2 – Dérive des horloges en secondes (ordonnée)

pour environ 14h30 (abscisse)
En effet, les horloges des portables n’avancent pas exactement à la même vitesse. Nous avons
pu le vérifier en utilisant trois machines placées dans la configuration présentée sur la figure 9.1.
On commence l’expérience par l’envoi d’un message de synchronisation de forwarding, qui assure
qu’à sa réception les dates sur chacune des machines sont identiques. Puis l’émetteur se met à
diffuser des paquets de 1000 octets de données à une cadence régulière. A la réception de ces
paquets (numérotés), chaque récepteur l’estampille avec sa date locale. Nous soustrayons ensuite,
pour chaque paquet, sa date de réception sur l’un des mobiles à sa date de réception sur l’autre.
Idéalement, la différence devrait être nulle à chaque fois. Les paquets sont envoyés au rythme de
10 par seconde et la mesure a duré environ 14h30 (soit un peu plus de 520000 paquets). Comme
on peut le voir sur la figure 9.2, la différence est loin d’être nulle puisqu’au bout de 14h30, les deux
récepteurs sont désynchronisés de 6.5 secondes.
On remarque immédiatement l’apparente linéarité de cette courbe, mais également la présence
de décalages ponctuels plus et plus ou moins fréquents. Ces décalages apparaissent quand, sur l’un
des récepteurs, le processeur est occupé et le paquet est stocké quelques instants dans une mémoire
tampon avant d’être traité et estampillé. Comme le paquet est estampillé ”en retard”, il semble
être reçu à une date très différente vis-à-vis de l’autre récepteur. De tels écarts sont gênants pour
les calculs, mais heureusement forts rares (quelques dizaines pour plus de 500000 paquets envoyés)
et peuvent donc être éliminés avec un système de seuil. Si l’écart entre deux paquets consécutifs
est trop grand, on élimine le paquet ; on obtient ainsi la figure 9.3.
6.5 secondes de décalage en 14h30, cela correspond à environ 7.5 ms de décalage par minute.
La durée de transmission d’un paquet de 1000 octets à 2 Mbit/s est d’un peu plus de 4 ms ; on se
rend bien compte que cette dérive est trop importante pour être ignorée lors de la création de nos
chronogrammes et qu’il va falloir la corriger. La figure 9.4 montre le chronogramme représentant
les réceptions des paquets diffusés tous les 1/10 de seconde lorsqu’aucune correction de la dérive
105
Fig. 9.3 – Dérive filtrée des horloges en secondes (ordonnée) pour environ 14h30 (abscisse)
Fig. 9.4 – Chronogramme de deux mobiles recevant des paquets diffusés lorsque la dérive des
horloges n’est pas corrigée
106
Fig. 9.5 – Les strates et la redondance dans le système NTP
n’est appliquée ; le problème y est flagrant, les paquets devraient être reçus exactement en même
temps.
9.3 Résolution du problème de la synchronisation

9.3.1 Les différentes approches, les systèmes existants
La synchronisation des horloges est un problème important que l’on retrouve dans de nombreux
domaine, non seulement les réseaux, mais aussi les systèmes distribués ou les systèmes temps réels.
La synchronisation permet aux composants de maintenir leurs dates système suffisamment proches.
Sa précision dépend des algorithmes utilisés, mais aussi de la topologie ou de la structure du réseau,
des liens de communication, de la charge des machines, etc. Il existe de nombreuses méthodes qui
sont proposées à chaque fois pour des domaines d’application bien spécifiques.
NTP (Network Time Protocol) [70] C’est un protocole très connu dans la synchronisation des
horloges de machines reliées à l’Internet. NTP permet de synchroniser l’horloge d’un ordinateur avec
celle d’un serveur de référence. Le protocole est organisé de façon arborescente. La synchronisation
se fait donc couche par couche, ou strate (voir figure 9.5). On distingue 16 niveaux de couches, le
16ème niveau correspondant à une horloge non synchronisée. Dans la pratique on ne dépasse guère
la couche 5.
Les serveurs de niveau 1 se synchronisent sur une source de référence (horloge, récepteur de
temps codé, récepteur GPS). Ces récepteurs dé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 déclaré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 inférieure. Ils n’ont pas à être déclarés ;
tout site peut installer un serveur de strate 3, à la condition de prévenir les administrateurs des sites
de strate inférieure officiels. Les serveurs de strate 4 sont en général, à l’usage d’un réseau local.
Et ainsi de suite pour les couches suivantes, jusqu’aux clients terminaux. Notons que les simples
clients ne sont pas autorisés avant la strate 3.
Comme il l’est mentionné dans [71], dans les réseaux sans fil de capteurs l’utilisation de NTP
s’avère difficile. Il faut un serveur de référence que toutes les machines puissent atteindre. Un réseau
ad hoc peut être partitionné pendant des périodes plus ou moins longues, ce qui pose problème. De
même, la précision que l’on peut espérer de NTP dans le cadre d’un réseau 802.11 est en-dessous
de nos besoin, du fait de l’incertitude sur la durée de transmission d’un paquet (backoff aléatoire,
107
collisions, pertes de paquets, ré-émissions par la couche MAC). Une solution à notre problème
aurait été d’installer un ré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 précision de l’ordre de la
milliseconde qui aurait été acceptable pour notre usage ; mais ce n’était techniquement pas possible
pour les expériences en extérieur et sur des distances un peu grandes.
Des méthodes généralistes Certains travaux (comme par exemple [72]) ont essayé de faire une
synthèse sur les recherches dans le domaine de la synchronisation des horloges. Les auteurs ont
classifié les algorithmes de synchronisation en faisant une évaluation sur leur type (déterministe,
statistique, probabiliste), de leur capacité à résister aux pannes (panne de processeur, d’horloge,
de lien ou de transmission, ...), de la procédure de synchronisation (qui peut être symétrique -tous
les ordinateurs jouant le même rôle - ou asymétrique - avec des serveurs par exemple). Les auteurs
divisent la synchronisation en trois étapes :
– Déterminer quand il faut synchroniser.
– Estimer les valeurs des horloges distantes.
– Corriger l’horloge locale après avoir estimé les horloges distantes.
Ces trois étapes sont assurées par trois blocs différents et les algorithmes sont également
classifiés en fonction des techniques utilisées dans chacun de ces blocs.
Néanmoins, ces travaux ne restent qu’au niveau de la présentation et de la classification des

algorithmes et ne spécifient pas leur domaines d’utilisation. Les performances de ces algorithmes
(précision de la synchronisation et nombre de messages à envoyer) dépendent de facteurs comme
la dé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 forcément compatibles avec notre contexte d’utili-
sation (par exemple elles peuvent nécessiter une connectivité complète du réseau, la présence d’un
système de distribution de temps (GPS), ...). Par conséquent, l’adaptation de ces techniques dans
notre contexte bien spécifique aurait été pour le moins hasardeuse et les résultats non garantis.
Synchronisation dans les réseaux de capteurs Le domaine des réseaux de capteurs [73]
a toujours connu des problèmes de synchronisation. Les applications déployées sur ces réseaux
impliquent souvent la fusion de données qui nécessite une synchronisation. Le protocole RBS (Re-
ference Broadcast Synchronization), décrit dans [71], peut atteindre une précision de 1 µs dans une
zone à un saut (tout les capteurs peuvent communiquer avec tous les autres). Son extension aux
réseaux multi-sauts se fait au prix d’une dégradation de la précision qui reste néanmoins de l’ordre
de la micro-seconde. Dans le contexte multi-sauts, RBS né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 réalisées dans les
scénarios.
Une synchronisation post facto est proposée dans [74] : une synchronisation est réalisée juste
après une communication. Le but est d’éviter une consommation d’énergie inutile pour une syn-
chronisation permanente mais non nécessaire. Néanmoins, cette synchronisation peut aussi avoir
un impact sur les mesures que nous voulons réaliser puisque chaque communication serait séparée
par une synchronisation.
108
Une méthode spécifique L’auteur de [75] a présenté une solution pour la synchronisation des
horloges dans le domaine des réseaux ad hoc. Cette solution suppose que la dérivée de la date
locale d’une horloge C(t) en fonction du temps absolu est bornée :
1 − ρ ≤ ∆C/∆t ≤ 1 + ρ
Ces inégalités conduisent à une relation entre la date locale d’une machine et le temps absolu,
et vice-versa. Grâce à cette propriété et en représentant la date locale par un intervalle de temps,
les auteurs ont pu dé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) après une transmission et
en tenant compte de sa durée. Cette technique permet d’évaluer dans certains cas l’ordre des dates
locales [t1 , t2 ] < [t3 , t4 ] ou d’évaluer combien de temps s’est écoulé entre les événements [t1 , t2 ] et
[t3 , t4 ]. Cependant, il reste toujours de cas où l’on ne connaı̂t pas l’ordre des événements (quand
les intervalles se chevauchent).
La précision de cette méthode de synchronisation dépend du délai de transmission ainsi que du
nombre de sauts que la date locale à synchroniser doit traverser. Cela présente une limite lorsque
l’on veut obtenir une précision de l’ordre du dixième de milliseconde dans un réseau multi-sauts
basé sur 802.11b, où le délai de transmission n’est pas garanti (présence de backoff aléatoires) et où
le nombre de sauts peut être important. De plus, si le réseau est chargé au moment de l’échange des
paquets de synchronisation, alors les délais de transmission pourront être très fortement affectés
(retards pouvant dépasser les dizaine de millisecondes), et la précision de la synchronisation sera
trop faible.
9.3.2 Premières constatations et méthode simple

Sur la figure 9.3, on constate que la dérive des horloges semble linaire. Nous avons effectué
d’autres mesures, et si l’ampleur de la dérive varie (en fonction de l’ancienneté des machines en
particulier elle évolue entre 0.3 et 7.5 ms par minute), nous observons toujours des courbes qua-
siment linéaires. Rappelons que nous ne sommes pas spécialement intéressés par un algorithme de
synchronisation en temps réel des horloges. Nous voulons surtout pouvoir mener une analyse post-
mortem des résultats, et donc une synchronisation a posteriori (ou encore ”recalage” de fichiers de
trace) est tout à fait acceptable. Notre première approche consiste donc à considérer que la dérive
entre deux horloges est approximable par une droite. Ainsi il est possible de choisir une horloge
comme référence absolue, et de corriger grâce à des coefficients linéaires les horloges de toutes les
autres machines pour les ramener dans le même temps. Il suffit de calculer une fois pour chaque
machine le coefficient avec lequel elle dérive par rapport à la référence, puis d’appliquer ce coefficient
à chaque résultat de mesure.
Par exemple, on peut considèrer l’horloge A d’un mobile qui dérive de façon linéaire de 7 ms
par minute par rapport à l’horloge B d’un autre mobile choisie comme réfé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 événement E fournie
par l’horloge A pourra être ramenée à la valeur
tBE = tAE × (1 − 7.10−3 /60) (9.1)

qui est la date de E dans le temps de référence.
Dans un but d’évaluation, nous avons appliqué cette méthode sur les données obtenues
précédemment afin d’ajuster les dates de réception des paquets diffusés. Le coefficient d’ajuste-
109
tA - t
t=0 tA
temps local
Fig. 9.6 – Un coefficient linéaire pour passer du temps local ou temps de référence
ment est calculé de la manière suivante : après filtrage des paquets ayant été reçus avec un temps
les séparant de leur prédécesseur s’écartant trop de la moyenne, nous prenons un point en dé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 calculé et appliqué, nous avons analysé l’erreur de synchronisation
résiduelle. L’erreur maximale é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 présentée sur la figure 9.7. Cet histo-
gramme montre que l’écart de synchronisation, bien qu’énormément réduit, reste non négligeable
(beaucoup de paquets ont une erreur dépassant les 2 ms, à mettre en rapport avec les seulement
4 ms qui dure la transmission d’un paquet). De plus, les paquets présentant les erreurs les plus
importantes sont le plus nombreux. La méthode de l’approximation par une droite est très simple,
mais ne donne pas des résultats suffisamment précis et nous avons du développer une autre méthode
utilisant une droite affine par morceaux.
9.3.3 Deuxième méthode : approximation de la dérive des horloges par une

droite affine par morceaux
En reprenant les mesures précédentes (figure 9.3), plutôt que de calculer le coefficient direc-
teur d’une unique droite cherchant à 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 même manière que précédemment (la
droite choisie est celle qui passe par le premier et le dernier point de l’intervalle). La précision de la
méthode est ainsi dépendante de la longueur que l’on choisit pour les tranches. Nous avons effectué
les calculs pour plusieurs longueurs différentes (pour un calcul donné, toutes les tranches ont la
même longueur). Les erreurs maximales et moyennes en fonction de la longueur des intervalles sont
présentées dans la table 9.1.
L’histogramme de la figure 9.8 pré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 inférieure à 0.054 ms, les
erreurs importantes étant extrê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 à 2 Mbit/s et de 1.6 ms
à 11 Mbit/s, alors il apparaı̂t que l’utilisation de synchronisation toutes les 20 minutes environ
donnera des résultats suffisamment précis pour nos besoins. Il faut noter que la grande précision
110
Fig. 9.7 – Distribution de l’erreur résiduelle avec l’approximation par une droite (nombre de paquets
en ordonné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 – Précision de l’approximation par une droite affine par morceaux
111
Fig. 9.8 – Distribution de l’erreur de synchronisation avec un intervalle de 20 minutes et sur environ
520000 paquets (nombre de paquets en ordonnée, erreur en abscisse)
de cette méthode vient de la propriété des réseaux radio que l’on exploite : plutôt que de chercher
à maintenir à jour l’heure sur chacune des machines en temps réel (comme le ferait NTP) grâce à
des échanges de paquets, nous utilisons le fait que lorsqu’un paquet est diffusé en radio, il est reçu
simultanément par toutes les machines environnantes.
D’un point de vue pratique, cette méthode de synchronisation des fichiers de trace fonctionne
de la manière suivante :
– Au début de la mesure, mise à zéro de l’horloge de toutes les machines (paquet de syn-
chronisation spécial de forwarding, qui nécessite que toutes les machines soient à portée de
communication à cet instant de celle qui envoie le paquet).
– Mesures diverses, pendant lesquelles les machines peuvent se déplacer, le réseau peut être
partitionné, etc.
– Toutes les 20 minutes environ, arrêt des mesures, regroupement de l’ensemble des machines
à portée de celle qui synchronise et diffusion par celle-ci d’un paquet qui sera reçu par toutes
les autres et qui délimitera ainsi un intervalle.
– Fin de la mesure, centralisation des fichiers de trace et ”recalage”.
La figure 9.9 présente le chronogramme obtenu lorsque l’on corrige la dérive des horloges avec
cette méthode. La synchronisation est bien meilleure, les données sont tout à fait utilisables.
Cette méthode a aussi été testée dans le scénario présenté sur la figure 9.10, où deux émetteurs
cherchent chacun à envoyer autant que possible de paquets de 1000 octets et saturent le canal. Le
chronogramme obtenu est présenté sur la figure 9.11
S’il reste du trafic de mesure dans le réseau lorsque les paquets de synchronisation sont diffusés,
il y a un risque que l’envoi de ces paquets soit retardé (phénomène de defering induit par 802.11),
112
horloges est corrigée avec la deuxième méthode
Synchro
Data
Data
Fig. 9.10 – Disposition des mobiles pour l’évaluation de la synchronisation (deux sources de
données)
Fig. 9.11 – Chronogramme de deux mobiles diffusant des paquets lorsque la dérive des horloges est
corrigée avec la deuxième méthode
113
1 2 3 4 5
Fig. 9.12 – Le synchronisateur pèlerin visite régulièrement les autres mobiles et leur transmet la
bonne horloge
faussant ainsi un peu l’échelle de temps. Cependant, et c’est le plus important, même dans ce
cas l’ordonnancement de l’ensemble des paquets ne sera pas vraiment affecté ; pas plus que par la
dérive de l’horloge de la machine synchronisatrice. Le seul risque est plutôt que des paquets de
donné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 régulièrement tous les portables à portée de communication du synchronisateur n’est

pas toujours aisé, en particulier lorsque l’on travaille sur des scénarios qui demandent un placement
précis de machines. Les déplacer pour les remettre ensuite en place peut poser problème, une erreur
de replacement de quelques centimètres ayant parfois un impact tout à fait non négligeable. De
plus cette phase de déplacement de toutes les machines peut demander un temps et une ”main
d’œuvre” considérables s’il y a beaucoup de machines. Hors c’est autant de temps pendant lequel
les batteries s’épuisent inutilement. Nous avons donc raffiné notre méthode.
9.3.4 Troisième méthode : le pèlerin synchronisateur

Nous avons vu qu’avec la méthode de l’approximation de la dérive des horloges par des droites af-
fines par morceaux, une durée d’une vingtaine de minutes était un bon compromis entre la précision
de la méthode et le travail occasionné. Cette fois-ci cependant, le moment venu, plutôt que de
déplacer toutes les machines vers le synchronisateur c’est le synchronisateur lui-même que nous
déplaçons (exemple d’un longue chaı̂ne sur la figure 9.12). La différence majeure avec la méthode
précédente tient dans le fait que, dans certaines topologies, aucun des paquets envoyés par le syn-
chronisateur ne pourra atteindre tous les mobiles à la fois. Il ne sera plus possible de comparer les
dates locales de réception d’un même paquet pour calculer la dérive relative des horloges.
La solution choisie consiste à faire porter par les paquets de synchronisation une information
horaire. En l’occurrence, ces paquets sont émis à une fréquence fixe et précise (par exemple toutes
les 5 secondes). Grâce au numéro de séquence du paquet, il est possible de calculer directement
l’heure de réception de ce paquet dans l’horloge de référence (en multipliant le numéro de séquence
par le temps séparant l’émission de deux paquets consécutifs). Il faut noter qu’ici l’horloge de
référence est donc l’horloge de la machine qui envoie les paquets de synchronisation.
Comme précédemment, la synchronisation des résultats se fait post-mortem ; une fois les fichiers
de trace regroupés, ils sont analysés et recalés. Nous appliquons toujours la méthode de l’approxi-
mation de la dérive des horloges par une droite affine par morceaux, mais cette fois-ci les segments
sont délimités par la réception de deux paquets de synchronisation consécutifs. La date de réception
du paquet de synchronisation de numéro de séquence zéro est l’origine du temps global. Si les pa-
114
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 échelle de temps local à une échelle de temps global (méthode du
pélerin)
quets de synchronisation sont envoyés toutes les k secondes alors la date de réception (en temps
global) d’un paquet de synchronisation de numéro de séquence n est :
Tn = k × n (9.2)
Si ts1 et ts2 sont les dates locales de réception de deux paquets de synchronisation consécutifs
de numéros de séquence respectifs n1 et n2 , alors (ts2 − ts1 ) est le temps local qui s’est écoulé entre
les deux. Par définition de 9.2, le temps global écoulé entre les deux est :
k × (n2 − n1 ) (9.3)
Le rapport liné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 écoulé entre la réception d’un paquet de données et celle du paquet
de synchronisation le précédant. Pour un paquet de données reçu à une date locale t comprise entre
ts1 et ts2 , le temps global T de réception de ce paquet est calculé de la manière suivante :
T = R × (t − ts1 ) + k × n1 (9.5)
Grâce à ces formules, nous pouvons projeter les dates de réception locales de tous les paquets
sur une échelle de temps global constituée par la réception des paquets de synchronisation. La
figure 9.13 donne un exemple de cette relation. Les temps locaux (estampillés à la réception des
paquets) sont indiqués dans la partie basse du schéma, les formules pour les convertir en temps sur
l’échelle globale sont indiqués dans la partie haute. Les paquets de synchronisation sont schématisés
par des traits verticaux épais, les paquets de données par des traits verticaux fins.
Il faut noter que cette méthode peut être améliorée afin de fournir des chronogrammes toujours
plus précis. En effet, telle que nous l’avons décrite, nous utilisons la propriété qu’un paquet radio
est reçu exactement au même moment par les mobiles à portée de communication, mais nous ne
nous servons que des paquets dits ”de synchronisation” qui sont envoyés assez peu souvent.
Au cours de la mesure, un grand nombre de paquets de données sont en général envoyés.
Si certains de ces paquets sont envoyés en mode diffusion, au moment de l’analyse des traces,
nous les retrouverons sûrement à plusieurs endroits. Là encore, on peut utiliser la propriété de
115
Synchro Data
Fig. 9.14 – Disposition des mobiles pour l’évaluation de la synchronisation (une source de données)
horloges est corrigée avec la troisième méthode
simultanéité pour améliorer la synchronisation entre les différents mobiles qui ont reçu un même
paquet. En quelque sorte, ces paquets nous donnent des jalons intermédiaires entre les paquets de
synchronisation qui nous donnent eux-mêmes le temps absolu. Dans les sous-segments délimités par
tous ces paquets, nous appliquons toujours le mécanisme d’approximation par des droites affines
par morceaux.
Au final, cette méthode permet d’obtenir une très grande synchronisation des traces, compatible
avec nos besoins.
De part la nature de la méthode, pour la valider il a fallu utiliser la topologie présentée sur
la figure 9.14 (elle consiste à rependre celle présentée sur la figure 9.1 et à ajouter le mobile
synchronisateur). Il y a toujours deux mobiles récepteurs, mais en plus du mobile synchronisateur,
un autre mobile a été ajouté qui diffuse des données à la vitesse de 10 paquets de 1000 octets par
seconde. Ce sont la réception de ces données sur les deux mobiles récepteurs qui est présentée sur
le chronogramme 9.15. On voit que cette fois-ci, la synchronisation est vraiment très bonne, notre
objectif est atteint.
Dans le cadre du scénario de la figure 9.10, les résultats sont également très bons, comme on
peut le voir sur le chronogramme 9.16
Fig. 9.16 – Chronogramme de deux mobiles diffusant des paquets lorsque la dérive des horloges est
corrigée avec la troisième méthode
116
CHAPITRE
Les scénarios ”avancés”
0
10
Après avoir réalisé un certain nombre de mesures préparatoires et développé des outils de
synchronisation adéquats, nous avons pu passer à des mesures dans des scénarios plus complexes.
A des fins évidentes de comparaison, nous avons cherché à reproduire dans la réalité les scénarios
que nous avions utilisé lors de la phase de simulation. Les problèmes d’accès au canal seraient-ils
aussi sévères que les simulations et les calculs le laissent supposer ? Dans ce chapitre, nous allons
présenter les résultats obtenus pour des configurations à deux et trois paires ainsi que pour une
chaı̂ne comportant de 1 à 4 sauts.
10.1 Les deux paires

Jusqu’à présent, nous nous sommes intéressés à la portée effective des cartes 802.11. Dans
cette expérience, nous cherchons à mesurer jusqu’à quelle distance des mobiles peuvent détecter
réciproquement leurs porteuses et à partir de quand la réutilisation spatiale devient possible. Pour
ce faire, nous utilisons quatre mobiles répartis en 2 paires. Ces quatre mobiles sont initialement
très proches et au fur et à mesure de l’expérience nous allons éloigner les deux paires l’une de
l’autre comme indiqué sur la figure 10.1. L’orientation des cartes est également celle indiquée sur
la figure 10.1, c’est à dire sur les côtés par rapport au sens de déplacement, et non face-à-face ou
dos-à-dos. Dans la pratique nous éloignons les paires par étapes successives. Chaque é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 à chaque fois suivies de 25 secondes d’inactivité pendant lesquelles nous déplaçons les mobiles,
puis un nouveau cycle commence. La figure 10.2 décrit les combinaisons de flux pendant les phases
de transmission (nous rappelons que la diffusion se fait toujours à 2 Mbit/s, et qu’ici l’envoi en
unicast est configuré pour se faire à 11 Mbit/s) :
– 0 à 15 : Un flux à 11 Mbit/s dans la paire de droite et un flux à 2 Mbit/s dans celle de
gauche.
– 15 à 20 : Uniquement le flux à 2 Mbit/s dans la paire de gauche.
– 20 à 35 : Un flux à 2 Mbit/s dans chacune des paires.
– 35 à 40 : Un flux à 2 Mbit/s uniquement dans la paire de droite.
– 40 à 55 : Un flux à 11 Mbit/s dans la paire de gauche et un flux à 2 Mbit/s dans celle de
droite.
– 55 à 60 : Un flux à 11 Mbit/s uniquement dans la paire de gauche.
– 60 à 75 : Un flux à 11 Mbit/s dans chacune des paires.
La figure 10.3 présente les débits mesurés par le mobile 2 en fonction du temps. Comme chaque
phase de transmission se fait à une position donnée, puis que les mobiles sont déplacés durant les
117
CHAPITRE 10. LES SCÉNARIOS ”AVANCÉS”
25 secondes qui suivent, la lé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
commençant par les plus simples :
– A 190 mètres : Les deux paires sont totalement indépendantes, aussi bien à 11 qu’à 2 Mbit/s.
Quelle que soit l’activité dans l’autre paire, le débit utile des flux unicast dépasse donc les
5 Mbit/s, ce qui est le maximum possible pour la taille de paquet utilisée. Il en est de même
avec le flux broadcast qui plafonne quant à lui aussi à son maximum, c’est à dire 1.6 Mbit/s
environ. Du fait de la distance, les paquets émis en mode diffusion par le mobile 3 ne sont
évidemment pas reçus du tout par le mobile 2.
– A courte distance (jusqu’à 58 mètres) : Les émetteurs doivent partager le canal. Plusieurs
situations se détachent :
– Deux flux broadcast simultanés (secondes 20 à 35 des cycles concernés) : ils obtiennent
chacun un peu plus de la moitié de ce qu’un aurait obtenu seul, soit environ 0.8 Mbit/s.
La raison pour laquelle il n’obtiennent pas juste la moitié est celle qui avait été donnée
lors de l’étude précédente de 1 à 7 flux simultanés : les backoff sont décrémentés en partie
simultanément et cela se traduit par un temps en moyenne inférieur entre deux paquets
consécutifs sur le canal.
– Deux flux unicast simultanés (secondes 60 à 75 des cycles concernés) : ils obtiennent
également chacun un peu plus de la moitié de ce qu’un aurait obtenu seul, soit pas loin de
3 Mbit/s.
– Un flux unicast et un flux broadcast simultanés (secondes 0-15 et 40-55) des cycles
concernés : ils se partagent le canal avec une probabilité d’accès égale. Cela se traduit
par un débit intermédiaire d’environ 1.3 Mbit/s pour chacun des flux. En effet, le flux à
2 Mbit/s envoie autant de paquets que celui à 11 Mbit/s. Ce dernier va donc se trouver
pénalisé par ce partage. Les deux flux vont obtenir le même débit alors que l’un d’eux est
sensé avoir un débit plus élevé. Ce phénomène a été relevé par [42].
– Entre 94 et 160 mètres : C’est dans cette région que les interférences se manifestent. On
remarque tout d’abord que l’on est désormais trop loin pour que le mobile 2 reçoive encore
correctement les paquets envoyés en mode diffusion par le mobile 3. A 94 mètres et un tout
petit peu à 120 mètres on reçoit néanmoins encore quelques uns de ces paquets, mais plus
aucun à 160 mètres. Puisque c’est à cette distance que les phénomènes sont les plus visibles,
nous nous attardons sur chacune des combinaisons de flux à une distance de 160 mètres :
– Lorsque le flux unicast local doit cohabiter avec le flux broadcast distant (secondes 0-15 du
cycle), on remarque que le canal est partagé. Le flux unicast n’obient en effet qu’environ
1.5 Mbit/s. Comme nous l’avons déjà dit, le flux broadcast n’est pas compris à cette distance
(et n’apparaı̂t pas sur la courbe, mais il est bel et bien détecté.)
– Lorsque le flux unicast local doit cohabiter avec le flux unicast distant (secondes 60 à 75
du cycle), il n’y a visiblement plus de partage du canal nécessaire, puisque le flux local est
au débit maximum.
– Le flux broadcast (secondes 20 à 55 du cycle) est lui aussi affecté par le flux broadcast
distant, mais dans une moindre mesure : on voit une instabilité assez nette tant que le
mobile distant émet à 2 Mbit/s, mais cette instabilité disparaı̂t lorsque le mobile distant
passe à 11 Mbit/s.
Dans [41], les auteurs présentent le problème de la zone grise. Ce problème apparaı̂t lorsque
les protocoles de routage utilisent des paquets diffusés à 2 Mbit/s pour construire les routes, et
118

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 sché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 reçus par les 2 nœud récepteurs dans le scénario des deux paires mobiles
que les données sont ensuite envoyées à une vitesse supérieure (par exemple 11 Mbit/s). Comme
la portée diminue avec l’augmentation de la vitesse, il se peut que certaines routes soient valides à
2 Mbit/s mais ne soient pas utilisables à 11 Mbit/s. C’est la différence entre les zones de couverture
à différentes vitesses qui est appelée zone grise. Dans cette expérience des deux paires mobiles, nous
n’avons pas mesuré directement la zone grise. Nous avions bien un flux à 2 Mbit/s et une autre à
11 Mbit/s, mais ce dernier était en unicast et restait local dans chaque paire mobile, il ne pouvait
donc pas être compris par l’autre paire. Par contre, et en particulier à 160 mètres, l’extension du
problème de la zone grise à la zone de détection de porteuse est très visible. La portée de détection
de porteuse d’un flux à basse vitesse est nettement plus grande que celle d’un flux plus rapide
(11 Mbit/s). De ce fait, à 160 mètres, durant les secondes 0 à 35 du cycle, on voit très bien que les
flux locaux (aussi bien à 11 Mbit/s qu’à 2 Mbit/s) n’obtiennent pas toute la bande passante : il y
a détection de la porteuse du flux à 2 Mbit/s dans l’autre paire et il y a donc partage du canal.
La portée de détection de porteuse du flux distant à 11 Mbit/s (secondes 40 à 75 du cycle) est elle
inférieure à 160 mètres. Les flux locaux à 2 et 11 Mbit/s ne détectent pas du tout son activité et
occupent la totalité de la bande passante.
119
10.2 Les trois paires

La configuration des trois paires que nous avons étudiée par simulation avait montré de graves
problèmes dans l’équité de l’accès au médium pour la paire centrale lorsqu’elle percevait en quasi
permanence le canal occupé par l’une ou l’autre des paires extérieures. A des fins de vérification,
nous avons donc cherché à reproduire cette configuration pour des mesures réelles. Pour des raisons
pratiques, nous avons travaillé en intérieur. En utilisant la topologie du bâtiment, il nous était en
effet plus facile de faire en sorte que les deux paires extérieures ne se gênent pas du tout entre
elles. Nous avons travaillé à 2 Mbit/s et sans RTS/CTS. Dans la configuration présentée sur la
figure 10.4, les paires extérieures pouvaient détecter la porteuse de la paire centrale (nous l’avons
vérifié en constatant un partage équitable du canal si l’on activait la paire centrale et seulement l’une
des paires extérieures à la fois), et les deux paires extérieures ne se gênaient pas (elles obtenaient
toutes les deux le débit maximum si elles étaient activées en même temps). Une fois toutes les
machines dans la position voulue, nous avons activé un flux dans chacune d’entre elles (comme à
l’accoutumée, afin de saturer le réseau, nous avons utilisé des flux de paquets UDP de 1000 octets
pour lesquels la file d’attente est toujours pleine).
Les débits mesurés sur chacune des paires sont présentés sur la figure 10.5. Il faut noter qu’à
partir de la seconde 925 environ, les émetteurs des paires centrale et gauche sont stoppés. On
observe très clairement les difficultés rencontrées par la paire centrale : son débit évolue entre 5 et
15% du débit des paires extérieures. On remarque également la présence d’une période (entre les
secondes 805 et 870 environ) où le débit sur la paire centrale est vraiment très faible (moins de 10
paquets par seconde, soit moins de 5% de la bande passante). Cette période correspond au moment
où le débit des paires extérieures est quasiment maximal. Le reste du temps, la paire de droite
semble partager la bande passante (d’une manière certes non-équitable) avec la paire centrale.
Après une étude détaillée et de nombreuses répétitions de l’expérience, nous avons déterminé que
ce partage venait en fait d’interférences au niveau de la paire de droite par une station de base
située à un autre étage du bâtiment (et sur laquelle nous n’avions pas de contrôle).
Cette expérience confirme donc de manière très nette les simulations. Dans certaines situations
où des mobiles sont gênés de façon asymétrique, certains mobiles utilisant 802.11 peuvent connaı̂tre
de grande difficultés pour accéder au canal. Comme nous l’avons déjà expliqué, ce problème ne
peut être réglé simplement, car ils est causé par la conjonction de l’activité de plusieurs mobiles
qui en empêchent ainsi d’autres d’accéder correctement au médium. Les mobiles qui émettent n’ont
d’ailleurs pas de moyen de savoir qu’ils gênent quelqu’un d’autre.
10.3 La chaı̂ne
10.3.1 Le scénario, les contraintes
La configuration que nous voulons tester est celle présentée sur la figure 10.6. L’environnement
de mesure est le boulevard précédemment décrit (chapitre 7). Nous utilisons cinq portables pour
réaliser la chaı̂ne, ainsi qu’un sixième qui joue le rôle de synchroniseur selon la méthode présentée
dans le chapitre précédent. Nous utilisons bien évidemment forwarding pour forcer la topologie
logique (le mobile 2 ré-émet tous les paquets qu’il reçoit de 1, le mobile 3 ré-émet tous ceux qu’il
reçoit de 2 et ainsi de suite). Afin de récolter un maximum de données, les transmissions se font en
mode diffusion, et donc à 2 Mbit/s. La diffusion permet de savoir, pour chaque paquet émis, à quels
120
Fig. 10.4 – Les disposition des mobiles pour l’expérience des trois paires
Fig. 10.5 – Les difficultés pour la paire centrale à accéder au canal
121
1 2 3 4 5
Fig. 10.6 – La chaı̂ne à 4 sauts et le synchronisateur
endroits il peut être reçu (en fonction des réceptions d’un même paquet, on reconstruit directement
la zone de communication du mobile qui a émit ce paquet).
Le premier problème rencontré réside dans la portée des émetteurs lorsqu’on les utilise à
2 Mbit/s. Dans le chapitre sur la portée, nous avons vu que le signal pouvait alors être reçu à
plus de 500 mètres. Mais le boulevard où nous effectuons les expérimentations ne mesure qu’un
kilomètre environ et nous n’avons pas à disposition un environnement homogène permettant di-
rectement l’expérience de la chaı̂ne (il nous faudrait une ligne droite d’au minimum deux ou trois
kilomètres). Nous avons avons donc décidé de réduire artificiellement la portée de nos é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’émission). Aussi empirique
et simpliste qu’elle puisse paraı̂tre, cette méthode est très efficace et permet de diviser la portée des
cartes par un facteur 5 à 10 suivant la quantité d’aluminium utilisé. Cette façon de procéder a un
intérêt majeur à nos yeux : elle nous permet d’effectuer la mesure de la chaı̂ne tout en la gardant à
une échelle significative du point de vue de l’environnement et des interférences. Il nous aurait été
possible d’utiliser des antennes externes modifiées pour avoir un gain très faible (techniquement,
en donnant une portée de l’ordre du mètre à nos carte il aurait été ainsi possible de réaliser l’en-
semble des mesures multi-sauts dans une seule pièce), mais un tel changement d’échelle du réseau
modifie profondément les effets de l’environnement sur l’expérience. Dans un réseau multi-sauts
à une échelle de quelques centaines de mètres, les conditions d’interférences de l’environnement
peuvent être très différentes d’un endroit à l’autre du réseau (passage d’une voiture, proximité d’un
équipement perturbateur, bâtiment qui réfléchit les ondes de certains émetteurs, portes fermées
ou ouvertes en intérieur, présence ou simplement passage de piétons, etc.). Un réseau miniature
(tenant dans une pièce) ne serait pas soumis aux mêmes phénomènes (la plupart des éléments
perturbateurs décrits précédemment affecteraient l’ensemble du réseau de manière uniforme).
10.3.2 Le déploiement et le déroulement de l’expérience

Afin de mieux rentabiliser notre temps (et la durée des batteries), l’expérience est conçue de
manière à mesurer en une seule fois les comportements sur des chaı̂nes à 1, 2, 3 et 4 sauts. Dans
un réseau ad hoc, une configuration de chaı̂ne apparaı̂t lorsque l’émetteur d’un paquet est trop
loin du destinataire et que des mobiles intermédiaires doivent relayer les données de proche en
proche. Les mobiles intermédiaires sont choisis par le protocole de routage et en général ils vont
l’être de manière à 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 à deux sauts. Forwarding nous
permet, en forçant le choix des routes, d’éviter toute instabilité dans leur choix qui pourrait être
liée au protocole de routage. Mais en contrepartie il faut nous assurer nous-même du placement des
mobiles. La chaı̂ne de notre expérience est donc construite progressivement. Le mobile 1 est placé
122
à une extrémité du boulevard et configuré pour émettre un flux à 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’éloigne jusqu’à ce que le débit qu’il en reçoit commence à baisser. En quelques minutes on arrive,
grâce à l’affichage du débit en temps réel et par des déplacements successifs, à la placer à la limite
de la zone dans laquelle la plupart des paquets émis par le mobile 1 sont reçus. On configure alors
le mobile 2 pour émettre lui aussi (à cette étape, on ne stoppe pas encore l’émission du mobile 1).
On peut alors placer le mobile 3 en fonction des flux venant de 1 et de 2. Quelques minutes sont
également nécessaires pour trouver une position dans laquelle on reçoit bien le mobile 2, mais pas
ou très peu le mobile 1. On peut alors démarrer l’émission sur le mobile 3 et stopper celle sur le
mobile 1 (pour économiser l’énergie) ; on place alors le mobile 4 ... et ainsi de suite.
Finalement, on arrive donc à placer les 5 mobiles de la chaı̂ne dans la configuration désirée. On
stoppe alors les flux restants et on effectue un passage de synchronisation avec le sixième mobile.
10.3.3 Les résultats

Nous avons réalisé deux fois cette expérience. Il aurait été préférable de la réaliser plus de fois
encore, mais la lourdeur de ce genre d’expérimentation est telle que cela n’a pas été possible.
Première mesure
Lors de la première mesure, une fois les mobiles placés comme décrit précédemment et la phase
de synchronisation initiale effectuée, nous démarrons le flux de données sur la chaı̂ne. Au départ,
il n’y a pas de répétition des paquets (un seul saut), et au fur et à mesure on allonge la chaı̂ne en
activant la répétition sur chacun des mobiles. Les paquets UDP font 1000 octets, ils sont envoyés
en mode diffusion, à 2 Mbit/s. Les débits mesurés sont présentés sur les figures 10.7 à 10.11. La
chronologie de l’activation des ré-émissions et l’interprétation des résultats est la suivante :
– 270 à 380 : Aucune répétition, seul le flux entre 1 et 2 existe, il obtient la totalité de la bande
passante, soit environ 1.6 Mbit/s de débit utile (figures 10.7 et 10.8) et est assez stable. On
remarque sur la figure 10.9 que certains paquets émis par 1 sont reçus en 3 (secondes 300 à 340
environ) mais qu’ils ne sont pas très nombreux. Ces paquets sont très intéressants et montrent
bien un problème spécifique aux réseaux ad hoc : la propension à subir des interférences par
rafales. Ces paquets reçus en 3 à partir de 1 auraient pu conduire un protocole de routage
à établir une route directe. Mais la durée de vie de cette route aurait été courte (30 à 40
secondes), et surtout aurait subit un taux de perte particulièrement élevée (90 à 95% environ).
– 380 à 540 : Le mobile 2 répète les paquets qu’il reçoit de 1 (la chaı̂ne passe à 2 sauts). Les flux
(1→2) et (2→3) doivent donc se partager le canal. Ce partage s’effectue assez bien au début
(partie de 380 à 490), comme l’atteste la figure 10.7. Pour cette partie tout d’abord, comme
le laissait présager l’expérience précédente des 2 à 7 flux en concurrence dans la même pièce,
on y voit que le débit agrégé de deux flux est dans ces conditions égal voire un peu supérieur
à 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 débit du flux (2→3) est légèrement inférieur à celui
du flux (1→2) alors qu’idéalement ils devraient être identiques. Si l’on compare le flux venant
de 2 reçu en 2 et en 3 sur les figures 10.8 et 10.9, on constate que (2→2) est strictement égal
à (1→2) (les courbes sont superposées) et supérieur à (2→3). Ceci est tout à fait normal. En
fait, 2 reçoit lui-même les paquets qu’il diffuse quoiqu’il arrive sur le canal (les paquets sont
envoyés par forwarding à la couche IP, qui les envoie d’une part à la couche MAC, mais aussi
123
directement à forwarding puisqu’il s’agit d’une diffusion). On remarque enfin sur la figure 10.9
la présence de quelques paquets venant directement de 1 (secondes 380 à 400), alors que les
mobiles 4 et 5 n’ont jusqu’à présent perçu aucun paquet.
Les choses se gâtent cependant entre les secondes 490 et 540, où le flux (2→3) est brusquement
fortement affecté par des interférences externes : son débit devient très instable. Pour cette
partie, on voit que le débit reçu en 2 à partir de 1 ne change pas (figure 10.7 et 10.8) et que
ces paquets sont transmis à la couche MAC de 2 (flux (2→2) sur la figure 10.8). De ces deux
choses, on déduit donc que les paquets sont bien émis par 2 mais qu’ils ne sont pas reçus par 3
(s’ils n’étaient pas ré-émis par 2, le débit de (1→2) augmenterait avec la bande passante ainsi
libérée). Ceci souligne une fois de plus la tendance de certaines des interférences extérieures
à se produire par rafale.
– 540 à 700 : Le mobile 3 se met à répéter les paquets qu’il reçoit de 2 (et uniquement ceux-
là) ; la chaı̂ne passe ainsi à 3 sauts. On voit que de saut en saut, des paquets sont perdus
(figures 10.7 à 10.10), et que le débit effectif arrivant en 4 est faible (figure 10.10 : en moyenne
de 200 kbit/s alors qu’il devrait idéalement dépasser les 500 kbit/s) et extrêmement instable
(parfois quasiment nul pendant 5 à 10 secondes). On remarque, comme dans les simulations,
que le mobile qui génère les paquets (le mobile 1) occupe plus la bande passante qu’il ne le
devrait pour un accès équitable au médium. Lorsque des paquets sont perdus plus loin sur la
chaı̂ne, les mobiles qui auraient dû les ré-émettre peuvent se trouver dans une situation de
’famine’, et le mobile 1 qui lui a toujours sa file d’émission pleine en profite.
– 700 à 830 : Le mobile 4 se met à répéter les paquets qu’il reçoit de 3 ; la chaı̂ne passe à
4 sauts. Les observations sont semblables à celles de la chaı̂ne à 3 sauts : des paquets sont
perdus à chaque étape et le débit de bout en bout est à la fois faible est très instable. Entre
les secondes 780 et 800 environ, plus aucun trafic n’est même reçu en 4 (figure 10.11). On
remarque également (figure 10.8) que le flux (1→2) maintient le même dé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 à ce qu’elle devrait être idéalement.
Une fois cette expérience de la chaı̂ne à 4 sauts réalisée, comme il nous restait suffisamment de
charge sur nos batteries, nous avons décidé de reproduire la même expérience, mais en unicast. La
vitesse de transmission reste de 2 Mbit/s (la changer aurait signifié la nécessité de replacer tous les
mobiles en conséquence, et nos batteries n’auraient pas tenu aussi longtemps). Passer en unicast
présente l’intérêt d’activer le mécanisme des acquittements (et donc de la détection des collisions ou
erreurs de transmission, avec la ré-émission qui s’en suit), mais a le désavantage de nous empêcher
de détecter les paquets qui ne nous sont pas explicitement envoyés. Les débits présentés sur les
figures 10.12 à 10.16 sont donc moins riches que celles de la phase en diffusion (pour des raisons
de facilité de lecture, les figures 10.13 à 10.16 reprennent chacune une courbe de la figure 10.12 de
façon séparée).
La chronologie de l’activation des ré-émission et leur interprétation est la suivante :
– 1140 à 1205 : Il n’y a pas de ré-émission, seul le flux (1→2) existe. Il utilise toute la bande
passante et le débit effectif dépasse les 1.5 Mbit/s (figures 10.12 et 10.13). Il est évidemment
inférieur au débit lors de la phase équivalente en diffusion, puisqu’il faut maintenant prendre
en compte les acquittements. La stabilité de l’unique flux est comparable celles de la phase
en diffusion, c’est-à-dire assez grande.
– 1205 à 1415 : Le mobile 2 se met à ré-émettre les paquets qu’il reçoit de 1 ; la chaı̂ne passe
à 2 sauts. Le canal est partagé équitablement (figure 10.12) et le débit de bout en bout est
124
2e+06
de 1 recu en 2
de 2 recu en 3
de 3 recu en 4
de 4 recu en 5
debit aggrege
1.5e+06
1e+06
500000
0
300 400 500 600 700 800
temps en secondes
Fig. 10.7 – Dé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
1e+06
500000
0
300 400 500 600 700 800
temps en secondes
Fig. 10.8 – Occupation du canal perçue par le nœud 2 (mesure 1, broadcast)
125
2e+06
de 1 recu en 3
de 2 recu en 3
de 3 recu en 3
de 4 recu en 3
debit aggrege
1.5e+06
1e+06
500000
0
300 400 500 600 700 800
temps en secondes
2e+06
de 1 recu en 4
de 2 recu en 4
de 3 recu en 4
de 4 recu en 4
debit aggrege
1.5e+06
1e+06
500000
0
300 400 500 600 700 800
temps en secondes
126
2e+06
de 1 recu en 5
de 2 recu en 5
de 3 recu en 5
de 4 recu en 5
debit aggrege
1.5e+06
1e+06
500000
0
300 400 500 600 700 800
temps en secondes
optimal ou presque, sauf entre les secondes 1240-1260 et 1380-1415 environ.

Entre 1240 et 1260, le mobile 2 ne ré-émet plus les paquets. Cela se voit à l’absence de
réception par 3 dans cette période (figure 10.14) et au dé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 mitigées, le dé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 à une capture partielle ou totale du canal par le mobile 1, et ce pour une durée assez
longue (une vingtaine de secondes environ).
– 1415 à 1540 : Le mobile 3 se met à ré-émettre les paquets qu’il reçoit de 2 ; la chaı̂ne passe à
3 sauts. Le partage du canal est très é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 débit chuter de manière très importante.
Toujours sur la figure 10.12, la courbe de débit agrégé nous montre encore une fois assez bien
la tendance des interférences à se manisfester par rafales (chutes très importantes du débit
dans le réseau pour des durées de 5 à 20 secondes en général).
– 1540 à 1720 : On passe à 4 sauts. Le comportement est encore une fois très semblable à
celui de la chaı̂ne à 3 sauts mesuré juste avant. Les débits de (1→2) et (2→3) sont en général
très proches (figure 10.12), de même pour (3→4) et (4→5). La plupart des pertes se trouvent
au moment du passage de 3 à 4. Le débit de bout en bout obtenu dans la réalité sur la chaı̂ne
à quatre sauts est différent de celui obtenu par simulation (figure 10.17) D’une part il est
beaucoup plus instable. D’autre part il se situe en général autours de 250 kbit/s alors que les
simulations l’estimaient à 400 kbit/s. Dans la réalité, il n’a atteint qu’une fois la valeur de
400 kbit/s, et pour une durée assez courte (une dizaine de secondes environ).
127
2e+06
de 1 recu en 2
de 2 recu en 3
de 3 recu en 4
de 4 recu en 5
debit aggrege
1.5e+06
1e+06
500000
0
1100 1200 1300 1400 1500 1600 1700
temps en secondes
Fig. 10.12 – Débit de proche en proche sur la chaı̂ne (mesure 1, unicast)
2e+06
de 1 recu en 2
1.5e+06
1e+06
500000
0
1100 1200 1300 1400 1500 1600 1700
temps en secondes
Fig. 10.13 – Occupation du canal perçue par le nœud 2 (mesure 1, unicast)
128
2e+06
de 2 recu en 3
1.5e+06
1e+06
500000
0
1100 1200 1300 1400 1500 1600 1700
temps en secondes
2e+06
de 3 recu en 4
1.5e+06
1e+06
500000
0
1100 1200 1300 1400 1500 1600 1700
temps en secondes
129
2e+06
de 4 recu en 5
1.5e+06
1e+06
500000
0
1100 1200 1300 1400 1500 1600 1700
temps en secondes
1.8e+06
1.6e+06
1.4e+06
1.2e+06
1e+06
800000
600000
400000
200000
0
0 10 20 30 40 50 60
temps en secondes
Fig. 10.17 – Débit de bout en bout simulé dans une chaı̂ne de quatre sauts (modèle two-ray ground)
130
2e+06
de 1 recu en 2
de 2 recu en 3
de 3 recu en 4
de 4 recu en 5
debit aggrege
1.5e+06

1e+06
500000
0
1850 1900 1950 2000 2050 2100 2150 2200 2250
temps en secondes
Fig. 10.18 – Débit de proche en proche sur la chaı̂ne (mesure 2, broadcast)
Deuxième mesure
Nous avons cherché à reproduire l’expérience décrite précédemment. Le protocole expérimental
était identique (configuration et placement des machines), à l’exception de la chronologie de l’acti-
vation des ré-émissions. Cette fois-ci, la chaı̂ne commence entièrement formée (4 sauts), et au fur et
à mesure de l’expérience on stoppe des ré-émissions de façon à la raccourcir. A noter que dans cette
expérience, les batteries du mobile 1 se sont épuisées à la seconde 2240 environ et que la chaı̂ne
était alors constituée de 2 sauts (il n’y a pas de mesures à un seul saut dans cette expérience donc).
Les résultats sont présentés sur les figures 10.18 à 10.22 et la chronologie des désactivation des
retransmissions est la suivante :
– 1810 à 2050 : Les mobiles 2 à 4 ré-émettent les paquets qu’ils reçoivent de leur prédécesseur
direct, la chaı̂ne est composée de 4 sauts. Sur la figure 10.18, on voit que les débits des flux
(1→2) et (2→3) sont en général très proches l’un de l’autre, de même que (3→4) et (4→5),
mais que beaucoup de paquets ré-émis par 3 sont perdus à certains moments (différence très
visible entre (2→3) et (3→4) entre les secondes 1875-1895 et 2010-2050). Dans ces moments
où les mobiles 4 et 5 ne reçoivent que peu de paquets, on remarque que le débit sur (1→2)
et (2→3) n’augmente pas pour autant ... ceci est du au fait que le mobile 3 envoie accède lui
aussi au canal (mais simplement peu de ses paquets sont reçus).
– 2050 à 2190 : Le mobile 4 a cessé de ré-émettre, la chaı̂ne n’est plus constituée que de 3
sauts. La encore, on constate (figure 10.18) que beaucoup de paquets sont émis par 3 mais
pas reçus par 4. On remarque bien aussi les périodes de 10 à 20 secondes pendant lesquelles
les interférences externes causent ces pertes en série.
– 2190 à 2240 : seul le mobile 2 ré-émet, la chaı̂ne ne fait plus que 2 sauts. Le partage du canal
est très équitable. On remarque très bien néanmoins une période où l’ensemble des mobiles
encore actifs sont affectés par des interférences (’trou’ dans le débit des flux (1→2) et (2→3)
au alentours des secondes 2230-2240).
La figure 10.23 présente un chronogramme du début de cette mesure obtenu avec la méthode
exposée précédemment. Nous rappelons que dans les chonogrammes construits comme celui ci à
partir de mesures réelles, ce sont les réceptions de paquet qui sont représentées ; chaque rectangle
correspond à un paquet reçu et compris, et sa couleur indique par quel mobile il a été émit. Au
131
2e+06 2e+06
de 1 recu en 2 de 1 recu en 3
debit aggrege debit aggrege
1.5e+06 1.5e+06

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
Fig. 10.19 – Occupation du canal perçue par le Fig. 10.20 – Occupation du canal perçue par le
nœud 2 nœud 3
2e+06 2e+06
debit aggrege debit aggrege
1.5e+06 1.5e+06
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
Fig. 10.21 – Occupation du canal perçue par le Fig. 10.22 – Occupation du canal perçue par le
nœud 4 nœud 5
132
Fig. 10.23 – Chronogramme dans la chaı̂ne à 4 sauts (mesure 2, broadcast)
début du chronogramme, le mobile 2 reçoit 3 paquets consécutifs du mobile 1 (a), puis en ré-émet
un (b). Un peu plus tard, le mobile 3 ré-émet ce paquet (c). On remarque que les émissions des
mobiles 1, 2 et 3 n’ont jamais lieu en même temps : ils se partagent le canal. Mais lorsque le mobile
4 ré-émet un paquet (d), le mobile 1 peut émettre lui aussi : il y a réutilisation spatiale. On peut
voir également la perte de certains paquets : en (e), le mobile 3 émet un paquet qui n’est reçu qu’en
2, alors qu’il devrait aussi l’être en 4. En (f) enfin, on remarque la réception simultanée d’un paquet
émit par 2 en 3, et d’un paquet émit par 4 en 5. On savait depuis (d) que 3 était bien à portée de
4. Alors que ses deux voisins directs ont émit en même temps, le mobile 3 a donc été (cette fois-ci
tout du moins) en mesure de recevoir correctement un des deux messages.
Résumé et interprétation des résultats de l’expérience de la chaı̂ne

D’un manière générale, nous avons vu au travers des expériences que même dans des conditions
favorables (routage statique, flux UDP), le débit obtenu d’un bout à l’autre d’une chaı̂ne d’une
longueur pourtant raisonnable (4 sauts au plus) est assez problématique. L’analyse détaillée des
événements nous a permis de constater le rôle important des interférences liées à l’environnement.
Plutôt que de s’étaler d’une manière homogène dans le temps, elles arrivent par rafales. Cela
se traduit par des coupures plus ou moins complètes de communication pendant des périodes de
durées très variables (parfois quelques paquets consé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 données à envoyer. Plus la chaı̂ne est longue, plus les chances qu’un segment soit rompu ou
gravement ’bruité’ à un instant donné sont grandes. C’est probablement ici que se situe le principal
enseignement que l’on peut retirer de cette série d’expériences : du fait des erreurs qui se produisent
souvent par rafales longues (plusieurs dizaines de secondes), les simulations sur-estiment en géné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 réel, nous
avons soulevé le problème de l’équité de l’accès au canal radio dans certaines configurations où les
interférences se faisaient de façon asymétrique. Les mobiles les plus gênés ne pouvaient pratiquement
jamais envoyer de paquets, car ils détectaient toujours le canal occupé. Nous avons analysé le
phénomène et montré qu’il était possible de l’atténuer avec un mécanisme de pénalités appliquées
aux mobiles qui émettaient trop de paquets par secondes. Afin de confirmer nos dires, nous avons
décidé d’implémenter ce mécanisme sur nos mobiles et de le tester.
11.1 Choix de l’implémentation

Le mécanisme du malus est très simple en lui-même. Le temps est découpé en cycles courts (une
seconde) et pour chaque paquet envoyé, une pénalité au backoff doit être ajoutée en fonction du
nombre de paquets que le mobile a déjà envoyé au cours du cycle. La pénalité est bien sûr remise
à zéro au début de chaque nouveau cycle.
La principale difficulté dans l’implémentation de cette méthode est que contrairement à ce que
nous avons pu faire sous simulateur, il ne nous est en fait pas possible de modifier le mécanisme de
backoff. Toute la couche MAC est codée dans une mémoire directement soudée sur la carte réseau
radio, et nous n’avons pas été en mesure d’en obtenir les codes sources.
Il nous a fallu trouver une solution de remplacement donnant des résultats comparables, au
moins dans le contexte de l’expé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 réseau. L’idée était de détourner les paquets juste avant qu’ils
ne soient envoyés à la carte réseau, de les faire attendre à notre convenance dans une file d’attente,
puis de les remettre dans le flux normal pour qu’ils soient émis dans les airs.
De cette manière, même sans contrôler directement le backoff, il est possible de réduire progres-
sivement le débit des mobiles qui cherchent à émettre trop vite.
Concrètement, l’implémentation de cet algorithme s’est faite avec un filtre de paquets. Un filtre
de paquets est un programme qui analyse les en-têtes des paquets au fur et à mesure qu’ils passent
et décide du devenir de l’ensemble du paquet en fonction de ce qu’il y trouve. Il peut décider de
détruire le paquet (DROP) et il disparaı̂t alors comme s’il n’avait jamais été reçu ; il peut aussi
l’accepter (ACCEPT) et le paquet continue son chemin ; mais il peut également en faire quelque
chose de plus compliqué. Sous linux, le filtrage se fait dans le noyau (le code peut être directement
intégré dans le noyau ou chargé sous forme de module), et il peut réaliser des fonctions diverses,
même si le principe expliqué précé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 différents points d’accroche
Le filtrage de paquet est en général utilisé pour les fonctions suivantes :

– Le contrô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 requêtes HTTP
vers les adresses de doubleclick.net).
– La sécurité : Sur une passerelle, surtout si l’on n’est pas sûr de la configuration des machines
qui sont derrière, il peut être intéressant d’interdire complè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 requêtes d’accès à leurs fichiers seront bloquées au niveau de la
passerelle.
– Le monitoring : Si jamais des trafics suspects sont détectés, il est bon que l’information soit
remontée à l’administrateur.
Nous dé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 mécanisme de filtrage de paquet des noyaux 2.4 de Linux s’appelle Iptables [76]. Un certain
nombre de listes de règles appelées ”chaı̂nes” sont implémentées par défaut (INPUT, OUTPUT et
FORWARD), comme présentées sur la figure 11.1. Quand un paquet atteint une chaı̂ne, elle est
examinée pour décider du sort du paquet. Si la chaı̂ne dit DROP, alors il est détruit, et si elle dit
ACCEPT, alors il continue son chemin dans le diagramme. Chaque chaı̂ne est une liste de règles,
et si l’en-tête d’un paquet ne correspond pas à une règle, alors la règle suivante est examinée, et
ainsi de suite. Si aucune règle ne s’est avérée convenir au paquet, alors la règle par défaut de la
chaı̂ne est appliquée (par défaut configurée à ACCEPT).
Le fonctionnement des trois chaı̂nes est le suivant :
1. Quand un paquet arrive de l’interface réseau, le noyau regarde quelle est sa destination et
décide où il est envoyé (routage).
2. Si le paquet est destiné à la machine locale, alors il passe dans la chaı̂ne INPUT, et s’il est
accepté par celle-ci, alors il sera reçu par tout processus qui l’attend.
3. Si le routage est activé et si le paquet est destiné à une autre interface réseau, alors il passe
dans la chaı̂ne FORWARD et est envoyé si cette dernière l’accepte.
4. Finalement, lorsqu’un processus local veut envoyer un paquet sur le réseau, il doit d’abord
être accepté par la chaı̂ne OUTPUT avant d’aller vers l’interface à laquelle il est destiné
(notez que l’on parle bien ici d’interface physique d’entrée / sortie).
135
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 règles dans les chaı̂nes et les chaı̂nes elles-mêmes peuvent être ajoutées ou supprimées
en ligne de commande, grâce à l’utilitaire iptable. Cet utilitaire nous permet en particulier de
spécifier l’action à effectuer (c’est-à-dire la cible, ou encore TARGET) lorsqu’une règle s’applique à
un paquet. Les cibles les plus utilisées sont DROP et ACCEPT, mais nous allons plutôt nous servir
de QUEUE, qui permet, grâce au module ip queue, d’envoyer les paquets dans une file d’attente
spéciale dans l’espace utilisateur. Là, un programme spécialement écrit (delay) pourra aller les
chercher, et les renvoyer au noyau et à l’interface physique après les avoir éventuellement retenus
quelques temps (figure 11.2). Le programme delay retarde bien évidemment les paquets en suivant
l’algorithme du malus. Notons que pour obtenir une précision suffisante, nous avons dû utiliser
l’appel système nanosleep, et que de ce fait certaines précautions doivent être prises quant aux
autres processus fonctionnant au même instant sur les ordinateurs mobiles (pour que nanosleep
donne la meilleure précision, les règles d’ordonnancement des processus doivent être quelque peu
changées).
Il faut noter également que le mécanisme du malus doit être adapté pour pouvoir donner les
ré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 à un niveau intermédiaire entre l’application (ici la source CBR) et la couche MAC,
alors le malus aura un effet moindre (voir nul) par rapport à s’il avait été appliqué directement
dans la couche MAC. Si le malus est appliqué dans netfilter, alors il peut y avoir un recouvrement
entre son temps de pause et l’envoi d’autres paquets par la couche MAC. L’objectif du système
de malus est d’augmenter le temps entre deux paquets consécutifs envoyés par un mê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 être
appliqué directement dans la couche MAC, un tel recouvrement ne serait pas possible. Pour être
appliqué en dehors de la couche MAC, il faut donc que le malus tienne compte de la durée de
transmission du paquet (comme présenté 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 à laquelle il va être
envoyé. De cette façon, il est alors possible d’imposer le temps inter-trame désiré. Notons que sur
la figure, pour des raisons de lisibilité, le backoff aléatoire de la couche MAC n’est pas représenté
mais que le résultat final est le même.
11.2 Résultats
Nous avons réalisé à nouveau l’expérience des trois paires, de la manière déjà décrite (figure 11.5).
Les résultats sont présentés sur les figures 11.6 à 11.9 (pour des raisons de lisibilité, les figures 11.7
à 11.9 reprennent chacune une courbe de la figure 11.6). La pénalité appliquée est celle que nous
136
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 être appliqué 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 pénalité ”effective” appliqué en fonction du nombre de paquets envoyés
avions déjà utilisée lors des simulations (figure 11.4), corrigée à la volée de la manière décrite dans
la section précédente afin de prendre en compte la différence dans la manière de l’appliquer.
L’expérience s’est déroulée en plusieurs étapes, qui peuvent être décrites et analysées comme
suit :
– Secondes 100 à 900 : seules les deux paires extérieures sont actives et le malus n’est
pas encore utilisé. On remarque une certaine instabilité dans les débits. Le débit maximum
théorique est de 190 paquets de 1000 octets par seconde pour un émetteur seul et si aucune
contention ou collision n’a lieu. Jusqu’à la seconde 800 environ, la paire de gauche subit des
interférences assez visibles (qui affectent même la paire de droite vers la seconde 550). Ces
interférences sont en fait dues à une station de base située à une autre étage du bâtiment.
Nous avons simplement attendu que ces interférences cessent pour réaliser les mesures qui
nous intéressaient (les interférences cessent vers la seconde 800, il était alors midi et les
utilisateurs du réseau ont quitté les bureaux).
– Secondes 900 à 1350 : la troisième paire est activée. On se retrouve dans les mêmes condi-
tions que l’expérience précédente avec les trois paires (chapitre 10. La paire centrale n’accède
que très peu au canal radio (elle n’arrive à envoyer qu’entre 5 et 15 paquets par seconde
137
Fig. 11.5 – Les disposition des mobiles pour l’expérience des trois paires
contre 180-190 pour chacune des paires extérieures). Cette étape est réalisée simplement à
des fins de confirmation du problème.
– Secondes 1350 à 1400 : la paire de droite est stoppée. L’objectif était de vérifier que
conformément aux pré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 à 1700 : on réactive la paire de doite, et on revient dans la même situation
problématique de la période 900-1350.
– Secondes 1700 à 2100 : on active le mécanisme du malus. La pair centrale voit alors ses
chances d’accès au canal augmenter de manière significative (son débit évolue désormais entre
60 et 70 paquets par seconde environ). Le débit des deux paires extérieures quand à lui est
logiquement réduit (il plafonne alors à environ 105-110 paquets par seconde). Notons que ces
résultats sont très proches de ceux prévus par la simulation.
– Secondes 2100 à 2300 : la paire centrale est stoppée, mais les paires extérieures continue
d’utiliser le malus. Leur débit continue de plafonner à environ 100 paquets par seconde. Ceci
avait également été prévu par le calcul et les simulations, c’est l’effet négatif du mécanisme du
malus dans les conditions où il est le plus visible. Les deux paires extérieures ne se gênent en
effet pas du tout, et le temps inter-trames supplémentaire imposé par la malus est ici inutile
et dommageable pour le débit. Notons bien cependant que c’est ici le pire cas, et que comme
nous l’avons vu, cet effet décroı̂t très rapidement avec l’augmentation du nombre de mobile
en contention.
Dans cette expérience, nous avons pu vérifier que le mécanisme du malus offrait bien les résultats
escomptés et que la paire centrale pouvait accéder au canal dans une proportion beaucoup plus
exploitable qu’avant. Le désavantage principal du mécanisme a également été souligné : diminu-
tion nette du débit maximum possible lorsqu’il n’y pas de contention. Nous rappelons que deux
autres désavantages existent : la tendance à transmettre par rafale ainsi qu’un retard (assez court
cependant), à l’envoi effectif des paquets.
Il est important de garder à l’esprit que dans une situation comme celle de cette expérience,
du fait de l’impossibilité d’é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 caractéristique en trois étapes) présente cependant assez peu de désavantages, pour
peu qu’il y ait plusieurs mobiles en contention.
138
200
gauche
centrale
droite
150
paquets par seconde
100
50
0
0 500 1000 1500 2000 2500
temps en secondes
Fig. 11.6 – Expé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 – Expérience des trois paires avec le malus (paire de gauche)
139
200
centrale
150
paquets par seconde
100
50
0
0 500 1000 1500 2000 2500
temps en secondes
Fig. 11.8 – Expé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 – Expérience des trois paires avec le malus (paire de droite)
140
Conclusions
Dans cette thèse, nous nous sommes intéressés au comportement de la norme IEEE 802.11
lorsqu’elle est utilisée pour réaliser des réseaux ad hoc. D’une manière générale, notre travail peut
être résumé en deux étapes principales : la mise en lumière de problèmes et l’analyse de leurs
impacts d’une part, ainsi que l’apport de solutions d’autre part.
La mise en lumière des problèmes et leurs impacts

Pour des raisons pratiques et historiques, nos travaux ont débuté par un grand nombre de
simulations. Les scénarios qui nous intéressaient étaient très caractéristiques des ré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, à même de charger ponctuellement ou durablement le réseau comme le
feraient des applications réelles telles que la navigation sur le web, le transfert de fichiers ou même
la consultation de messageries).
Néanmoins, les simulateurs disponibles présentent un certain nombre de limitations. De plus,
très peu d’expériences ont été réalisées pour mesurer les impacts réels de 802.11 dans les réseaux
ad hoc. Nous sommes donc passés à une phase de vérification de mesures réelles. A cette fin nous
avons développé un outil appelé forwarding spécialement conçu pour permettre le déploiement et
l’évaluation de configurations typiquement ad hoc. Afin de nous permettre de nous concentrer
sur le comportement de 802.11, forwarding nous affranchit des couches supérieures. Pour cela, il
autorise le routage statique et met en œuvre des flux UDP, nous permettant ainsi de contrôler de
façon très précise l’émission et le cheminement de chaque paquet. En utilisant cet outil, nous avons
tout d’abord réalisé des expériences simples, puis nous avons mis en place des expériences plus
complexes. Ces dernières ont nécessité l’étude et le développement de mécanismes nous permettant
d’obtenir des traces parfaitement synchronisées à partir de nos différentes machines. Compte tenu
de la précision dont nous avions besoin, la dérive des horloges des ordinateurs est en effet telle que
nous ne pouvions l’ignorer. Des contraintes supplémentaires liées notamment au partitionnement
possible du réseau étaient également à prendre en compte. La méthode que nous avons proposée
remplit cependant parfaitement nos attentes.
Un certain nombre de caractéristiques de 802.11 ont peu être mises en évidence dans cette thèse.
Les principales sont les suivantes :
L’impact du WEP La cryptographie WEP de nos cartes présente une anomalie lorsque les
débits utilisés sont de 11Mb/s. Cela a une impact important sur le débit lorsque la taille des
paquets dépasse un certain seuil, puisque le débit obtenu est bien inférieur au débit attendu. Cette
anomalie a été mise en évide par expérimentation.
141
Le débit global Le débit global d’un réseau complet (tous les mobiles peuvent communiquer avec
tous les autres) augmente quand le nombre de mobiles en contention augmente. Cette caractéristique
a été mise en évidence par une expérimentation qui a montré que le débit aggrégé augmentait
lorsqu’on avait jusqu’à cinq mobiles en contention, puis il se stabilisait après (jusqu’à sept mobiles
utilisés). Ce fait provient du mécanime d’attente aléatoire de DFWMAC de 802.11 : lorsqu’un
mobile n’a pas pu émettre, il ne retire pas un nouveau backoff aléatoire mais utilise le backoff
restant.
Si on considère que, d’après les travaux de [77], le nombre optimal de voisins dans un réseau
ad hoc devrait être de l’ordre de six, cela impliquerait que le débit global est optimal dans chaque
zone de diffusion (où tous les mobiles peuvent communiquer avec tous les autres). Cela est bien sûr
vrai si on regarde chaque zone de diffusion indépendamment des autres. Mais il est beaucoup plus
difficile de prédire le débit global lorsque ces zones sont dépendantes les unes des autres.
La portée de communication Une différence de taille est à noter dans les portées de com-
munication obtenues par simulation et par expérimentation. En effet, la portée réelle (obtenue en
environnement extérieur) est très inférieure aux portées considérées dans NS2. De plus, les zones de
couverture sont loin d’être circulaires comme le suppose les modèles de propagation couramment
utilisés en simulation : il existe dans la réalité une zone où les communications sont très instables
et sujettent à des interférences liées à l’environnement se produisant de façon regroupées dans le
temps (par rafales). L’observation de tels comportement dans la réalité alors qu’ils ne sont pas pris
en compte dans les simulateurs (même dans le modèle shadowing qui est le plus réaliste proposé par
NS2) indique que ces derniers ont nécessairement une vision optimiste, et que leurs résultats sont
peut-être parfois bien loin de la réalité. Ceci est particulièrement problématique dans la mesure où
la perception que les simulateurs donnent de l’environnement radio aux concepteurs de protocoles
de routage influence ces derniers de façon certaine. Enfin, les expérimentations ont montré que
l’orientation des cartes, aussi bien au niveau du récepteur que de l’émetteur, avait un impact non
négligeable sur la portée de communication.
Les interférences par rafales Ce constat provient des deux points précédents et des expériences
réelles (notamment sur la chaı̂ne) Les communications sont perturbées par des interférences prove-
nant de l’environnement qui interviennent de manière groupée dans le temps. Pendant des périodes
de temps plus ou moins longues, le débit des communications devient faible, voire nul. Puis les com-
munications repartent normalement sans raison apparente. Ceci rend les résultats réels nettement
inférieurs aux prévisions par simulation.
Le mécanisme d’EIFS apporte une instabilité dans les débits Le mécanisme d’EIFS est
déclenché quand un mobile reçoit un signal qu’il n’est pas en mesure de comprendre mais qui
l’empêche d’émettre. L’EIFS est environ six fois plus important que le DIFS utilisé lors de l’envoi
“classique” de paquets, i.e. quand aucun signal interférant ne vient troubler les communications.
Or cette différence entre les valeurs de DIFS et de EIFS entraı̂ne une instabilité dans les débits. En
effet, lorsqu’un mobile réussit à prendre la main dans l’accès au médium, il va alors la garder pour
l’envoi de plusieurs paquets consécutifs, car le mobile gêné par ces communications doit attendre
plus longtemps avant de pouvoir accéder au médium. Cette instabilité a été mise en évidence par
simulation dans les scénarios des deux paires et des trois paires.
Le partage du médium en zone de détection de porteuse Si deux mobiles sont en zone
de détection de porteuse l’un de l’autre, ils doivent partager le médium radio, même s’ils sont trop
éloignés pour communiquer. Cette caractéristique a été mise en évidence par simulation et par
expérimentation dans les scénarios des deux paires et des trois paires. Elle s’explique aussi très bien
par le fonctionnement de 802.11. Elle a un impact très important au niveau de la qualité de service
dans de tels ré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 être en
mesure d’évaluer les communications s’effectuant dans la zone de détection de porteuse.
Dans NS2, la zone de détection de porteuse est deux fois plus grande que la zone de communi-
cations. Les expérimentations ont montré que cette zone était aussi de l’ordre de deux foix la zone
de communication mais qu’elle était aussi beaucoup plus instable. L’expérience sur une chaı̂ne de
mobiles montre que parfois cette zone devenait plus grande ou plus petite.
Les débits multiples 802.11b permet l’utilisation de débits multiples : les paquets de données
sont envoyés à 11Mb/s alors que les paquets de diffusion sont envoyés à 2Mb/s. De plus, 802.11
permet la dégradation de débit d’un flux si la communication n’est pas bonne. Plusieurs travaux
([42, 41]) ont montré que l’utilisation de débits multiples avaient des effets non négligeables. D’une
part, les protocoles de routage qui se basent sur des paquets en mode diffusion vont offrir une vision
erronée du voisinage aux mobiles. D’autre part, le partage équitable que 802.11 offre aux mobiles à
portée de communication va ralentir les mobiles à plus grand débit qui auront le même débit que
les mobiles plus lents. Ces caractéristiques ont été retrouvées par expérimentation.
Les problèmes d’équité Par simulation et expérimentation, des problèmes graves d’équité dans
l’accès au canal sont apparus, certains mobiles étant dans la quasi-impossibilité d’envoyer des
messages pendant des périodes de temps prolongées. L’analyse de ces problèmes (par simulation et
expérimentation, avec l’aide d’outils de visualisation tels que les chronogrammes et par le calcul)
nous a montré qu’ils trouvaient leur source dans la norme 802.11. Cette dernière a été conçue pour
des réseaux à stations de base. Dans les configurations particulières de réseaux ad hoc que nous
avons testées, elle est clairement mise en défaut. La nature du problème tient pour une bonne part
dans l’inégalité des mobiles faces aux interférences. 802.11 donne des chances comparables d’accès
au canal à des mobiles en compétition mais à portée de communication directe ou indirecte (deux
sauts, grâce aux RTS/CTS). Mais dans les configurations que nous avons présentées ces chances
sont faussées. En effet, certains mobiles vont subir une combinaison des activités de mobiles voisins
qui agissent indépendamment les uns des autres et qui indique à ce mobile que le canal est occupé
en permanence, et l’empêche donc de façon durable d’y accéder.
Ce problème a été mis en relief dans le scénario des trois paires aussi bien par simulation que
par expérimentation. Il se retrouve aussi dans le scénario de la chaı̂ne, mais il est combiné à d’autres
problématiques (comme des débits différents sur les mobiles par exemple).
L’impact de ces problèmes sur les applications mais également sur les protocoles de routage a été
souligné. Les émissions conjuguées de certains mobiles sont à même de causer dans leur voisinage
des cassures et des redécouvertes de routes à répétitions ; l’efficacité du routage s’en ressentant
grandement. Enfin, les protocoles ont une vision erronée du réseau et pourraient peut-être prendre
des décisions différentes s’ils disposaient de la topologie réelle.
Impact des EIFS sur l’équité . Comme nous l’avons vu par la simulation dans le scénario des
trois paires, l’utilisation des EIFS peut amplifier les inégalités dans l’accès au médium. Dans ce
scénario, la paire centrale accédait jusqu’à six fois moins souvent au canal que lorsqu’elle n’attendait
que DIFS après la fin d’une transmission erronée.
Les RTS/CTS Le mécanisme des RTS/CTS souvent prôné comme la solution aux problèmes des
nœuds cachés semble avoir des effets pas toujours positifs sur des scénarios plus complexes comme
la chaı̂ne de mobiles. Par simulation, nous avons vu que les débits sur la chaı̂ne était fortement
diminué lorsque les RTS/CTS étaient utilisés et que la communication était bien meilleure sans ce
mécanisme.
Les débits réels Les expériences ont montré que les débits réels obtenus dans les réseaux ad hoc
testés sont plus faibles que ceux obtenus par simulation.
L’étude de solutions
A partir du moment où les simulations ont soulevé les problèmes d’équité dont nous venons
de parler, nous y avons cherché des solutions. La nature du problè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 émissions pose problème n’ont pas de moyen
de s’en rendre compte (parfois ces mobiles sont complètement hors de portée de communication
directe ou indirecte les uns des autres ainsi que des mobiles qu’ils empêchent d’accéder au canal).
Nous avons donc proposé une première solution basée sur des pénalités appliquées d’une manière
étudiée aux mobiles qui émettent beaucoup. Sous simulateur, cette méthode a donné des résultats
tout à fait satisfaisants, aussi bien dans les scénario des trois paires que dans celui de la chaı̂ne
perturbée. Le principal désavantage de la méthode est une chute du débit maximum possible en cas
d’absence de contention. Ce désavantage est cependant très vite limité et rendu imperceptible dès
que le nombre de mobiles en contention augmente E cette situation est finalement très probable
dans un réseau ad hoc, où beaucoup de mobiles vont devoir non seulement envoyer leurs propres
données, mais aussi celles d’autres nœuds pour lesquels ils routent des paquets.
A des fins de vérification, nous avons adapté le mécanisme de la pénalité à notre environnement
de mesure. Comme il n’était pas possible de modifier la couche MAC directement (ce qui aurait
été idéal, mais impossible du fait des codes sources fermés), nous avons utilisé un système de
remplacement. Ce dernier, basé sur le filtrage de paquets dans le noyau linux et leur retenue
temporaire dans l’espace utilisateur a nécessité quelques modifications dans notre algorithme, mais
a ensuite donné entière satisfaction. Dans le scénario des trois paires que nous avons reproduit une
nouvelle fois, la paire centrale pouvait enfin accéder au canal dans des proportions raisonnables.
Enfin, nous avons aussi amélioré une solution aux problèmes d’équité proposée par Bensaou
et al. Par un mé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 équité et qui permet de diminuer la perte de débit
global en bande passante.
Bilan
L’intérêt pour les réseaux ad hoc est récent. Les recherches dans ce domaine se sont concentrées
sur certains problèmes clefs, et en particulier sur le routage. Pour des raisons pratiques, au travers
de différents outils de simulation, ces nombreuses études s’appuient dans leur grande majorité sur
la norme 802.11.
L’originalité de nos travaux tient dans l’approche pragmatique que nous avons eue des réseaux
ad hoc. La pile de protocoles, du niveau physique jusqu’aux applications, même si elle présente des
similitudes avec celles des mondes filaires et cellulaires, a besoin d’adaptations spécifiques à tous
les niveaux. La couche MAC de 802.11, de part son fonctionnement totalement distribué, sert de
fondation pour la majorité des travaux du domaine ad hoc se voulant capables de fonctionner sur
les technologies radio grand public de ce début de millénaire. C’est donc d’une manière naturelle
que notre intérêt s’est porté sur elle et ses interactions avec les couches supérieures dans le contexte
ad hoc.
De part les problèmes que nous avons soulevés, nous avons montré que le choix des couches
basses et de la couche MAC en particulier étaient loin d’être neutres dans les réseaux ad hoc,
et qu’il y avait des interdépendances très fortes entre tous les niveaux de la pile de protocoles.
Ainsi, l’environnement et les situations topologiques propres aux réseaux ad hoc conduisent à des
interférences physiques, qui agissent sur la couche MAC, qui elle-même a un effet sur le fonction-
nement des protocoles de routage.
Notre étude de ces phénomènes et de leur impact est novatrice dans le sens où nous avons
cherché à les isoler spécifiquement, plutôt qu’à obtenir des résultats agrégés où les interactions
entres les couches MAC, PHY, routage, TCP et application sont entremêlés et finalement peut
exploitables.
Perspectives
Un certain nombre de topologies ad hoc qui posaient problème à 802.11 ont été mises à jour
dans nos travaux, mais la recherche de ces situations n’a pas été exhaustive et il est tout à fait
possible qu’il en existe d’autres qui soulèvent des problèmes particuliers. La recherche de l’ensemble
des situations problématiques, leur étude théorique et leur reconnaissance par des expériences nous
apparaı̂t donc comme un premier axe de travail dans la continuité de cette thèse ; d’autant plus
que nous pouvons désormais compter sur les outils que nous avons développés.
Les problèmes d’équité forment à eux seuls un domaine de recherche. Certaines études théoriques
existent déjà dans la littérature, mais beaucoup de travail reste à faire, aussi bien dans la classifica-
tion des définitions diverses de l’équité, que dans la proposition de solutions. Le lien peut être fait
également avec le point précédent : les problèmes spécifiques des réseaux ad hoc (de topologie et des
interférences qui y sont liées en particulier) peuvent être pris en compte pour définir l’équité et y
proposer des solutions adaptées. Les contraintes sont cependant nombreuses, comme la distribution
de l’algorithme qui est un point capital par exemple.
Le troisième axe de recherche concerne les interactions avec les couches supérieures, et le routage
en premier lieu. Dans cette thèse nous avons montré et expliqué un certain nombre d’impacts sur
le routage que peuvent avoir les couches basses, nous pensons qu’il faudrait maintenant capitaliser
ces résultats et s’en servir pour repenser et adapter la manière de router dans un réseau ad hoc.
Dans le domaine des simulateurs, la réalisation de couches physiques présentant les comportements
observés dans nos mesures nous semble un premier pas dans cette voie. Dans la communauté ad hoc,
les simulateurs ont un impact très important sur la conception des protocoles de routage. Au delà
du routage, les interactions avec TCP mériteraient également d’être revisitées, les performances
de TCP étant passablement mauvaises, aussi bien dans les simulations actuelles de réseaux ad
hoc (pourtant étonnamment optimistes, comme nous l’avons souligné) que dans les rares mesures
ré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 (consulté le 5/12/2003).
[3] D. Dhoutaut and I. Guerin-Lassous. Impact of heavy trafic beyond communication range in multi-hops
ad-hoc networks. In Proceedings of International Network Conference 2002. University of Plymouth,
UK, 2002.
[4] D. Dhoutaut and I. Guerin-Lassous. Experiments with 802.11 in ad-hoc configurations. In 14th IEEE
International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2003), 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 réseau ad-hoc multi-sauts. In Proceedings of ALGOTEL 2002, Mèze, France, pages 147–153,
mai 2002.
[6] D. Dhoutaut and I. Guerin-Lassous. Expé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 Gué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 (consulté le 5/12/2003).
149
BIBLIOGRAPHIE
[17] Yih-Chun Hu David B. Johnson, David A. Maltz. The Dynamic Source Routing Protocol for Mobile
Ad Hoc Networks (DSR) (draft IETF), 2003.
[18] Philippe Jacquet Thomas Clausen. RFC 3626, Optimized Link State Routing Protocol (OLSR), 2003.
[19] M. Lewis R. Ogier, F. Templin. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
(draft IETF), 2003.
[20] E. Royer and C. Toh. A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks.
In IEEE Personal Communications., April 1999.
[21] C. Chiang, H. Wu, W. Liu, and M. Gerla. Routing in Clustered Multihop, Mobile Wireless Networks.
In Mobile Wireless Networks, The IEEE Singapore International Conference on Networks, 1997.
[22] Vincent D. Park and M. Scott Corson. A Highly Adaptive Distributed Routing Algorithm for Mobile
Wireless Networks. In INFOCOM (3), pages 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] Mühlethaler Paul. 802.11 et les ré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 Appliquée : protocoles, algorithmes et
codes source en C. 2e é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, Université de Paris-Sud, 2000.
[38] Y. Wang and B. Bensaou. Achieving Fairness in IEEE 802.11 DFWMAC with Variable Packet Lengths.
In IEEE Global Telecommunications Conference (GLOBECOM) 2001, pages 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 Nordströ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 Rö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

Langue

These PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

These PDF

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

N d’ordre

Étude du standard IEEE 802.11 dans le cadre

À soutenir le 11 Décembre 2003 devant la Commission d’examen

1 Les réseaux ad hoc 10

3 Particularités de 802.11 dans un contexte ad hoc 40

4 Simulations : introduction et scénarios de prise en main 47

6 Quelques solutions aux problèmes d’équité dans les réseaux ad hoc 72

II Expérimentations en environnement réel 83

7 Objectifs des mesures et moyens mis en œuvre 84

8 Les premières mesures 92

9 Les outils d’analyse avancée 104

10 Les scénarios ”avancés” 117

11 Mise en pratique du malus 134

Point de départ et sujet de thèse

Contributions et organisation du document

Notre contribution se présente ensuite sous la forme de trois parties distinctes :

1.2 Problèmes et contraintes spécifiques des réseaux radio

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

1.3.1 Routage hiérarchique ou plat

Fig. 1.2 – Routage ”à plat” Fig. 1.3 – Routage hiérarchique

1.3.2 Etat de liens ou vecteur de distance

1.3.3 Les différentes familles de protocoles de routage MANET

Les protocoles réactifs

Les protocoles proactifs

Les protocoles hybrides

1.3.4 Description de quelques protocoles de routage représentatifs

Ad-hoc On Demand Distance Vector (AODV)

Dynamic Source Routing (DSR)

rreq (1) rreq (1)

rreq (2) rreq (2)

rreq (2) rreq (2)

rreq (3) rreq (3)

Optimized Link State Routing (OLSR)

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

Fig. 1.6 – Relais multipoints

2.1 Les autres normes de réseaux locaux sans fil.

TCP/IP ATM / UMTS IEEE

Couche de convergence réseau (NC)

Fig. 2.3 – L’organisation générale d’HiperLAN type 2

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

Fig. 2.4 – Un scatternet Bluetooth

2.2 Introduction à 802.11

Fig. 2.5 – Réseau 802.11 en mode infrastruc-

Fig. 2.7 – Les couches et sous-couches OSI définies par 802.11

2.3 La couche physique

Fig. 2.8 – Changer de fréquence

Tab. 2.1 – Réglementations de la bande ISM

Fig. 2.10 – Le réutilisation spatiale grâce à un plan d’allocation des fréquences

Canal 1 Canal 7 Canal 13

Fig. 2.11 – Le recouvrement des canaux dans la bande ISM

Fig. 2.12 – Les 8 premiers canaux définis par 802.11a

2.4 La couche MAC

802.11 802.11b 802.11a 802.11g

FHSS DSSS HR-DSSS OFDM OFDM

Fig. 2.13 – Récapitulatifs des technologies et des débits possibles

2.4.1 Description du mode DCF

Fig. 2.15 – Le backoff et le defering

aCWmax 255 255

Fig. 2.16 – Un exemple de backoff exponentiel

CTS (2) CTS (2)

SIFS SIFS SIFS DIFS