IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 28, NO

IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 28, NO. 7, SEPTEMBER 2010 1105

Handling Inelastic Traffic in Wireless SensorNetworks

Jiong Jin, Student Member, IEEE, Avinash Sridharan, Bhaskar Krishnamachari, Member, IEEEand Marimuthu Palaniswami, Senior Member, IEEE

Abstract—The capabilities of sensor networking devices areincreasing at a rapid pace. It is therefore not impractical toassume that future sensing operations will involve real time(inelastic) traffic, such as audio and video surveillance, whichhave strict bandwidth constraints. This in turn implies that futuresensor networks will have to cater for a mix of elastic (havingno bandwidth constraint requirements) and inelastic traffic.Current state of the art rate control protocols for wireless sensornetworks, are however designed with focus on elastic traffic. Inthis work, by adapting a recently developed theory of utility-proportional rate control for wired networks to a wireless setting,and combining it with a stochastic optimization frameworkthat results in an elegant queue backpressure-based algorithm,we have designed the first-ever rate control protocol that canefficiently handle a mix of elastic and inelastic traffic in a wirelesssensor network. We implement this novel protocol in a real worldsensor network stack, the TinyOS-2.x communication stack forIEEE 802.15.4 radios and evaluate the real-world performanceof this protocol through comprehensive experiments on 20 and40-node subnetworks of USC’s 94-node Tutornet wireless sensornetwork testbed.

Index Terms—Wireless Sensor Networks, Congestion control,Backpressure-based stacks, Stochastic optimization.

I. INTRODUCTION

FOR LOW-POWER wireless sensor networks (WSNs),the degradation of per-source sustainable rate is quite

drastic with increase in network size. In our experiments onthe USC Tutornet wireless sensor network testbed [1], it hasbeen observed that with a 40 byte packet, a 4-node networkcan give per-source rate as low as 16 pkts/sec. A 20-nodenetwork under similar conditions results in a reduction of per-source rate to ∼ 2 pkts/sec, and in a 40-node network thisrate reduces to ∼ 0.5 pkts/sec. Thus, even if low data ratesources are operational in these networks (which is typical fora WSN), given the scarce capacity, a sufficiently large numberof such sources can easily cause congestion collapse if they areoperating unaware of the sustainable rates in the network. Thisobservation reflects the importance of rate control protocolsfor these networks.

Manuscript received 18 May 2009; revised 16 February 2010. Jiong Jin andAvinash Sridharan are equal contributors in this work. Further, this work wassupported by the Australian Research Council under Grant DP0985322, ARCResearch Networks on Intelligent Sensors, Sensor Networks and InformationProcessing and NSF grants CNS-0347621, CNS-0325875, and CNS-0627028.J. Jin and M. Palaniswami are with the Department of Electrical and

Electronic Engineering, the University of Melbourne, Victoria 3010, Australia(e-mail: [email protected]; [email protected]).A. Sridharan and B. Krishnamachari are with Ming Hsieh Department of

Electrical Engineering, University of Southern California, Los Angeles, CA90089, USA (e-mail: [email protected]; [email protected]).Digital Object Identifier 10.1109/JSAC.2010.100915.

Given the importance of rate control protocols, there havebeen numerous proposals for congestion control in wirelesssensor networks (ARC [2], CODA [3], IFRC [4], RCRT [5],BRCP [6]). Despite the variance in the design techniquesused, and the capabilities of these protocols, a common themeunderlying all these protocols is that they are targeted towardsmanaging traffic, with elastic bandwidth requirements, i.e.,this traffic will present a non-zero utility as long as it has anon-zero bandwidth allocated to it. Typically, the goodness ofsuch a traffic can be measured by defining the utility achievedby the traffic as a logarithmic function of its rate. A typicalutility for such traffic is Us(rs) = log(rs + 1), where Us isthe utility of the source generating the traffic, and rs is thegoodput observed from this source. The utility obtained for anelastic source, at different allocated rates for such a log-basedutility can be seen in Figure 1(a).

A key reason for current proposals on rate control protocoldesign, with focus on elastic traffic, is the nascent nature ofsensor network deployments (Habitat monitoring, Structuralhealth monitoring). However, we believe that there are a wholerange of applications that are being targeted towards sensornetworks, such as audio and video surveillance, real-timetraffic monitoring, real-time seismic activity monitoring, thatwill force sensor networks to support real-time traffic withstrict bandwidth constraints. We term such traffic as inelastic.The utility for an inelastic traffic can be typically given by asigmoid function. The utility behavior of inelastic traffic withrate is shown in Figure 1(b). Given the heterogeneous natureof sensing devices that nodes in these networks (iMote2f [7],Iris [8], Tmote sky [9]) can carry, we envision that futuresensor networks will be required to carry a mix of elastic andinelastic traffic.

The problem of handling a mix of elastic and inelastictraffic is a known problem in the Internet context. For wirednetworks, Wang et al. [10] have shown that if a mix ofelastic and inelastic traffic is run over a network deployingrate control protocols that are designed to optimize the sumutility of elastic traffic, it leads to serious unfairness in termsof utility performance for the inelastic traffic. Though thisobservation has been made in the context of wired networks,it is safe to assume that such an unfairness will exist inwireless networks as well. The unfairness, resulting fromuse of rate control protocols designed for elastic traffic, isprimarily due to the underlying design philosophy which isreferred to as “Optimal Flow Control ”(OFC); under OFC,the objective has been to design rate control protocols that

0733-8716/10/$25.00 c© 2010 IEEE

1106 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 28, NO. 7, SEPTEMBER 2010

U

Bandwidth

(a) Elastic

U

Bandwidth

(b) Inelastic

Fig. 1. Behavior of utility for elastic and inelastic sources.

will try to maximize the sum utility of the sources. If theutilities are concave Log functions of sources, maximizingsum of utilities will result in a proportional fair rate allocation,making the design principles of OFC particularly attractivewhen dealing with elastic traffic. However, for inelastic trafficsince a proportionally fair rate allocation does not guaranteethat the inelastic sources will get a rate greater than theirminimum required rate, a proportionally fair rate allocationmight result in some inelastic sources getting zero utility; thisdespite the fact that they have non-zero rates.In the wired context, Wang et al. [10], propose a theoretical

framework for designing rate control protocols for handling amix of elastic and inelastic traffic. They show that, if we designrate control protocols that try to achieve proportional fairnessin terms of utilities, rather than proportional fairness in termsof rates, it improves the utility performance of inelastic sourcesdrastically, while impacting the utility performance of elasticsources marginally resulting in overall improvement in systemperformance.Our key contributions in this work are: first, we show that

