Tpe-Tran Quoc Tuan

INSTITUT DE LA FRANCOPHONIE POUR INFORMATIQUE
Rapport de travail personnel encadr

Protocoles de routage dans les rseaux multi-radios mobiles
Superviseurs: Etudiant :
Victor MORARU LE Van Tuan TRAN Quoc Tuan Promotion 14, IFI
Hano, Juin - 2009
TPE - Protocoles de routage dans les rseaux multi-radios mobiles
Remerciements
Avant de vous prsenter ce rapport, Je tiens remercier tous ceux qui mont aid raliser ce TPE. Je voudrais en particulier citer : M. Victor MORARU, professeur lInstitut de la francophonie pour linformatique, il ma donn ses commentaires. En plus, il m'a donn beaucoup de conseils pour rsoudre tous les problmes en conception et en programmation. Cest intressant et utiles pour moi. M. LE Van Tuan, chercheur de laboratoire MSI, il ma propos lide de mon travail thorique et pratique. Ces ides mont aid vrifier le but de TPE. Enfin, tous les autres professeurs et amis lIFI, les personnes mont donn des conseils, des remarques et des critiques pour que je puisse amliorer le rsultat.
Rapport final pour TPE - Tran Quoc Tuan, P14, IFI
Page i
Table des matires

Remerciements ............................................................................................................................ i Table des matires......................................................................................................................ii Chapitre 1. Introduction .......................................................................................................... 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Chapitre 2. 2.1 Contexte ........................................................................................................... 1 Travail thorique .............................................................................................. 1 Travail pratique ................................................................................................ 2 Termes techniques principaux .......................................................................... 2 Outils employs ................................................................................................ 2 Rsultats attendus ............................................................................................. 3 Difficults principales ...................................................................................... 3 Etat de lart ........................................................................................................... 4 Technologies de communication sans fils dans les rseaux informatiques ..... 4 Wifi (802.11 a/b/g /draft n) ........................................................................ 4 Wimax (802.16d fixable / 802.16e mobile) ............................................... 4 ZigBee (802.15.4 Wireless Personal Area Network) .............................. 4 Bluetooth .................................................................................................... 4
2.1.1 2.1.2 2.1.3 2.1.4 2.2
Protocoles de routages dans le rseau 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 modle multi-interface multicanaux ................................................ 6 MITF .......................................................................................................... 6 TENS .......................................................................................................... 6 Hyacinth ..................................................................................................... 7 Module-based Wireless Node (MWNode - module de nud sans fil) ...... 7 Modle multi-interface multicanaux de chercheur Ramn Agero Calvo 8
2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4
Protocoles de routage dans le rseau 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 Problmes existants .................................................................................... 9 2.5 Simulation des protocoles de routage de rseaux sans fils dans NS2 ............ 10
2.5.1 Simulation des protocoles de routage....................................................... 10 2.5.2 Problmes existants dans NS2.................................................................. 10 Chapitre 3. 3.1 Ralisation pratique ........................................................................................... 12 Objectif ........................................................................................................... 12 Page ii

3.2 Construction d'un modle des nuds mobiles multi-interfaces multicanaux 12 Architecture dun nud mobile................................................................ 12 Architecture original dun nud mobile NS2 .......................................... 12 Nouvelle Architecture dun nud mobile ................................................ 14 Changement dans la source de code NS2................................................. 15
3.2.1 3.2.2 3.2.3 3.2.4 3.3 interfaces
Changement lagent de routage pour sadapter le nouveau modle de multi16
3.3.1 Protocole AODV ...................................................................................... 16 3.3.2 Changement de code C++ pour crer un nouveau modle en sadaptant le modle multicanaux multi-interfaces ............................................................................... 17 3.4 Protocole de routage dans le modle multicanaux multi-interfaces MCR ..... 21 3.4.1 Stratgie de lassignement dinterface ..................................................... 22 3.4.2 Changement du code C++ pour limplmentation de commutation de linterface 24 3.5 Chapitre 4. 4.1 Table de changement de code ........................................................................ 28 Exprimentation ................................................................................................. 29 Test de scnario de modle des nuds multi-interfaces ................................ 29
4.1.1 Topologie du rseau ................................................................................. 29 4.1.2 Contenu de scnario ................................................................................. 29 4.1.3 Rsultat :................................................................................................... 29 4.2 Test de scnario de routage de modle des nuds multi-interfaces .............. 30
4.2.1 Topologie du rseau ................................................................................. 30 4.2.2 Contenu de scnario ................................................................................. 30 4.2.3 Rsultat ..................................................................................................... 30 4.3 Deux scnarios de transmission de mme frquence ..................................... 33
4.3.1 Scnario 1 de transmission de mme frquence....................................... 33 4.3.2 Scnario 2 de transmission de mme frquence....................................... 34 4.4 Deux scnario de distance .............................................................................. 36
4.4.1 Scnario 1 de distance .............................................................................. 36 4.4.2 Scnario 2 de distance .............................................................................. 37 4.5 Scnario dimplmentation de commutation de linterface ........................... 38
4.5.1 Topologie du rseau ................................................................................. 38 4.5.2 Contenu de scnario ................................................................................. 39 4.5.3 Rsultat ..................................................................................................... 39 Chapitre 5. 5.1 5.2 Conclusions et perspectives ............................................................................... 40 Conclusion...................................................................................................... 40 Perspectives .................................................................................................... 40 Page iii

Chapitre 6. 6.1 6.2 Bibliographies et rfrences .............................................................................. 42 Rfrences scientifiques ................................................................................. 42 Rfrences autres............................................................................................ 43
Table des figures

Figure 1 - Architecture originale d'un nud mobile dans NS2 .................................. 13 Figure 2 - Nouvelle architecture dun nud mobile dans NS2 .................................. 14 Figure 3 - Processus de dcouverte de route ................................................................ 16 Figure 4 - Processus de lentretien de route ................................................................. 17 Figure 5 - Commutation de linterface avec 3 canaux et 2 interfaces ......................... 23 Figure 6 - File de paquet de chaque canal.................................................................... 24 Figure 7 - Topologie de modle des nuds multi-interfaces (scnario 1) ................... 29 Figure 8 - Rsultat de scnario 1.................................................................................. 29 Figure 9 - Topologie de scnario 2 .............................................................................. 30 Figure 10 - Dbit de nud 0 ........................................................................................ 31 Figure 11 - Dbit de nud 0 et nud .......................................................................... 32 Figure 12 - Topologie de scnario 1 de mme frquence ............................................ 33 Figure 13 - Dbit de 2 connexion ................................................................................ 34 Figure 14 - Topologie de scnario 2 de transmission de mme frquence .................. 35 Figure 15 - Dbit de nud 0 et nud 1 ....................................................................... 35 Figure 16 - Topologie de scnario 1 de distance ......................................................... 36 Figure 17 - Dbit de nud n ........................................................................................ 37 Figure 18 - Topologie de scnario 2 de distance ......................................................... 37 Figure 19 - Dbit de nud n ........................................................................................ 38 Figure 20 - Topologie de scnario 1 de distance ......................................................... 39 Figure 21 - Dbit de nud n ........................................................................................ 39
Page iv
Chapitre 1. Introduction
1.1 Contexte
Aujourdhui, les rseaux sans fils sont connus pour appliquer transfrer des donnes entre les terminaux mobiles. Il y a beaucoup de technologies de rseaux sans fils comme : Wifi, Wimax, ZegBee, Bluetooth, En consquence, il est difficile de choisir une technologie optimale, et on se propose de les intgrer sur le mme rseau. Dautre part, il y a des problmes de ces technologies comme : renforcer la robustesse du rseau, optimiser lutilisation de bande passante, conomiser lnergie surtout le problme de protocole de routage. Mon sujet qui est un sujet de recherche va concentrer la recherche des protocoles de routage des rseaux multi-radio mobiles. Alors, ce TPE pour but de faire dune tude de routage dans les rseaux multi-radio (multifrquence, multicanaux, etc.) et valuer les caractristiques de ces rseaux 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 crer les paramtres meilleurs que les rseaux existants.
1.2 Travail thorique

o Etudier tous les technologies de communication sans fils dans les rseaux 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 rseaux ad hoc, les protocoles de routage multi-radio : AODV (ractif) DSR (ractif) OLSR (proactif) TBRPF (proactif) 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 rseaux sans fils, les diffrents technologies de communication radio. o Etudier ltat de lart sur les protocoles de routage multi-radio (multifrquence, multicanaux, etc.). En consquence, il faut donner les avantages et les inconvnients de ces protocoles. o Si possible, proposer un nouveau protocole ou adapter un protocole existant pour faire du routage dans les rseaux multicanaux. Forcment, ce protocole possde les avantages meilleurs que les protocoles existants.
Page 1
1.3 Travail pratique

o Apprendre tous les quelques choses pour servir du simulateur NS2 (installation, programmation, simulation). o Construire les modles des protocoles de routages avec NS2 et raliser les simulations de ces modles. o Comparer des performances des protocoles de routage existants(en termes de dbit, robustesse, tolrance aux dconnexions, latence, QoS, o Raliser et simuler un protocole de routage adapt aux rseaux multi-radio ou multifrquence ou multicanaux,.. Et analyser et donner les rsultats.
1.4 Termes techniques principaux

o Rseau informatique : est un groupe des ordinateurs connects ou des quipements pour changer les informations. Ce rseau doit distinguer le rseau de tlcommunication qui est bas sur le transfert des signaux de voix. Aujourdhui, deux rseaux sont contigus avec le dveloppement de technologie IP et la commutation de paquet. o Protocole : permettent de dfinir de faon standardise la manire dont les informations sont changes entre les quipements du rseau : il s'agit de procdures qui contrlent 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-mmes [21]. o Rseaux multi-radio /multifrquences/ multicanaux : cest--dire les rseaux sans fils qui utilisent la mthode des ondes radio / des ondes de autres frquences / des ondes de autres canaux pour changer les informations. o Rseaux Ad-hoc : est un type de rseau sans fils. Chaque nud prt transmettre des donnes aux autres nuds, le rle dun nud est comme une station et il ny a pas le nud principal. Le premier rseau Ad-hoc est le rseau radio du paquet (PRNETs) aux annes 1970, parrain par la DARPA [21]. . o Dbit binaire : mesure une quantit de donnes numriques transmises en bits par seconde (bit/s, b/s ou bps). o Robustesse : cest--dire lintensit donde dans lespace. Il est valu par la range de rseaux sans fils [21]. . o Tolrance aux dconnexions : cest--dire le nombre dordinateurs pour permettre daccder le rseau sans fils. Ce paramtre reprsente la capacit de rseau.
1.5 Outils employs

o Simulateur NS2 (Network Simulator) :cest un simulateur des vnements discrets pour but faire de la recherche de rseau. NS2 fournit un soutien substantiel pour simuler le TCP, le routage, le multicast et les protocoles dans les rseaux filaires et les rseaux sans fils (local et satellite). NS2 est crit en C++, et il y a une version oriente-objet de TCL, qui sappelle OTcl. De plus, aujourdhui,
Page 2

NS2 a intgr quelques outils comme NAM, qui est bas sur loutil danimation TCL/TK pour afficher des traces de rseau simul et des traces de paquet relles. Il soutient la maquette de topologie, lanimation au niveau de paquet, les outils divers du contrle de donnes. o Langage TCL/Tk (Tool Command Language) : est un outil trs puissant, mais il est facile dapprendre le langage de programmation dynamique. Il est adapt aux domaines larges comme : le Web et les applications de bureau, rseau, l'administration, les essais et beaucoup d'autres. En plus, Tk est une interface graphique utilisateur d'outils pour dvelopper 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'excutent 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 procdurale, la programmation oriente objet et la programmation gnrique. Dans ce sujet, le langage C++ peut tre rcrit quelques classes pour simuler les rseaux meilleurs.
1.6 Rsultats attendus

o Donner une synthse danalyse des protocoles du routage dans les rseaux multiradio mobiles. o Chercher et simuler les modles des protocoles de routage avec NS2. o Faire dune comparaison des performances des protocoles du routage existants avec les paramtres : dbit, robustesse, tolrance aux dconnexions, Donner les avantages et les inconvnients de ces protocoles o Si possible, donner, simuler un protocole de routage adapt aux rseaux multiradio, multifrquence ou multicanaux
1.7 Difficults 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 rseau Ad-hoc comme : les protocoles du routage proactifs, les protocoles du routage ractifs, les protocoles du routage adaptatifs, les protocoles du routage hybride, les protocoles du routage hirarchique, En consquence, il est difficile de dterminer les protocoles principaux du routage o Le simulateur NS2 est un environnement console, il est moins convivial que les autres simulateurs comme : OMNeT++, OpNET,
Page 3
Chapitre 2. Etat de lart

La partie thorique de mon TPE contient dtudier les technologies de communication sans fils dans les rseaux informatiques et les protocoles de routage dans les rseaux ad-hoc et les protocoles de routage multi-radio en particulier. En plus, cette partie est destine vous prsenter le modle de multi-radios et multicanaux dans le logiciel de simulateur NS2.
2.1 Technologies de communication sans fils dans les rseaux informatiques

Aujourdhui, il y a des technologies de communication sans fils qui a pour but de transfrer rapidement des donnes, dconomiser lnergie, optimiser lutilisation de bande passante,
2.1.1 Wifi (802.11 a/b/g /draft n)

Wifi est une technique de rseau informatique sans fil pour fonctionner le rseau interne et un moyen daccs lInternet. 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 : spcifie 52 canaux de sous-porteuses radio dans la bande de frquences des 5 GHz. IEEE 802.11b : spcifie 13 canaux dans la bande de frquences des 2.4 GHz IEEE 802.11 draft n : spcifie quelques canaux dans 2 bandes de frquences 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 tlcommunication sans fils qui est bas sur la norme IEEE 802.16 ou sappelle Broadband Wireless Access. La vitesse WIMAX peut tre jusqu 75 Mb/s (large bande symtrique). Aujourdhui, on divise Wimax en 2 normes : 802.16d pour lutilisateur fixable et 802.16e pour lutilisateur mobile.[7].
2.1.3 ZigBee (802.15.4 Wireless Personal Area Network)

ZIGBEE - nouvelle technologie sans fils qui est prsent par le standard IEEE 802.15.4 PAN (Personal Area Network). Cette technologie conoit les larges applications et pour remplacer les technologies non-standards. Aujourdhui, 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 dappliquer le WPAN (Wireless Personal Area Network).[29].
2.1.4 Bluetooth
Bluetooth est une technologie mergeante qui peut remplacer linterconnexion en cble. Bluetooth permet aux quipements de connecter en distance courte avec la bande nonautorise 2.4 GHz. Il soutient la connexion-oriente et le lien sans connexion. Pour le prix bon march et la popularit de Bluetooth, cette technologie est non seulement un fondement
Page 4

idal de LAN sans fils, mais encore une technologie potentielle de PAN ad-hoc (Personal Area Network ad-hoc) [8]. .
2.2 Protocoles de routages dans le rseau ad-hoc

Le rseau Ad-hoc est un type de rseau sans fils. Chaque nud prt transmettre des donnes aux autres nuds, le rle dun nud est comme une station et il ny a pas le nud principal. Aujourdhui, il y a beaucoup de recherche de problme de routage dans le rseau ad-hoc surtout les protocoles de routage. Aujourdhui, on divise en 3 types de protocole de routage dans le rseau ad-hoc [3].
2.2.1 Le protocole proactif

Le protocole proactif est un type de protocole de routage. Il peut dterminer la route indpendante 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 gnraux qui sont plus hauts quand les routes sont en train de mettre jour [28]. . Voici les plusieurs protocoles proactifs :
2.2.1.1 DSDV Destination Sequenced Distance Vector Routing

DSDV est un algorithme de table-moteur (table-driven), qui est bas sur le mcanisme de routage classique Bellman-Ford. Lamlioration de lalgorithme 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 nuds dans le rseau. Chaque nud 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 cre les routes quand le nud de source demande une route de source la destination. Ensuite, le processus de route dcouvert commence dans le rseau. Ce processus va complter quand une route a cherch. Aprs une route est tablie, il y a des formes de procdure 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 nud de source S veut envoyer un paquet au nud de destination D, mais le nud S ne connait pas la route au nud D. Le nud S va commencer le processus la dcouvert de route. En consquence, le nud S inonde les messages Route Request (RREQ). Chaque nud ajoute son identification quand le transfert de message RREQ. En fin, partir des messages RREQ, le nud S va choisir une route plus optimale. [28].
Page 5
TPE - Protocoles de routage dans les rseaux 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-tte. En consquence, les paquets ont le large en-tte et pour dgrader la performance de rseau. Par contre, le protocole AODV essaie de maintenir les tables de routage pour amliorer le DSR, parce que les paquets de donne ne contiennent pas des routes. En plus, AODV retient la fonction de DSR que les routes maintiennent entre les nuds 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 amliorer mieux le routage [17]. Ce rapport va prsenter 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 ltat de rseau et maintient la route sans se soucier daucunes donnes de circulation existent ou non. En plus, il dtermine une route au nud de destination sil y a quelques donnes qui ont envoy au nud de destination. [28].
2.3 Projets de modle multi-interface multicanaux

Jai fait dune recherche de les modles multi-interface qui sadaptent le modle de simulateur NS2. Quelques approches sont utilises ou disponibles. Dans cette section, je vais analyser 3 approches les plus pertinentes.
2.3.1 MITF
Ce projet nest pas actif, ce qui a t ralise lUniversit de Rio de Jainero. Son objectif tait de mise en uvre des interfaces multiples et dadapter le protocole de routage AODV avec NS2 en version 2.28. Toutefois, puisque ce projet arrt, il nest pas possible dvaluer pleinement les rsultats 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 diffrents modules qui sont une partie de larchitecture MobileNode comme LL, ARP, MAC et les tableaux (listes de variables) . De cette faon, il est possible de se rfrer au module (modle 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 crs dans la classe MobileNode pour grer la liste de nuds associs chaque canal, en utilisant le canal comme l'indice d'accs ces deux nouveaux tableaux. D'autre part, limplmentation de code Tcl et de protocole de routage AODV ont t modifis de sorte que la capacit multi-interface pourrait tre exploite par le protocole de routage. Mais le dveloppement de ce projet n'est pas compltement 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'amliorer la ns-2.1b9a de la mise en uvre du protocole IEEE 802.11 sur les diffrents aspects, comme la couche MAC et le modle physique pour ajouter
Page 6

le soutien linterface multiple pour de cette version NS. La mise en uvre multi-modle d'interface est base sur le multiplexage avec limplmentation de code C++ de la couche physique. Il a utilis un numro de canal dans le script Tcl pour slectionner le canal appropri. Ce modle de multi-interface vise imiter les diffrents canaux utiliss par la DSSS version de la norme IEEE 802.11 (galement la comptabilisation des interfrences). Cette approche a modifi les fichiers C++,Tcl et un des aspects les plus importants a t la manire dont les diffrents interfaces ont t incorpores dans le nud de code Tcl, cette approche est assez semblable celui utilis par le projet Hyacinth. Dans ce cas, une boucle a t ajoute la procdure add-interface de fichier ns-mobilenode.tcl pour crer plus d'une couche physique comme MAC, LL, et IFQ par chaque nud.
2.3.3 Hyacinth
Ce projet correspondant a t initialement ralis l'Universit de l'tat de New York pour ns-2.1b9a [25]. , et il y a des informations disponibles sur la faon de l'utiliser sur ns2,29 [26]. [27]. . Son principal inconvnient est qu'il fournit une configuration statique, dans lequel tous les nuds dans le scnario de ncessit d'intgrer jusqu' 5 diffrentes interfaces. En outre, un lagent de routage statique (configuration manuelle) a t mis en uvre pour utiliser la capacit de multicanaux. Mais il nexiste pas les informations disponibles sur la faon de modification les agents de routage comme AODV ou DSDV et de lutilisation de la capacit de multi-interfaces. Aprs avoir dfini jusqu' 11 canaux diffrents (et donc l'mulation de la couche physique IEEE 802.11b) dans le script de simulateur, cinq d'entre eux sont affects chaque nud par la commande node-config. Par consquent, les procdures correspondantes ont t ajoutes dans le fichier ns-lib.tcl. Ensuite, la procdure create-wireless-node qui est dans mme fichier, elle demande 5 fois sur la procdure add-interface, chacun d'eux avec un canal diffrent. Ces segments de code sont toujours excuts, peu importe si l'utilisateur sintresse au nud spcifique avec le nombre de linterface. En regardant les changements qui sont ncessaires au fichier mac-802.cc, il semble que pour garantir un comportement correct, dans un scnario, tous les nuds a de mme nombre d'interfaces (dans ce cas, le nombre dinterface gale 5). Dautre part, ce modle 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 scnario de script. Par consquent, il n'est pas simple de stendre l'utilisation des interfaces multiples aux protocoles de routage diffrents
2.3.4 Module-based Wireless Node (MWNode - module de nud sans fil)

Ce projet a t ralis luniversit de science et technologie norvgienne. Il fournit les modules pour largir le modle de nud NS2 surtout le nud sans fils MW-Node. Un MW-Node est un noeud (et non pas un MobileNode) avec des capacits comme sans fils, la mobilit, (le soutien dnergie, pas encore fonctionnel) - ajoute par le moyen de modules. Le but de cette nouvelle conception de la mise en rseau sans fil et mobile de soutien ns2 en est double:
Page 7

- De soutenir de nouvelles caractristiques 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 lagent de routage traite les interfaces sans fils sur les canaux diffrents - Multi-interface: plusieurs interfaces, peut-tre de diffrents types (par exemple les diffrents Mac / Phy), avec un objet de lagent de routage traite une interface. Mais cette approche a dun inconvnient. Pour utiliser le modle MW-Node, on doit installer un patch dextension NS2 (aujourdhui le patch sadapte le logiciel NS2 en version 2.33).
2.3.5 Modle multi-interface multicanaux de chercheur Ramn Agero Calvo

Cette approche a t ralise luniversit de Cantabrita, Espagne. Il fournit les changements de modle original NS2 pour soutenir la multi-interface. Il permet davoir plus une pile sans fils au-dessous d'un seul agent de routage sur un MobileNode. Toutes les piles sans fil sont identiques (mme Mac/Phy). Le code dagent de routage doit tre modifi afin de grer 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 : - Dajouter les interfaces multiples sur un moyen souple - D'utiliser un certain nombre d'interfaces flexibles par nud (cest--dire : pas tous les nuds dans le mme scnario ncessit d'utiliser les mmes interfaces). - De modifier les protocoles de routage (existants et nouveaux) pour amliorer la capacit de multicanaux, multi-interface. Mais cette approche a dun inconvnient. Son modle est vraiment multicanaux, cest-dire un seul objet de lagent de routage traite les interfaces sans fils sur les canaux diffrents. En consquence, il est difficile de soutenir un systme qui utilise les interfaces diffrentes avec les technologies diffrentes. Par exemple, il est impossible davoir un systme qui utilise un carte de GPRS et un carte de Wifi 802.11 pour accder lInternet.
2.4 Protocoles de routage dans le rseau multi-radio

