scenario based performance of routing protocols

8/3/2019 Scenario Based Performance of Routing Protocols

1/12

Scenario-based Performance Analysis of RoutingProtocols for Mobile Ad-hoc Networks

Per Johansson Tony Larsson Nicklas HedmanEricsson Radio Systems AB Ericsson Radio Systems AB Ericsson Erisoft AB, Box 920SE-l 26 25 Stockholm, Sweden SE-l 26 25 Stockholm, Sweden SE-971 28 Lulea, Sweden+4687190290 +4687195033 +46 920 20 23 16Per.JohanssonQericsson.com Tony.LarssonQera-t.ericsson.se Nicklas.HedmanQlu.erisoft.se

Bartosz Mielczarek Mikael DegermarkDepartment of Signal and Systems Department of CS & EE Swedish Institute ofChalmers University of Technology Lulea University of Technology Computer ScienceSE-41 2 96 Goteborg, Sweden SE-971 87 Lulea, Sweden Box 1263+46 31 772 17 63 mickeQsm.luth.sebartosz.mielczarekQs2.chalmers.seABSTRACTThis study is a comparison of three routing pro-tocols proposed for wireless mobile ad-hoc net-works. The protocols are: DestinationSequenced Distance Vector (DSDV), Ad-hoc Ondemand Distance Vector (AODV) and DynamicSource Routing (DSR). Extensive simulationsare made on a scenario where nodes moves ran-domly. Results are presented as a function of anovel mobility metric designed to reflect the rel-ative speeds of the nodes in a scenario. Further-more, three realistic scenarios are introduced totest the protocols in more specialized contexts.In most simulations the reactive protocols(AODV and DSR) performed significantly bet-ter than DSDV. At moderate traffic load DSRperformed better than AODV for all tested mo-bility values, while AODV performed betterthan DSR at higher traffic loads. The latter iscaused by the source routes in DSR data pack-ets, which increase the load on the network.

routers and hosts, thus a node may forward packets betweenother nodes as well as run user applications.Mobile ad-hoc networks have been the focus of many recentresearch and development efforts. Ad-hoc packet radio net-works have so far mainly concerned military applications,where a decentralized network configuration is an operativeadvantage or even a necessity. Networks using ad-hoc con-figuration concepts can be used in many military applica-tions, ranging from interconnected wireless access points tonetworks of wireless devices carried by individuals, e.g., dig-ital maps, sensors attached to the body, voice communica-tion, etc. Combinations of wide range and short range ad-hocnetworks seek to provide robust, global coverage, even dur-ing adverse operating conditions.

1. INTRODUCTIONThe notion of a mobile ad-hoc network used in this work is anetwork formed without any central administration, consist-ing of mobile nodes that use wireless interfaces to send pack-et data. The nodes in an ad-hoc network can act as both

In the commercial sector, equipment for wireless, mobilecomputing has not been available at a price attractive forlarger markets. However, as the capacity of mobile comput-ers increases steadily, the need for un-tethered networking isexpected to rise as well. Commercial ad-hoc networks couldbe used in situations where no infrastructure (fixed or cellu-lar) is available. Examples include rescue operations in re-mote areas, or when local coverage must be deployedquickly at a remote construction site. Ad-hoc networks be-tween notebook or palmtop computers could be used tospread and share information among the participants of aconference. Short range ad-hoc networks can simplify inter-communication of various mobile devices (e.g., a cellularphone and a PDA) by eliminating the tedious need for ca-bles. The latter case could also extend the mobility providedby the fixed network (e.g., Mobile IP) to nodes further out inan ad-hoc network domain.Permiss ion to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the tirst page. To copyotherwise, to republish , to post on servers or to redistrihute to lists.requires prior specific permission and/or a fee.Mobicom 99 Scattlc Washington USACopyright ACM 1999 I-581 13-142-9/99/08...$5.00

Since the network nodes are mobile, an ad-hoc network willtypically have a dynamic topology which will have a pro-found effects on network characteristics. Network functionssuch as routing, address allocation, authentication, and au-thorization must be designed to cope with a dynamic andvolatile network topology. Network nodes will often be bat-tery powered, which limits the capacity of CPU, memory,

SE-1 64 29 K ista, Sweden

195


2/12

