KAMMOUN Sabeur

Cycle de formation des ingénieurs en Télécommunications
Option :
Réseaux mobiles
Rapport de Projet de fin d’études
Thème :
Implémentation de la QoS sur un

protocole de routage (multicast) Ad hoc
Réalisé par :
Sabeur KAMMOUN
Encadrant :
M. Nabil TABBANE
Année universitaire : 2005/2006

A mon père,
A ma mère,
A mon frère et ma sœur,
A mon oncle et toute sa famille,
A tous ceux qui m'aiment ; A tous ceux que j'aime,
Je dédie ce travail.
Remerciements
Mes sincères remerciements s’adresse à M. Nabil TABBANE pour son
encadrement et ses qualités 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 Supérieure des
Communications de Tunis pour l’effort qu’ils ont déployé durant ma formation.

Projet de fin d’étude
Implémentation de la QoS dans un protocole de routage (multicast) ad hoc
Résumé
De nos jours, plusieurs travaux ont été menés sur les réseaux ad hoc afin d’intégrer
les applications temps réel telles que la voix et la vidéo exigeant certaines contraintes au
niveau des ressources offertes en terme de délai et de bande passante. Parmi ces
applications temps réel, nous pouvons citer la vidéoconférence qui nécessite en plus la
communication de groupe.
La topologie dynamique des réseaux ad hoc a une influence importante sur la
qualité de service. Pour cela, et vue l’émergence des applications temps réel, la QoS dans
les réseaux mobiles ad hoc devient un sujet de plus en plus important mais aussi délicat.
Dans ce projet, nous avons implémenté l’aspect QoS sur les protocoles de routage
AODV et MAODV en considérant les contraintes de débit, délai et le couplage de ces
deux contraintes ensemble dans la recherche et l’établissement des routes. Nous avons
étudié l’apport de ces mécanismes de QoS sur les trafics unicast et multicast.
Mots clés
Réseaux ad hoc, QoS, AODV, Multicast-AODV.NS-2

Table des matières
INTRODUCTION GENERALE......................................................................................................1
CHAPITRE I .....................................................................................................................................2
RESEAUX AD HOC ET QOS .........................................................................................................2
I.1 INTRODUCTION...........................................................................................................................2
I.2 ETAT D’ART................................................................................................................................2
I.2.1 Modélisation d’un réseau ad hoc .......................................................................................3
I.2.2 Les applications des réseaux ad hoc ..................................................................................4
I.2.3 Les caractéristiques des réseaux 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 réactifs .....................................................................................5
I.3.3 Le protocole de routage AODV..........................................................................................5
I.4 QOS DANS LES RESEAUX AD HOC ...............................................................................................7
I.4.1 Les métriques de QoS pour un environnement ad hoc .......................................................8
I.4.2 QoS au niveau routage .......................................................................................................9
I.4.3 Modèles de QoS pour les réseaux 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 L’ARBRE ................................16
II.3 CONSTRUCTION DE L’ARBRE ..................................................................................................17
II.4 LA MAINTENANCE DE L’ARBRE MULTICAST ...........................................................................19
II.4.1 la propagation périodique d’un GRPH...........................................................................20
II.4.2 la maintenance de la connectivité entre les nœuds voisins .............................................20
II.4.3 La sélection du chef de groupes (group leader)..............................................................22
II.4.4 Révocation des membres de groupe ................................................................................24
II.4.5 Fusion d’arbres...............................................................................................................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 apportés au message RREQ ........................................................................28
III.2.2 Estimation de débit ........................................................................................................30
III.2.3 Fonctionnement de l’algorithme....................................................................................30
III.3 IMPLANTATION DE LA CONTRAINTE DE DELAI ......................................................................33
III.3.1 Extensions apportés au message RREQ ........................................................................33
III.3.2 Estimation de délai ........................................................................................................34
III.3.3 Fonctionnement de l’algorithme....................................................................................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 Délai moyen de bout en bout..........................................................................................39
IV.4.2 Taux de paquets livrés avec succès................................................................................40
IV.4.3 Délai d’établissement d’une route .................................................................................40
IV.4.4 Trafic de contrôle...........................................................................................................40
IV.5 PARAMETRES DE CONTEXTE DE SIMULATION .......................................................................41
IV.6 RESULTATS ET INTERPRETATIONS ........................................................................................42
IV.6.1 Effet de la contrainte de débit ........................................................................................42
IV.6.2 Effet de la contrainte de délai ........................................................................................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 : Modélisation d’un réseau ad hoc .....................................................................................3

Figure 1.2 : Le changement de la topologie des réseaux ad hoc .........................................................3
Figure 1.3 : Nœud cœur 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 opérations de jointure de l’arbre, 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 : Réparation d’arbre .........................................................................................................21
Figure 2.7 : Sélection du group leader 1ère cas.................................................................................22
Figure 2.8 : Sélection du group leader 2ème cas...............................................................................23
Figure 2.9 : Sélection du group leader 3ème cas...............................................................................24
Figure 2.10 : Procédure « self prune » ..............................................................................................25
Figure 2.11 : Fusion d’arbres.............................................................................................................26
Figure 3.1 : Première extension apportée au message RREQ ...........................................................29
Figure 3.2 : Deuxième extension apportée au message RREQ .........................................................29
Figure 3.3 : Cas où il n’existe pas de chemin enregistré ...................................................................31
Figure 3.4 : Cas où le table de routage enregistre un chemin............................................................33
Figure 3.5 : Extensions apportée au message RREQ pour l’estimation du délai ..............................34
Figure 3.7 : Recherche d’un chemin qui répond à la contrainte de délai ..........................................36
Figure 4.1 : Trafic de contrôle en fonction de la vitesse en respectant la contrainte de débit ...........42
Figure 4.2 : Délai d’établissement d’une route en fonction de la vitesse en respectant la contrainte
de débit ..............................................................................................................................................44
Figure 4.3 : Délai d’établissement d’une route en fonction du temps avec contrainte de débit ........44
Figure 4.4 : Taux de paquets livrés avec succès en fonction de la vitesse en respectant la . contrainte
de débit ..............................................................................................................................................45
Figure 4.5 : Taux de paquets livrés avec succès en fonction du temps avec contrainte de débit ......46
Figure 4.6 : Délai moyen de bout en bout en fonction de la vitesse en respectant la contrainte de
débit ...................................................................................................................................................47
Figure 4.7 : Délai moyen de bout en bout en fonction du temps avec contrainte de débit................48
Figure 4.8 : Trafic de contrôle en fonction de la vitesse en respectant la contrainte de délai ...........48
Figure 4.9 : Délai d’établissement d’une route en fonction de la vitesse en respectant la contrainte
de délai ..............................................................................................................................................49
Figure 4.10 : Délai d’établissement d’une route en fonction du temps avec contrainte de délai .....50
Figure 4.11 : Taux de paquets livrés avec succès en fonction de la vitesse en respectant la
contrainte de délai .............................................................................................................................51
Figure 4.12 : Taux de paquets livrés avec succès en fonction du temps avec contrainte de délai.....51
délai ...................................................................................................................................................52
Figure 4.14 : Délai moyen de bout en bout en fonction du temps avec contrainte de délai ..............53
Figure 4.15 : Trafic de contrôle en fonction de la vitesse en respectant les contraintes de délai et de
débit ...................................................................................................................................................53
Figure 4.16 : Délai d’établissement d’une route en fonction de la vitesse en respectant les.............54
contraintes de débit et de délai ..........................................................................................................54
Figure 4.17 : délai d’établissement d’une route en fonction du temps avec contraintes de débit et de
délai ...................................................................................................................................................54
Figure 4.18 : Taux de paquets livrés avec succès en fonction de la vitesse en respectant les
contraintes de débit et de délai ..........................................................................................................55
Figure 4.19 : Taux de paquets livrés avec succès en fonction du temps avec contraintes de débit et
de délai ..............................................................................................................................................56
Figure 4.20 : Délai moyen de bout en bout en fonction de la vitesse en respectant les contraintes de
débit et de délai..................................................................................................................................56
Figure 4.21 : Délai moyen de bout en bout en fonction du temps avec contraintes ..........................57
de débit et de délai.............................................................................................................................57
Liste des tableaux
Tableau 1 : Paramétrage du contexte de simulation ............................................................ 41

Tableau 2 : Environnement de simulation ........................................................................... 41
Introduction générale sup’com
Introduction générale
Les concepteurs et les fournisseurs de services dans le domaine des télécoms ont choisi d'investir
dans l'intégration de la qualité de service (QoS) pour les réseaux filaires. Au début, les réseaux
sans fil présentaient beaucoup de difficultés à cause de leurs caractéristiques principales telles
que le dynamisme de la topologie et les limites de la bande passante.
On distingue deux classes de réseaux sans fil; les réseaux avec infrastructure qui utilisent
généralement le modèle de la communication cellulaire, et les réseaux sans infrastructures dits ad
hoc.
A l’opposé des réseaux cellulaires, un réseau mobile ad hoc peut être défini comme une
collection d'entités mobiles interconnectées par une technologie sans fil formant un réseau
temporaire sans l'aide de toute administration ou de tout support fixe. Les réseaux ad hoc
peuvent être reliés à d'autres catégories de réseaux (LAN, WAN,…) et donc ils sont très utiles
pour les communications de groupe. De nos jours, plusieurs travaux ont été menés sur de tels
réseaux afin d'intégrer les applications temps réels telles que la voix ou la vidéo exigeant
certaines contraintes au niveau des ressources offertes en terme de délai et de bande passante.
Parmi ces applications temps réels, nous pouvons citer la vidéoconférence qui nécessite 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'implémenter les contraintes de débit et de
délai exigées pour les applications temps réels.
L'objectif de ce projet est d'implémenter la qualité de service sur les protocoles de routage
AODV et MAOV tout en respectant les contraintes de débit, de délai et le couplage des deux.
Notre rapport est organisé de la façon suivante :
Nous avons effectué, dans le premier chapitre, une étude bibliographique sur les réseaux mobiles
ad hoc, et recensé les mécanismes de qualité de service existants.
Dans le deuxième chapitre nous allons analyser les spécifications du protocole de routage
MAODV.
Quand au troisième chapitre, nous présentons les différentes étapes de l'implémentation de la
QoS dans les protocoles AODV et MAODV.
Enfin, le quatrième chapitre traite l'analyse des résultats de simulations effectuées à l'aide du
simulateur réseau NS-2.
Projet de fin d’étude 1

Réseaux ad hoc et QoS sup’com
Chapitre I
Réseaux ad hoc et QoS
I.1 Introduction
Les systèmes de communication cellulaire sont basés essentiellement sur l'utilisation des réseaux
filaires (tel que Internet ou ATM) et la présence des stations de base qui couvrent les différentes
unités mobiles du système. Les réseaux mobiles "ad hoc" sont à l'inverse, des réseaux qui
s'organisent automatiquement de façon à être déployable rapidement, sans infrastructure fixe, et
qui doivent pouvoir s'adapter aux conditions de propagation, aux trafics et aux différents
mouvements pouvant intervenir au sein des nœuds mobiles.
Les réseaux mobiles présentent une architecture originale. En effet, l'atténuation des signaux
avec la distance, fait que le médium peut être réutilisé simultanément en plusieurs endroits
différents sans pour autant provoquer de collisions, ce phénomène est appelé la réutilisation
spatiale (Spatial Reuse) et il sert de base au concept de la communication cellulaire.
I.2 Etat d’art
Un réseau mobile ad hoc, appelé généralement MANET (Mobile Ad hoc NETwork) [1], consiste
en une grande population, relativement dense, d'unités mobiles qui se déplacent dans un territoire
quelconque et dont le seul moyen de communication est l'utilisation des interfaces sans fil, sans
l'aide d'une infrastructure préexistante ou administration centralisée. Le réseau ad hoc est une

collection de nœuds mobiles formant un réseau temporaire a topologie variable et fonctionnant

sans station de base et sans administration centralisée.
Les réseaux appelés GSM ne représentent pas des réseaux ad hoc, car la communication entre les
unités passe obligatoirement par des stations de base du réseau filaire.
I.2.1 Modélisation d’un réseau ad hoc
Un réseau ad hoc peut être modélisé par un graphe Gt = (Vt, Et). Où :

Vt représente l'ensemble des nœuds (i.e. les unités ou les hôtes mobiles) du réseau et Et modélise
l'ensemble des connexions qui existent entre ces nœuds.
Si e = (u,v) appartient à Et, cela veut dire que les nœuds u et v sont en mesure de communiquer
directement à l'instant t.
La figure 1.1 représente un réseau ad hoc de 8 unités mobiles sous forme d’un graphe.
8 Unité mobile
2 5
7 Lien de communication
1 6
3
4
Figure 1.1 : Modélisation d’un réseau ad hoc
La topologie du réseau peut changer à tout moment (voir la figure 1.2), elle est donc dynamique
et imprévisible ce qui fait que la déconnexion des unités soit très fréquente.
Après déplacement des nœuds, la topologie du réseau de la figure 1.1 peut devenir à un moment
donné comme suit :
8 Unité mobile
2
7 Lien de communication
5
1
6
3
Figure 1.2 : Le changement de la topologie des réseaux ad hoc

