Simulation d'un réseau Ad-Hoc sous NS2

18 février 2016

Remerciements

Nous tenons à remercier en pre-mier temps, notre professeur, MmeSonia BEN REJEB, qui nous adonné la chance d’enrichir nosconnaissances.Nous remercions également MmeSamia ALOULOU pour l’aide etles conseils concernant les missionsévoquées dans ce rapport.

Rabeb BOUMAIZARihab CHEBBAH

Résumé-synthèse

RésuméL’objectif de ce travail était d’analyser les propriétés du protocole de routage AODV

opérant dans les réseaux ad hoc, en particulier le délai de découverte de route, l’optima-lité de sélection des routes et le coût de sélection des routes. La simulation est un outilindispensable pour étudier la performance des protocoles de routage dans ces réseaux.Les résultats de simulation ont été représentés sur des graphes et interprétés. Ces si-mulations nous ont conduit à bien savoir comment le protocole AODV opère face à ladensité du réseau et à la charge du trafic y circulant ainsi que de valider la variationdu taux d’acceptation de connexions en présence d’un contrôle d’admission basé sur ladisponibilité de la bande passante dans les noeuds de routage.Mots clés : réseau ad hoc, protocole de routage AODV, simulation NS2, évaluationde performance, qualité de service, réservation de bande passante, contrôle d’admission.

Abstractthe objective of this work was to analyze the properties of AODV routing protocol

operating in ad hoc networks, especially the route discovery period, the optimal selec-tion of routes and cost of route selection. The simulation is an indispensable tool forstudying the performance of routing protocols in these networks.Simulation results were represented on graphs and interpreted. These simulations haveled us to know how the protocol operates AODV facing the network density and trafficload traveling therein as well as validating the change in the acceptance rates of connec-tions in the presence of an admission control based on the availability of bandwidth inthe routing nodes.Key words : ad hoc network, AODV routing protocol, NS2 simulation, performanceevaluation, quality of service, bandwidth reservation, admission control

Sommaire

Introduction Générale 1

1 Réseaux Mobile AdHoc 31.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Architecture de connexion . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Services offerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 protocoles de routages . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Modèles de trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.6 qualité de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Network Simulator 2 132.1 Description Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Présentation du NS 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3 Modèles de mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 Installation du NS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Réalisation 253.1 Description du fichier TCL . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Exécution du fichier TCL . . . . . . . . . . . . . . . . . . . . . . . . . 343.3 Analyse du fichier trace . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4 Critères de sélection des protocoles . . . . . . . . . . . . . . . . . . . . 363.5 Comparaison des résultats avec OLSR . . . . . . . . . . . . . . . . . . 38

Conclusion Générale 39

I

Liste des figures 42

Bibliographie 45

Introduction générale

L’internet est le réseau des réseaux informatiques communicants entre eux grâce à unprotocole de communication commun. Toutefois , la croissance exponentielle d’Interneta induit la naissance des nouvelles technologies de réseaux informatiques notemment leréseau sans fil.

Ce dernier est un ensemble des nœuds qui s’interconnectent à travers des ondesradio. Il se basent sur une infrastructure où le maintien de la connectivité est ménagépar des équipements spécifiques citant des routeurs wifi et des points d’accés.Le réseaux sans fil possède deux architecture de connexion : mode infrastructure etmode adhoc. le mode infrastructure s’appuie sur l’établissement des connexions via despoints d’accés centralisé et chaque point d’accés est connecté à un réseau filaire. Grâceà ce mode, nous avons la possibilité de rester connecté tout en se déplaçant dans unezone géographique plus ou moins étendu, c’est la raison pour laquelle nous entendonsparfois parler de "mobilité". Cette qualification a donné naissance au mode ad hoc ouencore MANET.

Ce type d’architecture vient à éliminer l’emploi des points d’accés. Chaque nœudalors sera comporter comme un récepteur, un émetteur et aussi un routeur WIFI pourses nœuds voisins ; il calcule et maintien les routes afin d’atteindre toutes les destina-tions à porté du rayon. Ce qui nécessite l’emploi des protocoles de routage, fonctionnantsavec des routeurs mobiles, par les nœuds intermédiaires pour acheminer les paquets demessage à la bonne destination. Le protocole qui nous intéresse dans ce mini-projet estle AODV fondé sur le principe de vecteurs de distance.

La qualité de service est un facteur essentiel dans un réseau ; débit, taux de perte depaquets, taux d’utilisation, le retard et le nombre de sauts sont souvent utilisés commedes indicateurs pour évaluer les performances de ce réseau.

Le but de ce mini-projet est d’élaborer un réseau mobile ad hoc en implémentantun modèle de simulation sous Network Simulator avec le protocole de routage AODVen particulier afin d’évaluer son impact sur le taux de paquet reçus délivrée, le tauxde perte des paquets et encore le délai des transmissions de la source vers la destination.

Ce rapport du mini-projet se compose de trois chapitres. Le premier présente unevision d’ensemble de la thématique des réseaux adhoc. Le deuxième est consacré à laprésentation de l’outil de simulation "Network Simulator" ainsi que son installation. Le

1

dernier chapitre montre le modèle de simulation préparé suivant lequel les métriquesdu protocole AODV sont évaluées. Les résultats de la simulation sont affichés sur desgraphes et sont interprétés. Une conclusion générale et des perspectives font la fin dece rapport.

2

Chapitre 1

Réseaux Mobile AdHoc

Introduction

Au niveau de ce chapitre, nous définirons la nouvelle technologie des réseaux sansfil tout en présentant ses services offerts, son architecture de connexion, ses modèlesde trafic, les protocoles de routage et en finissant par l’étude de la qualité de servicequ’elle dispose.

1.1 Description

Manet, ou encore un réseau adhoc mobile, est peut être définit comme étant unensemble des nœuds , pouvant être mobiles, interconnectés et communicants entre euxsans l’aide de tous supports fixes et d’une administration centralisée. le déploiementd’un réseau adhoc est simple et ne nécessite aucun pré requis ; il suffit de disposer desterminaux dans un espace pour créer un réseau adhoc. Chaque nœud dans le réseau secomporte comme un routeur et transmet les paquets pour d’autres nœuds. Le cheminemprunté pour transmettre un message d’un nœud source à un nœud destination estdéterminé par un protocole de routage.