by merging the theoretical framework presented by Wang etal. [10] with a recent proposal on wireless CSMA MAC layermodeling [11], we can develop elegant queue backpressure-based algorithms that will allow us to design rate controlprotocols for wireless sensor networks which can optimize ofnon-concave (inelastic) utilities, having the ability to handlea mix of elastic and inelastic traffic. To the best of ourknowledge this work is a first, in terms of extending thequeue backpressure-based stochastic optimization approachfor handling fairness of non-concave utility-based traffic ina wireless setting. Furthermore, we do not restrict ourselvesto the realm of theory, and use this framework to designand implement a rate control protocol that will be able tosupport a mix of elastic and inelastic traffic over the TinyOS-2.x communication stack. TinyOS-2.x is one of the mostpopular soperating systems currently used in wireless sensornetworks. We also test our implementation and design of thisnew utility-proportional-fair rate control protocol over a 20and 40-node subnetwork of the USC Tutornet testbed [1], a 94node wireless sensor network, and show that the performanceof this novel rate control protocol, over traditional rate controlprotocols designed for elastic traffic, is much better in terms ofthe utilities presented to the inelastic traffic, especially whenthere is a mix of elastic and inelastic traffic in the network.The rest of the paper is organized as follows. In Section II,

we discuss the prior art. In Section III we present our analysis

that allows us to extend the framework of wired networks,to a wireless sensor network running over a CSMA MAC.In Section IV, we present the system overview and presentthe implementation of the utility-proportional-fair rate controlstack over the TinyOS-2.x communication stack. In Section V,we present an evaluation of the utlity-proportional-fair ratecontrol stack over the USC Tutornet testbed [1] when testedin a setting having a mix of elastic and inelastic traffic. Finally,in Section VI, we present our conclusions and future work.

II. RELATED WORK

The formulation of the rate control stack design, as anoptimization problem was first motivated by the seminal workof Kelly et al. [12]. Chiang et al. [13] have built upon this sem-inal work and promoted a general theoretical framework forcross-layer protocol design to optimize system wide networkutility. The fundamental assumption of works above is thatthe rate-utility function is concave, and thus it is appropriateonly for elastic traffic. When inelastic traffic is concerned,the problem turns out to be non-convex and becomes hard tosolve. Further, Lee et al. [14] show that instability and highnetwork congestion may be caused by mixing of inelastic andelastic traffic in the absence of appropriate rate controllers.Hande et al. [15] have further derived the sufficient andnecessary conditions of the system optimality in a mixedtraffic scenario, and proposed a link provisioning method,which can potentially be used during network planning stage.Alternatively, Wang et al. [10] have developed a new ratecontrol framework that is able to deal with both elastic andinelastic traffic, such that the resulting utility is proportionalfair. All these results are mainly theoretical contributions inthe context of wired networks.For wireless networks in general, and wireless sensor net-

works specifically there have been several proposals for ratecontrol protocols (ARC [2], CODA [3], RCRT [5], IFRC [4],WRCP [16], ESRT [17], Ee and Bajcsy [18], Rangwala etal. [19]), however, as stated before none of these protocolsare designed to handle inelastic traffic. From a theoreticalstandpoint Neely et al. [20]–[22] have developed a stochasticnetwork optimization framework that models a general net-work as a queueing system with transmission rate subjectto resource allocation decisions, such as scheduling and ratecontrol, to achieve joint optimal performance. The ability totackle these problems in a stochastic settings makes theirsolutions more relevant to a wireless multi-hop scenario. Inparticular, the framework relies heavily on the existence ofa backpressure scheduling policy that can be implementedat the MAC layer. The backpressure scheduling policy wasinitially proposed by Tassiulas et al. [23], and assumes aTDMA synchronized operation with a centralized scheduler. Itis proven to achieve the maximum throughput compared withall other scheduling policies. More recently Jiang et al. [11]has also shown, that under idealized conditions, a similarqueue backpressure-based stochastic optimization frameworkcan be developed for a CSMA based MAC as well.The novelty of our work is that we show, that by com-

bining the framework presented by Wang et al. [10], withthe scheduling policy proposed by Jiang et al. [11], wecan garner intuition for designing practically implementable

JIN et al.: HANDLING INELASTIC TRAFFIC IN WIRELESS SENSOR NETWORKS 1107

flow controllers that exhibit proportional fairness in terms ofutility, allowing for development of rate control protocols forinelastic traffic over wireless networks. From a theoreticalstandpoint our contribution is to show that by modifyingthe scheduling policy proposed by Jiang et al. [11], we canachieve the same performance using per-destination queuesinstead of per-flow queues. This makes the theoretical designof the protocol, practically viable. To exhibit the validityof our design, we have implemented the above mentionedrate controller over the TinyOS-2.x communication stack, andexperimentally validated their performance in the presence ofa mix of elastic and inelastic traffic.

III. ANALYSIS

A. An Optimization framework for utility-fair flow control

Following the pioneering proposal of optimal flow con-trol [12], an extensive study of network flow control problemshas been carried out in the last decade (see [13] and referencestherein). Essentially, the approach is to formulate flow controlas an optimization problem and then maximize the sum utilityunder the capacity constraint:

P1: max∑

s∈S Us(rs) (1)

s.t. rs ∈ Λ (2)

where S = {1, 2, . . . , S} is the set of sources; for eachsource s ∈ S, rs is the source rate, Us(rs) is the associatedutility as a measure of performance (or equivalently QoS), andΛ denotes the capacity region.As shown in [10], even though the optimal flow control

(OFC) approach has made great advances in dealing withcongestion control and resource allocation, serious limitationsstill exist due to the objective of OFC of pursuing utilitymaximization. First, OFC assumes the nature of traffic iselastic (modeled by strictly concave utility functions), there-fore it is not applicable for inelastic traffic (modeled by non-concave utility functions) like increasingly popular real-timeapplications. Second, there exists a serious conflict betweenthe utility maximization and utility fairness; for the sourceswith different QoS requirements OFC seeks to maximizethe total utility, unfortunately this may cause extreme utilityunfairness among contending sources. In particular, the sourcewith strict bandwidth demand (inelastic) might receive a band-width requirement less than its minimum required, resultingin inelastic sources receiving “zero” utility.In order to support heterogeneous traffic (elastic and inelas-

tic), and guarantee utility fairness among competing flows1,we will adopt the newly developed flow control strategy byWang et al. [10]. This new mechanism of flow control, whichwe refer to as utility-fair flow control, is not only suitable forelastic traffic but also capable of handling inelastic traffic.In this framework, for each source s with utility function

Us(rs), we define a “pseudo utility” Us(rs) as

Us(rs) =∫ rs

