Spatiotemporal Multicast in Sensor Networks Presenter: Lingxuan Hu Sep 22, 2003 Qingfeng Huang, Chenyang Lu and Gruia-Catalin Roman.

Spatiotemporal Multicast in Sensor Networks

Presenter: Lingxuan HuSep 22, 2003

Qingfeng Huang, Chenyang Lu and Gruia-Catalin Roman

OutlineOutline

Problem Statement BackgroundParameter AnalysisOptimizationDiscussion

ScenarioScenario

Thousands of sensor nodes communicating wirelessly to track a vehicle

Sleeping nodesAwaken nodes

ScenarioScenario

Wake up just in time

Sleeping nodesAwaken nodes

More examplesMore examples

Observations

The delivery zone is moving over time

Just-in-time delivery instead of ASAP delivery is preferred

Background: MulticastBackground: Multicast

IP multicast identifies the recipients by their subscription to a common multicast IP address.Geocast identifies the set of recipients by the geographical locations of the relevant parties.

Limitation of GeocastLimitation of Geocast

Geocast assume the information to be delivered as soon as possible

An early delivery of the wake-up call is likely to waste the precious power resources

Slack and Overhead Slack and Overhead

Rectangle A—C: Initial geocast areaB: The point of re-issuing requestL: The length of the geocast areaW: The distance between B and CVa: The speed of soldierVp: The speed of maximum message

propagation speed

The number of extra radio transmission per delivery Mw ~ W/(L-W)

The average earliness of the nodes receiving message ts = (L-W)(1/Va – 1/Vp)/2

Geocast has fundamental conflict in this application

GeocastRe-geocast

L-W

Mobicast ExamplesMobicast Examples

A mobicast session is specified by a tuple (m, Z(t), Ts, T)Figure (a) shows a rectangular delivery zone moving upwardFigure (b) shows a more general scenario where the delivery zone can change its direction, size and shape over time

How to decide the shape and direction of the delivery zone?

Design ConcernsDesign ConcernsReliable deliveryMake the initialization time as short as possible Reduce the slack time Reduce the retransmission overhead

Simple MobicastSimple Mobicast

Hold-and-forward strategy– In current delivery zone: deliver and forward– Will be in delivery zone soon: hold and forward at

the time the delivery zone reaches the node– Other cases: Ignore the message

Has minimal delivery overhead and has good slack time characteristicsNot reliable

In Current delivery zone

Will be in delivery zone

soon

Other nodes

Problem of Simple Mobicast

Problem of Simple Mobicast

There is a hole between X and other nodes in the delivery zone. The protocol fails to deliver the mobicast message to node X

To deliver reliably, some nodes that are not in the delivery zone have to participate in message forwarding.

Delivery zone Hole

How to determine who should participate?

Mobicast FrameworkMobicast Framework

Delivery zone: the area that message should be delivered

Forwarding zone: The area that message should be forwarded, which is some distance ahead of the delivery zone

Headway distance: The physical distance between the forwarding zone its delivery zone

Hold & Forward Zone: The area that receive the message before entering the forwarding zone

Delivery Zone

Future Delivery ZoneForwarding Zone

Headway Distance

Hold & Forward Zone

Mobicast FrameworkMobicast Framework

Two phases – Initialization phase: communicate the message in an ASAP fashion

to “catch-up” with the spatial and temporal demands of its specification

– Cruising phase: The forwarding zone moves at the same velocity as the delivery zone

Just-in-time – In forwarding zone: forward message immediately– Will be in forwarding zone: hold and forward at the time

becoming member of the forwarding zone– Other cases: Ignore the message

What is the size and shape of forwarding zone?What is the headway distance?What is the initialization time?

Undetermined Parameters

Undetermined Parameters

∆-Compactness∆-Compactness

G(V, E): geometric graphd(i, j): Euclidean distance between node i and jM(i, j): Set of shortest hop network paths between node i and jđ(i, j): The minimum Euclidean length of all paths in M(i, j), also called S2 distance

∆-compactness of two nodes: δ(i, j) = d(i, j) / đ (i, j)∆-compactness of network: δ = MINi,j δ(i, j) ∆-dilation: The inverse of ∆-compactness

ADEB, 3 hops

d(A, B)

ACB, 2 hops

đ(A, B)

M(A, B)

Delivery GuaranteeDelivery Guarantee• Math Concepts

x2/a2+y2/b2 = 1 c = sqrt(a2-b2) Eccentricity e = c/a

• Delivery guarantee– The ellipse that has A

and B as its foci and with eccentricity e = & (network ∆-compactness value) contains a shortest network path inside it.

Fociac b

An exampleAn example

