KAMMOUN Sabeur

Cycle de formation des ingnieurs en Tlcommunications
Option :
Rseaux mobiles
Rapport de Projet de fin dtudes
Thme :
Implmentation de la QoS sur un

protocole de routage (multicast) Ad hoc
Ralis par :
Sabeur KAMMOUN
Encadrant :
M. Nabil TABBANE
Anne universitaire : 2005/2006
A mon pre,
A ma mre,
A mon frre et ma sur,
A mon oncle et toute sa famille,
A tous ceux qui m'aiment ; A tous ceux que j'aime,
Je ddie ce travail.
Remerciements
Mes sincres remerciements sadresse M. Nabil TABBANE pour son

encadrement et ses qualits humaines.
Je tiens remercier tous mes camarades et surtout Issa Konat AW pour son aide.
Je tiens aussi remercier tous mes enseignants de l'Ecole Suprieure des

Communications de Tunis pour leffort quils ont dploy durant ma formation.
Projet de fin dtude

Implmentation de la QoS dans un protocole de routage (multicast) ad hoc
Rsum
De nos jours, plusieurs travaux ont t mens sur les rseaux ad hoc afin dintgrer
les applications temps rel telles que la voix et la vido exigeant certaines contraintes au
niveau des ressources offertes en terme de dlai et de bande passante. Parmi
ces
applications temps rel, nous pouvons citer la vidoconfrence qui ncessite en plus la
communication de groupe.
La topologie dynamique des rseaux ad hoc a une influence importante sur la
qualit de service. Pour cela, et vue lmergence des applications temps rel, la QoS dans
les rseaux mobiles ad hoc devient un sujet de plus en plus important mais aussi dlicat.
Dans ce projet, nous avons implment laspect QoS sur les protocoles de routage
AODV et MAODV en considrant les contraintes de dbit, dlai et le couplage de ces
deux contraintes ensemble dans la recherche et ltablissement des routes. Nous avons
tudi lapport de ces mcanismes de QoS sur les trafics unicast et multicast.
Mots cls
Rseaux ad hoc, QoS, AODV, Multicast-AODV.NS-2
Table des matires
INTRODUCTION GENERALE......................................................................................................1
CHAPITRE I .....................................................................................................................................2
RESEAUX AD HOC ET QOS .........................................................................................................2
I.1 INTRODUCTION...........................................................................................................................2
I.2 ETAT DART................................................................................................................................2
I.2.1 Modlisation dun rseau ad hoc .......................................................................................3
I.2.2 Les applications des rseaux ad hoc ..................................................................................4
I.2.3 Les caractristiques des rseaux ad hoc ............................................................................4
I.3 PROTOCOLES DE ROUTAGE DANS LES RESEAUX AD HOC ........................................................5
I.3.1 Les protocoles de routage proactifs ...................................................................................5
I.3.2 Les protocoles de routage ractifs .....................................................................................5
I.3.3 Le protocole de routage AODV..........................................................................................5
I.4 QOS DANS LES RESEAUX AD HOC ...............................................................................................7
I.4.1 Les mtriques de QoS pour un environnement ad hoc .......................................................8
I.4.2 QoS au niveau routage .......................................................................................................9
I.4.3 Modles de QoS pour les rseaux ad hoc.........................................................................11
I.4 CONCLUSION ............................................................................................................................12
CHAPITRE II..................................................................................................................................13
LE PROTOCOLE DE ROUTAGE MAODV ...............................................................................13
II.1 GENERALISATION ...................................................................................................................13
II.2 DECOUVERTE ET MAINTENANCE DE ROUTE POUR ATTEINDRE LARBRE ................................16
II.3 CONSTRUCTION DE LARBRE ..................................................................................................17
II.4 LA MAINTENANCE DE LARBRE MULTICAST ...........................................................................19
II.4.1 la propagation priodique dun GRPH...........................................................................20
II.4.2 la maintenance de la connectivit entre les nuds voisins .............................................20
II.4.3 La slection du chef de groupes (group leader)..............................................................22
II.4.4 Rvocation des membres de groupe ................................................................................24
II.4.5 Fusion darbres...............................................................................................................25
II.5 CONCLUSION...........................................................................................................................27
CHAPITRE III ................................................................................................................................28
IMPLEMENTATION DE LA QOS AU NIVEAU ROUTAGE..................................................28
III.1 INTRODUCTION ......................................................................................................................28

III.2 IMPLANTATION DE LA CONTRAINTE DE DEBIT ......................................................................28
III.2.1 Extensions apports au message RREQ ........................................................................28
III.2.2 Estimation de dbit ........................................................................................................30
III.2.3 Fonctionnement de lalgorithme....................................................................................30
III.3 IMPLANTATION DE LA CONTRAINTE DE DELAI ......................................................................33
III.3.1 Extensions apports au message RREQ ........................................................................33
III.3.2 Estimation de dlai ........................................................................................................34
III.3.3 Fonctionnement de lalgorithme....................................................................................35
III.4 COUPLAGE DES DEUX CONTRAINTES.....................................................................................36
III.5 CONCLUSION .........................................................................................................................37
CHAPITRE IV ................................................................................................................................38
EVALUATION DES PERFORMANCES ....................................................................................38
IV.1 INTRODUCTION ......................................................................................................................38
IV.2 LE MODELE DE TRAFIC ..........................................................................................................38
IV.3 LE MODELE DE MOBILITE ......................................................................................................39
IV.4 PARAMETRES A EVALUER .....................................................................................................39
IV.4.1 Dlai moyen de bout en bout..........................................................................................39
IV.4.2 Taux de paquets livrs avec succs................................................................................40
IV.4.3 Dlai dtablissement dune route .................................................................................40
IV.4.4 Trafic de contrle...........................................................................................................40
IV.5 PARAMETRES DE CONTEXTE DE SIMULATION .......................................................................41
IV.6 RESULTATS ET INTERPRETATIONS ........................................................................................42
IV.6.1 Effet de la contrainte de dbit ........................................................................................42
IV.6.2 Effet de la contrainte de dlai ........................................................................................48
IV.6.3 couplage des deux contraintes ensembles......................................................................53
IV.7. CONCLUSION.........................................................................................................................58
CONCLUSION GENERALE.........................................................................................................59
BIBLIOGRAPHIES ........................................................................................................................61
ACRONYMES.................................................................................................................................63
ANNEXE 1 .......................................................................................................................................64
ANNEXE 2 .......................................................................................................................................72
ANNEXE 3 .......................................................................................................................................74
Liste des figures
Figure 1.1 : Modlisation dun rseau ad hoc .....................................................................................3

Figure 1.2 : Le changement de la topologie des rseaux ad hoc .........................................................3
Figure 1.3 : Nud cur en CEDAR .................................................................................................10
Figure 2.1: Arbre de groupe multicast...............................................................................................14
Figure 2.2 : Construction de la table de routage unicast ...................................................................14
Figure 2.3 : Construction de la table du group leader .......................................................................15
Figure 2.4 : Les oprations de jointure de larbre, propagation des messages RREQ-J et RREP-J ..18
Figure 2.5 : Propagation des MACT et construction des tables de routage multicast.......................19
Figure 2.6 : Rparation darbre .........................................................................................................21
Figure 2.7 : Slection du group leader 1re cas.................................................................................22
Figure 2.8 : Slection du group leader 2me cas...............................................................................23
Figure 2.9 : Slection du group leader 3me cas...............................................................................24
Figure 2.10 : Procdure self prune ..............................................................................................25
Figure 2.11 : Fusion darbres.............................................................................................................26
Figure 3.1 : Premire extension apporte au message RREQ ...........................................................29
Figure 3.2 : Deuxime extension apporte au message RREQ .........................................................29
Figure 3.3 : Cas o il nexiste pas de chemin enregistr ...................................................................31
Figure 3.4 : Cas o le table de routage enregistre un chemin............................................................33
Figure 3.5 : Extensions apporte au message RREQ pour lestimation du dlai ..............................34
Figure 3.7 : Recherche dun chemin qui rpond la contrainte de dlai ..........................................36
Figure 4.1 : Trafic de contrle en fonction de la vitesse en respectant la contrainte de dbit ...........42
Figure 4.2 : Dlai dtablissement dune route en fonction de la vitesse en
respectant la contrainte
de dbit ..............................................................................................................................................44
Figure 4.3 : Dlai dtablissement dune route en fonction du temps avec contrainte de dbit ........44
Figure 4.4 : Taux de paquets livrs avec succs en fonction de la vitesse en respectant la . contrainte
de dbit ..............................................................................................................................................45
Figure 4.5 : Taux de paquets livrs avec succs en fonction du temps avec contrainte de dbit ......46
Figure 4.6 : Dlai moyen de bout en bout en fonction de la vitesse en respectant la contrainte de
dbit ...................................................................................................................................................47
Figure 4.7 : Dlai moyen de bout en bout en fonction du temps avec contrainte de dbit................48
Figure 4.8 : Trafic de contrle en fonction de la vitesse en respectant la contrainte de dlai ...........48
Figure 4.9 : Dlai dtablissement dune route en fonction de la vitesse en respectant la contrainte
de dlai ..............................................................................................................................................49
Figure 4.10 : Dlai dtablissement dune route en fonction du temps avec contrainte de dlai .....50
Figure 4.11 : Taux de paquets livrs avec succs en
fonction de la vitesse en respectant la
contrainte de dlai .............................................................................................................................51

Figure 4.12 : Taux de paquets livrs avec succs en fonction du temps avec contrainte de dlai.....51
dlai ...................................................................................................................................................52
Figure 4.14 : Dlai moyen de bout en bout en fonction du temps avec contrainte de dlai ..............53
Figure 4.15 : Trafic de contrle en fonction de la vitesse en respectant les contraintes de dlai et de
dbit ...................................................................................................................................................53
Figure 4.16 : Dlai dtablissement dune route en fonction de la vitesse en respectant les.............54
contraintes de dbit et de dlai ..........................................................................................................54
Figure 4.17 : dlai dtablissement dune route en fonction du temps avec contraintes de dbit et de
dlai ...................................................................................................................................................54
Figure 4.18 : Taux de paquets livrs avec succs en fonction de la vitesse en respectant les
contraintes de dbit et de dlai ..........................................................................................................55
Figure 4.19 : Taux de paquets livrs avec succs en fonction du temps avec contraintes de dbit et
de dlai ..............................................................................................................................................56
Figure 4.20 : Dlai moyen de bout en bout en fonction de la vitesse en respectant les contraintes de
dbit et de dlai..................................................................................................................................56
Figure 4.21 : Dlai moyen de bout en bout en fonction du temps avec contraintes ..........................57
de dbit et de dlai.............................................................................................................................57
Liste des tableaux
Tableau 1 : Paramtrage du contexte de simulation ............................................................ 41

Tableau 2 : Environnement de simulation ........................................................................... 41
Introduction gnrale
supcom
Introduction gnrale
Les concepteurs et les fournisseurs de services dans le domaine des tlcoms ont choisi d'investir
dans l'intgration de la qualit de service (QoS) pour les rseaux filaires. Au dbut, les rseaux
sans fil prsentaient beaucoup de difficults cause de leurs caractristiques principales telles
que le dynamisme de la topologie et les limites de la bande passante.
On distingue deux classes de rseaux sans fil; les rseaux avec infrastructure qui utilisent
gnralement le modle de la communication cellulaire, et les rseaux sans infrastructures dits ad
hoc.
A loppos des rseaux cellulaires, un rseau mobile ad hoc peut tre dfini comme une
collection d'entits mobiles interconnectes par une technologie sans fil formant un rseau
temporaire sans l'aide de toute administration ou de tout support fixe. Les rseaux ad hoc
peuvent tre relis d'autres catgories de rseaux (LAN, WAN,) et donc ils sont trs utiles
pour les communications de groupe. De nos jours, plusieurs travaux ont t mens sur de tels
rseaux afin d'intgrer les applications temps rels telles que la voix ou la vido exigeant
certaines contraintes au niveau des ressources offertes en terme de dlai et de bande passante.
Parmi ces applications temps rels, nous pouvons citer la vidoconfrence qui ncessite en plus
la communication de groupe.
Dans notre travail nous avons choisi un protocole de routage utile pour les communications de
groupe qui est le protocole MAODV : Multicast Ad hoc On Demand Vector distance. A ce
protocole, nous avons apport des modifications afin d'implmenter les contraintes de dbit et de
dlai exiges pour les applications temps rels.
L'objectif de ce projet est d'implmenter la qualit de service sur les protocoles de routage
AODV et MAOV tout en respectant les contraintes de dbit, de dlai et le couplage des deux.
Notre rapport est organis de la faon suivante :
Nous avons effectu, dans le premier chapitre, une tude bibliographique sur les rseaux mobiles
ad hoc, et recens les mcanismes de qualit de service existants.
Dans le deuxime chapitre nous allons analyser les spcifications du protocole de routage
MAODV.
Quand au troisime chapitre, nous prsentons les diffrentes tapes de l'implmentation de la
QoS dans les protocoles AODV et MAODV.
Enfin, le quatrime chapitre traite l'analyse des rsultats de simulations effectues l'aide du
simulateur rseau NS-2.
Projet de fin dtude
Rseaux ad hoc et QoS
supcom
Chapitre I
I.1 Introduction
Les systmes de communication cellulaire sont bass essentiellement sur l'utilisation des rseaux
filaires (tel que Internet ou ATM) 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 dployable 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.
Les rseaux mobiles prsentent une architecture originale. En effet, l'attnuation des signaux
avec la distance, fait que le mdium peut tre rutilis simultanment en plusieurs endroits
diffrents sans pour autant provoquer de collisions, ce phnomne est appel la rutilisation
spatiale (Spatial Reuse) et il sert de base au concept de la communication cellulaire.
I.2 Etat dart

Un rseau mobile ad hoc, appel gnralement MANET (Mobile Ad hoc NETwork) [1], consiste
en une grande population, relativement dense, d'units mobiles qui se dplacent dans un territoire
quelconque et dont le seul moyen de communication est l'utilisation des interfaces sans fil, sans
l'aide d'une infrastructure prexistante ou administration centralise. Le rseau ad hoc est une
Projet de fin dtude
supcom
collection de nuds mobiles formant un rseau temporaire a topologie variable et fonctionnant

sans station de base et sans administration centralise.
Les rseaux appels GSM ne reprsentent pas des rseaux ad hoc, car la communication entre les
units passe obligatoirement par des stations de base du rseau filaire.
I.2.1 Modlisation dun rseau ad hoc
Un rseau 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 Et modlise
l'ensemble des connexions qui existent entre ces nuds.
Si e = (u,v) appartient Et, cela veut dire que les nuds u et v sont en mesure de communiquer
directement l'instant t.
La figure 1.1 reprsente un rseau ad hoc de 8 units mobiles sous forme dun graphe.
Unit mobile
Lien de communication
6
3
4
Figure 1.1 : Modlisation dun rseau ad hoc
La topologie du rseau peut changer tout moment (voir la figure 1.2), elle est donc dynamique
et imprvisible ce qui fait que la dconnexion des units soit trs frquente.
Aprs dplacement des nuds, la topologie du rseau de la figure 1.1 peut devenir un moment
donn comme suit :
Unit mobile
2
5
3
4
Figure 1.2 : Le changement de la topologie des rseaux ad hoc
Projet de fin dtude
supcom
Dans ce cas, lancienne route qui existait entre le nud 2 et le nud 8 est perdu car le lien entre
le nud 2 et le nud 5 est cass.
I.2.2 Les applications des rseaux ad hoc
Les applications qui vont s'orienter vers les rseaux ad hoc sont naturellement celles qui ne
peuvent se contenter d'une mobilit restreinte ou reposant sur une infrastructure existante. Nous
trouverons bien sr dans ces applications les rseaux militaires. Nous y trouverons galement les
rseaux d'urgence (incendies, tremblement de terre), et les rseaux temporaires d'exposition ou
correspondant un vnement particulier.
I.2.3 Les caractristiques des rseaux ad hoc
Les rseaux mobiles ad hoc sont caractriss par :
Une topologie dynamique : Les units mobiles du rseau, se dplacent d'une faon libre
et arbitraire. Par consquent la topologie du rseau peut changer, des instants
imprvisibles, d'une manire rapide et alatoire. Les liens de la topologie peuvent tre
unis ou bidirectionnels.
Une bande passante limite : Une des caractristiques primordiales des rseaux bass sur
la communication sans fil est l'utilisation d'un mdium de communication partag. Ce
partage fait que la bande passante rserve un hte soit modeste.
Des contraintes d'nergie : Les htes mobiles sont aliments par des sources d'nergie
autonomes comme les batteries ou les autres sources consommables. Le paramtre
d'nergie doit tre pris en considration dans tout contrle fait par le systme.
Une scurit physique limite : Les rseaux mobiles ad hoc sont plus touchs par le
paramtre de scurit, que les rseaux filaires classiques. Cela se justifie par les
contraintes et limitations physiques qui font que le contrle des donnes transfres doit
tre minimis.
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.
Projet de fin dtude
supcom
De telles caractristiques peuvent contrarier lintroduction de la qualit de service dans les