ms

1Us(y)

dy, ms ≤ rs ≤Ms. (3)

1In the remainder of paper, we will use the term flow and source inter-changeably.

where ms ≥ 0 and Ms <∞ are the minimum and maximumtransmission rates required by source s respectively. Nowreplacing the utility function in the original optimizationproblem P1 with “pseudo utility” Us(rs), it leads to theoptimization problem P2

P2: max∑

s∈S Us(rs) (4)

s.t. rs ∈ Λ (5)

According to the optimization condition of P2, at theoptimum equilibrium r∗, we have that, for any feasible ratevector r �= r∗,∑

s∈S

∂Us(r∗s)∂rs

(rs − r∗s) =∑s∈S

rs − r∗sUs(r∗s)

≤ 0 (6)

Recalling the definition of well-known proportional fairness,a particular bandwidth allocation r∗ is proportional fair if forany feasible r �= r∗, ∑

s∈S

rs − r∗sr∗s

≤ 0. (7)

The solution of P2 thus achieves utility proportional fairness.We would like to emphasize that the strategy (P2) is philo-

sophically different from OFC (P1); OFC strives to achieveproportional fairness in terms of rates, however, utility-fairflow controller strives to achieve proportional fairness in termsof utilities. Thus, the utility-fair flow controller assumes thatthe utilities, rather than rates, are a meaningful metrics of QoSfor the flows.Moreover, it is clear from (3) that

U ′s(rs) =

1U(rs)

, ms ≤ rs ≤Ms (8)

and U ′s(rs) > 0 is strictly decreasing, according to the strictly

increasing property of Us(rs). Indeed “pseudo utility” Us(rs)is a strictly increasing concave function in the interval rs ∈[ms, Ms] regardless the concavity of source s’s utility functionUs(rs). Therefore, P2 stays as a convex optimization problemafter mapping, and is able to deal with elastic and inelastictraffic.

B. Achievable capacity region of CSMA MAC based wirelessnetworks

Since the optimization framework of utility-fair flow controlis primarily developed for wired networks, it cannot be directlyapplied to wireless networks. In order to solve the problemP2 in a wireless setting, we need a model that presents usall the constraints for the problem P2 in a wireless setting.One way of achieving this is to formulate a scheduling policythat will achieve the optimal throughput rate region of thewireless network. The scheduling policy will then give us theconstraints for the problem P2.Recently, Jiang et al. [11] proposed an adaptive scheduling

algorithm that can theoretically achieve the maximum through-put over a CSMA MAC. The work shows that if the rate of theback-off window (an exponential random variable) is chosenaccording to a queue differential between a node and its parent,the system can achieve 100% throughput. We can thereforeuse the framework proposed by Jiang et al. [11], to define the


constraints of the problem P2. In the next section, we willcombine the above frameworks proposed by Wang et al. [10],and Jiang et al. [11], to develop a queue backpressure-basedutility-fair flow control protocol that will be implemented atthe transport and the MAC layer respectively.

C. Joint flow control and scheduling algorithm

A key problem with the scheduling policy proposed byJiang et al. [11] is that it assumes the per-flow queue model,i.e., each link maintains a separate queue for each flow travers-ing through that link. This will obviously result in overhead,and make the implementation difficult, especially when a largenumber of flows are active in the network. Therefore, whenmerging the frameworks proposed by Wang et al. [10] andJiang et al. [11], we show that the scheduling policy proposedby Jiang et al. [11] can be changed from per-flow queue toper-destination queue, without any loss in performance. Thismodification particularly helps in simplifying the implemen-tation of the protocol.

Consider a multi-hop wireless network with L links, and letL denote the set of links and N denote the set of nodes. Foreach link l ∈ L, it can also be represented by a node pair (i, j),meaning transmission from node i to node j. Assume thereare a set S of flows and a set D of intended destinations. Eachflow s is associated with a source node fs and a destinationnode ds, and is able to adjust the input rate. Let rs be the rate,and Us(rs) be the defined “pseudo utility” function of flow s.

Each node i maintains per-destination queues for flowsthat traverse it, i.e., different queues are maintained for flowsdestined to different destinations. Denote γd

ij the service rateof queue towards d ∈ D on link (i, j). Then, the servicerate of each particular queue on node i should be no lessthan the incoming rate, i.e.,

∑j:(i,j)∈L γd

ij ≥∑

j:(j,i)∈L γdji +∑

s:fs=i,ds=d rs.

Furthermore, in [11], it has been shown that the maximum-weight scheduling policy can be effectively modeled as max-imizing the entropy of a Markov chain

maxu

−∑

k

uk log uk

s.t.∑

k

uk · xk(i,j) ≥ λij , ∀(i, j) ∈ L (9)

where uk is a variable satisfying uk ≥ 0,∑

k uk = 1.xk

(i,j) indicates the transmission status of link (i, j) undera particular scheduler xk ∈ {0, 1}L. λij is normalized i.i.darrival traffic rate at each link (i, j).Now, we can formulate the optimization problem in (10).

The tuning parameter V is used in (10) to determine theextent to which “pseudo utility” optimization is emphasized.As shown in [22], it presents a tradeoff between the optimalityand system queue backlog. The 3rd constraint of (10) saysthat the total service rate of link (i, j) is divided among thedestination queues. By associating dual variables qd

i ≥ 0 tothe 2nd constraint, a partial Lagrangian (subject to γd

ij ≥

0,∑

k uk · xk(i,j) =

∑d∈D γd

ij and uk ≥ 0,∑

k uk = 1) is

L(u, γ, r; q)

= −∑

k

uk log(uk) + V∑s∈SUs(rs)

+∑

d∈D,i�=d

qdi

⎛⎜⎜⎝ ∑

j:(i,j)∈Lγd

ij −∑

j:(j,i)∈Lγd

ji −∑

s:fs=ids=d

rs

⎞⎟⎟⎠

= −∑

k

uk log(uk) + V∑s∈SUs(rs)

−∑s∈S

qds

fsrs +

∑(i,j)∈L,d∈D

γdij(q

di − qd

j ) (11)

First fixing the vectors u and q, we solve for γdij in the

sub-problem

maxγ

∑(i,j)∈L,d∈D

γdij(q

di − qd

j )

s.t. γdij ≥ 0, ∀(i, j) ∈ L, ∀d ∈ D∑

d∈Dγd

ij =∑

k

uk · xk(i,j), ∀(i, j) ∈ L. (12)

It is quite straightforward to find the solution: for eachlink (i, j), let d∗(i, j) = argmaxd(qd

i − qdj ), and let γd

ij =∑k uk · xk

(i,j) if d = d∗(i, j) and γdij = 0, otherwise. In other

