UNIVERSITI TEKNOLOGI MALAYSIA

FAKULTI KEJURUTERAAN ELEKTRIK

MKET1313 Communication and Computer Networks

ASSIGNMENT 2:
NETWORK SIMULATOR 2 (NS2)

GROUP MEMBERS:
1) NURIZAN BINTI TAHIR (MKE161006)
2) AIDAYU DELAILA BINTI DAHLAN (MKE161002)
3) M TIGHAZZA (MKE161 )

LECTURER:
PROF. MADYA DR. SHARIFAH HAFIZAH BINTI SYED ARIFFIN
 Assignment 2
Network Simulator 2 (NS2)

1.0 INTRODUCTION

NS2 is an open-source event-driven simulator designed specifically for research in

computer communication networks. NS2 is an object-oriented, discrete event driven network
simulator developed at UC Berkely written in C++ and OTcl. NS is primarily useful for
simulating local and wide area networks to implement network protocols such as TCP and UPD,
traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management
mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and many
more.

Figure1: NS
working process

Figure 1 show the NS

working process which is Object-oriented Tcl (OTcl) script interpreter that has a simulation
event scheduler and network component object libraries, and network setup (plumbing) module
libraries (actually, plumbing modules are implemented as member functions of the base
simulator object). In other words, to use NS, you program in OTcl script language. To setup and
run a simulation network, a user should write an OTcl script that initiates an event scheduler, sets
up the network topology using the network objects and the plumbing functions in the library, and
tells traffic sources when to start and stop transmitting packets through the event scheduler. The
term "plumbing" is used for a network setup, because setting up a network is plumbing possible
data paths among network objects by setting the "neighbour" pointer of an object to the address
of an appropriate object.

Another major component of NS beside network objects is the event scheduler. An event in
NS is a packet ID that is unique for a packet with scheduled time and the pointer to an object that
handles the event. In NS, an event scheduler keeps track of simulation time and fires all the
events in the event queue scheduled for the current time by invoking appropriate network
components, which usually are the ones who issued the events, and let them do the appropriate
action associated with packet pointed by the event.

Network components communicate with one another passing packets, however this does
not consume actual simulation time. All the network components that need to spend some
simulation time handling a packet (i.e. need a delay) use the event scheduler by issuing an event
for the packet and waiting for the event to be fired to itself before doing further action handling
the packet. Timers use event schedulers in a similar manner that delay does. The only difference
is that timer measures a time value associated with a packet and does an appropriate action
related to that packet after a certain time goes by, and does not simulate a delay.

There are three queuing mechanisms which are as below:

a)Droptail Queuing

It is one of the simplest queuing mechanisms that are used by routers when packets should
be dropped. In this mechanism, similar treatment of packets is applied to each packet and when
queue is filled to its maximum capacity, the newly coming packets are dropped until the queue
has sufficient space to accept new incoming packets [2]

b) Stochastic Fairness Queuing (SFQ)

Stochastic Fairness Queueing (SFQ) is a simple implementation of the fair queuing

algorithms family which allow multiple packets flow to comparatively share the link capacity. It
is however less accurate compare to other mechanisms in the same family, but also requires less
calculation due to being almost perfectly fair. In this mechanism, routers have multiple queues
for each output line for every user.[2]

c)Random Early Detection (RED) Queuing

Random Early Detection is a congestion avoidance queuing mechanism that is potentially

useful especially in high-speed transit networks. It operates on the average queue size on a statics
information basis. When the buffer is empty, all incoming packets are acknowledged. As the
queue size increases, the probability that a packet is discarded increases as well. Once the buffer
is full, the probability becomes 1 and all incoming packets are dropped. The advantages of using
RED is the capability of evading global synchronization of TCP flows, preserve high throughput,
as well as low delay and attaining fairness over multiple TCP connections. Therefore, RED is the
most common mechanisms for stopping congestive collapses.

2.0 METHODOLOGY

2.1 Network simulation using NS2

Network simulation using run NS2 is on Windows-based operating systems. Basically,

the idea is to make Windows-based machines has an operating system guest as a virtual
workstation. In this simulation, the Oracle Virtual Box is used to create Linux environment by
using Ubuntu 14.04 LTS as an operating system. For ease of installation, it is recommended that
the all-in-one package be used which called as NS-allinone-2.35.

