Design Routing Protocol Performance Comparison in NS2:

AODV comparing to DSR as Example

Yinfei Pan

SUNY BinghamtonComputer Science

Why this topic important?• There are already many projects try to tell us how

to use NS-2 easily, while not as that difficult as its official manual says.

• However, how to easily use NS-2 to do performance evaluation is still lacking.– Usually, a trace file is larger than 600MB, to analysis

this huge file definitely will cost great time.– There are many evaluation methods, but to use them is

very time cost and may not exactly what the simple version we want.

• This project is to let people who use NS-2 can easily do the work of network post simulation. Thus make the fast use of NS-2 more practical.

Overview

• Do wireless simulation in NS-2

• Reading trace file

• How to program the analysis on trace file

• Example Part– Brief on AODV & DSR– Simulating them in NS-2– Show the analysis results

About NS-2

• Academic project over 10 years old– freely distributed, open source

• Large user base – mostly academics

• “de facto” standard in networking research

NS-2 could do what for us?

• Discrete event network simulator– Physical activities are translated to events– Events are queued and processed in the order of

their scheduled occurrences– Time progresses as the events are processed – So, the simulation “time” may not be the real

life time you “input”

Event Driven Simulation

TX Pkt Event @ 1.5sec

Node 1 Module

Node 2 Module

TX Pkt Event @ 1.5sec

RX Pkt Event @ 1.7sec

RX Pkt Event @ 1.7sec

TX Ack Event @ 1.8sec

Event Queue

It works like events passing among Nodes which is programmed as modules

Event @ 2.0sec

Event @ 2.0sec

Event @ 1.8sec

NS-2 could do what for us? (cont.)

• Modeling Essential Network Components– Traffic models and applications

– Transport protocols

– Routing and queue

– Link layer mechanism

• Providing a huge trace file recording all the events line by line in it. So, we can see event driven mechanism is important for post simulation analysis

Agent(Src/ Sink)

Port

Demux

DSR

LL

IFq

MAC

NetIFRadio

PropagationModel

Channel

ARP

Simulation Scenario

Tcl Script

C++ Implementation

1 2

set ns_ [new Simulator]

set node_(0) [$ns_ node]

set node_(1) [$ns_ node]

class MobileNode : public Node {

friend class PositionHandler;public: MobileNode();

••

}

What we need in one simulation?

• Appearance: the whole topology view of sensor network or mobile network– The position of nodes: (x, y, z) coordinate– The movement parameters

• Starting time• To what direction• Speed

• Internal work: which nodes are the sources? what are the connections? and using what kind of connection?

• Drive the simulation: What about the configuration network components on sensor node? Where to give out the simulation results? How to organize a simulation process?

Running simple wireless simulations in NS-2 (do the above in one tcl)

• # Create an instance of the simulator,

set ns_ [new Simulator]

• # Setup trace support by opening file # “trace_bbtr.tr” and call the procedure trace-all

set tracefd [open trace_bbtr.tr w]$ns_ trace-all $tracefd

• # Create a topology object that keeps track # of all the nodes within boundary

set topo [new Topography]

• # The topography is broken up into grids

# and the default value of grid resolution is 1.

# A diferent value can be passed as a third

# parameter to load_flatgrid {}.

$topo load_flatgrid $val(x) $val(y)

• # Create the object God, "God (General Operations Director) is the object that is used to store global information about the state of the environment, network or nodes

set god_ [create-god $val(nn)]

• The procedure create-god is defined in $NS2_HOME/tcl/mobility/com.tcl, which allows only a single global instance of the God object to be created during a simulation.

• God object is called internally by MAC objects in nodes, so we must create god in every cases.

• # Before we can create node, we first needs to configure them. Node configuration API may consist of defining the type of addressing (flat/hierarchical etc), for example, the type of adhoc routing protocol, Link Layer, MAC layer, IfQ etc.

$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) \ -channel [new $val(chan)] \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace OFF

# Simulation options# channel typeset val(chan) Channel/WirelessChannel# radio-propagation modelset val(prop) Propagation/TwoRayGround# Antenna typeset val(ant) Antenna/OmniAntenna# Link layer typeset val(ll) LL# Interface queue typeset val(ifq) Queue/DropTail/PriQueue# max packet in ifqset val(ifqlen) 50 # network interface typeset val(netif) Phy/WirelessPhy# MAC typeset val(mac) Mac/802_11# ad-hoc routing protocol set val(rp) DSDV# number of mobilenodesset val(nn) 5

• # create nodes:

for {set i 0} {$i < $val(nn) } {incr i} {

set node_($i) [$ns_ node]

# disable random motion

$node_($i) random-motion 0

}

• The random-motion for nodes is disabled here, as we are going to provide node position and movement (speed & direction) directives next.

• # give nodes positions to start with, Provide initial (X,Y, for now Z=0) co-ordinates for node_(0) and node_(1). Node0 has a starting position of (5,2) while Node1 starts off at location (390,385).

$node_(0) set X_ 5.0$node_(0) set Y_ 2.0$node_(0) set Z_ 0.0

$node_(1) set X_ 390.0$node_(1) set Y_ 385.0$node_(1) set Z_ 0.0

• At time 50.0s, node 1 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 nodes.

$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0”

• # setup traffic flow between the two nodes as follows: TCP connections between node_(0) and node_(1)

set tcp [new Agent/TCP]$tcp set class_ 2set sink [new Agent/TCPSink]$ns_ attach-agent $node_(0) $tcp$ns_ attach-agent $node_(1) $sink$ns_ connect $tcp $sinkset ftp [new Application/FTP]$ftp attach-agent $tcp$ns_ at 10.0 "$ftp start"

• # define stop time when the simulation ends and tell nodes to reset which actually resets their internal network components

for {set i 0} {$i < $val(nn) } {incr i} { $ns_ at 150.0 "$node_($i) reset";}

$ns_ at 150.0001 "stop"$ns_ at 150.0002 "puts \"NS EXITING...\" ; $ns_ halt"

proc stop {} { global ns_ tracefd nf $ns_ flush-trace close $tracefd close $nf}

# 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.

• # finally the command to start the simulation

puts "Starting Simulation...\n"$ns_ run

• There are some problems for the use of above tcl programming steps for actually testing– Performance testing usually needs to be scalable in the

number of nodes and network transmitting packets– Suppose the work you need to set all of the nodes’

positions and their movement, what a huge amount of work?

– Suppose you need to setup all the possible sources and destinations and even connections, also a huge work load, isn’t it?

– Also, even if you set them, can you guarantee what your input is randomly select? This is necessary for a fair comparison.

For performance test purpose

• Can we do nodes and network traffic related work automatically?– Yes, definitely.

• For nodes positions and their movement– We can generate a file with the statements of set nodes

positions and nodes movement using CMU generator.– It is under

$NS2_HOME/indep-utils/cmu-scen-gen/setdest– You need run “make” to create executable “setdest”

program

Scenario Generating

• The usage of $NS2_HOME/indep-utils/cmu-scen-gen/setdest/setdest

./setdest [-n num_of_nodes] [-p pausetime] [-s maxspeed] [-t simtime] [-x maxx] [-y maxy] > [scenario_output_file]

Setdest Example

• ./setdest -n 20 -p 2.0 -s 10.0 -t 200 -x 500 -y 500 > scen-20-test

– Topology boundary is 500m X 500m – This scenario has 20 nodes – Nodes’s max moving speed is 10.0m/s – Pause between movement is 2s– Simulation will stop in 200s – Finally, output the generate tcl statements into

file whose name is scen-20-test

The output of setdest

For performance test purpose (cont.)

• For network traffic generating– What generated are also statements on such as sources,

connections, and so on.

– This work could be done as a tcl file, which is as $NS2_HOME/indep-utils/cmu-scen-gen/cbrgen.tcl

– Since this can be easily read and modified, if you want, you can just simply modify it so that the scenario be generated will be more suitable to what your need.

Network traffic generating

• ns cbrgen.tcl [-type cbr/tcp] [-nn nodes] [-seed seed] [-mc connections] [-rate rate] – -type cbr/tcp: define the type of traffic connection– -nn nodes: the number of nodes could be used– -mc connections: maximum number of connections to

be setup between those nodes– -seed seed: a random seed, if it not equal to 0, the

traffic pattern will reappear if all the other parameters are the same

– -rate rate: a rate whose inverse value is used to compute the interval time, which easily to say is packets sending rate

Network traffic generating (cont.)

• ns cbrgen.tcl -type cbr -nn 20 -seed 1.0 -mc 20 -rate 4.0 > cbr-20-test – create a CBR connection pattern between 20

nodes, having maximum of 20 connections, with a seed value of 1.0 and a rate of 4.0 pkts/second

The traffic generating output

How to add generating results to the main tcl file?

• Add two variables in parameter optionsset val(sc) "/home/ypan3/sensortcl/scen-20-test "set val(cp) "/home/ypan3/sensortcl/cbr-20-test“

