18 février 2016

Remerciements

Nous tenons à remercier en pre-

mier temps, notre professeur, Mme
Sonia BEN REJEB, qui nous a
donné la chance d’enrichir nos
connaissances.
Nous remercions également Mme
Samia ALOULOU pour l’aide et
les conseils concernant les missions
évoquées dans ce rapport.

Rabeb BOUMAIZA
Rihab 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 outil
indispensable 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 à la
densité du réseau et à la charge du trafic y circulant ainsi que de valider la variation
du taux d’acceptation de connexions en présence d’un contrôle d’admission basé sur la
disponibilité de la bande passante dans les noeuds de routage.
Mots clés : réseau ad hoc, protocole de routage AODV, simulation NS2, évaluation
de performance, qualité de service, réservation de bande passante, contrôle d’admission.

Abstract
the 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 for
studying the performance of routing protocols in these networks.
Simulation results were represented on graphs and interpreted. These simulations have
led us to know how the protocol operates AODV facing the network density and traffic
load 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 in
the routing nodes.
Key words : ad hoc network, AODV routing protocol, NS2 simulation, performance
evaluation, quality of service, bandwidth reservation, admission control
 Sommaire

Introduction Générale 1

1 Réseaux Mobile AdHoc 3

1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Architecture de connexion . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Services offerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 protocoles de routages . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Modèles de trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 qualité de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Network Simulator 2 13
2.1 Description Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Présentation du NS 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Modèles de mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Installation du NS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Réalisation 25
3.1 Description du fichier TCL . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Exécution du fichier TCL . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Analyse du fichier trace . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Critères de sélection des protocoles . . . . . . . . . . . . . . . . . . . . 36
3.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 à un
protocole de communication commun. Toutefois , la croissance exponentielle d’Internet
a induit la naissance des nouvelles technologies de réseaux informatiques notemment le
réseau sans fil.

Ce dernier est un ensemble des nœuds qui s’interconnectent à travers des ondes
radio. 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 et
mode adhoc. le mode infrastructure s’appuie sur l’établissement des connexions via des
points 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 une
zone géographique plus ou moins étendu, c’est la raison pour laquelle nous entendons
parfois parler de "mobilité". Cette qualification a donné naissance au mode ad hoc ou
encore MANET.

Ce type d’architecture vient à éliminer l’emploi des points d’accés. Chaque nœud
alors sera comporter comme un récepteur, un émetteur et aussi un routeur WIFI pour
ses 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, fonctionnants
avec des routeurs mobiles, par les nœuds intermédiaires pour acheminer les paquets de
message à la bonne destination. Le protocole qui nous intéresse dans ce mini-projet est
le 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 de
paquets, taux d’utilisation, le retard et le nombre de sauts sont souvent utilisés comme
des 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émentant

un modèle de simulation sous Network Simulator avec le protocole de routage AODV
en particulier afin d’évaluer son impact sur le taux de paquet reçus délivrée, le taux
de 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 une

vision d’ensemble de la thématique des réseaux adhoc. Le deuxième est consacré à la
pré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étriques
du protocole AODV sont évaluées. Les résultats de la simulation sont affichés sur des
graphes et sont interprétés. Une conclusion générale et des perspectives font la fin de
ce rapport.

2
 Chapitre 1

Réseaux Mobile AdHoc

Introduction

Au niveau de ce chapitre, nous définirons la nouvelle technologie des réseaux sans

fil tout en présentant ses services offerts, son architecture de connexion, ses modèles
de trafic, les protocoles de routage et en finissant par l’étude de la qualité de service
qu’elle dispose.

1.1 Description

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

3
1.2 Architecture de connexion

Figure 1.1 – Architecture de connexion AdHoc

1.3 Services offerts

Chaque 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éseaux
locaux, 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’interconnecter
facilement. Ils sont autonomes et possèdent à la fois les fonctionnalités de relais
et de point de communication.
Mobilité La topologie du réseau peut changer d’autant plus rapidement que les nœuds
sont mobiles.
Auto-Configuration L’auto configuration permet aux nœuds de s’intégrer facilement
dans un réseau. Elle facilite la gestion du réseau car l’interconnexion des éléments
ne 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éseaux
ad hoc.

4
1.4 protocoles de routages
Des protocoles de routage ont été proposés pour prendre en compte les spécificités
des réseaux MANET.

DSR : Dynamic Source Routing

DSR 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 au
réseau d’être complètement auto-organisé et auto-configuré, sans avoir besoin de toute
l’infrastructure ou de l’administration de réseau existant. Le protocole est composé de
deux principaux mécanismes de la découverte de la route et la maintenance de cette
dernière, qui travaillent ensemble pour permettre les nœuds de découvrir et de maintenir
les routes vers des destinations arbitraires dans le réseau adhoc. Tous les aspects du
protocole fonctionnent entièrement sur la demande, permettant à la tête de routage
de paquets de DSR à l’échelle automatiquement seulement ce qui est nécessaire pour
réagir aux changements dans les routes actuellement en usage. Le protocole permet à
plusieurs routes de circuler vers toute destination et permet à chaque expéditeur de
sé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és
de la mobilité.

DSDV : Destination-Sequenced Distance Vector

Ce 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 du
RIP classique de table de routage. En utilisant le numéro de séquence nouvellement
ajouté, les nœuds mobiles peuvent distinguer les informations d’itinéraire vicié de la
nouvelle 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 sont
connus soit directement, soit par l’intermédiaire des voisins. Chaque nœud a une seule
entrée dans la table de routage. L’entrée va avoir des informations sur l’adresse IP du
nœ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 atteindre
la 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 cette
mise à jour le nœud diffuse sur l’ensemble de sa table de routage.
2. Mises à jour de déclenchement
Ces mises à jour sont envoyées chaque fois qu’un noeud reçoit un paquet DSDV
qui a provoqué un changement dans sa table de routage. Le document d’origine
ne mentionne pas clairement quand pour ce changement dans le tableau devrait
une mise à jour de DSDV être envoyé. Le courant Mise en œuvre et envoie une
mise à 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 est
plus élevée indépendamment de la métrique. Si la mise à jour avec le même numéro de
séquence est reçu, un HopCount sera donné avec priorité plus faible.

AODV : Ad hoc On Demand Distance Vector

AODV 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 les
pertes de paquets.
A chaque nœud, AODV maintient une table de routage. L’entrée de table de routage
pour une destination contient trois domaines essentiels : un nœud de saut suivant, un
numé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 une
forme d’horodatage, et est une mesure de la fraîcheur d’un itinéraire. Le nombre de
sauts représente la distance en cours au nœud de destination. Dans AODV, les nœuds
découvrent les itinéraires dans les cycles de demande-réponse. Un nœud demande un
itinéraire vers une destination en diffusant un message RREQ à tous ses voisins. Quand
un 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’une
route 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ême
la destination) répond avec un message de RREP. Cette MIQ est unicast le long des
routes inverse des nœuds intermédiaires jusqu’à ce qu’il atteigne le nœud demandeur
d’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œuds
qui potentiellement reçu son MIQ.

Sur réception des trois messages de AODV : RREQ, RREP et RERR, les nœuds
sont mis à jour la prochaine hop, numéro de séquence et les nombres de sauts de leurs
itiné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 Routing

Ce 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 à ce
que tout voisins de cette station soit joignable en un maximum de deux sauts à travers
les nœuds RMP : chaque nœud émet périodiquement la liste de ces voisins mais seuls
les 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 routage
dont algorithmes calculer les meilleurs chemins pour réseaux différemment Distance Vector protocoles
de routage. Considérant que les protocoles à vecteur de distance savent routes par des mesures de
distance et de vecteur (direction) tels que rapportés par les routeurs voisins, protocoles de routage
d’état de liens calculent leurs itinéraires du réseau par la construction d’une topologie complète de
la zone de réseau entier, puis en calculant le meilleur chemin de cette topologie ou carte de tous les
réseaux interconnectés.

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

TORA : Temporally Ordered Routing Algorithm

