1. Data Collection and Dissemination

2. Learning Objectives Understand Trickle – an data dissemination protocol for WSNs Understand data collection protocols in low- duty-cycled WSNs with unreliable links

3. Prerequisites Module 5 Basic concepts of Computer Networks

4. Outline Data Dissemination –Estrablishing eventual consistency on a shared variable –Trickle – Address single packet Data Collection –DSF

5. [Dissemination_1]5 Data Dissemination - Trickle

6. Simple Broadcast Retransmission Broadcast Storm Problem –Redundant rebroadcasts –Severe contention –Collision

7. Trickle Motivation –WSNs require network code propagation Challenges –WSNs exhibit highly transient loss patterns, susceptible to environmental changes –WSNs network membership is not static –Motes must periodically communicate to learn when there is new code Periodical metadata exchange is costly

8. Trickle Requirement Low Maintenance Rapid Propagation Scalability

9. Trickle An algorithm for code propagation and maintenance in WSNs Based on “Polite Gossip” –Each node only gossip about new things that it has heard from its neighbors, but it won’t repeat gossip it has already heard, as that would be rude Code updates “trickle” through the network

10. Trickle Within a node time period –If a node hears older metadata, it broadcasts the new data –If a node hears newer metadata, it broadcasts its own metadata (which will cause other nodes to send the new code) –If a node hears the same metadata, it increases a counter If a threshold is reached, the node does not transmit its metadata Otherwise, it transmits its metadata

11. Trickle – Main Parameters Counter c: Count how many times identical metadata has been heard k: threshold to determine how many times identical metadata must be heard before suppressing transmission of a node’s metadata t: the time at which a node will transmit its metadata. t is in the range of [0, τ]

12. [Dissemination_1]: Figure 312 Trickle Maintenance – One Example Assume –No packet loss –Perfect interval synchronization How to relax these assumptions?

13. Trickle – Impact of Packet Loss Rates

14. [Dissemination_1]: Figure 514 Trickle Maintenance without Synchronization – Short Listen Problem Mote B selects a small t on each of its three intervals –Although other motes transmit, mote B’s transmissions are never suppressed The number of transmissions per intervals increases significantly

15. Trickle – Impact of Short Listen Problem

16. Solution to Short Listen Problem Instead of picking a t in the range [0, τ], t is selected in the range [τ/2, τ]

17. [Dissemination_1]: Section 517 Propagation Tradeoff between different values of τ –A large τ Low communication overhead Slowly propagates information –A small τ High communication overhead Propagate more quickly How to improve? –Dynamically adjust τ Lower Bound τ l Upper Bound τ h

18. Trickle Complete Algorithm

19. Data Collection

20. [Collection_2]20 Data Collection Link-Quality based Data Forwarding –Wireless communication links are extremely unreliable –ETX: to find high-throughput paths on multiple Sleep-Latency Based Forwarding –Duty Cycling: sensor nodes turn off their radios when not needed Idle listening waste much energy

21. [Collection_2]21 Sleep Latency in Low Duty-Cycle Sensor Networks Sleep now. Wake up in 35 seconds Sleep now. Wake up in 4 seconds Sleep now. Wake up in 57seconds Sleep now. Wake up in 13 seconds 35s latency 57s latency 4s latency13s latency A B C D E

22. Unreliable Radio Links 90% 95% 50% 70% A B C D E

23. State-of-the-art Solutions: ETX 50%, 100s 40%, 10s ETX = 1/0.5 + 1/0.5 = 4 ETX = 1/0.4 + 1/0.4 = 5 Expected E2E delay is 400s Expected E2E delay is 50s A B C D Sole link quality based solutions cannot help reduce E2E delay in extremely low-duty cycle sensor networks! ETX only considers link quality

24. State-of-the-art Solutions: DESS 10%, 10s 100%, 20s DESS = 10 + 10 = 20s DESS = 20 + 20 = 40s Expected E2E delay is 200s Expected E2E delay is 40s A B C D Sole sleep latency based solutions cannot help reduce E2E delay in extremely low-duty cycle sensor networks! DESS only considers sleep latency

25. End-to-End Delay vs. Duty Cycle Suppose one fixed forwarding node –Suffer excessive delivery delays when waiting for the fixed receiver to wake up again if the ongoing packet transmission fails

26. End-To-End Delay vs. Average Link Quality Given bad link quality, the end to end delay increases dramatically

27. Sensor States Representation Scheduling Bits –( 10110101 )* Switching Rate –0.5HZ  16s round time On 10110101 Off

