-传感器网络地上层-fulltutorialhandout

HiPC2003Tutorial

SystemSupportforSensorNetworksSpeakers:Sharad

Mehrotra,Univ.ofCalifornia,IrvineNaliniVenkatasubramanian,Univ.ofCalifornia,IrvineRajeshGupta,Univ.ofCalifornia,SanDiego

QuasarGroupAcknowledgements(forSlides)Nesime

TatbulKevinHoeschele,Anurag

Shakti

Maskey(AURORAteam)JenniferWidom,RajeevMotwani(STREAM)SamMadden(TinyDB)Anantha

Chandrakasan(MITuAMPSTEAM)QiHan,Iosif

Lazaridis,XingboYu(QUASARteam)Srini

Seshan(Irisnet)Slidesfortutorialavailableat/~quasar/tutorial/hipc.pptQuasarGroupSensorNetworksVariousSensorApplicationsBattlefieldMonitoringHabitatMonitoringEarthquakeMonitoringOceanographiccurrentmonitoringMedicalConditionMonitoringTrafficCongestionDetectionTargetTracking&DetectionIntrusionDetectionVideosurveillanceQuasarGroupTaxonomyofApplications(1)DataAccessneedsofapplicationsHistoricaldataAnalysistobetterunderstandthephysicalworldCurrentdataMonitoringandcontroltooptimizetheprocessesthatdrivethephysicalworldFuturedataForecastingtrendindatafordecisionmakingQuasarGroupTaxonomyofApplications(2)PredictabilityofDataaccessFixeddataaccessneedsofapplicationsknowna-prioriUnpredictable(ad-hoc)DataaccessneedsofapplicationsnotknownatanyinstanceoftimePredictable(continuous)DataaccessneedsofapplicationscanbepredictedforsometimeinthefuturewithhighprobabilityQuasarGroupApplicationLandscapenoknowledge someknowledge fullknowledgeTemporalpropertyofdataaccessedPredictabilityofdataaccessthepresentthefutureEacheveningat8pmpredictthetemperatureforthenext5daysNotifymeimmediatelywhenthereisaforestfireEverymonth,calculatetheaveragehumidityinCaliforniaforthelast30daysDidthetemperatureriseabove40oCinthelastyear?IsMr.Doe’snewlyproposedweathermodelaccuratefor1996-2000?HowmuchsnowisthereinAspen?I’mgoingsurfingonSep.30!Willitbewindy?VisualizecurrenthumiditywithMrs.Doe’snewinterpolationscheme.Predictnoiselevelsaroundtheairportifrunway2becomesoperationalthepastQuasarGroupBasicarchitectureofsensornodesQuasarGroupSensorProperties–DifferentCapabilitiesStorageBuilt-inmemorySensingComputingMicro-processorormicro-controllerCommunicationShortrangeradioforwirelesscommunicationQuasarGroupSensorProperties–ResourceConstraintsLowertransmissiondistances(<10m)Lowerbitrates(typically<kbps)LimitedbatterycapacityRadiomodePowerconsumption(mw)Transmit14.88Receive12.50Idle12.36Sleep0.016QuasarGroupSensorDevicestodayMITuAMPS59Mhzto206Mhzprocessor2radios,capableoftransmittingat1Mbps4KBRAMBerkeleyMicamotes8bit,4Mhzprocessor40kbitCSMAradio4KBRAM,TinyOSbasedAseriesofsensornodesdevelopedQuasarGroupSensorOSConceptsConstrainedSchedulingEvent-based(?)ConstrainedStorageModelframepercomponent,sharedstack,noheapVeryleanmultithreadingEfficientLayeringMessagingComponentinitPower(mode)TX_packet(buf)TX_packet_done(success)RX_packet_done(buffer)InternalStateinitpower(mode)send_msg(addr,type,data)msg_rec(type,data)msg_send_done)internalthreadCommandsEventsQuasarGroupSensorNetworkPropertiessmall-scalesensornodesrestrictedresourcesenvironmentalinfluencepronetofailuredepletedbatteryunattendedoperationfrequenttopologychangesandnetworkpartitionsnodemobilitydensedeploymentinlargenumbersscalabilityissuesheterogeneityissuesconcurrencyissuesfixedvs.mobilesensorgridsinfrastructurebasedvs.ad-hoccommunicationQuasarGroupControversieswithsensornetworksHowisthisdifferentfrommobileubiquitouscomputing?Network-centricvs.edge-centricarchitecture?Passivesensorsvs.smartsensorsAnewclassofalgorithms?Tbabilisticvs.epidemicQuasarGroupWirelessNetworkedEmbeddedSystemsCharacteristicsWirelesslimitedbandwidth,highlatency(3ms-100ms)variablelinkqualityandlinkasymmetryduetonoise,interference,disconnectionseasiersnoopingneedformoresignalandprotocolprocessingMobilitycausesvariabilityinsystemdesignparameters:connectivity,b/w,securitydomains,locationawarenessneedformoreprotocolprocessing