Le problme de routage dans le rseau multi-radio (multicanaux, multi-interface), il nest pas nouveau. Il y a des chercheurs qui cherchent rgulirement ce problme. De plus, il y a quelques approches de problme de routage dans le rseau 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 bass sur la norme IEEE 802.11 par lutilisation de multicanaux. Nasipuri et les autres auteurs [11]. , [12]. , Jain et les autres auteurs [13]. ont propos un classe de protocole o touts les nuds qui ont une interface pour chaque canal. Ces
Page 8

protocoles sont diffrents dans le calcul de mtrique quand on choisit un canal pour la communication entre les nuds. Ensuit, So et les autres auteurs [16]. ont propos une solution de multicanaux que lutilisation de linterface unique. Nanmoins, touts les protocoles multicanaux ci-dessus veulent changer la norme IEEE 802.11 et nutilisent pas lhardware actuel. Bahl et les autres auteurs [15]. ont propos une solution de couche-lien que ce protocole utilise une interface unique et peut excuter la norme IEEE 802.11 non-modifie. Adya et les autres auteurs [14]. ont propos une solution de couche-lien pour marquer des donnes dans la multi-interface. Kyasanur et les autres auteurs [2]. ont propos une nouvelle stratgie de distribution de linterface pour la multi-interface. Cette stratgie peut implmenter 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 rseau multicanaux que ce protocole utilise une interface unique chaque nud. Shacham et les autres auteurs [16]. ont propos larchitecture pour les rseaux multicanaux sans fils ce que lutilisation de linterface unique. Chaque nud a un canal pour recevoir des donnes. Et quand un nud veut transfrer un paquet de donnes, ce nud commute le canal de transfert. Mais cette architecture nestime pas limpact de latence de commutation. De plus, les 2 protocoles de routage sans fils existants : DSR, AODV qui soutiennent multiple interfaces, mais ces protocole nexploite pas les canaux disponibles. Draves et les autres auteurs [18]. ont propos le protocole LQSR un protocole de routage pour les rseaux multicanaux, multi-interface. LSQR suppose que le nombre dinterfaces est aussi gal que le nombre de canaux. De plus, LQRS est bas sur le rseau statique, le rseau sans fil multi-hop tels que le rseau de maille, il nexplique pas linfluence de mobilit des nuds dans le routage heuristique. Dautre part, Kyasanur et les autres auteurs [2]. ont propos un protocole de routage pour le rseau multicanaux et multi-interface. Ce protocole sappelle MCR (Multi-Channel Routing Protocol). Toutefois, il ajoute une petite couche au-dessus de la couche MAC et le protocole implmente la couche rseau. Si le nombre de canaux est trop grand, tous les canaux ne sont pas utiliss. En consquence, la performance de rseau nest pas optimale.
2.4.3 Problmes existants