Dans ce cas, l’ancienne route qui existait entre le nœud 2 et le nœud 8 est perdu car le lien entre
le nœud 2 et le nœud 5 est cassé.
I.2.2 Les applications des réseaux ad hoc
Les applications qui vont s'orienter vers les réseaux ad hoc sont naturellement celles qui ne
peuvent se contenter d'une mobilité restreinte ou reposant sur une infrastructure existante. Nous
trouverons bien sûr dans ces applications les réseaux militaires. Nous y trouverons également les
réseaux d'urgence (incendies, tremblement de terre), et les réseaux temporaires d'exposition ou
correspondant à un événement particulier.
I.2.3 Les caractéristiques des réseaux ad hoc
Les réseaux mobiles ad hoc sont caractérisés par :
• Une topologie dynamique : Les unités mobiles du réseau, se déplacent d'une façon libre
et arbitraire. Par conséquent la topologie du réseau peut changer, à des instants
imprévisibles, d'une manière rapide et aléatoire. Les liens de la topologie peuvent être
unis ou bidirectionnels.
• Une bande passante limitée : Une des caractéristiques primordiales des réseaux basés sur
la communication sans fil est l'utilisation d'un médium de communication partagé. Ce
partage fait que la bande passante réservée à un hôte soit modeste.
• Des contraintes d'énergie : Les hôtes mobiles sont alimentés par des sources d'énergie
autonomes comme les batteries ou les autres sources consommables. Le paramètre
d'énergie doit être pris en considération dans tout contrôle fait par le système.
• Une sécurité physique limitée : Les réseaux mobiles ad hoc sont plus touchés par le
paramètre de sécurité, que les réseaux filaires classiques. Cela se justifie par les
contraintes et limitations physiques qui font que le contrôle des données transférées doit
être minimisé.
• L'absence d'infrastructure : Les réseaux ad hoc se distinguent des autres réseaux mobiles
par la propriété d'absence d'infrastructures préexistante et de tout genre d'administration
centralisée. Les hôtes mobiles sont responsables d'établir et de maintenir la connectivité
du réseau d'une manière continue.

De telles caractéristiques peuvent contrarier l’introduction de la qualité de service dans les

réseaux ad hoc.
I.3 Protocoles de routage dans les réseaux ad hoc

I.3.1 Les protocoles de routage proactifs
Les protocoles de routage proactifs pour les réseaux mobiles ad hoc, sont basés sur la même
philosophie des protocoles de routage utilisés dans les réseaux filaires conventionnels. Les deux
principales méthodes utilisées sont :
• La méthode Etat de Lien ("Link State")
• La méthode du Vecteur de Distance ("Distance Vector").
Les deux méthodes exigent une mise à jour périodique des données de routage qui doit être
diffusée par les différents nœud s de routage du réseau.
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 réactifs
Les protocoles de routage appartenants à cette catégorie, créent et maintiennent les routes selon
les besoins. Lorsque le réseau a besoin d’une route, une procédure de découverte globale de
routes est lancée, et cela dans le but d’obtenir une information spécifiée, inconnue au préalable.
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] représente essentiellement une amélioration de l'algorithme DSDV. Le

protocole AODV, réduit le nombre de diffusions de messages, et cela en créant les routes lors du
besoin, contrairement au DSDV, qui maintient la totalité des routes.
• L'AODV utilise les principes des numéros de séquence à fin de maintenir la consistance des
informations de routage.

• A cause de la mobilité des nœud s dans les réseaux ad hoc, les routes changent fréquemment
ce qui fait que les routes maintenues par certains nœud s, deviennent invalides. Les numéros de
séquence permettent d'utiliser les routes les plus nouvelles (fresh routes).
• De la même manière que dans le DSR [14], l'AODV utilise une requête de route dans le but de
créer un chemin vers une certaine destination. Cependant, l'AODV [2] maintient les chemins
d'une façon distribuée en gardant une table de routage, au niveau de chaque nœud de transit
appartenant au chemin cherché.
• Un nœud diffuse une requête de route (RREQ) dans le cas où il aurait besoin de connaître 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 préalable, ou
→ Si la durée de vie du chemin existant vers la destination a expiré ou le chemin est
devenu défaillant.
• Lorsque la destination reçoit ce message, elle répond par un RREP.
• Le champ numéro de séquence destination du paquet RREQ, contient la dernière valeur connue
du numéro de séquence, associé au nœud destination. Cette valeur est recopiée de la table de
routage. Si le numéro de séquence n'est pas connu, la valeur nulle sera prise par défaut. Le
numéro de séquence source du paquet RREQ contient la valeur du numéro de séquence du nœud
source.
• A fin de maintenir des routes consistantes, une transmission périodique du message "HELLO"
est effectuée. Si trois messages "HELLO" ne sont pas reçus consécutivement à partir d'un nœud
voisin, le lien en question est considéré défaillant.
• Le protocole AODV ne présente pas de boucle de routage, en outre il évite le problème
"counting to infinity" de Bellman-Ford, ce qui offre une convergence rapide quand la topologie
du réseau ad hoc change.
Formats des messages RREQ :
Type J R Réservé Nombre de sauts

Identité
@ destination
Numéro de séquence destination
@ source

• Type : 1
• J : join flag ; réservé pour le multicast.
• R : Repair flag ; réservé pour le multicast.
• Réservé : envoyé à 0 ; ignoré à la réception.
• Nombre de sauts : le nombre de sauts entre la source et le nœud manipulant la requête.
• Identité : un numéro qui identifie d’une manière unique le RREQ.
• @ destination : l’adresse IP de la destination
• Numéro de séquence destination : Le dernier numéro de séquence reçu au passé par la source
pour une route vers la destination
• @ source : l’adresse IP du nœud qui a émis la requête.
• Numéro de séquence source : le numéro de séquence courant à utiliser dans l’entrée de la route
qui pointe vers le nœud source de la requête.
Formats des messages RREP :
Type L R U Réservé Taille préfixe Nombre de sauts
@ destination
Duré de vie
• L : si L = 1 alors il s’agit d’un message hello

• U : update flag ; réservé pour le multicast.
• Taille préfixe : si différent de zéro, il spécifie que le saut suivant indiqué peut être utilisé pour
n’importe quel nœud avec le même préfixe (comme il est défini par la taille préfixe) que la
destination.
• Durée de vie : Le temps pendant lequel les nœuds recevant le RREP considèrent la route
valide.
I.4 QoS dans les réseaux ad hoc
La QoS représente le niveau de performance d’un service offert par un réseau à un utilisateur.
Pour introduire la QoS dans les réseaux filaires, l’IETF a proposé les modèles "IntServ" [7] et
"DiffServ" [8]. Pour assurer la QoS, ces deux algorithmes n'ont qu'à spécifier la méthode de
réservation de ressources.

Dans les réseaux 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 d’une communication,
tout en optimisant l’utilisation des ressources disponibles.
Le modèle IntServ [7] s’avère donc inadaptée à l’environnement ad hoc alors que le modèle
DiffServ [8] semble le mieux adapté aux réseaux mobiles.
Il existe deux types d'algorithme traitant les mécanismes de la QoS dans les réseaux 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 indépendamment des protocoles de
routage. Ils sont basés sur les concepts "IntServ" et "DiffServ". Ils représentent le
modèle général de la QoS dans les réseaux ad hoc.
I.4.1 Les métriques de QoS pour un environnement ad hoc
La QoS se manifeste par un ensemble de paramètres qui sont soit qualitatives (qualité de la voix,
de l'image,…) soit quantitatives (mesurés : délai, débit, gigue,…).
Les métriques les plus importants pour les réseaux ad hoc sont :
¾ Délai : Ce paramètre représente le délai de bout en bout nécessaire pour transmettre un

paquet de données depuis la source vers la destination. C'est une métrique additive.
¾ Bande passante (Débit) : Ce paramètre définit la quantité maximale de données qu’un lien
peut transmettre pendant un intervalle de temps donné. C’est une métrique concave. Le
réseau doit répondre à cette contrainte dans la transmission de la vidéo.
¾ Perte de paquet : Ce paramètre indique le taux de suspension de la transmission des paquets

erronés. Ce paramètre est utile pour les applications Web, transfert de fichier, chat et
messagerie électronique.
Variance de délai (gigue) : Ce paramètre décrit la variation de délai de transmission entre les
différents paquets. Il est classé parmi les métriques additives. Le réseau doit respecter ce
paramètre lors de la transmission de la voix, la vidéo conférence etc.

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 réactif avec qualité de service. Il réduit au maximum les
messages de contrôle. Il est basé sur une élection dynamique d’un sous ensemble de stations qui
forment un coeur de réseau stable. Ces stations sont appelées « routeurs cœur ». Des
informations sur les liens stables disposant d’une grande bande passante sont propagées entre les
nœuds cœur. Le calcul des routes est effectué par ces nœuds en utilisant des informations locales.
Utilisé dans des réseaux de petite à moyenne taille (de dizaines à des centaines de nœuds), il est
basé sur trois composantes essentielles :
– Extraction d’un coeur du réseau : un ensemble de nœud est dynamiquement choisi pour
calculer les routes et maintenir l’état des liens du réseau. L’avantage d’une telle approche est
qu’avec un ensemble réduit de nœud s les échanges d’informations d’état et de route seront
minimisés, évitant ainsi des messages supplémentaires circulant dans le réseau. En outre, lors
d’un changement de route, seuls les nœuds du cœur serviront au calcul,
– Propagation d’état de lien : le routage avec qualité de service est réalisé grâce à la propagation
des informations sur les liens stables avec une grande bande passante.
L’objectif est d’informer les nœuds distants sur les liens de grande capacité, alors que les liens de
faible capacité sont connus au niveau local (les nœuds n’ont pas une information sur la topologie
globale du réseau),
– Calcul de route : celui-ci est basé sur la découverte et l’établissement d’un plus court chemin
vers la destination satisfaisant la bande passante demandée. Des routes de secours sont utilisées
lors de la reconstruction de la route principale, quand cette dernière est perdue. La reconstruction
peut être locale (à l’endroit de la cassure), ou à l’initiative de la source.
Au lieu de calculer une route avec un minimum de saut, l’objectif principal de CEDAR est de
trouver un chemin stable pour garantir plus de bande passante. Dans ce protocole de routage, les
nœud s du cœur du réseau auront plus de trafics à gérer, en plus des messages de contrôle (pour
la découverte et la maintenance des routes). En outre, en cas de forte mobilité, la convergence de
l’algorithme est difficile à atteindre.

Unité mobile
Nœud coeur
Lien de communication
8 Lien virtuel
2 5
7
1 6
3
4
Figure 1.3 : Nœud cœur en CEDAR
I.4.2.2 Ticket-Based QoS Routing
C'est un protocole de routage distribué [11], qui autorise des informations d’état imprécises
durant la phase de calcul de la route. Il permet de réduire la quantité des messages de routage
diffusée pour la découverte de la route, en publiant un certain nombre de ’tickets logiques’.
Chaque message de découverte (ou d’observation) de route doit avoir au moins un ticket. Quand
un message arrive à un nœud, il peut être divisé en plusieurs messages d’observation, qui sont
relayés vers les prochains sauts.
Chaque message fils contiendra un sous ensemble des tickets de son message père.
Evidemment, un message ayant un seul ticket ne peut être divisé. Lors de l’arrivée d’un message
de découverte de route à la destination, le chemin saut par saut est connu et les informations de
délai ou de bande passante peuvent être utilisées pour effectuer la réservation de ressources pour
la route répondant aux besoins de la qualité de service. Le nombre de tickets générés est fonction
de la précision des informations d’états disponibles à la source et les besoins de la qualité de
service de la communication. Plus de tickets sont publiés dans le but d’augmenter la chance de
trouver un chemin désiré.
Dans les réseaux filaires, une distribution de probabilité, selon des informations sur le délai ou la
bande passante, peut être calculée. Cependant, cela reste inapproprié dans les réseaux ad hoc où
les liens sans fil sont sujets à des cassures, où les informations d’états sont imprécises. Pour cela,
un modèle simple a été proposé pour l’algorithme Ticket Based.

Il utilise l’historique et l’estimation des variations du délai, et une formule de lissage pour
calculer le délai courant. Pour s’adapter aux changements de topologie, l’algorithme autorise
différents niveaux de redondance de route. Il utilise aussi des techniques de réparation et de
reroutage pour la maintenance des routes. La réparation 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 Modèles de QoS pour les réseaux ad hoc
I.4.3.1 Flexible quality of service model for MANETs (FQMM)
Le modèle FQMM [5] repose sur une architecture réseau plate (non hiérarchique), constituée
d’une cinquantaine de nœuds mobiles, formant un domaine DiffServ [8]. Il combine les
propriétés des modèles filaires IntServ [7] et DiffServ, en offrant une méthode
d’approvisionnement hybride : par flux, pour les trafics prioritaires, et par classe pour les autres
trafics. Dans le réseau, les nœuds peuvent avoir des rôles différents suivant les trafics existants :
nœud d’entrée du trafic, intermédiaire ou de sortie. Les nœuds d’entrée permettent de marquer et
classifier les paquets, qui seront ensuite relayés par les nœuds intermédiaires suivant leurs PHB
(Per Hop Behavior), jusqu’à arriver au nœud destinataire. Ce modèle repose essentiellement
sur la couche IP, où les fonctionnalités sont séparées en deux grands plans : le plan relayage de
données et le plan contrôle et gestion. Les techniques d’ordonnancement et de gestion de
mémoires tampons sont étudiées. Dans ce modèle, le protocole de routage est supposé fournir
des routes ayant suffisamment de ressources.
L’avantage d’une telle approche est la possibilité d’interfacer le réseau avec l’Internet, vu les
mécanismes de qualité de services offerts qui sont proches des protocoles filaires.
Cependant, plusieurs mécanismes ainsi que l’interaction avec la couche MAC restent à définir
pour s’adapter aux conditions variables du réseau ad hoc.
I.4.3.2 Service differentiation in wireless ad hoc networks (SWAN)
SWAN [6] est un modèle réseau sans état basé sur des algorithmes de contrôle distribués dans le
but d’assurer une différenciation de services dans les réseaux ad hoc. Il offre la priorité (au

niveau paquet) aux trafics temps réel en contrôlant la quantité de trafics best effort acceptée par
nœud. Pour accepter un nouveau trafic temps réel, le contrôle d’admission sonde la bande
passante minimale disponible sur la route (valide et obtenu par un protocole de routage). Une
décision à la source est alors prise suivant la bande passante obtenue. Pour maintenir la qualité
de service des trafics déjà acceptés, le débit des trafics best effort est régulé en utilisant les
mesures de délais au niveau MAC comme paramètre. Un classificateur et un shaper permettent
de différencier les deux types de trafic. En cas de congestion, les bits ECN (Explicit Congestion
Notification) de l’entête des paquets IP sont positionnés pour permettre à la source de re-initier le
contrôle d’admission. Si la route ne dispose pas d’assez de bande passante, le trafic est supprimé.
Ainsi, SWAN permet de fournir une QoS logiciel (soft QoS).
Un flux prioritaire admis n’est pas sûr d’avoir des garanties pour l’entière durée de la
communication, et peut à tout moment être violé par d’autres demandes de trafics. Un
mécanisme de contrôle de débit des flux best effort n’est pas à lui seul suffisant pour offrir des
garanties aux applications temps réel. En outre, dans cette approche, le protocole de routage ainsi
que la couche d’accès au médium sont de type best effort.
I.4.3.3 Modèle iMAQ
Le modèle iMAQ [10] fournit le support des transmissions des données multimédia dans un
MANET [1]. Le modèle inclut une couche ad hoc de routage et une couche de service logiciel
(Middleware). Dans chaque nœud, ces deux couches partagent les informations et communiquent
afin de fournir les garanties de qualité de service aux trafics multimédia. Le protocole de routage
est basé sur la prédiction de la position des nœuds (predictive location-based) et orienté qualité
de service. La couche Middleware communique également avec la couche application et la
couche réseau et essaye de prévoir le partitionnement du réseau. Pour fournir une meilleure
accessibilité aux données, il réplique les données entre les différents groupes du réseau avant
d’effectuer le partitionnement.
I.4 Conclusion
Tous ces modèles et ces protocoles ne peuvent pratiquement pas servir pour des applications qui
nécessitent des protocoles de routages adaptés aux communications de groupes. Il faudra donc
introduire la QoS au niveau des protocoles de routage multicast qui sont les mieux adaptées pour
les applications de ce type. Nous allons détaillé dans le chapitre suivant les spécifications du
protocole de routage MAODV classique.

Le protocole de routage MAODV sup’com
Chapitre II
Le protocole de routage MAODV
II.1 Généralisation
MAODV [3] est un protocole de routage réactif pour les réseaux ad hoc dédié au trafic multicast.
C’est en fait un protocole obtenu par extension du protocole AODV, ce dernier est dédié au trafic
unicast dans les réseaux ad hoc. Le MAODV comme tout autre protocole de routage multicast
se base sur le concept de groupe. Rappelons qu’un groupe multicast est un ensemble de nœuds
qui se communiquent les informations par diffusion sélective dans un réseau à topologie
dynamique tel que le réseau ad hoc. Le MAODV fait partie de la famille des protocoles "Tree-
based" c'est-à-dire qu’il respecte une structure arborescente pour livrer des paquets de données
pour un groupe multicast. Chaque groupe multicast possède une adresse multicast unique de
groupe. Selon les spécifications du MAODV, les groupes multicast sont organisés en une
structure arborescente (voir la figure 2.1) composée 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 l’arbre et
appartiennent au groupe de l'arbre. Associés à 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 périodique de messages "Group-Hello"
(GRPH) dans tout le réseau. Le chef de groupe maintient également le numéro de séquence du
groupe, qui est propagé dans le réseau à travers le message GRPH.

Figure 2.1: Arbre de groupe multicast
Chaque nœud dans le réseau peut maintenir trois tables. La première 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 nœud parmi les autres du réseau.
Un cas particulier qui peut se présenter est lorsque l’adresse de destination est une adresse
multicast, ce qui se produit quand le nœud n'est pas un membre d'arbre multicast mais doit
envoyer des paquets de données multicast à un groupe multicast.
(-:-) [source: prochain saut vers la source]
[-:-] [destination: prochain saut vers

(1:1) la destination]
(1:3) RREQ
RREP
[8:8] Group leader
6
Membre de groupe
Membre de l’arbre
Figure 2.2 : Construction de la table de routage unicast

La seconde table est la table de routage multicast dans laquelle, sont enregistrés les prochains
sauts vers la structure arborescente de chaque groupe multicast du réseau. Dans cette table,
chaque entrée représente une structure arborescente de groupe. Chaque nœud qui appartient à cet
arbre de groupe devrait maintenir de telles entrées, avec sa propre identité comme : chef de
groupe, membre de groupe ou routeur. La construction de cette table est détaillée 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 nœud plus près 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 nœuds dans l'arbre devraient avoir un et seulement un saut en amont.
La troisième table est la table du Chef de groupe "Group Leader Table". Elle enregistre l’adresse
du groupe multicast courant avec l’adresse du chef de groupe et le prochain saut vers ce chef de
groupe, et toutes ces informations sont reçues à travers les messages GRPH périodiquement
diffusées. La figure 2.3 illustre la construction de cette table et la diffusion des messages GRPH.
Envoie du message GRPH

[-:- ] [destination:prochain saut
[6:8]
[6:3] vers la destination]
[6:6]
Group leader
Membre de groupe
6 Membre de l’arbre
[6:6]
[6:6]
[6:5]
[6:6]
[6:9]
[6:4]
Figure 2.3 : Construction de la table du group leader

II.2 Découverte et maintenance de route pour atteindre l’arbre
Etant donné que tout nœud du réseau qu’il soit membre ou pas d’un groupe multicast peut
générer un trafic multicast, la découverte de route pour atteindre un nœud multicast peut se faire
en deux étapes lorsque le nœud émetteur de données n'est pas membre de l’arbre :
) La première étape :
Elle consiste à trouver une route entre le nœud émetteur de données et un membre de l’arbre;
après que ce membre de l’arbre ait reçu les paquets de données multicast, il les propage dans
tout l'arbre, atteignant ainsi chaque membre du groupe. Pour accomplir cette première étape on
utilise le mécanisme spécifique à AODV [2] pour la découverte et l'entretien de route pour
atteindre un nœud.
Le nœud émetteur de données lance un paquet RREQ pour demander un itinéraire à l’adresse
multicast du groupe. Habituellement, ce RREQ est identique au RREQ utilisé dans AODV, sans
aucun champ joins ni diffusion dans le réseau, mais avec le "Group Leader Table". En effet le
nœud source peut connaître déjà un itinéraire pour atteindre le chef de groupe en utilisant les
informations enregistrées dans le "Group Leader Table". Le RREQ peut être envoyé d’une
façon unicast vers le chef de groupe si c'est la première fois que ce nœud envoie le paquet
RREQ. Pendant la propagation de RREQ, la route inverse vers le nœud source est construite
comme décrit dans le protocole AODV. Tout nœud n’appartenant pas à cet arbre multicast mais
ayant une route fraîche à cette adresse multicast, ou n'importe quel membre de l'arbre avec le
chef de groupe connu peut répondre à ce RREQ avec un RREP. Tandis que le RREP est envoyé
au nœud source le long de la route inverse, chaque nœud intermédiaire et le nœud 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
première étape, le nœud de destination est un membre de l'arbre.
) La deuxième étape :
La deuxième étape est accomplie avec la construction de l'arbre multicast, qui est décrite dans la
section II.3. Pendant l'expédition de paquets de données multicast, chaque nœud vérifie
d'abord s’il est lui-même membre de l'arbre multicast. S’il n'est pas un membre de l'arbre, il
vérifiera sa table de routage unicast pour trouver le prochain saut vers l'adresse multicast. S'il

