Communication Networks University of Bremen Prof. Dr. rer. nat. habil. C.

Grg

Mini project

Performance Analysis of Ad hoc On-demand Distance Vector routing (AODV) using OPNET Simulator
Of

Anipakala Suresh
Bremen, 11th April 2005

Supervised by: Prof. Dr. rer. nat. habil. C. Grg Koojana Kuladinithi

Ich versichere, da die vorliegende Arbeit bis auf die offizielle Betreuung durch den Lehrstuhl ohne Fremde Hilfe von mir durchgefhrt wurde. Die verwendete Literatur ist im Literaturverzeichnis vollstndig angegeben. I certify that I have conducted this work on my own and no other supporting material has been used other than those which are listed as references. Bremen, den 8. April 2005

(Anipakala Suresh)

ABSTRACT

An ad hoc network is an instantly deployable wireless network that does not require the services of any networking infrastructure such as base stations or routers. A key feature of these networks is their ease of deployment that makes it ideally suitable for battlefield, search and rescue and disaster relief operations. These networks can operate on a single-hop or multi-hop basis where nodes in the network are able to act as intermediaries (routers) for communications of other nodes. Nodes in these networks operate with power limited batteries, and the bandwidth is constrained as these are wireless networks. MANET (Mobile Ad hoc NETworks) which is a working group at the Internet Engineering Task Force (IETF) focuses on developing the standards for these networks. One of the MANET standardized ad hoc networking protocols is Ad hoc On-demand Distance Vector routing (AODV) which was published as a RFC in 2003 (RFC 3561). There are several implementations and simulators are available for AODV protocol. In this work, performance analysis of AODV networks using the OPNET simulator was done. AODV model was added to the OPNET simulator very recently (version 10.5 released in 2004). Several simulations of AODV networks in OPNET were done to investigate the behavior of transport layer protocols, both UDP and TCP when using in AODV networks. Results were analyzed for both UDP and TCP separately. Unidirectional video streaming was used to analyze the UDP communication, while TCP performance was analyzed using file downloads via FTP (File Transfer Protocol).

KURZFASSUNG

Ein Ad-Hoc-Netz ist ein sofort einsetzbares drahtloses Netz, das keine Dienste einer Netzinfrastruktur, wie Basisstationen oder Router, bentigt. Eine Schlsselkomponente dieser Netze ist ihre einfache Aufstellung, die es ideal fr den Einsatz auf Schlachtfeldern, fr Rettungsdienste sowie Katastropheneinstze macht. Diese Netze knnen auf der Basis von Ein- oder Multi-Hop arbeiten. Bei Letzterem sind Knoten im Netz Mittelsmnner (Router) fr die Kommunikation anderer Knoten. Beschrnkungen in solchen Netzen sind gegeben durch eingeschrnkte Batterieleistung und eine gegebene Bandbreite des drahtlosen Netzes. Eine Arbeitsgruppe der Internet Engineering Task Force (IETF) mit dem Namen MANET (Mobile Ad hoc NETworks) entwickelt Standards fr diese Netze. Einer der Standards fr Ad-Hoc-Netz-Protokolle, mit denen sich MANET beschftigt, ist Ad Hoc on-demand Distance Vector (AODV), welches als Request For Comment (RFC) im Jahr 2003 verffentlicht worden ist. Es sind diverse Implementierungen und Simulatoren fr das AODV-Protokoll verfgbar. Im Rahmen dieser Arbeit wurde eine Leistungsanalyse eines AODV Netzes mit Hilfe von OPNET durchgefhrt. Das AODV Modell wurde vor Kurzem dem OPNET Simulator in der Version 10.5, die im Jahr 2004 verffentlicht wurde, hinzugefgt. Zahlreiche Simulationen des AODV-Protokolls mit OPNET wurden durchgefhrt, um das Verhalten der Transportschicht, sowohl von TCP als auch von UDP, in AODVNetzen zu untersuchen. Die Ergebnisse wurden fr UDP und TCP getrennt ausgewertet. Uni-Direktionales Video-Streaming wurde benutzt um die UDP-Kommunikation zu analysieren, whrend die TCP-Leistungsfhigkeit anhand von Datei-Downloads mittels FTP analysiert wurde.

TABLE OF CONTENTS

1. 2.

3.

4.

5. 6. 7. 8.

Introduction ............................................................................................................................9 Overview to Ad hoc On-demand Distance Vector routing (AODV) ......................................11 2.1 Properties of IEEE 802.11b (WLAN).............................................................11 2.1.1 Hidden Station Problem ..........................................................................11 2.1.2 Exposed Station Problem ........................................................................12 2.1.3 Basic Access Method: CSMA/CA ..........................................................12 2.2 Basic Operations of AODV ............................................................................14 2.2.1 Path Discovery ........................................................................................14 2.2.2 Route Table Management .......................................................................16 2.2.3 Link Breakage .........................................................................................17 2.2.4 Path Maintenance ....................................................................................17 2.2.5 Local Connectivity Management ............................................................17 2.2.6 Local repair .............................................................................................18 OPNET Simulation Environment..........................................................................................19 3.1 OPNET Architecture.......................................................................................19 3.2 MANET Model Architecture in OPNET ........................................................19 3.2.1 Node Models in MANET........................................................................20 3.2.2 AODV Model Files .................................................................................21 3.3 Configuring AODV in OPNET.......................................................................22 3.4 Taking results of AODV .................................................................................23 Modelling of AODV networks and Analysis of Results .........................................................25 4.1 Modelling an AODV network.........................................................................25 4.2 Generating UDP traffic ...................................................................................26 4.2.1 Configuring the Task Configuration Object ...........................................26 4.2.2 Configuring the Application Config Object............................................27 4.2.3 Configuring the Profile Configuration Object ........................................28 4.3 Generating TCP traffic....................................................................................30 4.4 Configuring the mobile node ..........................................................................32 4.5 Analysis of UDP Results.................................................................................34 4.5.1 AODV Routing Traffic ...........................................................................34 4.5.2 IP Traffic .................................................................................................35 4.5.3 UDP Traffic.............................................................................................36 4.6 Analysis of TCP results...................................................................................38 4.6.1 AODV routing traffic ..............................................................................38 4.6.2 IP traffic ..................................................................................................39 4.6.3 TCP traffic...............................................................................................40 4.6.4 Congestion Window Size........................................................................40 Simulation Results Vs Test-bed Results ..............................................................................43 Conclusion ...........................................................................................................................47 LIST OF FIGURES ..............................................................................................................49 Reference ............................................................................................................................51

