Building Efficient Wireless Sensor Networks withLow-Level Naming

�

John Heidemann�

Fabio Silva�

Chalermek Intanagonwiwat�

Ramesh Govindan�

Deborah Estrin���

Deepak Ganesan���

�USC/Information Sciences Institute4676 Admirality WayMarina del Rey, CA, USA 90292

�Computer Science DepartmentUniversity of California, Los AngelesLos Angeles, CA, USA 90095

�johnh,fabio,intanago,govindan,estrin,gdeepak� @isi.edu

ABSTRACTIn mostdistributedsystems,namingof nodesfor low-level com-municationleveragestopologicallocation(suchasnodeaddresses)andis independentof any application.In thispaper, weinvestigateanemergingclassof distributedsystemswherelow-level commu-nication doesnot rely on network topological location. Rather,low-level communicationis basedon attributesthat areexternalto the network topology and relevant to the application. Whencombinedwith densedeployment of nodes,this kind of nameddataenablesin-networkprocessingfor dataaggregation,collabo-rative signalprocessing,andsimilar problems.Theseapproachesare essentialfor emerging applicationssuchas sensornetworkswhereresources suchasbandwidthandenergy arelimited. Thispaperis thefirst descriptionof thesoftwarearchitecturethatsup-ports nameddataand in-network processing in an operational,multi-applicationsensor-network. We show thatapproachessuchasin-network aggregationandnestedqueriescansignificantlyaf-fectnetwork traffic. In oneexperiment aggregationreducestrafficby up to 42% andnestedqueriesreduceloss ratesby 30%. Al-thoughaggregationhasbeenpreviously studiedin simulation,thispaperdemonstratesnestedqueriesasanotherform of in-networkprocessing, andit presentsthefirst evaluationof theseapproachesover anoperational testbed.

1. INTRODUCTIONIn mostdistributedsystems,namingof nodesfor low-level com-�This work wassupportedby DARPA undergrantDABT63-99-

1-0011aspartof theSCAADSproject,NSFgrantANI-9979457aspartof theSCOWR project,andwasalsomadepossiblein partdueto support from CiscoSystems.

Permissionto make digital or hard copies of all or part of this work forpersonal or classroomuseis granted without fee provided that copies arenot madeor distributedfor profit or commercial advantage andthatcopiesbearthis noticeandthefull citationon thefirst page. To copy otherwise,torepublish,to postonserversor to redistributeto lists, requiresprior specificpermissionand/or a fee.SOSP2001,Lake Louise,Banff, CanadaCopyright 2001ACM X-XXXXX-XX-X/XX/XX ...$5.00.

municationleveragestopologicallocation(suchasnodeaddresses)and is independent of any application. Typically, higher-level,location-independentnamingandcommunicationisbuilt upon theselow-level communicationprimitivesusingoneor more levels of(possiblydistributed)bindingservicesthatmaphigher-level namesto topologicalnamesandsometimesconsiderapplication-specificrequirements.

An exampleof this is the InternetwhereIP addressesprovidethelow-level namessuitablefor routing. IP addressesareassignedtopologically: theaddressesfor nodesthataretopologicallyprox-imateareusuallydrawn from the sameaddressprefix [18]. (Bytopology, we meanlogical connectivity asdistinct from physicalgeography.) This topological assignment is essentialfor scalingtherouting systemandwascarriedforward into IPv6 [30]. DNSprovidesa text-basedhierarchicalnodenamingsystem[26] thatis implementedusingIP. Above this system,the web andsearchenginesprovide a documentandobjectnamingsystem,andcon-tentdistributionnetworksaddgeographic or application-level con-straints.As an alternative, systemssuchasJini [35] andINS [1]layerdifferentapproachesfor resourcediscoveryaboveIP for net-worksof devices.

In this paper, we investigatean emerging classof distributedsystemswherelow-level communication doesnot rely onnetworktopological location. Rather, low-level communication is basedonnamesthatareexternalto thenetwork topologyandrelevant totheapplication;namescanbebasedoncapabilitiessuchassensortypesor geographic location. Suchan approachto namingal-lows two kinds of efficiencies. First, it eliminatesthe overheadof communication requiredfor resolving namebindings. Sec-ond,becausedatais now self-identifying,it enablesactivation ofapplication-specific processinginsidethe network, allowing datareductionnearwheredatais generated.

Thesetwo benefits do not apply to the Internet as a whole,where,by comparison, bandwidthis plentiful, delay is low, andthroughput(routerprocessingcapability) is theprimaryconstraint.Technologytrendssuggest,however, that theseconditionsarere-versed in wirelesssensornetworks. Sensornetworks arepredi-catedontheassumptionthatit will befeasibleto havesmallform-factordevicescontainingsignificantmemoryresources,process-ing capabilities,andlow-power wirelesscommunication,in addi-tion to several on-boardsensors.In sensornetworks processing

time� per bit communicatedis plentiful (CPUsarefastandband-widths low), but bandwidthis dear. For example, in onescenarioPottieandKaiserobservethat3000instructionscouldbeexecutedfor thesameenergy costof sendingabit 100mby radio[29]. Thisenvironmentencouragestheuseof computationto reducecommu-nication. In that context, fewer levels of namingindirectionandtheuseof in-network, application-specificmessageprocessing(asopposedto opaquepacket forwarding)areessentialto thedesignof sensornetworks.

Our thesis,then,is thattheresourceconstraintsof wirelesssen-sornetworkscanbebettermetby anattribute-basednamingsys-tem with an external frameof referencethan by traditional ap-proaches.Therehavebeenmany attribute-basednamingschemes,but most build over an underlying topological naming schemesuchasIP [28, 10,6, 38,4, 27,1, 20,22]. Multiple layersof nam-ing maynot bea bottleneckwith a few or eventensof nodes,butthe overheadbecomesunreasonablewith hundreds or thousandsof nodesthatvary in availability (dueto movementandfailures).However, constrained,application-specific domainssuchassen-sornetworkscanprofit by eliminatingmultiple layersandnamingandrouting datadirectly in application-level terms. Efficient at-tribute namingis basedon external framesof referencesuchaspre-definedattributesandgeography. Pre-definedsensortypesre-ducethe levelsof run-timebindingandgeographic-aidedroutingreducesresourceconsumption.

In addition to attribute-basednaming, application-specific, in-networkprocessingis essentialin resource-constrainedsensornet-works. As suggestedby the above trade-off betweencomputa-tion and communication, application-specific caching,aggrega-tion, andcollaborative signalprocessing shouldoccurascloseaspossibleto wherethedatais collected.Suchprocessingdependson attribute-identifieddata to trigger application-specificfilters,pre-definedattributesanddatatypesto allow pre-deploymentofthesefilters, andhop-by-hopprocessingof thedata.This kind ofprocessingis similar to Active Networks [34], but differs by op-eratingin theconstrained, bandwidth-poorenvironmentof sensornetworkswhereanintegrated,application-specificsolutionis ap-propriate.

As anillustrationof attribute-basednamingandin-network pro-cessingin a sensornetwork, considera wirelessmonitoringsys-temwith a mixtureof light or motionsensors(constantlyvigilantat low-power),andafew higher-power andhigher-bandwidthsen-sorssuchas microphonesor cameras.To conserve energy andbandwidththe audio sensorswould be off (or not recording)atmost times, except when triggeredby lessexpensive light sen-sors. Insteadthis computation canbe distributedthroughout thenetwork. Queries(userrequests)arelabeledwith sensortype(au-dio or light) known to thesystemat designtime. Queriesdiffusethroughthe network to be handledby nodeswith matchingsen-sorsin the relevant geographic region. The applicationwill hearfrom whatever relevant sensorsrespond. Moreover, the decisionof onesensortriggeringanothercanbe moved into the networkto be handleddirectly betweenthe light andaudiosensors.Thealternative Internet-basedarchitecturewould have a centraldirec-tory of active sensorsand a centralapplicationthat interrogatesthis database,monitorsspecificsensors, andthentriggersothers.Our goal is to eliminatethe communicationcostsof maintainingthiscentralinformationto providemorerobustandlong-livednet-works in spiteof changingcommunications, moving nodes,andlimited batterypower. (We exploreexactly how theseapproaches

work in Section5 andquantify potentialsavingsin Section6.)In this paper, we demonstratethat thereexists a simplearchi-

tecturethatusestopology-independentnamingfor low-level com-municationsto achieve flexible, yet highly energy efficient appli-cationdesigns.Thekey contributionsof this work aretherefore:

� Identifying thebuilding-blocksof this architecture,specifi-cally anattribute-basednamingschemewith flexiblematch-ing rulesgrounded in asharedframework of attributes(suchassensortypesandgeography).

� Showing how this approachto namingenablesapplication-specific, in-networkprocessingsuchaslocalizeddataaggre-gation,andto quantifythesebenefitsin a runningsystem.

In previouswork [23], wehavediscussedthelow-level commu-nicationprimitives that constitutedirecteddiffusion. This workfocusedon understanding thedesignspaceof the network proto-cols underlying directeddiffusion. It alsoevaluatedtheir perfor-mancethroughsimulation,findingthatscalabilityis goodasnum-bersof nodesand traffic increases.However, this work did notdevelopthesoftwarearchitecturenecessary for realizingattributesandin-network processingin anoperationalsystem(for example,it employedasimplifiedattributeschemeandhard-codedaggrega-tion methods).In addition,simulationsnecessitateapproximatingenvironmental effectssuchasradiopropagation,andmany param-etersof thosesimulationswerenot set to matchthe sensornet-working hardwarethat is only now becoming available. By con-trast,thispaperevaluatesthedesignquestionsconcerningnamingandin-network processing encounteredin deploying asensornet-work, andit presentsthe first experimentalresultsof datadiffu-sionin a testbed(reflectingthedetailsof an implementationsuchasnon-idealizedradios,propagation,MAC protocols,etc.).

Numerous early systemshave developedattribute-basednam-ing systems,for generaluse[28, 10, 6], asan approachto soft-waredesign[9, 4, 27,17,25] andfor sensornetworks[1, 22]. Ourwork is uniquein thatit replacesratherthanaugmentstheunderly-ing networking routinglayers,andthat it provides matchingrulesthatallow efficient implementationandyet areexpressive enoughto cover a wide rangeof applications,and provides in-networkprocessing.

2. RELATED WORKOur work builds on prior work in attribute-basednaming, in-

network processing, andsensornetworks.

2.1 Attrib ute-basednaming systemsTherehasbeena largeamount of work on attribute-basednam-

