PERFORMACE ANALYSIS OF AODV ROUTING PROTOCOL AT VARIOUS FREQUENCIES IN AD-HOC MESH NETWORKS: A SIMULATION STUDY

PERFORMANCE CHARACTERISTICS OF AODV IN A HIGHLY CONSTRAINED WIRELESS ENVIRONMENT: A SIMULATION STUDY

Shwetha Ramasamy

Division of Computing Studies, Arizona State University

sramasam@asu.edu

Abstract - A communication network that handles many-to-many connections and one that is capable of dynamically updating and optimizing these connections is a wireless mesh network (WMN). It is an arrangement of peer-to-peer wireless nodes and access points. The access points form a mesh of self-healing link among themselves. These devices can be deployed in fixed or high speed mobile and internet devices and could be used in gamut of applications ranging from geographical explorations to national surveillance. This technology is mainly aimed towards achieving higher bandwidth network at an inexpensive rate with higher resistance to network congestion and comparatively lower radio interference. It is also intended to offer secure and seamless roaming beyond the capabilities of a tradition WLAN. The IEEE 802.11s Extended Service Set (ESS) Mesh Networking Task Group is working on creating a standard for WMNs and one of the routing protocols that they are considering is Ad-Hoc on Demand distance Vector (AODV). These protocols initiate route discovery only when a route is required and maintain active routes only when they are used, unused routes are deleted. In other words, it discovers and maintains routes on demand. The routing protocols would be evaluated in the forms of metrics like User Datagram Protocol (UDP) traffic by utilizing the Network Simulator (NS2). This project is aimed at analyzing AODV routing protocol at various configurations in different constraints for a set of network topology and mobile nodes.

Index Terms- AODV, NS2, WMN

1. Introduction

A mesh network is a network that employs one of two connection arrangements, full mesh topology or partial mesh topology. A WMN is network that handles many-to-many connections and one that is capable of dynamically updating and optimizing these connections. Mesh network is self-organizing and simple enough so that users are able to deploy, and maintain with limited technology experience. Mesh networking technology also provides numerous and unique capabilities that can facilitate the deployment of public access wireless networks, as it enables higher reliable Internet access services by providing a fault tolerant infrastructure and redundant access links with respect to traditional wired methods. Moreover, wireless mesh networks enable advanced applications/services through ubiquitous access and reliable connectivity. The dynamic management of complex routing procedure includes information about external networks. AODV was designed specifically for wireless mobile nodes communicating in an ad-hoc fashion to find routes on an as needed basis with minimal route acquisition latency and control overhead. A wireless mesh network can be visualized as a type of wireless ad hoc network which does not experience direct mobility and they are considered to be static. WMNs diversify the capabilities and functionalities of ad-hoc networks. Based on the architecture [1], wireless mesh networks could be classified into three types:

Infrastructure/Backbone: These can be built using various types of radio technologies, besides to the mostly used IEEE 802.11 technologies. The mesh routers form a mesh of self-configuring, self-healing links among themselves. The work proposed in [5] uses AODV to form a new concept from existing networks called localized self healing community, such a network tries to mitigate the adverse effects caused by malicious nodes by distributing the network service to other members. With gateway functionality, mesh routers can be connected to the Internet.

Client: In this architecture the client nodes constitute the actual network to perform routing and configuration functionalities as well as providing end-user applications to customers. Hybrid: This is a combination of infrastructure and client meshing and they can access the network through mesh routers and mesh clients.

Figure 1[1] Hybrid WMNs

The authors in [14] have discussed methods to aid researchers to develop on demand protocols and assisted users in determining the implementation design that fits their needs. The projects aim is to provide a better understanding of some research challenges like throughout value for a scenario of developed network topology. Some of the factors that are be taken into consideration are as follows: 1. Packet Delivery Ratio: Ratio of packets delivered to that transmitted by the source. 2. Changing the HELLO packet intervals 3. Changing the Network_Diameter 4. Changing the Allowed HELLO Loss and 5. Changing the Active_Route_ Timeout.

Working of AODV