The NS2 is installed in directory nsallinone-2.35. Figure 2 shows the directory structure
under directory nsallinone-2.35. Based on the figure, directory nsallinone-2.30 is on the Level 1.
At Level 2, there is directory tclcl-1.18 contains classes in TclCL such as Tcl, TclObject, and
TclClass. All NS2 simulation modules are in directory ns-2.35 on the Level 2. Meanwhile, at
Level 3, the modules in the interpreted hierarchy are under directory tcl. Among these modules,
the frequently-used ones for instance ns-lib.tcl, ns-node.tcl, ns-link.tcl are stored under directory
lib on Level 4.
 Figure 2: Directory structure of NS2 [4]

2.1.1 NS2 Simulation Steps

There are three important steps for network simulation simulation using NS2:

Step 1: Simulation Design

The rst step in simulating a network using NS2 is to design the simulation. The user
should determine the simulation purposes, network congurations and assumptions, the
performance measures, and the type of expected results.

Step 2: Conguring and Running Simulation

This step implements the design in the rst step, the simulation design. It consists of two
phases: network conguration phase and simulation phase. The network phase created and
configured network components such as node, UDO and TCP and the events like data transfer
are scheduled to start at certain time. The simulation phase starts the simulation that is
configured in the step 2. While simulating, the simulation clock is maintains and executes event
chronologically. Normally, it is convenient to dene a simulation scenario in a tcl scripting le
(e.g., <file>) and feed the le as an input argument of an NS2 invocation such as executing ns
<file>).
Step 3: Post Simulation Processing

The main tasks in this step include verifying the integrity of the program and evaluating
the performance of the simulated network.

3.0 SOURCE CODE

This section divide the source code by section so that the workflow of the constructing the
code is able to illustrate and understand. The sections is as below:

a) Creating the simulation object

Simulator object is allows for the creation of nodes, links and connecting agents used in

creating a network topology in determining network performance . The simulator class has all the

basic functions to perform this task and the functions belonging to the simulator class can be

used by appending $ns at the beginning of the code since the simulator object are design to be

handled by ns. The code is as below:

#Create a simulator object

Set ns [new Simulator]

b) Trace file

Trace file is use in collecting data for determining the simulation results and the aid of

NS2 trace file shows drop or arrival of packet that occurs in queue or in a link. The code is:

#Open trace files

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

#Open the namtrace file

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

A simulator object is used to create five nodes which are assign to be handle s0, s1, s2, G, r.

The handles are used when referring to those nodes and traffic sources, FTP and CBR are

attached to the traffic agents called TCP and UDP. These traffic agents are attached to the nodes

at an end of the system. Below is the code for creating nodes:

#s1, s2 and s3 act as sources.

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

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

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

d) Colour definition for different traffic flow

The traffic used can be differentiated from one another by assigning colour to the traffic. The

color assigning is using this code:

#Define different colors for data flows- use any colours

$ns color 1 blue; #the color of packets from s1
$ns color 2 Green; #the color of packets from s2
$ns color 3 Red; #the color of packets from s3

e) Link Creation between nodes

Links are required to connect all the different nodes together. The output queue and the queue

type of a node are implemented as part of the link. There are two types of links called simplex

and duplex but in this simulation all links are design to be duplex. The command for duplex link

connection between all the sources S0, S1 and S2, gateway and the receiver using Droptail
queuing mechanism are:

#create links between the nodes

$ns duplex-link $s1 $G 8Mb 1ms Droptail
$ns duplex-link $s2 $G 8Mb 1ms Droptail
$ns duplex-link $s3 $G 8Mb 1ms Droptail
$ns duplex-link $G $r 8Mb 1ms Droptail

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

to the gateway have a bandwidth of 8Mb and a delay of 1ms. The duplex link between the

gateway and the receiver has a bandwidth of 8Mb and delay of 1ms.

f) Queuing size definition

The Queuing size between the gateway and the receiver using this code:

#Define the queue size for the link between node G and r
$ns queue-limit $G $r 5

g) Topology layout

There is need to set up the layout of the network topology comprises of a collections of links
and nodes.

#Define the layout of the topology

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

h) Monitoring of queues for the links

It 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.

#Monitor the queues for links

$ns duplex-link-op $s1 $G queuePos 0.5
$ns duplex-link-op $s2 $G queuePos 0.5
$ns duplex-link-op $s3 $G queuePos 0.5
$ns duplex-link-op $G $r queuePos 0.5

i) Creating TCP and UDP agent and attached nodes