CHAPTER 1

1. Introduction
A Mobile Ad hoc NETwork (MANET) [1] is a set of wireless mobile nodes forming a dynamic autonomous network. Nodes communicate with each other without the intervention of centralized access points or base stations. In such a network, each node acts both as a router and as a host. Due to the limited transmission range of wireless network interfaces, multiple hops are needed to exchange data between nodes in the network. Ad hoc On-demand Distance Vector routing (AODV) [2] is one of the most popular reactive type of MANET protocols. In this work, the performance of the AODV routing protocol was analyzed when using UDP and TCP based applications. This analysis was done using the MANET model in OPNET simulator [5]. OPNET Simulator is the industrys leading simulator specialized for network research and development. It allows to design and study communication networks, devices, protocols, and applications with great flexibility. It provides a graphical editor interface to build models for various network entities from physical layer modulator to application processes. All the components are modeled in an object-oriented approach which gives intuitive easy mapping to your real systems. MANET model is integrated to the basic OPNET modeler to simulate ad hoc routing protocols of AODV, DSR (Dynamic Source Routing) and TORA (Temporally Ordered Routing Algorithm) [2]. This report consists of the following chapters: Chapter 2- Overview to AODV protocol: This chapter details the operation of AODV and discusses the properties of IEEE 802.11b wireless technology that has been used in this simulation. Chapter 3- OPNET Simulator: This chapter explains about model architecture of OPNET simulator in general and MANET models. It also addresses how to configure AODV parameters in OPNET and how to obtain the results of AODV using this simulator. Chapter 4- Modeling of an AODV network and Analysis of Results: This chapter details how to model 5 nodes AODV network and how to generate applications based on UDP and TCP protocols. It also discusses the results of this 5 nodes AODV network, when using UDP and TCP based applications. Chapter 5- Simulation results Vs Test bed results: Simulated results that are analyzed in the above chapter are compared with the test-bed results that were taken previously. Chapter 6 Conclusion: This concludes the report and discusses the future work

CHAPTER 2

2. Overview to Ad hoc On-demand Distance Vector routing (AODV)

Ad hoc On-demand Distance Vector Routing (AODV) [2] is a novel algorithm for the operation of ad hoc networks. Each mobile node operates as a specialized router and routes are obtained as needed i.e. on-demand with little or no reliance on periodic advertisements. The new routing algorithm is quite suitable for a dynamic self-starting network as required by users wishing to utilize ad hoc networks. AODV provides loop free routes even while repairing broken links. Because the protocol does not require global periodic routing advertisements, the demand on the overall bandwidth available to the mobile nodes is substantially less than in those protocols that do necessitate such advertisements. AODV can be called as a pure on-demand route acquisition system, in this nodes do not lie on active paths neither maintain any routing information nor participate in any periodic routing table exchanges. Further, a node does not have to discover and maintain a route to another node until it needs to communicate. To maintain the most recent routing information between nodes the concept of destination sequence numbering will be used. Each ad hoc node maintains a monotonically increasing sequence number counter which is used to supersede stale cached routes. The first section of this chapter details the properties of WLAN (IEEE 802.11x) [7] that will mostly be used in ad hoc networks to make the physical connections directly between two nodes. IEEE 802.11b is used in the simulation. The next section details all the operations of AODV as defined in RFC 3561 [2]. 2.1 Properties of IEEE 802.11b (WLAN)

A system of portable computers that communicate by radio can be regarded as a wireless LAN. These LANs have some what different properties than conventional LANs and require special MAC sub layer protocols. Conventional LAN protocol is not appropriate for WLAN because what matters is interference at the receiver, not at the sender. Conventional LAN protocol in WLAN leads to two kinds of problems are called hidden station problem and exposed station problem [6]. 2.1.1 Hidden Station Problem Consider the four stations A, B, C, D as shown in figure, in which A and B are within each others radio range and can potentially interfere with one another. C can also potentially interfere with both B and D, but not with A.

12

2 Overview to Ad hoc On-demand Distance Vector routing (AODV)

Figure 2-1 A Wireless LAN with station A is transmitting (Hidden Station Problem)

First consider what happens when A is transmitting to B as depicted in figure 2-1. If C senses the medium, it will not hear A because A is out of range of C, and thus falsely conclude that it can transmit. If C does start transmitting, it will interfere at B, wiping out the frame from A. The problem of a station not being able to detect a potential competitor for the medium because the competitor is too far away is called as the hidden station problem. 2.1.2 Exposed Station Problem Now let us consider B is transmitting to A as shown in figure 2-2. If C senses the medium, it will hear an ongoing transmission and falsely conclude that it may not send to D, when in fact such a transmission would cause bad reception only in the zone between B and C, where neither of the intended receivers is located. This situation is called as the exposed station problem.

Figure 2-2 Wireless LAN with station B is transmitting (Exposed Station Problem)

2.1.3 Basic Access Method: CSMA/CA The basic access mechanism used in WLAN is CSMA/CA (Carrier Sense Multiple Access/ Collision Avoidance) together with the Distributed Coordination Function (DCF). DCF uses RTS (Request To Send) and CTS (Clear To Send) signals to reduce the possibility of collisions caused by the hidden station problem [6]. To avoid the exposed station problem, a node must wait a random backoff time between two consecutive new packet transmissions time. The mechanism works as in the following paragraphs.

2.1 Properties of IEEE 802.11b (WLAN)

13

