2009 TIZI OUZOU Routage Avec QoS Dans AODV PDF

Ministre de L'Enseignement Suprieur et de la Recherche Scientifique
Universit Mouloud MAMMERI de TIZI-OUZOU

Facult du Gnie Electrique et d'Informatique
Dpartement d'Informatique
Prsent pour obtenir le titre dingnieur dtat

Spcialit : INFORMATIQUE
Option : INFORMATIQUE INDUSTRIELLE
Thme
Routage avec Qualit de

Service dans AODV
Prsent par
Houari MAOUCHI
Encadreurs :
Mme Nadia NOUALI Maitre de recherche CERIST
Mr Nadir BOUCHAMA Attach de recherche CERIST
Anne 2008 -2009

In the Name of Allah, the Benificent, the Merciful
My prayer and my sacrifice and my life and my death

are surely for Allah,
Allah, the Lord of the worlds
Le Saint Coran
ii
DDICACES
A ma chre mre pour ses sacrifices depuis quelle

ma mis au monde,
A la mmoire de mon pre,
A ma tante Zhira, ma deuxime mre,
A mes frres et mes surs,
A mon cousin et mon ami Zoubir et son frre Merzak,
A toute ma grande famille,
A tous mes amis dont la liste est longue,
Enfin tous ceux que jaime et ceux qui maiment,
Jexprime mes sentiments les plus profonds
Et leur ddie ce modeste travail.
iii
REMERCIEMENTS
En premier lieu, je remercie le Bon Dieu de mavoir

donn la force et le courage pour accomplir ce travail et
qui ma procur ce succs.
Mes trs vifs remerciements vont lencontre de mes

encadreurs M eme Nadia NOUALI et Mr. Nadir BOUCHAMA, pour
avoir accept de mencadrer et de morienter tout au long de ce
travail, je les remercie une deuxime fois pour leur patience,
leur sympathie et leurs conseils.
Je remercie vivement tous les enseignants de
dpartement dInformatique de luniversit Mouloud
Mammeri de TIZI-OUZOU pour tous les efforts quils ont
fournis toute au long de cette formation.
Je remercie galement les membres du jury qui ont

accept de juger ce travail.
Que toute personne qui, d'une manire ou d'une autre,

ma aid et encourag l'aboutissement de ce travail,
trouve ici l'expression de mes sincres reconnaissances.
iv
Table des matires
Table des Matires .... v
Table des Figures . . ..viii
Liste des tableaux . x
Introduction Gnrale ..01
Chapitre I : Gnralits sur les rseaux sans fil

1 introduction...04
2 Les rseaux sans fil ...04
2.1 Historique ...04
2.2 Dfinition.05
2.3 Caractristiques ...05
2.4 Classification des rseaux sans fil .... 05
2.4.1 Selon la zone de couverture. 05
2.4.2 Selon le mode de fonctionnement ....06
2.4.3 Selon la topologie du rseau. 08
3 Prsentation de la norme 802.11... 09
3.1 Le modele de rfrence OSI . 09
3.2 Les rseaux sans fil et le modle OSI .........11
3.3 Le standard 802.11... 11
3.3.1 Couche physique ...11
3.3.2 la couche liaison de donnes .. 12
3.3.2.1 la sous-couche LLC (Logical Link Control) ...12
3.3.2.2 la sous-couche MAC (Medium Access Control) .. .. 12
3.4 Les diffrentes drives de la norme 802.11 ......16
4 Les rseaux mobiles ad hoc 17
4.1Dfinition..17
4.2 Modlisation 17
4.3Domaines dapplication des rseaux ad hoc... 18
4.4 Les caractristiques des rseaux ad hoc .18
Conclusion 19
Chapitre II : Routage dans les rseaux mobiles ad hoc

1 Introduction ..21
2 Dfinitions..21
3 Problmatique du routage dans les rseaux mobile ad hoc .22
4 Taxonomie des protocoles de routage dans les MANETs ...22
4.1 Selon larchitecture 23
4.1.4 Les protocoles de routage plat (ou uniformes) .....23
4.1.2 Les protocoles de routage hirarchiques (ou non uniformes).24
4.2 Selon lalgorithme utilis ...... . 25
4.3 Les catgories de protocoles de routage MANET..... 25
4.3.1 les protocoles proactifs...25
4.3.2 Les protocoles ractifs... 26
4.3.3 Les protocoles hybrides .....26
v
5 Description de quelques protocoles MANETs .. 26
5.1 OLSR..27
5.2 TBRTF ...27
5.3 DSR27
6 Etude dtaille du protocole AODV ..28
6.1 Table de routage et paquets de contrle ...28
6.2 Numro de squence ..30
6.3 Principe de fonctionnement .....31
6.3.1 Dcouverte d'une route.. 31
6.3.2 Maintenance des routes.......32
6.3.3 Gestion de la connectivit locale......33
6.4 AODV : Avantages et inconvnients .... 33
7 Autres protocoles....34
Conclusion..34
Chapitre III : Qualit de service dans les rseaux mobiles ad hoc

1 Introduction.. 36
2 Dfinition de la Qualit de service.36
3 Les mtriques de la qualit de service .. 36
3.1 La bande passante37
3.2 Dlai de bout en bout.. 37
3.3 La gigue : (variation du dlai) ...37
3.4 La perte de paquets...37
4 Les besoins dapplications de la QoS...38
5 Exemple de besoins de QoS : la voix sur IP (VoIP)38
5.1 Les paramtres de la voix sur IP...38
5.1.1 Les diffrents chantillonnages39
5.1.2 Le dlai de bout en bout...39
5.1.3 La gigue39
5.1.4 La perte de paquets...40
6 La QoS dans Les rseaux mobiles ad hoc ...40
7 Solutions de QoS dans les MANETs . 41
7.1 Modles de qualit de service ...41
7.2 Solutions au niveau de la couche MAC ...42
7.2.1 Diffrenciation de services pour 802.11 .. 42
7.2.2 MACA/PR (Multihop Access Collision Avoidance with Piggyback Reservation)42
7.2.3 IEEE 802.11e.. 42
7.3Protocoles de signalisation43
7.4 Routage avec QoS... 43
7.4.1 Objectifs du routage avec QoS.44
7.4.2 Difficult de routage avec QoS dans les MANETs . 44
7.5 Protocole de routage avec QoS .44
Conclusion...45
Chapitre IV : Conception
1 Introduction ...47
2 le routage AODV avec QoS...47
2.1 Estimation du dlai dans les MANETs.....48
2.2 Estimation du dlai 1 saut radio 48
2.2.1 Dtermination du dlai dans la file dattente.48
vi
2.2.2 Dtermination du dlai de propagation.50
2.3 Dtermination du dlai multi sauts.52
3 Intgration dans AODV.52
3.1 Extension de la RREQ ....52
3.2 Extension des messages HELLO..53
3.3 Mcanisme de routage AODV avec QoS.53
3.3.1Dcouverte des routes53
3.3.2 Maintenance des routes..54
3.4 Limitations .55
4 Diagramme de squence.57
5 Diagramme de classes.57
Conclusion 59
Chapitre V : Implmentation
1 Introduction ...61
2 Prsentation dAODV sous NS-2... 61
3 Prsentation du protocole mac-802_11 sous NS-2 .62
4 Structure des nuds AODV et AODV-D sous NS-2 ..62
5 Implmentation dAODV-D sous NS-2...63
5.1 Estimation du dlai au niveau de la couche MAC 64
5.1.1 Estimation de la bande passante libre sur un nud... 64
5.1.2 Rcupration du paramtre ...66
5.1.3 Le dlai dans la file dattente R 67
5.1.4 Estimation du dlai de propagation ;;;;67
5.1.5 Le dlai un saut ;;.69
6 Les modifications au niveau de la couche rseau.69
6.1Le format du paquet RREQ dans AODV-D 69
6.2Le format du paquet RREP dans AODV-D...70
6.3 Contrle dadmission 70
6.4 La probabilit de collision ....72
7 Les exigences de QoS.73
Conclusion.74
Chapitre VI : Simulation et discussion des rsultats

1 Introduction...76
2 Intrt et ncessit de la simulation.76
3 Modle de simulation...76
3.1 Modle de trafic77
4 Mtriques de simulation mesures....78
5 Scnario de simulation.78
6 Simulation et discussion ..79
6.1 Dlai de bout en bout...79
6.2 La variation de dlai (la gigue) .80
6.3 La perte de paquets..81
Conclusion..82
Conclusion gnrale et perspectives83
Bibliographie ......... 85
Annexes..91
vii
Table des figures
1. 1 :Topologie totalement connecte
1 .2 : Topologie station de base.
1.3: Topologie routage interne.
1.4 Topologie hybride.
1.5: Classification des rseaux sans fil.
1.6 : Exemple de mode infrastructure.
1.7 : Exemple de mode ad Hoc.
1.8 : Le modle de rfrence OSI.
1.9 : 802.11 et le modle OSI.
1.10 : La couche PHYSIQUE dans le rseau sans fil.
1.11 : talement de Spectre Squence Directe DSSS.
1.12: Comparaison des technologies daccs au canal radio.
1.13. Le problme du nud cach et des nuds exposs.
1.14 Le mcanisme RTS/CTS.
1.15: La modlisation d'un rseau ad hoc.
2.1 : Modes de communication dans les rseaux.

2.2 : Taxonomie des protocoles de routage ad hoc.
2.3 : Routage plat.
2.4 : Routage hirarchique.
2.5 : La propagation du paquet RREQ.
2.6 : Le chemin pris par RREP.
3.1 : Exemple de besoins de QoS.

3.2 : Solutions de QoS pour les rseaux ad hoc.
3.3 : Exemples de routage avec QoS.
4.1 : Modlisation dun nud 802.11 par une file M/M/1/K.

4.2 : Exemple de la bande passante libre sur deux nuds dun MANET.
4.3 : Dcouverte de routes dans AODV-D
4.4 : Chemin de RREP.
4.5 : L'organigramme d'excution de AODV-D.
4.6 : Lorganigramme dexcution de RREQ pour AODV-D.
viii
4.7 : Diagramme de squence dAODV-D
4.8 : Diagramme de classes dAODV-D
5.1 : Structure des nuds AODV et AODV-D sous NS-2.

5.2 : Les mthodes appeles par AODV-D (dcouverte de route).
6.1 : Pile protocolaire mis en place

6.2 : Scenario de simulation utilis.
6.3 :Dlai de bout en bout du flux CBR1 avec AODV-D et AODV.
6.4 : Evolution de la gigue pour AODV.
6.5 : Evolution de la gigue pour AODV-D.
A.1 : Une simple utilisation de NS2.

A2 : Arborescence de drivation des classes C++ du simulateur.
A3 : Arborescence des fichiers de la distribution NS.
A5 : exemple de fichier trace.
A.5 : Fentre de visualisation de NAM.
A.6 : Structure dun nud mobile sous NS-2.
ix
Liste des tableaux
1.1 Famille de IEEE 802 sans fil.
1.2 La famille dIEEE 801.11.
2.1 Les principaux protocoles MANET.

2.2 Format du message RREQ.
2.3 Format du message RREP.
2.4 Format du message RERR.
3.1 : Les principaux codecs et leurs Vitesses dchantillonnage.

3.2 : Les seuils du dlai pour un codec G711.
3.3 :Les exigences de QoS pour la VoIP.
3.4 :Exemples de protocoles de routage avec QoS.
4.1 : Format du message RREQ dans AODV-D.

4.2 : Format du message HELLO dans AODV-D.
6.1. Paramtres de simulation utiliss.

6.2 : Paramtres de droulement de la simulation.
6.3 : Taux de perte de paquets pour AODV-D et AODV standard.
A1 : Les principaux composants de NS-2.

A2 : Ltructure dune ligne du fichier trace.
x
Introduction gnrale
On assiste ces dernires annes une importante volution dans le domaine des
tlcommunications, conduite par la commercialisation et lmergence des appareils de
communications sans fil (tels que les tlphones cellulaires, les ordinateurs portables, les
assistants personnels, . . . etc.) et la convergence des rseaux fixes et mobiles. Lutilisateur
passe ainsi de lge de lordinateur personnel lge du traitement de linformation travers
plusieurs infrastructures. Il a accs linformation nimporte o et nimporte quand.
En 1999, l'IEEE (Institute of Electrical and Electronics Engineers) a standardis le protocole
d'accs au mdium radio 802.11 visant assurer la communication entre ordinateurs
personnels utilisant le mdium radio. Aujourd'hui, le protocole IEEE 802.11 est largement
utilis dans les rseaux locaux sans fil.
On peut distinguer deux modes de communication dans un rseau sans fil. Dans le
premier cas, toute transmission de donnes doit passer par un point fixe (nomm point
daccs) et ce mme si deux mobiles communicants sont proches. Cette entit particulire
joue le rle de routeur lintrieur du rseau local sans fil et souvent de passerelle vers un
rseau filaire. Chaque point daccs administre alors une zone gographique et assure
ventuellement la liaison avec dautres zones, avec un rseau local filaire ou avec lInternet.
Les rseaux cellulaires (GSM, GPRS, UMTS) peuvent tre considrs comme tant une forme
particulire de rseau avec point daccs.
Dans le second mode de communication, chaque mobile du rseau a la possibilit de
communiquer directement avec tous ses voisins, cest--dire tous les nuds capables de
recevoir le signal envoy et de le comprendre. Chaque mobile peut se connecter, se dplacer
ou se dconnecter du rseau tout moment. Il ny a aucune infrastructure fixe priori et les
mobiles nont aucune connaissance de leur environnement. Si chaque mobile dun tel rseau a
la possibilit de router des paquets, il est alors possible de communiquer au del de sa
distance dmission. On parle alors de rseaux mobiles ad hoc ou MANET (pour Mobile Ad
hoc Network).
Les avantages quoffre un rseau ad hoc le rendent plus adquat pour le dploiement des
applications utilises dans les situations critiques telles que la communication dans un champ
de bataille, dans les oprations de secours et la gestion des catastrophes en gnral.
Cependant, un tel rseau est subit un nombre de contraintes qui rendent un tel
dploiement trs complexe On peut citer essentiellement : les contraintes de mdium radio, le
caractre fortement dynamique, et labsence dune administration centralise.
En effet, Chaque nud du rseau doit participer dans le routage des paquets travers le
rseau, jouant ainsi le rle d'un routeur et dun terminal en mme temps. Pour cela un
protocole de routage distribu est ncessaire.
Plusieurs protocoles de routage ont t proposs pour les rseaux mobiles ad hoc, ces
protocoles de routage peuvent tre classifis suivant la manire de cration et de maintenance
de routes lors de l'acheminement selon plusieurs critres. Le groupe de travail MANET
(Mobile ad hoc NETwork) de l'IETF (Internet Engineering Task Force) se proccupe de la
normalisation des protocoles ad hoc fonctionnant sous IP. Dans ce cadre, AODV, OLSR, DSR
sont actuellement lobjet dune RFC grce leurs caractristiques intressantes, ces protocoles
fonctionnent en mode best effort. Cependant, ils ne permettent pas de garantir une qualit de
service (QoS).
-1-
xi
Pour certaines applications telles que les applications multimdia ou temps rel le
service best effort nest pas du tout suffisant. De telles applications exigent des garanties en
terme de certains critres de qualit de service (un minimum de bande passante, un dlai max
ne pas dpasser.etc...). En effet, il semble important dadapter les MANETs pour supporter
un certain niveau de QoS dans le but de dploiement des applications exigeantes.
Ce travail s'inscrit dans le cadre du projet adopt par le CERIST (Centre de Recherche sur
lInformation Scientifique et Technique) intitul Le pervasive computing pour laide la
gestion de situations durgence et de catastrophes .
La finalit du travail effectu dans ce mmoire est de faire une extension du protocole AODV
en le rendant sensible une mtrique de QoS, savoir le dlai de bout en bout.
Ce mmoire est organis en six chapitres :
Le premier chapitre donne un tat de lart des rseaux sans fil et des diffrents concepts
lis ce type de rseaux, ainsi quune description de la norme IEEE 802.11. Enfin, il prcise
les notions de base des rseaux mobiles ad hoc et les principales caractristiques des MANETs
ainsi que les contraintes qui en dcoulent.
Le deuxime chapitre traite les principes du routage dans les rseaux mobiles ad hoc. Il
sintresse plus prcisment la problmatique du routage et les contraintes lies aux
MANETs. Il dcrit galement les principaux protocoles proposs et leurs classifications.
Enfin il prsente une tude dtaille du protocole AODV.
Le troisime chapitre introduit le concept de qualit de service ainsi quun tat de lart
sur les solutions existantes, plus particulirement le routage avec QoS dans les MANETs.
Le quatrime chapitre est consacr la conception du protocole AODV-D qui est une
extension dAODV en termes du dlai, il dcrit galement la mthode d'estimation du dlai
utilise.
Le cinquime chapitre donne des dtails de limplmentation de ce qui a t conu dans
le chapitre quatre.
Le sixime chapitre est consacr aux simulations et discussions des rsultats.
Nous terminerons par une conclusion gnrale et quelques perspectives pour des travaux
futurs.
-2-
xii
Chapitre I
Gnralits sur les rseaux sans fil

Chapitre I Gnralits sur les rseaux sans fil
Gnralits sur les rseaux sans fil
1 Introduction
Les communications sans fil ont un rle crucial jouer au sein des rseaux informatiques.
Elles offrent des solutions ouvertes pour fournir de la mobilit ainsi que des services
essentiels l o linstallation dune infrastructure nest pas possible. Les rseaux sans fil
(Wireless Networks) constituent de plus en plus une technologie mergente permettant ses
utilisateurs un accs linformation et aux services lectroniques indpendamment de leurs
positions gographiques. Le succs de ce type de rseaux ces dernires annes est suscit par
un grand intrt de la part des particuliers, des entreprises et du milieu industriel. En effet, ce
type de rseaux est peru comme une nouvelle alternative complmentaire aux rseaux filaires
traditionnels [1].
Dans ce chapitre, nous allons parler de la technologie de communication sans fil utilise
dans les rseaux mobiles, pour cela nous dtaillons quelques principales notions ncessaires
la comprhension de ces systmes, ainsi quune prsentation globale de la norme 802.11.
Ensuite, nous allons voir les classifications principales des rseaux sans fil et les diffrentes
technologies utilises dans chaque catgorie, enfin le chapitre introduit le concept des rseaux
mobiles ad hoc, la dfinition, les caractristiques, et les domaines dapplication.
2 Les rseaux sans fil

2.1 Historique
Aux environs de 1940, la premire re de l'informatique moderne fit son apparition.
Rapidement, l'adaptation des technologies de tlcommunications l'informatique fut
incontournable. En 1957, le ministre de la dfense amricain cre l'agence pour les projets
de recherche avance : ARPA (Advanced Research Projects Agency). A la fin des annes 60 les
chercheurs de l'ARPA ont cr L'ARPANET, rseau destin relier entre elles les diffrentes
universits du pays, qui grce la standardisation du modle TCP/IP (Transmission Control
Protocol/Internet) Protocol, voluera vers l'Internet que nous connaissons actuellement.
Jusqu la fin des annes 1980, la technologie sans fil a surtout t utilise dans le cadre de
la radio, de la tlvision ou des communications rserves dimportants organismes comme
larme. Cest larrive des tlphones cellulaires GSM (Global System for Mobile communications)
qui a offert tous la possibilit de communiquer de nimporte o, avec nimporte qui.
En 1997, alors que lattention est accapare par le succs dInternet, un vnement est
pass inaperu sauf pour quelques spcialistes et observateurs :ladoption du standard IEEE
802.11 ou Ethernet sans fil. Exploitant la bande de frquence de 2,4 GHz, le 802.11
plafonne un dbit de 2 Mbits/s au maximum. Ce prcurseur est suivi de plusieurs
dclinaisons dont le clbre Wi-Fi (Wireless Fidelity) qui connat un grand succs. Il dsigne les
diffrentes dclinaisons de la norme IEEE 802.11 qui permet plusieurs ordinateurs de
communiquer sans fil en utilisant comme support les ondes radio. Les cbles disparaissent
enfin [5].
4
2.4 Dfinition
Un rseau sans fil peut tre considr comme un systme de transmission de donnes, dont
le but est dassurer une liaison indpendante de lemplacement des entits informatiques qui
composent le rseau [1]. Les rseaux sans fil sont bass sur une liaison utilisant des ondes
radiolectriques (radio et infrarouges) en lieu et place des cbles habituels.
Grce aux rseaux sans fil, un utilisateur a la possibilit de rester connect tout en se
dplaant dans une zone gographique plus ou moins tendue.
Les deux termes mobile et sans fil sont souvent confondus, le terme sans fil dsigne la
nature des liens utiliss dans linterconnexion des diffrents composants du rseau, alors que
le terme mobile dsigne la possibilit de dplacement des utilisateurs du rseau suite
lutilisation des liens sans fil. En effet, on peut dire que tous rseau mobile est un rseau sans
fil, et le contraire nest pas toujours vrais.
Il existe plusieurs technologies se distinguant dune part par la frquence dmission utilise
ainsi que le dbit et la porte des transmissions. Les rseaux sans fil permettent de relier trs
facilement des quipements distants dune dizaine de mtres quelques kilomtres.
2.4 Caractristiques
Lutilisation dune interface sans fil introduit nombres de diffrences par rapport la
communication par cble.
Tout dabord, le spectre radio, et donc la capacit disponible pour le transfert de donnes
sont limits par la rglementation. La bande de frquence occupe par un rseau mobile ne
peut tre tendue. Cette restriction limite galement le dbit disponible imposant la ncessit
dune utilisation efficace du canal.
Ensuite, la qualit des liens radio peut varier avec le temps au gr des diverses interfrences
et de la mobilit des usagers. Cette situation mne donc un taux derreurs de transmission
plus important que sur un rseau filaire et surtout un taux trs fluctuant.
Une des diffrences majeures entre ces deux types de rseaux reste tout de mme le
caractre dynamique dun rseau sans fil. Le point daccs dune entit sur un rseau filaire est
fixe alors que dans le cas dun rseau sans fil, lusager peut se connecter depuis diffrents
lieux et peut mme changer de point daccs au cours de sa connexion. Le problme est alors
dans un premier temps de retrouver un utilisateur dans le rseau et donc un chemin
permettant de latteindre. Dans un deuxime temps, il faut pouvoir maintenir sa connexion de
faon transparente et ce, malgr sa mobilit et ses changements de zone de communication.
Un autre aspect important est que laccs physique aux donnes dun rseau sans fil est non
scuris. En effet, si dans le cas dun rseau filaire on peut protger les points daccs et les
cbles reliant les diffrents postes, dans le cas dun rseau sans fil, nimporte qui peut couter
le rseau et donc rcuprer les donnes transitant par linterface air. Ceci va donc impliquer
lutilisation de mcanismes de chiffrement et dauthentification afin dassurer la
confidentialit des donnes [5].
2.4 Classification des rseaux sans fil

Les rseaux sans fil peuvent tre classs selon divers critres :la zone de couverture, la
topologie et le mode de fonctionnement.
5
2.4.1 Selon la zone de couverture

Une classification classique concerne ltendue gographique, Ils sont diviss en quatre
classes.
a) Rseaux personnels sans fil (WPAN)
Le rseau personnel sans fil not (WPAN pour Wireless Personal Area Network) concerne les
rseaux sans fil d'une faible porte : de l'ordre de quelques dizaines de mtres. Ce type de
rseau sert gnralement relier des priphriques (imprimante, tlphone portable, appareils
domestiques, ...) ou un assistant personnel (PDA) un ordinateur sans liaison filaire ou bien
permettre la liaison sans fil entre deux machines trs peu distantes.
b) Rseaux locaux sans fil (WLAN)

Le rseau local sans fil (WLAN pour Wireless Local Area Network) est un rseau permettant
de couvrir l'quivalent d'un rseau local d'entreprise, soit une porte d'environ une centaine
de mtres.
c) Rseaux mtropolitains sans fil (WMAN)

Le rseau mtropolitain sans fil (WMAN pour Wireless Metropolitan Area Network) est connu
sous le nom de Boucle Locale Radio (BLR). Les WMAN sont bass sur la norme IEEE
802.16. La boucle locale radio offre un dbit utile de 1 10 Mbit/s pour une porte de 4 10
kilomtres, ce qui destine principalement cette technologie aux oprateurs de
tlcommunication.
d) Rseaux tendus sans fil (WWAN)

Le rseau tendu sans fil (WWAN pour Wireless Wide Area Network) est galement connu
sous le nom de rseau cellulaire mobile. Il s'agit des rseaux sans fil les plus rpandus puisque
tous les tlphones mobiles sont connects un rseau tendu sans fil.
Les diffrentes technologies utilises dans chaque catgorie et leurs caractristiques sont
regroupes dans le tableau 1.1[20].
Catgorie WPAN WLAN WMAN WWAN

Standard IEEE 802.15 IEEE 802.11 IEEE 802.16 IEEE 802.20
Bluetooth Wifi WiMax GSM
HomeRF HyperLAN2 GPRS
Technologies
Zigbee UMTS
IR(infrarouge)
quelques dizaines une centaine quelques dizaines une centaine
de mtres de mtres de kilomtres de kilomtres
Couverture
<1 Mbps 2 54 Mbps Jusqu' 70 Mbps 10 384
Dbit
Kbps
Point point Rseau Fixe, accs au GSM
Applications quipement d'entreprise dernier kilomtre PDA...
quipement
Tab 1.1 : La famille de lIEEE 802 sans fil.
6
2.4.2 Selon la topologie du rseau

Une deuxime classification moins classique consiste classifier les rseaux sans fil suivant la
topologie et linfrastructure utilise.
utilise. Les topologies que lon peut identifier sont les suivantes
[9] :
Topologie totalement connecte

Tous les nuds du rseau s'entendent et il n'y a donc nul besoin de protocole de Routage
(Figure 1.1).
Lien sans fil
Nud
Fig. 1 .1 Topologie totalement connecte
Topologie station de base

Ce modle met en uvre une station de base qui centralise les communications entre les
nuds du rseau. L'unique moyen de communication pour un nud est de passer par la
station de base (Figure : 1.2).
Fig. 1.2
1. : Topologie station de base.
Topologie routage interne

Dans cette architecture, les nuds ne s'entendent pas tous. Le rseau se base sur un
routage interne entre ses membres (Figure
(Fig 1.3).
Fig. 1.3:
1. Topologie routage interne.
7
Topologie combine ou hybride

Consiste un mlange de type de rseaux, combinant une architecture filaire avec des rseaux
sans fil (Figure : 1.4).
Liens sans fil
Lien filaire
Fig. 1.4: Topologie hybride
2.4.3 Selon le mode de fonctionnement

Les rseaux sans fil, peuvent tre classs en deux classes : les rseaux avec infrastructure et
les rseaux sans infrastructure. Le standard IEEE 802.11 dfinit les deux modes de
fonctionnement (figure 1.5).
Les rseaux sans fil
Les rseaux avec infrastructure Les rseaux sans infrastructure
Fig. 1.5: Classification des rseaux sans fil
a)Les rseaux avec infrastructure

Dans ce cas, toute transmission de donnes doit passer par un point (nomm point
d'accs) et ce mme si deux mobiles communicants sont proches. Cette entit particulire
joue le rle de routeur lintrieur du rseau sans fil et souvent de passerelle vers un rseau
filaire. Chaque point d'accs administre alors une zone gographique et assure la liaison avec
d'autres zones, avec un rseau filaire ou avec internet (fig1.6). Les rseaux cellulaires (GSM,
UMTS) peuvent tre considrs comme tant une forme particulire de rseau avec point
d'accs.
8
Point daccs
Rseaux statiques
Zone de couverture
Units mobiles
Fig. 1.6 : Exemple de mode infrastructure.
b) Les rseaux sans infrastructure ou ad hoc

