Reliable Bursty Convergecast in Wireless Sensor Networks

Preview:

DESCRIPTION

Reliable Bursty Convergecast in Wireless Sensor Networks. Hongwei Zhang, Anish Arora Young-ri Choi, Mohamed Gouda. Thanks: Lites & ExScal teams. Application context. A Line in the Sand (Lites) - PowerPoint PPT Presentation

Citation preview

April 19, 2023

Reliable Bursty Convergecast in Wireless Sensor Networks

Hongwei Zhang, Anish Arora Young-ri Choi, Mohamed Gouda

Thanks: Lites & ExScal teams

Application context

A Line in the Sand (Lites)

field sensor network experiment for real-time target

detection, classification, and tracking

A target can be detected by tens of nodes

Traffic burst

Bursty convergecast

Deliver traffic bursts to a base station nearby

Problem statement

Only 33.7% packets are delivered with the default

TinyOS messaging stack

Unable to support precise event classification

Our objectives

Close to 100% reliability

Close to optimal event goodput (real-time)

Experimental study for high fidelity

Outline

Testbed

Limitations of two commonly used mechanisms

Protocol RBC

Experimental results

Concluding remarks

Network setup

Network

49 MICA2s in a 7 X 7 grid

5 feet separation

Power level: 9 (for 2-hop

reliable communication

range)

Logical Grid Routing (LGR)

It uses reliable links

It spreads traffic uniformly

base station

Traffic trace from Lites

Packets generated in a 7 X 7 subgrid, when a vehicle passes across the middle of the Lites network

Optimal event goodput:

6.66 packets/second0 5 10 150

20

40

60

80

100

Time (seconds)

# o

f pa

cke

ts g

en

era

ted

Outline

Testbed

Limitations of two commonly used mechanisms

Protocol RBC

Experimental results

Concluding remarks

Retransmission based packet recovery

At each hop, retransmit a packet if the corresponding

ACK is not received after a constant time

Synchronous explicit ack (SEA)

Explicit ACK immediately after packet reception

Shorter retransmission timer

Stop-and-wait implicit ack (SWIA)

Forwarded packet as an ACK

Longer retransmission timer

SEA

Retransmission does not

help much, and may

even decrease reliability

and goodput

Similar observations

when adjusting

contention window of B-

MAC and using S-MAC

Retransmission-incurred

contention

Metrics RT= 0 RT= 1 RT= 2

Reliability (%) 51.05 54.74 54.63

Delay (sec) 0.21 0.25 0.26

Goodput (pkt/sec) 4.01 4.05 3.63

0 5 10 150

20

40

60

80

100

Time (seconds)

# o

f pa

cke

ts r

ece

ive

d RT = 0RT = 1RT = 2

SWIA

Again, retransmission

does not help

Compared with SEA,

longer delay and lower

goodput/reliability

longer retransmission

timer & blocking flow

control

More ACK losses, and

thus more

unnecessary

retransmissions

Metrics RT= 0 RT= 1 RT= 2

Reliability (%) 43.09 31.76 46.5

Delay (sec) 0.35 8.81 18.77

Goodput (pkt/sec) 3.48 2.58 1.41

0 5 10 15 20 25 30 350

20

40

60

80

100

Time (seconds)

# o

f pa

cke

ts r

ece

ive

d RT = 0RT = 1RT = 2

Outline

Testbed

Limitations of two commonly used mechanisms

Protocol RBC

Experimental results

Concluding remarks

Protocol RBC

Differentiated contention control

Reduce channel contention caused by packet retransmissions

Window-less block ACK

Non-blocking flow control

Reduce ack loss

Fine-grained tuning of retransmission timers

Window-less block ACK

Non-blocking window-less queue management Unlike sliding-window based black ACK, in order packet delivery

is not considered Packets have been timestamped

For block ACK, sender and receiver maintain the “order” in which packets have been transmitted

“order” is identified without using sliding-window, thus there is no upper bound on the number of un-ACKed packet transmissions

Sender: queue management

static

physical queue

ranked

