Vous êtes sur la page 1sur 48
INSTITUT DE LA FRANCOPHONIE POUR INFORMATIQUE Rapport de travail personnel encadré Protocoles de routage dans
INSTITUT DE LA FRANCOPHONIE POUR INFORMATIQUE
Rapport de travail personnel encadré
Protocoles de routage dans les réseaux multi-radios mobiles
Superviseurs:
Victor MORARU
LE Van Tuan
Etudiant :
TRAN Quoc Tuan
Promotion 14, IFI
Hanoï, Juin - 2009

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Remerciements

Avant de vous présenter ce rapport, Je tiens à remercier tous ceux qui m’ont aidé à

réaliser ce TPE. Je voudrais en particulier citer :

M. Victor MORARU, professeur à l’Institut de la francophonie pour l’informatique,

il m’a donné ses commentaires. En plus, il m'a donné beaucoup de conseils pour résoudre tous les problèmes en conception et en programmation. C’est intéressant et utiles pour moi.

M. LE Van Tuan, chercheur de laboratoire MSI, il m’a proposé l’idée de mon travail théorique et pratique. Ces idées m’ont aidé à vérifier le but de TPE.

Enfin, tous les autres professeurs et amis à l’IFI, les personnes m’ont donné des conseils, des remarques et des critiques pour que je puisse améliorer le résultat.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Table des matières

Remerciements

 

i

Table des matières

ii

Chapitre 1. Introduction

1

1.1 Contexte

1

1.2 Travail

théorique

1

1.3 Travail

pratique

2

1.4 Termes techniques principaux

2

1.5 Outils employés

 

2

1.6 Résultats attendus

3

1.7 Difficultés principales

3

Chapitre 2. Etat de l’art

4

2.1

Technologies de communication sans fils dans les réseaux informatiques

4

2.1.1 Wifi (802.11 a/b/g /draft n)

4

2.1.2 Wimax (802.16d fixable / 802.16e mobile)

4

2.1.3 ZigBee (802.15.4 Wireless Personal Area Network)

4

2.1.4 Bluetooth

4

2.2

Protocoles de routages dans le réseau ad-hoc

5

2.2.1 Le

protocole

proactif

5

2.2.2 Le

protocole

actif

5

2.2.3 Le

protocole

hybride

6

2.3

Projets de modèle multi-interface multicanaux

6

2.3.1 MITF

6

2.3.2 TENS

6

2.3.3 Hyacinth

7

2.3.4 Module-based Wireless Node (MWNode - module de nœud sans fil)

7

2.3.5 Modèle multi-interface multicanaux de chercheur Ramón Agüero Calvo 8

2.4

Protocoles de routage dans le réseau multi-radio

8

2.4.1 Approche de protocole MAC et couche-lien multicanaux

8

2.4.2 Approche de protocole de routage multicanaux

9

2.4.3 Problèmes existants

9

2.5

Simulation des protocoles de routage de réseaux sans fils dans NS2

10

2.5.1 Simulation des protocoles de routage

10

2.5.2 Problèmes existants dans NS2

10

Chapitre 3. Réalisation pratique

12

3.1

Objectif

12

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

3.2 Construction d'un modèle des nœuds mobiles multi-interfaces multicanaux 12

3.2.1 Architecture

d’un nœud mobile

12

3.2.2 Architecture original d’un nœud mobile NS2

12

3.2.3 Nouvelle Architecture d’un nœud mobile

14

3.2.4 Changement dans la source de code NS2

15

3.3

Changement l’agent de routage pour s’adapter le nouveau modèle de multi-

interfaces

16

16

3.3.2 Changement de code C++ pour créer un nouveau modèle en s’adaptant le

3.3.1 Protocole AODV

modèle multicanaux multi-interfaces

17

3.4

Protocole de routage dans le modèle multicanaux multi-interfaces MCR

21

3.4.1 Stratégie de l’assignement d’interface

22

3.4.2 Changement du code C++ pour l’implémentation de commutation de

l’interface

24

3.5

Table de changement de code

28

Chapitre 4. Expérimentation

 

29

4.1

Test de scénario de modèle des nœuds multi-interfaces

29

4.1.1 Topologie du réseau

29

4.1.2 Contenu de scénario

29

4.1.3 Résultat :

29

4.2

Test de scénario de routage de modèle des nœuds multi-interfaces

30

4.2.1 Topologie du réseau

30

4.2.2 Contenu de scénario

30

4.2.3 Résultat

30

4.3

Deux scénarios de transmission de même fréquence

33

4.3.1 Scénario 1 de transmission de même fréquence

33

4.3.2 Scénario 2 de transmission de même fréquence

34

4.4

Deux scénario

de

distance

36

4.4.1 Scénario 1 de distance

36

4.4.2 Scénario 2 de distance

37

4.5

Scénario d’implémentation de commutation de l’interface

38

4.5.1 Topologie du réseau

38

4.5.2 Contenu de scénario

39

4.5.3 Résultat

39

Chapitre 5. Conclusions et perspectives

40

5.1 Conclusion

 

40

5.2 Perspectives

40

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Chapitre 6.

Bibliographies et références

6.1 scientifiques

Références

6.2 autres

Références

Table des figures

Figure 1 - Architecture originale d'un nœud mobile dans NS2 Figure 2 - Nouvelle architecture d’un nœud mobile dans NS2 Figure 3 - Processus de découverte de route Figure 4 - Processus de l’entretien de route Figure 5 - Commutation de l’interface avec 3 canaux et 2 interfaces Figure 6 - File de paquet de chaque canal Figure 7 - Topologie de modèle des nœuds multi-interfaces (scénario 1) Figure 8 - Résultat de scénario 1 Figure 9 - Topologie de scénario 2

Figure 10 - Débit de nœud 0

Figure 11 - Débit de nœud 0 et nœud

Figure 12 - Topologie de scénario 1 de même fréquence

Figure 13

- Figure 14 - Topologie de scénario 2 de transmission de même fréquence Figure 15 - Débit de nœud 0 et nœud 1 Figure 16 - Topologie de scénario 1 de distance

Figure 17 - Débit de nœud n

Figure 18 - Topologie de scénario 2 de distance

Figure 19

- Figure 20 - Topologie de scénario 1 de distance

Figure 21 - Débit de nœud n

Débit de 2 connexion

Débit de nœud n

42

42

43

13

14

16

17

23

24

29

29

30

31

32

33

34

35

35

36

37

37

38

39

39

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Chapitre 1. Introduction

1.1 Contexte

Aujourd’hui, les réseaux sans fils sont connus pour appliquer à transférer des données entre les terminaux mobiles. Il y a beaucoup de technologies de réseaux sans fils comme : Wifi, Wimax, ZegBee, Bluetooth, … En conséquence, il est difficile de choisir une technologie optimale, et on se propose de les intégrer sur le même réseau. D’autre part, il y a des problèmes de ces technologies comme : renforcer la robustesse du réseau, optimiser l’utilisation de bande passante, économiser l’énergie … surtout le problème de protocole de routage. Mon sujet qui est un sujet de recherche va concentrer la recherche des protocoles de routage des réseaux multi-radio mobiles. Alors, ce TPE à pour but de faire d’une étude de routage dans les réseaux multi-radio (multifréquence, multicanaux, etc.) et évaluer les caractéristiques de ces réseaux comme : la performance, la fiabilité, la latence, etc. De plus, je peux proposer un nouveau protocole ou adapter un protocole existant pour faire du routage et créer les paramètres meilleurs que les réseaux existants.

1.2 Travail théorique

o

Etudier tous les technologies de communication sans fils dans les réseaux informatiques

Wifi (802.11 a/b/g/ draft n)

Wimax (802.16d fixable/ 802.16e mobile)

ZegBee(802.15.4-WPAN : Wireless Personal Area Network)

Bluetooth (WPAN)

o

Etudier les protocoles principaux de routage dans les réseaux ad hoc, les protocoles de routage multi-radio :

AODV (réactif)

DSR (réactif)

OLSR (proactif)

TBRPF (proactif)

DSDV (proactif) ….

o

Etudier le simulateur NS2 (The Network Simulator) et les moyens disponibles

o

comme le langage TCL, C++ … pour faire de simuler des protocoles du routage pour les réseaux sans fils, les différents technologies de communication radio. Etudier l’état de l’art sur les protocoles de routage multi-radio (multifréquence, multicanaux, etc.). En conséquence, il faut donner les avantages et les inconvénients de ces protocoles.

o

Si possible, proposer un nouveau protocole ou adapter un protocole existant pour faire du routage dans les réseaux multicanaux. Forcément, ce protocole possède les avantages meilleurs que les protocoles existants.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

1.3 Travail pratique

o

Apprendre tous les quelques choses pour servir du simulateur NS2 (installation, programmation, simulation).

o

Construire les modèles des protocoles de routages avec NS2 et réaliser les simulations de ces modèles.

o

