Mission-critical Applications Spatiotemporal Query for Wireless Sensor Networks Structural Health Fire Monitoring Real-time Tracking Monitoring Guoliang Xing ; Chenyang Lu, Octav Chipara Chien-Liang Fok, Sangeeta Bhattacharya •Spatially and temporally dense monitoring •Real-time query and response Department of Computer Science and Engineering •Moving entities •Stringent real-time requirements •Spatiotemporal query service 1 2 Modified from Deborah Estrin, SIGMETRICS keynote, http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt Existing Query Services WSN Mica2 Mote Sensors: light, temperature, pressure, � � Stationary users and areas acceleration, acoustic, magnetic… � Directed Diffusion [Intanagonwiwat 00] , TinyDB [Madden 02] Severe resource constraints � � Stationary areas, mobile users Microcontroller: 7.4 MHz, 8 bit � TTDD [Ye 02] , SEAD [Kim 03] � Memory: 4KB data, 128 KB program � � Spatiotemporal query is not supported � Radio: < 40 Kbps � Mobile users and query areas � Power � Spatiotemporal constraints � Days of lifetime on two AA batteries Integration with power management protocols � � Lifetime of 450 days requires 1% duty cycle [Polastre 04] 3 4 Spatiotemporal Query for Mobile Users Spatiotemporal Constraints A Motivating Example Fireman in wild fire Fireman in wild fire • report temperature within 100m of the moving user every 2s; • report temperature within 100m of the moving user every 2s ; • temperature data must be no more than 1s old • temperature data must be no more than 1s old Spatial constraints � Query area moves with the user � All and only the sensors in the current query area should � respond to the query Temporal constraints � Result must be delivered within the current period � Delivered result should not be older than the validity interval � Meeting the constraints are critical to the fireman’s safety! � 5 6 1
Spatiotemporal Query Service Design Goals of MobiQuery � Allows a mobile user to periodically query a surrounding area under spatiotemporal constraints � Meet spatiotemporal constraints � Query parameters � Deal with severe resource constraints Attributes � Reduce energy consumption � Lifetime: a query has multiple instances � Reduce storage cost � � Period: an instance of the query is executed in each period Reduce communication overhead � � Query area: a function of the user location � Handle unpredictable user mobility Data validity interval � � Support mission-critical applications with mobile users Battlefield awareness � Search and rescue � � Navigation in fire 7 8 Challenge Naive Solution Does Not Work! � Long life time is required � User issues a query at the beginning of each period of 5s � Mica2 mote: Lifetime of 450 days requires 1% duty cycle [Polastre 04] A node is active for 150ms every 15s � � Low duty cycles cause high comm. delays Communication delay is 0 ~ 14.85s � � Many nodes cannot be woken up in time Incoming query packet 0.15s 0.15s 0.15s 0.15s active query period 5s 14.85s 14.85s 14.85s 14.85s 0.15s 0.15s 0.15s 0.15s asleep active cycle 1 cycle 2 cycle 3 cycle 4 14.85s 14.85s 14.85s 14.85s 1% duty cycle asleep wakeup delay cycle 1 cycle 2 cycle 3 cycle 4 9 10 Backbone Assumptions � Nodes know their locations � Nodes have synchronized clocks Sleeping node Sleeping nodes run a synchronized sleep schedule � Active node � A power management protocol maintains a “backbone” composed of Forewarned node active nodes � Examples: SPAN [chen et al. 01] , CCP [wang et al. 03] , GAF [Xu et al. 01] � Active nodes deliver data to sleeping nodes when they wake up � Bound the communication delay between any two nodes in the order of 2 one duty cycle 4 1 3 11 12 2
MobiQuery Overview Generation of Motion Profiles User submits a query once; MobiQuery executes multiple instances Motion prediction � � Motion prediction � predict future pickup points where the user expects a query result � Predict future user path based on movement history � Prefetching � Motion profile available after actual movement send a prefetch message to future pickup points ahead of time � Example: prediction based on two location readings Query dissemination � � � collector node creates a routing tree, alerts the sleeping nodes p 1 Data collection � � p p p = 1 2 2 v nodes wake up in time and deliver data to user through the tree � − t t 2 1 t t � Motion planning 1 2 Uninvolved nodes Robots plan their paths in advance based on map � Collector node Active nodes Motion profile available before actual movement � Alerted nodes 13 14 Just-in-time (JIT) Prefetching Greedy Prefetching Uninvolved nodes Uninvolved nodes Collector node Collector node Active nodes Active nodes Alerted nodes Alerted nodes Forward a prefetch msg at the right time � Forward a prefetch msg ASAP � � Early enough to respond to the query in time � Many query areas are set up simultaneously � Late enough to improve performance High network contention: many overlapping trees are created simultaneously � Only a few query areas are set up simultaneously � � High storage cost: nodes must keep the state of a query for a long time � Reduce network contention & storage cost Prediction of pickup points far away is likely wrong � � More robust to user motion changes 15 16 Prefetch Forwarding Time NS2 Simulation Settings K th query area (K+1) th query area Used CCP as the power management protocol � Parameters � Observations: 200 nodes, 450x450m, radio range is 105m � Query period: 2s � •T travel <T p � Data validity interval: 1s •T collect <T fresh � Query radius: 150m •T dissem ≈ T collect <T fresh Performance metrics � Data fidelity of a query instance: fraction of the nodes in the � K th collector node must forward a prefetch msg before the following time query area that report data instance in order to meet the (K+1) th query deadline: � Success ratio of a query: fraction of the query instances that meet their deadlines and have data fidelity above 95% (K+1)*T p - T travel - T sleep - T dissem - T collect Evaluated impact of sleep period, user speed, location error, user � motion changes, delay in motion prediction > K*T p – T sleep – 2T fresh forwarding time used in Mobiquery 17 18 3
Dynamic Performance under Average Performance Accurate Motion Profile under Accurate Motion Profile � Baseline protocol: No-Prefetching (NP) Success Ratio MQ-JIT 1 0.9 MQ-GP 0.8 NP performs 0.7 0.6 extremely poorly 0.5 0.4 NP 0.3 0.2 0.1 0 16~20 6~10 3 6 9 12 3~5 15 Sleep Period (second) User Speed Range (m/s) Greedy prefetching has a high jitter 19 20 Performance under Imperfect Motion Profile Extensions Limitations of prefetching algorithms � � Requires motion profile Create a new tree in every query period � high overhead & contention � Time between � two turns: New: Directional Tree Maintenance (DTM) � 42s ~ 210s Reduces overhead & contention by maintaining a single moving tree � � Delay in motion � New: Omni-directional Tree Creation (OTC) prediction: Does not require knowledge of motion profile � T lag = -6 ~ 8s � DTM and OTC successfully deliver >80% of query results with � Location error: query period of 1s � err=5, 10m duty cycle < 1% � changing user direction every minute � location error ≤ 15m. � � Mobiquery is robust to frequent motion changes, delay in motion prediction and Location errors 21 22 Implementation on Mica2 Motes Summary Implemented MobiQuery on 6x3 grid of Mica2 motes � Acroname PPRK robot carrying Stargate emulates the user � � Spatiotemporal query introduces a new type of real-time Demo at SenSys 2004 � issues due to mobility � MobiQuery � New approach : Meet spatiotemporal constraints via just-in-time prefetching Low power : deal with low duty cycles � � Efficiency : Lower network contention and storage � Robustness : handle imperfect motion predictions 23 24 4
Recommend
More recommend