Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 873 (2005)
(USC DC Other)
USC Computer Science Technical Reports, no. 873 (2005)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
Interference-Aware Fair Rate Control in Wireless Sensor Networks
Sumit Rangwala
Ramakrishna Gummadi
Ramesh Govindan
ABSTRACT
In a wireless sensor network of N nodes transmitting data,
possibly over multiple hops, to a single base station, what
distributed mechanisms should be implemented in order to
dynamically allocate fair and efcient transmission rates to
each node? To address this problem, our interference-aware
fair rate control (IFRC) technique devises a novel conges-
tion sharing mechanism among nodes whose transmissions
might potentially interfere with each other. This mechanism
constrains the fair share rate at each potential interferer to
be no more than that of the congested node, and effectively
propagates congestion along the routing tree. Nodes detect
congestion by measuring their average queue length, and
adapt their rates according to an AIMD control law. We eval-
uate IFRC on a 40-node wireless sensor network testbed.
Our experimental results indicate that IFRC converges to a
fair rate that is within a factor of 2 of the fair optimal rate
achievable on the underlying tree. IFRC's rate adaptation
mechanism is very effective; we did not observe a single in-
stance of queue overow in our many experiments. Finally,
IFRC can be easily extended to support weighted fairness
and multiple base stations.
1. INTRODUCTION
Congestion control has been an active area of network-
ing research for several decades now. Relatively less atten-
tion has been paid to congestion control in the emerging area
of wireless sensor networks. In this paper, we examine the
following simple problem: in a sensor network of N sensor
nodes each transmitting data, possibly over multiple hops, to
a base station, what distributed mechanisms must the sensor
network implement in order to dynamically allocate fair and
efcient transmission rates to each node?
Our motivation for this problem comes from our prior ex-
perience with implementing wireless sensor networks for
structural health monitoring. In this application, a set of sen-
sors is deployed on a large civil structure (such as a build-
ing or a bridge). Each sensor continuously measures struc-
tural vibrations at a few hundred samples a second. When
University of Southern California. srangwal@usc.edu
University of Southern California. gummadi@usc.edu
University of Southern California. ramesh@usc.edu
a signicant response is detected, as when the structure is
vibrated using a mechanical shaker, every sensor transmits
a time series of recorded samples to a base station. Civil
engineers nd an application such as this to be extremely
useful for conducting short to medium term experiments on
test structures; they analyze the structural response to de-
rive models of the structure, or assess the level of damage in
the structure. We have developed a software system called
Wisden [22] that implements this functionality, and have de-
ployed this on some real structures [15]. Currently, Wisden
has a congured upper limit on the rate at which any node
in the sensor network can send data to the base station. A
solution to the problem posed above would greatly improve
the performance and efciency of real-life deployments of
Wisden.
This problem is also more generally applicable to future
sensor network architectures. We are currently investigat-
ing a sensor network architecture, called Tenet [4], for tiered
networksthose comprising tiny wireless sensors like the
Berkeley motes, and larger embedded systems that have 32-
bit processors and 802.11 radios. The latter class of nodes
provide bandwidth scaling with their higher capacity radios.
Our Tenet architecture is examining a functional organiza-
tion that restricts application-specic code to these larger
nodes. Applications task motes to collect and process data,
and transmit them back to the nearest embedded node. In
such an architecture, the dominant trafc pattern has motes
sending their processed readings to the nearest embedded
node. In effect, processed sensor readings are routed on one
or more trees towards one or more base stations. Rate con-
trol will be an essential component of any realization of the
Tenet architecture.
The general problem of fair rate control in wireless net-
works is complicated by the time varying nature of the wire-
less channel, as well as by channel contention. As such,
the channel contention arbitration used by the MAC layer
and the quality of paths determined by the routing protocol
can impact the quality of any solution to rate control. It is
therefore tempting to cast this problem as one for which a
cross-layer approach (jointly designing MAC layer, a rout-
ing layer, and a rate allocation scheme) might be optimal. In
this paper, we take a simpler rst step and examine a fair rate
1
control mechanism that requires minimal functionality from
the underlying MAC and routing protocols.
Within this framework, one important challenge is to de-
sign a mechanism by which each node can locally detect
all other potential channel contenders, and fairly adapt its
rate such that the channel capacity is not exceeded. In gen-
eral, interference-aware rate allocation in wireless networks
is known to be intractable for arbitrary communication pat-
terns [11]. As we show in this paper, we can leverage the
tree-based trafc pattern prevalent in wireless sensor net-
works to obtain an adaptive fair rate control mechanism.
Our interference-aware fair rate control (IFRC) technique
(Section 2) is a collection of mechanisms that together achieve
a fair and efcient rate allocation for tree-based communi-
cation in wireless sensor networks. It uses AIMD control
laws to ensure convergence to fairness, and monitors average
queue lengths to detect incipient congestion. Our main con-
tribution is the design of a novel congestion sharing mech-
anism that allows IFRC to converge to a fair and efcient
rate allocation. Congestion sharing itself is not a new idea;
it has been used to achieve MAC-layer fairness [5]. IFRC
leverages the tree-based trafc pattern to design a simple,
low-overhead mechanism for congestion sharing. We derive
two simple rules by which a node can adapt its transmission
rate such that the network converges to a fair and efcient
allocation. The design of this mechanism is not trivial; to
achieve fairness, all trafc (even that originating at a distant
node) that passes through a congested wireless region needs
to be throttled, and rapidly signaling all relevant nodes is no
mean task. Beyond the congestion sharing mechanism itself,
IFRC's contribution is a careful integration of that mech-
anism with queue management and rate adaptation, and a
principled approach to deriving parameter settings that re-
sult in stable and efcient operation.
We have implemented IFRC in TinyOS, and demonstrate,
using extensive experiments on a 40-node testbed (Section 3),
that IFRC achieves fair rate control. We also demonstrate
that congestion sharing is crucial; pure local rate adapta-
tion based on observing queue lengths results in an unfair
and inefcient rate allocation. IFRC's performance is nearly
within a factor of two of the upper bound on the theoretically
optimal fair rate (Jain et al. [11]). It can be trivially extended
to more general versions of our problem: where each sensor
node sends to the nearest of many base stations (as in Tenet,
above), where only a subset of the nodes transmit data, or
where an application might require a weighted fair rate allo-
cation. Finally, IFRC's rate adaptation is very effective; we
noticed no packet drops due to queue overows in any of our
experiments.
2. IFRC DESIGN
In this section, we discuss the design of IFRC, beginning
with an overview of the various elements of IFRC, followed
by a discussion of the detailed node-level algorithms for con-
gestion detection, signaling, and rate adaptation in IFRC.
Extensions to, and limitations of, IFRC appear at the end of
the section.
2.1 Problem Denition, Terminology, Notation,
and Assumptions
Consider a network of N sensor nodes, with each node
identied by an integer in the range 1::N. In the simplest
version of our problem, each node has innite data to send
to a single base station. This data can traverse multiple hops
before reaching the base station. Thus, a sensor node orig-
inates trafc (is a source), and may forward trafc sent by
other nodes. The trafc from source i to the base station is
the i-th ow, denoted by f
i
. We seek to adaptively assign
a fair and efcient rate r
i
to f
i
(or equivalently, to node i).
(As an aside, rate-based congestion control seems to us to
be more natural for sensor networks than window-based con-
gestion control. That said, many of IFRC's mechanisms will
be relevant for window-based congestion control as well.)
All ows are treated equally. In later sections, we show how
IFRC can be extended in several practical ways: to support
multiple base stations; to allow only a subset of the nodes to
send; and, to assign different priorities to ows.
We assume that the sensor nodes run a contention-based
medium access layer. The default MAC layer in TinyOS
(the widely-used sensor node operating system) uses carrier-
sense for collision avoidance, and our implementation is built
upon this MAC. Our design can be extended to other contention-
based MACs, such as those that use RTS/CTS [23]. We have
not considered whether IFRC extends easily to token-based
and TDMA MACs.
We also assume that the sensor nodes run a routing proto-
col [20] that builds a sink tree to the base station. The solid
lines in Figure 1 depict such a tree. The correctness of IFRC
is not sensitive to the particular choice of routing protocol,
but its performance is. In general, IFRC will result in higher
overall throughput on routing protocols that use link-quality
metrics to establish the tree than on those that do not. In what
follows, we assume that a sink tree has been constructed by
the routing protocol, and, for the ease of exposition, that the
sink tree is stable. IFRC is designed to adapt to changes in
the underlying routing tree.
Finally, we assume that the MAC layer provides link-layer
retransmissions. As we show later, our current IFRC design
performs well in regimes where the wireless loss rates on the
tree links are such that link layer retransmission sufces to
recover from packet losses. Many, but not all, of our exper-
iments in real radio environments fall in this regime. Many
current real-world sensor network deployments also use sim-
ple hop-by-hop reliability mechanisms. For real-world de-
ployments in this regime, r
i
is effectively the goodput that
the node receives. To relax this assumption, we need a scal-
able end-to-end reliability mechanism using which each node
can compute the effective goodput that it receives. Design-
ing such a mechanism is a challenge in its own right, and we
have deferred this to future work.
2
What do we mean by a fair and efcient rate? Intuitively,
we would like each ow to receive a fair share of the wire-
less channel bandwidth. However, in non-uniform deploy-
ments, spatial reuse effectively denes several wireless con-
tention domains, in each of which the fair share may be dif-
ferent depending upon the number of ows traversing the
domain. IFRC's goal is assign to each node at least the
most congested fair share rate, but, in addition, to allow
sources whose ow passes through less restrictive contention
domains to send at higher rates in order to achieve overall
network efciency.
It is possible to make this intuition more precise using a
constructive denition. (In effect, IFRC achieves a max-min
fair rate allocation, but also allocates additional bandwidth in
a fair manner. We resort to this constructive denition to
capture this behavior. Moreover, our constructive denition
cleanly motivates IFRC's novel congestion-sharing mecha-
nism, which we describe in Section 2.2.2.) To do this, con-
sider the sink tree built by the routing protocol (as in Fig-
ure 1), and dene F
i
to be the set of ows routed through
node i. This set includes f
i
, and all the ows originated
by descendents in this subtree rooted at i. Also dene a
neighbor of node i to be any node which is within a sin-
gle hop of i; this includes i's parent, its children, and other
tree nodes shown by the dashed lines in Figure 1. Finally,
for the purpose of this denition, assume that radios have
a well-dened nominal data rate B. Then, IFRC's adaptive
rate allocation attempts to achieve the following rate alloca-
tion:
At each node i, deneF
i
to be the union of all sets
F
j
, where j is either a neighbor of i, or a neighbor of
i's parent. These nodes are said to be i's potential in-
terferers. Intuitively, if j is a neighbor of i, its trans-
missions can interfere with those of i. If j is a neigh-
bor of i's parent, then, when j is transmitting, i cannot
safely send data to its parent. Allocate to each ow in
F
i
, a fair and efcient share of the nominal bandwidth
B. (We do not dene how to compute this share, since
we are merely interested in dening network-wide fair-
ness and efciency. Note that more efcient alloca-
tions may be possible than merely evenly dividing up B
across all the ows, for example, by carefully schedul-
ing non-interfering ows.) Denote by f
l;i
the rate al-
located at node i to ow l. Repeat this calculation for
each node.
Assign to f
l
the minimum of f
l;i
for all nodes i.
We illustrate the above denition by showing the set of
ows that belongs toF
16
in gure 1. f
20
; f
21
; f
14
being
neighbors of f
16
belong toF
16
. f
13
; f
17
; f
12
, being neigh-
bors of 16's parent also belong to this set. Finally f
15
; f
18
; f
19
also belong toF
16
as they are routed either through a neigh-
bor of 16 or through neighbor of 16's parent 14.
Is fairness the appropriate design goal for sensor network
data transport? Unless we get more deployment experience,
this question is difcult to answer. Fairness is a reason-
able initial design goal, and design insights from IFRC will
be useful in designing other rate adaptation mechanisms for
sensor networks. Furthermore, simple extensions to fairness,
such as weighted fairness, can be easily realized with IFRC
(Section 2.3.1).
Figure 1: A sample tree topology; dashed lines represent
a potential interferer that is neither a parent nor a child
of a node.
2.2 IFRC Mechanisms
In IFRC, each node i adaptively converges to a fair and
efcient rate r
i
using a distributed rate adaptation technique.
It achieves this by accurately sharing congestion information
with potential interferers. IFRC consists three inter-related
components: one that measures the level of congestion at a
node, another that shares congestion information with po-
tential interferers, and a third that adapts the rate using an
AIMD control law. In addition, IFRC requires a specialized
mechanism at the base station. We describe all four mech-
anisms in this subsection. We conclude by discussing how
IFRC algorithm parameters are chosen.
2.2.1 Measuring Congestion Levels
Various techniques have been proposed in the wireless and
sensor network literature to measure the level of conges-
tion experienced by a node. Broadly speaking, these tech-
niques either directly measure the channel utilization around
a node [18], or measure the queue occupancy at the node [8],
or a combination thereof. However, recent work [8] reports
that, for a trafc pattern in which multiple sources send to
a single sink, queue occupancy is a sufciently accurate in-
dicator of congestion. Intuitively, with a MAC layer that
uses carrier-sense, MAC backoffs effectively cause queues
to build up at a node, so queue lengths are a reasonable indi-
cator of congestion.
At each node, IFRC maintains a single queue of packets
3
from all ows passing through the node. This includes ows
from all descendents of the node in the routing tree and that
sourced by the node itself. Following much of the prior work
on congestion control, IFRC uses an exponentially weighted
moving average of the instantaneous queue length as a mea-
sure of congestion: avg
q
= (1 w
q
)avg
q
+ w
q
inst
q
. The
average queue length is updated whenever a packet is in-
serted into the queue.
Conceptually, IFRC detects incipient congestion by us-
ing a simple thresholding technique with hysteresis. Thus, if
avg
q
exceeds a certain upper threshold U, the node is said to
be congested, and the node halves its current r
i
(the precise
rate adaptation behavior is described in detail in a later sub-
section). The node remains in a congested state until avg
q
falls below a lower threshold L, at which point it can safely
increase its r
i
(additively, as we explain later).
In practice, a single threshold is too coarse-grained to ef-
fectively react to congestion. U can be very sensitive to the
actual density of deployment or the structure of the tree, and
merely halving r
i
when U is crossed may not be sufcient
to drain the node's queue. Thus, IFRC employs multiple
thresholds U(k), dened by U(k) = U(k 1) + I=2
k1
,
where k is a small integer and I is a constant increment of
the queue length. When avg
q
is increasing and crosses each
U(k), the node halves its r
i
(gure 2). Since the difference
between U(k) and U(k1) decreases geometrically with in-
creasing k, the rate halving becomes more frequent as the
queue size increases. In this manner, a node continues to
aggressively cut its r
i
until its queue starts to drain.
While our use of thresholds may seem supercially simi-
lar to Internet congestion control mechanisms like RED [6],
IFRC does not use probabilistic dropping or marking as con-
gestion indicators. Rather, each node shares its congestion
information with all other potential interferers, as described
in the next section.
2.2.2 Congestion Sharing
In Section 2.1, we introduced a constructive denition for
IFRC's rate adaptation goal. To achieve that goal, it is nec-
essary to share i's congestion state (its current average queue
length) with other potential interferers. Each node can do
this by explicitly transmitting its queue length to its poten-
tial interferers. Since some of its potential interferers are two
hops away from node i, and since all ows passing through
those nodes need to be throttled, the design of such a mecha-
nism becomes a little tricky. IFRC uses a simpler congestion
sharing mechanism, described below, that achieves the same
goal.
In IFRC, node i includes the following information in the
header of each outgoing transmission packet: its current r
i
,
a bit indicating whether the node is congested or not, and for
its most congested child l (the reason for this information
will become clear in a moment), a bit indicating whether l
is congested or not and r
l
. Using this information, all recip-
ients of each packet (we assume that nodes snoop transmis-
sions, a common assumption in many sensor network pro-
tocols) can determine whether i (and any of its children) is
congested or not. All neighbors of i (its children, its parent,
and other nodes that can hear i's transmissions) receive this
packet. However, some potential interferers of i (the neigh-
bors of i's parent) may not receive this packet. How, then,
does IFRC converge to the fair rate?
IFRC introduces two simple constraints on the value of r
i
at node i:
Rule 1: r
i
cannot exceed the value of r
j
for any congested
neighbor j, or that of any congested child of the neigh-
bor. Thus, if i overhears a transmission from j and
nds that j is congested or any of j's children are con-
gested and that r
j
(or r
l
where l is the congested child
of j) is less than r
i
, it immediately sets r
i
to r
j
(or r
l
,
whichever is lower). (It does not change its conges-
tion state, however, since that is dened by its average
queue length. However, even if i itself is not congested,
as long as j or one of its children is congested, this rule
prevents i from increasing its rate).
Rule 2: r
i
can never exceed the rate r
j
of its parent, regard-
less of whether the parent is congested or not.
Why do these two constraints achieve the goal described in
Section 2.1? Consider a congested node i. By rule 2 above,
all children of i will eventually be notied of i's congestion
and set their rates to be no more than r
i
. By rule 1, any other
neighbor of i, including its parent, will set its own rate to r
i
.
Furthermore, recursively, each descendant of a non-parent
neighbor will also set its rate to r
i
. Finally, all neighbors
of i's parent will also set their rates to r
i
by rule 1; when
i's parent sends any transmission, it indicates that one of its
children (namely i) is congested (see above).
More specically, let us assume node 16 in Figure 1 is
congested. We require all nodes inF
16
to have the same
rate as r
16
. By rule 1 all neighbors of 16, i.e., 20, 21 and 14
will set their rate equal to r
16
. 14 will include information
about a congested child in its outgoing packets. Based on
this information and rule 1, node 13, 17 and 12 will set their
rate to equal to r
16
. All the remaining nodes inF
16
, namely
node 15, 18 and 19 will eventually have their rates set to r
16
by rule 2 as one of their ancestors has set its rate to r
16
.
2.2.3 Rate Adaptation
Finally, in this section, we describe some of the details of
IFRC's rate adaptation mechanism. Before we do this, it
is worth emphasizing that r
i
is the long-term fair and ef-
cient rate that IFRC converges to, and not the instantaneous
rate achievable by a node (which may be affected by vari-
ous MAC-layer fairness and transmission scheduling mech-
anisms).
When a node i's rate is not constrained by any potential
interferer, it adapts its rate as follows. If i is not congested,
it increases its rate additively. Every 1=r
i
seconds, its rate is
incremented by d=r
i
. We discuss the choice of the additive
4
Figure 2: Queue thresholds and corresponding rate changes
increase parameter d and the choice of the 1=r
i
control inter-
val in Section 2.2.5. If i is congested, then when threshold
U(k) is crossed, the node halves its current r
i
. It does this
at most once for each U(k) during one congestion epoch; an
epoch begins when the node transitions to a congested state,
and ends when it transitions to a non-congested state. The
latter happens when, in a congested state, the average queue
length goes below the lower threshold L.
When i discovers its r
i
to be higher than that of its par-
ent j, it sets its rate to r
j
. When i overhears a neighbor l's
transmission that indicates that l, or one of l's children p
is congested, its sets r
i
to either r
l
or r
p
as necessary. In
either case, i does not change its own congestion state: in
particular, if it was originally not congested, it continues to
additively increase r
i
.
Both these sets of rules follow from the discussions in the
previous two sections. Thus far, however, we have not de-
scribed IFRC's startup behavior.
All nodes start from a xed initial rate r
init
. For faster con-
vergence, IFRC implements a multiplicative rate increase
initially. This technique is similar to TCP's slow start. While
node i is in slow start it adds f to its rate every 1=r
i
seconds,
thus multiplicatively increasing its r
i
. It exits this mode
when one of three conditions is true. If in slow start, i itself
becomes congested, it halves r
i
. If its r
i
equals or exceeds
that of its parent, it sets r
i
to its parent's rate and transitions to
additive increase. Finally, if its rate is constrained by conges-
tion sharing, i sets its r
i
to that of the constraining node and
transitions to additive increase. These three conditions are
consistent with the congestion sharing rate adaptation mech-
anisms discussed above.
Slow start behavior is also invoked, for rapid recovery,
when r
i
goes below r
init
. This can happen in one of two
ways. If i's average queue length increases continuously, it
will repeatedly halve its rate (Section 2.2.1). Alternately, i's
rate can be constrained by a neighbor to be below r
init
. In
either scenario, i resumes slow start only when congestion
clears (its average queue length goes below L).
The pseudo-code for IFRC's rate adaptation is in App-
endix A.
2.2.4 Base Station Behavior
The base station is a distinguished node in IFRC, since it
never sources any trafc, and therefore does not need a sep-
arate allocated rate. Thus, it does not execute the algorithms
described so far. It does, however, need to facilitate con-
gestion sharing between its children. For this, it maintains a
rate r
b
and enforces congestion sharing by adapting r
b
to
congestion indicators from its children. Its children are con-
strained by Rule 2 in Section 2.2.2 to a rate no greater than
r
b
.
Initially, IFRC sets r
b
equal to the nominal data rate of
the wireless channel. IFRC is not sensitive to the choice of
value for this rate, since each node independently measures
congestion by monitoring queue lengths. The initial value
of r
b
merely needs to be high enough that the base station's
children can determine their fair rates without being con-
strained by the congured value. The base station always
additively increases r
b
: every 1=r
b
seconds, it increments r
b
by d=r
b
. Since the base station does not source any trafc,
it broadcasts a packet containing this rate as a way of shar-
ing congestion information. To limit overhead, this packet is
sent only when r
b
has increased signicantly (in our imple-
mentation, by 5%) since the last time it was broadcast.
When a child i transitions to a congested state, the base
station sets r
b
to r
i
and immediately broadcasts a packet con-
taining this rate; this effectively throttles its children. Im-
mediately thereafter the base station continues to additively
increase r
b
. This behavior is different from that of a sensor
node, which cannot increase its rate beyond that of a con-
gested child. This continued additive increase allows those
of its children that are not neighbors of i to increase their
rate.
Figure 3: Fairness and Throughput Tradeoff
There is at least one topology in which this base station
behavior (which we use in all our experiments) leads to un-
fairness. In the tree on the right side of Figure 3, when
congestion occurs at node 1, the only way we can achieve
fairness is by setting r
2
equal to r
1
. However, if the base
5
station were to follow the rate adaptation rules discussed in
Section 2.2.3, a fair rate allocation would result, but the rule
would not be efcient in all tree topologies (e.g., the tree on
the left of Figure 3).
We have not encountered the topology on the right in our
experiments, but it illustrates some of the trade-offs between
fairness and efciency in the design of base station behavior.
We intend to more carefully examine this trade-off in future
work.
2.2.5 Choosing IFRC Parameters
The choice of many IFRC parameters is inuenced by
IFRC's open-loop design. In reliable transport protocols
like TCP, acknowledgements used for error recovery are re-
ceived after one round trip time. The RTT is a natural time-
scale at which many rate adaptation functions are invoked.
Currently, IFRC is not coupled with end-to-end reliability
(Section 2.1), and departs from traditional congestion con-
trol protocols in its parameter choices.
Choice of control interval: We have already said that
during additive increase IFRC increases r
i
by d=r
i
every
1=r
i
seconds. In the absence of ack clocking, IFRC could
have incremented the rate periodically every t sec. However,
choosing the right value for t is difcult, hence our choice.
Choice of d, r
init
, and f: We encountered a similar dif-
culty in selecting r
init
, d and f. In window-based protocols,
1 is a natural choice for the initial window, 1 packet per RTT
for the rate of additive increase, and a factor of 2 per RTT
for the multiplicative increase during slow start. In IFRC, a
bad choice of r
init
or d can lead to unstable behavior. If r
init
is comparable to the fair share rate of a node, the system will
always be in slow start. Similarly, if d or f is large compared
to a node's fair share rate, the system can oscillate.
In IFRC, a sensor network administrator derives a conser-
vative estimate of the fair share rate based on the nominal ra-
dio bandwidth B and network size N. This estimate is used to
set IFRC's parameters. It is not very sensitive to the choice
of B or N; ballpark estimates for these two quantities can
be used. Sensor networks will require careful deployment
planning, so it is reasonable to assume per-network parame-
ter conguration.
In an N node sensor network, as long as the underlying
routing protocol (for example, one that selects paths based
on link-quality metrics) does not choose degenerate cong-
urations, the fair share rate assigned to each node will be
proportional to B=N. We then conservatively set r
init
to be
B=50N. Now, in each control interval during slow start r
i
increases by f. For stability, we would like f to be less than
r
i
at all times. Since the smallest value of r
i
is r
init
, we set f
to be r
init
for stability. Finally, in each control interval dur-
ing additive increase, r
i
increases by d=r
i
. Using a similar
argument as for f, we set d to be (r
init
)
2
.
2.3 IFRC Discussion
We have assumed that every node in the network has data
to send to a single base-station. Our IFRC design is exi-
ble enough to accommodate multiple base stations, weighted
fairness, or only a subset of nodes transmitting data. At the
same time, our current IFRC design has some limitations
that suggest interesting directions for future work.
2.3.1 Extensions to IFRC
Figure 4: Multiple Base Stations
Multiple Base Stations: Consider a network with multi-
ple base stations. Each sensor node may be able to send to
more than one base station, but picks the one with the best
path, and the system converges to one routing tree for each
base station. In this scenario, a potential interferer for node i
may be on a different routing tree than the one i is on. IFRC
must account for this in adapting to a fair and efcient rate.
To accommodate multiple base stations, IFRC requires a
simple modication to the base station behavior (Section 2.2.4).
Figure 4 motivates this modication and shows two rout-
ing trees rooted at node 1 and node 10. When node 11 is
congested, node 10, following the base station behavior de-
scribed above, sets r
10
to r
11
. r
1
should also to be set to r
10
as the ow from 1 can interfer with the transmission from
11! 10. But since node 10 is not congested (it is the base
station), Rule 2 in Section 2.2.2 is never triggered at node 1.
Our x to this modies the control packet transmitted by
the base station to include the congestion state and, in place
of the current rate of the most congested child, the base sta-
tion's own rate. With this change, when node 11 is congested
r
10
resets its rate to r
11
and sends a control packet indicating
that r
11
is congested. This triggers Rule 2 at node 1 if r
1
is
greater than r
11
. This modication is backwards compatible
to the single base station case. All our experiments have in-
corporated this modication. In discussing other extensions
to IFRC below, we revert to a single base-station scenario,
and believe that these other extensions will extend without
modication to multiple base stations.
Weighted Fairness: Consider a network where node i is
assigned a weight w
i
. We say a rate allocation scheme is
fair if the normalized rate for each ow f
i
=w
i
is fair accord-
ing to our denition in Section 2.1. We have implemented
weighted fairness as follows. We do not change any aspect
of IFRC rate adaptation, congestion sharing, or queue man-
6
agement. Rather, to implement weighted fairness, each node
sends trafc at a long-term rate w
i
r
i
, instead of just r
i
. We
experimentally demonstrate that IFRC achieves weighted
fairness (Section 3).
When only a subset of nodes transmit: Finally, IFRC
works (without modication) when only a subset of nodes
are sending data in the network. Each node i maintains r
i
exactly as it would if it had data to send. Intuitively a subset
of nodes sending data can be considered as a special case of
weighted fairness where nodes that have data to send have
weight 1 and nodes that don't have weight 0. We also exper-
imentally demonstrate this extension in Section 3.
2.3.2 Limitations
We have already observed that IFRC is not currently in-
tegrated with an end-to-end reliability mechanism. For this
reason, IFRC parameter selection is different from that of
more traditional transport protocols. When it is integrated
with end-to-end reliability, we expect few conceptual changes
to IFRC; the details of rate adaptation and parameter selec-
tion will, of course, change.
Many sensor network routing protocols [20, 2] dynami-
cally estimate link packet loss rates when selecting paths. In
preliminary experiments, we have observed that these esti-
mators are not stable at high trafc rates. When used with
IFRC, the routing protocol may change the routing tree fre-
quently, degrading performance. The design of stable link
quality estimators is critical for IFRC.
Many sensor network systems designs duty-cycle network
nodes [23] to conserve energy. As long as the underlying
routing protocol maintains routing paths when nodes resume
from sleep, we believe IFRC will work, but have not veri-
ed this. We also believe IFRC will work without modica-
tion when intermediate nodes perform in-network aggrega-
tion [9]. In general, aggregation reduces the volume of data
transmitted by nodes; in IFRC, nodes will adaptively detect
the availability of, and use, the available capacity.
3. EV ALUATIONS
In this section, we present a performance evaluation of
our implementation of IFRC on a 40-node wireless sensor
testbed.
3.1 Implementation
We have implemented, in TinyOS 1.x, all the features of
IFRC described in Section 2. Our implementation is about
1200 lines of code, and consists of two modules, QueueMan-
agement and RateControl. The former module maintains the
packet queue, and implements packet forwarding functional-
ity. It also measures the node's congestion level as described
in Section 2.2.1, and signals the RateControl module when
the node's congestion state changes.
The RateControl module implements congestion sharing
(Section 2.2.2) and rate adaptation (Section 2.2.3). In addi-
tion, the module maintains a neighbor table to track neigh-
bor congestion state and rates. The RateControl module
also promiscuously snoops network packets for congestion
sharing. In the version of TinyOS we use, putting the radio
in promiscuous mode disables the chip-level acknowledge-
ments that TinyOS relies on. Since link layer acknowledge-
ments are essential for IFRC, we added acknowledgments
to the MAC layer.
Finally, the base station functionality (Section 2.2.4) is
also implemented in a single TinyOS module.
3.2 Methodology
We evaluated our IFRC implementation on a 40node in-
door wireless sensor network testbed. Each sensor node in
our testbed is a Moteiv Tmote [3] with an 8MHz Texas In-
struments MSP430 microcontroller, 10k RAM and a 2.4GHz
IEEE 802.15.4 Chipcon Wireless Transceiver [1].
Figure 6 shows the layout of the deployed testbed spread
over 1125 sq. meters of an ofce oor. Our testbed is de-
ployed in clusters, where a cluster of about 7 motes is con-
nected via a USB hub to a Stargate. The Stargates them-
selves form an ad hoc wireless network and are used for
programming the motes and for logging experimental data.
Even though the motes are deployed in clusters, they collec-
tively form a connected topology (Figure 5) with a ve-hop
diameter.
We have tested IFRC on several routing trees constructed
on various topologies with up to 40 nodes, and with differ-
ent base station locations. In this paper, we present a subset
of these results. During our experiments, two testbed nodes
(numbered 20 and 37) incurred a hardware failure. In all
the graphs presented below, the results from those nodes are
absent. Table 1 shows the parameters used in our experi-
ments. Selecting parameters using the method described in
Section 2.2.5 has worked well in all the experiments we have
attempted. In Section 3.3.4, we also demonstrate below the
effect of a deliberately incorrect choice of parameter value.
In Section 2.3.2, we explained that because the packet reli-
ability estimators are not stable at high loads, a routing pro-
tocol that uses such estimators will interact with IFRC to
give poor performance. To factor this out, we modied the
existing TinyOS routing protocol (MultiHopLQI) to termi-
nate the route computation after an initial, reasonable tree
is found. For each experiment, then, we ran this modied
routing protocol to x an initial tree, then executed IFRC on
it.
In our testbed, the capacity of the Stargate network does
not allow us to program all the nodes simultaneously. Our
script programs nodes in groups, but each node begins send-
ing trafc and running IFRC as soon as it starts. As a result,
the startup behavior of the system is complex, and we have
ltered the transients in presenting most of our results (in
one subsection below, we do analyze IFRC's startup behav-
ior). We ran each experiment for at least an hour after the
transient in order to get representative results.
For each experiment, we logged every packet transmission
7
0
1
2
3
4
5
6
7
9
11
12
13
10
8
18
19
17
14
15
16
28
31
27
24
29
30
21
23
40
38
22
25
26
34
39
36
41
32
33
35
Figure 5: Testbed topology Figure 6: Testbed layout on ofce oor
and reception, and every change in rate, at each network
node. In addition, we logged every packet received at the
base station. This fairly detailed logging helps us visualize
IFRC behavior in several ways below.
We measure the per-ow goodput, as the total number of
packets received from a node at the base station, divided by
the duration of the experiment. We plot the rate adaptation
at each node, by plotting r
i
as a function of time. For some
experiments, we visualize instantaneous queue size at nodes
as a function of time. For some experiments, we also present
a per-ow packet reception plot, which shows the number of
packets received as a function of time.
Jain et al. [11] consider the problem of determining the
maximum throughput in a wireless network whose network
topology, routing topology, sending and receiving nodes, and
link losses are given. Their problem is to nd the maxi-
mum rate, and a scheduling strategy to achieve it, at which
each sender can send a designated receiver, subject to in-
terference constraints imposed on the routing topology by
the neighboring nodes in the network topology. Their pa-
per proves that calculating the optimal maximum sending
rates for an arbitrary topology in general is an NP-complete
problem, and gives a heuristic algorithm that instead gives
upper and lower bounds on the maximum achievable rates.
We have implemented these upper and lower bound calcula-
tions (suitably altering the paper's linear programming for-
mulations to compute the maximum achievable fair rate as
suggested by the authors), and have validated our implemen-
tation against the results presented in the paper. These calcu-
lations take as input the topology, the packet reception rates
on each link (we approximate this by the average reception
rate over the duration of the experiment), and the nominal
radio bandwidth B. We use the resulting bounds to calibrate
the fair rates achieved by IFRC.
3.3 Results
In this section, we present experimental results that val-
idate our IFRC design, demonstrate that IFRC can be ex-
tended in the ways we have discussed in Section 2.3.1, and
analyze the consequences of poor parameter choices for IFRC.
Parameters Value
Lower Threshold (L) 4
Upper Threshold (U) 8
Increment(I) 8
d 0.0004
r
init
0.02
MAXTRANS 5
Queue Size 32
w
q
0.1
Packet Size 32 bytes
Table 1: Parameters for Experiments runs
3.3.1 IFRC on a 40node network
In this section we discuss the performance of IFRC on a
40-node network. All 40 nodes are transmitting data, and
there is one base station. All ows are treated equally.
Figure 7 shows the routing tree generated during one ex-
perimental run. Packet loss rates are depicted on each link
and vary between 4% and 23%. This tree is 8 hops deep.
This surprisingly large depth is an artifact of the way in
which we terminate the routing protocol computation in or-
der to x the tree. However, the depth of the tree, the variable
fanout at various nodes, the high variability in packet loss
rates, and the unbalanced layout make this a good topology
to study IFRC performance.
Figure 8 shows the per-ow goodput received at the sink.
It is clear that all nodes receive approximately the same good-
put, validating the most basic part of IFRC design. The g-
ure also validates another part of IFRC design. From Fig-
ure 7, notice that nodes 1 2 and 4 6 are topologically
set apart from the other nodes in the network. These nodes
are not potential interferers of the most congested node in
the network (node 9). IFRC is able to allocate a slightly
higher rate to each of them (see arrows in Figure 8), and this
additional allocation is evenly distributed. This behavior is
more clearly evident in Figure 12, where one node (node 4)
does not interfere with the most congested node and receives
higher goodput.
8
In Figure 8, the two horizontal lines show the upper and
lower bound on the optimal fair rate achievable with the rout-
ing tree of Figure 7 as derived from our implementation of
Jain et al.,'s algorithm [11]. Notice that IFRC's rate alloca-
tion is close to the lower bound, and slightly lower than half
that of the upper bound. These bounds correspond to an ide-
alized transmission schedule that requires a ne grain tem-
poral control on transmissions. Even with a CSMA MAC
layer that departs signicantly from this idealization, it is
commendable that IFRC is nearly within a factor of two of
the optimal. We have also veried that the same observation
holds for our second experiment of Figure 12.
Figure 9 shows the rate adaptation at each node and at the
base station. The base station's r
b
is generally higher than
that of any other node. This is by design, and lets other
nodes additively increase their rates to nd efcient alloca-
tions (Section 2.2.4). All nodes adapt their rates in near-
synchrony (the rate plots for various nodes overlap with each
other), and the classic saw-tooth behavior is clearly visible
in the graph. A closer look (not shown) reveals that the rate
adaptation at different nodes is slightly de-synchronized by
network latencies, but this effect does not show up at the time
scale of the graph. The base station decreases r
b
to match the
rate of its most congested child; except for one instance, r
b
always drops to the same rate as other nodes. In that one
instance, congestion was observed lower in the routing tree,
not at a child of the base station. Also, at about 12:20, no-
tice that a group of nodes gets a higher rate than others; this
group is the one identied in the previous paragraph. Finally,
there is a small measurement artifact in the graph; at about
11:35, the rate plot for one of the nodes is slightly distorted.
This results from an infrequent data logging queue overow
at the USB ports on one of our motes.
In subsequent experiments, unless otherwise specied, we
use the same routing tree as the one used for Figure 9.
Figure 10 shows the instantaneous size of the queue at ev-
ery node. While it is difcult to decipher the detailed behav-
ior of each ow from the graph, we clearly see that the in-
stantaneous size never grows beyond 20. Each of our nodes
has a buffer size of 32, so in this experiment no packets are
lost due to queue overow. The same behavior occurs in
another experiment (Figure 11). In fact, in all the experi-
ments that we have conducted, we have never seen a single
instance of buffer overow. This results from IFRC's ag-
gressive rate cutting at each U(k) (Section 2.2.1).
3.3.2 Dynamics and Startup Behavior
IFRC dynamically adapts to node addition and removal.
We would have liked to validate this behavior by turning
nodes on and off. However, as we have discussed above,
IFRC can interact with link quality based route selection,
and turning notes on and off would trigger changes to the
routing tree. So, we conducted two simple experiment to
demonstrate how IFRC adapts to the addition or removal of
nodes.
In the rst experiment, all the nodes were turned on at the
beginning of the experiment, and the routing tree was xed,
but only a fourth of them started sending data then. The
others started sending data about 20 minutes into the exper-
iment. Figure 13 shows the rate adaptation of the nodes in
this experiment. The reduced overall fair share rate, when
nodes are added to the network, is clearly visible in this plot.
A packet reception plot also shows the same phenomenon
(Figure 15); the slope of a packet reception curve indicates
the goodput that a node receives, and this gure clearly shows
the reduced goodput of all the nodes when nodes are added
to the network.
The second experiment was similar, but all nodes started
sending data at the beginning, and three-fourths of the nodes
stopped about 20 minutes into the experiment. Nodes that
continue transmitting data after a large fraction of the nodes
have been removed obtain higher fair share rates, as shown
in Figure 14.
In a previous section, we described how nodes are pro-
grammed in a staggered fashion in each experiment. This
results in a fairly complex startup behavior, but Figure 21
presents a simplied view of this behavior. The rst node
to start clearly shows the exponential increase in rate during
slow start. Thereafter, we see that its a rate is aggressively
cut repeatedly, as other nodes start and contend for the band-
width. This process takes several minutes to converge, and
represents an extremely pathological convergence behavior.
The behavior of a node that starts up later (shown by an ar-
row) is markedly different; its slow start is quickly clamped
by its parent's rate. This faster convergence is likely to be the
common case when individual notes recover from failure.
3.3.3 IFRC Extensions
In this section, we validate the performance of the IFRC
extensions discussed in Section 2.3.1.
Figure 16 plots the per-ow goodput for an experiment
in which some nodes were assigned different weights than
others. Each node whose id is divisible by 4 was assigned a
weight of 2 and all the other nodes were assigned a weight
1. The gure clearly demonstrates that IFRC is effective in
allocating rates conforming to the congured weights. Node
4 gets twice the rate of nodes 1;2;5;6; recall that these nodes
do not interfere with the most congested node in the network,
and hence get a higher rate. All other nodes whose identiers
are divisible by 4 get twice the fair share rate dictated by the
most congested node.
Figure 17 shows the per-ow goodput for an experiment in
which only nodes whose identiers were divisible by 3 were
allowed to transmit data. As expected, all transmitting nodes
receive at least the fair rate, and node 6 receives a higher
rate because it does not interfere with the most congested
note. Furthermore, the fair share per-ow goodput is ap-
proximately a factor of four higher in this case than when all
nodes transmit; IFRC adapts to the increased overall avail-
able capacity and allocates it fairly to the transmitting nodes.
9
1
0
16%
2
22%
3
6%
4
18%
5
12%
6
13%
7
10%
8
15%
9
9%
10
17%
11
12%
12
7%
13
8%
14
17
22%
19%
15
19%
16
23%
18
8%
19
14%
21
24
8%
31%
22
12%
23
14%
25
12%
26
4%
27
9%
28
12%
29
13%
30
13%
31
10%
32
39
4%
40
13%
33
4%
34
9%
35
9%
36
6%
38
4%
12%
41
6%
Figure 7: Routing tree used for ex-
periments
0
0.2
0.4
0.6
0.8
1
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
1 2 4 5 6
Optimal Rate(upper bound)
Optimal Rate(lower bound)
Figure 8: Per-ow goodput in 40-
node experiments
0
1000
2000
3000
4000
5000
6000
7000
8000
11:30 11:35 11:40 11:45 11:50 11:55 12:00 12:05 12:10 12:15 12:20 12:25 12:30
Rate X 10000 (pkts/sec)
Time(Hour:Min)
Rate at Each Node
Base Station
Other Nodes
Figure 9: Rate adaptation in 40-node
experiments
0
5
10
15
20
11:30 11:35 11:40 11:45 11:50 11:55 12:00 12:05 12:10 12:15 12:20 12:25 12:30
Inst. Queue Size
Time(Hour:Min)
Instantaneous Queue Size at Each Node
Figure 10: Instantaneous queue size
in a 40-node experiment
0
5
10
15
20
25
09:10 09:15 09:20 09:25 09:30 09:35 09:40 09:45 09:50 09:55 10:00 10:05 10:10
Inst. Queue Size
Time(Hour:Min)
Instantaneous Queue Size at Each Node
Figure 11: Instantaneous queue size
in another 40-node experiment
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-node Goodput
Figure 12: Per-ow goodput in an-
other 40-node experiment
0
2000
4000
6000
8000
10000
12000
14000
01:30 01:40 01:50 02:00 02:10 02:20 02:30 02:40 02:50 03:00
Rate X 10000 (pkts/sec)
Time(Hour:Min)
Rate at Each Node
Figure 13: Node Addition: Rate
adaptation
0
2000
4000
6000
8000
10000
12000
14000
16000
04:10 04:20 04:30 04:40 04:50 05:00 05:10 05:20 05:30 05:40
Rate X 10000 (pkts/sec)
Time(Hour:Min)
Rate at Each Node
Figure 14: Node Deletion: Rate
Adaptation
0
200
400
600
800
1000
1200
1400
1600
01:30 01:40 01:50 02:00 02:10 02:20 02:30 02:40 02:50 03:00
Packet Received
Time(Hour:Min)
Packet Received Per-Node
Figure 15: Node Addition: Packet
Reception Plot
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 16: Per-ow goodput with
Weighted Fairness
0
0.2
0.4
0.6
0.8
1
1.2
0 5 10 15 20 25 30 35 40
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 17: Per-ow goodput with
only a subset of the nodes sending
10
Finally, we ran an experiment with two base stations. The
routing tree used for this experiment is shown in Figure 24.
A fourth of the nodes send data to one sink (node 41) and the
rest send to another sink (node 0). As Figure 19 shows, the
two sets of nodes get different fair share rates. The smaller
cluster is not constrained by the most congested node (node
7) in the larger cluster, and can spatially reuse capacity.
3.3.4 Validating Some Design Choices
How crucial is congestion sharing to the performance of
IFRC? Figure 18 shows the per-ow goodput when IFRC's
congestion sharing algorithm is disabled. In this experiment,
nodes merely monitor their own queues, and locally adapt
their sending rates based on their current congestion state.
We clearly see that the nodes are segregated into winners and
losers, with about two-third of the nodes getting near zero
goodput. This validates our attention to a carefully designed
congestion sharing mechanism.
In Section 2.2.5, we explained the need to carefully select
IFRC parameters. To validate this, we deliberately chose a
high value of d in one experiment. As Figure 22 shows, this
aggressive choice of d segregates nodes into winners and
losers, though not as spectacularly as disabling congestion
sharing.
In Section 2.1, we discussed why link-layer retransmis-
sions are essential for IFRC. In all of our experiments but
one, we have found that the ve retransmission limit we use
is sufcient to ensure fairness. However, we were able to
construct a pathological routing tree (Figure 20) that illus-
trates that, in extremely high packet loss regimes, IFRC can
result in an unfair rate allocation. We did this by not allowing
the routing protocol to converge to good-quality paths before
xing the tree. As a result, two on-tree links had extremely
high loss rates for which even a ve retransmission limit
was not sufcient to recover packet loss. This caused the
topology to effectively partition into three groups of nodes
as shown (empty circles, shaded circles and empty ellipses)
in Figure 20, and is reected in the tri-modal goodput dis-
tribution of Figure 23. In the routing tree we have used for
experiments in this paper, even a three retransmission limit
sufces to ensure fairness (Figure 26).
4. RELATED WORK
IFRC draws inspiration from the Internet congestion con-
trol literature, and borrows liberally from the work on TCP [10],
active queue management [6, 13]. It is also inuenced by
work on MAC-layer fairness in wireless networks [5]. How-
ever, our problem setting is quite unlike any considered in
these areas; to our knowledge, the problem of achieving a
fair and efcient rate when many nodes send data, possibly
over multiple hops, to a base station, has not been studied
in either the Internet or ad-hoc networks literature before.
Perhaps closest in spirit is prior work on multicast conges-
tion control in the Internet; however, even this body of work
tackles a different problemthat of sending data from a sin-
gle sender to multiple receivers.
There has been prior work in sensor networks on detecting
and managing congestion in a variety of ways. Most relevant
to IFRC is the work on Fusion [8]. Fusion tackles a slightly
different problem from ours: given N nodes that want to
send data at a specied rate (offered load), what mecha-
nisms are sufcient to mitigate congestion in the network
and improve its efciency in delivering the data? Fusion
uses queue lengths to measure levels of congestion, as we
do, but also uses a qualitatively different set of mechanisms
than the congestion sharing mechanism we have considered;
it applies hop-by-hop backpressure using a token-based reg-
ulation mechanism, and a prioritized medium access layer
that allows congestion at local nodes to drain quickly. Fun-
damentally, however, the main distinction between Fusion
and IFRC is that the latter can dynamically determine the
fair and efcient rate that a node may send trafc at without
introducing congestion. We suspect Fusion can be modied
to hunt for a safe offered load, but we have not seen any
literature that describes how to do this.
In early work on a problem similar to our own, Woo et al.,
[19] examine an AIMD rate adjustment strategy in which the
additive increase is proportional to the number of descen-
dents of a node, and multiplicative decrease is performed
whenever a node detects (by promiscuously listening) that
its parent is unable to forward its trafc. Thus, a parent in-
dicates congestion by dropping some trafc from its child,
forcing the latter into multiplicative decrease. IFRC is dif-
ferent from this work. It detects incipient congestion and
applies aggressive rate cutting to avoid dropping packets. It
also employs a more sophisticated congestion sharing strat-
egy beyond just a signal from a parent to its children.
CODA [18] also considers a problem setting similar to
ours and comes up with a complementary approach. They
examine the efcacy of channel sensing for measuring con-
gestion levels; IFRC uses queue lengths under the assump-
tion that, to a rst order, a carrier-sense based MAC layer
will cause congestion to be reected in backed up queues.
Beyond that, their work considers two strategies: open-loop
back pressure for transient congestion, and an end-to-end
acknowledgment based approach for permanent congestion.
Unlike CODA, IFRC does not rely on separate mechanisms
for different congestion durations. Furthermore, CODA does
not explicitly focus on per-source fairness.
Several other pieces of work in the sensor and ad hoc net-
work literature are tangentially related to IFRC. Xu et al.,
[21] extend RED to improve TCP fairness in wireless sen-
sor networks. They introduce the idea of a distributed queue
comprised of all the nodes that contend for a channel. Each
node locally computes its RED drop probability based on
this distributed queue. This is a congestion sharing mecha-
nism somewhat similar to ours. Li et al., [12] demonstrate
that fairness at the medium access layer does not lead to
transport layer fairness. Zhang et al., [24] examine priority
adjustment techniques to reduce the retransmission priori-
11
0
1
2
3
4
5
6
7
8
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 18: Per-ow goodput with no
congestion sharing
0
0.5
1
1.5
2
2.5
3
3.5
4
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 19: Per-ow goodput for mul-
tiple sinks
1
0
18%
2
19%
3
47%
4
26%
5
12%
6
15%
7
23%
8
36%
9
20%
10
32%
11
76%
12
23%
13
25%
18
11%
19
19%
27
30%
14
15
16%
98%
16
30
5%
20%
17
16%
21
23%
22
21%
23
7%
24
20%
25
25%
26
5%
28
18%
29
22%
31
9%
32
38
15%
81%
33
16%
34
7%
35
18%
36
4%
39
5%
40
18%
41
5%
Figure 20: Routing tree partitioned
by pathological links
0
50000
100000
150000
200000
250000
01:52 01:54 01:56 01:58 02:00 02:02 02:04 02:06 02:08 02:10
Rate X 10000 (pkts/sec)
Time(Hour:Min)
Rate during Slow Start
Figure 21: Startup behavior: Rate
Adaptation
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 22: Per-ow goodput with
high d
0
1
2
3
4
5
6
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 23: Behavior of IFRC with
pathological link loss
1
7
33%
0
21%
2
14%
3
17%
4
12%
5
6%
6
4%
8
16%
9
10%
10
21%
11
11%
12
14%
14
18
16%
24%
15
15%
16
7%
17
9%
19
20%
21
14%
22
24
7%
17%
23
20%
25
6%
26
11%
27
9%
28
31
5%
14%
29
5%
30
7%
32
33
39%
41
8%
34
10%
35
11%
36
8%
38
7%
39
9%
40
8%
Figure 24: Topology for multiple
base station experiment.
0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 25: Per-ow goodput with no
link-layer retransmissions
0
0.05
0.1
0.15
0.2
0.25
0 5 10 15 20 25 30 35 40 45
Goodput(pkts/sec)
Node Id
Per-Node Goodput
Figure 26: Per-ow goodput with
three link-layer retransmissions
12
ties of unacknowledged packets, with the aim of improving
overall goodput. Finally, several pieces of work have consid-
ered reliable point-to-point or point-to-multipoint delivery in
sensor networks [17, 16, 7, 14]; we hope to leverage some
of this work in the design of an end-to-end reliability mech-
anism that would complement IFRC.
5. CONCLUSIONS AND FUTURE WORK
In this paper, we have described the design and implemen-
tation of IFRC, an interference-aware rate control mech-
anism for wireless sensor networks. IFRC incorporates a
novel low-overhead congestion sharing mechanism that lever-
ages the prevalent tree-based communication pattern in wire-
less sensor networks. IFRC also detects incipient conges-
tion by monitoring average queue lengths, and implements
an AIMD control law for rate adaptation. IFRC is fair and
efcient in realistic wireless environments with packet loss
rate up to 30% and its queue management strategy com-
pletely prevents packet drops due to queue overow (at least
in the experiments we have conducted).
Our design of IFRC points to several directions for future
work: the integration of an end to end reliability mechanism
with IFRC; the design of estimators that are stable under
high load; and, an exploration of the subtleties of base station
behavior.
6. REFERENCES
[1] Chipcon Wireless Transceiver.
[2] Extensible Sensing System.
[3] Moteiv Corporation.
[4] Tenet: An Architecture for Tiered Embedded Networks.
[5] Vaduvur Bharghavan, Alan J. Demers, Scott Shenker, and Lixia
Zhang. MACAW: A Media Access Protocol for Wireless LAN's. In
SIGCOMM, pages 212225, 1994.
[6] S. Floyd and V . Jacobson. Random Early Detection gateways for
Congestion Avoidance. IEEE/ACM Transactions on Networking,
1(4), 1993.
[7] Jonathan W. Hui and David Culler. The Dynamic Behavior of a Data
Dissemination Protocol for Network Programming at Scale. In
Proceedings of the 2nd international conference on Embedded
networked sensor systems, pages 8194. ACM Press, 2004.
[8] Bret Hull, Kyle Jamieson, and Hari Balakrishnan. Mitigating
congestion in wireless sensor networks. In SenSys '04: Proceedings
of the 2nd international conference on Embedded networked sensor
systems, pages 134147, New York, NY , USA, 2004. ACM Press.
[9] C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed Diffusion:
A Scalable and Robust Communication Paradigm for Sensor
Networks. In Proceedings of Sixth International Conference on
Mobile Computing and Networking (MobiCom'00), 2000.
[10] V . Jacobson. Congestion Avoidance and Control. ACM Computer
Communication Review; Proceedings of the Sigcomm '88 Symposium
in Stanford, CA, August, + 1988, 18, 4:314329, 1988.
[11] Kamal Jain, Jitendra Padhye, Venkata N. Padmanabhan, and Lili Qiu.
Impact of interference on multi-hop wireless network performance.
In MobiCom '03: Proceedings of the 9th annual international
conference on Mobile computing and networking, pages 6680, New
York, NY , USA, 2003. ACM Press.
[12] Jinyang Li and Charles Blake and Douglas S. J. De Couto and Hu
Imm Lee and Robert Morris. Capacity of ad hoc wireless networks.
In Proceedings of the 7th ACM International Conference on Mobile
Computing and Networking, pages 6169, Rome, Italy, July 2001.
[13] Srisankar Kunniyur and R. Srikant. Analysis and Design of an
Adaptive Virtual Queue (A VQ) Algorithm for Active Queue
Management. San Diego, California, USA, 8 2001.
[14] P. Levis, N. Patel, D. Culler, and S. Shenker. Trickle: A
Self-Regulating Algorithm for Code Propagation and Maintenance in
Wireless Sensor Networks, 2004.
[15] Jeongyeup Paek, Krishna Chintalapudi, John Cafferey, Ramesh
Govindan, and Sami Masri. A Wireless Sensor Network for
Structural Health Monitoring: Performance and Experience. In
Proceedings of the Second IEEE Workshop on Embedded Networked
Sensors (EmNetS-II),, Syndney, Australia, May 2005.
[16] Fred Stann and John Heidemann. Rmst: Reliable data transport in
sensor networks. In Proceedings of the First International Workshop
on Sensor Net Protocols and Applications, pages 102112,
Anchorage, Alaska, USA, April 2003. IEEE.
[17] Chieh-Yih Wan, Andrew T. Campbell, and Lakshman
Krishnamurthy. PSFQ: A Reliable Transport Protocol For Wireless
Sensor Networks. In Proceeding of First ACM International
Workshop on Wireless Sensor Networks and Applications (WSNA
2002), pages 111, Atlanta, September 2002.
[18] Chieh-Yih Wan, Shane B. Eisenman, and Andrew T. Campbell.
CODA: Congestion Detection and Avoidance in Sensor Networks. In
Proceedings of the First ACM Conference on Embedded Networked
Sensor Systems (SenSys 2003)., pages 266279, Los Angeles,
November 2003.
[19] Alec Woo and David Culler. A Transmission Control Scheme for
Media Access In Sensor Networks. In Proceedings of the Seventh
Annual ACM/IEEE International Conference on Mobile Computing
and Networking (Mobicom 2001), 2001.
[20] Alec Woo, Terence Tong, and David Culler. Taming the Underlying
Challenges of Reliable Multihop Routing in Sensor Networks. In
Proceedings of the First ACM Conference on Embedded Networked
Sensor Systems (SenSys 2003)., Los Angeles, CA, November 2003.
[21] Kaixin Xu, Mario Gerla, Lantao Qi, and Yantai Shu. Enhancing TCP
fairness in ad hoc wireless networks using neighborhood RED. In
MobiCom '03: Proceedings of the 9th annual international
conference on Mobile computing and networking, pages 1628, New
York, NY , USA, 2003. ACM Press.
[22] Ning Xu, Sumit Rangwala, Krishna Kant Chintalapudi, Deepak
Ganesan, Alan Broad, Ramesh Govindan, and Deborah Estrin. A
wireless sensor network For structural monitoring . In SenSys '04:
Proceedings of the 2nd international conference on Embedded
networked sensor systems, pages 1324. ACM Press, 2004.
[23] W. Ye, J. Heidemann, and D. Estrin. An energy-efcient MAC
protocol for wireless sensor networks, 2002.
[24] Hongwei Zhang, Anish Arora, Young ri Choi, and Mohamed G.
Gouda. Reliable bursty convergecast in wireless sensor networks. In
MobiHoc '05: Proceedings of the 6th ACM international symposium
on Mobile ad hoc networking and computing, pages 266276, New
York, NY , USA, 2005. ACM Press.
13
APPENDIX
A. PSEUDOCODE FOR IFRC
w
i
= f airness weight
r
i
= r
init
r
parent
= bandwidth
nominal
Every 1=r
i
secs
Add w
i
packets to the queue
checkCongestion()
If(node is in slow start)
r
i
= r
i
+ f
If(node is in additive increase)
r
i
= r
i
+ d=r
i
checkNeighCongestion()
On every packet reception
Update neighbor information
if (packet from a child node)
add packet to the queue
checkCongestion()
checkCongestion()
if(avg
q
crosses an upper threshold
and no multiplicative decrease during
the last 1=r
i
sec)
do multiplicative decrease
move to congestion state
if(avg
q
goes below lower threshold
and node is in congestion state)
move to additive increase
checkNeighcongestion()
checkNeighCongestion()
r
cong neigh min
= min(r
j
of congested neighbor
or congested child of neighbor of i)
if(neighbor or child of a neighbor
is congested and r
cong neigh min
< r
i
)
r
i
= r
cong neigh min
if(node is in slow start)
move to additive increase
if(r
i
> r
parent
)
r
i
= r
parent
if(node is in slow start)
move to additive increase
if(r
i
r
init
)
r
i
= r
init
if(no local congestion)
enter slow start
Rate Control Module
r
i
= bandwidth
nominal
Every 1=r
i
sec
r
i
= r
i
+ d=r
i
if(r
i
> bandwidth
nominal
)
r
i
= bandwidth
nominal
On every packet reception
Update neighbor information
r
child min
=
min(r
i
of congested children of base station)
if(avg
q
of any child crossed an
upper threshold)
r
i
= r
child min
send a beacon message
send a beacon message every T sec or when r
i
changes by more than K
Rate Control Module(Base Station)
On every packet insertion
avg
q
= (1 w
q
) avg
q
+ w
q
inst
q
while(queue in not empty)
transmit packet at most max retransmit times
Queue Management Module
14
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 848 (2005)
PDF
USC Computer Science Technical Reports, no. 872 (2005)
PDF
USC Computer Science Technical Reports, no. 839 (2004)
PDF
USC Computer Science Technical Reports, no. 910 (2009)
PDF
USC Computer Science Technical Reports, no. 774 (2002)
PDF
USC Computer Science Technical Reports, no. 841 (2005)
PDF
USC Computer Science Technical Reports, no. 692 (1999)
PDF
USC Computer Science Technical Reports, no. 852 (2005)
PDF
USC Computer Science Technical Reports, no. 745 (2001)
PDF
USC Computer Science Technical Reports, no. 771 (2002)
PDF
USC Computer Science Technical Reports, no. 750 (2001)
PDF
USC Computer Science Technical Reports, no. 905 (2009)
PDF
USC Computer Science Technical Reports, no. 888 (2007)
PDF
USC Computer Science Technical Reports, no. 916 (2010)
PDF
USC Computer Science Technical Reports, no. 732 (2000)
PDF
USC Computer Science Technical Reports, no. 915 (2010)
PDF
USC Computer Science Technical Reports, no. 746 (2001)
PDF
USC Computer Science Technical Reports, no. 773 (2002)
PDF
USC Computer Science Technical Reports, no. 957 (2015)
PDF
USC Computer Science Technical Reports, no. 830 (2004)
Description
Sumit Rangwala, Ramakrishna Gummadi, Ramesh Govindan. "Interference-aware fair rate control in wireless sensor networks." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 873 (2005).
Asset Metadata
Creator
Govindan, Ramesh
(author),
Gummadi, Ramakrishna
(author),
Rangwala, Sumit
(author)
Core Title
USC Computer Science Technical Reports, no. 873 (2005)
Alternative Title
Interference-aware fair rate control in wireless sensor networks (
title
)
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Tag
OAI-PMH Harvest
Format
14 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16269664
Identifier
05-873 Interference-Aware Fair Rate Control in Wireless Sensor Networks (filename)
Legacy Identifier
usc-cstr-05-873
Format
14 pages (extent),technical reports (aat)
Rights
Department of Computer Science (University of Southern California) and the author(s).
Internet Media Type
application/pdf
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Source
20180426-rozan-cstechreports-shoaf
(batch),
Computer Science Technical Report Archive
(collection),
University of Southern California. Department of Computer Science. Technical Reports
(series)
Access Conditions
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Repository Email
csdept@usc.edu
Inherited Values
Title
Computer Science Technical Report Archive
Description
Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.
Coverage Temporal
1991/2017
Repository Email
csdept@usc.edu
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/