PROTOCOLS FOR MOBILE AD HOC NETW ORKING FOR MOBILE AD HOC NETW ORKING Robert Castaneda,˜ B.S., ... ﬂooding by exploring multiple, ... to run internetworking …

PROTOCOLS FOR MOBILE AD HOC NETWORKING

APPROVED BY SUPERVISING COMMITTEE:

Dr. SamirR. Das,SupervisingProfessor

Dr. RobertHiromoto

Dr. KleanthisPsarris

Dr. WeiningZhang

Dr. ParimalPatel,OutsideMember

Accepted:

Deanof GraduateStudies

Dedication

Thisdissertationis dedicatedto:

� Robert Gabriel Castaneda, my son;

AND

� Henry G. Castaneda, my father, and

� RomanaCastaneda, my mother.

Without their love, support,andencouragementI could not have completedthe requiredresearchfor this

dissertation.Thankyou.


by

ROBERT CASTANEDA, B.S.,M.S.

DISSERTATIONPresentedto theGraduateFacultyof

TheUniversityof TexasatSanAntonioin PartialFulfillmentof theRequirementsfor theDegreeof

DOCTOROFPHILOSOPHYIN COMPUTERSCIENCE

THE UNIVERSITY OFTEXAS AT SAN ANTONIOCollegeof SciencesandEngineering

Divisionof ComputerScienceDecember2000

Acknowledgements

I would like to expresssinceregratitudefor the time, encouragement,andguidanceprovided by my

advisor, Dr. SamirR. Daswhosehelpcannotbe truly expressedin words. I alsowould like to thankDr.

RobertHiromoto,Dr. WeiningZhang,Dr. KleanthisPsarris,andDr. ParimalPatelfor servingon my final

Ph.Dcommitteeandfor all of their supportandsuggestions.

Thisresearchwassupportedby theAFOSRgrantF49260-96-1-0472,TexasAdvancedTechnologyPro-

gramgrant010115-248b,NationalScienceFoundationgrantACI-9733836,NSFMII grantCDA-9633299,

andtheUniversityof TexasatSanAntonioDivisionof ComputerScience.Theresearchfor thisdissertation

wasconductedat theUniversityof TexasatSanAntoniowithin thelaboratoriesof theDivisionof Computer

Science.

I would alsolike to thankall of my friendswith whom I madeduring the pastfive yearson my path

towardearningmy doctoraldegree.Thanksfor all thegreattimesandfor all theencouragementandsug-

gestions.It madethis journey muchmorepleasantandmeaningful.Thankyouall.

August2000

iv


RobertCastaneda,B.S.,M.S.,Ph.D.TheUniversityof TexasatSanAntonio,2000

SupervisingProfessor:SamirR. Das

A mobileadhocnetwork is anautonomoussystemof mobilehostsconnectedby wirelesslinks. Such

networks areusefulin military andothertacticalapplications,e.g.,emergency rescueor explorationmis-

sions,wherecellular infrastructureis unavailableor unusable.Becauseof constantlychangingtopology,

adhocnetworksmustadoptefficient dynamicroutingtechniques.Routingoverheadis oneimportantcon-

cernasthewirelesslink bandwidthis typically low. Recently, anew classof protocolscalled“on-demand”

protocolshasreceivedattentionbecauseof their potentialfor low routingoverhead.On-demandprotocols

discover routeson an “as-needed”basis,ratherthanin a moreproactive fashion,asin the traditionallink

stateor distancevectorprotocols.This dissertationpresentsa comparative simulationstudyof on-demand

protocolswith themoretraditionalproactive protocolson a commonplatformacrossa rangeof traffic and

mobility scenarios.Thesimulationresultsshow thaton-demandprotocolsindeeddemonstratelow routing

overheads,but over-relianceon queryfloodingcanactuallycauseon-demandprotocolsto losemostof this

overheadadvantageat high loads.

As acountermeasure,wedevelopandevaluatetwo techniquesthatreducestheroutingoverheadfor on-

demandprotocols.Thefirst technique,calledquerylocalization, usescertainlocality heuristicsto prevent

network-wide queryflood. It effectively limits the queryto a small region wherethe routeis very likely

to be found. The secondtechnique,calledmultipathrouting, focuseson reducingthe frequency of query

floodingby exploringmultiple,disjoint routesperflood operation.This providestheroutingprotocolwith

alternaterouteswhentheprimaryroutebreaks.Simulationresultsshow thateitherof thesetechniquescan

reduceroutingoverheadssignificantly.

Unlike stationaryhosts,mobilehostscanoperateonly aslong asthe their batterieslast. Thus,battery

power conservation is animportantcomponentof a routingprotocol.We describea “power-aware” mech-

v

anismthat canwork with any on-demandroutingprotocolto offload the routing responsibilitiesfrom the

nodesrunninglow onbatterypowertowardsthenodeswith morepower. Thesimulationresultsdemonstrate

that this techniquedistributestheavailablebatterypower moreevenly andimprovestheoperationlifetime

of theadhocnetwork.

vi

Contents

Acknowledgements iv

Abstract v

List of Figures ix

1 Intr oduction 11.1 UnicastRoutingProtocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Link StateProtocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.2 DistanceVectorProtocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.3 MultipathProtocols– TORA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.4 On-DemandProtocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.5 OtherProtocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 PowerManagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 ConcludingRemarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 PerformanceEvaluation of UnicastRouting Protocols 132.1 SimulationModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Detectinglink statuschanges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2 SimulationParameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 PerformanceResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4 ConcludingRemarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Query Localization Techniques 263.1 QueryLocalizationProtocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 DynamicNeighborhoodEvaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2 DistributedMaintenanceof Locality Information . . . . . . . . . . . . . . . . . . . 29

3.2 PerformanceEvaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.1 SimulationResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.4 ConcludingRemarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 On-DemandMultipath Routing 454.1 MultipathDynamicSourceRouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 PerformanceEvaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.4 ConcludingRemarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

vii

5 On-DemandPower-Aware Routing 625.1 Power-AwareRouting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1.1 PerformanceTradeoffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2 PerformanceEvaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.1 SimulationResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.4 ConcludingRemarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6 Conclusions 766.1 PerformanceEvaluationof RoutingProtocols . . . . . . . . . . . . . . . . . . . . . . . . . 776.2 Reductionof RoutingOverhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.2.1 QueryLocalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2.2 MultipathRouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.3 On-DemandPower-AwareRouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.4 FutureWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Bibliography 80Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Vita 85

viii

List of Figures

1.1 A mobileadhocnetwork. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Fractionof packetsdeliveredin a30and60mobilehostnetworksfor all routingprotocols. . 202.2 Averageend-to-enddelayin a30and60mobilehostnetworksfor all routingprotocols.. . . 212.3 Normalizedroutingloadin a 30and60mobilehostnetworksfor all routingprotocols. . . . 22

3.1 Illustrationof thepathlocality principlewith k=1. . . . . . . . . . . . . . . . . . . . . . . . 273.2 Routingoverheadfor bothprotocolsfor differentvaluesof k. . . . . . . . . . . . . . . . . . 333.3 Datapacket delivery fractionfor low andhighmobilitiesfor differentvaluesof k. . . . . . . 343.4 Averagedelayfor low andhighmobilitiesfor differentvaluesof k. . . . . . . . . . . . . . . 353.5 Routingoverheadanddatapacket delivery metricsfor low andhighmobilitiesfor dynamic

choiceof k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.6 Averagedelaymetricfor low andhighmobilitiesfor dynamicchoiceof k. . . . . . . . . . . 373.7 Square-with-a-holeregion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.8 Routingoverheadanddatapacket delivery metricsfor low andhighmobilitiesfor dynamic

choiceof k within thesquare-with-a-holeregion. . . . . . . . . . . . . . . . . . . . . . . . 383.9 Averagedelaymetricfor low andhighmobilitiesfor dynamicchoiceof k within thesquare-

with-a-holeregion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.10 Routingoverheadand datapacket delivery metricsfor 1 conversation/nodewith varying

mobilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.11 Averagedelaymetricfor 1 conversation/nodewith varyingmobilities. . . . . . . . . . . . . 413.12 Routingoverheadand datapacket delivery metricsfor 9 conversation/nodewith varying

mobilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.13 Averagedelaymetricfor 9 conversation/nodewith varyingmobilities. . . . . . . . . . . . . 43

4.1 Multipathprotocol1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2 Multipathprotocol2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3 Numberof routediscoveriesandfraction of datapacketsdroppedfor the singlepathand

bothmultipathDSRprotocolsusing1, 3, and5 alternateroutes. . . . . . . . . . . . . . . . 514.4 Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaverage

hoplengthfor thesinglepathandmultipathDSRprotocol.Themultipathprotocol(protocol2) usesonedisjointalternateroutefrom eachintermediatenode(includingthesource)to thedestination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.5 (a): Total numberof routingpacketstransmittedduringthesimulationrun for thesamesetof simulationsasin Figure4.4. (b)-(d): Breakdown of theroutingpacketsin request,reply,anderrorpackets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.6 Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaveragehop lengthfor the samenetwork with varyingmobility. Now the traffic load is fixed at 1conversationpernode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ix

4.7 (a): Total numberof routingpacketstransmittedduringthesimulationrun for thesamesetof simulationsasin Figure4.6. (b)-(d): Breakdown of routingpacketsin request,reply, anderrorpackets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.8 Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaveragehop lengthfor the samenetwork with varyingmobility. Now the traffic load is fixed at 9conversationspernode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.9 (a): Total numberof routingpacketstransmittedduringthesimulationrun for thesamesetof simulationsasin Figure4.8. (b)-(d): Breakdown of routingpacketsin request,reply, anderrorpackets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1 WarningZoneState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 Low ZoneState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3 Datapacket delivery andbatterylevel remainingpernodefor 5 conversationsand10 con-

versations,respectively, for low mobility. . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.4 Variousperformancemetricsfor 5 conversationsatmediummobility. . . . . . . . . . . . . 715.5 Variousperformancemetricsfor 10conversationsat mediummobility. . . . . . . . . . . . . 725.6 Variousperformancemetricsfor 20conversationsat high (12m/s)mobility. . . . . . . . . . 73

x

Chapter 1

Intr oduction

A mobile,adhocnetwork [12] is anautonomoussystemof mobilehostsconnectedby wirelesslinks (Figure

1.1). Thereis no staticinfrastructuresuchasbasestations.If two hostsarenot within radiorangeof each

other, all messagecommunicationbetweenthemmustpassthroughoneor more intermediatehoststhat

doubleasrouters.Thehostsarefreeto movearoundrandomly, thuschangingthenetwork topologydynam-

ically. Suchnetworksarevery usefulin military andothertacticalapplicationssuchasemergency rescue

or explorationmissions,wherecellularinfrastructureis unavailableor unreliable.Commercialapplications

arealsolikely wherethereis aneedfor ubiquitouscommunicationserviceswithout thepresenceor useof a

fixedinfrastructure.Examplesincludeon-the-flyconferencingapplications,networking intelligentdevices

or sensors,etc.

Interestin suchdynamicwirelessnetworks is not new. It datesbackto the seventies,whenthe U.S.

DefenseResearchAgency, DARPA workedon PRNET(Packet radioNetwork) [39] andSURAN (Surviv-

ableAdaptive Networks)[60] projects.They supportedautomaticroutesetupandmaintenancein a packet

radio network with moderatemobility. Interestin suchnetworks hasrecentlygrown dueto the common

availability of wirelesscommunicationdevicesthatcanconnectlaptopsandpalmtopsandoperatein license

freeradiofrequency bands(suchastheIndustrial-Scientific-Military or ISM bandin theU.S.). In aninterest

to run internetworking protocolsonadhocnetworks,anew workinggroupfor Mobile, Ad hocNetworking

(MANET) hasbeenformedwithin theInternetEngineeringTaskForce(IETF) [48], whosecharterincludes

developinga framework for runningIP (InternetProtocol)-basedprotocolsin ad-hocnetworks. Interesthas

1

CHAPTER1. INTRODUCTION 2

Data

Data

Source

Destination

Figure1.1: A mobileadhocnetwork.

alsobeenpartially fueledby therecentIEEEstandard802.11[19] thatincludestheMAC (MediumAccess

Control)protocolandphysicallayerspecificationsfor wirelessLANs withoutany fixedinfrastructure.

Efficient packet routing is thekey researchissuein adhocnetworks. Several characteristicsof thead

hoc networks make the routing problemvery differentthanwired networks. First, dynamicallychanging

network connectivity requiresthat routesbeupdatedfrequently. Second,low bandwidthof wirelesslinks

necessitatesthatroutingoverheadbekeptlow, sothatonly asmallfractionof network bandwidthis spenton

transmittingroutingpackets(asopposedto datapackets).Third, quickconvergenceof theroutingprotocol

may be crucial even if the routesobtainedmay be sub-optimal.This is becausespendinga long time to

obtaina high quality route(e.g.,shortestpath)may not be very productive, asroutesmay changeby the

time routediscovery is complete.Thus,thereexists interestingtrade-offs betweenthequality of theroute,

andtime andoverheadspentin discovering that route. Fourth, the longevity of a node’s batterybecomes

anissuesincethey will beusingbatteryenergy to sustainlife within anadhocnetwork. Routingprotocols

designedwith energy conservationin mindmaybecomeanimportantcriteriathatmayneedto beaddressed.

Severalqualitativepropertiesfor designinga routingprotocolaredesiredfor a mobileadhocnetwork.

First, theoperationof theprotocolshouldbedistributedandnot centralizedto any onelocation.A central-

izedprotocolleavesopenthedoorfor congestionproblems.Also, thewholenetwork will fail if thecentral

controllernodefails. Second,theprotocolshouldfind loop-freeroutes.Third, theprotocolmusthave the


ability to adaptto the topologyandtraffic patternsof thenetwork. Theprotocolshouldbeableto do this

with low routingoverhead.Fourth,availability of undirectionalor bidirectionallinks will influencetheper-

formanceof a routingprotocol. Designingrouting protocolswith the assumptionof bidirectionallinks is

usuallythenormandmakesthefunctionalityof thealgorithmseasier. In real life, networksmaynot have

this luxury andmayin facthave unidirectionallinks thatmayincur substandardperformanceon protocols

thatwork well with bidirectionallinks.

Thereareseveralquantitativeperformancemetricsthatcanbeusedto assesstheperformanceof routing

protocolswithin a mobileadhocnetwork. First, throughputandend-to-enddelayaretypical performance

measuresthatshow aroutingprotocol’s effectivenessin doingits job (i.e. deliveringdatapackets).Second,

for certainprotocolsthatacquirerouteson-demandtheamountof time it takesto acquirea routeor route

discovery latencyis alsoan importantperformancemeasure.This measurementmoreeasilyconformsto

thoseprotocolsthatareof ademand-basepropertyandthusshouldbeacquired.Third,bandwidthutilization

shouldbeobserved to seehow effective theprotocolis if both routingpacketsanddatapacketssharethe

samechannel.Onesuchmeasurewould be to obtainthe numberof bytes(or packets)of routingpackets

transmittedpernumberof bytes(or packets)of datapacketsdelivered.Anothersuchmeasurementmaybe

theamountof databits transmittedperdatabit deliveredto show theefficiency of datadelivery throughout

thenetwork.

Theobjective of this dissertationis understandingandimproving theperformanceof routingprotocols

for mobileadhocnetworks. In anattemptto understandtheperformanceissuesbetter, we have performed

acomparativeperformanceevaluationof someexistingroutingprotocolsof adifferentnatureundervarying

traffic andmobility conditions. Our work is oneof the first major comparative evaluationwork reported

that hasbeenreportedin literature[17, 18]. We will then focus on a classof routing protocols,called

“on-demand”protocols,that show a significantpromisecomparedto othersbecauseof their low routing

overhead,anddesigntechniquesto reducetheir routingoverheadsfurther. Two differenttechniques,query

localizationandmultipathroutingareproposedandevaluatedto reducetheroutingoverhead.Finally, we

turnedour attentionto batterypower managementfor on-demandprotocolsanddevelop techniquesthat

limit power usagewithout any significantnegative impacton routingperformance.Power managementof


theroutingprotocolsareimportantasadhocnetworksareexpectedto beprimarily batteryoperatedwithout

many opportunitiesfor frequentrecharging of batteries.At the end,we will presentour conclusionsand

pointersto futureresearch.

In the restof this chapterwe review currentstate-of-the-artin ad hoc network research.Specifically,

we review two areas:unicastroutingprotocolsandpower management.Link layer issuessuchasmedium

accesscontrolor MAC protocolsor otherroutingprotocols,suchasmulticastaresomewhatorthogonalto

our interestsandarenot reviewedhere.

1.1 UnicastRouting Protocols

Routingprotocolsin packet-switchednetworkshave traditionallyusedeithera link-stateor distance-vector

typeroutingalgorithm[42]. Both algorithmsallow a hostto find thenext hopneighborto reachthedesti-

nationvia the“shortestpath.” Theshortestpathis usuallyin termsof thenumberof hops;however, other

suitablecostmeasuressuchaslink utilizationor queueingdelaycanalsobeused.Suchshortestpathproto-

colshave beensuccessfullyusedin many dynamicpacket-switchednetworks.Prominentexamplesinclude

usageof the link-stateprotocol in OSPF(OpenShortestPath First) [49] and useof the distance-vector

protocolin RIP (RoutingInformationProtocol)[33] for interior routing in the Internet. Even thoughany

suchprotocolwould, in principle,work for ad hocnetworks, a numberof protocolshasbeenspecifically

developedfor usewith adhocnetworks. Theprimarymotivation is that theshortestpathprotocols,either

link-stateor distance-vector, take too long to convergeandhave a high messagecomplexity [12]. Because

of thelimited bandwidthof wirelesslinks,messagecomplexity mustbekeptlow. Also, apotentiallyrapidly

changingtopologymakesit importantto find routesquickly, evenif theroutemaybesuboptimal[12].

Severalnew adhocroutingprotocolshave beendevelopedwith this basicphilosophy. They, however,

vary widely in characteristics.For example,someof theseprotocolsarevariationsof distancevectorrout-

ing. Someprotocolsexplicitly maintainredundantrouting pathsso that alternativesareavailablewhena

routechanges.Somerecentlyproposedprotocolsusea reactiveapproachfor routediscovery andmainte-

nance,insteadof themoretraditional,proactiveapproach[32]. In areactive approachprotocolsare“source

initiated;” routesarediscoveredandmaintainedon anasneededbasis,thuscircumventinglargeoverheads


of alwaysmaintainingroutesbetweenall possiblesourceanddestinationpairs. The protocolsarebriefly

reviewedin thefollowing section.

1.1.1 Link StateProtocols

Eachnodemaintainsits own view of the network topology, including link costsof all its outgoinglinks.

To keepviews up-to-date,eachnodebroadcaststhelink costsof all its neighbors1 to all othernodesin the

network usingflooding. This is donewhenever thereis a changein link costs. As a nodereceives this

information,it updatesits view of the network topologyandappliesa shortestpathalgorithm(Dijkstra’s

shortestpathalgorithm[21] in our simulations)to choosethenext hopto a destination.Asynchronouslink

costupdatesmaygiveriseto short-livedroutingloops;however, they disappearby thetimeupdatemessages

have propagatedthroughoutthe network [42]. In our simulationwe usedtheSPFimplementationof link

stateprotocolasdescribedin [61].

1.1.2 DistanceVector Protocols

In thedistancevectorapproach,for eachdestination�, every node� maintainsa setof distancesor costs,

�� , where � rangesover the neighborsof�. Node � is treatedasthe next hop nodefor a datapacket

destinedfor�, if

�� min�� . To keepthesedistancesup-to-date,whenever thereis any

changeof thisminimumdistancebecauseof link costchanges,thenew minimumdistanceis reportedto the

neighboringnodes.If, asa result,a minimumdistanceto any neighborchanges,this processis repeated.

This techniqueis theclassicaldistributedBellman-Ford algorithm[4].

Routingloops,bothshort-livedandlong-lived,arepossiblein thedistributedBellman-Ford algorithm.

Thereis also a possibility of the counting-to-infinity problem,whereit takes a large numberof update

messagesto detectthatanodeis unreachable[42]. Severalprotocolshave beenproposedto avoid thelong-

livedloopsandcounting-to-infinityproblems.They typically work by increasingtheamountof information

exchangedbetweennodesor providing somesortof inter-nodalcoordination.For example,in theBorder

Gateway Protocol(BGP) theentirepathbetweenthe sourceandthedestinationis sentinsteadof just the

1In amobile,adhocnetwork any nodecanpotentiallybeaneighbor.