A station in the wireless network that wants to transmit data performs a carrier sense of the medium first. If the medium is idle, it waits a time period of a DCF (Distributed Coordination Function) Inter Frame Spacing (DIFS), which is a time period a station has to wait before sensing the medium again. If the medium is idle again after this DIFS period, data will be transmitted immediately. The receiver of data waits a Short Inter Frame Spacing (SIFS). After the SIFS, an Acknowledgement ACK is replied back to the sending station. During the time when a station has access to the medium, all other stations are deferring access [7]. Otherwise, if the sender had sensed the medium busy it had to wait a DIFS and after that entered the contention phase. In this contention phase, each station has to generate a random backoff time and wait for this time period. The contention period is counted in slots and after each elapsed slot the backoff value is counted down, but only when the medium is idle. If the medium is idle after the backoff time period, a station has to wait a DIFS as described above and transmit after that if it is still idle. Virtual Carrier Sense: A station willing to transmit a packet will first transmit a short control packet called RTS (Request To Send), which will include the source, destination and the duration of the following transaction and the destination station will respond with a response controlled packet called CTS (Clear To Send) if the medium is free, which will include the same duration information. All stations receiving either the RTS or the CTS will set their Virtual Carrier Sense indicator called NAV (Network Allocation Vector) for the given duration and is used to indicate how long the medium will be reserved.

Figure 2-3 WLAN CSMA/CA medium access scheme

14

2 Overview to Ad hoc On-demand Distance Vector routing (AODV)

2.2

Basic Operations of AODV

This section explains each process that is required in an AODV [2] network to create, delete and maintain routes. 2.2.1 Path Discovery The Path Discovery process is initiated whenever a source node needs to communicate with another node for which it has no routing information in its table. Every node maintains two separate counters: a node sequence number and a broadcast id. The source node initiates path discovery by broadcasting a route request (RREQ) packet to its neighbors. The RREQ contains the following fields. Source address Source sequence number Broadcast ID Destination address Destination sequence number Hop count The pair source address and broadcast ID uniquely identifies a RREQ. Broadcast ID is incremented whenever the source issues a new RREQ. Each neighbor either satisfies the RREQ by sending a route reply (RREP) back to the source or re-broadcasts the RREQ to its own neighbors after increasing the hop count. Notice that a node may receive multiple copies of the same route broadcast packet from various neighbors. When an intermediate node receives a RREQ, if it has already received a RREQ with the same broadcast ID and source address, it drops the redundant RREQ and does not rebroadcast it. Reverse path setup: There are two sequence numbers included in a RREQ: the source sequence number and the last destination sequence number known to the source The source sequence number is used to maintain freshness information about the reverse route to the source and the destination sequence number specifies how fresh a route to the destination must be before it can be accepted by the source. As shown in the Figure 2-4, when the source node S determines that it needs a route to the destination node D and does not have the root available. Immediately node S starts broadcasting RREQ (Route Request) message to its neighboring nodes in quest of route to the destination. The nodes 1 and 4 being as neighbors to the node S receive the RREQ message. And nodes 1 and 4 create a reverse link to the source from which they received RREQ. Since the nodes 1 and 4 not aware of the link to the node D, they simply rebroadcast this RREQ to their neighboring nodes 2 and 5. As the RREQ travels from a source to various destinations, it automatically sets up the reverse path from all nodes back to the source as shown in Figure 2-4. This reverse route will be needed if the node receives a RREP back to the node that originated the RREQ. Before broadcasting the RREQ, the originating node buffers the RREQ ID and the originator IP address. In this way, when the node receives the packet again from its neighbors, it will not reprocess and re-forward the packet.

2.2 Basic Operations of AODV

15

D 3

3 2 2 Timeout 1

1
Ss ss

S 4 5 4 5

Reverse path
Figure 2-4 Reverse Path Setting

Forward path
Figure 2-5 Forward Path setting

Forward Path setup: Eventually, a RREQ will arrive at a node that possesses a current route to the destination or the destination itself. The receiving node first checks that the RREQ was received over a bi-directional link. If an intermediate node has a route entry for the desired destination, it determines whether the route is current by comparing the destination sequence number in its own route entry to the destination sequence number in the RREQ. If the RREQs sequence number for the destination is greater than that recorded by the intermediate node, the intermediate node must not use its recorded route to respond to the RREQ. Instead the intermediate node rebroadcasts the RREQ. The intermediate node can reply only when it has a route with a sequence number that is greater than or equal to that contained in the RREQ. If it does have a current route to the destination and if the RREQ has not been processed previously, the node then unicasts a route reply packet (RREP) back to its neighbor from which it received the RREQ. A RREP contains the following information. Source address Destination address Destination sequence number

16

2 Overview to Ad hoc On-demand Distance Vector routing (AODV)

Hop count Lifetime

By the time a broadcast packet arrives at a node that can supply a route to the destination, a reverse path has been established to the source of the RREQ. As the RREP travels back to the source each node along the path sets up a forward pointer to the node from which the RREP came, updates its timeout information for route entries to the source and destination, and records the latest destination sequence number for the requested destination. Figure 2-2 represents the forward path setup as the RREP travels through the nodes 3, 2, 1 from the destination D to the source node S. Nodes 4 and 5 are not along the path determined by the RREP, and will timeout after active route timeout and will delete the reverse pointers from these nodes. A node receiving a RREP propagates the first RREP for a given source node towards that source. If it receives further RREPs, it updates its routing information and propagates the RREP only if the RREP contains either a greater destination sequence number than the previous RREP, or the same destination sequence number with a smaller hop count. Now the source node S can begin data transmission as soon as the first RREP is received, and can later update its routing information if it learns of a better route. 2.2.2 Route Table Management A timer Associated with reverse path routing entries is called the route request expiration timer. The purpose of this timer is to erase reverse path routing entries from those nodes that do not lie on the path from the source to the destination The expiration time depends upon the size of the ad-hoc network Another important parameter associated with routing entries is the route caching timeout or the time after which the route is considered to be invalid. In each routing table entry, the address of active neighbours through which packets for the given destination are received is also maintained. A neighbour is considered active for that destination, if it originates or relays at least one packet for that destination within the most recent active timeout period. This information is maintained so that all active source nodes can be notified when a link along a path to the destination breaks. A route entry is considered active, if it is in use by any active neighbours. A mobile node maintains a route table entry for each destination of interest. Each route table entry contains the following information. Destination Next Hop Number of hops Sequence number for the destination Active neighbours for this route Expiration time for the route table entry Each time a route entry is used to transmit data from a source toward a destination, the timeout for the entry is reset to the current time plus active route timeout. If a new route

