A Performance Comparison ofMulti-Hop Wireless Ad Hoc NeWork Routing

Josh Broth David A. Maltz David B. Johnson Yih-Chun Hu

Computer Science DepartmentCarnegie Mellon University

Pittsbur~, PA 15213

http: //w.monarch. cs .cmu. edu/

Abstract

An ad hoc networkis a collwtion of wirelessmobilenodes dynamicallyforminga temporarynetworkwithouttheuseof anyexistingnetworkirrfras-tructureor centralizedadministration.Dueto the limitedtransmissionrangeof ~vlrelessnenvorkinterfaces,multiplenetwork“hops”maybe neededforonenodeto exchangedata ivithanotheracrox thenetwork.Inrecentyears,a ttiery of nelvroutingprotocols~geted specificallyat this environmenthavebeen developed.but little pcrfomrartwinformationon mch protocoland no ralistic performancecomparisonbehvwrrthem ISavailable. ~Ispaper presentsthe results of a derailedpacket-levelsimulationcomparingfourmulti-hopwirelessad hoc networkroutingprotocolsthatcovera rangeof designchoices: DSDV,TORA, DSR and AODV. \Vehave extendedthe /~r-2networksimulatorto accuratelymodelthe MACandphysical-layerbehaviorof the IEEE 802.1I wirelessLANstandard,includinga realisticwtrelesstransmissionchannelmodel, and present the resultsof simulationsof net(vorksof 50 mobilenodes.

1 Introduction

In areas in which there is little or no communication infrastructureor the existing infrastructure is expensive or inconvenient to use,wireless mobile users may still be able to communicate through theformation of an adhocrte~ork. In such anehvork, each mobile nodeoperates not only as a host but also as a router, forwarding packetsfor other mobile nodes in the network that may not be within directwireless tmnsrnission range of each other. Each node participates inan ad hoc routing protocol that allows it to discover “muki-hop” pathsthrough thenehvorkto anyothernode. Theideaofadhocnehvorkingis sometimes also called infras[mcturelms neworfing [13], since themobile nodes in the network dynamically establish routing amongthemselves to form their own nehvork “on the fly? Some examples ofthe possible uses of ad hoc nehvorting include students using laptopcomputers to participate in an interactive lecture, business associatessharing information during a meeting, soldiers relaying informationfor situational awareness on the battlefield [12, 21], and emergencydisaster relief personnel coordinating efforts after a hurricane orearthquake.

This work was supported in part by Ihe National Science Foundation @S~ underCAREER AwardNCR-9S027M, by the Air Force hfateriet Command (AFLIC) underDARP,\ contract number F19628-9W~61, and by the AT&T Foundation under aSpecial Purpose Grant in Science and Enginwnn& Datid Nfaltzwas atso supportedundrr mr IBhl Coopcmtive Fellowship, and Mh-Chun Hu was also supported by anNSF Graduate Fellowship. The views and conclusions contained here arc those of theauthors and should not be interpretedas neces~ly representing the officialpolicies orendomements,eitherexpressorimplie& ofNSF, AFhfC, DARPA,theAT&TFoundation,~hf, Carnegie hlellon Unirersi~, or the U.S. GovernsnenL

Pemtission to make digital or hard copiesof all or partof thisworkforpersonalor classroomuse is grantedivithoutfeeprovidedth3tcopiesarenot madeor distributedforprofitor commercialadvantageand thatcopicabear thisnoticemrdthe fullcitationon the firstpage.Tocopyothenvise,to republish,to poston serversor to redistributeto lists,requirespriorspecificpermissionarrdor a fee.MOBICOM 9S Dallas Texas USACopyrightACM19981-58113~35-ti98110...S00OO 85

Protocols

Jo~eta Jetcheva

Many different protocols have been proposed to solve the multi-hop routing problem in ad hoc nehvorks, each based on differentassumptions and intuitions. However, little is known about the actualperformance of these protocols, and no attempt has previously beenmade to directly compare them in a realistic manner.

This paper is the first to provide a realistic, quantitative analysiscomparing the performance of a variety of multi-hop wireless ad hocnetwork routing protocols. We present results of detailed simulationsshowing the relative performance of four recently proposed ad hocrouting protocols DSDV [18], TORA [14, 15], DSR [9, 10, 2]. andAODV [17]. To enable these simulations, we extended the ns-2nehvork simulator [6] to include

●

●

●

●

Node mobility.A realistic physical layer including a radio propagation modelsuppotiing propagation delay, capture effects, and carriersense [20].Radio netiork inte~aces with properties such as transmissionpower, antenna gain, and receiver sensitivity.The IEEE 802.11 Medium Accas Control (MAC) protocol usingthe Distributed Coordination Function (DCF) [8].

Ourrestdts inthispaperarebasedon simulations ofan ad hoc networkof 50 wireless mobile nodes moving about and communicating witheach other. We analyze the performance of each protocol and explainthe design choices that account for their performance.

2 Simulation Environment

m is a discrete event simulator developed by the University ofCalifornia at Berkeley and the VINT project [6]. While it providessubstantial support for simulating TCP and other protocols over con-ventional nehvorks, it provides no support for accurately simulatingthe physical aspects ofmulti-hop wireless nehvorks or the MAC pro-tocols needed in such environments. Berkeley has recently releasedns code that provides some support for modeling wireless LANs, butthis code cannot be used for studying multi-hop ad hoc networks asit does not support the notion of node position; there is no spatialdiversity (all nodes are in the same collision domain), and it can onlymodel directly connected nodes.

In this section, we describe some of the modifications we made tons to allow accurate simulation of mobile wireless nehvorks.

2.1 Physical and Data Link Layer Model

To accurately model the attenuation of radio waves behveen anten-nas close to the ground, radio engineers typically use a model thatattenuates the power of a signal as 1/rz at short distances (T is thedistance between the antennas), and as l/r4 at longer distances.The crossover point is called the reference distance, and is typicallyaround 100 meters for outdoor low-gain antennas 1.5m above theground plane operating in the 1–2GHz band [20]. Following thispractice, our signal propagation model combines both a free spacepropagation model and a two-ray ground reflection model. When atransmitter is within the reference distance of the receiver, we use

——

the free space model where the signal attenuates as l/T2. Outside ofthis distance, we use the ground reflection model where the sigudfalls off as l/T4.

Each mobile node has a position and a velocity and moves aroundon a topography that is specified using either a digitd elevation mapor a flat grid. The position of a mobile node can be crdculated asa function of time, and is used by the radio propagation model tocdcdate the propagation delay from one node to another and todetermine the power level of a received signal at each mobile node.

Each mobile node has one or more wireless network interfams,with dl interfaces of the same type (on dl mobile nodes) linkedtogether by a single physical chmel. When a network interfacetransmits a packet, it passes the packet to the appropriate physicalchannel object. This object then computes the propagation delayfrom the sender to every other interfam on the channel and schedtiesa “packet reception” event for each. This event notifies the receivinginterface that the first bit of a new packet has arrived. At this time,the power level at which the packet was received is compared to twodifferent values: the carrier sense threshold and the receive threshold.If the power level falls klow the carrier sense threshold the packetis discarded as noise. If the received power level is above the carriersense threshold but below the receive threshold the packet is markedas a packet in error before beiig passed to tie MAC layer. Otherwise,the packet is simply handed up to the MAC layer.

Once the MAC layer receives a packe~ it checks to insure that itsreceive state is presentiy “ide? If the receiver is not ide, one of twothings cm happen. If the power level of the packet aheady beingreceived is at least 10 dB greater tha the received power level of thenew packet, we assume capture, discard the new packet, and allowthe receiving interface to continue with its current receive operation.Otherwise, a collision occurs and both packets are droppe~

If the MAC layer is ide when an incoming packet is passed upfrom the network interface, it simply computes the transmission timeof the packet and scheddes a “packet reception complete” event foritse~. When this event occurs, the MAC layer verifies that the packetis error-free, performs destination address filtering, and passes thepacket up the protocol stack.

2.2 Medium ACCMControl

The link Iayerofoursimtiatorimplements the complete EEE 802.11standard [8] Medium Access Control WC) protocol DistributedCoordination Function ~~ in order to accurately model thecontention of nodes for the wireless medium. DCF is similar toMACA [11] and MACAW [1] and is designed to use both physi-cal carrier sense and virtwl cam.er sense mechanisms to reduce theprobability of collisions due to hidden termin~s. The transmission ofeach unicast packet is preceded by a Request-to-SenWClear-to-Send@TSICTS) exchange that reserves the wireless chael for trans-mission of a data packet. Each correcfly received unicast packet isfollowed by an Acknowledgment (AcK) to the sender, which retrsms-mits the packet a limited number of times until this ACK is received.Broadcast packets are sent ordy when virtual and physical carriersense indicate that the medium is clear, but they are not preceded byan RTS/CTS and are not acknowledged by their recipients.