Comparer des performances des protocoles de routage existants(en termes de débit, robustesse, tolérance aux déconnexions, latence, QoS,…

o

Réaliser et simuler un protocole de routage adapté aux réseaux multi-radio ou

multifréquence ou multicanaux,…

Et analyser et donner les résultats.

1.4 Termes techniques principaux

o

Réseau informatique : est un groupe des ordinateurs connectés ou des équipements pour échanger les informations. Ce réseau doit distinguer le réseau de télécommunication qui est basé sur le transfert des signaux de voix. Aujourd’hui, deux réseaux sont contigus avec le développement de technologie IP et la commutation de paquet.

o

Protocole : permettent de définir de façon standardisée la manière dont les informations sont échangées entre les équipements du réseau : il s'agit de procédures qui contrôlent le flux d'information entre deux équipements [21].

o

Protocoles du routage : sont des protocoles qui permettent d'échanger les informations de routage entre les routeurs eux-mêmes [21].

o

Réseaux multi-radio /multifréquences/ multicanaux : c’est-à-dire les réseaux sans fils qui utilisent la méthode des ondes radio / des ondes de autres fréquences / des ondes de autres canaux pour échanger les informations.

o

Réseaux Ad-hoc : est un type de réseau sans fils. Chaque nœud prêt à transmettre des données aux autres nœuds, le rôle d’un nœud est comme une station et il n’y a pas le nœud principal. Le premier réseau Ad-hoc est le réseau radio du paquet (PRNETs) aux années 1970, parrainé par la DARPA

o

Débit binaire : mesure une quantité de données numériques transmises en bits par seconde (bit/s, b/s ou bps).

o

Robustesse : c’est-à-dire l’intensité d’onde dans l’espace. Il est évalué par la rangée de réseaux sans fils

o

Tolérance aux déconnexions : c’est-à-dire le nombre d’ordinateurs pour permettre d’accéder le réseau sans fils. Ce paramètre représente la capacité de réseau.

1.5 Outils employés

o Simulateur NS2 (Network Simulator) :c’est un simulateur des événements discrets pour but à faire de la recherche de réseau. NS2 fournit un soutien substantiel pour simuler le TCP, le routage, le multicast et les protocoles dans les réseaux filaires et les réseaux sans fils (local et satellite). NS2 est écrit en C++, et il y a une version orientée-objet de TCL, qui s’appelle OTcl. De plus, aujourd’hui,

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

NS2 a intégré quelques outils comme NAM, qui est basé sur l’outil d’animation TCL/TK pour afficher des traces de réseau simulé et des traces de paquet réelles. Il soutient la maquette de topologie, l’animation au niveau de paquet, les outils divers du contrôle de données.

o

Langage TCL/Tk (Tool Command Language) : est un outil très puissant, mais il est facile d’apprendre le langage de programmation dynamique. Il est adapté aux domaines larges comme : le Web et les applications de bureau, réseau, l'administration, les essais et beaucoup d'autres. En plus, Tk est une interface graphique utilisateur d'outils pour développer des applications de bureau à un niveau plus élevé que les approches conventionnelles. Tk est l'interface graphique standard, non seulement pour Tcl, mais pour beaucoup d'autres langages dynamiques, et elle peut produire des applications qui s'exécutent aux environnements comme Windows, Mac OS X, Linux…

o

Langage C++ : est un langage de programmation permettant la programmation sous de multiples paradigmes comme, par exemple, la programmation procédurale, la programmation orientée objet et la programmation générique. Dans ce sujet, le langage C++ peut être récrit quelques classes pour simuler les réseaux meilleurs.

1.6 Résultats attendus

o

Donner une synthèse d’analyse des protocoles du routage dans les réseaux multi- radio mobiles.

o

Chercher et simuler les modèles des protocoles de routage avec NS2.

o

Faire d’une comparaison des performances des protocoles du routage existants avec les paramètres : débit, robustesse, tolérance aux déconnexions,… Donner les avantages et les inconvénients de ces protocoles

o

Si possible, donner, simuler un protocole de routage adapté aux réseaux multi- radio, multifréquence ou multicanaux…

1.7 Difficultés principales

o

Il est difficile de donner un nouveau protocole ou adapter un protocole existant qui est meilleur que les protocoles existants.

o

Il y a beaucoup de protocoles du routage dans le réseau Ad-hoc comme : les protocoles du routage proactifs, les protocoles du routage réactifs, les protocoles du routage adaptatifs, les protocoles du routage hybride, les protocoles du routage hiérarchique, …En conséquence, il est difficile de déterminer les protocoles principaux du routage

o

Le simulateur NS2 est un environnement console, il est moins convivial que les autres simulateurs comme : OMNeT++, OpNET,…

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Chapitre 2. Etat de l’art

La partie théorique de mon TPE contient d’étudier les technologies de communication sans fils dans les réseaux informatiques et les protocoles de routage dans les réseaux ad-hoc et les protocoles de routage multi-radio en particulier. En plus, cette partie est destinée à vous présenter le modèle de multi-radios et multicanaux dans le logiciel de simulateur NS2.

2.1 Technologies

de

communication

réseaux informatiques

sans

fils

dans

les

Aujourd’hui, il y a des technologies de communication sans fils qui a pour but de transférer rapidement des données, d’économiser l’énergie, optimiser l’utilisation de bande passante, …

2.1.1 Wifi (802.11 a/b/g /draft n)

Wifi est une technique de réseau informatique sans fil pour fonctionner le réseau interne et un moyen d’accès à l’Internet. Il est basé sur la norme IEEE 802.11 (ISO/CEI 8802-11). La norme 802.11 est un standard international, qui ont les petites normes comme :

802.11a, 802.11b, 802.11 c, 802.11 d, …

IEEE 802.11a : spécifie 52 canaux de sous-porteuses radio dans la bande de fréquences des 5 GHz.

IEEE 802.11b : spécifie 13 canaux dans la bande de fréquences des 2.4 GHz

IEEE 802.11 draft n : spécifie quelques canaux dans 2 bandes de fréquences des 2.4 GHz et 5 GHz.

2.1.2 Wimax (802.16d fixable / 802.16e mobile)

Wimax Worldwide Interoperability for Microwave Access est une technologie de télécommunication sans fils qui est basé sur la norme IEEE 802.16 ou s’appelle Broadband Wireless Access. La vitesse WIMAX peut être jusqu’à 75 Mb/s (large bande symétrique). Aujourd’hui, on divise Wimax en 2 normes : 802.16d pour l’utilisateur fixable et 802.16e pour l’utilisateur mobile.[7].

2.1.3 ZigBee (802.15.4 Wireless Personal Area Network)

ZIGBEE - nouvelle technologie sans fils qui est présenté par le standard IEEE 802.15.4 PAN (Personal Area Network). Cette technologie conçoit les larges applications et pour remplacer les technologies non-standards. Aujourd’hui, elle se marche dans la bande de 868MHz en Europe, bande de 914MHz aux États-Unis, et dans la bande ISM 2.4 GHz (Industrial, Scientific and Medical) au monde entier. ZIGBEE a pour but d’appliquer le WPAN (Wireless Personal Area Network).[29].

2.1.4 Bluetooth

Bluetooth est une technologie émergeante qui peut remplacer l’interconnexion en câble. Bluetooth permet aux équipements de connecter en distance courte avec la bande non- autorisée 2.4 GHz. Il soutient la connexion-orientée et le lien sans connexion. Pour le prix bon marché et la popularité de Bluetooth, cette technologie est non seulement un fondement

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

idéal de LAN sans fils, mais encore une technologie potentielle de PAN ad-hoc (Personal Area Network ad-hoc)

2.2 Protocoles de routages dans le réseau ad-hoc

Le réseau Ad-hoc est un type de réseau sans fils. Chaque nœud prêt à transmettre des données aux autres nœuds, le rôle d’un nœud est comme une station et il n’y a pas le nœud principal. Aujourd’hui, il y a beaucoup de recherche de problème de routage dans le réseau ad-hoc surtout les protocoles de routage. Aujourd’hui, on divise en 3 types de protocole de routage dans le réseau ad-hoc [3].

2.2.1 Le protocole proactif

Le protocole proactif est un type de protocole de routage. Il peut déterminer la route indépendante avec la maquette de circulation. Les protocoles de routage traditionnels

comme : link-state, distance-vector sont proactifs. Les protocoles proactifs ont la latence plus basse depuis que les routes soient maintenues tous les temps, mais ils ont les frais généraux

qui sont plus hauts quand les routes sont en train de mettre à jour protocoles proactifs :

Voici les plusieurs

2.2.1.1 DSDV Destination Sequenced Distance Vector Routing

DSDV est un algorithme de table-moteur (table-driven), qui est basé sur le mécanisme de routage classique Bellman-Ford. L’amélioration de l’algorithme Bellman-Ford contient la liberté de boucles dans la table de routage.[28].

2.2.1.2 WRP The Wireless Routing Protocol

WRP est un protocole à base de tables qui a but pour maintenir les informations de routage entre les nœuds dans le réseau. Chaque nœud est responsable pour maintenir quatre tables : table de distance, table de routage, table de prix-lien, table de liste de message de retransmission (MRL). [9].

2.2.2 Le protocole actif

Le protocole actif est un type de protocole de routage. Il crée les routes quand le nœud de source demande une route de source à la destination. Ensuite, le processus de route découvert commence dans le réseau. Ce processus va compléter quand une route a cherché. Après une route est établie, il y a des formes de procédure maintenu de routes jusqu’à le destination devient inaccessible.[28]. Voici quelques protocoles actifs :

2.2.2.1 DSR Dynamic Source Routing

DSR est un protocole de routage, quand le nœud de source S veut envoyer un paquet au nœud de destination D, mais le nœud S ne connait pas la route au nœud D. Le nœud S va commencer le processus la découvert de route. En conséquence, le nœud S inonde les messages « Route Request » (RREQ). Chaque nœud ajoute son identification quand le transfert de message RREQ. En fin, à partir des messages RREQ, le nœud S va choisir une route plus optimale. [28].

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

2.2.2.2 AODV Ad-hoc On Demand Distance Vector Routing

AODV est un protocole de routage. DSR contient les routes de source dans le paquet en-tête. En conséquence, les paquets ont le large en-tête et pour dégrader la performance de réseau. Par contre, le protocole AODV essaie de maintenir les tables de routage pour améliorer le DSR, parce que les paquets de donnée ne contiennent pas des routes. En plus, AODV retient la fonction de DSR que les routes maintiennent entre les nœuds qui ont besoin de la communication.[28].

2.2.3 Le protocole hybride

Le protocole actif est un type de protocole de routage. Il combine le protocole proactif et le protocole actif pour améliorer mieux le routage [17]. Ce rapport va présenter le protocole hybride ZRP (Zone Routing Protocol).

2.2.3.1 ZRP Zone Routing Protocol

ZRP est un protocole de routage combiné. Il met à jour l’état de réseau et maintient la route sans se soucier d’aucunes données de circulation existent ou non. En plus, il détermine une route au nœud de destination s’il y a quelques données qui ont envoyé au nœud de destination. [28].

2.3 Projets de modèle multi-interface multicanaux

J’ai fait d’une recherche de les modèles multi-interface qui s’adaptent le modèle de simulateur NS2. Quelques approches sont utilisées ou disponibles. Dans cette section, je vais analyser 3 approches les plus pertinentes.

2.3.1 MITF

Ce projet n’est pas actif, ce qui a été réalisée à l’Université de Rio de Jainero. Son objectif était de mise en œuvre des interfaces multiples et d’adapter le protocole de routage AODV avec NS2 en version 2.28. Toutefois, puisque ce projet arrêté, il n’est pas possible d’évaluer pleinement les résultats concrets de cette recherche. La plupart des modifications qui ont été faites sur le simulateur avec les fichiers C++. Dans cette approche, il a créé les différents modules qui sont une partie de l’architecture MobileNode comme LL, ARP, MAC et les tableaux (listes de variables) …. De cette façon, il est possible de se référer au module (modèle de tableau) en utilisant le canal comme un index pour localiser les « target » correspondants dans la liste de variables de canaux. En outre, deux nouveaux tableaux ont été créés dans la classe MobileNode pour gérer la liste de nœuds associés à chaque canal, en utilisant le canal comme l'indice d'accès à ces deux nouveaux tableaux. D'autre part, l’implémentation de code Tcl et de protocole de routage AODV ont été modifiés de sorte que la capacité multi-interface pourrait être exploitée par le protocole de routage. Mais le développement de ce projet n'est pas complètement terminé.

2.3.2 TENS

Ce projet [24]. a été faite à l'Institut indien de technologie de Kanpur, en Inde. Son objectif principal était d'améliorer la ns-2.1b9a de la mise en œuvre du protocole IEEE 802.11 sur les différents aspects, comme la couche MAC et le modèle physique pour ajouter

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

le soutien l’interface multiple pour de cette version NS. La mise en œuvre multi-modèle d'interface est basée sur le multiplexage avec l’implémentation de code C++ de la couche physique. Il a utilisé un numéro de canal dans le script Tcl pour sélectionner le canal approprié. Ce modèle de multi-interface vise à imiter les différents canaux utilisés par la DSSS version de la norme IEEE 802.11 (également la comptabilisation des interférences). Cette approche a modifié les fichiers C++,Tcl et un des aspects les plus importants a été la manière dont les différents interfaces ont été incorporées dans le nœud de code Tcl, cette approche est assez semblable à celui utilisé par le projet Hyacinth. Dans ce cas, une boucle a été ajoutée à la procédure add-interface de fichier ns-mobilenode.tcl pour créer plus d'une couche physique comme MAC, LL, et IFQ par chaque nœud.

2.3.3 Hyacinth

Ce projet correspondant a été initialement réalisé à l'Université de l'État de New York

pour ns-2.1b9a [25]. , et il y a des informations disponibles sur la façon de l'utiliser sur ns-

Son principal inconvénient est qu'il fournit une configuration statique, dans

lequel tous les nœuds dans le scénario de nécessité d'intégrer jusqu'à 5 différentes interfaces. En outre, un l’agent de routage statique (configuration manuelle) a été mis en œuvre pour utiliser la capacité de multicanaux. Mais il n’existe pas les informations disponibles sur la façon de modification les agents de routage comme AODV ou DSDV et de l’utilisation de la capacité de multi-interfaces. Après avoir défini jusqu'à 11 canaux différents (et donc l'émulation de la couche physique IEEE 802.11b) dans le script de simulateur, cinq d'entre eux sont affectés à chaque nœud par la commande node-config. Par conséquent, les procédures correspondantes ont été ajoutées dans le fichier ns-lib.tcl. Ensuite, la procédure create-wireless-node qui est dans même fichier, elle demande 5 fois sur la procédure add-interface, chacun d'eux avec un canal différent. Ces segments de code sont toujours exécutés, peu importe si l'utilisateur s’intéresse au nœud spécifique avec le nombre de l’interface. En regardant les changements qui sont nécessaires au fichier mac-802.cc, il semble que pour garantir un comportement correct, dans un scénario, tous les nœuds a de même nombre d'interfaces (dans ce cas, le nombre d’interface égale 5). D’autre part, ce modèle original a été basé sur un statique, un agent de routage manuel qui a été configuré (c'est-à-dire des processus pour ajouter et supprimer des routes) à partir du scénario de script. Par conséquent, il n'est pas simple de s’étendre l'utilisation des interfaces multiples aux protocoles de routage différents

2,29 [26].

2.3.4 Module-based Wireless Node (MWNode - module de nœud sans fil)

Ce projet a été réalisé à l’université de science et technologie norvégienne. Il fournit les modules pour élargir le modèle de nœud NS2 surtout le nœud sans fils MW-Node. Un MW-Node est un noeud (et non pas un MobileNode) avec des capacités comme sans fils, la mobilité, (le soutien d’énergie, pas encore fonctionnel) - ajoutée par le moyen de modules. Le but de cette nouvelle conception de la mise en réseau sans fil et mobile de soutien ns2 en est double:

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

- De soutenir de nouvelles caractéristiques telles que de multiples canaux multiples interfaces

- De fournir une base commune pour la mise en œuvre des protocoles de routage sans fils pour remplacer les protocoles de routage dans le module de MobileNode. On fait la distinction entre:

- Multicanaux: un seul objet de l’agent de routage traite les interfaces sans fils sur les canaux différents

- Multi-interface: plusieurs interfaces, peut-être de différents types (par exemple les

différents Mac / Phy), avec un objet de l’agent de routage traite une interface. Mais cette approche a d’un inconvénient. Pour utiliser le modèle MW-Node, on doit installer un patch d’extension NS2 (aujourd’hui le patch s’adapte le logiciel NS2 en version

2.33).

2.3.5 Modèle

multi-interface

multicanaux

de

chercheur

Ramón

Agüero Calvo

Cette approche a été réalisée à l’université de Cantabrita, Espagne. Il fournit les changements de modèle original NS2 pour soutenir la multi-interface. Il permet d’avoir plus une pile sans fils au-dessous d'un seul agent de routage sur un MobileNode. Toutes les piles sans fil sont identiques (même Mac/Phy). Le code d’agent de routage doit être modifié afin de gérer plus d'une sans-fil pile. Cette disposition ne s'applique les agents de routage qui utilise le standard MobileNode. Cette approche a pour but :

- D’ajouter les interfaces multiples sur un moyen souple

- D'utiliser un certain nombre d'interfaces flexibles par nœud (c’est-à-dire : pas tous les nœuds dans le même scénario nécessité d'utiliser les mêmes interfaces).

- De modifier les protocoles de routage (existants et nouveaux) pour améliorer la

capacité de multicanaux, multi-interface. Mais cette approche a d’un inconvénient. Son modèle est vraiment multicanaux, c’est- à-dire un seul objet de l’agent de routage traite les interfaces sans fils sur les canaux différents. En conséquence, il est difficile de soutenir un système qui utilise les interfaces différentes avec les technologies différentes. Par exemple, il est impossible d’avoir un système qui utilise un carte de GPRS et un carte de Wifi 802.11 pour accéder l’Internet.

2.4 Protocoles de routage dans le réseau multi-radio

Le problème de routage dans le réseau multi-radio (multicanaux, multi-interface), il n’est pas nouveau. Il y a des chercheurs qui cherchent régulièrement ce problème. De plus, il y a quelques approches de problème de routage dans le réseau multi-radio. Mais, on divise en 2 approches suivant :

2.4.1 Approche de protocole MAC et couche-lien multicanaux

Plusieurs chercheurs ont proposé les protocoles MAC qui sont basés sur la norme IEEE 802.11 par l’utilisation de multicanaux. Nasipuri et les autres auteurs [11]. , [12]. , Jain et les autres auteurs [13]. ont proposé un classe de protocole où touts les nœuds qui ont une interface pour chaque canal. Ces

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

protocoles sont différents dans le calcul de métrique quand on choisit un canal pour la communication entre les nœuds. Ensuit, So et les autres auteurs [16]. ont proposé une solution de multicanaux que l’utilisation de l’interface unique. Néanmoins, touts les protocoles multicanaux ci-dessus veulent changer la norme IEEE 802.11 et n’utilisent pas l’hardware actuel. Bahl et les autres auteurs [15]. ont proposé une solution de couche-lien que ce protocole utilise une interface unique et peut exécuter la norme IEEE 802.11 non-modifiée. Adya et les autres auteurs [14]. ont proposé une solution de couche-lien pour marquer des données dans la multi-interface. Kyasanur et les autres auteurs [2]. ont proposé une nouvelle stratégie de distribution de l’interface pour la multi-interface. Cette stratégie peut implémenter sur la couche-lien.

2.4.2 Approche de protocole de routage multicanaux

So et les autres auteurs [18]. ont proposé un protocole de routage pour le réseau multicanaux que ce protocole utilise une interface unique à chaque nœud. Shacham et les autres auteurs [16]. ont proposé l’architecture pour les réseaux multicanaux sans fils ce que l’utilisation de l’interface unique. Chaque nœud a un canal pour recevoir des données. Et quand un nœud veut transférer un paquet de données, ce nœud commute le canal de transfert. Mais cette architecture n’estime pas l’impact de latence de commutation. De plus, les 2 protocoles de routage sans fils existants : DSR, AODV qui soutiennent multiple interfaces, mais ces protocole n’exploite pas les canaux disponibles. Draves et les autres auteurs [18]. ont proposé le protocole LQSR un protocole de routage pour les réseaux multicanaux, multi-interface. LSQR suppose que le nombre d’interfaces est aussi égal que le nombre de canaux. De plus, LQRS est basé sur le réseau statique, le réseau sans fil multi-hop tels que le réseau de maille, il n’explique pas l’influence de mobilité des nœuds dans le routage heuristique. D’autre part, Kyasanur et les autres auteurs [2]. ont proposé un protocole de routage pour le réseau multicanaux et multi-interface. Ce protocole s’appelle MCR (Multi-Channel Routing Protocol). Toutefois, il ajoute une petite couche au-dessus de la couche MAC et le protocole implémente à la couche réseau. Si le nombre de canaux est trop grand, tous les canaux ne sont pas utilisés. En conséquence, la performance de réseau n’est pas optimale.

2.4.3 Problèmes existants

Le nombre de canaux orthogonaux

Deux canaux s’appellent canaux orthogonaux, c’est-à-dire ils ne sont pas chevauchants dans le spectre de l’onde, et ils ne créent pas l’interférence entre les autres canaux, parce que les signaux en haut fréquence créent facilement l’interférence. En effet, la norme 802.11a donne 12 canaux non-chevauchants, et la norme 802.11b donne 3 canaux non- chevauchants. De plus, le nombre de canaux orthogonaux est moins grand que le nombre de canaux non-chevauchants. Le nombre de canaux orthogonaux influe sur la performance de protocole de routage. Je pense qu’au futur, les nouveaux équipements vont avoir des filtres meilleurs pour élever le nombre de canaux orthogonaux.

La latence de commutation d’interface

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Dans la réalité, le nombre d’interfaces est plus petit que le nombre de canaux disponibles. Quand on utilise touts les canaux d’une interface, on va commuter une autre interface. Pour la commutation d’une interface d’un canal à l’autre interface, il va créer une latence, qui s’appelle la latence de commutation d’interface. Aujourd’hui, avec les normes IEEE 802.11, la latence est de quelques millisecondes aux quelques centaines de microsecondes. A l’avenir, la latence va réduire aux quelques dizaines de microsecondes. En plus, il est possible de commuter les fréquences aux autres bandes. Par exemple, quelques cartes de wifi peuvent soutenir 802.11a (5GHz), 802.11b/g (2.4 GHz) et 802.11 draft n (2.4 et 5 GHz). C’est pourquoi, ils peuvent commuter entre 2 bandes.

Protocole de routage multicanaux

Aujourd’hui, dans le réseau sans fil, on divise les protocoles de routage en 3 types principaux : le protocole proactif, le protocole réactif, le protocole hybride. Mais la plupart des protocoles ne soutient pas le réseau multicanaux. Les recherches de réseaux sans fils multicanaux n’appliquent pas dans la réalité. A l’avenir, pour le développement de nouveaux réseaux comme : Wimax, Ad-hoc, Sensor, etc. le protocole de routage multicanaux va développer mieux.

2.5 Simulation des protocoles de routage de réseaux sans fils dans NS2

Simulateur NS2 (Network Simulator) est un simulateur des événements discrets pour but à faire de la recherche de réseau. NS2 fournit un soutien substantiel pour simuler le TCP, le routage, le multicast et les protocoles dans les réseaux filaires et les réseaux sans fils (local et satellite). NS2 est écrit en C++, et il y a une version orientée-objet de TCL, qui s’appelle OTcl.

2.5.1 Simulation des protocoles de routage

NS2 est un outil très puissant. Cependant qu’aujourd’hui, il a développé le version NS2 2.33, NS2 ne soutient complètement les réseaux sans fils surtout les protocoles de routage multicanaux, multi-interface. Pour le document [5], NS2 a soutenu les types de protocole de routage de réseau fils : le routage unicast, le routage multicast, le routage hiérarchique. Pour un type de protocole de routage, NS2 fournit les fonctions API pour soutenir les utilisateurs qui simulent facilement le réseau. De nos jours, NS2 a soutenu 4 protocoles de routage dans le réseau mobile : DSDV, AODV, TORA et DSR, mais le soutien est élémentaire. De plus, il a créé les fonctions API pour construire la topologie de réseau sans fils, le protocole MAC, le protocole TDMA.

2.5.2 Problèmes existants dans NS2

Cependant que NS2 a soutenu les méthodes pour les réseaux sans fils, mais il est plus petit dans le domaine des réseaux sans fils. Aujourd’hui, pour développent varié de technologies, NS2 doit soutenir de plus en plus mieux pour l’utilisateur peut simuler les réseaux mobiles. Maintenant, il y a quelques des problèmes existants dans l’outil NS2 :

NS2 ne soutient pas les réseaux multi-interface. Mais, dans le document [3]. , l’auteur a présenté une solution pour ajouter la capacité soutenue de réseau multi-interface. En

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

conséquence, l’utilisateur va implémenter et changer les codes dans les modules de NS2 (au langage C++ et au langage TCL). Il coûte beaucoup de temps pour reconstruire ces modules.

NS2 ne soutient pas les réseaux multicanaux. Je peux consulter le document [2]. pour comprendre l’algorithme de routage de réseaux multicanaux et pour créer les modules de NS2. Il coûte aussi les temps pour créer ces modules.

NS2 soutient la technologie 802.11. Il ne soutient pas les autres technologies comme :

Wimax, ZIGBEE, Bluetooth, … Pour simuler les protocoles de routage dans ces technologies, je dois reconstruire ou consulter les nouveaux module au langage C++ ou TCL. Il coûte beaucoup de temps pour créer ces modules.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Chapitre 3. Réalisation pratique

3.1 Objectif

L’objectif de cette partie sera donc de réaliser le réseau multi-interface dans le

document

des modules au langage C++ et Tcl. Pour construire le réseau multi-interface, je vais installer un protocole de routage comme : AODV et évaluer ces protocoles dans le réseau multi-interface. En suite, j’améliore le réseau multi-interface pour construire le réseau multicanaux. Alors je peux utiliser l’algorithme dans le document [2]. pour installer le réseau multi-interface multicanaux. Ensuite, s’il est possible, je vais améliorer le protocole de routage : AODV avec l’algorithme d’assignement de l’interface pour exécuter ce protocole dans le réseau multi-interface multicanaux

Ce réseau multi-interface est construire dans NS2 avec les changements

3.2 Construction

d'un

modèle

des

interfaces multicanaux

nœuds

3.2.1 Architecture d’un nœud mobile

mobiles

multi-

Un modèle des mobiles multi-interfaces, multicanaux, qui a dés caractères suivants :

Le nombre de canaux est modifiable

Le nombre de l'interface d'un nœud est variable

Chaque nœud peut connecter des canaux différents

L'héritage des opérations ns2 est garanti

3.2.2 Architecture original d’un nœud mobile NS2

Pour construire d'un modèle des nœuds mobiles multi-interfaces multicanaux, on doit modifier le modèle MobileNode existant dans NS2.

Comme le modèle original MobileNode de NS2, il ne soutient pas des nœuds mobiles multi-interfaces multicanaux. L'architecture d'un nœud mobile originale est le schéma suivant :

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 1 - Architecture originale d'un nœud mobile

Figure 1 - Architecture originale d'un nœud mobile dans NS2

Il y a quelques composants dans cette architecture :

Routing Agent ; router des paquets

protocoles de routage du réseau ad-hoc

à next-hop. Aujourd'hui, NS2 soutient 4

o

AODV Adhoc On-demand Distance Vector

o

DSDV Destination Sequenced Distance Vector Routing

o

DSR Dynamic Source Routing

o

TORA Temporally Ordered Routing Algorithm

Link Layer : Pour mettre l'adresse de destination MAC dans l'en-tete de paquet IP, on cherche l'adresse IP de nœud next-hop dans « Routing Agent » et la résolution l'adresse entre l'adresse MAC et ARP.

ARP Address Resolution Protocol Il reçoit des requêtes de « Link-Layer » pour résoudre l’adresse du matériel qui se réfère une table ARP. S’il est possible de trouver une adresse, il est décrit au en-tête de paquet MAC, Sinon, il y a requête ARP publié. Dans le cas de retrouver une adresse MAC, le paquet va s'insérer à la file d’interface.

Interface Queue (file d’interface)

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Donner la priorité des paquets dans protocole de routage.

MAC (Media Access Control) Traiter des paquets reçus ou envoyés à partir de « Link Layer ». Pour envoyer le paquet, il ajoute l’en-tête de MAC et transmet le paquet vers le canal.

Network Interface Comme une interface de matériel, pour accéder le canal.

Channel Simuler des effets de canal réel sans fils dans le signal transféré.

3.2.3 Nouvelle Architecture d’un nœud mobile

Si on construit des nœuds mobiles multi-interfaces multicanaux, on va construire une nouvelle architecture d’un nœud mobile. Voici le schéma de la nouvelle architecture d’un nœud mobile :

le schéma de la nouvelle architecture d’un nœud mobile : Figure 2 - Nouvelle architecture d’un

Figure 2 - Nouvelle architecture d’un nœud mobile dans NS2

La différence entre 2 architectures est que chaque nœud a des formes des couches de lien, ARP, files d’interface, MAC, interface du réseau et des entités de canal. Chaque forme représente une interface du réseau sans fils.

D’autre part, la nouvelle structure ne change pas le matériel IEEE 802.11. En conséquence, il est possible de simuler et d’implémenter la nouvelle architecture dans la réalité.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

3.2.4 Changement dans la source de code NS2

3.2.4.1 Changement du code OTCL

- D’abord, on ajoute 4 procédures dans le fichier ns -2.33/tcl/lib/ns -lib.tcl

Procédure change-numifs{ newnumifs} Permettre à l’utilisateur de spécifier le nombre d’interface newnumifs de chaque nœud. Cette procédure doit appeler avant de créer un nœud sans fils

Procédure get-numifs{} Trouver le nombre d’interface définie.

Procédure : add-channel {indexch ch}

Ajouter une interface (canal) d’un nœud. Dans cette procédure, il y a 2 arguments :

+ indexch : indice de canal ajouté

+ ch :se référer l’objet de canal créé.

Procédure ifNum{val} Ajouter la multi-interface comme un argument de procédure node-config pour changer la valeur locale de numifs_

- Ensuite, on change 2 procédures existantes dans le fichier ns -2.33/tcl/lib/ns -lib.tcl

Procédure node-config args{}

+ Ajouter le soutien de multi-canal

+ Utiliser la variable chan pour présenter la compatibilité arriéré. S’ il y a une

interface, chan est un variable single. S’il y a plus 2 interfaces, chan est une table

(array).

Procédure create-wireless-node{} Prendre le nombre d’interface défini numifs_ et appéler itérativement la procédure add-interface pour créer le nombre d’interface de chaque nœud.

De plus, on change des procédures existantes dans le fichier ns -2.33/tcl/lib/ns - mobilenode.tcl

Procédure add-interface {} Ajouter une interface dans un objet MobileNode. Elle va créer une table ARP de chaque interface.

Procédure add-target { agent port } Cette procédure attache une agent de routage à un objet MobileNode et attache ce agent à une port. En plus, cette procédure appelle get-numifs pour trouver le nombre d’interface utilisée.

Procédure add-target-rtagent { agent port } Cette procédure ajoute un cible (target) d’agent de routage.

Procédure init args{} Initialiser la table ARP d’objet MobileNode par le nombre d’interface défini.

Procédure reset{} Remettre la table ARP d’objet MobileNode par le nombre d’interface défini.

-

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

3.2.4.2 Changement du code C++

Changement de l’objet MobileMode : ns -2.33/common/mobilenode.h NS 2 utilise 2 listes de lien pour gérer le nombre de canal. prevX_ - référence de nœud précédent ; nextX_ - référence de nœud prochain. Primitivement, ces listes sont pointeurs aux nœuds. Pour changer ces liste, ces listes deviennent des tables de pointeur. comme : nextX_[MAX_CHANNELS], prevX_[MAX_CHANNELS]

Changement de ns -2.33/common/mobi lenode.cc Ajouter getLoc() pour retrouver la situation d’un nœud.

Changement de ns -2.33/mac/channel.cc Pour changer la liste de gestion dans l’objet MobileNode, on change l’accès de chaque nœud quand on attache, supprime ou met à jours un nouveau nœud à un canal correspondant un nombre de canal. On remplace de la commande this->index() par les commandes prevX_[this->index] , nextX_[this->index] . D’autre part, dans la fonction affectedNodes(), on ajoute une nouvelle condition pour vérifier que l’interface de nœud de destination soit connecté à le même canal avant la transfert de paquet entre cette interface et l’autre interface.

Changement de ns -2.33/mac/mac-802_11.cc On modifie la méthode recv() dans la classe MAC 802.11 pour s'enregistrer l’interface reçue MAC correcte dans l’en-tête MAC.

3.3 Changement

l’agent

nouveau modèle de multi-interfaces

de

routage

pour

s’adapter

le

3.3.1 Protocole AODV

Tout d’abord, on doit comprendre bien le processus d’exécution de l’agent de routage AODV dans NS2. Dans le protocole AODV, il y 2 processus : le découverte de route (Route Discovery) et l’entretien de route (Route Maintenance).

3.3.1.1 Processus de découverte de route

Voici un exemple de processus de découverte de route dans le protocole AODV :

processus de découverte de route dans le protocole AODV : Figure 3 - Processus de découverte

Figure 3 - Processus de découverte de route

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Si les nœuds dans le réseau ad-hoc sont créés, ensuite la fonction command() de librairie AODV est exécutée par chaque nœud. Quand la source demande une route à la destination, il diffuse un paquet RREQ par le fonction sendRequest(). Les nœuds intermédiaires reçoivent ce paquet pour mettre à jours leurs informations de source nœud et créer le un pointeur arrière au nœud de source dans leur table de routage. Ce paquet est transmit au nœud prochain par la fonction forward(). Quand un nœud reçoit ce paquet RREQ, ce qui est destination, ensuite ce nœud va transmettre un unicast de paquet RREP par la fonction sendReply() . Comme le RREP est propagé à la source de nœud, les nœud intermédiaires reçoit ce paquet RREP par la fonction recvReply() pour créer un pointeur à la nœud de destination , et ces nœuds intermédiaires va transmettre ce paquet par la fonction forward(). Enfin, le nœud de source reçoit ce paquet RREP, une route active est établie et il faut commencer à transférer des données par la fonction forward().

3.3.1.2 Processus de l’entretien de route

Voici un exemple de processus de l’entretien de route dans le protocole AODV :

sus de l’entretien de route dans le protocole AODV : Figure 4 - Processus de l’entretien

Figure 4 - Processus de l’entretien de route

Ce processus a pour but de mettre à jours les routes établies. Parfois, une route d’un nœud offre la connectivité des informations par la fonction sendHello() pour diffuser des messages Hello. Chaque fois qu'un nœud reçoit un message Hello d'un voisin via recvHello(), le nœud fait en sorte qu'il y a une route de voisin et en créant une route s’il est nécessaire. Le nœud courant peut commencer à utiliser cette route pour transmettre des paquets. En outre, lorsque la rupture d'un lien est détectée par un nœud, ce nœud va appeler sendError() pour notifier au nœud de source avec la paquet Route Error(RERR). Ensuite le nœud de source initialise un nouveau processus de découverte de route.

3.3.2 Changement de code C++ pour créer un nouveau modèle en s’adaptant le modèle multicanaux multi-interfaces

Selon l’originale structure de nœud mobile, on a utilisé les variables : targetlist et ifqueue. Dans cette nouvelle structure, on utilise 2 tables : targetlist qui stocke des modules

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

LL (Link-Layer) de toutes les interfaces d’un nœud, et ifqueuelist qui stocke des files d’attente correspondantes. Alors, j’ai choisit l’agent de routage AODV pour implémenter le modèle des nœuds multi-interfaces.

D’abord, on déclare des variables dans le fichier aodv.h pour gérer le nombre maximal d’interface d’un nœud, des modules LL et des files d’attents :

//TPE: Gerer l'interface multiple #define MAX_IF 12 // le nombre d'interface d'un noeud //TPE: le variable de nombre d'interface int nIfaces; //le nombre d'interface

//TPE: File d'attent stocke le module LL pour chaque interface NsObject *targetlist[MAX_IF]; //TPE: Stoker les files d'attent de toutes interfaces PriQueue *ifqueuelist[MAX_IF];

Ensuite, on modifie la méthode command de classe AODV dans le fichier aodv.cc pour initialiser des valeurs de Tclscript comme : if-queue, target

 

//TPE: le methode "command" de classe agent routage else if(argc == 4) { if (strcmp(argv[1],"if-queue") == 0){ PriQueue *ifq = (PriQueue *) TclObject::lookup(argv[3]); int temp_ = atoi(argv[2]); if (temp_== nIfaces){ nIfaces++;

 

}

ifqueuelist[temp_] = ifq;

if (ifqueuelist[temp_]){ return TCL_OK;

}

else { return TCL_ERROR;

 

}

 

}