Le nombre de canaux orthogonaux Deux canaux sappellent canaux orthogonaux, cest--dire ils ne sont pas chevauchants dans le spectre de londe, et ils ne crent pas linterfrence entre les autres canaux, parce que les signaux en haut frquence crent facilement linterfrence. En effet, la norme 802.11a donne 12 canaux non-chevauchants, et la norme 802.11b donne 3 canaux nonchevauchants. 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 quau futur, les nouveaux quipements vont avoir des filtres meilleurs pour lever le nombre de canaux orthogonaux. La latence de commutation dinterface Page 9

Dans la ralit, le nombre dinterfaces est plus petit que le nombre de canaux disponibles. Quand on utilise touts les canaux dune interface, on va commuter une autre interface. Pour la commutation dune interface dun canal lautre interface, il va crer une latence, qui sappelle la latence de commutation dinterface. Aujourdhui, avec les normes IEEE 802.11, la latence est de quelques millisecondes aux quelques centaines de microsecondes. A lavenir, la latence va rduire aux quelques dizaines de microsecondes. En plus, il est possible de commuter les frquences 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). Cest pourquoi, ils peuvent commuter entre 2 bandes. Protocole de routage multicanaux Aujourdhui, dans le rseau sans fil, on divise les protocoles de routage en 3 types principaux : le protocole proactif, le protocole ractif, le protocole hybride. Mais la plupart des protocoles ne soutient pas le rseau multicanaux. Les recherches de rseaux sans fils multicanaux nappliquent pas dans la ralit. A lavenir, pour le dveloppement de nouveaux rseaux comme : Wimax, Ad-hoc, Sensor, etc. le protocole de routage multicanaux va dvelopper mieux.
2.5 Simulation des protocoles de routage de rseaux sans fils dans NS2
Simulateur NS2 (Network Simulator) est un simulateur des vnements discrets pour but faire de la recherche de rseau. NS2 fournit un soutien substantiel pour simuler le TCP, le routage, le multicast et les protocoles dans les rseaux filaires et les rseaux sans fils (local et satellite). NS2 est crit en C++, et il y a une version oriente-objet de TCL, qui sappelle OTcl.
2.5.1 Simulation des protocoles de routage

NS2 est un outil trs puissant. Cependant quaujourdhui, il a dvelopp le version NS2 2.33, NS2 ne soutient compltement les rseaux sans fils surtout les protocoles de routage multicanaux, multi-interface. Pour le document [5], NS2 a soutenu les types de protocole de routage de rseau fils : le routage unicast, le routage multicast, le routage hirarchique. Pour un type de protocole de routage, NS2 fournit les fonctions API pour soutenir les utilisateurs qui simulent facilement le rseau. De nos jours, NS2 a soutenu 4 protocoles de routage dans le rseau mobile : DSDV, AODV, TORA et DSR, mais le soutien est lmentaire. De plus, il a cr les fonctions API pour construire la topologie de rseau sans fils, le protocole MAC, le protocole TDMA.
2.5.2 Problmes existants dans NS2

Cependant que NS2 a soutenu les mthodes pour les rseaux sans fils, mais il est plus petit dans le domaine des rseaux sans fils. Aujourdhui, pour dveloppent vari de technologies, NS2 doit soutenir de plus en plus mieux pour lutilisateur peut simuler les rseaux mobiles. Maintenant, il y a quelques des problmes existants dans loutil NS2 : NS2 ne soutient pas les rseaux multi-interface. Mais, dans le document [3]. , lauteur a prsent une solution pour ajouter la capacit soutenue de rseau multi-interface. En Page 10

consquence, lutilisateur va implmenter et changer les codes dans les modules de NS2 (au langage C++ et au langage TCL). Il cote beaucoup de temps pour reconstruire ces modules. NS2 ne soutient pas les rseaux multicanaux. Je peux consulter le document [2]. pour comprendre lalgorithme de routage de rseaux multicanaux et pour crer les modules de NS2. Il cote aussi les temps pour crer 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 cote beaucoup de temps pour crer ces modules.
Page 11
Chapitre 3. Ralisation pratique

3.1 Objectif
Lobjectif de cette partie sera donc de raliser le rseau multi-interface dans le document [3]. . Ce rseau multi-interface est construire dans NS2 avec les changements des modules au langage C++ et Tcl. Pour construire le rseau multi-interface, je vais installer un protocole de routage comme : AODV et valuer ces protocoles dans le rseau multi-interface. En suite, jamliore le rseau multi-interface pour construire le rseau multicanaux. Alors je peux utiliser lalgorithme dans le document [2]. pour installer le rseau multi-interface multicanaux. Ensuite, sil est possible, je vais amliorer le protocole de routage : AODV avec lalgorithme dassignement de linterface pour excuter ce protocole dans le rseau multi-interface multicanaux
3.2 Construction d'un modle des nuds mobiles multiinterfaces multicanaux