23 Addrws Resolution

Since the routing protocols dl operate at the nehvork layer using fPaddresses, an implementation of ARP [19], modeled after the BSDUnix implementation [23], was included in the simulation and usedto resolve F addresses to link layer addresses. The broadcmt natureof an ARP ~Q= packet (Section 6.3) and the interaction of ARPwith on-demmd protocols (Section 6.4) make ARP an importantdeti of the simdation.

2.4 Packet Buffering .

Each node has a queue for packets awaiting transmission by thenetwork interface that holds up to 50 packets and is managed in a

86

droptail fashion. Each on-demand routing protocol (i.e., TORA,DSR, or AODV), can buffer separately an additiond 50 packets thatthat are awaiting discove~ of a route through the nehvork.

3 Ad Hoc Netiork Routtig Protocok Studied

In this section, we briefly describe the key features of the DSDV,TORA, DSR, and AODV protocols studied in our sirmdations. Werdso describe the partictiar parameters that we chose when imple-menting each protocol.

The protocols were care~y implemented according to their spec-ifications published as of April 1998 and based on clfications ofsome issues from the designers of each protocol and on our ownexperimentation with them. b particdar, during the process of im-plementing each protocol and analyzing the restits from early simu-lation runs, we discovered some modifications for each protocol thatimproved its performance. The key improvements to each protocolae higtiighted in the respective protocol descriptions below. Wedso made the following improvements to W of the protocols:

●

●

●

3.1

To prevent synchronization, periodic broadcasts and packetssent in response to the reception of a broadcast packet werejittered using a random delay uniforrrdy distributed between Oand 10 milliseconds.To insure that routing information propagated through the net-work in a timely fashion, routing packets being sent were queuedfor transmission at the head of the nehvork interface transmitqueue, whereas W otier packets (ARP and data) were insertedat tie end of the interface ~mit queue.Each of the protocols used link breakage detection feedbackfrom the 802.11 MAC layer that indicated when a packet coddnot be forwarded to its next hop, with tie exception of DSDVas explained in Section 3.1.2.

D=tination-Sequenced Distance Vector @SDm

DSDV [18] is a hopby-hop distance vector routing protocol requir-ing each node to periodicdy broadcmt routing updates. The keyadvantage of DSDV over traditionrd distance vector protocols is thatit guarantees Ioopfreedom.

3.1.1 Basic Mectiisms

Each DSDV node maintains a routing table fisting the “next hop” foreach reachable destination. DSDV tags each route with a sequencenumber and considers a route R more favorable than R’ if R has agreater sequence number, or if the hvo routes have equal sequencenumbers but R has a lower metic. Each node in the network ad-vertises a monotonically increasing even sequence number for itself.When a node B decides that its route to a destination D has broken,it advertises the route to D with an itinite metric and a sequencenumber one greater than its sequence number for the route that hasbroken (making an odd sequence number). This causes any nodeA routing packets through B to incorporate the itite-metric routeinto its routing table until node A hears a route to D with a highersequence number.

3.1.2 Implementation Decisions

We did not use tink layer breakage detection from the 802.11 MACprotocol in obtaining the DSDV data presented in this paper, becauseafter implementing the protocol both with and without it, we foundthe performance significantly worse with the hnk layer breakagedetection. The reason is that if a neighbor N of a node A detectsthat its link to A is broken, it will broadcast a triggered route updatecontaining an infinite metric for A. The sequence number in thistriggered update will be one greater than the last sequence numberbroadcast by A, and therefore is the highest sequence nurnberexistinganywhere in the network for A. Each node that hears this update willrecord an ifinite metric for destination A and will propagate the

1-. —.. ._— -. -. . .. ——

TableI Consmts usedin the DSDV-SQsimulation.

Periodicrouteupdateinteti 15sPeriodicupdatesmissedbeforefinkdeclaredbroken 3Initialtiggered updateweightedsetig time 6sWeightedsetig timeweightingfactor 718Routeadvertisementaggregationdme 1sMaximumpacketsbufferedpernodeperdestination 5

information further. This renders node A unreachable from dl nodesin the network until A broadcasts a newer sequence number in aperiodic update. A will send this update as soon as it learns of theirdiuite metric &lrrg propagatd for iL but large numbers of packetscan be dropped in the meantime.

Our implementation uses both Ml and increment updates asrequired by the protocol’s description. However, the published de-scription of DSDV [18] is ambiguous about specitilng when trig-gered updates shotid be sent. One interpretation is that the receiptof a new sequence number for a destination shotid cause a triggeredupdate. We crdl this approach DSDV-SQ (sequence number). Theadvantage of this approach is that broken links wti be detected androuted ~ound as new sequence numbers propagate around the broken~i and create dtemate routes. The second interpretation, which wecrdl simply DSDV, is that ordy the receipt of a new metric shotidcause a triggered update, and that the receipt of a new sequence rmm-ber is not sufficiently impomt to incur the overhead of propagatinga triggered update.

We implemented both DSDV-SQ and DSDV and found that whileDSDV-SQ is much more expensive in terms of overhead it providesa much better packet defivery ratio inmost cases. The second scheme(DSDw is much more conservative in terms of routing overhea~ butbecause fink breakages are not detected as quic~y, more data packetsare dropped All of the resdts in this paper use DSDV-SQ, with theexception of Section 6.2, which comp=es this with DSDV.

Table I Hsts the constants used in our DSDV-SQ simdation.

3.2 TemporWyOrdered Routing Algorithm (TORA)

TORA [14, 15] is a distributed routing protocol breed on a “linkreversal’ dgorithrn. It is designed to discover routes on demand,provide mrdtiple routes to a destination, estabfish routes quicuy,md minimize communication overhead by Iocdizing rdgorithrnicreaction to topological changes when possible. Route optimrdity(shortest-path routing) is considered of seconm importrmce, andlonger routes are often used to avoid tie overhead of discoveringnewer routes.

The actions taken by TORA can be described in terms of waterflowing downhill towards a destination node through a nehvork oftubes that models the routing state of the red nehvork. The tubesrepresent W behveen nodes in the network, the junctions of tubesrepresent the nodes, and the water in the tubes represents the packetsflowing towards the destination. Each node has a height with respectto the destination that is computed by the routing protocol. If a tubebetween nodes A and B becomes blocked such that water can nolonger flow through it, the height of A is set to a height greater thanthat of any of its remaining neighbors, such that water will now flowback out of A (and towards the other nodes that had been routingpackets to the destination via A).

3.2.1 Basic hlectinisms

At each node in the nehvork, a Iogicrdly separate copy of TORA isrun for each destination. When a node needs a route to a particuhrrdestination, it broadcmts a Q~RY packet containing the address ofthe destination for which it requires a route. This packet propagatesthrough the network until it reaches either the destination, or anintermediate node having a route to the destination. The recipientof the QHY then broadcasts an UPDAmpacket listing its height

87

with respect to the destination. As this packet propagates throughthe network, each node that receives the UPDA~ sets its height to avalue greater than the height of the neighbor from which the UPDA~was received. This has the effect of creating a series of direetdlinks from the ongind sender of the Q~Y to the node that inititiygenerated the UPDA~.

When anode discovers that a route to a destination is no longervdl~ it adjusts its height so that it is a Iocd maximum with respectto its neighbors and transmits an UPDA~ packet. If the node has noneighbors of finite height with respect to this destination, then thenode instead attempts to discover a new route as described above.When anode detects a network partition, it generates a ~Rpacketthat resets routing snte and removes invalid routes from the network.

TORA is layered on top of MP, the htemet MA~TEncapsdation Protocol [5], which is required to provide reliable,in-order detivery of dl routing control messages from a node to eachof its neighbors, plus notification to the routing protocol whenever afink to one of its neighbors is created or broken. To reduce overheadfMEP attempts to aggregate marry TORA and MP control mes-sages (which ~P refers to as objec~s)together into a single packet(as an object block) before transmission. Each block carries a se-quence number and a response list of other nodes from which an ACKhas not yet been received, and ordy those nodes ACKthe block whenreceiving i~ WP retransmits each block with some period, and con-tinues to retransmit it if needed for some mtimurn toti period afterwhich time, the link to each unacknowledged node is declared downand TORA is notified. MP cart rdso provide network layer addressresolution, but we did not use tis service, as we used ARP [19] withfll four routing protocols. For link status sensing and maintaininga list of a node’s neighbors, each ~P node periodically transmitsa BmCON (or “BWCON-eqrdvdent”) packet, which is ~wered byeach node hearing it with a ~Lo (or “~Lo-equivdent”) packet.

3.2.2 Implementation Decisions

~P must queue objects for some period of time to allow possi-ble aggregation with other objects, but the ~P specification [5]does not define this time period and we discovered that the ovedlperformance of the protocol was very sensitive to the choice of thisvalue. After significant experimentation, we chose as the best ba-lancebetween packet overhead and routing protocol convergence, toaggregate ~LLO and ACKpackets for a time unifotiy chosen be-tween 150 ma and 250 rns, and to not delay TORA routing messagesfor aggregation. The reason for not delaying these messages is thatthe TORA link reversal process creates short-lived routing loops thatexist from the time that the hnk-reversd starts until the time that dlnodes that need to be aware of the reversal receive the correspondingUPDA~ (Section 5.2). Delaying the transmission of TORA routingmessages for aggregation, coupled with any queuing delay at thenetwork interface, allows these routing loops to last long enough thatsignificrmtnumbers of data packets me dropped.

The TORA and I~P specifications [15,5] do not define the pre-cise semantics of rehable object delivery required by TORA, butexperimentation showed that very strong semantics must be pro-vided in order to prevent the creation of long-lived routing loops.k partictia, rdl TORA objects must be delivered reliably and inorder, without any duplication. Additiondly, rdl neighhring nodesin the ad hoc network must have a consistent picture of the networkwith regard to each destination. This impfies that anytime a node Adecides its link to a neighbor B hm gone down, B mwt dso decidethat the link to A has gone down.

Wehave implemented ~P to provide this functionrdity,althoughthe retransmission timeout and total number of attempts are notspecified by IMEP [5]. We chose a retransmission period of 500 rnsand atoti timeout of 1500rns, dthoughbaseduprr ourobsewations,au adaptive retransmission timer should be added to the protocol. h-order delivery is enforced by, at each receiver node B, ordypassing

————

.

TableU Constantsusd in theTORAsimulation.

I BMCONwriod I Is I

Tme afterwhicha W is decked downif no BWCONor ~s-o uackets were exchanged I.Tme afterwhichan objectblockis re~nritted if no 500macknowledmnentis received

an object blwk from some node A to TORA if the block has thesequence number that ~P at B next expects from A. Blocks withIowersequence numbers may generate another ACKbutae otherwisedropped Blocks with higher sequence numbers are queued until themissing blocks arrive or until the mtimum 1500 rns total timeoutexpires, at which point B can be certain the object will never beretransmitted. By this poin~ A will have declared its link to B down,since it will not have received an ACKfor the missing packet. Togive the routing protocol at B a picture consistent with that seen bythe prot~ol at A, the ~P layer at B notifies its routing protocolthat the link to A is down, then notifies it the link is back up, andthen processes the queued packets.

Finally, we improved MFs method of link status sensing byreducing it to a point that functions with minimum overhead yetstill maintains dl of the required fink status information. Duringour experimentation with ~P, we found that nodes need ordysend BMCON messages when they are disconnected from dl othernodes. Suppose two nodes A and B, both of which have neighbors,transmit a single WO listing each of tieir neighbors once perBMCON perid If abi-directiomd fink exists between A and B, bothnodes WU overhear each other’s mLLOS and rdlother trmssrnissions,causing each node to create a link to the other with “incoming”status. In subsequent -O messages, A and B will list each other,cotirming that a bi-directionti link exists between them.

Table ~ lists tie constants used in our TORA simtiation.

33 Dynamic Source Routing @SR)