2.2 Basic Operations of AODV

17

is offered to a mobile node, the mobile node compares the destination sequence number of the new route to the destination sequence number for the current route. The route with the greater sequence number is chosen. If the sequence numbers are the same, then the new route is selected only if it has a smaller metric to the destination. 2.2.3 Link Breakage When the link breakage happens the node must invalidate the existing route in the routing table entry. The node must list the affected destinations and determine which neighbours can be affected with this breakage. Finally the node must send the route error (RERR) message to the corresponding neighbours. The RERR message can be broadcasted if there are many neighbours who need that information or unicasted if there is only one neighbour. The host can also iteratively unicast the message to needed neighbours if broadcast is not possible. 2.2.4 Path Maintenance Movement of nodes not lying along an active path does not affect the routing to that paths destination. If the source node moves during an active session it can reinitiate the route discovery procedure to establish a new route to the destination When either the destination or some intermediate node moves, a special RREP is sent to the affected source nodes. Periodic hello messages can be used to ensure symmetric links, as well as to detect link failures. Alternatively, and with far less latency, such failures could be detected by using link-layer acknowledgments (LLACKS). A link failure is also indicated if attempts to forward a packet to the next hop fail. Once the next hop becomes unreachable, the node upstream of the break propagates an unsolicited RREP with a fresh sequence number and hop count of infinity to all active upstream neighbours. Those nodes subsequently relay that message to their active neighbours and so on. This process continues until all active source nodes are notified. Upon receiving notification of a broken link, source nodes can restart the discovery process if they still require a route to the destination. To determine whether route is still needed, a node may check whether the route has been used recently, as well as inspect upper level protocol control blocks to see whether connections remain open using the indicated destination If the source node (or any other node along the previous route) decides it would like to rebuild the route to the destination, it sends out an RREQ with a destination sequence number of one greater than the previously known sequence number, to ensure that it builds a new route and that no nodes reply if they still regard the previous route as valid. 2.2.5 Local Connectivity Management Although AODV is a reactive protocol it uses the Hello messages periodically to inform its neighbours that the link to the host is alive. The Hello messages are broadcasted with TTL equals to 1, so that the message will not be forwarded further. When host receives the Hello message it will update the lifetime of the host information in the routing table. If the host does not get information from the hosts neighbour for allowed hallo loss *

18

2 Overview to Ad hoc On-demand Distance Vector routing (AODV)

hello interval amount of time, then the routing information in the routing table is marked as lost. This action generates needed RRER message to inform other hosts of the link breakage. The local connectivity management with hello messages can also be used to ensure that only nodes with bidirectional connectivity are considered to be neighbours. For this purpose, each hello sent by a node lists the nodes from which it has heard. Each node checks to make sure that it uses only routes to neighbours that have heard the nodes hello message. To save local bandwidth, such checking should be performed only if explicitly configured into the nodes. 2.2.6 Local repair When the link breakage occurs then the host can try to locally repair the link if the destination is no more than specified amount of hops. In order to repair the link the host increase the destination sequence number and broadcasts the RREQ message to the host. The TTL for the IP header must be calculated, so that locally repair process would not spread throughout the network. The host waits for the RREP messages to its RREQ message for specified amount of time. If the RREP message is not received, then it changes the routing table status for the entry to invalid. If host receives the RREP message then the hop count metric is compared. If the hop metric from the message is greater than the previous one then the RERR with the N field set up is broadcasted. The N field in the RERR message indicates that the host has locally repaired the link and the entry in the table should not be deleted. The received RREP message is handled as original RREP message.

CHAPTER 3

3. OPNET Simulation Environment

This chapter details the architecture of OPNET simulator. The second section details how to use MANET model in OPNET to simulate AODV networks. 3.1 OPNET Architecture

OPNET provides a comprehensive development environment for modeling and performance evaluation of communication networks and distributed systems. The package consists of a number of tools, each one focusing on particular aspects of the modeling task. These tools fall into three major categories that correspond to the three phases of modeling and simulation projects: Specification, Data Collection and Simulation and Analysis. These phases are necessarily performed in sequence. They generally form a cycle, with a return to Specification following Analysis. Specification is actually divided into two parts: initial specification and re-specification, with only the latter belonging to the cycle, as illustrated in the following figure 3-1

Re-Specification

Initial Specification

Data Collection and Simulation

Analysis

Figure 3-1 Simulation Project Cycle of OPNET

3.2

MANET Model Architecture in OPNET

Models of AODV, DSR and TORA are available in OPNET version10.5. OLSR and modified version of OSPFv3 for the MANET model are under development. This

20

3 OPNET Simulation Environment

section explains about model architecture, node models of MANET and all source, header and external files that are used by AODV process.

Figure 3-2 MANET Model Architecture

The Figure 3-2 explains the node model architecture of a MANET node. This MANET node could be a WLAN workstation operating in ad hoc mode. The function of ip_dispatch of the ip_encap process creates a manet_mgr that manages all ad hoc routing protocols in OPNET. The manet_mgr again creates another specific process for the required ad hoc routing protocol as defined in the parameters. 3.2.1 Node Models in MANET All MANET capable nodes are included in the MANET object palette as shown in the following Figure 3-3. Wireless LAN workstations and servers These node models can be used to generate application traffic such as FTP, E-mail, HTTP over TCP over IP over WLAN. These nodes can be configured to run AODV as the routing protocol. MANET stations These node models can be used to generate raw packets over IP over WLAN. They can configure as a traffic source or destination and can be configured to run AODV as the routing protocol. Profile Config - Profiles describe the activity patterns of a user or group of users in terms of the applications used over a period of time. You can have several different