rseaux ad hoc.
I.3 Protocoles de routage dans les rseaux ad hoc

I.3.1 Les protocoles de routage proactifs
Les protocoles de routage proactifs pour les rseaux mobiles ad hoc, sont bass sur la mme
philosophie des protocoles de routage utiliss dans les rseaux filaires conventionnels. Les deux
principales mthodes utilises sont :
La mthode Etat de Lien ("Link State")
La mthode du Vecteur de Distance ("Distance Vector").
Les deux mthodes exigent une mise jour priodique des donnes de routage qui doit tre
diffuse par les diffrents nud s de routage du rseau.
Les protocoles les plus importants de Cette classe sont :
-Le protocole de routage DSDV
-Le protocole de routage FSR
I.3.2 Les protocoles de routage ractifs
Les protocoles de routage appartenants cette catgorie, crent et maintiennent les routes selon
les besoins. Lorsque le rseau a besoin dune route, une procdure de dcouverte globale de
routes est lance, et cela dans le but dobtenir une information spcifie, inconnue au pralable.
Les protocoles les plus importants de cette classe sont :
Le protocole de routage DSR.
Le protocole de routage TORA.
Le protocole de routage AODV.
I.3.3 Le protocole de routage AODV

Le protocole AODV [2] reprsente essentiellement une amlioration de l'algorithme DSDV. Le
protocole AODV, rduit le nombre de diffusions de messages, et cela en crant les routes lors du
besoin, contrairement au DSDV, qui maintient la totalit des routes.
L'AODV utilise les principes des numros de squence fin de maintenir la consistance des
informations de routage.
Projet de fin dtude
supcom
A cause de la mobilit des nud
s dans les rseaux ad hoc, les routes changent frquemment
ce qui fait que les routes maintenues par certains nud
s, deviennent invalides. Les numros de
squence permettent d'utiliser les routes les plus nouvelles (fresh routes).
De la mme manire que dans le DSR [14], l'AODV utilise une requte de route dans le but de
crer un
chemin vers une certaine destination. Cependant, l'AODV [2] maintient les chemins
d'une faon distribue en gardant une table de routage, au niveau de chaque nud de transit
appartenant au chemin cherch.
Un nud
diffuse une requte de route (RREQ) dans le cas o il aurait besoin de connatre un
chemin vers une certaine destination et qu'une telle route n'est pas disponible. Cela peut arriver:
Si la destination n'est pas connue au pralable, ou
Si la dure de vie du chemin existant vers la destination a expir ou le chemin est
devenu dfaillant.
Lorsque la destination reoit ce message, elle rpond par un RREP.
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.
A fin de maintenir des routes consistantes, une transmission priodique du message "HELLO"
est effectue. Si trois messages "HELLO" ne sont pas reus conscutivement partir d'un nud
voisin, le lien en question est considr dfaillant.
Le protocole AODV ne prsente pas de boucle de routage, en outre il vite le problme
"counting to infinity" de Bellman-Ford, ce qui offre une convergence rapide quand la topologie
du rseau ad hoc change.
Formats des messages RREQ :
Type
Rserv
Nombre de sauts
Identit
@ destination
Numro de squence destination
@ source
Projet de fin dtude
supcom
Type : 1
J : join flag ; rserv pour le multicast.
R : Repair flag ; rserv pour le multicast.
Rserv : envoy 0 ; ignor la rception.
Nombre de sauts : le nombre de sauts entre la source et le nud manipulant la requte.
Identit : un numro qui identifie dune manire unique le RREQ.
@ destination : ladresse IP de la destination
Numro de squence destination : Le dernier numro de squence reu au pass par la source
pour une route vers la destination
@ source : ladresse IP du nud qui a mis la requte.
Numro de squence source : le numro de squence courant utiliser dans lentre de la route
qui pointe vers le nud source de la requte.
Formats des messages RREP :
Type
Rserv
Taille prfixe
Nombre de sauts
@ destination
Dur de vie
L : si L = 1 alors il sagit dun message hello

U : update flag ; rserv pour le multicast.
Taille prfixe : si diffrent de zro, il spcifie que le saut suivant indiqu peut tre utilis pour
nimporte quel nud avec le mme prfixe (comme il est dfini par la taille prfixe) que la
destination.
Dure de vie : Le temps pendant lequel les nuds recevant le RREP considrent la route
valide.
I.4 QoS dans les rseaux ad hoc

La QoS reprsente le niveau de performance dun service offert par un rseau un utilisateur.
Pour introduire la QoS dans les rseaux filaires, lIETF a propos les modles "IntServ" [7] et
"DiffServ" [8]. Pour assurer la QoS, ces deux algorithmes n'ont qu' spcifier la mthode de
rservation de ressources.
Projet de fin dtude
supcom
Dans les rseaux ad hoc, tant donn le dynamisme de la topologie, il faut trouver une route
ayant suffisamment de ressources pour satisfaire les besoins de la QoS dune communication,
tout en optimisant lutilisation des ressources disponibles.
Le modle IntServ [7] savre donc inadapte lenvironnement ad hoc alors que le modle
DiffServ [8] semble le mieux adapt aux rseaux mobiles.
Il existe deux types d'algorithme traitant les mcanismes de la QoS dans les rseaux ad hoc :
Les algorithmes qui introduisent la QoS au niveau des protocoles de routage. On parle
alors de la QoS niveau routage.
Les algorithmes qui cherchent introduire la QoS indpendamment des protocoles de

routage. Ils sont bass sur les concepts "IntServ" et "DiffServ". Ils reprsentent le
modle gnral de la QoS dans les rseaux ad hoc.
I.4.1 Les mtriques de QoS pour un environnement ad hoc

La QoS se manifeste par un ensemble de paramtres qui sont soit qualitatives (qualit de la voix,
de l'image,) soit quantitatives (mesurs : dlai, dbit, gigue,).
Les mtriques les plus importants pour les rseaux ad hoc sont :
Dlai : Ce paramtre reprsente le dlai de bout en bout ncessaire pour transmettre un
paquet de donnes depuis la source vers la destination. C'est une mtrique additive.
Bande passante (Dbit) : Ce paramtre dfinit la quantit maximale de donnes quun lien
peut transmettre pendant un intervalle de temps donn. Cest une mtrique concave. Le
rseau doit rpondre cette contrainte dans la transmission de la vido.
Perte de paquet : Ce paramtre indique le taux de suspension de la transmission des paquets
errons. Ce paramtre est utile pour les applications Web, transfert de fichier, chat et
messagerie lectronique.
Variance de dlai (gigue) : Ce paramtre dcrit la variation de dlai de transmission entre les
diffrents paquets. Il est class parmi les mtriques additives. Le rseau doit respecter ce
paramtre lors de la transmission de la voix, la vido confrence etc.
Projet de fin dtude
supcom
I.4.2 QoS au niveau routage

I.4.2.1 Core-Extraction Distributed Ad hoc Routing Algorithm (CEDAR)
CEDAR [9] est un protocole de routage ractif avec qualit de service. Il rduit au maximum les
messages de contrle. Il est bas sur une lection dynamique dun sous ensemble de stations qui
forment un coeur de rseau stable. Ces stations sont appeles routeurs cur . Des
informations sur les liens stables disposant dune grande bande passante sont propages entre les
nuds cur. Le calcul des routes est effectu par ces nuds en utilisant des informations locales.
Utilis dans des rseaux de petite moyenne taille (de dizaines des centaines de nuds), il est
bas sur trois composantes essentielles :
Extraction dun coeur du rseau : un ensemble de nud
est dynamiquement choisi pour
calculer les routes et maintenir ltat des liens du rseau. Lavantage dune telle approche est
quavec un ensemble rduit de nud
s les changes dinformations dtat et de route seront
minimiss, vitant ainsi des messages supplmentaires circulant dans le rseau. En outre, lors
dun changement de route, seuls les nuds du cur serviront au calcul,
Propagation dtat de lien : le routage avec qualit de service est ralis grce la propagation
des informations sur les liens stables avec une grande bande passante.
Lobjectif est dinformer les nuds distants sur les liens de grande capacit, alors que les liens de
faible capacit sont connus au niveau local (les nuds nont pas une information sur la topologie
globale du rseau),
Calcul de route : celui-ci est bas sur la dcouverte et ltablissement dun plus court chemin
vers la destination satisfaisant la bande passante demande. Des routes de secours sont utilises
lors de la reconstruction de la route principale, quand cette dernire est perdue. La reconstruction
peut tre locale ( lendroit de la cassure), ou linitiative de la source.
Au lieu de calculer une route avec un minimum de saut, lobjectif principal de CEDAR est de
trouver un chemin stable pour garantir plus de bande passante. Dans ce protocole de routage, les
nud
s du cur du rseau auront plus de trafics grer, en plus des messages de contrle (pour
la dcouverte et la maintenance des routes). En outre, en cas de forte mobilit, la convergence de

lalgorithme est difficile atteindre.
Projet de fin dtude
supcom
Unit mobile
Nud coeur
2
Lien virtuel
6
3
4
Figure 1.3 : Nud cur en CEDAR
I.4.2.2 Ticket-Based QoS Routing
C'est un protocole de routage distribu [11], qui autorise des informations dtat imprcises
durant la phase de calcul de la route. Il permet de rduire la quantit des messages de routage
diffuse pour la dcouverte de la route, en publiant un certain nombre de tickets logiques.
Chaque message de dcouverte (ou dobservation) de route doit avoir au moins un ticket. Quand
un message arrive un nud, il peut tre divis en plusieurs messages dobservation, qui sont
relays vers les prochains sauts.
Chaque message fils contiendra un sous ensemble des tickets de son message pre.
Evidemment, un message ayant un seul ticket ne peut tre divis. Lors de larrive dun message
de dcouverte de route la destination, le chemin saut par saut est connu et les informations de
dlai ou de bande passante peuvent tre utilises pour effectuer la rservation de ressources pour
la route rpondant aux besoins de la qualit de service. Le nombre de tickets gnrs est fonction
de la prcision des informations dtats disponibles la source et les besoins de la qualit de
service de la communication. Plus de tickets sont publis dans le but daugmenter la chance de
trouver un chemin dsir.
Dans les rseaux filaires, une distribution de probabilit, selon des informations sur le dlai ou la
bande passante, peut tre calcule. Cependant, cela reste inappropri dans les rseaux ad hoc o
les liens sans fil sont sujets des cassures, o les informations dtats sont imprcises. Pour cela,
un modle simple a t propos pour lalgorithme Ticket Based.
Projet de fin dtude
10
supcom
Il utilise lhistorique et lestimation des variations du dlai, et une formule de lissage pour
calculer le dlai courant. Pour sadapter aux changements de topologie, lalgorithme autorise
diffrents niveaux de redondance de route. Il utilise aussi des techniques de rparation et de
reroutage pour la maintenance des routes. La rparation des routes se fait en utilisant des
reconstructions locales.
I.4.2.3 Multipath QoS Routing Protocol
Contrairement aux autres protocoles avec QoS, qui essayent de trouver un seul chemin entre la
source et la destination, le Multipath QoS Routing Protocol, permet de trouver plusieurs routes
qui fournissent collectivement suffisamment de ressources.
I.4.3 Modles de QoS pour les rseaux ad hoc
I.4.3.1 Flexible quality of service model for MANETs (FQMM)
Le modle FQMM [5] repose sur une architecture rseau plate (non hirarchique), constitue
dune cinquantaine de nuds mobiles, formant un domaine DiffServ [8]. Il combine les
proprits des modles filaires IntServ [7] et DiffServ, en offrant une mthode
dapprovisionnement hybride : par flux, pour les trafics prioritaires, et par classe pour les autres
trafics. Dans le rseau, les nuds peuvent avoir des rles diffrents suivant les trafics existants :
nud dentre du trafic, intermdiaire ou de sortie. Les nuds dentre permettent de marquer et
classifier les paquets, qui seront ensuite relays par les nuds intermdiaires suivant leurs PHB
(Per Hop Behavior), jusqu arriver au nud
destinataire. Ce modle repose essentiellement
sur la couche IP, o les fonctionnalits sont spares en deux grands plans : le plan relayage de
donnes et le plan contrle et gestion. Les techniques dordonnancement et de gestion de
mmoires tampons sont tudies. Dans ce modle, le protocole de routage est suppos fournir
des routes ayant suffisamment de ressources.
Lavantage dune telle approche est la possibilit dinterfacer le rseau avec lInternet, vu les
mcanismes de qualit de services offerts qui sont proches des protocoles filaires.
Cependant, plusieurs mcanismes ainsi que linteraction avec la couche MAC restent dfinir
pour sadapter aux conditions variables du rseau ad hoc.
I.4.3.2 Service differentiation in wireless ad hoc networks (SWAN)
SWAN [6] est un modle rseau sans tat bas sur des algorithmes de contrle distribus dans le
but dassurer une diffrenciation de services dans les rseaux ad hoc. Il offre la priorit (au
Projet de fin dtude
11
supcom
niveau paquet) aux trafics temps rel en contrlant la quantit de trafics best effort accepte par
nud. Pour accepter un nouveau trafic temps rel, le contrle dadmission sonde la bande
passante minimale disponible sur la route (valide et obtenu par un protocole de routage). Une
dcision la source est alors prise suivant la bande passante obtenue. Pour maintenir la qualit
de service des trafics dj accepts, le dbit des trafics best effort est rgul en utilisant les
mesures de dlais au niveau MAC comme paramtre. Un classificateur et un shaper permettent
de diffrencier les deux types de trafic. En cas de congestion, les bits ECN (Explicit Congestion
Notification) de lentte des paquets IP sont positionns pour permettre la source de re-initier le
contrle dadmission. Si la route ne dispose pas dassez de bande passante, le trafic est supprim.
Ainsi, SWAN permet de fournir une QoS logiciel (soft QoS).
Un flux prioritaire admis nest pas sr davoir des garanties pour lentire dure de la
communication, et peut tout moment tre viol par dautres demandes de trafics. Un
mcanisme de contrle de dbit des flux best effort nest pas lui seul suffisant pour offrir des
garanties aux applications temps rel. En outre, dans cette approche, le protocole de routage ainsi
que la couche daccs au mdium sont de type best effort.
I.4.3.3 Modle iMAQ
Le modle iMAQ [10] fournit le support des transmissions des donnes multimdia dans un
MANET [1]. Le modle inclut une couche ad hoc de routage et une couche de service logiciel
(Middleware). Dans chaque nud, ces deux couches partagent les informations et communiquent
afin de fournir les garanties de qualit de service aux trafics multimdia. Le protocole de routage
est bas sur la prdiction de la position des nuds (predictive location-based) et orient qualit
de service. La couche Middleware communique galement avec la couche application et la
couche rseau et essaye de prvoir le partitionnement du rseau. Pour fournir une meilleure
accessibilit aux donnes, il rplique les donnes entre les diffrents groupes du rseau avant
deffectuer le partitionnement.
I.4 Conclusion
Tous ces modles et ces protocoles ne peuvent pratiquement pas servir pour des applications qui
ncessitent des protocoles de routages adapts aux communications de groupes. Il faudra donc
introduire la QoS au niveau des protocoles de routage multicast qui sont les mieux adaptes pour
les applications de ce type. Nous allons dtaill dans le chapitre suivant les spcifications du
protocole de routage MAODV classique.
Projet de fin dtude
12
Le protocole de routage MAODV
supcom
Chapitre II
II.1 Gnralisation
MAODV [3] est un protocole de routage ractif pour les rseaux ad hoc ddi au trafic multicast.
Cest en fait un protocole obtenu par extension du protocole AODV, ce dernier est ddi au trafic
unicast dans les rseaux ad hoc. Le MAODV comme tout autre protocole de routage multicast
se base sur le concept de groupe. Rappelons quun groupe multicast est un ensemble de nuds
qui se communiquent les informations par diffusion slective dans un rseau topologie
dynamique tel que le rseau ad hoc. Le MAODV fait partie de la famille des protocoles "Treebased" c'est--dire quil respecte une structure arborescente pour livrer des paquets de donnes
pour un groupe multicast. Chaque groupe multicast possde une adresse multicast unique de
groupe. Selon les spcifications du MAODV, les groupes multicast sont organiss en une
structure arborescente (voir la figure 2.1) compose de membres de groupe et plusieurs routeurs,
qui ne sont pas membre de groupe mais doivent exister dans l'arbre pour relier les membres de
groupe. Nous dirons que les membres de groupe et les routeurs sont tous membres de larbre et
appartiennent au groupe de l'arbre. Associs chaque arbre multicast, le membre de groupe qui
construit le premier l'arbre est le chef du groupe pour cet arbre, et est donc responsabilis la
maintenance du groupe de l'arbre par une diffusion priodique de messages "Group-Hello"
(GRPH) dans tout le rseau. Le chef de groupe maintient galement le numro de squence du
groupe, qui est propag dans le rseau travers le message GRPH.
Projet de fin dtude
13
supcom
Figure 2.1: Arbre de groupe multicast
Chaque nud
dans le rseau peut maintenir trois tables. La premire est la table de routage
unicast dans laquelle, est enregistr le prochain saut servant router le trafic unicast vers d'autres
destinations (figure2.1). Habituellement, la destination est un nud
parmi les autres du rseau.
Un cas particulier qui peut se prsenter est lorsque ladresse de destination est une adresse
multicast, ce qui se produit quand le nud n'est pas un membre d'arbre multicast mais doit
envoyer des paquets de donnes multicast un groupe multicast.
(-:-) [source: prochain saut vers la source]

[-:-] [destination: prochain saut vers
la destination]
(1:1)
RREQ
(1:3)
RREP
[8:8]
Group leader
Membre de groupe
Membre de larbre
Figure 2.2 : Construction de la table de routage unicast
Projet de fin dtude
14
supcom
La seconde table est la table de routage multicast dans laquelle, sont enregistrs les prochains
sauts vers la structure arborescente de chaque groupe multicast du rseau. Dans cette table,
chaque entre reprsente une structure arborescente de groupe. Chaque nud qui appartient cet
arbre de groupe devrait maintenir de telles entres, avec sa propre identit comme : chef de
groupe, membre de groupe ou routeur. La construction de cette table est dtaille dans la section
II.3.
A chaque prochain saut est associ une direction qui est soit en amont ou soit en aval. Si le
prochain saut est un nud plus prs du chef de groupe alors la direction est ascendante (en
amont); autrement la direction est descendante (en aval). Le chef de groupe n'a aucun saut en
amont, alors que d'autres nuds dans l'arbre devraient avoir un et seulement un saut en amont.
La troisime table est la table du Chef de groupe "Group Leader Table". Elle enregistre ladresse
du groupe multicast courant avec ladresse du chef de groupe et le prochain saut vers ce chef de
groupe, et toutes ces informations sont reues travers les messages GRPH priodiquement
diffuses. La figure 2.3 illustre la construction de cette table et la diffusion des messages GRPH.
Envoie du message GRPH

[-:- ]
[6:8]
[6:3]
[destination:prochain saut
vers la destination]
[6:6]
Group leader
Membre de groupe
Membre de larbre
6
[6:6]
[6:6]
[6:5]
[6:6]
[6:9]
[6:4]
Figure 2.3 : Construction de la table du group leader
Projet de fin dtude
15
supcom
II.2 Dcouverte et maintenance de route pour atteindre larbre

Etant donn que tout nud du rseau quil soit membre ou pas dun groupe multicast peut
gnrer un trafic multicast, la dcouverte de route pour atteindre un nud multicast peut se faire
en deux tapes lorsque le nud metteur de donnes n'est pas membre de larbre :
) La premire tape :
Elle consiste trouver une route entre le nud metteur de donnes et un membre de larbre;
aprs que ce membre de larbre ait reu les paquets de donnes multicast, il les propage dans
tout l'arbre, atteignant ainsi chaque membre du groupe. Pour accomplir cette premire tape on
utilise le mcanisme spcifique AODV [2] pour la dcouverte et l'entretien de route pour
atteindre un nud.
Le nud metteur de donnes lance un paquet RREQ pour demander un itinraire ladresse
multicast du groupe. Habituellement, ce RREQ est identique au RREQ utilis dans AODV, sans
aucun champ joins ni diffusion dans le rseau, mais avec le "Group Leader Table". En effet le
nud source peut connatre dj un itinraire pour atteindre le chef de groupe en utilisant les
informations enregistres dans le "Group Leader Table". Le RREQ peut tre envoy dune
faon unicast vers le chef de groupe si c'est la premire fois que ce nud envoie le paquet
RREQ. Pendant la propagation de RREQ, la route inverse vers le nud source est construite
comme dcrit dans le protocole AODV. Tout nud nappartenant pas cet arbre multicast mais
ayant une route frache cette adresse multicast, ou n'importe quel membre de l'arbre avec le
chef de groupe connu peut rpondre ce RREQ avec un RREP. Tandis que le RREP est envoy
au nud source le long de la route inverse, chaque nud
intermdiaire et le nud
de source
mettent jour la route vers le membre de l'arbre avec l'adresse de destination qui est l'adresse de
groupe multicast. Cette mise jour est faite dans leur table de routage unicast. Pour cette
premire tape, le nud
de destination est un membre de l'arbre.
) La deuxime tape :
La deuxime tape est accomplie avec la construction de l'arbre multicast, qui est dcrite dans la
section II.3. Pendant l'expdition de paquets de donnes multicast, chaque nud
vrifie
d'abord sil est lui-mme membre de l'arbre multicast. Sil n'est pas un membre de l'arbre, il
vrifiera sa table de routage unicast pour trouver le prochain saut vers l'adresse multicast. S'il
Projet de fin dtude
16
supcom
trouve les informations, les paquets de donnes sont expdis vers le prochain saut sinon il
enverra un RREP au nud source pour que ce dernier initialise une nouvelle procdure de
dcouverte de route. Si le nud lui-mme est membre de larbre, il suivra sa table de routage
multicast pour expdier les paquets. Lors de lutilisation de la table de routage Unicast pour
expdition des paquets de donnes multicast, on utilise la dtection de la couche MAC pour
dtecter la rupture de lien sur les routes.
II.3 Construction de larbre