DSR [9, 10,2] uses source routing rather than hopby-hop routing,with each packet to be routed carrying in its header the complete,ordered Est of nodes through which the packet must pass. The keyadvantage of source routing is that intermediate nodes do not need tomaintain uptwdate routing information in order to route the packetsthey forward since the packets themselves tieady contain dl therouting decisions. This fact, coupled with the on-demmd nature ofthe protocol, eliminates the need for the Priodic route advertisementand neighbor detection packets present in other protocols.

3.3.1 Basic Mecbnisms

The DSR protocol consists of two mechanisms: Route Discoveryand Route Maintenance. Route Discovery is the mechanism bywhich a node S wishing to send a packet to a destination D obtainsa source route to D. To prforrn a Route Discovery, the source nodeS broadcasts a Rom mQ~T packet that is flooded through thenetwork in a controlled manner and is answered by a Rom ~LYpacket from either the destination node or another node that hews aroute to the destination. To reduce the cost of Route Discovery, eachnode maintains a cache of source routes it has learned or overheardwhich it aggressively uses to limit the frequency md propagation ofRom WQ~TS.

Route Maintenance is the mechanism by which a packet’s senderS detects if the network topology has changed such that it can nolonger use its route to the destination D because hvo nodes listedin the route have moved out of range of each other. When RouteMaintenance indicates a source route is broken, S is notified with

88

Table~ ConstarrKusti in theDSRsimuhtion.

fime between retransmittedROW WQ~S(exponentitiybackedo~

500mI

Ske of source routeheader-g n addresses 4n + 4 bytes

~meout fornonpropagatingsearch 30 m

Tne to hold packets awaiting routes 30 s

Maxrate for sending ~tuitous ~LYs for a route 1/s

a Ro~ ERRORpacket. The sender S can then attempt to use anyother route to D tieady in its cache or crm invoke Route Discoveryagain to find a new route.

3.3.2 Implementation Decisions

Using the suggestions from the published description of DSR [10],we have optimized our implementation in a number of ways.

Although the DSR protocol supports unidirectional routes, EEE802.11 requires an RTS/CTS~attiACK exchange for W unicastpackets, limiting the routing protocol to using ordy bidirectiomdlinks in delivering data packets. We implemented DSR to discoverordy routes composed of bidirectional finks by requiring that a nodereturn rdl Ro~ ~PLY messages to the requester by reversing thepath over which the Rom ~Q~ packet came. If the path takenby a Ro~ ~Q~ contained unidirectionrd links, then the cor-responding Ro~ ~LY wi~ not reach the requester, preventing itfrom learning the unidirectional link route.

k Route Discovery, a node fist sends a Rom WQ~T with themaximum propagation ~it @op Emit) set to zero, prohibhing itsneighbors from rebroadcmting it. At the cost of a singe broadcastpacket, this mechanism ~ows a node to query the route caches ofW its neighbors for a route ad rdso optimizes the case in which thedestination node is adjacent to the source. E this nonpropagatingsearch times out, a propagadrrg Rom NQWT is sent.

Nodes operate their network interfaces inpromiscuow mode, dis-abling the interface’s address filtering and causing the nehvork proto-col to received packets that the interface overhears. These packetsare scanned for use~ source routes or Rom ERRORmessages andthen discarded. This optimization Wows nodes to learn potentiallyusefl information, while causing no additiond overhead on the lim-ited nehvork badwidth.

Furthermore, when a node overhears a packet not addressed toitself, it checks the unprocessed portion of the source route in thepacket’s header. E the node’s own address is present, it knows thatthis source route cotid bypass the unprocessed hops preceding it inthe route. The node then sends a gratuitous Rom ~LY messageto the packet’s source, giving it the shorter route without these hops.

Finrdly, when an intermediate node forwarding a packet discoversthat the next hop in the source route is unreachable, it examines itsroute cache for another route to the destination. If a route exists, thenode replaces the broken source route on the packet with the routefrom its cache and retransmits the packet. If a route does not exist inits cache, the node drops the packet and does not begin anew RouteDiscovery of its own.

Table ~ Ests the constants used in our DSR simtdation.