The AODV Routing protocol uses an on-demand approach for finding routes, that is, a route is established only when it is required by a source node for transmitting data packets. It employs destination sequence numbers to identify the most recent path. AODV offers quick adaptation to dynamic link conditions, low processing and memory overhead, low memory utilization, and determines unicast routes to destinations within adhoc network. The major difference between AODV and Dynamic Source Routing (DSR) is that DSR uses source routing in which a data packet carries the complete path to be traversed. The message types defined by the AODV protocol are Route Requests (RREQs), Route Replies (RREPs) and Route Errors (RERRs). However, in AODV, the source node and the intermediate nodes store the next-hop information corresponding to each flow for data packet transmission. In an on-demand routing protocol, the source node floods the RREQ packet in the network when a route is not available for the desired destination. It may obtain multiple routes to different destinations from a single RouteRequest. The major difference between AODV and other on-demand routing protocols is that it uses a destination sequence number (DestSeqNum) to determine an up-to-date path to the destination. A node updates its path information only if the DestSeqNum of the current packet received is greater than the last DestSeqNum stored at the node.

A node offers connectivity information by broadcasting local Hello messages as follows.[6] During every Hello interval milliseconds, the node checks whether it has sent a broadcast within the last Hello_Interval. If it has not sent one, it broadcasts a RREP with TTL = 1, called a Hello message, with the RREP message fields set as follows: The destination IP Address would be the node's IP address, the destination Sequence Number would be the node's latest sequence number. The value of hop count would be the Lifetime Allowed_Hello_Loss * Hello_Interval. AODV makes sure these routes do not contain loops and tries to find the shortest possible route. AODV is also handles changes in routes and can create new routes if there is an error. These message types are received via UDP, and normal IP header processing is applied. So, the requesting node is expected to use its IP address as the Originator IP address for the messages. For broadcast messages, the IP limited broadcast address (255.255.255.255) is used. AODV operation does require certain messages (RREQ) to be disseminated widely. The range of dissemination of such RREQs is indicated by the TTL in the IP header.

Figure 2 shows a set of nodes on a wireless network. Circles represent the communication range for each node. Due to limited range, each node can only communicate with the nodes next to it.

. Figure 2 [2] Packet Broadcast in the AODV protocol

Nodes which could communicate with directly are considered to be Neighbors. A node keeps track of its Neighbors by listening for a HELLO message that each node broadcast at set intervals. When one node needs to send a message to another node that is not its Neighbor it broadcasts a RREQ message. The RREQ message contains several key bits of information: the source, the destination, the lifespan of the message and a Sequence Number which serves as a unique ID. In Figure 2, [2] Node 1 wishes to send a message to Node 3. Node 1s Neighbors are Nodes 2 + 4. Since Node 1 cannot directly communicate with Node 3, Node 1 sends out a RREQ. The RREQ is heard by Node 4 and Node 2. When Node 1s Neighbors receive the RREQ message the nodes have two choices; if they know a route to the destination or if they are the destination they can send a RREP message back to Node 1, otherwise the nodes will rebroadcast the RREQ to their set of Neighbors. The message keeps getting rebroadcast until its lifespan is up. If Node 1 does not receive a reply in a set amount of time, it will rebroadcast the request except at this time the RREQ message will have a longer lifespan and a new ID number. In AODV, the network is silent until a connection is required. The network node that needs a connection broadcasts a request for connection. Other AODV nodes forward this message, and record the node that they received it from, creating an explosion of temporary routes back to the node which requires the connection. This node then begins using the route that has the least number of hops through other nodes. Unused entries in the routing tables are recycled after a time. The main advantage of this protocol is that routes are established on demand and destination sequence numbers are used to find the latest route to the destination. The connection setup delay is less. AODV provides loop-free routes even while repairing periodic routing advertisements, the demand on the overall bandwidth available to the mobile nodes is substantially less than in the protocols that do necessitate such advertisements.

The Network Scenario

AODV [8] borrows route establishment and maintenance mechanisms from DSR [9] (Dynamic Source Routing) Protocol and sequence numbers and hop-to-hop routing from DSDV [10] (Destination Sequenced Distance Vector) protocols. This project, as described in this paper, only uses AODV for unicast route establishment. This project was initially started by developing a wired environment and the simulation was studied for a defined set of 9 nodes. Node 3, 4, 5, and Nodes 6, 7, 8 are sources and they are attatched to sinks 2 and 1 respectively. Figure 3 shows the packets travelling from the sources to the final sink 0. Sinks 2 and 1 now act as sources when they collect the packets from their neighbbour sources and transfer them to sink 1.

