0% found this document useful (0 votes)
4 views12 pages

Computer Network NS2

The document provides an overview of the Network Simulator ns-2, detailing its capabilities in simulating various IP networks and protocols. It explains the process of writing OTcl scripts to set up and run simulations, including defining network topology, traffic sources, and agents. Additionally, it outlines steps for executing simulations in Ubuntu and includes a sample script for a point-to-point network with performance metrics on packet drops.

Uploaded by

deadshotlev
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views12 pages

Computer Network NS2

The document provides an overview of the Network Simulator ns-2, detailing its capabilities in simulating various IP networks and protocols. It explains the process of writing OTcl scripts to set up and run simulations, including defining network topology, traffic sources, and agents. Additionally, it outlines steps for executing simulations in Ubuntu and includes a sample script for a point-to-point network with performance metrics on packet drops.

Uploaded by

deadshotlev
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 12

NETWORK SIMULATOR

The Network Simulator ns-2


NS is an event driven network simulator developed at UC Berkeley that simulates
variety of IP networks. It implements network protocols such as TCP and UPD, traffic source
behaviour 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 more. NS also
implements multicasting and some of the MAC layer protocols for LAN simulations. The NS
project is now a part of the VINT project that develops tools for simulation results display,
analysis and converters that convert network topologies generated by well-known generators
to NS formats. Currently, NS (version 2) written in C++ and OTcl is available.

Figure Simplified User's View of NS

As shown in Figure7.1, in a simplified user's view, NS is Object-oriented Tcl (OTcl)


script interpreter that has a simulation event scheduler and network component object
libraries, and network setup module libraries. 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. When
a user wants to make a new network object, he or she can easily make an object either by
writing a new object or by making a compound object from the object library, and plumb the
data path through the object. This may sound like complicated job, but the plumbing OTcl
modules actually make the job very easy. The power of NS comes from this plumbing. NS is
written not only in OTcl but in C++ also. For efficiency reason, NS separates the data path
implementation from control path implementations. In order to reduce packet and event
processing time (not simulation time), the event scheduler and the basic network component
objects in the data path are written and compiled using C++. These compiled objects are
made available to the OTcl interpreter through an OTcl linkage that creates a matching OTcl
object for each of the C++ objects and makes the control functions and the configurable
variables specified by the C++ object act as member functions and member variables of the
corresponding OTcl object. In this way, the controls of the C++ objects are given to OTcl. It
is also possible to add member functions and variables to a C++ linked OTcl object. The
objects in C++ that do not need to be controlled in a simulation or internally used by another
object do not need to be linked to OTcl. Likewise, an object (not in the data path) can be
entirely implemented in OTcl.

Figure Architectural View of NS

Figure shows the general architecture of NS. In this figure a general user (not an NS
developer) can be thought of standing at the left bottom corner, designing and running
simulations in Tcl using the simulator objects in the OTcl library. The event schedulers and
most of the network components are implemented in C++ and available to OTcl through an
OTcl linkage that is implemented using tclcl. The whole thing together makes NS, which is a
OO extended Tcl interpreter with network simulator libraries.
WRITING A TCL SCRIPT

As shown in Figure 1, we desire to simulate a simple network in which the source node is
generating data with a Mobile Wifi subscriber node as the destination.

Fig simulation scenario

Writing the tcl script for this scenario include the following steps

i) Define simulator.

Creating a simulator is essential for any NS-2 simulation. It is done using the
following simple codes.

Set simulator_name [new simulator]

ii) Define topology.

In this step, define the area (in terms of size) under which the simulation occurs. WE
must define it keeping in view the possible locations of our nodes.

Set topography _ name [new Topography]

$topography _ name load_flatgrid size_x size_y

iii) Define output trace files.


Trace files record events that occur during any simulation like node creation and data
transfer, among others. There are several trace formats and choosing one among them would
depend on the results we are looking for and what the files log. A trace file is defined as
follows.

