Comparison of Ad Hoc Network Routing Protocols

John Bellardo Jenny Fang November 23, 1999 Greg Hamerly

Abstract An ad hoc wireless network is a collection of mobile hosts which need to communicate with each without the aid of traditional xed-position routers (such as a base station in a cellular network) or physical connections. With this comes the problem of establishing routes between hosts that are not able to communicate directly because of limited transmission range and maintaining routes in the presence of changes due to host mobility and external interference. To resolve this, there are several types of ad hoc routing protocols in which hosts participating in the network agree to forward packets for other hosts. We were curious which protocols are more ecient and work better under dierent circumstances. We investigated three of the more common algorithms: Ad Hoc On-Demand Distance Vector, Dynamic Source Routing, and Location-Aided Routing.

Introduction

An ad hoc wireless network is a collection of mobile hosts which need to communicate with each other without the aid of traditional routers. Several types of protocols have been proposed for routing in an ad hoc network. A full range of studies is being conducted to discover the advantages and disadvantages of each protocol. In this paper, we compare two of the three algorithms currently under review by IEEE and analyze a supplemental algorithm that can optimize the performance of the others. The two algorithms are Ad Hoc On-Demand Distance Vector and Dynamic Source Routing. The optimization algorithm is Location-Aided Routing. We will compare the protocols with respect to resiliance to network topology changes, resource usage, path discovery costs, scalability, and security. We nd that no one protocol works best for all of these areas, but each has its advantages. In this paper we will refer to several terms we dene here. A networks diameter is the maximum length path (in number of hops) in a minimum spanning tree of the network. When a host oods a network, it sends out a packet that gets forwarded to all other hosts on the network. Path discovery occurs in an ad hoc network when a source host needs to communicate with a destination host but does not know how to route packets to get to the destination.

Ad Hoc On-Demand Distance Vector Routing

Ad Hoc On-Demand Distance Vector Routing (AODV) was proposed by Perkins and Royer [4] in 1999. AODV is a second generation wireless distance vector routing protocol that evolved from Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) [3]. For the remainder of this description the term source node will refer to the node that wants to send a packet, destination node will refer to the node the source node wants to send the packet to, and intermediate node will refer to any node in the route from the source node to the destination node, excluding the endpoints. AODV is a pure on demand protocol. No routes are discovered or maintained until they are needed. This means that the only routing activity (discovery or maintenance) a node participates in is the activity associated with the other node(s) it is communicating with, or, if the node is oering its services to forward packets for other nodes. The route table for AODV contains next-hop routing information, and information needed to administer the route table as described below. Once a route has been established using path discovery all the source node has to do is send the packet for the destination node to the nexthop node as dened in the route table. The next-hop node will in turn forward the packet to its next-hop node for the given destination node, and so on until the packet reaches the destination node. AODV uses the idea of a route sequence to guarantee that nodes will not be presented with stale routes. Sequence numbers can be though of as a virtual time where the higher numbered sequences occurred at a latter time than the lower numbered sequences. Sequences are maintained on a per destination node basis, so the only useful comparison of sequence numbers is between those whose corresponding route has the same destination node. The destination node in the route contains the authoritative sequence number for the route. As time progresses and the topology of the network changes the sequence number gets increased. There are four distinct aspects to the AODV algorithm: path discovery, route table management, path maintenance, and local connectivity management.

2.1

Path Discovery

Path discovery is used when there is no available route to the destination node in the source nodes route table and the source node wishes to send a packet to the destination. Each node maintains two sequence numbers to aid in path discovery, broadcast-id and sequence-num. broadcast-id is the sequence number that identies each unique path discovery request. Because broadcast-id uniquely identies a path discovery request from a given source, the <source-addr, broadcast-id> pair uniquely identies a path discovery request in the entire network. To initiate path discovery the source node broadcasts a path discovery packet containing the elds <source-addr, source-seq-num, broadcast-id, dest-addr, dest-seq-num, hop-count> to the network. After broadcasting the request the source node increments broadcast-id to ensure that it will uniquely identify the next broadcast discovery request. All neighboring nodes receive the packet and can do one of two things. First, if a path to the destination is in their route table, and that path has a sequence number greater than dest-seq-num then the intermidiate node sends a path discovery response along the reverse path back to the source node. Otherwise the node increments 2