Dans ce mode de communication, chaque mobile (appel aussi nud) du rseau a la
possibilit de communiquer directement avec tous ses voisins, c'est dire tous les nuds
capables de recevoir le signal envoy et de le comprendre. Chaque nud peut se connecter,
con se
dplacer ou se dconnecter du rseau a tout moment. Il n'y a aucune infrastructure. On parle
alors des rseaux ad hoc ou MANET (Mobile
( Ad hoc NETwork).
Fig. 1.7 : Exemple de mode ad Hoc.
3 Prsentation de la norme 802.11

3.1 Le model de rfrence OSI
Propos en 1984 par lISO (International Standards Organisation), le modle OSI (Open
( System
Interconnection)) est devenu une norme internationale servant de guide aux mises en rseau .Ce
modle de rfrence nest pas une architecture de rseaux parce quil ne spcifie pas
rellement les services et protocoles utiliss dans chaque couche ; il dcrit simplement ce que
chaque couche doit faire. Ainsi le modle nest rien de moins quune pile de couches exerant
chacune des fonctions bien dfinies : ces couches sont au nombre de 7 comme lillustre la
figure 1.8 [3].
9
La couche physique : soccupe de la transmission des bits de faon brute sur un canal
de communication .Sa conception doit tre telle que lon soit sr que, lorsquun ct
envoie un bit 1, on reoit de lautre ct un bit 1, et non un bit 0.
La couche liaison de donnes : sa tche est de prendre un moyen de transmission brut
et de le transformer en une ligne qui parait exempte derreur de transmission la couche
rseau.
La couche rseau : permet de grer le sous rseau de communication dont elle doit
connatre la topologie .Cette gestion comprend : le contrle de flux et le routage de
paquets ainsi que leurs adressage.
La couche transport : sa fonction de base est daccepter des donnes de la couche
session de les dcouper en plus petite units, de les passer la couche rseau et de
sassurer que tous les morceaux arrivent correctement de lautre ct .
La couche session : permet des utilisateurs travaillant sur diffrentes machines
dtablir des sessions entre eux (gestion du dialogue etc.).
La couche prsentation : la diffrence des autres couches, celle-ci sintresse la
syntaxe et la smantique de linformation transmise.
La couche application : joue le rle dinterface pour laccs des applications aux services
du rseau. [3].
Fig.1.8 : le modle de rfrence OSI.
APDU : Application Protocol Data Unit.

PPDU : Presentation Protocol Data Unit.
SPDU : Session Protocol Data Unit.
TPDU : Transport Protocol Data Unit.
10
3.2 Les rseaux sans fil et le modle OSI

Le modle OSI est conu initialement pour rpondre aux besoins des rseaux filaires, les
rseaux sans fil ont des caractristiques diffrentes des rseaux filaires (mobilit, qualit du
signal). Malgr ces particularits, le passage au monde sans fil a gard le principe de
conception en couche du modle OSI .Comme tous les standards IEEE 802, le standard
802.11 se concentre sur les deux premiers niveaux, la couche physique et la couche liaison de
donnes.
Fig. 1.9 :802.11 et le modle OSI.
3.3 Le standard IEEE 802.11

Normalis par lIEEE en 1997, le protocole 802.11 est le standard le plus rpandu dans le
monde des rseaux sans fil. Grce a sans succs commercial, il est devenu non seulement le
dominant dans le mode infrastructure mais aussi dans les travaux et publications scientifique
sur les rseaux ad hoc.
Le standard 802.11 s'attache dfinir les couches basses du modle OSI pour une liaison
sans fil utilisant des ondes lectromagntiques, c'est--dire :
La couche physique :(note parfois couche PHY)
La couche liaison de donnes : constitue de deux sous-couches : le contrle de la liaison
logique (Logical Link Control, ou LLC) le contrle d'accs au support (Media Access Control,
ou MAC).
La couche physique dfinit la modulation des ondes radiolectriques et les caractristiques
de la signalisation pour la transmission de donnes, tandis que la couche liaison de donnes
dfinit l'interface entre le bus de la machine et la couche physique, notamment une mthode
d'accs proche de celle utilise dans le standard Ethernet et les rgles de communication entre
les diffrentes stations. La norme 802.11 propose en ralit trois couches physiques [5].
3.3.1 Couche physique

Initialement, le standard IEEE 802.11 admet les trois spcifications diffrentes de la
couche physique : FHSS (Frequency Hoping Spread Spectrum), DSSS (Direct Sequence Spread
Spectrum) et IR (InfraRed), auxquelles 802.11a a rajout la technique OFDM (Fig 1.10) [4].
11
Couches suprieures
802.11 802.11b 802.11a/g Infra

2 Mbps 11 Mbps 54Mbps PHY
Rouge
FHSS DSSS OFDM
Fig 1.10 : La couche PHYSIQUE dans le rseau sans fil.
FHSS : (talement de Spectre avec Saut de Frquences)

FHSS (Frequency Hopping Spread Spectrum) est Utilise dans les rseaux 802.11b et dautres
technologies sans fil, cette technologie utilise la technique de saut de frquence. Son principe
est de diviser la bande passante en 79 sous-canaux de 1 MHz de largeur de bande offrant
chacun, un dbit allant de 1 2 Mbps avec un codage binaire. Lmetteur et le rcepteur
saccordent sur une squence de sauts de frquence porteuse et les donnes sont envoyes
successivement sur les diffrents sous canaux en vitant (de manire temporaire) dutiliser les
sous canaux fortement perturbs. Chaque communication sur le rseau seffectue suivant un
schma de saut diffrent et cela de faon minimiser le risque que deux missions utilisent le
mme sous canal [1].
DSSS : (talement de Spectre Squence Directe)

Le DSSS (Direct Sequence Read Spectre) est une couche physique utilisant une technique radio.
Cest une technologie de transmission par spectre tal, o la porteuse est successivement
module par linformation et par un code pseudo alatoire de dbit beaucoup plus important.
Le signal rsultant occupe donc une bande trs importante.
Dans cette technique, la bande des 2.4 GHz est divise en 14 sous-canaux de 22MHz (fig
1.11). Cette technique offre des dbits de transmission allant de 5.5 11 Mbps. Avec comme
avantages :
Une densit spectral faible du signal transmis, car ce dernier est large bande.
Une scurit assure, tant que le code dtalement reste secret [1].
Fig. 1.11 : talement de Spectre Squence Directe DSSS
12
OFDM : (Multiplexage par Rpartition Orthogonale de la Frquence)

La technologie OFDM (Orthogonal Frequency Division Multiplexing) reprsente une technique
de modulation numrique des signaux, utilise entre autres pour les systmes de transmissions
mobiles haut dbit de donnes. Elle consiste rpartir le signal sur un grand nombre de
sous porteuses orthogonales modules individuellement bas dbit.
Ainsi, des normes telles que 802.11a et 802.11g peuvent offrir des dbits thoriques jusqu
54 Mbps, l o la norme 802.11b qui nest pas OFDM, se limite 11 Mbps [1].
Infrarouge
En utilisant un faisceau de lumire, ce mode est bas sur lutilisation des mmes frquences
que celles utilises sur les fibres optiques. Malgr que la lumire infrarouge possde une large
bande passante offrant par consquent des dbits relativement importants, la porte de ce
type de communications reste faible. En revanche, les infrarouges peuvent pntrer travers
le verre, mais pas travers des obstacles opaques, ce qui reprsente un avantage en terme de
scurit. Mais, comme les rseaux infrarouges sont sensibles aux interfrences lumineuses, la
coupure du faisceau lumineux implique linterruption de la transmission.
3.3.2 La couche liaison de donnes

La couche liaison de donnes a pour objectif de raliser lacheminement sans erreur de
blocs dinformations sur la liaison physique cest dire sur le circuit de donnes reliant deux
commutateurs adjacents. Afin deffectuer une transmission correcte, la couche liaison de
donnes attache des en-ttes et des caractres aux paquets de donnes transmettre. Dans ce
cas, les messages changs sont appels trames MAC ou MPDU (MAC Protocol Data Unit).
Ceux ci seront encapsuls par la suite dans des trames de niveau physique appeles PLCP-
PDU (Physical Level Control Protocol-PDU).
3.3.2.1 La sous-couche LLC (Logical Link Control)

La sous-couche LLC (spcification IEEE 802.2), qui est indpendante des mcanismes
daccs au support physique, reprsente une partie de la couche de liaison de donnes. Elle
prsente les caractristiques de fiabilit grce au squencement et la retransmission des
donnes en cas de dtection derreurs.
3.3.2.2 La sous-couche MAC (Medium Access Control)

La sous-couche MAC, permet un hte de communiquer avec plusieurs priphriques en
mme temps. En effet, la sous-couche MAC est ncessaire pour grer les accs au canal de
communication, car lun des problmes majeurs des rseaux sans fil consiste savoir qui a le
droit dmettre un moment donn [1]. La norme IEEE 802.11 dfinit deux modes daccs
au mdium au niveau MAC :
Le mode centralis (Point Coordination Function, PCF) : peut tre utilis lorsque les
communications sont gres par une station de base fixe.
Le mode distribu (Distributed Coordination Function, DCF) : utilis la fois pour les
communications via une station de base et pour les communications directes de mobile
mobile. Cest ce dernier mode qui est utilis dans le cas des rseaux ad hoc [17].
Des protocoles ont t proposs afin de rsoudre ces problmes daccs. Dans ce qui suit
nous prsentons un chantillon de ces techniques dans le cadre des rseaux sans fil [1].
13
FDMA : (Accs Multiple par Rpartition en Frquence)

Lide est de diviser le spectre en canaux et daffecter chaque interlocuteur ou chaque
message (un la fois), un canal frquentiel. Cette affectation est alors base sur le principe du
premier arriv, premier servi ou FIFO (First In First Out).
En pratique, le message utilis sert moduler une frquence porteuse ( lorigine en
amplitude, parfois avec suppression de porteuse) et les diffrentes porteuses ainsi modules
sont juxtaposes. Du ct du rcepteur, des filtres slectifs isolent les diffrentes porteuses
dmodules et si les frquences porteuses sont parfaitement connues ou restitues, une
dmodulation cohrente (synchrone) est effectue [1].
TDMA (Accs Multiple par Rpartition dans le Temps)

Dans cette technique, les canaux sont multiplexs sous la forme dintervalles de temps de
telle faon que chaque correspondant ou chaque message occupe la totalit de la bande mais
pendant un temps trs court (accs toute la bande passante alloue pour le systme de
transmission). Avec le TDMA, les chantillons issus dun message sont intercals avec ceux
des autres. Ainsi, le tri de ses chantillons se fait du ct du rcepteur.
Le fait que le TDMA prsente une gestion complexe, il faut ajouter des bits de signalisation
et de synchronisation, mais cette technique offre un cot rduit pour la station de base, ainsi
quune souplesse de modification sur les dbits transmis [1].
CDMA (Accs Multiple par Rpartition en Code)

Ici, tous les utilisateurs accdent simultanment la totalit de la bande, ils sont distingus
la rception grce des codes pseudo-alatoires personnels. Ce qui permet davoir une
bonne immunit au bruit et la possibilit dutiliser la diversit de frquences, ainsi que le
cryptage. La technique CDMA utilise des modulations talement de spectre qui peuvent
tre ralises par saut de frquence ou par squence directe. En effet, le CDMA est trs
souple au niveau des dbits transmis, mais relativement complexe car elle peut ncessiter une
galisation la rception et un contrle de la puissance dmission [1].
La figure 1.12 montre une comparaison entre les diffrentes techniques daccs au canal
radio dcrites prcdemment :
Fig. 1.12: Comparaison des technologies daccs au canal radio.
14
CSMA/CA (Accs
Accs Multiple avec coute de Porteuses/vitement de Collisions)
Collisions
Le CSMA/CA est une technique daccs au mdium utilise dans les rseaux sans fil IEEE
802.11. Elle permet de traiter les problmes des stations caches et des stations exposes expos
illustrs par la figure 1.13,, et dviter les collisions en utilisant le principe appel vitement de
collisions (Collision Avoidance).
A B C A B C D
Fig.1.13. Le problme du nud cach et des nuds exposs.
Dans cette technique, chaque nud (souhaitant mettre des donnes) doit couter le canal
avant de tenter dobtenir laccs. Si le canal est occup le nud doit attendre la fin de la
transmission en cours pour avoir le droit daccs au mdium. Lorsque le le canal devient libre,
avant toutes choses, il faut quil le reste pour une priode DIFS (DCF Inter-Frame
Inter Space), si le
canal reste libre durant le DIFS alors les nuds qui veulent mettre choisissent un temps
de temporisation appel backoff [1] ; Le backoff est choisit au hasard dans un intervalle appel
Contention Window (CW)qui est par dfaut [0 ;31] ; avec un time slot de 20 s, le backoff va donc
tre compris entre 0 et 620 s. et la taille de la fentre va doubler afin de diminuer les chances
que de telles collisions se rp
ptent. La borne infrieure de la Contention Window est toujours
zro, et la borne suprieure
rieure (dont les valeurs autorises
autoris es par la norme ne sont que des
puissances de 2 moins 1) va voluer oluer entre les valeurs CWmin et CWmax dfinies par la
norme [15].
Lorsque la temporisation expire, si le canal est inoccup, ils peuvent commencer lenvoi de
ses paquets. Dans le cas de plusieurs nuds qui veulent accder au canal, celui qui a choisi la
temporisation la plus courte est donc celui qui gagne le droit daccs et les autres doivent
attendre simplement la fin de la transmission pour avoir le droit de tenter nouveau laccs
au mdium [1].. Le mcanisme de backoff limite les risques de collision mais ne les supprime
pas compltement .due cette insuffisance le 802.11 802.11 propose lutilisation du mcanisme
RTS/CTS (figure.1.14) [4].
Fig. 1.14
1 Le mcanisme RTS/CTS.
15
Un nud vrifie si le mdium est libre. Si le mdium est occup, lmetteur attend quil se
libre, puis attend un temps alatoire avant dmettre. Si personne nest en train dmettre, le
nud envoie un message de type RTS (Request To Send) contenant ladresse de destination et
la dure de la transmission pour demander la parole. Les autres nuds savent donc que le
mdium sera occup pendant cette dure. Le destinataire rpond avec un message de type
CTS (Clear To Send) qui indique quil est prt recevoir les donnes sans aucun risque de
collision.
Chaque paquet doit tre acquitt et si aucun acquittement nest reu, le paquet est
retransmis. Il faut noter que le temps qui spare un paquet de donnes de son acquittement
est appel SIFS (Short Inter frame Space).
Une autre fonction importante appele coute de la porteuse virtuelle fournie par le vecteur
NAV (Network Allocation Vector). Le NAV reprsente une minuterie indiquant la dure
pendant laquelle le mdium sera rserv. Chaque nud fixe le NAV sa dure dutilisation du
mdium, en incluant les trames ncessaires la terminaison de lopration en cours [1].
3.4 Les diffrentes drives de la norme 802.11

La norme IEEE 802.11 est la norme initiale offrant des dbits de 1 ou 2 Mbps .Des
rvisions ont t apportes la norme originale afin d'optimiser le dbit (c'est le cas des
normes 802.11a, 802.11b et 802.11g, appeles normes 802.11 physiques) ou bien prciser des
lments afin d'assurer une meilleure scurit ou une meilleure interoprabilit. Dautres
normes sont orientes vers lamlioration de la qualit de service (QoS) tel que 802.11 e.
Le tableau (tab 1.2) reprsente les principales drives de la norme 802.11 et leurs
caractristiques :
Norme caractristiques
-Date de normalisation : 1997
802.11 -Bande de frquence : 2.4 GHz
-Dbit : thorique: 2 Mbps, rel:<1 Mbps
-Porte thorique : 100 m
-Bande de frquence : 5 GHz
802.11a -Dbit : thorique: 54 Mbps, rel:30 Mbps
-Spcificit: 8 canaux radio
-Bande de frquence : 2.4 GHz
802.11b -Dbit : thorique: 11 Mbps, rel:6 Mbps
-Spcificit: 3 canaux radio
802.11e Amlioration de la qualit de service (niveau MAC) pour le support
audio et vido.
802.11f Interoprabilit entre les points d'accs
-Bande de frquence : 2.4 GHz
802.11g -Dbit : thorique: 54 Mbps, rel:30 Mbps
-Spcificit: compatibilit 802.11b
802.11h Adaptation de 802.11a aux normes d'missions lectromagntiques
Europennes.
802.11i Amlioration de la scurit des transmissions sur les bandes de
frquences 2.4 GHz et 5 GHz.
16
802.11n -Date de normalisation : 2006

-Dbit : thorique: 500 Mbps
-Implmente la technologie MIMO (Multiple Input Multiple Output)
802.11k Apporte des amliorations dans le domaine de la mesure des ressources radio,
but : darriver une meilleure gestion et la maintenance des WLAN.
802 .11r -Date de normalisation : 2008
-Amlioration des performances de la VoIP (Voice over IP)
Tab 1.2 la famille de IEEE 801.11.
4 Les rseaux mobiles ad hoc

L'volution rcente de la technologie dans le domaine de la communication sans fil et
l'apparition des units de calculs portables (les laptops par exemple), poussent aujourd'hui les
chercheurs faire des efforts afin de raliser le but des rseaux : "l'accs l'information
n'importe o et n'importe quand".
Le concept des rseaux mobiles ad hoc essaie d'tendre ces notions de la mobilit toutes
les composantes de l'environnement. Ici, contrairement aux rseaux bass sur la
communication cellulaire, aucune administration centralise n'est disponible, ce sont les htes
mobiles elles-mmes qui forment, d'une manire ad hoc, une infrastructure du rseau.
Aucune supposition ou limitation n'est faite sur la taille du rseau ad hoc, le rseau peut
contenir des centaines ou des milliers d'units mobiles, voire des centaines de milliers.
Les rseaux ad hoc sont idals pour les applications caractrises par une absence (ou la
non fiabilit) d'une infrastructure prexistante, telles que les applications militaires et les
autres applications de tactique comme les oprations de secours (incendies, tremblement de
terre..) et les missions d'exploration.
4.1 Dfinition
Dans le RFC 2501[10] de IETF (Internet Engineering Task Force), qui reprsente lorganisme
responsable de llaboration de standards pour Internet, dfinit les rseaux mobiles ad hoc
(appels gnralement MANETs pour Mobiles Adchoc NETwork) de la manire suivante :
" Un rseau ad hoc est un systme autonome de plates-formes mobiles (par exemple un
routeur interconnectant diffrents htes et quipements sans fil) appeles nuds qui sont
libres de se dplacer alatoirement et sans contrainte. Ceci provoque des changements rapides
et prdictibles de la topologie du rseau. Ce systme peut fonctionner dune manire isole ou
sinterfacer des rseaux fixes au travers de passerelles. Dans ce dernier cas, un rseau ad hoc
est un rseau dextrmit".
4.2 Modlisation
Un rseau mobile ad hoc peut tre modlis par un graphe Gt = (Vt , Et ) o :
Vt : reprsente l'ensemble des nuds (i.e. les units ou les htes mobiles) du rseau.
Et : modlise l'ensemble des connections qui existent entre ces nuds. (Figure 1.15).
Si e = (u, v) Et , cela veut dire que les nuds u et v sont en mesure de communiquer
directement l'instant t [6].
17
Fig. 1.15-
1.1 La modlisation d'un rseau ad hoc.
4.3 Domaines dapplication des rseaux ad hoc

Les premires applications des rseaux ad hoc concernaient les communications et les
oprations dans le domaine militaire. Cependant, avec lavancement des recherches dans le
domaine des rseaux et lmergence des technologies
technologies sans fil (ex : Bluetooth, IEEE 802.11 et
Hiperlan) ; dautres applications civiles sont apparues. On distingue [7] :
Les services durgence : opration de recherche et de secours des personnes,
tremblement de terre, feux, inondation, dans le but de remplacer linfrastructure filaire.
Le travail collaboratif et les communications dans des entreprises ou btiments :
dans le cadre dune runion ou dune confrence par exemple.
Home network : partage dapplications et communications des quipements mobiles. m
Applications commerciales : pour un paiement lectronique distant (taxi) ou pour
laccs mobile lInternet, o service de guide en fonction de la position de lutilisateur.
Rseaux de senseurs : pour des applications environnementales (climat, activit ac de la
terre, suivi des mouvements des animaux, . . . etc.) ou domestiques (contrle des
quipements distance).
Rseaux en mouvement : informatique embarque et vhicules communicants.
D'une faon gnrale, les rseaux ad hoc sont utiliss dans dans toute application o le
dploiement d'une infrastructure filaire est trop contraignant, soit parce que difficile mettre
en place, soit parce que la dure d'installation du rseau ne justifie pas de cblage demeure.
4.4 Les caractristiques

ctristiques des rseaux ad hoc
Les MANET ont plusieurs caractristiques particulires [10] :
Une topologie dynamique : les nuds sont libre de se dplacer arbitrairement, ce qui
fait que la topologie du rseau peut changer alatoirement et rapidement nimporte quel
moment,, et peut tre constitue la fois de liaisons unidirectionnelles ou
bidirectionnelles.
Liaisons dbit variable et bande passante limite : les liaisons sans fil auront
toujours une capacit infrieure leurs homologues filaires. En plus, le dbit
d rel des
communications sans fil aprs avoir dduit les effets des accs multiples, du bruit et des
interfrences, etc., est souvent infrieur au dbit de transfert maximum de la liaison
radio.
Utilisation limite de l'nergie : Une partie des nuds d'un MANET voire
l'ensemble des nuds, peut reposer sur des batteries ou un autre moyen limit pour
leur nergie .Pour
Pour ces nuds, le plus important est sans doute de mettre en place
pl des
critres d'optimisation
tion pour la conversation de lnergie.
18
Scurit physique limite : Les rseaux sans fil sont gnralement plus sensibles aux
menaces physiques que les rseaux cbls. Les techniques existantes pour la scurit des
liaisons sont souvent appliques au sein des rseaux sans fil pour rduire les risques
d'attaques. Notons cependant un avantage dans le fait que le contrle des rseaux
MANET soit dcentralis ajoute sa robustesse, contrairement aux problmes pouvant
survenir sur les points centraux dans les approches plus centralises [10].
L'absence d'infrastructure : Les rseaux ad hoc se distinguent des autres rseaux
mobiles par la proprit d'absence d'infrastructures prexistante et de tout genre
d'administration centralise. Les htes mobiles sont responsables d'tablir et de
maintenir la connectivit du rseau d'une manire continue [8].
Conclusion
Lvolution rapide de la technologie de tlcommunication sans fil, a permet la
manipulation de linformation travers des units de calculs portables. Ces units ont des
caractristiques particulires et accdent au rseau travers une interface de communication
sans fil. La mobilit et le nouveau mode de communication utilis, engendrent de nouvelles
caractristiques propres lenvironnement mobile. Ces caractristiques nous obligent
changer la vision classique aux problmes lis aux diffrentes stratgies de routage proposes
pour les rseaux filaires, ces stratgies deviennent plus en plus complexes quand il sagit dun
rseau ad hoc.
Les systmes de communication cellulaire sont bass essentiellement sur l'utilisation des
rseaux filaires (tel que Internet) et la prsence des stations de base qui couvrent les
diffrentes units mobiles du systme. Les rseaux mobiles "ad hoc" sont l'inverse, des
rseaux qui s'organisent automatiquement de faon tre dplorable rapidement, sans
infrastructure fixe, et qui doivent pouvoir s'adapter aux conditions de propagation, aux trafics
et aux diffrents mouvements pouvant intervenir au sein des nuds mobiles.
Dans ce chapitre, nous avons prsent plusieurs concepts de bases lis aux rseaux sans fil,
notamment la norme IEEE 802.11 et les concepts des rseaux ad hoc.
Dans le prochain chapitre nous allons tudier le concept de routage dans les rseaux
mobiles ad hoc, et une description de quelques protocoles de routage MANET
particulirement le protocole AODV.
19
Chapitre II
Routage dans les rseaux mobiles ad hoc

Chapitre II Routage dans les rseaux mobiles ad hoc
Routage dans les rseaux mobiles ad hoc
1 Introduction
linverse dun rseau de tlcommunication classique, Larchitecture dun rseau mobile
ad hoc tant caractrise par une absence dinfrastructure fixe prexistante, il doit sorganiser
automatiquement de faon tre dployable rapidement et pouvoir sadapter aux conditions
de propagation, au trafic et aux diffrents mouvements des units mobiles.
Le principe du routage dans les rseaux avec infrastructure repose sur le fait que la source
transmet un datagramme une destination en lenvoyant pralablement au routeur le plus
proche. Le paquet transite dans le rseau de routeur en routeur jusqu' ce quil soit rout
directement sur le destinataire. Or dans les rseaux mobiles ad hoc, ce systme ne peut tre
appliqu. La notion de routeur nexiste pas et ce sont les terminaux eux mme qui doivent
prendre en charge le routage des paquets. Chaque nud est susceptible d'tre mis
contribution pour participer au routage et retransmettre les paquets ; tout nud joue ainsi le
rle de station et de routeur [17].
MANET (Mobile ad hoc NETwork) [10] est un groupe de travail au sein de lIETF
(Internet Engineering Task Force) qui a merg du groupe de travail mobile IP. Le groupe
MANET se concentre sur les protocoles de routage dans les rseaux mobiles ad hoc et se
propose de standardiser des protocoles de routage au niveau IP. Les protocoles de routage
doivent tre totalement distribus, c'est dire qu'aucune entit centrale ne doit tout
commander, en plus, les protocoles doivent ragir aux changements imprvisibles et rapides
de la topologie du rseau.
Ce chapitre est consacr au routage dans les rseaux mobiles ad hoc, pour cela il introduit
les diffrents concepts lis au routage dans les rseaux mobiles ad hoc ; les contraintes, une
taxonomie des protocoles existants ; ainsi quune tude de quelques protocoles existants et
une tude dtaille du protocole AODV qui est au centre des travaux de ce mmoire.
2 Dfinitions
Le terme routage dsigne lensemble des mcanismes mis en uvre dans un rseau pour
dterminer les routes qui vont acheminer les paquets dun terminal metteur un terminal
rcepteur [43]. On distingue gnralement deux entits :
Lalgorithme de routage est la partie du logiciel de la couche rseau qui a la responsabilit
de dcider sur quelle ligne de sortie un paquet entrant doit tre retransmis [3].Le but d'un
algorithme de routage est de permettre le calcul de route entre une source et une destination
au sens d'un certain critre (plus court chemin par exemple), et la diffusion des informations
ncessaires ce calcul.
Un protocole de routage est un ensemble de rgles sappliquant au format et la
signification des trames, paquets ou messages changs entre entits paires au sein de la
couche rseau [3].
21
3 Problmatique du routage dans les rseaux mobile ad hoc

