Analysis and Performance evaluation of routing protocols in … › ~mwang2 › projects › MANET_routing... · 2014-12-14 · Analysis!and!PerformanceEvaluation!of! Routing!Protocolsin!MANETS!!!!

Analysis and Performance Evaluation of

Routing Protocols in MANETS

Team Effort by

Ankita Mukherjee

Roopashree N

Department of Computer Science & Engineering, Santa Clara University

Fall 2014

Computer Networks Project – Fall 2014

1

Preface Mobile ad-‐hoc network is a relatively new innovation in the field of wireless technology. These types of networks operate in the absence of fixed infrastructure, which makes them easy to deploy at any place and at any time. The absence of any fixed infrastructure in mobile ad-‐hoc networks makes it difficult to utilize the existing techniques for network services, and poses number of various challenges in the area.

Mobile ad-‐hoc networks (MANETS) are a popular subject for research as laptops and 802.11/Wi-‐Fi wireless networking has become a widespread application. Many of the academic papers evaluate protocols and abilities assuming varying degrees of mobility within a bounded space, usually with all nodes within a few hops of each other, and usually with nodes sending data at a constant rate. Different protocols are then evaluated based on the packet drop rate, the overhead introduced by the routing protocol, and other measures.

This project aims at evaluating one proactive, two reactive and one hybrid protocol in MANETS.


2

Acknowledgement The sense of contention and elation that accompanies the success of this project and report could be incomplete without expressing our gratitude to Dr. Prof Ming-‐Hwa Wang, whose constant guidance and support resulted in the completion of the project and also for giving us the opportunity to work together as a team.


3

Table of Contents

List of Tables and Graphs ........................................................................................................ 4

Abstract .................................................................................................................................. 6

2. Introduction ....................................................................................................................... 7 2.1 Objective .................................................................................................................................... 7 2.2 What is the problem? ................................................................................................................. 7 2.3 Why is this project related to class ............................................................................................. 7 2.4 Why other approaches are not good ........................................................................................... 7 2.5 Why we think our approach is better .......................................................................................... 7 2.6 Statement of the problem .......................................................................................................... 7 2.7 Area or scope of investigation .................................................................................................... 8

3. Theoretical bases and literature review .............................................................................. 8 3.1 Definition of the problem ........................................................................................................... 8 3.2 Theoretical background of the problem ...................................................................................... 8 3.3 Related research to solve the problem ....................................................................................... 8 3.4 Advantage/Disadvantage of those research ................................................................................ 9 3.5 Our solution to solve this problem .............................................................................................. 9 3.6 Where our solution is different from others? .............................................................................. 9 3.7 Why our solution is better? ........................................................................................................ 9

4. Hypothesis/Goals ............................................................................................................... 9 4.1 Positive/Negative hypothesis ..................................................................................................... 9

5. Methodology .................................................................................................................... 10 5.1 How to generate/collect input data .......................................................................................... 10 5.2 How to solve the problem ........................................................................................................ 10

5.2.1 Algorithm Design ...................................................................................................................... 10 5.2.2 Language used .......................................................................................................................... 10 5.2.3 Tools used ................................................................................................................................. 10

5.3 How to generate output ........................................................................................................... 10 5.4 How to test against hypothesis ................................................................................................. 11

6. Implementation ................................................................................................................ 11 6.1 Code ......................................................................................................................................... 11

7. Data analysis and discussion ............................................................................................. 17 7.1 Output generation .................................................................................................................... 17

7.1.1 Tracing Objects ......................................................................................................................... 18 7.1.2 Working with Trace file ............................................................................................................. 19 7.1.3 Plotting Graph ........................................................................................................................... 20

7.2 Output analysis ........................................................................................................................ 20


4

7.2.1 AODV ......................................................................................................................................... 20 7.2.2 DSDV ......................................................................................................................................... 21 7.2.3 DSR ............................................................................................................................................ 23 7.2.4 ZRP ............................................................................................................................................ 24 7.2.5 Comparison Graphs .................................................................................................................. 26

7.3 Compare output against hypothesis ......................................................................................... 27 7.4 Abnormal case explanation ...................................................................................................... 27

8. Conclusions and Recommendations .................................................................................. 28 8.1 Summary and Conclusions ........................................................................................................ 28 8.2 Recommendations for future studies ........................................................................................ 28

9. Bibliography ..................................................................................................................... 29

10. Appendices ..................................................................................................................... 30 10.1 Other related material ............................................................................................................ 30

10.1.1 Awksript .................................................................................................................................. 30 10.1.2 NS Directory Structure ............................................................................................................ 32

List of Tables and Graphs