3.2.1 Architecture dun nud mobile
Un modle des mobiles multi-interfaces, multicanaux, qui a ds caractres suivants : Le nombre de canaux est modifiable Le nombre de l'interface d'un nud est variable Chaque nud peut connecter des canaux diffrents L'hritage des oprations ns2 est garanti
3.2.2 Architecture original dun nud mobile NS2

Pour construire d'un modle des nuds mobiles multi-interfaces multicanaux, on doit modifier le modle MobileNode existant dans NS2. Comme le modle original MobileNode de NS2, il ne soutient pas des nuds mobiles multi-interfaces multicanaux. L'architecture d'un nud mobile originale est le schma suivant :
Page 12
Figure 1 - Architecture originale d'un nud mobile dans NS2
Il y a quelques composants dans cette architecture : Routing Agent ; router des paquets next-hop. Aujourd'hui, NS2 soutient 4 protocoles de routage du rseau ad-hoc 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 nud next-hop dans Routing Agent et la rsolution l'adresse entre l'adresse MAC et ARP. ARP Address Resolution Protocol Il reoit des requtes de Link-Layer pour rsoudre ladresse du matriel qui se rfre une table ARP. Sil est possible de trouver une adresse, il est dcrit au en-tte de paquet MAC, Sinon, il y a requte ARP publi. Dans le cas de retrouver une adresse MAC, le paquet va s'insrer la file dinterface. Interface Queue (file dinterface)
Page 13

Donner la priorit des paquets dans protocole de routage. MAC (Media Access Control) Traiter des paquets reus ou envoys partir de Link Layer . Pour envoyer le paquet, il ajoute len-tte de MAC et transmet le paquet vers le canal. Network Interface Comme une interface de matriel, pour accder le canal. Channel Simuler des effets de canal rel sans fils dans le signal transfr.
3.2.3 Nouvelle Architecture dun nud mobile

Si on construit des nuds mobiles multi-interfaces multicanaux, on va construire une nouvelle architecture dun nud mobile. Voici le schma de la nouvelle architecture dun nud mobile :
Figure 2 - Nouvelle architecture dun nud mobile dans NS2
La diffrence entre 2 architectures est que chaque nud a des formes des couches de lien, ARP, files dinterface, MAC, interface du rseau et des entits de canal. Chaque forme reprsente une interface du rseau sans fils. Dautre part, la nouvelle structure ne change pas le matriel IEEE 802.11. En consquence, il est possible de simuler et dimplmenter la nouvelle architecture dans la ralit.
Page 14
3.2.4 Changement dans la source de code NS2

3.2.4.1 Changement du code OTCL
- Dabord, on ajoute 4 procdures dans le fichier ns-2.33/tcl/lib/ns-lib.tcl Procdure change-numifs{ newnumifs} Permettre lutilisateur de spcifier le nombre dinterface newnumifs de chaque nud. Cette procdure doit appeler avant de crer un nud sans fils Procdure get-numifs{} Trouver le nombre dinterface dfinie. Procdure : add-channel {indexch ch} Ajouter une interface (canal) dun nud. Dans cette procdure, il y a 2 arguments : + indexch : indice de canal ajout + ch :se rfrer lobjet de canal cr. Procdure ifNum{val} Ajouter la multi-interface comme un argument de procdure node-config pour changer la valeur locale de numifs_ - Ensuite, on change 2 procdures existantes dans le fichier ns-2.33/tcl/lib/ns-lib.tcl Procdure node-config args{} + Ajouter le soutien de multi-canal + Utiliser la variable chan pour prsenter la compatibilit arrir. S il y a une interface, chan est un variable single. Sil y a plus 2 interfaces, chan est une table (array). Procdure create-wireless-node{} Prendre le nombre dinterface dfini numifs_ et appler itrativement la procdure add-interface pour crer le nombre dinterface de chaque nud. - De plus, on change des procdures existantes dans le fichier ns-2.33/tcl/lib/nsmobilenode.tcl Procdure add-interface {} Ajouter une interface dans un objet MobileNode. Elle va crer une table ARP de chaque interface. Procdure add-target { agent port } Cette procdure attache une agent de routage un objet MobileNode et attache ce agent une port. En plus, cette procdure appelle get-numifs pour trouver le nombre dinterface utilise. Procdure add-target-rtagent { agent port } Cette procdure ajoute un cible (target) dagent de routage. Procdure init args{} Initialiser la table ARP dobjet MobileNode par le nombre dinterface dfini. Procdure reset{} Remettre la table ARP dobjet MobileNode par le nombre dinterface dfini.
Page 15
TPE - Protocoles de routage dans les rseaux multi-radios mobiles 3.2.4.2 Changement du code C++
Changement de lobjet MobileMode : ns-2.33/common/mobilenode.h NS 2 utilise 2 listes de lien pour grer le nombre de canal. prevX_ - rfrence de nud prcdent ; nextX_ - rfrence de nud prochain. Primitivement, ces listes sont pointeurs aux nuds. Pour changer ces liste, ces listes deviennent des tables de pointeur. comme : nextX_[MAX_CHANNELS], prevX_[MAX_CHANNELS] Changement de ns-2.33/common/mobilenode.cc Ajouter getLoc() pour retrouver la situation dun nud. Changement de ns-2.33/mac/channel.cc Pour changer la liste de gestion dans lobjet MobileNode, on change laccs de chaque nud quand on attache, supprime ou met jours un nouveau nud un canal correspondant un nombre de canal. On remplace de la commande this->index() par les commandes prevX_[this->index] , nextX_[this->index] . Dautre part, dans la fonction affectedNodes(), on ajoute une nouvelle condition pour vrifier que linterface de nud de destination soit connect le mme canal avant la transfert de paquet entre cette interface et lautre interface. Changement de ns-2.33/mac/mac-802_11.cc On modifie la mthode recv() dans la classe MAC 802.11 pour s'enregistrer linterface reue MAC correcte dans len-tte MAC.
3.3 Changement lagent de routage pour sadapter le nouveau modle de multi-interfaces

3.3.1 Protocole AODV
Tout dabord, on doit comprendre bien le processus dexcution de lagent de routage AODV dans NS2. Dans le protocole AODV, il y 2 processus : le dcouverte de route (Route Discovery) et lentretien de route (Route Maintenance).
3.3.1.1 Processus de dcouverte de route

Voici un exemple de processus de dcouverte de route dans le protocole AODV :
Figure 3 - Processus de dcouverte de route
Page 16

Si les nuds dans le rseau ad-hoc sont crs, ensuite la fonction command() de librairie AODV est excute par chaque nud. Quand la source demande une route la destination, il diffuse un paquet RREQ par le fonction sendRequest(). Les nuds intermdiaires reoivent ce paquet pour mettre jours leurs informations de source nud et crer le un pointeur arrire au nud de source dans leur table de routage. Ce paquet est transmit au nud prochain par la fonction forward(). Quand un nud reoit ce paquet RREQ, ce qui est destination, ensuite ce nud va transmettre un unicast de paquet RREP par la fonction sendReply() . Comme le RREP est propag la source de nud, les nud intermdiaires reoit ce paquet RREP par la fonction recvReply() pour crer un pointeur la nud de destination , et ces nuds intermdiaires va transmettre ce paquet par la fonction forward(). Enfin, le nud de source reoit ce paquet RREP, une route active est tablie et il faut commencer transfrer des donnes par la fonction forward().
3.3.1.2 Processus de lentretien de route

