Rpublique Algrienne Dmocratique et Populaire

Ministre lEnseignement Suprieur et de la Recherche Scientifique

Universit Hadj Lakhdar BATNA
Facult des Sciences de lIngnieur
Dpartement Informatique

Etude et analyse de la stabilit

des protocoles de routage dans
les rseaux ad-hoc

Mmoire prsent en vue de lobtention du Diplme de Magister

en Informatique
Option : Informatique Industrielle

Prsent par :
Kamil CHEBIRA

Sous la direction de :
Pr. Noureddine DOGHMANE

Composition du Jury :
Dr. ZIDANI Abdelmadjid
Pr. DOGHMANE Noureddine
Dr. BILAMI Azzedine
Dr. FARAH Nadir

Matre de confrence
Professeur
Matre de confrence
Matre de confrence

Universit Batna Prsident

Universit Annaba Encadreur
Universit Batna Examinateur
Universit Annaba Examinateur

Anne universitaire 2006 - 2007

Ddicace et remerciements

Ce modeste travail nest ni plus ni moins le fruit de parents qui ont su comment
faire aboutir ce projet de magister. Ils mont toujours encourag et orient vers
la russite. Je ne les remercierai jamais assez.
A mon encadreur, Mr N. DOGHMANE qui a toujours t prsent pour
mclairer le chemin et qui na pas hsit avec ses conseils constructifs.
A mon frre Mounis, mes surs May et Lydia
A mon pouse Lilia et ma fille Yara
A mes neveux Macil et Selyane
A toute ma famille
A tous ceux qui ont particip llaboration de ce travail et qui sauront se
reconnatre

Je ddie le cur de cette thse de magister.

Kamil CHEBIRA.

Table des matires

Table des matires
Liste des tableaux
Liste des graphiques
Liste des acronymes
Introduction
1.
Description du projet
2.
Objectifs du projet
3.
Organisation du rapport
Chapitre 1.
Les rseaux sans fil
1.1
Rseaux sans fil tlphonique (Couches de transport)
1.2
Rseaux sans fil informatiques
1.3
Les rseaux sans fil ad hoc
1.3.1
Caractristiques des rseaux ad hoc
1.4
Le routage classique
1.4.1
Les Protocoles tat de Liaisons
1.4.2
Les protocoles Vecteur de Distance
1.4.3
Source routing
1.4.4
Flooding
1.5
Protocoles de routage dans les rseaux ad hoc
1.5.1
Protocoles ractifs
1.5.1.1
AODV (ad hoc On-Demande Distance-Vector)
1.5.1.2
DSR (Dynamic Source Routing)
1.5.1.3
TORA (Tomporally Ordered Routing Algorithme)
1.5.2
Protocoles Proactifs
1.5.2.1
DSDV (Destination Sequenced Distance-Vector Routing)
1.5.2.2
CGSR (Clusterhead Gateway Switch Routing)
1.5.2.3
WRP (Wireless Routing Protocol)
1.5.2.4
OLSR (Optimized Link State Routing)
1.5.3
Protocoles hybrides
ZRP (Zone Routing Protocol)
1.6
Proprits cibles par les protocoles de routage des rseaux ad hoc
1.6.1
Distribution des oprations
1.6.2
Routes sans cycle
1.6.3
Opration la demande
1.6.4
Liens unidirectionnels
1.6.5
La scurit
1.6.6
Conservation d'nergie
1.6.7
Multi-routes
1.6.8
Le support de la qualit de service
1.7
Comparaison
Chapitre 2.
Cadre Exprimental
Etude de simulation
2.1
Introduction
2.1.1
Les simulateurs de rseaux
2.1.1.1
Omnet ++

2
4
5
6
8
9
10
10
11
12
13
17
18
19
19
19
20
20
21
21
22
23
25
27
27
27
28
29
29
29
30
31
31
31
31
31
31
31
31
32
33
33
34
34
34

2.1.1.2
2.1.1.3
2.1.1.4
2.1.1.5
2.1.1.6
2.1.1.7
2.1.1.8
2.2
Chapitre 3.
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
Chapitre 4.
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.2.
4.2.1
4.2.2
Chapitre 5.
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.2
Bibliographie
Annexe A
Annexe B

NS-2
SensorSIM
GlomoSim
QualNet
Jist / SWANS
JSim
Opnet Modeler
Simulateur NS
tude de cadrage
Gnrateur de scripts
Paramtres de la simulation
Le modle de topologie
Le modle de propagation
Le modle de trafic
Le modle de mobilit
Le modle d'nergie
Les variables de la simulation
Les protocoles simuls
Le nombre de nuds
La mobilit
Les dplacements
Nombre de trafic TCP
Occupation de la bande passante
Calcul de la simulation
Mtriques de simulation
Les paquets de control
Les paquets utiles
Les paquets perdus
Le trafic mis
Le trafic rout
Le temps d'attente forc du mdium
Variables de la simulation
Mobilit
Intensit de flux sortants
Rsultats de la simulation
Rsultats et discussions
Paquets de control (pqt/nud)
Paquets utiles (pqt/nud)
Paquets perdus (pqt/nud)
Trafic mis (Koctet/nud)
Trafic rout (Koctet/nud)
Temps d'attente forc du mdium (Milliseconde/nud)
Conclusions et perspectives

35
35
35
35
36
36
36
37
39
40
40
40
41
41
4
42
42
43
43
43
44
44
45
46
47
47
47
47
48
48
48
48
49
49
51
52
52
53
54
55
57
58
59
61
62
64

Liste des tableaux

TAB 1
TAB 2
TAB 3
TAB 4
TAB 5

Diffrentes normes 802.11

Tableau comparatif des diffrents protocoles de routage ad hoc
Valeurs discrtes de la Mobilit
Valeurs discrtes de l'Intensit du flux sortant
Sens de variation des mtriques dans le cas idal

16
32
49
49
50

Liste des graphiques

FIG 1.1 FIG 1.2 FIG 1.3 FIG 1.4 FIG 1.5 FIG 1.6 FIG 1.7 FIG 1.8 FIG 2.1 FIG 3.1 FIG 3.2 FIG 3.3 FIG 3.4 FIG 5.1-A FIG 5.1-B FIG 5.2-A FIG 5.2-B FIG 5.3-A FIG 5.3-B FIG 5.4-A FIG 5.4-B FIG 5.5-A FIG 5.5-B FIG 5.6-A FIG 5.6-B FIG A.1 FIG B.1 -

Simple rseau ad hoc

Routage par "Source Routing"
Routage par "Flooding".
Formation de chemin sous AODV
Cration d'une route dans DSR
Maintenance de route sous TORA.
Routage du nud 1 au nud 8 par CGSR.
Le routage dans ZRP.
La simulation sous ns.
Terrain de simulation.
Architecture utilise.
Modle d'une connexion TCP dans ns.
Types de dplacements des noeuds.
Paquets de control en fonction de la mobilit
Paquets de control en fonction de l'Intensit du flux sortant
Paquets utiles en fonction de la mobilit
Paquets utiles en fonction de l'Intensit du flux sortant
Paquets de perdus en fonction de la mobilit
Paquets de perdus en fonction de l'Intensit du flux sortant
Trafic mis en fonction de la mobilit
Trafic mis en fonction de l'Intensit du flux sortant
Trafic rout en fonction de la mobilit
Trafic rout en fonction de l'Intensit du flux sortant
Temps d'attente forc du mdium en fonction de la mobilit
Temps d'attente forc du mdium en fonction de l'Intensit du flux sortant
Processus gnral de simulation
Une capture d'cran du Network Animator

17
20
21
23
25
26
28
30
38
40
41
42
44
52
52
53
53
55
55
55
55
57
57
58
58
63
65

Liste des acronymes

AODV : ad hoc On-Demande Distance-Vector

BTS : Base Tranceiver Station

Bluetooth : Technologie de rseau personnel sans fils (not WPAN pour Wireless
Personal Area Network),

Broadcast Diffusion

CGSR : Clusterhead Gateway Switch Routing

CLR Clear packet

CMU : Carnegie Mellon University

CSMA/CA : Carrier Sense, Multiple Access/Collision Avoidance

CSMA/CD : Carrier Sense Multiple Access / Collision Detect

DAG : Graphe Dirig Acyclique (Directed Acyclic Graph)

DECT : Digital Enhanced Cordless Technology

DSDV : Destination Sequenced Distance-Vector Routing

DSR : Dynamic Source Routing

EDGE : Enhanced Data rate for GSM Evolution

Flooding : Inondation

GHz Giga Hertz

GPRS : General Packet Radio Service

GSM : Global System for Mobile Communications

HiperLAN : High Performance Radio LAN

HomeRF : Spcification de rseau sans fil (Shared Wireless Access Protocol-SWAP)

IEEE : Institute of Electrical and Electronics Engineers

IEEE 802.11 : Standard pour les rseaux locaux sans fil sans infrastructure

IETF : The Internet Engineering Task Force

IMEP : Internet MANET Encapsulation Protocole

iMode : Internet mode

INPL : Institut National Polytechnique de Lorraine (Nancy - France)

IrDA : InfraRed Data Association

LBNL : Laboratoire National de Lawrence Berkeley

LSP : Link State Packets

MAC : Medium Access Control

MPR Multi-Points Relais

MRL : Message Retransmission List (Liste des Messages Retransmettre).

Mbps : Mega bit pas seconde

m/h : mtres pas heure

m/s : Mtres pas seconde

N.S : Simulateur de rseaux, une collaboration de UC Barcley, LBL, USC/ISI et Xerix

PARC.

NAM : Network Animator

OLSR : Optimized Link State Routing

OPNET : Open NETwork

OSPF : Open Shortest Path First

Otcl : Object Tool Command Language

PAN : Personal Area Network

Python : Langage de programmation interprt, multi-paradigme

QRY Demande de la source

R&D Recherches et dveloppements

RIP : Routing Information Protocol

Rrep : Route Reply

Rreq : Route Request

SIG : Special Interest Group (Microsoft, IBM et Nokia)

TC : Topology Control

TCL/TK : Tool Command Language, TK: Toolkit (La bibliothque graphique de TCL).

TCP/IP : Transmission Control Protocol/Internet Protocol

TORA :Tomporally Ordered Routing Algorithme

Trace : Fichier journal obtenu en sortie (rsultat de la simulation).

UMTS : Universal Mobile Telecomunications System

VINT :Virtual InterNetwork Testbed

WAP : Wireless Application Protocol

WECA :Wireless Ethernet Compatibility Alliance

WLAN : Wireless Local Area Network appel aussi WiFi

WPAN : Wireless Personal Area Network

WRP : Wireless Routing Protocol

WiFi : Wireless Fidelity

ZRP : Zone Routing Protocol

Introduction

Introduction
Les protocoles de routage dans les rseaux informatiques sont divers et varis en
fonction des types de rseaux. Dans notre tude nous allons nous intresser
particulirement aux protocoles de routage au sein des rseaux sans fils Ad hoc.
Ce type de rseaux appel Ad hoc ne dispose gure dinfrastructure fixe comme le
cas des rseaux GSM qui ncessitent une installation dantennes appeles BTS (Base
Transceiver Station).
Le support de transmission est les ondes radio. Les nuds metteurs disposent dun
rayon de propagation qui couvre leur voisinage.
Ces caractristiques offrent ces rseaux plus de mobilit et un dploiement trs
rapide.
Par consquent, le rafrachissement des tables de routage pnalise la bande passante
par les paquets de contrles frquents.
Les performances dun protocole de routage se dterminent en fonction du taux de
rafrachissement, des temps de rponse ainsi que le niveau de saturation du
mdium ou milieu de transmission. Pour amliorer ces performances, les quipes de
recherches simulent diffrents algorithmes de routage en variant leurs paramtres de
configuration et analysent le comportement de chacun dans plusieurs scnarios.

1. Description du projet
Les protocoles de routage ad hoc existants ne semblent pas trs diffrents. Des
tudes pousses peuvent nous rvler le contraire. Pour accentuer les petits carts, la
simulation prsente un outil essentiel, rapide et peu coteux.
Le but de notre travail est de distinguer les protocoles de routage partir de leur
algorithme afin de dsigner le plus performant. La simulation, notre outil de
comparaison, nous offre un grand nombre davantages. Elle permet de faire vivre un
scnario rel dun rseau informatique en virtuel, cest dire dans la mmoire dun
ordinateur. Le temps dune simulation relle est divis par milliers pour avoir le mme
scnario en virtuel. Ce grand avantage nous laisse la possibilit de multiplier nos tests
et faire un grand nombre de simulations. Nous valuons les rsultats par des fonctions
mathmatiques qui nous rapprochent beaucoup des rsultats rels. Si chacune des
simulations sintresse une proprit ou un paramtre de lalgorithme de routage,
nous serons en mesure de dfinir le bon algorithme et voire mme ouvrir des voies
pour lamlioration des autres.

10

Afin davoir un grand angle de vision pour la comparaison des protocoles, nous avons
pens simuler avec diffrents paramtres. Un paramtre peut bien tre la faveur
dun algorithme mais pas pour un autre.
Les paramtres varier dans notre tude sont classs en deux principales catgories,
physiques et logiques.
Les paramtres physiques jouent principalement sur la topologie de lenvironnement
au sein du rseau, contrairement aux paramtres logiques, qui configurent la bande
passante et le trafic de donnes.
Cette tude sintresse aux protocoles de routage ad hoc les plus connus, le ractif
DSDV et les ractifs AODV et DSR. Le simulateur de rseaux NS (Network
Simulator)1 [1], [2], [3] sera utilis comme outil de simulation durant tout notre travail.

2. Objectifs du projet
Notre objectif est de simuler des protocoles de routage ad hoc avec le simulateur de
rseaux NS pour analyser leurs performances dans une multitude de scnarios, o
des topologies et des flux sont dfinir. Une fois les simulations termines et leurs
traces2 gnres, nous les analyserons suivant diffrents critres et gnrerons des
courbes qui prsentent les synthses finales.