Table 7.1 Collision values for AODV………………………………………………………………………………………………….20 Graph 7.1 Collision in AODV……………………………………………………………………………………………………………..20 Table 7.2 Delay values for AODV………………………………………………………………………………………………………21 Graph 7.2 Delay in AODV………………………………………………………………………………………………………………….21 Table 7.3 Throughput values per node for AODV………………………………………………………………………………21 Graph 7.3 Throughput values for AODV……………………………………………………………………………………………21 Table 7.4 Collision values for DSDV…………………………………………………………………………………………………..22 Graph 7.4 Collision in DSDV………………………………………………………………………………………………………………22 Table 7.5 Delay values for DSDV……………………………………………………………………………………………………….22 Graph 7.5 Average delay in DSDV……………………………………………………………………………………………………..22 Table 7.6 Throughput values per node DSDV…………………………………………………………………………………….23 Graph 7.6 Throughput values per node DSDV……………………………………………………………………………………23 Table 7.7 Collision values for DSR……………………………………………………………………………………………………..23 Graph 7.7 Collision in DSR…………………………………………………………………………………………………………………23 Table 7.8 Delay values for DSR………………………………………………………………………………………………………….24 Graph 7.8 Delay in DSR……………………………………………………………………………………………………………………..24 Table 7.9 Throughput values per node for DSR………………………………………………………………………………….24 Graph 7.9 Throughput values per node in DSR…………………………………………………………………………………..24 Table 7.10 Collision values for ZRP…………………………………………………………………………………………………….25


5

Graph 7.10 Collision in ZRP………………………………………………………………………………………………………………25 Table 7.11 Delay values for ZRP……………………………………………………………………………………………………….25 Graph 7.11 Delay in ZRP…………………………………………………………………………………………………………………..25 Table 7.12 Throughput values per node for ZRP……………………………………………………………………………….26 Graph 7.12 Throughput values per node in ZRP……………………………………………………………………………….26 Graph 7.13 Comparison of Delay……………………………………………………………………………………………………..26 Graph 7.14 Comparison per node throughput………………………………………………………………………………….27 Graph 7.15 Comparison of drop packets………………………………………………………………………………………….27


6

Abstract A wireless network is a network of computers, computer peripherals and various other devices that are connected to each other without wires. This enables ease of communication, especially for mobile computing platforms.

A wireless ad-‐hoc network is a decentralized type of wireless network. The network is ad-‐ hoc because it does not rely on a pre-‐existing infrastructure, such as routers in wired networks or access point in managed wireless networks. Instead, each node participates in routing by forwarding data for other nodes, and so the determination of which nodes forward data is made dynamically based on the network connectivity.

A Mobile Ad-‐hoc Network (MANET) is an autonomous collection of mobile users that communicate over relatively bandwidth constrained wireless links. Since the nodes are mobile, the network topology may change rapidly and unpredictably over time. The network is decentralized, where all network activity including discovering the topology and delivering messages must be executed by the nodes themselves i.e., routing functionality will be incorporated into mobile nodes.

In MANETS, each mobile node acts as a routing node, and a packet is routed from source to its destination by incorporating of other network users. Every node in this ad-‐hoc network acts as both a host and a router, and often the network is intelligent enough to handle the network dynamics.

This project aims to analyze the performance metrics i.e. Collision, delay incurred and throughput in MANETS for different routing protocols.

A network collision occurs when more than one mobile device attempts to send a packet on a network segment at the same time.

The delay of a network specifies how long it takes for a bit of data to travel across the network from one node to another. Delay is incurred due to collision.

Throughput or network throughput is the average rate of successful message delivery over a communication channel. This data may be delivered over a physical or logical link, or pass through a certain network node. The throughput is usually measured in bits per second (bit/s or bps), and sometimes in data packets per second or data packets per time slot.

Collision and delay together affect throughput of the transmission in the network.

We aim to analyze the metrics for one proactive, two reactive and one hybrid routing protocol for MANETS. All these performance metrics are analyzed for different scenarios using NS-‐2.


7

2. Introduction

2.1 Objective To analyze the performance of different routing protocols in MANETS with respect to different performance metrics i.e; collision, delay incurred and throughput. All these performance metrics are analyzed for different scenarios using NS-‐2.

2.2 What is the problem? MANETS operate in the absence of fixed infrastructure, which makes them easy to deploy at any place and at any time. The absence of any fixed infrastructure in mobile ad-‐hoc networks makes it difficult to utilize the existing techniques for network services, and poses number of various challenges in the area and one of the major challenges is to find a appropriate routing protocol.

2.3 Why is this project related to class The project involves implementing and evaluating different routing protocols. In MANETS, every node acts as a router and also as a host to forward data packets. Since, it does not relay on any fixed infrastructure, a suitable routing protocol which works best in a particular scenario is highly needed. Hence, routing protocols play a major role in MANETS and also it is a key feature of computer networks.

2.4 Why other approaches are not good While studying different research papers, we came across few papers where reactive protocols works better with low no of nodes. The conclusions of those papers are totally specific for a particular condition. As the no of nodes and connections increases, reactive protocols might not work at its best as compared to hybrid protocols.

2.5 Why we think our approach is better We propose to do a detail simulation study of different routing protocols in mobile ad-‐hoc networks under various scenarios which includes low no of nodes and connections as well as high no of nodes and connections so that we can show which particular protocol works best in a particular condition. Also, we are using NS-‐2 for the simulation in which results can be quickly obtained and more complex scenarios can be easily tested in a smaller time frame.

