1

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

Chenyang Lu, Guoliang Xing, Octav ChiparaChien-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

Query fresh data from surrounding sensors periodically

•Coordinate fireman efforts to put out wildfires•Search and rescue missions•Robotic motion planning in hazardous environments

5

Problem Formulation

Example: “Update a temperature map within 100m every 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

Collector node

Active nodes

Forewarned nodesResultsRouting tree

Uninvolved nodes

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-DTC MQ-DTM