3. Organisation du rapport
Le premier chapitre comprend une prsentation des rseaux informatiques, sans fils et
ad hoc, leurs caractristiques, leurs protocoles de routage et leurs proprits. Le
second chapitre est consacr au cadre exprimental o nous exposons le simulateur
de rseaux. Nous dfinissons les paramtres qui nous ont servis pour les simulations
au troisime chapitre. Le quatrime prsente ltude et calcules de simulations avec
toutes les variables utilises. Enfin, les analyses des rsultats couvrent le chapitre cinq
qui est prend fin par des conclusions et perspectives.
Deux annexes sont introduites la fin du document afin de mieux schmatiser
lenvironnement de simulation.

1
2

N.S : Simulateur de rseaux, une collaboration de UC Barcley, LBL, USC/ISI et Xerix PARC.
Trace : Fichier journal obtenu en sortie (rsultat de la simulation).

11

Chapitre 1.
Les rseaux sans fil

12

Le dveloppement technologique au cours de ces dernires dcennies a rvolutionn

un certain nombre de domaines, notamment celui des rseaux informatiques et plus
spcialement les rseaux sans fil. Les performances ne cessent d'augmenter et les
prix de chuter. Cette avance les a rendu abordable par le grand public. Ce march de
l'quipement sans fil est actuellement en plein essor. Le constructeur de la puce
Bluetooth avait annonc le chiffre de 100 millions d'quipements lectroniques
Bluetooth en 2002.
Cette rvolution des rseaux informatiques devrait se poursuivre au vu des cots des
investissements dans le cblage de plus en plus levs.
Le sans fil a touch beaucoup de domaines mis part les rseaux informatiques, par
exemple, la tlphonie mobile o beaucoup de couches de transports ont t
dveloppes. Nous citerons quelques exemples comme (GSM 3 , GPRS 4 , UMTS 5 ,
EDGE6). Dans notre travail nous allons nous intresser principalement aux rseaux
sans fil informatiques.
Voici quelques dfinitions des principaux types de rseaux sans fil existant
actuellement.

1.1

Rseaux sans fil tlphonique (Couches de transport)

GSM (Global System for Mobile Communications)

Norme mondiale la plus rpandue de tlphonie cellulaire numrique qui exploite les
frquences 900 et 1800 Mhz dans plusieurs pays du monde et la 1900 Mhz en
Amrique du Nord.

GPRS (General Packet Radio Service)

Amlioration du GSM pour supporter les transferts de donnes.

UMTS (Universal Mobile Telecomunications System)

La 3me gnration introduite comme la rvolution des applications mobiles o elle

assure aussi le transfert de sons, images et vidos en haut dbit (de 384 Kbps 2
Mbps)

EDGE (Enhanced Data rate for GSM Evolution)

Propos par loprateur tlphonique Bouygues Tlcom alternative lUMTS avec un

dbit maximum de 384 Kbps.
3

GSM : Global System for Mobile Communications

GPRS : General Packet Radio Service
5
UMTS : Universal Mobile Telecommunications System
6
EDGE : Enhanced Data rate for GSM Evolution
4

13

Les couches cites ci-dessus sont utilises par quelques applications telles que WAP7,
iMode8.

WAP (Wireless Application Protocol)

Introduit en 1997 dans le but de permettre aux tlphones portables de se connecter

au Web par les collaborateurs NOKIA, ERICSSON, MOTOROLA et UNWIRED
PLANET. Cette initiative devait permettre la consultation de.mails, laccs aux
rseaux locaux dentreprises et beaucoup dautres services. Mais les aspects
techniques taient limits et loin de limage marketing annonce pour ce protocole.

iMode (Internet Mode)

Technologie dveloppe par loprateur japonais NTT-DoCoMo et introduite en France

par loprateur tlphonique Bouygues Tlcom. iMode utilise la couche basse GPRS,
et ralise de ce fait une conomie considrable par rapport au WAP. Il garde la
connexion juste au moment du transfert des paquets contrairement au WAP qui
facture le temps de la consultation mais pas le volume des donnes transfres.

1.2

Rseaux sans fil informatiques

Les autres rseaux qui nous intressent particulirement sont : Bluetooth9, HomeRF10,
HiperLAN11 et WiFi12.

Bluetooth (Internet Mode)

Cette technologie gre les connexions sans fil de type ondes radio utilisant les
frquences 2,4 Ghz dun dbit de 1Mbps et dune porte de 10m 30m. Cette
technologie concurrence fortement linfrarouge IrDA (InfraRed Data Association).
Le nom Bluetooth a t inspir en 1994 par ses crateurs (ERICSSON, IBM, INTEL,
NOKIA et TOSHIBA) du nom de Harald Blaatand (910-986), littralement Harald la
dent bleue qui unifia le Danemark et la Norvge, dans une Europe divise.
Le Bluetooth Special Interest Group (SIG) qui compte notamment Microsoft, IBM et
Nokia comme membres vient d'adopter en novembre 2004, les spcifications de la
norme Bluetooth 2.0+ Enhanced Data Rate. Offrant des dbits thoriques de l'ordre du
3 Mbps, la future norme a fait son apparition dbut 2005 dans les magasins.
L'organisme a rvl quelques unes des principales nouveauts de son nouveau
standard. Outre l'augmentation du dbit qui va donc passer de 1 Mbps 3 voire 10
7

WAP : Wireless Application Protocol

iMode : Internet mode
9
Bluetooth :
10
HomeRF :
11
HiperLAN :
12
WiFi :
8

14

Mbps dans certains cas, la consommation devrait diminuer de l'ordre de 50% environ.
Le taux d'erreurs sur bits, donne caractrisant la fiabilit des communications, sera
galement en baisse. Ce lot d'innovation s'accompagne d'une compatibilit garantie
avec les versions antrieures du Bluetooth.

HomeRF

Norme qui devrait servir banaliser la mise en place des rseaux locaux domestiques
sans fil. Elle est inspire des deux normes DECT13 (pour la transmission de la voix) et
WLAN14 (pour la transmission de donnes TCP/IP)
HomeRF assure un traitement allant jusqu' 127 nuds et 6 liaisons voix.
Dans la pratique, la porte d'une base est de 50 mtres, ce qui est cens couvrir une
maison moyenne avec son jardin. l'oppos, un rseau Bluetooth dfinit un PAN
(Personal Area Network), rseau radio de trs courte porte, d'environ 10 mtres. Le
dbit brut radio d'une base HomeRF est de 1,6 Mbps et de 1 Mbps utile en IP, 800
Kbps en tenant compte des pertes et des interfrences (une volution vers un dbit de
10 Mbps et 2 Mbps utiles est prvue, mais les matriels sont encore en phase de
dveloppement).
En matire de rseaux domestiques sans fil, HomeRF doit affronter la concurrence de
Bluetooth. La norme est en effet promue par plus de 1 000 industriels contre 90 pour
HomeRF. En outre, le groupe de travail 802. 15 de l'IEEE vient de se former pour
standardiser une norme de rseau personnel PAN (Personal Area Network) sans fil
reposant sur la technique Bluetooth. HomeRF a cependant pris de l'avance, puisque
les premiers matriels sont dj disponibles sur le march. " Bluetooth possde un
avantage marketing certain. Mais pour relier tous les appareils d'une maison, il est
insuffisant en termes de porte. Bluetooth serait plutt concurrent des liaisons
infrarouges. De plus, les premiers modles d'appareils la norme tardent tre
commercialiss. Il se pourrait que la premire technologie sur le march russisse tout
de mme l'emporter ", analyse le responsable des produits sans fil chez France
Tlcom R&D.

HiperLAN

Spcifi par l'ETSI (European Telecommunications Standards Institute)

Mobilit supporte : pitonne (3m/s max i.e. 10km/h)
Hiperlan met dans la bande des 5 GHz et permet d'atteindre un dbit de 54 Mbps.
HiperLAN possde des avantages techniques, par exemple l'inclusion d'une classe de
service lui permettant de grer la voix et l'mission multimdia en continu. Elle intgre

13
14

DECT : Digital Enhanced Cordless Technology

WLAN : Wireless LAN appel aussi WiFi

15

galement une technique empchant les interfrences avec d'autres quipements

radio.

WiFi

La norme IEEE 802.11 (ISO/IEC 8802-11) est un standard international dcrivant les
caractristiques d'un rseau local sans fil (WLAN). Le nom WiFi 15 (contraction de
Wireless Fidelity, parfois note Wi-Fi) correspond initialement au nom donn la
certification dlivre par la Wi-Fi Alliance, anciennement WECA (Wireless Ethernet
Compatibility Alliance), l'organisme charg de maintenir l'interoprabilit entre les
matriels rpondant la norme 802.11. Par abus de langage (et pour des raisons de
marketing) le nom de la norme se confond aujourd'hui avec le nom de la certification.
Ainsi un rseau Wifi est en ralit un rseau rpondant la norme 802.11. Le tableau
ci-dessous regroupe toutes les nomes 802.11 de la plus ancienne la plus rcente.

15

WiFi : Wireless Fidelity

16

Nom de la
norme

Nom

Description

Wifi5

La norme 802.11a (baptis WiFi 5) permet d'obtenir un haut dbit

(54 Mbps thoriques, 30 Mbps rels). La norme 802.11a spcifie 8
canaux radio dans la bande de frquence des 5 GHz.

802.11b

Wifi

La norme 802.11b est la norme la plus rpandue actuellement. Elle

propose un dbit thorique de 11 Mbps (6 Mbps rls) avec une
porte pouvant aller jusqu' 300 mtres dans un environnement
dgag. La plage de frquence utilise est la bande des 2.4 GHz,
avec 3 canaux radio disponibles.

802.11c

Pontage 802.11
vers 802.1d

La norme 802.11c n'a pas d'intrt pour le grand public. Il s'agit

uniquement d'une modification de la norme 802.1d afin de pouvoir
tablir un pont avec les trames 802.11 (niveau liaison de donnes).

International

La norme 802.11d est un supplment la norme 802.11 dont le but

est de permettre une utilisation internationale des rseaux locaux
802.11. Elle consiste permettre aux diffrents quipements
d'changer des informations sur les plages de frquence et les
puissances autorises dans le pays d'origine du matriel.

802.11a

802.11d

Amlioration
802.11e

802.11f

de la qualit de
service

Itinrance
(roaming)

La norme 802.11e vise donner des possibilits en matire de

qualit de service au niveau de la couche liaison de donnes. Ainsi
cette norme a pour but de dfinir les besoins des diffrents paquets
en terme de bande passante et de dlai de transmission de telle
manire permettre notamment une meilleure transmission de la
voix et de la vido.
La norme 802.11f est une recommandation l'intention des
vendeurs de point d'accs pour une meilleure interoprabilit des
produits. Elle propose le protocole Inter-Access point roaming
protocol permettant un utilisateur itinrant de changer de point
d'accs de faon transparente lors d'un dplacement, quelles que
soient les marques des points d'accs prsentes dans
l'infrastructure rseau. Cette possibilit est appele itinrance (ou
roaming en anglais)

802.11g

La norme 802.11g offre un haut dbit (54 Mbps thoriques, 30

Mbps rels) sur la bande de frquence des 2.4 GHz. La norme
802.11g a une compatibilit ascendante avec la norme 802.11b, ce
qui signifie que des matriels conformes la norme 802.11g
pourront fonctionner en 802.11b

802.11h

La norme 802.11h vise rapprocher la norme 802.11 du standard

Europen (HiperLAN 2, do le h de 802.11h) et tre en conformit
avec la rglementation europenne en matire de frquence et
d'conomie d'nergie.

802.11i

La norme 802.11i a pour but d'amliorer la scurit des

transmissions (gestion et distribution des cls, chiffrement et
authentification). Cette norme s'appuie sur l'AES (Advanced
Encryption Standard) et propose un chiffrement des
communications pour les transmissions utilisant les technologies
802.11a, 802.11b et 802.11g.

802.11IR

La norme 802.11j a t labore de telle manire utiliser des

signaux infra-rouges. Cette norme est dsormais dpasse
techniquement.

802.11j

La norme 802.11j est la rglementation japonaise ce que le

802.11h est la rglementation europenne.

Tableau 1. Diffrentes normes 802.11

17

1.3

Les rseaux sans fil ad hoc

Introduction
Un rseau sans fil ad hoc est un rseau sans fil d'entits mobiles lies entre elles par
des liaisons base d'ondes radio sans infrastructure fixe ni administration centralise.
Chaque nud joue le rle d'hte ou de routeur un instant donn. L'interconnexion
de tous les nuds mobiles forme une topologie temporaire dynamique qui se dploie
aisment.
Par ailleurs, la mobilit des nuds leur pose diffrentes contraintes sur les ressources
ainsi que leurs capacits. Un nud mobile peut bouger librement sans prvenir son
entourage qui doit dtecter l'absence de ce dernier et surtout maintenir une vue
cohrente de l'environnement chaque instant.
Les protocoles de routage ad hoc doivent acheminer les paquets leurs destinations
indpendamment des changements de topologie. Pour rpondre ces exigences, le
protocole doit converger rapidement vers la stabilit pour assurer la rsolution des
ruptures de liaisons qui sont dues la mobilit et interrompent le trafic.
La reprsentation des rseaux se fait classiquement sous forme de petits cercles pour
les nuds et des segments de droite pour les liaisons entre ces nuds. Pour les
rseaux ad hoc, la reprsentation peut tre diffrente du fait qu'il n'y a plus de liaisons
cbles. Alors le segment est remplac par un cercle concentr sur le nud pour
reprsenter la zone de connexion du nud ou en d'autres termes son rayon de
propagation.
La figure 1.1 reprsente un simple rseau ad hoc.
Sur cette figure, le nud A ne peut communiquer qu'avec le nud B et le nud C ne
peut communiquer qu'avec B cause de leur limitation du rayon de propagation. Par
contre B peut communiquer avec les deux, ce qui lui attribuera la fonction de routeur
qui achemine le trafic entre les deux htes.

