University of Southern California Dissertations and Theses

Rate adaptation in networks of wireless sensors

(USC Thesis Other)

Rate adaptation in networks of wireless sensors

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content RATEADAPTATIONINNETWORKSOFWIRELESSSENSORS by JeongyeupPaek ADissertationPresentedtothe FACULTYOFTHEUSCGRADUATESCHOOL UNIVERSITYOFSOUTHERNCALIFORNIA InPartialFulfillmentofthe RequirementsfortheDegree DOCTOROFPHILOSOPHY (COMPUTERSCIENCE) December2010 Copyright 2010 JeongyeupPaek Acknowledgements I would like to thank professor Ramesh Govindan for being an excellent advisor, a trusted mentor, and a respectablerolemodelthroughoutmypursuitofPh.D. Iwould liketoacknowledge mycollaborators also. Tenet was ajointworkwithBenGreenstein, Om- prakash Gnawali, Ki-Young Jang, Marcos Vieira, August Joki, John Hicks, Prof. Eddie Kohler, and Prof. Deborah Estrin. RAPS was a joint work with Joongheon Kim. Although not included in this dissertation, earlier work on structural health monitoring was joint work with Krishna Chintalapudi, analysis work on ZigZag was done with Prof. Michael Neely, and the SALSA work in Urban Tomography project was a jointworkwithMoo-RyongRa,AbhishekSharmaandProf. MartinKrieger. ii TableofContents Acknowledgements ii ListOfTables vi ListOfFigures vii Abstract xi Chapter1: Introduction 1 Chapter2: LiteratureReview 5 2.1 SensorNetworkArchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 CongestionControlandReliableTransport . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 EnergyEfficientLocalizationonMobileSmartphones . . . . . . . . . . . . . . . . . . . . 12 Chapter3: TheTenetArchitectureforTieredSensorNetworks 15 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2 TheTenetPrinciple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3 TheTenetSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.1 DesignPrinciples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.2 TasksandtheTaskLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.2.1 TaskBuildingBlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.2.2 TheTaskDataStructure . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.2.3 MoteRuntime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.2.4 TaskOperations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.2.5 OSDependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.2.6 ExamplesofTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.2.7 AnExampleofaDataCollectionApplication . . . . . . . . . . . . . . 30 3.3.3 TheNetworkingSubsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.3.1 TieredRouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.3.2 TieredTaskDissemination . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.3.3 ReliableTransport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4 TenetEvaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4.1 TasksandTasklets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.4.2 ApplicationCaseStudy: Pursuit-Evasion . . . . . . . . . . . . . . . . . . . . . . 44 3.4.3 ApplicationCaseStudy: Event-BasedVibrationMonitoring . . . . . . . . . . . . 49 3.4.4 Real-WorldDeployment: VibrationMonitoringatVincentThomasBridge . . . . 51 3.4.5 RealWorldDeployment: PitfallTrapMonitoringatJamesReserve . . . . . . . . 55 3.4.6 Manageability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 iii 3.4.7 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Chapter4: RCRT:Rate-ControlledReliableTransportProtocolforWirelessSensorNetworks 63 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2 RateControlledReliableTransport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.1 DesignGoals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.2 RCRT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.2.3 End-to-EndReliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2.4 CongestionDetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.2.5 RateAdaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.2.6 RateAllocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.2.7 OtherDetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.2.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.3.1 ImplementationandMethodology . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.3.2.1 Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.3.2.2 Optimality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.3.2.3 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.3.2.4 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.3.2.5 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.3.3 NetworkTopology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.3.3.1 NetworkSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.3.3.2 NetworkDensity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.3.3.3 NetworkDepth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.3.4 Sensitivity: Hop-by-HopRetransmissionsandQueueSizes . . . . . . . . . . . . . 105 4.3.5 AdditiveIncreaseParameterA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.4 Real-WorldDeployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.4.1 MotivationandDeployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 4.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Chapter5: Energy-EfficientRate-AdaptiveGPS-basedPositioningforSmartphones 114 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.3 Rate-AdaptivePositioningSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 5.3.2 Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.3.3 Space-TimeHistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.3.4 Celltower-RSSBlacklisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.3.5 Bluetooth-basedPositionSynchronization . . . . . . . . . . . . . . . . . . . . . . 135 5.3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.4.1 QuantifyingtheBenefitsof RAPS anditsComponents . . . . . . . . . . . . . . . 140 5.4.2 Comparing RAPS toPeriodicGPSActivation . . . . . . . . . . . . . . . . . . . 147 5.4.3 IntegrationwithaWiFiPositioningSystem . . . . . . . . . . . . . . . . . . . . . 149 5.4.4 AreGPSerrorsPervasive? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 5.4.5 SummaryandFutureWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 iv Chapter6: Conclusions 154 References 155 AppendixA ListofTenetTaskletAPI’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 AppendixB TenetTaskingAPIHowTo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 v ListOfTables 2.1 SensorNetworkTransportProtocols: ATaxonomy . . . . . . . . . . . . . . . . . . . . . 9 3.1 TaskletsinTheTenetTaskLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2 TenetNetworkingMechanismSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 Statisticsforexampletasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4 Executiontimeofmeasuringthemeandeviationfromthemeanasafunctionofthenumber ofinputsamples. Averagedoverfiveruns. . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.5 PEGApplicationOverhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1 RCRTComponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2 ExperimentstoDemonstratethat RCRT MeetsitsGoals. . . . . . . . . . . . . . . . . . . 87 4.3 SetupforTwo-Application,Two-SinkExperiment. . . . . . . . . . . . . . . . . . . . . . 97 4.4 RateAchievedby RCRT forVariousNetworkSizesandTopologies. . . . . . . . . . . . . 102 4.5 RCRT Resultson40-NodeNetworkwithVaryingRFPowerSettings. . . . . . . . . . . . 104 4.6 RCRT Resultson40-NodeNetworkwithVaryingNumberofSinkNodes. . . . . . . . . . 105 4.7 RCRT Resultson40-nodeNetworkwithVaryingAdditiveIncreaseParameter‘A’. . . . . 108 5.1 Six Different Schemes Used for Evaluation ( -mark and×-mark represent enabled and disabled,respectively) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 5.2 ComparisonofThe RAPS AgainstPeriodicGPSwithFixedDuty-Cycle . . . . . . . . . 147 5.3 ComparisonofThe RAPS withGPSandWPS. . . . . . . . . . . . . . . . . . . . . . . . 150 vi ListOfFigures 3.1 Motedatastructuresforatypicaltask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 PEGapplicationerror. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3 PEGdetectionlatency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4 Vibrationsensingwithonsetdetector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.5 Deploymenttopologyonthebridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.6 Time-seriesplotoftheaccelerationdatafromtwodifferentnodes: measuredinperpendic- ulardirectiontothebridge,ataround5:00pm. . . . . . . . . . . . . . . . . . . . . . . . . 53 3.7 Verticalvibrationmodalfrequencies(Hz). . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.8 DeploymenttopologyattheJamesReserve. . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.9 Image-transfer vs. time plot: An image is generated every 30 minutes, in addition to wheneveranobjectisdetected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.10 Spidertriggeredimagetransfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.11 Sun/shadechangecausedimagetransfers. . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.12 TestbedtopologyasgatheredbyNextHop()→Send(). . . . . . . . . . . . . . . . . . 59 3.13 Taskdisseminationlatency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.14 Sequencenumberevolutionofstreamtransportconnections. . . . . . . . . . . . . . . . . 61 4.1 CDFplotofthepacketlatencyplotfromWisdendeployment,2004. . . . . . . . . . . . . 64 4.2 Plotof p i ,correspondingtotaltrafficr i (t) ′ ,andeffectofM(t) . . . . . . . . . . . . . . . . 76 4.3 AsnapshotofroutingtopologyconstructedbyMultihopLQI. . . . . . . . . . . . . . . . . 86 4.4 Rater i allocatedtoeverynodeinthe40-nodeexperimentwithfairratepolicy. . . . . . . . 89 vii 4.5 Per-nodegoodputinthe40-nodeexperimentwithfairratepolicy. . . . . . . . . . . . . . 89 4.6 Packetreceptionplotforallnodesinthe40-nodeexperimentwithfairratepolicy. . . . . . 90 4.7 Percentage of packet repaired by end-to-end loss recovery mechanism in the 40-node ex- periment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.8 Feedbackpacketoverhead(percentagerelativetodatapackets)inthe40-nodeexperiment. 91 4.9 Averagegoodputachievedbybest-efforttransport. . . . . . . . . . . . . . . . . . . . . . 92 4.10 Averagegoodputachievedbyreliabletransport. . . . . . . . . . . . . . . . . . . . . . . . 92 4.11 Averagegoodputachievedby RCRT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.12 Rate r i allocated to each node in the 40-node experiment with demand-proportional rate allocationpolicywhen8nodesjoininafter500seconds. . . . . . . . . . . . . . . . . . . 95 4.13 Per-flowgoodputinthe40-nodeexperimentwithdemand-proportionalrateallocationpol- icywhen8nodesjoininafter500seconds. . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.14 Numberofroutingparentchangesduringthe40-nodeexperimentwithdemand-proportional rateallocationpolicywhen8nodesjoininafter500seconds. . . . . . . . . . . . . . . . . 96 4.15 Rate allocated to each node in 39-node experiment with two applications running on two sinks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.16 Per-nodegoodput(twoflowsforsamenodestackedtogether)in39-nodeexperimentwith twoapplicationsrunningontwosinks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.17 RateachievedbyIFRCand RCRT in30-nodeexperiment . . . . . . . . . . . . . . . . . 99 4.18 Rateachieved byIFRCand RCRT ina30-nodeexperiment withmodifiedMACparame- tersforsoftwareacknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.19 Asnapshotofroutingtopologyconstructedina80nodenetwork . . . . . . . . . . . . . . 103 4.20 LayoutofsourceandsinknodesinTutornet. . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.21 GoodputachievedbyRCRTinthe40-nodeexperimentwithvaryingqueuesizesandmax- imumnumberofhop-by-hopretransmissions. . . . . . . . . . . . . . . . . . . . . . . . . 106 4.22 PRR achieved by best-effort transport (z-axis) with varying forwarding queue sizes (x- axis)andvaryingmaximumnumberofhop-by-hopretransmissions(y-axis). . . . . . . . . 107 4.23 AmapdetailingthelocationandtopologyofourdeploymentatJamesReserve. . . . . . . 109 4.24 Linkconnectivityofeachnode: PacketreceptionrateandRSSItonexthopnode. . . . . . 111 4.25 Rate-allocationprofileatJamesReserveforsingleimagetransfer . . . . . . . . . . . . . . 112 viii 4.26 Rate-allocationprofileatJamesReservefor10imagetransfers(2hour45minuteperiod) . 112 5.1 AccuracyofGPS,WPS,andGSM-basedPositioning . . . . . . . . . . . . . . . . . . . . 115 5.2 Power consumption ofGPSonN95smartphone (Repeated 30seconds onand 90seconds off) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.3 GPStraceplotshowingtheinaccuracyofGPSinurbanareas. . . . . . . . . . . . . . . . 118 5.4 GPSgroundtruthverification: DistanceerrorofGPSreadingvs. GPSgroundtruth . . . . 119 5.5 DistributionofhorizontalaccuracyreportedbyGPSonN95smartphone . . . . . . . . . . 120 5.6 DistributionofdistancesbetweenGPSupdatesforperiodicGPSwith180secupdateinterval.121 5.7 Updateintervalvs. averagedistancebetweenGPSupdatesforperiodicGPS. . . . . . . . 122 5.8 Example behavior of the onset detector where the acceleration signal and its envelope of usermovement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.9 PowerconsumptionofaccelerometersensoronN95phone . . . . . . . . . . . . . . . . . 126 5.10 Accelerometerduty-cycleparameterselection . . . . . . . . . . . . . . . . . . . . . . . . 129 5.11 Conceptual view of the 3-D space-time coordinate system used for maintaining history of usermobility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 5.12 CDF of the distance between two consecutive GPS locations 5 seconds apart; with and withoutaGSMcellId change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.13 RSSdifferencevs. distance,betweentwopositionswithingsamecellId . . . . . . . . . . 133 5.14 GPSavailabilityprobabilityasafunctionofsignalstrengthfortwodifferentcellId’s . . . 134 5.15 PowerconsumptionofBluetoothonN95phone . . . . . . . . . . . . . . . . . . . . . . . 136 5.16 GPStraceplotofourexperiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.17 Lifetimeofthephones(inhours:min)foreachofthetestedschemes . . . . . . . . . . . . 142 5.18 Eventtimelineofthethreephones;twowithBPSenabled,andtheotherwithBPSdisabled 143 5.19 Contentofthecelltower-RSSblacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 5.20 AverageGPSactivationinterval(inseconds)foreachofthetestedschemes . . . . . . . . 145 5.21 Estimatedaveragepowerconsumptionforeachofthetestedschemes . . . . . . . . . . . 146 5.22 Median distance between two consecutive GPS position updates for each of the tested schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 ix 5.23 Average position uncertainty of periodic GPS from experiment as a function of duty- cyclinginterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 5.24 SuccessratioofperiodicGPSfromexperimentasafunctionofduty-cyclinginterval . . . 148 5.25 PowerconsumptionofWPSonN95phone . . . . . . . . . . . . . . . . . . . . . . . . . 150 5.26 Assisted-GPSvs. GPS:Positionerrorcomparison . . . . . . . . . . . . . . . . . . . . . 151 5.27 Comparisonofpositionerrorforfourdifferenttypesofmobilesmartphones . . . . . . . . 152 x Abstract In this dissertation we explore rate-adaptation in networks of wireless sensors. We investigate how the conceptofrateadaptationcanbeusedtobuildsensingsystemsthatadapttothenetworkandenvironment dynamics. Specifically,wedesignarate-adaptivetransportprotocolthatcanreliablyandefficientlydeliver sensordataonanarchitecturethatrespectsthetechnologicalconstraintsoftheembeddedsensors. Wealso designarate-adaptivesensingsystemthatadaptstotheenvironmentandthebehavioroftheusertoprovide energy-efficientlocationsensing. WefirstpresenttheTenetarchitecturethatrespectsthetechnologicalconstraintsoftheembeddedsen- sors. Tenetconstrainsmultinodefusiontothemastertierwhileallowingmotestoprocesslocally-generated sensor data. We show through extensive evaluation and real-world deployments that Tenet architecture simplifies application development and allows mote-tier software to be reused without significant loss of performance. Wealsoshowthattieredarchitecturescalesnetworkcapacityandallowsreliabledeliveryof highratedata. We next present RCRT, a rate-controlled reliable transport protocol suitable for resource constrained sensor nodes in wireless sensor networks. RCRT uses end-to-end explicit loss recovery, but places all the congestion detection and rate adaptation functionality in the sinks. We show that, because sinks make rate allocation decisions, they are able to achieve greater efficiency and flexibility since they have a more comprehensiveviewofnetworkbehavior. WeevaluateRCRTextensivelyonarealwirelesssensornetwork testbed and show that RCRT achieves a significantly better rate than that achieved by IFRC and WRCP, tworecentlyproposedinterference-awaredistributedrate-controlprotocols. Wealsopresentresultsfroma xi 3-month-longrealworlddeploymentofRCRTinanimagingapplicationandshowthatRCRTworkswell inreallong-termdeployments. Finally, we present RAPS, a rate-adaptive positioning system for smartphone applications. It is based on the observation that GPS is generally less accurate in urban areas, so it suffices to turn on GPS only as often as necessary to achieve this accuracy. RAPS uses a collection of techniques and sensors to cleverly determine whether and when to turn on GPS. We evaluate RAPS through real-world experiments using a prototypeimplementationonamodernsmartphoneandshowthatitcanincreasephonelifetimesbymore thanafactorof3.8overanapproachwhereGPSisalwayson. xii Chapter1 Introduction Sensors are used to observe the physical world. Network of sensors can coordinate to perform more so- phisticatedsensingtasksthatthetraditionalsensingsystemscouldnothavedone. Networksofsensorscan alsocoverlargerarea,enabledenserinstrumentation,andprovidemorerobust,reliable,andefficientsens- ing. Researchinthisareahasdevelopedsensornetworkswhereembeddedwirelessnetworksareequipped withsensing,actuation,communication,andcomputationalcapabilities. Thesesensornetworkshavebeen deployed to monitor habitats [72, 106], micro-climates [108], agriculture fields [62], volcanoes [114], bridges [54, 85], buildings [82], and even human bodies [56]. Another kind of sensor networks where mobile phones carried by individuals act as participatory sensors have also been deployed to monitor the environment and the world around the participants [1, 76, 23, 33, 60]. Networks of sensors will provide a better understanding of the physical world, and also enable us to interact better with the environment surroundingus. However, these networks of sensors have several sources of dynamics which make it challenging to build robust and efficient systems. For example, the quality of wireless channel or the network topology canchangerapidlyeveninastationarynetwork. Thephysicalenvironmentaroundthesensorsorthetarget of sensing themselves might also have highly variable dynamics. Sensor network systems must adapt to thesedynamicswhileremainingefficient. Networksofsensorsmayneedtoadapthowtheysense,actuate, transmit,orevencoordinateamongthemselvestoadapttothenetworkandenvironmentaldynamics. Thus, 1 ourmainthemeofresearchinthisdissertationis“Rate-AdaptationinTheNetworksofWirelessSensors”. We explore how the concept of rate adaptation can be used to build sensing systems that adapt to the dynamics that they face. We design a rate-adaptive transport protocol on an architecture that respects the technological constraints of the embedded sensors, and also design a rate-adaptive sensing system that adapts to the environment and the behavior of the user. Specifically, within this underlying theme of rate-adaptation in networks of wireless sensors, we first propose an architecture for tiered embedded networks [84] on top of which we present a transport protocol that uses rate-adaptation to reliably and efficiently transport sensor data in wireless sensor networks [83]. Finally, we move to a different domain, mobile smartphones, and discuss how rate-adaptation can be used to provide energy-efficient location sensingbycoordinatingacollectionofsensors[86]. WefirstproposetheTenetarchitecturefortieredembeddedsensornetworks. Wearguethatanarchitec- turalprinciplethatpermitsmultinodedatafusiononsmall-form-factor,resource-poornodes,ormotesleads to fragile and unmanageable systems and explore an alternative. We therefore constrain the placement of application functionality according to the following Tenet Principle: Multi-node data fusion functionality andmultinodeapplicationlogicshouldbeimplementedonlyinthemastertier. Thecostandcomplexityof implementingthisfunctionalityinafullydistributedfashiononmotesoutweighstheperformancebenefits of doing so. The central thesis of this work is that the Tenet architectural principle simplifies application development and results in a generic mote-tier software that can be reused for a variety of applications, all without significant loss of overall system efficiency. Our primary intellectual contribution in this work is the design, implementation, and evaluation of a Tenet architecture that validates this thesis. In Tenet, sensornetapplicationsrunonmastersandmasterstaskmotesbycomposingtaskdescriptionsfromanovel taskletlibrary. OurTenetimplementationalsocontainsarobustandscalablenetworkingsubsystemfordis- seminatingtasksandreliablydeliveringresponses. Wehaveimplementedasuiteofqualitativelydifferent applications on Tenet, ranging from tracking and vibration monitoring to imaging and network manage- ment. WeshowthataTenetpursuit-evasionapplicationexhibitsperformancecomparabletoamote-native implementation while being considerably more compact. We also present two real-world applications of 2 Tenetsystem;structuralvibrationmonitoringatVincentThomasBridge,andimage-basedhabitatmonitor- ingatJamesReserve;andshowthattieredarchitecturescalesnetworkcapacityandallowsreliabledelivery of high rate data. Our evaluation of the individual components of Tenet reveals that Tenet’s task library cansupporthightaskthroughputandthatitsreliabledisseminationmechanismisfast. Moregenerally,our evaluation supports the thesis that the Tenet architectural principle can simplify application development andpromotecodereusewithoutmuchlossofefficiency. We next discuss RCRT, a rate-controlled reliable transport protocol suitable for constrained sensor nodes. RCRT is a protocol that ensures reliable delivery of sensor data from a collection of sensors to a base station, while avoiding congestion collapse. It is designed for loss-intolerant high-rate applications that need to reliably transport large volumes of data concurrently from several sensors. RCRT uses end- to-end explicit loss recovery, but places all the congestion detection and rate adaptation functionality in the sinks. Because sinks make rate allocation decisions, they are able to achieve greater efficiency since they have amore comprehensive view ofnetwork behavior. For thesame reason, itispossibletoalterthe rate allocation decisions without modifying sensor code at all. Also, RCRT employs a novel congestion detectiontechniquebasedontheconceptof‘time-to-recover-loss’. Ourdetailedevaluationof RCRT per- formance brings out many of its features: its ability to dynamically respond to congestion, its flexibility, robustness, and its support for multiple applications. More importantly, our evaluations show that RCRT achieves1.7timestherateachievedbyIFRCand1.4timesthatofWRCP,tworecentlyproposedapproach that implements decentralized congestion control but does not guarantee end-to-end reliability. We also presentresultsfroma3-month-longmoderate-sizedrealworlddeploymentofRCRTinanimagingappli- cation in which RCRT have collected 83 million packets with 100% reliability, and show that RCRT is capableofrunningrobustlyandefficientlyinlongtermrealdeployments. Finally, we present RAPS, rate-adaptive positioning system for smartphone applications. RAPS is a positioning system that provides accurate position information while spending minimal energy, and it is designedformanyemergingsmartphoneapplicationsthatrequirepositioninformationtoprovidelocation- basedorcontext-awareservices. ItisbasedontheobservationthatGPSisgenerallylessaccurateinurban 3 areas, so it suffices to turn on GPS only as often as necessary to achieve this accuracy. RAPS uses a collection of novel techniques to cleverly and cheaply determine whether and when to activate GPS. It uses the location-time history of the user to estimate user velocity and adaptively turn on GPS only if the estimated uncertainty in position exceeds the accuracy threshold. It also efficiently estimates user movement using a duty-cycled accelerometer, and utilizes Bluetooth communication to reduce position uncertainty among opportunistic neighboring devices. Finally, it employs celltower-RSS blacklisting to detect GPS unavailability (e.g., indoors) and avoid turning on GPS in these cases. Rather than merely considering each technique in isolation, we design a complete system that uses a collection of techniques in concert to reduce energy usage. We evaluate RAPS through real-world experiments using a prototype implementation on a modern smartphone and show that it can increase phone lifetimes by more than a factorof3.8overanapproachwhereGPSisalwayson,andabout1.9xlongerlifetimethanaperiodicGPS schemewithcomparableerrorrate. Ingeneral,ourevaluationisencouragingandsuggeststhat RAPS can obtainsubstantialenergysavingswithoutsacrificingtheaccuracyofperiodicGPS. This dissertation is organized as follows. In Chapter 2, we present the reivew of related work in the literature. InChapter3,wedescribetheTenetarchitecturefortieredembeddednetworks. Wefirstdiscuss thedesignprinciplesbehindthearchitecture,andthenpresentdetaileddesign,implementation,andevalu- ation of the Tenet architecture, along with several case studies based on real-world deployments of Tenet. InChapter4,wepresentRCRT.WediscussthedesigngoalsofRCRT,howRCRThasbeendesignedand implementedtomeetthosegoals,andadetailedevaluationofRCRT.InChapter5,wediscussRAPS.We discuss the main observation behind trading-off positioning accuracy for lower energy, and describe the keymechanismsthatenablesRAPStosignificantlyreducetheenergyspentforlocalizationinsmartphone applications. InChapter6,wesummarizeourworkanddiscussfuturework. 4 Chapter2 LiteratureReview Thisdissertationincludesthreerelatedbutdistincttopicsinthebroadfieldofwirelesssensornetworksand mobilesmartphones. Sooursurveyofrelatedworkisdividedintothreesectionsthatreviewseachofthese topics. We first review literature related to sensor network architecture, and then survey related works in congestioncontrolandreliabletransportforwirelesssensornetworks. Finally,wediscussliteraturerelated tosensingandlocalizationonmobilesmartphones. 2.1 SensorNetworkArchitecture In the earliest work on sensor network architecture, Estrin et al. [26] motivate the need for application- specific multinode aggregation within the network. More recently, [19] describe SNA, a software archi- tecture that describes the principles by which mote software and services are arranged. They also define the“narrowwaist”ofthearchitecturetobeatranslucentSensorProtocollayerthatexportsneighborman- agementandamessagepool,ontopofwhichseveralnetworkprotocolscanbebuilt[88]. Chameleon[21] goes a step further and provides a set of communication primitives that can accommodate variety of un- derlying protocols and mechanisms. Recently, Essentia [42] proposed “asymmetric function placement”, similar in spirit with Tenet, as a guiding principle to architect sensor network systems. It advocates that any nonessential functions should be implemented outside the sensor network to overcome the resource 5 constraintsofsensornodes. Tenetiscomplementarytothisbodyofwork,sinceTenetconstrainstheplace- ment of application functionality in a tiered system and does not address the modularization of software, thelower-layercommunicationprimitives,ortheplacementofapplication-independentfunctionality. The mote-tierinTenetcanbeimplementedusingSPorChameleon. TheTenetprinciplesharessomesimilaritieswiththeInternet’send-to-endprinciple[95]. Bothprinci- ples discuss the placement of functionality within a network, and in both cases the rationale for the prin- cipleliesinthetradeoffbetweentheperformanceadvantages obtainedbyembeddingapplication-specific functionality and the cost and complexity of doing so. However, the Tenet principle is not subsumed by, nor a corollary of, the end-to-end principle, since it is based on a specific technological trend (tiered networks). TheTenetprinciplesharessomesimilaritieswithActiveNetworks[107]. Specifically,theyaresimilar inthatpackets(called“capsules”inActiveNetworks)containcodethataredistributedandexecutedinthe network to process application-specific data. However, they differ because Active Networks do not limit applicationdatafusion,andplacesfew,ifany,constraintsonwhatcanbeexecutedwithinthenetwork. Many sensor network deployments in the recent past have been tiered. Examples include the Great DuckIslanddeployment[106],theJamesReserveExtensibleSensingSystem[40],andtheExtremeScal- ing Network [7]. In these deployments, tiering provides greater spatial scale and increased network ca- pacity. Other systems have been built upon tiered networks. SONGS [70] focuses on a set of high-level services designed to extract semantic information from a tiered network. Lynch et al. [59] discuss tiered networks for structural monitoring since upper-tier nodes can perform the sophisticated signal processing functions required for the application. [94] describe the design of a tiered network for increasing sensor network lifetime. Tenet, however, is an architecture for building applications for such networks quickly andeffectively. Severalpiecesofworkandhaveanalyticallyexaminedthebenefitsoftieredsystems. LiuandTowsley[68] show that if the number of masters exceeds the square root of the number of motes, a tiered network ex- hibits no capacity constraint. [74] describe a similar result for the lifetime of a tiered network. Finally, 6 [118] explore how the geometry of tiered deployments affects their lifetime and capacity. This line of researchshedssomelightontierednetworkplacementandprovisioning. Many of Tenet’s components are inspired by sensor network research over the last seven years. We nowdiscussthese. Mate[64,63]providesaframeworkforimplementinghigh-levelapplication-specificvirtualmachines on motes and for disseminating bytecode. A key observation of this work is that a fairly complicated action, such as transmitting a message over the radio, can be represented as a single bytecode instruction provided by an application-specific instruction set. Such an approach can greatly reduce the overhead in disseminating new applications and can simplify application construction. The trade off—as in Tenet— is expressiveness. To the extent that it disseminates and executes task instructions, Tenet defines a virtual machine. However,ourfocushasbeenlessonthemechanicsofbytecodedisseminationandexecution,and more on defining the right high-level instructions for sensor networks to carry out. ASVMs execute one high-level program at a time, although this program can contain multiple threads. Tenet motes explicitly support concurrent and independent application-level tasks. In this respect, Tenet also differs from tasks in SHARE [69], a system that allows applications on a wireless mesh network to express computation in the form of tasks, and optimizes task execution to eliminate or reduce repeated execution of overlapping taskelements. Tenet’smotesoftwarerunswiththeTinyOS[44]operatingsystemandiswritteninnesC[34]. TinyOS’ design choices (pushing as many decisions as possible to compile-time) have led to the development of an impressively stable and flexible runtime and library of drivers. However, static allocation is not the right model for dynamically invoked application-level tasks. Although our software runs on TinyOS, it makes widespread use of dynamic memory and function pointers. Tenet’s attribute-based data structures and processing chains are similar to Snack [37]. Also, Tenet’s tasking language has some resemblance to that of DSN [15]. However, DSN is intended for programming the lowlevel behavior of individual moteswhereasTenet’staskinglanguageisusedtoexpressapplication-leveltasksthatcanbedynamically disseminatedandexecutedatruntime. 7 Tenet, like many proposed macroprogramming techniques such as MacroLab [45], Pleiades [58], and Regiment[80],attemptstoprovideageneral-purposeprogrammingframeworkthatrelievesthecomplexity of distributed programming. However, Tenet achieves this goal by constraining mote-tier functionality, while macroprogramming approaches, in general, rely on compiler and runtime technology to provide higher-levelprogrammingabstractions. Toourknowledge,nopriorworkhasproposedorimplementedacompletenetworkingsubsystemfora tierednetwork,aswehave. Thecomponentsofthenetworkingsubsystembearsomeresemblancetoprior work,butareuniquelyinfluencedbyTenet’scommunicationpatternsandgenerality. TRD(TieredReliableDissemination,Section3.3.3.2)employssimilartechniques(exponentialtimers and suppression) as prior code dissemination protocols [65, 105, 46]. However, although all reliable dis- semination mechanisms employed for code dissemination assume a single sender (for obvious reasons), TRD supports multiple masters sending different tasks concurrently to all motes, and employs reliable floodingbothonthemasterandthemote-tiers. Second,reliablecodedisseminationdesignsareoptimized fortheparticularapplication;unlikeTRD’ssummaries,themetadatasummariesusedforlossrecoveryare specifictocodepages. Reliable data transport has received some attention in the literature. RMST [103] (Reliable Multi- Segment Transport) adds reliable transport on top of Directed Diffusion. RMST is a NACK-based proto- col in which loss is repaired hop-by-hop. However, unlike Tenet’s transport, it is tightly integrated with Diffusion, designed for larger and more capable platforms, and optimized for recovering losses of image fragments. PSFQ[111](PumpSlowly,FetchQuickly)isahop-by-hopreliabletransportprotocoldesigned forsensornetworkreprogramming,Wisden[117]isasystemforreliablytransportingstructuralvibration data from a collection of sensors to a base station, and DataRel [104] provides a TCP-like abstraction for transporting data from a mote to a border master in a tiered network. Finally, Flush [53] is a reliable bulk transport protocol that reduces transfer time by carefully controlling the rate at each hop along a flow, assuming that data collection is coordinated to allow only one flow in the network at a time. In contrast 8 Distributed Centralized No CongestionControl CongestionControl CongestionControl Reliable Flush,STCP,Hop RCRT Wisden,Tenet RMST Unreliable WRCP,IFRC, QCRA,ESRT Surge,CTP,RBC, Fusion,CODA CentRoute,Koala Table2.1: SensorNetworkTransportProtocols: ATaxonomy tothesesystems,Tenet’sreliabletransportensurespoint-to-pointdeliveryofprocessedsensordatafroma motetoanymasterinatierednetwork. Most prior routing protocols either support data delivery to a base station [89, 116] or to multiple sinks [40]. Some, such as Centroute [104], also centrally compute efficient source routes to individual motes on demand, supporting unicast traffic from a base station to a mote. Tenet’s routing system, in contrast,supportsunicasttrafficfromamotetoanymasterinthetierednetwork,andbuildsroutingentries fortrafficinthereversedirectioninadata-drivenfashion. 2.2 CongestionControlandReliableTransport To place our work in context, we taxonomize sensor network transport protocols as shown in Table 2.1. We distinguish transport protocols by whether they provide end-to-end reliability or not, whether they implement congestion control or not, and if they do, whether the congestion control implementation is distributedorcentralized(atasink,forexample). AsTable2.1shows, RCRT is,tothebestofourknowl- edge,theonlyinstanceofareliabletransportprotocolthatimplementscongestioncontrolinacentralized manner. Furthermore,toourknowledge,althoughthereisalargeliteratureoncongestioncontrolinwired and wireless networks, this specific problem has not been addressed in those contexts. However, many of our individual design decisions draw from that literature; we cite the relevant pieces of work when we describethedetaileddesignof RCRT inSection4.2. WenowdiscusseachelementofTable2.1inturn. The simplest transport protocols are those that do not guarantee end-to-end reliability, and implement no congestion control. Surge (TinyOS) and CTP [35] can be thought of as implementing such a simple transportprotocol. CentRoute/DataRel[104]centrallycomputesefficientsourceroutestoindividualmotes 9 on demand and provides a TCP-like abstraction for transporting data from a mote to a nearest gateway in a tiered network. It implements a fixed number of end-to-end retransmissions to improve reliability, but does not incorporate congestion control. RBC [120] is a hop-by-hop reliable transport scheme optimized for real-time many-to-one delivery of bursty event data, and uses retransmission scheduling to increase reliabilityandreducelatency. Koala[79]isadataretrievalsystemoptimizedforbulkdatadeliveryatlow dutycycles. InKoala,thegatewayinitiatesbulkdeliverybywakingupandinstallingroutingpathsonthe motes dynamically. However, neither RBC nor Koala was designed for continuous flows, and they do not guaranteeend-to-endreliability. Next come the class of transport protocols that provide end-to-end reliability, but implement no con- gestioncontrol. RMST(ReliableMulti-SegmentTransport)[103]andthetransportprotocolimplemented in Wisden [117] and Tenet [84] are examples of such protocols. RMST is a hop-by-hop reliable transport protocol built on top of Directed Diffusion [49] in which loss is repaired hop-by-hop using caches in the intermediatenodes. RMSTguaranteesreliability,butitisdesignedforlargerandmorecapableplatforms. Wisden’s transport protocol (Tenet’s is very similar) provides end-to-end reliability of sensor data trans- mitted from a field of sensors to a single sink. However, in both these systems, the rate at which this data istransmittedbyanodemustbemanuallysetbyasystemadministrator. Some research has examined centralized congestion control without end-to-end reliability guarantees. QCRA [9] (Quasi-static Centralized Rate Allocation) is a centralized rate allocation scheme that tries to achieve fair and near-optimal rate allocation for each node given the topology, routing tree, and link loss rate information. ESRT (Event-to-Sink Reliable Transport) [96], is also a centralized rate control scheme for event-driven applications where the base station requests all source nodes to increase or decrease rate inordertoachievethedesiredeventreliability. ButESRTassumesthatthesinkcancommunicatewithall sourcesinonehop,andhasonlybeenevaluatedinsimulation. Thereisabodyofworkthathasdesigneddistributedcongestioncontrolschemeswithoutregardtoend- to-endreliability. IFRC(Interference-awareFairRateControl)[92]isadistributedrateallocationscheme thatusesqueuesizetodetectcongestion,sharesthecongestionstatethroughoverhearing,andconvergesto 10 fairandefficientratesforeachnode. EventhoughIFRCdoesnotprovideend-to-endreliability,itisclosest in spirit to our work in that it attempts to find a fair and efficient transmission rate that avoids congestion collapse. WequantitativelycompareIFRCandRCRTinalatersection,butnotethata)RCRThasgreater flexibilitythanIFRCsincemanydifferenttrafficallocationpoliciescanbeimplementedintheRCRTsink without changing any code at the sensor nodes, and b) RCRT does not require sophisticated parameter tuning for stability as IFRC does. WRCP (Wireless Rate Control Protocol) [102] is another recently proposeddistributedratecontrolschemethatusesanestimateofreceivercapacityandestimatesofactive flow counts to allocate fair rates to each node. It does not provide end-to-end reliability, and RCRT is more flexible and requires less parameter tuning than WRCP as well. Although WRCP converges faster to a less oscillatory rate allocation than IFRC, RCRT achieves better goodput than WRCP. Also different fromRCRTisworkoncongestionmitigation: Fusion[47]useshop-by-hopcongestioncontrolandCODA (Congestion Detection and Avoidance) [112] uses end-to-end flow control along with hop-by-hop back- pressureforthispurpose. Finally,someworkhasexamineddistributedcongestioncontrolofend-to-endreliabletransport. STCP[50] proposestouseRED[30]-stylecongestiondetectioninsensornodesandaslightlymodifiedformofTCP end-to-end. To our knowledge, STCP has not been evaluated on a real wireless testbed. By contrast, Flush [53] is a reliable transport protocol designed for large diameter sensor networks. Unlike in RCRT, at any instant at most one node can transport its data to the sink using Flush. Also, Hop [66] is a recently proposed wireless transport protocol that uses reliable per-hop block transfer and backpressure flow con- trol. Iteliminatestheoverheadandlatencyinvolvedinend-to-endcontrol,butitisdesignedforlargerand morecapableplatformswithsufficientmemory. NotincludedinthetaxonomydescribedinTable2.1areprotocolsforreliabledissemination. PSFQ[111], Deluge [46], and TRD [84] are reliable dissemination protocols designed for reprogramming or retasking the sensor network from a base station, and not for transport of data in the other direction. Also omitted from Table 2.1 is prior work on congestion sharing in wired networks (for example, Ensemble-TCP [22], 11 andIntegratedCongestionManagementArchitecture[8]). Theseproposals,thoughnotdirectlyapplicable tosensornetworks,bearsomeresemblanceto RCRT’scentralizedcongestioncontrol. 2.3 EnergyEfficientLocalizationonMobileSmartphones A few prior pieces of work have attempted to duty-cycle location determination. The piece of work most closely related to ours is EnTracked [55] 1 . It uses the accelerometer as a binary sensor to distinguish between stationary and in-motion users, and determines user velocity from the estimate reported by GPS. Based on this estimation of mobility, it schedules the next position update to save energy. However, it does not leverage user history nor does it employ the concept of activity ratio as a surrogate for velocity, as we do. It also does not consider the high power consumption of the accelerometer, nor infer GPS availabilityusingcelltowerinformation,anditdoesnotadapttomovementchangesuntilthenextdecision point. Moreover,thesystemhasaninherentcircularitywhichcanpotentiallydegradeperformance: ituses a velocity estimate to decide when to turn on GPS, but also uses GPS to get the velocity estimate. Most importantly, it does not consider the case where GPS is not available (e.g., indoors), and the system has beenevaluatedonlyinscenarioswhereGPSisalwaysavailable. Someworkhasexploredtheenergy-accuracytradeoffinwaysdifferentfrom RAPS.EnLoc[18]uses dynamic programming to find the optimal localization accuracy for a given energy budget and decides which one of GPS/WiFi/GSM localization methods to use. It uses the space-time history in its human mobility profile, but does not associate this with the accelerometer-based user activity. Micro-Blog [33] exploits the accuracy-energy tradeoff of GPS, WiFi, and GSM based localization for energy-aware local- ization. Specifically, depending on the accuracy requirement of the application, it uses a lower energy method over a higher method when possible. Contemporaneously, a-Loc [67] proposes to dynamically trade-off location accuracy and energy use, using probabilistic models of user location and sensor errors. It uses these models to choose among different localization methods and tune the energy expenditure to 1 As of this writing, the code for EnTracked is not publicly available. So, we present only a qualitative comparison with this scheme. However, both protocols have compared their performance relative to the case when GPS is always on, so the reader can assesstherelativeperformancedifferencebetween RAPS andEnTracked. 12 meet the dynamic location accuracy requirements specified by applications. It also discusses a method to automatically determine the accuracy requirements for certain applications such as mobile search and so- cial networking. Incontrast toall thesepieces ofwork, RAPS leverages theobservation that applications will need to tolerate intrinsic GPS errors in urban obstructed environments in order to trade-off accuracy forlowerenergy. We have also built upon other duty-cycle determination methods. You et al. [119] propose a signal- strength based indoor localization scheme that adapts the sampling rate to the target’s estimated mobility level for energy-efficient operation. This work uses a positioning error model similar to ours and also employs the accelerometer to detect whether the target is stationary or not. However, unlike RAPS, it is tailored for RF-based indoor localization and assumes walking as the only mobility mode. Farrell et al. [27] also use a similar positioning uncertainty model and propose an algorithm that controls when to perform GPS updates for efficient positioning. However, they do not estimate velocity but simply assume a maximum walking velocity for uncertainty calculation. Moreover, this work has been evaluated only in simulations. There are several pieces of work that are related to individual components of RAPS. Deblauwe and Treu [20] propose GSM signature-based triggering to avoid activating the GPS receiver for as long as possible in order to save energy while still being able to detect entering and leaving a zone. Their basic ideaistocomparethedevice’scurrentGSMmeasurementswiththeonestakenthelasttimetheGPSwas switched on. This work is based on a similar intuition as ours, but assumes that cellId-RSS information from several celltowers are available at the smartphone, which, as we have discussed, contradicts current practice. SenseLess [4] uses accelerometer triggering to detect the existence of user movement and turns offGPSwhennotmoving,andreportsthatthiscanbeeffectiveinreducingthenumberofGPSactivations. EEMSS[113]employstheideaofusinglowpowersensors(i.e.theaccelerometer)todetectuserstateand context, and trigger activation of high power sensors (i.e. GPS) only if necessary. While doing this, they duty cycle each sensor to further save energy. Concurrent with our own work, Zhuang et al. [122] have 13 proposed a location-sensing framework that includes four design principles – accelerometer-based sup- pression, location-sensing piggybacking, substitution of location-sensing mechanisms, and adaptation of sensingparameterswhenbatteryislow–toimprovetheenergyefficiency oflocalizationonsmartphones thatrunmultiplelocation-basedapplications. Several pieces of work have attempted to learn mobility patterns. BreadCrumbs [81] uses the space history of a user to train a mobility model for each specific user and use it to schedule network usage using the connectivity forecasts. Zheng et al. [121] use supervised learning to infer motion modes (e.g., walking, bus, driving) from their GPS logs. Sohn et al. [100] also recognizes mobility modes, but using coarse-grained GSM data instead of GPS data. Although RAPS does not explicitly infer users’ motion modesusingGPSorGSMlogs,itestimatesuservelocity(whichisafunctionofthemobilitymode). Finally,severalotherattemptshavebeenmadetoaddressshortcomingswithGPS.PureWiFi-based[2, 115] and GSM-based [110] systems attempt to save energy by inferring location using other means. In contrast, RAPS focuses only on adapting the rate of GPS activations and can, in theory, be incorporated intothesesystems. 14 Chapter3 TheTenetArchitectureforTieredSensorNetworks Most sensor network research and software design has been guided by an architectural principle that per- mits multinode data fusion on small-form-factor, resource-poor nodes, or motes. While we were among theearliestpromotersofthisapproach,throughexperiencewefoundthatthisprincipleleadstofragileand unmanageablesystemsandexploreanalternative. TheTenetarchitecture[84]ismotivatedbytheobserva- tionthatfuturelarge-scalesensornetworkdeploymentswillbetiered,consistingofmotesinthelowertier and masters, relatively unconstrained 32-bit platform nodes, in the upper tier. Tenet constrains multinode fusion to the master tier while allowing motes to process locally-generated sensor data. This simplifies applicationdevelopmentandallowsmote-tiersoftwaretobereused. Applicationsrunningonmasterstask motesbycomposingtaskdescriptionsfromanoveltaskletlibrary. OurTenetimplementationalsocontains arobustandscalablenetworkingsubsystemfordisseminatingtasksandreliablydeliveringresponses. We show that a Tenet pursuit-evasion application exhibits performance comparable to a mote-native imple- mentation while being considerably more compact. We also present tworeal-world deployments of Tenet system: a structural vibration monitoring application at Vincent Thomas Bridge and an imaging-based habitatmonitoringapplicationatJamesReserve,andshowthattieredarchitecturescalesnetworkcapacity andallowsreliabledeliveryofhighratedata. 15 3.1 Introduction Research in sensor networks has implicitly assumed an architectural principle that, in order to conserve energy, it is necessary to perform application-specific or multinode data fusion on resource-constrained sensor nodes as close to the data sources as possible. Like active networks [107], this allows arbitrary applicationlogictobeplacedinanynetworknode. Asitsfirstproposersputit: Application-Specific. Traditionalnetworksaredesignedtoaccommodateawidevarietyofapplications. We believe it is reasonable to assume that sensor networks can be tailored to the sensing task at hand. In particular, this means that intermediate nodes can perform application-specific data aggregation and caching, or informed forwarding of requests for data. This is in contrast to routers that facilitate node- to-nodepacketswitchingintraditionalnetworks.[26,Section2] Thisprinciplehasgovernedthedesignofdata-centricroutingandstorageschemes[48,93],sensornetwork databases [71], programming environments that promote active sensor networks [63], and a flexible yet narrow-waistednetworkingstack[88]. The principle can minimize communication overhead, but at what cost? In our experience, the major costsareincreasedsystemcomplexityandreducedmanageability. Systemsarehardtodevelopanddebug since application writers are expected to implement sophisticated application-specific routing schemes, and algorithms for multinode fusion, while contending with mote-tier resource constraints. Adherence to this principle is the main reason why there is currently a significant dichotomy between sensor network deploymentsandresearchsystems: manyofourexistinglong-liveddeploymentsarerelativelysimpledata collectionsystemsthatincorporatenomultinodedatafusion. We examine here a different point in the space of possible architectures, motivated by a property common to many recent sensor network deployments [40, 106, 7]. These deployments have two tiers: a lower tier consisting of motes 1 , which enable flexible deployment of dense instrumentation, and an upper tier containing fewer, relatively less constrained 32-bit nodes with higher-bandwidth radios, which 1 In this dissertation, we use the term mote broadly to denote a class of sensing devices that for reasons of power, form factor, or price have constrained processing, memory, and communication resources. Such devices are thus incapable of efficiently providing theflexibility,visibility,androbustnessofPC-classembeddeddevices. 16 wecallmasters. Tiersarefundamentaltoscalingsensornetworksizeandspatialextent,sincethemasters collectively have greater network capacity and larger spatial reach than a flat (non-tiered) field of motes. Furthermore, masters can be and usually are engineered to have significant sources of energy (a solar paneland/orheavy-dutyrechargeablebatteries). Forthesereasons,mostfuturelarge-scalesensornetwork deploymentswillbetiered. 2 Future systems could take advantage of the master tier to increase system manageability and reduce complexity, but simply porting existing software to a tiered network would only partially realize these gains. We seek instead to aggressively define a software architecture for tiered embedded networks, one that prevents practices that we believe reduce manageability, even at the cost of increased communication overhead. We therefore constrain the placement of application functionality according to the following Tenet Principle: Multi-node data fusion functionality and multinode application logic should be implemented only in the master tier. The cost and complexity of implementing this functionality in a fully distributed fashion on motes outweighs the performance benefits of doing so. Since the computation and storage capabilities of masters are likely to be at least an order of magnitude higher than the motes at any point inthetechnologycurve,mastersarethemorenaturalcandidatesfordatafusion. Theprincipledoesallow motes to process locally-generated sensor data, since this avoids complexity and can result in significant communication energy savings. This architectural constraint could be relaxed if required, of course, but aggressivelyenforcingitmostclearlydemonstratesthecostsandbenefitsofourapproach. The central thesis of this work is that the Tenet architectural principle simplifies application develop- ment and results in a generic mote-tier networking subsystem that can be reused for a variety of applica- tions, all without significant loss of overall system efficiency. Our primary intellectual contribution is the design,implementation,andevaluationofaTenetarchitecturethatvalidatesthisthesis. 2 Tiering does not imply physical clustering. In the most general definition of a tiered network, a mote can communicate with more than one master, possibly over multiple mote-hops. However, a mote may not have multihop connectivity to all masters in the network. 17 In Tenet, applications run on one or more master nodes and task motes to sense and locally process data. Conceptually, a task is a small program written in a constrained language. The results of tasks are delivered by theTenet system totheapplication program. This program can thenfusethereturned results and retask the motes or trigger other sensing modalities. More than one application can run concurrently onTenet. OurTenetsystemadherestotheTenetarchitecturalprinciplebyconstrainingmotefunctionality. Allcommunicationtothemote-tierconsistsoftasks,andallcommunicationfromthemote-tierconsistsof taskresponses(suchassensordata)destinedforamaster,soapplicationssimplycannotexpressmote-tier multinodefusioncomputation. Tenet has several novel components. Using our simple yet expressive tasking language, applications specifyataskasalineardataflowprogramconsistingofasequenceoftasklets. Forexample,anapplication thatwantstobenotifiedwhenthetemperatureatanymoteexceeds50 ◦ Fwouldwriteataskofthefollowing form. Sample(1000ms, 1, REPEAT, ADC10, TEMP) -> LEQ(A, TEMP, 50) -> DeleteActiveTaskIf(A) -> Send() A task library implements a collection of composable tasklets. A reliable multitier task dissemination protocol ensures highly robust, rapid delivery of tasks from the master tier to the motes. Since different applications may need different levels of reliability for transmitting data back to the application, Tenet implements three qualitatively different data transport mechanisms. Finally, a routing subsystem ensures robust connectivity between the tiers; it creates routing table entries in a data-driven fashion in order to reduceoverhead. Tenet has been implemented for networks with MicaZ or TelosB in the mote-tier 3 and 32-bit devices such as Stargates or PCs in the master tier. We have implemented a suite of qualitatively different appli- cations on Tenet, ranging from tracking and vibration monitoring to imaging and network management. Each of these applications is tens of lines of code, and requires no modifications to the rest of the Tenet system. 3 TenetalsosupportsMica2andMica2dotinthemote-tieralthoughlessevaluationhasbeendoneonthoseplatforms. 18 We have extensively experimented with pursuit-evasion, a particularly challenging application for Tenet since existing implementations deeply rely on multinode data fusion for efficiency [97]. In pursuit- evasion, one or more mobile pursuer robots track and attempt to “capture” one or more evaders with the help of a sensor network. We compared a Tenet implementation with a more traditional one which incorporates mote-tier multinode fusion to reduce redundant evader reports [97]; our Tenet implementa- tion exhibits higher accuracy and lower overhead than mote-PEG at the cost of marginally higher evader detectionlatency. We have also successfully deployed two qualitatively different Tenet applications in the real world; structural vibration monitoring at Vincent Thomas Bridge, and image-based habitat monitoring at James Reserve. OntheVincentThomasBridge,atieredsensornetworkrunningTenetreliablycollectedambient vibrationofthestructureataratewhichwouldhavebeendifficulttoachieveonaflatnetworkofmotes. At JamesReserve,image-sensors(Cyclopscameras[90])wereusedtomonitoranddeliverimagesofanimal trapoccupancy,simplifyingthelivesofbiologists. ThesedeploymentssuggestTenetisflexibleenoughto implementavarietyofrealapplications. Our evaluation of the individual components of Tenet reveals that Tenet’s task library can support hightaskthroughputandthatitsreliabledisseminationmechanismisfast. Moregenerally,ourevaluation supportsthethesisthattheTenetarchitecturalprinciplecansimplifyapplicationdevelopmentandpromote codereusewithoutmuchlossofefficiency. 3.2 TheTenetPrinciple The Tenet architectural principle moves aggressively away from prevailing practice and prohibits in-mote multinode sensor data fusion. It constrains the processing of data received from multiple sensors to be placed at the master tier, regardless of whether this processing is specific to an application or can be expressedasagenericfusionservice. (Itmight, forexample, bepossibletocastbeamformingortracking asagenericservicethatcanbeusedbymanyapplications.) Thishastwoadvantages. First,sincemasters 19 have more processing and storage resources, applications can perform more sophisticated fusion than is possible with the motes. Second, masters can use their high-capacity network to exchange data spanning alargespatialextent,givingfusionalgorithmsmorecontextintosensedphenomenaandresultinginmore accuratedecisions. The trade-off is, of course, a potential loss of efficiency which comes in three forms. The first is the opportunity cost of in-mote multinode fusion. For most applications that we have encountered, there is significanttemporalredundancy,butlittlespatialredundancy(inalmostalldeployments,weundersample spatially). SinceTenetallowsmotestoprocesslocally-generated sensordata(thislocalprocessingiscru- cial, since it is clearly infeasible to collect time-series data from every sensor in a large sensor network), applications can remove temporal redundancy and recover most of the gains from in-mote multinode fu- sion. Another, smaller, cost is that processed sensor data needs to be routed over multiple hops from a mote to the nearest master. We argue that even this cost is negligible, since the network diameter in a well-designedsensornetworkwillbesmall;wirelesslossratesbeingwhattheyare,largediametersensor networks will be inefficient [39]. The third cost is that in-mote fusion can reduce congestion inside the network. Forinstance,inpursuit-evasion,leaderelectionwithinaone-hopneighborhoodresultsinasingle evader detection being transmitted; since Tenet does not permit such fusion, it can potentially incur the bandwidth costoftransmittingmultipledetections tomasters. However, asweshowinSection3.4, Tenet can avoid this by adaptively setting task parameters so that only nodes having a high-confidence evader detectionneedtransmittheirvaluestoamaster. Will the Tenet principle hold when mote processing power, memory, and communication capabilities evolve significantly? The principle simplifies the management and control of constrained motes, and we expect that, for reasons of price, form factor, or battery capacity, motes will continue to be impoverished, relativetomasters,fortheforeseeablefuture. Inabsoluteterms,moteswillbecomemorecapablecompu- tationally, and possiblywithrespect tomemory. However, inabsolute terms, at leastinthelastfew years, wehavenotseenconcomitant growthinbatterylifeorwirelesscommunication capability. Thus,wecon- tendthatthisarchitecturalseparationwillcontinuetomakesense,sinceotherwiseprogrammerswillhave 20 to deal with communication and battery life constraints. Moreover, as technology evolves, we will also want to do more with sensor networks (e.g., sense more complex signals, etc.), and we see these relative constraints as continuing to dictate the architectural separation. Even if the technology were to evolve to thepointwheremoteconstraintsdidnotmatter,ourTenetimplementationwouldstillbeaviable,flexible programming system for a distributed system of sensors, as our implementations of different applications show. 3.3 TheTenetSystem Inthissection,wefirstdescribeasetofdesignprinciplesthatguidedthedevelopmentoftheTenetimple- mentation. Wethendescribe,insomedetail,thetwomaincomponentsofTenet,itstaskingsubsystemand itsnetworkingsubsystem. WeconcludewithadiscussionofthelimitationsofourcurrentTenetprototype, motivatingdirectionsforfuturework. 3.3.1 DesignPrinciples The Tenet architectural principle constrains the design space for sensor network architectures, but is not itselfanarchitecture. OurTenetsystemisbasedontheTenetprincipleandthefiveadditionaldesignprin- ciples described here. Again, we define these principles aggressively, since this will show when violating theprinciplesisnecessaryfornetworkperformanceorfunctionality. The Tenet principle prohibits multinode fusion in the mote-tier. The precise form of this prohibition is expressed as restriction on sensor network communication, which must take the form of Asymmetric TaskCommunication: Anyandallcommunicationfromamastertoamotetakestheformofatask. Any and all communication from a mote is a response to a task; motes cannot initiate tasks themselves. Here, a “task” is a request to perform some activity, perhaps based on local sensor values; tasks and responses are semantically disjoint. Thus, motes never communicate with (send sensor data explicitly directed to) 21 another mote. Rather, masters communicate with (send tasks to and receive data from) motes, and vice versa. The second principle expresses the Addressability properties of a Tenet network: Any master can communicate with any other master as long as there is (possibly multihop) physical-layer connectivity between them; any master can task any mote as long as there is (possibly multihop) physical-layer con- nectivitybetweenthem;andanymoteshouldalwaysbeabletosendataskresponsetothetaskingmaster. This principle helps enforce high network robustness and a relatively simple programming model. For example, imagine that a mote A is connected one-hop to a master M, but could be connected to a differ- ent master, M ′ , via three hops. The addressability principle requires that, if M fails, A will learn about M ′ and be able to send responses via M ′ , and vice versa. The requirement to support master-to-master communication allows, but does not require, the construction of distributed applications on the masters. Addressability requires much less of motes, however; a mote must be able to communicate with at least onemaster(assumingthenetworkisnotpartitioned),notallmasters,andmote-to-moteconnectivityisnot required. Thisisbydesign,andgreatlysimplifiesmoteimplementations. The third Task Library principle further defines what tasks may request of a mote: Motes provide a limitedlibraryofgenericfunctionality,suchastimers,sensors,thresholding,datacompression,andother formsofsimplesignalprocessing. Eachtaskactivatesasimplesubsetofthesefunctionality. Atasklibrary thatsimultaneouslysimplifiesmote,master,andapplicationprogrammingwhileprovidinggoodefficiency isakeypieceoftheTenetarchitecture. Wediscussthedesignofthetasklibraryshortly. Finally, Robustness and Manageability are primary design goals. Robust networking mechanisms, whichpermitapplicationoperationeveninthefaceofextensivefailuresandunexpectedfailuremodes,are particularly important for the challenging environments in which sensor networks are deployed. Manage- abilityimplies,forexample,thattoolsinthetasklibrarymustprovideusefulinsightintonetworkproblems (suchaswhyaparticularsensororgroupofsensorsisnotresponding,orwhynodeenergyresourceshave beendepletedfarfasterthanonewouldhaveexpected)andallowautomatedresponsetosuchproblems. 22 Threeimportantadvantagesarisefromthesedesignprinciples. First,applicationsexecuteonthemas- ter tier, where programmers can use familiar programming interfaces (compiled, interpreted, visual) and differentprogrammingparadigms(functional,declarative,procedural)sincethistierisrelativelylesscon- strained. Second, the mote-tier networking functionality is generic, since Tenet’s networking subsystem merelyneedstorobustlydisseminatetaskdescriptionstomotesandreliablyreturnresultstomasters. This enablessignificantcodereuseacrossapplications. Finally,motefunctionalityislimitedtoexecutingtasks andreturningresponses,enablingenergy-efficientoperation. 3.3.2 TasksandtheTaskLibrary When developing a language for describing tasks, the key trade-off faced is between expressiveness and simplicity. Conventional Turing-complete languages place few or no restrictions on what a programmer mayrequestamotetodo,butmaketaskserrorprone,hardtounderstand,andhardtoreuse. Tenetchoosessimplicityinstead. ATenettaskiscomposedofarbitrarilymanytaskletslinkedtogether in a linear chain. Each tasklet may be thought of as a service to be carried out as part of the task; tasklets expose parameters to control this service. For example, to construct a task that samples a particular ADC channelevery500msandsendsgroupsoftwentysamplestoitsmasterwiththetagLIGHT,wewrite Sample(500ms, 20, REPEAT, ADC0, LIGHT) -> Send() orequivalently, Repeat(500ms) -> Sample(ADC0, LIGHT) -> Pack(LIGHT, 20) -> Send() Tenetrestrictstaskstolinearcompositionsoftaskletsforsimplicityandeaseofconstructionandanal- ysis, another example of an aggressive constraint. Tasks have no conditional branches or loops, although certain tasklets provide limited versions of this functionality. For example, a tasklet within a task may repeat its operation. Also, a tasklet may, depending on its parameters, ignore or delete certain inputs or terminate its execution, implementing a constrained conditional. (Appendix A lists all of Tenet’s current setoftasklets,andAppendixBprovidesbriefinstructiononhowtousethesetaskletstocomposetasks.) 23 Tenet’stasklibrarywasinspiredbyourownpriorworkonSNACK[37]andVanGo[38],andsomewhat resembles other sensor network tasking architectures [69]. It can also be seen as a particular instantiation of a virtual machine [64]. However, rather than allow application-specific VMs, we have worked to make this VM flexible, general, high level, and efficient enough to support easy programming and tasking from masters. 3.3.2.1 TaskBuildingBlocks The tasklets in the Tenet task library provide the building blocks for a wide array of data acquisition, processing, filtering, measurement, classification, diagnostic, and management tasks. For example, the Get() tasklet collects a variety of information from the system such as routing state or statistics on dynamic memory usage, while the Issue() tasklet controls when a task should be initiated either by delayingthesubsequenttaskletsonataskchainuntilaspecifiedtimeorbyinitiatingataskperiodicallyat agiveninterval. Thedifficultyinconstructingsuchalibraryisindeterminingwhattherightbuildingblocksshouldbe. The Reboot() tasklet should, of course, reboot the node. But what should Sample() do? Should it know how to be periodic? Should it know how to pack several samples into a packet? Also, should we makeoneArith()tasklet? orshouldweseparateAdd()andSubtract()tasklets? Ourguidingprincipleisthattaskletsshouldprovideasmuchfunctionalityaspossible,whilestillbeing easy to use and reuse. So, Sample() knows how to repeat and collect blocks of samples because this level of functionality is still easy to control (the parameters to Sample() are intuitive) and it is still fairly efficient. (A Tmote mote can manage the state of roughly 100 Sample() tasklets even with its limited RAM.) Also, Arith() can perform add, subtract, multiply, etc., because it only requires one extraparameter,OP TYPE,whileavoidingreplicationofcode. Our guiding principle can result in tasklets with many parameters. To simplify programming these tasklets, Tenet provides the user with a rich set of easy-to-use master-side tasklet APIs (Appendix A). 24 Figure3.1: Motedatastructuresforatypicaltask. TheseAPIsaretranslatedattheTenetmasterintotheappropriatetaskletssupportedatthemote. Forexam- ple,theAdd()andSub()master-sidetaskletsareequivalenttoArith(ADD)andArith(SUBTRACT) respectively,andNextHop()isidenticaltoGet(NEXT HOP).Thisapproachincursnooverheadonthe motes, since the translation is performed at the task parser on the master. Furthermore, it enables a sim- pler, more user-friendly, and less error-prone API, and makes it easier to statically analyze tasks on the master-sideforparametervalidityandusage. 3.3.2.2 TheTaskDataStructure Figure3.1presentsthetaskdatastructuresfromtheperspectiveofamote. Ataskexecutingonamotehas two parts: a task object maintains the tasklet chain, and one or more active containers hold intermediate andfinalresultsoftaskprocessing. The task object includes a task ID and a list of tasklets with their corresponding parameters. During installation each tasklet’s constructor is called, passing any parameters specified by the master; the con- structor returns to the task object these parameters, pointers to methods to run and delete the tasklet, and any needed tasklet state. Finally, a new active container is created that points at the first tasklet in the chain. Theunderlyingschedulerwillsoonstarttaskprocessingbypassingthisactivecontainertothefirst tasklet. An active container corresponds to an instance of a task whose processing is in progress. The active container moves from tasklet to tasklet, being processed by each in turn. Once it reaches the end of the 25 chain of tasklets, it is deleted. An active container maintains a pointer to its task object and an index specifying where it is currently in the task object’s linear chain of tasklets. A repeating tasklet clones the activecontaineraftereachiteration. Forexample,whileexecutingthetask Repeat(1000ms) -> LocalTime(X) -> Send() anactivecontainerisclonedandemittedfromtheRepeat()taskletevery1000ms. Thus,theremaybe severalactivecontainersassociatedwiththesametaskinthesystematthesametime. An active container also holds a bag of attributes, containing all data resulting from task execu- tion. Each attribute is simply the tuplehtag,length,valuei. For example, in the preceding task, the LocalTime()taskletaddsanattributewiththetagXtothebag. Ingeneral,taskletsnametheirinputandoutputdatatypesexplicitlyusingthesetags. Thus Sample(10000ms, 1, REPEAT, ADC_LIGHT, X) -> LEQ(Y, X, 39) -> DeleteActiveTaskIf(Y) -> LocalTime(Z) -> Send() willsendtimestampedlightvaluesonlywhentheirvaluesaregreaterthan39. (Theactualimplementation isdonebydeletingtheexecutionofcurrentinstanceifthelightvalueislessthanorequalto39). Itisupto thetaskcomposertoverifythatthedatatypespecifiedasinputtoantaskletiscompatiblewiththattasklet. Allstateassociatedwithataskismaintainedbythattask. Tasksandtaskletsaredynamicallyallocated. Since tasks arrive unpredictably, it is impractical to statically plan memory allocation for them; dynamic allocationimprovessystemefficiencybyprovidingawaytoallocatememoryresourcesonlywhereneeded. 3.3.2.3 MoteRuntime TheTenetmoteruntimeprovidesasetoftask-awarequeuesforwaitingonhardwareresources. Eachqueue is owned by a service corresponding to a particular tasklet. For example, the Issue() tasklet, which implements the Wait() and Repeat() API’s, delays a task for a period of time. Its corresponding 26 time service maintains a queue where tasks may reside until it is time for them to proceed. Likewise, the Sample()servicemaintainsaqueueoftaskswaitingfortheADCresource. 4 At the heart of the system is the Tenet scheduler. It maintains a queue of tasks waiting to use the mote’s microcontroller. The scheduler operates at the level of tasklets, and knows how to execute the task’staskletsinorder. Sinceitoperatesatthislevelofgranularity(asopposedtoexecutingeachcomplete taskoneatatime),severalconcurrentlyexecutingtasksmaygetfairaccesstoamote’sresources. 3.3.2.4 TaskOperations The task description disseminated from a master to its motes contains, in serialized form, a task identifier and the list of tasklets that comprise this task. Each tasklet encodes its name (from a well-known enum) anditsparametersasatag-length-valueattribute. Motes accept two operations on tasks: installation and deletion. When a mote receives a task descrip- tion from a master containing a task ID that is not currently installed, the mote concludes that this task should be installed. An empty description with currently installed task ID is interpreted as a request to destroy a running task. To delete a task, all active containers corresponding to that task are found and destroyed(theymaybehidinginanytasklet’sassociatedserviceorinthescheduler),followedbythetask objectitself. 3.3.2.5 OSDependencies The Tenet task library was implemented on top of TinyOS, but we follow very few of the programming patterns of that operating system. The advantage to using TinyOS is in the robustness and availability of its drivers. The chief drawback is that we cannot dynamically load software libraries at runtime; thus, all taskletsanapplicationmightrequiremustbecompiledintoasinglebinary. Inthefuture,wemayconsider OSesthatrelaxthisrestriction[41],allowingrequiredtaskletstobefetchedfromamasterdynamically. 4 Arbitrationbetweentaskletsthatusethesameresourceisimportant. Weexpecttheunderlyingsystem(e.g.,TinyOS)toprovide thisfunctionality. 27 Tasklets Description ROM RAM Actuate Actuatespecifiedactuationchannel 272 0 Arith Arithmeticoperationonattributedata 592 0 Attribute Checkexistence/non-existence ofanattribute 202 0 Bit Bitwiseoperationonattributedata 496 0 Comparison Comparisonoperationonattributedata 558 0 Count Incrementsacounter 122 0 DeleteActiveTaskIf Deletesanactivetask,possiblyconditional 152 0 DeleteAttributeIf Deletesattribute(s),possiblyconditional 226 0 DeleteTaskIf Deletesthetask,possiblyconditional 156 0 Get Getsystemstateinformation(GlobalTime,NextHop,etc.) 850 0 Image ControlCyclopscameraandtakeimage 2098 243 Issue Issueataskafterdelay(periodicorspecifiedtime) 1582 28 Logical Logicaloperationonattributedata 402 0 OnsetDetector Filterdatabydetectingonsetofsignificantevent 1996 0 Pack Packconsecutivescalarsintoavectorattribute 292 0 Reboot Rebootsthemote 56 0 SendPkt Sendusingpacket-basedorbest-efforttransport 3742 398 SendStr Sendusingstream-basedtransport 4442 560 SendRcrt SendusingRCRTprotocol 6198 866 Sample SamplesspecifiedADCchannel 7224 146 SampleRssi UsesradioRSSIasavirtualsensor 226 18 SampleMda400 Samplesspecializedvibrationboard 2324 18 Statistics Statisticsofanattributedata 462 0 Storage Store/Retrieveanattribute,validacrossexecutionsoftask 544 6 Voltage Samplesbatteryvoltage(codepartlyoverlapswithSample) 3444 66 UserButton Trigger/blocktaskexecutionusinguserbutton(Telosb) 360 16 Table3.1: TaskletsinTheTenetTaskLibrary 3.3.2.6 ExamplesofTasks Table3.1describesTenet’scurrenttaskletsandtheircontributionstoprogramsizeandstaticmemoryallo- cationwhereROMandRAMbytesarethebytessavedbyremovingeachtaskletfromourmoteapplication (Appendix A lists all of Tenet’s tasklet APIs provided by current set of tasklets.) We may link together thesebuildingblockstocomposeawidearrayofsensing,maintenance,anddiagnostictasks. For instance, wehavecomposed severaltasksthatassessandmaintainthehealthofasensornetwork. Toverifybyvisualinspectionthatamoteisrunningproperly,wemayinjecttheBlink task. Repeat(1000ms) -> Count(A, 0, 4) -> SetLeds(A) Everysecond,thistaskadds4toacounterwhoseinitialvalueis0,placesthevalueofthiscounterintoan attribute called A, and displays A as a pattern of LEDs. CntToLedsAndRoutedRfm is a more complicated tasktohelpverifythatthereisend-to-endconnectivityfromamastertoamote. Repeat(1000ms) -> Count(A, 0, 1) -> SetLeds(A) -> Send() Inadditiontoblinking,thistasktransmitsthevalueofAbacktothemasternode. 28 To further diagnose our motes, we may monitor routing table information and the memory usage by issuingPingandMeasureHeaptasks. Repeat(1000ms) -> NextHop(A) -> Send() Repeat(1000ms) -> MemoryStats(B) -> Send() Pingreportstheroutingtable’snexthopinformationeverysecond. MeasureHeapreportsamote’sstatistics on current and peak dynamic memory allocations on the heap. Such tasks, as well as data acquisition and processingtasks,mayrunconcurrently. Ifmotesoftwareseemstobebehavingpoorly,theReboot()taskletmaybeusedtoresetamote. This is often the most prudent recourse. Of course, some mote software failures within the routing, transport, and task installation software may prevent the proper reception, installation, and execution of the Reboot task. The taskletSample() serves as the data source for acquisition and processing chains. ASend()- style tasklet is usually the chain’s tail; the particular tasklet depends on the type of transport desired (see thefollowing). Forexample, Sample(1000ms, 1, REPEAT, 1, ADC0, A) -> Send() provides the most basic sampling and transmission support one might expect from a mote. Every second, this task takes a sample from the ADC’s channel 0, gives it the name A, and transmits it. It is similar to the TinyOS SenseToRfm application in that it periodically collects a single sensor value, and to TinyOS’s Surgeapplicationinthatitdeliversdatausingmultihoptransport. Tasklet parameters and their linear composition make it fairly flexible. The following configuration, forexample,samplesbothchannels0and1andstoresfivesamplesofeachbeforesendingthem. Repeat(1000ms) -> Sample(ADC0, A) -> Sample(ADC1, B) -> Pack(A, 5) -> Pack(B, 5) -> Send() Toinstructamotetoprocessthesamplesitcollects,amastermayspecifytaskletsbetweenSample() andSend(). Arathercomplicatedexampleisasfollows. 29 Sample(1000ms, 10, REPEAT, ADC0, A) -> MeanDev(B, A) -> SetLeds(A) -> CountGEQ(C, A, 45) -> GEQ(C, C, 3) -> DeleteAttributeIf(C, A) -> DeleteAttribute(C) -> GlobalTime(D) -> Count(C, 0, 1) -> Send() Everysecond,thistasktakesasamplefromtheADC,waitsuntil10samplesarecollected,andpassesthis set of ten samples at a time through the task chain. On each pass through the chain, the task measures the mean deviation of the sample set, and displays on the LEDs a pattern representative of the values of the samples. The task also classifies the sample set as interesting if at least three of them have an amplitude ofatleast45(bycountinghowmanyofthemhaveanamplitudeofatleast45andcheckingwhetherthere are at least three of them). It then records the global timestamp and a sequence number, and transmits the sample set along with the measured mean deviation. The sample itself is transmitted as well, but only if it happens to be interesting. Notice that the tasking language allows re-use of attributes. For example, GEQ(C, C, ’3’)usesattributeCasbothinputandoutputwherethecreationofanoutputattributewill automatically delete any attribute with the same name. This is analogous to writing C = (C >= 3)? 1:0;inC/C++language. 3.3.2.7 AnExampleofaDataCollectionApplication HowcanaTenetapplicationmakeuseofthistaskinglibrary? Shownshortlyisthecodeforacompleteap- plication which collects voltage level, next routing hop, and global timeinformation every 5seconds. We support Tenet application development in C or Python; the pseudocode that follows is slightly abstracted fromaCprogram. int main() { task_string = "Sample(5000ms, 1, REPEAT, 2, VOLTAGE) \\ ->NextHop(3)->GlobalTime(4)->Send()"; 30 task_packet = construct_task(task_string); task_id = send_task(task_packet); while (1) { (response, mode_id) = read_response(); voltage = response_find(2, response); nexthop = response_find(3, response); globaltime = response_find(4, response); store_data_to_file(mote_id, voltage, nexthop, globaltime); } } TheTenetmaster-sideAPIenablesaprogrammertoconstructataskingpacketfromataskdescription (construct task()), disseminate the task (send task()), receive task responses from the motes (read response()), and find the attribute of interest from this response (response find()). The programmeronlyneedstowritedownthetaskdescription,extractdatafromtheresponse,andprocessthe data. In the previous application, the data is stored in a file, but a more realisticapplication might process thedataasitisreceived. 3.3.3 TheNetworkingSubsystem Tenet’s networking subsystem has two simple functions: to disseminate tasks to motes and to transport taskresponsesbacktomasters. Thedesignofthenetworkingsubsystemisgovernedbyfourrequirements. The subsystem should support different applications on tiered networks. Routing and dissemination mechanismsinthepriorsensornetworkliteraturedonotsupporttierednetworks(Section2.1). Asaresult, we had to build a complete networking subsystem from the ground up while leveraging existing mature implementationswherepossible. Animportantdesigngoalwastosupportmanyapplicationclasses,rather thantailoringthenetworkingsubsystemtoasingleclass. Routingmustberobustandscalable. Theroutingsystemmustfindapathbetweenamoteandamaster ifthereexistsphysicalmultihopconnectivitybetweenthem. InTenet,theroutingsystemneedstomaintain state for motes since masters may need to transmit packets to motes; the routing state on the motes must, in the worst case, be proportional to the number of actively communicating motes. For routing data back to the masters, the system will need to maintain state for masters. We require that this state be constant, 31 Function Mechanism Disseminatingtasksfromamastertoamote Tieredreliablefloodingofasequenceofpacketsfromanymasterto allmotes Routingtaskresponsesfromamotetoa master Tieredrouting,withnearestmasterselectiononthemote-tier,and overlayroutingonthemastertier Routingtransportacknowledgmentsfrom mastertomote Data-drivenreverse-pathestablishment End-to-endreliabletransportofevents Transactionalreliabletransmissionprotocol End-to-endreliabletransportoftimeseries Streamreliabletransmissionwithnegativeacknowledgments Table3.2: TenetNetworkingMechanismSummary independent of the number of masters. Intuitively, this is the best a tree-based mote routing system can do, without increasing packet header size. Byusingsourcerouting, asinCentroute [104], itispossibleto removeroutingstateatthemotesentirely,andTenetcansupportthisformofroutingaswell. Tasksshouldbedisseminatedreliablyfromanymastertoallmotes. Anymastershouldbeabletotask motes,sotaskdisseminationmustworkacrosstiers. Furthermore,tasksmustbedisseminatedreliably,and amotemustbeabletoretrieverecentlydisseminatedtasksafterrecoveryfromatransientcommunication ornodefailure. Task responses should be transported with end-to-end reliability, if applications so choose. Some applications, such as structural monitoring or imaging, are loss intolerant. Furthermore, as applications push more data processing onto the motes, this processed data will likely be loss intolerant. This makes end-to-endreliabletransmissionavaluableserviceTenetshouldsupport. Whilemanyexistingsystemsuse alimitednumberofhop-by-hopretransmissionsorhop-by-hopcustodialtransfer(retransmituntilthenext hopreceivesthepacket),neitherofthesemechanismsensuresend-to-endreliabledelivery;forexample,if thereceiverofacustodialtransferfailsimmediatelyafterthetransferiscomplete,datamaybeirretrievably lost. The following sections describe the design of Tenet’s networking subsystem and how the design achievesthesegoals;Table3.2summarizesitsnovelmechanisms. 32 3.3.3.1 TieredRouting In Tenet, all nodes (masters and motes) are assigned globally unique 16-bit identifiers. The identifier size is determined by the TinyOS networking stack, and motes use the 16-bit TinyOS node identifier. Masters run IP, and use the lower 16 bits of their IP address as their globally unique identifier for master-to-mote communication. Thisrequirescoordinatedaddressassignmentbetweenthemasterandthemote-tiers,but thiscoordinationdoesnotimposesignificantoverheadduringdeployment. Tenet’s routing system has several components: one component (master tier routing) leverages exist- ing technology; another component (mote-to-master routing) is adapted from existing tree-routing imple- mentations; and two other components (data-driven route establishment for master-to-mote routing, and overlayroutingonthemastertier)arenovel. Ouraddressabilityprinciplerequiresmasterstobeabletocommunicatewitheachother. Tenetsimply usesIProutinginthemastertier. Thishastwoadvantages. First,distributedTenetapplicationscanusethe well-understood socket interface for communicating between distributed application instances. Second, TenetcanleverageroutingsoftwaredevelopedforwirelessIPmeshes. Ourcurrentimplementationallows multiple IP routing mechanisms within the master tier; our experiments used static routing, but Tenet can easilyaccommodateotherwirelessroutingprotocolimplementationssuchasRoofnet[5]andOLSR[16]. Tenet’s addressability also calls for any mote to be able to return a response to the tasking master. Standard tree-routingprotocols areinadequate sincetheyassumeasinglebasestation. Tenet usesanovel tiered routing mechanism, where a mote’s response is first routed to its nearest master, and is then routed on the master tier using an overlay. In order to enable motes to discover the nearest master, each master periodicallytransmitsbeacons. Whenamotereceivesabeacon,itrelaysthistoitsneighborsafterupdating a path metric reflecting the quality of the path from itself to the corresponding master. Then, the mote selectsasits“parent”thatneighborwhichadvertisedthebestpathtoamaster. Overtime,amote’sparent may change if the path quality to its nearest master degrades, or if the nearest master fails, conditions detected by the periodic beacons. This only requires a mote to maintain state for a one master plus a 33 fixed number of potential alternate masters, and as long as a mote can hear at least one master, it can send traffic to the master tier. We have modified three well-known tree routing protocols (MultiHopLQI, MultiHopRssi, and MintRoute) 5 to support this nearest master selection. When a mote receives a packet fromanyneighborthatisnot itsparent,itforwardsthepackettotheparent. Once the packet reaches the master tier, an IP overlay is used to forward the packet to the destination master. Amasternodethatgetsapacketfromthemote-tierexaminesthe16-bitdestinationaddressonthe packet. It translates this to an IP address (by prepending its own 16-bit subnet mask to that address), then determinesthenexthoptowardsthisIPaddressusingtheIProutingtable. Itthenencapsulates thepacket inaUDPpacket,andsendsthistothenexthop. Thenexthopmasternoderepeatstheseactions,ensuring that the packet reaches the destination. This IP overlay is implemented as a user-space daemon. Together withnearestmasterselection,IPoverlayroutingensuresthatifthereexistsapathbetweenamoteandthe mastertowhichitshouldsenditstaskresponse,thatpathwillbetaken. The routing system also enables point-to-point routing between masters and motes. This is necessary intwocases. First,ourreliabletransportmechanisms(describedshortly)requireconnectionestablishment and acknowledgment messages to be transmitted from a master to a mote. Second, in certain circum- stances, it may be necessary to adaptively retask an individual mote; for efficiency, a master can directly send the task description to the corresponding mote instead of using our task dissemination mechanism described soon. In either case, a master needs to be able to unicast a packet to a mote only after it has receivedatleastonepacketfromthemote. Tenet’s scalable data-driven route establishment mechanism works as follows. When a mote gets a taskresponsedatapacketfromanonparent,itestablishesarouteentrytothesourceaddress(sayS)inthe packet,withthenexthopsettothesender. Italsoimplementsanagingmechanism;theageofanewroute entryissettozero,andwhentheageexceedsacertainlimit(inourimplementation,2minutes),thisentry isremoved. Iftheentryexistedpreviously,themoteresetstheassociatedage. Onlyafterupdatingthestate 5 We use MultiHopLQI in our PEG experiments (Section 3.4.2) and VTB deployment (Section 3.4.4), and MultiHopRssi in our JR deployment (Section 3.4.5). MultiHopLQI, MultiHopRssi and MintRoute are implemented in TinyOs-1.x. Our TinyOs-2.x port usesmodifiedversionsofMLQIandCTP[36]. 34 doesitforwardthepackettotheparent. Subsequently,whentheparentsendsapacketdestinedtoS(saya transportacknowledgmentfromamaster),thenodeusesthisroutingentrytoforwardthepackettoS,and resets the associated age. Thus, the routing entry is active as long as a mote has recently communicated withitsmaster. Mastersalsoimplementasimilaralgorithmthatsetsupthesedata-drivenroutessopackets onthemastertierarecorrectlyroutedtowardsS. Thus, data-driven route establishment maintains one routing entry per actively communicating mote. Moreprecisely,eachmotemaintainsoneroutingentryforeachactivemoteinitsownsubtree. Data-driven route establishment can have degraded data delivery performance in the presence of link asymmetry. For thisreason,wehaverecentlyaddedsupportfortheCTProutingprotocol,toTinyOs-2.ximplementationof Tenet,whichhaslargermemoryfootprintbutusesbidirectionalETXasitsroutingmetric. Moregenerally, the Tenet architecture does not restrict the choice of mote-tier tree routing protocol. Hence, asymmetric linksarenotachallengespecifictoTenet,andanyroutingsolutiondevelopedtoaddressthisproblemcan beincorporatedintoTenet. 3.3.3.2 TieredTaskDissemination A central component of Tenet’s networking subsystem is one that disseminates tasks from masters to motes. Tenet’s task dissemination subsystem reliably floods task descriptions to all motes. This choice is based on the observation that in most of the applications we describe in this chapter, and those we can foresee, taskinganetworkisarelativelyinfrequent event, andapplications usuallytaskmostifnotallthe motes. Whenapplicationsneedtoselectasubsetofthemotestotask,theycanindicatethisbyprepending a predicate tasklet to the task description. A predicate is a function of static attributes of a node (such as the sensors it has, its current location, and so on). All motes begin executing the task, but task execution is completed only on motes whose attributes satisfy the predicate. For example, to execute a task only on moteswhoseIDislessthan10,thefollowingtaskletchaincanbeprependedtothetask. NodeId(A) -> GT(B, A, 10) -> DeleteTaskIf(B) -> ... 35 Tenet’s reliable task dissemination mechanism is built upon a generic reliable flooding protocol for tiered networks called TRD (Tiered Reliable Dissemination). TRD provides the abstraction of reliably floodingasequenceofpacketsfromanymastertoallmotesinthenetwork. TRD’sabstractionisdifferent from that considered in the literature (Section 2.1). Disseminating a task using TRD is conceptually straightforward. Applications send the task to TRD; if the task description fits within a packet, TRD sends the packet directly, otherwise it fragments the task description into multiple packets which are then reassembledateachmote. TRD works as follows. Suppose a master M wishes to transmit a task packet. TRD locally caches a copy of the packet on M, assigns a sequence number to the packet, and broadcasts the packet to its neighbors as well as to any nearby motes (in case M happens to have motes nearby). Motes also cache received packets, and rebroadcast previously unseen packets to their neighbors, and so forth. Each cache entry contains <master id, sequence number> tuple along with a copy of the packet and its age since creation. In our implementation, both master and mote caches are of fixed size (25 entries), and cache entriesarereplacedusinganLRUpolicy. Of course, some motes or masters may not receive copies of the packet as a result of wireless trans- missionerrors. Torecoverfromtheselosses,eachnode(masterormote)occasionallytransmitsaconcise summary of all the packets it has in its cache. These transmissions are governed by an exponentially backedofftimer[65],sothatwhenthenetworkquiesces,theoverheadisminimal. Thesummariescontain thelastk(wherekisaparameterdeterminedbythememoryavailableonthemotes)<masterid,sequence number> tuples, one tuple from each active master id in the cache with the latest sequence number for that master. If the node detects that a neighbor has a newer packet (identified by <master id, sequence number> tuples) than what it has in its own cache, it immediately requests the missing packet using a unicast request. If a node detects that a neighbor has some missing packets, it immediately broadcasts a summarysotheneighborcanrapidlyrepairthemissingsequencepackets,andsoothernodescansuppress theirownrebroadcast. Lastly,whenanodebootsup,itbroadcastsanemptysummarypromptingneighbors tosendtheirsummaries. 36 This protocol has several interesting features. It uses the master tier for dissemination; as we show in our experiments, this results in lower task dissemination latencies than if a single master were used to inject tasks into the mote cloud. It is extremely robust: all the nodes in the network would have to simultaneouslyfailforapackettobelost. Itperiodicallytransmitssmallgenericsummaries,proportional insizetothenumberofactivemasters. Onthemasterside,TRDisimplementedwithinaseparatetransportlayerdaemonthatalsoimplements the transport protocols described next. Applications connect to this daemon through sockets and transmit a task description to TRD (our implementation has a procedural interfacesend task() that hides this detail from the programmer). Before transmitting a new task, the daemon assigns it a unique task ID and maintains a binding between a task ID and the application. Applications can use this task ID to delete tasks,ortoassociatetaskresponsestotasks. ThisIDisalsoincludedintaskresponsessothatthetransport layerknowswhichapplicationtoforwardtheresponseto. OurTRDimplementationcheckpointsassigned taskIDstoavoidconflictingtaskIDassignmentsafteracrash. An interesting side effect of TRD’s robustness is that a node which recovers after a crash may receive a copy of a task it had previously received or sent out recently in the past. This may cause problems; for example, if aReboot() task was sent to reset the motes, a mote might repeatedly reboot. To avoid this undesirable situation, every TRD message has an age field which is incremented using a timer and synchronized through summary exchanges. TRD checks the age of the received task message and deletes this task if it is older than the node’s lifetime. Hence, only the tasks that are generated after a node boots upwillbeexecutedonthatnode. Our mote implementation of TRD is engineered to satisfy mote resource constraints and to support multiple platforms. TRD stores its packet cache in Flash memory in order to conserve RAM and only maintains a small index of the Flash contents in RAM. Furthermore, TRD currently only supports a fixed numberofmasters(currently5)tolimitthesizeoftheindex. Itimplementsaconsistentagingstrategyby whichmasterentriesinthesummaryareindividuallytimedouttoaccommodatenewactivemasters. 37 Finally, Tenet applications might also wish to adaptively retask a subset of the motes; for example, an application might choose to adjust the sampling rate on some sensors based on observed activity. Ap- plications can use TRD to delete the previous task and disseminate a modified task description with an appropriate predicate or, if it is more efficient, send the updated task descriptions directly to the motes usingoneofTenet’sreliabletransportprotocolsdescribedinthenextsection. 3.3.3.3 ReliableTransport Tenet needs a mechanism for transmitting task responses from a mote to the master that originated the task, possibly with end-to-end reliability. Tenet currently supports four types of delivery mechanisms: a best-efforttransportusefulforloss-tolerantperiodiclowrateapplications,atransactionalreliabletransport for events, a stream transport for high-data rate applications (imaging, acoustics, vibration data), and the RCRT[83]protocolforcongestion-controlledreliabledatacollection. Allfourdeliverymechanismsusea limited number of hop-by-hop retransmissions to counter the high wireless packet loss rates encountered in practice. Applications select a transport mechanism by using the corresponding tasklet in their task description(respectively,Send(),Send(E2E ACK),SendStr(),orSendRcrt()). Theimplemen- tationofbest-efforttransportisconventional,andthatofRCRTprotocolisdetailedin[83];therestofthis sectiondiscussesthetransactionalandstreamtransportmechanisms. Transactionalreliabletransportallowsamotetoreliablysendasinglepacket(containinganevent,for example)toamaster. InTenet,transactionaltransportisimplementedasaspecialcaseofstreamtransport: thedatapacketispiggybackedonstreamconnectionestablishment. Thestreamtransportabstractionallowsamotetoreliablysendastreamofpacketstoamaster. Whena task invokes theSendStr() tasklet, the stream transport module first establishes an end-to-end connec- tionwiththecorrespondingmaster. Streamdeliveryusesaconnectionestablishmentmechanismsimilarto thethree-wayhandshakemechanismofTCP.However,becausestreamdeliveryisfundamentallysimplex, theconnectionestablishmentstatemachineisnotascomplexasTCP’sandrequiresfewerhandshakesfor connection establishment and teardown. Once a connection has been established, the module transmits 38 packetsonthisconnection. PacketscontainsequencenumbersaswellasthetaskIDofthecorresponding task. Theremotemasterusesthesequencenumberstodetectlostpacketsandsendsnegativeacknowledg- ments for the missing packets to the mote, which then retransmits the missing packets. End-to-end repair isinvokedinfrequentlybecauseofourhop-by-hopretransmissions(Section3.4). On masters, transport protocols are implemented at user level. Transport and TRD execute in one daemon so that they can share task ID state. On motes, our implementation is engineered to respect mote memory constraints. Retransmission buffers at the sending mote are stored in Flash in order to conserve RAM. 6 Furthermore, our implementation has a configured limit (currently 4) on the number of open connections a mote may have for reliable transport. (Best-effort transport does not have this limit.) All transport protocols work transparently across the two tiers in Tenet. All types of reliable delivery can traverse multiple hops on both tiers of the network and there is almost no functional difference between ourimplementationsforthetwotiers. 3.3.4 Limitations We view our current work on Tenet as the first step towards a general-purpose architecture for sensor networks. As such, our current prototype lacks functionality required to support some sensor network applications. Infrastructural components can be easily incorporated into the Tenet system. Our current prototype already includes time synchronization. Once a mature implementation of localization is available, it will be conceptually easy to incorporate this into Tenet. Information from these components (such as location and time) can be exported to applications through tasklets; indeed, we have already developed tasklets thatexportsysteminformation(suchasroutingstate,taskconcurrency,dynamicmemoryusage,etc.) and allowapplicationstoreadglobaltimeandsynchronizetaskexecution. At the moment, the Tenet system does not support delay-tolerant applications, those that require (sta- tistical) delay bounds, or low latency messaging (e.g, [98]). Whether these can be achieved within the 6 Every new packet sent using stream transport is stored to a circular Flash buffer, which can hold 200 packets in our current implementation. ThisdesigntradesoffenergyagainstRAM.Weplanalsotoexplorealternateretransmissionstrategies. 39 Max MemoryUsage(bytes) DataTransmitted(bytes/pkt) Task Concurrency Application Overhead Tasking Output Overhead Diagnostics — 94 22 46 26 46% Sample[1]→Send 64 64 18 30 6 67% +LocalTime 55 76 20 38 14 57% +Count 47 90 22 48 20 60% +MeanDev 41 104 24 58 26 61% +Comparison+DeleteAttr 32 134 28 80 26 61% Sample[40]→Send — 142 18 40 84 5% Table 3.3: Statistics for example tasks. Max Concurrency shows the number of concurrent tasks a single Tmotecansupport. MemoryUsageshowsthenumberofbytesusedpertaskforapplicationdataandmal- locoverhead. DataTransmittedshowsthenumberofbytesneededtospecifyataskinataskdissemination packet,andthenumberofbytessentpertaskexecution. The%Overheadcolumnshowshowmuchofthat loadistakenupbyattributeoverhead(typeandlengthbytes). context of this architecture or not remains an open question, one that can only be answered after we have attemptedtoaddsupportfortheseinthesystem. AswestateinSection3.1,thearchitecturalconstraintof Tenet could be relaxed if required, of course, but we aggressively enforce it to most clearly demonstrate thecostsandbenefitsofourapproach. Inthischapter,wehavenotdiscussedenergymanagement. Recently,wehavebeenabletoretrofitradio duty-cycling into Tenet, without compromising the Tenet principle [36]. Several other extensions to the Tenetsystemremainopen,andwebelievetheseareconceptuallyeasytoachieve. Supportforactuationcan be naturally expressed as a task. Similarly, mote-tier storage can also be realized by adding appropriate abstractions (reading and writing to named persistent storage) and associated tasklet implementations. Finally,mechanismsforensuringtheauthenticityandintegrityofdata,andmethodsformulti-useraccess controlandresourcemanagement,canborrowfromsimilarmechanismsinothergeneral-purposesystems. 3.4 TenetEvaluation This section evaluates Tenet through microbenchmarks of its tasking and networking subsystems and re- liable stream transport, and through four application studies, including a pursuer-evader game (PEG), an applicationbelievedtobeparticularlychallengingtoimplementefficientlywithoutin-networkdatafusion. WefindthatTenet’scoremechanisms,suchastasking,scalewell;thatTenetsarerobustandmanageable; 40 that its tasking language is flexible enough to accommodate a variety of applications; and that even chal- lengingapplicationsmaybeimplementedwithlittleefficiencyloss. 3.4.1 TasksandTasklets TenettaskletsandthebaseTenetimplementation,particularlyitstaskingandmemorysubsystems,should be lightweight enough to allow many tasks to execute concurrently on a mote; for instance, to run di- agnostics tasks concurrently with sensing tasks. Thus, as an end-to-end evaluation of the Tenet tasking software stack, we find the maximum number of copies of a task that a mote can support. A Tmote can run32concurrentversionsofanontrivialtask;thismaximumconcurrencyrisesforsimplertasks. Wealso measureotherbasicaspectsofthesystem,suchasmemoryandpacketoverhead. Concurrency Webegintheconcurrencystudywithasimplesample-and-send task. Sample(60000ms, 1, REPEAT, ADC0, A) -> Send() Weincreasethesamplingperiodto60secondstopreventtheradiofrombeingtheconcurrencybottleneck. The fact that the radio cannot support very much traffic, particularly when communicating over multiple hops, is a well-known issue with sensor networks in general. Varying numbers of copies of this task are run alongside the following single diagnostics task, which sends, from each mote, a timestamp, the next hop,andstatisticsofmemoryusage. Repeat(1000ms) -> LocalTime(A) -> MemoryStats(B) -> NextHop(C) -> Send() A single Tmote mote can concurrently execute the diagnostics task plus up to 64 sample-and-send tasks. Naturally, tasks that contain more tasklets consume more resources, so the mote can execute fewer of them at once. We measure this effect by adding tasklets to the sample-and-send task, thus making it 41 morecomplex. Foreachincrementaladditiontothetask,wemeasurehowmanyofthatintermediatetask canexecuteonamoteatthesametime. Themorecomplicatedtaskisasfollows. Sample(20000ms, 1, REPEAT, 1, ADC0, A) -> LocalTime(B) -> Count(C, 0, 1) -> MeanDev(D, A) -> GT(E, A, 0) -> DeleteAttribute(A) -> Send() This task is similar to the data acquisition and processing example in the previous section, except that we additionally delete the sample for good measure. Table 3.3 shows the results: a Tmote can concurrently execute32instancesofthiscomplicatedtask. Memory We now turn our attention to identifying the resource bottleneck that prevents higher task concurrency. There are two candidates: available MCU cycles and RAM. Radio bandwidth cannot be the bottleneck as ourtaskssentsufficientlylittledata. Our results indicate that memory is the tasking bottleneck on our motes. Table 3.3 shows the total bytes allocated from the heap per task in steady state, and the total number of bytes allocated to manage theseheapblocks(twobytesperblock). OurTenetTmoteshavearound5540bytesavailableinRAMfor theheapandcallstack. Inthesteadystate,asample-and-send taskuses82(64+18)bytesallocatedfrom the heap and the diagnostics task uses 116 (94+22) bytes. Thus, even ignoring the call stack, a Tmote wouldn’t be able to support more than⌊ (5540−116)/82⌋ =66 concurrently executing sample-and-send tasks while a diagnostics task is running. In actuality, a Tmote supports 64. On more RAM-constrained motes, this number can be much lower; a Tenet MicaZ, for example, supports only 12 sample-and-send tasks. EventasksthatuseourmostCPU-intensivetasklet,MeanDev()(orequivalentlyStatistics(MEAN DEV)), experiencememoryconstraintsbeforeprocessorconstraints. Thefollowingtaskdemonstratesthis. Sample(1000ms, 1, REPEAT, ADC0, A) 42 InputSamples ExecutionTime(ms) 1 1.8 40 2.3 400 6.8 800 11.9 1200 16.9 Table 3.4: Execution time of measuring the mean deviation from the mean as a function of the number of inputsamples. Averagedoverfiveruns. -> LocalTime(B) -> MeanDev(C, A) -> LocalTime(D) -> DeleteAttribute(A) -> Send() This task measures and reports the mean deviation from the mean of a collected sensor value. We record thetimebeforeandafterrunningthistasklettomeasureitsexecutionspeed. Ourhypothesisisthatforthe tasklets we have written, none consumes enough MCU cycles such that concurrency will be bounded by themicrocontroller. Table3.4liststheexecutiontimesofcalculatingthemeandeviationfromthemeanas afunctionofthenumberofinputsamples. Evenwhenprocessing1200samplesatatime,whichconsumes about half the application’s available RAM, the execution time is a mere 16.9 milliseconds. Thus, a mote running several tasks that gather statistics will only be CPU-bound when the aggregate sampling rate is approximately71,000samplespersecond. DataTransmittedandPacketOverhead The task library’s processing flexibility results from the use of flexible attribute-based packets and data structures. However,nothingisforfree: thisflexibilitycomesatthecostofincreasedoverhead. Table3.3 shows the packet overhead associated with adding type and length fields to each of our data attributes. It requires 30 bytes to specify a task as simple as sample-and-send. Each packet generated by this task containsonlysixbytesofapplicationdata,fourofwhicharethenameandlengthoftheattributecontaining the sample. When sampling is periodic, the ratio of task specification bytes to output bytes becomes insignificant, but for tasks that put a single sample in each packet the overhead of describing the response inTLVformatisstilllarge. 43 To compensate for this overhead, the Sample tasklet can pack more than one sample in an attribute. Whenthemasterspecifiesthat40samplesbepackedandsentineachpacket(theSample[40]→Send task),thisoverheaddropsto5%. 3.4.2 ApplicationCaseStudy: Pursuit-Evasion Howmuch,ifatall,doesTenetdegradeapplicationperformancerelativetoamote-nativeimplementation that performs in-mote multinode fusion? In this section, we examine this question by comparing mote- nativeandTenetimplementationsofapursuit-evasionapplication. Pursuit-EvasionGames Pursuit-Evasion Games (PEGs) have been explored extensively in robotics research. In a PEG, multiple robots (the pursuers) collectively determine the location of one or more evaders, and try to corral them. The game terminates when every evader has been corralled by one or more robots. PEGs have motivated interesting research directions in multirobot coordination. In this work, however, our interest in PEGs comes from the following observation: in obstructed environments such as buildings, pursuers may not have line-of-sight visibility to evaders, and a sensor network can help detect and track evaders. Indeed, [97] describe a mote-level implementation of the mechanisms required for evader detection and tracking inPEGs. Intheirimplementation,themotenetworksensesevadersusingamagnetometer,andtransmitsa locationestimatetooneormorepursuers. Thenetworkcontinuouslytracksevaders,sothatpursuershave an almost up-to-date, if approximate, estimate of where the evaders are. The pursuers can then employ collaborativepathplanningalgorithmstomovetowardstheevaders. We have reimplemented a version of Sharp et al.’s system, including their leader election, landmark routing, and landmark-to-pursuer routing mechanisms. (We could not use their implementation since it wasdevelopedonapreviousgenerationsensorplatform,themica2dot.) Leaderelectionperformsin-mote multinodedatafusiontodeterminethecentroidofallsensorsthatdetectanevader;theothermechanisms 44 routeleaderreportstopursuers. Ourreimplementation,whichwecallmote-PEG,usesSharpetal.’salgo- rithms, but a more mature routing technology, namely MultihopLQI. This allows for a more meaningful comparisonwithourTenetimplementation. TenetandPEGs PEGs represent a stress test for Tenet. In a dense deployment, it is highly likely that multiple motes will sense the evader. Pushing the application-specific processing into the motes, as mote-PEG does in its leaderelectioncode,canconserveenergyandreducecongestion. BecauseTenetexplicitlyforbidsin-mote multinodefusion,itcannotachievesimilarefficiencies. We have implemented a single pursuer, single evader PEG application for Tenet. In Tenet-PEG, the pursuerisamobilerobotthatispartofthemasternetwork. TheTenet-PEGapplicationrunsonthepursuer, which tasks all the motes to report evader detections whose intensity is above a certain threshold T. The pursuerreceivesthetaskresponsesandcomputestheevaderpositionsasthecentroidofallreportsreceived withinawindowP,wherePisthesamplingperiodatthemotes. Extendingthisimplementationtomultiple pursuersinvolvesdistributingtheapplicationacrossthemastertier,whichwehavelefttofuturework. Although Tenet-PEG cannot reduce network traffic by multinode data fusion on the motes, it can control overhead by dynamically adjusting the threshold. In our Tenet-PEG implementation, we have implemented a very simple adaptive algorithm. K, the target number of reports, is an input parameter to thisalgorithm. Initially,ourTenet-PEGimplementationsetsalowthreshold. Whenithasreceivedatleast P (10, in our current implementation) distinct sensor values, it picks the K-th highest sensor value (K is 3 in our experiments), and retasks the motes to report at this threshold. A more sophisticated algorithm would continuously adjust the threshold based on the number of received reports, and is left for future work;however,eventhissimplealgorithmworkswellinpractice. 45 ExperimentalMethodologyandMetrics We now compare the performance of Tenet-PEG and mote-PEG. Our experiments are conducted on the testbed shown in Figure 3.12(a). This testbed consists of 56 Tmotes and 6 Stargates deployed above the false ceiling of a single floor of a large office building. The Stargate and mote radios are assigned noninterfering channels. The mote radio power is configured such that the maximum network diameter is 5∼ 7 hops. This testbed represents a realistic setting for examining network performance as well as for evaluating PEGs. The false ceiling is heavily obstructed, so the wireless communication that we see is representative of harsh environments. The environment is also visually obstructed, and thus resembles, say, a building after a disaster, in which a pursuit-evasion sensor network might aid the robotic search for survivors. Wemaketwosimplificationsforourexperimentswhichaffectbothimplementationsequallyandthere- fore do not skew the results. First, lacking a magnetometer sensor, we use an “RSSI” sensor. The evader periodically sends radio beacons and sensors detect the existence of the evader by the receipt of the bea- cons. The beacon’s RSSI value is used as an indication of the intensity of the sensed data. Since multiple nodescandetecttheevaderbeacon,itseffectissimilartothatofhavingarealmagnetometer. TheRSSIis alsousedtoimplicitlylocalizetheevader;RSSIhasbeenusedbeforefornodelocalization[11],andsince we only require coarse-grained localization (see the following), it is a reasonable choice for our experi- ments as well. Second, to create a realistic multihop topology, we limit the transmit power of each mote. Thisresultsinatopologywitha9-hopdiameter,andiscomparabletothediameterofthenetworkusedin [97]. Thisalsoresultsinarealistictierednetwork,withthelargestdistancefromamastertoamotebeing aboutfourhops. Inthissetting,sinceweareinterestedinhowthenetworkaffectsapplicationperformance,weconduct the following experiment. We place one stationary pursuer. An evader tours the floor, carrying a laptop attachedtoamotethatemitstheevaderbeacon. Thefrequencyofevaderbeaconing,aswellasthatofRSSI sampling, is 2 Hz. The laptop receives user input about its current location, and maintains a timestamped 46 Overhead(msg/min) Min Max Average Mote-PEG 191 384 272 Tenet-PEG 181 255 217 Table3.5: PEGApplicationOverhead log of the evader position. This log represents the ground truth. For Tenet-PEG, we use a network with a single master; this enables a more even comparison with mote-PEG, since using a tiered network could skewperformanceresultsinTenet’sfavor. In comparing the two implementations, we use the following metrics. Our first metric measures application-perceived performance, the error in position estimate. Many robotic navigation techniques reducethemapofanenvironmenttoatopologicalmap[61]. Thistopologicalmapisacollectionofnodes andlinksthatrepresentsimportantpositionsintheenvironments. Usingsuchatopologicalmap,pathplan- ning can be reduced to graph search [10]. Our Tenet-PEG implementation actually implements a simple graphsearchtechnique. InPEGimplementationsthatusesuchatopologicalmap,thegoalistonarrowthe evader’s location down to the nearest node on the topological map. Thus, our definition of position error at a given instant is the distance on the topological map between the pursuer’s estimate of the evader’s position, and ground truth. We study the variation of position error over time. In our implementation, we divideourfloorinto14topologicalnodes,eachapproximately22feetapart. Ourtwoothermetricsmeasurenetworkperformance. Thefirstisthelatencybetweenwhenamotede- tectsanevaderandwhenthisdetectionreachesthepursuer. WemeasurethisusingFTSP[73]timestamps. The second is the application overhead, the total number of messages received per minute at the pursuer. This measure, while unconventional, indicates the how well the filtering algorithms work. If we get more thantheexpected 120reports(at2Hzsamplingrate)perminute, duplicate informationisbeingreceived. ForTenet-PEG,thismeanstheRSSI-thresholdistoolow;formote-PEGitmeansthatsometimesmultiple nodesgetelectedasleaders. 47 0 0.2 0.4 0.6 0.8 1 0 1 2 3 4 5 6 7 8 Fraction of Reports Positional Error Mote-PEG Tenet-PEG Figure3.2: PEGapplicationerror. 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 50 100 150 200 250 Fraction of Reports Reporting Latency (ms) Tenet-PEG Mote-PEG Figure3.3: PEGdetectionlatency. Results Figure 3.2 shows that Tenet-PEG estimates the evader position slightly more accurately than mote-PEG. Therearetworeasonsforthis. First,ourTenet-PEGimplementationadaptivelysetsthereportingthreshold using information from many nodes across the network. By contrast, mote-PEG’s reporting decisions are based on a local leader election, which can sometimes result in spurious local maxima. Second, while mote-PEGcomputesevaderpositionasthecentroidofallthereportingnodes,Tenet-PEGsimplyusesthe positionofthereportingnode. Inmote-PEG,thereportingnodesmaysometimesspanourfloor,resulting incaseswheremote-PEGerrorisseveralhops. Figure3.3showsthatTenet-PEG’slatencyisonlymarginallyhigherthanthatofmote-PEG.Thissmall difference is attributable to the latency across the serial link between the master and its attached mote, as wellasprocessingoverheadsintheTenetstack. 48 Figure3.4: Vibrationsensingwithonsetdetector. Finally, Table 3.5showsthat Tenet-PEG incurs slightlyloweroverhead thanmote-PEG. Thiscan also beattributedtoTenet-PEG’sadaptivethresholdselectionalgorithmwhichreducesthenumberofreporting nodes. Overall, our results are extremely encouraging. In the case of medium-scale pursuit-evasion, an ap- plication previously thought to demand in-mote multinode data fusion for performance, Tenet implemen- tations can perform comparably with mote-native implementations in the experiments conducted on our testbed. Although some applications may use in-mote multinode data fusion, our Tenet-PEG experience suggeststhatitmightbepossibletoachievesimilarperformancegainsbycarefullocalprocessing. 3.4.3 ApplicationCaseStudy: Event-BasedVibrationMonitoring InSection3.4.1,weshowseveralexamplesofdebuggingandmaintenancetasksthataretrivialtoexpress in Tenet. It is difficult to measure quantitatively whether Tenet simplifies the programming of more re- alistic applications. In this, and subsequent sections, we discuss a few application case studies in which we have implemented realistic (and qualitatively different) applications using Tenet. Two of these appli- cations have been deployed for up to several days in realistic environments. Our first example is a Tenet implementationofamaturestructuralmonitoringsystem,Wisden[82,117],anevent-basedvibrationdata acquisition system that reliably transmits vibration samples from a network of motes to a base station. 49 Each mote transmits only interesting events using a simple onset detector [82], greatly reducing com- munication requirements. An onset is defined to be a part of a signal waveform that exceeds the mean amplitude by more than a few standard deviations. Wisden implements specialized mechanisms for time synchronization,aswellasforreliablytransmittingdatatoabasestation. To port Wisden to Tenet, we implemented an OnsetDetector tasklet and used it to build a task functionally equivalent to Wisden’s mote code. Specifically, the application tasks motes using a task descriptionofthefollowingform. SampleMDA400(20ms, 40, CONT, Z_AXIS, A) -> OnsetDetector(A) -> SendStr() Here,SampleMDA400()controlsavibrationsensorboardandSendStr()invokesourstreamtransport protocol. Figure 3.4 shows the vibration time-series on two MicaZ motes using a single master. One mote was programmedwiththeprecedingtask,butwithoutOnsetDetector()(thelowertimeseries). Theother was programmed with the preceding task (the upper timeseries). We then put the two motes on a table, and hit the table. The mote without OnsetDetector() sends vibration data even before the onset; this vibration is induced by human activity (movement, typing). The other task does not send spurious vibrations,resulting,inoursmallexperiment,ina90%trafficreduction. ThisTenetimplementationofWisdenisnotonlyfunctionallyequivalenttoWisdenbutimprovesover Wisden in several aspects. First, a Tenet deployment is more scalable since the bandwidth capacity limit which bounded the number of nodes in Wisden is circumvented in Tenet by using masters. Second, the Tenet implementation of Wisden can alter application parameters (such as sampling frequency, channels, etc.) at runtime by retasking the motes whenever the application wishes to; by contrast, Wisden required reprogrammingofthemotes. Finally,inTenet,otherapplicationtaskscanrunconcurrentlywhilerunning the Wisden application. This not only promotes reusability within the network, but it can also provide usefulinformationaboutthestateofnetwork(routingtopology,time-syncstate,andmemoryusage)while anapplicationexecutes,therebyimprovingthemanageabilityandtherobustnessofthesensornetwork. 50 Figure3.5: Deploymenttopologyonthebridge. The Tenet version of Wisden’s mote code reduces in the end to three simple tasklets. Tenet integrates support for tasking and stream transport, making the Wisden application itself both smaller and simpler. Our qualitative judgment is that, even for these reasons alone, Tenet significantly simplifies application development. 3.4.4 Real-WorldDeployment: VibrationMonitoringatVincentThomasBridge In this section, we discuss our experiences from a real-world deployment of Tenet on a large suspension bridge. ThisTenetdeploymentrananapplicationdesignedtocontinuouslymonitorthebridge’svibrations, andreliablytransmitthedatabacktoabasestation. DeploymentMethodologyandExperiences WedeployedaTenetsystem,runningasimplestructuraldataacquisitionapplication,onVincentThomas Bridge, a 6,000 ft long suspension bridge with a main suspension span of 1,500 ft, and a height of 185 ft above water. We instrumented 600 ft of the bridge using a Tenet network consisting of 5 master nodes and20motes,andcollecteddatafor24hours. Mastersandmoteswereequippedwithbatteriescapableof lastingtheentiredurationoftheexperiment. The communication environment on the bridge was relatively harsh. Masters were able to commu- nicate at distances of only 100 ft with less than 1% packet loss rate. Beyond 140 ft, they were unable 51 to communicate. Motes were able to communicate only 80 ft reliably, and there was a sharp drop off of connectivity at 90 ft. These results were surprisingly worse than what we could achieve in a ground-level openspace,anddictatedourdeploymenttopology. The deployment spanned 600 ft starting from the east tower towards the center of the bridge (Fig- ure 3.5). The network was configured as a linear topology of 20 motes and 5 masters. Each mote was placed 30 ft apart from each other resulting in a maximum distance of 45 ft from any mote to its nearest master. Everypairofneighboringmasterswasseparatedbyabout120ft. VibrationMonitoringApplication Onthisnetwork,weranaTenetapplicationwhichtasksallthemotestosampleat20Hzalongthreeaxes (x,y,z), retrieves the data, and stores the responses into a log file at a master. Although our hardware and theTenetsystempermitasamplingfrequencyofupto1kHz,itisnotpossibletostreamdatacontinuously at such a high rate given the capacity limits on the motes. Based on prior experiences with hardware limitations [82], we concluded that our system would be able to support continuous-sampling and real- time transmission without any compression at 80 Hz for a single channel, or one-third of that for three channels. Tobeconservative,weselected20Hztri-axisforourexperiment,andusedthefollowingTenet task. SampleMda400(50ms, 20, CONT, AX, A, AY, B, AZ, C) -> SendStr() This task is similar to that of the Wisden application (Section 3.4.3) except that here we do not perform OnsetDetector() processing. Recall that SendStr() invokes reliable stream transport protocol. Henceeverynodecontinuouslygenerates3packetspersecond(whereeachpacketcontains20samplesand each sample is 16 bits), which adds up to total of 60 packets per second being received at the application. This corresponds to a data rate of 35.52 kbps (including a timestamp and packet headers), a challenging rateforaflatmultihopnetworkof20motesespeciallywhenreliabledatatransferisarequirement[53,83]. 52 0 1 2 3 4 5 6 7 8 9 10 x 10 5 −0.04 −0.03 −0.02 −0.01 0 0.01 0.02 0.03 0.04 time (ms) acceleration (g) 0 1 2 3 4 5 6 7 8 9 10 x 10 5 −0.04 −0.03 −0.02 −0.01 0 0.01 0.02 0.03 0.04 time (ms) acceleration (g) Figure 3.6: Time-series plot of the acceleration data from two different nodes: measured in perpendicular directiontothebridge,ataround5:00pm. Figure3.7: Verticalvibrationmodalfrequencies(Hz). DataValidation Figure 3.6 shows that the time-series plot of the ambient vibration data from two different nodes on the bridge are consistent with each other. Figure 3.7 depicts the spectral density plots for data from several sensors,takenataboutthesametime. FFTprofilesofthedatahaveallbeenbandpassfilteredforfrequen- cies between 0.15 and 5.0 Hz, using a two-pass, two-pole Butterworth filter. The spectral density plots show two interesting features. First, they are internally consistent: many peaks (modes) are observed at several sensors. That some modes are not visible at some sensors is expected; such sensors are placed at 53 0 2 4 6 8 10 12 14 16 18 20 0 500 1000 1500 2000 2500 3000 Mote node index Number of packets Number of packet loss from mote wireless Number of packet loss from master wireless nulls of the corresponding vibration mode shapes. Second, the location of the modes is also consistent withpublishedresultsobtainedfromwiredinstrumentation[99]. SystemEvaluation Our experiment ran for 26 hours, comprising 22 rounds: in each round the system collects data for 60 minutes, backs up the data, and resets the motes during the next 10 minutes. This experiment design was an artifact of the fact that we had observed rare software crashes on the motes. Rebooting the entire network every hour enabled us to recover from these crashes reliably. Out of 22 rounds, 19 rounds had datafromall20nodes,andtheother3roundshaddatafrom19nodes,whichresultsinanode-roundyield of99.32%(437outof440node-rounds). Ineachofthosethreeincompleterounds,onenodewasnotable tostartthetaskasaresultofthesoftwarebug. Wecollectedatotalof6,430,792datapacketsduringtheexperimentwhichamountstoapproximately 323,745 packets from each sensor node. Each of the 19 complete datasets have approximately 294,500 packetsand4,386,000samplesperround. For all 437 node-rounds in which we were able to collect data, our system achieved 100% end-to-end reliability with no lost packets. To achieve this, the end-to-end reliable transport protocol was required to retransmit 26,965 packets, which is 0.42% of the total number of data packets received (Figure 3.4.4). Nodes farther away from center of the network required more retransmissions because their packets tra- versedlongerpaths(morehops)togettothecollectionpoint. Amongtheseretransmissions,approximately 54 Figure3.8: DeploymenttopologyattheJamesReserve. 2.92% were due to packet loss on the IEEE 802.11b master wireless links and 97.08% were due to loss on the IEEE 802.15.4 mote wireless links (Figure 3.4.4). Despite losses on the mote as well as master wirelesslinks,oursystemwasabletoreliablycollectallthetransmittedsamples. Overall, the results show that Tenet performs well in real-world deployment. Its tiered architecture scales network capacity and allows reliable delivery of high rate data that would otherwise have been difficulttoachieveonaflatmultihopnetworkofmotes. 3.4.5 RealWorldDeployment: PitfallTrapMonitoringatJamesReserve Inthissection,wediscussaqualitativelydifferentreal-worlddeploymentofTenet: animagingapplication forpitfalltrapmonitoring,deployedattheJamesReserve 7 . Thisapplicationusesimage-sensors(Cyclops cameras[90])andleveragestheCyclops’on-boardprocessingcapabilities. Itisalsothemostcomplicated Tenetapplicationwehaveexploredtodate,anddemonstratestheexpressivenessandreusabilityofTenet’s taskinglibrary. 7 http://www.jamesreserve.edu/+ 55 Pitfall trap arrays at James Reserve are used by biologists to sample the local population of lizards and amphibians. Biologists deploy arrays of traps in clusters. When a lizard is caught in a trap, it is tagged and freed. Over time, a count of trapped lizards can be used to estimate the overall population of lizards. However,ifalizardislefttoolonginatrap,itcandie. So,biologistsfrequentlypolleachtrapby physically visiting each every few hours: because these traps are deployed over a few square kilometers, inspectingthesetrapscanbeanarduoustask. ATenetnetworkwithimagesensorscanhelp: thebiologists can inspect the images remotely, and only visit a trap when a lizard is caught, saving time, effort, and frustration. We deployed a Tenet system in an array of pitfall traps at James Reserve. Our deployment consisted of seven traps in a star configuration. We placed 7 traps each equipped with a mote and attached Cyclops camera, one stargate master near the array, and a laptop master at a lodge about 100 yds away from the array. Figure 3.8 depicts the deployment topology. Some of the nodes were behind the trees with foliage whichblockedlineofsighttothebasestation. Our goal was to design a triggered data collection system, where each node frequently captures an image, but only sends it to the base station when some interesting change has been detected in the image. Thisisnecessarytoconservenetworkbandwidth,sinceeachimageis16KB.However,theimagechange detection algorithm we use can exhibit false negatives. If a false negative detection occurs, no image will bedeliveredatthatinstant. Evenifthereactuallywasalizardinthattrap,ifthatlizarddoesnotmove,no image transfer will be triggered at subsequent sampling times as well. This might result in a missed and eventually dead lizard. To avoid this, we designed our application to transfer at least one image every 30 minutes. HereisaTenettaskthatrealizesthisrelativelycomplicatedlogic. Repeat(120000ms) -> ImageDetect(TAKE_NEW, FLASH_ON, 128x128, BW, A) -> Count(B,0,1) -> Mod(B,B,’15’) -> Eq(B,B,’0’) -> Or(A,A,B) -> Store(C,A) -> DeleteAllAttributeIf(A) -> Send(E2E_ACK) 56 -> Retrieve(C) -> Not(C,C) -> DeleteActiveTaskIf(C) -> DeleteAttribute(C) -> ImageDetect(RESET) -> ImageFetch(LAST, 40, 140ms, D) -> SendStr(); In this task, ImageDetect() invokes a background-subtraction-based algorithm to detect noticeable differences between the new and previous image, and ImageFetch() retrieves the last image stored in the Cyclops memory. Thus the preceding task takes an image every 2 minutes, and transfers it only if some change has been detected in the image or every 15th run (every 30 minutes). If an object is not detected and it is not the 15th run, the task sends a small message (A≡0) usingSend(E2E ACK), as a keep-alive. Otherwise,ittransfersthelastimageusingSendStr(),andresetsthedetectionbackground. Each image isan128x128 black-and-white image whosesizeis16KB, andeach packet can contain upto 40bytesofimagefragmentdata;so,eachimagerequires410packets. TheseImage-style tasklets are different from other tasklets in that they are executed on the cameras themselves. Image processing requires memory and MCU cycles beyond the capabilities of the current generation of motes, and the Cyclops board was designed to provide specialized image processing tasks. Forthisreason,theTenetmoteexportssingleImage()taskletthatcanbeusedtoparametrizeandinvoke Image-relatedoperations,suchasImageDetect(), ImageFetch(), ImageSetParam(),etc. which are implemented within the camera themselves. This design allows any resource-intensive opera- tiontobeperformedoff-moteandcanbeappliedtootherspecializedexternalsensors(e.g.,high-frequency ADCboardsthatcansampleat10kHz)withon-boardprocessing. Our deployment lasted 3 days, and the network was operational only during the daytime hours (7am– 7pm). We collected 589 Cyclops images, out of which 588 images were complete; there was one incom- plete image from a node which almost ran out of battery (we used two D-cell batteries on each node). Figure 3.9 plots the time when each has transferred an image on the last day of the experiment. Many of the transferred images were triggered as a result of changes in the intensity of sunlight (Figure 3.11), and 57 Figure3.9: Image-transfervs. timeplot: Animageisgeneratedevery30minutes,inadditiontowhenever anobjectisdetected. Figure3.10: Spidertriggeredimagetransfers. someotherswereintentionallytriggeredbyustotestthesystem. Onesetofimages,atnode102between 7:45pmand8:40pm,caughtatrappedspider(Figure3.10). Finally, note that there was a similar deployment at James Reserve before [57] that did not use Tenet. Our deployment not only replaced the previous system but also improved upon that in several aspects: multihop communication, reliable data delivery, easier-to-use end-to-end system, etc. This is another example which shows that Tenet is reusable and expressive: Tenet can be used to fully implement and improveonpreviouslyexistingapplications. Figure3.11: Sun/shadechangecausedimagetransfers. 58 (a) sixmastertopology (b) singlemastertopology Figure3.12: TestbedtopologyasgatheredbyNextHop()→Send(). Mastersarestars,motesaredots. PEGexperimentsuseonlythecentralmaster. Insummary,thisapplicationhasshowntheexpressivenessandreusabilityoftheTenettaskinglibrary, andhowoff-boardprocessingcanbeexpressedinit. Largelybasedonexperiencesfromthisdeployment, we have moved on to a larger Tenet deployment with 4 masters and 20 cameras for bird nest monitoring at James Reserve [43]. This deployment incorporates image compression, and uses a recently design congestioncontrolprotocol,RCRT[83]. 3.4.6 Manageability Network monitoring is an important part of networked system manageability. Although we have not extensively evaluated manageability, we have been able to quite easily construct simple applications that can monitor and measure a Tenet network. For example, the following task allows us to get a snapshot of theroutingtreeatanyinstant. Wait(1000ms) -> NextHop(A) -> Send(E2E_ACK) This obtains each mote’s routing parent using our reliable packet delivery protocol. Figure 3.12 was gatheredinthismanner. Suchanapplicationcanbeinvaluableformonitoringanddebugging,particularly sinceitcanrunconcurrentlyonTenetwithanapplicationwhichwemaybetryingtodebug. Itisalsoeasytoperformcertainkindsofmeasurements. Thistask GlobalTime(A) -> Wait(1000ms) -> Send(E2E_ACK) 59 Figure3.13: Taskdisseminationlatency. timestamps a task using the time computed by the FTSP [73] protocol (which is integrated into the stack) assoon asitisreceived, backs offforasecond toreduce congestion, and sends theresultsback. Itcan be used to measure the latency of task dissemination. We have run this on the network shown in Figure 3.12 and measured the Tenet’s task dissemination latency with a varying number of masters turned on. With 6 masters, the average tasking latency is 110 ms, and the largest is 550 ms (Figure 3.13). The benefits of tieringareclearlyevident;inourtestbed,theaveragetaskinglatencyusing6mastersisaboutafifthofthat using only 1 master (because the network has a much smaller mote diameter, leaving fewer opportunities forlostpacketsandretransmissionsbetweenmotes). 3.4.7 Robustness We conducted a simple experiment to demonstrate the robustness of our current Tenet implementation to the failure of masters. In this experiment, we tasked 35 nodes in a 5-master network to sample their temperature sensor and transmit the samples using our reliable transport protocol. The task chain for this experimentwasasfollows. Sample(100ms, 1, REPEAT, ADC10, A) -> SendStr() Five minutes after tasking the network, we turned off one of the masters, and five minutes thereafter, another. 60 Figure3.14: Sequencenumberevolutionofstreamtransportconnections. Figure 3.14 plots, for each connection, the received sequence number against the time at which the corresponding packet was received at the master. Two things are noticeable about the figure. For all connections,initially,thesequencenumberevolvessmoothly,showingrelativelyfewpacketlosses. When the first master is turned off, the sequence number evolution of some (but not all) of the motes exhibits a discontinuity;untilroutingconvergesagain,manypacketsarelost. Eventually,however,thoseconnections do recover and packets from the affected nodes are retransmitted to the master. We attribute the long routing convergence times to the high traffic rate in the network. A similar behavior is seen when the secondmasteristurnedoff. We also measured the rate of negative acknowledgements to estimate the efficacy of stream transport. For sources that were not affected by the route change, only 7% of the packets were lost end-to-end, despite a fairly heavy traffic load. By constrast, the number was 25% for those sources that were affected by master failure. Finally, using our tasking latency measurement tool, we measured the latency before andduringthisexperiment;theaveragetaskinglatencyincreasedthreefold(from137msto301ms). 3.5 Conclusions In this chapter, we have shown that the Tenet architecture simplifies application development for tiered sensor networks without significantly sacrificing performance. By constraining multi-node fusion to the 61 master tier, Tenet also benefits from having a generic mote-tier that does not need to be customized for applications. Our Tenet system is able to run applications concurrently, and our collections of tasklets support data acquisition, processing, monitoring, and measurement functionality. Many interesting re- search directions remain: energy management, support for mobile elements, network congestion control, extendingthetasklibrarytoincorporatearichertaskletset,andsoforth. 62 Chapter4 RCRT:Rate-ControlledReliableTransportProtocolforWireless SensorNetworks Emerginghigh-rateapplications(imaging,structuralmonitoring,acousticlocalization)willneedtotrans- port large volumes of data concurrently from several sensors. These applications are also loss-intolerant. Akeyrequirementforsuchapplications,then,isaprotocolthatreliablytransportssensordatafrommany sources to one or more sinks without incurring congestion collapse. In this chapter, we discuss RCRT, a rate-controlled reliable transport protocol suitable for constrained sensor nodes. RCRT uses end-to-end explicitlossrecovery,butplacesallthecongestiondetectionandrateadaptationfunctionalityinthesinks. This has two important advantages: efficiency and flexibility. Because sinks make rate allocation deci- sions, they are able to achieve greater efficiency since they have a more comprehensive view of network behavior. For the same reason, it is possible to alter the rate allocation decisions (for example, from one that ensures that all nodes get the same rate, to one that ensures that nodes get rates in proportion to their demands),withoutmodifyingsensorcodeatall. WeevaluateRCRTextensivelyona40-nodewirelesssen- sor network testbed and show that RCRT achieves 1.7 times the rate achieved by IFRC and 1.4 times that of WRCP, two recently proposed interference-aware distributed rate-control protocols. We also present resultsfroma3-month-long19-noderealworlddeploymentofRCRTinanimagingapplicationandshow thatRCRTworkswellinreallong-termdeployments. 63 0 0.5 1 1.5 2 2.5 3 3.5 0 0.2 0.4 0.6 0.8 1 Latency (hours) % of Packets Recvd Figure4.1: CDFplotofthepacketlatencyplotfromWisdendeployment,2004. 4.1 Introduction As sensor network software and hardware matures, it is becoming increasingly possible to conceive of a classofapplicationsthathasreceivedrelativelylittleattentionsofar—applicationsrequiringthetransport of high-rate data. Sources for high-rate data include imagers, microphones, and accelerometers. These sensors in turn motivate several interesting applications in surveillance, precision agriculture, structural damageassessment,andmilitarytargettracking. To support these emerging applications, we need to solve two problems. First, wireless sensors have limited radio bandwidth. A collection of sensors generating high-rate data can easily overwhelm the network to the point of congestion collapse, where the network is unable to perform useful work because its capacity is exceeded. Second, applications that use high-rate sensors of the kind described above are often loss-intolerant. For example, source localization algorithms [6] use time difference of arrival between comparable samples at different nodes, and structural monitoring algorithms estimate structural mode shapes [12] by correlating comparable samples observed at different nodes. Even if application data can be compressed to reduce bandwidth requirements [43], compression algorithms require reliable delivery. Butaprotocolforend-to-endreliabledeliveryofvoluminousdatacan,ifnotcarefullydesigned,result inpoornetworkperformance. Welearnedthislessoninadramaticwayduringourdeploymentofwireless sensors on the Four Seasons building in Los Angeles about 4 years ago [82]. In this deployment, sensor 64 nodes measured vibrations and transmitted it to a central node, over multiple hops, at a preconfigured fixed rate. During our deployment, severe network congestion occurred, a behavior we did not observe during extensive predeployment tests. Figure 4.1 plots the CDF of the packet latencies from the entire experiments for all nodes. (Reception time on the x-axis, percentage on the y-axis.) More than half the packetsweredeliveredmorethananhouraftertheywerefirstinjectedintothenetwork. Whilemanysensornetworktransportprotocolshavebeenstudiedintheliterature,mostofthemsolve oneofthetwoproblemsalreadyidentified(Section2.2): theyeitherprovidereliableend-to-enddeliveryof data from every sensor to a sink, or discuss a congestion control mechanism without ensuring end-to-end reliabledelivery. In this work, we discuss the design and implementation of a transport protocol that ensures reliable delivery of sensor data from a collection of sensors to a base station, while avoiding congestion collapse. However, we place two other requirements on the design of this transport protocol. First, unlike most existing proposals which, implicitly or explicitly, support only a single stream of sensor data from each network node, we require the network to be able to support multiple concurrent streams from each sensor node. We foresee that future sensor network deployments will be multiuser systems, with concurrently executingapplications. Second,whilemuchexistingworkhasassumedaspecificwaytoallocatenetwork capacity to all sensors (e.g., a fair allocation), we require our solution to separate the capacity allocation policyfromtheunderlyingtransportmechanisms. Itisunclear,yet,ifthereexistsasingletrafficallocation policythatwouldsatisfytheneedsofallsensornetworkapplications. Our solution, RCRT, has many different components, many of which are novel (Section 4.2). It uses relatively standard mechanisms for end-to-end reliable delivery; the base station (or sink) discovers miss- ing packets and explicitly requests them from the sensors. However, its congestion control functionality, in a significant departure from much of the prior work, is implemented in the sink. The sink has a com- prehensiveviewoftheperformanceofthenetwork,anditusesthisperspectivetocontroltrafficallocation in a more efficient way than would be possible with decentralized congestion control. RCRT employs a novel congestion detection technique, in which the sink decides that the network is congested if the time 65 to repair a loss is significantly higher than a round-trip time. Moreover, it decouples rate adaptation from rate allocation; that is, the RCRT sink first decides how much the total traffic needs to be reduced (or in- creased)inresponsetocongestion(orlackthereof),thenseparatelydecideshowtoallocatetheincreaseor decrease to different sources. This decoupling allows a network administrator to assign different capacity allocationpoliciesfordifferentapplications. We have implemented RCRT’s sink-side functionality on a PC-class platform (our code ports to em- bedded systems such as Stargates as well), and the sensor-side functionality on the Telosb, MicaZ, and Mica2 mote platforms. Our detailed evaluation (Section 4.3) of RCRT performance brings out many of its features: its ability to dynamically respond to congestion, its flexibility, robustness, and its support for multiple applications. More important, our evaluations show that RCRT is able to achieve 1.7 times the networkthroughputofIFRC[92]and1.4timesthatofWRCP[102],tworecentlyproposedapproachthat implements decentralized congestion control but does not guarantee end-to-end reliability. RCRT is able toachievethisbecauseitstrafficcontrolalgorithmsareabletobetterestimateandcontrolthenetworkca- pacity given the sink’s comprehensive perspective into network performance. Finally, we have employed RCRT in a 3-month-long moderate-sized real-world deployment of an image-based environmental moni- toringapplication,inwhich RCRT havecollected83millionpacketswith100%reliability,andshowthat RCRT iscapableofrunningrobustlyandefficientlyinlongtermrealdeployments. 4.2 RateControlledReliableTransport In this section, we start by describing the goals of RCRT and discuss how its overall design meets those goals. WethendelveintothedetailsofindividualcomponentsofRCRT:end-to-endreliability,congestion detection,rateadaptation,andrateallocation. Weconcludewithadiscussionof RCRT’slimitations. 66 4.2.1 DesignGoals RCRT isdesignedforsensornetworksinwhichsensorreadingsaretransmittedfromoneormoresensors (sources)toabasestation(orsink). Itisalsoapplicabletotieredsensornetworks[84],wheresensorsmay be transporting sensor readings to the nearest gateway (master, in the terminology of [84]), which in turn routes the messages to a designated upper-tier node (which we call the sink). RCRT does not require all sensors to be transmitting data. More generally, sensors may start and end data transmissions at arbitrary timesthatarenotknownapriori. Sixgoalsguidethedesignof RCRT.Theyareasfollows. Reliableend-to-endtransmission. Ourfirstgoalistoachievecompleteend-to-endreliabilityofalldata transmittedbyeachsensortoasink. Ofcourse,thisisonlypossibleifthenetworkisnotpartitioned: thatis, foreachsource,thereexistsanetworklevelpathtothesinkwhereeachlinkhasanonzeropacketreception rate. Thisgoalismotivatedbyemerginghighdatarateapplicationswhichareloss-intolerant;examplesof these applications include networked imaging [90], acoustic source localization [6], and structural health monitoring [13]. In each of these cases, processing algorithms are extremely sensitive to packet loss, and they are rarely interested in internode data aggregation. For example, source localization algorithms use time difference of arrival between comparable samples at different nodes, and structural monitoring algorithmsestimatestructuralmodeshapesbycorrelatingcomparablesamplesobservedatdifferentnodes. Ineithercase,thelossofsamplescanadverselyaffecttheaccuracyofthealgorithm. NetworkEfficiency. Oursecondgoalistomaintainthenetworkatanefficientoperatingpoint. Specif- ically, we wish to avoid congestion collapse [28], a regime in which sources are sending data faster than the network can transport them to the base station. In this regime, no useful work gets done by the net- work, since packets are repeatedly lost and continually retransmitted. In addition, we wish to ensure that sources transmit their sensor readings to the base station at as high a rate as possible. Since sources may start transmitting sensor readings at arbitrary times, this rate cannot be determined a priori, but must be adaptivelydiscovered. 67 Support for concurrent applications. Whilemuch priorworkonsensornetwork transporthasfocused on supporting a single sensing application, we wish to explicitly support multiple concurrent applications in RCRT. For example, a user might want to run a network diagnostic application while a sensing appli- cationisrunning,orrunanactuationapplicationdependingontheresultsreportedfromanenvironmental sensing application. Future sensor network deployments are likely to evolve to being multiuser or multi- applicationsystems,soitisimportanttoconsiderthisdesigncriterionattheoutset. Flexibility. Anothergoalistoallowdifferentapplicationstochoosedifferentcapacityallocationpoli- cies. A capacity allocation policy determines how the overall network capacity is divided up among the differentsources. Insomehomogeneousdeployments,whereallthesensorsaregeneratingdataatexactly the same rates, it may be necessary to divide up the capacity equally (in a fair manner). In other cases, somesources mightneed aproportionally larger allocation since, forexample, theymight betransmitting images. An important subgoal is that this flexibility should not come at the expense of requiring code modifications on the sensors; this is clearly desirable. This goal distinguishes our work from distributed congestion control mechanisms that implicitly embed a traffic allocation policy within the network. For example,IFRCcanonlysupportfairandweightedfairallocations[92]. Minimalsensorfunctionality. Wewishtokeepasmuchoftheprotocolfunctionalityoutofthesensors aspossible. Thisgoalismotivatedbytheconstraintsofthecurrentgenerationofsensors. Moregenerally, however, it is motivated by the observation that, for our problem, it is possible to achieve overall system simplicitybymovingasmuchoftheintelligenceaspossibleoutofthesensornetworkandintothesink. Robustness. Finally, we require that RCRT be robust to routing dynamics and to nodes entering and leaving the system. This implies that traffic allocations to sensors can dynamically change, as can the locationsofcongestednodes. Thesystemmustbeabletodynamicallyadapttothesechanges. 4.2.2 RCRTOverview To describe RCRT, we introduce the following notation and terminology. We define a sink as an entity (softwareprogram,orpartthereof)whichrunsonabasestation(oranupper-tiernodeinatierednetwork) 68 Function Where How End-to-end Source End-to-endNACKs LossRecovery andSink CongestionDetection Sink Basedontimetorecoverloss RateAdaptation Sink Basedontotaltraffic,withadditiveincrease anddecreasebasedonlossrate RateAllocation Sink Basedonapplication-specified capacityallocationpolicy Table4.1: RCRTComponents and which collects data from one or more sensors (sources). LetS be the set of sensor nodes that have data to send to a sink, andK the set of all sinks in the network. RCRT is oblivious to the kind of data sourced by the sensors: they can be raw samples, processed time series, images, and so forth. More than one sink can be running concurrently in the sensor network. We use the notation f i,j to denote the flow of data from source i∈S for sink j∈K. Of course, this flow is delivered from the source over (possibly) multiple hops to the base station. A sensor i may source several flows f i,j for different sinks j. Finally, each sink j is associated with a capacity allocation policy P j which determines how network capacity is divided up across flows f i,j for∀i∈S. The simplest P j is one in which each flow f i,j gets an equal share ofthenetworkcapacity(afair allocation). WegivemoreexamplesofP j later. RCRTprovidesreliable,sequenceddeliveryofflows f i,j . Furthermore,RCRTensuresthat,foragiven application j,theavailablenetworkcapacityisallocatedtoeachflowaccordingtopolicyP j . Specifically, eachflow f i,j isallocatedarater i,j (t)ateachinstantt thatisinaccordancewithpolicyP j . Thus,forafair allocationpolicy,allsensorswouldreceiveequalr i,j (t). How does RCRT achieve all this? Table 4.1 describes the various components of RCRT. End-to-end reliabilityisachievedusingend-to-endnegativeacknowledgments. AparticularlynovelaspectofRCRTis that its traffic management functionality resides at the sink. Specifically, each sink determines congestion levels and makes rate allocation decisions. Once sink j decides the rate r i,j , it either piggybacks this rate onanegative acknowledgment packet, or sendsaseparate feedback packet, tosource i. Thesource nodes simplyreacttothefeedbackprovidedbythesink. 69 At the sink, RCRT has three distinct logical components. The congestion detection component ob- servesthepacketlossandrecoverydynamics(whichpacketshavebeenlost,howlongittakestorecovera loss)acrosseveryflow f i,j ,anddecidesifthenetworkiscongested. Onceitdeterminesthatthenetworkis congested,therateadaptationcomponentestimatesthetotalsustainabletrafficR(t)inthenetwork. Then, the rate allocation component decreases the flow rates r i,j (t) to achieve R(t), while conforming to policy P j . Conversely, when the network is not congested, the rate adaptation component additively increases the overall rate R(t), and the rate allocation component determines r i,j (t). In our current implementation, multiple sinks do not cooperate with each other to determine congestion, adapt or allocate rates; doing so is likely to provide higher efficiency gains and a more equitable rate allocation, and we have left this to futurework. RCRT satisfies our design goals (Section 4.2.1). By design, it provides end-to-end reliability and attempts to keep the network operating efficiently while supporting multiple applications, each with its own capacity allocation policy. Much of the traffic management functionality in RCRT is centralized at thesink,keepingthesensorsassimpleaspossible. Finally, our assumptions about the link layer and the routing layer are largely consistent with current practice. Although our experiments are conducted using the default CSMA MAC layer in TinyOS, the design of RCRT does not depend on any features specific to a particular MAC layer. Link-level retrans- missionsattheMAClayercanimprovetheperformanceof RCRTbutarenotessentialforitscorrectness. WediscussthisinmoredetailinSection4.2.8,andverifyourargumentthroughevaluationinSection4.3.4. Weassumethatthesensornodesrunaroutingprotocolthatdynamicallyselectsapathfromeachnode to the sink and also a reverse path from the sink to each node. Also, RCRT does not assume symmetric routing between a source and the sink. Our experiments (Section 4.3) are conducted using TinyOS’s tree- basedroutingprotocol,MultiHopLQI,butcanworkwithotherroutingprotocolssuchasCentRoute[104] thatsatisfytheserequirements. Finally, RCRT focuses on the transport protocol itself. Cross-layer techniques for congestion control thatexploitradio,MAC,orroutingprotocolfeaturesarebeyondthescopeofthiswork. 70 In the following sections, we discuss the detailed design of RCRT. As we have described, RCRT sinksactindependently inrateallocationdecisions. So,inwhatfollows,wedropthesubscript j,withthe understandingthatallthebehaviordescribedfurtheronreferstoasinkanditsassociatedflows. 4.2.3 End-to-EndReliability UnlikeTCP[51], RCRT implementsaNACK-basedend-to-endlossrecoveryschemetoguarantee100% reliable data delivery. The sink detects packet losses and repairs them by requesting end-to-end retrans- missions from source nodes. This design leverages the fact that the base station has significantly more memory and can keep track of all missing packets. Each sensor node stores a copy of every data packet that it originates in its local retransmit buffer when transmitting the packet to the sink. The sink keeps track of sequence numbers of packets that it receives on each flow. A gap in the sequence number of received packets indicates packet loss. The sinkmaintains alistof missingpackets per flow. When losses are detected, the sequence numbers of the lost packets are inserted into this list. Entries in this list of missing packets are sent as negative acknowledgments (NACKs) by the sink to each source. The use of NACKs avoids an “ACK implosion” [31], where the acknowledgments of successful receptions sent by thesinkoverwhelmthenetwork. UponreceivingaNACK,thesourceretransmitstherequestedpacketsto repairthelosses. Also,thesourcedetermineswhenitcansafelyoverwritepacketsintheretransmitbuffer by looking at the cumulative ACK sequence number piggybacked in all feedback packets (Section 4.2.7 describescumulativeACKsandfeedbackpackets). Thesinkalsomaintainsalistofout-of-orderpacketsforeachflowtoprovidein-orderdeliveryofdata packetstotheapplication. Thislistcontainspacketsthatarereceivedatthesinkbuthavenotbeenpassed to the application layer because there are one or more gaps in the sequence numbers. For example, if sequencenumbers[1,2,3,5,6]havebeenreceivedsofar,packets5and6areinsertedintotheout-of-order packets list. When packet 4 is received, the sink passes packets 4,5,6 to the application and removes 5,6 fromtheout-of-orderpacketslist. 71 RCRTusestheper-flowlistsofmissingandout-of-orderpacketsfordetectingcongestionandadapting rates,asweshalldiscussbelow. 4.2.4 CongestionDetection An important technical challenge for RCRT is the design of a mechanism for congestion detection. Var- ious techniques have been proposed in the wireless and sensor network literature to measure the level of congestion at a node. Broadly speaking, these techniques either directly measure the channel utilization around a node [112], or measure the queue occupancy at the node [47, 92]. These techniques are similar in spirit to approaches that attempt to detect incipient congestion in Internet routers [30, 52]. By contrast, RCRTattemptstomeasure,atthesink,whetherthenetworkiscongested. Thisapproachiscloserinspirit to approaches in wired networks that have attempted to detect congestion at the ends [51, 91], but with one important difference: in RCRT, a sink has a more extensive view of network performance than, for example,aTCPsender,sincethesinkreceivestrafficfrommanysources. However,itwouldbeincorrecttomerelyborrowcongestiondetectionmethodsusedinwirednetworks. For example, TCP uses a single packet drop to infer that the network is congested. In a wireless network, itiswellknownthatsuchacongestiondetectionmechanismcanresultinextremelypoortransportperfor- mancebecausewirelesslinkstendtoexhibitrelativelyhighpacketlossrates. Accordingly, RCRT bases its congestion detection mechanism on a completely different approach. This approach is in line with RCRT’s primary goal of providing end-to-end reliability. Its congestion detectionmechanismisbasedonthefollowingintuition,derivedfromourearlyexperimentaldeployment and discussed in Figure 4.1: that the network is uncongested as long as end-to-end losses are repaired “quicklyenough”. Thisintuitionpermitsafewend-to-endlossescausedbytransientcongestion,orbypoor wireless links. Furthermore, it permits the sources to transmit at a higher rate even if there are occasional end-to-endlosses,sincethoselossescanberecoveredbythemechanismdescribedintheprevioussection. Forthisreason, RCRT usesthe“timetorecoverloss”asacongestionindicator. 72 Recall that RCRT maintains a per-flow list of packets that have been received out of order, and also a per-flow list of packets that are missing (Section 4.2.3). Now, the sum of the length of these two lists minus 1 indicates how many packets should have been received after the first unrecovered packet loss, which reflects how much time has passed since the first unrecovered loss. Ideally, we would want the average time taken to recover a loss to be around one round trip time (RTT). If that property holds, the network is not congested in the sense that loss recovery is functioning properly. If it takes more than few RTTs to recover the losses, then the network is more likely to be congested. Since the expected number ofpacketsreceivedduringoneRTTisr i RTT i ,ifthesumofout-of-orderpacketlistlengthandthemissing packetlistlengthisr i RTT i ,thenroughlyoneRTThaspassedsincethefirstunrecoveredloss(recallthatr i istherateassignedtosourcei;wehaveomittedthetimedimensioninthenotationforsimplicity). Denote byF i thelengthofsourcei’sout-of-orderpacketlist,andbyG i thelengthofsourcei’smissingpacketlist, atsomeinstant. Then V i = F i +(G i −1) r i RTT i is a measure of the number of RTTs it would take to recover the loss. RCRT uses the exponentially weighted moving average of this value V i as the measure of average congestion level, denoted by C i , for source i. Thus, C i = 2 means that it takes around 2 RTT i ’s on average to repair losses for node i. (Section4.2.7explainshowRTTisestimated.) RCRT detectscongestionbyusingasimplethresholdingtechnique. IftheC i exceedsanupperthresh- oldU for any source i, we say that the network is congested. RCRT declares the network underutilized whenC i falls below a lower threshold L for every i. The gap betweenU and L is the desired congestion levelinsteadystatethatallowsforsomelossestoachievehigherthroughputwhileensuringtimelylossre- covery. RCRT updatestheC i sforeveryflowwheneverapacketisreceivedfromthatflow. Itthendecides whether the network is congested or underutilized or otherwise, based on the algorithm described above. RCRT performsdifferentactionsinthecongestedandunderutilizedstates,asdescribedinSection4.2.5. 73 We use L = 0.2 and U = 2 as our thresholds, and the intuition behind this is as follows. The lower thresholdL=0.2correspondstothecasewherealostpackettakesaroundoneRTTtorecoverandroughly one packet gets lost every five successful data packets ( (1+0+0+0+0) 5 =0.2). If the packet losses are less frequentthanthisandarerecoveredwell,thenetworkshouldnotbecongested. TheupperthresholdU =2 correspondstothecasewhereapacketislosteveryfivesuccessfuldatapackets,andthislossisrecovered only after around four RTTs ( (1+2+3+4+0) 5 = 2). On the one hand, thresholds should be conservatively large since a flow’s RTT i increases dramatically when the network transitions from an uncongested to a congested state. On the other, small thresholds can account for the fact that C i is lower than the actual time to recover loss since it is averaged over successfully received packets as well as the losses. Thus, largevaluesforLandU willincreasetheratesfaster,butmayresultinoscillatorybehavior. SmallerLand U will allow RCRT to be more stable, but may require a longer convergence time. A high L and lowU maybefastandstable,butthesmallergapbetweenthemwillleadtofrequentratechangesthatwillincur higherfeedbackoverhead. Weexperimentallychooseourthresholdvaluestobalancetheseconstraintsand ensure that RCRT reacts to congestion in a timely manner, but does not react to congestion earlier than it should. 4.2.5 RateAdaptation ThesecondmajorchallengeinRCRTisthedesignofamechanismtoadapttransmissionratesinresponse to congestion (or lack thereof). Rate adaptation techniques have been studied widely in the literature. Most transport protocols additively increase flow rates (or, as in TCP [109], windows) in the absence of congestion,andmultiplicativelydecreaseflowrateswhencongestionisdetected. ChiuandJain[14]show that this AIMD approach guarantees stability and convergence to a fair and efficient allocation. While RCRT uses AIMD, it adapts the total aggregate rate of all the flows as observed by the sink, rather than the rate of a single flow. In spirit, this is similar to XCP [52], but there are some qualitative differences: XCP’s decisions are made at abottlenecked router, and XCP adapts ratebased on the excess capacity at a link. Wedescribe RCRT’srateadaptationdesignnow. 74 LetR(t)denotethesumofthecurrentlyassignedratesr i (t)forallflowsi. RCRTusesAIMDonR(t). Whenthenetworkisnotcongested, RCRT increasesR(t)additively, Increase: R(t+1)=R(t)+A, where Aisapositiveconstanti, 1 independent ofthenumberofflowsinthenetwork. Whenthenetworkis congested, RCRT decreasesR(t)multiplicatively: Decrease: R(t+1)=M(t)R(t), whereM(t)∈(0,1]isatime-dependentmultiplicativedecreasefactor. Thesymbolt representsthediscrete time instants at which RCRT makes rate adaptation decisions. An alternative design would have been to individually control the rates of each flow. However, since the sink has a greater perspective into network performance, designing the rate adaptation to control the total aggregate rate of the network allows the control algorithm to be independent of the number of flows, and less oscillatory when there are a large numberofflows. Two questions remain: When are rate adaptation decisions made? How is M(t) determined? We addressthesequestionsnext. Whenever RCRT determinesthenetworkiscongested(Section4.2.4),itappliestheratedecreasestep we have described, computes a new rate allocation for all the flows (Section 4.2.6), and sends the new rate r i for each flow to the corresponding source. It does not make another rate reduction decision until it observestheeffectsofthepreviousdecision. Todothis,RCRTwaitsconservativelyforatleastthreetimes the maximum value of RTT i . This usually allows enough time for the rate feedback to reach the sources, and for the sources to send enough packets so that congestion measures at the sink are appropriately updated. Thereafter, if a packet is received from some flow i, andC i is still above the upper thresholdU, anotherratedecreasestepistriggered,butonlyif f i reportsthatitisusingtherateassignedintheprevious 1 WehaveusedA=0.5pkts/secforourexperiments. 75 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 Rate (pkts/sec) Offered Load r i (t) 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 0.5 0.6 0.7 0.8 0.9 1 Packet delivery ratio Offered Load r i (t) Total traffic r i ’(t) Capacity x=y line Packet delivery ratio p i Total traffic after reduction r i ’(t+1) New rate after reduction r i (t+1) Figure 4.2: Plot of p i , corresponding total traffic r i (t) ′ = r i (t)(2−p i ) p i , and effect of M(t) where p i has been polynomial curve-fitted from the experimentally collected data. r i (t+1) is the new rate after M(t) reduc- tion, and r ′ i (t+1) is the expected total traffic after M(t) reduction. X-axis is the offered load r i . Y-axis representbothpacketdeliveryratio p i (rightaxis),andtheexpectedtotaltrafficr i (t) ′ (leftaxis). rate adaptation step. This last check ensures that RCRT does not react to stale information; especially in times of congestion, RCRT’s RTT estimates can be slightly off and this step ensures that RCRT reacts only after the source has had a chance to respond to the previous rate adaptation. Finally, if the network is underutilized, RCRT applies the increase rule above, but only if three times the maximum RTT i plus threetimesthecurrentinterpacketinterval(1/r i )hasexpiredsincethelastrateadaptationdecision. Inthe rate regime at which sensor networks operate, the interpacket interval can sometimes be higher than the RTT; using three interpacket intervals reduces the frequency of feedback generation during rate increase, at the expense of a more conservative increase. RCRT also refrains from increasing the rate if there are unrecoveredburstlosses 2 inanysinglenode,eveniftheirC i isbelow L. Weaddedthisrulebecauseburst losses at low C i are often a symptom of the onset of congestion, when a flow moves from uncongested statetoacongestedstate. In most transport protocols, the multiplicative decrease factor is constant (0.5 in TCP). However, be- cause RCRT hasacomprehensiveviewofnetworkbehavioracrossdifferentsources,itcandobetterthan simply halve R(t). In RCRT, when a packet is received from flow f i and that packet causesC i to exceed 2 Wecurrentlydefinethreeconsecutivelossesasburstlosses. 76 theupperthresholdU,M(t)iscomputedbasedonthelossrateexperiencedby f i . Whatistheintuitionfor this? Supposethat f i ’spacketdeliveryratiois p i . Thismeansthat,everysecond, r i p i packetsoutof r i are being delivered to the sink without end-to-end loss. Furthermore, feedback traffic, roughly proportional to r i (1−p i ) must be delivered by the sink to the source in response to these losses. 3 Then the expected amountoftraffictoandfromthesinkis r i p i and r i (1−p i ) p i respectively. Thisaddsuptototaltrafficofatleast r ′ i = r i (2−p i ) p i fornodeiinthenetwork. We know that this level of traffic (r ′ i (t)) was not sustainable, since the flow was congested. But, the lasttimethatarateadaptationdecisionwasmade,asourcerateofr i (t)wasdeemedsustainable,assuming no end-to-end losses. Given a packet delivery rate p i , it would now be safe to set f i ’s rate such that the total amount of traffic is r i (t). To do this, we should reduce f i ’s rate to: r i (t +1) = p i 2−p i r i (t), so that r ′ i (t+1)≡r i (t). However, RCRTisalittlebitmoreconservativethanthat. Itreducestheoveralltotalrate R(t)bythatfactor,bysettingthemultiplicativedecreasefactorM(t)tobe: M(t)= p i (t) 2−p i (t) where f i is the flow that triggers the rate decrease. M(t) is larger than 0.5 for all p i greater than 0.67. So, in regimes where the end-to-end packet reception rate is high, RCRT can more efficiently adapt to congestionthanprotocolsthatemployafixedmultiplicativedecreasefactorof0.5. WenowgivesomeintuitionforhowM(t)behavesfordifferentvaluesofr i (t). Todothis,weconducted an experiment consisting of 40 nodes, and measured the average or smoothed value of p i as a function of r i . This is shown in Figure 4.2. Also shown in that figure is 1) the total network traffic corresponding to a given r i (labeled r ′ i (t)), 2) the value r i (t +1), which is the rate that would have been assigned to node i by RCRT after its multiplicative decrease, and 3) the value r ′ i (t+1), which is the expected total network traffic corresponding to r i (t+1) after the multiplicative decrease. For this network, the network was empirically determined to be saturated at 1.1 pkts/sec per node (Section 4.3). Note that the estimated 3 In RCRT, a list of missing information can be packed into a single NACK. In this analysis, we assume that only one missing packetisincludedineachNACKpacket. Thiscanhappenwhenthelossesareinfrequentandspreadoutuniformlyovertime. 77 totaltrafficr ′ i (t)increasesdrasticallyastheofferedloadr i increasesabovethiscapacityline. We’dliketo point out two important properties of M(t). First, regardless of the value of r i , M(t) is always successful in assigning a rate r i (t+1) that keeps the aggregate rate below overall capacity, but also ensures that the expectedtotaltrafficr ′ i (t+1)isbelowcapacity. Second,M(t)ismoreaggressivewhenr ′ i (t)iswellabove the network’s capacity. These two properties imply that M(t) is sufficient to move RCRT out from a congested state to an uncongested state regardless of when the congestion was detected and rate decrease wastriggered. Moreover,thisdetectionisrapid: evenifseveralpacketsarelostduetocongestion,asingle successfuldeliverysufficestotriggeraratedecrease. Loss Rate Estimation. Thus far, we have not described how p i (t) is calculated. RCRT keeps track of estimatedpathlossrate(1−p i (t))foreachflowusingtheAverageLossIntervalmethoddiscussedin[29]. It uses the average interval (in number of packets) between loss events to estimate the loss rate of a flow. Denotetheintervalbetweenm-thandm+1-thlossonflowiass i,m . Then,fortherecent1≤m≤nlosses, theaveragelosseventinterval ˆ s i forflowiiscalculatedas ˆ s i(1,n) = ∑ n m=1 w m s i,m ∑ n m=1 w m ˆ s i(0,n−1) = ∑ n−1 m=0 w m s i,m ∑ n m=1 w m ˆ s i =max(ˆ s i(1,n) ,ˆ s i(0,n−1) ), where s 0 is the interval since the most recent loss and w m is the weight given to each loss interval in the history. The larger of the two quantities ˆ s i(1,n) and ˆ s i(0,n−1) is selected so that the most recent loss with small s 0 does not cause severe underestimation of ˆ s i . We have followed the analysis in Floyd et al. [29] andusedn=8andw=[1,1,1,1,0.8,0.6,0.4,0.2]asourparameters. Intuitively,thesechoicesgivegreater weighttorecentlossperiods,andlesserweighttomoredistantlossevents. Thenwecompute p i (t)from 1−p i (t)= 1 ˆ s i (t) , 78 WechosetheAverageLossInterval(ALI)methodoverothersafterexperimentallyverifyingthatitwas more robust to parameter choices than the alternatives. A window-based method that estimates loss rates based on some window of the number of packets or time is highly sensitive to the choice of window. An EWMAapproachissensitivetothechoiceofgain,andincludesasignificanthistoryoflosses. Bycontrast, the ALI method always looks at a fixed number of loss events, and preferentially weighs the recent ones. Thishelps RCRT bemoreresponsivetotheonsetofcongestion. 4.2.6 RateAllocation OncethetotalrateR(t)iscalculatedbytherateadaptationmechanism,theroleof RCRT’srateallocation componentistoimplementthecapacityallocationpolicyP j associatedwithitssink. Thisisanovelaspect ofRCRT;toourknowledge,mostpriorworkhas(implicitlyorexplicitly)embeddedacapacityallocation policywithintherateallocationmechanism. RCRT’s rate allocation component essentially assigns rates r i (t) to each flow in keeping with the rate allocation policy P j such that the individual flow rates sum up to R(t). Because RCRT decouples rate adaptation from rate allocation, it is possible to obtain this flexibility. We see this flexibility as being crucial,sinceitisunclearthatthereis,apriori,apreferredpolicyforsensornetworks(unliketheInternet, whichisasharedinfrastructure,andforwhichsomeformoffairnessmakessense). RCRT’srateallocation componentissimilartoXCP’s[52]fairnesscontroller,butoffersgreaterflexibility. Ourcurrentprototypecontainsthreedifferentpolicies. Demand-proportional. In this policy, each flow expresses a desired rate, that we call its demand d i . This policy allocates rate r i to each node i proportional to its demand d i such that the fraction (r i (t)/d i ) is thesameforalli; r i (t)/d i =ρ(t) ∀i∈S. 79 As long as we use sameρ(t)=ρ i (t) for all node i, demand-proportional allocation follows. We compute ρ(t)asfollows: D= ∑ i∈S d i R(t)= ∑ i∈S r i (t) ρ(t)= R(t) D , (4.1) whereDisthesumofalld i s. Then,thenewrateforeachnodeisimplybecomes: r i (t)=ρ(t)·d i Demand-limited. In this policy, R(t) is divided among all the flows equally, except that no flow gets a higher rate than d i . Given R(t), there exists a simple greedy algorithm for computing a demand-limited rateallocation. Fair. ThisallocationpolicyassignsanequalshareofR(t)toallflows,regardlessofd i . Flowdemands areignoredinthispolicy. As an example, consider a scenario where two nodes A and B demands for 1 pkt/sec and 2 pkts/sec respectively, and the network can only support 2.4 pkts/sec total. Then, the Demand-proportional policy will allocate 0.8 and 1.6 pkts/sec, the Demand-limited policy will allocate 1.0 and 1.4 pkts/sec, and and theFairpolicywillallocate1.2and1.2pkts/sec,tonodesAandBrespectively. While we have not experimented with other policies, our prototype software is written modularly to easily accommodate other policies. For example, it is easy to implement a weighted allocation policy, where each source gets a rate allocation proportional to a configured weight w i (weighted allocation is similartodemand-proportionalallocation,withtheonlydifferencethatinthelatter,asourceisnotassigned 80 aratehigherthanitsdemand). Thisweightedallocationpolicyisageneralizedformofpriorityallocation, inwhichsomenodesaregivenhigherprioritythanothers. Finally,newrateallocationpoliciesshouldnot requireanychangestotheprotocol(ortocodeonthesensors)—theycansimplybeconfiguredatthesink. 4.2.7 OtherDetails In our description, we have left out several details of RCRT.We describe them here briefly for complete- ness. Source Node Behavior: In RCRT, each source node initiates a flow by first establishing an end-to- end connection with the sink. RCRT uses a three-way handshake connection establishment mechanism similar to that of TCP where the third ACK is substituted with the first data packet. While doing this, the source tells the sink its desired data rate d i (although this information can, in principle, also be just configured at the sink), and the sink tells the node the rate r i . This three-way handshake also allows RCRT to guess an initial RTT estimate. Once a connection has been established, the node transmits packets on this connection. Each node originates data at rate at most r i assigned by the sink. The rate r i is enforced by a token bucket with rate r i . Each packet contains sequence number, flow ID, and the rate of the corresponding flow. The rate r i regulates only the new packets that are sourced by this node. End- to-end retransmissions are not constrained by this rate, nor are forwarding and link-level retransmissions performedthelowerlayersoftheprotocolstack. Since rate allocation and loss recovery are controlled end-to-end by the sink, each node simply reacts tothesink. Whenanodereceivesapacketfromthesinkwithnewrater ′ i (thisisusuallysentinafeedback packet which may or may not contain NACK information, as will be explained), the node adjusts the tokenbucketrateaccordingly. WhenanodereceivesafeedbackpacketwithNACK information,thenode retransmitsthosemissingpackets. Finally, each source has a fixed-size retransmit buffer which contains sent packets that have not been acknowledged. Clearly, a source cannot store an infinite number of packets for potential retransmission. To efficiently manage the retransmit buffer, each feedback packet (described in the following) includes a 81 cumulative ACK sequence number, which indicates the last sequence number that the sink has received contiguously without any missing packets. The source can safely remove packets in the retransmit buffer thatarecoveredbythecumulativeACKsequencenumber. When the retransmit buffer is full, the source stops sending new packets and retransmits the packet whose sequence number is one higher than the last acknowledged packet at a rate of min( r i 2 , 1 RTT ). The source does this until it is told that the sink has received those packets and hence it is safe to overwrite the buffers. When this packet has been received at the sink, loss recovery is triggered, the rate is adjusted for all nodes, and a feedback packet is sent. The retransmit buffer rarely fills up since a cumulative ACK is piggybacked in every feedback packet. Additionally, to prevent a stall, each source requests explicit feedback from the sink when its retransmit buffer is more than half full. It does this by setting a bit in every outgoing packet. To minimize the number of feedback transmissions while allowing for enough packetstobeintransit,thebuffermustbelargeenough(>>2r i /RTT i packets). Feedback packets: Every feedback packet sent to a source i contains the assigned rate r i , a list of NACKed sequence numbers, a cumulative ACK, and the RTT avg (see below) value for that node. Thus, every feedback packet is completely self-contained so that, even if one of these is lost, a subsequent feedbackpacketsufficestoadjustthenode’srate,andrecoverfromloss. RCRT hastobecarefulinsendingfeedbackpackets,sincetheyrepresentsignificantoverhead. When apacketisreceivedatthesinkfromnodei,thesinksendsafeedbacktothenodeonlywhenatleastoneof thesefourconditionshavebeenmet: oneormoremissingpacketshavebeendetected;thenodeissending at a rate different from the assigned rate; a duplicate packet with an already acknowledged sequence number has been received; or, a feedback packet has been explicitly requested by the node. However, RCRT is careful not to send feedback more often than once every RTO i , defined as RTT avg +2∗RTT var , where RTT avg is the average RTT (see below), and RTT var is the mean deviation of RTT. This rate limit tradesoffincreasedconvergencetimeforloweroverhead,especiallyintimesofcongestion. Finally,recall that rate adaptation decisions are made on RTT time-scales, also reducing the rate of sending feedback packets. 82 RTT estimation: Finally, the sink estimates the RTT of each node using feedback packets. RCRT doesnotrequireanytimesynchronizationmechanismtodothis. ThesinkrecordsthetimeT i whenitsends a feedback packet to node i. Node i remembers the time T ′ i at which it had received the feedback. When node i next sends a packet to the sink at time T ′′ i , it calculates the interval T ′′ i −T ′ i and piggybacks this valueinthepacket. UponreceptionofthispacketattimeT ′′′ i ,thesinkcancalculatetheinstantaneousRTT sample value RTT inst,i by (T ′′′ i −T i )−(T ′′ i −T ′ i ). RCRT uses an exponentially weighted moving average ofthisvaluetogettheestimatedRTT avg,i fornodei. Earlierinthissection,whenwehavereferredtoRTT i , wehavemeantRTT avg,i . 4.2.8 Discussion Three minor details of RCRT are worth mentioning. One is that any NACK-based scheme suffers from not being able to detect the loss of the last packet (or the contiguous loss of the last few packets), since it relies on the successful reception of a later packet. In RCRT, we detect and recover from such losses during connection tear-down: after they are done sending data, sources explicitly tear down the transport connection, at which point they synchronize sequence numbers and repair the last loss (if any). The second is that in large networks, the maximum RTT can be high and since RCRT makes decisions on RTTtimescales,thenetworkmayconvergeslowly. Thethirdisthecasewhenseveralconsecutivepackets are lost due to high congestion. Until a subsequent data packet is received, the sink will not notice the congestion, hence RCRT’sreaction may be delayed. RCRT’sreaction may also be delayed when several consecutive feedbacks are lost due to high congestion. However, at least one packet from at least one of the congested nodes will eventually be delivered, and this will bring the rates down sufficiently (M(t), Section4.2.5). Thereducedrateswillbeappliedtoatleastthenodesthatcanreceivethefeedbackpackets, andthisinturnwillmakesomecapacityroomforthefeedbackpacketstoreachtheothercongestednodes. Hence, RCRT willregaincontrol. A fourth detail requires a little more explanation. Our current RCRT implementation uses link-level retransmissions, and a natural question to ask is: how would RCRT perform in the absence of link-layer 83 retransmissions? To us, this question is ill-posed: in wireless networks with link loss rates approaching 30%,tryingtodesignanend-to-endARQ-basedreliabilitymechanismwithoutlink-layerretransmissions is a fundamentally bad idea, since it would rely on expensive end-to-end retransmissions to repair loss. Thatsaid,withalimitonthenumberofretransmissionsasin RCRT,theremaybescenariosinwhichthe end-to-endpacketdeliveryrateisstilllow. Inthiscase, p i (Section4.2.5)willbelow,andthemultiplicative decrease factor could be lower than 0.5 (the constant multiplicative decrease used by TCP). Thus, in this regime, RCRT may be more conservative than TCP’s AIMD, but that mechanism it not known to work wellinlossyconditionsanyway;itisunrealistictoexpectefficientandreliabledeliveryinanetworkwhere thepacketdeliveryratioisextremelypoor. Inthoseconditions,thebestapproachwouldbetoreprovision the network by redeploying some nodes, or adding capacity using extra nodes or introducing tiers. We evaluatetheeffectoflink-levelretransmissionsinSection4.3.4. Finally,weaddressthequestion: does RCRT reallyavoidcongestioncollapse? Therearetwocasesto consider. Whensourcenodeshearfeedbackfromthesink, RCRT’smultiplicativedecreasefunctionM(t) (Figure 4.2) aggressively reduces source sending rates, allowing the network to recover from congestion. When a source does not hear feedback, the source sends at r i (t) for a while, but it eventually fills up its retransmitbufferandstalls,effectivelysendingonepacketperRTT(Section4.2.7). Thisisaconservative solution, since the source needs to “probe” by sending at least one packet to recover from transient path failures, and the RTT is the right timescale to do this. (Of course, more conservative approaches, like exponentially backing off the probe interval are possible, and we have left these to future work). When it isstalled,thesourcedoesnotcongestthenetwork,allowingthenetworktorecover(if,indeed,thelossof feedbackpacketswascausedbycongestion). There are several open questions in the design of RCRT. First, we have not examined intersink coop- eration. Having such a mechanism in place would help administrators control capacity allocation across different applications and provide higher efficiency gains. Second, our current design does not support a policy that gives excess bandwidth to unconstrained sources. In most of the topologies we have ex- perimented with, almost all sources are constrained by one bottleneck wireless region. However, there 84 can exist topologies where some sources may not be so constrained, and it might be beneficial to allocate higher rates to these sources while rate limiting the congested sources only. Since RCRT does not have insight into the network, it cannot easily distinguish between these sources. Even if the sink observe a set ofuncongestedflows,itcannotdeterminehowthoseflowsinterferewithotherflows. So,tryingtoallocate higherratetothoseflowsmightexacerbatecongestiononotherflows. Finally, we conclude with a discussion of an important aspect of congestion control design that we have ignored so far: what should the “application” do if the data generation rate exceeds the rate offered by the congestion control protocol? Or, how should the application adapt to the rate control performed by the network stack? Prior work in congestion control for WSN has assumed infinite backlog of data that can be arbitrarily delayed or dropped. However, we argue that the application should adapt to rate control. Applications can adopt many methods to ensure that the offered rate matches the rate that can be supported by the underlying network. Simple periodic sensing applications can subsample the stream so that the user-perceived quality degrades more gracefully. However, such subsampling should be ac- companied by appropriate low pass filtering to avoid altering the spectral characteristics of the data. Bulk transfer applications can either adjust the chunk generation rate, use adaptive compression techniques, or employlocalprocessing. Tosupportsuchadaptation,atransportprotocolmustprovidepreciseandtimely information about the currently achievable rate to the application, and RCRT is capable of providing this information. 4.3 Evaluation In this section, we present results from an extensive performance evaluation of our implementation of RCRT onawirelesssensortestbed. 85 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 Figure4.3: AsnapshotofroutingtopologyconstructedbyMultihopLQI. 4.3.1 ImplementationandMethodology WehaveimplementedRCRTinTinyOSforthemotes 4 andinCforaPC-classsinkdevicerunningLinux. The RCRT module on the motes provides a transport-layer interface that a sensor application can use to initiate a flow to the sink and send data packets. Also, the module implements a token bucket, whose rate is set to the rate allocated by the sink, to regulate data packets generated at that node. The memory footprint of RCRT for the mote is approximately 5252 code bytes and 374 bytes of RAM for a packet payload size of 64 bytes. The code size excludes RCRT-independent basic components such as timer, flash, MAC, and routing. It uses 64KB of external flash for a retransmit buffer. All other mechanisms described in Section 4.2 including loss detection, rate adaptation, rate allocation, congestion detection, andRTTestimationareimplementedatthesink. We have evaluated our RCRT implementation on an indoor wireless sensor network testbed 5 . Most experiments areconducted on a40-node subset of this testbed, but wealsoshow resultsfrom some larger topologies. EachsensornodeinourtestbedisaMoteivTmotewithan8MHzTI-MSP430microcontroller, IEEE 802.15.4-compatible CC2420 radio chip, 10KB RAM, and a 1MB external serial flash memory. Thesemotesaredeployedover1125squaremetersofalargeofficefloor. We have used MultihopLQI in TinyOS as our routing tree protocol and default CSMA in TinyOS as our MAC protocol for our experiments. In MultihopLQI, each node dynamically selects its parent to 4 RCRT hasbeenimplementedinbothTinyOS1.xandTinyOS2.xandtheirperformancearesimilar. 5 Tutornet: TieredWirelessSensorNetworkTestbed. (http://enl.usc.edu/projects/tutornet/) 86 DesignGoal Section Reliableend-to-endtransmission All NetworkEfficiency Section4.3.2.1 Section4.3.2.2 Section4.3.2.5 Section4.3.3 Supportforconcurrentapplications Section4.3.2.4 Flexibility Section4.3.2.4 Section4.3.2.3 Robustness Section4.3.2.3 Section4.3.3 Table4.2: ExperimentstoDemonstratethat RCRT MeetsitsGoals. construct a routing tree to the base station using the link quality indicator provided by the CC2420 radio chip. Since a sink-to-mote reverse path is required in RCRT (for the feedback packets), we have added a data-driven reverse path construction mechanism. This works as follows. Each node maintains a routing table. When it receives a packet with source address S from a neighbor N, it adds a route entry to S with next hop N. Feedback packets are forwarded using this routing table. Finally, our implementation uses link-layerretransmissionsbasedonchip-levelacknowledgmentswithupto4retransmissionsunlessstated otherwise. Weexperimentwithdifferentlink-layerretransmissionstrategiesinSection4.3.4. Figure 4.3 is a snapshot of the routing tree constructed by the MultihopLQI during one of our exper- iments. Due to changes in wireless link quality over time, the routing tree changes. Figure 4.14 shows how frequently each node changed its parent in one of our experiments; our experiments were conducted in a dynamic environment, with significant routing variability. However, in most of our experiments, the routing protocol consistently produced 5 to 7-hop deep routing trees. We show the effect of different topologies/nodedensityinSection4.3.3. In each of our RCRT experiments, each source originated at least 1000 data packets. This traffic is synthetic, and does not represent the workload generated by any sensor; however, since RCRT is obliv- ious to the actual data, this is an appropriate methodology. Each experiment ran from 30 minutes to an hour depending on the achieved rate. We logged every packet received at the sink along with the current allocatedrateatthetimeofpacketreception. 87 4.3.2 Results In this section, we describe experimental results that validate our RCRT design, demonstrate that RCRT achieves the goals discussed in Section 4.2.1, and show that RCRT outperforms the state of the art in distributedcongestioncontrol. Table4.2summarizesourmethodology: foreachhigh-levelgoaldescribed inSection4.2.1,wehavedesignedatleastoneexperimenttovalidateorquantifythatgoal. (Oneexception is the goal of minimal sensor functionality, which follows from RCRT’s design). Some experiments are usedtovalidateorquantifymorethanonegoal. Inmostcases,weevaluateRCRT’sperformanceusingitsrateallocationprofilewhichistheplotofthe assignedsensorratesr i sasafunctionoftime. Insomecases,particularlytoshowtheefficacyof RCRT’s capacityallocationpolicies,weplottheaveragegoodputachievedbythenodeduringtheexperiment. Wemustemphasizethatwehaverun RCRT experimentsunderverygeneralsettings. Allexperiments reported here are from an actual implementation running on a real testbed. The underlying routing and MAC layers are not optimized in any way, nor have the experiments been run at special times to avoid interference. Our testbed is susceptible to significant interference both from other 802.15.4 radios and from802.11radios,andthisinterferenceishighlytime-varying. Finally, we note that RCRT achieves 100% reliable packet delivery in all experiments we have con- ductedforthiswork. Forthisreason,wedonotfocuson RCRT’send-to-endreliabletransmissionmech- anism, but instead focus on how well RCRT’s congestion control works: what rates are assigned, how RCRT reactstodynamics,andsoon. 4.3.2.1 Baseline WestartwithasimplebaselineexperimentthatillustratessomeoftheimportantfeaturesofRCRT.Inthis experiment,RCRTrunsona40-nodenetwork. Onenodeisabase-station,andtheothersareprogrammed tosenddatabacktothesink. Thefairrateallocationpolicyisusedatthesink. 88 0 200 400 600 800 1000 1200 0 0.2 0.4 0.6 0.8 1 packets/sec time (seconds) Allocated Rate Average Goodput Figure4.4: Rater i allocatedtoeverynodeinthe40-nodeexperimentwithfairratepolicy. 0 5 10 15 20 25 30 35 40 0 0.2 0.4 0.6 0.8 1 packets/sec Node ID Figure4.5: Per-nodegoodputinthe40-nodeexperimentwithfairratepolicy. Figure 4.4 shows the rate allocation profile r i (t) allocated to every node by the sink as a function of time. Thesolidlinerepresentstheinstantaneousallocatedrateloggedatthetimeofeverypacketreception. Thedashedlineshowstheaverageachievedgoodputfromallnodes. Sinceafair-ratepolicywasused,all nodesreceivedthesamegoodput. Thisgraphshowstheefficiencyof RCRT’srateadaptationmechanism. Unlike other AIMD schemes that drastically reduce the rate in response to congestion by halving the rate (or,asinTCP,thewindow)RCRTtriestostaynearthesteadystateaverageratebymakingsmalladaptive reductions. At the beginning of the experiments, the allocated rate overshoots to almost 1 pkts/sec, and drops down to around 0.55 pkts/sec (almost half). This is because when the nodes first start sending packets, the network was not congested, and the RTT estimate takes some time to stabilize. But after this transient, the allocated rate converges and stays within 25% of the average goodput. This less oscillatory 89 Figure4.6: Packetreceptionplotforallnodesinthe40-nodeexperimentwithfairratepolicy. 0 5 10 15 20 25 30 35 40 0 2 4 6 8 10 Node ID Percentage (%) end−to−end retx ratio 5 % Figure 4.7: Percentage of packet repaired by end-to-end loss recovery mechanism in the 40-node experi- ment. behavior results from RCRT’s rate adaptation design which makes rate adaptation decisions based on the overalltraffic,ratherthanonasingleflow. Figure 4.5 shows the per-flow goodput achieved at the sink. Each bar represents the average goodput achieved by each source during the entire experiment. This graph shows that nodes achieved approxi- mately fair goodput: the difference between the largest and the smallest goodput is only 0.015pkts/sec! Thisisasurprisingresultsinceonemightexpectthatallocating samesendingratetoallnodesinamulti- hop environment would penalize nodes fartheraway fromthe sink, since they traversemorehops. RCRT maintains fairness because its rate adaptation mechanism conservatively adapts to the source that experi- encescongestionmostalongthepathtothesink. 90 0 5 10 15 20 25 30 35 40 0 5 10 15 20 Node ID Percentage (%) feedback overhead average 11.6 % Figure4.8: Feedbackpacketoverhead(percentagerelativetodatapackets)inthe40-nodeexperiment. Figure 4.6 shows the packet reception plot for all the nodes in the network. Each point on the curve is the time at which a packet with a particular sequence number was received. Since all of the packets wereeventuallydelivered,theprogressinsequencenumbersapproximatelycorrespondstotheprogressin number of packets received. The slope of each plot is the estimate of the instantaneous goodput that each node achieves at that point in time, and this figure shows that all nodes have approximately fair goodput throughout the experiment. The small spikes below the curve represent lost packets being repaired by RCRT’send-to-endlossrecoverymechanism. How many packets are recovered via end-to-end retransmission? Because of link-layer retransmis- sions,forallbut6nodes,only5%ofthepacketsincurredend-to-endretransmissions,andfornoneofthe nodes were more than 9% of the packets recovered end-to-end (Figure 4.7). This is encouraging, since oneoftheoriginaldesigngoalsof RCRT’send-to-endreliabilitymechanismwastoavoidafeedbackim- plosion. We can quantify the overhead of feedback in RCRT. In this experiment, 4549 feedback packets were sent in total for 39000 data packets, representing an overhead of 11.6% (Figure 4.8. This feedback was used both to recover from losses and to adapt to congestion. Contrast this with TCP, in which every connection can see half as many ACK packets as data packets (most TCP implementations acknowledge everyotherpacket). 91 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Rate Demand packets/sec Best−Effort Goodput x = y reference line Figure 4.9: Average goodput achieved by best- effort transport. X-axis is the rate at which each node sourced packets. Y-Error bar represent the maximum and minimum goodput among all nodes. 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Rate Demand packets/sec Stream Transport Goodput x = y reference line Figure 4.10: Average goodput achieved by re- liable transport. X-axis is the rate at which each node sourced packets. Y-Error bar reprint the maximum and minimum goodput among all nodes. 4.3.2.2 Optimality Thebaselineexperimentdemonstratessomeofthesalientfeaturesof RCRT’salgorithms. Thenextques- tion we address is: How close does RCRT’s rate allocation get to the optimal? One way to evaluate the performance achieved by RCRT is to determine the maximum fair and reliable rate sustainable on the same network with same routing and MAC layers. We address this question by experimentally eval- uating the goodput received by two different kinds of transport mechanisms at different offered loads. Best-effort transport sends data at a configured rate, but includes no end-to-end reliability and does not adapt to congestion. Reliable transport sends data at a configured rate, includes end-to-end reliability, but does not adapt to congestion. In our implementation for the experiments, best-effort transport is essen- tially MultihopLQI with application-level sequence numbers, and reliable transport adds end-to-end loss recovery(Section4.2.3)ontopofthat. Figures 4.9 and 4.10 plot the average goodput over all nodes for two transport mechanisms at various offeredloads. Thethicksolidcurveshowstheaveragegoodputachievedatthesink,theerror-barsparallel tothey-axisindicatethemaximumvariationinnodegoodputateachofferedload,andthestraightdotted diagonallinerepresentstherateachievablewithinfinitecapacity. 92 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Rate Demand packets/sec RCRT Goodput x = y reference line Figure 4.11: Average goodput achieved by RCRT. X-axis is the demand assigned to each node. Y-Error barrepresentthemaximumandminimumgoodputamongallnodes. Figure 4.9 shows the maximum fair rate achievable without end-to-end reliability on our 40-node testbed. Untiltheofferedloadreaches1.1pkts/secpernode,allnodesachieveapproximatelyfairgoodput (small error bars) and 95.4% reliability (not shown). However, as the offered load increases above 1.2 pkts/sec,variabilityingoodputincreases,andthereliabilitydropsbelow90%. Figure 4.10 represents the achievable rate with end-to-end reliability, but no congestion control. Our network is able to sustain up to 0.9 pkts/sec per node. Thereafter, it experiences congestion collapse: acknowledgmentsandretransmissionsuseupmuchofthenetworkcapacity,resultinginlessgoodputand lowerfairnessthanbest-efforttransport. Since RCRT provides end-to-end reliability, we should compare its achieved rate with that of Fig- ure 4.10. If we define 0.9 pkts/sec as the maximum sustainable rate for reliable transport, then, as Fig- ure 4.11 shows, RCRT achieves nearly 0.8 pkts/sec per node, or 88% of the sustainable rate for reliable transport. Inthisexperiment,weassignedallnodesequaldemand. Thefigureplotsthisincreasingdemand on the x-axis. Of course, since RCRT is congestion-adaptive, sources only send at the assigned rates, not attheirdemands. Another way to evaluate RCRT’s optimality is to consider a single-source network. We conducted a single-source single-sink experiment and found that best-effort transport can achieve up to 95 pkts/sec, and RCRT canachieveupto60pkts/seconaverage(Asanaside,notethat RCRT iscapableofachieving highgoodput(60pkts/sec). Inourpreviousexperiments,thelowper-nodegoodput(0.8pkts/sec)ismainly 93 a function of the topology, not our protocol.) We can relate these experimental results to those observed on our larger topology as follows. In Figure 4.3, an instantaneous snapshot of the routing tree during one of our experiments, we estimate that node 19 is the most congested node: it has 19 children, 3 siblings, 3 children of the siblings, and hence a parent (node 13) that has total of 26 children. Let us say every node sends 1 unit of data per 1 unit of time. Then node 19 receives 19 units of data and sends 20 units of data (including it’s own data) per unit time. Also, node 19 contends with 6 units of data from its 3 siblings and their children to reach its parent. Finally, node 19 contends with 27 units of data that the parent (node 13) transmits to its parent (node 1). Hence, the channel capacity around 19→ 13 must be shared at least by total traffic of 72 units of data per unit time (= 19 + 20 + 6 + 27), even if we assume an ideal MAC. (We call this 72 the maximum contention factor of this routing topology.) This means that the optimal sustainable rate in this network is 60/72 =0.83 for RCRT and 95/72 =1.32 for best-effort transport. These numbers match what we have observed, and confirms that RCRT closely achieves what the topology allows; RCRT in a 40-node network achieves 96% of what it can achieve in a single node network. Wediscusshowresilient RCRT istotheeffectofnetworktopologyinSection4.3.3. Insummary,RCRTmanagestoassignnear-optimalratesbyhavingcongestioncontrolfunctionalityat thesink. Wehavecomparedthevarioustransportprotocolswiththesameradio,MAC,androutinglayers, toensurethatourresultsarenotaffectedbydifferencesintheunderlyingprotocollayers. Ourresultsshow that it is possible to estimate and manage overall network capacity in a centralized manner, and achieve highefficiency. 4.3.2.3 Robustness In this section, we conduct an experiment that demonstrates RCRT’s robustness, and also validates its flexibilityincapacityallocation. Inthisexperiment,nodesjoinandleavedynamically,anddifferentnodes areassigneddifferentdemands. Thenetworkisconfiguredtouseademand-proportionalallocationpolicy. Wesetupthreesetsofflowsthatrequestdifferentdemands. Specifically,inthisexperiment,31flowsstart at time 0. Sixteen of these (which we will call set A) demand 1.0 pkts/sec and the other 15 flows (set B) 94 0 500 1000 1500 2000 0 0.5 1 1.5 2 2.5 3 packets/sec time (seconds) (A) d i = 0.5pkts/s, 16nodes (B) d i = 1.0pkts/s, 15nodes (C) d i = 4.0pkts/s, 8nodes 8 Nodes join 8 Nodes leave 15 Nodes leave C B A Figure 4.12: Rate r i allocated to each node in the 40-node experiment with demand-proportional rate allocationpolicywhen8nodesjoininafter500seconds. 0 5 10 15 20 25 30 35 40 0 0.5 1 1.5 2 2.5 3 packets/sec Node ID d i = 0.5pkts/sec, 15nodes d i = 1.0pkts/sec, 15nodes d i = 4.0pkt/sec, 8nodes Figure4.13: Per-flowgoodputinthe40-nodeexperimentwithdemand-proportionalrateallocationpolicy when8nodesjoininafter500seconds. demand0.5pkts/sec. Theremaining8flows(setC)joininafter500secondswithademandof4pkts/sec. Allflowssendthesametotalnumberofpackets,butsetC finishesearlierbecauseofitshigherdemand. Figure 4.12 shows the rate allocation profile for this experiment. Recall that RCRT allocates exactly the same rate to all flows having the same demand. During the first 500 seconds of the experiment, sets A andBwereallocatedroughlytheratethattheydemanded: 0.5and1pkts/sec. WhenthethirdsetofflowsC joinedinwithsignificantlyhigherdemand,thenetworkimmediatelyexperiencedcongestion,andtheflows in both A and B were forced to reduce their rates. Between 500 and 1000 seconds into the experiment, all threesetsofflowswereactive,andwereallallocatedratesproportionaltotheirdemands. Whentheflows in setC had completed at around 1000 seconds, the network had enough capacity to satisfy the demands 95 0 5 10 15 20 25 30 35 40 0 5 10 15 20 Node ID number of route changes Figure4.14: Numberofroutingparentchangesduringthe40-nodeexperimentwithdemand-proportional rateallocationpolicywhen8nodesjoininafter500seconds. offlowsAandB. Thisresultshowsthat RCRT isrobusttonodejoinsandleaves,itscongestiondetection mechanism and the rate adaptation mechanism successfully adapted the network-wide aggregate rate to thenetworkstate,andtherateallocationmechanismindeedallocatedratesproportionaltothedemandsof eachnode. Figure 4.13 plots the goodput achieved by each node for this experiment. While nodes with identical demands achieved comparable goodputs, the average goodput between different sets is, interestingly, not exactly proportional to their demands. Specifically, the average goodput achieved by sets A, B, and C is 0.44, 0.77, and 2.04 pkts/sec respectively, while their demands are 0.5, 1.0, and 4.0 pkts/sec respectively. This is because each set experienced network congestion for different fractions of their lifetimes. Since the flows in setC experienced congestion during their entire lifetime and only achieved half the goodput of their demand, the average r i d i during this congested period is about 0.5 (2.04/4.0≈ 0.5). Since set B experienced congestion and was assigned half the demanded rate for half of its lifetime, its expected goodputisaround75%ofwhatitwouldhaveachievedinanuncongestednetwork. Thisroughlymatches the goodput that set B actually achieved (0.5 1 2 +1.0 1 2 = 0.75≈ 0.77). Finally, set A was assigned half the rate for 1/4 of its lifetime, which amounts to 0.25 1 4 +0.5 3 4 = 0.4325 pkts/sec, which is close to the observed0.44pkts/sec. Thus,RCRT’sdemand-proportionalallocationpolicyresultsininstantaneous,but 96 Set App. ID Demand Num.pkts Num.nodes A 1 1 1.0pkts/sec 1000 19 B 1 1 0.5pkts/sec 500 18 A 2 2 1.0pkts/sec 500 19 B 2 2 0.5pkts/sec 250 18 Table4.3: SetupforTwo-Application,Two-SinkExperiment. not long-term, demand-proportional rate assignments. It is possible to implement a long-term demand- proportionalallocationpolicyin RCRT,andwehaveleftthistofuturework. Finally,Figure4.14showshowfrequentlyeachnodechangeditsroutingparentduringthis38-minute experiment. Even though, on average, each node changed its parent 3.4 times, RCRT assigned rates correctlytoalltheflows. Thisalsohighlightstherobustnessof RCRT’sdesignandimplementation. 4.3.2.4 Flexibility In this section, we demonstrate that RCRT achieves two more of its original goals: that it can support multipleconcurrentapplications,andthateachapplicationcanusedifferentcapacityallocationpolicies. We ran two separate “applications” with two sinks. Each application ran on a different sink and used different rate allocation policies: one used demand-proportional allocation, and the other used demand- limited allocation. The two sinks at the upper tier were connected via 802.11b wireless. Nodes 15 and 30 were the gateway motes on our testbed connected to the two sinks. Each sink was a Stargate running Linux. The motes used a multisink version of MultiHopLQI, so that two trees were formed, one rooted at each sink. We used additional routing software that allowed both sinks to receive data packets from all motes. Thus,thissetuprepresentstwoapplicationsrunningonatierednetwork. Inthisexperiment,weused37motes. TheexperimentwassetupasshowninTable4.3. Thedemand- proportional application comprised two sets of nodes A 1 and B 1 , the first set being assigned twice the demand asthesecond. Thedemand-limited applicationcomprisedthesametwosets(denoted A 2 and B 2 ) respectively, with identical respective demand assignments. The total aggregate demand was 56 pkts/sec, enoughtosaturatethenetwork. 97 0 200 400 600 800 1000 1200 0 0.2 0.4 0.6 0.8 1 packets/sec time (seconds) A 1 , d i = 1pkts/sec, 1000pkts B 1 , d i = 0.5pkts/sec, 500pkts A 2 , d i = 1pkts/sec, 500pkts B 2 , d i = 0.5pkts/sec, 250pkts B 2 ends A 2 ends Figure 4.15: Rate allocated to each node in 39-node experiment with two applications running on two sinks. 0 5 10 15 20 25 30 35 40 0 0.5 1 1.5 2 packets/sec Node ID Application−1, Weighted−fair, 37nodes Application−2, Demand−limited, 37nodes Figure 4.16: Per-node goodput (two flows for same node stacked together) in 39-node experiment with twoapplicationsrunningontwosinks. Figure 4.15 shows the rate allocation profile for this experiment. Flows in application 1 (sets A 1 and B 1 ) were assigned rates proportional to their demands, and flows in application 2 (sets A 2 and B 2 ) were assigned rates limited by their demands. Thus, notice that even though flows in A 1 and A 2 had the same demand, they each get different rate allocations because the applications use different capacity allocation policies. Also note that all flows in the demand-limited application get the same rate; the sustainable network rate was below the 0.5 pkts/sec demanded by B 2 . All flows experienced congestion from time 0 till about 600 seconds when all four sets of flows were active (a total of 74 flows). After set B 2 finished at 600 seconds, the other flows were allocated higher rates to take advantage of the increased available capacity. 98 0 500 1000 1500 2000 0 0.2 0.4 0.6 0.8 1 packets/sec time (seconds) RCRT IFRC Figure4.17: RateachievedbyIFRCand RCRT in30-nodeexperiment Finally,Figure4.16showsthegoodputachievedatthesinkbyeachnode. Twoflows(fortwodifferent applications) from the same node are stacked together to show the total goodput achieved by each node. Theaveragegoodputsachievedbythetwoapplicationsare0.718pkts/secand0.508pkts/secrespectively, which totals 1.226 pkts/sec. This brings up an important point. The total achieved goodput is approx- imately 60% higher than the single-sink 40-node experiment (Section 4.3.2.1). This comes from using a tiered network. The two sinks are near the center of the network and roughly have comparably sized subtrees. Moreover, the two sinks use 802.11b radios to communicate with each other, which has at least anorderofmagnitudehigherbandwidth. ThisexperimentnotonlyshowsthatRCRTcansupportmultiple concurrent applications on a tiered network with multiple sinks, but also quantifies the capacity increase achievable byusing RCRT onatierednetwork. Furthermore, although wehaveleftintersinkcooperative ratecontrolasfuturework,thisexperiment showsthatindependent congestioncontroldecisionsmadeby differentsinksresultedinreasonable(althoughnotperfect)behavior. 4.3.2.5 Comparison In this section, we compare the performance of RCRT with that of IFRC [92], a recently proposed interference-awaredistributedrate-controlprotocol,andalsowithWRCP[102],anotherrecentlyproposed distributedrate-controlprotocol. 99 Figure4.18: Rateachieved by IFRCand RCRT ina30-node experiment withmodified MAC parameters forsoftwareacknowledgment Figure 4.17 shows the rate achieved by IFRC together with RCRT’s rate allocation in a 30-node ex- periment. The two protocols are qualitatively different, since IFRC does not provide end-to-end reliable transmissions. However, weareinterestedincomparing theircongestion control efficacy: IFRCdoes dis- tributedcongestioncontrol, while RCRT performscongestioncontrolatthesink,andweexploretowhat extent these approaches are quantitatively different. To compare these two protocols, we run them on the same set of nodes with the same radio power. RCRT was configured to use the fair allocation policy. However, IFRC has been evaluated only on static routing trees [92], so we ran IFRC on an empirically determined“good”tree. 6 RCRT runswithdynamicroutingenabled. In Figure 4.17, the solid line represents the rate allocated to all nodes in RCRT, and the dashed line represents the rate achieved by one of the nodes in IFRC. Since all nodes were allocated the same rate in RCRT,asinglelineissufficienttoshowrateallocationofallnodes. InIFRC,allnodesadapttheirratesin near-synchrony, and rate plots for various nodes overlap with each other. We only plot the rate adaptation plot for one node for clarity. The dotted horizontal lines show the average rate achieved by each protocol duringtheexperiment. The results show that RCRT achieves an average rate of 0.824 pkts/sec in this experiment, which is morethantwicetherateachievedbyIFRC:0.293pkts/sec. 6 Our IFRC experiments were executed by the lead author of the IFRC paper. We ran dynamic routing in RCRT because the performance was similar to static and we wanted to emphasize the fact that RCRT works over dynamic routing where as IFRC does not;asignificantdeficiencyofbothIFRCandWRCP. 100 This surprisingly large difference in the result deserves further investigation. After extensive experi- ments,wehavefoundthatahardwarelimitationofourcurrentplatformdegradestheperformanceofIFRC. IFRC,bydesign,requirestheradioandMACtoruninpromiscuousmodeandoverhearthepacketsinthe neighborhood. However, our experimental platform (CC2420) does not permit the use of hardware-level acknowledgmentsalongwithpromiscuousmode. SotheIFRCimplementationusessoftwareacknowledg- mentsforlink-levelretransmission,whichaddssomesoftwaredelaysintheMAClayerandreducesIFRC throughput. When RCRT uses the same software acknowledgment implementation as IFRC, RCRT’s averagegoodputisabout1.7timesthatofIFRC(Figure4.18). Webelieve twomainreasonsaccount forthisdifference. Thefirst,ofcourse, isthatmuchof RCRT’s performance advantage comes from implementing its congestion control functionality at the sink, which has a more global view of network state. This results in less pronounced rate deviations in RCRT’s rate allocation profile. A second reason is that IFRC aggressively avoids congestion whereas RCRT detects congestion after it has happened. To avoid dropping packets, IFRC detects incipient congestion and ag- gressively cuts its ratewhen queues exceed a small threshold. On the other hand, RCRT fullyutilizes the network queues until packets are lost, resulting in higher throughput. RCRT can afford packet loss, since it has a built-in loss recovery mechanism. That said, it should be possible to improve IFRC performance by varying its parameters and making it less aggressive in avoiding congestion, at the possible expense of lowerend-to-endgoodput. Recently, we have also compared the performance of RCRT with that of WRCP [102]. Since the code for WRCP was not publicly available at the time of this writing, we ran RCRT on the same 40- node topology as that in the WRCP paper and compared the RCRT results to the WRCP result in their paper [102]. Specifically, on the same testbed (Tutornet 7 ), we used exactly the same set of nodes, same radio power (5) and channel (26), and same static routing topology as in their topology. The result is that RCRT achieves an average rate of 0.84 pkts/sec, which is about 1.4 times the rate reported for WRCP: 0.6 pkts/sec. Moreover, if we can assume that RTT is roughly the double of end-to-end latency, then the 7 Tutornet: TieredWirelessSensorNetworkTestbed. (http://enl.usc.edu/projects/tutornet/) 101 network max contention estimated achieved % feedback RTT size hopcount factor rate rate achieved overhead (msec) 80 7 171 0.35 0.34 97% 18.5% 390 40 6 72 0.83 0.80 96% 15.8% 325 20 3 27 2.22 2.11 95% 14.1% 229 Table4.4: RateAchievedby RCRT forVariousNetworkSizesandTopologies. latency achieved by RCRT (Table 4.4) is no greater than that achieved by [102]. The reasons for this difference are similar as for IFRC: in particular, WRCP aggressively avoids congestion by conservatively dividingthereceivercapacityintotheestimatedactiveflowcounts. 4.3.3 NetworkTopology InSection4.3.2.2,wehaveshownthatthelowper-nodegoodput(0.8pkts/sec)inourbaselineexperiment (Section 4.3.2.1) is mainly a function of the topology, not our protocol. Also, we have already mentioned thatRCRTcanachieveupto60pkts/seconaverageinasingle-sourcesingle-sinknetwork. Inthissection, we investigate how network size and topology affects the rate achieved by RCRT, which in turn shows how well RCRT adapts to different topologies. We used a 40-node network for our baseline experiment to enable comparison with IFRC and WRCP (Section 4.3.2.5). In this section, we report results from two other network sizes, 80 and 20 nodes. We also report result from a 40-node network with different node densities(byvaryingtheRFtransmitpower)andnetworkdepth(byvaryingthenumberofmasternodes). Note that RCRT achieved approximately fair goodput as well as 100% reliable packet delivery in all of theseexperiments. 4.3.3.1 NetworkSize Table 4.4 summarizes the rate achieved by RCRT from various network sizes that we have experimented with. It also shows the estimated achievable rate for each topology. This is calculated using the method- ology described in Section 4.3.2.2. Specifically, for the 80 node topology (Figure 4.19) we compute it as follows. In this topology, we estimate that node 17 is the most congested node: it has 54 children, 3 siblings and their children, and hence a parent (node 8) that has total of 58 children. Using the same 102 1 2 3 4 5 7 8 9 10 12 13 6 16 11 14 15 17 63 21 18 19 20 22 23 24 26 27 32 43 44 67 81 29 25 46 55 30 31 33 35 36 38 37 39 40 42 47 51 52 53 50 60 62 64 65 66 68 70 73 72 75 71 79 76 77 78 80 69 82 83 84 85 86 87 91 92 88 89 90 93 94 Figure4.19: Asnapshotofroutingtopologyconstructedina80nodenetwork calculationmethodasSection4.3.2.2,thechannelcapacityaround17→8mustbesharedatleastbycon- tention factor of 171 (=54+55+3+59), even if we assume an ideal MAC. This means that the optimal sustainablerateinthisnetworkis60/171=0.35,whichcloselymatchestheachievedrate. Theachievable rateestimatewascalculatedforthe20-nodenetworkinasimilarmanner. Thus,forthreedifferentnetwork sizes, RCRT achievesbetween95-97%oftheachievablerateonthecorrespondingtopology. Table4.4alsoshowstheaveragefeedbackoverhead,measuredasthetotalnumberoffeedbackpackets divided by the total number of data packets, and the average RTT achieved by RCRT. Notice that even whenthenetworksizedoublesfrom40to80nodes,theoverheadandRTTincreaseislessthan20%. This is only a small increase. However, it is true that the overhead and latency will continue to increase if the network size continues to grow. However, with a larger network, the overall per-node throughputs will become vanishingly small, and it is not clear that such a configuration would be useful for the kinds of applications we have considered in this work. Instead, in such cases, a tiered architecture with multiple sinksshouldbeemployedtoreducethefeedbackoverheadandimprovethroughput,asdescribedbelowin Section4.3.3.3. 4.3.3.2 NetworkDensity Next, we experiment with different network densities by varying the RF transmit power in a 40 node network. Thiseffectivelychangesthenodedensityandtheroutingdepthofthenetworkinagivenphysical 103 RFPowerconfiguration 3 5 7 11 15 19 23 27 31 dbm -25 ∼ -15 -10 -7 -5 -3 -1 0 hopcount avg. 3.3 2.8 2.7 2.2 1.9 1.8 1.6 1.7 1.6 max. 7 6 5 4 3 3 3 3 3 avg. goodput 0.81 0.95 0.97 0.98 0.98 1.07 0.96 1.10 1.06 avg. overhead(%) 15.1 15.0 15.5 15.9 15.2 15.2 16.5 15.5 16.0 avg. RTT(ms) 548 505 396 363 359 348 305 311 290 Table4.5: RCRT Resultson40-NodeNetworkwithVaryingRFPowerSettings. area. Table 4.5 summarizes the rate, as well as the feedback overhead and RTT, achieved by RCRT with varying RF transmit power. There are several things to note in this result. First, as expected, the network depth decreases as the transmit power increases, and RTT is smaller when the network depth is smaller. Second, the feedback overhead stays at around 15% regardless of the network density. Finally, therateachievedby RCRT isalsofairlyconsistentevenatdifferentdensitiesforcomparabledepths. The latter two results are because the congestion usually occurs near the sink and the total number of flows passing through that region governs the achievable rate of the network. On the contrary, as we will see in Section 4.3.3.3, the rate and overhead achieved by RCRT will differ when the number of flows passing through the congestion region changes. Thus, increasing the transmit power within a given network is unlikelytoimprovetherateachievedbythenetwork. 4.3.3.3 NetworkDepth Inthisexperiment,wevarythenumberofsinksinthenetworkwhilekeepingthenumberofnodesandRF powerconstant. Figure4.20depictsthelayoutofthesourceandsinknodesinourtestbedwherethedarker squaresrepresentthesinknodeswiththenumberingintheiraddedorder. Table4.6summarizestheresult from this experiment. The average and maximum hop count (routing depth) decreases as the number of sinks increase. Thus the average RTT also decreases. What is more important is that, unlike increasing the RF transmit power, the rate achieved by RCRT improves significantly and the overhead incurred also reduces as the number of sinks increase. This is because, as more sinks are added to the network, and the number of flows that a single sink handles reduces, and congestion is distributed among the several sinks. 104 Figure4.20: LayoutofsourceandsinknodesinTutornet. NumberofMaster(Sink)nodes 1 2 3 4 5 6 hopcount avg. 2.8 1.6 1.5 1.4 1.3 1.0 max. 6 3 3 3 3 2 avg. goodput 0.87 1.33 1.62 2.32 2.56 2.78 avg. overhead(%) 15.8 14.6 15.1 13.9 13.3 13.5 avg. RTT(ms) 492 256 208 194 189 162 Table4.6: RCRT Resultson40-NodeNetworkwithVaryingNumberofSinkNodes. Thus,deployingadditionalsinksinagivennetworkisaneffectivewayofimprovethethroughput,aswell asoverheadandlatency,achievedby RCRT. 4.3.4 Sensitivity: Hop-by-HopRetransmissionsandQueueSizes Aswehavementionedearlier(Section4.2.2),thedesignofRCRTdoesnotdependonanyfeaturesspecific to a particular MAC or routing layer. We only assume that there exists at least one or more end-to-end path,withnonzerodeliveryprobability,fromeachsensornodetothesinkandalsoareversepathfromthe sinktoeachnode. However,aswehavementionedinSection4.2.5also,theperformanceof RCRT’srate adaptation may depend on the quality of these end-to-end paths. If the end-to-end packet delivery ratio is extremelypoor, RCRT mayoverestimatecongestionandassignlowerratesthanoptimal. In this section, we investigate the effects of lower-layer parameters to the performance of RCRT. Specifically, we look at the effects of the limit on the number of hop-by-hop retransmissions (the retrans- mission limit) at the MAC layer and the size of the forwarding queue at the routing layer, since these two factorsmayimpactpathpacketlosscharacteristics. 105 0 5 10 15 20 25 30 0.2 0.4 0.6 0.8 1 1.2 queue size packets/sec #.Retx 4 #.Retx 2 #.Retx 0 Figure 4.21: Goodput achieved by RCRT in the 40-node experiment with varying queue sizes and maxi- mumnumberofhop-by-hopretransmissions. Figure4.21showsthegoodputachievedbyRCRTinthe40-nodeexperiment,withvaryingqueuesizes andvaryingretransmissionlimits. Thebottomdash-dotline(withsquares),thedottedline(withcrosses), and the solid line (with circles), each show the goodput achieved by RCRT when the retransmission limits are 0, 2, and 4, respectively. There are several observations that we can make from this figure. First, RCRT achieves very low goodput (∼0.1 pkts/sec) regardless of the queue size when there are no hop-by-hop retransmissions. On the other hand when the retransmission limit is either 2 or 4, the queue size impacts the rate achieved by RCRT. This is because, when there are no hop-by-hop retransmissions, successful packet delivery probability is so poor that RCRT assigns low rates and the number of packets inthenetworkisverysmall,sotheforwardingqueueneverfillsup. Asecondobservationrequiresamorecarefulunderstanding. Whentheforwardingqueuesizeisabove a certain point (15 in this figure), a retransmission limit of 4 achieves better goodput compared to that of 2. However,whenthequeuesizeisbelowacertainpoint(7inthisfigure),retransmissionlimitsof2and4 have similar goodput. This is because more hop-by-hop retransmissions result in higher utilization of the forwarding queue and possible queue drops. In general, more hop-by-hop retransmissions should result in better end-to-end packet delivery ratio, and hence better goodput achieved by RCRT. However, when the queue sizes are small, a higher rate results in more queue drops, which in turn takes away the extra 106 1 3 7 15 31 0 2 4 20 40 60 80 100 Queue Len. Num. Retx. PRR (%) 55 60 65 70 75 80 85 90 95 Figure 4.22: PRR achieved by best-effort transport (z-axis) with varying forwarding queue sizes (x-axis) andvaryingmaximumnumberofhop-by-hopretransmissions(y-axis). packetdeliveryachievedbymorehop-by-hopretransmissions. Thusmorehop-by-hopretransmissionsdo notimprovethegoodputachievedby RCRT whenforwardingqueuesizesaretoosmall. Toverifytheabovearguments,weranaseriesofexperimentstomeasuretheend-to-endpacketrecep- tionratio(PRR)achievedbythebest-efforttransportinthesame40nodenetworkwithvaryingforwarding queue sizes and varying retransmission limits. Figure 4.22 is a 3-D plot of all the results: the z-axis rep- resents the PRR achieved by the best-effort transport, and the x- and y-axes plot forwarding queue sizes and retransmission limits, respectively. Observe that when there are no hop-by-hop retransmissions, the PRR is very poor regardless of what queue size we use. However, when there are hop-by-hop retransmis- sions (limit of 2 or 4), queue size does affect PRR. Another observation is that, when the queue size is verysmall(1,theminimumpossible),thePRRisverypoorevenwithhop-by-hopretransmissions. How- ever,whenthequeuesizeissufficientlylargerelativetothenetworksize,hop-by-hopretransmissionscan significantlyimproveend-to-endPRR.TheseresultsconfirmthatourreasoningaboutFigure4.21isvalid. In summary, the performance of RCRT may depend on the end-to-end packet delivery ratio of the source nodes in the network. Hop-by-hop retransmissions at the MAC layer and the queue size at the routing layer are two important factors that may affect the end-to-end packet delivery. However, having 107 AdditiveIncreaseParameter‘A’ 0.25 0.5 1 2 4 5 10 20 avg. goodput 0.72 0.91 0.93 0.99 0.95 0.62 0.66 0.56 avg. overhead(%) 18.5 16.5 15.6 14.5 16.8 31.2 28.4 34.0 avg. RTT(ms) 331 390 514 495 662 551 485 428 Table4.7: RCRT Resultson40-nodeNetworkwithVaryingAdditiveIncreaseParameter‘A’. a moderate queue size (15 packets) and reasonable retransmission limits (4) result in good RCRT perfor- mance,acrossallourexperiments. 4.3.5 AdditiveIncreaseParameterA In this section, we investigate the effect of the value of the additive increase parameter A on the perfor- mance of RCRT.As wehave discussed inSection 4.2.5, RCRT additively increments the total aggregate rate R(t) by A when it observes the network as underutilized. If this A is too small, it will take long time for RCRT tothrottleitsrateuptothesteady-statelevelwhenevertherateisbelowit. IfthisAistoolarge, RCRT’s rate adaptation will oscillate significantly around the steady-state level. Thus, setting the value of A incorrectly can result in significant performance loss. For this reason, we explore the sensitivity of RCRT’sperformancetothechoiceofA. Table4.7summarizestheaveragerate,overhead,andRTTachievedbyRCRTina40-nodeexperiment withvaryingA. Thereareseveralobservationsthatcanbemadefromthisresult. First,whenAistoolarge (5 or higher), RCRT incurs high overhead and achieves lower rate due to the oscillatory behavior of its rate adaptation. This is because it increases the rate quickly and decreases frequently, instead of spending more time near the steady-state rate (between the upper and the lower threshold). Second, when A is too small(0.25orlower), RCRTachievesloweroverallgoodputbecauseittakeslongtimeforittorecoverits steady-staterateafteracongestedperiod. NotethatthisdoesnotnecessarilyworsentheoverheadandRTT. Finally, RCRT achieves more or less comparable rates for a wide range of A values, between 0.5∼4. In this range, the average overhead and average RTT are also comparable. Thus, the result altogether shows 108 Figure4.23: AmapdetailingthelocationandtopologyofourdeploymentatJamesReserve. that it is possible for RCRT to select any value of A within this range; in our other experiments, we have usedaconservativevalueofA=0.5. 4.4 Real-WorldDeployment In this section, we discuss a real-world deployment of RCRT, used in an imaging application for bird nestbox monitoring at the James San Jacinto Mountain Reserve 8 [43]. This application used RCRT to reliablytransferimagesofbirdnestboxesinalargemountainareaforthreemonths. 4.4.1 MotivationandDeployment StudieshavebeentakingplaceforseveralyearsattheJamesSanJacintoMountainsReserveonthebreed- ing biology of some species of birds. These studies involve observing the behavior of birds in nest boxes, speciallyplacedtoattractbirds. However,observingday-to-daychangesinbreedingbehaviorinthesenest boxes is extremely labor intensive. Each box spread over a large mountain area must be checked daily by a biologist in the field. A wireless sensor network with image sensors can help: the biologists can inspect 8 http://www.jamesreserve.edu/ 109 the wirelessly delivered images remotely, saving time and effort. For this purpose, we developed a wire- less imaging application on Tenet [84] using the RCRT protocol to transfer images periodically taken by Cyclops[90]cameras. Wedeployedthissystem,consistingof5masternodesand19motes,over120,000 squaremetersoftheJamesReserve,for3monthsbetweenMay9th∼Aug9th,2008. The goal of our application was to repeatedly collect, from every node, an image along with envi- ronmental sensor readings as frequently as possible. Reliable delivery is a requirement for our system, otherwise image quality can be severely compromised. Each image is large (40 KB uncompressed), and the total network data rate required to deliver images from all our nodes can easily overwhelm the radio bandwidth. Our system uses lossless image compression to alleviate this somewhat, but congestion con- trol, which allows our application to adapt its image transfer rate dynamically, is still necessary to avoid congestioncollapse. Itisalsonecessarytoachieveefficiencyinthepresenceofnetworkdynamics: inour deployment,somenodesranoutofbattery,andwereunattendedforawhile,afterwhichthebatterieswere replacedandtheyrejoinedthenetwork;also,thewirelessenvironmentchangedasfoliagegrewduringthe 3-monthperiod. Forthesereasons,weused RCRT asourtransportprotocolinthisapplication. In our deployment, we had one Linux server machine running as the RCRT sink, and this server communicatedwithfourStargatesthatwereplacedaroundtheJamesReservetoconstitutethemastertier of the network. The server and the Stargates were connected via Ethernet and 802.11b wireless. Each Stargate was connected to a Mica2 mote that acted as gateway to nearby sensor nodes. Each sensor node was a Mica2 mote equipped with a Cyclops camera. The resulting network topology is shown in Figure 4.23. While our system does support multihop routing (and we did log some temporary multihop paths), nestboxplacementwasdeterminedfromaprevious,single-hopdeployment[57]. 4.4.2 Results Duringthe3monthdeploymentperiod,RCRTdeliveredover83millionpacketstocollect102,173images from 19 sensor nodes. Since there were times when our application was stopped for maintenance or debugging purposes, our networking log files are discontinuous. Here we present the observations we 110 501 503 504 505 506 507 508 606 703 704 707 708 709 901 904 9051702 1707 1906 20 30 40 50 60 70 80 90 100 PRR (%) Node ID −70 −65 −60 −55 −50 −45 RSSI (dbm) PRR RSSI Figure4.24: Linkconnectivityofeachnode: PacketreceptionrateandRSSItonexthopnode. made for one week from July 21 to 28, 2008. During this period, there were total of 8453 attempts to transfer an image from 19 nodes. Among these attempts, 8372 image transfers, which corresponds to 99% of initiated RCRT transfers, were complete with 100% packet delivery. For these complete images, the average data rate achieved by the network was 1.1 packets/sec per node, and the average number of packets required to deliver one image was 833.2. As a result, one image transfer took 12.6 minutes on average (each image is 40KB, but had a variable size after compression, so there was some variability in thenumberofpacketsrequiredtodeliveranimage). Thisdatarateof1.1pkts/secwasachieveddespiteextremelypoorlinkconnectivity. Figure4.24shows theend-to-endpacketdeliveryratioforeachnodewhenwetestedthenetworkjustbeforethedeployment using best-effort delivery without loss recovery. (e.g., node 905 had PRR of less than 50%). The figure also plots the RSSI readings to nearest routing parent for each node. When we conducted a single-source single-sink experiment with 433MHz Mica2 motes, we found that RCRT can achieve up to 11 pkts/sec onaverage. 9 FromFigure4.23,noticethatStargate42871atthetop-leftareaofthemapisthebottleneck where8sensornodesaretryingtoroutethroughasinglestargate. Thismeansthatthemaximumachievable rateinthistopologycannotexceed11/8=1.375pkts/secevenwithanidealMACwhenfairrateallocation policy is used. Considering the extremely poor link connectivities (Figure 4.24) and the fact that RCRT 9 Weusean80byteTinyOSpacketpayload. 111 0 100 200 300 400 500 600 700 800 0 0.5 1 1.5 2 2.5 time (seconds) packets/sec Allocated Rate Average Goodput Figure4.25: Rate-allocationprofileatJamesReserveforsingleimagetransfer 0 2000 4000 6000 8000 0 0.5 1 1.5 2 2.5 time (seconds) packets/sec Allocated Rate Average Goodput Figure4.26: Rate-allocationprofileatJamesReservefor10imagetransfers(2hour45minuteperiod) mayover-estimatecongestionwhenPRRisverylow(Section4.2.5),thedeploymentresultof1.1pkts/sec (whichis80%of1.375)isverygood. The reason that only 99% of the initiated RCRT transfers were complete is as follows. Poor link connectivity for some nodes caused frequent packet losses and delayed loss recovery severely. But our applicationterminatedanimagetransferifnonewimagesegmentcameinwithin30seconds. Sowhenever there were lost packets near the end of image transfers that were not recovered within 30 seconds, our application stopped without waiting for the RCRT loss recovery to complete. Given more time, RCRT wouldhavebeenabletocorrectlytransferthoseimages. Figure 4.26 is a snapshot of the rate allocation profile for 10 consecutive image transfers during a 2 hour 45 minute period. Also, Figure 4.25 is a zoomed-in version of Figure 4.26 which plots the rate 112 allocated to each node for a single image transfer during 13 minute period. There are several things to notice here. First, the average data rate was consistently around 1.1 pkts/sec most of the time for most of theimagetransfers. Itisvisuallyevidentthat RCRT’srateadaptationstayednearthesteady-stateaverage by making small rate reductions. Second, the reason that the rate starts at 0.5 pkts/sec at the beginning of each image transfer is because this was set as the initial value for our AIMD rate adaptation. (We start a newRCRTconnectionforeveryimagetransfer). Finally,therateshootsuptoaround2.5pkts/secnearthe endofeachimagetransfer. Thisisbecausetherearemultiplenodesinthenetworkandsomenodesfinish datatransferearlierthanothersduetothevariabilityinlossrates(Figure4.24). Whensubsetofthenodes finish transfer earlier than others, there is leftover network capacity, which RCRT detects and adapts to, sotheincompletetransfersareallocatedhigherratesasmorenodescomplete. In summary, we have used RCRT for three months in a real-world deployment of 19-node network deployed over an area of 120000 square meters (Figure 4.23). During this deployment, RCRT collected over 83 million packets reliably at a reasonable rate despite highly variable individual node availability andwirelesslinkquality. Ourdeploymenthaveshownthat RCRT workswellinrealdeployments. 4.5 Conclusions RCRT is a reliable transport protocol for wireless sensor networks. It places its congestion control func- tionality at the sink, whose perspective into the network enables better aggregate control of traffic, and affords flexibility in rate allocation. It supports multiple concurrent applications, and is robust to network dynamics. Finally, RCRT’s rates are significantly higher than that of the state of the art in sensor net- workcongestioncontrol. Weenvisionseveralinterestingdirectionsforfutureworkincludingcoordinated rate allocation across sinks, differential treatment for flows unconstrained by the bottleneck region, and improvedconvergencetimeinnetworkswithhighlyvaringRTTs. 113 Chapter5 Energy-EfficientRate-AdaptiveGPS-basedPositioningfor Smartphones Manyemergingsmartphoneapplicationsrequirepositioninformationtoprovidelocation-basedorcontext- aware services. In these applications, GPS is often preferred over its alternatives such as GSM/WiFi based positioning systems because it is known to be more accurate. However, GPS is extremely power hungry. Henceacommonapproachistoperiodicallyduty-cycleGPS.However,GPSduty-cyclingtrades- off positioning accuracy for lower energy. A key requirement for such applications, then, is a positioning systemthatprovidesaccuratepositioninformationwhilespendingminimalenergy. In this chapter, we present RAPS, rate-adaptive positioning system for smartphone applications. It is based on the observation that GPS is generally less accurate in urban areas, so it suffices to turn on GPS only as often as necessary to achieve this accuracy. RAPS uses a collection of techniques to cleverly de- termine when to turn on GPS. It uses the location-time history of the user to estimate user velocity and adaptively turn on GPS only if the estimated uncertainty in position exceeds the accuracy threshold. It also efficiently estimates user movement using a duty-cycled accelerometer, and utilizes Bluetooth com- munication to reduce position uncertainty among neighboring devices. Finally, it employs celltower-RSS blacklistingtodetectGPSunavailability(e.g.,indoors)andavoidturningonGPSinthesecases. Weeval- uate RAPS through real-world experiments using a prototype implementation on a modern smartphone 114 Figure5.1: AccuracyofGPS,WPS,andGSM-basedPositioning and show that itcan increase phone lifetimesbymore thanafactor of 3.8over an approach where GPS is alwayson. 5.1 Introduction Manyemergingsmartphoneapplicationsrequirepositioninformationtoprovidelocation-basedorcontext- aware services. Our Urban Tomography [60] system is a good example. It allows a user to capture video clips, tags each with the most recent position information, and then automatically uploads each video to a server. Many participatory sensing applications, where the phone is autonomously recording ambientconditionsoruseractivity,alsocontinuouslyrecordpositioninformation. Otherapplicationsthat make continuous use of location or context information are Micro-Blog [33], TrafficSense [76], Pothole Patrol[25],MetroSense[24],PlaceIts[101],PeopleNet[77],MyExperience[32]. Intheseapplications,GPSisoftenpreferredoveritsalternativessuchasGSM/WiFibasedpositioning systems because it is known to be more accurate. Figure 5.1 plots two example locations from which we have collected positioning data using all three positioning systems: GPS, WPS (WiFi-based positioning system from SkyHookWireless [115]), and GSM-based positioning on a N95 smartphone over the AT&T cellular network. Both locations had a clear view of the sky and usable WiFi access points so that GPS and WPS could work. The figure clearly shows that WPS is less accurate than GPS, and GSM-based 115 Figure5.2: PowerconsumptionofGPSonN95smartphone(Repeated30secondsonand90secondsoff) positioning has an error as high as 300 meters. For these reasons, the use of GPS for location-based applicationsisunlikelytodiminish;itmay,however,beaugmentedwiththeseotherpositioningmethods. However, it is also well-known that GPS is extremely power-hungry. Our measurements of the power consumption 1 (showninFigure5.2)agreeswiththeresultspublishedbyothers[113,4]andconfirmsthat the internal GPS on Nokia N95 smartphones uses around 0.37 Watt of power on top of∼0.06 W idle power. Keeping GPS activated continuously would drain the 1200 mAh battery on an N95 smartphone in less than 11 hours, even in the absence of any other activity. This is clearly a significant roadblock on the way to all-day smartphone usage, and a more intelligent and energy-efficient activation of GPS is the subjectofthischapter. The key insight that motivates our work is the observation that, when used by pedestrians in urban areas, GPS can exhibit errors in the range of 100m. GPS inaccuracy in urban “canyons” is well-known, but we have found that, even in relatively benign environments such as college campuses or residen- tial neighborhoods, GPS can exhibit this kind of inaccuracy, especially for pedestrian smartphone usage. Location-based applications will have to deal with this level of error using application-specific methods, suchasmap-matchingormap-snapping. Soweask: ifapplicationscantoleratethispositionerror,whynot tradeoffsomepositionaccuracyforreducedGPSenergyusage? Asimplewaytodothisistoperiodically duty-cycleGPS.Thistrades-offpositioningaccuracyforlowerenergy. However,thekeychallengeinthis 1 We have used the Power Monitor device from Monsoon Solutions Inc. for all of our power measurements and cross-verified it withtheNokiaEnergyProfilerv1.2softwaretool. 116 periodicGPSduty-cyclingistodecideonasuitabletimeperiod;foralmostanychoice,thereexistsauser mobilitypatternthatwillresultinunboundedpositionerror(Section5.2). To avoid this, a thread of research has examined different heuristics to cheaply determine a change of position sothat GPS can be selectively activated [55, 18, 119, 27, 20, 4]. Our work follows inthis thread, butmakestwocontributions. First,itintroducesnoveltechniquesforcheaplyinferringwhetherandwhen GPSactivationsarenecessary. Moreimportant,ratherthanmerelyconsideringeachtechniqueinisolation, wedesignacompletesystemthatusesacollectionoftechniquesinconcerttoreduceenergyusages. Atthecoreofourapproachisamethodtoestimateuservelocityfromahistoryofpreviouslymeasured velocities at the same location and the same time-of-day; intuitively, this velocity estimation leverages consistency in user behavior. When the estimated distance traveled approaches a user-specified accu- racy bound, our system (called RAPS, the rate-adaptive positioning system) activates GPS. This decision to activate GPS is delayed if the user’s current average activity level, as measured by a duty-cycled ac- celerometer, is inconsistent with historical activity at that position and time-of-day. Similarly, RAPS delays activation if the identifier and the signal strength from the currently active cell-tower indicates that previous activation attempts at locations with comparable identifier and signal strength information failed frequently. Finally, RAPS delaysGPSactivationifitlearns, over Bluetooth, ofamorerecentpositionfix completedbyanopportunisticcontact. WehaveimplementedthesetechniquesinacompleteRAPSprototypeontheNokiaN95smartphones andhaveexperimentedwithitonouruniversitycampus. Ourevaluationrevealsthat RAPS hasover3.8x longer lifetime than a scheme in which GPS is always on, and about 1.9x longer lifetime than a periodic GPSschemewithcomparableerrorrate. WealsobreakdownthecontributionsofeachtechniqueinRAPS towards these performance gains. Finally, we demonstrate that RAPS can be easily adapted to work atop a WiFi-based positioning system, WPS [115]. In general, our evaluation is encouraging and suggests that RAPS canobtainsubstantialenergysavingswithoutsacrificingtheaccuracyofperiodicGPS. 117 Figure5.3: GPStraceplotshowingtheinaccuracyofGPSinurbanareas. 5.2 Problem In this section, we first present our observations on the inaccuracy of GPS readings taken from a smart- phone. We demonstrate that, in urban environments and especially for pedestrian use, there is signif- icant uncertainty in GPS-reported positions, and location-aware applications must adapt to this using application-specific methods. We then explore whether, by periodically duty-cycling GPS readings, it is possible to achieve significant energy savings without sacrificing accuracy. This motivates the prob- lemwetackleinthiswork,thatofdesigninganenergy-efficientrate-adaptiveduty-cyclingforGPSbased positioning. Figure5.3plotsapartofaGPStracecollectedforaperiodof1weekusingasmartphonethatcontin- uouslyloggedGPSpositionsevery1second. Toobtainthisfigure,wewroteasmallprogramthatrecords raw GPS readings using the Location API provided by the Android OS. Later, we used the Google Maps API v3 to plot the points in the figure. An analysis of this trace reveals an interesting result. The “ground truth” path is labeled ‘A’ in Figure 5.3, but the trace contains a phantom path, labeled as ‘B’ in the figure, parallel to the ground truth path, which was never taken during trace collection. (That the phantom path alignswithawalkwayonourcampusis,webelieve,accidental: tothebestofourknowledge,theGoogle MapsAPIdoesnotdoanymap-matchingwhenprovidedwiththeGPScoordinates.). Moreover,thetrace 118 Distance (meter) 0 50 100 150 200 250 300 Average Distance Error Maximum Distance Error Samples (70 locations) No received GPS signals Relatively less clear view of the sky Figure5.4: GPSgroundtruthverification: DistanceerrorofGPSreadingvs. GPSgroundtruth hadpositionlogsthatweremuchfurthersouthoncampus,labeledas‘C’,whichwerenevervisitedduring tracecollection. While GPS inaccuracy for automotive navigation applications in urban canyons is well known, our finding suggests that such inaccuracies might be much more prevalent, and may affect pedestrian or out- dooruseofGPSevenoncampusesormoderatelypopulatedneighborhoodswithmodest-heightmulti-story structures. To understand the prevalence of this problem we decided to further investigate the accuracy of GPSonsmartphones. We collected GPS position readings from 70 different locations in the greater Los Angeles area in- cluding the USC campus, West Los Angeles, Glendale, Korea Town, and other areas. These locations wereselectedtocoveravarietyofoperatingconditionssuchaswide-openspaces,areaswithtrees,streets between buildings, indoors near windows, inside vehicles, and so on. We then compared the error in col- lectedpositionsrelativeto“groundtruth”positionsobtainedbymanuallymarkingeachlocationonGoogle Mapsandextractingthecorrespondingcoordinates. WhileGoogleMapsitselfmightbeinaccurate,many location-awareapplicationsdomapmatchingagainstGoogleMaps(orotheronlinemapservices),andour errorsarerepresentativeoftheerrorsthoseapplicationswouldsee. Figure 5.4 presents the result of this experiment. Black and gray bars represent the average and max- imum error, respectively, for each tested location, and the figure is sorted by increasing average error. Generallyspeaking, wehavefoundthatthisorderingcorrespondstodecreasingvisibilityofthesky, from 119 Figure5.5: DistributionofhorizontalaccuracyreportedbyGPSonN95smartphone left to right. (Our observation is clearly qualitative: without access to the satellites visible to the GPS receiver at each location, clearly we cannot quantify visibility.) With good visibility, GPS errors are rel- atively low, but still range from 5 to 35 meters and occasionally go up to as high as 120 meters. As we move to the right, the average error increases up to around hundred meters, with maximum error at times of over 300 meters. Finally, there were several places where GPS was completely unavailable. In fact, in theone-weekGPStracefromwhichFigure5.3wasdrawn,GPSwasavailableforonly11.2%ofthetime. This result is consistent with other reports [2] of low GPS availability on human-carried devices. This discussion confirms our observation in Figure 5.3: GPS may provide inaccurate positioning with average errorsashighas100metersormoreacrossawiderangeofurbanlocations. Where do these errors come from? A GPS receiver requires signals from 4 satellites, along with their ephemeris data, to calculate the time and position of the receiver in latitude, longitude, and altitude. As long as the receiver has a position fix using complete signals from at least 4 satellites, these errors are knowntobewithin15meters. Thesourcesoferrorinthiscaseareionosphericeffects(±5meters),shifts in the satellite orbits (±2.5 meters), satellite clock errors (±2 meters), multipath effects (±1 meters), troposphericeffects(±0.5meters),andcalculationandroundingerrors(±1meters)[87]. However,when GPSreceiversdonothavecompletesignalsorcompleteephemerisdatafromall4satellites,thentheerrors canincreasesignificantly. Forexample,ifsignalsfromonly3satellitesareavailable,aGPSreceivermust guessitslocationbyassumingeitherperfecttimesyncormeansea-levelaltitude. 120 Figure5.6: DistributionofdistancesbetweenGPSupdatesforperiodicGPSwith180secupdateinterval. When its guesses a position, a GPS receiver provides accuracy estimates. Figure 5.5, which plots the distribution of the horizontal accuracy estimates obtained from the GPS on the Nokia N95 smartphone, shows that the GPS itself often reports low confidence in its position results. Receivers use proprietary methodsforcomputingaccuracyestimatesandforcorrectingerrorswhenlessthan4satellitesarevisible, so it is difficult to infer the exact cause for the inaccuracy. However, what we do know is that there may exist significant inaccuracy in the position reported by these devices. (So far, we have reported GPS accuracy only on a single platform. In Section 5.4.4, we demonstrate that this problem may be pervasive: similar inaccuracies exist in at least three other platforms, running different phone operating systems. Moreover, we show that the use of Assisted-GPS does not improve accuracy, but can reduce the time to first-fix.) Moreover, smartphone GPS receivers are more likely to be inaccurate than, say, automotive GPS sys- tems. Smartphones have smaller antennae, are often carried in clothing or bags, are often indoors, and frequently powered off. As such, location-aware smartphone applications will have to have application- specific ways to deal with these inaccuracies: techniques such as map-matching [17] and map-snapping are, by now, well-established methods for addressing this problem. On the other hand, smartphone GPS use is known to be an energy drain, and many power users likely manually activate and de-activate GPS toconservebattery. Inthiswork,weaskthequestion: canwecleverlyactivateGPSonlywhennecessary, andsacrificealittleaccuracy(sincelocation-awareapplicationswillhavetodealwiththislossofaccuracy anyway),inexchangeforsignificantreductionsinenergyusagebyGPS? 121 Figure5.7: Updateintervalvs. averagedistancebetweenGPSupdatesforperiodicGPS. The simplest approach to trade-off accuracy for energy in GPS-based locations services is to periodi- callyduty-cycleGPS.Thisapproachiscommonlyusedinmanyreal-worldapplications. Forexample,the Urban Tomography application [60] activates GPS every 7 minutes and tags the videos taken by the user with the position information closest in time. Similarly, PEIR [78] collects GPS readings approximately every 30 seconds. However, the key challenge in this periodic GPS duty-cycling is to decide the time interval at which to turn on and off GPS. If the GPS is activated too often, it will waste a lot of energy whenthephoneismostlystationary. IftheGPSisactivatedtooinfrequently,accuracywillsuffer. To illustrate these tradeoffs with periodically duty-cycled GPS, consider Figure 5.6. To obtain this figure, we conducted an experiment in which, for a specific choice of period (3 mins), we measured the position uncertainty (the reported distance between two GPS readings in our trace taken at 3 minute intervals). The uncertainty is less than 40 meters for 28% of time, but may often exceed 100 meters and go as high as 300 meters. Clearly, this uncertainty depends upon the movement pattern of the user during the experiment. However, because periodic duty-cycles are oblivious to the actual mobility, this approach canincurhigherror. Moreover, there exists no single satisfactory value for the duty-cycle period, as shown in Figure 5.7. Figure 5.7 plots the average distance between two consecutive position updates as a function of the pe- riodic duty-cycling interval. This figure was generated from an experiment in which we collected GPS reading every 5 seconds for 48 hours. We simulated the different intervals by appropriately sub-sampling 122 the experimental trace. The figure shows that as the interval increases enabling lower energy usage, the uncertaintyincreaseslinearly,withnoobvioussweetspot. Another approach is to tune the GPS duty-cycling period to an application-specified average error bound. In Figure 5.7 if that an application could tolerate a 100m uncertainty, its GPS could be activated every 80 seconds. However, this may not help reduce energy significantly. GPS can take up to several tensofseconds afteractivation toget apositionfix, andmany GPSreceivers have apower-down delay of around 30 seconds ([55]). So, an 80 seconds duty-cycling interval will likely result in minimal savings. To be more precise, if we assume an ideal case where first-time-to-fix is always 6 seconds, then the GPS would be on for 36 sec (6 + 30sec power off delay) every 80 seconds, which translates into spending 600 Jouleperhour. ThismeansthatonN95smartphoneswith1200mAhbatteries,thebatterywilllastforless than27hoursevenwhenGPSduty-cyclingistheonlytaskonthephone. Inpractice,however,GPStimes out whensatelliteviews areunavailable. Ifthishappens asfrequently asitdidinour traces(88.8% ofthe GPSattempts),thenthebatterywilllastlessthan13hours. Evenatthiscost,theerrorsarenon-negligible. Insummary,wehavemadetwoimportantobservationsinthissection: 1)GPSisgenerallylessaccurate in urban areas, and 2) periodic duty-cycling with a fixed interval can introduce significant, potentially unbounded, error without necessarily providing significant energy benefits. This motivates the need for a positioning system that provides position information with reasonable error while expending minimal energy. In the rest of this chapter, we present RAPS, a rate-adaptive positioning system for smartphone applications. 5.3 Rate-AdaptivePositioningSystem Inthissection,westartbydescribingthegoalofRAPS,arate-adaptivepositioningsystemforsmartphone applications, and discuss how it is designed to meet that goal. We then delve into the details of the indi- vidual components of RAPS: 1) user movement detection using a duty-cycled accelerometer, 2) velocity and uncertainty estimation using space-time history, 3) GPS unavailability detection using celltower-RSS 123 blacklisting, and 4) position uncertainty reduction using Bluetooth. We conclude with a discussion of RAPS’slimitations. 5.3.1 Overview RAPSisdesignedforsmartphoneapplicationsthatrequirepositioninformationforlocation-basedcontext- aware services. It is based on the observation that GPS is generally less accurate in urban areas, so it suffices to turn on GPS only as often as necessary to achieve this accuracy. Thus the goal of RAPS is to reduce the amount of energy spent by the positioning system while still providing sufficiently accurate positioninformation. Toachievethisgoal,RAPSusesacollectionoftechniquestocleverlydeterminewhentoturnonGPS, and when not to. First, it uses a duty-cycled accelerometer to efficiently estimate user movement. RAPS detectswhethertheuserismovingornot,andalsomeasurestheactivityratio,thefractionoftimethatthe user is in motion between two position updates. The movement detection is used to prevent RAPS from activatingGPSwhentheuserhasbeenstationary. Theactivityratioisusedtoestimatethecurrentvelocity based on historical correlations between velocity and activity (see below); this lets RAPS activate GPS onlyiftheestimateduncertaintyinpositionexceedstheaccuracythreshold. Second, RAPS stores the space-time history of user movements (where the user has been and at what time) to estimate when to activate GPS. Whenever RAPS gets a new position update, it calculates the average velocity relative to the previous position, and associates this velocity and the recent activity ratio with the previous space-time coordinate. It uses averages of the velocity and activity ratio to estimate, duringasubsequentvisittothesamelocationatthesametime-of-day,thelikelyuservelocity. Thisinturn enables RAPS toestimatepositioninguncertainty,allowingittoselectivelyactivateGPS. Third, RAPS employs celltower-RSS blacklisting to detect GPS unavailability (e.g., indoors) and avoids turning on GPS in these places. Whenever it succeeds or fails in obtaining new position update, it records the current celltower ID and the received signal strength (RSS) information and associates with thatsuccessorfailure. Then,whenitdeterminesthatitistimetoactivateGPS,itchecksthecelltower-RSS 124 table for the historical probability of GPS availability and defers GPS activation if it believes that GPS is notlikelytobeavailable,thusavoidingunnecessaryenergyusage. Finally, RAPS utilizes Bluetooth communication to reduce position uncertainty among neighboring devices. Whenever it receives a new position update, it broadcasts this information to Bluetooth peers so that they can update their position without activating GPS themselves. If a device receives a position update from a peer that has greater uncertainty than its own estimate, it replies with its more accurate information. Eventually, all devices in the neighborhood synchronize to the position information with leastuncertainty. All the techniques that RAPS uses can be realized on the current generation of smartphones. As we discuss later, we have implemented a complete RAPS prototype on a smartphone, the Nokia N95. In the followingsubsections,wediscusseachofthesetechniquesinmoredetail. 5.3.2 Movement Many,ifnotall,modernsmartphonesareequippedwithanaccelerometer. Thereisasignificantliterature on the effectiveness of using an accelerometer to detect whether the user is moving or not [55, 119, 4]. Others have explored techniques to estimate velocity [75] using the accelerometer. Given that we are interested in estimating user speed to minimize GPS activation, we too use the accelerometer to detect motion. However, our use of the accelerometer differs from the prior literature in two important ways. First, unlike most prior work that either uses the accelerometer as a binary sensor to detect movement or non-movement,orrestrictsittodetectpedestrians,weusetheaccelerometertomeasuretheactivityratio, definedasthefractionofagiventimewindowduringwhichtheuserisinmotion. Wethenusethisactivity ratio along with the history of velocity information (Section 5.3.3) to estimate the current velocity of the user. Second, given the high power consumption of the accelerometer, we carefully duty-cycle it to save energy without significantly sacrificing accuracy. We describe each of these two aspects below in more detail. 125 Figure 5.8: Example behavior of the onset detector where the acceleration signal and its envelope of user movement From a continuous sequence of accelerometer samples, it is possible to detect whether a user is sta- tionary or not using an onset detection technique [82]. This technique can reliably detect the start and duration of significant user activity. It does this by maintaining running estimates of the signal envelope (dynamic upper and lower bounds of the signal) and compares these against the noise mean (which is 1g, orgravity, inour case) andthestandard deviation. Itisdesigned such thattheonset isdetected assoonas possible after the beginning of a period of significant activity. Moreover, the end of the period is declared conservatively, i.e.,onlyaftertheenvelopeoftheaccelerationmagnitudehasdecayedbelowandhasthen not exceeded one standard deviation from the noise level, indicating quiescence. Figure 5.8 illustrates the behavioroftheonsetdetectorwheretheaccelerationsignalanditsenvelopeofusermovementareplotted insolidgraylinesalongwiththeonsetdetectionresultindottedblackline. RAPSusesthisonsetdetection method and calculates the activity ratio as the fraction of the time during a measurement period that the userwasactive. Thisvalueislaterusedtoestimatetheuservelocity,whichwedescribeinSection5.3.3. However, RAPS cannotusetheaccelerometercontinuouslybecausemeasuringaccelerationcanincur significant energy usage. Figure 5.9 plots the power usage from our measurement on an N95 smartphone when the accelerometer was turned on and off at 30 second intervals. This measurement shows that the accelerometer consumes around 0.08 Watt, which means that turning on the accelerometer for 5 minutes consumes more energy than activating GPS for 1 minute. In other words, if the accelerometer is always 126 Figure5.9: PowerconsumptionofaccelerometersensoronN95phone onandGPSwasturnedonevery5minutesonaverage,thenover50%oftheenergywouldbeusedbythe accelerometer,andwemightaswellturnonGPSevery2.5minutesinstead. Given that energy-efficiency is a major goal of our design, we argue that operating the accelerometer continuously is not a viable option. RAPS duty-cycles the accelerometer carefully, using a duty-cycling parameterderivedempirically,asdescribedbelow. Our method for deriving a good duty-cycling parameter involved first collecting continuous accelera- tionmeasurementsforfivedifferentkindsofcommonhumanactivities: beingstationary,frequentwalking and stopping, fast walking, driving in a car, and milling about in a coffee shop. Although these five activ- ities do not cover every possible human movement, our intention is to illustrate a plausible methodology for selecting a duty-cycling parameter. It is possible to optimize the parameter selection method, and we have left that to future work. For each activity, we obtained a 5-minute long acceleration trace. For each trace, we calculated the reference activity ratio for the always-on accelerometer case using the onset de- tector. Then, we performed offline analysis that emulated duty-cycling on these logs for various ON and OFF periods, and calculated the error in the activity ratio with respect to the reference always-on case. The parameters we emulated range from 5%∼ 50% for the duty-cycle, and 2∼ 15 seconds for the ON period. Our goal was to select the lowest duty-cycle parameter which resulted in less than 10% average erroracrossallfiveactivities. 127 Figure 5.10 plots the average error (averaged over five activity logs) as a function of the duty-cycle withvariousONperiods. Fromthisfigure,theapproximatekneeoftheboundingcurvescorrespondstoa duty-cycle parameter of 12.5% with 2 and 14 seconds ON/OFF periods; this incurs 3% error on average and less than 10% error across all the activities. Intuitively, RAPS is able to detect human activity which has a timescale larger then multiples of 16 seconds, by simply turning on the accelerometer for a short fraction of that time window. In doing so, the accelerometer consumes 1/8 of its original power, which is 0.01Watt,whichsignificantlyaltersthebalanceofpowerusagebetweenGPSandtheaccelerometer. Could we have used a similar accelerometer duty cycling technique to estimate user speed (and there- foredistance),ratherthanjustactivity? Intheory,distanceisasimpleintegralofvelocity,whichinturnis anotherintegralofaccelerationonceweknowtheexactorientationofthephone. To determine this, we used the continuous accelerometer traces obtained above, and computed the horizontal displacement of the user using a technique proposed in [75]. To do this, we needed to estimate thegravityvector,whichcanbeobtainedbyperformingarunningaverageofaccelerometersamples(when the magnitude of the acceleration vector is close to 1g, the gravity). This gravity vector estimate, in turn, enablesestimationoftheverticalcomponentandthemagnitudeofthehorizontalcomponentoftheuser’s motion regardless of the orientation of the three-axis accelerometer. Using this idea, we calculate the distancethattheuserhasmovedasfollows: d=a−g : useraccelerationminusgravity p= d·g g·g g : verticalcomponentofd h=d−p : horizontalcomponentofd v= Z h·dt : velocityvector distance= Z v·dt 128 Figure 5.10: Accelerometer duty-cycle parameter selection: we select 12.5% as our accelerometer duty- cyclewhichincurs3%erroronaverage,andlessthan10%errorforfivedifferentactivitymodes(station- ary,walks&stops,fastwalking,drivinginacar,slowwalkingwithconversation) Weconductedextensiveexperimentsthatrevealedthatthiscalculationisroughlycorrectwhentheorienta- tionofthephonedoesnotchangetoofrequentlyandtheaccelerationisgreaterthanthenoiselevelduring the period of movement. However, it often overestimates distance when the user is handling the phone in herhands,andunderestimatesdistancewhensittingquietlyonacushionedcarseat. Furthermore, using a method similar to that described above, we found that a duty cycle of 50% or more is required to estimate the distance moved by the user within 10% error of the always-on case. This makes it a less attractive option for us, so RAPS uses only the activity ratio whenever we have sufficient historytoperformvelocityestimation,andfallsbacktousingboththedistanceestimationandtheactivity ratioonlyifthereisinsufficienthistory. Wedescribethisinmoredetaillaterwhenweexplainour RAPS algorithminfull. 5.3.3 Space-TimeHistory AkeycomponentofRAPSisthespace-timetablethatrecordsthepasthistoryofusermovements. Specif- ically, RAPS maintains the average user velocity and the average estimated activity ratio (Section 5.3.2) associated with each space-time unit in a 3-dimensional (latitude, longitude, time-of-day) coordinate sys- tem. Whenever RAPS needs to decide when to activate GPS, it looks up the history of average user 129 velocity and activity ratio associated with the current position and time, and then calculates the current positionuncertaintybasedontheestimatedcurrentvelocityandtheactivityratio. Theintuitionbehindthisideaisthatthereis,often,consistencyinuserbehavioratagivenpointinthe space/time coordinate system. For example, a person is, in general, more or less stationary for extended durations when at the office during the work hours or at home overnight. A person is likely to move at walkingspeedatplacesthatsheusuallywalks,andalsolikelytomovefastonroadsthatsheusuallydrives inavehicle. Conversely,apersonisnotlikelytobestationaryinthemiddleofastreet,andalsonotlikely to walk on a freeway. This is the intuition that lies behind our use of space-time coordinates to associate user movement history, and to estimate speed. (One might obtain more precise estimates by maintaining aweek-longhistory,andusingday-and-time-of-weektoindexintothishistory: wehaveleftthattofuture work). RAPS updatesandusesthisspace-timehistoryasfollows. First,forscalingreasons,itquantizesboth the space and time dimensions. The space coordinates are quantized into a 2-D grid by rounding latitude and longitude values to 3 decimal places; 0.001’ x 0.001’ grid box. In the Southern California area, this approximately corresponds to a 92.2m x 111.2m square area. In other locations, RAPS quantizes the historysothatthesizecorrespondstoabout100m,thelowerboundonthepositionaccuracywetarget. The time-of-day dimension is quantized into bins of size 30 mins each. The quantized space-time coordinate systemisillustratedinFigure5.11. Next,RAPSassociateswitheachgridboxinthisquantizedcoordinatesystemtwoquantities: ahistory of average velocity and the average activity ratio seen in the box. More precisely, whenever it receives a new position P B at time T B , it calculates a velocityV A as distance A→B timeinterval A→B relative to its previous known position P A at time T A , and usesV A to update the average velocityV A associated with the space-time grid boxS (P A ,T A ) . Inasimilarmanner,italsoreadstheactivityratioduringthistimeintervalupdatestheaverage activityratioR A associatedwiththatspace-timegridbox. 130 Figure 5.11: Conceptual view of the 3-D space-time coordinate system used for maintaining history of usermobility. Thisspace-timehistoryisusedtoestimateuncertaintyasfollows. Supposethattheuserwaslastknown tobeat(P A ,T A )(P A isthelastrecordedpositionfix). TocalculatetheuncertaintyU(t)atsometimet >T A , RAPS usesthefollowingequations: V(t)=V A ∗ R(t) R A (5.1) U(t)=V(t)∗(t−T A )+U A (5.2) where V A and R A are the average velocity and activity ratio associated with (P A ,T A ), and U A is the last uncertainty of position P A at time T A , R(t) is the current activity ratio, and V(t) is the estimate of the current velocity. If RAPS does not find information associated with (P A ,T A ), it falls back to using only the position information and finds an entry that matches P A only. This uncertainty calculation is based on theassumptionthattheaveragevelocityinaspace-timecoordinatelocationisproportionaltotheaverage activityratiointhatlocation;i.e.V A ∝R A . Intuitively,weusetheactivityratioasasurrogateforvelocity. ThiscanleadtobetterestimatesofGPS activationtimesthansimplyusinghistoryordetectingmovement,andcanhavelowerenergy(aswehave discussedearlier)thanestimatingvelocitybykeepingtheaccelerometeralwayson. 131 Tounderstandhow RAPS worksinpractice,considerthefollowingexample. Forillustration,assume that the decisions are made after every unit of time. If a user moves into a position A, is stationary for 4 units of time and moves out of position A in the next unit of time at a velocity of 10m/s and activity ratio of 0.5. Then the velocity and activity ratio associated with position A during this period is{0,0,0,0,10} and{0,0,0,0,0.5}respectively,resultinginaveragevaluesof2m/sand0.1storedinthehistory. Lateron, whentheuserrevisitspositionA,therearetwopossiblecases;iftheuserisstationary,thecurrentactivity ratio R(t) will be zero, and thus the estimated velocityV(t) is zero by Eq. 5.1. When the user is moving outofpositionAwithR(t)closeto0.5,V(t)becomes2∗0.5/0.1=10m/stherebycorrectlyestimatingthe user velocity and thus the uncertainty. This approach allows RAPS to cheaply estimate user movement, activatingGPSonlywhenusermovementmayhaveexceededtheaccuracybound. 5.3.4 Celltower-RSSBlacklisting Prior work has proposed the use of GSM signatures, which include information about visible cell-towers and their RSS (Received Signal Strength), to detect large scale movement [20] or recognize mobility modes [100]. In this section, we investigate whether or not such signatures can be used to detect motion, so we can regulate how often GPS needs to be activated. GSM data comes for free – as long as the phoneisonandhasanactiveservicesubscription,GSMdatacanberetrievedwithoutincurringadditional energy cost. However, most prior work on GSM-based localization has assumed sufficient knowledge of the location and RSS information from all visible cell towers. In practice, this information is often not available to third party application developers on many platforms. At least for both Symbian-OS on Nokia-N95phoneandAndroidonG1phone,onlyonecelltowerinformationisvisibleatatime,andthere isnoinformationaboutthelocationofthetower. ThisisonereasonwhymuchofthepriorworkonGSM localizationhasbeenevaluatedonlyinsimulation. To determine the feasibility of using cell-tower information to adaptively activate GPS, we first em- pirically examined whether information from a single cell-tower can reliably detect user movement. Fig- ure 5.12 plots the cumulative distribution of the distance between two consecutive GPS locations when 132 Figure5.12: CDFofthedistancebetweentwoconsecutiveGPSlocations5secondsapart;withandwithout aGSMcellId change. Figure5.13: RSSdifferencevs. distance,betweentwopositionswithingsamecellId therewasachangeincellId. ItalsoplotstheCDFofthemaximumdistancebetweentwopositionswithin thesamecellId. EachGPSupdatewasobtainedevery5seconds. Oneobservationfromthefigureisthat,58.3%ofthetime,alessthan10mdifferenceinGPSpositions can result in a change in cellId. The rest of the time, when a cellId changes, the difference in GPS positionscanbeuniformlyanywherebetween10mand150m. Conversely,themaximumdistancebetween twopositionswithinsamecellIdisgreaterthan100mfor28.2%ofthetime(CDFof71.8%within100m). Thus,theseresultsimplythatsimplyusingthecellIditselfprovidesinsufficientinformationaboutwhether theuserhasmovedasignificantdistanceornot. Our next step was to see whether the signal strength difference within a cellId can be an indicator of change in position. Figure 5.13 plots the maximum, average, and minimum distance between two GPS updates with different RSS values within same cellId. Although the average distance plot shows a 133 Figure5.14: GPSavailabilityprobabilityasafunctionofsignalstrengthfortwodifferentcellId’s rough trendinwhich anincreasing RSSdifference correlates withincreasing distance, thevariance ofthe distance is too high to be used as a measure of distance. This variability is not too surprising given the complexity of the urban environment we live in. These results together show that using the identifier of, and the signal strength from, a single cell-tower cannot reliably identify user movement, at least in urban areaswithirregularcelldeployment. SincewearemerelyinterestedindeterminingwhetherandwhenGPSshouldbeactivated,weconsid- ered the following question: instead of using cell towers to detect motion, can we directly detect whether users are in an environment (e.g., indoors) where it would be futile to turn on GPS? To understand this question,wefirststudiedtherelationshipbetweenGSMcellId andtheirRSSvalues,andGPSavailability. We define GPS availability as the fraction of attempts for which it is possible, at a given location, to get a positionfixwithin2minutesstartingfrompower-offstate. This2-minutetime-to-firstfixtimeoutfollows from GPS receiver properties: a GPS receiver requires information from 4 satellites to get a position fix andreceivingfullephemerisdataforasatellitetakes30secondseach. ForagivencellId,weexpectedtoseesomecorrelationbetweenRSSandGPSavailability,sinceGSM signals indoors are heavily attenuated. Figure 5.14 plots the GPS availability probability as a function of signal strength for two different cellId’s. We note several features. First, there is a good RSS range at which GPS is available most of the time, and also a bad RSS range at which GPS is mostly unavailable. Examples of extremely bad locations include elevators and underground parking lots. Second, there is a 134 variableRSSregionwherethereexistsahighvariabilityintheGPSavailability. Inthisregion,itisdifficult to derive a strong relationship between RSS value and availability, suggesting that GPS availability must beestimatedprobabilistically. Finally,notethattheseregionboundariesdifferfordifferentcellIds. From theseresults, itisclear that theremaynot existauniversal way topredict GPSavailability from cell-tower information. However, we believe that maintaining a history of GPS availability per-cellId can helpaccuratelypredictwhetheraGPSfixislikelytobesuccessful, givenaspecific cellId andthecurrent RSS reading. Indeed, RAPS uses exactly this idea. Whenever a GPS reading is successfully obtained or the request has timed-out, it stores this information in a celltower-RSS blacklist. To do this, it reads the currentcellIdandRSSvaluesandincrementsthesuccessorfailcounterforthecorrespondingcellIdinthe list. ThentheGPSavailabilityforthatparticularcellIdissimplythefractionofsuccessfulattempts. Italso updatesoneoftwoRSSthresholdvaluesassociatedtoeachcellId;RSS Good Thresh isthebestRSSvaluethat resulted in GPS update failure, and RSS Bad Thresh is the worst RSS value that resulted in successful GPS update. The list is called blacklist because RAPS uses it to maintain locations at which GPS activation is more likely to fail, so it can delay activation and save energy. To do this, RAPS uses an eviction policy that discards the cellId entry with the best GPS availability when the list is full. RAPS conservatively assumesGPSavailabilityifnopriorhistoryexistsintheblacklist. Then, when the position uncertainty indicates that it is time to get a GPS update, RAPS checks the blacklist for the GPS availability predicted for the current cellId-RSS reading. Ifthe listindicates that the user is in the good or variable region, RAPS turns on GPS with a probability equal to the historically- observed availability. Ifitfinds itselfinthe bad region, itwaitsuntil either thereisachange inGSM data (eithercellId orRSS)oruntilamaximumtimeouttimehaspassed. In summary, the goal of celltower-RSS blacklisting is to estimate, based on a history of GPS attempts atlocationswithspecificcellId andRSSreadings,locationswhereturningonGPSisunlikelytoprovidea positionfix. Ourmethodcanberobusttocell-towerdensity,unlikeschemesthatattempttodetectmobility using cellId information. However, its performance is, of course, heavily dependent on user motion, on 135 Figure5.15: PowerconsumptionofBluetoothonN95phone the surrounding environment, and on cell-tower placement. We quantify the performance benefits of this approachinSection5.4. 5.3.5 Bluetooth-basedPositionSynchronization In this section, we discuss the use of Bluetooth communication to synchronize position information be- tween neighboring devices. This enables phones to save energy by reducing the number of GPS activa- tions. Consider a scenario where there are two smartphones, A and B, in direct communication range of each other. If A has recently activated GPS and received a position fix, then it is possible for B to get thepositioninformationfromitsneighboringnodeusingpeer-to-peercommunicationwithouttheneedto activateGPSitself. IfBhappenstohavebetterposition(loweruncertainty)thanA,thenitcanimmediately notifyAofthatfactandAcanuseB’spositiontoupdateitself. Thegoalistoopportunisticallysynchronize thepositioninformationwithBluetoothcontactstoloweroveralluncertaintyandreduceenergyusage. 136 Bluetoothisagoodcandidateforsuchapositionsynchronizationforseveralreasons. First,thecommu- nication range of Bluetooth in smartphones is in general less than 10 meters. Thus, the added uncertainty inpositionatthereceivingnodeislessthan10metersrelativetothetransmittingnode. Ifthetransmitting node transmits its uncertainty along with its last position, then the uncertainty at the receiving node can conservativelybesetasthereceiveduncertaintyplusthemaxcommunicationrange,10meters. Second, the energy cost of Bluetooth is considerably less than that of GPS. Figure 5.15 plots the actual power consumption on smartphones for a master-slave pair while running our implementation of the position synchronization protocol (which we describe below). Using Bluetooth, most of the power is consumed on the master node while discovering the nearby devices and their services. This contributes around 0.15 Watt of power relative to idle state for around 15∼ 20 seconds. The actual transmissions (∼0.07W) and receptions (∼0.09W) take less than one second, and listening for and detecting incoming discovery requests consumes almost negligible power, less than 0.01W relative to idle state. During one synchronization cycle depicted in the figure, the slave node used 0.09J, and the master node used 3.07J, averaging1.58Jpernode. Forcomparison,ifaGPSreceiverwasturnedonandstayedonfor60secondsto getapositionfix,itwouldhavespentaround0.37W∗60sec=22.2J. Thus,ifasingleBluetoothexchange could avoid GPS activation at one of the two nodes, about 43% reduction in energy usage (overall, across bothnodes)wouldbeachieved. Furthermore, duetothemaster-slavecommunicationarchitectureofBluetoothtechnology, theenergy costofdevicediscoveryisamortizedoverthenumberofnodesintheneighborhood. Forexample,ifthere are5nodesintheareaandonenodeactsasamasterwhileothersasslaves,then,ifaGPSactivationatone node, followed by Bluetooth communication can avoid GPS activations at the other 4 nodes, the energy costforthetwocasesis5∗22.2=111Jversus22.2+3.07+4∗0.9=28.87Jresultingina74%reduction inenergy. Finally, Bluetooth is available on almost all mobile phones, not just smartphones, and many users enable Bluetooth for frequent everyday use. We see this likely to persist, with the passage of legislation requiring drivers to use hands-free headsets, many of which use Bluetooth. Thus, we envision a future 137 wheremanysmartphonesrunourRAPSsoftwaretoenergy-efficientlygettheirpositionfromneighboring devices. Furthermore, it is also possible to imagine future Bluetooth access points that provide accurate location beacons for fine-grained infrastructure-based location services at public places and places where GPSisunavailable(i.e.positioningintunnels,subways,orforadvertisementsinshoppingmalls[3]). Our Bluetooth-based Position Synchronization protocol (BPS), which we have prototyped on a Nokia N95, works as follows. By default, every node becomes a Bluetooth slave node and stays in idle listening state awaiting incoming device discovery requests. Once a node decides to transmit its position and un- certaintyinformation,itassumestheroleofaBluetoothmasterandscansitsneighborhoodfordeviceand servicediscovery. Ifanyneighboringslavenodesexist,themasterconnectstoallofthem,andbroadcasts itspositioninformation. Eachslave,uponreceptionofthepositioninformationfromthemaster,compares its uncertainty and updates its own position if the received position has lower uncertainty. If the received uncertainty is higher than its own, the slave replies to the master with better position and uncertainty val- ues. When the master receives a reply from the slave, it also compares the uncertainty, updates its own positionifthereceivedpositionhasloweruncertainty,andrebroadcaststhatinformation. Atthispoint,the uncertaintyvalueofallconnecteddevicesaresynchronized. Finally,recallthatwhenanodereceivesabetterpositionestimatefromanothernode,itaddsa10mun- certainty(thenominalBluetoothrange). Ifitre-propagatesthisestimatetoanotherneighbor,thatneighbor will conservatively add 10m again to the estimate. However, this uncertainty propagation is not serious: a node accepts a neighbor’s estimate only if that estimate, plus the 10m uncertainty, is better than its own estimate. Thus,ateverystep,Bluetoothsynchronizationresultsinimprovedaccuracyestimates. To determine when to transmit, BPS employs two simple rules. A node decides to become a master andinitiatesynchronization wheneither1)ithasreceived afreshGPSpositionupdate, or2)whenaGPS update was requested but was unavailable for a specified interval. In Section 5.4.1, we present a result showingthatBPScanbeeffectiveinreducingthenumberofrequiredGPSactivations. 138 5.3.6 Discussion Three details of RAPS are worth mentioning briefly. First, the user space-time history and the celltower- RSSblacklistmustbepopulatedfor RAPS toworkefficiently. Whilethisdataisbeingpopulated, RAPS aggressively activates GPS, and frequently measures celltower-RSS information. Second, our velocity estimationbasedonactivityratiocanbemisledbyhandsetactivitynotrelatedtohumanmotion. Forusers who continuously fiddle with their mobile phone while sitting in one location, for example, RAPS will recordaninflatedactivityratiowithrespecttovelocity. Subsequentvelocityestimatesatthatlocationcan underestimate the true velocity. Finally, accelerometers on smartphones may need a one-time per-device calibration of the offset and scaling before running RAPS. Before our experiments, we have manually calibratedtheaccelerometeroffline. OurBluetooth-basedpositionsynchronizationrequiresuserco-operation. Thisprotocolraisesprivacy and security concerns, which we have not considered in this work: our objective was merely to explore the energy-reduction potential of Bluetooth synchronization. It would also require incentivizing users appropriatelytosharetheirpositionwithBluetooth-neighbors,atopicbeyondthescopeofthisdissertation. Weobserve, however that,giventhewayourprotocolworks,eachnodeisroughlyequallylikelytoavoid GPS activations as a result of Bluetooth-based synchronization, so there may exist a natural incentive to participate. 5.4 Evaluation In this section, we present results from real world experiments using our prototype implementation of RAPS on a modern smartphone. We have implemented RAPS in Symbian C++ for the Symbian S60 3rd FP1 devices. In all our experiments, we have used the Nokia N95-3 smartphone, which has GPS, a built-in accelerometer, Bluetooth, WiFi and 3G/EDGE interfaces, and a 2GB micro-SD card. We have experimentedwithour RAPS implementationinandaroundtheUSCcampus. Ourevaluationisdesignedtoanswerfourquestions: 139 History Accel. C-RBlacklist BPS RAPS RAPS-B × RAPS-BC × × RAPS-BCA × × × Always-On PeriodicGPSwith20secondsinterval Periodic PeriodicGPSwith180secondsinterval Table 5.1: Six Different Schemes Used for Evaluation ( -mark and×-mark represent enabled and dis- abled,respectively) • How much, in absolute terms, does RAPS increase lifetime, and how much do each of its compo- nentscontributetothisimprovement? • CouldaperiodicGPSactivationstrategyhaveperformedjustaswell? • Is RAPS flexibleenoughtobeincorporatedwithaWiFi-basedpositioningsystem? • AretheGPSerrorsthatmotivatedthedesignof RAPS pervasive? Wediscussthesequestionsinthefollowingsub-sections. 5.4.1 QuantifyingtheBenefitsofRAPSanditsComponents Inthissub-section,wepresenttwokindsofevaluation. First,wedemonstratetheenergysavingsachieved by RAPS, relative to an always-on GPS schemes. Second, we quantify the benefits of each of our tech- niques: mobility detection using a duty-cycled accelerometer, celltower-RSS blacklisting, and Bluetooth- basedpositionsynchronization. Methodology. Toconductthisevaluation,weprogrammedsixsmartphonestousedifferentGPSactivation strategies, as discussed below. All of these six phones were placed in a single bag, and carried by one of theauthorsforalmosttwoentiredays. Duringasinglerunoftheexperiment,theexperimenterwentabout his normal daily activities, mostly inside and around the USC campus. These activities involved a variety ofmobilitymodes,includingoccasionaltripsinacar. Therewasnointentionalrepetitionnoranyartificial movement. Moreover, the phones were not used for any other activities, such as browsing, or calling. Figure5.16showsthelocationsvisitedbytheexperimenterduringarunoftheexperiment;thegeographic 140 Figure5.16: GPStraceplotofourexperiment spread of the locations is over 3 miles. We conducted several runs, and report the result of one of these; otherrunsshowqualitativelysimilarresults. Ofthesixphones,tworanRAPSwithallofitscomponentsenabled,whilethreephonesranavariantof RAPS eachwithadifferentcombinationoftheheuristicsenabled;mobilitydetectionusingaduty-cycled accelerometer, celltower-RSS blacklisting, and Bluetooth-based position synchronization. (The space- time history based velocity estimation is a fundamental component of RAPS that cannot be disabled.) In describing our results, we use the following notation (Table 5.1): RAPS denotes results from the phone runningRAPSwithallofitscomponentsenabled;RAPS-BdenotesRAPSwithoutBPS(Bluetooth-based positionsynchronization);RAPS-BCdenotesRAPSwithoutBPSandwithoutcelltower-RSSblacklisting; 141 Figure5.17: Lifetimeofthephones(inhours:min)foreachofthetestedschemes and RAPS-BCA is RAPS without BPS, celltower-RSS blacklisting, and accelerometer-based velocity estimation. Finally, another phone was programmed with alternative GPS activation schemes: Always- On denotes a scheme in which GPS is never turned off. Our experimental methodology, of carrying six phonesinonebag,ensuresthateachphoneseesthesameGPSandcelltoweravailability,anduseractivity. Moreover,allphonesarewithinBluetoothcommunicationrangeofeachother,andthosephonesthathave BPSinstalledcanbenefitfromsynchronization. Weseededeachphonewithtwodaysworthofpriorspace-timehistoryandblacklistinformation. The batterywasfullychargedbeforestartingtheexperiment, andtheexperimentranuntilthebatterycapacity dipped below 14% of full charge (level 1, out of 7 levels) at which point we intentionally terminated the application on that phone. This ensured graceful termination of the application, and safe retrieval of experimental logs. Our actual experiment ran for approximately 34 hours for the longest lasting phone whiletheAlways-Onphoneterminatedinapproximately9hours. Lifetime. Our first performance metric is lifetime: the time from when the experiment was started until the battery indicator for the phone reached 14% of full charge. Figure 5.17 shows the lifetime of each phonefromourexperimental run. Thereareseveral observationstobemadeinthisfigure. First, RAPS’s lifetime is 3.87 times longer than that of Always-On, extending life of the smartphone on a single charge bymorethan25hours. Bycomparison,thestate-of-the-artscheme[55]showsa50%energyimprovement overAlways-Oninanemulatedscenario. 142 Figure5.18: Eventtimelineofthethreephones;twowithBPSenabled,andtheotherwithBPSdisabled Figure 5.17 also shows the lifetime of RAPS variants, from which we can infer each RAPS compo- nent’scontributiontolifetimesavings. By comparing the lifetime of RAPS with that of RAPS-B, we see that BPS increased lifetime by 2 hours and 48 minutes. This corresponds to about 10.8% of the total RAPS lifetime increase over the Always-On case. Although it might seem that our evaluation methodology might overestimate the per- formance benefits from BPS, since phones were carried in close proximity, we believe this is not always true. If BPS penetration were high, then it is quite conceivable that the average number of Bluetooth con- tacts seen in an urban or campus setting could be considerably higher than the one that we have in our experiment,andourevaluationcouldunderestimateenergysavings. To understand how BPS enables energy savings, it is instructive to look at a timeline of Bluetooth messagingandGPSactivation. Figure5.18showsanexcerptofatimelinecontainingtwophonesrunning full RAPS, and one running RAPS-B. Three kinds of events are shown in the figure: GPS activation, Bluetooth transmission attempts, and Bluetooth reception. Notice how Bluetooth communication clearly defers GPS activation in the two RAPS phones, relative to the RAPS-B phones. Also, notice that BPS benefitsarenotunidirectional: eachRAPSphonebenefitsfromtheother. Thisprovidesanaturalincentive for BPS adoption; by adopting BPS, users will not only benefit others, but will also improve their own phone lifetimes. Of course, in our timeline, a GPS activation event may or may not result in a GPS position update since GPS may timeout due to unavailability. Nevertheless, activation consumes energy regardless of whether it results in a position fix or not. Moreover, Bluetooth transmission attempts also 143 Figure5.19: Contentofthecelltower-RSSblacklist include both successful and failed transmissions. Failures happen when both nodes attempt to become a master at the same time and neither was listening to become a slave device. This happened several times in our experiment because all phones were in the same bag and their activities and positions were closely synchronized: in this case, our evaluation methodology is somewhat adversarial with respect to BPS. Becauseofthesefailuremodes,twophonesrunningBPSmayactivateGPSatdifferenttimesbecausethey canhavedifferentuncertaintyestimates. By comparing RAPS-B and RAPS-BC, we see that celltower-RSS blacklisting contributed a signif- icant increase to lifetime; it extended the lifetime by 15 hours and 11 minutes, or 59.0% of the total lifetime increase. To understand why this RAPS component is effective in increasing lifetime, consider Figure 5.19. This figure depicts the content of the celltower-RSS blacklist at the end of our experiment. Bar graphs represent the failure/success counts of GPS activations for each celltower that was observed when GPS was activated. The continuous line shows the corresponding success ratio, and celltowers on the x-axis are ordered by decreasing success ratio. Two features are evident from this graph. First, for a majority of cell-towers (those on the middle and left of the plot), GPS position fixing never fails. Second, for a smaller number of cell-towers, which also happen to be frequently visited, GPS failures do occur. We conjecture that this latter set includes cell-towers observed when a user is indoors; in this case, the GPS failures represent the cost of learning the different RSS values to blacklist. As we shall see below, 144 Figure5.20: AverageGPSactivationinterval(inseconds)foreachofthetestedschemes celltower-RSS blacklisting can significantly increase the average interval between GPS activations (or, equivalently,canreducethenumberofGPSactivations). BycomparingRAPS-BCAwiththeAlways-Oncase,weseethatourspace-timehistory-basedvelocity estimation,togetherwiththeideaoftrading-offaccuracyforenergyandallowinguncertaintytobeashigh as 100 meters, extends the lifetime by 7 hours and 22 minutes over the Always-On case, contributing to 28.5%oftheenergysavings. On the contrary, the use of accelerometer for velocity estimation actually resulted in only about 1.5% lifetime savings (compare RAPS-BC and RAPS-BCA). As we show later, RAPS-BC does have notably fewerGPSactivationsthanRAPS-BCA.However,fortheuserinourexperiments,clearlytheenergycost of using the accelerometer (even a duty-cycled one) almost cancels the benefits of fewer GPS activations. This brings out an important aspect of RAPS; the performance benefits depend strongly on many factors (human behavior, environmental conditions), and not all components will necessarily provide significant energysavingsunderallconditions. Wehaveleftanexplorationofthistofuturework. Average GPS Activation Interval. Figure 5.20 shows how often GPS was activated (in the Always-On case,GPSwasactivatedalwaysandapositionupdatewasloggedevery20seconds). Thefigureshowsthat RAPS activated GPS every 630.9 seconds on average. Moreover, as expected, we also see progressively smaller intervals as we disable components of RAPS one-by-one: RAPS-B activates GPS every 588.5 seconds, RAPS-BC every 259.5 seconds, and RAPS-BCA every 135.4 seconds. Note that the longer experimentslastedforover24hoursandincludethetimewhentheuserwassleeping. 145 Figure5.21: Estimatedaveragepowerconsumptionforeachofthetestedschemes ExpectedAveragePowerConsumption. The average GPS activation interval is an important indication of energy consumption, but a more complete picture emerges when we consider the breakdown of power consumption across other hardware components (Bluetooth and accelerometer). Figure 5.21 shows the estimated average power consumption for each of the tested schemes. This figure was generated by av- eraging out the power usage of all components over the average GPS activation interval in Figure 5.20. For Always-On case, it is the power consumption of the GPS itself. From the figure we see that, as ex- pected,GPSconsumesthemostpower. Bycontrast,Bluetoothandtheaccelerometercontributerelatively small portions to the overall power consumption. This validates our strategy of adapting GPS activation intervals,atthecostofalittleadditionalenergyexpenditurebyusingothersensors. Distance Between GPS Position Updates. The goal of RAPS is to trade-off position uncertainty for reduced energy use. Thus, RAPS activates GPS when it estimates the position uncertainty to be near the 100m limit. Hence, ideally, the distance between two consecutive GPS readings should be exactly 100 meters. Of course, this is not a hard limit and can be exceeded due to various reasons: RAPS uncertainty estimates may not be precise; after GPS is activated, the user might have moved some distance before a fix is obtained; a GPS activation may fail, because GPS is unavailable at the user’s new location. Thus, in practice, we expect that 100m bound to hold only in a statistical sense. Figure 5.22 shows the median distancebetweentwoconsecutiveGPSpositionreadingsforeachofthetestedschemes. Ingeneral,RAPS, RAPS-B and RAPS-BC all have median distances of around 80 to 110 meters, which is an encouraging 146 Figure 5.22: Median distance between two consecutive GPS position updates for each of the tested schemes Avg.GPSInterval Avg.Uncertainty(Dev.) SuccessRatio Avg.Power RAPS 465.1sec 85.8m(69.2m) 72.2% 0.064W Periodic(T=180) 180.0sec 61.9m(84.6m) 72.3% 0.123W Periodic(T=270) 270.0sec 84.1m(88.6m) 69.4% 0.082W Table5.2: ComparisonofThe RAPS AgainstPeriodicGPSwithFixedDuty-Cycle result. However,RAPS-BCAhasalowermediandistancethanotherRAPSvariantsbecauseitfrequently over-estimated the uncertainty, without being able to detect non-movement of the stationary user, and turnedontheGPS.Withoutanaccelerometer, RAPS-BCAusesthehistoricalaverageofthevelocityeven whenauserhasbeenstationary,andthisaccountsfortheoverestimate. 5.4.2 ComparingRAPS toPeriodicGPSActivation In this subsection, we investigate how RAPS compares with periodic GPS activations. To conduct this experiment, we used two phones: one phone ran RAPS with all of its components enabled, and another phone was programmed to collect a GPS reading every 5 seconds. The experiment began with no prior space-time history or blacklist information (an adversarial setting for RAPS), and ran for approximately 8 hours and 2 minutes. The methodology for this experiment was otherwise identical to that discussed in Section5.4.1. In this experiment, RAPS achieved an average GPS activation interval of 465.1 seconds with average position uncertainty of 85.5 meters and a success ratio of 72.2%. Position uncertainty is defined as the distancebetweenthetwoGPSpositions,andsuccessratioisthefractionoftimesthatthedistancebetween 147 Figure 5.23: Average position uncertainty of periodic GPS from experiment as a function of duty-cycling interval Figure5.24: SuccessratioofperiodicGPSfromexperimentasafunctionofduty-cyclinginterval twoGPSreadingswaswithin100meters(ourtargetuncertaintybound). TocomparethistoperiodicGPS with various intervals, we used the log of GPS readings collected every 5 seconds and simulated the differentintervalsbysub-samplingattheappropriatefrequency. Figures 5.23 and 5.24 depict the average position uncertainty and the success ratio of periodic GPS, respectively,asafunctionoftheperiodicity. Usingthesetwometrics,wefindtheperiodicitythatmatches the performance achieved by RAPS. To have comparable average uncertainty as RAPS, periodic GPS duty-cycling requires its period to be around 270 seconds as indicated by arrows in Figure 5.23. For comparable success ratio, periodic GPS requires a period of 180 seconds, as shown in Figure 5.24. We compare RAPS againstthesetwobenchmarks. Table 5.2 summarizes the result. In this table, the average GPS interval is the time between GPS activations,regardlessofwhethertheyresultedinasuccessfulpositionfixornot. Theaveragepoweristhe estimated power usage for each case, which includes the power consumed by GPS and the accelerometer 148 (when enabled), averaged over the average GPS time interval. The average uncertainty is the average distancebetweenthetwoconsecutivepositionupdates. Thetablealsoshowsthedeviationofthisdistance from the 100m uncertainty tolerance target. Although the average location uncertainty and its deviation seemlarge,thelargedeviationscanbeattributedtoGPSunavailability,andtheresultsshowthat RAPS’s deviationiscomparabletothatofperiodicGPS. To achieve a comparable success ratio, periodic GPS consumes 1.92 times the power used by RAPS, whiletoachievecomparableaverageuncertainty,ituses1.28timestheenergyusedbyRAPS.Togetsome insightintothesenumbers,letusconsiderascenariowherethesepositioningsystemsareusedonanN95 smartphone with 1200mAh batteries without any other service running. Then, the battery will last for 35 hours with RAPS whereas it will last only for 23.8 and 30.8 hours for periodic GPS with intervals 180 and270secondsrespectively. Thisresultclearlyshowstheenergysavingbenefitsof RAPS overperiodic GPSschemeswithfixedperiod. 5.4.3 IntegrationwithaWiFiPositioningSystem RAPS has been designed to work with GPS in mind. However, all the techniques used in RAPS are oblivioustoGPS,so RAPS canbeusedatopanotherunderlyingpositioningsystemaslongasitprovides reasonably accurate positions. To validate this, we have implemented and tested a WPS [115] version of RAPS,namely RAPS-WPS. WPS is a WiFi-based positioning system from Skyhook Wireless [115]. It determines location based on Skyhook’s database of known Wi-Fi access points. The key advantage of WPS is that it can provide position information in urban areas and indoors given that a database exists for those areas. However, since it requires detection of beacons from 3 or more known WiFi APs, it does not work well when movingfast(i.e.driving),norinplaceswhereWiFiAPsaresparse. Also,thepowerconsumptionofWPS is comparable to GPS because of the cost of WLAN scanning and of communicating with the Skyhook databaseserver,asweshowbelow. Finally,itisgenerallyknownthatWPSprovideslessaccurateposition thanGPSatoutdoorlocations,whichagreeswithourexperiments(Figure5.1). 149 Figure5.25: PowerconsumptionofWPSonN95phone Avg.Positioning Avg.Power Avg.Uncertainty(Dev.) Interval RAPS GPS 465.1sec 0.064W 85.8m(69.2m) RAPS WPS 387.3sec 0.035W 122.9m(108.1m) Table5.3: ComparisonofThe RAPS withGPSandWPS. Figure 5.25 plots the power usage on the phone when WPS positioning was requested three times with 30 seconds interval. It shows that a single WPS positioning request, which involves scanning for visible WiFi APs and communicating with the database server, consumes around 1.05 Watt on average for a duration of approximately 6 seconds per request. Using this number, we can estimate the average power usedby RAPS whenWPSisusedastheunderlying positioningsystem. Table5.3summarizesthe result along with the original RAPS for comparison. It shows that RAPS-WPS uses lower power, but has higher average uncertainty. However, higher average uncertainty is not due to the fact that RAPS- WPSactivatedWPSonfeweroccasions, butbecauseWPSisinherentlylessaccurate; infact,theaverage positioning interval wassmaller for RAPS-WPS,which means that itwas activated more frequently. The estimatedaveragepowerusageof RAPS-WPSislowerthanthatofGPSbecauseWiFiscanningisfaster, soconsumeslessenergy. Tosummarize,RAPScanbeusedwithpositioningsystemsotherthanGPS,suchasWPS.Itconsumes less energy when used with WPS because it can obtain a position fix faster, but its accuracy is lower than whenusingGPSbecauseWPSisinherentlymoreinaccurate. 150 Figure5.26: Assisted-GPSvs. GPS:Positionerrorcomparison 5.4.4 AreGPSerrorsPervasive? InFigure5.4ofSection5.2,weshowedtheinaccuracyofGPSbycollectingpositionreadingsfromseveral knownlocations. Inthissection,wevalidatethisobservationbyansweringtwoquestions: • DoesAssisted-GPSresultinlowererror? • Aretheresignificantdifferencesintheerrorcharacteristicsacrossdifferenthandsetplatforms? Atleastfromtheexperimentswehaveconducted,theanswertoboththesequestionsisnegative,suggest- ingthattheinstanceofrelativelyhighGPSerrorisafunctionoftheenvironment,notoftheplatform. Assisted GPS. Figure 5.26 compares the position inaccuracy results for GPS and Assisted-GPS, on both N95 and G1 phones, at 35 different known locations. As the figure shows, we have found negligible dif- ference in position accuracy between A-GPS and GPS for either platform. This result is consistent with our personal experience using N95 phones where Assisted-GPS is superior to GPS only in the Time-To- First-Fix(TTFF)andnotinthepositioningaccuracy. AlthoughthetermA-GPSisbroadlyusedtoinclude variousformsofassistance(whichcouldpossiblyincludesophisticatedpositionestimationtechniques),it usually refers to an enhanced version of GPS that retrieves almanac and ephemeris data over a data con- nection(e.g.GPRSor3G)forafasterfix. Atleastforthephonesthatwehaveusedinourmeasurements, thisdoesnotimprovepositioningaccuracy. 151 Figure5.27: Comparisonofpositionerrorforfourdifferenttypesofmobilesmartphones Different Platforms. Figure 5.27 compares the position (in)accuracy results for four different handset platforms: Android G1, Nokia N95, MotoDriod, and WinMobile HTC. As the figure shows, there isn’t a qualitative difference in position accuracy between different types of mobile phone except for the G1 phone; other three phones had similar performance. The Android G1 phone did often report slightly higher distance errors than other phones especially when there was relatively less clear view to the sky. However,webelievethatthisfactdoesnotsignificantlyaffectourdesignnortheresultof RAPS. 5.4.5 SummaryandFutureWork The results we have presented so far suggest that significant energy-saving gains can be obtained with a collection of techniques that permit delayed GPS activation. Of course, much work remains to be done before RAPS can become truly practical. Our parameter settings (for example, the accelerometer duty- cycling) can be optimized. Although we believe the system has the right incentives for the adoption of Bluetooth synchronization, privacy and security considerations need to be considered. Finally, we intend to perform a more careful evaluation of the parameter space, which is exceedingly large: performance critically depends on user consistency and phone handling behavior, on environmental conditions, GPS visibility,celltowerplacementdensity,andsoforth. Asanextstep,wearealsoinvestigatingacellid-aidedpositioningsystemcalledCAPS.CAPSisbased on the observation that users have consistency in their everyday routes, and the cellid transition point that 152 the user experiences can often uniquely represent the current user position. CAPS uses cellid sequence matchingtoestimatecurrentpositionbasedonthehistoryofhcellid,GPSlocationsisequencestoprovide ‘reasonably’ accurate position information while avoiding turning on GPS as much as possible to reduce itsenergyexpenditure. 5.5 Conclusions In this chapter, we presented RAPS, rate-adaptive positioning system for smartphone applications. It is based on the observation that GPS is generally less accurate in urban areas, so it suffices to turn on GPS only as often as necessary to achieve this accuracy. RAPS uses a collection of techniques that could be implemented on current generation of smartphones to cleverly determine when to turn on GPS. We have evaluated RAPS through real-world experiments using a prototype implementation on a modern smartphone and show that it increases lifetime by more than a factor of 3.8 relative to the case when GPS isalwayson. 153 Chapter6 Conclusions In this dissertation we have explored how rate-adaptation in networks of wireless sensors can be used to buildsensingsystemsthatadapttothenetworkandenvironmentdynamics. RCRT is a rate-adaptive reliable transport protocol designed on the Tenet architecture that respects theresourceconstraintsoftheembeddedsensors. RCRT placesitscongestioncontrolfunctionalityatthe sink, whose perspective into the network enables better aggregate control of traffic, and affords flexibility in rate allocation. It supports multiple concurrent applications, and is robust to network dynamics. We have shown that RCRT’s rates are significantly higher than that of the state of the art in sensor network congestioncontrol. RAPSisarate-adaptivepositioningsystemforsmartphoneapplications. Itisbasedontheobservation that GPS is generally less accurate in urban areas, so it suffices to turn on GPS only as often as necessary toachievethisaccuracy. RAPS usesacollectionoftechniquestocleverlydeterminewhetherandwhento turn on GPS. We have shown that RAPS increases battery lifetime significantly relative to the case when GPSisalwayson. 154 References [1] Peir: Personalenvironmentalimpactreport. http://peir.cens.ucla.edu/. [2] Placelab: Aprivacy-observantlocationsystem. http://www.placelab.org/. [3] Lauri Aalto, Nicklas G¨ othlin, Jani Korhonen, and Timo Ojala. Bluetooth and wap push based location-awaremobileadvertisingsystem. InProceedingsof2ndInternationalConferenceonMo- bileSystems,Applications,andServices(MobiSys’04),2004. [4] Fehmi Ben Abdesslem, Andrew Philips, and Tristan Henderson. Less is more: energy-efficient mobilesnesingwithsenseless. InMobiHeld’09: Proceedingsofthe1stACMSIGCOMMWorkshop onNetworking,Systems,andApplicationsforMobileHandhelds.ACM,2009. [5] Dan Aguayo, John Bicket, Sanjit Biswas, Douglas De Couto, and Robert Morris. The mit roofnet project. http://pdos.csail.mit.edu/roofnet/. [6] A.M.Ali,K.Yao,T.Collier,C.Taylor,D.Blumstein,andL.Girod. Anempiricalstudyofcollab- orativeacousticsourcelocalization. InProc.oftheIPSN/SPOTS,Boston,MA,2007. [7] Anish Arora, Rajiv Ramnath, Emre Ertin, Prasun Sinha, Sandip Bapat, Vinayak Naik, Vinod Ku- lathumani, Hongwei Zhang, Hui Cao, Mukundan Sridharan, Santosh Kumar, Nick Seddon, Chris Anderson, Ted Herman, Nishank Trivedi, Chen Zhang, Mikhail Nesterenko, Romil Shah, Sandeep Kulkarni,MaheshAramugam,LiminWang,MohamedGouda,Young-riChoi,DavidCuller,Prabal Dutta, Cory Sharp, Gilman Tolle, Mike Grimmer, Bill Ferriera, and Ken Parker. ExScal: Elements of an extreme scale wireless sensor network. In Proceedings of 11th IEEE International Confer- enceonReal-TimeandEmbeddedComputingSystemsandApplications(RTCSA’05),HongKong, August2005. [8] Hari Balakrishnan, Hariharan S. Rahul, and Srinivasan Seshan. An integrated congestion manage- mentarchitectureforinternethosts. SIGCOMMComput.Commun.Rev.,29(4):175–187,1999. [9] Fang Bian, Sumit Rangwala, and Ramesh Govindan. Quasi-static Centralized Rate Allocation for Sensor Networks. In Proceedings of IEEE Conference on Sensor, Mesh and Ad Hoc Communica- tionsandNetworks(SECON),SanDiego,CA,June2007. [10] R. A. Brooks. Solving the find-path problem by good representation of free space. IEEE Transac- tionsonSystems,ManandCybernetics,13(3):190–197,March/April1983. [11] Nirupama Bulusu, John Heidemann, and Deborah Estrin. GPS-less low cost outdoor localization forverysmalldevices. IEEEPersonalCommunications,7(5):28–34,October2000. [12] J. Caffrey, R. Govindan, E. Johnson, B. Krishnamachari, S. Masri, G. Sukhatme, K. Chintalapudi, K. Dantu, S. Rangwala, A. Sridharan, N. Xu, and M. Zuniga. Networked Sensing for Struc- tural Health Monitoring. In Proceedings of the 4th International Workshop on Structural Control, ColumbiaUniversity,NY,June2004. 155 [13] Krishna Chintalapudi, Jeongyeup Paek, Omprakash Gnawali, Tat Fu, Karthik Dantu, John Caffrey, Ramesh Govindan, and Erik Johnson. Structural Damage Detection and Localization Using Net- SHM. InProceedingsofIPSN/SPOTS’06,Nashville,TN,April2006. [14] D.-M.ChiuandR.Jain. Analysisoftheincreaseanddecreasealgorithmsforcongestionavoidance incomputernetworks. Comput.Netw.ISDNSyst.,17(1):1–14,1989. [15] David Chu, Lucian Popa, Arsalan Tavakoli, Joseph M. Hellerstein, Philip Levis, Scott Shenker, and Ion Stoica. The Design and Implementation of a Declarative Sensor Network System. In Proceedings of The 5th ACM International Conference on Embedded Networked Sensor Systems (SenSys’07),Sydney,Australia,November2007. [16] T.ClausenandP.Jacquet. Optimizedlinkstateroutingprotocol(olsr). 2003. [17] Ionut Constandache, Romit Roy Choudhury, and Injong Rhee. Towards mobile phone localization withoutwar-driving. InProceedingsofIEEEInfocom,2010. [18] Ionut Constandache, Shravan Gaonkar, Matt Sayler, Romit Roy Choudhury, and Landon Cox. En- loc: energy-efficientlocalizationformobilephones. InINFOCOMMiniconference’09,2009. [19] David Culler, Prabal Dutta, Cheng Tien Ee, Rodrigo Fonseca, Jonathan Hui, Philip Levis, Joseph Polastre, Scott Shenker, Ion Stoica, Gilman Tolle, and Jerry Zhao. Towards a Sensor Network Architecture: Lowering the Waistline. In Proceedings of 10th Hot Topics in Operating Systems Symposium(HotOS-X),pages139–144,SantaFe,NewMexico,June2005. [20] Nico Deblauwe and Georg Treu. Hybrid gps and gsm localization - energy-efficient detection of spatial triggers. In WPNC’08: Proceedings of the 5th Workshop on Positioning, Navigation and Communication,2008. [21] Adam Dunkels, Fredrik ¨ Osterlind, and Zhitao He. An adaptive communication architecture for wireless sensor networks. In Proceedings of The 5th ACM International Conference on Embedded NetworkedSensorSystems(SenSys’07),Sydney,Australia,November2007. [22] LarsEggert,JohnHeidemann,andJoeTouch. Effectsofensemble-tcp. ACMComputerCommuni- cationReview,30(1):15–29,January2000. [23] S. B. Eisenman, E. Miluzzo, N. D. Lane, R. A. Peterson, G-S. Ahn, and A. T. Campbell. The bikenet mobile sensing system for cyclist experience mapping. In Proceedings of The 5th ACM InternationalConferenceonEmbeddedNetworkedSensorSystems(SenSys’07),Sydney,Australia, November2007. [24] Shane B. Eisenman, Nicholas D. Lane, Emiliano Miluzzo, Ronald A. Peterson, Gahng-Seop Ahn, and Andrew T. Campbell. Metrosense project: people-centric sensing at scale. In First Workshop onWorld-Sensor-Web: MobileDeviceCentricSensoryNetworksandApplicationsWSW06,SenSys 06,2006. [25] Jakob Eriksson, Lewis Girod, Bret Hull, Ryan Newton, Samuel Madden, and Hari Balakrishnan. The pothole patrol: Using a mobile sensor network for road surface monitoring. In Proceedings of 6thInternationalConferenceonMobileSystems,Applications,andServices(MobiSys’08),2008. [26] Deborah Estrin, Ramesh Govindan, John Heidemann, and Satish Kumar. Next century challenges: Scalable coordination in sensor networks. In Proceedings of 5th (MobiCom’99), pages 263–270, Seattle,Washington,August1999. [27] TobiasFarrell,ReynoldCheng,andKurtRothermel. Energy-efficientmonitoringofmobileobjects with uncertainty-aware tolerances. In Proceedings of 11th International Database Engineering & ApplicationsSymposium(IDEAS’07),2007. 156 [28] S.Floyd. Congestioncontrolprinciples. RFC2914,2000. [29] SallyFloyd, MarkHandley, JitendraPadhye, andJorgWidmer. Equation-based congestioncontrol for unicast applications. In Proceedings of ACM SIGCOMM Conference, Stockholm, Sweden, August2000. [30] Sally Floyd and Van Jacobson. Random early detection gateways for congestion avoidance. IEEE/ ACMTransactionsonNetworking,1(4):397–413,1993. [31] Sally Floyd, Van Jacobson, Ching-Gung Liu, Steven McCanne, and Lixia Zhang. A reliable mul- ticast framework for light-weight sessions and application level framing. IEEE/ACM Transactions onNetworking,5(6):784–803,1997. [32] JonFroehlich,MikeY.Chen,SunnyConsolvo,BeverlyHarrison,andJamesA.Landay. Myexperi- ence: Asystemforinsitutracingandcapturingofuserfeedbackonmobilephones. InProceedings of5thInternationalConferenceonMobileSystems,Applications,andServices(MobiSys’07),2007. [33] Shravan Gaonkar, Jack Li, Romit Roy Choudhury, Landon Cox, and Al Schmidt. Micro-blog: sharingandqueryingcontentthroughmobilephonesandsocialparticipation. InProceedingsof6th InternationalConferenceonMobileSystems,Applications,andServices(MobiSys’08),2008. [34] DavidGay,PhilipLevis,RobertvonBehren,MattWelsh,EricBrewer,andDavidCuller. ThenesC language: Aholisticapproachtonetworkedembeddedsystems. InProceedings of ACM SIGPLAN 2003ConferenceonProgrammingLanguageDesignandImplementation(PLDI),pages1–11,San Diego,California,June2003. [35] Omprakash Gnawali, Rodrigo Fonseca, Kyle Jamieson, David Moss, and Philip Levis. Collection Tree Protocol. In Proceedings of The 7th ACM International Conference on Embedded Networked SensorSystems(SenSys’09),November2009. [36] Omprakash Gnawali, Jongkeun Na, and Ramesh Govindan. Application-Informed Radio Duty- Cycling in a Re-Taskable Multi-User Sensing System. In Proceedings of the 8th ACM/IEEE In- ternational Conference on Information Processing in Sensor Networks (IPSN’09), San Francisco, California,April2009. [37] Ben Greenstein, Eddie Kohler, and Deborah Estrin. A sensor network application construction kit (SNACK). In Proceedings of The 2nd ACM International Conference on Embedded Networked SensorSystems(SenSys’04),pages69–80,Baltimore,Maryland,November2004. [38] Ben Greenstein, Christopher Mar, Alex Pesterev, Shahin Farshchi, Eddie Kohler, Jack Judy, and Deborah Estrin. Capturing high-frequency phenomena using a bandwidth-limited sensor network. InProceedingsofThe4thACMInternationalConferenceonEmbeddedNetworkedSensorSystems (SenSys’06),Boulder,Colorado,November2006. [39] P.R. Gupta, P.; Kumar. The capacity of wireless networks. IEEE Transactions on Information Theory,46(2):388–404,March2000. [40] RichardGuy,BenGreenstein,JohnHicks,RahulKapur,NithyaRamanathan,TomSchoellhammer, Thanos Stathopoulos, Karen Weeks, Kevin Chang, Lew Girod, and Deborah Estrin. Experiences withtheExtensibleSensingSystemESS. TechnicalReport61,CENS,March292006. [41] Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler, and Mani Srivastava. A dynamic operat- ing system for sensor nodes. In Proceedings of 3rd International Conference on Mobile Systems, Applications,andServices(MobiSys’05),Seattle,Washington,June2005. 157 [42] TianHe,J.A.Stankovic,R.Stoleru,YuGu,andYafengWu. Essentia: Architectingwirelesssensor networksasymmetrically. InINFOCOM2008.The27thConferenceonComputerCommunications. IEEE,April2008. [43] John Hicks, Jeongyeup Paek, Sharon Coe, Ramesh Govindan, and Deborah Estrin. An Easily De- ployable Wireless Imaging System. In Proceedings of ImageSense08: Workshop on Applications, Systems,andAlgorithmsforImageSensing,Raleigh,NC,November2008. [44] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for network sensors. In Proceedings of 9th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-IX), pages 93–104, Cambridge, Mas- sachusetts,November2000. [45] Timothy W. Hnat, Tamim I. Sookoor, Pieter Hooimeijer, Westley Weimer, and Kamin White- house. Macrolab: a vector-based macroprogramming framework for cyber-physical systems. In Proceedings of The 6th ACM International Conference on Embedded Networked Sensor Systems (SenSys’08),November2008. [46] J. Hui and D. Culler. The dynamic behavior of a data dissemination algorithm at scale. In Pro- ceedingsofThe2ndACMInternationalConferenceonEmbeddedNetworkedSensorSystems(Sen- Sys’04),Baltimore,Maryland,November2004. [47] Bret Hull, Kyle Jamieson, and Hari Balakrishnan. Mitigating congestion in wireless sensor net- works. InProceedings ofThe2nd ACMInternational Conference onEmbedded Networked Sensor Systems(SenSys’04),Baltimore,Maryland,November2004. [48] ChalermekIntanagonwiwat,RameshGovindan,andDeborahEstrin. Directeddiffusion: Ascalable and robust communication paradigm for sensor networks. In Proceedings of 6th (MobiCom’00), pages56–67,Boston,Massachusetts,August2000. [49] Chalermek Intanagonwiwat, Ramesh Govindan, Deborah Estrin, John Heidemann, and Fabio Silva. Directed diffusion for wireless sensor networking. ACM/IEEE Transactions on Network- ing,11(1):2–16,February2002. [50] Y.G. Iyer, S. Gandham, and S. Venkatesan. Stcp: a generic transport layer protocol for wireless sensor networks. In Proceedings of International Conference on Computer Communications and Networks,October2005. [51] VanJacobson. Congestionavoidanceandcontrol. InProceedingsofACMSIGCOMMConference, Stanford,CA,August1988. [52] DinaKatabi,MarkHandley,andCharlieRohrs. Congestioncontrolforhighbandwidth-delayprod- uct networks. In SIGCOMM ’02: Proceedings of the 2002 conference on Applications, technolo- gies,architectures,andprotocolsforcomputercommunications,2002. [53] Sukun Kim, Rodrigo Fonseca, Prabal Dutta, Arsalan Tavakoli, David Culler, Philip Levis, Scott Shenker, and Ion Stoica. Flush: A Reliable Bulk Transport Protocol for Multihop Wireless Net- works. In Proceedings of The 5th ACM International Conference on Embedded Networked Sensor Systems(SenSys’07),pages351–365,Sydney,Australia,November2007. [54] Sukun Kim, Shamim Pakzad, David Culler, James Demmel, Gregory Fenves, Steven Glaser, and Martin Turon. Health monitoring of civil infrastructures using wireless sensor networks. In Pro- ceedingsof6thACM/IEEEInternationalConferenceonInformationProcessinginSensorNetworks (IPSN’07),Cambridge,Massachusetts,USA,April2007. 158 [55] MikkelBaunKjaergaard,JakobLangdal,TorbenGodsk,andThomasToftkjaer. Entracked: energy- efficientrobustpositiontrackingformobiledevices. InProceedingsof7thInternationalConference onMobileSystems,Applications,andServices(MobiSys’09),2009. [56] JeongGil Ko, Tia Gao, and Andreas Terzis. Empirical study of a medical sensor application in an urban emergency department. In BodyNets ’09: Proceedings of the Fourth International Con- ference on Body Area Networks. ICST (Institute for Computer Sciences, Social-Informatics and TelecommunicationsEngineering),2009. [57] Teresa Ko, Shaun Ahmadian, John Hicks, Mohammad H. Rahimi, Deborah Estrin, Stefano Soatto, Sharon Coe, and Michael P. Hamilton. Heartbeat of a nest: Using imagers as biological sensors. ACMTransactionsonSensorNetworks,6(3),2010. [58] Nupur Kothari, Ramakrishna Gummadi, Todd Millstein, and Ramesh Govindan. Reliable and effi- cientprogrammingabstractionsforwirelesssensornetworks. InProceedingsofSIGPLANConfer- enceonProgrammingLanguageDesignandImplementation,2007. [59] Venkata A. Kottapalli, Anne S. Kiremidjian, Jerome P. Lynch, Ed Carryer, Thomas W. Kenny, KinchoH.Law,andYingLei. Two-tieredwirelesssensornetworkarchitectureforstructuralhealth monitoring. In Shih-Chi Liu, editor, Proceedings of SPIE 5057—Smart Structures and Materials 2003: Smart Systems and Nondestructive Evaluation for Civil Infrastructures, San Diego, CA, August2003. [60] Martin. H. Krieger, Moo-Ryong Ra, Jeongyeup Paek, Ramesh Govindan, and Jeniffer Evans- Cowley. Urban Tomography. Journal of Urban Technology, 2010. http://tomography. usc.edu/. [61] B.J.KuipersandY.-T.Byun. Arobustqualitativemethodforspatiallearninginunknownenviron- ments. In Proceedings of 7th National Conference on Artificial Intelligence (AAAI-88), Saint Paul, Minnesota,July1988. [62] Koen Langendoen, Aline Baggio, and O. Visser. Murphy loves potatoes: experiences from a pilot sensornetworkdeploymentinprecisionagriculture. InIPDPS,2006. [63] P.Levis,D.Gay,andD.Culler. Activesensornetworks. InProceedingsof2ndUSENIXSymposium on Networked Systems Design and Implementation (NSDI’05), Boston, Massachusetts, May 2005. USENIX. [64] Philip Levis and David Culler. Mat´ e: A tiny virtual machine for sensor networks. In Proceed- ings of 10th International Conference on Architectural Support for Programming Languages and OperatingSystems(ASPLOS-X),pages85–95,SanJose,California,October2002. [65] Philip Levis, Neil Patel, David Culler, and Scott Shenker. Trickle: A self-regulating algorithm for codepropagationandmaintenanceinwirelesssensornetworks. InProceedingsof1stUSENIXSym- posium on Networked Systems Design and Implementation (NSDI’04), San Francisco, California, March2004.USENIX. [66] Ming Li, Devesh Agrawal, Deepak Ganesan, and Arun Venkataramani. Block-switched networks: A new paradigm for wireless transport. In Proceedings of 6th USENIX Symposium on Networked SystemsDesignandImplementation(NSDI’09).USENIX,2009. [67] Kaisen Lin, Aman Kansal, Dimitrios Lymberopoulos, and Feng Zhao. Energy-accuracy aware localizationformobiledevices. InProceedingsof8thInternationalConferenceonMobileSystems, Applications,andServices(MobiSys’10),June2010. 159 [68] B.Liu,Z.Liu,andD.Towsley. Onthecapacityofhybridwirelessnetworks. InProceedingsof22nd Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM’03), SanFrancisco,California,March2003. [69] Jie Liu, Elaine Cheong, and Feng Zhao. Semantics-based optimization across uncoordinated tasks in networked embedded systems. In Proceedings of 5th ACM Conference on Embedded Software (EMSOFT2005),September2005. [70] JieLiuandFengZhao. Towardssemanticservicesforsensor-richinformationsystems. InProceed- ings of 2nd International Conference on Broadband Networks (BROADNETS 2005), pages 44–51, Boston,Massachusetts,October2005. [71] Samuel Madden, MichaelJ.Franklin, JosephM.Hellerstein, andWeiHong. TAG:ATinyAGgre- gationserviceforad-hocsensornetworks. InProceedingsof5thUSENIXSymposiumonOperating SystemsDesignandImplementation(OSDI’02),Boston,Massachusetts,December2002. [72] Alan Mainwaring, Joseph Polastre, Robert Szewczyk, David Culler, and John Anderson. Wireless sensor networks for habitat monitoring. In Proceedings of 1st ACM International Workshop on WirelessSensorNetworksandApplications(WSNA),Atlanta,Georgia,September2002.ACM. [73] MiklosMaroti,BranislavKusy,GyulaSimon,andAkosLedeczi. TheFloodingTimeSynchroniza- tion Protocol. In Proceedings of The 2nd ACM International Conference on Embedded Networked SensorSystems(SenSys’04),Baltimore,Maryland,November2004. [74] Vivek P. Mhatre, Catherine Rosenberg, Daniel Kofman, Ravi Mazumdar, and Ness Shroff. A min- imum cost heterogeneous sensor network with a lifetime constraint. IEEE Transactions on Mobile Computing,4(1):4–15,January/February2005. [75] DavidMizell. Usinggravitytoestimateaccelerometerorientation. InISWC’03: Proceedingsofthe 7thInternationalSymposiumonWearableComputing,2003. [76] Prashanth Mohan, Venkata N. Padmanabhan, and Ramachandran Ramjee. Nericell: rich moni- toring of road and traffic conditions using mobile smartphones. In Proceedings of The 6th ACM InternationalConferenceonEmbeddedNetworkedSensorSystems(SenSys’08),November2008. [77] Mehul Motani, Vikram Srinivasan, and Pavan S. Nuggehalli. Peoplenet: Engineering a wireless virtualsocialnetwork. InProceedingsof11th(MobiCom’05),2005. [78] Min Mun, Sasank Reddy, Katie Shilton, Nathan Yau, Jeff Burke, Deborah Estrin, Mark Hansen, Eric Howard, Ruth West, and P´ eter Boda. Peir, the personal environmental impact report, as a platformforparticipatorysensingsystemsresearch. InProceedingsof7thInternationalConference onMobileSystems,Applications,andServices(MobiSys’09),pages55–68,2009. [79] Razvan Musaloiu-E., Chieh-Jan Mike Liang, and Andreas Terzis. Koala: Ultra-low power data retrieval in wireless sensor networks. In Proceedings of 7th ACM/IEEE International Conference onInformationProcessinginSensorNetworks(IPSN’08),St.Louis,Missouri,April2008. [80] Ryan Newton, Greg Morrisett, and Matt Welsh. The regiment macroprogramming system. In Pro- ceedingsof6thACM/IEEEInternationalConferenceonInformationProcessinginSensorNetworks (IPSN’07),Cambridge,Massachusetts,USA,April2007. [81] Anthony J. Nicholson and Brian D. Noble. Breadcrumbs: Forecasting mobile connectivity. In Proceedingsof14th(MobiCom’08),2008. 160 [82] Jeongyeup Paek, Krishna Chintalapudi, John Cafferey, Ramesh Govindan, and Sami Masri. A Wireless Sensor Network For Structural Health Monitoring: Performance and Experience. In In ProceedingsofTheSecondIEEEWorkshoponEmbeddedNetworkedSensors,(EmNetS-II),Sydney, Australia,May2005. [83] Jeongyeup Paek and Ramesh Govindan. RCRT: Rate-Controlled Reliable Transport for Wireless Sensor Networks. In Proceedings of The 5th ACM International Conference on Embedded Net- workedSensorSystems(SenSys’07),Sydney,Australia,November2007. [84] JeongyeupPaek,BenGreenstein,OmprakashGnawali,Ki-YoungJang,AugustJoki,MarcosVieira, John Hicks, Deborah Estrin, Ramesh Govindan, and Eddie Kohler. The Tenet Architecture for TieredSensorNetworks. ACMTransactionsonSensorNetworks,6(4),2010. [85] Jeongyeup Paek, Omprakash Gnawali Ki-Young Jang, Daniel Nishimura, Ramesh Govindan, John Caffrey,MazenWahbeh,andSamiMasri. AProgrammableWirelessSensingSystemforStructural Monitoring. In4thWorldConferenceonStructuralControlandMonitoring(4WCSCM),SanDiego, CA,July2006. [86] Jeongyeup Paek, Joongheon Kim, and Ramesh Govindan. Energy-Efficient Rate-Adaptive GPS- based Positioning for Smartphones. In Proceedings of 8th International Conference on Mobile Systems,Applications,andServices(MobiSys’10),June2010. [87] Bradford W. Parkinson and James J. Spilker. Global Positioning System: Theory and Practice, volumeI. AmericanInstituteofAeronauticsandAstronautics,Inc.,Washington,DC,1996. [88] Joseph Polastre, Jonathan Hui, Philip Levis, Jerry Zhao, David Culler, Scott Shenker, and Ion Sto- ica. A unifying link abstraction for wireless sensor networks. In Proceedings of The 3th ACM International Conference on Embedded Networked Sensor Systems (SenSys’05), pages 76–89, San Diego,California,November2005. [89] Joseph Polastre, Robert Szewczyk, and David Culler. Telos: Enabling ultra-low power wireless research. InProceedingsof4thACM/IEEEInternationalConferenceonInformationProcessingin SensorNetworks(IPSN’05),SPOTStrack,April2005. [90] MohammadRahimi,RickBaer,ObimdinachiI.Iroezi,JuanC.Garcia,JayWarrior,DeborahEstrin, andManiSrivastava. Cyclops: Insituimagesensingandinterpretationinwirelesssensornetworks. InProceedingsofThe3thACMInternationalConferenceonEmbeddedNetworkedSensorSystems (SenSys’05),pages192–204,SanDiego,California,November2005. [91] K.K.Ramakrishnan andR.Jain. Abinaryfeedback schemeforcongestion avoidance incomputer networks with connectionless network layer. ACM/IEEE Transactions on Networking, 8(2):158– 181,1990. [92] Sumit Rangwala, Ramakrishna Gummadi, Ramesh Govindan, and Konstantinos Psounis. Interference-Aware Fair Rate Control in Wireless Sensor Networks. In Proceedings of ACM SIG- COMMSymposiumonNetworkArchitecturesandProtocols,Pisa,Italy,September2006. [93] Sylvia Ratnasamy, Brad Karp, Li Yin, Fang Yu, Deborah Estrin, Ramesh Govindan, and Scott Shenker. GHT:Ageographichashtablefordata-centricstorage. InProceedings of1stACMInter- national Workshop on Wireless Sensor Networks and Applications (WSNA), pages 78–87, Atlanta, Georgia,September2002.ACM. [94] S. Rhee, D. Seetharam, and S. Liu. Techniques for minimizing power consumption in low data- rate wireless sensor networks. In Proceedings of IEEE Wireless Communications and Networking Conference(WCNC2004),Atlanta,Georgia,March2004. 161 [95] J. H. Saltzer, D. P. Reed, and D. D. Clark. End-to-end arguments in system design. ACM Transac- tionsonComputerSystems,2(4):277,November1984. [96] Yogesh Sankarasubramaniam, Ozgur B. Akan, and Ian F. Akyildiz. Esrt: Event-to-sink reliable transport in wireless sensor networks. In Proceedings of 4th ACM international symposium on Mobile ad hoc networking & computing (MobiHoc ‘03), pages 177–188, Annapolis, Maryland, USA,June2003.ACM. [97] Cory Sharp, Shawn Schaffert, Alec Woo, Naveen Sastry, Chris Karlof, Shankar Sastry, and David Culler. Designandimplementationofasensornetworksystemforvehicletrackingandautonomous interception. In Proceedings of 2nd European Workshop on Wireless Sensor Networks (EWSN), Sydney,Australia,January2005. [98] GyulaSimon,Mikl´ osMar´ oti, ´ AkosL´ edeczi,Gy¨ orgyBalogh,BranislavKusy,Andr´ asN´ adas,G´ abor Pap,J´ anosSallai,andKenFrampton. Sensornetwork-basedcountersnipersystem. InProceedings of The 2nd ACM International Conference on Embedded Networked Sensor Systems (SenSys’04), Baltimore,Maryland,November2004. [99] A.W. Smyth, J.S. Pei, and S.F. Masri. System identification of the vincent thomas bridge based usingearthquakesrecords. EarthquakeEngineeringandStructuralDynamics,33,2003. [100] Timorthy Sohn, Alex Varshavsky, Anthony LaMarca, Mike Y. Chen, Tanzeem Choudhury, Ian Smith, Sunny Consolvo, Jeffery Hightower, William G. Griswold, and Eyal de Lara. Mobility detection using everyday gsm traces. In UbiComp’06: Proceedings of the 8th International Con- ferenceonUbiquitousComputing,2006. [101] Timothy Sohn, Kevin A. Li, Gunny Lee, Ian Smith, James Scott, and William G. Griswold. Place- its: A study of location-based reminders on mobile phones. In UbiComp’05: Proceedings of the 7thInternationalConferenceonUbiquitousComputing,2005. [102] Avinash Sridharan and Bhaskar Krishnamachari. Explicit and preciseratecontrol forwirelesssen- sor networks. In Proceedings of The 7th ACM International Conference on Embedded Networked SensorSystems(SenSys’09),November2009. [103] F. Stann and J. Heidemann. Rmst: Reliable data transport in sensor networks. In Proceedings of 1st IEEE Workshop on Sensor Network Protocols and Applications (SNPA), Istanbul, Turkey, May 2003. [104] Thanos Stathopoulos, Lewis Girod, John Heidemann, and Deborah Estrin. Mote herding for tiered wirelesssensornetworks. TechnicalReport58,CENS,December72005. [105] ThanosStathopoulos,JohnHeidemann,andDeborahEstrin. Aremotecodeupdatemechanismfor wirelesssensornetworks. TechnicalReport30,CENS,November262003. [106] Robert Szewczyk, Alan Mainwaring, Joseph Polastre, John Anderson, and David Culler. An anal- ysis of a large scale habitat monitoring application. In Proceedings of The 2nd ACM Interna- tionalConferenceonEmbeddedNetworkedSensorSystems(SenSys’04),pages214–226,Baltimore, Maryland,November2004. [107] David L. Tennenhouse and David J. Wetherall. Towards an active network architecture. Computer CommunicationReview,26:5–18,1996. [108] Gilman Tolle, Joseph Polastre, Robert Szewczyk, David E. Culler, Neil Turner, Kevin Tu, Stephen Burgess, Todd Dawson, Philip Buonadonna, David Gay, and Wei Hong. A macroscope in the redwoods. In Proceedings of The 3th ACM International Conference on Embedded Networked SensorSystems(SenSys’05),SanDiego,California,November2005. 162 [109] USC/ISI. Transmissioncontrolprotocol. RFC793,1981. [110] Alex Varshavsky, Denis Pankratov, John Krumm, and Eyal de Lara. Calibree: Calibration-free localization using relative distance estimations. In Proceedings of 7th International Conference on MobileSystems,Applications,andServices(MobiSys’09),2009. [111] C. Y. Wan, A. T. Campbell, and L. Krishnamurthy. Psfq: A reliable transport protocol for wireless sensor networks. In Proceedings of 1st ACM International Workshop on Wireless Sensor Networks andApplications(WSNA),Atlanta,Georgia,September2002.ACM. [112] Chieh-Yih Wan, Shane B. Eisenman, and Andrew T. Campbell. Coda: Congestion detection and avoidanceinsensornetworks. InProceedingsofThe1stACMInternationalConferenceonEmbed- dedNetworkedSensorSystems(SenSys’03),LosAngeles,California,November2003. [113] YiWang,JialiuLin,MuraliAnnavaram,QuinnA.Jacobson,JasonHong,BhaskarKrishnamachari, andNormanSadeh. Aframeworkofenergyefficientmobilesensingforautomaticuserstaterecog- nition. In Proceedings of 7th International Conference on Mobile Systems, Applications, and Ser- vices(MobiSys’09),2009. [114] Geoff Werner-Allen, Konrad Lorincz, Jeff Johnson, Jonathan Lees, and Matt Welsh. Fidelity and yield in a volcano monitoring sensor network. In OSDI ’06: Proceedings of the 7th symposium on Operatingsystemsdesignandimplementation,2006. [115] SkyhookWireless. http://www.skyhookwireless.com/. [116] A. Woo and D. Culler. Evaluation of efficient link reliability estimators for low-power wireless networks. TechnicalReportCSD-03-1270,UniversityofCalifornia,Berkeley,April2003. [117] N. Xu, S. Rangwala, K. Chintalapudi, D. Ganesan, A. Broad, R. Govindan, and D. Estrin. A WirelessSensorNetworkforStructuralMonitoring. InProceedingsofThe2ndACMInternational ConferenceonEmbeddedNetworkedSensorSystems(SenSys’04),Baltimore,Maryland,November 2004. [118] M. Yarvis, N. Kushalnagar, Harkirat Singh, A. Rangarajan, Y. Liu, and Suresh Singh. Exploiting heterogeneity in sensor networks. In Proceedings of 24th Annual Joint Conference of the IEEE ComputerandCommunicationsSocieties(INFOCOM’05),Miami,Florida,March2005. [119] Chuang-Wen You, Polly Huang, Hao hua Chu, Yi-Chao Chen, Ji-Rung Chiang, and Seng-Yong Lau. Impact of sensor-enhanced mobility prediction on the design of energy-efficient localization. ElsevierAdHocNetworks,6(8):1221–1237,2008. [120] H. Zhang, A. Arora, Y. Choi, and M. Gouda. Reliable bursty convergecast in wireless sensor net- works. In Proceedings of 4th ACM international symposium on Mobile ad hoc networking & com- puting(MobiHoc‘03),Annapolis,Maryland,USA,June2003.ACM. [121] Yu Zheng, Quannan Li, Yukun Chen, Xing Xie, and Wei-Ying Ma. Understanding mobility based on gps data. In UbiComp’08: Proceedings of the 10th International Conference on Ubiquitous Computing,2008. [122] Zhenyun Zhuang, Kyu-Han Kim, and Jatinder Pal Singh. Improving energy efficiency of loca- tion sensing on smartphones. In Proceedings of 8th International Conference on Mobile Systems, Applications,andServices(MobiSys’10),June2010. 163 AppendixA ListofTenetTaskletAPI’s This appendix contains the list of tasklet APIs that are provided by the tasklets in Table 3.1. Unless oth- erwise stated, the default data type returned by a tasklet is a vector of unsigned 16-bit integer(s). All op- erations (e.g., Arith, Logical, etc.) take attribute(s) and/or constants as their arguments. Unless otherwise stated,alloperationsonattribute(s)assumethatanattributeisavectorofunsigned16-bitintegers,andthat twoargumentsofanoperationareeitherofequalsizeorascalar(vectorofsizeoneoraconstant). Tasklet APIsarecase-insensitive. Detailsofthesyntaxandargumentscanbefoundathttp://tenet.usc.edu. TaskingAPI Description Tasklet Count returnavaluewhichisincrementedeverytimeitruns. Count Constant returnaconstant Count Issue issueataskafterdelay(globalorrelative,onceorperiodic) Issue Wait delayataskfor‘period’ Issue Repeat repeatataskperiodicallyevery‘period’ Issue Wait n Repeat waitfor’waitperiod’,andthenrepeatataskperiodicallyevery‘period’ Issue Alarm runthetaskatglobaltime‘starttime’ Issue GlobalRepeat repeatataskevery‘period’afterglobal‘starttime’ Issue Get returnasysteminformation Get NextHop returnroutingnext-hop(parent) Get GlobalTime return32-bittime-synchronizedglobaltime Get LocalTime return32-bitlocaltime Get RfPower returnRFpowerconfiguration Get RfChannel returnRFchannelconfiguration Get Memory Stats returndynamicmemorystatsstructure Get Leds returnthestateoftheLEDs Get Num Tasks returnthenumberoftasksinstalled Get Num Active Tasks returnthenumberofactivetasksrunning Get is Timesync returnwhethertimeissynchronizedornot Get Local Address returnnodeid Get Platform returnplatformtype Get Clock Freq returnclockfrequencyusedforlocaltime Get Master returncurrentnearestroutingmaster Get HopCount returnhopcounttonearestroutingmaster Get Rssi returnRSSIvaluefromroutingnext-hop Get Logical Performthelogicaloperationonattribute(s) Logical And result←attr &arg Logical Or result←attr|arg Logical Not result←arg Logical Bit Performthebitoperationonattribute(s) Bit Bit And result←attr ANDarg Bit Bit Or result←attr ORarg Bit Bit Not result←NOT arg Bit Bit Xor result←attr XORarg Bit Bit Nand result←attr NANDarg Bit Bit Nor result←attr NORarg Bit ShiftLeft result←attr≪ arg Bit ShiftRight result←attr≫ arg Bit 164 Arith performarithmeticoperation Arith Add result←attr+arg Arith Sub result←attr−arg Arith Mult result←attr×arg Arith Div result←attr÷arg Arith Diff result←|attr−arg| Arith Mod result←attr %arg Arith Pow result←attr arg Arith Comparison performcomparisonoperation Comparison LT result←(attr<arg?) Comparison GT result←(attr>arg?) Comparison EQ result←(attr≡arg?) Comparison LEQ result←(attr≤arg?) Comparison GEQ result←(attr≥arg?) Comparison NEQ result←(attr6=arg?) Comparison Count LT result←count(attr<arg?) Comparison Count GT result←count(attr>arg?) Comparison Count EQ result←count(attr≡arg?) Comparison Count LEQ result←count(attr≤arg?) Comparison Count GEQ result←count(attr≥arg?) Comparison Count NEQ result←count(attr6=arg?) Comparison Stats performstatisticaloperation Stats Sum result←sum(attr) Stats Min result←minimum(attr) Stats Max result←maximum(attr) Stats Avg result←average(attr) Stats Cnt result←count(attr) Stats MeanDev result←mean d eviation(attr) Stats Attribute checkanattributeinthecurrentactivetask Attribute Exist return1ifattrexists,otherwise0 Attribute Not Exist return1ifattrdoesnotexist,otherwise0 Attribute Length returnthelengthofattrvector Attribute Actuate actuatesaparticularchannel Actuate Set Leds settheledstoaccordingtogivenvalue Actuate Toggle Leds toggleledsbasedonthreeLSBofgivenvalue Actuate Leds0Toggle toggleled0 Actuate Leds1Toggle toggleled1 Actuate Leds2Toggle toggleled2 Actuate Sounder start/stopMicasbsounder Actuate Storage storageisvalidwithinatask,maintainedacrossactivetasks Storage Store storeanattributeintostorage Storage Retrieve retrieveanattributefromstorage Storage Pack packconsecutiveinputvaluesintoavectorofvalues Pack Pack n Wait perform‘pack’andwaituntilthevectorisfull Pack Send sendtaskresponsebackusingbest-efforttransport SendPkt/Str/Rcrt SendPkt sendtaskresponsebackusingpackettransport SendPkt SendStr sendtaskresponsebackusingstreamtransport SendStr SendRcrt sendtaskresponsebackusingRCRTprotocol SendRcrt Reboot rebootthemote Reboot DeleteAttributeIf deleteanattributeifarg==TRUE DeleteAttributeIf DeleteAttribute deleteanattribute DeleteAttributeIf DeleteAllattributeIf deleteallattributesifarg==TRUE DeleteAttributeIf DeleteTaskIf deletethetaskcompletelyifarg==TRUE DeleteTaskIf DeleteActiveTaskIf deleteactiveinstanceofthetaskifarg==TRUE DeleteActiveTaskIf Sample sampleon-boardADC’s Sample Voltage returnvoltagelevel Voltage UserButton (Telosbonly)runthetaskeverytimeuserbuttonispressed UserButton SampleMDA400 (Micaz/Mica2only)samplemda400vibrationboard SampleMda400 Onset Detector performonset-detectionanddata-filtering OnsetDetector FirLpFilter performFIRlow-passfilteringondata FirLpFilter RLE performRun-LengthEncondingondata Rle PackBits performPackBitsencodingondata PackBits Vector generateadummyvectorof’length’with’pattern’ Vector Image (Micaz/Mica2only)interactwithCyclopscamera Image Image Snap takeapicture Image Image Detect performbackground-subtractionbasedobjectdetection Image Image Get getanimagefromCyclops Image Image Set Capture Params setcameraparameters Image Image Get Capture Params getcameraparameters Image Image GetRLE getanimage,compresswithrunlengthencoding Image Image GetRLE getanimage,compresswithPackBitsalg. Image 165 AppendixB TenetTaskingAPIHowTo Introduction This appendix briefly discusses the usage of the tasklets in the Tenet tasking library, and the syntax for writing the ”task description string” which is equivalent to “contructing a task”. An example of a task descriptionstringwouldbe: "Repeat(1000)->GlobalTime(0xAA)->NextHop(0xBB)->Count(0xCC)->Send()" which will task the motes to send packets periodically every one second with time-synchronized global- time,nexthop(routingparent),andanapplication-levelsequencenumber. Ataskisconstructedbycomposingoneormoretaskletsinalinearchain. Thereisnoloopingorbrach- ing. But there are couple of special tasklets that can control the issuance of a task or perform conditional execution. Whenwritingyourownapplication,allyouneedtodoistodisseminateataskintothenetworkistofirst constructataskdescriptionstring,andthenpassthatstringtothe’send task(char*s)’functionasdeclared in the tenet library. To get a feel of how it works, you can try out the pre-compiled example application; ‘send task’application;inourTenetbinarydistribution(http://tenet.usc.edu)asfollows: 1. Goto the application directory: % cd $TENET_ROOT/master/apps 2. Run ’send_task’ application using the example task shown above: % ./send_task "Wait(1000,1)->GlobalTime(10)->NextHop(11)->Count(12,1,1)->Send()" Press <Ctrl-C> to stop. 3. Try turning on and off the LEDs of the motes: % ./send_task "set_leds(’7’)" % ./send_task "set_leds(’0’)" 4. Try a tinyos toy application, CntToLedsAndRfm: % ./send_task "repeat(500)->count(5,0,1)->set_leds(5)->send()" 5. You can check the usage of any tasklet by using ’-u’ option: % ./send_task -u wait // see usage of ’wait’ Attributes In Tenet, all data are generated, manipulated, and sent in a form of an attribute. The following list dis- cusses the syntax and semantics of attributes. It might be useful to think of attributes as variables in a programminglanguage. • Attributeshave16-bitunsignedintergertagasaname 166 • An attribute can either be a scalar (we support only one type: unsigned short) or a vector (an array ofunsignedshorts),andthisisdeterminedfromthecontext • Anattributeisimplicitlydefinedinthefirsttaskletinwhichitisreferenced • Whenitisfirstdefined,theattributeshouldbeonthe“LHS”ofanoperator. • Anattributemustbeexplicitlydeleted • Send()tasklettransmitsallundeletedattributes • Thefollowingattributenamesarereservedforspecialpurpose: ‘0’,‘1’ Constants Someorthetaskletstakeeitheranattributeoraconstantasanargument. Forexample,toturn-onallthree LEDsofatelosb(ormicaz)mote,youcando: % ./send_task "set_leds(’7’) or % ./send_task "constant(5, 7)->set_leds(5)" Bothcommandswillresultinsamebehavior. Inthefirstexample,‘7’inquotesisaconstantseven. Inthe secondeexample,and5isanattributenamefive,and7isaconstantseven. In the tasklet API,for the arguments that explicitly say ‘constant’ or ‘attribute’, the supplied value is interpreted as declared regardless of the quote. For the arguments that can take either ‘constant’ or ‘attribute’, the argument value is interpreted as constant if written within quotes, otherwise as attribute name. So,thefollowingcommandswillresultinanerror: % ./send_task "set_leds(7) // no attribute with name 7 exist % ./send_task "constant(5, 7)->set_leds(7)"// no attribute with name 7 exist Butthefollowingcommandwillbefine: % ./send_task "constant(’5’, 7)->set_leds(5)" Repeatingtask There is no looping or branching construct in Tenet tasking language. But it is possible to do “do this every 1 second”, or “sample every 1 minute”. How do we do this? There are two special tasklets that can dorepeatedexecutionofatask. Thisislike‘forking’inaCprogram. (Wecalleachexecutionofataskas ‘active task’,whichcouldbethoughtofasaniterationofatask,oraninstanceofatask.) repeat(period) : Execute task every ’period’ millisecond. An aliased tasklet from ’issue(waittime, period, abs)’ sample(interval, count, repeat, channel, out) : sample ’channel’ every ’interval’ millisecond. fill up an attribute with ’count’ number of samples and tag it as ’out’. repeat this procedure if ’repeat’. Two tasklet API’s, ‘Wait n Repeat’ and ‘GlobalRepeat’ are variants of the ’Repeat’. No other tasklet can generatearepeatedexecutionofatask. ConditionalExecution ThereisnoloopingorbranchingconstructinTenettaskinglanguage. Butitispossibletodo“runthistask only on node 10”, or “send packet only when temperature is above 25”. How do we do this? There are twospecialtaskletsthatlet’syoudodoconditionalexecutionofatask. deletetaskif(arg) : delete this task including all its active instances, if arg is non 0 deleteactivetaskif(arg) : delete active instance of this task if arg is non 0 Forexample,thefollowingtaskwillrunonlyonanodewithid101. "NodeId(2)->NEQ(3,2,‘101’)->DeleteTaskIf(3)->Sample(4)->Send()" AppendixAlistsalltaskletAPI’savailableinTenetsoftwareasofreleasev2.0. 167

Abstract (if available)

Abstract In this dissertation we explore rate-adaptation in networks of wireless sensors. We investigate how the concept of rate adaptation can be used to build sensing systems that adapt to the network and environment dynamics. Specifically, we design a rate-adaptive transport protocol that can reliably and efficiently deliver sensor data on an architecture that respects the technological constraints of the embedded sensors. We also design a rate-adaptive sensing system that adapts to the environment and the behavior of the user to provide energy-efficient location sensing.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Congestion control in multi-hop wireless networks

PDF

Transport layer rate control protocols for wireless sensor networks: from theory to practice

PDF

Techniques for efficient information transfer in sensor networks

PDF

Robust routing and energy management in wireless sensor networks

PDF

Gradient-based active query routing in wireless sensor networks

PDF

Dynamic routing and rate control in stochastic network optimization: from theory to practice

PDF

Reconfiguration in sensor networks

PDF

Efficient and accurate in-network processing for monitoring applications in wireless sensor networks

PDF

Reliable languages and systems for sensor networks

PDF

Realistic modeling of wireless communication graphs for the design of efficient sensor network routing protocols

PDF

Adaptive resource management in distributed systems

PDF

Relative positioning, network formation, and routing in robotic wireless networks

PDF

Design of cost-efficient multi-sensor collaboration in wireless sensor networks

PDF

Multichannel data collection for throughput maximization in wireless sensor networks

PDF

Optimal distributed algorithms for scheduling and load balancing in wireless networks

PDF

Cooperation in wireless networks with selfish users

PDF

On location support and one-hop data collection in wireless sensor networks

PDF

Models and algorithms for energy efficient wireless sensor networks

PDF

Distributed wavelet compression algorithms for wireless sensor networks

PDF

Enabling virtual and augmented reality over dense wireless networks

Asset Metadata

Creator Paek, Jeongyeup (author)

Core Title Rate adaptation in networks of wireless sensors

School Viterbi School of Engineering

Degree Doctor of Philosophy

Degree Program Computer Science

Publication Date 10/26/2010

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag centralized congestion control,energy efficiency,mobile smartphone,OAI-PMH Harvest,rate adaptation,Software Architecture,tiered embedded network,wireless network,wireless sensor network

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Govindan, Ramesh (committee chair), Neely, Michael J. (committee member), Psounis, Konstantinos (committee member)

Creator Email jpaek@enl.usc.edu,jpaek@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-m3514

Unique identifier UC187513

Identifier etd-Paek-4074 (filename),usctheses-m40 (legacy collection record id),usctheses-c127-419890 (legacy record id),usctheses-m3514 (legacy record id)

Legacy Identifier etd-Paek-4074.pdf

Dmrecord 419890

Document Type Dissertation

Rights Paek, Jeongyeup

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Repository Name Libraries, University of Southern California

Repository Location Los Angeles, California

Repository Email cisadmin@lib.usc.edu