∆-compactness δ = MINi,jd(i, j) / đ (i, j)

For any two nodes A and B in the network, there must exist a shortest network path that is inside the ellipse which has A and B as its foci with eccentricity δ

10685

55

d(A, B)=10, d(A, D)=8, d(B, C)=6, d(A, C)=d(C, D)= d(D, B)=5

δ(A,B)=10/15 δ(A,D)=8/10 δ(B,C)=6/10 δ(A,C)=5/5 δ(C,D)=5/5δ(D,B)=5/5

For A, B. c = 10/2 = 5, c/a = e = & = 0.6, so a=25/3, b=20/3

δ = MIN (10/15, 8/10, 6/10, 5/5, 5/5, 5/5) = 0.6

x2/(25/3)2 + y2/(20/3)2 = 1

Γ-CompactnessΓ-Compactness

If a network’s Γ-compactness value is γ, then any two nodes in the network separated by a distance d must have a shortest path no greater than d/γ hops

h(i, j): The minimum number of network hops between nodes i and j

d(i, j): The Euclidean distance between node i and j

Γ-Compactness: γ = min d(i, j) / h(i, j)

10685

55

d(A, B)=10, d(A, D)=8, d(B, C)=6, d(A, C)=d(C, D)= d(D, B)=5

γ(A,B)=10/3 γ(A,D)=8/2 γ(B,C)=6/2 γ(A,C)=5/1 γ(C,D)=5/1 γ(D,B)=5/1

A, B has path no more than d/γ= 10/3 = 3.3 hopsγ = MIN (10/3, 8/2, 6/2, 5/1, 5/1, 5/1) = 3

K-coverK-coverThe k-cover of a convex polygon P is defined as the locus of all points p in the plane such that there exists two points q and r in the polygon P that satisfy the constraints d(p, q) + d(p, r) ≤ kd(q, r)

K-cover of a line connecting two points i and j is exactly the ellipse of eccentricity 1/k with foci at i and j.

r

k*r

K-cover of a circle with radius r is a concentric circle of radius k*r

?

K-cover of arbitrary polygon is hard to compute

Headway DistanceHeadway Distance

Definition Τ1: the max one-hop latency of the network Sd: the diagonal length of a delivery zone v: the traveling speed γ: Γ-Compactness value. γ = min d(i, j) / h(i, j) ds: headway distance

Headway Distance d

Diagonal length Sd vV

Result ds = vΤ1[Sd/γ]Discussion The longer transmission delay, the longer headway distance The larger delivery zone size, the longer headway distance The faster moving speed, the longer headway distance The smaller Γ-Compactness, the longer headway distance

Summary of Parameter Analysis

Summary of Parameter Analysis

Based on known network topology, we can compute the upper bound of forwarding zone and headway distance to ensure reliable deliveryThe forwarding zone is k-cover of the delivery zoneThe headway distance is also computable

Optimization—Real Application

Optimization—Real Application

The math result can ensure 100% delivery, however

Can the result be applied to real application?

Can we make a trade-off between delivery guarantee and communication overhead?

Can we use a local notion of compactness and the forwarding zone be adaptively adjusted to the local compactness values?

Pairwise Compactness Distribution

Pairwise Compactness Distribution

ObservationsThe value of ∆-compactness of the network is less than 0.290% of node pairs have ∆-compactness greater than 0.6200% of forward cost may be saved by sacrificing delivery guarantee to 90%

ApproachesDesign a sensor network with high compactness to support spatial temporal communicationUse a smaller forwarding zone than the one needed for an “absolute” delivery guaranteeUse a protocol that adapts to the local compactness conditions rather than the global one

∆-compactness of the network

More than 90% ∆-compactness value >= 0.6

(1/0.2-1/0.6)/(1/0.6)

Impact of Node Density

Impact of Node Density

The network dilation decreases as the node density increasesThere have a saturation point at a moderate densityThe occurrence of lower extreme compactness value is a rare event

Saturation Point

Lower bound of the top 99% δ

Optimistic Mobicast: Environment

Optimistic Mobicast: Environment

NS-2 simulator, 800 sensor nodes on a 1000x400m areaCircular delivery zonePacket Header

– Message type– delivery zone size (radius)– sender packet sequence number– delivery zone velocity (x and y components)– sender location (x and y coordinates)– delta factor– sending time– gamma factor– message lifetime

Optimistic Mobicast: Protocol

Optimistic Mobicast: Protocol

