See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/264166764

Communication and Computer Networks Simulator (NS2)

Article · January 2014

CITATIONS READS
0 807

1 author:

Yousif Mohsin Hasan

University of Al-Qadisiyah
16 PUBLICATIONS   2 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

High Altitude Platform Stations in Design Wireless Communication System View project

All content following this page was uploaded by Yousif Mohsin Hasan on 11 August 2016.

The user has requested enhancement of the downloaded file.

 Communication and Computer Networks Simulator (NS2)
YOUSIF MOHSIN HASAN
University of AL-Qadisiyha, Diwaniya, Iraq

1.0 INTRODUCTION

NS meaning Network Simulation is an open source network simulation tool or software, which
was first, developed Steve McCanne in 1995-1997. NS (Version 2) is an object oriented, discrete
event driven simulator written in C++ (core) and Otcl (python). NS was mainly developed in
order for researchers to simulate various kinds of wired or wireless LAN and WAN thus
implementing network protocols such as TCP and UDP. In addition NS enables researchers to
study and understand traffic source behavior of FTP, VBR, CBR, Web and Telnet, not only that
but also router queue management mechanism such as DropTail, RED and CBQ, routing
algorithms such as Dijkstra, and many more.

NS2 was written in C++ and Otcl in order to differentiate the control and data path
implementations. The simulator supports a class hierarchy in C++ (the compiled hierarchy) and a
corresponding hierarchy within the Otcl interpreter (interpreted hierarchy). To understand more
about the control and data path, take for instance; basically simulation of protocols requires
efficient manipulation of bytes and packet headers thus making run-time speed very essential. On
the other hand, in network studies where the aim is to vary some parameters and to quickly
examine a number of scenarios the time to change the model and run it again is more important.

In NS2 for detailed protocol implementation (new queuing discipline), C++ is the best choice
this is because every packet flowing must be processed and C++ is quiet fast. On the other hand
Otcl is suitable for configuration and setup. Otcl runs a bit slow compared to C++, but it can be
changed very quickly making the construction of simulations easier. Another important aspect is
availability of the compiled C++ objects to the Otcl interpreter; this enables the objects to be
controlled from the OTcl level.

A network simulation performance for a network topology that consist of 3 sources, a gateway
and a receiver is analyzed using FTP and CBR applications connected over TCP and UDP agent
respectively. The benchmark for the simulation is done using the following queuing mechanisms
namely; Droptail, Stochastic Fair Queuing (SFQ) and Random Early Detection (RED) in which
the performance of this topology is analyzed. The report is organized as follows;

First, an introduction is carried out to give an overview on Network Simulation software (NS2)
and the aim of this simulation; this is followed by the methodology which gives an insight on the
steps carried out in developing the code script for the simulation, this is then followed by the
source code and NAM trace file for TCP Scenario. Afterwards the results of the simulation are
analyzed and a conclusion on the overall simulation is performed.

2.0 METHODOLOGY
This section will cover detail description on various sections of the code and their functions. The
various code sections are organized as follows;

a. Creation of new simulator object

b. Trace file

c. Source creation

d. Color definition for different traffic flow

e. Link Creation between nodes

f. Queuing size definition

g. Topology layout

h. Monitoring of queues for the links

i. Creating TCP and UDP agent and attaching to nodes

j. Creating a TCP sink agents and attach them to node

k. Scheduling events for the FTP and CBR agents

NS2 Simulation Flow chart

Create a <filename>.tcl tcl file

Type ns <filename>.tcl to interpret the file

Type nam in the terminal to open the network

animator

Search for the corresponding .nam file in the

2.1 Creation of new simulator object
working folder
A simulator object have functions that allow for the creation of nodes, links and connecting

agents used in creating a network topology for the simulation in determining network

performance . The class Simulator has all the basic functions to perform this task. Functions

belonging to the simulator class can be used by appending “$ns” at the beginning of the

command since the simulator object are design to be handled by ns. This is show below.

#Create a simulator object

set ns [new Simulator]

2.2 Trace file

Trace file is use in collecting data for calculating of simulation results. With the aid of NS2 trace

file, drop or arrival of packet that occurs in queue or in a link are recorded. Below is the code

that is use in creating a trace file and the nam trace file for the simulation.

#Open trace files

set f [open droptail-queue-out.tr w]
$ns trace-all $f

#Open the nam trace file

set nf [open droptail-queue-out.nam w]
$ns namtrace-all $nf