Les contraintes des rseaux mobiles ad hoc rendent lapplication des protocoles de routage
traditionnellement dploys dans les rseaux filaires inefficace, les principaux problmes qui
se posent sont :
La capacit limite des liens (liens radio) : un protocole de routage ad hoc doit tre
efficace en bande passante utilise. Il doit minimiser le trafic de contrle (overhead)
ncessaire ltablissement et la maintenance des routes afin de rduire la charge sur le
rseau.
La nature variable des liens (unidirectionnelle ou bidirectionnelle) doit tre prise en
compte par le protocole de routage.
Les ressources matrielles restreintes des units mobiles excluent les algorithmes
exigeants en capacit de mmoire et de traitement.
Changements frquents dans la topologie : lalgorithme dobtention dune route doit
prendre en compte la mobilit des nuds et rechercher la route la plus courte en
nombre de sauts. En effet, le dplacement des units mobiles peut remettre en cause la
validit des informations de routage.
Labsence dinfrastructure ou dadministration fixes dans le rseau impose par ailleurs
un fonctionnement distribu [2].
En effet l'tude et la mise en uvre d'algorithmes de routage pour assurer la connexion des
rseaux mobiles ad hoc au sens classique du terme (tout sommet peut atteindre tout autre),
est un problme complexe. Il semble donc important que toute conception de protocole de
routage doive tudier les problmes suivants :
La minimisation de la charge du rseau : l'optimisation des ressources du rseau
renferme deux autres sous problmes qui sont l'vitement des boucles de routage, et
l'empchement de la concentration du trafic autour de certains nud s ou liens.
Offrir un support pour pouvoir effectuer des communications multipoints
fiables : le fait que les chemins utiliss pour router les paquets de donnes puissent
voluer, ne doit pas avoir d'incident sur le bon acheminement des donnes.
L'limination d'un lien, pour cause de panne ou pour cause de mobilit devrait,
idalement, augmenter le moins possible les temps de latence.
Assurer un routage optimal : la stratgie de routage doit crer des chemins optimaux
et pouvoir prendre en compte diffrentes mtriques de cots (bande passante, nombre
de liens, ressources du rseau, dlais de bout en bout,etc.). Si la construction des
chemins optimaux est un problme complexe, la maintenance de tels chemins peut
devenir encore plus complexe, la stratgie de routage doit assurer une maintenance
efficace de routes avec le moindre cot possible.
Le temps de latence : la qualit des temps de latence et de chemins doit augmenter
dans le cas o la connectivit du rseau augmente [8].
4 Taxonomie des protocoles de routage dans les MANETs

Les protocoles de routage ddis aux rseaux ad hoc peuvent tre caractriss par leur
catgorie (protocoles proactifs, ractifs ou hybrides), leur architecture (plate ou hirarchique)
ainsi que par leur type dalgorithmes (voir fig. 2.2) [2].
Avant de dcrire les diffrentes classifications, il est bon de rappeler quels sont les
principaux modes de communication dans les rseaux mobiles : la communication point
22
point ou unicast pour laquelle il y a une source et une seule destination, la communication
multipoint ou multicast qui permet d'envoyer un message plusieurs destinataires et la
diffusion ou broadcast qui envoie un message tous les nuds du rseau. Ces trois modes de
communication sont schmatiss par la figure 2.1 [14].
Fig. 2.1 : Modes de communication dans les rseaux.
La figure 2.2 illustre une taxonomie des protocoles de routage pour les rseaux mobiles ad
hoc :
Routage
Multipoint Routage point point Diffusion
Hirarchique Plat
Slection de Orients Orients

Partitionnement
voisins topologie Destination
GCSR s
*OLSR CBRP
ZRP HSR
Proactif Ractif Proactif Ractif
GSR *DSR DSDV *AODV
FSR WRP TORA
*TBRPF DYMO
* protocoles RFC au niveau de lIETF
Fig. 2.2 : Taxonomie des protocoles de routage ad hoc [16].
4.1 Selon larchitecture

La premire classification des protocoles de routage ad hoc concerne le type de vision
quils ont du rseau et les rles quils accordent aux diffrentes units mobiles.
4.1.1 Les protocoles de routage plat (ou uniformes)

Ces protocoles considrent que tous les nuds sont gaux (fig.2.3). La dcision dun nud
de router des paquets pour un autre dpendra de sa position et pourra tre remise en cause au
cours du temps [15].
23
Fig.2.3 : Routage plat.
Les protocoles de routage uniformes peuvent tre galement regroups selon les donnes
qu'ils utilisent pour effectuer leur tche [16] :
Les protocoles orients topologie

Dans les protocoles orients topologie, chaque nud utilise comme donnes l'tat de ses
connexions avec ses nud s voisins, cette information est ensuite transmise aux autres
nuds pour leur donner une connaissance plus prcise de la topologie du rseau.
Les protocoles orients destinations

Ces protocoles maintiennent pour chaque nud destination une information sur le nombre
de nuds qui les en sparent (la distance) et ventuellement sur la premire direction
emprunter pour y arriver (le vecteur).
4.1.2 Les protocoles de routage hirarchiques (ou non uniformes)

Les protocoles hirarchiques fonctionnent en confiant aux mobiles des rles qui varient de
lun lautre. Certains nud s sont lus et assument des fonctions particulires qui
conduisent une vision en plusieurs niveaux de la topologie du rseau. Par exemple, un
mobile pourra servir de passerelle pour un certain nombre de nud s qui sont relis lui. Un
exemple est donn sur la figure 2.4, o le nud N3 passe par les passerelles P1, P2 et P3
pour atteindre N7 [15].
Fig.2.4 : Routage hirarchique.
On distingue deux modes de fonctionnement dans les protocoles hirarchiques [16] :
24
Les protocoles slection de voisins
Dans les protocoles slection de voisins, chaque nud sous-traite la fonction de routage
un sous-ensemble de ses voisins directs.
Les protocoles partitionnement :
Pour les protocoles partitionnement, le rseau est dcoup en zones dans lesquelles le
routage est assur par un unique nud matre (appel aussi cluster-head).
4.2 Selon lalgorithme utilis

Une autre classification, hrite du monde filaire, est possible pour les protocoles de
routage ad hoc: deux algorithmes de routage sont utiliss, les algorithmes tat de lien (Link-
state) et les algorithmes vecteur de distance (distance Vector) [15].
Les protocoles tat de lien (Link-state protocols)

Les protocoles tat de liens cherchent maintenir dans chaque nud une carte plus ou
moins complte du rseau o figurent les nuds et les liens les reliant. A partir de cette carte
il est possible de construire les tables de routage. Un des avantages de ce type de protocole
est leur capacit pouvoir facilement trouver des routes alternatives lorsquun lien est rompu.
Il est mme possible dutiliser simultanment plusieurs routes vers une mme destination,
augmentant ainsi la rpartition de la charge et la tolrance aux pannes dans le rseau. En
contrepartie, si le rseau est tendu, la quantit dinformations stocker et diffuser peut
devenir considrable.
Les protocoles vecteur de distance (distance Vector protocols)

Ces protocoles ne conservent que la liste des nuds du rseau et lidentit du voisin par
lequel passer pour atteindre la destination par le chemin le plus court. A chaque destination
possible sont donc associs un next-hop et une distance. Si un voisin envoie un paquet de
contrle dans lequel il indique tre plus prs dune destination que le next-hop que lon utilisait
jusqualors, alors il le remplace dans la table de routage. Un des inconvnients de cette
technique est la difficult de conserver plusieurs routes alternatives au cas o celle qui est
privilgie serait rompue (on ne dispose que du next-hop, et on ne sait pas si la suite de la
nouvelle route est indpendante de celle qui a t rompue).
4.3 Les catgories de protocoles de routage MANET

Les protocoles dvelopps pour les rseaux mobiles ad hoc peuvent tre classifis en trois
grandes familles en tant que ractifs, proactifs ou hybrides [1].
4.3.1 les protocoles proactifs

Dans le routage proactif, chaque nud maintient une ou plusieurs tables contenant
linformation de routage vers chaque autre nud du rseau. Tous les nuds mettent leurs
tables jour de faon maintenir une vue consistante et relle du rseau. Lorsque la
topologie du rseau change, les nuds propagent des messages de mise jour travers le
rseau afin de garder cette consistance et de garder jour linformation de routage pour
lensemble du rseau. Ces protocoles diffrent sur la manire par laquelle des changements
25
de topologies sont distribus travers le rseau et sur le nombre de tables ncessaires au

routage. Il existe plusieurs protocoles connus de cette catgorie, titre dexemples, nous
pouvons citer DSDV, GSR, FSR, HSR et ZHLS.
4.3.2 Les protocoles ractifs
Dans cette deuxime catgorie de protocoles de routage dite routage la demande, les
routes ne sont pas maintenues vers tous les nuds mais elles sont cres selon les besoins.
Lorsquil y a un besoin de routage, un mcanisme de dcouverte de route est lanc dans le but
dobtenir une information spcifie, inconnu au pralable et qui va rester valide tant que la
destination est joignable ou jusquau moment o la route devienne inutile. Ici, la majorit des
algorithmes utiliss sont bass sur le mcanisme dapprentissage en arrire. Ce type de routage
est lent cause de la recherche des chemins, ce qui peut dgrader les performances des
applications interactives. De plus, il est impossible de connatre la qualit au pralable dun
chemin (bande passante, dlai, ..), tandis quune telle connaissance est importante pour les
applications multimdia. A titre dexemples, les protocoles appartenant cette catgorie sont
DSR, AODV et TORA.
4.3.3 Les protocoles hybrides

Une troisime catgorie appele les protocoles hybrides permet de combiner les deux
concepts ; celui des protocoles proactifs et celui des protocoles ractifs. Gnralement le
rseau est divis en deux zones et le principe est dutiliser une approche proactive pour avoir
des informations sur les voisins les plus proches, qui se trouvent au maximum deux sauts
du nud mobile. Une approche ractive est utilise au-del de cette zone prdfinie afin de
chercher des routes.
Lavantage de cette troisime catgorie de protocoles est le fait quelle sadapte bien aux
rseaux de grandes tailles. Cependant, cette approche a comme inconvnient de cumuler les
points faibles des protocoles ractifs et ceux des protocoles proactifs, tels que les messages de
contrle priodique et le cot dtablissement dune nouvelle route. Il existe plusieurs
protocoles connus appartenant cette catgorie de protocoles hybride, citons ZRP (Zone
Routing Protocol) et CBRP (Cluster Based Routing Protocol).
5 Description de quelques protocoles MANETs

De nombreux protocoles de routage ont t proposs pour les rseaux mobiles ad hoc.
Les protocoles dcrits dans ce qui suit sont issus du groupe de travail MANET de lIETF.
Ces protocoles sont reprsentatifs de diverses techniques et sont les plus avancs sur la voie
dune normalisation [15]. Ils font dsormais lobjet dune Request For Comment (RFC) au niveau
de lIETF. Les protocoles concerns (table 2.1) sont : OLSR (RFC 3626, octobre 2003) [18]
et TBRPF (RFC 3684, fvrier 2004) [12], ainsi que les protocoles ractifs : DSR (RFC 4728,
fvrier 2007)[13] et AODV (RFC 3561, juillet 2003) [11] ,ce dernier sera tudi en dtails.
Nom DSR AODV OLSR TBRPF

Catgorie Ractifs Proactifs
Architecture plat plat hirarchique hirarchique
Algorithme Routage Vecteur Etat de Etat de
source de liens liens
distance
Table 2.1 : les principaux protocoles MANET
26
5.1 OLSR
OLSR (Optimized Link State Routing) [18] est un protocole proactif tat de liens. Afin de
maintenir jour les tables de routage, chaque nud implmentant OLSR diffuse
rgulirement des informations sur son propre voisinage. Ces informations sont suffisantes
pour permettre chaque nud de reconstruire une image du rseau et de trouver une route
vers nimporte quelle destination. Cette diffusion ne se fait pas par une simple inondation (o
chaque nud retransmet simplement chaque nouveau paquet quil reoit) ; OLSR optimise
la diffusion grce au systme des relais multi-points (MPR : Multi-Points Relays). Chaque nud
choisit dans ses voisins directs un sous-ensemble minimal de nuds qui lui permettent
datteindre tous ses voisins deux sauts. La diffusion des informations sur les liens utiliss
pour le routage se fait ensuite uniquement par les relais multi-points ; la couverture totale du
rseau est assure tout en limitant sensiblement le nombre de rmissions. Afin de choisir ses
relais multipoints, un nud a besoin de connatre compltement la topologie de son
voisinage deux sauts ; cela est ralis grce lenvoi priodique de paquets hello contenant
la liste des voisins connus un saut [15].
5.2 TBRPF
TBRPF (Topologie Dissmination Based on Reverse-Path Forwarding) [12] est un protocole de
routage proactif tat de liens. Chaque nud maintient en permanence un arbre dont il est
la racine et qui fournit les chemins les plus courts pour tous les autres nud s .TBRPF est
constitu de deux parties complmentaires : la dcouverte des voisins et le routage
proprement dit.
La dcouverte des voisins est assure par un mcanisme de paquets hello diffuss
rgulirement au voisinage direct. Ces paquets hello contiennent la liste des voisins du nud,
et permettent ainsi de connatre rapidement la topologie complte du rseau deux sauts. Il
faut noter que TBRPF emploie une technique de hello diffrentiels o seuls les changements de
topologie sont notifis (diminuant ainsi la taille moyenne des paquets et autorisant leur envoi
une plus grande frquence).
La partie routage quant elle est base sur un change des arbres de routage entre nuds
voisins, conduisant progressivement la diffusion de linformation dans lensemble du rseau.
L encore seules des parties darbres sont changes. Normalement, un nud ne diffuse
quun sous-arbre deux niveaux dont il est la racine. Au premier niveau apparaissent les liens
vers tous les voisins directs du nud, et au deuxime niveau un unique lien vers chaque
voisin deux sauts (on peut noter ici une certaine similitude avec le mcanisme des relais
multi-points dOLSR). En conjonction avec ce systme de base, TBRPF peut galement
ajouter des informations sur dautres liens larbre diffus, avant de ragir plus vite en cas de
changement de la topologie. A noter enfin que dans un souci dconomie de bande passante,
les sous-arbres et les paquets hello sont regroups autant que possible dans un mme paquet
(on parle dagrgation ou piggybacking puisque lon profite des paquets hello pour envoyer en
mme temps les sous- arbres) [15].
5.3 DSR
DSR (Dynamic Source Routing) [13] est un autre protocole ractif. Il se diffrencie des autres
en particulier parce quil pratique le source routing : lmetteur prcise dans len-tte de chaque
paquet la liste des nuds quil devra traverser pour atteindre sa destination. Ce type de
routage prsente certains avantages particulirement intressants ; il autorise en particulier la
source conserver dans sa table de routage plusieurs chemins valides vers une mme
27
destination. Le choix du chemin emprunt pourra donc tre fait indpendamment pour
chaque paquet, et permettre un meilleur quilibrage de la charge du rseau ou une meilleure
ractivit aux changements de topologie. Dans la pratique, DSR est structur en deux sous-
parties complmentaires : la recherche de route et la maintenance de route. La recherche de
route se fait par inondation : un paquet de recherche est diffus de proche en proche jusqu
la destination. Au fur et mesure, les identifiants des nuds traverss sont ajouts dans le
paquet de recherche de route. Quand elle reoit ce paquet, la destination sait donc dj quel
chemin il a emprunt, et obtient ainsi (en linversant) la route pour retourner la source. A la
rception, les paquets de recherche ayant suivi des chemins diffrents, la destination rpond
sur les chemins inverses, et la source aura ainsi finalement plusieurs chemins valides pour
latteindre.
6 Etude dtaille du protocole AODV

AODV (Ad hoc On demand Distance Vector) est un protocole de routage conu par Charles E.
Perkins et Elizabeth M. Royer et spcifi dans le RFC 3561 [11]. C'est un protocole bas sur
le principe des vecteurs de distance et appartient la famille des protocoles ractifs. Il
reprsente essentiellement une amlioration de l'algorithme proactif DSDV mais rduit
l'overhead (nombre de diffusions de messages) en ne calculant les routes que sur demande
(AODV). Ce protocole utilise les deux mcanismes "dcouverte de route" et "maintenance
de route", en plus du routage " nud par nud " et construit les routes par l'emploi d'un
cycle de requte "route request/route reply" [20].
AODV utilise le principe des numros de squence afin de maintenir la consistance des
informations de routage. A cause de la mobilit des nuds dans les rseaux mobiles ad hoc,
les routes changent frquemment ce qui fait que les routes maintenues par certains nuds,
deviennent invalides. Les numros de squence permettent d'utiliser les routes les plus
nouvelles ou autrement dit les plus fraches (fresh routes) [17].
6.1 Table de routage et paquets de contrle

AODV maintient les chemins dune faon distribue en gardant une table de routage, au
niveau de chaque nud de transit appartenant au chemin cherch. Une entre de la table de
routage contient essentiellement [17]:
Ladresse IP de la destination.
Le nud suivant.
La distance en nombre de nud (i.e. le nombre de nud ncessaire pour atteindre la
destination).
Le numro de squence destination qui garantit quaucune boucle ne peut se former.
Liste des voisins actifs (origine ou relais dau moins un paquet pour la destination
pendant un temps donn).
Le temps dexpiration de lentre de la table.
Un tampon de requte afin quune seule rponse soit envoye par requte.
A chaque utilisation dune entre, son temps dexpiration est remis jour (temps courant +
active route time).
Si une nouvelle route est ncessaire, ou si une route disparat, la mise jour de ces tables
s'effectue par l'change de trois types de messages entre les nuds [17] :
RREQ (Route Request): Message de demande de route ;
RREP (Route Reply): Message de rponse un RREQ ;
RERR (Route Error): Message qui signale la perte d'une route.
Le format des paquets est donn ci-dessous:
28
RREQ: contient essentiellement les champs suivants [11] :
Type J |R |G | D |U Reserved Hop Count

RREQ ID
Destination IP Address
Destination Sequence Number
Originator IP Address
Originator Sequence Number
Tab. 2.2 : Format du message RREQ.
Type (8 bits): ce champ indique le type de paquet, dans ce cas il prend la valeur 1.
Flags (drapeaux) (5 bits): ce champ contient cinq flags (J, R, G, D, U) tel que ;
J (Join flag) et R (Repair flag) sont rserv pour le multicast ;
G (Gratuitous RREP flag) indique si un message RREP spcifique doit tre envoy la
destination dans le cas o un nud intermdiaire possde un chemin la
destination.
D (Destination only flag) ce drapeau indique si seulement la destination qui doit
rpondre la requte ou pas.
U (Unknown sequence number) indique le numro de squence de la destination est
inconnu.
Rserved (11 bits): initialis la valeur 0 et ignor la rception du message.
Hop Count (8 bits): il contient le nombre de sauts parcourus par RREQ.
RREQ ID: il identifie la requte parmi les requtes envoyes par la mme source.
Destination IP Address: l'adresse IP de destination pour laquelle une route est dsire.
Destination Squence Number: Le dernier numro de squence reu dans le pass par le
crateur pour n'importe quelle route vers la destination.
Originator IP Adress: l'adresse IP de la source de la requte.
Originator Sequence Number: Le nombre de squence courant de la source contenue dans
la table de routage de ce nud s.
RREP: contient essentiellement les champs suivants [11] :
Type R|A Reserved Prefix Sz Hop Count

Lifetime
Tab. 2.3 : Format du message RREP.
Type (8 bits): ce champ indique le type de paquet, dans ce cas il prend la valeur 2.
Flags (drapeaux) (2 bits): ce champ contient deux flags ;
R (Repair flag) : utilis pour le multicast.
A (Acknowledgment required): indique si la source doit envoyer un acquittement pour le
message RREP.
Reserved (9 bits): initialis la valeur 0 et ignor la rception du message.
29
Prfix Sz(5 bits): si la valeur de ce champs est diffrente de zro, ce dernier indique que
le nud prochain peut tre utilis pour chaque nud demandant cette destination et
qui possde la mme valeur de Prefix Sz.
Hop Count (8 bits): il contient le nombre de sauts entre la source jusqu' la destination.
Destination IP Address : ladresse IP de la destination du paquet RREQ.
Destination Sequence Number : le numro de squence de la destination associ cette
route.
Originator IP Adress : ladresse IP du nud qui cre la requte.
Lifetime : le temps pour lequel chaque nud qui reoit RREP considre que la route est
valide.
RERR: Un message d'erreur de route contient essentiellement les champs suivants [11]:
Type N Reserved DestCount

Unreachable Destination IP Address (1)
Unreachable Destination Sequence Number (1)
Tab. 2.4 : Format du message RERR.
Type (8 bits): la valeur de ce champ prend 3 dans le message RRER.

Flag (1 bits): il contient un drapeau (N: No delete flag), celui-ci est indicatif lorsqu'un
nud est capable de rparer le lien, et informe les nuds suivants qu'ils ne doivent pas
supprimer le chemin.
Reserved (15 bits): initialis la valeur 0 et ignor la rception du message.
DestCount (8 bits): il indique le nombre de destinations inaccessibles incluses dans ce
message. Ce champ doit tre suprieur ou gal un.
Unreachable Destination IP Address:l'adresse IP des destinations inaccessibles pour la raison
de cassure de lien.
Unreachable Destination Sequence Number : le nombre de squence de la liste des
destinations inaccessibles qui se trouve dans le champ Unreachable Destination IP Address.
6.2 Numro de squence

L'algorithme de Bellman Ford est un algorithme qui trouve le plus court chemin entre
deux nuds. Les protocoles vecteur de distance sont en gnral sujets au problme de
boucles de routage (routing loops) et de comptage linfini (counting to infinity) de l'algorithme de
Bellman-Ford qu'ils utilisent. Certaines parties du rseau se trouvent isoles du reste, et les
nuds composants vont croire qu'ils peuvent atteindre les nuds desquels ils sont coups en
passant par leurs voisins. Il s'en suit un phnomne de bouclage dans lequel les nuds
injoignables se voient attribuer des distances de plus en plus grandes.
Dans le cas d'AODV, ces problmes sont rsolus par l'utilisation de numros de squence
pour les messages de contrle [15].
Chaque nud possde un numro de squence. Il est le seul habilit l'incrmenter. Ce
numro personnel ne peut tre incrment que dans deux situations :
Avant d'entreprendre un processus de recherche de route par l'envoi d'un paquet
RREQ, le nud incrmente son numro.
Avant de rpondre un message RREQ par un message RREP, le numro de squence
doit tre remplac par la valeur maximale entre son numro de squence actuel et celui
contenu dans le message RREQ. Ce numro accompagne son adresse dans les messages
30
de contrle et permet aux autres de distinguer les messages importants des messages
redondants.
Le numro de squence est utilis aussi pour la mise jour de la table de routage, celle-ci ne
s'effectue que si les conditions suivantes sont observes:
Le numro de squence du paquet de contrle est strictement suprieur au numro de
squence prsent dans la table.
Les numros de squence (de la table et du paquet) sont gaux mais, la distance en sauts
du paquet plus 1 est infrieure la distance actuelle dans la table de routage.
Le numro de squence pour cette destination est inconnu.
Cette faon de procder garantit la cration de routes sans boucles [17].
6.3 Principe de fonctionnement

Deux tapes sont observes [17] ; la premire est la dcouverte dune route, et la deuxime
est la maintenance des routes :
6.3.1 Dcouverte d'une route

Un nud diffuse une requte de route (RREQ), dans le cas o il aurait besoin de
connatre une route vers une certaine destination et qu'une telle route n'est pas disponible
(Fig 2.5).Cela peut arriver si la destination n'est pas connue au pralable, ou si le chemin
existant vers la destination a expir sa dure de vie ou il est devenu dfaillant (i.e. la mtrique
qui lui est associe est infinie). Le champ numro de squence destination du paquet RREQ,
contient la dernire valeur connue du numro de squence, associ au nud destination.
Cette valeur est recopie de la table de routage. Si le numro de squence n'est pas connu,
la valeur nulle sera prise par dfaut. Le numro de squence source du paquet RREQ
contient la valeur du numro de squence du nud source. Aprs la diffusion du RREQ, la
source attend le paquet rponse de route (RREP). Si ce dernier n'est pas reu durant une
certaine priode (appele RREP_WAIT_TIME), la source peut rediffuser une nouvelle
requte RREQ.
Quand un nud de transit (intermdiaire) envoie le paquet de la requte un voisin, il
sauvegarde aussi l'identificateur du nud partir duquel la premire copie de la requte est
reue.
Fig. 2.5 : La propagation du paquet RREQ.
31
Cette information est utilise pour construire le chemin inverse (Fig 2.6), qui sera travers
par le paquet rponse de route de manire unicast (cela veut dire qu'AODV supporte
seulement les liens symtriques). Puisque le paquet RREP va tre envoy la source, les
nuds appartenant au chemin de retour vont modifier leurs tables de routage suivant le
chemin contenu dans le paquet de rponse (temps d'expiration, numro de squence et
prochain saut).
Afin de limiter le cot dans le rseau, AODV propose d'tendre la recherche
progressivement. Initialement, la requte est diffuse un nombre de sauts limit. Si la source
ne reoit aucune rponse aprs un dlai d'attente dtermin, elle retransmet un autre message
de recherche en augmentant le nombre maximum de sauts. En cas de non rponse, cette
procdure est rpte un nombre maximum de fois avant de dclarer que cette destination est
injoignable. A chaque nouvelle diffusion, le champ Broadcast ID du paquet RREQ est
incrment pour identifier une requte de route particulire associe une adresse source.
Fig. 2.6 : Le chemin pris par RREP.
Si la requte RREQ est rediffuse un certain nombre de fois (RREQ_RETRIES) sans la

rception de rponse, un message d'erreur est dlivr l'application .La destination renvoie
un message RREP, ce message peut donc tre achemin vers la source. Chaque nud
travers incrmentera le nombre de sauts. Et ajoutera une entre sa table pour la
destination. Une rponse adquate peut aussi tre donne par un nud situ entre la source
et la destination. Dans ce cas l'obtention de routes bidirectionnelles est nanmoins possible
grce au drapeau "Gratuitous RREP". Le nud intermdiaire enverra alors en plus un RREP
vers la destination. Les nuds entre le nud intermdiaire et la destination ajouteront donc
leur table une entre vers la source du RREQ. Cette disposition permettra la destination
d'envoyer directement des paquets la source sans devoir procder la recherche d'une
route. C'est utile lors de l'tablissement de communications TCP pour l'envoi du premier
ACK [20].
6.3.2 Maintenance des routes

Afin de maintenir des routes consistantes, une transmission priodique du message
"HELLO " (qui est un RREP avec un TTL (Time To Live) de 1) est effectue. Si trois
messages " HELLO " ne sont pas reus conscutivement partir d'un nud voisin, le lien en
question est considr dfaillant. Les dfaillances des liens sont, gnralement, dues la
mobilit du rseau ad hoc. Les mouvements des nuds qui ne participent pas dans le chemin
actif, n'affectent pas la consistance des donnes de routage. Quand un lien, reliant un nud p
avec le nud qui le suit dans le chemin de routage, devient dfaillant, le nud p diffuse un
32
paquet UNSOLICITED RREP, avec une valeur de numro de squence gale l'ancienne
valeur du paquet RREP incrmente d'une, et une valeur infinie de la distance. Le paquet
UNSOLICITED RREP est diffus aux voisins actifs, jusqu' ce qu'il arrive la source. Une
fois le paquet est reu, la source peut initier le processus de la dcouverte de routes.
AODV maintient les adresses des voisins travers lesquels les paquets destins un
certain nud arrivent. Un voisin est considr actif, pour une destination donne, s'il dlivre
au moins un paquet de donnes sans dpasser une certaine priode (appele active timeout
period). Une entre de la table du routage est active, si elle est utilise par un voisin actif. Le
chemin reliant la source et la destination en passant par les entres actives des tables de
routage, est dit un chemin actif. Dans le cas de dfaillances de liens, toutes les entres des
tables de routage participantes dans le chemin actif et qui sont concernes par la dfaillance
sont supprimes. Cela est accompli par la diffusion d'un message d'erreur entre les nuds
actifs [18].
La maintenance peut tre rsume dans les trois points suivants :
Des messages HELLO priodiques pour dtecter les coupures de liens.
Si la source se dplace, la procdure de dtermination de route peut tre riniti.
Si un nud intermdiaire ou la destination se dplacent, un RREP spcial est mis au
nud source (reconstruisant la route au passage).
6.3.3 Gestion de la connectivit locale