and bandwidth. This will require network functions that areresource effective. Furthermore, the wireless (radio) mediawill also affect the behavior of the network due to fluctuat-ing link bandwidths resulting from relatively high errorrates.1.1 Routing protocols for ad-hoc networksThis work focuses on routing protocols for mobile ad-hocnetworks. Traditional routing protocols are proactive in thatthey maintain routes to all nodes, including nodes to whichno packets are sent. They react to topology changes, even ifno traffic is affected by the change. They are based on eitherlink-state or distance vector principles [ 181 and require peri-odic control messages to maintain routes to every node inthe network. The rate at which these messages are sent mustreflect the dynamics of the network in order to maintain val-id routes. Hence, the use of scarce resources, e.g., powerand link bandwidth, for control traffic will increase with in-creased node mobility. An alternative approach is reactiveroute establishment, where routes between nodes are deter-mined only when explicitly needed to route packets,Several routing protocols for ad-hoc networks have beenproposed, for instance [l, 3, 4, 6, 8, 9, 10, 13, 15, 17, 191,but few comparisons between the different protocols havebeen published.Within the Internet Engineering Task Force (IETF), a work-ing group named Mobile Ad-hoc Networks (MANET) [ 121has the charter to standardize an IP routing protocol for mo-bile ad-hoc networks . All the routing protocols listed above(except for [ 171) have been submitted to the MANET groupas internet drafts.The work presented in [2] is the most comprehensive com-parison of ad-hoc routing protocols published so far. Thestudy was done in the Monarch project at CMU and aims ata fair evaluation based on quantitative metrics. Examples ofother simulation results on individual protocols are [ 1 ] and[ 141, but as these used different metrics the results are diffi-cult to compare.Three routing protocols are studied in this work, namelyAd-hoc on Demand Distance Vector (AODV), DynamicSource Routing (DSR), and Destination Sequenced Dis-tance Vector (DSDV). AODV and DSR were selected be-cause they show the best performance in [2], but should becompared and evaluated further using additional metrics andscenarios. As opposed to DSR and AODV, DSDV is a pro-active protocol and was included to illustrate the differencesbetween reactive and proactive protocols.This w ork has been inspired by the simulations in [2], butextends those results further by introducing a new mobilitymetric and new network scenarios as well as presenting re-sults on delays and byte overhead. First, a metric calledmobility is introduced as a means to capture the relative mo-tion of nodes in the network. Second, throughput and delay1. Mobile Networking ARCHitectures

are measured for the analyzed protocols with mobility andoffered traffic load as variables in a random network scenar-io. Third, three network scenarios are analyzed, denotedConference, Event Coverage, and Disaster Area, respective-ly. They are intended to model a set of usage cases believedto be more realistic than a totally random motion pattern. Inaddition, the simulation tools were modified to include sim-ple obstacles that shadow the coverage of nodes, which addto the realism of the latter scenarios.The models of DSDV and DSR used in the study were partof a simulation package from CMU [20], while AODV hadto be implemented independently at the time of this work.To clarify the differences to the work made in [2], a discus-sion on protocol implementations and protocol parametersare presented in conjunction with the protocol descriptionsin Section 2.In all simulations presented herein, the link layer consists ofa wireless LAN using a media access control (MAC) func-tion based on the IEEE 802.11 [7] standard. This MACfunction uses a random access algorithm denoted CSMA/CA (Carrier Sense Multiple Access with Collision Avoid-ance) that essentially operates as an Ethernet in the air with-out the collision detection part. The random access conceptused in this protocol makes it relatively easy to form ad-hocnetworks. The technology is commercially available, andthere is an implementation of this link layer in the simula-tion environment used in this study.The paper is organized as follows. In Section 2, brief de-scriptions of the studied protocols are given. Section 3 intro-duces a mobility metric used throughout the study. InSection 4, simulation results for the random scenario aregiven and in Section 5 results for the three realistic scenari-os are presented and discussed. In Section 6 conclusions aredrawn from the study and, finally, in Section 7 planned fur-ther work is listed.2. PROTOCOL DESCRIPTIONSThis section gives short descriptions of the three ad-hocrouting protocols studied in this work.2.1 Destination Sequenced Distance Vector -DSDVDSDV [17] is a hop-by-hop distance vector routing proto-col. It is proactive; each network node maintains a routingtable that contains the next-hop for, and number of hops to,all reachable destinations. Periodical broadcasts of routingupdates attempt to keep the routing table completely updat-ed at all times.To guarantee loop-freedom DSDV uses a concept of se-quence numbers to indicate the freshness of a route. A routeR is considered more favorable than R if R has a greater se-quence number or, if the routes have the same sequencenumber, R has lower hop-count. The sequence number for aroute is set by the destination node and increased by one forevery new originating route advertisement. When a nodealong a path detects a broken route to a destination D, it ad-

196


3/12

vertises its route to D with an infinite hop-count and a se-quence number increased by one.Route loops can occur when incorrect routing information ispresent in the network after a change in the network topolo-gy, e.g., a broken link. In this context the use of sequencenumbers adapts DSDV to a dynamic network topology suchas in an ad-hoc network.DSDV uses triggered route updates when the topologychanges. The transmission of updates is delayed to intro-duce a damping effect when the topology is changing rapid-ly. This gives an additional adaptation of DSDV to ad-hocnetworks.The parameter values used for DSDV in the simulations aregiven in Table 1 and are the same as in [Z].

Table 1: DSDV Simulation parametersPeriodic route update interval 15 sPeriodic updates missed before link declared 3brokenRoute advertisement aggregation time ISMaximum packets buffered per node per desti- 5nation

2.2 Ad-hoc On Demand Distance vector -AODVAODV [ 15,161 is a distance vector routing protocol, likeDSDV, but it is reactive rather than proactive like DSDV.That is, AODV requests a route only when needed and doesnot require nodes to maintain routes to destinations that arenot communicating. The process of finding routes is re-ferred to as the route acquisition henceforth. AODV uses se-quence numbers in a way similar to DSDV to avoid routingloops and to indicate the freshness of a route.Whenever a node needs to find a route to another node itbroadcasts a Route Request (RREQ) message to all itsneighbors. The RREQ message is flooded through the net-work until it reaches the destination or a node with a freshroute to the destination. On its way through the network, theRREQ message initiates creation of temporary route tableentries for the reverse route in the nodes it passes. If the des-tination, or a route to it, is found, the route is made availableby unicasting a Route Reply (RREP) message back to thesource along the temporary reverse path of the receivedRREQ message. On its way back to the source, the RREPmessage initiates creation of routing table entries for thedestination in intermediate nodes. Routing table entries ex-pire after a certain time-out period.Neighbors are detected by periodic HELLO messages (aspecial RREP message). If a node x does not receive HEL-LO messages from a neighbor y through which it sends traf-fic, that link is deem ed broken and a link failure indication(a triggered RREP message) is sent to its active neighbors.The latter refers to the neighbors of x that were using thebroken link between x and y. When the link failure messageseventually reach the affected sources, these can choose to ei-

ther stop sending data or to request a new route by sendingout new RREQ messages.The implementation of AODV made within this study com-bines HELLO messages with information from the MAClayer to detect link failures, which results in quicker failuredetection. DSR uses similar methods. The HELLO intervalwas also increased to 1.5 seconds (1 second in [16]) sincethe protocol now gets additional information from the linklayer. Moreover, the AODV implementation used in thisstudy has a send buffer of 64 packets, which is not specifiedin [ 161. The send buffer, loca ted in the sending node, storesoutgoing packe ts until the route acquisition procedure ob-tains a route to their destination. The AODV specificationdoes not require a send buffer, but it is needed to obtain afair comparison with DSR which does specify a send buffer.The maximum time to keep packets in the send buffer wasset to 8 seconds, which was a heuristically determined valuebased on a series of initial simulations. Some of the parame-ters used in the simulation was slightly modified comparedto the ones used in [2] and the ones specified by [17]. TheRoute reply lifetime was set to match the Active route time-out value. The Time between retransmitted requests was setto fit the reverse route life time (3 seconds) since it shouldbe possible to retransmit a request as soon as the reverseroute has expired. To save bandwidth, the frequency of trig-gered RREP messages was limited to one every second. Theparameter values used in the simulations are given in Table2.

Table 2: Parameter values for AODVHELLO interval 1,5 sActive route time-out 300 sRoute reply lifetime 300 sAllowed HELLO loss 2Request retries 3Time between retransmitted requests 3sTime to hold packets awaiting routes 8sMaximum rate for sending replies for a route l/S

2.3 Dynamic Source Routing - DSRDynamic Source Routing (DSR) [2][10][11] is a reactiverouting protocol which uses source routing to deliver datapackets. Headers of data packets carry the sequence ofnodes through which the packet must pass. This means thatintermediate nodes only need to keep track of their immedi-ate neighbors in order to forward data packets. The source,on the other hand, needs to know the complete hop sequenceto the destination.As in AODV, the route acquisition procedure in DSR re-quests a route by flooding a Route Request packet. A nodereceiving a Route Request packet searches its route cache,where all its known routes are stored, for a route to the re-quested destination. If no route is found, it forwards theRoute Request packet further on after having added its ownaddress to the hop sequence stored in the Route Requestpacket. The Route Request packet propagates through the

197


4/12

network until it reaches either the destination or a node witha route to the destination. If a route is found, a Route Replypacket containing the proper hop sequence for reaching thedestination is unicasted back to the source node. DSR doesnot rely on bi-directional links since the Route Reply packetis sent to the source node either according to a route alreadystored in the route cache of the replying node, or by beingpiggybacked on a Route Request packet for the source node.However, bi-directional links are assumed throughout thisstudy. Then the reverse path in the Route Request packetcan be used by the Route Reply message.The DSR protocol has the advantage of being able to learnroutes from the source routes in received packets. When Afinds a route to C through B, it will in the process learn aroute to B, and C will learn a route to A. When data startsflowing from A to C, B will learn a route C. However, if thereverse path from C to A passes through B, B will learn aroute to C already when Route Reply message passesthrough B.To avoid unnecessarily flooding the network with Route Re-quest messages, the route acquisition procedure first queriesthe neighboring nodes to see if a route is available in the im-mediate neighborhood. This is done by sending a first RouteRequest message with the hop limit set to zero, thus it willnot be forwarded by the neighbors. If no response is ob-tained by this initial request, a new Route Request messageis flooded over the entire network.DSR may use the MAC layer to inform about link failures.Alternatively, it can use the Network Layer Acknowledg-ment feature as described in [3]. In this study the MAC layerfeedback is used only. In case of a link failure, a route errorpacket is sent back to the source node, which then removesthe broken link from its route cache and all routes that con-tain this hop are truncated at the point of the broken link.Furthermore, an intermediate node that forwards the routeerror packet may also update its route cache in a similarmanner.A DSR node is able to learn routes by overhearing packetsnot addressed to it (the promiscuous mode). However, thisfeature requires an active receiver in the nodes, which maybe rather power consuming. In networks were nodes havelimited power the aim is to shut down the transceiver as of-ten as possible to conserve power. In order to investigatehow DSR would operate in such an environment the promis-cuous mode was not used in the DSR simulations. This de-cision was also motivated by simulation runs (not presenteddue to space limitations), comparing DSR with and withoutthe promiscuous mode. In these simulations the use of thepromiscuous mode did not give a significant improvementof network performance. However, more exhaustive simula-tions should be made to confirm this.The parameter values used in the DSR simulations are takenfrom [2] (see Table 3).

Table 3: Parameters for DSR.

Maximum rate for sending replies for a route 1 /s I3. MOBILITY METRICThis section defines a mobility metric, henceforth referredto as mobility, intended to capture and quantify the kind ofnode motion relevant for an ad-hoc routing protocol. Ad-hoc routing protocols must take action when the relativemotion of nodes causes links to break or form, and a mobili-ty metric should thus be proportional to the number of suchevents. The metric should also, if possible, be independentof the particular network technology used. Therefore a mo-bility metric is proposed which is geometric in the sense thatthe speed of a node in relation to other nodes is measured,while it is independent of any links form ed between nodesin the network.The study in [2] uses the pause time at waypoints in a ran-dom motion model as a mobility metric. This m akes sensefor the particular motion model used in that study but is tooad-hoc to be useful for generic motion models. For in-stance, the pause time metric is ill-defined when node mo-tion is continuous or when nodes use different pause times.Moreover, the speed at which nodes move between way-points is also relevant for how often links break and form.The mobility metric proposed here describes the mobility ofa scenario with a single value M which is a function of therelative motion of the nodes taking part in a scenario. Ifl(n,f) is the position of node II at time t, the relative velocityv(x,y, t) between nodes x and y at time t is

v(x, , t) = -&cx, t) - ICY, 0) .The mobility measure, Mxr between any pair (x, y) of nodesis defined as their absolute relative speed taken as an aver-age over the time, T, the mobility is measured. The formulafor obtaining Mq is given below.

1 M-5 , r)ldrr,


5/12

the number of nodes in the scenario. (Note that the secondrelation in (3) assumes nodes being numbered from 1 to n.)Hence, the mobility expresses the average relative speed be-tween all nodes in the network. Consequently, the mobilityfor a group of nodes standing still, or moving in parallel atthe sam e speed, is zero.For practical reasons a discrete version of the mobility for-mula is used when computing the mobility for the networkscenarios in this study. M is approximated by summing therelative speeds over small time steps, 0.1 seconds. Decreas-ing the time increment below 0.1 seconds did not improvethe accuracy significantly for the scenarios under study.The distances are measured in meters which gives the mo-bility measure in meters per second. Alternatively, the dis-tance could be normalized with the transmitting range of thenodes to compare systems with different radio coverage.However, this modification is left for evaluation in futurestudies.The mobility metric M appears to capture something rele-vant for the routing protocols. The diagram in Figure 1 is of-fered as evidence for this claim. The diagram shows thenumber o f times links break or form as a function of the mo-bility when the nodes move in a random model as describedin Section 4. The diagram gives average values, based ondata from all the random scenario simulations.

3500

Figure 1. Mobility vs. link changes for a random scenario.4. SIMULATIONS - RANDOM SCENARIOSThe simulation study was conducted in the Network Simu-lator (ns2) [5] environment and used the ad-hoc networkingextensions provided by CMU [20]. All simulations wereperformed on a PC (Pentium-2, 400 MHz, 128 MB ofRAM) running FreeBSD 2.2.6.In the random scenario, each node randomly selects way-points in a square environment space (1 km x 1 km). At eachwaypoint a node pauses for a predefined time and picks thespeed to the next waypoint from a uniformly distributed in-terval [&v-l. The simulations of random scenarios aresimilar to the approach in [2], where the area was insteadrectangular, 15OOmx 300m.A square area does not discriminate one direction of mo-

tion like a rectangular area do. On the other hand, it limitsthe number of hops (from 6 to 4 for a transmitting range of250m). Since Section 5 analyzes scenarios with many hops,the square area was chosen for this part of the study.Delay and throughput were measured. In addition, to under-stand the protocol efficiency, the overhead imposed by therouting protocols was measured both in terms of packetsand bytes. Two sets of simulations were run. First, the mo-bility was varied and the offered load was held constant. Inthe second set of simulations the offered load was varied aswell as the mobility. Table 4 provides all the simulation pa-rameters.

Table 4: Simulation Parameter Values

In all random scenario simulations the implicit mobility val-ue is controlled through the explicit maximum speed param -eter, v-,. The mobility value is difficult to set exactly, soan interval of fO. I for each point was allowed. The mobilityvalues used in the simulations are: 0, 0.5, 1.0, 1.5, 2.0, 2.5,3.0, and 3.5, where a mobility factor of 3.5 corresponds to av-.of 20 m/s.In all the simulations the traffic was generated by 15 contin-uous bit rate (CBR) sources spreading the traffic randomlyamong all nodes. The packet size was 64 bytes and the pack-et rate was 5 packe ts/s in the first set of simulations. In thesecond set of simulations the rate ranged from 5 packets/s to20 packet/s.4.1 Delay4.1.1 First set of simulations - Varied MobilityThe average packe t delay increases with mobility for allthree protocols, as shown in Figure 2. However, DSR has alower delay than AODV at higher mobility values due to theway routes are detected in DSR. The route acquisition pro-cedure in DSR allows more routes to be detected and cachedthan in AODV, which obtains a single route per RREQ.With DSR, packets wait less during route acquisition thanwith AODV.DSDV exhibits a low delay because only packets belongingto valid routes at the sending instant ge t through. A lot ofpacke ts are lost until new (valid) route table entries havebeen propagated through the network by the route updatemessages in DSDV. For DSR and AODV, on the other hand,

199


6/12

0 0 0.5 1 1.5 2 2.5 3 3.5M*iMy (m/s)

Figure 2. AU - Average delay with varied mobility.the reactive route acquisition procedures manage to provide

O-Pyq,6.:, --.=---............................................................... .. DSRPJ......

-0 0.5 1 t.5 2 2.5 3 3.5Mdmy (In%)

Figure 4. DSR - Average delay with varied offered traffic.4. I.2 Second set of simulations - Varied LoadThe results for AODV, DSR, and DSDV are shown in Figure3, Figure 4, and Figure 5, respectively.All protocols exhibit higher delays with increased load. Thisis because send buffers become more filled with increasingload. At the highest mobility, AODV shows the highest de-lay, but also delivers more packets than DSR and DSDV(see Section 4.2).DSDVs inability to converge when the mobility is high be-comes increasingly evident at high loads. More traffic is of-fered but the route update interval remains unchanged. InFigure 5 this can be seen as a high delay increase when thepacket rate goes from 5 to 10packefs/s at 1.5 m/s mobility.At the highest load all protocols exhibit a somewhat surpris-ing property; the delay is higher at low mobility than atmoderate mobility (0 - I m/s). The explanation is that at lowmobility routes are relatively long lived. More traffic is car-ried over the same paths during longer times, so longerqueues will form and incur higher delays. At higher mobili-

-0 0.5 1 1.5 2 2.5 3 3.5Mobility (tdslFigure 3. AODV- Average delay with varied offered trafk.

new routes with a low packet loss.0.7 I I r - DSDVpk--*-- DSOV0 9o.6 ; --a.- DSDV5 pkv,. . 1. + .--*-... DSDV,fhkVs

0 0.5 1 1.5 2 2.5 3 3.5Mobuity (na)

Figure 5. DSDV -Average delay with varied offered traffic .ty routes are reestablished occasionally, so the traffic isspread out over a larger number of nodes, one might say thatthe result is a form of load balancing. At the highest mobili-ty the delay for AODV and DSR increases again due tolonger route acquisition procedures, while it saturates forDSDV due to the short send buffer.4.2 Throughput4.2.1 First set of simulations - Varied MobilityThe average throughput for the network is shown in Figure6. With an offered load of 5 packets/s the maximumthroughput is approximately 2.5 kbps. Throughput decreas-es only slightly for AODV and DSR with increased mobility(about 4-5 percent packe t loss at the highest mobility).DSDV on the other hand has difficulties in finding routeswhen mobility increases. This is clear from Figure 6, wherethe throughput drops with about 40 percent at high mobility.The slightly lower throughput for DSDV at zero mobility iscaused by packets that are sent (and lost) before routes haveconverged initially in the network . Note that all simulations

200


7/12

Figure 6. All - Throughput with varied mobility.are started without any established routes .

0 0.5 1 1.5 2 2.5 3 3.5Mabili~ (rrds)Figure 8. DSR - Throughput with varied mobility.

4.2.2 Second set of simulations - Varied LoadAt higher offered loads, DSDV exhibits the highest drop inthroughput (50 percent at 20 packets/s). This is due to pack-ets being dropped along outdated routes (see Figure 9).DSR, in Figure 8, also shows a big drop in throughput athigher loads, e.g., 40 percent at 20 packets/s. This is an ef-fect of the higher network load caused by the source routescarried in all data packets. Thus, DSR will face a higherpacket loss than AODV at higher loads. AODV is more ro-bust and drops about 28 percent in throughput at 20 packets/s (see Figure 7).Note that at the highest packet rate, 20 packets/s, and zeromobility, all protocols still only deliver about 80 percent ofthe offered packets. At this load the network drops a ratherlarge number of packets due to buffer overflow in some con-gested nodes. This congestion is caused by an increase inMAC layer packet collisions, giving less capacity to drainqueues, combined with a higher aggregated packet rate insome forwarding nodes.

Figure 7. AODV - Throughput with varied offered traffk.

Figure 9. DSDV - Throughput with varied offered traffk.4.3 Routing protocol overheadThe overhead was measured as number of control packetsand as byte overhead. The latter includes overhead in datapacke ts, e.g. source routes as well as the entire control pack-ets. The total number of packets (or bytes) sent during theentire simulation is reported . Only overhead stemming fromthe IP layer is included, i.e. link layer or physical layer over-head is not.The packet overhead shown in Figure 10 clearly exposes thecharacteristics of the three protocols. DSDV does not adaptto increased mobility; the update intervals remain constant.AODV and DSR on the other hand detect and react to morelink failures when mobility increases, resulting in an in-creased number of control packets. Moreover, AODV sendsHELLO packe ts periodically which gives it a higher packetoverhead.Figure 11 shows the byte overhead. It reveals the impact ofoverhead for source routes as used by DSR. DSDV has thehighest byte overhead of all protocols because the routingtable updates often contain the entire routing table. This is

201


8/12

I.&+06 - AODbGW&&,AAC---a.-- DSR,.6e+06 -.-a.- DSDV .;

-0 0.5 1 1.5 2 2.5 3 3.5Mobility (Ws)Figure 10. All - Packet overhead w ith varied mobility.

%__~!2,5e*m.. ; ..:...j%t

2e+c6 -

t ,.Ej.3+06 - -. I .; . ;,. y .._.,..,. ,. . ..,,,..... .,,,0

I0 0.5 1 1.5 2 2.5 3 3.5

Mab6ity W4Figure 12. AODV - Byte overhead at varied offered traffic.accentuated when the mobility increases since more routesneed to be fully updated in each update. At high offeredloads the byte overhead becomes large for DSR, as can beseen from the upper plots in Figure 13. The high byte over-head at low mobility is caused by many packets being deliv-ered and thus also many source routes carried in data packetheaders. The byte overhead decreases for DSR when themobility increases to moderate values and causes lowerthroughput. At the highest mobility the overhead increasesagain as more control packets are needed to acquire routes.AODV has a more robust byte overhead than DSR a t higherloads since the overhead is caused by control packe ts only(Figure 12). It needs to be pointed ut, however, that thesmall packets used (64 bytes) penalizes DSR because thesource routes are large compared to the payload.5. SIMULATIONS - REALISTICSCENARIOSIn order to investigate how the routing protocols perform inless artificial scenarios than random movement, three real-istic scenarios were designed and simulated. The scenariosare

2wM)ot . .i... j ..:. ; ; .,. . .f 101 I0 0.5 1 1.5 2 2.5 3 3. 5

MckilW (nvS)Figure 11. AU - Byte overhead with varied mobility.

soccQO-

0 0 OS 1 1.5 2 2.5 3 3.5Mobility (rds)Figure 13. DSR - Byte overhead at varied offered traffhz.

. Conference, with low mobilityl Event Coverage, with fairly high mobility.l Disaster Area, with some relatively slow nodes andsome very fast nodes (vehicles).The names of the scenarios attempt to categorize them andshould not be construed as precise definitions. The parame-ters common to all simulations are given in Table 5.

Table 5: Parameters used during realistic simulations.

202


9/12

Speed of a vehicle (not used)a. Disaster Area only

2oa t-l-h I establish routes to the speaker to try to decide, based on theretrieved information, if they should join the session or not.Low-power radios used for indoor communication typicallycannot propagate signals through walls, doors, and other ob-stacles in a building, without severe attenuation. Similarconditions may exist in an outdoor scenario, where objectsin the terrain, such as buildings, cars, etc. may shadow radiotransceivers. In order to get significant results in a simula-tion claiming to be realistic, obstacles to radio propagationshould be mode led. Consequently, the capability to modelobstacles1 was added to the simulation tool. This feature al-lows the placement of obstacles in the form of boxes amongthe moving nodes. If the straight line between any twonodes are crossed by an obstacle, a link between these nodesis considered broken until the nodes move out of the shad-owed area (the straight line is not crossed). A more realisticmodel would include radio signals penetrating some of theobjec ts only partly absorbed as well as reflected radio sig-nals. However, this simple model is a first approx imationonly, which assumes fully absorbing objects.5.1 Conference scenario

The conference scenario has rather low mobility as only 10percent of the nodes are moving at any moment in time. Theroutes typically involve many hops and the traffic is concen-trated to the speaker. Due to high node density, there will berelatively high radio interference.The purpose of this scenario is to test responsiveness to lo-cal changes of long-lived routes. Furthermore, the low mo-bility in combination with the traffic concentration willstress congestion properties.The results fare shown in Table 6. The calculated mobilityfor this scenario is very low. AODV and DSR perform quitewell, they deliver 94 to 98 percent o f the packe ts with an av-erage throughput of 15.0 - 15.7 kbps. DSDV delivers only75.6 percent of the packets with an average throughput of12.1 kbps. This indicates that an ad-hoc routing protocolmust adapt quickly to topology changes even for long-livedroutes.

Table 6: Conference simulation results.

I \Zone 1 4 Spiaker

-Transmitter Rangew *

0 0000 00-00 00.0..

0.0. 0 0 00

5.2 Event coverageThe event coverage scenario, depicted in Figure 15, modelsa group of 50 highly mobile people which are frequently

l = Node H= changing position. It may represent a group of reporters thatObstacle K= Movement are covering a political event, a sport event, or stockbrokersFigure 14. Conference scenario. negotiating at a stock exchange.

The conference scenario models 50 people attending a con-ference, seminar session, or a similar activity as illustratedin Figure 14. It includes 2 CBR sources and 6 receivers re-sulting in 6 CBR flows. Three zones can be distinguished inthe scenario: 1) the speaker zone where the speaker movessideways and constantly changes her/his closest neighbor inthe audience, 2) the audience zone where people are ratherstatic, when someone moves a long-lived route might break,3) the entrance zone where curious people outside-the room

1. Obstaclescould be placed out in the original version of the mo-bility extensions rom CMU, but these were transparent o radiosignals.

There are 9 CBR sources and 45 receivers, giving 45 CBRflows. The scenario has a rather high mobility in that at anymoment 50 percent of the nodes move with a speed of 2 m/s.Clusters consisting of around 10 nodes are formed sponta-neously in the network as the nodes move. The routes con-sist of relatively few hops and are generally short lived.Since the simulation area has many obstacles, interference israther low unless clusters are formedThe objective with this scenario was to test the ability to re-spond to fast topology changes and fluctuating traffic. More-over, the overhead due to frequent topology changes wasalso of interest. The traffic was intentionally spread out allover the area to avoid congested nodes in this scenario.

203


10/12

1 Average hop-count 1.46 hops 1S7 hops 1,55 hops5.3 Disaster area

. =Node I= Obstacle L= MovementFigure 15. Event coverage scenario. I

The results from the simulations are presented in Table 7.All protocols have fairly high throughput, with DSR andAODV performing best. The event coverage scenario has afairly low mobility (0.72) due to the low speed (I m/s) of themoving nodes. The traffic is generally traversing only a fewhops (on average 1.5). The short paths result in low byteoverhead for DSR since the source routes in data packets areshort (160 kB overhead compared to over 4 MB for the con-ference scenario).

. Subnetwork& I

AODV gives a delay almost a magnitude lower than DSRwith roughly the same throughput. This is a positive effectof the HELLO message mechanism in AODV, which givesan a priori knowledge of the neighbors. It fits nicely in thisscenario since the destination of a packet sent in a cluster isoften a neighbor. The route acquisition procedure need notbe invoked, which saves time.An entirely proactive protocol like DSDV may have largeoverhead due to frequent full topology updates, which alsoadd extra load to the network. In this scenario the offeredtraffic load was low so DSDV had a fairly high throughputand low delay.

Table 7: Event coverage simulation results.

a -. l .-/\\ /

w =Node m = Obstacle k= MovementFigure 16. Disaster area scenarios

The disaster area scenario aims at representing a rescue op-eration at a natural disaster area. Members of the rescueteam have personal communicators with ad-hoc network ca-pability. The scene, depicted in Figure 16, consists of threegroups that can intercommunicate only via the nodesmounted on vehicles 1 and 2 (helicopters, cars etc.). The ve-hicles are moving back and forth at 20 m/s, while the othernodes (people) move m ore slowly (I m/s) and randomlywithin each group. There are 38 CBR sources with 87 re-ceivers for a total of 87 CBR flows.The characteristics of this scenario include diverse mobili-ties (95 percent o f the nodes have low mobility and 5 per-cent very high) and several network partitioning events.Thus it provides a way to study how the protocols behavewhen node speeds are diverse and when the network parti-tions and heals.Throughput is measured only when the CBR flows are actu-ally being received in order to show the performance whenthe network is not partitioned. This explains the seemingdiscrepancy between throughput and the fraction of receivedpackets.Results are shown in Table 8. Due to the network partition-ing events, less than 55 percent of the deliverable offeredtraffic is delivered. DSDV only delivers about 30 percent ofthe traffic, which is a clear indication that proactive proto-cols should not be used under these conditions.DSDV has the lowest delay, mainly due to its low deliveryratio; packets are dropped instead of queued. AODV hasslightly lower delay than DSR because the HELLO mecha-nism provides routes to neighbor nodes immediately.The rather large hop-count result in substantial overhead for

204


11/12

DSR because the source routes become relatively large.DSDV finds the shortest paths, just like in the other realisticscenarios, but the difference is more accentuated here. How-ever, DSDV drops a large number of packe ts due to invalidroutes, which must be taken into account. The rapidlychanging routes through the fast (vehicle) nodes are re-quired for inter-group traffic and are fairly long. DSDV can-not adapt well to such fast route changes and thus the routesfound by DSDV are relatively short.

Table 8: Disaster area sil lulation results.DSDV

Mobility factor 1.16Received 29.5%Throughput [kbps] 12.42Sent 29.6. lo3Average delay [s 0.196Dropped 20.9 . lo3Received packets 8.8 . lo3 16.2. lo3 16.0. lo3Packet overhead 41.4. lo3 30.7 . lo3 77.3 * lo3Byte overhead [MB] 6.50 5.14 3.10I IAverage hop-count 3.42 hops 15.16 hops 15.26 hops6. CONCLUSIONSThe simulations presented here clearly show that there is aneed for routing protocols specifically tuned to the charac-teristics of ad-hoc networks. The mobility metric usedthroughout the study explicitly shows how the examinedprotocols behave for various degrees of relative node mo-tion. The mobility metric is explicitly designed to capturethe kind o f motion important for an ad-hoc network - therelative motion of nodes. It can be used for any continuousnode motion.In networks with a dynamic topology, proactive protocolssuch as DSDV have considerable difficulties in maintainingvalid routes, and loses many packets because of that. Withincreasing mobility, its strive to continuously maintainroutes to every node increases network load as updates-be-coine larger.This study clearly indicates that a reactive routing protocolis superior to a proactive one. The principle of focusing onlyon explicitly needed connectivity, and not all connectivity,seems to be excellent when the network consists of movingnodes. In addition, the protocol should be able to detect linkfailures as quickly as possible to avoid use of invalid routes.Overall, the proactive protocols under study (AODV andDSR) behaved similarly in terms of delay and throughput.On the basis of this study both should be considered suitablefor mobile ad-hoc networks. However, a number of differ-ences between the protocols do exist.The source routes used by DSR give increased byte over-head compared to AODV when routes have many hops and

packet rates are high. DSR is, on the other hand, efficient infinding (learning) routes in terms of the number of controlpackets used, and does not use periodic control messages.Data packets in AODV carry the destination address only,and not source routes. Therefore, the byte overhead forAODV is the lowest of the examined protocols. The over-head is however high in terms of packets since AODVbroadcasts periodic HELLO messages to its neighbors, andneeds to send control messages more frequently than DSRto find and repair routes.The simulations in this work show that DSR performs betterthan AODV for low traffic loads, since it discovers routesmore efficiently. At higher traffic loads, however, AODVperforms better than DSR due to less additional load beingimposed by source routes in data packets.The realistic scenarios were examined to get an understand-ing on how the protocols would behave in an environmentmore realistic than the random scenarios. The results con-firm most of the properties found in the random scenarios.DSDV had considerable difficulties in handling m ost sce-narios even though the mobility was kept rather low. Theconference scenario and event coverage scenarios were han-dled very well by both DSR and AODV, with DSR generallyproviding slightly better performance. The loads were ratherlow and did not bring out the byte overhead disadvantage ofDSR. The disaster area scenario was a challenge for all pro-tocols since most routes passed through fast nodes and linkswere often obscured by objects. DSR and AODV managedto deliver about 55 percent of the traffic while DSDV onlydelivered 30 percent. It should be noted, however, that thedisaster scenario exhibited frequent partitioning of the net-work.Both DSR and AODV performed quite well for almost allexamined scenarios, while DSDV had serious performanceproblems. As a preliminary recommendation, DSR shouldbe considered for ad-hoc networks where paths have a limit-ed number of hops and where it is crucial to limit packetoverhead. AODV on the other hand appears to perform bet-ter in networks where paths have many hops and low byteoverhead is preferred over low packet overhead.7. FURTHER WORKThe work presented herein is the first of a series of simula-tion studies within the area of mobile ad-hoc networking.These studies will includel additional analysis of other proposed protocols (e .g.TORA, ZRP and CBRP),l measurements and estimation of power consumption andprocessing costs,l other traffic than CBR (e.g., TCP transfers),l inclusion of QoS mechanisms for real-time and non real-time traffic,. evaluation of proposed multicast routing protocols,l analysis of interworking functions for Mobile IP.

205


12/12

8. ACKNOWLEDGEMENTThe authors would like to thank the students and facultymembers within the Monarch Projec t at CMU. Their workon the ad-hoc network extensions for the ns2 simulator hasto a large extent contributed to this work .9.111

PI

131

[41

[51

[61

r71

PI

r91

REFERENCESBommaiah, McAuley and Talpade. AMRoute, AdhocMulticast Routing Protocol, Internet draft, draft-tal-pade-manet-amroute-OO.txt, August 1998. Work inprogress.Josh Broth, David A. Maltz, David B. Johnson, Yih-Chun Hu and Jorjeta Jetcheva, A performance Com-parison of Multi-hop Wireless Ad Hoc Network Rout-ing Protocols. Mobicom98, Dallas Texas, 25-30October 1998.Josh Broth, David B. Johnsson, David A. Maltz, TheDynamic Source Routing Protocol for Mobile Ad HocNetworks. Internet Draft, draft-ietf-manet-dsr-OO.txt,March 1998. Work in progress.M.Scott Corson, S. Papademetriou, Philip Papa-dopolous, Vincent D. Park and Amir Qayyum, AnInternet MANET Encapsulation Protocol (IMEP) Spec-ification. Internet draft, draft-ietf-manet-imep-specOl.txt, August 1998. Work in progress.Kevin Fall and Kannan Varadhan, ns notes and docu-mentation. The VINT project, UC Berkeley, LBL,USC/ISI, and Xerox PARC, May 1998. Work inprogress.Zygmunt J. Haas and Marc R. Pearlman, The ZoneRouting Protocol (ZRP) for Ad Hoc Networks, Inter-net draft, draft-ietf-manet-zone-zrp-01 .txt, August1998. Work in progress.IEEE Computer Society LAN MAN Standards Com-mittee, Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) Speci$cations, IEEE Std802.11-1997. The Institute of Electrical and ElectronicsEngineers, New York.Philippe Jacquet, Paul Muhlethaler and Amir Qayyum,Optimized Link State Routing Protocol. Internetdraft, draft-ietf-manet-olsr-OO.txt, November 1998.Work in progress.Mingliang Jiang, Jinyang Li and Yong Chiang Tay,Cluster Based Routing Protocol (CBRP) Functionalspecification. Internet draft, draft-ietf-manet-cbrp-spec-OO.txt, August 1998. Work in progress.

[IO] David B. Johnson and David A.Maltz, Dynamicsource routing in ad hoc wireless networks. In MobileComputing, edited by Tomasz Imielinski and HankKorth, chapter 5, pages 153- 181. Kluwer AcademicPublishers, 1996.[ 1 ] David B. Johnson and David A. Maltz, Protocols foradaptive wireless and mobile computing. In IEEE Per-sonal Communications, 3(l), February 1996.[ 121Mobile Ad-hoc Networks (MANET). URL: http://www.ietf.org/html.charters/manet-charter.html. (1998-1 -29). Work in progress.[ 131Vincent D. Park and M. Scott Corson, Temporally-Ordered Routing Algorithm (TORA) Version 1: Func-tional specification. Internet draft, draft-ietf-manet-tora-spec-01 .txt, August 1998. Work in progress.[ 141Vincent D. Park and M. Scott Corson, A performancecomparison of the Tempora lly-Ordered Routing Algo-rithm and Ideal Link-state routing. In Proceedings ofIEEE Symposium on Computers and Communication98, June 1998.[ 151Charles E. Perkins, Ad Hoc On Demand Distance Vec-

tor (AODV) Routing. Internet draft, draft-ietf-manet-aodv-Ol.txt, August 1998. Work in progress.[ 161Charles E. Perkins, Ad Hoc On Demand Distance Vec-tor (AODV) Routing. Internet draft, draft-ietf-manet-aodv-02.txt, November 1998. Work in progress.[ 171Charles E. Perkins and Pravin Bhagwat, Highlydynamic Destination-Sequenced Distance-Vector rout-ing (DSDV) for mobile computers. In Proceedings ofthe SIGCOM 94 Conference on CommunicationsArchitecture, protocols and Applications, pages234-244, August 1994. A revised version of the paper isavailable from http://www.cs.umd.edu/projects/mcml/papers/Sigcomm94.ps. (1998-1 l-29)[ 181Larry L. Peterson and Bruce S. Davie, Computer Net-works - A Systems Approach. San Francisco, MorganKaufmann Publishers Inc. ISBN l-55860-368-9, 1996.[ 191Raghupathy Sivakumar, Prasun Sinha and VaduvurBharghavan, Core Extraction Distributed Ad hocRouting (CEDAR) Spec ification, Internet draft, draft-ietf-manet-cedar-spec-OO.txt, October 1998. Work inprogress.[20] The CMU Monarch Project. The CMU MonarchProjec ts Wireless and Mobility Extensions to ns.URL: http://www.monarch.cs.cmu.edu/. (1998-1 l-29).Work in progress.

206

scenario based performance of routing protocols

Documents