virtual queues (VQ)

VQ0 1 2

VQ1 3 4 5

VQM

VQM+1 6

high

low

occu

pie

dem

pty

ID of buffer/packet

M: max. # of retransmissions

Sender: gets a packet from an upper layer

VQ0 1 2

VQ1 3 4 5

VQM

VQM+1 6

empty queue buffer?

Sender: transmits a packet

VQ0 1

VQ1 3 4 5

VQM

VQM+1 6

2

1,

earlier later

2

order of transmission

fresher

older

Receiver: loss detection

i i, j

if no packet loss, expecting packet

j

i’

=

no loss

some loss

i’ = j

Receiver: block ACK

i j

i, j

k

i, k i, i

k’

i, k’

ACK replication !

Sender: processes a block ACK

VQ0 1 2

VQ1 3 4 5

VQM

VQM+1 6

3, 5

Differentiated contention control

Schedule channel access across nodes

Higher priority in channel access is given to

nodes having fresher packets

nodes having more queued packets

Implementation of contention control

The rank of a node j = M - k, |VQk|, ID(j) , where

M: maximum number retransmissions per-hop

VQk: the highest-ranked non-empty virtual queue at j

ID(j): the ID of node j

A node with a larger rank value has higher priority

Neighboring nodes exchange their ranks Lower ranked nodes leave the floor to higher ranked ones

Fine tuning retransmission timer

Timeout value: tradeoff between

delay in necessary retransmissions

probability of unnecessary retransmissions

In RBC

Dynamically estimate ACK delay

Conservatively choose timeout value; also

reset timers upon packet and ACK loss

Outline

Testbed

Limitations of two commonly used mechanisms

Protocol RBC

Experimental results

Concluding remarks

Event-wise

Retransmission helps

improve reliability and

goodput

close to optimal

goodput (6.37 vs.

6.66)

Compared with SWIA,

delay is significantly

reduced

1.72 vs. 18.77 seconds

Metrics RT= 0 RT= 1 RT= 2

Reliability (%) 56.21 83.16 95.26

Delay (sec) 0.21 1.18 1.72

Goodput (pkt/sec) 4.28 5.72 6.37

0 5 10 150

20

40

60

80

100

Time (seconds)

# o

f pa

cke

ts r

ece

ive

d RT = 0RT = 1RT = 2

Distribution of packet generation and reception

RBC

Packet reception

smoothes out and almost

matches packet

generation

SEA

Many packets are lost

despite quick packet

reception

SWIA

Significant delay and

packet loss

0 10 20 30 400

20

40

60

80

100

Time (seconds)

# o

f pa

cke

ts

Lites traceSEASWIARBC

Breakdown of RBC

Metrics RT= 0 RT= 1 RT= 2

Reliability (%)RBC 56.21 83.16 95.26

RBC-NoDiffCtrl 54.90 77.19 82.29

Latency (sec)RBC 0.21 1.18 1.72

RBC-NoDiffCtrl 0.22 1.12 1.52

Goodput

(pkt/sec)

RBC 4.28 5.72 6.37

RBC-NoDiffCtrl 4.04 4.13 4.12

RBC-NoDiffCtrl: RBC without Differentiated Contention Control

Contention control plays an increasingly important role as RT (thus channel contention) increases

Field deployment

A Line in the Sand (Lites)

~ 100 MICA2’s

10 X 20 meter2 field

Sensors: magnetometer, micro impulse radar (MIR)

ExScal

~ 1,000 XSM’s, ~ 200 Stargates

288 X 1260 meter2 field

Sensors: passive infrared radar (PIR), acoustic

sensor, magnetometer

Outline

Testbed

Limitations of two commonly used mechanisms

Protocol RBC

Experimental results

Concluding remarks

Concluding remarks

With its unique traffic pattern and performance requirements, bursty convergecast

poses new challenges to error control Non-blocking packet delivery Retransmission scheduling

also offers opportunities E.g., reorder-tolerance

Other applications Continuous event convergecast Data aggregation

to use explicit ack

Recommended