trouve les informations, les paquets de données sont expédiés vers le prochain saut sinon il
enverra un RREP au nœud source pour que ce dernier initialise une nouvelle procédure de
découverte de route. Si le nœud lui-même est membre de l’arbre, il suivra sa table de routage
multicast pour expédier les paquets. Lors de l’utilisation de la table de routage Unicast pour
expédition des paquets de données multicast, on utilise la détection de la couche MAC pour
détecter la rupture de lien sur les routes.
II.3 Construction de l’arbre
Les mêmes messages RREQ et RREP utilisés dans AODV [2] sont adaptés pour être employés
pour la construction de l'arbre dans MAODV [3]. En outre, le message MACT est introduit pour
finir la dernière étape de construction de l'arbre. Lorsqu’un nœud, n’appartenant pas à un groupe
multicast, veut rejoindre ce dernier, ce nœud lance un message RREQ avec un champ « Join »
(RREQ-J). Avant d'envoyer RREQ-J, le nœud crée une entrée 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 nœud de l'arbre n’est pas un membre de groupe
et veut devenir membre de groupe, il change simplement son identité, enregistrée dans sa table
de routage multicast en tant que routeur à un membre de groupe.
Habituellement, RREQ-J est diffusé dans le réseau, mais si le nœud peut obtenir des
informations sur le chef de groupe et les informations pour atteindre ce chef de groupe en
vérifiant sa propre « Group Leader Table » et que c’est la première fois qu'il envoie RREQ-J,
RREQ-J peut être envoyé d’une façon unicast vers le chef de groupe. Pendant la propagation de
RREQ-J, la route inverse au nœud source de la requête est établie dans la table de routage
unicast. Quand un nœud reçoit un RREQ-J non dupliqué, seuls les membres de l'arbre avec un
numéro de séquence du groupe multicast supérieur ou égal à celui du RREQ-J peuvent répondre
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 mémoire cache sans ajouter un nouveau saut valide dans l'entrée (figure 2.4). Si plus tard
le nœud reçoit un autre RREP-J indiquant une meilleure branche (c'est-à-dire un numéro de
séquence plus grand ou un nombre de saut plus petit au cas où le numéro de séquence est le
même), il met les nouvelles informations en mémoire cache et propage le RREP-J vers le nœud
source; dans le cas contraire il abandonne les derniers RREP-J.

Un nouveau message, MACT (Multicast Route Activation), est utilisé pour greffer une branche à
l'arbre multicast. Lorsque le nœud source envoie RREQ-J et attend un temps spécifique égal à
RREP_WAIT_TIME [13], il vérifie s'il a déjà reçu un quelconque RREP-J et mémorisé les
informations correspondantes. Si oui, il envoie un MACT avec un champ « Join » MACT-J vers
le nœud en amont mémorisé qui va être ajouter à sa table de routage multicast. Chaque nœud
recevant un message MACT-J devrait ajouter dans sa table de routage multicast, le nouveau
prochain saut en aval indiquant le nœud auprès duquel il a reçu le MACT-J (figure 2.5). S’il est
membre de l'arbre, alors la branche est finalement greffée ; sinon, il vérifiera sa propre mémoire
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 nœud .
RREQ-J
RREP-J
[-] prochain saut en amont
Mémoire cache
[-:-] [source:prochain saut vers la source]

[1:3]
Group leader
Membre de groupe
[1:2] [8]
6
[1:1] [1:1]
1 [7]
[1:5]
[5]
Figure 2.4 : Les opérations de jointure de l’arbre, propagation des messages RREQ-J et RREP-J
Si le nœud source du message RREQ essaye plusieurs fois (RREQ_RETRIES) de se joindre à un

arbre de groupe, mais n'a pas reçu de message RREP-J, alors cela signifie que le groupe
recherché n’existe pas dans le réseau ou bien que le nœud source ne peut pas joindre le groupe à
cause de la partition du réseau. Dans ce cas le nœud source demandeur devient le premier nœud

dans ce groupe et agit comme un chef de groupe pour maintenir le numéro de séquence du
groupe et la structure arborescente.
L’envoi des paquets de données multicast se fait par diffusion dans tout l’arbre afin
d’économiser la largeur de bande. Mais nous ne savons pas si tous les voisins dans l'arbre
reçoivent correctement les données car il n’y pas de réservation de canal pour obtenir un
feedback de réception.
MACT-J
[-,-] [Prochain saut en amont:
Prochain saut en aval]
6 Group leader
[7: 1 ] Membre de groupe
1
[5] [6: 5]
Figure 2.5 : Propagation des MACT et construction des tables de routage multicast
II.4 La maintenance de l’arbre multicast
La maintenance de l'arbre multicast est beaucoup plus compliquée que l'entretien de route
unicast. Cette complexité émane du fait que l'entretien inclut la propagation périodique du
message GROUP-HELLO (GRPH), entretien de la connectivité avec les voisins, le choix du
Chef de groupe, la révocation d'adhésion, et la fusion d'arbres.

