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.
PROTOCOLS FOR MOBILE AD HOC NETWORKING
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
PROTOCOLS FOR MOBILE AD HOC NETWORKING
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
CHAPTER1. INTRODUCTION 3
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
CHAPTER1. INTRODUCTION 4
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
CHAPTER1. INTRODUCTION 5
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.
CHAPTER1. INTRODUCTION 6
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].
CHAPTER1. INTRODUCTION 7
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.
CHAPTER1. INTRODUCTION 8
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.
CHAPTER1. INTRODUCTION 9
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.
CHAPTER1. INTRODUCTION 10
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
CHAPTER1. INTRODUCTION 11
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%
CHAPTER1. INTRODUCTION 12
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.
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 15
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.
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 16
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.
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 17
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
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 18
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
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 19
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
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 20
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.
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 21
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.
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 22
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.
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 23
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
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 24
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.
2.4 Concluding Remarks
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
CHAPTER2. PERFORMANCEEVALUATION OFUNICAST ROUTING PROTOCOLS 25
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
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 28
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 � .
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 29
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.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 30
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).
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 31
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
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 32
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.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 33
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.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 34
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
(a)Low mobility, Protocol1
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
(b) Low mobility, Protocol2
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
(c) High mobility, Protocol1
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
(d) High mobility, Protocol2
Figure3.3: Datapacket delivery fractionfor low andhighmobilitiesfor differentvaluesof k.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 35
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
(a)Low mobility, Protocol1
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
(b) Low mobility, Protocol2
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
(c) High mobility, Protocol1
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
(d) High mobility, Protocol2
Figure3.4: Averagedelayfor low andhighmobilitiesfor differentvaluesof k.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 36
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.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 37
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
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 38
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.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 39
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-
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 40
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
Average Mobility (m / sec)
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
Average Mobility (m / sec)
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
Average Mobility (m / sec)
DSR-NWDSR-QC
protocol-1
(d) Packet delivery fraction,square-with-a-holeregion
Figure3.10: Routingoverheadanddatapacket delivery metricsfor 1 conversation/nodewith varyingmo-bilities.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 41
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
Average Mobility (m / sec)
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
Average Mobility (m / sec)
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.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 42
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
Average Mobility (m / sec)
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
Average Mobility (m / sec)
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
Average Mobility (m / sec)
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
Average Mobility (m / sec)
DSR-NWDSR-QC
protocol-1
(d) Packet delivery fraction,square-with-a-holeregion
Figure3.12: Routingoverheadanddatapacket delivery metricsfor 9 conversation/nodewith varyingmo-bilities.
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 43
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
Average Mobility (m / sec)
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
Average Mobility (m / sec)
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.
3.4 Concluding Remarks
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
CHAPTER3. QUERY LOCALIZATION TECHNIQUES 44
(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
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 47
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
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 48
(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.
4.2 PerformanceEvaluation
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.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 49
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.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 50
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
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 51
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
Single PathMultipath, Alt = 1Multipath, Alt = 3Multipath, Alt = 5
(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
Single PathMultipath, Alt = 1Multipath, Alt = 3Multipath, Alt = 5
(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
Single PathMultipath, Alt = 1Multipath, Alt = 3Multipath, Alt = 5
(d) DataPacketsDropped,Protocol2
Figure4.3: Numberof routediscoveriesandfractionof datapacketsdroppedfor thesinglepathandbothmultipathDSRprotocolsusing1, 3, and5 alternateroutes.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 52
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
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 53
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
Single PathMultipath
(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
Single PathMultipath
(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.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 54
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
Single PathMultipath
(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
Single PathMultipath
(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
Single PathMultipath
(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
Single PathMultipath
(d) ErrorPackets
Figure4.5: (a): Total numberof routingpacketstransmittedduring thesimulationrun for thesamesetofsimulationsasin Figure4.4. (b)-(d): Breakdown of theroutingpacketsin request,reply, anderrorpackets.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 55
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
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 56
0200400600800
10001200140016001800200022002400260028003000
0 4 8 12 16 20 24 28 32
Rou
te D
isco
verie
s
Average Mobility (m / sec)
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 4 8 12 16 20 24 28 32F
ract
ion
of P
acke
ts D
ropp
ed
_
Average Mobility (m / sec)
Single PathMultipath
(b) DataPacketsDropped
0
2
4
6
8
10
12
14
16
0 4 8 12 16 20 24 28 32
Del
ay (
ms)
`
Average Mobility (m / sec)
Single PathMultipath
(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
Average Mobility (m / sec)
Single PathMultipath, PrimaryMultipath, Alt = 1
(d) AverageHopsFor aPath
Figure4.6: Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaveragehop lengthfor thesamenetwork with varyingmobility. Now the traffic load is fixedat 1 conversationpernode.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 57
0
4000
8000
12000
16000
20000
24000
28000
32000
36000
40000
0 4 8 12 16 20 24 28 32
Rou
ting
Pac
kets
Average Mobility (m / sec)
Single PathMultipath
(a)TotalRoutingPackets
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
Average Mobility (m / sec)
Single PathMultipath
(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
^
Average Mobility (m / sec)
Single PathMultipath
(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
^
Average Mobility (m / sec)
Single PathMultipath
(d) ErrorPackets
Figure4.7: (a): Total numberof routingpacketstransmittedduring thesimulationrun for thesamesetofsimulationsasin Figure4.6. (b)-(d): Breakdown of routingpacketsin request,reply, anderrorpackets.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 58
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.
4.4 Concluding Remarks
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.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 59
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
Average Mobility (m / sec)
Single PathMultipath
(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
_
Average Mobility (m / sec)
Single PathMultipath
(b) DataPacketsDropped
0
2
4
6
8
10
12
14
16
0 4 8 12 16 20 24 28 32
Del
ay (
ms)
`
Average Mobility (m / sec)
Single PathMultipath
(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
Average Mobility (m / sec)
Single PathMultipath, PrimaryMultipath, Alt = 1
(d) AverageHopsFor aPath
Figure4.8: Numberof routediscoveries,fractionof datapacketsdropped,end-to-enddelay, andaveragehoplengthfor thesamenetwork with varyingmobility. Now thetraffic loadis fixedat 9 conversationspernode.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 60
020000400006000080000
100000120000140000160000180000200000220000240000260000280000300000
0 4 8 12 16 20 24 28 32
Rou
ting
Pac
kets
Average Mobility (m / sec)
Single PathMultipath
(a)TotalRoutingPackets
0
20000
40000
60000
80000
100000
120000
140000
160000
180000
200000
0 4 8 12 16 20 24 28 32
Req
uest
Pac
kets
Average Mobility (m / sec)
Single PathMultipath
(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
^
Average Mobility (m / sec)
Single PathMultipath
(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
^
Average Mobility (m / sec)
Single PathMultipath
(d) ErrorPackets
Figure4.9: (a): Total numberof routingpacketstransmittedduring thesimulationrun for thesamesetofsimulationsasin Figure4.8. (b)-(d): Breakdown of routingpacketsin request,reply, anderrorpackets.
CHAPTER4. ON-DEMAND MULTIPATH ROUTING 61
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”
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 64
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 .
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 65
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,
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 66
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
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 67
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.
5.2 PerformanceEvaluation
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-
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 68
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
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 69
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
DSRPower-Aware Routing
(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
DSRPower-Aware Routing
(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
DSRPower-Aware Routing
(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.
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 70
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
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 71
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
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
Fra
ctio
n of
Initi
al B
atte
ry L
evel
Rem
aini
ng P
er N
ode
f
Seconds
DSRPower-Aware Routing
(b) BatteryLevel, 5 conversations
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
DSRPower-Aware Routing
(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
DSRPower-Aware Routing
(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
DSRPower-Aware Routing
(e)AverageNumberof Hops,5 conversations
Figure5.4: Variousperformancemetricsfor 5 conversationsat mediummobility.
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 72
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
DSRPower-Aware Routing
(a)DataPacket Delivery, 10 conversations
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
DSRPower-Aware Routing
(b) BatteryLevel, 10 conversations
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
DSRPower-Aware Routing
(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
DSRPower-Aware Routing
(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
DSRPower-Aware Routing
(e)AverageNumberof Hops,10 conversations
Figure5.5: Variousperformancemetricsfor 10conversationsatmediummobility.
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 73
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
DSRPower-Aware Routing
(a)DataPacket Delivery, 20 conversations
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
DSRPower-Aware Routing
(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
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 74
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.
5.4 Concluding Remarks
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
CHAPTER5. ON-DEMAND POWER-AWARE ROUTING 75
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
CHAPTER6. CONCLUSIONS 78
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
CHAPTER6. CONCLUSIONS 79
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.