Set handler [open filename w]

$simulator_name trace _type $handler

iv) Define the General Operations Director (“GOD”).

Quoted from CMU document, "GOD (General Operations Director) is the object that
is used to store global information about the state of the environment, network or nodes that
an omniscient observer would have, but that should not be made known to any participant in
the simulation." In simple words, we need to define the GOD to manage the details of
operations we supply such as the movement patterns in our simulations.

Create-god number_of_nodes

v) Define access point/base station and configure the AP/BS.

To create and configure a base station or an access point in NS-2, it is preferable to define the
options we want to configure the AP/BS with. The configuration is handled as follows.

$simulator_name ap-config-option_1 value_1\

-option_2 value_2\

........................................

To create an AP/BS with the set configuration, we can now define it as follows.

Set ap_name [$simulator_name ap]

Then we need to disable random motion for the AP and give it a location.

$ap_name random-motion 0

$ap_name set X _ x _location


$ap_name set Y _ y _ location

$ap_name set Z _ 0

After you are done with creating the AP, switch off the configuration mode.

$simulator _ name apConfig OFF

vi) Define wireless node, configure it and attach to AP/BS.

Creating and configuring a wireless node is very similar to what we needed to do with the
AP. To set the configurable options, we use the following code.

$simulator _ name node-congig -option _ 1 valu2 _ 1\

-option _ 2 value_ 2 \

....................................

–option_n value _ n\

To create a wireless node (in fact even a wired node):

Set node_name [$simulator _name node]

Disable random motion and set location as we did earlier.

Finally we “attach” the wireless node to the AP.

$node_name base-station [AddrParams addr2id {$ap_name node-addr]]

vii) Define the wired source, configure it and connect it to the AP/BS.

The creation and configuration of the wired source is similar to that of the wireless node,
except we do not “attach” it but rather “connect” it with a wired link.

$simulator_name duplex-link $ node-name $ap_name bandwidth delay queue type


viii) Define traffic generator agent and attach it to the source and destination node.

To define the traffic flow, we need to designate the nodes as source or destination and decide
the type of application/traffic.

The first step is to define the source agent.

Set src_agent_name [new Agent/src_agent_type]

Then designate which node assumes the agent we defined.

$simulator_name attach-agent $src_node_name $src_agent_name

Define the traffic/application type and attach it to source agent.

Set $traffic_name [new Application/Traffic/traffic type]

$traffic_name attach-agent $src_agent_name

It should be noted that each traffic type comes with default values of traffic parameters like rate
and packet size which can be easily overridden with the set command.

Set traffic parameter value

Now define the destination agent and attach it.

Set dest_agent_name [new Agent/dest_agent_type].

$Simulator-name attach-agent $dest_node_name $dest_agent_name

It must be noted that source and destination agents form a pair, and though many options are
available for a type of agent, not all of them all compatible with each other.

Finally, we can connect the agents.

$simulator_name connect $src_agent_name $dest_agent_name

It is necessary to tell the simulator when to start and stop the traffic flow. To do so we
schedule events that controls the agent‟s activities.
$simulator_name at start_time “$traffic_name start”

$simulator_name at stop_time “$traffic_name stop”

ix) Run simulator.

To order the simulator to execute, we simply need to provide the following statement in the
script.

$simulator_name run

It is necessary to clear variables and close files after the simulation ends. It is customary to
create a procedure for that.

$simulator _ name at simulation_stop_time “proc_name”

Proc proc_name {} {

Global vaiable_list file_list

$simulator_name flush-trace

Close $file_name

exit 0

}
STEPS TO RUN NS2 PROGRAM IN UBUNTU

1. In Home folder select the program folder in NS2 allinone2.35 and copy the path location,
to copy the location ctrl+l and ctrl+c.

2. Go to Terminal Window and paste the program folder path location Command for that

