rapport de projet de fin d’études - read.pudn.comread.pudn.com/downloads154/doc/comm/684760/site...

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

Projet de fin d’étude 1

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.

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.

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 :

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

1

2

3

4

5

6

7

8 Unité mobileLien de communication

1

2

3

4

5

6

7

8 Unité mobile

Lien de communication



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.



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.

Unité mobile

Lien de communication

Nœud coeur

Lien virtuel

1

2

3

4

5

6

7

8



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.

Figure 2.2 : Construction de la table de routage unicast

(1:3)

[8:8]

(1:1)

6

(-:-) [source: prochain saut vers la source] [-:-] [destination: prochain saut vers la destination]

RREQ

RREP

Membre de groupe

Group leader

Membre de l’arbre



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.

Figure 2.3 : Construction de la table du group leader

[6:6]

[6:9]

[6:4]

[6:6]

[6:6]

[6:5]

[6:8]

[6:6] [6:3]

6

Envoie du message GRPH

[-:- ] [destination:prochain saut vers la destination]

Membre de groupe

Group leader

Membre de l’arbre



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 .

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

[-:-] [source:prochain saut vers la source]

[1:1] [1:1]

[1:2]

[1:3]

[1:5] [5]

[7]

[8] 6

RREQ-J RREP-J

[-] prochain saut en amont

Mémoire cache

Membre de groupe

Group leader

1



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.

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.

[5]

[7: 1 ]

[6: 5]

6

1

MACT-J

[-,-] [Prochain saut en amont: Prochain saut en aval]

Membre de groupe

Group leader



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).

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

95

7

28

10

6

1

3

9

5

7

28

10

6

1

3RREQ-J

[2,8:7] [8,2:1]

Liaison

[-,-,…:-] Table multicast



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).

Figure 2.7 : Sélection du group leader 1ère cas

Membre de groupe

9

5

7

28

10

6

1

3

9

5

7

28

10

6

1

3

Group leader

[2,8:7] [8,2:]

[10:9] [10:9]




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.

Figure 2.8 : Sélection du group leader 2ème cas

Membre de groupe

9

5

7

2 8

10

6

1

3

9

5

7

28

10

6

1

3

[9:7]

MACT-P

Group leader



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.

Membre de groupe

9

5

7

28

10

6

1

3

9

5

7

28

10

6

1

3MACT-GL

Group leader

[2,8:7] [8:2]

[9,10: ] [10:9]




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

9

5

7

28

10

6

1

3

[2,8:7]

[10:9]

9

57

28

10

6

1

3

[8:7]

Membre de groupe

MACT-P

Group leader




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.

Figure 2.11 : Fusion d’arbres

9

5

7

28

10

6

1

3

[8,2: ]

[10:9]

9

5

7

28

10

6

1

3

[8:2]

Membre de groupe

RREQ-JR/RREP-JR

Group leader

[-,-,…:-] Table multicast RREQ-JR/RREP-R

[10,9:1]



À 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 :

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).

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

N1

N2

RREQ, ts

ts

tr

N1

N2

RREQ, d1



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 :

srNN ttd −=21 (3.1)

Le nœud N2 peut maintenant estimer le débit maximal sur le lien N1 N2 :

21NNlienlesur d

TDébit = (3.2)

T : Taille du paquet RREQ,

21NNd : 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.



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.

6

Membre de groupe

Group leader

Membre de l’arbre RREQ,d1,ts1 RREQ,d1,ts3



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

sauts Prochain

saut Numéro de

séquence Délai de validité débit

@ du groupe multicast 0 3 1 X1 1000000000

Table du nœud 3 :

Table du nœud 8 :

destination Nombre de

sauts Prochain

saut Numéro de

séquence 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.

Destination Nombre de sauts

Prochain saut

Numéro de séquence

Délai de validité débit




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.

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

6

Membre de groupe

Group leader

Membre de l’arbre RREQ,d1,ts1



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.

N2

