Interference-Aware Fair Rate Control in Wireless Sensor Networks (IFRC)

Sumit Rangwala, Ramakrishna Gummadi, Ramesh Govindan, Konstantinos Psounis

University of Southern CalifoniaTo appear in SIGCOMM 2006

Presenter : AheyDate : 2006/08/04

Outline

Motivation Problem Definition IFRC Mechanisms Design IFRC Parameters Design Simulation Results Conclusions

Outline

Motivation Problem Definition IFRC Mechanisms Design IFRC Parameters Design Simulation Results Conclusions

Motivation

High data-rate application are emerging An event is sensed → a large number of

nodes transmit many raw sample data along routing tree to base station

In tiered sensor network, lower-tier nodes (tiny wireless sensor) transmit data to upper-tier node (usu. an embedded 32bit system)

ex. Structural Health Monitoring

Rate control prevents congestion collapse

Goal

Given a wireless network of N nodes transmitting to a single base station over multiple hops

“Design a distributed algorithm to dynamically allocate fair and efficient transmission rates to each node”

All rates are End-to-End

NeighborChild/Parent

Outline

Motivation Problem Definition IFRC Mechanisms Design IFRC Parameters Design Simulation Results Conclusions

Problem Definition What’s a fair and efficient rate allocation? Fair rate allocation: max-min fairnessLet r=r1, r2,…rk be the vector of the rates allocated to k sources.

min(r): the minimum rate allocated to any source.

For all other possible allocation r’, min(r)≥min(r’)

Efficiency criteria:Without reducing fairness, the capacity of the network is

utilized to its maximum

Problem Definition Measurement metrics Based on end-2-end goodput of each flow,

i.e. the number of packets received from a node at the base station.

IFRC is not a transmission scheduling scheme.

It is a transport layer protocol , works above the MAC layer to provide transport-layer fairness to the flows.

Problem Definition (An Example)

Interfering link Transmission along a link l1

prevents transmission along l2

→ l1 interfere with l2 Congestion around node 16 Potential interferers of node 16 :

nodes belonging to the congested region 16, 20 , 21(node’s subtree) 14, 13, 12, 17 (parent’s

subtree+ parent’s neighbor) 15, 18, 19 (parent’s neighbor’s

subtrees)

10

11

13 14

16

15

17 1918

12

2120

Neighbor

Child/Parent

Routing subtree

Problem Definition fi : flow originating from node i Fi : flows routed through node i

1. At each node i, define Ғi to be the union of Fi and all sets Fj

• where j is either a neighbor of i, or a neighbor of i’s parent. Ғi includes flows from all of i’s potential interferers.

2. Allocate to each flow in Ғi a fair and efficient share of the radio nominal data rate B. Denote by fl,i the rate allocated at node i to flow l.

3. Repeat this calculation for each node.4. Assign to fl the minimum of fl,i over all nodes i.

Outline

Motivation Problem Definition IFRC Mechanisms Design IFRC Parameters Design Simulation Results Conclusions

IFRC Mechanisms Congestion Detection

Based on current average queue length and congestion thresholds

Congestion Sharing Signal all potential interferers

during congestion at a particular node

Rate Adaptation AIMD (Additive Increase

Multiplicative Decrease)

ri

Forwarding Traffic

Packet transmitted until queue is empty (with retransmission)

Queue at each node

Congestion Detection Based on EWMA (Exponential Weighted Moving Average) of

instantaneous queue length avgq = (1-wq)*avgq + wq*instq Multiple thresholds

Lower threshold L Upper thresholds U(k) = U(k-1) + I/2k-1

U(0) = U When queue size↑, a node is congested if qavg > U → ri = ri /2 When queue size↓, a node is congested if qavg > L

ri remains unchanged

L U

every 1/ri secri = ri+δ/ri

ri = ri /2

U + I U + 3I/2

ri = ri /2 ri = ri /2

every 1/ri secri = ri+δ/ri

Congestion Sharing

Piggybacking on every transmitted packet Current local rate ri

Current average queue length qi,avg

A bit indicating whether any child of i is congested Smallest rate rl among all its congested children Average queue length of the most congested child ql, avg

Congestion SharingRule 1:

ri can never exceed the rj , rate of i’s parent.

Rule 2: Whenever a congested neighbor (including parent) j of i crosses a congestion threshold U(k) (for any k),

ri = min(ri, ,,rj )or if the most congested child of i’s neighbor l crosses a congestion threshold U(k) (for any k),

ri = min(ri, , rl )

j

i k

l

Neighbor

Child/Parent

Rate Adaptation Slow-start

Starts with rinit Every 1/ ri sec

ri = ri + Φ

Slow-start ends when i gets congested ri greater than rj,where j is i’s parent ri greater than rj,where i is j’s potential interferer

Go to Additive Increase after the 2nd or 3rd condition happens Every 1/ ri sec

ri = ri + δ / ri

Rate Adaptation Steady state

Every 1/ ri sec ri = ri + δ / ri

When local average queue, qi,avg crosses any threshold U(k) ri = ri /2

ri remains unchanged

L U

every 1/ri secri = ri+δ/ri

ri = ri /2

U + I U + 3I/2

ri = ri /2 ri = ri /2

every 1/ri secri = ri+δ/ri

Base Station

Maintains rb, like ri of any other node, to share congestion across nodes