the hop count by one and re-broadcasts the path discovery packet. For the later case the node also needs to set up the reverse path (see below) so that the path discovery response sent from another node can reach the source node. The node also needs to start listening for the path discovery response so that it can set up the forward path as needed. The node can easily ignore multiple path discovery requests for the same path because it can check the <source-addr, broadcast-id> pair to determine if it has already seen the path request. This greatly reduces the amount of extraneous broadcast overhead. The broadcast packet will eventually ood the entire network and will nd a path to the destination node by nding the destination node itself, or a cached path in another node. Once the path is found a path discovery response will be sent along the reverse path. If no path to the destination node exists the request will time out waiting for a response and the source node will know that the destination node is unreachable. 2.1.1 Reverse Path Setup

As each node receives and forwards a new path discovery request it stores the node that it received the request from before it re-broadcasts the path discovery. The node checks the source-seq-num in the request packet and updates its route table to ensure that it has the latest version of the route back to the source node. This route back to the source node is kept in the route table at least long enough to allow the route discovery result to be delivered to the source node. 2.1.2 Forward Path Setup

If a node forwards a path discovery request it must listen for the path discovery response. Listening for the response is critical to the functioning of the system. If a valid response is seen it allows the node to add an entry into its route table with the correct next-hop for the given destination node. It is this entry that will allow the node to correctly route future packets to the destination node. After the node is nished updating its route table it sends the response back along the reverse path so that the next node in the path can also set up their route table correctly. Eventually the response gets delivered to the source node. At this point the route is set up and the source node knows the correct next-hop to use when sending packets to the destination node. It is possible to have a node receive more than one route discovery response. The rst response packet received is always propagated along the reverse path. If sometime in the future the same node receives a response to the same route discovery request it checks to see if the hop count of the new route is less than the current routes hop count. If the hop count is less the current route is replaced with the new route, and the new routes route discovery response is propagated along the reverse path. Because, after the rst route is discovered, only better routes are propagated the source node will eventually have the best route to the destination node. This allows the source to start communication with the destination as soon as a single route is known even though it may not be the best route. Over time the best route will be discovered and used.

2.2

Route Table Management

There are a few bits of information needed to correctly manage the route table. The rst of these is an expiration timer per route table entry. When the expiration timer runs out the route entry is 3

purged from the route table. In the case of reverse path routing entries the timer is set signicantly less than the timer for the forward path entries. This has the eect of keeping the reverse paths around for just slightly more time than needed to deliver all of the route discovery responses. In addition to the expiration timer there is a set of active nodes associated with each route table entry. An active node is dened as a neighboring node who has used the forwarding services of the current node within the last active-timeout seconds. This set is used to determine which nodes to inform when there is a change in the route. There is also the concept of an active path. A path is active if there has been packets sent using the path within the last active-path-timeout seconds. The active-path-timeout and the active-timeout are set to the same value. Both active nodes and active paths are used during path maintaineance.

2.3

Path Maintenance

Path maintenance only applies to those nodes that fall in an active path, which are by denition active nodes. If a node is not active then it does not participate in path maintenance. When a broken path is detected only the nodes in the half of the path with the source node are aected. From now on this side will be called the upstream side. As soon as the break is detected an unsolicited path discovery response with a hop count of and a sequence number one more than the current sequence number for the route is propagated from the node detecting the break to all of its next-hop active neighbors. The neighbors will in turn propagate the response to their active neighbors, and so on until all of the active nodes of the path on the upstream side of the break are notied. The response causes all of the active nodes to update their route table with an unreachable route to the destination node. The incremented sequence number ensures that the lack of a path will supersede any other currently known path. If any of the active nodes still need to communicate with the destination node they can do another path discovery. There are a few dierent ways to detect a broken link. The rst way is if a sent packet times out before getting the expected reply. The second way to tell if a link is broken is to periodically send ping packets to known active neighbors to see if they respond. Another way to detect if there has been a break in the network is through the use of link-layer acknowledgements which are very similar to the pings, but because they are link layer they have much less overhead.

2.4

Local Connectivity Management