ing, bothfor generalpurposeuseover Internet-stylenetworks,forspecialdomains(suchasthe web),andasan internalstructuringmechanismfor services.

Researchandindustryhavedevelopednumerousattribute-basednamingsystemslayeredon topof general-purposenetworks.Uni-versandyellow-pagesnamingat theUniversityof Arizona[6, 28]weredesignedto provide servicediscovery for groupsof comput-ers(for example,print to anunloadedpostscript-capableprinter).Likeourwork, they includeattributesandoperators,but they buildoverstandardInternetprotocolsfor communications.Commercialattribute-basednamingsystemssuchasX.500[10] andLDAP[38]alsooperateover Internetor Internet-like routing and provide a

primarily� hierarchicalorganization. Dependenceon IP-level ad-dressingand routing limits addssubstantial overhead when ap-plying thesesystemsto highly resource-constrainedenvironmentssuchassensornetworks. (For example,someapproachesto ser-vice locationfor smartspacesrequireservicesfor IP assignment,IP-level routing, hostnamelookup, andserviceregistrationandlookup.) With end-to-endprocessing only, thesesystemsalsodonot provide in-network processing.

As an alternative to providing attribute-basednamingfor end-useruse,severalsystemshaveproposedattribute-basedcommuni-cationsfor structuringdistributedsystems.Linda proposedstruc-turingdistributedprogramsusingseveralCPUsaroundanattribute-indexedcommon memorycalleda tuplespace[9]. For theS/Netimplementationthiswasthebasiccommunicationmechanism,butproposed implementationsassumeuniform and rapid communi-cationsbetweenall processors.Later systemssuchas ISIS [4]and the InformationBus [27] provide a “publish andsubscribe”approachwhere information providers publish information andclientssubscribeto attribute-specifiedsubsetsof thatinformation.Thesesystemsaredesignedto be robust to failure,but againas-sumereasonably fast, plentiful, and expensive communicationsbetweennodes. Theseapproachesarenot directly applicabletoresource-constrainedsensornetworks.They donotuseapplication-specific,in-network processingsinceall processesarereasonablycloseto eachother; when they do useprocessing(suchas at awide-areagateway) it is manually configured.

More specificstill is work thatproposesattribute-basedprimi-tivesassolutionsto specificproblems. SRM first suggestedus-ing nameddata as the fundamental data unit for reliable mul-ticast communication, and it demonstratedthis approach with adistributed whiteboard[17]. Our work is inspiredby theseap-proaches, but it differs by providing a wider rangeof matchingoperators(ratherthanjustequality),addingin-network processingto leverageCPU-communicationstrade-offs for sensornetworks,and operatingdirectly over low-level (hop-by-hop) communica-tionsprotocolsinsteadof theInternetmulticastinfrastructure.

2.2 In-network processingRecentwork in active networks [34] and active services[2]

hasexaminedwaysto provide in-network processingfor the In-ternet.Sampleapplicationsincludeinformationtranscoding, net-work monitoring,andcaching. Thiswork is built overanInternet-likeinfrastructure,oftenaugmentedwith anextendedrun-timeen-vironment,andassumesnodesare individually addressable. Weinsteadbuild directlyoverhop-by-hopcommunicationsprimitivesandidentify datainsteadof nodes.Our work differs from activeservicesin that we assumethat communicationscostsbetweennodesvary greatly while currently proposedactive servicesas-sumeroughly equivalentdistancesbetweenall service-providingnodes. We differ from active networks primarily in the targetdomain: we target sensornetworks wherebandwidth is limited,energy is expensive, andcomputepower is comparatively plenti-ful andinexpensive. Instead,active networks typically considersInternet-like domainswherebandwidthis plentiful, the ratio ofcomputepower to bandwidthis muchlower, andenergy is not anissue.All of theseapproachesdistributeapplication-specific codethroughout the network, raisingquestionsabout codesafetyandportability. Theseproblemsarenot central to somesensornet-works(suchasthosethataredevotedto a singleapplication),butmorecomplex networkswouldbenefit from active-networks-style

executionenvironmentsto support in-placeupgradability .Recentwork onadaptivewebcaching[25] andpeer-to-peerfile

sharingsystemssuchasFreenet[12] exploreapplication-specific,hop-by-hop processing. Unlike active networks and our work,theseapproachesemphasizeprotocolsdesignedfor a particularapplication. In addition,our work runsdirectly over hop-by-hopcommunicationratherthanoveravirtual network layeredover theInternet.

2.3 Sensor-network-specific systemsSensornetworking researchhasseenincreasingactivity in the

lastfew years,with advancesin sensornodeandradiohardware[33,29]. This work hasbeeninstrumentalin clarifying the trade-offbetweencomputation and communication and the needfor in-network processing. Our focuson in-network processingis moti-vatedby thiswork. Thiswork ishoweverbasedontopographically-addressedsensornodes;theprimarydifferencein our work is theuseof attribute-basednamingfor structureanddatadiffusion forcommunication.

Internetadhocrouting(Brochetal.survey severalprotocols[7]suchas DSR and AODV) can also be usedin sensornetworks.Sincead hoc routing recreatesIP-styleaddressing, it would re-quiresomekind of directoryserviceto locatesensors,unlike ourapproach wherethey arenamedby attributes.Ad hocroutingdoesnot support in-network processing.

Jini is an exampleof a resourcediscovery systembuilt overInternetprotocols[35]. It provides a directoryserviceandusesJava to distributeprocessingto usernodes,makingit well suitedto a local-areanetwork with high bandwidthand multicast. Bycontrast,we distribute the directory acrossthe network and al-low application-specific processingat intermediatesystemnodes,addressingproblemsof resource-constrained, multi-hop wirelessnetworks.TheNinjaServiceDiscoveryService[15] locatesXML-namedobjectsthroughanetwork of collaboratingserversbut againtargetshigh bandwidth local-arearesources.

ThePiconetwork haspresentedfundamentaladvancesin energy-conserving network communicationsfor networksof devices[3].Their work focuses on static hierarchiesof networked devices,concentrators, and hosts. While similar to our tiered architec-turewith full andmicro-diffusion, they do not considerattribute-nameddataor dynamicin-network processing.

SPINevaluatesseveralvariantsof flooding for wirelesssensornetworks [20]. Datain SPINis identifiedby application-specificmetadatathat appears to assumeindividual sensors areaddress-able.Weinsteaduseattributesto namedataalone;globallyuniqueidentifiersarenotused.SPINdoesnotconsiderapplication-specificin-network processing.

TheIntentionalNamingSystemis anattribute-basednamesys-temoperatingin anoverlaynetwork over the Internet[1]. Its useof attributesasastructuringmechanismandamethodto copewithdynamically locatingdevicesis similar to ourapproachin motiva-tion andmechanism.The primary differenceis that we assumethat attribute-basedcommunication(datadiffusion) is the basiccommunicationsprimitive (above hop-by-hop messaging), whilethey constructanoverlay network over an IP-basedInternet.Ar-chitecturallythis impliesthatwe distributenamematchingacrossmany smallcommunicationsnodeswhile they managenamesatafew resolvers that cooperatively managepartsof the namespace.Finally, the detailsof matchingaredifferent in the two systems.Their work providesa sophisticatedhierarchicalattribute match-

ing procedure. Ourapproach is muchmoremodestby comparison(targetingsmallerembeddeddevices) but addscomparative oper-atorsin additionto equality.

LEACHanalyzestheperformanceof cluster-basedroutingmech-anismwith in-network datacompression[19]. They emphasizehow intermediate-rangecommunicationvia cluster-headsandhowcompressioncan reduceenergy consumption. Their in-networkcompressionis oneexampleof thekind of in-network processingthatwe would like to support.They do not specifyhow flowsandopportunitiesfor aggregationwould beactivated,while our workfocuseson thenamingmechanismsthatallow suchactivity.

DataSpacedescribesanattributebasednamingmechanism forqueryingphysicalobjectsthat produce andstorelocal data[22].The DataSpaceis divided into smalleradministrative andlogicaldatacubes, whicharelogically groupedinto dataflocks. Dataflocksareaddressedatthenetwork level throughIPv6multicastaddressesthat correspondto their geographiccoordinates,andtheir valuesfor certainattributesthatserve asnetwork indices. Queryresultsmay involve aggregation of more specific queriesaddressedtosub-datacubes. At a high-level their namingapproach is similarto ours,but insteadof mappingattributesandgeometry to a verylarge numberof multicastgroupswe routedirectly on attributesthemselveswithout this indirection. In addition, they do not ex-plorein-network processing.

The COUGAR device databasesystemproposes distributingdatabasequeriesacrossasensornetwork asopposedto moving alldatato a centralsite[5]. Sensordatais representedasanAbstractDataType attribute, the public interfaceto which corresponds tospecificsignal processingfunctionssupportedby a sensortype.They thenperformjoins or aggregation in the network asspeci-fied by a centrallycomputedqueryplan. Their work is commonwith oursin its emphasison in-network processing, andour studyof nestedqueries(Section5.2) was inspiredby their work. Theprimary differencebetweentheir work in ours is how placementof in-network processingis determined.We emphasizetheuseoffiltersandnestedqueriesto enableeitherad-hocor sensor-specificplacementof in-network processing, while COUGAR centrallytranslatesthequeryandassignsprocessing to thedistributedsys-tem, incurring overheadto centrallycollect network informationfor queryoptimization.

Declarative Routingfrom MIT’ s Lincoln Labsis closestto ourwork [14]. The publish/subscribe-orientedAPI we usewas de-fined in collaborationwith them [13] and they have developedanindependentimplementation.Theprimarydifferencebetweentheir work andours is our focus on in-network processing. Weevaluatetheir work morecompletelyin Section4.2.

3. ARCHITECTUREOurcommunicationsarchitectureisbasedonthreecomponents:

directeddiffusion,matchingrules,andfilters. Directeddiffusionis usedto disseminateinformationin thedistributedsystem.Datais managedasa list of attribute-value-operation tuples.Matchingrules identify whendatahasarrived at its destination,or if inter-mediatefilters shouldprocessthe data.This approach to namingcomestogetherto provide an external framework relevant to theapplication. Thesecomponents balancethe genericservicesofdiffusion andmatchingruleswith application-provided attributesandfilters. We next describeeachof thesecomponents.

3.1 Dir ectedDiffusionDirecteddiffusionis adatacommunicationmechanismfor sen-

