DAIS: Enabling Declarative Applications in Immersive Sensor NetworksTR - PDF document

DAIS: Enabling Declarative Applications in Immersive Sensor NetworksTR-UTEDGE-2006-000 ©Copyright 2006 [23]L.Neitzel,S.Seixas,andK.Ren.Areviewofcranesafetyintheconstructionindustry.AppliedOccupationalandEnvironmentalHygiene,16(12):1106{1117,2001.[24]M.Puccio.Enhancingcranesafety:Digitallycompensatedtiltsensors.SensorsMagazine,20(9),2003.[25]HuangQ,C.Lu,andG.-C.Roman.Spatiotemporalmulticastinsensornetworks.InProc.ofthe1stInt'l.Conf.onEmbeddedNetworkedSensorSystems,pages205{217,2003.[26]A.Ranganathan,S.Chetan,J.Al-Muhtadi,R.Campbell,andM.D.Mickunas.Olympus:Ahigh-levelprogrammingmodelforpervasivecomputingenvironments.InProc.ofthe3rdInt'l.Conf.onPervasiveComputingandCommunications,2005.[27]G.-C.Roman,C.Julien,andQ.Huang.Networkabstractionsforcontext-awaremobilecomputing.InProc.inthe24thInt'l.Conf.onSoftwareEngineering,pages363{373,2002.[28]M.Roman,C.Hess,R.Cerqueira,A.Ranganathan,R.Campbell,andK.Narstedt.Amiddlewareinfrastructureforactivespaces.IEEEPervasiveComputing,1(4):74{83,2002.[29]K.Romer,O.Kasten,andF.Mattern.Middlewarechallengesforwirelesssensornetworks.ACMSIGMOBILEMobileComputingandCommunicationsReview,6(4):59{61,2002.[30]N.Shrivastava,C.Burgohain,D.Agrawal,andS.Suri.Mediansandbeyond:Newaggregationtechniquesforsensornetworks.InProc.ofthe2ndInt'l.Conf.onEmbeddedNetworkedSensorSystems,pages239{249,2004.[31]M.Weiser.Thecomputerforthetwenty-rstcentury.ScienticAmerican,265(3):94{101,1991.[32]M.WelshandG.Mainland.Programmingsensornetworksusingabstractregions.InProc.ofthe1stUSENIX/ACMSymp.onNetworkedSystemsDesignandImplementation,2004.[33]K.Whitehouse,C.Sharp,E.Brewer,andD.Culler.Hood:Aneighborhoodabstractionforsensornetworks.InProc.ofthe2ndInt'l.Conf.onMobileSystems,Applications,andServices,pages99{110,2004.[34]Y.YaoandJ.Gehrke.Thecougarapproachtoin-networkqueryprocessinginsensornetworks.ACMSIGMODRecord,31(3):9{18,2002.[35]Y.Yu,B.Krishnamachari,andV.K.Pasanna.Issuesindesigningmiddlewareforwirelesssensornetworks.IEEENetwork,18(1):15{21,2004.20 theSceneMmodulemustmonitorchangesinthescenemembershipthatmightcauseittonolongerbeamember.Forexample,ifthesceneisdenedbyrelativelocation,andtheuseriswalkingthroughthesensornetwork,ashemovespastthesensorandfurtheron,thesensorwillneedtoberemovedfromthescene.Toaccomplishthis,thescenemustmonitorincomingbeaconmessagesforthisscenefromtheparent(asindicatedbythepreviousHopeldinthemessage).SuchmessagesarealsoreceivedinSceneMthroughtheReceiveMsginterface.SceneMpassesthemtotheMonitormodulethroughtheMonitorMsginterface.TheMonitormoduleusesincomingbeaconmessagesfromtheparent,informationaboutthescene(fromtheinitialmessage),andinformationfromthecontextsourcestomonitorwhetherthisnoderemainsinthescene.Inaddition,theMonitorTimerrequiresthatthenodehasheardabeaconfromtheparentatleastonceinthelastthreebeaconintervals.Ifeithertheparenthasnotbeenheardfromorthereceivedbeaconpushesthenodeoutofthescene,theMonitormodulegeneratesaneventthatishandledbytheSceneMmodulethatultimatelyceasesthenode'sparticipationinthescene.ThisincludessignalingareceiveeventontheReceiveinterfaceconnectiontotheQueryProcessor.ThiseventpassesanullmessagethatindicatestotheQueryProcessortoceaseevaluatingthenotedpersistentquery.Finally,theBeaconmoduleshowninFigure9isalsoactivatedwhenapersistentqueryisreceived.Thismoduleperiodicallytransmitsanupdateforthisnode'smetricvalueforthescene.AstheMonitormoduledetectschangesinthemetricvalue(basedonthemessagesfromitsparent),themetricvalueisupdated(throughtheSceneMmodule).WhentheMonitormoduledetectsthatthenodeisnolongerpartoftheuser'sscene,theSceneMmoduleshutsdowntheBeaconmodule.ProcessingQueries.OncetheSceneMmoduledescribedabovedeterminesthatthenodeisinthescene,itpassesthereceivedmessagetotheQueryProcessorcomponentshowninFigure11. Figure11.ImplementationoftheQueryProcessorfunctionalityonsensorsInourinitialimplementation,thiscomponentimplementsthefunctionalityshownatthetoplayerofthesensorportionofthearchitectureinFigure2.ThedatarequestmessagearrivesintheQueryProcessorthroughthereceiveeventoftheReceiveinterface.Ifthequeryisaone-timequery(i.e.,ifthepersistent aginthemessageisfalse),thentheQueryProcessorsimplyconnectstotheon-boardsensorthatcanprovidetherequesteddatatype(depictedasSensorinthegure)throughtheADC16 Figure8.SimpliedobjectdiagramforDAISquery,atablewithintheSceneViewisupdatedwithamappingfromauniquequeryidgeneratedforthequerytotheResultListenerhandleprovidedwiththequery.Inaddition,forpersistentqueries,thisuniqueidisreturnedtotheapplicationasareceiptofregistrationthatcanbeusedinsubsequentinteractionstoderegisterthequeryassociatedwiththeparticularuniqueid.Whentheunderlyingprotocolimplementation(accessedthroughtheStrategypatterndescribednext)returnsaresulttoaquery,theQueryResultisforwardedtotheSceneView,whichusesitslocaldatastructuretomaketheQueryResultbacktotheappropriateResultListener,basedontheuniquequeryidreferencedintheQueryResult.TheResultListenerthenpassestheresultbacktotheapplicationbyinvokingtheresultReceivedmethodintheResultListenerinterface.Thelocaldataproxies(i.e.,theQueryandQueryResult)mediatebetweentheSceneandtheSceneViewAPIsandtheprotocolimplementationsthatunderliethemiddleware.AsshowninFigure8,multiplequeriesmaybeactiveoverasinglesceneatanygiventime.Foreachscene,theSceneViewcontrolsallofthesequeriesandconnectsthemtotheunderlyingimplementationviathestrategypatterninterface.4.2StrategyPatternInterfaceInourmiddleware,wemakeuseofthestrategypattern[7].Thestrategypatternisaparticularsoftwaredesignpattern,wherealgorithms(suchasstrategiesforquerydissemination)canbechosenatruntimedependingonsystemconditions.Thestrategypatternprovidesameanstodeneafamilyofalgorithms,encapsulateeachoneasanobject,andmaketheminterchangeable.Suchanapproachallowsthealgorithmstovaryindependentlyfromclientsthatusethem.FortheDAISmiddleware,theclientsthatemploythestrategiesarethequeries,andthedierentstrategiesaretheSceneStrategyalgorithmsThesealgorithmsdeterminehowaQueryisdisseminatedtotheSceneandhowtheQueryResultisreturnedfromtheScene.Ifaparticularquerydissemina-tionalgorithmotherthanthedefaultalgorithmisrequiredforaspecicapplication,anappropriateSceneStrategyalgorithmisinstantiatedandpluggedintotheSceneStrategy.Twoprincipledirectivesofobject-orienteddesignareusedinthestrategypattern:Encapsulatetheconceptthatvaries.12 Operation Description protectedSceneView() Theconstructorispackageprotectedbecausetheonly accesstoaSceneViewisthroughitsassociatedScene. voidsendQuery(Queryq, Sendsaone-timequerytotheScene.Theresultlistener ResultListenerr) receivesresultsfromthisquery. intregisterQuery(Queryq, RegistersapersistentqueryontheScene.Thefrequency ResultListenerr, indicateshowoftenreadingscomefromeachqualied intfrequency) sensorinthescene.Themethodreturnsareceiptthatcan beusedtocanceltheregistrationwhendesired. voidsendAggQuery(Queryq, Sendsaone-timequery,requestingin-networkaggregation. ResultListenerr, Theuserprovidestheaggregationfunction. Aggregatora) intregisterAggQuery(Queryq, RegistersapersistentqueryontheScene,requestingin- ResultListenerr, networkaggregation.Theuserprovidestheaggregation intfrequency, function.Themethodreturnsareceiptthatcanbeused Aggregatora) tocanceltheregistrationwhendesired. voidderegisterQuery(intreceipt) Stopstheregisteredqueryreferencedbythereceipt. Figure7.SceneViewAPIoperationsregisterAggQuery:Theapplicationasksfortheaveragetemperaturefromconcretesensorsinthesceneeveryveminutes.(Theprotocolrealizingsuchaquerymaydierfordierentfrequencies.Forhigh-frequencyqueries,itwilllikelymakesensetopushtheproactivenesstothesensors.Forlow-frequencyqueries,i.e.,ontheorderofminutes,itmaybemoreecienttosendaone-timequeryeachtimesincetheexpenseofmaintainingthescenewillnotbeamortizedovermanyresults,especiallyiftheuserissignicantlymobile.)Eachqueryisdispatchedtoeverynodethatiswithinthesceneandeverynoderespondstoeachquery.Themiddlewareimplementationofthisquerymodelincludesthreeadditionalabstractions:theQueryobject,theQueryResultobject,andtheResultListenerobject.ThedeclarativespecicationofaQueryallowstheprogrammertodescribethedatahewants,withoutrequiringhimtospecifyhowitshouldbeobtained.Therefore,thequeryprocessinglayercanchangehowitrunsaquery,withoutrequiringthequeryitselftobechanged,whichwillbeexplainedinSection4.Inourinitialprototype,aQueryprovidesadeclarationofasimpledatatypeprovidedbyasensor.Toeasetheprogrammingtask,thetypesenabledarebuilt-inasconstantswithinthemiddleware,sobuildingaqueryisaseasyasselectingaMetricforthescene.Morecomplicateddatatypesareconstructedusingthevirtualsensors(describedbrie yearlier),whichareoutsidethescopeofthispaper.Forexample,asinglesensormayprovidetemperatureorlocationinformation,whileavirtualsensorcanprovidethecombinationofhtemperature,locationi.Withinthemiddleware,eachdatatypemustalsodenehoweachstyleofaggregationisperformedonthetype(e.g.,whatitmeanstoaveragetheparticulartypeofdata).Forthemostcommoncases(e.g.,numericaldatavalues),thesedenitionsareprovidedinthedatatypebaseclass.Whileweomitthespecicsforbrevity,theinterfaceforintroducingnewdatatypes(aswellastheinterfacesforintroducingnewaggregatorsornewmetrics)arequitesimpleandmakeeveryeorttoguideanoviceprogrammerincreatingcorrectconstructs.AResultListenerisregisteredtoreceivetheresultsofeachquery.Whentheresultisready,themiddlewarecallstheresultReceived(QueryResult)methodfortheresultlistenerstoforwardtheresultstotheapplication.Thisachievesanasynchronousandnonblockingimplementation,sothattheapplicationcanperformothertasksincasenoresponsecomesbacktothequeryortheresponseforthequeryisdelayed.10 (a) (b)Figure4.Accuracyoflocation-basedScenecalculationsnetworkwaslargelydisconnected,soourapproachdidnotmissmanyconnectedscenemembers.Totherightofthevalley,thenetworkwasmuchmoreconnected,andthedirectapproachisquitesuccessful.TheresultsdepictedinFigure4arguethatourapproachtendstondthevastmajorityofthemembersofasceneunderreasonableconditions.Forthisreason,DAISfavorsthesimplicityofnaturalscenespecications(describednext)overcompleteaccuracyofscenemembership.3.1.2AProgrammingInterfaceforSceneDenitionTopresentthedynamicsceneconstructtotheapplicationdeveloper,webuildasimpleAPIthatin-cludesbuilt-ingeneral-purposemetrics(e.g.,hopcount,distance,etc.)andprovidesastraightforwardmechanismfordeveloperstoinsertadditionalmetrics.Figure5showstheAPIfortheSceneclass.classScenefpublicScene(Constraints[]c);publicSceneViewgetSceneView();gFigure5.TheAPIfortheSceneclassFromtheapplication'sperspective,thesceneisadynamicdatastructurecontainingasetofqualiedsensorswhichareconstrainedasspeciedbyalistofconstraints,Constraints[],andaccessedthroughaSceneView.EachconstraintisatripleoftheformhMetricm,Aggregatora,Thresholdti,and,tobeincludedinaScene,adatasource'smetricvaluemustmeettheseconstraints.ThegetSceneView()methodprovidesaccesstothedatasourcesintheSceneandseparatesthecontentsofascenefromtheaccesstothosecontents.Thus,ausercanspecifyasceneandseamlesslyaccesstherelevantdatasources,whichmaychangeastheusermoves,withoutrequiringhimtochangehisscenedenition.Figure6showssomeexamplesofhowscenesmaybespecied.Theseexamplesincluderestrictingthescenebythemaximumnumberofhopsallowed,theminimumallowablebatterypoweroneachparticipatingnode,orthemaximumphysicaldistance.Asoneexample,SCENE HOP COUNTisametricexplicitlydenedwithintheDAISarchitecture,andithastheeectofassigningavalueofonetoeachnetworklink.Therefore,usingthebuilt-inSCENE SUMaggregator,theapplicationcanbuild8 needtobe.Consider,forexample,aconstructionsitesupervisorthatwantstomonitortheaverageconcretecurerates.Hemaychoosetolimittheconcretepadstothosethatliewithinacircleofradiusvemetersaroundhimorhemaychoosetoreceivetheaverageconcretecureratesoveralltheconcretepadsthroughouttheconstructionsite.Thesceneforthelattercasewouldbespeciedas\allconcretecureratesensorswithintheconstructionsiteboundaries."Inthisexample,\within5m"or\withintheconstructionsiteboundaries"speciesthethreshold.Fortime-sensitiveinformation,hemayneedtofurtherrestrictthesetofconcretepadsensorsheinteractswithbasedonthelatencyofthelinks.Furthermore,astheconstructionsitesupervisorwalksthroughthesite,thescenespecicationstaysthesame,butthedatasourcesbelongingtothescenemaychange.Asimilarconceptwasexploredinmobileadhocnetworksinthenetworkabstractionsmodel[27]whichallowsapplicationstoprovidemetricsoverpathsofnetworkconnectivity.Nodestowhichthereexistsapathsatisfyingthemetricareincludedinthespecier'snetworkcontext,whilethoseoutsideareexcluded.Thisapproachisoverlyexpressive,makingitdicultforthenoviceapplicationdevelopertospecifysimplemetricsusingtheprogramminginterface.Also,asitwasbuiltformorecapabledevices,itistoocomplexforoperationonlightweightsensornodes.Morerecently,similarconceptshavebeenexploredinthecontextofsensornetworks.Hood[33]allowssensornodestodeneareasaroundthemselvesbasedonhopcountsandothernetworkproperties.Coordinationisthenperformedwithinthisneighborhood.Similarly,AbstractRegions[32]allowsapplicationstodeneregionsofcoordinationbutcouplestheabstractionwithprogrammingconstructsthatallowapplicationstoissueoperationsovertheregions.Whilebothapproacheshaveshownpromiseincoordinatingtraditionalsensornetworkapplicationslikeobjecttrackingandcontournding,theapproachesarenotevaluatedwithrespecttothedynamicspresentinouroperationalenvironmentandbothrequireconstantproactivebehaviorofanysensorthatmaybelongtoaregion.Mobicast[25]denesamessagedisseminationalgorithmforpushingmessagestonodesthatfallinaregioninfrontofamovingtarget.Itprovides\just-in-timedelivery"toallownodestosleepuntiltheyneedtoreceiveamessagebypredictingthemovementpatternofthetarget.MobiQuery[20]alsosupportsspatiotemporalqueriesinawirelesssensornetworkandallowsaqueryareatorespondtoauser'sannouncedmotionprole.Thequeryareaisdenedusingspatiotemporalpropertiesprovidedbytheapplication.Thesceneconcept,ontheotherhand,seekstominimizetheoverallcommunicationcostincurredbyhavingalightweightcollectionalgorithmthatreactsdirectlytoauser'sactualmovement.3.1.1DeningScenesBasedonPhysicalCharacteristicsThemetricsusedtospecifyscenescanbedividedintotwocategories.Therstcategorydenesscenesbasedonpropertiesofnetworkpaths,eitherdenedbycharacteristicsofthelinks(e.g.,latency)orofthedevices(e.g.,batterypower).Thesecondcategorydenesscenesbasedonphysicalcharacteristicsoftheenvironment(e.g.,locationortemperature).Theabilitytoqueryanetworkbasedonsuchphysicalcharacteristicsisimportanttomanyapplications.However,theattempttouseaphysicalcharacteristicsuchaslocationtocalculatenetworkpathsisplaguedbytheC-shapednetworkproblem.ConsiderthenetworkshowninFigure3.Inthiscase,nodesAandBarewithin50metersofeachother,yetadiscoveryfromAtoBmustleavetheregionofradius50meterssurroundingAinordertondB.Theonlywaytoguaranteethateverydevicewithinadistanceradiusisdiscoveredisto oodtheentirenetwork.Thenetworkabstractionsmodel[27]directlyrecognizesthissituationandguaranteesthatitcalculatesacorrectregionbyrequiringapplications'regiondenitionstoincludemetricsthatstrictlyincreasealonganetworkpath.Absolutephysicaldistanceisnotsuchametric,sototintothismodel,itmustbecombinedwithanothermetricthatdoessatisfytherequirement(e.g.,hopcount).TheAbstractRegions[32]approachimplicitlyaddressesthisissueby6 provideindirectmeasurementsofabstractconditions(that,bythemselves,arenotphysicallymeasurable)bycombiningsenseddatafromagroupofheterogeneousphysicalsensors.Forexample,onanintelligentconstructionsite,usersmaydesirethecranestohavesafeloadindicatorsthatdetermineifacraneisexceedingitscapacity.Suchavirtualsensorwouldtakemeasurementsfromphysicalsensorsthatmonitorboomangle,load,telescopinglength,two-blockconditions,windspeed,etc.[23,24].Signalsfromtheseindividualsensorsareusedincalculationswithinthevirtualsensortodetermineifthecranehasexceededitssafeworkingload.Withthevirtualsensorsmodel,anapplicationperceivestheenvironmentthroughacombinationofphysicalandvirtualsensorsthatprovidetheapplicationwiththenecessaryinformationaboutitsenvironment.Inthispaper,wefocusnotonthedenitionofthesevirtualsensors,butonthebehavioralprogrammingabstractionsDAISprovidesforapplicationdevelopment.Werstdescribehowadeveloperdenesanimmersivesensorenvironment,wherethelocalityofinteractionsisspeciedbyanabstractioncalledthescene.Wethendetailhowprogramsdynamicallyinteractwithdatafromtheenvironmentthroughahigh-levelprogramminginterface.Thedetailsoftheunderlyingimplementationsoftheabstractions(i.e.,thelowerlevelsofFigure2andallofthecomponentson-boardthesensors)willbedescribedinSection4.3.1Scenes:DeclarativeSpecicationsofLocalInteractionsInaninstrumentedsensornetwork,auser'soperationalcontextishighlydynamic.Thatis,thesetofavailabledatasourceschangesbasedontheuser'slocationandmovement.Furthermore,ifthesensornetworkiswell-connected,theuser'sdevicewillbeabletoreachvastamountsofrawinformationthatmustbelteredtobeusable.Foranecientapproach,theapplicationmustbeabletolimitthescopeofitsinteractionstoincludeonlythedatathatmatchesitsneeds.Inourmodel,anapplication'soperatingenvironment(i.e.,thesensorswithwhichitinteracts)isencapsulatedinanabstractioncalledascene.Byitsdenition,asceneconstrainswhichparticularsensorsmayin uenceaparticularapplication.Theconstraintsmaybeonpropertiesofhosts(e.g.,batterylife),ofnetworklinks(e.g.,bandwidth),andofdata(e.g.,type).Thesetypesofconstraintsoergeneralityand exibilityandprovideahigherlevelofabstractiontotheapplicationdeveloper.Thedeclarativespecicationdeningasceneallowsanapplicationprogrammertodescribethetypeofscenehewantstocreate,withoutrequiringhimtospecifytheunderlyingdetailsofhowitshouldbeconstructed.Theprogrammeronlyneedstospecifythreeparameterstodenetheconstraints:Metric:Aquantiablepropertyofthenetworkorofthephysicalenvironmentthatdenesthecostofaconnection.Aggregator:Anaggregationfunction(suchasSUM,AVG,MIN,MAX)thatoperatesonlinkweightsinanetworkpathtocalculatethecostofthepath.Threshold:Thethresholdvaluethatthecostcalculatedforapathmustsatisfyforthatsensortobeamemberofthescene.TheuseoftheAggregatorinthisrespectisdierentfromexistingdataaggregationschemesinsensornetworks[12,21,30].Inthiscase,weareusingthesamenotionofaggregatingvaluestocalculatetheexpanseofasceneinsteadoftoconsolidatedatareadingsenroutebacktoarequester.WerevisittheuseofthisAggregatorinterfaceforamoretraditionalpurposeinSection3.2.Eventhoughthesceneconceptconveysanotionoflocality,anapplicationmaychooseitsscenetobeasexpansiveasthewholenetwork.Thatistheapplicationmaydecidehow\local"theinteractions5 adiculttask.Inimmersivesensornetworks,however,theprogrammingburdensaremagniedduetothechallengesdescribedhere.Inaddition,thedesiretoprovideend-userapplications(asopposedtomoredatabaseorienteddatacollection)increasesthedemandforapplicationsandthenumberofprogrammersthatwilldesiretoconstructthem.Thecon uenceofthesechallengesdemonstratestheneedfor exibleyetexpressiveprogrammingenvironmentsthatenableapplicationdevelopmentforimmersivesensornetworkswhilepayingcarefulattentiontoresourceconstraints.DAIS,describednext,addressestheseconcernsbyprovidingintuitiveabstractionsoftheimmersiveenvironment.3TheDAISMiddlewareModelInthissection,wediscussthehigh-levelmiddlewaremodelusedinDAIS.Figure2showstheDAISarchitecture,whichconsistsofahandheldcomponent(runningoneitheralaptoporaPDA)andtheimmersivesensorenvironment(asdenedbyacommunityofsensors). Figure2.TheDAIShigh-levelarchitecture.Theleft-handsideshowsthecomponentscomprisingthemodelonthecomponentcarriedbytheuser(e.g.,PDAorlaptop),andtheright-handsideshowstheDAIScomponentsonthesensors.AsFigure2shows,aclientapplicationrunswiththesupportoftwokeyabstractions,namelybehav-ioralprogrammingabstractionsandvirtualsensors.Throughinterfacesprovidedbythesecomponents,theapplicationdevelopernotonlydeneshisapplications'interactionenvironments,butcanalsopro-grammaticallyspecifytheirdatarequests.Thesecondofthesecomponents,virtualsensors,provideprogrammingsupportthatallowsapplicationstospecifysophisticatedaggregationmechanismsforheterogeneousdatasources.Suchvirtualsensors4 (a)Usingtoday'scapabilities,auser'squeryisphysicallydetachedfromthesensoreld.Res-olutionofthequeryreliesonacentralizedcollectionpoint,generallytherootofaroutingtreeconstructedoverthenetwork. (b)UsingDAIS,anapplicationrunningontheuser'sdevicecanseamlesslyconnecttothesensorsinthelocalregion,removingtherequirementthatphysicallydistantsensorsparticipateinthequery'sresolution.Figure1.Comparisonof(a)existingoperationalenvironmentswith(b)theoperationalenvironmentimposedbyDAIS.thatexistingcollectionbehaviorsthatsense,aggregate,andstreaminformationtoacentralcollectionpointmaystillbeusefuleveninimmersivesensornetworks,thispaperundertakesonlytheportionoftheproblemrelatedtoenablingapplications'direct,on-demandinteractions.Fromthisperspective,ourapproachfocusesonusingsensornetworkstoenablepervasivecomputingapplications,notonremotedistributedsensing.Thisstyleofinteractiondiersfromcommonusesofsensornetworks,introducingseveraluniquechallengesandheighteningexistingones:Localityofinteractions:asdescribedabove,anapplicationwilloftenwishtointeractdirectlywithlocalsensornodes.Whilethiscanbebenecialwithrespecttominimizingthecommunicationoverheadandlatency(seeFigure1),itcanalsobecumbersomewithrespecttoenablingtheapplicationtopreciselyspecifytheareafromwhichitneedstocollectinformation.Mobilityinduceddynamics:whilethesensornodesarestilllikelystationary(asinmanyotherdeployments),theapplicationinteractingwiththesensorsrunsonadevicecarriedbyausermovingamongthesensors.Therefore,thedevice'sconnectionstoparticularsensorsandtheareafromwhichtheapplicationdesirestodrawinformationaresubjecttoconstantchange.Unpredictabilityofcoordination:whileotherrecentworkinsensornetworkshasalsomotivatedtheneedforgeneral-purposealgorithmicsolutions,suchconcernsareaggravatedinimmersivesensornetworkswhichdemandthatthenetworkbegeneral-purpose.Assuch,fewaprioriassumptionscanbemadeabouttheneedsorintentionsofapplicationsthatwillruninthenetwork,requiringthenetworktoadapttounexpectedandchangingsituations.Complexityofprogramming:applicationdevelopmentforsensornetworksislargelyrecognizedas3 needforprogrammingplatforms(i.e.,middleware)thatprovideabstractionsforsimplifyingapplicationdevelopment.Asdescribedinmoredetailinlatersections,muchoftheexistingworkinsimplifyingtheprogrammingtaskinsensornetworksfocusesonapplication-specicnetworkswherethenodesarestaticallydeployedbyaparticulardevelopertoserveaparticulartask.Weenvisionamorefuturisticbutnotunrealisticscenarioinwhichsensornetworksbecomemoregeneralpurposeandreusable.Whilethenetworksmaystillremaindomainspecic,wetargetsituationsinwhichthetypesofapplicationsthatwillbedeployedarenotknownaprioriandmayincludeapplicationswithvaryingsensingneedsandadaptivebehaviors.Examplesofsuchdomainsincludeawarehomes[17],intelligentconstructionsites[5],battleeldscenarios[13],andrstresponderdeployments[19].Finally,existingapplicationscommonlyassumethatsensordataiscollectedfromthenetworkatacentrallocationtobeprocessedandusedinthefutureand/oraccessedviatheInternet.Applicationsfromthedomainsdescribedabove,however,ofteninvolveusersimmersedinthesensornetworkthataccesslocallysensedinformationon-demand.Thisisexactlythevisionoffuturepervasivecomputingenvironments[31],inwhichsensornetworksmustplayanintegralpart[4].ThispaperintroducestheDAIS1(DeclarativeApplicationsinImmersiveSensornetworks)middlewareplatformthatprovidesobject-orientedprogrammingabstractionstailoredtotheubiquitousapplicationsdescribedabove.DAISisnotamiddlewareforsensornetworksinthesensethatitrunsstrictlyonthesensorsthemselves.Instead,DAISallowsdeveloperstocreateapplicationsthatrunonclientdevices(e.g.,laptopsorPDAs)thatinteractdirectlywithanembeddedsensornetwork.Whilethisstyleofinteractioniscommoninmanyapplicationdomains(includingthoseenumeratedabove),throughouttheremainderofthepaperwewilluseapplicationsfromanintelligentjobsitetomotivatethemiddlewareanditsprovidedconstructs.Suchanenvironmentprovidesauniqueandheterogeneousmixofsensingandmobiledevices.Theformerincludessensorsonequipmenttomeasureitslocation,withinconcretetomeasuretemperatureandgeneratecureddata,oncranestomeasuretheirmovementandstresses,andevennearbytohazardousmaterialstomeasuretheconcentrationofpotentiallydangerouschemicals.Mobiledevicesincludethosemovingwithinvehiclesorcarriedbyworkers[16].Severalapplicationsinthisscenariodemandopportunisticinteractionwithlocallyavailablesensors,andwewillusetheseapplicationstodemonstratetheuseoftheDAISmiddleware.Thespecicnovelcontributionsofthisworkarethreefold.First,wedescribeanewmiddlewarearchi-tecturedesignedtomediatetheinteractionsofapplicationsonclientdeviceswithanimmersivesensornetwork.Second,wedevelopanessentialunderlyingabstractionthatallowsanapplicationdevelopertopreciselyspecifythedynamicsetofsensorsthatitinteractswith.Finally,wedescribeaprototypeimplementationofthismiddlewarethatincludesthecreationofaprotocolenablingadaptiveandecientconstructionoflocalzoneswithinthesensornetwork.Theremainderofthispaperisorganizedasfollows.Thenextsectiondescribesthechallenges,high-lightinghowimmersivesensorenvironmentschangetherequirementsofamiddleware.InSection3,weprovideadetaileddescriptionoftheDAISarchitectureincludingitsmostimportantaspect:thepro-gramminginterfaceprovidedtoapplicationdevelopers.Section4coverstheinternalsofthemiddleware.Section5contrastsrelatedprojects,andSection6concludes.2ProblemDenitionInthispaper,weaddresstheneedsofapplicationsdesignedforimmersivesensornetworks.Insuchscenarios,usersmovethroughaninstrumentedenvironmentanddesiretohaveon-demandaccesstoinformationgatheredfromthelocalarea.Figure1(a)showshowcurrentinteractionswithsensornetworkscommonlyoccur,whileFigure1(b)showstheneedsofourintendedapplications.Whilewerecognize 1DAIS(da0s):fromthemiddleEnglishwordmeaning\raisedplatform"2 deployedonthenodes.MiLAN[10]aimstoenableapplicationstocontrolthenetwork'sresourceusageandallocationtooptimallytunetheperformanceofanentiresensornetworkthroughthedenitionofapplicationpoliciesthatareenactedonthenetwork.Whilesuchapproachesarehighlybenecialwhentheapplicationisknownandthenetworksarerelativelyapplication-specic,theydonotmapwelltoimmersivesensornetworkswherethenodesmustbeabletoserviceavarietyofunpredictableapplications.Moregeneralizedapproachesattempttoprovideintegratedsuitesoftoolsthatenablesimpliedpro-grammingofsensornetworks.Forexample,EmStar[8]providesasuiteoflibraries,developmenttools,andapplicationservicesthatfocusoncoordinatingmicroservers(e.g.,sensingdeviceswithcomputationalpowerequivalenttoaPDA).TheSensorNetworkApplicationConstructionKit(SNACK)[9]consistsofasetoflibrariesandacompilerthatmakesitpossibletowriteverysimpleapplicationdescriptionsthatspecifysophisticatedbehavior.Agilla[5]isanagentbasedmiddlewarethatallowsapplicationstoinjectagentsintothesensornetworkthatmigrateintelligentlytocarryouttheapplications'tasks.DAISdiersfromtheseapproachesinthatitperceivesthesensornetworknotasadatarepositorybutasaninstrumentedenvironmentthathasthecapacitytoaugmentauser'spervasivecomputingexperi-ence.Similarly,TinyLime[3]isatuplespacebasedmiddlewarethatenablesmobilecomputingdevicestointeractwithsensordatainamannerdecoupledinbothspaceandtime.TinyLimeprovidesonlysingle-hopconnectionstosensorsandassumesthatthesensorsdonotcommunicateamongthemselves.Thiseectivelyplacesalloftheburdenofaggregationontheshouldersoftheapplicationdeveloper.7ConclusionsInthispaper,wehavedescribedDAIS,atieredmiddlewarethatallowsdeveloperstocreatelightweightapplicationsthatrunonclientdevices(e.g.,laptopsorPDAs)andallowuserstointeractdirectlywithanimmersivesensorenvironment.DAISdenesasetofprogrammingconstructscenteredonthesceneabstraction.Asceneisalocalizedbutdynamicviewofthesensornetworkthatadaptstochangesastheusermovesthroughhisenvironment.Byabstractingtheprocessofselectingsensorstointeractwith,DAISenablesapplicationstomakeintelligenttradeosregardingthepropertiesoftheselectedsensorsandtheircommunicationlinkswithouthavingtodirectlydealwithlow-levelprogrammingconcerns.Usingthesceneabstraction,DAISprovidesawrapperforlow-leveldataacquisitionandaggregation,allowingapplicationstouseahigh-level,asynchronousqueryandresponsemechanismforretrievingdatafromtheenvironment.Asnecessitatedbytheunpredictablesensorenvironment,theseinteractionsaredata-centric,therebydirectlyleveragingapplicationknowledgewithinthecommunicationprocess.Whilethefocusofthispaperisprogrammingabstractionsandtheensuingsimplicationofdevelop-ment,wealsodemonstratedtheaccuracywithwhichscenescanbebuiltaroundlocationinformation.Futureworkwillincludeasimilarevaluationfordierentmetricsandacompletenetworkperformanceevaluationthatconsidersscenedynamicsandmeasuresqueryresponsetimes,energyusage,andoverallcommunicationoverhead.Otherfutureworkwillincludetheintegrationofadditionalstrategiesforsceneconstructionandtheabilitytodynamicallyupdatethecodeonsensornodestoincludenewlyintroducedmetricsandaggregators.Insummary,DAISpresentsauniqueviewofprogrammingpervasivecomputingenvironmentsthatinthefuturewillincludelargenumbersofheterogeneouswirelesssensors.Bycreatinghigh-levelprogram-mingabstractionsthatencapsulatethelocalityofpervasivecomputinginteractions,DAISisarststepinenablingnoviceprogrammerstocreatesophisticatedpervasivecomputingapplications.16 (a) (b)Figure11.Accuracyoflocation-basedScenecalculationstocaseswhenthenetworkwaslargelyconnected,buttheconnectionsweresparse.Inthesesituations,roundaboutpathsmayexistbetweennodeswhenmoredirectroutesdonot.Totheleftofthevalley,thenetworkwaslargelydisconnected,soourapproachdidnotmissmanyconnectedscenemembers.Totherightofthevalley,thenetworkwasmuchmoreconnected,andthedirectapproachisquitesuccessful.TheresultsdepictedinFigure11showthatourapproachtendstondthevastmajorityofthemembersofasceneunderreasonableconditions.Forthisreason,DAISfavorsthesimplicityofnaturalscenespecicationsovercompleteaccuracyofscenemembership.6RelatedWorkSystemsdesignedtoaddressthespecicchallengesposedbysensornetworksand/orpervasivecom-putinghaverecentlybeenatopicofresearchdiscussions.Existingworkhashighlightedseveraldesigntenetsthatamiddlewareforwirelesssensornetworksmustadhereto[31],andtheDAISplatformat-temptstofollowtheseguidelines.Otherprojectshavealsoundertakensimilareorts,andwehighlightafewofthesesystems.Asoneexampleofamiddlewareforpervasivecomputing,GAIA[25]introducesActiveSpacesthatcanbeprogrammedintopervasivecomputingapplications.However,themodelassumesacentralizedandheavyweightsystemstructurewhichisindirectoppositiontothegoalofmiddlewareforcoordinatingwithwirelesssensornetworks.Projectstargeteddirectlyforsensornetworkshaveoftenexploredrepresentingthesensornetworkasadatabase.TwodemonstrativeexamplesareTinyDB[21]andCougar[30].Generallytheseapproachesenableapplicationswithdatarequeststhat owoutfromacentralpoint(i.e.,abasestation)andcreateroutingtreestofunnelrepliesbacktothisroot.Muchoftheworkwithintheseapproachesfocusesonperformingintelligentinnetworkaggregationandroutingtoreducetheoverallenergycostwhilestillkeepingthesemanticvalueofdatahigh.VM?[17]providesavirtualmachineapproachdirectedathandlingdeviceheterogeneity.WhilethisisalsoanimportantconcerninDAIS,VM?assumessituationswheretheapplicationanditsneedscanbeknowninadvancesothattheVMdeployedcanbeoptimizedwithrespecttotheapplicationanddevice.TinyGALS[1]allowsprogrammerstorepresentapplicationsintermsofrelativelyhigh-levelcomponentswhicharesubsequentlysynthesizedintothelow-level,lightweight,ecientprogramsthatare15 Figure9.ImplementationoftheQueryProcessorfunctionalityonsensorsisaone-timequery(i.e.,ifthepersistent agisfalse),thentheQueryProcessorsimplyconnectstotheon-boardsensorthatcanprovidetherequesteddatatype(depictedasSensorinthegure)throughtheADCinterface.Ifthedatarequestisforasensortypethatisnotsupportedonthisdevice(i.e.,thesensortablestoredintheQueryProcessorhasnomappingtoasensorthatcanprovidethespecieddatatype),thenthemessageisignored.Thenodeisstillincludedinthescenebecauseitmaybeanecessaryroutingnodeconnectingtherequestertoanothernodethatdoeshavetherequiredsensor.Ifthequeryispersistent,theninadditiontoimmediatelyreturningtherequestedvalue,theQueryProcessorMmodulealsoinitializesaQueryTimerusingtherequestfrequencyspeciedinthedataportionofthereceivedmessage.Whenthetimerres,QueryProcessorMretrievesavaluefromthesensorandsendsitbacktotheinitialrequesterusingthesendMsginterfaceoftheQueuedSendmodule.Whenanodeisnolongerinascene,theSceneMmodulecreatesanullmessagethatitsendstotheQueryProcessorthroughtheReceiveinterface.TheQueryProcessortakesthismessageasasigntoceasestreamingdatabacktotherequester,andstopstheQueryTimer.5ACaseStudyinSceneDenitionThemetricsusedtospecifyscenescanbedividedintotwocategories.Therstdenesscenesbasedonpropertiesofnetworkpaths,eitherdenedbycharacteristicsoflinks(e.g.,latency)ordevices(e.g.,batterypower).Thesecondcategorydenesscenesbasedonphysicalcharacteristicsoftheenvironment(e.g.,locationortemperature).Theabilitytoqueryanetworkbasedonsuchphysicalcharacteristicsisimportanttomanyapplications.However,theattempttouseaphysicalcharacteristicsuchaslocationtocalculatenetworkpathsisplaguedbytheC-shapednetworkproblem.ConsiderthenetworkshowninFigure10.Inthiscase,nodesAandBarewithin50metersofeachother,yetadiscoveryfromAtoBmustleavetheregionofradius50meterssurroundingAinordertondB.Theonlywaytoguaranteethateverydevicewithinadistanceradiusisdiscoveredisto oodtheentirenetwork.Thenetworkabstractionsmodel[24]directlyrecognizesthissituationandguaranteesthatitcalculatesacorrectregionbyrequiringapplications'regiondenitionstoincludemetricsthatstrictlyincreasealonganetworkpath.Absolutephysicaldistanceis13 componentsmakesthesystemeasiertomaintain,extend,andreuse.Fornow,weprovideonlyasingleimplementationofthestrategy,theBasicScene.Thisisasimple,greedyschemeinwhichalldataaggregationisperformedlocally.Wehavechosenthisasarststeptoprovideaquickprototypeoftheentiremiddleware.OthercommunicationapproachescanbeswappedinfortheBasicScene(forexampleonebuiltaroundTinyDB[21]ordirecteddiusion[14],althoughtheimplementationsoftheseapproachesonthesensorsmayhavetobemodiedslightlytoaccommodatesceneconstruction).BydeningtheSceneStrategyinterface,weenabledeveloperswhoareexpertsinexistingcommunicationapproachestocreatesimpleplug-insthatusedierentquerydisseminationand/oraggregationprotocols.Dierentcommunicationparadigmscanbeusedindierentenvironmentsortosupportdierentapplicationdomainsdependingontheresourceconstraintsordomain-speciccapabilitiesofthedevicesinaparticulardomain.EachSceneStrategyinteractswiththejavax.commpackagetoprovidetheDAISabstractionproto-colsthatallowtheportionofthemiddlewareimplementedinJava(describedabove)tointeractwiththesensorhardware.EachSceneStrategyrequiresnotonlyahigh-levelportionimplementedonthehandhelddevice,butalsoalow-levelportionthatrunsonthesensors.Inthenextsection,wedetailourimplementationoftheportionoftheBasicScenethatmustrunonthesensornodesthatrespondtoaclientapplication'squeries.ThisservesasjustoneexampleofaparticularimplementationoftheSceneStrategy.4.3RealizingtheSceneImplementationonResourceConstrainedSensorsInDAIS,sensorcomponentshavebeendevelopedfortheCrossbowMica2moteplatform[2].OurinitialimplementationiswrittenforTinyOS[13]inthenesClanguage[7]andhelpstheBasicScenestrategyconformtotheSceneStrategyinterfacedescribedpreviously.4.3.1BuildingScenesInnesC,anapplicationconsistsofmoduleswiredtogetherviasharedinterfacestoformcongurations.WehavecreatedseveralcomponentsthatformthefundamentalfunctionalityoftheSceneconguration.Figure7abstractlydepictsthenecessarycomponentsandtheinterfacestheyshare.Thisimplementationfunctionsasaroutingcomponentoneachnode,receivingeachincomingmessagefromtheradioandprocessingitasourprotocoldictates.Inthispicture,weshowcomponentsasroundedrectanglesandinterfacesasarrowsconnectingcomponents.Acomponentprovidesaninterfaceifthecorrespondingarrowpointsawayfromitandusesaninterfaceifthearrowpointstowardsit.Ifacomponentprovidesaninterface,itmustimplementallofthecommandsintheinterface,andifacomponentusesaninterface,itcancallanycommandsintheinterfaceandmusthandlealleventsgeneratedbytheinterface.TheScenecongurationusestheReceiveMsginterface(providedinTinyOS)whichallowsthecom-ponenttoreceivemessagesincoming(byhandlingthereceiveevent).ThestructureofthemessagesreceivedthroughthisprocessisshowninFigure8.ThemessagecontainstwoconstantsthatinstructtheSceneMcomponentinprocessingthescenecalculation.Therstindicatesthepropertyusedtoconstructthescene(e.g.,SCENE DISTANCEfromFigure4).Thesecondindicatestheaggregationfunctiontobeused(e.g.,SCENE MINfromFigure4).Theuseoftheseconstantsmakestheimplementationabitmorein exiblebecausethesetofmetricsthatcanbeusedinanetworkmustbeknownonthesensorsapriori,buttheapproachpreventsmessagesfromhavingtocarrythecodethatdenestheevaluation.ThemetricValueintheSceneMsgallowstheScenebuildingprocesstopropagatestate.ThepreviousHopintheSceneMsgallowsthisnodetoknowitsparentintheroutingtree,whichisimportantinmaintainingthesceneastherequestermovesthrough10 Figure6.SimpliedobjectdiagramforDAISsendaQueryovertheScene.Uponreceivinganyqueryrequest,theSceneViewobjectadjustsitsstateinseveralways.First,foreveryquery,atablewithintheSceneViewisupdatedwithamappingfromauniquequeryidgeneratedforthequerytotheResultListenerhandleprovidedwiththequery.Inaddition,forpersistentqueries,thisuniqueidisreturnedasareceiptofregistrationthatcanbeusedinsubsequentinteractionstoderegisterthequery.Whentheunderlyingprotocolimplementationreturnsaresulttoaquery,theQueryResultisfor-wardedtotheSceneView,whichusesitslocaldatastructuretodelivertheQueryResulttotheappropri-ateResultListener,byinvokingtheresultReceivedmethodintheResultListenerinterface.Thelocaldataproxies(i.e.,theQueryandQueryResult)mediatebetweentheSceneandtheSceneViewAPIsandtheprotocolimplementationsthatunderliethemiddleware.AsshowninFigure6,multiplequeriesmaybeactiveoverasinglesceneatanygiventime.Foreachscene,theSceneViewcontrolsallofthesequeriesandconnectsthemtotheunderlyingimplementationviathestrategypatterninterface.4.2StrategyPatternInterfaceOurmiddlewaremakesuseofthestrategypattern[6],asoftwaredesignpatterninwhichalgorithms(suchasstrategiesforquerydissemination)canbechosenatruntimedependingonsystemconditions.Thestrategypatternprovidesameanstodeneafamilyofalgorithms,encapsulateeachoneasanobject,andmaketheminterchangeable.Suchanapproachallowsthealgorithmstovaryindependentlyfromclientsthatusethem.InDAIS,theclientsthatemploythestrategiesarethequeries,andthedierentstrategiesaretheSceneStrategyalgorithms.ThesealgorithmsdeterminehowaQueryisdisseminatedtotheSceneandhowtheQueryResultisreturned.Ifaparticulardisseminationalgorithmotherthanthedefaultisrequiredforaspecicapplication,anappropriateSceneStrategyalgorithmisinstantiated.Twoprincipledirectivesofobject-orienteddesignareusedinthestrategypattern:encapsulatetheconceptthatvaries,andprogramtoaninterface,nottoanimplementation.Usingthestrategypattern,wedecoupletheQueryfromthecodethatrunsitsowecanvarythequerydisseminationalgorithmwithoutmodifyingtheQueryclass.Theloosecouplingthatthestrategypatternenablesbetweenthe9 Operation Description voidsendQuery(Queryq, Sendsaone-timequerytotheScene.Theresultlistener ResultListenerr) receivesresultsfromthisquery. intregisterQuery(Queryq, RegistersapersistentqueryontheScene.Thefrequency ResultListenerr, indicateshowoftenreadingscomefromeachqualied intfrequency) sensorinthescene.Themethodreturnsareceiptthatcan beusedtocanceltheregistrationwhendesired. voidsendAggQuery(Queryq, Sendsaone-timequery,requestingin-networkaggregation. ResultListenerr, Theuserprovidestheaggregationfunction. Aggregatora) intregisterAggQuery(Queryq, RegistersapersistentqueryontheScene,requestingin- ResultListenerr, networkaggregation.Theuserprovidestheaggregation intfrequency, function.Themethodreturnsareceiptthatcanbeused Aggregatora) tocanceltheregistrationwhendesired. voidderegisterQuery(intreceipt) Stopstheregisteredqueryreferencedbythereceipt. Figure5.SceneViewAPIoperationswants,withoutrequiringhimtospecifyhowitshouldbeobtained.Therefore,thequeryprocessinglayercanchangehowitrunsaquery,withoutrequiringthequeryitselftobechanged.Inourinitialprototype,aQueryprovidesadeclarationofasimpledatatypeprovidedbyasensor.Toeasetheprogrammingtask,thetypesenabledarebuilt-inasconstantswithinthemiddleware,sobuildingaqueryisaseasyasselectingaMetricforthescene.Morecomplicateddatatypesareconstructedusingvirtualsensors.Withinthemiddleware,eachdatatypemustalsodenehoweachstyleofaggregationisperformedonthetype(e.g.,whatitmeanstoaveragethedata).Forcommoncases(e.g.,numericaldata),thesedenitionsarebuiltintothebaseclass.Whileweomitthespecicsforbrevity,theinterfaceforintroducingnewdatatypes(aswellastheinterfacesforintroducingnewaggregatorsornewmetrics)isquitesimpleandmakeseveryeorttoguideanoviceprogrammerincreatingcorrectconstructs.AResultListenerisregisteredtoreceivetheresultsofeachquery.Whentheresultisready,themiddlewarecallstheresultReceived(QueryResult)methodfortheresultlistenerstoforwardtheresultstotheapplication.Thisachievesanasynchronousandnonblockingimplementation,sothattheapplicationcanperformothertasksincasenoresponsecomesbacktothequeryortheresponseforthequeryisdelayed.4ImplementationDetailsInthissection,wedescribetheinternalsoftheDAISmiddlewarethatprovidestheseprogrammingabstractionsdescribedabove.Figure6depictsasimpliedobjectdiagramoftheDAISmiddlewarelayers.ThenamesofthelayersontherightofthegurecorrespondtothelayersinFigure3.Werstgivebriefdetailsofthetoplayersofthisdesign,relatingthemtoourdiscussionoftheAPIinSection2.Wethendiscusstheideaofthestrategypattern,itsimportancetotheoveralldesignofthesystem,andhowourmiddlewaremakesuseofthisconcept.Finally,wewilldetailoneexamplerealizationofthesceneabstractiononthesensors.4.1ApplicationProgrammingInterfaceTheSceneobjectiscreatedthroughtheAPIprovidedtotheapplicationdeveloper,asdiscussedinSection3.Thatis,whentheapplicationneedstoquerytheScene,itcallsthegetSceneView()methodwhichreturnsahandletoaSceneView.OncetheapplicationhasthisaccesstotheScene,itisfreeto8 coordinationbutcouplestheabstractionwithprogrammingconstructsthatallowapplicationstoissueoperationsovertheregions.Whilebothapproacheshaveshownpromiseincoordinatingtraditionalsensornetworkapplicationslikeobjecttrackingandcontournding,theapproachesdonotdirectlyconsiderdynamicsandbothrequireconstantproactivebehaviorofanysensorthatmaybelongtoaregion.Mobicast[23]denesamessagedisseminationalgorithmforpushingmessagestonodesthatfallinaregioninfrontofamovingtarget.Itprovides\just-in-timedelivery"toallownodestosleepuntiltheyneedtoreceiveamessagebypredictingthemovementpatternofthetarget.MobiQuery[19]alsosupportsspatiotemporalqueriesinawirelesssensornetworkandallowsaqueryareatorespondtoauser'sannouncedmotionprole.Thesceneconcept,ontheotherhand,seekstominimizetheoverallcommunicationcostincurredbyhavingalightweightcollectionalgorithmthatreactsdirectlytoauser'sactualmovement.3.1.1AProgrammingInterfaceforSceneDenitionTopresentthedynamicsceneconstructtotheapplicationdeveloper,webuildasimpleAPIthatin-cludesbuilt-ingeneral-purposemetrics(e.g.,hopcount,distance,etc.)andprovidesastraightforwardmechanismfordeveloperstoinsertadditionalmetrics.Figure3showstheAPIfortheSceneclass.classScenefpublicScene(Constraints[]c);publicSceneViewgetSceneView();gFigure3.TheAPIfortheSceneclassFromtheapplication'sperspective,thesceneisadynamicdatastructurecontainingasetofqualiedsensorswhichareconstrainedasspeciedbyalistofconstraints,andaccessedthroughaSceneView.EachconstraintisatriplehMetricm,Aggregatora,Thresholdti,and,tobeincludedinaScene,anode'svalueforthemetricmustmeettheseconstraints.ThegetSceneView()methodprovidesaccesstothedatasourcesintheSceneandseparatesthecontentsofascenefromtheaccesstothosecontents.Thus,ausercanspecifyasceneandseamlesslyaccesstherelevantdatasources,evenashemovesandtheparticularsourceschange.Figure4showssomeexamplesofhowscenesmaybespecied.Theseexamplesincluderestrictingthescenebythenumberofhopsallowed,therequiredbatterypoweroneachparticipatingnode,orthemaximumphysicaldistance.Wenotethatbatterypowerbyitselfmaynotbeagoodmetric(sinceitdoesnotconveyanynotionoflocality),buttheuseofmultipleconstraintsinascenedenitionallowsittobenaturallyandeasilycombinedwithothermetrics(suchasdistanceorhopcount,toensurethatthequerystopspropagating). HopCountScene BatteryPowerScene DistanceScene Metric SCENE HOP COUNT SCENE BATTERY POWER SCENE DISTANCE Aggregator SCENE SUM SCENE MIN SCENE DFORMULA MetricValue numberofhopstraversed minimumbatterypower locationofsource Threshold maximumnumberofhops minimumallowablebatterypower maximumphysicaldistance Figure4.ExampleSceneDenitions6 (a)Usingtoday'scapabilities,auser'squeryisphysicallydetachedfromthesensoreld.Res-olutionofthequeryreliesonacentralizedcollectionpoint,generallytherootofaroutingtreeconstructedoverthenetwork. (b)UsingDAIS,anapplicationrunningontheuser'sdevicecanseamlesslyconnecttothesensorsinthelocalregion,removingtherequirementthatphysicallydistantsensorsparticipateinthequery'sresolution.Figure1.Comparisonof(a)existingoperationalenvironmentswith(b)theoperationalenvironmentimposedbyDAIS.Thisstyleofinteractiondiersfromcommonusesofsensornetworks,introducingseveraluniquechallengesandheighteningexistingones:Localityofinteractions:Anapplicationinteractsdirectlywithlocalsensornodes.Whilethiscanminimizethecommunicationoverheadandlatency(seeFigure1),itcanalsobecumbersomewithrespecttoenablingtheapplicationtopreciselyspecifytheareafromwhichitcollectsinformation.Mobilityinduceddynamics:Whilethesensornodesarelikelystationary(asinmanyotherdeploy-ments),theapplicationinteractingwiththemrunsonadevicecarriedbyamobileuser.Therefore,thedevice'sconnectionstoparticularsensorsandtheareafromwhichtheapplicationdesirestodrawinformationaresubjecttoconstantchange.Unpredictabilityofcoordination:Immersivesensornetworksdemandthatthenetworkbegeneral-purpose.Assuch,fewaprioriassumptionscanbemadeabouttheneedsorintentionsofapplica-tions,requiringthenetworktoadapttounexpectedandchangingsituations.Complexityofprogramming:applicationdevelopmentforsensornetworksislargelyrecognizedasadiculttask.Inimmersivesensornetworks,theprogrammingburdensaremagniedduetothechallengesdescribedhere.Inaddition,thedesiretoprovideend-userapplications(asopposedtomoredatabase-orienteddatacollection)increasesthedemandforapplicationsandthenumberofprogrammersthatwillneedtoconstructthem.Thecon uenceofthesechallengesnecessitatesfor exibleyetexpressiveprogrammingenvironmentsthatenableapplicationdevelopmentforimmersivesensornetworkswhilepayingcarefulattentiontoresourceconstraints.DAISaddressestheseconcernsbyprovidingintuitiveabstractionsoftheimmersiveenvironment.3 Asdescribedinmoredetailinlatersections,muchoftheexistingworkinsimplifyingprogramminginsensornetworksfocusesonapplication-specicnetworkswherethenodesarestaticallydeployedforaparticulartask.Weenvisionamorefuturistic(butnotunrealistic)scenarioinwhichsensornetworksbecomemoregeneral-purposeandreusable.Whilethenetworksmayremaindomain-specic,wetargetsituationsinwhichtheapplicationsthatwillbedeployedarenotknownaprioriandmayincludevaryingsensingneedsandadaptivebehaviors.Examplesofsuchdomainsincludeawarehomes[16],intelligentconstructionsites[15],battleeldscenarios[12],andrstresponderdeployments[18].Finally,existingapplicationscommonlyassumethatsensordataiscollectedatacentrallocationtobeprocessedandusedinthefutureand/oraccessedviatheInternet.Applicationsfromthedomainsdescribedabove,however,involveusersimmersedinthesensornetworkwhoaccesslocallysensedinformationon-demand.Thisisexactlythevisionoffuturepervasivecomputingenvironments[27],inwhichsensornetworksmustplayanintegralrole[4].ThispaperintroducestheDAIS1(DeclarativeApplicationsinImmersiveSensornetworks)middlewareplatformthatprovidesprogrammingabstractionstailoredtotheubiquitousapplicationsdescribedabove.DAISisnotamiddlewareforsensornetworksinthesensethatitrunsstrictlyonthesensors.Instead,DAISallowsdeveloperstocreateapplicationsthatrunonclientdevices(e.g.,laptopsorPDAs)thatinteractdirectlywithembeddedsensornetworks.Whilethisstyleofinteractioniscommoninmanyapplicationdomains,throughoutthepaperwewilluseapplicationsfromanintelligentjobsitetomotivatethemiddlewareanditsprovidedconstructs.Suchanenvironmentprovidesauniqueandheterogeneousmixofsensingandmobiledevices.Thefor-merincludessensorsonequipmenttomeasureitslocation,withinconcretetomeasuretemperatureandgeneratecureddata,oncranestomeasuretheirmovementandstresses,andevennearhazardousmate-rialstomeasuretheconcentrationofpotentiallydangerouschemicals[15].Mobiledevicesincludethosemovingwithinvehiclesorcarriedbyworkers.Theapplicationsinthisscenariodemandopportunisticinteractionwithlocallyavailablesensors,andwewillusethemtodemonstratetheuseofDAIS.Thespecicnovelcontributionsofthisworkarethreefold.First,wedescribeanewmiddlewarearchitecturedesignedtomediatedirectinteractionsbetweenmobiledevicesandanimmersivesensornetwork.Second,wecreateanessentialunderlyingabstractionthatallowsadevelopertopreciselyspecifythedynamicsetofsensorsthatitinteractswith.Finally,wedescribeaprototypeimplementationofthismiddlewarethatincludesthecreationofaprotocolenablingadaptiveandecientconstructionoflocalzoneswithinthesensornetworkthatdynamicallyre ectanapplication'sneeds.Section2ofthispaperdescribesthechallenges,highlightinghowimmersivesensorenvironmentschangetherequirementsofamiddleware.InSection3,weprovideadetaileddescriptionoftheDAISarchitecture.Section4coverstheinternalsofthemiddleware.InSection5,weevaluateacasestudyinscenedenition.Section6contrastsrelatedprojects,andSection7concludes.2ProblemDenitionInimmersivesensornetworks,usersmovethroughaninstrumentedenvironmentanddesiretohaveon-demandaccesstoinformationgatheredfromthelocalarea.Figure1(a)showshowcurrentinteractionswithsensornetworkscommonlyoccur,whileFigure1(b)showstheneedsofourintendedapplications.Whileexistingcollectionbehaviorsthatsense,aggregate,andstreaminformationtoacentralcollectionpointmaybeusefulinimmersivesensornetworks,thispaperundertakesonlytheportionoftheproblemrelatedtoenablingapplications'direct,on-demandinteractions.Fromthisperspective,ourapproachfocusesonusingsensornetworkstoenablepervasivecomputingapplications,notonremotedistributedsensing. 1DAIS(da0s):fromthemiddleEnglishwordmeaning\raisedplatform"2