Simulation D'une Architecture SANET en Utilisant NS2

Université Mohammed V de Rabat
ENSIAS
Réseaux TCP-IP et Mobilité
Simulation d’une architecture

SANET en utilisant NS2.
Salah Eddine HEBABAZE Hamid EL BOUABIDI
January 26, 2021

Contents
1 Introduction 3
1.1 installation de NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Mise en place d’une simulation avec NS-2: . . . . . . . . . . . . 4
1.3 Protocole de Routage AODV : Ad hoc On Demand Distance Vec-
tor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Les Protocoles à comparer : . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 TCP New-Reno : . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 TCP Vegas : . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Modèles de trafic : . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Mise en place de la simulation : 7
3 L’éxecution de la simulation 12
3.1 Démarrage NS2: . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Démarrage NAM : . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Analyse et interpretation de performance 13

4.1 Le fichier de traçage : . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Résultat de notre fichier de traçage sanet.t . . . . . . . . 13
4.1.2 La signification des différents champs du fichier de trace
est décrite comme suit : . . . . . . . . . . . . . . . . . . 13
4.1.3 La Perte des paquets : . . . . . . . . . . . . . . . . . . . . 13
4.2 L’analyse de congestion pour chaque protocole : . . . . . . . . . . 14
4.3 Delay per packet : . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 Pour TCP New Reno : . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Pour TCP Vegas : . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Jitter per packet : . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1 Pour TCP New Reno : . . . . . . . . . . . . . . . . . . . . 18
4.4.2 Pour TCP Vegas : . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Throughput : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.1 Pour TCP New Reno : . . . . . . . . . . . . . . . . . . . . 19
4.5.2 Pour TCP Vegas : . . . . . . . . . . . . . . . . . . . . . . 20
5 Conclusion 20
1
List of Figures
1 topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Network Animator . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Capture de Fichier de trace . . . . . . . . . . . . . . . . . . . . . 13
4 La signification des différents champs . . . . . . . . . . . . . . . 13
5 Description du fichier trace . . . . . . . . . . . . . . . . . . . . . 14
6 TCP vegas vs TCP NewReno . . . . . . . . . . . . . . . . . . . 21
2
1 Introduction
Ce travail s’inscrit dans un projet visant à comparer les performances des pro-
tocoles TCP New Reno et TCP Vegas dans un environnement SANET. Dans
cet rapport nous nous intéressons à évaluer l’utilisation de différents protocoles
de transport TCP (Transport Control Protocol) : TCP New-Reno et TCP Ve-
gas,en considérant différents paramètres liés à la QoS (Quality of Service). Cette
évaluation s’effectue dans le contexte suivant :
• OS: Ubuntu 18.01

• L’outil de simulation : NS2 (Network Simulator )
• Nombre de noueds : 7
• Déploiement d’une architecture SANET composée de :

– 2 Sources
– 3 Gateways
– 2 Destinations
– 6 Cellules de portée max 250.
– Applications : FTP1 et FTP2 entre les sources et destinations.
• NS2 visual Trace Analyse :
Cet outil fournit un moyen facile permettant aux utilisateurs de tracer
des graphiques, des paquets de filtres, de visualiser la position des nœuds,
calculer les statistiques de noeuds et de la circulation, et ainsi de suite.
Cette application autonome, avec une interface utilisateur conviviale, pas
besoin d’installer et pas de bibliothèques externes exigences.
1.1 installation de NS-2

Le protocole de routage AODV a été implémenté comme une partie de NS2.
Mais OLSR a été implémenté comme un patch et doit être ajouté à NS2. Pour
ajouter le protocole OLSR à NS2, nous pouvons télécharger le correctif à partir
de http://sourceforge.net/projects/um-olsr/ et suivre installer instruction de :
http://masimum.inf.um.es/fjrm/development/um-olsr/.
1. Après avoir installé VMware, la première étape de l’installation de NS-