if (strcmp(argv[1],"target") == 0){

 

int temp_ = atoi(argv[2]); if (temp_== nIfaces){ nIfaces++;

}

targetlist[temp_] = (NsObject *) TclObject::lookup(argv[3]);

if (targetlist[temp_]){ return TCL_OK;

}

else { return TCL_ERROR;

 

}

 

}

 

}

return Agent::command(argc, argv);

}

De plus, un nœud doit décider une interface qui transfère chaque paquet. C’est pourquoi, on utilise une transmission diffusée (comme dans le processus Route Discovery ). Si il y des plus 2 interfaces disponibles, on doit transférer un paquet diffusé aux toutes interface de ce nœud. Dans cet agent de routage AODV, on change 4 méthodes : sendRequest, sendError, sendHello, forward. Voici le code de changement suivant :

//method sendRequest //Scheduler::instance().schedule(target_, p, 0.); //TPE1 : Envoyer un paquet de difussion if (nIfaces) {

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

for (int i = 0; i < nIfaces; i++) { Packet *p_copy = p->copy(); Scheduler::instance().schedule(targetlist[i], p_copy, 0.); printf("n%d\tsendRequest - broadcast\n\n", (int)index);

}

Packet::free((Packet *)p); } else {

Scheduler::instance().schedule(target_, p, 0.);

}

}