3.4 Ad Hoe On-Demand Distance Vector (AOD~

AODV [17] is essentially a combination of both DSR and DSDV.It borrows the basic on-demand mechanism of Route Discovery andRoute Maintenance from DSR, plus the use of hopby-hop routing,sequence numbers, and periodic beacons from DSDV.

3.4.1 Basic Mechnisrns

When a node S needs a route to some destination D, it broad-casts a Ro~ mQmT message to its neighbors, including the lastknown sequence number for that destination. The Rom mQ~Tis flooded in a controlled manner through the network until it reaches

I—.,.. . . ,<.. -- ---—

-—

a node that has a route to the destination. Each node that forwardsthe ROW WQ~T creates a reverse route for itself back to node S.

When the Rom mQmT reaches anode with a route to D, thatnode generates a Rom WPLY that contains the number of hopsnecessary to reach D and the sequence number for D most recenflyseen by the node generating the WPLY. Each node that participatesin fonvarding this ~PL>’ back toward the originator of the Ro~~Qm (node S), creates a foward route to D. The state createdin each node along the path from S to D is hopby-hop state that is,each node remembers ody the next hop and not the entire route, aswodd be done in source routing.

h order to maintain routes, AODV norrndly requires that eachnode periodically transmit a ~Lo message, with a defadt rate ofonce per second Failure to receive three consecutive -LO mes-sages from a neighbor is taken as an indication that the fink to theneighbor in question is down. Alternatively, the AODV specificationbriefly suggests that anode may use physical layer or link layer meth-ods to detect Iinkbreakages to nodes that it considers neighbors [17].

When a hnk goes down, any upstrem node that has recenflyforwarded packets to a destination using that link is notified via anUNSOLIC~D Rom WLY containing an ifinite metric for thatdestination. Upon receipt of such a Rom ~LY, a node mustacquire a new route to the destination using Route Discovery asdescribed above.

3.4.2 Implementation Decisions

We initially implemented AODV using periodic-O messages forlink breakage detection as described in the AODV specification [17].For comparison, we dso implemented aversion of AODV that we crdlAODV-LL (link layer), instead using only ~i layer feedback from802.11 as inDSR, completely eliminating the standardAODV WLLOmechanism. Such an approach saves the overhead of the periodic~LLO messages, but does somewhat change the fundamentrd natureof the protocol; for example, dl Enk breakage detection in AODV-LLis ordy on-demand, and thus a broken link cannot be detected untila packet needs to be sent over the fink, whereas the periodic ~LOmessages in standard AODV may allow broken Enks to be detectedbefore a packet must be fonvmded. Nevertheless, we found our alte-rnateversion AODV-LL to perform sigrrificanflybetter than standardAODV,and so we report measurements from that version here.

h addition, we dso changed our AODV implementation to use ashorter timeout of 6 seconds before retrying a Rom MQ~T forwhich no Ro~ ~LY has been received &P-WAIT_T~).The value given in the AODV specification was 120 seconds, basedon the other constants specified there for AODV. However, a Row~LY can ody be returned if each node along the discovered routestill has a reverse route along which to return iL saved from when theRom ~QH was propagatd. Sin@ the specified timeout fortbisreverse route information in each node is ordy 3 seconds, the ongindRom ~LY timeout value of 120 seconds urmecesstily limitedthe protocol’s abfity to recover from a dropped Rom ~QW orRom -LY packeL

Table N lists the cons~ts used in our AODV-LL simdation.

4 Metiodolofl

The ovedl god of our experiments was to measure tie ability ofthe routing protocols to react to network topology change whilecontinuing to successtily deliver data packets to their destinations.To measure this ability, our basic methodology was to apply to asimdated network a variety of wor~oads, in effect testing with eachdata packet originated by some sender whether the routing protocolcan at that time route to the destination of that packet. We werenot attempting to measure the protocols’ performance on a particdarwor~oad taken from red life, but rather to measure the protocols’performance under a range of conditions.

8

TableW ~nstanK usd in theAODV-LLsirmdation.

Timefor whicha routeis consideredactive 3M sLifetimeona Rom _LY sentby destinationnode 600SNumberof timesa Rom WQ_ is retied 3Tme beforea ROW ~Qm is retried 6s~me for whichthebroadwt id for a forwardedRo=WQ~ is kept

3s

Timefor whichreverserouteinformationfor a Ro~~LY k kept

3s

Tne beforebrokenfinkis deleti fromroutingtable 3sMC layerfinkbr~ge detection yes

Our protocol evaluations are basedon thesimtiationof 50wirelessnodes forming an ad hoc network, moving about over a rectan~ar(1500m x 300m) flat space for 900 seconds of simdated time. Wechose a rectan@ar space in order to force the use of longer routesbetween nodes than wotid occur in a square space with equal nodedensity. me physical radio characteristics of each mobile node’s net-work interface, such as the antenna gain, transmit pwer, and receiversensitivi~, were chosen to approximate the Lucent WaveLAN [22]direct sequence spread spectrum radio.

horder to enable direct, fair comparisons between the protocols,it was cnticd to chrdlenge the protocols with identicd loads andenvirorunenti conditions. Each run of the simtiator accepts as inputa scemn”o file that describes the exact motion of each node and theexact sequence of packets originated by each node, together with theexact time at which each change in motion or packet origination isto occur. We pre-generated 210 different scenario files with varyingmovement patterns and tic loads, and then ran dl four routingprotocols against each of these scenario files. Since each protocolwas challenged in an identicd fashion, we can direcfly compare theperformance restits of the four protocols.

4.1 Movement Model

Nodes in the simtiation move according to a model that we cdl the“random waypoint” model [10]. The movement scenario files weused for each simdation are characterized by apause time. Each nodebegins the simtiationby remaining stationq forpause time seconds.It then selects a random destination in the 1500m x 300rn space andmoves to that destination at a speed distributed unifotiy between Oand some maximum speed. Upon reaching the destination, the nodepauses again forpause time seconds, selects another destination, andproceeds there as previously descnbe& repeating this behavior forthe duration of the simdation. Each simrdation ran for 900 secondsof simdated time.

We ran our simulations with movement patterns generated for 7different pause times: O, 30, ~, 120, 300, 600, and 900 seconds.A pause time of Oseconds corresponds to continuous motion, md apause time of 900 (the length of the simdation) corresponds to nomotion.

Because the~rfomrmce of the protocols is very sensitive to move-ment pattern, we generated scenario files with 70 different movementpatterns, 10 for each vrdue of pause time. All four routing protocolswere run on the sme 70 movement patterns.

We experimented with NO different maximum s~eds of nodemovement. We primarily report in this paper data horn simdationsusing a maximum node speed of 20 meters per second (average s~d10 meters per second), but dso compare this to simdations using amaximum speed of 1 meter per second.

4.2 Communication Model

As the god ofoursimulation was to compare theperformanceof eachrouting protocol, we chose our trtic sources to be constant bh rate(CBR) sources. When defining the parameters of the communicationmodel, we experimented with sending rates of 1, 4, and 8 packets

. . .. . .

4

- -456789 10