Portabilitylimitedcapacities(battery,CPU,I/O,storage,dimensions)needforenergyefficientsignalandprotocolprocessingQuasarGroupCapacityofWirelessSensorNetworksSensorNetworksnodescansense(actuate),compute,communicateatthenextlevel,thesenodesandnetworkscaninfer,track,correlateandcorrespondwhensuchnodescanbecomposed,theapplicationpossibilitiescanbewildlyimaginativehighlyintelligent

real-timedistributedsystemsHowever,therearefundamentallimitstoscalingthathavetodowiththeadhocnatureofsuchnetworksnodesbuildinglinksandcommunicating(includingrelaying,setupanddiscovery)withoutacentralcontrolQuasarGroupCommunicationinSensorNetworksQuestionsweseektoanswerHowmuchinformationcanwirelesssensornetworkstransport?Whatcanbedonetomaximizethistransport?Whatistherightpowerlevelfortransport?Whereisthiscontrol(best)exercised?WhatistheappropriatenetworkconfigurationDirectcommunication(single-hop)Multi-hopcommunicationDirecteddiffusion,LAR,GFCluster-basedcommunicationLEACHQuasarGroupChallengesforSensorNetworksChallengesforSensorNetworksServicesforlocalization,discovery,storage,agreementInjectionofapplicationknowledgeintosensornetworkinfrastructureIntegrationofcommunicationandapplicationspecificdataprocessingQualityofdata/serviceGuaranteesunderresourceconstraintsAutomaticconfiguration&errorhandlingTime&locationmanagementQuasarGroupProjectsonSensorNetworksSensorOSUC-BerkeleyMITmuOSStabilizationOhio-stateUniv.ofIowaMichiganstateUniv.UT-ArlingtonKennStateUniv.QoSinSurveillanceandControl

UIUCUniv.ofVirginiaCMUNetworkrelatedISIUCLAUSCNESTNESTWebDustRutgersCougarCornellQuasarUC-IrvineAuroraBrown,MIT,BrandeisUniv.SensITMITDukeUniv.Univ.ofHawaiiUniv.ofWisconsinNorthwesternUniv.PennStateUniv.AuburnUniv.SmartDustUC-BerkeleyXeroxTinyDBUC-BerkeleyQuasarGroupWhataretheChoices?SensornetworksWirelessnetworksSpecializedinfrastructureCOTSinfrastructureSmartsensorsPassivesensorsProbabilisticguaranteesDeterministicsolutionsQuasarGroupThistutorial–systemsperspectiveLayeredapproachDevicelevelChallengesindesignofsensordevicesandOSsDistributedsensornetworksChallengesinmanaginglargenetworksofsensorstomeetapplicationrequirementsSensorDatabaseManagementChallengesinQueryProcessingoversensornetworksQuasarGroupDesignofsensornodesSensorNodeComponentsComputation/communicationtradeoffEnergyManagementwithinasensorComputation/communicationtradeoffPower-awareOSdesignforsensorsQuasarGroupDistributedComputingInfrastructureforSensorsDesigningDistributedSensorArchitecturesServeroriented--datamigratestoserverfromsensorsStoreornotstore(stream)WhenshoulddatamigrateHowshouldshoulddatamigrateinitsoriginalrawformorinsomeaggregatedform.DistributedapproachDatadoesnotmigrate,requests/QueriesmigrateTinyDBapproach,DimensionApproachDesigningMiddlewareSupportforSensorNetworksEnergy-EfficiencyReal-timeFaulttoleranceQuasarGroupQueryProcessinginSensorNetworksQueriesProcessingoverSensorDatabasesTaxonomyofqueriesLifetimequeries,aggregationqueries,approximatequeries,setbasedqueriesWheredoqueriesariseAttheserver,fullydistributedatanynodeQuerysemanticsWhatdoesaquerymean?Exactsemanticsnotveryclear.QueryProcessingtechniquesAnsweringApproximateQueriesoverApproximateRepresentationAnsweringQueriesinthenetworkDistributedQueryAnsweringDataStreamprocessing&DynamicDataQuasarGroupDesignIssuesinSensorDevicesHiPC2003,Hyderabad,IndiaQuasarGroupEnergyAvailabilityGrowth

limitedto2-3%peryearProcessor(MIPS)HardDisk(capacity)Memory(capacity)Battery(energystored)012345616x14x12x10x8x6x4x2x1xImprovement(comparedtoyear0)Time(years)Needtobeenergyefficientatalllevelsandinalltasks.J.Rabaey,BWRCQuasarGroupComputationalEfficiencySpeedpowerefficiencyhasindeedgoneup10x/2.5yearsforPsandDSPsin1990sbetween100mW/MIPto1mW/MIPsince1990ICprocesseshaveprovided10x/8yearssince1965restfrompowerconsciousICdesigninrecentyearsLowerpowerforagivenfunction&performancee.g.1.6x/yearreductionsinceearly80sforDSPs(sourceTI)Mostoptimisticprojectionsatbeststopat60pJ/op(about20X)However,circuitgainsarenearingaplateaucircuittricks&voltagescalingprovidedalargepartofthegainswhileenergyneeds(functionality,speed)continuetoclimb10xincreases:ingatecount(7years);infrequency(9years)QuasarGroupEfficiencyinCommunicationsPowerEfficiency(orEnergyEfficiency)P=Eb/N0ratioofsignalenergyperbittonoisepowerspectraldensityrequiredatthereceiverforacertainBERhighpowerefficiencyrequireslow(E_b/N_0)neededforagivenBERBandwidthEfficiencyB=bitrate/bandwidth=R_b/Wbps/hzratioofthroughputdataratetobandwidthoccupiedbythemodulatedsignal(typicallyrangefrom0.33to5)Oftenatrade-offbetweenthetwoe.g.foragivenBERaddingFECreducesBbutreducesrequiredPmodulationschemeswithlarger#ofbitspersymbolhavehigherBbutalsorequirehigherPQuasarGroupCommunicationvs.ComputationComputationcost(2004projected):60pJ/opMinimumthermalenergyforcommunications:20nJ/bit@1.5GHzfor100mequivalentof300ops2nJ/bit@1.5GHzfor10mequivalentof0.03opssignificantprocessingversuscommunicationtradeoffJ.Rabaey,BWRCQuasarGroupTheNeedPowerconsumption,energyefficiencyisasystemleveldesignconcernefficiencyincomputation,communicationandnetworkingsubsystemsTheenergy/powertradeoffscutacrossallsystemlayers:circuit,architecture,software,algorithmsneedtochoosetherightmetricPowerawarenessgoesbeyondlowpowerconcernsmaketradeoffsagainstperformance,qualitymeasuresagainstapplicationconstraintsQuasarGroupPowerSupplyWheredoesthePowerGo?BatteryDC-DCConverterCommunicationRadioModemRFTransceiverProcessingProgrammablePs&DSPs(apps,protocolsetc.)MemoryASICsPeripheralsDiskDisplaySignalingprotocols,choiceofmodulation,TX/RXarchitecture,RF/IFcircuitsBasebandDSPQuasarGroupCapabilities:vibration,acoustic,accelerometer,magnetometer,temperaturesensingExample1:PowerMeasurementsonRockwellWINSNodeSummaryProcessor=360mWdoingrepeatedtransmit/receiveSensor=23mWProcessor:Tx=1:2Processor:Rx=1:1TotalTx:Rx=4:3atmaximumrangeCommunication