words, each link schedules the transmission of the destinationqueue whose backpressure qd

i − qdj is maximum.

Substitute the solution of (12) into (11), we get

L(u, r; q)=

⎡⎣−∑

k

uk log(uk) +∑

(i,j)∈Lzij

(∑k

uk · xk(i,j)

)⎤⎦

+

[V∑s∈SUs(rs)−

∑s∈S

qds

fsrs

]

where zij := maxd(qdi − qd

j ) is the maximum backpressure oflink (i, j). Hence, a distributive algorithm to solve (10) is asfollows

Algorithm: Joint flow control and scheduling

Initially, assume that all queues are empty, and set qdi =

0, ∀i, d.

• Transport layer (flow control): the rate of each flow sis determined by

r∗s = argmaxrs{V · Us(rs)− qds

fsrs}

= U−1s

(V

qds

fs

).

It maximizes L(u, r; q) over r.• MAC layer (scheduling): link (i, j) schedules the trans-mission of destination queue with the maximum back-pressure zij = maxd(qd

i − qdj ) when it gets the oppor-

tunity. Specifically, the back-off window size is set tobe an exponential random variable with mean 1

exp(zij). It

maximizes L(u, r; q) over u [11]. The dual variable qdi


maxu,γ,r

−∑

k

uk log uk + V∑s∈SUs(rs) (10)

s.t. γdij ≥ 0, ∀(i, j) ∈ L, ∀d ∈ D∑

j:(i,j)∈Lγd

ij ≥∑

j:(j,i)∈Lγd

ji +∑

s:fs=ids=d

rs, ∀d ∈ D, ∀i �= d

∑k

uk · xk(i,j) =

∑d∈D

γdij , ∀(i, j) ∈ L

uk ≥ 0,∑

k

uk = 1

is updated by

qdi ←

⎡⎢⎢⎣qd

i − α

⎛⎜⎜⎝ ∑

j:(i,j)∈Lγd

ij −∑

j:(j,i)∈Lγd

ji −∑

s:fs=ids=d

rs

⎞⎟⎟⎠⎤⎥⎥⎦

+

where [a]+ = max{0, a}. We observe that qdi ∝ Qd

i .Then Qd

i , the actual queue length of node i for destina-tion d, can be used as the corresponding dual variable.

Remark 1: Though the Algorithm appears similar to thosein [22], [24], it is philosophically different in terms of theobjective and the chosen MAC model.

IV. IMPLEMENTING UTILITY-FAIR FLOW CONTROL IN

TINYOS-2.X

As mentioned earlier, the objective of this work is not onlyto build a framework that will allow us to present quantitativedesigns of utility-fair flow controllers that can support inelastictraffic in a sensor network, but to realize these designs inpractice. In this section, inline with our goals, we present asoftware architecture that allows us to implement the utility-fair controller presented in Section III, in the TinyOS-2.xnetwork stack, one of the most popular operating systemsin the wireless sensor network community. It is importantto note that though the analytical framework presented inSection III is applicable to any general multi-hop wirelessnetwork, we choose wireless sensor network as a specific usecase of this framework for exhibiting the practicality of thedesign approach pursued in this work.As described in Section III-C, in order to implement

the utility-fair flow controller we need to implement abackpressure-based scheduler at the MAC layer, and use thequeueing information presented by this backpressure-basedscheduler to implement the utility-fair flow controllers at thetransport layer. Figure 2 presents a software architecture thatcaptures the design of such a backpressure-based rate controlstack.For the purposes of this work we restrict our investigation

specifically to a fixed collection tree, implying that there existsa single destination in the network to which all sources arerouting their data. We concentrate specifically on a collectiontree, since as shown in Section III, it is trivial to extend thisdesign to multiple destination. In order to support multipledestination all that needs to be added to this design is a per-destination queue.

Application

Leaky Bucket Flow Controller

Routing Engine Forwarding Engine

Communication Stack

Fig. 2. Software architecture for a backpressure-based stack.

When routing is fixed, the backpressure-based rate controlstack is implemented at the MAC and the transport layers.The transport layer functionality is implemented as part of the“Leaky Bucket” and “Flow Controller” blocks in Figure 2. Theflow controller needs to determine the allowed instantaneousrate of admission as a function of the forwarding queue size.The “Flow Controller” block in Figure 2 interacts with theforwarding engine to learn the instantaneous queue size, andsets an allowed admission rate in the leaky bucket. The leakybucket then generates tokens at the admission rate. When apacket arrives from the application to the flow controller, it isinjected into the forwarding engine only if a token is available.

The backpressure-based MAC is implemented as part ofthe “Forwarding Engine” and “Communication stack” blocks(Figure 2). The forwarding engine calculates the currentqueue differential, using information about parent queue size(learned through periodic broadcasts) and its own queue size.Based on the current queue differential, the forwarding enginedecides wether or not to transfer a packet to the MAC layer(represented by the communication stack in Figure 2). If thescheduler wants to implement differential queue prioritization,the forwarding engine can use interfaces provided by theunderlying MAC to modify the MAC back-off window sizes,before injecting the packet.

We now describe the implementation of the transport andMAC layer in further detail.


A. Transport layer

The key component in implementing the transport layer isthe flow controller block. The objective of the flow controlleris to operate the source at a time average rate rs, allowing thesource to achieve a utility Us(rs), such that the rate allocationrs, ∀ s, maximizes

∑s Us(rs) across the entire network. Note

that the flow controller runs at each node, and hence it needsto make local decisions, but the local decisions should be suchas to optimize a global function (max

∑∀s Us(rs)).

If we want to implement a utility-fair flow controller,Section III shows that it maximizes the total “pseudo utility”Us(rs) =

∫1

Us(rs)drs. For an inelastic source, the utility

function Us(rs) will be given by a sigmoid function, whilefor the elastic source the utility function Us(rs) will be givenby a logarithmic function [25]. We now present the designof the sigmoid-utility-fair flow controller and the log-utility-fair flow controller, for regulating inelastic and elastic trafficsources.

1) Sigmoid-utility-fair flow controller: The sigmoid-utility-fair flow controller is designed to be used with an inelasticsource. The utility function for real-time inelastic traffic is asfollows:

Us(rs) = 0, if rs ≤ Bmin

= 11+e−a(rs−b) , if Bmin ≤ rs ≤ Bmax

= 1, if rs ≥ Bmax

Bmin and Bmax are the minimum and maximum bandwidthconstraints on the sigmoid, b = (Bmax−Bmin

2 ) + Bmin , acontrols the slope of the sigmoid.From the Algorithm in Section III-C, the optimal rate r∗s is

