Etude du standard IEEE 802.11 dans le cadre des réseaux ad ...theses.insa-lyon.fr/publication/2003ISAL0094/these.pdf · utilisant en particulier la norme 802.11 de l’IEEE. Mon

N d’ordreAnnee 2003

These

Etude du standard IEEE 802.11 dans le cadredes reseaux ad hoc : de la simulation al’experimentation.

Presentee devantL’Institut National des Sciences Appliquees de Lyon

pour obtenirLe grade de docteur

ParDominique Dhoutaut

A soutenir le 11 Decembre 2003 devant la Commission d’examen

Jury MM.S. Amarger Deputy Laboratory Manager (Hitachi, Sophia-Antipolis)A. Duda Professeur (ENSIMAG, Grenoble)I. Guerin-Lassous Chargee de recherche (INRIA)P. Jacquet Directeur de recherche (INRIA, Rocquencourt)G. Pujolle Professeur (Universite Paris VI)F. Spies Professeur (Universite de Franche-Comte)S. Ubeda Professeur (INSA de Lyon)

Les reseaux ad-hoc sont auto-organises et ne reposent sur aucune infrastructure fixe. Leselements les composant sont en general relies par radio, potentiellement mobiles, et peuvent etreamenes a entrer ou sortir du reseau a tout moment. Ces reseaux sont caracterises par la capacitede chaque participant d’agir a la fois comme client et comme routeur du reseau. Si un emetteurn’est pas a portee directe de la machine destination, les informations devront etre transmises deproche en proche, le long d’un chemin etabli et maintenu par le reseau en cas de modification dela topologie (ces reseaux sont d’ailleurs qualifies de multi-sauts).

Le domaine des reseaux ad-hoc est vaste et recent. Un travail consequent est actuellementeffectue dans le groupe MANET de l’IETF dans le but de normaliser un ou des protocoles deroutage pour ces reseaux. Ces travaux, ainsi que de nombreux autres portants sur des protocolesde plus haut niveau (qualite de service, decouverte de services, ...) s’appuient sur des simulationsutilisant en particulier la norme 802.11 de l’IEEE.

Mon travail porte sur l’utilisation de cette norme comme support pour les reseaux ad-hoc,domaine pour lequel elle n’a pas ete prevue a l’origine.

– Dans un premier temps, j’ai realise de nombreuses simulations avec le simulateur de reseauxNS2. Elles m’ont en particulier permis de montrer que de graves problemes d’equite au niveaude l’acces au medium pouvaient apparaıtre. Dans de nombreuses situations typiques desreseaux ad-hoc certains mobiles peuvent voir leur acces fortement reduit ; ceci a un impactdirect sur les applications, mais aussi sur les protocoles de routages eux memes, et risque deprovoquer un effondrement du reseau.

– J’ai donc travaille a la comprehension et l’analyse de ces problemes mis en lumiere par lasimulation. En sus de problemes deja largement etudies dans la litterature (par exemple lesnœuds caches), le fait que dans un reseau ad-hoc des mobiles puissent se gener les uns lesautres sans pour autant avoir de moyen de communiquer apporte de nombreuses contraintessupplementaires. L’etude (par la theorie et la simulation) de ces contraintes et de leurs in-teractions avec certains mecanismes prevus par la norme 802.11 m’ont logiquement amene aproposer des solutions aux problemes d’equite. Certaines solutions s’affranchissent de toutecommunication entre les mobiles se genant potentiellement. D’autres solutions essaient detirer parti d’une connaissance d’une region plus etendue que le voisinage direct pour obtenirdes resultats s’approchant de l’ideal.

– Mais au fur et a mesure que ma comprehension de la norme 802.11 et des phenomenes lies a sonutilisation dans les reseaux ad-hoc s’etoffait, il m’est apparu que la realite etait plus complexe.En environnement reel, des phenomenes physiques non presents dans les simulations entrenten jeu. Afin de mieux les cerner, et afin de mieux savoir ce qu’il est possible d’attendre de lanorme 802.11 dans notre contexte, j’ai donc mene de nombreuses experimentations a l’aided’outils que j’ai developpes. Dans un premier temps, ces mesures ont porte sur des scenariossimples permettant d’extraire les caracteristiques principales de 802.11. Ces mesures ont ainsipermis de mettre en lumiere des problemes jusqu’alors presentes de facon theorique par lacommunaute (par exemple le probleme des ”zones grise”), mais egalement d’autres jusqu’alorsignores ou non pris en compte.

– Dans un deuxieme temps, j’ai mene des experimentations sur des scenarios plus complexeset typiques des reseaux ad-hoc (sauts multiples, interferences entres mobiles ne pouvant pascommuniquer entre eux,...). Ces experimentations ont d’une part confirme les problemes sou-leves par certaines simulations, et d’autre part m’ont permis d’implementer, de tester et devalider les solutions aux problemes d’equite que j’avais proposees precedemment.

Table des matieres

1 Les reseaux ad hoc 101.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Problemes et contraintes specifiques des reseaux radio . . . . . . . . . . . . . . . . . 101.3 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.1 Routage hierarchique ou plat . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.2 Etat de liens ou vecteur de distance . . . . . . . . . . . . . . . . . . . . . . . 141.3.3 Les differentes familles de protocoles de routage MANET . . . . . . . . . . . 151.3.4 Description de quelques protocoles de routage representatifs . . . . . . . . . . 16

2 Presentation de 802.11 202.1 Les autres normes de reseaux locaux sans fil. . . . . . . . . . . . . . . . . . . . . . . 20

2.1.1 HiperLAN 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.2 HiperLAN 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Introduction a 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 La couche physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4 La couche MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1 Description du mode DCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.2 Description du mode PCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5 La securite des informations : la Wired Equivalent Privacy (WEP) . . . . . . . . . . 342.6 Les trames 802.11b et le debit utile 802.11b . . . . . . . . . . . . . . . . . . . . . . . 36

3 Particularites de 802.11 dans un contexte ad hoc 403.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 Le probleme des nœuds caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3 Le probleme des nœuds exposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4 Le probleme de la zone grise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Partage du canal entre des flux a vitesses differentes . . . . . . . . . . . . . . . . . . 433.6 TCP et 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.7 Capacite theorique en fonction la topologie (grille, chaıne) . . . . . . . . . . . . . . . 443.8 Equite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.9 Conclusion et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3

I Simulations logicielles de reseaux ad-hoc 46

4 Simulations : introduction et scenarios de prise en main 474.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Objectifs initiaux des simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 Presentation de Network Simulator 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1 Les differents modeles de propagation radio sous NS2 . . . . . . . . . . . . . 494.3.2 La gestion des interferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4 Traitements des resultats et outils d’analyse . . . . . . . . . . . . . . . . . . . . . . . 524.5 Prise en mains et premieres simulations . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5.1 Portee de communication et debit . . . . . . . . . . . . . . . . . . . . . . . . 564.5.2 Interferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Scenarios ”avances” 605.1 Introduction et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 Trois paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3 Sauts multiples en configuration de chaıne . . . . . . . . . . . . . . . . . . . . . . . . 635.4 La chaıne fixe et la paire de perturbateurs . . . . . . . . . . . . . . . . . . . . . . . . 675.5 Le probleme de l’asymetrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.6 Conclusion sur ces simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Quelques solutions aux problemes d’equite dans les reseaux ad hoc 726.1 Une solution historique et locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2 Une solution etendue geographiquement . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2.1 Point de depart et algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.2.2 Quelques resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

II Experimentations en environnement reel 83

7 Objectifs des mesures et moyens mis en œuvre 847.1 Introduction et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.2 Les environnements de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.2.1 Travaux anterieurs bases sur des mesures . . . . . . . . . . . . . . . . . . . . 857.2.2 Ad hoc Protocol Evaluation (APE) . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3 Description de l’outil forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.3.1 Architecture du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3.2 Format des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.3.3 Les commandes disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8 Les premieres mesures 928.1 Justifications des donnees mesurees. . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.2 Le debit en fonction de la taille des paquets . . . . . . . . . . . . . . . . . . . . . . . 92

8.2.1 La fragmentation a 1500 octets . . . . . . . . . . . . . . . . . . . . . . . . . . 938.2.2 L’impact du WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938.2.3 Hormis les problemes pre-cites, des debits tres proches de la theorie . . . . . 95

8.3 Partage du canal entre nœuds a portee de communication . . . . . . . . . . . . . . . 968.3.1 Deux flux (combinaisons d’emetteurs et recepteurs) . . . . . . . . . . . . . . . 968.3.2 Flux multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.4 Les mesures de portee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988.4.1 L’environnement et le outils de mesure . . . . . . . . . . . . . . . . . . . . . . 998.4.2 Les resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

9 Les outils d’analyse avancee 1049.1 Les chronogrammes en environnement reel . . . . . . . . . . . . . . . . . . . . . . . . 1049.2 Le probleme de la synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049.3 Resolution du probleme de la synchronisation . . . . . . . . . . . . . . . . . . . . . . 107

9.3.1 Les differentes approches, les systemes existants . . . . . . . . . . . . . . . . . 1079.3.2 Premieres constatations et methode simple . . . . . . . . . . . . . . . . . . . 1099.3.3 Deuxieme methode : approximation de la derive des horloges par une droite

affine par morceaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109.3.4 Troisieme methode : le pelerin synchronisateur . . . . . . . . . . . . . . . . . 114

10 Les scenarios ”avances” 11710.1 Les deux paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11710.2 Les trois paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12010.3 La chaıne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

10.3.1 Le scenario, les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12010.3.2 Le deploiement et le deroulement de l’experience . . . . . . . . . . . . . . . . 12210.3.3 Les resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

11 Mise en pratique du malus 13411.1 Choix de l’implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13411.2 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5

Introduction

Point de depart et sujet de these

A l’heure ou les communications telephoniques sans fil se sont imposees de facon indeniable,et ou les reseaux locaux radio connaissent un essor fulgurant, de nouvelles applications de cestechnologies apparaissent sans cesse. Ces sont les militaires qui ont ete les premiers interesses pardes technologies de communication radio fonctionnant de proche en proche et restant fonctionnellesen cas de mobilite ou de perte de certains elements routeurs. Dans [1], on apprend que des le debutdes annees 1970, les techniques de commutation de paquets ont inspire le developpement par leDARPA1 des Packet Radio Network (PRNET). Ces reseaux disposaient deja d’une architecturedistribuee, partageaient dynamiquement le canal de diffusion par une combinaison des protocolesAloha et CSMA, et se servaient de la repetition des paquets pour elargir la zone de couvertureglobale. Par la suite, en 1983, les Survivable Radio Networks (SURAN) furent developpes parle DARPA. L’objectif etait de passer outre les principales limitations des PRNet (en particulierpermettre le passage a des reseaux comportant enormement de nœuds, gerant la securite, gerantl’energie, et offrant des capacites de calcul suffisantes pour supporter des protocoles evolues). Maisles recherches sur ces reseaux restaient exclusivement militaires. Les applications civiles de cesreseaux appeles ad hoc n’apparurent que beaucoup plus tard, vers la fin des annees 1990. Parmi lesapplications actuellement les plus en vogue destinees aux reseaux ad hoc, en sus de celles a usagemilitaire, on peut citer par exemple :

– le deploiement de reseaux dans des environnements ou les infrastructures fixes ne sont plusoperationnelles (sur les lieux de catastrophes naturelles ou autres) ;

– le deploiement de reseaux de capteurs dans des environnements hostiles ou difficiles d’acces.Un tel reseau s’auto-configure en fonction des ressources energetiques restantes et de la dis-tribution geographique des nœuds (disseminations initiale par largage par exemple, qui lesplace de maniere assez aleatoire) ;

– l’extension de reseaux dotes d’infrastructures : lorsqu’un certain nombre de stations de basefixes existent mais que certains mobiles se trouvent en dehors de leur zone de couverture etcherchent a passer par des mobiles intermediaires pour les atteindre et ainsi se rattacher al’ensemble du reseau.

Ces recherches sur les reseaux ad hoc dans le domaine civil n’ont en fait veritablement prisleur essor qu’avec l’arrivee des premieres technologies radio bon marche : principalement la normeIEEE2 802.11 et ses diverses extensions. La norme 802.11 est concue avant tout pour batir desreseaux autour d’une infrastructure fixe de bornes radio reliees entre elles par un reseau cable.

1Defense Advanced Research Projects Agency2Institute of Electrical and Electronics Engineers, http ://www.ieee.org

6

Mais la methode d’acces au canal qu’elle propose par defaut fonctionne de maniere totalementdistribuee, c’est la Distributed Coordination Function (DCF). Cette derniere, alliee au cout moderedes equipements, a joue un role primordial pour l’utilisation de 802.11 dans un contexte ad hoc.Elle peut en effet etre utilisee directement et laisse les chercheurs se concentrer sur les couchessuperieures.

Ces recherches se sont cristallisees en particulier sous la forme d’un groupe de travail al’IETF3 : le groupe MANET (Mobile Ad hoc NETworks [2]). Les problematiques de ce type dereseaux sont nombreuses et substantiellement differentes de celles des mondes filaire ou memecellulaire (pas d’infrastructure fixe ni meme d’assurance d’avoir des voisins, mobilite possible detous les elements et donc absence de plan d’allocation geographique des frequences, etc.). Legroupe MANET travaille essentiellement a l’elaboration de protocoles de routage adaptes (lorsquel’on cherche a communiquer avec un mobile qui n’est pas a portee directe, il va falloir etre capablede trouver des mobiles intermediaires qui vont relayer le message). Mais les couches les plus basses(physique et d’acces au medium) aussi bien que les couches plus elevees (jusqu’aux applications)necessitent elles aussi des retouches plus ou moins importantes. Par exemple, l’absence d’elementsfixes empeche de centraliser certaines tache, et rend l’utilisation de methodes d’acces au canaltelles que TDMA (Time Division Multiple Access) ardues. De meme, puisque le reseau peut parfoisse partitionner, les applications n’ont pas toujours acces aux memes ressources, et doivent doncutiliser des caches ou prendre toutes autres mesures qu’elles jugent utiles pour fournir un servicele moins degrade possible.

De part sa diffusion et son faible cout, 802.11 sert de support a de tres nombreux travaux dansle domaine des reseaux ad hoc (que ce soit au niveau du routage, de la qualite de service ou encoredes applications). Mais cette norme n’a neanmoins pas ete concue pour ce type d’utilisation puisqueles reseaux a stations de base sont le contexte qu’elle cible reellement. Il apparaıt que certains deses comportements dans un cadre purement ad hoc ne sont finalement pas bien connus. C’est al’etude de ces comportements et leurs interactions avec les couches superieures qu’est vouee cettethese.

Contributions et organisation du document

Nos travaux se situent au niveau de l’interaction entre les protocoles specifiques des reseauxad hoc et les couches MAC (Medium Access Control) et physique sur lesquelles ils s’appuient.Le chapitre 1 introduit les reseaux ad hoc et le chapitre 2 presente la norme 802.11. Pourles reseaux ad hoc, les differentes familles de protocoles de routage sont presentees, accom-pagnees d’un certains nombre d’exemples detailles qui nous permettront par la suite de mieuxcomprendre les effets qu’auront sur chacun d’entre eux les comportement des couches bassesutilisees dans un contexte ad hoc. La norme IEEE 802.11 quant a elle n’est bien sur pascompletement detaillee, mais les parties significatives et importantes pour notre travail le sont.Il s’agit, en sus d’un apercu des techniques utilisees par la couche physique radio, de tout cequi concerne la gestion distribuee de l’acces au canal radio, ainsi que certains points precis,comme la gestion de la cryptographie ainsi que certaines particularites des extensions de 802.11(802.11b notamment, qui introduit des debits plus eleves mais qui dispose d’amenagements pourmaintenir la compatibilite dont nous devront tenir compte plus tard). Le chapitre 3 quant a lui

3l’Internet Engineering Task Force, http ://www.ietf.org

7

detaille les contraintes et particularites de l’utilisation de 802.11 dans un contexte purement ad hoc.

Notre contribution se presente ensuite sous la forme de trois parties distinctes :

Par des simulations. Dans les chapitres 4 et 5, en utilisant le simulateur Network Simulator 2,nous avons cherche a mettre en lumiere certains problemes bien specifiques lies a l’utilisation de802.11 dans un contexte ad hoc. Cette etude commence par une prise en main de l’outil de simulationet la realisation de scenarios simples mais neanmoins necessaires, puis passe a des scenarios plusspecifiques. Les conditions d’utilisation des reseaux ad hoc qui ont attire notre attention sont cellesou le reseau est regulierement traverse par des flux importants ; ces conditions nous semble eneffet hautement probables dans des reseaux utilises pour acceder au web, transferer des fichiers ouencore consulter des messageries. A travers quelques scenarios tres caracteristiques (une chaıne demobiles, une chaıne et un couple de nœuds perturbateurs, trois paires de mobiles situes a diversesdistances), nous mettons en lumiere des problemes d’equite de l’acces au canal. Il apparaıt que dansdes situations malheureusement tres communes dans des reseau ad hoc, certains mobiles peuventse trouver dans l’incapacite d’emettre, et cela du simple fait de l’activite combinee de certains deleurs voisins.

A l’aide de divers outils, dont un systeme de visualisation produisant des chronogrammesdetailles, nous analysons alors le probleme et montrons qu’il trouve sa source dans le mecanismed’acces au medium de 802.11. Il n’a en effet pas ete prevu pour fonctionner dans des situationsou, dans un ensemble de mobiles voisins, certains d’entre eux rencontrent plus de contention qued’autres. Nous montrons egalement que le mecanisme EIFS de 802.11, concu pour reduire leschances de collision, est dans cette situation dommageable et amplifie les inegalite face a l’acces aucanal. Nous expliquons alors quels sont les effets sur les protocoles de niveau superieur. Les pro-tocoles de routages patissent en particulier des interruptions prolongees de communication que cesproblemes declenchent, les liens vont leur apparaıtre plus instables et ils vont consommer beaucoupde ressources pour maintenir leurs tables de routage a jour.

Apres avoir detaille pourquoi certains sacrifices devraient necessairement etre faits pour reduireces problemes, nous y proposons dans le chapitre 6 deux solutions. La premiere est basee surune penalite. Cette penalite est appliquee d’une maniere particuliere aux mobiles qui bloquentleurs voisins en emettant trop et donne des resultats encourageants. Nous presentons ensuite uneseconde methode, dans laquelle les mobiles diffusent des informations sur l’occupation du canalpercue localement. Avec les informations transmises par leurs voisins, les nœuds cherchent a secomporter de maniere plus equitable. Des resultats interessants seront egalement obtenus aveccette technique.

Par des mesures reelles. Dans le chapitre 7, apres en avoir justifie le choix face a des solutionsexistantes, nous presentons le logiciel forwarding que nous avons ecrit dans le but de faciliter larealisation d’experiences sur de veritables reseaux multi-sauts.

Dans le chapitre 8 nous utilisons forwarding pour verifier que certains comportements prevuspar la simulation et le calcul se transposent effectivement dans la realite. Il s’agit en particulier demesures sur les debits possibles en fonction de la taille des paquets, de l’effet de la cryptographieWEP (Wired Equivalent Privacy), et de divers phenomenes lorsque le canal doit etre partage entreun certain nombre de mobiles a portee de communication.

8

Dans le meme chapitre, nous soulignons ensuite les limites des modeles utilises dans les simula-tions. En particulier, l’absence de gestion des debits multiples utilises par 802.11 pour ses paquetsde controle et les donnees ainsi que la forme de la zone de couverture. Sous les simulateurs, lesmodeles de propagation couramment utilises (free-space, two-ray ground et shadowing) conduisenta des zones de couverture circulaires centrees sur le mobile emetteur. Par des series de mesures adifferentes distances, vitesses de transmission et orientations des cartes radio, nous montrons quela realite est bien differente. Nous fournissons des graphiques nous permettant d’estimer la porteede communication des cartes en fonction des positions respectives des emetteurs et recepteurs. Cesmemes graphiques nous servent egalement a montrer l’effet des interferences qui se traduit par uneinstabilite des liens, meme en l’absence de mobilite.

Par des mesures en environnement reel a l’aide du logiciel que nous avons developpe, nousconfirmons les problemes mentionnes dans le premier point et en soulevons d’autres.

Par une analyse avancee des resultats des mesures. Les metriques habituellement utiliseespour mesurer les performances des reseaux (debits, taux de perte, delais, ...) ont rapidement montreleurs limites dans l’aide a la comprehension des phenomenes issus de l’utilisation des couches PHY etMAC de 802.11 dans un contexte multi-sauts. La realisation de chronogrammes precis s’etait reveleetres utile lors de l’analyse des resultats de simulation. Aussi, dans le chapitre 9, nous presentonsune methode qui permet de realiser de tels graphiques a partir d’experiences reelles. Les problemesprincipaux lors du passage de la simulation a l’experimentation sont essentiellement lies a l’absenced’horloge globale et a une derive trop rapide des horloges locales des mobiles. Une etude de cettederive est presentee et un mecanisme permettant d’en corriger les effets est proposee.

Dans le chapitre 10 nous realisons des experiences mettant en œuvre des scenarios typiquementad hoc. Il s’agira de deux paires s’eloignant l’une de l’autre, du scenario des trois paires deja etudiepar simulation et enfin d’une configuration de chaıne. Les resultats de ces experiences confirmerontles problemes d’equite de l’acces au canal et la necessite de mieux prendre en compte les couchesbasses lors de la conception des protocoles de routage ad hoc.

Disposant alors de tous les outils necessaires, nous implementons dans le chapitre 11 lemecanisme de penalite decrit dans le chapitre 4. Certaines adaptations sont cependant necessaires,du fait de l’impossibilite de modifier la couche MAC, celle-ci etant codee dans une memoireembarquee sur les cartes reseau radio et non modifiable (il nous etait tout du moins impossibled’avoir acces a ses codes source qui ne sont pas ouverts). Les resultats encourageants obtenus sontalors commentes et ouvrent des pistes pour des mecanismes plus elabores et plus efficaces.

Cette these constitue un travail de trois ans qui a ete realise au sein du LIP puis du CITI,Isabelle Guerin-Lassous en a assure l’encadrement au jour le jour durant toute la duree. Certainsdes travaux presentes ici sont encore en cours, d’autres ont deja fait l’objet de publications dansdes conferences internationales ([3, 4]) ou nationales ([5, 6]). Notons egalement la presentation decertaines parties sous forme de poster a MS3G 2001, et la finalisation lors du debut de la these de[7, 8] qui concluaient des travaux effectues en DEA.

9

CHAPITRE

1 Les reseaux ad hoc

1.1 Objectifs

Les reseaux ad hoc auxquels nous nous sommes interesses sont ceux decrits et etudies parle groupe de travail Mobile Ad-hoc NETworks (MANET) de l’Internet Engineering Task Force(IETF). Une definition de ces reseaux est donnee formellement dans la RFC 2501 [9]. Il s’agit dereseaux sans fil et sans infrastructure fixe, utilisant generalement le medium radio, et ou chaquenœud peut combiner les roles de client et de routeur. Les reseaux ad-hoc sont auto-organises, cequi implique que la connectivite doit etre preservee autant que possible automatiquement lorsquela topologie du reseau change (suite a l’apparition, la disparition ou au mouvement de certainsnœuds). Les premiers travaux sur ce type de reseaux ont ete effectues dans une optique militaire(la capacite a se reconfigurer et a rester operationnel en cas de perte de certains mobiles etantun avantage considerable) ; mais leur champ d’application est beaucoup plus vaste. Par exemple,ces reseaux faciles a deployer peuvent etre particulierement utiles pour retablir les communicationslorsque des catastrophes ont detruit les installations fixes existantes, on encore lorsque l’on desiredeployer un reseau de capteurs dans certains environnements hostiles.

1.2 Problemes et contraintes specifiques des reseaux radio

De par la nature du canal radio, un certain nombre de problemes se posent qui ne trouvent pasd’equivalent dans le monde filaire. On peut citer en particulier :

– Un debit plus faible par rapport a un equivalent filaire. Il faut donc que la gestion dureseau occupe une part la plus reduite possible des maigres ressources en bande passante.

– Une attenuation rapide du signal en fonction de la distance (bien plus rapide que sur uncable) qui induit l’impossibilite pour un emetteur de detecter une collision au moment memeou il transmet. Dans un reseau filaire, un emetteur sait qu’il y a collision quand le signalqu’il lit sur le cable est different de celui qu’il cherche a emettre. Dans un reseau radio, unsignal venant d’un autre nœud est tellement attenue par la distance qu’il ne provoquera quedes perturbations negligeables par rapport au signal emis localement. Par exemple, sur lafigure 1.1, au niveau du nœud B, le signal emis par B lui-meme est de tres loin superieur acelui qu’il recoit du nœud A. Par consequent, le signal du nœud A est completement ignorepar B qui croit qu’il n’y a pas de collision. Malheureusement, au niveau du nœud C, les deuxsignaux ont des puissances comparables et il y a bien collision du point de vue du recepteur.Seul un systeme d’acquittement peut garantir la bonne reception d’un message dans ce typede contexte. Cette incapacite a detecter un signal etranger lorsque l’on emet nous-meme rend

10

CHAPITRE 1. LES RESEAUX AD HOC

AB

C

D

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

donc le medium radio half-duplex, ce qui signifie que l’on ne peut pas emettre et recevoir enmeme temps.

– Les interferences. Les liens radios ne sont pas isoles, et le nombre de canaux disponiblesest limite. Il faut donc se les partager. Les interferences peuvent etre de natures diverses.Par exemple, des emetteurs travaillant a des frequences trop proches peuvent interfererentre eux. L’environnement lui-meme peut egalement produire des bruits parasites (certainsequipements electriques, certains moteurs, ...) qui interferent avec les communications. L’envi-ronnement peut aussi deformer le signal et le rendre rapidement incomprehensible a cause desphenomenes d’attenuation, de reflexion ou de chemins multiples (l’attenuation et la reflexionvarient en fonction des materiaux rencontres ; le probleme des chemins multiples apparaıtlorsque des reflexions d’une meme onde par des chemins differents arrivent de maniere decaleedans le temps au recepteur, se chevauchent, et forment un tout plus difficile a analyser). Cesproblemes font que les taux d’erreurs de transmission dans les reseaux radio sont nettementplus eleves que dans les reseaux filaires. Cela a un impact non negligeable sur les protocolesde niveau superieur. TCP en particulier va y etre particulierement vulnerable, car il va in-terpreter les pertes de paquets comme etant dues a de la congestion sur le reseau. Quand TCPdetecte de la congestion, il cherche a l’attenuer en reduisant la taille de sa fenetre d’emission[10]. Malheureusement, dans le cas present, c’est exactement l’inverse qu’il faudrait faire, lespaquets perdus doivent etre re-emis au plus vite. TCP Westwood [11] est une variante deTCP qui cherche a corriger ce probleme en estimant la bande passante de bout en bout et engerant differemment la reduction de la taille de sa fenetre.Il faut ajouter egalement que des interferences ou des changements persistants dans l’envi-ronnement vont conduire a une grande versatilite des liens, qui peuvent apparaıtre ou etrecoupes de maniere durable a tout moment.

– La puissance du signal. Non seulement elle est rapidement attenuee avec la distance, maiselle est egalement limitee par des reglementations tres strictes. Un emetteur ne peut doncdepasser une certaine puissance a l’emission.

– L’energie. Les applications relatives aux reseaux sans fil ont en general un caractere nomadeet tirent leur autonomie de batteries. Emettre ou recevoir des donnees consomme de l’energieet l’on peut chercher a l’economiser en optimisant les protocoles de gestion du reseau. Lapuissance d’emission a un impact important sur la quantite d’energie utilisee et la encore onessaie si possible de la limiter a ce qui est strictement necessaire.

– Une faible securite. Il est facile ”d’espionner” un canal radio de maniere passive. Lesprotections ne pouvant pas se faire de maniere physique (il est en general difficile d’empecherquelqu’un de placer discretement une antenne receptrice tres sensible dans le voisinage), elledevront etre mises en place de maniere logique, avec de la cryptographie ou eventuellement

11


des antennes tres directionnelles. Mais le canal radio restera quoiqu’il en soit vulnerable a unbrouillage massif (attaque de type denial of service).

– La mobilite. De nombreuses applications des reseaux radio concernent des mobiles qui,comme leur nom l’indique, sont amenes a se deplacer. Ceci va conduire a des changementsplus ou moins rapides de la topologie. Pour les gerer, des protocoles appropries vont etrenecessaires.

Nous avons vu que le full-duplex etait rendu impossible par l’attenuation trop rapide des signauxen fonction de la distance. Pour pouvoir travailler sur un canal half-duplex, les communicationspeuvent etre multiplexees en temps (TDD : Time Division Duplex). En TDD, un nœud peuttransmettre durant certains slots et recevoir durant d’autres slots dans la meme bande de frequences.Quand les debits deviennent tres importants, le temps de passage d’un mode a l’autre devientcependant non negligeable. Le multiplexage FDD (Frequency Division Duplex) permet quant a luid’emettre et de recevoir en meme temps car on travaille alors sur plusieurs frequences differentes.Mais les equipements necessaires sont plus complexes.

Dans les reseaux ad hoc, certaines des contraintes presentees precedemment sont accentuees etd’autres apparaissent en supplement :

– L’impossibilite de mettre en place un plan d’allocation des frequences limite lareutilisation spatiale. Dans les reseaux radio utilisant des stations de base, on cherche aattribuer des frequences differentes aux stations voisines, evitant que les cellules ainsi creeesn’interferent entre elles. Dans les reseaux ad hoc, pour garantir la connectivite, comme il n’ya pas d’infrastructure fixe et que tous les nœuds sont susceptibles de bouger ou de disparaıtre,il est plus simple et moins couteux de travailler avec une seule frequence. On utilise alors unmultiplexage TDD. La reutilisation spatiale reste possible, mais un nœud qui emet empechel’acces au canal radio par tous les mobiles se trouvant dans un voisinage etendu autour delui.

– L’energie. Dans un reseau a stations de base, les dites stations sont en general alimentees surle secteur. Dans un reseau ad-hoc ces stations sont absentes. De plus, suivant la topologie dureseau, certains mobiles peuvent se trouver dans des positions clef et assurer le routage pourun grand nombre de flux (entre plusieurs sous-parties du reseau autrement independantes parexemple). Ces nœuds peuvent etre amenes a consommer tres vite leurs ressources energetiques.Le trafic de controle peut egalement avoir un impact important. Comme un reseau ad-hocdoit s’auto-organiser, cela signifie que d’une maniere ou d’une autre il va y avoir un tra-fic de controle dependant de la mobilite dans le reseau. Plus la topologie changera vite etprofondement, plus la charge (et donc la consommation d’energie) du trafic de controle seraimportante.

– La mobilite. L’impact d’une mobilite ”totale” est important a differents niveaux. Du pointde vue des couches basses (PHY et MAC), comme nous l’avons deja souligne, il n’est d’unepart plus possible d’affecter des frequences a des zones geographiques ; d’autre part, lesmecanismes d’acces au medium utilisant des horloges globales seront egalement inutilisables(TDMA par exemple a besoin d’une grande synchronisation des horloges qui est impossibledans ce contexte). A un niveau plus eleve, dans les reseaux a stations de base (en particuliera grande echelle comme dans les reseaux de telephonie mobile), le routage est effectue dans lapartie fixe du reseau. Dans le cas des reseaux ad hoc, l’ensemble du routage doit fonctionnersur les mobiles et de facon totalement distribuee. Cela necessite de nouveaux algorithmes etles contraintes a leur realisation sont plus importantes.

12


– La faible securite. Dans les reseaux ad hoc, non seulement les donnees sont vulnerablescomme dans tout reseau radio, mais consecutivement au point precedent, il en est de memepour le trafic de controle et de gestion du routage [12, 13]. Les problematiques de la securitedans les reseaux ad hoc sont donc tres complexes, puisque l’on cherche a autoriser de nouveauxmobiles a participer au reseau, tout en evitant des nœuds ”malins” qui detourneraient ouperturberaient le fonctionnement meme du routage.

– La qualite de service. De nombreuses applications ont besoin de certaines garanties re-latives par exemple au debit, au delai ou encore a la gigue. Dans ces reseaux ad hoc, cesgaranties sont tres difficiles a obtenir. Ceci est du a la nature du canal radio d’une part (in-terferences et taux d’erreur eleves) et au fait que des ”liens” entre des mobiles peuvent avoira se partager les ressources (alors qu’en filaire, deux liens sont par definition independants).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 specifiquesdoivent etre proposes [14, 15].

1.3 Routage

Les reseaux ad hoc que nous considerons sont multi-sauts. Il peut donc arriver qu’un mobileveuille communiquer avec un autre qui n’est pas dans sa portee de communication directe. Lesmessages vont devoir etre transmis de proche en proche jusqu’a la destination : c’est ce que l’onappelle le routage. La technique la plus basique est l’inondation, ou chaque mobile re-emet tousles paquets qu’il recoit pour la premiere fois. Evidemment, l’inondation consomme beaucoup deressources (bande passante et energie) et n’est pas optimale. De nombreux protocoles de routageont donc ete proposes pour rendre les communications multi-sauts plus efficaces (moins de re-emissions, chemins plus courts, etc.) que l’inondation basique.

Meme si elle n’en constitue pas le fondement, la connaissance des protocoles de routage du mondead hoc est necessaire au travail que nous avons mene. Nous allons voir plus loin que les phenomenesdes niveaux physique et MAC ont des impacts importants sur les protocoles de niveaux superieurs.Mais ces impacts varient grandement en fonction des techniques utilisees pour le routage.

Dans cette section, nous allons donc presenter certains des protocoles de routage developpesdans le cadre du groupe de travail MANET de l’IETF. Ces protocoles travaillent au niveau IPet sont donc independants des couches physique et MAC. Le routage IP permet en particulierune interconnectivite aisee avec toutes sortes d’autres reseaux ou materiels. Il est d’ailleurs pos-sible d’utiliser ces protocoles pour federer en un seul reseau MANET des utilisateurs utilisant desmateriels differents (cartes radios de technologies diverses, reseaux filaires, etc.). Les protocolespresentes sont parmi les plus representatifs des diverses techniques utilisees pour le routage ad hoc.

1.3.1 Routage hierarchique ou plat

Les protocoles de routage pour les reseaux ad hoc peuvent etre classes suivant plusieurs criteres.Le premier d’entre eux concerne le type de vision qu’ils ont du reseau et les roles qu’ils accordentaux differents mobiles.

– Les protocoles de routage ”a plat” considerent que tous les nœuds sont egaux (figure 1.2).La decision d’un nœud de router des paquets pour un autre dependra de sa position et pourraetre remise en cause au cours du temps.

13


N1

N10

N11N4

N9

N8

N3

N5

N7

N6

N2

Fig. 1.2 – Routage ”a plat”

N4N6

N8

N7

N5

N3

N2

N1

P1

P2

P3

Fig. 1.3 – Routage hierarchique

– Les protocoles de routage hierarchique fonctionnent en confiant aux mobiles des roles quivarient de l’un a l’autre. Certains nœuds sont elus et assument des fonctions particulieres quiconduisent a une vision en plusieurs niveaux de la topologie du reseau. Par exemple, un mobilepourra servir de passerelle pour un certain nombre de nœuds qui se seront attaches a lui. Leroutage en sera simplifie, puisqu’il se fera de passerelle a passerelle, jusqu’a celle directementattachee au destinataire. Un exemple est donne sur la figure 1.3, ou le nœud N3 passe parles passerelles P1, P2 et P3 pour atteindre N7. Dans ce type de protocole, les passerellessupportent la majeure partie de la charge du routage (les mobiles qui s’y rattachent saventque si le destinataire n’est pas dans leur voisinage direct, il suffit d’envoyer a la passerelle quise debrouillera). Dans les reseaux ou certains nœuds s’averent tres sedentaires et disposentde suffisamment d’energie (par exemple reseau d’ordinateurs portables mais ou certains sontrelies au secteur, stations de base disposees la pour garantir la connectivite, etc.) , ce type deroutage presente certains avantages.

1.3.2 Etat de liens ou vecteur de distance

Une autre classification, heritee du monde filaire, est possible pour les protocoles de routage :

Les protocoles a etat de lien. Ils cherchent a maintenir dans chaque nœud une carte plus oumoins complete du reseau ou figurent les nœuds et les liens les reliant. A partir de cette carte ilest possible de construire les tables de routage. Un des avantages de ce type de protocole est leurcapacite a pouvoir facilement trouver des routes alternatives lorsqu’un lien est rompu. Il est memepossible d’utiliser simultanement plusieurs routes vers une meme destination, augmentant ainsi larepartition de la charge et la tolerance aux pannes dans le reseau. En contre partie, si le reseau estetendu, la quantite d’informations a stocker et diffuser peut devenir considerable.

Les protocoles a vecteur de distance. Plutot que de maintenir une carte complete du reseau(ce qui peut s’averer extremement lourd), ces protocoles ne conservent que la liste des nœuds dureseau et l’identite du voisin par lequel passer pour atteindre la destination par le chemin le pluscourt. A chaque destination possible sont donc associes un next-hop et une distance. Si un voisinnous envoie un paquet de controle dans lequel il indique etre plus pres d’une destination que le next-hop que l’on utilisait jusqu’alors, alors il le remplace dans la table de routage. Un des inconvenientsde cette technique et qu’il n’est du coup plus possible de conserver plusieurs routes alternatives aucas ou celle qui est privilegiee serait rompue.

14


1.3.3 Les differentes familles de protocoles de routage MANET

Dans les travaux menes a l’IETF, plusieurs familles de protocoles se sont rapidement degagees.Chaque protocole peut ainsi etre classifie en tant que reactif, proactif, ou hybride.

Les protocoles reactifs

Le principe des protocoles reactifs est de ne rien faire tant qu’une application ne demande pasexplicitement d’envoyer un paquet vers un nœud distant. Cela permet d’economiser de la bandepassante et de l’energie. Lorsqu’un paquet doit etre envoye, le protocole de routage va rechercherun chemin jusqu’a la destination. Une fois ce chemin trouve, il est inscrit dans la table de routageet peut etre utilise. En general, cette recherche se fait par inondation (un paquet de recherchede route est transmis de proche en proche dans tout ou partie du reseau). L’avantage majeur decette methode est qu’elle ne genere du trafic de controle que lorsqu’il est necessaire. Les principalescontre-parties sont que l’inondation est un mecanisme couteux qui va faire intervenir tous les nœudsdu reseau en tres peu de temps et qu’il va y avoir un delai a l’etablissement 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 desire envoyer un paquet a un autre mobile, une route soitimmediatement connue. Dans le contexte des reseaux ad-hoc les nœuds peuvent apparaıtre oudisparaıtre de maniere aleatoire et la topologie meme du reseau peut changer ; cela signifie qu’il vafalloir un echange continuel d’informations pour que chaque nœud ait une image a jour du reseau.Les tables sont donc maintenues grace a des paquets de controle, et il est possible d’y trouverdirectement et a tout moment un chemin vers les destinations connues en fonctions de diverscriteres. On peut par exemple privilegier les routes comportant peu de sauts, celles qui offrentla meilleure bande passante, ou encore celles ou le delai est le plus faible. L’avantage premier dece type de protocole est d’avoir les routes immediatement disponibles quand les applications enont besoin, mais cela se fait au cout d’echanges reguliers de messages (consommation de bandepassante) qui ne sont certainement pas tous necessaires (seules certaines routes seront utilisees parles applications en general).

Les protocoles hybrides

Les protocoles hybrides combinent les approches reactive et proactive. Le principe est deconnaıtre notre voisinage de maniere proactive jusqu’a une certaine distance (par exemple troisou quatre sauts), et si jamais une application cherche a envoyer quelque chose a un nœud qui n’estpas dans cette zone, d’effectuer une recherche reactive a l’exterieur. Avec ce systeme, on disposeimmediatement des routes dans notre voisinage proche, et lorsque la recherche doit etre etendueplus loin, elle en est optimisee (un nœud qui recoit un paquet de recherche de route reactive vatout de suite savoir si la destination est dans son propre voisinage. Si c’est le cas, il va pouvoirrepondre, et sinon il va propager de maniere optimisee la demande hors de sa zone proactive). Selonle type de traffic et de les routes demandees, ce type de protocole hybride peut cependant combinerles desavantages des deux methodes : echange de paquets de controle reguliers et inondation del’ensemble de reseau pour chercher une route vers un nœud eloigne.

15


1.3.4 Description de quelques protocoles de routage representatifs

Les protocoles decrits par la suite sont issus du groupe de travail MANET de l’IETF. Cesprotocoles sont representatifs de diverses techniques et sont les plus avances sur la voie d’unenormalisation. AODV et OLSR font desormais l’objet d’une Request For Comment (RFC) tandisque les autres en sont a des versions assez stabilisees de leur drafts.

Ad-hoc On Demand Distance Vector (AODV)

AODV [16] est un protocole base sur le principe des vecteurs de distance et appartient a la familledes protocoles reactifs. Les protocoles a vecteur de distance sont en general sujets au probleme deboucle et de comptage a l’infini de l’algorithme de Bellman-Ford qu’ils utilisent (certaines parties dureseau se trouvent isolees du reste, et les nœuds les composant vont croire qu’ils peuvent atteindre lesnœuds desquels ils sont coupes en passant par leurs voisins. Il s’en suit un phenomene de bouclagedans lequel les nœuds injoignables se voient attribuer des distances de plus en plus grandes).Dans le cas d’AODV, ces problemes sont resolus par l’utilisation de numeros de sequence pour lesmessages de controle. Quand une application a besoin d’envoyer des paquets sur le reseau et qu’uneroute est disponible dans la table de routage, AODV ne joue aucun role. S’il n’y a pas de routedisponible, il va par contre en rechercher une. Cette recherche commence par une inondation depaquets Route Request (RREQ). Chaque nœud traverse par un RREQ en garde une trace dansson cache et le retransmet. Quand les paquets de recherche de route arrivent a la destination (oua un nœud intermediaire qui connait lui-meme une route valide jusqu’a la destination), alors unpaquet de reponse est genere (RREP) et il est envoye par le chemin inverse, grace aux informationsgardees dans les caches des nœuds traverses par les RREQ (voir figure 1.4). AODV dispose d’uncertain nombre de mecanismes optimisant son fonctionnement. L’inondation se fera par exempleau premier essai dans un rayon limite autour de la source, et si aucun chemin n’est trouve, alorsseulement elle sera etendue a une plus grande partie du reseau. En cas de rupture de certains liens,AODV va essayer de reconstruire localement les routes affectees en trouvant des nœuds suppleants(cette detection de rupture peut d’ailleurs se faire grace a un mecanisme optionnel de paquets hellodiffuses aux voisins directs uniquement). Si une reconstruction locale n’est pas possible, alors lesnœuds concernes par la rupture des routes utilisant ce lien sont prevenus de sorte qu’ils pourrontrelancer une nouvelle phase de reconstruction complete.

Dynamic Source Routing (DSR)

DSR [17] est un autre protocole reactif. Il se differencie des autres en particulier parce qu’ilpratique le source routing : l’emetteur precise dans l’en-tete de chaque paquet la liste des nœudsqu’il devra traverser pour atteindre sa destination. Ce type de routage presente certains avantagesparticulierement interessants ; il autorise en particulier la source a conserver dans sa table de routageplusieurs chemins valides vers une meme destination. Le choix du chemin emprunte pourra doncetre fait independamment pour chaque paquet, et permettre un meilleur equilibrage de la chargedu reseau ou une meilleure reactivite aux pannes / changements de topologie (plutot que de toutde suite en construire une nouvelle quand une route est brisee, on en a d’autres a dispositionimmediate). Dans la pratique, DSR est structure en deux sous-parties complementaires : la recherchede route et la maintenance de route. La recherche de route se fait par inondation : un paquet derecherche est diffuse de proche en proche jusqu’a la destination. Au fur et a mesure, les identifiantsdes nœuds traverses sont ajoutes dans le paquet de recherche de route. Quand elle recoit ce paquet,

16


Source

F

Dest.

D

C

E

A

B

rreq (1)

rreq (1)

rreq (2)

rreq (3)

rreq (4)

rreq (3)rreq (2)

rrep (1)

rrep (2)

rrep (3)

rrep (4)

rreq (2)

rreq (4)

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

Source

F

Dest.

D

C

E

A

B

rreq (1)

rreq (1)

rreq (2)

rreq (3)

rreq (4)

rreq (3)rreq (2)

rrep (1)

rrep (2)

rrep (3)

rrep (4)

rreq (2)

rreq (4)rrep (1)

rrep (2)

rrep (3)

rrep (4)

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

la destination sait donc deja quel chemin il a emprunte, et obtient ainsi (en l’inversant) la routepour retourner a la source. A la reception par la destination de paquets de recherche ayant suivi deschemins differents, la destination repond sur les chemins inverses, et la source aura ainsi finalementplusieurs chemins valides pour l’atteindre (voir figure 1.5).

Optimized Link State Routing (OLSR)

OLSR [18] est un protocole proactif a etat de liens. Afin de maintenir a jour les tables deroutage, chaque nœud implementant OLSR diffuse regulierement des informations sur son proprevoisinage. Ces informations sont suffisantes pour permettre a chaque nœud de reconstruire uneimage du reseau et de trouver une route vers n’importe quelle destination. Mais contrairement ades protocoles tels qu’OSPF, cette diffusion ne se fait pas par une simple inondation (ou chaquenœud retransmet simplement chaque nouveau paquet qu’il recoit) ; OLSR optimise la diffusiongrace au systeme des relais multi-points (Multi-Points Relays : MPR). Chaque nœud choisit dansses voisins directs un sous-ensemble minimal de nœuds qui lui permettent d’atteindre tous sesvoisins a deux sauts (voir figure 1.6). La diffusion des informations sur les liens utilisees pour leroutage se fait ensuite uniquement par les relais multi-points ; la couverture totale du reseau estassuree tout en limitant sensiblement le nombre de re-emissions. Afin de choisir ses relais multi-points, un nœud a besoin de connaitre completement la topologie de son voisinage a deux sauts ;cela est realise grace a l’envoi periodique de paquets hello contenant la liste des voisins a un sautconnus.

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

TBRPF [19] est un protocole de routage proactif a etat de liens. Chaque nœud maintient enpermanence un arbre dont il est la racine et qui fournit les chemins les plus courts pour tous lesautres nœuds du reseau. TBRPF est constitue de deux parties complementaires : la decouverte desvoisins et le routage proprement dit.

17


Source

MPRMPR

MPR

Fig. 1.6 – Relais multipoints

La decouverte des voisins est assuree par un mecanisme de paquets hello diffuses regulierementau voisinage direct. Ces paquets hello contiennent la liste des voisins du nœud, et permettentainsi de rapidement connaıtre la topologie complete du reseau a deux sauts. Il faut noter queTBRPF emploie une technique de hello differentiels ou seuls les changements de topologie sontnotifies (diminuant ainsi la taille moyenne des paquets et autorisant leur envoi a une plus grandefrequence).

La partie routage quant a elle est basee sur un echange des arbres de routage entre nœudsvoisins, conduisant progressivement a la diffusion de l’information dans l’ensemble du reseau.La encore cependant seules des parties d’arbres sont echangees. Normalement, un nœud nediffuse qu’un sous-arbre a deux niveaux dont il est la racine. Au premier niveau apparaissent lesliens vers tous les voisins directs du nœud, et au deuxieme niveau un unique lien vers chaquevoisin a deux sauts (on peut noter ici une certaine similitude avec le mecanisme des relaismulti-points d’OLSR). En conjonction avec ce systeme de base, TBRPF peut egalement ajouterdes informations sur d’autre liens a l’arbre diffuse, avant de reagir plus vite en cas de changementde la topologie. A noter enfin que dans un souci d’economie de bande passante, les sous-arbres etles paquets hello sont regroupes autant que possible dans un meme paquet (on parle d’agregationou piggybacking puisque l’on profite des paquets hello pour envoyer en meme temps les sous-arbres).

De nombreux autres protocoles de routage ont ete proposes pour les reseaux ad hoc. [20]en decrit un certain nombre en sus de ceux deja mentionnes. Dans la categorie des protocolesconstruisant une topologie hierarchique on peut citer Clusterhead Gateway Switch Routing(CGSR) presente dans [21]. Certains autre protocoles necessitent l’emploi de materiels externes.Par exemple Temporaly-Ordered Routing Algorithm (TORA) [22] a besoin que les mobilessoient synchronises. D’autres ([23],[24]) utilisent le systeme GPS pour estimer la directiongeographique de la destination et ne faire intervenir qu’une sous-partie du reseau dans la phasede 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 criteresen consideration. ABR (Associativity-Based Routing) [25] par exemple privilegie les liens lesplus stables (mobiles qui restent longtemps dans le voisinage les uns des autres). SSR (SignalStability Routing) [26] travaille a partir des informations de niveau de signal et [27] cherche a maxi-miser la duree de vie du reseau en agissant sur la puissance d’emission de chaque mobile separement.

Les reseaux ad hoc font partie d’un domaine de recherche qui n’a pris son essor que tresrecemment. Le facteur qui a declenche cet interet fut l’arrivee de technologies relativement bonmarche qui ont favorise la conception et le deploiement de tels reseaux. Avant cela, ce domaineetait reserve aux militaires qui disposaient de moyens tout autres.

Les principales normes de reseaux sans fil qui sont a l’origine cet interet pour les reseaux adhoc sont HiperLAN 1 [28] et 2 [29], Bluetooth [30] et 802.11 [31] de l’IEEE.

19

CHAPITRE

2 Presentation de 802.11

Dans la seconde moitie des annees 90, plusieurs normes pour les reseaux sans fils a portee limiteeon ete developpees (visant des usages a l’echelle du bureau ou du batiment). Leur arrivee a souleveun engouement nouveau pour les reseau radio multi-sauts, qui etaient jusqu’alors le domaine exclusifdes militaires. Dans ce chapitre, nous allons presenter ces differentes normes, et en particulier 802.11,qui est desormais utilisee dans la plupart des travaux appliques de la communaute ad hoc.

2.1 Les autres normes de reseaux locaux sans fil.

Bluetooth a plutot pour objectif de faire disparaıtre les cable entre les divers equipementsnumeriques (peripheriques d’ordinateurs tels que clavier, imprimantes, modems, ou encore appareilsphoto numeriques, PDA, walkmans, etc.). Les equipements bluetooth ont donc des portees et desdebits assez modestes, ainsi qu’une consommation electrique en rapport.

802.11 est concue pour les reseaux locaux, en entreprise ou chez les particuliers. Cette normes’appuie sur des stations de base reliees a un reseau filaire qui fournir une infrastructure fixe etreliant les utilisateurs mobiles aux ressources de l’entreprise (et eventuellement a l’Internet). Depuispeu, 802.11 (et en particulier les cartes compatibles a son extension 802.11b) connaissent un succescommercial considerable.

HiperLAN type 1 a ete concu comme le pendant europeen de 802.11. Cette norme se veut assezsimilaire dans son utilisation, mais certains choix technologiques ont ete faits qui se demarquentnettement de 802.11. Commercialement cependant HiperLAN est reste a l’etat de prototype et n’estjamais sorti des laboratoires de recherche.

HyperLan type 2 a pour but de concurrencer les versions les plus performantes de 802.11(802.11a et 802.11g) en offrant des debits aussi eleves et un certain nombre de fonctionnalitessupplementaires. Mais la encore, il est a craindre qu’HiperLAN 2 ne soit jamais commercialisee agrande echelle.

2.1.1 HiperLAN 1

High Performance Local Area Network type 1 (HiperLan 1) est un standard de l’EuropeanTechnical Standard Institute (ETSI). Il decrit le fonctionnement d’equipements travaillant dans labande des 5.15-5.30 GHz et permettant d’atteindre des debits de 23.5 Mbit/s sur une distance d’en-viron 50 metres. L’architecture est totalement decentralisee. Il n’y a pas de notion de point d’accesmais les nœuds HiperLAN 1 peuvent cependant avoir des roles de passerelles. Les caracteristiquesles plus marquantes d’HiperLAN 1 sont :

20

CHAPITRE 2. PRESENTATION DE 802.11

– le mecanisme d’acces au medium evolue, qui gere les priorites. Il est possible d’obtenir desgaranties de qualite de service, particulierement utiles pour les flux multimedias par exemple ;

– la possibilite d’etendre le reseau au dela de la portee radio, par sauts successifs (fonctionne-ment en cela tres semblable aux reseaux ad hoc, des nœuds jouant le role d’intermediairesentres ceux qui sont trop loin pour communiquer directement).

Les fonctionnalites d’HiperLAN 1 sont organisees comme presente sur la figure 2.1. Nous n’en-trerons pas dans les details de cette norme complexe, mais nous pouvons remarquer neanmoins quele mecanisme d’acces au medium EY-NPMA (Elimination Yield-Non Preemptive Multiple Access)est au cœur du systeme. C’est lui qui permet en particulier la gestion des priorites. Le fonction-nement de EY-NPMA est particulierement interessant puisqu’il est prevu pour fonctionner dansun contexte ad hoc. Nous allons donc le decrire plus en avant. Il fonctionne en trois phases et unexemple est donne sur la figure 2.2 :

– La phase de priorite. Cinq niveaux de priorite sont definis par la norme (de 0 pour leplus prioritaire a 4) et la phase de priorite est donc divisee en cinq slots. Au debut d’unnouveau cycle de transmission, tous les nœuds qui veulent acceder au canal vont envoyer unburst de signalement, dont la date de debut depend de la priorite du paquet. Plus la prioriteest elevee, plus le burst commence tot. Sur la figure, les nœuds A, C et D ont une prioritede 2, et le nœud B a une priorite de 3. L’idee est d’ecouter le canal tant que notre prioritenous interdit d’emettre notre propre burst de signalement. Si l’on detecte de l’activite avantd’avoir pu emettre, c’est que quelqu’un est plus prioritaire que nous, et l’on abandonne l’ideede transmettre pour ce cycle. C’est le cas du nœud B sur la figure 2.2.

– La phase d’elimination. Il se peut que plusieurs nœuds veuillent emettre en meme tempsdes paquets de priorites identiques. Il faut donc les departager. Pour cela, chaque nœud vapoursuivre l’envoi de son burst de signalement pendant un nombre aleatoire de slots. Ce seracelui qui aura tire le plus grand nombre qui l’emportera. Des que l’emission de notre burst estterminee, nous ecoutons le canal. Si nous y detectons de l’activite, c’est qu’un autre nœud atire un plus grand nombre que nous, et nous abandonnons pour ce cycle. Sur la figure, c’estle cas du nœud C .

– La phase d’ecoute. Si toutefois il reste plusieurs nœuds en lice alors l’elimination va seterminer dans la troisieme phase. Un nombre aleatoire de slots est choisit. C’est celui quiaura tire le plus petit qui pourra transmettre. Chaque nœud attend pendant la duree qu’il adetermine, en ecoutant le canal. Si il detecte 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’emettra pas durant ce cycle. Sison attente se termine alors que le canal est toujours libre, alors il emet. Sur la figure, c’estle nœud D qui l’emporte. Il faut noter que si le paquet est envoye en point a point, il seraacquitte par son recepteur (ici le nœud E).

Avec HiperLAN type 1, un mecanisme de routage multi-sauts est implante. Les nœuds envoientdes paquets hello qui leur permettent de connaıtre leur voisinage. Ces informations de voisinagesont propagees dans tout le reseau et permettent ainsi a un nœud d’en reconstruire la topologie.C’est un protocole a etat de lien qui utilise une systeme de relais multipoints pour optimiser lesdiffusions d’informations.

21


Couche physique

Accès multiple et gestion du

trafic multimédia

Relayage et gestion des informations topologiques

Système de connaissance

du réseau

Economie d'énergie

Système de cryptage

Couches supérieures

Fig. 2.1 – Organisation d’Hiperlan 1

Phas

e de p

riorité

Phas

e d'él

imina

tion

Phas

e d'éc

oute

DATA

ACK

fin du cycle précédent

Les trois phases de l'accès multiple

Accusé de réception (uniquement pour le trafic point

à point)

A

B

C

D

E

Fig. 2.2 – L’acces au canal avec EY-NPMA

2.1.2 HiperLAN 2

L’organisation generale d’HiperLAN type 2 est presentee sur la figure 2.3. On remarque enpremier lieu que la norme prevoit la compatibilite avec diverses technologies (TCP/IP bien sur,mais aussi ATM, UMTS et l’IEEE 1394 connue aussi sous le nom de Firewire).

HiperLAN type 2 est tres different dans son architecture d’HiperLAN type 1. Contrairementau type 1, le type 2 est base sur une centralisation poussee. Les points d’acces sont d’ailleursindifferemment appeles Access Points (AP) ou Central Controler (CC). Les points d’acces sontrelies entre eux par une infrastructure reseau filaire ou non-filaire (qui doit simplement disposerd’une interface adequate dans HyperLAN 2, comme celles de la liste donnee precedemment). Lesmobiles s’attachent ensuite a ces points d’acces pour acceder aux ressources du reseau.

HiperLAN 2 peut aussi fonctionner sans infrastructure fixe. Dans ce cas, un mobile est elu pourjouer le role de controleur central et les autres vont s’attacher a lui. Bien entendu, dans ce typede configuration il n’est pas question de reseau ad hoc au sens ou le groupe MANET l’entend.Tout au plus, les mobiles pourront communiquer directement entre eux (un saut), ou alors parl’intermediaire du controleur central (deux sauts).

L’acces au medium reflete ces choix architecturaux, et c’est le controleur central qui decide del’ordonnancement des communications dans la zone qu’il gere. Ces communications se font grace ades trames de duree fixe (2 ms) qui sont elles-memes decoupees en differents champs de longueurvariable et qui portent les informations de controle du point d’acces ou les donnees dans un sens oudans l’autre. Il faut noter egalement que la couche physique d’HiperLAN type 2 est tres semblablea la couche physique de 802.11a (qui sera presentee plus en detail dans la section dediee a 802.11).

De part son architecture tres ciblee, HiperLAN 2 est donc peu adapte aux reseaux ad hoc, etnous ne detaillerons pas plus cette norme ici.

2.1.3 Bluetooth

Les reseaux Bluetooth ont ete developpe pour permettre la realisation de reseaux personnels(PAN : Personnal Area Network). Ces reseaux doivent permettre des communications a courteportee, a des debits faibles ou moyens entre toute sorte d’equipements. Ils travaillent dans la bande

22


Couche de convergence réseau (NC)

TCP/IP ATM / B-ISDN

UMTS IEEE 1394

Couche liaison (DLC)

Couche Physique

Fig. 2.3 – L’organisation generale d’HiperLAN type 2

ISM des 2.4 GHz a des puissances leur permettant d’atteindre des portees allant du metre a lacentaine de metres environ.

C’est le groupe de travail Bluetooth SIG (Bluetooth Special Interest Group) qui a elabore lesspecifications de Bluetooth. Ce groupe de travail, au depart constitue de grosses societes de l’infor-matique et des telecommunications telles qu’IBM, Ericsson, Intel ou Nokia, a rapidement pris del’ampleur et regroupe actuellement plus de 2500 societes.

Il faut noter que le Bluetooth SIG n’est pas le seul organisme produire des specifications dansce domaine, le groupe de travail 802.15 de l’IEEE completant et prolongeant ces travaux dansplusieurs directions :

– Le sous-groupe 802.15.1. Il a pour role, en accord avec le Bluetooth SIG, de traduire lesspecifications Bluetooth en specifications de type 802.

– Le sous-groupe 802.15.2. Il doit etudier les configurations des reseaux personnels et no-tamment la coexistence de ces reseaux avec les reseaux locaux sans fils (du type de 802.11).

– Le sous-groupe 802.15.3. Il travaille sur les specifications d’un reseau personnel a hautdebit (de l’ordre de 20 Mbit/s).

– Le sous groupe 802.15.4. Il etudie les specifications pour des reseaux personnels a basdebit (de l’ordre de 200 kbit/s).

Les reseaux Bluetooth sont construit de maniere centralisee. Un maıtre elu peut prendre encharge jusqu’a huit esclaves et forme ainsi un piconet. Dans un piconet, c’est le maıtre qui controletoutes les transmissions. Les esclaves ne peuvent emettre des paquets que s’ils y ont ete invitespar le maıtre. Ce dernier doit donc les interroger regulierement pour savoir s’ils ont des donnees aenvoyer (polling).

Plusieurs piconets peuvent etre relies afin de former une structure plus grande appeleescatternet (de l’anglais scatter, disperse). A cette fin, les mobiles peuvent quitter temporairementleur piconet pour aller s’attacher a un autre. La figure 2.4 donne un exemple de scatternet. Unesclave alterne entre les piconets 1 et 2 afin d’en assurer la liaison et un mobile esclave du piconet2 est aussi maıtre dans le piconet 3 (le processus de de-association est reversible, il est possible dequitter temporairement un piconet puis de le rejoindre a nouveau et de revenir a la situation initiale).

L’acces au medium dans Bluetooth est gere par intervalles de temps reguliers (slotted). Le slotde base a une duree de 625 µs. Au niveau physique, Bluetooth fonctionne par sauts de frequencetres rapides (jusqu’a 1600 sauts par seconde). La frequence reste la meme pour la duree d’un slot.En general, sauf si le paquet a transmettre est trop long pour tenir sur un seul slot auquel cas il enoccupe plusieurs, la frequence change apres chaque slot selon un schema cyclique.

23


Esclave

Maître dans P3

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

Esclave

Esclave

Esclave

Esclave

Esclave dans P2

Esclave

Esclave

Esclave

MaîtreMaître

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 presente bel et bien une forme de reseau ad hoc multi-sauts. Mais du fait de l’utilisationciblee pour un usage personnel, ces reseaux restent assez statiques et leur etendue volontairementlimitee.

2.2 Introduction a 802.11

802.11 [31, 32] est une norme etablie par l’IEEE. Elle decrit les couches physique et MACd’interfaces reseau radio et infra-rouge. Les debits possibles varient entre 1 et 54 Mbit/s suivantles techniques et les eventuelles extensions de la norme employees. Les portees prevues variententre quelques dizaines et quelques centaines de metres en fonction de la vitesse choisie et del’environnement. Cette norme cible deux contextes d’utilisation :

– Le mode ”infrastructure” (l’utilisation privilegiee de 802.11), ou des stations de basereliees entre elles par un reseau filaire assurent la couverture d’une certaine zone et prennenten charge les mobiles dans leur voisinage (figure 2.5).

– Le mode appele ad hoc, qui consiste en fait simplement a autoriser les communicationsentre deux mobiles a portee l’un de l’autre, sans intervention de stations ou d’autres mobilesexterieurs (figure 2.6).

La norme originelle 802.11 date de 1997 et decrit les couches physiques et MAC pour un debitallant jusqu’a 2 Mbit/s en radio, dans la bande des 900MHz. Des extensions ont ete publiees depuisqui viennent lui ajouter des ameliorations et des modes de fonctionnement plus performants. Lesprincipales extensions sont les suivantes :

– 802.11 (version de 1999) passe dans la bande ISM des 2.4 GHz, avec toujours des debitspouvant atteindre les 2 Mbit/s. Cette bande de frequence est partagee avec d’autres types dereseaux locaux sans fil (Bluetooth en particulier) ainsi que par diverses autres applications.

– 802.11b ajoute la description d’une couche physique amelioree proposant des debits de 5.5et 11 Mbit/s en plus de ceux deja supportes.

24


Station de base

Station de base

Fig. 2.5 – Reseau 802.11 en mode infrastruc-ture Fig. 2.6 – Reseau 802.11 ad-hoc

OSI Layer 2Data Link Layer

OSI Layer 1Physical Layer

(PHY)

802.11 Logical Link Control (LLC)

802.11 Medium Access Control (MAC)

FHSS DSSS IR Wi-Fi802.11b

...Wi-Fi5802.11a

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

– 802.11a ajoute des modes encore plus rapides (jusqu’a 54 Mbit/s) en travaillant dans labande des 5GHz, mais en utilisant des techniques OFDM (presentees succinctement dans lasection suivante) d’acces au canal.

– 802.11g utilise des technique OFDM similaires 802.11a, mais en restant dans la bande ISMa 2.4GHz. Les debits possibles atteignent egalement les 54 Mbit/s tout en gardant la compa-tibilite avec les equipements 802.11b.

– 802.11e cherche a ameliorer 802.11 de facon a pouvoir donner des garanties de qualite deservice. Cette extension de la norme n’est pas encore finalisee.

– 802.11h cherche a mieux gerer la puissance d’emission et la selection des canaux dans labande des 5 GHz suivant si l’on est a l’interieur ou a l’exterieur de batiments. L’objectif estd’etre, a terme, mieux en accord avec les diverses legislations (notamment europeennes).

– 802.11i cherche a ameliorer les mecanismes de securite et d’authentification ; ce travail n’estpas encore finalise non plus.

Afin de permettre la mise en place de ces differentes ameliorations et de presenter aux couchessuperieures une interface tres similaire a 802.3 (le celebre Ethernet), 802.11 propose le modele encouches de la figure 2.7. La sous-couche LLC est l’interface ”visible” de 802.11, c’est par son in-termediaire que les grandes similitudes avec 802.3 sont possibles. La sous-couche d’acces au medium(MAC) est specifique a 802.11, mais reste la meme quelles que soient les couches physiques em-ployees en-dessous. Pour finir, un certain nombre de couches physiques sont definies. Originellementseules une couche infra-rouge et une couche radio dans la bande des 900MHz etaient definies. Lacouche physique radio proposait deja plusieurs techniques de modulation (FHSS et DSSS, presenteeselles aussi dans la section suivante) a utiliser en fonction du debit desire (qui pouvait aller jusqu’a2 Mbit/s). Par la suite d’autres couches physiques ameliorees ont ete ajoutees. Les plus importantesde ces couches PHY dans le contexte des reseaux ad hoc seront decrites dans la section suivante.

25


2.3 La couche physique

Initialement, le standard IEEE 802.11 permet l’utilisation de trois couches physiques differentes(FHSS, DSSS et IR), auxquelles 802.11a a ajoute ODFM :

– FHSS : Frequency Hoping Spread Spectrum. La plupart des interferences nuisibles aux trans-missions radio n’agissent en fait que sur des bandes de frequence assez etroites. Si par mal-chance de telles interferences ont lieu au moment ou l’on transmet, alors notre signal serafortement degrade. Une technique pour proteger notre signal consiste a regulierement changerde frequence (figure 2.8). Bien sur les paquets envoyes sur la bande perturbee seront affectes,mais ils ne representeront plus qu’une minorite des transmissions et leur retransmission seramoins couteuse. L’emetteur et le recepteur doivent connaıtre a l’avance le sequencement dessauts de frequence, mais des informations portees par les paquets permettent a un mobiles’attachant au reseau de savoir a partir d’un paquet qu’il recoit ou en est le deroulement dela sequence.

– DSSS : Direct Sequence Spread Spectrum. Toujours pour lutter contre les interferences impor-tantes mais n’affectant que des plages de frequences assez etroites, il existe la technique del’etalement de spectre. Des manipulations sur le signal vont le faire occuper un spectre pluslarge (on le multiplie par une sequence pseudo-aleatoire ayant certaines proprietes d’auto-correlation). A la reception, une manipulation inverse est effectuee (figure 2.9). Cette tech-nique est moins sensible aux interferences dues aux frequences parasites a faible largeur spec-trale.

– IR : Infra Red. Que l’on ne detaillera pas ici du fait de son absence totale du marche.– OFDM : Orthogonal Frequency Division Multiplexing. Nous avons deja mentionne le probleme

des chemins multiples : lorsqu’un signal radio est emis, l’onde va se refracter, se reflechir etdonc se diviser sur les divers obstacles rencontres. A l’arrivee plusieurs chemins pourrontavoir ete empruntes, et leur temps de parcours n’etant pas forcement les memes, les multiplesrefractions / reflexions d’une meme onde vont interferer entre elles. Plus la difference detemps de parcours sera grande vis a vis de la duree de transmission totale du symbole, plusles chances que des reflexions / refractions de symboles consecutifs se chevauchent. Pouraugmenter le debit, l’approche traditionnelle consiste a reduire la duree d’un symbole, maiscela augmente aussi les problemes de chemin multiple. OFDM propose donc d’utiliser dessymboles plus longs, mais envoyes en parallele. On peut dire pour resumer succinctementcette methode qu’en presence de chemins multiples, a debit total equivalent, l’agregation d’uncertain nombre de canaux lents donne de meilleurs resultats qu’un seul canal tres rapide.

A l’origine, la bande de frequence utilisee etait celle des 900MHz. Les extensions successives ontajoute d’autres couches physiques afin de permettre des debits de plus en plus eleves en radio.

802.11 (version de 1999) La version de 1999 de 802.11 a remplace la bande des 900 MHz parla bande ISM (2.4 GHz). Dans la bande ISM, 14 canaux radio de 20 MHz de largeur ont ete definis.Suivant les reglementations, ils ne sont pas tous utilisables dans tous les pays (voir table 2.1).

Il n’est possible pour un emetteur ou un recepteur de ne travailler que sur un seul canal a lafois. Disposer de plusieurs canaux permet donc de les affecter aux stations de base de maniere a ceque deux cellules voisines n’interferent pas entre elles (on ameliore ainsi la reutilisation spatiale).Un exemple est donne sur la figure 2.10.

26


Temps

Fréquence

Interférences

Fig. 2.8 – Changer de frequenceregulierement pour reduire l’impactde certaines interferences

Etalement de spectre

InterférencesMessage fortement

dégradé par les interférences

Message peu dégradé par les

interférences

Transmission

Message à transmettre

Fréquence

Amplitude

Fig. 2.9 – Etaler le spectre pour reduire l’impact de cer-taines interferences

Pays (organisme regulateur) Bandes de frequenceEtats-Unis (FCC) 2.400 - 2.485 GHzEurope (ETSI) 2.400 - 2.435 GHzJapon (MKK) 2.471 - 2.497 GHzFrance (ART) 2.400 - 2.454 GHz a 100 mW, 2.454 - 24835 GHz a 10 mW en exterieur

2400 - 2483.5 Ghz a 100mW en interieur

Tab. 2.1 – Reglementations de la bande ISM

De plus, il faut preciser que ces canaux ne sont pas tous independants les uns des autres. Ils sechevauchent en partie, comme presente sur la figure 2.11. Il faut egalement noter que la bande ISMtend a etre saturee car de nombreux equipements 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 DSSSmodifiee (High Rate DSSS) avec une modulation CCK (Complementary Code Keying) et definitainsi les vitesses de 5.5 et 11 Mbit/s. Le canaux restent les memes et la compatibilite est preserveeavec les modes a 1 et 2 Mbit/s. Afin de garantir l’interoperabilite des materiels 802.11b des differentsconstructeurs, la WECA (Wireless Ethernet Compatibility Alliance1) a cree le label Wi-Fi. Les

1www.weca.net

1 7

1

13

13 1

13

Fig. 2.10 – Le reutilisation spatiale grace a un plan d’allocation des frequences

27


Canal 1 Canal 7 Canal 13

2.4 GHz 2.4835 GHz

83 MHz

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

200 MHz

5.32 GHz5.20 GHz 5.22 GHz 5.24 GHz 5.26 GHz 5.28 GHz 5.30 GHz5.18 GHz5.15 GHz

5.35 GHz

Fig. 2.12 – Les 8 premiers canaux definis par 802.11a

produits estampilles Wi-Fi on ete analyses grace a des tests de compatibilite developpes par laWECA et leur interoperabilite 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 ete definis(voir figure 2.12 pour les 8 premiers, les 4 derniers etant dans les 5.7 GHz). La bande UN-II estmoins encombree que la bande ISM. L’autre principal utilisateur de la bande UN-II est HiperLan2, qui n’est pas repandu commercialement. 802.11a autorise des debits allant jusqu’a 54 Mbit/s,mais cela se fait au detriment de la portee de communication qui n’excede pas quelques dizaines demetres aux debits les plus eleves. De facon similaire au label Wi-Fi des produits 802.11b, le labelWi-Fi5 de la WECA garantit l’interoperabilite des produits 802.11 le portant.

802.11g 802.11g, publiee apres 802.11a travaille dans la meme bande ISM que 802.11b maisutilise les memes techniques OFDM que 802.11a afin de permettre des debits allant egalementjusqu’a 54 Mbit/s. La aussi, la compatibilite est preservee avec 802.11b. Il faut cependant noterque les debits maximums ne peuvent etre obtenus qu’a courte portee et que si la station de baseet l’ensemble des mobiles de la cellule utilisent 802.11g.

La figure 2.13 recapitule les differentes technologies et debits possibles pour chacune d’entreelles.

2.4 La couche MAC

La couche MAC de 802.11 peut utiliser deux modes de fonctionnement.– Distributed Coordination Fonction (DCF) est un mode qui peut etre utilise par tous

les mobiles, et qui permet un acces equitable au canal radio sans aucune centralisation de la

28


802.11 802.11b 802.11a 802.11g

FHSS DSSS HR-DSSS OFDM OFDM

1 Mbit/s2 Mbit/s

1 Mbit/s2 Mbit/s

5.5 Mbit/s 11 Mbit/s

6 Mbit/s9 Mbit/s

12 Mbit/s18 Mbit/s24 Mbit/s36 Mbit/s48 Mbit/s54 Mbit/s

Jusqu'à 54Mbit/s

Fig. 2.13 – Recapitulatifs des technologies et des debits possibles

gestion de l’acces (mode totalement distribue). Ce mode peut aussi bien etre utilise lorsqu’iln’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 lacharge de la gestion de l’acces au canal dans leur zone de couverture pour les mobiles qui leursont rattaches.

Dans les reseaux ad hoc multi-sauts, il n’y a pas de stations de base fixes et c’est donc lemode DCF qui sera employe. Le mode DCF va etre decrit dans la sous-section suivante. Le modePCF sera neanmoins decrit brievement lui aussi, dans la mesure ou les mecanismes qu’il utilisesont fondamentaux dans 802.11 et que leur comprehension apporte a la comprehension globale ducomportement de 802.11 dans le contexte des reseau ad hoc.

2.4.1 Description du mode DCF

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

Dans le monde filaire, lorsqu’un emetteur envoie un signal sur le cable, il peut y lire en memetemps la valeur qui y est effectivement presente. Si jamais la valeur lue est differente de celleque l’emetteur ecrit, c’est qu’un autre emetteur est actif au meme moment et qu’il y a collision.Cette ecoute du signal sur le cable au moment de l’emission est a la base de la methode d’accesCSMA/CD bien connue d’Ethernet. CSMA/CD permet de detecter une collision et le cas echeantde retransmettre le paquet apres un temps d’attente aleatoire.

En radio cependant, l’attenuation du signal en fonction de la distance est bien plus importanteque sur un cable. Au niveau d’un emetteur, le signal qu’il envoie va donc etre recu avec unepuissance tres superieure a un signal venant de n’importe quel autre mobile. Par exemple, sur lafigure 2.14 sont schematisees les puissances recues reciproquement par deux emetteurs A et B. Unsignal emis localement est recu avec une puissance tellement superieure aux autres signaux qu’il lesocculte completement. Du point de vue d’un emetteur, il n’y a donc jamais de collision en radio.Evidemment le probleme se pose au niveau du recepteur, ou plusieurs signaux pourraient ainsi etrerecus simultanement avec des puissances comparables. Dans la pratique, des collisions se produisenteffectivement uniquement au niveau des recepteurs.

La premiere caracteristique de la couche MAC de 802.11 est donc d’utiliser des acquittementspour detecter ces collisions et permettre la retransmission des paquets qui ont ete perdus (enl’absence d’acquittement, l’emetteur sait qu’il doit retransmettre).

29


A B

Emis par AEmis par B

Position

Puissance perçue

Fig. 2.14 – L’attenuation tres rapide des signaux rend la detection de collision impossible

Il faut noter que 802.11 peut envoyer une trame a un recepteur specifique (unicast) ou ladiffuser (broadcast). Dans le cas de la diffusion, il n’y a pas d’acquittement et des paquets peuventetre perdus de maniere tout a fait silencieuse (ce qui est logique, car chaque mobile ayant recu lepaquet chercherait a envoyer l’acquittement au meme moment et il y aurait une serie de collisionssur les acquittements).

En Ethernet, l’idee est d’observer l’etat du canal avant d’emettre. Si le canal est libre, alors nouspouvons envoyer notre trame (et si a ce moment-la nous detectons une collision, nous re-emettonsla trame un peu plus tard, apres une attente de duree aleatoire). Or nous venons de voir qu’enradio il n’etait pas possible de detecter directement les collisions. Par consequent, le mecanismequi conditionne l’autorisation d’emettre sur le canal doit lui aussi etre modifie par rapport a cequi se fait en 802.3. En effet, si nous nous contentions d’attendre que la canal devienne libre pouremettre, alors si plusieurs mobiles etaient en attente d’emission, ils detecteraient tous le canal libreet emettraient au meme moment. Il y aurait collision au recepteur et il faudrait attendre que ledelai imparti pour le retour de l’acquittement soit ecoule pour s’en rendre compte, ceci pourraitetre relativement long.

L’idee retenue pour 802.11 est donc, lorsque le canal devient libre, d’attendre une periode deduree aleatoire supplementaire appelee backoff avant d’emettre. Ce mecanisme s’applique lorsquele canal devient libre aussi bien apres une de nos propres emissions qu’apres toute autre emission.Ainsi, si plusieurs mobiles veulent emettre, il y a peu de chances pour qu’ils aient choisi la memeduree. Celui qui a choisi le plus petit backoff va commencer a emettre, et les autres vont alorsse rendre compte qu’il y a a nouveau de l’activite sur le canal et vont attendre. La figure 2.15schematise ce qui se passe lorsque deux mobiles a portee de communication veulent emettre versun troisieme et que le canal devient libre.

Lorsque le canal devient libre, avant toute chose, il faut qu’il le reste pour une periode DIFS(DCF Inter-Frame Space). Si le canal est reste libre durant toute cette periode, alors les mobilesqui veulent emettre choisissent un backoff aleatoire exprime en un nombre de time slots d’une dureefixe de 20 µs. Le backoff est choisit au hasard dans un intervalle appele Contention Window (CW)qui est par defaut [0 ;31] ; avec un time slot de 20 µs, le backoff va donc normalement etre comprisentre 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. Unefois ce tirage effectue, tant que le canal reste libre, les mobiles decrementent leur backoff. Des quel’un d’eux a termine (ici le mobile 1), il emet. L’autre mobile, des qu’il detecte le regain d’activitesur le canal stoppe la decrementation de son backoff et entre en periode de defering.

30


destination

source 2

autrecanal

occupé

DATA

DIFS SIFS

ACK

DIFS

DATA

ACK

SIFS

defering

back

off

back

off

back

off re

stant

source 1

Fig. 2.15 – Le backoff et le defering

Il faut noter que le temps de pause qui separe un paquet de donnees de son acquittement estappele SIFS (Short Inter-Frame Space) et qu’il est plus court que DIFS. Le mobile en periode dedefering ne pourra reprendre la decrementation de son backoff que si le canal est a nouveau librependant DIFS. Le fait que SIFS soit plus court empeche que la decrementation ne reprenne demaniere inopportune entre les donnees et leur acquittement.

Lorsque les donnees du mobile 1 ont ete acquittees et que DIFS s’est ecoule sans activite surle canal, le mobile 2 peut reprendre la decrementation de son backoff. Ici, aucun autre mobile nevient l’empecher de terminer et il peut donc finalement envoyer ses donnees.

Le mecanisme de backoff limite les risques de collision mais ne les supprime pas completement.Aussi, si une collision se produit quand meme (detectee grace a l’absence d’acquittement), unnouveau backoff va etre tire au hasard. Mais a chaque collision consecutive, la taille de la fenetreva doubler afin de diminuer les chances que de telles collisions se repetent. La borne inferieure dela Contention Window est toujours zero, et la borne superieure (dont les valeurs autorisees par lanorme ne sont que des puissances de 2 moins 1) va evoluer entre les valeurs aCWmin et aCWmaxdefinies par la norme. La borne superieure de la fenetre est re-initialisee a aCWmin sitot qu’unpaquet a ete transmis correctement (ou lorsque les timers de re-emission expirent). Un exempled’evolution de la fenetre de contention est donne sur la figure 2.16.

Le mecanisme RTS/CTS

Nous avons vu que le mecanisme CSMA/CA cherche a eviter les collision en ecoutant l’activitesur le canal et en choisissant un delai aleatoire supplementaire avant l’emission. Mais il existe unefamille de configuration ou ce mecanisme est insuffisant. Il s’agit du probleme des nœuds caches(figure 2.17) ou deux emetteurs qui ne peuvent pas du tout s’entendre (en general a cause d’unobstacle) veulent atteindre un meme recepteur. Comme dans cette configuration un emetteur nedetecte jamais l’activite de l’autre, il croit que le canal est toujours libre et emet des qu’il a desdonnees disponibles. Les chances de collisions a repetition au niveau du recepteur sont tres elevees.

802.11 propose un mecanisme utilisant des paquets de controle appeles Request To Send (RTS)et Clear To Send (CTS) introduit par [33]. Un mobile qui veut emettre ne va plus directementenvoyer son gros paquet de donnees, mais plutot un petit paquet RTS pour lequel les chancesde collision sont plus faibles. A ce paquet RTS, le destinataire va repondre par un petit paquet

31


715

31

63

127

255 255aCWmax

aCWmin

Troisième retransmissionDeuxième retransmission

Première retransmissionTentative 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 quipermettent de reserver le canal pour la duree de transmission des donnees qui vont suivre. Unmobile qui recoit un CTS alors qu’il n’a pas envoye (ni meme detecte de RTS) sait que quelqu’und’autre va emettre et doit donc attendre. Le mobile qui a envoye le RTS sait, quand il recoit leCTS correspondant, que le canal a ete reserve pour lui et qu’il peut emettre.

Au niveau des mobiles, la reservation du canal est implementee grace au Network AllocationVector (NAV). Dans chaque nœud, le NAV indique pour combien de temps le canal est utilise parquelqu’un d’autre, independamment de ce qui est physiquement percu sur le canal (on parle ausside detection de porteuse ’logique’). Sur la figure 2.19 sont presentees les mises a jour du NAV auniveau d’un mobile alors qu’une trame est echangee entre deux autres mobiles. Lorsque le nœud nonconcerne par l’echange recoit le RTS, il sait grace aux informations contenues dans ce dernier pourcombien de temps il ne devra pas acceder lui-meme au canal. Nous avons vu que dans certainesconfigurations (par exemple celle de la figure 2.17), certains paquets ne sont pas recus par tousles mobiles potentiellement concernes. Les CTS et les paquets de donnees vont donc aussi devoirporter les informations de duree, afin que leur reception puisse mettre le NAV a jour (un exempleest donne dans la figure 2.18 ou seul le CTS est recu par le mobile de droite).

A B

Fig. 2.17 – Le probleme des nœuds caches

RTS (1)

CTS (2) CTS (2)

DATA (3)ACK (4)

Fig. 2.18 – L’echange RTS/CTS

32


source

destination

autre

RTS

CTS

SIFS SIFS

DATA

SIFS

ACK

DIFS

NAV (RTS)

NAV (CTS)Temps

NAV (DATA)

Fig. 2.19 – Le Network Allocation Vector (NAV)

Le mecanisme EIFS

Dans la configuration presentee sur la figure 6.13, le nœud de gauche (”autre”) detecte laporteuse de l’emetteur sans pour autant comprendre ses messages (le signal est trop faible pouretre decode, mais suffisamment fort pour etre reconnu comme tel). Les paquets envoyes par lerecepteur ne sont quant a eux pas detectes du tout par le mobile de gauche. Dans cette situation,802.11 impose l’utilisation d’un Extended Inter Frame Spacing(EIFS), afin d’eviter une collisionau niveau de l’emetteur au moment du CTS et de l’acquittement par le recepteur. La figure 2.21detaille ce qui se passe : L’emetteur envoie tout d’abord un paquet de controle RTS. Ce paquetest recu par le recepteur, qui va y repondre par un CTS. Le mobile de gauche, lui, a detecte del’activite au moment du RTS mais sans comprendre le paquet. Le mecanisme de defering presenteprecedemment l’empeche d’emettre pendant l’envoi du RTS (canal occupe) et pendant une periodeDIFS consecutive (on est toujours oblige d’attendre que la canal ait ete libre pendant DIFS pouremettre). Mais DIFS est plus court que SIFS+CTS. Si jamais le mobile de gauche avait terminede decrementer son backoff trop vite, il aurait pu emettre pendant le CTS, causant une collision auniveau de l’emetteur. Pour proteger le CTS (et de maniere similaire l’acquittement), 802.11 imposequ’un nœud doive attendre pendant un temps EIFS lorsque le canal redevient libre mais que lepaquet n’a pas ete compris ; la longueur de EIFS etant suffisante pour que l’envoi du CTS ou del’ACK se deroule dans de bonnes conditions.

2.4.2 Description du mode PCF

Nous avons vu que le mode DCF permettait un fonctionnement totalement distribue de l’accesau medium, mais que, afin de limiter le nombre des collisions, CSMA/CA avait recours a une dureealeatoire avant l’emission de chaque paquet. Le temps passe a attendre represente autant de debiteffectif perdu. Aussi 802.11 propose en option un mecanisme centralise qui permet d’obtenir unmeilleur 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’implementant.

Le principe de base de la PCF est de centraliser la gestion de l’acces au medium d’une cellule.C’est le point d’acces qui indiquera a chacun des mobiles qui lui sont rattaches quand ils doiventemettre leurs paquets. Le backoff aleatoire devient ainsi en partie inutile. Durant toute la phase ou

33


Emetteur Récepteur

Autre

Fig. 2.20 – Une configuration ou l’EIFS estnecessaire

source

destination

autre

RTS

CTS

SIFS SIFS

DATA

SIFS

ACK

DIFS

Temps

EIFSdefer defer

DIFS

EIFS

Fig. 2.21 – L’Extended Inter Frame Spacing(EIFS)

Balise PCF DCF

CFP CP

PCF DCF

CFP CP

Balise

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’acces au canal ;on parle de Contention Free Period.

De plus, afin de preserver la compatibilite, dans chaque cycle de la PCF, une periode de DCFest conservee et permet aux mobiles n’implementant pas la PCF de continuer a acceder au canal.C’est la Contention Period (figure 2.22). La cohabitation entre les mobiles implementant la PCF etceux ne l’implementant pas est assuree grace au temporisateur PIFS (PCF Inter Frame Spacing).Durant la periode sans contention, les trames ne sont en effet separees que de periodes PIFS (ouSIFS suivant les cas) qui sont toutes les deux plus courtes que DIFS. Grace a ces temporisateurs,un mobile n’implementant pas la PCF ne risque donc pas de prendre la main durant la periodegeree par la station de base en mode PCF.

Il faut noter que pour l’instant, tres peu de cartes implementent la PCF (mais en general unemise a jour du firmware embarque dans les cartes et les stations de base sera possible).

2.5 La securite des informations : la Wired Equivalent Privacy (WEP)

Dans la section consacree aux problemes specifiques des reseaux radio, nous avons signale lafacilite avec laquelle il est possible pour un tiers d’ecouter passivement les communications radio.Afin de se premunir contre ces ecoutes 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 recus avec unepuissance suffisante que dans les zones que l’on controle, comme nos bureaux ou les hangars denotre usine). Mais meme un placement specialement pense des stations de base est mis en defautsi ”l’espion” utilise une antenne a fort gain.

Le chiffrement des donnees est donc necessaire si l’on recherche une certaine confidentialite.802.11 decrit de ce fait une methode de chiffrement : c’est la Wired Equivalent Provacy ou WEP,qui peut etre utilisee de maniere optionnelle. Le systeme repose sur une clef secrete qui doitetre partagee par l’emetteur et le recepteur. La distribution de cette clef est en dehors du cadre

34


RC4Graine

Algorithme d'intégrité (CRC)

Clef secrète

Vecteur d'Initialisation (IV)

Message en clair

Code de vérification d'intégrité concaténé aux

données

Partie chiffrée

Message

IV

Chiffrement (OU exclusif)

Séquence pseudo-aléatoire de chiffrement

(concaténation IV + clef)

Fig. 2.23 – Fonctionnement du chiffrement WEP

de la norme, et de nombreuses techniques existent, qui vont de la simple transmission de vivevoix a des serveurs d’authentification elabores. Nous ne detaillerons pas ces systemes qui sortentegalement du cadre de ce travail, mais la comprehension du mecanisme de chiffrement aura sonimportance, en particulier lorsque nous presenterons plus tard des resultats de mesures de debit reel.

Le principe du WEP est de combiner une sequence pseudo-aleatoire generee a partir de laclef avec les donnees. Seul le recepteur qui connaıt aussi la clef pourra generer la meme sequencepseudo-aleatoire et decoder le message. La figure 2.23 donne les details de ce chiffrement :

– Afin de renforcer la clef, on la combine avec un vecteur d’initialisation qui est change a chaquepaquet. L’idee est d’eviter qu’une meme clef soit utilisee souvent, et en particulier plusieursfois consecutives.

– La concatenation de la clef et du vecteur d’initialisation sert de graine pour l’algorithme RC4qui va generer la sequence pseudo-aleatoire de bits.

– D’autre part, un code de redondance cyclique (CRC) est calcule sur les donnees, et y estconcatene.

– Un OU exclusif est utilise pour combiner la sequence pseudo-aleatoire et les donnees a chiffrer(c’est le chiffrement proprement dit).

– Le vecteur d’initialisation est concatene aux donnees chiffrees et le paquet est envoye (l’IVdoit etre en clair, le recepteur n’a pas de moyen de prevoir quelle sera sa valeur).

A la reception, le mobile connaıt deja la clef secrete. Il lui adjoint le vecteur d’initialisationqu’il trouve au debut du paquet et genere la meme sequence pseudo-aleatoire que celle qui a servi acrypter. Avec un OU exclusif entre les donnees chiffrees et la sequence pseudo-aleatoire, il obtientdirectement les donnees en clair. La verification du CRC lui permet d’etre sur qu’aucune erreur nes’est produite et que sa clef etait la bonne.

Au sujet de RC4, [34] nous apprend que c’est un algorithme base sur des permutations. Une tablede 256 octets est initialisee avec la clef qui lui est fournie, et les elements de la table vont ensuiteetre permutes les uns les autres en fonction de leur valeur. Cet algorithme est repute sur et a enoutre l’avantage d’etre tres rapide (suivant le micro-processeur, entre 8 et 16 operations simples sontnecessaires pour produire un octet pseudo-aleatoire). Ceci est d’ailleurs particulierement importantcar les cartes reseau 802.11 n’embarquent pas en general des processeurs tres puissants.

35


DIFS

(50

µs)

Emetteur

RécepteurBa

ckof

f ( 0

à 6

20 µ

s)Ph

y hea

der (

192

µs)

Mac

hea

der (

24.7

µs)

Mac

dat

a (7

71 µ

s)

SIFS

(10

µs)

Phy h

eade

r (19

2 µs

)AC

K da

ta (5

6 µs

)

Temps

1 MBits/s

11 MBits/s

Trame de données

Acquittement

987.7 µs

248 µs

1295.7 à 1915.7 µs

2 MBits/s

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

2.6 Les trames 802.11b et le debit utile 802.11b

Dans la suite de nos travaux, lorsqu’il s’est agit d’effectuer des mesures avec des veritablescartes, nous avons utilise 802.11b. Nous detaillons donc ici plus en detail le fonctionnement et laconstruction des trames, de maniere a pouvoir comparer plus tard les debits pratiques aux debitstheoriques.

Sans detailler le contenu de chaque champ, il est tout de meme important de savoir que lespaquets envoyes par 802.11 sur le medium radio comprennent plusieurs niveaux d’encapsulation.Aux donnees venant des couches superieurs, au moment de l’envoi, est ajoutee une en-tete MACainsi qu’une en-tete physique. Les vitesses de transmission pour certaines de ces parties peuventvarier. L’en-tete physique est envoyee a la vitesse constante de 1 Mbit/s. L’objectif est de permettresa reception par toute station utilisant une carte 802.11b (et ainsi permettre la cohabitation entrela version d’origine et les versions plus rapides, 802.11g comprise).

L’en-tete MAC et les donnees sont envoyes a une vitesse negociee qui peut aller jusqu’a 54Mbit/s avec 802.11g.

Les paquets de controle (RTS/CTS/ACK) sont envoyes quand a eux a des vitesses qui peuventencore etre differentes. La norme indique que ces paquets doivent etre envoyes a une vitesse choisiedans la liste de celles qui vont permettre leur reception par tout autre mobile compatible. Maisces vitesses ne sont pas donnees explicitement. Dans la pratique, la plupart des constructeurspermettent a leurs paquets de controle d’etre envoyes a 2 Mbit/s et se replient sur 1 Mbit/s si lestaux d’echec sont trop importants. D’autres cependant proposent de les envoyer jusqu’a 11 Mbit/s,proposant ainsi des performances superieures a leurs concurrents lorsque les conditions sont ideales.Comme les paquets de controle, les paquets envoyes en mode diffusion le sont a des vitesses choisiesdans la liste des vitesses ”compatibles”. Par defaut, la diffusion se fera donc a 2 Mbit/s. Il fautnoter enfin que c’est bien l’ensemble des paquets qui sont sujets a cette encapsulation et que memeles paquets de controle possedent une en-tete physique qui est envoyee a 1 Mbit/s.

36


Si l’on decompose completement l’envoi d’un paquet UDP de 1032 octets de donnees a 11Mbits/s (figure 2.24), on observe (en considerant qu’il n’y a pas eu de collision ou de perte depaquet avant et que le canal vient juste de se liberer) :

- Un temps d’attente fixe DIFS de 50 µs (compte a partir du moment ou le canal devient libre)

- Un temps d’attente aleatoire (backoff) d’une duree comprise entre 0 et 31 time-slots de 20 µschacun (0 a 620 µs au total donc).

- L’envoi de la trame de donnees (qui dure ici 987.7 µs) decomposee en :

- L’en-tete physique de la trame, a 1 Mbit/s, qui dure 192 µs.

- L’en-tete MAC de la trame, a 11 Mbit/s, qui dure 24.7 µs.

- Les donnees proprement dites (ici 1032 octets de donnees application plus 28 octetsd’en-tete IP) envoyees a 11 Mbits/s, et qui durent 771 µs.

- Un temp d’attente fixe SIFS de 10 µs.

- L’acquittement, decompose en :

- L’en-tete 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 parametres, nous avons calcule les debits maximums possibles en fonction dela taille des paquets. Il faut noter que dans la realite, les paquets de grande taille peuvent etrefragmentes par les couches superieures si elle croient avoir affaire a 802.3 (Ethernet, dont la tailledes trames ne depasse pas 1500 octets environ). Dans nos calculs, nous avons donc tenu compte decette fragmentation. Les figures 2.25, 2.26 et 2.27 presentent les debits theoriques pour des vitessesrespectives d’emission physique des donnees de 11, 5.5 et 2 Mbit/s. Il faut noter que les courbespresentees ont pour but d’etre comparees dans la suite du document a des mesures reelles. Le lecteurinteresse par les debits theoriques de 802.11 les trouvera dans [35] pour ses diverses extensions, maissans la prise en compte de la fragmentation cependant.

37


0

1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

0 500 1000 1500 2000 2500 3000

debi

t en

bits

par

sec

onde

s

taille des paquets (donnees UDP)

11 Mbit/s11 Mbit/s, fragmentation

11 Mbit/s, RTS11 Mbit/s, RTS, fragmentation

Fig. 2.25 – Debits maximums theoriques en fonction de la taille des paquets (a 11 Mbit/s)

0

1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

0 500 1000 1500 2000 2500 3000

debi

t en

bits

par

sec

onde

s


5.5 Mbit/s5.5 Mbit/s, fragmentation

5.5 Mbit/s, RTS5.5 Mbit/s, RTS, fragmentation

Fig. 2.26 – Debits maximums theoriques en fonction de la taille des paquets (a 5.5 Mbit/s)

38


0

1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

0 500 1000 1500 2000 2500 3000

debi

t en

bits

par

sec

onde

s


2 Mbit/s2 Mbit/s, fragmentation

2 Mbit/s, RTS2 Mbit/s, RTS, fragmentation

Fig. 2.27 – Debits maximums theoriques en fonction de la taille des paquets (a 2 Mbit/s)

39

CHAPITRE

3 Particularites de 802.11 dansun contexte ad hoc

3.1 Introduction

802.11 a ete concu dans l’optique de reseaux d’entreprises ou de hot spots organises autour destations de base. Nous avons vu que de part son faible cout, sa disponibilite (aussi bien commercialeque dans les simulateurs) et par sa possibilite a etre utilise pour des reseaux multi-sauts par la simpleadjonction de protocoles de routage de niveau superieur, 802.11 est devenu le support privilegiepour l’etude des reseaux ad hoc. Mais un certain nombre de problemes apparaissent, qui peuventetre regroupes en plusieurs categories :

– Des problemes de topologie radio. Ils apparaissent lorsque les mobiles sont places dansdes configurations bien specifiques (des mobiles ne pouvant communiquer qu’avec certains deleurs voisins, ou encore ne detectant les porteuses que de certains autres). Ces problemes sontconnus depuis longtemps dans le contexte des reseaux a stations de base. 802.11 integre dessolutions pour certains (les nœuds caches) et en laisse d’autres de cote (les nœuds exposespar exemple). Mais lors du passage a des reseaux multi-sauts, ces problemes devoilent denouvelles facettes qu’il est necessaire de prendre en consideration.

– Des problemes lies aux debits multiples. 802.11 propose plusieurs vitesses de transmis-sion parmi lesquelles les mobiles choisissent en fonction des conditions du canal (les vitesses lesplus basses sont plus tolerantes aux perturbations radio et permettent une meilleure portee).Le fait de pouvoir utiliser plusieurs vitesses differentes va avoir des repercussions dans unreseau ad hoc. D’une part en terme de debit, puisque des problemes deja connus dans lesreseaux a stations de base risquent d’y etre magnifies. Et d’autre part en terme de connec-tivite, en particulier lorsque les protocoles de routage utilisent des paquets ayant une plusgrande portee que les donnees qui doivent etre envoyees ensuite.

– Des problemes d’equite entre des flux multiples et de debit total dans le reseau.802.11 etant prevu pour fonctionner dans des configurations ou la plupart des mobiles sont aportee les uns des autres (ou dans le pire des cas voisins a deux sauts), ses performances dansdes configurations multi-sauts sont nettement en deca des optimums theoriques, en terme dedebit et d’equite d’acces au canal.

3.2 Le probleme des nœuds caches

Le probleme des nœuds caches a ete introduit dans le chapitre 2 en meme temps que lemecanisme RTS/CTS utilise pour le corriger. Il faut cependant bien noter que dans le cadre prevupar 802.11, ce probleme n’apparaıt que dans une configuration comme celle de la figure 3.1, ou deuxmobiles isoles l’un de l’autre, utilisant une meme frequence et attaches a une meme station de base

40

CHAPITRE 3. PARTICULARITES DE 802.11 DANS UN CONTEXTE AD HOC

A B

Fig. 3.1 – Noeuds caches simples

A B C D E

Fig. 3.2 – Noeuds caches dans une chaıne

A B

C

ED

F

H

G

ACK

Fig. 3.3 – Multiples nœuds caches

veulent emettre vers cette derniere en meme temps. Dans ce contexte, le mecanisme de RTS/CTSest effectivement efficace. Pour peu que la charge du reseau soit importante, [36, 37] ont montre parle calcul et des simulations que le surcout en terme de debit des RTS/CTS est plus que compensepar le gain qu’il procure en evitant des collisions a repetition.

Dans un reseau ad hoc base sur 802.11, nous avons vu que tous les mobiles devront travaillersur la meme frequence s’ils veulent permettre une connectivite complete du reseau. De ce fait, lessituations de nœuds caches vont etre beaucoup plus nombreuses et plus frequentes. La figure 3.2donne un exemple de chaıne a quatre sauts. A l’instant considere, les mobiles B et D, qui ne s’en-tendent pas du tout, veulent emettre. 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 carles zones de detection de porteuse etant parfaitement circulaires et d’un rayon double de la zonede communication, B se trouverait dans la zone de detection de porteuse de D et reciproquement.Mais dans la realite, l’experience a montre que ce type de collision etait tout a fait possible, nousle verrons d’ailleurs par la suite. La figure 3.3 quant a elle, presente une configuration encore pluscomplexe. La encore, de nombreuses situations de collisions se presentent, du fait de l’utilisation partous les nœuds d’une seule et meme frequence. Le communications desirees sont (A→B), (D→E),(C→F) et (H→G). Si ces transmissions avaient lieu en meme temps, des collisions entre les donneespourraient se produire en B et en E, et, suivant la longueur des paquets, l’acquittement renvoye parF pourrait provoquer une collision en G avec les donnees venant de H. Ces constatations tendraienta nous faire penser que l’utilisation des RTS/CTS serait la solution a ces problemes. Malheureu-sement les RTS/CTS sont aussi sujets a problemes dans les reseau ad hoc. D’une part eux aussipeuvent entrer en collision (par exemple, sur la figure 3.3, si les CTS de B et E ne sont pas recus avecune puissance suffisante en C pour etre compris, alors C pourra emettre et eventuellement causerdes collisions en B et en E). D’autres configurations specifiques posant probleme sont egalementdecrites et analysees plus en detail dans [38] ou encore dans [39]. Nous verrons par ailleurs dansnos propres simulations et experiences des situations ou les RTS/CTS sont mis en defaut, lorsqu’ilsne peuvent etre compris correctement.

41


A B C D

Fig. 3.4 – Le phenomene des nœuds exposes

Zone de communication à 2 Mbit/s

Zone de communication à 11 Mbit/s

Fig. 3.5 – Le phenomene de la zone grise

3.3 Le probleme des nœuds exposes

Le probleme des nœuds exposes apparaıt dans des configurations comme celle presentee surla figure 3.4. Ici, les nœuds B et C voudraient emettre respectivement vers A et D. En suivant lemecanisme de la DCF, celui qui a tire le plus petit backoff va acceder au canal et envoyer son paquet,alors que l’autre detectera la porteuse du premier, et entrera en periode de defering. Pourtant, siB et C emettaient en meme temps, le signal de B au niveau de A serait largement superieur a celuide C et suffisant pour une reception correcte. La situation serait l’inverse au niveau du nœud D,qui recevrait correctement le paquet de C, malgre le leger bruit venant de B. Dans cette situation,la DCF limite donc inutilement la bande passante totale du reseau. On peut noter que certainstravaux s’interessent au probleme, notamment [40] qui propose l’utilisation d’un mecanisme deparallel RTS pour le resoudre en partie.

3.4 Le probleme de la zone grise

Nous avons vu que 802.11b utilise des vitesses de transmissions de 1 ou 2 Mbit/s pour lespaquets qu’il diffuse, mais que les paquets envoyes en unicast peuvent l’etre jusqu’a 11 Mbit/s. Laplupart des protocoles de routage utilisent la diffusion pour construire ou maintenir les routes (lespaquets Hello ou RouteRequest sont typiquement diffuses par exemple). Ces paquets sont donc emisa 2 Mbit/s et permettent de construire un certain nombre de routes dans le reseau. Mais lorsqueles donnees sont ensuite envoyees a 11 Mbit/s sur ces routes, comme la portee de communicationdecroıt avec l’augmentation de la vitesse, il est possible que des mobiles pourtant a portee despaquets de routage lents soient trop loin pour les paquets de donnees rapides. Il en decoule queles routes construites avec les paquets diffuses ne sont pas forcement exploitables a des debits plus

42


eleves. La zone concernee (la soustraction de la zone ”rapide” a la zone ”lente” plus large) estappelee ”zone grise” et ce probleme avait ete releve theoriquement et experimentalement dans [41].

3.5 Partage du canal entre des flux a vitesses differentes

En sus du phenomene des zones grises, l’utilisation des debits multiples que propose 802.11conduit a d’autres problemes. Lorsque des mobiles implementant 802.11 rencontre de forts taux deperte, la norme leur recommande de reduire leur vitesse d’emission (plus la vitesse est basse, plusle signal est resistant aux interferences et est comprehensible loin de l’emetteur). Mais, comme ill’est montre en detail dans [42], la methode DCF d’acces au medium ne cherche pas a equilibrer lesdebits de plusieurs flux en contention, mais plutot a donner a chaque paquet des chances equitablesd’etre envoye. Lorsque certains paquets sont envoyes a des vitesses elevees et d’autres a des vitesseslentes, cela va se traduire par une alternance plus ou moins reguliere entre eux. Les mobiles emettantleurs paquets tres lentement vont donc ”capturer” le canal pendant la majorite du temps et fairechuter le debit des autres mobiles qui ne prennent pourtant pas beaucoup de temps pour emettreleurs propres paquets. Ainsi, dans un environnement de competition entre plusieurs mobiles, si l’und’entre eux emet a 1 Mbit/s, meme si tous les autres travaillent a 11 Mbit/s, leurs debit utile seratres bas. Dans un environnement ad hoc, du fait du mecanisme de routage qui utilise en general lespaquets diffuses a 2 Mbit/s (comme note au paragraphe 3.4), beaucoup de liens ainsi decouvertsne supporteront pas des debits elevees (5.5 ou 11 Mbit/s) et s’en tiendront au debit reduit de2 Mbit/s. Les trafics sur les liens ou le 11 Mbit/s est possible seront donc le plus souvent affectesconsiderablement par ces autres liens plus lents.

3.6 TCP et 802.11

TCP est un protocole extremement utilise dans le monde filaire. Afin de pouvoir utiliser direc-tement dans les reseaux ad hoc les innombrables applications qui sont basees sur TCP, il faut queles performances de ce dernier dans ce contexte soient suffisantes. Un certain nombres d’etudes ontete conduites sur le comportement de TCP lorsqu’il est utilise au-dessus de 802.11 [43, 10, 44] etdes problemes consequents sont apparus. Les auteurs de ces articles se sont interesses a des confi-gurations ad hoc diverses, parmi lesquelles la chaıne se trouvaient a chaque fois. Ils ont utilise dessimulateurs (Network Simulator 2 et Glomosim) et ont constate les problemes suivants :

– L’instabilite des connexions. Les flux TCP sont tres souvent stoppes, et doivent reprendrea chaque fois en passant par la phase de demarrage lent. Ces interruptions sont dues a ladetection de cassure de liens au niveaux MAC. Il a ete montre que la taille de la fenetre TCPavait un impact tres important sur ce probleme, mais qu’il prend veritablement racine dansla couche d’acces au medium.

– L’inegalite entre certains flux. Dans certaines configuration multi-sauts, alors que l’on voudraitque plusieurs flux TCP se partagele canal, il arrive que certains d’entre eux ”capturent” lecanal et que d’autres soient completement stoppes ou presque.

Malheureusement, bien qu’elles aient souleve certains problemes, ces etudes sont basees sur certainesconfigurations ou l’analyse des phenomenes et de leurs origines est rendu complexe par l’empile-ment des protocoles et leurs diverses interactions. De plus, comme nous le verrons, ces problemespeuvent encore etre classes en plusieurs categories, la couche physique elle-meme joue un role dans

43


certains d’entre eux et en environnement reel, certains autres vont encore apparaıtre qui avaientete totalement omis dans ces etudes.

3.7 Capacite theorique en fonction la topologie (grille, chaıne)

Certains travaux se sont attaches a evaluer la capacite theorique (en terme de bande passante)des reseaux ad hoc bases sur 802.11. [45] s’interesse au trafic dans des topologies regulieres (chaıneet grille de nœuds). Au travers de simulations, les auteurs montrent que 802.11 peine a offrir unebande passante optimale dans ce type de configuration. Le premier nœud de la chaıne cherche aenvoyer autant de paquets que possible (sa file d’attente est pleine en permanence). Les nœudssitues plus loin sur la chaıne ne peuvent envoyer des paquets que s’ils en ont prealablement recu.De plus, les premier nœuds (et en particulier le tout premier) ont moins de voisins avec qui entrer encontention que ceux situes plus loin. Il en resulte que les premiers nœuds utilisent une grande partde la bande passante pour envoyer des paquets que leurs successeurs ne pourront de toute facon pastous retransmettre du fait de la haute contention qu’ils recontrent. Dans ces conditions d’inegalitede contention et de trafics offerts, la couche MAC de 802.11 ne peut pas produire l’ordonnancementqui aurait donne le meilleur debit total.

Dans l’etude de la grille, le probleme et confirme. Il y apparaıt d’autre part que les schemas destrafics vont avoir eux aussi un grand impact sur les performances globales (si les flux sont eloignesles uns des autres, s’ils se croisent, etc.). A ce niveau, le type d’application va etre tres important,tout comme les protocoles de routage utilises.

Si les auteurs de [45] apportent une explication interessante sur les faibles debits obtenus dansdes configurations regulieres comme la chaıne ou la grille, nous proposons neanmoins dans le cha-pitre 4 notre propre evaluation et analyse de 802.11 dans une chaıne de mobiles. Ce travail quiaurait pu paraıtre redondant nous a en fait semble necessaire pour plusieurs raisons :

– Les mesures de base de 802.11 proposees dans [45] n’etaient pas coherentes avec celles quevous avions obtenues, et certains arguments avances nous semblaient en contradiction avecnos propres connaissances de NS2.

– Les outils avances d’analyse que nous avions mis en place permettaient une evaluation pluspoussee que celle proposee dans [45].

3.8 Equite

Plusieurs travaux ont mis en lumiere certains problemes d’equite dans l’acces au medium radioqui pouvaient survenir avec l’utilisation de 802.11. Le protocole MACAW [46], un des ancetresde 802.11 publie en 1994 (et qui avait d’ailleurs introduit l’utilisation des acquittements), avaitdeja remarque le probleme. Il proposait en particulier un mecanisme pour resoudre l’inegalite entremobiles qui provenait de l’utilisation du principe de Binary exponential Backoff dans l’ajustementde la fenetre de contention.

Dans [47], les auteurs presentent trois scenarios qui montrent une inegalite dans l’acces aumedium radio avec 802.11. Ils s’interessent a l’inegalite par nœud ainsi qu’a l’inegalite par flux.Ils expliquent que cette inegalite provient d’une asymetrie des zones de contention de mobiles. Siintuitivement on sent bien que cette asymetrie va gener fortement les mobiles connaissant le plus decontention, les auteurs ne donnent pas d’explications detaillees du dysfonctionnement de 802.11 facea cette asymetrie. En plus des problemes d’asymetrie mentionnes par [47], les travaux de Bensaou

44


et al. [38, 48] soulevent un probleme d’inegalite provenant de collisions repetees dans le cadre dereseaux ad hoc particuliers.

3.9 Conclusion et positionnement

Cet etat de l’art montre qu’un certain nombre de problemes ont ete mis en evidence avecl’utilisation de 802.11 dans les reseaux ad hoc. Certains travaux ont ete realises avant ma these (lesplus anciens vraiment specifiques a ce contexte datant de 1999, les autres ayant ete publies au coursde ma these, celle-ci ayant commence en 2000). Chacun de ces travaux souleve une problematiquebien particuliere mais aucun ne propose une analyse complete de 802.11 dans un cadre ad hoc.Enfin, la majorite de ces travaux se basent sur des resultats de simulation (hormis [41, 42] quirealisent quelques experimentations).

Dans cette these, nous avons essaye de mener un travail complet sur les performances de 802.11dans les reseaux ad hoc. Nous avons tente de degager les scenarios de base qui permettent delister les differents problemes souleves et d’y apporter des explications ciblees. Grace a ces simula-tions, certains des phenomenes observes dans la litterature ont ete retrouves, tandis que d’autrescaracteristiques ont ete degagees.

Enfin, contrairement aux travaux existants, un long travail d’experimentations de 802.11 dans uncontexte ad hoc a ete realise au cours de cette these. Ce travail a permis d’une part de connaıtre lesperformances reelles de 802.11, et d’autre part d’eclairer les problematiques sous un angle nouveau.

45

Premiere partie

Simulations logicielles de reseauxad-hoc

46

CHAPITRE

4 Simulations : introduction etscenarios de prise en main

4.1 Introduction

La communaute ad-hoc concentre une grande part de son attention sur les protocoles de routage.Cela etait d’autant plus vrai au moment du debut de ma these, alors que le groupe MANET del’IETF voyaient de nombreux nouveaux protocoles presentes, et qu’aucun d’entre eux n’etait assezstabilise pour envisager une normalisation. Pour developper, tester et valider ces algorithmes, leschercheurs se sont tres rapidement tournes vers les simulateurs. Ceci est en premier lieu du a desraisons pratiques. Il est peu commode de deployer un protocole sur un reseau reel compose d’uncertain nombre de machines (en particulier dans une configuration multi-sauts), de faire quelquesessais, puis de recommencer en changeant quelques parametres ou quelques morceaux de code. Deplus, peu de laboratoires disposaient du materiel necessaire (probleme de cout et de logistique ...et si l’on veut tester des scenarios presentant de la mobilite, de la ”main d’œuvre” est necessaire).

Lorsque nous avons commence ces travaux, notre laboratoire ne disposait d’aucun equipementradio. C’est donc tres logiquement que nous nous sommes nous aussi tournes vers la simulation.

4.2 Objectifs initiaux des simulations

Dans la seconde moitie des annees 90, avec l’elaboration de plusieurs normes pour les reseauxsans fils a portee limitee (visant des usages a l’echelle du bureau ou du batiment), un certainnombre de simulateurs ont ete developpes conjointement. Nous pouvons par exemple citer NetworkSimulator 2 [49] et son extension ”sans fil”, OPNET [50] ou encore GloMoSim [51] / Qualnet [52].

NS2 est certainement le simulateur de reseaux le plus utilise par la communaute ad-hoc. Il estgratuit et son code source est disponible ; autant d’avantages qui font qu’il est largement mis acontribution par les chercheurs desireux d’evaluer les performances des protocoles de routage qu’ilsdeveloppent. Lorsque nous avons commence a vouloir tester des heuristiques et divers algorithmesse rapportant aux reseaux ad-hoc, c’est donc logiquement vers NS2 que nous nous sommes tournes.L’installation ainsi que la prise en main du logiciel et des outils l’accompagnant a ete relativementaisee ; une fois la decision prise d’effectuer des simulations, nous avons donc pu rapidement nouslancer dans nos premieres simulations.

Dans un premier temps, et puisque que nous n’etions pas du tout familiers des reseaux sansfils, ces simulations ont consiste en des scenarios simples, permettant de se faire une idee descomportements de base des mobiles utilisant 802.11. Nous nous sommes par exemple interessesaux differents modeles de propagation disponibles ou aux debits et distances de communicationmaximum.

47

CHAPITRE 4. SIMULATIONS : INTRODUCTION ET SCENARIOS DE PRISE EN MAIN

Apres cette etape de prise en main, nous nous sommes interesses plus specifiquement a desscenarios typiques des reseaux ad-hoc (communication necessitants plusieurs ”sauts” et problemesd’interferences).

Dans de nombreux articles ([53, 54, 55]) dont l’objectif est de verifier que les protocoles deroutage arrivent bien a construire et maintenir les routes, les flux de donnees sont tres faibles (engeneral moins de 8 ou 10 paquets par seconde et par source, envoyes a une vitesse constante).Dans ces articles, les modeles de mobilite jouent egalement un role tres importants. Le RandomWaypoint, utilise pour la premiere fois dans [56] puis plus tard raffine dans [54] est certainement leplus utilise. Il consiste en :

– Le placement d’un certain nombre de mobiles (typiquement 50 a 100) dans une zone carreede laquelle ils ne peuvent sortir.

– L’affectation d’une position, d’une vitesse et d’une destination initiale a chaque mobile.– La selection aleatoire des emetteurs et de la destination de leurs paquets.– Le deroulement 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 aleatoirementapres un eventuel temps de pause.

Il faut noter que ce modele assez simple a ete sujet a critiques, notamment dans [57] ou l’instabiliteet la diminution progressive de la vitesse moyenne des mobiles en fonction du temps de simulationest mise en lumiere. Comme la destination et la vitesse sont choisis aleatoirement, des mobiles vontparfois choisir des destination lointaines et des vitesses tres lentes, et il leur faudra enormementde temps pour y arriver. Plus la simulation sera longue, plus le nombre de mobiles ”coinces” danscette situation va augmenter, et la proportion de mobiles ”lents” va croıtre de facon genante.

Quoiqu’il en soit, il est clair que les performances de chaque protocole de routage dependentbeaucoup des conditions d’utilisation (certains sont concus pour fonctionner dans des petits reseauxa forte mobilite, d’autres dans de grands reseaux, etc.). Pour pouvoir construire des modeles demobilite vraiment pertinents, il faudrait idealement pouvoir disposer d’informations sur le contextedans lequel le reseau ad hoc sera reellement deploye , et ceci est generalement impossible.

Mais contrairement a ce que l’on rencontre en general dans la litterature, nous avons cherchea voir ce qui se produisait quand le reseau arrivait a saturation. Nous ne cherchions pas a testerles algorithmes de tel ou tel protocole de routage, nous voulions plutot savoir ce qui se passerait(en terme de debit, de connectivite et de delais) quand des flux tres importants sont presentsentres certains mobiles dans un reseau ad-hoc. Ceci etait motive par l’idee que dans de nombreusescirconstances, le trafic s’effectue plutot par rafale (comme par exemple la navigation web, le transfertde fichiers ou meme la consultation d’e-mails). Dans nos scenarios, nous avons donc en general utilisedes flux cherchant a occuper completement la bande passante. Ces conditions de saturation sontun element important de nos travaux et les differencie d’une grande majorite de ceux effectuesprecedemment et qui n’utilisaient que des flux tres peu gourmands.

4.3 Presentation de Network Simulator 2

NS2 est un simulateur a evenements discrets developpe dans un but de recherche [58]. Il fournitun environnement assez detaille permettant entre autre de realiser des simulations d’IP, TCP, duroutage et des protocoles multicast aussi bien sur des liens filaires que sans fil.

Network simulator 2 a ete originellement developpe en tant que variante du ”REAL networksimulator” en 1989, et a considerablement evolue au cours des annees. En 1995, NS2 etait developpe

48


par le projet VINT. Actuellement, son developpement est supporte par le DARPA a travers SAMANet par la NSF a travers CONSER, tout en incluant de nombreuses contributions exterieures, commeen particulier les codes pour les reseaux sans fils des projets Daedalus de l’UCB et Monarch de laCMU et de Sun Microsystems.

NS2 est ecrit en C++ et en oTCL, et il est fourni avec divers outils d’analyse complementaireseux-memes ecrits en C/C++ ou TCL/Tk.

NS2 implemente la version de 1997 de la norme 802.11. A ce titre, le debit maximum possibleest de 2 Mbit/s. Il faut noter egalement que ce logiciel est developpe, corrige et etendu au fur eta mesure de l’apparition de nouveaux besoins (ou de la decouverte d’erreurs). Ainsi, au cours duderoulement de cette these, plusieurs versions se sont succedees, apportant leurs lots de correctionset ameliorations diverses.

Compte tenu de nos objectifs, nous avons bien sur essentiellement mis a contribution la partieIP/UDP/TCP en environnement sans fil. NS permet de positionner sur un plan virtuel des mobilesequipes d’emetteurs radio, et il gere la mobilite de ces nœuds dans le temps. Pour qu’un paquetemis sur une interface sans fil sous NS2 soit recu, il faut qu’il arrive au destinataire avec un niveaude signal superieur a un certain seuil. Ce seuil est par defaut de 3.652× 10−10 W, et nous l’avonslaisse a cette valeur pour toutes les simulations qui seront presentees par la suite.

4.3.1 Les differents modeles de propagation radio sous NS2

NS2 permet egalement de choisir parmi les modeles de propagation suivants, qui influeront enparticulier sur la maniere dont seront attenues les signaux en fonction de la distance :

– Free space model : Ce modele considere le cas ideal ou il y a un seul chemin de propagationentre l’emetteur et le recepteur et qu’il est en vue directe. H.T. Friis a presente dans [59]l’equation suivante pour calculer la puissance du signal recu en environnement libre a unedistance d de l’emetteur.

Pr(d) =PtGtGrλ

2

(4π)2d2L(4.1)

ou Pt est la puissance d’emission, Gt et Gr les gains respectifs des antennes de l’emetteuret du recepteur. L (avec L ≥ 1) est la perte du systeme, et λ est la longueur d’onde. Dansnos simulations avec NS, nous prendrons toujours Gt = Gr = 1 et L = 1. Ce modele depropagation represente les zones de communication comme un cercle autour de l’emetteur.Si un recepteur est dans ce cercle il recoit tous les paquets, s’il est en dehors il n’en recoitaucun.

– Two-ray ground reflection model : En environnement reel, il est en fait peu probableque le seul chemin de propagation soit le chemin direct. Le modele two-ray ground consideredonc a la fois le chemin direct et une reflexion sur le sol. Comme il est montre dans [60], cemodele donne des resultats plus justes que le modele de propagation en espace libre quandla distance est assez grande. La puissance recue a une distance d est calculee de la manieresuivante :

Pr(d) =PtGtGrht

2hr2

d4L(4.2)

ou ht et hr sont les hauteurs des antennes de transmission et de reception. Notez que l’equationoriginelle dans [60] considere que L = 1. Afin que NS soit coherent avec le modele de propa-gation en espace libre, L a ete ajoute a l’equation.

49


Environnement βEn exterieur Espace libre 2

Zone urbaine obstruee 2.7 a 5En interieur En ligne de vue 1.6 a 1.8

Obstrue 4 a 6

Tab. 4.1 – Quelques valeurs typiques pour l’exposant d’attenuation β

L’equation precedente presente une decroissance de la puissance recue en fonction de la dis-tance plus rapide que l’equation (4.1). Cependant, pour des distances courtes, le modele adeux rayons ne donne pas de bons resultats (en raison d’oscillations causees par la combinai-son constructive et destructive des deux rayons). Le modele de propagation en espace libreest donc utilise a la place de celui-ci quand d est suffisamment petit.Pour ce modele, nous avons donc besoin de calculer une distance seuil dc. Quand d < dc,l’equation (4.1) est utilisee, et quand d > dc, on prend l’equation (4.2). A la distance seuil,les equations (4.1) et (4.2) doivent donner les memes resultats ; la distance seuil dc peut doncetre calculee de la maniere suivante :

dc =4πhthr

λ(4.3)

– Shadowing model : Les modeles de propagation en espace libre ou utilisant deux rayonscalculent de maniere deterministe la puissance recue en fonction de la distance. Ils represententtous deux la zone de communication comme un cercle ideal. Dans la realite, la puissance recuea une certaine distance varie de maniere aleatoire, a cause des effets de propagation par deschemins multiples. En fait, les deux modeles precedents calculent la puissance moyenne recuea une distance d. Le shadowing model est un modele de propagation plus generaliste presentedans [60] et implante dans NS2.Le modele ”shadowing” est compose de deux parties. La premiere est le modele d’attenuationen fonction de la distance, qui calcule la puissance moyenne recue a une distance d, noteePr(d). Il utilise une distance courte comme reference, notee d0. Pr(d) est calculee relativementa Pr(d0) de la maniere suivante :

Pr(d0)Pr(d)

=(

d

d0

)β

(4.4)

β est appele l’exposant d’attenuation en fonction de la distance, et est generalement determinede facon empirique par des mesures en environnement reel. D’apres l’equation (4.1), on saitqu’en espace libre β = 2. La table 4.1 donne quelques valeurs typiques de β. Les grandesvaleurs correspondent a une obstruction plus forte et donc a une decroissance plus rapide dela puissance recue en fonction de la distance. Pr(d0) peut etre calculee a partir de l’equation(4.1), en prenant par exemple d0 = 1 metre.L’attenuation en fonction de la distance est souvent mesuree en dB. A partir de l’equation(4.4) nous avons [

Pr(d)Pr(d0)

]dB

= −10β log(

d

d0

)(4.5)

50


Environnement σdB (dB)En exterieur 4 a 12Bureaux, separations legere 7Bureaux, murs 9.6Usine, en ligne de vue 3 a 6Usine, obstruee 6.8

Tab. 4.2 – Quelques valeurs typiques pour la deviation du shadowing σdB

La seconde partie du modele shadowing reflete les variations de la puissance recue a unedistance donnee. C’est une variable suivant une loi log-normale, c’est a dire dont la distributionmesuree en dB est gaussienne. L’ensemble du modele shadowing est represente par[

Pr(d)Pr(d0)

]dB

= −10β log(

d

d0

)+ XdB (4.6)

ou XdB est la variable aleatoire gaussienne dont la moyenne est zero et l’ecart type σdB. σdB

est appele shadowing deviation, et est egalement obtenue par des mesures en environnementreel. La table 4.2 donne quelques valeurs typiques pour σdB. L’equation (4.6) est aussi connuesous le nom de log-normal shadowing model.Le shadowing model etend le cercle ideal de communication a un modele statistique plus riche ;les nœuds ne peuvent communiquer qu’avec une certaine probabilite lorsqu’ils sont vers lalimite de portee.

4.3.2 La gestion des interferences

Le terme ”interferences” est souvent utilise de facon generique, et recouvre en fait plusieursphenomenes qu’il est important de differencier. Avant tout, les conditions suivantes doivent etreremplies pour qu’un paquet puisse etre recu :

– La puissance du signal recu doit depasser un certain seuil (seuil de communication).– Le rapport signal sur bruit ambiant doit etre suffisamment grand (le signal doit etre clairement

identifie, et non noye dans le bruit).Il existe un seuil de detection de porteuse. Si la puissance du signal est comprise entre ce seuil

et le seuil de communication, alors le message n’est pas compris mais l’activite sur le canal estneanmoins detectee. Si l’on utilise le modele two-ray ground (ou le modele free-space), ces seuilsdefinissent donc deux zones autour d’un nœud. Si le recepteur est place au centre de la figure 4.1,alors un emetteur place dans la zone interne (zone de communication) pourra lui envoyer des mes-sages qui seront compris (en l’absence d’autres interferences). Si l’emetteur est place dans la zoneexterne (zone de detection de porteuse), la communication ne sera pas possible mais l’autre mobilesera informe a chaque fois que l’emetteur accedera au canal. Si l’on utilise le modele shadowing,les deux zones sont egalement definies, mais leurs frontieres sont ”floues” du fait du caractereprobabiliste du modele. 802.11 impose qu’un mobile qui veut emettre doit d’abord s’assurerqu’aucune autre communication n’est en cours dans son voisinage. Si une telle communication esten cours, et si l’emetteur est suffisamment proche (c’est a dire dans la zone de communication)du mobile qui voudrait lui aussi emettre, alors ce dernier a recu l’en-tete du message et sait donc(par l’intermediaire de son Network Allocation Vector) pour combien de temps le canal doit encoreetre occupe. Le nœud qui voulait emettre va donc attendre. Par contre, si le mobile qui veut

51


Zone de communication

Zone de détection de porteuse

Fig. 4.1 – Portee de communication et de detection de porteuse

aussi emettre est plus loin (dans la zone de detection de porteuse de l’emetteur) l’en-tete n’a paspu etre comprise. Il est impossible dans ce cas de prevoir a l’avance quand on aura a nouveaule droit d’emettre, il faut attendre que l’activite sur le canal disparaisse. Dans ces contextes,les differents nœuds se genent les uns les autres, et cela se traduit par un partage du canal entre eux.

Une fois ces precisions donnees, les differents facteurs a prendre en compte pour les interferencessont :

– L’attenuation du signal en fonction de la distance et de l’environnement . C’est la prise encompte uniquement de la distance dans le calcul d’attenuation qui donne sa forme circulairea la zone de couverture de la figure 4.1. C’est ce que fait NS2 (avec eventuellement un facteuraleatoire supplementaire dans le modele shadowing).

– Le bruit ambiant est normalement la somme de tous les bruits percus au niveau durecepteur. Ce bruit de fond provient de l’environnement (passage de vehicules motorises,appareils bruiteurs divers, ...), mais aussi des autres mobiles du reseau. Sous NS2 il n’y a pasde bruit de fond provenant de l’environnement, le signal recu de l’emetteur est simplementcompare a tour de role a chacune des autres sources du reseau actives a ce moment la. Ceci estune limitation de NS2, car suivant les conditions, il se peut qu’aucune de ces sources de bruitne soit suffisante pour gener la communication de maniere independante, mais que leur sommele soit. D’un maniere generale, NS calcule donc une approximation du bruit qui est inferieurea ce qu’elle devrait etre. Il faut bien garder a l’esprit que si des problemes d’interferences ap-paraissent dans certains scenarios, l’impact de ces interferences en environnement reel seraitencore superieur.

4.4 Traitements des resultats et outils d’analyse

NS2 ecrit les resultats de ses simulations dans un fichier texte ou chaque ligne correspond aun evenement qui s’est produit a un niveau ou a un autre de la pile protocolaire. Il est possiblede configurer NS2 de telle sorte qu’il ne garde une trace que de certains types d’evenements (parexemple tout ce qui concerne le routage, mais pas ce qui concerne la couche MAC). Ceci est enparticulier utilise pour accelerer la simulation et reduire la taille du fichier.

Ce fichier texte peut porter en lui-meme enormement d’informations. Mais pour extraire etrepresenter de maniere synthetique ces informations, il faut souvent appliquer de nombreux traite-

52


O 2

1 3

Fig. 4.2 – Scenario d’exemple pour le chronogramme

ments a ce fichier. Par exemple, si l’on veut calculer un debit sur un lien, il faut compter le nombrede paquets transmis durant une certaine periode entre certains nœuds et tenir compte de leur taille.Comme l’ensemble des evenements qui se sont produits se trouvent dans ce fichier et qu’ils ne sontclasses que par ordre chronologique, ceci peut se reveler pour le moins laborieux.

Ainsi, pour calculer les debits, on prefere plutot agir au niveau du script TCL decrivant lescenario. Certains objets utilises dans les simulations sont capables de comptabiliser les paquets oules octets qui les traversent (comme ceux qui servent de recepteurs pour les flux TCP par exemple).Ces informations peuvent etre recuperees au niveau du script TCL, qui se charge alors de les ecriredans un fichier.

Bien que ces deux techniques permettent deja de recuperer enormement d’informations, cecin’a pas toujours ete suffisant pour nos besoins. Comme nous cherchons a savoir ce qui se passeaux niveaux MAC et physique, nous avions besoin en particulier de plus de details que la simpleconnaissance de l’echec ou de la reussite de la transmission d’un paquet au niveau MAC. Nous avonsdonc ajoute du code dans NS2 qui nous permet, pour chaque nœud, de connaitre les moments ouil est en train :

– D’emettre sur le canal (toutes les emissions, les RTS/CTS et les acquittements seront doncvisibles separements).

– De decrementer son backoff (avec des indications lorsque cette decrementation est suspenduepuis 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 stockees dans des fichiers separes du fichier de log principal de NS2. La visualisation se faitgrace a un programme externe, qui represente graphiquement les informations sous la forme d’unchronogramme.

Pour donner un exemple, nous considerons le scenario presente sur la figure 4.2. Il y a deuxcouples d’emetteur / recepteur situes juste a cote les uns des autres. Les nœuds 0 et 2 sont lesemetteurs, 1 et 3 sont les recepteurs. Les nœuds 0 et 2 cherchent a envoyer autant de paquets UDPde 1000 octets que possible.

Le chronogramme est presente sur la figure 4.3. Le temps est represente de gauche a droite, sonechelle est indiquee en bas a gauche et a droite. Sur cette capture d’ecran, nous avons zoome defacon a afficher uniquement ce qui se passait entre les secondes 11.023 et 11.04 de la simulation. Letemps indique en bas au milieu correspond a la position du curseur de la souris (invisible sur cettecapture d’ecran) ; il est souvent utile pour ”lire” directement les temps approximatifs des evenements

53


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

dessines. Les tirages d’un nouveau backoff ainsi que la fin de leur decrementation sont signales sur legraphique par des petites barres verticales au bout des rectangles. Une barre en debut d’un rectanglede backoff indique qu’il vient d’etre tire au hasard et que sa decrementation commence, une barre ala fin indique qu’il a ete decremente jusqu’a zero et que l’emission va pouvoir commencer. L’absencede barre verticale indique que la decrementation a ete temporairement stoppee ou qu’elle reprend.

Les douze fichiers de trace sont dessines les uns en dessous des autres. Ici, on peut lire lederoulement suivant de la simulation :

– Le nœud 2 est en train d’emettre (1). Le nœud 3 est en train de recevoir (ceci n’apparaıt pasdirectement sur la figure, mais la presence d’un acquittement permettra ensuite de savoir sicette communication s’est deroulee correctement), et les nœuds 0 et 1 savent qu’ils ne doiventpas emettre (leur NAV leur indique que le canal est occupe).

– Le nœud 3 a fini de recevoir le paquet de donnees. Il retourne un acquittement (2). Les NAVdes nœuds 0 et 1 leur indiquent toujours qu’ils ne doivent pas emettre

– En (3), le canal devient libre. Les nœuds 0 et 2 veulent tous les deux emettre. Cette fois-la,le nœud 2 a tire un backoff tres petit, des qu’il a fini de le decrementer, il emet un RTS(4). Immediatement, le nœud 0 detecte l’activite sur le canal et arrete de decrementer sonbackoff. Le RTS contenant la duree de la transmission de donnees qu’il annonce, cela permetaux nœuds 0 et 1 de positionner leur NAV sitot le RTS recu.

– Le nœud 3 repond au RTS par un CTS (5), puis le nœud 2 y repond par l’envoi de sesdonnees, qui sont acquittees ... et ainsi de suite

Cet outil qui vient d’etre presente est simple d’utilisation. Grace a lui nous serons par la suiteen mesure de realiser une evaluation fine des scenarios simules.

4.5 Prise en mains et premieres simulations

54


Fig. 4.4 – Description de l’experience desdeux mobiles s’eloignant

X Graph

out0-sc00-1-rts.tr

Y x 106

X

0.0000

0.1000

0.2000

0.3000

0.4000

0.5000

0.6000

0.7000

0.8000

0.9000

1.0000

1.1000

1.2000

1.3000

1.4000

1.5000

1.6000

1.7000

0.0000 20.0000 40.0000 60.0000 80.0000 100.0000

Fig. 4.5 – Debits dans l’experience des deuxmobiles s’eloignant (modele free-space). Enabscisse : distance en dizaines de metres, enordonnee : debit en bits par seconde

0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

1.8e+06

0 100 200 300 400 500 600 700

debi

t en

bits

par

sec

onde

distance en metres

modele two-ray ground sans RTS/CTSmodele two-ray ground avec RTS/CTS

Fig. 4.6 – Debits en fonction de la distance avecle modele two-ray ground.

0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

1.8e+06

0 100 200 300 400 500 600 700

debi

t en

bits

par

sec

onde

distance en metres

modele shadowing sans RTS/CTSmodele shadowing avec RTS/CTS

Fig. 4.7 – Debit en fonction de la distance avecle modele shadowing.

55


Fig. 4.8 – Modele shadowing, chronogramme a 100 m

Fig. 4.9 – Modele shadowing, chronogramme a 500 m (sans RTS/CTS)

4.5.1 Portee de communication et debit

Les toutes premieres simulations realisees ont pour but d’observer la portee et le debit del’implementation de 802.11 disponible sous NS2. Les scenarios consistent a placer un emetteur etun recepteur juste a cote l’un de l’autre. L’emetteur envoie un flux a debit constant de paquets UDPde 1000 octets (il en envoie suffisamment pour saturer le canal). Progressivement, on deplace lerecepteur (figure 4.4). Nous effectuons cette simulation avec chacun des modeles de propagation pro-poses, en utilisant a chaque fois AODV comme protocole de routage. Ces simulations nous serventa comparer les modeles de propagation disponibles, et nous servent d’etalon pour les simulationsplus complexes qui vont suivre (nous rappelons que dans toutes ces simulations, le debit physiquesimule est de 2 Mbit/s, puisque c’est celui supporte par defaut par NS2). A chaque fois, nous avonsegalement effectue une simulation avec les RTS/CTS et une autre sans. Le debit maximum observesans utiliser les RTS/CTS est de 1.6 Mbit/s, et descend a environ 1.4 Mbit/s lorsqu’on les utilise.

Modele free-space. Ce modele de propagation est le plus simple propose par NS2. Le debit obtenuen fonction de la distance entre l’emetteur et le recepteur est presente sur la figure 4.5. D’apres cemodele, la puissance recue diminue de maniere continue avec la distance. Comme la reception d’unpaquet n’est possible que si la puissance est superieure a un certain seuil, nous obtenons logiquementune courbe ou le debit est maximum jusqu’a une certaine distance (600 m) puis ensuite nul. Leseuil de communication est la valeur par defaut de NS2 (3.652.1010 W). Dans la pratique, NS2est passablement bugge , et au dela de 600 m, dans sa version 2.26, son comportement devientimprevisible (debit non nul a tres grande distance, variation au cours du temps a une distance fixe,crash pur et simple de NS2, ...).

Modele two-ray ground. Ce modele de propagation est celui qui est generalement utilise par lacommunaute ad-hoc lorsqu’il s’agit de developper et tester des protocoles de routage. On observeles resultats presentes sur la figure 4.6. On remarque que jusqu’a une certaine distance (250 metres)le debit est maximum, puis qu’au-dela les communications ne sont plus possibles du tout. Ceci esttout a fait normal compte tenu du modele de propagation utilise. On remarque aussi l’impact sur ledebit de l’utilisation du mecanisme RTS/CTS. Dans ce scenario ou l’on obtient un debit maximum

56


de 1.6 Mbit/s en leur absence, l’utilisation des RTS/CTS provoque une baisse du debit utile de12% environ a 1.4 Mbit/s.

Modele shadowing. Ce modele est plus complexe que les precedents, il est probabiliste et utiliseaussi des informations recoltees sur le terrain. Le debit que l’on obtient avec lui en fonction dela distance est presente sur la figure 4.7. Le scenario est le meme que precedemment (figure 4.4)et les parametres du modele shadowing sont ceux par defaut ( β = 2.0, σdB = 4.0, d0 = 1 metre). Ce modele de propagation donne, a partir d’une certaine distance, une probabilite de plus enplus importante pour qu’un paquet soit perdu (signal trop attenue). Dans ce scenario, cela cetraduit par une diminution progressive du debit, qui commence a baisser a partir de 250 metresenviron, mais qui ne devient nul qu’au dela de 600 metres. Avec le modele shadowing, tout commeavec le freespace, la portee de communication est tres grande, nettement plus qu’avec le two-rayground. A courte distance, l’impact des RTS/CTS est le meme qu’avec le modele two-ray ground.On remarque cependant que lorsque l’on utilise les RTS/CTS, lorsque la distance augmente, ledebit baisse beaucoup plus vite que quand on ne les utilise pas. Ceci est assez logique, puisque qu’ilsuffit que l’un des paquets de controle soit perdu pour que la transmission echoue. Il faut egalementnoter que nous avons rencontre de nombreux ”plantages” de NS2 en utilisant ce modele (sur lafigure 4.7, l’experience sans RTS a en fait ete arretee par un plantage du simulateur, qui n’a jamaisreussi a depasser ce stade.

Sur les figures 4.8 et 4.9, on peut observer la distribution assez uniforme des pertes de paquetsengendrees par le modele shadowing. Sur la figure 4.8, les nœuds ne sont espaces que d’une dizainede metres. Il n’y a aucune perte de paquets, les paquets se suivent donc sans interruption sur lecanal, et un acquittement est envoye pour chacun d’entre eux. Sur la figure 4.9, qui correspond aune periode ou les deux nœuds sont deja eloignes de 500 metres, on remarque par contre qu’uncertain nombre de paquets de donnees ne sont pas acquittes, et meme que parfois les paquets dedonnees ne sont plus envoyes (lorsque les acquittements eux-memes sont perdus, au bout d’uncertain nombre d’essais, la couche MAC notifie l’erreur a la couche superieure, et un systeme detimer va empecher une tentative immediate de retransmission). Sur les chronogrammes presentes,c’est surtout la distribution dans les temps des acquittements manquants qui permet de bienmettre en evidence la repartition assez homogene des erreurs de transmission avec le modeleshadowing

Du fait que le modele two-ray ground est utilise en quasi exclusivite dans les simulations realiseesdans la communaute ad-hoc, nous l’avons retenu pour la suite de nos travaux. Sauf mentioncontraire, c’est donc ce modele de propagation qui a ete utilise pour les simulations qui serontpresentees dans les paragraphes suivants.

4.5.2 Interferences

La seconde serie de simulations avait pour objectif d’observer les interferences entre deuxemetteurs. Pour ce faire, nous avons utilise quatre nœuds dans notre scenario, repartis en deuxpaires. Au depart, tous les mobiles sont tres proches les uns des autres, puis les deux paires vontprogressivement s’eloigner. Dans chaque paire, l’emetteur et le recepteur restent par contre tresproches (quelques metres). Le trafic est un flux de paquets UDP de 1000 octets, envoyes aussi viteque possible (on cherche a saturer la bande passante).

57


200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

1.8e+06

0 100 200 300 400 500 600 700

debi

t en

bits

par

sec

onde

s

distance en metres

paire de gauchepaire de droite

Fig. 4.10 – Debit pour les deux pairess’eloignant (sans RTS/CTS)

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

0 100 200 300 400 500 600 700

debi

t en

bits

par

sec

onde

s

distance en metres

paire de gauchepaire de droite

Fig. 4.11 – Debit pour les deux pairess’eloignant (avec RTS/CTS)

Fig. 4.12 – Les deux pairess’entendent directement

Fig. 4.13 – Les deux paires nese comprennent plus mais sedetectent

Fig. 4.14 – Les deux pairessont totalement idependantes

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

Fig. 4.16 – Chronogramme quand les paires sont en zone de detection de porteuse

58


Les debits obtenus sur chacune des paires en fonction de la distance sont presentes sur lesfigures 4.10 (sans RTS/CTS) et 4.11 (avec RTS/CTS). On remarque en premier lieu que l’utilisationou non du mecanisme de RTS/CTS ne change pratiquement rien a l’allure generale de la courbe.Les RTS/CTS ne vont influer ici que sur le debit utile, qui est legerement inferieur lorsqu’on lesutilise. On remarque ensuite la presence tres nette de trois parties distinctes sur ces courbes.

– De 0 a 250 metres, tous les mobiles sont a portee directe de communication les uns desautres (figure 4.12). Le medium radio est partage equitablement. Chaque paquet emis estpercu par les trois autres mobiles qui peuvent en particulier mettre a jour leur NAV.

– De 250 a 550 metres, les deux paires sont trop eloignees l’une de l’autre pour que le contenude leurs paquets soient compris (figure 4.13). Le NAV ne peut plus etre mis a jour. Par contre,le mecanisme de detection de porteuse est encore capable de determiner quand des paquetssont en cours de transmission dans l’autre paire. Cela ce traduit par un partage equitabledu medium, mais avec une plus grande instabilite dans cette repartition. Cette instabilite estliee aux EIFS qui sont utilises par les mobiles quand ils detectent de l’activite sur le canal.Dans cette configuration, ils sont en particulier declenches dans une paire au moment ou lecanal devient libre apres l’emission d’un acquittement dans l’autre paire. Pour emettre sonprochain paquet, cette paire va devoir attendre un temps correspondant a EIFS+backoff, alorsque l’autre se contente de DIFS+backoff. DIFS+backoff etant statistiquement plus petit, il ya une forte probabilite qu’un mobile emette un certain nombre de paquets avant que l’autre yarrive et que la situation s’inverse. Ceci est particulierement visible sur les figures 4.15 et 4.16.Sur la figure 4.15 on voit que les deux nœuds accedent au medium avec une alternance tresrapide (lorsque les emetteurs sont a portee de communication, un nœud n’emet en general pasplus de deux ou trois paquets consecutifs avant de laisser la main). Sur la figure 4.16 ou lesemetteurs sont par contre en zone de detection de porteuse, lorsqu’un nœud prend la main,il la garde parfois pour un envoi comprenant jusqu’a une douzaine de paquets consecutifs.

– Au dela de 550 metres, les deux paires sont totalement independantes (figure 4.14), chacundes emetteurs occupe la totalite de la bande passante et transmet en continu.

Dans la phase de 200 a 550 metres, les RTS/CTS n’ont aucun effet en dehors de la diminutiondu debit utile que l’on avait deja observe dans la premiere simulation. Ceci est tout a fait normal,puisque l’on se place dans une configuration (entre 250 et 550 metres) ou les paquets RTS et CTS nepeuvent pas plus etre compris que les paquets de donnees (les signaux sont recus avec une puissancetrop faible, les deux emetteurs sont dans la zone de detection de porteuse l’un de l’autre).

59

CHAPITRE

5 Scenarios ”avances”

5.1 Introduction et objectifs

Nous avons etudie jusqu’a present des configurations basiques, avec seulement deux mobilesemetteurs. Les resultats obtenus vont nous servir maintenant a mieux comprendre les mecanismeset les interactions qui se deroulent dans des scenarios plus complexes. Ces scenarios vont desormaiscompter plus de mobiles, et les configurations vont etre plus caracteristiques des reseaux ad hoc.Nous nous interesserons en premier lieu a la structure en chaıne, qui est a la base meme desreseaux radio multi-sauts. Nous considererons ensuite des configurations ou certains mobiles sontplus affectes par les interferences que d’autres. Et nous terminerons par une chaıne perturbee demaniere inegale.

5.2 Trois paires

Le scenario que nous presentons maintenant a pour but de mettre en evidence certains problemesd’equite dans l’acces au medium avec 802.11. Nous utilisons six mobiles que nous placons commeindique sur la figure 5.1 : ils sont tous initialement tres proches les uns des autres. Les mobilessont repartis en trois paires d’emetteur / recepteur. Dans chaque paire, l’emetteur essaie d’envoyerautant de paquets UDP de 1000 octets que possible a son recepteur (la file d’attente d’emission estcontinuellement pleine). La vitesse de transmission est de 2 Mbit/s et le mecanisme RTS/CTS estutilise.

L’idee du scenario est de produire une situation typique des reseaux ad hoc ou certains mobilessont plus soumis a des interferences que d’autres. Pour ce faire, au cours de la simulation, nousdeplacons progressivement les paires exterieures a la vitesse constante de 25 metres par seconde.Au fur et a mesure du deroulement du scenario, les mobiles vont tout d’abord tous interferer les

Fig. 5.1 – Position initiale des 3 pairesFig. 5.2 – Interferences non symetriques entreles 3 paires

60

CHAPITRE 5. SCENARIOS ”AVANCES”

uns avec les autres, puis les paires exterieures vont continuer a interferer avec la paire centrale maissans se gener entre elles (figure 5.2), et enfin les trois paires vont etre suffisamment eloignees lesunes des autres pour acceder au canal en meme temps sans probleme. Nous obtenons les debitspresentes sur la figure 5.3, ils peuvent etre interpretes comme suit :

– De 0 a 5 secondes (les paires exterieures sont entre 0 et 125 metres de la paire centrale),les trois paires sont en contact ”direct” (elles sont a portee de communication les unes desautres). Meme si le reseau est sature, comme les debits demandes sont identiques, la bandepassante est partagee de maniere equitable (le debit utile maximal de 1.6 Mbit/s environdivise par 3).

– De 5 a 11 secondes (les paires exterieures sont desormais entre 125 et 275 metres de la pairecentrale, mais surtout entre 250 et 550 metres l’une de l’autre) les communications (et donc lamise a jour du NAV grace aux RTS/CTS) n’est plus possible entre les paires exterieures, maiscomme elles detectent reciproquement leurs porteuses, elle savent que le canal est utilise et lepartage encore de maniere assez equitable (environ un tiers chacune). Le canal est cependantun peu moins bien partage. La raison se trouve dans le phenomene decrit dans la simulationdes deux paires, au moment ou elles sont dans les zones de detection de porteuse l’une del’autre. Le declenchement des EIFS est a la base du phenomene d’instabilite.

– De 11 a 22 secondes (les paires exterieures sont entre 275 et 550 metres de la paire centrale)la paire centrale est dans une situation differente des deux autres paires. Elle detecte laporteuse des deux paires exterieures, alors que ces dernieres ne detectent chacune que cellede la paire centrale. Dans ce contexte asymetrique, le mecanisme d’acces au canal presenteune faiblesse tres nette. Des que la paire centrale perd l’acces au canal, elle a enormementde difficultes a le recuperer. Le debit de la paire centrale est quasiment nul durant cetteperiode, alors que celui des paires exterieures atteint le maximum possible. Ceci s’expliquede la facon suivante : la paire centrale ne peut emettre que lorsque les deux autres sontsilencieuses pendant une periode suffisante. Mais les deux autres ne se genent pas entreelles, et il n’y a donc aucune raison pour qu’elles soient synchronisees. De ce fait, il n’y apas de raison pour que leurs periodes de backoff coıncident. De plus, plus la charge utile despaquets est importante, plus petites sont les chances pour que les backoff des paires exterieurescoıncident. La figure 5.5 montre le decalage existant entre les periodes de silence des deuxpaires exterieures. Le phenomene est encore amplifie par le mecanisme EIFS de 802.11. Lafigure 5.4 presente ce qui se passe d’une facon simplifiee (pour des raisons de lisibilite l’echellede temps n’est pas respectee entre les differents elements). On peut tout d’abord noter quememe si dans la realite les differents mobiles ne commenceraient pas forcement de manieresynchronisee, le probleme apparaıtrait neanmoins au bout de quelques instants. En premierlieu, le canal doit etre libre pendant une periode DIFS avant qu’un nœud decide d’essayerde transmettre (figure 5.4a). Les nœuds attendent ensuite pendant une periode de backoffaleatoire (figure 5.4b). Comme l’emetteur de la premiere paire a termine de decrementerson backoff et que le canal est toujours libre, il commence a transmettre, brouillant ainsi laseconde paire qui entre alors en periode de defering jusqu’a ce que le canal soit a nouveaulibre. Comme la troisieme paire n’est pas genee, elle peut terminer la decrementation de sonbackoff et commencer elle aussi a emettre (figure 5.4c). A cause de l’activite sur le canal venantde la troisieme paire, la deuxieme doit rester plus longtemps en defering. Et quand le canalredevient enfin libre, elle doit encore attendre pendant une periode EIFS (qui est environ 6

61


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

5 10 15 20 25 30

debi

t en

bits

par

sec

onde

temps en secondes

debit dans la paire de gauchedebit dans la paire centrale

debit dans la paire de droite

Fig. 5.3 – Debit en fonction du temps dans lescenario des trois paires

temps

DIFS

temps

DIFS

temps

DIFS

temps

DIFS

temps

DIFS

temps

DIFS Backoff

Backoff

Backoff

temps

DIFS

temps

DIFS

temps

DIFS Backoff

Backoff

Backoff

DATA

DATA

Defer

temps

DIFS

temps

DIFS

temps

DIFS Backoff

Backoff

Backoff

DATA

DATA

DIFS

DIFS

Defer

Backoff

Backoff

EIFS

DATA

Defer

temps

DIFS

temps

DIFS

temps

DIFS Backoff

Backoff

Backoff

DATA

DATA

DIFS

DIFS

Defer EIFS

(a)

(b)

(c)

(d)

(e)

Fig. 5.4 – Detail du probleme d’acces aumedium avec l’EIFS

fois plus longue qu’un DIFS). Entre temps, les deux autres paires ont deja recommence unnouveau cycle (figure 5.4d) et tout recommence ... (figure 5.4e).

– Au dela de 22 secondes Les trois paires sont suffisamment eloignees les unes des autres.Elles ne detectent plus les porteuses des autres et peuvent emettre en meme temps au debitmaximum.

Il faut noter que pour la periode problematique, l’amplification des problemes par le mecanismedes EIFS peut etre quantifiee. Nous avons effectue une serie de simulations en placant les troispaires dans la position correspondant a la periode des secondes 11 a 22 de la figure 5.3. Pourcertaines mesures, nous avons utilise des EIFS ayant leur duree normale (364 µs) et dans d’autresdes EIFS ayant la meme duree que les DIFS (50 µs). Nous avons egalement effectue ces simulationsan activant ou non les RTS/CTS. La figure 5.6 presente ces resultats :

Fig. 5.5 – Details de la simulation entre les secondes 11 et 22

62


0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

700 800 900 1000 1100 1200 1300 1400

Cen

tral

pai

r tim

e-sh

are

(%)

Packet size (bytes)

2 Mb/s without RTS/CTS: DIFS vs. DIFS2 Mb/s with RTS/CTS: DIFS vs. DIFS

2 Mb/s without RTS/CTS: EIFS vs. DIFS2 Mb/s with RTS/CTS: EIFS vs. DIFS

Fig. 5.6 – Proportion d’acces au canal pour la paire centrale en fonction de la taille des paquets etde la duree de l’EIFS (periode des secondes 11 a 22).

– Avec les EIFS ”normaux” (364µs), la paire centrale obtient aux alentours de 1% de la bandepassante. Si les nœuds utilisent les RTS/CTS, la paire centrale obtient un debit encorelegerement inferieur.

– Avec des EIFS ”courts” (50µs, soit la meme duree que les DIFS), la paire centrale obtiententre 5 et 6 fois plus de bande passante. Mais avec 5 ou 6% de la bande passante totale, ellereste encore tres largement defavorisee vis-a-vis des paires exterieures. Cette limitation vientde l’effet de la non synchronisation des paires exterieurs dont nous avons parle precedemment.La encore, les RTS/CTS ont un impact negatif pour le partage equitable, lorsqu’ils sontactives, la paire centrale a plus de difficultes a acceder au canal que lorsqu’ils ne le sontpas. On remarque enfin que les chances d’acces au canal de la paire centrale diminuent avecl’augmentation de la taille des paquets. Plus les paquets sont longs, plus la proportion dutemps ou le canal est occupe (transmission de donnees ou de paquets de controle) par rapportau temps ou le canal est libre (periodes de backoff, DIFS, EIFS) diminue. Par consequent leschances que les periodes de silence des paires exterieures coıncident diminuent aussi.

Cette experience met donc en evidence un probleme d’inegalite important dans l’acces aumedium radio de 802.11.

5.3 Sauts multiples en configuration de chaıne

Jusqu’alors nous nous sommes interesses qu’a des configurations qui ne faisaient pas appel a lacapacite de routage des reseaux ad-hoc. Dans le scenario presente sur la figure 5.7, nous cherchonsmaintenant a voir ce qu’il se passe dans une chaıne assez longue (comportant jusqu’a 7 sauts) sil’emetteur envoie autant de donnees que possible.

Tout d’abord, il est important de comprendre que dans ce genre de scenario, le protocole deroutage utilise a deja un impact important. En effet, si des interferences ou des collisions au niveaude 802.11 provoquent la perte de certains paquets necessaires pour le routage voire des incapacitestotales de communication un peu longues entre certains mobiles, cela peut conduire le protocolede routage a declarer l’expiration de la route. Les timers et les mecanismes declenchant 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 meme pour les algorithmes dereconstruction qu’une perte de route va declencher.

Par exemple, dans notre scenario de chaıne, en cas d’utilisation d’un protocole proactif, la pertede paquets hello consecutifs peut provoquer la rupture de la route. Cela va declencher une premieremise a jour en cascade des tables de routage. Quand les paquets hello sont ensuite a nouveaux recus,cela va provoquer une seconde mise a jour en cascade. Il y aura donc une periode d’instabilite dansl’etat des tables de routage (ou il n’y aura plus de route de bout en bout de la chaıne), ainsi qu’unecharge eventuellement importante du reseau. Dans le cas d’un protocole reactif, la perte de paquetsde recherche de route peut amener l’emetteur a penser qu’il n’y a pas de route disponible du tout ;et donc a attendre un nouvel essai initie par une couche superieure pour a nouveau essayer detrouver la route.

Cette mise en garde effectuee, revenons a la description du scenario. Il a consiste a faire transiterdes 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œudssont places a 200 metres les uns des autres. Dans la section 4.5.1, nous avons vu que dans le casdu modele two-ray ground, cela correspondait a un placement tel qu’un nœud peut communiqueravec ses voisins de gauche et de droite, et que sa porteuse est detectee par les nœuds a deux sautset pas plus loin. Cela correspond evidemment a l’idee que l’on se fait d’une communication multi-sauts dans un veritable reseau ad hoc, ou les nœuds d’une route sont en general choisis de sorte aminimiser si possible le nombre de sauts.

La figure 5.8 montre les debits mesures sur la chaıne en fonction du nombre de sauts. Le debit debout en bout diminue logiquement tres vite lorsque l’on augmente le nombre de sauts (1.6 Mbit/savec un seul saut, 0.8 Mbit/s avec deux sauts, environ 0.55 Mbit/s avec un troisieme) pour sestabiliser aux alentours de 300 kbit/s lorsque plus de 4 nœuds sont impliques. Dans les cas dechaınes assez longues, on remarque egalement un certaine instabilite du debit de bout en bout.

La figure 5.9 presente les chronogrammes d’emissions pour des chaınes de 2 a 8 nœuds. LesRTS/CTS n’etaient pas utilises, seuls les donnees et leurs eventuels acquittements sont doncrepresentes. 2 IF0 et 2 IF1 representent les emissions par les nœuds 0 et 1 dans la chaıne a unsaut, 3 IF0, 3 IF1 et 3 IF2 representent les emissions par les nœuds 0, 1 et 2 dans la chaıne adeux saut et ainsi de suite. Cette partie du chronogramme correspond au tout debut des echanges,on y voit la forme en ’V’ particuliere correspondant aux paquets RouteRequest et RouteReply quitraversent la chaıne de bout en bout pour construire la route. On remarque que ces paquets Rou-teRequest et RouteReply ne sont pas acquittes (ils sont diffuses) mais que les paquets de donnees

64


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

1.8e+06

0 10 20 30 40 50 60

debi

t en

bits

par

sec

onde

temps en secondes

1 saut2 sauts3 sauts4 sauts5 sauts6 sauts7 sauts

Fig. 5.8 – Debit 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 paquetstres courts).

On voit egalement que lorsque le nombre de sauts augmente, certains nœuds ont du mal aacceder au medium. Par exemple, dans la chaıne a 8 nœuds (derniere serie), apres la traverseede la chaıne complete par trois paquets de donnees, le nœud 1 monopolise le canal pendant unedouzaine de paquets (ces paquets sont bien recus au nœud 2 comme le prouvent les acquittementsqu’il renvoie, mais il n’arrive pas ensuite a acceder au canal pour continuer a router ces paquets).Ces effets sont causes par la combinaison de plusieurs facteurs : le nœud 0 a toujours des paquetsa envoyer et le nœud 1 est gene par plus de mobiles que le nœud 0 (0 ne peut pas emettre enmeme temps que 1 ou 2, 1 ne peut emettre en meme temps que 0, 2 et 3). Sur ces chronogrammes,il est egalement aise de constater la reutilisation spatiale (si deux ou plus nœuds emettent a uninstant donne, c’est qu’ils sont suffisamment eloignes pour ne pas interferer ni meme se detecter,par exemple les nœuds 0 et 3 emettent parfois en meme temps).

L’allure generale des chronogrammes pour les chaınes assez longues (5 sauts ou plus) permetde tout de suite saisir certaines informations confirmees par d’autres analyses des traces : dansun scenario de chaıne, avec un modele de propagation two-rays ground, les paquets ont de forteschances d’etre bloques au niveau des 3 premiers nœuds ; mais s’ils atteignent le quatrieme, alorsleur chance d’atteindre la destination finale est tres importante. Ce blocage au niveau des premiersnœuds est en fait du aux difficultes d’acces au canal puisque la source essaie d’envoyer autant depaquets que possible (et que comme nous l’avons mentionne, elle rencontre moins de contentionque les autres.) Plus loin sur la chaıne le probleme ne se pose plus car les nœuds ne cherchent aemettre 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 meme simulation mais en ajoutant l’utilisation des RTS/CTS.Le debit de bout en bout obtenu en fonction du nombre de sauts est presente sur la figure 5.10. Lesdebits pour les chaınes courtes (1, 2 et 3 sauts) sont assez similaires a ceux obtenus si l’on n’utilisepas les RTS/CTS. Bien sur, dans leurs cas, on observe une diminution du debit proportionnelleau temps supplementaire de transmission des paquets RTS/CTS (debits respectifs de 1.4, 0.7 et0.4 Mbit/s respectivement). Mais lorsque la chaıne continue de s’allonger, le debit de bout en boutdevient vraiment tres faible (moins de 100 kbit/s a partir de 5 sauts). Les RTS/CTS semble doncdans ce contexte avoir un contre-effet et etre particulierement dommageables. Les chronogrammesdes figures 5.11 (sans RTS/CTS) et 5.12 (avec RTS/CTS) montrent que dans le cas de l’utilisationdes RTS/CTS, tres peu de paquets arrivent a traverser la chaıne de facon consecutive. Le nœud0 envoie en quasi permanence des paquets au nœud 1, mais celui-ci n’arrive que rarement a lesfaire suivre. On remarque egalement des coupures tres frequentes de la route, qui force AODV ala reconstruire (ceci se voit tres bien avec les formes en ”V” precedant les periodes ou quelquespaquets arrivent a traverser la chaıne completement.

Les chronogrammes des figures 5.13 (sans RTS/CTS) et 5.14 (avec RTS/CTS) permettent devoir plus en detail ce qui se passe. En l’absence de RTS/CTS, on remarque une forte reutilisationspatiale, les nœuds situes a trois sauts ou plus l’en de l’autre pouvant en general emettre en memetemps. Avec les RTS/CTS maintenant, on remarque que c’est plus problematique. Sur la figure 5.14par exemple, on voit que lorsque le nœud 3 accede au canal, le nœud 0 envoie plusieurs RTS qui nerecoivent pas de reponse de 1 (et de meme, 1 envoie plusieurs RTS a 2 qui n’y repond pas quand 4est en train d’envoyer des donnees).

Sur le chronogramme de la figure 5.15 (qui correspond a une autre periode de la simulationde la chaıne de 8 nœuds avec RTS/CTS, on voit cependant que cette reutilisation spatiale peutparfois avoir lieu. On voit bien en particulier sur cette figure les emissions en parallele des mobiles(0,4), (1,5) et (2,6). Ceci est d’ailleurs en contradiction avec [45] qui utilisait aussi NS2 mais quine semble avoir retenu que le cas de la figure 5.14.

5.4 La chaıne fixe et la paire de perturbateurs

Cette experience montre l’impact dans un contexte plus realiste du phenomene qui a ete mis enlumiere dans le scenario precedent. La topologie est celle presentee sur la figure 5.16 : un flux UDPa debit constant traverse une chaıne de six mobiles (similaire a celle utilisee dans les premieressimulations, avec une distance de 200 metres entre chaque nœud). Une paire de mobiles (entrelesquels existe un autre flux a debit constant) est initialement situee loin de la chaıne (en dehorsde toute zone d’interferences). Les mobiles de la paire sont tres proches l’un de l’autre (un metre)durant la totalite de la simulation. Les nœuds de la chaıne restent fixes du debut a la fin. Au furet a mesure de la simulation, la paire va se deplacer et va progressivement entrer puis ressortir dela zone d’interferences des nœuds de la chaıne.

La simulation a ete effectuee pour differents debits demandes sur les deux flux (2000, 1333,1000, 800, 400 et 200 kbit/s). Excepte pour des debits demandes de 200 kbit/s, le reseau est satureet la bande passante n’est pas suffisante pour delivrer la totalite des paquets demandes. Pour desraisons de lisibilite la figure 5.17 ne presente qu’une moyenne des debits sur la chaıne simules enfonction du temps. Le but de cette courbe est de donner une idee des phenomenes d’interferencesen fonction de la position des divers mobiles ; plus que les debits chiffres, c’est la forme de la courbequi est importante ici. On remarque immediatement un effet de symetrie. Au tout debut et a la

67


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

1.8e+06

0 10 20 30 40 50 60

debi

t en

bits

par

sec

onde

temps en secondes

1 saut2 sauts3 sauts4 sauts5 sauts6 sauts7 sauts

Fig. 5.10 – Debit 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), detail

Fig. 5.14 – Chronogramme dans la chaıne a 8 nœuds (UDP, avec les RTS/CTS), detail

Fig. 5.15 – Chronogramme dans la chaıne a 8 nœuds (UDP, avec les RTS/CTS), detail 2

69


Fig. 5.16 – Le scenario de la chaıne etdu couple de perturbateurs

0

50000

100000

150000

200000

250000

300000

350000

10 20 30 40 50de

bit e

n bi

ts p

ar s

econ

de

temps en secondes

Fig. 5.17 – Debit moyen sur la chaıne

fin de la simulation, la paire perturbatrice est trop loin de la chaıne pour la gener, c’est la que l’onobserve logiquement le debit maximum. On remarque ensuite que lorsque la paire perturbatriceest tres proche de la chaıne (partie centrale de la courbe, entre les secondes 25 et 45 environ), ledebit sur la chaıne est reduit mais neanmoins existant. Et finalement on observe deux zones ou leflux sur la chaıne est completement stoppe ou presque (secondes 10 - 25 et 45 - 50). Ces periodescorrespondent aux moment ou la paire perturbatrice est dans la zone de detection de porteuse desnœuds centraux de la chaıne. Le phenomene qui se produit alors est tres proche de celui rencontredans la simulation des trois paires : les mobiles au centre de la chaıne detectent les porteuses despremiers mobiles de la chaıne mais aussi celles de la paire perturbatrice. Ils sont dans la memesituation que la paire centrale dans le scenario des trois paires, puisque qu’a cet instant la paireperturbatrice et les premiers mobiles de la chaıne ne se genent pas du tout et emettent de facondesynchronisee.

5.5 Le probleme de l’asymetrie

Les problemes que nous avons mis en lumiere dans les simulations precedentes sont ca-racteristiques des reseaux ad-hoc. L’effet le plus remarquable est l’incapacite pour certainsemetteurs d’acceder au canal radio. Contrairement aux problemes d’equite mis en evidence dans[44, 48] ou l’inegalite provient de collisions repetees, l’inegalite mise en evidence ici provient del’impossibilite d’acceder au medium radio (certains mobiles ne peuvent pas s’exprimer). Ce typede comportement se produit lorsqu’il existe une asymetrie dans les interferences entre les differentsmobiles. La notion d’asymetrie a ete mentionnee dans [47], mais aucune explication de 802.11 facea cette asymetrie n’a ete apportee. Or le scenario des trois paires permet de bien comprendrel’origine du probleme. En effet, pour un mobile connaissant une contention plus importante, uncertain nombre d’autres mobiles en competition avec lui ne se genent pas du tout entre eux, etleurs emissions ne sont donc pas synchronisees. Pour que le mobiles mis en defaut puisse acceder au

70


canal, il faut que les periodes de silence des autres mobiles se recouvrent. Or la probabilite d’un telrecouvrement est faible, et le mobile percoit le canal comme occupe des que l’un ou l’autre l’utilise.Dans les configurations que nous avons presentees, les mobiles les plus exposes (la paire centraledans le scenario des des trois paires par exemple) percoivent le canal occupe en quasi permanence, etles mobiles ”geneurs” le percoivent presque tout le temps libre (ils continuent donc leurs emissionsde plus belle).

Ce probleme n’est pas un probleme de nœuds caches et ne peut pas etre resolu par le mecanismedes RTS/CTS. En effet, les recepteurs des mobiles desynchronises ne sont pas necessairement lesmemes et de plus les mobiles peuvent etre trop loin les une des autres pour comprendre le contenudes paquets de controle. Dans le contexte prevu par 802.11 (mobiles attaches a des stations de baseou a portee directe de communication) le type d’asymetrie decrit precedemment ne se produit pas.Soit les mobiles sont a portee de communication directe, soit ils sont relies a une meme stationde base et lorsqu’ils communiquent avec elle les RTS ou CTS qu’elle envoie suffisent a reserverconvenablement le canal et y permettre un acces equitable.

Nous avons vu egalement que le mecanisme des EIFS qui est sense proteger les acquittementspouvait amplifier le probleme de l’asynchronisme que nous venons decrire. De meme, nous avonsvu dans l’etude des resultats de la chaıne que les RTS/CTS pouvaient avoir eu aussi un impactparticulierement negatif dans le cadre de reseaux multi-sauts etendus.

5.6 Conclusion sur ces simulations

L’inegalite dans l’acces au medium radio rencontree dans des configurations de base des reseauxad hoc a une impact fondamental sur les protocoles des couches superieures. En effet, la plupart desprotocoles dans les reseaux ad hoc basent leur fonctionnement sur la connaissance des liens. Desqu’un lien apparaıt ou disparaıt, des informations sont mises a jour dans le reseau. Dans le cadred’un reseau fixe, si chaque mobile est en mesure de s’annoncer regulierement les liens seront connuset consideres comme stables, ce qui entraınera peu de trafic de controle. Par contre, si certainsmobiles ne sont pas en mesure d’acceder regulierement au medium, des liens vont apparaıtre etdisparaıtre de maniere cyclique alors que ces liens existent bien physiquement ! Ceci entraınera unecharge de trafic de controle non negligeable qui aurait pu etre evitee si tous les mobiles avaientpu emettre de maniere equitable (ces cassures de lien repetees et le trafic de controle genere sontparticulierement visibles dans le chronogramme de la chaıne de 8 nœuds avec RTS/CTS, sur lafigure 5.10 et 5.14). Cela implique aussi que les protocoles de routage n’auront pas une bonnevision du reseau puisqu’ils ne verront pas certains liens existants reellement. Ils n’auront doncqu’une connaissance partielle de la topologie. Ils pourraient alors prendre des decisions adapteesa la vision qu’ils ont alors qu’elles ne le sont peut-etre pas a la topologie reelle. Enfin, une telleinegalite implique que certaines communications ne pourront obtenir qu’un debit tres faible voirenul a certains moments.

71

CHAPITRE

6 Quelques solutions auxproblemes d’equite dans lesreseaux ad hoc

Plusieurs solutions ont ete proposees pour resoudre le probleme d’equite dans l’acces au mediumradio.

MACAW [46] propose une gestion differente de la fenetre de contention : l’idee est de ne pasfavoriser la station qui vient juste d’emettre comme le fait le Binary Exponential Backoff. Cettesolution concerne les problemes d’inegalite provenant de collisions mais elle ne resoudra pas lesproblemes ou certains mobiles n’accedent pas du tout au medium.

Les solutions elaborees dans [47] se basent sur un graphe de contention des flux ce qui supposeune connaissance globale du reseau ainsi que des flux achemines dans le reseau. Cette solution estdonc difficile a implanter en pratique.

Les travaux de Bensaou et al. [48, 38] ont une approche de faisabilite puisqu’ils modifient 802.11dans le but de garantir une meilleure equite. L’idee est que chaque mobile prenne en compte lescommunications dans son voisinage a un saut afin de savoir s’il peut emettre beaucoup ou s’ildoit se ralentir. En comptant ses propres communications et les communications de ses voisins,chaque mobile peut savoir s’il a emis plus ou moins que ses voisins. S’il a emis plus, il augmentesa fenetre de contention, ce qui lui permet statistiquement de ralentir ses emissions. S’il a emismoins, il diminue sa fenetre de contention, ce qui lui permet statistiquement d’augmenter sesemissions. Avec ces modifications, le systeme doit alors se stabiliser sur une solution plus equitable.L’idee est interessante (meme si l’algorithme n’a manifestement pas ete correctement finalise etsi quelques modifications simples l’amelioreraient), mais il ne permet d’equilibrer que des flux aportee de communication. Or, comme dans le scenario des trois paires par exemple, les emetteurssont en zone de detection 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 resoudre le problemed’equite quand les mobiles en competition ne peuvent pas communiquer. Par la suite, nous avonspropose une seconde solution, inspiree de celle de Bensaou et al., mais qui cherche a diffuser del’information dans son voisinage pour etre plus efficace.

6.1 Une solution historique et locale

Un certain nombre de contraintes que nous nous etions fixees nous on conduit a elaborer cettepremiere solution. Ces contraintes etaient les suivantes :

72

CHAPITRE 6. QUELQUES SOLUTIONS AUX PROBLEMES D’EQUITE DANS LESRESEAUX AD HOC

– Minimiser les changements a apporter a 802.11 (notre approche est assez pragmatique, il estimportant a nos yeux de chercher une solution qui puisse etre implementee concretement dansdes materiels existants).

– Garder la compatibilite avec les cartes 802.11 n’ayant pas ete modifiees– Fonctionner meme lorsque les mobiles impliques n’ont aucun moyen de communiquer, meme

en passant par des intermediairesSous nos contraintes il peut parfois etre impossible de communiquer avec les mobiles qui nous

genent ni meme de les identifier. Il est egalement impossible pour un mobile de se rendre compte queson activite, lorsqu’elle est cumulee a celles d’autres emetteurs, empeche d’autres mobiles d’accederau canal (par exemple, du point de vue des paires exterieures dans le scenario des trois paires, lecanal est toujours libre et elles en profitent logiquement pour emettre au debit maximum). Notresolution consiste a chercher a penaliser les mobiles qui transmettent beaucoup. De cette maniereon espere que lorsqu’ils seront forces de se taire, les chances que les periodes de silence coıncidentau niveau des mobiles genes augmenteront et que ces derniers pourront enfin emettre.

La modification que nous proposons concerne le backoff et son calcul devient le suivant : auniveau de chaque nœud le temps est decoupe en periodes de longueur fixe (par exemple uneseconde). La situation est la meme pour chaque nœud en debut de periode. Ensuite, a chaquefois que le nœud gagne l’acces au canal et envoie un paquet, une penalite est ajoutee au backoff(le backoff pour les paquets suivants sera toujours aleatoire, mais statistiquement plus grand).En dehors de cette penalite, le calcul du backoff reste strictement identique a celui decrit dansla norme. Nous avons soigneusement choisi la courbe de progression de la penalite (ou malus)qui est presentee sur la figure 6.1. Cette courbe est caracterisee par un premier plateau ou lemalus est nul ou presque (”les premiers paquets ne sont pas penalises”), par une rampe assezraide (”maintenant que l’on a deja beaucoup parle, il est temps de laisser de la place auxautres”) et enfin par un plateau assez haut (si l’on continuait a augmenter la penalite de maniereexponentielle, lorsqu’il n’y a qu’un seul flux, son debit serait trop penalise). Au debut de chaquecycle, le compteur est re-initialise et la penalite redevient nulle. Dans ce systeme, les parametresqui peuvent etre ajustes sont essentiellement la duree du cycle et la forme de la courbe deprogression de la penalite. Il faut noter que nous n’avons pas essaye de favoriser les mobiles endefaut en diminuant la borne maximale de leur fenetre de contention en dessous du seuil cwMinfixe par la norme. Nous pensions que la norme avait ses raisons d’avoir fixe cwMin a 31 et quereduire cette valeur pourrait notamment augmenter de maniere sensible les collisions dans le reseau.

Bien que cette methode soit simple, elle donne des resultats tout a fait interessants. Dans lessimulations, il est apparu que la probabilite pour un mobile d’etre completement ”ecrase” par sesvoisins non directs est beaucoup plus faible qu’avec 802.11 non modifiee.

La figure 6.2 montre les debits obtenus dans le scenario des trois paire en utilisant le malus dela figure 6.1. On remarque que dans la zone centrale de la courbe (lorsque la paire centrale detecteles porteuses des deux paires exterieures sans pouvoir communiquer avec elles) l’acces au canaln’est peut-etre pas encore equiprobable pour les trois paires, mais que la paire centrale n’est pluscompletement etouffee par les deux autres (elle obtient un debit de 300 - 350 kbit/s, contre environ800 kbit/s pour chacune des paires exterieures). Le principal inconvenient de la methode est aussiclairement visible sur cette courbe, puisque le debit maximum d’une paire lorsqu’elle ne subit pasd’interferences est severement limite (seulement environ 1 Mbit/s au dela de 22 secondes, alors quesans malus on atteint 1.6 Mbit/s, soit une reduction de pres de 40%). Comme nous augmentons

73


0

50

100

150

200

250

0 5 10 15 20 25 30

Mal

us (

en n

ombr

e de

tim

e sl

ots)

paquets envoyes depuis le debut du cycle

malus

Fig. 6.1 – Progression de la penalite enfonction du nombre de paquets envoyes

0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

5 10 15 20 25

debi

t en

bits

par

sec

onde

temps en secondes

paire de gauchepaire centrale

paire de droite

Fig. 6.2 – La simulation des 3 paires en utilisant lemecanisme du malus

statistiquement le backoff, le nombre maximum de paquets qu’un mobile peut envoyer par secondediminue. Mais il faut garder a l’esprit que ce probleme devient rapidement imperceptible lorsque lenombre de flux en competition a un instant donne pour l’acces au canal augmente. Sur la premierepartie de la courbe (de 0 a 10 secondes), les trois flux sont en competition et leur debit agregeest de 450×3 soit 1350 kbit/s ; avec trois flux en competition, la perte de debit engendree par lemecanisme du malus passe donc deja en-dessous des 20%.

Nous avons egalement teste notre systeme sur le scenario 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 debit demande pour chacund’entre eux de 2 Mbit/s. Avec la version normale de 802.11, nous avons obtenu des resultatsdesastreux (figure 6.3). Il faut bien garder a l’esprit que le caractere erratique de l’acces au mediumdans ces conditions empeche de nombreux acquittements de TCP d’arriver a temps, empechantainsi parfois TOUTE progression de la communication. La version modifiee se comporte beaucoupmieux (figure 6.4). Notons qu’en l’absence de contention, le debit sur la paire perturbatrice estfortement affecte (periodes des secondes 0 a 10 et de 53 a la fin) puisque le mecanisme du malus lefait passer de 1250 kbit/s a un peu moins de 950 kbit/s, mais que le debit sur la chaıne ne changepas (un peu plus de 200 kbit/s, avec ou sans malus). Comme nous l’avions deja enonce, l’effetnegatif du malus sur le debit decroıt tres rapidement avec le nombre de mobiles en contention.

L’autre inconvenient principal de la methode, qui n’apparaıt pas cette fois-ci sur les courbes, estla tendance a produire des transferts par rafale, qui peuvent causer des problemes a certains typesd’applications (multimedia utilisant des petits tampons en particulier, comme la telephonie). Si unemetteur ne rencontre pas beaucoup de difficultes pour acceder au canal et qu’il a beaucoup depaquets en attente, il va les emettre a la suite les uns des autres jusqu’a ce que la penalite deviennenon negligeable et le freine. Les emissions d’un tel mobile seront donc en majorite en debut decycle. A ce propos, la taille de la fenetre TCP a une importance : trop petite et TCP pensera qu’ily a de la congestion lorsque le debit sera reduit par la penalite ; il reagira en diminuant encore safenetre, ce qui est mauvais.

74


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

0 10 20 30 40 50 60

DØ

bit (

en b

it pa

r se

cond

e)

Temps (en secondes)

chainepaire perturbatrice

Fig. 6.3 – Debits dans la simulation de la chaıneet du perturbateur (TCP, 802.11 non modifie)

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

1e+06

0 10 20 30 40 50 60

DØ

bit (

en b

it pa

r se

cond

e)

Temps (en secondes)

chainepaire perturbatrice

Fig. 6.4 – Debits dans la simulation de la chaıneet du perturbateur (TCP, 802.11 modifie)

Au niveau des amelioration possibles de ce systeme, on peut citer d’une part le changementdans le comptage effectue. Plutot que de compter les paquets indifferemment, il serait peut-etreplus judicieux de prendre en compte leur taille. En effet, en fonction des applications (telnet parexemple) et des protocoles utilises (TCP avec ses acquittements), il se peut qu’il y ait beaucoup depaquets tres petits a transferer. Ces dernier ferait tres vite progresser le malus alors que finalementils ne genent peut-etre pas beaucoup les mobiles du voisinage. D’autre part, la courbe de progressionde la penalite meriterait d’etre etudiee plus en detail egalement. Sous sa forme actuelle elle donnedes resultats deja tres encourageants, mais nous avons le sentiment que ces derniers pourraient etreencore ameliores.

Remarquons finalement que ce systeme de penalite sur le backoff permet bien l’inter-operabiliteavec les mobiles utilisant des cartes 802.11 non modifiees. Les mobiles utilisant la version modifieeseront un peu desavantages en terme de debit possible, mais la communication restera possible.

6.2 Une solution etendue geographiquement

6.2.1 Point de depart et algorithme

Nous sommes partis des travaux de Bensaou et al. [48]. Chaque mobile effectue un comptagedes paquets en terme d’occupation du medium. Le nombre de paquets qu’il envoie est stocke dansla variable Wi et le nombre de paquets envoyes par ses voisins est stocke dans la variable Wo. Lesvariables Φi et Φo correspondent respectivement a l’allocation faite au nœud i et celle faite a sesvoisins. Ils definissent un index d’equite egal a Wi

Wo× Φo

Φi. La fenetre de contention de chaque mobile

est alors ajustee de la maniere suivante : chaque mobile double sa fenetre de contention si sonindex d’equite devient superieur a une constante C, chaque mobile divise par deux sa fenetre decontention si son index d’equite devient inferieur a 1

C , et chaque mobile ne fait rien si son indexd’equite est compris entre 1

C et C.Comme nous l’avons dit dans l’introduction de ce chapitre, l’algorithme propose presente

quelques faiblesses. D’une part, le comptage des paquets est effectue de maniere anarchique : cer-

75


A

B

C

D

Fig. 6.5 – La configuration a quatre nœuds

tains paquets sont comptes plusieurs fois sans aucune raison. D’autre part, l’index d’equite pourchaque mobile devrait se stabiliser vers 1 or il se situe entre 2 et 4. Enfin, dans les scenarios pro-poses, la taille des fenetres de contention des mobiles se bloque a la taille maximale autorisee par802.11, ce qui conduit a une perte de debit global importante.

Neanmoins les approches d’espionnage du medium et de faisabilite nous semblaient interessantes.Nous avons donc garde le socle de l’algorithme presente par Bensaou et al. et nous l’avons modifieafin d’apporter un espionnage etendu et de reduire la perte globale de bande passante.

Un espionnage etendu Dans l’algorithme de depart, chaque mobile ne considere que les paquetsqui sont envoyes dans sa zone de communication. Or deux flux peuvent etre en competition memesi leurs emetteurs ne sont pas a portee de communication. Par exemple, dans la figure 6.5, lesemetteurs A et B ne se voient pas mais leurs flux associes sont en competition. Par consequent,cette methode ne permet pas a un mobile d’evaluer toux les flux qui sont en competition avec leflux dont il est emetteur.

Nous proposons donc que chaque mobile communique dans son acquittement (ou son CTSquand il est actif) son estimation des communications voisines (Wo dans l’algorithme). Ceci vapermettre a l’emetteur d’un flux d’avoir une connaissance plus etendue des flux en competition. Ilfaut neanmoins faire attention a ne pas compter plusieurs fois les paquets. Pour cela, chaque mobiledoit faire un comptage separe des paquets de mobiles voisins. Ensuite chaque mobile enverra dansl’ACK ou le CTS la liste des mobiles connus comme etant voisins et le comptage Wo. Lorsque lesmobiles recoivent cette information, ils n’ont plus qu’a retirer le comptage des mobiles deja connusd’eux du Wo recu et mettre a jour leur nouveau Wo.

L’envoi de la liste des voisins peut etre couteux, c’est pourquoi nous proposons que seules lesentrees/sorties de cette liste soient integrees dans le paquet ACK ou CTS.

Ajustement de la fenetre de contention A partir des donnees de comptage, le calcul de l’indexd’equite intervient, puis en fonction de la valeur obtenue la fenetre de contention est ajustee. Dansl’algorithme de depart, nous avons remarque que les changements dans la taille de la fenetre etaientbrusques et ne prenaient pas le temps de verifier qu’ils etaient profitables.

Nous proposons donc de modifier l’ajustement de la fenetre de contention. Dans le cas ou unmobile lese ses voisins, la fenetre ne sera modifiee que si ces trois conditions sont remplies (le casou le mobile est lese par ses voisins est symetrique) :

– L’index d’equite doit depasser la valeur 1 augmentee d’une tolerance fixee ;– La periode d’adaptation de la fenetre de contention actuelle doit etre terminee ;

76


– L’evolution de l’index d’equite doit etre superieure a 0.9, ceci afin de rendre compte si lasituation s’est degradee ou amelioree.

Si ces conditions sont remplies, la fenetre de contention est multipliee par l’evolution de l’indexd’equite et de Wi, plutot que par 2 (comme c’est le cas dans l’algorithme de base). On assure ainsique la fenetre de contention est equilibree et prend en compte l’evolution propre du debit du mobile.

6.2.2 Quelques resultats

Ce travail a ete realise en fin de these, et je nous ne sommes malheureusement pas en mesured’apporter des resultats detailles sur l’algorithme propose. Neanmoins, quelques scenarios ont eteevalues afin de pouvoir comparer la version de base de Bensaou et al. et la version amelioree. Nousavons effectue un certain nombre de simulation grace a NS2.

Premier scenario a 2 paires. Le scenario utilise est celui propose initialement par Bensaou etal. dans [48], il est presente sur la figure 6.5. Dans ce scenario, il existe un flux entre A et C, ainsiqu’un autre en B et D. Les trais en pointilles indiquent que B et C sont a portee de communicationmais ne s’envoient pas de paquets de donnees. Les flux de donnees sont constitues de paquets UDPde 1000 octets. Le debit demande par chacun des flux augmente avec le temps suivant la courbepresentee sur la figure 6.6.

Sur la figure 6.7, on presente le debit de chacune des paires dans ce scenario si l’on utilise802.11 tel qu’il est implante dans NS2. A partir du moment ou le debit demande est suffisammentimportant, on remarque le debit extremement faible entre A et B (de l’ordre de 100 kbit/s) alorsqu’il est une dizaine de fois plus important entre C et D (environ 1 Mbit/s). Le probleme est detailledans [48], il provient de l’utilisation des RTS/CTS. Dans ce scenario, A ne peut communiquer avecB, ni meme detecter sa porteuse. Lorsque A veut envoyer un paquet de donnees a C, il commencepar 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 donnees a D,il n’est pas gene que si C a pu envoyer un CTS a A (et D n’etant a portee que de B, il peuttoujours repondre au RTS de ce dernier). A partir du moment ou B arrive a envoyer un CTS, ildevient tres difficile pour A d’obtenir un CTS permettant de lui envoyer des donnees, d’ou les debitsdesequilibres. Du fait des nombreux echecs de transmission que recontre le nœud A, sa fenetre decontention est en general tres grande, comme on peut le voir sur la figure 6.8 (avec l’algorithmede Binary Exponential Backoff, la taille de la fenetre double a chaque echec, jusqu’a se stabiliser a1031 time slots).

Dans [48], Bensaou et al. proposent une solution que nous avons implantee dans notre version deNS2. Nous avons ensuite implante la version modifie de cet algorithme decrite precedemment. Lesdebits obtenus avec l’algorithme original de Bensaou et al. sont presentes sur la figure 6.9 et ceuxobtenus avec notre version le sont sur la figure 6.11. A partir du moment ou le debit demande estsuffisamment important, avec l’algorithme de Bensaou et al., le debit des deux flux est nettementplus equitable qu’avec la version non modifiee de 802.11. Par contre, evoluant les deux entre 200et 300 kbit/s, le debit agrege est bien en dessous du debit maximum autorise par le canal (dansles meme 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 treslongs avec l’algorithme de Bensaou et al. La taille des fenetres de contention sont presentees sur lafigure 6.10, et l’on peut voir qu’elles sont la plupart du temps a leur valeur maximale (1023 timeslots).

77


0

500000

1e+06

1.5e+06

2e+06

0 2 4 6 8 10 12 14 16

debi

t dem

ande

en

bits

par

sec

onde

temps en secondes

Fig. 6.6 – Debit demande sur chaque flux en fonction du temps

Les debits obtenus avec la modification que nous proposons sont presentes sur la figure 6.11. Onpeut voir que l’equite entre les deux flux est tres bien respectee, et qu’avec environ 300-350 kbit/schacun, les deux emetteurs utilisent plus de bande passante qu’avec l’algorithme originel de Bensaouet al . Ceci est confirme par les tailles des fenetres de contention de A et de B qui sont beaucoupplus equilibree, comme le montre la figure 6.12.

Second scenario a 2 paires. Nous avons ensuite legerement modifie le scenario. La configurationde cette deuxieme simulation est celle de la figure 6.13. Le nœud A envoie toujours des donnees aC et le nœud B en envoie toujours a D. Les debits demandes en fonction du temps sont toujoursceux de la figure 6.6. Mais cette fois ci, A est a portee de detection de porteuse de D. Les debitsobtenus avec la version normale de 802.11 pour les flux (A→C) et (B→D) sont presentes sur lafigure 6.14. On remarque une fois de plus une tres forte inegalite dans les debits. Les tailles desfenetres de contention (figure 6.15) montrent bien que nous avons affaire a un probleme d’accesau medium et non de collision. En effet, les fenetres de contention des deux emetteurs restenttres basses durant toute la duree de la simulation. La figure 6.16 detaille le phenomene qui seproduit, et qui a pour origine le mecanisme des EIFS. Nous rappelons que les EIFS ont pour butde proteger les acquittements dans le cas ou un mobile a percu de l’activite sur le canal mais n’apas pu comprendre le paquet. Si ce paquet etait un paquet de donnees, alors son destinataire doitl’acquitter. Si le mobile qui a detecte l’activite sans la comprendre emettait tout de suite lorsque lecanal devient libre, alors il pourrait provoquer une collision avec cet acquittement. 802.11 imposedonc aux mobiles dans cette situation d’attendre un temps plus long, EIFS, suffisant pour que leveritable destinataire du paquet envoie son propre acquittement. Dans ce scenario, B comprendles paquets de A, et peut donc positionner son NAV correctement. Mais il ne peut que detecterla 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 decrementer au moinsen partie. Comme D comprend les CTS et ACK envoyes par C, D ne se trouve donc pas en EIFSde facon symetrique. Il en resulte une forte inegalite dans l’acces au canal, puisque A a de grossesdifficultes a reprendre la main lorsqu’il la perd.

78


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

0 2 4 6 8 10 12 14 16

debi

t en

bits

par

sec

onde

temps en secondes

A -> C (normal)B -> D (normal)

Fig. 6.7 – Debit dans le scenario des deux paires(802.11 normal)

0

200

400

600

800

1000

0 2 4 6 8 10 12 14 16

taill

e de

la fe

netr

e de

con

tent

ion

temps en secondes

A (normal)B (normal)

Fig. 6.8 – Taille de la fenetre de contention(802.11 normal)

0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

0 2 4 6 8 10 12 14 16

debi

t en

bits

par

sec

onde

temps en secondes

A -> C (bensaou)B -> D (bensaou)

Fig. 6.9 – Debit dans le scenario des deux paires(802.11 Bensaou)

0

200

400

600

800

1000

0 2 4 6 8 10 12 14 16

taill

e de

la fe

netr

e de

con

tent

ion

temps en secondes

A (bensaou)B (bensaou)

Fig. 6.10 – Taille de la fenetre de contention(802.11 Bensaou)

79


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

0 2 4 6 8 10 12 14 16

debi

t en

bits

par

sec

onde

temps en secondes

A -> C (modif.)B -> D (modif.)

Fig. 6.11 – Debit dans le scenario des deux paires(802.11 modifie)

0

200

400

600

800

1000

0 2 4 6 8 10 12 14 16

taill

e de

la fe

netr

e de

con

tent

ion

temps en secondes

A (modif.)B (modif.)

Fig. 6.12 – Taille de la fenetre de contention(802.11 modifie)

A

B

C

D

Fig. 6.13 – La deuxieme configuration a quatre nœuds

Nous avons ensuite teste l’algorithme de Bensaou et al (figure 6.17 pour le debit et figure 6.18pour les fenetres de contention). Sur ces figures, nous pouvons voir que cet algorithme ne donnepas de bons resultats. Les fenetres de contention restent en quasi permanence au minimum, et parconsequent la situation est presque la meme qu’avec 802.11 non modifie, c’est a dire une tres grandeinegalite dans l’acces au canal.

Nous avons finalement utilise notre propre algorithme (figure 6.19 pour le debit et figure 6.20pour les fenetres de contention). Nous voyons sur ces figures que grace a une augmentation controleedes fenetre de contention, on arrive a obtenir des debits equitables et stables.

Conclusion Les resultats obtenus avec la modification que nous avons proposee de l’algorithmede Bensaou et al. donne des resultats tres encourageants. Non seulement il permet une bonne equitedans des conditions qui tiennent 802.11 en echec, mais il permet aussi une meilleure utilisation de labande passante disponible. Notre algorithme a cependant certaines limitations. Pour fonctionner,

80


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

0 2 4 6 8 10

debi

t en

bits

par

sec

onde

temps en secondes

A -> C (normal)B -> D (normal)

Fig. 6.14 – Debit dans le deuxieme scenario desdeux paires (802.11 normal)

0

200

400

600

800

1000

0 2 4 6 8 10

taill

e de

la fe

netr

e de

con

tent

ion

temps en secondes

A (normal)B (normal)

Fig. 6.15 – Taille de la fenetre de contention(802.11 normal)

RTSB

A

CTS

C

D

DATA

ACK

NAVCS EIFS CS EIFS

RTSbackoff

Fig. 6.16 – L’origine du probleme dans la deuxieme configuration a quatre nœuds

0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

0 2 4 6 8 10

debi

t en

bits

par

sec

onde

temps en secondes

A -> C (bensaou)B -> D (bensaou)

Fig. 6.17 – Debit dans le deuxieme scenario desdeux paires (802.11 Bensaou)

0

200

400

600

800

1000

0 2 4 6 8 10

taill

e de

la fe

netr

e de

con

tent

ion

temps en secondes

A (bensaou)B (bensaou)

Fig. 6.18 – Taille de la fenetre de contention(802.11 Bensaou)

81


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

0 2 4 6 8 10

debi

t en

bits

par

sec

onde

temps en secondes

A -> C (modif.)B -> D (modif.)

Fig. 6.19 – Debit dans le deuxieme scenario desdeux paires (802.11 modifie)

0

200

400

600

800

1000

0 2 4 6 8 10

taill

e de

la fe

netr

e de

con

tent

ion

temps en secondes

A (modif.)B (modif.)

Fig. 6.20 – Taille de la fenetre de contention(802.11 modifie)

il a besoin d’ajouter des informations dans les RTS, qui doivent donc etre utilises (ce n’est pastoujours le cas pour les paquets de donnees envoyes en unicast, et ne l’est jamais pour ceux diffuses).Enfin, il faut noter qu’il existe toujours des conditions face auxquelles ce type d’algorithme estimpuissant. C’est le cas notamment lorsque les mobiles qui sont en contention ne sont pas enmesure de communiquer les uns avec les autres, comme par exemple dans le scenario des troispaires que nous avions etudie precedemment.

82

Deuxieme partie

Experimentations en environnementreel

83

CHAPITRE

7 Objectifs des mesures etmoyens mis en œuvre

7.1 Introduction et objectifs

Les iimplantations de 802.11 sous simulateurs sont en general partielles, et parfois incorrectes.Une simulation detaillee de la couche MAC peut etre particulierement couteuse et inapproprieepour des simulations a grande echelle. Et une simulation detaillee de la couche physique seraitinexploitable la plupart du temps car bien trop complexe et donc trop lente (si l’on ne considerepas la mobilite, certaines techniques peuvent neanmoins etre employees [61, 62].

Le travail des concepteurs des simulateurs consiste entre autre a simplifier le code simule touten faisant en sorte que son comportement reste suffisamment realiste. Mais cette notion de realismevarie en fonction de l’utilisation. Par exemple la simulation de la diffusion d’une video dans unreseau a points d’acces (un flux de paquets re-emis uniquement par les stations de base et ou despertes sont acceptees) ne sera pas affectee de la meme facon par le manque de detail dans la couchephysique que le fonctionnement d’un protocole de routage ad-hoc (ou la perte de quelques paquetspeut considerablement alterer la vision de la topologie, et ou la perte d’un paquet par nœud de lachaıne de transmission en prive tous les nœuds suivants). Par consequent, et particulierement dansle contexte des reseaux ad hoc, les resultats obtenus par simulation peuvent etre differents de ceuxobtenus dans la realite. Or tres peu d’experiences ont ete realisees en contexte ad hoc. De plus, lesrares experiences menees avaient pour but d’evaluer differents protocoles de routage et non 802.11.

Comme les cartes 802.11 sont disponibles sur le marche, et que les materiels necessaires etaientsuffisamment abordables, nous avons donc decide de mener des series de mesures. Nous avons ainsipu mener une premiere evaluation de 802.11 en environnent ad hoc reel. Nous avons egalement pucomparer les mesures reelles aux simulations et nous assurer que les hypotheses faites a partir dessimulations sur le comportement de 802.11 dans un reseau ad hoc etaient correctes.

7.2 Les environnements de mesure

Dans un permier temps, il nous fallait realiser des experiences simples, permettant de verifierque les cartes se comportaient comme prevu dans des situations standards (mesures de debit sansinterferences exterieures, portee, etc.). Il nous fallait ensuite pouvoir mettre en place des scenariosrepresentant des utilisations caracteristiques des reseaux ad-hoc (communications multi-saut enparticulier). Et il nous fallait enfin obtenir des traces suffisamment detaillees sur le deroulementde ces scenarios 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 utilisees tres largement dans les travaux sur les reseaux ad hoc, ce n’estpas le cas des mesures en environnement reel. Cela vient du fait qu’il faut disposer du materiel(les ordinateurs et les cartes reseau), mais aussi de la main d’œuvre. Autant il est aise pour unepersonne seule de developper et de conduire des simulations, autant cela s’avere difficile des quel’on cherche a reproduire dans la realite des scenarios ad hoc.

7.2.1 Travaux anterieurs bases sur des mesures

Malgre la difficulte logistique de telles etudes, leur interet est certain, en particulier en tant quecomplement des resultats des simulations. Plusieurs travaux, qui cherchent avant tout a evaluerdes protocoles de routage bien precis, mettent donc en œuvre des mesures reelles. Dans [63] et[64] les auteurs evaluent DSR en utilisant quelques ordinateurs fixes et une demi-douzaine d’autresembarques dans des voitures se deplacant sur le campus. Des recepteurs GPS (Global PositioningSystem) sont utilises pour connaıtre les positions precises de mobiles, et les donnees sont sauve-gardees de maniere a pouvoir etre rejouees ensuite dans des simulations.

Dans [65], c’est ABR qui est evalue dans une configuration de un a trois sauts. Quatre mobilessont utilises pour realiser cette experience. Ils sont cependant disposes a des distances maximalesde 50 metres les uns de autres, les obstacles (batiments, arbres, etc.) empechant le reseau d’etreentierement maille.

ODMRP quant a lui est evalue par des mesures reelles dans [66] grace a sept ordinateursorganises dans des configurations multi-sauts. Dans certaines des experiences presentees, l’un desordinateurs se deplace d’ailleurs au cours de la mesure.

7.2.2 Ad hoc Protocol Evaluation (APE)

APE [67, 68] est un environnement dedie a l’evaluation des protocoles de routage des reseauxad hoc. Il est developpe a l’universite Uppsala en Suede ou l’idee de le creer avait germe lorsqu’uncertain nombre d’etudiants avaient ete equipes d’ordinateurs portables et de cartes reseau sans fil.Le materiel et la main d’œuvre disponibles, il etait en effet interessant de les utiliser. APE est fournisous la forme d’une distribution Linux (RedHat) accompagnee d’un certain nombre d’utilitaires.Les Wireless Tools [69] (un ensemble d’utilitaires permettant de configurer les cartes reseaux sansfil et de recolter certaines informations sur leur fonctionnement telles que les niveaux de signal etde bruit) sont utilises pour configurer le materiel. Les cartes doivent etre en particulier placeesen mode ad hoc (au sens de 802.11), et des adresses IP doivent etre assignees a chaque machine.L’objectif principal d’APE etant de permettre les comparaisons entre protocoles de routage, unedouzaine d’entre eux sont fournis directement (dont AODV, DSR, TORA, OLSR, TBRPF, etc.).

Afin de pouvoir mener a bien ces comparaisons, la reproductibilite des resultats est un elementcapital, aussi APE fournit-il un systeme permettant de regir par des scripts l’ensemble des actions.Apres une etape de synchronisation des horloges (une heure de declenchement relative a l’heure dedebut de la mesure est associee a chaque evenement, d’ou la necessite d’une synchronisation au toutdebut), les scripts controlant le declenchement des differentes sources sont lances. Les personnesayant en charge chacune des machines n’ont pas besoin de connaıtre les details des scenarios ; desinformations elles aussi scriptees sont affichees pour leur donner les instructions de deplacement aufur et a mesure.

Une fois une mesure terminee, les donnees sont centralisees sur une machine grace a des uti-litaires fournis. Un ensemble de programmes permet alors de traiter ces donnees et d’en tirer un

85


nombre important de metriques (taux de pertes de paquets, optimalite des routes, ...). Des outilspermettent egalement de generer des graphiques divers. Enfin, la notion de mobilite virtuelle estdefinie et peut etre calculee et affichee. Elle est calculee a partir des informations de niveau de signalissues des Wireless Tools et les transpose en une information de distance percue qui possede unegrande representativite du scenario etudie (les mobiles dont on recoit les paquets avec un niveaude signal faible sont consideres comme loin).

Bien que virtuellement n’importe quelle application reseau puisse etre utilisee, dans les articlessur APE dont nous avons connaissance, les donnees envoyees sont des paquets ”ping” ICMP envoyesa intervalles reguliers. Des flux avec des trafics si reduit sont couramment utilises dans les simulationdestinees a tester les protocoles de routage (comme nous l’avons deja mentionne dans le chapitre 4),mais ne donne malheureusement pas forcement une bonne idee de ce qui se passe si le reseau estensuite charge par une application quelconque.

Il faut noter que APE fournit aussi un utilitaire (mackill) permettant d’instaurer une topologievirtuelle en forcant certaines machines a ignorer les paquets venants de certaines autres. Ceci estparticulierement utile pour tester certains comportements des protocoles de routage sans avoir adeplacer tous les mobiles dans la position multi-sauts adequate. Ce mecanisme a une contrepartiecependant : les effets des interferences (de l’environnement et des mobiles entre eux) sur les pro-tocoles de routage ne seront pas forcement realistes. Par exemple, il est possible de simuler unechaıne de 10 sauts en gardant tous les mobiles dans une seule piece, mais il n’y aura alors aucunereutilisation spatiale : un seul mobile pourra emettre a un instant donne .

7.3 Description de l’outil forwarding

Nous avons vu que les outils disponibles etaient surtout orientes sur l’evaluation de solutionscompletes (mobiles equipes de cartes radio utilisant des protocoles de routage ad hoc et faisantfonctionner de vraies applications). Puisque nous voulions isoler les effets de 802.11 de ceux desautres couches, cela ne correspondaient pas vraiment a nos besoins. Plutot que de chercher amodifier des programmes existants, nous avons prefere developper un nouveau logiciel, qui se voulaitsimple et specialement adapte a nos mesures. Les caracteristiques retenues etaient les suivantes :

Un programme simple. Comme nous cherchions a realiser quelque chose de simple, le pro-gramme (appele forwarding) a ete ecrit en langage C. Il fonctionne sous linux, et s’appuie sur leswireless tools [69]. Pour des raisons pratiques, le programme a ete installe sur un cdrom bootablede linux, accompagne des outils necessaires pour sauvegarder temporairement les resultats sur despartitions aussi bien linux que windows. Il etait ainsi assez aise de realiser nos mesures sur diversportables, en fonction de ce que l’on pouvait emprunter le jour de l’experience (dans certainesmesures, nous avons utilise jusqu’a 8 portables simultanement). A la fin de l’experience, les fi-chiers de resulats (qui pouvaient occuper plusieurs centaines de mega-octets) etaient centralisessur une machine fixe avant d’etre depouilles. A noter egalement que la version de linux sur le CDetait minimaliste, afin d’eviter des interferences avec des demons ou autres processus utilisant desressources.

Le programme lui-meme, une fois lance, presente une simple ligne de commande ou l’utilisateurpeut a loisir configurer divers parametres, afficher en temps reels des informations sur les paquetsrecus, et surtout demarrer ou arreter des sources de donnees.

86


Pas de protocole de routage. Nos objectifs initiaux etaient entre autres de mesurer les in-terferences entre nœuds voisins lorsque l’on realise des communications multi-sauts, et nous comp-tions pour cela nous appuyer sur les communications en mode diffusion (broadcast) des cartes 802.11.L’idee etait qu’au niveau de chaque nœud on pourrait ainsi recevoir et garder une trace des paquetsqui ne nous etaient pas reellement destines et qui etaient neanmoins recus avec suffisamment depuissance. Ceci avait pour but de rendre l’analyse plus facile et plus complete.

Afin de gerer les communications multi-sauts, notre programme avait donc la charge d’effectuerou non une re-emission des paquets, en fonction de regles etablies prealablement a la mesure. Cesregles de re-emission (ou de routage statique) avaient comme autre objectif de nous liberer deseffets non desirables que les protocoles de routage normaux pouvaient provoquer dans nos mesures.Comme nous nous concentrions sur l’etude de 802.11, les time-out, la selection non controlee desroutes ou les paquets de controle generes par un protocole de routage auraient brouille nos mesureset rendu les resultas difficilement exploitables.

Ces regles de routages conditionnaient la re-emission des paquets recus en fonction d’identifiantsde flux portes par les paquets et / ou des nœuds desquels ils nous arrivaient (champ last-hop dansl’entete des paquets).

Des flux UDP a debit constant. La encore, nous voulions nous affranchir au maximum des pro-tocoles superieurs a 802.11 qui auraient pu masquer certains resultats. TCP en particulier presentaitde nombreux problemes. D’une part il generait du traffic supplementaire dans les deux sens (ac-quittements et autres paquets de controle), mais en fonction de la taille des fenetres d’emission etde l’arrivee a temps ou non des acquittements, TCP risquait en plus de detecter une congestion dureseau et d’y reagir en modifiant encore la taille de sa fenetre. Il serait alors devenu particulierementdifficile de savoir si un paquet quelconque avait ete vraiment perdu suite a un probleme au niveaude 802.11 ou si on avait eu affaire a l’arrivee en retard d’un acquittement par exemple. Il aurait eteegalement tres difficile avec seulement quelques machines de mesurer les effets de la saturation dela bande passante physique (si TCP decide de tres fortement reduire la taille de sa fenetre suite aquelques pertes interpretees comme de la congestion, alors le canal radio sera sous-utilise).

Nous avons donc prefere n’utiliser qu’UDP, qui nous permet un bien meilleur controle despaquets effectivement envoyes dans les air. Sur chaque nœud, jusqu’a 10 sources UDP a debitconstant peuvent etre configurees. Chaque source se voit attribuer un numero de flux unique al’echelle du reseau qui permet d’identifier les paquets de maniere unique. La taille des paquetsenvoyes ainsi que le debit de ces sources sont configurables de maniere tres precise.

Des fichiers de trace detailles. Chaque reception de paquet par un nœud est consignee dans unfichier de trace, avec la date locale precise du nœud ainsi que des informations diverses (numero desequence, nom de l’emetteur originel, nom du dernier re-emetteur (last-hop), taille, ...). Un fichierde trace optionnel peut contenir des informations complementaires sur le niveau de signal pourchacun de ces paquets. Mais il s’agit de l’information retournee par le pilote de la carte 802.11 etpar consequent elle n’est mise a jour qu’a chaque reception de paquet (cela signifie que forwardingn’est pas capable d’indiquer le niveau de bruit ambiant en dehors des moment ou il recoit despaquets, entre autres). Une fois les mesures terminees, les differents fichiers de trace sont regroupeset combines. Ensembles ils permettent de reconstituer l’historique precis de tout ce qui s’est passedans le reseau. Les problemes d’horloge sont geres par forwarding. Des outils de synchronisation luisont integres et seront detailles par la suite.

87


Il faut noter que notre programme n’utilise pas de mecanisme particulierement optimise pourla sauvegarde des informations au fur et a mesure de le l’experience. Dans la pratique, dans lespires cas un nœud n’avait a ecrire que quelques dizaines de milliers d’octets par seconde. Ecriredirectement sur le disque (qui de toute facon dispose de tampons geres par le systeme et de tamponsinternes) etait donc suffisant pour nos besoins. Nous n’avons pas utilise de mecanisme avance telque la sauvergarde dans un disque virtuel en memoire vive, qui aurait de toute facon ete trop petitpar rapport a la quantite de donnees recoltees dans certaines de nos mesures les plus longues.

7.3.1 Architecture du logiciel

Forwarding est un programme multi-threads. Au demarrage du programme un ensemble dethreads est initialise.

L’un d’eux va servir pour les receptions. Il est en attente constante de paquets venant dureseau. Lorsqu’un paquet arrive, il applique des regles de filtrage (en particulier un nœud recoit lespaquets qu’il a lui-meme diffuse et il faut les eliminer), puis il inscrit ce paquet dans son fichier detrace, avant de le traiter et eventuellement de le re-emettre. Ce thread s’occupe aussi de la gestionde l’interface avec l’utilisateur (affichage periodique d’informations et lecture des commandes auclavier et / ou dans des scripts).

Les autres sont utilises pour generer le traffic Le fait d’utiliser un thread separe pourchaque flux evite de mettre en place un systeme complexe d’ordonnanceur, mais en contre-partieune legere latence peut etre introduite a cause de changements de contexte. Heureusement sonimpact est negligeable sur des machines comme celles que nous avons utilisees (au minimum desPentium II a 300 MHz).

Dans forwarding, le temps est compte en secondes a partir du lancement du programme. Parexemple, on peut demarrer un flux a la seconde 100 et l’arreter a la seconde 150. Evidemment,puisque le programme n’est pas lance exactement au meme moment sur chacune des machines, il ya une certaine desynchronisation. Ce probleme est en partie resolu grace a la possibilite de diffuserun paquet special qui force un changement de la date locale au moment de sa reception. L’idee estque lorsque qu’un paquet est diffuse, tous les nœuds du voisinage le recoivent au meme moment.L’envoi de ce paquet appele SYNC est une chose a faire au debut de chaque mesure (si des paquetsont ete envoyes avant, il faudra les eliminer des traces car il ne seront pas dans la meme echelle detemps).

Il faut noter aussi que si le programme a ete originellement concu pour envoyer les paquetsen mode diffusion, il est neanmoins capable de les envoyer en unicast. Cela est en particuliernecessaire lorsque l’on veut mesurer l’impact des acquittements, des RTS/CTS, ou des debits phy-siques superieurs a 2Mbit/s (la diffusion est limitee par la norme 802.11 a 2Mbit/s). Les commandesde creation de source ou de mise en place de regles de repetition prennent une adresse IP en pa-rametre optionnel. Mais de ce fait il est important qu’avant la mesure proprement dite tous lesnœuds aient ete a portee de communication et que des paquets aient ete echanges (ping rempli tresbien ce role). Cela permet a ARP construire sa table d’adresses MAC des cartes des autres nœudset evite que les requetes ARP soient ensuite melees aux paquets de donnees.

88


Type Paquet

Id Destination Id Dernier Emetteur

Id Source

Num. Seq. Emetteur Num. Seq. Flux

Taille des DonnéesNuméro Flux

0 84

Fig. 7.1 – Format de l’en-tete utilisee par forwarding pour tous ses paquets

Nom de l’option Effet-id determine l’identifiant unique du nœud-traceFile specifie le nom du fichier de trace a utiliser-qualityTraceFile active l’enregistrement des informations de niveau de signal et de bruit-script demarre automatiquement le script specifie apres le lancement du programme-traceSelfDiscard En mode diffusion, les nœuds recoivent et eliminent leurs propres paquets.

Cette option permet de memoriser quand meme ces paquets.

Tab. 7.1 – Principales options de lancement

7.3.2 Format des paquets

Tous les paquets utilises par forwarding partagent une en-tete commune (voir figure 7.1) ou sontdecrits leur type (DATA ou les diverses variantes de paquets de controle ou de synchronisation),leur source, leur destination, leurs numeros de sequence et leur taille. Cette en-tete a une taillefixe de 32 octets et il faut noter que les tailles de paquets donnees sur les nombreuses courbes quiseront presentees plus tard n’incluent pas toujours cette en-tete (l’inclusion ou non de l’en-tete dansles valeurs mesurees sera precisee pour chaque courbe). Les nœuds sont identifies sous forwardinggrace a un numero unique donne manuellement au lancement du programme. Lors du demarraged’une source de donnees, un numero de flux est attribue manuellement a cette source et on peutainsi retrouver facilement tous ses paquets (pour les paquets de controle, le numero de flux estarbitrairement fixe a zero). Deux numeros de sequence sont geres : l’un est propre au nœud et estincremente a chaque fois qu’il envoie un paquet, quel qu’en soit le type, l’autre est propre a chaqueflux, et n’est incremente que lors de l’envoi de paquets appartenant a ce flux. Le champ du dernieremetteur est evidemment mis a jour a chaque re-emission du paquet.

En plus de leur en-tete, les paquets comportent un champ de donnees (dont la taille est specifieedans l’en-tete). Dans le cas des paquets de controle, ce champ contient une commande ou un resultatd’execution, dans le cas des paquets de donnees, ce champ est rempli de zeros pour constituer lacharge utile.

7.3.3 Les commandes disponibles

Un certain nombre d’options peuvent etre specifiees au lancement du programme, les plusimportantes sont presentees dans la table 7.1

89


Une fois le programme lance, une ligne de commandes est presentee a l’utilisateur. Les princi-pales commandes sont detaillees dans la table 7.2.

Avec forwarding nous avons donc a disposition un outil qui va nous permettre de tester desscenarios sur des reseaux ad hoc et de mesurer les performances de 802.11 sans etre perturbes parles protocoles des couches superieures.

90


Nom de la commande Descriptionsync [time] synchronise les horloges sur toutes les machines

a portee.setTime time definit le temps local.time affiche le temps local.affichePaquetsRecus 0 | 1 chaque seconde, affiche combien de paquets ont

ete recus, de qui, et a quels flux ils appar-tiennent.

pingAll diffuse un paquet ping auxquels tous les nœudsdoivent repondre par une paquet pong.

startCBR numSourceThread flowID idSourcedelay packetSize [destinationIP]

demarre un flux CBR. L’emetteur, la taille dupaquet, le delai entre deux paquets consecutifset le numero de flux doivent etre specifies. Uneadresse IP optionnelle peut etre utilisee pourforcer l’envoi a un destinataire unique.

stopCBR numSourceThread numNode arrete un flux CBR specifie par le numero dunœud et le numero du thread source qui legenere.

addForwardingRule idNode flowID IDLas-tHop [destinationIP]

les paquets ayant le numero de flux et l’iden-tifiant de dernier nœud traverse identiques aceux specifies seront repetes. Une adresse IPoptionnelle permet de forcer la re-emission versune cible unique.

deleteForwardingRule idNode flowID ID-LastHop

efface une regle etablie grace a la commandeprecedente.

execScript scriptName execute le script specifie.execCommand shellCommand execute la commande shell specifiee.setPhyTraceList adresses IP les wireless tools ne ”remontent” les informa-

tions de qualite de signal et de bruit que pourles nœuds dont les adresses ont ete specifiees.

Tab. 7.2 – Les commandes les plus representatives

91

CHAPITRE

8 Les premieres mesures

Au fur et a mesure du developpement de forwarding, nous avons realise des mesures ; ellesavaient le triple but de tester le programme, d’evaluer 802.11 dans un environnement ad hoc reel,mais aussi de comparer a la realite les simulations que nous avions realisees auparavant avec NetworkSimulator.

8.1 Justifications des donnees mesurees.

Par la suite, nous allons regulierement presenter des courbes montrant differentes valeurs me-surees au cours de nos experimentations. Il est important de preciser de quelle maniere ces valeurssont obtenues et, le cas echeant, calculees.

Les debits. Pour un flux donne nous avons vu que les paquets ont toujours la meme taille.Lorsque nous analysons les fichiers de trace, nous comptons le nombre de paquets par unite detemps repondant a un meme critere (au moins le numero de flux, mais parfois plus, comme parexemple le last-hop) et nous multiplions par la taille des paquets.

Les durees de transmission. Nous presenterons parfois des histogrammes decrivant la distri-bution de la duree de transmission des paquets. Dans la pratique, nous n’avons pas de moyen demesurer directement une telle duree. Nous savons a quel moment l’application envoie le paquet aupilote, et nous savons a quel moment le paquet est recu par l’autre mobile ; par contre nous nesavons pas a quel moment la carte 802.11 a reellement emis le paquet (si elle a trouve le canal radiooccupe, elle a pu attendre un certain temps avant qu’il ne devienne libre pour elle). Pour realiser leshistogrammes que nous presentons, nous nous sommes donc toujours place dans une situation ouune seule source saturait completement la bande passante, et ou aucune interference externe n’etaitpresente. Comme le canal etait completement sature, il devenait possible de connaıtre la duree detransmission en faisant la difference entre les dates de reception de deux paquets consecutifs.

8.2 Le debit en fonction de la taille des paquets

Notre toute premiere experience consiste a mesurer le debit effectif dans la configurationpresentee sur la figure 8.1, ou un emetteur envoie des paquets a un recepteur situe juste a cotede lui.

Les paquets UDP comportent un champ de donnees d’une taille comprise entre 82 et 2532octets, par increment de 50 octets. La figure 8.2 presente les resultats des mesures pour differentes

92

CHAPITRE 8. LES PREMIERES MESURES

Fig. 8.1 – Configuration pour lamesure du debit en fonction de lataille des paquets (bande passantesaturee)

0

100000

200000

300000

400000

500000

600000

700000

800000

0 500 1000 1500 2000 2500 3000

debi

t en

octe

ts p

ar s

econ

detaille des paquets UDP

11MBit/s avec WEP11MBit/s sans WEP

5.5MBit/s2MBits/s1MBits/s

Fig. 8.2 – Debit utile en fonction de la taille des paquetsUDP

vitesses de transmission, ainsi que lorsque l’on utilise le systeme de cryptographie WEP (WiredEquivalent Privacy) decrit la norme 802.11. Les observations sont les suivantes :

8.2.1 La fragmentation a 1500 octets

La premiere chose que l’on remarque est le phenomene de decrochement lorsque la taille despaquets depasse les 1500 octets. Ce phenomene est lie a la couche IP qui croit avoir affaire a une carteEthernet (802.3) et qui cherche a optimiser la taille des paquets pour eviter une refragmentation(avec Ethernet, la taille maximale d’une trame est de 1500 octets environ, alors qu’avec 802.11 elleest de 2432 octets). Ici, cette optimisation est malvenue et fait visiblement chuter le debit.

8.2.2 L’impact du WEP

On remarque en second l’impact de l’utilisation de la cryptographie WEP. A 11 Mbits/s, pourdes tailles de paquets superieures a 1000 octets environ, les performances deviennent sensiblementinferieures a ce qu’elles sont si on n’utilise pas le WEP (la courbe de debit paraıt ecretee). Nousavons realise de nombreuses experiences pour comprendre ce phenomene qui etait tout a fait re-productible mais qui ne concernait que les communications a 11 Mbits/s et pas celles aux debitsinferieurs. La source du probleme apparaıt mieux lorsque l’on presente la distribution des durees detransmission des paquets. La figure 8.3 montre deux histogrammes representant chacun les dureesde transmissions pour une douzaine de milliers de paquets de 900 et de 1400 octets. La taille de900 octets a ete choisie car d’apres la figure 8.2 les flux de paquets de cette taille ne subissent pasde perte de debit du au WEP. La distribution theorique est un rectangle (ce qui est normal etantdonne que la duree de transmission d’un paquet d’une certaine taille est composee d’une partie fixeet du backoff qui est tire de maniere aleatoire et equiprobable entre deux bornes). La distributionmesuree pour des paquets de 900 octets est proche de la distribution theorique. On peut justeremarquer un biais du generateur aleatoire qui fait que les paquets ayant des backoffs tres courts

93


0

100

200

300

400

500

600

700

0 0.0005 0.001 0.0015 0.002 0.0025 0.003 0.0035 0.004 0.0045 0.005 0.0055

num

ber

of p

acke

ts

time elapsed since last packet (in seconds)

900 bytes packets900 bytes packets (theoretical)

1400 bytes packets1400 bytes packets (theoretical)

Fig. 8.3 – Effet du WEP sur la duree de transmission d’une trame

sont un peu plus nombreux que la moyenne. A ce sujet on peut noter que des cartes presentantce type de biais beneficie d’un debit legerement superieur a celui de carte ayant une distributionplus equitable (en moyenne elles attendent en petit peu moins longtemps avant d’envoyer leursdonnees). Par contre dans un environnement ou toutes les cartes ont ce biais, cela va se traduirepar une hausse du taux de collision. Ceci est une chose a garder a l’esprit lorsque l’on compare lesperformances des cartes de differents constructeurs.

Toujours d’apres la figure 8.2, des problemes apparaissent pour les paquets de plus de 1000octets et sont le plus importants juste avant que la fragmentation n’entre en jeu (vers 1400 octets).La distribution des durees de transmission des paquets de 1432 octets reflete et permet d’expliquerce phenomene. La distribution theorique tout d’abord est logiquement decalee vers la droite (dureede transmission en moyenne plus longue que celles de paquets de 1032 octets), puisque la partiefixe de la duree de transmission d’un paquet depend de sa taille. Mais on remarque tout de suitedeux sous-ensembles dans les durees de transmission effectives. Un certain nombre de paquetsont ete transmis en un temps conforme aux previsions, mais les paquets du deuxieme groupe ontmis beaucoup plus de temps. De plus l’etalement du deuxieme groupe (double de l’etalement dupremier) et sa position (deux fois plus loin) indiquent clairement que ces paquets n’ont etes recusqu’apres une re-emission (le backoff est tire deux fois, d’ou l’etalement double).

La raison profonde de cette re-emission nous est pour l’instant inconnue, le mecanisme du WEPn’etant pas sense poser ce genre de probleme. Malheureusement le WEP est implante dans le BIOSdes cartes 802.11 et n’y ayant pas acces nous n’avons pas pu pousser plus loin nos investigations.Peut-etre ce probleme se pose-t-il lorsque que le processeur embarque sur la carte arrive a ses limites(cryptage/decryptage de gros paquets au debit maximum supporte). Quoi qu’il en soit, dans la suitede nos experimentations nous avons decide de ne plus utiliser le WEP.

94


0

1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

0 500 1000 1500 2000 2500 3000 3500

Deb

it en

bits

par

sec

onde

Taille des paquets UDP

11 MBit/s avec WEP mesure11 MBit/s sans WEP mesure

11 Mbit/s theorie5.5 MBit/s

5.5 Mbit/s theorie2 MBits/s

2 Mbit/s theorie

Fig. 8.4 – Comparaison des debits theoriques et mesures a differentes vitesses et en fonction de lataille des paquets.

Remarquons que si sur la figure 8.2 l’effet negatif du WEP a 11 Mbit/s paraıt moins sensiblepour les paquets de plus de 1500 octets que pour ceux de 1500 octets ou un peu moins, cela estsimplement du au fait que ces paquets UDP de plus de 1500 octets sont divises en un gros paquetqui 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 leniveau de securite du WEP est en realite assez faible.

8.2.3 Hormis les problemes pre-cites, des debits tres proches de la theorie

Les debits mesures sont donc extremement proches des debits calcules par la theorie, comme onpeut le voir sur la figure 8.4. Mais on peut cependant noter que les debits utiles sont tres eloignesdes debits physiques. Cela est specialement flagrant lorsque l’on utilise des paquets de petite taille(le debit utile avec des paquets de 82 octets et plus de 7 fois inferieur au debit utile avec des paquetsde 1432 octets) ou que la fragmentation a 1500 octets force la division de gros paquets en un paquetde 1500 et en un autre plus petit (le debit diminue de 50% environ lorsque la taille passe de 1450a 1500 octets)

95


8.3 Partage du canal entre nœuds a portee de communication

8.3.1 Deux flux (combinaisons d’emetteurs et recepteurs)

Apres nous etre interesses a la capacite du canal lorsqu’il n’y a qu’un seul emetteur, nous noussommes ensuite tournes vers des scenarios ou plusieurs emetteurs proches les uns des autres sonten contention pour l’acces au medium.

Nous avons tout d’abord utilise quatre mobiles situes dans la meme piece (et donc a portee decommunication directe), et nous avons realise les diverses combinaisons de flux presentees sur lafigure 8.5. Les flux de donnees etaient constitues de paquets UDP de 1000 octets, envoyes aussi viteque possible. Les cartes etaient configurees pour fonctionner a 11 Mbit/s sans utiliser de RTS/CTS.

Les resultats de cette experience sont presentes sur la figure 8.6 et peuvent etre interpretes dela facon suivante (l’ordre n’est pas chronologique, mais presente les situations les plus simples enpremier) :

– secondes 175 a 195 : Il n’y a qu’un seul flux (de 3 vers 2), et donc aucune contention. Onobtient le debit maximum observe dans les experiences precedentes dans les memes conditions,soit un petit peu plus de 600 paquets de 1000 octets par seconde.

– secondes 120 a 125 et 150 a 165 : Il n’y a qu’un seul flux (de 1 vers 2 cette fois-ci). Onobtient la encore le debit maximum.

– secondes 100 a 120 et 125 a 150 : Il y a deux flux en contention. On observe la memechose que les recepteurs soient deux nœuds differents ou non. On remarque immediatementune difference de debit entre les deux flux (l’emetteur 1 accede un peu moins souvent au canalque l’emetteur 2). Les cartes 802.11 utilisees etaient a priori les memes, et ce phenomene peutprobablement etre impute soit a l’heterogeneite de nos machines, soit a des differences nondocumentees entre nos cartes (de meme marque et de meme modele). Il est important deremarquer que la somme des deux flux simultanes est legerement superieure au debit obtenupar un flux unique isole. Ce phenomene s’explique par la decrementation en parallele desbackoffs sur chacun des emetteurs. En effet, lorsque dans ce scenario le canal devient initiale-ment libre, les deux stations choisissent un backoff aleatoire et commencent a le decrementer.Des que l’une d’elles a termine, elle emet et bloque la decrementation de l’autre station.Mais quand le canal redevriendra libre, l’autre station reprendra la decrementation la ou elles’etait arretee (au lieu de tirer un nouveau backoff), et statistiquement finira donc rapidementsa propre decrementation. Finalement, on observe une diminution de la duree moyenne dutemps d’inactivite separant deux trames (de sources differentes) sur le canal, et donc uneaugmentation du debit.

8.3.2 Flux multiples

Dans ce scenario, nous avons observe l’activite sur le canal radio alors qu’un nombre croissantde flux etaient en contention pour y acceder. Comme precedemment, les mesures ont ete effectueesavec des paquets UDP, les RTS/CTS n’etaient pas utilises et le debit nominal etait de 11 Mbit/s.L’experience est divisee en 7 phases (voir figure 8.7, ou a chaque etape un flux supplementaire estactive), et ou chaque phase est elle-meme divisee en 5 periodes de 20 secondes ou les flux sontconstitues de paquets d’une taille donnee (200, 500, 1000, 1400 et 2000 octets, dans cet ordre).

La figure 8.8 presente les debits agreges en paquets par seconde (c’est a dire la somme des debitsdes differents flux). Comme on pouvait s’y attendre, on voit bien que pour une etape donnee, plus

96


3 −> 2

1 −> 2

3 −> 4

3 −> 2

1 1 12 2 2 2

3343

time in seconds0 120 125 150 165 175 195

Fig. 8.5 – Deux paires a portee decommunication

0

100

200

300

400

500

600

700

100 120 140 160 180 200

num

ber

of p

acke

ts r

ecei

ved

per

seco

nd

time in seconds

flow 1 -> 2flow 3 -> 4flow 3 -> 2flow 3 -> 2

Fig. 8.6 – Debit quand deux paires sont a portee decommunication

2 4 5 6 7 83

1

301

201

301

401

501

601

701

801

time

201 401 501 601 701 801

Fig. 8.7 – Un a sept flux simultanes 0

200

400

600

800

1000

1200

1400

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

thro

ughp

ut in

pac

kets

rec

eive

d pe

r se

cond

number of simultaneous flows

200 bytes packets

Fig. 8.8 – Debits cumules pour un a sept flux se parta-geant le canal

97


0

200

400

600

800

1000

1200

1400

1600

1800

2000

0 0.0005 0.001 0.0015 0.002 0.0025 0.003 0.0035 0.004

num

ber

of p

acke

ts

time elapsed between 2 consecutives packets

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

les paquets sont petits, plus ils sont nombreux a etre envoyes au cours d’une seconde. Mais onremarque aussi que lorsque le nombre d’emetteurs en contention augmente, le debit total augmentelui aussi legerement. Ceci est du au phenomene detaille dans l’experience precedente. Lorsque lecanal devient libre, tous les nœuds ont des paquets a envoyer, et decrementent donc leur backoffen parallele. Plus il y a de flux en concurrence, plus les chances sont grandes que l’un d’eux ait unbackoff restant court, et donc que le canal soit rapidement reoccupe. L’effet est plus visibles avecdes paquets de petites tailles, puisqu’on en envoie plus par seconde et que l’on gagne ainsi du debitsur chacun de leurs backoffs. Evidemment, ce phenomene est progressivement contrebalance par lescollisions. Plus il y a de flux en contention, plus les chances sont grande que deux nœuds aient finien meme temps de decrementer leurs backoffs et emettent en meme temps. A partir de cinq flux encontention, le debit global n’augmente donc plus.

La figure 8.9 presente la distribution du temps separant deux paquets consecutifs de 1000octets lorsque 7 emetteurs sont en contention. Contrairement a ce que l’on avait pu observer dansla figure 8.3 ou il n’y avait qu’un seul flux et ou la distribution etait assez homogene, ici on voit unregroupement des ecarts vers les valeurs les plus basses (la duree minimale de transmission de nospaquets, lorsque le backoff tire est nul, est de 1300 µs environ, et d’un peu plus de 1900µs lorsquequ’il est maximal et qu’il n’y a pas eu de collision avant). Ceci est tout a fait en adequation avecnos remarques precedents sur l’augmentation du debit lorsque le nombre de flux augmente.

En sus du pic principal, on remarque qu’un certain nombre de paquets on ete transmis en untemps environ double par rapport a la majorite (pic vers 2.5 ms). Ces paquets sont en fait ceux quiont subi une collision et qui ont du etre reemis. Dans ce graphique, dans 93.25% des cas, le tempsseparant deux paquets consecutifs etait de moins de 2000 µs. Cela signifie que le taux de collisionetait finalement assez faible malgre la presence de 7 emetteurs (6.75% seulement des paquets onteu besoin d’une reemission).

8.4 Les mesures de portee

L’etape suivante dans l’analyse du comportement de 802.11 dans le contexte des reseaux ad-hocest l’etude de la portee de communication reelle. Nos objectifs a plus long terme etaient evidemment

98


de realiser des mesures dans des configurations typiquement ad-hoc telles qu’une chaıne, et la porteede communication est une donnee dont nous avons besoin pour preparer ces futures mesures.

Nous avons vu dans le chapitre qui leur est dedie que les simulateurs considerent en generalque les zones de communication sont circulaires et centrees sur le mobile (avec des variantes, telleque le modele shadowing qui ajoute une probabilite de perte des paquets sur le bord de ce cercle).Les experiences decrites dans ce chapitre avaient pour but de comparer la realite avec ces resultatstheories.

8.4.1 L’environnement et le outils de mesure

Le materiel utilise. Comme dans les autres experiences, nous utilisons forwarding sur des por-tables PC demarres avec notre CD de linux. Des ces premieres experiences en exterieur, il estimportant de noter que le materiel joue un grand role. La longevite des batteries en particulier estlargement affectee par la temperature, et il faut en tenir compte lors de la conception des scenariosde mesure et des scripts de commandes. Les cartes radio utilisees sont des cartes Orinoco ou Wave-Lan de Lucent Technologies, elles emettent avec une puissance de 15 dBm et utilisent leurs antennesintegrees.

L’environnement. L’environnement n’est jamais neutre ; comme ces mesures de portee sontpreparatoires pour des mesures sur des configurations veritablement ad hoc, nous avons choisi deles effectuer en exterieur, dans un environnement suffisamment degage. Nous avions en effet effectuedes mesures prealables en interieur, et il etait rapidement apparu qu’il etait impossible d’y mettreen place une configuration avec une chaıne d’une longueur superieure a deux sauts (notre batimentest trop petit, et il est impossible de placer des mobiles de telle sorte qu’ils ne puissent communiquerqu’avec leurs voisins directs. Quoique nous fassions, chaque mobile peut atteindre n’importe quelautre en deux sauts maximum).

L’endroit retenu pour nos experiences est une piste cyclable le long d’un boulevard proche ducampus (voir la figure 8.10 pour la disposition et la figure 8.11 pour la photographie). Le principalavantage de ce lieu est la ligne de vue directe (environ 1km en ligne droite), avec une certainehomogeneite dans l’environnement (borde d’un cote par une route, de l’autre par un parc que l’onsurplombe de quelques metres). Le muret nous fournit le support pour poser nos portables.

8.4.2 Les resultats

Afin d’evaluer la portee de communication de nos cartes, nous utilisons deux portables ini-tialement tres proches l’un de l’autre et que l’on eloigne par etapes successives. La vitesse detransmission physique est de 11Mbit/s. A chaque etape, le mobile emetteur envoie a l’autre desrafales consecutives de paquets de differentes tailles (200, 500, 1000 et 1400 octets) et qui durentchacune une vingtaine de secondes. L’orientation des machine a un impact tout a fait remarquablesur les resultats, et nous repetons donc nos mesures dans diverses positions. Les debits obtenus enfonction de la distance, de la taille des paquets et de l’orientation des cartes sont presentes sur lafigure 8.12. Plusieurs remarques importantes peuvent etres faites :

– En fonction de l’orientation des cartes, la portee de communication varie grandement (d’unfacteur superieur a 2 entre la position la plus et la moins favorable). Cartes emettrices etreceptrices dos a dos, le debit utile est deja grandement affecte a une distance de 45 mettres,

99


route

routeterre-plein central

piste

muret

parc (en contre-bas)

Fig. 8.10 – L’environnement pour les mesures deportee

Fig. 8.11 – L’environnement pour les mesuresde portee

alors que face a face il ne commence a baisser qu’a partir de 75 metres et que les communi-cations restent possibles jusqu’a 150 metres environ. Sur les figures 8.14 et 8.15 sont indiquesles niveau de signal et de bruit mesures pour chacun des paquets correctement recus. On re-marque l’affaiblissement de la puissance du signal (de l’ordre de 10dBm en moyenne) lorsqueles antennes sont dos a dos (figure 8.14) plutot que face a face (figure 8.15). Il faut noteraussi que l’orientation de la carte receptrice est tout aussi importante que celle de la cartequi emet, comme on peut le voir avec les differences entre les mesures dans les positions 1 et2 de la figure 8.12.

– A part a courte distance ou l’on obtient bien celui prevu, une grande instabilite dans le debitutile apparaıt. A une distance fixee (par exemple 90 metres dans le cas des cartes face a face),le debit varie grandement en fonction du temps. L’environnement reel est loin d’etre stablecomme le predisent les modeles simples de propagation dans les simulateurs. La encore, cetteinstabilite est confirmee par les niveaux de signal et de bruit mesures (figures 8.14 et 8.15)qui varient dans une plage de 10 dBm a une distance fixee.

– Pour chacune des distances, les mesures ont ete effectuees avec 4 tailles de paquets differentes.On aurait pu penser que les gros paquets seraient plus affectes que les petits par la qualitedu lien radio car ils durent plus longtemps et auraient ainsi plus de chances de subir desinterferences. La figure 8.13 presente les memes donnees que la figure 8.12, mais avec unlissage (en ordonnee, on peut lire le nombre de paquets recus par intervalle de 4 secondesau lieu d’une seconde). A courte distance (15 a 60 metres), on remarque que les debits enpaquets par seconde diminuent avec la taille des paquets de maniere previsible. Mais plus loin(par exemple 90 ou 135 metres), on se rend compte qu’il n’y a pas forcement de relation entrela taille des paquets et le taux de perte. Ceci est important. On savait que les gros paquetspermettaient d’obtenir un debit utile superieur a courte distance, mais il apparaıt aussi qu’ilsne sont pas penalisants quand la distance augmente et que les interferences deviennent severes.

– Toujours sur la figure 8.12, on peut remarquer que le taux d’echec dans la reception resteparfois stable pendant certaines periodes. Par exemple a 75 metres dans la 5eme position,il semble qu’au milieu de la phase d’envoi des paquets de 200 octets les interferences soientsubitement devenues plus fortes. Une observation attentive des resultats montre que ce typede phenomene se produit a differentes echelles (parfois ce sont quelques paquets consecutifs

100


Position 1

0

200

400

600

800

1000

1200

15m 30m 45m 60m 75m 90m 105m 120m 135m 150mdé

bit e

n pa

quet

s re

çus

par s

econ

dedistance en metres

paquets de 200 octetspaquets de 500 octets


Position 2

0 100 200 300 400 500 600 700 800 900

1000

15m 30m 45m 60m 75m

débi

t en

paqu

ets

reçu

s pa

r sec

onde

distance en metres



Position 3

0 100 200 300 400 500 600 700 800 900

1000

15m 30m 45m 60m 75m 90m 105m 120m 135m 150m

débi

t en

paqu

ets

reçu

s pa

r sec

onde

distance en metres



Position 4

0 100 200 300 400 500 600 700 800 900

1000

15m 30m 45m 60m 75m 90m 105m

débi

t en

paqu

ets

reçu

s pa

r sec

onde

distance en metres



Position 5

0 100 200 300 400 500 600 700 800 900

1000

15m 30m 45m 60m 75m 90m 105m

débi

t en

paqu

ets

reçu

s pa

r sec

onde

distance en metres



Fig. 8.12 – Debits mesures en fonction de la distance, de la taille des paquets et de l’orientationdes antennes (vitesse d’emission de 11 Mbit/s)

qui sont perdus, parfois plusieurs dizaines voire centaines). Ce type de comportement ou leserreurs de transmission arrivent par rafale est different de ce que l’on peut observer avec lesmodeles classiques de propagation dans les simulateurs. Au mieux, le modele shadowing vaproduire par exemple un taux de perte non nul mais stable a une distance donnee.

La figure 8.16 presente quand a elle les debits mesures lorsque la vitesse d’emission est forceea 2 Mbit/s. La tendance generale en fonction de l’orientation des cartes est sans surprise assezsemblable 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 ados (position 2), et la position 6 permet une portee intermediaire. Mais si la tendance en fonctionde l’orientation est semblable, ce n’est pas le cas de la portee qui est logiquement beaucoup plusgrande. Cette fois-ci, des paquets peuvent etre recus jusqu’a 300 metres environ si l’orientation est

101


Fig. 8.13 – Debits lisses pour la position 3 et en fonction de la distance

Fig. 8.14 – Niveaux de signal et de bruit pourla position 2

Fig. 8.15 – niveaux de signal et de bruit pourla position 3

102


Position 2

Position 3

Position 6

Fig. 8.16 – Debits mesures en fonction de la distance, de la taille des paquets et de l’orientationdes antennes (vitesse d’emission de 2 Mbit/s)

favorable (position 3). On peut noter egalement que la portee reelle reste quand meme en generaltres nettement inferieure a celle prevue par la simulation. Rappelons que pour un debit physique de2 Mbit/s, le modele freespace de NS2 prevoyait une portee de 600 metres sans degradation, que lemodele shadowing prevoyait de ne pas avoir de degradation avant 250 metres et ensuite des pertesde plus en plus importantes jusqu’a 700 metres, et qu’enfin le modele two-ray ground prevoyait quejusqu’a 250 metres on pourrait avoir le debit maximum et plus rien au-dela.

Tout comme on avait pu le voir a 11 Mbit/s, on observe enfin une certaine instabilite a partird’une certaine distance (au-dela de 200 metres pour la position 3, au-dela de 100 metres pour laposition 6).

103

CHAPITRE

9 Les outils d’analyse avancee

Nous avons vu precedemment qu’un chronogramme pouvait etre un bon outil pour analyserfinement ce qui se passe, en particulier dans un reseau ad hoc. Nous cherchons donc a reproduirele meme 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 simules,des problemes se posent lorsque l’on passe a l’experimentation en environnement reel. Les horlogesdes differents portables ne sont pas synchronisees, et quelques experimentations nous montrentqu’elles derivent les unes par rapport aux autres d’une maniere que l’on ne peut negliger.

Afin de produire des chronogrammes utilisables, il nous est donc indispensable de comprendre,quantifier et corriger ces problemes.

9.1 Les chronogrammes en environnement reel

Les modifications que nous avons apportees a NS nous permettaient de recuperer directementtoutes les informations dont nous avions besoin pour tracer les chronogrammes. Par exemple, nousavions les dates de debut et de fin d’emission physique, les debuts, pauses, reprises, fins de backoffs,les DIFS, etc. En environnement reel, nous ne disposons que de la date de reception des paquets etde leur taille. Cependant, comme nous pouvons deduire la duree d’un paquet a partir de sa tailleet de la vitesse d’emission, il reste possible de construire un chronogramme utile bien qu’un peumoins complet. Certaines precautions doivent etre prises cependant, comme par exemple lorsque lespaquets sont envoyes en unicast et qu’il faut prendre en compte les acquittements qui n’apparaissentpas dans les traces.

9.2 Le probleme de la synchronisation

Dans forwarding, un mecanisme simple de synchronisation a ete integre tres tot. Il tire partid’une propriete des reseaux radio : tous les mobiles qui recoivent un paquet diffuse savent qu’ils lerecoivent a la meme date (il n’y a pas de re-emission, les delais de propagation des ondes sont touta fait negligeables dans ce contexte et le paquet envoye par forwarding contient sa date d’emission,ce qui permet d’ajuster les horloges des mobiles le recevant de facon a ce qu’elles soient toutessynchronisees). Si ce mecanisme est suffisamment precis pour les mesures de debit, il ne l’est pluslorsque l’on veut construire un chronogramme permettant de comparer precisement les dates dereceptions des paquets sur plusieurs mobiles (les debits sont en general exprimes en octets parseconde, des decalages de l’ordre du dixieme de seconde ne sont pas vraiment genants dans cecontexte).

104

CHAPITRE 9. LES OUTILS D’ANALYSE AVANCEE

Fig. 9.1 – Position des por-tables pour la mesure de ladesynchronisation

Fig. 9.2 – Derive des horloges en secondes (ordonnee)pour environ 14h30 (abscisse)

En effet, les horloges des portables n’avancent pas exactement a la meme vitesse. Nous avonspu le verifier en utilisant trois machines placees dans la configuration presentee sur la figure 9.1.On commence l’experience par l’envoi d’un message de synchronisation de forwarding, qui assurequ’a sa reception les dates sur chacune des machines sont identiques. Puis l’emetteur se met adiffuser des paquets de 1000 octets de donnees a une cadence reguliere. A la reception de cespaquets (numerotes), chaque recepteur l’estampille avec sa date locale. Nous soustrayons ensuite,pour chaque paquet, sa date de reception sur l’un des mobiles a sa date de reception sur l’autre.Idealement, la difference devrait etre nulle a chaque fois. Les paquets sont envoyes au rythme de10 par seconde et la mesure a dure environ 14h30 (soit un peu plus de 520000 paquets). Commeon peut le voir sur la figure 9.2, la difference est loin d’etre nulle puisqu’au bout de 14h30, les deuxrecepteurs sont desynchronises de 6.5 secondes.

On remarque immediatement l’apparente linearite de cette courbe, mais egalement la presencede decalages ponctuels plus et plus ou moins frequents. Ces decalages apparaissent quand, sur l’undes recepteurs, le processeur est occupe et le paquet est stocke quelques instants dans une memoiretampon avant d’etre traite et estampille. Comme le paquet est estampille ”en retard”, il sembleetre recu a une date tres differente vis-a-vis de l’autre recepteur. De tels ecarts sont genants pourles calculs, mais heureusement forts rares (quelques dizaines pour plus de 500000 paquets envoyes)et peuvent donc etre elimines avec un systeme de seuil. Si l’ecart entre deux paquets consecutifsest trop grand, on elimine le paquet ; on obtient ainsi la figure 9.3.

6.5 secondes de decalage en 14h30, cela correspond a environ 7.5 ms de decalage par minute.La duree de transmission d’un paquet de 1000 octets a 2 Mbit/s est d’un peu plus de 4 ms ; on serend bien compte que cette derive est trop importante pour etre ignoree lors de la creation de noschronogrammes et qu’il va falloir la corriger. La figure 9.4 montre le chronogramme representantles receptions des paquets diffuses tous les 1/10 de seconde lorsqu’aucune correction de la derive

105


Fig. 9.3 – Derive filtree des horloges en secondes (ordonnee) pour environ 14h30 (abscisse)

Fig. 9.4 – Chronogramme de deux mobiles recevant des paquets diffuses lorsque la derive deshorloges n’est pas corrigee

106


Fig. 9.5 – Les strates et la redondance dans le systeme NTP

n’est appliquee ; le probleme y est flagrant, les paquets devraient etre recus exactement en memetemps.

9.3 Resolution du probleme de la synchronisation

9.3.1 Les differentes approches, les systemes existants

La synchronisation des horloges est un probleme important que l’on retrouve dans de nombreuxdomaine, non seulement les reseaux, mais aussi les systemes distribues ou les systemes temps reels.La synchronisation permet aux composants de maintenir leurs dates systeme suffisamment proches.Sa precision depend des algorithmes utilises, mais aussi de la topologie ou de la structure du reseau,des liens de communication, de la charge des machines, etc. Il existe de nombreuses methodes quisont proposees a chaque fois pour des domaines d’application bien specifiques.

NTP (Network Time Protocol) [70] C’est un protocole tres connu dans la synchronisation deshorloges de machines reliees a l’Internet. NTP permet de synchroniser l’horloge d’un ordinateur aveccelle d’un serveur de reference. Le protocole est organise de facon arborescente. La synchronisationse fait donc couche par couche, ou strate (voir figure 9.5). On distingue 16 niveaux de couches, le16eme niveau correspondant a une horloge non synchronisee. Dans la pratique on ne depasse guerela couche 5.

Les serveurs de niveau 1 se synchronisent sur une source de reference (horloge, recepteur detemps code, recepteur GPS). Ces recepteurs decodant les signaux radio de transmission de l’heurepar les sites officiels. Les serveurs de strate 2 se synchronisent sur les serveurs de strate 1, et suivantles configurations, entre eux. Les serveurs des strates 1 et 2 sont officiels et declares (exemples pour lastrate 2 : ntp.univ-lyon1.fr, bernina.ethz.ch, biofiz.mf.uni-lj.si, ntp0.strath.ac.uk, ntp1.strath.ac.uk).Les serveurs de strate 3 se synchronisent sur ceux de strate inferieure. Ils n’ont pas a etre declares ;tout site peut installer un serveur de strate 3, a la condition de prevenir les administrateurs des sitesde strate inferieure officiels. Les serveurs de strate 4 sont en general, a l’usage d’un reseau local.Et ainsi de suite pour les couches suivantes, jusqu’aux clients terminaux. Notons que les simplesclients ne sont pas autorises avant la strate 3.

Comme il l’est mentionne dans [71], dans les reseaux sans fil de capteurs l’utilisation de NTPs’avere difficile. Il faut un serveur de reference que toutes les machines puissent atteindre. Un reseauad hoc peut etre partitionne pendant des periodes plus ou moins longues, ce qui pose probleme. Dememe, la precision que l’on peut esperer de NTP dans le cadre d’un reseau 802.11 est en-dessousde nos besoin, du fait de l’incertitude sur la duree de transmission d’un paquet (backoff aleatoire,

107


collisions, pertes de paquets, re-emissions par la couche MAC). Une solution a notre problemeaurait ete d’installer un reseau filaire entre les machines de notre banc de test et de s’en servirpour synchroniser les horloges avec NTP. On aurait ainsi pu obtenir une precision de l’ordre de lamilliseconde qui aurait ete acceptable pour notre usage ; mais ce n’etait techniquement pas possiblepour les experiences en exterieur et sur des distances un peu grandes.

Des methodes generalistes Certains travaux (comme par exemple [72]) ont essaye de faire unesynthese sur les recherches dans le domaine de la synchronisation des horloges. Les auteurs ontclassifie les algorithmes de synchronisation en faisant une evaluation sur leur type (deterministe,statistique, probabiliste), de leur capacite a resister aux pannes (panne de processeur, d’horloge,de lien ou de transmission, ...), de la procedure de synchronisation (qui peut etre symetrique -tousles ordinateurs jouant le meme role - ou asymetrique - avec des serveurs par exemple). Les auteursdivisent la synchronisation en trois etapes :

– Determiner quand il faut synchroniser.– Estimer les valeurs des horloges distantes.– Corriger l’horloge locale apres avoir estime les horloges distantes.Ces trois etapes sont assurees par trois blocs differents et les algorithmes sont egalement

classifies en fonction des techniques utilisees dans chacun de ces blocs.

Neanmoins, ces travaux ne restent qu’au niveau de la presentation et de la classification desalgorithmes et ne specifient pas leur domaines d’utilisation. Les performances de ces algorithmes(precision de la synchronisation et nombre de messages a envoyer) dependent de facteurs commela derive maximale des horloges, le temps de transmission et la gigue des paquets, etc. De plus, cestechniques ont des contraintes qui ne sont pas forcement compatibles avec notre contexte d’utili-sation (par exemple elles peuvent necessiter une connectivite complete du reseau, la presence d’unsysteme de distribution de temps (GPS), ...). Par consequent, l’adaptation de ces techniques dansnotre contexte bien specifique aurait ete pour le moins hasardeuse et les resultats non garantis.

Synchronisation dans les reseaux de capteurs Le domaine des reseaux de capteurs [73]a toujours connu des problemes de synchronisation. Les applications deployees sur ces reseauximpliquent souvent la fusion de donnees qui necessite une synchronisation. Le protocole RBS (Re-ference Broadcast Synchronization), decrit dans [71], peut atteindre une precision de 1 µs dans unezone a un saut (tout les capteurs peuvent communiquer avec tous les autres). Son extension auxreseaux multi-sauts se fait au prix d’une degradation de la precision qui reste neanmoins de l’ordrede la micro-seconde. Dans le contexte multi-sauts, RBS necessite de maintenir une structure deroutage entre les zones de diffusion. Dans le cadre de notre travail, cela impliquerait d’introduireun protocole de routage ce qui viendrait perturber les mesures fines de 802.11 realisees dans lesscenarios.

Une synchronisation post facto est proposee dans [74] : une synchronisation est realisee justeapres une communication. Le but est d’eviter une consommation d’energie inutile pour une syn-chronisation permanente mais non necessaire. Neanmoins, cette synchronisation peut aussi avoirun impact sur les mesures que nous voulons realiser puisque chaque communication serait separeepar une synchronisation.

108


Une methode specifique L’auteur de [75] a presente une solution pour la synchronisation deshorloges dans le domaine des reseaux ad hoc. Cette solution suppose que la derivee de la datelocale d’une horloge C(t) en fonction du temps absolu est bornee :1− ρ ≤ ∆C/∆t ≤ 1 + ρ

Ces inegalites conduisent a une relation entre la date locale d’une machine et le temps absolu,et vice-versa. Grace a cette propriete et en representant la date locale par un intervalle de temps,les auteurs ont pu definir une loi permettant de transformer la date locale d’un machine en la datelocale d’une autre machine (toujours sous forme d’intervalle de temps) apres une transmission eten tenant compte de sa duree. Cette technique permet d’evaluer dans certains cas l’ordre des dateslocales [t1, t2] < [t3, t4] ou d’evaluer combien de temps s’est ecoule entre les evenements [t1, t2] et[t3, t4]. Cependant, il reste toujours de cas ou l’on ne connaıt pas l’ordre des evenements (quandles intervalles se chevauchent).

La precision de cette methode de synchronisation depend du delai de transmission ainsi que dunombre de sauts que la date locale a synchroniser doit traverser. Cela presente une limite lorsquel’on veut obtenir une precision de l’ordre du dixieme de milliseconde dans un reseau multi-sautsbase sur 802.11b, ou le delai de transmission n’est pas garanti (presence de backoff aleatoires) et oule nombre de sauts peut etre important. De plus, si le reseau est charge au moment de l’echange despaquets de synchronisation, alors les delais de transmission pourront etre tres fortement affectes(retards pouvant depasser les dizaine de millisecondes), et la precision de la synchronisation seratrop faible.

9.3.2 Premieres constatations et methode simple

Sur la figure 9.3, on constate que la derive des horloges semble linaire. Nous avons effectued’autres mesures, et si l’ampleur de la derive varie (en fonction de l’anciennete des machines enparticulier elle evolue entre 0.3 et 7.5 ms par minute), nous observons toujours des courbes qua-siment lineaires. Rappelons que nous ne sommes pas specialement interesses par un algorithme desynchronisation en temps reel des horloges. Nous voulons surtout pouvoir mener une analyse post-mortem des resultats, et donc une synchronisation a posteriori (ou encore ”recalage” de fichiers detrace) est tout a fait acceptable. Notre premiere approche consiste donc a considerer que la deriveentre deux horloges est approximable par une droite. Ainsi il est possible de choisir une horlogecomme reference absolue, et de corriger grace a des coefficients lineaires les horloges de toutes lesautres machines pour les ramener dans le meme temps. Il suffit de calculer une fois pour chaquemachine le coefficient avec lequel elle derive par rapport a la reference, puis d’appliquer ce coefficienta chaque resultat de mesure.

Par exemple, on peut considerer l’horloge A d’un mobile qui derive de facon lineaire de 7 mspar minute par rapport a l’horloge B d’un autre mobile choisie comme reference. La pente de ladroite sur la figure 9.6 est de 7.10−3/60 en fonction de tA. Une date tAE d’un evenement E fourniepar l’horloge A pourra etre ramenee a la valeur

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

qui est la date de E dans le temps de reference.Dans un but d’evaluation, nous avons applique cette methode sur les donnees obtenues

precedemment afin d’ajuster les dates de reception des paquets diffuses. Le coefficient d’ajuste-

109


temps local

tA - t

tAt = 0

Fig. 9.6 – Un coefficient lineaire pour passer du temps local ou temps de reference

ment est calcule de la maniere suivante : apres filtrage des paquets ayant ete recus avec un tempsles separant de leur predecesseur s’ecartant trop de la moyenne, nous prenons un point en debutde courbe, un autre en fin de courbe, et nous calculons le coefficient directeur de la droite passantpar ces deux points.

Une fois le coefficient calcule et applique, nous avons analyse l’erreur de synchronisationresiduelle. L’erreur maximale etait 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 presentee sur la figure 9.7. Cet histo-gramme montre que l’ecart de synchronisation, bien qu’enormement reduit, reste non negligeable(beaucoup de paquets ont une erreur depassant les 2 ms, a mettre en rapport avec les seulement4 ms qui dure la transmission d’un paquet). De plus, les paquets presentant les erreurs les plusimportantes sont le plus nombreux. La methode de l’approximation par une droite est tres simple,mais ne donne pas des resultats suffisamment precis et nous avons du developper une autre methodeutilisant une droite affine par morceaux.

9.3.3 Deuxieme methode : approximation de la derive des horloges par unedroite affine par morceaux

En reprenant les mesures precedentes (figure 9.3), plutot que de calculer le coefficient direc-teur d’une unique droite cherchant a approximer l’ensemble de la courbe, nous travaillons sur dessegments plus ou moins longs. Pour chacun de ces intervalles, nous approximons la courbe parune droite dont nous calculons le coefficient directeur de la meme maniere que precedemment (ladroite choisie est celle qui passe par le premier et le dernier point de l’intervalle). La precision de lamethode est ainsi dependante de la longueur que l’on choisit pour les tranches. Nous avons effectueles calculs pour plusieurs longueurs differentes (pour un calcul donne, toutes les tranches ont lameme longueur). Les erreurs maximales et moyennes en fonction de la longueur des intervalles sontpresentees dans la table 9.1.

L’histogramme de la figure 9.8 presente la distribution de l’erreur de synchronisation de plusde 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 inferieure a 0.054 ms, leserreurs importantes etant extremement minoritaires. Lorsque l’on prend en compte le fait que letemps de transmission d’un paquet de 1000 octets est d’environ 5 ms a 2 Mbit/s et de 1.6 msa 11 Mbit/s, alors il apparaıt que l’utilisation de synchronisation toutes les 20 minutes environdonnera des resultats suffisamment precis pour nos besoins. Il faut noter que la grande precision

110


Fig. 9.7 – Distribution de l’erreur residuelle avec l’approximation par une droite (nombre de paquetsen ordonnee, erreur en ms en abscisse)

Longueur de l’intervalle Erreur maximale Erreur moyenne5 min 0.23 ms 0.38 µs20 min 0.31 ms 4.4 µs30 min 0.44 ms 10 µs60 min 0.62 ms 30 µs

Tab. 9.1 – Precision 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 environ520000 paquets (nombre de paquets en ordonnee, erreur en abscisse)

de cette methode vient de la propriete des reseaux radio que l’on exploite : plutot que de cherchera maintenir a jour l’heure sur chacune des machines en temps reel (comme le ferait NTP) grace ades echanges de paquets, nous utilisons le fait que lorsqu’un paquet est diffuse en radio, il est recusimultanement par toutes les machines environnantes.

D’un point de vue pratique, cette methode de synchronisation des fichiers de trace fonctionnede la maniere suivante :

– Au debut de la mesure, mise a zero de l’horloge de toutes les machines (paquet de syn-chronisation special de forwarding, qui necessite que toutes les machines soient a portee decommunication a cet instant de celle qui envoie le paquet).

– Mesures diverses, pendant lesquelles les machines peuvent se deplacer, le reseau peut etrepartitionne, etc.

– Toutes les 20 minutes environ, arret des mesures, regroupement de l’ensemble des machinesa portee de celle qui synchronise et diffusion par celle-ci d’un paquet qui sera recu par toutesles autres et qui delimitera ainsi un intervalle.

– Fin de la mesure, centralisation des fichiers de trace et ”recalage”.La figure 9.9 presente le chronogramme obtenu lorsque l’on corrige la derive des horloges avec

cette methode. La synchronisation est bien meilleure, les donnees sont tout a fait utilisables.Cette methode a aussi ete testee dans le scenario presente sur la figure 9.10, ou deux emetteurs

cherchent chacun a envoyer autant que possible de paquets de 1000 octets et saturent le canal. Lechronogramme obtenu est presente sur la figure 9.11

S’il reste du trafic de mesure dans le reseau lorsque les paquets de synchronisation sont diffuses,il y a un risque que l’envoi de ces paquets soit retarde (phenomene de defering induit par 802.11),

112


Fig. 9.9 – Chronogramme de deux mobiles recevant des paquets diffuses lorsque la derive deshorloges est corrigee avec la deuxieme methode

Synchro

DataData

Fig. 9.10 – Disposition des mobiles pour l’evaluation de la synchronisation (deux sources dedonnees)

Fig. 9.11 – Chronogramme de deux mobiles diffusant des paquets lorsque la derive des horloges estcorrigee avec la deuxieme methode

113


1 2 3 4 5

S

Fig. 9.12 – Le synchronisateur pelerin visite regulierement les autres mobiles et leur transmet labonne horloge

faussant ainsi un peu l’echelle de temps. Cependant, et c’est le plus important, meme dans cecas l’ordonnancement de l’ensemble des paquets ne sera pas vraiment affecte ; pas plus que par laderive de l’horloge de la machine synchronisatrice. Le seul risque est plutot que des paquets dedonnees entrent en collision au niveau de certains mobiles avec les paquets de synchronisation, etla perte de ces paquets est beaucoup plus dommageable.

Rapporter regulierement tous les portables a portee de communication du synchronisateur n’estpas toujours aise, en particulier lorsque l’on travaille sur des scenarios qui demandent un placementprecis de machines. Les deplacer pour les remettre ensuite en place peut poser probleme, une erreurde replacement de quelques centimetres ayant parfois un impact tout a fait non negligeable. Deplus cette phase de deplacement de toutes les machines peut demander un temps et une ”maind’œuvre” considerables s’il y a beaucoup de machines. Hors c’est autant de temps pendant lequelles batteries s’epuisent inutilement. Nous avons donc raffine notre methode.

9.3.4 Troisieme methode : le pelerin synchronisateur

Nous avons vu qu’avec la methode de l’approximation de la derive des horloges par des droites af-fines par morceaux, une duree d’une vingtaine de minutes etait un bon compromis entre la precisionde la methode et le travail occasionne. Cette fois-ci cependant, le moment venu, plutot que dedeplacer toutes les machines vers le synchronisateur c’est le synchronisateur lui-meme que nousdeplacons (exemple d’un longue chaıne sur la figure 9.12). La difference majeure avec la methodeprecedente tient dans le fait que, dans certaines topologies, aucun des paquets envoyes par le syn-chronisateur ne pourra atteindre tous les mobiles a la fois. Il ne sera plus possible de comparer lesdates locales de reception d’un meme paquet pour calculer la derive relative des horloges.

La solution choisie consiste a faire porter par les paquets de synchronisation une informationhoraire. En l’occurrence, ces paquets sont emis a une frequence fixe et precise (par exemple toutesles 5 secondes). Grace au numero de sequence du paquet, il est possible de calculer directementl’heure de reception de ce paquet dans l’horloge de reference (en multipliant le numero de sequencepar le temps separant l’emission de deux paquets consecutifs). Il faut noter qu’ici l’horloge dereference est donc l’horloge de la machine qui envoie les paquets de synchronisation.

Comme precedemment, la synchronisation des resultats se fait post-mortem ; une fois les fichiersde trace regroupes, ils sont analyses et recales. Nous appliquons toujours la methode de l’approxi-mation de la derive des horloges par une droite affine par morceaux, mais cette fois-ci les segmentssont delimites par la reception de deux paquets de synchronisation consecutifs. La date de receptiondu paquet de synchronisation de numero de sequence zero est l’origine du temps global. Si les pa-

114


R(t1-ts1)+(k*n1)

t1 t2

k*n1 k*n3k*n2

R(t2-ts2)+(k*n2)

ts1 ts3ts2

Espace de temps global

Espace de temps local

Fig. 9.13 – Le passage d’une echelle de temps local a une echelle de temps global (methode dupelerin)

quets de synchronisation sont envoyes toutes les k secondes alors la date de reception (en tempsglobal) d’un paquet de synchronisation de numero de sequence n est :

Tn = k × n (9.2)

Si ts1 et ts2 sont les dates locales de reception de deux paquets de synchronisation consecutifsde numeros de sequence respectifs n1 et n2, alors (ts2− ts1) est le temps local qui s’est ecoule entreles deux. Par definition de 9.2, le temps global ecoule entre les deux est :

k × (n2 − n1) (9.3)

Le rapport lineaire entre le temps global et le temps local est donc :

R =k × (n2 − n1)

(ts2 − ts1)(9.4)

t−ts1 exprime le temps local ecoule entre la reception d’un paquet de donnees et celle du paquetde synchronisation le precedant. Pour un paquet de donnees recu a une date locale t comprise entrets1 et ts2, le temps global T de reception de ce paquet est calcule de la maniere suivante :

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

Grace a ces formules, nous pouvons projeter les dates de reception locales de tous les paquetssur une echelle de temps global constituee par la reception des paquets de synchronisation. Lafigure 9.13 donne un exemple de cette relation. Les temps locaux (estampilles a la reception despaquets) sont indiques dans la partie basse du schema, les formules pour les convertir en temps surl’echelle globale sont indiques dans la partie haute. Les paquets de synchronisation sont schematisespar des traits verticaux epais, les paquets de donnees par des traits verticaux fins.

Il faut noter que cette methode peut etre amelioree afin de fournir des chronogrammes toujoursplus precis. En effet, telle que nous l’avons decrite, nous utilisons la propriete qu’un paquet radioest recu exactement au meme moment par les mobiles a portee de communication, mais nous nenous servons que des paquets dits ”de synchronisation” qui sont envoyes assez peu souvent.

Au cours de la mesure, un grand nombre de paquets de donnees sont en general envoyes.Si certains de ces paquets sont envoyes en mode diffusion, au moment de l’analyse des traces,nous les retrouverons surement a plusieurs endroits. La encore, on peut utiliser la propriete de

115


Synchro Data

Fig. 9.14 – Disposition des mobiles pour l’evaluation de la synchronisation (une source de donnees)

Fig. 9.15 – Chronogramme de deux mobiles recevant des paquets diffuses lorsque la derive deshorloges est corrigee avec la troisieme methode

simultaneite pour ameliorer la synchronisation entre les differents mobiles qui ont recu un memepaquet. En quelque sorte, ces paquets nous donnent des jalons intermediaires entre les paquets desynchronisation qui nous donnent eux-memes le temps absolu. Dans les sous-segments delimites partous ces paquets, nous appliquons toujours le mecanisme d’approximation par des droites affinespar morceaux.

Au final, cette methode permet d’obtenir une tres grande synchronisation des traces, compatibleavec nos besoins.

De part la nature de la methode, pour la valider il a fallu utiliser la topologie presentee surla figure 9.14 (elle consiste a rependre celle presentee sur la figure 9.1 et a ajouter le mobilesynchronisateur). Il y a toujours deux mobiles recepteurs, mais en plus du mobile synchronisateur,un autre mobile a ete ajoute qui diffuse des donnees a la vitesse de 10 paquets de 1000 octets parseconde. Ce sont la reception de ces donnees sur les deux mobiles recepteurs qui est presentee surle chronogramme 9.15. On voit que cette fois-ci, la synchronisation est vraiment tres bonne, notreobjectif est atteint.

Dans le cadre du scenario de la figure 9.10, les resultats sont egalement tres bons, comme onpeut le voir sur le chronogramme 9.16

Fig. 9.16 – Chronogramme de deux mobiles diffusant des paquets lorsque la derive des horloges estcorrigee avec la troisieme methode

116

0

CHAPITRE

10 Les scenarios ”avances”

Apres avoir realise un certain nombre de mesures preparatoires et developpe des outils desynchronisation adequats, nous avons pu passer a des mesures dans des scenarios plus complexes.A des fins evidentes de comparaison, nous avons cherche a reproduire dans la realite les scenariosque nous avions utilise lors de la phase de simulation. Les problemes d’acces au canal seraient-ilsaussi severes que les simulations et les calculs le laissent supposer ? Dans ce chapitre, nous allonspresenter les resultats obtenus pour des configurations a deux et trois paires ainsi que pour unechaıne comportant de 1 a 4 sauts.

10.1 Les deux paires

Jusqu’a present, nous nous sommes interesses a la portee effective des cartes 802.11. Danscette experience, nous cherchons a mesurer jusqu’a quelle distance des mobiles peuvent detecterreciproquement leurs porteuses et a partir de quand la reutilisation spatiale devient possible. Pource faire, nous utilisons quatre mobiles repartis en 2 paires. Ces quatre mobiles sont initialementtres proches et au fur et a mesure de l’experience nous allons eloigner les deux paires l’une del’autre comme indique sur la figure 10.1. L’orientation des cartes est egalement celle indiquee surla figure 10.1, c’est a dire sur les cotes par rapport au sens de deplacement, et non face-a-face oudos-a-dos. Dans la pratique nous eloignons les paires par etapes successives. Chaque etape dure 75secondes pendant lesquelles nous effectuons des mesures pour plusieurs combinaisons de flux et devitesses de transmission (nous utilisons toujours des paquets UDP de 1000 octets). Ces 75 secondessont a chaque fois suivies de 25 secondes d’inactivite pendant lesquelles nous deplacons les mobiles,puis un nouveau cycle commence. La figure 10.2 decrit les combinaisons de flux pendant les phasesde transmission (nous rappelons que la diffusion se fait toujours a 2 Mbit/s, et qu’ici l’envoi enunicast 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 degauche.

– 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 presente les debits mesures par le mobile 2 en fonction du temps. Comme chaque

phase de transmission se fait a une position donnee, puis que les mobiles sont deplaces durant les

117

CHAPITRE 10. LES SCENARIOS ”AVANCES”

25 secondes qui suivent, la legende de la figure en abscisse indique directement les distances. Cettefigure porte de nombreuses informations et nous allons la commenter en trois parties distinctes encommencant par les plus simples :

– A 190 metres : Les deux paires sont totalement independantes, aussi bien a 11 qu’a 2 Mbit/s.Quelle que soit l’activite dans l’autre paire, le debit utile des flux unicast depasse donc les5 Mbit/s, ce qui est le maximum possible pour la taille de paquet utilisee. Il en est de memeavec le flux broadcast qui plafonne quant a lui aussi a son maximum, c’est a dire 1.6 Mbit/senviron. Du fait de la distance, les paquets emis en mode diffusion par le mobile 3 ne sontevidemment pas recus du tout par le mobile 2.

– A courte distance (jusqu’a 58 metres) : Les emetteurs doivent partager le canal. Plusieurssituations se detachent :– Deux flux broadcast simultanes (secondes 20 a 35 des cycles concernes) : 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 ete donneelors de l’etude precedente de 1 a 7 flux simultanes : les backoff sont decrementes en partiesimultanement et cela se traduit par un temps en moyenne inferieur entre deux paquetsconsecutifs sur le canal.

– Deux flux unicast simultanes (secondes 60 a 75 des cycles concernes) : ils obtiennentegalement chacun un peu plus de la moitie de ce qu’un aurait obtenu seul, soit pas loin de3 Mbit/s.

– Un flux unicast et un flux broadcast simultanes (secondes 0-15 et 40-55) des cyclesconcernes : ils se partagent le canal avec une probabilite d’acces egale. Cela se traduitpar un debit intermediaire d’environ 1.3 Mbit/s pour chacun des flux. En effet, le flux a2 Mbit/s envoie autant de paquets que celui a 11 Mbit/s. Ce dernier va donc se trouverpenalise par ce partage. Les deux flux vont obtenir le meme debit alors que l’un d’eux estsense avoir un debit plus eleve. Ce phenomene a ete releve par [42].

– Entre 94 et 160 metres : C’est dans cette region que les interferences se manifestent. Onremarque tout d’abord que l’on est desormais trop loin pour que le mobile 2 recoive encorecorrectement les paquets envoyes en mode diffusion par le mobile 3. A 94 metres et un toutpetit peu a 120 metres on recoit neanmoins encore quelques uns de ces paquets, mais plusaucun a 160 metres. Puisque c’est a cette distance que les phenomenes sont les plus visibles,nous nous attardons sur chacune des combinaisons de flux a une distance de 160 metres :– 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’environ1.5 Mbit/s. Comme nous l’avons deja 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 detecte.)

– Lorsque le flux unicast local doit cohabiter avec le flux unicast distant (secondes 60 a 75du cycle), il n’y a visiblement plus de partage du canal necessaire, puisque le flux local estau debit maximum.

– Le flux broadcast (secondes 20 a 55 du cycle) est lui aussi affecte par le flux broadcastdistant, mais dans une moindre mesure : on voit une instabilite assez nette tant que lemobile distant emet a 2 Mbit/s, mais cette instabilite disparaıt lorsque le mobile distantpasse a 11 Mbit/s.

Dans [41], les auteurs presentent le probleme de la zone grise. Ce probleme apparaıt lorsqueles protocoles de routage utilisent des paquets diffuses a 2 Mbit/s pour construire les routes, et

118


Fig. 10.1 – Positions des deux pairesmobiles

� � � � � ��

� � � � � ��

� � � � � � ��

� � � � � ��

� � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � ��

Unicast

Unicast Unicast

Broadcast

Broadcast

time in seconds

0 55 60 7540352015

1 −> 2

3 −> 4

Fig. 10.2 – Communications dans le schema des pairesmobiles

0

1

2

3

4

5

6

very close 25.5m 58m 94.5m 119.75m 159.75m 189.75m

Thro

ughp

ut in

Mb pe

r sec

ond

distance in meters

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

Fig. 10.3 – Paquets recus par les 2 nœud recepteurs dans le scenario des deux paires mobiles

que les donnees sont ensuite envoyees a une vitesse superieure (par exemple 11 Mbit/s). Commela portee diminue avec l’augmentation de la vitesse, il se peut que certaines routes soient valides a2 Mbit/s mais ne soient pas utilisables a 11 Mbit/s. C’est la difference entre les zones de couverturea differentes vitesses qui est appelee zone grise. Dans cette experience des deux paires mobiles, nousn’avons pas mesure directement la zone grise. Nous avions bien un flux a 2 Mbit/s et une autre a11 Mbit/s, mais ce dernier etait en unicast et restait local dans chaque paire mobile, il ne pouvaitdonc pas etre compris par l’autre paire. Par contre, et en particulier a 160 metres, l’extension duprobleme de la zone grise a la zone de detection de porteuse est tres visible. La portee de detectionde 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 metres, durant les secondes 0 a 35 du cycle, on voit tres bien que lesflux locaux (aussi bien a 11 Mbit/s qu’a 2 Mbit/s) n’obtiennent pas toute la bande passante : il ya detection de la porteuse du flux a 2 Mbit/s dans l’autre paire et il y a donc partage du canal.La portee de detection de porteuse du flux distant a 11 Mbit/s (secondes 40 a 75 du cycle) est elleinferieure a 160 metres. Les flux locaux a 2 et 11 Mbit/s ne detectent pas du tout son activite etoccupent la totalite de la bande passante.

119


10.2 Les trois paires

La configuration des trois paires que nous avons etudiee par simulation avait montre de gravesproblemes dans l’equite de l’acces au medium pour la paire centrale lorsqu’elle percevait en quasipermanence le canal occupe par l’une ou l’autre des paires exterieures. A des fins de verification,nous avons donc cherche a reproduire cette configuration pour des mesures reelles. Pour des raisonspratiques, nous avons travaille en interieur. En utilisant la topologie du batiment, il nous etait eneffet plus facile de faire en sorte que les deux paires exterieures ne se genent pas du tout entreelles. Nous avons travaille a 2 Mbit/s et sans RTS/CTS. Dans la configuration presentee sur lafigure 10.4, les paires exterieures pouvaient detecter la porteuse de la paire centrale (nous l’avonsverifie en constatant un partage equitable du canal si l’on activait la paire centrale et seulement l’unedes paires exterieures a la fois), et les deux paires exterieures ne se genaient pas (elles obtenaienttoutes les deux le debit maximum si elles etaient activees en meme temps). Une fois toutes lesmachines dans la position voulue, nous avons active un flux dans chacune d’entre elles (comme al’accoutumee, afin de saturer le reseau, nous avons utilise des flux de paquets UDP de 1000 octetspour lesquels la file d’attente est toujours pleine).

Les debits mesures sur chacune des paires sont presentes sur la figure 10.5. Il faut noter qu’apartir de la seconde 925 environ, les emetteurs des paires centrale et gauche sont stoppes. Onobserve tres clairement les difficultes rencontrees par la paire centrale : son debit evolue entre 5 et15% du debit des paires exterieures. On remarque egalement la presence d’une periode (entre lessecondes 805 et 870 environ) ou le debit sur la paire centrale est vraiment tres faible (moins de 10paquets par seconde, soit moins de 5% de la bande passante). Cette periode correspond au momentou le debit des paires exterieures est quasiment maximal. Le reste du temps, la paire de droitesemble partager la bande passante (d’une maniere certes non-equitable) avec la paire centrale.Apres une etude detaillee et de nombreuses repetitions de l’experience, nous avons determine quece partage venait en fait d’interferences au niveau de la paire de droite par une station de basesituee a un autre etage du batiment (et sur laquelle nous n’avions pas de controle).

Cette experience confirme donc de maniere tres nette les simulations. Dans certaines situationsou des mobiles sont genes de facon asymetrique, certains mobiles utilisant 802.11 peuvent connaıtrede grande difficultes pour acceder au canal. Comme nous l’avons deja explique, ce probleme nepeut etre regle simplement, car ils est cause par la conjonction de l’activite de plusieurs mobilesqui en empechent ainsi d’autres d’acceder correctement au medium. Les mobiles qui emettent n’ontd’ailleurs pas de moyen de savoir qu’ils genent quelqu’un d’autre.

10.3 La chaıne

10.3.1 Le scenario, les contraintes

La configuration que nous voulons tester est celle presentee sur la figure 10.6. L’environnementde mesure est le boulevard precedemment decrit (chapitre 7). Nous utilisons cinq portables pourrealiser la chaıne, ainsi qu’un sixieme qui joue le role de synchroniseur selon la methode presenteedans le chapitre precedent. Nous utilisons bien evidemment forwarding pour forcer la topologielogique (le mobile 2 re-emet tous les paquets qu’il recoit de 1, le mobile 3 re-emet tous ceux qu’ilrecoit de 2 et ainsi de suite). Afin de recolter un maximum de donnees, les transmissions se font enmode diffusion, et donc a 2 Mbit/s. La diffusion permet de savoir, pour chaque paquet emis, a quels

120


Fig. 10.4 – Les disposition des mobiles pour l’experience des trois paires

Fig. 10.5 – Les difficultes pour la paire centrale a acceder au canal

121


1 2 3 4 5

S

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

endroits il peut etre recu (en fonction des receptions d’un meme paquet, on reconstruit directementla zone de communication du mobile qui a emit ce paquet).

Le premier probleme rencontre reside dans la portee des emetteurs lorsqu’on les utilise a2 Mbit/s. Dans le chapitre sur la portee, nous avons vu que le signal pouvait alors etre recu aplus de 500 metres. Mais le boulevard ou nous effectuons les experimentations ne mesure qu’unkilometre environ et nous n’avons pas a disposition un environnement homogene permettant di-rectement l’experience de la chaıne (il nous faudrait une ligne droite d’au minimum deux ou troiskilometres). Nous avons avons donc decide de reduire artificiellement la portee de nos emetteurs.Pour cela nous utilisons du papier d’aluminium avec lequel nous entourons les antennes de noscartes (nos cartes Lucent ne permettaient pas de changer la puissance d’emission). Aussi empiriqueet simpliste qu’elle puisse paraıtre, cette methode est tres efficace et permet de diviser la portee descartes par un facteur 5 a 10 suivant la quantite d’aluminium utilise. Cette facon de proceder a uninteret majeur a nos yeux : elle nous permet d’effectuer la mesure de la chaıne tout en la gardant aune echelle significative du point de vue de l’environnement et des interferences. Il nous aurait etepossible d’utiliser des antennes externes modifiees pour avoir un gain tres faible (techniquement,en donnant une portee de l’ordre du metre a nos carte il aurait ete ainsi possible de realiser l’en-semble des mesures multi-sauts dans une seule piece), mais un tel changement d’echelle du reseaumodifie profondement les effets de l’environnement sur l’experience. Dans un reseau multi-sautsa une echelle de quelques centaines de metres, les conditions d’interferences de l’environnementpeuvent etre tres differentes d’un endroit a l’autre du reseau (passage d’une voiture, proximite d’unequipement perturbateur, batiment qui reflechit les ondes de certains emetteurs, portes fermeesou ouvertes en interieur, presence ou simplement passage de pietons, etc.). Un reseau miniature(tenant dans une piece) ne serait pas soumis aux memes phenomenes (la plupart des elementsperturbateurs decrits precedemment affecteraient l’ensemble du reseau de maniere uniforme).

10.3.2 Le deploiement et le deroulement de l’experience

Afin de mieux rentabiliser notre temps (et la duree des batteries), l’experience est concue demaniere a mesurer en une seule fois les comportements sur des chaınes a 1, 2, 3 et 4 sauts. Dansun reseau ad hoc, une configuration de chaıne apparaıt lorsque l’emetteur d’un paquet est troploin du destinataire et que des mobiles intermediaires doivent relayer les donnees de proche enproche. Les mobiles intermediaires sont choisis par le protocole de routage et en general ils vontl’etre de maniere a minimiser le nombre de sauts. Cela signifie que chaque mobile de la chaınepeut communiquer avec ses voisins directs, mais pas avec ses voisins a deux sauts. Forwarding nouspermet, en forcant le choix des routes, d’eviter toute instabilite dans leur choix qui pourrait etreliee au protocole de routage. Mais en contrepartie il faut nous assurer nous-meme du placement desmobiles. La chaıne de notre experience est donc construite progressivement. Le mobile 1 est place

122


a une extremite du boulevard et configure pour emettre un flux a vitesse maximale (ici des paquetsUDP de 1000 octets). Le mobile 2 est mis en route. Initialement il est proche du mobile 1, et onl’eloigne jusqu’a ce que le debit qu’il en recoit commence a baisser. En quelques minutes on arrive,grace a l’affichage du debit en temps reel et par des deplacements successifs, a la placer a la limitede la zone dans laquelle la plupart des paquets emis par le mobile 1 sont recus. On configure alorsle mobile 2 pour emettre lui aussi (a cette etape, on ne stoppe pas encore l’emission du mobile 1).On peut alors placer le mobile 3 en fonction des flux venant de 1 et de 2. Quelques minutes sontegalement necessaires pour trouver une position dans laquelle on recoit bien le mobile 2, mais pasou tres peu le mobile 1. On peut alors demarrer l’emission sur le mobile 3 et stopper celle sur lemobile 1 (pour economiser l’energie) ; 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 desiree. Onstoppe alors les flux restants et on effectue un passage de synchronisation avec le sixieme mobile.

10.3.3 Les resultats

Nous avons realise deux fois cette experience. Il aurait ete preferable de la realiser plus de foisencore, mais la lourdeur de ce genre d’experimentation est telle que cela n’a pas ete possible.

Premiere mesure

Lors de la premiere mesure, une fois les mobiles places comme decrit precedemment et la phasede synchronisation initiale effectuee, nous demarrons le flux de donnees sur la chaıne. Au depart,il n’y a pas de repetition des paquets (un seul saut), et au fur et a mesure on allonge la chaıne enactivant la repetition sur chacun des mobiles. Les paquets UDP font 1000 octets, ils sont envoyesen mode diffusion, a 2 Mbit/s. Les debits mesures sont presentes sur les figures 10.7 a 10.11. Lachronologie de l’activation des re-emissions et l’interpretation des resultats est la suivante :

– 270 a 380 : Aucune repetition, seul le flux entre 1 et 2 existe, il obtient la totalite de la bandepassante, soit environ 1.6 Mbit/s de debit utile (figures 10.7 et 10.8) et est assez stable. Onremarque sur la figure 10.9 que certains paquets emis par 1 sont recus en 3 (secondes 300 a 340environ) mais qu’ils ne sont pas tres nombreux. Ces paquets sont tres interessants et montrentbien un probleme specifique aux reseaux ad hoc : la propension a subir des interferences parrafales. Ces paquets recus en 3 a partir de 1 auraient pu conduire un protocole de routagea etablir une route directe. Mais la duree de vie de cette route aurait ete courte (30 a 40secondes), et surtout aurait subit un taux de perte particulierement elevee (90 a 95% environ).

– 380 a 540 : Le mobile 2 repete les paquets qu’il recoit 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 debut(partie de 380 a 490), comme l’atteste la figure 10.7. Pour cette partie tout d’abord, commele laissait presager l’experience precedente des 2 a 7 flux en concurrence dans la meme piece,on y voit que le debit agrege de deux flux est dans ces conditions egal voire un peu superieura un seul flux qui aurait toute la bande passante. On remarque cependant, toujours sur lafigure 10.7, qu’il y a quelques pertes : le debit du flux (2→3) est legerement inferieur a celuidu flux (1→2) alors qu’idealement ils devraient etre identiques. Si l’on compare le flux venantde 2 recu en 2 et en 3 sur les figures 10.8 et 10.9, on constate que (2→2) est strictement egala (1→2) (les courbes sont superposees) et superieur a (2→3). Ceci est tout a fait normal. Enfait, 2 recoit lui-meme les paquets qu’il diffuse quoiqu’il arrive sur le canal (les paquets sontenvoyes 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.9la presence de quelques paquets venant directement de 1 (secondes 380 a 400), alors que lesmobiles 4 et 5 n’ont jusqu’a present percu aucun paquet.Les choses se gatent cependant entre les secondes 490 et 540, ou le flux (2→3) est brusquementfortement affecte par des interferences externes : son debit devient tres instable. Pour cettepartie, on voit que le debit recu en 2 a partir de 1 ne change pas (figure 10.7 et 10.8) et queces paquets sont transmis a la couche MAC de 2 (flux (2→2) sur la figure 10.8). De ces deuxchoses, on deduit donc que les paquets sont bien emis par 2 mais qu’ils ne sont pas recus par 3(s’ils n’etaient pas re-emis par 2, le debit de (1→2) augmenterait avec la bande passante ainsiliberee). Ceci souligne une fois de plus la tendance de certaines des interferences exterieuresa se produire par rafale.

– 540 a 700 : Le mobile 3 se met a repeter les paquets qu’il recoit 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 debit effectif arrivant en 4 est faible (figure 10.10 : en moyennede 200 kbit/s alors qu’il devrait idealement depasser les 500 kbit/s) et extremement instable(parfois quasiment nul pendant 5 a 10 secondes). On remarque, comme dans les simulations,que le mobile qui genere les paquets (le mobile 1) occupe plus la bande passante qu’il ne ledevrait pour un acces equitable au medium. Lorsque des paquets sont perdus plus loin sur lachaıne, les mobiles qui auraient du les re-emettre peuvent se trouver dans une situation de’famine’, et le mobile 1 qui lui a toujours sa file d’emission pleine en profite.

– 700 a 830 : Le mobile 4 se met a repeter les paquets qu’il recoit de 3 ; la chaıne passe a4 sauts. Les observations sont semblables a celles de la chaıne a 3 sauts : des paquets sontperdus a chaque etape et le debit de bout en bout est a la fois faible est tres instable. Entreles secondes 780 et 800 environ, plus aucun trafic n’est meme recu en 4 (figure 10.11). Onremarque egalement (figure 10.8) que le flux (1→2) maintient le meme debit que lorsqu’il yavait un saut de moins ; il s’accapare une part de la bande passante de plus en plus importantepar rapport a ce qu’elle devrait etre idealement.

Une fois cette experience de la chaıne a 4 sauts realisee, comme il nous restait suffisamment decharge sur nos batteries, nous avons decide de reproduire la meme experience, mais en unicast. Lavitesse de transmission reste de 2 Mbit/s (la changer aurait signifie la necessite de replacer tous lesmobiles en consequence, et nos batteries n’auraient pas tenu aussi longtemps). Passer en unicastpresente l’interet d’activer le mecanisme des acquittements (et donc de la detection des collisions ouerreurs de transmission, avec la re-emission qui s’en suit), mais a le desavantage de nous empecherde detecter les paquets qui ne nous sont pas explicitement envoyes. Les debits presentes sur lesfigures 10.12 a 10.16 sont donc moins riches que celles de la phase en diffusion (pour des raisonsde facilite de lecture, les figures 10.13 a 10.16 reprennent chacune une courbe de la figure 10.12 defacon separee).

La chronologie de l’activation des re-emission et leur interpretation est la suivante :– 1140 a 1205 : Il n’y a pas de re-emission, seul le flux (1→2) existe. Il utilise toute la bande

passante et le debit effectif depasse les 1.5 Mbit/s (figures 10.12 et 10.13). Il est evidemmentinferieur au debit lors de la phase equivalente en diffusion, puisqu’il faut maintenant prendreen compte les acquittements. La stabilite de l’unique flux est comparable celles de la phaseen diffusion, c’est-a-dire assez grande.

– 1205 a 1415 : Le mobile 2 se met a re-emettre les paquets qu’il recoit de 1 ; la chaıne passea 2 sauts. Le canal est partage equitablement (figure 10.12) et le debit de bout en bout est

124


0

500000

1e+06

1.5e+06

2e+06

300 400 500 600 700 800

debi

t en

bits

par

sec

onde

temps en secondes

de 1 recu en 2de 2 recu en 3de 3 recu en 4de 4 recu en 5debit aggrege

Fig. 10.7 – Debit de proche en proche sur la chaıne (mesure 1, broadcast)

0

500000

1e+06

1.5e+06

2e+06

300 400 500 600 700 800

debi

t en

bits

par

sec

onde

temps en secondes


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

125


0

500000

1e+06

1.5e+06

2e+06

300 400 500 600 700 800

debi

t en

bits

par

sec

onde

temps en secondes



0

500000

1e+06

1.5e+06

2e+06

300 400 500 600 700 800

debi

t en

bits

par

sec

onde

temps en secondes



126


0

500000

1e+06

1.5e+06

2e+06

300 400 500 600 700 800

debi

t en

bits

par

sec

onde

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-emet plus les paquets. Cela se voit a l’absence dereception par 3 dans cette periode (figure 10.14) et au debit du flux (1→2) qui augmentesubitement pour utiliser toute la bande passante disponible (figure 10.13).Entre 1380 et 1415, les choses sont un peu plus mitigees, le debit de (1→2) augmente alorsque celui de (2→3) diminue, mais (2→3) ne devient pas nul. Dans ces deux cas, on assistedonc a une capture partielle ou totale du canal par le mobile 1, et ce pour une duree assezlongue (une vingtaine de secondes environ).

– 1415 a 1540 : Le mobile 3 se met a re-emettre les paquets qu’il recoit de 2 ; la chaıne passe a3 sauts. Le partage du canal est tres equitable (figure 10.12) entre les flux (1→2) et (2→3). Ill’est un peu moins avec (3→4) qui voit parfois son debit chuter de maniere tres importante.Toujours sur la figure 10.12, la courbe de debit agrege nous montre encore une fois assez bienla tendance des interferences a se manisfester par rafales (chutes tres importantes du debitdans le reseau pour des durees de 5 a 20 secondes en general).

– 1540 a 1720 : On passe a 4 sauts. Le comportement est encore une fois tres semblable acelui de la chaıne a 3 sauts mesure juste avant. Les debits de (1→2) et (2→3) sont en generaltres proches (figure 10.12), de meme pour (3→4) et (4→5). La plupart des pertes se trouventau moment du passage de 3 a 4. Le debit de bout en bout obtenu dans la realite sur la chaınea quatre sauts est different de celui obtenu par simulation (figure 10.17) D’une part il estbeaucoup plus instable. D’autre part il se situe en general autours de 250 kbit/s alors que lessimulations l’estimaient a 400 kbit/s. Dans la realite, il n’a atteint qu’une fois la valeur de400 kbit/s, et pour une duree assez courte (une dizaine de secondes environ).

127


0

500000

1e+06

1.5e+06

2e+06

1100 1200 1300 1400 1500 1600 1700

debi

t en

bits

par

sec

onde

temps en secondes


Fig. 10.12 – Debit de proche en proche sur la chaıne (mesure 1, unicast)

0

500000

1e+06

1.5e+06

2e+06

1100 1200 1300 1400 1500 1600 1700

debi

t en

bits

par

sec

onde

temps en secondes

de 1 recu en 2

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

128


0

500000

1e+06

1.5e+06

2e+06

1100 1200 1300 1400 1500 1600 1700

debi

t en

bits

par

sec

onde

temps en secondes

de 2 recu en 3


0

500000

1e+06

1.5e+06

2e+06

1100 1200 1300 1400 1500 1600 1700

debi

t en

bits

par

sec

onde

temps en secondes

de 3 recu en 4


129


0

500000

1e+06

1.5e+06

2e+06

1100 1200 1300 1400 1500 1600 1700

debi

t en

bits

par

sec

onde

temps en secondes

de 4 recu en 5


0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

1.8e+06

0 10 20 30 40 50 60

debi

t en

bits

par

sec

onde

temps en secondes

Fig. 10.17 – Debit de bout en bout simule dans une chaıne de quatre sauts (modele two-ray ground)

130


0

500000

1e+06

1.5e+06

2e+06

1850 1900 1950 2000 2050 2100 2150 2200 2250

debi

t en

bits

par

sec

onde

temps en secondes


Fig. 10.18 – Debit de proche en proche sur la chaıne (mesure 2, broadcast)

Deuxieme mesure

Nous avons cherche a reproduire l’experience decrite precedemment. Le protocole experimentaletait identique (configuration et placement des machines), a l’exception de la chronologie de l’acti-vation des re-emissions. Cette fois-ci, la chaıne commence entierement formee (4 sauts), et au fur eta mesure de l’experience on stoppe des re-emissions de facon a la raccourcir. A noter que dans cetteexperience, les batteries du mobile 1 se sont epuisees a la seconde 2240 environ et que la chaıneetait alors constituee de 2 sauts (il n’y a pas de mesures a un seul saut dans cette experience donc).

Les resultats sont presentes sur les figures 10.18 a 10.22 et la chronologie des desactivation desretransmissions est la suivante :

– 1810 a 2050 : Les mobiles 2 a 4 re-emettent les paquets qu’ils recoivent de leur predecesseurdirect, la chaıne est composee de 4 sauts. Sur la figure 10.18, on voit que les debits des flux(1→2) et (2→3) sont en general tres proches l’un de l’autre, de meme que (3→4) et (4→5),mais que beaucoup de paquets re-emis par 3 sont perdus a certains moments (difference tresvisible entre (2→3) et (3→4) entre les secondes 1875-1895 et 2010-2050). Dans ces momentsou les mobiles 4 et 5 ne recoivent que peu de paquets, on remarque que le debit sur (1→2)et (2→3) n’augmente pas pour autant ... ceci est du au fait que le mobile 3 envoie accede luiaussi au canal (mais simplement peu de ses paquets sont recus).

– 2050 a 2190 : Le mobile 4 a cesse de re-emettre, la chaıne n’est plus constituee que de 3sauts. La encore, on constate (figure 10.18) que beaucoup de paquets sont emis par 3 maispas recus par 4. On remarque bien aussi les periodes de 10 a 20 secondes pendant lesquellesles interferences externes causent ces pertes en serie.

– 2190 a 2240 : seul le mobile 2 re-emet, la chaıne ne fait plus que 2 sauts. Le partage du canalest tres equitable. On remarque tres bien neanmoins une periode ou l’ensemble des mobilesencore actifs sont affectes par des interferences (’trou’ dans le debit des flux (1→2) et (2→3)au alentours des secondes 2230-2240).

La figure 10.23 presente un chronogramme du debut de cette mesure obtenu avec la methodeexposee precedemment. Nous rappelons que dans les chonogrammes construits comme celui ci apartir de mesures reelles, ce sont les receptions de paquet qui sont representees ; chaque rectanglecorrespond a un paquet recu et compris, et sa couleur indique par quel mobile il a ete emit. Au

131


0

500000

1e+06

1.5e+06

2e+06

1850 1900 1950 2000 2050 2100 2150 2200 2250

debi

t en

bits

par

sec

onde

temps en secondes


Fig. 10.19 – Occupation du canal percue par lenœud 2

0

500000

1e+06

1.5e+06

2e+06

1850 1900 1950 2000 2050 2100 2150 2200 2250

debi

t en

bits

par

sec

onde

temps en secondes



0

500000

1e+06

1.5e+06

2e+06

1850 1900 1950 2000 2050 2100 2150 2200 2250

debi

t en

bits

par

sec

onde

temps en secondes



0

500000

1e+06

1.5e+06

2e+06

1850 1900 1950 2000 2050 2100 2150 2200 2250

debi

t en

bits

par

sec

onde

temps en secondes



132


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

debut du chronogramme, le mobile 2 recoit 3 paquets consecutifs du mobile 1 (a), puis en re-emetun (b). Un peu plus tard, le mobile 3 re-emet ce paquet (c). On remarque que les emissions desmobiles 1, 2 et 3 n’ont jamais lieu en meme temps : ils se partagent le canal. Mais lorsque le mobile4 re-emet un paquet (d), le mobile 1 peut emettre lui aussi : il y a reutilisation spatiale. On peutvoir egalement la perte de certains paquets : en (e), le mobile 3 emet un paquet qui n’est recu qu’en2, alors qu’il devrait aussi l’etre en 4. En (f) enfin, on remarque la reception simultanee d’un paquetemit par 2 en 3, et d’un paquet emit par 4 en 5. On savait depuis (d) que 3 etait bien a portee de4. Alors que ses deux voisins directs ont emit en meme temps, le mobile 3 a donc ete (cette fois-citout du moins) en mesure de recevoir correctement un des deux messages.

Resume et interpretation des resultats de l’experience de la chaıne

D’un maniere generale, nous avons vu au travers des experiences que meme dans des conditionsfavorables (routage statique, flux UDP), le debit obtenu d’un bout a l’autre d’une chaıne d’unelongueur pourtant raisonnable (4 sauts au plus) est assez problematique. L’analyse detaillee desevenements nous a permis de constater le role important des interferences liees a l’environnement.Plutot que de s’etaler d’une maniere homogene dans le temps, elles arrivent par rafales. Celase traduit par des coupures plus ou moins completes de communication pendant des periodes dedurees tres variables (parfois quelques paquets consecutifs, parfois plus de communications pendant30 secondes sur le lien). Lorsque les communications sont temporairement rompues sur un segmentde la chaıne, les segments suivants se retrouvent rapidement en situation de ’famine’ : ils n’ontplus de donnees a envoyer. Plus la chaıne est longue, plus les chances qu’un segment soit rompu ougravement ’bruite’ a un instant donne sont grandes. C’est probablement ici que se situe le principalenseignement que l’on peut retirer de cette serie d’experiences : du fait des erreurs qui se produisentsouvent par rafales longues (plusieurs dizaines de secondes), les simulations sur-estiment en generalnettement les performances des configurations en chaıne.

133

1

CHAPITRE

11 Mise en pratique du malus

Au cours de nos simulations, puis plus tard avec des mesures en environnement reel, nousavons souleve le probleme de l’equite de l’acces au canal radio dans certaines configurations ou lesinterferences se faisaient de facon asymetrique. Les mobiles les plus genes ne pouvaient pratiquementjamais envoyer de paquets, car ils detectaient toujours le canal occupe. Nous avons analyse lephenomene et montre qu’il etait possible de l’attenuer avec un mecanisme de penalites appliqueesaux mobiles qui emettaient trop de paquets par secondes. Afin de confirmer nos dires, nous avonsdecide d’implementer ce mecanisme sur nos mobiles et de le tester.

11.1 Choix de l’implementation

Le mecanisme du malus est tres simple en lui-meme. Le temps est decoupe en cycles courts (uneseconde) et pour chaque paquet envoye, une penalite au backoff doit etre ajoutee en fonction dunombre de paquets que le mobile a deja envoye au cours du cycle. La penalite est bien sur remisea zero au debut de chaque nouveau cycle.

La principale difficulte dans l’implementation de cette methode est que contrairement a ce quenous avons pu faire sous simulateur, il ne nous est en fait pas possible de modifier le mecanisme debackoff. Toute la couche MAC est codee dans une memoire directement soudee sur la carte reseauradio, et nous n’avons pas ete en mesure d’en obtenir les codes sources.

Il nous a fallu trouver une solution de remplacement donnant des resultats comparables, aumoins dans le contexte de l’experience des trois paires.

Comme nous ne pouvions agir sur les couches les plus basses (PHY et MAC), nous avons choiside travailler au niveau de la couche reseau. L’idee etait de detourner les paquets juste avant qu’ilsne soient envoyes a la carte reseau, de les faire attendre a notre convenance dans une file d’attente,puis de les remettre dans le flux normal pour qu’ils soient emis dans les airs.

De cette maniere, meme sans controler directement le backoff, il est possible de reduire progres-sivement le debit des mobiles qui cherchent a emettre trop vite.

Concretement, l’implementation de cet algorithme s’est faite avec un filtre de paquets. Un filtrede paquets est un programme qui analyse les en-tetes des paquets au fur et a mesure qu’ils passentet decide du devenir de l’ensemble du paquet en fonction de ce qu’il y trouve. Il peut decider dedetruire le paquet (DROP) et il disparaıt alors comme s’il n’avait jamais ete recu ; il peut aussil’accepter (ACCEPT) et le paquet continue son chemin ; mais il peut egalement en faire quelquechose de plus complique. Sous linux, le filtrage se fait dans le noyau (le code peut etre directementintegre dans le noyau ou charge sous forme de module), et il peut realiser des fonctions diverses,meme si le principe explique precedemment reste valide.

134

CHAPITRE 11. MISE EN PRATIQUE DU MALUS

Décision de routage FORWARD

OUTPUTINPUT

Processus local

Réception des paquets Emission

des paquets

Fig. 11.1 – Iptables et les differents points d’accroche

Le filtrage de paquet est en general utilise pour les fonctions suivantes :– Le controle : 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 requetes HTTPvers les adresses de doubleclick.net).

– La securite : Sur une passerelle, surtout si l’on n’est pas sur de la configuration des machinesqui sont derriere, il peut etre interessant d’interdire completement certains trafics venant del’Internet. Il est rassurant par exemple de savoir que quelle que soit la configuration de mesmachines sous windows, les requetes d’acces a leurs fichiers seront bloquees au niveau de lapasserelle.

– Le monitoring : Si jamais des trafics suspects sont detectes, il est bon que l’information soitremontee a l’administrateur.

Nous detournons un peu le filtre de paquets de son usage habituel pour le faire retenir lespaquets qui le traversent. Pour comprendre comment nous faisons, il faut d’abord savoir commentle filtrage de paquet fonctionne.

Le mecanisme de filtrage de paquet des noyaux 2.4 de Linux s’appelle Iptables [76]. Un certainnombre de listes de regles appelees ”chaınes” sont implementees par defaut (INPUT, OUTPUT etFORWARD), comme presentees sur la figure 11.1. Quand un paquet atteint une chaıne, elle estexaminee pour decider du sort du paquet. Si la chaıne dit DROP, alors il est detruit, et si elle ditACCEPT, alors il continue son chemin dans le diagramme. Chaque chaıne est une liste de regles,et si l’en-tete d’un paquet ne correspond pas a une regle, alors la regle suivante est examinee, etainsi de suite. Si aucune regle ne s’est averee convenir au paquet, alors la regle par defaut de lachaıne est appliquee (par defaut configuree a ACCEPT).

Le fonctionnement des trois chaınes est le suivant :

1. Quand un paquet arrive de l’interface reseau, le noyau regarde quelle est sa destination etdecide 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 estaccepte par celle-ci, alors il sera recu par tout processus qui l’attend.

3. Si le routage est active et si le paquet est destine a une autre interface reseau, alors il passedans la chaıne FORWARD et est envoye si cette derniere l’accepte.

4. Finalement, lorsqu’un processus local veut envoyer un paquet sur le reseau, il doit d’abordetre 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’entree / sortie).

135


Application file d'attente delay

ip_queue

Carte réseau sans fil

Espace utilisateur

Noyau

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

Les regles dans les chaınes et les chaınes elles-memes peuvent etre ajoutees ou supprimeesen ligne de commande, grace a l’utilitaire iptable. Cet utilitaire nous permet en particulier despecifier l’action a effectuer (c’est-a-dire la cible, ou encore TARGET) lorsqu’une regle s’applique aun paquet. Les cibles les plus utilisees sont DROP et ACCEPT, mais nous allons plutot nous servirde QUEUE, qui permet, grace au module ip queue, d’envoyer les paquets dans une file d’attentespeciale dans l’espace utilisateur. La, un programme specialement ecrit (delay) pourra aller leschercher, et les renvoyer au noyau et a l’interface physique apres les avoir eventuellement retenusquelques temps (figure 11.2). Le programme delay retarde bien evidemment les paquets en suivantl’algorithme du malus. Notons que pour obtenir une precision suffisante, nous avons du utiliserl’appel systeme nanosleep, et que de ce fait certaines precautions doivent etre prises quant auxautres processus fonctionnant au meme instant sur les ordinateurs mobiles (pour que nanosleepdonne la meilleure precision, les regles d’ordonnancement des processus doivent etre quelque peuchangees).

Il faut noter egalement que le mecanisme du malus doit etre adapte pour pouvoir donner lesresultats attendus. En effet, comme on peut le voir sur la figure 11.3 dans la partie de gauche, si l’onajoute le malus a un niveau intermediaire 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 ete applique directementdans la couche MAC. Si le malus est applique dans netfilter, alors il peut y avoir un recouvremententre son temps de pause et l’envoi d’autres paquets par la couche MAC. L’objectif du systemede malus est d’augmenter le temps entre deux paquets consecutifs envoyes par un meme mobilesur le canal, et l’on voit ici qu’il n’y arrive pas lorsque le malus est petit. Si le malus pouvait etreapplique directement dans la couche MAC, un tel recouvrement ne serait pas possible. Pour etreapplique en dehors de la couche MAC, il faut donc que le malus tienne compte de la duree detransmission du paquet (comme presente sur la partie de droite de la figure 11.3). Pour cela, ila besoin essentiellement de connaıtre la taille du paquet ainsi que la vitesse a laquelle il va etreenvoye. De cette facon, il est alors possible d’imposer le temps inter-trame desire. Notons que surla figure, pour des raisons de lisibilite, le backoff aleatoire de la couche MAC n’est pas representemais que le resultat final est le meme.

11.2 Resultats

Nous avons realise a nouveau l’experience des trois paires, de la maniere deja decrite (figure 11.5).Les resultats sont presentes sur les figures 11.6 a 11.9 (pour des raisons de lisibilite, les figures 11.7a 11.9 reprennent chacune une courbe de la figure 11.6). La penalite appliquee est celle que nous

136


1 2 3CBR

Netfilter

MAC1 2 3

malus malusmalus

temps inter-trames

court temps inter-trames

court

temps inter-trames court malgré le malus

4 5 6

malus

4 5 6

temps inter-trames

court temps inter-trames

court

Temps inter-trame de la longueur voulue

recouvrement entre le malus et l'émission physique

Fig. 11.3 – Adapter le malus pour qu’il puisse etre applique ailleurs que dans la couche MAC

0

50

100

150

200

250

0 5 10 15 20 25 30

Mal

us (

en n

ombr

e de

tim

e sl

ots)

paquets envoyes depuis le debut du cycle

malus

Fig. 11.4 – La penalite ”effective” applique en fonction du nombre de paquets envoyes

avions deja utilisee lors des simulations (figure 11.4), corrigee a la volee de la maniere decrite dansla section precedente afin de prendre en compte la difference dans la maniere de l’appliquer.

L’experience s’est deroulee en plusieurs etapes, qui peuvent etre decrites et analysees commesuit :

– Secondes 100 a 900 : seules les deux paires exterieures sont actives et le malus n’estpas encore utilise. On remarque une certaine instabilite dans les debits. Le debit maximumtheorique est de 190 paquets de 1000 octets par seconde pour un emetteur seul et si aucunecontention ou collision n’a lieu. Jusqu’a la seconde 800 environ, la paire de gauche subit desinterferences assez visibles (qui affectent meme la paire de droite vers la seconde 550). Cesinterferences sont en fait dues a une station de base situee a une autre etage du batiment.Nous avons simplement attendu que ces interferences cessent pour realiser les mesures quinous interessaient (les interferences cessent vers la seconde 800, il etait alors midi et lesutilisateurs du reseau ont quitte les bureaux).

– Secondes 900 a 1350 : la troisieme paire est activee. On se retrouve dans les memes condi-tions que l’experience precedente avec les trois paires (chapitre 10. La paire centrale n’accedeque tres 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’experience des trois paires

contre 180-190 pour chacune des paires exterieures). Cette etape est realisee simplement ades fins de confirmation du probleme.

– Secondes 1350 a 1400 : la paire de droite est stoppee. L’objectif etait de verifier queconformement aux previsions, les deux paires restantes (gauche et centrale) se partageraientle canal. On voit que c’est effectivement le cas, chacune obtenant environ 95-100 paquets parseconde.

– Secondes 1400 a 1700 : on reactive la paire de doite, et on revient dans la meme situationproblematique de la periode 900-1350.

– Secondes 1700 a 2100 : on active le mecanisme du malus. La pair centrale voit alors seschances d’acces au canal augmenter de maniere significative (son debit evolue desormais entre60 et 70 paquets par seconde environ). Le debit des deux paires exterieures quand a lui estlogiquement reduit (il plafonne alors a environ 105-110 paquets par seconde). Notons que cesresultats sont tres proches de ceux prevus par la simulation.

– Secondes 2100 a 2300 : la paire centrale est stoppee, mais les paires exterieures continued’utiliser le malus. Leur debit continue de plafonner a environ 100 paquets par seconde. Ceciavait egalement ete prevu par le calcul et les simulations, c’est l’effet negatif du mecanisme dumalus dans les conditions ou il est le plus visible. Les deux paires exterieures ne se genent eneffet pas du tout, et le temps inter-trames supplementaire impose par la malus est ici inutileet dommageable pour le debit. Notons bien cependant que c’est ici le pire cas, et que commenous l’avons vu, cet effet decroıt tres rapidement avec l’augmentation du nombre de mobileen contention.

Dans cette experience, nous avons pu verifier que le mecanisme du malus offrait bien les resultatsescomptes et que la paire centrale pouvait acceder au canal dans une proportion beaucoup plusexploitable qu’avant. Le desavantage principal du mecanisme a egalement ete souligne : diminu-tion nette du debit maximum possible lorsqu’il n’y pas de contention. Nous rappelons que deuxautres desavantages existent : la tendance a transmettre par rafale ainsi qu’un retard (assez courtcependant), a l’envoi effectif des paquets.

Il est important de garder a l’esprit que dans une situation comme celle de cette experience,du fait de l’impossibilite d’etablir des communications entre les trois paires, toute solution passaitpar un sacrifice de la bande passante maximale. La solution que nous avons choisi (le malus avecsa progression caracteristique en trois etapes) presente cependant assez peu de desavantages, pourpeu qu’il y ait plusieurs mobiles en contention.

138


0

50

100

150

200

0 500 1000 1500 2000 2500

paqu

ets

par

seco

nde

temps en secondes

gauchecentrale

droite

Fig. 11.6 – Experience des trois paires avec le malus

0

50

100

150

200

0 500 1000 1500 2000 2500

paqu

ets

par

seco

nde

temps en secondes

gauche

Fig. 11.7 – Experience des trois paires avec le malus (paire de gauche)

139


0

50

100

150

200

0 500 1000 1500 2000 2500

paqu

ets

par

seco

nde

temps en secondes

centrale

Fig. 11.8 – Experience des trois paires avec le malus (paire centrale)

0

50

100

150

200

0 500 1000 1500 2000 2500

paqu

ets

par

seco

nde

temps en secondes

droite

Fig. 11.9 – Experience des trois paires avec le malus (paire de droite)

140

Conclusions

Dans cette these, nous nous sommes interesses au comportement de la norme IEEE 802.11lorsqu’elle est utilisee pour realiser des reseaux ad hoc. D’une maniere generale, notre travail peutetre resume en deux etapes principales : la mise en lumiere de problemes et l’analyse de leursimpacts d’une part, ainsi que l’apport de solutions d’autre part.

La mise en lumiere des problemes et leurs impacts

Pour des raisons pratiques et historiques, nos travaux ont debute par un grand nombre desimulations. Les scenarios qui nous interessaient etaient tres caracteristiques des reseaux ad hocde par leur topologie (chaınes de mobiles, paires mobiles, etc.) mais aussi par les trafics mis enœuvre (des flux importants, a meme de charger ponctuellement ou durablement le reseau comme leferaient des applications reelles telles que la navigation sur le web, le transfert de fichiers ou memela consultation de messageries).

Neanmoins, les simulateurs disponibles presentent un certain nombre de limitations. De plus,tres peu d’experiences ont ete realisees pour mesurer les impacts reels de 802.11 dans les reseauxad hoc. Nous sommes donc passes a une phase de verification de mesures reelles. A cette fin nousavons developpe un outil appele forwarding specialement concu pour permettre le deploiement etl’evaluation de configurations typiquement ad hoc. Afin de nous permettre de nous concentrersur le comportement de 802.11, forwarding nous affranchit des couches superieures. Pour cela, ilautorise le routage statique et met en œuvre des flux UDP, nous permettant ainsi de controler defacon tres precise l’emission et le cheminement de chaque paquet. En utilisant cet outil, nous avonstout d’abord realise des experiences simples, puis nous avons mis en place des experiences pluscomplexes. Ces dernieres ont necessite l’etude et le developpement de mecanismes nous permettantd’obtenir des traces parfaitement synchronisees a partir de nos differentes machines. Compte tenude la precision dont nous avions besoin, la derive des horloges des ordinateurs est en effet telle quenous ne pouvions l’ignorer. Des contraintes supplementaires liees notamment au partitionnementpossible du reseau etaient egalement a prendre en compte. La methode que nous avons proposeeremplit cependant parfaitement nos attentes.

Un certain nombre de caracteristiques de 802.11 ont peu etre mises en evidence dans cette these.Les principales sont les suivantes :

L’impact du WEP La cryptographie WEP de nos cartes presente une anomalie lorsque lesdebits utilises sont de 11Mb/s. Cela a une impact important sur le debit lorsque la taille despaquets depasse un certain seuil, puisque le debit obtenu est bien inferieur au debit attendu. Cetteanomalie a ete mise en evide par experimentation.

141

Le debit global Le debit global d’un reseau complet (tous les mobiles peuvent communiquer avectous les autres) augmente quand le nombre de mobiles en contention augmente. Cette caracteristiquea ete mise en evidence par une experimentation qui a montre que le debit aggrege augmentaitlorsqu’on avait jusqu’a cinq mobiles en contention, puis il se stabilisait apres (jusqu’a sept mobilesutilises). Ce fait provient du mecanime d’attente aleatoire de DFWMAC de 802.11 : lorsqu’unmobile n’a pas pu emettre, il ne retire pas un nouveau backoff aleatoire mais utilise le backoffrestant.

Si on considere que, d’apres les travaux de [77], le nombre optimal de voisins dans un reseauad hoc devrait etre de l’ordre de six, cela impliquerait que le debit global est optimal dans chaquezone de diffusion (ou tous les mobiles peuvent communiquer avec tous les autres). Cela est bien survrai si on regarde chaque zone de diffusion independamment des autres. Mais il est beaucoup plusdifficile de predire le debit global lorsque ces zones sont dependantes les unes des autres.

La portee de communication Une difference de taille est a noter dans les portees de com-munication obtenues par simulation et par experimentation. En effet, la portee reelle (obtenue enenvironnement exterieur) est tres inferieure aux portees considerees dans NS2. De plus, les zones decouverture sont loin d’etre circulaires comme le suppose les modeles de propagation courammentutilises en simulation : il existe dans la realite une zone ou les communications sont tres instableset sujettent a des interferences liees a l’environnement se produisant de facon regroupees dans letemps (par rafales). L’observation de tels comportement dans la realite alors qu’ils ne sont pas prisen compte dans les simulateurs (meme dans le modele shadowing qui est le plus realiste propose parNS2) indique que ces derniers ont necessairement une vision optimiste, et que leurs resultats sontpeut-etre parfois bien loin de la realite. Ceci est particulierement problematique dans la mesure oula perception que les simulateurs donnent de l’environnement radio aux concepteurs de protocolesde routage influence ces derniers de facon certaine. Enfin, les experimentations ont montre quel’orientation des cartes, aussi bien au niveau du recepteur que de l’emetteur, avait un impact nonnegligeable sur la portee de communication.

Les interferences par rafales Ce constat provient des deux points precedents et des experiencesreelles (notamment sur la chaıne) Les communications sont perturbees par des interferences prove-nant de l’environnement qui interviennent de maniere groupee dans le temps. Pendant des periodesde temps plus ou moins longues, le debit des communications devient faible, voire nul. Puis les com-munications repartent normalement sans raison apparente. Ceci rend les resultats reels nettementinferieurs aux previsions par simulation.

Le mecanisme d’EIFS apporte une instabilite dans les debits Le mecanisme d’EIFS estdeclenche quand un mobile recoit un signal qu’il n’est pas en mesure de comprendre mais quil’empeche d’emettre. L’EIFS est environ six fois plus important que le DIFS utilise lors de l’envoi“classique” de paquets, i.e. quand aucun signal interferant ne vient troubler les communications.Or cette difference entre les valeurs de DIFS et de EIFS entraıne une instabilite dans les debits. Eneffet, lorsqu’un mobile reussit a prendre la main dans l’acces au medium, il va alors la garder pourl’envoi de plusieurs paquets consecutifs, car le mobile gene par ces communications doit attendreplus longtemps avant de pouvoir acceder au medium. Cette instabilite a ete mise en evidence parsimulation dans les scenarios des deux paires et des trois paires.

Le partage du medium en zone de detection de porteuse Si deux mobiles sont en zonede detection de porteuse l’un de l’autre, ils doivent partager le medium radio, meme s’ils sont tropeloignes pour communiquer. Cette caracteristique a ete mise en evidence par simulation et parexperimentation dans les scenarios des deux paires et des trois paires. Elle s’explique aussi tres bienpar le fonctionnement de 802.11. Elle a un impact tres important au niveau de la qualite de servicedans de tels reseaux. En effet, si le but est d’offrir une garantie sur la bande passante, on voit qu’iln’est plus possible de seulement se baser sur les communications voisines, mais qu’il faudra etre enmesure d’evaluer les communications s’effectuant dans la zone de detection de porteuse.

Dans NS2, la zone de detection de porteuse est deux fois plus grande que la zone de communi-cations. Les experimentations ont montre que cette zone etait aussi de l’ordre de deux foix la zonede communication mais qu’elle etait aussi beaucoup plus instable. L’experience sur une chaıne demobiles montre que parfois cette zone devenait plus grande ou plus petite.

Les debits multiples 802.11b permet l’utilisation de debits multiples : les paquets de donneessont envoyes a 11Mb/s alors que les paquets de diffusion sont envoyes a 2Mb/s. De plus, 802.11permet la degradation de debit d’un flux si la communication n’est pas bonne. Plusieurs travaux([42, 41]) ont montre que l’utilisation de debits multiples avaient des effets non negligeables. D’unepart, les protocoles de routage qui se basent sur des paquets en mode diffusion vont offrir une visionerronee du voisinage aux mobiles. D’autre part, le partage equitable que 802.11 offre aux mobiles aportee de communication va ralentir les mobiles a plus grand debit qui auront le meme debit queles mobiles plus lents. Ces caracteristiques ont ete retrouvees par experimentation.

Les problemes d’equite Par simulation et experimentation, des problemes graves d’equite dansl’acces au canal sont apparus, certains mobiles etant dans la quasi-impossibilite d’envoyer desmessages pendant des periodes de temps prolongees. L’analyse de ces problemes (par simulation etexperimentation, 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 derniere a ete concue pourdes reseaux a stations de base. Dans les configurations particulieres de reseaux ad hoc que nousavons testees, elle est clairement mise en defaut. La nature du probleme tient pour une bonne partdans l’inegalite des mobiles faces aux interferences. 802.11 donne des chances comparables d’accesau canal a des mobiles en competition mais a portee de communication directe ou indirecte (deuxsauts, grace aux RTS/CTS). Mais dans les configurations que nous avons presentees ces chancessont faussees. En effet, certains mobiles vont subir une combinaison des activites de mobiles voisinsqui agissent independamment les uns des autres et qui indique a ce mobile que le canal est occupeen permanence, et l’empeche donc de facon durable d’y acceder.

Ce probleme a ete mis en relief dans le scenario des trois paires aussi bien par simulation quepar experimentation. Il se retrouve aussi dans le scenario de la chaıne, mais il est combine a d’autresproblematiques (comme des debits differents sur les mobiles par exemple).

L’impact de ces problemes sur les applications mais egalement sur les protocoles de routage a etesouligne. Les emissions conjuguees de certains mobiles sont a meme de causer dans leur voisinagedes cassures et des redecouvertes de routes a repetitions ; l’efficacite du routage s’en ressentantgrandement. Enfin, les protocoles ont une vision erronee du reseau et pourraient peut-etre prendredes decisions differentes s’ils disposaient de la topologie reelle.

Impact des EIFS sur l’equite . Comme nous l’avons vu par la simulation dans le scenario destrois paires, l’utilisation des EIFS peut amplifier les inegalites dans l’acces au medium. Dans cescenario, la paire centrale accedait jusqu’a six fois moins souvent au canal que lorsqu’elle n’attendaitque DIFS apres la fin d’une transmission erronee.

Les RTS/CTS Le mecanisme des RTS/CTS souvent prone comme la solution aux problemes desnœuds caches semble avoir des effets pas toujours positifs sur des scenarios plus complexes commela chaıne de mobiles. Par simulation, nous avons vu que les debits sur la chaıne etait fortementdiminue lorsque les RTS/CTS etaient utilises et que la communication etait bien meilleure sans cemecanisme.

Les debits reels Les experiences ont montre que les debits reels obtenus dans les reseaux ad hoctestes sont plus faibles que ceux obtenus par simulation.

L’etude de solutions

A partir du moment ou les simulations ont souleve les problemes d’equite dont nous venonsde parler, nous y avons cherche des solutions. La nature du probleme fait qu’il semble difficile deproposer une solution qui ne fasse pas de sacrifice en terme de bande passante. Dans de nombreusesconfigurations, les mobiles dont la conjonction des emissions pose probleme n’ont pas de moyende s’en rendre compte (parfois ces mobiles sont completement hors de portee de communicationdirecte ou indirecte les uns des autres ainsi que des mobiles qu’ils empechent d’acceder au canal).Nous avons donc propose une premiere solution basee sur des penalites appliquees d’une maniereetudiee aux mobiles qui emettent beaucoup. Sous simulateur, cette methode a donne des resultatstout a fait satisfaisants, aussi bien dans les scenario des trois paires que dans celui de la chaıneperturbee. Le principal desavantage de la methode est une chute du debit maximum possible en casd’absence de contention. Ce desavantage est cependant tres vite limite et rendu imperceptible desque le nombre de mobiles en contention augmente E cette situation est finalement tres probabledans un reseau ad hoc, ou beaucoup de mobiles vont devoir non seulement envoyer leurs propresdonnees, mais aussi celles d’autres nœuds pour lesquels ils routent des paquets.

A des fins de verification, nous avons adapte le mecanisme de la penalite a notre environnementde mesure. Comme il n’etait pas possible de modifier la couche MAC directement (ce qui auraitete ideal, mais impossible du fait des codes sources fermes), nous avons utilise un systeme deremplacement. Ce dernier, base sur le filtrage de paquets dans le noyau linux et leur retenuetemporaire dans l’espace utilisateur a necessite quelques modifications dans notre algorithme, maisa ensuite donne entiere satisfaction. Dans le scenario des trois paires que nous avons reproduit unenouvelle fois, la paire centrale pouvait enfin acceder au canal dans des proportions raisonnables.

Enfin, nous avons aussi ameliore une solution aux problemes d’equite proposee par Bensaouet al. Par un mecanisme simple (inclu dans l’acquittement ou le CTS) qui permet de prendreen compte les communications distantes et par une meilleure stabilisation de l’algorithme, nousproposons une solution qui donne une meilleure equite et qui permet de diminuer la perte de debitglobal en bande passante.

Bilan

L’interet pour les reseaux ad hoc est recent. Les recherches dans ce domaine se sont concentreessur certains problemes clefs, et en particulier sur le routage. Pour des raisons pratiques, au traversde differents outils de simulation, ces nombreuses etudes s’appuient dans leur grande majorite surla norme 802.11.

L’originalite de nos travaux tient dans l’approche pragmatique que nous avons eue des reseauxad hoc. La pile de protocoles, du niveau physique jusqu’aux applications, meme si elle presente dessimilitudes avec celles des mondes filaires et cellulaires, a besoin d’adaptations specifiques a tousles niveaux. La couche MAC de 802.11, de part son fonctionnement totalement distribue, sert defondation pour la majorite des travaux du domaine ad hoc se voulant capables de fonctionner surles technologies radio grand public de ce debut de millenaire. C’est donc d’une maniere naturelleque notre interet s’est porte sur elle et ses interactions avec les couches superieures dans le contextead hoc.

De part les problemes que nous avons souleves, nous avons montre que le choix des couchesbasses et de la couche MAC en particulier etaient loin d’etre neutres dans les reseaux ad hoc,et qu’il y avait des interdependances tres fortes entre tous les niveaux de la pile de protocoles.Ainsi, l’environnement et les situations topologiques propres aux reseaux ad hoc conduisent a desinterferences physiques, qui agissent sur la couche MAC, qui elle-meme a un effet sur le fonction-nement des protocoles de routage.

Notre etude de ces phenomenes et de leur impact est novatrice dans le sens ou nous avonscherche a les isoler specifiquement, plutot qu’a obtenir des resultats agreges ou les interactionsentres les couches MAC, PHY, routage, TCP et application sont entremeles et finalement peutexploitables.

Perspectives

Un certain nombre de topologies ad hoc qui posaient probleme a 802.11 ont ete mises a jourdans nos travaux, mais la recherche de ces situations n’a pas ete exhaustive et il est tout a faitpossible qu’il en existe d’autres qui soulevent des problemes particuliers. La recherche de l’ensembledes situations problematiques, leur etude theorique et leur reconnaissance par des experiences nousapparaıt donc comme un premier axe de travail dans la continuite de cette these ; d’autant plusque nous pouvons desormais compter sur les outils que nous avons developpes.

Les problemes d’equite forment a eux seuls un domaine de recherche. Certaines etudes theoriquesexistent deja dans la litterature, mais beaucoup de travail reste a faire, aussi bien dans la classifica-tion des definitions diverses de l’equite, que dans la proposition de solutions. Le lien peut etre faitegalement avec le point precedent : les problemes specifiques des reseaux ad hoc (de topologie et desinterferences qui y sont liees en particulier) peuvent etre pris en compte pour definir l’equite et yproposer des solutions adaptees. Les contraintes sont cependant nombreuses, comme la distributionde l’algorithme qui est un point capital par exemple.

Le troisieme axe de recherche concerne les interactions avec les couches superieures, et le routageen premier lieu. Dans cette these nous avons montre et explique un certain nombre d’impacts surle routage que peuvent avoir les couches basses, nous pensons qu’il faudrait maintenant capitaliserces resultats et s’en servir pour repenser et adapter la maniere de router dans un reseau ad hoc.Dans le domaine des simulateurs, la realisation de couches physiques presentant les comportements

observes dans nos mesures nous semble un premier pas dans cette voie. Dans la communaute ad hoc,les simulateurs ont un impact tres important sur la conception des protocoles de routage. Au deladu routage, les interactions avec TCP meriteraient egalement d’etre revisitees, les performancesde TCP etant passablement mauvaises, aussi bien dans les simulations actuelles de reseaux adhoc (pourtant etonnamment optimistes, comme nous l’avons souligne) que dans les rares mesuresreelles.

Liste des acronymes

ACK ACKnowledgmentAP Access Point

BEB Binary Exponential BackoffBPSK Binary Phase Shift KeyingBS Base StationBSA Basic Service AreaBSS Basic Service Set

CA Collision AvoidanceCBR Constant Bit RateCCK Complementary Code KeyingCD Collision DetectionCDMA Code Division Multiple AccessCFP Contention Free PeriodCP Contention PeriodCRC Cyclic Redundancy CheckCSMA Carrier Sense Multiple AccessCTS Clear To SendCW Contention Windows

DARPA Defense Advanced Research ProjectsDCF Distributed Coordination FonctionDIFS DCF Inter Frame SpacingDSSS Direct Sequence Spread Spectrum

ETSI European Telecommmunications Standards Institute

FDD Frequency Division DuplexFHSS Frequency Hopping Spread Spectrum

GPS Global Positioning System

HiperLAN High Performance European Radio LAN

147

IEEE Institute of Electrical and Electronics EngineersIETF Internet Engineering Task ForceIFS Inter Frame SpacingIP Internet ProtocolIR Infra-RedISM Industry, Scientific and MedicalIV Initialisation Vector

LAN Local Area NetworkLLC Logical Link Control

MAC Medium Access ControlMANET Mobile Ad hoc NETwork

NAV Network Allocation VectorNS Network Simulator

OFDM Orthogonal Frequency Division MultiplexingOSI Open System Interconnection

PCF Point Coordination FonctionPIFS Polling IFSPRNET Packet Radio Network

QoS Quality of ServiceQPSK Quadrature Phase Shift Keying

RTS Request To Send

SIFS Short IFS

TCP Transport Control ProtocolTDD Time Division DuplexTDMA Time Division Multiple Access

UDP User Datagram ProtocolUN-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 AdHoc Networks in Charles E. Perkins Ad-hoc networking. London, Addison Wesley, 2000.

[2] The IETF Mobile Ad hoc NETworks working group [en ligne]. Disponible surhttp ://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-hopsad-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 IEEEInternational 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 communicationdans une reseau ad-hoc multi-sauts. In Proceedings of ALGOTEL 2002, Meze, France, pages 147–153,mai 2002.

[6] D. Dhoutaut and I. Guerin-Lassous. Experimentations avec 802.11 dans des configurations ad-hoc. InProceedings of ALGOTEL 2003, Banyuls sur mer, France, mai 2003.

[7] D. Dhoutaut and D. Laiymani. A corba-based architecture for parallel applications : experimentationswith the wz matrix factorization. In Proceedings of the first IEEE/ACM Internatianol Symposium onCluster Computing and the Grid, Brisbane, Asutralia, pages 442–449, 2001.

[8] D. Dhoutaut and D. Laiymani. A corba-based architecture for parallel applications : experimentationswith 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 Issuesand Evaluation Considerations.

[10] Gavin Holland and Nitin H. Vaidya. Analysis of TCP performance over mobile ad hoc networks. InMobile 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 Guerin 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 MobileAd 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, IEEEPersonal 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 LocalArea 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] Muhlethaler Paul. 802.11 et les reseaux sans fil. Paris, Eyrolles, 2002. 281 p.[33] P. Karn. MACA - a new channel access method for packet radio. In ARRL/CRRL Amateur Radio 9th

Computer Networking Conference, pages 134–140, 1990.[34] Ronald L. Rivest. Rc4. Dans Bruce Schneier, Cryptographie Appliquee : protocoles, algorithmes et

codes source en C. 2e ed. Paris : Vuibert, 2001, page 419-420.[35] Jangeun Jun, Pushkin Peddabachagari, and Mihail L. Sichitiu. Theoretical Maximum Throughput

of IEEE 802.11 and its Applications. In Proceedings of IEEE International Symposium on networkcommunications, 2003. Cambridge, MA, pp. 249-256.

[36] W. Moh, D. Yao, and K. Makki. Wireless LAN : Study of hidden terminal effect and multimediasupport. 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 wirelessLAN. 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. : PrenticeHall, 2002. 302 p.

150

BIBLIOGRAPHIE

[40] Aravind Velayutham and Haoli Wang. Solution to the exposed node problem of 802.11 in wirelessad-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 of802.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 Proceedingsof IEEE MMT’99, Venice, Italy, October 1999.

[44] Shugong Xu and Tarek Saadawi. Does the IEEE 802.11 MAC Protocol Work Well in Multihop WirelessAd 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 accessprotocol 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 PacketNetworks. 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-hocnetworks. In Proceedings of the 1st ACM international symposium on Mobile ad hoc networking andcomputing, 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 ComparisonStudy 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 PerformanceComparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols. In Mobile Computing andNetworking, pages 85–97, 1998.

[55] Samir Ranjan Das, Charles E. Perkins, and Elizabeth E. Royer. Performance Comparison of TwoOn-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. InImielinski 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. : PrenticeHall, 1996. 641 p.

[61] R.A. Valenzuela. Ray tracing approach to predicting indoor wireless transmission. In Proceedings ofthe 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 ofindoor 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 hocnetwork 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 AdHoc 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 wirelessnetwork 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 Nordstrom. 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 NetworkingConference, 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 usingReference 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 MobileComputing, pages 1965–1970, San Francisco, CA, USA, April 2001.

[75] Kay Romer. 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 amagic number. In Proc. IEEE National Telecommunications Conference, 1978.

152

Documents

Etude du standard IEEE 802.11 dans le cadre des réseaux ad ...theses.insa-lyon.fr/publication/2003ISAL0094/these.pdf · utilisant en particulier la norme 802.11 de l’IEEE. Mon