Les mmes messages RREQ et RREP utiliss dans AODV [2] sont adapts pour tre employs
pour la construction de l'arbre dans MAODV [3]. En outre, le message MACT est introduit pour
finir la dernire tape de construction de l'arbre. Lorsquun nud, nappartenant pas un groupe
multicast, veut rejoindre ce dernier, ce nud lance un message RREQ avec un champ Join
(RREQ-J). Avant d'envoyer RREQ-J, le nud cre une entre dans sa table de routage multicast
et s'identifie en tant que membre de groupe, mais avec une adresse de chef de groupe inconnue et
sans prochain saut ni en amont ni en aval. Si un nud de l'arbre nest pas un membre de groupe
et veut devenir membre de groupe, il change simplement son identit, enregistre dans sa table
de routage multicast en tant que routeur un membre de groupe.
Habituellement, RREQ-J est diffus dans le rseau, mais si le nud
peut obtenir des
informations sur le chef de groupe et les informations pour atteindre ce chef de groupe en
vrifiant sa propre Group Leader Table et que cest la premire fois qu'il envoie RREQ-J,
RREQ-J peut tre envoy dune faon unicast vers le chef de groupe. Pendant la propagation de
RREQ-J, la route inverse au nud source de la requte est tablie dans la table de routage
unicast. Quand un nud reoit un RREQ-J non dupliqu, seuls les membres de l'arbre avec un
numro de squence du groupe multicast suprieur ou gal celui du RREQ-J peuvent rpondre
au RREQ-J avec un RREP-J (RREP avec un champ Join ). Le renvoi de RREP-J le long de la
route inverse signifie que cette route peut tre une branche potentielle de l'arbre. Ainsi dans la
table de routage multicast, les informations sur le prochain saut en amont vers l'arbre sont mises
dans la mmoire cache sans ajouter un nouveau saut valide dans l'entre (figure 2.4). Si plus tard
le nud reoit un autre RREP-J indiquant une meilleure branche (c'est--dire un numro de
squence plus grand ou un nombre de saut plus petit au cas o le numro de squence est le
mme), il met les nouvelles informations en mmoire cache et propage le RREP-J vers le nud
source; dans le cas contraire il abandonne les derniers RREP-J.
Projet de fin dtude
17
supcom
Un nouveau message, MACT (Multicast Route Activation), est utilis pour greffer une branche
l'arbre multicast. Lorsque le nud source envoie RREQ-J et attend un temps spcifique gal
RREP_WAIT_TIME [13], il vrifie s'il a dj reu un quelconque RREP-J et mmoris les
informations correspondantes. Si oui, il envoie un MACT avec un champ Join MACT-J vers
le nud en amont mmoris qui va tre ajouter sa table de routage multicast. Chaque nud
recevant un message MACT-J devrait ajouter dans sa table de routage multicast, le nouveau
prochain saut en aval indiquant le nud auprs duquel il a reu le MACT-J (figure 2.5). Sil est
membre de l'arbre, alors la branche est finalement greffe ; sinon, il vrifiera sa propre mmoire
cache pour trouver un prochain saut potentiel en amont vers l'arbre et ajouter ce prochain saut
dans sa table de routage multicast, puis envoyer un MACT-J vers ce nud .
RREQ-J
RREP-J
[-]
prochain saut en amont

Mmoire cache
[-:-]
[1:3]
Group leader
[1:2]
Membre de groupe
[8]
[1:1]
[source:prochain saut vers la source]
[1:1]
[7]
[5]
[1:5]
Figure 2.4 : Les oprations de jointure de larbre, propagation des messages RREQ-J et RREP-J
Si le nud source du message RREQ essaye plusieurs fois (RREQ_RETRIES) de se joindre un

arbre de groupe, mais n'a pas reu de message RREP-J, alors cela signifie que le groupe
recherch nexiste pas dans le rseau ou bien que le nud source ne peut pas joindre le groupe
cause de la partition du rseau. Dans ce cas le nud source demandeur devient le premier nud
Projet de fin dtude
18
supcom
dans ce groupe et agit comme un chef de groupe pour maintenir le numro de squence du
groupe et la structure arborescente.
Lenvoi des paquets de donnes multicast se fait par diffusion dans tout larbre afin
dconomiser la largeur de bande. Mais nous ne savons pas si tous les voisins dans l'arbre
reoivent correctement les donnes car il ny pas de rservation de canal pour obtenir un
feedback de rception.
MACT-J
[-,-]
[Prochain saut en amont:

Prochain saut en aval]
Group leader
Membre de groupe
[7: 1 ]
1
[5]
[6: 5]
Figure 2.5 : Propagation des MACT et construction des tables de routage multicast
II.4 La maintenance de larbre multicast

La maintenance de l'arbre multicast est beaucoup plus complique que l'entretien de route
unicast. Cette complexit mane du fait que l'entretien inclut la propagation priodique du
message GROUP-HELLO (GRPH), entretien de la connectivit avec les voisins, le choix du
Chef de groupe, la rvocation d'adhsion, et la fusion d'arbres.
Projet de fin dtude
19
supcom
II.4.1 la propagation priodique dun GRPH