//methode sendError if (jitter) {

// TPE: Envpyer un paquet de diffusion if (nIfaces) { for (int i = 0; i < nIfaces; i++) { Packet *p_copy = p->copy(); Scheduler::instance().schedule(targetlist[i], p_copy,

0.01*Random::uniform());

printf("n%d\tsendError - broadcast (jitter)\n\n",

(int)index);

}

Packet::free((Packet *)p); } else { Scheduler::instance().schedule(target_, p,

0.01*Random::uniform());

}

} else { //TPE : Envoyer un paquet de diffusion if (nIfaces) { for (int i = 0; i < nIfaces; i++) { Packet *p_copy = p->copy(); Scheduler::instance().schedule(targetlist[i], p_copy, 0.0); printf("n%d\tsendError - broadcast (else)\n\n", (int)index);

}

Packet::free((Packet *)p); } else { Scheduler::instance().schedule(target_, p, 0.0);

}

}

}

//methode sendHello //Scheduler::instance().schedule(target_, p, 0.0); //TPE : Envoyer un paquet de diffusion if (nIfaces) { for (int i = 0; i < nIfaces; i++) { Packet *p_copy = p->copy(); Scheduler::instance().schedule(targetlist[i], p_copy, 0.0); printf("n%d\tsendHello - broadcast\n\n", (int)index);

}