SubsystemRadio

ModemGPSMicro

ControllerRestoftheNodeCPUSensorQuasarGroupPowerConsumptionNotablesDifferencesinradio“sleep”versus“shutdown”canbesignificantneedpowermanagementstrategiesatmodule/subsystemlevelGenerallyRXpowerlessthanTXpower.However,asTXgettolowerpowermodes,undersomecircumstances,itmaybelessthanRXpowerparticularlytruein“sensor”typenodesneedprotocolsthatminimizelisteningneededneedverylowpower“paging”channelsforwakeupProcessingcanbeasignificantfractionoftotalpower30-50%QuasarGroupMetricsforPowerAbsolutepower(mW)setsbatterylifeinhoursproblem:powerfrequency(slowthesystem!)uW/MHzaverageenergyconsumedbythesystemEnergyperoperationfixesobviousproblemwiththepowermetricbutcancheatbydoingstuffthatwillslowthechipEnergy/op=Power*Delay/opMetricshouldcapturebothenergyandperformance:e.g.Energy/Op*Delay/OpEnergy*Delay=Power*(Delay/Op)2Therefore:uW/MIPS:averageenergyperinstructionuW/MIPS^2:normalizesuW/MIPSwiththearchitecturalperformanceusefulforcomparingarchitecturesforpowerefficiency.QuasarGroupNodeLevelPowerManagementChoices:H/W,Firmware,OS,Application,UsersHardware&firmwaredon’tknowtheglobalstateandapplication-specificknowledgeUsersdon’tknowcomponentcharacteristics,andcan’tmakefrequentdecisionsApplicationsoperateindependentlyandtheOShidesmachineinformationfromthemOSisareasonableplace,but…OSshouldincorporateapplicationinformationinpowermanagementOSshouldexposepowerstateandeventstoapplicationsforthemtoadapt.QuasarGroupOperatingSystemDirectedPowerManagementSignificantopportunitiesinpowermanagementliewithapplication-specific“knobs”qualityofservice,timingcriticalityofvariousfunctionsOSplaysanimportantroleinallocation,sharingofcriticalresourceitisalogicalplacefordynamicpowermanagementapplication-specificconstraintsandopportunitiesforsavingenergythatcanbeknownonlyatthatlevelNeedsofapplicationsaredrivingforceforOSpowermanagementfunctions&power-basedAPIcollaborationbetweenapplicationsandtheOSinsetting“energyusepolicy”OShelpsresolveconflictsandpromotecooperationQuasarGroupSlowdownbyreducingsupplyvoltage–DynamicVoltageScalingReductioninsupplyvoltagereducesspeedReducesupplyvoltagewhenslowerspeedcanbetoleratedorusearchitecturaltechniquestocombatslowoperatione.g.concurrency,pipeliningviacompilertechniquesQuasarGroupShutdownforEnergySavingShutdownattractiveformanywirelessapplicationsduetolowdutycycleofmanysubsystems:Issues:Costofrestarting:latencyvs.powertrade-offincreaseinlatency(responsetime)increaseinpowerconsumptionduetostartupWhentoShutdown:Optimalvs.IdleTimeThreshold

vs.PredictiveWhentoWakeup:Optimalvs.On-demand

vs.PredictiveTwomainapproaches:(ReactiveversusPredictive)“GotoReducedPowerModeaftertheuserhasbeenidleforafewseconds/minutes,andrestartondemand”“Usecomputationhistorytopredictwhether

Tblock[i]islargeenough(Tblock[i]

Tcost)”QuasarGroupToShutdownorReduceVoltage?Observation:bettertolowervoltagethantoshutdownincaseofdigitallogicExample:taskwith100msdeadline,requires50msCPUtimeatfullspeednormalsystemgives50mscomputation,50msidle/stoppedtimehalfspeed/voltagesystemgives100mscomputation,0msidlesamenumberofCPUcyclesbut1/4energyreductionVoltagegetsdictatedbythetightest(critical)timingconstraintbothonthroughputandlatency-->dynamicallychangevoltageUsevoltagetocontroltheoperatingpointonthepowervs.speedcurveI.e.,powerandclockfrequencyarefunctionsofvoltageMainchallengehereisalgorithmic:onehastoschedulethevoltagevariationaswell!viacompilerorOSorhardwareQuasarGroupCurrentOSPM-ACPIAdvancedConfigurationandPowerManagementInterface(ACPI)OSvisible(SCI-based)asopposedtoOSinvisible(SMI-based)OS/drivers/BIOSareinsyncregardingpowerstatesStandardwayforthesystemtodescribeitsdeviceconfig.&powercontrolh/winterfacetotheOSregisterinterfaceforcommonfunctionssystemcontrolevents,processorpowerandclockcontrol,thermalmanagement,andresumehandlingInfoondevices,resources,&controlmechanismsDescriptionTables,linkedina"tableoftables"descriptiondataforeachdevice:PowermanagementcapabilitiesandrequirementsMethodsforsettingandgettingthepowerstateHardwareresourcesettingsMethodsforsettinghardwareresourcesQuasarGroupNewpower-awareinterfacesrequiredProvidewaysbywhichApplication,OperatingSystemandHardwarecanexchangeenergy/powerandperformancerelatedinformationefficiently.Facilitatethecontinuouslydialogue/adaptationbetweenOS/Applications.FacilitatetheimplementationofpowerawareOSservicesbyprovidingasoftwareinterfacetolowpowerdevicesApower-awareAPItotheenduserthatenablesonetoimplementenergy-efficientRTOSservicesandapplicationsQuasarGroupPower-awareAPITheapplicationsinterfaceprovidesthefollowingservices:

TheapplicationisabletotellRTinformationtoOS(period,deadlines,WCET,hardness)createnewthreadstellOStimepredictedtofinishagiventaskinstancedependingontheconditionsoftheenvironment(applicationdependentandnotyetimplemented)OSmustbeabletopredictandtellapplicationsthetimeestimatedtofinishthetaskdependsontheschedulingschemeusedAhardtaskmustbekilledifitsdeadlineismissed.QuasarGroupPowerManagementinCommunicationSubsystemsComputation

Subsysteme.g.Dynamic

Voltage/Freq.

ScalingCommunication

SubsystemModulationcodingPower-aware

TaskSchedulingOS/Middleware/Applicationcoordinate?Power-aware

PacketSchedulingQuasarGroupTinyOSConceptsScheduler+GraphofComponentsconstrainedtwo-levelschedulingmodel:threads+eventsComponent:Commands,EventHandlersFrame(storage)Tasks(concurrency)ConstrainedStorageModelframepercomponent,sharedstack,noheapVeryleanmultithreadingEfficientLayeringMessagingComponentinitPower(mode)TX_packet(buf)TX_packet_done(success)RX_packet_done(buffer)InternalStateinitpower(mode)send_msg(addr,type,data)msg_rec(type,data)msg_send_done)internalthreadCommandsEventsQuasarGroupApplication=GraphofComponentsRFMRadiobyteRadioPacketUARTSerialPacketADCTempphotoActiveMessagesclocksbitbytepacketRoutemaproutersensorapplnapplicationHWSWExample:adhoc,multi-hoproutingofphotosensorreadings3450Bcode226BdataGraphofcooperatingstatemachinesonsharedstackQuasarGroupPart2:DistributedComputingInfrastructureforSensorApplications