distance[59]. In DUAL (Distributed UpdateAlgorithm) [28] inter-nodal coordinationis achieved via a

techniqueknown asdiffusingcomputation.

Here,we focusour attentionon two distancevectorprotocolswhich show themostpromisefor adhoc

networks. Thefirst, extendedBellman-Ford, achievedgoodperformancefor stationarynetworks in earlier

simulationstudies[61]. Thesecond,DSDV [56], wasspecificallyproposedfor mobile,adhocnetworks.

ExtendedBellman-Ford ExtendedBellman-Ford[11] augmentstheclassicalBellman-Fordby maintain-

ing onnode� , (in additionto thesetof distances�� ) asetof nodes� �� , whichimmediatelyprecedes

thedestination�

in thepathfrom � to�

via neighbor� . Thenit is possiblefor thesourcenode�

to construct

thewholepathto thedestination,by repeatedlyusingtheprecedingnode � �� asa new destination.It

canbeshown thattheprotocolis freefrom bothlong-livedloopsandcounting-to-infinityproblems,if each

nodeavoidssendingroutechangeupdatesto aneighborfor any destination�, if thatneighboris in thepath

to�.

WeusedtheEXBF implementationdescribedin [61] for ourevaluation.Here,periodicallyor whenever

a failureor reconnectoccurs,link costsarerecalculated,andif thereis a changein theminimumdistance,

thenew minimumdistanceis reportedto theneighboringnodes.Severalprotocolsproposedin theliterature

arealsobasedon a similar ideaof maintainingthesecond-to-lasthop(predecessor)for theshortestpathto

eachdestinationto achieve loop freedom.See[50] andthereferencestherein.

DSDV Thedestinationsequenceddistancevectoror DSDV protocol[56] hasbeenspecificallytargeted

for mobile networks. DSDV augmentsthe classical,distributed Bellman-Ford by taggingeachdistance

entry�� by a sequencenumberthat originatedin the destinationnode

�. Eachnodemaintainsthis

sequencenumber, incrementingit eachtime the nodesendsan updateto the neighbors. The sequence

numberis disseminatedin thenetwork via updatemessages.Thedestinationsequencenumberis usedto

determinethe “freshness”of a route. Alwaysthe latestsequencenumberis usedfor updatingroutes.For

equalsequencenumbers,theonewith thesmallestdistancemetric is used.It hasbeenshown thatDSDV

avoidsthelong-livedloopsandcounting-to-infinityproblems[56].


1.1.3 Multipath Protocols– TORA

Theuniquefeatureof thetemporally orderedroutingalgorithmor TORA [54] is themaintainingof multiple

routesto thedestinationsothatmany topologicalchangesdo not requireany reactionat all, ashaving just

a singlerouteis sufficient. Theprotocolreactsonly whenall routesto thedestinationarelost. In thatcase

routesarere-establishedvia atemporallyorderedsequenceof diffusingcomputations,whichareessentially

link reversals, (to be describedmomentarily). In the event of network partitions,the protocol is able to

detectthepartitionanderaseall invalid routes.

TORA is based,in part,ontheclassicalwork by GafniandBertsekas[27], whoconsiderasimilarprob-

lem of maintaininga destinationorienteddirectedacyclic graph(DAG) in thefaceof topologicalchanges.

A DAG is considereddestinationoriented,if for every node,thereis a pathto a givendestination.If link

failuresmake sucha graph“destinationdisoriented,” aseriesof link reversalsensuesothatthegraphagain

becomesdestinationorientedin finite time. Thegraphis initially constructed(routediscovery or construc-

tion phase)in a “source-initiated”fashion,usinga queryflood followedby updateroutingpackets. From

that point it is maintained(routemaintenancephase)using link reversalsalone,whenever a topological

changecausesa nodeto loseits lastdownstreamlink. If thedestinationbecomesunreachablebecauseof a

network partition,theprotocolerases(routeerasurephase)all invalid routes.

TORA usesa notionof node“height” to maintainthedestinationorientedDAG. Eachnodemaintains

a heightandexchangesthis valuewith eachneighbor. The significanceof the height is that a link is al-

waysdirectedfrom a “higher” nodeto a “lower” node. Note that this notionof heightandlink directions

aredestinationspecific. Independentcopiesof theprotocolrunsfor eachpossibledestinationnodein the

network.

In theinitial routeconstructionphase,theheightof anodecarriesthenotionof distance(in hops)of the

nodefrom thedestination.However, this distanceinformationis eventuallylost duringroutemaintenance

phase.Sincemultipleroutesaremaintainedin TORA, anobviousquestionis thechoiceof route.Two alter-

nativesaresuggested– choosinganeighborrandomlysothattheloadsaremoreor lessevenlydistributedor

choosingthelowestneighbor[54]. Wehave chosenthelatterin ourevaluationsreportedin a laterchapter.


1.1.4 On-DemandProtocols

Link-stateanddistance-vectorprotocolsareprimarily proactiveprotocolsin thesensethatroutesaremain-

tainedto all potentialdestinations(possiblyall nodesin thenetwork) at all times,regardlessof whetheror

not all suchroutesareactuallyused.Routemaintenancecanbea large overheadbecauseof a significant

amountof routeupdatetraffic, especiallyfor largenetworks.Reactiveor on-demandprotocols,ontheother

hand,createandmaintainroutesonly on an“as needed”basis.Thus,whena routeis needed,somesortof

globalsearchprocedureis employed via flooding. Floodingis implementedasfollows. Whena “source”

nodeS needsto find a routeto a “destination”nodeD, nodeS broadcastsa routequery messageto all its

neighbors.2 A node,sayX, on receiving a routequerymessage,comparesthedesireddestinationwith its

own identifier. If thereis a match,it meansthat thequeryis for a routeto itself (i.e., nodeX). Otherwise,

nodeX broadcaststhequeryto its neighbors.To avoid redundanttransmissionsof routequeries,a nodeX

broadcastsa particularroutequeryonly once.Repeatedreceptionof a routequeryis detectedby theuseof

sequencenumbers.Thisfloodingmechanismguaranteesthatif thedestinationis reachablefrom thesource,

thequerymessagewill eventuallyreachthedestination.

Thesequenceof hopstraversedby thefirst querymessagereceivedby thedestinationdefinestheroute

to be usedfor sendingdatapackets. On receiving the first query, the destinationrepliesto the sourceby

sendinga routereply message.If thewirelesslinks aresymmetric,the reply goesbackto thesourcejust

by retracingtheroutein theoppositedirection.Theactualmechanicsof doingthis variesfrom protocolto

protocol.For example,theDSR(DynamicSourceRouting)protocol[38], builds therouteincrementallyas

a sequenceof nodesvisitedby thequery, andstoresit in theheaderof thequerypacket. Thereply packet

carriesthis routeandsimply traversesit backwards. The Ad Hoc On DemandDistanceVector(AODV)

protocol[55], on theotherhand,maintainstheroutein specificdatastructureson thenodeson theroute.

DSRandAODV aretheprimeexamplesof reactiveor on-demandprotocols,andaredescribedin further

detailbelow asmany of our laterevaluationswill dealwith theseprotocols.NotethatTORA [54], described

earlier is also partially reactive in the sensethat route creationis initiated on-demand.However, route

2A singletransmissionreachesall neighborsdueto inherentbroadcastpropertyof thewirelessmedium.Two nodesaresaidtobeneighborsif they candirectlycommunicatewith eachother.


maintenanceis doneon a proactive basissuchthat multiple routing optionsareavailable in caseof link

failures.

DSR Dynamicsourceroutingor DSR[38] usesa techniquewherethesourceof adatapacket determines

thecompletesequenceof nodesthroughwhichto forwardthepacket; thesourceexplicitly lists this routein

thepacket’s header. DSRbuilds routeson-demandusingfloodedquerypacketsthatcarry thesequenceof

hopsthey passedthrough.Oncea queryreachesthedestination,thedestinationreplieswith a reply packet

thatsimplycopiestheroutefromthequerypacketandtraversesit backwards.3 Eachnodehasaroutecache,

wherecompleteroutesto desireddestinationsarestoredasgleanedfrom thereplypackets.Theseroutesare

usedby datapackets.Routefailureis detectedby thefailureof anattemptedmessagetransmission.Sucha

failure initiatesanerrorpacket sentbackward to thesource.Theerrorpacket erasesall routesin theroute

cachesof all intermediatenodeson its path,if theroutecontainsthefailedlink.

A recentimplementationof DSRby theauthorsof theprotocolincludedaquerycontainmentmechanism

[6]. Here,only theone-hopneighborsarequeriedusingasinglebroadcastfrom thesource.A network-wide

queryflood is initiatedonly whennoneof theone-hopneighborshasa routeto thedestination.

DSRhasanuniqueadvantageby virtueof sourcerouting.As therouteis partof thepacket itself, routing

loops,eithershort-or long-lived,cannotbeformedasthey canbeimmediatelydetectedandeliminated.This

propertyopensup the protocolto a variety of usefuloptimizations.For example,a floodedquerycanbe

quenchedearlyby having any non-destinationhostreply to thequeryif thathosthasarouteto theintended

destination.A nodecanlearnarouteto adestinationwhile passingonroutereplypackets.Also, routescan

beimprovedby having nodespromiscuouslylistento conversationsbetweenothernodesin proximity. We

haven’t implementedthis lastoptimization,however.

AODV Ad hoc,on-demanddistancevectorprotocolor AODV [55] is anon-demandvariationof distance

vectorprotocols.AODV usesdestinationsequencenumberslike DSDV to determinefreshnessof routing

information.In AODV, floodedrequestsareusedto createaroute,with thedestinationrespondingto thefirst

3We assumethat thewirelesslinks aresymmetric,which maynot be thecasein practice.DSRcantolerateasymmetriclinksby, for example,usinganindependentroutediscovery from destinationbackto thesource.We did not considerasymmetriclinksin ourevaluationsin thiswork.


suchrequest,muchasin DSR.However, AODV maintainsroutesin a distributedfashion,asroutingtable

entries,onall intermediatenodeson theroute.Routingtableentriesaretuplesin theform of � destination,

next hop,distance� . Nodesforwardingqueriesremembertheearlierhoptakenby thequerypacket. This

hopis usedto forwardthereplypacket backto thesource.Thereplypacket setsup theroutingtableentries

on its path. AODV advocatesuseof “early quenching”of requestpackets,i.e., any nodehaving a routeto

thedestinationcanreplyto arequest.AODV alsousesatechniquecalledrouteexpiry, wherearoutingtable

entryexpiresafterapre-determinedperiod,afterwhicha freshroutediscovery mustbeinitiated.

AODV maintainstheaddressesof theneighborsthroughwhichpacketsdestinedfor a givendestination

werereceived.A neighboris consideredactive(for adestination),if it originatesor relaysat leastonepacket

for thatdestination,within thepastactivetimeoutperiod. A routingtableentry is activeif it is usedby an

activeneighbor. Thepathfrom asourceto adestinationvia theactiveroutingtableentriesis calledanactive

path.Onalink failure,all routingtableentriesareerasedfor whichthefailedlink is ontheactivepath.This

is accomplishedby anerrorpacket goingbackwardsto theactive neighbors,which forward themto their

active neighborsandsoon. This techniqueeffectively erasestheroutebackwardsfrom thefailedlink.

NeitherDSR nor AODV guaranteesthe shortestpath. If the destinationalonecan respondto route

requests(i.e., earlyquenchingof routerequestsis not used)andthesourcenode(andnot an intermediate

node)is alwaystheinitiator of therouterequest,theinitial routemaybetheshortest.But dependingon the

changesin topologythis routemaynotalwaysremaintheshortest.

1.1.5 Other Protocols

Several other protocolshave appearedin literaturefor mobile, ad hoc networks. Zone routing protocol

(ZRP)[30, 31, 32] is azoneor clusterbasedroutingprotocolthatis ahybridbetweenproactiveandreactive

routing. It is targetedfor very largenetworksanddividesthenetwork into zonesor clustersof nodes.The

nodeswithin azonearecloseto oneanother.

ClusterBasedRoutingProtocol(CBRP)[36] is anotherclusterbasedprotocolthat is basedon source

routing similar to that usedin [38]. Nodesaregroupedtogetherinto clustersthat canbe overlappingor

disjoint. Usingdynamicroutediscovery, sourceswill cachetheir pathsto destinationsfor futureuse.The


protocolalsotakesinto considerationtheexistenceof unidirectionallinks andincorporatestheminto intra-

clusterandinter-clusterrouting.Quitea few morecluster-basedapproacheshave appearedin thepast.See,

for example,[60, 29, 46].

OptimizedLink StateRoutingProtocol(OLSRP)[35] is basedonthelink statetechnique.Theprotocol

is proactive, thereforenodesexchangetopologicalinformationamongeachotherperiodically. Using this

information,a routingtableis calculatedso thatdestinationsmaybereachedby a source.Theprotocolis

developedto work with theIMEP protocol[14] andis suitablefor largedensenetworks.

1.2 Power Management

Unlike stationaryhosts,a mobilehostcanoperateonly aslongasthelongevity of its battery. In critical en-

vironmentssuchasrescueoperationstheconservingof batterypower is vital in keepinganadhocnetwork

operational.Note that even if a hostdoesnot communicateon its own, it muststill routedataandrout-

ing packetsfor others.Much work hasgoneinto reducingthepower consumptionin non-communication

devicessuchasdisks[22] [34] andCPUs[47] [68] in mobilesystems.

However, relatively lesswork hasgoneinto reducingpower consumptionon thecommunicationcom-

ponentsof a mobilehostwithin awirelessenvironment.Whenaddressingthecommunicationcomponents,

themainobjective is to turn off thecomponentwhenit is idle to conserve power. However, reducingthe

power of a mobilehostby turningoff its communicationcomponentalsobringsforth theunwarrantedloss

of communicationor delay, asit is notusuallyclearwhenthecomponentshouldturnbackon.

In [67], theauthorssimulatedtrace-drivensimulationsusingthenetwork simulatorns[24], for protocols

TCPandUDP on readingemailandwebaccessby hand-helddevices. They thensuspendedthenetwork

interface(wirelessEthernetCard)periodicallyandshowedby increasingthesleepduration,anincreasein

power savingswasattainable.

In [45], theauthorsproposea transportlevel protocolto suspendthecommunicationdevice duringidle

periods. Using simulation-basedcommunicationpatternsand trace-driven communicationpatternsthey

showedareductionof powerusageduringtheseidle periods.Thepowersavingsvariedfrom 48%to 83%


on thecommunicationsavingswhich translatedup to 9% total savingsfor high endlaptopsandup to 40%

total savingsfor handheldPCs.

In [62], they proposean elaborateMAC level protocol to turn off the power of a mobile hostduring

unnecessarypower usage.Their protocol(PAMAS) is basedon the MACA protocol[40] coupledwith a

separatesignalingchannel.Theirresultsshowedpowersavingsfrom 10%to 70%dependingonthenetwork

topology. Unlikethepreviouswork [67] [45], thePAMAS protocolwassimulatedunderamultihopwireless

network environment.

1.3 Concluding Remarks

An adhocnetwork is characterizedby dynamicallychangingnetwork topologyandtheexistenceof multi-

hopwirelesslinks betweencommunicatinghosts.In thischapterwereviewedsomenetwork layerissuesin

suchnetworks,particularly, unicastroutingprotocols(bothproactive andreactive) andpower management.

Our later work for the dissertationevolvesaroundtheseareas.Efficient packet routing is, of course,the

mostcritical issuebecauseof the dynamicnatureof ad hoc networks. In the following chapterwe will

presenta comparative performanceevaluationof a suiteof protocolsfor mobileadhocnetworks.Thesuite

containsbothproactive andreactive (on-demand)protocols.In Chapter3 we will focuson a techniqueto

reduceroutingoverheadsfor on-demandprotocols.Thetechniqueworksby controllingtheextentof route

discovery flooding. Chapter4 will alsofocuson routingoverheadreductionfor on-demandprotocols,but

will emphasizereductionof frequency of suchfloodsvia multipathrouting. Chapter5 will concentrateon

power-awareon-demandrouting that attemptsto extendthe operationallife of a batteryoperatedad hoc

network. Conclusionswill bepresentedin Chapter6.

Chapter 2

PerformanceEvaluation of UnicastRoutingProtocols

Even thoughmany unicastrouting protocolshave beenproposedfor ad hoc networks, their comparative

performanceis not well understood.Currentliteraturereportsonly a limited amountof performancestudy

andwhenperformanceis reported,typically comparisonshave beenmadeonly to a selectedfew protocols

(typically only to link-stateanddistance-vectorprotocols).Specifically, beforeour work reportedherethe

unicastroutingprotocolshadnot beenevaluatedagainstoneanotherin thesameframework. Concurrently

with our work that we presentedin [17] or later, several independentcomparative evaluationshave been

reported.They will bereviewedin a latersection.

We will presenta comparative simulationstudyof a suiteof unicastrouting protocolswith different

characteristics.The protocolsuite includesall protocolsreviewed in the previous chapter, viz., proactive

protocolssuchasSPF(thelink stateprotocol),EXBF (extendedBellman-Ford) andDSDV; multipathpro-

tocol TORA; andon-demandprotocolssuchasDSRandAODV. We startout by describingthesimulation

framework andthenwewill proceedto theperformanceresultsandtheir interpretation.

2.1 Simulation Model

A discreteevent,packet-level, routingsimulatorcalledMaRS(MarylandRoutingSimulator)[3] wasused

for comparative performanceevaluation.MaRSis a flexible platformdevelopedspecificallyfor evaluation

andcomparisonof network routingalgorithms.MaRSwasusedpreviously for comparative evaluationof

13

CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 14

link-stateanddistance-vectorroutingprotocolsfor theNSFNETT1 backbonenetwork with thepossibility

of link failures[61]. We augmentedMaRSto provide nodemobility. The nodescanmove aroundin a

rectangularregion accordingto a given mobility model(to be describedmomentarily). Eachnodehasa

fixedradiorangeandhasa link to every othernodein thesystem.If theothernodeis not within rangethe

link costis infinity. Otherwise,thelink costis modeledby thehop-normalizeddelayfunction,sameasthe

revisedARPAnetcostmetric[43, 61].

Eachnodeis modeledby astore-and-forwardqueueingstation,andis characterizedby parameterssuch

asbuffer spaceandprocessingspeed.Eachlink is characterizedby a bandwidthandpropagationdelay. A

link is modeledasanFCFSqueuewith servicetimeasthetransmissiontime. Currently, ourstudyis limited

to network layerdetails.Thus,no link layerdetails,suchasMAC protocol,multiple-accessinterferenceor

link errorsaremodeled,norareany physical,radiochannellevel details.

Theroutingprotocolis modeledasanindependentroutingmodule,oneat eachnode,which maintains

routing information(suchasnext-hops,distances,routing tableetc. dependingon the protocolused)and

respondsto routingpacketsandlink statuschanges.Routingpacketsaredistinct from datapacketsin the

simulatorandareusedfor routemaintenance.Thenodesforwarddatapacketsvia thenext hoplink asper

therouting informationprovidedby the routingmodule. If thenext hop link is brokenor thereis no next

hop informationavailable,datapacketsaredroppeduntil someusablenext hop informationis available.

In sourceroutedprotocols,however, thedatapacketsthemselvescontaintheroutegleanedfrom theroute

cachemaintainedby theroutingmodule.

Workloadis definedin termsof conversations. A conversationis aunicastconversationbetweenasource

anda sink. Thesourceandsink aremodulesassociatedwith nodes.Severalworkloadmodelsareprovided

in MaRS.In this dissertation,however, we usethesimplestmodel,similar to a datagram,wherethesource

generatesdatapacketsdestinedfor thesink at a steadyrate.This traffic is characterizedby a packet length

andarandom(exponentiallydistributedin oursimulation)inter-packet generationinterval. Thereis noflow

or congestioncontrol.


2.1.1 Detectinglink statuschanges

An importantfeatureof mobilenetworks is detectionof link failuresor appearances.This canbedonein

a few ways,suchasperiodiclink statussensing/probingby so-calledhello messages.Link layerprotocols

thatuseacknowledgmentscanalsobeusedto detectlink failures.Sinceno link layerdetailsaremodeled,

a link layer event is generatedautomaticallywhenever a link fails or reappears,i.e., a nodegoesout or

comesin range.Theroutingprotocolrespondsto this event. No hello messageshave beenmodeledin our

implementations.

2.1.2 Simulation Parameters

Physical network We assumea channelbandwidthof 1.5 Mbits/sec.This datarateis similar to what is

obtainablefrom thecurrentgenerationwirelessLAN productsusingIEEE 802.11[19] or similar standard.

Sincenomultiple-accesscontentionor interferenceis modeled,eachlink essentiallyenjoys theentirechan-

nel bandwidthwhile transmittingpackets. In thesimulationmodel,a packet canbeunicast(receivedonly

by a specificneighbor)or broadcast(receivedby all neighbors).Broadcasttransmissionsaremodeledasa

sequenceof unicasttransmissionson all active links of a node,but a routing packet is countedonly once

in simulationstatistics. Datapacketsarealwaysunicast. 1 Routingpacketscanbe broadcastor unicast

dependingon theprotocolrequirement.

All nodesareassumedto haveadequatebuffer capacityfor bufferingpacketsawaitingforwarding.Data

packets areprocessed(includesparsingthe header, consultingthe routing tableor cacheandaddingthe

packet to theappropriateoutgoingpacketqueue)in parallel.Datapacketprocessingtimesarefixed.Routing

packetshave higherpriority over datapackets in the node’s outgoingpacket queue.Routingpacketsare

processedsequentially. Routingpacket processingtime and routing packet sizesdependon the routing

protocol being used. Data packet sizesare definedby the workload model plus a fixed, small header.

However, for sourceroutingtheheaderlengthis variableandcanbelongdependingon thelengthof the

1Passiveeavesdroppingmayimproveperformanceof someroutingprotocolssuchasDSR.Thiscouldbemodeledusingbroad-casttransmission.However, wedid notmodeleavesdroppingyet.


route.Packetprocessingtimesareestimatedvia independentsimulationrunsby timing theprocessingcodes

in thesimulatoritself.

Mobility Nodesmove aroundin a rectangularregion of size1000m � 1000m accordingto a mobility

model.Thenodeshaveaconstantradiorangeof 350m. Nodesareconstantlymoving, thusputtingstresson

theroutingprotocols.Thenodemovements,however, arediscretizedfor easeof modelingin adiscreteevent

framework. Eachnodechoosesa direction,speedanddistanceof move basedon a pre-defineddistribution

andthencomputesits next position � andthe time instant � of reachingthat position. Similarly, a new

“move” is againcomputedat simulationtime � . A nodecomputesits neighborhoodaftereachsuchmove,

thusgeneratinglink failureandlink repaireventsthatin turndrive theroutingprotocol.

For theexperimentsdescribedin this chapter, thespeedof eachmove is uniformly distributedbetween

a givenrange(0.4 – 0.6 m/secfor low mobility experimentsand3.5 – 4.5 m/secfor high mobility experi-

ments),distanceis exponentiallydistributedwith a meanof 5 m, andthedirectionis uniformly distributed

within � �"!#!�$&%#')(+*,!#!�$&%#'.- with respectto thedirectionof thepreviousmove. Notethatin thechosenmobility

model,thenodesarealwaysmoving (albeit in discretetime) without stationaryintervals. This presentsa

stresscasefor theroutingprotocols.All simulationsarerun for 10,000simulatedseconds.

Workload A simpleworkloadmodelisused.All datapacketsare512byteslong,andinterarrival timesare

exponentiallydistributedwith ameanof 300ms.Thereis noacknowledgment,or flow or congestioncontrol

in theworkloadmodel.Flow or congestioncontrolmechanismswill beinfluencedby theroutingdynamics

and thus will changethe load on the network. It is not clear how this will influenceour performance

metricsandhow comparisonshouldbemadeacrossroutingprotocolswith very differentdynamics.Thus

thesimplestdatagramworkloadmodelhasbeenchosen.Workloadtraffic is alwaysbetweenapairof source

andsinknodes,calledaconversation. Thenumberof suchpairsor conversationsis variedoverawiderange

in thesimulationexperiments.In theperformanceplots,it is presentedin termsof no. of conversationsper

nodein thenetwork.


2.2 PerformanceResults

Wehavesimulated30and60nodemobile,adhocnetworkswith respectto theabovemobility andworkload

models.All protocolsarestudiedwith respectto threekey performancemetrics:

� Fraction of packets delivered: measuredasa ratio of the numberof datapackets deliveredto the

destinationandthenumberof datapacketssentby thesender. Datapacketsmaybedroppedenroute

for two reasons:the next hop link is broken whenthe datapacket is readyto be transmitted,or no

routingtable(cache)entryexistsfor theintendeddestination.

� End-to-enddelay: measuredin ms(milliseconds).This delayincludesprocessingandqueueingde-

laysin eachintermediatenode.

� Routingload: measuredin a normalizedfashionin termsof numberof bytesof routing packets

transmittedper byte of datapackets transmitted. The latter includesonly the datapackets finally

deliveredat the destinationand not the onesthat are dropped. The transmissionon eachhop is

countedoncefor bothroutinganddatapackets. This givesanideaof network bandwidthconsumed

by routingpacketswith respectto “useful” datapackets.

Thefirst setof figurespresentthe fractionof datapacketsdeliveredfor all protocolsfor low andhigh

mobilitiesfor bothnetwork sizes(Figures2.1). Notetheexcellentbehavior on thepartof all link-stateand

distance-vectorprotocols,but considerablylower packet delivery fractionfor on-demandprotocolsaswell

asfor TORA. On-demandprotocols(DSRandAODV) dropa considerablenumberof datapacketsduring

the routediscovery phase,asrouteacquisitiontakestime proportionalto the distancebetweenthe source

anddestination.The situationis similar with TORA. Packet dropsarefewer with proactive protocolsas

alternateroutingtableentriescanalwaysbeassignedin responseto link failures.In SPF, analternateroute

is assignedfrom the currentnode’s view of the stateof all links in the network. In EXBF andDSDV, an

alternateminimumcostrouteis foundvia adifferentneighbor. However, nosuchalternative is availablefor

DSRandAODV andthuspacketsaredroppeduntil theroutecanberepaired.TORA, surprisingly, offers

the lowestpacket delivery fraction in spiteof its multipathcapability. In our observation, the key reason


for this is that the initial routediscoveriestake longer. This affectstheperformancemostwhenthereis a

reconnectionafteranetwork partition.In addition,in TORA wirelesslinks have asenseof direction,which

is maintainedby theprotocol. Becauseof theasynchrony in the distributedimplementation,therecanbe

short-lived inconsistenciesaboutthesenseof the directionof a link asperceived by thenodesat theend-

pointsof this link (e.g.,duringlink reversal).If thenetwork is congestedandthequeueingdelaysarehigh,

this inconsistency canpersistfor a while causingbothdelayandlossof packets.Thismorethanoffsetsthe

advantagesgainedby themultipathnatureof theprotocol.

We alsonoteherein passingthatTORA canbequitesensitive to thelossof routingpacketscompared

to theotherprotocols.Lossof certaintypesof routingpackets(e.g.,UPD, usingthe terminologyin [54])

canput the routing tablestowardsan inconsistentstate,which may take a while to recover. In the most

recentspecificationof TORA [53] it is recommendedthat TORA be run with an encapsulationprotocol

calledIMEP [14] thatguaranteesreliable,in-orderdelivery of routingpackets.We did not,however, feel it

necessaryto implementIMEP in our simulationmodelaslossof routingpacketsis unlikely in theabsence

of any link layermodelwhenthelink is up.

Buffering datapackets while a route discovery is in progresshasa greatpotentialto improve DSR,

AODV andTORA performances.However, this alternative hasnot beenevaluatedup to this point. We

alsohave not usedearlyquenchingof routerequestpacketsby a non-destinationnodein AODV. We have

noticedthat AODV performsvery poorly by picking up staleroutes,if earlyquenchingis used. It affects

bothits packet delivery anddelayperformancesignificantly. DSR,on theotherhand,doesnot demonstrate

any significantperformancedifferentialwith or without theuseof earlyquenching.

AODV hasaslightly worsepacketdeliveryperformancethanDSRbecauseof higherdroprates.AODV

usesroute expiry, droppingsomepackets when a route expires and a new route must be found. This,

however, givesbetterquality routesto AODV in general.

The averageend-to-enddelaysareshown in Figure2.2, for both network sizesandfor low andhigh

mobilities. Theshortestpathprotocols(SPF, EXBF andDSDV) show theminimumdelaycharacteristics.

AODV andDSRshow worsecharacteristicsastheir routesaretypically not theshortest.Evenif theinitial

routediscovery phasefindstheshortestroute(it typically will), theroutemaynot remaintheshortestover


a periodof time dueto nodemobility. Also, notethat in AODV routesaremaintainedasa soft state,i.e.,

routesexpire aftera timeoutinterval anda freshroutediscovery is initiated. Accordingly, AODV performs

a little betterdelay-wiseandcanpossiblydo even betterwith somefine-tuningof this timeoutperiodby

makingit, for example,a functionof nodemobility. TORA hastheworstdelaycharacteristicsbecauseof

thelossof distanceinformationwith progress.

The routing loadcharacteristicsshown in Figure2.3 areinteresting.Note that the routing loadvaries

over a very wide rangeand hencethe plots usea logarithmic scalefor the vertical axis. SPFexpends

significantlymorerouting loadthantheotherprotocols.Thedistancevectorprotocols,EXBF andDSDV,

have verysimilar routingloads,andmuchlower thanSPF. DSRandAODV performverywell, particularly

for smallernumberof conversations,with DSR often outperformingAODV. The excellent routing load

performanceof DSRis dueto theoptimizationspossibleby virtue of sourcerouting.TORA’s performance

is notverycompetitive with thedistancevectorandon-demandprotocols.Weconjecturethatit is dueto the

factnetwork partitionscauseTORA to dosubstantialwork to eraseroutesevenwhenthoseroutesarenot in

use.

It appearsthat the theoretical“worst” casecommunicationcomplexity (numberof messagesrequired

to adaptto a link failure/recovery) doesnot provide muchinsight into theaveragecasebehavior obtained

via simulation. For example,SPFhasa worst casecommunicationcomplexity of / � !#01 [42], where 0 is

the numberof links in the network. On the otherhandcommunicationcomplexity in protocolsbasedon

distributedBellman-Ford,suchasEXBFandDSDV, is exponentialin thenumberof nodes� in thenetwork

[11], whichshouldbemuchhigher. However, SPFhasamuchhigherroutingloadin thesimulations.

Most protocolsbenefitto somedegreeasthe numberof conversationsgrow large. This is becausea

singlerouterepaircanpotentiallybenefitmany conversations.Thusrouting loaddo not increaseasmuch

asthedataloadwith increasingnumberof conversations.Thiseffect is themostpronouncedfor proactive,

shortest-pathprotocolswhererouting load is independentof thedataload. Also notethat theroutingload

differentialsbetweenthe protocolsbecomesmallerasthe numberof conversationsgrow large. Thusthe

proactive, distancevectorprotocolsmaybefavoredat largenumberof conversationsasthey provide better

packet delivery fractionsand end-to-enddelay characteristics.We also note in passing,that DSR uses


0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

2

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(a)Packet delivery fraction(30 hosts),low mobility case

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

2

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(b) Packet delivery fraction(30hosts),highmobility case

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

2

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(c) Packet delivery fraction(60 hosts),low mobility case

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

2

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(d) Packet delivery fraction(60hosts),highmobility case

Figure2.1: Fractionof packetsdeliveredin a 30and60mobilehostnetworksfor all routingprotocols.


0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

3

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(a)Averagedelay(30 hosts),low mobility case

0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

3

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(b) Averagedelay(30hosts),highmobility case

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

3

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(c) Averagedelay(60 hosts),low mobility case

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

3

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(d) Averagedelay(60hosts),highmobility case

Figure2.2: Averageend-to-enddelayin a30and60mobilehostnetworksfor all routingprotocols.


0.01

0.020.030.050.070.1

0.20.30.50.7

1

2357

10

20

40

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Load

(no

rmal

ized

)

4

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(a)Normalizedroutingload(30 hosts),low mobility case

0.01

0.020.030.050.070.1

0.20.30.50.7

1

2357

10

20

40

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Load

(no

rmal

ized

)

4

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(b) Normalizedroutingload(30hosts),highmobility case

0.010.020.030.050.070.10.20.30.50.7

12357

1020305070

100200

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Load

(no

rmal

ized

)

4

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(c) Normalizedroutingload(60 hosts),low mobility case

0.010.020.030.050.070.10.20.30.50.7

12357

1020305070

100200

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Load

(no

rmal

ized

)

4

#conversations/node

SPFEXBFDSDVTORA

DSRAODV

(d) Normalizedroutingload(60hosts),highmobility case

Figure2.3: Normalizedroutingloadin a30and60mobilehostnetworksfor all routingprotocols.


somewhatmorebandwidth(10–20%in our experiments)becauseof sourcerouting that increasesthesize

of theheaderin datapackets. Evencountingthis in asa partof theroutingload,DSRis very competitive

with AODV. However, thisbandwidthusageis expectedto increasefor largernetworksandmaymakeDSR

lessattractive.

2.3 RelatedWork

Somesimulationstudiesof theroutingprotocolsevaluatedherehave beenpresentedearlierin literature.In

[52] ParkandCorsoncomparedTORA with anideallink-stateroutingprotocolanddemonstratedsuperior

performanceof TORA. In theirchosennetwork model,however, thereis notruenodemobility. Thenetwork

is connectedin a “honeycomb” patternandlinks go up anddown at someratewith the averagenetwork

connectivity heldconstantartificially. In anearlierwork [13], CorsonandEphremidespresentedsimulation

resultsof threeprotocolson which TORA is basedin part. Hereagainstationarynetworksarechosenwith

links goingupanddown at randomintervals.

JohnsonandMaltz presentedthesimulationstudyof DSRin [38]. They simulateda true,mobilenet-

work. Their resultsindicatethatDSRis ableto find closeto optimalroutesonanaverage.However, actual

pathlengthsin hops(andnot theend-to-enddelay)wasmeasuredto determineoptimality. Freislebenand

JansenevaluatedDSRagainstDSDV in [26]. They built a morecomprehensive simulatorcompletewith a

MAC layermodelof theIEEE standard802.11[19] aswell astruemobility. Only packet delivery fraction

is evaluatedwith DSDV performingmarginally worsethanDSR.

Concurrentlywith ourwork, theMonarchresearchgroupin CMU did acomprehensivesimulationstudy

of four adhocroutingprotocols,viz., DSDV, TORA, DSRandAODV [6]. They useda fairly comprehen-

sive simulatorthatincludephysicallayerandradiointerfacemodelsandconsideredtheIEEE802.11MAC

protocol[19]. Froma qualitative point of view, muchof their observationsregardingthecomparative per-

formanceof thesefour protocolsaresimilar to ours. In the following year, a researchgroupfrom Sweden

usedthesamesimulatorbut with new mobility models[37]. A new mobility metricthatmeasuresmobility

in termsof relative speedsof thenodeswasintroduced.Theirexperimentswereconductedon threeadhoc

routingprotocols,viz., DSDV, AODV, andDSR.Their conclusionsdifferedslightly from theformerstudy


in that DSRperformedbetterfor low loadswhereasAODV performedbetterhigh loads. In the Monarch

study, DSRwasfoundto have betterperformancein contrastto theotherprotocols,includingAODV.

Thereis a largebodyof simulationstudyof shortest-pathprotocols.Mostcloselyrelatedto ourwork is

theperformancestudyin [61] by Shankaret. al.,which usedbothSPFandEXBF protocols,amongothers,

for a performancecomparisonusing the MaRSsimulator. They useda staticnetwork with dynamically

changinglink connectivity with links going up anddown accordingto a stochasticdistribution. Various

traffic andlink failuremodelswerestudiedto evaluatetransientandsteady-stateperformanceof therouting

protocols.Delayandthroughputperformanceof SPFandEXBF werefound to beequivalentin themost

part.


Our work is oneof thefirst attemptstowardsa comprehensive performanceevaluationof routingprotocols

for mobile ad hoc networks. The protocolsuite includesseveral protocolscurrentlybeingconsideredin

theMANET working groupwithin IETF for standardization.In addition,moreestablishedlink-stateand

distance-vector protocolshave beenincludedin the suite to provide a referencepoint. Steadystateper-

formancein termsor fraction of packets delivered,delay, androuting load have beenconsideredas the

performancemetrics.

Even with a packet-level simulationmodelthe essentialaspectsof the routing protocolsareexposed.

Thekey observationsareasfollows. Theproactive, shortestpathprotocolsprovide excellentperformance

in termsof end-to-enddelaysandpacket delivery fraction,however, at thecostof higherroutingload. The

on-demandprotocolssuffer from sub-optimalroutesaswell asworsepacket delivery fraction becauseof

moredroppeddatapackets. However, they aresignificantlymoreefficient in termsof the routing load.

Themultipathprotocol,TORA, did notperformwell in spiteof maintainingmultiple redundantpaths.The

overheadof finding andmaintainingmultiple pathsseemsto outweighthe benefits.Also, the end-to-end

delayperformanceispoorbecauseof thelossof distanceinformation.Theroutingloaddifferentialsbetween

all routingprotocolsreducewith largenumberof peer-to-peerconversationsin thenetwork. However, the

otherperformancedifferentialsarenotaffectedconclusively. Rateof mobility andnetwork sizedonotseem


to affect theperformancebeyondwhatis normallyexpected– suchashigherroutingload,moredelayand

droppedpackets.

It is importantto notethelimitationsof thestudy. First,apacket-level simulationhasits own limitations.

No MAC protocolor multiple accessinterferenceis modeled.Thus,a high routing packet load doesnot

interfereasmuch with the datatransmissions(except for queueingdelays)as it would in reality. Also,

thereareno transmissionerrors.Thecurrentstudybestreflectstheperformancewhenall active links in the

network areonaseparatefrequency band.Second,only amoderatesizenetwork hasbeenstudied.Though

it is unclearwhatsizeswill berealisticfor anadhocnetwork runningIP basedprotocols,usinga few other

sizes,going up to a few hundreds,will provide morematurity to the study. Third, a few different traffic

models,for example,dynamicallychangingpeersfor conversationsandintroductionof hot-spotsshould

be studiedto evaluatethe sensitivity to traffic models. Fourth,fine tuning of certainprotocolparameters

(e.g.,varioustimeoutperiodsfor theon-demandprotocols)is possiblewith changingmobility andtraffic

characteristics.Wehaveusedreasonablevaluesthatwork well, but havenotchangedthevaluesfor different

traffic andmobility. Also, certainprotocolspecificoptimizations(e.g.,passive eavesdroppingin DSR)as

well asmoregeneraloptimizations(e.g.,buffering of datapacketson routelossuntil routeis repaired)are

possible.They mayimpactrelativeperformance.Fifth, impactof memoryusageby theprotocolshavebeen

ignored. This may be importantas the computingnodesdeployed in a mobile, ad hoc environmentcan

below power andsmallsizedevices. In spiteof theselimitations,we have gainedvaluableinsightinto the

behavior of routingalgorithmsin anadhocnetwork. Someof ourfuturework will addresstheselimitations.

2.5 Acknowledgement

JiangtaoYan implementedthe DSDV andAODV protocols,andhelpedsignificantly in the performance

evaluationby runningmany simulations.

Chapter 3

Query Localization Techniques

The motivation behindthe designof on-demandrouting protocols,suchas DSR and AODV, is that the

“routing overhead”(typically measuredin termsof thenumberof routingpacketstransmitted,asopposed

to datapackets) is typically lower than the shortestpath protocolsas only the actively usedroutesare

maintained.However, asit wasdemonstratedin thesimulationstudiespresentedin thepreviouschapter, the

routingoverheadstill approachesto thatof theshortestpathprotocolsif amoderateto largenumberof routes

needsto beactively maintained(when,for example,thereis a moderateto largenumberof active peer-to-

peerconversations). This is becausethe on-demandprotocolsdiscover routesvia a flooding technique,

wherethesource(or any nodeseekingtheroute)floodstheentirenetwork with a querypacket in searchof

a routeto thedestination.

Floodingis straightforwardto implement.Wehavedescribedhow it is typically implementedin Section

1.1.4of Chapter1. However, asmentionedbefore,network-wideflooding incursa considerableoverhead

anddiminishestheperformanceadvantageof on-demandprotocols.Althoughseveraloptimizationsto the

basicfloodingmechanismhave beenproposedpreviously (e.g.,useof a time-to-liveor TTL field to limit

thequerywithin aspecificnumberof hopsfrom thesource[5, 6]), thefloodingschemecanstill deliver the

queryto a very large numberof nodesin the network, leadingto a high routing overhead.The problem

canbeseverewhenthemobility is high (very frequentroutediscoveries)and/orthenetwork is large(many

routingmessagesgeneratedin regionsfarawayfrom thesourceandthedestination).Ourgoalsin thiswork

is to investigatenew approachesto reducethe routingoverheadby localizing thequeryflood to a limited

region in thenetwork. Similar ideaswereexploredbefore.Themostprominentamongthemis thelocation-

26

CHAPTER3. QUERY LOCALIZATION TECHNIQUES 27

S

D

A

(a)Beforeroutechange

S

D

A

1

1

1

0

1 2

1

2

1

2

1

2

2

0

(b) After routechange

Figure3.1: Illustrationof thepathlocality principlewith k=1.

aidedrouting or LAR technique[44] which usesthe Global PositioningSystem(GPS)[51], to limit the

queryfloodto arestrictedregion. However, ourapproachmakesintelligentuseof routinghistoriesanddoes

notneedlocationinformation.On theotherhand,it deliverscomparableperformanceadvantage.

3.1 Query Localization Protocols

Theproposedquerylocalizationprotocolsarebasedonthenotionof spatiallocality: “a mobilenodecannot

movetoofar toosoon.” Thus,prior routinghistoriescanbecachedto estimateasmallregion in thenetwork

with highprobabilityof finding thedestinationnode.Only this region needsto beflooded.In theapproach

we studied,prior routehistoriesareusedto limit the queryto a region in the neighborhoodof the prior

routes.Hop-wisedistanceis usedto definetheneighborhood.Following theterminologyusedin literature

[44], wereferto thisregionastherequestzone. Similarideashavebeenusedin theselectivepagingschemes

in cellularnetworks[2], wherea mobileis pagedonly in theneighboringcellsof thelastcell it reportedto

have visited.

In the discussionthat follows, assumethat sourcerouting is used,i.e., the querypacket includesthe

path � (asa sequenceof nodes)it hastraversedsofar (asin DSR).This assumptionmakesthediscussion


straightforward. Alternative approaches,wheresourcerouting is not used,will be explored later. Two

heuristicsto exploit locality areconsidered.

� Exploitingpath locality: This approachrelieson theassumptionthataftera routeto thedestination

nodebreaks,thenew routecannotbevery differentthanthemostrecentlyusedroute. Theprotocol

maintainsa setof nodes�6587&9 , which includesall nodeson the last valid routebetweenthe specific

source-destinationpair.

During routediscovery, thequeryflood is propagatedby only suchnodesfor which theaccumulated

path � in thequerypacket hasat most � nodesnot in �:587&9 . To accomplishthis, theset �6587&9 is sentin

theheaderof thequerypacket, in additionto P. A counteris alsosentasa partof thequery, which is

initialized to zero.Thecounteris incrementedeachtimea nodenot in theset �6587&9 is encounteredby

thequery. Thequeryis no longerpropagatedif thecounterexceedsthethresholdvalue � . (As will be

discussedlater, theprotocolcanalsobeimplementedwithout including �6587&9 in thequery.)

Figure3.1illustratestheabove protocolwith anexamplenetwork. NodesS andD arethesourceand

destinations,respectively. NodeA hasmovedcausinga routechange.The“dark” nodeswereon the

old route. All “filled” (darkor lightly shaded)nodesarefloodedwith queryusingthepathlocality

heuristicswith k=1. The valueof the counteris shown at eachnodevisited by the queryafter the

routechange.Thequeryis not propagatedif thecounterreaches2. Notethatwith thenaive flooding

protocol,all nodesin thegraphwill beflooded.This is trueeven if floodingis controlledby a TTL

field wherethe queryis only propagatedup to 4 hops(the numberof hopsbetweenthe sourceand

destinationis 4 in this example).Discountingthenodeson theroute,querylocalizationsavesabout

half of thenodesin thenetwork from beingfloodedin thisexample.

� Exploitingnodelocality: Theassumptionhereis thatthedestinationnodecanbefoundwithin asmall

numberof hopsfrom somenodeonthemostrecentlyusedroute.As before,thesetof nodes�6587&9 and

a counter(initialized to zero)aresentasa part of the query. The counteris resetto zerowhenever

thequeryreachesa nodein theset �6587&9 , otherwiseit is incrementedby one. As before,thequeryis

droppedwhenthecounterexceedsthethresholdvalue � .


The requestzonesdefinedby the above two heuristicsaredifferent, in general.For a given valueof

� , the requestzonedefinedby the nodelocality heuristicswill subsumethat definedby the pathlocality

heuristics.

3.1.1 Dynamic NeighborhoodEvaluation

Theparameter� is usedto limit thedistribution of routequeries.For minimizing theroutingoverhead,an

appropriatevalueof � mustbeused.The optimalvalueof � is dependenton the mobility pattern,which

maybetime-varying.Toosmallavalueof � mayresultin thefailureof routediscovery (and,thus,dropping

a large numberof datapackets),while too large a valuewill increaserouting overheadby enlarging the

requestzone. Incremental,dynamictechniquescanbe usedto determinethe right valueof � . Onesuch

techniqueis describedbelow.

Initially, �; =< . If thedestinationcannotbelocatedwithin areasonabletimeoutperiod,� is incremented

by 1, andanotherqueryis initiated. This incrementalapproachleadsto theright valueof � (say, > ). Next

timearound,afteranotherroutefailure,insteadof startingfrom �; =< , theprotocolstartsfrom �? @>A�B< ,

for example.A relatedtechniquecanuseall nodeson thelast few routesin theset �6587&9 , insteadof only the

mostrecentroute.Anothervariationcanbeto useall routesusedin thelast C timeunits.

3.1.2 Distributed Maintenanceof Locality Inf ormation

In theabove protocols,we have includedtheset �65D7E9 in thequerymessages.It is alsopossibleto maintain

�65D7E9 in adistributedfashion,eliminatingtheneedto includeit in everyquery. Here,eachnodein thenetwork

maintainsa flag, F �HG, indicatingwhetherit hasbeenon a routebetweena givenpair of nodes