II.4.1 la propagation périodique d’un GRPH
Le chef de groupe doit périodiquement diffuser un message GRPH du groupe dans tout le réseau
entier, pour indiquer l'existence de ce groupe et de son état actuel. En recevant le message de
GRPH, chaque nœud 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 nœud qui n'est pas un membre d'arbre retransmet le GRPH reçu pour la première fois.
Un nœud membre d'arbre qui reçoit un message GRPH de ses propres nœuds en amont peut
utiliser le GRPH pour mettre à jour leur numéro de séquence courant du groupe, chef de groupe
courant et la distance courante entre le nœud 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 l’arbre reçoit un message GRPH de la part d’un nœud autre que son propre nœud en
amont, il cherche d’abord l’information sur le chef de groupe enregistrée dans sa table de routage
multicast. Si l’information est identique à celle indiquée dans le message GRPH, alors ce GRPH
est rejeté et le nœud attente un prochain GRPH. Mais si l’information n’est pas identique à celle
indiquée dans le GRPH, il existe alors un autre arbre avec la même adresse de groupe multicast
mais pas le même chef de groupe, et ces deux arbres peuvent être reliés. Ainsi, le processus de
fusion d'arbres commence. La fusion d'arbre est lancée 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 indiquée dans le message GRPH, le nœud abandonne ce GRPH.
II.4.2 la maintenance de la connectivité entre les nœuds voisins
Puisque le trafic multicast est diffusé dans tout l'arbre, nous ne pouvons pas utiliser la détection
de la couche MAC pour détecter la rupture de liens dans l'arbre. Pour cela, les messages
périodiques « Neighbor-Hello » à un seul saut sont utilisés. Et pour réduire le trafic de ces
messages, ces derniers sont envoyés par diffusion avec des paquets de données. La connectivité
des voisins dans l'arbre est maintenue par une réparation locale quand le nœud 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 spécifique (habituellement égale à trois fois l'intervalle de temps du
message « Neighbor-Hello ». Après avoir détecté une rupture de lien, le nœud en aval supprime
son prochain saut (seulement celui en amont) de sa table de routage multicast, et devient alors un
nœud source d’un message RREQ-J pour découvrir une nouvelle branche (figure 2.6). Ce
RREQ-J est différent du RREQ-J utilisé pour le nœud qui n’est pas un membre d'arbre mais veut

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 nœuds descendants de répondre au RREQ-J, sans
compter la condition pour répondre à ce RREQ-J (seulement le membre d'arbre avec le même ou
un plus grand numéro de séquence de groupe peuvent répondre à ce RREQ-J). Quand un
membre d'arbre reçoit un RREQ-J avec extension, il doit vérifier son propre « hop-count » vers
le chef de groupe, seul le membre de l'arbre avec un « hop count » égal ou plus petit peut
répondre. Et le processus devient ensuite le même que celui vu dans la section II.3 (construction
de l’arbre).
6
6
3
RREQ-J
3 7
7 [-,-,…:-] Table multicast
1 5 1
Liaison
5 [8,2:1] 9
9 [2,8:7]
8 2
8 2
10
10
Figure 2.6 : Réparation d’arbre
En plus de cela, si suite à une réparation locale, les changements interviennent sur les
informations de groupe du nœud source tels que le chef de groupe le numéro de séquence du
groupe et le hop-count vers le chef de groupe, ce nœud enverra un GRPH avec un champ de
mise à jour (GRPH-U) à ses nœuds descendants un à un d’une façon unicast pour mettre à jour
leur information de groupe. Si le nœud source essaye plusieurs fois (RREQ_RETRIES
tentatives) de réparer cette branche, mais ne reçoit pas de réponse RREP-J, alors une partition

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 décrit dans la section suivante (choix du Chef de groupe).Si ce
n'est pas le nœud descendant mais le nœud ascendant qui réalise la rupture de lien, le nœud
ascendant supprime le prochain saut (un de ses liens descendants) dans sa table de routage
multicast. Si ce nœud ascendant n'est pas un membre de groupe, il devient une feuille sans aucun
nœud en aval, et si après ça il garde encore cet état, alors commence le processus de révocation
« self-prune » décrit dans la section (Révocation des membres de l’arbre).
II.4.3 La sélection 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 adhésion au groupe. Quand le partitionnement d'arbre se produit, et le nœud 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 nœuds descendants, parce que
le nœud divisé n'a aucun nœud ascendant comme le chef précédent de groupe n'a aucun
ascendant non plus. Si le nœud courant a un seul nœud descendant, il supprime l'entrée pour ce
groupe dans sa table de routage multicast pour indiquer qu’il n'appartient plus à l'arbre, et envoie
un MACT avec un champ « prune » (MACT-P) vers ce nœud descendant, indiquant qu'il quittera
l'arbre et que ce dernier a besoin d’un chef (figure 2.8).
Group leader
6
6 Membre de groupe
3
3
[-,-,…:-] Table multicast
7
7
1 5 1
5
9 [2,8:7]
[8,2:] 9
8 2 [10:9]
8 [10:9]
2
10
10
Figure 2.7 : Sélection du group leader 1ère cas

Si le nœud courant a plus qu’un nœud en aval, il sélectionne un descendant, change sa direction
d'un nœud en aval en un nœud en amont, et envoie un MACT avec un champ de « group
leader » (MACT-GL) vers ce nœud, pour indiquer qu'il existe une autre branches dans l'arbre et
que ce dernier a besoin d’un chef. Ainsi le nœud descendant peut recevoir un MACT-P ou un
MACT-GL de son nœud ascendant.
En recevant un MACT-P de son ascendant, le nœud supprime sa liaison ascendante de sa table

de routage multicast. En recevant un MACT-GL, le nœud change la direction ascendante en une
direction descendante. Puis si ce nœud est un membre de groupe, il devient le nouveau chef de
groupe. Sinon, il poursuit le même 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 périodiquement le message GRPH dans le réseau entier. S'il a un
quelconque nœud en aval, il enverra également un GRPH-U à chaque nœud descendant d’une
façon unicast, pour indiquer le nouveau chef de groupe et mettre à jour l'information du groupe
dans leur table de routage multicast.
Group leader
6
6 Membre de groupe
3
3
MACT-P
7
7
5 1
5 1 [9:7]
9
9
8 2
8 2
10
10
Figure 2.8 : Sélection du group leader 2ème cas

Group leader
6
6 Membre de groupe
3
3 MACT-GL
7
1 5 1
5
9 [2,8:7] [8:2] 9
8 [9,10: ]
8 2 [10:9] 2
10 10
Figure 2.9 : Sélection du group leader 3ème cas
II.4.4 Révocation des membres de groupe
Un membre de groupe, y compris le chef de groupe, peut retirer son adhésion au groupe à tout
moment. Si ce nœud est le chef de groupe, il change sa propre identité en un routeur, et un
nouveau chef de groupe doit être choisi. Si le nœud n'est pas le chef de groupe, d'abord il retire
son adhésion en changeant sa propre identité en un routeur, et puis vérifie s'il a un quelconque
nœud en aval. S'il a des nœuds descendants, il doit rester dans l'arbre pour relier les membres de
groupe. Sinon, il peut lancer la procédure « self-prune » pour se retirer de l'arbre multicast. Le
« self-pruning » provoque le départ du nœud de l'arbre multicast, ainsi elle doit mettre à jour sa
table de routage multicast en supprimant les entrées à cette adresse multicast. Ainsi il envoie un
MACT-P à son nœud ascendant pour l’informer qu'il n'appartient plus à l'arbre. Si la réception
d'un MACT-P fait du nœud ascendant une feuille et s’il n'est également pas un membre de
groupe, il peut se retirer de l'arbre de la même façon. La procédure se termine quand le dernier
nœud qui reçoit un MACT-P est membre de groupe ou différent d’une 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é d’un nœud en aval vers un nœud en amont, alors que le MACT-P utilisé pour le choix
de chef de groupe est envoyé d'un nœud en amont vers nœud en aval.

Group leader
6 Membre de groupe
6
3 3 MACT-P

7
1
5 5 1
9 [2,8:7]
9 [8:7]
8 2 [10:9] 8 2
10
10
Figure 2.10 : Procédure « self prune »
II.4.5 Fusion d’arbres
La fusion d'arbre peut être détectée quand un membre d'arbre avec une plus petite adresse de
chef de groupe reçoit un GRPH produit par un autre chef de groupe avec une plus grande adresse
pour le même groupe.
Tout nœud 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, d’une façon 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 nœud en aval vers un nœud en amont jusqu'à
atteindre le chef de groupe. Si le chef n'a pas autorisé à un nœuds de reconstruire l'arbre, il peut
renvoyer un RREP avec un champ « repair » (RREP-R) à ce nœud source de la requête RREQ-
R. Durant l’envoi du message RREQ-R, la route inverse au nœud source demandeur est formée,
ainsi le RREP-R suit cette route inverse jusqu’au nœud source demandeur. Un cas particulier est
que le chef lui-même peut réaliser 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 l’arbre commence quand le nœud demandeur envoie d’une façon unicast
un RREQ avec un champ « join-and-repair » (RREQ-JR) au chef de groupe avec une plus grande
adresse, puisque quand le nœud demandeur reçoit un GRPH de ce chef de groupe, il enregistre

déjà 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é d’une façon unicast du nœud
descendant vers le nœud ascendant jusqu'à ce que le chef de groupe soit atteint. Durant
l’acheminement du RREQ-JR, la route inverse vers le nœud source est établie. Quand le chef de
groupe avec l'adresse plus grande reçoit le RREQ-JR, il renvoie un RREP-JR au nœud source
demandeur le long de la route inverse. Pendant l’acheminement du RREP-JR, l'information de
groupe, telle que l'adresse de chef de groupe, le numéro de séquence du groupe, et le « hop-
count » 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 nœud en amont vers un
nœud en aval. Si un nœud non membre de l’arbre est atteint, ce nœud devient un routeur pour le
nouvel arbre, ajoutant deux prochains sauts dans sa table de routage multicast, indiquant les
nœuds ascendant et descendant correspondants.
Quand le membre d'arbre ayant la plus petite adresse de groupe est atteint, il ajoute le nœud à
partir duquel il a reçu RREP-JR comme son prochain saut en amont, change l’ancien nœud
ascendant à une direction descendante. Puis le RREP-JR se propage d'un nœud en aval vers un
nœud en amont dans l'arbre avec l'adresse la plus petite de chef de groupe.
Group leader
6 6 Membre de groupe
3 3 RREQ-JR/RREP-JR
RREQ-JR/RREP-R
7 7 [-,-,…:-] Table multicast
5 5
[8:2]
[8,2: ] 9 1 9 1
8 [10:9] 8 [10,9:1]
2 2
10 10
Figure 2.11 : Fusion d’arbres

À chaque étape, le nœud courant change la direction descendant en une direction ascendante
pour le prochain saut duquel il reçoit le RREP-JR, change le nœud en amont en un nœud en aval,
et expédie le RREP-JR vers le vieux nœud 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 nœuds
descendants en un nœud ascendant, et change son identité de chef de groupe en un membre de
groupe, ainsi le nouvel arbre est complètement établi. Après ces étapes, l’ancien chef de groupe
devrait diffuser d’une façon unicast le message GRPH-U à ses nœuds en aval, leur indiquant le
changement d’information de groupe.
II.5 Conclusion
Le protocole de routage MAODV [3] est utile pour des applications tels que la vidéoconférence,
le travail de collaboration et les jeux distribués. Ce type d’applications, nécessite un certain
niveau de QoS (bande passante, délai de transmission, …).
Le chapitre suivant développe une méthode pour implémenter l’aspect QoS dans ce protocole.

Implémentation de la QoS au niveau routage sup’com
Chapitre III
Implémentation de la QoS au niveau routage
III.1 Introduction
Dans cette partie nous développons notre méthode pour l’implémentation de la qualité de service
sur le protocole de routage MAODV [3] tout en respectant l’une des contraintes de délai ou de
débit et qu’on va ensuite les coupler.
Nos algorithmes vont être exécutés au niveau de chaque nœud jusqu’au traçage de la route.
L’algorithme consiste en une estimation de l’une des deux contraintes au niveau d’un lien. Si
cette contrainte est assurée par ce lien, alors il est choisi pour construire un itinéraire vers la
destination. Un nœud peut estimer le délai ou la bande passante au niveau d’un lien en utilisant
les informations propagées par les messages RREQ. Nous avons donc ajouté des champs
supplémentaires au niveau du message RREQ à fin de les utiliser dans la procédure de
l’estimation du délai ou de la bande passante.
III.2 Implantation de la contrainte de débit

III.2.1 Extensions apportés au message RREQ
Lorsqu’un nœud reçoit un RREQ, il va estimer la bande passante disponible au niveau de son
lien avec le nœud source du RREQ. Pour ce faire, ce nœud a besoin de connaître le temps de
transmission de ce paquet RREQ.

Nous allons donc ajouter au niveau du message RREQ un nouveau champ permettant le calcul
de ce temps. L’information que peut apporter le paramètre enregistré dans ce champ est le
moment de l’émission d’un RREQ. En d’autre terme, à la réception d’un RREQ, un nœud peut
connaître, en plus du temps de son réception, le temps de son émission par le nœud émetteur de
ce même RREQ.
La figure suivante montre l’utilité de ce champ :
RREQ, ts
N1
ts
N2
tr
Figure 3.1 : Première extension apportée au message RREQ
Deux événements s’exécutent au niveau des nœuds N1 et N2 :
¾ Emission du RREQ : A l’émission du RREQ, N1 va remplir le nouveau champ par

l’instant de l’émission (ts).
¾ Réception du RREQ : Lorsque le nœud N2 reçoit le message RREQ, il enregistre le

moment de cet événement (tr) (CURRENT_TIME). Il va ensuite extraire l’information
qui lui permet de connaître le moment de l’émission 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 qu’un lien peut offrir comme débit et ce que la source demande,
nous allons ajouter au niveau du message RREQ un champ contenant le débit demandé par la
source (figure 3.2).
RREQ, d1
N1
N2
Figure 3.2 : Deuxième extension apportée au message RREQ
Après avoir estimé le débit que peut offrir le lien, N2 va extraire du message RREQ
l’information qui lui permet de connaître le débit minimum demandé par N1 (d1). Le nœud N2

va finalement comparer entre ce qui est demandé par N1 (d1) et ce que le lien peut offrir comme
débit.
Nous allons ajouter au message RREQ deux champs qui contiennent le temps de l’émission du
message et le débit demandé par la source. Ces extensions représentent en fait des informations
utiles pour le nœud récepteur du RREQ lui permettant d’estimer le débit et de prendre la bonne
décision pour le choix du lien en cours.
III.2.2 Estimation de débit
Une évaluation de débit peut être faite simplement en émettant des paquets RREQ et en mesurant
les délais correspondants :
d N 1N 2 = t r − t s (3.1)
Le nœud N2 peut maintenant estimer le débit maximal sur le lien N1 N2 :
T
Débit sur le lien = (3.2)
d N 1N 2
T : Taille du paquet RREQ,
d N 1N 2 : Délai de transmission du même paquet entre deux nœuds adjacents.
III.2.3 Fonctionnement de l’algorithme
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 débit exigée. Si oui, on lance le trafic de
données sur ce chemin. Dans le cas où un lien intermédiaire est brisé, on lance le mécanisme de
maintenance de route.
Si un nœud veut émettre des données, il va lancer la procédure de recherche d'un chemin vers la
destination selon la contrainte de débit qu’il exige ;
Le nœud source diffuse un paquet RREQ (au format intégrant la QoS) à tous ses nœuds voisins
voulant assurer avec eux sur le lien qui les sépare un certain débit exigé. Si un nœud voisin ne
dispose pas de chemin vers la destination dans sa table de routage, il effectue les opérations de
calcul de (3.1) et (3.2). S’il 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 débit vers la destination dans la table de routage,
dans ce cas, on empreinte ce même chemin pour envoyer les paquets de données.