Le chef de groupe doit priodiquement diffuser un message GRPH du groupe dans tout le rseau
entier, pour indiquer l'existence de ce groupe et de son tat actuel. En recevant le message de
GRPH, chaque nud met jour sa table de chefs de groupes (Group Leader Table) indiquant le
chef de groupe et la route vers ce chef de groupe.
Alors le nud qui n'est pas un membre d'arbre retransmet le GRPH reu pour la premire fois.
Un nud membre d'arbre qui reoit un message GRPH de ses propres nuds en amont peut
utiliser le GRPH pour mettre jour leur numro de squence courant du groupe, chef de groupe
courant et la distance courante entre le nud et le chef de groupe, ce qui exige que le GRPH soit
propag tape par tape dans le sens descendant de sa propre structure arborescente. Si un
membre de larbre reoit un message GRPH de la part dun nud autre que son propre nud en
amont, il cherche dabord linformation sur le chef de groupe enregistre dans sa table de routage
multicast. Si linformation est identique celle indique dans le message GRPH, alors ce GRPH
est rejet et le nud attente un prochain GRPH. Mais si linformation nest pas identique celle
indique dans le GRPH, il existe alors un autre arbre avec la mme adresse de groupe multicast
mais pas le mme chef de groupe, et ces deux arbres peuvent tre relis. Ainsi, le processus de
fusion d'arbres commence. La fusion d'arbre est lance par le membre d'arbre avec un chef de groupe
dont l'adresse est plus petite que l'adresse du chef indiqu dans le GRPH. Si l'adresse de chef est plus
grande que celle indique dans le message GRPH, le nud abandonne ce GRPH.
II.4.2 la maintenance de la connectivit entre les nuds voisins
Puisque le trafic multicast est diffus dans tout l'arbre, nous ne pouvons pas utiliser la dtection
de la couche MAC pour dtecter la rupture de liens dans l'arbre. Pour cela, les messages
priodiques Neighbor-Hello un seul saut sont utiliss. Et pour rduire le trafic de ces
messages, ces derniers sont envoys par diffusion avec des paquets de donnes. La connectivit
des voisins dans l'arbre est maintenue par une rparation locale quand le nud descendant d'un
lien dans l'arbre se rend compte que le lien est rompu en ne recevant aucun message diffus par
son voisin dans un temps spcifique (habituellement gale trois fois l'intervalle de temps du
message Neighbor-Hello . Aprs avoir dtect une rupture de lien, le nud en aval supprime
son prochain saut (seulement celui en amont) de sa table de routage multicast, et devient alors un
nud source dun message RREQ-J pour dcouvrir une nouvelle branche (figure 2.6). Ce
RREQ-J est diffrent du RREQ-J utilis pour le nud qui nest pas un membre d'arbre mais veut
Projet de fin dtude
20
supcom
se joindre un groupe multicast, du fait que ce RREQ-J doit tre diffuser avec une extension
contenant des informations additionnelles sur le hop-count vers le chef de groupe, afin
d'viter la vieille branche et ses propres nuds descendants de rpondre au RREQ-J, sans
compter la condition pour rpondre ce RREQ-J (seulement le membre d'arbre avec le mme ou
un plus grand numro de squence de groupe peuvent rpondre ce RREQ-J). Quand un
membre d'arbre reoit un RREQ-J avec extension, il doit vrifier son propre hop-count vers
le chef de groupe, seul le membre de l'arbre avec un hop count gal ou plus petit peut
rpondre. Et le processus devient ensuite le mme que celui vu dans la section II.3 (construction
de larbre).
3
7
1
5
9 [2,8:7]
8
RREQ-J
[-,-,:-] Table multicast
Liaison
[8,2:1]
8
9
2
10
10
Figure 2.6 : Rparation darbre
En plus de cela, si suite une rparation locale, les changements interviennent sur les
informations de groupe du nud source tels que le chef de groupe le numro de squence du
groupe et le hop-count vers le chef de groupe, ce nud enverra un GRPH avec un champ de
mise jour (GRPH-U) ses nuds descendants un un dune faon unicast pour mettre jour
leur information de groupe. Si le nud source essaye plusieurs fois (RREQ_RETRIES
tentatives) de rparer cette branche, mais ne reoit pas de rponse RREP-J, alors une partition
Projet de fin dtude
21
supcom
d'arbre s'est produite. Ainsi un nouveau chef de groupe doit tre choisi pour cet arbre partitionn.
Le choix de chef de groupe est dcrit dans la section suivante (choix du Chef de groupe).Si ce
n'est pas le nud descendant mais le nud ascendant qui ralise la rupture de lien, le nud
ascendant supprime le prochain saut (un de ses liens descendants) dans sa table de routage
multicast. Si ce nud ascendant n'est pas un membre de groupe, il devient une feuille sans aucun
nud en aval, et si aprs a il garde encore cet tat, alors commence le processus de rvocation
self-prune dcrit dans la section (Rvocation des membres de larbre).
II.4.3 La slection du chef de groupes (group leader)
Un nouveau chef de groupe doit tre choisi pour l'arbre divis ou quand le chef de groupe retire
son adhsion au groupe. Quand le partitionnement d'arbre se produit, et le nud courant est un
membre de groupe, il devient le nouveau chef de groupe (figure 2.7). Sinon, il forcera un de ses
voisins d'arbre tre le chef de groupe. Tous ses voisins sont des nuds descendants, parce que
le nud divis n'a aucun nud ascendant comme le chef prcdent de groupe n'a aucun
ascendant non plus. Si le nud courant a un seul nud descendant, il supprime l'entre pour ce
groupe dans sa table de routage multicast pour indiquer quil n'appartient plus l'arbre, et envoie
un MACT avec un champ prune (MACT-P) vers ce nud descendant, indiquant qu'il quittera
l'arbre et que ce dernier a besoin dun chef (figure 2.8).
Group leader
Membre de groupe
7
1
9 [2,8:7]
8
2 [10:9]
[8,2:] 9
8
[10:9]
10
10
Figure 2.7 : Slection du group leader 1re cas
Projet de fin dtude
22
supcom
Si le nud courant a plus quun nud en aval, il slectionne un descendant, change sa direction
d'un nud en aval en un nud en amont, et envoie un MACT avec un champ de group
leader (MACT-GL) vers ce nud, pour indiquer qu'il existe une autre branches dans l'arbre et
que ce dernier a besoin dun chef. Ainsi le nud descendant peut recevoir un MACT-P ou un
MACT-GL de son nud ascendant.
En recevant un MACT-P de son ascendant, le nud supprime sa liaison ascendante de sa table
de routage multicast. En recevant un MACT-GL, le nud change la direction ascendante en une
direction descendante. Puis si ce nud est un membre de groupe, il devient le nouveau chef de
groupe. Sinon, il poursuit le mme processus jusqu' atteindre un membre de groupe qui devient
un nouveau chef de groupe. Une fois que le nouveau chef de groupe est choisi, il commence
maintenir l'arbre et diffuser priodiquement le message GRPH dans le rseau entier. S'il a un
quelconque nud en aval, il enverra galement un GRPH-U chaque nud descendant dune
faon unicast, pour indiquer le nouveau chef de groupe et mettre jour l'information du groupe
dans leur table de routage multicast.
Group leader
Membre de groupe
MACT-P
7
5
[9:7]
1
9
9
8
8
2
10
10
Figure 2.8 : Slection du group leader 2me cas
Projet de fin dtude
23
supcom
Group leader
Membre de groupe
MACT-GL
7
1
9 [2,8:7]
8
2 [10:9]

1
[8:2] 9
8
10
[9,10: ]
10
Figure 2.9 : Slection du group leader 3me cas
II.4.4 Rvocation des membres de groupe

Un membre de groupe, y compris le chef de groupe, peut retirer son adhsion au groupe tout
moment. Si ce nud est le chef de groupe, il change sa propre identit en un routeur, et un
nouveau chef de groupe doit tre choisi. Si le nud n'est pas le chef de groupe, d'abord il retire
son adhsion en changeant sa propre identit en un routeur, et puis vrifie s'il a un quelconque
nud en aval. S'il a des nuds descendants, il doit rester dans l'arbre pour relier les membres de
groupe. Sinon, il peut lancer la procdure self-prune pour se retirer de l'arbre multicast. Le
self-pruning provoque le dpart du nud de l'arbre multicast, ainsi elle doit mettre jour sa
table de routage multicast en supprimant les entres cette adresse multicast. Ainsi il envoie un
MACT-P son nud ascendant pour linformer qu'il n'appartient plus l'arbre. Si la rception
d'un MACT-P fait du nud ascendant une feuille et sil n'est galement pas un membre de
groupe, il peut se retirer de l'arbre de la mme faon. La procdure se termine quand le dernier
nud qui reoit un MACT-P est membre de groupe ou diffrent dune feuille (voir figure 2.10).
Bien que ce MACT-P soit identique celui utilis pour le choix de chef de groupe, ce MACT-P
est envoy dun nud en aval vers un nud en amont, alors que le MACT-P utilis pour le choix
de chef de groupe est envoy d'un nud en amont vers nud en aval.
Projet de fin dtude
24
supcom
Group leader
Membre de groupe
MACT-P
7
1
9 [2,8:7]
8
9 [8:7]
2 [10:9]
10
10
Figure 2.10 : Procdure self prune
II.4.5 Fusion darbres

La fusion d'arbre peut tre dtecte quand un membre d'arbre avec une plus petite adresse de
chef de groupe reoit un GRPH produit par un autre chef de groupe avec une plus grande adresse
pour le mme groupe.
Tout nud membre de l'arbre avec une plus petite adresse de chef de groupe peut initier la fusion
d'arbre. Le membre de l'arbre lance la fusion en envoyant, dune faon unicast, un RREQ avec
un champ repair (RREQ-R) vers le chef de groupe lui demandant la permission de
reconstruire l'arbre. Ce RREQ-R se propage d'un nud en aval vers un nud en amont jusqu'
atteindre le chef de groupe. Si le chef n'a pas autoris un nuds de reconstruire l'arbre, il peut
renvoyer un RREP avec un champ repair (RREP-R) ce nud source de la requte RREQR. Durant lenvoi du message RREQ-R, la route inverse au nud source demandeur est forme,
ainsi le RREP-R suit cette route inverse jusquau nud source demandeur. Un cas particulier est
que le chef lui-mme peut raliser qu'il y a un autre arbre pour ce groupe avec un chef de groupe
ayant une plus grande adresse. Dans ce cas-ci, le cycle RREQ-R et RREP-R est omis et si le chef
n'a permis aucun autre membre d'arbre de reconstruire l'arbre, il commencera le reconstruire.
La reconstruction de larbre commence quand le nud demandeur envoie dune faon unicast
un RREQ avec un champ join-and-repair (RREQ-JR) au chef de groupe avec une plus grande
adresse, puisque quand le nud demandeur reoit un GRPH de ce chef de groupe, il enregistre
Projet de fin dtude
25
supcom
dj la route vers ce chef de groupe dans sa table de chefs de groupe Group Leader Table ,
ainsi on utilise l'information dans la table de Chef de groupe pour atteindre l'autre arbre. Une fois
un membre de l'autre arbre atteint, le RREQ-JR est envoy dune faon unicast du nud
descendant vers le nud ascendant jusqu' ce que le chef de groupe soit atteint. Durant
lacheminement du RREQ-JR, la route inverse vers le nud source est tablie. Quand le chef de
groupe avec l'adresse plus grande reoit le RREQ-JR, il renvoie un RREP-JR au nud source
demandeur le long de la route inverse. Pendant lacheminement du RREP-JR, l'information de
groupe, telle que l'adresse de chef de groupe, le numro de squence du groupe, et le hopcount vers le chef de groupe est mise jour. Quand le RREP-JR circule dans l'arbre avec une
plus grande adresse de chef de groupe, il se propage simplement d'un nud en amont vers un
nud en aval. Si un nud non membre de larbre est atteint, ce nud devient un routeur pour le
nouvel arbre, ajoutant deux prochains sauts dans sa table de routage multicast, indiquant les
nuds ascendant et descendant correspondants.
Quand le membre d'arbre ayant la plus petite adresse de groupe est atteint, il ajoute le nud
partir duquel il a reu RREP-JR comme son prochain saut en amont, change lancien nud
ascendant une direction descendante. Puis le RREP-JR se propage d'un nud en aval vers un
nud en amont dans l'arbre avec l'adresse la plus petite de chef de groupe.
Group leader
Membre de groupe
RREQ-JR/RREP-JR
RREQ-JR/RREP-R
[8,2: ]
8
9
2
10
[10:9]
[8:2]
9
8
[10,9:1]
10
Figure 2.11 : Fusion darbres
Projet de fin dtude
26
supcom
chaque tape, le nud courant change la direction descendant en une direction ascendante
pour le prochain saut duquel il reoit le RREP-JR, change le nud en amont en un nud en aval,
et expdie le RREP-JR vers le vieux nud ascendant. Ainsi quand le RREP-JR atteint le chef de
groupe ayant une plus petite adresse, ce chef de groupe met jour un de ses propres nuds
descendants en un nud ascendant, et change son identit de chef de groupe en un membre de
groupe, ainsi le nouvel arbre est compltement tabli. Aprs ces tapes, lancien chef de groupe
devrait diffuser dune faon unicast le message GRPH-U ses nuds en aval, leur indiquant le
changement dinformation de groupe.
II.5 Conclusion
Le protocole de routage MAODV [3] est utile pour des applications tels que la vidoconfrence,
le travail de collaboration et les jeux distribus. Ce type dapplications, ncessite un certain
niveau de QoS (bande passante, dlai de transmission, ).
Le chapitre suivant dveloppe une mthode pour implmenter laspect QoS dans ce protocole.
Projet de fin dtude
27
Implmentation de la QoS au niveau routage
supcom
Chapitre III
III.1 Introduction
Dans cette partie nous dveloppons notre mthode pour limplmentation de la qualit de service
sur le protocole de routage MAODV [3] tout en respectant lune des contraintes de dlai ou de
dbit et quon va ensuite les coupler.
Nos algorithmes vont tre excuts au niveau de chaque nud jusquau traage de la route.
Lalgorithme consiste en une estimation de lune des deux contraintes au niveau dun lien. Si
cette contrainte est assure par ce lien, alors il est choisi pour construire un itinraire vers la
destination. Un nud peut estimer le dlai ou la bande passante au niveau dun lien en utilisant
les informations propages par les messages RREQ. Nous avons donc ajout des champs
supplmentaires au niveau du message RREQ fin de les utiliser dans la procdure de
lestimation du dlai ou de la bande passante.
III.2 Implantation de la contrainte de dbit

III.2.1 Extensions apports au message RREQ
Lorsquun nud reoit un RREQ, il va estimer la bande passante disponible au niveau de son
lien avec le nud source du RREQ. Pour ce faire, ce nud a besoin de connatre le temps de
transmission de ce paquet RREQ.
Projet de fin dtude
28
supcom
Nous allons donc ajouter au niveau du message RREQ un nouveau champ permettant le calcul
de ce temps. Linformation que peut apporter le paramtre enregistr dans ce champ est le
moment de lmission dun RREQ. En dautre terme, la rception dun RREQ, un nud peut
connatre, en plus du temps de son rception, le temps de son mission par le nud metteur de
ce mme RREQ.
La figure suivante montre lutilit de ce champ :
RREQ, ts
N1
ts
tr
N2
Figure 3.1 : Premire extension apporte au message RREQ
Deux vnements sexcutent au niveau des nuds N1 et N2 :

Emission du RREQ : A lmission du RREQ, N1 va remplir le nouveau champ par
linstant de lmission (ts).
Rception du RREQ : Lorsque le nud N2 reoit le message RREQ, il enregistre le
moment de cet vnement (tr) (CURRENT_TIME). Il va ensuite extraire linformation
qui lui permet de connatre le moment de lmission de ce message (ts) par N1. N2 peut
enfin calculer le temps de transmission (tr-ts) de ce message entre N1 et N2.
Pour pouvoir comparer entre ce quun lien peut offrir comme dbit et ce que la source demande,
nous allons ajouter au niveau du message RREQ un champ contenant le dbit demand par la
source (figure 3.2).
N1
RREQ, d1
N2
Figure 3.2 : Deuxime extension apporte au message RREQ
Aprs avoir estim le dbit que peut offrir le lien, N2 va extraire du message RREQ
linformation qui lui permet de connatre le dbit minimum demand par N1 (d1). Le nud N2
Projet de fin dtude
29
supcom
va finalement comparer entre ce qui est demand par N1 (d1) et ce que le lien peut offrir comme
dbit.
Nous allons ajouter au message RREQ deux champs qui contiennent le temps de lmission du
message et le dbit demand par la source. Ces extensions reprsentent en fait des informations
utiles pour le nud rcepteur du RREQ lui permettant destimer le dbit et de prendre la bonne
dcision pour le choix du lien en cours.
III.2.2 Estimation de dbit
Une valuation de dbit peut tre faite simplement en mettant des paquets RREQ et en mesurant
les dlais correspondants :
d N 1N 2 = t r t s
(3.1)
Le nud N2 peut maintenant estimer le dbit maximal sur le lien N1 N2 :
Dbit sur le lien =
T
d N 1N 2
(3.2)
T : Taille du paquet RREQ,

d N 1N 2 : Dlai de transmission du mme paquet entre deux nuds adjacents.
III.2.3 Fonctionnement de lalgorithme
Avant d'entamer la recherche, on consulte la table de routage pour voir s'il existe un chemin
menant vers la destination et satisfaisant la contrainte de dbit exige. Si oui, on lance le trafic de
donnes sur ce chemin. Dans le cas o un lien intermdiaire est bris, on lance le mcanisme de
maintenance de route.
Si un nud veut mettre des donnes, il va lancer la procdure de recherche d'un chemin vers la
destination selon la contrainte de dbit quil exige ;
Le nud source diffuse un paquet RREQ (au format intgrant la QoS) tous ses nuds voisins
voulant assurer avec eux sur le lien qui les spare un certain dbit exig. Si un nud voisin ne
dispose pas de chemin vers la destination dans sa table de routage, il effectue les oprations de
calcul de (3.1) et (3.2). Sil peut offrir le service demand par la source, il diffuse son tour le
paquet RREQ ses voisins et ceci jusqu' atteindre la destination (figure 3.3). Si par contre, on
trouve un chemin satisfaisant cette contrainte de dbit vers la destination dans la table de routage,
dans ce cas, on empreinte ce mme chemin pour envoyer les paquets de donnes.
Projet de fin dtude
30
supcom
Group leader
RREQ,d1,ts1
Membre de groupe
RREQ,d1,ts3
Membre de larbre
Figure 3.3 : Cas o il nexiste pas de chemin enregistr
Dans le cas prsent par la figure 3.3, le nud 3, en recevant le RREQ, calcule le dbit
maximum au niveau du lien entre le nud 1 et le nud 2 en utilisant ts1 et puis il compare le
rsultat trouv avec le dbit d1 demand par la source (nud 1). Si le dbit estim est suprieur
d1, il diffuse le message RREQ ses voisins (tant donne quil ne dispose pas de chemin vers la
destination dans sa table de routage). Le nud 8 (qui est un membre de larbre et donc il
reprsente la destination) effectue les mmes oprations que le nud 3 et sil peut offrir le dbit
demand par la source, il renvoi un RREP vers le nud 3. Cest ce moment que lalgorithme
enregistre ce chemin avec le dbit quil offre dans la table de routage du nud qui reoit le
RREP.
Enregistrement du chemin trouv dans la table de routage :
Nous avons ajout au message RREP un champ contenant le minimum des dbits au niveau des
liens constituant le chemin vers la destination. Ce champ est initialis par une valeur trs leve.
A la rception dun RREP, chaque nud enregistre dans ce champ le minimum entre lancienne
valeur et le dbit estim. Cette valeur va tre enregistre dans la table de routage (dans un
nouveau champ que nous avons appel dbit). Avant lexcution de lalgorithme, le champ dbit
de la table de routage est initialis par une valeur qui tend vers linfini.
Projet de fin dtude
31
supcom
Pour mieux comprendre cette procdure nous allons prsenter les tables de routage des nuds 1,
3 et 8 de la figure 3.4.
Avant excution de lalgorithme :
Table du nud 1 :
destination
@ du groupe multicast
Nombre de
Prochain
Numro de
sauts
saut
squence
Dlai de validit
dbit
X1
1000000000
Table du nud 3 :
Destination
Nombre de
sauts
Prochain
saut
Numro de
squence
Dlai de validit
dbit
X2
1000000000
Nombre de
Prochain
Numro de
Dlai de validit
dbit
sauts
saut
squence
X3
1000000000
Table du nud 8 :
destination
Aprs excution de lalgorithme :

Aprs excution de lalgorithme de la qualit de service, le champ dbit de chacun des tables de
routages va prendre les valeurs suivantes :
Table du nud 8 : 1000000000.
Table du nud 3 : le minimum entre 1000000000 et d8 ; d8 = min (1000000000, r8),
r8 reprsente le dbit estim par le nud 8.
Table du nud 1 : le minimum entre d3 et r3 ; d3 = min(d1,r3),
r3 reprsente le dbit estim par le nud 3.
Maintenant, aprs la mise jour des tables de routage, le nud qui veut mettre des paquets de
donnes peut utiliser le chemin enregistr dans sa table de routage menant vers la destination et
satisfaisant la contrainte de dbit exige.
Projet de fin dtude
32
supcom
Dans le cas de la figure 3.4, le nud 1 va consulter sa table de routage et comparer le champ
dbit (d3) avec d1 (dbit demand par la source). Si d3 est suprieur d1 le nud 1 lance le
trafic de donnes sur ce chemin.
Group leader
Membre de groupe
RREQ,d1,ts1
Membre de larbre
Figure 3.4 : Cas o le table de routage enregistre un chemin
III.3 Implantation de la contrainte de dlai

III.3.1 Extensions apports au message RREQ
Lorsquun nud lance la procdure de recherche dun chemin satisfaisant la contrainte de dlai,
les nuds voisins doivent effectuer des oprations de soustraction, de multiplication et de
comparaison pour sassurer que le chemin en construction rpond a la qualit de service
demand par la source.
Ces oprations vont tre effectues sur des variables quun nud doit les extraire du message
RREQ quil reoit. Nous avons donc ajout au message RREQ des champs qui renseignent sur le
temps de rception de ce paquet par le nud antcdent (figure 3.5), le dlai de transmission de
ce paquet et le dlai restant
Projet de fin dtude
33
tr1
N1
supcom
RREQ, tr1,dprop,dr
tr
N2
Figure 3.5 : Extensions apporte au message RREQ pour lestimation du dlai
Au niveau du nud N1, deux vnements sexcutent :

Rception dun RREQ : Lorsque le nud N1 reoit le message RREQ, il connat le
moment de cet vnement (CURRENT_TIME). N1 enregistre cette information dans le
nouveau champ.
Emission du RREQ : N1 achemine le paquet RREQ actualis vers le prochain saut (N2).
En recevant ce paquet RREQ, N2 peut calculer son dlai de transmission depuis la source (trtr1). Le rsultat obtenu va tre enregistr dans le champ dlai de transmission. Le champ qui
reprsente le dlai restant (dr) est initialis par le dlai minimum ne pas dpasser et
dcrmenter chaque fois que le message RREQ passe par un nud.
La diffrence entre lestimation du dbit et lestimation du dlai rside dans le fait que le dbit
est une mtrique concave alors que le dlai est une mtrique additive. En effet, pour lestimation
du dbit lalgorithme traite chaque lien part et donc ne prend pas en considration le temps de
traitement du message par les nuds intermdiaires. Alors que pour la prdiction du dlai,
lalgorithme va estimer le dlai du paquet de donnes de bout en bout.
A ce niveau deux problmes se posent :
Le calcul du temps de traitement du paquet RREQ.
Ladaptation de cette estimation pour les paquets de donnes.
III.3.2 Estimation de dlai
Nous avons choisi d'valuer les dlais en utilisant les paquets RREQ plutt que les paquets de
donnes afin d'viter de gnrer du trafic overhead supplmentaire sur le rseau.
Projet de fin dtude
34
supcom
Notons que le dlai d N 1N 2 entre un nud N1 et un nud N2 dpend de la taille des paquets. Une
correction doit tre faite afin de tenir compte de la taille des paquets de donnes.
Taille du paquet de donnes
d ' N 1N 2 = d N 1N 2
Taille
du
paquet
de
contrle
(3.3)
Ce dlai reprsente lestimation du dlai de transmission dun paquet de donne entre deux
nuds adjacents (figure 3.6)
dN0N1
N0
N1
dN1N2
N2
Figure 3.6 : Dlai de propagation
Dans la figure 3.6, le dlai de traitement du paquet de donne nest pas pris en compte. Nous
avons donc propos de calculer le dlai de traitement du paquet RREQ en utilisant la mthode
donne par la figure 3.5 (tr-tr1). De cette faon, le dlai d N 1N 2 reprsentera le dlai de
transmission du RREQ plus le dlai de son traitement dans N1. Aprs correction, ce dlai
reprsentera une estimation du NTT "node traversal time" qui est en fait un des paramtres
existant dans le protocole AODV [2] et qui est considr comme constant de 30 ms [12].
III.3.3 Fonctionnement de lalgorithme
Recherche d'un chemin entre la source et la destination selon la contrainte de dlai exige
Le nud source diffuse un paquet RREQ (au format intgrant la QoS) tous ses nuds voisins.
En recevant ce message, un nud intermdiaire estime le NTT. Pour sassurer que le chemin en
construction offre un dlai infrieur ou gal celui impos par la source, chaque nud
intermdiaire soustrait le NTT quil trouve du dlai maximum restant et ne pas dpasser dans le
reste du chemin. Si le rsultat est ngatif, ce chemin est abandonn. Si cest positif le processus
continu et ceci jusqu' atteindre la destination.
Projet de fin dtude
35
supcom
Group leader
Membre de groupe
RREQ tr, NTT, dr
RREQ tr1, NTT1, dr1
Membre de larbre
Figure 3.7 : Recherche dun chemin qui rpond la contrainte de dlai
La figure 3.7 illustre un exemple de recherche de route o la contrainte de dlai est respecte. En
recevant le RREQ, le nud 3 estime le NTT [12] (initialis 0), soustrait le rsultat du dr (NTTdr) (initialis par la contrainte de dlai ne pas dpasser) et vrifie le signe de la nouvelle valeur
de dr. Si cest positif, il achemine le RREQ avec les nouvelles valeurs (tr1, NTT1, dr1). Si non, il
abandonne le processus. Quand le nud 8 reoit ce RREQ, il calcule le NTT, soustrait le rsultat
du dr1 et vrifie si la nouvelle valeur du dr1 est positive. Si cest le cas, il rpond par un RREP.
Si non il abandonne le processus.
III.4 Couplage des deux contraintes

Pour rpondre aux deux contraintes de dlai et de dbit ensemble, chaque nud intermdiaire
doit estimer la bande passante dun lien et le NTT. Un nud source du RREQ doit donc diffuser
avec ce message toutes les informations qui permettent deffectuer cette estimation. Ces
informations correspondent au temps de rception du RREQ, temps dmission du RREQ (par le
mme nud), le NTT, le dlai restant ne pas dpasser dans la suite du chemin, et le dbit
minimum demand par la source.
Le processus de recherche est abandonn si lun des deux contraintes nest plus respectes.
Projet de fin dtude
36
supcom
III.5 Conclusion
Dans ce chapitre nous avons dcrit le droulement de lalgorithme qui permet dintroduire la
qualit de service au niveau du protocole de routage MAODV. Cette approche est applicable
aussi pour le protocole de routage AODV.
Dans la procdure de lintroduction de la contrainte de dbit, nous avons choisi dutiliser les
anciens chemins trouvs. Car si non, le trafic de contrle augmente et consommera plus de bande
passante. Dans ce cas, il devient difficile de trouver le chemin qui peut fournir le dbit exig.
Pour la contrainte de dlai, lenregistrement de ce paramtre au niveau de la table de routage de
chaque nud constituant le chemin, ncessite des oprations beaucoup plus complexes que dans
le cas de la bande passante. Ces oprations risquent daugmenter considrablement le dlai
dtablissement dune route. Nous avons donc choisi de ne pas modifier la structure de la table
de routage dans la procdure de recherche de route avec la contrainte de dlai.
Projet de fin dtude
37
Evaluation des performances
supcom
Chapitre IV
IV.1 Introduction
Lobjectif dans cette partie est dvaluer certains aspects de performances de notre approche et
de comparer avec le protocole de routage sans qualit de service. Pour ce faire, nous allons
utiliser le simulateur de rseaux NS-2 [4]. Les paramtres que nous allons valuer touchent la
capacit de service que peut offrir le rseau ad hoc savoir :
Le dlai moyen de bout en bout.
Taux de paquets livrs avec succs.
Nous allons examiner de prs quelques scnarios de simulation du protocole multicast et unicast
AODV [2] avant et aprs implmentation de la qualit de service. Les scnarios simuler vont
mettre laccent sur un paramtre troitement li la topologie dynamique des rseaux ad hoc.
Ce paramtre reprsente la vitesse de dplacement des nuds. Nous allons aussi tudier la
stabilit de ce protocole dot de la qualit de service tout en variant le temps de simulation.
IV.2 Le modle de trafic

Dans notre application, les scnarios utilisent des applications qui sont des sources de trafic
dbit constant (CBR : Constant Bit Rate). Ces sources de trafic modlisent la couche application
Projet de fin dtude
38
supcom
et se trouvent sur des agents de transports UDP (User Datagrammes Protocol) modlisant la
couche transport.
Dans notre application nous allons utiliser cinq agents source qui vont envoyer les donnes un
groupe mulicast dans le cas du MAODV [3]. Pour le cas de lAODV [2], nous allons considrer
cinq connexions. Les sources mettent des paquets de taille 512 octets avec un dbit de cinq
paquets par secondes et un temps de simulation de 590 s ce qui fait que le trafic total qui circule
dans le rseau est 14750 paquets, soit 7552 koctets.
IV.3 Le modle de mobilit

Dans chaque scnario, la mobilit des nuds est rgie par un modle pseudo alatoire appel
Random Point Model . Chaque nud est plac dans un emplacement alatoire au dbut de la
simulation (X0, Y0), ensuite, des instants choisis alatoirement, certains nuds, eux choisis
alatoirement, vont se dplacer selon le principe suivant :
choisir un nouvel emplacement (Xt, Yt),
choisir une vitesse de mouvement entre 0 et Vmax m/s,
se dplacer vers le nouvel emplacement,
rester en repos pendant une dure entre 0 et un temps de pause maximal en ms.
Ainsi, deux paramtres pourront affecter la mobilit des nuds dans le rseau : la vitesse Vmax
ou bien le temps de pause maximal : nous avons choisi de fixer le temps de pause 0s et faire
varier la vitesse entre 0 et 20m/s.
IV.4 Paramtres valuer

IV.4.1 Dlai moyen de bout en bout
Ce paramtre reprsente le dlai pass entre linstant o un paquet de donnes quitte lmetteur
et linstant o il est reu par la destination.
T (i) T (i)
End to End Delay : EED = 1000
paquets reus
AR
AS
Projet de fin dtude
39
supcom
TAR(i) : instant o le paquet de donne i est reu par lagent de transport de destination.
TAS(i) : instant o le paquet de donne i est mis par lagent de transport source.
Remarque : Pour le protocole MAODV [3], nous avons pris la moyenne des dlais entre la
source et chacun des membres de groupe.
IV.4.2 Taux de paquets livrs avec succs
Ce paramtre donne le pourcentage des paquets livrs leurs destinations par rapport aux
paquets mis par le rseau.
Packet Delivery Ratio : PDR =
paquet reus
paquets mis nombre de rcepteur
100
Dans le cas de lAODV [2] unicast, le nombre de rcepteur est gal un.
IV.4.3 Dlai dtablissement dune route
Ce paramtre renseigne sur le temps mis par le protocole de routage pour trouver une route. Il
peut nous donner une indication sur le temps de sjour dun paquet de donnes dans les buffers
dun nud avant dtre mis.
Ts (i) Tr (i)
Route Acquisition Latency : RAL = 1000
paquets reus
i
Ts(i) : instant o le paquet de donne i quitte le routeur.
Tr(i) : instant o le paquet de donne i est dlivr par lagent de transport la couche
rseau.
IV.4.4 Trafic de contrle

Ce paramtre nous informe sur la quantit des messages de contrles gnrs par les protocoles
de routage MAODV et AODV pour, la recherche, ltablissement et le maintient des routes.
Traffic OverHead :
Projet de fin dtude
TOH = RREQ, RREP, RERR
40
supcom
IV.5 Paramtres de contexte de simulation

Avant de lancer la simulation des scnarios, nous devons ajuster et fixer certains paramtres qui
vont constituer le contexte de notre simulation. Ces paramtres sont illustrs dans le tableau
suivant :
Temps de simulation
590s
Protocoles
AODV et MAODV
Nombre de scnarios pour un mme contexte
Temps de pause des nuds
0s
Taille de paquet de donnes
512 octets
Vitesse dmission
5 pkts/s
Taille du buffer des nuds
50 paquets
Nombre des nuds sources envoyant les donnes au groupe
multicast (nombre de connexions pour le AODV unicast)

Nombre des nuds constituant le groupe
10
Tableau 1 : Paramtrage du contexte de simulation
Pour les paramtres de la qualit de service, chaque source va imposer comme contrainte de dlai
ne pas dpasser 70 ms pour le MAODV et 60 ms pou le AODV et comme contrainte de bande
passante minimum qui doit tre disponible au niveau dun lien 50 kbps pour lunicast et le
multicast.
Lenvironnement de la simulation est dcrit dans le tableau suivant :
Machine
Pentium 4, 3 GHz, 256 Mo
Systme
Linux Red Hat 9.0
NS
Ns-allinone-2.26
Tableau 2 : Environnement de simulation
Au dbut de chaque simulation, les paramtres de chaque nud mobile doivent tre configurs
comme suit :
Type MAC : MAC/802_11
Taille du buffer (ifqLen)
Projet de fin dtude
41
supcom
Type dinterface de queue : Queue/DropTail/PriQueue
Type de canal : [new Channel/WirelessChannel]
Modle de propagation radio: TwoRayGround \
Type de lantenne : Antenna/OmniAntenna
Type de couche de liaison : LL
Nombre maximum de paquets dans le queue dinterface : 50
Trace de lagent : ON
Trace du routeur : ON
Trace du mouvement : OFF
Trace du MAC : OFF
En plus, la topographie du rseau consiste en une surface cre de dimension 1000 m x 1000 m
sur laquelle sont distribus 50 nuds. Nous avons vari la vitesse de dplacement des nuds de
0 20m/s, et pour chaque vitesse nous avons fait cinq simulations.
IV.6 Rsultats et interprtations

IV.6.1 Effet de la contrainte de dbit
IV.6.1.1 Trafic de contrle
nombre de paquets de controles (paquets
25000
toh_aodv
toh_maodv
toh_aodv_bw
toh_maodv_bw
20000
15000
10000
5000
0
0
10
15
20
vitesse (m/s)
Figure 4.1 : Trafic de contrle en fonction de la vitesse en respectant la contrainte de dbit
Projet de fin dtude
42
supcom
La figure 4.1 nous donne le nombre de paquets de contrle circulant dans le rseau. La premire
constatation est que le trafic de contrle augmente avec la vitesse de dplacement des nuds. En
effet, si la vitesse augmente la route dj enregistre dans la table de routage nest plus valable et
donc le nombre de paquet RERR (indispensable pour la maintenance de la route) va augmenter.
Cette figure montre aussi que le protocole MAODV dot de la qualit de service gnre plus de
trafic de contrle. Cela est d aux exigences de la source. En dautre terme, le risque de ne pas
trouver une route qui rpond aux exigences de lmetteur en dbit augmente ce qui fait que la
source va mettre plus de paquets RREQ pour la dcouverte dune route.
Nous constatons aussi que la marge de trafic entre les courbes toh_maodv_bw et toh_aodv_bw a
diminu par rapport celle entre les courbes toh_maodv et toh_aodv pour une mobilit comprise
entre 3 et 8 m/s. Cette diminution de la marge du trafic de contrle tait prvisible car non
seulement le mcanisme de maintien de larbre multicast gnre plus de paquets de contrle,
mais galement le mcanisme du protocole AODV classique ne sexcute que pour rparer les
ruptures de liens. Pour les protocoles AODV et MAODV avec contrainte de qualit de service, le
nombre dexcutions de la procdure de recherche de route va augmenter. Et ce nombre est plus
important en unicast quen multicast (car en unicast le nombre des nuds intermdiaires est plus
important ce qui fait que le temps dattente de la rponse "RREP_WAIT_TIME = 1 sec" risque
de sexpirer. Si cest le cas, la source relance la recherche en diffusant dautres paquets RREQ).
IV.6.1.2 Dlai dtablissement dune route
La figure 4.2 montre que le dlai dtablissement dune route devient plus important avec
laugmentation de la vitesse de dplacement des nuds. En effet, pour une mobilit rapide, la
topologie du rseau change rapidement et par consquence, les liens au niveau du chemin inverse
(pour la propagation des RREP) risquent dtre casss.
Cette figure montre aussi que laspect qualit de service a des effets ngatifs sur le
comportement de ce paramtre. En effet, il faut trouver une route qui rpond aux exigences de la
source. Pour ce faire, chaque nud intermdiaire est oblig deffectuer des oprations
supplmentaires par rapport au protocole best effort. Ces oprations permettent un nud de
chercher un lien satisfaisant la contrainte de dbit demande par lmetteur.
Finalement, nous constatons que le taux daugmentation de ce dlai est plus important pour le
MAODV (en comparant les courbe ral_maodv_bw et ral_maodv ce taux est environ 3 ms pour
des vitesse < 10 m/s et 6 ms pour des vitesses > 10 m/s) que pour le AODV (en comparant les
courbes ral_aodv_bw et ral_aodv il est autour de 6 ms pour des vitesse < 10 m/s et 13 ms pour
Projet de fin dtude
43
supcom
des vitesses > 10 m/s). Cela est d au fait que le nombre des nuds intermdiaires est plus
important dans le cas unicast.
30
ral_aodv
ral_maodv
ral_aodv_bw
ral_maodv_bw
dlai d'tablissement d'une route (ms)
25
20
15
10
0
0
10
15
20
vitesse (m/s)
Figure 4.2 : Dlai dtablissement dune route en fonction de la vitesse en respectant la

contrainte de dbit
35
ral_maodv_bw (5m/s)
ral_aodv_bw (5m/s)
30
ral_maodv_bw (20m/s)
ral_aodv_bw (20m/s)
25
20
15
10
0
0
50
100
150
200
250
300
350
400
450
500
550
590
temps de simulation (sec)
Figure 4.3 : Dlai dtablissement dune route en fonction du temps avec contrainte de dbit
La figure 4.3 donne le comportement de ce paramtre en fonction du temps de simulation.
Projet de fin dtude
44
supcom
Nous remarquons dabord que si le temps de simulation avance, le dlai de recherche dune route
rpandant la contrainte de dbit dmuni. En effet, au dbut de la simulation il n y a pas de route
enregistre dans la table de routage et qui satisfait les exigences de la source. Mais avec le temps,
les nuds intermdiaires peuvent utiliser les routes dj enregistres dans la table de routage.
Le problme cest que ces routes ont une dure de vie (ACTIVE_ROUTE_TIMEOUT = 50 sec)
[13] et pour cette raison le dlai dtablissement dune route augmente dans des instants prcis et
en particulier pour un mouvement rapide des nuds. Ces instant o le dlai augmente (50,200 et
350 sec) correspondent aux moments o le chemin enregistr dans la table de routage nest plus
valable.
IV.6.1.3 Taux de paquets livrs avec succs
La figure 4.4 montre dabord que le taux de livraison de paquets de donnes diminue lgrement
si la vitesse de dplacement des nuds augmente. En effet, si la vitesse de dplacement des
nuds augmente, il devient plus difficile de maintenir les liaisons au niveau du rseau et donc le
nombre de paquets perdus augmente.
100
98
96
taux de paquets livrs avec succs (%)
94
92
90
88
86
84
82
80
78
76
74
72
70
68
pdr_aodv
66
pdr_maodv
64
pdr_aodv_bw
62
pdr_maodv_bw
60
0
10
15
20
vitesse (m/s)
Figure 4.4 : Taux de paquets livrs avec succs en fonction de la vitesse en respectant la
contrainte de dbit
Nous remarquons que ce taux augmente aprs lintroduction de la qualit de service en terme de
bande passante. En effet, le protocole de routage classique (reprsent par la courbe pdr_aodv
dans le cas unicast et la courbe pdr_maodv dans le cas multicast) choisit la route la plus rcente
Projet de fin dtude
45
supcom
et la plus courte, alors que celui dot de la qualit de service (reprsent par la courbe
pdr_aodv_bw dans le cas unicast et la courbe pdr_maodv_bw dans le cas multicast) impose en
plus une contrainte de bande passante. Dans ce cas, les liens composant la route possdent une
bande passante plus large. Ce qui fait que le nombre de paquets perdus diminue.
110
100
90
80
70
60
50
40
30
pdr_maodv_bw (5m/s)
pdr_aodv_bw (5m/s)
pdr_maodv_bw (20m/s)
pdr_aodv_bw (20m/s)
20
10
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.5 : Taux de paquets livrs avec succs en fonction du temps avec contrainte de dbit
La variation de ce paramtre en fonction du temps de simulation est reprsente dans la figure

4.5.
Nous constatons que pendant les 30 premires secondes, le taux de livraison est faible et il ne
dpasse pas 30 % au dbut de la simulation. Cela est d au fait que les paquets de donnes sont
encore dans la file dattente (soit quils attendent ltablissement dun chemin soit la rparation
des liens dfectueux si le paquet est en cours de route).
Cette figure montre aussi que, dans le cas unicast (reprsent par les courbes pdr_aodv_bw), le
taux de paquets livrs avec succs reste constant durant toute la simulation. Alors que pour le
multicast (reprsent par les courbes pdr_maodv_bw), ce paramtre varie lgrement pendant la
simulation. En effet, avec lavancement de la simulation, le rseau devient plus satur (plus de
paquets de donnes et de contrle circulent dans le rseau). En plus, le volume de trafic de
contrle va augmenter aux moments de lexpiration de la validit de la route enregistre dans la
table de routage. Ces moments de saturation vont causer la perte des paquets de donnes.
Ce qui fait la diffrence entre lunicast et le multicast est le volume de trafic de contrle qui est
plus important pour le multicast (pour la maintenance de larbre). Cependant, nous remarquons
que la fluctuation de ce paramtre est plus importante pour un mouvement rapide des nuds.
Projet de fin dtude
46
supcom
IV.6.1.4 Dlai moyen de bout en bout

120
dlai de bout en bout (ms)
100
80
60
40
eed_aodv
eed_maodv
eed_aodv_bw
eed_maodv_bw
20
0
0
10
15
20
vitesse (m/s)
dbit
A partir de la figure 4.6, nous constatons la diffrence entre le protocole MAODV (reprsent
par la courbe eed_maodv) et le QoS-MAODV (reprsent par la courbe eed_maodv_bw).
Sur cette mme figure, nous remarquons que si la vitesse des nuds augmente, le dlai de bout
en bout augmente.
Nous remarquons aussi que le mcanisme de qualit de service pour le trafic multicast rduit le
dlai de bout en bout de 10 ms. Il nous fait aussi gagner 20 ms sur le dlai pour le trafic unicast.
Pour mieux comprendre leffet de lintroduction de la qualit de service sur le dlai de bout en
bout, nous avons tudi le comportement de ce dlai le long de la simulation. Le rsultat est
illustr dans la figure 4.7.
Nous remarquons sur cette figure que le protocole MAODV avec QoS est plus stable pour les
faibles mobilit. Nous constatons aussi qu partir du temps de simulation 300 secondes, le dlai
de bout en bout du protocole QoS-AODV est devenu plus faible que celui du QoS-MAODV. En
effet, ce comportement peut tre justifi par le fait que plus on avance dans le temps plus les
nuds mobiles composant le groupe multicast ont tendance de sloigner. Ce qui donne des
chemins plus longs (en nombre de sauts) entre la source et l'un des membres du groupe.
Projet de fin dtude
47
supcom
140
eed_maodv_bw (5m/s)
eed_aodv_bw (5m/s)
eed_maodv_bw (20m/s)
eed_aodv_bw (20m/s)
120
100
80
60
40
20
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.7 : Dlai moyen de bout en bout en fonction du temps avec contrainte de dbit
IV.6.2 Effet de la contrainte de dlai

22000
nombre de paquets de controle (paquets)
20000
18000
16000
14000
12000
10000
8000
6000
toh_aodv
4000
toh_maodv
toh_aodv_dlai
2000
toh_maodv_dlai
0
0
10
15
20
vitesse (m/s)
Figure 4.8 : Trafic de contrle en fonction de la vitesse en respectant la contrainte de dlai
Projet de fin dtude
48
supcom
Sur la figure 4.8 nous remarquons que le trafic de contrle du protocole de routage sous
contrainte de qualit de service en terme de dlai (courbes toh_aodv_dlai et toh_maodv_dlai)
est lgrement suprieur celui du protocole de routage best effort (courbes toh_aodv et
toh_maodv). En effet, ce comportement est prvisible dans la mesure o le mcanisme de la
qualit de service rend les conditions sur les routes recherches plus strictes. Ie nombre de
paquets RREQ et RREP circulant dans le rseau va ncessairement augmenter
La figure 4.9 montre que le protocole de routage dot de la qualit de service (reprsent par les
courbes ral_aodv_dlai et ral_maodv_dlai) met plus de temps pour trouver une route. En effet,
lors de la propagation des messages RREQ il y a plus de traitements effectuer dans le cas o la
qualit de service est implante. Le temps de propagation de ces messages va donc augmenter et
par consquent le mcanisme de recherche de la route prend plus de temps. Nous remarquons
que le dlai dtablissement dune route devient six fois plus grand aprs introduction de la
qualit de service.
30
ral_aodv
ral_maodv
ral_aodv_dlai
ral_maodv_dlai
dlai d'tablissement d'une route (ms
25
20
15
10
0
0
10
15
20
vitesse (m/s)
Figure 4.9 : Dlai dtablissement dune route en fonction de la vitesse en respectant la

contrainte de dlai
Projet de fin dtude
49
supcom
40
ral_maodv_dlai (5m/s)
ral_aodv_dlai (5m/s)
35
ral_maodv_dlai (20m/s)
ral_aodv_dlai (20m/s)
30
25
20
15
10
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.10 : Dlai dtablissement dune route en fonction du temps avec contrainte de dlai
La figure 4.10 donne le comportement du dlai d'tablissement d'une route en fonction du temps
avec la contrainte de dlai. Nous constatons que les courbes de cette figure admettent des
maximums et des minimums relatifs. Cette variation de dlai est due la disposition des nuds.
En effet, le temps d'tablissement d'une route depuis la source jusqu' la destination comprend le
temps d'excution de l'algorithme de qualit de service au niveau des nuds intermdiaires. Ce
temps augmente en fonction du nombre de sauts.
La figure 4.11 montre que dans le cas dun routage multicast et pour des vitesses leves le taux
de livraison se dgrade denviron 2.5% avec lintroduction de la qualit de service. Pour les
grandes vitesses, les messages de contrles sont plus nombreux, ceci est d au changement
frquent de la topologie du rseau. En plus ces messages disposent d'une taille plus importante
aprs l'introduction de la contrainte du dlai comme contrainte de QoS, ce qui occupera des
ressources supplmentaires en bande passante.
Dans le cas dune faible mobilit, le MAODV avec QoS (reprsent par la courbe
pdr_maodv_dlai) dispose d'un PDR suprieur celui offert par le MAODV classique
(reprsent par la courbe pdr_maodv). Ceci s'explique par le fait que nous garantissons avec ce
protocole un chemin plus stable permettant de satisfaire la contrainte de dlai exige. Par
consquent les paquets de donnes ont plus de chance d'atteindre leurs destinations.
Projet de fin dtude
50
supcom
105
pdr_aodv
pdr_maodv
pdr_aodv_dlai
pdr_maodv_dlai
100
95
90
85
80
75
70
65
60
0
10
15
20
vitesse (m/s)
Figure 4.11 : Taux de paquets livrs avec succs en fonction de la vitesse en respectant la
contrainte de dlai
Pour le routage unicast, nous remarquons que le taux de livraison des paquets de donnes se
dgrade lgrement avec la vitesse comme dans le cas du MAODV avec QoS.
Nous constatons que les PDR offerts par les trafics unicasts sont environ 20% plus importants
que ceux constats dans les trafics multicasts. Ceci est d au trafic de contrle supplmentaire
indispensable pour la maintenance de l'arbre multicast qui consomme des ressources
supplmentaires en bande passante.
120
100
80
60
40
pdr_maodv_dlai (5m/s)
20
pdr_aodv_dlai (5m/s)
pdr_madv_dlai (20m/s)
pdr_aodv_dlai (20m/s)
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.12 : Taux de paquets livrs avec succs en fonction du temps avec contrainte de dlai
Projet de fin dtude
51
supcom
Sur la figure 4.12 nous remarquons que pour un temps de simulation suprieur 150 secondes, le
taux de livraison est stable. Pour un temps de simulation compris entre 0 et 30 secondes, ce taux
est infrieur 50 %. En effet, cela est prvisible parce que les paquets de donnes ne peuvent
tre livrs quaprs tablissement ditinraire ou rparation de liens.
Sur la figure 4.13, nous constatons que le dlai de bout en bout ne dpasse pas les 70 ms pour le
QoS-MAODV (reprsent par la courbe eed_maodv_dlai), alors quil atteint les 100 ms pour le
MAODV sans QoS (reprsent par la courbe eed_maodv). De mme pour le aodv unicast
(reprsent par les courbes eed_aodv et eed_aodv_dlai). En effet, ceci sexplique du fait que
nous avons garanti des liens disposant dun dlai minimal.
120
eed_aodv
eed_maodv
eed_aodv_dlai
100
eed_maodv_dlai
80
60
40
20
0
0
10
15
20
vitesse (m/s)
dlai
Lvolution de ce dlai durant la simulation est prsent dans la figure 4.14. Nous observons sur
cette figure que le dlai de bout en bout du protocole MAODV fluctue lgrement en fonction du
temps. En effet, cela est prvisible du fait que ce dlai dpend de la distance (nombre de sauts)
entre la source et chacun des membres de groupe multicast.
Nous remarquons aussi que le dlai offert par le QoS-MAODV peut tre soit infrieur soit
suprieur celui offert par le QoS-AODV. Cela est d lvolution de la structure de larbre
(distance entre les membre du groupe) en fonction du temps.
Projet de fin dtude
52
supcom
.
100
eed_maodv_dlai (5m/s)
eed_aodv_dlai (5m/s)
90
eed_maodv_dlai (20m/s)
eed_aodv_dlai (20m/s)
80
70
60
50
40
30
20
10
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.14 : Dlai moyen de bout en bout en fonction du temps avec contrainte de dlai
IV.6.3 couplage des deux contraintes ensembles

nombre de paquets de controle (paquets)
25000
toh_aodv
toh_maodv
toh_qos-aodv
toh_qos-maodv
20000
15000
10000
5000
0
0
10
vites se (m /s)
15
20
Figure 4.15 : Trafic de contrle en fonction de la vitesse en respectant les contraintes de dlai et
de dbit
La figure 4.15 montre quil y a plus de paquets de contrle circulant dans le rseau pour les
protocoles de routages avec qualit de service (toh_qos-aodv et toh_qos-maodv). En effet, les
conditions sur la route que le protocole de routage avec QoS exige, sont plus strictes que celles
exiges par les protocoles unicast et multicast AODV.
Projet de fin dtude
53
supcom
Nous constatons, sur la figure 4.16 que le dlai dtablissement dune route est influenc
considrablement par lintroduction de la qualit de service. En effet, chaque nud
intermdiaire, en recevant un paquet RREQ ou RREP, est oblig deffectuer des oprations de
calcul et de comparaison pour les deux contraintes de dbit et de dlai, ce qui ncessite un temps
dtablissement dune route supplmentaire.
30
ral_aodv
ral_maodv
ral_qos-aodv
ral_qos-maodv
25
20
15
10
0
0
10
15
20
vitesse (m/s)
Figure 4.16 : Dlai dtablissement dune route en fonction de la vitesse en respectant les
contraintes de dbit et de dlai
50
ral_qos-maodv (5m/s)
ral_qos-aodv (5m/s)
ral_qos-maodv (20m/s)
ral_qos-aodv (20m/s)
45
40
35
30
25
20
15
10
5
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.17 : dlai dtablissement dune route en fonction du temps avec contraintes de dbit et
de dlai
Projet de fin dtude
54
supcom
La figure 4.17 donne lvolution de ce dlai durant la simulation. Nous remarquons linstabilit
de ce dlai cause de la variation de la langueur du chemin durant la simulation. Ce dlai est
plus important pour les vitesses leves.
105
pdr_aodv
pdr_maodv
pdr_qos-aodv
pdr_qos-maodv
100
95
90
85
80
75
70
65
60
0
10
15
20
vitesse (m/s)
Figure 4.18 : Taux de paquets livrs avec succs en fonction de la vitesse en respectant les
contraintes de dbit et de dlai
Daprs la figure 4.18 nous remarquons que les deux protocoles AODV et MAODV
implmentant les deux contraintes ensembles (pdr_qos-aodv et pdr_qos-maodv) possdent un
taux de livraison plus important que les protocoles de routage AODV et MAODV classiques
(pdr_aodv et pdr_maodv). En effet, les protocoles de routages unicast et multicast dots de la
qualit de service imposent la contrainte de bande passante. Les liens composant la route
possdent donc une bande passante plus large. Dans ce cas le nombre de paquets perdus diminue.
La figure 4.19 donne lvolution du PDR en fonction du temps de simulation. Cette figure
montre que le PDR est important et assez stable. Ceci sexplique du fait que nous avons garantie
des liens disposant dune bande passante maximal et dun dlai minimal.
Projet de fin dtude
55
supcom
120
100
80
60
40
pdr_qos-maodv (5m/s)
pdr_qos-aodv (5m/s)
pdr_qos-maodv (20m/s)
pdr_qos-aodv (20m/s)
20
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.19 : Taux de paquets livrs avec succs en fonction du temps avec contraintes de dbit et de
dlai
120
eed_aodv
eed_maodv
eed_qos-aodv
eed_qos-maodv
100
80
60
40
20
0
0
10
15
20
vitesse (m/s)
Figure 4.20 : Dlai moyen de bout en bout en fonction de la vitesse en respectant les contraintes
de dbit et de dlai
Projet de fin dtude
56
supcom
La figure 4.20 montre quaprs implmentation de la qualit de service, le dlai de transmission

des paquets de donnes ne dpasse pas 70 ms (valeur max ne pas dpasser exig par
lmetteur) pour le routage multicast et 60 ms pour lunicast.
Les deux protocoles AODV et MAODV implantant les deux contraintes de la qualit de service
ensemble (reprsents par les courbes eed_qos-aodv et eed_qos-maodv) peuvent garantir un
dlai minimal de transmission de paquets de donnes que les protocoles classiques (reprsents
par les courbes eed_aodv et eed_maodv). Cette amlioration du dlai devient plus ressentie avec
laugmentation de la vitesse. En effet, pour une faible mobilit la qualit de service na pas
deffet car la contrainte de dlai impose par la source est toujours respecte mme pour les
protocoles de routages classiques. Lorsque la mobilit augmente, le mcanisme de la qualit de
service va ignorer les routes o le dlai dpassera la contrainte exige par lmetteur.
La figure 4.21 montre que le dlai de bout en bout est instable et cette instabilit est plus
importante pour le protocole MAODV. En effet, dans le cas o la destination est un groupe
multicast, ce dlai reprsente une moyenne des dlais entre la source et chacun des membres du
groupe. Ce dlai dpend donc de la structure de l'arbre.
120
eed_qos-maodv (5m/s)
eed_qos-aodv (5m/s)
eed_qos-maodv (20m/s)
eed_qos-aodv (20m/s)
100
80
60
40
20
0
0
50
100
150
200
250
300
350
400
450
500
550
590
Figure 4.21 : Dlai moyen de bout en bout en fonction du temps avec contraintes
de dbit et de dlai
Projet de fin dtude
57
supcom
IV.7. conclusion
Malgr que le protocole de routage dot de la qualit de service implantant les contraintes de
dbit et de dlai ensemble consomme plus de la bande passante, il a permis de combler les points
faibles du protocole dot de la qualit de service en terme de dlai ou de dbit. En effet, un
protocole de routage implantant les deux contraintes ensemble, doit dterminer des chemins tout
en respectant la bande passante et le dlai demand par lmetteur.
Projet de fin dtude
58
Conclusion gnrale
supcom
Conclusion gnrale
Vue lmergence de nombreuses applications dans les rseaux ad hoc et qui ncessitent des
communications multicast tels que la visioconfrence, le travail de collaboration, et les jeux
distribus, lenvironnement ad hoc a commenc attirer lintention des chercheurs dans le
domaine des protocoles de routage multicast.
Le dynamisme des membres dun rseau ad hoc induit des problmes de routage dans ce type de
rseaux, ce qui va influencer la qualit de service offert (dlai de transmission, taux de perte, ).
Pour cela, et vue lmergence des applications sans fil, la QoS dans les rseaux mobiles ad hoc
devient un sujet de plus en plus important mais aussi dlicat.
Dans ce projet, nous avons implment laspect QoS sur les protocoles de routage AODV et
MAODV en considrant les contraintes de dbit, dlai et le couplage de ces deux contraintes
ensemble dans la recherche et l'tablissement de routes. Nous avons tudi l'apport de ces
mcanismes de QoS sur les trafics unicast et multicast.
Lanalyse des rsultats de simulations montre que lintroduction de la contrainte de dlai de bout
en bout a amlior les performances du rseau. Nous avons constat aussi que le taux de paquets
livrs avec succs augmente avec lintroduction de la contrainte de dbit. Le couplage des deux
contraintes a nettement amlior ces deux mtriques.
Lvaluation de performance dun protocole de routage se fait gnralement sur les mmes
paramtres. Et cest l justement que se pose le problme qui relve de la diversification des
paramtres configurables avant tout scnarios de simulation. En effet, les rsultats prsents ici
resteront certainement valables condition de garder la mme configuration. Ce qui pose en fait
un problme relativement complexe lorsquil sagit de se ramener la ralit du terrain.
Ici par exemple, nous avons utilis une mobilit alatoire pour les nuds, ce qui nest
gnralement pas le cas dans lutilisation relle du rseau ad hoc.
Ce travail laisse entrevoir des perspectives intressantes. Cependant, nous prvoyons dtudier
notre approche dans un contexte multimdia rel. Nous pouvons aussi utiliser un modle de
mobilit plus proche de la ralit.
Projet de fin dtude
59
Conclusion gnrale
supcom
En fin, malgr quon peut sapprocher de la ralit, une valuation par simulation nous ne donne
quune ide globale sur la performance du protocole. Une valuation sur terrain peut donc nous
donner une ide plus claire sur notre approche.
Projet de fin dtude
60
Bibliographie
supcom
Bibliographies
[1] S. Corson, J. Macker, Mobile Ad hoc Networking (MANET) : Routing Protocol
Performance Issues and Evaluation Considerations, Request for Comments 2501,
IETF, January 1999

[2] C.E. Perkins, E.M. Belding-Royer, et S. Das. Ad Hoc On Demand Distance Vector (AODV)
Routing, IETF RFC 3561
[3] Y. Zhu, T. Kunz, "MAODV Implementation for NS-2.26", Systems and computer
Engineering, Carlton University, Technical Report SCE-04-01,January 2004.
[4] http://www.isi.edu/nsnam/ns
[5] H. Xiao, K. G. Seah, A. Lo, and K. C. Chua, "A flexible quality of service model for mobile
ad-hoc networks", Vehicular Technology Conference Proceedings, 2000, VTC 2000-Spring
Tokyo, IEEE : 51st, Volume : 1, Page(s) : 445 -449
[6] Gahng-Seop Ahn, Andrew T. Campbell, Andras Veres and Li-Hsiang Sun, SWAN : Service
Differentiation in Stateless Wireless Ad Hoc Networks , Proc. IEEE INFOCOM, New York,
2002
[7] R. Braden RFC : 2205 Resource ReSerVation Protocol (RSVP), Request for Comments,
IETF, Sep. 1997.

[8] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss RFC : 2475 An
Architecture for Differentiated Services, Request for Comments, IETF, December 1998
[9] R. Sivakumar, P. Sinha and V. Bharghavan, CEDAR : a Core-Extraction Distributed Ad hoc
Routing algorithm, INFOCOM 99, Eighteenth Annual Joint Conference of the IEEE Computer
and Communications Societies Proceedings, IEEE, Volume : 1, 21-25 Mar 1999 Page(s) : 202 209 vol.1 1999
[10] K. Chen, S. H. Shah, and K. Nahrstedt, Cross Layer Design for Data Accessibility in
Mobile Ad Hoc Networks, Journal on Wireless Communications, vol. 21, pp. 49-75, 2002
[11] S. Chen, K. Nahrstedt, Distributed quality-of-service routing in ad hoc networks, IEEE
Journal on Selected Areas in Communications 17 (8), pp 1488-1504, (1999)

[12] C. E. Perkins, E. M. Royer, and S. R. Das, "Ad hoc on-demand distance vector routing",
Internet Draft, 2002.

[13] C. E. Perkins, E. Royer, "Ad Hoc On Demand Distance Vector (AODV) Routing", Internet
Draft, 20 November 1998.
Projet de fin dtude
61
Bibliographie
supcom
[14] D. B. Johnson, D. Maltz, Yih-Chun Hu, The Dynamic Source Routing Protocol for
Mobile Ad Hoc Networks (DSR), Internet Draft , 19 July 2004
Projet de fin dtude
62
Acronymes
supcom
Acronymes
AODV : Ad hoc On Demand Vector distance
CEDAR : Core-Extraction Distributed Ad hoc Routing algorithm
DiffServ : Differentiated Services
DSDV : Distance Source Distance Vector routing protocol
DSR : Dynamic Source Routing Protocol
EED : End to end delay
FQMM : Flexible quality of service model for MANETs
GRPH : Group Hello
GRPH-U : Group Hello-Update
IntServ : Integrated Services
MAC : Medium Access Control
MACT : Multicast route ACTivation
MANET : Mobile Ad hoc NETwork
MAODV : Multicast Ad hoc On Demand Vector distance
NS : Network Simulator
PDR : Packet Delivery Ratio
QoS : Quality of Service
QoS-AODV : Quality of Service for Ad hoc On Demand Vector distance
QoS-MAODV : Quality of Service for Multicast Ad hoc On Demand Vector distance
RERR : Route ERRor
RREP : Route REPly
RREP-J : Route REPly-Join
RREP-R : Route REPly-Repair
RREQ : Route REQuest
RREQ-J : Route REQuest-Join
RREQ-R : Route REQuest-Repair
SWAN : Service differentiation in wireless ad hoc networks
Projet de fin dtude
63
Annexe 1
supcom
Annexe 1
NS2 : Aperu du logiciel
NS est un outil logiciel de simulation de rseaux informatiques. Il est principalement bti sur
lide de la conception par objets, de la rutilisation du code et de modularit. Il est devenu
aujourd'hui un standard de rfrence dans ce domaine. C'est un logiciel dans le domaine public
disponible sur l'Internet. Son utilisation est gratuite. Le logiciel est excutable tant sous la
plateforme Unix que Windows.
Il sagit dun simulateur vnement discret, fruit de la collaboration entre luniversit de
Berkely, USC et Xerox PARC dans le cadre du projet VINT. Ce projet est soutenu par le
DARPA. NS-2 est un outil de recherche trs utile pour le design et la comprhension des
protocoles.
Le simulateur NS actuel est particulirement bien adapt aux rseaux commutation de paquets
et la ralisation de simulations de petite taille. Il contient les fonctionnalits ncessaires
l'tude des algorithmes de routage unipoint ou multipoint, des protocoles de transport, de session,
de rservation, des services intgrs, des protocoles d'application comme HTTP. De plus le
simulateur possde dj une palette de systmes de transmission (couche 1 de l'architecture
TCP/IP), d'ordonnanceurs et de politiques de gestion de files d'attente pour effectuer des tudes
de contrle de congestion. Il permet lutilisateur de concevoir un rseau et de simuler les
communications entre les nuds. Le simulateur utilise le langage orient objet OTCL (Object
TCL) driv du TCL (Tool Command Language) pour la description des conditions de
simulation sous forme de script.
La liste des principaux composants actuellement disponible dans NS par catgorie est:
Projet de fin dtude
64
Annexe 1
supcom
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

Ces capacits ouvrent le champ l'tude de nouveaux mcanismes au niveau des diffrentes
couches de l'architecture rseau.. Ils peuvent ainsi partager leurs efforts et changer leurs
rsultats de simulations. Cette faon de faire se concrtise aujourd'hui par l'envoi dans certaines
listes de diffusion lectronique, des scripts de simulations NS pour illustrer les points de vue.
Comme tout outil de simulation, NS2 permet ltude de lexistant, la conception, la validation et
lvaluation de performances et ceci dans le domaine des protocoles et mcanismes rseaux. il
bnfice aussi des avantages dun simulateur de rseaux tels que la flexibilit, ltude des cas
difficiles reproduire dans la ralit, le faible cot des exprimentations et la reproductibilit des
rsultats. Dautre part, il souffre de leurs inconvnients tels que la simplification et labstraction
du monde rel, la difficult de tester certaines choses, et la puissance de calcul requise qui croit
avec la complexit du systme simul. De plus NS2 souffre de ltat primitif aussi bien de ses
outils de collecte et traitements des rsultats que de son interface graphique et de la lenteur de
correction des bugs.
L'utilisation de NS-2 peut tre :
De base: on utilise le simulateur tel que] (code fourni par les dveloppeurs).
Intermdiaire: on ajoute des fonctionnalits sans modifier le coeur du simulateur.
Avance: on dveloppe son propre code (en C++) et on modifie le coeur du simulateur.
La figure (A.1) illustre un cycle de simulation typique avec NS2
Projet de fin dtude
65
Annexe 1
supcom
Problme
tudier
Modle de
simulation
Cration de scnario
de simulation
Analyse des
rsultats
Excution des
simulations
Modification NS2
(code OTcl et/ou
c++)
Figure A.1 : Cycle dune simulation

Le rsultat dune simulation est un fichier texte contenant tous les vnements de la simulation.
Un traitement ultrieur de ce fichier permet den extraire linformation souhaite. Par ailleurs, le
simulateur permet la cration dun fichier danimation, permettant de visualiser la simulation sur
une interface graphique NAM. Ce visualisateur fournit une reprsentation du graphe du rseau
sur laquelle on peut voir circuler ces paquets, suivre le niveau des files dattente, etc.
Architecture et implmentation
NS-2 est dvelopp en C++ et en OTcl abject Tools command language . Il contient une
hirarchie de classes compiles d'objets crits en C++ et une hirarchie de classes interprtes
d'objets crits en OTcl. Ces deux hirarchies sont troitement lies. En effet, lorsque l'utilisateur
cre un nouvel objet par l'interprteur OTcl, un objet correspondant, appel objet reflet, est aussi
cre dans la hirarchie compile. On dit que ces objets sont des "objets fondus". D'ailleurs, des
procdures d'appel entre OTcl et C++ sont mises en place permettant ainsi l'utilisateur
d'accder aux diffrents objets aussi bien en Otcl qu'en C++ .
Il est noter que l'utilisation de deux langages permet la sparation entre les plans donnes et
contrle (des chelles temporelles diffrentes). Le langage C++ est utilis pour le plan
donnes pour traiter des vnements au niveau paquet tels que la gnration de paquets IP et le
traitement des paquets dans les routeurs. Quant au langage OTcl. Il sert pour le plan contrle
afin de pouvoir effectuer des traitements des chelles temporelles plus grandes et coder des
Projet de fin dtude
66
Annexe 1
supcom
modles de trafic et/ou applications simples (ex: application ftp).

L'OTcl permet aussi le contrle des simulations par la dfinition des scnarios de simulation
(topologie du rseau, taille des files dattentes des routeurs).
Otcl est un langage interprt qui ne demande pas de compilation. Il est utilis .pour concatner
des objets, accder aux objets partir de l'interprteur' et configurer des simulations, Ce langage
rend l'utilisation du simulateur assez souple et convivial car il offre de nombreux objets
prdfinis qui peuvent tre utiliss pour simuler un grand nombre de Scnarios assez aisment.
Le langage C++ est utilis pour crer des classes de base permettant de traiter un grand nombre
de donnes tels que le calcul des tables de routage, le mouvement des mobiles... On fait appel
donc ce langage pour programmer des agents adapts un comportement particulier ou un
protocole spcifique.
Au plus bas niveau, il y a six classes qui dfinissent l'ensemble de la structure du programme et
fournissent les mthodes lmentaires. Il s'agit des classes Tcl, TclObject, TclClass,
Tclcommand, EmbeddedTcl et InstVar. Elles dfinissent entre autres les mthodes utilises par
C++ pour accder l'interprteur, la hirarchie, les principales commandes de haut niveau et les
mthodes pour accder aux variables de C++ et Otcl.
La simulation est configure, contrle et gre l'aide des interfaces fournies par la classe Otcl
Simulator. Cette classe fournit des procdures pour crer et grer la topologie, initialiser le
format des paquets et choisir le planificateur d'vnements. Elle stocke intrieurement des
rfrences chaque lment de la topologie. Un script devra donc toujours commencer par
l'instanciation d'une variable de cette classe. L'utilisateur cre ensuite la topologie travers Otcl
en utilisant les classes node et link qui sont les composants essentiels de la topologie.
La mobilit dans NS2

Limplmentation originale de NS2 ne contient pas une extension pour la simulation des rseaux
mobiles. Les dernires versions du logiciel ont bnfici de deux extensions de mobilit :
Wireless Mobility Extension: projet dvelopp par le CMU Monarch Projcct,
Mobile IP Extension: projet dvelopp par SunMicroSystem.
Nous avons choisit l'extension CMU, car elle nous offre une architecture protocolaire complte
pour la simulation des rseaux ad hoc, cette architecture implmente un modle de canal
Projet de fin dtude
67
Annexe 1
supcom
physique, un protocole MAC, le protocole ARP et quelques protocoles de routage ad hoc.
Le modle de propagation:Le modle de propagation est utilis pour dterminer si les

donnes transmises ont t correctement reues ou pas. Ce modle inclut les dlais de
propagation, l'coute du canal, la dtection de la porteuse, etc.
Le protocole MAC: Le modle de protocole MAC utilis tant le IEEE 820.11

Distributed Coordination Function (DCF), donnant la possibilit de transmission point
point (Unicast) et diffusion gnralise (Broadcast).
L'interface physique:Chaque nud mobile est quip d'une interface physique pour la
transmission et rception des donnes. Cette interface offre une porte radio de 250m, un
dbit maximal de 2 Mb/s et utilise une antenne omni-directionelle de gain unit. De plus,
cette interface contient les files d'attentes ncessaires pour drouler les algorithmes de
routage.
Les donnes sont gnres par la couche application et les paquets de donnes atteignent l'agent
de routage qui dtermine la route que doit prendre le paquet puis le fait passer la couche LLC.
Celle ci utilise le protocole de rsolution d'adresse (ARP) pour la correspondance entre l'adresse
IP du nud destinataire et son adresse physique (MAC). Le paquet est ensuite mis dans la file
d'attente en attendant que le protocole MAC dcide de le faire passer l'interface physique qui
son tour l'met dans le canal radio.
Chaque interface physique qui reoit un paquet, va y inscrire des informations particulires
(instant de rception, ...) puis fait appel au modle de propagation. Celui ci utilise alors les
informations qui ont t marqu sur le paquet durant son parcours par les diffrentes interfaces
physiques, pour estimer la puissance avec laquelle les donnes sont reues. Si cette puissance
n'est pas au dessous d'un seuil de dtection, alors le paquet est livr la couche MAC, qui
s'assure de l'absence d'erreurs et de trace de collision, puis le met dans le module " Entry Point"
qui livre le paquet un dmultiplexeur.
Si le paquet a atteint sa destination, le dmultiplexeur dcide vers quelle application aiguiller les
donnes, si non, le dmultiplexeur fait passer le paquet la couche rseau pour tre relay vers
sa destination.
Projet de fin dtude
68
Annexe 1
supcom
Figure : Schma synoptique dun nud mobile dans NS2
Prsentation du TCL
Tcl est un langage de commande comme le shell UNIX mais qui sert contrler les applications.
Son nom signifie Tool Command Language. Tcl offre des structures de programmation telles que
les boucles, les procdures ou les notions de variables. Il y a deux principales faons de se servir
de Tcl: comme un langage autonome interprt ou comme une interface applicative d'un
programme classique crit en C ou C++. En pratique, l'interprteur Tcl se prsente sous la forme
d'une bibliothque de procdures C qui peut tre facilement incorpore dans une application.
Cette application peut alors utiliser les fonctions standard du langage Tcl mais galement ajouter
des commandes l'interprteur.
Prsentation de lOTcl
La documentation est accessible l'URL ftp://ftp.tns.lcs.mit.edu/pub/otcl/. OTcl est une
extension oriente objet de Tcl. Les commandes Tcl sont appeles pour un objet. En OTcl, les
classes sont galement des objets avec des possibilits d'hritage. Les analogies et les diffrences
avec C++ sont:
C++ a une unique dclaration de classe. En OTcl, les mthodes sont attaches un objet
ou une classe.
Projet de fin dtude
69
Annexe 1
supcom
Les mthodes OTcl sont toujours appeles avec l'objet en prfixe
L'quivalent du constructeur et destructeur C++ en OTcl sont les mthodes
init{}/destroy{}.
L'identification de l'objet lui-mme: this (C++), $self (OTcl). $self s'utilise l'intrieur
d'une mthode pour rfrencer l'objet lui-mme. A la diffrence de C++, il faut toujours
utiliser $self pour appeler une autre mthode sur le mme objet. C'est dire "$self xyz 5"
serait "this->xyz(5)" ou juste "xyz(5)" en C++.
Les mthodes OTcl sont tout le temps "virtual". A savoir, la dtermination de la mthode
appeler est effectue l'excution.
En C++ les mthodes non dfinies dans la classe sont appeles explicitement avec
Loprateur de porte ":. En OTcl, les mthodes sont implicitement appeles dans l'arbre
d'hritage par "$self next". Cette commande appelle la mthode de mme nom de la
classe parent.
Technique de simulation
La simulation des protocoles de routage des rseaux ad hoc s'articule autour de 4 grandes parties
interdpendantes:
1- Pr simulation
Durant cette phase, nous allons gnrer le script principal en OTCL faire transmettre NS2 ; ce
script est gnr automatiquement partir de plusieurs modles de scripts TCL pour les
configurations et la manipulation de fichiers, ainsi qu'un script OTCL contenant le code de
gnration du trafic sur le rseau et un autre script OTCL, contenant les instructions dfinissant
le mouvement des nuds dans le rseau. L'ensemble des ces fichiers constitue un "scnario" de
simulation.
2- Simulation
Durant cette phase, NS2 va simuler les diffrents scnarios pendant une dure bien fixe. Le
rsultat de ces simulations se trouve dans des fichiers de trace gnrs par NS2.
Projet de fin dtude
70
Annexe 1
supcom
3- Post-simulation
Dans cette phase, nous allons rcuprer les fichiers de trace NS2 et en extraire les rsultats que
nous voudrions visualiser ou interprter. Cette extraction ainsi que toute autre opration de calcul
est assure par plusieurs scripts en langage AWK ou PERL.
4- Exploitation
Une fois les rsultats calculs, les scripts AWK les enregistrent dans des fichiers que nous
pouvons ensuite sauvegarder ou bien utiliser avec d'autres programmes pour tracer des courbes
ou bien effectuer d'autres calculs.(MatLab, excel...).
Projet de fin dtude
71
Annexe 2
supcom
Annexe 2
Implmentation du protocole MAODV
Etapes dimplmentation
Dabord il faut que NS2 soit install. Tlcharger les paquetages NS2 du site
http:/www.isi.edu/nsnam/ns.
Les paquetages MAODV contiennent en total 18 fichiers :
1) aodv.h;
2) aodv.cc;
3) aodv_mcast.cc;
4) aodv_mtable_aux.cc;
5) aodv_mtable_aux.h;
6) aodv_mtable.cc
7) aodv_mtable.h;
8) aodv_packet.h;
9) aodv_rqueue.cc;
10) aodv_rqueue.h;
11) aodv_rtable.cc;
12) aodv_rtable.h;
13) cmu-trace.cc;
14) wireless-phy.cc;
15) wireless-phy.h;
16) node.cc;
17) node.h;
18) ns-mcast.tcl.
Parmi ces fichiers il y a trois nouveaux qui nexistaient pas dans la AODV.
Ces fichiers sont :
Aodv_mtable.cc : construction de la table de routage multicast
Aodv_mtable_aux.cc : construction de la table du group leader
Aodv_mcast.cc : il contient les procdures suivantes :
diffusion priodique du message GRPH.
recherche des nuds qui doivent sortir de larbre.
sortie dun nud de larbre (pruning of tree member).