3.2 MANET Model Architecture in OPNET

21

profiles running on a given LAN or workstation. These profiles can represent different user groups, for example, you can have an Engineering profile, a Sales profile and an Administration profile to depict typical applications used for each employee group

Figure 3-3 MANET Object palette

Application Config -A profile is constructed using different application definitions; for each application definition, you can specify usage parameters such as start time, duration and repeatability. You may have two identical applications with different usage parameters; you can use different names to identify these as two distinct application definitions. Rxgroup Config - The receiver group configuration node is used to compute the set of possible receivers that a node can communicate with. This utility node can greatly speed up a simulation by eliminating receivers that do not match. Task Config Custom applications are configured by using this task configuration node. Mobility Config These nodes can be used to define mobility profiles that individual nodes reference to model mobility. This node controls the movement of nodes based on the configured parameters. 3.2.2 AODV Model Files Following are the AODV related files defined in the MANET model. Process model: These models are available in the directory <opnet_dir>/std/manet. aodv_rte is used to generate and process AODV control packets, also maintains AODV routing tables and updates IP common routing table. Header files: These files are also available in the <opnet_dir>/std/manet directory. The file aodv.h defines constants, data structure for route, request and connectivity tables,

22

3 OPNET Simulation Environment

aodv_pkt_support.h file defines types of packets and structure of packet options like rreq, rrep, rerr, and aodv_ptypes.h files are function prototypes for external files. External Source Files: These files are written in the C-code and are available in the <opnet_dir>/std/Manet directory. aodv_pkt_queue.ex.c aodv_pkt_support.ex.c aodv_request_table.ex.c aodv_route_table.ex.c aodv_support.ex.c 3.3 Configuring AODV in OPNET

By doing right click on the nodes placed in the project editor, a new window will be opened to edit attribute values on different parameters. The following Figure 3-4 shows how to configure AODV parameters as defined in RFC3561 in the OPNET.

Figure 3-4 Configuration of AODV in OPNET

3.4 Taking results of AODV

23

3.4

Taking results of AODV

By just right click on the project editor new editor will be opened to choose individual DES (Discrete Event Simulation) statistics by going in that we will have choice to select the different statistics that is going to be simulated. The Figure 3-5 shows how to choose the statistics from OPNET project editor.

Figure 3-5 Choosing Statistics

CHAPTER 4

4. Modelling of AODV networks and Analysis of Results

This chapter explains how to model an AODV network with default parameters of RFC 3561 using a MANET model in OPNET. Next section analyses both UDP and TCP results. Video streaming was used to analyze the UDP performance and File transfer using FTP was used to analyze the TCP performance 4.1 Modelling an AODV network

The campus network with five WLAN nodes is deployed over a square geographical area with the dimension 4000m * 4000m. All the nodes in the network are configured to work under ad hoc mode. Among the five nodes as shown in Figure 4-1, 4 nodes are fixed ad hoc nodes (source, node_03, node_04 and destination) while one node (mobile_node) is mobile. The mobile_node starts moving after 160 seconds along the path specified by the trajectory during the simulation period.

Figure 4-1 configured five node campus network for UDP traffic

26

4 Modelling of AODV networks and Analysis of Results

All the nodes use AODV as the routing protocol. The following Figures 4-1 and 4-2 show the above configured ad hoc network in the campus area. In the Figure 4-1, all nodes are WLAN workstations while in the Figure 4-2 uses 4 WLAN workstations and one WLAN server. WLAN server is used to generate TCP traffic while operating as a FTP server.

Figure 4-2 configured five node campus network for TCP traffic

4.2

Generating UDP traffic

The following sub sections explain how unidirectional UDP traffic is generated in the above modeled AODV network. 4.2.1 Configuring the Task Configuration Object Unidirectional UDP traffic is generated by configuring the Custom Applications since it is not possible to generate unidirectional traffic in the standard applications (i.e. using Application Config object). The traffic that is to be generated is defined in Task Config Object by assigning the task name as udp_task. And with the Manual Configuration, traffic is generated by sending 5060 request packets from the source to the destination with a inter request time 1 sec. Response from the destination is disabled in order to make unidirectional traffic. Each request packet consists of 1470 bytes, with each request sending only one packet. The following figure 4-3 explains how to configure unidirectional traffic using Task Config object in OPNET.

4.2 Generating UDP traffic

27

Figure 4-3 Configuring parameters in the Task Configuration Object

4.2.2 Configuring the Application Config Object Once the tasks have been defined, they are used to build (define) the custom application in the Application Config Object. The transport protocol that is to be used for this application is defined in the Custom Table as shown in Figure 4-4. For this application traffic, UDP is defined as the transport protocol in the Custom Table. And the task (udp_task) that is defined in the Task Config Object is deployed in the Task Description Table of Application Config object as shown in the Figure 4-4.

28

4 Modelling of AODV networks and Analysis of Results

Figure 4-4 Configuring parameters in the Application Definition Object

4.2.3 Configuring the Profile Configuration Object Once the Custom Application is defined , it will be used in the Profile Config Object . In the above modelled AODV network, the profile named udp_iperf_user will start at 100 seconds and lasts until end of the simulation. The Custom Application named udp_application is deployed in the Application Table of Profile Configuration Table as shown in the figure 4-4. This application will start running without any start time offset and lasts for the end of profile time.

4.2 Generating UDP traffic

29

Figure 4-5 Configuring parameters in the Profile Configuration Object

The above defined profile will be deployed into the originating node of the application, i.e. the source node. Figure 4-6 explains how to add the above defined UDP application in the source node of Figure 4-1.

30

4 Modelling of AODV networks and Analysis of Results

Figure 4-6 Deploying defined profile in source node

4.3

Generating TCP traffic

