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
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
6
Outline

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

7
Problem Definition

• Whats a fair and efficient rate allocation?
• Fair rate allocation max-min fairness
• Let rr1, 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
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(nodes subtree)
• 14, 13, 12, 17 (parents subtree parents
  neighbor)
• 15, 18, 19 (parents neighbors 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 is parent. ?i includes flows from all of is
  potential interferers.
• 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.
• Repeat this calculation for each node.
• Assign to fl the minimum of fl,i over all nodes i.

11
Outline

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

12
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
Congestion Detection

• Based on EWMA (Exponential Weighted Moving
  Average) of instantaneous queue length
• avgq (1-wq)avgq wqinstq
• 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 gt U
  
• ? ri ri /2
• When queue size?, a node is congested if qavg gt 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 rl among all its congested children
• Average queue length of the most congested child
  ql, avg

15
Congestion Sharing

• Rule 1
• ri can never exceed the rj , rate of is 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 is 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/ ri sec
• ri ri F
• Slow-start ends when
• i gets congested
• ri greater than rj,where j is is parent
• ri greater than rj,where i is js potential
  interferer
• Go to Additive Increase after the 2nd or 3rd
  condition happens
• Every 1/ ri sec
• ri ri d / ri

17
Rate Adaptation

• Steady state
• Every 1/ ri sec
• ri ri d / 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 rb only when a child j of base station
  is congested (rj gtU(k) for any k) .
• It does not decreases its rate when any non-child
  neighbor or any neighbors 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 , F
• 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 F rinit
  /8
• Additive increase d (related to e, rmin,i, Fj,
  U0, U1, s2 )

21
Parameter Selection

• Intensity of AIMD
• ri ri d/ ri ? ri (t) d t
• t1 t2r1/r2 (rmaxrst)/d
• excess load r1t1/2 (rmaxrst)2/ 2d
• Underutilized capacity (r2-r1)t1/2
• (rmaxrst)(rstrmin)/ 2d
• excess load lt underutilized capacity
• and
• ?
• Avoid ri jumping from rmin,i to rmax,i
• set d e 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 js
  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.
• e 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
Routing Tree and Link Qualities
27
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

28
Comparison with Optimal

• each node to send at a fixed rate R
• R0.36, achieve 60 (0.22/0.36) of the max.
  sustainable fair rate
• Above 0.36 pkt/sec, buffer overflow (queue
  lengthgt64)

• R0.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

29
Rate Adaptation and Instantaneous queue length
Slow start AIMD
Not a single drop due to queue overflow (queue
length lt20 less than queue size 64)
30
Per-node goodput with high d
Result in unfair rate
31
Node Addition
2 successive Multiplicative Decrease (a parent
and child reaching a congested state within a
short time) Inactive nodes ri
32
Node Deletion
Packet loss Inactive nodes ri
33
Extension to IFRC1. Weighted Fairness

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

34
Subset of node

• Special case of weighted fairness
• nodes with no data to send ? wi 0

35
Extension to IFRC2. Multiple base station

• 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 isnt part of the most congested
  region.

Not in congested region
36
Outline

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

37
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

38
Conclusions

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

39
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 dont provide exact solution, need to
  set them ourselves
• If it shows by which inequality and assumption he
  got the value, it would be better

40
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?