TORA 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 court
pour 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 le
plus 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 ou
plusieurs "voies" aval vers le nœud de destination à travers de multiples nœuds voisins
intermé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 une
destination.
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 chemins
aval à la destination". Ce DAG est appelé comme «Destinations Oriented DAG". Un
nœud marqué comme destination DAG est orientée vers le dernier nœud ou le nœud
de destination et aucun lien provenant de ce nœud. Il a la hauteur la plus basse. Trois
messages différents sont utilisés par TORA pour établir un chemin : le (QRY) un
message de requête pour la création d’un itinéraire, de mise à jour (UPD) un message
pour 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 entre
les noeuds en fonction de la hauteur. La mise en place de l’itinéraire de la source à la
destination est basée sur le mécanisme de DAG assurant ainsi que toutes les routes sont
boucle libre. Les paquets se déplacent du noeud de source ayant la plus grande hauteur
au noeud de destination avec la hauteur la plus basse. Il est le même haut en approche
descendante.

8
AODV vs OLSR

Comme protocole proactif, OLSR réduit la surcharge de commande forçant le MPR

pour propager les mises à jour de l’état de lien, aussi l’efficacité est acquise par rapport
au protocole de l’état de la liaison classique lorsque l’ensemble de MPR sélectionné est
aussi faible que possible. Mais l’inconvénient de cette est qu’elle doit maintenir la table
de routage pour tous les itinéraires possibles, donc il n’y a pas de différence dans les
petits 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 protocole
OLSR. 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éseau
avec le trafic léger et une faible mobilité des protocoles réactifs échelles parfaitement
aux grands réseaux à faible bande passante et les frais généraux de stockage. Comme
l’environnement indésirable pour les protocoles réactifs est le réseau à fort trafic avec un
grand nombre de destinations à forte mobilité. Cette situation entraînera qu’un grand
nombre 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 une
plus grande efficacité de routage que les protocoles réactifs dans le réseau avec le trafic
diffusée. Parce que les mises à jour proviennent de mises à jour périodiques et aucune
charge 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 protocoles
ré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 route
de 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 en
réduisant l’intervalle de temps de messages de contrôle périodiques. L’inconvénient est
qu’il OLSR utiliser en permanence la bande passante, mais AODV essaie de garder la
bande passante faible pour le maintien des routes.
le protocole OLSR est plus efficace dans les réseaux à haute densité et de trafic très
sporadique. 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 exige
qu’il ait en permanence une certaine largeur de bande afin de recevoir les messages de
mises à jour de la topologie.

9
1.5 Modèles de trafic
MANET 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 binaire
variable et CBR désigne le taux binaire constant. Le type de trafic sélectionné à travers
la 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 questions
en cas de besoin de travailler dans un environnement sans fil. En particulier, dans un
ré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ère
impré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 de
reprise 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 se
produit non seulement en raison de la congestion, mais aussi en raison de contraintes
moyennes et de la mobilité, TCP doit distinguer la nature de l’erreur afin qu’il puisse
prendre les mesures les plus appropriées pour chaque cas. En outre, le lien et la couche
réseau algorithmes émergents pour ce type de réseau peuvent jouer un rôle clé sur la
performance TCP. De même, des facteurs tels que chemin asymétrie (qui peut aussi être
causée par des stratégies de couches inférieures, entre autres éléments) et la taille de la
fenê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 synchronisation
de temps entre la source et la destination du trafic. CBR est adapté pour tout type
de données pour lesquelles les systèmes d’extrémité nécessitant un temps de réponse
prévisible et une quantité statique de la bande passante disponible en permanence pour
la durée de vie de la connexion. Ces applications comprennent des services tels que la
visioconfé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 Rate
VBR 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é de
données qui est perdue lorsque le contenu est compressé et décompressé. De nombreux
facteurs 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étail
est 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érique
au 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 de
sorte que la qualité est aussi élevé que possible tout en maintenant la moyenne. Le débit
ré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 dans
le 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ême
flux codé comme le VBR sans contrainte.

1.6 qualité de services

Pour 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 de
délai de transmission, de taux de perte d’informations et de bande passante.

11
Ratio de livraison de paquets
Rapport 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 de
perte de paquets, ce qui limite le débit maximal du réseau.

Débit
Le 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 temps
qui 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.

Jitter
Il 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 par
rapport à la latence ou retard idéal. Elle est causée par la congestion du réseau, un
changement de topologie de réseau soudaine ou des changements d’itinéraire.

Conclusion
Nous 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’un
outil du simulation qui sera décrit dans le chapitre suivant.

12
 Chapitre 2

Network Simulator 2