3

1.2 Architecture de connexion

Figure 1.1 – Architecture de connexion AdHoc

1.3 Services offertsChaque nouvelle technologie est caractérisée par les services qu’elles offrent aux

utilisateurs notemment le réseau AdHoc.

Réseaux sans fil conçu pour les réseaux locaux et domestiques Pour les réseauxlocaux, nous trouvons les technologies IEEE 802.11a, 802.11b (Wifi) et 802.11g.Pour les réseaux WPAN, nous trouvons la technologie Bluetooth. IEEE 802.11b,802.11g et Bluetooth opèrent dans la bande ISM (Industrial, Scientific and Medi-cal ) à 2.4 GHz alors que 802.11a opère dans la région des 5 GHz.

Les nœuds Ces participants possède des systèmes hétérogène afin de s’interconnecterfacilement. Ils sont autonomes et possèdent à la fois les fonctionnalités de relaiset de point de communication.

Mobilité La topologie du réseau peut changer d’autant plus rapidement que les nœudssont mobiles.

Auto-Configuration L’auto configuration permet aux nœuds de s’intégrer facilementdans un réseau. Elle facilite la gestion du réseau car l’interconnexion des élémentsne nécessite qu’un minimum d’intervention technique externe. Cette fonctionnalitéest de plus en plus nécessaire pour un déploiement à grande échelle des réseauxad hoc.

4

1.4 protocoles de routagesDes protocoles de routage ont été proposés pour prendre en compte les spécificités

des réseaux MANET.

DSR : Dynamic Source RoutingDSR est un protocole simple et efficace de routage spécialement conçu pour une

utilisation en multi-hop réseaux sans fil adhoc des nœuds mobiles. DSR permet auréseau d’être complètement auto-organisé et auto-configuré, sans avoir besoin de toutel’infrastructure ou de l’administration de réseau existant. Le protocole est composé dedeux principaux mécanismes de la découverte de la route et la maintenance de cettedernière, qui travaillent ensemble pour permettre les nœuds de découvrir et de maintenirles routes vers des destinations arbitraires dans le réseau adhoc. Tous les aspects duprotocole fonctionnent entièrement sur la demande, permettant à la tête de routagede paquets de DSR à l’échelle automatiquement seulement ce qui est nécessaire pourréagir aux changements dans les routes actuellement en usage. Le protocole permet àplusieurs routes de circuler vers toute destination et permet à chaque expéditeur desélectionner et de contrôler les itinéraires utilisés pour l’acheminement de ses paquets.Le protocole DSR est conçu principalement pour les réseaux mobiles adhoc jusqu’àenviron deux cents nœuds et est conçu pour fonctionner même avec des taux très élevésde la mobilité.

DSDV : Destination-Sequenced Distance VectorCe protocole est adapté du protocole classique du routage (RIP) aux réseaux de

routage adhoc. Il ajoute un nouvel attribut, numéro de séquence, à chaque entrée duRIP classique de table de routage. En utilisant le numéro de séquence nouvellementajouté, les nœuds mobiles peuvent distinguer les informations d’itinéraire vicié de lanouvelle et d’éviter ainsi la formation de boucles de routage.Chaque nœud devra maintenir un tableau énumérant tous les autres nœuds, ils sontconnus soit directement, soit par l’intermédiaire des voisins. Chaque nœud a une seuleentrée dans la table de routage. L’entrée va avoir des informations sur l’adresse IP dunœud, le dernier numéro de séquence connue et le nombre de sauts pour l’atteindre.Avec ces détails la table conserve également la trace du voisin nexthop pour atteindrela destination, l’horodatage de la dernière mise à jour reçue pour ce nœud.

5

Le message de mise à jour de DSDV se compose de trois champs, adresse de desti-nation, le numéro de séquence et HopCount.

Chaque nœud utilise 2 mécanismes d’envoyer les mises à jour DSDV. Ils sont :1. Mises à jour périodique

Mises à jour périodiques sont envoyés après chaque 15s par défaut. Dans cettemise à jour le nœud diffuse sur l’ensemble de sa table de routage.

2. Mises à jour de déclenchementCes mises à jour sont envoyées chaque fois qu’un noeud reçoit un paquet DSDVqui a provoqué un changement dans sa table de routage. Le document d’originene mentionne pas clairement quand pour ce changement dans le tableau devraitune mise à jour de DSDV être envoyé. Le courant Mise en œuvre et envoie unemise à jour quelle que soit la modification de la table de routage.

Les mises à jour sont acceptées sur la base de la métrique pour un nœud particulier.Le premier facteur qui détermine l’acceptation d’une mise à jour est le numéro de sé-quence. Il doit accepter la mise à jour si le numéro de séquence du message de MAJ estplus élevée indépendamment de la métrique. Si la mise à jour avec le même numéro deséquence est reçu, un HopCount sera donné avec priorité plus faible.

AODV : Ad hoc On Demand Distance VectorAODV est un protocole de routage sans boucle pour les réseaux ad-hoc. Il est conçu

pour être auto-démarré dans un environnement de nœuds mobiles, résister à une variétéde comportements de réseau tels que la mobilité des nœuds, les pannes de liaison et lespertes de paquets.A chaque nœud, AODV maintient une table de routage. L’entrée de table de routagepour une destination contient trois domaines essentiels : un nœud de saut suivant, unnuméro de séquence et un nombre de sauts. Tous les paquets destinés à la destina-tion sont envoyées au nœud de saut suivant. Le numéro de séquence agit comme uneforme d’horodatage, et est une mesure de la fraîcheur d’un itinéraire. Le nombre desauts représente la distance en cours au nœud de destination. Dans AODV, les nœudsdécouvrent les itinéraires dans les cycles de demande-réponse. Un nœud demande unitinéraire vers une destination en diffusant un message RREQ à tous ses voisins. Quandun nœud reçoit un message de RREQ mais ne dispose pas d’un itinéraire vers la desti-nation demandée, à son tour diffuse le message RREQ. En outre, il se souvient d’uneroute inverse vers le nœud demandeur, qui peut être utilisé pour transmettre des ré-ponses ultérieures à ce RREQ. Ce processus se répète jusqu’à ce que le RREQ atteint

6

