1 Services for Mobile Users Services for Mobile Users Mobicast : - - PDF document

1
SMART_READER_LITE
LIVE PREVIEW

1 Services for Mobile Users Services for Mobile Users Mobicast : - - PDF document

Hint on Question 5.2 in HW2 Compute the maximum processor utilization that can be assigned to a Deferrable Server to guarantee the task Sensor Netw ork Services set (periodic tasks). for Mobile Users 1/ 1/ n n +


slide-1
SLIDE 1

1

1

Sensor Netw ork Services for Mobile Users

Chenyang Lu

Department of Computer Science and Engineering Washington University in St. Louis 2

Hint on Question 5.2 in HW2

Compute the maximum processor utilization that can be

assigned to a Deferrable Server to guarantee the task set (periodic tasks).

1/ 1/

2 2 1 1 2 1 2 1

n n s s p s s p s s

U U U U U n U n U U ⎡ ⎤ ⎡ ⎤ ⎛ ⎞ ⎛ ⎞ + + ⎢ ⎥ ⎢ ⎥ + ≤ + − ⇒ ≤ − ⎜ ⎟ ⎜ ⎟ + + ⎢ ⎥ ⎢ ⎥ ⎝ ⎠ ⎝ ⎠ ⎣ ⎦ ⎣ ⎦

3

Utilization Bound w ith DS

Under RMS As n ∞:

When Us = 0.186, min Ub = 0.652

System is schedulable if

⎥ ⎥ ⎦ ⎤ ⎢ ⎢ ⎣ ⎡ − ⎟ ⎟ ⎠ ⎞ ⎜ ⎜ ⎝ ⎛ + + + = 1 1 2 2

/ 1 n s s s b

U U n U U ⎟ ⎟ ⎠ ⎞ ⎜ ⎜ ⎝ ⎛ + + + = 1 2 2 ln

s s s b

U U U U ⎟ ⎟ ⎠ ⎞ ⎜ ⎜ ⎝ ⎛ + + ≤ 1 2 2 ln

s s p

U U U

4

Fire Monitoring

Fireman in wild fire

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

5

Navigation through Fire

6

Cargo Tracking

Shipping Yard Ship Train Truck Customer, Shipper, Customs

slide-2
SLIDE 2

2

7

Services for Mobile Users

  • Mobicast: information dissemination to moving areas.
  • MobiQuery: spatiotemporal query for mobile users.
  • Roadmap Query: navigation in dynamic environments.
  • MLDS: mobile agent directory service for tracking applications.

8

Services for Mobile Users

  • Mobicast: information dissemination to moving areas.
  • MobiQuery: spatiotemporal query for mobile users.
  • Roadmap Query: navigation in dynamic environments.
  • MADS: mobile agent directory service for tracking applications.

9

MobiQuery

10

A Motivating Application

Fireman in wild fire

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

11

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 Result should not be older than data 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

12

Key Challenges

Limited power, memory and bandwidth. Low duty cycle for extending network lifetime.

Sleep schedule consists of cycles of long sleep period followed

by short active period.

Lifetime of 450 days requires < 1% duty cycle. (based on Mica2 motes

[J.Polastre et. al. Hot Chips ‘04])

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

slide-3
SLIDE 3

3

13

Design Goals of MobiQuery

Allows a mobile user to periodically collect sensor

data from surrounding areas

Meet spatiotemporal constraints Deal with severe resource constraints Reduce storage cost Reduce communication overhead Robust against unpredictable user movement

14

Prefetching

Predict future query areas Prefetching

Forewarn nodes ahead of time so that they wake up at

the right time to deliver the sensor data

Query dissemination and data collection

Nodes wake up in time and upload fresh data to user

15

Wakeup Process

Sleeping node Active node Forewarned node Assuming backbone based power management (ex.

CCP, GAF, Span)

4 2 1 3 Wake-up at T2 Wake-up at T3 Wake- up at T4 Wake-up at T1

16

Prefetching

Greedy Prefetching

Forewarn nodes in future query areas ASAP Many routing trees set up simultaneously Prediction of far away query areas is likely to be wrong!

Just-in-time (JIT) Prefetching

Forewarn nodes in future query areas at the right time Store and forward strategy Reduce network contention & storage cost More robust to user motion changes

17

Directional Tree Creation (DTC)

Forewarned node Sleeping node Active node

Wake-up sensors ahead of the user Create a new query tree in each query area Aggregate sensor data and deliver to the user when the user

reaches a query area

18

MobiQuery Protocols

Directional Tree Creation (DTC) [ICDCS’05]