• 1. if ( ˜m ) is new and t < T• 2. cache this message• 3. if the value of the delta field is zero• 4. use local delta value for computation• 5. else• 6. use the value in the packet for computation• 7. end if• 8. if (I am in current forwarding zone F[t]) • 9. broadcast ˜m immediately ;• // fast forward• 10. if (I am in current delivery zone Z[t]) • 11. deliver data D to the application;• 12. else• 13. compute my td[in];• 14. if td[in] exists and td[in] < T• 15. schedule delivery of data D to the application

layer at td[in];• 16. end if• 17. end if• 18. else• 19. compute my tf[in];• 20. if tf [in] exists• 21. if t0≤tf [in] ≤ t• 22. broadcast ˜m immediately ;• // catch-up!• 23. else if t < tf[in] < T• 24. schedule a broadcast of ˜m at tf[in];• //hold and forward• 25. end if• 26. end if• 27. end if• 28. end if

Simulation ResultSimulation Result

Metrics– Delivery ratio– Forwarding overhead– Forwarding zone factor

Results– The delivery ratio is 100% after forwarding zone factor reach 2.5– The forwarding overhead increases linearly as the forwarding zone

factor increases

Linear

Simulation Result (cont)

Simulation Result (cont)

The delivery ratio increases when node density or forwarding size increases

The slack time of just-in-time delivery is much better than that of ASAP delivery

Den

sity

Forwarding Zone Size

Adaptive MobicastAdaptive Mobicast• Protocol

– The local compactness is computed for each node to a depth of five hops and within a 100 meter radius.

– A delivery zone node will replace the delta value in the packet by its local delta value before forwarding it.

– A non delivery zone node will not change the delta value in packet.

• Result– Appear to guarantee 100% delivery– Relatively high transmission overhead (because holes are common in

network)

Adaptive MobicastAdaptive Mobicast

Adaptive forwarding zone

Hole

Example of Adaptive Mobicast

Example of Adaptive Mobicast

The protocol adapts to the local topology, and achieves 100% delivery even in the presence of a large hole in its path

The radio transmission overhead is less than 1.2 transmissions per delivery (195 extra radio transmission for 164 deliveries)

DiscussionDiscussion

Mobicast enables applications to have control over the velocity of information dissemination across the space. However

The underlying routing protocol can be improved

The one-hop transmission latency may be unpredictable

The movement of delivery zone may be arbitrary

More CommentsMore Comments

Comments on assumptionsLocation awareness – May be expensive though reasonable– Can we track vehicles without location awareness?

Known network topology– Not applicable to large scale or mobile networks– Adaptive mobicast has advantages over mobicast with

weaker assumption

Conclusions and Future work

Conclusions and Future work

Conclusion– Propose a new and interesting application– Successfully change the problem to a mathematical

model– Analyze the upper bound of parameters for reliable

delivery– The assumptions are expensive– The math result can’t be directly applied to real

application– The adaptive mobicast need to be further explored

Future work– Adaptive mobicast– Other interesting real-time applications

ReferencesReferences

• J. C. Navas and T. Imielinski. Geocast – geographic addressing and routing. In Proceedings of MobiCom’97, pages 66-76, 1997

• Y. Ko and N. Vaidya. Geocasting in mobile ad hoc networks: Location-based multicast algorithms. TR 98-018, Texas A&M university, 1998.

• Q. Huang, C. Lu and G.-C. Roman. Spatiotemporal multicast in sensor networks. WUCSE 18, Washington University in Saint Louis, 2003.

• Q. Huang, C. Lu and G.-C. Roman. Design and analysis of spatiotemporal multicast protocols for wireless sensor networks. WUCS-03-45.

Related Work – RAPRelated Work – RAP

• RAP: A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks.

A

B

CE

HIGH

LOW

Related Work – LSRPRelated Work – LSRP

• LSRP: Local Stabilization in Shortest Path Routing

Containment Wave

Fault Propagation WaveInitiate a “Containment” action that moves faster than the “Fault Propagation” action.

Related Work – Trajectory

Related Work – Trajectory

Source

Destination

• Trajectory Based Forwarding and Its Applications

Trajectory

Related Work – SPEEDRelated Work – SPEED

23

5

9

10

7

DelayBoo

411

6

13

12Packet 1

Packet 1

Beacon

Packet 2

Packet 2

Packet 2

Packet 2

Packet 2

• SPEED: A Stateless Protocol for Real-Time Communication in Sensor Networks.

Related Work – MobicastRelated Work – Mobicast

• Spatiotemporal Multicast in Sensor Networks.

Just in Time Delivery

ComparisonComparison

Mobicast

SPEED

Trajectory

LSRP

RAP

N/A

N/A

Controlled

Shortest

N/A

Space

Controlled

Fastest

N/A

N/A

N/A

Time

N/A

N/A

N/A

N/A

Priority

Context