sornetworks[23]. Datasourcesandsinksuseattributesto identifywhat information they provide or are interestedin. The goal ofdirecteddiffusion is to establishefficient n-way communicationbetweenoneor moresourcesandsinks. Directeddiffusion is adata-centriccommunication paradigmthat is quitedifferentfromhost-basedcommunicationin traditional networks. To describetheelementsof diffusion,we take thesimpleexampleof a sensornetwork designedfor trackinganimalsin a wildernessrefuge.

Supposethat a user in this network would like to track themovementof animalsin someremotesub-region of the park. Indirecteddiffusion, this tracking task representsan interest. Aninterestis a list of attribute-value pairs that describea task us-ing sometask-specificnamingscheme(we describethedetailsoftheseattributesin thenext section).Intuitively, attributesdescribethe datathat is desiredby specifyingsensortypesand possiblysomegeographic region. They arethenusedto identify andcon-tactall relevantsensors.We usethetermsink to denote thenodethatoriginatesaninterestandthereforeis thedestinationof data.

The interestis propagatedfrom neighbor-to-neighbortowardssensornodesin thespecifiedregion. A key featureof directeddif-fusion is that every sensornodeis task-aware—by this we meanthatnodesstoreandinterpretinterests,ratherthansimplyforward-ing themalong.In our example,eachsensornodethatreceivesaninterestrememberswhich neighbor or neighbors sent it that in-terest. To eachsuchneighbor, it setsup a gradient. A gradientrepresentsboth the directiontowardswhich datamatchingan in-terestflows, andthestatusof thatdemand (whetherit is active orinactive andpossiblythe desiredupdate rate). After settingup agradient,thesensornoderedistributestheinterestto its neighbors.Whenthenodecaninfer wherepotentialsourcesmightbe(for ex-ample,from geographic informationor existingsimilargradients),theinterestcanbeforwardedto a subsetof neighbors.Otherwise,it will simply broadcasttheinterestto all of its neighbors.

Whenasensornodethatmatchestheinterestis found, theappli-cationactivatesits local sensorsto begin collectingdata.(Prior toactivationwe expectthenode’s sensorswould be in a low-powermode). The sensornodethengeneratesdata messagesmatchingthe interest. In directeddiffusion, datais alsorepresentedusingan attribute-basednamingscheme.A sensornodethat generatessuchanevent descriptionis termeda source.

Data is cachedat intermediatenodes as it propagatestowardsinks.Cacheddatais usedfor severalpurposesat differentlevelsof diffusion.Thecorediffusionmechanismusesthecacheto sup-pressduplicatemessagesandprevent loops,andit canbeusedtopreferentiallyforward interests.(Sincethe diffusion core is pri-marily interestedin an exact match,as an optimization,hashesof attributescanbecomputedandcomparedratherthancompletedata.)Cacheddataisalsousedfor application-specific,in-networkprocessing.For example,datafrom detectionsof a singleobjectby differentsensorsmaybemergedto a singleresponsebasedonsensor-specificcriteria.

Theinitial datamessagefrom thesourceis markedasexplora-tory and is sentto all neighborsfor which it hasmatchinggra-dients. If the sink hasmultiple neighbors,it choosesto receivesubsequent datamessagesfor the sameinterestfrom a preferredneighbor(for example,the onewhich deliveredthe first copy ofthe datamessage). To do this, the sink reinforces the preferredneighbor, which, in turn reinforcesits preferredupstreamneigh-

Sink

Event

Source

Interests

(a) Interest propaga-tion

Sink

Event

Source

Gradients

(b) Initial gradientssetup

Sink

Event

Source

(c) Datadelivery alongreinforcedpath

Figure1: A simplified schematicfor dir ecteddiffusion.

bor, andsoon. Finally, if a nodeon this preferredpathfails, sen-sor nodescanattemptto locally repair the failed path. The sinkmayalsonegativelyreinforce its currentpreferredneighbor if an-other neighbor delivers better(lower latency) sensordata. Thisnegative reinforcement propagatesneighbor-to-neighbor, remov-ing gradients andtearingdown andexisting pathif it is no longerneeded[23]. Negative reinforcementssuppressloopsor duplicatepathsthatmayarisedueto network dynamics.

After theinitial exploratorydatamessage,subsequentmessagesaresentonly on reinforcedpaths. Periodicallythe sourcesendsadditional exploratory data messagesto adjust gradientsin thecaseof network changes(due to nodefailure, energy depletion,or mobility), temporarynetwork partitions,or to recover from lostexploratory messages.Recovery from dataloss is currently leftto the application. While simpleapplicationswith transientdata(suchassensorsthatreporttheir stateperiodically)needno addi-tionalrecoverymechanism,wearealsodeveloping retransmissionschemefor applicationsthattransferlarge,persistentdataobjects.

Eventhis simplifieddescriptionpointsout severalkey featuresof diffusion,andhow it differsfrom traditionalnetworking. First,diffusion is data-centric;all communication in a diffusion-basedsensornetwork usesintereststo specifynameddata. Second,allcommunication in diffusion is neighbor-to-neighbor or hop-by-hop, unlike traditionaldatanetworks with end-to-endcommuni-cation.Everynodeis an“end” in asensornetwork. A corollarytothis previousobservationis thatthereareno “routers” in a sensornetwork. Eachsensornodecan interpretdataand interestmes-sages. This designchoice is justified by the task-specificityofsensornetworks. Sensornetworks arenot general-purposecom-municationnetworks. Third, nodesdo not needto have globallyuniqueidentifiersor globally uniqueaddresses for regularopera-tion. Nodes,however, do needto distinguishbetweenneighbors.Fourth,becauseindividual nodescancache,aggregate,andmoregenerally, processmessages,it is possibleto performcoordinatedsensingcloseto thesensedphenomena. It is alsopossibleto per-form in-network datareduction,therebyresulting in significantenergy savings. Finally, althoughour exampledescribesa partic-ular usageof the directeddiffusion paradigm(a query-responsetypeusage,seeFigure1), theparadigmitself is moregeneralthanthat;wediscussseveralotherexampleapplicationsin Section5.

3.2 Attrib ute Tuplesand Matching RulesDiffusion messages andapplicationinterestsarecomposedof

attribute-value-operationtuples.Attributesareidentifiedby unique

one-waymatch:given two attributesets and �for each attribute � in where �� op is a formal �

matched = falsefor each attribute � in � where �� key ���� key and �� op is anactual

if �� val compareswith �� val using �� op,then matched= trueif not matched then return false(no match)�

return true(successfulone-way match)

Figure2: Our one-waymatching algorithm.

keys drawn from a centralauthority. (In practicewe implementtheseassimple32-bit numbersand assumeout-of-bandcoordi-nation of their values,just as Internetprotocol numbers are as-signed.) Attributes implicitly have a data format (integersandfloating point valuesof differentsizes,strings,anduninterpretedbinarydataarecurrentlysupported).

Theoperationfield defineshow datamessagesandinterestsin-teract.Operationsaretheusualbinarycomparisons(EQ,NE, LE,GT, LE, GE,correspondingto equality, inequality, lessthan,etc.),“EQ ANY” (which matchesanything), andIS. “IS” allows usersto specifyanactual(literal or bound) value,while all theotherop-erationsspecifyformal (acomparisonor unbound)parametersforcomparison. A one-waymatch comparesall formal parametersofoneattributesetagainsttheactualsof theothers(Figure2). Anyformal parameterthat is missinga matchingactual in the otherattributesetcausestheone-way matchto fail (for example,“con-fidenceGT 0.5” musthave anactualsuchas“confidenceIS 0.7”andwould not match“confidence IS 0.3”, “confidenceLT 0.7”,or “confidence GT 0.7”). Two setsof attributeshave a completematch if one-way matchessucceedin both directions. In otherwords,attribute sets � and � matchif the one-way matchalgo-rithm succeedsfrom both � to � and � to � .

Thismatchingstyleis similarto therulesusedin otherattribute-basedlanguages(for example,Linda [9] andINS [1]), but weaddtwo-waymatchingandarangeof operatorsin additionto equality.Whenmultiple attributesandoperatorsarepresentthey areeffec-tively “anded” together;all formalsmustbesatisfiedfor a matchto besuccessful.This approach strikesa balancebetweeneaseofimplementationandflexibility . Thesimplebounded setof opera-torscanbeimplementedin tensof linesof codeandyet supports,for example,rectangular regions.

To seehow diffusion andattribute matchinginteract,we con-tinue the example from Section3.1 wherea userasksa sensornetwork to trackfour-leggedanimals.Theuser’s querytranslatesinto an interestwith the attributes(type EQ four-legged-animal-search,interval IS 20ms,durationIS 10seconds,x GE–100,x LE200, y GE 100, y LE 400). Also, an implicit “classIS interest”attribute is addedto identify this messageasan interest(asop-posedto data).This interestspecifiesfive conditions:detectionofanimalsin aparticularregion specifiedby a rectangle.It alsopro-vides informationabout how frequently datashouldbe returnedandhow long thequeryshouldlast.

Sensorsin thenetwork areprogrammedwith animalsearchrou-tines(eitherby pre-programmingatdeploymenttimeor by down-loading mobile code). Suchsensorswould watch for interestsin animalsby expressinginterestsabout interestswith attributes(classEQ interest,type IS four-legged-animal-search, x IS 125,y IS 220). Whentheuser’s interestarrivesat thesensorit wouldactivateits sensorusingtheparametersprovided(durationandin-terval) andreply if it detectsanything.

Whenthesensordetectssomethingthedatamessagewould in-clude attributes(type IS four-legged-animal-search, instanceISelephant,x IS 125,y IS 220,intensityIS 0.6,confidence IS 0.85,timestampIS 1:20,classIS data).This messagesatisfiestheorig-inal interest.It encodes asattributesadditionalinformationaboutwhatwasseenandwhatconfidencethesenderhasin its detection.

Thisexampleillustratesthedetailsof a specificquery. It showshow nameddataprovidesa convenientway of encoding informa-tion, andhow geometryandwell-known attributesallow simplematchingruleswork for this application. Although this exampleusesseveralattributes,someapplicationsmayuseonly asubsetofthesemethods,omitting geographic constraints(in a smallsensornetwork) or usingasingleattribute(whenthereis only onesensortype). We have found thattheseprimitivesprovide goodbuildingblocksfor a rangeof applications;we describethesein Section5.

Althoughmatchingis reasonably powerful, it doesnotperfectlycover all scenariosor tasks. Simplematchingin thesecasescanapproximatewhat is required,and application-specific codecanfurtherrefinethechoice.For example,perfectrectanglesalignedwith the coordinate systemare insufficient to describearbitrarygeometricshapes.Non-rectangular shapescanbe accomplishedeitherby multiplequeries,or by usingthesmallestbounding rect-angleandhaving the applicationignorerequestsinsidethe rect-anglebut outsidetherequiredregion. Similarly, applicationscanusegeneralattributesthat areclarified with sub-attributesor pa-rameters(type IS animal-search,subtypeIS four-legged). Filters(describednext) alsoallow applicationsto influenceprocessing.