2.6 Statement of the problem Impact of different routing protocols for mobile ad-‐hoc networks with respect to different performance metrics.


8

2.7 Area or scope of investigation Ad-‐hoc networks are a new paradigm of wireless communication for mobile host. The future commercial use may include but not restrict to conferencing, home networking and personal area network and embedded computing application. This project will focus mostly on analyzing proactive, reactive and hybrid protocols. Designing of network protocols in MANETS is a complex issue. We will be simulating these protocols in NS-‐2 with different no of nodes and based on the performance metrics we will try to show which protocol works best for the given scenario. These results would be shown graphically using Gnuplot.

3. Theoretical bases and literature review

3.1 Definition of the problem For MANETS to operate efficiently appropriate routing protocols have to be incorporated. To identify the best routing protocol we need to analyze where proactive, reactive and hybrid protocols works at its best.

3.2 Theoretical background of the problem Pervasive computing refers to the emerging trend towards numerous, easily accessible computing devices connected to an increasingly ubiquitous network infrastructure. This trend will likely create new opportunities and challenges for the Information Technology (IT) companies to place high-‐performance computers and sensors in virtually every device, appliance, and piece of equipment in buildings, homes, workplaces, and factories, and even in clothing. Various areas like sensing the environment and Actuating, Human Computer Interaction, Security and Privacy and Networking and Distributed Systems, contribute to the Pervasive Computing Environment. This project contributes to the Networks aspect of Pervasive Computing. A MANET is an autonomous collection of mobile users that communicate over relative bandwidth constrained wireless links. Since the nodes are mobile, the network topology may change rapidly and unpredictably over time.

3.3 Related research to solve the problem • Research has been carried out to evaluate performance of different MANET routing

protocols based on performance metrics such as average end-‐to-‐end delay, throughput, normalized routing load, packet delivery fraction and average jitter.

• Lot of research is being carried out to optimize the hybrid protocols such that it works better than hybrid protocols.


9

3.4 Advantage/Disadvantage of those research • Based on detailed simulation study appropriate routing protocol in MANETS for particular

scenario can be chosen. • Better improvement can be done on the research in terms of optimization techniques for

routing protocols in MANETS.

3.5 Our solution to solve this problem We will analyze one proactive (DSDV), 2 reactive (AODV & DSR) and 1 hybrid (ZRP) protocol for different number of nodes and various connections in a network simulator. We have chosen NS2 version 2.35 as our simulation tool. The back end of NS2 consists of C++ core methods and the front end is OTCL. We will use TCL scripts for the simulation of the above mentioned protocols. Also, we are using NAM (Network Animator) in which we can visualize the network topology, node mobility and transmission of data packets. Based on the simulation results obtained for different routing protocols, we need to plot graphs for the purpose of evaluation.

3.6 Where our solution is different from others? Active research work for mobile ad hoc network is carried out mainly in the fields of medium access control, routing, resource management, power control and security. Because of the importance of routing protocols in dynamic multi-‐hop networks, a lot of mobile ad hoc network routing protocols have been proposed in the last few years but most of them have proved that reactive protocol DSR is best in performance. We will implement zone routing protocol which is a hybrid protocol and show that it will perform better than DSR.

3.7 Why our solution is better? As we are trying to implement a hybrid protocol which combines the advantages of both proactive and reactive protocol. It will definitely produce better results than proactive and reactive protocols for various no of nodes and under different conditions.

4. Hypothesis/Goals

4.1 Positive/Negative hypothesis • Implementing hybrid protocol like ZRP will give better results than other proactive and

reactive protocols as the no of nodes, connections and node mobility increases. • If we optimize ZRP protocol to control the overhead caused by the forwarding of query

packets, then much efficient performance will be obtained.


10

5. Methodology

5.1 How to generate/collect input data We have to write a TCL script which contains the below details

• Define Options: define the channel type, queue length, no of mobile nodes, routing protocol, X area grid, Y area grid and simulation stop time.

• Should Initialize the global variables such as packet size and trace file descriptor and set the network animator file.

• Set up the topography object. • Create specified no of mobile node and attach them to channel. Also, configure the

nodes that are created. • Provide initial X, Y coordinates for mobile nodes. • Specify node movements. • Specify data packet transfer. • Stop at the specified simulation end time.

5.2 How to solve the problem

5.2.1 Algorithm Design • Code to construct topology using TCL Script • Code is executed using Shell Script • Inputs are given to Shell Script • Output file is generated when Shell Script is executed • Run a awk program to calculate Delay and Throughput • Plot the Graph using Gnuplot • Compare the Results • Observe the Packet Transfer Process using Network Animator • Calculate Drop Packets due to Collision

5.2.2 Language used TCL and awk scripts

5.2.3 Tools used NS2 and Gnuplot