Local connectivity information is maintained via hello messages and network monitoring. If a node does not receive any packet from a known neighbor within a set period of time, the link to that neighbor is considered questionable. If no packets are received within twice the same timeout period the link is considered broken and the above mentioned path maintenance takes place. Nodes keep track of how long it has been since they have communicated with their neighbors. If the time interval gets too long (too long is necessarily less than the no activity timeout) then the node broadcasts a hello message to its neighbors. Nodes that are not active and that do not fall along an active path do not need to worry about managing local connectivity. Changes in local connectivity cause a reevaluation of the current paths, possible resulting in detecting a broken path which would require path maintenance.

2.5

AODV Analysis

All of the performance numbers are from ad hoc network simulations done by Perkins and Royer [4]. 2.5.1 Resilience to Change

The main way of detecting network breaks in an active network is packet timeouts. The timeout values are relatively small, so a break can be detected within a few seconds. In an idle network the breaks will be detected by an absence of the hello messages and will be detected before a packet is lost due to a timeout. After a break is detected the information is propagated to all the nodes in the route on the source nodes side of the break. The concept of active nodes allows the new route information to be passed to nodes that were using the route recently. This is in contrast to DSV (presented in next section) where all the nodes in the partition get the new route even if they havent used the route lately. In some cases this will force future nodes to timeout in order to discover that the route is broken. For more dynamic networks AODV will not be as good as an algorithm that does not have this problem, but in most cases this wont be an issue. AODV does make assumption that there are only bidirectional links (and it ignores any links that are not) and that they all incur the same cost to use. This assumption can decrease the overall performance of the network if a large number of the links do not meet the assumption. 2.5.2 Resource Usage

Memory Each route table entry holds a xed number of elements (next-hop, timer, active) so the largest the route table can get is O(n) where n is the number of nodes in the network. AODV also maintains a set of active neighbors with a size at most O(n), so the upper bound on the total memory usage is O(n). Since AODV is an on-demand algorithm the actual size of the route table will be much smaller in the average case (it will just contain the nodes you are talking to). CPU Usage There is no signicant additional CPU overhead imposed by the algorithm other than that needed to directly route packets and discover the routes to the destination. DSR contrasts AODV sharply here. Number of Packets Please refer to the section on Path Discovery Costs for more detailed information. AODV has some room for improvement here, but it still does pretty good. Path maintenance will require one packet to be sent to each node in the active path. You cant do any better than this without using some form of multicasting. The hello messages are only sent during long periods of network inactivity, so they have no impact on the network. Bandwidth Utilization Table 1 contains the simulation results using AODV and can be used to provide an idea of bandwidth utilization. In the best case 10% of the bandwidth was used by algorithm overhead, so the total bandwidth utilization can be no more than 90%. 5

number of Nodes 50 100 500 1000

% Network trac due to algorithm overhead 10 12 24 33

Table 1: Simulation results for AODV [4]

2.5.3

Path Discovery Costs

The number of packets used for route discovery is at most n2 (in the case where everyone is a neighbor), but the total time to discover a route is as most O(n). LAR (presented in section 4) provides a way to reduce the number of packets needed for path discovery. 2.5.4 Scalability

The lower per-node memory and CPU requirements of AODV provide promise that it will scale well. Evidence to support this can be seen in the Table 1. As the number of nodes in the ratio of algorithm overhead to number of nodes actually decreases. This means that AODV has great potential to scale. 2.5.5 Special Needs

AODV has no special hardware needs so it will work on all existing hardware. AODV does make the assumption that all links in the network are bidirectional and are of equal cost. The impacts of this assumption is considered in the Resilience to Change section above.

Dynamic Source Routing

Dynamic Source Routing (DSR) is a protocol proposed by Johnson and Maltz [1] whose primary design goals are resiliance to changes in the network topology while maintaining near-optimum route tables. Ad hoc networks with mobile hosts are prone to rapid changes. DSR assumes that each client will act as a router, and that communication along a channel is not necessarily bidirectionally equivalent. In DSR, each client maintains a cache of the full paths required to get to each host it wants to communicate with. This is in contrast to a protocol such as distance vector, in which just the next hop for a path is recorded. DSR discovers routes on demand by broadcast. Other hosts which have cached routes to a desired host may respond authoritatively during route discovery, saving network overhead. After a route has been discovered a host will specify the route a data packet must take by embedding the full path in the packet. Each host that receives the packet relays it to the next host in the hop list. If a host somewhere in the path cannot be contacted (discovered via a timeout), the host with 6