un nœud qui a une route valide vers la destination. Ce nœud (qui peut être lui-mêmela destination) répond avec un message de RREP. Cette MIQ est unicast le long desroutes inverse des nœuds intermédiaires jusqu’à ce qu’il atteigne le nœud demandeurd’origine. Ainsi, à la fin de ce cycle de demande-réponse bidirectionnel un itinéraire estétabli entre le nœud demandeur et la destination. Quand un nœud perd la connectivitéà sa prochaine hop, le noeud invalide sa route en envoyant un RERR à tous les nœudsqui potentiellement reçu son MIQ.

Sur réception des trois messages de AODV : RREQ, RREP et RERR, les nœudssont mis à jour la prochaine hop, numéro de séquence et les nombres de sauts de leursitinéraires de manière à satisfaire la contrainte d’ordre partiel mentionné ci-dessus.

Figure 1.2 – Ad hoc On Demand Distance Vector

OLSR : Optimized Link State RoutingCe protocole optimise le protocole LSR 1 en réduisant les diffusions par la notion de

RMP ou point multi-relais, qui sont des nœuds élus par chaque station de manière à ceque tout voisins de cette station soit joignable en un maximum de deux sauts à traversles nœuds RMP : chaque nœud émet périodiquement la liste de ces voisins mais seulsles voisins multipoints vont diffuser cette liste à leur tour pour minimiser les diffusions.Les nœuds RMP garderont les informations sur l’état des liens des messages de mises

1. Link State Routing, protocoles de routage à état de liens sont des protocoles de routagedont algorithmes calculer les meilleurs chemins pour réseaux différemment Distance Vector protocolesde routage. Considérant que les protocoles à vecteur de distance savent routes par des mesures dedistance et de vecteur (direction) tels que rapportés par les routeurs voisins, protocoles de routaged’état de liens calculent leurs itinéraires du réseau par la construction d’une topologie complète dela zone de réseau entier, puis en calculant le meilleur chemin de cette topologie ou carte de tous lesréseaux interconnectés.

7

à jour qui leur parviennent pour permettre ensuite le routage des paquets de donnéesd’une communication. Autrement dit, seul les nœuds RMP ont la connaissance de latopologie du réseau et peuvent assumer le rôle de routeur, les autres stations ayant pourseul possibilités de diffuser vers leur voisins RMP. Globalement, ce protocole amélioreréellement LSR en évitant l’inondation totale du réseau mais laisse nombre de sesproblèmes en suspens.

TORA : Temporally Ordered Routing AlgorithmTORA est un protocole sur la demande de routage. Contrairement à d’autres algo-

rithmes du protocole de routage, TORA ne sert pas le concept de chemin le plus courtpour la création de chemins de source à la destination comme il peut lui-même prendreénorme quantité de la bande passante dans le réseau. Au lieu d’utiliser le chemin leplus court pour le calcul des routes, son algorithme maintient la "direction de la desti-nation suivante" de transmettre les paquets. Ainsi, un nœud de source maintient un ouplusieurs "voies" aval vers le nœud de destination à travers de multiples nœuds voisinsintermédiaires. Il réduit les messages de commande dans le réseau par les nœuds ayantà la requête pour un chemin seulement quand il a besoin d’envoyer un paquet vers unedestination.Dans TORA trois étapes sont impliqués dans établir un réseau :

1. Création d’itinéraires de source à la destination

2. maintenir les routes

3. Effacement routes invalides

TORA utilise le concept de «graphe orienté acyclique (DAG) à établir des cheminsaval à la destination". Ce DAG est appelé comme «Destinations Oriented DAG". Unnœud marqué comme destination DAG est orientée vers le dernier nœud ou le nœudde destination et aucun lien provenant de ce nœud. Il a la hauteur la plus basse. Troismessages différents sont utilisés par TORA pour établir un chemin : le (QRY) unmessage de requête pour la création d’un itinéraire, de mise à jour (UPD) un messagepour créer et maintenir les routes et Effacer (CLR) message pour effacer un itinéraire.Chacun des noeuds est associé à une hauteur dans le réseau. Un lien a été établi entreles noeuds en fonction de la hauteur. La mise en place de l’itinéraire de la source à ladestination est basée sur le mécanisme de DAG assurant ainsi que toutes les routes sontboucle libre. Les paquets se déplacent du noeud de source ayant la plus grande hauteurau noeud de destination avec la hauteur la plus basse. Il est le même haut en approchedescendante.

8

AODV vs OLSR

Comme protocole proactif, OLSR réduit la surcharge de commande forçant le MPRpour propager les mises à jour de l’état de lien, aussi l’efficacité est acquise par rapportau protocole de l’état de la liaison classique lorsque l’ensemble de MPR sélectionné estaussi faible que possible. Mais l’inconvénient de cette est qu’elle doit maintenir la tablede routage pour tous les itinéraires possibles, donc il n’y a pas de différence dans lespetits réseaux, mais quand le nombre des hôtes mobiles augmente, alors la tête de mes-sages de contrôle est également en augmentation. Cela limite l’évolutivité du protocoleOLSR. Le travail de protocole OLSR plus efficacement dans les réseaux denses.La surcharge des protocoles réactifs comme AODV est liée principalement à la décou-verte de la nouvelle route et de mises à jour des routes utilisables. Ainsi, dans le réseauavec le trafic léger et une faible mobilité des protocoles réactifs échelles parfaitementaux grands réseaux à faible bande passante et les frais généraux de stockage. Commel’environnement indésirable pour les protocoles réactifs est le réseau à fort trafic avec ungrand nombre de destinations à forte mobilité. Cette situation entraînera qu’un grandnombre de voies sera briser résultant découvertes de route répétées et les rapports d’er-reurs dans le réseau.De l’information ci-dessus, il est évident que les protocoles proactifs produisent uneplus grande efficacité de routage que les protocoles réactifs dans le réseau avec le traficdiffusée. Parce que les mises à jour proviennent de mises à jour périodiques et aucunecharge supplémentaire se produit pour trouver de nouveaux itinéraires, mais les pro-tocoles proactifs utilisent plus de bande passante et de ressources que les protocolesréactifs.Le protocole AODV besoin de découvrir la route en premier afin d’envoyer les don-nées réelles, de sorte que le temps de latence de recherche affecte du protocole AODV,OLSR n’a pas besoin de faire le travail supplémentaire pour la découverte de la routede sorte qu’il fournit une faible latence de transmission de paquets unique . La réac-tivité des changements topologiques de détection dans OLSR peut être améliorée enréduisant l’intervalle de temps de messages de contrôle périodiques. L’inconvénient estqu’il OLSR utiliser en permanence la bande passante, mais AODV essaie de garder labande passante faible pour le maintien des routes.le protocole OLSR est plus efficace dans les réseaux à haute densité et de trafic trèssporadique. Mais la situation est meilleure lorsque le entre un grand nombre d’hôtes.Les mesures de qualité sont faciles à développer pour le protocole actuel. OLSR exigequ’il ait en permanence une certaine largeur de bande afin de recevoir les messages demises à jour de la topologie.