5.3 How to generate output When the code is executed, we obtain an output file which is a .tr file. Trace file contains event


11

type, time source node, destination node, packet name, packet size, flags, flow id, source address, destination address, sequence no and packet unique id. As the trace files can be very large, so to extract any meaningful information out of them is difficult. Hence we resort text processing tools like awk. AWK is a UNIX based text processing tools and awk programming is like any other high level programming. AWK identifies the strings separated by tabs and spaces on a single line in the text as a single unit and accordingly designates those numbers. We will need to write AWK scripts to calculate end-‐to-‐end delay and throughput.

5.4 How to test against hypothesis By measuring average end-‐to-‐end delay, drop packets and throughput against various no of nodes for different routing protocols like DSDV, AODV, DSR and ZRP.

6. Implementation

6.1 Code The scenarios generated are random and the inbuilt NS procedure module has been used for this purpose. The following is the explanation of the Tcl script. set ns [new Simulator]: Generates an NS simulator object instance, and assigns it to variable. The "Simulator" object has member functions that do the following:

• Create compound objects such as nodes and links • Connect network component objects created (ex. attach-‐agent) • Set network component parameters (mostly for compound objects) • Create connections between agents (ex. make connection between a "tcp" and "sink") • Specify NAM display options etc.

set tracefd [open tracefileName.tr w] $ns_ trace-‐all $tracefd : The first line opens the file ‘ tracefileName.tr ’ for writing and gives it the file handler ' tracefd '. In the second line we tell the simulator object that we created above to write all simulation data into this file. It is similar for NAM file trace data. $ns namtrace-‐all file-‐descriptor: This member function tells the simulator to record simulation traces in NAM input format. It also gives the file name that the trace will be written to later by the command $ns flush-‐trace. Similarly, the member function trace-‐all is for recording the simulation trace in a general format. set topo [new Topography]: Next create a topology object that keeps track of movements of mobilenodes within the topological boundary. Provide the topography object with x and y co-‐


12

ordinates of the boundary, (x=500, y=500). A different value can be passed as a third parameter to load_flatgrid {} as $topo load_flatgrid x y create-‐god $val(nn): God (General Operations Director) is the object that is used to store global information about the state of the environment, network or total number of mobile nodes and a table of shortest number of hops required to reach from one node to another. God object stores the The next hop information is normally loaded into god object from movement pattern files, before simulation begins, since calculating this on the fly during simulation runs can be quite time consuming. However, in order to keep this example simple we avoid using movement pattern files and thus do not provide God with next hop information.First, we need to configure nodes before we can create them. Node configuration API may consist of defining the type of addressing (flat/hierarchical etc), the type of adhoc routing protocol, Link Layer, MAC layer, IfQ etc. set n0 [$ns node]: The member function node creates a mobile node. $node_ (node number) set X_ co-‐ordinate value : This is used to specify the X co-‐ordinate position , similarly we should set Y and Z co-‐ordinate position. $ns_ at time "$node_(1) setdest x coordinate y coordinate speed : It produce some node movements, means at time, node1 starts to move towards the destination (e.g. x=25,y=20) at a speed of ‘k’ m/s (e.g. 15m/s). This API is used to change direction and speed of movement of the mobile nodes. As basic network setup is done, the next thing to do is to setup traffic agents such as TCP, traffic sources such as FTP and attach them to nodes and agents respectively. set tcp [new Agent/TCP]: This line shows how to create a TCP agent. But in general, users can create any agent or traffic sources in this way. Agents and traffic sources are in fact basic objects (not compound objects), mostly implemented in C++ and linked to OTcl. Therefore, there are no specific Simulator object member functions that create these object instances. To create agents or traffic sources, a user should know the class names these objects (Agent/TCP, Agnet/TCPSink, Application/FTP and so on). $ns attach-‐agent node agent: The attach-‐agent member function attaches an agent object created to a node object. Actually, what this function does is call the attach member function of specified node, which attaches the given agent to itself. Therefore, a user can do the same thing by, for example, $n0 attach $tcp. Similarly, each agent object has a member function attach-‐agent that attaches a traffic source object to itself $ns connect agent1 agent2: 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 .


13

proc finish {}: This function is called after this simulation is over by the command $ns at 180.0 "finish". In this function, post-‐simulation processes are specified. We need to define stop time when the simulation ends and tell mobile nodes to reset, which actually resets their internal network components. The nodes are reset at that time and the "$ns_ halt" is called at some specific time, a little later after resetting the nodes. The procedure stop{} is called to flush out traces and close the trace file. $ns run: Command to start the simulation The general template of wireless specifications: #Define options set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-‐propagation model set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(ifq) Queue/DropTail/PriQueue ;# interface queue type set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# antenna modelset val set val(ifqlen) 50 ;# max packet in ifq set val(nn) 8 ;# number of mobilenodes set val(rp) AODV ;# routing protocol set val(x) 500 ; set val(y) 500 ; set val(stop) 180 ; # Initialize Global Variables and create a simulator object set ns_ [new Simulator] set pktsize 500 set tracefd [open AODV8.tr w] $ns_ trace-‐all $tracefd set namfile [open AODV8.nam w] $ns_ namtrace-‐all-‐wireless $namfile $val(x) $val(y) # set up topography object set topo [new Topography] $topo load_flatgrid 500 400 # Create God create-‐god $val(nn) # Create the specified number of mobilenodes [$val(nn)] and "attach" them to the channel.