Voici un exemple de processus de lentretien de route dans le protocole AODV :
Figure 4 - Processus de lentretien de route
Ce processus a pour but de mettre jours les routes tablies. Parfois, une route dun nud offre la connectivit des informations par la fonction sendHello() pour diffuser des messages Hello. Chaque fois qu'un nud reoit un message Hello d'un voisin via recvHello(), le nud fait en sorte qu'il y a une route de voisin et en crant une route sil est ncessaire. Le nud courant peut commencer utiliser cette route pour transmettre des paquets. En outre, lorsque la rupture d'un lien est dtecte par un nud, ce nud va appeler sendError() pour notifier au nud de source avec la paquet Route Error(RERR). Ensuite le nud de source initialise un nouveau processus de dcouverte de route.
3.3.2 Changement de code C++ pour crer un nouveau modle en sadaptant le modle multicanaux multi-interfaces
Selon loriginale structure de nud mobile, on a utilis les variables : targetlist et ifqueue. Dans cette nouvelle structure, on utilise 2 tables : targetlist qui stocke des modules
Page 17

LL (Link-Layer) de toutes les interfaces dun nud, et ifqueuelist qui stocke des files dattente correspondantes. Alors, jai choisit lagent de routage AODV pour implmenter le modle des nuds multi-interfaces. Dabord, on dclare des variables dans le fichier aodv.h pour grer le nombre maximal dinterface dun nud, des modules LL et des files dattents :
//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 mthode 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 nud doit dcider une interface qui transfre chaque paquet. Cest pourquoi, on utilise une transmission diffuse (comme dans le processus Route Discovery ). Si il y des plus 2 interfaces disponibles, on doit transfrer un paquet diffus aux toutes interface de ce nud. Dans cet agent de routage AODV, on change 4 mthodes : 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) {
Page 18

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
Page 19

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. Cest pourquoi, on stocke les informations dinterface en sortie pour arriver next hop. Dans ce cas, on ajoute un variable rt_interface dans le fichier aodv_rtable.h pour stocker lindice dinterface approprie. Et le processus de transmission unicast va utiliser rt_interface pour choisir une entre de targetlist. Le processus unicast est utilis dans 2 mthodes 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) {
Page 20

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 ladresse dinterface entrante qui est un membre de en-tte de paquet commun. Dans ce cas, on trouve la valeur rt_interface dans 2 mthodes 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 modle multicanaux multiinterfaces MCR
Page 21

Dans larticle [2]. , Pradeep Kyasanur, Nitin H. Vaidya ont propos une approche gnral de routage et dassignement de linterface dans le rseau ad-hoc sans fil multicanaux muti-interfaces. Une solution de modle multicanaux est base sur les matriels existants IEEE 802.11 Une stratgie dassignement de linterface avec lalgorithme de commutation dinterface pour utiliser les interfaces et les canaux disponibles. Un protocole de routage MCR (Multiple-Channel Routing) pour amliorer le dbit avec lvaluation de la diversit de linterface et le cot de commutation dinterface. Dans ce TPE, on implmente le modle multicanaux multi-interface qui sadapte les matriels existants IEEE 802.11. Ensuite, pour amliorer le dbit de modle multicanaux multi-interface, on peut installer la stratgie dassignement de linterface avec lalgorithme de commutation dinterface sur un protocole de routage existant comme AODV. Enfin, il est difficile dimplmenter le protocole MCR dans NS2, parce que dans cet article, les auteurs utilisent le simulateur Qualnet en version 3.6 [30]. En consquence, il y a des diffrences entre le simulateur Qualnet et le simulateur NS2.
3.4.1 Stratgie de lassignement dinterface

3.4.1.1 Interface fixe et commutable
Dans cet article, les auteurs a dfini 2 concepts : linterface fixe et linterface commutable. On suppose que chaque nud a des M interfaces disponibles et ces interface sont divise en 2 groupes : Linterface fixe : Quelques K des M interfaces de chaque nud sont affects dans les longs intervalles de temps aux certains canaux K. Les canaux correspondants sont considrs comme des canaux fixes. Ces interfaces fixes sont utilises pour recevoir des donnes et sont commutables sur la base du nombre de nuds d'un canal. Linterface commutable : Les (M - K) interfaces sont assignes de faon dynamique un des autres canaux (M - K) sur les chelles de temps court qui bases sur le trafic de donnes. Les canaux correspondants sappellent les canaux commutables. Une interface commutable permet le nud X de transmettre nud Y dans leurs voisins par la commutation au canal fixe du nud Y. La valeur de M et K est diffrente dans chaque nud. Par exemple, il y a un scnario avec M = 2 et K = 1 pour tous les nuds (cest--dire une interface fixe et une interface commutable) et il y a 3 canaux non-chevauchements. Dans ce scnario de ltape 1, les nuds A, B, C ont des interfaces correspondantes sur le canal 1, 2, 3. De plus, on suppose quil y a une route : A BC, a-veut-dire le nud A veut transfrer des donnes au nud C. Dans ltape 2, le nud A commute linterface commutable de 3 2 avant de transfrer des donnes au nud 2, parce que linterface fixe de nud B est 2. De mme, dans ltape prochaine, nud B commute son interface commutable de 1 3, parce que linterface fixe de nud C est 3. En consquence, il y a une interface approprie qui cre dans un flux dinitiation et les flux postrieurs ne doivent pas commuter les autres interfaces dans le long temps.
Page 22
Figure 5 - Commutation de linterface avec 3 canaux et 2 interfaces
En gnral, si le nud X transfre au nud Y sur le canal a, linterface commutable de X est commut au canal a pour transfrer au nud Y. Et si linterface commutable de X est canal a, il ny a pas de la commutation de linterface. Cest--dire lexpditeur sadapte le rcepteur par la commutation de linterface commutable qui gale linterface fixe de rcepteur.
3.4.1.2 Assignement de linterface fixe

Lassignement de linterface fixe a pour but dslectionner le canal qui est assign une interface fixe et dinformer les nuds de voisin que le canal qui est utilis par cette interface. Chaque nud stocke 2 tables : o La table de voisin (NeighbourTable) : contient les canaux fixes qui sont utilis par ses voisins. o La liste de canaux dusage (ChannelUsageList): stocke les nombre de nuds de chaque canal fixe (mais il y a seulement des nuds dans la range de communication. Etape 1 : Chaque nud choisit un canal alatoire pour linterface fixe Etape 2 : Priodiquement, chaque nud 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 nud reoit le paquet Hello ou Request(Discovery) partir de voisin, ce nud va mettre jours : o La table de voisin : le canal fixe de son voisin o La liste de canaux dusage utilise sa table de voisin, par consquent la liste de canaux dusage contient les informations dusage 2 hops Etape 4 : Chaque nud consulte priodiquement sa liste de canaux dusage. Le temps priodique est le temps maximal de transmission dun paquet. o Si le nombre dautre nud qui utilise le mme canal fixe est grand, il y a une probabilit p pour le nud change le canal fixe. Ensuite le nud transmit un paquet Hello ou Request pour informer ses voisin sur le nouveau canal utilis. Page 23

o Dautre part, dans ce cas, la valeur de probabilit p qui gale 0.5 par une fonction alatoire.
3.4.1.3 Assignement de linterface commutable

Linterface commutable est utilis de transfrer des donnes partir de nud X, ds que le canal fixe de destination est diffrent partir de canal fixe de nud X. Chaque nud maintient une file de paquet pour chaque canal comme le schma suivant :
Figure 6 - File de paquet de chaque canal
Etape 1 : Si un paquet unicast est reu dans la couche de lien de donne (Data Link Layer) : o Le nud cherche le canal fixe de destination de paquet dans la table de voisin. Si lexpditeur a le mme canal fixe de rcepteur, il faut stocker le paquet au canal fixe. Si non, il faut stocker au le canal commutable o Pour diffuser un paquet, le nud copie et donne ce paquet la file de chaque canal. Le paquet est envoy quand le canal commence transfrer des donnes Etape 2 : Linterface commutable change le canal sil y a des paquets dans la file pour lautre canal
3.4.2 Changement du code C++ commutation de linterface

3.4.2.1 Fichier /ns-2.33/aodv/aodv.h
pour
limplmentation
de
Ajouter les nouveaux variables de classe AODV

#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;
Page 24

int interface_switchable;
3.4.2.2 Fichier /ns2.33/aodv/aodv_packet.h

On change lentte 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 nud //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

Mthode command() : Le nud choisit un canal alatoire 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 dusage
//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]++;
Mthode 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];
Mthode recvRequest(), recvReply(), recvHello() Page 25

//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;
Mthode forward()
Le programme traite le paquet reu (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]; }
Page 26