Group leader
Membre de groupe
RREQ,d1,ts1 RREQ,d1,ts3
Membre de l’arbre
Figure 3.3 : Cas où il n’existe pas de chemin enregistré
Dans le cas présenté par la figure 3.3, le nœud 3, en recevant le RREQ, calcule le débit
maximum au niveau du lien entre le nœud 1 et le nœud 2 en utilisant ts1 et puis il compare le
résultat trouvé avec le débit d1 demandé par la source (nœud 1). Si le débit estimé est supérieur à
d1, il diffuse le message RREQ à ses voisins (étant donnée qu’il ne dispose pas de chemin vers la
destination dans sa table de routage). Le nœud 8 (qui est un membre de l’arbre et donc il
représente la destination) effectue les mêmes opérations que le nœud 3 et s’il peut offrir le débit
demandé par la source, il renvoi un RREP vers le nœud 3. C’est à ce moment que l’algorithme
enregistre ce chemin avec le débit qu’il offre dans la table de routage du nœud qui reçoit le
RREP.
Enregistrement du chemin trouvé dans la table de routage :
Nous avons ajouté au message RREP un champ contenant le minimum des débits au niveau des
liens constituant le chemin vers la destination. Ce champ est initialisé par une valeur très élevée.
A la réception d’un RREP, chaque nœud enregistre dans ce champ le minimum entre l’ancienne
valeur et le débit estimé. Cette valeur va être enregistrée dans la table de routage (dans un
nouveau champ que nous avons appelé débit). Avant l’exécution de l’algorithme, le champ débit
de la table de routage est initialisé par une valeur qui tend vers l’infini.

Pour mieux comprendre cette procédure nous allons présenter les tables de routage des nœuds 1,
3 et 8 de la figure 3.4.
¾ Avant exécution de l’algorithme :
Table du nœud 1 :
destination Nombre de Prochain Numéro de Délai de validité débit
sauts saut séquence
@ du groupe multicast 0 3 1 X1 1000000000
Table du nœud 3 :
Destination Nombre de Prochain Numéro de Délai de validité débit

Table du nœud 8 :
destination Nombre de Prochain Numéro de Délai de validité débit
¾ Après exécution de l’algorithme :

Après exécution de l’algorithme de la qualité de service, le champ débit de chacun des tables de
routages va prendre les valeurs suivantes :
Table du nœud 8 : 1000000000.
Table du nœud 3 : le minimum entre 1000000000 et d8 ; d8 = min (1000000000, r8),
r8 représente le débit estimé par le nœud 8.
Table du nœud 1 : le minimum entre d3 et r3 ; d3 = min(d1,r3),
r3 représente le débit estimé par le nœud 3.
Maintenant, après la mise à jour des tables de routage, le nœud qui veut émettre des paquets de
données peut utiliser le chemin enregistré dans sa table de routage menant vers la destination et
satisfaisant la contrainte de débit exigée.

Dans le cas de la figure 3.4, le nœud 1 va consulter sa table de routage et comparer le champ
débit (d3) avec d1 (débit demandé par la source). Si d3 est supérieur à d1 le nœud 1 lance le
trafic de données sur ce chemin.
Group leader
Membre de groupe
RREQ,d1,ts1
Membre de l’arbre
Figure 3.4 : Cas où le table de routage enregistre un chemin
III.3 Implantation de la contrainte de délai

III.3.1 Extensions apportés au message RREQ
Lorsqu’un nœud lance la procédure de recherche d’un chemin satisfaisant la contrainte de délai,
les nœuds voisins doivent effectuer des opérations de soustraction, de multiplication et de
comparaison pour s’assurer que le chemin en construction répond a la qualité de service
demandé par la source.
Ces opérations vont être effectuées sur des variables qu’un nœud doit les extraire du message
RREQ qu’il reçoit. Nous avons donc ajouté au message RREQ des champs qui renseignent sur le
temps de réception de ce paquet par le nœud antécédent (figure 3.5), le délai de transmission de
ce paquet et le délai restant

tr1 RREQ, tr1,dprop,dr

N1
tr N2
Figure 3.5 : Extensions apportée au message RREQ pour l’estimation du délai
Au niveau du nœud N1, deux événements s’exécutent :
¾ Réception d’un RREQ : Lorsque le nœud N1 reçoit le message RREQ, il connaît le

