1. Yinfei Pan SUNY Binghamton Computer Science
Design Routing Protocol Performance Comparison in NS2: AODV comparing to DSR as Example
Yinfei Pan
SUNY Binghamton
Computer Science

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

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

4. About NS-2 Academic project over 10 years old Large user base
freely distributed, open source
Large user base
mostly academics
“de facto” standard in networking research

5. 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”

6. Event Driven Simulation
2.0sec
TX Pkt 1.5sec
Node 1 Module
RX Pkt 1.7sec
Event Queue
TX Ack 1.8sec
2.0sec
TX Pkt 1.5sec
1.8sec
RX Pkt 1.7sec
Node 2 Module
It works like events passing among Nodes which is programmed
as modules

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

10. Simulation Scenario Tcl Script C++ Implementation 1 2
set ns_ [new Simulator]
set node_(0) [$ns_ node]
set node_(1) [$ns_ node]
Tcl Script
class MobileNode : public Node {
friend class PositionHandler;
public:
MobileNode(); • }
C++ Implementation

11. 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?

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

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

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

15. # Before we can create node, we first needs to configure them
# 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

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

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

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

19. 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 ”
# setup traffic flow between the two nodes as follows: TCP connections between node_(0) and node_(1)
set tcp [new Agent/TCP]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_(0) $tcp
$ns_ attach-agent $node_(1) $sink
$ns_ connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 10.0 "$ftp start"

20. # 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 "$node_($i) reset"; }
$ns_ at "stop"
$ns_ at "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 s, a little later after resetting the nodes. The procedure stop{} is called to flush out traces and close the trace file.

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

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

23. 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]

24. Setdest Example Topology boundary is 500m X 500m
./setdest -n 20 -p 2.0 -s 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

25. The output of setdest

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

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

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

29. The traffic generating output

30. How to add generating results to the main tcl file?
Add two variables in parameter options
set 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 statements
source $val(sc)
source $val(cp)

31. 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
./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
The same way to generate different traffic patterns

32. Run main tcl and accumulate extracted results
for sim_time in 1 2 3 do
for node in
#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

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

34. Trace file format Trace file snapshot which routing with AODV:
Trace file snapshot which routing with DSR:

35. Trace file format (cont.)
Common header:

36. Trace file format (cont.)
IP Trace

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

38. Trace file format (cont.)
Specific extension (DSR format)

39. Perl Script in Reading Trace
open(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 ++; ……

40. 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 ++;

41. 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 CBR
packets, AODV routing control packets, DSR routing control packets, and
so on.

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

43. 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 Discovery
Route Maintenance

44. DSR - Route Discovery
To establish a route, the source floods a Route 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 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 Cache which records routes it has learned and overheard over time

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

46. 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 A
Precursor Nodes
Destination

47. Route Discovery Source broadcasts Route Request (RREQ)
<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
Destination
Route Request Propagation

48. <Flags, HopCnt, Dst_Addr, Dst_Seq#, Src_Addr, Lifetime>
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

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

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

51. 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 MAC

52. Under low load, DSR is better

53. Under normal load, DSR is better
AODV begin to drop packets

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

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

56. Low load, delay is small

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

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

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

60. For routing load, AODV is always
much more higher than DSR

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

65. I will open the related source under
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.

66. Thank you