There are several types of TCP agent such as

Agent/TCP/Reno a Reno TCP sender
Agent/TCP a Tahoe TCP sender
Agent/TCP/Sack1 TCP with selective acknowledgement

The code used are:

#Create a TCP agent and attach it to node s1

set tcp1 [new Agent/TCP/Reno]
$ns attach-agent $s1 $tcp1
$tcp1 set window_ 8
$tcp1 set fid_ 1

#Create a TCP agent and attach it to node s2

set tcp2 [new Agent/TCP/Reno]
$ns attach-agent $s2 $tcp2
$tcp2 set window_ 8
$tcp2 set fid_ 2

#Create a TCP agent and attach it to node s3

set tcp3 [new Agent/TCP/Reno]
$ns attach-agent $s3 $tcp3
$tcp3 set window_ 4
$tcp3 set fid_ 3
 j) Creating a TCP sink agents and attached node

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

#Create TCP sink agents and attach them to node r

set sink1 [new Agent/TCPSink]
set sink2 [new Agent/TCPSink]
set sink3 [new Agent/TCPSink]

$ns attach-agent $r $sink1

$ns attach-agent $r $sink2

$ns attach-agent $r $sink3

#Connect the traffic sources with the traffic sinks

$ns connect $tcp1 $sink1
$ns connect $tcp2 $sink2
$ns connect $tcp3 $sink3

#Create FTP applications and attach them to agents

set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcp1
set ftp2 [new Application/FTP]
$ftp2 attach-agent $tcp2
set ftp3 [new Application/FTP]
$ftp3 attach-agent $tcp3

k) Instruction to start and stop the simulation

The code to activate and stop the simulation is as below:

#Define a 'finish' procedure

proc finish { } {
global ns
$ns flush-trace
Puts running nam
Exec nam droptail-queue-out.nam & exit 0
}

l) Scheduling events for the FTP with label of the nodes

The code below shows the scheduling of the FTP and label of nodes:
$ns at 0.0 $s1 label Sender1
$ns at 0.0 $s2 label Sender2
$ns at 0.0 $s3 label Sender3
$ns at 0.0 $G label Gateway
$ns at 0.0 $r label Receiver
$ns at 0.1 $ftp1 start
$ns at 0.1 $ftp2 start
$ns at 0.1 $ftp3 start
$ns at 5.0 $ftp1 stop
$ns at 5.0 $ftp2 stop
$ns at 5.0 $ftp3 stop
$ns at 5.25 finish
$ns run

4.0 NAM FILE FOR TCP SCENARIO

NAM trace function as is records simulation detail in a text le, and uses the text le the
play backs the simulation using animation [4]. NAM trace is activated by the command $ns
namtrace-all $file, where ns is the simulator handle. The file is a handle associated with the le
which stores the NAM trace information. Then, after obtaining a NAM trace le, the animation
can be initiated directly at the command prompt through the following command. The NAM file
is an animation tools to illustrate the network after simulating the code. The NAM file helps user
to illustrate the node energy, packet filter, highlight leaf trees and showing annotations.

The Figure 3 shows the whole network. It contains three sender or node with label, S1,
S2, and S3. These three nodes communicate to the gateway. Then from the gateway, the network
connected to the receiver. This NAM file appeared right after the play button is clicked. Figure
4 and Figure 5 shows the TCP connection for sender 1, sender 2 and sender 3. In addition, Figure
6, Figure 7 and Figure 8 shows the packet drop in the gateway for each sender when the buffer is
full.
Figure 3: The whole network simulation
Figure 4: the TCP connection for sender 1 and 3
Figure 5: The TCP connection for sender 1 and 2
Figure 6: Packet drop from sender 1 at gateway when buffer is full
Figure 7: Packet drop from sender 2 at gateway when buffer is full
 Figure 8: Packet drop from sender 3 at gateway when buffer is full

5.0 ANALYSIS AND RESULTS

REFERENCE

[2]Mohit Agrawal1, Navneet Tiwari , Lalla Atul Singh Chaurasia and Jatan Saraf, Performance
Comparison of Active Queue Management Algorithms, 2009 International Symposium on
Computing, Communication, and Control (ISCCC 2009) Proc .of CSIT vol.1 (2011) (2011)
IACSIT Press, Singapore
[4] Issariyakul, Teerawat, and Ekram Hossain. An introduction to network simulator NS2.
Springer, 2012.