9

1.5 Modèles de traficMANET soutient différents types de trafics et les trafics les plus importants et

fréquemment utilisés sont TCP, VBR et CBR trafique ici VBR signifie un débit binairevariable et CBR désigne le taux binaire constant. Le type de trafic sélectionné à traversla procédure de routage va influencer les performances du protocole de routage.

TCP : Transmission Control Protocol

Le Transmission Control Protocol (TCP) soulève un certain nombre de questionsen cas de besoin de travailler dans un environnement sans fil. En particulier, dans unréseau ad hoc, il doit faire face à de nouveaux défis difficiles tels que la haute probabilitéde défaillances à la fois de séparation du réseau et la route dus à la mobilité.Dans un scénario adhoc tous les nœuds peuvent se déplacer librement et de manièreimprévisible, ce qui rend le contrôle de congestion TCP assez difficile car il est un mé-canisme basé sur l’horloge. Par conséquent, les stratégies de détection d’erreur et dereprise sur erreur inhérentes à besoin de TCP standard pour être adaptés afin d’adap-ter cet environnement. En particulier, puisque les erreurs dans cet environnement seproduit non seulement en raison de la congestion, mais aussi en raison de contraintesmoyennes et de la mobilité, TCP doit distinguer la nature de l’erreur afin qu’il puisseprendre les mesures les plus appropriées pour chaque cas. En outre, le lien et la coucheréseau algorithmes émergents pour ce type de réseau peuvent jouer un rôle clé sur laperformance TCP. De même, des facteurs tels que chemin asymétrie (qui peut aussi êtrecausée par des stratégies de couches inférieures, entre autres éléments) et la taille de lafenêtre de congestion pourraient également affecter les performances de ce protocole.

CBR : Constaint Bit Rate

La catégorie de service CBR est utilisé pour les connexions qui transportent le traficà un débit binaire constant, où il ya une confiance inhérente sur la synchronisationde temps entre la source et la destination du trafic. CBR est adapté pour tout typede données pour lesquelles les systèmes d’extrémité nécessitant un temps de réponseprévisible et une quantité statique de la bande passante disponible en permanence pourla durée de vie de la connexion. Ces applications comprennent des services tels que lavisioconférence, la téléphonie (services vocaux) ou tout type de service à la demande,tels que la voix et l’audio interactif.

10

VBR : Variable Bit RateVBR est une alternative à CBR et est soutenu par certains codecs. Quoique CBR

vise à maintenir le débit des médias codé, VBR vise à atteindre la meilleure qualitépossible des médias codé. La qualité du contenu codé est déterminé par la quantité dedonnées qui est perdue lorsque le contenu est compressé et décompressé. De nombreuxfacteurs affectent la perte de données dans le processus de compression, mais en général,la plus complexe des données d’origine et plus le taux de compression le plus en détailest perdue dans le processus de compression.Il existe trois types d’encodage VBR : sans contrainte, avec contrainte et un autre basésur la qualité de service.

VBR basé sur la qualité de service

Ce type permet de spécifier un niveau de qualité pour un flux multimédia numériqueau lieu d’un débit binaire. Le codec sera alors encoder le contenu de sorte que tous leséchantillons sont de qualité comparable.

VBR sans contrainte

le codec utilise une valeur en tant que le débit binaire moyen pour le flux et code desorte que la qualité est aussi élevé que possible tout en maintenant la moyenne. Le débitréel à tout moment dans le flux codé peut varier grandement de la valeur moyenne.

VBR avec contrainte

En spécifiant un débit maximum et une fenêtre maximum de mémoire tampon dansle profil, le codec utilise ces valeurs maximales afin de déterminer comment les donnéesà comprimer. Si les valeurs maximales sont assez élevé, ce type va produire le mêmeflux codé comme le VBR sans contrainte.

1.6 qualité de servicesPour toutes les applications des réseaux AdHoc, à portée plus ou moins importante,

il est indispensable de garantir un certain niveau de qualité de service en termes dedélai de transmission, de taux de perte d’informations et de bande passante.

11

Ratio de livraison de paquetsRapport de livraison de paquets est calculé en divisant le nombre de paquets reçus

par la destination par le nombre de paquets émis par la source. Il spécifie le taux deperte de paquets, ce qui limite le débit maximal du réseau.

DébitLe débit peut être définit comme le pourcentage de paquets reçus par la destination

parmi les paquets envoyés par la source. Il est la quantité de données par unité de tempsqui est fournie d’un nœud à un autre par l’intermédiaire d’une liaison de communication.Le débit est mesuré en bits par seconde.

JitterIl est la variation dans le temps entre les arrivées de paquets. Il mesure la stabilité

de la réponse de l’algorithme à des changements topologiques. Il est la déviation parrapport à la latence ou retard idéal. Elle est causée par la congestion du réseau, unchangement de topologie de réseau soudaine ou des changements d’itinéraire.

ConclusionNous avons tout au long de ce chapitre met l’accent sur les réseaux mobiles AdHoc.

Afin d’étudier ses caractéristiques, il est de coutume d’abord définir ce que nous enten-dons par une instance d’un réseau mobile AdHoc. Ce dernier est fait en utilisant d’unoutil du simulation qui sera décrit dans le chapitre suivant.

12

Chapitre 2

Network Simulator 2

IntroductionUn simulateur de réseau est une technique de mise en œuvre du réseau de l’ordi-