The procedure for generating the TCP traffic is also same as UDP traffic generation. But, for TCP, the originating node starts sending only one FTP request and the destination node sends data continuously to the source. Destination is sending comparatively more traffic than source which is only sending a request packet for downloading the file from destination. The traffic generation in TCP is shown in Figures 4-7 and 4-8.

4.3 Generating TCP traffic

31

Figure 4-7 TCP traffic generation from source to destination

Figure 4-8 TCP traffic generation from destination to source

TCP as the transport protocol for the application is defined in the custom table of Application Definition Table in Application Config Object as shown in the Figure 4-9.

Figure 4-9 Defining TCP as the transport protocol

32

4 Modelling of AODV networks and Analysis of Results

Defining the Profile Config Object for TCP traffic generation is also same as explained in UDP traffic generation. Configuring the Destination node is bit different in TCP traffic generation model since here the destination is a WLAN server. Application supported services of destination attributes must support the application (tcp_application) defined in the Application Configuration Object. Configuring this destination is explained in the figure 4-10.

Figure 4-10 Configuring destination in TCP traffic generation

4.4

Configuring the mobile node

The mobile node is attached to a trajectory to define the mobility patterns. This could be done by selecting a pre defined trajectory as shown in Figure 4-11.

4.4 Configuring the mobile node

33

Figure 4-11 Selecting the defined trajectory

In the above configured network (as shown in the Figure 4-1 and Figure 4-1), mobile node waits until 2 minutes 40 seconds (i.e. 160 sec) and starts moving away towards the path defined by the trajectory during the simulation. Figure 4-12 shows how this trajectory attributes are defined.

Figure 4-12 Trajectory attributes editor

34

4 Modelling of AODV networks and Analysis of Results

4.5

Analysis of UDP Results

Simulation was run for 220 seconds on the five node AODV network (refer Figure 4-1) and the following results have been obtained to analyze the AODV performance, when using customized video streaming based on unidirectional UDP traffic. 4.5.1 AODV Routing Traffic In the Figure 4-13, source node is sending two RREQs (Route Request) packets for the route discovery to the destination, the first RREQ has sent at 100 seconds (at the beginning of the application) via the mobile node and the second RREQ at 165 seconds via the nodes 3 and 4 since the mobile node starts moving away towards the defined trajectory. Destination node will send corresponding RREPs (Route Reply) in response to the requests sent by the source node. AODV routing traffic sent by each node is shown in the Figure 4-8. In the destination, there is sudden raise in the traffic at 100 and 165 seconds as it is sending RREP packets, at the rest of the time the traffic is due to only the hello messages. At mobile node traffic raise at 100 and 165 seconds due to RREQ and RERR messages and the rest of the traffic is due to hello messages. At nodes 3 and 4 all the traffic is due to hello messages except at 165 seconds. At this time traffic raise is due to the propagation of the second RREQ message. The traffic at source node is due to RREQ and hello messages.

Figure 4-13 AODV RREQs and RREPs sent

Figure 4-14 AODV routing traffic sent

4.5 Analysis of UDP Results

35

The Figure 4-15 shows the AODV traffic received by each node in the modeled network, all the traffic received in the nodes is due to received hello messages, RREQs and RREPs messages. Figure 4-16 gives the number of hops per route in the AODV network. Source and destination nodes will have 2 hops per route before the mobile node starts moving and after started moving the mobile node traffic will go through nodes 3 and 4 which will count 3 hops per route. At nodes 3 and 4 it will have 1 hops per route before mobility of mobile node and afterwards it counts 2 hops per route. And mobile node counts 1 hop per route.

Figure 4-15 AODV routing traffic received

Figure 4-16 AODV number of hops per route

4.5.2 IP Traffic IP traffic includes both the AODV routing traffic and UDP traffic. IP traffic and AODV traffic sent by destination node is exactly same since destination is not at all sending UDP traffic. IP and UDP traffic received by destination is same except in the packet count. IP traffic sent and received by Source, mobile node, nodes 3 and 4 is similar to the AODV traffic sent, and receive graphs, but it differs only with the number of

36

4 Modelling of AODV networks and Analysis of Results

packets sent since IP traffic includes the UDP traffic. IP traffic sent and receive are shown in the Figures 4-17 and 4-18.

Figure 4-17 IP traffic sent in packets/sec

Figure 4-18 IP traffic received in packets/sec

4.5.3 UDP Traffic As the UDP traffic is unidirectional from source to destination in the modeled network, UDP traffic sent by the destination will be nothing as shown in the figure 4-19. Since mobile node, nodes 3 and 4 are working as routers while traffic is sent from source to destination, UDP traffic send and receive through this nodes will be zero as shown in the figures 4-19 and 4-20. Source node starts sending UDP traffic at 100 seconds and lasts for end of profile. And the received traffic by the destination will be dropped suddenly at 160 seconds due to the link breakage with the mobile node as it is moving away along with the trajectory.

4.5 Analysis of UDP Results

37

Figure 4-19 UDP traffic sent in Bytes/sec

Figure 4-20 UDP traffic received in Bytes/sec

38

4 Modelling of AODV networks and Analysis of Results

4.6

Analysis of TCP results

Some of the important TCP parameters are analysed on the simulated results obtained on the five nodes modelled ad hoc network as shown in Figure 4.2. 4.6.1 AODV routing traffic Source node has initiated the route discovery process to send the FTP request packet to the destination (i.e. WLAN server) for downloading the files. In this process source is broadcasting the RREQ packet towards destination and as a response, destination is sending the corresponding RREPs. When the route is established between source and destination, destination also started sending the data continuously in response to the FTP request. While sending the data, there are more chances of link breakages due to the lost at the link layer and also delay in processing hello messages exchange between neighbours. Because of these link breakages, we can see more RREQs sent by the destination again to establish the link between the source and the destination. Source also sends corresponding RREPs. As shown in the Figure 4-21, source has initiated two route discovery processes. They are at the beginning and also just after the movement of the mobile node. The destination has started more route discoveries during the data communication in order to make the link again.

Figure 4-21 AODV RREQs and RREPs sent and received by the source and destination

4.6 Analysis of TCP results

39