Packet::free((Packet *)p);

} else { Scheduler::instance().schedule(target_, p, 0.0);

}

}

//methode forward if (ih->daddr() == (nsaddr_t) IP_BROADCAST) { assert(rt == 0); //TPE: envoyer un paquet de diffusion

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

if (nIfaces) { for (int i = 0; i < nIfaces; i++) { Packet *p_copy = p->copy(); Scheduler::instance().schedule(targetlist[i], p_copy,

0.01*Random::uniform());

printf("n%d\tforward - broadcast\n\n", (int)index);//debug

}

Packet::free((Packet *)p); }else { Scheduler::instance().schedule(target_, p , 0.01 * Random::uniform());

}

}

En plus, quand un paquet de routage à une interface de destination, on doit une transmission unicast pour connaitre cette interface. C’est pourquoi, on stocke les informations d’interface en sortie pour arriver à next hop. Dans ce cas, on ajoute un variable rt_interface dans le fichier aodv_rtable.h pour stocker l’indice d’interface appropriée. Et le processus de transmission unicast va utiliser rt_interface pour choisir une entrée de targetlist. Le processus unicast est utilisé dans 2 méthodes sendReply et forward :

//fichier aodv_rtable.h // TPE: indice d'interface pour router paquets int rt_interface;

//fichier aodv.cc //methode forward // Not a broadcast packet if(delay > 0.0) { if (nIfaces) { printf("n%d\tforward - rt->rt_interface (delay > 0): %d\n\n", (int)index, rt->rt_interface); Scheduler::instance().schedule(targetlist[rt->rt_interface], p,

delay);

} else { Scheduler::instance().schedule(target_, p, delay);

}

}

//Scheduler::instance().schedule(target_, p, delay); //} else { // Not a broadcast packet, no delay, send immediately // Scheduler::instance().schedule(target_, p, 0.); //TPE: Envoyer un paquet unicast if (nIfaces) { printf("n%d\tforward - rt->rt_interface (else): %d\n\n", (int)index,rt->rt_interface); Scheduler::instance().schedule(targetlist[rt->rt_interface], p,

0);

//Scheduler::instance().schedule(targetlist[Iface], pkt, 0); } else { Scheduler::instance().schedule(target_, p, 0);

}

}

}

}

//methode sendReply //TPE : Envoyer un paquet unicast if (nIfaces) {

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

printf("n%d\tsendReply - rt->rt_interface (unicast): %d\n\n", (int)index, rt->rt_interface);

Scheduler::instance().schedule(targetlist[rt->rt_interface], p, 0.); } else { Scheduler::instance().schedule(target_, p, 0.);

}

}

Pour trouver la valeur rt_interface, on utilise l’adresse d’interface entrante qui est un membre de en-tête de paquet commun. Dans ce cas, on trouve la valeur rt_interface dans 2 méthodes recvRequet et recvReply :

//methode recvRequest // TPE : Trouver l'en-tete commun de paquet struct hdr_cmn *ch = HDR_CMN(p);

//TPE : trouver l'indice de l'interface entrante if (nIfaces) { printf("n%d\trecvRequest - ch->iface() (rt0 = 0): %d\n", (int)index, ch->iface()); printf("n%d\trecvRequest - ((Mac *)ifqueuelist[0]->target())- >addr() (rt0 = 0): %d\n", (int)index, ((Mac *)ifqueuelist[0]->target())- >addr());

rt0->rt_interface = ch->iface()-((Mac *)ifqueuelist[0]- >target())->addr(); } else { rt0->rt_interface = -1;

}

printf("n%d\trecvRequest - rt0->rt_interface (rt0 = 0): %d\n\n", (int)index, rt0->rt_interface);

}

//method recvReply // TPE : Trouver l'en-tete commun de paquet struct hdr_cmn *ch = HDR_CMN(p);

if(rt == 0) { rt = rtable.rt_add(rp->rp_dst);

//TPE: Trouver l'indice de l'interface if (nIfaces) { printf("n%d\trecvReply - ch->iface() (rt = 0): %d\n", (int)index, ch->iface()); printf("n%d\trecvReply - ((Mac *)ifqueuelist[0]->target())- >addr() (rt = 0):%d\n", (int)index, ((Mac *)ifqueuelist[0]->target())- >addr());

rt->rt_interface = ch->iface()-((Mac *)ifqueuelist[0]- >target())->addr(); } else {

rt->rt_interface = -1;

}

printf("n%d\trecvReply - rt->rt_interface (rt = 0): %d\n\n", (int)index,

rt->rt_interface);

}

3.4 Protocole de routage dans le modèle multicanaux multi- interfaces MCR

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Dans l’article [2]. , Pradeep Kyasanur, Nitin H. Vaidya ont proposé une approche général de routage et d’assignement de l’interface dans le réseau ad-hoc sans fil multicanaux muti-interfaces.

Une solution de modèle multicanaux est basée sur les matériels existants IEEE 802.11

Une stratégie d’assignement de l’interface avec l’algorithme de commutation d’interface pour utiliser les interfaces et les canaux disponibles.

Un protocole de routage MCR (Multiple-Channel Routing) pour améliorer le débit avec l’évaluation de la diversité de l’interface et le coût de commutation d’interface. Dans ce TPE, on implémente le modèle multicanaux multi-interface qui s’adapte les matériels existants IEEE 802.11. Ensuite, pour améliorer le débit de modèle multicanaux multi-interface, on peut installer la stratégie d’assignement de l’interface avec l’algorithme de commutation d’interface sur un protocole de routage existant comme AODV. Enfin, il est difficile d’implémenter le protocole MCR dans NS2, parce que dans cet article, les auteurs utilisent le simulateur Qualnet en version 3.6 [30]. En conséquence, il y a des différences entre le simulateur Qualnet et le simulateur NS2.