nateur. Grâce à lui, le comportement du réseau est calculée soit par le réseau entitésinterconnexion utilisant des formules mathématiques, ou en capturant et en lecture desobservations à partir d’un réseau de production.Avant de commencer la réalisation du notre projet, il faut choisir les outils nécessairespour l’implémenter. Pour cela nous avons choisi de travailler avec la virtuelle MachineVmware où nous avons installer une plate-forme de logiciel open source, Ubuntu 15.04,et le Network Simulator NS 2.35.

2.1 Description Générale

Les outils des simulationsDans le domaine de réseaux, il existe différents types de simulateurs. dans cette

partie nous allons découvrir les différences entre eux.Network Simulator 2 - NS2 • Logiciel de simulation multicouche.

• Interface de programmation en Otcl (Tool Command Langage) et noyau écriten C++.• Développement orienté objet.• Adapté aux petits réseaux.

13

• Exécution lente mais pas de compilation.Network Simulator 3 - NS3 • C’est un programme open source , sous les termes

GNUGPL v2.• Peut être utilisé sur les plateformes Linux/Unix, OS X(Mac), et Windows (via

Cygwin ou une machine virtuelle).• Deux langages de programmation : C + +, Python.• Contrairement à NS2, tout est écrit en C++ sous NS3.• Beaucoup plus rapide en termes d’exécution (tout est préalablement compilé).• NS3 plus performant que NS2 en termes de gestion de mémoire.

J-SIM • J-Sim permet de simuler des réseaux de l’ordre de 1000 nœuds. Le passageà l’échelle peut toutefois être amélioré• Le simulateur utilise différemment deux langages : Java et TCL• L’analyse des résultats est aisée et son architecture très modulable.• L’architecture et le code sont suffisamment bien structurés pour permettre une

prise en main relativement rapide• Il permet d’utiliser n’importe quelle application Java comme générateur de

traficGlobal Mobile Simulator - Glomosim • Il permet la simulation d’environnement

à grande échelle pour des réseaux sans fil et filaires• Il est capable de simuler un réseau purement sans fil, avec tous les protocoles

de routage que cela inclut (AODV, DSR, ODMRP, WRP, FSR, ...).OMNET++ • Il a principalement pour but de simuler des communications réseaux.

• son architecture de base flexible lui permet même de simuler des architecturesmatérielles et des processus commerciaux.• Omnet++ gère nativement le TCP / IP, le SCSI et le FDDI.• Les composants d’OMNET++ sont codés en C++, puis assemblés sous un

modèle d’architecture plus large• codé sous un langage fédérateur de haut niveau : le NED.• Les modèles peuvent être réutilisés librement et gratuitement.

Domaine d’utilisation de Ns2 et Ns3Les deux simulateurs de réseaux ciblent un même domaine d’utilisation qui est la

recherche et l’éducation. Ce domaine-là apparait par exemple dans la mise en placed’une topologie qui n’a pas encore été testée et de pouvoir modifier ses paramètres,tout comme ces simulateurs sont utilisés pour tester de nouveaux protocoles avant deles utilisés réellement.

14

Le choix de NS2

NS-2 est utilisé sous un environnement Linux. Certaines membres de l’équipe utiliseCygwin pour utiliser NS-2 sous Windows. Le logiciel doit donc être compatible avecUnix et Windows. Le choix s’est donc porter sur Java. Ce langage en plus d’ être mul-tiplateforme dispose de nombreuses API répondant à nos besoins.La partie principale de l’application est la création graphique de la topologie. L’ergono-mie étant très importante, l’utilisation d’un module graphique complet est nécessaire.l’API JGraph présente ces caractéristiques. Ce composant permet de créer des dia-grammes, des graphes à état, ou toute sorte de graphe basé sur des principes de nœudset de liens. De plus les entités peuvent prendre n’importe quelle forme afin de cor-respondre aux besoins du développeur. Cette API dispose de fonctions de sauvegardequi ne seront pas utilisés puisque le logiciel a besoin de stocker d’autres informationspropres à chaque entité.Pour la gestion des sauvegardes de graphes ainsi que des sauvegardes de configurationle choix s’est porté sur l’utilisation de Extensible Markup Language (XML). L’APIretenue pour cette tâche est JDom, car cette API propose une interface d’exploitationsimple.

Avantages

• Observations des états des systèmes• Etudes des points de fonctionnement d’un système• Etudes de systèmes à échelle de temps variable• Etudes de l’impact des variables sur les performances du système• Etude d’un système sans les contraintes matérielles

Inconvénients

• La conception de modèles peut nécessiter des compétences spéciales• Une autre forme d’analyse plus proche de la réalité est peut être nécessaire• Résultats difficilement interprétables• Résultats pas forcément généralisable• Résultats sont en fonction des entrées du système

15

2.2 Présentation du NS 2

Le Network Simulator 2 est un ensemble d’outils qui simule le comportement duréseau ; il permet de créer des topologies réseaux, consigner les évènements qui se pro-duisent dans toute charge et aussi d’analyser ces évènements afin de comprendre lecomportement du réseau. Le simulateur utilise le langage orienté objet OTCL dérivéde TCL pour la description des conditions de simulation sous forme du script en four-nissant les caractéristiques des liens physiques, les protocoles utilisé, le type de traficgénéré par les sources, les événements, etc. L’observation de ce comportement est sefait via le NAM.

Script TCL-OTCL

TCL est un langage conçu pour une utilisation par un développeur de l’applicationqui peut être participé à travers une demande ou pourrait être utilisé par une applica-tion de diverses manières, par exemple, pour permettre à un utilisateur de fournir uneinitialisation personnalisée pour l’application.L’OTCL est un TCL avec les extensions orientée objet.NS2 utilise otcl pour le programmeur de simulation pour créer les objets de réseau dansla mémoire et d’insérer des événements initiaux dans la file d’attente de l’événement.

NAM

NAM est un outil d’animation basé sur Tcl pour les traces de simulation de réseauxd’observation et des traces de paquets du monde réel. Il prend en charge la topologiemise en page, l’animation au niveau du paquet, et divers outils de contrôle de données.Cette visualisation fournit une représentation du graphe du réseau sur laquelle on peutvoir les paquets circuler, suivre le niveau des files d’attente et observer le débit courantdes liaisons.

16

Figure 2.1 – représentation d’un graphe sous NAM

Xgraphe