2.3 Source creation

The Simulator class has a member called “node” that is use to create five nodes which are assign

to be handle s0, s1, s2, G, r. The handles are used when referring to those nodes. Traffic sources

(FTP and CBR) are attached to the traffic agents (TCP and UDP) and these traffic agents are

attached to the nodes if a node is not a router but an end system. Below is the code for creating

nodes using the Simulator class “node”.

#s1, s2 and s3 act as sources.

set s0 [$ns node]
set s1 [$ns node]
set s2 [$ns node]

#G acts as a gateway.
set G [$ns node]

#r acts as a receiver.
set r [$ns node]

2.4 Color definition for different traffic flow

In the simulation, there are two types of traffic used. These traffics can be differentiated from

one another by assigning color to each. The color assigning is done using the calling the color

function from the Simulator class using the commands below;

#Define different colors for data flows

$ns color 1 Yallow ; # the color of packets from s0
$ns color 2 SeaGreen ; # the color of packets from s1
$ns color 3 Blue ; # the color of packets from s2

It could be seen that the packet sent from node s0 and s1 have the assigned color red because

they use the same TCP traffic agent and that of node s2 has green color which uses a UDP traffic

agent.

2.5 Link Creation between nodes

In other to complete the network topology, links are required to connect all the different nodes

together. When creating a link in NS2, the output queue and the queue type of a node are

implemented as part of the link. There are two types of links namely: simplex and duplex but in

this simulation all links are design to be duplex. The command for creating a duplex or simplex

link between two nodes is shown by the code fragment below;

$ns duplex/simplex-link endpoint1 endpoint2 bandwidth delay queue-type

The code section below shows a duplex link connection between all the sources (S0, S1 and S2)

and the gateway and from the gateway to the receiver using Drop tail queuing mechanism.

#Create links between the nodes

$ns duplex-link $s0 $G 6Mb 5ms DropTail
$ns duplex-link $s1 $G 6Mb 5ms DropTail
$ns duplex-link $s2 $G 6Mb 5ms DropTail
$ns duplex-link $G $r 3Mb 10ms DropTail

From the code section above, it could be seen that the duplex link connection the sources to the

gateway have a bandwidth of 6Mb and a delay of 5ms. The duplex link between the gateway and

the receiver has a bandwidth of 3Mb and delay of 10ms.

There are several queue management algorithms implemented in ns2, but in this exercise only

DropTail, RED and SFQ queuing mechanism will be needed.

2.6 Queuing size definition

The Queuing size between the gateway and the receiver need to be define.

$ns queue-limit node1 node2 number:

The command above sets the queue limit of the two duplex links that connect node1 and node2

to the number specified. In this report, a queuing size of 5 is used between the gateway and the

receiver. This is illustrated as shown in the code fragment below.

#Define the queue size for the link between node G (gateway) and r (receiver)

$ns queue-limit $G $r 5

2.7 Topology layout

For the simulation scenario in ns2 to run successfully, there is need to set up the layout of the
network topology. This topology comprises of a collections of links and nodes. The code
fragment for creating the topology using 5 nodes is shown below:

#Define the layout of the topology

$ns duplex-link-op $s0 $G orient right-down
$ns duplex-link-op $s1 $G orient right
$ns duplex-link-op $s2 $G orient right-up
$ns duplex-link-op $G $r orient right

Figure 1: Network topology for simulation

2.8 Monitoring of queues for the links
Monitoring of queues for links is essential as it provides means of integrating quantities, which

includes number of arrived packets in the queue or number of packets drops, this therefore make

it possible to track the statistics of arrivals, departures and drops which can represented either in

bytes or packets . Similarly, queue size overtime can be tracked by the queue monitor.

#Monitor the queues for the links

$ns duplex-link-op $s0 $G queuePos 0.5

$ns duplex-link-op $s1 $G queuePos 0.5

$ns duplex-link-op $s2 $G queuePos 0.5

$ns duplex-link-op $G $r queuePos 0.5

The code fragment above shows the queue for monitoring the links.

2.9 Creating TCP and UDP agent and attaching to nodes

UDP and TCP agents are the most commonly used agents in NS2. There are several types of
TCP agent some of which are
a. Agent/TCP/Reno – a Reno TCP sender

b. Agent/TCP – a Tahoe TCP sender

c. Agent/TCP/Sack1 – TCP with selective acknowledgement