High overhead and network contention at high query rates Requires knowledge of user motion profile

Directional Tree Maintenance (DTM) [IPSN’05]

Reduces overhead and contention Requires knowledge of user motion profile

Omni-directional Tree Creation (OTC) [IPSN’05]

Does not require knowledge of user motion profile

slide-4
SLIDE 4

4

19

Generation of Motion Profile

Motion prediction

Predict future user path based on movement history Motion profile available after actual movement

Motion planning

Motion planner plans user path Motion profile available before actual movement

20

Directional Tree Maintenance (DTM)

Query Forewarned node Sleeping node Active node

Maintains a single moving tree rooted at the user Local reconfiguration based on geographic location and user

motion profile

21

2

Directional Tree Maintenance (DTM)

1 3 4 5

Maintains a single moving tree rooted at the user Local reconfiguration based on geographic location and user

motion profile

Forewarned node Sleeping node Active node

22

Omni-directional Tree Creation (OTC)

No motion profile required

Assume knowledge of maximum user speed

Wake up sensors in a circular wake-up area

Encloses sensors in all possible query areas in the

next few query periods

Create a tree when the user reaches a query area

23

Query Query Sleeping node Active node Query

OTC - Algorithm

24

Analysis

Derive parameters such that sensors in future query

areas are woken up

early enough to respond to the query in time late enough to reduce storage cost

DTM / DTC

Time to forward wake-up/prefetch message Based on user velocity and sensor sleep period

OTC

Size of wake-up area Based on knowledge of maximum user velocity and

sensor sleep period

slide-5
SLIDE 5

5

25

Simulations - Metrics

Success ratio – fraction of queries

that meet deadline for which, the faction of sensors that respond in a

query area is above a threshold

Communication cost – total number of messages

normalized by total number of query results

26

Simulations - Settings

Run on ns-2 Backbone-based Power management: Coverage

Configuration Protocol

200 sensors in a 450mx450m area Query radius = 150m Sensor nodes

Communication Range – 105m Sensing Range – 50m Bandwidth – 2Mbps

27

Impact of Sleep Period

Figure 1. Effect on Success Ratio (Tp=0.5s); threshold = 90%

No prefetching performs extremely poorly DTM > OTC >> DTC at long sleep periods

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 3 6 9 12 15 Sleep Period (s) Success Ratio DTM OTC DTC No Prefetching

28

Impact of User Speed

Figure 2. Effect on Success Ratio (Tp=1s, Ts=15s); threshold = 90%

DTM and OTC successfully adapt to different speed ranges.

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 3~5 ms/s 6 ~ 10 m/s 16 ~ 20 m/s 36~40 m/s User Speed (m/s) Success Ratio DTM OTC DTC

29

Impact of Location Error

Figure 3. Effect on Success Ratio ; threshold = 80%

OTC is not affected by inaccuracy in the motion profile; DTM delivers 80% of the query results for location error of 15m. 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 5 10 15 20 Location Error (m) Success Ratio

DTM Ts = 6s DTM Ts = 12s OTC Ts = 6s OTC Ts = 12s

30

Impact of Motion Changes

Figure 4. Effect on Success Ratio (location error = 10m); threshold = 80%

OTC is not affected by user motion changes DTM maintains a success ratio greater than 80%

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 4 6 8 10 12 Number of Motion Changes Success Ratio

DTM Ts = 6s DTM Ts = 12s OTC Ts = 6s OTC Ts = 12s

slide-6
SLIDE 6

6

31

Communication Cost

Figure 5. Under accurate motion profile (Ts=9s)

DTM << DTC < OTC

20 40 60 80 100 120 O T C D T C D T M O verhead per Q uery R esul t Tp=1s Tp=0. 5s

32

Implementation on Motes

Implemented DTC and DTM on 6x3 grid of Mica2 motes Acroname PPRK robot carrying stargate was used to

emulate the user

33

Summary

Meet stringent spatiotemporal constraints.

DTC - good performance for query periods ≥ 2s DTM - lowest communication overhead. OTC - most robust to location error and motion changes.

DTM and OTC successfully deliver >80% of results when

query period = 1s <1% duty cycle user changes direction every minute location error = 15m

34

Roadmap Query for Navigation

35

Problem Addressed

Mobile entity navigation in dynamic environments

Example dynamic environment fire

Applications - search and rescue, evacuation Find a safe path from a start point S to a goal point G,

that is clear of fire.

Safe path - path where the maximum temperature

along the path is below ΔT.

36

Example Scenario

S G TAB < ΔT TAB > ΔT TCG < ΔT A B C T > ΔT

slide-7
SLIDE 7