Xgraph est une application X-Windows qui inclut le traçage interactif et graphique,animation et déritives, de portabilité et de corrections de bugs.Donc, pour tracer les caractéristiques des paramètres NS2 comme le débit, la fin d’unretard de la fin, les paquets d’informations, etc peut être tracée en utilisant xgraph.Le fichier xgraph affiche les informations à propos de la surcharge avec la taille duréseau, Overhead est comparé avec quatre protocoles de routage comme AODV, DSR,DSDV et NEAODV. Les valeurs sont prises à partir des divers fichiers de trace.

17

Figure 2.2 – exemple d’un graph

2.3 Modèles de mobilitéPour soignesement et systématiquement analyser un nouveau réseau adhoc, il est

important de simuler le protocole et d’étudier son performance. La simulation du pro-tocole dispose des paramètres clés y compris , le modèle du mobilité et modèle de trafic.

Modèle Random Way Point (RWP)C’est un modèle élementaire ; il décrit le modèle du mouvement de chaque nœud

indépendemment en termes simples.Dans ce modèle , les nœuds sont placés dans une zone où ils ne peuvent pas la quitter.Chaque nœud possède une position , une vitesse et une destination initiale. Lorsqu’ilatteint sa destination, il prend un temps du pause pour une réflexion afin d’avoir aléa-toirement sa nouvelle position, sa nouvelle vitesse et aussi sa nouvelle destination. Cecomportement est répété pour la durée de la simulation.

Modèle Random Walk (RW)Ce modèle a été élaboré pour émuler les mouvements imprévisibles des déplacements

des nœuds d’une manière inattendues. Les nœuds mobiles dans ce modèle se déplace

18

de façon aléatoire et librement sans aucune restriction d’un endroit à l’autre. La desti-nation, la vitesse et la direction sont également choisis au hasard et indépendammentde tous les autres nœuds du réseau. Les entités dans le modèle de la RW sont trèsinespérés comme un nœud mobile se déplace de son emplacement actuel vers un nouvelemplacement en choisissant au hasard une direction et la vitesse dans laquelle voyager.La nouvelle vitesse et nouvelle direction sont tous deux choisi de gammes prédéfinies,[vitesseMin, vitesseMax] et [0, 2π], respectivement.

Modèle Random Direction (RD)Ce modèle est un peu semblable du modèle RWP. Avant le processus du simulation

, le nœud choisit un nombre constant des nœuds à atteindre. Une fois il arrive à sadirection, il prend un temps de pause pour une réflexion pour choisir une autre directionet continue son processus du simulation.

2.4 Installation du NS

Mise en place des conditions préalablesAprès le téléchargement du Network Simulator, NS-allinone-2.35, nous avons le placé

dans notre dossier personnel du système Ubuntu ( /home/rihab/documents ).La mise à jour du système Ubuntu est essentielle afin de bien préparer l’environne-ment. Aussi, nous devons installer les essentielles packages reliée à NS, en utilisant cescommandes ci-dessous.sudo apt-get update L’option update met à jour la liste des fichiers disponibles dans

les dépôts APT présents dans le fichier de configuration /etc./apt/sources.list.sudo apt-get dist-upgrade L’option dist-upgrade met à jour tous les paquets instal-

lés vers les dernières versions en installant de nouveaux paquets si nécessaire.sudo apt-get upgrade L’option upgrade met à jour tous les paquets installés sur le

système vers les dernières versions (couramment utilisé).Sudo apt-get install build-essential autoconf automake Permet d’installer le lo-

giciel de base dont vous aurez besoin pour compiler à partir des sources, commele compilateur GCC et d’autres services.

sudo apt-get install tcl8.5-dev tk8.5-dev Package de TCL.Sudo apt-get install perlxgraphlibxt-dev libx11-dev libxmu-dev Package du NAMSudo apt-get install gcc-4.4 Permet d’installer le GNU MAKE pour que vous de-

vriez pouvoir compiler le logiciel en C / C ++.

19

Installation du NS2Nous avons accédé au dossier où nous avons placé le dossier d’installation du NS2

et nous l’avons extrait.

Figure 2.3 – Commande d’extraction du dossier

Figure 2.4 – Résultat d’extraction

Ensuite, nous avons modifié le fichier ls.h qui se trouve sous « ns-allinone-2.35/ns-2.35/linkstate » pour ne pas rencontrer des problèmes avec NS2 au cours de son instal-lation.

Figure 2.5 – Emplacement fichier ls.h

Nous l’avons ouvert, puis nous avons remplacé le mot "erase" par "this->erase" auniveau de la ligne 137 , puis nous avons sauvegardé ces modifications.

20

Figure 2.6 – Fichier ls.h avant modification

Figure 2.7 – Fichier ls.h après modification

Nous avons commencé l’installation tout en tapant la commande " ./install " aprèsl’accés au dossier décompressé du NS2.

Figure 2.8 – Installation NS2

Les variables d’environnementA ce stade-là, nous avons bien installé NS, et il y a quelques variables d’environne-

ment qui doivent être ajoutées au niveau du fichier bashrc, donc nous avons l’édité àl’aide du commande :

21

Figure 2.9 – Fichier bashrc

Ensuite, nous avons ajouté le code affiché ci-dessous à la fin du fichier bashrc enremplaçant « /path_to » par le chemin dont lequel nous avons mis le dossier du ns2,(/home/rihab/documents) dans notre cas, puis nous avons sauvegardé les modificationsapportés.

Figure 2.10 – Configuration du chemin de fichier bashrc

Par la suite, nous avons redémarré le système pour qu’il prenne en compte lesmodifications accordés et nous avons rechargé le fichier bashrc :

Figure 2.11 – Rechargement du fichier bashrc

22

Vérification de l’installationLa dernière étape à assurer est la vérification du bon fonctionnement du NS2. Pour

cela, nous avons accédé au dossier NS2 et nous avons lancé la commande "validate".

Figure 2.12 – Vérification du fonctionnement de NS2

D’après la figure 2.12, nous avons bien installé NS2 sur notre système Ubuntu, nouspouvons alors commencer à l’utiliser en tapons la commande NS dans le terminal, Sinous avons reçu le signe «%», cela signifie que NS est en cours d’exécution.

Figure 2.13 – Exécution du NS2

