RBP: Robust Broadcast Propagation in Wireless Networks

Fred Stann, John Heidemann, Rajesh Shroff, Muhammad Zaki MurtazaUSC/ISIIn SenSys 2006

Outline

Introduction Related work RBP algorithm Analysis Implementation Simulation results Testbed results Further simulations Conclusion

What is Flooding?

Every node broadcast To let every node receive the message

Flooding in Wireless Networks

Route discovery DSR, AODV

Resource discovery Directed diffusion

Network-integrated database systems TinyDB

Why is Broadcast Unreliable?

Collision Collision detection/avoidance

PHY layer capture MAC layer TDMA Application layer jitter

Unreliable wireless link Retransmission

May incur unnecessary overhead No RTS-CTS-data-ACK

Prevent control traffic implosion Directly reflect the reliability of wireless channel

Related Work

Wired Networking

Reliable multicast SRM, RMTP 100% reliability, repair triggered by

missing sequence number RBP relaxed 100% slightly for

efficiency, and focus on individual flood

Wireless for improved reliability

Probabilistic broadcast Reduce collisions and energy consumption Requires 8+ neighbors (high density)

Gossiping multiple rounds of exchanges Local repair of missed data

RBP adapts to density and recognizes failed delivery by overhearing

Wireless for improved reliability

Area-based method in MANETs Using knowledge of complete node locati

ons/distances to suppress redundant broadcasts

Minimize the bandwidth consumed RBP does not focus on efficiency, and

only requires local information

Wireless with perfect reliability

Application such as reprogramming the entire network (Deluge)

TDMA for contention free reliable broadcast

RBP Does not do TDMA because wireless is

volatile Does NOT focus on applications

demanding perfect reliability

Short Summary

Goals of RBP Tries to improve reliability but not 100% Adapts to neighborhood density Does not focus on redundancy

suppression

Algorithm

Ideas of RBP

Detect delivery failure by overhearing Implicit ACK

Adapts retransmission threshold and times to neighborhood density Reduce redundant broadcast

Important link detection Bottleneck!

RBP Algorithm – Step 1

A node knows the identity of its one hop neighbors Neighbor must have inbound and

outbound connectivity No weak and asymmetric neighbors

RBP Algorithm – Step 2

Retransmission Every node would forward the flooding

packets at the first time Nodes snoop and keep track of neighbor

rebroadcast (implicit ACK) If this rebroadcast record is lower than a

percentage of neighbors, the node again retransmit the packet

RBP Algorithm – Step 3

Retransmission threshold and number of retries are adjusted based on neighborhood density

Detection of important links

RBP Algorithm – Step 4

High density with one especially important link

RBP Algorithm – Step 4

Every node keeps a histogram of the neighbor first transmitting unheard broadcast

If a single neighbor has the majority, sends a control message to inform this important link

Short Summaryneighbor threshold retry

1-3 100% 3

4-6 66% 2

7+ 50% 1

Analysis

Uniformly Distributed Network

Previous studies shown that the reliability will increase while network density increases

In real deployment, uneven distribution is common

High density around the source but low density away could give misleading reliability

Effect of Multi-pathAssume per link reliability 85%

P(e2e) = 85%*85%*85%=61%

P(e2e) = 1-(1-61%) (1-61%) (1-61%)

= 94%

Effect of Multi-path

P(e2e) = 99.9%

Flooding is inherently reliable

What if a bottleneck

Bounded by bottleneck link 85%

Implementation

Settings

Environment: EmStar Directed diffusion and B-MAC

One-phase-pull Resides between routing and MAC RBP timeout 10 sec

Diffusion has 1 sec forwarding delay and 800ms jitter

Neighborhood Discovery

Modules provided by EmStar Broadcast packets have sequence nu

mber and inbound connectivity attached

Compute over 12 broadcast pkts Use upper and lower reliability threshol

d (70% and 60% in testbed)

Simulation Results

Settings

Environment: EmSim Directed diffusion resource discovery fl

ood every 60 sec No flooding overlap No data sources

Error Model

EmSim provides an communication error model, but computed independently for each tx/rx pair

Is real-world packet loss spatially correlated?

Error Model

Experiment of 8 stargate node surrounding one sender.

Independence of receiver errors

Correlated transmission failures

Metrics

Reliability: percentage of floods that traverse the network diameter

Bytes-per-flood: sum of byte transmissions triggered by a single event

Reliability Cost Metric (RCM)

Number of floods required to achieve near-perfect reliability

Worst case: bottleneck link exits

If propagation reliability is 85%, 20 nodes, 80 byte broadcast pakcet. F=2.4, measured BytesPerFlood=1200

RCM=1.8 F=1 for RBP

Cost of a perfect flood

Topology

Results - ReliabilityTRP: rebroadcast whenever less than 99% of neighbors receiving up to 4 times (MAC-only)

Results - BytesPerFlood

Results - RCM

RBP degrades to TRP in low density networks

Unnecessary attempts to achieve reliability when density is high

Testbed Results

Testbed

20 stargate nodes Nonuniform connectedness

Results

Close to the simulation result

Results

They initially do not add the important link detection.

RBP reliability is slightly better than single flood and RCM higher

Further Simulation

Effect of Density

Effect of Density

High density reduce the advantage of RBP

Effect of Correlated Error

Density fixed to 6 neighbors

Effect of Pair-wise Error

With enough density, single link failure has less impact on flooding

Future work and conclusion

State-limited version Focus on end-to-end reliability Variable density Real testbed results