moment de cet événement (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 délai de transmission depuis la source (tr-
tr1). Le résultat obtenu va être enregistré dans le champ «délai de transmission». Le champ qui
représente le délai restant (dr) est initialisé par le délai minimum à ne pas dépasser et
décrémenter à chaque fois que le message RREQ passe par un nœud.
La différence entre l’estimation du débit et l’estimation du délai réside dans le fait que le débit
est une métrique concave alors que le délai est une métrique additive. En effet, pour l’estimation
du débit l’algorithme traite chaque lien à part et donc ne prend pas en considération le temps de
traitement du message par les nœuds intermédiaires. Alors que pour la prédiction du délai,
l’algorithme va estimer le délai du paquet de données de bout en bout.
A ce niveau deux problèmes se posent :
¾ Le calcul du temps de traitement du paquet RREQ.
¾ L’adaptation de cette estimation pour les paquets de données.
III.3.2 Estimation de délai
Nous avons choisi d'évaluer les délais en utilisant les paquets RREQ plutôt que les paquets de
données afin d'éviter de générer du trafic overhead supplémentaire sur le réseau.

Notons que le délai d N 1N 2 entre un nœud N1 et un nœud N2 dépend de la taille des paquets. Une
correction doit être faite afin de tenir compte de la taille des paquets de données.
⎛ Taille du paquet de données ⎞

d ' N 1N 2 = d N 1N 2 × ⎜⎜ ⎟⎟ (3.3)
⎝ Taille du paquet de contrôle ⎠
Ce délai représente l’estimation du délai de transmission d’un paquet de donnée entre deux
nœuds adjacents (figure 3.6)
dN0N1 N1 dN1N2
N0
N2
Figure 3.6 : Délai de propagation
Dans la figure 3.6, le délai de traitement du paquet de donnée n’est pas pris en compte. Nous
avons donc proposé de calculer le délai de traitement du paquet RREQ en utilisant la méthode
donnée par la figure 3.5 (tr-tr1). De cette façon, le délai d N 1N 2 représentera le délai de
transmission du RREQ plus le délai de son traitement dans N1. Après correction, ce délai
représentera une estimation du NTT "node traversal time" qui est en fait un des paramètres
existant dans le protocole AODV [2] et qui est considéré comme constant de 30 ms [12].
III.3.3 Fonctionnement de l’algorithme
Recherche d'un chemin entre la source et la destination selon la contrainte de délai exigée
Le nœud source diffuse un paquet RREQ (au format intégrant la QoS) à tous ses nœuds voisins.
En recevant ce message, un nœud intermédiaire estime le NTT. Pour s’assurer que le chemin en
construction offre un délai inférieur ou égal à celui imposé par la source, chaque nœud
intermédiaire soustrait le NTT qu’il trouve du délai maximum restant et à ne pas dépasser dans le
reste du chemin. Si le résultat est négatif, ce chemin est abandonné. Si c’est positif le processus
continu et ceci jusqu'à atteindre la destination.

Group leader
Membre de groupe
RREQ tr, NTT, dr RREQ tr1, NTT1, dr1 Membre de l’arbre
Figure 3.7 : Recherche d’un chemin qui répond à la contrainte de délai
La figure 3.7 illustre un exemple de recherche de route où la contrainte de délai est respectée. En
recevant le RREQ, le nœud 3 estime le NTT [12] (initialisé à 0), soustrait le résultat du dr (NTT-
dr) (initialisé par la contrainte de délai à ne pas dépasser) et vérifie le signe de la nouvelle valeur
de dr. Si c’est positif, il achemine le RREQ avec les nouvelles valeurs (tr1, NTT1, dr1). Si non, il
abandonne le processus. Quand le nœud 8 reçoit ce RREQ, il calcule le NTT, soustrait le résultat
du dr1 et vérifie si la nouvelle valeur du dr1 est positive. Si c’est le cas, il répond par un RREP.
Si non il abandonne le processus.
III.4 Couplage des deux contraintes
Pour répondre aux deux contraintes de délai et de débit ensemble, chaque nœud intermédiaire
doit estimer la bande passante d’un lien et le NTT. Un nœud source du RREQ doit donc diffuser
avec ce message toutes les informations qui permettent d’effectuer cette estimation. Ces
informations correspondent au temps de réception du RREQ, temps d’émission du RREQ (par le
même nœud), le NTT, le délai restant à ne pas dépasser dans la suite du chemin, et le débit
minimum demandé par la source.
Le processus de recherche est abandonné si l’un des deux contraintes n’est plus respectées.

III.5 Conclusion
Dans ce chapitre nous avons décrit le déroulement de l’algorithme qui permet d’introduire la
qualité de service au niveau du protocole de routage MAODV. Cette approche est applicable
aussi pour le protocole de routage AODV.
Dans la procédure de l’introduction de la contrainte de débit, nous avons choisi d’utiliser les
anciens chemins trouvés. Car si non, le trafic de contrôle augmente et consommera plus de bande
passante. Dans ce cas, il devient difficile de trouver le chemin qui peut fournir le débit exigé.
Pour la contrainte de délai, l’enregistrement de ce paramètre au niveau de la table de routage de
chaque nœud constituant le chemin, nécessite des opérations beaucoup plus complexes que dans
le cas de la bande passante. Ces opérations risquent d’augmenter considérablement le délai
d’établissement d’une route. Nous avons donc choisi de ne pas modifier la structure de la table
de routage dans la procédure de recherche de route avec la contrainte de délai.

Evaluation des performances sup’com
Chapitre IV
Evaluation des performances
IV.1 Introduction
L’objectif dans cette partie est d’évaluer 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 réseaux NS-2 [4]. Les paramètres que nous allons évaluer touchent à la
capacité de service que peut offrir le réseau ad hoc à savoir :
• Le délai moyen de bout en bout.

• Taux de paquets livrés avec succès.
Nous allons examiner de prés quelques scénarios de simulation du protocole multicast et unicast
AODV [2] avant et après implémentation de la qualité de service. Les scénarios à simuler vont
mettre l’accent sur un paramètre étroitement lié à la topologie dynamique des réseaux ad hoc.
Ce paramètre représente la vitesse de déplacement des nœuds. 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 modèle de trafic
Dans notre application, les scénarios utilisent des applications qui sont des sources de trafic à
débit constant (CBR : Constant Bit Rate). Ces sources de trafic modélisent la couche application

et se trouvent sur des agents de transports UDP (User Datagrammes Protocol) modélisant la
couche transport.
Dans notre application nous allons utiliser cinq agents source qui vont envoyer les données à un
groupe mulicast dans le cas du MAODV [3]. Pour le cas de l’AODV [2], nous allons considérer
cinq connexions. Les sources émettent des paquets de taille 512 octets avec un débit de cinq
paquets par secondes et un temps de simulation de 590 s ce qui fait que le trafic total qui circule
dans le réseau est 14750 paquets, soit 7552 koctets.
IV.3 Le modèle de mobilité
Dans chaque scénario, la mobilité des nœuds est régie par un modèle pseudo aléatoire appelé
« Random Point Model ». Chaque nœud est placé dans un emplacement aléatoire au début de la
simulation (X0, Y0), ensuite, à des instants choisis aléatoirement, certains nœuds, eux choisis
aléatoirement, vont se déplacer selon le principe suivant :
• choisir un nouvel emplacement (Xt, Yt),

• choisir une vitesse de mouvement entre 0 et Vmax m/s,
• se déplacer vers le nouvel emplacement,
• rester en repos pendant une durée entre 0 et un temps de pause maximal en ms.
Ainsi, deux paramètres pourront affecter la mobilité des nœuds dans le réseau : 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 Paramètres à évaluer

IV.4.1 Délai moyen de bout en bout
Ce paramètre représente le délai passé entre l’instant où un paquet de données quitte l’émetteur
et l’instant où il est reçu par la destination.
∑ T (i) − T (i)
AR AS
End to End Delay : EED = 1000 × i
∑ paquets reçus

• TAR(i) : instant où le paquet de donnée i est reçu par l’agent de transport de destination.
• TAS(i) : instant où le paquet de donnée i est émis par l’agent de transport source.
Remarque : Pour le protocole MAODV [3], nous avons pris la moyenne des délais entre la
source et chacun des membres de groupe.
IV.4.2 Taux de paquets livrés avec succès
Ce paramètre donne le pourcentage des paquets livrés à leurs destinations par rapport aux
paquets émis par le réseau.
Packet Delivery Ratio : PDR =

∑ paquet reçus × 100
∑ paquets émis × nombre de récepteur
Dans le cas de l’AODV [2] unicast, le nombre de récepteur est égal à un.
IV.4.3 Délai d’établissement d’une route
Ce paramètre renseigne sur le temps mis par le protocole de routage pour trouver une route. Il
peut nous donner une indication sur le temps de séjour d’un paquet de données dans les buffers
d’un nœud avant d’être émis.
∑ Ts (i) − Tr (i)
Route Acquisition Latency : RAL = 1000 × i
∑ paquets reçus
• Ts(i) : instant où le paquet de donnée i quitte le routeur.
• Tr(i) : instant où le paquet de donnée i est délivré par l’agent de transport à la couche
réseau.
IV.4.4 Trafic de contrôle
Ce paramètre nous informe sur la quantité des messages de contrôles générés par les protocoles
de routage MAODV et AODV pour, la recherche, l’établissement et le maintient des routes.
Traffic OverHead : TOH = ∑ RREQ, RREP, RERR

IV.5 Paramètres de contexte de simulation
Avant de lancer la simulation des scénarios, nous devons ajuster et fixer certains paramètres qui
vont constituer le contexte de notre simulation. Ces paramètres sont illustrés dans le tableau
suivant :
Temps de simulation 590s

Protocoles AODV et MAODV
Nombre de scénarios pour un même contexte 5
Temps de pause des nœuds 0s
Taille de paquet de données 512 octets
Vitesse d’émission 5 pkts/s
Taille du buffer des nœuds 50 paquets
Nombre des nœuds sources envoyant les données au groupe 5
multicast (nombre de connexions pour le AODV unicast)
Nombre des nœuds constituant le groupe 10
Tableau 1 : Paramétrage du contexte de simulation
Pour les paramètres de la qualité de service, chaque source va imposer comme contrainte de délai
à ne pas dépasser 70 ms pour le MAODV et 60 ms pou le AODV et comme contrainte de bande
passante minimum qui doit être disponible au niveau d’un lien 50 kbps pour l’unicast et le
multicast.
L’environnement de la simulation est décrit dans le tableau suivant :
Machine Pentium 4, 3 GHz, 256 Mo

Système Linux Red Hat 9.0
NS Ns-allinone-2.26
Tableau 2 : Environnement de simulation
Au début de chaque simulation, les paramètres de chaque nœud mobile doivent être configurés
comme suit :
• Type MAC : MAC/802_11

• Taille du buffer (ifqLen)

• Type d’interface de queue : Queue/DropTail/PriQueue

• Type de canal : [new Channel/WirelessChannel]
• Modèle de propagation radio: TwoRayGround \
• Type de l’antenne : Antenna/OmniAntenna
• Type de couche de liaison : LL
• Nombre maximum de paquets dans le queue d’interface : 50
• Trace de l’agent : ON
• Trace du routeur : ON
• Trace du mouvement : OFF
• Trace du MAC : OFF
En plus, la topographie du réseau consiste en une surface créée de dimension 1000 m x 1000 m
sur laquelle sont distribués 50 nœuds. Nous avons varié la vitesse de déplacement des nœuds de
0 à 20m/s, et pour chaque vitesse nous avons fait cinq simulations.
IV.6 Résultats et interprétations

IV.6.1 Effet de la contrainte de débit
IV.6.1.1 Trafic de contrôle
25000
toh_aodv
toh_maodv
toh_aodv_bw
toh_maodv_bw
nombre de paquets de controles (paquets
20000
15000
10000
5000
0
0 5 10 15 20
vitesse (m/s)
Figure 4.1 : Trafic de contrôle en fonction de la vitesse en respectant la contrainte de débit

La figure 4.1 nous donne le nombre de paquets de contrôle circulant dans le réseau. La première
constatation est que le trafic de contrôle augmente avec la vitesse de déplacement des nœuds. En
effet, si la vitesse augmente la route déjà enregistrée dans la table de routage n’est 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 génère plus de
trafic de contrôle. Cela est dû aux exigences de la source. En d’autre terme, le risque de ne pas
trouver une route qui répond aux exigences de l’émetteur en débit augmente ce qui fait que la
source va émettre plus de paquets RREQ pour la découverte d’une 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 contrôle était prévisible car non
seulement le mécanisme de maintien de l’arbre multicast génère plus de paquets de contrôle,
mais également le mécanisme du protocole AODV classique ne s’exécute que pour réparer les
ruptures de liens. Pour les protocoles AODV et MAODV avec contrainte de qualité de service, le
nombre d’exécutions de la procédure de recherche de route va augmenter. Et ce nombre est plus
important en unicast qu’en multicast (car en unicast le nombre des nœuds intermédiaires est plus
important ce qui fait que le temps d’attente de la réponse "RREP_WAIT_TIME = 1 sec" risque
de s’expirer. Si c’est le cas, la source relance la recherche en diffusant d’autres paquets RREQ).
IV.6.1.2 Délai d’établissement d’une route
La figure 4.2 montre que le délai d’établissement d’une route devient plus important avec
l’augmentation de la vitesse de déplacement des nœuds. En effet, pour une mobilité rapide, la
topologie du réseau change rapidement et par conséquence, les liens au niveau du chemin inverse
(pour la propagation des RREP) risquent d’être cassés.
Cette figure montre aussi que l’aspect qualité de service a des effets négatifs sur le
comportement de ce paramètre. En effet, il faut trouver une route qui répond aux exigences de la
source. Pour ce faire, chaque nœud intermédiaire est obligé d’effectuer des opérations
supplémentaires par rapport au protocole best effort. Ces opérations permettent à un nœud de
chercher un lien satisfaisant la contrainte de débit demandée par l’émetteur.
Finalement, nous constatons que le taux d’augmentation de ce délai 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

des vitesses > 10 m/s). Cela est dû au fait que le nombre des nœuds intermédiaires est plus
important dans le cas unicast.
30
ral_aodv
ral_maodv
25 ral_aodv_bw
délai d'établissement d'une route (ms)
ral_maodv_bw
20
15
10
0
0 5 10 15 20
vitesse (m/s)
Figure 4.2 : Délai d’établissement d’une route en fonction de la vitesse en respectant la

contrainte de débit
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 : Délai d’établissement d’une route en fonction du temps avec contrainte de débit
La figure 4.3 donne le comportement de ce paramètre en fonction du temps de simulation.

Nous remarquons d’abord que si le temps de simulation avance, le délai de recherche d’une route
répandant à la contrainte de débit démuni. En effet, au début de la simulation il n y a pas de route
enregistrée dans la table de routage et qui satisfait les exigences de la source. Mais avec le temps,
les nœuds intermédiaires peuvent utiliser les routes déjà enregistrées dans la table de routage.
Le problème c’est que ces routes ont une durée de vie (ACTIVE_ROUTE_TIMEOUT = 50 sec)
[13] et pour cette raison le délai d’établissement d’une route augmente dans des instants précis et
en particulier pour un mouvement rapide des nœuds. Ces instant où le délai augmente (50,200 et
350 sec) correspondent aux moments où le chemin enregistré dans la table de routage n’est plus
valable.
IV.6.1.3 Taux de paquets livrés avec succès
La figure 4.4 montre d’abord que le taux de livraison de paquets de données diminue légèrement
si la vitesse de déplacement des nœuds augmente. En effet, si la vitesse de déplacement des
nœuds augmente, il devient plus difficile de maintenir les liaisons au niveau du réseau et donc le
nombre de paquets perdus augmente.
100
98
96
94
92
taux de paquets livrés avec succès (%)
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 5 10 15 20
vitesse (m/s)
contrainte de débit
Nous remarquons que ce taux augmente après l’introduction de la qualité de service en terme de
bande passante. En effet, le protocole de routage classique (représenté par la courbe pdr_aodv
dans le cas unicast et la courbe pdr_maodv dans le cas multicast) choisit la route la plus récente

et la plus courte, alors que celui doté de la qualité de service (représenté 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 possèdent 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)
20 pdr_aodv_bw (5m/s)
pdr_maodv_bw (20m/s)
10 pdr_aodv_bw (20m/s)
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.5 : Taux de paquets livrés avec succès en fonction du temps avec contrainte de débit
La variation de ce paramètre en fonction du temps de simulation est représentée dans la figure

4.5.
Nous constatons que pendant les 30 premières secondes, le taux de livraison est faible et il ne
dépasse pas 30 % au début de la simulation. Cela est dû au fait que les paquets de données sont
encore dans la file d’attente (soit qu’ils attendent l’établissement d’un chemin soit la réparation
des liens défectueux si le paquet est en cours de route).
Cette figure montre aussi que, dans le cas unicast (représenté par les courbes pdr_aodv_bw), le
taux de paquets livrés avec succès reste constant durant toute la simulation. Alors que pour le
multicast (représenté par les courbes pdr_maodv_bw), ce paramètre varie légèrement pendant la
simulation. En effet, avec l’avancement de la simulation, le réseau devient plus saturé (plus de
paquets de données et de contrôle circulent dans le réseau). En plus, le volume de trafic de
contrôle va augmenter aux moments de l’expiration de la validité de la route enregistrée dans la
table de routage. Ces moments de saturation vont causer la perte des paquets de données.
Ce qui fait la différence entre l’unicast et le multicast est le volume de trafic de contrôle qui est
plus important pour le multicast (pour la maintenance de l’arbre). Cependant, nous remarquons
que la fluctuation de ce paramètre est plus importante pour un mouvement rapide des nœuds.

IV.6.1.4 Délai moyen de bout en bout
120
100
délai de bout en bout (ms)
80
60
40
eed_aodv
eed_maodv
20 eed_aodv_bw
eed_maodv_bw
0
0 5 10 15 20
vitesse (m/s)
débit
A partir de la figure 4.6, nous constatons la différence entre le protocole MAODV (représenté
par la courbe eed_maodv) et le QoS-MAODV (représenté par la courbe eed_maodv_bw).
Sur cette même figure, nous remarquons que si la vitesse des nœuds augmente, le délai de bout
en bout augmente.
Nous remarquons aussi que le mécanisme de qualité de service pour le trafic multicast réduit le
délai de bout en bout de 10 ms. Il nous fait aussi gagner 20 ms sur le délai pour le trafic unicast.
Pour mieux comprendre l’effet de l’introduction de la qualité de service sur le délai de bout en
bout, nous avons étudié le comportement de ce délai le long de la simulation. Le résultat 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 délai
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
nœuds mobiles composant le groupe multicast ont tendance de s’éloigner. Ce qui donne des
chemins plus longs (en nombre de sauts) entre la source et l'un des membres du groupe.

140
eed_maodv_bw (5m/s)
eed_aodv_bw (5m/s)
120 eed_maodv_bw (20m/s)
eed_aodv_bw (20m/s)
100
80
60
40
20
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.7 : Délai moyen de bout en bout en fonction du temps avec contrainte de débit
IV.6.2 Effet de la contrainte de délai
22000
20000
nombre de paquets de controle (paquets)
18000
16000
14000
12000
10000
8000
6000
toh_aodv
4000
toh_maodv
2000
toh_aodv_délai
toh_maodv_délai
0
0 5 10 15 20
vitesse (m/s)
Figure 4.8 : Trafic de contrôle en fonction de la vitesse en respectant la contrainte de délai

Sur la figure 4.8 nous remarquons que le trafic de contrôle du protocole de routage sous
contrainte de qualité de service en terme de délai (courbes toh_aodv_délai et toh_maodv_délai)
est légèrement supérieur à celui du protocole de routage best effort (courbes toh_aodv et
toh_maodv). En effet, ce comportement est prévisible dans la mesure où le mécanisme de la
qualité de service rend les conditions sur les routes recherchées plus strictes. Ie nombre de
paquets RREQ et RREP circulant dans le réseau va nécessairement augmenter
La figure 4.9 montre que le protocole de routage doté de la qualité de service (représenté par les
courbes ral_aodv_délai et ral_maodv_délai) 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 implantée. Le temps de propagation de ces messages va donc augmenter et
par conséquent le mécanisme de recherche de la route prend plus de temps. Nous remarquons
que le délai d’établissement d’une route devient six fois plus grand après introduction de la
qualité de service.
30
ral_aodv
ral_maodv
25 ral_aodv_délai
ral_maodv_délai
délai d'établissement d'une route (ms
20
15
10
0
0 5 10 15 20
vitesse (m/s)
Figure 4.9 : Délai d’établissement d’une route en fonction de la vitesse en respectant la

contrainte de délai

40
ral_maodv_délai (5m/s)
ral_aodv_délai (5m/s)
35 ral_maodv_délai (20m/s)
ral_aodv_délai (20m/s)
30
25
20
15
10
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.10 : Délai d’établissement d’une route en fonction du temps avec contrainte de délai
La figure 4.10 donne le comportement du délai d'établissement d'une route en fonction du temps
avec la contrainte de délai. Nous constatons que les courbes de cette figure admettent des
maximums et des minimums relatifs. Cette variation de délai est due à la disposition des nœuds.
En effet, le temps d'établissement d'une route depuis la source jusqu'à la destination comprend le
temps d'exécution de l'algorithme de qualité de service au niveau des nœuds intermédiaires. Ce
temps augmente en fonction du nombre de sauts.
La figure 4.11 montre que dans le cas d’un routage multicast et pour des vitesses élevées le taux
de livraison se dégrade d’environ 2.5% avec l’introduction de la qualité de service. Pour les
grandes vitesses, les messages de contrôles sont plus nombreux, ceci est dû au changement
fréquent de la topologie du réseau. En plus ces messages disposent d'une taille plus importante
après l'introduction de la contrainte du délai comme contrainte de QoS, ce qui occupera des
ressources supplémentaires en bande passante.
Dans le cas d’une faible mobilité, le MAODV avec QoS (représenté par la courbe
pdr_maodv_délai) dispose d'un PDR supérieur à celui offert par le MAODV classique
(représenté 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 délai exigée. Par
conséquent les paquets de données ont plus de chance d'atteindre leurs destinations.

105
pdr_aodv
100 pdr_maodv
taux de paquets livrés avec succès (%) pdr_aodv_délai
95 pdr_maodv_délai
90
85
80
75
70
65
60
0 5 10 15 20
vitesse (m/s)
contrainte de délai
Pour le routage unicast, nous remarquons que le taux de livraison des paquets de données se
dégrade légèrement 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 constatés dans les trafics multicasts. Ceci est dû au trafic de contrôle supplémentaire
indispensable pour la maintenance de l'arbre multicast qui consomme des ressources
supplémentaires en bande passante.
120
100
80
60
40
pdr_maodv_délai (5m/s)
20 pdr_aodv_délai (5m/s)
pdr_madv_délai (20m/s)
pdr_aodv_délai (20m/s)
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.12 : Taux de paquets livrés avec succès en fonction du temps avec contrainte de délai

Sur la figure 4.12 nous remarquons que pour un temps de simulation supérieur à 150 secondes, le
taux de livraison est stable. Pour un temps de simulation compris entre 0 et 30 secondes, ce taux
est inférieur à 50 %. En effet, cela est prévisible parce que les paquets de données ne peuvent
être livrés qu’après établissement d’itinéraire ou réparation de liens.
Sur la figure 4.13, nous constatons que le délai de bout en bout ne dépasse pas les 70 ms pour le
QoS-MAODV (représenté par la courbe eed_maodv_délai), alors qu’il atteint les 100 ms pour le
MAODV sans QoS (représenté par la courbe eed_maodv). De même pour le aodv unicast
(représenté par les courbes eed_aodv et eed_aodv_délai). En effet, ceci s’explique du fait que
nous avons garanti des liens disposant d’un délai minimal.
120
eed_aodv
eed_maodv
100 eed_aodv_délai
eed_maodv_délai
80
60
40
20
0
0 5 10 15 20
vitesse (m/s)
délai
L’évolution de ce délai durant la simulation est présenté dans la figure 4.14. Nous observons sur
cette figure que le délai de bout en bout du protocole MAODV fluctue légèrement en fonction du
temps. En effet, cela est prévisible du fait que ce délai dépend de la distance (nombre de sauts)
entre la source et chacun des membres de groupe multicast.
Nous remarquons aussi que le délai offert par le QoS-MAODV peut être soit inférieur soit
supérieur à celui offert par le QoS-AODV. Cela est dû à l’évolution de la structure de l’arbre
(distance entre les membre du groupe) en fonction du temps.

.
100
eed_maodv_délai (5m/s)
90 eed_aodv_délai (5m/s)
eed_maodv_délai (20m/s)
80 eed_aodv_délai (20m/s)
70
60
50
40
30
20
10
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.14 : Délai moyen de bout en bout en fonction du temps avec contrainte de délai
IV.6.3 couplage des deux contraintes ensembles
25000
toh_aodv
toh_maodv
toh_qos-aodv
toh_qos-maodv
nombre de paquets de controle (paquets)
20000
15000
10000
5000
0
0 5 10 15 20
vites se (m /s)
Figure 4.15 : Trafic de contrôle en fonction de la vitesse en respectant les contraintes de délai et
de débit
La figure 4.15 montre qu’il y a plus de paquets de contrôle circulant dans le réseau 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
exigées par les protocoles unicast et multicast AODV.

Nous constatons, sur la figure 4.16 que le délai d’établissement d’une route est influencé
considérablement par l’introduction de la qualité de service. En effet, chaque nœud
intermédiaire, en recevant un paquet RREQ ou RREP, est obligé d’effectuer des opérations de
calcul et de comparaison pour les deux contraintes de débit et de délai, ce qui nécessite un temps
d’établissement d’une route supplémentaire.
30
ral_aodv
ral_maodv
ral_qos-aodv
25
ral_qos-maodv
20
15
10
0
0 5 10 15 20
vitesse (m/s)
Figure 4.16 : Délai d’établissement d’une route en fonction de la vitesse en respectant les
contraintes de débit et de délai
50
ral_qos-maodv (5m/s)
45 ral_qos-aodv (5m/s)
ral_qos-maodv (20m/s)
ral_qos-aodv (20m/s)
40
35
30
25
20
15
10
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.17 : délai d’établissement d’une route en fonction du temps avec contraintes de débit et
de délai

La figure 4.17 donne l’évolution de ce délai durant la simulation. Nous remarquons l’instabilité
de ce délai à cause de la variation de la langueur du chemin durant la simulation. Ce délai est
plus important pour les vitesses élevées.
105
pdr_aodv
100 pdr_maodv
pdr_qos-aodv
pdr_qos-maodv
95
90
85
80
75
70
65
60
0 5 10 15 20
vitesse (m/s)
Figure 4.18 : Taux de paquets livrés avec succès en fonction de la vitesse en respectant les
contraintes de débit et de délai
D’après la figure 4.18 nous remarquons que les deux protocoles AODV et MAODV
implémentant les deux contraintes ensembles (pdr_qos-aodv et pdr_qos-maodv) possèdent 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 dotés de la
qualité de service imposent la contrainte de bande passante. Les liens composant la route
possèdent donc une bande passante plus large. Dans ce cas le nombre de paquets perdus diminue.
La figure 4.19 donne l’évolution du PDR en fonction du temps de simulation. Cette figure
montre que le PDR est important et assez stable. Ceci s’explique du fait que nous avons garantie
des liens disposant d’une bande passante maximal et d’un délai minimal.

120
100
80
60
40
pdr_qos-maodv (5m/s)
20
pdr_qos-aodv (5m/s)
pdr_qos-maodv (20m/s)
pdr_qos-aodv (20m/s)
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.19 : Taux de paquets livrés avec succès en fonction du temps avec contraintes de débit et de
délai
120
eed_aodv
eed_maodv
eed_qos-aodv
eed_qos-maodv
100
80
60
40
20
0
0 5 10 15 20
vitesse (m/s)
Figure 4.20 : Délai moyen de bout en bout en fonction de la vitesse en respectant les contraintes
de débit et de délai

La figure 4.20 montre qu’après implémentation de la qualité de service, le délai de transmission

des paquets de données ne dépasse pas 70 ms (valeur max à ne pas dépasser exigé par
l’émetteur) pour le routage multicast et 60 ms pour l’unicast.
Les deux protocoles AODV et MAODV implantant les deux contraintes de la qualité de service
ensemble (représentés par les courbes eed_qos-aodv et eed_qos-maodv) peuvent garantir un
délai minimal de transmission de paquets de données que les protocoles classiques (représentés
par les courbes eed_aodv et eed_maodv). Cette amélioration du délai devient plus ressentie avec
l’augmentation de la vitesse. En effet, pour une faible mobilité la qualité de service n’a pas
d’effet car la contrainte de délai imposée par la source est toujours respectée même pour les
protocoles de routages classiques. Lorsque la mobilité augmente, le mécanisme de la qualité de
service va ignorer les routes où le délai dépassera la contrainte exigée par l’émetteur.
La figure 4.21 montre que le délai 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 délai représente une moyenne des délais entre la source et chacun des membres du
groupe. Ce délai dépend donc de la structure de l'arbre.
120
eed_qos-maodv (5m/s)
eed_qos-aodv (5m/s)
eed_qos-maodv (20m/s)
100 eed_qos-aodv (20m/s)
80
60
40
20
0
0 50 100 150 200 250 300 350 400 450 500 550 590
Figure 4.21 : Délai moyen de bout en bout en fonction du temps avec contraintes
de débit et de délai

IV.7. conclusion
Malgré que le protocole de routage doté de la qualité de service implantant les contraintes de
débit et de délai 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 délai ou de débit. En effet, un
protocole de routage implantant les deux contraintes ensemble, doit déterminer des chemins tout
en respectant la bande passante et le délai demandé par l’émetteur.

Conclusion générale sup’com
Conclusion générale
Vue l’émergence de nombreuses applications dans les réseaux ad hoc et qui nécessitent des
communications multicast tels que la visioconférence, le travail de collaboration, et les jeux
distribués, l’environnement ad hoc a commencé à attirer l’intention des chercheurs dans le
domaine des protocoles de routage multicast.
Le dynamisme des membres d’un réseau ad hoc induit des problèmes de routage dans ce type de
réseaux, ce qui va influencer la qualité de service offert (délai de transmission, taux de perte, …).
Pour cela, et vue l’émergence des applications sans fil, la QoS dans les réseaux mobiles ad hoc
devient un sujet de plus en plus important mais aussi délicat.
Dans ce projet, nous avons implémenté l’aspect QoS sur les protocoles de routage AODV et
MAODV en considérant les contraintes de débit, délai et le couplage de ces deux contraintes
ensemble dans la recherche et l'établissement de routes. Nous avons étudié l'apport de ces
mécanismes de QoS sur les trafics unicast et multicast.
L’analyse des résultats de simulations montre que l’introduction de la contrainte de délai de bout
en bout a amélioré les performances du réseau. Nous avons constaté aussi que le taux de paquets
livrés avec succès augmente avec l’introduction de la contrainte de débit. Le couplage des deux
contraintes a nettement amélioré ces deux métriques.
L’évaluation de performance d’un protocole de routage se fait généralement sur les mêmes
paramètres. Et c’est là justement que se pose le problème qui relève de la diversification des
paramètres configurables avant tout scénarios de simulation. En effet, les résultats présentés ici
resteront certainement valables à condition de garder la même configuration. Ce qui pose en fait
un problème relativement complexe lorsqu’il s’agit de se ramener à la réalité du terrain.
Ici par exemple, nous avons utilisé une mobilité aléatoire pour les nœuds, ce qui n’est
généralement pas le cas dans l’utilisation réelle du réseau ad hoc.
Ce travail laisse entrevoir des perspectives intéressantes. Cependant, nous prévoyons d’étudier
notre approche dans un contexte multimédia réel. Nous pouvons aussi utiliser un modèle de
mobilité plus proche de la réalité.

Conclusion générale sup’com
En fin, malgré qu’on peut s’approcher de la réalité, une évaluation par simulation nous ne donne
qu’une idée globale sur la performance du protocole. Une évaluation sur terrain peut donc nous
donner une idée plus claire sur notre approche.

Bibliographie sup’com
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.

Bibliographie sup’com
[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

Acronymes sup’com
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

Annexe 1 sup’com
Annexe 1
NS2 : Aperçu du logiciel
NS est un outil logiciel de simulation de réseaux informatiques. Il est principalement bâti sur
l’idée de la conception par objets, de la réutilisation du code et de modularité. Il est devenu
aujourd'hui un standard de référence dans ce domaine. C'est un logiciel dans le domaine public
disponible sur l'Internet. Son utilisation est gratuite. Le logiciel est exécutable tant sous la
plateforme Unix que Windows.
Il s’agit d’un simulateur à événement discret, fruit de la collaboration entre l’université 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 très utile pour le design et la compréhension des
protocoles.
Le simulateur NS actuel est particulièrement bien adapté aux réseaux à commutation de paquets
et à la réalisation de simulations de petite taille. Il contient les fonctionnalités nécessaires à
l'étude des algorithmes de routage unipoint ou multipoint, des protocoles de transport, de session,
de réservation, des services intégrés, des protocoles d'application comme HTTP. De plus le
simulateur possède déjà une palette de systèmes 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 contrôle de congestion. Il permet à l’utilisateur de concevoir un réseau et de simuler les
communications entre les nœuds. Le simulateur utilise le langage orienté objet OTCL (Object
TCL) dérivé 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 catégorie est:

Annexe 1 sup’com
Application Web ftp, telnet, générateur 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
Système de transmission CSMA/CD, CSMA/CA, lien point à point
Ces capacités ouvrent le champ à l'étude de nouveaux mécanismes au niveau des différentes
couches de l'architecture réseau.. Ils peuvent ainsi partager leurs efforts et échanger leurs
résultats de simulations. Cette façon de faire se concrétise 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 l’étude de l’existant, la conception, la validation et
l’évaluation de performances et ceci dans le domaine des protocoles et mécanismes réseaux. il
bénéfice aussi des avantages d’un simulateur de réseaux tels que la flexibilité, l’étude des cas
difficiles à reproduire dans la réalité, le faible coût des expérimentations et la reproductibilité des
résultats. D’autre part, il souffre de leurs inconvénients tels que la simplification et l’abstraction
du monde réel, la difficulté de tester certaines choses, et la puissance de calcul requise qui croit
avec la complexité du système simulé. De plus NS2 souffre de l’état primitif aussi bien de ses
outils de collecte et traitements des résultats 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 développeurs).
• Intermédiaire: on ajoute des fonctionnalités sans modifier le coeur du simulateur.
• Avancée: on développe son propre code (en C++) et on modifie le coeur du simulateur.
La figure (A.1) illustre un cycle de simulation typique avec NS2

Annexe 1 sup’com
Problème à Modèle de
étudier simulation
Création de scénario
de simulation
Analyse des
résultats
Modification à NS2
Exécution des (code OTcl et/ou
simulations c++)
Figure A.1 : Cycle d’une simulation
Le résultat d’une simulation est un fichier texte contenant tous les évènements de la simulation.
Un traitement ultérieur de ce fichier permet d’en extraire l’information souhaitée. Par ailleurs, le
simulateur permet la création d’un fichier d’animation, permettant de visualiser la simulation sur
une interface graphique NAM. Ce visualisateur fournit une représentation du graphe du réseau
sur laquelle on peut voir circuler ces paquets, suivre le niveau des files d’attente, etc.
Architecture et implémentation
NS-2 est développé en C++ et en OTcl « abject Tools command language ». Il contient une
hiérarchie de classes compilées d'objets écrits en C++ et une hiérarchie de classes interprétées
d'objets écrits en OTcl. Ces deux hiérarchies sont étroitement liées. En effet, lorsque l'utilisateur
crée un nouvel objet par l'interpréteur OTcl, un objet correspondant, appelé objet reflet, est aussi
crée dans la hiérarchie compilée. On dit que ces objets sont des "objets fondus". D'ailleurs, des
procédures d'appel entre OTcl et C++ sont mises en place permettant ainsi à l'utilisateur
d'accéder aux différents objets aussi bien en Otcl qu'en C++ .
Il est à noter que l'utilisation de deux langages permet la séparation entre les plans « données» et
« contrôle» (des échelles temporelles différentes). Le langage C++ est utilisé pour le plan «
données» pour traiter des événements au niveau paquet tels que la génération de paquets IP et le
traitement des paquets dans les routeurs. Quant au langage OTcl. Il sert pour le plan « contrôle»
afin de pouvoir effectuer des traitements à des échelles temporelles plus grandes et coder des

Annexe 1 sup’com
modèles de trafic et/ou applications simples (ex: application ftp).

L'OTcl permet aussi le contrôle des simulations par la définition des scénarios de simulation
(topologie du réseau, taille des files d’attentes des routeurs…).
Otcl est un langage interprété qui ne demande pas de compilation. Il est utilisé .pour concaténer
des objets, accéder aux objets à partir de l'interpréteur' et configurer des simulations, Ce langage
rend l'utilisation du simulateur assez souple et convivial car il offre de nombreux objets
prédéfinis qui peuvent être utilisés pour simuler un grand nombre de Scénarios assez aisément.
Le langage C++ est utilisé pour créer des classes de base permettant de traiter un grand nombre
de données tels que le calcul des tables de routage, le mouvement des mobiles... On fait appel
donc à ce langage pour programmer des agents adaptés à un comportement particulier ou à un
protocole spécifique.
Au plus bas niveau, il y a six classes qui définissent l'ensemble de la structure du programme et
fournissent les méthodes élémentaires. Il s'agit des classes Tcl, TclObject, TclClass,
Tclcommand, EmbeddedTcl et InstVar. Elles définissent entre autres les méthodes utilisées par
C++ pour accéder à l'interpréteur, la hiérarchie, les principales commandes de haut niveau et les
méthodes pour accéder aux variables de C++ et Otcl.
La simulation est configurée, contrôlée et gérée à l'aide des interfaces fournies par la classe Otcl
Simulator. Cette classe fournit des procédures pour créer et gérer la topologie, initialiser le
format des paquets et choisir le planificateur d'évènements. Elle stocke intérieurement des
références à chaque élément de la topologie. Un script devra donc toujours commencer par
l'instanciation d'une variable de cette classe. L'utilisateur crée ensuite la topologie à travers Otcl
en utilisant les classes node et link qui sont les composants essentiels de la topologie.
La mobilité dans NS2
L’implémentation originale de NS2 ne contient pas une extension pour la simulation des réseaux
mobiles. Les dernières versions du logiciel ont bénéficié de deux extensions de mobilité :
• Wireless Mobility Extension: projet développé par le CMU Monarch Projcct,

• Mobile IP Extension: projet développé par SunMicroSystem.
Nous avons choisit l'extension CMU, car elle nous offre une architecture protocolaire complète
pour la simulation des réseaux ad hoc, cette architecture implémente un modèle de canal

Annexe 1 sup’com
physique, un protocole MAC, le protocole ARP et quelques protocoles de routage ad hoc.
• Le modèle de propagation:Le modèle de propagation est utilisé pour déterminer si les

données transmises ont été correctement reçues ou pas. Ce modèle inclut les délais de
propagation, l'écoute du canal, la détection de la porteuse, etc.
• Le protocole MAC: Le modèle de protocole MAC utilisé étant le IEEE 820.11

Distributed Coordination Function (DCF), donnant la possibilité de transmission point à
point (Unicast) et diffusion généralisée (Broadcast).
• L'interface physique:Chaque nœud mobile est équipé d'une interface physique pour la
transmission et réception des données. Cette interface offre une portée radio de 250m, un
débit maximal de 2 Mb/s et utilise une antenne omni-directionelle de gain unité. De plus,
cette interface contient les files d'attentes nécessaires pour dérouler les algorithmes de
routage.
Les données sont générées par la couche application et les paquets de données atteignent l'agent
de routage qui détermine la route que doit prendre le paquet puis le fait passer à la couche LLC.
Celle ci utilise le protocole de résolution d'adresse (ARP) pour la correspondance entre l'adresse
IP du nœud destinataire et son adresse physique (MAC). Le paquet est ensuite mis dans la file
d'attente en attendant que le protocole MAC décide de le faire passer à l'interface physique qui à
son tour l'émet dans le canal radio.
Chaque interface physique qui reçoit un paquet, va y inscrire des informations particulières
(instant de réception, ...) puis fait appel au modèle de propagation. Celui ci utilise alors les
informations qui ont été marqué sur le paquet durant son parcours par les différentes interfaces
physiques, pour estimer la puissance avec laquelle les données sont reçues. Si cette puissance
n'est pas au dessous d'un seuil de détection, 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 démultiplexeur.
Si le paquet a atteint sa destination, le démultiplexeur décide vers quelle application aiguiller les
données, si non, le démultiplexeur fait passer le paquet à la couche réseau pour être relayé vers
sa destination.

Annexe 1 sup’com
Figure : Schéma synoptique d’un nœud mobile dans NS2
Présentation du TCL
Tcl est un langage de commande comme le shell UNIX mais qui sert à contrôler les applications.
Son nom signifie Tool Command Language. Tcl offre des structures de programmation telles que
les boucles, les procédures ou les notions de variables. Il y a deux principales façons de se servir
de Tcl: comme un langage autonome interprété ou comme une interface applicative d'un
programme classique écrit en C ou C++. En pratique, l'interpréteur Tcl se présente sous la forme
d'une bibliothèque de procédures C qui peut être facilement incorporée dans une application.
Cette application peut alors utiliser les fonctions standard du langage Tcl mais également ajouter
des commandes à l'interpréteur.
Présentation de l’OTcl
La documentation est accessible à l'URL ftp://ftp.tns.lcs.mit.edu/pub/otcl/. OTcl est une

extension orientée objet de Tcl. Les commandes Tcl sont appelées pour un objet. En OTcl, les
classes sont également des objets avec des possibilités d'héritage. Les analogies et les différences
avec C++ sont:
• C++ a une unique déclaration de classe. En OTcl, les méthodes sont attachées à un objet
ou à une classe.

Annexe 1 sup’com
• Les méthodes OTcl sont toujours appelées avec l'objet en préfixe

• L'équivalent du constructeur et destructeur C++ en OTcl sont les méthodes
• init{}/destroy{}.
• L'identification de l'objet lui-même: this (C++), $self (OTcl). $self s'utilise à l'intérieur
• d'une méthode pour référencer l'objet lui-même. A la différence de C++, il faut toujours
utiliser $self pour appeler une autre méthode sur le même objet. C'est à dire "$self xyz 5"
serait "this->xyz(5)" ou juste "xyz(5)" en C++.
• Les méthodes OTcl sont tout le temps "virtual". A savoir, la détermination de la méthode
à appeler est effectuée à l'exécution.
• En C++ les méthodes non définies dans la classe sont appelées explicitement avec
• L’opérateur de portée ":». En OTcl, les méthodes sont implicitement appelées dans l'arbre
d'héritage par "$self next". Cette commande appelle la méthode de même nom de la
classe parent.
Technique de simulation
La simulation des protocoles de routage des réseaux ad hoc s'articule autour de 4 grandes parties
interdépendantes:
1- Pré simulation
Durant cette phase, nous allons générer le script principal en OTCL à faire transmettre à NS2 ; ce
script est généré automatiquement à partir de plusieurs modèles de scripts TCL pour les
configurations et la manipulation de fichiers, ainsi qu'un script OTCL contenant le code de
génération du trafic sur le réseau et un autre script OTCL, contenant les instructions définissant
le mouvement des nœuds dans le réseau. L'ensemble des ces fichiers constitue un "scénario" de
simulation.
2- Simulation
Durant cette phase, NS2 va simuler les différents scénarios pendant une durée bien fixée. Le
résultat de ces simulations se trouve dans des fichiers de trace générés par NS2.

Annexe 1 sup’com
3- Post-simulation
Dans cette phase, nous allons récupérer les fichiers de trace NS2 et en extraire les résultats que
nous voudrions visualiser ou interpréter. Cette extraction ainsi que toute autre opération de calcul
est assurée par plusieurs scripts en langage AWK ou PERL.
4- Exploitation
Une fois les résultats calculés, 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...).

Annexe 2 sup’com
Annexe 2
Implémentation du protocole MAODV
Etapes d’implémentation
D’abord il faut que NS2 soit installé. Télécharger 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 n’existaient 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 procédures suivantes :
• diffusion périodique du message GRPH.

• recherche des nœuds qui doivent sortir de l’arbre.
• sortie d’un nœud de l’arbre (pruning of tree member).
• détection des partitions d’arbre.
• sélection du group leader.
• fusion d’arbres.

Annexe 2 sup’com
• acheminement des paquets de contrôle.

• acheminement des paquets de données et leur diffusion dans l’arbre.
La démarche à suivre est :

Copier les fichiers 1) à 12) dans le répertoire ./ns-2.26/aodv/;
Copier le fichier 13) dans le répertoire ./ns-2.26/trace/;
Copier les fichiers 14) et 15) dans le répertoire ./ns-2.26/mac/;
Copier les fichiers 16) et 17) dans le répertoire ./ns-2.26/common;
Et finalement le fichier 18) dans le répertoire ./ns-2.26/tcl/mcast/.
Après avoir copier les fichiers, dans le répertoire ns-2.26, modifier Makefile.in par l'ajout du
fichier objet du protocole à la liste des fichiers objet de ns.
Les fichiers objets ajoutés 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 répertoire ./ns-
2.26.
) Make : pour créer les nouvelles objets.
Le protocole MAODV est enfin implémenté sur NS2.