• /home/ypan3/sensortcl/ could be on directory you store all your tcl files

• In the main tcl file, just replace all the tcl statements which are related to node placement and movement, and also traffic creating with the following two statementssource $val(sc)source $val(cp)

Do generating automatically for performance test

• Ex: write a shell script to create several scenarios which are with different number of nodes

for sim_time in 1 2 3 do mkdir Scenario_${sim_time} for node_num in 50 100 150 do ./setdest -v 1 -n ${node_num} -p 400 -M 5 -t 200 -x 500 -y 500 > /Scenario_${sim_time}/scen_${node_num}_400_5_200_500_500 done done

• The same way to generate different traffic patterns

• Run main tcl and accumulate extracted results

for sim_time in 1 2 3

dofor node in 50 100 150

do

#go to the specific directory with specific number of node

cd ${tracefile_directory}

rm -f trace_bbtr.tr #this is the trace file

ns main.tcl

rm -f result.txt

perl cal_trace.pl #do trace file analysis in a perl script file!

cat result.txt >> result1.txt #append the results

done

done

Trace file analysis in perl script• Some terms usually used for measuring

routing performance– Packet Delivery Rate

• Total packets successfully received / Total packets sent

– Average Delay:• Sum(for each i equal to packet number, (packet i received -

time packet i sent time)) / Total packets transmitted

– Average Routing Load• Total routing control pkts / Simulation time

Trace file format

Trace file snapshot which routing with AODV:

Trace file snapshot which routing with DSR:

Trace file format (cont.)Common header:

Trace file format (cont.)• IP Trace

Trace file format (cont.)• Specific extension (AODV format)

Trace file format (cont.)

• Specific extension (DSR format)

Perl Script in Reading Traceopen(FileHndl, "trace_bbtr.tr")