ConclusionDans ce chapitre, nous avons bien décrit les différents outils de simulation en mettant

l’accent sur l’outil Network Simulator 2... Dans le chapitre suivant, nous allons présenterla réalisation du notre projet à l’aide de ce dernier outil.

23

Chapitre 3

Réalisation

Introduction

3.1 Description du fichier TCL

Cette simulation se compose de 8 nœuds mobiles, nous trouve une connexion entrechaque 2 nœuds, une pour la source (agent UDP) et l’autre pour destination(agentSink). Un trafic CBR est attaché a une connexion dont on spécifie quelques paramètresimportantes comme le taille du paquet et l’intervalle du temps entre deux paquets.Le Taux d’un nœud de transmission est de 600 Kbps. Le temps de simulation a durépendant 300 secondes. Le fichier TCL est décrit comme suit :

25

Figure 3.1 – Description fichier TCL (1)26

Figure 3.2 – Description fichier TCL (2)

27


28


29


30


31


32


33

3.2 Exécution du fichier TCLL’exécution du fichier TCL se fait avec la commande "exec". La ligne suivante nous

montre le résultat de cette dernière

Figure 3.9 – Capture simulation sous l’outil NAM

3.3 Analyse du fichier traceLe contenu du fichier de trace consiste en une liste d’évènements dates se produisant

chronologiquement, à raison d’un évènement par ligne.Les évènements répertories dans le fichier de trace sont, à quelques exceptions près,de deux types : d’une part ceux concernant le d’emplacement des nœuds, d’autre partceux concernant le parcours des différents types de paquets. C’est ce dernier type d’in-formation qui s’avère le plus intéressant du point de vue de l’analyse du routage. Ilpermet de connaitre, à chaque fois qu’un paquet passe d’un nœud a un autre ou passe- au sein d’un même nœud - d’une couche a une autre, le contenu de ses en-têtes et desinformations caractéristiques (identifiants, taille, etc...).Description du fichier traceQuand l’on utilise la commande ’trace-all’, une trace de chaine de caractère sera créé.La figure suivante représente un fichier de trace généré par la simulation.

34

Figure 3.10 – Capture du fichier trace

La signification des différents champs du fichier de trace est décrite comme suit :

Figure 3.11 – Description du fichier trace

35

3.4 Critères de sélection des protocolesPour comparer les protocoles de routages des réseaux Ad hoc plusieurs paramètres

sont à tester.Ces paramètres peuvent décrire les résultats de simulation et nous parlerons dans ce casde métriques de performance, où ils décrivent des variables ou des données d’entrées desimulation. Nous sommes intéressées essentiellement à la mobilité, débit, la quantité dutrafic de contrôle généré et le taux de paquets reçus , ce qui influe sur la fiabilité desliaisons.Parmi ces métriques nous citons :La Perte des paquets elle corresponde au non délivrance d’un paquet de données

par rapport à ceux envoyés.

Figure 3.12 – La perte des paquets

→ La perte de paquets peut être causée par un certain nombre de facteurs, no-tamment la dégradation de signal sur le réseau en raison de multi-chemin, la pertede paquets à cause de la congestion du canal, les paquets corrompus rejetés entransit, matériel réseau défectueux. → nous avons constaté aussi que le taux deperte diminue avec l’augmentation de nombre de nœuds, par contre il augmenteavec l’augmentation de la vitesse de la mobilité.

Taux de paquets reçus délivrés C’est le nombre de paquets reçus par rapport aunombre de paquets envoyés.

36

Figure 3.13 – Taux de paquets reçus délivrés

Mobilité Elle indique le mouvement des nœuds, elle peut être faible ou forte. Le calculse fait en mesurant le mouvement relatif d’un nœud par rapport aux autres.

Figure 3.14 – Délai moyen de transfert d’un paquet de donnée

37

Autres critères prises en considération :

Délai ou temps de réponse elle caractérise le retard entre l’émission et la ré-ception d’un paquet.

Délai moyen de transfert d’un paquet de donnée C’est le délai moyen prispar un paquet de données pour transiter d’une application à une autre.

→ Nous avons constaté que le débit binaire est inversement proportionnel aunombre de nœuds et la vitesse de mobilité (le débit baisse si le nombre de nœudset la vitesse de mobilité croient).→ Le débit du protocole AODV est mieux quand la vitesse de nœuds augmente.

Temps de pause Il indique le temps moyen où les nœuds ne sont pas en mouvement.Plus longues sont les pauses, moins le mouvement est important.

3.5 Comparaison des résultats avec OLSRDans les réseaux Ad hoc plusieurs protocoles de routage sont connues, les plus uti-

lisés sont : AODV et OLSR.Nous nous proposons de les mettre en application dans un certain nombre de scénarios.Les diverses scénarios doivent permettre de dégager l’influence sur chacun de para-mètres tels que le nombre de connexion et la vitesse des nœuds.

D’après les résultats de la simulation, nous avons constatés quelque remarque diffé-rences entre les deux protocoles cités au-dessus :

→ Les deux protocoles sont très similaires en termes de performances.→ AODV est un peu avantageux en termes de rapidité de la mise à jour des routes,par contre, OLSR admet un retard de mise à jour des informations sur l’état de lien àcause de l’attente des paquets Hello perdus.→ OLSR charge moins le réseau qu’AODV en termes de densité.→ Dans des réseaux moyens, OLSR et AODV sont équivalent.→ OLSR à un grand avantage sur AODV lors de l’établissement de communicationscourtes car les routes sont disponible immédiatement.→ Dans la plupart des cas, les messages de contrôles d’AODV sont légèrement plusnombreux que ceux d’OLSR.

38

ConclusionTout au long de ce chapitre, nous avons découvrir les différentes types des simula-

teurs réseaux en spécifiant les différences entre eux. Dune part, nous avons bien expliquéles avantages du choix du NS2 comme étant un bon simulateur. Aussi nous avons pré-senté les différentes étapes nécessaires pour l’installation de ce simulateur. D’une autrepart, nous avons présenté une description détaillé du fichier TCL, ainsi que son fichierde trace. Ensuite, nous avons expliqué quelques critères de performances telles que ledébit, taux de pertes des paquets, etc. Nous avons fini par une comparaison généraleentre deux protocoles de routages AODV et OLSR qui sont plus utilisés dans le domainede réseaux.

