NB Pfe

1.1.1.
Rpublique Tunisienne Ministre de lEnseignement Suprieur
Universit de Sfax Ecole Nationale dIngnieurs de Sfax Dpartement dInformatique et de Mathmatiques Appliques
Cycle de Formation dIngnieurs dans la discipline Gnie informatique
Projet de fin dtudes N dordre: 2004GI27
MEMOIRE
prsent
lEcole Nationale dIngnieurs de Sfax

(Dpartement dInformatique et de Mathmatiques Appliques) en vue de lobtention
du Diplme National dIngnieur en Gnie Informatique

par
Nouha BACCOUR
Etude comparative de deux simulateurs pour les rseaux sans fil Ad-hoc
soutenu le 4 juillet 2005, devant la commission d'examen :
M. Abderrazak OUALI M. Bachar ZOUARI M. Maher BEN JEMAA M. Hni KAANICHE
Prsident Membre Encadreur Encadreur
Ddicace
Je ddie ce travail
A
Mes Parents : Mohamed et Fatma Pour tous leurs sacrifices, leurs soutiens, Leurs encouragements et leurs amours qui ont t la raison de ma russite. prsente Que dieu leur prsente une bonne sant et une longue vie.
A
Mes frres : Hamdi et Rami Mon fianc : Riadh Pour leur disponibilit entendre mes frustrations et les sources de mon stress Avec mes souhaits de bonheur et de russite dans leur vie.
A
jaime Tous ceux que jaime et quils maiment. Quils trouvent dans ce travail lexpression de mes sentiments les plus affectueux.
2. Nouha
Remerciement
Initialement, ce projet naurait pas t ralis sans la bndiction du Bon Dieu qui ma permis de minstruire et Qui a rcompens mes prires. Au terme de ce travail, je veux bien exprimer ma profonde gratitude mes encadreurs : Monsieur Maher BEN JEMAA, mon enseignant, Matre Assistant en informatique, et directeur du dpartement dinformatique et de Mathmatiques appliques lEcole Nationale dIngnieurs de Sfax pour avoir accept, dassurer le suivi de ce projet de fin dtudes et pour la qualit de son encadrement. Monsieur Hni KAANICHE, mon enseignant, Chercheur et Assistant lEcole Nationale dIngnieurs de Sfax, pour son soutien tout au long du droulement de ce projet et son aide si prcieuse. Mademoiselle Hend KOUBAA, Chercheur en poste doctoral luniversit Henri Poincar et Madame Virginie GALTIER, Matre de Confrences et directeur de recherche lINT, EVRY.,pour leur soutien tout au long du droulement de ce projet.
Je remercie trs vivement Monsieur Abderrazak OUALI, Professeur lEcole Nationale dIngnieurs de Sfax, pour lhonneur quil ma fait en prsidant mon jury de mmoire de fin dtudes. Je remercie trs vivement Monsieur Bachar ZOUARI, mon enseignant chercheur lINT, EVRY et assistant lInstitut Suprieur dInformatique et Multimdias de Gabes, pour avoir accept de participer ce jury.
Je ne peux conclure ces remerciements sans exprimer ma reconnaissance tous ceux qui mont aid et encourag durant ce projet.
Table de matires
Introduction gnrale..1 Chapitre1 : Les rseaux mobiles AD HOC 1. Introduction......................................................................................................................5 2. Les rseaux mobiles .........................................................................................................5 2.1. INTRODUCTION .......................................................................................................5 2.2. CLASSIFICATION DES RESEAUX MOBILES ................................................................5 2.2.1. Classification selon le mode opratoire du rseau........................................5 2.2.2. Classification selon la zone de couverture ....................................................7 2.3. LIMITATIONS DES ENVIRONNEMENTS MOBILES .......................................................8 2.4. CONCLUSION.........................................................................................................11 3. Prsentation des rseaux mobiles Ad hoc ....................................................................11 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. INTRODUCTION .....................................................................................................11 DEFINITION ET MODELISATION D'UN RESEAU AD HOC ...........................................11 LES CARACTERISTIQUES DES RESEAUX AD HOC ....................................................12 LIMITATIONS LIEES A LENVIRONNEMENT MOBILE AD HOC ...................................13 QUALITE DE SERVICE DANS LES RESEAUX AD HOC ................................................14 CONCLUSION.........................................................................................................16
4. Le routage dans les rseaux ad hoc ..............................................................................16 4.1. INTRODUCTION .....................................................................................................16 4.2. CLASSIFICATION ...................................................................................................16 4.3. LE PROTOCOLE AODV (AD HOC ON DEMAND VECTOR)......................................18 4.3.1. Table de routage ..........................................................................................19 4.3.2. Principe des numros de squence ..............................................................19 4.3.3. Dcouverte de route.....................................................................................20 4.3.4. Maintenance de route ..................................................................................21 4.4. LE PROTOCOLE OLSR (OPTIMISED LINK STATE ROUTING PROTOCOL) ................24 4.5. LE PROTOCOLE ZRP (ZONE ROUTING PROTOCOL) ...............................................25 4.6. CONCLUSION.........................................................................................................26 5. Mesure de performances ...............................................................................................26 6. Conclusion ......................................................................................................................27 Chapitre2: Comparaison qualitative entre NCTUns et GloMoSim 1. Introduction....................................................................................................................29 2. NCTUns (National Chiao Tung University network simulator) ...............................29 2.1. 2.2. 2.3. 2.4. 2.5. 3.1. 3.2. PRESENTATION GENERALE ....................................................................................29 AVANTAGES..........................................................................................................30 INCONVENIENTS ....................................................................................................32 ARCHITECTURE .....................................................................................................32 DEROULEMENT DE LA SIMULATION.......................................................................36 PRESENTATION GENERALE ....................................................................................37 AVANTAGES..........................................................................................................37
3. GloMoSim (Global Mobile information system Simulator) ......................................37
3.3. 3.4. 3.5. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6.
INCONVENIENTS ....................................................................................................39 ARCHITECTURE .....................................................................................................39 DEROULEMENT DE LA SIMULATION.......................................................................42 PLACEMENT DES NUDS .......................................................................................43 SCENARIO DE MOBILITE ........................................................................................44 TERRAIN PHYSIQUE ...............................................................................................44 GENERATION DE TRAFIC .......................................................................................45 MODULES IMPLEMENTES ......................................................................................45 PARAMETRAGE DES SIMULATIONS .......................................................................46 Chapitre3: Comparaison quantitative entre NCTUns et GloMoSim
4. Etude comparative .........................................................................................................43
5. Conclusion ......................................................................................................................47 1. Introduction....................................................................................................................49 2. Paramtres de simulation..............................................................................................49 3. Porte de transmission...................................................................................................50 3.1. 3.2. 3.3. 4.1. 4.2. 4.3. DESCRIPTION ........................................................................................................50 RESULTATS DE SIMULATION .................................................................................51 ETUDE COMPARATIVE ...........................................................................................52 DESCRIPTION ........................................................................................................53 RESULTATS DE SIMULATION .................................................................................53 ETUDE COMPARATIVE ...........................................................................................54
4. Mthode daccs au mdium.........................................................................................53
5. Performance du routage................................................................................................55 5.1. INTRODUCTION .....................................................................................................55 5.2. SCENARIO 1 ..........................................................................................................56 5.2.1. Description...................................................................................................56 5.2.2. Rsultats de simulation ................................................................................56 5.2.3. Etude comparative .......................................................................................57 5.3. SCENARIO 2 ..........................................................................................................57 5.3.1. Description...................................................................................................57 5.3.2. Rsultats de simulation ................................................................................58 5.3.3. Etude comparative .......................................................................................63 6. Scalabilit, temps de simulation et Autres facteurs ....................................................66 6.1. 6.2. 6.3. DESCRIPTION ........................................................................................................66 RESULTATS DE SIMULATION .................................................................................67 ETUDE COMPARATIVE ..........................................................................................67
7. Conclusion ......................................................................................................................70 Conclusion et perspectives.71 Bibliographie...73 Annexe1...75 Annexe2...76 Annexe3...78
Liste des figures

Figure 1.1. Le modle de rseau avec infrastructure............................................................6 Figure 1.2. Le modle des rseaux mobiles sans infrastructure ...........................................7 Figure 1.3. Lattnuation rapide du signal en fonction de la distance .................................9 Figure 1.4. Le problme des nuds cachs.........................................................................10 Figure 1.5. La modlisation d'un rseau Ad hoc.................................................................12 Figure 1.6. Le changement de la topologie des rseaux Ad hoc.........................................12 Figure 1.7. La classification des rseaux Ad hoc................................................................17 Figure 1.8. Les tapes de la dcouverte de route................................................................21 Figure 1.9. Le processus de maintenance de route dans AODV.........................................23 Figure 1.10. Relais multipoints ...........................................................................................25 Figure 2.1. les composants de larchitecture de NCTUns .................................................33 Figure 2.2. larchitecture distribue de NCTUns ...............................................................35 Figure 2.3. Temps de lexcution de la simulation en variant le nombre de nuds...........38 Figure 2.4. Arborescence du package GloMoSim ..............................................................40 Figure 2.5. Arborescence du package GloMoSim ..............................................................41 Figure 2.6. Les principales entits de Glomosim ................................................................42 Figure 3.1. Scnario pour la vrification de la porte de transmission ............................51 Figure 3.2. Nombre de paquets reus par le mobile N2 en fonction de la distance N1,N2 52 Figure 3.3. Scnario de test de la mthode daccs ...........................................................54 Figure 3.4. Collision entre les trames RTS ..................................................................54 Figure 3.5. Scnario 1 pour le test du routage ..................................................................56 Figure 3.6. Scenario1 ltat initial..................................................................................57 Figure 3.7. Rsultats de simulation du scnario 1 avec NCTUns.......................................60 Figure 3.8. Rsultats de simulation du scnario 1 avec GloMoSim ...................................63 Figure 3.9. Taux de paquets reus en fonction du temps (avant la correction)..................64 Figure 3.10. Taux de paquets reus en fonction du temps (aprs la correction)................65 Figure 3.11. Nombre de paquets reus en fonction du temps (aprs la correction)...........66 Figure 3.12. Taux de perte en fonction de la porte de transmission .................................67 Figure 3.13. Variations du PDR en fonction dbit, nombre de sources et mobilit ...........68 Figure 3.14. Variations du temps de simulation en fonction dbit, nombre de sources et mobilit ........................................................................................................................70
Liste des tableaux