- mme m [m

FW 1 D~tibution of the sho~t path ati~ble to eachapptimtionpacketori@natedoveratl smnados.

~r secon~ networks containing 10, 20, and 30 CBR sources, andpacket sizes of 64 and 1024 bytes.

V@g the number of CBR sources was approximately equivalentto varying the sending rate. Hence, for these simtdations we chose toh the sending rate at 4 packets per second and used three differentcommunication patterns corresponding to 10,20, and 30 sources.

When using 1024byte packets, we found that congestion, dueto lack of spatial diversity, became a problem for dl protocols andone or two nodes wodd drop most of the packets that they receivedfor forvfarding. As none of the studied protocols performs loadbalancing, and the god of our amdysis was to determine if the routingprotocols codd consistently track changes in topology, we attemptedto factor out congestive effects by reducing the packet size to 64bytes.This sdler packet size still provides a good test of the routingprotocols, since we are sti~ testing their ability to determine routesto a destination with the same frequency (a totrd of 40, 80, or 120times per second).

All communication patterns were peer-tmpeer, and connectionswere started at times tmifody distributed behveen Oand 1S0 sec-onds. The three communication patterns (10, 20, and 30 sources),taken in conjunction with the 70 movement patterns, provide a totrdof 210 different scenario files for each maximum node movementspeed (1 @s and 20 ds) with which we compared the four routingprotocols.

We did not use TCP sources because TCP offers a conformingload to the network, meaning that it changes the times at whichit sends packets based on its perception of the networks ability tocarry packets. As a restdL both the time at which each data packet isoriginated by its sender and the position of the node when sendingthe packet wotid differ between the protocols, preventing a directcomparison between them.

4S Scenario Charactetilm

To characterize the chrdlenge our scenarios placed on the routingprotocols, we measured the lengths of the routes over which theprotocols had to deliver packets, and the toti number of topologychanges in each scenario.

When each data packet is originate~ an intemd mechanism of oursimtdator (sepmte from the routing protocols) cdctdates the shortestpath between the packet’s sender md its destination. The packet islabeled with this information, which is compared with the numberof hops actu~y taken by the packet when received by the intendeddestination. The shortest path is cdctdated based on a nomimdtransmission range of 250m for each radio and does not account forcongestion or interference that any partictiar packet might see.

TableV Averagenrrrnberof ~ connectivitychangesdtingeach~second simdation as a fmrctionof pawe time.

#ofcomrectivityChangu%we Time

1ds 20 ds

o 898 1185730 908 898460 792 7738

120 732 5390300 512 2428600 245 1270900 0 0

Figure 1 shows the distribution of shortest path lengths for dlpackets over the 210 scenario ties at 1 ds and 20 tis that we used.The height of each bar represents the number of packets for whichthe destination was the given distance away when the packet wasoriginated. The average data packet in our simtdations had to cross2.6 hops to reach its destination, and the farthest reachable node towhich the routing protocols had to deliver a packet was S hops away.

Table V shows the average number of link connectivity changesthat occurred during each of the sirntiations runs for each vahreof pause time. We count one fink connectivity change whenever anode goes into or out of direct communication range with anothernode. For the specific scenarios we used the 3@second pause timescenarios at 1 ds actudy have a shghfly higher average rate of linkcormectivi~ change than the @second pause time scenarios, due toan artifact of the random generation of the scenarios. This artifactis rdso visible as a slight bump at a pause time of 30 seconds in theperformance graphs we present for 1 tis in Section 5. I

4.4 Vrdidation of the Propagation Model and WC Layer1

Our propagation model uses standard equations and techniques, andit was vefied by an expert in radio propagation modeling. Weanalyzed the power and simtdated radio behavior as a function ofdistance between small groups of nodes to ensure that the propaga-tion, capture, and carrier sense models were working as designed.

The S02.11 MAC implementation was studied in a variety of sce-ntios and independency verified by two of the authors. We exper-imentily tested that when dl nodes are in range of each other, nodata packets experience colhsions (regardess of offered traffic load),and that each node is able to make progress sending packets. Thisverified that the ctier sense, RTSICTS, and back-off mechanismsofS02.11 were working correctiy.

4.5 Vtidation of the Routing Protocol kplementations

Each protocol implementation was studied and verified by at leasthvo of the authors, and hvo independent implementations were madeof both AODV and DSDV.

The restdts of each simtiation were intemdly consistent. Thatis, the percentage of packets originated by the “application Iayef’sources that were not logged as either received or dropped at the endof the simtdation was less than 0.0170 (approximately 10packets persimtdation). These packets were flmost certairdy in transit at the endof the simulation, as the simtdation originates behveen 40 and 120packets per simdated second and terminates at exactiy 900 seconds

I

without a cool-down period.The restdts of our simulations are, in fact, different from the few

previously reported studies of some of these protocols. We explainthe reasons for these differences in Sections 5,6, and 7.

4.6 Metnm

h comparing the protocols, we chose to evahtate them according tothe following three metrics:

90

—_ .— .—. ,. ..

● Pacht deliveq ratio The ratio behveen the number of packetsoriginated by the “application layer” CBR sources and the num-ber of packets received by the CBR sink at the find destination.

● Routing overhed The total number of routing packets trans-mitted during the simdation. For packets sent over mukiplehops, each transmission of the packet (each hop) counts as onetransmission.

● Path optirt~ali~ The difference between the number of hops apacket took to reach its destination and the length of the shortestpath that physically existed through the nehvork when the packetwas originated.

Packet delive~ ratio is important as it describes the loss rate thatwill be seen by the transport protocols, which in turn effects themaximum throughput that tie nehvork can support. This metriccharacteties both the completeness and correctness of the routingprotocol.

Routing overhead is an important metric for comparing these pro-tocols, as it measures the scalability of a protocol, the degree to whichit will function in congested or low-bandwidth environments, and itsefdciency in terms of consuming node battew power. Protocols thatsend large numbers of routing packets can dso increase the prob-ability of packet co~lsions and may delay data packets in nehvorkintefiace @ausmission queues. We rdso evaluated the number ofbytes of routing overhead caused by the source routing header re-quired by DSR, and present those resuks in Section 6.1. We didnot include EEE 802.11 MAC packets or ARP packets in routingoverhead, since tie routing protocols cordd be run over a varietyof different medium access or addrtis resolution protocols, each ofwhich wotid have different overhead Our god was to compare therouting protocols to each other, not to fid the optimaf performancepossible in our scenarios.

kr the absence of congestion or other “noisej’ pati optimrdiwmeasures the ability of the routing protocol to efficiently use nehvorkresources by selecting the shortest path from a source to a destination.We cdcrdate it as the difference between the shortest path foundintemdly by the sirudator when the packet was onginate~ and thenumber of hops the packet actually took to reach its destination.

5 Stidation Rwulh

As notedin Section4. 1,we conducted simdations using two differentnode movement speeds: a maximum speed of 20 ds (average speed10 tis) and a maximum speed of 1 tis. We fist compme the fourprotocols based on the 20 tis simrdations, and then in Section 5.5present data for 1 tis for comparison. For dl simdations, thecommunication patterns were peer-to-per, with each run havingeither 10,20, or 30 sources sending 4 packets per second.

5.1 Comparison Summary

Figures 2 md 3 hi~ight the relative performmce of the four routingprotocols on our tic loads of 20 sources.

All of the protocols dehver a greater percentage of the originateddata packets when there is Etie node mobifity Q.e., at large pausetime), converging to 10070delivery when there is no node motion.DSR and AODV-LL perform ptictiarly well, dehvering over 95%of the data packets regmdess of mobility rate. In these scenarios,DSDV-SQ ftils to converge at pause times less than 300 seconds.

The four routing protocols impose vastiy different amounts ofoverhead, as shown in Figure 3. Nearly an order of magnitudeseparates DSR, which has the least overhea~ from TORA, whichhm the most. The basic character of each protocol is demonstratedin the shape of its overhead curve. TORA, DSR, and AODV-LL aredl on-demand protocols, and their overhead drops as the mobilityrate drops. As DSDV-SQ is a largely periodic routing protocol, itsoverhead is nearly constant with respect to mobility rate.

9

Figure 2 Comparisonbetweenthefourprotocokof thefractionofapplication&m packetssu=sfi~y defivered(packetdefiveryratio)asa functionof pausetime. PausetimeOrepr=entsconstantmotihty.

i

....a.m - ● w. o

-+------

+ ----------- +------- ___

0 *0 lm ao ao m 5W MO 700 m w

Pa,= he (s)

F-3 timparison ktwun the forrrprotocok of the numkr ofrouting packets sent (routing overhead)as a function of pause time.

Pause time Orepresens constant motifi~.

The TORA resuks shown in Figures 2 and 3 at pause time 600 arethe average of ofly 9 scenarios, as the overhead for tie tenth scenariowas much higher than the others due to significant congestion causedby the routing protocol. The complete resuks are included below andexplained in Section 5.3.

5.2 Packet Defivery Ratio Deti

Figure 4 shows the fraction of the originated application data packetseach protocol was able to deliver, as a function of both node moblfityrate (pause time) and network load (number of sources). For DSRand AODV-LL,packet delivery ratio is independent of offered trafdcload, with both protocols delivering between 95% and 100% of thepackets in dl cases.

DSDV-SQ fails to converge below pause time 300, where it de-livers about 9290 of its packets. At higher rates of mobility (lowerpause times), DSDV-SQ does poorly, dropping to a 70% packet de-livery ratio. Nearly dl of the dropped packets are lost because a stierouting table entry directed them to be forwarded over a broken link.As described in Section 3.1.2, DSDV-SQ maintains ordy one routeper destination and consequently, each packet that the MAC layer isunable to deliver is dropped since there are no akemate routes.

1

I

(a) DSDV-SQ

1

@) DSR

1

---+-4 -* ------

Q9- o=~

(c) TOM (d) AODV-U

F-4 Packet defiveryratio as a fonction of pawe time. TORAis show on a different vertid sde for ctity (see Figure 2).

TORA does well with 10 or 20 sources, delivering between 90%md 9570 of originated data packets even at the highest rate of nodemobility (pause time O). The majority of the packet drops are dueto the creation of short-hved routing loops that are a naturrd partof its link-reversal prwess. Consider a node A routing packets toC via B. H B’s link to C breaks, B will reverse its link to A,transmit an UPDA~ to notify its neighbors it has done tis, andbe~n routing packets to C via A. Until A receives the UPDA~,data packets to C will loop between A and B. Our implementationof TORA detects when the next-hop of a packet is the same as theprevious-hop md drops the data packet, since experiments showedthat allowing these packets to loop until their TTL expires or theloop resolves causes more packets to be dropped overall, as thelooping data packets interfere with the ability of other nearby nodes tosuccesstily exchange the broadcast UPDA~ packet that will resolvetheir routing loop.

Whh 30 sources, TOWS average packet delivery ratio drops to~% at pause time O, although upon examination of the data wefound that variability was extremely large, with packet delivery ra-tios ranging from S90to 9190. h most of these scenarios, TORAfails to converge because of incremed congestion, as explained inSection 5.3. A very recenfly released revision to the ~P speci-fication [4] claims to improve the refiable control message delive~semantics provided by ~P, which might eliminate some of the be-haviors seen here. However, these new mechanisms add more packet

