Presentation on theme: "Spatiotemporal Multicast in Sensor Networks Presenter: Lingxuan Hu Sep 22, 2003 Qingfeng Huang, Chenyang Lu and Gruia-Catalin Roman."— Presentation transcript:
Spatiotemporal Multicast in Sensor Networks Presenter: Lingxuan Hu Sep 22, 2003 Qingfeng Huang, Chenyang Lu and Gruia-Catalin Roman
Outline Problem Statement Background Parameter Analysis Optimization Discussion
Scenario Thousands of sensor nodes communicating wirelessly to track a vehicle Sleeping nodes Awaken nodes
Scenario Wake up just in time Sleeping nodes Awaken nodes
More examples Observations The delivery zone is moving over time Just-in-time delivery instead of ASAP delivery is preferred
Background: 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 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 Rectangle A—C: Initial geocast area B: The point of re-issuing request L: The length of the geocast area W: The distance between B and C Va: The speed of soldier Vp: 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 t s = (L-W)(1/Va – 1/Vp)/2 Geocast has fundamental conflict in this application GeocastRe-geocast L-W
Mobicast Examples A mobicast session is specified by a tuple (m, Z(t), Ts, T) Figure (a) shows a rectangular delivery zone moving upward Figure (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 Concerns Reliable delivery Make the initialization time as short as possible Reduce the slack time Reduce the retransmission overhead
Simple 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 characteristics Not reliable In Current delivery zone Will be in delivery zone soon Other nodes
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 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 ZoneFuture Delivery Zone Forwarding Zone Headway Distance Hold & Forward Zone
Mobicast 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
∆-Compactness G(V, E): geometric graph d(i, j): Euclidean distance between node i and j M(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: δ = MIN i,j δ(i, j) ∆-dilation: The inverse of ∆-compactness ADEB, 3 hops d(A, B) ACB, 2 hopsđ(A, B) M(A, B)
Delivery Guarantee Math Concepts x 2 /a 2 +y 2 /b 2 = 1 c = sqrt(a 2 -b 2 ) 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. Focia c b
An example ∆-compactness δ = MIN i,j d(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 δ 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 x 2 /(25/3) 2 + y 2 /(20/3) 2 = 1
Γ -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) 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-cover The 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 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) d s : headway distance Headway Distance d Diagonal length Sd v V 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 Based on known network topology, we can compute the upper bound of forwarding zone and headway distance to ensure reliable delivery The forwarding zone is k-cover of the delivery zone The headway distance is also computable
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 Observations The value of ∆-compactness of the network is less than % of node pairs have ∆-compactness greater than % of forward cost may be saved by sacrificing delivery guarantee to 90% Approaches Design a sensor network with high compactness to support spatial temporal communication Use a smaller forwarding zone than the one needed for an “absolute” delivery guarantee Use 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 The network dilation decreases as the node density increases There have a saturation point at a moderate density The occurrence of lower extreme compactness value is a rare event Saturation Point Lower bound of the top 99% δ
Optimistic Mobicast: Environment NS-2 simulator, 800 sensor nodes on a 1000x400m area Circular delivery zone Packet 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 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 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) 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 Density Forwarding Zone Size
Adaptive 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 Mobicast Adaptive forwarding zone Hole
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)
Discussion 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 Comments Comments on assumptions Location 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 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
References 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 , Texas A&M university, Q. Huang, C. Lu and G.-C. Roman. Spatiotemporal multicast in sensor networks. WUCSE 18, Washington University in Saint Louis, Q. Huang, C. Lu and G.-C. Roman. Design and analysis of spatiotemporal multicast protocols for wireless sensor networks. WUCS
Related Work – RAP RAP: A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks. A B C E HIGH LOW
Related Work – LSRP LSRP: Local Stabilization in Shortest Path Routing Containment Wave Fault Propagation Wave Initiate a “Containment” action that moves faster than the “Fault Propagation” action.
Related Work – Trajectory Source Destination Trajectory Based Forwarding and Its Applications Trajectory
Related Work – SPEED Delay Boo Packet 1 Beacon Packet 2 SPEED: A Stateless Protocol for Real-Time Communication in Sensor Networks.
Related Work – Mobicast Spatiotemporal Multicast in Sensor Networks. Just in Time Delivery
Comparison Mobicast SPEED Trajectory LSRP RAP N/A Controlled Shortest N/A Space Controlled Fastest N/A Time N/A Priority Context