14

# configure nodes that are created. $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) \ -‐channelType $val(chan) \ -‐topoInstance $topo \ -‐agentTrace ON \ -‐routerTrace ON \ -‐macTrace ON \ -‐movementTrace OFF

for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node]

# disable random motion as we are going to provide node position and movement(speed & direction) directives

} # Provide initial (X,Y, for now Z=0) co-‐ordinates for mobile nodes $node_(0) set X_ 210.0 $node_(0) set Y_ 225.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 285.0 $node_(1) set Y_ 165.0 $node_(1) set Z_ 0.0 $node_(3) set X_ 285.0 $node_(3) set Y_ 90.0 $node_(3) set Z_ 0.0 $node_(2) set X_ 30.0 $node_(2) set Y_ 165.0 $node_(2) set Z_ 0.0 $node_(4) set X_ 30.0 $node_(4) set Y_ 90.0 $node_(4) set Z_ 0.0 $node_(5) set X_ 105.0 $node_(5) set Y_ 225.0 $node_(5) set Z_ 0.0 $node_(6) set X_ 210.0 $node_(6) set Y_ 30.0


15

$node_(6) set Z_ 0.0 $node_(7) set X_ 105.0 $node_(7) set Y_ 30.0 $node_(7) set Z_ 0.0 # node movements $ns_ at 10.0 "$node_(0) setdest 63.0 44.0 3.0" $ns_ at 15.0 "$node_(1) setdest 11.0 71.0 5.0" $ns_ at 30.0 "$node_(0) setdest 60.0 75.0 5.0" $ns_ at 45.0 "$node_(2) setdest 56.0 84.0 5.0" $ns_ at 50.0 "$node_(4) setdest 25.0 71.0 5.0" $ns_ at 60.0 "$node_(5) setdest 29.0 81.0 5.0" $ns_ at 65.0 "$node_(7) setdest 44.0 89.0 5.0" $ns_ at 85.0 "$node_(1) setdest 290.0 381.0 5.0" # Setup traffic flow between nodes set tcp [new Agent/TCP/Newreno] $tcp set class_ 2 $ns_ attach-‐agent $node_(0) $tcp set sink [new Agent/TCPSink] $ns_ attach-‐agent $node_(4) $sink $ns_ connect $tcp $sink set tcp1 [new Agent/TCP] $tcp1 set class_ 3 $ns_ attach-‐agent $node_(4) $tcp1 set sink1 [new Agent/TCPSink] $ns_ attach-‐agent $node_(1) $sink1 $ns_ connect $tcp1 $sink1 set tcp2 [new Agent/TCP] $tcp2 set class_ 4 $ns_ attach-‐agent $node_(2) $tcp2 set sink2 [new Agent/TCPSink] $ns_ attach-‐agent $node_(6) $sink2 $ns_ connect $tcp2 $sink2 set tcp3 [new Agent/TCP] $tcp3 set class_ 5 $ns_ attach-‐agent $node_(1) $tcp3 set sink3 [new Agent/TCPSink] $ns_ attach-‐agent $node_(3) $sink3


16

$ns_ connect $tcp3 $sink3 set tcp4 [new Agent/TCP] $tcp4 set class_ 6 $ns_ attach-‐agent $node_(5) $tcp4 set sink4 [new Agent/TCPSink] $ns_ attach-‐agent $node_(7) $sink4 $ns_ connect $tcp4 $sink4 set ftp [new Application/FTP] $ftp attach-‐agent $tcp $ns_ at 75.0 "$ftp start" set ftp1 [new Application/FTP] $ftp1 attach-‐agent $tcp1 $ns_ at 75.0 "$ftp1 start" set ftp2 [new Application/FTP] $ftp2 attach-‐agent $tcp2 $ns_ at 75.0 "$ftp2 start" set ftp3 [new Application/FTP] $ftp3 attach-‐agent $tcp3 $ns_ at 75.0 "$ftp3 start" set ftp4 [new Application/FTP] $ftp4 attach-‐agent $tcp4 $ns_ at 75.0 "$ftp4 start" for {set i 0} {$i < $val(nn) } {incr i} { $ns_ initial_node_pos $node_($i) 30 } for { set i 0 } { $i < $val(nn) } { incr i } { $ns_ at $val(stop) "$node_($i) reset"; } $ns_ at $val(stop) "$ns_ nam-‐end-‐wireless $val(stop)" $ns_ at $val(stop) "stop" $ns_ at $val(stop).01 "puts \"end simulation\";$ns_ halt" proc stop {} { global ns_ tracefd namfile $ns_ flush-‐trace exec nam AODV84new.nam &


17

close $tracefd close $namfile exit 0 } $ns_ run