overhead to TO~P which, as shown in Section 5.3, is aheadyhigher than the other protocols studied here.

5S Routing Overhead De-

Figure 5 shows the number of routing protocol packets sent by eachprotocol in obtaining the defivery ratios shown in Figure 4. DSR andDSDV-SQ are plotted on a the same scale as each other, but AODV-LL and TORA me each plotted on different scales to best show theeffect of pause time and offered load on overhead TORA, DSR,and AODV-LL are on-demand routing protocols, so as the numberof sources increases, we expect tie number of routing packets sentto increase because there are more destinations to which the networkmust maintain working routes.

DSR and AODV-LL, which use only on-demand packets and verysimilar basic mechanisms, have almost identically shaped curves.Both protocols exhibit the desirable property that the incrementalcost of additiond sources decreases as sources are added, since theprotocol can use information learned from one route discovery tocomplete a subsequent route discovery.

However, the absolute overhead required by DSR and AODV-LLare very different, with AODV-LL requiring about 5 times the over-head of DSRwhen there is constant node motion (pause time O).Thisdramatic increase in AODV-LUS overhead occurs because each ofits route discoveries typically propagates to every node in the ad hocnetwork. For example, at pause time Owith 30 sources, AODV-LL

92

_—________ ._ . .--.-—-— —., <- _ .—— —

(a) DSDV-SQ

j 180,&

I ,-’,~ -“%. ~ . \g Is,w .’ \

‘. ,“ ,.\. . ,’ \ 1

@) DSR

(c) TORA (d) AODV-LL

F~e 5 Routing overhad as a fanction of pause time. TORA md AODV-LLare show on different vertid sales for ctity (see Figure 3)

initiates about 2200 route discoveries Wr 900-second simtiationrun, restiting in around 110,000 ROm-nQWT transmissions. Incontrast, DSR tits the scope and overhead of ROH nQmTpackes by using caching from forwarded and promiscuously over-heard packets and using non-propagating Ro~ mQmTS as de-scribed in Section 3.3.2, which restits in DSR sending ordy 950non-propagating requests and 300 propagating requests per simtia-tion run.

TOWS overhead is the sum of a constant mobility-independentoverhead and a variable moblli~-dependent overhead. The constantoverhead is the resdt of MP’s neighbor discovery mechrmism,which requires each node to transmit at least 1 ~LLO packet perBmCON period (1 second). For 900-second simdations with 50nodes, this resdts in a minimum overhead of 45,000 packets. Thevariable part of the overhead consists of the routing packets TORAuses to create and maintain routes, multiphed by the number ofretransmission and ac~owledgment packets MP uses to ensuretheir rehable, in-order delivery.

h many of our scenarios with 30 sources, TORA essentially un-derwent congestive coflapse. A positive feedback loop developed inTO~P wherein the number of routing packets sent caused nu-merous MAC-layer collisions, wtich in turn caused data, ACK,and~LLO packets to be lost. The loss of these packets caused IMEP toerroneously beheve that links to its neighbors were breaking, even in

93

the pause time 900 scenarios when dl nodes were stationw. TORAreacted to the perceived link breakages by sending more UPDA~,which closed the feedback loop by directly causing more conges-tion. More importantly, each UPDA~ sent required reliable delive~,which increased the system’s exposure to additionrd erroneous linkfailure detections, since the ftihrre to receive an ACKfrom retrans-mitted UPDA~ was treated as a link failure indication. In the worstruns, TORA generated over 10 million objects, which ~P aggre-gated into 1.6 million packets requiring rehable defivery. h the few3@source runs where congestion did not develop, the overhead var-ied from 639,000 packets at pause time Oto 47,000 packets at pausetime 900.

DSDV-SQ hm approximately constant overhead, regardess ofmovement rate or offered trafdc load. This constant behavior arisesbecause each destination D broadcasts a periodic update with a newsequence number every 15 seconds. With 50 unsynchronized nodesin the simulation, at least one node broadcasts aperiodic update dur-ing each second. DSDV-SQ considers the receipt of a new sequencenumber for a node to be important enough to distribute immediately(Section 3.1), so each node that receives Ds periodic update gener-ates a triggered update. These triggered updates flood the ne~ork,m each node receiving one learns a new sequence number and sodso generates a triggered update. Each node limits the rate at whichit sends triggered updates to one per second, but since there is at lemt

-——-- — .. -- I

—..-. . . . . . . . . .

tn

FI DSDV-SQTORA

W,m OSR

I

AOOV-U

mm

F-6 DifferencebeWwnthe numberofhops eachpackettookto reachits destimtionandtheoptimalnum~r of hops

required. Datais for20 sources.

one new sequence number per second, every node transmits triggeredupdates at the mtimuru permitted rate. Therefore, although the basewnodic action of DSDV-SQ is once per 15 seconds, the effectiverate of a group of nodes is one update per node per second, yieldingan overhead of 45,000 packets for a 9Wsecond, 50-node simulation.

5.4 Path OptirnrdityDeW

As described in Section 4, an intemd mechanism of our simdatorknows the length of the shortest possible path between dl nodes inthe network at any time and labels dl packets with this path lengthwhen they are originated. Figure 6 shows the difference behveenthis shortest path length and the length of the paths actually takenby data packets. A difference of Omeans the packet took a shortestpath, and a difference greater than Oindicates the number of extrahops the packet took.

Both DSDV-SQ and DSR use routes very close to optimal. TORAand AODV-LL each have a significant tail, taking up to 4 or morehops longer than optimal for some packets, although TORA wasnot designed to find shortest paths. For space reasons, Figure 6aggregates tie data from dl pause times into one graph. Men thedata are broken out by pause time, DSDV-SQ and DSR do very wellregardess of pause time, with no statistically significant change inoptimtity of routing with respect to node mobility rate. TORA andAODV-LL,on the other hand each show a significant difference withrespect to pause time in the length of the routes they use relative tothe shortest possible routes. men node motiliw is very low, theyuse routes that are sigrtificantiy closer to the shortest possible routesthan when nodes are moving.

5.5 Lower Speed of Node Movement

In order to explore how the protocols scrde as the rate of topologychange varies, we changed the maximum node speed from 20 tisto 1 tis and re-evahrated dl four protocols over scenario files usingthis lower movement speed Figures 7 and S show the resdts of thisexperiment when using 20 sources. Ml of the protocols deliver morethan 9S.5% of their packets at this movement speed. Urdike in the20 ds scenarios, where DSDV-SQ cotdd not converge, it deliversexce~ent performance in the 1 ds scenarios.

Even a~this slowerrate of movement, each of the routing protocolsgenerated very different amounts of overhead. Neither DSR norAODV-LL were seriously challenged by this set of scenarios, asthe overhead increases ordy mildy as pause time decreases. The

94

F@e 7 Comparison of the fraction of apptimtion data packetssucmsfnlly detivered as a function of pause time. SPA is 1 tis.

N.000t

-- %--- -- ----. i

{..O+*--+------+----------- --- ---

0--- I

0 1w2M~@0~ 6W7W8WWPa= tme (S)

F@e S Comparison of the number of routing packe~ sentas a fiction of pause time. Speed is 1 tis.

separation between DSR and AODV-LL, however, has grown froma factor of 5 to nearly a factor of 10 because DSWS caching is evenmore effective at lower speeds where the cached information goesstie more slowly.

Due to its largely periodic nature, DSDV-SQ continues to have aconstmt overhead of approximately 41,000 packets, while TOWSoverheads dorninatedby the litistatus sensing mechanism of I~P,which amounts to one packet per node per second, or a totrdof45,000packets per simdation (Section 5.3).

6 Additional Observations

6.1 Overhead in Source Routing Protocols

men comparing the number of routing overhead packets sent byeach of the protocols, DSR clearly has the lowest overhead (Figure 5).The data for 20 sources is reproduced in Figure 9(a) on a semi-logaxis for cltity. However, if routing overhead is measured in bytesand includes the bytes of the source route header that DSR places ineach packet, DSR becomes more expensive than AODV-LL exceptat the highest rates of mobility, although it stiUtransmits fewer bytesof routing overhead than does DSDV-SQ or TORA. AODV-LLusesa Route Discovery mechanism based on DSFS, but it creates hopby-hop routing state in each node along a path in order to elitinate

—.— .—. _——

-. *.----- --

-,.~ .. . .3 +Y. .0..

-+. -: . . .g 104

---

~‘-+--

------- --+. .

‘. ... .

. . . ““. . . :]

.

J,, ,AA&~)SDV~.m)=IODV-U

2Mmm100 -- --- ---mm m (-)

, ~.% J--

. . ./“ \ >

. . .

.

-..

. . .5