39

Conclusion générale

Notre projet se concentre dans le domaine de réseaux mobiles, plus précisément leréseau AdHoc. Nous avons présenté une étude générale sur ce réseau, son architecture,son modèle de trafic, les services offerts, les différents types de protocole de routage ,les plus utilisés et les plus connues, ainsi que les paramètres qui influes sur la qualitéde service de ce réseau tels que le Débit, la perte, la bande passante, etc.Ce projet nous a permis aussi de comprendre les différents types de protocoles, plusprécisément les protocoles du routage proactif tel qu’AODV et OLSR.Nous nous sommes intéressées au protocole AODV puisqu’il est basé sur l’échange despaquets et la mise à jour des tables de routage. En fait, ce protocole illustre parfaitementle concept de routage proactif en exécutant le fichier TCL qui présente la simulation dece protocole.Ce n’est malheureusement pas le cas pour le protocole OLSR. Nous avons cependanttrouvé une procédure par ajouter ce protocole à l’outil de simulation. En effet, il existeun patch des sources de NS qui ajoute la connaissance d’OLSR. Une fois les sourcespatchée, il ne reste plus qu’à recompiler NS. Ceci, nous permet de connaitre la perfor-mance de ces différents protocoles.

Pour conclure, durant cette période, ce projet nous a permis d’améliorer notreconnaissance dans le domaine des réseaux mobiles.

41

Liste des figures

1.1 Architecture de connexion AdHoc . . . . . . . . . . . . . . . . . . . . . . . 41.2 Ad hoc On Demand Distance Vector . . . . . . . . . . . . . . . . . . . . . 7

2.1 représentation d’un graphe sous NAM . . . . . . . . . . . . . . . . . . . . 172.2 exemple d’un graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 Commande d’extraction du dossier . . . . . . . . . . . . . . . . . . . . . . 202.4 Résultat d’extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 Emplacement fichier ls.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6 Fichier ls.h avant modification . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Fichier ls.h après modification . . . . . . . . . . . . . . . . . . . . . . . . . 212.8 Installation NS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.9 Fichier bashrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.10 Configuration du chemin de fichier bashrc . . . . . . . . . . . . . . . . . . 222.11 Rechargement du fichier bashrc . . . . . . . . . . . . . . . . . . . . . . . . 222.12 Vérification du fonctionnement de NS2 . . . . . . . . . . . . . . . . . . . . 232.13 Exécution du NS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Description fichier TCL (1) . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Description fichier TCL (2) . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Description fichier TCL (3) . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Description fichier TCL (4) . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 Description fichier TCL (5) . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 Description fichier TCL (6) . . . . . . . . . . . . . . . . . . . . . . . . . . 313.7 Description fichier TCL (7) . . . . . . . . . . . . . . . . . . . . . . . . . . 323.8 Description fichier TCL (8) . . . . . . . . . . . . . . . . . . . . . . . . . . 33

42

3.9 Capture simulation sous l’outil NAM . . . . . . . . . . . . . . . . . . . . . 343.10 Capture du fichier trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.11 Description du fichier trace . . . . . . . . . . . . . . . . . . . . . . . . . . 353.12 La perte des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.13 Taux de paquets reçus délivrés . . . . . . . . . . . . . . . . . . . . . . . . . 373.14 Délai moyen de transfert d’un paquet de donnée . . . . . . . . . . . . . . . 37

43

Bibliographie

[1] Réseaux Wifi, cours M1 SSICE, Réseaux Nouvelles Génération, Dr. So-nia bEN REJEB CHAOUCH, 2015

[2] Réseau WLAN, cours L3 SE, Technologies des réseaux sans fil, Dr. Mo-hamed LAARAYEDH, 2014

[3] Norme 802.11 et réseaux AdHoc, Cours M1 SSICE, Réseaux NouvellesGénération, Mr. Mohamed HEDHILI, 2014

[4] http ://www.guill.net/index.php ?cat=3&pro=2&rfc=17,Scott Carsonet Joseph Macker, visité le 14/10/2015 à 11h40

[5] http ://fr.slideshare.net/boutitimehdi/support-de-cours-reseaux-avec-et-sans-fil ?related=1, visité le 14/10/2015 à 21h29

[6] https ://fr.wikipedia.org/wiki/Routage_ad_hoc, visité le 18/10 à 22h50

[7] http ://toubkal.imist.ma/bitstream/handle/123456789/7121/THESE_OUDIDI.pdf ?se-quence=1, visité le 20/10/2015 à 20h00

[8] http ://www.netlab.tkk.fi/ esa/java/rwp/rwp-model.html, visité le20/10/2015à 20h07

[9] http ://research.ijcaonline.org/volume111/number7/pxc3901249.pdf, vi-sité le 20/10/2015 à 21h18

[10] https ://www.ietf.org/rfc/rfc3626.txt, visité le 17/11/2015 à 22 :22

[11] http ://www.danscourses.com/CCNA-2/link-state-routing-protocols.html, visité le 17/11/2015 à 23 :01

45

Liste des acronymesAODV Adhoc On Demand Distance VectorCBR Constant Bit RateCLR ClearDAG Directed Acyclic GraphDSDV Destination Sequenced Distance VectorDSR Dynamic Source RoutingGCC GNU Compiler CollectionGLOMOSIM Global Mobile SimulatorIEEE Institute of Electrical and Electronics EngineersIP Internet ProtocolISM industrial scientific and medicalJ-SIM Joint SimulationLSR Link State RoutingManet Mobile Adhoc NetworkMPR Multipoint RelayNAM Network AnimatorNED Network Description LanguageNS Network SimulatorOLSR optimized link state routingOS Operating SystemOTCL Orient Tool Command LanguageQRY QueryRD Random DirectionRERR Route ErrorRIP Routing Information ProtocolRMP Reactif Manet ProtocolRREP Route ReplayRREQ Route RequestRW Random WalkRWP Random Way PointTCL Tool Command LanguageTCP Transmission Control ProtocolTORA Temporally Ordered Routing AlgorithmUDP user Datagram ProtocolUPD UpdateVBR Variable Bit RateWIFI Wireless FiedelityWPAN Wireless Personal Area Network

46

47

Education

Simulation d'un réseau Ad-Hoc sous NS2