7

37

Application Challenges

Dynamic environments may change quickly. Up-to-date information about the environment is

required for successful navigation.

On-board sensors insufficient due to limited sensing

range.

Solution?

Obtain up-to-date information about the surrounding area through a sensor network!

38

New Challenges

Heavy communication workload Congestion, communication delay and data loss. Poor safety and navigation performance Efficient query that can provide required information at minimum communication cost

39

Assumptions

Sensor nodes are location aware. Mobile user communicates with sensor network

through on-board gateway.

Mobile user gets burnt at Δburn Nodes have sensing range RS.

T R

T burn S

δ Δ − Δ =

Δburn Rs ΔT δT

Temperature Threshold Burn Temperature Max.Temperature Gradient (oC/m)

40

Roadmap-based Approach

Roadmap-based navigation algorithm – runs on the

mobile entity.

Roadmap Query (RQ) – collects sensor data from

the sensor network.

41

Roadmap-based Navigation

Roadmap Edge Roadmap Vertex

Edge Weight = Weighted function of

max temperature along edge (Tmax) and edge length.

If Tmax > ΔT, edge weight = infinity

S G

42

Roadmap Query

Optimized for roadmap-based navigation. Collects sensor data only from vicinity of mobile user. Selective sampling: collects data only from nodes

that lie along roadmap edges.

slide-8
SLIDE 8

8

43

Roadmap Query Approach

S G

44

Roadmap Query Approach

S G

45

Roadmap Query Approach

S G

46

Roadmap Query Approach

S G

47

Roadmap Query Approach

S G

48

Query Execution

B A C D E

Node that forwards the query Node that heard the query

slide-9
SLIDE 9

9

49

RQ - Forw arding Rule

B C 2 1 4 3 5 7 8 9 10 Node that forwards the query Node that heard the query

If received query msg from node i, forward query msg if (a) cover roadmap edge BC, AND (b) closest to C among node i’s neighbors.

6

50

RQ - Reply Rule

Send query reply if (a) forwarded query msg, OR (b) cover edge BC and temperature > ΔT

B C 2 1 4 3 5 7 8 9 10 Node that forwards the query Node that heard the query 6

51

Query Propagation

B A C D E 1 3 5 9 10 8

Node that forwards the query Node that heard the query

2 4 7 6 52

Query Propagation

B A C D E 1 3 5 9 10 7 8 2 4

Node that forwards the query Node that heard the query

6 53

Data Aggregation

B A C D E 1 3 5 9 10 8

Node that forwards the query Node that heard the query

7 2 4 6 54

Implementation

Implemented on Agilla - our mobile agent middleware Deployed on Mica2 motes.

slide-10
SLIDE 10

10

55

Simulation Setting

Simulations done in NS-2 NIST Fire Dynamics Simulator (FDS) used to obtain

realistic fire scenarios.

Two simulation environments

More Dynamic – start time 50s Less Dynamic – start time 200s

Compared RQ with

Dartmouth Algorithm (DA) [Q. Li, et al. 2003] Global Query (GQ) Local Query (LQ) [G. Alankus, et al. 2005]

56

Success Ratio

RQ > LQ > DA > GQ

57

Communication Cost

RQ has 70% lower communication cost than LQ. RQ reduces node participation by 60%

(a) Communication Cost (b) Node participation per query

0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Forwarding Query Msg Sending Query Reply

  • no. of nodes in RQ/no. of

nodes in LQ Start time 50s Start time 200s 500 1000 1500 2000 2500 RQ LQ Number of msgs Start time 50s Start time 200s

58

Summary

Roadmap Query is optimized for navigation in dynamic

environments

Uses selective sampling guided by roadmaps. Effectively handles node failures.

Successfully deployed and tested RQ on the Agilla

mobile agent middleware and Mica2 motes.

Simulation results show that under realistic fire

scenarios, Roadmap Query has

higher success ratio and lower communication cost.

59

Optional Readings

  • C. Lu, G. Xing, O. Chipara, C.-L. Fok, and S. Bhattacharya, A

Spatiotemporal Query Service for Mobile Users in Sensor Networks, ICDCS'05.

  • S. Bhattacharya, G. Xing, C. Lu, G.-C. Roman, B. Harris, and O.

Chipara, Dynamic Wake-up and Topology Maintenance Protocols with Spatiotemporal Guarantees, IPSN'05.

  • S. Bhattacharya, N. Atay, G. Alankus, C. Lu, O.B. Bayazit and G.-C.

Roman, Roadmap Query for Sensor Network Assisted Navigation in Dynamic Environments, DCOSS'06.