3.3 FiltersFiltersareourmechanismfor allowing application-specificcode

to run in thenetwork andassistdiffusion andprocessing.Appli-cationsprovide filters beforedeployment of a sensornetwork, orin principlefilterscouldbedistributedasmobilecodepackagesatrun-time. Filtersregisterwhat kinds of datathey handlethroughmatching;they arethentriggeredeachtime that kind of dataen-tersthenode.Wheninvoked,afilter canarbitrarilymanipulatethemessage,cachingdata,influencinghow or whereit is sentonward,or generatingnew messages in response.Filtershaveaccessto in-ternalinformationaboutdiffusion,includinggradientsandlistsofneighbornodes.

Filtersaretypically usedfor in-network aggregation,collabora-

tivesignalprocessing,caching,andsimilar tasksthatbenefitfromcontrolover datamovement.In additionto theseapplications,wehave foundthemvery usefulfor debugging andmonitoring.

Continuingour example,a filter canbe usedto suppresscon-currentdetectionsof four-leggedanimalsfrom differentsensors.It would register interestin detectioninterestsanddatawith at-tributes(type IS four-legged-animal-search).It could thenrecordwhat the desiredinterval is, then allow exactly one reply everyinterval units of time, suppressingrepliesfrom othersensors.Amoresophisticatedfilter couldcountthenumberof detectingsen-sorsandadd that asan additionalattribute, or it could generatesomekind of aggregate“confidence” rating in someapplication-specificmanner. In this examplefiltering maydiscardsomedata,but by reducingunnecessarycommunicationit will greatlyextendthesystem’s operationallifetime.

We describesomeapplicationof filters in Section5, andquan-tify thebenefitsof aggregationin onescenarioin Section6.1.

4. IMPLEMENT ATIONSTherearecurrentlythreeimplementationsof all or partof this

architecture.Our currentreferenceimplementationSCADDSdif-fusionversion3 providesall components. MIT-Lincoln Labshasimplemented“declarative routing” that providesattribute match-ing but nofilters[14]. Bothof theseimplementationsrunonLinuxon desktopPCsandPC/104-basedsensornodes[11] (embeddedx86 machines,ourswith a 66MHz CPUand16MB of RAM andflash disk, Figure 3(a)), and on WINSng 1.0 sensornodes [29](Windows-CE-basednodeswith customlow-power radios,Fig-ure3(b)). We have alsoimplementedmicro-diffusion, a baresub-setof theseservicesdesignedto run on Moteswith tiny 8-bit pro-cessorsandonly 8KB of memory(Figure3(c)).

Sourcecodeto our implementationscanbe found on our websitehttp://www.isi.edu/scadds.

All of our implementations build upona simpleradioAPI thatsupportsbroadcastor unicastto immediateneighbors. Neighborsmust have somekind of identifier, but it is not requiredto bepersistent. We can usepersistentidentifiers(for example, Eth-ernetMAC addresses)or operatewith ephermallyassignediden-tifiers [16].

4.1 Basicdiffusion APIsOur referenceimplementationincludesC++ NetworkRouting

APIs summarizedin Figure4 (see[13] for a completespecifica-tionandexamplesourcecode).TheAPIsdefineapublish/subscribeapproachto datahandling. To receivedata,nodessubscribeto par-ticular setof attributes. A subscriptionresultsin interestsbeingsentthroughthenetwork andsetsup gradients.A callbackfunc-tion is theninvoked whenever relevantdataarrivesat thenode.

Applications that generateinformation publish that fact, andthensendspecificdata.Theattributesspecifiedin thepublishcallmustmatchthesubscription.If thereareno active subscriptions,publisheddatadoesnot leave thenode.As a furtheroptimizationsensornodesmaywishto avoid generatingdatathathasnotakers.In this casetheapplicationwould subscribefor subscriptionsandwould beinformedwhensubscriptionsarrive or terminate.

Filter-specificAPIs areshown in Figure5. A filter is primarilya callbackprocedure (thecb specifiedin addFilter)that is calledwhenmatchingdataarrives.Ratherthanoperateonly on attributevectors,filters are given direct accessto messages that includeidentifiersfor the previous andnext immediatedestinations.We

(a) Our PC/104node (b) WINSng1.0node (c) UCB ReneMote

Figure3: Diffusion operational platforms.

handle NR::subscribe(NRAttrVec *subscribeAttrs,const NR::Callback * cb);

int NR::unsubscribe(handle subscription_handle);handle NR::publish(NRAttrVec *publishAttrs);int NR::unpublish(handle publication_handle);int NR::send(handle publication_handle,

NRAttrVec *sendAttrs);

Figure4: Basicdiffusion API.

handle addFilter(NRAttrVec *filterAttrs,int16_t priority, FilterCallback *cb);

int NR::removeFilter(handle filter_handle);void sendMessage(Message *msg, handle h,

int16_t agent_id = 0);void sendMessageToNext(Message *msg, handle h);

Figure5: Filter APIs.

are currently evaluatingusing this additional level of control tooptimizediffusion, for exampleusinggeographic informationtoavoid floodingexploratoryinterests.Weexpecttheseinterfacestobeextendedaswe gainmoreexperiencewith how filtersareusedandwhatinformationthey require.

Finally, theseAPIshavebeendesignedto favor anevent-drivenprogrammingstyle,althoughthey have beensuccessfullyusedinmulti-threadedenvironments suchasWINSng 1.0. We have tar-getedevent-driven programming to avoid synchronizationerrorsand to avoid the memoryand performance overheads of multi-threading.Evidenceis growing thatevent-drivensoftwareis wellsuitedto embeddedprogramming,particularlyon very memory-constrainedplatforms[21].

Also we allow filtersandapplicationsto run in thesameor dif-ferentmemoryaddressspacesfrom eachotherandthe diffusioncore. Single-addressspaceoperationis necessaryfor very smallsensornodes that lack memoryprotectionandasa performanceoptimization.Multiple addressspacesmaybedesiredfor robust-nessto isolatefiltersof differentapplicationsfrom eachother.

4.2 MIT -LL declarative routingDan Coffin helpeddefine the basicdiffusion APIs (Figure 4

and[13]) anddevelopedan independent implementationin MIT-Lincoln Lab’s Declarative Routingsystem[14]. In principle allapplicationsthatdo not depend on filters will run over eitherim-plementation.Thislevel of portabilityhasbeendemonstratedwithCornell’s queryproxy [5] thatrunsover bothimplementations.1

Declarative routinganddatadiffusionarefar moresimilar thanthey aredifferent.Both namedataratherthanend-nodes.Differ-encesarein how routesandtransmissionareoptimized,both byapplicationsandthe coresystem.The primary differenceis thatdeclarative routing doesnot include filters to allow applicationsto directly influencediffusion. We seefilters as a critical nec-essarycomponent to enablegeneralin-network dataprocessing.Second,Lincoln Lab’s declarative routing includesdirectsupportfor energy andgeography-aidedroutingsothatroutesareselectedto avoid energy-poor nodesandgenerallymove “towards” a tar-get geographicarea. In our currentimplementationinterestsandexploratorymessagesarefloodedthroughthenetwork beforegra-dientsaresetup for direct communication. We arecurrentlyex-ploringusingfilters to optimizediffusion(avoidingflooding)withgeographic information[39].

4.3 Micr o-diffusionMicro-diffusion is a subsetof our approachimplementedon

very small processors(8-bit CPU, 8KB memory). It is distin-guishedby its extremelysmall memoryfootprint anda comple-mentaryapproachfor deploymentto our full system.

Micro-diffusion is a subsetof our full system,retainingonlygradients,condensing attributes to a single tag, and supportingonly limited filters. As aresultit addsonly 2050bytesof codeand106 bytesof datato its hostoperatingsystem. (By comparison,our full systemrequiresa daemonwith staticsizesof 55KB code,8KB data,andalibrary at20KB code,4KB data.)Micro-diffusionis implementedasa componentin TinyOS [21] that adds3250Bcodeand144B of data(including supportfor radio anda photosensor),so theentiresystemrunsin lessthan5.5KB of memory.Micro-diffusion is staticallyconfiguredto support 5 active gradi-entsanda cacheof 10 packetsof the2 relevantbytesperpacket.�No changeswererequiredto our diffusion implementation,al-

thoughtheport requiredonechangeto theapplicationto accom-modatea casewhereMIT’ s implementationwaslessstrict aboutattributematching.

Although� reducedin size,thelogical headerformat is compatiblewith that of the full diffusion implementationandwe areimple-mentingsoftware to gateway betweenthe implementations.Al-thoughwedonotcurrentlyprovidefilters in micro-diffusion,theyareanessentialcomponentof enablingin-network aggregationindiffusion,andwe plan to addthem.We intendto leverageon theability to reprogrammotesover theair [21] to programfilters dy-namically.

Motesandmicro-diffusioncanbeusedin regionswherethereisneedfor densesensordistribution,suchasdistributing photosen-sorsin a roomto detectchangein light or temperaturesensorsforfine grainedsensing.They provide thenecessarysensordatapro-cessingcapability, with theability to usediffusionto communicatewith lessresource-constrainednodes (for example,PC/104-classnodes). Motescanalsobe usedto provide additionalmulti-hopcapabilityunderadversewirelesscommunication conditions.

We thusenvisagedeploymentof a tieredarchitecturewith bothlarger and smallernodes. Lessresource-constrainednodeswillform the highesttier andact asgatewaysto the secondtier. Thesecondtier will be composed of motesconnected to low-powersensorsrunning micro-diffusion. Most of the network “intelli-gence”is programmed into the first tier. Second-tiernodeswillbecontrolledandtheir filters programmed from thesemorecapa-blenodes.

4.4 Implementation discussionWe draw two observationsfrom our experienceswith theseim-

