Upload
roger
View
33
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Interference-Aware Fair Rate Control in Wireless Sensor Networks (IFRC). Sumit Rangwala, Ramakrishna Gummadi, Ramesh Govindan, Konstantinos Psounis University of Southern Califonia To appear in SIGCOMM 2006 Presenter : Ahey Date : 2006/08/04. Outline. Motivation Problem Definition - PowerPoint PPT Presentation
Citation preview
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?