The command used for setting up a TCP agent that uses Reno and attaching to a node s0 with a
window size of 8 byte which is the maximum amount of received data that can be buffered at any
given time on the receiving side of the connection.

# setting a TCP agent using Reno

set tcp [new Agent/TCP/Reno]
$ns attach-agent $s0 $tcp
$tcp set window_ 8
$tcp set fid_ 1
There are several traffic sources and applications provided by NS2 and the ones implemented in
this simulation are

a. Application/Traffic/CBR – generates packets with a constant bit rate

b. Application/FTP – produces bulk data that TCP will send

The command used to create an FTP application and attaching it to a TCP/Reno agent is shown
below;

#Create FTP applications and attach it to an agents

set ftp [new Application/FTP]

$ftp attach-agent $tcp

$ftp set type_ FTP

Similarly, the command use to create a CBR application and attaching it to a UDP agent is
shown by the code fragment below;

#Setup a UDP agent and attach it to node s2

set udp [new Agent/UDP]

$ns attach-agent $s2 $udp

set null [new Agent/Null]

$ns attach-agent $r $null

$ns connect $udp $null

$udp set fid_ 2

#Setup a CBR over UDP connection

set cbr [new Application/Traffic/CBR]

$cbr attach-agent $udp

$cbr set type_ CBR

$cbr set packet_size_ 1000

$cbr set rate_ 1mb

$cbr set random_ false

The packet size use for the CBR application is 1000byte with a packet rate of 1Mb per second.

2.10 Creating a TCP sink agents and attach them to node

To terminate the flow of information without any processing, a UDP and TCP sources have to be
connected with traffic sinks.

Class Agent/TCPSink is used to define a TCP sink as shown below;

#Create TCP sink agents and attach them to node r

set sink0 [new Agent/TCPSink]

set sink1 [new Agent/TCPSink]

set sink2 [new Agent/TCPSink]

$ns attach-agent $r $sink0

$ns attach-agent $r $sink1

#connect the traffic sources with the traffic sinks

$ns connect $tcp0 $sink0

$ns connect $tcp1 $sink1

While Class Agent/Null is use to define a UDP sink also shown below;
set null [new Agent/Null]

$ns attach-agent $r $null

$ns connect $udp $null

2.11 Scheduling events for the FTP and CBR agents
The start and stop of the simulation and other events need to be scheduled after the simulation
topology is created and user agents are also configured. Starting and stopping of the simulation
can be done using the commands below;

$ns at $time “finish”

$ns run
The first command schedules the procedure finish at the end of the simulation, and the second
command starts the simulation. To flush the trace buffer, closing the trace file and terminate the
program with an exit routine is defined using the finish procedure. It can also start the NAM
(network animator), post process information and plot the information. The code fragment below
shows the scheduling of the FTP and CBR agent, starting and stopping of the simulation.

