EXPERIMENTS TO DEVELOP CONFIGURABLE
PROTOCOLS
By
PREETI VENKATESWARAN
A REPORT
Submitted in partial fulfillment of the requirements for
the degree
MASTER of SCIENCE
Department of Computing and Information Sciences
College of Engineering
KANSAS STATE UNIVERSITY
Manhattan, Kansas
May 2005
Approved by:
Major Professor
Dr. Gurdip Singh
ABSTRACT
A major concern in communication protocols is their performance arising
due to a mismatch between the protocols and the application requirements.
By designing reconfigurable protocols, one can address this issue by
dynamically
reconfiguring
protocols
based
on
the
application
characteristics. The goal of this project is to conduct experiments to develop
configurable protocols in programmable radio networks.
The network simulator ns (version 2) was used to conduct these experiments.
NS is an object oriented, discrete event, packet level simulator targeted at
networking research. It provides substantial support for simulation of TCP,
routing, and multicast protocols over wired and wireless (local and satellite)
networks.
Experiments were conducted for the Physical, MAC and Network layers of
ns-2. To begin with, Rayleigh and Ricean fading models were incorporated
in the wireless physical layer. The throughput of nodes incorporating the
modified wireless physical layer in their protocol stack was compared for
the different fading models. Transmission power and data rate thresholds
were calculated so that a switch from one scheme to another in the physical
layer could be made. At the MAC layer, the effect of slot time was measured
in the 802.11b standard on the end-to end delay for packet reception. At the
network layer, the effect of cache size, the timeout interval, the speed of
nodes, and the number of nodes on the packet delivery ratio was measured.
TABLE OF CONTENTS
TABLE OF CONTENTS .............................................................................. i
TABLE OF FIGURES ................................................................................ iii
ACKNOWLEDGEMENTS ........................................................................ iv
1 INTRODUCTION ......................................................................................1
1.1 APPROACH .........................................................................................2
1.2 ROADMAP OF THE REPORT .........................................................3
2 NETWORK SIMULATOR .......................................................................5
2.1 INTRODUCTION ................................................................................5
2.2 GENERAL STRUCTURE AND ARCHITECTURE OF NS ..........5
2.3 SAMPLE SIMULATION SCRIPT ....................................................9
2.4. SIMULATOR BASICS.....................................................................13
2.4.1 Event Scheduler .............................................................................13
2.4.2 Basic Node .....................................................................................14
2.4.3 Link ................................................................................................15
2.4.4 Packet .............................................................................................16
2.4.5 Agent ..............................................................................................17
2.4.5.1 Adding a new Agent to NS simulator.........................................19
2.4.6 Application.....................................................................................22
2.5 MOBILE NETWORKING ...............................................................23
2.5.1 Mobile Node ..................................................................................23
2.5.2 Creating Node Movements ............................................................28
2.5.3 Routing Agents ..............................................................................30
2.6 TRACE SUPPORT ............................................................................33
3 EXPERIMENTS TO DEVELOP CONFIGURABLE PROTOCOLS39
i
3.1 PHYSICAL LAYER ..........................................................................39
Implementation of Rayleigh and Ricean Fading Models .......................40
EXPERIMENT 1: Comparison of Two-Ray Ground and Free Space
propagation with Rayleigh and Ricean fading in terms of Packet
Delivery Ratio .........................................................................................42
3.2 DATA LINK LAYER ........................................................................45
EXPERIMENT 2: Effect of Varying Slot time on End-to-End Delay..46
3.3 NETWORK LAYER .........................................................................49
EXPERTIMENT 3: Effect of varying cache size, speed and timeout
interval on Packet Delivery Ratio ...........................................................49
EXPERIMENT 3.1 Cache size vs. Packet delivery ratio .......................50
EXPERIMENT 3.2: Speed vs. Packet Delivery Ratio ..........................52
EXPERIMENT 3.3: Timeout Interval of Send-buffer vs. Packet
Delivery Ratio .........................................................................................53
4 MANAGEMENT LAYER .......................................................................55
Extending NS to Incorporate Management Layer in Protocol Stack of
Each Node .................................................................................................56
EXPERIMENT 4.1: Two Node Scenario ...............................................58
EXPERIMENT 4.2: Three Node Scenario .............................................59
5 CONCLUSIONS .......................................................................................62
APPENDIX (A) ............................................................................................63
APPENDIX (B) ............................................................................................66
APPENDIX (C) ............................................................................................69
APPENDIX (D) ............................................................................................72
APPENDIX (E) ............................................................................................75
REFERENCES ............................................................................................78
ii
TABLE OF FIGURES
Figure 1: Introduction of Management Layer in Protocol Stack ....................3
Figure 2: C++/OTcl Duality ............................................................................6
Figure 3: Simplified View of NS .....................................................................7
Figure 4: Directory Structure of NS ................................................................8
Figure 5: Scenario for a simple Simulation Script ..........................................9
Figure 6: Event Scheduler .............................................................................14
Figure 7: Basic Structure of Node in NS .......................................................15
Figure 8: Simplex Link ..................................................................................15
Figure 9: Packet Structure .............................................................................16
Figure 10: Mobile Node ................................................................................24
Figure 11: Free-Space vs. Packet Delivery Ratio..........................................43
Figure 12: Two-Ray Ground vs. Packet Delivery Ratio ...............................44
Figure 13: Slot-time vs. End-to-end Delay....................................................48
Figure 14: Cache Size vs. Packet Delivery Ratio ..........................................51
Figure 15: Speed vs. Packet Delivery Ratio ..................................................52
Figure 16: Timeout Interval vs. Packet Delivery Ratio.................................54
Figure 17: Scenario for Experiment 4.1 ........................................................58
Figure 18: Scenario for Experiment 4.2 ........................................................60
iii
ACKNOWLEDGEMENTS
I sincerely thank Dr. Gurdip Singh, my major professor, for giving me the
encouragement, advice and guidance to complete this project. I also thank
him for being flexible, adjusting and patient during the course of this project.
I’m grateful to Dr. Mitchell Neilsen and Dr. Scott Deloach for serving on my
committee and agreeing to review my report.
I thank Dr. Don Gruenbacher and Dr. Bala Natrajan for their time and
guidance.
I’m indebted to my family for their love, support and constant
encouragement.
And finally, to Arjun Ramesh, thank you for your patience and support.
iv
1 INTRODUCTION
There is an increasing demand for technology to rapidly deploy and
configure wireless networks. Since the network conditions can change
dynamically, we need to develop configurable protocols to enable dynamic
adaptation to the changing environment.
The programmability of a protocol layer can be exploited by other layers to
improve performance. But, changes in one layer may also constrain the
behavior of the other layers. The optimization and configuration of a
protocol layer must take into account application QoS parameters such as
throughput, delay and packet delivery ratio, as well as constraints from other
layers, changes in topology due to mobility and wireless link quality. Each
layer can be modeled as having several observable and adjustable
parameters. For example, adjustable parameters in the network layer would
include cache size and timeout intervals, while the adjustable physical layer
parameters would include the modulation scheme, transmission strength and
receiver sensitivity.
These adjustable parameters define the “state” of a layer. The goal of this
project is to develop a turbo optimization technique in which the changes in
the state of one layer triggers changes in the other layers until a steady state
is reached.
1
1.1 APPROACH
Our approach to achieving these goals is as follows:
* Identify the adjustable parameters in the different layers
We model each layer in the protocol stack as having several adjustable
parameters which would define the state of a layer. We identify the
adjustable parameters in the Physical, Data link and Network layers and
observe the effect of changing their values on the application QoS
parameters. This helps us fix the different thresholds for these parameters.
These thresholds are then used to decide when to make a switch from one
state to another.
* Introduce a new layer in the protocol stack, which would
communicate with the all the layers and adjust their state depending on
the current environment conditions.
We introduce a management layer in the protocol stack of each node. We
design this layer to be able to communicate with all the layers in the protocol
stack. Depending on the value of certain configurable parameters in one
layer, it changes the value of adjustable parameters in other layers until a
steady state is reached. In this way, the management layer helps in finding
the best state of a layer given the constraints imposed by the environment.
This in turn, helps in developing a turbo optimization technique in which
changes in the state of one layer trigger incremental changes in the other
layers until a steady state is reached.
2
Network Layer
Link Layer
Management Layer
Mac Layer
Physical Layer
Figure 1: Introduction of Management Layer in Protocol Stack
1.2 ROADMAP OF THE REPORT
We used the NS simulator as the simulation platform for this project largely
because of its wide acceptance in the networking community and its open
design suitable for modification. Considerable amount of time was spent in
understanding the working of the simulator, before actually conducting the
experiments of interest. One of the goals of this project was to initiate the
use of NS simulator in our research group at K-State. Hence, an extensive
introduction of NS is given in the report to guide other members of the
group to use NS.
3
The report is organized as follows. In Section 2 we give an overview of the
Network Simulator, NS (version 2). We provide information on the different
simulated objects, like event schedulers, nodes, agents, links etc., and
describe how to configure and run the simulator under different scenarios.
We also provide information on mobile networking in NS, giving an
overview of the mobile node with its protocol stack.
In Section 3, we put forth the design and implementation of the experiments
conducted in the Physical, Data link and Network layers. Results and
analysis of the conducted experiments are also included.
In Section 4, we extend NS to incorporate a management layer in the
protocol stack of each node. We then describe the working of this layer, by
showing how it changes the transmit power in the Physical layer based on
the packet drops in the Mac layer. Finally, we present concluding remarks
and future work in Section 5.
4
2 NETWORK SIMULATOR
2.1 INTRODUCTION
NS (version 2) is an object-oriented, discrete event driven network simulator
developed at UC Berkeley written in C++ and OTcl. NS is primarily useful
for simulating local and wide area networks. It implements network
protocols such as TCP and UPD, traffic source behavior such as FTP, Telnet
and CBR, router queue management mechanism such as Drop Tail, RED
and CBQ, routing algorithms such as AODV, DSR, and more. NS also
implements multicasting and some of the MAC layer protocols for LAN
simulations. The purpose of this section is to give some basic idea of how
the simulator works and how to setup a simulation network.
2.2 GENERAL STRUCTURE AND ARCHITECTURE OF NS
NS is a discrete event simulator written in C++, with an OTcl interpreter as a
front-end. The simulator supports a class hierarchy in C++ (we also call it
the compiled hierarchy), and a similar class hierarchy within the OTcl
interpreter (we also call it the interpreted hierarchy). The two hierarchies are
closely related to each other. From the user's perspective, there is a one-toone correspondence between a class in the interpreted hierarchy and one in
the compiled hierarchy. The root of this hierarchy is the class TclObject.
Users create new simulator objects through the interpreter; these objects are
instantiated within the interpreter, and are closely mirrored by a
corresponding object in the compiled hierarchy. The interpreted class
5
hierarchy is automatically established through methods defined in the class
TclClass. User instantiated objects are mirrored through methods defined in
the class TclObject.
Figure 2: C++/OTcl Duality
NS uses two languages because the simulator has two different kinds of
things it needs to do. On the one hand, detailed simulations of protocols
require a systems programming language which can efficiently manipulate
bytes, packet headers, and implement algorithms that run over large data
sets. For these tasks, the run-time speed is important and the turn-around
time 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, the iteration time is more important.
Since configuration runs once (at the beginning of the simulation), the runtime of this part of the task is less important. 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.
When a simulation is finished, NS produces one or more text-based output
files that contain detailed simulation data, if specified to do so in the input
6
OTcl script. The data can be used for simulation analysis or as an input to a
graphical simulation display tool called Network Animator (NAM) . NAM
has a nice graphical user interface that can graphically present information
such as throughput and number of packet drops at each link, although the
graphical information cannot be used for accurate simulation analysis.
Figure 3: Simplified View of NS
7
We now briefly examine what information is stored in which directory or
file in ns-2.
Figure 4: Directory Structure of NS
Among the sub-directories of ns-allinone-2.27, ns-2 is the place that has all
of the simulator implementations (either in C++ or in OTcl), validation test
OTcl scripts and example OTcl scripts. Within this directory, all OTcl codes
located under a sub-directory called tcl, and most of C++ code, which
implements event scheduler and basic network component object classes are
located in the main level.
8
2.3 SAMPLE SIMULATION SCRIPT
We now present a simple simulation script and explain what each line
means. Consider the following network topology of Figure 4.
cbr
null
udp
Figure 5: Scenario for a simple Simulation Script
We have two nodes; n0 and n1.The duplex link between n0 and n1 has 2
Mbps of bandwidth and 10 ms of delay. Each node uses a DropTail queue,
of which the maximum size is 10. A "udp" agent that is attached to n0 is
connected to a "null" agent attached to n1. A "null" agent just frees the
packets received. A "cbr" traffic generator is attached to the "udp" agent, and
the "cbr" is configured to generate a 500 byte packet every 1 second. The
"cbr" is set to start at 0.5 second and stop at 4.5 second.
9
A simple NS simulation tcl script
# Create simulator object
set ns [new Simulator]
# Open the NAM trace file
set nf [open out.nam w]
$ns namtrace-all $nf
#Define a finish procedure
proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}
#Create 2 nodes
set n0 [$ns node]
set n1 [$ns node]
#Create link between the nodes
$ns duplex-link $n0 $n1 1Mb 10ms DropTail
#Setup a UDP agent and attach it to node n0
set udp0 [new Agent/UDP]
$ns attach-agent $n0 $udp0
set null0 [new Agent/Null]
$ns attach-agent $n1 $null0
$ns connect $udp0 $null0
#Setup a CBR over UDP connection
set cbr0 [new Application/Traffic/CBR]
$cbr0 set packetSize_ 500
$cbr0 set interval_ 1.0
$cbr0 attach-agent $udp0
#Schedule events for CBR agent
$ns at 0.5 "$cbr0 start"
$ns at 4.5 "$cbr0 stop"
#Call finish procedure after 5 seconds of simulation time
$ns at 5.0 "finish"
#Run the simulation
$ns run
10
The following is the explanation of the script above.
o set ns [new Simulator] generates a new NS simulator object
instance, and assigns it to a variable ns. This line creates an event
scheduler for the simulation, initializes the packet format and
selects the default address format.
o $ns namtrace-all nf tells the simulator to record simulation traces
in NAM input format. nf is the file name that the trace will be
written to later by the command $ns flush-trace.
o proc finish {} closes the trace file and starts nam.
o set n0 [$ns node] creates a node. A node in NS is compound object
made of address and port classifiers (described in a later section).
o $ns duplex-link node1 node2 bandwidth delay queue-type creates
two simplex links of specified bandwidth and delay, and connects
the two specified nodes.
o set udp [new Agent/UDP] creates a udp agent. Users can create
any agent or traffic sources in this way.
o $ns attach-agent node agent attaches an agent object created to a
node object.
11
o $ns connect agent1 agent2 connects the two agents specified.
After two agents that will communicate with each other are
created, the next thing is to establish a logical network connection
between them. This line establishes a network connection by
setting the destination address to each others' network and port
address pair.
o $ns at 4.5 “$cbr start” tells the CBR agent when to start sending
data.
o $ns at 0.5 “$cbr stop” tells the CBR agent when to stop sending
data.
o $ns at 5.0 “finish” tells the simulator object to execute the 'finish'
procedure after 5.0 seconds of simulation time
o $ns run starts the simulation.
12
2.4. SIMULATOR BASICS
2.4.1 Event Scheduler
NS is an event driven simulator. There are presently four schedulers
available in the simulator, each of which is implemented using a different
data structure: a simple linked-list, heap, calendar queue (default), and a
special type called ``real-time''. The real-time scheduler is for emulation,
which allows the simulator to interact with a real network. Currently,
emulation is under development although an experimental version is
available. Event schedulers are used to schedule events such as when to start
a cbr agent, when to send /receive/drop a packet, etc. They are also used to
simulate delay.
Event schedulers run by selecting the next earliest event, executing it to
completion (by invoking appropriate network components and letting them
do the appropriate action associated with the event), and returning to execute
the next event. The simulator is single-threaded, and there is only one event
in execution at any given time.
13
Figure 6: Event Scheduler
2.4.2 Basic Node
A node is a compound object. It is composed of a node entry object and
classifiers. There are two types of nodes in NS. A unicast node has an
address classifier that does unicast routing and a port classifier (agents are
attached to ports). A multicast node, in addition, has a classifier that classify
multicast packets from unicast packets and a multicast classifier that
performs multicast routing.
14
Figure 7: Basic Structure of Node in NS
2.4.3 Link
Link is a compound object in NS. It connects two nodes. We can create both
simplex and duplex links in NS. A duplex link is nothing but two simplex
links in both directions.
Figure 8: Simplex Link
When a node wants to send a packet through a link, it puts the packet on the
Queue object of the link. Packets de-queued from the queue object are
15
passed to the delay object. The delay object simulates link delay. Sending a
packet to a null agent from the queue object simulates the dropping of the
packet. The TTL object calculates the time to live of each packet received
and updates the TTL field of the packet.
2.4.4 Packet
Packets are the fundamental units of exchange between objects. A packet is
composed of a stack of headers and an optional data space.
Figure 9: Packet Structure
Each header within the stack corresponds to a particular layer. In addition,
there is a common header which can be accessed by all the layers, and a
trace header which contains information for trace support. New protocols
may define their own packet headers or may extend existing headers with
additional fields.
16
2.4.5 Agent
Agents are used in the implementation of protocols at various layers. They
represent endpoints where network-layer packets are constructed or
consumed. The table below gives the list of the different agents currently
supported by NS at the transport layer. NS also has routing agents
implementing the different routing protocols like DSDV, TORA, AODV and
DSR. There routing protocols will be discussed in a later section.
List of Agents supported by NS
TCP
a Tahoe TCP sender (cwnd = 1 on any
loss)
TCP/Reno
a Reno TCP sender (with fast recovery)
TCP/Newreno
a modified Reno TCP sender (changes
fast recovery)
TCP/Sack1
a SACK TCP sender
TCP/Fack
a forward SACK sender TCP
TCP/FullTcp
a more full-functioned TCP with 2-way
traffic
TCP/Vegas
a Vegas TCP sender
TCP/Vegas/RBP
a Vegas TCP with .rate based pacing
TCP/Vegas/RBP
a Reno TCP with .rate based pacing
TCP/Asym
an
experimental
Tahoe
TCP
for
Reno
TCP
for
asymmetric links
TCP/Reno/Asym
an
experimental
17
asymmetric links
TCP/Newreno/Asym
an
experimental
Newreno
TCP
for
asymmetric links
TCPSink
a Reno or Tahoe TCP receiver (not used
for FullTcp)
TCPSink/DelAck
a TCP delayed-ACK receiver
TCPSink/Asym
an experimental TCP sink for asymmetric
links
TCPSink/Sack1
a SACK TCP receiver
TCPSink/Sack1/DelAck a delayed-ACK SACK TCP receiver
UDP
a basic UDP agent
RTP
an RTP sender and receiver
RTCP
an RTCP sender and receiver
LossMonitor
a packet sink which checks for losses
IVS/Source
an IVS source
IVS/Receiver
an IVS receiver
CtrMcast/Encap
a centralised multicast encapsulator
CtrMcast/Decap
a centralised multicast de-encapsulator
Message
a protocol to carry textual messages
Message/Prune
processes
multicast
routing
prune
messages
SRM
an SRM agent with non-adaptive timers
SRM/Adaptive
an SRM agent with adaptive timers
Tap
interfaces the simulator to a live network
Null
a degenerate agent which discards packets
rtProto/DV
distance-vector routing protocol agent
18
All agents are derived from the C++ Agent class. The following member
functions are implemented by the C++ Agent class, and are generally not
over-ridden by derived classes:
[]Packet* allocpkt allocate new packet and assign its fields
[int]Packet*
allocate new packet with a data payload of n bytes and
allocpkt
assign its fields
The following member functions are also defined by the class Agent, but are
intended to be over-ridden by classes deriving from Agent:
[timeout number]void timeout
subclass-specific time out method
[Packet*, Handler*]void recv
receiving agent main receive path
The allocpkt method is used by derived classes to create packets to send.
The recv method is the main entry point for an Agent which receives
packets, and is invoked by upstream nodes when sending a packet. The
timeout method is used to periodically send request packets.
2.4.5.1 Adding a new Agent to NS simulator
NS allows users to extend the existing protocol stack by adding their own
agents. We show how this can be done by adding a simple agent - MyAgent
to NS. We create a new network object class in C++, “MyAgent”, derived
from the “Agent” class. To make it possible to create an instance of this
19
object in OTcl, we define a linkage object, say “MyAgentClass”, derived
from “TclClass” which creates an OTcl object of specified name
“Agent/MyAgentOtcl”.
Example C++ Network Component and Linkage object
When NS is first started, it creates an instance of “MyAgentClass”. In this
process, the “Agent/MyAgentOtcl” class and its appropriate methods are
created in OTcl space. Whenever a user in OTcl space tries to create an
instance of this object using the command “new Agent/MyAgentOtcl”, it
invokes “MyAgentClass::create” that creates an instance of “MyAgent” and
returns the address.
We can access the member variables of the C++ object, “MyAgent” from
the OTcl input script. To do this we use a binding function for each of the
C++ class variables we want to export. A binding function takes two
20
arguments. It creates a new member variable of the first argument in the
matching OTcl object class ("Agent/MyAgentOtcl"), and creates bidirectonal bindings between the OTcl class variable and the C++ variable
whose address is specified as the second variable. Suppose "MyAgent", has
two parameter variables, say "my_var1" and "my_var2",that we want to
access from OTcl using the input simulation script. The bindings for
"my_var1" and "my_var2" are shown below. The binding functions are
placed in the "MyAgent" constructor function to establish the bindings when
an instance of this object is created.
Variable binding creation example
We then define a “command” member function of the C++ object
("MyAgent"). This function works as an OTcl command interpreter. An
OTcl command defined in a "command" member function of a C++ object
looks the same as a member function of the matching OTcl object to a user.
When the user tries to call a member function of an OTcl object, OTcl
searches for the given member function name in that OTcl object. If the
given member function name cannot be found, then it invokes the
“MyAgent::command” passing the invoked OTcl member function name
and arguments in argc/argv format. If there is an action defined for the
invoked OTcl member function name in the "command" member function, it
carries out what is asked and returns the result. If not, the "command"
function for its ancestor object is recursively called until the name is found.
21
If the name cannot be found in any of the ancestors, an error message is
return to the OTcl object, and the OTcl object gives an error message to the
user. In this way, a user in OTcl space can control a C++ object's behavior.
Example OTcl command interpreter
2.4.6 Application
Applications sit on top of transport agents such as UDP and TCP. There are
two basic types of applications: traffic generators and simulated
applications.
NS supports four types of traffic generators.
o EXPOO_Traffic – Generates traffic according to an Exponential
On/Off distribution. Packets are of constant size and are sent at a fixed
rate during on periods, and no packets are sent during off periods.
Both on and off periods are taken from an exponential distribution.
o POO_Traffic -- Generates traffic according to a Pareto On/Off
distribution. The on and off periods are taken from a pareto
distribution. These sources can be used to generate aggregate traffic
that exhibits long range dependency.
22
o CBR_Traffic -- Generates traffic according to a deterministic rate.
Packets are constant size. Optionally, some randomizing dither can be
enabled on the interpacket departure intervals.
o TrafficTrace -- Generates traffic according to a trace file.
There are two simulated applications FTP and Telnet. FTP simulates bulk
data transfer.
2.5 MOBILE NETWORKING
The wireless model essentially consists of the MobileNode at the core, with
additional supporting features. It is derived from the basic Node class. It is
the basic Node object with added mobility features like node movement,
periodic position updates, maintaining topology boundary etc.
2.5.1 Mobile Node
MobileNode is a split object. In addition to the basic node model, it consists
of a network stack. The network stack for a mobile node consists of a link
layer (LL), an ARP module connected to LL, an interface priority queue
(IFq), a mac layer(MAC), a network interface (netIF), all connected to a
common wireless channel. These network components are created and
plumbed together in OTcl. A packet sent down the stack flows through the
link layer (and ARP),the Interface queue, the MAC layer, and the physical
layer. At the receiving node, the packet then makes its way up the stack
through the Mac, and the LL.
23
Node
port
classifier
protocol
agent
Classifier: Forwarding
255
addr
classifier defaulttarget_
LL
Agent: Protocol Entity
routing
agent
Node Entry
ARP
LL
LL: Link layer object
IFQ
IFQ: Interface queue
MAC
MAC: Mac object
PHY
PHY: Net interface
IFQ
MAC
PHY
MobileNode
Propagation
and antenna
models
CHANNEL
Prop/ant
Radio propagation/
antenna models
Figure 10: Mobile Node
Each component is briefly described here.
o Link Layer
The link layer can potentially have many functionalities such as queuing
and link-level retransmission. The LL object implements a particular data
link protocol, such as ARQ. By combining both the sending and
receiving functionalities into one module, the LL object can also support
other mechanisms such as piggybacking.
The link layer for mobile node has an ARP module connected to it which
resolves all IP to hardware (Mac) address conversions. Normally for all
24
outgoing (into the channel) packets, the packets are handed down to the
LL by the Routing Agent. The LL hands down packets to the interface
queue. For all incoming packets (out of the channel), the mac layer hands
up packets to the LL which is then handed off at the node_entry_ point.
o ARP
The Address Resolution Protocol (implemented in BSD style) module
receives queries from Link layer. If ARP has the hardware address for
destination, it writes it into the mac header of the packet. Otherwise it
broadcasts an ARP query, and caches the packet temporarily. For each
unknown destination hardware address, there is a buffer for a single
packet. Incase additional packets to the same destination is sent to ARP,
the earlier buffered packet is dropped. Once the hardware address of a
packet's next hop is known, the packet is inserted into the interface
queue.
o Interface Queue
The Interface queue is implemented as a priority queue, which gives
priority to routing protocol packets, inserting them at the head of the
queue. It supports running a filter over all packets in the queue and
removes those with a specified destination address.
o Mac Layer
Depending on the type of physical layer, the MAC layer must contain a
certain set of functionalities such as: carrier sense, collision detection,
collision avoidance, etc. Since these functionalities affect both the
sending and receiving sides, they are implemented in a single Mac object.
25
For sending, the Mac object must follow a certain medium access
protocol before transmitting the packet on the channel. For receiving, the
MAC layer is responsible for delivering the packet to the link layer.
The IEEE 802.11 distributed coordination function (DCF) Mac protocol
has been implemented by CMU. It uses a RTS/CTS/DATA/ACK pattern
for all unicast packets and simply sends out DATA for all broadcast
packets. The implementation uses both physical and virtual carrier sense.
o Network Interfaces (Physical layer)
The Network Interface layer serves as a hardware interface which is used
by mobile node to access the channel. This interface subject to collisions
and the radio propagation model receives packets transmitted by other
node interfaces to the channel. The interface stamps each transmitted
packet with the meta-data related to the transmitting interface like the
transmission power, wavelength etc. This meta-data in packet header is
used by the propagation model in receiving network interface to
determine if the packet has minimum power to be received and/or
captured and/or detected (carrier sense) by the receiving node. The
Network interface in NS approximates the DSSS radio interface (Lucent
WaveLan direct-sequence spread-spectrum).
o Radio Propagation Model
These models are used to predict the received signal power of each
packet. At the physical layer of each wireless node, there is a receiving
threshold. When a packet is received, if its signal power is below the
receiving threshold, it is marked as error and dropped by the MAC layer.
26
NS supports the free space model (at near distances), two-ray ground
reflection model (at far distances) and the shadowing model (includes
fading)
o Antenna
An omni-directional antenna having unity gain is used by mobile nodes.
The following API configures for a mobile node with all the given values of
adhoc-routing protocol, network stack, channel, topography, propagation
model, with wired routing turned on or off (required for wired-cum-wireless
scenarios) and tracing turned on or off at different levels (router, mac,
agent).
$ns_ node-config -adhocRouting $opt(adhocRouting) # dsdv/dsr/aodv/tora
-llType $opt(ll) # specifies link layer object
-macType $opt(mac) # specifies mac object
-ifqType $opt(ifq) # specifies ifq object
-ifqLen $opt(ifqlen) # specifies length of ifq
-antType $opt(ant) # specifies antenna object
-propInstance [new $opt(prop)]# propagation object
-phyType $opt(netif) # specifies physical layer object
-channel [new $opt(chan)] # specifies channel object
-topoInstance $topo # specifies topography
-wiredRouting OFF # for wired cum wireless simulations
-agentTrace ON # specifies agent level trace ON/OFF
-routerTrace OFF # specifies router level trace ON/OFF
-macTrace OFF # specifies mac level trace ON/OFF
27
A mobile node is created using the following procedure:
for { set j 0 } { $j \< $opt(nn)} {incr j} {
set node_($j) [ $ns_ node ]
$node_($i) random-motion 0
;#disable random motion
}
This procedure creates a mobile node (split)object, creates an adhoc-routing
routing agent as specified, creates the network stack consisting of a link
layer, interface queue, mac layer, and a network interface with an antenna,
uses the defined propagation model, interconnects these components and
connects the stack to the channel.
2.5.2 Creating Node Movements
The MobileNode is designed to move in a three dimensional topology.
However, the third dimension (Z) is not used. That is the MobileNode is
assumed to move always on a flat terrain with Z always equal to 0. Thus the
MobileNode has X, Y, Z(=0) co-ordinates that is continually adjusted as the
node moves.
We first need to define the topography creating the mobile nodes. Normally
flat topology is created by specifying the length and width of the topography
using the following primitive:
set topo
[new Topography]
$topo load_flatgrid $opt(x) $opt(y)
where opt(x) and opt(y) are the boundaries used in simulation.
28
There are two mechanisms to induce movement in mobile nodes. In the first
method, starting position of the node and its future destinations may be set
explicitly. These directives are normally included in a separate movement
scenario file.
The start-position and future destinations for a mobilenode may be set by
using the following APIs:
$node set X_ \<x1\>
$node set Y_ \<y1\>
$node set Z_ \<z1\>
$ns at $time $node setdest \<x2\> \<y2\> \<speed\>
At $time sec, the node would start moving from its initial position of (x1,y1)
towards a destination (x2,y2) at the defined speed.
In this method the node-movement-updates are triggered whenever the
position of the node at a given time is required to be known. This may be
triggered by a query from a neighboring node seeking to know the distance
between them, or the setdest directive described above that changes the
direction and speed of the node.
The second method employs random movement of the node. The primitive
to be used is:
$mobilenode start
which starts the mobile node with a random position and have routine
updates to change the direction and speed of the node. The destination and
speed values are generated in a random fashion.
29
2.5.3 Routing Agents
All packets destined for the mobile node are routed directly by the address
de-multiplexer to its port de-multiplexer. The port de-multiplexer hands the
packets to the respective destination agents. A port number of 255 is used to
attach routing agent in mobile nodes. The mobile nodes also use a defaulttarget in their classifier (or address de-multiplexer). In the event a target is
not found for the destination in the classifier (which happens when the
destination of the packet is not the mobile node itself), the packets are
handed to the default-target which is the routing agent. The routing agent
assigns the next hop for the packet and sends it down to the link layer.
The four different ad-hoc routing protocols are currently implemented for
mobile networking. They are DSDV, DSR, AODV and TORA.
2.5.3.1 DSDV
In DSDV, routing messages are exchanged between neighboring mobile
nodes. Routing updates may be triggered or routine. Updates are triggered in
case routing information from one of the neighbors forces a change in the
routing table. A packet for which the route to its destination is not known is
cached while routing queries are sent out. The packets are cached until
route-replies are received from the destination. There is a maximum buffer
size for caching the packets waiting for routing information beyond which
packets are dropped.
30
2.5.3.2 DSR
The Dynamic Source routing protocol requires a small modification to the
structure of the mobile node discussed in section 2.5.1. The modified node’s
entry point points to the DSR routing agent, thus forcing all packets
received by the node to be handed down to the routing agent. This model is
required for future implementation of piggy-backed routing information on
data packets which otherwise would not flow through the routing agent.
The DSR agent checks every data packet for source-route information. It
forwards the packet as per the routing information. Incase it does not find
routing information in the packet; it provides the source route, if route is
known, or caches the packet and sends out route queries if route to
destination is not known. Routing queries, always triggered by a data packet
with no route to its destination, are initially broadcast to all neighbors.
Route-replies are send back either by intermediate nodes or the destination
node, to the source, if it can find routing info for the destination in the routequery. It hands over all packets destined to it to the port de-multiplexer. In
this node the port number 255 points to a null agent since the packet has
already been processed by the routing agent.
2.5.3.3 AODV
AODV is a combination of both DSR and DSDV protocols. It has the basic
route-discovery and route-maintenance of DSR and uses the hop-by-hop
routing, sequence numbers and beacons of DSDV. The node that wants to
know a route to a given destination generates a ROUTE REQUEST. The
route request is forwarded by intermediate nodes that also create a reverse
31
route for itself from the destination. When the request reaches a node with
route to destination it generates a ROUTE REPLY containing the number of
hops required to reach the destination. All nodes that participate in
forwarding this reply to the source node create a forward route to
destination. This state, created from each node from source to destination is
a hop-by-hop state and not the entire route as is done in source routing.
2.5.3.4 TORA
TORA is a distributed routing protocol based on "link reversal" algorithm.
At every node a separate copy of TORA is run for every destination. When a
node needs a route to a given destination it broadcasts a QUERY message
containing the address of the destination for which it requires a route. This
packet travels through the network until it reaches the destination or an
intermediate node that has a route to the destination node. This recipient
node then broadcasts an UPDATE packet listing its height with respect to
the destination. As this node propagates through the network each node
updates its height to a value greater than the height of the neighbor from
which it receives the UPDATE. This results in a series of directed links from
the node that originated the QUERY to the destination node. If a node
discovers a particular destination to be unreachable it sets a local maximum
value of height for that destination. Incase the node cannot find any neighbor
having finite height with respect to this destination; it attempts to find a new
route. In case of network partition, the node broadcasts a CLEAR message
that resets all routing states and removes invalid routes from the network.
32
2.6 TRACE SUPPORT
In order to obtain results from simulations, we need to know what exactly
happens during a simulation run. NS realizes this by generation of event logs
that can be analyzed offline, after a simulation. These event log files
however, contain only events of packets being sent, received or dropped, so
called Packet Traces. NS does not support the logging of more abstract
events, i.e. related to connection establishment.
We now give an overview of the new wireless trace format generated by NS
simulations.
Sample Wireless Trace file
s -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.255 -Id -1.255
–It message -Il 32 -If 0 -Ii 0 -Iv 32
s -t 1.511681090 -Hs 1 -Hd -1 -Ni 1 -Nx 390.00 -Ny 385.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.255 -Id -1.255
–It message -Il 32 -If 0 -Ii 1 -Iv 32
s -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It
tcp -Il 1000 –If 2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0
r -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It
tcp -Il 1000 –If 2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0
r -t 100.004776054 -Hs 1 -Hd 1 -Ni 1 -Nx 25.05 -Ny 20.05 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma a2 -Md 1 -Ms 0 -Mt 800 -Is 0.0 -Id 1.0 –
It tcp -Il 1020 -If 2 -Ii 21 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 1 -Po 0
33
The new trace format as seen above can be can be divided into the following
fields:
Event type: In the traces above, the first field describes the type of event
taking place at the node and can be one of the four types:
s send
r receive
d drop
f forward
General tag: The second field starting with "-t" may stand for time or global
setting
-t time
-t * (global setting)
Node property tags: This field denotes the node properties like node-id, the
level at which tracing is being done like agent, router or MAC. The tags start
with a leading "-N" and are listed as below:
-Ni: node id
-Nx: node's x-coordinate
-Ny: node's y-coordinate
-Nz: node's z-coordinate
-Ne: node energy level
-Nl: trace level, such as AGT, RTR, MAC
-Nw: reason for the event. The different reasons for dropping a packet
are given below:
34
"END" DROP_END_OF_SIMULATION
"COL" DROP_MAC_COLLISION
"DUP" DROP_MAC_DUPLICATE
"ERR" DROP_MAC_PACKET_ERROR
"RET" DROP_MAC_RETRY_COUNT_EXCEEDED
"STA" DROP_MAC_INVALID_STATE
"BSY" DROP_MAC_BUSY
"NRTE” DROP_RTR_NO_ROUTE i.e no route is available.
"LOOP" DROP_RTR_ROUTE_LOOP i.e there is a routing
loop
"TTL" DROP_RTR_TTL i.e TTL has reached zero.
"TOUT" DROP_RTR_QTIMEOUT i.e packet has expired.
"CBK" DROP_RTR_MAC_CALLBACK
"IFQ" DROP_IFQ_QFULL i.e no buffer space in IFQ.
"ARP" DROP_IFQ_ARP_FULL i.e dropped by ARP
"OUT" DROP_OUTSIDE_SUBNET i.e dropped by base
stations on receiving routing updates from nodes outside its
domain.
Packet information at IP level: The tags for this field start with a leading
"-I" and are listed along with their explanations as following:
-Is: source address.source port number
-Id: dest address.dest port number
-It: packet type
-Il: packet size
-If: flow id
-Ii: unique id
35
-Iv: ttl value
Next hop info: This field provides next hop info and the tag starts with a
leading "-H".
-Hs: id for this node
-Hd: id for next hop towards the destination.
Packet info at MAC level: This field gives MAC layer information and
starts with a leading "-M" as shown below:
-Ma: duration
-Md: dst's ethernet address
-Ms: src's ethernet address
-Mt: ethernet type
Packet info at Application level: The packet information at application
level consists of the type of application like ARP, TCP, the type of ad-hoc
routing protocol like DSDV, DSR, AODV etc being traced. This field
consists of a leading "-P" and list of tags for different application is listed as
below:
-P arp: Address Resolution Protocol. Details for ARP are given by
these tags:
-Po: ARP Request/Reply
-Pm: src mac address
-Ps: src address
-Pa: dst mac address
-Pd: dst address
36
-P dsr: This denotes the adhoc routing protocol called Dynamic
source routing. Information on DSR is represented by the following
tags:
-Pn: Number of nodes traversed
-Pq: routing request flag
-Pi: route request sequence number
-Pp: routing reply flag
-Pl: reply length
-Pe: src of srcrouting->dst of the source routing
-Pw: error report flag
-Pm: number of errors
-Pc: report to whom
-Pb: link error from linka->linkb
-P cbr : Constant bit rate. Information about the CBR application is
represented by the following tags:
-Pi: sequence number
-Pf: how many times this pkt was forwarded
-Po: optimal number of forwards
-P tcp: Information about TCP flow is given by the following
subtags:
-Ps: seq number
-Pa: ack number
-Pf: how many times this pkt was forwarded
-Po: optimal number of forwards
37
We use these trace file to calculate measures such as throughput, end-to-end
delay, packet drop ratio etc.
We have given a concise description of the NS simulator. We now proceed
to explain the experiments we conducted, using NS, to develop configurable
protocols in programmable radio networks.
38
3 EXPERIMENTS TO DEVELOP CONFIGURABLE
PROTOCOLS
The most important step towards developing configurable protocols is to
identify programmable parameters in the protocols. We looked at the
Physical, Mac and Network layer implementation in NS (version 2) and
identified configurable parameters. We then observed their effect on the
application QoS parameters. These experiments helped us configure the
protocols in the best possible state for a given context.
3.1 PHYSICAL LAYER
One of the most important characteristics of the propagation environment is
the path (propagation) loss. Because of the separation between the receiver
and the transmitter, attenuation of the signal strength occurs. An accurate
estimation of the propagation losses provides a good basis for a proper
selection of base station locations and a proper determination of the
frequency plan. By knowing propagation losses, one can efficiently
determine
the
field
signal
strength,
signal-to-noise
ratio
etc.
When a node receives a packet, the physical layer sends it to the radio
propagation model. The radio propagation model predicts the received
power of the packet based on parameters such as distance between the
source and destination, the transmit power of the packet and the antenna gain
and height, and returns the packet to the physical layer with the calculated
received power. At the physical layer of each wireless node, there is a
39
receiving threshold. If the received power is below the receiving threshold,
the packet is marked as error and dropped by the MAC layer.
In addition to this path loss component, we must also take into account the
small scale fading suffered by the packet. Small scale fading is caused by
movement of the transmitter, receiver, or of other objects in the
environment. The current implementation of NS does not take into account
this small scale fading while prediction received signal power. The small
scale fading can be calculated by Rayleigh or Ricean fading models. We
incorporated these fading models into the physical layer of NS. We then
compared the packet delivery ratio of the Two-Ray Ground and Free Space
propagation models with these fading models.
[3] was used as a reference while conducting our experiments in the Physical
layer. [3] incorporated Rayleigh and Ricean fading models in NS and
compared the packet delivery ratio of the Two-Ray Ground and Free Space
propagation models with those fading models. We gave our own
implementation of the Rayleigh and Ricean fading models. We then
conducted the same experiments and checked to see if the results from our
models were consistent with the ones given in [3].
Implementation of Rayleigh and Ricean Fading Models
We approximated the effects of fading using random number generation
with the appropriate statistical behavior. For generating a Ricean random
variable with second moment equal to unity, we generated 2 independent
Gaussian random variables with mean 0.5 and variance 0.25. We then
40
squared each variable and added them. The resulting random variable was
non-central chi-square whose square root resulted in a Ricean random
variable. For generating a Rayleigh random variable, we repeated the above
procedure with mean 0 and variance 0.5. We incorporated these fading
models in the sendUp() function of the wireless physical layer (wirelessphy.cc).
Rayleigh and Ricean model incorporated in NS (wireless-phy.cc)
if(propagation_) {
s.stamp((MobileNode*)node(), ant_, 0, lambda_);
Pr = propagation_->Pr(&p->txinfo_, &s, this);
/************************************************************/
//this piece of code is for Rayleigh calculation
//comment out when using ricean
x1 = rand_->normal(0,0.7071);
x2 = rand_->normal(0,0.7071);
ray = (x1*x1)+(x2*x2); // rayleigh random variable
Pr = Pr * ray;
/********************************************************/
//this piece of code is for Ricean calculation
//comment out when using rayleigh
x1 = rand_->normal(0.5,0.5);
x2 = rand_->normal(0.5,0.5);
rice = (x1*x1)+(x2*x2); // ricean random variable
Pr = Pr * rice;
/********************************************************/
41
EXPERIMENT 1: Comparison of Two-Ray Ground and Free Space
propagation with Rayleigh and Ricean fading in terms of Packet
Delivery Ratio
We conducted the following set of experiments for a wireless network with
the Free Space propagation model. We then repeated the same set of
experiments, for the same wireless network, with the Two-Ray Ground
propagation model. In each case, the set of experiments consisted of a
simulation run with Rayleigh fading model, a run with Ricean fading model,
and a run with no fading model.
MOVEMENT MODEL:
For our experiments, we considered a fixed scenario of 100 nodes, moving
with a maximum speed of 20m/s, with a pause time of 100s, within a
topology boundary of 1200 x 1200, for a simulation time of 30s. We
specified this scenario in a separate scenario file, scene-100. We generated
this scenario file by typing the following command in ns-2.27/indeputils/cmugen/setdest directory:
./setdest –n 100 –p 100.0 –M 20.0 –t 30 –x 1200 –y 1200 > scene-100
COMMUNICATION MODEL:
We gave the nodes 40 cbr connections, with a packet generation rate of 4
pkts/s. We specified this connection pattern in a separate pattern file cbr100-40 by typing the following command in ns-2.27/indep-utils/cmugen
directory:
ns cbrgen.tcl –type cbr –nn 50 –seed 1.0 –mc 10 –rate 4 > cbr-100-40
42
Using the scenario and communication models defined above, we ran the tcl
script, propagation.tcl (given in Appendix(A)), thrice for the Free Space
propagation model and thrice for the Two-Ray Ground propagation model,
changing the fading model from Rayleigh to Ricean to none each time. We
ran all the simulations with the DSR routing protocol.
SIMULATION RESULTS:
The results obtained for simulations conducted with the Free Space
propagation model are shown in Figure 10.
FREE-SPACE PROPAGATION MODEL
1.2
1
0.98
Packet Delivery Ratio
0.8
0.6
0.448
0.44
0.4
0.2
0
1
none
2
ricean
3
rayleigh
Figure 11: Free-Space vs. Packet Delivery Ratio
43
The results obtained for simulations conducted with the Two Ray Ground
propagation model are shown in Figure 11.
TWO-RAY GORUND PROPAGATION MODEL
0.43
0.425
0.424
0.42
Packt Delivery Ratio
0.415
0.41
0.405
0.402
0.4
0.395
0.395
0.39
0.385
0.38
none
ricean
rayleigh
Figure 12: Two-Ray Ground vs. Packet Delivery Ratio
INTERPRETATION OF RESULTS:
From the simulation results above, we observe that the PDR values decrease,
as the fading models become more extreme from no fading to Rayleigh
fading for both the propagation models. The Free Space Model is considered
to be an idealized propagation model. With this path loss model, even nodes
far from the transmitter can receive packets, which can result in fewer hops
to reach the final destination. Therefore, simulation results with the free
space path loss model tend to be better than with other path loss models.
44
But, it would be incorrect to assume that the Free Space propagation model
is superior to the Two-Ray Ground model. A single line-of-sight path
between two mobile nodes is seldom the only means of propagation. The
two-ray ground reflection model considers both the direct path and a ground
reflection path. The Two-Ray Ground model takes the obstacles between
the communication paths into account and so, is more realistic.
3.2 DATA LINK LAYER
Slot time is the time it takes for a packet to travel the maximum theoretical
distance between two nodes in a network. Collision detection protocols
always wait for a minimum of slot time before transmitting; allowing any
packet that was sent over the channel during the time the waiting node was
requested to send, to reach the waiting node. By allowing the packet to reach
the waiting node, a local collision occurs, rather than a late one. By having
the collision occur locally (near the node), the data link protocol can take
more control over the situation.
If the slot time were less it would mean that the nodes waiting to send a
packet would wait for a small time before transmission. If the slot time were
set to a large value, it would mean that they would have to wait for a longer
period of time. From this we can conclude that smaller slot time would mean
more collisions and longer slot time would mean lesser collisions. Setting
the slot time to an optimum value is important. While we would not want to
set it to a value too small, we would also not want to set it to a value bigger
45
than necessary. That would mean that the nodes would have to wait for an
unnecessarily long period of time.
More collisions would mean more retransmissions and hence delay in the
packet reaching its destination. So, noting the delay in packet reception for
different slot times would help us in understanding the consequences of
switching from one slot time to another. For a given network scenario, we
varied the slot time of the Mac layer protocol and observed its effects on the
delay in packet reception. NS implements two MAC layer protocols for
mobile networking- Mac802.11 and preamble based TDMA protocol. We
used the Mac802.11 protocol while conducting our experiments, as it is a
contention-based protocol. Also, the preamble based TDMA protocol is still
in its preliminary stages of development.
EXPERIMENT 2: Effect of Varying Slot time on End-to-End Delay
We now give a description of the experiment we conducted. The default
value of slot time for Mac802.11 is set to 20us (defined in ns-default.tcl).
We varied the slot time by changing this value to 10us, 12us, 15us and 20us,
and calculated the average end-to-end delay in packet reception.
MOVEMENT MODEL:
For our experiment, we considered a fixed scenario of 100 nodes, moving
with a maximum speed of 10m/s, with a pause time of 4s, within a topology
boundary of 500 x 500, for a simulation time of 30s. We specified this
scenario in a separate scenario file, scene-exp1-100. We generated this
46
scenario file by typing the following command in ns-2.27/indeputils/cmugen/setdest directory:
./setdest –n 100 –p 4.0 – 10.0 –t 30 –x 500 –y 500 > scene-exp1-100
COMMUNICATION MODEL:
We gave the nodes 40 cbr connections, with a packet generation rate of 2.66.
We specified this connection pattern in a separate pattern file exp1-cbr-10040-2.66 by typing the following command in ns-2.27/indep-utils/cmugen
directory:
ns cbrgen.tcl –type cbr –nn 100 –seed 0.0 –mc 40 –rate 2.66>exp1-cbr-10040-2.66
SIMULATION RESULTS:
Using the above scenario and communication models, we ran the tcl script,
slottime.tcl (given in Appendix (B)), for slot time values of 10us, 12us, 15us
and 20us and noted the average delay in packet reception for each case. We
ran all the simulations with the DSR routing protocol.
47
Slotim e vs end-to-end delay
0.014
0.012
0.01186
avg-delay s
0.01
0.00821
0.008
100 nodes, 40 connections
0.00625
0.006
0.005
0.004
0.002
0
20
15
12
10
slot-tim e
Figure 13: Slot-time vs. End-to-end Delay
INTERPRETATION OF RESULTS:
The obtained results are consistent with our initial expectations that the
delay in packet reception increases when the slot time decreases. The plot in
the graph above is a smooth and continuous curve, indicating that there is a
steady increase in average delay in packet reception as the slot time is
reduced. We do not find any unique slot time such that there is a sharp
increase in delay once we go below that value.
48
3.3 NETWORK LAYER
At the Network layer, we identified configurable parameters for the
Dynamic Source Routing (DSR) protocol. DSR performs two actions while
routing packets to their correct destination, namely, route discovery and
route maintenance. In route discovery, a source node that has a packet to
send to another destination node, tries to find a route to that destination
node. As for the route maintenance, when a route is found to be not valid
any more (i.e. a broken link is discovered), DSR then, allows the
intermediate node that discovered the link breakage to salvage the packet at
hand, and at the same time, inform the source about the link breakage. The
sender then, tries to find another route from its cache. In case the sender
does not have a cache entry for this target, it starts a new route discovery.
The above insight helps us realize that cache size, speed of nodes and
timeout intervals (at the buffers holding packets) are important parameters in
the working of DSR.
EXPERTIMENT 3: Effect of varying cache size, speed and timeout
interval on Packet Delivery Ratio
We conducted experiments varying the cache size, timeout interval of the
send buffer and speed of nodes in the network and observed the effect of
changing their values on packet delivery ratio. We calculated packet delivery
ratio as: data packets received / data packets sent.
49
MOVEMENT MODEL:
For our experiments, we considered a fixed scenario of 50 nodes, moving
with a maximum speed of 20m/s, with a pause time of 2s, within a topology
boundary of 1200 x 1200, for a simulation time of 10s. We specified this
scenario in a separate scenario file, scene-50-1200. We generated this
scenario file by typing the following command in ns-2.27/indeputils/cmugen/setdest directory:
./setdest –n 50 –p 2.0 –M 20.0 –t 10 –x 1200 –y 1200 > scene-50-1200
COMMUNICATION MODEL:
We gave the nodes 10 cbr connections, with a packet generation rate of 4
pkts/s. We specified this connection pattern in a separate pattern file cbr-5010-4 by typing the following command in ns-2.27/indep-utils/cmugen
directory:
ns cbrgen.tcl –type cbr –nn 50 –seed 0.0 –mc 10 –rate 4 > cbr-50-10-4
EXPERIMENT 3.1 Cache size vs. Packet delivery ratio
In DSR, the cache implementation of the nodes is divided into two parts:
primary and secondary. Generally, DSR node uses the primary cache for
active routes that are being used to send data and it leaves old routes that are
not used in the secondary cache.
Using the scenario and communication models defined above, we varied the
size of the primary and secondary caches defined in dsr/mobicache.cc and
50
observed its effect on packet delivery ratio. We used the tcl script,
network.tcl (given in Appendix (C)), in our simulations.
SIMULATION RESULTS:
Cache Size Vs. Packet delivery
0.8
0.7
0.7162
0.70134
recieved/sent packet ratio
0.6529
0.6
0.5065
0.5
0.4
50nodes-10connections
0.3
0.2
0.1
0
p30-s31
p10-s11
p3-s4
p1-s2
Primary(p) & Secondary(s) cache size
Figure 14: Cache Size vs. Packet Delivery Ratio
INTERPRETATION OF RESULTS:
The obtained results indicate that the packet delivery ratio decreases as the
cache size decreases. The plot indicates that there is not much change in the
packet delivery ratio for cache sizes of 10 and above. When the primary
cache size goes below 10, we see a considerable decrease in the packet
delivery ratio. This experiment shows that if we want to reduce the cache
size in the nodes, we should probably not reduce it below 10 as that would
affect the performance of the network.
51
EXPERIMENT 3.2: Speed vs. Packet Delivery Ratio
When the speed increases, routes to the nodes become outdated as they
change their position very quickly. The cache entries become stale, and this
affects packet delivery ratio. Using the scenario and communication models
defined above, we varied the speed of the nodes and observed its effect on
packet delivery ratio. We used the tcl script, network.tcl (given in
Appendix(C)), in our simulations, changing the scenario file to reflect
different speeds each time.
SIMULATION RESULTS:
Speed vs packet delivery
0.92
0.90476
0.9
0.88
packet delivery ratio
0.86
0.84
50nodes,10connections
0.82
0.81099
0.8
0.79016
0.78
0.76
0.74
0.72
15
20
30
Speed
Figure 15: Speed vs. Packet Delivery Ratio
52
INTERPRETATION OF RESULTS:
The obtained results indicate that the packet delivery ratio decreases as the
speed size decreases. The plot in the graph is uniform indicating a steady
decrease in packet delivery ratio as the speed is increased. We do not find
any unique speed such that there is a sharp increase in packet delivery ratio
once we go above that value.
EXPERIMENT 3.3: Timeout Interval of Send-buffer vs. Packet
Delivery Ratio
During the route discovery the node keeps buffering outgoing packets,
hoping that a route will get discovered, so that it can deliver those buffered
packets. These packets are buffered in the send buffer. There is a timeout
interval for which a packet can remain in the send buffer. After the timeout
interval, the packet expires and is removed from the buffer. The node keeps
making new attempts to find a route, with suitable back-off, to deliver the
packets it’s buffering until those packets expire in the send buffer. Thus,
making changes to the timeout interval in the send buffer of DSR would
definitely have an effect on packet delivery ratio.
Using the scenario and communication models defined above, we varied the
timeout interval of the send buffer, defined in dsr/dsragent.cc and observed
its effect on packet delivery ratio. We used the tcl script, network.tcl (given
in Appendix(C)), in our simulations.
53
SIMULATION RESULTS:
Timeout Interval vs. Packet Delivery Ratio
0.7014
0.70135
0.70134
Packet Delivery Ratio
0.7013
0.70128
0.70125
50nodes, 10connections
0.7012
0.70118
0.70115
0.7011
1
5
10
Timeout Interval in Send Buffer
Figure 16: Timeout Interval vs. Packet Delivery Ratio
INTERPRETATION OF RESULTS:
The obtained results indicate that the packet delivery ratio decreases very
slightly as the timeout interval size decreases. We reduced the timeout
interval to a minimum of 1s and still did not find any drastic change in the
packet delivery ratio.
54
4 MANAGEMENT LAYER
We extended NS to incorporate a management layer in the protocol stack of
each node. We designed the management layer to be able to communicate
with all the layers in the protocol stack. We then used the management layer
to alter the transmit power of a node.
NS implements the 914MHz Lucent WaveLAN DSSS radio interface at the
physical layer for mobile nodes. The transmission range for this layer is
defined to be 250m. The default transmit power Pt_, for this range is defined
as 0.28183 in ns-default.tcl. If the two communicating nodes moved to a
distance greater than 250m, the default Pt_ would be insufficient for packets
to be received properly. We used the management layer to detect the packet
drops and consequentially increase the transmit power at the physical layer.
The Mac layer is responsible for link-to-link communication. When the Mac
layer sends a packet, it waits for an acknowledgement from the receiver. If it
does not receive this acknowledgement within a specified time period, it
retransmits the packet. If it does not receive an acknowledgement after a
specified number of retries, it drops the packet. In NS, when the Mac-802.11
layer needs to retransmit a packet, it enters the retransmitRTS() function. So,
if the control enters the retransmitRTS() function, we know that it is time to
increase the transmit power of the node.
In our implementation, in the RetransmitRTS() function at the Mac802.11
layer, we introduced a call to the setPower(Packet *p) function of the
Management layer. This function increases the power level of the node by
55
one level. In NS, the Wireless Physical layer stamps the packet with the
transmit power down the channel. We made a small modification to this. In
the Wireless Physical layer, before sending a packet down the channel, a call
is made to the Management layer’s getPt() function. This function returns
the appropriate transmit power (based on the power level set by the
setPower()) . The Wireless Physical layer then transmits the packet with this
power.
Extending NS to Incorporate Management Layer in Protocol
Stack of Each Node
We define the management layer by the class Manage, derived from the
class BiConnector. We include the following man.h and man.cc files in the
ns-allinone-2.27/ns-2.27/mac directory.
ns-allinone-2.27/ns-2.27/mac/man.h
#ifndef ns_man_h
#define ns_man_h
#include "bi-connector.h"
#include <ll.h>
#include <wireless-phy.h>
class Manage : public BiConnector {
friend class WirelessPhy;
public:
Manage(): BiConnector() {};
void setPower();
double setPt();
int pow_level_ ;
inline int& pow_level() { return (pow_level_); }
protected:
int command(int argc, const char*const* argv);
WirelessPhy wphy_;
// wireless Phy
LL ll_;
// link layer
Mac802_11 mac_;
//mac layer
};
#endif
56
ns-allinone-2.27/ns-2.27/mac/man.cc
#ifndef lint
static const char rcsid[] =
"@(#)
$Header:
/nfs/jade/vint/CVSROOT/ns-2/mac/ll.cc,v
2002/03/14 01:12:52 haldar Exp $ (UCB)";
#endif
#include <mac.h>
#include <ll.h>
#include <man.h>
1.46
static class ManageClass : public TclClass {
public:
ManageClass() : TclClass("Manage") {}
TclObject* create(int, const char*const*) {
return (new Manage());
}
} class_man;
/* setPower(p) is called by the retransmitRTS() function of the mac
layer. */
void Manage::setPower()
{
if (pow_level() == 0)
pow_level() = 1;
else if (pow_level() == 1)
pow_level() = 2;
return;
}
/* getPt(p) is called by the sendDown() function of the physical layer.
The physical layer looks up the transmit power calculated by the
management layer and stamps the packet with that power. */
double Manage::getPt(Packet *p)
{
if (pow_level() == 0) // for a range upto 250m
return 0.28;
else if(pow_level() == 1) // for a range upto 300m
return 0.5;
else if (powlevel() == 2) // for a range upto 350m
return 1.08
}
57
EXPERIMENT 4.1: Two Node Scenario
We conducted our experiment with two nodes, gradually moving away from
each other. We attached a CBR traffic generator to one node, and a traffic
sink to the other node. The scenario used is given in Figure 17. The tcl file
used in the simulations is given in Appendix (D).
CBR
Sink
UDP
Node
1
Node
0
Node
1
Within communication range
Node 1 moving outside the communication range of Node 0
Figure 17: Scenario for Experiment 4.1
MOVEMENT MODEL:
For our experiment, we considered a scenario of 2 nodes, moving with a
maximum speed of 20m/s, with a pause time of 2s, within a topology
boundary of 1200 x 1200, for a simulation time of 100s. We specified this
scenario in a separate scenario file, scene-50-1200. We generated this
scenario file by typing the following command in ns-2.27/indeputils/cmugen/setdest directory:
58
./setdest –n 2 –p 2.0 –M 20.0 –t 100 –x 1200 –y 1200 > scene-2-1200
COMMUNICATION MODEL:
We gave the nodes 1 cbr connection, with a packet generation rate of 4
pkts/s. We specified this connection pattern in a separate pattern file cbr-2
by typing the following command in ns-2.27/indep-utils/cmugen directory:
ns cbrgen.tcl –type cbr –nn 2 –seed 0.0 –mc 1 –rate 4 > cbr-2
SIMULATION RESULTS:
Without the inclusion of the Management layer, we would expect the
receiver to drop packets once the distance between the nodes crosses 250m.
With the inclusion of our management layer we found packets were dropped
only after the distance between the nodes crossed 350m. The greatest
transmit power set by the Management layer is 1.08W. This power
guarantees packet reception for a distance of 350m only. So our results are
consistent with the design of our Management layer.
EXPERIMENT 4.2: Three Node Scenario
We conducted our experiment with three nodes, arranged in a straight line,
with two of them fixed and the third node gradually moving away. We
positioned node(0) and node (1) within the default communication range
(250m). We positioned node(2) within the communication distance of
node(1), and outside the communication range of node(0). We attached a
CBR traffic generator to node(0), and a traffic sink to node(2). The scenario
used is given in Figure 17.
59
CBR
Sink
UDP
Node
0
Node
2
Node
1
Node
2
Within
communication
range
Outside communication range
Figure 18: Scenario for Experiment 4.2
The aim of the experiment was to check if packets were dropped at the Mac
layer despite the inclusion of our Management layer. The tcl file used in the
simulations is given in Appendix (D).
MOVEMENT MODEL:
For our experiment, we considered a scenario of 3 nodes, moving with a
maximum speed of 20m/s, with a pause time of 2s, within a topology
boundary of 1200 x 1200, for a simulation time of 100s. We specified this
scenario in a separate scenario file, scene-50-1200. We generated this
scenario file by typing the following command in ns-2.27/indeputils/cmugen/setdest directory:
60
./setdest –n 2 –p 2.0 –M 20.0 –t 100 –x 1200 –y 1200 > scene-3-1200
COMMUNICATION MODEL:
We gave the nodes 1 cbr connection, with a packet generation rate of 4
pkts/s. We specified this connection pattern in a separate pattern file cbr-2
by typing the following command in ns-2.27/indep-utils/cmugen directory:
ns cbrgen.tcl –type cbr –nn 3 –seed 0.0 –mc 1 –rate 4 > cbr-3
SIMULATION RESULTS:
Without the inclusion of the Management layer, we would expect the
following. The packets from node(0) destined for node(2), must first reach
node(1) as there is no direct communication with node(2). Node(1) then
forwards the packets to node(2). The packets are received at node(2) as long
as node(1) and node(2) are within 250m. Once node(2) moves to location
outside its communication range with node(1), packets are dropped. We
observed these drops taking place at the MAC layer of node(1). This can be
explained by the fact that node(1) fails to get an acknowledgement from
node(2), and so drops the packet after repeated attempts to send.
With the inclusion of our management layer we found packets were dropped
at node(1) only after the distance between the node(1) and node(2) crossed
350m. The greatest transmit power set by the Management layer is 1.08W.
This power guarantees packet reception for a distance of 350m only. So our
results are consistent with the design of our Management layer.
61
5 CONCLUSIONS
The report presented a set of experiments to develop configurable protocols
in programmable radio networks using the NS simulator. It also gave a
concise overview of the NS simulator. The report identified adjustable
parameters in the Physical, Data link and Network layers and observed the
effects of changing their values on the application QoS parameters.
A Management layer, which could communicate with all the layers of the
protocol stack, was incorporated in NS. The report used the Management
layer to optimize the battery power of a mobile node. In future, this could be
extended to optimize the other configurable parameters identified in the
report. This would help in developing a turbo optimization technique in
which changes in the state of one layer would trigger incremental changes in
the other layers until a steady state is reached.
62
APPENDIX (A)
propagation.tcl - Simulation Script for Experiment 1 in Section 3.1
# =====================================================================
# Define options
# =====================================================================
set val(chan)
Channel/WirelessChannel
set val(prop)
Propagation/TwoRayGround # comment out when using
Free space model
#set val(prop)
Propagation/FreeSpace # comment out when using
TwoRayGround model
set val(netif)
Phy/WirelessPhy
set val(mac)
Mac/802_11
set val(ifq)
CMUPriQueue
set val(ll)
LL
set val(ant)
Antenna/OmniAntenna
set val(x)
1200
;# X dimension of the topography
set val(y)
1200
;# 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)
100
;# how many nodes are simulated
set val(cp)
"../mobility/scene/cbr-100-40-test"
set val(sc)
"../mobility/scene/scene-100"
set val(stop)
30.0
;# simulation time
# =====================================================================
# Main Program
# =====================================================================
#
# Initialize Global Variables
#
# create simulator instance
set ns_
[new Simulator]
$ns_ use-newtrace
# setup topography object
set topo
[new Topography]
# create trace object for ns and nam
set tracefd [open test-ex1-out.tr w]
set namtrace
[open test-ex1-out.nam w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
63
# define topology
$topo load_flatgrid $val(x) $val(y)
#
# Create God
#
set god_ [create-god $val(nn)]
#
# define how node should be created
#
#global node setting
$ns_ node-config -adhocRouting $val(adhocRouting) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
#
#
#
Create the specified number of nodes [$val(nn)] and "attach" them
to the channel.
for {set i 0} {$i < $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0
;# disable random motion
}
#
# Define node movement model
#
puts "Loading connection pattern..."
source $val(cp)
#
# Define traffic model
#
puts "Loading scenario file..."
source $val(sc)
# 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
64
# The function must be called after mobility model is defined
$ns_ initial_node_pos $node_($i) 20
}
#
# Tell nodes when the simulation ends
#
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at $val(stop).0 "$node_($i) reset";
}
proc stop { } {
global ns_ tracefd
$ns_ flush-trace
close $tracefd
exec nam wireless1-out &
#exec xgraph out1.tr -geometry 800x400 &
exit 0
}
$ns_ at $val(stop) "stop"
$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
puts
$tracefd
"M
0.0
nn
$val(nn)
x
$val(x)
y
$val(y)
$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)"
puts "Starting Simulation..."
$ns_ run
65
rp
APPENDIX (B)
slottime.tcl - Simulation Script for Experiment 2 in Section 3.2
# =====================================================================
# Define options
# =====================================================================
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
val(chan)
Channel/WirelessChannel
val(prop)
Propagation/TwoRayGround
val(netif)
Phy/WirelessPhy
val(mac)
Mac/802_11
val(ifq)
CMUPriQueue
val(ll)
LL
val(ant)
Antenna/OmniAntenna
val(x)
500 ;# X dimension of the topography
val(y)
500
;# Y dimension of the topography
val(ifqlen)
50
;# max packet in ifq
val(seed)
0.0
val(adhocRouting)
DSR
val(nn)
100
;# how many nodes are simulated
val(cp)
"../mobility/scene/exp1-cbr-100-40-2.66"
val(sc)
"../mobility/scene/scene-exp1-100"
val(stop)
30.0
;# simulation time
# =====================================================================
# Main Program
# =====================================================================
#
# Initialize Global Variables
#
# create simulator instance
set ns_
[new Simulator]
$ns_ use-newtrace
# setup topography object
set topo
[new Topography]
# create trace object for ns and nam
set tracefd [open st-17.tr w]
set namtrace
[open st-17.nam w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
# define topology
66
$topo load_flatgrid $val(x) $val(y)
#
# Create God
#
set god_ [create-god $val(nn)]
#
# define how node should be created
#
#global node setting
$ns_ node-config -adhocRouting $val(adhocRouting) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
#
#
Create the specified number of nodes [$val(nn)] and "attach" them
to the channel.
for {set i 0} {$i < $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0
;# disable random motion
}
#
# Define node movement model
#
puts "Loading connection pattern..."
source $val(cp)
#
# Define traffic model
#
puts "Loading scenario file..."
source $val(sc)
# 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
# The function must be called after mobility model is defined
67
$ns_ initial_node_pos $node_($i) 20
}
#
# Tell nodes when the simulation ends
#
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at $val(stop).0 "$node_($i) reset";
}
proc stop { } {
global ns_ tracefd
$ns_ flush-trace
close $tracefd
exec nam wireless1-out &
#exec xgraph out1.tr -geometry 800x400 &
exit 0
}
$ns_ at $val(stop) "stop"
$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
puts
$tracefd
"M
0.0
nn
$val(nn)
x
$val(x)
y
$val(y)
$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)"
puts "Starting Simulation..."
$ns_ run
68
rp
APPENDIX (C)
network.tcl - Simulation Script for Experiment 3 in Section 3.3
# =====================================================================
# Define options
# =====================================================================
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
val(chan)
Channel/WirelessChannel
val(prop)
Propagation/TwoRayGround
val(netif)
Phy/WirelessPhy
val(mac)
Mac/802_11
val(ifq)
CMUPriQueue
val(ll)
LL
val(ant)
Antenna/OmniAntenna
val(x)
1200 ;# X dimension of the topography
val(y)
1200
;# Y dimension of the topography
val(ifqlen)
50
;# max packet in ifq
val(seed)
0.0
val(adhocRouting)
DSR
val(nn)
50
;# how many nodes are simulated
val(cp)
"../mobility/scene/cbr-50-10-4"
val(sc)
"../mobility/scene/scene-50-1200"
val(stop)
10.0
;# simulation time
# =====================================================================
# Main Program
# =====================================================================
#
# Initialize Global Variables
#
# create simulator instance
set ns_
[new Simulator]
$ns_ use-newtrace
# setup topography object
set topo
[new Topography]
# create trace object for ns and nam
set tracefd [open cache-50-3.tr w]
set namtrace
[open cache-50-3.nam w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
69
# define topology
$topo load_flatgrid $val(x) $val(y)
#
# Create God
#
set god_ [create-god $val(nn)]
#
# define how node should be created
#
#global node setting
$ns_ node-config -adhocRouting $val(adhocRouting) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
#
#
#
Create the specified number of nodes [$val(nn)] and "attach" them
to the channel.
for {set i 0} {$i < $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0
;# disable random motion
}
#
# Define node movement model
#
puts "Loading connection pattern..."
source $val(cp)
#
# Define traffic model
#
puts "Loading scenario file..."
source $val(sc)
# 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
70
# The function must be called after mobility model is defined
$ns_ initial_node_pos $node_($i) 20
}
#
# Tell nodes when the simulation ends
#
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at $val(stop).0 "$node_($i) reset";
}
proc stop { } {
global ns_ tracefd
$ns_ flush-trace
close $tracefd
exec nam wireless1-out &
#exec xgraph out1.tr -geometry 800x400 &
exit 0
}
$ns_ at $val(stop) "stop"
$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
puts
$tracefd
"M
0.0
nn
$val(nn)
x
$val(x)
y
$val(y)
$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)"
puts "Starting Simulation..."
$ns_ run
71
rp
APPENDIX (D)
threshold-2.tcl - Simulation Script for Experiment conducted in Section 4.1
#
======================================================================
# Define options
#
======================================================================
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
val(chan)
Channel/WirelessChannel
val(prop)
Propagation/TwoRayGround
val(netif)
Phy/WirelessPhy
val(mac)
Mac/802_11
val(ifq)
CMUPriQueue
val(ll)
LL
val(ant)
Antenna/OmniAntenna
val(x)
1200 ;#X dimension of the topography
val(y)
1200
;#Y dimension of the topography
val(ifqlen)
50
;#max packet in ifq
val(seed)
0.0
val(adhocRouting)
DSR
val(nn)
2
;#how many nodes are simulated
val(cp)
"../mobility/scene/cbr-2"
val(sc)
"../mobility/scene/scene-2-1200"
val(stop)
100.0
;#simulation time
# =====================================================================
# Main Program
#
======================================================================
#
# Initialize Global Variables
#
# create simulator instance
set ns_
[new Simulator]
$ns_ use-newtrace
# setup topography object
set topo
[new Topography]
# create trace object for ns and nam
set tracefd [open man-check-1.tr w]
#set namtrace
[open man-check-1.nam w]
$ns_ trace-all $tracefd
#$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
72
# define topology
$topo load_flatgrid $val(x) $val(y)
#
# Create God
#
set god_ [create-god $val(nn)]
#
# define how node should be created
#
#global node setting
$ns_ node-config -adhocRouting $val(adhocRouting) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
set node_(0) [$ns_ node]
set node_(1) [$ns_ node]
$node_(0) random-motion 0
$node_(1) random-motion 0
for {set i 0} {$i < $val(nn)} {incr i} {
$ns_ initial_node_pos $node_($i) 20
}
#
# Define node movement model
#
puts "Loading connection pattern..."
source $val(cp)
#
# Define traffic model
#
puts "Loading scenario file..."
source $val(sc)
73
# 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
# The function must be called after mobility model is defined
# $ns_ initial_node_pos $node_($i) 20
#}
#
# Tell nodes when the simulation ends
#
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at $val(stop).0 "$node_($i) reset";
}
proc stop { } {
global ns_ tracefd
$ns_ flush-trace
close $tracefd
# exec nam wireless1-out &
#exec xgraph out1.tr -geometry 800x400 &
exit 0
}
$ns_ at $val(stop) "stop"
$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
puts
$tracefd
"M
0.0
nn
$val(nn)
x
$val(x)
y
$val(y)
$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)"
puts "Starting Simulation..."
$ns_ run
74
rp
APPENDIX (E)
threshold-3.tcl - Simulation Script for Experiment conducted in Section 4.2
#
======================================================================
# Define options
#
======================================================================
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
val(chan)
Channel/WirelessChannel
val(prop)
Propagation/TwoRayGround
val(netif)
Phy/WirelessPhy
val(mac)
Mac/802_11
val(ifq)
CMUPriQueue
val(ll)
LL
val(ant)
Antenna/OmniAntenna
val(x)
1200 ;#X dimension of the topography
val(y)
1200
;#Y dimension of the topography
val(ifqlen)
50
;#max packet in ifq
val(seed)
0.0
val(adhocRouting)
DSR
val(nn)
3
;#how many nodes are simulated
val(cp)
"../mobility/scene/cbr-3"
val(sc)
"../mobility/scene/scene-3-1200"
val(stop)
300.0
;#simulation time
# =====================================================================
# Main Program
#
======================================================================
#
# Initialize Global Variables
#
# create simulator instance
set ns_
[new Simulator]
$ns_ use-newtrace
# setup topography object
set topo
[new Topography]
# create trace object for ns and nam
set tracefd [open man-check-1.tr w]
#set namtrace
[open man-check-1.nam w]
$ns_ trace-all $tracefd
#$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
# define topology
$topo load_flatgrid $val(x) $val(y)
75
#
# Create God
#
set god_ [create-god $val(nn)]
#
# define how node should be created
#
#global node setting
$ns_ node-config -adhocRouting $val(adhocRouting) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
set node_(0) [$ns_ node]
set node_(1) [$ns_ node]
$node_(0) random-motion 0
$node_(1) random-motion 0
for {set i 0} {$i < $val(nn)} {incr i} {
$ns_ initial_node_pos $node_($i) 20
}
#
# Define node movement model
#
puts "Loading connection pattern..."
source $val(cp)
#
# Define traffic model
#
puts "Loading scenario file..."
source $val(sc)
# Define node initial position in nam
#for {set i 0} {$i < $val(nn)} {incr i} {
76
# 20 defines the node size in nam, must adjust it according to your
scenario
# The function must be called after mobility model is defined
# $ns_ initial_node_pos $node_($i) 20
#}
#
# Tell nodes when the simulation ends
#
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at $val(stop).0 "$node_($i) reset";
}
proc stop { } {
global ns_ tracefd
$ns_ flush-trace
close $tracefd
# exec nam wireless1-out &
#exec xgraph out1.tr -geometry 800x400 &
exit 0
}
$ns_ at $val(stop) "stop"
$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
puts
$tracefd
"M
0.0
nn
$val(nn)
x
$val(x)
y
$val(y)
$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)"
puts "Starting Simulation..."
$ns_ run
77
rp
REFERENCES
[1] NS Manual http://www.isi.edu/nsnam/ns
[2] NS by Example http://nile.wpi.edu/NS
[3] Mineo Takai, Jay Martin, Rajive Bagrodia, UCLA Computer Science
Department, “Effects of Wireless Physical Layer Modeling in Mobile Ad-hoc
Networks”
78