Nud A

Nud B
Nud C

Limite de la zone
de propagation

FIG 1.1 - Simple rseau ad hoc.

18

Dans ce type prcis de rseaux ad hoc que nous tudions, les nuds sont dots
d'une antenne radio leurs permettant d'mettre leurs signaux et de rceptionner ceux
mis par leurs voisins. Pour chaque nud, est dfinie une zone de propagation quand
il est entrain d'mettre. Tout nud se trouvant sur cette zone est appel un voisin et il
ne peut mettre au mme moment, parce que la frquence utilise est unique pour
tous les nuds. Les interfrences empchent les metteurs d'mettre directement sur
le support. Chaque metteur doit tout d'abord couter sur le mdium puis met s'il
est libre sinon attendre un moment, ce protocole vite les collisions provoques par
deux missions simultanes exemple de ce protocole CSMA/CA (Carrier Sense,
Multiple Access/Collision Avoidance). Sinon un autre protocole qui dtecte les
collisions est aussi valable il s'appelle CSMA/CD (Carrier Sense Multiple Access /
Collision Detect). La norme IEEE 802.1116 [7] utilise ces fonctions soit pour viter les
collisions comme pour le CSMA/CA, soit pour dtecter les collisions et programmer
une rediffusion aprs pour le CSMA/CD.

1.3.1 Caractristiques des rseaux ad hoc

Les rseaux mobiles ad hoc ont plusieurs caractristiques ; nous citons certaines
d'entre elles :
-

Topologie dynamique : la topologie du rseau est chaque instant dfinie par

les positions des nuds qui se dplacent arbitrairement formant ainsi un
graphe

d'interconnexion

compos

de

liaisons

unidirectionnelles

et

bidirectionnelles.
-

Liaisons dbit variable et bande passante limite : la capacit radio est

infrieure celle des rseaux cbls surtout si nous prenons en considration
les interfrences, le bruit et les accs multiples au mdium qui rduisent
considrablement la bande passante.

nergie limite : Le nomadisme des nuds ne leur permet pas de se dplacer

avec d'normes batteries, de ce fait une bonne gestion d'nergie doit tre mise
en place pour utiliser le minimum d'nergie et des modes de mise en veille sont
prvoir.

Scurit limite : Compte tenue de la souplesse de dploiement des rseaux

ad hoc, n'importe quel nud peut faire partie du rseau juste en se plaant
dans une zone de propagation, o il pourra couter tout ce qui passe par le
mdium physique; ce qui rduit la scurit et s'oppose la confidentialit. Le
groupe de travail MANET (Mobile Ad-Hoc Network [8]) de IETF (The Internet
Engineering Task Force [9]) aborde ce problme et prvoit des mthodes de

16

IEEE 802.11 : Norme de transmission de donnes par ondes radio pour les rseaux locaux.

19

chiffrement, d'authentification inter-routeur, soit par simple cl partage ou

mme jusqu' une infrastructure de cls Publiques/Prives [1].

1.4 Le routage classique

Le routage s'occupe de l'acheminement des paquets vers les destinations dsires. Il
offre des services aux diffrentes applications qui dsirent envoyer des donnes
d'autres applications se trouvant dans d'autres rseaux distants. Il existe plusieurs
protocoles de routage mais appartenant deux classes majeures, les protocoles de
routage statiques et dynamiques.
Dans le routage statique, les entres de la table de routage sont cres par dfaut
avec la configuration de l'interface ou par des commandes. Ce type de protocoles est
gnralement utilis pour les rseaux de petite taille surtout s'ils comportent un seul
point de connexion.
Les protocoles de routage ad hoc sont bass sur des algorithmes distribus. Les
routeurs communiquent entre eux pour s'changer l'information des rseaux auxquels
ils appartiennent et avec lesquels ils peuvent communiquer, ainsi chaque changement
dans le rseau est signal et tous les routeurs auront mis jour leurs tables de
routage [2].
Suivant le fonctionnement et la stratgie des protocoles de routage, nous distinguons
les principaux protocoles :
1.4.1 Les Protocoles tat de Liaisons Leur stratgie est d'envoyer des paquets
du type (LSP Link State Packets) entre les routeurs contenant l'adresse de tous les
voisins avec le cot des liaisons qui les joignent. Ainsi, chaque routeur sera capable
de calculer indpendamment des autres routeurs le chemin le plus court vers
n'importe quelle destination, exemple OSPF (Open Shortest Path First [4]).
1.4.2 Les

protocoles

Vecteur

de

Distance

Chaque routeur

transmet

priodiquement un vecteur comportant pour chaque destination connue du routeur :

son adresse, distance depuis le routeur qui transmet le vecteur jusqu' cette
destination. Le vecteur de distance n'est qu'un rsum de la table de routage. Chaque
routeur reoit ces vecteurs de distance provenant de ses voisins immdiats et se base
sur cette information pour construire et mettre jour sa table de routage, exemple de
protocoles, RIP (Routing Information Protocol [2]).

20

1.4.3 Source routing Ce genre de routage propose pour chaque paquet mis un
chemin complet ds sa mise sur rseau jusqu' sa destination, ce qui conomise le
temps de calcul du meilleur chemin et surtout de routage au niveau des routeurs
intermdiaires et vite aussi les boucles. Cette stratgie peut causer des surcharges
au niveau des routeurs. La figure 1.2 prsente un simple exemple pour ce type de
routage.
Les paquets mis par la source comportent le chemin qu'ils doivent parcourir (N1-N2N5-N8, sur l'exemple de la figure 1.2, ainsi les routeurs intermdiaires n'auront pas
consulter leurs tables de routage.

N2

N1-N2-N5-N8
N1-N2-N5-N8

N5

Destination
N8

N1-N2-N5-N8

Source

N7
N1

N4
Paquet de donnes

2
N6

N de l'tape

N1-N2-N5-N8 Le chemin suivre

N3

FIG 1.2 - Routage par Source Routing .

