NS2 Simulation Tutorial
NS2 Simulation Tutorial
In this section, you are going to develop a Tcl (Tool command language) script for ns
which simulates a simple topology. You are going to learn how to set up nodes and links,
how to send data from one node to another, how to monitor a queue and how to start nam
from your simulation script to visualize your simulation.
• NS2 is written in C++ and OTcl
– OTcl = Tcl + OO
– C++ implements the code that executed frequently
– OTcl configures the system
–
How to start
Now we are going to write a 'template' that you can use for all of the first Tcl scripts. You can
write your Tcl scripts in any text editor like joe or emacs. I suggest that you call this first
example 'example1.tcl'.
First of all, you need to create a simulator object. This is done with the command
set ns [new Simulator]
Now we open a file for writing that is going to be used for the nam trace data.
proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}
You don't really have to understand all of the above code yet. It will get clearer to you
once you see what the code does. The next line tells the simulator object to execute the
'finish' procedure after 5.0 seconds of simulation time.
You probably understand what this line does just by looking at it. ns provides you
with a very simple way to schedule events with the 'at' command. The last line finally starts
the simulation.
$ns run
You can actually save the file now and try to run it with 'ns example1.tcl'. You are
going to get an error message like 'nam: empty trace file out.nam' though, because until now
we haven't defined any objects (nodes, links, etc.) or events. You will have to use the code
from this section as starting point in the other sections.
A new node object is created with the command '$ns node'. The above code creates
two nodes and assigns them to the handles 'n0' and 'n1'. The next line connects the two nodes.
This line tells the simulator object to connect the nodes n0 and n1 with a duplex link
with the bandwidth 1Megabit, a delay of 10ms and a DropTail queue.
Now you can save your file and start the script with 'ns example1.tcl'. nam will be started
automatically and you should see an output that resembles the picture below.
#Create a simulator object
set ns [new Simulator]
Sending data
The next step is to send some data from node n0 to node n1. In ns, data is always
being sent from one 'agent' to another. So the next step is to create an agent object that sends
data from node n0, and another agent object that receives the data on node n1.
And now we have to tell the CBR agent when to send data and when to stop sending.
Note: It's probably best to put the following lines just before the line '$ns at 5.0 "finish"'.
This code should be self-explaining again. Now you can save the file and start the
simulation again. When you click on the 'play' button in the nam window, you will see that
after 0.5 simulation seconds, node 0 starts sending data packets to node 1. You might want to
slow nam down then with the 'Step' slider.
Now you start some experiments with nam and the Tcl script. You can click on any
packet in the nam window to monitor it, and you can also click directly on the link to get
some graphs with statistics.Try to change the 'packetsize_' and 'interval_' parameters in the
Tcl script to see what happens.
Thetopology
You will always have to create a simulator object, you will always have to start the
simulation with the same command, and if you want to run nam automatically, you will
always have to open a trace file, initialize it, and define a procedure which closes it and starts
nam.
Now insert the following lines into the code to create four nodes.
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
The following piece of Tcl code creates three duplex links between the nodes.
You can save and start the script now. You might notice that the topology looks a bit
awkward in nam. You can hit the 're-layout' button to make it look better, but it would be nice
to have some more control over the layout. Add the next three lines to your Tcl script and
start it again.
$ns duplex-link-op $n0 $n2 orient right-down
$ns duplex-link-op $n1 $n2 orient right-up
$ns duplex-link-op $n2 $n3 orient right
You will probably understand what this code does when you look at the topology in
the nam window now. It should look like the picture below.
The events
Now we create two UDP agents with CBR traffic sources and attach them to the nodes n0
and n1. Then we create a Null agent and attach it to node n3.
We want the first CBR agent to start sending at 0.5 seconds and to stop at 4.5 seconds while
the second CBR agent starts at 1.0 seconds and stops at 4.0 seconds.
When you start the script now with 'ns example2.tcl', you will notice that there is
more traffic on the links from n0 to n2 and n1 to n2 than the link from n2 to n3 can carry. A
simple calculation confirms this: We are sending 200 packets per second on each of the first
two links and the packet size is 500 bytes. This results in a bandwidth of 0.8 megabits per
second for the links from n0 to n2 and from n1 to n2. That's a total bandwidth of 1.6Mb/s, but
the link between n2 and n3 only has a capacity of 1Mb/s, so obviously some packets are
being discarded. But which ones? Both flows are black, so the only way to find out what is
happening to the packets is to monitor them in nam by clicking on them. In the next two
sections I'm going to show you how to distinguish between different flows and how to see
what is actually going on in the queue at the link from n2 to n3.
Marking flows
Add the following two lines to your CBR agent definitions.
Now you can start the script again and one flow should be blue, while the other one is
red. Watch the link from node n2 to n3 for a while, and you will notice that after some time
the distribution between blue and red packets isn't too fair anymore (at least that's the way it
is on my system). In the next section I'll show you how you can look inside this link's queue
to find out what is going on there.
Monitoring a queue
You only have to add the following line to your code to monitor the queue for the
link from n2 to n3.
Start ns again and you will see a picture similar to the one below after a few moments.
You can see the packets in the queue now, and after a while you can even see how the
packets are being dropped, though (at least on my system, I guess it might be different in later
or earlier releases) only blue packets are being dropped. But you can't really expect too much
'fairness' from a simple Drop Tail queue. So let's try to improve the queuing by using a SFQ
(stochastic fair queuing) queue for the link from n2 to n3. Change the link definition for the
link between n2 and n3 to the following line.
$ns duplex-link $n3 $n2 1Mb 10ms SFQ
The queuing should be 'fair' now. The same amount of blue and red packets should be
dropped.
Ubuntu:
1. Open gedit in Ubuntu Application --> Accessories --> gedit Text editor
2. Save your file with .tcl extension. For example save on Desktop.
3. Open your terminal in ubuntu ( Application --> Accessories --> terminal )
Our tcl file is stored on desktop so we have to change directory in terminal by using
command cd foldername.
Syntax: ns filename.tcl
Example: ns sample.tcl
WINDOWS:
1. Open the notepad and write the ns2 program and save it by using (filename.tcl) .
2. With the help of cygwin we have to check and run the ns2 using WinXserver for
running the .tcl script files.
3. Change your present directory
Our tcl file is stored on desktop so we have to change directory in terminal by using
command cd foldername.
C:\cygwin\home\acer\
set a 20
set b 30
set c [expr $a+$b]
puts $c OUTPUT: 50
Node Creation: