Data Collection and Dissemination

Data Collection and Dissemination

Outline

• Data Dissemination– Trickle – Address single packet

• Data Collection– DSF

[Dissemination_1] 3

Data Dissemination - Trickle

Simple Broadcast Retransmission

• Broadcast Storm Problem– Redundant rebroadcasts– Severe contention– Collision

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

Trickle Requirement

• Low Maintenance• Rapid Propagation• Scalability

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

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

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

[Dissemination_1]: Figure 3 10

Trickle Maintenance – One Example

• Assume– No packet loss– Perfect interval synchronization

• How to relax these assumptions?

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

Solution to Short Listen Problem

• Instead of picking a t in the range [0, τ], t is selected in the range [τ/2, τ]

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

Trickle Complete Algorithm

Data Collection

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

Unreliable Radio Links

90%

95%

50%

70%

A

B

C

D

E

State-of-the-art Solutions: ETX

50%, 100s

50%, 100s

40%, 10s40%, 10s

ETX = 1/0.5 + 1/0.5 = 4

ETX = 1/0.4 + 1/0.4 = 5

Expected E2E delay is 400sExpected E2E delay is 50s

A

B

C

DSole link quality based solutions cannot help reduce E2E delay in extremely low-duty cycle sensor networks!

ETX only considers link quality

State-of-the-art Solutions: DESS

10%, 10s 10%, 10s

100%, 20s

100%, 20s

DESS = 10 + 10 = 20s

DESS = 20 + 20 = 40s

Expected E2E delay is 200sExpected E2E delay is 40s

A

B

C

DSole sleep latency based solutions cannot help reduce E2E delay in extremely low-duty cycle sensor networks!

DESS only considers sleep latency

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

End-To-End Delay vs. Average Link Quality

• Given bad link quality, the end to end delay increases dramatically

Sensor States Representation

• Scheduling Bits– (10110101)*

• Switching Rate– 0.5HZ 16s round time On

10110101

Off

Data Delivery Process

1 2 3 4

Sleep latency is 1

Sleep latency is 2

Sleep latency is 3

End to End (E2E) Delay is 6

(1000000000)* (0100000000)* (0001000000)* (0000001000)*

1st attempt: Sleep latency is 1

Main Idea

1 2 3 4(1000000000)* (0100000000)* (0001000000)* (0000001000)*

Sleep latency is 1

2nd attempt: Sleep latency is 1 + 10 =11ith attempt: Sleep latency is 1 + 10 * (i-1)

(0010000000)*

5

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

Optimization Objectives

• EDR: Expected Delivery Ratio

• EED: Expected End-to-End Delay

• EEC: Expected Energy Consumption

Optimization Objectives(1) : EDR

1 3

4

(100)*

(100)*EDR = 90%

(001)*EDR = 80%

(010)*EDR = 70%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 (EDR1):

Forwarding Sequence

See Equation (3)

Optimizing EDR

1

3

(100)*

(001)*EDR = 80%

2 (010)*EDR = 70%

100%

100% If only node 3 is selected as forwarding node:

EDR1 = 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:

EDR1 = 1 * 0.7 = 0.7

Optimizing EDR with dynamic programming

1

2

3

4

(100)*

(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 skip

Try or drop

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

Distributed Implementation

sink

42

1 3EDR = 98%, EED = 2, EEC = 1

EDR = 99%, EED = 15, EEC = 2

EDR = 100%, EED = 0, EEC = 0

EDR = 97%, EED = 20, EEC = 5 EDR = 90%, EED = 90, EEC =

12

Complete Protocol Implementation at Node e