3.4.1 Stratégie de l’assignement d’interface

3.4.1.1 Interface fixe et commutable

Dans cet article, les auteurs a défini 2 concepts : l’interface fixe et l’interface commutable. On suppose que chaque nœud a des M interfaces disponibles et ces interface sont divisée en 2 groupes :

L’interface fixe : Quelques K des M interfaces de chaque nœud sont affectés dans les longs intervalles de temps aux certains canaux K. Les canaux correspondants sont considérés comme des canaux fixes. Ces interfaces fixes sont utilisées pour recevoir des données et sont commutables sur la base du nombre de nœuds d'un canal.

L’interface commutable : Les (M - K) interfaces sont assignées de façon dynamique à un des autres canaux (M - K) sur les échelles de temps court qui basées sur le trafic de données. Les canaux correspondants s’appellent les canaux commutables. Une interface commutable permet le nœud X de transmettre à nœud Y dans leurs voisins par la commutation au canal fixe du nœud Y. La valeur de M et K est différente dans chaque nœud. Par exemple, il y a un scénario avec M = 2 et K = 1 pour tous les nœuds (c’est-à-dire une interface fixe et une interface commutable) et il y a 3 canaux non-chevauchements. Dans ce scénario de l’étape 1, les nœuds A, B, C ont des interfaces correspondantes sur le canal 1, 2, 3. De plus, on suppose qu’il y a une route : A BC, ça-veut-dire le nœud A veut transférer des données au nœud C. Dans l’étape 2, le nœud A commute l’interface commutable de 3 à 2 avant de transférer des données au nœud 2, parce que l’interface fixe de nœud B est 2. De même, dans l’étape prochaine, nœud B commute son interface commutable de 1 à 3, parce que l’interface fixe de nœud C est 3. En conséquence, il y a une interface appropriée qui crée dans un flux d’initiation et les flux postérieurs ne doivent pas commuter les autres interfaces dans le long temps.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 5 - Commutation de l’ interface avec

Figure 5 - Commutation de l’interface avec 3 canaux et 2 interfaces

En général, si le nœud X transfère au nœud Y sur le canal a, l’interface commutable de X est commuté au canal a pour transférer au nœud Y. Et si l’interface commutable de X est canal a, il n’y a pas de la commutation de l’interface. C’est-à-dire l’expéditeur s’adapte le récepteur par la commutation de l’interface commutable qui égale l’interface fixe de récepteur.

3.4.1.2 Assignement de l’interface fixe

L’assignement de l’interface fixe a pour but d’sélectionner le canal qui est assigné à une interface fixe et d’informer les nœuds de voisin que le canal qui est utilisé par cette interface.

Chaque nœud stocke 2 tables :

o

La table de voisin (NeighbourTable) : contient les canaux fixes qui sont utilisé par ses voisins.

o

La liste de canaux d’usage (ChannelUsageList): stocke les nombre de nœuds de chaque canal fixe (mais il y a seulement des nœuds dans la rangée de communication.

Etape 1 : Chaque nœud choisit un canal aléatoire pour l’interface fixe

Etape 2 : Périodiquement, chaque nœud diffuse un paquet Hello ou Request (Route Discovery) sur tous les canaux qui contiennent les canaux fixes qui sont utilisé par sa table de voisin. On peut utiliser les protocoles comme AODV qui diffusent ces paquet Hellp ou Request (Route Discovery).

Etape 3 : Si le nœud reçoit le paquet Hello ou Request(Discovery) à partir de voisin, ce nœud va mettre à jours :

o

La table de voisin : le canal fixe de son voisin

o

La liste de canaux d’usage utilise sa table de voisin, par conséquent la liste de canaux d’usage contient les informations d’usage 2 hops

Etape 4 : Chaque nœud consulte périodiquement sa liste de canaux d’usage. Le temps périodique est le temps maximal de transmission d’un paquet.

o Si le nombre d’autre nœud qui utilise le même canal fixe est grand, il y a une probabilité p pour le nœud change le canal fixe. Ensuite le nœud transmit un paquet Hello ou Request pour informer ses voisin sur le nouveau canal utilisé.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

o D’autre part, dans ce cas, la valeur de probabilité p qui égale 0.5 par une fonction aléatoire.

3.4.1.3 Assignement de l’interface commutable

L’interface commutable est utilisé de transférer des données à partir de nœud X, dès que le canal fixe de destination est différent à partir de canal fixe de nœud X. Chaque nœud maintient une file de paquet pour chaque canal comme le schéma suivant :

file de paquet pour chaque canal comme le schéma suivant : Figure 6 - File de

Figure 6 - File de paquet de chaque canal

Etape 1 : Si un paquet unicast est reçu dans la couche de lien de donnée (Data Link Layer) :

o

Le nœud cherche le canal fixe de destination de paquet dans la table de voisin. Si l’expéditeur a le même canal fixe de récepteur, il faut stocker le paquet au canal fixe. Si non, il faut stocker au le canal commutable

o

Pour diffuser un paquet, le nœud copie et donne ce paquet à la file de chaque canal. Le paquet est envoyé quand le canal commence à transférer des données

Etape 2 : L’interface commutable change le canal s’il y a des paquets dans la file pour l’autre canal

3.4.2 Changement

du

code

C++

commutation de l’interface

3.4.2.1 Fichier /ns-2.33/aodv/aodv.h

pour

l’implémentation

Ajouter les nouveaux variables de classe AODV

de

#define MAX_ENT_NT 20 // le nombre maximal de entry dans le table de voisin #define MAX_ENT_CUL 20 // le nombre maximal de entry dans la liste de canaux utilises

//TPE : Stoker les canaux fix qui sont utilise pas les voisin int tbl_neighbour[MAX_ENT_NT]; //TPE2 : Stoker le nombre de noeuds qui est utilise dans un canal int ls_channel_usage[MAX_ENT_CUL]; //TPE2 : l'interface fixed et switchable int interface_fixed;

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

int interface_switchable;

3.4.2.2 Fichier /ns2.33/aodv/aodv_packet.h

On change l’entête de paquet de AODV, on ajoute les variables dans le message hdr_aodv_request pour le RREQ et hdr_aodv_reply pour le RREP et Hello

// hdr_aodv_reply //TPE : Implemeter les informations de multi-interface, multicanaux int rp_fixed_channel_used; //l'indice de canal fixed de ce noeud nsaddr_t rp_sender_node_ip; //IP de noeud d'emmeteur int *rp_neighbour_table; //Table de voisin de ce nœud

//hdr_aodv_request //TPE : Implemeter les informations de multi-interface, multicanaux int rq_fixed_channel_used; //l'indice de canal fixed de ce noeud nsaddr_t rq_sender_node_ip; //IP de noeud d'emmeteur int *rq_neighbour_table; //Table de voisin de ce noeud

3.4.2.3 Fichier /ns-2.33/aodv/aodv.cc

Méthode command() :

Le nœud choisit un canal aléatoire pour son interface fixe et son interface commutable

//TPE : Initial de methode MCR //Choisir une interface fixed et une interface switchable interface_fixed = rand() % (temp_+1); if (nIfaces > 1){ do{ interface_switchable = rand() % (temp_+1); } while (interface_switchable == interface_fixed); } //end nIfaces

On doit mettre à jour le canal fixe dans le table de voisin et la liste de canaux

d’usage

//TPE : Ajouter l'interface fixed dans le table de voisin int fixed_channel = ((Mac *)ifqueuelist[interface_fixed]->target())- >netif()->channel()->index(); tbl_neighbour[(int)index] = fixed_channel; ls_channel_usage[fixed_channel]++;

Méthode sendRequest(), sendReply(), sendHello()

//sendRequest //TPE2: Ajouter le canal fixed de ce noeud au packet rq->rq_fixed_channel_used = tbl_neighbour[(int)index]; rq->rq_sender_node_ip = (int)index; rq->rq_neighbour_table = &tbl_neighbour[0];

//sendReply //TPE2: Ajouter le canal fixed de ce noeud au packet rp->rp_fixed_channel_used = tbl_neighbour[(int)index]; rp->rp_sender_node_ip = (int)index; rp->rp_neighbour_table = &tbl_neighbour[0];

//sendHello //TPE2: Ajouter le canal fixed de ce noeud au packet hello rh->rp_fixed_channel_used = tbl_neighbour[(int)index]; rh->rp_sender_node_ip = (int)index; rh->rp_neighbour_table = &tbl_neighbour[0];

Méthode recvRequest(), recvReply(), recvHello()

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

//recvRequest() //Quand recevoir un paquet RREQ d'un voisin , il faut mettre a jour le table de voisin tbl_neighbour[(int)(rq->rq_sender_node_ip)]= rq->rq_fixed_channel_used; //Mettre a jour la liste de canaux usage for (int i = 0; i < MAX_ENT_CUL; i++){ if (i==(int)index){ continue;//eviter le cas de repetition

}

if (rq->rq_neighbour_table[i] != -1 ){ ls_channel_usage[rq->rq_neighbour_table[i]]++;

}

}

//recvReply() //Quand recevoir un paquet RREP d'un voisin , il faut mettre a jour le table de voisin tbl_neighbour[(int)(rp->rp_sender_node_ip)]= rp->rp_fixed_channel_used; //Mettre a jour la liste de canaux usage for (int i = 0; i < MAX_ENT_CUL; i++){ if (i==(int)index){ continue;//eviter le cas de repetition

}

if (rp->rp_neighbour_table[i] != -1 ){ ls_channel_usage[rp->rp_neighbour_table[i]]++;

}

}

//recvHello //Quand recevoir un paquet HELLO d'un voisin , il faut mettre a jour le table de voisin tbl_neighbour[(int)(rq->rq_sender_node_ip)]= rq->rq_fixed_channel_used; //Mettre a jour la liste de canaux usage for (int i = 0; i < MAX_ENT_CUL; i++){ if ((rp->rp_neighbour_table[i] == -1)||(i==(int)index||(tbl_neighbour[i] == rp->rp_neighbour_table[i]))){ continue;//eviter le cas de repetition } else if(tbl_neighbour[i] != rp->rp_neighbour_table[i]){ //si l'interface fixed et l'information mis a jour sont differente, //on doit mettre a jour la liste de canaux if (ls_channel_usage[tbl_neighbour[i]]>0){ ls_channel_usage[tbl_neighbour[i]]--;

}

ls_channel_usage[rp->rp_neighbour_table[i]]++; } else {

ls_channel_usage[rp->rp_neighbour_table[i]]++;

}

}// end for tbl_neighbour[(int)(rp->rp_sender_node_ip)] = rp->rp_fixed_channel_used;

Méthode forward()

Le programme traite le paquet reçu (RREQ, RREP et Hello) et ajoute le canal fixe dans sa table de voisin

//TPE2: Dans le cas, Expediter le paquet RREQ if(rq->rq_type == AODVTYPE_RREQ){ rq->rq_fixed_channel_used = tbl_neighbour[(int)index]; rq->rq_sender_node_ip = (int)index; rq->rq_neighbour_table = &tbl_neighbour[0];

}

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