given by:

r∗s = argmax (V Us(rs)− qsrs) = U−1s

(V

qs

)Note that since here we consider the single destination case,the superscript d is omitted for simplicity. As pointed out,V is a constant that acts as a tuning parameter to effect atradeoff between the forwarding queue size qs, and “pseudoutility” Us(rs). A large value of V will imply large value of qs,and large total Us(rs). Whereas a small value of V will implysmall value of qs, and small total Us(rs).2 The implementationwould set r∗s as follows:

r∗s = b − 1a log

(qs

V − 1), qs > V

= Bmax, qs < V

2) Log-utility-fair flow controller: The log-utility-fair flowcontroller is designed to be used with elastic traffic. The utilityfunction for elastic traffic is as follows:

Us(rs) = log(rs + 1)

We offset the rate by +1 to ensure the positiveness of theutility. Again, the optimal rate r∗s is

r∗s = argmax (V Us(rs)− qsrs) = U−1s

(V

qs

)

2It should be noted that the flow controller designs presented here aresimilar to the proposals presented by Sridharan et al. [6].

Hence,r∗s = e

Vqs − 1

B. MAC Layer

In order for the backpressure based flow controllers towork, it is imperative that the underlying MAC implements abackpressure-based scheduling policy. Since, the Algorithm inSection III-C is a backpressure scheduling algorithm that canachieve the maximum throughput on a CSMA MAC, ideallywe should be modifying the existing CSMA MAC to supportthis algorithm.While theoretically the algorithm described in Section III-C

is quite appealing, and it can be realized in a real system aswell, in practice the performance of this algorithm is quitepoor. This is primarily due to the fact, that in practice it ishard to realize every possible mapping between the queuedifferential of a node with its parent, and the resulting back-off window mechanism. In [6] the authors show that dueto these practical limitations, a CSMA MAC whose windowsize is mapped to the queue differential can perform muchworse than a much simpler backpressure scheme, where theforwarding engine allows a packet to the enter the MAClayer if it sees a positive queue differential with the next-hop. In this naive backpressure scheduler, once packet entersthe MAC its transmission slot is chosen, unlike the idealbackpressure scheduler, using a uniformly random back-offtimer independent of the size of the queue differential. Theauthors, in [6], call this simple version of a backpressurescheduling policy, the positive differential queue MAC (PDQMAC).Based on the empirical evidence presented by us in [6], we

chose to implement the backpressure scheduling policy at theMAC in the form of the PDQ MAC. In order to implementthe PDQ MAC over the TinyOS-2.x CSMA MAC the onlymodification was addition of a 1 byte queue size field to theMAC header which will be used by the MAC layer to learnthe queue backlog information of the next-hop by snoopingpackets transmitted by the next-hop. Given that the PDQ MACcan learn the queue differential information between a nodeand its next-hop, it uses this information to accept packetsinjected by the forwarding engine only if the queue differentialinformation is positive. The PDQ MAC thus results in a verysimple backpressure scheduler which, as we will see in ourexperiments, performs quite well in practice.

V. EVALUATION

In order to test the performance of the utility-fair flowcontrollers presented in Section IV-A and implemented inTinyOS-2.x, we ran different types of traffic generators (elas-tic and inelastic) over the backpressure-based rate controlstack (Section IV). We compared its performance with asimilar backpressure-based stack running the proportional-fair flow controller instead of the utility-fair flow controllers.The proportional-fair flow controller is the traditional flowcontroller, based on the OFC design, where the flow controllertries to optimize for the sum utility (

∑s Us(rs)) of the traffic

instead of trying to optimize for the sum “pseudo utility”(∑s Us(rs) =

∑s

∫1

Ui(rs)drs

), which is the objective of the


1

7

12

2

34

5

6

8

9

11

13

10

14

15 16

17

18

20

19

(a) 20-node

1

7

12

23

5

4

6

14

8

9 10

11

13

16

15

20

29

17 18 19

21

22 23

24 25

26 27 28

30

31

32 33 34

35 36

37 38

39 40

(b) 40-node

Fig. 3. Routing topologies on the USC Tutornet [1] testbed.

utility-fair flow controller. Despite the existence of numerousrate control protocols for wireless sensor networks (RCRT [5],IFRC [4], WRCP [16]), we choose to compare the utility-fair flow controller against the proportional-fair flow controllerdeveloped on top of our own backpressure-based stack, sincenone of the existing rate control protocols exhibit the ability toperform proportional fair rate allocation. The purpose of thiscomparative evaluation is two fold: first it shows how using anOFC based flow controller, such as the proportional-fair flowcontroller leads to extremely poor performance for inelastictraffic, when inelastic and elastic traffic are mixed; second itshows the gains achieved, in terms of improvements in utilityperformance of inelastic traffic, when used in the same trafficsettings.

A. Experimental setup

The comparative experiments were performed on the USCTutornet testbed [1], a 94 node wireless sensor networktestbed. The testbed consists of Tmote sky [9] devices whichcan run the TinyOS-2.x operating system. The Tmote skydevices come fitted with an 802.15.4 compatible CC2420 [26]radio. The TinyOS-2.x platform comes with a default CSMAMAC, called the CC2420 MAC, that can operate over theseradios. Of the 94 nodes present in the testbed, we used amaximum of 40 nodes. The experiments were performed over

two different routing topologies, a 20-node topology and a40-node topology shown in Figure 3(a) and 3(b).The CC2420 radio can operate at 31 different power levels.

For these experiments, for the 20-node topology, we operatedthe CC2420 radios at a power level of 5, and at a power levelof 10 for the 40-node topologies. The power levels for the twotopologies were chosen to ensure that the network topologieswere connected and also had a healthy density of interferinglinks, to make the results interesting.

B. Proportional-fair flow controller

The proportional-fair flow controller is designed and im-plemented similar to the utility-fair flow controllers, whichhave been described in Section IV-A. The only differencebetween the implementation of the utility-fair flow controllersand the proportional-fair flow controller is that in the case ofthe utility-fair flow controller we deal with “pseudo utility”Us(rs) =

∫1

Us(rs)drs, where as for the proportional flowcontroller we just deal with the utility Us(rs).The flow controller than sets the instantaneous rate rs(t) to

the following :

r∗s = argmax (V Us(rs)− qsrs)

For the proportional flow controller Us(rs) = log(rs + 1),hence the instantaneous rate will be set to :

r∗s = Vqs− 1, if V

qs≥ 1

= V, if qs = 0= 0, if V

qs< 1

where V is the same constant that presents a tradeoff betweenthe total utility achieved and the queue size in the system.Incidentally, this is the exact design that has been proposed bySridharan et al. in [6] and [27], using the Lyapunov drift-basedstochastic optimization technique proposed by Neely et al.[20]–[22], as well as the design proposed by Akyol et al [28]based on the stochastic optimization technique proposed byStolyar [24].

C. Traffic sources

A key to performing this empirical evaluation is to havetraffic generators that can emulate the elastic and inelastictraffic in a real world wireless sensor network. For elastictraffic generator, we choose a CBR traffic that generates apacket every 10 ms. Emulating an inelastic source is morecomplicated. To emulate the inelastic source, we implementeda traffic generator that injects packets into the system asfollows: recall that the utility of an inelastic source is givenby a sigmoid function having a minimum and maximumbandwidth constraints of Bmin andBmax. Our inelastic sourcesimply tries to emulate this utility function; if the allocatedrate to the source is less than Bmin the source does notinject any packets into the system; if the allocated rate tothe source is Bmin ≤ ri < Bmax, the source injects packetinto the system with a probability p = 1

1+e−a(rs−b) , whereb = (Bmax−Bmin

2 ) + Bmin, and a is set to 2; if the allocatedrate to the source is greater than Bmax it injects packet into thesystem probability 1. The inelastic source generates packetsat a constant rate of 1 packet every 10 ms, however whether


5

10

15

20

25

30

35

40

0 25 50 75 100 125

150 175

200 225

250 0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000

Tot

al L

og U

tility

Tot

al A

vera

ge Q

ueue

Len

gth

V

Log UtilityAvg Queue Length

(a) 20 node, Utility-fair controller

5

10

15

20

25

30

35

40

45

50

0 25 50 75 100 125

150 0 150 300 450 600 750 900 1050 1200 1350 1500 1650 1800 1950 2100 2250 2400 2550 2700 2850 3000

Tot

al L

og U

tility

Tot

al A

vera

ge Q

ueue

Len

gth

V


(b) 40 node, Utility-fair controller

5

10

15

20

25

30

35

40

45

50

0 25 50 75 100 125

150 0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800

Tot

al L

og U

tility

Tot

al A

vera

ge Q

ueue

Len

gth

V


(c) 20 node, proportional controller

5

10

15

20

25

30

35

40

45

50

0 25 50 75 100 125

150 175

200 225

250 275

300 0 150 300 450 600 750 900 1050 1200 1350 1500 1650 1800 1950 2100 2250 2400 2550 2700 2850 3000

Tot

al L

og U

tility

Tot

al A

vera

ge Q

ueue

Len

gth

V


(d) 40 node, proportional controller

Fig. 4. Selecting the optimal value of the parameter V for the 20 and 40-node topologies, for the utility-fair and proportional fair flow controllers.

it decides to inject the packet into the system or not dependson the above mentioned conditions. The packet sizes in ournetwork are ∼ 40 bytes.

D. Parameter selection

A large V will force the system to operate close to edge ofthe rate region; allowing for close-to-optimal utility, albeit atthe cost of large queues. While a small value of V will allowthe system to operate well within the rate region; allowing forsmall queue sizes, albeit at the cost of sub-optimal utility.For the 20 and 40-node topologies, in order to determine the

optimal setting of V , we plot the utility and queue behaviorfor different values of V . For this experiment all sources areassumed to be elastic sources. Thus the system utility beingmeasured is

∑s log(rs). Since all sources are elastic, we use

the log-utility fair flow controller (Section IV-A2) when testingthe utility-fair flow controllers. The results of this experimentare presented in Figure 4. For each of the flow controllers, overeach of the topologies, it can be seen that the utility increaseslogarithmically with V , while queue sizes increases linearlywith V . Also, for each of the graphs, after a certain value ofV the utility actually starts falling while the queue sizes keepincreasing. This behavior occurs due the finite queue sizes thatexist in all practical system. Due to the limitation of queuesizes, packet drops start occurring after a certain value of Vresulting in loss of utility. Thus, for the system to operateefficiently we will have to select a V that will allow for goodutility while allowing the system to operate within the finitebounds of the queue sizes. From this figure it can be seenthat a value of V = 30 for the 20-node topology, and V = 5for the 40-node topology will present good performance for

the utility-fair flow controller. Similarly for the proportionalflow controller we choose a value of V = 100 for the 20-nodetopology, and V = 50 for the 40-node topology.

E. Performance of the Utility-fair flow controller

We perform a comparative evaluation between the two typesof flow controllers using the following two traffic scenarios:In the first scenario all sources in the network are elastic. Thisparticular scenario helps us validate the implementation of theutility-fair controller. In this scenario, the utility and goodputfor the sources should be similar to the utility and goodputwhen using the proportional flow controller. For the secondscenario, we use traffic mix of elastic and inelastic traffic.This particular scenario showcases the advantage of the utility-fair flow controller over the proportional fair flow controller.The expectation in this scenario is that the utility-fair flowcontroller will treat the inelastic traffic fairly, by giving it ahigher priority, and presenting the inelastic traffic with a betterutility than in the case when the same traffic mix is run overa proportional flow controller.1) Elastic Traffic: For this specific case, due to space

constraints we present only results from experiments on the40-node topology3. The Figure 5 presents the performance ofthe utility-fair flow controller and the proportional-fair flowcontroller when all sources in the network are elastic. Since allsources are elastic, all nodes use the log-utility flow controllerto represent the utility-fair flow controller. It can be seen thatthe goodput distribution using either flow controller is very

3It should be noted that the same experiment was performed on the20-node topology as well, with an improvement over the results presentedhere.


0.01 0.0133333 0.0177778 0.0237037 0.0316049 0.0421399 0.0561866 0.0749154 0.0998872

0.133183 0.177577

0.23677 0.315693 0.420924 0.561232 0.748309 0.997746

1.33033 1.77377 2.36503 3.15337 4.20449 5.60599 7.47465

9.9662 13.2883 17.7177 23.6236

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Goo

dput

(Pk

ts/s

ec)

Node ID

Utility-fair controllerProportional controller

(a) Goodput

0.01

0.02

0.04

0.08

0.16

0.32

0.64

1.28

2.56

5.12

10.24

20.48

40.96

Total

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

Util

ity

Node ID


(b) Utility

Fig. 5. Goodput and utility comparison for the 40-node topology with elastictraffic.