the packet will send an error packet back to the source host. At that point the source host will truncate its knowledge of the reachable network after the host which returned the error packet. Such network partitioning will cause the source host to re-discover the path to the destination host. DSR does not use periodic hello packets to notify its neighbors of its state. All changes in DSR are made on demand (such as due to a link failure), except when more convenient methods are readily available. More convenient methods involve each host listening promiscuously to network trac of adjacent hosts, and drawing conclusions about network status from these other packets. For example, an error packet returned to a host can also be considered valid by every host that forwards and can hear the error packet, so each host in the error packets return path can update their routes accordingly. This is a valuable optimization as it does not require every host using a route to time out to discover that partitions exist. Additionally, if lower cost routes become available, listening to adjacent trac can alert a host to these. The DSR implementation stores all paths as a tree, thereby minimizing the amount of redundant hosts in multiple paths.

3.1

Resiliance to Change

Changes in network topology propagate quickly in DSR. This is because complete routing information is kept at each host, so that when a route becomes unavailable the protocol requires a route rediscovery, and all old state information is discarded. Errors in the form of invalid or old routes could propagate since hosts are allowed to respond authoritatively on behalf of others, but this is accounted for by the promiscuous network monitoring, which will alert many hosts of route failures for one error message. However, DSR will not be able to keep up with changes in topology beyond a certain frequency (i.e. hosts moving in and out of range too quickly). However, we believe this is the case with any such ad hoc protocol. In a simulation of 24 hosts, Johnson and Maltz illustrate that even when all hosts are in constant motion (at a reasonable speed) all packets were able to get to their target destination, which they claim is unlikely in a distance vector protocol [1].

3.2

Resource Usage

A host that utilizes DSR will require more memory and cpu time, as compared to other routing protocols. However, the number of packets required is nearly optimal. Memory Since each host must keep track of full topology for all other hosts that it wants to communicate with, each host could be required to keep a full view of the entire network (in the worst case) in its cache, which is redundant information over multiple hosts. Typical routing protocols, such as distance vector, store just the next hop for any route path. CPU Usage DSR uses more CPU time than conventional routing protocols for two reasons. One is that each host must participate in forwarding packets, which is not uncommon in ad hoc networks. The other is that the optimizations which allow DSR to work eciently in time and react

quickly to change require each host to monitor all of the network trac going on within its receiving range. Number of Packets DSR performs well in terms of the number of packets it requires. In their simulations, Johnson and Maltz found that the number of packets sent was within 1-2% of the optimal [1]. Bandwidth Utilization DSR uses network ooding to do route discovery, which has an impact on most of the connected network. As it implies, ooding is a way of quickly getting routing information at the cost of much bandwidth used. Flooding is necessary in the absence of any other information, however, and (as stated before) most ad hoc protocols use similar features. Even so, DSR uses an optimized form of ooding to reduce network overhead. On route discovery, it will send out one broadcast packet to all of its 1-hop neighbors. If it does not receive a response on how to reach its destination from them, it will only then send out a network-wide broadcast. The network-wide ood is limited to 10 hops, because it is assumed that all useful routes in an ad hoc network are within this limit. DSR is well-suited to more static networks in its bandwidth use, because it does not send out network status packets (hello). It only sends packets for real trac in these cases. Therefore, in a relatively quiescent network topology, DSR will not be using much (if any) bandwidth for routing overhead.

3.3

Path Discovery Costs

As described above, DSR uses an optimized ooding algorithm to discover paths that a host needs. Because there is the chance that several hosts may all have the capability to reply to a route discovery request, resulting in unnecessary network overhead, DSR optimizes for this case. If an intermediate host receives a route discovery request for a host that it has a cached route for, it does not simply return the route it knows. Instead, it delays for a time period of: d = H (h 1 + r) where h is the amount of hops to get to the destination from this host, r is a random amount between 0 and 1, and H is the amount of time it takes to make one hop on the network. During this time the intermediate host listens to surrounding network trac. If it hears a response packet with a route that is equal to or better (in terms of hop count) than the one it has cached, it discards its response. If it does not hear anything as good or better, it sends its response. In their simulation Johnson and Maltz calculated the amount of network overhead versus optimum for dierent network variabilities [1]. When the network was the least stable and path re-discovery was happening frequently, the packet overhead was 2.6 times optimum. That gives a good indication of what total path discovery cost is about 150% (somewhere between two and three times) above optimum routing for each situation.