**SupportedinpartbyacollaborativeNSFITRgrantentitled“real-timedatacapture,analysis,andqueryingofdynamicspatio-temporalevents”incollaborationwithUCLA,U.Maryland,U.ChicagoQuasarGroupManagingDistributedSensorInfrastructuresAdatacollectionandmanagementmiddlewareinfrastructurethatprovidesseamlessaccesstodatadispersedacrossahierarchyofsensors,servers,andarchivessupportsmultipleconcurrentapplicationsofdiversetypesadaptstochangingapplicationneedsFundamentalIssues:Wheretostoredata?donotstore,attheproducers,attheserversWheretocompute?Attheclient,server,dataproducersQuasarGroupOutlineofthissectionSensornetworkarchitecturesSensorapplicationneedsAccuracy,timeliness,cost,reliabilityTasksofamiddlewareframeworkServicesthatcanbecustomizedtoaddressneedsCasestudiesaccuracy/costtradeoffsincollectionAccuracy/cost/timelinesstradeoffsincollectionStorage/accuracytradeoffsinarchivalQuasarGroupArchitecturalConfigurationsServer-centricStreamsHierarchicalDistributedQuasarGroupSensorNetworkArchitectures–1:(servercentric)Traditionaldatamanagementclient-serverarchitectureefficientapproachestodatastorage&queryingqueryshippingversusdatashippingdatachangeswithexplicitupdateLimitationsSensorsgeneratecontinuouslychangingdataProducersmustbeconsideredas“firstclass”entitiesDoesnotexploitthestorage,processing,andcommunicatingcapabilitiesofsensorsdata/queryrequestdata/queryresultclientserverdata

producersQuasarGroupSensorNetworkArchitectures–2:streamsStreammodelDatastreamsthroughtheserverbutisnotstoredContinuousqueriesevaluatedagainststreamingdataDealswithproblemsduetodynamicdataontheserversideLimitationsDoesnotconversesensorresources(e.g.,power)DoesnotexploitthestorageandprocessingcapabilitiesofsensorsGearedtowardscontinuousmonitoringandnotarchivalapplicationsstreamprocessingengine(Approximate)Answersynopsisin

memorydata

streamscontinuousqueriesQuasarGroupSensorNetworkArchitectures–3:hierarchicalHierarchicalarchitecture(e.gQuasar)dataflowsfromproducerstoservertoclientsperiodicallyqueriesflowtheotherway:Ifclientcachedoesnotsuffices,thenqueryroutedtoappropriateserverIfservercachedoesnotsuffice,thenaccesscurrentdataatproducerThisisalogicalarchitectureproducerscouldalsobeclientsAservermaybeabasestationora(more)powerfulsensornodeServersmightthemselvesbehierarchicallyorganizedThehierarchymightevolveovertimeserverclientclientcacheservercacheandarchiveProducer&itscacheQUERYFLOWDATAFLOWQuasarGroupDistributedarchitecture(e.g.Dimensions)StoredataatsensornodesConstructdistributedload-balancedquad-treehierarchyof

lossywavelet-compressed

summaries

correspondingtodifferentresolutionsandspatio-temporalscales.Queriesdrill-downfromrootofhierarchytofocussearchonsmallportionsofthenetwork.Progressivelyage

summariesforlong-termstorageandgracefuldegradationofqueryqualityovertime.PROGRESSIVELYAGELevel0Level1Level2PROGRESSIVELYLOSSY…SensorNetworkArchitectures-4:

FullyDistributedP2PQuasarGroupOutlineofthissectionSensornetworkarchitecturesSensorapplicationneedsAccuracy,timeliness,cost,reliabilityTasksofamiddlewareframeworkServicesthatcanbecustomizedtoaddressneedsCasestudiesaccuracy/costtradeoffsincollectionAccuracy/cost/timelinesstradeoffsincollectionStorage/accuracytradeoffsinarchivalQuasarGroupBalancingTradeoffsinApplicationRequirementsAccuracyMoreaccuratecontextresultsinbetterapplicationperformanceVeryhighaccuracymaynotbeneededCostMinimizeresourcesconsumedNetwork(messaging)EnergyStorageTimelinessLatedatamaybeuselessReliabilityWrong/missingdatamaycauseproblemsQuasarGroupDataRepresentationInstantaneousvalueRange-basedStaticIntervalDynamicrange-basedProbabilisticdistribution(mean,stdev)withdecayCompressedformatswavelethistogramssketchesQuasarGroupWhatisaccuracy?ResolutionTemporal(Aurora)1valueforaslidingwindowofsize5Load-shedding,subsettingSpatial(askIosifaboutwkshppaper)1valueforagivenregionofdimension[x.y]Valuelaxity(Quasar)Valuerepresentedasaninterval9representedas[6,12]ValuerepresentedasaprobabilitydistributionQuasarGroupTasksofaSensorManagementFrameworkTranslation:mappingapplicationqualityrequirementtodataqualityrequirementsExamples:Targettracking:qualityoftrack-->accuracyofdataAggregationQueries:accuracyofresults-->accuracyofdataStrategyshouldadapttoexpectedapplicationloadCollectionMinimizesensorresourceconsumptionwhileguaranteeingrequireddataqualityStorageDissemination/DeliveryQuasarGroupMiddlewareComponents