plementations.First, therangeof diffusion implementationssug-geststhat both the ideasand the code are portablesince therearethreeindependent implementations(ourmainimplementation,micro-diffusion, and MIT-LL’s declarative routing) and our pri-mary implementationruns on multiple platforms (PC/104sandWINSng 1.0 asof June2001,with ports in progressto two newradiosand platforms). The requirements for diffusion are quitemodestin termsof CPUspeed(a 15MHz 32-bit processoris suf-ficient),memory(a few megabytessupportsdiffusion,anOS,andapplications),andradio(10–20kb/sbandwidthis sufficient). Sev-eral low-power radio designshave packet sizesassmall as30B.We requiremoderatesizepackets (100B or more)andusecodefor fragmentationandreassemblywhennecessary. Second,micro-diffusiondemonstratesthatit is possibleto implementa subsetofdiffusion on an embeddedprocessor. A common preconceptionis that fully customprotocols areneededfor embeddedsystems;theseobservationssuggest thatuseof diffusionshouldnotbepre-cludeddueto sizeor complexity.

5. APPLICATION TECHNIQ UES FORSENSORNETWORKS

We next considerapplicationtechniques in moredetail. Thesetechniquesillustratehow topology-independent low-level namingandin-network processingcanbe usedto build efficient applica-tionsfor sensornetworks.Thefirst approachweexamineis filter-drivendataaggregation, anexampleof how in-network processingcanreducedatatraffic to conserve energy. We alsoconsider twoapproaches to provide nestedquerieswhereonesensorcuesan-other. Finally, we briefly describeseveral otherapplicationsthathave beenimplemented.

5.1 In-network data aggregationAn anticipatedsensorapplicationis to querya field of sensors

andthentakesomeactionwhenoneor moreof thesensorsis acti-vated.For example,asurveillancesystemcouldnotify a biologistif an animalentersa region. Coverageof deployed sensorswilloverlap to ensurerobust coverage,so oneevent will likely trig-germultiple sensors.All sensorswill reportdetectionto theuser,but communicationandenergy costscanbereducedif thisdataisaggregatedasit returnsto the user. Datacanbe aggregatedto abinary value(therewasa detection),an area(therewasa detec-tion in quadrant 2), or with someapplication-specificaggregation(seismicandinfraredsensorsindicate80%chanceof detection).

Althoughdetailsof aggregationcanbeapplication-specific, thecommonsystemsproblem is the designof mechanismsfor es-tablishingdatadisseminationpathsto the sensorswithin the re-gion, and for aggregating responses. Considerhow one mightimplementthis kind of datafusion in a traditionalnetwork withtopologically-assigned low-level nodenames. First, in order todeterminewhich sensorsarepresentin a given region, a bindingservicemust exist which, given a geographical region, lists thenodeidentifiersof sensorswithin that region. Oncethesesensorsare tasked, an electionalgorithmmust dynamicallyelectoneormorenetwork nodes to aggregatethedataandreturntheresulttothequerier.

Instead,our architectureallows us to realizethis usingoppor-tunisticdataaggregation.Sensorselectionandtaskingis achievedby naming nodesusing geographic attributes. As data is sentfrom the sensorsto the querier, intermediatesensorsin the re-turn path identify and cacherelevant data. This is achieved byrunningapplication-specific filters. Theseintermediatenodescanthensuppressduplicatedataby simply not propagatingit, or theymayslightly delayandaggregatedatafrom multiple sources.Wearealsoexperimentingwith influencingthe dynamicselectionofaggregationpointsto minimizeoverall datamovement.

Opportunistic dataaggregationbenefitsfrom severalaspectsofour approach. Filtersprovide a naturalapproachto inject applica-tion-specificcodeinto thenetwork. Attributenamingandmatch-ing allow thesefiltersto remaininactiveuntil triggeredby relevantdata.A commonattributesetmeansthatfilters incur no networkcoststo interactwith directoryor mappingservices.

In prior work we analyzedthe performanceof diffusion withandwithout aggregation throughsimulation[23]. In Section6.1weevaluateour implementationof thisover realsensornodesandvalidateour initial resultswith laboratorytests.

5.2 NestedqueriesReal-world eventsoftenoccurin responseto someenvironmen-

tal change.For example,a personenteringa roomis oftencorre-latedwith changesin light or motion,or a flower’s opening withthepresenceor absenceof sunlight.Multi-modal sensornetworkscanusethesecorrelationsby triggeringa secondary sensorbasedonthestatusof another, in effectnestingonequeryinsideanother.Reducingthe duty cycle of somesensorscanreduceoverall en-ergy consumption(if thesecondarysensorconsumesmoreenergythantheinitial sensor, for exampleasanaccelerometertriggeringaGPSreceiver)andnetwork traffic (for example,atriggeredimagergeneratesmuchlesstraffic thana constant video stream).Alter-natively, in-network processingmight choosethebestapplicationof a sparseresource(for example,a motion sensortriggering asteerablecamera).

user

user

b)

a)

Figure 6: Two approachesto implementing nestedqueries.Squaresare initial sensors,gray circlesare triggered sensors,and the large circle is the user. Thin dashedlines representcommunication to init ial sensors;bold lines are communica-tion to the triggered sensor.

Figure6 shows two approachesfor a userto causeonesensorto triggeranother in a network. In bothcaseswe assumesensorsknow their locationsandnot all nodescancommunicate directly.Part (a)shows adirectway to implementthis: theuserqueriestheinitial sensors(smallsquares),whenasensoris triggered,theuserqueriesthe triggeredsensor(the small gray circle). The alterna-tive shown in part (b) is a nested,two-level approachwheretheuserqueriesthe triggeredsensorwhich thensub-tasksthe initialsensors.This nestedqueryapproachgrew out of discussions withPhilippeBonnetandembeddeddatabasequeryoptimizationin hisCOUGARdatabase[5].

Theadvantageof anestedqueryis thatdatafrom theinitial sen-sorscanbeinterpreteddirectlyby thetriggeredsensor, ratherthanpassingthroughthe user. In monitoring applicationsthe initialandtriggeredsensorswould oftenbequitecloseto eachother(tocover thesamephysicalarea),while theuserwould be relativelydistant. A nestedquery localizesdatatraffic nearthe triggeringevent ratherthansendingit to thedistantuser, thusreducingnet-work traffic and latency. Sinceenergy-conservingnetworks aretypically low-bandwidth andmay be higher-latency, reductioninlatency canbesubstantial,andreductions in aggregatebandwidthto the usercan meanthe differencebetweenan overloadedandoperationalnetwork. Thechallengesfor nestedqueriesarehow torobustly matchthe initial andtriggeredsensorsandhow to selecta goodtriggeredsensorif only oneis desired.

Implementationof directqueriesisstraightforwardwith attribute-addressedsensors.The usersubscribesto datafor initial sensorsandwhensomethingis detectedherequeststhestatusof thetrig-geredsensor(eitherby subscribingor askingfor recentdata).Di-rectqueriesillustratetheutility of predefinedattributesidentifyingsensortypes.Diffusionmayalsomake useof geography to opti-mizerouting.

Nestedqueriescanbe implementedby enablingcodeat eachtriggeredsensorthat watchesfor a nestedquery. This codethensub-tasksthe relevant initial sensorsand activatesits local trig-geredsensoron demand.If multiple triggeredsensorsareaccept-ablebut thereis a reasonabledefinitionof which oneis best(per-haps,the most centralone), it can be selectedthroughan elec-

tion algorithm.Onesuchalgorithmwould have triggeredsensorsnominatethemselvesaftera randomdelayasthe “best”, inform-ing their peersof their locationandelection(this approach is in-spiredby SRM repairtimers[17]). Betterpeerscanthendisputethe claim. Useof locationasan external frameof referencede-finesa bestnode andallows timersto beweightedby distancetominimizethenumberof disputedclaims.

In Section6.2 we evaluatenestedquerieswith experimentsinour testbed.

5.3 Other applicationsIn addition to theseapproacheswe have explored at ISI, our

systemhasbeenusedby severalotherresearchefforts.ResearchersatCornellhaveusedoursystemto providecommu-

nicationbetweenanend-userdatabaseandapplicationthatrepre-sentsandvisualizesa sensorfield andqueryproxiesin eachsen-sor node [5]. This applicationusedattributesto identify sensorsrunningqueryproxiesandto passquerybyte-codesto the prox-ies. They alsooriginatedthe ideaof usinga nestedapproachfornestedqueries.Futurework includesunderstandingwhatnetworkinformation is necessary for databasequeryoptimizationandal-ternative approachesfor nestedqueries.

ResearchersatBAE SystemsandPennsylvaniaStateUniversityhave usedour systemfor collaborative signal processing. BAEsystemscontributedsignalprocessingcodeandsystemsintegra-tion, while PSUprovided sensorfusionalgorithms[8]. Thecom-binedsystemusedour systemto communicatedatabetweensen-sorsusingnameddataanddiffusion. At the time our filter archi-tecturewasnot in place;interestingfuturework is to evaluatehowsensorfusionwould bedoneasa filter.

6. EVALUATIONThe approachesdescribedin this paperareuseful if they can

be efficiently implementedandimprove the energy-efficiency ofdistributedsystemssuchassensornets.In Section5 wedescribedseveralapplicationsthatemploy thesetechniques. In this section,we measurethe benefitsof aggregation and nestedqueriesandverify raw matchingperformance.

6.1 AggregationbenefitsIn Section5.1,we arguedthat it is relatively easyto build sen-

sor network applicationsusing attribute-basednaming, and in-network filters. In earlierwork, we have observedthatin-networkaggregationis importantto theperformanceof datadiffusion[23].In this section,wevalidatetheseresultswith anactualimplemen-tation of a simple surveillanceapplicationusing attribute-basednamesandfilters.

Weexaminedin-network aggregationin ourtestbedof 14PC/104sensornodesdistributedontwo floorsof ISI (Figure7). Thesesen-sorsareconnectedby RadiometrixRPCmodems (off-the-shelf,418MHz, packet-based radiosthatprovide about13kb/s through-put) with 10dB attenuatorson the antennasto allow multi-hopcommunicationsin our relatively confinedspace.Theexacttopol-ogy variesdepending on the level of RF activity, andthenetworkis typically 5 hopsacross.

To evaluatethe effect of aggregationwe placeda sink on onesideof thetopology(“D” atnode28)andthenplaceddatasourcesontheotherside(“S” atnodes25,16,22,and13),typically 4 hopsapart. All sourcesgenerateeventsrepresentingthe detectionof

Figure 7: Node positions in our sensortestbed. Light nodes(11, 13, 16) are on the 10th floor; the remaining dark nodesareon the 11th floor. Radio rangevaries greatly depending onnodeposition,but the longeststablelink wasbetweennodes20and 25.

