1 Spatiotemporal Query Service Design Goals of MobiQuery Allows a - - PDF document

1

1

Spatiotemporal Query for Wireless Sensor Networks

Guoliang Xing; Chenyang Lu, Octav Chipara Chien-Liang Fok, Sangeeta Bhattacharya Department of Computer Science and Engineering

2

Mission-critical Applications

Structural Health Monitoring Fire Monitoring Real-time Tracking

Modified from Deborah Estrin, SIGMETRICS keynote, http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt

• Spatially and temporally dense monitoring
• Real-time query and response
• Moving entities
• Stringent real-time requirements
• Spatiotemporal query service

3

WSN Mica2 Mote

• Sensors: light, temperature, pressure,

acceleration, acoustic, magnetic…

• Severe resource constraints
• Microcontroller: 7.4 MHz, 8 bit
• Memory: 4KB data, 128 KB program
• Radio: < 40 Kbps
• Power

Days of lifetime on two AA batteries Lifetime of 450 days requires 1% duty cycle [Polastre 04]

4

Existing Query Services

Stationary users and areas

• Directed Diffusion [Intanagonwiwat 00], TinyDB [Madden 02]

Stationary areas, mobile users

• TTDD [Ye 02], SEAD [Kim 03]

Spatiotemporal query is not supported

• Mobile users and query areas
• Spatiotemporal constraints
• Integration with power management protocols

5

Spatiotemporal Query for Mobile Users

A Motivating Example

Fireman in wild fire

• report temperature within 100m of the moving user every 2s;
• temperature data must be no more than 1s old

6

Spatiotemporal Constraints

• 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!

Fireman in wild fire

• report temperature within 100m of the moving user every 2s;
• temperature data must be no more than 1s old

2

7

Spatiotemporal Query Service

Allows a mobile user to periodically query a surrounding

area under spatiotemporal constraints

Query parameters

• Attributes
• Lifetime: a query has multiple instances
• Period: an instance of the query is executed in each period
• Query area: a function of the user location
• Data validity interval

Support mission-critical applications with mobile users

• Battlefield awareness
• Search and rescue
• Navigation in fire

8

Design Goals of MobiQuery

Meet spatiotemporal constraints Deal with severe resource constraints

• Reduce energy consumption
• Reduce storage cost
• Reduce communication overhead

Handle unpredictable user mobility

9

Challenge

Long life time is required

• Mica2 mote: Lifetime of 450 days requires 1% duty cycle [Polastre 04]

Low duty cycles cause high comm. delays

cycle 1 cycle 2 cycle 3 cycle 4 14.85s 0.15s 0.15s 0.15s 0.15s 14.85s 14.85s 14.85s active asleep

1% duty cycle

Incoming packet wakeup delay

10

Naive Solution Does Not Work!

User issues a query at the beginning of each period of 5s

• A node is active for 150ms every 15s
• Communication delay is 0 ~ 14.85s
• Many nodes cannot be woken up in time

cycle 1 cycle 2 cycle 3 cycle 4 14.85s 0.15s 0.15s 0.15s 0.15s 14.85s 14.85s 14.85s active asleep

query query period

5s

11

Assumptions

• Nodes know their locations
• Nodes have synchronized clocks
• Sleeping nodes run a synchronized sleep schedule
• A power management protocol maintains a “backbone” composed of

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
• ne duty cycle

12

Backbone

Sleeping node Active node Forewarned node

4 2 1 3

3

13

MobiQuery Overview

User submits a query once; MobiQuery executes multiple instances

• Motion prediction
• predict future pickup points where the user expects a query result
• Prefetching
• send a prefetch message to future pickup points ahead of time
• Query dissemination
• collector node creates a routing tree, alerts the sleeping nodes
• Data collection
• nodes wake up in time and deliver data to user through the tree

Collector node Active nodes Alerted nodes Uninvolved nodes

14

Generation of Motion Profiles

Motion prediction

• Predict future user path based on movement history
• Motion profile available after actual movement
• Example: prediction based on two location readings

Motion planning

• Robots plan their paths in advance based on map
• Motion profile available before actual movement

1

p

2

p

1

t

2

t

1 2 2 1

t t p p v − =

• 15

Greedy Prefetching

• Forward a prefetch msg ASAP
• Many query areas are set up simultaneously
• High network contention: many overlapping trees are created simultaneously
• High storage cost: nodes must keep the state of a query for a long time
• Prediction of pickup points far away is likely wrong

Collector node Active nodes Alerted nodes Uninvolved nodes

16

Just-in-time (JIT) Prefetching

• Forward a prefetch msg at the right time
• Early enough to respond to the query in time
• Late enough to improve performance
• Only a few query areas are set up simultaneously
• Reduce network contention & storage cost
• More robust to user motion changes

Collector node Active nodes Alerted nodes Uninvolved nodes

17

Prefetch Forwarding Time

> K*Tp – Tsleep – 2Tfresh

Kth collector node must forward a prefetch msg before the following time instance in order to meet the (K+1)th query deadline:

Observations:

• Ttravel<Tp
• Tcollect<Tfresh
• Tdissem≈Tcollect<Tfresh
• Ttravel - Tsleep
• Tcollect
• Tdissem

(K+1)*Tp

Kth query area (K+1)th query area

forwarding time used in Mobiquery

18

NS2 Simulation Settings

• Used CCP as the power management protocol
• Parameters
• 200 nodes, 450x450m, radio range is 105m
• Query period: 2s
• Data validity interval: 1s
• Query radius: 150m
• Performance metrics
• Data fidelity of a query instance: fraction of the nodes in the

query area that report data

• Success ratio of a query: fraction of the query instances that

meet their deadlines and have data fidelity above 95%

• Evaluated impact of sleep period, user speed, location error, user

motion changes, delay in motion prediction

4

19

Average Performance under Accurate Motion Profile

• Baseline protocol: No-Prefetching (NP)

MQ-JIT MQ-GP NP 15 12 9 6 3 Sleep Period (second) 16~20 6~10 3~5 User Speed Range (m/s) 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Success Ratio

NP performs extremely poorly

20

Dynamic Performance under Accurate Motion Profile

Greedy prefetching has a high jitter

21

Performance under Imperfect Motion Profile

• Mobiquery is robust to frequent motion changes, delay in motion prediction

and Location errors

• Time between

two turns: 42s ~ 210s

• Delay in motion

prediction: Tlag = -6 ~ 8s

• Location error:

err=5, 10m

22

Extensions

• Limitations of prefetching algorithms
• Requires motion profile
• Create a new tree in every query period high overhead & contention
• New: Directional Tree Maintenance (DTM)
• Reduces overhead & contention by maintaining a single moving tree
• New: Omni-directional Tree Creation (OTC)
• Does not require knowledge of motion profile
• DTM and OTC successfully deliver >80% of query results with
• query period of 1s
• duty cycle < 1%
• changing user direction every minute
• location error ≤ 15m.

23

Implementation on Mica2 Motes

• Implemented MobiQuery on 6x3 grid of Mica2 motes
• Acroname PPRK robot carrying Stargate emulates the user
• Demo at SenSys 2004

24

Summary

Spatiotemporal query introduces a new type of real-time

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