MobiQuery:

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

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 KTp 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
• KTp (Ttravel Ttree Tcollect)
• Timing analysis
• Ttravel lt Tp since the msg must travel faster
  than the user
• Tcollect lt 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 lt 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 lt 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(KTpTa)/vprf
  -- (a)
• Query deadlines are not met during warmup
• Time to take user to reach Kth pickup point lt
  Tprf tree setup time data collection time ?
• KTpTaltTprfTtreeTfresh
  (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 (Tsleep2Tfresh)/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