someobject at the rate of one event every 6 seconds. For ex-perimentrepeatabilityeventsareartificially generated,ratherthantaken from a physicalsensorandsignalprocessing.Eacheventgeneratesa 112 bytesmessageand is given sequence numbersthat aresynchronized at experiment start.2 All nodeswerecon-figuredwith aggregationfilters thatpassthefirst uniqueeventandsuppresssubsequent eventswith identicalsequencenumbers.Al-thoughthis scenarioabstractssomedetailsof a completesensornetwork (for example,real signalprocessingmay have differentsensingdelays),webelieve it capturestheessenceof thenetwork-ing component of multi-sensoraggregation.

We would like to comparethe energy expended per receivedevent.Unfortunately, wecannotmeasurethatdirectly for two rea-sons.First, we do not have hardware to directly measureenergyconsumptionin a running system. Second,we have previouslyobserved that choiceof MAC protocol cancompletelydominateenergy measurements.In low power radios,MAC protocolsthatdo not sleepperiodically are dominatedby the amountof timespentlistening, regardlessof choiceof protocol. Thus energy-consciousprotocolslikePAMAS [32] or TDMA arenecessaryforlong-livedsensornetworks. We arecurrentlyexperimenting withpower-awareMAC approaches.

Althoughwe currentlycannotmeasureenergy consumption onanappropriateMAC, we canestimatetheeffectiveness of reduc-ing traffic for MACs with differentduty cycles. A simplemodelof energy consumption is:

����� ���"!$#%!'&(�*)+#$),&(�*-.#/-where � and # define the relative power and time spentlisten-ing, receiving, and sendingand � is definedas the requiredlis-tenduty cycle (the fractionof time theradiomustbe listeningtoreceive all traffic destinedto it). We found our sensornetworkcontainedpockets of severecongestion,but in the aggregate,ra-dios listen:receive:sendtimeswereabout1:3:40. Relative energy0An operationalsensornetwork would usetimestampsinsteadof

sequencenumbers. Both requiresynchronization, but time canbe synchronized globally with GPS or NTP. We use sequencenumbersbecauseat the time of this experiment we hadnot syn-chronizedour clocks.Experimentally, otherthansynchronizationoverhead,sequencenumbersandtimestampsareequivalent.

0

500

1000

1500

2000

2500

3000

3500

0 1 2 3 4 5

Byt

es s

ent b

y di

ffusi

on

1

(per

rec

eive

d di

stin

ct e

vent

)

2

Number of Sources

With suppressionWithout suppression

Figure8: Bytessentfr om all diffusion modules,normalized tothe number of distinct events,for varying numbersof sources.

consumptionof listen:receive:sendhasbeenmeasuredat ratiosfrom 1:1.05:1.4to 1:2:2.5 [37]. For simplicity, assumeenergyconsumptionratiosof 1:2:2. With theseparameters,energy us-agefor nodeswith a duty cycle of 1 arecompletelydominatedbyenergy spentlistening.At duty cycle of 22%half of theenergy isspentlistening.Duty cyclesof 10%begin to bedominatedby sendcost.Duty cycle for mostradiostodayis 100%, but TDMA radiossuchasin WINSng nodes [29] mayhave duty cyclesof 10–15%for non-base-stations.This analysisillustratesthe importanceofenergy-conserving MAC protocols.

Sincewe cannotdirectly measureenergy per event, Figure 8measuresbytessentfrom diffusionin all nodesin thesystemnor-malizedto the numberof distinct eventsreceived. Eachpoint inthisgraphrepresentsthemeanof five30-minuteexperimentswith95% confidence intervals. Performancewith onesourceis basi-cally identicalwith andwithout suppression(this form of aggre-gation).As expected,suppression requireslessdatapereventwithmultiplesourcesthanexperimentswithoutsuppression. With sup-pressionthe amountof traffic is roughly constantregardlessofthenumberof sources.This application-specific dataaggregationshows thebenefitof in-network processing. It alsoshows thatdif-fusionis usefulfor point-to-multipointcommunication, sincetraf-fic representsbothdataandcontroltraffic. Comparingtraffic withandwithout suppressionshows thatsuppressionis ableto reducetraffic by up to 42% for four sources.The network exhibits veryhighlossratesatthatlevel of traffic. OurcurrentMAC is quiteun-sophisticated,performingonly simplecarrierdetectionandlack-ing RTS/CTS or ARQ. Sinceall messages arebroken into several27-bytefragments,lossof a singlefragmentresultsin lossof thewhole message,andhiddenterminalsareendemic to our multi-hoptopology, thisMAC performsparticularlypoorly athigh load.Wearecurrentlyworking on a betterMAC protocol.

We canconfirm theseresultswith a simpletraffic model. Weapproximateall messagesas127B long andaddtogetherinterestmessages(sentevery 60sandfloodedfrom eachnode),reinforce-mentmessages(senton thereinforcedpathbetweenthesink andeachsource),simpledatamessages(9 out of every 10 datames-sages,sentonly on the reinforcedpath,andeitheraggregatedornot), andexploratorydatamessages(1 out of every 10 datames-sages,sentfrom eachsourceandfloodedin turn from eachnode,

again possiblyaggregated). If datamessagesarenot aggregated,eachsourceincursthecostof thefull path,while if datamessagesareaggregatedafter the first hop eachincursonehop costto theaggregationpoint andthenonemessagewill travel on to thesink.Summingthe messagecostandnormalizingper event we expectaggregationto provide a flat 990B/event independentof thenum-berof sources,andweexpectbytessentpereventto increasefrom990to 3289B/eventwithout aggregationasthenumberof sourcesrisefrom 1 to 4.

The shapeof this predictionmatchesour experimental results,but in absolutetermsit underpredictsthe B/event of aggregationand overpredicts the 4-source/no-aggregation case. We believethesedifferencesaredue to MAC-layercollisions in the experi-ment that tend to drive bytes-per-event to the middle. Only 55–80% of events generatedin the experimentweredeliveredto thesink, so bytes-per-event in lesscongestedportionsof the exper-iment (with onesourceor aggregation) is high becausetraffic isnormalizedoverfewerevents. Ontheotherhand, with foursourcesand no aggregation, we believe collisions happenvery near thedatasourcesand so the aggregateamount of datasent is lowerthatpredicted.In addition,we sometimesobserve longerpathsinexperimentthanwe expected.

Theseexperimentalmeasurements of aggregationarealsouse-ful to validateourprevioussimulationexperimentsthatconsiderawider rangeof scenarios.Previoussimulationstudieshave shownthataggregationcanreduceenergy consumptionby a factorof 3–5 3 in a largenetwork (50–250nodes)with fiveactivesourcesandfive sinks(Figure6b from [23]). Although caremustbe usedincomparingenergy to bytessent,a 3–5-fold energy savings withfivesourcesis muchgreaterthanthe42%(or 1.7-fold)traffic sav-ings we observe with four sources.The primary reasonfor thisdifferenceis differencesin ratio of exploratory to datamessagesin thesesystems.Exploratorymessages(calledlow-dataratemes-sagesin [23]) areusedto selectgood gradientsandsoarefloodedto all nodes. Datamessages(calledhigh-ratemessagesin [23])aresentonly on reinforcedgradientsforming a pathbetweenthesourcesandsinks. In simulationthe ratio of exploratory to datamessagessentfrom a sourcewasabout 1:100(exploratorymes-sagesweresentevery 50s,dataevery 0.5s,messagesweremod-eled as 64B packets). In our testbedthis ratio was about 1:10(exploratory messages every 60s, dataevery 6s, with messagesof roughly the samesize). Increasingthis ratio in experimentwasnot possiblegiven our small radio bandwidth (13kb/sratherthan1.6Mb/sin simulation)while keepingreasonableexperimen-tal runningtimes.This largedifferencein ratiosis consistentwiththelargedifferencein energy or traffic savings.

A potentialdisadvantageof dataaggregation is increasedla-tency. Theeffect of aggregationon latency is stronglydependentonthespecific,application-determinedaggregationalgorithm.Thealgorithmusedin theseexperimentsdoesnot affect latency at all,sincewe forward uniqueeventsimmediatelyuponreceptionandthensuppressany additionalduplicates(incurring only the addi-tional negligible costof searchingfor duplicates). Otheraggre-gationalgorithms,suchasthosethat delay transmittinga sensorreadingwith thehopeof aggregatingreadingsfrom othersensors,canaddsomelatency. Understanding aggregationandsensorfu-sionalgorithmsis animportantareaof futurework.

Althoughwe have quantifiedthe benefitsof in-network aggre-gation in a specificapplication,aggregation is one example ofin-network processing. Otherexamplesrangefrom simpledata

0

10

20

30

40

50

60

70

80

90

0 1 2 3 4 5

audi

o ev

ents

suc

cesf

ully

del

iver

ed (

%)

4

number of light sensors

1-level2-level

Figure 9: Percentageof audio eventssuccessfullydelivered tothe user.

cachingto collaborative signal processing. As our experimentsshow, not only do attributematchingandfiltersmake aggregationandsimilar serviceseasyto provide, they alsoenablenoticeableperformance improvements.

6.2 Nestedquery benefitsIn Section5.2 we suggestedthat nestedqueriescould reduce

network costsandlatency, andwearguedthatnestedqueriescouldbeimplementedusingattributesandfilters. To validateour claimabout the potentialperformance benefitsof this implementationwe measurethe performanceof an applicationthat usesnestedqueriesagainstonethatdoesnot.

The applicationis similar to that describedin Section5.2 andFigure6: a userrequestsacousticdatacorrelatedwith (triggeredby) light sensors. We reuseour PC/104testbedshown in Fig-ure 7 placing the user“U” at node39, the audio sensor“A” atnode20, andlight sensors“L” at nodes16, 25, 22, and13. It isonehop from the light sensorsto theaudiosensor, andtwo hopsfrom thereto theusernode.To provide areproducible experimentwe simulatelight datato changeautomaticallyevery minuteonthe minute. Light sensorsreport their stateevery 2s (no specialattemptis madeto synchronizeor unsynchronizesensors).Audiosensorsgeneratesimulatedaudiodataeachtime any light sensorchangesstate.Light andaudiodatamessagesareabout100byteslong.

Figure9 shows the percentageof light changeevents that suc-cessfullyresult in audiodatadeliveredto the user. (Datapointsrepresentthemeanof three20-minuteexperimentsandshow 95%confidence intervals.) Thetotal numberof possibleeventsarethenumber of times all light sourceschange stateand a successfulevent is audio datadelivered to the user. Thesedelivery ratesdo not reflect per-hop messagedelivery rates(which are muchhigher),but ratherthecumulativeeffectof sendingbest-effort dataacrossthreeor five hopsfor nestedor flat queries,respectively.

