A Scalable Approach for Reliable Downstream Data Delivery in Wireless Sensor Networks

1. A Scalable Approach for Reliable Downstream Data Delivery in Wireless Sensor Networks Seung-Jong Park, Ramanuja Vedantham, Raghupathy Sivakumar and Lan F. Akyildiz School of Electrical and Computer Engineering Georgia Institute of Technology ACM MobiHoc 2004 Speaker: Hao-Chun Sun

2. Outline • Introduction • GARUDA Overview • GARUDA Framework • Performance Evaluation • Conclusion

3. Introduction -background- • Sink to the sensors • The need for reliability in a sensor network is dependent upon the specific application the used for. Sensor Network Downstream Sink

4. Introduction -background- • Security application for reconfigurable sensors • Sink upgrades software (control code) to sensor. • Sink sends target database to sensor. • Sink sends a query. Sensor Network Downstream Reliability Sink

5. Introduction -Motivation- • Reliable downstream point-to-multipoint data delivery from sink to the sensors. • Sensor network Challenges— • Environment considerations • Message considerations • Reliability considerations

6. Introduction -Motivation- • Sensor network Challenges— • Environment considerations • Limited life time • Low bandwidth, energy • Message considerations • Small sized messages • Reliability considerations • Traditionally, reliability notion is a simple 100% reliable data delivery. • WSNs might require other notions of reliability.

7. Introduction -Motivation- • WSNs reliability notions

8. GARUDA Overview • GARUDA design elements • Core node • Instantaneous construction • A single packet flood. • Approximation of the minimum dominating set (MDS) • Used for the loss recovery • On a per-message basis

9. GARUDA Overview • GARUDA design elements • Loss recovery process • Two-stage loss recovery • Loss recovery for Core Nodes • Loss recovery for Non-core Nodes • Reasons for two-stage— • Precluding any non-core nodes’ contention • When the core nodes perform retransmission for other core nodes, this core node’s neighbors can receive the packets. • Only core nodes are performing retransmissions, the chances for collisions are minimized.

10. GARUDA Overview • GARUDA design elements • Loss recovery process • NACK based • Cannot handle all packets in a message being lost. • NACK implosion • In-sequence forwarding • Out-of sequence forwarding with A-map propagation • A-map (Availability Map)—representing availability of packets with bit set. • Ex:1 message=5 packetsA-map:(01010)

11. Ts Tp Time P pulses P pulses GARUDA Overview • GARUDA design elements • Reliable Single/First Packet Delivery • Wait-for-First-Packet (WFP) pulse • Short duration pulses • The amplitude that is much larger than that of a regular data transmission. • Sink inform the sensors about an impending message. • It enables sensors to require for retransmission. Tp<Td<Ts

12. GARUDA Overview • GARUDA design elements • Multiple Reliability Semantics • Require reliable delivery to a subset Gs of the nodes in the graph G. • Gs is consisted of K components. Sink MDS MDS Shortest Path Tree MDS MDS

13. GARUDA Framework • Single/First Packet Delivery • NACK reliability problem • Core instantaneous construction Forced WFP Pulse Ts DIFS Data Packet S Sink Forced WFP Pulse DIFS Data Packet Data Packet A A Forced WFP Pulse Data Packet B B

14. GARUDA Framework • Single/First Packet Delivery • Loss detection and recovery Forced WFP Pulse Ts DIFS Data Packet S Sink Forced WFP Pulse DIFS DIFS Data Packet Data Packet Data Packet A A X Forced WFP Pulse Data Packet B B Forced WFP Pulse

15. GARUDA Framework • Single/First Packet Delivery • Loss detection and recovery • Tc=i × Δ × Td, i: hop number; Δ: max node degree DIFS DIFS Data Packet Data Packet A A X Forced WFP Pulse Tc Data Packet B B Forced WFP Pulse

16. GARUDA Framework • Core instantaneous construction Sink Sensor node Core node 0 3i+1 3i+2 3i 3i+1 3i+2 3i

17. GARUDA Framework • Core instantaneous construction Sink Sensor node Core node 0 3i+1 3i+2 3i 3i+1 3i+2 3i

18. GARUDA Framework Broadcast Unicast • Core instantaneous construction Anycast 3i Core band a b 3i+1 c d 3i+2 e f Core band 3(i+1) g h ……… 3i+2 Boundary band i

19. GARUDA Framework • Core instantaneous construction

20. GARUDA Framework • Two phase loss recovery • Loss detection • A-map • Loss Recovery • Loss recovery for core nodes • Loss recovery for non-core nodes

21. GARUDA Framework Broadcast Unicast • Two phase loss recovery • Loss recovery for core nodes phase If non-core node has the request packet, it intercepts the request and retransmits to downstream core. 3i Upstream core nodes a (Cid, A-map, bid, vFlag) 3i+1 b (Cid+NCid, A-map, bid, vFlag) 3i+2 If the number of id equal to three, then sets the vFlag to false. c (Cid+NCid+NCid, A-map, bid, vFlag) Downstream core nodes 3(i+1) d Downstream core node will check the A-map from Upstream.

22. GARUDA Framework • Two phase loss recovery • Loss recovery for non-core nodes phase • A non-core node snoops all transmission from its core nodes. • Once it observes an A-map from its core node with all the bits set, it enters the non-core recovery phase by initiating retransmission requests to the core node. • If it doesn’t hear from its core node for the period core presence timer, it sends an request to the core node to which the core node responds with its current A-map.

23. GARUDA Framework • Supporting other reliability semantics • The variants differ in which subset of nodes receive the message delivery. • Referring to the problem of determining the subset as the candidacy problem. Candidate nodes Forced Candidate nodes (core band)

24. GARUDA Framework • Supporting other reliability semantics • Candidate nodes selection • Sub-region • Sub-region information is piggybacked on the first packet. • Cover sensing field • Sensing range ≦ Transmission range • Non-core nodes seek permission from their core nodes to become candidate nodes. • Probabilistic subset • Local process: each node chooses itself as a candidate node with a probability of p.

25. GARUDA Framework • Supporting other reliability semantics • Forced candidate nodes selection Sink Sensor node Core node Forced candidate 3i+1 3i+2 3i 3i+1 3i+2 3i

26. Performance Evaluation • Simulator: NS2 • Network Size: 650m x 650m • Nodes Deployment— • First 100 nodes to ensure connectivity • Sink is located at the center of one of the edges of the square. • Radio Range:67m • Channel Capacity: 1Mbps • Each message consists of 100 packets. • Transmission rate: 25 packets/s • Packet size: 1KB

27. Performance Evaluation • Single Packet Delivery • Latency

28. Performance Evaluation • Single Packet Delivery • Number of data packet sent

29. Performance Evaluation • Single Packet Delivery • Energy consumption per node

30. Performance Evaluation • Multiple Packet Delivery • Latency

31. Performance Evaluation • Multiple Packet Delivery • Number of data packet sent

32. Performance Evaluation • Multiple Packet Delivery • Energy consumption per node

33. Performance Evaluation • Evaluation of Variants • Sub-region

34. Performance Evaluation • Evaluation of Variants • Sub-region

35. Performance Evaluation • Evaluation of Variants • Minimal number of sensors

36. Performance Evaluation • Evaluation of Variants • Probability

37. Conclusion • It proposed a new framework for providing sink-to-sensors reliability in WSNs. • GARUDA • WFP pulses • Core node • A-map • Two stage recovery • Future work: Multi-sink