Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
LAB SHEET
Note:
On-the-spot evaluation may be carried out during or at the end of the experiment.
Students are advised to read through this lab sheet before doing experiment.
Your performance, teamwork efford, and learning attitude will count towards the marks.
ETM3056 : Communications. Networks CN1: Communication Protocol Analysis
Computer running ns-allinone (latest release is 2.31) is a package which contains required
components and some optional components used in running NS-2. The package contains an
"install" script to automatically configure, compile and install these components.
Currently the package contains:
Tcl release 8.4.14 (Main component)
Tk release 8.4.14 ( Main component)
Otcl release 1.13 ( Main component)
TclCL release 1.19 ( Main component)
Ns release 2.31 (Main component)
Nam (Animation purpose)
Gnuplot (Plotting purpose)
External storage to save the simulation output.
3. INTRODUCTION
3.1 NS-2 SIMULATION TOOL
NS-2 uses two languages because any network simulator, in general, has two different kinds of
things it needs to do. On the one hand, detailed simulations of protocols requires a systems
programming language which can effciently manipulate bytes, packet headers, and implement
algorithms that run over large data sets. For these tasks run-time speed is important and turn-around
time (run simulation, find bug, fix bug, recompile, re-run) is less important. On the other hand, a
large part of network research involves slightly varying parameters or configurations, or quickly
exploring a number of scenarios. In these cases, iteration time (change the model and re-run) is
more important. Since configuration runs once (at the beginning of the simulation), run-time of this
part of the task is less important.
Khairil/Shamini/Muslim Updated 06-2010 (CN1) 1 of 15
ETM3056 : Communications. Networks CN1: Communication Protocol Analysis
NS-2 meets both of these needs with two languages, C++ and Otcl. C++ is fast to run but slower to
change, making it suitable for detailed protocol implementation. Otcl runs much slower but can be
changed very quickly (and interactively), making it ideal for simulation configuration. NS-2 (via
tclcl) provides glue to make objects and variables appear on both languages.
Figure 1
Traces in NS-2 format
$ns trace-all [open tr.out w]
<event> <time> <from> <to> <pkt> <size> -- <fid> <src> <dst> <seq> <attr>
+ 1 0 2 cbr 210 ------- 0 0.0 3.1 0 0
- 1 0 2 cbr 210 ------- 0 0.0 3.1 0 0
r 1.00234 0 2 cbr 210 ------- 0 0.0 3.1 0 0
d 1.04218 1 2 cbr 210 ------- 0 0.0 3.1 0 0
Queue Time From To Traff Pkt Flags Flow Src Dst. Seq. Pkt ID
Node Node Type Size ID Port Port Num.
+,-,r,d double int int string int string int int. int int. int int int
Queue
+ queue, - dequeue, r received, d dropped
Time
time stamp
From/To Nodes
paket is between these nodes
Traffic Type
what type of agent created this traffic
Packet Size
The size of the packet moving from one node to the next
Flags
Any flow control of congestion flags
Flow ID
Helps identify which traffic path this is apart of
Source Port and Destination Port
The end points of the packet
Sequence Number
Used in TCP Windowing and Acking
Packet Number
Unique number used to id this single packet for monitoring sake. NAM allows you to actually
track a packets movement through a network using this ID
4. EXPERIMENTS
For these experiments, we will be using Knoppix with embedded NS-2. Knoppix is complete Linux
distribution that can run for a single CD. Usually this kind of distribution is called a live CD where
it can load Linux system without installing it on a hard drive. The distribution used for this
experiment come with NS-2 embedded in it. Hence, student can run the NS-2 without having to
install it on the hard drive. Please get a Knoppix CD from the lab technician.
After Knoppix uploaded, type the command below to run the KDE environment:
startx
Bring up the Konsole, and setup path for nam and xgraph line by line (press Enter after each
line):
PATH=”$PATH:/usr/local/ns-allinone-2.29/nam-1.11”
export PATH
PATH=”$PATH:/usr/local/ns-allinone-2.29/xgraph-12.1”
export PATH
To check either the paths are already set, type the commands below one by one. It should
return the path to the required applications:
which ns
which nam
which xgraph
cd Desktop
From now on, do save all the documents and files on your desktop.
At the end of session, after logout from the KDE environment, press the below keys
simultaneously to eject the CD:
Ctrl+Alt+Del
Objective: To understand the basic components, simulation setup and simulation animation using
NS-2
ns
Step5: In this section you are going to write a template that you can use for all your simulation
scripts. A simulation in NS-2 is described by a Tcl class Simulator. A simulation script, therefore,
generally begins by creating an instance of this class. This is done with the command
Step6: After creating the simulator object a simulation script usually calls various methods to create
nodes and topologies. Next we have to define what exactly we want to happen in the simulation.
Since the NS-2 simulator is an event-driven simulator this is done by scheduling events: when
creating a simulator object a scheduler is created which runs by selecting the next earliest event,
executing it to completion, and returning to execute the next event. An event can for example be the
sending of data from one node to another node or the failure of a link. The command to schedule an
event is
Example:
Step7: After scheduling all the events, we are ready to start the simulation:
$ns run
Although we have seen the basics of running a simulation we don’t have a way yet to get any output
from the simulation. Fortunately, NS-2 provides a number of ways of collecting output or trace data
on a simulation (We will see this in Section 4.1.3).
Optionally, we can run the above scripts by inserting all the scripts inside a file (say experiment1-
1.tcl) and run the file by executing:
ns experiment1-1.tcl
Create a new file by the name “experiment1-2.tcl”. Type all the followings inside the file.
The following code for example first opens the file ‘out.nam’ for writing and gives it the file handle
‘nf’. It then tells the simulator to trace each packet on every link in the topology and write the data
into the file.
The trace data is collected in a format that can later be used by the nam program to visualize the
simulation in an animation.
The only remaining step is to make sure that all the trace data is flushed into the file at the end of
the simulation and that the file is closed. Furthermore, we have to run the nam tool on the created
trace file to produce the animation. We do this by writing a ‘finish’ procedure that we call at the end
of the simulation and that performs all these tasks.
To create a node we can simply use the simulator method node. The following two lines create two
nodes and assign them to the handles ‘n0’ and ‘n1’.
We can then either use the simulator method simplex-link or the method duplex-link to connect the
nodes with a link:
This creates a bidirectional link between n0 and n1 with bandwidth 1Mbps, a propagation delay of
10ms and a DropTail queue. In addition to the DropTail queue, NS-2 also supports many other
queuing policies like for example FairQueueing(FQ), Random Early Detection (RED), and Class-
based queuing (CBQ).
By now you have some scripts that create topologies but there is not yet trace. Trace generation in
NS-2 is based on objects of two classes, the Agent and the Application.
Agents represent endpoints where network-layer packets are constructed or consumed. Every node
in the network that needs to send or receive trace must have an agent attached to it. These agents
can be thought of as the implementation of the transport protocol.
On top of an agent runs an application. The application determines the kind of trace source that is
simulated (e.g. ftp or telnet). Applications represent the application layer in an NS-2 simulation.
Creating Agents: Corresponding to the two most popular transport protocols used in the Internet
there are also two types of agents in NS-2: UDP agents and TCP agents.
The following code shows an example of attaching a UDP agent to nodes n0 and n1:
This code first creates a UDP agent and attaches it to n0 using the attach-agent procedure. It then
creates a Null agent which will act as a traffic sink and attaches it to n1. Finally, the two agents are
connected using the simulator method connect. In the next section the UDP agent will be used by an
application to send data.
Creating Applications: In the previous section, we have set up the agents implementing the
transport layer. We will now create applications that we attach to the transport agents and that will
actually generate traffic. In NS-2 there are two basic types of applications: simulated applications
and traffic generators.
Traffic generators generate On/Off traffic: during On-periods, packets are generated at a constant
burst rate and during Off-periods no packets are generated. NS-2 provides three different classes of
traffic generators which differ in how the lengths of the On and Off-periods are modelled:
See the NS-2 manual for how to configure these traffic generators.
All traffic generators run on top of a UDP agent. Therefore, we have to attach a traffic generator to
a UDP agent before we can use it to send data. The following example illustrates the use of the
CBR traffic generator that we created above.
The following line calls this procedure at the end of the simulation,
So far, when we wanted to see what is happening in a simulation we have used nam to visualize the
events. However, often we want more detailed trace data on a simulation which then allows us to
compute numbers like packet loss rates or per-connection throughput.
The easiest way to do this is to use the simulator method trace-all which traces all the links in the
topology (insert these 2 lines into your previous file):
When you use trace-all you also have to remember to change the finish procedure to flush the trace
and close the file (as we did previously for the nam tracing).
Sometimes we are only interested in the events at one particular queue and want to avoid the over-
head that comes with tracing every single link in the topology. For this case NS-2 provides us with
the trace-queue method. In addition, Section 22 of the NS-2 manual describes many other ways of
collecting trace data.
Instead of tracing events it is often useful to trace C++ or Tcl instance variables. Below is an
example of setting up variable tracing in NS-2.
Figure 2
Task(1a): Now execute the file that you have created which refer to Figure 2 (experiment1-2.tcl)
ns experiment1-2.tcl
Task(1b): Describes your simulation above. Hence, construct the topology in Figure 3 and name
the file “experiment1-3.tcl”
Figure 3
Objective: To understand the simulation output tools and analysis using NS-2
ns experiment2.tcl
The “grep” command in unix allow us to “filter” a file. We can create a new file which consists of
only those lines from the original file that contain a given character sequence. For example, output
traces in NS-2 may obtain all types packets that go through all links and we may be interested only
in the data concerning tcp packets that went from node 0 to node 3. If lines concerning such events
contain the string “ 0 3 tcp” then all we have to do is type
where “experiment2.tr” is the original trace and “experiment2-1.tr” is the new file. If we wish to
obtain a file containing all lines of experiment2.tr that begin with the letter r, we should type
if we wish to make a file of all the lines begin with “s” and have later “tcp 1040” we should type
We are going to use xgraph instead of gnuplot to do our analysis. To plot using xgraph, it
will only read from file consist only 2 columns of data. Hence, to extract certain columns
from the required data:
awk ‘{print $column1, $column2}’ outputfile.tr > newfile.tr
Example to select column 1 and column 2 from file ‘experiment2.tr’ and save it into new
file ‘plot1.tr’:
awk ‘{print $1, $2}’ experiment2.tr > plot1.tr
To start plotting:
xgraph plot1.tr
Task(2b): Plot the graph of experiment2.tr from different link and comment on the results
Task(2c): Plot the graph of experiment2.tr from different link and comment on the results. PLOT in
EXCEL
ns experiment3-1.tcl
nam experiment3-1.nam
Task(3a)
Draw and indicate network properties of the simulated script.
Identify the queuing discipline of the router used in the simulation
Plot the sender's TCP window over simulation time. Determine where the TCP slow-starts ends
and where congestion avoidance begins.
Calculate the throughput of the transfer.
Say now that we consider the same topology but the link experiences random losses (usually
wireless link)
ns experiment3-2.tcl
nam experiment3-2.nam
Task(3b)
Plot the same sender's TCP window over simulation time.
Calculate the throughput of this connection
By changing the script from using “TCP/Reno” to “TCP/Newreno”, repeat the simulation and
again calculate the throughput.
Is there any improvement between “TCP/Reno” compare to “TCP/Newreno”? Comment if there
is any improvement.
Discuss what are the limitations of conducting simulation experiment using NS-2 compare
to real implementation testing?
Besides using the xgraph to plot the out graph, name and discuss other tools that can use for
the same purpose?
Discuss in brief, what would be the best implementation and assumptions for a video
conference simulation.
6. REFERENCES
[1] The Network Simulator - NS-2 (no date). Home page. [Online]. University of Michigan.
http://nsnam.isi.edu/nsnam/index.php/User_Information [2007, June 11].
[2] NS Manual (no date). Home page. [Online]. University of Michigan.
http://www.isi.edu/nsnam/ns/ns-documentation.html [2007, June 11].
[3] NS by Example (no date). Home page. [Online]. University of Michigan.
http://nile.wpi.edu/NS/ [2007, June 11].
[4] Fred Halsall, “Computer Networking and the Internet”, 5th Edition, Addison Wesley; 2005
Appendix I
Appendix II
Experiment 2 – Source Code
Appendix III
Experiment 3-1 – Source Code
# whether to create the nam log for visualization $ns connect $tcpSender $tcpReceiver
{yes,no}
set namlog "yes" $ns at $starttime "$ftp start"
# when to start the sender $ns at $stoptime "$ftp stop"
set starttime 1.0
# when to stop the simulation $ns at $stoptime "finish"
set stoptime 10.0
# where to log the sender's cwnd trace # do the simulation
set logfilename "experiment3-1.out" $ns run
if {$namlog == "yes"} {
set namf [open experiment3-1.nam w]
$ns namtrace-all $namf
}
proc finish {} {
global ns namlog cwndf namf
$ns flush-trace
close $cwndf
if {$namlog == "yes"} {
close $namf
}
exit 0
}
# source node
set src [$ns node]
# desination node
set dst [$ns node]
# routers
set r1 [$ns node]
set r2 [$ns node]
# bottleneck link
$ns duplex-link $r1 $r2 1Mb 16ms DropTail
# router queue
$ns queue-limit $r1 $r2 5
# access links
$ns duplex-link $src $r1 11Mb 2ms DropTail
$ns duplex-link $dst $r2 11Mb 2ms DropTail
Appendix IV
Experiment 3-2 – Source Code
# source node
set src [$ns node]
# desination node
set dst [$ns node]
# routers
set r1 [$ns node]
set r2 [$ns node]
# bottleneck link
$ns duplex-link $r1 $r2 1Mb 10ms DropTail
# router queue
$ns queue-limit $r1 $r2 10
# access links
$ns duplex-link $src $r1 11Mb 2ms DropTail
$ns duplex-link $r2 $dst 11Mb 2ms DropTail
1. OBJECTIVE
Multimedia University
CN2
In this laboratory, you are going to learn to use the mobile wireless simulation model available in the
Network Simulator (NS). Three experiments have been setup to simulate different topology and
different functionalities of the wireless capability in NS.
2. INTRODUCTION
NS is an Application Programming Interface (API). The wireless model in NS was originally designed
by CMU's Monarch group's mobility extension. In this original version, it covers the internal of a
mobilenode, routing mechanisms and network components that are used to construct the network stack
for a mobilenode. The components that are covered briefly are Channel, Network-interface, Radio
Propagation model, MAC protocols, Interface Queue, Link Layer and Address Resolution Protocol
model (ARP). CMU trace support and Generation of node movement and traffic scenario files are also
covered. The original CMU model allows simulation of pure wireless LANs or multihop ad-hoc
networks. Further extensions were made to this model to allow combined simulation of wired and
wireless networks. MobileIP was also extended to the wireless model.
A mobilenode consists of network components like Link Layer (LL), Interface Queue (IfQ), MAC
layer, the wireless channel nodes transmit and receive signals from, etc. For details about these network
components refer to the NS Manual.
At the beginning of a wireless simulation, we need to define the type for each of these network
components. For example, there are four different wireless ad-hoc routing protocols currently
implemented for mobile networking in NS that we could choose from. They are (i) DSDV (Highly
Dynamic Destination-Sequenced Distance Vector routing protocol), (ii) Dynamic Source Routing
(DSR), (iii) TORA (Temporally-Ordered Routing Algorithm routing protocol) and (iv) Ad hoc On-
demand Distance Vector Routing (AODV). Additionally, we need to define other parameters like the
type of antenna, the radio-propagation model 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 will begin
our tcl script 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
An object god will need to be created. 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 omniscient
observer would have, but that should not be made known to any participant in the
simulation."
Authors: Zalifah/Khairil/Nazeri/05-2007 (T1 Session 2010/2011) Page 1 of 13
ETM3056 Communication Networks Wireless Network 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 mobilenodes. So even though we
may not utilise god for evaluation purposes, we still need to create god.
A setdest program generates movement pattern files using the random waypoint algorithm. The node-
movement files generated using setdest (like scen-3-test which we will use in Experiment 2) already
include lines like above to load the god object with the appropriate information at the appropriate time.
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.
3. SOFTWARE REQUIRED
4. EXPERIMENT
We are going to simulate a very simple 2-node wireless scenario. The topology consists of two
mobilenodes, node_(0) and node_(1). The mobilenodes move about within an area whose boundary is
defined in this example as 500mX500m. 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 mobilenodes. 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. You
need to assign a name to this tcl file such as mywireless.tcl.
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 a xxx.tr file (such as simple.tr) and call the procedure trace-all {}
as follows:
Also we are going to set up nam traces. To support nam trace, setup this by opening a xxx.nam file
(such as wireless-out.nam).
Next create a topology object that keeps track of movements of mobilenodes within the topological
boundary.
We had earlier mentioned that mobilenodes move within a topology of 500mX500m. We provide the
topography object with x and y co-ordinates of the boundary, (x=500, y=500) :
The topography is broken up into grids and the default value of grid resolution is 1. A different value
can be passed as a third parameter to load_flatgrid {} above.
create-god $val(nn)
Then, we create mobilenodes. 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
Note: All default values for these options are NULL except for addressingType = flat
We are going to use the default value of flat addressing. Also let’s turn on only AgentTrace and
RouterTrace. You can experiment with the traces by turning all of them on. MovementTrace, when
turned on, shows the movement of the mobilenodes.
# 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 ON
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
Node0 has a starting position of (5,2) while Node1 starts off at location (390,385).
#
# 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"
$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.
This sets up a TCP connection between the two nodes with a TCP source on node0.
Next add the following lines for providing initial position of nodes in nam.
Then we need to define stop time when the simulation ends and tell mobilenodes to reset which
actually resets their 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";
}
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.
Now that you have finished writing the code, save the file and assign it a name (such as mywireless.tcl).
Next run the simulation by typing "ns filename.tcl " such as "ns mywireless.tcl" at prompt.
At the end of the simulation run, trace-output file simple.tr and nam file wireless.nam are created. You
can open the file to see the content of these files. As we have turned on the AgentTrace and
RouterTrace we see DSDV routing messages and TCP packets being received and sent by Router and
Authors: Zalifah/Khairil/Nazeri/05-2007 (T1 Session 2010/2011) Page 5 of 13
ETM3056 Communication Networks Wireless Network Simulation
Agent objects in node _0_ and _1_. We see TCP flow starting at 10.0s from node0. Initially both the
nodes are far apart and thus TCP packets 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. Packets start getting dropped as the nodes move away from one
another.
To see the movement or animation, type “nam filename.nam” or “nam wireless.nam” at prompt. Nam
windows will come up and you can see the nodes in one of them. Click on the “play” button to start
the animation.
As an extension to the previous experiment, we are going to simulate a simple multihop wireless
scenario consisting of 3 mobilenodes here. As before, the mobilenodes 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 mobilenodes 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".
In addition to node-movements, traffic flows that are setup between the mobilenodes, 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 mobilenodes and data packets are sent,
forwarded or received by nodes within hearing range of one another.
We shall make changes to the tcl script, we had created in Experiment 1 and shall assign a new name
to the resulting file (such as wireless1.tcl). 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, for convenience. They are
listed as follows:
Number of mobilenodes is changed to 3. Also we use DSR (dynamic source routing) as the adhoc
routing protocol in place of DSDV (Destination sequence distance vector);
After the creation of ns_, the simulator instance, open a file (such as wireless1-out.tr) for wireless
traces. Also we are going to set up nam traces. You can assign new names for these files as to be
different from Experiment 1.
Next (after the creation of mobilenodes) 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)
This, as described in earlier sub-section, means at time 50s, node2 starts to move towards destination
(368.4,170.5) at a speed of 3.37m/s. We also see other lines like
$god_ set-dist 1 2 2
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.
Next add informative headers for the CMUTrace file, just before the line "ns_ run" :
Save the file and assign a name such as 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:
ns wireless1.tcl
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 mobilenodes moving in nam
window.
The wireless simulation described earlier supports multi-hop ad-hoc networks or wireless LANs. But
we may need to simulate a topology of multiple LANs connected through wired nodes, or in other
words we need to create a wired-and-wireless topology.
In this section we are going to extend the simple wireless topology created earlier to create a mixed
scenario consisting of a wireless and a wired domain, where data is exchanged between the mobile and
non-mobile nodes. Modifications have been made to the earlier tcl script and named as wireless2.tcl.
For the mixed scenario, we are going to have 2 wired nodes, W(0) and W(1), connected to our wireless
domain consisting of 3 mobilenodes (nodes 0, 1 & 2) via a base-station node, BS. Base station nodes
are like gateways between wireless and wired domains and allow packets to be exchanged between the
two types of nodes. Fig1 below shows the topology for this example described above.
The Adhoc routing protocol used is DSDV. Also, we define TCP and CBR connections between the
wired and wireless nodes in the script itself. So we do not need to use the connection pattern file used
in earlier simulation. Also the simulation stop time has been changed. Note here that we use array opt()
instead of val() simply to illustrate that this is no longer a global array variable and its scope is defined
only in the test script. The full script is included in the Appendix.
Run the script. The ns and nam trace files are generated at the end of simulation run. Running
wireless2-out.nam shows the movement of mobilenodes and traffic in the wired domain.
5. REFERENCE
i. NS manual, http://www.isi.edu/nsnam/ns/doc
ii. NS tutorial, http://www.isi.edu/nsnam/ns/tutorial/index.html
6. DISCUSSION/ QUESTIONS
APPENDIX I
#
# 0 connecting to 2 at time 127.93667922166023
#
set udp_(0) [new Agent/UDP]
$ns_ attach-agent $node_(0) $udp_(0)
set null_(0) [new Agent/Null]
$ns_ attach-agent $node_(2) $null_(0)
set cbr_(0) [new Application/Traffic/CBR]
$cbr_(0) set packetSize_ 512
$cbr_(0) set interval_ 4.0
$cbr_(0) set random_ 1
$cbr_(0) set maxpkts_ 10000
$cbr_(0) attach-agent $udp_(0)
$ns_ connect $udp_(0) $null_(0)
$ns_ at 127.93667922166023 "$cbr_(0) start"
APPENDIX II
# wireless2.tcl
# simulation of a wired-and-wireless scenario consisting of 2 wired nodes
# connected to a wireless domain through a base-station node.
# ======================================================================
# Define options
# ======================================================================
set opt(chan) Channel/WirelessChannel ;# channel type
set opt(prop) Propagation/TwoRayGround ;# radio-propagation model
set opt(netif) Phy/WirelessPhy ;# network interface type
set opt(mac) Mac/802_11 ;# MAC type
set opt(ifq) Queue/DropTail/PriQueue ;# interface queue type
set opt(ll) LL ;# link layer type
set opt(ant) Antenna/OmniAntenna ;# antenna model
set opt(ifqlen) 50 ;# max packet in ifq
set opt(nn) 3 ;# number of mobilenodes
set opt(adhocRouting) DSDV ;# routing protocol
set num_wired_nodes 2
set num_bs_nodes 1
# ============================================================================
# check for boundary parameters and random seed
if { $opt(x) == 0 || $opt(y) == 0 } {
puts "No X-Y boundary values given for wireless topology\n"
}
if {$opt(seed) > 0} {
puts "Seeding Random number generator with $opt(seed)\n"
ns-random $opt(seed)
}
# define topology
$topo load_flatgrid $opt(x) $opt(y)
# create God
create-god [expr $opt(nn) + $num_bs_nodes]