proc finish {} {

global ns nf

$ns flush-trace

#Close the NAM trace file

close $nf

#Execute NAM on the trace file

exec nam droptail-queue-out.nam &

exit 0

#Schedule events for the FTP and CBR agents

$ns at 0.0 "$s0 label S0"

$ns at 0.0 "$s1 label S1"
$ns at 0.0 "$s2 label S2"
$ns at 0.0 "$G label GW"
$ns at 0.0 "$r label Rx"

$ns at 0.1 "$ftp0 start"

$ns at 0.2 "$ftp1 start"
$ns at 0.3 "$cbr start"

$ns at 5.5 "$ftp0 stop"

$ns at 6.0 "$ftp1 stop"
$ns at 6.5 "$cbr stop"

$ns at 7.0 "finish"

$ns run
3.0 SOURCE CODE
This section contains the source codes that are used for the simulation. The codes are categorized
based on the two connection technique TCP and UDP and in each of these connections different
queuing mechanism (i.e DropTail, RED, and SFQ) queuing mechanism were implemented.
Making a total of six different source codes.
a. Droptail queuing mechanism code

b. SFQ queuing mechanism code

c. RED queuing mechanism code

3.1 TCP Source code

3.2 UDP connection source code

3.3 SFQ queuing mechanism code

The code for the SFQ queuing mechanism is the same as that of the Droptail. They only differ at
link creation between the nodes where the Droptail is replaced with SFQ

#Create links between the nodes

$ns duplex-link $s0 $G 6Mb 5ms SFQ

$ns duplex-link $s1 $G 6Mb 5ms SFQ

$ns duplex-link $s2 $G 6Mb 5ms SFQ

$ns duplex-link $G $r 3Mb 10ms SFQ

3.4 RED queuing mechanism code

#Create links between the nodes

$ns duplex-link $s0 $G 6Mb 5ms RED

$ns duplex-link $s1 $G 6Mb 5ms RED

$ns duplex-link $s2 $G 6Mb 5ms RED

$ns duplex-link $G $r 3Mb 10ms RED

4.1 ANALYSIS AND RESULTS

Figure 2: traffic flow for packet from source to receiver TCP = Yellow, UDP = Seagreen

Figure 3: packet drop at gateway when buffer is full

From the result obtained, it can be concluded that the SFQ queuing mechanism has a better
performance in term of average packet dropped which is 1. It means that for every drop an
approximate of packets are dropped. It is the best mechanism use to stop congestion collapses.
The result obtained basis on RED queuing mechanism has show good performance as its in the
term of average packet dropped which is 2. As its operate on the basis of statistics information.
All incoming packets are acknowledged. When the buffer of the gateway is empty, the
probability of discard in packet also increased when as the queuing size increase.
the probability that a packet is drop is 1 show that the buffer is full and all incoming packets are
dropped. Which is implies RED is capable of evading global synchronization of TCP flows,
preserves high throughput as well as low delay and attains fairness over multiple TCP
connections.
Lastly the droptail queuing mechanism as shown in the table bellow has less performance
compare to SFQ and RED queuing mechanisms in term of average packets drop which is 3. It is
mean It is a simple queue mechanism that is used by the routers that when packets should to be
drop. In this mechanism each packet is treated identically and when queue filled to its maximum
capacity the newly incoming packets are dropped until queue have sufficient space to accept
incoming traffic.
Table1: A summary for combination of TCP and UDP code result
Queuing Total packets number of Packets per drop
mechanism dropped drops per
simulation
Droptail 59 28 3
RED 67 35 2
SFQ 11 11 1
 Table 1: Summary of simulation results

Type of Queuing Total packets number of Packets per drop

Connection mechanism dropped drops per
simulation
TCP Droptail 51 26 2
RED 75 38 2
SFQ 0 0 0
UDP DropTail 0 0 0
RED 0 0 0
SFQ 0 0 0

5.0 Conclusion
The codes has been compiled and run based on the network simulation software of NS2 using
three queuing mechanism (Droptail, RED and SFQ queuing mechanism), as stated earlier from
the discussion of the result SFQ provide the best result among the three in terms of average
packet drop, and the number of packet drop per simulation time with less congestion in the
network as well as high throughput this is achieved duet to fact that SFQ does not actually assign
a queue for every session rather it uses an algorithm that divides the traffic over a restricted
number of queues. The result obtained from RED queuing mechanism as well agree with it
concept that it preserves high throughput which make it suitable mechanism to stop congestion
collapses, on the other side Droptail produce less performance as its treat each packet identically
and loss of packet causes the sender to enter slow start which decreases the throughput there by
increasing the congestion window. The aim and objectives of the project has been achieved
through learning the basic on how to use NS2 software and Ubuntu operating system, which
helped in clarifying and identifying different queuing mechanism as a basic of understanding the
basis for more complicated network simulation, and give more light towards understanding
network performance like queuing delay and packet loss where various session of queuing
mechanism behavior where observed and analyzed. The nam (NS2 network animator or GUI)
that receive some of the NS2 command to display the result help a lot in our discussion and
analysis
 REFERENCE

1. Issariyakul, Teerawat, and Ekram Hossain. An introduction to network simulator NS2.

Springer, 2012.

2. Altman, E.; Jiménez, T. (2003). NS Simulator for beginners [Online]. Available:

citeseer.ist.psu.edu/altman03ns.html

3. Chung, J.; Claypool, M. NS by Example [Online]. Available: http://nile.wpi.edu/NS/

4. The ns Manual (formerly ns Notes and Documentation [Online].Available:

http://www.isi.edu/nsnam/ns/doc/index.html

5. Kalav, Dolly, and Sudha Gupta. "Congestion Control Communication Network Using RED,
SFQ and REM Algorithm."

6. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, d. Estrin, S. Floyd, v. Jacobson, G.

Minshall, C. Patridge, L. Peterson, K. Ramakrishan, S. Shenker, J. WrocLawski, and Lixia
Zhang, “ Recommendations on Queue Management and Congestion Avoidance in the Internet”,
April 1998, RFC 2309.

View publication stats