similar. The proportional flow controller outperforms the log-utility flow controller, but by only a small margin. For thistopology the proportional flow controller presents a sum log-utility of 31.22, while the log-utility flow controller presentsa sum log-utility of 27.36. The reason for the sub-optimalityof the log-utility-fair controller is that, the log-utility-faircontroller has been optimized for presenting a proportionallyfair solution in terms of utility; while the proportional faircontroller is designed specifically to maximize the sum log-utility, since this presents proportional fairness in terms ofrates. The objective of presenting these results is that thoughthe log-utility-fairness is suboptimal in terms of achievingproportional fairness in terms of rates, it still is able togive a rate distribution comparative to the proportional-faircontroller; given the performance gains presented by theutility-flow controller in more demanding traffic scenario, theresults presented here motivate the argument for the use of theutility-fair flow controller in all traffic scenarios.2) Elastic and Inelastic Traffic: The goal of developing the

utility-fair flow controllers was to present nodes in a wirelesssensor network the ability to support a mix of elastic andinelastic traffic. In this section we validate this goal. Wetest the performance of the utility-fair flow controller and

0

0.75

1.5

2.25

3

3.75

4.5

5.25

6

6.75

7.5

8.25

9

9.75

1 2 3-in4-in5 6 7 8 10-in11 12 13 14 15 16 17-in18-in19-in20-in

Goo

dput

(Pk

ts/s

ec)

Node ID

Utility-fair controllerProportional controlle r

(a) Goodput

0.01

0.02

0.04

0.08

0.16

0.32

0.64

1.28

2.56

5.12

10.24

20.48

40.96

1 2 3-in4-in5 6 7 8 10-in11 12 13 14 15 16 17-in18-in19-in20-in

Util

ity

Node ID

Utility-fair controllerProportional controlle r

(b) Utility

Fig. 6. Goodput and utility comparison for the utility-fair flow controller,and the proportional flow controller for the 20-node topology.

the proportional-fair flow controller over the 20 and 40-nodetopologies, in terms of the goodputs and utility achieved by thesources, under a mixed traffic setting. In order to emulate themix of elastic and inelastic traffic, for the 20-node topologysources 3, 4, 10, 17, 18, 19 and 20 are inelastic sources; allother sources are elastic sources. For the 40-node topologysources 1-10, 12, 26, 27, 28, 39 and 40 are inelastic; all othersources are elastic sources. As mentioned earlier, in the caseof the utility-fair flow controllers the source use a specific typeof utility-fair flow controller, depending on the type of trafficthey are generating. The elastic source use the log-utility flowcontroller, and the inelastic sources use the sigmoid-utility flowcontroller. For the case of the proportional flow controller,since there exist only a single type of flow controller, allsources use the same flow controller.

There is a specific reason for choosing this distributionof sources for these topologies. Since the proportional flowcontroller strives to achieve a tradeoff between efficiency andfairness, it presents sources that are closer to the sink witha much higher rate than nodes that are farther away fromthe sink. Thus, by choosing the given traffic mix we areable to clearly highlight the disdvantage the proportional flow


controller presents to the inelastic traffic. This is reflectedin the results for the 20 and 40-node topologies shown inFigures 6 and 7.For the 20-node topology, for the inelastic traffic the Bmin

of the sigmoid utility is set to 2 pkts/sec, and Bmax is set to4 pkts/sec. For the 40-node topology, for the inelastic trafficthe Bmin of the sigmoid utility is set to 1 pkts/sec, andBmax is set to 4 pkts/sec. In the x-axis, the inelastic trafficsources are marked with the suffix “-in”. Both the goodputand utility plots show that, when using the proportional fairflow controller some of the inelastic sources get a goodput lessthan Bmin. A direct result of this unfairness results in thoseinelastic sources getting zero utility. In a practical sense thisimplies that any data sent by these sources simply resultedin a wastage of energy since the data received at the sinkwill be useless, given that they are getting zero utility. Theperformance of the inelastic sources is greatly improved whenusing the utility-fair controllers. As can be seen when using theutility-fair flow controllers, the inelastic sources get a muchhigher goodput, since they are given higher priority, and thisautomatically results in a much higher utility than in the caseof the proportional fair flow controller. The results presentedin this section clearly validate our design and motivation ofusing utility-fair controllers for handling a mix of elastic andinelastic traffic.

VI. CONCLUSION AND FUTURE WORK

In this work, we have extended the concept of designing ratecontrol protocols that can achieve utility-proportional fairnessin a wireless sensor network running over a CSMA MAC.Experiments of this novel rate control stack, over the USCTutornet [1] testbed, show that this new rate control stackpresents inelastic sources with much better utilities, than ifthe same sources were run with a rate-proportional fair ratecontrol protocol, designed using the traditional optimal flowcontrol model.Though the empirical results presented here are encourag-

ing, there are still some open problem before the protocolspresented can be widely adopted in existing communicationstacks. The key issue is with the parameter V , on which theperformance of these protocols rely heavily. As mentionedearlier, and seen in our empirical results, V presents a tradeoffbetween the network queue size and utilities achieved. Theoptimal setting of V depends on the traffic pattern (numberof flows in the network), and the network topology. Thus, de-pending on the traffic pattern and network topology, the settingof V might need to be changed continuously in order to derivegood performance from the stack. This has been highlightedin [6] as well. Our future work will therefore be targetedtowards designing online algorithms that can estimate on thefly, the value of this parameter V . Recently, the technique ofusing flotaing queues within a backpressure-based algorithmused for designing the routing protocol BCP [29], in order toreduce the queue size in the network and hence the variationin the value of the parameter V with varying network size isa promising result; we hope to leverage this result in order towork towards finding a solution to dynamically estimate thisparameter V .

0.01 0.0133333 0.0177778 0.0237037 0.0316049 0.0421399 0.0561866 0.0749154 0.0998872

0.133183 0.177577

0.23677 0.315693 0.420924 0.561232 0.748309 0.997746

1.33033 1.77377 2.36503 3.15337 4.20449 5.60599 7.47465

9.9662 13.2883 17.7177 23.6236

1-in 2-in 3-in4-in5-in 6-in7-in8-in9-in10-in11 12-in13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39-in40-in

Goo

dput

(Pk

ts/s

ec)

Node ID


(a) Goodput

0.01

0.02

0.04

0.08

0.16

0.32

0.64

1.28

2.561-in 2-in 3-in4-in5-in 6-in7-in8-in9-in10-in11 12-in13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39-in40-in

Util

ity

Node ID


(b) Utility

Fig. 7. Goodput and utility comparison for the utility-fair flow controller,and the proportional flow controller for the 40-node topology. For inelastictraffic Bmin = 1 pkts/sec, and Bmax = 4 pkts/sec.

REFERENCES

[1] “http://testbed.usc.edu.”[2] A. Woo and D. E. Culler, “A transmission control scheme for media

access in sensor networks,” in ACM MOBICOM, 2001.[3] C. Y. Wan, S. B. Eisenman, and A. T. Campbell, “CODA: Congestion