Follows the same algorithm for rate adaptation with one exception Decreases rb only when a child j of base station is

congested (rj >U(k) for any k) . It does not decreases its rate when any non-child

neighbor or any neighbor’s child is congested

Outline

Motivation Problem Definition IFRC Mechanisms Design IFRC Parameters Design Simulation Results Conclusions

Parameter Selection Congestion detection

thresholding : L ,U(0) , I (related to # of hops) EWMA weight : wq ( )

Rate adaptation Slow-start : rinit , ΦFor tree-based, sustainable sending rate rst is of order of

O(1/nlogn), conservatively set Initial rate rinit = B/10nlogn

Avoid slow-start overshooting rst, set Φ= rinit /8

Additive increase :δ (related to ε, rmin,i, Fj, U0, U1, s2 )

Parameter Selection Intensity of AIMD

ri = ri + δ/ ri → ri (t) = δ* t

t1= t2*r1/r2 = (rmax–rst)/δ

excess load = r1*t1/2 = (rmax–rst)2/ 2δUnderutilized capacity = (r2-r1)*t1/2

= (rmax–rst)(rst–rmin)/ 2δexcess load < underutilized capacity and

→

Avoid ri jumping from rmin,i to rmax,i

set δ = ε rmin,i2

Where is the rate during last multiplicative decrease

Rateri +δ

1tri t+1

slope = tanθ=δθ

δ

Time

Time

Ratermax

Excess Load

rst

slope = δ

t2= rmin/ δ

rmin=rmax

2

Multiplicative Decrease

Additive Increase

t1

r1

r2

Parameter Selection Iij : =1 if pkt from node i traverse j =0 otherwise Total # of excess pkt at j =

fij : reflects # of time slots j cannot transmit due to transmission of excess pkt by j’s potential interferer

Uk : instantaneous queue length for EWMA queue length to exceed U(k)

Avoid multiple multiplicative decrease

si : # of rate updates at node i before it receive congestion information from j , usu. set to as the average network radius

Take propagation delay into account,

Parameter Selection Define ,

Set to 1.5 ,sacrificing convergence time

(when Fj is small) and

As a rule of thumb, Fj =n logn for balanced tree.

ε depends on Size of the network (n) Queue Thresholds (U0, U1) By rule of thumb :U0= N/2 and U1= N

Average depth of the tree ( s = average network radius)

Outline

Motivation Problem Definition IFRC Mechanisms Design IFRC Parameters Design Simulation Results Conclusions

Evaluation Platform

Tmote Sky TinyOS 1.1.15

Setup 40 Node testbed

Network diameter = 8 hops Static Tree

Depth of the Tree = 9 hops Link quality varied from 66% to 95%

Each experiment lasted for an hour Metrics

Fairness: per-flow goodput & pkt reception rate Efficiency: pkt loss & compared with optimal goodput &

instantaneous queue length & dynamical adaptation

Per Flow Goodput & Packet Reception Per-flow goodput = total # of pkt rcv from base station divided by the

duration of experiment

(green : pkt loss ; red : average rate) Per-flow pkt reception = # of pkt rcv at the sink as a fx of time

Comparison with Optimaleach node to send at a fixed rate R R=0.36, achieve 60% (0.22/0.36) of the max.

sustainable fair rate Above 0.36 pkt/sec, buffer overflow (queue

length>64)

R=0.27, achieve 80% (0.22/0.27) of the max. sustainable fair rate

Above 0.27 or 0.36 pkt/sec, max/min goodput ratio divert from 1

Rate Adaptation and Instantaneous queue length

Not a single drop due to queue overflow (queue length <20 less than queue size 64)

Slow start AIMD

Per-node goodput with high δ

Result in unfair rate

Extension to IFRC1. Weighted Fairness

IFRC works without modification Each node sends wi packet every ri sec

Subset of node

Special case of weighted fairness nodes with no data to send → wi = 0

Two base station rooted at 1 and 41 Nodes gets rate that

are fair across trees IFRC is efficient

Node 4,5 and 6 get greater (but equal) rates

Their flow isn’t part of the most congested region.

Extension to IFRC2. Multiple base station

Not in congested region

Outline

Motivation Problem Definition IFRC Mechanisms Design IFRC Parameters Design Simulation Results Conclusions

Conclusions Contribution:

Derived from TCP flow control mechanism, IFRC is the first practical rate control mechanism for wireless sensor network

With hop-by-hop recovery (using a limited # of retransmissions), IFRC can recover from most end-to-end losses (8% pkt loss)

Queue management strategy prevents packet drops due to queue overflow

Conclusions Strength:

Not only qualitative analysis but also detailed deduction of quantitative analysis

Reasonable simplification and assumption are made to find out proper parameters

Conclusions Weakness:

A more complete validation of analysis on IFRC parameters needed (Too many rules of thumb)

A complete analysis of the impact of other parameters on IFRC performance needed

It is said that IFRC provides fairness within 20-40% of the optimal fair rate achievable

No detail deduction show this result Is the figure 20-40% significant?

The value of parameters is based on the formulae shown. But they don’t provide exact solution, need to set them ourselves If it shows by which inequality and assumption he got the value, it

would be better

Relevance to our research They use real testbed rather than TinyOS

simulation to evaluate performance. In sensor network, simple is better or we still

need do QoS for some application (eg. high data-rate application)?

Can we apply this to our hospital sensor network project?