2 consiste à télécharger le fichier ns-allinone-2.35.tar.gz de sourceforge
http://sourceforge.net/projects/nsnam/ et enregistrez-le dans le dossier.
2. Tapez ”tar –ZVFX ns-allinone-2.35.tar.gz” pour extraire les fichiers ns-2.
Ce fichier contient toutes les bibliothèques
• tk release 8.5.10
• Tcl release 8.5.10
3
• Tclcl release 1.20
• Otcl release 1.14
• Ns release 2.35
• Nam release 1.15
• Xgraph version 12.2
• CWeb version 3.4g
• SGB version 1.0
• Gt-itm gt-itm and sgb2ns 1.1
• Zlib version 1.2.3
3. Le dossier d’installation ns-2.35 contient le script d’installation qui doit
être installé.
• cd ns-allinone-2.35
• ./install
4. Une fois l’installation terminée, ajoutez le patch suivant dans le fichier
”.bashrc”
NSHOME=~/ns-allinone-2.35
OTCL_LIB=$ (NS HOME)/ otcl-1.14
NS2_LIB=$ (NSHOME 10 / library
Export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB
Export TCL_LIBRARY=$ (NSHOME)/tcl 8.5.10 / library
PATH=$PATH: $ (NSHOME)/ ns-2.35: $ (NSHOME)/ nam-1.15
5. Testez si le répertoire NS-2 doit être ajouté à la variable $ PATH”.On

peut la tester en exécutant :
echo $PATH
6. Testez l’instalation par la commande ns
1.2 Mise en place d’une simulation avec NS-2:

Phase 1 : Configuration du réseau : configurer les composants du réseau
(nœuds, connexions entre les nœuds, type de connexion, durée d’échange, le
début du transfert de données, . . . ). Pour ce faire, l’utilisateur créé un
script OTcl nomscript.tcl contenant les commandes nécessaires pour la mise
en place de la simulation
Phase 2 : Exécution de la simulation : il s’agit d’exécuter la simulation con-
figurée dans la phase 1. Une horloge de simulation est maintenue pour exécuter
les événements chronologiquement jusqu’à atteindre une limite spécifiée précédemment
dans la phase de configuration.Pour cela, NS-2 offre aux utilisateurs une com-
mande exécutable (ns) qui prend le nom du fichier contenant le script de sim-
ulation nomscript.tcl comme argument en entrée et produit en sortie deux
fichiers de traces :
4
• nomscript.tr dans lequel sont inscrites toutes les actions observées lors
de la simulation
• nomscript.nam qui sert à la création de l’animation corres-pondante à
la simulation grâce au programme NAM (Network AniMator) inclu dans
NS-2 et ce en exécutant la commande nam suivie du fichier à visualiser.
Phase 3 : Évaluation de la performance du réseau simulé : il s’agit de collecter

et de compiler les résultats des simulations. Un parcours du fichier de traces
nomscript.tr s’impose pour dégager les informations voulues. Des langages de
script (tel que awk ou shell) sont généralement utilisés pour parser les fichiers
et dégager l’information voulue.
1.3 Protocole de Routage AODV : Ad hoc On Demand

Distance Vector
AODV est un protocole de routage sans boucle pour les réseaux ad-hoc. Il est
conçu pour être auto-démarré dans un environnement de nœuds mobiles, résister
à une variété de comportements de réseau tels que la mobilité des nœuds, les
pannes de liaison et les pertes de paquets. A chaque nœud, AODV maintient
une table de routage. L’entrée de table de routage pour une destination contient
trois domaines essentiels : un nœud de saut suivant, un numéro de séquence et
un nombre de sauts. Tous les paquets destinés à la destination sont envoyées
au nœud de saut suivant.
Le numéro de séquence agit comme une forme d’horodatage, et est une mesure
de la fraı̂cheur d’un itinéraire. Le nombre de sauts représente la distance en
cours au nœud de destination.
Dans AODV, les nœuds découvrent les itinéraires dans les cycles de demande-
réponse. Un nœud demande un itinéraire vers une destination en diffusant
un message RREQ à tous ses voisins. Quand un nœud reçoit un message de
RREQ mais ne dispose pas d’un itinéraire vers la destina-tion demandée, à
son tour diffuse le message RREQ. En outre, il se souvient d’une route inverse
vers le nœud demandeur, qui peut être utilisé pour transmettre des réponses
ultérieures à ce RREQ. Ce processus se répète jusqu’à ce que le RREQ atteint 6
un nœud qui a une route valide vers la destination. Ce nœud (qui peut être lui-
même la destination) répond avec un message de RREP. Cette MIQ est unicast
le long des routes inverse des nœuds intermédiaires jusqu’à ce qu’il atteigne
le nœud demandeur d’origine. Ainsi, à la fin de ce cycle de demande-réponse
bidirectionnel un itinéraire est établi entre le nœud demandeur et la destination.
Quand un nœud perd la connectivité à sa prochaine hop, le noeud invalide sa
route en envoyant un RERR à tous les nœuds qui potentiellement reçu son MIQ.
5
1.4 Les Protocoles à comparer :
1.4.1 TCP New-Reno :
La principale différence entre TCP New-Reno est TCP Reno consiste à la prise
en considération des acquittements partiels dans l’algorithme Fast Recovery.
Dans TCP Reno, la taille de la fe-nêtre de congestion augmente tant qu’il n’y
a pas de pertes. TCP Reno a deux phases pour l’augmentation de la taille de
la fenêtre, Slow Start et Congestion Avoidance. Cette dernière est déclenchée
lorsque le cwnd devient égale à ssthresh(taille maximum d’une fenêtre d’émission
en slow start)
Lors de la réception d’un acquittement partiel, un ACK d’au moins d’un segment
perdu TCP Reno quitte le mode Fast Recovery, ce qui pose un problème de
performance lorsque plusieurs segments d’une même fenêtre sont perdus. TCP
New-Reno ne quitte le mode de Fast Recovery que si l’ACK reçu acquitte tous les
segments envoyés. A la réception d’un ACK partiel, TCP New-Reno retransmet
immédiatement le paquet suivant le dernier paquet acquitté dans cet ACK, il
diminue la taille de la fenêtre du nombre de paquets acquittés par cet ACK
partiel et retransmet un paquet si c’est permis par la taille de cwnd (fenêtre de
congestion).
En résumé, avec New-Reno, à la différence de Reno,un accusé de réception
partiel ne fait pas quitter l’algorithme de Fast Recovery. Il faut un accusé de
réception total pour cela [1].
1.4.2 TCP Vegas :

Dans TCP Reno la congestion n’est pas détectée tant qu’il n’y a pas de perte,
alors que TCP Vegas propose un algorithme de pré-vision de congestion du
réseau, il détecte la congestion avant que les paquets soient perdus.
TCP Vegas contrôle la taille de la fenêtre en observant le RTT (variation des
temps) des paquets que l’hôte expéditeur a envoyés. Si le RTT observée de-
vient grand, TCP Vegas reconnaı̂t que le réseau commence à s’encombrer. Si le
RTT diminue, TCP Vegas comprend que le réseau est libéré de la congestion et
augmente la taille de la fenêtre.
1.5 Modèles de trafic :

Le Transmission Control Protocol (TCP) soulève un certain nombre de questions
en cas de besoin de travailler dans un environnement sans fil. En particulier,
dans un réseau ad hoc, il doit faire face à de nouveaux défis difficiles tels que
la haute probabilité de défaillances à la fois de séparation du réseau et la route
dus à la mobilité. Dans un scénario adhoc tous les nœuds peuvent se déplacer
li-brement et de manière imprévisible, ce qui rend le contrôle de congestion TCP
assez difficile car il est un mé- canisme basé sur l’horloge. Par conséquent, les
stratégies de détection d’erreur et de reprise sur erreur inhérentes à besoin de
TCP standard pour être adaptés afin d’adapter cet environnement. En partic-
ulier, puisque les erreurs dans cet environnement se produit non seulement en
6
raison de la congestion, mais aussi en raison de contraintes moyennes et de la
mobilité, TCP doit distinguer la nature de l’erreur afin qu’il puisse prendre les
mesures les plus appropriées pour chaque cas. En outre, le lien et la couche
réseau algorithmes émergents pour ce type de réseau peuvent jouer un rôle clé
sur la performance TCP. De même, des facteurs tels que chemin asymétrie (qui
peut aussi être causée par des stratégies de couches inférieures, entre autres
éléments) et la taille de la fenêtre de congestion pourraient également affecter
les perfor-mances de ce protocole.
1.6 Topologie
Notre topologie consiste d’avoir une connexion tcp new reno entre le node n0 et
n5.Une connexion tcp vegas entre les nodes n1 et n6.
Figure 1: topologie
2 Mise en place de la simulation :

Nous présentons dans cette section les différents paramètres à prendre en con-
sidération dans les simulations. Ces paramètres sont initialisés dans le script
nomscript.nam. Nous décrivons ainsi le contenu de ce fichier regroupant les
paramètres des simulations qui concernent la topologie, le trafic, la mobilité, le
timing des événements, etc.
Topologie: Nous considérons un réseau ad hoc composé de 7 nœuds mobiles
de portée max 250 placés selon leuer position dans un terrain dégagé de 828 m
× 505 m. Les nœuds utilisent le protocole MAC IEEE 802.11 .
Structure des nœuds: Chaque nœud maintient une file d’attente de type
FIFO (premier entré,premier sorti). Ainsi, les messages les plus anciens sont
effacés lors d’un débordement dans cette file. La taille de cette file d’attente est
fixée à 50 paquets.
Mobilité : Les nœuds sont fixe
Modèle du trafic: La simulation dure 30 s durant laquelle les nœuds vont
échanger un traffic ftp basé sur TCP/Newreno et TCP/Vegas.
Script TCL: TCL est un langage conçu pour une utilisation par un développeur
de l’application qui peut être participé à travers une demande ou pourrait être
7
utilisé par une application de diverses manières, par exemple, pour permettre à
un utilisateur de fournir une initialisation personnalisée pour l’application.
NS2 utilise tcl pour le programmeur de simulation pour créer les objets de réseau
dans la mémoire et d’insérer des événements initiaux dans la file d’attente de
l’événement.
Xgraphe : Xgraph est une application X-Windows qui inclut le traçage in-
teractif et graphique, animation et déritives, de portabilité et de corrections de
bugs.
Donc, pour tracer les caractéristiques des paramètres NS2 comme le débit, la fin
d’un retard de la fin, les paquets d’informations, etc peut être tracée en utilisant
xgraph. Le fichier xgraph affiche les informations à propos de la surcharge avec
la taille du réseau, Overhead ..
Un scénario de simulation dans NS2 est créé en commençant par un script TCL.
Ce script va regrouper tous les besoins d’un réseau comme paramètres du canal,
des couches OSI, la taille du champ de la simulation, positions des nœuds, le
modèle de propagation, le trafic (couche application), le traçage des évènements,
et beaucoup d’ autres caractéristiques du réseau.
Pour cette simulation on a créé un fichier de simulation nommé sanet.tcl
Les étapes suivantes décrivent la creation de fichier sanet.tcl pour la simulation
du projet .
• Etape 1 : le paramétrage des variables d’environnement pour la simulation
set val(chan) Channel/WirelessChannel ;# Type de canal

set val(prop) Propagation/TwoRayGround ;# Modéle de propagation
set val(netif) Phy/WirelessPhy ;# Type de Réseau
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# Type de laqueue
set val(ll) LL ;# Type de couche réseau
set val(ant) Antenna/OmniAntenna ;# Type d’antenne
set val(ifqlen) 50 ;# Max des paquets dans ifq
set val(nn) 7 ;# number of mobilenodes
set val(rp) AODV ;# Méthode de routage
set val(x) 828 ;# X dimension of topography
set val(y) 505 ;# Y dimension of topography
set val(stop) 30.0 ;# time of simulation end
• Etape 2 : Initialisation et fichiers de traçage :

#Creation d’un objet de simulation avec l’instruction suivante:
set ns [new Simulator]

# Localisation des noeuds
set topo [new Topography]
# taille de champ
$topo load_flatgrid $val(x) $val(y)
8
# CREATION D’OBSERVATEUR DE LA SIMULATION (GENERATOR OPERATIONS DIRECTOR)
QUI sert à sau-vegarder les information sur me nombre de nœuds mobile,
le nombre minimum de hops pour atteindre un autre nœud...
create-god $val(nn)
# Permettre la traçage de toutes les informations de toutes les couches :
set tracefile [open sanet.tr w]
$ns trace-all $tracefile
set f1 [open cwnd-vegas.tr w]
set f2 [open cwnd-nreno.tr w]
# l’ouverture d’un fichier de traçage des données qui seront utilisé par NAM
set namfile [open sanet.nam w]
# indiquer au simulateur que le fichier de traçage est crée
$ns namtrace-all $namfile
$ns namtrace-all-wireless $namfile $val(x) $val(y)
# déclaration de chaine de communication
set chan [new $val(chan)]
• Etape 3 : la configuration et la création des nœuds

Configuration des nœuds par les valeurs pardéfaut :
$ns node-config -adhocRouting $val(rp) \

-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channel $chan \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON
Définition des positions et de la nature du mouvement des noeuds
set n0 [$ns node]

$n0 set X_ 296
$n0 set Y_ 399
$n0 set Z_ 0.0
$ns initial_node_pos $n0 20
set n1 [$ns node]
$n1 set X_ 296
$n1 set Y_ 106
9
$n1 set Z_ 0.0
set n2 [$ns node]
$n2 set X_ 369
$n2 set Y_ 254
$n2 set Z_ 0.0
set n3 [$ns node]
$n3 set X_ 510
$n3 set Y_ 252
$n3 set Z_ 0.0
set n4 [$ns node]
$n4 set X_ 627
$n4 set Y_ 252
$n4 set Z_ 0.0
set n5 [$ns node]
$n5 set X_ 728
$n5 set Y_ 405
$n5 set Z_ 0.0
set n6 [$ns node]
$n6 set X_ 721
$n6 set Y_ 103
$n6 set Z_ 0.0
• Etape 4 : Définition des Agents TCP :New reno et Vegas

# Setup a TCP/Newreno connection
# Création de l’agent TCP Newreno

set tcp1 [new Agent/TCP/Newreno]
# Attacher l’agent tcp1 au node 1
$ns attach-agent $n1 $tcp1
set sink1 [new Agent/TCPSink]
$ns attach-agent $n6 $sink1
# Etablir une connexion entre l’agent source tcp1 et l’agent destination sink1
$ns connect $tcp1 $sink1
$tcp1 set packetSize_ 1500
#Setup a TCP/Vegas connection
set tcp2 [new Agent/TCP/Vegas]
$ns attach-agent $n0 $tcp2
set sink2 [new Agent/TCPSink]
$ns attach-agent $n5 $sink2
10
$ns connect $tcp2 $sink2
$tcp2 set packetSize_ 1500
• Etape 5 : Définition des Applications
# creation d’une source de traffic FTP et l’attacher à TCP1

set ftp1 [new Application/FTP]
# Attacher l’application ftp1 à l’agent tcp1
$ftp1 attach-agent $tcp1
$ns at 0.0 "$ftp1 start"
$ns at 30.0 "$ftp1 stop"
# Setup a FTP Application over TCP/Newreno connection
set ftp2 [new Application/FTP]
$ftp2 attach-agent $tcp2
$ns at 0.0 "$ftp2 start"
$ns at 30.0 "$ftp2 stop"
• Etape 6 :Implémentation de procédure pour générer un rapport concenant

la congestion tcp pour les deux agents
## Obtain CWND from TCP agent
##################################################
# procedure to plot the congestion window

proc plotWindow {tcpSource outfile} {
global ns tracefile namfile f1 f2 tcp1 tcp2
# le planificateur conserve une trace du temps dans la simulation
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
# les donneés seront enregistés pour les protocole Vegas et Newreno
dans les fichiers vegas.xg et nreno.xg
puts $outfile "$now $cwnd"
$ns at [expr $now+0.1] "plotWindow $tcpSource $outfile"
}
set outfile1 [open "vegas.xg" w]
set outfile2 [open "nreno.xg" w]
$ns at 0.0 "plotWindow $tcp1 $outfile1"
$ns at 0.0 "plotWindow $tcp2 $outfile2"
• Etape 7 : Définition de procedure ”finish” : Creation d’une procedure

”ficnish” qui ferme le fichier et démarre NS2 par la suite :
proc finish
global ns tracefile namfile f1 tcp1 f2 tcp2
Display the final average throughput
11
puts [format ”Vegas-Throughput: puts [format ”NewReno-Throughput:
Nettoyer les buffers des objets de traçage nsf lush − traceclosetracefile
close namf ileclosef1 close f 2exit0
demander au simulateur d’exécuter la procédure ”finich” après le temps
d’arret du simulation nsatval(stop) ”finish” nsatval(stop) ”puts d̈one¨;
nshalt”démarrerlasimulationns run
3 L’éxecution de la simulation
3.1 Démarrage NS2:
NS2 démarre avec la commande ‘ns sanet.tcl‘. le tclscript est un fichier
en langage TCL qui définit le scénario de la simulation (topologie et les
évenement) .tout le reste de la simulation dépend de ce fichier TCl.le script
Tcl écrit les sortie, trace les évènements et peut ddémarrer la fenetre
”nam” afin de vi-sualiser la simulation
3.2 Démarrage NAM :

La fenêtre d’animation NAM (Network Animator ) démarre avec la com-
mande ‘nam sanet tcl‘,donnate lieu à la fenêtre décrite par la figure ci-
dessous
Figure 2: Network Animator
12
4 Analyse et interpretation de performance
4.1 Le fichier de traçage :
C’est un fichier créé automatiquement par NS2 qui détaille tous les événements
qui se sont passés dans le réseau (généralement sous format .tr) un évènement
est souvent lié à un paquet (reçu,transmis , ou échoué );chaque ligne donne
plusieurs informations sur l’évènement (s=sent; r=received ,d=droped
(prdue) ;f=forward (achminé) ).
Les évènements répertories dans le fichier de trace sont, à quelques excep-
tions près, de deux types : d’une part ceux concernant le d’emplacement
des nœuds, d’autre part ceux concernant le parcours des différents types
de paquets
4.1.1 Résultat de notre fichier de traçage sanet.t
Figure 3: Capture de Fichier de trace
4.1.2 La signification des différents champs du fichier de trace

est décrite comme suit :
Figure 4: La signification des différents champs
4.1.3 La Perte des paquets :
Elle corresponde au non délivrance d’un paquet de données par rapport à

ceux envoyés.
13
Figure 5: Description du fichier trace
4.2 L’analyse de congestion pour chaque protocole :

Pour protocole Vegas on utilise la commande suivante pour générer le dia-
gramme en utilisant l’outil xgraph et gnuplot Pour le protocole Vegas
Le résultat est le suivant avec xgraph
Le résultat avec gnuplo
14
Pour le protocole NewReno
En utilisant xgraph:
En utilisant gnuplot
Les commandes utiliser pour générer le graphe
15
Le graphe :
Comparaison entre Vegas et New Reno :
Taux de paquets reçus avec succès :
16
Ce taux noté PDR pour Packet Delivery Ratio [Fri07] est le nombre de
paquets de données reçus avec succès par la destination par rapport au
nombre de paquets de données émis par la source. Il nous permet de
vérifier si l’extension du protocole à un impact sur le transfert de paquets
de données avec succès.
4.3 Delay per packet :

Dans un réseau basé sur la commutation de paquets, le délai de trans-
mission (ou délai de stockage et de transmission, également appelé délai
de mise en paquets) est le temps nécessaire pour pousser tous les bits du
paquet dans le câble. En d’autres termes, il s’agit du retard causé par le
débit de données de la liaison.
Le délai de transmission est fonction de la longueur du paquet et n’a rien
à voir avec la distance entre les deux nœuds. Ce délai est proportionnel à
la longueur du paquet en bits.
4.3.1 Pour TCP New Reno :
17
4.3.2 Pour TCP Vegas :
4.4 Jitter per packet :

Dans le domaine des réseaux informatiques, la gigue (en anglais jitter) est
la variation de la latence au fil du temps. Il ne faut pas la confondre avec
la gigue en électronique qui recouvre une notion différente.
Plus précisément, la gigue est la différence de délai de transmission de
bout en bout entre des paquets choisis dans un même flux de paquets,
sans prendre en compte les paquets éventuellement perdus (RFC 33931)
18
4.5 Throughput :
Le throughput est le taux de production ou la vitesse à laquelle quelque
chose peut être traitée. Ce terme peut aussi désigner le débit global d’un
routeur ou d’un nœud du réseau. Lorsqu’il est utilisé dans le cadre des
réseaux de télécommunications, tels que ethernet ou un réseau radio en
mode paquet, le throughput d’un réseau est le débit de transmission utile
du réseau sur un canal de communication (messages reçus avec succès).
Les données de ces messages peuvent être émises sur un lien physique ou
logique, ou bien à travers un nœud du réseau.
La mésure de throuput en n6 des paquets provenant de n
19
La mésure de throuput en n5 des paquets provenant de n0
Dans un réseau basé sur la commutation de paquets, le délai de trans-

mission (ou délai de stockage et de transmission, égale-ment appelé délai
de mise en paquets) est le temps nécessaire pour pousser tous les bits du
paquet dans le câble. En d’autres termes, il s’agit du retard causé par
le débit de données de la liaison.Le délai de transmission est fonction de
la longueur du paquet et n’a rien à voir avec la distance entre les deux
nœuds. Ce délai est proportionnel à la longueur du paquet en bits.
La plupart des réseaux à commutation de paquets utilisent une trans-
mission à mémorisation et retransmission à l’entrée de la liaison. Un
commutateur utilisant la transmission par stockage et retransmission re-
cevra (sauvegardera) le paquet entier dans la mémoire tampon et vérifiera
les erreurs CRC ou d’autres problèmes avant d’envoyer le premier bit du
paquet dans la liaison sortante. Ainsi, les commutateurs de paquets à
mémori-sation et retransmission introduisent un délai de mémorisation et
de retransmission à l’entrée de chaque liaison le long de la route du paquet.
La dynamique des fenêtres de TCP Vegas est beaucoup plus stable que
celle de TCP New Reno, ce qui se traduit par une utilisation beaucoup
plus efficace des ressources du réseau. De plus, alors que TCP New Reno
discrimine les utilisateurs avec de longs délais de propagation, TCP Vegas
partage équitablement la bande pas-sante disponible entre les utilisateurs,
quels que soient leurs délais de propagation
5 Conclusion
Pour conclure , nous sélectionnons le meilleur TCP sur la base des paramètres
mentionnés ci-dessus. Chaque variante réagit différemment sous différents
paramètres. Si une variante a de faibles performances dans un paramètre,
il est possible que la variante ait les performances les plus élevées dans un
20
autre paramètre. Le tableau en décrit plus :
Figure 6: TCP vegas vs TCP NewReno
References
[1]B.Angoma, ANALYSE DU COMPORTEMENT DU HANDOVER
VERTICAL SELON.Revue Méditerranéenne des Télécommunications.
[Fri07]M.Frikha.Planification et simulation des réseaux. Collection perfor-

mance des réseaux.AndrÃc©-Luc Beylot, 1 edition, September 2007.
21

Simulation D'une Architecture SANET en Utilisant NS2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Simulation D'une Architecture SANET en Utilisant NS2

Transféré par

Droits d'auteur :

Formats disponibles

Université Mohammed V de Rabat

Simulation d’une architecture

Salah Eddine HEBABAZE Hamid EL BOUABIDI

January 26, 2021

2 Mise en place de la simulation : 7

4 Analyse et interpretation de performance 13

• OS: Ubuntu 18.01

• Déploiement d’une architecture SANET composée de :

1.1 installation de NS-2

1. Après avoir installé VMware, la première étape de l’installation de NS-

5. Testez si le répertoire NS-2 doit être ajouté à la variable $ PATH”.On

6. Testez l’instalation par la commande ns

1.2 Mise en place d’une simulation avec NS-2:

Phase 3 : Évaluation de la performance du réseau simulé : il s’agit de collecter

1.3 Protocole de Routage AODV : Ad hoc On Demand

1.4.2 TCP Vegas :

1.5 Modèles de trafic :

2 Mise en place de la simulation :

set val(chan) Channel/WirelessChannel ;# Type de canal

• Etape 2 : Initialisation et fichiers de traçage :

set ns [new Simulator]

• Etape 3 : la configuration et la création des nœuds

$ns node-config -adhocRouting $val(rp) \

Définition des positions et de la nature du mouvement des noeuds

set n0 [$ns node]

• Etape 4 : Définition des Agents TCP :New reno et Vegas

# Création de l’agent TCP Newreno

• Etape 5 : Définition des Applications

# creation d’une source de traffic FTP et l’attacher à TCP1

• Etape 6 :Implémentation de procédure pour générer un rapport concenant

## Obtain CWND from TCP agent

# procedure to plot the congestion window

• Etape 7 : Définition de procedure ”finish” : Creation d’une procedure

3.2 Démarrage NAM :

Figure 2: Network Animator

4.1.1 Résultat de notre fichier de traçage sanet.t

Figure 3: Capture de Fichier de trace

4.1.2 La signification des différents champs du fichier de trace

Figure 4: La signification des différents champs

4.1.3 La Perte des paquets :

Elle corresponde au non délivrance d’un paquet de données par rapport à

4.2 L’analyse de congestion pour chaque protocole :

Le résultat avec gnuplo

Les commandes utiliser pour générer le graphe

Comparaison entre Vegas et New Reno :

Taux de paquets reçus avec succès :

4.3 Delay per packet :

4.3.1 Pour TCP New Reno :

4.4 Jitter per packet :

4.4.1 Pour TCP New Reno :

4.5.1 Pour TCP New Reno :

La mésure de throuput en n6 des paquets provenant de n

La mésure de throuput en n5 des paquets provenant de n0

Dans un réseau basé sur la commutation de paquets, le délai de trans-

Figure 6: TCP vegas vs TCP NewReno

[Fri07]M.Frikha.Planification et simulation des réseaux. Collection perfor-

Vous aimerez peut-être aussi