detection and avoidance in sensor networks,” in ACM SENSYS, 2003.[4] S. Rangwala, R. Gummadi, R. Govindan, and K. Psounis, “Interference-

aware fair rate control in wireless sensor networks,” in ACM SIGCOMM,2006.

[5] J. Paek and R. Govindan, “RCRT: rate-controlled reliable transport forwireless sensor networks,” in ACM SENSYS, 2007.

[6] A. Sridharan, S. Moeller, and B. Krishnamachari, “Investigatingbackpressure-based rate control protocols for wireless sensor networks,”in USC EE CENG Technical Report, CENG-2008-7, 2008.

[7] “http://www.xbow.com/products/productdetails.aspx?sid=253.”[8] “http://www.xbow.com/products/productdetails.aspx?sid=264.”[9] “http://www.moteiv.com.”[10] W. H. Wang, M. Palaniswami, and S. H. Low, “Application-oriented

flow control: fundamentals, algorithms and fairness,” IEEE/ACM Trans.Netw., vol. 14, no. 6, pp. 1282–1291, December 2006.

[11] L. Jiang and J. Walrand, “A distributed CSMA algorithm for throughputand utility maximization in wireless networks,” in Allerton Conferenceon Communication, Control, and Computing, 2008.

[12] F. P. Kelly, A. Maulloo, and D. Tan, “Rate control for communicationnetworks: Shadow prices, proportional fairness and stability,” Journalof Operations Research Society, vol. 49, no. 3, March 1998.

[13] M. Chiang, S. H. Low, A. R. Calderbank, and J. C. Doyle, “Layer-


ing as optimization decomposition: a mathematical theory of networkarchitectures,” Proceedings IEEE, vol. 95, no. 1, January 2007.

[14] J. W. Lee, R. R. Mazumdar, and N. B. Shroff, “Non-convex optimizationand rate control for multi-class services in the internet,” IEEE/ACMTrans. Netw., vol. 13, no. 4, August 2005.

[15] P. Hande, S. Zhang, and M. Chiang, “Distributed rate allocation forinelastic flows,” IEEE/ACM Trans. Netw., vol. 15, no. 6, December 2007.

[16] A. Sridharan and B. Krishnamachari, “Explicit and precise rate controlin wireless sensor networks,” in ACM SENSYS, 2009.

[17] Y. Sankarasubramaniam, O. B. Akan, and I. F. Akyildiz, “ESRT:Event-to-sink reliable transport in wireless sensor networks,” in ACMMOBIHOC, 2003.

[18] C. T. Ee and R. Bajcsy, “Congestion control and fairness for many-to-one routing in sensor networks,” in ACM Sensys, 2004.

[19] S. Rangwala, A. Jindal, K. Jang, K. Psounis, and R. Govindan, “Un-derstanding congestion control in multi-hop wireless mesh networks,”in ACM MOBICOM, 2008.

[20] M. J. Neely, “Dynamic power allocation and routing for satellite andwireless networks with time varying channels,” Ph.D. dissertation,Massachusetts Institute of Technology, 2003.

[21] M. Neely, “Energy optimal control for time varying wireless networks,”IEEE Trans. Inf. Theory, vol. 52, no. 7, July 2006.

[22] M. J. Neely, E. Modiano, and C. P. Li, “Fairness and optimal stochasticcontrol for heterogeneous networks,” IEEE/ACM Trans. Netw., vol. 16,no. 2, April 2008.

[23] L. Tassiulas and A. Ephremides, “Stability properties of constrainedqueueing systems and scheduling policies for maximum throughputin multihop radio networks,” IEEE Trans. Autom. Control, vol. 37,December 1992.

[24] A. L. Stolyar, “Maximizing queueing network utility subject to stability:greedy primal-dual algorithm,” Queueing Systems, vol. 50, no. 4, 2005.

[25] S. Shenker, “Fundamental design issues for the future Internet,” jsac,vol. 13, no. 7, July 1995.

[26] CC2420, True single-chip 2.4 GHz IEEE 802.15.4/ZigBee RFtransceiver with MAC support, Chipcon Inc, http://www.chipcon.com.

[27] A. Sridharan, S. Moeller, and B. Krishnamachari, “Making distributedrate control using Lyapunov drift a reality in wireless sensor networks,”in IEEE WIOPT, 2008.

[28] U. Akyol, M. Andrews, P. Gupta, J. Hobby, I. Sanjee, and A. Stolyar,“Joint scheduling and congestion control in mobile ad-hoc networks,”in IEEE INFOCOM, 2008.

[29] S. Moeller, A. Sridharan, B. Krishnamachari, and O. Ganawali, “Routingwithout routes: Backpressure collection protocol,” in ACM/IEEE IPSN,2010.

Jiong Jin (S’10) received the B.E. degree in Com-puter Engineering from Nanyang Technological Uni-versity, Singapore, in 2006. He is currently workingtowards the Ph.D. degree in the Department of Elec-trical and Electronic Engineering, The University ofMelbourne, Australia. His research interests includecontrol and optimization of the network performancefor Internet, wireless ad-hoc and sensor networks,flow and congestion control, nonlinear system andsliding mode control theory.

Avinash Sridharan received his B.E. in Electronicsand Telecommunication Engineering at the ArmyInstitute of Technology, Pune, India, in 2000, andhis M.S. and Ph.D. degrees from University ofSouthern California in 2004 and 2009 respectively.He is currently a Software Engineer at the Er-icsson Silicon Valley development center in SanJose, California. His primary research interest is inthe implementation of practically viable congestioncontrol, and routing protocols for next-generationwired and wireless networks.

Bhaskar Krishnamachari (M’02) received his B.E.in Electrical Engineering at The Cooper Union, NewYork, in 1998, and his M.S. and Ph.D. degrees fromCornell University in 1999 and 2002 respectively.He is currently an Associate Professor and MingHsieh Faculty Fellow in the Department of ElectricalEngineering at the University of Southern Califor-nia. His primary research interest is in the designand analysis of algorithms and protocols for next-generation wireless networks.

Marimuthu Palaniswami (SM’95) received hisM.E. from the Indian Institute of science, India,M.Eng.Sc. from The University of Melbourne andPh.D from The University of Newcastle, Australia.He is currently a Professor in the Department ofElectrical and Electronic Engineering at The Uni-versity of Melbourne and leads one of the largestfunded ARC Research Network on Intelligent Sen-sors, Sensor Networks and Information Process-ing (ISSNIP). His research interests include SVMs,Sensors and Sensor Networks, Machine Learning,

Neural Network, Pattern Recognition, Signal Processing and Control.

Documents

IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 28, NO