DistributedSensorEnvironment

mobiletargettracking

activitymonitoring

....

locationbasedservice

Applications

-

ServerSideComponentsAdaptiveMiddleware

SensorSideComponents

sensordatamanagementsensordatabase

SensorStatemanagementsensorselectionfaulttoleranceAQDQtranslationprecisiondrivenadaptationadaptiveprecisionsettingpredictionmodulepredictionmoduleQuasarGroupAdaptiveTrackingofmobileobjectsTrackvisualizationBasestation1Basestation2Basestation3ServerShowmetheapproximatetrackoftheobjectwithprecisionWirelessSensorGridobjectWirelesslinkTrackingArchitectureAnetworkofwirelessacousticsensorsarrangedasagridtransmittingviaabasestationtoserverObjectiveTrackamobileobjectattheserversuchthatthetrackdeviatesfromtherealtrajectorywithinauserdefinederrorthresholdtrackwithminimumcommunicationoverhead.

QuasarGroupBasicTriangulationAlgorithmP:sourceobjectpower,Ii=intensityreadingatithsensor(x-x1)2+(y-y1)2=P/4I1(x-x2)2+(y-y2)2=P/4I2(x-x3)2+(y-y3)2=P/4I3Solvingweget(x,y)=f(x1,x2,x3,y1,y2,y3,P,I1,I2

,I3,

)(x1,y1)(x2,y2)(x3,y3)(x,y)

MorecomplexapproachestoamalgamatemorethanthreesensorreadingspossibleThosearebasedonnumericalmethods--donotprovideaclosedformequationbetweensensorreadingandtrackinglocation!Servercanusesimpletriangulationtoconverttrackqualitytosensorintensityqualitytolerancesanduseamorecomplexapproachtotrack.QuasarGroupTrackqualitydataquality

Intensity(I1)timeI1

Intensity(I2)timeI2Intensity(I3)timeI3

tit(i+1)

tit(i+1)

tit(i+1)X(m)Y(m)Case1(powerconstant)LetIibetheintensityvalueofsensorIf then,trackqualityisguaranteedtobewithintrackwhere andCisaconstantderivedfromtheknownlocationsofthesensorsandthepoweroftheobject.Case2(powervariesbetween[Pmin,Pmax])If then trackqualityisguaranteedtobewithintrackwhereC’=C/P2andisaconstant.

Theaboveconstraintisaconservativeestimate.BetterboundspossibletrackQuasarGroupDSDSComponentsofanInformationCollectionFrameworkInformationMediatorDSInformationConsumerconsumerconsumer……InformationSourcesourcesourcesource……sourceupdaterequestconsumerrequestQuasarGroupSensorModelWirelesssensors:batteryoperated,energyconstrainedIntensityabovethresholdGeterrorboundfromserverRemovedfrom“activelist”Removedfrom“activelist”S1:activeprocessoron,sensoron,radioonS2:quasi-activeprocessoron,sensoron,radiointermittentS0:monitorprocessoron,sensoron,radiooffQuasarGroupDataCollectionProtocolsSensor-Sideprotocol:Whennotinuse:tellservertoremoveitfrom“activelist”,switchtomonitormodeS0Uponexternalevent:ifinS0,changetoactivemodeS1,andupdateeverytimeinstantifinS2,updateonlywhenerrorboundviolatedServer-Sideprotocol:IfsensorstatechangestoS1additto“activelist”computeanerrorboundforit,andsendtothesensorelse,whenvaluereceived,updateservercacheifthesensorisin“activelist”QuasarGroupDataCollectionProblemLetP=<p[1