Annexe 3 sup’com
Annexe 3
Modèle de trafic multicast
Le modèle de trafic décrit les ensembles nœuds {Nœud source, les nœuds du group multicast
destinations} choisi pour une communication (l’utilisateur celui qui impose le nombre des
nœuds émettrices et le nombre des nœuds réceptrices qui constituent le groupe multicast.
Le script TCL permettant de générer un trafic pour 50 nœuds avec le nœud 0 comme source et
les nœuds 40 à 49 des nœuds réceptrices 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"
}
Création des scénarios des nœuds mobiles
Dans le répertoire : ns-allinone-2.26/ns-2.26/indep-utils/cmu-scen-gen/setdest, il faut exécuter :

./setdest [-n num_of_nodes] [-p pausetime] [-s maxspeed] [-t simtime] [-x maxx] [-y maxy] >
[output-file]
Par exemple dans le cas d’un réseau de 50 nœuds avec la vitesse de mobilité des nœuds de 5 m/s
et dans une surface de 500m x 500m on lance la ligne suivante (dans le répertoire déjà cité) :
./setdest –n 25 –p 0 –s 5 –x 500 –y 500 > scen25

KAMMOUN Sabeur

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

KAMMOUN Sabeur

Загружено:

Авторское право:

Доступные форматы