This systemis very congested,and as describedabove (Sec-tion 6.1), our primitive MAC protocolexaggeratesthe impactofcongestion. Missing eventstranslateinto increaseddetectionla-tency. Althoughasensornetwork couldafford to missafew events(sincethey would be retransmittedin the next time the sensorismeasured),theseloss ratesare unacceptably high for an opera-

SetA: interest SetB: dataclassIS interest classIS datataskEQ“detectAnimal” taskIS “detectAnimal”confidenceGT 50 confidence IS 90latitudeGE10.0 latitudeIS 20.0latitudeLE 100.0 longitudeIS 80.0longitudeGE5.0 target IS “4-leg”longitudeLE 95.0target IS “4-leg”

Figure10: Attrib utesusedfor matching experiments.

tionalsystem.However, this experimentsharplycontraststhe bandwidthre-

quirementsof nestedandflat queries. Even with onesensortheflat query shows significantlygreaterloss than the nestedquerybecauseboth light and audiodatamust travel to the user. Bothflat andnestedqueriessuffer greaterlosswhenmoresensorsarepresent,but the one-level query falls off further. Comparingthedelivery ratesof nestedquerieswith one-level queriesshows thatlocalizing the datato the sensorsis very important to parsimo-nious useof bandwidth. In an uncongestednetwork we expectthat nestedquerieswould allow operationwith a lower level ofdatatraffic thanone-level queriesandsowould allow a lower ra-dio duty cycle anda longernetwork lifetime.

6.3 Run-time costsof matchingAttribute matchingis usedin all communication betweensen-

sors,filters, and applicationsin our system. Although technol-ogy trendssuggestrapid improvementin processorperformance,price,andsize,sensornodesmaychoseto hold performancecon-stantandleveragetechnology throughreducedprice andsize,sorun-timeperformancemustbeconsidered. A secondconstraintismemorystorage,particularlyin very smallimplementations.

To evaluatematchingperformancewe examinedthe cost ofmatchingdatafrom asensor. Thebasicmatchingin thatcasecom-paresan8-elementinterestagainsta6-elementdata(attributesareshown in Figure10). To evaluatethe costof larger dataobjectswe increasedthenumberof attributesin thedatafrom 6 to 30 at-tributes. This experimentwasdoneon our PC/104sensornodewith a66MHzAMD 486-classCPU.To evaluatethecostof asin-glematchwe measuredcostof many matches(5000for matchingor 10,000for thenon-matchingcase)in a loopandnormalized,re-peatingthis experiment 1000 timesto avoid unduesystemeffectssuchasinterrupts.The orderof attributesin eachsetis random-izedeachexperiment.Wealsoshow 95%confidence intervals,al-thoughthey arealwayslessthan5%of themean.Althoughmem-ory cachingwill causethis approachto underestimatethecostofamatch,thebasictrendsit identifiesshouldbeapplicableto oper-ationalsystems.

Our expectationis that the costof matchingis linear with thenumberof elements.This is confirmedin Figure11 that showsthe costof matchingasthe numberof attributesin oneattributesetincreasesin differentways.Thetwo lowestlines(no-match/ISand no-match/EQ)show the casewhereone of the attributesinsetA is notmatchedby thosein setB (specifically, theconfidencevaluein setB is changed from 90 to 10). Becausethe two-waymatchingalgorithmteststheformalsin setA first, theincrementalcostof additionalattributesin set B is fairly small in this case,and it is insensitive to the type of attribute added. If the failingformal wasin setB we would expectthe costto be higher(mid-

0

100

200

300

400

500

600

700

800

900

0 5 10 15 20 25 30 35

uSec

per

mat

ch

4

number of attributes in set B

match/ISmatch/EQ

no-match/ISno-match/EQ

Figure11: Matching performanceasthe number of attrib utesgrow.

way betweenthemeasureddata).The two higher lines (match/ISandmatch/EQ)show the cost

of matchingwhenall attributessucceed.The differencein costof additionalattributesin theselinesshows thecostof additionalmatching. In the match/EQline all additionalattributesare for-mals(additionsof the “classEQ interest”attribute),soeachnewattributemustbematchedagainstsetA. For match/IS,additionalattributesareactuals(repetitionsof ‘extra IS “foo” ’) thatmustbeexaminedbut do not requiresearching.

Althoughourcurrentimplementationiscompletelyunoptimized,theabsolute performanceof theseoperationsis quite reasonable.At 5005 s/match for small attribute setsour quite slow PC/104canmatch2000setsper second. Although quite slow by Inter-netrouterstandards,this is reasonablefor sensornetworkswherewe expecthigh-level eventsto happen with frequenciesof 10Hzor less.

Finally, thesemeasurementssuggestseveralpotentialoptimiza-tionsto matchingperformance. Segregatingactualsfrom formalscanreducesearchtime(sinceformalscannotmatchotherformalsthereis noneedto comparethem).Attributescouldbestaticallyordynamicallyoptimizedto move theattributesleastlikely to matchto thefront. Weplanto explorethesekindsof optimizationsin thefuture.

6.4 Experiment DiscussionTheseexperimentshave provided new insight into sensornet-

work operation,buildingsubstantially onourprior simulationstud-ies[23].

Theseexperimentsarefirst examinationof nestedqueriesandmatchingperformance. They suggestthat the CPU overhead ofmatchingshouldnot bea constraintfor reasonablypowerful sen-sornodesandthatnestedqueriescangreatlyreducecontention bylocalizingdatamovement.

Theseexperimentshaveexploredlow-bandwidthoperation.Pre-vious simulationstudiesof sensornetworks often have not usedthe low-bandwidth radioswe seein actualsensor-network hard-ware. Protocolsand scenariosbehave qualitatively different at10–20kb/sfor sensor networksratherthanthe3–12Mb/scommonto wireless802.11LANs. Even with our early operationalexpe-riencein small-scaledemonstrationsandtesting,we did not ap-

preciate� thedifficulty of operatinga 14-nodesensornetwork at arelatively high utilization. Our observationssuggesttwo areasoffuturework: first, sensornetworks mustadaptto local nodeden-sities(we arebeginning to explore this area[11]). Second,morework is neededto understandhow diffusion’s parametersmaptodifferentneeds,particularlythe trade-offs betweenoverheadandreliability presentin the frequency of exploratory messages,in-terests,andreinforcements. Finally, thediffusionapplicationswecurrentlyuseoperatein an openloop; feedbackand congestioncontrolareneeded.

Two aspectsof radiopropagationprovedunexpectedlydifficult.First, someexperimentsseemedto show asymmetriclinks (com-municationwas fine in one direction but poor or impossibleintheother).Diffusiondoesnot currentlywork well with asymmet-ric links; we areconsideringhow to bestrevise it. Second,somelinks provided only intermittentconnectivity. A future directionfor diffusion might sendsimilar dataover multiple pathsto gainrobustnesswhenfacedwith low-quality links. Currentsimulationmodels,evenwith statisticalnoise,do notadequatelyreflecttheseobservedpropagationcharacteristics.

Finally, weweregenerallyhappy with ourapproach to attributenamingandfilters. It wasreasonablyeasyto build andadaptoursampleapplicationsanddebuggingsoftware.

7. FUTURE WORKThiswork describesourcurrentapproachto constructingrobust

distributedsensornetworksfor afew applications.It suggestssev-eralareasfor futurework includingenhancingourtestbedandpro-tocols,applyingthemto additionalapplications,andunderstand-ing how to build sensornetworks.

Wehaveseveralplanned changesto ourtestbedhardware.Mostimportantly, we plan to move to a different radio by RF Mono-lithicsandtouseaUCBMoteasthepacket controller. Thepacket-level controllerof ourRadiometrixRPCwasveryhelpful for rapiddevelopment,but this revisedapproachwill giveuscompletecon-trol over theMAC protocol.

We have now exploreddiffusion performanceboth in simula-tion andwith testbedexperiments. In-network aggregationshowsqualitatively thesameresultsin bothevaluations(Section6.1). Anext stepis to usetheexperimentsto parametrizethesimulations.

In this work we were repeatedlychallenged by the difficultyin understanding what was going on in a network of dozens ofphysicallydistributednodes.Our currentenvironment augmentsthe radio network with a separatewired network for experimen-tal datacollection,but muchmorework is neededin developinganalysistools for thesenetworks. Tools areneededto report thechanging radio topology, observe collision ratesandenergy con-sumption,permit moreflexible logging, andaccuratelysynchro-nizenodeclocks.We have begunwork on in-network monitoringtools[40], but morework is needed.

AppropriateMAC protocolsfor sensornetworks is a continu-ing challenge. In spiteof publishedwork in this area[3, 33] andongoing activities,a freelyavailable,energy awareMAC protocolremainsneeded. We andothersarecurrently exploring alterna-tiveshere;we hopesolutionswill beforthcoming.

A balanceof controlanddatatraffic is particularlyimportantinbandwidth-constrainedsystemssuchassensornetworks. Severalknown techniques to constraincontrol traffic exist for soft-stateprotocolsin wired networks [24, 31, 36]; theseapproachesneed

to beappliedto our system.Wehave exploredtwo applicationsof sensornetworksandcol-

laboratedon other applications,but many other applicationsre-main. One interestingdirection is to explore how collaborativesignalprocessing interactswith in-network processingandfilters.

Finally, althoughwe focus on wirelesssensornetworks, thetechniqueswedeveloparealsorelevantto wiredsensornetworks.Wired connections greatlyreducebandwidth constraintsandandeliminatepower constraints,but attribute-basednamingcan re-ducesystemcomplexity by decouplingdatasourcesandsinks,andin-network processingmay reducelatency andimprove scalabil-ity. Although prior systemshave separatelyusedtheseabstrac-tionsfor virtual informationsystems,a futuredirectionis to applythem to large, wired sensornetworks that are coupledwith thephysicalworld.

8. CONCLUSIONThis paper has describedan approachto distributed systems

built around attribute-nameddataandin-network processing. Byusing attributeswith externalmeaning(suchas sensortype andgeographic location)at the lowest levels of communication, thisapproach avoidsmultiple levelsof namebindingcommonto otherapproaches.Attribute-nameddatain turn enablesin-network pro-cessingwith filters, supporting dataaggregation, nestedqueriesand similar techniquesthat arecritical to reducenetwork trafficandconserveenergy. Weevaluatedtheeffectivenessof thesetech-niquesby quantifying the benefitsof in-network processingfordataaggregationandnestedqueries.In oneexperiment we foundthat aggregationreducestraffic by up to 42% andnestedqueriesreducesloss ratesby 15–30%. Although aggregationhasprevi-ously beenstudiedin simulation,theseexperiments are the firstevaluationof thesetechniques in an operational testbed. Theseapproachesareimportantin theemergingdomainof wirelesssen-sor networks wherenetwork andpower resourceconstraintsarefundamental.

