In this section, you are going to learn to use the mobile wireless
simulation model available in ns. The section consists of two parts. In
the first subsection, we discuss how to create and run a simple 2-node
wireless network simulation. In second subsection, we will extend our
program to create a relatively more complex wireless scenario.
We are going to simulate a very simple 2-node wireless scenario. The
topology consists of two mobile nodes, node_(0) and node_(1). The mobile
nodes move about within an area whose boundary is defined in this
example as 500m X 500m. The nodes start out initially at two opposite
ends of the boundary. Then they move towards each other in the first
half of the simulation and again move away for the second half. A TCP
connection is setup between the two mobile nodes. Packets are exchanged
between the nodes as they come within hearing range of one another. As
they move away, packets start getting dropped.
Just as with any other ns simulation, we begin by creating a tcl script for the wireless simulation. We will call this file
simple-wireless.tcl.
If you want to download a copy of simple-wireless.tcl click here.
A mobile node consists of network components like Link Layer (LL),
Interface Queue (IfQ), MAC layer, the wireless channel nodes transmit
and receive signals from etc.
At the beginning of a wireless simulation, we need to define the type
for each of these network components. Additionally, we need to define
other parameters like the type of antenna, the radio-propagation model,
the type of ad-hoc routing protocol used by mobilenodes etc. See
comments in the code below for a brief description of each variable
defined. The array used to define these variables, val() is not global
as it used to be in the earlier wireless scripts.We begin our script
simple-wireless.tcl with a list of these different parameters described
above, as follows:
# ======================================================================
# Define options
# ======================================================================
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(ant) Antenna/OmniAntenna ;# Antenna type
set val(ll) LL ;# Link layer type
set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type
set val(ifqlen) 50 ;# max packet in ifq
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(rp) DSDV ;# ad-hoc routing protocol
set val(nn) 2 ;# number of mobilenodes
|
Next we go to the main part of the program and start by creating an instance of the simulator,
Then setup trace support by opening file simple.tr and call the procedure trace-all {} as follows:
set tracefd [open simple.tr w]
$ns_ trace-all $tracefd
|
Next create a topology object that keeps track of movements of mobilenodes within the topological boundary.
set topo [new Topography]
|
We had earlier mentioned that mobile nodes move within a topology of
500m X 500m. We provide the topography object with x and y co-ordinates
of the boundary, (x=500, y=500) :
$topo load_flatgrid 500 500
|
The topography is broken up into grids and the default value of grid
resolution is 1. A diferent value can be passed as a third parameter to
load_flatgrid {} above.
Next we create the object God, as follows:
Quoted from CMU document on god, "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 omniscent observer would have,
but that should not be made known to any participant in the
simulation." Currently, God object stores the total number of mobile
nodes and a table of shortest number of hops required to reach from one
node to another. The next hop information is normally loaded into god
object from movement pattern files, before simulation begins, since
calculating this on the fly during simulation runs can be quite time
consuming. However, in order to keep this example simple we avoid using
movement pattern files and thus do not provide God with next hop
information. The usage of movement pattern files and feeding of next hop
info to God shall be shown in the example in the next sub-section.
The procedure create-god is defined in ~ns/tcl/mobility/com.tcl,
which allows only a single global instance of the God object to be
created during a simulation. In addition to the evaluation
functionalities, the God object is called internally by MAC objects in
mobile nodes. So even though we may not utilize God for evaluation
purposes,(as in this example) we still need to create God.
Next, we create mobile nodes. The node creation APIs have been revised
and here we shall be using the new APIs to create mobile nodes.
IMPORTANT NOTE: The new APIs are not available with ns2.1b5 release.
Download the daily snapshot version if the next release (2.1b6 upwards)
is not as yet available.
First, we need to configure nodes before we can create them. Node
configuration API may consist of defining the type of addressing
(flat/hierarchical etc), the type of adhoc routing protocol, Link Layer,
MAC layer, IfQ etc. The configuration API can be defined as follows:
(parameter examples)
# $ns_ node-config -addressingType flat or hierarchical or expanded
# -adhocRouting DSDV or DSR or TORA
# -llType LL
# -macType Mac/802_11
# -propType "Propagation/TwoRayGround"
# -ifqType "Queue/DropTail/PriQueue"
# -ifqLen 50
# -phyType "Phy/WirelessPhy"
# -antType "Antenna/OmniAntenna"
# -channelType "Channel/WirelessChannel"
# -topoInstance $topo
# -energyModel "EnergyModel"
# -initialEnergy (in Joules)
# -rxPower (in W)
# -txPower (in W)
# -agentTrace ON or OFF
# -routerTrace ON or OFF
# -macTrace ON or OFF
# -movementTrace ON or OFF
|
All default values for these options are NULL except: addressingType: flat
We are going to use the default value of flat addressing; Also lets turn
on only AgentTrace and RouterTrace; You can experiment with the traces
by turning all of them on. AgentTraces are marked with AGT, RouterTrace
with RTR and MacTrace with MAC in their 5th fields. MovementTrace, when
turned on, shows the movement of the mobilenodes and the trace is marked
with M in their 2nd field.
The configuration API for creating mobilenodes looks as follows:
# Configure nodes
$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) \
-topoInstance $topo \
-channelType $val(chan) \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace OFF
|
Next we create the 2 mobilenodes as follows:
for {set i 0} {$i < $val(nn) } {incr i} {
set node_($i) [$ns_ node ]
$node_($i) random-motion 0 ;# disable random motion
}
|
The random-motion for nodes is disabled here, as we are going to provide
node position and movement(speed & direction) directives next.
Now that we have created mobilenodes, we need to give them a position to start with,
#
# Provide initial (X,Y, for now Z=0) co-ordinates for node_(0) and node_(1)
#
$node_(0) set X_ 5.0
$node_(0) set Y_ 2.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 390.0
$node_(1) set Y_ 385.0
$node_(1) set Z_ 0.0
|
Node0 has a starting position of (5,2) while Node1 starts off at location (390,385).
Next produce some node movements,
#
# Node_(1) starts to move towards node_(0)
#
$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0"
$ns_ at 10.0 "$node_(0) setdest 20.0 18.0 1.0"
# Node_(1) then starts to move away from node_(0)
$ns_ at 100.0 "$node_(1) setdest 490.0 480.0 15.0"
|
$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0" means at time 50.0s,
node1 starts to move towards the destination (x=25,y=20) at a speed of
15m/s. This API is used to change direction and speed of movement of the
mobilenodes.
Next setup traffic flow between the two nodes as follows:
# TCP connections between node_(0) and node_(1)
set tcp [new Agent/TCP]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_(0) $tcp
$ns_ attach-agent $node_(1) $sink
$ns_ connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 10.0 "$ftp start"
|
This sets up a TCP connection betwen the two nodes with a TCP source on node0.
Then we need to define stop time when the simulation ends and tell
mobilenodes to reset which actually resets thier internal network
components,
#
# Tell nodes when the simulation ends
#
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at 150.0 "$node_($i) reset";
}
$ns_ at 150.0001 "stop"
$ns_ at 150.0002 "puts \"NS EXITING...\" ; $ns_ halt"
proc stop {} {
global ns_ tracefd
close $tracefd
}
|
At time 150.0s, the simulation shall stop. The nodes are reset at that
time and the "$ns_ halt" is called at 150.0002s, a little later after
resetting the nodes. The procedure stop{} is called to flush out traces
and close the trace file. And finally the command to start the
simulation,
puts "Starting Simulation..."
$ns_ run
|
Save the file simple-wireless.tcl. In order to download a copy of the file click here. Next run the simulation in the usual way (type at prompt:
"ns simple-wireless.tcl" )
At the end of the simulation run, trace-output file simple.tr is
created. As we have turned on the AgentTrace and RouterTrace we see DSDV
routing messages and TCP pkts being received and sent by Router and
Agent objects in node _0_ and _1_. Note that all wireless traces starts
with WL in their first field. See Chapter 15 of ns documentation for
details on wireless trace. We see TCP flow starting at 10.0s from node0.
Initially both the nodes are far apart and thus TCP pkts are dropped by
node0 as it cannot hear from node1. Around 81.0s the routing info
begins to be exchanged between both the nodes and around 100.0s we see
the first TCP pkt being received by the Agent at node1 which then sends
an ACK back to node0 and the TCP connection is setup. However as node1
starts to move away from node0, the connection breaks down again around
time 116.0s. Pkts start getting dropped as the nodes move away from one
another.
2. Using node-movement/traffic-pattern files and other features in wireless simulations
As an extension to the previous sub-section, we are going to simulate a
simple multi hop wireless scenario consisting of 3 mobile nodes here. As
before, the mobile nodes move within the boundaries of a defined
topology. However the node movements for this example shall be read from
a node-movement file called
scen-3-test. scen-3-test
defines random node movements for the 3 mobile nodes within a topology
of 670mX670m. This file is available as a part of the ns distribution
and can be found, along with other node-movement files, under directory
~ns/tcl/mobility/scene.
Random node movement files like scen-3-test can be generated using
CMU's node-movement generator "setdest". Details on generation of node
movement files are covered in
Generating traffic-connection and node-movement files for large wireless scenarios section of this tutorial.
In addition to node-movements, traffic flows that are setup between the
mobile nodes, are also read from a traffic-pattern file called
cbr-3-test. cbr-3-test is also available under ~ns/tcl/mobility/scene.
Random CBR and TCP flows are setup between the 3 mobile nodes and data
packets are sent, forwarded or received by nodes within hearing range of
one another. See cbr-3-test to find out more about the traffic flows
that are setup. These traffic-pattern files can also be generated using
CMU's TCP/CBR traffic generator script. More about this is discussed in
Generating traffic-connection and node-movement files for large wireless scenarios section of this tutorial.
We shall make changes to the script,
simple-wireless.tcl, we had created in above section. and shall call the resulting file wireless1.tcl.
For a copy of wireless1.tcl download from here.
In addition to the variables (LL, MAC, antenna etc) that were declared
at the beginning of the script, we now define some more parameters like
the connection-pattern and node-movement file, x and y values for the
topology boundary, a seed value for the random-number generator, time
for the simulation to stop, for convenience. They are listed as follows:
set val(chan) Channel/WirelessChannel
set val(prop) Propagation/TwoRayGround
set val(netif) Phy/WirelessPhy
set val(mac) Mac/802_11
set val(ifq) Queue/DropTail/PriQueue
set val(ll) LL
set val(ant) Antenna/OmniAntenna
set val(x) 670 ;# X dimension of the topography
set val(y) 670 ;# Y dimension of the topography
set val(ifqlen) 50 ;# max packet in ifq
set val(seed) 0.0
set val(adhocRouting) DSR
set val(nn) 3 ;# how many nodes are simulated
set val(cp) "../mobility/scene/cbr-3-test"
set val(sc) "../mobility/scene/scen-3-test"
set val(stop) 2000.0 ;# simulation time
|
Number of mobile nodes is changed to 3; Also we use DSR (dynamic source
routing) as the adhoc routing protocol inplace of DSDV (Destination
sequence distance vector);
After creation of ns_, the simulator instance, open a file
(wireless1-out.tr) for wireless traces. Also we are going to set up nam
traces.
set tracefd [open wireless1-out.tr w] ;# for wireless traces
$ns_ trace-all $tracefd
set namtrace [open wireless1-out.nam w] ;# for nam tracing
$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
|
Next (after creation of mobile nodes) source node-movement and
connection pattern files that were defined earlier as val(sc) and
val(cp) respectively.
#
# Define node movement model
#
puts "Loading connection pattern..."
source $val(cp)
#
# Define traffic model
#
puts "Loading scenario file..."
source $val(sc)
|
In node-movement file scen-3-test, we see node-movement commands like
$ns_ at 50.000000000000 "$node_(2) setdest 369.463244915743 \
170.519203111152 3.371785899154"
|
This, as described in earlier sub-section, means at time 50s, node 2
starts to move towards destination (368.4,170.5) at a speed of 3.37m/s.
We also see other lines like
These are command lines used to load the god object with the shortest
hop information. It means the shortest path between node 1 and 2 is 2
hops. By providing this information, the calculation of shortest
distance between nodes by the god object during simulation runs, which
can be quite time-consuming, is prevented.
A program called calcdest
(~ns/indep-utilities/cmu-scen-gen/setdest/calcdest) can be used to
annotate movement pattern files generated by other means with the lines
of god information. calcdest makes several assumptions about the format
of the lines in the input movement pattern file which will cause it to
fail if the file is not formatted properly. If calcdest rejects a
movement pattern file you have created, the easiest way to format it
properly is often to load it into ad-hockey and then save it out again.
If ad-hockey can read your input correctly, its output will be properly
formatted for calcdest.
Both setdest and calcdest calculate the shortest number of hops between
nodes based on the nominal radio range, ignoring any effects that might
be introduced by the propagation model in an actual simulation. The
nominal range is either provided as an argument to the programs, or
extracted from the header in node-movement pattern files.
The path length information provided to god was used by CMU's Monarch
Project to analyze the path length optimality of ad hoc network routing
protocols, and so was printed out as part of the CMUTrace output for
each packet.
Other uses that CMU has found for the information are:
- Characterizing the rate of topology change in a movement pattern.
- Identifying the frequency and size of partitions.
- Experimenting with the behavior
of the routing protocols if the god information is used to provide
them with ``perfect'' neighbor information at zero cost.
Next add the following lines for providing initial position of nodes in
nam. However note that only node movements can currently be seen in nam .
Dumping of traffic data and thus visualization of data pkt movements in
nam for wireless scenarios is still not supported (future work).
# Define node initial position in nam
for {set i 0} {$i < $val(nn)} {incr i} {
# 20 defines the node size in nam, must adjust it according to your
# scenario size.
# The function must be called after mobility model is defined
$ns_ initial_node_pos $node_($i) 20
}
|
Next add informative headers for the CMUTrace file, just before the line "ns_ run" :
puts $tracefd "M 0.0 nn $val(nn) x $val(x) y $val(y) rp $val(adhocRouting)"
puts $tracefd "M 0.0 sc $val(sc) cp $val(cp) seed $val(seed)"
puts $tracefd "M 0.0 prop $val(prop) ant $val(ant)"
|
The rest of the script remains unchanged.
Save the file wireless1.tcl. Make sure the connection-pattern and
node-movement files exist under the directories as declared above.
Run the script by typing at the prompt:
On completion of the run, CMUTrace output file "wireless1-out.tr" and
nam output file "wireless1-out.nam" are created. Running
wireless1-out.nam we see the three mobile nodes moving in nam window.
However as mentioned earlier no traffic flow can be seen (not supported
as yet). For a variety of coarse and fine grained trace outputs turn
on/off AgentTrace, RouteTrace, MacTrace and movementTrace as shown
earlier in the script. From the CMUTrace output we find nodes 0 and 2
are out of range and so cannot hear one another. Node1 is in range with
nodes 0 and 2 and can communicate with both of them. Thus all pkts
destined for nodes 0 and 2 are routed through node 1.
3. Creating random traffic-pattern for wireless scenarios.
Random traffic connections of TCP and CBR can be setup between mobile
nodes using a traffic-scenario generator script. This traffic generator
script is available under ~ns/indep-utils/cmu-scen-gen and is called
cbrgen.tcl. It can be used to create CBR and TCP traffics connections
between wireless mobile nodes. In order to create a traffic-connection
file, we need to define the type of traffic connection (CBR or TCP), the
number of nodes and maximum number of connections to be setup between
them, a random seed and in case of CBR connections, a rate whose inverse
value is used to compute the interval time between the CBR pkts. So the
command line looks like the following
ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] [-mc connections]
[-rate rate]
|
The start times for the TCP/CBR connections are randomly generated with a
maximum value set at 180.0s. Go through the tcl script cbrgen.tcl for
the details of the traffic-generator implementation.
For example, let us try to create a CBR connection file between 10
nodes, having maximum of 8 connections, with a seed value of 1.0 and a
rate of 4.0. So at the prompt type:
ns cbrgen.tcl -type cbr -nn 10 -seed 1.0 -mc 8 -rate 4.0 > cbr-10-test
|
From cbr-10-test file (into which the output of the generator is
redirected) thus created, one of the cbr connections looks like the
following:
#
# 2 connecting to 3 at time 82.557023746220864
#
set udp_(0) [new Agent/UDP]
$ns_ attach-agent $node_(2) $udp_(0)
set null_(0) [new Agent/Null]
$ns_ attach-agent $node_(3) $null_(0)
set cbr_(0) [new Application/Traffic/CBR]
$cbr_(0) set packetSize_ 512
$cbr_(0) set interval_ 0.25
$cbr_(0) set random_ 1
$cbr_(0) set maxpkts_ 10000
$cbr_(0) attach-agent $udp_(0)
$ns_ connect $udp_(0) $null_(0)
$ns_ at 82.557023746220864 "$cbr_(0) start"
|
Thus a UDP connection is setup between node 2 and 3. Total UDP sources
(chosen between nodes 0-10) and total number of connections setup is
indicated as 5 and 8 respectively, at the end of the file cbr-10-test.
Similarly TCP connection files can be created using "type" as tcp. An example would be:
ns cbrgen.tcl -type tcp -nn 25 -seed 0.0 -mc 8 > tcp-25-test
|
A typical connection from tcp-25-test looks like the following:
#
# 5 connecting to 7 at time 163.0399642433226
#
set tcp_(1) [$ns_ create-connection TCP $node_(5) TCPSink $node_(7) 0]
$tcp_(1) set window_ 32
$tcp_(1) set packetSize_ 512
set ftp_(1) [$tcp_(1) attach-source FTP]
$ns_ at 163.0399642433226 "$ftp_(1) start"
|
4. Creating node-movements for wireless scenarios
The node-movement generator is available under
~ns/indep-utils/cmu-scen-gen/setdest directory and consists of
setdest{.cc,.h} and Makefile. CMU's version of setdest used system
dependent /dev/random and made calls to library functions initstate()
for generating random numbers. That was replaced with a more portable
random number generator (class RNG) available in ns. In order to compile
the revised setdest.cc do the following:
1. Go to ns directory and run "configure" (you probably have done that
already while building ns). This creates a makefile for setdest.
2.Go to indep-utils/cmu-scen-gen/setdest. Run "make" , which first
creates a stand-alone object file for ~ns/rng.cc (the stand-alone
version doesnot use Tclcl libs) and then creates the executable
setdest.
3. Run setdest with arguments as shown below:
./setdest [-n num_of_nodes] [-p pausetime] [-s maxspeed] [-t simtime] \
[-x maxx] [-y maxy] > [outdir/movement-file]
|
Lets say we want to create a node-movement scenario consisting of 20
nodes moving with maximum speed of 10.0m/s with an average pause between
movement being 2s. We want the simulation to stop after 200s and the
topology boundary is defined as 500 X 500. So our command line will look
like:
./setdest -n 20 -p 2.0 -s 10.0 -t 200 -x 500 -y 500 > scen-20-test
|
The output is written to stdout by default. We redirect the output to
file scen-20-test. The file begins with the initial position of the
nodes and goes on to define the node movements.
$ns_ at 2.000000000000 "$node_(0) setdest 90.441179033457 44.896095544010
1.373556960010"
|
This line from scen-20-test defines that node_(0) at time 2.0s starts to
move toward destination (90.44, 44.89) at a speed of 1.37m/s. These
command lines can be used to change direction and speed of movement of
mobile nodes.
Directives for GOD are present as well in node-movement file. The
General Operations Director (GOD) object is used to store global
information about the state of the environment, network, or nodes that
an omniscent observer would have, but that should not be made known to
any participant in the simulation.
Currently, the god object is used only to store an array of the shortest
number of hops required to reach from one node to an other. The god
object does not calculate this on the fly during simulation runs, since
it can be quite time consuming. The information is loaded into the god
object from the movement pattern file where lines of the form
$ns_ at 899.642 "$god_ set-dist 23 46 2"
|
are used to load the god object with the knowledge that the shortest
path between node 23 and node 46 changed to 2 hops at time 899.642.
The setdest program generates node-movement files using the random
waypoint algorithm. These files already include the lines to load the
god object with the appropriate information at the appropriate time.
Another program calcdest (also available in
~ns/indep-utils/cmu-scen-gen/setdest) can be used to annotate movement
pattern files generated by other means with the lines of god
information. calcdest makes several assumptions about the format of the
lines in the input movement pattern file which will cause it to fail if
the file is not formatted properly. If calcdest rejects a movement
pattern file you have created, the easiest way to format it properly is
often to load it into ad-hockey and then save it out again. If ad-hockey
can read your input correctly, its output will be properly formatted
for calcdest.
Both calcdest and setdest calculate the shortest number of hops between
nodes based on the nominal radio range, ignoring any effects that might
be introduced by the propagation model in an actual simulation. The
nominal range is either provided as an argument to the programs, or
extracted from the header on the movement pattern file.
The path length information was used by the Monarch Project to analyze
the path length optimality of ad hoc network routing protocols, and so
was printed out as part of the CMUTrace output for each packet.
- Other uses that CMU found for the information:
- Characterizing the rate of topology change in a movement pattern.
- Identifying the frequency and size of partitions.
- Experimenting with the behavior of the routing protocols if the god
information is used to provide them with perfect'' neighbor information
at zero cost.
Thus at the end of the node-movement
file are listed information like number of destination unreachable,
total number of route and connectivity changes for mobile nodes and the
same info for each mobile node.
The revised (more portable) version
of setdest ( files revised are: setdest{.cc,.h}, ~ns/rng{.cc,.h},
~ns/Makefile.in ) should be available from the latest ns distribution.