while($line = <FileHndl> ) { if($line =~ /(\w)\s(\d*\.\d*)\s\_(\d*)\_\s*\w*\s*\S*\s*(\d*)\s*(cbr)\s\d*\s\\[\d*\w*\s\d*\w*\s\d*\w*\s\d*\w*\]\s*\S*\s*\[(\d*)\:\d*\s*(\d*)/) {

#print "$1, $2, $3, $4, $5, $6, $7. \n"; if($1 eq "s")

{ $num_of_s ++;

} if($1 eq "s" && $3 eq $6) # Current node is its destination node { $pkt_s_time[$4] = $2; #$4 is event id $num_of_t ++; } ……

……

Perl Script in Reading Trace (Cont.) if($line =~ /(\w)\s(\d*\.\d*)\s\_(\d*)\_\s*\w*\s*(\S*)\s*(\d*)\s*(AODV)/)

{ #print "$1, $2, $3, $4, \n"; if ($flag eq 0) {

$simulation_start_time = $2; #start time of begin transmit pkts

$flag =1; } if ($1 eq "r" && $4 ne "END“) {

$pkt_recv_time = $2; # update to newest pkts receive time$num_of_routing ++;

} } }

The core work of the perl script• So, from the previous code segments, it is

easily to see that the perl script is to get the trace file line by line

The statement:if($line =~ /(\w)\s(\d*\.\d*)\s\_(\d*)\_\s*\w*\s*\S*\s*(\d*)\s*(cbr)\s\d*\s\

\[\d*\w*\s\d*\w*\s\d*\w*\s\d*\w*\]\s*\S*\s*\[(\d*)\:\d*\s*(\d*)/)works as a filter when try to get a line from the trace file.

So, it can easily draw out the packets we want to count, such as CBRpackets, AODV routing control packets, DSR routing control packets, and so on.

Performance Comparison Example on AODV & DSR

• The following will be on AODV and DSR comparison, the main part will be on the test results which were get from the above performance evaluation code.

Dynamic Source Routing (DSR)

• Forwarding: source route driven instead of hop-by-hop route table driven– <Source> <IDn1, IDn2,…, IDnm> <Destination>

• No periodic routing update message is sent• Nodes ignore topology changes not affecting

active routes with packets in the pipe• The first path discovered is selected as the route• Two main phases

– Route DiscoveryRoute Discovery – Route MaintenanceRoute Maintenance

DSR - Route Discovery• To establish a route, the source floods a Route RequestRoute Request

message with a unique request ID– Packet has route record :<RREQ, RREQid, IDsrc, IDn1, IDn2,…,

IDnm>– Duplicate detect: <initiator, RREQid> list– Loop detect: own id appear in route record?– Reply?– Append its own ID to the route record for re-broadcast

• Route ReplyRoute Reply message containing path information is sent back to the source either by– the destination, or– intermediate nodes that have a route to the destination– Reverse the order of the route record, and include it in Route

Reply.– Unicast, source routing

• Each node maintains a Route CacheRoute Cache which records routes it has learned and overheard over time

Ad hoc On-Demand Distance Vector Routing (AODV)

• Primary Objectives– Provide unicast, broadcast, and multicast capability– Initiate forward route discovery only on demand– Disseminate changes in local connectivity to those

neighboring nodes likely to need the information

• Characteristics– On-demand route creation

• Effect of topology changes is localized

– Two dimensional routing metric: <Seq#, HopCount>– Storage of routes in Route Table

Route Table• Fields:

– Destination IP Address

– Destination Sequence Number

– Hop Count

– Next Hop IP Address

– Precursor Nodes

– Expiration Time

• Each time a route entry is used to transmit data, the expiration time is updated to current_time + active_route_timeout

Next Hop

Source

Source

APrecursor Nodes

Destination

Route Discovery

<Flags, Bcast_ID, HopCnt, Src_Addr, Src_Seq#, Dst_Addr, Dst_Seq#>

• Node can reply to RREQ if

– It is the destination, or

– It has a “fresh enough” route to the destination

• Otherwise it rebroadcasts the request

• Nodes create reverse route entry

• Record Src IP Addr / Broadcast ID to prevent multiple rebroadcasts

• Source broadcasts Route Request (RREQ)

Source

Destination

Route Request Propagation

• Destination, or intermediate node with current route to destination, unicasts Route Reply (RREP) to source

<Flags, HopCnt, Dst_Addr, Dst_Seq#, Src_Addr, Lifetime>

• Nodes along path create forward route

• Source begins sending data when it receives first RREP

Source

Destination

Forward Path Formation

What are the differences?• DSR allow cache more paths from a source to a

destination, while AODV just use the path first discovered.– So, DSR have significant greater amount of routing information

than AODV– DSR has access to many alternate routes which saves route

discovery floods, the performance then will be better if they are actually in use.

• DSR doesn’t contain any explicit mechanism to expire stale routes in the cache– Choose stale routes under stressful situation is normal thing in

DSR

• So, AODV is more conservative while DSR is more aggressive in using the past information. Which is better is hard to say.

What expected from the Comparison • Routing load

– DSR lower than AODV ( in terms of # of packets) due to aggressive caching (though more replies and errors)

– AODV is dominated by RREQ packets

• Packet delivery and delay

– DSR better if less stressful traffic load.

• Caching only provide significant benefits to a certain extent!

• Stale caches are chosen in high loads which will cause unnecessary bandwidth consumption and pollution of caches in other nodes.

– Delays are due to buffering (route discovery latency) and congestion

• So, DSR may be better in most cases

Performance evaluating configuration• The testing is in a 500 * 500 square• Total 50 nodes• Traffic sources are CBR, 512-byte as data packets,

sending rate is 4 pkts/sec• The number of sources are 10, 18, 32 and 45

separately• The node movement speed is set to from 0 to 5

which will be closer to the mobile sensor network’s application

• The mobility are done with various pause time: 50, 100, 150, 220, 325, 575, 800 seconds

• Using 802.11 MAC

Under low load, DSR is better

Under normal load, DSR is betterAODV begin to drop packets

Load become heavy, DSR become worse than AODV with low pause time which is also high mobility

Load is very stressful, DSR become more worse than AODV with low pause time, but both of them degenerate greatly

Low load, delay is small

Normal load, AODV become higher, this is because routing packets are more with AODV which may cause some latency of sending data packets

Load become heary, DSR with small pause time have more delay time since stale routes often be choose, which lost many delivery time

Under heavy load, AODV become higher again, this is because though many stale routes in DSR were used, AODV also generate many more RREQ pkts, so the RREQ pkts in AODV is indeed a great bottle neck

For routing load, AODV is alwaysmuch more higher than DSR

• Conclusion– AODV generate more RREQ pkts. So, it is

better to incorporate some ideas of DSR such as cache routing information into the specification of AODV. And, for DSR, it is better to have some expiration time for the routing cache entries.

– This performance evaluation mechanism developed by this project is really effective for scalable performance test in NS-2.

• I will open the related source under– http://www.cs.binghamtone.edu/~ypan3– I think the code produced by the research work

of this project will be very useful for who want to use NS-2 do network research.

Thank you