Simulations Conditions

The major constraints was testing with a date size of 100 Kilobytes / second (0.1 Megabyte / second). The data size is the product of packet size x number of packets transmitted / sec. To acheive this data size, we had to choose the values of packet size and number of packets transferred / second.

Default scenario:

500 packet size x 200 bits /sec

0.8 Mb / sec

Our scenario:

Keeping bits constant:

Packet Size X 200 bits = 0.1 Mb / sec

Packet Size = 62.5 bytes.

Keeping packet size contant:

500 X Bits = 0.1 Mb / sec

Bits = 25 packets.

Interval : 0.04.

A UDP agent is crated and attached to the source nodes, and a constant bit rate (CBR) traffic generates traffic to the UDP agent. According to our above calculations, the packet size is being set to 500 bytes and a packet will be sent every 0.04 seconds (that is, 25 packets per second). The CBR acts as the application layer in our topology. A duplex link is attached to the nodes to make it a wired network and that enhances the traffic flow between the nodes. A Null agent is attached to the sink and then the sources and the sink are connected to one another to generate the flow of traffic between the nodes. The graphs are plotted with total packets on y axes and time in the x axis.

Figure 3. Wired Network and Packets Passing to Sink 0.

Figure 4 Network Throughput Graph of AODV at 500 bits / sec and 25 packets

Wireless Scenario

To implement AODV, a wireless scenario was configured with a similar set of 9 nodes. The nodes move about within an area whose boundary is defined in this example as 800mX800m. A mobile node consists of network components like Link Layer (LL), Interface Queue (IfQ), MAC layer, the wireless channel nodes transmit and receive signals.

At the beginning of a wireless simulation, the types for each of these network components have to be defined. The type of antenna, the radio-propagation model, sand the type of routing protocol used by mobile nodes is some of the other parameters that are defined. Random traffic connections of UDP and CBR are setup between mobile nodes using a traffic-scenario generator script. We create CBR and UDP traffics connections between wireless mobile nodes.

Figure 5 The AODV packets flowing between the nodes at the set time interval.

To create a traffic-connection file, the type of traffic connection, the number of nodes and maximum number of connections to be setup between them, a random seed and incase of CBR connections, a rate whose inverse value is used to compute the interval time between the CBR packets are defined. We performed the simulation using the NS2 [4] simulator.

The node-configuration for a wireless, mobile node than runs AODV as its ad-hoc routing protocol is as shown below:

$ns_ node-config -addressType hierarchical \

-adhocRouting AODV \

-llType LL \

-macType Mac/802_11 \

-ifqType Queue/DropTail/PriQueue \

-ifqLen 50 \

-antType Antenna/OmniAntenna \

-propType Propagation/TwoRayGround\

-phyType Phy/WirelessPhy \

-topologyInstance $topo \

-channel Channel/WirelessChannel \

-agentTrace ON \

-routerTrace ON \

-macTrace OFF \

-movementTrace OFF

The default values for all the above options are NULL except addressing type whose default value is flat.

AODV routing process

The header files present in the standard ns2 directory has certain files which define various parameters as follows:

aodv.hTiming and structures for route table

aodv_packet.hStructure for AODV packet formats

There are some external files which provide support for the function implementation which are related to the above header files and they are related as follows:

aodv.haodv_rtable.h

aodv_rtable.cc

aodv_packet.haodv_rqueue.cc

aodv_rqueue.h

aodv_rqueue.o

Certain changes have been made to the packet formats in the header files and their respective external support file functions. The external files have functions which allocate memory for the packet formats create pointers and eventually free the memory. The RREQ and RREP are the packets that carry hop count information. This mutable information is protected via hash chains.

Type: Indicates the type of packet as an integer

Length: The length in bytes of the extension excluding the type and length field.

Hash_Function: An integer value for the type of hash function used.

Max_Hop_Count: The TTL value from the IP header.

Top_Hash: Repeated hash of the hop count for verification.

Hash: Hash of the hop count

The Hello Protocol is responsible for establishing and maintaining neighbor relationships. It also ensures that communication between neighbors is bidirectional. Hello packets are sent periodically to out all the network router interfaces. Bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello packet. The Hello packets are sent out each functioning router interface. They are used to discover and maintain neighbor relationships. The following page shows the node traversal scenario at different position during the course of their movements across the nodes.