N1 RREQ, tr1,dprop,dr tr1

tr



Notons que le délai 21NNd 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.

⎟⎟⎠

⎞⎜⎜⎝

⎛×=

contrôledepaquetduTailledonnéesdepaquetduTailledd NNNN 2121' (3.3)

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 dN1N2

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 21NNd 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.

N1

N2

N0



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.

6

Membre de groupe

Group leader

Membre de l’arbre RREQ tr, NTT, dr RREQ tr1, NTT1, dr1



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.

End to End Delay : ∑∑ −

×=reçus

)()(1000

paquets

iTiTEED i

ASAR



• 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 : 100récepteur de nombreémis

reçus ×

×=∑

∑paquets

paquetPDR

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.

Route Acquisition Latency : ∑∑ −

×=reçus

)()(1000

paquets

iTriTsRAL i

• 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 0 s

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

multicast (nombre de connexions pour le AODV unicast)

5

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

0

5000

10000

15000

20000

25000

0 5 10 15 20

vitesse (m/s)

nom

bre

de p

aque

ts d

e co

ntro

les

(paq

uets

toh_aodv toh_maodvtoh_aodv_bwtoh_maodv_bw

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.

0

5

10

15

20

25

30

0 5 10 15 20

vitesse (m/s)

déla

i d'é

tabl

isse

men

t d'u

ne ro

ute

(ms)

ral_aodv ral_maodvral_aodv_bw ral_maodv_bw

Figure 4.2 : Délai d’établissement d’une route en fonction de la vitesse en respectant la

contrainte de débit

0

5

10

15

20

25

30

35

0 50 100 150 200 250 300 350 400 450 500 550 590

temps de simulation (sec)

déla

i d'é

tabl

isse

men

t d'u

ne ro

ute

(ms)

ral_maodv_bw (5m/s)ral_aodv_bw (5m/s)ral_maodv_bw (20m/s)ral_aodv_bw (20m/s)

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.

60

6264

66

6870

72

7476

7880

82

8486

88

9092

94

9698

100

0 5 10 15 20

vitesse (m/s)

taux

de

paqu

ets

livré

s av

ec s

uccè

s (%

)

pdr_aodv pdr_maodvpdr_aodv_bw pdr_maodv_bw


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.

0

10

20

30

40

50

60

70

80

90

100

110

0 50 100 150 200 250 300 350 400 450 500 550 590


taux

de

paqu

ets

livré

s av

ec s

uccè

s (%

)

pdr_maodv_bw (5m/s)pdr_aodv_bw (5m/s)pdr_maodv_bw (20m/s)pdr_aodv_bw (20m/s)

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

0

20

40

60

80

100

120

0 5 10 15 20vitesse (m/s)

déla

i de

bout

en

bout

(ms)

eed_aodv eed_maodveed_aodv_bweed_maodv_bw


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.



0

20

40

60

80

100

120

140

0 50 100 150 200 250 300 350 400 450 500 550 590


déla

i de

bout

en

bout

(ms)

eed_maodv_bw (5m/s)eed_aodv_bw (5m/s)eed_maodv_bw (20m/s)eed_aodv_bw (20m/s)

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


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

22000

0 5 10 15 20

vitesse (m/s)

nom

bre

de p

aque

ts d

e co

ntro

le (p

aque

ts)

toh_aodv toh_maodvtoh_aodv_délai toh_maodv_délai

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

IV.6.2.2 Délai d’établissement d’une route 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.

0

5

10

15

20

25

30

0 5 10 15 20

vitesse (m/s)

déla

i d'é

tabl

isse

men

t d'u

ne ro

ute

(ms

ral_aodv ral_maodvral_aodv_délai ral_maodv_délai

Figure 4.9 : Délai d’établissement d’une route en fonction de la vitesse en respectant la

contrainte de délai



0

5

10

15

20

25

30

35

40

0 50 100 150 200 250 300 350 400 450 500 550 590temps de simulation (sec)

déla

i d'é

tabl

isse

men

t d'u

ne ro

ute

(ms)

ral_maodv_délai (5m/s)ral_aodv_délai (5m/s)ral_maodv_délai (20m/s)ral_aodv_délai (20m/s)

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.

IV.6.2.3 Taux de paquets livrés avec succès 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.



60

65

70

75

80

85

90

95

100

105

0 5 10 15 20

vitesse (m/s)

taux

de

paqu

ets

livré

s av

ec s

uccè

s (%

)

pdr_aodv pdr_maodvpdr_aodv_délai pdr_maodv_délai


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.

0

20

40

60

80

100

120

0 50 100 150 200 250 300 350 400 450 500 550 590


taux

de

paqu

ets

livré

s av

ec s

uccè

s (%

)

pdr_maodv_délai (5m/s)pdr_aodv_délai (5m/s)pdr_madv_délai (20m/s)pdr_aodv_délai (20m/s)

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.

IV.6.2.4 Délai moyen de bout en bout 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.

0

20

40

60

80

100

120

0 5 10 15 20

vitesse (m/s)

déla

i de

bout

en

bout

(ms)

eed_aodv eed_maodveed_aodv_délai eed_maodv_délai


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.



.

0

10

20

30

40

50

60

70

80

90

100


déla

i de

bout

en

bout

(ms)

eed_maodv_délai (5m/s)eed_aodv_délai (5m/s)eed_maodv_délai (20m/s)eed_aodv_délai (20m/s)

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


0

5000

10000

15000

20000

25000

0 5 10 15 20vitesse (m/s)

nom

bre

de p

aque

ts d

e co

ntro

le (p

aque

ts)

toh_aodv toh_maodvtoh_qos-aodvtoh_qos-maodv

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.



IV.6.3.2 Délai d’établissement d’une route 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.

0

5

10

15

20

25

30

0 5 10 15 20vitesse (m/s)

déla

i d'é

tabl

isse

men

t d'u

ne ro

ute

(ms)

ral_aodv ral_maodvral_qos-aodvral_qos-maodv

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

0

5

10

15

20

25

30

35

40

45

50


déla

i d'é

tabl

isse

men

t d'u

ne ro

ute

(ms)

ral_qos-maodv (5m/s)ral_qos-aodv (5m/s)ral_qos-maodv (20m/s)ral_qos-aodv (20m/s)

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.

IV.6.3.3 Taux de paquets livrés avec succès

60

65

70

75

80

85

90

95

100

105

0 5 10 15 20

vitesse (m/s)

taux

de

paqu

ets

livré

s av

ec s

uccè

s (%

)

pdr_aodv pdr_maodvpdr_qos-aodvpdr_qos-maodv

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.



0

20

40

60

80

100

120


taux

de

paqu

ets

livré

s av

ec s

uccè

s (%

)

pdr_qos-maodv (5m/s)pdr_qos-aodv (5m/s)pdr_qos-maodv (20m/s)pdr_qos-aodv (20m/s)

Figure 4.19 : Taux de paquets livrés avec succès en fonction du temps avec contraintes de débit et de

délai

IV.6.3.4 Délai moyen de bout en bout

0

20

40

60

80

100

120

0 5 10 15 20vitesse (m/s)

déla

i de

bout

en

bout

(ms)

eed_aodv eed_maodveed_qos-aodveed_qos-maodv

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.

0

20

40

60

80

100

120


déla

i de

bout

en

bout

(ms)

eed_qos-maodv (5m/s)eed_qos-aodv (5m/s)eed_qos-maodv (20m/s)eed_qos-aodv (20m/s)

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


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

Création de scénario de simulation

Problème à étudier

Exécution des simulations

Analyse des résultats

Modèle de simulation

Modification à NS2 (code OTcl et/ou

c++)

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

rapport de projet de fin d’études - read.pudn.comread.pudn.com/downloads154/doc/comm/684760/site...

Documents