Introduction
Un 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és
interconnexion utilisant des formules mathématiques, ou en capturant et en lecture des
observations à partir d’un réseau de production.
Avant de commencer la réalisation du notre projet, il faut choisir les outils nécessaires
pour l’implémenter. Pour cela nous avons choisi de travailler avec la virtuelle Machine
Vmware 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 simulations
Dans 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 écrit
en 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
trafic
Global 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 architectures
maté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 Ns3

Les 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 place
d’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 de
les utilisés réellement.

14
Le choix de NS2
NS-2 est utilisé sous un environnement Linux. Certaines membres de l’équipe utilise
Cygwin pour utiliser NS-2 sous Windows. Le logiciel doit donc être compatible avec
Unix 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œuds
et 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 sauvegarde
qui ne seront pas utilisés puisque le logiciel a besoin de stocker d’autres informations
propres à chaque entité.
Pour la gestion des sauvegardes de graphes ainsi que des sauvegardes de configuration
le choix s’est porté sur l’utilisation de Extensible Markup Language (XML). L’API
retenue pour cette tâche est JDom, car cette API propose une interface d’exploitation
simple.

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 du

ré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 le
comportement 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 trafic
généré par les sources, les événements, etc. L’observation de ce comportement est se
fait via le NAM.

Script TCL-OTCL

TCL est un langage conçu pour une utilisation par un développeur de l’application
qui 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 une
initialisation 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 dans
la 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éseaux
d’observation et des traces de paquets du monde réel. Il prend en charge la topologie
mise 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 peut
voir les paquets circuler, suivre le niveau des files d’attente et observer le débit courant
des 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’un
retard 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 du
ré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’il
atteint 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. Ce
comportement 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épendamment
de tous les autres nœuds du réseau. Les entités dans le modèle de la RW sont très
inespérés comme un nœud mobile se déplace de son emplacement actuel vers un nouvel
emplacement 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 à sa
direction, il prend un temps de pause pour une réflexion pour choisir une autre direction
et continue son processus du simulation.

2.4 Installation du NS
Mise en place des conditions préalables
Aprè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 ces
commandes 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, comme
le 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 NAM
Sudo 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 NS2
Nous 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" au
niveau 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ès
l’accés au dossier décompressé du NS2.

Figure 2.8 – Installation NS2

Les variables d’environnement

A 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 en
remplaç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 modifications
apporté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 les
modifications accordés et nous avons rechargé le fichier bashrc :

Figure 2.11 – Rechargement du fichier bashrc

22
Vérification de l’installation
La 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, nous
pouvons alors commencer à l’utiliser en tapons la commande NS dans le terminal, Si
nous avons reçu le signe «%», cela signifie que NS est en cours d’exécution.

Figure 2.13 – Exécution du NS2

Conclusion
Dans 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ésenter
la 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 entre
chaque 2 nœuds, une pour la source (agent UDP) et l’autre pour destination(agent
Sink). Un trafic CBR est attaché a une connexion dont on spécifie quelques paramètres
importantes 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
 26
Figure 3.1 – Description fichier TCL (1)
 27

Figure 3.2 – Description fichier TCL (2)

 28

Figure 3.3 – Description fichier TCL (3)

 29

Figure 3.4 – Description fichier TCL (4)

 30

Figure 3.5 – Description fichier TCL (5)

 31

Figure 3.6 – Description fichier TCL (6)

 32

Figure 3.7 – Description fichier TCL (7)

 33

Figure 3.8 – Description fichier TCL (8)

3.2 Exécution du fichier TCL
L’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 trace