28. Data Delivery Process 1 1 2 2 3 3 4 4 Sleep latency is 1Sleep latency is 2Sleep latency is 3 End to End (E2E) Delay is 6 (1000000000)*(0100000000 (0001000000 (0000001000

29. 1 st attempt: Sleep latency is 1 Main Idea 1 1 2 2 3 3 4 4 (1000000000)*(0100000000 (0001000000 (0000001000 Sleep latency is 1 2 nd attempt: Sleep latency is 1 + 10 =11 i th attempt: Sleep latency is 1 + 10 * (i-1) (0010000000)* 5 5 2 nd attempt: Sleep latency is 1 + 1 =2 We should try a sequence of forwarding nodes instead of a fixed forwarding node! Dynamic Switching-based Forwarding (DSF) is important in extremely low duty-cycle sensor networks.

30. Optimization Objectives EDR: Expected Delivery Ratio EED: Expected End-to-End Delay EEC: Expected Energy Consumption

31. Optimization Objectives(1) : EDR 1 1 3 3 4 4 (100)* EDR = 90% (001)* EDR = 80% (010)* EDR = 70% 2 2 60% 50% 40% EDR: Expected Delivery Ratio. 0.6*0.7+ (1-0.6)*0.5*0.8 + (1-0.6)*(1-0.5)*0.4*0.9 EDR for node 1 is (EDR 1 ): Forwarding Sequence

32. Optimization Objectives(1) : EDR 1 1 3 3 4 4 (1000)* (0001)* EDR = 90% (0010)* EDR = 80% (0100)* EDR = 70% 2 2 60% 50% 40% EDR: Expected Delivery Ratio. 0.6*0.7+ (1-0.6)*0.5*0.8 + (1-0.6)*(1-0.5)*0.4*0.9=0.652 EDR for node 1 is (EDR 1 ): Forwarding Sequence See Equation (3)

33. Optimization Objectives(2) : EED 1 1 3 3 4 4 (100000)* (000001)* EDR = 90%, EED = 9 (000010)* EDR = 80%, EED = 12 (001000)* EDR = 70%, EED = 10 2 2 60%,2 50%, 3 40%,5 EED: Expected E2E Delay. 0.6*1/0.7 * (2 + 10) + (1-0.6) * 0.5 * 1 /0.8 * (3 + 12) + (1- 0.6)*(1-0.5)*0.4*1/0.9 * (5 + 9) EED for node 1 is (EED): Forwarding Sequence See Equation (4)

34. Optimizing EDR 1 1 3 3 (100)* (001)* EDR = 80% 2 2 (010)* EDR = 70% 100% If only node 3 is selected as forwarding node: EDR 1 = 1 * 0.8 = 0.8 We should only choose a subset of neighboring nodes as forwarding nodes! Shall we try all available neighbors? If both node 2 and node 3 are selected as forwarding nodes: EDR 1 = 1 * 0.7 = 0.7

35. Optimizing EDR with dynamic programming 1 1 2 2 3 3 4 4 (100)* EDR = 90% (001)* EDR = 80% (010)* EDR = 70% 60% 50% 40% Select only a subset of neighbors as forwarders Node 4 has to be selected Then we attempt to add more nodes into the forwarding sequence backwardly. Try or skip Try or drop

36. Distributed Implementation EDR b (Ø) = 1 –The sink node has no packet loss EED b (Ø) = 0 –The sink node has no delay EEC b (Ø) = 0 –The sink node has no energy consumption

37. Distributed Implementation sink 4 4 2 2 1 1 3 3 EDR = 98%, EED = 2, EEC = 1EDR = 99%, EED = 15, EEC = 2 EDR = 100%, EED = 0, EEC = 0 EDR = 97%, EED = 20, EEC = 5 EDR = 90%, EED = 90, EEC = 12

38. Complete Protocol Implementation at Node e

39. Assignment 1. Please give one example to illustrate what the short-listen problem in the context of Trickle algorithms is. 2. How does Trickle algorithms solve the short-listen problem? 3. Why do not we use a constant τ in Trickle algorithm? 4. Why do we need to consider both link quality and the low-duty-cycle nature of wireless sensor networks when we design suitable applications?

40. 40 Project This is a group project. Each group can have up to 3 students Project Description In this project, you will develop a multi-hop data collection tree protocol based on TinyOS 2.x. 1. Development of a multi-hop data collection tree protocol 1.1 The protocol to form a multi-hop data collection tree The base station locally broadcast a tree construction message, which includes its own ID and its depth to be 0; a. When a node, say A, receives a tree construction message from node B at its first time (i.e., node A has not joined the data collection tree yet), node A assigns its depth to be the depth of node B plus one, and its parent to be node B. After this, node A rebroadcasts the tree construction message.

41. 41 Project - continue b. When a node, say A, already joins the data collection tree and receives a tree construction message from node B, node A just simply disregards the tree construction message. c. When a node, say A, already joins the data collection tree (suppose that node A’s parent is node B and node A’s depth is n) and receives a tree construction message from node C: 1. suppose that if node A selects node C as its parent, node A’s depth is m; 2. suppose m < n; node A will change its parent to node C.

42. 42 Project - continue one example multi-hop data collection tree

43. 43 Project - continue Also see attached slide tree.ppt for a dynamic view about how to construct a multi-hop data collection tree. 1.2 After the multi-hop data collection tree is formed, each node senses and transmits its light intensity to the base station every one second. For each received message, the base station displays the following information: –Node ID which originates the message; –Tree depth of the Node; –Sensed light value

44. 44 Project - continue Basic Steps: Please follow the steps listed below: 1. Setting up TinyOS environment - XubunTOS XubunTOS can be downloaded here: http://toilers.mines.edu/Public/XubunTOS 2. Go through the TinyOS tutorials at http://docs.tinyos.net/index.php/TinyOS_Tutor ials http://docs.tinyos.net/index.php/TinyOS_Tutor ials