7. Data analysis and discussion

7.1 Output generation The following parameters are considered along with the default values of Network Simulator for our comparative study.

Frequency 2.4 GHz

Data rate 1Mbps

RTS Size 20 bytes

CTS Size 14 bytes

Data Packet Size 500 bytes

Ack size 4 bytes

Slot time 20 µs

Mobility Model Random Waypoint

Propagation Model Two way ground

Routing Protocol AODV/DSDV/DSR/ZRP

Simulation Time 180.0 s

Channel Wireless Channel

We simulated the results for four protocols namely, AODV, DSDV, DSR and ZRP for different number of nodes such as 8 nodes, 16 nodes, 32 nodes, 64 nodes and 128 nodes. The following graphs show the average collision, delay and throughput for each of the four protocols. The


18

comparison has been carried out between proactive, reactive protocols and hybrid protocol.

7.1.1 Tracing Objects NS simulation can produce both the visualization trace(for NAM) as well as ASCII file trace corresponding to the events registered in the network. When we use tracing, NS inserts four objects in the link: EnqT, DeqT, RecvT and DrpT. EnqT registers information concerning a packet that arrives and is queued at the input queue of the link. If the packet overflows, then the information concerning the dropped packet are handled by DrpT. DeqT registers information at the instant the packet is dequeued. Finally, RecvT gives us information about packets that have been received at the output of the link.

The meanings of the fields are:

1. The first field is event type. It is given by one of four possible symbols r, +, -‐, d which correspond respectively to received, enqueued, dequeued and dropped.

2. The second field is the time at which the event occurs.

3. Gives the input node of the link at which the event occurs.

4. Gives the output node of the link at which the event occurs.

5. Gives the packet type. The type corresponds to the name that we gave to those applications. For ex, TCP or CBR.

6. Gives the packet size.

7. Some flags.

8. This is the Flow id(Fid) of IPv6 that a user can set for each flow at the input OTcl script. One can further use this field for analysis purpose.

9. This is the source address given in the form of “ node.port”.

10. This is the destination address given in the above mentioned format.

11. This is the network layer protocol’s packet sequence number.


19

12. The last field shows the unique id of the packet.

7.1.2 Working with Trace file Once the Tcl script runs, it generates a trace file with the above mentioned format. Data files can be processed using awk. The awk utility allows us to do simple operations on data files such as averaging the values of the given column, adding or multiplying them by term between several columns, all data reformatting tasks etc.

Sample awkscript for calculating Throughput is shown as below:

Throughput: BEGIN { recvdSize = 0 startTime = 400 stopTime = 0 } { event = $1 time = $2 node_id = $3 pkt_size = $8 level = $4 # Store start time if (level == "AGT" && event == "s" && pkt_size >= 512) { if (time < startTime) { startTime = time } } # Update total received packets' size and store packets arrival time if (level == "AGT" && event == "r" && pkt_size >= 512) { if (time > stopTime) { stopTime = time } # Rip off the header hdr_size = pkt_size % 512 pkt_size -‐= hdr_size # Store received packet's size recvdSize += pkt_size } } END { printf("Average Throughput[kbps] = %.2f\t\t


20

StartTime=%.2f\tStopTime=%.2f\n",(recvdSize/(stopTime-‐startTime))*(8/1000),startTime,stopTime) }

7.1.3 Plotting Graph We are using ‘Gnuplot’ software to plot the graphs. Once we get the value from awk scripts for different performance metrics, we need to keep those values in .txt file with a tabular format. Below are the sample commands for plotting a graph in gnuplot.

set title "ZRP per node Throughput(Kbps)" set xlabel "no of nodes" set logscale x set xtics (8,16,32,64,128) set ylabel "per node throughput(Kbps)" set yrange [0:100] set ytics (10,20,30,40,50,60,70,80,90,100) plot 'Path \ZRPTh.txt' using 1:2 with linespoints title "ZRP"

7.2 Output analysis

7.2.1 AODV A network of 4, 8,16,32,64,128 nodes respectively have been simulated using the reactive protocol AODV. The corresponding values for collision, delay and throughput are tabulated as shown below.

AODV Collision

Table 7.1 Collision values for AODV Graph 7.1 Collision in AODV

Nodes Drop Packets

8 78

16 221

32 524

64 898

128 960


21

AODV Delay

Table 7.2 Delay values for AODV Graph 7.2 Delay in AODV

AODV Throughput

Table 7.3 Throughput values per node for AODV Graph 7.3 Throughput values for AODV

7.2.2 DSDV A network of 8,16,32,64,128 nodes respectively has been simulated using the proactive protocol DSDV. The corresponding values for collision, delay and throughput are tabulated as shown below.

Nodes Delay(ms)

8 446.912

16 580.2

32 881.252

64 1620.34

128 640.912

Nodes Throughput per node (kbps)

8 83.441

16 38.118

32 5.573

64 3.234

128 3.21


22

DSDV Collision

Table 7.4 Collision values for DSDV Graph 7.4 Collision in DSDV

DSDV Delay

Table 7.5 Delay values for DSDV Graph 7.5 Average delay in DSDV

Nodes Drop Packets

8 53

16 117

32 130

64 465

128 547

Nodes Delay(ms)

8 411.282

16 570.785

32 826.57

64 1555.09

128 597.37


23

DSDV Throughput

Table 7.6 Throughput values per node DSDV Graph 7.6 Throughput values per node DSDV

7.2.3 DSR A network of 8,16,32,64,128 nodes respectively have been simulated using the reactive protocol DSR. The corresponding values for collision, delay and throughput are tabulated as shown below.

DSR Collision

Table 7.7 Collision values for DSR Graph 7.7 Collision in DSR

Nodes Throughput per node(kbps)

8 81.43

16 38.31

32 18.619

64 5.94

128 4.191

Nodes Drop Packets

8 66

16 139

32 157

64 447

128 408


24

DSR Delay

Table 7.8 Delay values for DSR Graph 7.8 Delay in DSR

DSR Throughput

Table 7.9 Throughput values per node for DSR Graph 7.9 Throughput values per node in DSR

7.2.4 ZRP A network of 8,16,32,64,128 nodes respectively has been simulated using the hybrid protocol ZRP. The corresponding values for collision, delay and throughput are tabulated as shown below.

Nodes Delay(ms)

8 568.142

16 1066.37

32 1497.57

64 2721.68

128 1065.36

Nodes Throughput per node (kbps)

8 80.65

16 37.256

32 18.434

64 5.642

128 3.58


25

ZRP Collision

Table 7.10 Collision values for ZRP Graph 7.10 Collision in ZRP

ZRP Delay

Table 7.11 Delay values for ZRP Graph 7.11 Delay in ZRP

Nodes Drop Packets

8 53

16 315

32 164

64 162

128 276

Nodes Delay(ms)

8 475.467

16 1014.67

32 1134.02

64 2750.6

128 1273.58


26

ZRP Throughput

Table 7.12 Throughput values per node for ZRP Graph 7.12 Throughput values per node in ZRP

7.2.5 Comparison Graphs The comparison has been carried out between proactive and reactive protocols and the following results have been evaluated.

Graph 7.13 Comparison of Delay

Nodes Throughput per node(kbps)

8 76.1

16 20.70

32 12.12

64 0.365

128 0.024


27

Graph 7.14 Comparison per node throughput

Graph 7.15 Comparison of drop packets

7.3 Compare output against hypothesis • As per the analysis carried out for ZRP, we see the number of drop packets decreases

and also delay is moderate when compare to DSR though there are more number of connections with varying nodes.

• We have analyzed that ZRP gives less throughput in case of higher number of nodes and connections because of overhead caused by the forwarding of query packets

7.4 Abnormal case explanation • While evaluating ZRP protocol in terms of throughput, we noticed that ZRP gives worst


28

throughput (64, 128 in our evaluation) for higher number of nodes when compare to other protocols.

• As per theory for routing protocols, we know that delay increases as the number of nodes increases but we observed that the delay for 128 nodes decreases for all the protocols.

8. Conclusions and Recommendations

8.1 Summary and Conclusions As a result of our analysis, DSR worked out to be an efficient protocol for different node scenarios. DSR being a “on-‐demand” protocol works without any periodic updates, whereas other protocols like DSDV is table driven protocol. Even AODV works well in many scenarios which do not involve too many mobile nodes.

DSR has much higher delay than AODV. DSDV is lesser than AODV, DSR and ZRP

The number of dropped packets in AODV is more than that of the other protocols because of the random mobility of the nodes and its random trajectories.

The performance of DSR with lesser number of nodes is similar to that of AODV and DSDV. But as the number of nodes increases the performance of DSR is better than that of the other two protocols.

In this project, the hybrid protocol ZRP is found to be the moderate for low numer of nodes and low mobility due to its hybrid nature and the capability to adapt to the routing conditions based on the zone radius.

So in Real time scenarios, DSR works much more efficient than other routing protocols.

8.2 Recommendations for future studies In this study we only considered the number nodes as constant throughout the simulation. But this could be varied dynamically so as to make the network scalable.

The various parameters used for propagation model, Link layer, MAC layer, interface queue and the antenna type in the Mobile ad hoc nodes can also be modified so as to evaluate more practical mobile networks.

Future work shall propose a new algorithm to reduce the network load by limiting the number of control packets when the protocol searches for a new route.


29

9. Bibliography

[1] “Performance Evaluation of DSR, OLSR and ZRP Protocols in MANETS”, IEEE published in 2012 [2] “An Efficient Query Packets Forward Algorithm in ZRP Protocol”, IEEE published in 2014 [3] Marc Greis’ Tutorial for the UCB/LBNL/VINT Network Simulator “ns”.

[4] Siting Internet Website : http://www.howstuffworks.com/search.php?terms=802.11

[5] Siting Internet Website : http://www.bluetronix.net/mobile_ad_hoc_networks.htm

[6] Ad-‐hoc, Mobile and Wireless Networks: Second International Conference, ADHOC-‐NOW

2003, Montreal, Canada, October 8-‐10, 2003, Proceedings (Lecture Notes in Computer Science)

[7] Aditya Goel, Ajaii Sharma. “Performance Analysis of Mobile Adhoc Network using AODV

Protocol”.

[8] G. Anastasi , E. Borgia, M. Conti, E. Gregori, “IEEE 802.11 Ad Hoc Networks: Performance

Measurements”, Proceedings of the Workshop on Mobile and Wireless Networks (MWN 2003),

Providence (Rhode Island), May 19, 2003.

[9] IEEE Computer Society LAN MAN Standards Committee,“Wireless LAN Medium Access

Control (MAC) and Physical Layer (PHY) Speci$cations”, IEEE Std 802.11-‐1997. The Institute of

Electrical and Electronics Engineers, New York.

[10] L. Kleinrock, Nomadicity: Anytime, anywhere in a disconnected world, in Mobile Networks

and Applications, vol. 1, pp. 351–357, Baltzer 1996


30

10. Appendices

10.1 Other related material

10.1.1 Awksript Delay: BEGIN { seqno = -‐1; count = 0;

} { if($4 == "AGT" && $1 == "s" && seqno < $6) { seqno = $6; } #end-‐to-‐end delay if($4 == "AGT" && $1 == "s") { start_time[$6] = $2; } else if(($7 == "tcp") && ($1 == "r")) { end_time[$6] = $2; } else if($1 == "D" && $7 == "tcp") { end_time[$6] = -‐1; } } END { for(i=0; i<=seqno; i++) { if(end_time[i] > 0) { delay[i] = end_time[i] -‐ start_time[i]; count++; } else


31

{ delay[i] = -‐1; } } for(i=0; i<=seqno; i++) { if(delay[i] > 0) { n_to_n_delay = n_to_n_delay + delay[i]; } } n_to_n_delay = n_to_n_delay/count; print "\n"; print "Average End-‐to-‐End Delay = " n_to_n_delay * 1000 " ms"; print "\n"; }

