1 / 66

Design Routing Protocol Performance Comparison in NS2: AODV comparing to DSR as Example

Design Routing Protocol Performance Comparison in NS2: AODV comparing to DSR as Example. Yinfei Pan SUNY Binghamton Computer 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.

cachet
Télécharger la présentation

Design Routing Protocol Performance Comparison in NS2: AODV comparing to DSR as Example

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 • 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. Node 1 Module Node 2 Module TX Pkt Event @ 1.5sec TX Pkt Event @ 1.5sec RX Pkt Event @ 1.7sec RX Pkt Event @ 1.7sec TX Ack Event @ 1.8sec Event @ 2.0sec Event @ 2.0sec Event @ 1.8sec Event Driven Simulation Event Queue 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

  8. Simulation Scenario 2 C++ Implementation 1 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(); • • }

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

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

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

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

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

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

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

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

  17. 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_ 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"

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

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

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

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

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

  23. The output of setdest

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

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

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

  27. The traffic generating output

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

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

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

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

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

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

  34. Trace file format (cont.) • IP Trace

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

  36. Trace file format (cont.) • Specific extension (DSR format)

  37. 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 ++; } …… ……

  38. 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 ++; } } }

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

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

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

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

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

  44. Precursor Nodes Next Hop A Destination Source Source 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

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

  46. 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 createforward route • Source begins sending data when it receives first RREP Source Destination Forward Path Formation

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

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

More Related