Cycle de formation des ingénieurs en Télécommunications

Rapport de Projet de fin d’études

Implémentation de la QoS sur un

Année universitaire : 2005/2006

A mon frère et ma sœur,

A mon oncle et toute sa famille,

A tous ceux qui m'aiment ; A tous ceux que j'aime,

Mes sincères remerciements s’adresse à M. Nabil TABBANE pour son

encadrement et ses qualités humaines.

Je tiens aussi à remercier tous mes enseignants de l'Ecole Supérieure des

Communications de Tunis pour l’effort qu’ils ont déployé durant ma formation.

Implémentation de la QoS dans un protocole de routage (multicast) ad hoc

Réseaux ad hoc, QoS, AODV, Multicast-AODV.NS-2

RESEAUX AD HOC ET QOS .........................................................................................................2

LE PROTOCOLE DE ROUTAGE MAODV ...............................................................................13

II.1 GENERALISATION ...................................................................................................................13

CHAPITRE III ................................................................................................................................28

IMPLEMENTATION DE LA QOS AU NIVEAU ROUTAGE..................................................28

EVALUATION DES PERFORMANCES ....................................................................................38

IV.1 INTRODUCTION ......................................................................................................................38

Figure 1.1 : Modélisation d’un réseau ad hoc .....................................................................................3

Tableau 1 : Paramétrage du contexte de simulation ............................................................ 41

Projet de fin d’étude 1

Réseaux ad hoc et QoS

I.2 Etat d’art

Projet de fin d’étude 2

collection de nœuds mobiles formant un réseau temporaire a topologie variable et fonctionnant

I.2.1 Modélisation d’un réseau ad hoc

Un réseau ad hoc peut être modélisé par un graphe Gt = (Vt, Et). Où :

Figure 1.1 : Modélisation d’un réseau ad hoc

Figure 1.2 : Le changement de la topologie des réseaux ad hoc

Projet de fin d’étude 3

I.2.2 Les applications des réseaux ad hoc

I.2.3 Les caractéristiques des réseaux ad hoc

Les réseaux mobiles ad hoc sont caractérisés par :

Projet de fin d’étude 4

De telles caractéristiques peuvent contrarier l’introduction de la qualité de service dans les

I.3 Protocoles de routage dans les réseaux ad hoc

I.3.2 Les protocoles de routage réactifs

• Le protocole de routage DSR.

• Le protocole de routage TORA.

I.3.3 Le protocole de routage AODV

• Le protocole AODV [2] représente essentiellement une amélioration de l'algorithme DSDV. Le

Projet de fin d’étude 5

Formats des messages RREQ :

Type J R Réservé Nombre de sauts

Projet de fin d’étude 6

Formats des messages RREP :

Type L R U Réservé Taille préfixe Nombre de sauts

• L : si L = 1 alors il s’agit d’un message hello

I.4 QoS dans les réseaux ad hoc

Projet de fin d’étude 7

I.4.1 Les métriques de QoS pour un environnement ad hoc

¾ Délai : Ce paramètre représente le délai de bout en bout nécessaire pour transmettre un

¾ Perte de paquet : Ce paramètre indique le taux de suspension de la transmission des paquets

Projet de fin d’étude 8

I.4.2 QoS au niveau routage

I.4.2.1 Core-Extraction Distributed Ad hoc Routing Algorithm (CEDAR)

Projet de fin d’étude 9

Figure 1.3 : Nœud cœur en CEDAR

I.4.2.2 Ticket-Based QoS Routing

Projet de fin d’étude 10

I.4.2.3 Multipath QoS Routing Protocol