Drop Packets: BEGIN { HighestPacketId=0; numberOfSentPackets=0; LowestPacketId=0; numberOfReceivedPackets=0; } { strEvent=$1; strAgt=$4; strType=$7;

Time=$2; idPacket=$6; nBytes=$8; if(strAgt=="AGT" && strType=="tcp" ) { if(idPacket>idHigestPacket) HighestPacketId=idPacket; if(idPacket<LowestPacketId) LowestPacketId=idPacket; if(strEvent=="s") {


32

numberOfSentPackets+=1; } if(strEvent=="r" && idPacket>=LowestPacketId) { numberOfReceivedPackets+=1; } } } END { DropPackets = numberOfSentPackets -‐ numberOfReceivedPackets print "DroppedPAckets = " DropPackets; }

10.1.2 NS Directory Structure Now let’s briefly examine what information is stored in which directory or file. Fig.3.6 shows a part of the directory structure of the simulator available with the ns all in one package.

Among the sub directories of ns-‐allinone, NS2 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 and test/example scripts are located under a sub directory called Tcl. Most of the C++ code which implements event scheduler and basic network component object classes except the www related ones are located in the main level.

Fig.3.6 NS Directory Structure


33

The Tcl directory has sub directories among which the lib directory that contains OTcl source codes for the most basic and essential parts of the NS implementation(agent, node, link, packet, address, routing and etc ) is the place one as a user, or as a developer will visit the most. Note that the OTcl source codes for LAN, Web and multicast implementations are located in separate sub directories of Tcl. Following is a partial list of files in “NS 2/Tcl/lib” directory.

NS-‐lib.Tcl:The simulator class and most of its member function definitions except for LAN, web and multicast related ones are located here. If we want know which member functions of the simulator object class are available and how they work, this is a place to look for.

NS-‐default.Tcl: The default values for configurable parameters for various network components are located here. Since most of network components are implemented in C++, the configurable parameters are actually C++ variables made available to OTcl via an OTcl linkage function, bind(C++_variable_name, OTcl_variable_name).

NS-‐packet.Tcl: The packet header format initialization implementation is located here. When we create a new packet header, we should register the header in this file to make the packet header initialization process to include the header into the header stack format and give the offset of that header in the stack.

Other OTcl files: Other OTcl files in this directory contain OTcl implementation of the compound network objects or the front end(control part) of network objects in C++. The FTP application is completely implemented in OTcl and the source code is located in the “NS-‐source.Tcl”.

Documents

Analysis and Performance evaluation of routing protocols in … › ~mwang2 › projects › MANET_routing... · 2014-12-14 · Analysis!and!PerformanceEvaluation!of! Routing!Protocolsin!MANETS!!!!