1 / 32

Data Collection and Dissemination

Data Collection and Dissemination. Outline. Data Dissemination Trickle – Address single packet Data Collection DSF. Data Dissemination - Trickle. Simple Broadcast Retransmission. Broadcast Storm Problem Redundant rebroadcasts Severe contention Collision. Trickle. Motivation

oma
Download Presentation

Data Collection and Dissemination

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data Collection and Dissemination

  2. Outline • Data Dissemination • Trickle – Address single packet • Data Collection • DSF

  3. Data Dissemination - Trickle [Dissemination_1]

  4. Simple Broadcast Retransmission • Broadcast Storm Problem • Redundant rebroadcasts • Severe contention • Collision

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

  6. Trickle Requirement • Low Maintenance • Rapid Propagation • Scalability

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

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

  9. 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, τ]

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

  11. 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 [Dissemination_1]: Figure 5

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

  13. 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 [Dissemination_1]: Section 5

  14. Trickle Complete Algorithm

  15. Data Collection

  16. 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 [Collection_2]

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

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

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

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

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

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

  23. Sensor States Representation 1 0 1 1 0 1 0 1 Off On • Scheduling Bits • (10110101)* • Switching Rate • 0.5HZ 16s round time

  24. Data Delivery Process ( 1 0 0 0 0 0 0 0 0 0 )* ( 0 1 0 0 0 0 0 0 0 0 )* ( 0 0 0 1 0 0 0 0 0 0 )* ( 0 0 0 0 0 0 1 0 0 0 )* 1 2 3 4 Sleep latency is 1 Sleep latency is 2 Sleep latency is 3 End to End (E2E) Delay is 6

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

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

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

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

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

  30. Distributed Implementation • EDRb(Ø) = 1 • The sink node has no packet loss • EEDb(Ø) = 0 • The sink node has no delay • EECb(Ø) = 0 • The sink node has no energy consumption

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

  32. Complete Protocol Implementation at Node e

More Related