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

1. 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

2. Outline • Motivation • Problem Definition • IFRC Mechanisms Design • IFRC Parameters Design • Simulation Results • Conclusions

3. Outline • Motivation • Problem Definition • IFRC Mechanisms Design • IFRC Parameters Design • Simulation Results • Conclusions

4. 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

5. Given a wireless network of N nodes transmitting to a single base station over multiple hops “Design a distributed algorithm to dynamically allocate fairand efficient transmission rates to each node” Neighbor Child/Parent Goal All rates are End-to-End

6. Outline • Motivation • Problem Definition • IFRC Mechanisms Design • IFRC Parameters Design • Simulation Results • Conclusions

7. Problem Definition • What’s a fair and efficient rate allocation? • Fair rate allocation: max-min fairness Let 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

8. 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.

9. 10 Neighbor Child/Parent 11 12 13 14 15 16 17 18 19 20 21 Problem Definition (An Example) Routing subtree • 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. Problem Definition • fi : flow originating from node i • Fi : flows routed through node i • 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. • Allocate to each flow in Ғia fair and efficient share of the radio nominal data rate B. Denote by fl,ithe rate allocated at node i to flow l. • Repeat this calculation for each node. • Assign to flthe minimum of fl,i over all nodes i.

11. Outline • Motivation • Problem Definition • IFRC Mechanisms Design • IFRC Parameters Design • Simulation Results • Conclusions

12. ri Forwarding Traffic Packet transmitted until queue is empty (with retransmission) 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) Queue at each node

13. every 1/ri sec ri = ri+δ/ri ri = ri /2 ri = ri /2 ri = ri /2 L U U + I U + 3I/2 every 1/ri sec ri = ri+δ/ri ri remains unchanged 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

14. 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 rlamong all its congested children • Average queue length of the most congested child ql, avg

15. Neighbor Child/Parent j i k l Congestion Sharing Rule 1: rican 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 )

16. Rate Adaptation • Slow-start • Starts with rinit • Every 1/ risec • 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/ risec • ri = ri + δ/ ri

17. every 1/ri sec ri = ri+δ/ri ri = ri /2 ri = ri /2 ri = ri /2 L U U + I U + 3I/2 every 1/ri sec ri = ri+δ/ri ri remains unchanged Rate Adaptation • Steady state • Every 1/ risec ri = ri + δ/ ri • When local average queue, qi,avg crosses any threshold U(k) ri = ri /2

18. 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 rbonly 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

19. Outline • Motivation • Problem Definition • IFRC Mechanisms Design • IFRC Parameters Design • Simulation Results • Conclusions

20. 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 )

21. rmin=rmax Rate ri +δ 2 t1 1 t2= rmin/ δ δ slope = tanθ=δ θ ri t t+1 Time Rate rmax Excess Load r1 Multiplicative Decrease slope = δ r2 rst Additive Increase Time 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

22. 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,

23. 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)

24. Outline • Motivation • Problem Definition • IFRC Mechanisms Design • IFRC Parameters Design • Simulation Results • Conclusions

25. 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

26. 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

27. Comparison with Optimal each 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

28. Rate Adaptation and Instantaneous queue length Slow start AIMD Not a single drop due to queue overflow (queue length <20 less than queue size 64)

29. Per-node goodput with high δ Result in unfair rate

30. IFRC works without modification Each node sends wi packet every risec Extension to IFRC1. Weighted Fairness

31. Subset of node • Special case of weighted fairness • nodes with no data to send →wi = 0

32. 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

33. Outline • Motivation • Problem Definition • IFRC Mechanisms Design • IFRC Parameters Design • Simulation Results • Conclusions

34. 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

35. Conclusions • Strength: • Not only qualitative analysis but also detailed deduction of quantitative analysis • Reasonable simplification and assumption are made to find out proper parameters

36. 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

37. 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?