+---------- - + -----------, ,,,5 ...,

0. . . .

; ., .,....

~ 106: ...““.0.,s ..g3

(a) Routingoverheadh pzkeE. ~) Roudngovedrmdinby~.

F-9 tin~ting routing overhead in packetsand inbytes. Both~phs usesemi-logaxes.

the overhead of source routing from data packets. This reduction inoverhead bytes is shown in Figure 90).

It is unclear whether this improvement in bytes of overhead issignificant for red world protocol operation, because the majori~ ofAODV-LL overhead bytes me carried in many smrdl packets. Thecost to acquire the medium to transmit a packet is significantly moreexpensive in terms of power and network utilization than the in-cremented cost of adding a few bytes to an existing packet, so theacturdcost of the source route header in DSR is less than the numberof bytes might indicate. A completely fair comparison based onoverhead in bytes wodd dso have to include the cost of physicallayer framing and WC protocol bytes, which we have deliberatelyfactored out sinw the routing protocols codd be N over many dif-ferent ~C implementations, each of which wotid have a differentoverhead.

6.2 The Effect of Triggered Updat= in DSDV

As noted in Section 3.1.2, DSDV can employ either of two strategiesfor determining when to send triggered updates. h the fist strategy,DSDV-SQ, a node sends a triggered update each time it receives anew sequence number for some destination. As shown in Figure 10,DSDV-SQ delivers over 99% of its packets for dl pause times whenthe maximum node speed is 1 tis. h the 20 ds case, DSDV-SQSpacket delivery ratio falls to 95% at a pause time of 300 seconds andfurther decreases at higher mobility rates as DSDV-SQ is unable toconverge. Figure 11 shows that for both the 1 tis and 20 tis dat%DSDV-SQS routing overhead is approximately 45,000 packets forM pause times, as discussed in Section 5.3.

The second scheme for sending triggered updates, which we cdlsimply DSDV, requires that they be sent ordy when a new metricis received for a destination. h this case, Euk breakages are notdetected as quicNy as in DSDV-SQ, generally resdting in moredropped packets.

For a movement speed of 1 tis, DSDV delivers fewer packetsthan DSDV-SQ, with its packet delivery ratio decreasing to 95%at pause time O. While DSDV’S routing overhead is a factor of 4smrdler, the fact that its routing overhead is constant indicates thata movement speed of 1 tis does not exercise the routing protocoltily. At 20 tis, both DSDV-SQ and DSDV fail to converge, causinga large percentage ofdatapackets to be dropped. However, the DSDVtriggering scheme reduces the relative routing overhead by a factorof 4 at pause time 900 md by a factor of 2 at pause time O.

95

63 Retiabfity h= with Broadcast Packets

Because broadcast packets are not receiver directed there is no wayto reserve the wireless medium at the receivers before transmitting abroadcast packet (e.g., with an RTSICTS exchange). Consequently,broadcmt packets are inherently less reliable than unicast packets.This difference does not exist in wired networks and represents afidamentrd limitation of wireless networks that must be accountedfor in the design of ad hoc nework routing protocols. Uponsampling a number of our scentios, we found that over any singlehop, 99.S% of unicast data packets are received successtily, whileordy 92.670of broadcast packets are received, based on counting thenumber of receivers within transmission mge of the broadcastingnode. The difference between the two numbers is due to col~sions.h fiture work, we will examine how the difference varies with theaverage degree of the nodes, the size of the broadcast packets, andthe relative proportion of broadcast packets.

6.4 bteraction of ARP with On-Demand Protocoh

When an on-demand routing protocol receives packets to a destina-tion for which it does not have a route, the protocol typically buffersthe packets in the routing layer until it can discover a route for thepackets. Once the routing protocol finds a route, it sends the queuedpackets down to the link-layer for transmission. k the course of ourearly experiments, however, we observed a serious layer-integrationproblem that wotid effect any on-demand protocol running on topof an ARP implementation similar to that in BSD Unix [23].

OurARP code, like the BSD code, buffers one packet perdestina-tion awaiting a link layer address. If a series of packets are passed bythe routing layer to the ARP code with a next-hop destination whoselink-layer address is urdmown, dl but the last of these packets willbe dropped by ARP. h our simtiation, we remedied this by pacingthe rate at which packets are passed from the routing queue, thoughthe implementation of ARP codd be modified to buffer additiondpackets, or the routing protocol codd be coded to check that theARP layer has a link-layer address for the next-hop before passing itpackets from the routing queue.

7 Related Work

Some simulation resdts for DSDV, TORA, and DSR have been pre-sentedin earlier papers, although those simrdations used substautitiydifferent input parameters than ours and did not simdate the wirelessnetwork as accurately. We are not aware of any previously publishedperformance resdts for AODV.

——. ———

F-10 Fraction of originated data packetssuwssfilly detivered by DSDV-SQand DSDV.

-x-.--x- ----- *--- ----- -“--- ----- - >

4D.W 3 -

q;::------E,;;,,,I

1dsISDV 20 ds

10 a DSDV 1 dS Ii

Figsrre11 Routing overheadas a function ofpame drne for DSDV-SQmd DSDV.

7.1 Park and Corson

An earfier simtiation of TORA was done by Park and Corson [16],who compared TORA to an “idetizd’ link state routing protocol.Their restits are quite different from those presented in this paper,showing TORA delivering over 9070 of its packets in dl cases, butthese resdts are incompmble to ours because of the many simplifi-cations they made in simtiating the environment. In order to avoidcongestion, their simdation used a packet transmission rate of ordy4, 1.5, or 0.6 packets per minute per node. Simtiations were runfor 2 hours, the meantime between failure for links was varied from32 minutes to 1 minute, md the average nehvork connectivity wasticidly held constant at 90%, 70%, or 50%.

Their simtiatormodeled the nehvork as a “densely-connectedhon-eycomW with constant node density. There is no notion of node mo-bifity. fich node is connected to a fixed set of neighbors by sepmatefinks that cycle behveen an active and an inactive state independentof dl other links. These links are error free, and no dynamics belowthe nehvork layer are modeled. Radio propagation, medium access,collisions, and physic~ node mobili~ are completely ignored, it iset’enpossible for a node to correcdy receive hvo simtitaneous trans-missions. h their simdation, link transitions cause interrupts thatgive the protocols immediate feedback whenever a link goes up or

down. In reality, though, a node can ordy detect that a link has brokenif it is wing to use the link or if it fails to receive expected Priodlcbeacons over it, and anode can ordy recognize the existence of a newneighbor when it receives a packet from that neighbor.

An earlier paper [3] presented simtiation resrdts for the protocolon which TORA is in part based, but the sirntiator used in that studyhad the same problems as the simdator used by Park and Corson,and the metrics used are incomparable to ours.

7.2 Johnson ana Mdti

We have previously simdatea DSR [10] using the same mobilitymodel as in this paper. h this previous work, movement speedsranged from 0.3 to 0.7 tis, with the nodes moving about in a9m x 9m space using shorter range infrared wireless transmitterswith a 3-meter range.

This simulation lacked a realistic model of radio propagation anda MAC layer such as fEEE 802.11. These missing pieces greadysimplify tie problem faced by the routing protocol, as propagationdelay, capture effects, MAC-layer collisions, and the effects of con-gestion due to large packet sizes are unaccounted for. Furthermore,broadcast and unicast packets were deliverea with the same proba-bility, and, as noted in Section 6.3, this is not a realistic assumption.This earlier simtiation study rdso did not consider ad hoc nehvorksof more thm 24 nodes.

hr the earher simtiation, we characterized the path optimdityof the routing protocol by reporting the ratio of the average routelength used to the optimal route length that codd have been usedif the routing protocol had perfect information. However, we didnot report the actual route lengths used, ana since both numbers areaverages, this ratio tendea to blur the aynamics of the protocol. As arestit, in this paper we present path optimdity data as the dt~erencebehveen the optimal and acturd path lengths uses.

7S Freisleben and Jansen

DSDV and DSR were recentiy simdatea ana compared by Freislebenand Jansen [7]. Their sirntiations used configurations of 10 or 25mobtie nodes, with movement speeds relative to transmission rangeapproximately 6 times faster than in our simrdations, making someof their resdts incomparable to ours. Furthermore, dthougb theirrestits coda be explainea by many factors, such as congestion,collisions, or the failure of the routing protocols to converge, theauthors do not analyze or interpret the restits and it is not possibleto assess the impact of these factors from the data presented.