1.4.4 Flooding Le flooding (l'inondation) est une technique utilise dans le routage
classique pour le multicast (Routage d'une source vers plusieurs rcepteurs). Elle
prsente beaucoup d'inconvnients comme l'usage inutile de la bande passante. Son
principe est trs simple, le nud qui dsire envoyer des paquets, les transmet ses
voisins (de mme zone de propagation) qui, leur tour les retransmettent leurs
voisins et ainsi de suite jusqu' ce que tous les nuds du rseau aient le paquet.
L'estampille est quand un paquet passe plusieurs fois par un mme serveur, pour cela
l'usage d'un numro de srie unique pour chaque paquet est possible, il sera
incrment par la source chaque nouveau paquet.
Sur la figure 1.3, nous voulons que l'metteur envoie les paquets sur toutes ces
connexions ainsi que tous les autres nuds intermdiaires (flches en ligne continue
sur la figure 1.3).Quelques-uns peuvent recevoir plusieurs fois le mme paquet, alors
ils l'ignorent (flches en pointills sur la figure 1.3). Ainsi de suite jusqu' atteindre le
ou les rcepteurs.

21

Paquet de donnes
Paquet retransmit
inutilement

1
2

N de l'tape

3
2

Emetteur

3
1
2

Rcepteur
2

Rcepteur

FIG 1.3 - Routage par Flooding .

1.5 Protocoles de routage dans les rseaux ad hoc

Les protocoles de routage classiques ne peuvent pas s'appliquer aux rseaux ad hoc
compte tenu de leur mobilit et support de transmission spcifique. Il faut adapter ces
protocoles pour ce genre de rseaux qui changent de topologie frquemment et
alatoirement. Les protocoles de routage ad hoc sont diviss en trois catgories, deux
principales et la troisime est issue de leur combinaison, ces catgories sont : Les
protocoles ractifs, les protocoles proactifs et les protocoles hybrides. La diffrence
entre les deux grandes catgories est que les ractifs doivent initialiser le chemin
entre la source et la destination avant d'envoyer les donnes par une demande de
chemin. Par contre les proactifs ont dans leur table de routage tous les chemins vers
tous les nuds du rseau, il ne leur manque que d'utiliser ce chemin pour envoyer
directement les donnes la destination. Les protocoles hybrides sont le compromis
entre les protocoles ractifs et les protocoles proactifs. Ils se comportent en proactifs
juste dans leur voisinage. Par contre, pour trouver des chemins plus longs ils
procdent en ractifs.

1.5.1 Protocoles ractifs

Ce type d'algorithmes ne ncessite pas le maintien permanent de tables de routage, ni

une connaissance pralable de la topologie du rseau au moment de l'envoi. Par
contre une phase prcdant l'envoi consiste rechercher le chemin vers la destination
voulue. Cette phase est initialise par la diffusion d'un paquet dcouverte de route
depuis la source sur tout le rseau et redirig par chaque nud intermdiaire

22

jusqu' atteindre la destination, o ce paquet sera retransmis vers la source sous

forme d'une rponse rponse de route traant ainsi un chemin vers la destination,
Des algorithmes ont t proposs, des amliorations et des valuations sont en cours.
Nous citons titre d'exemple AODV, DSR et TORA.

1.5.1.1 AODV (ad hoc On-Demande Distance-Vector [11])

Ce protocole est bas sur l'algorithme de routage Distance-Vector (DV). Il admet aussi
le routage Multicast, gnre des routes fraches sans cycle parce qu'il utilise le
numro de squence sur les paquets. Quand une source veut transmettre des
paquets, elle tente tout d'abord de trouver le chemin vers sa destination en diffusant
un paquet de demandes de chemin Route Request note [Rreq] tous ses voisins. A
leurs tours, les voisins retransmettent ce mme paquet mais en enregistrant l'adresse
du prdcesseur et en ajoutant sa propre adresse pour le successeur, pour garder la
trace du chemin parcouru, et ainsi de suite jusqu' ce qu'il soit arriv destination qui
aprs son acceptation de la demande, transmet sa rponse Route Reply note [Rrep]
la source directement en suivant le chemin inverse ou bien en diffusion [Broadcast].
A la rception de [Rrep] que la source attendait, elle enregistre localement le chemin
vers sa destination qui reste valide pour un temps prcis, sauf dans le cas d'une
rupture de liaison signale par l'un des nuds de ce chemin. Dans ce cas la source
relance un autre [Rreq] aprs une mise jour de sa table.
Une topologie mixte entre rseaux sans fils (ad hoc) et rseaux filaires est simple
mettre en uvre. AODV provoque moins de message de contrle en crant des
routes juste la demande et il s'oppose aussi au maintien d'une liste complte des
routes, de ce fait il est appel routage sur demande. Les nuds qui ne sont pas sur
un chemin choisi ne maintiennent pas l'information de routage et ne participent pas
aux changes de tables de routages. Chaque nud maintient son numro de
Squence avec l'ID de la diffusion (qui est incrment chaque [Rreq] initialis par un
nud). Pour garantir des routes sans cycle et rcentes. La source inclus dans le [Rreq]
le numro de squence le plus rcent pour la destination voulue, et tout nud
intermdiaire peut rpondre ce [Rreq] s'il possde pour cette destination un numro
de squence plus grand ou gal celui contenu dans le [Rreq]. Durant les
retransmissions des [Rreq], chaque nud enregistre l'adresse de son voisin
prdcesseur et ce pour garantir le chemin inverse. Dans le cas d'une rception du
mme [Rreq], les nuds le rejettent. Durant le retour (chemin inverse) chaque nud
met jour sa table de routage vers la destination qui avait mis le [Rrep] (voir Figure
1.4). Chaque entre de la table de routage est efface si celle-ci n'tait pas

23

utilise ou mise jour aprs un temps dtermin.

AODV ne supporte que l'utilisation des liens symtriques. Dans le cas de la mobilit
des nuds :
-

Si la source bouge elle n'a qu' rmettre un nouveau

Si un nud appartenant au chemin change de position, son nud ascendant

notifie par un message de rupture de lien ([Rrep] positionn l'infini) chaque
nud actif du chemin ascendant, et ainsi de suite jusqu' ce que la source soit
informe de cette rupture de lien et elle va dcider de lancer nouveau un
[Rreq] si elle tient toujours envoyer cette destination.

Sur la figure 1.4 (a), la rponse la [Rreq] est envoye par un nud intermdiaire en
suivant le chemin inverse. Par contre sur la figure 1.4 (b), le [Rrep] est transmis par la
destination D de nud l'autre jusqu' la source S.

Route request

Route reply
Nud
Rayon de
propagation

S
Temps mort

(a) Formation par chemin inverse

(b) Formation par chemin transmis

FIG 1.4 - Formation de chemin sous AODV

1.5.1.2 DSR (Dynamic Source Routing [12])

Ce protocole est ractif du fait que les nuds doivent dcouvrir la route avant chaque
transmission. L'avantage de cet algorithme est l'allgement du rseau des paquets
d'erreurs et indication de rupture de liens, o chaque couche MAC17 (Medium Access
Control [10]) doit informer son protocole de la rupture de ses liens et une mise jour
est effectue. Alors le principe de cet algorithme est la dcouverte du chemin puis son
maintien.

17

La couche MAC : Responsable pour contrler l'accs au rseau.

24

La dcouverte s'effectue par l'envoi d'un [Rreq] et l'attente du [Rrep] qui pourrai
tre envoy soit par la destination soit par un nud existant sur le chemin et
possdant dans son cache la suite du chemin vers la destination.

Le maintien c'est en fait un suivi des transmissions des paquets dans l'attente
d'un message d'erreur envoy par un nud qui prcde le nud qui n'est plus
sur son rayon de propagation (n'est plus un voisin) alors qu'il l'tait avant et sur
le mme chemin vers la destination. Ds rception du message d'erreur
contenant l'adresse du nud sortant, la source met jour ses caches en
tronquant tous les chemins contenant le nud en cause. Ds qu'un nud
dsire envoyer un paquet, il doit d'abord consulter sa table des routes si un
chemin vers sa destination qui n'a pas encore expir existe il l'utilise, sinon il
lance une requte de recherche de chemin [Rreq] avec l'adresse de la
destination, son adresse et un numro d'identification unique. Chaque nud
intermdiaire vrifie sur son cache s'il possde une entre vers cette
destination, sinon il ajoute son adresse la liste des adresses contenues dans
le paquet et l'envoie vers ses liens sortants (Figure 1.5). Pour limiter le nombre
de demandes rptes chaque lien vrifie si cette demande n'a pas t traite
avant et si son adresse ne figure pas sur la liste des nuds transits par le
paquet [Rreq]. Si la rponse [Rrep] doit tre envoye par le nud destination il
ne fera que copier la liste des nuds transits qui est dans le [Rreq] dans
[Rrep] et l'envoyer la source. Sinon si un nud intermdiaire est charg de le
faire, alors il ajoute la liste des nuds visits l'entre de sa table des routes
qui concide avec la destination (si elle est toujours valide). Le paquet rsultant
[Rrep] sera transmis la source soit en suivant le chemin inverse (si
l'algorithme supporte les routes symtriques) ou bien par une initialisation de
route vers la source faute dune entre de table pour cette source. Si une
erreur de liaison est entendue, tout nud doit enlever le nud en question de
toute sa table et tronquer toutes les routes le contenant en ce point prcis.
Pour router les messages d'erreurs, des acquittements sont utiliss pour
vrifier le bon fonctionnement de ces notifications o l'acquittement passif est
utilis aussi quand les mobiles sont capables d'couter le prochain routage des
nuds de la zone de propagation.

Sur la figure 1.5 (a), la source diffuse un [Rreq] qui se propage dans tout le rseau
en gardant trace du chemin parcouru. La rponse [Rrep] de la destination que
nous pouvons voir sur la figure 1.5 (b), est envoye la source suivant le chemin
emprunt par [Rreq].

25

N2

N2

N5

Destination

N1-N2-N5

N1-N2-N5-N8

N1-N3-N4-N7

Source

N7
N1

N8

N1-N2-N5-N8

N1-N2-N5-N8

3
N1

Destination

N8

N5

N1-N2

N7

Source

N1-N3-N4

N1

N1-N3-N4

N4
N1

N1-N3-N4-N6

N4

1
2

Route request

3
N1-N3

Route reply

N1-N3-N4

N6

N6

N de l'tape

N3

N3

N2-N5-N8

Le chemin suivi

(a) Construction de l'enregistrement du

chemin durant la dcouverte de la route.

(b) Propagation de la rponse de la route

avec l'enregistrement du chemin.

FIG 1.5 Cration dune route dans DSR [5]

1.5.1.3 TORA (Temporally Ordered Routing Algorithm [13])

TORA produit seulement le mcanisme de routage et repose sur le protocole IMEP
(Internet MANET Encapsulation Protocole [15]), le protocole labor pour supporter
les oprations de nombreux algorithmes de routage ou d'autres protocoles de couches
suprieures dans les rseaux mobiles ad hoc.
TORA repose sur 3 fonctions :
- Cration de route.
- Maintien de route.
- Effacement de route.
A tout nud lui est associe une hauteur. Les messages transitent d'un nud de
grande hauteur un autre de plus petite hauteur.
- La cration de route : elle est effectue la demande de la source [QRY], le nud
qui possde (dans son cache) la route vers la destination on le nud destination luimme envoi la rponse UPD la source contenant sa hauteur et avec cette mthode
la source aura plusieurs routes.
- Maintien de route : il est effectu grce aux messages de contrle du voisinage (voir
Figure 1.6).
- L'effacement de route : il est effectu l'issue de la rception du message
deffacement Clear packet [CLR].
TORA repose sur le protocole IMEP pour rduire le nombre de messages de contrle.
La hauteur assigne chaque nud aide beaucoup pour la cration du graphe
dirig acyclique DAG18 o la destination reprsente la racine.
18

DAG : Graphe Dirig Acyclique (Directed Acyclic Graph).

26

Avec la mobilit des nuds, le DAG est bris quelque part et une maintenance est
ncessaire. La synchronisation est un facteur important pour TORA parce que la
hauteur dpend du temps logique de rupture de liens TORA prsume que tous les
nuds sont synchroniss depuis une source unique (comme le Systme de Position
Globale GPS). La mtrique de TORA est un quintuple qui comporte :
-

Priode logique d'une rupture de lien.

Un ID unique qui dfinit la nouvelle rfrence des niveaux.

Un bit indicateur de rflexion.

Un paramtre d'ordre de propagation.

Un ID unique du nud.

Les trois premiers lments reprsentent la rfrence de niveau, o une nouvelle

rfrence de niveau est dfinie chaque fois qu'un nud perd son dernier lien
descendant due une rupture de lien. L'effacement de route produit essentiellement
un broadcast du message [CLR] sur tout le rseau pour effacer toute route non valide.
Dans TORA, il peut arriver que des oscillations se produisent surtout quand diffrentes
configurations de nuds coordonns dtectent concurremment des partitions. Comme
TORA utilise la coordination inter nodale, son problme d'instabilit se rapproche de
celui du compte l'infini de l'algorithme de routage Vecteur de Distance, par contre
sur TORA les oscillations sont temporaires et les routes convergeant tt ou tard.
Sur la figure 1.6, quand le nud D dtecte une erreur de liaison avec le F, il diffuse un
message d'erreur [CLR] sur tout le rseau. Ses voisins font de mme aprs rception
du message. Une fois le message d'erreur reu par la source A, elle utilise un autre
chemin pour envoyer ses donnes sa destination parce que TORA gnre plusieurs
routes.
B
A

B
A

(1)

(2)

B
A

B
A

(3)

(4)

Renversement de liaison

(a) A : Source

chec de liaison

G : Destination

FIG 1.6 - Maintenance de route sous TORA.

27

1.5.2 Protocoles Proactifs

Ce type d'algorithme est diffrent du prcdant du fait qu'il est principalement bas sur
la garde des tables de routage au niveau de chaque nud du rseau. Chaque
metteur consulte sa table pour trouver une entre vers la destination voulue.
Plusieurs algorithmes ont t proposs et mme implments et tests. Exemple
DSDV, CGSR, WRP et OLSR.
1.5.2.1 DSDV (Destination Sequenced Distance-Vector Routing [14])
Ce protocole est bas sur le mcanisme de routage classique de Bellman-Ford.
Chaque nud du rseau maintient une table de routage vers toute destination
possible. La mise jour des tables de routage est faite priodiquement Pour allger la
charge du le rseau, il existe deux mthodes de mise jour :
-

Full dump : Des paquets transportant toute information disponible du routage et

peut demander plusieurs NPDUs, leur transmission est occasionnelle.

Incremental : Des paquets portent juste l'information de changement sur les

tables de routage depuis la dernire mise jour. Les nuds maintiennent
aussi une autre table o ils enregistrent les paquets envoys.

1.5.2.2 CGSR (Clusterhead Gateway Switch Routing [17])

Ce protocole dcompose la topologie en un groupe de clusters o dans chaque cluster
un algorithme distribu est charg d'lire un leader qui prend la responsabilit de tout
le cluster (voir Figure 1.7). Plusieurs schmas de routage sont accepts. L'allocation
de la bande passante est aussi possible. CGSR utilise DSDV comme protocole de
routage fondamental, mais ici l'approche est hirarchique o pour le routage il faut
passer par les ttes de cluster. La gestion de ce systme de ttes de cluster peut
rduire les temps d'acheminements des paquets utiles. Une passerelle Gateway est le
nud charg de router les paquets entre deux ttes de cluster. Le routage s'effectue
dans l'ordre : Source - Tte de cluster - Gateway - ..... - Tte de cluster - Gateway Destination. Chaque nud garde une table de membres de clusters et une autre table
de routage. Elles sont mises jour en utilisant DSDV. Avec ces deux tables chaque
nud sera en mesure de dterminer la tte de cluster le plus proche de sa destination.
Sur la figure 1.7, nous remarquons que le nud 1 pour envoyer au nud 8, il doit
s'adresser la tte de cluster auquel il appartient puis c'est elle qui prend en charge le
reste du routage en passant par les Gateways et mme d'autres ttes de clusters.

28

Cluster

Nud
Passerelle
5

Tte de cluster

FIG 1.7 - Routage du nud 1 au nud 8 par CGSR.

1.5.2.3 WRP (Wireless Routing Protocol)

Chaque nud dispose de 4 tables
- Table de destination
- Table de routage
- Table des cots des liens
- Table de la liste des messages retransmettre (MRL)19
Chaque entre de la table MRL contient :
- Numro de squence du message de mise jour.
- Un compteur de retransmission.
- Un vecteur de flag des demandes d'acquittement avec une entre par voisin.
- Une liste de mise jour qui sera envoye dans les messages de mise jour
Les enregistrements de la MRL mis jour depuis la rception d'un message de mise
jour doivent tre retransmis aux voisins qui doivent accuser rception. Les messages
sont envoys seulement entre les nuds voisins et contenant une liste de mise jour
(destination, distance la destination, prdcesseur de la destination), aussi bien une
liste de rponses indiquant quels nuds devraient reconnatre la mise jour. Les
nuds envoient des mises jours aprs traitement de mise jour reue ou bien aprs
avoir dtecter des changements dans les liens voisins. En cas de rupture de liens, un
message de mise jour est envoy aux voisins qui leurs tours mettent jour leurs
tables des distances et cherchent une nouvelle route par d'autres nuds. Chaque
changement est signal par un message de mise jour aux voisins. Sans les
messages de mise jours, les nuds s'envoient mutuellement des paquets hello
pour confirmer l'existence et la validit des liaisons sinon nous pourrions dduire
qu'une liaison vient d'tre perdu. Dans le cas d'une rception d'un nouveau hello

19

MRL : Message Retransmission List (Liste des Messages Retransmettre).

29

envoy par un nouveau nud, nous linsrons dans la table de routage et une copie
de cette table sera envoye au nouveau nud. L'exception majeure de cet algorithme
est qu'il vite le problme du compte l'infini en obligeant chaque nud
d'effectuer des tests consistants sur les informations disponibles depuis les voisins.
Ainsi il n'y aura plus de boucle et un routage plus rapide est garanti.
1.5.2.4 OLSR (Optimized Link State Routing [16])
Protocole pro-actif prsente une optimisation de link state dont:
-

La rduction de l'impact de l'inondation sur le rseau, par la rduction du

nombre de nuds participants juste aux Multi-Points Relais [MPR], ce qui
conomise la bande passante.

La minimisation de la taille des messages de contrle, qui ne contiendront que

l'information du voisinage de l'expditeur mais pas de tous le rseaux.

En plus des routes sans cycle qui sont garanties, OLSR offre des routes
symtriques de plus court chemin.

Des paquets [TC] Topology Control sont priodiquement diffuss dans le rseau,
ne transitent que par les [MPR] et ne contiennent que la liste des relais multipoints
[MPR].
Un systme d'lection des [MPR] est mis en place et chaque nud lu reoit
l'information dans un message hello .
OLSR supporte l'adressage IP, o chaque nud est associ une adresse IP
rgulire, de plus il ne demande aucun changement sur le format des paquets IP. Le
protocole n'intervient que sur la gestion de la table de routage.

1.5.3 Protocoles hybrides

Ce type de protocoles est un compromis entre les ractifs et les proactifs et ce sont
des protocoles qui d'un ct utilisent une procdure de dtermination de route sur
demande mais de l'autre un cot de recherche limit.
ZRP (Zone Routing Protocol [18])
Le protocole ZRP est un modle hybride entre un schma proactif et un schma
ractif. Le principal problme dans l'laboration d'un protocole de routage pour rseau
ad hoc rside dans le fait que pour dterminer le parcours d'un paquet de donnes, le
nud source doit au moins connatre les informations permettant d'atteindre ses
proches voisins (voir Figure 1.8 (a)). D'un autre ct, la topologie d'un tel rseau
change frquemment. De plus, comme le nombre de nuds peut tre lev, le
nombre de destinations potentielles peut galement l'tre, ce qui requiert des

30

changes de donnes important et frquents. Donc la quantit de donnes de mise

jour du trafic peut tre consquente. Cela est en contradiction avec le fait que toutes
les mises jour dans un rseau interconnect ad hoc circulent dans l'air et donc sont
coteuses en ressources. Le protocole ZRP limite la procdure proactive uniquement
aux nud voisins et d'autre part, la recherche travers le rseau (voir Figure 1.8 (b)),
est effectue de manire efficace dans le rseau, contrairement une recherche
gnrale sur tout le rseau.
Sur la figure 1.8 (a), Le nud source S est centr dans un grand cercle en pointills
qui dlimite sa zone de routage rayon 2, dans laquelle il se comporte comme les
protocoles proactifs. Par contre, sur la figure 1.8 (b), pour atteindre sa destination D, le
nud S doit trouver le chemin avec des algorithmes ractifs parce que D est en
dehors de sa zone de routage rayon 2.
L

K
J

F
E

C
C

D
B

H
G

A
A

F
I

(a) Zone de routage rayon 2

(b) Opration interzone

FIG 1.8 - Le routage dans ZRP.

1.6 Proprits cibles par les protocoles de routage des rseaux ad hoc
Les protocoles ad hoc vrifient des proprits que d'autres n'ont pas, mais il reste
encore d'autres dignes d'intrt. Nous citons certaines proprits pour les deux cas :
1.6.1 Distribution des oprations
Il faut que chacun des nuds agisse tout seul suite un vnement et il ne doit
dpendre d'aucun autre nud. Tous les nuds sont au mme niveau et il n'existe
aucune hirarchie ni de structure centralise pour la supervision, seuls les trois tats
sont accessibles rcepteur, metteur ou routeur.

31

1.6.2 Routes sans cycle

Le protocole doit gnrer des routes sans cycle loop-free ce qui nous vite les
pertes sur la bande passante ainsi que la consommation de ressources CPU ou
d'nergie.
1.6.3 Opration la demande
La raction la demande permet d'conomiser de l'nergie. Parce qu'avec les
messages priodiques, non seulement la bande passante est mal exploite mais en
plus l'nergie est utilise inutilement dans la plupart des cas.
1.6.4 Liens unidirectionnels
L'usage de la technologie radio provoque des liaisons unidirectionnelles surtout si des
obstacles physiques se trouvent dans l'environnement, o nous trouvons un nud qui
peut atteindre un autre par contre la rciproque ne peut se faire. L'acceptation des
liens unidirectionnels amliore considrablement les performances du protocole.
1.6.5 La scurit
Les rseaux ad hoc sont trs sensibles aux attaques. Des mesures de scurit sont
appeles tre mis en place et l'usage de l'authentification, du tatouage de
linformation et la cryptographie semblent ncessaires. Il y a mme des discussions
sur IP-sec qui introduit les tunnels pour le transport des paquets.
1.6.6 Conservation d'nergie
tant donn que l'nergie emmagasine dans les batteries des nuds mobiles est
rduite et trs limite, il serait ncessaire que les protocoles proposs supportent le
mode veille au niveau de chacun des nuds.
1.6.7 Multi-routes
Si chaque nud peut stocker plusieurs routes vers la mme destination, les
changements frquents de la topologie influeront peu sur le trafic o nous trouvons
moins de congestions et peu de paquets de contrles issues des dcouvertes de
routes.
1.6.8 Le support de la qualit de service
Plusieurs modles de qualit de service sont envisageables pour les protocoles ad
hoc et beaucoup d'applications verront le succs, comme le support du trafic temps
rel et la rservation de la bande passante pour la vido confrence titre d'exemple.

32

1.7

Comparaison

Sur le tableau 1.2, une comparaison entre les diffrents protocoles de routage ad hoc
accentue les diffrences et met en valeur les proprits des chacun des protocoles [6].
Nous remarquons par ailleurs qu'aucun des protocoles ne supporte la conservation
d'nergie ou la qualit de service, ce qui pousse les recherches vers ces points prcis.

DSDV

AODV

DSR

CGSR

Routes sans cycle

Oui

Oui

Oui

Oui

Multi-routes

Non

Non

Oui

Oui

Distribution

Oui

Oui

Oui

Oui

WRP

OLSR
Oui,

ZRP

TORA (IMEP)

Oui

Oui

Non

Non

Non

Oui

Oui

Oui

Oui

Oui

Pas instantan

Non,
cycle temps

Ractif

Non

Oui

Oui

Non

Non

Non

Partiel

Oui

Liens unidirectionnels

Non

Non

Oui

Non

Non

Non

Non

Non

Support de la Qos

Non

Non

Non

Oui

Non

Non

Non

Non

Multicast

Non

Oui

Non

Oui

Non

Oui

Non

Non

Scurit

Non

Oui

Non

Non

Non

Non

Non

Non

Conservation d'nergie

Non

Non

Non

Non

Non

Oui

Non

Non

Diffusions priodiques

Oui

Oui

Non

Oui

Oui

Oui

Oui

Oui (IMEP)

TAB 2 - Tableau comparatif des diffrents protocoles de routage ad hoc [6]

33

Chapitre 2.
Cadre Exprimental

34

Etude de simulation
2.1 Introduction
Les documentations qui traitent sur les rseaux sans fil Ad hoc nous permettent de
connatre le type et caractristiques fonctionnelles de chacun des protocoles ainsi que
son algorithme de routage. Toutes les comparaisons sont faites sur un plan purement
thorique. Elles ne nous permettent pas de classer ces protocoles en fonction des
critres rels.
Depuis toujours la nature humaine rve de connatre le futur et dans notre cas, de
connatre les diffrents comportements des protocoles avant mme de les
implmenter et les commercialiser. Ltude de simulation offre cette vision du futur qui
est quasiment relle.
Une simulation sur les rseaux sans fil qui ne prend pas beaucoup de temps, nous
rapproche de lutilisation relle du protocole de routage. Ces deux grands avantages
nous aident slectionner les meilleurs protocoles qui ont un bon comportement dans
diffrents scnarios.

Les dveloppeurs de protocoles aussi font des tudes de

simulation pour amliorer les capacits de leur algorithme de routage.

Dans le cadre de notre projet nous avons opt aussi pour le cadre exprimental de la
simulation des rseaux ad hoc pour mieux comparer diffrents protocoles de routage,
tirer des conclusions et peut tre mme faire un pas vers lamlioration.
2.1.1 Les simulateurs de rseaux
Dans le monde de la simulation des rseaux informatiques, beaucoup de contributions
ont particip lenrichissement de ce domaine. La majorit des travaux effectus sont
dordre pdagogique et sont labors par des laboratoires informatiques travers le
monde.
Beaucoup daxes de recherches se basent sur ces simulateurs. En fonction des
particularits de chacun, les chercheurs choisissent le simulateur le plus appropri.
Les simulateurs les plus rpandus sont OMNET ++, NS-2 20 [22], SensorSIM,
GlomoSim [21], QualNet, Jist / SWANS, JSim, OPNET21 [23] Modeler [26].
2.1.1.1

Omnet ++22

Il est utilis sur la plate-forme Microsoft Windows (avec Cygwin), Unix. Sa licence est
gratuite pour les universitaires et pour toute utilisation non lucrative.
20

NS : The Netword Simulator

OPNET : Open NETwork
22
OMNET ++ : http://www.omnetpp.org/
21

35

Il ne semble pas particulirement prvu pour le sans-fil. Il nexiste pas de modles

spcifiques aux capteurs indiqus sur le site Web. Cependant Omnet++ semble
sduire de plus en plus la communaut scientifique et un nombre croissant de
modles est disponible.
2.1.1.2

NS-223

Il est utilis sur la plate-forme Unix (Linux, solaris, Mac OS X incertain), Microsoft
Windows. Sa licence est gratuite.
NS-2 est trs utilis pour les rseaux ad hoc et les rseaux filaires. Toutefois les
modles de couche physique sont simplistes. Le dveloppement des protocoles
s'effectue en C++ et en OTcl (volution objet de TCL). Les scnarios sont dcrits en
OTcl. La prise en main est peu aise ; en effet OTCL est peu connu et la
programmation en C++ ncessite de comprendre l'interface entre les deux langages.
L'analyse des rsultats est en gnral peu aise ; le rsultat de la simulation tant
essentiellement compos d'un fichier retraant l'ensemble des envois, rceptions et
suppressions de paquets. Un certain nombre de scripts ont t dvelopps (ou sont
en cours de dveloppement) pour faciliter cette analyse. Du fait de sa popularit, de
nombreux protocoles sont a priori disponibles pour NS-2. Quelques protocoles
spcifiques aux rseaux de capteurs sont disponibles.
2.1.1.3

SensorSIM24

Il est utilis sur la plate-forme Unix (Linux, solaris, Mac OS X incertain), Microsoft
Windows avec une licence gratuite.
Il s'agit d'un projet d'UCLA25 visant crer un simulateur spcifique aux rseaux de
capteurs sur la base de NS-2. Cependant, le projet vient de dmarrer et l'chancier
n'est pas clair. Les sources ont d'ailleurs t retires de la page du projet du fait de
l'absence de support.
2.1.1.4

GlomoSim26

Utilis sur la plate-forme Unix avec une licence gratuite pour les universitaires.
Peu de modles semblent disponibles. Le moteur de GlomoSim est bas sur la
bibliothque Parsec

27

. Le simulateur peut donc tre paralllis. Toutefois,

l'apprentissage de cette API peut se rvler difficile.

23

NS-2 : http://www.isi.edu/nsnam/ns/

24

SensorSIM : http://nesl.ee.ucla.edu/projects/sensorsim/
UCLA : Universit de Californie Los Angeles

25
26
27

GlomoSim : http://pcl.cs.ucla.edu/projects/glomosim/
Parsec : Le langage de programmation de GlomoSim

36

2.1.1.5

QualNet28

Il est utilis sur la plate-forme Microsoft Windows, Linux, Solaris. Simulateur payant.
Des rductions sont appliques pour la recherche.
QualNet est la version commerciale de GlomoSim. Une documentation plus fournie
que GlomoSim et un support technique sont fournis. Une interface graphique est aussi
intgre au logiciel.
Le projet europen Bison a choisi, aprs tude comparative de l'ensemble des
simulateurs, d'utiliser ce produit pour sa facilit d'utilisation et son caractre inter
oprable.
2.1.1.6

Jist / SWANS29

Il est dvelopp sous Java. Sa licence est gratuite. Jist est le moteur de simulation,
SWANS est le "simulateur", c'est--dire une interface de Jist.
Jist permet d'utiliser, comme gnrateur de trafic, n'importe quelle application Java. Il
souffre cependant du manque de modles li sa jeunesse. Jist adopte un mode de
programmation similaire J-Sim (essentiellement Java). Les protocoles sont conus
comme des composants indpendants interconnects par des interfaces. Concernant
l'aspect passage l'chelle, il prsente de meilleures performances que J-Sim. Le
calcul de la propagation est "optimis".
2.1.1.7

JSim30

Il est dvelopp sous Java. Sa licence est gratuite J-Sim est utilis l'INT31 et permet
de simuler des rseaux de l'ordre de 1000 noeuds. Le passage l'chelle peut
toutefois tre amlior. J-Sim souffre peut tre de sa jeunesse, quelques corrections
tant ncessaires. Le simulateur utilise quasi-indiffremment deux langages : Java et
TCL. L'architecture et le code sont suffisamment bien structurs pour permettre une
prise en main relativement aise. L'analyse des rsultats est aise. J-Sim permet
d'utiliser, comme gnrateur de trafic, n'importe quelle application Java. J-Sim semble
grer correctement l'aspect consommation d'nergie.
2.1.1.8

Opnet Modeler32

Il utilise la plate-forme Microsoft Windows (NT, 2000, XP) et Solaris. Sa licence est
payante. Il est possible de l'obtenir gratuitement en s'inscrivant au programme Opnet
pour les universits. Le dveloppement s'effectue en C++, au travers de l'interface du
28

QualNet : http://www.scalable-networks.com/products/qualnet.php
Jist / SWANS : http://jist.ece.cornell.edu/
30
JSim : http://chief.cs.uga.edu/~jam/jsim/
31
INT : Institut National des Tlcommunications
32
OPNET Modeler : http://www.opnet.com/
29

37

logiciel. Les scnarios se spcifient essentiellement travers la mme interface.

Toutefois, un mode batch est disponible et permet de raliser des batteries de
simulations. Les modles (protocoles) fournis avec le simulateur sont valids et prcis.
Toutefois, la majorit des modles sont crits par des dveloppeurs indpendants
(modles contribus) et ne sont pas tests par Opnet.

Cest un simulateur

vnements discrets qui va de la prparation de la simulation jusqu lanalyse des

donnes rsultantes [20]. Il est orient rseaux filaires pour lanalyse de
lordonnancement ainsi que la qualit de service. Il traite aussi bien les rseaux de
communication et les systmes distribus. Des chercheurs de lINPL33, ont fait usage
de OPNET sur des rseaux commutation de paquets pour tudier le respect des
contraintes temps rel. Un autre groupe de recherches, nomm IETF34, a travaill sur
la simulation du protocole OLSR35 avec OPNET o les chercheurs ont trouv quavec
un mcanisme hirarchique dans le protocole OLSR, ils arrivent rduire
considrablement le trafic de contrle sur des liens grand dbit [25].
Pour des raisons de disponibilit du simulateur au sein du laboratoire ainsi que dans la
continuit des projets antrieurs, nous avons opt pour NS-2 qui nous offre plus de
souplesse au niveau du paramtrage des protocoles sans fils.
Dans ce chapitre nous exposons notre tude exprimentale. Des protocoles de
routage ad hoc ont t l'objet de plusieurs simulations, o diffrents scnarios ont t
implments avec des paramtres varis.
2.2 Simulateur NS
Le simulateur rseau NS (Network Simulator) est un simulateur vnements discrets
orient objet, base sur le simulateur rseau REAL36. Au dpart, la version 1.0 de NS
a t dveloppe au Laboratoire National de Lawrence Berkeley 37 (LBNL) par le
groupe de recherche rseau. Son dveloppement fait maintenant partie du projet VINT
sous lequel la version 2.0 est sortie.
Le projet VINT [27] (Virtual InterNetwork Testbed) est dirig par l'Universit de
Californie du Sud et est financ par le DARPA38 en collaboration avec Xerox PARC39
et LBNL. Le but de ce projet est la construction d'un simulateur rseau qui offre des
outils et des mthodes innovatrices dans un environnement proche de la ralit.
33

INPL : Institut National Polytechnique de Lorraine (Nancy - France)

IETF : The Internet Engineering Task Force
35
OLSR : Optimized Link State Routing
36
Simulateur rseau REAL : http://www.cs.cornell.edu/skeshav/real/overview.html
37
LBLN : http://www-nrg.ee.lbl.gov/
38
DARPA : http://www.darpa.mil
39
Xerox PARC : http://www.parc.xerox.com/parc-go.html
34

38

Ce simulateur essaie de rpondre aux questions de mise l'chelle (simulation de

grandes topologies) et d'interaction entre protocoles dans des services intgrs
l'Internet (problmes d'htrognit). L'extension de NS nous a permit de simuler les
mobiles sans fil base d'ondes radio.
La philosophie gnrale de NS est assez simple. Comme entre, pour le simulateur de
rseaux (ns), sont introduits des fichiers de script en Otcl

40

qui dcrivent

l'environnement avec tous ses nuds, leurs dplacements et leurs trafics de donnes.
(Voir l'annexe A). Aprs que le simulateur traite ces fichiers, il gnre en sortie un
fichier que nous pouvons visualiser avec NAM41 pour voir le comportement des nuds
et des paquets mis (voir l'annexe B), ainsi qu'un autre fichier traces (journal) qui sera
analys par la suite pour gnrer des courbes.

FIG 2.1 - La simulation sous ns.

40
41

Otcl : Object Tool Command Language

NAM : Network Animator

39

Chapitre 3.
tude de cadrage

40

Les programmes implments pour la simulation qu'ils soient compils ou sous forme
de script ont t implments d'une faon qui facilite la modification des paramtres
de la simulation, o nous pouvons augmenter le nombre de nuds, changer la
manire du dplacement des nuds, augmenter ou diminuer la charge du rseau
ainsi que rajouter du trafic TCP, Le temps de la simulation lui aussi est paramtrable.
3.1 Gnrateur de scripts
Pour lancer un grand nombre de simulations. Il est ncessaire de disposer dun grand
nombre de scripts de description de topologie et de description de trafic de donnes
du rseau simuler. Chaque deux fichiers prsentent lentre du simulateur NS qui lui
permet de schmatiser le rseau simuler. Un programme paramtrable a t
dvelopp afin de rpondre ce besoin. Il gnre une diversit de scripts de topologie
et de trafic de donnes.
3.2 Paramtres de la simulation
Dans cette partie, nous allons prsenter les paramtres de nos simulations, le modle
de topologie, la propagation du signal radio, le trafic des donnes, la mobilit des
nuds et le modle de l'nergie utilis par chacun des nuds.
3.2.1 Le modle de topologie
Afin de simuler sur un environnement inspir de la ralit, un laboratoire simple
darchitecture a t imagin pour faire lobjet de notre cadre exprimental.
La topologie utilise est un terrain de 85x24m o les nuds mobiles peuvent se
dplacer dans un rectangle de 75x8m centr sur ce terrain.

FIG 3.1 - Terrain de simulation.

Ce terrain est une modlisation de couloir dans un immeuble qui spare deux
alignements de 15 bureaux de 5 mtres chacun (voir Figure 3.2)

41

FIG 3.2 - Architecture utilise.

Cette architecture nous permet de simuler un vritable immeuble o les nuds

peuvent se dplacer d'un bureau un autre tout en passant par un grand couloir.
Cette zone de mobilit des nuds est cadre par le rectangle gris.
3.2.2 Le modle de propagation
Il existe dans NS le modle de propagation radio Friss-space avec une attnuation
1/r2

pour

les

petites

distances.

Nous

avons

pris

lautre

modle

appel

TwoRayGround qui emploie une attnuation de 1/r4 pour les grandes distances.
Le type dantenne radio NS choisie est OmniAntenna qui reprsente les antennes
omnidirectionnelles o lmission est en 360. Tous les nuds que nous avons pris
ont la mme configuration et les mmes antennes d'o les mmes rayons de
propagation.
Le protocole de l'accs au mdium MAC42 (Medium Access Control [10]) que nous
avons utilis est le IEEE 802.1143 dvelopp par CMU44. Le support de transmission a
t configur pour fonctionner comme l'interface radio du Lucent WaveLAN DSSS
(914 Mhz) implment dans NS, avec une modification au niveau de la puissance de
transmission pour donner un rayon de connexion radio approximatif 35 mtres.
3.2.3 Le modle de trafic
Le modle de trafic utilis ne prend en charge que les trafics du type TCP avec
diffrentes tailles de paquets pour plusieurs combinaisons entre nombre de trafics
TCP (Agents TCP) et dbits utiliss. La figure 3.3 prsente l'architecture d'une
connexion TCP sous NS.

42

La couche MAC : Responsable pour contrler l'accs au rseau

IEEE 802.11 : Standard pour les rseaux locaux sans fil sans infrastructure.
44
CMU : Carnegie Mellon University
43

42

FIG 3.3 - Modle d'une connexion TCP dans ns.

L'attachement des agents TCP et Sink aux nuds, effectu dans la phase prparation,
est totalement alatoire. Le programme de gnration de scripts nous permet d'avoir
des connexions TCP alatoires pour les diffrentes simulations
3.2.4 Le modle de mobilit
Le modle de mobilit utilis donne le droit aux nuds de se dplacer entre les
bureaux alatoirement avec une vitesse alatoire aussi dans l'intervalle [1.5,3[ en
mtres par seconde suivant une trajectoire rectiligne. Cet intervalle de vitesse
correspond une vitesse normale de dplacement d'une personne portant un portable.
3.2.5 Le modle d'nergie
Le modle d'nergie utilis est celui implment dans NS et qui attribue aux nuds
une nergie initiale que nous avons fix 100 joules et, les nergies consommes,
soit par une transmission ou une rception, sont celles du modle radio Lucent
WaveLAN DSSS, 0.6 et 0.3 joules respectivement.
3.3 Les variables de la simulation
Dans nos simulations nous avons vari quelques paramtres de configuration dans les
scnarios pour accentuer les carts entre les diffrents protocoles. Ainsi nous pouvons
voir l'impact de chacun des critres de configuration de la simulation sur les rsultats
obtenus et surtout sur le comportement de chacun des protocoles. Chacune de ces
variables peut favoriser l'un ou l'autre des protocoles alors qu'au mme temps une
autre variable aggrave ou le dfavorise. Pour bien analyser ces protocoles dans
diffrentes conditions nous avons choisi les variables suivantes :

43

- Le type de protocole.
- Le nombre de nud.
- Le temps pour la mobilit.
- Le type de dplacement.
- Nombre d'agents TCP.
- Occupation de la bande passante.
3.3.1 Les protocoles simuls
Depuis les protocoles implments dans NS, nous avons pris ceux qui rentrent dans le
cadre des deux types tudis. Ractifs et Proactifs.
Les protocoles simuls taient :
- Ractif : AODV (Ad hoc On-Demand Distance Vector)
- Proactif : DSDV (Destination-Sequenced Distance-Vector)
- Ractif : DSR (Dynamic Source Routing)
3.3.2 Le nombre de nuds
Au niveau de nos topologies, nous avons vari la configuration du nombre de nuds
o le nombre maximum tait limit 30 nuds (un nud par bureau). Nous avons
simul aussi pour 10 et 20 nuds. Afin dtudier le comportement du rseau dans
diffrentes configurations.
Un rseau peu charg naura srement pas le mme comportement que quand il est
compos de beaucoup de nuds mobiles.
3.3.3 La mobilit
Pour assurer la diversit des configurations et tudier limpact de la mobilit sur la
stabilit du rseau nous avons pris en considration trois cas possibles pour la
mobilit :
- Simulation o tous les nuds sont stables.
- Simulation en trois phases : o le temps de la simulation est divis en trois phases :
la premire et la dernire ne comportent aucune mobilit. Seulement la deuxime
phase admet une mobilit des nuds afin dtudier la stabilit du trafic dans le rseau
durant la troisime phase.

44

- Simulation avec mobilit continue : Dans ce cas la mobilit est tendue sur le temps
de la simulation

3.3.4 Les dplacements

Cette variation traite les modes de dplacement. Un mode virtuel o la topologie des
bureaux nest pas prise en compte et un autre mode rel o les nuds se dplacent
de bureau en bureau via le couloir :
- Un dplacement direct d'un bureau un autre suivant un seul segment de droite.
- Un dplacement indirect en trois tapes (segments) o le nud doit passer par le
couloir pour changer de bureau, appel aussi dplacement en 'Z'.
La figure 3.4 prsente les deux manires de dplacement possibles des nuds.

FIG 3.4 - Types de dplacements des noeuds.

Avec ces deux variantes du dplacement de nuds nous pouvons tudier l'effet de la
trajectoire sur le routage dynamique ainsi que sur le trafic de donnes.
3.3.5 Nombre de trafic TCP
Le type de trafic que nous avons utilis est le TCP parce que nous pouvons tudier
lacquittement des paquets de donnes, ce qui va nous permettre un bon suivi du taux
d'erreurs et des bonnes rceptions. Par ailleurs, l'usage du protocole UDP ne nous
offre pas cette flexibilit danalyse du fait de labsence des acquittements des paquets
(perte de paquets sans trace.)
Pour varier du nombre de trafic TCP, nous avons vari le nombre de sources
mettrices afin dtudier la charge du rseau.

45

Les valeurs utilises dans nos simulations sont 3, 5, 7, 10 et 15 trafics TCP que nous
pouvons appeler aussi agents TCP. Un agent TCP est li qu un seul nud source.
3.3.6 Occupation de la bande passante
Le choix de ce paramtre a t tabli dans le but de voir le comportement du mdium
avec les diffrentes occupations de la bande passante pour tous les protocoles de
routage. Du fait que le mdium ne peut tre utilis un instant t que par un seul et
un seul metteur, sa sollicitation est gre comme les sections critiques.
Nous avons simul pour des occupations de 10%, 30%, 50% et 90% de la bande
passante afin de voir la capacit des protocoles de routage grer les goulots
dtranglement.
Pour exprimer ces pourcentages, nous avons vari la taille des paquets IP ainsi que
les frquences dmissions.

46

Chapitre 4.
Calcul de la simulation

47

Ce chapitre a pour but de prsenter ltude et calcules des simulations effectues. Les
mtriques utilises ainsi que les variables qui nous ont permis dtablir les courbes
reprsentatives. Cette phase de notre travail nous semblait trs importante du fait que
le bon choix des mtriques et des variables nous donne la possibilit dtablir des
schmas clairs et significatifs.
4.1 Mtriques de simulation
Chacune des mtriques que nous avons calcul dans nos simulations, nous aide a
mieux dpartager les protocoles suivant leur proprits dans diffrents scnarios. Une
mobilit excessive ou un trafic intense peuvent affaiblir lun des algorithmes mais pas
un autre dans les mmes conditions. De ce fait, nous avons dvelopp quelques
mtriques qui nous aident trouver les carts entre les algorithmes simuls. Cidessous nos six mtriques.
4.1.1 Les paquets de control
Dtermine le nombre de paquets mis par un nuds dans le but de grer le rseau
(identification, recherche de route, maintien de la table de routage, maintenance de
liens rompu etc).
Comme chaque protocole a son propre algorithme de routage. Nous esprons avec
cette mtrique, trouver lequel dentre eux utilise le minimum de paquets de control
pour un meilleur acheminement de paquets et une meilleure visibilit de la topologie
du rseau limporte quel instant.
4.1.2 Les paquets utiles
Dtermine le nombre de paquets de donnes utiles mises par un nud source ou
bien routeur pour un nud destinataire. Le trafic visible dans la simulation, nest pas
utile en entier. Les messages de contrle occupent une grande partie. Un bon
protocole fini par acheminer le maximum de donnes utiles avec un minium de control
dans nimporte quelle topologie mme si la mobilit est importante.
4.1.3 Les paquets perdus
Dtermine le nombre de paquets de control ou de donnes perdus physiquement dans
le rseau. Ces pertes sont issues de trafic important ou de temps dattente assez
lev. Les nuds routeurs perdent des paquets de donnes utiles ou mme de
control quand les liaisons sont perdues cause du dplacement des nuds

48

rcepteurs o ils sortent du rayon de propagation de leurs metteurs. Un bon

algorithme gnre plusieurs chemins pour viter les pertes dans des cas pareils.
4.1.4 Le trafic mis
Dtermine le volume des paquets de donnes effectives mises par un nud source
au profit dun nud destinataire. Un nud source peut ne pas avoir suffisamment de
temps pour envoyer toutes les donnes quil souhaite envoyer. Les principales raisons
sont soit le medium est trop occup par les nuds voisins, soit le nud mme est
trop charg par le routage des donnes dautres nuds sources. Un bon algorithme
essaie de tendre vers un bon quilibre et trouver la meilleure combinaison de chemins
qui optimise les flux sortants et routs.
4.1.5 Le trafic rout
Dtermine le volume des paquets de donnes effectives routes par un nud routeur.
Un nud peut tre source, routeur ou destination. Alors lidal serait, que chacune
des sources envoie directement sa destination sans dlguer sa charge des
nuds intermdiaires (routeurs). Cette situation est loin dtre la ralit, mais en
choisissant des chemins plus courts, le routage sera diminu en consquence.
4.1.6 Le temps d'attente forc du mdium
Il dtermine la dure o un nud source ou routeur attend la disponibilit du support
de transmission pour mettre ses paquets. Ces temps dattente peuvent augmenter en
fonction de laugmentation de la charge du rseau, de laugmentation du nombre de
nuds ou bien de laugmentation de la mobilit. Toutes ces situations provoquent
beaucoup de trafic quil soit de control ou de donnes. Le mdium nest utilis que par
un seul nud la fois. Donc, tous ces voisins sont lcoute pour savoir sils sont
concerns sinon ils sont en attente de libration du support de transmission.

4.2. Variables de la simulation

Pour bien reprsenter nos mtriques. Il nous fallait les schmatiser par rapport des
variables qui soient reprsentatives sur le plan quantitatif et qualitatif. Deux
algorithmes de routage ad hoc peuvent avoir les mmes valeurs au niveau des
mtriques parce quelles sont consolides. Une fois, ces valeurs clates en plusieurs
variables, le contraste des limites et des diffrences de ces protocoles sera plus

49

accentu. Ci-dessous sont prsentes nos variables de simulation.

4.2.1 Mobilit
La mobilit est la moyenne de la vitesse de tous les nuds calcule en Km/h. Quand
les nuds dun rseau se dplacent tous basse vitesse, les nuds auront le temps
de rafrachir leurs tables de routage ou de trouver les meilleurs chemins, qui resteront
valides un certain temps. Par contre, quand la vitesse des nuds est leve, les
tables de routage ne sont pas fraches. Ainsi, le rseau est dstabilis et gnre
beaucoup de contrle et de routage. Il est important dtudier le comportement des
protocoles et limpact de la mobilit sur les algorithmes de routage.
Le tableau ci-dessous liste les valeurs discrtes de la mobilit qui ont t calcules
sur l'ensemble des rsultats de simulations.
Mobilit (km/h)
0,00

0,10

0,13

0,28

0,32

0,42

TAB 3 - Valeurs discrtes de la Mobilit

4.2.2 Intensit de flux sortants

Cest le volume moyen en Ko par seconde des paquets mis par nud. Quand, dans
un rseau tous les nuds veulent mettre en mme temps, leurs fentres dmissions
ont tendance se chevaucher dans le temps. Une gestion de priorit sinstalle. Un
rseau forte intensit de flux sortants peut devenir trs instable cause des goulots
dtranglement qui apparaissent au niveau des files dattente dmissions. Une bonne
gestion des flux rend le rseau plus stable et efficace.
Le tableau ci-dessous liste les valeurs discrtes de lIntensit du flux sortant qui
ont t calcules sur l'ensemble des rsultats de simulations.
lIntensit du flux sortant (Koctet/seconde/nud)
9,68

16,93

24,60

29,04

39,45

48,40

87,12

114,26

TAB 4 - Valeurs discrtes de lIntensit du flux sortant

Afin daccentuer les carts entre les protocoles simuls. Nous avons imagin un
protocole idal qui rpond positivement toutes les exigences techniques et
fonctionnelles. Le tableau suivant prsente les variations idales des mtriques que
nous avons utiliss pour ce protocole vers la hausse
ou vers la baisse.

50

Mtriques

sens de variation

Les paquets de control

Les paquets utiles

Les paquets perdus

Le trafic mis

Le trafic rout

Le temps d'attente forc du mdium

TAB 5 - Sens de variation des mtriques dans le cas idal.

Lalgorithme idal imagin doit en effet : minimiser les paquets de control et

envoyer un maximum de paquets utiles avec un minimum de paquets perdus. Tout en
assurant un grand ratio trafic mis / trafic rout sans trop attendre pour mettre sur le
mdium.

51

Chapitre 5.
Rsultats de la simulation

52

Ce chapitre a pour but de prsenter tous les rsultats des simulations effectues
dans le cadre de cette tude. Ces rsultats sont prsents sous forme de courbes
calcules en fonction de six mtriques. Ces mtriques sont en fonction de deux
variables, la Mobilit des nuds dans le rseau et lIntensit du flux sortant que nous
avons calcul pour ces mmes fins.
5.1 Rsultats et discussions
5.1.1 Paquets de control (pqt/nud)
Pour ce scnario nous avons deux courbes. La premire illustre le nombre de
paquets de control en fonction de la mobilit (Fig. 5.1-A) et la deuxime illustre le

9
8
7
6
5
4
3
2
1
0

AODV
DSDV
DSR

0,1 0,13 0,28 0,32 0,42

Mobilit (Km/h)

Paquets de control (pqt/nud)

Paquets de control (pqt/nud)

nombre de paquets de control en fonction de lIntensit du flux sortant (Fig. 5.1-B).

10
8
6
4
2
0
9,68

24,6

39,45

87,12

Intensit du flux sortant (Koctet/sec/nud)

Nous remarquons sur la premire figure la courbe du protocole proactif DSDV

positionne au dessus des deux autres courbes. DSDV ainsi gnre plus de paquets
de control du fait quil soit proactif (maintient permanent dune tables de routage
frache).
Pour le protocole ractif ADOV, le nombre de paquets de control converge vers le
protocole proactif en augmentant la mobilit cause des interruptions frquentes des
trafics de donnes dues au changement de position des nuds.
Le ractif DSR se comporte mieux que les prcdents mme avec une forte
mobilit. Nous pouvons quasiment dire quil est insensible la mobilit.
Pour la deuxime figure, DSDV maintient la barre haute mais presque stable en
augmentant le flux sortant. AODV qui reste toujours proche de DSDV, augmente en
consommation de paquets de control avec laugmentation du flux sortant au point o il
le dpasse vers le max des flux. Ractif par sa nature, AODV vrifie bien la rgle du
besoin de paquets de control avec laugmentation des flux sortants.

53

DSR par contre requiert un faible control. Mais en augmentant le flux, il provoque
plus de control.
La corrlation des courbes dans la figure A et dans la figure B est bien visible. Les
deux protocoles DSDV et AODV ont deux courbes bien proches. Par contre, DSR
reste loin des autres avec toujours le minimum de paquets de control.
La logique thorique sollicite une augmentation du trafic de control avec
laugmentation de la mobilit ou bien laugmentation de lintensit du flux sortant. Elle
est bien exprime pour les trois protocoles. En thorie, les protocoles proactifs doivent
avoir une consommation rgulire en matire de paquets de contrles. Par contre les
ractifs utilisent de plus en plus ces paquets avec laugmentation de la demande.
Comme dans notre cas laugmentation de la mobilit ou le flux. Le proactif DSDV
semble tre assez stable. Le ractif AODV augmente naturellement son besoin en
paquets de control. Par contre, le ractif DSR semble baisser son utilisation en control
avec laugmentation de la mobilit, prsentant ainsi une contradiction avec les thories.
Lexplication que nous pouvons donner ce phnomne est que les nuds mobiles
ont arrang le routage des liaisons de donnes, comme il peut y avoir aussi le cas o
le dplacement des nuds les a regroup dans un petit rayon de propagation o le
control se rduit considrablement.

5.1.2 Paquets utiles (pqt/nud)

Pour ce scnario nous avons deux courbes. La premire illustre le nombre de
paquets utiles en fonction de la mobilit (Fig. 5.2-A) et la deuxime illustre le nombre
de paquets utiles en fonction de lIntensit du flux sortant (Fig. 5.2-B).

420

390

AODV
DSDV
DSR

360

330
0

0,1 0,13 0,28 0,32 0,42

Mobilit (Km/h)

Paquets utiles (pqt/nud)

Paquets utiles (pqt/nud)

La premire figure prsente trois courbes trs voisines. Avec laugmentation de la

1000
900
800
700
600
500
400
300
200
100
9,68 16,9 24,6

29

39,4 48,4 87,1 114

Intensit du flux sortant (Koctet/sec/nud)

mobilit, les trois protocoles arrivent donc acheminer leurs paquets avec presque le
mme taux.

54

Pour la deuxime figure, tous les protocoles ont le mme nombre de paquets utiles,
particularit pour la premire valeur de flux sortant qui enregistre un maximum de
paquet utiles pour tous les protocoles.
Au niveau des paquets utiles, nous ne pouvons pas dire que cette simulation nous
accentue les diffrences entre les protocoles.
La logique thorique prvoit une rduction des paquets utiles avec laugmentation
de la mobilit ou bien le flux sortant. Quand les nuds se dplacent beaucoup, les
liaisons sont rompues provoquant ainsi la perte des paquets. Nous aurions les mmes
rsultats pour le cas de laugmentation des flux, parce quil y aurait beaucoup de
goulots dtranglement qui provoquent la perte des paquets. Aucune diffrence entre
protocole ractif ou proactif nest souligner sur le plan thorique pour le taux des
paquets utiles achemins, parce quil sagit de la fonction objective de chacun deux.
Le but est den dlivrer le maximum. Nos trois protocoles arrivent garder un seuil
quasi stable avec la variation de la mobilit. Ce seuil devait dans la logique diminuer
avec laugmentation de la mobilit. Soit la mobilit ntait pas assez forte pour quelle
perturbe le routage ou bien, le maillage du rseau est fait dune telle faon que les
nuds mobiles ne jouent pas des rles majeurs dans le routage. Lintensit du flux a
vrifi la rgle de diminution des paquets utiles. Par contre la courbe des trois
protocoles voit une chute importante entre les deux premires valeurs. Il semble que
le premier flux (9,68 Koctet/sec/nud) soit un flux presque idal pour vhiculer un
maximum de paquets. Au del de ce flux, les protocoles gnrent plus de control,
perdent et dlivrent moins de paquets.
5.1.3 Paquets perdus (pqt/nud)
Pour ce scnario nous avons deux courbes. La premire illustre le nombre de
paquets de perdus en fonction de la mobilit (Fig. 5.3-A) et la deuxime illustre le
nombre de paquets perdus en fonction de lIntensit du flux sortant (Fig. 5.3-B).

55

Paquets perdus (pqt/nud)

15
AODV
10

DSDV
DSR

5
0
0

20
15
10
5
0
9,68

0,1 0,13 0,28 0,32 0,42

24,6

39,45

87,12

Intensit du flux sortant (Koctet/sec/nud)

Mobilit (Km/h)

La diffrence est bien visible sur les deux courbes entre les trois protocoles. Sur la
premire figure AODV se retrouve le numro 1 des paquets perdus. DSDV assure
moyennement la prservation des paquets. DSR a une perte presque ngligeable.
Ces deux derniers ont un comportement presque identique malgr laugmentation de
la mobilit. Par contre, AODV perd de plus en plus de paquets avec une forte mobilit
cause des chemins qui ne restent plus valides.
Nous pouvons presque appliquer la mme analyse la deuxime figure, o avec
laugmentation des flux sortants, AODV perd plus de paquets. Sa moyenne de perte
est nettement suprieure celle des deux autres protocoles qui ont une courbe quasi
identique une constante prs.
La logique thorique sattend une perte croissante avec la mobilit ainsi quavec
des flux sortants importants. DSDV et DSR semblent garder une moyenne fixe des
paquets perdus, qui doit tre au dtriment du control qui assure une bonne liaison
avant denvoyer les paquets. AODV valide la thorie.
5.1.4 Trafic mis (Koctet/nud)
Pour ce scnario nous avons deux courbes. La premire illustre le trafic mis en
fonction de la mobilit (Fig. 5.4-A) et la deuxime illustre le trafic mis en fonction de
lIntensit du flux sortant (Fig. 5.4-B).

Trafic mis (Koctet/nud)

850
AODV

800

DSDV

750

DSR

700
650
600

Trafic mis (Koctet/nud)

900

rs
Mi ll e

Paquets perdus (pqt/nud)

20

900
850
800
750
700
650
600

0,1 0,13 0,28 0,32 0,42

Mobilit (Km/h)

9,68 16,9 24,6 29

39,4 48,4 87,1 114

Intensit du flux sortant (Koctet/sec/nud)

56

La premire figure nous montre les deux protocoles AODV et DSDV qui ont
presque la mme tendance de courbe mais DSDV met plus que AODV du fait quil
trouve rapidement les chemins et le medium est plus libre. Par contre pour les ractifs
AODV et DSR, il leur faut plus de temps pour trouver un chemin. La mobilit ne
semble pas beaucoup influencer le trafic mis pour tous les protocoles simuls.
La deuxime figure prsente trois courbes assez voisines en hausse avec
laugmentation de lintensit du flux sortant. DSR met moins que les deux autres
protocoles toujours pour la mme prcdente raison lie au temps de dcouverte de
chemins.
Nous remarquons bien que la mobilit et lintensit du flux sortant nimpactent pas
les protocoles de la mme faon. DSDV se retrouve mieux que AODV pour une
grande mobilit et inversement quand il sagit dintensit de flux sortant.
En thorie, la hausse de la mobilit ralentit le trafic de donnes et rduit le volume
de paquets mis. Par contre, une grande intensit de flux sortant, bien quelle
engendre des saturations au niveau des files dattente, implique une grande taille des
paquets qui tend les volumes des donnes mises. Cette thorie est bien exprime
dans la deuxime courbe. Contenant la mobilit, une aberration pour le protocole
ractif DSR figure dans la premire courbe, o la mobilit 0,32 Km/h reprsente le
maximum de trafic mis alors que toutes les mobilits moins importantes donnent des
volumes de donnes mises beaucoup plus faibles. Lexplication possible pour ce cas
de figure est qu cette valeur de mobilit, les nuds dynamiques nont pas jou un
rle avantageux dans le routage ni dans les missions/rceptions. Ceci pourrait tre
justifi par une mobilit situe aux extrmits du rseau, l o le trafic de donnes ne
prsente pas une densit notable.

57

5.1.5 Trafic rout (Koctet/nud)

Pour ce scnario nous avons deux courbes. La premire illustre le trafic rout en
fonction de la mobilit (Fig. 5.5-A) et la deuxime illustre le trafic rout en fonction de
lIntensit du flux sortant (Fig. 5.5-B).

200

150
AODV
100

DSDV
DSR

50
0
0

0,1 0,13 0,28 0,32 0,42

Mobilit (Km/h)

Trafic rout (Koctet/nud)

Trafic rout (Koctet/nud)

200

150
100

50
0

9,68 16,9 24,6 29

39,4 48,4 87,1 114

Intensit du flux sortant (Koctet/sec/nud)

Sur la premire figure, AODV utilise plus de routage que les deux autres puisquil
est ractif. Donc ses chemins ne sont pas optimaux. Le proactif DSDV se situe entre
les deux ractifs, gardant ainsi une bonne moyenne. DSR utilise le minimum de
routage grce son algorithme qui lui procure des chemins courts la source.
Au niveau de la deuxime figure, les courbes trs voisines gardent quasiment les
mmes positions. Les deux figures attribuent une ide commune aux protocoles.
La thorie des algorithmes ad hoc veut que le routage augmente avec la mobilit
ainsi quavec de larges flux sortants, du fait que la mobilit favorise la disparition des
chemins valides. Quand les flux sortants montent, les nuds routeurs se saturent et
les chemins se dilatent. Lalgorithme qui calcule le plus court chemin doit bien se
comporter dans des scnarios pareils. Les trois protocoles semblent avoir les mmes
performances pour ce calcul. Jusqu la mobilit 0,13 Km/h ils semblent bien grer le
routage minimum. Juste aprs ce seuil, le routage commence prendre plus
dampleur.

Ce mme scnario est visible aussi pour les trois protocoles sur la

deuxime courbe. Jusqu 29 Koctet/sec/nud, le routage se dcline. Aprs cette

valeur, le trafic rout prend du volume cause de la mauvaise gestion des chemins
courts ou bien de la saturation des nuds routeurs qui narrivent pas subvenir aux
besoins des nuds qui les sollicitent.

58

5.1.6 Temps d'attente forc du mdium (Milliseconde/nud)

Pour ce scnario nous avons deux courbes. La premire illustre le temps d'attente
forc du mdium en fonction de la mobilit (Fig. 5.6-A) et la deuxime illustre le temps

500

400
AODV
300

DSDV
DSR

200
0

0,13

0,32

Mobilit (Km/h)

Temps d'attente force du mdium

(Milliseconde/nud)

Temps d'attente force du

mdium (Milliseconde/nud)

d'attente forc du mdium en fonction de lintensit du flux sortant (Fig. 5.6-B).

900

600

300

0
9,68 16,9 24,6 29

39,4 48,4 87,1 114

Intensit du flux sortant (Koctet/sec/nud)

Dans la premire figure, les trois protocoles augmentent leur temps dattente du
mdium avec laugmentation de la mobilit aprs la mobilit 0,13 Km/h. DSR semble
le plus sensible ce phnomne, o il se retrouve au maximum du temps dattente
pour une forte mobilit.
Pour la deuxime figure, tous les protocoles se comportent de la mme faon avec
des courbes quasi identiques, o leurs temps dattente du mdium augmentent avec
laugmentation de lintensit des flux de donnes. La simulation confirme la contrainte
physique du support de transmission qui doit tre utilis que par un seul metteur la
fois.
Sur un plan thorique, la mobilit amplifie le temps dattente du mdium.
Lintensit du flux sortant aussi agit de la mme faon sur le temps dattente dun
nud pour mettre des paquets de donnes via les ondes radios. La deuxime
courbe confirme bien cette rgle pour les trois protocoles avec une toute petite baisse
entre 9,68 et 16,9 Ko/sec/nud. Dans cet intervalle, les protocoles parviennent
rduire les temps dattente puisque les flux sont bien grs et optimiss sur le plan
longueur des chemins. Au del de cette valeur optimale, les temps dattente
augmentent avec lintensit des flux sortant du fait que le mdium est
considrablement employ. Mme scnario pour la premire courbe de mobilit mais
dune faon plus flagrante. La baisse des temps dattente vont jusquau 0,13 Km/h
pour remonter aussitt aprs, sauf pour le ractif AODV qui garde cette valeur jusqu
0,28 Km/h. Cette mobilit exprime le minimum du temps dattente pour la libration du
mdium. Le rapport entre les flux sortants, la longueur des chemins et leur degr de
fiabilit doit tre trs intressant et optimal.

59

5.2 Conclusion et perspectives

Conclusion
La majorit des protocoles de routage ad hoc ont des proprits communes et
dautres spcifiques pour chacun. Une configuration de ces proprits peut dfinir si le
protocole est performant ou non. Une tude consacre aux proprits spcifiques
nous rvle les vrais carts entre ces protocoles. Ces derniers peuvent diverger en
fonction des scnarios appliqus.
Dans notre tude nous avons pu dceler quelques carts entre les trois protocoles
simuls AODV, DSDV et DSR ainsi que dautres entre les types de protocoles
proactifs et ractifs. Ces carts sont loin dtre exhaustifs par rapport la ralit des
ces protocoles divers et varis.
Le protocole ractif AODV se comporte globalement dune manire assez
satisfaisante par rapport aux deux autres. Il craint les fortes mobilits ainsi que les flux
de donnes importants o il enregistre une perte de paquets considrable. En le
comparant DSR qui est de la mme catgorie nous avons constat quils ont
presque les mmes tendances sur un ordre gnral. Le proactif DSDV se distingue
par rapport aux autres par sa particularit de garder jour une table de routage. Nous
avons not quil commence mettre rellement trs vite aprs la demande. Ces
routes sont toujours disposition mme dans les fortes mobilits. Par rapport aux
taux dacheminement des paquets il assure un trs bon seuil. La quasi-totalit des
paquets arrive destination.
Le meilleur comportement que nous avons enregistr est celui de DSR. Cet
algorithme proactif requiert un minimum de paquets de control pour acheminer un
maximum de donnes avec une perte presque ngligeable. La diversit des scnarios
appliqus cet algorithme, ne semble pas beaucoup limpacter. Il arrive garder
presque toutes ses valeurs pour une grande mobilit ou dans un rseau dense. Son
attente de la libration du mdium augmente avec la mobilit du fait que les routes
disparaissent rapidement. Chacun des nuds metteurs initie une demande de
nouvelle route.
Sur un ordre gnral, DSR emporte la premire place par rapport tous les
rsultats que nous avons pu enregistrer durant nos simulations, mme si les deux
autres le dpassent dans quelques proprits prcises.

60

Perspectives
Durant les deux phases de notre tude thorique et pratique, nous nous sommes
vite rendus compte que le domaine de recherche dans les rseaux sans fils est tout
jeune et quil a un long chemin parcourir. Plusieurs groupes scientifiques
sintressent ce type de rseaux qui promet beaucoup pour lavenir.

Plus

spcialement, les protocoles de routage attirent de plus en plus les simulateurs afin de
combiner les meilleurs atouts de chacun deux en un seul. Aprs notre tude thorique
nous avons slectionn des proprits afin de les simuler et trouver les carts entre
les algorithmes de routage.
Ce travail de prparation des simulations ncessite beaucoup de recherche et de
dveloppements. Notre modeste contribution a besoin dtre largie avec des
simulations sur dautres paramtres. De nouvelles mtriques de comparaisons sont
envisager pour mieux accentuer les diffrences. Les tudes de simulations sur un seul
protocole auquel on apporte des changements sur son algorithme de routage
pourraient nous rvler de nouvelles particularits. Ainsi, nous allons permettre aux
algorithmes de progresser et les rseaux sans fils de voir de nouveaux terrains
dapplications. La tlphonie sur IP, la visiophonie et les applications multimdias sont
tous lattente de tels types de rseaux sans fils mais avec des bandes passantes
beaucoup plus larges et des temps de rponses trs courts.

La majorit des

applications actuelles exigent le maintien dune qualit de service minimale.

61

Bibliographie
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]

[26]
[27]
[28]
[29]

S.Corson, University of Maryland, J. Macker, Naval Research Laboratory."Mobile Ad hoc

Networking (MANET)". RFC 2501, January 1999.
G.Malkin, Xylogics, Inc., F.Baker, Cisco Systems."RIP Version 2 MIB Extension". RFC
1724, November 1994.
Kevin Fall,Kannan Varadhan. "The ns Manual". UC Berkeley, LBL, USC/ISI, and Xerox
PARC, avril 2001
J. Moy,Cascade Communications Corp. "OSPF Version 2. RFC 2178", July 1997.
Elizabeth M. Royer, Chai-Keong Toh. "A Review of Current Routing Protocols for Ad Hoc
Mobile Wireless Networks". IEEE Personal Communications, April 1999.
T.Larsson, N.Hedman. "Routing protocols in wireless ad hoc networks: a simulation
study". Dcembre 1998
Daniel L. Lough, T. Keith Blankenship, Kevin J. Krizman."A Short Tutorial on Wireless
LANs and IEEE 802.11".Summer 1997.
http://www.ietf.org/
http://www.ee.surrey.ac.uk/Personal/G.Aggelou/MANET_PUBLICATIONS.htm
Ajay Chandra V. Gummalla, John O. Limb. "Wireless Medium Access Control Protocols".
IEEE Communications Surveys, Second Quarter 2000.
Charles E. Perkins, Elizabeth M. Royer, Samir R. Das. s"Ad hoc On-Demand Distance
Vector (AODV) Routing". Internet Draft, 2 March 2001.
David B. Johnson, David A. Maltz, Yih-Chun Hu, Jorjeta G. Jetcheva. "The Dynamic
Source Routing Protocol for Mobile Ad Hoc Networks". Internet Draft, 2 March 2001.
V. Park, S. Corson. "Temporally-Ordered Routing Algorithm (TORA) Version 1". Internet
Draft, 20 July 2001.
Charles Perkins, Pravin Bhagwat. "Highly Dynamic Destination-Sequenced DistanceVector Routing (DSDV) for Mobile Computers ". 1994
M. S. Corson, S. Papademetriou, P. Papadopoulos, V. Park, A. Qayyum."An Internet
MANET Encapsulation Protocol (IMEP) Specification". Internet Draft, 7 August 1999.
Philippe Jacquet, Paul Muhlethaler, Amir Qayyum, Anis Laouiti, Laurent Viennot, Thomas
Clausen."Optimized Link State Routing Protocol". Internet Draft, 2 March 2001.
C.-C. Chiang."Routing in Clustered Multihop, Mobile Wireless Networks with Fading
Channel". Proceedings of IEEE SICON'97, Apr.1997.
Zygmunt J. Haas, Marc R. Pearlman. "The Zone Routing Protocol (ZRP) for Ad Hoc
Networks". Internet Draft, November 1997.
Anis KOUBAA. "Gestion de la Qualit de Service temporelle selon la contrainte (m,k)-firm
dans les rseaux commutation de paquets". 2004.
Simulateur de rseaux - http://www.reseaucerta.org/outils/simulateur/
GlomoSim - http://pcl.cs.ucla.edu/projects/glomosim/
NS: The Network Simulator - http://www.isi.edu/nsnam/ns/
OPNET: Open NETwork - http://www.opnet.com/
Une approche efficace de dtection des intrusions pour le protocole OLSR des MANET http://www.crc.ca/fr/html/manetsensor/home/publications/abstracts
Ying Ge, Louise Lamont, Luis Villasenor. "A Scalable Proactive Routing Protocol for
Heterogeneous Ad Hoc Networks". WiMob 2005 Wireless and Mobile Computing,
Montral, Canada, aot 2005.
Claude Chaudet. "Simulateurs".
http://www.infres.enst.fr/~chaudet/index.php/CaptAdhoc/Simulateurs
VINT : Virtual InterNetwork Testbed - http://www.isi.edu/nsnam/vint/
Fred L. Drake. Python Tutorial. Release 2.1.1, July 20, 2001
Deborah Estrin, Mark Handley, John Heidemann, Steven McCanne, Ya Xu, Haobo
Yu. Network Visualization with the VINT Network Animator Nam. Tech. Rp. 1999.

62

Annexe A
Description de la simulation

Le processus de simulation est compos de trois phases essentielles :

Phase de prparation : s'occupe de la gnration des fichiers d'entres

Phase de simulation : lance les simulations et gnre les traces

Phase d'analyse : Analyse les traces et gnre des courbes

La figure A.1 prsente le processus gnral d'une simulation sous ns.

Dans la premire phase de prparation, les fichiers d'entres de la simulation sont
gnrs par un programme que nous avons implment en C. Ces fichiers sont
classs en deux catgories :
1. Fichiers de scnario qui dcrivent les nuds, leurs positions ainsi que
leurs mouvements
2. Fichiers de communication qui dcrivent le trafic dans le rseau
Une fois la simulation lance en deuxime phase, elle prend comme entre les
deux fichiers scripts (Otcl) et gnre en sortie un fichier journal appel aussi la trace
qui dcrit les oprations et les transactions effectues travers le temps au sein du
rseau.
A ce moment, la phase d'analyse peut dbuter en prenant la trace comme entre
pour le programme d'analyse que nous avons implment en langage Python [28].

63

FIG A.1 - Processus gnral de simulation.

64

Annexe B
The Network Animator
La conception de protocole demande une comprhension de plusieurs dtails,
dont le suivi des tats d'un grand nombre de nuds, une analyse de l'change de
messages et doit caractriser les interactions dynamiques pour des trafics concurrents.
Habituellement, des traces de paquets sont utilises pour accomplir ces tches.
Cependant, ces traces ont deux inconvnients majeurs. Elles prsentent un nombre
important de dtails, ce qui peut compliquer la comprhension des donnes, et elles
sont statiques, ce qui cache une dimension importante du comportement des
protocoles. Les outils de visualisation adressent ce problme en permettant
l'utilisateur de prendre en considration plusieurs informations trs rapidement,
d'identifier visuellement les modles de communication et de mieux comprendre les
interactions et les causalits. NAM [29] est un outil d'animation bas sur Tcl/TK45 pour
l'observation des traces de paquet. Il peut tre install sur un systme de type unix ou
sur Windows 95/98/NT ayant Microsoft Visual C++ install. Les donnes utilises par
NAM peuvent provenir d'un simulateur ou de tests sur des rseaux rels. Il supporte
l'affichage de la topologie, l'animation des changes de paquets et des outils
d'inspection de donnes divers. NAM a t cre par le laboratoire LBL et s'est
considrablement dvelopp durant les dernires annes.
NAM interprte un fichier de trace contenant des vnements rseau indexs par
le temps de diffrentes manires. Ces vnements sont principalement les arrives,
dparts et suppressions de paquets et ruptures de lien. Pour les simulations de rseau
sans fil, la localisation et les mouvements des nuds sajoutent aux vnements
interprts.
NAM est excut avec comme paramtre le fichier enregistr. Lorsqu'on excute
NAM, une fentre de travail NAM est cre. Il est possible de faire tourner plusieurs
animations avec une seule instance, ce qui permet de mieux comparer certain
protocole.
La figure B.1 reprsente une fentre d'animation NAM. On peut entre autre rgler
le pas de la simulation (de 8s 800ms), zoomer sur des zones de la simulation, et
manipuler la lecture : on peut mettre pause tout moment ce qui donne un arrt sur
Image , revenir, avancer sur les tapes de la simulation ce qui permet d'examiner
des occurrences particulires. Cette animation comporte 20 nuds avec un trafic TCP
entre les nuds 13 et 17.
45

TCL/TK : Tool Command Language, TK: Toolkit (La bibliothque graphique de TCL).

65

FIG B.1 - Une capture d'cran du Network Animator.

66