dtection des partitions darbre.
slection du group leader.
fusion darbres.
Projet de fin dtude
72
Annexe 2
supcom
acheminement des paquets de contrle.

acheminement des paquets de donnes et leur diffusion dans larbre.
La dmarche suivre est :
Copier les fichiers 1) 12) dans le rpertoire ./ns-2.26/aodv/;
Copier le fichier 13) dans le rpertoire ./ns-2.26/trace/;
Copier les fichiers 14) et 15) dans le rpertoire ./ns-2.26/mac/;
Copier les fichiers 16) et 17) dans le rpertoire ./ns-2.26/common;
Et finalement le fichier 18) dans le rpertoire ./ns-2.26/tcl/mcast/.
Aprs avoir copier les fichiers, dans le rpertoire ns-2.26, modifier Makefile.in par l'ajout du
fichier objet du protocole la liste des fichiers objet de ns.
Les fichiers objets ajouts sont :
-aodv_mcast.o;
-aodv_mtable_aux.o;
-aodv_mtable.o;
Par la suite recompiler NS2 en tapant les commandes suivantes :
) ./configure : pour que le Makefile.in soit conforme avec le Makefile.
) Make clean : pour supprimer tout les anciens objets existant sous le rpertoire ./ns2.26.
) Make : pour crer les nouvelles objets.
Le protocole MAODV est enfin implment sur NS2.
Projet de fin dtude
73
Annexe 3
supcom
Annexe 3
Modle de trafic multicast
Le modle de trafic dcrit les ensembles nuds {Nud source, les nuds du group multicast
destinations} choisi pour une communication (lutilisateur celui qui impose le nombre des
nuds mettrices et le nombre des nuds rceptrices qui constituent le groupe multicast.
Le script TCL permettant de gnrer un trafic pour 50 nuds avec le nud 0 comme source et
les nuds 40 49 des nuds rceptrices par exemple est le suivant :
set udp_(0) [new Agent/UDP]
$udp_(0) set dst_addr_ 0xE000000
$ns_ attach-agent $node_(0) $udp_(0)
set cbr_(0) [new Application/Traffic/CBR]
$cbr_(0) set packetSize_ 512
$cbr_(0) set interval_ 0.50
$cbr_(0) set random_ 1
$cbr_(0) set maxpkts_ 2950
$cbr_(0) attach-agent $udp_(0)
$cbr_(0) set dst_ 0xE000000
$ns_ at 30.0 "$cbr_(0) start"
for {set i 40} {$i < 50} {incr i} {
$ns_ at 0.0100000000 "$node_($i) aodv-join-group 0xE000000"
}
Cration des scnarios des nuds mobiles

Dans le rpertoire : ns-allinone-2.26/ns-2.26/indep-utils/cmu-scen-gen/setdest, il faut excuter :
./setdest [-n num_of_nodes] [-p pausetime] [-s maxspeed] [-t simtime] [-x maxx] [-y maxy] >
[output-file]
Par exemple dans le cas dun rseau de 50 nuds avec la vitesse de mobilit des nuds de 5 m/s
et dans une surface de 500m x 500m on lance la ligne suivante (dans le rpertoire dj cit) :
./setdest n 25 p 0 s 5 x 500 y 500 > scen25
Projet de fin dtude
74

KAMMOUN Sabeur

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

KAMMOUN Sabeur

Transféré par

Droits d'auteur :

Formats disponibles

Cycle de formation des ingnieurs en Tlcommunications

Rapport de Projet de fin dtudes

Implmentation de la QoS sur un

Anne universitaire : 2005/2006

Mes sincres remerciements sadresse M. Nabil TABBANE pour son

Je tiens aussi remercier tous mes enseignants de l'Ecole Suprieure des

Projet de fin dtude

Table des matires

III.1 INTRODUCTION ......................................................................................................................28

Liste des figures

Figure 1.1 : Modlisation dun rseau ad hoc .....................................................................................3

fonction de la vitesse en respectant la

contrainte de dlai .............................................................................................................................51

Liste des tableaux

Tableau 1 : Paramtrage du contexte de simulation ............................................................ 41

Projet de fin dtude

Rseaux ad hoc et QoS

I.2 Etat dart

Projet de fin dtude

Rseaux ad hoc et QoS

collection de nuds mobiles formant un rseau temporaire a topologie variable et fonctionnant

Figure 1.1 : Modlisation dun rseau ad hoc

Figure 1.2 : Le changement de la topologie des rseaux ad hoc

Projet de fin dtude

Rseaux ad hoc et QoS

Projet de fin dtude

Rseaux ad hoc et QoS

De telles caractristiques peuvent contrarier lintroduction de la qualit de service dans les

I.3 Protocoles de routage dans les rseaux ad hoc

Le protocole de routage DSR.

Le protocole de routage TORA.

Le protocole de routage AODV.

I.3.3 Le protocole de routage AODV

Projet de fin dtude

Rseaux ad hoc et QoS

A cause de la mobilit des nud

s dans les rseaux ad hoc, les routes changent frquemment

ce qui fait que les routes maintenues par certains nud

s, deviennent invalides. Les numros de

destination. Cette valeur est recopie de la table de

Projet de fin dtude

Rseaux ad hoc et QoS

L : si L = 1 alors il sagit dun message hello

I.4 QoS dans les rseaux ad hoc

Projet de fin dtude

Rseaux ad hoc et QoS

Les algorithmes qui cherchent introduire la QoS indpendamment des protocoles de

I.4.1 Les mtriques de QoS pour un environnement ad hoc

Projet de fin dtude

Rseaux ad hoc et QoS

I.4.2 QoS au niveau routage

est dynamiquement choisi pour

s les changes dinformations dtat et de route seront

la dcouverte et la maintenance des routes). En outre, en cas de forte mobilit, la convergence de

Projet de fin dtude

Rseaux ad hoc et QoS

Figure 1.3 : Nud cur en CEDAR

I.4.2.2 Ticket-Based QoS Routing

Projet de fin dtude

Rseaux ad hoc et QoS

destinataire. Ce modle repose essentiellement

Rseaux ad hoc et QoS

Projet de fin dtude