Le 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 part
ceux 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. Il
permet 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 des
informations caractéristiques (identifiants, taille, etc...).
Description du fichier trace
Quand 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 protocoles
Pour 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 cas
de métriques de performance, où ils décrivent des variables ou des données d’entrées de
simulation. Nous sommes intéressées essentiellement à la mobilité, débit, la quantité du
trafic de contrôle généré et le taux de paquets reçus , ce qui influe sur la fiabilité des
liaisons.
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 perte
de paquets à cause de la congestion du canal, les paquets corrompus rejetés en
transit, matériel réseau défectueux. → nous avons constaté aussi que le taux de
perte diminue avec l’augmentation de nombre de nœuds, par contre il augmente
avec 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 au
nombre 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 calcul
se 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 pris
par un paquet de données pour transiter d’une application à une autre.
→ Nous avons constaté que le débit binaire est inversement proportionnel au
nombre de nœuds et la vitesse de mobilité (le débit baisse si le nombre de nœuds
et 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 OLSR

Dans 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 communications
courtes car les routes sont disponible immédiatement.
→ Dans la plupart des cas, les messages de contrôles d’AODV sont légèrement plus
nombreux que ceux d’OLSR.

38
Conclusion
Tout 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 autre
part, nous avons présenté une description détaillé du fichier TCL, ainsi que son fichier
de trace. Ensuite, nous avons expliqué quelques critères de performances telles que le
débit, taux de pertes des paquets, etc. Nous avons fini par une comparaison générale
entre deux protocoles de routages AODV et OLSR qui sont plus utilisés dans le domaine
de réseaux.

39
 Conclusion générale

Notre projet se concentre dans le domaine de réseaux mobiles, plus précisément le

ré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, plus
pré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 des
paquets et la mise à jour des tables de routage. En fait, ce protocole illustre parfaitement
le concept de routage proactif en exécutant le fichier TCL qui présente la simulation de
ce protocole.
Ce n’est malheureusement pas le cas pour le protocole OLSR. Nous avons cependant
trouvé une procédure par ajouter ce protocole à l’outil de simulation. En effet, il existe
un patch des sources de NS qui ajoute la connaissance d’OLSR. Une fois les sources
patché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 notre
connaissance dans le domaine des réseaux mobiles.

41
 Liste des figures

1.1 Architecture de connexion AdHoc . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Ad hoc On Demand Distance Vector . . . . . . . . . . . . . . . . . . . . . 7

2.1 représentation d’un graphe sous NAM . . . . . . . . . . . . . . . . . . . . 17

2.2 exemple d’un graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Commande d’extraction du dossier . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Résultat d’extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Emplacement fichier ls.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Fichier ls.h avant modification . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Fichier ls.h après modification . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Installation NS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 Fichier bashrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.10 Configuration du chemin de fichier bashrc . . . . . . . . . . . . . . . . . . 22
2.11 Rechargement du fichier bashrc . . . . . . . . . . . . . . . . . . . . . . . . 22
2.12 Vérification du fonctionnement de NS2 . . . . . . . . . . . . . . . . . . . . 23
2.13 Exécution du NS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Description fichier TCL (1) . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Description fichier TCL (2) . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Description fichier TCL (3) . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Description fichier TCL (4) . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Description fichier TCL (5) . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Description fichier TCL (6) . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Description fichier TCL (7) . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8 Description fichier TCL (8) . . . . . . . . . . . . . . . . . . . . . . . . . . 33

42
3.9 Capture simulation sous l’outil NAM . . . . . . . . . . . . . . . . . . . . . 34
3.10 Capture du fichier trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.11 Description du fichier trace . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.12 La perte des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.13 Taux de paquets reçus délivrés . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.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 Nouvelles
Génération, Mr. Mohamed HEDHILI, 2014
[4] http ://www.guill.net/index.php ?cat=3&pro=2&rfc=17,Scott Carson
et 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é le
20/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 acronymes
AODV Adhoc On Demand Distance Vector
CBR Constant Bit Rate
CLR Clear
DAG Directed Acyclic Graph
DSDV Destination Sequenced Distance Vector
DSR Dynamic Source Routing
GCC GNU Compiler Collection
GLOMOSIM Global Mobile Simulator
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
ISM industrial scientific and medical
J-SIM Joint Simulation
LSR Link State Routing
Manet Mobile Adhoc Network
MPR Multipoint Relay
NAM Network Animator
NED Network Description Language
NS Network Simulator
OLSR optimized link state routing
OS Operating System
OTCL Orient Tool Command Language
QRY Query
RD Random Direction
RERR Route Error
RIP Routing Information Protocol
RMP Reactif Manet Protocol
RREP Route Replay
RREQ Route Request
RW Random Walk
RWP Random Way Point
TCL Tool Command Language
TCP Transmission Control Protocol
TORA Temporally Ordered Routing Algorithm
UDP user Datagram Protocol
UPD Update
VBR Variable Bit Rate
WIFI Wireless Fiedelity
WPAN Wireless Personal Area Network
46
47