Effect of the frequent link breakages during the data transmission between the destination and the source is shown in the Figure 4-22. The mobile node sends more RERRs and drops some of the packets before the movement. After the movements, routes are established via the intermediate nodes of Nodes 3 and Node 04. These nodes also send more RERRs and drop more packets.

Figure 4-22 AODV RERRs sent and packets dropped

4.6.2 IP traffic IP traffic sent and received by the destination node (i.e. WLAN server) on average is more when the traffic is through the mobile node since this route has only 2 hops. Throughput of IP packets (both sent and received) has been decreased when the traffic is through the nodes 3 and 4 (i.e. after the mobile node movement at 160 seconds). This

40

4 Modelling of AODV networks and Analysis of Results

means that throughput will be decreased as the no of hops are increasing. IP traffic sent and received by each node in packets per seconds is shown in the Figures 4-23 and 424.

Figure 4-23 IP traffic sent by each node

Figure 4-24 IP traffic received by each node

4.6.3 TCP traffic The Figure 4-25 shows the TCP traffic received by the source node and the TCP segment delay in seconds. In this figure, the traffic received through the mobile node by the source is higher compared to the traffic received through the nodes 3 and 4 as it must travel through 3 hops where as through mobile node it needs lesser hops. So we can conclude that the throughput will decrease as the no of hops are increasing. This is justified with the analysis of segment delay. 4.6.4 Congestion Window Size Some of the TCP parameters are analysed in this subsection. They are congestion window variations, TCP packet trace (the sequence number and acknowledge number vs time), TCP connection retransmission count, variations in the RTT (Round Trip Time) and RTO (Retransmission Time Out) of the TCP connection (refer Figure 4-26). We can also say that segment RTT time will be more as the number hops increases. We can also observe that there is a sudden drop in the window size after the movement of mobile node, which is at after 160 seconds as shown in the Figure 4-26.

4.6 Analysis of TCP results

41

Figure 4-25 TCP traffic received by source and segment delay

Figure 4-26 Some TCP connection parameters

CHAPTER 5

5. Simulation Results Vs Test-bed Results

This chapter briefly compares the same set of results that were taken in the real environment with the above results. Real environment test was also carried in the five nodes AODV network consisting of notebooks as AODV nodes. Raw TCP and UDP traffic was generated using iperf traffic generator [11]. Following table summarizes the changes between two set ups.
Parameters Used TCP Parameters TCP implementation Starting Congestion Window Size (bytes) Max segment size WLAN (IEEE 802.11b) Operation mode Buffer size , bits Data Rates Application UDP

In the Test-Bed Reno Implementation 16K 40bytes Ad hoc 1024000 11Mbps

In the Simulation Reno 16K 2264 bytes Ad hoc 1024000 11 Mbps

video Uni-directional UDP flow Uni-directional at 512000 bps (generated streaming based on UDP at 11760 bits per seconds by iperf) 120 Sec (movement at 60 sec)

Duration TCP Measurements UDP throughput variation at D TCP throughput variations at S RREQ/RREP ,RERR TX/RX IP traffic RX/TX by all Data lost at the link layer TCP Parameters CWND RTT/RTO

Raw TCP packets FTP downloads at about 500kbytes per second generated by Iperf Yes Yes Yes Yes
Yes Yes yes yes Yes Yes Yes

Comparing with the test bed results as given in [12], more or less the results taken from the above simulation are same. Simulation has further extended to investigate the performance when changing the values of Hello Interval*Hello Loss.

44

5 Simulation Results Vs Test-bed Results

This was observed for the TCP model by changing HelloLoss from 3 to 5. Two different scenarios are taken to compare link breakages for above two values. These two scenarios are, one is with hello loss 3 and the other one is with hello loss 5. As shown in the Figure 5-1, it is observed that number of RREQs sent in the scenario with the hello loss 5 is less compared to the scenario with lesser hop counts. RERRs sent and packets dropped are also less in the scenario with hello loss 5 (red colour) compared to the scenario with hello loss 3 (blue colour) which is shown in the Figures 5-2 and 5-3. Figure 5-4 shows the TCP throughput variations. When using the higher value for the HelloLoss, throughput degrades more during the movement, but the throughput drops during the normal data transmission is less.

Figure 5-1 Comparison of RREQs sent by the two different scenarios

4.6 Analysis of TCP results

45

Figure 5-2 Comparison of RERRs sent by the two different scenarios

Figure 5-3 Comparison of Total Packets Dropped by the two different scenarios

46

5 Simulation Results Vs Test-bed Results

Figure 5-4 Comparison of TCP traffic received by two different scenarios

AODV detects link breaks based on HELLO messages, as implemented in OPNET. When detecting link breaks using HELLO messages, each node waits to receive at least one HELLO message for the duration of HelloInterval*HelloLoss. And also, each AODV node should process each packet (both data & control messages) to update the route lifetime. When having more data at the link layer, the probability of Hello packets to be lost is higher. And also, when processing more data packets (by the AODV protocol handler), the node takes a long time to process the HELLO message. If a Hello message is not received within the pre-defined interval (i.e. HelloInterval*HelloLoss), the node invalidates the active route and decides that the neighbor is not reachable. Therefore, lower the detection duration (i.e. lower the value for HelloLoss), the higher the probability of route breaks, under the transmission of higher data rates. Detecting link breaks using link layer information avoids this situation. In a static AODV environment, it is always better to use a higher value for HelloLoss, when transmitting higher data rates. The most suitable solution is to use link layer information to detect the link connectivity with the neighboring nodes.

CHAPTER 6