Tableau 2.1. NCTUns 2.0 ...................................................................................................30 Tableau 2.2. Des quipements rseau simuls par NCTUns 2.0 ........................................31 Tableau 2.3. Des quipements rseau simuls par NCTUns 2.0 ........................................34 Tableau 2.4. GloMoSim 2.03 ..............................................................................................37 Tableau 2.5. Comparatif entre NCTUns et GloMoSim dans le placement des nuds .......43 Tableau 2.6. Comparatif entre NCTUns et GloMoSim dans le Scnario de mobilit ........44 Tableau 2.7. Comparatif entre NCTUns et GloMoSim dans le modle du terrain physique .....................................................................................................................................45 Tableau 2.8. Comparatif entre NCTUns et GloMoSim La gnration du trafique ............45 Tableau 2.9. Ensemble des modules implments par les simulateurs GloMoSim et NCTUns .......................................................................................................................46 Tableau 3.1. Paramtres communs aux scnarii ................................................................49
Etude comparative de deux simulateurs pour les rseaux sans fil Ad hoc
Nouha BACCOUR
Les rseaux ad hoc sont auto-organiss et ne reposent sur aucune infrastructure fixe. Les lments les composant sont en gnral relis par radio, potentiellement mobiles, et peuvent tre amens entrer ou sortir du rseau tout moment. Ces rseaux sont caractriss par la capacit de chaque participant dagir la fois comme client et comme routeur du rseau. Si un metteur nest pas porte directe de la machine destination, les informations devront tre transmises de proche en proche, le long dun chemin. Ce chemin est tabli et maintenu par le rseau en cas de modification de la topologie (ces rseaux sont dailleurs qualifis de multi-sauts). Le domaine des rseaux ad hoc est vaste et rcent. Un travail consquent est actuellement effectu dans le groupe MANET (Mobile Ad hoc Networks) de lIETF dans le but de normaliser un ou des protocoles de routage pour ces rseaux. Ces travaux, ainsi que de nombreux autres portants sur des protocoles de plus haut niveau (qualit de service, dcouverte de services, ...) sappuient sur des simulations utilisant en particulier la norme 802.11 de lIEEE. Pour que les rsultats des simulations donns par un simulateur aient un sens en imitant le comportement dun rseau rel, il faut que les modles sur lesquels se base le simulateur soient le plus proches possible de la ralit. Actuellement, il existe plusieurs simulateurs de rseaux (en particulier les rseaux ad hoc) de popularit diffrente. Chaque simulateur se base sur une mthodologie et un modle propre lui pour pouvoir modliser un rseau rel. Si le modle est simple, la simulation gnre peu dvnements. Par consquent, le temps de simulation sera rduit ce qui favorise le passage lchelle ou la scalabilit (simuler des rseaux dont la taille peut atteindre 10.000 noeuds). En contre partie, la prcision sera mdiocre. Si le modle est complexe, la simulation sera coteuse en terme doccupation des ressources car elle gnre trop dvnements. Cest pourquoi le passage lchelle ne sera pas toujours possible ( moins quon exploite plusieurs processeurs). En revanche, les rsultats de simulation seront plus prcis. NCTUns est un nouveau simulateur de rseaux, en particulier les rseaux ad hoc. Sa premire version est sortie en Juin 2003. Il apporte beaucoup davantages tel que la facilit dutilisation et son ralisme dans limplmentation des applications. Comment peut on valuer ce simulateur ? Est ce quil possde des inconvnients ? En particulier, est ce que le passage lchelle du simulateur est possible tout en garantissant des rsultats prcis de simulation ?
-2-
Nouha BACCOUR
Notre travail porte sur lvaluation du simulateur NCTUns (version 2.0) en le comparant un simulateur clbre qui a t test par plusieurs scientifiques. Ce simulateur est intitul GloMoSim. Dans le premier chapitre, nous prsentons le concept des rseaux mobiles Ad hoc (dfinition, modlisation, caractristiques, applications,). Dans le chapitre suivant, nous commenons par dcrire les caractristiques et les capacits des deux simulateurs NCTUns et GloMoSim. Enfin, nous menons une comparaison prliminaire ou qualitative des deux simulateurs. Dans le dernier chapitre, nous procurions aux simulations pour pouvoir comparer les simulateurs en terme de rsultats et de temps de simulation.
-3-
Nouha BACCOUR
3. Introduction L'volution rapide de la technologie dans le domaine de la communication sans-fil, a permis des usagers munis d'units de calcul portables d'accder l'information indpendamment des facteurs : temps et lieu. Ces units, qui se communiquent travers leurs interfaces sans-fil, peuvent tre de diverses configurations : avec ou sans disque, des capacits de sauvegarde et de traitement plus ou moins modestes et aliments par des sources d'nergie autonomes (batteries).
4. Les rseaux mobiles 4.1. Introduction Un rseau sans-fil ou encore un rseau mobile est un rseau dans lequel au moins deux terminaux peuvent communiquer sans liaison filaire. Grce aux rseaux sans-fil, un utilisateur a la possibilit de rester connect tout en se dplaant dans un primtre gographique plus ou moins tendu. On distingue habituellement plusieurs catgories de rseaux sans-fil.
4.2. Classification des rseaux mobiles La classification des rseaux sans-fil peut tre mene selon le mode opratoire du rseau et on distingue ainsi deux modes : Le mode avec infrastructure qui utilise gnralement le modle de la communication cellulaire, et le mode sans infrastructure ou mode ad hoc. La classification des rseaux sans-fil peut galement tre mene selon le primtre gographique offrant une connectivit (appel zone de couverture), on distingue ainsi quatre catgories : rseaux personnels sans-fil, rseaux locaux sans-fil, rseaux mtropolitains sans-fil et rseaux tendus sans-fil. 4.2.1. Classification selon le mode opratoire du rseau Un rseau avec infrastructure (figure1.1) est compos de deux ensembles d'entits distinctes : Les sites fixes d'un rseau de communication filaire classique (wired network), et les sites mobiles (wireless network). Les sites fixes, appels gnralement station de
-5-
Nouha BACCOUR
base sont munis d'une interface de communication sans-fil pour la communication directe avec les sites ou units mobiles. Les sites mobiles sont localiss dans une zone gographique limite, appele cellule. A chaque station de base correspond une cellule partir de laquelle des sites mobiles peuvent mettre et recevoir des messages. Les sites fixes sont interconnects entre eux travers un rseau de communication filaire, gnralement fiable et d'un dbit lev. Alors que Les liaisons sans-fil ont une bande passante limite qui rduit svrement le volume des informations changes. Dans ce modle, une unit mobile ne peut tre, un instant donn, directement connecte qu' une seule station de base. Elle peut communiquer avec les autres sites travers la station laquelle elle est directement rattache. L'autonomie rduite de sa source d'nergie, lui occasionne de frquentes dconnexions du rseau; Sa reconnexion peut alors se faire dans un environnement nouveau voire dans une nouvelle localisation. Plusieurs systmes utilisent dj le modle de rseau avec infrastructure appel aussi modle cellulaire et connaissent une trs forte expansion l'heure actuelle (les rseaux GSM par exemple) mais requirent une importante infrastructure logistique et matrielle fixe. La contrepartie des rseaux cellulaires sont les rseaux mobiles ad hoc.
Rseau Statique (Mb/s Gb/s) Station de Base Unit mobile Cellule de communication sans-fil Ensemble de sites fixes
Figure 1.1. Le modle de rseau avec infrastructure
Un rseau sans infrastructure prexistante (figure 1.2) ou ad hoc ne comporte pas l'entit site fixe, tous les sites du rseau sont mobiles et se communiquent d'une manire directe en utilisant leurs interfaces de communication sans-fil. L'absence de l'infrastructure ou du rseau filaire compos des stations de base, oblige les units mobiles se comporter
-6-
Nouha BACCOUR
comme des routeurs qui participent la dcouverte et la maintenance des chemins pour les autres htes du rseau. Les applications des rseaux sans infrastructure prexistante ou ad hoc sont nombreuses, on cite l'exemple classique de leur application dans le domaine militaire et les autres applications de tactique comme les oprations de secours et les missions d'exploration.
Figure 1.2. Le modle des rseaux mobiles sans infrastructure
4.2.2. Classification selon la zone de couverture Rseaux personnels sans-fil : Concerne les rseaux sans-fil d'une faible porte : de l'ordre de quelques dizaines mtres. Ce type de rseau sert gnralement relier des priphriques (imprimante, tlphone portable, appareils domestiques,...) ou un assistant personnel (PDA) un ordinateur sans liaison filaire ou bien permettre la liaison sans-fil entre deux machines trs peu distantes. Il existe plusieurs technologies utilises pour les Rseaux personnels sans-fil. La principale technologie Rseaux personnels sans-fil est la technologie Bluetooth, lance par Ericsson en 1994, proposant un dbit thorique de 1 Mbps pour une porte maximale d'une trentaine de mtres. Bluetooth, connue aussi sous le nom IEEE 802.15.1, possde l'avantage d'tre trs peu gourmande en nergie, ce qui la rend particulirement adapte une utilisation au sein de petits priphriques. Rseaux locaux sans-fil: est un rseau permettant de couvrir l'quivalent d'un rseau local d'entreprise, soit une porte d'environ une centaine de mtres. Il permet de relier entre-eux les terminaux prsents dans la zone de couverture. Il existe plusieurs technologies concurrentes. La technologie la plus rpandue pour ce type de rseau sans-fil est le Wifi (ou IEEE 802.11), soutenu par l'alliance WECA (Wireless Ethernet Compatibility Alliance) et qui offre des dbits allant jusqu' 54Mbps sur une distance de plusieurs centaines de mtres. Le standard 802.11 dfinit deux modes opratoires :
-7-
Nouha BACCOUR
Le mode infrastructure dans lequel les clients sans-fil sont connects un point d'accs. Il s'agit gnralement du mode par dfaut des cartes 802.11b.
Le mode ad hoc dans lequel les clients sont connects les uns aux autres sans aucun point d'accs. Cest le Wifi en mode ad hoc quon souhaite utiliser dans ltude comparative. Rseaux mtropolitains sans-fil: est connu sous le nom de Boucle Locale Radio
(BLR). Les WMAN sont bass sur la norme IEEE 802.16. La boucle locale radio offre un dbit utile de 1 10 Mbit/s pour une porte de 4 10 kilomtres, ce qui destine principalement cette technologie aux oprateurs de tlcommunication. Rseaux tendus sans-fil: est galement connu sous le nom de rseau cellulaire mobile. Il s'agit des rseaux sans-fil les plus rpandus puisque tous les tlphones mobiles sont connects un rseau tendu sans-fil. Les principales technologies sont les suivantes : GSM (Global System for Mobile), GPRS (General Packet Radio Service) et UMTS (Universal Mobile Telecommunication System).
4.3. Limitations des environnements mobiles De part la nature du canal radio, un certain nombre de problmes se posent qui ne trouvent pas dquivalent dans le monde filaire. On peut citer en particulier : - Un dbit plus faible: par rapport un quivalent filaire. la bande passante est une ressource rare, il faut minimiser la portion utilise pour la gestion du rseau, afin de pouvoir laisser le maximum de bande passante pour les communications - Erreurs de transmission: les erreurs de transmission radio sont plus frquentes que dans les rseaux filaires. On peut citer quelques perturbations dues lenvironnement : les erreurs de transfert, la microcoupure, lexpiration du Timeout avant lacheminement de linformation transmettre. - Une attnuation rapide: du signal en fonction de la distance (bien plus rapide que sur un cble) qui induit limpossibilit pour un metteur de dtecter une collision au moment mme o il transmet. Dans un rseau filaire, un metteur sait quil y a collision quand le signal quil lit sur le cble est diffrent de celui quil cherche mettre. Dans un rseau radio, un signal venant dun autre nud est tellement attnu par la distance quil ne provoquera que des perturbations ngligeables par rapport au signal mis localement. Par exemple, sur la figure1.3, au niveau du nud B, le signal mis par B lui-mme est de trs suprieur celui quil reoit du nud A. Par consquent, le signal du nud A est
-8-
Nouha BACCOUR
compltement ignor par B qui croit quil ny a pas de collision. Malheureusement, au niveau du nud C, les deux signaux ont des puissances comparables et il y a bien collision du point de vue du rcepteur. Seul un systme dacquittement peut garantir la bonne rception dun message dans ce type de contexte. Cette incapacit dtecter un signal tranger lorsque lon met nous-mme, rend donc le mdium radio half-duplex, ce qui signifie que lon ne peut pas mettre et recevoir en mme temps.
D B A C
Figure 1.3. Lattnuation rapide du signal en fonction de la distance
- Les interfrences : Les liens radios ne sont pas isols, et le nombre de canaux disponibles est limit. Il faut donc se les partager. Les interfrences peuvent tre de natures diverses. Par exemple, des metteurs travaillant des frquences trop proches peuvent interfrer entre eux. Lenvironnement lui-mme peut galement produire des bruits parasites (certains quipements lectriques, certains moteurs,...) qui interfrent avec les communications. Lenvironnement peut aussi dformer le signal et le rendre rapidement incomprhensible cause des phnomnes dattnuation, de rflexion ou de chemins multiples (lattnuation et la rflexion varient en fonction des matriaux rencontrs ; le problme des chemins multiples apparat lorsque des rflexions dune mme onde par des chemins diffrents arrivent de manire dcale dans le temps au rcepteur, se chevauchent, et forment un tout plus difficile analyser). Ces problmes font que les taux derreurs de transmission dans les rseaux radio sont nettement plus levs que dans les rseaux filaires. Cela a un impact non ngligeable sur les protocoles de niveau suprieur. TCP en particulier va y tre particulirement vulnrable, car il va interprter les pertes de paquets comme tant dues la congestion sur le rseau. Quand TCP dtecte de la congestion, il cherche lattnuer en rduisant la taille de sa fentre dmission. Malheureusement, dans le cas
-9-
Nouha BACCOUR
prsent, cest exactement linverse quil faudrait faire, les paquets perdus doivent tre rmis au plus vite. Il faut ajouter galement que des interfrences ou des changements persistants dans lenvironnement vont conduire une grande versatilit des liens, qui peuvent apparatre ou tre coups de manire durable tout moment. - La puissance du signal : Non seulement elle est rapidement attnue avec la distance, mais elle est galement limite par des rglementations trs strictes. Un metteur ne peut donc dpasser une certaine puissance lmission. - Lnergie : Les applications relatives aux rseaux sans-fil ont en gnral un caractre nomade et tirent leur autonomie de batteries. Emettre ou recevoir des donnes consomme de lnergie et lon peut chercher lconomiser en optimisant les protocoles de gestion du rseau. La puissance dmission a un impact important sur la quantit dnergie utilise et l encore on essaie si possible de la limiter ce qui est strictement ncessaire. - Une faible scurit : Il est facile despionner un canal radio de manire passive. Les protections ne pouvant pas se faire de manire physique (il est en gnral difficile dempcher quelquun de placer discrtement une antenne rceptrice trs sensible dans le voisinage). - Topologie dynamique : De nombreuses applications des rseaux radio concernent des mobiles qui, comme leur nom lindique, sont amens se dplacer. Ceci va conduire des changements plus ou moins rapides de la topologie. Pour les grer, des protocoles appropris vont tre ncessaires. - Nuds cachs : ce phnomne est trs particulier lenvironnement sans-fil. Un exemple est illustr dans la figure 1.4. Dans cet exemple, les nuds B et C ne sentendent pas, cause dun obstacle qui empche la propagation des ondes par exemple. Les mcanismes daccs au canal vont permettre alors ces nuds de commencer des missions simultanes. Ce qui provoque des collisions au niveau du nud A.
Figure 1.4. Le problme des nuds cachs
-10-
Nouha BACCOUR
4.4. Conclusion Les environnements mobiles sont caractriss par de frquentes dconnexions et des restrictions sur les ressources utilises, surtout si tous les usagers du systme sont mobiles ce qui est le cas pour les rseaux Ad hoc. Ces rseaux possdent leurs caractristiques propres (topologie dynamique, absence d'infrastructure, routage multisauts, etc.), qui ajoutent dautres limitations aux rseaux mobiles.
5. Prsentation des rseaux mobiles Ad hoc
5.1. Introduction L'volution rcente de la technologie dans le domaine de la communication sans-fil et l'apparition des units de calculs portables, poussent aujourd'hui les chercheurs faire des efforts afin de raliser le but des rseaux : "l'accs l'information n'importe o et n'importe quand" Le concept des rseaux mobiles ad hoc essaie d'tendre les notions de la mobilit toutes les composantes de l'environnement. Ici, contrairement aux rseaux bass sur la communication cellulaire, aucune administration centralise n'est disponible, ce sont les htes mobiles elles-mmes qui forment, d'une manire ad hoc, une infrastructure du rseau. Aucune supposition ou limitation n'est faite sur la taille du rseau ad hoc, le rseau peut contenir des centaines ou des milliers d'units mobiles.
5.2. Dfinition et modlisation d'un rseau Ad hoc Un rseau mobile ad hoc, appel gnralement MANET ( Mobile Ad hoc NETwork), consiste en une grande population, relativement dense, d'units mobiles qui se dplacent dans un territoire quelconque et dont le seul moyen de communication est l'utilisation des interfaces sans-fil, sans l'aide d'une infrastructure prexistante ou administration centralise. Un rseau Ad hoc peut tre modlis par un graphe Gt = (Vt, Et) o Vt reprsente l'ensemble des nuds (i.e. les units ou les htes mobiles) du rseau et Et modlise l'ensemble des connexions qui existent entre ces nuds. Si e = (u, v) appartient
-11-
Nouha BACCOUR
Et, cela signifie que les nuds u et v sont en mesure de communiquer directement l'instant t (figure 1.5).
1 2 7 3 6 4 5
Nuds (ou units mobiles)
Liens physiques de communication
Figure 1.5. La modlisation d'un rseau Ad hoc
La topologie du rseau peut changer tout moment. Ainsi, elle est dynamique et imprvisible, ce qui fait que la dconnexion des units est trs frquente (figure 1.6).
A B A
Figure 1.6. Le changement de la topologie des rseaux Ad hoc
5.3. Les caractristiques des rseaux Ad hoc Les rseaux mobiles Ad hoc sont caractriss par : - Une topologie dynamique : Les units mobiles du rseau, se dplacent d'une faon libre et arbitraire. Par consquent la topologie du rseau peut changer, des instants imprvisibles, d'une manire rapide et alatoire. Les liens de la topologie peuvent tre unis ou bidirectionnels. - L'absence d'infrastructure : Les rseaux Ad hoc se distinguent des autres rseaux mobiles par la proprit d'absence d'infrastructures prexistantes et de tout genre d'administration
-12-
Nouha BACCOUR
centralise. Les htes mobiles sont responsables d'tablir et de maintenir la connectivit du rseau d'une manire continue. - Un routage multi-sauts : Cela signifie que des communications entre deux nuds doivent pouvoir seffectuer mme si ceux-ci sont hors de porte de communication directe. La connaissance rciproque de leur existence et les changes dinformation doivent tre possibles en traversant dautres nuds du rseau. - Chaque nud du rseau est la fois hte et routeur : Chaque nud du rseau contribue au bon acheminement des informations dans le rseau. Pour ce faire, chaque nud essaie de possder une connaissance partielle du rseau la plus tendue possible pour jouer le rle de routeur pour lui-mme et pour tout autre nud qui le lui demandera. Cette connaissance partielle se manifeste par la connaissance des voisins immdiats et leurs positions en fonction du temps. D'une faon gnrale, les rseaux Ad hoc sont utiliss dans toute application o le dploiement d'une infrastructure rseau filaire est trop contraignant, soit parce que difficile mettre en place, soit parce que la dure d'installation du rseau ne justifie pas de cblage demeurer. En plus, aucune supposition ou limitation n'est faite sur la taille du rseau Ad hoc, le rseau peut contenir des centaines ou des milliers d'units mobiles.
5.4. Limitations lies lenvironnement mobile ad hoc Limpossibilit de mettre en place un plan dallocation des frquences limite la rutilisation spatiale. Dans les rseaux radio utilisant des stations de base, on cherche attribuer des frquences diffrentes aux stations voisines, vitant que les cellules ainsi cres ninterfrent entre elles. Dans les rseaux ad hoc, pour garantir la connectivit, comme il ny a pas dinfrastructure fixe et que tous les nuds sont susceptibles de bouger ou de disparatre, il est plus simple et moins coteux de travailler avec une seule frquence. On utilise alors un multiplexage TDD (Time Division Duplex, Multiplexage temporel dans les deux sens de transmission sur une seule frquence : les voies montantes et descendantes utilisent tour de rle la mme frquence). Lnergie : Dans un rseau stations de base, les dites stations sont en gnral alimentes sur le secteur. Dans un rseau ad-hoc ces stations sont absentes. De plus, suivant la topologie du rseau, certains mobiles peuvent se trouver dans des positions clefs et assurer le routage pour un grand nombre de flux. Ces nuds peuvent tre amens consommer trs vite leurs ressources nergtiques. Le trafic de contrle peut galement
-13-
Nouha BACCOUR
avoir un impact important. En effet, comme un rseau ad-hoc doit sauto-organiser, cela signifie que dune manire ou dune autre il va y avoir un trafic de contrle dpendant de la mobilit dans le rseau. Plus la topologie changera vite et profondment, plus la charge (et donc la consommation dnergie) du trafic de contrle sera importante. La mobilit : Une variation dans l'environnement d'un mobile peut se traduire par la disparition ou lapparition d'un lien dans le rseau. La topologie peut donc voluer de faon imprvisible. Il ne suffit pas de mesurer la qualit du signal reu par un metteur pour en dduire sa position et son modle de mobilit. Si une telle stratgie peut donner des rsultats satisfaisants en espace libre, l'utilisation de terminaux radio dans des btiments ne sera pas soumise aux mmes lois. Limpact dune mobilit totale est important diffrents niveaux. Du point de vue des couches basses (PHY et MAC), comme nous lavons dj soulign, il nest dune part plus possible daffecter des frquences des zones gographiques; dautre part, les mcanismes daccs au mdium utilisant des horloges globales seront galement inutilisables (TDMA par exemple a besoin dune grande synchronisation des horloges qui est impossible dans ce contexte). A un niveau plus lev, dans les rseaux stations de base (en particulier grande chelle comme dans les rseaux de tlphonie mobile), le routage est effectu dans la partie fixe du rseau. Dans le cas des rseaux ad hoc, lensemble du routage doit fonctionner sur les mobiles et de faon totalement distribue. La faible scurit : Les problmatiques de la scurit dans les rseaux ad hoc sont trs complexes, puisque lon cherche autoriser de nouveaux mobiles participer au rseau, tout en vitant des nuds malins qui dtourneraient ou perturberaient le fonctionnement mme du routage. La qualit de service : De nombreuses applications ont besoin de certaines garanties relatives par exemple au dbit, au dlai ou encore la gigue. Dans ces rseaux ad hoc, ces garanties sont trs difficiles obtenir. Ceci est d la nature du canal radio dune part (interfrences et taux derreur levs) et au fait que des liens entre des mobiles peuvent avoir se partager les ressources (alors quen filaire, deux liens sont par dfinition indpendants).
5.5. Qualit de service dans les rseaux ad hoc Dans les rseaux de tlcommunication, lobjectif de la qualit de service est datteindre un meilleur comportement de la communication, pour que le contenu de cette
-14-
Nouha BACCOUR
dernire soit correctement achemin, et les ressources du rseau utilises dune faon optimale. La qualit de service QoS (Quality of Service) peut tre dfinie comme le degr de satisfaction dun utilisateur des services fournis par un systme de communication. La QoS est dfinie dans [16] comme la capacit dun lment du rseau (ex : routeur, nud ou une application) de fournir un niveau de garantie pour un acheminement des donnes. Le RFC 2386 [CRAW 99] caractrise la QoS comme un ensemble de besoins assurer par le rseau pour le transport dun trafic dune source une destination. Ces besoins peuvent tre traduits en un ensemble dattributs pr-spcifis et mesurables en terme de : Dlai de bout en bout, Variance de dlai (gigue), Bande passante, Pertes de paquets. Suivant le type de lapplication, les besoins de QoS sont diffrents. Par exemple, pour les applications temps rel, comme la voix et la vido, le dlai de bout en bout dun paquet doit tre limit, autrement le paquet est inutile. Les applications non temps rel, comme le transfert de fichier ou la messagerie, quant elles se focalisent sur la fiabilit des communications. Il est trs difficile de garantir une quelconque qualit de service une application temps rel dans un rseau ad hoc, car il faut prendre en considration les spcificits de ces rseaux, savoir : la bande passante limite, le changement dynamique de la topologie en fonction du temps, ainsi que le manque dinformation complte sur ltat du rseau. En outre, la communication entre les stations mobiles tant par voix radio, la qualit du lien sans-fil reste peu fiable, et susceptible des variations suivant la configuration et ltat du rseau. De nombreux problmes de qualit de service sont tudis par les solutions actuelles. On site par exemple linterconnexion avec les rseaux filaires (FQMM), la diffrentiation de services au niveau MAC [LIN 97] (MACA/PR : Multihop Access Collision Avoidance with Piggyback Reservation), la limitation des diffusions (Ticket Based Probing, CEDAR), la limitation du cot des messages de contrle (CEDAR, INSIGNIA) et en fin la Qos adptative (dynamic QoS, INSIGNIA).
-15-
Nouha BACCOUR
5.6. Conclusion Dans cette section nous avons prsent le concept de rseau ad hoc et dcrit ses principales caractristiques et limitations, nous avons aussi parl de la notion de qualit de service et les mtriques de performance qui y sont associs. Les limitations lies lenvironnement mobile ad hoc et les dsirs davoir de la qualit de services dans les communications, transforment certains problmes ayant des solutions videntes dans l'environnement classique, en des problmes complexes et difficiles rsoudre. Parmi ces problmes figure le problme de routage que nous allons discuter dans la section suivante.
6. Le routage dans les rseaux ad hoc
6.1. Introduction Les rseaux ad hoc que nous considrons sont multi-sauts. Il peut donc arriver quun mobile veuille communiquer avec un autre qui nest pas dans sa porte de communication directe. Les messages vont devoir tre transmis de proche en proche jusqu la destination : cest ce que lon appelle le routage. De nombreux protocoles de routage ont donc t proposs pour rendre les communications multi-sauts plus efficaces (moins de rmissions, chemins plus courts, etc.) Ces protocoles travaillent au niveau IP et sont donc indpendants des couches physique et MAC. Le routage IP permet en particulier une interconnectivit aise avec toutes sortes dautres rseaux ou matriels. Il est dailleurs possible dutiliser ces protocoles pour runir en un seul rseau MANET des utilisateurs utilisant des matriels diffrents (cartes radios de technologies diverses, rseaux filaires, etc.). Dans cette section, nous allons classer les protocoles de routage ensuite illustrer quelques protocoles dvelopps dans le cadre du groupe de travail MANET de lIETF.
6.2. Classification Vu les limitations des rseaux Ad hoc, la construction des routes doit tre faite avec un minimum de contrle et de consommation de la bande passante. Suivant la manire de
-16-
Nouha BACCOUR
cration et de maintenance de routes lors de l'acheminement des donnes, les protocoles de routage peuvent tre classs en trois catgories (figure 1.7).
Les protocoles de routage Ad hoc
Les protocoles Ractifs Exemple : DSR et AODV
Les protocoles Hybrides Exemple : ZRP
Les protocoles Proactifs Exemple : OLSR et DSDV
Figure 1.7. La classification des rseaux Ad hoc
Les protocoles ractifs : Le principe des protocoles ractifs est de ne rien faire tant quune application ne demande pas explicitement denvoyer un paquet vers un nud distant. Cela permet dconomiser de la bande passante et de lnergie. Lorsquun paquet doit tre envoy, le protocole de routage va rechercher un chemin jusqu la destination. Une fois ce chemin trouv, il est inscrit dans la table de routage et peut tre utilis. En gnral, cette recherche se fait par inondation (un paquet de recherche de route est transmis de proche en proche dans tout ou partie du rseau). Lavantage majeur de cette mthode est quelle ne gnre du trafic de contrle que lorsquil est ncessaire. Les principales contreparties sont que linondation est un mcanisme coteux qui va faire intervenir tous les nuds du rseau en trs peu de temps et quil va y avoir un dlai ltablissement des routes. Parmi les protocoles les plus importants de cette classe on site le protocole AODV et le protocole DSR. Les protocoles proactifs : Le principe de base des protocoles proactifs est de maintenir jour les tables de routage, de sorte que lorsquune application dsire envoyer un paquet un autre mobile, une route soit immdiatement connue. Dans le contexte des rseaux ad-hoc les nuds peuvent apparatre ou disparatre de manire alatoire et la topologie mme du rseau peut changer ; cela signifie quil va falloir un change continuel dinformations pour que chaque nud ait une image jour du rseau. Les tables sont donc
-17-
Nouha BACCOUR
maintenues grce des paquets de contrle, et il est possible dy trouver directement et tout moment un chemin vers les destinations connues en fonctions de divers critres. On peut par exemple privilgier les routes comportant peu de sauts, celles qui offrent la meilleure bande passante, ou encore celles o le dlai est le plus faible. Lavantage premier de ce type de protocole est davoir les routes immdiatement disponibles quand les applications en ont besoin, mais cela se fait au cot dchanges rguliers de messages (consommation de bande passante) qui ne sont certainement pas tous ncessaires (seules certaines routes seront utilises par les applications en gnral). Parmi les protocoles les plus importants de cette classe on site le protocole OLSR et le protocole DSR. Les protocoles hybrides : Les protocoles hybrides combinent les approches ractive et proactive. Le principe est de connatre notre voisinage de manire proactive jusqu une certaine distance (par exemple trois ou quatre sauts), et si jamais une application cherche envoyer quelque chose un nud qui nest pas dans cette zone, deffectuer une recherche ractive lextrieur. Avec ce systme, on dispose immdiatement des routes dans notre voisinage proche, et lorsque la recherche doit tre tendue plus loin, elle en est optimise (un nud qui reoit un paquet de recherche de route ractive va tout de suite savoir si la destination est dans son propre voisinage. Si cest le cas, il va pouvoir rpondre, et sinon il va propager de manire optimise la demande hors de sa zone proactive). Selon le type de trafic et les routes demandes, ce type de protocole hybride peut cependant combiner les dsavantages des deux mthodes : change de paquets de contrle rguliers et inondation de lensemble de rseau pour chercher une route vers un nud loign. Parmi les protocoles les plus importants de cette classe on site le protocole ZRP. Dans ce qui suit, on va illustrer un exemple de protocole pour chaque classe. Le protocole AODV sera illustrer comme protocole ractif, le protocole ZRP sera illustrer comme protocole proactif et Le protocole OLSR sera illustrer comme protocole hybride. Le protocole AODV sera particulirement plus dtaill ; car il est slectionn comme protocole de routage dans les simulations ralises dans notre tude comparative.
6.3. Le protocole AODV (Ad hoc On Demand Vector) L'algorithme de routage AODV [PER 99], est un protocole de routage avec vecteur de distance la demande. la demande veux dire qu'il ne construit des routes entre nuds que lorsqu'elles sont demandes par des nuds sources. LAODV est bas sur
-18-
Nouha BACCOUR
lutilisation des deux mcanismes dcouverte de route et maintenance de route , en plus du routage nud par nud et du principe des numros de squence. 6.3.1. Table de routage Chaque nud maintient une table de routage. Cette table contient une entre pour chaque destination accessible. Une entre contient principalement les informations suivantes : L'adresse IP de la destination, Le numro de squence associ la destination, La distance qui est le nombre de sauts ncessaire pour atteindre la destination (hop count ), Le nud suivant, qui il faut envoyer les paquets (next hop), Le temps de vie pour lequel la route est considre correcte. (Le temps d'expiration de l'entre de la table), Le liste des voisins qui utilisent cette route, Un tampon de requte afin quune seule rponse soit envoye par requte. Si une nouvelle route est ncessaire, ou quune route disparat, la mise jour de ces tables seffectue par lchange de trois types de messages entre les nuds : RREQ Route Request, un message de demande de route, RREP Route Reply, un message de rponse un RREQ, RERR Route Error, un message qui signale la perte dune route. 6.3.2. Principe des numros de squence L'AODV utilise les principes des numros de squence fin de maintenir la consistance des informations de routage. A cause de la mobilit des nuds dans les rseaux ad hoc, les routes changent frquemment ce qui fait que les routes maintenues par certains nuds, deviennent invalides. Les numros de squence permettent d'utiliser les routes les plus nouvelles ou autrement dit les plus fraches ( fresh routes ). Chaque nud possde un numro de squence. Il est le seul habilit lincrmenter. Ce numro personnel ne peut tre incrment que dans deux situations. La premire situation est : Avant dentreprendre un processus de recherche de route par lenvoi dun paquet RREQ, le nud incrmente son numro. La deuxime situation est : Avant de rpondre un message RREQ par un message RREP, le numro de squence doit tre remplac par la valeur maximale entre son numro de squence actuel et celui contenu dans le message RREQ.
-19-
Nouha BACCOUR
Une mise a jour de la table de routage ne seffectue que si lune des conditions suivantes sont observes : Le numro de squence du paquet de contrle est strictement suprieur au numro de squence prsent dans la table. Les numros de squence (de la table et du paquet) sont gaux mais, la distance en hops du paquet plus 1 est infrieure la distance actuelle dans la table de routage. Le numro de squence pour cette destination est inconnu.
Cette faon de procder garantit la cration de route sans boucles. 6.3.3. Dcouverte de route Chaque nud maintient la liste de ses voisins immdiats, soit en utilisant la couche liaison de donnes (L2) ou par lchange priodique de messages HELLO (qui sont des RREP avec un TTL de 1). Quand un nud souhaite obtenir un chemin vers une destination, il diffuse ses voisins immdiats un message RREQ (figure 1.8.a), celui-ci contient le dernier numro de squence connu pour cette destination. Ce message est diffus par rmissions successives par les diffrents nuds transitoires. Lorsquun nud reoit un RREQ deux cas se prsentent : Sil est la destination (Figure 1.8.c), ou sil possde une route vers la destination avec un numro de squence suprieur ou gal celui repris dans le RREQ (Figure 1.8.d) il envoie (en unicast) un paquet RREP vers la source. Chaque nud travers incrmentera le nombre de hops et ajoutera une entre sa table pour la destination. Un chemin bidirectionnel est donc dsormais disponible entre la source et la destination. Dans le cas contraire il rediffuse le RREQ (Figure 1.8.a) et met jour linformation relative la source et tablit des pointeurs de retour vers la source du RREQ dans les tables de routage (figure 1.8.b). Chaque nud conserve une trace des IP sources et des ID de broadcast des RREQ. Sils reoivent un RREQ qu'ils ont dj trait, ils l'cartent et ne le transmettent pas. Donc, dans AODV, on limine les paquets redondants grce leur ID identiques. Une fois que la source a reu les RREP, elle peut commencer mettre des paquets de donnes vers la destination. Si, ultrieurement, la source reoit un RREP contenant un numro de squence suprieur ou le mme mais avec un nombre de saut plus petit, elle mettra jour son information de routage vers cette destination et commencera utiliser la meilleure route. Afin de limiter le cot dans le rseau, AODV propose dtendre la recherche progressivement. Initialement, la requte est diffuse un nombre de sauts limit. Si la
-20-
Nouha BACCOUR
source ne reoit aucune rponse aprs un dlai dattente dtermin, elle retransmet un autre message de recherche en augmentant le nombre de sauts maximum. En cas de nonrponse, cette procdure est rpte un nombre maximum de fois avant de dclarer que cette destination est injoignable.
a.. Propagation du paquet RREQ
b. Formation de chemin inverse
DSN=12 DSN=11
c. Formation du chemin bidirectionnel vers la source
d. Formation du chemin bidirectionnel vers la source
Figure 1.8. Les tapes de la dcouverte de route 6.3.4. Maintenance de route Afin de maintenir des routes consistantes, une transmission priodique du message HELLO est effectue. Si trois messages HELLO ne sont pas reus conscutivement partir d'un nud voisin, le lien en question est considr dfaillant. Les dfaillances des liens sont, gnralement, d la mobilit du rseau ad hoc. Les mouvements des nuds qui ne participent pas dans le chemin actif, naffectent pas la consistance des donnes de routage.
-21-
Nouha BACCOUR
Soit lexemple illustratif de la figure 1.9 ; Le nud 2 voulant transmettre de linformation au nud 13. La phase de dcouverte de route a t dj faite et le nud source commence envoyer des paquets de donnes travers le chemin indiqu dans la Figure 1.9.a. Quand un lien, reliant le nud 5 avec le nud qui le suit dans le chemin de routage, cest--dire le nud 7, devient dfaillant, le nud 5 diffuse un paquet RERR Route ERROR , avec une valeur de numro de squence gale l'ancienne valeur du paquet RREP incrmente de un, et une valeur infinie de la distance (Figure 1.9.b). Le paquet derreur est diffus aux voisins actifs, jusqu' ce qu'il arrive la source, le nud 2. Une fois le paquet est reu, la source peut initier le processus de la dcouverte de routes(Figure 1.9.c).
-22-
Nouha BACCOUR
Route_Error(RERR):
Dest. N Dest. 13 1 4,3,2,1 2 13 squence Distance Source Dest. N Dest. 2 INF squence Distance
a. Le chemin dacheminement de paquets
b. La diffusion du RERR par le nud 5
Route_Request(RREQ) :
RREQ_id Source 1234 2 N squence Source 50 Dest. N squence Dest. 13 2 Distance 0
c.Initialisation du processus de dcouverte de route
Figure 1.9. Le processus de maintenance de route dans AODV
AODV maintient les adresses des voisins travers lesquels les paquets destins un nud donn transitent. Un voisin est considr actif, pour une destination donne, s'il dlivre au moins un paquet de donne sans dpasser une certaine priode appele active timeout period . Une entre de la table du routage est active, si elle est utilise par un voisin actif. Le chemin reliant la source et la destination en passant par les entres actives des tables de routage, est dit un chemin actif. Dans le cas de dfaillances de liens, toutes les entres des tables de routage participantes dans le chemin actif et qui sont concernes par
-23-
Nouha BACCOUR
la dfaillance sont supprimes. Cela est accompli par la diffusion d'un message d'erreur entre les nuds actifs. Le protocole de routage AODV n'assure pas l'utilisation du meilleur chemin existant entre la source et la destination. Cependant, des valuations de performances rcentes ont montr qu'il n'y a pas de grandes diffrences (en terme d'optimisation) entre les chemins utiliss par le protocole AODV et ceux utiliss par les protocoles bass sur les algorithmes de recherche des plus courts chemins [COR 99]. En plus de cela, le protocole AODV ne prsente pas de boucle de routage et vite le problme counting to infinity de Bellman-Ford, ce qui offre une convergence rapide quand la topologie du rseau Ad hoc change.
6.4. Le protocole OLSR (Optimised Link State Routing protocol) OLSR [JAC 03] est un protocole proactif tat de liens. Afin de maintenir jour les tables de routage, chaque nud implmentant OLSR diffuse rgulirement des informations sur son propre voisinage. Ces informations sont suffisantes pour permettre chaque nud de reconstruire une image du rseau et de trouver une route vers nimporte quelle destination. Mais contrairement des protocoles tels quOSPF, cette diffusion ne se fait pas par une simple inondation (o chaque nud retransmet simplement chaque nouveau paquet quil reoit) ; OLSR optimise la diffusion grce au systme des relais multi-points (Multi-Points Relays : MPR). Chaque nud choisit dans ses voisins directs un sous-ensemble minimal de nuds qui lui permettent datteindre tous ses voisins deux sauts (figure 1.10). La diffusion des informations sur les liens utiliss pour le routage se fait ensuite uniquement par les relais multi-points ; la couverture totale du rseau est assure tout en limitant sensiblement le nombre de r-missions. Afin de choisir ses relais multi-points, un nud a besoin de connatre compltement la topologie de son voisinage deux sauts ; cela est ralis grce lenvoi priodique de paquets hello contenant la liste des voisins connus un saut.
-24-
Nouha BACCOUR
MPR
source
MPR
MPR
Figure 1.10. Relais multipoints
6.5. Le protocole ZRP (Zone Routing Protocol) ZRP [PEA 99] est un protocole hybride dun protocole ractif et dun protocole proactif. Chaque nud dfinit une zone autour de lui dans laquelle il va utiliser son protocole proactif. Le protocole proactif en lui-mme nest pas impos par ZRP, et en principe, il peut tre tout type de protocole proactif. La zone du nud est limite en nombre de sauts entre le centre et les nuds de la frontire. Autrement dit, un nud appartient la zone sil est x sauts au maximum du nud central. Les nuds qui se trouvent la limite de cette zone sont appels les nuds priphriques. Lorsquun nud veut en joindre un autre, il regarde tout dabord sil est dans sa zone ou non. Sil est prsent dans sa zone, alors la route est connue et disponible immdiatement grce au protocole proactif ; sinon, une requte est envoye aux nuds priphriques qui leur tour regardent si le nud rechercher appartient leurs zones respectives. Si cest le cas, une rponse est renvoye la source. Dans le cas contraire, le processus se poursuit de la mme faon jusqu trouver le nud en question. Une rponse est alors formule et renvoye la source. Chaque nud maintient une liste des requtes traites de manire viter les doublons qui seront dtruits.
-25-
Nouha BACCOUR
6.6. Conclusion Dans cette section, nous avons prsent quelques protocoles de routage qui ont t proposs pour assurer le service de routage dans les rseaux mobiles ad hoc. Comme nous avons vu, les protocoles proposs sont classs en deux catgories : les protocoles pro-actifs les protocoles ractifs et les protocoles hybrides. Les protocoles de ces catgories essaient de s'adapter aux contraintes imposes par le rseau ad hoc, et cela en proposant une mthode qui soit de moindre cot en capacits et ressources, et qui garantit la survie du routage en cas de n'importe quelle panne de lien ou de nud. Les protocoles de routage prsents offrent diffrents avantages qui sont en ralit complmentaires et prfrables pour diffrents types d'applications. Lutilisation dune solution ou autre dpendra de lapplication souhaite. Dans notre tude, nous avons choisi le protocole AODV dans la ralisation des simulations. En effet, uniquement les protocoles AODV et DSR sont implments par les deux simulateurs la fois. Le choix du protocole AODV tait arbitraire parce que le but de cette tude nest pas lvaluation des protocoles de routages pour les rseaux ad hoc, mais la comparaison entre deux simulateurs. Les protocoles de routage, comme tous constituants des rseaux ad hoc doivent tre valus avant dtre utiliss dans de vrais rseaux ad hoc.
7. Mesure de performances Les constituants des rseaux ad hoc, savoir les protocoles, les applications ou la modlisation du rseau, doivent tre valus afin de mesurer les performances de la stratgie utilise et de tester sa fiabilit. L'utilisation d'un rseau ad hoc rel dans une valuation est difficile et coteuse, en outre de telles valuations ne donnent pas gnralement des rsultats significatifs. Le rseau rel n'offre pas la souplesse de varier les diffrents paramtres de l'environnement et pose en plus le problme d'extraction de rsultats; c'est pour cela la majorit des travaux d'valuation de performances utilisent le principe de simulation vu les avantages qu'il offre. En effet, la simulation permet de tester les protocoles sous une varit de conditions. Le simulateur, qui constitue une plate-forme construite avec un certain langage, permet de varier les diffrents facteurs de l'environnement tel que le nombre d'units mobiles, l'ensemble des units en mouvement, les vitesses des mouvements, le territoire du rseau et la distribution des units dans ce territoire.
-26-
Nouha BACCOUR
Cependant, des tudes ultrieures[20][21][22] ont montr des divergences constatables en comparant les rsultats de simulation donns par les simulateurs. Ces constatations mettent en question la fiabilit des simulateurs et obligent les chercheurs de prendre les prcautions ncessaires lors du choix du simulateur. En conclusion, pour valuer la performance dun protocole ou dun systme, il est peut tre plus prudent de raliser les simulations avec plusieurs simulateurs pour avoir plus de sret dans les rsultats de simulations. En revanche, lvaluation la plus exacte et la plus fiable est celle avec un rseau ad hoc rel.
8. Conclusion Dans ce chapitre, nous avons prsent les environnements mobiles et en particulier le concept des rseaux ad hoc. Nous avons vu galement la ncessit dvaluer les performances des rseaux ad hoc par des simulations. NCTUns permet de simuler les rseaux mobiles ad hoc, il prsente un ensemble davantages. Dans le chapitre suivant, nous allons valuer le simulateur NCTUns en menant une comparaison prliminaire ou qualitative entre ce simulateur et un simulateur populaire intitul GloMoSim.
-27-
Nouha BACCOUR
1. Introduction Une simulation consiste reprsenter par un programme informatique un rseau, et un scnario dutilisation de ce rseau afin de recueillir des statistiques. Ces statistiques permettent dvaluer les performances dun systme ou dun protocole avant que ce dernier ne soit rellement construit ou effectivement dploy dans un rseau. Les diffrentes parties dun programme de simulation sont les suivantes : La spcification du systme simuler (lments dun rseau, description des protocoles mis en jeu) ; La spcification des types de trafic devant circuler sur le rseau, les sources , les puits , les caractristiques des flux en terme de trafic, ventuellement les chemins devant tre suivis par ces flux ; Le scnario simul (quand dbute lactivit de chaque source, quand elle se termine; modifications ventuelles des caractristiques de ces sources) ; Les outils de recueil dinformations et de visualisation des rsultats. Les rsultats de lexcution du programme de simulation sont donc enregistrs dans une trace, qui peut tre analyse (soit en cours de simulation, soit posteriori). Dans cette tude, nous nous intressons en particulier la simulation des rseaux sans-fil ad hoc. Actuellement, il existe plusieurs simulateurs de rseau tel que NS [site 3], GloMoSim [site 2], Opnet [site 4] et rcemment NCTUns [site 5]. Ces simulateurs se basent sur diffrents modles pour mesurer les diffrentes couches du modle OSI. Dans ce chapitre, aprs la prsentation des deux simulateurs qui sont NCTUns (version 2.0) et GloMoSim (version 2.03), nous menons une comparaison qualitative entre ces deux simulateurs.
2. NCTUns (National Chiao Tung University network simulator)
2.1.
Prsentation gnrale NCTUns est un simulateur et mulateur de rseau filaire et sans-fil. Il est
dvelopp par Prof. S.Y. Wang NCTU (National Chiao Tung University) taiwan. NCTUns est une proprit intellectuelle du laboratoire NSL (Network and System Laboratory), dpartement dinformatique et dingnierie de linformation NCTU.
-29-
Nouha BACCOUR
NCTUns est un outil qui fournit une interface graphique pour lutilisateur (GUI) crite en C++ avec la bibliothque QT. La premire publication de NCTUns tait le 1er novembre 2002. depuis sa dernire publication : Le 16 fvrier 2005, plus que 2.745 personnes de 80 pays dans le monde ont t inscrit son site web (http://nsl.csie.nctu.edu.tw/nctuns.html) et l'ont tlcharg. Site web Version Licence http://nsl.csie.nctu.edu.tw/nctuns.html Sa dernire version est NCTUns 2.0 qui est sortie le 16 fvrier 2005. Peut tre tlcharg gratuitement partir du site web de NCTUns. La modification des sources est autorise pour des raisons non commerciales (Open-source). Il ncessite les caractristiques-systme suivantes : CPU : 1.6 GHz. RAM : 256 Mo (512Mo dans le cas de grands). Espace disque libre : 300 Mo. Cette version a t teste sur le systme dexploitation Linux avec la version Fedora 2.0 de Red Hat. Se trouve sur le lien suivant : http://nsl10.csie.nctu.edu.tw/support/documentation/ Cette page contient un ensemble de manuels, des diapositives de prsentation et des dmonstrations en vido de format .avi nctuns-announcement@nsl10.csie.nctu.edu.tw nctuns-announcement annonce les dernires nouvelles de NCTUns. nctuns@nsl10.csie.nctu.edu.tw nctuns fournit un mailing group qui assure la discussion entre ses utilisateurs. 258 pages contenant le mot nctuns Tableau 2.1. NCTUns 2.0
Systme
Documentation
Mailing-list
Pages Google au 20/03/2005
2.2.
Avantages NCTUns [WAN 05] est un mulateur et simulateur de rseau. Il nest pas si
populaire par rapport GloMoSim. En revanche, il prsente plusieurs avantages : Il utilise un ensemble de protocoles qui sont qualifis real-life . Outre, toute application UNIX existante ou dveloppe peut tre utilise directement dans le rseau simul. Tout outil de configuration rseau UNIX (e.g., route, ifconfig, netstat) ou de mesure de performance (e.g., tcpdump, traceroute) peut tre exploit dans la simulation. A titre dexemple, tcpdump permet de mesurer les paquets qui se dplacent sur un lien, et traceroute permet de trouver le chemin parcouru par un paquet. Ainsi, les rsultats de simulation seront plus ralistes ; -30-
Nouha BACCOUR
Il supporte plusieurs types de rseaux (e.g. rseau filaire, rseau sans-fil), ainsi que plusieurs types de liens et dquipements rseau (tableau 2.2) ;
quipement Lien Optique WDM Point point Lien Point point Comme Ethernet Terminal Hub Switch Routeur Nuage WAN Subnet (sous-rseau) Routeur de frontire en QoS DiffServ Station de base GPRS tlphone GPRS Pseudo Switch GPRS Wall (signal obstacle) IEEE 802.11 (b) station Mobile (rseau ad hoc) IEEE 802.11 (b) station Mobile (rseau avec infrastructure) IEEE 802.11 (b) point daccs
Icne acronyme
(GUI)
Spcification technologique Pour les rseaux optiques Pour les rseaux filaires Pour les rseaux filaires Pour les rseaux filaires Pour les rseaux filaires Pour les rseaux filaires Pour les rseaux filaires Pour les rseaux filaires. ensemble dhtes lis un Switch Pour les rseaux filaires Station de base dans un rseau cellulaire GPRS Tlphone dans un rseau cellulaire GPRS Pseudo Switch dans un rseau cellulaire GPRS Pour les rseaux sans-fil (bloquer la propagation du signal) Pour les rseaux sans-fil (ad hoc). Pour les rseaux sans-fil (avec infrastructure). Pour les rseaux sans-fil (avec infrastructure).
WDMLINK PPL HOST HUB SWITCH ROUTER WAN SUBNET BROUTER GPRSBS GPRSPHONE GPRSPS WALL MNODE MNODE_INFRA AP
Tableau 2.2. Des quipements rseau simuls par NCTUns 2.0
Il supporte les simulations concurrentes et distance grce son architecture distribue ; La ralisation du rseau simul comme les mesures de performance est facile et intuitive grce lenvironnement graphique GUI.
-31-
Nouha BACCOUR
2.3.
Inconvnients A travers les simulations ralises avec ce simulateur, plusieurs dfauts ont t
constats : La connexion travers lexpditeur (dispatcher en anglais) avec le serveur de simulation nest pas stable. En effet, il est frquent que le coordinateur (coordinator en anglais) devient occup. Dans ce cas, il notifie son tat au dispatcher . Ce dernier sera incapable de choisir la machine de simulation convenable dou lapparition du message no idle server . Par consquent il faut tout redmarrer (le coordinator, le dispatcher et le client) ; Le cot programmation est absent. Lutilisateur est trs li lenvironnement graphique. Parmi les consquences: la manipulation des modules de protocoles associs chaque nud ne peut se faire que soit individuellement soit pour tous les nuds la fois ; Pour excuter la simulation, il est ncessaire de faire participer lenvironnement graphique GUI . Ainsi, la simulation sera un peut lente, surtout dans le cas de simulation de rseaux qui prsentent un grand nombre de nuds.
2.4.
Architecture NCTUns [WAN 05] possde une architecture distribue afin quil supporte les
simulations distance et les simulations concurrentes. Il possde aussi une architecture flexible car il y a possibilit dajouter un module de protocole. Son architecture peut tre subdivise en huit composants (Figure2.1).
-32-
Nouha BACCOUR
Figure 2.1. les composants de larchitecture de NCTUns Environnement GUI Client : Le programme GUI communique directement avec le job Dispatcher. Pour assurer cette communication on doit prciser dans le menu Preference le port (par dfaut 9800) et ladresse IP (de la machine de simulation qui peut tre locale ou distante) utilise par le dispatcher. GUI veut dire interface graphique utilisateur [WAN 03]. Cet environnement graphique peut tre subdivis en cinq composants :
Topology Editor Editeur de topologie de rseau sans-fil et de rseau cbl.
-33-
Nouha BACCOUR
Network Node Attributes Specification Spcification des Attributs dun nud : par exemple le chemin travers par un nud mobile dans un rseau mobile ad hoc.
Performance Monitor Moniteur de performance : dessiner des courbes de mesure de performance du rseau simul. Par exemple tracer la courbe qui mesure le dbit accompli dune connexion TCP en fonction du temps.
Node editor Lditeur du nud sert spcifier les protocoles des couches physique, liaison de donne, rseau, transport et application.
Packet Animation Player Aprs lexcution de la simulation le Packet Animation Player permet de visualiser la trace du transfert des paquets dans le rseau simul avec la vitesse choisie. Cette trace est journalise dans un fichier log.
Tableau 2.3. Des quipements rseau simuls par NCTUns 2.0
Moteur de simulation : Le moteur de simulation Simulation Engine fournit des services aux modules de protocoles. Le Simulation Engine doit tre compil avec les
-34-
Nouha BACCOUR
diffrents modules de protocoles pour former le Simulation Server . Le serveur de simulation reoit comme entre des fichiers contenant la description de la simulation (de point de vue topologie, caractristiques des nuds, dure de la simulation etc.) et gnre comme sortie des fichiers trace qui journalisent les dtails du transfert de paquets. Modules de protocoles : Chaque module implmente un protocole ou une fonction. Par exemple le protocole ARP, la file FIFO sont deux modules de protocoles. Expditeur de taches : Le fonctionnement [WAN 03] de lexpditeur de taches Job Dispatcher explique le fait que larchitecture de NCTUns est une architecture distribue : La figure 2.2 montre que le dispatcher peut grer des simulations concurrentes sur plusieurs machines de simulations qui peuvent tre distantes. Chaque programme GUI envoie sa demande (une description de la simulation sous forme de fichier) une machine de simulation distante travers le Job Dispatcher pour lexcuter. Aprs avoir excut la simulation, les rsultats de simulation et les fichiers trace sont retourns au client GUI. Le Dispatcher va grer toutes les demandes laide dune file dattente.
Figure 2.2. larchitecture distribue de NCTUns Coordinateur : Le coordinateur coordinator est un processus qui fait partie dune machine de simulation bien dtermine. Son principal rle est dinformer le dispatcher si la machine est en train dexcuter une simulation (occupe) ou pas. Le dispatcher ne peut pas accder une machine occupe pour lui assigner une tche.
-35-
Nouha BACCOUR
Modifications du noyau : Ensemble de modifications du kernel (le kernel de Fedora 2.0 est Linux 2.6.5) de la machine de simulation Kernel Patches . Ces modifications permettent au processus serveur de simulation de sexcuter correctement sur une machine UNIX. Serveur de protocoles : Les serveurs ou dmons de protocoles Protocol Daemons prsentent un ensemble de programmes comme le dmon de routage routed ou gated . Applications : Elles Permettent de gnrer et contrler le trafic de rseau, configurer les nuds etc. (e.g. ttcp, rtg)
2.5.
Droulement de la simulation Lenvironnement graphique GUI est une interface utilisateur qui lui permet de
dcrire une simulation. En effet il peut diter la topologie du rseau simuler (le mode Edit topology ). Ensuite il peut aussi diter la proprit de chaque nud en prcisant par exemple les protocoles simuls des couches, le flux de donnes transmettre etc. (il sagit du mode Edit property ). Le programme du GUI enregistre la topologie dans un fichier binaire .tpl . (Dans la suite on suppose que les processus Dispatcher et Coordinateur sont lancs) Ensuite, avec le mode Run simulation , le programme du GUI va gnrer un ensemble de fichiers qui dcrivent les paramtres de la simulation. Ces fichiers sont stocks dans un rpertoire qui a pour suffixe .sim (exemple test.sim). Ce rpertoire inclut en particulier les deux fichiers .tcl et . tfc . Le premier contient linitialisation des variables globales, la description des diffrents protocoles des couches simules et la connectivit des diffrents nuds. Le second contient la description de trafic gnr. En plus du rpertoire .sim il y a cration du rpertoire qui a pour suffixe .result . Enfin on passe lexcution effective de la simulation, le serveur de simulation simulation sever va utiliser les fichiers du rpertoire .sim comme entre pour excuter la simulation et fournir en sortie des fichiers log qui reprsentent les rsultats de la simulation. Le serveur de simulation va envoyer ces fichiers au programme GUI qui va les stocker dans son rpertoire .result et passer automatiquement au mode Play Back .
-36-
Nouha BACCOUR
3. GloMoSim (Global Mobile information system Simulator)
3.1.
Prsentation gnrale GloMoSim [site 1] est un environnement de simulation pour les rseaux sans-fil de
grande taille. Il a t dvelopp par le PCL (Laboratoire de Calcul Parallle) de lUCLA (Universit de Californie Los Angeles) dans le cadre du projet DARPA GLOMO (GLObal MObil information system). Glomosim a donn suite Qualnet, le simulateur commercial de lentreprise Scalable Network affilie lUCLA. GloMoSim sappuie sur lenvironnement PARSEC (Parallel Simulation Environment for Complex systems) qui est un environnement de simulation pour lexcution squentielle ou parallle de modles de simulation vnements discrets. Parsec est dvelopp par le PCL de UCLA. Il est bas sur le C-ANSI, avec quelques possibilits supplmentaires hrites du C++. Parsec introduit les notions dentits (blocs autonomes qui peuvent sexcuter en parallle) et de messages entre ces entits, ce qui est trs utile pour les simulations de nuds schangeant des informations.
Site web Version Licence Systme Documentation Mailing-list Pages Google au 18/ 04/2005
http://pcl.cs.ucla.edu/projects/glomosim/ La dernire version de GloMoSim est 2.03 qui est diffuse en dcembre 2000 Gratuit pour le domaine universitaire, Modification des sources autorise pour le domaine universitaire Linux, Windows Le manuel utilisateur est trs peu fourni. Il est accessible en ligne sur le site avec la documentation annexe (slides, tutoriaux et publications) Elle est maintenue par lUCLA. On sy souscrit lors de la phase denregistrement pour lobtention de Glomosim, ou simplement en visitant ce lien : http://lists.ucla.edu/cgi-bin/mailman/listinfo/glomosim-users-l 6650 pages contiennent le mot glomosim Tableau 2.4. GloMoSim 2.03
3.2.
Avantages Le simulateur GloMoSim a t dvelopp pour atteindre les objectifs suivants : Faciliter la scalabilit de la simulation pour pouvoir simuler des rseaux avec
jusqu' cent mille nuds, ce ci grce lexcution parallle de la simulation et les notions de Node Aggregation et Layer Aggregation , ce qui rduit considrablement le
-37-
Nouha BACCOUR
temps de l'excution du modle de simulation. Le pouvoir de scalabilit est illustr dans la figure 2.3. Supporter des communications htrognes entre les nuds. Ces communications incluent les communications en multicast, les communications asymtriques qui utilisent la diffusion par satellite, les communications sans-fil multi-hop utilises dans le rseau ad hoc etc.
Figure 2.3. Temps de lexcution de la simulation en variant le nombre de nuds
Pour atteindre la scalabilit voulu cest dire pour pouvoir simuler un grand rseau dont le nombre de nuds peut atteindre jusqu' un million, GloMoSim utilise les deux techniques suivantes : Agrgation des nuds [site 2] : Parsec utilise une approche qui consiste considrer chaque nud du rseau comme tant une entit. Cette approche prsente des problmes de passage une grande chelle. Pour rsoudre ces problmes, GloMoSim utilise la notion de Node Aggregation . Cette approche consiste simuler un ensemble de nuds reprsentant une surface gographique de simulation, par une unique entit. Ce ci implique que le nombre de nuds peut crotre sans augmenter le nombre dentits. La seule contrainte est que la machine qui excute la simulation doit avoir autant de processeurs que dentits. Par consquent, une excution squentielle de la simulation ncessite une seule entit.
-38-
Nouha BACCOUR
Agrgation des couches [site 2] : Pour les mmes raisons vues prcdemment, GloMoSim reprsente les couches par une unique entit au lieu de reprsenter chaque couche par une entit
3.3.
Inconvnients Le simulateur GloMoSim est considr comme lun des simulateurs populaires. Il a
t test par plusieurs scientifiques. En revanche, Il prsente des inconvnients. Parmi ces inconvnients on peut citer le fait que la communaut de dveloppement du simulateur nest pas trs dynamique. En effet les mises jour de GloMoSim ne sont pas rgulires. La dernire mise jour tait en 2003. Outre, GloMoSim est conu pour utiliser la capacit de lexcution parallle de la simulation vnement discret fournie par PARSEC [site 1]. Ce ci constitue le point fort dans larchitecture de GloMoSim. En revanche, la version actuelle de GloMoSim supporte uniquement une excution squentielle de la simulation et par suite utilise une seule partition[site 2]. Par contre, la version commerciale de GloMoSim (QualNet) exploite le paralllisme.
3.4.
Architecture La plupart des rseaux actuels sont construits sous une approche en couche,
similaire aux sept couches du modle OSI. Cest pourquoi GloMoSim est conu pour utiliser une approche de structuration en couches. Plus prcisment, GloMoSim est une bibliothque de modules, chaque module simule un protocole de communication sans-fil spcifique de la pile de protocoles (figure 2.4). Des fonctions standards (API) assurent les communications (change de services) entre ces diffrentes couches [BAJ 00].
-39-
Nouha BACCOUR
Rseau Application/ Gnrateur de trafic Transport Layer :TCP,UDP,RTP IP, Mobile IP Wireless Network Layer : VC support Wireless Network Layer : routing Clustering (optionnel) Data Link MAC
Radio Model Propagation Model/Mobility Model
Figure 2.4. Arborescence du package GloMoSim La bibliothque GloMoSim est dveloppe en utilisant Parsec. Elle se prsente sous forme de 207 fichiers .pc (parsec) et .h (header) organiss en couches et des fonctions standards. Ce choix a t fait pour permettre une intgration rapide de modles dvelopps dans des couches diffrentes, par des groupes de travail diffrents. Les
protocoles supplmentaires peuvent tre ajouts cette bibliothque. En effet GloMoSim 2.03 est structur comme suit : glomosim-2.03 /main contiennent les fichiers .pc et .h ncessaires au fonctionnement /include du simulateur. /bin contient des fichiers excutables et des fichier de configuration /doc documentation sur GloMoSim /application /transport Contiennent les fichiers .pc , .h .c et .cpp . /network reprsentant les diffrentes couches simules /mac /radio /scenarios des exemples de scnarii /java_gui ....des classes java qui constituent loutil de visualisation de la simulation
-40-
Nouha BACCOUR
./bin /config.in /nodes.input /app.conf /mobility.in /ber_bpsk.in / glomo.stat Figure 2.5. Arborescence du package GloMoSim
Le
fichier
./config.in
prend
les
paramtres
partir
des
fichiers
./nodes.input , ./app.conf , ./mobility.in , ./ber_bpsk.in et Glomosim crit les rsultats de simulation dans le fichier glomo.stat . Fonctionnement sommaire de GloMoSim : Lorsque le code du simulateur est compil, GloMoSim se prsente sous forme dun fichier excutable. Celui-ci prend en argument un fichier de configuration de la simulation (il suffit de taper ./glomosim config.in ). En fait, une entit Driver est cre. Celle-ci lit les informations dans le fichier config.in et les transmet lentit GLOMO Partition . Cette entit initialise les couches et ensuite lance la simulation. La simulation se droule ensuite sous forme de messages. Lentit reoit un message dune couche dun nud et lenvoie la couche dun autre nud. Par exemple, si la couche network dun nud veut envoyer un paquet sa couche MAC, le message arrive lentitGLOMO Partition, qui le transmet ensuite la couche MAC. Il en va de mme pour les messages entre nuds, qui se droulent entre couches radio. (figure 2.6)
-41-
Nouha BACCOUR
Figure 2.6. Les principales entits de Glomosim
3.5.
Droulement de la simulation Lutilisateur saisit les paramtres de la simulation dans deux fichiers de
configuration texte : app.conf & config.in . Le premier contient les paramtres relatifs la couche applicative (quelles sont les applications excutes, quel moment, avec quel dbit). Le second contient la description : Des couches PHY, MAC, rseau & transport ; Du canal radio ; Des scnarios de mobilit ; De lenvironnement (terrain, nombre de nuds.) ; De la dure de la simulation ; Du type de statistiques remonter. Des statistiques sont disponibles pour Les trois premiers points, Le niveau applicatif. Glomosim dispose dune interface graphique java rudimentaire pour laffichage des dimensions du terrain, des communications radios et de la mobilit des nuds. Les statistiques remonter sont stockes dans un fichier texte (glomo.stat).
-42-
Nouha BACCOUR
4. Etude comparative Dans cette section, nous allons mener une comparaison entre les deux simulateurs en ce qui concerne le paramtrage des simulations et les modles implments dans : Lemplacement des nuds, Le scnario de mobilit, Terrain physique, Gnration de trafic, Modules de protocoles implments. Nous dfinissons en premier lieu les modles, ensuite un tableau comparatif montre les similitudes et les diffrences entre les simulateurs dans limplmentation de ces modles.
4.1. Placement des nuds - Random : les nuds sont placs alatoirement sur le terrain physique (les dimensions du terrain sont prcises par lutilisateur). - Uniform : en se basant sur le nombre de nuds, le terrain est divis en cellules. Dans chaque cellule, un nud est plac alatoirement. - Grid : le premier nud se place une position bien dtermine. Les autres nuds sont placs en ordre des distances gales pour former une sorte de grille. Lutilisateur prcise toutes les informations ncessaires pour pouvoir construire cette grille. - A partir dun fichier : un fichier contient lemplacement de chaque nud. - Manuellement : laide dun environnement graphique, en utilisant le glisser poser . Random Uniform Grid A partir dun fichier Manuellement NCTUns X X X X GloMoSim X X X X
Tableau 2.5. Comparatif entre NCTUns et GloMoSim dans le placement des nuds
On note que le modle Grid de NCTUns est plus riche que celui de GloMoSim. En effet, GloMoSim exige un nombre carr de nuds pour son implmentation du modle. Par contre NCTUns implmente le modle avec nimporte quel nombre de nuds.
-43-
Nouha BACCOUR
4.2.
Scnario de mobilit
- Aucun : les nuds sont fixes - Random waypoint : Le nud choisit alatoirement une destination sur le terrain de et sy rend avec une vitesse moyenne choisie. Lorsqu'il atteint sa destination, le nud fait une pause. Cette procdure se rpte jusqu la fin de la simulation. - Fichier de trace : la trajectoire des mobiles est extraite dun fichier de trace. Cette mthode permet ainsi de dcentraliser limplmentation des modles lextrieur du simulateur. - Random drunken : si un nud se trouve la position (x,y) linstant t, sa position linstant suivant est tire dans {(x-1, y), (x+1, y), (x, y-1), (x, y+1)}. Le dplacement est conditionn par le non-dpassement du terrain physique. Aucun Random waypoint Fichier de trace Random drunken NCTUns X X GloMoSim X X X X
Tableau 2.6. Comparatif entre NCTUns et GloMoSim dans le Scnario de mobilit
Avec NCTUns on peut prciser pour un nud donn, un point de dpart, un point de darrive, le temps du commencement du dplacement et la vitesse (en m/s) pour atteindre cette destination. Avec GloMoSim ce ci nest pas possible car pour dfinir un chemin de mobilit dun nud, on dfinit un point de dpart, un point de darrive et le temps de latteinte de la destination. Cest GloMoSim qui spcifie une vitesse constante pour atteindre la destination au temps spcifi.
4.3. Terrain physique - Flat grid : une grille plate donnant les dimensions du terrain. - Une topographie tridimensionnelle. Un plan bitmap : le terrain peut indiquer la prsence dobstacles en plus il peut intgrer une image comme arrire plan tel quune carte.
-44-
Nouha BACCOUR
Flat grid
Une topographie tridimensionnelle Un plan bitmap
NCTUns X X X
GloMoSim X
Tableau 2.7. Comparatif entre NCTUns et GloMoSim dans le modle du terrain physique
4.4.
Gnration de trafic
- A partir dun fichier : dtermine les sources, les puits, le type du flux qui transite entre eux avec les paramtres ncessaires pour dcrire ce flux comme par exemple le temps du commencement du trafic, la taille des paquets envoyer etc. - Manuellement : a laide de loutil graphique on accde chaque nud individuellement pour le configurer. A partir dun fichier Manuellement NCTUns X X GloMoSim X
Tableau 2.8. Comparatif entre NCTUns et GloMoSim La gnration du trafique
4.5. Modules implments Chacun des simulateurs NCTUns et GloMoSim implmente un ensemble de modules. Chaque module prsente un protocole ou un modle qui caractrise une couche donne. Comme le montre le tableau 2.5, les deux simulateurs ne prsentent pas des similitudes dans leurs modules implments. Cette diversit rend la comparaison plus difficile. En effet pour pouvoir comparer le comportement des deux simulateurs, il faut les paramtrer de la mme faon (mme protocoles, mme modles) pour pouvoir par la suite tirer des conclusions. Mais ce qui rassure dans cette situation cest le fait quon peut la plupart des cas trouver des intersections entres les deux simulateurs. Par exemple, on peut utiliser lapplication stg/rtg de NCTUns pour obtenir lapplication CBR implmenter par GloMoSim.
-45-
Nouha BACCOUR
Couche Physique Liaison de donns (Mac)
Rseau (routage)
Transport Application
NCTUns PHY, WPHY, AWPHY Ether, WLANAD, WLANIN, LBP, STP ARP, 2F-BLSR IP, ICMP, OSPF, RIP, FNGRP, DSR, AODV, ADV, DSDV, MNGRP, FIFO, DRR, RED, WAN, DS_I, DS_TC, GPRS, OBS, MIP TCP, UDP, RTP/RTCP, SDP HTTP, FTP, Telnet Tcpdump, Traceroute, Ping, Stcp/rtcp, Ttcp et Stg/rtg
GloMoSim Two ray et Free space CSMA, IEEE 802.11 et MACA IP with AODV, BellmanFord, DSR, Fisheye, LAR scheme 1, ODMRP, WRP
TCP et UDP CBR, FTP, HTTP et Telnet
Tableau 2.9. Ensemble des modules implments par les simulateurs GloMoSim et NCTUns
4.6. Paramtrage des simulations Chacun des simulateurs GloMoSim et NCTUns permet de configurer les
diffrentes couches pour constituer la topologie simuler. Cependant il y a des paramtres communs aux deux simulateurs et des paramtres propres lun des simulateurs. Ce ci rend la comparaison plus difficile. En effet pour comparer les rsultats de simulation fournit par ces simulateurs il faut dcrire la simulation dune faon unique dans les deux simulateurs. Par exemple Glomosim permet de configurer le modle de propagation Radio de la couche physique en donnant le choix entre le modle Two ray et le modle Free space , alors que NCTUns ne donne pas ce choix, il utilise le modle Two ray comme modle par dfaut, cest pourquoi toutes les simulations sont ralises avec ce modle. Dans ce qui suit nous allons prsenter les similitudes et les divergences dans le paramtrages des simulations pour prsenter le degr de flexibilit des deux simulateurs : Paramtres Communs : Temps de simulation, Le nombre SEED, Dimensions du terrain, Nombre de nuds, Placement des nuds, Spcification de la mobilit,
-46-
Nouha BACCOUR
Frquence du canal, Bande passante du lien radio, Puissance de transmission, Gain de lantenne, Puissance minimale du signal reu, Spcification des protocoles des couches MAC rseau transport et application, Spcification du protocole de
routage, Spcification des statistiques. Paramtres propres GloMoSim : Limite de propagation, Modle de propagation, Le brui dans lenvironnement, Temprature de lenvironnement, modle radio pour la transmission / rception des paquets, Puissance de rception, Utiliser ou pas GUI (il peut excuter la simulation et fournir les statistiques sans le GUI ), Model de rception des paquets. Paramtres propres NCTUns : Initialiser quelques variables utilises dans limplmentation du protocole de routage, Initialiser quelques variables utilises dans limplmentation du de la couche MAC (eg RTS thesthold), Les portes de transmission et dinterfrence, Mettre un lien radio invalide, Les statistiques par nud unique.
5. Conclusion Dans ce chapitre, nous avons tout dabord prsent les capacits des deux simulateurs NCTUns et GloMoSim. Ensuite, une comparaison qualitative a t mene. Cette comparaison permet de spcifier les ressemblances et les diffrences entre les deux simulateurs, dans la ralisation des simulations (placement des nuds, mobilit, terrain physique, gnration de trafic, paramtres de configuration de la simulation) et dans les modules de protocoles implments. Cette comparaison qualitative servira dhypothse pour la ralisation de la comparaison quantitative. Cest lobjectif du chapitre suivant qui consiste a raliser quelques scnarii pour tirer une comparaison entre les deux simulateurs en terme de rsultats et de temps de simulation.
-47-
Nouha BACCOUR
1. Introduction Dans le chapitre prcdent, la comparaison entre NCTUns et GloMoSim est thorique. Cette comparaison ne suffit pas pour mesurer les performances de NCTUns. En effet, pour valuer ce simulateur, il est ncessaire de passer lexprimentation en ralisant un ensemble de scnarii avec les deux simulateurs. Ensuite, la comparaison est faite en terme de rsultats et de temps de simulation. Les expriences ralises dans ce chapitre sont de plus en plus complexes. Nous commenons dabord par tester les caractristiques suivantes : la porte de transmission, laccs au canal radio et le routage. Enfin, nous testons essentiellement la scalabilit ou le passage lchelle.
2. Paramtres de simulation Dans les scnarii que nous avons ralis, un ensemble de paramtres communs aux deux simulateurs est fix. Ces paramtres sont rcapituls dans le tableau suivant : Paramtre Modle de propagation Radio Couche MAC Protocole de routage Couche transport Type du trafic gnr Dbit du trafic Taille paquet Bande passante du lien radio Porte de transmission Valeur Tow Ray Ground IEEE 802.11b, DCF AODV UDP CBR 200 paquets/seconde 512 octets 11 Mbits/s 250 mtres
Tableau 3.1. Paramtres communs aux scnarii Le modle de propagation Tow Ray Ground est choisi parce quil constitue le modle pris par dfaut par NCTUns. La couche MAC est implmente selon la norme IEEE 802.11b. En particulier, le mcanisme daccs utilis dans cette couche est la mthode DFC (Distributed Coordination
-49-
Nouha BACCOUR
Function) qui est typiquement le mcanisme CSMA/CA (Carrier Sense Multiple Access With Collision Avoidance). La norme IEEE 802.11b opre des dbits compris entre 1 et 11 Mbits/s. La variation de dbits dpend de la qualit de lenvironnement radio (interfrences, obstacles, distances entre quipements,). AODV est choisi comme protocole de routage puisquil est implment par les deux simulateurs. Le dbit du trafic ainsi que la taille des paquets ont t slectionns, car daprs des tudes antrieures comme [BRA 97], nous avons de meilleurs rsultats avec ces choix. Le flux CBR est choisi vu quil est simple. Il est caractris par un dbit constant et typiquement utilis par les applications vido et audio. Ce type dapplication exige des dlais stricts. Un flux CBR est gnr en fixant la taille du paquet (dans notre cas 512 octets) et le temps dinter-arrive entre deux paquets conscutifs (dans notre cas 0.005s).
3. Porte de transmission
3.1. Description Avec NCTUns, la porte de transmission peut tre dtermine en affectant la valeur dsire en mtres au paramtre Transmission Range qui se trouve dans le module WPHY (Wireless PHYsical-layer module). Avec GloMoSim [NUE 04], la porte de transmission peut tre dtermine en effectuant trois tapes : - Dtermination du modle de propagation, dans notre cas cest le modle Tow Ray Ground, - Dtermination de la puissance minimale pour recevoir un signal, - Dtermination de la puissance de transmission. Dans ce qui suit, nous allons appliquer ces conditions pour la configuration de la porte de transmission 250 mtres. La formule gnrale du modle de propagation Tow Ray Ground scrit :
R 3.1. Formule du modle de propagation Tow Ray Ground
-50-
Nouha BACCOUR
Avec : Pr , tant la puissance de rception. On choisit sa valeur celle prise par dfaut
dans le fichier de configuration de GloMoSim ( Pr = -81.0 dBm). - Pt, tant la puissance de transmission, - Gt et Gr, reprsentent les gains des antennes denvoi et de rception. On choisit leurs valeurs celles prises par dfaut dans le fichier de configuration de GloMoSim (Gt = Gr = 0.0 dBm c'est--dire antennes isotopiques), - ht et hr reprsentent les hauteurs des antennes denvoi et de rception, ils ont une valeur commune (ht = hr = 1.5 mtres). Daprs la relation R3.1 : Pour avoir une porte de transmission gale 250 mtres, il suffit de dterminer la puissance de transmission Pt pour laquelle la distance sparant un nud metteur et un nud rcepteur sera gale la porte de transmission voulue. On a, Pr = -81.0 dBm = 7.10-9 mW. Gt = Gr = 0 dBm = 1 mW. ht = hr = 1.5 m. d = 250 mtres Pt (mW ) = 5.041234568 C'est--dire, Pt (dBm) = 7.324930385
3.2. Rsultats de simulation Pour vrifier queffectivement la porte de transmission vaut 250 mtres, nous procdons la simulation suivante : Une topologie contenant deux nuds N1 et N2. Le nud N1 envoie au nud N2 un flux CBR. Le trafic commence 1s et sachve 250s. Le temps de simulation tant 300s et le protocole de routage tant AODV. Le nud N1 est fixe, alors que le nud N2 se dplace vers la droite avec une vitesse gale 1m/s (figure 3.1). La distance initiale entre les deux nuds vaut 50 mtres.
DATA (200 pkts/s)
2
50 mres 300 mtres
Figure 3.1. Scnario pour la vrification de la porte de transmission
-51-
Nouha BACCOUR
En se dplaant, la distance (N1, N2) augmente, ainsi peu peu, le mobile N2 quitte la zone de couverture de N1. Cet vnement est marqu par le fait que N2 ne reoit plus les paquets envoys par N1. Par consquent, le nombre de paquets reus devient constant. Si nous mesurons cet instant la distance (N1, N2), nous devons sattendre une valeur gale ou proche des 250 mtres.
3.3.Etude comparative La figure suivante prsente le nombre de paquets reus par le mobile N2 en fonction de la distance sparant les nuds N1 et N2.
41000 41000
Nombre de paquets reus Nombre de paquets reus
40000 40000 39000 39000 38000 38000 37000 37000 36000 36000 35000 35000 34000 34000 33000 33000
223 366 223 399 224 422 224 455 224 488 225 511 225 544 223 300 223 333 225 577 226 600
NCTUns NCTUns GloMoSim GloMoSim
243 mtres
Distance (mtres) Distance (mtres)
250 mtres
Figure 3.2. Nombre de paquets reus par le mobile N2 en fonction de la distance (N1, N2)
Cette figure montre bien que la porte de transmission de NCTUns vaut 250 mtres. En revanche, la porte de transmission de GloMoSim est diffrente de la valeur prvue. Par consquent le taux de paquets reus avec NCTUns sera suprieur celui avec GloMoSim (38439 paquets pour GloMoSim et 39977 paquets pour NCTUns). Ceci est d des facteurs (comme leffet du bruit et des interfrences) qui interviennent dans la porte de transmission. La figure 3.2 montre aussi que la modlisation de la couche physique est simplifie. En effet, si nous fixons cette distance, deux mobiles ne peuvent communiquer que si la distance qui les spare est infrieure ou gale 250 mtres. Alors quen ralit le nud source peut russir envoyer des trames mme si la distance qui le spare du nud
-52-
Nouha BACCOUR
destinataire excde les 250 mtres, car dans ce cas, le calcul des interfrences et du bruit dcidera si la communication est possible ou pas.
4. Mthode daccs au mdium
4.1.Description La mthode daccs au mdium que nous adoptons pour les simulateurs NCTUns et GloMoSim est : CSMA/CA avec le mcanisme RTS/CTS . En bref, cette mthode permet laccs au mdia en mode avec contention. Son principe de fonctionnement est le suivant : Une station voulant transmettre, coute le support de transmission, si le support est occup (une autre station est en train de transmettre), alors la station remet sa transmission plus tard. Si le support est libre pour un temps DIFS (Distributed Inter Frame Space), alors la station va transmettre une trame RTS qui a pour but de rserver le canal pendant la dure ncessaire la transmission. Une fois la trame RTS reue par la station destinataire, celle-ci va attendre un temps infrieur DIFS (temps SIFS ) pour ensuite transmettre son tour une trame CTS qui a pour but davertir toutes les stations sa porte, que le canal sera occup pendant le temps recalcul de la trame RTS prcdente. Ceci permet en effet dviter dventuelles collisions pendant la transmission des flux de donnes. Ce mcanisme peut tre considr comme une tentative dintroduire la qualit de service sur le lien WLAN afin dtre apte transfrer des flux multimdia (le cas du trafic CBR). La couche application tant non fiable. Par consquent, elle gnre un paquet toutes les 5 millisecondes (car nous avons choisi de fixer le dbit de transmission 200 paquets/s). Le rle de la couche MAC est denvoyer les paquets reus par la couche suprieure tout en respectant un ensemble de rgles comme la permission daccs au canal (canal libre, temporisateur expir,). Ainsi, il y aura un partage du mdium tout en diminuant tant la probabilit des collisions que les pertes quelles engendrent.
4.2. Rsultats de simulation Le but du scnario suivant est de crer une comptition sur lobtention du canal de transmission. Ce scnario consiste placer quatre nuds quidistants de 50 mtres.
-53-
Nouha BACCOUR
(figure 3.3) Les nuds N1 et N3 envoient simultanment un flux CBR (de 0.1s 30s) aux nuds N2 et N4. Le temps de simulation tant 50s. La distance (N1, N4) est gale 150 mtres. Dans cette situation, les quatre nuds se situent dans la zone de couverture de N1 et la probabilit de collision sera leve.
DATA (200 pkts/s)
DATA (200 pkts/s)
50 mtres
50 mtres
50 mtres
Figure 3.3. Scnario de test de la mthode daccs
4.3.Etude comparative Aprs la simulation du scnario avec les deux simulateurs, nous avons constat quaucun paquet nest reu par les nuds destinataires N2 et N4. Ceci est d au phnomne suivant. Au dbut, chacun des nuds N1 et N3 possde dans la file dattente de la couche MAC un paquet mettre. En coutant le canal, ils ne trouvent aucun signal car le canal est encore vide. Par consquent, chacun deux envoie un message RTS pour demander laccs au canal. Les deux trames RTS tombent en collision au niveau de N2. Ainsi, ce dernier ne reoit pas la trame RTS venant de N1. Dautre part, au niveau de N4 les trames RTS venant de N1 et N3 tombent en collision pendant que N4 est en train de recevoir la trame RTS . Donc, N4 ne russit pas recevoir la trame de N3.
Venant de 1
RTS
RTS
Figure 3.4. Collision entre les trames RTS Avant de retransmettre son message RTS , chacun des nuds N1 et N3 attend un temps alatoire. Si les temps dattente sont gaux, il y aura une retransmission simultane et on retombe de nouveau dans le mme phnomne (collision entre les paquets RTS ) jusqu' la fin du trafic. Daprs les rsultats de simulation, aucun paquet nest reu par son destinataire : trs probablement, il y a synchronisation dans lenvoi des messages RTS -54-
Nouha BACCOUR
et par consquent aucun paquet
RTS nest reu par les nud N2 et N4. Il en rsulte
quaucun paquet CTS nest reu par les nuds N1 et N3 et par la suite aucun paquet de donne na quitt la couche MAC. Pour confirmer notre hypothse, nous avons utilis le mme scnario avec les deux simulateurs mais en modifiant le temps denvoi. N1 commence lenvoi du flux CBR linstant 0.1s et N3 commence linstant 0.103s. Cette modification a pour but de permettre chacun des sources N1 et N3 denvoyer des temps spars. En effet, au dbut, le nud N1 coute le canal. Il le trouve libre. Il envoie donc son message RTS pour prendre la permission daccs au canal. Le paquet RTS arrive au nud N2. Ce dernier renvoie N1 le message CTS pour lui confirmer son acceptation de recevoir les donnes de sa part. Le premier paquet de N1 arrive N2 avant linstant 0.103s qui correspond au temps denvoi du message RTS par N3. Ainsi N3 trouve le canal disponible pour envoyer son premier paquet. Cette procdure est rpte pendant toute la dure du trafic. Ainsi, tous les paquets envoys par les sources N1 et N3 sont dlivrs leurs destination N2 et N4. Ceci est justifi daprs les rsultats de simulation, par un taux de paquets reus gal 1. En conclusion, ce scnario a montr que chacun des simulateurs NCTUns et GloMoSim prsente un point faible commun : le choix dun nombre SEED identique pour les deux nuds N1 et N3. En effet, normalement, chaque mobile possde un nombre SEEDmobile . Ce nombre, est cr partir du nombre SEEDsimulation global qui est fix dans la configuration de la simulation. partir de chaque SEEDmobile , un nombre alatoire est gnr. partir de ce nombre, le mcanisme de Backoff calcule le temps de retransmission. Ainsi, les temps de retransmission des deux sources seront diffrents. Sils ne sont pas diffrents, les nombres SEEDmobile des noeuds mobiles sont gaux et la retransmission sera simultane. Ceci constitue un problme qui a t retenu avec les deux simulateurs NCTUns et GloMoSim.
5. Performance du routage
5.1. Introduction Les rseau mobiles Ad hoc sont caractriss par une topologie dynamique et un routage multi sauts. Le but du rseau est dexploiter ses ressources logistiques pour sadapter ce dynamisme. En effet, suite un changement de topologie, un metteur -55-
Nouha BACCOUR
nest pas porte directe de la machine destination, les informations devront tre transmises de proche en proche (routage multi sauts), le long dun nouveau chemin. Ce chemin est tabli et maintenu par le rseau laide des protocoles de routage. Lun des rles fondamentaux des simulateurs est de tester les performances des protocoles de routage implments. Les deux simulateurs utilisent IP comme protocole de la couche rseau. Concernant le routage, les protocoles de routage implments en commun par les deux simulateurs sont AODV et DSR. Nous avons choisi le protocole AODV pour comparer les deux simulateurs en terme de routage et dimplmentation du protocole. Dans notre comparaison, nous avons ralis deux scnarii. Le premier scnario est statique et simple. Son rle est de tester le routage multi sauts indpendamment des autres facteurs comme la mobilit. Le second est dynamique. Son but est de comparer le
comportement du rseau vis vis du dynamisme de la topologie.
5.2. Scnario 1 5.2.1. Description Ce scnario est ncessaire pour sassurer de la justesse de fonctionnement petite chelle. Il consiste placer quatre nuds (figure 3.5). N1 envoie un flux CBR N4 qui se trouve trois sauts de N1. Les paquets de N1 devront tre routs de proche en proche jusqu atteindre leur destination.
DATA (200 pkts/s)
1
Source
4
Destination
Figure 3.5. Scnario 1 pour le test du routage 5.2.2. Rsultats de simulation Aprs avoir implment ce scnario avec les deux simulateurs NCTUns et GloMoSim, les rsultats de simulation montrent quavec les deux simulateurs, le taux de paquets dlivrs avec succs est gal 1.
-56-
Nouha BACCOUR
5.2.3. Etude comparative Le rsultat obtenu par les simulateurs NCTUns et GloMoSim est logique. En effet, le nud N1 reoit un accus de rception sur la trame mise avant denvoyer la trame suivante (le temps dinter-arrive tant 5ms et laccus de rception arrive N1 aprs 0.3ms).
5.3. Scnario 2 5.3.1. Description Une topologie contenant 13 nuds disposs dune faon bien dtermine (figure 3.6). Le nud 1 envoie un flux CBR au nud 6. Lenvoi commence t = 1s et sentame t = 195s. La mobilit concerne uniquement les nuds 4 et 7, leur dplacement engendre la rupture de quelques liens. En revanche, tout instant, il y a une route possible entre la source et la destination. Le temps de simulation est fix 200s.
10
12
11
13
Figure 3.6. Scnario1 ltat initial
linstant t = 0s, nous dfinissons la topologie par la figure 3.6. La source commence envoyer ses paquets.
-57-
Nouha BACCOUR
linstant t = 5s, le nud 4 quitte sa position (511, 340) et atteint la position (697, 343) t = 44,44s. Le dplacement du nud 4 fait rompre les deux liens (3, 4) et (4, 5) et apparatre un nouveau lien (2, 4). Par consquent, la route slectionne initialement (1,2,3,4,5,6) devient invalide. linstant t = 50s, le nud 7 quitte sa position (231, 459) et atteint la position (512, 485) t = 76,34s. Le dplacement du nud 7 fait rompre le lien (7, 10) et apparatre un nouveau lien (7, 12). Ds sa dernire arrive, le nud 7 se dirige immdiatement vers la position (519, 348) et latteint t = 80,91s. Ce dplacement fait rompre le lien (7, 12) et apparatre tout dabord le lien (7, 8) puis le lien (7, 5).
Un facteur important qui mesure le degr dadaptabilit du rseau face ce dynamisme est le dlai de reconfiguration du rseau, c'est--dire le temps sparant la rupture du chemin dacheminement des donnes et la slection du nouveau chemin. Ce facteur dpend essentiellement du protocole de routage utilis. Ce scnario a pour but de comparer les comportements des simulateurs vis vis du dynamisme de la topologie. 5.3.2. Rsultats de simulation
1 2
10
12
11
13
t = 1,03s tablissement de la route 1,2,3,4,5,6.
-58-
Nouha BACCOUR
4 3 5 6
10
12
11
13
t = 5s le nud 4 commence se dplacer. t = 19,755s rupture du lien (4,5). => de t = 19,75s t = 21.32s, le nud 6 ne reoit aucun paquet.
1
2
10
12
11
13
partir de 21,32s tablissement de la route 1,2,3,7,10,12,11,8,5,6. Le nud 4 na pas encore termin son dplacement.
4
7 8 9
10
12
11
13
-59-
Nouha BACCOUR
t = 50s le nud 7 commence se dplacer. t = 77,16s rupture du lien (10,7). => De t = 77,1s t = 77,87s, le destinataire ne reoit aucun paquet.
4
3 7
10
12
11
13
partir de77.87 s, tablissement de la route 1,2,3,7,5,6. Figure 3.7. Rsultats de simulation du scnario 1 avec NCTUns
-60-
Nouha BACCOUR
10
12
11
13
t = 1,034s, tablissement de la route 1,2,3,4,5,6.

1 2 4 3 5 6
10
12
11
13
t = 5s, le nud 4 commence se dplacer. t = 12,4s s, rupture du lien (3,4) puis, tablissement de la route 1; 2; 4; 5; 6.
4 1
2
10
12
11
13
t = 21,4s s, rupture du lien (4,5). partir de 21,401s, tablissement de la route 1,2,3,7,10,12,11,8,5,6.
-61-
Nouha BACCOUR
10
12
11
13
t = 50s le nud 7 commence se dplacer. t = 70,5s rupture du lien (10,7) puis, tablissement de la route 1,2,3,7, 12,11,8,5,6.
4
3 7
10
12
11
13
t = 72.3s rupture du lien (7,12) puis, tablissement de la route 1,2,3,7,8,5,6.
-62-
Nouha BACCOUR
3 7
10
12
11
13
t = 76.4 s rupture du lien (8,7) puis, tablissement de la route 1,2,3,7,5,6. Figure 3.8. Rsultats de simulation du scnario 1 avec GloMoSim 5.3.3. Etude comparative Les rsultats de simulation des deux simulateurs montrent des diffrences notables. Ces diffrences se manifestent dans les dlais de reconfiguration du rseau. En effet, daprs la figure 3.7, le nud destination (N6) reste 1.57s et 0,77s (respectivement : de t = 19,75s t = 21.32s et de t = 77,1s t = 77,87s) sans recevoir aucun paquet. Ces dlais sont considrs illogiques pour les raisons suivantes : Dune part, le simulateur GloMoSim a donn des dlais qui ne dpassent pas une dizaine de millisecondes. Dautre part, prenons lexemple de la dfaillance du lien (4,5). N4 saperoit quil a perdu sa connexion avec N5 ds quil retransmet sa trame 7 fois sans recevoir un accus de rception. Ceci correspond linstant t = 19.755s. cet instant, N4 envoie le message dalerte RERR . Normalement, ds que RERR arrive N1 (environ aprs 0.3Ms de son envoi), ce dernier doit procder la recherche de route en inondant le rseau par RREQ . En revanche, la diffusion na t faite qu linstant t = 21.265s. Ensuite le chemin est tabli t = 21.32s. Ainsi nous montrons que le retard dans ltablissement de la nouvelle route suite de la dfaillance du lien (4,5), est d au retard dans la diffusion
-63-
Nouha BACCOUR
RREQ . En dautre terme limplmentation du protocole AODV par NCTUns comporte quelques anomalies. Ces dlais se rpercutent sur la multitude des routes slectionnes. Nous avons ainsi remarqu que GloMoSim se comporte plus stablement que NCTUns, car malgr la mobilit des nuds, les paquets trouvent un chemin pour tre dlivrs leurs destinations ainsi que les dlais de reconfiguration du rseau ne dpassent pas une dizaine de millisecondes. Maintenant voyons les consquences de ces dlais sur le taux de paquets dlivrs vers leurs destinations. Dfinissons dabord, la mtrique PDR (Packet Delivery Ratio) par le rapport entre le nombre de paquets correctement reus pendant une priode T par les nuds destinations et le nombre de paquets envoys par la couche application pendant la mme priode T. PDR = (paquets reus / paquets envoys)
Les PDR sont calculs pendants les durs 20, 40, 60, 80, 100, 120, 140, 160, 180 et 200 secondes. Pour tracer les courbes du taux de paquets reus, nous avons exploit les fichiers trace gnrs la fin de la simulation. Les fichiers traces fournis par NCTUns ont donn des rsultats incorrects. En effet, ces fichiers donnent un taux de paquet suprieur 1 (figure 3.9). Ceci nest pas logique car le nombre de paquets reus ne peut pas tre suprieur au nombre de paquets envoys. Ceci peut tre justifi par le fait quil y a des paquets qui sont dlivrs plus quune fois.
1,2 1 0,8
PDR
PDR >1 !!!
0,6 0,4 0,2 0 20 40 60 80 100 120 140 160 180 200 Temps (secondes)
NCTUns
Figure 3.9. Taux de paquets reus en fonction du temps (avant la correction)
-64-
Nouha BACCOUR
Pour confirmer cette hypothse, nous avons exploit le fichier binaire .ptr gnr par NCTUns la fin de la simulation. Ce fichier fournit la trace de tous les paquets gnrs, c'est--dire reus par la couche MAC. Aprs avoir transform le fichier .ptr en fichier .log , nous avons crit un petit programme java qui analyse le fichier .log et regnre les fichiers trace (comme nombre de paquets reus en fonction du temps, nombre de paquets dupliqus en fonction du temps,). Effectivement, nous avons trouv quen moyenne 13,13 % des paquets sont dupliqus. Pour corriger ceci, nous avons gnr le fichier final des paquets reus en fonction du temps en liminant les paquets dupliqus. Les rsultats de cette correction sont illustrs dans la figure 3.10.
1 0,9 0,8 0,7 0,6
PDR
0,5 0,4 0,3 0,2 0,1 0 20 40 60 80 100 120 140 160 180 200 Temps (secondes)
NCTUns GloMoSim
Figure 3.10. Taux de paquets reus en fonction du temps (aprs la correction)
La figure3.10 montre que, chacun des simulateurs NCTUns et GloMoSim prsente : - Un PDR qui dcrot ds que les nuds se dplacent, - Un PDR qui augmente lorsque les nuds cessent de se dplacer. La figure 3.10 montre galement que les taux de paquets reus avec NCTUns sont largement suprieurs ceux trouvs avec GloMoSim. Ceci veut dire que le nombre de paquets reus avec NCTUns est suprieur au nombre de paquet reus avec GloMoSim puisque le nombre de paquets envoys par la couche application est fixe (trafic UDP non fiable). La figure 3.11 montre bien cette constatation.
-65-
Nouha BACCOUR
35000
Nombre de paquets reus
30000 25000 20000 15000 10000 5000 0 0 20 40 60 80 100 120 140 160 180 200 Temps (secondes) NCTUns GloMoSim
Figure 3.11. Nombre de paquets reus en fonction du temps (aprs la correction)
Cette diffrence dans le nombre de paquet reus est due ce que NCTUns nglige quelques facteurs comme le bruit et linterfrence. Elle est due aussi la diffrence entre les portes de transmission (la porte de GloMoSim est infrieure celle de NCTUns).
6. Scalabilit, temps de simulation et autres facteurs
6.1. Description Dans cette section, nous allons considrer un scnario typique [MAH 04] : Une topologie de surface rectangulaire (1000 m , 500 m), contenant 50 nuds dont 10 sources et 10 puits. Les sources envoient un flux CBR de linstant t = 0.1s jusqu linstant t = 30s. Le temps de simulation vaut 80s. Tous les nuds sont mobiles. Le placement des nuds ainsi que leurs chemins de mobilit sont alatoires. Pour se faire, nous avons vit de choisir le modle de placement des nuds Random et le modle de mobilit Random waypoint , parce que dans ce cas nous nallons pas obtenir la mme topologie avec les deux simulateurs. La solution tait de tracer notre topologie manuellement en faisant parpiller les nuds sur la totalit du terrain physique, et en assurant la connectivit entre tous les nuds mme aprs leur dplacement. En outre, les sources sont places loignes en terme du nombre de sauts qui les sparent leurs puits.
-66-
Nouha BACCOUR
Ceci tait faisable grce loutil graphique de NCTUns (GUI). En effet, la topologie est aisment trace grce GUI ensuite, toutes les informations des nuds (positions, trafic, mobilit,) sont enregistres pour tre places dans les fichiers de configuration de GloMoSim. Aprs avoir ralis, avec les deux simulateurs, le scnario ainsi prsent, nous avons effectu un ensemble de simulations du mme scnario mais en variant chaque fois un facteur de lenvironnement de simulation. Les facteurs que nous avons varis sont : la mobilit, le dbit du trafic, le nombre de sources et la porte de transmission.
6.2. Rsultats de simulation Les rsultats de simulation que nous avons effectus avec les deux simulateurs montrent des similitudes dans le comportement global du rseau et des diffrences dans les temps de simulation et le taux de paquets russis.
6.3.Etude Comparative Variation de la porte de transmission : Pour avoir une ide claire sur leffet de la porte de transmission sur le taux de paquets reus, nous effectuons les statistiques suivantes :
0,7 0,6 0,5
PDR
0,4 0,3 0,2 0,1 0 150 200 Poete de transmission 250
NCTUns GloMoSim
Figure 3.12. Taux de perte en fonction de la porte de transmission
-67-
Nouha BACCOUR
La figure 3.12 montre que le PDR crot en augmentant la porte de transmission. Ce ci est du au fait que le nombre de voisins augmente et la connectivit samliore. Par consquent, les pertes diminuent. Nous avons vu prcdemment, que les portes de transmission des simulateurs NCTUns et GloMoSim ne sont pas gales (243 mtres avec GloMoSim contre 250 mtres avec NCTUns) et que GloMoSim tient compte des interfrences et du bruit dans le calcul de cette porte. Par consquent, daprs les statistiques de la figure 3.12 (plus la porte est petite plus le PDR est petit), tous les PDR recueillis partir de NCTUns seront suprieurs ceux recueillis par GloMoSim. Ceci va tre confirm dans les rsultats qui suivent. Variation du PDR : Parmi les facteurs les plus importants et qui agissent sur le taux de paquets reus, nous citons le dbit du trafic, le nombre de sources, et la mobilit. La figure 3.12 montre la variation du PDR en fonction de ces facteurs.
0,8 0,7 0,6 0,5
0,7 0,6 0,5
PDR
0,4 0,3 0,2 0,1 0 50 100 150 200 250 300 Dbit (paquets/s)
GloMoSim
PDR
NCTUns
0,4 0,3 0,2 0,1 0 10 20 Nombre de sources 30
NCTUns GloMoSim
a. PDR en fonction du dbit

0,7 0,6 0,5
b. PDR en fonction du nombre de sources
PDR
0,4 0,3 0,2 0,1 0 Mobilit Sans Mobilit
NCTUns GloMoSim
c. PDR en fonction de la mobilit Figure 3.13. Variations du PDR en fonction dbit, nombre de sources et mobilit
-68-
Nouha BACCOUR
Le taux de paquets reus diminue lorsque le dbit du trafic augmente car dans ce cas le nombre de collisions augmente. Daprs la figure 3.13.a, nous remarquons que GloMoSim confirme ce rsultat alors que NCTUns fournit des valeurs non logiques pour les dbits 100 et 150 paquets/s. Ceci est d une injustesse dans limplmentation du protocole de routage. La figure 3.13.b montre que le PDR diminue lorsque le nombre de sources augmente. En effet, lorsque le nombre de sources augmente, le nombre de paquets perdus augmente. Ceci est du aux phnomnes de collision, congestion et comptition sur lobtention de laccs au medium. La figure 3.13.c montre que la mobilit est un facteur important qui dgrade la performance du rseau en terme de paquets dlivrs. Ce ci est d aux pertes des paquets pendant la phase de reconfiguration du rseau.
Temps de simulation et scalabilit : Notons que les simulations ont t ralises sur une machine qui a les caractristiques systme suivantes : CPU : Pentium 4 de frquence 1.70GHz, RAM : 256 Mo.
La figure 3.14 montre que : Dune part, dans toutes ses sous figures, le temps de simulation de NCTUns est nettement suprieur celui de GloMoSim. Ceci est tout fait logique car nous avons vu que NCTUns ne peut pas tre indpendant de lenvironnement graphique GUI lors de lexcution de chaque simulation. Dautre part, le temps de simulation avec NCTUns crot rapidement ds que nous augmentons le nombre de sources, la mobilit ou le dbit (figure 3.14.c), ce ci donne une ide sur le pouvoir de Scalabilit de NCTUns. GloMoSim se distingue par rapport aux autres simulateurs par son pouvoir de scalabilit. Cette caractristique est atteinte par un temps de simulation stable (naugmente pas rapidement) ce qui est dj signal par la figure 3.14. Le fait de montrer que : les temps des simulations par NCTUns sont nettement suprieurs ceux de GloMoSim et augmentent rapidement en augmentant les facteurs nombre de sources, mobilit et dbit ; nous pouvons ainsi confirmer que NCTUns a un pouvoir de scalabilit faible.
-69-
Nouha BACCOUR
Temps de simulation (secondes)
250
140 120 100 80 60 40 20 0 Mobilit Sans Mobilit NCTUns GloMoSim
200 150 100 50 0 10 20 Nombre de sources 30
NCTUns GloMoSim
a.Temps de simulation en fonction du nombre de sources

b. Temps de simulation en fonction de la mobilit
180 160 140 120 100 80 60 40 20 0 50 100 150 200 250 300 Dbit (paquets/s) NCTUns GloMoSim
c. Temps de simulation en fonction du dbit Figure 3.14. Variations du temps de simulation en fonction dbit, nombre de sources et mobilit
7. Conclusion travers ce chapitre, nous avons vu que NCTUns prsente un ensemble davantages par rapport GloMoSim comme la facilit de ralisation des scnarii de simulation grce son environnement graphique GUI. En revanche, nous avons montr que NCTUns possde les inconvnients suivants : - Les statistiques quil fournit ne sont pas rigoureuses. - Il y a des cas ou il ne tient pas des facteurs bruit et dinterfrence. - La mauvaise gestion du nombre SEED . - Limplmentation du protocole de routage AODV ncessite un perfectionnement. Le pouvoir de scalabilit de NCTUns est mdiocre.
-70-
Nouha BACCOUR
Lobjectif de ce projet de fin dtudes tait dvaluer le simulateur NCTUns en le comparant avec le simulateur GloMoSim et avec les rsultats thoriques envisags. Le choix de lutilisation de GloMoSim est justifi par le fait quil est considr comme tant populaire et a t test par plusieurs chercheurs. A travers notre comparaison, nous avons constat que malgr les avantages fournis par NCTUns tels que la facilit dutilisation et la convivialit de ses interfaces, nous avons dmontr quil prsente plusieurs inconvnients lis limplmentation de certains de ses protocoles et la simplification de quelques modles, ce qui peut engendrer linexactitude de certains rsultats. Nous avons galement constat que malgr sa popularit, GloMoSim partage quelques injustesses avec NCTUns. Ceci nous mne mettre des rserves sur les outils de simulation dune faon gnrale et par consquent, sur tous les protocoles qui n'ont t valids que sur la base de simulations, et jamais par une implmentation relle ou une preuve formelle. Les perspectives de ce travail seraient dajuster les incorrections quon a pu observ, fin de faire converger les deux simulateurs vers des rsultats proches de la ralit. Dans notre tude comparative nous nous somme bass sur des protocoles de rseaux sans fil Ad hoc, nous pourrons valuer aussi les protocoles filaires supports par NCTUns et dduire ainsi les performances de ce simulateur pour les rseaux filaires.
-72-
Nouha BACCOUR
BIBLIOGRAPHIE
REFERENCES
[WAN 03] S.Y. Wang, C.L. Chou, C.H. Huang, C.C. Hwang, Z.M. Yang, C.C. Chiou, and C.C. Lin The Design and Implementation of the NCTUns 1.0 Network Simulator, Network and System Laboratory, Department of Computer Science and Information Engineering, National Chiao Tung University, pp 1-19, Taiwan, 2003. [WAN 05] Prof. Shie-Yuan Wang Using the NCTUns 2.0 Network Simulator/Emulator to Facilitate Network Researches, Network and System Laboratory, Department of computer Science and Information Engineering, National Chiao Tung University, pp19-56, Taiwan, January 2005. [BAJ 00] Lokesh Bajaj, Mineo Takai, Rajat Ahuja, Ken Tang, Rajive Bagrodia, Mario Gerla, GloMoSim: A Library for Parallel Simulatio of Large-scale Wireless Networks, Computer Science Department University of California, pp 1-12, Los Angeles, 2000. [PER 99] E. Perkins, E.M. Royer, Ad-Hoc on demand Distance Vector Routing, Second annual IEEE workshop on Mobile Computing Systems and Applications, pp 90-100, February 1999. [JAC 03] Philippe Jacquet Thomas Clausen, Optimized Link State Routing Protocol (OLSR), RFC 3626, 2003. [PEA 99] M. Pearlman Z. Haas. The zone routing protocol (zrp) for ad hoc networks IETF Draft, 56 pages, draft-ietf-manet-zonezrp- 02.txt, 1999. [COR 98] M.S.Corson, J.P. Macker, Mobile Ad hoc Networking and the IETF, ACM. Mobile Computiong and Communications Review, Vol. 2, 1998. [16] [FOR 99] QoS Forum. QoS protocols and architectures. White paper of QoS Forum, July 1999. http ://www.qosforum.com. [CRAW 99] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick, A Framework for QoSbased Routing in the Internet, IETF RFC2386, 1999. [LIN 97] C. R. Lin and M. Gerla, MACA/PR : An Asynchronous Multimedia Multihop Wireless Network, In Proceedings of IEEE INFOCOM 97, April 1997. [COR 99] S. Corson and J. Macker. Mobile ad hoc networking (MANET): Routing protocol performance issues and evaluation considerations, RFC 2002, January 1999. [BRA 03] Ins Ben Brahim, Le routage et la gestion de la qualit de service dans les rseaux Ad hoc, Ecole Nationale des Ingnieurs de Sfax, juin 2003. [NUE 04] Jorge NUEVO, A Comprehensible GloMoSim Tutorial, INRS - Universit du Qubec, 2004.
-73-
Nouha BACCOUR
[MAH 04] Priya Mahadevan, Adolfo Rodriguezn, David Becker, Amin Vahdat, MobiNet: A Scalable Emulation Infrastructure for Ad Hoc and Wireless Networks , UC, San Diego, 2004.
SITES
[site 1] http://pcl.cs.ucla.edu/projects/glomosim/ [site 2] http://pcl.cs.ucla.edu/projects/glomosim/GloMoSimManual.html [site 3] http://www.isi.edu/nsnam/ns/ [site 4] http://www.opnet.com/ [site 5] http://nsl.csie.nctu.edu.tw/nctuns.html/
-74-
Nouha BACCOUR
ANNEXE 1
Hop Count BCID Destination @ DSN Source @ SSN
Hop Count Nombre de sauts jusqu destination BCID ID de request Destination Address @ IP Destination DSN N squence de destination le plus rcent connu par la source : Cette valeur est recopie de la table de routage. Si le numro de squence n'est pas connu, la valeur nulle sera prise par dfaut. Source Address @ IP Source SSN N squence courant Format du paquet RREQ
Hop Count
Destination @
DSN
Source @
Lifetime
Lifetime -Le temps en millisecondes pour lequel des nuds qui reoivent les RREP, considrent la route valide. Format du paquet RREP
-75-
Nouha BACCOUR
ANNEXE 2
Installation de NCTUns 2.0
.Les tapes dinstallation de NCTUns se rsument comme suit : 0- Le privilge de root est obligatoire 1- Copier le fichier NCTUns-allinone-linux-2.6.5.01202005.tar dans une nouvelle rpertoire package 2- Dcompresser le fichier tar zxvf NCTUns-allinone-linux-2.6.5.01202005.tar 2- Aller vers le rpertoire NCTUns cd NCTUns 3- Excuter la commande suivante pour installer le package : ./install.sh 4- Redmarrer lordinateur reboot 5- Editer un fichier /.bashrc qui contiendra la dfinition des variables denvironnements. vim /.bashrc contenue du fichier : alias rm=rm i alias cp=cp I alias mv=mv I export LD_LIBRARY_PATH=/usr/local/nctuns/lib export NCTUNSHOME=/usr/local/nctuns /etc/bashrc
5- Attribuer le privilge dexcution ce fichier: chmod +x /.bashrc et chmod +x /etc/bashrc 6- Excuter le fichier /.bashrc source /.bashrc a ne doit gnrer aucune erreur !
-76-
Nouha BACCOUR
7- Pour vrifier, afficher le contenu de la variable denvironnement NCTUNSHOME echo $NCTUNSHOME ca doit donner si tout va bien ceci : /usr/local/nctuns/lib 8- Excuter le dispacher puis le coordinator et enfin le nctunsclient : /usr/local/nctuns/bin/dispatcher usr/local/nctuns/bin/coordinator usr/local/nctuns/bin/nctunsclient Linterface graphique utilisateur (GUI) de NCTUns apparatra :
Capture dcran de louverture de linterface graphique de NCTUns2.0
-77-
Nouha BACCOUR
ANNEXE 3
Installation de GloMoSim 2.03
0- Aprs avoir tlcharger GloMoSim (2.4 Mo), copier le dans votre rpertoire personnel : /home/user_name/ 1- Faire transformer glomosim-2.03.tar.gz en glomosim-2.03.tar : gunzip -dfv glomosim-2.03.tar.gz 2- Dcompresser le fichier rsultant tar -xvf glomosim-2.03.tar
Installation du PARSEC Maintenant, il faut ouvrir une session Root pour faire ce qui suit : 3- Crer un rpertoire parsec dans /usr/local Ensuite, revenir vers la session User pour faire ce qui suit : 4- Si vous tapez pcc ce stade vous aurez lerreur suivant : bash: pcc: command not found 5- Affectation des variables denvironnements PATH , CLASSPATH et PCC_DIRECTORY : export PATH=$PATH:/usr/local/parsec/redhat7.2/bin:/usr/local/parsec/redhat-7.2/include: export CLASSPATH=$CLASSPATH:/usr/local/parsec/redhat-7.2/bin: export PCC_DIRECTORY=/usr/local/parsec/ 6- Maintenant, si vous taper pcc vous aurez: No input files. 6- Aller home/user_name/glomosim-2.03/glomosim/main/ et taper make cd /home/user_name/glomosim-2.03/glomosim/main/ make Si a fonctionne sans erreurs, donc cest bon. Sinon copier les deux fichiers pc_api.h et clocktype.h qui se trouvent dans /usr/local/parsec/redhat-7.2/include/ , dans /home/user_name/glomosim-2.03/glomosim/main/ 7- Taper la commande suivante : make -78-
Nouha BACCOUR
Si a fonctionne sans erreurs, donc cest bon. Sinon copier le rpertoire include qui se trouvent dans /home/user_name/glomosim-2.03/parsec/redhat-7.2/ , dans /home/user_name/glomosim-2.03/parsec/ 8- Aller home/user_name/glomosim-2.03/glomosim/main/ et taper make cd /home/user_name/glomosim-2.03/glomosim/main/ make Maintenant, a doit marcher ! Installation de Java GUI (si java est install alors ignorer cette tape) : 9- Tlcharger j2eesdk-1_4-linux.bin partir du site suivant : http://java.sun.com/j2se/1.4.2/download.html 10- Ouvrir une session Root pour crer un rpertoire s1studio_jdk dans /usr/local Copier j2eesdk-1_4-linux.bin dans le rpertoire /usr/local/ s1studio_jdk 11- Ensuite, revenir vers la session User. 12- Installation du jdk par la commande suivante : ./j2eesdk-1_4-linux.bin Si a fonctionne sans erreurs, donc cest bon. Sinon a va vous afficher lerreur suivante : ./j2eesdk-1_4-linux.bin: error while loading shared libraries: libstdc++libc6.2-2.so.3: cannot open shared object file: No such file or directory You have new mail in /var/spool/mail/root Dans ce cas tlcharger le package libstdc++2.10-2.96-0.83mdk.i586.rpm et linstaller avec la commande : rpm -ivh libstdc++2.10-2.96-0.83mdk.i586.rpm Maintenant, retaper la commande suivante pour linstallation du jdk : ./j2eesdk-1_4-linux.bin Maintenant, a doit fonctionner ! 13- Affectation des variables denvironnement : export PATH=$PATH:/usr/local/s1studio_jdk/jdk/bin: export CLASSPATH=$CLASSPATH:/usr/local/s1studio_jdk/jdk/bin: -79-
Nouha BACCOUR
14- copier les fichiers app.cong et nodes.input qui se trouvent dans le rpertoire /home/nouha/glomosim-2.03/glomosim/bin , dans le rpertoire /home/nouha/glomosim-2.03/glomosim/java_gui/ 15- aller /home/nouha/glomosim-2.03/glomosim/java_gui/ et compiler tout les fichiers java : cd /home/nouha/glomosim-2.03/glomosim/java_gui/ javac *.java 7- taper la commande suivant : java GlomoMain Linterface java GUI apparatra !
-80-

NB Pfe

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

NB Pfe

Uploaded by

Copyright:

Available Formats

1.1.1.

Rpublique Tunisienne Ministre de lEnseignement Suprieur

Cycle de Formation dIngnieurs dans la discipline Gnie informatique

Projet de fin dtudes N dordre: 2004GI27

lEcole Nationale dIngnieurs de Sfax

du Diplme National dIngnieur en Gnie Informatique

M. Abderrazak OUALI M. Bachar ZOUARI M. Maher BEN JEMAA M. Hni KAANICHE

Prsident Membre Encadreur Encadreur

3. GloMoSim (Global Mobile information system Simulator) ......................................37

3.3. 3.4. 3.5. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6.

4. Etude comparative .........................................................................................................43

4. Mthode daccs au mdium.........................................................................................53

7. Conclusion ......................................................................................................................70 Conclusion et perspectives.71 Bibliographie...73 Annexe1...75 Annexe2...76 Annexe3...78

Liste des figures

Liste des tableaux

Figure 1.1. Le modle de rseau avec infrastructure

Figure 1.2. Le modle des rseaux mobiles sans infrastructure

Figure 1.3. Lattnuation rapide du signal en fonction de la distance

Figure 1.4. Le problme des nuds cachs

5. Prsentation des rseaux mobiles Ad hoc

Liens physiques de communication

Figure 1.5. La modlisation d'un rseau Ad hoc

Figure 1.6. Le changement de la topologie des rseaux Ad hoc

6. Le routage dans les rseaux ad hoc

Les protocoles de routage Ad hoc

Les protocoles Ractifs Exemple : DSR et AODV

Les protocoles Hybrides Exemple : ZRP

Les protocoles Proactifs Exemple : OLSR et DSDV

Figure 1.7. La classification des rseaux Ad hoc

a.. Propagation du paquet RREQ

b. Formation de chemin inverse

c. Formation du chemin bidirectionnel vers la source

d. Formation du chemin bidirectionnel vers la source

a. Le chemin dacheminement de paquets

b. La diffusion du RERR par le nud 5

c.Initialisation du processus de dcouverte de route

Figure 1.9. Le processus de maintenance de route dans AODV

Figure 1.10. Relais multipoints

2. NCTUns (National Chiao Tung University network simulator)

Pages Google au 20/03/2005

Tableau 2.2. Des quipements rseau simuls par NCTUns 2.0

Topology Editor Editeur de topologie de rseau sans-fil et de rseau cbl.

Tableau 2.3. Des quipements rseau simuls par NCTUns 2.0

3. GloMoSim (Global Mobile information system Simulator)

Figure 2.3. Temps de lexcution de la simulation en variant le nombre de nuds

Radio Model Propagation Model/Mobility Model

Figure 2.6. Les principales entits de Glomosim

Tableau 2.6. Comparatif entre NCTUns et GloMoSim dans le Scnario de mobilit

Une topographie tridimensionnelle Un plan bitmap

Tableau 2.8. Comparatif entre NCTUns et GloMoSim La gnration du trafique

Couche Physique Liaison de donns (Mac)

TCP et UDP CBR, FTP, HTTP et Telnet

R 3.1. Formule du modle de propagation Tow Ray Ground

Figure 3.1. Scnario pour la vrification de la porte de transmission

NCTUns NCTUns GloMoSim GloMoSim

Distance (mtres) Distance (mtres)

4. Mthode daccs au mdium

DATA (200 pkts/s)

DATA (200 pkts/s)

Figure 3.3. Scnario de test de la mthode daccs

et par consquent aucun paquet

RTS nest reu par les nud N2 et N4. Il en rsulte

comportement du rseau vis vis du dynamisme de la topologie.