Lorsqu'un nud reoit un paquet en Broadcast, il met jour ses informations de connectivit
locale pour s'assurer qu'elles incluent ce voisin.
Si aucun paquet n'est mis aux voisins actifs pendant le dernier hello_interval, un nud va
envoyer un HELLO (RREP non sollicit) contenant :
son identit.
son numro de squence (non modifi pour les HELLO).
time to live de 1 pour ne pas tre retransmis.
liste des nuds pour lesquels il a reu un HELLO [18].
6.4 AODV : Avantages et inconvnients

Des tudes comparatives montrent que certains protocoles sont plus performants que
d'autres selon les caractristiques du rseau. Ces tudes ont montr que le protocole AODV
semble convenir des rseaux forte mobilit et semble performant dans les rseaux de
faible densit [16].
Parmi les inconvnients du protocole de routage AODV, est le fait qu'il n'assure pas
l'utilisation du meilleur chemin existant entre la source et la destination. Cependant, des
valuations de performances rcentes ont montr qu'il n'y a pas de grandes diffrences (en
terme d'optimisation) entre les chemins utiliss par le protocole AODV et ceux utiliss par les
protocoles bass sur les algorithmes de recherche des plus courts chemins.
L'avantage de ce protocole est qu'il ne prsente pas de boucle de routage et vite le
problme du "comptage l'infini" de Bellman Ford. En effet, ce dernier ne possde pas de
mcanisme prcis qui peut dterminer quand est ce que le rseau doit arrter l'incrmentation
de la distance qui correspond une destination donne, ce qui offre une convergence rapide
quand la topologie du rseau ad hoc change [8].
Un autre avantage de ce protocole est sa simplicit, titre d'exemple, le draft de DSR
mesure 111 pages, le RFC de OLSR fait 75 pages, alors que celui d'AODV a une taille de 37
pages. Ensuite son anciennet et sa maturit, AODV existe depuis longtemps et beaucoup de
33
travaux ont dj t raliss son propos et il a fait l'objet de simulations comparatives

dtailles. Ce sont des critres assez subjectifs qui conduisent au choix dAODV [20].
7 Autres protocoles
De nombreux autres protocoles de routage ont t proposs pour les rseaux mobiles ad
hoc. Dans la catgorie des protocoles hirarchique on peut citer Cluster- Head Gateway Switcher
Routing (CGSR) prsent dans [21]. Certains autres protocoles ncessitent lemploi de
matriels externes, Par exemple Temporaly-Ordered Routing Algorithm (TORA) [22] a besoin que
les mobiles soient synchroniss. Dautres utilisent le systme GPS pour estimer la direction
gographique de la destination et ne faire intervenir quune sous-partie du rseau dans la
phase de construction des routes. Alors que beaucoup de protocoles cherchent minimiser le
nombre de sauts (minimum shortest path), certains protocoles enfin sattachent prendre
dautres critres en considration. ABR [23] (Associativity-Based Routing) par exemple privilgie
les liens les plus stables (mobiles qui restent longtemps dans le voisinage les uns des autres).
SSR [24] (Signal Stability Routing) travaille partir des informations de niveau de signal et
cherche maximiser la dure de vie du rseau en agissant sur la puissance dmission de
chaque mobile sparment [15].
Conclusion
Si le routage dans son contexte gnral est une tche complexe, les caractristiques des
MANETs rendent la conception dun protocole de routage efficace plus complexe.
De nombreux protocoles de routage ont t dvelopps pour les MANETs faisant face aux
contraintes spcifiques de ce type de rseaux. Ces protocoles peuvent tre classs selon
plusieurs critres : leur architecture, les algorithmes utiliss, les politiques de routages, etc.
Ltablissement des routes par ces protocoles se fait seulement suivant le critre classique :
le plus court chemin ; il suffit dassurer la connectivit entre une source et une destination.
Cependant ce critre nest pas du tout suffisant pour des applications comme le multimdia
par exemple qui exigent des garanties particulires (la bande passante, le dlaietc.). En effet,
il est ncessaire de penser dautres solution de routage optimales en termes de certains
critres si nous voulons dployer de telles application dans un environnement ad hoc, on
parle alors de la notion du routage avec qualit de service.
Dans ce chapitre nous avons vu le concept de routage dans les rseaux mobiles ad hoc, les
contraintes, une taxonomie des diffrents protocoles existants, ensuite nous avons dcrit les
principaux protocoles proposs pour les MANETs, en fin nous avons dtaill le
fonctionnement du protocole AODV pour tre lobjet de notre tude. Le choix du protocole
AODV est justifi par les avantages cits dans la section 6.4.
Dans le chapitre suivant nous allons tudier la notion de qualit de service, particulirement
le routage avec qualit de service, dans le but de faire une extension du protocole AODV
pour garantir des exigences de la qualit de service.
34
Chapitre III
Qualit de service dans les rseaux mobiles

ad hoc
Chapitre III QoS dans les rseaux mobiles ad hoc
Qualit de Service dans les rseaux mobiles ad hoc
1 Introduction
La performance dun rseau est un lment fondamental et ncessaire pour une utilisation
efficace dapplications, notamment les applications qui exigent une qualit de service (QoS,
Quality of Service) telles que la tlphonie, la vido la demande, la vido confrence ou encore
les applications temps rels. Le dploiement de telles applications dans les MANETs
reprsente de nombreux intrts. Cependant on doit faire face plusieurs dfis et difficults,
et trouver des solutions fiables qui aident lintgration de la qualit de service dans ce genre
de rseaux.
Comme nous lavons vu dans le chapitre 2, le groupe MANET de lIETF a propos
plusieurs protocoles de routage pour les rseaux mobiles ad hoc. Ceux ci fonctionnent en
mode best effort c'est--dire : au mieux. Cependant, ils ne permettent pas de garantir une qualit
de service.
Gnralement, la recherche sur la qualit de service dans les rseaux mobiles ad hoc touche
plusieurs domaines ; Les modles de QoS, la diffrentiation au niveau de la couche MAC
(Medium Access Control), les protocoles de signalisation et Le routage avec QoS.
Dans ce chapitre, on sintressera aux solutions de la QoS dans les MANETs, plus
particulirement au routage avec QoS, pour ce faire nous prsentons dabord les principales
notions de qualit de service, la dfinition, les mtriques, les solutions et le problme de
routage avec QoS dans les MANETs.
2 Dfinition de la Qualit de service

La recommandation E.800 du CCITT (Consultative Committee for International Telegraph and
Telephone) dfinit la qualit de service (QoS pour Quality of Service ou QdS pour (Qualit de
Service) comme : leffet gnral de la performance dun service qui dtermine le degr de
satisfaction dun utilisateur du service . Cette dfinition reflte la perception de la qualit de
service de point de vue dun utilisateur [19].
Dans le RFC 2386 [25], la QoS est dfinit comme un ensemble de besoins assurer par le
rseau pour le transport dun trafic dune source une destination. Ces besoins peuvent tre
traduits en un ensemble dattributs pr-spcifis et mesurables en terme de :
Dlai de bout en bout,
Variance de dlai (gigue),
Bande passante,
Pertes de paquets.
3 Les mtriques de la qualit de service

Les principaux aspects connus de la qualit de service sont : la bande passante, le dlai de
bout en bout, la gigue (variation du dlai), et les pertes de paquets (souvent exprime en
termes de taux derreurs).
36
Les mtriques de QoS peuvent tre additives, concaves ou multiplicatives ;

h
Une mtrique additive Am est dfinie comme Li ( m ) o Li est la valeur de la
i=0
mtrique m sur le lien Li , Li P .h reprsente la longueur du chemin P .

Une mtrique concave dfinit la valeur minimale sur un chemin P et reprsent
comme suit : Cm = min( Li (m)) , Li (m) P .
Une mtrique multiplicative reprsente le produit des valeurs des mtriques de QoS, elle
est dfinie comme le produit des Li (m) avec i allant de 1 h, Li(m) P [17].
La bande passante est une mtrique concave, alors que le dlai et la gigue sont des
mtriques additives. La disponibilit dun lien, base sur des critres comme la probabilit de
perte du lien quant elle est une mtrique multiplicative [7].
3.1 La bande passante
La bande passante reprsente la source de transmission quoccupe ou reoit un flot. La
gestion de la bande passante est un lment important pour la garantie de la qualit de service
[17].
3.2 Dlai de bout en bout
Le terme dlai englobe en ralit trois aspects temporels diffrents :
1. le dlai de propagation, dtermin par la distance physique qui spare la source de la
destination.
2. le dlai dattente et de traitement des paquets lintrieur des files dattente,
dtermin par la charge du rseau, ainsi que les politiques de traitement de
linformation dans les routeurs pour obtenir une fluidit maximale de lcoulement
de linformation.
3. le dlai de transmission dpendant de la taille des flots. Ce paramtre est aussi
troitement li lutilisation du rseau et au partage de la bande passante disponible.
Garantir le dlai, implique la ncessit de mettre en uvre des mcanismes permettant de
grer au mieux lacheminement de linformation vers la destination en un temps minimal,
tenant compte des trois natures de dlais prcdemment cits [19].
3.3 La gigue : (variation du dlai)
La gigue correspond la variation du dlai de transmission de bout en bout entre les
diffrents paquets dun flot travers un rseau. La gigue est due principalement aux dlais de
traitement variables dans les nuds du rseau. Ce paramtre nuit automatiquement la
qualit de service demande.
3.4 La perte de paquets
Elle se produit lorsqu'il y a des erreurs d'intgrit sur les donnes. La perte de paquets se
produit principalement lorsque l'intensit du trafic sur les liens de sorties devient suprieure
leur capacit d'coulement [20].
37
4 Le besoin en QoS des dapplications

Au dbut de lapparition des rseaux mobiles ad hoc, lobjectif t dassurer la
communication entre les nuds on utilisant le service best effort . Mais pour des applications
telles que le multimdias, tlphonie, jeux, applications critiques, communications dans un
champ de bataille, etc. ce service nest pas suffisant. Ces applications sont exigeantes en
terme de certains critres (bande passante, dlai.. etc.).
Suivant le type de lapplication, les besoins de QoS sont diffrents. Par exemple, pour les
applications temps rel, comme la voix et la vido, le dlai de bout en bout dun paquet doit
tre born, autrement le paquet est inutile. Les applications non temps rel, comme le
transfert de fichiers ou la messagerie, quant elles se focalisent sur la fiabilit des
communications [7].
La figure 3.1 montre un exemple des besoins de quelques applications de la qualit de
service particulirement des deux mtriques : bande passante et dlai de bout en bout [19].
Fig.3.1 : exemple de besoins de QoS.
5 Exemple de besoins de QoS : la voix sur IP (VoIP)

La VoIP (Voice over Internet Protocol) est un ensemble de technologies qui permettent le
transport de la voix numrise sur les rseaux commutation de paquets au lieu des rseaux
commutation de circuits classique (PSTN, Public Switched Telephony Network). La VoIP sert
surtout la ToIP (Telephony over IP).
La finalit du travail effectu dans ce mmoire est de faire une extension du protocole
AODV en lui rend sensible une mtrique de QoS on amliorant les performances de la
voix sur IP dans les rseaux mobiles ad hoc. En effet il est ncessaire de connatre les besoins
de QoS de cette application. Pour cela nous traitons dans ce qui suit la voix sur IP, et ses
diffrentes caractristiques et paramtres.
5.1 Les paramtres de la voix sur IP

La problmatique de qualit de la voix sur IP est particulire car la voix attend de son
transporteur autre chose que les donnes. La transmission de donnes classique (fichiers,
messages, transactions ) ne supporte aucune perte en ligne sous peine de graves
consquences pour linterprtation et lutilisation de ces donnes, mais elle supporte en
revanche une drive importante en terme de dure dacheminement.
Le comportement attendu pour la voix est exactement inverse : 1% ou 2% de perte de
donnes de voix en ligne ne sont pas trop gnants pour la qualit du service de VoIP, mais en
38
revanche une variation frquente de 100 ms sur le dlai de transit est catastrophique et rend le
service inutilisable [48].
Les principaux paramtres influents en VoIP sont, les chantillonnages (codecs), le dlai de
bout en bout, la gigue et les pertes de donnes.
5.1.1 Les diffrents chantillonnages

Le paramtre dchantillonnage ou codec (pour compression / dcompression) est
structurant en VoIP. Le codec dtermine quelle vitesse la voix est chantillonne et
dimensionne par la mme le flux de donnes numriques que va gnrer la transformation
dun chantillon temporel de voix analogique. Les codecs sont rpertoris par leur nom
lITU(International Telecommunication Union). Les codecs les plus utiliss et leurs vitesses
dchantillonnage sont les suivants :
codec Vitesse dchantillonnage

G.711 64 kbps
G.726 32 kbps
G.726 24 kbps
G.728 16 kbps
G.729 8 kbps
G.723.1 MPMLQ 6.3 kbps
G.723.1 ACELP 5.3 kbps
Tab 3.1 : les principaux codecs et leurs Vitesses dchantillonnage.
5.1.2 Le dlai de bout en bout

Le dlai de bout en bout (ou end-to-end Delay) est un des paramtres critiques influenant
fortement la QoS dun service de voix sur IP. Cest le temps que va mettre en moyenne un
paquet IP contenant un chantillon de voix pour traverser linfrastructure entre deux
interlocuteurs [48].
Les recommandations G.114 et G.131 de lITU-T stipulent que la valeur recommande
pour le dlai de transit de la voix de bout en bout ne doit pas dpasser 150ms pour un codec
G711, pour un autre codec cette valeur nest pas la mme (tableau3.2).
Dlai de bout en bout Effet sur la qualit perue

<100-150ms dlai non dtectable
150-400ms qualit acceptable
Plus de 400 Dlai inacceptable ; conversation non comprhensible
Tab. 3.2 : les seuils du dlai pour un codec G711.
5.1.3 La gigue
La variation du dlai(ou gigue) est la consquence du fait que tous les paquets contenant
des chantillons de voix ne vont pas traverser le rseau la mme vitesse. Cela cre une
dformation de la voix ou un hachage.
39
La gigue est indpendante du dlai de transit. Le dlai peut tre court et la gigue
importante ou inversement. La gigue est une consquence de congestions passagres sur le
rseau, ce dernier ne pouvant plus transporter les donnes de manire constante dans le
temps. La valeur de la gigue va de quelques ms quelques dizaines de ms.
5.1.4 La perte de paquets

Une perte de donnes rgulire mais faible est moins gnante en voix sur IP que des pics
de perte de paquets espacs mais levs. En effet lcoute humaine shabituera une qualit
moyenne mais constante et en revanche supportera peu de soudaines dgradations de la QoS.
Le taux de perte en VoIP est en gnrale de quelques pourcents des diximes de pourcent.
Le tableau 3.3 prsente les seuils de valeurs pour les paramtres critiques et les
consquences constates pour la qualit de service de la VoIP en codec G.711 64 kbps [48]:
qualit
Bonne Moyenne Mauvaise
mtrique
Dlai de bout en bout D < 150 ms 150 ms < D < 400 ms 400 ms < D
Gigue G < 20 ms 20 ms < G < 50 ms 50 ms < G
Perte de paquets P < 1% 1% < P < 3% 3% < P
Tab.3.3 : les exigences de QoS pour la VoIP.
6 La QoS dans Les rseaux mobiles ad hoc

La qualit de service a t largement tudie dans les rseaux filaires. Le rseau ATM
(Asynchronous Transfert Mode) a considr le support de la QoS pour les trafics en plusieurs
classes [7]. Des solutions ont t proposes par lIETF pour amliorer le rseau Internet afin
de fournir la QoS aux communications multimdia. Les groupes de lIETF se sont penchs
sur deux ides [19] : IntServ [27] (Integrated Services), et DiffServ [28] (Differentiated Services).
Malheureusement aucune de ces solutions ne peuvent tre utilise directement dans les
MANETs [30]. En effet il est trs difficile de garantir une quelconque qualit de service une
application dans un rseau mobile ad hoc. Car, il faut prendre en considration les spcificits
de ces rseaux, savoir : la bande passante limite, le changement dynamique de la topologie
en fonction du temps, le manque dinformation complte sur ltat du rseau, ainsi que
labsence dune administration centralise ce qui implique une gestion distribue du trafic
ncessaire au fonctionnement du rseau.
En outre, la communication entre les stations mobiles tant sans fil, la qualit du lien sans
fil reste peu fiable, et susceptible des variations suivant la configuration et ltat du rseau
[7]. Donc assurer une QoS dans les MANETs revient fournir une fonctionnalit complexe
dans un environnement trs dynamique o les ressources sont rares [30].
Dans ce contexte, plusieurs solutions pour la QoS dans les MANETs ont t proposes
par la communaut scientifique pour pallier aux problmes lis aux contraintes spcifiques
des rseaux mobiles ad hoc. Dans ce qui suit, nous allons prsenter les solutions les plus
permanentes.
7 Solutions de QoS dans les MANETs

Les solutions de QoS pour les rseaux mobiles ad hoc peuvent tre classifies en quatre
catgories (figure 3.2) [30]: Les modles de QoS, la diffrentiation au niveau de la couche
MAC (Medium Access Control), les protocoles de signalisation, et le routage avec QoS.
40
Solutions de QoS dans les MANETs
Protocoles de Routage Diffrentiation Modles

signalisation avec QoS Couche MAC de QoS
Approches
Interviennent une couche ou sous-couche Inter couche
du modle de rfrence OSI CROSS LAYER
Fig.3.2 - solutions de QoS pour les rseaux ad hoc.
En ralit, ces solutions ne sont pas indpendantes. En effet, pour construire un bon
modle de qualit de service, les autres composants de QoS (routage QoS, protocole de
signalisation, protocole MAC avec QoS) doivent cooprer pour atteindre cet objectif. En
outre, Un protocole MAC QoS est un composant essentiel de la qualit de service dans les
MANET, toutes les couches suprieures (routage QoS et protocole de signalisation)
dpendent du protocole MAC avec QoS [32].
7.1 Modles de qualit de service

Un modle de qualit de service dfinit quels types de service peuvent tre fournis dans un
rseau et certains mcanismes utiliss afin d'offrir ces services (quelles fonctionnalits doit
fournir le protocole de routage, quelle est l'architecture des nuds, etc.) [32]. Les modles les
plus connus dans le monde filaire sont :
IntServ (Integrated services) : spcifi dans le RFC 1633 [27], ce modle propose une
architecture base de rservation de ressources pour chaque flot. Cette dernire
seffectue au moyen du protocole RSVP (Resource Reservation Setup Protocol), Cependant,
IntServ nest pas propice des rseaux de grande envergure [19].
DiffServ (Differentiated Services) : spcifi dans le RFC 2475[28], ce modle fonde son
concept sur une gestion de trafic par classe, sur des mthodes de conditionnement du
trafic lentre du rseau et sur le marquage de celui-ci en fonction de son appartenance
une classe, Trois principaux services de DiffServ sont mis en uvre : le service Best-
Effort pour les paquets traiter au-mieux comme le fait Internet actuellement ; le
service Assured Forwarding pour des classes priorit plus grande enfin le service
Expedited Forwarding pour les classes les plus prioritaires [19].
FQMM (Flexible Quality of service Model for Mobile ad hoc networks)
FQMM est un modle de QoS propos pour les MANETs. Les concepteurs du modle
FQMM prennent en compte le fait que les rseaux ad hoc pourraient, terme tre connects
des rseaux filaires de type Internet. Il apparat ds lors ncessaire d'offrir un mcanisme de
qualit de service suffisamment proche des protocoles filaires afin de s'interfacer avec ces
derniers. Le modle FQMM se situe entre les deux modles IntServ et DiffServ, il dfinit
plusieurs classes de service dont la plus haute permet chaque flux de spcifier les contraintes
qui lui sont propres.
FQMM dfinit trois types de nuds : les nuds d'entre (metteurs), les nuds
intermdiaires et les nuds de sortie (rcepteurs). Compte tenu du fait que dans un rseau ad
hoc, chaque nud assure la fonction de routeur, chaque mobile joue diffrents rles pour
diffrents flux. Le conditionnement du trafic (lissage, marquage, etc.) est la charge des
41
metteurs. FQMM requiert l'utilisation d'un protocole de routage capable d'offrir une certaine
QoS, c'est dire capable de rechercher des routes satisfaisant certaines contraintes [32].
7.2 Solutions au niveau de la couche MAC

La plupart des protocoles proposs pour la couche MAC dans les rseaux mobiles ad hoc
s'intressent aux problmes d'accs au mdium ainsi qu' la fiabilit des communications.
Trs peu s'attaquent aux problmes de rservation de trafic et de garanties de QoS.
Rcemment, des schmas de diffrenciation de service au niveau MAC ont t proposs.
7.2.1 Diffrenciation de services pour IEEE 802.11

Le principe est de doter le protocole IEEE 802.11 dun mcanisme de priorits entre les
trames afin de concevoir des mcanismes de diffrenciation de services efficaces. Pour ce
faire, les auteurs de [29] proposent dadapter certains paramtres de la fonction de
coordination distribue (DCF) du protocole 802.11 selon les priorits des paquets. Ces
paramtres peuvent tre adapts dynamiquement afin doffrir un mcanisme de priorits au
protocole 802.11 :
Lorsqu'une collision survient, les dlais avant retransmission sont allongs alatoirement. Il
est possible d'incrmenter ces dlais diffremment selon le niveau de priorit.
Il est possible d'utiliser diffrentes valeurs du dlai de silence avant une transmission
(DIFS) selon le niveau de priorit de la transmission.
Enfin, il est possible de limiter la longueur des trames selon le niveau de priorit, les trames
peu prioritaires occupant le canal moins longtemps [32].
7.2.2 MACA/PR (Multihop Access Collision Avoidance with Piggyback Reservation)

Ce protocole propose de fournir des garanties de bande passante pour les applications
temps rel via une rservation. Il permet d'tablir des connexions temps rel un saut
seulement. Il utilise un dialogue RTS/CTS avec acquittement, et diffrencie la politique
d'accs au mdium selon la nature des flux. Pour le trafic prioritaire, une seule demande
d'autorisation transmettre (RTS/CTS) au dbut du flux est utilise. Dans chaque paquet,
des informations sur l'ordonnancement du paquet suivant sont incluses pour empcher les
voisins d'entrer en collision avec les prochains paquets [20].
7.2.3 IEEE 802.11e

Actuellement en cours dvaluation, la spcification du draft IEEE 802.11e [31] propose le
support de la QoS dans les rseaux sans fil avec une nouvelle fonction de contrle EDCA
(Enhanced Distributed Channel Access), considre comme la nouvelle version de la fonction
DCF. EDCA introduit quatre catgories de trafics (TC). Les priorits sont contrles par les
stations en modifiant le schma daccs de base (DCF). 802 .11e propose aussi une fonction
de coordination hybride (HCF) Plus flexible que la fonction PCF, HCF est utilise par les
points daccs pendant la priode daccs contrle (CAP), qui peut commencer nimporte
quel moment durant la superframe. Autrement dit, a lui permet davoir accs au mdium
pour faire passer un trafic ayant des contraintes de QoS [7].
7.3 Protocoles de signalisation

Le but des protocoles de signalisation est de fournir un moyen de propager des
informations de contrle travers un rseau. Les informations transmises peuvent tre de
42
diffrentes natures. Il peut sagir dinformations topologiques, de demandes de recherche de

routes satisfaisant certaines contraintes ou encore de rapports sur ltat du rseau et la
disponibilit des ressources. Concevoir un protocole de signalisation consiste dfinir les
donnes changer afin de raliser une tache particulire ainsi que la manire de les changer
[32]. La signalisation permet de rserver et de mettre jour les ressources, d'initialiser et
d'arrter le trafic ainsi que de rengocier le profil du trafic. Elle peut s'effectuer l'intrieur
des paquets de donnes (signalisation in band) ou grce des paquets explicites de contrle
(signalisation out band) [20].
INSIGNIA
INSIGNIA est un protocole de signalisation in-band (la signalisation est incluse dans les
enttes des paquets de donnes) permettant deffectuer des rservations de bande passante
dans les rseaux ad hoc. INSIGNIA offre des garanties sur la base dune granularit par flot
aux applications adaptatives capables de modifier leur comportement en fonction de la
quantit de bande passante qui leur est alloue. Chaque application spcifie deux niveaux de
qualit de service.
Le niveau de base permet de spcifier la bande passante minimale ncessaire au trafic et le
niveau amlior, le dbit optimal atteindre lorsque les ressources sont disponibles. Ce
protocole a t conu pour ragir rapidement aux changements de topologie. INSIGNIA
nest pas li un protocole de routage particulier [32].
7.4 Routage avec QoS

Dans le RFC 2386 [25], le routage avec QoS est dfini comme tant : Un mcanisme de
routage dans lequel les chemins sont dtermins en fonction des connaissances sur la
disponibilit des ressources du rseau ainsi que l'exigence de qualit de service de flux . En
dautres termes lauteur de [33] le dfinit comme tant : un processus dtablissement et de
maintenance de routes optimales satisfaisant un certain critre sur la qualit de la transmission
de donnes .
Les algorithmes de routage traditionnels ont t proposs pour router les donnes sans
tenir compte des contraintes spcifiques ou des demandes des utilisateurs. Ainsi, ils sont
inadapts aux applications qui ncessitent le support de la qualit de service.
Le routage avec QoS est un lment cl pour raliser une architecture de QoS pour les
rseaux mobiles ad hoc. Le protocole de routage QoS peut informer une source sur la bande
passante et la disponibilit (en termes de QoS) de la destination. Cette connaissance va
permettre l'tablissement de connections avec qualit de service.
Les exemples illustrs dans la figure 3.3 montrent la diffrence entre un protocole classique
et un protocole avec QoS ; dans le premier, la route choisie est celle passe par les nuds B,
C et F est au lieu du plus court chemin pass par D, E car elle satisfait le besoin de la QoS de
la bande passante <Bp> demande. Dans le deuxime la route choisie est B E F car elle
satisfait le besoin du dlai.
43
<5>
<4> <20> <70>
B B C
C
S <4> <5> S <25> <50>
<30>
<2> <3> <70>
<Bp> : bande passante <D> : Dlai
E F E F Besoin en QoS:D150
<3> Besoin en QoS: Bp4 <60>
<4>
D <2> Plus court chemin D <70> Plus court chemin
<40>
Chemin Chemin satisfaisant
1
D satisfaisant la QoS 2 D la QoS
Fig. 3.3 - exemples de routage avec QoS.
7.4.1 Objectifs du routage avec QoS

Le routage avec QoS cherche atteindre les trois objectifs suivants [25]:
1. Dtermination dynamique de chemins possible : le routage QoS peut dterminer parmi
de nombreux choix, un chemin rpondant aux exigences de QoS et qui est ralisable de
bout en bout.
2. Optimisation de l'utilisation des ressources : le routage QoS peut aider dans lutilisation
efficace des ressources en amliorant la capacit totale du rseau.
3. Permettre une dgradation gracieuse des performances du rseau.
7.4.2 Difficult de routage avec QoS dans les MANETs

Dans le cas du routage avec qualit de service, le but n'est pas simplement de trouver le
meilleur chemin selon un certain critre mais de trouver le meilleur chemin admissible. On
ajoute un certain nombre de contraintes sur les routes afin de dterminer leur ligibilit. Par
exemple, on peut vouloir rechercher une route disposant d'une certaine quantit de bande
passante pour un trafic vido. Toute route satisfaisant un certain critre quantitatif peut tre
qualifie de route assurant une certaine qualit de service [33].
Si lon peut considrer que cet objectif sera bientt atteint dans les rseaux locaux filaires,
les rseaux ad hoc prsentent un grand nombre de spcificits qui rendent la conception dun
tel algorithme de routage avec QoS trs difficile.
Les rseaux ad hoc sont avant tout des rseaux radio, la propagation radio dans lair est
soumise des contraintes spcifiques. Les ondes radio sont extrmement sensibles leur
environnement. Le multi hop exig par labsence dune administration de base implique une
gestion distribue de la fonction du routage et lajout dune mtrique de la qualit de service
rende le mcanisme dtablissement des routes plus compliqu. En fin les changements de
topologie dans les rseaux ad hoc exigent de recalculer les routes avec QoS, et rpondre assez
rapidement sans dgrader leur niveau de QoS. Par consquent, des ressources additionnelles
sont consommes (bande passante, batterie, etc.) [7].
7.4.3 Protocoles de routage avec QoS

Plusieurs protocoles de routage avec QoS ont t proposs par la communaut scientifique
pour les MANETs faisant face aux contraintes spcifique de ces rseaux. Ces protocoles se
distinguent par plusieurs critres ; selon les mtriques de QoS intgres, .la plupart sont des
extensions des protocoles best effort existants.
44
Le tableau 3.4 dcrit quelques protocole de routage avec QoS reprsentatifs avec les
diffrents caractristiques et techniques de fournir la qualit de service au niveau de la couche
rseau. Chacun de ces protocoles aborde les problmes de lestimation de la bande passante
et du dlai, la dcouverte de routes avec QoS, la rservation des resources, et lapproche
utilise dans la maintenance des routes, les protocoles prsents dans ce tableau sont dcrits
dans [47].
Prise en
Estimati-
Protocole Rservation compte
Mtrique mation de dcouverte Routes
de Architecture de des redondantes
de QoS dlai/bande de routes
routage ressources cassures de
passante
liens
Hirarchique Bande Proactive
CEDAR Non Oui Non Non
passante /ractive
Bande
Ticket-
based
plat passante Non ractive Oui Non Oui
/dlai
OLSR- Bande
based hirarchique Oui Proactive Non Non Non
passante
Bande
AQOR plat passante Oui ractive Oui Non Non
/dlai
Bande
ADQR plat Non ractive Oui Oui Oui
passante
Bande
TDR plat Non ractive Oui Oui Non
passante
Bande
BEQR plat Oui ractive Non Non Non
passante
Tab.3.4 : exemples de protocoles de routage avec QoS.
Conclusion
Avec les avantages quoffrent un MANET par rapport dautres types de rseaux, le
dploiement de nouvelles applications dans ces rseaux reprsente plusieurs intrts. Pour
certaines applications, telles que le multimdia, lintroduction de la QoS dans les MANETs
est devenue une ncessit.
Plusieurs solutions ont t proposes plusieurs niveaux pour atteindre cet objectif. Selon
le cas, ces solutions peuvent toucher une ou plusieurs couches du rseau, la solution qui
touche plus de niveaux est la solution la plus efficace. Dans notre tude on sintressera plus
particulirement la couche rseau, en essayant dtablir un routage efficace en termes de
certains critres de la QoS.
Ce prsent chapitre discute le concept de QoS dans les MANETs, plus particulirement le
routage avec QoS et les problmes rencontrs dans le contexte ad hoc.
Dans le prochain chapitre, nous allons tudier les dtailles de la conception dun protocole
de routage avec QoS ; il sagit dune extension du protocole AODV tudi en dtails dans le
chapitre 2 on lui rend sensible une mtrique de QoS.
45
Chapitre IV Conception
Chapitre IV
Conception
- 46 -
Conception
1 Introduction
Deux approches sont possibles pour la conception dun protocole de routage avec QoS :
Approche rvolutionnaire qui consiste concevoir un nouveau protocole avec de
nouvelles fonctionnalits.
Approche volutionnaire qui consiste faire des extensions des protocoles best effort
existants ou dapporter des amliorations un protocole de routage avec QoS en
ajoutant dautres mtriques par exemple.
Dans le cadre de cette tude nous avons choisi cette dernire pour deux raisons ; la
premire quil est plus efficace et facile et encore moins coteux damliorer un travail
existant qu refaire un autre travail de nouveau. La deuxime est quune extension dun
protocole existant est plus compatible avec la version originale ce qui permet lutilisation des
deux la fois et facilite linterconnexion des deux plate formes fonctionnant avec lancienne
et la nouvelle version du protocole. Le protocole concern par cette tude est le protocole
AODV tudi en dtail dans le chapitre II.
Comme nous lavons vu, les chemins tablis par le protocole AODV standard ne permettent
pas de garantir des critres de qualit de service. C'est pourquoi il semble important de faire
une extension de ce protocole afin d'assurer une certaine qualit de service. Lintgration de
la QoS dans AODV a pour objectifs :
Amliorer la QoS dans les rseaux mobiles ad hoc.
Introduire une mtrique plus approprie que la distance (nombre de sauts).
valuer les performances dAODV afin de tester son efficacit pour des applications
exigeantes en QoS.
Dans cette partie, nous allons discuter les spcifications dune solution qui intgre la QoS
dans le protocole AODV base sur la mtrique dlai de bout en bout. Le choix de la mtrique
dlai de bout en bout est justifi par le besoin de dploiement des applications sensible cette
mtrique dans les MANETs telles que la VoIP.
Pour ce faire, nous avons commenc dabord par la description de la mthode destimation
du dlai qui sera utilise pour aider AODV intgrer cette mtrique. Par la suite, nous
expliquons les modifications ncessaires ajoutes la structure dAODV ainsi que le nouveau
mcanisme de fonctionnement bas sur la recherche de routes assurant la mtrique dlai de
bout en bout, et une anatomie le lagent de routage AODV avec QoS travers quelques
diagrammes UML (Unified Modeling language).
2 Le routage AODV avec QoS

Plusieurs travaux ont vis amliorer les performances du protocole AODV. Nous
pouvons citer titre dexemple : AOMDV (Ad-hoc on-demand multipath distance vector) [34],
AODVM (Ad hoc On-Demand Distance Vector Multipath)[35], AODV-BR (AODV with Backup
Routes) [36], EAODV(An Extended AODV protocol) [37], et QAODV (QoS Ad Hoc On-Demand
Distance Vector)[38]. Ces travaux essayent dapporter des amliorations au protocole AODV
en termes de certains critres en utilisant des mthodes et techniques diverses.
Dans cette tude, nous nous intressons plus particulirement la mtrique dlai de bout
en bout.
- 47 -
Afin de concevoir un protocole de routage avec QoS bas sur le dlai comme mtrique,
Une mthode destimation du dlai est indispensable, pour cela, nous allons dabord effectuer
une tude dune mthode destimation du dlai. La mthode adopte dans cette tude est
base sur le travail de C. Sarr dans [42].
2.1 Estimation du dlai dans les MANETs

La mthode la plus classique destimer le dlai consiste calculer la diffrence entre le
temps denvoi et le temps de rception dun paquet donn. Cette mthode nest pas prcise
car, elle est base sur lhypothse de synchronisation des units mobiles, ce qui est difficile
assurer dans un rseau ad hoc. En effet, dautres travaux sont effectus, Une chronologie de
ces travaux est prsente dans [42]. La plupart de ces travaux essayant destimer le dlai et qui
se basent sur la modlisation de la fonction DCF de 802.11 faite par Bianchi [44], cependant,
les hypothses effectues dans le modle de Bianchi, ne sont pas ralistes et ne peuvent tre
adaptes pour le calcul du dlai dans un environnement ad hoc multi-sauts [42]. Ces
hypothses sont :
Le nombre n de stations en comptition est connu et constant ;
La probabilit de collision est constante et indpendante ;
Cette probabilit de collision est la mme pour tous les nuds ;
Les nuds sont tous dans la mme zone de communication. Il ny a donc pas de
phnomne de stations caches, ni dinterfrences.
Toutes ces hypothses fondamentales permettent de simplifier les chanes de Markov
obtenues et de les rsoudre, ce qui ne sera pas le cas dans des rseaux ad hoc multi-sauts.
2.2 Estimation du dlai un saut

Le dlai de bout en bout est une mtrique additive. Il est gal lensemble des dlais un
saut radio sur le chemin menant de la source la destination. Ce dernier peut se dcomposer
en deux parties :
Le dlai entre linstant o le paquet entre dans la file dattente du nud metteur et
linstant o il est pass la couche MAC.
Le dlai scoulant entre le moment o le paquet est reu par la couche MAC jusqu
la rception de lacquittement correspondant par le nud rcepteur, Un paquet se
trouvant une station quelconque provient de deux sources : les paquets gnrs
localement au niveau du nud considr et les paquets routs qui passent par ce
nud. Ainsi, chaque nud du rseau peut jouer le rle de nud source, routeur ou
destination.
2.2.1 Dtermination du dlai dans la file dattente

Un nud sans fil de type 802.11 peut tre vu comme un buffer qui se remplit par des
paquets entrants provenant des couches suprieures. Ainsi un seul serveur fournit le
traitement ncessaire pour ces paquets. Le systme tre modlis par une file dattente
M/M/1/K (comme indiqu dans la figure 4.1), possdant les proprits suivantes :
Larrive des clients suit une loi exponentielle de paramtre .
Le traitement des clients suit galement une loi exponentielle de paramtre .
Il y a un seul serveur pour le traitement des clients entrants.
La taille de la file est borne par la valeur K . Un client est alors perdu sil y a dj K
clients dans le systme [42].
- 48 -
Queue
Client Serveur
n(t)K
Fig. 4.1- Modlisation dun nud 802.11 par une file M/M/1/K.
Le paramtre reprsente le dbit dsir par lapplication qui est explicitement fourni lors
de la phase de requte de route avec QoS.
Le paramtre reprsente la bande passante libre autour de ce nud. Cette valeur peut
tre estime en calculant le pourcentage de temps libre TL qui sera ensuite multipli par la
capacit maximale du mdium radio Cmax suivant la formule :
= TL C m ax .....4.1
La modlisation du taux de service par la bande passante rsiduelle (libre) dun nud
permet de prendre en compte deux facteurs :
Le temps scoulant entre linstant o le mobile rentre dans la file dattente et linstant
o il la quitte.
Le temps que le mobile doit attendre au niveau MAC avant de pouvoir mettre ses
paquets, le mdium tant occup par des transmissions voisines.
En effet, la bande passante libre nest pas la mme sur tous les nuds du rseau. Cela
dpend du trafic passant par le nud et de lactivit des transmissions des nuds voisins. La
figure 4.2 montre un exemple de la variation de la bande passante libre dans le temps sur
deux nuds du rseau obtenu par simulation (pour une capacit du mdium de 11Mbps).
Fig. 4.2- Exemple de la bande passante libre sur deux nuds dun MANET.
- 49 -
Le dlai dun paquet dans la file dattente de lmetteur nest autre que le temps moyen de
sjour not R dun client arrivant dans la file, donne par la loi de Little :
1 ( +1) + +1 1
R= Avec : =
1 1
Ce temps de service diverge lorsque = 1. Nous allons donc calculer la limite de R quand
1 de ce temps de service. On obtient donc comme rsultat :
1 1
lim R = ( +1)
1 2
Do lexpression finale de R est donne par :
1 ( +1) + +1 1
Si 1
1 1
R=
...4.2
1 1
( +1) Si = 1
2
2.2.2 Dtermination du dlai de propagation

Le dlai de propagation est le dlai qui scoule depuis larrive dun paquet la couche
MAC jusqu la rception du paquet dacquittement en provenance du nud rcepteur,
incluant toutes les retransmissions en cas de collision.
Soit P la probabilit de collision sur le lien considr.
Soit n le nombre de retransmissions associes la probabilit de collision p.
Soit X la variable alatoire reprsentant le nombre de retransmissions. On a donc les
galits suivantes en terme de probabilit :
P( X = 0) = p 0 (1 p)
P( X = 1) = p1 (1 p)
P( X = 2) = p 2 (1 p)
.
.
.
P( X = j ) = p (1 p) Pour j 6
j
Dans la norme IEEE 802.11 le nombre maximum de retransmissions est fix 7 donc :
P( X = 7) = p 7
P ( X = i) = 0 Si i 8
On remarque que le facteur (1 p) nest pas prsent lorsque X = 7 , car aprs 7
retransmissions sans rception dun acquittement, le paquet de donnes correspondant est
dropp par la couche MAC. Nous pouvons donc en dduire lesprance de la variable
alatoire X correspondant au nombre moyen de retransmissions n :
- 50 -
6
n = E ( X ) = i. p i (1 p ) + 7 p 7
i =0
Pour obtenir une expression simplifie de n en fonction de p on utilise les rsultats sur la
drivabilit des sommes gomtriques :
6
1 p7
On sait que : p i =
i =0 1 p
En drivant cette expression par rapport la variable p on obtient :
7
6 p7 _ 7 p6 + 1
p i 1 =
i =0 (1 p ) 2
En multipliant lexpression par (1 p ). p on obtient finalement :
7
6 p8 _ 7 p7 + p
n = p i (1 p ) = ....4.3
i =0 (1 p )
De plus, selon la norme IEEE 802.11, chaque collision la taille de la fentre de contention
est double ainsi la i eme collision successive ( i 7 selon la norme IEEE 802.11) la taille de la
fentre de backoff est de 2i CWmin . Le backoff tant une loi uniforme, chaque stage de backoff
nous prendrons la valeur moyenne pour reprsenter la valeur du backoff qui sera choisi pour le
paquet qui va tre mis.
Ainsi le dlai de propagation sur le canal not D prop est donn par la formule :
n
1
D prop = ( DIFS + 2i CWmin + Tm )
i =o 2
n
1 1
D prop = ( n + 1)( DIFS + Tm ) + CWmin 2i
2 i =o 2
1
D prop = (n + 1)( DIFS + Tm ) + CWmin (2n+1 1) ..4.4
2
Tm reprsente le temps moyen de propagation dun paquet sur le mdium. Cette valeur
est constante lorsque la capacit du mdium est la mme en tout point. Cest le temps
ncessaire pour transmettre les en-ttes MAC, physique et les donnes du paquet mettre.
Ainsi le dlai sur un lien dun paquet de taille m not D est :
D = R + D prop ..4.5
Comme le montre la formule ci-dessus, le dlai de transmission dpend de la probabilit
de collision entre un nud metteur et le rcepteur. Si on considre un seul metteur, ce taux
de collision nest pas le mme vers lensemble de ces nuds voisins. Ainsi, le dlai est
diffrenci suivant le voisin vers lequel en veut envoyer les donns.
La probabilit de collision peut tre estime en utilisant lenvoi priodique des messages
HELLO. Chaque nud calcule cette probabilit avec la formule suivante :
Nombre de paquets HELLO entrs en collision

p= .. 4.6
Nombrede paquets HELLO que lon devrait recevoir
Le nombre de paquets entrs en collision est le nombre de paquets que lon devrait
recevoir duquel on soustrait le nombre de paquets effectivement reus durant une priode de
mesure. Cette estimation nest toujours pas assez prcise, car les paquets HELLO peuvent
tre influencs par une congestion ou une dfaillance des liens que par des collisions. Toute
fois, cette problmatique nest pas prise en compte dans cette tude [42].
- 51 -
2.3 Dtermination du dlai multi sauts

Le dlai est une mtrique additive, autrement dit le dlai moyen de bout en bout entre une
source s et une destination d not Ds ,d est gal la somme des dlais Di moyens des liens
constituants ce chemin.
D s ,d = Di ........ 4.7
i[ s , d ]
3 Intgration dans AODV

Pour introduire la qualit de service dans AODV, un contrle dadmission est ncessaire
pour permettre la vrification des conditions de la QoS demande. Lide repose sur lajout
dun ou plusieurs champs dans les paquets de contrle. Les informations qui contiennent ces
champs seront utilises pour faciliter le contrle dadmission effectu lors de ltablissement
des routes. Selon le principe de fonctionnement adopt, nous avons modifi le format de
deux paquets ; la requte de route RREQ, et les messages HELLO.
Dans le contexte de cette tude, nous essayons dans ce qui suit de mettre en uvre les
modifications ncessaires pour que la mthode destimation du dlai dcrite prcdemment
soit intgre dans le protocole AODV. Le principe de ces extensions et de fonctionnement
du protocole AODV modifi est inspir du draft [39] de lIETF.
Pour distinguer le protocole AODV standard de lextension faite dans ce travail, nous
avons appel notre protocole: AODV-D (pour Ad-hoc On-demand Distance Vector with Delay
constraints), ou AODV avec contraints dlai.
3.1 Extension de la RREQ

La requte de route est tendue pour inclure trois nouveaux champs, le premier spcifie le
dlai maximum demand lapplication, le deuxime pour la bande passante dsire et le
troisime est rserv au dlai un saut calcul la rception de la requte de route. Ces champs
seront utiliss pendant la diffusion de la requte de recherche de routes pour effectuer un
contrle dadmission au niveau de chaque nud intermdiaire.
Type J |R |G | D |U Reserved Hop Count

Bande passante dsire Dlai max demand Dlai un saut calcul
RREQ ID
Originator Sequence Number
Tab.4.1 : Format du message RREQ dans AODV-D.
- 52 -
3.2 Extension des messages HELLO

Les messages HELLO sont tendus pour inclure un nouveau champ, il spcifie la
probabilit de collision calcule laide des messages HELLO suivant la formule 4.6 dcrite
prcdemment, cette valeur sera rcuprer par la couche MAC lors de lenvoi de ces messages
afin de calculer le dlai de propagation suivant les formules 4.3 et 4.4.
Type R|A Reserved Prefix Sz Hop Count

Lifetime
Probabilit de collision
Tab.4.2 : Format du message HELLO dans AODV-D.
3.3 Mcanisme de routage AODV-D

3.3.1 Dcouverte des routes
Puisque le protocole AODV-D est inspir du protocole AODV, il garde la plupart de ces
mcanismes de fonctionnement avec des modifications pendant la diffusion de la requte de
dcouverte des routes. En plus, pour faciliter le contrle dadmission effectu lors de la
diffusion de RREQ, une approche proactive sera utilise pour estimer le dlai de propagation
au niveau de chaque lien actif. En utilisant la diffusion priodique des messages HELLO
effectuer par le protocole AODV, chaque nud dduit alors la valeur de la probabilit de
collision au niveau de chaque lien laide de lquation 4.6 ce qui lui permet de calculer le
dlai de propagation sur le lien concern avec les quations 4.3 et 4.4.
Une autre valeur sera calcule priodiquement est la bande passante rsiduelle (libre) pour
chaque nud laide de lquation 4.1. Celle-ci sera utilise lors de la rception dune RREQ
(aprs la rcupration de la bande passante dsire) pour le calcul du dlai probablement
pass dans la file dattente du nud considr laide de lquation 4.2. On dduit alors le
dlai un saut D par une simple addition avec le dlai de propagation suivant lquation 4.5,
le dlai un saut D sera marqu dans le champ ddi de la RREQ pour une utilisation dans le
contrle dadmission effectu par le protocole AODV-D
Si un nud source veut communiquer avec un autre nud qui na pas une route valide
dans sa table de routage pour cette destination, une procdure de dcouverte de route est
initie. Le nud source diffuse dabord une requte RREQ travers le rseau, Quand un
nud intermdiaire reoit une RREQ, il vrifie d abord sil existe une route valide dans la
table de routage sil existe une route il renvoi un RREP vers la source, sinon, avant de
retransmettre le message, il effectue un contrle dadmission pour tester le dlai. Celui-ci
consiste comparer la valeur du champ dlai max demand de la requte RREQ avec le
dlai calcul. Si ce dernier est infrieur celui du message RREQ alors cette valeur sera
soustraite de la valeur du RREQ, ensuite le message sera diffus vers la destination. Sinon la
RREQ sera drop directement par ce nud intermdiaire. Dans ce cas, la source doit
retransmettre une autre RREQ jusqu un certain nombre de fois comme le fait le protocole
AODV standard (figure 4.3).
- 53 -
Fig.4.3- dcouverte de routes dans AODV-D.
Quand la destination reoit la RREQ, elle fait le mme contrle, sil est vrifi, elle envoie
une requte RREP en mode unicast vers la source par le chemin inverse pour la validation de
la route concerne (figure 4.4), chaque nud intermdiaire doit mettre jour sa table de
routage. La communication entre la source et la destination peut alors avoir lieu en respectant
le dlai requis par la source, jusqu ce que lune des extrmits ferme la connexion, ou
jusqu ce que la route utilise se brise ou se dgrade.
Fig.4.4 : chemin de RREP.
3.3.2 Maintenance des routes

Pour la maintenance des routes, le protocole AODV-D maintient le mme mcanisme de
que le protocole AODV standard. Les cassures des routes sont dtectes grce lenvoi
priodique des messages HELLO. Si un nud ne reoit pas un message HELLO d'un certain
voisin durant un intervalle de temps prdfini, il marque les routes utilisant ce voisin comme
invalides et envoie un message derreur RERR aux voisins en amont de la route. Seule la
source initie de nouveau une procdure de dcouverte de route aprs avoir reu le message
d'erreur.
Lutilisation des messages HELLO habituels pour lestimation du dlai permet une
minimisation du trafic de contrle destin gnralement de telles taches. Cela offre deux
avantages : dun cot les routes tablies assurent les exigences de QoS en termes de dlai de
bout en bout. De lautre cot il ny aurait pas un trafic supplmentaire surchargeant le rseau,
ce qui a une influence sur le dlai cause de laugmentation de la probabilit de collisions et
des interfrences.
Lorganigramme dexcution du protocole AODV-D est prsent dans la figure 4.5.
- 54 -
Fig. 4.5 - L'organigramme d'excution de AODV-D.
3.4 Limitations
La partie touche par les modifications concerne seulement la phase de dcouverte de
routes c'est--dire la diffusion de la requte RREQ (voire figure 4.6). En effet, la solution
prsente dans la section prcdente permet au protocole AODV-D dassurer un certain
degr de qualit de service de telle sorte que toutes les routes tablies respectent la mtrique
dlai de bout en bout. Cependant aucune garantie nest fournie pendant la transmission des
paquets de donnes. Si le dlai augmente sur un chemin aprs la validation de ce lui ci, aucun
mcanisme de dtection et de maintenance de telles situations nest fournie. Autrement dit, la
QoS offerte est relche (soft QoS).
- 55 -
CA : contrle dadmission.
Fig. 4.6 : Lorganigramme dexcution de RREQ pour AODV-D.
- 56 -
4 Diagramme de squence
La figure 4.7 illustre le diagramme de squence qui rsume les principales oprations
effectues par le protocole AODV-D. Il montre galement lenchainement des principales
tapes par lesquelles doit passer AODV-D pendant la phase de dcouverte de routes et
lemplacement du contrle dadmission effectu par les nuds intermdiaires et la
destination.
Fig. 4.7 : Diagramme de squence dAODV-D.
5 Diagramme de classes
La figure 4.8 montre le diagramme de classes du protocole AODV-D [46]. Notons ici que
le diagramme a gard la mme structure que celui dAODV. Les modifications effectues
concerne certains attributs et oprations et non les classes eux mme ; On na pas ajout des
classe ni limin dautres.
La conception du protocole AODV-D a t faite autour de la classe pivot AODV. Cest la
classe de tous les objets participant lexcution du protocole sur les nuds. Ces objets
occupent la couche rseau dans chaque nud. La classe AODV utilise les objets des classes:
BroadcastTimer, HelloTimer, NeighborTimer, RouteCacheTimer, LocalRepairTimer,
aodv_rtable et aodv_rqueue pour maintenir les tats (valeurs de ces attributs), et cest au
niveau de cette classe que les modifications du protocole AODV sont introduites en ajoutant
quelques fonctionnalits concernant le contrle dadmission qui vrifie la mtrique de QoS
considre. Les composants touchs par les modifications sont marques en gras dans la
figure 4.8.
Le point dentre de la classe AODV est la mthode recv( ). A partir de cette mthode on
fait appel toutes les autres fonctions de la classe AODV. Parmi eux, la fonction
recvAODV( ), celle-ci fait appel la fonction recvrequest( ), et cest exactement ici que le
contrle dadmission est effectu.
- 57 -
Fig. 4.8 : Diagramme de classes dAODV-D.
- 58 -
Conclusion
Ce prsent chapitre dcrits les spcifications dune solution qui permet d'tendre le
protocole AODV pour garantir de la QoS en termes de dlai de bout en bout. Il dtaille
galement le principe de fonctionnement du nouveau protocole et la mthode d'estimation
du dlai utilise.
Ce chapitre a t ddi la conception de AODV-D. nous y avons abord les principaux
diagrammes UML qui montrent les relations entre les diffrentes classes du protocole. Ces
classes sont en grande partie, bases sur les classes AODV.
Le prochain chapitre sera consacr aux dtails de limplmentation du protocole AODV-D
modifi sous le simulateur NS-2 (network simulator 2).
- 59 -
Chapitre V Implmentation
Chapitre V
Implmentation
- 60 -
Implmentation
1 Introduction
Avec lvolution des rseaux sans fil et llaboration de plusieurs normes pour ces rseaux,
et avec le besoin des simulations dans le contexte de lvaluation des performances, de
nombreux simulateurs des rseaux ont t dvelopps. Les simulateurs les plus connus sont :
NS-2 (Network Simulator 2), OPNET et GloMoSim/Qualnet [15].
Dans le cadre de notre tude, nous avons choisi le simulateur NS-2 (voir annexe A)
dvelopp Lawrence Berkeley National Laboratory (LBNL). Cest le simulateur de rseaux le
plus utilis par la communaut des chercheurs dans les MANETs. NS-2 offre plusieurs
avantages ; nous pouvons citer [38]:
Il est open source et gratuit. Il englobe les contributions de nombreux chercheurs
travers le monde.
Il peut tre tendu d'autres modles grce sa conception oriente objet et son
implmentation en C++.
Il est riche en modles et en protocoles pour les environnements filaires et mobiles.
Il fournit des rsultats fiables sous forme de fichier trace riche en informations que
l'utilisateur peut exploiter.
Il est bien document. Les ressources bibliographiques relatives sa conception et son
implmentation sont trs nombreuses.
Il est utilis dans plus de 43% des travaux de recherche dans le domaine du routage dans
les rseaux MANETs.
Il inclut les implmentations de quatre protocoles de routage dans les MANETs savoir :
AODV, DSDV, DSR et TORA.
En plus de ces avantages, lapproche volutive que nous avons choisie dans cette tude
justifie notre choix de NS-2, car une implmentation du protocole AODV existe dj, il suffit
donc dy apporter les modifications ncessaires qui permettent dintgrer la QoS dans AODV
en appliquant la mthode dcrite dans le quatrime chapitre.
Ce prsent chapitre est consacr aux dtails de limplmentation du protocole AODV-D
sous NS-2. Pour ce faire, nous prsentons dabord les diffrents fichiers et modules
concerns par les modifications. Ensuite nous dcrivons les modifications ncessaires du
protocole IEEE 802.11 pour intgrer la mthode destimation du dlai adopte, et enfin, les
nouvelles mthodes ajoutes, les changements dans le format des paquets, et le mcanisme de
fonctionnement de lagent de routage AODV-D.
2 Prsentation dAODV sous NS-2

Limplmentation du protocole AODV sous NS-2 a t faite autour des fichiers sources
situs dans le rpertoire : \cygwin\...\ns-allinone-2.33\ns-2.33\aodv. Les fichiers concerns
sont les suivants :
aodv.h : cest le fichier principal (header) dans lequel sont dfinis tous les timers
(temporisateurs) ncessaires, et lagent de routage qui excute les fonctionnalits du
protocole.
aodv.cc : dans lequel tous les timers, les Tclhooks (liens entre les composants c++ et
ceux dOTcl) sont implments, ainsi que lagent de routage et ces fonctionnalits.
- 61 -
aodv_packet.h : ici sont dclars tous les types de paquets quutilise AODV dans les
changes entre les nuds du rseau.
aodv_rtable.h : le fichier header o la table de routage est dclare.
aodv_rtable.cc : implmentation de la table de routage.
aodv_rqueue.h : ce fichier dfinit la file dattente utilise par le protocole de routage
et la dclaration des diffrentes fonctions et mthodes utilises qui servent la
manipulation de cette file.
aodv_rqueue.cc : il contient limplmentation de la file et de fonctionnalits.
aodv_logs.cc : destin la gestion de la connectivit locale entre les nuds du rseau.
Pour plus de dtails dimplmentation du protocole AODV sous NS-2 et la relations entre
ces fichiers et avec dautres fichiers ainsi que les diffrentes classes et mthodes utilises, voir
[45].
3 Prsentation du protocole MAC-802.11 sous NS-2

Le simulateur NS-2 implmente galement le protocole Mac_802.11 qui sera utilis dans
cette tude au niveau MAC. Limplmentation de ce dernier est faite dans le rpertoire
/ns.2.33/mac autour des fichiers suivant :
mac-802_11.h : cest le fichier header dans lequel la classe de base Mac802_11 est
dclare ainsi que tous ces composants et attributs ncessaires au fonctionnement du
protocole. il dfinit aussi les formats de paquets de contrle utiliss.
mac-802_11.cc : dans lequel sont implmentes toutes les fonctionnalits du
protocole
mac-timers.h : dans lequel sont dclars tous les Timers utiliss.
mac-timers.cc : ici les Timers dclars dans mac-timers.h sont implments.
Dans ce qui suit, nous dcrivons les modifications ncessaires apportes ces fichiers pour
implmenter la mthode destimation du dlai dcrite prcdemment.
4 Structure des nuds AODV et AODV-D sous NS-2

La classe Node est la classe de base qui permet linstanciation des objets nuds dans le
simulateur NS-2. MobileNode hrite de la classe Node permet la cration des nuds
mobiles. Elle offre les fonctionnalits ncessaires au fonctionnement de ce type de nuds
comme le mouvement et la possibilit denvoyer et de recevoir des paquets dans un canal de
transmission. Les composants de la mobilit tels que le mouvement, la mise jour priodique
de la position du nud, et le maintien des frontires de la topologie sont implments en
C++. Tandis que les composants rseau (MAC, LL, Classifier ...) plants dans le nud sont
implments en OTcl.
La figure 5.1 montre que la structure du nud AODV-D est lgrement diffrente de celle
utilise pour AODV standard. Les principales diffrences sont :
couche MAC : le protocole 802.11 intgre un mcanisme destimation du dlai afin
de lutiliser par lagent de routage AODV-D alors que le standard ne procde pas cette
fonctionnalit.
couche rseau : la nouvelle structure a comme ente lagent de routage AODV-D au
lieu de lagent AODV standard, la diffrence entre les deux est que le premier effectue
un contrle dadmission pour les requtes de route entrantes afin de vrifier la
mtrique dlai de bout en bout exig par lapplication.
- 62 -
Couche application : dans le cas AODV-D, lagent applicatif est capable dinitialiser
les besoins en QoS. Ceci est le cas gnral. Dans notre cas, nous avons procd
comme dans la section 7 de ce chapitre.
Fig. 5.1 : structure des nuds AODV et AODV-D sous NS-2.
5 Implmentation dAODV-D sous NS-2

Dans cette partie, nous allons discuter les dtails dimplmentation du protocole AODV-D
sous le simulateur NS-2. Il sagit dune extension du protocole AODV tout en gardant le
protocole IEEE 802.11 au niveau MAC. Afin de faciliter cette phase, nous avons gard les
mmes noms des classes et des fichiers.
Lextension tudie consiste en lintgration de la QoS dans AODV en termes du dlai de
bout en bout, une mthode destimation du dlai sera intgre au niveau de la couche MAC en
ajoutant les modifications ncessaires au protocole MAC_802.11.
- 63 -
5.1 Estimation du dlai au niveau de la couche MAC

Lestimation du dlai est faite au niveau de la couche MAC, car elle est plus simple et
pertinente. La prise en compte des interfrences et des flux voisins ne ncessite pas lajout
dun trafic de contrle supplmentaire ce qui est en opposition avec la nature ractive du
protocole AODV.
Dans la mthode destimation adopte nous avons dcompos le dlai un saut en deux
parties : le dlai dans la file dattente not R et le dlai de propagation not D prop .
Pour le premier, nous lavons calcul avec lquation 4.2. Cette quation dpend de deux
paramtres :
Le premier est le paramtre qui reprsente le dbit dsir par lapplication qui est
explicitement fourni lors de la phase de requte de route avec QoS.
Le deuxime est Le paramtre qui reprsente la bande passante libre (appele aussi
rsiduelle) autour de ce nud. Celle ci sera calcule chaque priode T.
Pour le deuxime, il dpend de la probabilit de collision au niveau du nud rcepteur,
celle-ci est calcule priodiquement avec lquation 4.5. Ensuite, nous calculons le nombre de
retransmissions possible avec lquation 4.3, enfin en dduit le dlai de propagation D prop par
lequation4.4.
Le dlai un saut est obtenu alors par une simple addition suivant la formule 4.7. Dans ce
qui suit, nous dcrivons les modifications ncessaires dans le protocole IEEE 802.11 qui
permettent lestimation du dlai un saut laide de limplmentation des quations dcrites
prcdemment.
5.1.1 Estimation de la bande passante libre sur un nud

Pour estimer la bande passante libre, des modifications dans le fichier mac_802.11.cc sont
ncessaires, plus prcisment la classe Mac.802_11. La mthode adopte pour calculer la
bande passante libre est base sur le calcul du pourcentage du temps libre autour dun nud.
Cette information nest pas disponible dans la base des informations de la classe MAC802.11
originale. Lide est simple, il sagit dajouter un temporisateur (Timer), chaque priode (T) il
teste lobjet MAC802.11. Le temporisateur est dclar dans le fichier mac_timers.h et
implment dans le fichier mac_timers.cc comme le montre le code suivant :
Listing 5.1 : Implmentation du Timer.

Void
bandwidthTimer::handle(Event *)
{
busy_ = 0;
paused_ = 0;
stime = 0.0;
rtime = 0.0;
mac->bandwidthHandler();
T = (MinHelloInterval +
((MaxHelloInterval - MinHelloInterval) * Random::uniform()))/1;
assert(T>=0);
rtime = T;
Scheduler::instance().schedule(this, &intr,rtime);
}
- 64 -
Le temporisateur T est choisi alatoirement entre les deux valeurs : MinHelloInterval et

MaxHelloInterval dfinis par le protocole AODV pour envoyer les messages HELLO. A
lexpiration du temporisateur, la fonction bandwidthHandler()(dans laquelle nous avons
fait la mise jour de la bande passante libre) est appele.
Un objet MAC802.11 est soit en mission, soit en rception sinon il est libre. La classe
MAC802.11 originale implmente deux mthodes pour la mise jour de son tat. A chaque
envoi (donnes, RTS, CTS, ACK) la mthode SetTxState est appele, et chaque rception
cest la mthode SetRxState qui est appele.
On peut dduire le taux doccupation du medium par le nud en introduisant deux
variables, la premire reprsente le temps de toutes les transmissions (Send_time) et la
deuxime reprsente celui de toutes les rceptions (Rcv_time) pendant la fentre de temps
(T). La mise jour des variables (Send_time) et (Rcv_time) est introduite dans les
mthodes SetRxState et SetTxState respectivement dans le fichier \ns-
2.33\mac\mac_802.11.cc (voir listing5.2):
Listing 5.2 : mise jour des temps dmission et de rception

inline void
Mac802_11::setRxState(MacState newState)
{
rx_state_ = newState;
checkBackoffTimer();
double time=0.0; //le temps de la rception.
if (rx_state_ == MAC_RECV)
{
time = txtime(pktRx_);
}
else if (rx_state_ == MAC_ACK)
{
time = txtime(phymib_.getACKlen(),basicRate_);
}
else if (rx_state_ == MAC_RTS)
{
time = txtime(phymib_.getRTSlen(),basicRate_);
}
else if (rx_state_ == MAC_CTS)
{
time = txtime(phymib_.getCTSlen(),basicRate_);
}
Rcv_time += time; //mise jour de Rcv_time.
}
inline void
Mac802_11::setTxState(MacState newState)
{
tx_state_ = newState;
checkBackoffTimer();
double time = 0.0; //le temps de la rception.
if (tx_state_ == MAC_SEND)
{
time = txtime(pktTx_);
}
else if (tx_state_ == MAC_ACK)
- 65 -
{
time = txtime(phymib_.getACKlen(),basicRate_);
}
else if (tx_state_ ==MAC_RTS)
{
time = txtime(phymib_.getRTSlen(),basicRate_);
}
else if (tx_state_ == MAC_CTS)
{
time = txtime(phymib_.getCTSlen(),basicRate_);
}
Send_time += time; //mise jour de Send_time.

}
Une fois Rcv_time et Send_time connus, nous pouvons calculer le taux doccupation du
mdium (Busy_time ) par la relation suivante :
Busy_time = Rcv_time + Send_time/T
Le pourcentage du temps libre (free_time) sera gal (1- Busy_time). La bande passante
libre autour dun nud est gale la capacit du mdium Cmax multiplie par le pourcentage du
temps libre free_time (quation 4.1). Pour ce faire, nous avons introduit une nouvelle
mthode la classe mac_802.11 qui fait un calcule priodique de la bande passante libre
(paramtre ) ainsi que la mise jour de Rcv_time et Send_time. La mthode est
bandwidthHandler(), son code est donn dans listing 5.3 :
Listing 5.3 : mise jour de la bande passante libre.

void
Mac802_11 :: bandwidthHandler()
{
busy_time = (Rcv_time+Send_time)/mhbwTimer_.T;
free_time = (1-busy_time);
freebw_ = free_time * dataRate_ ;//la bande passante libre.
Rcv_time = Send_time = 0.0;
5.1.2 Rcupration du paramtre

Le paramtre qui reprsente la bande passante dsire, est fourni avec la requte
RREQ. Pour le rcuprer au niveau MAC, nous avons autoris le protocole 802.11 daccder
directement lentte du paquet RREQ.
La mthode RecvDADA() qui est dans le fichier \ns-2.33\mac\mac_802.11.cc est le point
de service qui passe le paquet reu par la couche MAC la couche rseau, et cest ici que nous
rcuprons la bande passante dsire ( ) afin de calculer le dlai dans la file dattente R .
- 66 -
5.1.3 Le dlai dans la file dattente R

Une fois les deux paramtres et connus, on peut dduire le dlai dans la file dattente
R avec lquation 4.2. Pour ce faire nous avons ajout une nouvelle variable Q_delay la
classe Mac_802.11 (reprsente la valeur de R) qui sera calcule au niveau de la mthode
RecvDADA() chaque fois quon reoit un paquet de type RREQ comme le montre le listing
5.4 :
Listing 5.4 : Code permettant lestimation du dlai dans la file.
void
Mac802_11::recvDATA(Packet *p)
{
struct hdr_cmn *ch = HDR_CMN(p);
..
double free, req_bw, rho, q ;
struct hdr_aodv *ah_= HDR_AODV(p);

struct hdr_aodv_request *rq_= HDR_AODV_REQUEST(p);
if (ch->ptype() == PT_AODV)
{
if (ah_->ah_type == AODVTYPE_RREQ)
{
req_bw = rq_->bw_req; //rcupration de paramtre de la RREQ.
free = freebw_; // la bande passante libre (le parameter
rho = req_bw/free;
q = 50.0; // la taille de la file.
if (rho < 1.0)

{
Q_delay = (rho*(1.0-((q+1.0)*pow(rho,q))+(q*pow(rho,q+1.0))))
/((1.0-rho)* free *(1.0 - pow(rho,q))) ;
//le dlai R dans la file dattente avec la formule 4.2.

}
}
}
5.1.4 Estimation du dlai de propagation

La deuxime partie du dlai un saut est le dlai de propagation qui est le dlai scoulant
entre le moment o le paquet est reu par la couche MAC jusqu la rception de
lacquittement correspondant par le nud rcepteur y compris toutes les retransmissions
possibles dues aux collisions. La mthode quon a choisie est base sur lestimation de la
probabilit de collision laide de lenvoi priodique des messages HELLO. Limplmentation
de cette mthode est faite au niveau de la couche rseau par le protocole AODV. Elle sera
discute dans les sections suivantes.
Le dlai de propagation est calcul au niveau de la couche MAC. En utilisant lenvoi
priodique des messages HELLO pour passer la valeur de la probabilit de collision la
couche Mac, cela est fait au niveau de la mthode sendData() dans le fichier mac_802.11.cc
juste avant lenvoi du paquet HELLO. Cette valeur sera enregistre dans la variable
p_collision ajoute la classe Mac_802.11 comme le montre le listing 5.5 :
- 67 -
Listing 5.5 : Rcupration de la probabilit de collision.

void
Mac802_11::sendDATA(Packet *p)
{
hdr_cmn* ch = HDR_CMN(p);
struct hdr_mac802_11* dh = HDR_MAC802_11(p);

struct hdr_aodv *ah_= HDR_AODV(p);

struct hdr_aodv_reply *rp_ = HDR_AODV_REPLY(p);
if(ch->ptype() == PT_AODV)
{
if(ah_->ah_type == AODVTYPE_HELLO)
{
p_collision = rp_->collision;///rcupration de la probabilit
de collision des messages HELLO.
}
}

pktTx_ = p;
}
Une fois la probabilit de collision connue on peut calculer le dlai de probagation avec les
equations 4.3 et 4.4. Pour implmenter ces quations nous avons ajout une nouvelle variable
D_prop_estimation la class Mac_802.11 dans le fichier\ns-2.33\mac\mac_802.11.cc, la
mis jour de la valeur de cette variable sera faite au niveau de la mthode RecvDADA()
chaque fois que celle-ci est invoque (listing 5.6) :
Listing 5.6 : Estimation du dlai de propagation.

void
Mac802_11::recvDATA(Packet *p)
Double N ;
if (p_collision > 0.0)

{
nbr_retransmit=(5.0*pow(p_collision,8.0)-7.0*(pow(p_collision,7.0))
+p_collision)/(1.0- p_collision);
//nombre de retransmission calcul avec lquation 4.3
if (nbr_retransmit <= 0.0)

{
N = 0.0 ;
}
else {
N = floor(nbr_retransmit);
}
}
D_prop_estimation =(N+1.0)*(phymib_.getDIFS()+txtime(ch->size(),dataRate_))
+(0.5*phymib_.getCWMin()*phymib_.getSlotTime()*(pow(2.0,N+1.0)-1.0));
// dlai de propagation calcul avec lquation 4.4.

.
- 68 -
5.1.5 Le dlai un saut

Dans la mme fonction (RecvDADA()), avant de passer le paquet la couche rseau (le
protocole AODV-D dans notre cas), nous calculons le dlai un saut par une simple addition entre
les deux variables D_prop_estimation et Q_delay, nous le recopions en suite dans le paquet
RREQ afin de lutiliser dans le contrle dadmission par le protocole AODV-D (listing 5.7) :
Listing 5.7 : copie du dlai un saut dans la RREQ .
rq_->one_hop_delay = Q_delay + D_prop_estimation;

..
uptarget_->recv(p, (Handler*) 0);
}
6 Les modifications au niveau de la couche rseau

Aprs avoir termin avec lestimation du dlai au niveau MAC, passons maintenant la
couche rseau. Cest ce niveau que lagent de routage AODV excute ces diffrentes
fonctionnalits. Pour simplifier limplmentation des modifications nous avons gard le
mme nom de lagent et les mmes fonctionnalits (la gestion des paquets de contrle, de la
table de routage).
6.1 Le format du paquet RREQ dans AODV-D

Trois champs sont ajouts au format du paquet RREQ : Le premier reprsente le dlai_max
ne pas dpasser (exig par lapplication), le deuxime concerne la bande passante dsire (le
paramtre ), le dernier est rserv au dlai un saut calcul au niveau de la couche MAC.
La modification du paquet est faite dans le fichier aodv_packet.h qui contient toutes les
dclarations des paquets AODV (listing 5.8):
Listing 5.8 : extension du paquet RREQ .

Struct hdr_aodv_request {
u_int8_t rq_type; // Packet Type
u_int8_t reserved[2];
u_int8_t rq_hop_count; // Hop Count
u_int32_t rq_bcast_id; // Broadcast ID
nsaddr_t rq_dst; // Destination IP Address
u_int32_t rq_dst_seqno; // Destination Sequence Number
nsaddr_t rq_src; // Source IP Address
u_int32_t rq_src_seqno; // Source Sequence Number
double rq_timestamp; // when REQUEST sent;
// used to compute route discovery
latency
double max_delay; // dlai demand par l'application
double bw_req; // bande passante demande
double one_hop_delay; //le dlai un saut calcul au niveau
MAC
}
- 69 -
6.2 Le format du paquet RREP dans AODV-D

Le format des paquets RREP a t modifi en ajoutant un champ qui est rserv la
probabilit de collision (voir listing5.9). Ce champ sera rempli lors de lenvoi des messages
HELLO (notons ici que les messages HELLO utilisent le format des paquets RREQ) :
Listing 5.9 : extension du paquet RREP.

struct hdr_aodv_reply {
u_int8_t rp_type; // Packet Type
u_int8_t reserved[2];
u_int8_t rp_hop_count; //Hop Count
nsaddr_t rp_dst; //Destination IP Address
u_int32_t rp_dst_seqno; //Destination Sequence Number
nsaddr_t rp_src; //Source IP Address
double rp_lifetime; // Lifetime
double collision; // probabilit de collision
double rp_timestamp; // when corresponding REQ sent;
//used to compute route discovery latency
6.3 Contrle dadmission

Lagent de routage AODV reoit les paquets provenant des couches suprieures ou
infrieurs par la mthode recv( ) situe dans le fichier aodv.cc. Si le paquet est venu de la
couche MAC. Lagent de routage va tester le type de paquet avec la mthode recvAODV(p)
situe toujours dans le mme fichier. Si ce paquet est une RREQ, la mthode recvRequest(p)
est appele. Selon le cas, le paquet sera ignor en appelant la mthode drop (p) ou bien
rediffus par la mthode forward( ) vers les voisins. Les diffrentes mthodes appeles lors de
la dcouverte de routes par le protocole AODV-D sont prsentes dans la figure 5.2 [46].
Dans AODV standard la requte de route est drope par un nud pour deux raisons : soit
le nud est la source elle-mme c'est--dire quelle a reu sa propre requte, Soit le paquet est
dj pass par ce nud. Une troisime raison est ajoute dans AODV-D, il sagit dun contrle
dadmission qui teste la mtrique dlai, puisque les paramtres de QoS (dlai max et bande
passante dsire) sont fournis avec la RREQ, le contrle dadmission sera effectu au niveau
de la mthode recvRequest() en introduit les modifications ncessaires. Ces modifications
consistent comparer le champ dlai_max (le dlai demand par lapplication) du paquet
RREQ avec le dlai un saut rcupr de la couche MAC. Si ce dernier est suprieur au dlai
max, le paquet sera drop, sinon on fait une mise jour du champ dlai max par une
soustraction du dlai calcul du dlai max (listing5.10).
- 70 -
Fig.5.2 : les mthodes appeles par AODV-D (dcouverte de route).
Listing 5.10 : contrle dadmission.

void
AODV::recvRequest(Packet *p) {
struct hdr_ip *ih = HDR_IP(p);
struct hdr_aodv_request *rq = HDR_AODV_REQUEST(p);
aodv_rt_entry *rt;
/*
* Drop if:
* - I'm the source
* - I recently heard this request.
* - le dlai n'est pas suffisant. (Exigences de QoS).
*/
if(rq->rq_src == index) {
#ifdef DEBUG
fprintf(stderr, "%s: got my own REQUEST\n", __FUNCTION__);
#endif // DEBUG
Packet::free(p);
return;
}
if (id_lookup(rq->rq_src, rq->rq_bcast_id)) {
#ifdef DEBUG
fprintf(stderr, "%s: discarding request\n", __FUNCTION__);
#endif // DEBUG
- 71 -
Packet::free(p);
return;
}
/*controle dadmission*/
if (rq->max_delay >= rq->one_hop_delay)

{
rq->max_delay = rq->max_delay - rq->one_hop_delay;
}
else {
#ifdef DEBUG
fprintf(stderr, "%s: dlai insuffisant\n", __FUNCTION__);
#endif // DEBUG
Packet::free(p);
return;
}
.
forward((aodv_rt_entry*) 0, p, DELAY);
}
6.4 La probabilit de collision

La probabilit de collision est estime laide de lenvoi priodique des messages HELLO
suivant lquation 4.5. Pour ce faire, nous avons utilis les mthodes existant par le protocole
AODV pour la gestion de voisinage :nb_insert(), nb_delete() et nb_purge()q,en
ajoutant les quatre variables suivantes la classe AODV :
nbr_neighbors : pour compter le nombre de voisins actifs, chaque fois que la
fonction nb_insert()est appele on incrmente de 1 et chaque fois que la mthode
nb_delete() est appele en dcrmente de 1.
nbr_ph_rsv : pour le nombre de paquets HELLO effectivement reus pendant la
priode mesure, chaque fois la mthode revcHello() est appele on incrmente de 1.
nbr_ph_must_rsv : cest le nombre de paquets HELLO que lon devra reus pendant
la priode de mesure, qui est gale :
nbr_neighbors * la priode de mesure * le temps sparant deux messages HELLO
(on a choisi la valeur MaxHelloInterval pour sassurer que tous les voisins ont envoy leurs
messages HELLO).
la mis jour de la valeur de cette variable est faite au niveau de la mthode
nb_purge()qui est appele priodiquement.
p_coll : au niveau de la mme mthode, on calcule la probabilit de collision avec
lquation 4.6 comme le montre le code donn dans le listing 5.11 :
Listing 5.11 : mis jour de la probabilit de collision.

void
AODV::nb_purge()
{
AODV_Neighbor *nb = nbhead.lh_first;
AODV_Neighbor *nbn;
double now = CURRENT_TIME;
- 72 -
if (nbr_neighbors >= 1.0){
nbr_ph_must_rsv = nbr_neighbors*MaxHelloInterval*3;//3 seconde (priode
de mesure).
p_coll = (nbr_ph_must_rsv - nbr_ph_rsv)/nbr_ph_must_rsv;
//calcule de la probabilit de collision avec lquation 4.6.
nbr_ph_rsv = 0.0;
for(; nb; nb = nbn) {

nbn = nb->nb_link.le_next;
if(nb->nb_expire <= now) {
nb_delete(nb->nb_addr);
}
}
}
7 Les exigences de QoS

Dans le cas gnral, les exigences de QoS sont fournies par lapplication. Selon le type de
lapplication, les demandes sont multiples (dlai, bande passante, gigue). Ceci ncessite la
cration dun agent applicatif qui est capable denvoyer des paquets exigeant une QoS. Ces
exigences seront rcupres par lagent de routage avec QoS afin de les utiliser dans les
diffrentes phases dtablissement des routes.
Dans notre cas, nous supposons que le trafic circulant travers le rseau est de mme type
(VoIP par exemple) et exige donc les mmes contraintes de QoS. En effet, nous navons pas
cr un agent applicatif exigeant la QoS, mais ces derniers seront initialiss directement par
lagent de routage AODV-D, lobjectif tant de tester lapproche destimation du dlai choisie
et le mcanisme de routage avec QoS intgr dans le protocole AODV. Pour ce faire, nous
avons ajout trois variables la classe AODV :
req_bandwitdh et req_delay : Ces deux variables servent spcifier les
exigences en bande passante et/ou dlai respectivement. Cela est fait au niveau de la
mthode sendRequest()en remplissant les deux champs rservs par les valeurs de ces
deux variables.
QoS_factor : cette variable est utilise pour indiquer au protocole AODV si le contrle
dadmission sera effectu ou non ; si elle est gale 1, le contrle est excut, sinon il
sera ignor.
Pour une meilleure flexibilit, nous avons choisi dinitialiser ces variables partir de
linterface Tcl. Cela est fait par lutilisation de la fonction bind()qui sert autoriser laccs
au variables C++ via Tcl, en ajoutant les lignes suivantes au constructeur de la classe
AODV dans le fichier aodv.cc (listing 5.12) :
Listing 5.12 : autoriser laccs au paramtre de QoS via linterface Tcl.
Mac802_11::Mac802_11() :
Mac(), phymib_(this), macmib_(this), mhIF_(this), mhNav_(this),
{

bind("req_bandwitdh",&req_bandwitdh);
bind("req_delay",&req_delay);
bind("QoS_factor",&QoS_factor);

}
- 73 -
Pour initialiser ces variables il suffit dajouter les commandes suivantes dans notre script
Tcl (listing 5.13):
Listing 5.13 : commandes Tcl pour initialiser les paramtres de QoS.
Agent/AODV set QoS_factor valeur souhaite
Agent/AODV set req_bandwitdh
Agent/AODV set req_delay
Aprs avoir termin avec les modifications ncessaires dans le code, une recompilation de
NS-2 est ncessaire, cela est fait par la commande make : Une fois cela est fait sans erreurs,
le protocole AODV-D peut tre utilis dans des simulations afin de vrifier les rsultats et les
comparer avec celles du protocole AODV standard.
Conclusion
Ce chapitre a t consacr aux dtails de limplmentation du protocole AODV-D, il
donne dabord une prsentation globale de la structure du protocole AODV sous Network
Simulator 2. Il discute ensuite les modifications apportes ce protocole dans le but
dintroduire la qualit de service dans ce protocole en terme de dlai de bout en bout. Enfin,
il introduit une description des modifications apportes au protocole IEEE 802.11 utilis au
niveau MAC afin dimplmenter la mthode destimation du dlai adopte dans cette tude
qui est ncessaire pour effectuer un contrle dadmission par AODV-D.
Dans le chapitre suivant, nous allons dcrire une srie de simulations ralises laide du
simulateur NS-2 dans le but dvaluer les performances du protocole AODV-D, et de le
comparer avec AODV standard afin danalyser les avantages et les inconvnients de cette
extension.
- 74 -
Chapitre VI Simulation et discussion des rsultats
Chapitre VI
Simulation et Discussion des Rsultats
75
Simulation et Discussion des Rsultats
1 Introduction
Dans les deux chapitres prcdents, nous avons dvelopp un protocole de routage avec
QoS dans les rseaux mobiles ad hoc. Il sagit dune extension du protocole AODV qui le
rend capable dassurer ltablissement des routes qui satisfont la contrainte de dlai de bout
en bout dans le but damliorer les performances des applications sensibles cette mtrique.
Afin de valider et dvaluer le mcanisme de routage avec QoS mis en place,
limplmentation des modifications apportes au protocole AODV a t ralise sous le
simulateur NS-2. Nous avons utilis la version 2.33 installe sous Cygwin (un mulateur Unix
sous Windows XP). Le choix de ce dernier est motiv par ces caractristiques cites dans le
chapitre prcdent.
Dans ce chapitre, nous allons prsenter une srie de simulations ralises laide du
simulateur NS-2. Les objectifs de ces simulations sont les suivants :
Evaluer les performances du protocole AODV-D selon certains paramtres de
mesure ;
Comparer les deux protocoles AODV et AODV-D ;
Conclure limpact des modifications apportes au protocole AODV ainsi que les
avantages et inconvnients de la solution.
2 Intrt et ncessit de la simulation

L'valuation de performances des protocoles de routage peut se faire en utilisant trois
techniques, savoir : la mthode analytique, les mesures, et enfin la simulation.
Le recours la simulation prsente de nombreux avantages. En effet, elle est plus rapide,
moins coteuse en ressources, rptable et permettant d'isoler des paramtres qui peuvent
parfois affecter les performances. De plus, il existe des scnarios trs difficiles tudier dans
la ralit [20].
3 Modle de simulation
Le modle de simulation prcise les paramtres de simulation utiliser dans
l'environnement de simulation. Ces paramtres sont offerts par le simulateur NS-2 et sont
paramtrables via les scripts Tcl.
Le simulateur NS-2 implmente les diffrentes couches ncessaires (application, transport,
routage, MAC et physique) pour la simulation dun rseau ad hoc. Le tableau 6.1 rsume les
diffrents paramtres utiliss dans les simulations.
76
Paramtres Valeurs
Protocole de routage AODV /AODV-D
Modle de propagation Two-ray ground
Couche MAC 802.11/DCF avec CSMA/CA
Porte de transmission 250 mtres
Capacit du canal 5.5 Mbps
Trafic d'application CBR (Continuous Bit Rate)
Taille des paquets 1000 octets
Temps de simulation 40 secondes
Surface de simulation 1000*1000 m
Tab. 6.1. Paramtres de simulation utiliss.
3.1 Modle de trafic

Puisque le but de nos simulations est danalyser les proprits de lextension du protocole
AODV, nous avons choisi que les sources de trafics soient dbit constant CBR (Constant Bit
Rate).
Le trafic entre les nuds est gnr en initialisant des connexions de trafics de type CBR
qui commencent des instants fixs via le script de simulation comme le montre le tableau
6.2. La taille des paquets de donnes est de 1000 octets.
Nous navons pas employ des sources de trafic TCP par exemple parce que TCP offre une
charge conforme ltat du rseau, c'est--dire, le trafic TCP change les temps auquel il
envoie des paquets en se basant sur sa perception de la capacit du rseau de dlivrer ces
paquets [17].
Le schma des piles protocolaires mis en place pour cette srie de simulation est prsent
dans la figure 6.1.
Application CBR
Transport UDP
Routage AODV AODV-D
MAC Mac_802.11
Fig 6.1 : Pile protocolaire mise en place
77
4 Mtriques de simulation mesures

Les simulations sont faites par rapport trois paramtres, dans le but de tester le protocole
sur diffrents aspects. Ces paramtres sont : le dlai de bout en bout, la gigue et le taux de
perte de paquets. Nous avons choisi ces trois derniers car ils sont les plus influents sur la
qualit de la VoIP comme nous lavons vu dans le chapitre 3 (section5.1). Cela nous montre
une vision globale sur les amliorations possibles apportes cette application par le nouveau
mcanisme de routage avec QoS mis en place dans cette tude.
Les trois mtriques mesures sont les suivantes :
Le dlai de bout en bout (End to End Delay) : est le temps qui spare le moment d'envoi
d'un paquet de la couche transport de la source et le moment de rception de ce paquet
par la couche transport de la destination. Il inclut le temps de latence pour la dcouverte
de routes, le temps de passage dans les files d'attente des nuds intermdiaires et le
temps de transmission d'un saut vers un autre. Nous mesurons le dlai de bout en bout
par rapport tous les paquets gnrs pendant la simulation, puis nous calculons la
moyenne. Cette mtrique reprsente l'efficacit du protocole en termes de temps de
rponse et en termes du choix des chemins optimaux (moins de nuds de congestion et
plus de stabilit) [20].
La gigue (jitter) : reprsente la variation du dlai dacheminement des paquets entre la
source et la destination. Elle est obtenue en calculant la diffrence entre le dlai du
paquet N et le dlai du paquet N+1. Cette mtrique nous permet de connaitre la stabilit
des connexions tablies travers le rseau au cours du temps, et limpact de la politique
utilise par le protocole de routage pour le choix de la route sur cette stabilit.
Le taux de perte de paquets : cest le rapport entre le nombre de paquets perdus (par
toutes les destinations du trafic) et le nombre de paquets mis (par toutes les sources du
trafic) [20]. La mtrique oppose au taux de perte de paquets est le taux de dlivrance des
paquets PDR (Packet Delivery Ratio) : cest le rapport entre le nombre de paquets reus et
le nombre de paquets mis. Un taux de dlivrance de paquets lev est quivalent un
taux de perte petit, et vice versa. Cette mtrique reprsente la fiabilit du protocole pour
expdier tous les paquets de donnes envoys.
5 Scnario de simulation
Afin de prsenter le nouveau mcanisme de slection des route effectu par le protocole
AODV-D et leffet de celui-ci sur la qualit de service demande par le trafic circulant
travers le rseau, nous avons mis en place le scnario prsent dans la figure 6.2. Ce dernier
nous permet galement de le comparer avec le mcanisme dtablissement des routes par
AODV standard.
Pour ce faire, nous avons procd comme suit :
Nous voulons mesurer les performances de la connexion 6 9 (CBR1), celui-ci dispose de
deux chemins ; le plus court chemin passant par les nuds 10 15, et lautre passant par les
nuds 0 5.
Le premier, est surcharg par deux connexions : CBR2 entre les nuds 11 et 13. Et CBR3
entre les nuds 10 et 14. Sur le deuxime, une seule connexion est tablie entre les nuds 1
et 3. Chaque nud est spar avec son voisin direct par une distance de 200m, cela assure que
le flux est pass par tous les nuds du chemin.
78
Fig 6.2- Scnario de simulation utilis.

Le tableau 6.2 rsume le droulement de la simulation et les principaux paramtres utiliss
pour chaque flux.
Flux Dbit (Kbps) Dbut Fin

CBR1 80 15 35
CBR2 380 5 25
CBR3 380 10 30
CBR4 620 20 35
Tab 6.2 : Paramtres de droulement de simulation.
6 Simulation et discussion
6.1 Dlai de bout en bout
La figure 6.3 montre les rsultats obtenus concernant la mtrique dlai de bout en bout
pour chaque paquet du flux CBR1.
Fig 6.3 : Dlai de bout en bout du flux CBR1 avec AODV-D et AODV standard.
79
Discussion
Avant la seconde 25, on remarque que les dlais obtenus par le protocole AODV standard
sont beaucoup plus levs par rapport AODV-D. Cela est justifi par le fait que ce dernier
ayant exig un dlai max de 150 ms pour accepter la route, et donc a choisi la route passant
par les nuds 0 5 ayant plus de sauts mais moins encombre par dautres transmissions
(seul le flux CBR4 est actif). Le lger dpassement de 150ms a t produit aprs la validation
de la route par le protocole de routage, dans ce cas on a dit que le mcanisme ne possde
aucune garantie pour le dlai pendant la transmission des donnes.
Par contre, le protocole AODV standard a choisi la route qui passe par les nuds 10 15
selon le critre classique ; le plus court chemin. Cette route est surcharge par deux
connexions (les flux CBR2 et CBR3), ce qui provoque des dlais importants (jusqu 700ms).
Cela est justifi par laugmentation du dlai pass dans les files dattente des nuds
intermdiaires cause des congestions.
Aprs la seconde 25 le flux CBR3 est arrt, on remarque que les dlais pour AODV
standard ont des valeurs proches de celles obtenues par AODV-D. Cela est justifi par le fait
que la seule diffrence est le nombre de sauts des chemins choisis par les deux protocoles.
Dune manire gnrale, on peut dire que le protocole AODV-D semble plus performant
que celui standard dans les conditions de simulation dcrites en termes de dlai de bout en
bout.
6.2 La variation de dlai (la gigue)

Toujours pour le mme scnario, on obtient les rsultats prsents dans les figures 6.4 et
6.5 qui reprsentent lvolution de la gigue du flux CBR1 au cours du temps de la simulation
pour les protocoles AODV-D et AODV.
Fig 6.4 : Evolution de la gigue pour AODV.
80
Fig 6.5 : Evolution de la gigue pour AODV-D.
Discussion
Lorsque le protocole AODV standard est activ, les variations de dlai sont plus
frquentes et ont des dlais plus important (jusqu 300 ms et dpasse souvent 100 ms)
surtout avant la seconde 25. Cela est justifi toujours par le choix du plus court chemin sans
aucune contrainte (le chemin passant par 10 15 dans notre cas), ce dernier est perturb par
dautres connexions. Aprs la 25ime seconde la route est libre et la connexion se stabilise.
Pour le protocole AODV-D, le choix de la route est soumis la contrainte du dlai qui ne
doit pas dpasser 150 ms, en effet, la route choisie est la plus stable en terme du dlai et par
consquence, la gigue obtenue a des valeurs au maximum de 150 ms et ne dpasse pas 50 ms
dans la plupart du temps, ce qui est acceptable pour une qualit moyenne de la VoIP par
exemple (voir le tableau 3.3 dans le chapitre 3).
6.3 La perte de paquets

Le tableau 6.3 rsume les rsultats obtenus pour chaque flux pour la perte de paquets avec
le mme scenario de simulation prcdent.
Protocole AODV AODV-D
Flux CBR1 CBR2 CBR3 CBR4 CBR1 CBR2 CBR3 CBR4

Paquets
envoys
200 951 951 1396 200 951 951 1396
paquets
reus
193 916 951 1396 200 951 951 1396
Paquets
perdus
7 35 0 0 0 0 0 0
Taux de
perte %
3.5% 3.68% 0% 0% 0% 0% 0% 0%
Tab 6.3 : Taux de perte de paquets pour AODV-D et AODV standard.

81
Discussion
Les rsultats prsents dans le tableau nous montrent que les simples scenarios et
paramtres de simulation utiliss ne provoquent pas des taux de perte importants dans la
plupart des cas. Mais on remarque des diffrences entre les deus protocoles.
Lorsque le protocole AODV standard est activ, les flux CBR1 et CBR2 ont subis des taux
de pertes de 3.5% et 3.68% respectivement. Cela est justifi par le choix de la route 10 15
qui est dj surcharge par les deux flux CBR2 et CBR3 ; lajout du flux CBR1 cette route,
provoqu ces pertes cause du manque de ressources et des congestions.
Lorsque le protocole AODV-D est activ, le critre de choix de la route avec contrainte du
dlai a permis de choisir la route 1 5. Cette route est plus stable car, seul le flux CBR4 est
actif. Dans ce cas, chaque route est surcharge par deux connexions ce qui permet de crer
des transmissions de donnes plus stable et donc des pertes faibles de paquets voir nulle
comme les rsultats obtenus dans notre cas.
Conclusion
Les simulations effectues dans ce prsent chapitre nous a montr la diffrence entre les
deux protocoles AODV et AODV-D. La comparaison entre les deux protocoles nous a
permis de dgager le comportement dAODV-D face aux connexions demandant un certain
dlai suite a lintgration du nouveau mcanisme de routage.
Nous concluons galement que la mise en uvre dun tel mcanisme de routage ayant une
importante influence sur la stabilit du rseau. En effet, le routage avec contraints de dlai
peut apporter des amliorations des applications exigeant des ressources de QoS telles que
la voix sur IP. Il rend galement la mise en uvre de telles applications dans un rseau mobile
ad hoc plus efficace.
Il faut noter ici que le scnario simple que nous avons ralis dans ce chapitre a juste le but
de connatre la diffrence entre le comportement des deux protocoles. Toutefois, les
performances relles du protocole AODV-D ne peuvent tre dduites par ce simple scnario.
Il est, en effet, important de concevoir des scnarios pertinents (tels que des scenarios
alatoires en utilisant les modles de mobilit offerts par NS-2) conduisant une valuation
plus prcise du comportement du protocole.
82
Conclusion gnrale & Perspectives
Les rseaux ad hoc trouvent des applications dans plusieurs domaines tels que les
communications dans un champ de bataille, la gestion de catastrophes naturelles, les
communications de groupes, etc. Rcemment, ces rseaux attirent de plus en plus dattention
grce leurs avantages. Le revers de la mdaille est que plusieurs problmes comme la scurit,
lconomie dnergie, la scalabilit, et la qualit de service (QoS) doivent tre solutionns pour
permettre un large dploiement.
Dans le cadre de ce mmoire, lobjectif tait danalyser le protocole de routage AODV

oprant dans les rseaux mobiles ad hoc. Une extension de ce protocole est faite en termes
du dlai de bout en bout. Le but est de le rend plus adapt des applications telles que la voix
sur IP (VoIP).
Le travail ralis dans ce mmoire sinscrit dans le cadre des solutions proposes pour
lapprovisionnement en qualit de service relche (soft QoS) dans les rseaux ad hoc. En
effet, vu les caractristiques de tels environnements, on ne peut sattendre une qualit de
service ferme (hard QoS).
La recherche en qualit de service dans les rseaux ad hoc se focalise sur quatre axes
principaux, savoir : (i) les modles de QoS, (ii) les protocoles de signalisation, (iii) les
protocoles MAC sensibles la QoS, et enfin (iv) le routage avec QoS.
Daprs ltude que nous avons mene, plusieurs protocoles de routage avec QoS ont t
proposs dans la littrature, aussi bien pour les rseaux filaires que pour les rseaux ad hoc.
Nous pouvons classifier toutes ces propositions en deux grandes catgories : solutions
volutionnaires et solutions rvolutionnaires. La premire catgorie de solutions vise tendre des
protocoles best effort existants alors que la deuxime vise concevoir un protocole de
routage avec QoS partir de rien (from scratch).
Nous avons opt pour la premire approche pour des raisons de simplicit et de
compatibilit avec les protocoles best effort .
Par ailleurs, nous avons pris le dlai comme mtrique de routage. Pour concevoir notre
protocole baptis AODV-D (AODV with Delay constaints), nous nous sommes bass sur les
travaux de Sarr et al pour estimer le dlai dattente au niveau de la sous-couche MAC et sur le
draft de Perkins et al, auteurs du protocole AODV pour le mcanisme de fonctionnement.
Par la suite, nous avons procd limplmentation de notre protocole sous NS-2 (Network
Simulator 2) en rutilisant le code source du protocole AODV rajout dautres composantes
ncessaires.
En phase finale du projet, nous avons valu notre solution. Les rsultats prliminaires
de simulation ont montr que notre protocole donne de bonnes performances en termes de
dlai de bout en bout, de gigue, et de perte de paquets.
83
Notons enfin que ce travail nous a ouvert le champ vers dautres extensions que nous
citons ici en guise de perspectives :
- Evaluer AODV-D par rapport dautres mtriques telles que la consommation en nergie, le
temps dtablissement dune route, et loverhead gnr, dune part ; et par rapport dautres
scnarios dautre part ;
- Etendre le mme travail un autre protocole ractif qui est DSR et faire la comparaison avec
AODV-D ;
- Comparer lapproche routage avec contraintes de dlai avec lapproche routage multi-chemins
pour lamlioration des dlais de bout en bout. On peut imaginer par exemple comparer
AODV-D avec AOMDV
- Etendre notre protocole pour faire un routage multi-contraintes : on peut, par exemple, faire
un routage deux mtriques (bande passante et dlai) ou trois mtriques (bande passante,
dlai, et nergie) ;
84
Bibliographie
[1] : Mohamed BRAHMA tude de la QoS dans les Rseaux Ad hoc : Intgration du
Concept de lIngnierie du Trafic . Thse de doctorat. Universit de HAUTE ALSACE
(dcembre 2006).
[2] : Farid JADDI CSR: une extension hirarchique adaptative du protocole de routage ad hoc
DSR .Thse de doctorat. Institut National Polytechnique de Toulouse, Octobre 2006.
[3] : Andrew TANENBAUM rseaux, architecture, protocoles, application InterEditions,

Paris 1990.
[4] : Ahmed HABBOUCHI, Ismail LAOUFI Conception cross layer et intgration de la

QoS dans le protocole de routage DSR mmoire dingniorat, cole militaire polytechnique
(EMP) Anne 2007.
[5] : Michal Hauspie Contributions l'tude des gestionnaires de services distribus dans les
rseaux ad hoc thse de doctorat, Universit des Sciences et Technologies de Lille, Anne :
2005.
[6] :M.KHEMIS et H.TOUATI, Etude et simulation des protocoles de routage dans les
rseaux ad hoc .mmoire dingniorat 2002/2003, universit de TIZI OUZOU.
[7] : Rabah MERAIHI : Gestion de la qualit de service et contrle de topologie dans les
rseaux ad hoc thse de doctorat, Ecole nationale suprieure des tlcommunications, France.
janvier 2005.
[8] : Tayeb LEMLOUMA Le Routage dans les Rseaux Mobiles Ad Hoc Universit des
Sciences et de la Technologie Houari Boumdiene, Septembre 2000.
[9] : Anis LAOUITI : Unicast et multicast dans les rseaux ad hoc sans fil , thse de doctorat,
universit de Versailles, juillet 2002.
[10]: S. Corson , J. Macker Mobile Ad hoc Networking (MANET) Network Working Group
January 1999.ftp://ftp.nordu.net/rfc/rfc2501.txt
[11] C. Perkins, E. Belding-Royer, S.Das: Ad hoc On-Demand Distance Vector (AODV)
Routing, Network Working Group, July 2003: ftp://ftp.nordu.net/rfc/rfc3561.txt
[12] M. Lewis R. Ogier, F. Templin. Topology Dissemination Based on Reverse-Path

Forwarding (TBRPF) draft IETF, 2003.
[13]Yih-Chun Hu.David B. Johnson, David A. Malts: The Dynamic Source Routing
Protocol for Mobile Ad Hoc Networks (DSR) (draft IETF), 2003.
[14] : Van der Meerschen Jrme Hybridation entre les modes ad hoc et infrastructure dans
les rseaux de type Wi-Fi Universit Libre de Bruxelles anne 2005-2006
85
[15] : Dominique Dhoutaut, Etude du standard IEEE 802.11 dans le cadre des rseaux ad hoc
: de la simulation l'exprimentation LInstitut National des Sciences Appliques de Lyon
Thse Dcembre 2003.
[16] :Jean-Marc Percher et Bernard Jouga Dtection dintrusions dans les rseaux ad hoc
Ecole Suprieure dElectronique de lOuest (ESEO) France.
[17] : Meriam Dawoud, Analyse du protocole AODV rapport de stage, Universit Paul
Sabatier-I.R.I.T, 2005/2006. http://phdgroup.org/LebaneseUniversityArchive/CSTI/2005-
2006/5.pdf.
[18]: Philippe Jacquet Thomas Clausen. RFC 3626 Optimized Link State Routing Protocol
(OLSR), (draft IETF) 2003.
[19]: Leila TOUMI : Algorithmes et mcanismes pour la qualit de service dans les rseaux
htrognes Thse de doctorat, Institut National Polytechnique de Grenoble, dcembre 2002
[20] : Meriem BELGAID Saida OUHAB Routage et qualit de service dans AODV et
OLSR Mmoire 2006-2007 Universit A/Mira de Bejaa.
[21]:C. Chiang, H. Wu, W. Liu, and M. Gerla: Routing in Clustered Multihop, Mobile
Wireless Networks In Mobile Wireless Networks, The IEEE Singapore International
Conference on Networks, 1997.
[22] Vincent D. Park and M. Scott Corson. A Highly Adaptive Distributed Routing
Algorithm for Mobile Wireless Networks. In INFOCOM (3), pages 14051413, 1997.
[23]: C-K Toh. A Novel Distributed Routing Protocol To Support Ad-Hoc Mobile
Computing. In IEEE 15th Annual Intl. Phoenix Conf. Comp. and Commun, 1996.
[24]:R. Dube, C. Rais, K. Wang, and S. Tripathi. Signal stability based adaptive routing (SSA)
for ad hoc mobile networks. In Signal stability based adaptive routing (SSA) for ad hoc mobile
networks, IEE Personal Communication., February 1997.
[25]E. Crawley, R. Nair, B.Rajagopalan, and H. Sandick., A Framework for QoS-

basedRouting in the Internet, IETF RFC 2386, Aug. 1998. ftp://ftp.nordu.net/rfc/rfc2386.txt.
[27]: R. Braden, D. Clark, and S. Shenker. Integrated services in the internet architecture :an
overview. Internet Request For Comments RFC 1633, IETF, June 1994.
ftp://ftp.nordu.net/rfc/rfc1633.txt.
[28]: S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An architecture

for differentiated services. Internet Request For Comments RFC 2475, IETF, December1998.
ftp://ftp.nordu.net/rfc/rfc2475.txt.
[29]:Ian and C.Castelluccia Dierentiation mechanisms for IEEE 802.11. In to appear in

IEEE Infocom 2001, april 2001.
[30]:K. Wu and J. Harms QoS Support in Mobile Ad Hoc Networks. Crossing Boundaries-
the GSA Journal of University of Alberta, Volume 1, n 1. pages 92- 106. Nouvembre 2001
86
[31]: IEEE 802.11 WG, Wireless Medium Access Control (MAC) and Physical Layer (PHY)
spcifications : Medium Access Control (MAC) Enhancement for Quality of Service (QoS IEEE
802.11e/Draft 3.0, May 2002.
[32]: Claude Chaudet Qualit de service et rseaux ad hoc un tat de lart rapport de
recherche, institut national de recherche en informatique en automatique NRIA, novembre 2001.
[33] : Claude Chaudet Routage QoS et rseaux ad hoc : de ltat de lien ltat de nud
rapport de recherche INRIA, Janvier 2003.
[34] M.K Marina, and S.R Das. Ad hoc on-demand multipath distance vector routing. Wiley
Wireless Communications and Mobile Computing, vol. 6(7), 2006, pp. 969988.
[35] Z. Ye, S. V. Krishnamurthy, and S. K. Tripathi. A routing framework for providing

robustness to node failures in mobile ad hoc networks. Elsevier Ad Hoc Networks Journal, vol
2(1) 2004, pp. 87107.
[36] S.-J. Lee, and M. Gerla: AODV-BR: Backup Routing in Ad hoc Networks. , the IEEE
Wireless Communications and Networking Conference (WCNC 2000). Vol 3, September 2000
pp. 13111316.
[37] :Hui.Yao .Zhang, Marek.Bialkowski, Garry.Einicke and Jhon.Homer An extended

AODV protocol for VoIP application in mobile ad hoc network, SITEE, university of Brisbane
Australia(2007).
[38]: Shan Gong Quality of Service Aware Routing Protocols for Mobile Ad Hoc Networks
these de magister, HUT communication laboratory Finlande (2006).
[39]: C. Perkins and E. Belding-Royer: Quality of Service for Ad hoc On-Demand Distance
Vector Routing (work in progress), draft IETF, Oct 2003.
[40] : P. Anelli & E. Horlait NS-2: Principes de conception et d'utilisation
[41] : Baptiste BUXANT Simulation et valuation dun algorithme de contrle de congestion

pour Internet Universit Catholique de Louvain, anne 2001-2002.
[42] : Cheikh SARR De lapport dune valuation prcise des ressources de la qualit de service
des rseaux ad hoc bass sur IEEE802.11 thse de doctorat, Institut Nationale des Sciences
Appliques de Lion, anne 2007.
[43] : Antoine MAHUL Apprentissage de la qualit de service dans les rseaux multiservice :
application au routage optimale sous contraintes universit BLAISE PASCAL - CLERMONT-
FERRAND II, novembre 2005.
[44]: Giuseppe Bianchi Performance analysis of IEEE802.11 distributed coordination

function IEEE Journal on selected Areas in communication, volume18 (3): pages 535 -547
mars 2000.
[45]: http://dropzone.tamu.edu/~prajjwal/ns2/main.html
[46]: Sebastian Roschke Implementation of Feedback Mechanism into AODV based on
NS2. Un papier pulpier le 2007-05-16. Hasso Plattner-Institute for software systems engineering
87
[47]: Lei Chen and Wendi B. Heinzelman (University de Rochester USA) A Survey of
Routing Protocols that Support QoS in Mobile Ad Hoc Networks, IEEE Network.
November/December 2007.
[48]: la qualit de service en voix sur IP Accellent , www.accellent-group.com.
[49] : http://www.chez.com/brunogarcia/Unix/Docs/awk.html
88
Liste des Abbreviations
AODV Ad hoc On demand Distance Vector

AODV-D Ad hoc On demand Distance Vector with Delay constraints
CBR Constant Bit Rate
CBRP Cluster Based Routing Protocol
CSMA/CA Carrier Sense Multiple Access with Collision Avoidance
CTS Clear To Send
CW Contention Window
DCF Distributed Coordination Function
DIFS DCF Inter Frame Spacing
DSDV Distance Source Distance Vector routing protocol
DSR Distance Source Routing
DSSS Direct Sequence Spread Spectrum
EIFS Extended Inter Frame Spacing
FHSS Frequency Hoping Spread Spectrum
GHz Gga-Hertz
GPRS General Packet Radio Service
GSM Global System for Mobile Communication
HiperLAN2 HIgh Performance Radio LAN 2.0
IEEE Institute of Electrical and Electronical Engineers
IETF Internet Engineering Task Force
INRIA Institut National de Recherche en Informatique et en Automatique
IP Internet Protocol
IR Infra Red
ISO International Organization for Standardization
ITU International Telecommunication Union
MAC Medium Access Control
MACA/PR Multihop Access Collision Avoidance with Piggyback Reservation
MANET Mobile Ad hoc NETwork
Mbps Mga bits par seconde
MPR MultiPoint Relay
NAV Network Allocation Vector
NS-2 Network Simulator 2
OFDM Orthogonal Frequency Division Multiplex
OLSR Optimized Link State Routin
OSI Open Systems Interconnection
PCF Point Coordination Function
PDA Personal Digital Assistant
PDR Paquet Delevery Ratio
PIFS PCF Inter Frame Spacing
QoS Quality of Service
RERR Route ERRor
RFC Request For Comments
RREP Route REPly
RREQ Route REQuest
RTS Request To Send
SIFS Short Inter Frame Spacing
TBRPF Topology Dissemination Based on Reverse-Path Forwarding
TCP Transmission Control Protocol
ToIP Telephony over IP
89
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunication System
VoIP Voice over Internet Protocol
WiFi Wireless Fidelity
WLAN Wireless Local Area Network
WMAN Wireless Metropolitan Area Networks
WPAN Wireless Personal Area Networks
WWAN Wireless Wide Area Networks
ZRP Zone Routing Protocol
90
Annexes -
Annexe A : Network Simulator 2
A.1 Prsentation de Network Simulator 2
NS2 (Network Simulator 2) est un simulateur vnements discrets dvelopp dans un but
de recherche. Il fournit un environnement assez dtaill permettant entre autre de raliser des
simulations dIP, TCP, du routage et des protocoles multicast aussi bien sur des liens filaires
que sans fil [15].
NS-2, est aujourdhui le simulateur de rseau probablement le plus utilis par la
communaut scientifique des rseaux. Il a t le fruit de la collaboration entre luniversit de
Berkeley, USC (University of Southern California) et Xerox PARC dan lse cadre du projet VINT
(Virtual Inter Network Testbed). Ce projet est soutenu par le DARPA(Defense Advanced Research
Projects Agency). NS-2 est un outil de recherche trs utile pour le design et la comprhension
des protocoles. Il sert aussi bien dans ltude des protocoles de routage qu ltude des
rseaux mobiles o les communications par satellites.
NS-2 permet lutilisateur de dfinir un rseau et de simuler les communications entre les
nuds. Le simulateur utilise le langage orient objet OTCL driv de TCL pour la description
des conditions de simulation sous forme de script. Dans le script lutilisateur fournit la
topologie du rseau, les caractristiques des liens physiques, les protocoles utiliss, le type de
trafic gnr par les sources, les vnements, etc.
Si le script crit en OTCL permet une utilisation (dition, modification des simulations)
facilite du simulateur, les routines sont elles crites en C++ pour avoir une plus grande
puissance de calculs. Le rsultat dune simulation est un fichier texte contenant tous les
fichiers vnements de la simulation. Un traitement ultrieur de ce fichier permet den
soustraire linformation souhaite. Par ailleurs, le simulateur permet la cration dun fichier
danimation (dextension .tr), permettant de visualiser la simulation sur linterface graphique
NAM. Cette visualisation fournit une reprsentation du graphe du rseau sur laquelle on peut
voir les paquets circuler, suivre le niveau des files dattente et observer le dbit courant des
liaisons. La figure A1 prsente une simple utilisation de NS-2 [41].
Fig. A1 : Une simple utilisation de NS-2.
91
Annexes -
A.2 Installation de NS-2

NS-2 est conu initialement pour fonctionner sur les systmes d'exploitation Unix et
Linux, mais il existe un moyen pour son installation sur un systme Windows 2000/XP; il
s'agit de l'mulateur Cygwin qui offre un environnement Linux sous Windows. Cygwin est
tlchargeable partir d'Internet dans l'url : http:// www.cygwin.com. Le simulateur NS-2 est
fourni sous forme d'un paquetage qui regroupe tous les fichiers ncessaires son installation.
On le trouve sous le nom : ns-allinone-version.tar.gz. (ns-allinone-2.33.tar.gz est utilis dans
notre simulation).
A.2.1 Installation de NS-2 sous Windows

Avant de commencer installer NS-2, il faut tout d'abord installer cygwin. Pour ce faire
suivre les tapes suivantes :
A.2.1.1 Installation de cygwin

1. Tlcharger cygwin partir de son emplacement sur internet.
2. lancer l'installation on cliquant sur le bouton suivant.
3. choisir le chemin a partir de quel il s'installe: install from local directory.
4. choisir le chemin d'installation.
5. choisir Next.
6. slectionner les packages installer en activant install.
7. choisir Next.
8. terminer l'installation on cliquant sur terminer.
9. choisir OK.
A.2.1.2 Installation de NS-2

Aprs avoir installer cygwin, on doit suivre les tapes suivantes pour installer NS-2:
1. Tlcharger NS-2 partir de son emplacement sur internet.
2. Copier le dossier ns-allinone, dans le dossier /home/.
3. cliquer sur l'icne cygwin, la fentre noir s'affiche.
4. dcompresser le: tar zxvf ns-allinone-2.33.tar.gz
5. accder au rpertoire ns-allinone-2.33: cd ns-allinone-2.33
6. taper la commande ./install.
7. Configuration finale: une fois ceci fait, notre NS-2 est install, il nous reste de le configurer.
D'habitude, on configure le fichier .bashrc mais avec cygwin, il y'a une autre alternative plus
facile:
(a) Copier ns.exe qui est sur ns-allinone-2.33/ns-2.33 et le coller sur cygwin/bin
(b) Copier nam.exe qui est sur ns-allinone-2.33/nam-1.11 et le coller sur cygwin/bin
Ainsi notre configuration est termine.
92
Annexes -
A.3 Les composants disponibles dans NS-2

La liste des principaux composants actuellement disponible dans NS-2 sont reprsents
par catgorie da le tableau suivant :
Application Web, ftp, telnet, gnrateur de trafic (CBR, ...).

Transport TCP, UDP, RTP, SRM.
Routage Statique, dynamique (vecteur distance) et routage multipoint
(DVMRP, PIM).
Gestion de file d'attente RED, DropTail, Token bucket.
Discipline de service CBQ, SFQ, DRR, Fair queueing.
Systme de transmission CSMA/CD, CSMA/CA, lien point point ;
Tab A1 : Les principaux composants de NS-2.
A.4 Les langages utiliss dans NS-2

NS-2 utilise deux langages parce quil ralise deux types de choses. Dune part, le
simulateur doit tre efficace dans la manipulation de bytes, de paquets et denttes et dans
lapplication dalgorithmes sur de grandes quantits de donnes. Dans ce cas la vitesse
dexcution est primordiale et prend le pas sur le temps de compilation, lutilisation du C++
simpose. Dautre part, lutilisateur souhaite changer rapidement ses scnarios de simulation,
dans ce cas OTCL offre une bonne solution [40].
NS-2 permet lutilisateur de dfinir un rseau et de simuler les communications entre les
nuds. Le simulateur utilise le langage orient objet OTCL driv de TCL pour la description
des conditions de simulation sous forme de script.
Dans le script lutilisateur fournit la topologie du rseau, les caractristiques des liens
physiques, les protocoles utiliss, le type de trafic gnr par les sources, les vnements, etc.
Si le script crit en OTCL permet une utilisation (dition, modification des simulations)
facilite du simulateur, les routines sont elles crites en C++ pour avoir une plus grande
puissance de calculs. Un grand nombre de classes sont prdfinies et mettent en uvre
plusieurs types de protocoles, de files dattentes, de sources et algorithmes de routage.
A.5 Architecture de NS-2

A.5.1 Arborescence des classes compiles
Un grand nombre de classes sont prdfinies et mettent en uvre plusieurs types de
protocoles, de files dattentes, de sources et algorithmes de routage [41].La figure A.2
reprsente l'arborescence de classes utilises par le simulateur [40].
93
Annexes -
Fig. A2 : Arborescence de drivation des classes C++ du simulateur.
TclObject : Cest la racine de toutes les autres classes la fois dans l'arborescence compile
et interprte. La classe TclObject constitue donc la classe de base de la plupart des autres
classes. Tous les objets du modle de simulation sont des instances de la classe TclObject.
Cette classe sert aux objets dont la cration est initie par l'interprteur. Elle possde les
interfaces ncessaires aux liaisons entre les variables qui doivent tre visibles la fois en C++
et OTcl. Elle dfinit la fonction command () qui est trs utile pour ajouter des commandes
l'interprteur. La classe TclObject ainsi que les autres sources du rpertoire tclcl sont
partages entre NS-2 et le projet MASH de Berkeley. Dans la hirarchie des classes OTcl, le
nom de la classe racine se nomme autrement et porte le nom de SplitObject.
NsObject : cest une sous-classe de la classe TclObject mais reste cependant une superclasse
aux autres classes. La principale diffrence avec la classe TclObject tient ce qu'elle soit
capable de recevoir des paquets et traiter des vnements. Elle hrite de la classe Handler.
Cette classe constitue la principale racine des objets dans NS-2. Elle contient les fonctions
communes ncessaires au simulateur et dfinit la fonction virtuelle : void recv (Packet *,
Handler* callback =0)=0; Cette fonction est une fonction gnrique utilise par tous les
objets drivs de NsObject pour recevoir un paquet. Elle est rellement dfinie par les sous-
classes :
Application : Classe mre de toutes les applications (ftp, telnet, web)
Agent : La classe agent fournit des mthodes utiles au dveloppement de la couche
transport et d'autres protocoles du plan de signalisation ou de gestion. C'est la classe
de base pour dfinir des nouveaux protocoles dans NS-2. Elle fournit l'adresse locale
et de destination, les fonctions pour gnrer les paquets, l'interface la classe
Application. Actuellement NS-2 comporte de nombreux agents citons: UDP,
protocoles de routage, diffrentes versions de TCP, RTP, etc. [20].
Node : un nud peut tre une machine hte, un switch, un routeur, une passerelle,
etc. Chaque nud contient au minimum les composants suivants :
1. Une adresse ou un identificateur (id_) automatiquement incrment par une unit (
partir de 0) quand les nuds sont cres.
2. Une liste de noeuds voisins (neighbor_).
94
Annexes -
3. Une liste d'agents (agent_).

4. Un identificateur du type du nud (nodetype_).
5. Un module de routage.
Queue : la classe mre de tous les buffers (DropTail, RED)
LinkDelay : cette classe simule le dlai de propagation et le temps de transmission sur
les liens du rseau. Avec la classe Queue, cette classe simule les couches 1 et 2 d'Internet.
Packet : la classe de tous les paquets circulant sur le rseau.
TimerHundler : la classe mre de tous les timers(temporisateurs) utiliss par les
protocoles du rseau [20].
A.5.2 Arborescence des fichiers

La distribution de NS-2 comprend principalement 3 rpertoires (figureA3) [41]:
- NS-2, l'application NS. Ce rpertoire contient l'ensemble des fichiers .h et .cc de
NS-2.
- nam-1, l'outil de visualisation des rsultats de la simulation: l'animateur rseau.
- tclcl, sources du code assurant la liaison entre l'interprteur et le simulateur. Lun des
principaux fichiers est: tcl-object.tcl.
Fig. A3 : Arborescence des fichiers de la distribution NS-2.
A.6 Le modle de rseau sous NS-2

Un modle de rseau sous NS-2 est constitu de quatre composants essentiels :
Les nuds de rseau : endroits o est gnr le trafic, ou nuds de routage ;
Les liens de communication entre les rseaux.
Les agents de communication, reprsentant les protocoles de niveau transport (TCP,
UDP) ; ces agents sont attachs aux nuds et connects lun lautre, ce qui reprsente un
change de donnes (cnnexion TCP, flux UDP).
Les applications qui gnrent le trafic de donnes selon certaines lois (CBR, VBR), et se
servent des agents de transport [17].
A.7 Traitement des rsultats dans NS-2

Aprs le droulement de la simulation, NS-2 donne un fichier trace qui est un fichier texte
contenant tous les vnements de la simulation. Le traitement de ce fichier permet den
soustraire linformation souhaite [40]. Chaque vnement est reprsent dans le fichier trace
95
Annexes -
avec une ligne qui contient douze champs. Le tableau A.2 donne une vision des la structure
dune ligne du fichier trace sous NS-2 :
Event Time From To Pkt Pkt Flags Fid Src Dst Seq Pkt
node node type size addr addr num id
Tab A2 : Structure dune ligne du fichier trace.
1. Action effectue sur le paquet. Un + signifie que le paquet est reu dans une file, un
- signifie que le paquet quitte la file, un s signifie que le paquet est envoy, un d
signifie que le paquet est jet (drop) et un r signifie que le paquet est rceptionn par
un agent.
2. Instant o laction est effectue.
3. Nud de dpart du lien concern.
4. Nud darrive du lien concern.
5. Type de paquet.
6. Taille du paquet en bytes.
7. Flags.
8. Identificateur de flux.
9. Agent de dpart.
10. Agent darrive.
11. Numro de squence.
12. Identificateur unique pour chaque paquet.
La figure A4 illustre un exemple dtaill dune ligne dun fichier trace sous NS-2 :
+ 0 .002048 1 3 cbr 256 --------------- 0 1.0 7.0 8 9

Time Id
Type Type Taille Num
flux
vnement trafic paquet seq
+ enqueue paquet
- dequeue
r receive Source dest
d drope Adresse de la source et
s send Source et dest destination du paquet
Entre lesquelles Id unique
lvnement est pass du paquet
Fig A4 : Exemple de fichier trace.
En plus des fichiers traces quoffre le simulateur NS-2, il permet de visualiser les
vnements de la simulation travers une interface graphique NAM (figure A5) :
96
Annexes -
Fig A5 Fentre de visualisation de NAM.
A.8 Structure dun nud mobile sous NS-2

La figure A6 dcrit la structure dun nud sans fil dans NS-2.
Elle montre le travail interne du flux dans le nud sans fil. Le nud reoit toujours des
paquets l'entre du nud. Le paquet passe par le classificateur o son champ d'adresse est
examin. Les agents sont les connecteurs. Quand les connecteurs reoivent les paquets, ils
excutent certaines fonctions et livrent les paquets vers leurs voisins ou les ignorent. Il existe
plusieurs types de connecteurs effectuent diffrentes fonctions, par exemple, l'agent, Link
Layer, couche MAC et d'interface rseau.
Fig. A6 : Structure dun nud mobile sous NS-2.
97
Annexes -
A.9 Les diffrents modles de mobilit sous NS-2

Puisque les rseaux ad hoc (MANET) sont souvent analyss par des simulations, leurs
rsultats dexcution dpendent lgrement des paramtres de rseau de simulation. Ainsi,
lvaluation dun protocole de routage ad hoc dpend de choisir soigneusement un modle de
mobilit pour illustrer les mouvements ralistes des utilisateurs.
Les modles de mobilit dentit reprsentent les nuds mobiles dont les mouvements
sont indpendant lun de lautre. Dautre part, les modles de mobilit de groupe reprsentent
les nuds mobiles dont les mouvements dpendent lun de lautre et ils tendent tre plus
ralistes dans les applications impliquant la communication de groupe [20].
A.9.1 Le modle Radom Way Point (RWP)

Dans ce modle la mobilit des nuds est typiquement alatoire et tous les nuds sont
distribus uniformment dans lespace de simulation. En effet il consiste en :
Le placement dun certain nombre de mobiles dans une zone carre de laquelle ils ne
peuvent sortir.
Laffectation dune position, dune vitesse et dune destination initiale chaque mobile.
Le droulement proprement dit de la simulation, o chaque fois que les mobiles
atteignent leur destination dans le carr, ils repartent vers une autre destination choisie
alatoirement aprs un ventuel temps de pause. Du fait de la simplicit de ce modle, il
nest pas toujours adapt pour dcrire des comportements de mobilit complexes [20].
A.9.2 Le modle Random Walk

Ce modle est dvelopp pour imiter un mouvement imprvisible. Un nud mobile dans
ce modle se dplace de son endroit courant un nouvel endroit en choisissant alatoirement
une direction et une vitesse suivant lesquelles il se dplace. La nouvelles vitesse et direction
toutes les deux sont choisies dans des gammes prdfinies, [speedmin, speedmax] et [0, 2]
respectivement. Un nud mobile atteignant la frontire de simulation, rebonds avec langle
dtermin par la direction entrante et puis continue le long du nouveau chemin.
A.9.3 Le modle alatoire de direction (random direction model)

Il vient comme une modification sur le modle de RWP. Dans RWP, la probabilit dun
nud mobile de choisir une nouvelle destination situe au centre du la zone de simulation ou
une destination qui ncessite un dplacement par le centre est haute. Ce modle essaye
dallger ce comportement, fournissant un nombre constant de voisins dans toute la
simulation. Les nuds mobiles choisissent une direction alatoire suivant laquelle ils se
dplacent en tant que modle de mobilit de random walk, o ils se dplacent vers la frontire
de la simulation dans cette direction. Une fois que la frontire est atteinte, le nud mobile fait
une pause pendant le temps indiqu, choisit une autre direction angulaire entre (0 et 180)
continue alors le processus.
98
Annexes -
Conclusion
Dans cette partie, nous avons prsent une brve description de l'outil de simulation NS-2.
Nous avons dcrit les langages utiliss dans ce simulateur, citons tcl et OTcl. Puis nous avons
dcrit l'architecture gnrale de son utilisation, l'arborescence et la hirarchie des diffrentes
classes existantes. Un point important est visualis, c'est l'tude et la cration des
environnements mobiles dans ce simulateur ainsi l'extraction et le traitement des rsultats.
99
Annexes -
Annexe B : Langage AWK
B.1 Prsentation
AWK est un outil qui permet d'effectuer des recherches, simples ou complexes, dans des
fichiers textes. C'est un langage de programmation datant de 1977, date de son apparition
dans le monde Unix. Il tire son nom des trois programmeurs qui l'ont dvelopp : Alfred V.
Aho, Peter J. Weinberger et Brian W. Kernighan [49]. Cette utilitaire a t cre dans le but de
remplacer les commandes grep et sed. Sa grande souplesse lui a permis de connatre un
succs immdiat. Et de nouvelles versions sont apparues au fil du temps : nawk et gawk.
Aujourd'hui encore, cet utilitaire est toujours utilis du fait de sa ressemblance avec le
langage C, de sa souplesse et de sa prsence sur la majorit des systmes d'exploitation Unix.
Il est encore utilis en administration systme et dans les scripts Shell en tant que commande.
Awk fonctionne en lisant des donnes. Ces donnes peuvent tre ainsi traites par
l'utilisateur. Utilisateur qui peut choisir de lire des donnes provenant de fichiers ou du canal
de l'entre standard. Par consquent, awk a pour but premier de jouer un rle de filtre bien
qu'il ne se limite pas qu' cela.
B.2 Syntaxe gnrale d'un programme awk

Un programme awk est constitu de trois grandes sections :
La section initiale :
Les commandes qu'elle contient sont lues et traites avant la lecture du fichier en entre.
C'est le bon endroit pour initialiser des variables par exemple ou pour ouvrir des fichiers
auxiliaires. Elle commence par le mot clef BEGIN et est entoure d'une paire d'accolades.
La section terminale :
Comme son nom l'indique, la section terminale n'est traite qu'une fois le fichier en entre
ferm. Typiquement, c'est l'endroit idal pour fermer des fichiers auxiliaires ou raliser des
statistiques. Bref, tout ce qui ne peut se faire qu'une fois toutes les donnes connues et
traites. Elle est introduite par le mot clef END et est entoure d'une paire d'accolades.
La section des rgles :

C'est la section o nous mettons les lignes de code de traitement du fichier. Elle est
appele ainsi, car, nous spcifions des rgles d'activation pour les ordres de AWK. Chaque
ensemble de commandes est ceint d'une paire d'accolades et prcd d'une porte. Celle ci
peut tre sous la forme d'une expression rgulire entoure par des slash / mais galement
toute expression arithmtique permettant de discriminer les lignes, par exemple, des
conditions sur le nombre de champs. Elle peut galement tre vide, auquel cas, les
commandes seront appliques toutes les lignes.
100
Annexes -
B.3 Excution d'un programme AWK

Il y a deux faons gnrales d'excuter des instructions AWK [31]:
1. pour des applications simples :

Linstruction d'excution est sous la forme :
awk 'program' fichier1 ... fichier n
'program': est une liste d'instructions se prsentant sous la forme : Pattern action 1;
action 2; ... ; action n.
fichier1 ... fichier n:liste des fichiers de donnes en entre.
La commande excute le programme, fichier par fichier, sur chaque ligne de faon
squentielle, ou s'il n'y a pas de fichier en entre, prend le standard input en tant que fichier
d'entre.
2. pour des applications plus complexes :

On ouvre un fichier d'instructions awk et l'excution s'effectue par la commande :
awk -f fichierprog liste optionnelle de fichiers de donnes.
fichierprog : est le fichier d'instructions awk enregistr sous l'extension .awk.

La commande excute squentiellement le programme se trouvant dans le fichier
programme sur chaque ligne des fichiers en entre.
101
Annexes -
Annexe C : codes source
C.1 script Tcl
# Define optioNS
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 16 ;# number of mobilenodes
set val(rp) AODVD/AODV ;# routing protocol
set val(x) 1000 ;# X dimension of topography
set val(y) 1000 ;# Y dimension of topography
set val(stop) 40 ;# time of simulation end
Mac/802_11 set dataRate_ 5.5Mb ;# 802.11 data transmission rate

Mac/802_11 set basicRate_ 1Mb ;# 802.11 basic transmission rate
# parametres de QoS
Agent/AODV set QoS_factor 1 ;# activer /dsactiver le contrle dadmission.
Agent/AODV set req_bandwitdh 0.08 ;# bande passante demande.
Agent/AODV set req_delay 0.150 ;# dlai max ne pas dpasser.
# prparation des fichiers traces

set ns [new Simulator]
set tracefd [open simplecbr.tr w]
set fd [open freebw.tr w]
set namtrace [open simwrlscbr.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
# set up topography object

set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
#cration et configuration des noeuds.
$ns node-config -adhocRouting $val(rp) \

-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
102
Annexes -
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON\
-macTrace OFF\
-movementTrace OFF
for {set i 0} {$i < $val(nn) } { incr i } {

set node_($i) [$ns node]
}
# Dfinition des locations initiales des noeuds

for {set j 0} {$j <= 5 } { incr j } {
set posicion_x [expr ($j % 10) * 200 ]
$node_($j) set X_ $posicion_x
$node_($j) set Y_ 800.0
$node_($j) set Z_ 0.0
}
for {set j 10} {$j <= 15 } { incr j } {

set posicion_x [expr ($j % 10) * 200 ]
$node_($j) set X_ $posicion_x
$node_($j) set Y_ 200.0
$node_($j) set Z_ 0.0
}
$node_(6) set X_ 0.0
$node_(6) set Y_ 400.0
$node_(6) set Z_ 0.0
$node_(7) set X_ 0.0
$node_(7) set Y_ 600.0
$node_(8) set X_ 1000.0
$node_(8) set Y_ 600.0
$node_(9) set X_ 1000.0
$node_(9) set Y_ 400.0
#cration de quatre connexioNS de type cbr.
#cbr1 entre le noeud 6 et 9.

set udp1 [new Agent/UDP]
$ns attach-agent $node_(6) $udp1
set null1 [new Agent/Null]
$ns attach-agent $node_(9) $null1
$ns connect $udp1 $null1
set cbr1 [new Application/Traffic/CBR]
$cbr1 attach-agent $udp1
$cbr1 set packet_size_ 1000
103
Annexes -
$cbr1 set rate_ 0.08Mb

$ns at 15.0 "$cbr1 start"
$ns at 35.0 "$cbr1 stop"



#procedure pour afficher la bande passante libre toutes les secondes

proc record {} {
global fd NS node_ mac_ freebw_
set time 1.0
set free [[$node_(1) set mac_(0)] set freebw_]
set now [$NS now]
puts $fd "$now $free"
104
Annexes -
$ns at [expr $now+$time] "record"

}
$ns at 1.0 "record"
# definition des position initiales

#pour le visualisateur nam.
for {set i 0} {$i < $val(nn)} { incr i } {
$ns initial_node_pos $node_($i) 30
}
# fin de la simulation
for {set i 0} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$node_($i) reset";
}
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"

$ns at $val(stop) "stop"
$ns at 39.01 "puts \"end simulation\" ; $ns halt"
proc stop {} {
global NS tracefd namtrace fd
$ns flush-trace
close $tracefd
close $fd
close $namtrace
}
$ns run
105
Annexes -
C.2 Script Awk

BEGIN {
max_packet_id = 0;
totalreceved = 0;
PDR = 0.0;
totalsend = 0;
total_time = 0.0;
{
action = $1;
time = $2;
layer = $4;
type = $7;
id_paquet = $6;
if (id_paquet > max_packet_id )
max_packet_id = id_paquet ;
if ( action == "s" && layer == "AGT"){
if ( start_time[id_paquet] == 0 ) start_time[id_paquet] = time;
if (action != "D" ){
if (action == "r" && layer == "AGT") end_time[id_paquet] = time;
}else { end_time[id_paquet] = -1; }
if ((layer == "AGT") &&(action == "r")) totalreceved ++;
if ((layer == "AGT") && (action == "s")) totalsend ++;
106
Annexes -
END {
for ( id_paquet = 0; id_paquet <= max_packet_id; id_paquet++ )

{
start = start_time[id_paquet];
end = end_time[id_paquet];
end_to_end = end - start;
if ( start < end ){
total_time = total_time + end_to_end;
printf("%d %f %f %f \n", id_paquet, start, end,

end_to_end);
delay = total_time/totalreceved;
PDR = totalreceved/totalsend;
PLR = 1.0 - PDR;
printf("%f %f %f %f %d %d \n", delay, PDR, PLR,
totalreceved, totalsend);
107
Rsum
Lapprovisionnement en Qualit de Service (QoS) est lune des
problmatiques majeures poses dans les rseaux mobiles ad hoc(MANETs).
Une bonne solution de QoS est gnralement construite base de plusieurs
briques dont le routage avec QoS. Contrairement au routage au mieux , le
routage avec QoS permet de chercher des routes assurant une certaine QoS
par rapport une mtrique bien dfinie. Par consquent, il est mieux adapt
pour les applications multimdia ou temps rel.
Dans ce travail, nous nous intressons garantir le dlai de bout en
bout dans le protocole AODV. Notre protocole de routage ave QoS baptis
AODV-D (AODV with Delay constraints) a comme brique principale
lestimation du dlai par une file M/M/1/K, un contrle dadmission sera
effectu par la suite pour vrifier le dlai. Les rsultats prliminaires de
simulation sous NS-2 ont montr une amlioration significative des
performances selon les trois mtriques principales de la VoIP.
Mots cls: rseau ad hoc, IEEE 802.11, protocoles de routage, qualit de

service (QoS), AODV, simulateur NS-2.
Abstract
Quality of Service (QoS) provisioning is one of the major problems in
mobile ad hoc networks (MANETs). A good solution of QoS is generally built
upon several blocks, of whom QoS routing. Contrary to best effort ,
routing, QoS routing makes it possible to search routes ensuring QoS
according to a given metric. Consequently, it is more adapted for multimedia
or real time applications.
In this work, we are interested in guaranteeing end to end delay in the
AODV protocol. Our QoS routing protocol named AODV-D (AODV with
Delay constraints) has as principal building block delay estimation by an
M/M/1/K queue. Thereafter, an admission control is carried out to check the
delay. The preliminary results of simulation under NS-2 showed a significant
improvement of the performances according to the three principal metrics of
VoIP.
Keywords: ad hoc network, IEEE 802.11, routing protocols, quality of service

(QoS), AODV, NS-2 simulator.

2009 TIZI OUZOU Routage Avec QoS Dans AODV PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2009 TIZI OUZOU Routage Avec QoS Dans AODV PDF

Transféré par

Droits d'auteur :

Formats disponibles

Ministre de L'Enseignement Suprieur et de la Recherche Scientifique

Universit Mouloud MAMMERI de TIZI-OUZOU

Prsent pour obtenir le titre dingnieur dtat

Routage avec Qualit de

Anne 2008 -2009

My prayer and my sacrifice and my life and my death

A ma chre mre pour ses sacrifices depuis quelle

En premier lieu, je remercie le Bon Dieu de mavoir

Mes trs vifs remerciements vont lencontre de mes

Je remercie galement les membres du jury qui ont

Que toute personne qui, d'une manire ou d'une autre,

Chapitre I : Gnralits sur les rseaux sans fil

Chapitre II : Routage dans les rseaux mobiles ad hoc

Chapitre III : Qualit de service dans les rseaux mobiles ad hoc

Chapitre VI : Simulation et discussion des rsultats

2.1 : Modes de communication dans les rseaux.

3.1 : Exemple de besoins de QoS.

4.1 : Modlisation dun nud 802.11 par une file M/M/1/K.

5.1 : Structure des nuds AODV et AODV-D sous NS-2.

6.1 : Pile protocolaire mis en place

A.1 : Une simple utilisation de NS2.

2.1 Les principaux protocoles MANET.

3.1 : Les principaux codecs et leurs Vitesses dchantillonnage.

4.1 : Format du message RREQ dans AODV-D.

6.1. Paramtres de simulation utiliss.

A1 : Les principaux composants de NS-2.

Gnralits sur les rseaux sans fil

Gnralits sur les rseaux sans fil

2 Les rseaux sans fil

2.4 Classification des rseaux sans fil

2.4.1 Selon la zone de couverture

b) Rseaux locaux sans fil (WLAN)

c) Rseaux mtropolitains sans fil (WMAN)

d) Rseaux tendus sans fil (WWAN)

Catgorie WPAN WLAN WMAN WWAN

Tab 1.1 : La famille de lIEEE 802 sans fil.

2.4.2 Selon la topologie du rseau

Topologie totalement connecte

Lien sans fil

Fig. 1 .1 Topologie totalement connecte

Topologie station de base

Topologie routage interne

Topologie combine ou hybride

Fig. 1.4: Topologie hybride

2.4.3 Selon le mode de fonctionnement

Les rseaux sans fil

Les rseaux avec infrastructure Les rseaux sans infrastructure

Fig. 1.5: Classification des rseaux sans fil

a)Les rseaux avec infrastructure

Fig. 1.6 : Exemple de mode infrastructure.

b) Les rseaux sans infrastructure ou ad hoc

Fig. 1.7 : Exemple de mode ad Hoc.

3 Prsentation de la norme 802.11

Fig.1.8 : le modle de rfrence OSI.

APDU : Application Protocol Data Unit.

3.2 Les rseaux sans fil et le modle OSI

Fig. 1.9 :802.11 et le modle OSI.

3.3 Le standard IEEE 802.11

3.3.1 Couche physique

802.11 802.11b 802.11a/g Infra

Fig 1.10 : La couche PHYSIQUE dans le rseau sans fil.

FHSS : (talement de Spectre avec Saut de Frquences)

DSSS : (talement de Spectre Squence Directe)