3.4

Scalability

DSR does not appear to be a very scalable protocol because each host must keep full knowledge of the paths that it needs to communicate over. In the worst case, if a host has to communicate 8

with every other host on the network, that amount of information that the host must keep grows linearly with network growth. Over all hosts, this state will grow as O(n2 ), where n is the number of hosts in the network. In more conventional networks with default routers, minimal changes have to be made to local routing tables when the network grows. Also, in a densely connected network (where many hosts are within communication distance), there can be a lot of unnecessary overhead on each host due to promiscuous listening, as described above. Again, this will grow linearly per host and as O(n2 ) over the network in the worst case.

3.5

Special Needs

DSR needs is for each host to participate as a router in the network. It also needs network interface hardware and software that is able to listen to network trac promiscuously, which most today are able to. Johnson and Maltz [1] make the suggestion that an optimization could be made to implement this protocol on the network interface hardware, with the largest benet being that the CPU will not have to inspect each packet that it receives.

Location-Aided Routing

Location-Aided Routing (LAR) algorithm proposed by Vaidya et. al. [2] is essentially the same as ooding, except that it makes use of location information to reduce routing overhead. Location information is provided by the Global Positioning System (GPS).

4.1

Preliminaries

Two zones are dened with respect to the source node S and the destination node D: the expected zone and the request zone. 4.1.1 Expected zone:

If S does not have any previous knowledge of D, then the expected zone of D is the entire region that is occupied by the ad hoc network. If S wants to transmit data to D, it must rst invoke a route discovery phase by ooding the whole network. The size of the expected zone is therefore directly related to the routing overhead. In order to reduce the size of the expected zone, the LAR algorithm assumes that S knows Ds location (call it L) at time t0 , Ds speed v, and the current time t1 . Note that all these information can be provided by the GPS. The expected zone of D, as viewed by S at time t1 , is dened as the region that S expects to contain D at t1 . One way to visualize the expected zone is to imagine a circular region of radius v(t1 t0 ) that is centered at location L. This region is only an estimate made by S, since Ds speed could have changed between t0 and t1 . The size of the expected zone can be further reduced if more information about the mobility of D is known to S. For example, if S knows that D is moving North during t0 and t1 , then the 9

expected zone can be reduced to a semicircle. 4.1.2 Request zone:

S denes a request zone in order to avoid using network-wide ooding when it tries to discover a route to D. Upon the receipt of a route request packet from S, an intermediate relaying node N can either forward the packet if N is within the request zone for this transmission, or discard the packet if otherwise. To increase the probability of successfully reaching D, the request zone should at least include the expected zone, and possibly other regions. S could be either inside or outside of the expected zone of D, and S could sometimes by chance dene a request zone such that there are no relaying nodes available within the zone. Thus there is no guarantee that a path can be found consisting only of nodes in a chosen request zone. Under this circumstance, S must initiate a new route request after a time-out period with an expanded request zone. Thus there exists a trade-o between latency of route determination and routing overhead. The larger the request zone is, the more probable it is to nd a path within the rst time-out period, and therefore the shorter the latency. However, a large request zone also means more routing overhead.

4.2

Algorithms

Location-Aided Routing can be classied as an on-demand routing protocol, in that there are no periodic routing updates and the routing table maintained at each node does not store the link state or location information about every other node in the network. In LAR, the routing table maintained at a node (say, S) stores only the location (and speed) information learned from previous transmissions made by S at time t. If S has never transmitted to a particular node (say, D) before, then there is no entry about D in Ss routing table. Thus when S wants to transmit to D, it rst looks for an entry on D in its routing table. If no entry on D is found, a network-wide ooding must be used to for route discovery. If an entry on D is found, then S calculates a request zone based on the information in the entry and initiates a route discovery. Vaidya et. al. introduces two routing schemes. While both use location information provided by the GPS to limit the ooding region during the route discovery phase, they dier by ways of dening request zones for a route request. 4.2.1 LAR scheme 1:

S is assumed to know the location and the speed of D at time t0 . Let (Xd , Yd ) be Ds location at t0 , and let v be the speed of D at that time. If at time t1 , S initiates a route discovery for D, the expected zone is the circle of radius v(t1 v0 ) centered at (Xd , Yd ). The request zone is dened as the smallest rectangle that contains the current location of S and the expected zone of D. The sides of the rectangle need to be parallel to the longitude and the latitude. S can thus easily determine the coordinates of the four corners of the rectangle, and includes them in the route request packet. When a node receives the packet, it checks its own location given by the GPS against the

10

coordinates in the packet. It forwards the route request packet if it is within the rectangle and discard the packet otherwise. Although in [2] Vaidya did not describe the procedure of forwarding a route request packet, we assume that the relaying node appends its own ID and location information to the packet to aid the route reply process. Assume that the route request packet eventually reaches D, D replies by sending a route reply message as in most other routing algorithms. However, LAR diers from the rest of the algorithms in that D also includes its current location, time, and speed in the route reply message. Vaidya again did not describe in detail the procedure for sending a route reply packet, but we assume that D simply copies the IDs of the relaying nodes in reverse order from the route request packet to the reply packet. D then sends the reply packet to the relaying node that is listed rst in the packet. When S receives the reply packet, it records Ds location, time, and speed information into the its routing table, so it can be used for a future transmission. 4.2.2 LAR scheme 2:

The basic assumptions are the same as in LAR scheme 1. S now calculates its distance, DISTs , from D and includes it in the route request packet. The coordinates (Xd , Yd ) are also included in the packet. When a relaying node I receives the route request packet, it uses the coordinates (Xd , Yd ) included in the packet and its own GPS location to calcuate its distance, DISTi , from D. If DISTi DISTs + , where is a pre-dened number, then I replaces DISTs in the original route request packet with DISTi and broadcasts the packet to its neighbors. If the above inequality does not hold, I discards the route request packet and does not forward. When a node J receives the packet from I, it uses the same procedure to determine whether it should forward the packet. Thus, J forwards the route request packet sent by I only if J is at most farther away from D than I. Upon the receipt of route request packet, D replies in a similar fashion as in LAR scheme 1. LAR scheme 2 is reminiscent of several papers published by Kleinrock in the 80s, which introduced the notion of progress. The basic idea is that we always want to send a packet towards the destination rather than away from it. In case that the route request fails after the rst time-out, both LAR schemes react in a similar fashion. In LAR scheme 1, the request zone could be expanded to include more relaying nodes; while in LAR scheme 2, the value of could be relaxed. However, to simplify the simulation procedure, Vaidya et. al. simply reverted both algorithms to ooding.

4.3
4.3.1

Discussion
Eects of mobility:

Unlike the static routing protocols in which each node needs to continuously maintain updated information about all other nodes in the network, the nodes under both LAR schemes do not need to do so. Therefore, a network that employs LAR does not need to send packets to update each others routing tables as in the network that uses static routing protocols.

11

Simulations by Vaidya et. al. in [2] show that the routing overhead is consistently lower for both LAR schemes than for ooding. As the hosts become more mobile, the number of routing packets begin to increase for all routing protocols. Routes break more often with higher node mobility, and so the routing overhead increases. However, both LAR schemes still provide much lower rate of increase than ooding due to small request zones. 4.3.2 Resource usage:

With LAR, the number of routing related packets received by various nodes is much lower than with ooding, because LAR limits the route discovery to a much smaller request zone. There is not a signicant increase in CPU usage at each node. Each node is only required to do simple additions and multiplications in order to determine whether it should forward the route request packets. Let n be the number of nodes in a network. Unlike the static routing protocols, where each node caches detailed route sequences to (n 1) nodes, each node in LAR only needs to cache the location and speed information of at most (n 1) nodes. 4.3.3 Scalability:

When n is small (such as 15 nodes), both LAR schemes give similar routing overhead as in ooding. However, when the number of nodes is increased, the amount of routing overhead for the ooding algorithm increases more rapidly than for the LAR schemes. In fact, both LAR schemes are extremely scalable.