Figure 9 showing movement from source to sink

Red bubble shows the source packets

Figure 10 showing some initial packet drops

Figure 11 showing significant packet burstsFigure 12 showing two nodes overlap of 2 nodes Red bubble indicate the overlap

Figure 13 showing Dual packet burst

Figure 14 showing distinct packet drops

Figure 15 Network Throughput Graph by changing AODV Hello_Interval to 1 second

Figure 15 shows the graph plotted for the default AODV Hello_Interval. The graphs are plotted with total packets on y axes and time in the x axis. The graph in Figure 16 and 17 shows the throughput by changing the Hello interval to 2 and 3 seconds respectively. From the above plots, it could be inferred that the packets received decreases with the change in the Hello interval time. The total traffic is forwarded by the wireless LAN MAC layers to the higher layers in all the nodes in the network. It was also observed that AODV requires more overhead for discovering routes. The number of packets received and the number of packets lost could be found from the trace file at that particular time interval. Also they were plotted using the X-graph tool available in the NS2. The next parameter that was studied and monitored was the network diameter. It is the average minimum distance between two pair of nodes. Net_Diameter actually refers to the maximum possible number of hops between two nodes in the network. Mobile nodes in ad hoc networks may change values of certain parameters, in particular the Net_diameter and Node_Traversal values. These parameters may affect the robustness of the flooding operation; however there is not a considerable change in the throughput values. Each node in the ad hoc network is enabled to retransmit flooded packet that it receives. There might be some additional control signaling which reduces the number of nodes that perform the retransmission. This reduces the overall bandwidth consumption and congestion which could have been caused by excessive flooding.

Figure 16 Network Throughput Graph by changing AODV Hello_Interval to 2 second

Figure 17 Network Throughput Graph by changing AODV Hello_Interval to 3 second.

Figure 18 Allowed Hello Loss for the Value of 3 packets

Figure 19 Allowed Hello Loss for the Value of 5 packets

The value of lifetime field for Hello Packets is Allowed_Hello_Loss. This was performed for 9 nodes making one of the nodes mobile and then by varying the Allowed_hello_loss parameter. The figure 18 and 19 shows the Allowed_Hello_Loss graph for the values. The X-graph shows that as the value of the packets received and value of packets loss changes when the Allowed_Hello_Loss parameter is varied. The packets received in the latter case is less and the packets lost are more than the default Allowed_hello_loss value.

The next parameter that was analyzed was by increasing the value of Active_Route_Timeout parameter. Active_Route_Timeout is a static parameter that defines how long a route is kept in the routing table after the last transmission of a packet on this route. This parameter is arbitrarily set to 10 seconds. In the case of reactive ad hoc network routing, the protocols attempt to minimize the route discovery overhead by caching the route information for some period of time after a connection expires. Figures 20 and 21 show the graph plotted by changing the value of Active_Route_Timeout. The route discovery time for AODV when applied to this networks show that for up to about 9 nodes the AODV has different set of values for different values of Active_route_Timeout. The graphs are, like the rest of the above conditions, plotted with total packets on y axis and time in the x axis. The number of packets received in this is less in the first case when the active_route_timeout was 10 seconds than in the second case when the value was increased to 30 seconds. So with increasing timeout values, the packets received also increases and the packtes lost decreases.

Figure 20 Active_Route_Timeout for the Value of 10 seconds

Figure 21 Active_Route_Timeout for the Value of 30 seconds

CONCLUSION

The area of ad hoc networking has been receiving increasing attention among network researchers in recent years. Many of the proprietary WMN devices (backhaul routers) made by commercial vendors, like BelAir, Tropos, Strix Systems, Cisco and Nortel, perform routing based on protocols which derive from AODV [13], which is a popular on-demand reactive protocol researched and used extensively in MANETs. The IEEE 802.15.4 [12] standard is expected to enable a wide variety of envisaged low-cost control and monitoring applications with relaxed throughput requirements and a strong emphasis on power conservation. This has been accompanied by an increasing availability of implementations for different operating systems. However, it has been largely unknown how such implementations perform against each other and how different design decisions affect the performance of transport protocols. Some of the major constraints in this were the selective transmission of data packets which were allowed to be transmitted through the nodes. Some standard default AODV values were changed and observed the network of 9. The project was performed by introducing some changes to the existing AODV set-up and UDP was used as the transport protocol. With an increase in value of Hello_packet, the packets received decreases and packets lost increases. The packets received increases and that lost decreases when the Allowed_Hello_Lost values are increased from 3 to 5 packets. The packets received decreases and lost increases when the Active_Route_Timeout was increased from 10 to 30 seconds. To increase the effectiveness of hello messages, their reception characteristics should be equal to that of data packets. The reception of hello messages will indicate that reception of data packets will occur, and better throughput will result.