6. Conclusion
In this work, performance analysis of AODV networks using the OPNET simulator was done. AODV model was added to the OPNET simulator very recently (version 10.5 released in 2004). Several simulations of AODV networks in OPNET were done to investigate the behavior of transport layer protocols, both UDP and TCP in AODV networks. Results were analyzed for both UDP and TCP separately. Unidirectional video streaming was used to analyze the UDP communication, while TCP performance was analyzed using file downloads via FTP (File Transfer Protocol). Following conclusions are made based on the analysis of simulation results. In general, the behavior of TCP and UDP in simulated as well as in real test-bed AODV networks is almost same. With the increase of number of hops, throughput degrades due to the higher RTT delay. With the increase of loads (i.e. application traffic), throughput can again be degraded due to the loss at the link layer. Link layer losses could be due to problems of hidden/exposed node or collisions in the wireless media Throughput of TCP communications can be affected by altering certain AODV parameters. More specifically, it was found that by changing the HelloLoss value from three to five, the TCP through put was enhanced for the FTP rates of 500 Kbytes per second. Lower the detection duration, the higher the probability of route breaks, under the transmission of higher data rates. Detecting link breaks using link layer information avoids the route breaks when using higher loads in AODV networks. In a static AODV environment, it is always better to use a higher value for HelloLoss, when transmitting higher data rates.

Further work: Following work can be done in the future using OPNET simulator. . Further performance analysis of AODV networks: (For different AODV parameters (e.g., Change of Net Diameter, TTL parameters, etc) have to be analyzed, Performance analysis of AODV networks in a large number of nodes networks (more than 20 nodes) also to be analyzed, Effects on simulations by defining the RX group configuration object Performance comparison of different ad hoc protocols (DSR vs AODV, OLSR vs AODV) Analysis for TCP performance in AODV networks for different wireless TCP implementation available.

CHAPTER 7

7.

LIST OF FIGURES

Figure 2-1 A Wireless LAN with station A is transmitting (Hidden Station Problem) .............................. 12 Figure 2-2 Wireless LAN with station B is transmitting (Exposed Station Problem)................................. 12 Figure 2-3 WLAN CSMA/CA medium access scheme ............................................................................... 13 Figure 2-4 Reverse Path Setting Figure 2-5 Forward Path setting.......................... 15 Figure 3-1 Simulation Project Cycle of OPNET .......................................................................................... 19 Figure 3-2 MANET Model Architecture ..................................................................................................... 20 Figure 3-3 MANET Object palette ............................................................................................................... 21 Figure 3-4 Configuration of AODV in OPNET ......................................................................................... 22 Figure 3-5 Choosing Statistics ...................................................................................................................... 23 Figure 4-1 configured five node campus network for UDP traffic .............................................................. 25 Figure 4-2 configured five node campus network for TCP traffic............................................................... 26 Figure 4-3 Configuring parameters in the Task Configuration Object...................................................... 27 Figure 4-4 Configuring parameters in the Application Definition Object.................................................. 28 Figure 4-5 Configuring parameters in the Profile Configuration Object..................................................... 29 Figure 4-6 Deploying defined profile in source node .................................................................................. 30 Figure 4-7 TCP traffic generation from source to destination ..................................................................... 31 Figure 4-8 TCP traffic generation from destination to source ..................................................................... 31 Figure 4-9 Defining TCP as the transport protocol ...................................................................................... 31 Figure 4-10 Configuring destination in TCP traffic generation................................................................... 32 Figure 4-11 Selecting the defined trajectory ................................................................................................ 33 Figure 4-12 Trajectory attributes editor........................................................................................................ 33 Figure 4-13 AODV RREQs and RREPs sent Figure 4-14 AODV routing traffic sent................ 34 Figure 4-15 AODV routing traffic received Figure 4-16 AODV number of hops per route..... 35 Figure 4-17 IP traffic sent in packets/sec Figure 4-18 IP traffic received in packets/sec ...... 36 Figure 4-19 UDP traffic sent in Bytes/sec Figure 4-20 UDP traffic received in Bytes/sec..... 37 Figure 4-21 AODV RREQs and RREPs sent and received by the source and destination........................ 38 Figure 4-22 AODV RERRs sent and packets dropped ................................................................................ 39 Figure 4-23 IP traffic sent by each node Figure 4-24 IP traffic received by each node .... 40 Figure 4-25 TCP traffic received by source and segment delay .................................................................. 41 Figure 4-26 Some TCP connection parameters ............................................................................................ 41 Figure 5-1 Comparison of RREQs sent by the two different scenarios...................................................... 44 Figure 5-2 Comparison of RERRs sent by the two different scenarios ....................................................... 45 Figure 5-3 Comparison of Total Packets Dropped by the two different scenarios..................................... 45 Figure 5-4 Comparison of TCP traffic received by two different scenarios................................................ 46

BIBLIOGRAPHY

8. Reference
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] IETF-Working-Group, "MANET: Mobile Ad hoc NETworks," www.ietf.org/html.charters/manet-charter.html. C. Perkins, B.-R. E., and D. S., "Ad hoc On-demand Distance Vector routing," Request For Comments (Proposed Standard) 3561, Internet Engineering Task Force http://www.ietf.org/rfc/rfc3561.txt?number=3561, July 2003. C. E. Perkins, Ad Hoc Networking. NJ: Addison-Wesely, 2000. UoB-JAdhoc, "AODV implementation in Java, developed by ComNets, University of Bremen, available at www.aodv.org," 0.11 ed, 2003. OPNET Modeler product documentation- release 10.5 Andrew .S.Tanenbaum "Computer Networks," Prentice Hall India (PHI), November 1998. Pablo Brenner"A Technical Tutorial on IEEE 802.11 Protocol," http://www.sss-mag.com/pdf/802_11tut.pdf Tirumala, A., et al., Iperf: The TCP/UDP Bandwidth Measurement Tool. Available at http://dast.nlanr.net/Projects/Iperf Xu, S and T.Saadawi, Does the IEEE 802.11 MAC Protocol Work Well in Multihop Wireless Ad Hoc, in IEEE Communication Magazine, 2001 OPNET Simulator, http://www.opnet.com/ Tirumala, A., et al., Iperf: The TCP/UDP Bandwidth Measurement Tool, avialable at http://dast.nlanr.net/Projects/Iperf. K. Kuladinithi, N.A. Fikouras, A. Udugama and C. Grg, Experimental Performance Evaluation of AODV Implementations in Static Environments, available at www.aodv.org