MobiQuery: A Spatiotemporal Query Service for Mobile Users in Sensor Networks

1. MobiQuery: A Spatiotemporal Query Service for Mobile Users in Sensor Networks Chenyang Lu, Guoliang Xing, Octav Chipara Chien-Liang Fok, and Sangeeta Bhattacharya

2. Outline • Motivation • Design • Analysis • Simulations • Demo

3. Motivation • Supporting query from users is one of the most important function of sensor networks • Existing solutions • Fixed query areas, fixed user: directed diffusion, TinyDB • Fixed areas, mobile user: TTDD, SEAD • Query from mobile users in mission-critical applications has not been addressed • Mobile users and moving query areas • Stringent real-time requirement

4. Mission-Critical Applications • Coordinate fireman efforts to put out wildfires • Search and rescue missions • Robotic motion planning in hazardous environments Query fresh data from surrounding sensors periodically

5. Problem Formulation • Example: “Update a temperature map within 100mevery 2s. Data can be at most 1s old.” • Spatial constraint • Query area: range of 100m • all and only the sensors within the query area should respond to the query • Query area moves with the user • Temporal constraints • Query period: 2s • results must be delivered before end of current period • Data freshness: 1s

6. Challenges • Low duty cycle • Mica2: lifetime of 450 days  1% duty cycle • High wakeup delay • Scarce resources • Require low storage cost, comm. overhead and network contention • Trivial solution does not work! • User issues a query at the beginning of each query period • 1% duty cycle: active for 150ms in every 15s • Wakeup delay: 0~ 14.85s • Many nodes cannot be woken up and respond

7. MobiQuery Approach • Motion prediction • Calculate future pickup points where the user expects a query result, based on a user motion profile • Prefetching • Send prefetch msgs to future pickup points at the right time • Query dissemination • Forwarn sleeping nodes and create a routing tree • Data collection • Sleeping nodes wake up at scheduled time and send data to user via the tree Uninvolved nodes Collector node Active nodes Forewarned nodes Results Routing tree

8. Assumptions • Network runs a power management protocol • Maintain a backbone of active nodes • Bound the comm. delay between any two nodes within the order of a duty cycle • Examples: CCP, SPAN, GAF • MobiQuery can work without backbones with slight modification • Every node knows its location • Nodes have synchronized clocks

9. Generation of Motion Profiles • Motion prediction • Predict future path based on movement history • Motion profile available after actual movement • Motion planning • Robots plan their paths in advance based on map • Motion profile available before actual movement • Advance time of a motion profile • How early a motion profile available before the actual movement: positive for motion planning, negative for motion prediction • Affect the performance of prefetching

10. Prefetching • Greedy prefetching • Send a prefetch msg to future pickup points ASAP • Many routing trees set up simultaneously • Just-in-time prefetching • Send a prefetch msg to a future pickup point at the right time • Only a few trees being set up simultaneously • Advantages of JIT prefectching • Reduce the network contention • Reduce storage cost • Reduce the cost caused by user motion changes

11. Query Dissemination • The node receiving a prefetch msg distributes the query to all nodes in query area • A tree is set up during query dissemination • Sleeping nodes are restricted to be leaves • Wake up when user arrives • Resume sleeping after collecting & sending data

12. Data Collection • Must finish within Tfresh due to data freshness constraint • Parent nodes wait for results from children to enable data aggregation • May miss query deadline due to child failures • Solution based on timeouts • Each node sends results received so far when timeout • Leaf nodes send results at Tfresh before query deadline • Nodes closer to the root have later timeouts • Query results always meet deadline due to the timeouts, possibly with incomplete results

13. Prefetch Forwarding Time • When (K-1)th collector node to forward a prefetch msg to Kth pickup point • Must ensure the query deadline K*Tp to be met • Delay the forwarding to reduce storage time of query states in the Kth query area • Time costs between the prefetch msg is sent and Kth query deadline • Msg travels between two pickup points Ttravel • Sets up the tree in a query area Ttree • Collects data Tcollect