//TPE2: Dans le cas, Expediter le paquet RREP if(rp->rp_type == AODVTYPE_RREP){ rp->rp_fixed_channel_used = tbl_neighbour[(int)index]; rp->rp_sender_node_ip = (int)index; rp->rp_neighbour_table = &tbl_neighbour[0];

}

//TPE2: Dans le cas, Expediter le paquet des donnees

if(rp->rp_type == 0 && rq->rq_type == 0){ int channel_usage_highest = 0; int channel_usage_lowest = 0; bool found = false; static int flag = 0; //TPE2 : Trouver le canal qui est utilise maximal for (int i=0; i < nIfaces; i++){ if (ls_channel_usage[i] == 0){ channel_usage_lowest = i; continue;

} //end == 0 if (ls_channel_usage[i] >= ls_channel_usage[channel_usage_highest]){ channel_usage_highest = i; found = true;

} //end > highest if (ls_channel_usage[i] <= ls_channel_usage[channel_usage_lowest]){ channel_usage_lowest = i;

} //end < lowest } //end for

}

Ensuite, si le nombre de canal fixe est grand, on choisit la probabilité 0.5 pour changer le canal fixe. De plus, le nœud va transférer un message Hello pour informer ses voisin sur le nouveau canal fixe.

if (found && !flag ){ if(ls_channel_usage[tbl_neighbour[(int)index]] == ls_channel_usage[channel_usage_highest]){ int probability_switch = rand() % 101; //la probabilite switchable if (probability_switch < 50){ //Si condition de changement = true, on doit changer la liste de cannaux

int channel_fixed = ((Mac *)ifqueuelist[interface_fixed]- >target())->netif()->channel()->index(); ls_channel_usage[channel_fixed]--;

//Choisir un nouveau cannal = canal minimal channel_fixed = channel_usage_lowest; ls_channel_usage[channel_fixed]++; tbl_neighbour[(int)index] = channel_fixed; for (int i = 0; i<nIfaces; i++){ if ( ((Mac *)ifqueuelist[i]->target())->netif()- >channel()->index() == channel_fixed){ interface_fixed = i; break; } //end if Mac }//end for sendHello(); }//end probability

Enfin, le nœud cherche le canal fixe dans la table de voisin pour assigner ce canal fixe au canal commutable

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

int channel_switch = tbl_neighbour[(int)(rt->rt_nexthop)]; for (int i = 0; i< MAX_IF; i++ ){ if ( (((Mac *)ifqueuelist[i]->target())->netif()->channel()- >index())==channel_switch ){ interface_switchable = i; break;

}

} // end for MAX_IF

3.5 Table de changement de code

Voice le table de changement de code

Nombre

La liste de fichier

1

/ns-2.33/aodv/aodv.h

/ns-2.33/aodv/aodv.c

/ns-2.33/aodv/aodv_rtable.h

/ns-2.33/aodv/aodv_paquet.h

2

/ns-2.33/common/mobilenode.h

/ns-2.33/common/mobilenode.cc

3

/ns-2.33/mac/channel.cc

/ns-2.33/mac/mac.h

/ns-2.33/mac/mac-802_11.cc

4

/ns2-33/tcl/lib/ns-lib.tcl

/ns2-33/tcl/ns-mobile.tcl

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Chapitre 4. Expérimentation

4.1 Test de scénario de modèle des nœuds multi-interfaces

4.1.1 Topologie du réseau

On crée 3 nœuds avec la spécification suivant :

Nœud 0 a 2 interfaces : Interface 0 opère la fréquence 2.14 Ghz et Interface 1 opère la fréquence 914 Mb.

Nœud 1 a 1 interface qui opère la fréquence 914 MHz

Nœud 2 a 1 interface qui opère la fréquence 2.14 GHz

 Nœud 2 a 1 interface qui opère la fréquence 2.14 GHz Figure 7 - Topologie

Figure 7 - Topologie de modèle des nœuds multi-interfaces (scénario 1)

4.1.2 Contenu de scénario

On utilise 1 transmission TCP entre le nœud 0 et nœud 1 à partir de deuxième seconde. (2)

On utilise 1 transmission TCP entre le nœud 0 et nœud 2 à partir de douzième secondes (12)

4.1.3 Résultat :

Voici le résultat de débit de nœud 1 et de nœud 2 :

: Voici le résultat de débit de nœud 1 et de nœud 2 : Figure 8

Figure 8 - Résultat de scénario 1

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

- Ligne rouge : débit de nœud 1

- Ligne vert : débit de nœud 2

Pour le résultat, le débit de nœud 1 n’influence pas sur le débit de nœud 2. Parce que le nœud 0 transfère des données à la fréquence 914 MHz avec l’interface 0 de nœud 0 ; et le

nœud 1 transfère des données à la fréquence 214 GHz avec l’interface 0 de nœud 0

4.2 Test de scénario de routage de modèle des nœuds multi- interfaces

4.2.1 Topologie du réseau

On crée 3 nœuds avec la spécification suivant :

Nœud 0 a 2 interfaces : Interface 0 opère la fréquence 2.14 Ghz et Interface 1 opère la fréquence 914 MHz.

Nœud 1 a 1 interface qui opère la fréquence 914 MHz

Nœud 2 a 1 interface qui opère la fréquence 2.14 GHz

N œud 2 a 1 interface qui opère la fréquence 2.14 GHz 4.2.2 Contenu de scénario

4.2.2 Contenu de scénario

Figure 9 - Topologie de scénario 2

On utilise 1 transmission TCP entre le nœud 2 et nœud 1 à partir de deuxième seconde. (2)

La source est le nœud 2

La destination est le nœud 1

Le nœud 0 est intermédiaire pour transférer directement des données au nœud 1 et au nœud 2

4.2.3 Résultat

Voici le résultat des débits

Débit de nœud immédiate 0 :

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 10 - Débit de nœud 0 -

Figure 10 - Débit de nœud 0

- Ligne rouge : débit de nœud 0

Débit de destination du nœud 1:

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 11 - Débit de nœud 0 et

Figure 11 - Débit de nœud 0 et nœud

- Ligne rouge : débit de nœud 1

- Ligne vert : débit de nœud 0

Pour le résultat, on a transféré des données entre le nœud 1 et le nœud 2. Le nœud 0 est un rôle de nœud intermédiaire pour transférer des données du nœud 2 à nœud 1. C’est pourquoi, le nœud 1 ne connecte pas directement le nœud 2. Parce que le nœud 1 a une interface qui opère la fréquence 914 MHz, le nœud 2 a 1 interface qui opère la fréquence 2.14 GHz et la distance entre le nœud 1 et nœud 2 est 350, cette distance n’utilise pas de connecter directement dans la norme 802.11a/b

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

4.3 Deux scénarios de transmission de même fréquence

4.3.1 Scénario 1 de transmission de même fréquence

4.3.1.1 Topologie du réseau

On crée 4 nœuds avec la spécification suivant :

Nœud 0 a 1 interface qui opère la fréquence 914 MHz.

Nœud 1 a 1 interface qui opère la fréquence 914 MHz.

Nœud 2 a 1 interface qui opère la fréquence 914 MHz.

Nœud 3 a 1 interface qui opère la fréquence 914 MHz.

Nœud 3 a 1 interface qui opère la fréquence 914 MHz. Figure 12 - Topologie de

Figure 12 - Topologie de scénario 1 de même fréquence

4.3.1.2 Contenu de scénario

On utilise 1 transmission TCP entre le nœud 0 et nœud 1 à partir de deuxième seconde (2). Ensuite, on choisit le canal 0 et la fréquence 914 Mhz.

o

La source est le nœud 0

o

La destination est le nœud 1

On utilise 1 transmission TCP entre le nœud 2 et nœud 3 à partir de cinquième seconde (5). Ensuite, on choisit le canal 1 et la fréquence 914 Mhz.

o

La source est le nœud 2

o

La destination est le nœud 3

4.3.1.3 Résultat

Voici le résultat des débits

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 13 - Débit de 2 connexion -

Figure 13 - Débit de 2 connexion

- Ligne rouge : débit de nœud 1

- Ligne vert

: débit de nœud 3

Dans cette expérience, on utilise la structure originale de nœud NS2 avec la même fréquence 914 MHz. De plus, le débit d’aucune connexion n’influence pas d’autre connexion. Parce que chaque connexion utilise un canal différent et je pense que la structure de nœud NS2 utilise une bande de fréquence autour de 914 MHz. En plus, la structure NS2 et la standard 802.11 utilisent les canaux orthogonaux. En conséquence, ces 2 canaux n’ont pas l’interférence et le débit entre 2 canaux est approximatif.

4.3.2 Scénario 2 de transmission de même fréquence

4.3.2.1 Topologie du réseau

On crée 3 nœuds avec la spécification suivant :

Nœud 0 a 2 interfaces : Interface 0 opère la fréquence 914 MHz et Interface 1 opère la fréquence 914 MHz.

Nœud 1 a 1 interface qui opère la fréquence 914 MHz

Nœud 2 a 1 interface qui opère la fréquence 914 MHz

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 14 - Topologie de scénario 2 de

Figure 14 - Topologie de scénario 2 de transmission de même fréquence

4.3.2.2 Contenu de scénario

On utilise 1 transmission TCP entre le nœud 2 et nœud 1 à partir de deuxième seconde. (2)

La source est le nœud 2

La destination est le nœud 1

Le nœud 0 est intermédiaire pour transférer directement des données au nœud 1 et au nœud 2

4.3.2.3 Résultat

Voici le résultat des débits

au nœud 2 4.3.2.3 Résultat Voici le résultat des débits Figure 15 - Débit de nœud

Figure 15 - Débit de nœud 0 et nœud 1

- Ligne rouge : débit de nœud 1

- Ligne vert : débit de nœud 0

Dans cette expérience, on a transféré des données entre le nœud 1 et le nœud 2. Le nœud 0 est un rôle de nœud intermédiaire pour transférer des données du nœud 2 à nœud 1. C’est pourquoi, le nœud 1 ne connecte pas directement le nœud 2. Parce

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

que le nœud 1 utilise la fréquence 914 MHz, le nœud 2 utilise aussi la fréquence 914 MHz et la distance entre le nœud 1 et nœud 2 est 350m.

Mais le débit de nœud 0 et nœud 1 ne change pas la valeur. Parce que, on utilise 2 interfaces et 2 canaux différents pour transférer des données. De plus, la structure NS 2 peut utiliser 2 canaux orthogonaux. Par conséquent, on obtient ce résultat.

4.4 Deux scénario de distance

4.4.1 Scénario 1 de distance

4.4.1.1 Topologie du réseau

On crée n nœuds avec la spécification suivant :

Chaque nœud a des 2 interfaces : Interface 0 opère la fréquence 914 MHz et Interface 1 opère la fréquence 914 MHz.

La distance entre 2 nœuds est 200 m.

914 MHz.  La distance entre 2 nœuds est 200 m. Figure 16 - Topologie de

Figure 16 - Topologie de scénario 1 de distance

4.4.1.2 Contenu de scénario

On utilise 1 transmission d’une application CBR entre le nœud 0 et nœud 1 à partir de première seconde. (1)

La source est le nœud 0

La destination est le nœud n

Le nœud i ( i = 1->n-1 )est intermédiaire pour transférer directement des données au nœud 0 et au nœud n

4.4.1.3 Résultat

Voici le résultat des débits

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 17 - Débit de nœud n Dans

Figure 17 - Débit de nœud n

Dans cette expérimentation, le débit de modèle original est petit que les autres cas. En conséquence, le nouveau modèle est meilleur que le modèle original.

4.4.2 Scénario 2 de distance

4.4.2.1 Topologie du réseau

On crée n nœuds avec la spécification suivant :

Chaque nœud a 2 interfaces : Interface 0 opère la fréquence 914 MHz et Interface 1 opère la fréquence 914 MHz.

La distance entre 2 nœuds est 20 m.

914 MHz.  La distance entre 2 nœuds est 20 m. Figure 18 - Topologie de

Figure 18 - Topologie de scénario 2 de distance

4.4.2.2 Contenu de scénario

On utilise 1 transmission d’une application CBR entre le nœud 0 et nœud 1 à partir de première seconde. (1)

La source est le nœud 0

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

La destination est le nœud n

Le nœud i ( i = 1->n-1 )est intermédiaire pour transférer directement des données au nœud 0 et au nœud n

4.4.2.3

Résultat

Voici le résultat des débits

au nœud n 4.4.2.3 Résultat Voici le résultat des débits Figure 19 - Débit de nœud

Figure 19 - Débit de nœud n

Dans cette expérience, le débit entre le nœud 0 et le nœud n est grand (800 Kbps). C’est pourquoi, la distance entre le nœud 0 et nœud n (maximal n = 10) = 20 * 10 = 200 m. En conséquence, la transmission entre le nœud 0 et le nœud n est directe.

4.5 Scénario l’interface

4.5.1 Topologie du réseau

d’implémentation

de

commutation

de

On crée n nœuds avec la spécification suivant :

Chaque nœud a des 2 interfaces : Interface 0 opère la fréquence 914 MHz et Interface 1 opère la fréquence 914 MHz.

La distance entre 2 nœuds est 200 m.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Protocoles de routage dans les réseaux multi-radios mobiles Figure 20 - Topologie de scénario 1 de

Figure 20 - Topologie de scénario 1 de distance

4.5.2 Contenu de scénario

On utilise 1 transmission d’une application CBR entre le nœud 0 et nœud 1 à partir de première seconde. (1)

La source est le nœud 0

La destination est le nœud n

Le nœud i ( i = 1->n-1 )est intermédiaire pour transférer directement des données au nœud 0 et au nœud n

4.5.3 Résultat

Voici le résultat des débits

et au nœud n 4.5.3 Résultat Voici le résultat des débits Figure 21 - Débit de

Figure 21 - Débit de nœud n

Dans cette expérimentation, le débit de modèle original est petit que les autres cas. En conséquence, le nouveau modèle est meilleur que le modèle original.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Chapitre 5. Conclusions et perspectives

5.1 Conclusion

Dans ce TPE, j’ai déjà terminé les tâches suivant :

Compléter la partie théorique, ce sont de

o

Etudier tous les technologies de communication sans fils dans les réseaux informatiques

Wifi (802.11 a/b/g/ draft n)

 

Wimax (802.16d fixable/ 802.16e mobile)

 

ZegBee(802.15.4-WPAN : Wireless Personal Area Network)

Bluetooth (WPAN)

 

o

Etudier les protocoles principaux de routage dans les réseaux ad hoc, les

protocoles de routage multi-radio :

 

AODV (réactif)

 

DSR (réactif)

DSDV (proactif)

o

Etudier

le

simulateur

NS2 (The Network Simulator) et les moyens

disponibles comme le langage TCL, C++ … pour faire de simuler des

protocoles du routage pour les réseaux sans fils, les différents technologies de communication radio.

o

Etudier

l’état

de

l’art

sur les

protocoles

de routage multi-radio

(multifréquence, multicanaux, etc.). En conséquence, il faut donner les avantages et les inconvénients de ces protocoles.

Compléter la réalisation pratique, ce sont de :

o

J’ai déjà construit le modèle de nœuds multi-interfaces, multicanaux pour exécuter les scénarios dans le simulateur NS2

o

Ensuite, j’ai modifié le protocole AODV pour s’adapter le nouveau modèle multi-interfaces, multicanaux

o

De plus, j’ai implémenté l’algorithme d’assignement de l’interface de protocole MCR [2]. sur le protocole NS2.

o

Après de tester les scénarios différents, on montre que le nouveau modèle multi-interfaces multicanaux a des avantages comme le débit, la latence dans le réseau sans fil, surtout le réseau Ad-hoc

5.2 Perspectives

Dans l’avenir, si le projet est continué à développer, on pourra améliorer les problèmes que je viens de présenter suivants :

On peut construire un autre modèle multi-interfaces multicanaux tel que chaque interface est contrôlé un agent de routage différent. En conséquence, on peut simuler les équipements qui contiennent des technologies différentes comme :

Wimax, Wifi et GPRS.

On peut améliorer le protocole AODV en s’adaptant le modèle multi-interface multicanaux pour élever le débit de réseau et la stabilisation de réseau Ad-hoc

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

On peut construire le protocole indépendant MCR dans le NS2 pour évaluer la performance et l’effet de ce protocole.

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

Chapitre 6. Bibliographies et références

6.1 Références scientifiques

[1]. Victor Moraru, La structure de l'Internet, IFI, 2008. [2]. Pradeep Kyasanur, Nitin H. Vaidya "Routing in Multi-Channel Multi-Interface Ad Hoc Wireless Networks" Technical Report, December 2004 [3]. R. A. Calvo, and J. P. Campo. "Adding multiple Interface Support in NS2", Techincal Report, University of Cantabria. Jan, 2007 [4]. Tcl Developer Site : http://www.tcl.tk/ [5]. Kevin Fall, Kannan Varadhan «The ns Manual», The VINT Project, Octobre 15, 2008 [6]. Francisco J.Ros and Pedro M.Ruiz. Implementing a new MANET unicast routing protocol in NS2. Technical report, University of Murcia December 2000 [7]. Farhat Anwar, Md. Saiful Azad, Md Arafatur Rahman, and Mohammad Moshee Udin « Performance Analysis of Ad hoc Routing in Mobile WiMAX Environment », IAENG International Journal of Computer Science, 21 Août 2008. [8]. Min-Te Sun, Chung-Kuo Chang, Ten-Hwang Lai, «A Self-Routing Topology for Bluetooth Scatternet», Proceedings of the 2002 International Symposium on Parallel Architectures, Algorithms and Networks, pp 17, 2004 [9]. Elizabeth M. Royer, C-K Toh «A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks», IEEE Personal Communications, 1999

[10].

Kevin Fall, Kannan Varadhan «The ns Manual», The VINT Project, Octobre 15, 2008

[11].

A. Nasipuri, J. Zhuang, and S.R. Das, «A multichannel CSMA MAC protocol for

multihop wireless networks,» WCNC, September 1999. [12]. A. Nasipuri,S.R. Das, «Multichannel CSMA with signal power-based channel selection for multihop wireless networks,» VTC, Septembre 2000. [13]. N. Jain, S. Das, A. Nasipuri, «A multichannel CSMA MAC protocolwith receiver- based channel selection for multihop wireless networks,», IEEE International Conference on Computer Communications and Networks (IC3N), Octobre 2001. [14]. Atul Adya, Paramvir Bahl, Jitendra Padhye, Alec Wolman, Lidong Zhou, «A multi- radio unification protocol for ieee 802.11 wireless networks,” in IEEE International Conference on Broadband Networks (Broadnets), 2004. [15]. Paramvir Bahl, Ranveer Chandra, John Dunagan, «Ssch: Slotted seeded channel hopping for capacity improvement in ieee 802.11 adhoc wireless networks,» in ACM Mobicom, 2004. [16]. N. Shacham, P. King., «Architectures and performance of multichannel multihop packet radio networks,» IEEE Journal on Selected Area in Communications, vol. 5, no. 6, pp. 10131025, juillet1987. [17]. Jungmin So, Nitin H. Vaidya, «A routing protocol for utilizing multiple channels in multi-hop wireless networks with a single transceiver,» Tech. Rep., University of Illinois at Urbana-Champaign, Octobre 2004. [18]. Richard Draves, Jitendra Padhye, Brian Zill, «Routing in multiradio,multi-hop wireless mesh networks,» in ACM Mobicom, 2004. [19]. Brent B. Welch «Practiacal Programming in TCL en TK», Prentice Hall PTR, 1995

TPE - Protocoles de routage dans les réseaux multi-radios mobiles

6.2 Références autres

[20]. Simulation of IEEE 802.15.4/ZigBee with Network Simulator-2 (ns-2):

[21].

http://www.ifn.et.tudresden.de/~marandin/ZigBee/ZigBeeSimulation.html Wikipedia The free encyclopedia: http://en.wikipedia.org/wiki/

[22].

NS2 The network simulator (Page consultée le 5 novembre 2008)

[23].

http://nsnam.isi.edu/nsnam/index.php/Main_Page NAM Network Animator (Page consultée le 5 novembre 2008) :

[24].

http://www.isi.edu/nsnam/nam/ The Enhanced Network Simulator, http:// www.cse.iitk.ac.in/users/braman/tens

[25].

Tzi cker Chiueh, Ashish Raniwala Rupa Kishnan, and Kartil Gopalan. Hyacinth :An IEEE 802.11 -based Multi-channel Wireless Mesh Network.

[26].

http://www.ecsl.cs.sunysb.edu/multichannel,(Page consultée le 5 novembre 2008) Bo Wang. NS2 Notebook : Multi-channel Multi-interface Simulation in NS2(2.29). http://www.cse.msu.edu/~wangbo1/ns2/nshowto8.html (Page consultée le 5 novembre

2008)

[27]. Dapeng Wang. Make « hyacinth » run on Debian NS-2.29.2. http://my.opera.com/HenryDF/blog/show.dml/202861 (Page consultée le 5 novembre

[28].

2008)

Nitin H. Vaidya, «Mobile Ad Hoc Networks:Routing, MAC and Transport Issues»,

consultée

décembre 2008)

Séminaire

2006,

(Page

le

25

,

[29]. ZigBee Tutorial, (Page consultée le 25 décembre 2008), http://www.ifn.et.tu- dresden.de/~marandin/ZigBee/ZigBeeTutorial.html [30]. Scalable Network Technologies, « Qualnet simulator version 3.6 ». http://www.scalable-networks.com (Page consultée le 25 décembre 2008)