FUTURE WORK

The authors in [11] have suggested that AODV is a promising candidate for WMNs, which needs to service a large number of mobile clients with low latency and high bandwidth requirements. However, the authors in [7] have suggested that to improve the performance of AODV, they have modified AODV to include the source route accumulation feature of DSR. This is known AODV with path accumulation.

REFERENCES

[1] Ian F. Akyildiz, A Survey on Wireless Mesh Networks, IEEE Radio Communications, Sept.2005

A Survey on wireless mesh networks http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/35/32334/01509968.pdf?temp=x[2] Luke Klein-Berndt Wireless Communications Technology group - A Quick Guide To AODV Routing, http://w3.antd.nist.gov/wctg/aodv_kernel/aodv_guide.pdf[3] The Network Simulator manual

[4] The Network Simulator (NS2) website, http://www.isi.edu/nsnam/ns/ns-build.html[5] J.Kong, X.Hong, Y.Yi, J.-S.Park, J.Liu, M.Gerla, A Secure Ad-hoc Routing Approach using Localized Self-healing Communities, Proc. Of ACM MobiHoc, 2005.

[6] Charles E. Perkins Mobile Ad Hoc Networking Working Group - Nokia Research Center, Ad hoc On-Demand Distance Vector (AODV) Routing.

[7] Gwalani, S, AODV PA: AODV with path Accumulation, Communications, 2003. ICC '03. IEEE International Conference Volume 1, 11-15 May 2003

[8] C.E.Perkins, E.M.Royer, Ad-hoc On-Demand Distance Vector Routing, Proc. Of ACM, 2002.

[9] D.Johnson, Y.Hu, D.Maltz, Dynamic Source Routing (DSR) Protocol, ftp://ftp.rfc-editor.org/in-notes/rfc4728.txt, Feb.2007

[10] C.E.Perkins, P.Bhagwat, Highly dynamic Destination Sequenced Distance Vector Routing (DSDV) for mobile computers, in Proc. Of ACM SIGCOMM, p.g. 234-244, 1994

[11] Asad Amir Pirzada, Marius Portmann, Jadwiga Indulska, Performance analysis of multi-radio AODV in hybrid wireless mesh networks, Volume 31 , Issue (March 2008), Pages 885-895 http://portal.acm.org/citation.cfm?id=1349996[12] C Gomez, P Salvetella, O.Olonso, J Paradells, Adapting AODV for IEEE 802.15.4 Mesh Sensor Networks:Theoretical Discussion and Performance Evaluation in a Real Environment International Workshop on Wireless Mobile Multimedia,Proceedings of the 2006 International Symposium on on World of Wireless, Mobile and Multimedia Networks

[13] C.E.Perkins, E.Belding-Royer, S.R.Das, Ad-Hoc On Demand Distance Vector (AODV) routing IETF RFC 3561, July 2003.

[14] Ian D Chakeras, Elizebeth M Belding Royer AODV Routing Protocol Implementation Design http://moment.cs.ucsb.edu/pub/wwan_chakeres_i.pdfACKNOWLEDEMENT

The author would like to thank Dr Bruce Millard, Professor of Practice, Division of Computing Studies, ASU Polytechnic, for his support and guidance throughout this project work. The author also would like to thank Dr Tim Lindquist and Dr Alan Skousen, both Professors of Practice in the Division of Computing Studies for having agreed to be in the graduation committee.

Bio: Shwetha Ramasamy graduated from the SRM Engineering College, University of Madras, India with a bachelors degree in Instrumentation & Control Engineering in 2004. She joined Arizona State University at the East Campus in Spring 2007, majoring in Computing Systems and would be completing her Masters degree in Fall 2008. Her research interests include Networking, Web development and Object Oriented programming.