Comparisons

We now consider the dierences between each protocol on several points: resiliance to change, resource usage, path discovery costs, scalability, special hardware needs, and security.

5.1

Resiliance to Network Topology Changes

all three detect partitions the same with timeouts AODV has the advantage that it can detect some network partitions in advance of demand (because of trac monitoring and hello messages to active nodes. DSR has the advantage that a host can make use of error packets it hears that are not destined for it. Because of the way DSR truncates its view of the connected network, one error packet can invalidate several routes. Also, DSR does not consider bandwidth across a hop to be bidirectionally equivalent. LAR utilizes knowledge of location to reduce path discovery overhead and can predict changes.

12

We believe that DSR is more ecient at realizing and reacting to network topology changes. LAR could be used in conjunction with either AODV or DSR to further reduce the cost of path discovery.

5.2

Resource Usage

Memory AODV is the most ecient in memory usage in contrast to DSR or LAR. DSR stores the complete path for each route it uses (bounded by O(n2 ) over all hosts) and LAR keeps track of position and velocity information (also bounded by O(n2 )), where AODV simply stores next-hop information at each node. CPU DSR requires additional processing overhead to monitor all adjacent network trac. AODV does not, making it more ecient in this case. LARs additional overhead appears negligible in addition to the other two. Each protocol incurs the cost of forwarding packets (acting as a router), but this is the same cost in each protocol. Bandwidth Overhead LAR is the winner in this category since it can use specialized location information to limit the amount of network ooding that occurs. DSR, with its promiscuous optimizations and absence of hello packets, has a low overhead in quiescent and slowly changing networks.

5.3

Path Discovery Costs

Each protocol performs in O(D) time in the worst case, where D is the diameter of the network. With respect to network bandwidth used, LAR is the most ecient for the reasons given above. In the worst case each protocol resorts to ooding the entire network, which is O(n) packets sent.

5.4

Scalability

AODV has a clear advantage over DSR in scalability, because DSR stores redundant information and uses more memory and CPU resources. LAR can be used to enhance scalability since it limits the amount of ooding a network performs.

5.5

Special Hardware Needs

LAR requires a GPS unit to function properly, which also requires extra power. DSR could benet from special link-layer hardware which has the protocol built in, osetting the cost of promiscuous network monitoring from the CPU to the network interface.

5.6

Security

In ad hoc protocols, each host acts as a router with full privileges to forward packets, advertise routes to other hosts, and to announce that a link has gone down. Because of this, each host in an 13

ad hoc network must have full trust in every other host, which does not lend itself well to security. A host acting in a byzantine manner may provide wrong information for other hosts. Through the use of cryptography, data on the network may be kept private, but information about routes and whom a host is communicating with are not private. Therefore, these do not appear to be very secure protocols against attacks. Since each host is trusted equally (there is no notion of a more trusted site), it does not appear that security can be retrotted easily onto one of these protocols. In addition, the LAR protocol is particularly hard to use securely because a host reveals location information about itself.

Conclusion

No protocol is a clear winner in all cases presented. However, it appears that for small, dynamic networks, DSR would work best, and for larger, more static networks AODV will be best. LAR would benet either, especially when there is host movement, and its benets would increase as networks grow larger.

References
[1] D. Johnson and D. Maltz. Dynamic Source Routing in Ad Hoc Wireless Networks. In Computer Communications Review - Proceedings of SIGCOMM 96, Aug. 1996. [2] Y. Ko and N. Vaidya. Location-Aided Routing (LAR) in Mobile Ad Hoc Networks. In MobiCom 98 Proceedings of Fourth Annual ACM/IEEE International Conference on Mobile Computing and Networking, pp. 66-75, Oct. 1998. [3] C. Perkins and P. Bhagwat. Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers. In Computer Communication Review, vol. 24, (no. 4), pp. 234-44, Oct. 1994. [4] C. Perkins and E. Royer. Ad-hoc On-Demand Distance Vector Routing. In Proceedings WMCSA 99 Second IEEE Workshop on Mobile Computing Systems and Applications, pp. 90-100, Feb. 1999.

14