mkt@mkt~Aspire-4530:~$cd/home/mkt/ns-allinone-2.35/madocar (folder name)

3. To see the list of file in the folder Command we have to give

mkt@mkt~Aspire-4530:~$cd/home/mkt/ns-allinone-2.35/madocar (folder name) $ ls

Fig List of files in folder

4. To run the program we have to use the command ns filename.tcl

mkt@mkt-Aspire-4530:~/ns-allinone-2.35/madocar$ ns caa.tcl

If there is no error in the program after executing the program we will get Nam window and
Graph windows.

5. For Program trace file also be created in that it contains information like which protocol
we used, traffic generated, packet sent, packet receive, request and reply between the nodes.
Fig Trace File

6. To know the performances metrics we have to write AWK script program that should be
save in same program folder. The performance matrices like throughput, end-to-end delay,
packet delivery ratio, total packet dropped, and total packet sent.

7. To run the AWK script we have to use the command

mkt@mkt-Aspire-4530:~/ns-allinone-2.35/madocar$ gawk -f packet.awk caa.tr

Where packet.awk is the AWK script is to know the performance matrices and caa.tr is the
trace file generated for our program.

Fig Performance matrices


8. To run the graph file separately we have to use the command

mkt@mkt-Aspire-4530:~/ns-allinone-2.35/madocar$ ns graph.tcl

Fig Graph Window


Program 1
1. Implement three nodes point – to – point network with duplex links between them. Set
the queue size, vary the bandwidth and find the number of packets dropped.
# create simulator
set val(stop) 10.0
set ns [new Simulator]
#open trace file and NAM file
set tracefile [open out.tr w]
$ns trace-all $tracefile
set namfile [open out.nam w]
$ns namtrace-all $namfile
#create Three Nodes
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
# Finish Procedure
proc Finish {} {
global ns tracefile namfile
#dump all trace file and close file
$ns flush-trace
close $tracefile
close $namfile
#execute NAM file
exec nam out.nam &
exec echo "The number of packet drops is " &
exec grep -c "^d" out.tr &
exit 0
}
#create TCP source
$n0 label "TCP Source"
$n1 label "Sink"
$ns color 1 blue
#create Link between nodes
$ns duplex-link $n0 $n1 1Mb 10ms DropTail
$ns duplex-link $n1 $n2 1Mb 10ms DropTail
#make the link orientation
$ns duplex-link-op $n0 $n1 orient right
$ns duplex-link-op $n1 $n2 orient right
#set Queue Size
$ns queue-limit $n0 $n1 10
$ns queue-limit $n1 $n2 10
#setup a Transport Layer connection
set tcp [new Agent/TCP]
$tcp set class_ 1+-
$tcp set fid_ 1
$tcp set packetSize 1000
set sink0 [new Agent/TCPSink]
$ns attach-agent $n0 $tcp
$ns attach-agent $n2 $sink0
$ns connect $tcp $sink0
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 0.5 "$ftp start"
$ns at 5.0 "$ftp stop"
set udp_(0) [new Agent/UDP]
$ns attach-agent $n0 $udp_(0)
set sink0 [new Agent/LossMonitor]
$ns attach-agent $n2 $sink0
#setup application layer Traffic
set cbr1_(0) [new Application/Traffic/CBR]
$cbr1_(0) set packetSize_ 1000
$cbr1_(0) set interval_ 0.01
$cbr1_(0) set random_ 1
$cbr1_(0) set rate_ 400kb
$cbr1_(0) set maxpkts_ 1000
$cbr1_(0) attach-agent $udp_(0)
$ns connect $udp_(0) $sink0
#schedule event
$ns at 0.31 "$cbr1_(0) start"
$ns at 5.0 "$cbr1_(0) stop"
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "Finish"
$ns at $val(stop) "puts \"done\" ; $ns halt"
#Run simulation
$ns run

OUTPUT
Packet drop=20

You might also like