� � (I�� in the

recentpast(say, in thepastC timeunits). It is alwayspossibleto maintainthisflag F �HGbecausethenodesen

routeseetheroutereplypacket passingthroughthem,andtheothernodesdonot. 1

Thus,a nodeconsidersitself to bein theset �:587&9 , for thesource-destinationpair� � (I�� , only if this flag

is set. Thequerypacket now carriesonly thecounter(initialized to zero). Thecounteris incrementedby

one,whenever a nodewith F �HG Falseis visited. Otherwise,the counteris not modified. The queryis

1A little ingenuityis neededfor asymmetricnetworks,wherethe reply maycomevia a differentpath. In suchcases,thefirstdatapacket goingthrougha recentlyestablishedroutewill settheflags.


droppedwhenthecounterexceedsthevalue � . This is similar to thepathlocality-basedprotocolconsidered

earlier. A simplevariationimplementsthenodelocality-basedheuristics.Here,thecounteris incremented

asbefore,whena nodewith F �JG Falseis visited,but is resetto zero,whena nodewith F �JG True is

visited.

This distributedimplementationof �:587E9 hastheadvantageof reducingthesizeof thequerymessages,

thussaving network bandwidth.Anotheradvantageof this mechanismis that it canalsobeusedwith pro-

tocolsthatdonotusesourcerouting,suchasAODV [57]. Onedisadvantageof thedistributedmaintenance

is thatit maybehardto supportalternative definitionsof set �6587&9 . For example,theset �:587&9 maybedefined

astheunionof all routesfoundin thelast K routediscoveries,insteadof beingbasedsolelyona timer. This

will beeasyto supportin theoriginalprotocol,but not in thedistributedvariation.

3.2 PerformanceEvaluation

We ran the experimentsunderthe sameenvironmentas in Chapter2 except now our mobility speedis

uniformly distributed betweenthe rangesof 3.5 – 4.5 m/sec(low mobility) and14.0 – 18.0m/sec(high

mobility) andthedirectionis uniformly distributedwithin �H*ML�% ' (N�OL�% ' - with respectto thedirectionof the

previousmove. Simulationsarerunfor 300simulatedsecondsandthefinal resultspresentedaretheaverage

over 5 runswith differentrandomnumberstreams.Threeimportantperformancemetricsareevaluated:

� Routingoverhead:measuredin termsof the total numberof routingpacketstransmitted(broadcast

transmissionsarecountedasasingletransmission).

� Packet deliveryfraction: measuredastheratioof thenumberof datapacketsdeliveredto thedestina-

tion andthenumberof datapacketssentby thesource.

� End-to-enddelay: measuredastheaverageend-to-endlatency of datapackets. This measurementis

givenin ms(milliseconds).


In thecaseof a routeloss,datapacketsarenotbuffered.Thus,longerroutediscovery latency will typically

translateto lower packet delivery fraction. Buffering of datapackets,on theotherhand,will causelonger

delays.

3.2.1 Simulation Results

In the first setof experimentaldata(Figure3.2), querylocalizationprotocolsfor bothheuristics(referred

henceforthasprotocol1 and2, respectively) areevaluatedwith variousvaluesof the thresholdparameter

� , chosenstatically. Comparisonis madeagainsttheDSRprotocolusingnetwork-wideflooding(labeled

asDSR-NW).All protocolsareidenticalexcepthow the queryflooding is implemented.The plots show

the numberof routing packets transmittedthroughoutthe simulationrun for different valuesof � , with

increasingnumberof conversations.As expected,the larger the valueof � , the greateris the numberof

routingpackets.Also, thesecondprotocolsendsmoreroutingpacketsfor thesamevalueof � asit defines

a larger requestzone.Increasingmobility andthenumberof conversationsalsogeneratesa largernumber

of routingpackets.

Figure3.3shows datapacket delivery fractionfor bothprotocols.As expected,lower valuesof � gives

poorerpacket delivery performance,especiallyfor highermobility. Notethatlargerroutediscovery latency

translatesto higherpacket lossin oursimulation,asdatapacketsarenotbuffered.

Figure3.4showstheaverageend-to-enddelay. An interestingobservationhereis thevery largeaverage

delayin theDSR-NWprotocolfor thehighmobility case.This is dueto largequeueingdelaysin thenodes

owing to thepresenceof a largenumberof routingpackets. As expected,lower valuesof � givesa lower

delay. Basedupontheseprevious results,protocol1 waschosenasthe protocolwith the mostpotential.

Henceforth,all experimentsconductedarebaseduponprotocol1.

Figure3.5 shows theperformancefor dynamicchoiceof � for both routingoverheadanddatapacket

delivery. Herewe have a conservative implementation,with � startingfrom 1 incrementallyfor eachroute

discovery. For the sake of comparison,we alsopresentthe performanceof the DSR protocol that uses

querycontainmentasdescribedin Subsection1.1.4of Chapter1. This is labeledasDSR-QC.Note that

the querylocalizationprotocolis ableto reducethe routing overheadsignificantly. The savings areoften


in theneighborhoodof 50%comparedto DSR-NWandat least20%comparedto DSR-QC.Consequently,

thedelayis minimizedsignificantlywhendataloadandmobility is high(Figure3.6)with almostnegligible

impactonpacket loss.Theaveragevalueof � with this dynamicmechanismwasfoundto bebetween2.1–

2.4,with valuestendingto behigherfor highermobility. Smallaveragevaluesof � reinforcesthe“spatial

locality” assumptionbehindthequerylocalizationidea.

Oneproblemwith thechosenmobility modelis thattheaveragenumberof hopsis small(between3–4

for low mobility and4–5 for high mobility). Increasingthe field sizedoesincreasethe averagenumber

of hops,but it alsoincreasestheprobabilityof thenetwork beingpartitioned.Network partition is a dark

cloudloomingover successfuldesignof adhocnetworkswith unconstrainedmobility. Most performance

evaluationstudiessofar choosesmobility modelssuchthat theprobabilityof network partitionis minimal

[6]. In orderto increasetheaveragehopcountwithout any significantchanceof network partition,we ran

a completesetof simulationswith a differentchoiceof “field” while keepingthemobility modelidentical.

Now thefield is asquareareawith a holeinsideasshown in Figure3.7. Theperformancedatais presented

in Figures3.8 and3.9. Averagehopcountsbetweensourceanddestinationarenow larger, between6–9.

Notethatevenwith muchlargerhopcountsthequerylocalizationtechniqueperformsverywell.

We alsoranthesamemodelswith thenumberof conversations/node fixed(1 and9 conservations/node

wereused),while the averagemobility variedover a predefinedrange. The averagespeedof the nodes

werevariedfrom 4 m/secup to 28 m/sec.Figures3.10and3.11shows theresultsfor 1 conversation/node

with varyingmobility, andFigures3.12and3.13shows the resultsfor 9 conversations/node with varying

mobility. In all plots,thequerylocalizationprotocolstill maintainsagreatreductionof routingpacketsover

DSR-NWandDSR-QCasthemobility speedis varied.Also, datapacket delivery fractionis not impaired

with theuseof our localizationtechnique.Also, for ahighernumberof conversations/node (9), theaverage

delay is reducedsignificantly. This is dueto the reductionin network congestionandresultingqueuing

delays(seeFigures3.13(a) and(b)). As expected,theperformanceimpactalwaystendsto begreaterfor

highermobility.


020000400006000080000

100000120000140000160000180000200000220000240000260000280000300000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWk = 1k = 3k = 5k = 7

(a)Low mobility, Protocol1

020000400006000080000

100000120000140000160000180000200000220000240000260000280000300000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWk = 1k = 3k = 5

(b) Low mobility, Protocol2

050000

100000150000200000250000300000350000400000450000500000550000600000650000700000750000800000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWk = 1k = 3k = 5k = 7

(c) High mobility, Protocol1

050000

100000150000200000250000300000350000400000450000500000550000600000650000700000750000800000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWk = 1k = 3k = 5

(d) High mobility, Protocol2

Figure3.2: Routingoverheadfor bothprotocolsfor differentvaluesof k.


0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWk = 1k = 3k = 5k = 7


0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWk = 1k = 3k = 5


0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWk = 1k = 3k = 5k = 7


0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWk = 1k = 3k = 5


Figure3.3: Datapacket delivery fractionfor low andhighmobilitiesfor differentvaluesof k.


0

2

4

6

8

10

12

14

16

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWk = 1k = 3k = 5k = 7


0

2

4

6

8

10

12

14

16

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWk = 1k = 3k = 5


0

5

10

15

20

25

30

35

40

45

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWk = 1k = 3k = 5k = 7


0

5

10

15

20

25

30

35

40

45

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWk = 1k = 3k = 5


Figure3.4: Averagedelayfor low andhighmobilitiesfor differentvaluesof k.


020000400006000080000

100000120000140000160000180000200000220000240000260000280000300000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWDSR-QC

protocol-1

(a)Routingoverhead,low mobility case

050000

100000150000200000250000300000350000400000450000500000550000600000650000700000750000800000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWDSR-QC

protocol-1

(b) Routingoverhead,highmobility case

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWDSR-QC

protocol-1

(c) Packet delivery fraction,low mobility case

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWDSR-QC

protocol-1

(d) Packet delivery fraction,highmobility case

Figure3.5: Routingoverheadanddatapacket delivery metricsfor low andhigh mobilities for dynamicchoiceof k.


0

2

4

6

8

10

12

14

16

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWDSR-QC

protocol-1

(a)Averagedelay, low mobility case

0

5

10

15

20

25

30

35

40

45

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWDSR-QC

protocol-1

(b) Averagedelay, highmobility case

Figure3.6: Averagedelaymetricfor low andhighmobilitiesfor dynamicchoiceof k.

1000 m

800 m

Figure3.7: Square-with-a-holeregion

3.3 RelatedWork

It is notanew observationthatnetwork-widefloodingof querymessagesmaybeaperformanceproblemin a

bandwidth-pooradhoc,wirelessnetwork. A sophisticatedtechniquecalledLocation-AidedRouting(LAR)

[44] hasbeenproposedrecentlywhich usestheGlobalPositioningSystem(GPS)to localizequeriesto a

limited geographicregion(requestzone). Therequestzoneis definedbasedonthepastlocationinformation

of thedestinationnodeandits speed.As in ourquerylocalizationapproach,LAR canbeusedwith any on-

demandprotocol. Simulationstudieshave shown excellentimprovementof routingoverheadwith respect


020000400006000080000

100000120000140000160000180000200000220000240000260000280000300000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWDSR-QC

protocol-1

(a)Routingoverhead,low mobility case

050000

100000150000200000250000300000350000400000450000500000550000600000650000700000750000800000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node

DSR-NWDSR-QC

protocol-1

(b) Routingoverhead,highmobility case

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWDSR-QC

protocol-1

(c) Packet delivery fraction,low mobility case

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Del

iver

ed

P

#conversations/node

DSR-NWDSR-QC

protocol-1

(d) Packet delivery fraction,highmobility case

Figure3.8: Routingoverheadanddatapacket delivery metricsfor low andhigh mobilities for dynamicchoiceof k within thesquare-with-a-holeregion.


0

5

10

15

20

25

30

35

40

45

50

55

60

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWDSR-QC

protocol-1

(a)Averagedelay, low mobility case

0

25

50

75

100

125

150

175

200

225

250

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node

DSR-NWDSR-QC

protocol-1

(b) Averagedelay, highmobility case

Figure3.9: Averagedelaymetric for low andhigh mobilities for dynamicchoiceof k within the square-with-a-holeregion.

to network-wideflooding. Our approachis similar in principleto LAR andachievessimilar improvements

with similarmobility models,but it doesnot requirelocationor speedinformation.Thismakesit attractive

in many situationswhereGPScannotbeusedbecauseof concernsof (i) cost(GPSmaybemoreexpensive

thansomelow-costwirelessnodes),(ii) accuracy (GPSaccuracy maynotbesufficient for somein-building

networkswith small radio range,suchastheBluetooth[23]) or (iii) usability (GPScannotbeusedinside

many buildings).

It is alsoworthnotingherethatour “location-unaware” locality-basedmechanism,mayin fact,perform

betterthanthelocation-aidedmechanismsin situationswherenodemovementsarerelatively fast,but highly

correlated.Examplesincludethemovementof anassaulttroopor arescueteam.In suchsituations,locality

basedonphysicallocationis lessrelevantthanlocality basedonneighborhoodwith othernodes.

A ZoneRoutingProtocol(ZRP) [32] hasbeenproposedwhich respondsto the routing overheadvs.

routediscovery latency tradeoff questionin anindirectfashion.It advocatesonly limited useof on-demand

protocols. In ZRPthe network is split into zonesor clustersof suitablesize. Proactiveshortestpathpro-

tocolsareusedwithin a zoneandreactiveon-demandprotocolsareusedacrosszones.Thoughno explicit

querycontrolschemewasdeveloped,thezoningschemeautomaticallyreducesthefloodingoverhead.Sim-


0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

220000

0 4 8 12 16 20 24 28 32

Rou

ting

Pac

kets

Average Mobility (m / sec)

DSR-NWDSR-QC

protocol-1

(a)Routingoverhead,squareregion

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

220000

0 4 8 12 16 20 24 28 32

Rou

ting

Pac

kets


DSR-NWDSR-QC

protocol-1

(b) Routingoverhead,square-with-a-holeregion

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 4 8 12 16 20 24 28 32

Fra

ctio

n of

Pac

kets

Del

iver

ed

P


DSR-NWDSR-QC

protocol-1

(c) Packet delivery fraction,squareregion

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 4 8 12 16 20 24 28 32

Fra

ctio

n of

Pac

kets

Del

iver

ed

P


DSR-NWDSR-QC

protocol-1

(d) Packet delivery fraction,square-with-a-holeregion

Figure3.10: Routingoverheadanddatapacket delivery metricsfor 1 conversation/nodewith varyingmo-bilities.


0

2

4

6

8

10

12

14

16

18

20

22

24

0 4 8 12 16 20 24 28 32

Del

ay (

ms)

Q


DSR-NWDSR-QC

protocol-1

(a)Averagedelay, squareregion

0

2

4

6

8

10

12

14

16

18

20

22

24

0 4 8 12 16 20 24 28 32

Del

ay (

ms)

Q


DSR-NWDSR-QC

protocol-1

(b) Averagedelay, square-with-a-holeregion

Figure3.11:Averagedelaymetricfor 1 conversation/nodewith varyingmobilities.

ilarly, in the recentlyproposedCEADR protocol[65], only theso-called“core” nodesparticipatein route

computation,thuslimiting thefloodingoverhead.

The flood control problemis not uniqueto ad hoc networks. Other network routing protocolsalso

facethis problem. For example,in [8] the constructionof multicasttreesacrossdifferentdomainsin a

wide-areawirednetwork is considered.Here,theprotocoldoesconsecutive floodingto searchincreasingly

largerregionsuntil reachingthemulticasttree.This techniqueis calledtheexpandingrings. Thisapproach

canalsobe usedin ad hoc networks, by first settingTTL = 1, thento 2, andso on, until the destination

is reached.This approachstill propagatesthe query in directionsaway from the destination.Also, this

incrementalapproachmaybetooslow if thedestinationis farawayand,asFigure3.1demonstrates,canbe

no betterthannetwork-wideflooding. To thebestof our knowledge,this techniquehasnot beencarefully

evaluatedagainstnetwork-wide flooding in ad hoc networks, thougha recentversionof AODV protocol

includesthis technique[58]. In a recentwork the RDMAR protocol[1] automaticallyestimatesthe hop-

wisedistancebetweenthesourceanddestinationpair. This estimateis basedon thephysicaldistancethe

nodesmayhavetraveledaftertheprior routediscovery, nodevelocityandtransmissionrangeestimates.The

TTL field is setequalto theabove estimate.


0

100000

200000

300000

400000

500000

600000

700000

800000

900000

1e+06

0 4 8 12 16 20 24 28 32

Rou

ting

Pac

kets


DSR-NWDSR-QC

protocol-1

(a)Routingoverhead,squareregion

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

1e+06

0 4 8 12 16 20 24 28 32

Rou

ting

Pac

kets


DSR-NWDSR-QC

protocol-1

(b) Routingoverhead,square-with-a-holeregion

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 4 8 12 16 20 24 28 32

Fra

ctio

n of

Pac

kets

Del

iver

ed

P


DSR-NWDSR-QC

protocol-1

(c) Packet delivery fraction,squareregion

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 4 8 12 16 20 24 28 32

Fra

ctio

n of

Pac

kets

Del

iver

ed

P


DSR-NWDSR-QC

protocol-1

(d) Packet delivery fraction,square-with-a-holeregion

Figure3.12: Routingoverheadanddatapacket delivery metricsfor 9 conversation/nodewith varyingmo-bilities.


0

5

10

15

20

25

30

35

40

45

50

55

60

0 4 8 12 16 20 24 28 32

Del

ay (

ms)

Q


DSR-NWDSR-QC

protocol-1

(a)Averagedelay, squareregion

0

50

100

150

200

250

300

0 4 8 12 16 20 24 28 32

Del

ay (

ms)

Q


DSR-NWDSR-QC

protocol-1

(b) Averagedelay, square-with-a-holeregion

Figure3.13:Averagedelaymetricfor 9 conversation/nodewith varyingmobilities.

In [10] theproblemof distributedQoS(Qualityof Service)routingin dynamicnetworksis considered.

The goal is to find routesthat have sufficient resourcesto meetthe QoSrequirementof every admitted

connection.To reducetheoverheadof a globalsearchusingflooding,a ticket-basedprobing techniqueis

introduced.Herethequery(calledprobein thepaper)floodis controlledby introducingthenotionof tickets.

Thesourceissuesa numberof ticketsthatarecarriedby the initial query. Theticketsmustgetdistributed

eachtime thequeryis propagatedby a node.A querymustcarryat leastoneticket. Thus,thenumberof

routingmessagesat any time in the network is boundedby the numberof tickets issued.This technique,

however, doesnot limit thenumberof transmissionsof querymessages.


On-demandrouting protocolsareattractive for mobile, ad hoc networks. However, their effectivenessis

limited by the needof flooding to discover new routes. We presenta querylocalizationtechniquewhere

thequeryfloodingis limited within a smallregion in thenetwork. This region is determinedbasedonprior

routinghistoriesof theconcernedsource-destinationpair. Any on-demandroutingprotocolthatdependson

floodingcanusethis technique.We have evaluatedquerylocalizationusingtheDynamicSourceRouting


(DSR)protocolasa testcase.Performanceevaluationusinga packet-level routingsimulatordemonstrates

excellentreductionof routingoverheads.Thesavingsareoftenaround50%comparedto thenetwork-wide

floodingandalmostalwaysmorethan20%comparedto a simplequerycontainmenttechnique.This also

indirectly contributesto lower end-to-enddelaysfor datapacketsbecauseof reducednetwork congestion.

The reductionin delaywasfound to be closeto an orderof magnitudefor high mobility scenarios.Our

performanceestimatespresentedhereare fairly conservative asour simulationplatform doesnot model

multiple-accessprotocolsonthewirelessmedia.Weanticipategreaterlevelsof performancebenefitsin real

systems,asreductionof routingoverheadswill alsotranslateto moreefficientbandwidthutilizationandless

multiple-accessinterference.

Chapter 4

On-DemandMultipath Routing

As wasdemonstratedin Chapter3, theroutingoverheadcanbereducedby localizingthequeryflood to a

limited regionby makingintelligentuseof routinghistories.However, this techniqueis limited to reducing

the“extent” of theflood. In this chapterwe focuson anothertechniqueto reducetheroutingoverheadby

reducingthe“frequency” of theflood by discovering multiple possibleroutesfrom a singlefloodedquery

andusingthealternaterouteson routefailure.Our goalis to provide enoughredundancy at a low cost.We

proposetwo multipathtechniquesfor theon-demandroutingprotocolDSRthatusemultiple disjoint paths

andshow how intelligentuseof thesetechniquescanreducethe frequency of queryfloods. Thegoal is to

provideenoughredundancy ata low cost.

Theideaof multipathroutingisnotnew. It alwayshasbeenafavorablealternatebothfor circuit switched

andpacketswitchednetworks,asit providesaneasymechanismto distributetraffic andbalancethenetwork

load,aswell asprovide fault tolerance.Seefor example,[69] for someprior work on multipathroutingon

packetswitchednetworks.Theadhocnetwork communityhasalsoinvestigatedmultipathtechniques,albeit

lessvigorously. See[54, 5, 38] for someexamples.However, performancebenefitsof multipathshasnever

beentruly evaluatedonmobileadhocnetworks.

4.1 Multipath Dynamic SourceRouting

We first considerthe situationwherethe destinationrepliesto a selectedsetof queries. Note that many

copiesof thefloodedquerymessagearrive at thedestinationvia differentroutes.Considerthatthequeries

45

CHAPTER4. ON-DEMAND MULTIPATH ROUTING 46

DS

AR1

M

DATA

(a)

DATA

DS

AR1

M

(d)

DATA

Data PacketsDropped

(c)

DS

AR1

MReroute Data Packets

Data PacketsDropped

(b)

DS

AR1

M

DATA

ERR-PKT

Figure4.1: Multipathprotocol1.

thatarerepliedto arethosethatcarryasourceroutethatis link-wisedisjoint from theprimarysourceroute.

Theprimarysourcerouteis theroutetakenby thefirst queryreachingthedestination.This usuallydefines

theshortestroutebetweenthesourceandthedestination.Thedestination“remembers”theprimaryroute,

in orderto figureout which laterrequeststo respondto. Only disjoint routesarechosen,asthentheroutes

areindependentanda link failure in oneroutedoesnot effect theothers.This alsoimplicitly controlsthe

total numberof replies,thuspreventinga reply flood occurrence.Thesourcekeepsall routesreceived on

reply packets in its routecache.Whentheprimary routebreaks,theshortestremainingalternaterouteis

used.This processcontinuesuntil all routesbreak,whereina freshroutediscovery is theninitiated. The

numberof alternateroutesusedcanbea selectableparameterof theprotocol.We will latershow thatonly

a few routesareactuallysufficient. Let uscall this techniqueprotocol1, for easeof laterreference.Figure

4.1depictstheoperationof protocol1 with onealternateroute(AR1).

ThesourceR usestheprimaryroute(shown with blacksolidlinesandblacksolidnodes)for transmitting

datapacketsto the destinationS until a link failure occursat somepoint, (saynode T moves). Whena


link is broken,nodeT will respondby generatinganerrorpacket andsendsit backto thesourceR . This is

shown in Figure4.1(b). Uponreceiving theerrorpacket, thesourceR will thenreroutefuturedatapackets

by utilizing its alternateroute UMVW< , by copying this routeinto thedatapacket headerasdepictedin Figure

4.1(c). Datapacketswill continueto usethisalternateroute UMVW< , Figure4.1(d), until anotherbreakoccurs

within this route. Thenanothererror packet will be generatedandsentbackto the sourceR whereupon,

having nomorealternateroutes,will begin a new routediscovery for a freshrouteto destinationS .

Protocol1 equipsonly thesourcewith alternateroutes.An intermediatelink failureontheprimaryroute

still sendsanerrorpacketbackto thesource,whichwill thenusethealternateroute.Thiscausesatemporary

lossof routefor thedatapacketsthatarealreadyin transitupstreamfrom the failed link. To prevent this,

a betteralternative is explored. All intermediatenodesarenow equippedwith a disjoint alternaterouteso

that in-transitdatapacketsno longerfaceany routeloss. To accomplishthis, the destinationnow replies

to eachintermediatenodein theprimaryroutewith analternatedisjoint routeto thedestination.Notethat

any suchreply is in responseto a queryfrom the sourcethat hastraveledthroughthat intermediatenode

(i.e. this intermediatenodeis on the primary routethat the sourceis using). The reply is targetedto the

intermediatenodeinsteadof thesource.Notethat it maynot alwaysbepossiblefor all intermediatenodes

to getanalternatedisjoint route. This would beparticularlytrue for sparsenetworks. Thus,this still may

resultin temporarylossof routeson link failuresuntil anupstreamnodeswitchesto analternateroute.

Figure4.2depictstheoperationof thistechnique(henceforthcalledprotocol2) usingonealternateroute

per nodeon the primary route. As in theprevious examplefor protocol1, the sourceR usesthe primary

routefor transmittingdatapacketsto thedestinationS until link failureoccursat somepoint,becausesay,

a node TX< moves. This time whenthe link brakes,node TY< will replacetheunusedportionof theroute

in thedatapacket headerby thealternateroute UMVZ! , shown in Figure4.2(b). Thus,unlike protocol1, data

packetswill thencontinuealongtheir new routetowardsthedestinationunbeknown to thesourcethatany

suchreroutinghasoccurredto thedatapacket (seeFigure4.2 (c)). This will continueuntil a link on UMVZ!breaks.Sayfor examplenode T=! movesasshown in Figure4.2 (d). It will causean error packet to be

transmittedbackward up to the sourceR , whereit will thenswitchall impendingdatapackets to its own

alternateroute UMVW< by modifying the sourceroute in the packet headerasbefore,(shown in Figure4.2


(e-f)). Finally, whena link breakagesoccursalong UMVW< thegeneratederrorpacket will besentbackto the

sourceR , wheretheactionsof protocol2 will now beforcedto doa new routediscovery.

Both examplesthat were just illustratedwerewith onealternateroute for any given nodealong the

primaryroute. If a nodehasmorethanonealternateroute,thena nodewill continueto useany available

alternaterouteuntil it hasexhaustedits supply. Thenanerrorpacket will besentup streamto its neighbor

wherethesameproceedingswill take placeat thatnode.

Thus,for protocol2, lossof all alternateroutesin a nodeto thedestinationgeneratesanerror packet

backto thesource.Any intermediatenodewith analternaterouteto thedestinationmayquenchtheerror

packet. Thisnodeis alsoresponsiblefor modifying thesourcerouteon all following datapacketsto useits

own alternateroute.Thisprocesscontinuesuntil thesourcegetsanerrorpacketandhasnoalternaterouteto

fall backon (implying thatall nodesalongtheprimaryroutehave no morevalid routesto thedestination).

Thena new routediscovery is initiated. Again, notethat in our simpleexamplewe maintainedonly one

alternaterouteper node. In principle, any numberof suchroutescanbe maintainedfor both protocols.

However, asour simulationresultswill show, morethanonealternaterouteprovidesonly a very minimal

additionaladvantagefor eitherprotocol.


We simulatedtheDSRprotocolwith singlepathaswell asmultipathroutingfor a mobile,adhocnetwork

of size60 mobilehosts.As in previouschapters,theevent-driven,packet-level routingsimulatorMaRSis

usedfor thesimulationstudy. We ran theexperimentswith thespeedof eachmove uniformly distributed

between14.0– 18.0m/sec(average16.0m/sec).Distanceis exponentiallydistributedwith a meanof 5 m,

andthedirectionis uniformly distributedwithin �H*,[)\ ' (N�"[)\ ' - with respectto thedirectionof theprevious

move. Nodesareagainassumedto have a radiorangeof 350m. Workloadsandregion areaarethesame

asdescribedin Subsection2.1.2of Chapter2. All simulationsarerun for 300simulatedsecondsandeach

point in aplot representsthefinal averageof 5 runswith differentrandomnumberstreams.


DS

AR1

AR3DATA

M1

AR2AR4

M2

(a)

DS

AR1

AR3

AR2AR4

M2

(b)

M1DATA

Reroute Data Packets

DS

AR1

AR3

AR2AR4

M2

(c)

M1DATA

Data PacketsDropped

DS

AR1

AR3

AR4

(d)

M1

M2

DATA AR2

ERR-PKT

DS

AR1

AR3

AR2AR4

(f)

M1

M2

DAT

A

Data PacketsDropped

DS

AR1

AR3

AR2AR4

(e)

M1

M2

DAT

A

Reroute Data Packets

Figure4.2: Multipathprotocol2.


Four importantperformancemetricsareevaluated:

� Fractionof packetsdropped:measuredastheratioof thenumberof datapacketsdroppedenrouteto

thenumberof datapacketssentby thesource.

� End-to-enddelay: measuredas the averageend-to-enddelay latency of datapackets; given in ms

(milliseconds).

� Numberof routediscoveries: measuredasthenumberof timesa routediscovery is initiatedby any

nodeduringthesimulationrun (it is inverselyproportionalto thetime interval betweenroutediscov-

eries).

� Routingload: measuredin termsof thetotal numberof routingpacketstransmitted(broadcasttrans-

missionsarecountedasasingletransmission).

In the first setof experimentaldata(Figure4.3), both multipathprotocolsareevaluatedwith various

chosennumbersof disjoint alternateroutes.As in all previous experiments,datapacketsarenot buffered

whenaroutediscovery is in progress.Whencomparedindividually, bothprotocolsbenefitlittle in reduction

of routediscoverieswhenusing3 or 5 alternateroutesin comparisonto only usingonealternateroute.

The sametype of relative performancecanbe seenin the amountof datapackets that aredropped.This

observationcanbeattributedto thelow percentageof alternate(disjoint) routesthatmaybeactuallysentto

a nodeoncethenumberis increasedbeyondone.Alternateroutesbeingunique,automaticallymake those

nodeswithin a routeineligible from beingreusedfor otherpossibleroutesto besentto thesource(protocol

1) or to any othernodesalongtheprimaryroute(protocol2).

Whenthe performancesof the two multipathprotocolsarecomparedagainsteachother, we cansee

thatprotocol2 hasa clearadvantageover protocol1. Thecredit for this is in how thealternateroutesare

beingreciprocated.Recall that in protocol1 only the sourcewill receive alternateroutesto the intended

destination.In protocol2, thesourceand the intermediatenodesalongtheprimary routearereceiversof

alternateroutesto theintendeddestination.Duringsimulationrunsfor protocol1, whenalink failureoccurs

alongtheprimaryroutedatapacketscanonly besalvagedwhenthesourcehasbeennotifiedof the failed


0

4000

8000

12000

16000

20000

24000

28000

32000

36000

40000

0 1 2 3 4 5 6 7 8 9 10

Rou

te D

isco

verie

s

#conversations/node

Single PathMultipath, Alt = 1Multipath, Alt = 3Multipath, Alt = 5

(a)RouteDiscoveries,Protocol1

0

4000

8000

12000

16000

20000

24000

28000

32000

36000

40000

0 1 2 3 4 5 6 7 8 9 10

Rou

te D

isco

verie

s

#conversations/node


(b) RouteDiscoveries,Protocol2

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Dro

pped

P

#conversations/node


(c) DataPacketsDropped,Protocol1

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

0 1 2 3 4 5 6 7 8 9 10

Fra

ctio

n of

Pac

kets

Dro

pped

P

#conversations/node


(d) DataPacketsDropped,Protocol2

Figure4.3: Numberof routediscoveriesandfractionof datapacketsdroppedfor thesinglepathandbothmultipathDSRprotocolsusing1, 3, and5 alternateroutes.


link and the sourcehasan alternaterouteto the intendeddestination.All datapackets in transitwill be

dropped.If thesourcedoesnothaveanalternateroute,thena freshroutediscoverywill beinduced.During

this routediscovery phase,all datapacketswill bedropped.Thus,thetime periodfrom whena link failure

occursandthesourceis notifiedto begiventheopportunityto switchto analternaterouteis crucialto the

overallperformance.Thisproblemis furthercompoundedif this timeperiodis extendedto includethetime

it takes for a routediscovery to obtaina new routeto the destinationif thereis no alternaterouteat the

source.

In protocol2, whena link failureoccursalongtheprimaryroutedatapacketsaregiventheopportunity

to besalvagedat any nodealongtheprimary route(assumingthe nodeshave alternateroutes).This sup-

plementalopportunityundeniablygivesprotocol2 theadvantagein salvaginga higherpercentageof data

packetsover protocol1. Furthermore,giventhataparticularnodedoesnothave analternateroute,anerror

packet is generatedandpassedbackto its upstreamneighborin orderto give it achanceto salvageimpend-

ing datapackets. If so,thentheerrorpacket is not propagatedany further, thuspreventinganunnecessary

routediscovery from thesource.In theworstcasescenario,theerrorpacket will besentbackto thesource

whereit is giving the lastopportunityto salvagedatapackets(i.e. protocol1). Protocol2’s advantageous

characteristicsshow up in Figure4.3 (b) and(d) whencomparedto protocol1, Figure4.3 (a) and(c). The

contingency thatprotocol1 wasfacedwith (discussedabove) is alleviatedin protocol2 dueto thehelpof

the intermediatenodes.Routediscoveriesarereducedconsiderablyin protocol2 relative to protocol1 as

arethe amountof datapackets that aredropped.Basedupontheseresults,protocol2 waschosenasthe

protocolwith themostpotential. Sincelittle is gainedby going beyondonealternateroutepernode,this

numberwaschosenasthefixedparameterfor protocol2. Henceforth,all experimentsconductedarebased

uponprotocol2 with onealternateroute.

Figure4.4 (a) shows significantimprovementsin thenumberof routediscoveriesfor differentnumber

of conversations,demonstratingthatthemultipathprotocolis ableto reducethenumberof routediscoveries

by roughlyone-third.Significantsavingsin datapacketsdroppedshows to bebetween20-30%asshown in

Figure4.4 (b). Detailedinstrumentationof thesimulatorrevealsthat30-40%of delivereddatapacketsuse

alternateroutes.Thisshows up to besignificantin our experimentalresultsdespitethefactthatavailability


0

4000

8000

12000

16000

20000

24000

28000

32000

36000

40000

0 1 2 3 4 5 6 7 8 9 10

Rou

te D

isco

verie

s

#conversations/node

Single PathMultipath

(a)RouteDiscoveries

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.10

0 1 2 3 4 5 6 7 8 9 10F

ract

ion

of P

acke

ts D

ropp

ed

P

#conversations/node


(b) DataPacketsDropped

0

2

4

6

8

10

12

14

16

0 1 2 3 4 5 6 7 8 9 10

Del

ay (

ms)

Q

#conversations/node


(c) End-to-endDelay

0

1

2

3

4

5

0 1 2 3 4 5 6 7 8 9 10

Hop

s F

or a

Pat

h

]

#conversations/node

Single PathMultipath, PrimaryMultipath, Alt = 1

(d) AverageHopsFor aPath

Figure4.4: Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaveragehop lengthfor the singlepathandmultipathDSR protocol. The multipathprotocol(protocol2) usesonedisjointalternateroutefrom eachintermediatenode(includingthesource)to thedestination.


0

20000

40000

60000

80000

100000

120000

140000

160000

180000

0 1 2 3 4 5 6 7 8 9 10

Rou

ting

Pac

kets

#conversations/node


(a)TotalRoutingPackets

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

110000

120000

0 1 2 3 4 5 6 7 8 9 10

Req

uest

Pac

kets

#conversations/node


(b) RequestPackets

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

55000

60000

0 1 2 3 4 5 6 7 8 9 10

Rep

ly P

acke

ts

^

#conversations/node


(c) ReplyPackets

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

11000

12000

13000

14000

0 1 2 3 4 5 6 7 8 9 10

Err

or P

acke

ts

^

#conversations/node


(d) ErrorPackets

Figure4.5: (a): Total numberof routingpacketstransmittedduring thesimulationrun for thesamesetofsimulationsasin Figure4.4. (b)-(d): Breakdown of theroutingpacketsin request,reply, anderrorpackets.


of alternateroutesarenot alwaysguaranteed.However, ascanbeseenin Figure4.4 (c), end-to-enddelay

hasincreasedslightly in themultipathprotocol.This is dueto thefactthatthealternateroutesaretypically

longerthantheprimaryroutes(seeFigure4.4(d)). Thealternateroutesareonanaverageabout1 hoplonger

thantheprimaryroute. Theprimaryroutelengthwasfoundto beabout4 averagewise. Recallthatusing

disjoint alternateroutesleavesany nodeto be usedonly oncein any alternatereply to any nodewithin a

primaryroutefor any givensource,destinationpair. As nodesthatarecloseto thevicinity of thenodesof

theprimaryrouteareusedin alternatereplys,theavailability of nodesfurtheraway from theseusednodes

canonly beused.This in turn increasesthelengthof alternaterouteswhich alsoextendsthelatency of the

end-to-enddelay.

Figure4.5 (a-d)shows therouting loadandits breakdown into request,reply, anderrorpackets. Note

that the numberof route requestpackets (Figure 4.5 (b)) comedown for the multipath protocol almost

proportionateto the numberof routediscoveries. The replies,on the otherhand,increasesomewhat as

shown in Figure4.5 (c). This is expectedbecauseof multiple repliesperroutediscovery cycle. This slight

increasein reply(unicast)packetsarecounteredoff by themoresignificantreductionof request(broadcast)

packets. Theerrorpacketsalsocomedown becauseof fewer routeerrorsgenerated,asseenin Figure4.5

(d). Recall that protocol2 canhave its intermediatenodesalongthe primary routesalvagedatapackets,

unlike protocol1. This in turn prohibitsan error packet from traveling any further thanwhat is needed.

Overall thesetranslateto savingson theroutingload.Thesavingsaremoresignificantonhigh loads(close

to a quarter)which shows thatthesealternateroutesarehelpfulevenfor a higherratio of conversationsper

node.Thus,preventinganoverabundantamountof routediscoveriesthatwould normallyoccurfor sucha

high load.

Figures4.6 - 4.9 show resultsfrom a similar set of experimentswith varying mobility but constant

traffic loadsat 1 (low traffic load)and9 conversations(high traffic load), respectively, per node. General

observationsarethesameasabove,exceptthatwefind asmallerfractionalimprovementof theroutingload

andnumberof routediscoveriesfor highermobilities. This is dueto thefact thatfor highermobilitiesit is

morelikely thata link failureof anexistingrouteis accompaniedby a link failureof its alternateroute.The


0200400600800

10001200140016001800200022002400260028003000

0 4 8 12 16 20 24 28 32

Rou

te D

isco

verie

s



(a)RouteDiscoveries

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.10

0 4 8 12 16 20 24 28 32F

ract

ion

of P

acke

ts D

ropp

ed

_




0

2

4

6

8

10

12

14

16

0 4 8 12 16 20 24 28 32

Del

ay (

ms)

`



(c) End-to-endDelay

0

1

2

3

4

5

0 4 8 12 16 20 24 28 32

Hop

s F

or a

Pat

h

a




Figure4.6: Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaveragehop lengthfor thesamenetwork with varyingmobility. Now the traffic load is fixedat 1 conversationpernode.


0

4000

8000

12000

16000

20000

24000

28000

32000

36000

40000

0 4 8 12 16 20 24 28 32

Rou

ting

Pac

kets




0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

22000

24000

0 4 8 12 16 20 24 28 32

Req

uest

Pac

kets



(b) RequestPackets

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

11000

12000

13000

14000

0 4 8 12 16 20 24 28 32

Rep

ly P

acke

ts

^



(c) ReplyPackets

0

500

1000

1500

2000

2500

3000

3500

4000

0 4 8 12 16 20 24 28 32

Err

or P

acke

ts

^



(d) ErrorPackets

Figure4.7: (a): Total numberof routingpacketstransmittedduring thesimulationrun for thesamesetofsimulationsasin Figure4.6. (b)-(d): Breakdown of routingpacketsin request,reply, anderrorpackets.


breakagesof the existing routeandthe alternateroutemay be correlated,for instance,whenthe existing

routebreaksdueto movementof thedestinationnode.

4.3 RelatedWork

As alreadymentioned,the ideaof multipathrouting is not new but incorporatingthe ideainto mobile ad

hocnetworksneedsto beinvestigated.TheTemporallyOrderedRoutingAlgorithm or TORA [54] provides

multiple alternatepathsby maintaininga “destination-oriented” directedacyclic graph(DAG) from the

source. However, TORA doesnot have an easymechanismto evaluatethe “quality” of thesemultiple

routes.Becauseof thenatureof theprotocol,it is hardto determinewhichrouteis theshortest.In addition,

TORAdid notperformwell in comparisonto otheron-demandprotocolsasoursimulationresultsin Chapter

2 have shown.1

TheDynamicSourceRouting(DSR)protocol[5, 38] alsohasanoptionof maintainingmultiple routes,

so that analternateroutecanbeuseduponfailure of the primary one. In DSR,the quality of routes(i.e.

hop-wiselengths)canbeeasilyevaluatedandthebest(i.e. theshortest)onecanbeused.But in DSR[38]

toomany routesaremaintainedin a trivial manner, withoutany regardto theirultimateusefulness.Further,

if alternaterouteshave a lot of overlapwith theprimaryroute,a link failure in theprimaryroutemayalso

forcethemto becomeinvalid.


We proposedtwo multipathextensionsfor the popularon-demandrouting protocolDSR. The extension

exploresalternate,disjoint routesthatcanbeusefulin casetheprimaryroutebreaks.Two variationswere

explored. In thefirst, only thesourcegetsmultiple alternateroutes.In thesecond,eachintermediatenode

on theprimaryroutegetsanalternateroute(asidefrom thesource).Thekey advantageis thereductionin

thefrequency of routediscovery floods,which is recognizedasamajoroverheadin on-demandprotocols.

1Thecontemporarywork by CMU in [6] alsoshowedTORA to bedeficientin performancerelative to otheron-demandproto-cols.


0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

55000

60000

0 4 8 12 16 20 24 28 32

Rou

te D

isco

verie

s



(a)RouteDiscoveries

0

0.02

0.04

0.06

0.08

0.10

0.12

0.14

0 4 8 12 16 20 24 28 32F

ract

ion

of P

acke

ts D

ropp

ed

_




0

2

4

6

8

10

12

14

16

0 4 8 12 16 20 24 28 32

Del

ay (

ms)

`



(c) End-to-endDelay

0

1

2

3

4

5

0 4 8 12 16 20 24 28 32

Hop

s F

or a

Pat

h

a




Figure4.8: Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaveragehoplengthfor thesamenetwork with varyingmobility. Now thetraffic loadis fixedat 9 conversationspernode.


020000400006000080000

100000120000140000160000180000200000220000240000260000280000300000

0 4 8 12 16 20 24 28 32

Rou

ting

Pac

kets




0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

0 4 8 12 16 20 24 28 32

Req

uest

Pac

kets



(b) RequestPackets

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

0 4 8 12 16 20 24 28 32

Rep

ly P

acke

ts

^



(c) ReplyPackets

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

22000

24000

26000

0 4 8 12 16 20 24 28 32

Err

or P

acke

ts

^



(d) ErrorPackets

Figure4.9: (a): Total numberof routingpacketstransmittedduring thesimulationrun for thesamesetofsimulationsasin Figure4.8. (b)-(d): Breakdown of routingpacketsin request,reply, anderrorpackets.


Performanceevaluationusinga packet-level routingsimulatorshows significantreductionsin thenum-

berof routediscoveriesandhencein routingloadfrom theuseof multipathrouting. Thereductionscould

beup to aboutonehalf for routediscoveriesandsimilarly for therouting load. Also, asa consequenceof

alternatedisjoint routes,fraction of droppedpackets improved by up to aboutone-third. As wasshown,

alternateroutestendto belongerthantheprimaryroute.This in turn, leadsto a slightly longerend-to-end

delayfor thedelivereddatapackets.This resultsin a subtletradeoff betweenend-to-enddelayandrouting

load.Oursimulationsdonotmodeltheradiolink layerandthusnomultipleaccessinterferenceis captured.

We believe that in a realnetwork, reductionin the routing loadwill alsocontribute to reducedend-to-end

delaybecauseof thereducedinterference.Thus,thetradeoff will bemoreon thesideof reductionof the

routingload.

Chapter 5

On-DemandPower-AwareRouting

Even thoughmucheffort hasbeenspentin understandingthe behavior of the routing protocolsandtheir

comparative performancecharacteristics(see,for example,[6, 17,16]), lessattentionhasbeenpaidto make

theseprotocolsenergy-efficient. In critical environmentssuchasmilitary or rescueoperations,wheread

hocnetworkswill betypically used,conservingof batterypower will bevital in orderto make thenetwork

operationalfor long durations. Recharging or replacingbatterieswill often not be possible. This makes

thestudyin power-awareroutingcritical. Thechallengein adhocnetworks is thateven if a hostdoesnot

communicateon its own, it still frequentlyforwardsdataandrouting packets for others,which drainsits

battery. Switchingoff a non-communicatingnodemaynot bealwaysa goodidea,asit maydisconnectthe

network.

In this chapterwe againfocuson the on-demandrouting protocolcalledDynamicSourceRoutingor

DSR[38, 7] andexploresimpletechniquesto make this protocolpower-aware.Eventhoughwe developed

andevaluatedthesetechniquesfor DSR,they shouldbeapplicablefor otheron-demandprotocolsof similar

nature,suchasAODV [55, 58]. On-demandprotocolsarechosenfor power-awareness,asthey typically

have lower routingoverheadsthanproactive distributedshortestpathprotocols(our simulationsconfirmed

this in Section2.2of Chapter2) andthushave lower baselineenergy consumption.

62

CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 63

(b)

S DDATA

WZ-PKT

WZ

(a)

S DDATA

S DDATA

WZ

(d)

Route discoveryinitiated (i.e. flooding)

(c)

S DDATA

WZ

Figure5.1: WarningZoneState

5.1 Power-AwareRouting

Thetechniquewe proposeis built aroundtwo batteryenergy levels. We assumethat thenodescanalways

determinethe remainingbatteryenergy and take appropriaterouting decisions. Two energy thresholds

are defined. Below the first one, the nodeentersa the warning zonestate,signifying that its batteryis

runninglow, but is still adequateto keepit running.However, at this point it wishesto relieve itself of the

routingactivities if alternative routerscanbefound.If alternativescanbefound,they take over therouting.

Otherwise,the warning zonenodecontinuesrouting as usual. If the batteryof the warning zonenode

continuesto bedepletedit eventuallycrossesanotherlower threshold,below which it entersthe low zone

state.Here,thebatteryis low enough,thatthisnoderefusesto routepacketsfor othernodes.But it canstill

functionasa sourceor destinationof packets. Eventuallyasthebatterycontinuesto bedepleted,thenode

dies.

For thefollowing description,referto Figure5.1.Figure5.1(a)showsanestablishedroutefor thegiven

sourceR , destinationS pair. Upon enteringthe warning zonestate,a node(labeledWZ) sendsbacka

warningzonepacket (WZ-PKT) backto thesourceR to give it awarningthatit shouldfind anotherroutein

placeof theexisting routethatdoesnot includethis warningzonenode.However, this beinga “courtesy”


S DDATA

WZ

LZ

(e)

M

M

Data PacketsDropped

S DDATA

WZLZ-PKT

LZ

(c)

Route discoveryinitiated (i.e. flooding)

M

Data PacketsDropped

S DDATA

WZ

LZ

(d)

M

S DDATA

WZ

(a)

WZ

WZ-PKT

MRoute discoveryinitiated (i.e. flooding)

S DDATA

WZ

WZ

(b)

Figure5.2: Low ZoneState

warning,the WZ nodewill continueto routedatapackets for the source(shown in solid lines leadingto

the destinationS ) until it hasfound anotherroute. This is shown in Figure5.1 (b). Upon receiving an

WZ-PKT, thesourceR startsusinganalternative routefrom its cacheor, if thereis nosuchroute,it initiates

a routediscovery to find alternateroutes.The latterscenariois shown in Figure5.1 (c). Theentireregion

encapsulatedby the dashedline signifys RREQpackets that aredisseminateddueto the routediscovery

originatedat the source R . Notice that the WZ nodedoesnot participatein this routediscovery. After

receiving RREQpackets,theWZ nodewill not forwardthem,thusguaranteeingthatit will notbeincluded

in thenew route.Figure5.1(d) shows thenew route(solid lines)thatthesourceR hasobtainedvia a route

discovery to thedestinationS .


Figure5.2depictssuchascenariofor anodegoinginto the low zonestatefrom thewarning zonestate.

This sequence,beginning with Figure5.2 (a), is the nodeWZ en route from R to S . Let us assumethat

thesourceR cannotfind a new routeafter it receivesWZ-PKT andissuesa routediscovery asdepictedin

Figure5.2 (b). Also, assumethatnode T hasmoved from its original location. NodeWZ’s batterylevel

will continueto bedepleteduntil it reachesthe low zonestate(now shown asLZ in Figure5.2 (c)). At this

point it hasno otheroptionbut to sendbacka low zonepacket (LZ-PKT) to thesourceR telling it that it

refusesto participatein aidingits datapacketsto reachthedestinationS . At thispoint forth, any moredata

packetsthattheLZ nodeencountersfrom R will bedropped.Also, nodeT is assumedto havemovedonce

again.TheLZ nodewill alsorefuseto participatein anyotherroutediscoveriesthatarecurrentlyoccurring

or will occuron the network. Again, network flooding is depictedasthe region encapsulatedwithin the

dashedline in Figure5.2 (d). The LZ nodewill continue,however, to sendand/orreceive its own data

packetsif needed.Thefinal routediscovered,which doesnot includeboththeLZ nodeandtheWZ node,

is shown Figure5.2(e).

Note that in eitherof thecasesdescribedabove, a nodewill never completelyshutitself down. Thus,

a nodewill still keepits network interfaceon and receive packets. The reasonis that without actually

receiving packets it is not possibleto know the intent of the packet. It is just the transmittingactivity

that will becurtaileddependingon the stateof the node. For example,in the low zonestate,a nodewill

not transmitany datapacket except its own andwill not transmitany routing packet unlessit is an error

(RERR)packet. Thisscenariocanoccurif thesourcehasnotyet receivedtheLZ-PKT andalink failurehas

occurreddownstreamfrom the vicinity of theLZ nodealongthis currentroute. Error packetsarealways

treatedwith top priority regardlessof node’s batterystatus(low zonestateor warning zonestate)andneed

to bedeliveredto theintendingsource.Notethatothernodesalonga brokenrouteshouldalsobeinformed

whena link hasfailedsothatthey mayalsotake appropriateaction.

Note thatpotentialroutediscovery activities after receiving a WZ-PKT or LZ-PKT will alsodrain the

energy of othernodes.To optimizethe overall energy budget,routediscovery timeoutsaremanipulated.

Thistimeoutreflectshow longthesourcenodeshouldwait for areplybeforeissuinganotherroutediscovery.

A muchlongertimeoutis chosenfor routediscoveriesafterreceiving theWZ-PKT. If a routeis not found,


thenthenext routediscoverywill notoccurimmediately. Rather, thesourcewaitsfor aperiodof time,which

we call a periodictimeout, beforeissuingthenext routediscovery. Thereasonbehindthis is that,although

a new routeshouldbe found,thescenariois not asurgentaswhentheredoesnot exist any route. Recall,

thattheWZ nodethatsenttheWZ-PKT is still willing to forwarddatapacketsasa courtesyto thesource.

Thus,for thetime thattheWZ nodeis still in thewarningzonestate,thesource’s datapacketswill still be

forwarded.During thescenariothata sourcereceivesanLZ-PKT from anLZ node,however, this will be

treatedasthoughit wereanRERRpacket, to which thesourcewill immediatelyclearthiscurrentroute(or

any otherroutefor thatmattercontainingthis link) from its cacheandproceedto begin a routediscovery.

Herethereis no useof theperiodictimeoutsincethis is treatedasa moreurgentcasein thata new routeis

neededto befoundimmediately. Thus,if no routeis foundsoonthenaftera small timeoutperiod,another

routediscovery will begin. The small timeoutperiod is a predefinedtime that is the averagetime that it

takesfor a sourceto receive a routereply onceit hasstarteda routediscovery andis considerablysmaller

thantheperiodictimeout.

5.1.1 PerformanceTradeoffs

It is importantto understandthat the performancetradeoffs posedby the above power-awaremechanism.

Themechanismdoesnot directly attemptto optimizethepower consumptionof thenetwork asa whole. It

just wantsto avoid usingnodeswith low batterylevels, thusrunningthe risk of nodesdying prematurely

andpossiblydisconnectingthenetwork. It is actuallypossiblethat thealternaterouteusedafter receiving

a WZ-PKT or LZ-PKT is longerthantheoriginal route.Thispresentsseveral inefficiencies.First, thedata

packet latency could be higher for longer routes. Second,overall energy expenditurefor routing a data

packet would behigherfor longerroutes.Third, additionalroutediscoverieswill alsoconsumeadditional

energy. However, theusefullifetime of thenetwork will increaseasnodeswith low batterylevelswill be

avoidedasmuchaspossibleandoverall energy drainwill befairly distributedall over thenetwork instead

of beingconcentratedin a few nodes.Wewill seeevidenceof this in theperformanceevaluationsection.

Variousnetwork, traffic and mobility characteristicswill have a varying degreeof influenceon our

method.For example,if thenetwork is sparselyconnectedthenodeswill nothaveasmuchof aselectionof


alternatenodes.Thiswill reducetheeffectivenessof our technique.Similarly, a largenumberof conversa-

tionscoveringmany differentsource-destinationpairsmaynot gainvery muchfrom this technique.Here,

many nodesin the network will act asroutersandtherewill not be many free nodesto shift the routing

loadto. Lastly, highmobility somewhatbalancesout theroutingloadoverall nodesasroutesarefrequently

changing.Thus,high mobility scenariosmaynot gainvery muchfrom this techniqueeither. We will see

evidenceof someof theseconjecturesin thenext section.


We simulatedour power-aware routing techniqueas an extensionto the DSR protocol for a mobile, ad

hocnetwork. TheDSRprotocolis implementedwith the low zonestateonly, while thepower-awarerout-

ing protocolis implementedwith both the low zonestateandthewarning zonestateasdescribedbefore.

Promiscuouslisteningwasnot implementedin eitherprotocolasthis hasbeenshown to bea ratherexpen-

sive power consumption-wise[25]. Again as in previous chapters,the event-driven, packet-level routing

simulatorMaRSis usedfor thesimulationstudy. In themodelwe have simulated,60 mobilehostsmove

arounda rectangularregion of size800m � 800m accordingto thefollowing mobility model.Eachnode

choosesa direction,speedanddistanceof move basedon a pre-defineddistribution andthencomputesits

next position � andthetimeinstant� of reachingthatposition.Similarly, anew “move” is againcomputed

at simulationtime � . A nodecomputesits neighborhoodaftereachsuchmove, thusgeneratinglink failure

andlink repaireventsthat in turn drive the routingprotocol. Eachnodeis assumedto have a radio range

of 350m. For theexperimentsreportedhere,thespeedof eachmove is uniformly distributedbetween3.0

– 5.0 m/sec(low mobility experiments)and7.0 – 9.0 m/sec(mediummobility experiments),distanceis

exponentiallydistributedwith ameanof 5 m,andthedirectionis uniformly distributedwithin �H*Z[)\ ' (N�"[)\ ' -with respectto thedirectionof thepreviousmove. Notethatin thechosenmobility model,thenodesareal-

waysmoving (albeit in discretetime)withoutstationaryintervals.Thispresentsastresscasefor therouting

protocol.

Theworkloadis thesameasdescribedin Subsection2.1.2of Chapter2. Weused5 and10conversations

with sourceanddestinationsselectedrandomly. All simulationsarerun until thedatapacket delivery frac-


tion (definedbelow) dropsbelow 80%.Eachpoint in a plot representsanaverageof tenrunswith different

randomnumberstreams.

Five importantperformancemetricsareevaluated:

� Packet deliveryfraction– measuredastheratio of thenumberof datapacketsdeliveredto thedesti-

nationandthenumberof datapacketssentby thesource,

� Batterylevel– measuredastheamountof remainingbatteryenergy,

� Fraction of nodesin the low zonestate– measuredasthe fraction of nodesin the network whose

batterylevel is ator below thethresholdof LOW ZONE,

� End-to-enddelay– measuredastheaverageend-to-endlatency of datapackets,

� Average numberof hops– averagenumberof hopsin theroutes.

In theperformanceplotsall thesemetricsareplottedacrossatimeaxisaveragedover10secondintervals

in orderto capturetheoverall run-timedynamics.For thetwo batterythresholdlevels,thefollowing values

are found to work well in our model. We have useda value of 45% of the initial batterylevel for the

WARNING ZONE thresholdanda valueof 20%of theinitial batterylevel for theLOW ZONE threshold.

Following the publishedvaluesfor power consumptionfor variouscommercialradio network interfaces

[66], we have assumedthat a nodespends2 units of energy for transmittingversus1 unit of energy for

receiving a packet. To make the measurementsimpler, we have usedthe sameenergy valuesregardless

of the sizeof the packet. We assumethat thereis no batterydrainwhena nodeis idle – not receiving or

transmittingany packets.In realityhowever, thereis adrainwhenever thenetwork interfaceis on,evenif it

is idle. But this issueshouldn’t affect our comparative evaluation.Wehave initialized thebatteryto 15,000

unitsof energy.

5.2.1 Simulation Results

In thefirst setof experimentaldata(Figure5.3),we ranour power-awareroutingprotocolagainstthebase-

line DSRusing5 conversationsand10conversations,respectively. Bothprotocolswererunusinglow node


0.4

0.5

0.6

0.7

0.8

0.9

1

0 100 200 300 400 500 600 700 800 900 1000 1100

Fra

ctio

n of

Pac

kets

Del

iver

ed

b

Seconds

DSRPower-Aware Routing

(a)DataPacket Delivery, 5 conversations

0.5

0.6

0.7

0.8

0.9

1

0 100 200 300 400 500 600 700 800 900 1000 1100

Fra

ctio

n of

Initi

al B

atte

ry L

evel

Rem

aini

ng P

er N

ode

c

Seconds


(b) BatteryLevel, 5 conversations

0.4

0.5

0.6

0.7

0.8

0.9

1

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700

Fra

ctio

n of

Pac

kets

Del

iver

ed

d

Seconds


(c) DataPacket Delivery, 10conversations

0.5

0.6

0.7

0.8

0.9

1

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700

Fra

ctio

n of

Initi

al B

atte

ry L

evel

Rem

aini

ng P

er N

ode

c

Seconds


(d) BatteryLevel, 10 conversations

Figure5.3: Datapacket delivery andbatterylevel remainingpernodefor 5 conversationsand10 conversa-tions,respectively, for low mobility.

mobility. For bothnumbersof conversationsexperimentedwith, datapacket delivery wasgreatlyenhanced

over a periodof time with thepower-awareroutingprotocol. This metric is shown in Figure5.3 (a,c). In

DSRsomenodesstarteddyingearly, thusoccasionallydisconnectingthenetwork. Nodesstartdyingmuch

laterin thepower-awareroutingprotocolasour techniqueattemptsto distributeroutingparticipationoncea

nodeenterstheWZ state.Overall,a packet delivery ratioof at least90%wasextendedbetween150to 200

seconds.Figure5.3 (b,d)shows thataveragebatteryconsumptionwasalsonoticeablyreceptive in savings

in relationto the DSR protocolover this time. A closerobservation revealsa direct correlationbetween

batterylevel savingsandtheextendedtime for highdatapacket delivery fraction.


Performancesfor 5 and10 conversationsrun at mediummobility areshown in Figures5.4 and 5.5.

respectively. As canbeseenfor datapacket delivery andbatterylevel in bothcases,Figures5.4 (a,b)and

5.5(a,b)respectively, thelongevity for bothmetricsareextendedconsiderably. Extendedtime is about100

secondsfor datapacket delivery of at least90%andabout70 secondsfor datapacket delivery of at least

80%.As before,thereis adirectcorrelationbetweentheaveragebatteryconsumptionandtheextendeddata

packet delivery.

Thefractionof nodesthathaveenteredthelow zonestatehasbeenreducedby asmuchas50%for most

of thedurationof thetimeascanbeseenin Figures5.4(c)and5.5(c). Indicatingthattherearemoreactive

nodesavailablethroughoutthenetwork with sufficientbatterypower to keeproutingpackets.

As time goeson, theaverageend-to-enddelayincreasesslightly in our protocol.This is not surprising

asthenumberof nodesavailableto routepacketsbecomesless,routelengthsaretypically longer. This is

shown in Figures5.4(d,e)and5.5 (d,e). Also, notethat for the DSR protocolthe inverseoccursastimes

goeson. Dueto thehigherpercentageof nodesin thelow zonestatethereis lessactivenodeswith sufficient

batterypower to re-routedatapackets.While ashorterend-to-enddelayis attractive, thiscomesat thesame

timeof ahigherpercentageof datapacketsbeingdropped.Thus,only source-destinationpairsthatareclose

in vicinity to eachotherareableto successfullytransmitandreceive datapackets.

Furtherinvestigatedexperimentsrevealsasensitivity to bothahighernumberof conversationsand/oran

increasein mobility. Figure5.6shows theperformancemetricsfor a run of 20conversations,onceagainin

thesamesizenetwork but now with ahigh mobility of 12m/s.Notethatthereis still anincrease(although

small) in thedatapacket delivery performancefor our power-awareroutingprotocolin comparisonto the

DSR protocol for a brief periodof time in Figure5.6 (a). This, in conjunctionwith the rapidly increase

of nodesin the low zonestateshown in Figure5.6 (b), shows that therewill be little benefitwith sucha

scenarioastimegoeson. Thereasonis two fold. First,asthenumberof conversationsincreasesthroughout

thenetwork, therewill bemoredatapacketsbeingrouted(highercommunicationpattern).Thusonaverage,

nodeswill bedoingmorework eithersending,receiving, or moreimportantly, routingfor others.As more

conversationsareintroducedinto thenetwork theamountof roomfor optimizationis reduced.Second,due

to anincreasein theamountof mobility, links fail morefrequently. This increasesroutingoverheaddueto


0.4

0.5

0.6

0.7

0.8

0.9

1

0 100 200 300 400 500 600 700 800 900

Fra

ctio

n of

Pac

kets

Del

iver

ed

e

Seconds



0.5

0.6

0.7

0.8

0.9

1

0 100 200 300 400 500 600 700 800 900

Fra

ctio

n of

Initi

al B

atte

ry L

evel

Rem

aini

ng P

er N

ode

f

Seconds



0

0.01

0.02

0.03

0.04

0 100 200 300 400 500 600 700 800 900

Fra

ctio

n of

Nod

es in

the

Low

Zon

e

g

Seconds


(c) Low ZoneNodes,5 conversations

0

2

4

6

8

10

12

14

0 100 200 300 400 500 600 700 800 900

Del

ay (

ms)h

Seconds


(d) AverageDelay, 5 conversations

0

1

2

3

4

0 100 200 300 400 500 600 700 800 900

Ave

rage

Hop

s fo

r a

Pat

h

i

Seconds


(e)AverageNumberof Hops,5 conversations

Figure5.4: Variousperformancemetricsfor 5 conversationsat mediummobility.


0.4

0.5

0.6

0.7

0.8

0.9

1

0 50 100 150 200 250 300 350 400 450 500 550

Fra

ctio

n of

Pac

kets

Del

iver

ed

e

Seconds



0.5

0.6

0.7

0.8

0.9

1

0 50 100 150 200 250 300 350 400 450 500 550

Fra

ctio

n of

Initi

al B

atte

ry L

evel

Rem

aini

ng P

er N

ode

f

Seconds



0

0.01

0.02

0.03

0.04

0.05

0 50 100 150 200 250 300 350 400 450 500 550

Fra

ctio

n of

Nod

es in

the

Low

Zon

e

g

Seconds


(c) Low ZoneNodes,10conversations

0

2

4

6

8

10

12

0 50 100 150 200 250 300 350 400 450 500 550

Del

ay (

ms)h

Seconds


(d) AverageDelay, 10conversations

0

1

2

3

0 50 100 150 200 250 300 350 400 450 500 550

Ave

rage

Hop

s fo

r a

Pat

h

i

Seconds


(e)AverageNumberof Hops,10 conversations

Figure5.5: Variousperformancemetricsfor 10conversationsatmediummobility.


0.4

0.5

0.6

0.7

0.8

0.9

1

0 50 100 150 200 250

Fra

ctio

n of

Pac

kets

Del

iver

ed

e

Seconds



0

0.01

0.02

0.03

0.04

0 50 100 150 200 250

Fra

ctio

n of

Nod

es in

the

Low

Zon

e

g

Seconds


(b) Low ZoneNodes,20conversations

Figure5.6: Variousperformancemetricsfor 20conversationsathigh (12m/s)mobility.

frequentroutediscoveries,drainingbatterypower of all nodesrapidly. Thus,thereis little thatcanbedone

to optimizeanetwork with heavy traffic andhighmobility.

5.3 RelatedWork

Theproblemof trying to conserve batteryusagewithin a mobileadhocnetwork is notnew. Previousother

work hasgoneinto differentstrategieson how to conserve power usage.In [9], thenetwork longevity was

theoverall goalin reducingbatteryconsumption.An algorithmicapproachof a classof flow augmentation

algorithmscoupledwith a flow redirectionalgorithmwasused.Unlike theconventionalapproachof min-

imizing thecostof a routefrom a sourceto a givendestination,their strategy wasgearedto balancingthe

batterylevel usageamongthenodesin thenetwork in proportionto theirenergy reserves.

In [64], power-awaremetricswerediscussedandsimulatedfor performanceevaluation.Resultsshowed

thatwith theuseof thesepower-awaremetricstheactualcostperpacket wasreduced.Thoughthenetwork

sizesusedweresmall,20or lessnodes,aninterestingobservationwasmadethatin largernetworkssavings

arehigher. It shouldbenotedthatthis techniquewasrunon topof theirMAC layerprotocolPAMAS [63].

In PAMAS, nodesturnoff their interface,whenthey know they cannot(becauseof possiblemultipleaccess


interference,for example)sendor receive packets. This is, in general,a usefultechniquefor power-aware

communicationin any layer.

In [45], a transportlayerprotocolis proposedto suspendthecommunicationdevice duringidle periods

wasaddressed.Thetradeoff of sucha methodis in thechoosingof theinterval to shutdown thecommuni-

cationdeviceandwhento turn it on. Thiswill incuradelayin deliveryof datapackets.Experimentalresults

baseduponsimulationcommunicationpatternsshow thatqueuingof datawill incur only a smalldelaybut

is dependentuponthepower managementlevel.

In [25], a performanceanalysisof the on-demandprotocolsDSR andAODV [55] wereevaluatedfor

their energy consumption.Sinceno attemptwasmadeto optimizethe batteryusageof the nodeswithin

thenetwork, theprimarywork wasto evaluatetheprotocolsthemselvesduringoperation.Oneinteresting

observationwasthatflooding(thecommonoccurrenceamongon-demandprotocols)wasveryexpensive in

regardto thenetwork asa whole. This wastruefor bothprotocolsbut moresofor AODV dueto its more

broadcasttraffic stemmingfrommorefrequentroutediscoveries.However, DSRwith its promiscuousmode

turnedon alsohada very high pricesincea nodeis listeningto whatever it canlisten to andthuswill be

receptive to ahighernumberof packets.


On-demandrouting protocolsareuseful for a mobile ad hoc network environmentfor their low routing

overheads.However, if inadequatecareof batteryusageis not taking into considerationin their design,it

may leadto prematuredepletionof somenodes’batteryleadingto network frequentnetwork disconnects.

Wehaveproposedapower-awaretechniqueasanextensionof theDSRprotocolthatwill reactappropriately

to discover alternateroutesasandwhenanode’s batteryrunslow. Two levelsareusedto denotetwo levels

of urgency — onejust issuesawarning(warning zonestate)andtheotherdenotesanemergency (low zone

state).Thesourcenodesfor theroutesgoingvia thenodewith low batteryreactappropriatelyby attempting

to discover a new routeto thedestinationexcludingthosenodeswhosebatterylevel is low.

Performanceevaluationusingapacket-level routingsimulatorshowsthatthelongevity of anetwork can

beextendedby asignificantamount.Nodeswith abatterylevel in thethe low zonestateis alsoreducedby


asmuchas50%usingour technique.This is significantin thatthisallows thenetwork to usethesenodesto

forwarddatapacketsor aid in findingotherroutes,thatwoulddiequickly in thebaselineDSRprotocol.

Our power-awaretechniquecanbeusedfor otheron-demandprotocolsthatdo not usesourcerouting.

Only the nodesmonitoringtheir own batterylevel needbe implementedthe sameway asdescribedhere

with WZ-PKTsandLZ-PKTs causinga responseat thesourceasbefore.Our futureplanis to optimizeor

make thesearchingof a new route“smarter”by having a new routeconsistingonly of nodeswith a certain

adequateamountof batterylevel. For example,knowing thata routediscovery is initiatedby a WZ-PKT,

thenonly thosenodesthathaveabatterylevel of at least5%or morethantheactualWARNINGZONElevel

will beacceptedinto theviableroute. We feel that this shouldfurtherextendthe longevity of thenetwork

with still a high datapacket delivery. We alsoplanto evaluatetheeffectivenessof our techniquein various

othermobility andtraffic scenarios,andwith moreelaboratesimulationsthatmodelall protocollayers.

Chapter 6

Conclusions

Mobile ad hoc networks arecharacterizedby the lack of any stationaryinfrastructure,multihop wireless

links andfrequentlychangingnetwork topology. Suchnetworksareusefulwhereamobilenetwork mustbe

setupquickly withouttheaidof anexistinginfrastructure,suchasmilitary or search-and-rescueoperations,

emergency managementandexplorationmissions.In addition,futurecommercialuseis likely in thearea

of home-or personal-areanetworkswhereusinganinfrastructuremaynotbecost-effective.

Developmentof efficient dynamicrouting protocolsis a centralchallengein ad hoc network design.

Limited bandwidthof wirelessnetworksnecessitatesthattheroutingoverheadbekeptlow. However, this is

hardto achieve aschangingmobility requiresthatsignificantroutingandre-routingactivitiesareperformed

very frequently. Anotherimportantresourcein suchnetworks is the individual batterylevelsof eachnode

thatlimits theusefullifetime of thenetwork. Evena few nodesdyingoutquickly cansignificantlylimit the

lifetime of thenetwork if thenetwork getsdisconnected.This is very likely to happenin asparsenetwork.

Thework presentedin thisdissertationaddressestheabovechallengesin thefollowing way. It compares

theperformanceof severalexisting routingprotocolsin a commonframework andevaluatesseveraluseful

metricsincludingtheroutingoverhead.It thenfocusesontheroutingoverheadquestionfurtheranddevelops

two independenttechniquesto reducetheroutingoverheads,viz., querylocalizationandmultipathrouting.

Finally, a routingoptimizationis developedthatincreasesthelifetime of thenetwork by makingtherouting

protocolpower-aware.Wesummarizethespecificcontributionsandobservationsin thefollowing.

76

CHAPTER6. CONCLUSIONS 77

6.1 PerformanceEvaluation of Routing Protocols

In theearlystagesof thisdissertation,therewaslimited literaturethatevaluatedtheperformanceof existing

routingprotocolsin acommonframework. Ourwork wasoneof first to performacomprehensiveevaluation

of a large suiteof routing protocols,including protocolsof varioustypes(viz. proactive andreactive or

on-demand)in a commonsimulationplatform. Several useful performancemetrics,suchas fraction of

packetsdelivered,delayandroutingload,wereevaluatedacrossvarioustraffic andmobility scenarios.The

simulationresultsshow thatproactive protocolsdemonstrateexcellentperformancein end-to-enddelayand

datapacket delivery albeitwith very high routingoverhead.Reactive (on-demand)protocols,on theother

hand,showedexcellentsavingsin routingloadthoughlessthanidealperformancein end-to-enddelayand

datapacket delivery. Thiswasbecauseon-demandprotocols,unlike theirproactive counterparts,createand

maintainroutesonly onan“asneeded”basis.Thiskeepstheroutingloaddown, but letstheprotocolsuffer

amodestroutediscovery latency makingit moreproneto datapacket dropsandend-to-enddelay.

6.2 Reductionof Routing Overhead

Theroutingoverheaddifferentialbetweenproactive andon-demandprotocolswasoverwhelminglyin favor

of on-demandprotocols.In a realnetwork, routingoverheadwill adverselyimpactthedelayanddelivery

metricsbecauseof additionalmultiple accessinterferencethat our simulatordid not capturebecauseof

modelinglimitations. Also, more routing overheadwill translateto morebatteryusage. This prompted

us to focuson the routing overheadquestionfurther. Herewe only consideredon-demandprotocolsfor

theiralreadylow routingoverhead.Wedevelopedtwo techniquesto reduceroutingoverheads,asdescribed

below.

6.2.1 Query Localization

Themajorcomponentof routingloadin on-demandprotocolsis thequeryfloodingfor routediscovery. A

querylocalizationtechniqueis developedthatlimits theextentof thequeryflood, thusreducingtherouting

load. Utilizing valuableinformationfrom prior routing historiesof thesource-destinationpairs,we show


that new routesare very similar in comparisonto the older, staleroutes. Thus, flooding can be guided

aroundthevicinity of theseprior routesin finding new routes.Simulationresultsshow a reductionof the

routing load up to about50% in comparisonto network-wide flood and20% in comparisonto a simple

querycontainmentfloodmechanism.Reductionin theroutingloadis alsoshown to positively impactdelay

anddelivery performances.

6.2.2 Multipath Routing

In additionto controllingtheextentof thequeryflood, it is possibleto reducethefrequency of suchaflood.

We explore this optionhereby finding multiple routesper routediscovery. We focuson disjoint routesso

thattheseroutesarelesslikely to fail together. Alternateroutesareusedwhenprimaryroutesfail andthus

routediscovery floodscanbepostponeduntil all alternateroutesbreak.Differentmultipathtechniquesare

explored,for example,thosethatprovidealternateroutesonly at thesourceandthosethatprovideall nodes

on theprimaryroutewith thealternateroutes.Simulationresultsshow a reductionin thenumberof route

discoveriesby approximatelyone-third,which contributesto a similar reductionin the routing load. We

alsodiscoveredthatthereis little benefitin providing morethanonealternateroutes.

Multipath techniquesalsoreducestheamountof droppeddatapackets. But thereis slight increasein

theend-to-enddelayasalternateroutestendto be longerthanprimary routes.However, we considerthis

shortcomingto beveryminorcomparedto thebenefitsof multipathroutingin adhocnetworks.

6.3 On-DemandPower-AwareRouting

Finally, we focuson the questionof makingrouting protocolsawareof diminishingbatterylevels at the

nodesso that the operationallifetime of thenetwork canbe improved. Note that reductionof the routing

load also reducesbatteryusage. However, specificpower managementprotocolsneedto be devised to

offloadroutingresponsibilitiesfrom thenodesrunninglow onbatterypower. Wedevelopeda power-aware

routing techniquefor on-demandprotocolswhereall nodesare aware of their own batterylevels. The

techniqueworksby shiftingroutingresponsibilitiestowardsnodeswith higherbatterylevelsfrom nodes


with very low batterylevels. This effectively increasesthe longevity of the network by distributing the

batterylevelsmoreevenly.

Simulationresultsshow thatthelongevity of thenetwork canbeextendedup to 200secondswhile still

deliveringa highpercentageof datapackets.Theamountof nodeswhosebatterypower wasdrainedto the

level of not beingableto help in any form of routingwasreducedby 50%. Thus,thenumberof potential

participatingnodesis increasedandbatterylevelsaredistributedmoreevenlyamongthenetwork.

6.4 Future Work

A coupleof researchdirectionsareimmediatelyapparentfrom theabove work. First,moreelaboratesim-

ulatorsthatmodelall protocollayersin detailwill possiblydiscover performanceissuesthatcouldnot be

ascertainedfromthework presentedin thisthesis.For example,theinteractionof theroutingloadwith other

metrics(suchasdelayandpacket delivery fraction)will bemoreseverein a detailedsimulator. Somede-

tailedsimulationwork is alreadyin progressin ourgroupor elsewhere[37, 41]. Wehappilynote,however,

thatdetailedsimulatorsfind farbetterimprovementsfrom usingourroutingloadreductiontechniques.See,

for example,our recentwork reportedin [15]. Second,realadhocnetwork testbedsneedto bedeveloped

to understandperformanceissuesfurther. Someeffortsareunderway in our researchgroup[20].

Severaladditionaltechniquesareexpectedto improveperformanceof on-demandroutingprotocolsthat

arenot yet exploredby the researchcommunity. For example,theprotocolscurrentlygivespreferenceto

shortestroute in termsof hop countandnot in termsof delay. Using a delaymetric is complex, asit is

dynamicallychangingevenwithoutany changein route,andalsoit maygive riseto routeoscillations.But

clearly, a delaymetricwill bemoreeffective from theapplication’s point of view. Similarly, routescanbe

constructedby skirting aroundcongestionpointswhich will alsoemphasizethedelaymetric. In addition,

choiceof sophisticatedqueuingdisciplines,for example,thosethatwill givehigherpriority to certaintypes

of packets(say, errorpacketsmorethantherouterequestpackets)shouldbeexplored.

Bibliography

[1] G. AggelouandR. Tafazolli. Rdmar:A bandwidth-efficient routingprotocolfor mobileadhocnet-works. In Proceedingsof ACM MobiCom99WoWMoM99, August1999.

[2] I. F. Akyildiz, J. S. M. Ho, andY.-B. Lin. Movement-basedlocationupdateandselective pagingforPCSnetwork. IEEE/ACM TransactionsonNetworking, 4(4):629–638,August1996.

[3] C. Alaettinoglu,A. U. Shankar, K. Dussa-Zieger, andI. Matta. Designandimplementationof MaRS:A routingtestbed.Journalof Internetworking:Research andExperience, 5(1):17–41,1994.

[4] D. BertsekasandR. Gallager. DataNetworks. Prentice-Hall,1987.

[5] J.Broch,D. Johnson,andD. Maltz. Thedynamicsourceroutingprotocolfor mobileadhocnetworks.http://www.ietf.org/internet-drafts/ draft-ietf-manet-dsr-01.txt, Dec1998.IETF InternetDraft.

[6] J.Broch,D. A. Maltz, D. B. Johnson,Y-C. Hu, andJ.Jetcheva. A performancecomparisonof multi-hopwirelessadhocnetwork routingprotocols.In Proceedingsof the4th InternationalConferenceonMobileComputingandNetworking(ACM MOBICOM’98), pages85–97,October1998.

[7] JoshBroch, David Johnson,andDavid Maltz. The dynamicsourcerouting protocol for mobile adhocnetworks.http://www.ietf.org/internet-drafts/ draft-ietf-manet-dsr-03.txt, Oct1999.IETF InternetDraft (work in progress).

[8] K. Carlberg andJ. Crowcroft. Building sharedtreesusinga one-to-many joining mechanism.ACMComputerCommunicationReview, pages5–11,January1997.

[9] J.H.ChangandL. Tassiulas.Energy conservingroutingin wirelessad-hocnetworks. In Proceedingsof theIEEEInfocomTheConferenceonComputerCommunications, pages22–31,March2000.

[10] S.ChenandK. Nahrstedt.DistributedQoSroutingwith imprecisestateinformation.In 7th Int. Conf.onComputerCommunicationsandNetworks(IC3N), pages614–621,October1998.

[11] C. Cheng,R. Riley, andS.P. R. Kumar. A loop-freeextendedBellman-Fordroutingprotocolwithoutbouncingeffect. In Proc.of ACM SIGCOMMConf., pages224–236,1989.

[12] M.S. Corson,S. Batsell,andJ. Macker. Architecturalconsiderationsfor mobile meshnetworking.http://tonnant.itd.nrl.navy.mil/mmnet/ mmnetRFC.txt, May 1996. RequestforCommentsDraft.

[13] M.S.CorsonandA. Ephremides.A distributedroutingalgorithmfor mobilewirelessnetworks. Wire-lessNetworks, 1(1):61–81,1995.

80

BIBLIOGRAPHY 81

[14] S. Corson, S. Papademetriou, P. Papadopoulos, V. Park, and A. Qayyum. An in-ternet MANET encapsulationprotocol (IMEP) specification. http://www.ietf.org/internet-drafts/draft-ietf-manet-imep-spec-01.txt, 1998.InternetDraft.

[15] R. CastanedaS.R.Das. Query localizationtechniquesfor on-demandrouting protocolsin ad hocnetworks. ACM/BaltzerWirelessNetworksJournal, 2000.Submitted.

[16] SamirR.Das,CharlesE.Perkins,andElizabethM. Royer. Performancecomparisonof two on-demandroutingprotocolsfor adhocnetworks.In Proceedingsof theIEEEINFOCOM2000Conference, March2000.

[17] S.R.Das,R. Castaneda,J. Yan, andR. Sengupta.Comparative performanceevaluationof routingprotocolsfor mobile,adhocnetworks. In 7th Int. Conf. on ComputerCommunicationsandNetworks(IC3N), pages153–161,October1998.

[18] S.R.Das,R. Castaneda,J.Yan,andR. Sengupta.Simulationbasedperformanceevaluationof routingprotocolsfor mobile,adhocnetworks. ACM/BaltzerWirelessNetworksJournal, 1998.Submitted.

[19] IEEEStandardsDepartment.WirelessLAN mediumaccesscontrol(MAC) andphysicallayer(PHY)specifications,IEEEstandard802.11–1997,1997.

[20] S. Desilva andS. R. Das. Experimentalevaluationof a wirelessadhocnetwork. In ProceedingsoftheIEEEInternationalConferenceonComputerCommunicationandNetworks(ICCCN’00), October2000.

[21] E. W. Dijkstra. A noteon two problemsin connectionwith graphs.NumericalMathematics, 1:269–271,Oct.1959.

[22] F. Douglis,P. Krishnan,andB. Marsh.Thwartingthepower hungrydisk. In Proceedingsof the1994Winter USENIXConference, January1994.

[23] J. Haarstenet. al. Bluetooth:Vision, goals,andarchitecture.ACM SIGMOBILEMobile ComputingandCommunicationsReview, 2(4):38–45,Oct1998.

[24] K. Fall and K. Varadhan. ns notes and documentation.http://www-mash.cs.berkeley.edu/ns/, November1997.

[25] L. M. Feeney. An energy consumptionmodelfor performanceanalysisof routingprotocolsfor mobileadhocnetworks.http://www.sics.se/ lmfeeney/research.html, July1999.

[26] B. FreislebenandR. Jansen.Analysisof routingprotocolsfor adhocnetworksof mobilecomputers.In Proceedingsof the15thIASTEDInternationalConferenceonAppliedInformatics, pages133–136,Innsbruck,Austria,1997.Iasted-ActaPress.

[27] E. Gafni andD. Bertsekas.Distributedalgorithmsfor generatingloop-freeroutesin networks withfrequentlychangingtopology. IEEETrans.onCommunication, 29(1):11–18,January1981.

[28] J.J.Garcia-Luna-Aceves.A unifiedapproachto loopfreeroutingusingdistancevectorsor link states.In Proc.of ACM SIGCOMM’89Conf., pages212–223,Sept.1989.

[29] M. Gerla and J.T.-C. Tsai. Multicluster, mobile, multimediaradio networks. WirelessNetworks,1(3):255–265,1995.

BIBLIOGRAPHY 82

[30] Z. Haas.A new routingprotocolfor thereconfigurablewirelessnetworks. In Proc. of the IEEE Int.Conf. onUniversal PersonalCommunications., Oct1997.

[31] Z. J.HaasandM. R.Pearlman.Thezoneroutingprotocol(ZRP)for adhocnetworks.http://www.ietf.org/internet-drafts/draft-ietf- manet-zone-zrp-00.txt, 1997. IETFInternetDraft.

[32] Z. J. Haasand M. R. Pearlman. The performanceof query control schemesfor the zoneroutingprotocol.In Proceedingsof ACM SIGCOMM’98Conference, pages167–177,Vancouver, Sept.1998.

[33] C. Hedrick. Routinginformationprotocol.RFC1058,June1988.

[34] D. Helmbold,D.D. E. Long, andB. Sherrod.A dynamicdisk spin-down techniquefor mobilecom-puting. In SecondACM InternationalConferenceon Mobile ComputingandNetworking(ACM MO-BICOM’96), pages130–142,November1996.

[35] P. Jacquet,P. Muhlethaler, and A. Qayyum. Optimized link state routing protocol. http://www.ietf.org/internet-drafts/ draft-ietf-manet-olsr-00.txt, November1998.IETF InternetDraft.

[36] M. Jiang, J. Li, and Y. C. Tay. Cluster based routing protocol (CBRP). http://www.ietf.org/internet-drafts/ draft-ietf-manet-cbrp-spec-00.txt,August1998. IETF InternetDraft.

[37] P. Johansson,T. Larsson,N. Hedman,B. Mielczarek,andM. Degermark.Scenario-basedperformanceanalysisof routing protocolsfor mobile ad-hocnetworks. In Proceedingsof the 5th InternationalConferenceon Mobile Computingand Networking(ACM MOBICOM’99), pages195–206,August1999.

[38] D. JohnsonandD. Maltz. Dynamicsourceroutingin adhocwirelessnetworks. In T. Imielinski andH. Korth,editors,Mobilecomputing. Kluwer Academic,1996.

[39] J. JubinandJ. D. Tornow. The DARPA packet radio network protocols. Proceedingsof the IEEE,75(1):21–32,January1987.

[40] P. Karn. Maca- a new channelaccessmethodfor packet radio. In ARRL/CRRLAmateurRadio9thComputerNetworkingConference, pages134–140,1990.

[41] B. Karp andH.T. Kung. Gpsr:Greedyperimeterstatelessroutingfor wirelessnetworks. In Proceed-ingsof the6thInternationalConferenceonMobileComputingandNetworking(ACM MOBICOM’00),August2000.Submitted.

[42] S.Keshav. AnEngineeringApproach to ComputerNetworking: ATM Networks,theInternet,andtheTelephoneNetwork, chapter11. Addison-Wesley, 1997.

[43] A. KhannaandJ. Zinky. A revisedARPANET routingmetric. In Proc. of the ACM SIGCOMM’89Conf., pages45–56,Sept.1989.

[44] Y. Ko andN. H. Vaidya.Location-aidedrouting(LAR) in mobileadhocnetworks. In ACM/IEEEIn-ternationalConferenceonMobileComputingandNetworking(MOBICOM), pages66–75,November1998.

BIBLIOGRAPHY 83

[45] R.KravetsandP. Krishnan.Powermanagementtechniquesfor mobilecommunication.In Proceedingsof the 4th InternationalConferenceon Mobile Computingand Networking(ACM MOBICOM’98),pages157–168,October1998.

[46] P. Krishna,N. H. Vaidya,M. Chatterjee,andD. K. Pradhan.A cluster-basedapproachfor routingindynamicnetworks. ACM SIGCOMMComputerCommunicationReview, pages49–65,April 1997.

[47] J. R. Lorch andA. J. Smith. Reducingpower processorconsumptionby improving processortimemanagementin a single-useroperatingsystem.In SecondACM InternationalConferenceon MobileComputingandNetworking(ACM MOBICOM’96), pages143–154,November1996.

[48] J. Macker and S. Corson. Mobile ad hoc networks (MANET). http://www.ietf.org/html.charters/manet-charter.html, 1997.IETF WorkingGroupCharter.

[49] J.Moy. OSPFversion2. RFC1247,July1991.

[50] S.Murthy andJ.J.Garcia-Luna-Aceves. An efficient routingprotocolfor wirelessnetworks. MobileNetworksandApplications, 1(2):183–197,Oct.1996.

[51] USCGNavigation CenterGPSPage. http://www.navcen.uscg.mil/faq/gpsfaq.htm,April 1998.

[52] V. ParkandS.Corson.A performancecomparisonof TORA andideallink staterouting. In Proceed-ingsof IEEESymposiumof Computers andCommunication, June1998.

[53] V. Park and S. Corson. Temporally ordered routing algorithm (TORA) version 1, func-tional specification.http://www.ietf.org/ internet-drafts/ draft-ietf-manet-tora-spec-01. txt, 1998.IETF InternetDraft.

[54] V. D. Park andM. S. Corson. A highly adaptive distributed routing algorithmfor mobile wirelessnetworks. In Proceedingsof IEEEINFOCOM’97Conf., pages1405–1413,April 1997.

[55] C. Perkins. Ad hoc on demand distance vector (AODV) routing. http://www.ietf.org/internet-drafts/ draft-ietf-manet-aodv-00.txt, 1997.IETF InternetDraft.

[56] C. PerkinsandP. Bhagwat. Highly dynamicdestination-sequenced distance-vector routing (DSDV)for mobilecomputers.In Proceedingsof theACM SIGCOMM’94 Conference, pages234–244,August1994.

[57] C. Perkins and E. Royer. Ad hoc on demand distance vector routing. http://www.ietf.org/internet-drafts/ draft-ietf-manet-aodv-02.txt, November1998.IETF InternetDraft.

[58] CharlesPerkins,ElizabethRoyer, andSamirDas.Ad hocondemanddistancevector(AODV) routing.http://www.ietf.org/internet-drafts/ draft-ietf-manet-aodv-04.txt, Oct 1999. IETF InternetDraft (workin progress).

[59] Y. RekhterandT. Li. A BorderGatewayProtocol-4.RFC827,March1995.

[60] N. SchachamandJ.Westcott.Futuredirectionsin packet radioarchitecturesandprotocols.Proceed-ingsof theIEEE, 75(1):83–99,Jan1987.

BIBLIOGRAPHY 84

[61] A. U. Shankar, C. Alaettinoglu,K. Dussa-Zieger, and I. Matta. Transientand steady-stateperfor-manceof routing protocols: Distance-vector versuslink-state. Journal of Internetworking: Re-search and Experience, 6:59–87,1995. (Preliminary version appearedin Proc. ACM SIGMET-RICS/PERFORMANCEConf.,1992,pages181-192.).

[62] S.SinghandC. S.Raghavendra.PAMAS - power awaremulti-accessprotocolwith signallingfor adhocnetworks. In ACM ComputerCommunicationReview (ACM CCR’98), July 1998.

[63] S.SinghandC. S.Raghavendra.PAMAS - power awaremulti-accessprotocolwith signallingfor adhocnetworks. In ACM ComputerCommunicationReview (ACM CCR’98), July 1998.

[64] S. Singh, M. Woo, and C. S. Raghavendra. Power-aware routing in mobile ad hoc networks. InProceedingsof the4th InternationalConferenceonMobileComputingandNetworking(ACM MOBI-COM’98), pages181–190,October1998.

[65] R. Sivakumar, P. Sinha, and V. Bharghavan. Core extraction dis-tributed ad hoc routing (CEDAR) specification. http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-cedar-00.txt, October1998.IETF InternetDraft.

[66] M. Stemm,P. Gauthier, D. Harada,andR.Katz.Reducingpowerconsumptionof network interfacesinhand-helddevices. In Third InternationalWorkshoponMobileMultimediaCommunication(MoMuc-3’96), December1996.

[67] M. StemmandR. Katz. Reducingpower consumptionof network interfacesin hand-helddevices. InThird InternationalWorkshoponMobileMultimediaCommunication(MoMuc-3’96), December1996.

[68] M. Weiser, B. Welch,A. Demers,andS.Shenker. Schedulingfor reducedcpuenergy. In Proceedingsfo theFirstSymposiumonOperatingSystemDesignandImplementation(OSDI’94), November1994.

[69] W.T. ZaumenandJ.J.Garcia-Luna-Aceves. Loop-freemultipathroutingusinggeneralizeddiffusingcomputations.In Proceedingsof theIEEEINFOCOM’98, pages1408–1417,March1998.

Vita

RobertCastanedawasborn in SanAntonio, Texasin the countryof the United Statesof Americaon

March16, 1963. He is thethird child of HenryG. CastanedaandRomanaCastaneda.He grew up in San

AntonioandattendedWestAvenueElementarySchool,Nimitz Middle School,andgraduatedfrom Robert

E. LeeHigh Schoolin May 1981.For his higherlevel of education,heattendedtheUniversityof Texasat

SanAntonio wherehe obtaineda Bachelor’s Degreeof Sciencein ComputerSciencein December1990.

He later pursuedgraduateschoolthereandearneda Master’s Degreeof Sciencein ComputerSciencein

December1994. His researchcollectively leadto a Master’s Thesisentitled“Evaluating Hot SpotEffects

andMutual ExclusionAlgorithmPerformanceon SharedMemoryMultiprocessors” underthesupervision

of Dr. XiaodongZhang.His researchalsoleadto theawardUniversity Life Award for College of Science

andEngineeringthatwaspresentedto him in April 1994.After graduationhebecameaResearchAssistant

underDr. Zhangto furtherhis researchskills. With theadventof thenew ComputerSciencePh.Dprogram

establishedin theFall of 1995at theUniversityof Texasat SanAntonio,heagainbecamea studentin his

questfor his doctoraldegree.Undertheguidanceof his advisor, Dr. SamirR. Das,his researchleadto his

dissertationentitled“Pr otocolsfor MobileAdHoc Networking”. Hesuccessfullydefendedhis dissertation

onAugust25,2000andformally earnedhisDoctoratedegreein December, 2000.UponearninghisDoctor

of Philosophyin ComputerSciencehis interesthave turnedto industryto pursueacareerwithin thefield of

wirelessdatanetworking. Currentlyhehasoneson,RobertGabrielCastaneda,bornJuly 16, 1986in San

Antonio,Texas.

Teaching

Universityof Texasat SanAntonio,1997-2000.

Publicationsstemmingfrom thisdissertationareannotatedhere.

Publications

Journals

“Query LocalizationTechniquesfor On-demandRoutingProtocolsin Ad Hoc Networks”, ACM/BaltzerWirelessNetworks, 2000.(with SamirR. DasandMaheshK. Marina).

“Performanceof MultipathRoutingfor On-DemandProtocolsin Mobile Ad hocNetworks”, WirelessMul-ticastandRoutingin MONET, 2000.(with AsisNasipuriandSamirR. Das).

“SimulationBasedPerformanceEvaluationof Mobile, Ad hocNetwork RoutingProtocols”,ACM/BaltzerWirelessNetworks, 1999.(with SamirR. DasandJiangtaoYan).

Conferences

“A Power-Aware Routing Techniquefor On-DemandRouting Protocolsin Mobile Ad Hoc Networks”,submittedfor publication(with SamirR. Das).

“QueryLocalizationTechniquesfor On-demandRoutingProtocolsin Ad HocNetworks”, TheFifth AnnualACM/IEEEInternationalConferenceon Mobile ComputingandNetworking(MOBICOM), August,1999.(with SamirR. Das).

“Comparative PerformanceEvaluationof RoutingProtocolsfor Mobile Ad HocNetworks”, ProceedingsoftheSeventhInternationalConferenceon ComputerCommunicationsandNetworks(IC3N), October, 1998.(with SamirR. Das,JiangtaoYan,andRimli Sengupta).

Otherpublicationsfrom previousresearchareannotatedhere.

Publications

Journals

“ExecutionComplexities andPerformanceof SoftwareMutual ExclusionAlgorithmson Shared-MemoryMultiprocessors”,IEEEParallel & DistributedTechnology, SpringIssue,1996,pp. 25-42.(with XiaodongZhangandYongYan)

“ComparativePerformanceEvaluationof HotSpotContentionBetweenMIN-basedandRing-basedShared-MemoryArchitectures”,IEEE Transactionson Parallel andDistributedSystems, Vol. 6, No. 8, 1995,pp.872-886.(with XiaodongZhangandYongYan).

“Spin-LockSynchronizationon theButterfly andKSR-1”, IEEE Parallel andDistributedTechnology, Vol.2, SpringIssue,1994,pp. 51-63.(with XiaodongZhangandElisaW. Chan).

Conferences

“A Comparative Evaluationof HierarchicalNetwork Architectureof theHP-Convex Exemplar”,Proceed-ings of IEEE InternationalConferenceon ComputerDesign, October, 1997. (with XiaodongZhangandJamesM. Hoover).

“Modeling andmeasuringhot spotson MIN-basedandHR-basedshared-memoryarchitectures”,Proceed-ings of the Fifth IEEE Symposiumon Parallel and Distributed Processing(SPDP’93), IEEE ComputerSocietyPress,December, 1993.(with XiaodongZhangandYongYan).

Permanentaddress: 638EdgebrookLnSanAntonio,TX 78213-4514

Thisdissertationwastypesetby RobertCastanedain LATEX.

Documents

PROTOCOLS FOR MOBILE AD HOC NETW ORKING FOR MOBILE AD HOC NETW ORKING Robert Castaneda,˜ B.S., ... ﬂooding by exploring multiple, ... to run internetworking …