AcknowledgmentsWe would like to thankDanCoffin for his work definingthenet-work routingAPIs. VanJacobson firstsuggestedapplyingdirecteddiffusionto sensornetworks.

Many people participatedin developingourPC/104testbed,in-cluding Alberto Cerpa,JeremyElson,Lewis Girod, MohammadRahimi,andJerryZhao.In particular, we thankJerryZhaofor hishelpon settingup debug stationsandPC/104s,andJeremyElsonfor his promptmodificationof the RPCdevice driver. The mea-surementsin thispaperwould havebeenimpossiblewithoutall oftheir input.

Wewouldalsoliketo thanktheTinyOSgroup(http://tinyos.millennium.berkeley.edu) at UC Berkeley for their supportwith TinyOSandMotes.

Thediscussionin this paperbenefitted from contributionsfromnumerous people,including Philippe Bonnet, Brian Noble (ourpapershepherd),andthemany SOSPreviewers.

9. REFERENCES[1] W. Adjie-Winoto,E. Schwartz, H. Balakrishnan, andJ.Lilley. The

designandimplementationof anintentional namingsystem.InProceedingsof the17thSymposiumon Operating SystemsPrinciples, pages186–201, Kiawah Island, SC,USA, Dec.1999.ACM.

[2]6 E. Amir, S.McCanne,andR. H. Katz.An active serviceframeworkandits application to real-time multimedia transcoding.InProceedingsof theACM SIGCOMMConference, pages178–189,Vancouver, Canada,Sept. 1998.ACM.

[3] F. Bennett,D. Clarke,J.B. Evans,A. Hopper, A. Jones,andD. Leask.Piconet: Embeddedmobilenetworking. IEEEPersonalCommunicationsMagazine, 4(5):8–15, Oct.1997.

[4] K. P. Birman. Theprocessgroupapproach to reliabledistributedcomputing. Communicationsof theACM, 36(12):36–53,Dec.1993.

[5] P. Bonnet, J.Gehrke, T. Mayr, andP. Seshadri. Queryprocessingina device databasesystem.Technical ReportTR99-1775,CornellUniversity, Oct.1999.

[6] M. Bowman,S.K. Debray, andL. L. Peterson. Reasoning aboutnamingsystems.ACM Transactionson ProgrammingLanguagesandSystems, 15(5):795–825,Nov. 1993.

[7] J.Broch,D. A. Maltz, D. B. Johnson,Y.-C. Hu, andJ.Jetcheva.Aperformance comparision of multi-hopwirelessadhocnetworkroutingprotocols. In Proceedingsof theACM/IEEEInternationalConference on Mobile Computing andNetworking, pages85–97,Dallas,Texas,USA, Oct.1998.ACM.

[8] R. R. BrooksandS.S.Iyengar. Robustdistributedcomputing andsensingalgorithm. IEEEComputer, 29(6):53–60,June1996.

[9] N. Carriero andD. Gelernter. TheS/Net’s Linda kernel. InProceedingsof theTenthSymposiumon Operating SystemsPrinciples, pages110–129.ACM, Dec.1985.

[10] CCITT. Thedirectory: Overview of concepts,modelsandservice.Recommendation X.500,CCITT, 1988.

[11] A. Cerpa,J.Elson,D. Estrin,L. Girod,M. Hamilton,andJ.Zhao.Habitat monitoring: Applicationdriver for wirelesscommunicationstechnology. In Proceedingsof theACM SIGCOMMWorkshoponData Communicationsin Latin AmericaandtheCaribbean, SanJose,CostaRica, Apr. 2001.ACM.

[12] I. Clarke, O. Sandberg, B. Wiley, andT. W. Hong.Freenet: Adistributedanonymousinformation storageretrieval system.InProceedingsof theICSI Workshopon DesignIssuesin AnonymityandUnobservability , Berkeley, CA, USA, July 2000.

[13] D. Coffin, D. V. Hook,R. Govindan, J.Heidemann,andF. Silva.NetworkRoutingApplication Programmer’s Interface(API) andWalk Through. MIT/LL andUSC/ISI,Dec.2000.

[14] D. A. Coffin, D. J.V. Hook,S.M. McGarry, andS.R. Kolek.Declarative ad-hocsensornetworking. In Proceedingsof theSPIEIntegratedCommandEnvironmentsConference, SanDiego,California,USA, July 2000.SPIE.(partof SPIEInternationalSymposiumon Optical Science andTechnology).

[15] S.E. Czerwinski, B. Y. Zhao,T. D. Hodes,A. D. Joseph,andR. H.Katz.An architecturefor a secureservice discovery service. InProceedingsof theACM/IEEEInternational Conferenceon MobileComputing andNetworking, pages24–35,Seattle, WA, USA, Aug.1999.ACM.

[16] J.ElsonandD. Estrin.Random,ephemeraltransaction identifiersindynamicsensornetworks. In Proceedingsof theInternationalConference on Distributed Computing Systems, pages459–468,Phoenix,Arizona,USA, Apr. 2001.IEEE.

[17] S.Floyd andV. Jacobson.Link-sharing andresourcemanagementmodelsfor packet networks.ACM/IEEETransactionsonNetworking, 3(4):365–386,Aug. 1995.

[18] V. Fuller, T. Li, J.Yu, andK. Varadhan. Classlessinter-domainrouting(CIDR): anaddressassignmentandaggregationstrategy.RFC1519,Internet RequestFor Comments,Sept.1993.

[19] W. R. Heinzelman,A. Chandrakasan,andH. Balakrishnan.Energy-efficient communication protocols for wirelessmicrosensornetworks.In Proceedingsof theHawaii International Conferenceon SystemsSciences, Jan.2000.

[20] W. R. Heinzelman,J.Kulik, andH. Balakrishnan. Adaptiveprotocols for information dissemination in wirelesssensornetworks.In Proceedingsof theACM/IEEEInternationalConference on Mobile Computing andNetworking, pages174–185,Seattle,WA, USA, Aug. 1999.ACM.

[21] J.Hill, R. Szewczyk, A. Woo,S.Hollar, D. Culler, andK. Pister.Systemarchitecturedirectionsfor network sensors.In Proceedingsof the9th International Conferenceon Architectural SupportforProgrammingLanguagesandOperating Systems, pages93–104,Cambridge, MA, USA, Nov. 2000.ACM.

[22] T. Imielinski andS.Goel.DataSpace:QueryingandMonitoringDeeplyNetworkedCollectionsin PhysicalSpace. IEEEPersonalCommunications.Special Issueon SmartSpacesandEnvironments,7(5):4–9,October2000.

[23] C. Intanagonwiwat, R. Govindan, andD. Estrin.Directeddiffusion:A scalable androbustcommunication paradigm for sensornetworks. In Proceedingsof theACM/IEEEInternationalConference on Mobile Computing andNetworking, pages56–67,Boston,MA, USA, Aug. 2000.ACM.

[24] V. Jacobson. CompressingTCP/IPheaders for low-speedseriallinks. RFC1144,InternetRequestFor Comments,Feb. 1990.

[25] S.Michel, K. Nguyen, A. Rosenstein, L. Zhang,S.Floyd, andV. Jacobson. Adaptive webcaching: Towardsa new global cachingarchitecture. In Proceedingsof the3rd International World WideWebConference, Manchester, England, June1998.

[26] P. Mockapetris.Domainnames—conceptsandfaciliti es.RFC1034,Internet RequestFor Comments,Nov. 1987.

[27] B. Oki, M. Pfluegl, A. Siegel, andD. Skeen.Theinformationbus—anarchitecturefor extensibledistributedsystems.InProceedingsof the14thSymposiumon Operating SystemsPrinciples, pages58–68,Ashevil le, North Carolina,USC,Dec.1993.ACM.

[28] L. L. Peterson.A yellow-pagesservicefor a local-areanetwork.Proceedingsof theACM SIGCOMMConference’87, pages235–242,Aug. 1987.

[29] G. J.PottieandW. J.Kaiser. Embeddingtheinternet: wirelessintegratednetwork sensors.Communicationsof theACM,43(5):51–58,May 2000.

[30] Y. Rekhter, P. Lothberg, R. Hinden,S.Deering, andJ.Postel. AnIPv6 provider-basedunicastaddressformat.RFC2073,InternetRequestFor Comments,Jan.1997.

[31] P. Sharma,D. Estrin,S.Floyd, andV. Jacobson.Scalable timersforsoft stateprotocols. In Proceedingsof theIEEEInfocom, Kobe,Japan,Apr. 1997.IEEE.

[32] S.SinghandC. Raghavendra. PAMAS: Power aware multi-accessprotocol with signalling for adhocnetworks.ACM ComputerCommunication Review, 28(3):5–26, July 1998.

[33] K. Sohrabi,J.Gao,V. Ailawadhi,andG. Pottie.A self-organizingsensornetwork. In Proceedingsof the37thAllerton Conference onCommunication, Control, andComputing, Monticello, Ill ., USA,Sept.1999.

[34] D. L. Tennenhouse,J.M. Smith,W. D. Sincoskie,D. J.Wetherall,andG. J.Minden. A survey of active network research. IEEECommunicationsMagazine, 35(1):80–86,Jan.1997.

[35] J.Waldo.TheJini architecturefor network-centric computing.Communicationsof theACM, 42(10):76–82,Oct.1999.

[36] L. Wang,A. Terzis,andL. Zhang.A new proposalfor RSVPrefreshes. In Proceedingsof theIEEEInternational ConferenceonNetworkProtocols, Toronto,Canada, Oct.1999.IEEE.

[37] Y. Xu, J.Heidemann, andD. Estrin.Geography-informedenergyconservation for adhocrouting. In Proceedingsof theACM/IEEEInternational Conferenceon Mobile Computing andNetworking,pages70–84, Rome,Italy, July 2001.ACM.

[38] W. Yeong, T. Howes,andS.Kille. Lightweight directory accessprotocol. RFC1777,InternetRequestFor Comments,Mar. 1995.

[39] Y. Yu, D. Estrin,andR. Govindan.Geographical andenergy-awareroutingfor wirelesssensornetworks: A recursive datadissemination protocol. Work in Progress,Mar. 2001.

[40] Y. Zhao,R. Govindan,andD. Estrin.Residual energy scansformonitoring wirelesssensornetworks.Technical Report01-745,May 2001.