//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 nud va transfrer 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 nud cherche le canal fixe dans la table de voisin pour assigner ce canal fixe au canal commutable
Page 27

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
Page 28
Chapitre 4. Exprimentation
4.1 Test de scnario de modle des nuds multi-interfaces
4.1.1 Topologie du rseau
On cre 3 nuds avec la spcification suivant : Nud 0 a 2 interfaces : Interface 0 opre la frquence 2.14 Ghz et Interface 1 opre la frquence 914 Mb. Nud 1 a 1 interface qui opre la frquence 914 MHz Nud 2 a 1 interface qui opre la frquence 2.14 GHz
Figure 7 - Topologie de modle des nuds multi-interfaces (scnario 1)
4.1.2 Contenu de scnario

On utilise 1 transmission TCP entre le nud 0 et nud 1 partir de deuxime seconde. (2) On utilise 1 transmission TCP entre le nud 0 et nud 2 partir de douzime secondes (12)
4.1.3 Rsultat :
Voici le rsultat de dbit de nud 1 et de nud 2 :
Figure 8 - Rsultat de scnario 1
Page 29

- Ligne rouge : dbit de nud 1 - Ligne vert : dbit de nud 2 Pour le rsultat, le dbit de nud 1 ninfluence pas sur le dbit de nud 2. Parce que le nud 0 transfre des donnes la frquence 914 MHz avec linterface 0 de nud 0 ; et le nud 1 transfre des donnes la frquence 214 GHz avec linterface 0 de nud 0
4.2 Test de scnario de routage de modle des nuds multiinterfaces

On cre 3 nuds avec la spcification suivant : Nud 0 a 2 interfaces : Interface 0 opre la frquence 2.14 Ghz et Interface 1 opre la frquence 914 MHz. Nud 1 a 1 interface qui opre la frquence 914 MHz Nud 2 a 1 interface qui opre la frquence 2.14 GHz
Figure 9 - Topologie de scnario 2

On utilise 1 transmission TCP entre le nud 2 et nud 1 partir de deuxime seconde. (2) La source est le nud 2 La destination est le nud 1 Le nud 0 est intermdiaire pour transfrer directement des donnes au nud 1 et au nud 2
4.2.3 Rsultat
Voici le rsultat des dbits Dbit de nud immdiate 0 :
Page 30
Figure 10 - Dbit de nud 0
- Ligne rouge : dbit de nud 0 Dbit de destination du nud 1:
Page 31
Figure 11 - Dbit de nud 0 et nud
- Ligne rouge : dbit de nud 1 - Ligne vert : dbit de nud 0 Pour le rsultat, on a transfr des donnes entre le nud 1 et le nud 2. Le nud 0 est un rle de nud intermdiaire pour transfrer des donnes du nud 2 nud 1. Cest pourquoi, le nud 1 ne connecte pas directement le nud 2. Parce que le nud 1 a une interface qui opre la frquence 914 MHz, le nud 2 a 1 interface qui opre la frquence 2.14 GHz et la distance entre le nud 1 et nud 2 est 350, cette distance nutilise pas de connecter directement dans la norme 802.11a/b
Page 32
4.3 Deux scnarios de transmission de mme frquence

4.3.1 Scnario 1 de transmission de mme frquence
4.3.1.1 Topologie du rseau
On cre 4 nuds avec la spcification suivant : Nud 0 a 1 interface qui opre la frquence 914 MHz. Nud 1 a 1 interface qui opre la frquence 914 MHz. Nud 2 a 1 interface qui opre la frquence 914 MHz. Nud 3 a 1 interface qui opre la frquence 914 MHz.
Figure 12 - Topologie de scnario 1 de mme frquence
4.3.1.2 Contenu de scnario

On utilise 1 transmission TCP entre le nud 0 et nud 1 partir de deuxime seconde (2). Ensuite, on choisit le canal 0 et la frquence 914 Mhz. o La source est le nud 0 o La destination est le nud 1 On utilise 1 transmission TCP entre le nud 2 et nud 3 partir de cinquime seconde (5). Ensuite, on choisit le canal 1 et la frquence 914 Mhz. o La source est le nud 2 o La destination est le nud 3
4.3.1.3 Rsultat
Voici le rsultat des dbits
Page 33
Figure 13 - Dbit de 2 connexion
- Ligne rouge : dbit de nud 1 - Ligne vert : dbit de nud 3 Dans cette exprience, on utilise la structure originale de nud NS2 avec la mme frquence 914 MHz. De plus, le dbit daucune connexion ninfluence pas dautre connexion. Parce que chaque connexion utilise un canal diffrent et je pense que la structure de nud NS2 utilise une bande de frquence autour de 914 MHz. En plus, la structure NS2 et la standard 802.11 utilisent les canaux orthogonaux. En consquence, ces 2 canaux nont pas linterfrence et le dbit entre 2 canaux est approximatif.
4.3.2 Scnario 2 de transmission de mme frquence

On cre 3 nuds avec la spcification suivant : Nud 0 a 2 interfaces : Interface 0 opre la frquence 914 MHz et Interface 1 opre la frquence 914 MHz. Nud 1 a 1 interface qui opre la frquence 914 MHz Nud 2 a 1 interface qui opre la frquence 914 MHz
Page 34
Figure 14 - Topologie de scnario 2 de transmission de mme frquence

On utilise 1 transmission TCP entre le nud 2 et nud 1 partir de deuxime seconde. (2) La source est le nud 2 La destination est le nud 1 Le nud 0 est intermdiaire pour transfrer directement des donnes au nud 1 et au nud 2
4.3.2.3 Rsultat
Figure 15 - Dbit de nud 0 et nud 1
- Ligne rouge : dbit de nud 1 - Ligne vert : dbit de nud 0 Dans cette exprience, on a transfr des donnes entre le nud 1 et le nud 2. Le nud 0 est un rle de nud intermdiaire pour transfrer des donnes du nud 2 nud 1. Cest pourquoi, le nud 1 ne connecte pas directement le nud 2. Parce
Page 35

que le nud 1 utilise la frquence 914 MHz, le nud 2 utilise aussi la frquence 914 MHz et la distance entre le nud 1 et nud 2 est 350m. Mais le dbit de nud 0 et nud 1 ne change pas la valeur. Parce que, on utilise 2 interfaces et 2 canaux diffrents pour transfrer des donnes. De plus, la structure NS 2 peut utiliser 2 canaux orthogonaux. Par consquent, on obtient ce rsultat.
4.4 Deux scnario de distance

4.4.1 Scnario 1 de distance
On cre n nuds avec la spcification suivant : Chaque nud a des 2 interfaces : Interface 0 opre la frquence 914 MHz et Interface 1 opre la frquence 914 MHz. La distance entre 2 nuds est 200 m.
Figure 16 - Topologie de scnario 1 de distance