All of their restits rdso suffer due to a number of deficiencies intheir sirmdation and implementation of the protocols. Ml events intheir simtiator take place in re~ar time steps, restiting in perfectiysynchronized behavior of a number of separate mobile nodes in somecases. For example, upon receipt of a broadcast packet, W nodeswho attempt to send a response packet wi~ experience a collision ontheir RTS, requiring a binary exponentird backoff and retrarrsrnissionattempt. Furthermore, they do not buffer any packets while waitingfor a Rom ~LY to be returnea auring a DSR Route Discovery,causing large numbers of packets to be dropped needessly.

8 Conclmions

The area of ad hoc nehvorkbrg has been receiving increasing at-tention among researchers in recent years, as the avrdlable wirelessnehvorking and mobile computing hardware bases are now capableof supporting the promise of this technology. Over the past fewyears, a variety of new routing protocols targeted specifically at theaa hoc nehvorking environment have been proposed, but Iittie per-formance information on each protocol and no detailed performancecomparison between the protocols has previously been available.

This paper makes contributions in hvo areas. First, we describeour modifications to the m nehvork simtiator to provide an accu-rate simulation of the MAC and physical-layer behavior of the EEE

96

.. -7-. .- ...—- =.... .. — ..-= _ .— --

S02.11 wireless LN standara including a retistic wireless trans-mission channel model. This new simtiation environment providesa powefl tool for evahtating ad hoc nehvorking protocols and otherwireless protocols and apphcations. Semn& using this simtiationenvironrnen~ we present the resrdts of a detailed packet-level sirnda-tioncomparing four recent mtdti-hop wireless adhocnehvorkroutingprotocols. These protocols, DSDV, TORA, DSR, and AODV, covera range of design choices, including periodic advertisements vs. on-demand route discovery, use of f~dback from the MAC layer toindicate a failure to forward a packet to the next hop, and ho~by-hop routing vs. source routing. We simdated each protocol in ad hocnetworks of 50 mobile nodes moving about and communicating witheach other, and presented the resdts for a range of node mobitityrates and movement speeds.

Each of the protocols studied performs well in some cases yethas certain drawbacks in others. DSDV performs quite predictably,delivering virtually rdl data packets when node mobitity rate andmovement speed are low, and faihg to converge as node mobilityincreases. TORA, although the worst prforrner in our experiments interms ofrouting packet overhea~ still defiveredover90% ofthepack-ets in scenarios witi 10or20 sources. At 30 sources, the network wasunable to hande dl of the trafdc generated by the routing protocol anda si~cant fraction of data packets were dropped. The performanceof DSR was very good at M mobifity rates and movement speeds,although its use of source routing increases the number of routingoverhead bytes required by tie protocol. Findy, AODV performsalmost as we~ as DSR at rdlmobility rates and movement speeds adaccomphshes its god of e~inating source routing overhea~ but itstill requires the transmission of many routing overhead packets andat high rates of node moblfity is acturdly more expensive than DSR.

Acbowled~enk

Many thanks are due to Dan Stancfl, who reviewed our propaga-tion model for correctness and provided insights on the details ofradio propagation. We wordd dso Eke to thank Pravin Bhagwat,Tracy Camp, Scott Corson, Vincent Park, and Charles Perkins foranswering our questions about the detils of the operation of DSDV,TO~P, and AODV.

Referenc-

fll Vaduvur Bbamhavan. & Demers, Scott Shenker, and Ltia -g.

[2]

[3]

[4]

[5]

[6]

v]

MACAW A mda access protocol for wireless LAN’s. In Proceedingsof the SIGCOMM ’94 Conferenceon CornnnmicatiomArchitecmres,Protocok ondApplications, pagw 212-225, August 1994.

Josh Brocb David B. Johnson, and David A. Mrdti The DynamicSource RoudrrgRotocol for Mobile Ad Hoc Networks. ktemet-mdraft-ietf-marretWr-00.tx~ March IW8. Work in progress.

M. Scott Corson and Anthony Ephrernides. A distribute routing d-algorithmfor mobile wirelms ne~orks. Wrekss Ne~ork, 1(1):6141,February 1995.

M. Scott ~rson, S. Papademetriou, Phihp Papadopordos,Vincent D.Park, and Anrir Qayyurn. An ktemet MANET Errcapstition Prot&ml ~P) Specifimtion. htemet-m draf-ieti-rnarret-imep-spw-01.KL August 1998. Work in progress.

M. Scott Corson and Viicent D. Park. An htemet MANET Enmpsu-kdion Protocol (WP) Specification. Intemet-Dti draft-ietf-manet-imep-s~-~.tx~ November 1997. Work in progress.

KevinFd and KannarrVaradhan,dtors. ns notes and documentation.The V~ Projecg UC Berkeley, LBL, US~SI, and Xerox PARC,November 1997. Atihble from h~J/www-srmsh.cs.&rkeley.edtid.

Bemd Freisleben and Muh Jarrsen. Ativsis of routing rrrotocolsfor ad hoc networks of mobile comutcrs. In Proceedings of the 15thUSTED InternationalConferenceon Applied Infornratics,pagm 13>136, Wbruck Amtri& February 1997.MSTED-Acts Press.

97

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[lq

[IT

[18]

[19]

[20]

[21]

[22]

[23]

EEE Computer Society LAN MAN Standards tirrrrnittee. WrelessW Medim Access Control (MAC)and Physical @er (Pm) Speci-fiatiom, EEE Std 802.11-1997. The ktitute of Electrid and Elec-tronics Enginwrs, New York New Yor& 1997.

David B. Johnson. Routing in ad hm networks of mobile hosts. hProceedingsof the IEEEWorkhop on Mobile ComputingSystemsandApplications,pages 15%163, Decem&r 1994.

David B. Johnson and David A. Md~ Dynamic source routing inad hoc wirelws networks. h Mobik Conrputig, edited by Torrrasztiehki and Hank Koti chapter 5, pag= 15>181. Wrrwer Aca-demic Pubkhers, 1996.

Phil Kam. MACA—A new channel a-s methti for packet radio.hr Proceedings of the 9th Computer Netsvorfig Conference,pages13*140, September 1990.

Barry M. Leimer,Robert J. Ruth, and Arobatipndi R. Sastry. Go* andc~enges of tie DHA G1oMoprogram. IEEE Persod Cornnruni-cations, 3(6):3M3, Dmmber 1996.

Nationat Scierrm Foundation. R~mch priorities in wirelfis andmobile comrnnrrications and networking Report of a workshopheld Masch 2&26, 1997, Aufie House, Viginia Available athttp://www.cise.nsf.gov/ti/ww.hti.

Vincent D. Park and M. Scott Corson. A bi~y adaptive distributedrouting atgonthrn for mobile wirelws networks. k Proceedings ofINFOCOM97, pagw 1405-1413, April 1997.

Viwrst D. Park and M. Smtt Corson. Tempo@y-Ordered RoutingAlgorithm ~ORA) version 1: Furrctiod specification. ktemet-~draft-ietf-rnanet-tora-spec-00.tx4November 1997. Workin progress.

Vicent D. Park and M. Scott Cmson. A performance comptilon ofTORA ad Idd Lti State routing. h ProceedingsoflEEESymposimon Computersand Conrrnrmication ’98, June 1998.

Charlw Perkins. Ad Hoc On DemandDKtanceVector(AODV)routing.Internet-m draft-ietf-rnruret-aodv-00.mLNovember 1997. Work inprogras.

CbarlU E. Perkins and PravirrBbagwa~ HigMy dynamic D=tirration-S~uenti Distance-Vector routing @SDV) for mobfle computers.In Proceedings of the SIGCOMM ’94 Conference on Comnnuri-cations Architectures, Protocok and Applications, pagw 234244,August 1994. A revised version of the paper is avaihble fromh~//www.cs.rund.edtiprojecWm@papedSigmm94.ps.

David C. Phrmrner. An Ethernet address resolution protocol: Or con-verting network protocol addr=ses to 48.bh Ethernet addrwses fortransmission on Ethernet hardware. RFC 826, November 1982.

Theodore S. Rappapofi Wreless Conununications: Principles andPractice. Prentim Hatl, New Jersey, 1996.

Neil Siegel, Dave Hall, Cfint W*er, and Rene Rubio. The Tactid h-temet GrayWd Panel briefings. U.S. Army Digitimtion OffiW.Avail-able at h~//www.ado.arrny.ti~riefingflact%2Ohtemetimdm.hti,October 1997.

Brrrm~ch. Development of WaveLAN, an ISM band wireless LAN.AT&TTechnicd Jourmd,72(4>27-33, July/August 1993.

Gasy R. Wright and W.Richard Stevens. TCPAPIllustrated, Volume2:me Implement~.on. Addison-W~ley, Radirrg, Massachuse~, 1995.

——— ——.-T-. > - . . . . --- . . . .7- -—.- .