1 A Motivating Application Fireman in wild fire report - - PDF document

1

1

Sensor Netw ork Services for Mobile Users

Chenyang Lu

Department of Computer Science and Engineering 2

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

3

Navigation through Fire

4

Cargo Tracking

Shipping Yard Ship Train Truck Customer, Shipper, Customs

5

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.

6

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.

2

7

MobiQuery

8

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

9

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

10

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

11

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

12

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

3

13

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

14

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

15

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

16

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

17

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

18

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

4

19

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

20

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

21

Query Query Sleeping node Active node Query

OTC - Algorithm

22

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

23

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

24

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

5

25

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

26

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

27

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

28

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

29

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

30

Implementation on Motes

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

emulate the user

6

31

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

32

Roadmap Query for Navigation

33

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.

34

Example Scenario

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

35

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!

36

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

7

37

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)

38

Roadmap-based Approach

Roadmap-based navigation algorithm – runs on the

mobile entity.

Roadmap Query (RQ) – collects sensor data from

the sensor network.

39

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

40

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.

41

Roadmap Query Approach

S G

42

Roadmap Query Approach

S G

8

43

Roadmap Query Approach

S G

44

Roadmap Query Approach

S G

45

Roadmap Query Approach

S G

46

Query Execution

B A C D E

Node that forwards the query Node that heard the query

47

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 from node i, forward query if (a) cover roadmap edge BC, AND (b) is closest to C among node i’s neighbors.

6

48

RQ - Reply Rule

Send query reply if (a) forwarded query, 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

9

49

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 50

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 51

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 52

Implementation

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

53

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]

54

Success Ratio

RQ > LQ > DA > GQ

10

55

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

56

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.

57

References

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