On utilise 1 transmission dune application CBR entre le nud 0 et nud 1 partir de premire seconde. (1) La source est le nud 0 La destination est le nud n Le nud i ( i = 1->n-1 )est intermdiaire pour transfrer directement des donnes au nud 0 et au nud n
4.4.1.3 Rsultat
Page 36
Figure 17 - Dbit de nud n
Dans cette exprimentation, le dbit de modle original est petit que les autres cas. En consquence, le nouveau modle est meilleur que le modle original.
4.4.2 Scnario 2 de distance

On cre n nuds avec la spcification suivant : Chaque nud a 2 interfaces : Interface 0 opre la frquence 914 MHz et Interface 1 opre la frquence 914 MHz. La distance entre 2 nuds est 20 m.

On utilise 1 transmission dune application CBR entre le nud 0 et nud 1 partir de premire seconde. (1) La source est le nud 0 Page 37

La destination est le nud n Le nud i ( i = 1->n-1 )est intermdiaire pour transfrer directement des donnes au nud 0 et au nud n
4.4.2.3 Rsultat
Dans cette exprience, le dbit entre le nud 0 et le nud n est grand (800 Kbps). Cest pourquoi, la distance entre le nud 0 et nud n (maximal n = 10) = 20 * 10 = 200 m. En consquence, la transmission entre le nud 0 et le nud n est directe.
4.5 Scnario dimplmentation linterface

On cre n nuds avec la spcification suivant :
de
commutation
de
Chaque nud a des 2 interfaces : Interface 0 opre la frquence 914 MHz et Interface 1 opre la frquence 914 MHz. La distance entre 2 nuds est 200 m. Page 38

On utilise 1 transmission dune application CBR entre le nud 0 et nud 1 partir de premire seconde. (1) La source est le nud 0 La destination est le nud n Le nud i ( i = 1->n-1 )est intermdiaire pour transfrer directement des donnes au nud 0 et au nud n
4.5.3 Rsultat
Dans cette exprimentation, le dbit de modle original est petit que les autres cas. En consquence, le nouveau modle est meilleur que le modle original.
Page 39
Chapitre 5. Conclusions et perspectives

5.1 Conclusion
Dans ce TPE, jai dj termin les tches suivant : Complter la partie thorique, ce sont de o Etudier tous les technologies de communication sans fils dans les rseaux 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 rseaux ad hoc, les protocoles de routage multi-radio : AODV (ractif) DSR (ractif) 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 rseaux sans fils, les diffrents technologies de communication radio. o Etudier ltat de lart sur les protocoles de routage multi-radio (multifrquence, multicanaux, etc.). En consquence, il faut donner les avantages et les inconvnients de ces protocoles. Complter la ralisation pratique, ce sont de : o Jai dj construit le modle de nuds multi-interfaces, multicanaux pour excuter les scnarios dans le simulateur NS2 o Ensuite, jai modifi le protocole AODV pour sadapter le nouveau modle multi-interfaces, multicanaux o De plus, jai implment lalgorithme dassignement de linterface de protocole MCR [2]. sur le protocole NS2. o Aprs de tester les scnarios diffrents, on montre que le nouveau modle multi-interfaces multicanaux a des avantages comme le dbit, la latence dans le rseau sans fil, surtout le rseau Ad-hoc
5.2 Perspectives
Dans lavenir, si le projet est continu dvelopper, on pourra amliorer les problmes que je viens de prsenter suivants : On peut construire un autre modle multi-interfaces multicanaux tel que chaque interface est contrl un agent de routage diffrent. En consquence, on peut simuler les quipements qui contiennent des technologies diffrentes comme : Wimax, Wifi et GPRS. On peut amliorer le protocole AODV en sadaptant le modle multi-interface multicanaux pour lever le dbit de rseau et la stabilisation de rseau Ad-hoc Page 40

On peut construire le protocole indpendant MCR dans le NS2 pour valuer la performance et leffet de ce protocole.
Page 41
Chapitre 6. Bibliographies et rfrences

6.1 Rfrences 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 Aot 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 receiverbased 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 multiradio 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. 1013 1025, 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
Page 42
6.2 Rfrences autres

[20]. Simulation of IEEE 802.15.4/ZigBee with Network Simulator-2 (ns-2): http://www.ifn.et.tudresden.de/~marandin/ZigBee/ZigBeeSimulation.html [21]. Wikipedia The free encyclopedia: http://en.wikipedia.org/wiki/ [22]. NS2 The network simulator (Page consulte le 5 novembre 2008) http://nsnam.isi.edu/nsnam/index.php/Main_Page [23]. NAM Network Animator (Page consulte le 5 novembre 2008) : http://www.isi.edu/nsnam/nam/ [24]. 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. http://www.ecsl.cs.sunysb.edu/multichannel,(Page consulte le 5 novembre 2008) [26]. Bo Wang. NS2 Notebook : Multi-channel Multi-interface Simulation in NS2(2.29). http://www.cse.msu.edu/~wangbo1/ns2/nshowto8.html (Page consulte 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 consulte le 5 novembre 2008) [28]. Nitin H. Vaidya, Mobile Ad Hoc Networks:Routing, MAC and Transport Issues, Sminaire , 2006, (Page consulte le 25 dcembre 2008) http://www.crhc.uiuc.edu/wireless/talks/2006.Infocom.ppt [29]. ZigBee Tutorial, (Page consulte le 25 dcembre 2008), http://www.ifn.et.tudresden.de/~marandin/ZigBee/ZigBeeTutorial.html [30]. Scalable Network Technologies, Qualnet simulator version 3.6 . http://www.scalable-networks.com (Page consulte le 25 dcembre 2008)
Page 43

Tpe-Tran Quoc Tuan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tpe-Tran Quoc Tuan

Uploaded by

Copyright:

Available Formats

INSTITUT DE LA FRANCOPHONIE POUR INFORMATIQUE

Rapport de travail personnel encadr

Hano, Juin - 2009

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

Table des matires

2.1.1 2.1.2 2.1.3 2.1.4 2.2

Protocoles de routages dans le rseau ad-hoc .................................................. 5

2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4

Protocoles de routage dans le rseau multi-radio ............................................. 8

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

3.2.1 3.2.2 3.2.3 3.2.4 3.3 interfaces

Changement lagent de routage pour sadapter le nouveau modle de multi16

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

Table des figures

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

1.2 Travail thorique

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

1.3 Travail pratique

1.4 Termes techniques principaux

1.5 Outils employs

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

1.6 Rsultats attendus

1.7 Difficults principales

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

Chapitre 2. Etat de lart

2.1 Technologies de communication sans fils dans les rseaux informatiques

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

2.1.2 Wimax (802.16d fixable / 802.16e mobile)

2.1.3 ZigBee (802.15.4 Wireless Personal Area Network)

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

2.2 Protocoles de routages dans le rseau ad-hoc

2.2.1 Le protocole proactif

2.2.1.1 DSDV Destination Sequenced Distance Vector Routing

2.2.1.2 WRP The Wireless Routing Protocol

2.2.2 Le protocole actif

2.2.2.1 DSR Dynamic Source Routing

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

2.2.3 Le protocole hybride

2.2.3.1 ZRP Zone Routing Protocol

2.3 Projets de modle multi-interface multicanaux

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

2.3.4 Module-based Wireless Node (MWNode - module de nud sans fil)

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

2.3.5 Modle multi-interface multicanaux de chercheur Ramn Agero Calvo

2.4 Protocoles de routage dans le rseau multi-radio

2.4.1 Approche de protocole MAC et couche-lien multicanaux

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles

2.4.2 Approche de protocole de routage multicanaux

2.4.3 Problmes existants

Rapport final pour TPE - Tran Quoc Tuan, P14, IFI

TPE - Protocoles de routage dans les rseaux multi-radios mobiles