14. Prefetch Forwarding Time Illustration Ttravel + Ttree + Tcollect

15. Prefetch Forwarding Time • Kth query deadline will be met if forward before K*Tp – (Ttravel + Ttree + Tcollect) • Timing analysis • Ttravel < Tp since the msg must travel faster than the user • Tcollect < Tfresh due to data freshness requirement • Ttree = wakeup delay + broadcast delay from root to furthest node in a query area • Assume broadcast delay = data collection delay • Justified by the similarity between tree setup and data collection • Ttree < sleep period Tsleep + Tfresh • Hence Kth query deadline will be met if forward before (K-1)*Tp – Tsleep – 2Tfresh

16. Warmup Interval • When the user changes its path • it may be too late to wake up all the nodes in first several query areas on the new path • Prefetch forwarding time has passed • Temporally suffer from poor performance • Prefetch msg is forwarded asap to catch up • Resume just-in-time prefetching at some collector node when • Current time < prefetching forwarding time

17. Warmup Interval • Suppose a new motion profile received Ta seconds before the motion change • Suppose warmup interval lasts K query periods • Time to take prefetch msg to reach kth pickup point is Tprf = vusr*(K*Tp+Ta)/vprf -- (a) • Query deadlines are not met during warmup • Time to take user to reach Kth pickup point < Tprf+ tree setup time + data collection time  K*Tp+Ta<Tprf+Ttree+Tfresh – (b) • Solving K from (a) and (b): K ≈Tsleep + 2Tfresh + Ta • How early a new motion profile is available before actual motion change is important to the performance

18. Storage Cost • Storage cost during T seconds proportional to • States of a query * max num of routing trees being set up concurrently within T • Analyze num of routing trees only • Greedy prefetching • Intuitively depends on the speeds of msg and user • Proportional to T * (1-vusr/vprf) • Proportional to duration of query • Just-in-time prefetching • Only depend on query parameters • Roughly proportional to (Tsleep+2*Tfresh)/Tp • Independent from duration of query

19. Network Contention • Greedy prefetching causes high network contention • Set up as many routing trees as possible at the same time • Worse when adjacent query areas overlap • Just-in-time prefetching causes much lower network contention • Just-in-time prefetching delays the setup processes of adjacent trees

20. Simulation Results • Metrics • Data fidelity: ratio of the num of nodes that contribute to a query result to the total num of nodes in a query area • Success ratio: ratio of the num of queries that meet deadlines and have data fidelity above a threshold, to the total num of queries • The threshold of data fidelity set to 95%

21. Performance under Accurate Motion Profile • No-prefetching (NP): user issues a query at the beginning of each query period

22. Dynamic Behavior • Greedy prefetching has high jitter due to network congestion • Impropriate for mission-critical applications Warmup interval

23. Performance under Imperfect Motion Prediction • Effect of advance time of a motion profile • Warmup proportional to Tsleep + Ta, consistent to the analysis

24. Effect of Motion Changes and Location Errors

25. Effect of Motion Changes and Location Errors • Motion changes have little effect when advance time is positive • Performance drops with num of motion changes when advance time is negative • Error in user position • Lead to inaccurate motion prediction • Over 85% of queries succeed even when the user changes his motion pattern every 70s and location error is 10m

26. Conclusions • A sptiotemporal query service • Meet stringent spatiotemporal constraints through just-in-time prefetching • Can handle extreme low duty cycles • Can handle imperfect motion prediction schemes • Analysis to practical issues • Network storage, network contention, warmup

27. Critiques • Simple topology creation scheme • Create a routing tree in each query area • High comm. cost and network contention • Solution: Incremental tree maintenance • Dependence on motion profile • Movement pattern may be highly unpredictable (e.g., invader & pursuer game) • Solution: Omni-directional prefetching • Only simulation results • Solution: MQ demo and prototype is working now!

28. Results on 18 Mica2 motes MQ-DTM MQ-DTC