symphony: synchronous two-phase rate and power control in...
TRANSCRIPT
Symphony: Synchronous Two-phase Rate and PowerControl in 802.11 WLANs
Kishore Ramachandran†, Ravi Kokku‡, Honghai Zhang‡, and Marco Gruteser††WINLAB, Rutgers University, North Brunswick, NJ, USA
‡NEC Laboratories America, Princeton, NJ, USA†{kishore, gruteser}@winlab.rutgers.edu, ‡{ravik, honghai}@nec-labs.com
AbstractAdaptive transmit power control in 802.11 Wireless LANs(WLANs) on a per-link basis helps increase network capac-ity and improves battery life of Wifi-enabled mobile devices.However, it faces the following challenges: (1) it can ex-acerbate receiver-side interference and asymmetric channelaccess, (2) it can incorrectly lead to lowering the data rateof a link, (3) mobility-induced channel variations at shorttimescales make detecting and avoiding these problems morecomplex. Despite significant research in rate and power con-trol, state of the art solutions lack comprehensive techniquesto address the above problems.
In this paper, we design and implement Symphony—a Syn-chronous Two-phase Rate and Power control system, whoseagility in adaptation enables us to systematically address thethree problems, while maximizing the benefits of power con-trol on a per-link basis. We implement Symphony in theLinux MadWifi driver, and show that it can be realized onhardware that supports transmit power control with no mod-ifications to the 802.11 MAC, thereby fostering immediatedeployability. Our extensive experimental evaluation on areal testbed in an office environment demonstrates that Sym-phony (1) enables up to 80% of the clients in 3 different cellsto settle at 50% to 94% lower transmit power than a per-cell power control solution, (2) increases network throughputby up to 50% across realistic deployment scenarios, (3) im-proves the throughput of asymmetry-affected links by 300%,and (4) opportunistically reduces the transmit power of mo-bile clients running VOIP calls by up to 97%, while causingminimum impact on voice quality.
Categories and Subject DescriptorsC.2.1 [Computer-Communication Networks]: NetworkArchitecture and Design—Wireless Communication
General TermsAlgorithms, Design, Performance, Experimentation
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MobiSys’08, June 17–20, 2008, Breckenridge, Colorado, USA.Copyright 2008 ACM 978-1-60558-139-2/08/06 ...$5.00.
KeywordsWLANs, Rate adaptation, Transmit power control, Batterylife, Mobility, Interference, Asymmetry, VOIP
1. INTRODUCTIONProjections that sales of mobile video phones and WiFi-
enabled smartphones will exceed $100 billion in 2010 suggestthat voice and data applications are fast converging fromportable onto mobile devices and that WiFi is increasinglybeing used for last-mile network access [3, 6]. In light ofthese two trends, WLANs face (1) higher user mobility, (2)more stringent energy budgets, and (3) higher node den-sities. While these requirements will likely be addressedthrough a combination of several mechanisms, we believethat an adaptive transmit power and rate control solutionwill be an integral component of the overall system. Adap-tive transmit power control can compensate for link changesdue to mobility, improve spatial reuse by increasing simul-taneous transmissions on multiple links, and reduce energyconsumption for frequently transmitting handheld devices((e.g., video call from smartphone)1.
Despite decades of power and rate control research, fewsystems exist that jointly adapt transmit power and ratefor WLANs on a per-link basis (partly due to the lack ofhardware support for fine-grained power control until re-cently [36, 48]). In particular, while rate control is per-formed on a per-link basis, current solutions either use staticor coarsely dynamic transmit power configurations on a per-AP or per-cell basis [2, 31]. These approaches forego per-linkpower control’s benefits in a mobile environment. Currentindustry wisdom even seems to view power control as in-compatible with VoIP applications [5], further discouragingits adoption. In general, adaptive transmit power control forWLANs faces the following challenges: (1) it can exacerbatereceiver-side interference (also known as the hidden-terminalproblem) and asymmetric channel access [31], thereby lead-ing to unnecessary packet retransmissions and reduced fair-ness; (2) it can incorrectly lead to lowering the data rateof a link, thereby increasing the air-time on the channel;(3) mobility-induced channel variations at short timescalesmake detecting and avoiding these problems more complex.
1For instance, Broadcom’s 802.11b/g interface consumesabout 625mW and 425mW when transmitting at 15dBmand 7dBm [1], and 295mW when receiving. Assuming thedevice transmits half of the active time and receives in therest half, this translates to an active-mode battery life in-crease of up to 27% when operating at 7dBm instead of15dBm.
While some of these problems have been identified previ-ously [23, 25, 31], to our knowledge, no integrated systemssolution exists that simultaneously addresses all three chal-lenges. Further, no per-link solution exists to address theasymmetric channel access problem in WLANs. The onlywork on WLAN asymmetry [31] is focused on a per-cell so-lution that cannot be easily extended to the per-link case,especially in the presence of user mobility, since it convergesvery slowly (30 seconds in one of their experiments).
In this paper, we propose Symphony—a novel synchronoustwo-phase rate and power control system that addresses allthe above challenges in a unified framework. The key ideais to use a periodic reference phase during which all nodesoperate at maximum power (as if no power control wereused) to detect whether power control leads to adverse ef-fects. Symphony is robust to user mobility, and can be easilyrealized on state-of-the-art hardware with no new modifi-cations to the 802.11 MAC protocols. We implement Sym-phony in the Linux MadWifi driver [30], and demonstrate itsefficacy through a detailed prototype evaluation. Extensiveexperiments on a real testbed in an office environment andon the indoor ORBIT testbed [42] demonstrate that Sym-phony (1) enables up to 80% of the clients in 3 different cellsin an office environment to settle at 50% to 94% (3 to 12 dB)lower transmit power than a per-cell power control solution,(2) opportunistically reduces the transmit power of mobileclients running VOIP calls by up to 97% (15 dB), while caus-ing minimum impact on R-score—a popular performancemetric for quantizing voice quality, (3) addresses the prob-lems of hidden terminals and asymmetric channel access,while improving the throughput of asymmetry-affected linksby 300%, and (4) across 4 realistic deployment scenarios, in-creases network throughput by up to 50%.
In summary, we make three contributions in this paper:
1. We propose Symphony, the first per-link rate and powercontrol system for WLANs that simultaneously ad-dresses the problems introduced by power control ina comprehensive and easily realizable manner. By im-plementing Symphony in the Linux MadWifi driver [30]running over off-the-shelf hardware, and requiring noextensions to 802.11 protocols, we demonstrate thatthe solution is readily deployable.
2. As part of Symphony, we propose a novel and sim-ple mechanism based on expected transmission time(ETT) to detect WLAN channel access asymmetry ina distributed manner. Unlike state-of-the-art per-linksolutions in the ad-hoc domain, this mechanism doesnot require information about the topology [44] or thesource of interference [47].
3. As part of Symphony, we propose RRAA+, an im-proved version of the state-of-the-art RRAA rate adap-tation algorithm [50], which significantly reduces packetloss and makes links more robust to user mobility.RRAA+ is also useful standalone.
The rest of the paper is organized as follows. In Sec-tion 2, we describe the challenges of performing adaptivetransmit power control, and discuss related work and theirdrawbacks. In Section 3, we discuss the design and imple-mentation of Symphony, and present evaluation results inSection 4. Section 5 discusses open issues and limitations.Section 6 concludes.
2. PROBLEM FORMULATIONAs users increasingly make WLANs the first choice for
last-mile network access, both spatial reuse and battery lifeare crucial metrics for better user experience. With emerg-ing mobile applications leading to increased data transferover Wifi interfaces, and hardware [7] and protocol [9] im-provements reducing the idle-time power consumption ofthese interfaces, transmit power becomes the dominatingfactor influencing battery lifetime. Secondly, with increas-ingly dense deployments of WLANs for continuous coverageto users, mitigating interference to maximize spatial reuse isa crucial design goal. Adaptive transmit power control on aper-link basis promises to improve both the above metrics.
2.1 Power Control ChallengesWhile per-link adaptive power control is beneficial, doing
so can be challenging due to several reasons.
Receiver-side Interference and Asymmetric Chan-nel Access: Transmit power control can introduce linkasymmetry that leads to two problems: Receiver-side in-terference and Asymmetric channel access. Several previousworks have already observed these two problems with powercontrol [23, 25, 31, 39]. To provide a more quantitativecharacterization of (1) their effect on performance in realis-tic settings and (2) their likelihood of occurrence, consider acanonical network of four nodes—two senders and two cor-responding receivers using the same 802.11 channel. Fig-ure 1(a) identifies the different scenarios of interaction whenthe two links use different transmit powers. Solid arrowsindicated that nodes are in communication range. Dottedarrows indicate that the senders are in carrier-sense range;in (b) S1 can hear S2, but not vice versa. Dashed arrows in-dicate unintended interference at the receivers. Scenario (a)represents fair channel sharing since S1 and S2 can carrier-sense each other. Scenario (b) represents the case of asym-metric channel access; whenever S2 has data to transmit, S1does not get a fair chance to transmit. Scenarios (c) and(d) are two instances of receiver-side interference; while thesenders are oblivious of each others’ presence, packets sentby them collide at their receivers. Finally, scenario (e) is theideal case of no interference and simultaneous transmissionson each link. Scenarios (b), (c) and (d) for any two links inthe network can degrade the link and network throughputand fairness.
Setup: We use four laptops (with Atheros PCMCIA wire-less cards) to emulate this canonical network—two laptopsare configured as APs while the remaining two are configuredas clients (one associated with each AP). Both AP-clientlinks are on the same channel (802.11a channel 40). Each APstarts backlogged UDP transfers to its corresponding clientand we fix the 802.11 MAC bit-rate to 54 Mbps. To emu-late receiver-side interference, APs (senders) are positionedsuch that they do not carrier sense each other, and clientsare placed such that their receptions may be corrupted byinterfering transmissions on the other link (scenarios (c) and(d)). We use packet delivery ratio (PDR), calculated as theratio of packets successfully received at each client to thosesent out by its corresponding AP, as the metric. For asym-metric channel access, we place both receivers such that thenetwork cannot be in scenarios (c) and (d). As the metric,we use the expected transmission time (ETT) [15, 11] ofpackets, with the minor modification that we only consider
S2S1S2S1
S2S2 S1 S2S1 S1
R1 R2(b)(a) (c)
(d) (e)
Link
1
Link
2
Link
1
Link
2
Link
1
Link
2
Link
1
Link
2
Link
1
Link
2
1
0.75
0.5
0.25
0 2 4 6 8 10 12 14 16 18
Deliv
ery
Ratio
Link-2 Power-Level (dBm)
Link-1 at 3dBmLink-1 at 12dBmLink-1 at 15dBm
Link-2 when Link1 at 15dBm
0
200
400
600
800
1000
1200
1400
1600
0 20 40 60 80 100 120
EW
MA
ET
T L
ink-
1 (
mic
rose
cs)
Time (seconds)
Links 1 & 2 @ 17dBmLink 1 @ 7dBm, 2 @ 17dBm
(a) (b) (c)
Figure 1: Problems introduced by power control: (a) Scenarios of interaction between two links (b) Receiver-side interference on Link-1, and (c) Asymmetric channel access on Link-1.
1
0.8
0.6
0.4
0.2
0 0 1 2 3 4 5 6
Pro
babi
lity
Relative distance between two APs
Scenario (a)Scenario (b)Scenario (c)Scenario (d)Scenario (e)
1
0.8
0.6
0.4
0.2
0 0 1 2 3 4 5 6
Pro
babi
lity
Relative distance between two APs
(i) All Scenarios (ii) Aggregate Bad Scenarios
Figure 2: (i) Probability of scenarios (a)-(e), (ii)Total probability of problematic scenarios (scenarios(b), (c) and (d)).
packets that succeed without any retries, to approximate thechannel access delay for each frame.
Results: Figure 1(b) shows the PDR observed by bothlinks, in the experiment emulating receiver-side interference,when the transmit power of each link is changed. In this fig-ure, the lines “Link-1 at 3dBm”, “Link-1 at 12dBm”, and“Link-1 at 15dBm” show that Link-1 is able to tolerate (dueto physical layer capture) varying degrees of interferencefrom Link-2 (Scenario (d)) depending on the relative dif-ference in transmit powers. Similarly, the line “Link-2 whenLink-1 at 15 dBm” shows that Link-2’s PDR is affected byreceiver-side interference at low transmit powers. In Fig-ure 1(c), we plot the smoothed (using EWMA) ETT of pack-ets on Link-1. When links are asymmetric (scenario (b)),Link-1 has higher channel access delay and hence higherETT than when both links are symmetric (scenario (a)).
We now address the question, how frequently do the prob-lematic scenarios ((b),(c) and (d)) occur? Since an experi-mental approach cannot sufficiently answer this question, wetake an analytical approach. We derive the probability thateach of the scenarios occur in a random geometrical graphwith four nodes as above when the senders employ transmitpower control. For brevity, we present the detailed mathe-matical formulation and analysis in a technical report [40],and just state the results here. Figure 2(i) shows the prob-ability of occurrence of each scenario with distance betweenthe senders, where the distance is shown as a factor of thecommunication range of the senders. Figure 2(ii) shows thesum of probabilities of all problematic scenarios. The graphclearly shows that these scenarios can occur very frequentlyin a real deployment. Detecting and avoiding these prob-lems in mobile environments is even more challenging sincethey can be dynamically introduced for short time periods.
SINR Range (dB) Rate SINR Range (dB) Rate
≥ 24.56 54 [10.79,17.04) 18[24.05,24.56) 48 [9.03,10.79) 12[18.8,24.05) 36 [7.78,9.03) 9[17.04,18.8) 24 [6.02,7.78) 6
Table 1: SINR vs. Rate (Mbps) for BERs ≤ 10−5.
Interaction with Rate Adaptation: In 802.11a/b/g wire-less LANs, senders use one of multiple transmission ratesfor sending packets. The choice of the rate is determined byan estimate of the channel conditions either through packetloss [24, 28, 30], delivery ratio [50], throughput [11], or Signalto Interference and Noise Ratio (SINR) estimates [27, 21].Conceptually, a link is expected to perform well at a chosenrate if the SINR at the receiver is above a threshold (Table1) [27]. Rate selection and transmit power control are tiedtogether; power control without considering rate can reducethe SINR, leading to reduction in rate and hence the linkand network throughput. In this paper, we take a systemperspective and choose a (minimum) power level for a linkthat does not compromise the achievable rate. From the ta-ble, it can be seen that for supporting 54Mbps, the transmitpower can be reduced until it reaches the SINR thresholdlimit of 24.56dB. Similarly, say, if 54Mbps and 48Mbps can-not be supported even at maximum allowed transmit power,then power can be reduced until the SINR approaches 19dB,which still allows operation at 36Mbps.
While such rate and power selection is easily realizablewith precise knowledge of receiver SINR [27], reliable SINRmeasurements and reports in the presence of mobility can-not be achieved at fine timescales due to their overhead.Consequently, we rely on estimating the channel conditionsbased on the delivery ratio of a window of packets, similar topast works [50]. Such an approach, however, makes rate andpower selection non-trivial. To illustrate, consider Figure 3.If the link is in a state of rate and power allocation (rj , pk)at a given instant, and the delivery ratio deteriorates (neg-ative feedback), the reaction can either be to reduce rate orincrease power. While increasing power appears to be a nat-ural choice (as in PARF [8]), it is possible that even at themaximum power, the current rate cannot be supported, inwhich case reducing rate is the right choice. Lack of knowl-edge of whether a rate can be supported by increasing powerto the maximum, can increase the convergence time, whichis prohibitive in the presence of mobility. A similar dilemmaexists for positive feedback.
Rat
e
Transmit Power
r(j−1),p(k)
r(j),p(k)r(j),p(k−1)
r(j+1),p(k)
r(j),p(k+1)+ve
+ve−ve
−ve
Figure 3: The rate and power adaptation dilemma.
0
10
20
30
40
50
60
0 3 6 9 12 15 18 21 24 27 30
RS
SI p
er s
econ
d (d
B)
Time (seconds)
Path 1 (LOS)Path 3 (NLOS)
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
1
0 1 2 3 4 5 6 7 8 9 10
CD
F
Diff. in Avg. RSSI per second (dB)
Path 1 (LOS)Path 2 (LOS)
Path 3 (NLOS)Path 4 (NLOS)
(a) (b)
Figure 4: Effect of mobility (at 0.75 m/s) on RSSI.
Mobility: Adaptive transmit power control becomes morechallenging in the presence of user mobility. Link conditionschange frequently due to distance-based path loss, short-lived hidden terminals and destructive multipath interfer-ence at certain locations in a user’s path.
To illustrate and quantify these effects, we conducted anexperiment with one moving client, at walking speed (ap-proximately 0.75 m/s), sending voice call traffic (50 packetsper second) to a stationary AP. The client moves away fromthe AP along four different paths in our office building, re-maining in line-of-sight (LOS) of the AP on two of the paths,and in non-line-of-sight (NLOS) on the others. Figure 4 (a)shows the average RSSI per second over time for one LOSand one NLOS case. In Figure 4 (b), we show the CDF ofthe difference in avg. RSSI per second. Although 95% of thetime, the avg. RSSI in one second changes by at most 5dB,we also observed changes up to 15db within two seconds.
In such environments, both rate and power control algo-rithms need to address the following questions effectively:How frequently should the adaptation take place? and Atwhat granularity should rate and power be adapted? Forthe first question, solutions have to strike the right balancebetween reliability and responsiveness: waiting for enoughsamples avoids reacting to short-lived drops in link condi-tions, while waiting too long can also be detrimental to per-formance. For the second question, changing power at coarsegranularity allows adapting less frequently, but compromiseson battery life and spatial reuse; whereas fine granularitychanges require frequent adaptation.
2.2 Existing Solutions and DrawbacksTransmit power control and rate adaptation are well re-
searched topics in wireless networks. However, our studyreveals that no solution provides a comprehensive and eas-ily realizable approach to simultaneously address the chal-lenges discussed in the previous section. In particular, oursurvey across the fields of WLANs, Adhoc, Cellular and Sen-sor networks research, reveals that (i) there are no existingper-link solutions to address the asymmetric channel accessproblem in WLANs, and (ii) although approaches exist thataddress a subset of the challenges, Symphony is the first sys-tem to simultaneously address the complete set and pro-
vide a solution for mobility-enabled WLANs. Table 2 pro-vides a taxonomy of the relevant related work and identifiestheir drawbacks. Solutions having deployability constraintsdue to significant protocol modifications or impractical as-sumptions such as the requirement of precise interferencemeasurements, are marked by × under ‘Deployability’. So-lutions not realized in practice and hence not addressingsystem-level challenges are marked by × under ‘Realization’.Remaining columns provide information on the granularityof each solution, its objective (reduced energy consumptionor increased capacity or both), and whether it addressesreceiver-side interference, asymmetric channel access, andjointly adapting rate.
Several per-link solutions in the adhoc domain addresschannel access asymmetry (Table 2). However, the solu-tions are not applicable in the WLAN domain because oftheir assumption that any node is allowed to communicatewith any other node in range; whereas in WLANs, clientscan only communicate with the associated AP, and viceversa. Further, these solutions require knowledge about thesource of interference, which is impractical to identify at finetimescales in WLANs with mobility (hence marked by × un-der ‘Realization’). Among per-cell [31] and per-network [35]solutions, COMPOW [35] addresses the asymmetric channelaccess problem by making every node in an ad-hoc networktransmit at a common optimum power. In WLANs, Mhatreet. al. [31] propose maintaining symmetry by jointly tun-ing the CCA threshold and transmit powers to maximizenetwork-wide throughput for a given placement of APs andclients. However, these solutions do not lend themselves wellto be extended for the per-link case for two reasons: (a) theytake a long time to converge after a topology change (e.g.,Mhatre et. al’s [31] solution takes 30 seconds in one of theirexperiments), which is unacceptable in the presence of usermobility, and (b) they operate many links in the network ata significantly higher transmit power than necessary since, ineither case, the weakest link determines the transmit power.In general, we note that per-cell approaches have to neces-sarily degenerate into per-link approaches to efficiently dealwith mobility. Finally, we identify the lack of a solution forthis problem in approaches proposed for other domains suchas sensor networks ([49, 20, 29, 22]) or CDMA cellular net-works ([17, 51, 13, 18]) mainly because they rely on differentmultiple access techniques.
With regards to joint rate and power adaptation for WLANs,till date, we are aware of techniques that address only a sub-set of the problems, and have mostly been implemented insimulators [38, 12, 8]. In contrast, Symphony is the first ef-fort to implement a complete system. The use of transmitpower to mitigate the hidden terminal problem is also novelas compared to the use of RTS/CTS messages.
We acknowledge that the related work discussed here isby no means complete and refer the reader to our surveyin [40] for more details.
3. DESIGN AND IMPLEMENTATIONThis section describes the design and implementation of
Symphony, a synchronous two-phase rate and power controlframework to increase battery life of mobile devices and im-prove spatial reuse, while addressing several challenges withadaptive transmit power control.
Domain Solution Granularity Realization Deployability Objective Rate Channel Access HiddenEnergy Capacity Adaptation Asymm. Nodes
[Sheth02] [45, 46] Per-link√ √ √ √ √
× ×MiSer [38] Per-link ×
√ √×
√×
√
WLANs PARF, PERF [8] Per-link√ √
×√ √
× ×[Chevillat05] [12] Per-link ×
√ √ √ √× ×
[Mhatre07] [31] Per-cell√ √
×√
×√
×PCMA [32] Per-link × × ×
√× ×
√
Adhoc BASIC, PCM [23] Per-link ×√ √
× × ×√
Networks PCDC [33] Per-link × ×√ √
× ×√
POWMAC [34] Per-link × ×√ √
× ×√
SHUSH [47] Per-link × ×√ √
×√ √
PRC [27] Per-link × ×√ √ √
× ×TACP [44] Per-link × ×
√ √×
√ √
COMPOW [35] Per-network√ √
×√
×√ √
Table 2: Taxonomy of existing transmit power control algorithms.
REFERENCE PHASEref_ctxt: ERateRURTSRETTRalgo. related vars
Algorithm:
rate_adapt( )
OPERATIONAL PHASEopt-ctxt: ERateOURTSOETTOalgo. related vars
Algorithm:
rate_adapt( )power_adapt( )
X1 ms passed
X2 ms passed
INIT PHASE
Algorithm:init_pwr_discover( )
START
Y ms passedwithout samples
INIT succeeded
Figure 5: Two-phase synchronous strategy.
3.1 OverviewDue to the possible adverse effects of power control, the
goal of Symphony is to control the transmit power and rateof each link in a WLAN such that the link’s performance isat least as good as in the baseline maximum-power network.At the core of Symphony is a synchronous two-phase execu-tion (Figure 5) strategy, in which all nodes (APs and clients)in the WLAN cycle through two phases in synchrony—theREFERENCE (REF) phase and the OPERATIONAL (OPT)phase. In the REF phase, Symphony estimates for each linkthe best achievable performance, and in the OPT phase,it tunes the link to the lowest transmit power to achievethe same performance as in the REF phase. Due to mo-bility (of users or the environment) the best attainable per-formance may continuously change, and a power/rate set-ting may suddenly be affected by asymmetry. The referencephase provides a convenient solution to periodically verifythat power and rate control have not unnecessarily degradedsystem performance.
Similar to most rate control algorithms, Symphony exe-cutes on each unidirectional (sender, receiver) link at thesender side. The sender can be either an AP or a client,and the receiver a client or an AP. In the REF phase, eachsender performs rate adaptation for each link at the maxi-mum power to choose the best data rate for the current chan-nel conditions. In the OPT phase, the sender performs bothrate and power adaptation. The rate and power adaptationalgorithms maintain two contexts—ref ctxt and opt ctxt, onefor each phase for each link. Each context contains severalperformance metrics and other variables needed for execut-ing the rate and power adaptation algorithms. We choose
ETTEstimation
Basic rate adaptation and adaptive RTS mechanism
R O R O R OURTSERate ETT
Power adaptationSET
RTS on/offratetxpower
Symphony
Network layer
Interface card
Rec
eive
pat
h
Tra
nsm
it pa
th
pktsSnd
pktsRcv
tx_pkt() tx_pkt_complete()
Device driver
Figure 6: Architecture of Symphony. The blocks Rand O represent REF and OPT contexts.
three metrics—EWMA (Exponential Weighted Moving Av-erage) of data rate, utility of RTS and EWMA of ETT—tohelp detect and avoid the problems outlined in Section 2.The performance metrics in the ref ctxt serve as referencevalues for the OPT phase. In the OPT phase, each link istuned to the lowest power such that each performance met-ric in the opt ctxt is no worse than the corresponding metricin the REF phase by more than a threshold.
Before entering the REF-OPT cycle, each link goes throughan INIT phase, in which the sender starts from the minimumpower level and rapidly discovers the initial power level nec-essary for communication with the receiver. To avoid affect-ing applications, we use probe packets at the highest rateand additively increase power for each packet till a probepacket succeeds in reaching the receiver. If we reach themaximum power and still do not succeed, we lower the rateand start over at the lowest power. After succeeding, thesender initializes the OPT phase with the successful powerlevel, and enters the REF phase with the successful rateat the appropriate synchronized time. If the sender is idlefor a threshold number of seconds (=2 in our prototype),and then a packet from the network layer arrives that doesnot succeed in reaching the receiver, we determine that therate and power information is stale (e.g., due to mobility)and reset the sender to the INIT phase to repeat the rapiddiscovery process.
We achieve synchronized phase execution on all APs andclients in two steps. First, the APs are synchronized to a
Algorithm 1 RRAA
1: if (loss > HTk) then2: k ← next lower rate3: else if (loss < LTk) then4: k ← next higher rate5: end if
global real-time clock by a central controller2. The con-troller configures the lengths of the two phases on each AP,and specifies at what point in time the phases should startexecuting. Second, for each phase change, each AP broad-casts a message (at maximum power) informing the changeto the clients, and the clients switch phase. These broadcastmessages are sent at high priority to ensure minimum skewacross nodes; in our prototype, we use the hardware queuereserved for voice traffic in the Atheros cards.
We implement Symphony in the MadWifi driver 0.9.3.1 [30].Figure 6 shows the architecture of Symphony. As shown,Symphony executes in the transmit path. We represent rateadaptation as a separate block to make Symphony extensible.Any rate adaptation algorithm can fit into Symphony as longas it executes in the two contexts and provides rate informa-tion for power adaptation. Similarly, different mechanismscan be implemented for ETT estimation and determinationof RTS utility. In what follows, we describe the importantcomponents of Symphony.
3.2 Rate AdaptationRate adaptation involves choosing one of several trans-
mission bitrates supported by 802.11a/b/g standards basedon the channel conditions. In our context, a rate adaptationalgorithm should satisfy at least three requirements: (1) itshould be agile to user mobility in typical WLAN environ-ments, (2) it should converge to an appropriate rate for eachlink rapidly to help with power adaptation, and (3) it shouldnot drop rate due to receiver-side interference, and insteadaid the power adaptation algorithm to correct it.
Rate adaptation is a well researched topic in 802.11 wire-less networks [11, 19, 21, 24, 28, 30, 37, 50]. Wong et.al. [50] and Ramachandran et al. [41] provide a survey ofseveral rate adaptation algorithms. In this paper, we focuson two state-of-the-art algorithms that we analyze in detailfor our purpose: SampleRate [11] and RRAA [50].SampleRate: The SampleRate [11] algorithm selects atransmission rate that minimizes the mean packet transmis-sion time. The algorithm maintains an EWMA of expectedpacket transmission time (ETT) for each rate. For each suc-cessfully sent packet, the ETT is updated based on the num-ber of retransmissions, packet length and protocol timingoverheads. The algorithm periodically attempts transmis-sion at other data rates and if these sample transmissionsindicate lower mean transmission time at other rates, thealgorithm switches the rate.RRAA: This algorithm [50] uses short-term loss estima-tion of 802.11 frames (in a window of tens of frames) toopportunistically guide rate adaptation. The basic RRAAalgorithm works with high and low thresholds HTk and LTk
on loss rate at the current data rate k selected; Algorithm 1depicts its behavior. Further, it uses selective RTS/CTS for
2The controller and thin-AP architecture is the most com-mon way WLANs are built today.
Algorithm 2 RRAA+
1: if (loss > HTk) then2: p[k] /= α1
3: k ← next lower rate4: else if (loss < LTk) then5: for (all rates j ≤ k) do6: p[j] *= α2
7: end for8: if (rand() < p[next higher k]) then9: k ← next higher rate
10: end if11: end if
avoiding unnecessary rate adaptation in response to collision-induced losses (i.e. receiver-side interference). Briefly, selec-tive RTS/CTS works as follows: on detecting loss of frames3,RRAA enables RTS/CTS on a selective number of frames.If RTS/CTS reduces the frame loss data rate is not reduced,instead RTS/CTS is increasingly enabled on greater numberof frames. Otherwise, RRAA determines that losses are notbecause of receiver side interference, and reduces rate whiledisabling RTS/CTS. Note that while turning on RTS/CTSon all frames avoids receiver side interference completely, italso reduces the link and network throughput due to proto-col overhead and hence, is not generally enabled in practice.
Basing rate adaptation on loss estimation over a windowof packets helps a transmitter to not react adversely to oneor a few packet losses, which are more common with mobil-ity and power control. The second feature of not reducingrate in response to collision-induced losses is a useful fea-ture [26, 50], and is missing in SampleRate. One drawbackof RRAA, however, is that it does not converge to a par-ticular rate, if the next higher rate is inappropriate. Forinstance, if the 54Mbps rate causes frame loss higher thanthe high threshold, and 48Mbps causes frame loss lower thanthe low threshold, RRAA flips between 54 and 48Mbps; ide-ally the algorithm should converge to 48Mbps.RRAA+: To make RRAA converge, we propose a fix tothe algorithm as shown in Algorithm 2, and call the new al-gorithm RRAA+. In brief, RRAA+ maintains for each datarate, the probability that it transitions to this rate from thenext lower rate. Every time the loss at a rate exceeds thehigh threshold, the probability of returning to this rate isreduced before transitioning to the next lower rate. Also,every time the loss is lower than LTk, the probability of thecurrent data rate and the rates below is increased, assumingthat all rates below the current rate can also be supportedwith the current channel conditions. Notice that the proba-bility is only used on positive feedback (when the loss is lessthan LTk) for transitioning to a higher rate; transitions onnegative feedback are deterministic. The MIMD (multiplica-tive increase, multiplicative decrease) parameters α1 and α2are chosen such that the algorithm becomes stable. In ourprototype, α1 = 2 and α2 = 1.0905; it takes 8 incrementsto match one decrement.
To compare the performance of the algorithms, we imple-mented RRAA and RRAA+ in the Linux MadWifi driver.An implementation of SampleRate exists already in the Mad-
3Frame is at the MAC level, whereas packet is at the driverlevel. Each packet can lead to multiple frame exchanges dueto retransmissions.
100
80
60
40
20
0
0 10 20 30 40 50 60
MA
C lo
ss r
ate
(%)
Time (seconds)
RRAARRAA+ 54
48
36
24 18 12
6
0 10 20 30 40 50 60
802.
11 B
it-ra
te (
Mbp
s)
Time (seconds)
RRAARRAA+
54 36
12
0 10 20 30 40 50 60 70
Time (seconds)
RRAARRAA+
54 36
12
0 10 20 30 40 50 60 70
Time (seconds)
802.
11 B
it-ra
te (
Mbp
s)
SampleRRAA+
(a) Loss rate comparison (b) Bit-rate for static client (c) Bit-rate for mobile client
Figure 7: Efficacy of RRAA+ over RRAA.
Wifi package. In our implementation, RRAA and RRAA+is invoked every 200ms or after 40 packets4 have been re-ceived (defined as an interval), and the algorithms use lossrate estimated in the last interval for rate adaptation. Wedefine the interval as above in order to be agile to user mobil-ity, and at the same time receive enough packets to reliablyestimate channel conditions. In particular, VOIP calls gen-erate 10 packets in the 200ms interval, which is a reasonablenumber of samples. We now perform two experiments todemonstrate the benefit of RRAA+ over RRAA and Sam-pleRate.Experiment 1: We consider one sender and one receiver(two laptops with Atheros PCMCIA cards), with the re-ceiver kept in non-line-of-sight with the sender at a distanceof 15 meters. We emulate a VOIP call between the nodes us-ing the DITG traffic generator [10] that generates 50 packetsper second with 20 byte payload, emulating a G.729.2 codec.We repeat the experiment with RRAA and RRAA+. Fig-ure 7(a) and (b) show the 802.11 frame loss and the datarate chosen by RRAA and RRAA+. The graphs show thatRRAA incurs greater frame loss and hence increased num-ber of retries because of not “learning” that 54Mbps rate isnot appropriate for the link. In contrast, RRAA+ learnsto avoid 54 Mbps. Note that increased frame loss leads toreduced overall network throughput.Experiment 2: We again consider one sender and one re-ceiver, but we make the receiver mobile (by placing the lap-top in a chair and dragging the chair). We setup the voicecall as above again. The receiver starts at a distance of 40meters and in line-of-sight with the sender, and moves to-wards the sender to within a meter. The receiver is initiallystationary and starts moving 15 seconds after the start of theexperiment. We repeat this experiment for RRAA, RRAA+and SampleRate. In Figure 7(c), we observe that SampleR-ate takes longer to converge than both RRAA and RRAA+while RRAA has the same oscillatory behavior as in Fig-ure 7(b). Such conservative rate selection by SampleRateleads to inefficient channel usage and reduces overall net-work throughput. Further, as shown in [50], SampleRatecan incorrectly lower the bit rate in response to collisioninduced losses.
In summary, we choose RRAA+ over others for rate adap-tation in Symphony due to its three features—agility, conver-gence to appropriate rate and avoidance of rate adaptationbecause of collision-induced packet losses.
4Wong et. al [50] observe that 10-40 samples is a goodenough number to reliably estimate the channel conditions.
3.3 Power AdaptationOur goal for power adaptation is to tune each (sender, re-
ceiver) link in a WLAN to the lowest transmit power suchthat the performance metrics in the OPT phase are no worsethan the corresponding metrics in the REF phase. Algo-rithm 3 shows the basic behavior of power adaptation inSymphony. The three conditions in line 1 detect undesir-able rate adaptation, receiver side interference and asym-metric channel access introduced by power control. Similarto RRAA+, the power control algorithm learns the lowestappropriate power level by maintaining the probability withwhich it should transition to a particular level. The algo-rithm executes once for every two intervals of the rate adap-tation algorithm to adapt to user mobility. Further, severalrate adaptation intervals can occur in each of the REF andOPT phases, depending on traffic.
Preventing undesirable rate adaptation: For detect-ing and preventing undesirable rate adaptation due to powercontrol, for each link, the two contexts maintain an EWMAof the rate chosen by the rate control algorithm in responseto the measured packet loss: for each ratei chosen in inter-val i, we set ERate = ERate ∗ ψ + ratei ∗ (1 − ψ) at theend of interval i. Everytime the power control algorithm istriggered, if the EWMA of rate in OPT phase (ERateO) islower than that in the REF phase (ERateR) by a thresholdτ1, transmit power is increased. In our implementation, theEWMA parameter ψ is chosen as 0.8. We choose τ1 to be3 Mbps if ERateR is above 48Mbps or below 24 Mbps, and6 Mbps otherwise. We make this choice because of the non-uniformity in 802.11 a/g bit rate granularity. Our idea is toplace the threshold between the two consecutive rates.
Preventing receiver side interference: To detect thatpower control introduces receiver side interference we usethe adaptive RTS/CTS mechanism. Similar to RRAA [50],RRAA+ includes a mechanism to detect if packet losses arehappening due to collisions as opposed to degraded channelconditions. Our implementation of the adaptive RTS/CTSmechanism, however, differs significantly from RRAA; whileRRAA was implemented on a per-frame basis (because ofthe availability of card firmware), we implement it on thebasis of a window of packets, both for more reliable estima-tion of receiver side interference, and for obviating the needof modifying the firmware.
Using this mechanism, we maintain a performance metric—the utility of RTS (URTS)—that is set to one if the lossrate with RTS/CTS is less than the total loss rate in at
Algorithm 3 power control
1: if ((ERateR − ERateO > τ1) OR(URTSO > URTSR) OR(ETTO − ETTR > τ2)) then
2: p[curpwr] /= β1
3: curpwr ← next higher pwr4: else5: for (all pwr levels i ≥ curpwr) do6: p[i] *= β2
7: end for8: if (rand() < p[next lower pwr]) then9: curpwr ← next lower pwr
10: end if11: end if
Algorithm 4 ETT Estimation
1: VARIABLES mark seqno, itime, etime2:3: FUNCTION driver send pkt (seqno)4: if (mark seqno not set) then5: mark seqno = seqno6: etime = curtime7: end if8:9: FUNCTION card sent pkt (seqno)
10: if (mark seqno = seqno) then11: ETT = curtime - MAX (itime, etime)12: itime = curtime13: unset mark seqno14: else15: ETT = curtime - itime16: itime = curtime17: end if
least 2 out of 4 last rate adaptation intervals, i.e. enablingRTS/CTS is helpful to reduce losses. Otherwise, URTS isset to zero. The rationale for waiting for 4 intervals is todetermine the utility with greater reliability, while tradingoff responsiveness; further, unless the receiver interferenceproblem is sustained, we do not increase transmit powerand let adaptive RTS address the problem. Now, if URTSis 0 in the REF phase and 1 in the OPT phase, it indicatesthat power control introduced the receiver side interferencethat didn’t exist in the REF phase. Line 1 in Algorithm 3captures this condition and triggers a power increase.
Preventing asymmetric channel access: To detect thatpower control introduces asymmetric channel access, we mea-sure the EWMA of the expected transmission time (ETT)of each packet. The key idea here is that if a sender does notget a chance to transmit as frequently as in REF phase dueto asymmetry in the OPT phase, the ETT in the OPT phaseincreases compared to the REF phase. If the ETT increasesby more than a threshold τ2, we trigger power increase (asin Algorithm 3). In our implementation, τ2 = 100µs.
If the interface card provides to the device driver the trans-mission time for each packet, EWMA of ETT can be easilycalculated. However, Atheros cards currently do not providethis information. Further, multiple packets can be queuedby the driver in the buffer of the card for efficiency, whichmakes ETT estimation non-trivial. In our implementation,we overcome the above problem with the two functions in
Algorithm 4 that exploit the interaction between the devicedriver and the interface card. We use the unique sequencenumbers in packets that are sent to the card, and keep oneoutstanding marked packet. We estimate when the packettransmission started using two variables: etime that repre-sents the time a marked packet was sent to the card, anditime that represents the implicit time when the previouspacket transmission was completed. Note that we configurethe card to provide per-packet transmission status feedbackusing sysctl -w dev.wifi0.txintrperiod=1. This method en-sures that ETT can be estimated even on packets that arebuffered back-to-back and hence are not explicitly marked.Further, we only consider packets that do not incur any re-transmissions to reliably estimate the channel access delay,and consider packets sent at the same rate as in REF phaseto avoid false positives due to rate-based ETT changes.
Finally, since packet sizes affect the ETT because of thevaried transmission time on the air, we maintain ETT interms of 1500 byte packets. For smaller packets, the ETT isscaled to 1500 bytes before using it to calculate EWMA. Todo so, we set for each packet fixedETT = ETT + (1500−pkt size)/rate, where rate is the data rate used to transmitthe packet. We validate experimentally that this approachof scaling ETT is reasonably accurate [40].
Granularity of power control: Learning from our ob-servations in Figure 4, and given that power adaptationgets triggered at least twice in a second, in our implementa-tion, Symphony increases and decreases power at a granular-ity of 3dB, between [MIN PLEVEL, MAX PLEVEL]. Thisensures agility to typical user mobility in WLANs. Fur-ther, [48] observes that transmit power control at a finer-granularity than 3dB may not always be useful in indoorenvironments. The minimum and maximum transmit powervalues can be different on different 802.11 cards, vary withthe frequencies used (such as in the 5GHz band) and alsovary based on the gains of the external antennas connectedto the cards. However, we assume that the levels are dis-crete at a granularity of 3dB. In our prototype with Atheroscards, we vary the power levels between 0 and 18 dBm.
The process of increasing and decreasing power is simi-lar to rate adaptation in RRAA+. Symphony maintains foreach power level, the probability that it transitions to thislevel from the next higher level. Every time at least oneof the conditions on the performance metrics satisfies, theprobability of returning to this power level is reduced beforetransitioning to the next higher power. The MIMD param-eters β1 and β2 are chosen to make the algorithm stable. Inour prototype, β1 = 3 and β2 = 1.14; it takes 8 incrementsto match one decrement. Again, the choice of β1 and β2
strikes a tradeoff between the benefits of power control andstability of the algorithm; we arrive at the above values afterexperimenting with several scenarios.
With Symphony’s approach of maintaining probability perpower level, the transmit power of each sender will eventu-ally converge to a point where the performance of each linkis at least as good as in the REF phase. If the performanceof a link at a given power level is similar to or better thanthat of the REF phase the probability of returning to thatpower level and to any higher power level will converge to1 due to the multiplicative increase of the probability. Oth-erwise, the probability of returning to that power level willconverge to a small value due to the multiplicative decrease.
(a) Static nodes (b) Problematic scenarios (c) Mobile clients
Figure 8: Experimental setup.
In our implementation, we bound the probability on thelower side to 1
64to be responsive to changing channel con-
ditions and mobility.
4. EVALUATIONTo demonstrate the achievement of the design goals out-
lined earlier, in this section, we carry out a systematic andextensive set of experiments, in both controlled and uncon-trolled environments. In what follows, we describe the ex-perimental setups and then present our results.
4.1 SetupFigure 8 shows our setups for the different experiments.
We broadly classify the setups into four categories: (1) staticnodes (Figure 8(a)) in which clients are randomly placed indifferent cubicles and office rooms (represented by lower caseletters), and APs are placed close to the operational WLANAPs, (2) problematic scenarios (Figure 8(b)) in which wecarefully choose client and AP locations so as to emulatechannel access asymmetry and receiver-side interference, (3)mobile clients (Figure 8(c)) in which APs are placed close tooperational WLAN APs (the AP is at location T1 for pathsp1,p2 and p3, at T2 for path p6, and at T3 for paths p4and p5), and clients associated with one of the APs moveon different paths in the office building, and (4) the indoorORBIT testbed [42]. For the setup involving client mobil-ity, the rationale behind choosing the different paths is toapproximate a reasonable mix of mobility patterns (movingtowards/away from an AP), and channel conditions (LOSor NLOS) that occur in real-world situations.
In the first three setups, Symphony APs and clients areDell laptops, while the ORBIT testbed uses custom-made,small form-factor PCs. All setups use Atheros cards (PCM-CIA or mini-PCI), which transmit at a default (maximum)power level of 18dBm5 for 54Mbps data rate, and allow Sym-phony to change transmit power at the desired granularityof 3 dB. The APs are connected by a 100Mbps wired net-work and all nodes use the same 802.11 channel. While bothclients and APs can execute Symphony, we perform most ofour experiments with APs as senders and clients as receivers.This is because of the current limitation of Atheros cardsthat do not implement per-packet power control for ACKand CTS packets. To overcome this limitation for properevaluation, unless specified otherwise, we run Symphony on
5While the specifications mention maximum transmit powerof 15±2dBm, we observe that the card can use up to 18dBm.
0 0.2 0.4 0.6 0.8
1
0 1000 2000 3000 4000 5000
CD
F
Phase switch skew (microsec)
AP1-AP2AP1-CLIENT
Figure 9: Skew between phases on two APs and anAP and its client (observed by an external monitor).
APs, and disable per-packet transmit power control on theclients. Instead, APs append transmit power information toeach outgoing frame, and a slightly modified client driver ex-tracts this information and sets the card to this power level(similar to how iwconfig athN txpower $val sets power). Thisensures that all frames, including ACKs are returned at theconfigured power. Finally, except for the experiments thatfocus on interactions with Symphony-non-compliant nodes(e.g. legacy WLANs), all experiments are conducted on802.11a channels to avoid interference from/to our office’sWLAN that uses all three 802.11g channels (1,6,11).
For AP synchronization and configuration, instead of us-ing a different central controller, we just use one AP asthe master AP, and synchronize the others with the mas-ter through NTP on the wired network. Further, for all theexperiments in this section, we use 200ms and 800ms as thelength of REF and OPT phase resp., and all APs are con-figured to start the REF phase at the beginning of each onesecond boundary. The choice of phase lengths is a tradeoffthat ensures collecting reliable estimates in the REF phase,while not compromising too much on energy savings [40].
Two-phase Synchronization: To test that Symphony in-deed executes synchronously on APs and clients, we firstperform a micro-benchmark in which we consider a networkof two APs with one client each. In this experiment, bothclients and APs run Symphony. We place a laptop withits wireless card in monitor mode, close to the APs. Westart two UDP transfers of 200 pkts/sec between each (AP,client) pair and collect packets on the monitor. The packetsare appended with the transmit power used to send themand the executing phase (REF/OPT). Figure 9 plots theCDF of skew between two APs and one AP and its client asseen by the monitor. The graph shows that the nodes makecorresponding phase transitions within 5 ms of each other.
18 15 12 9 6 3 0
fezdhknpmgjqacby
54 48
36
24 18 12T
x. P
ower
(dB
m)
802.
11a
Bitr
ate
(Mbp
s)
Location
Power (Symphony)Rate (MAX)
Rate (Symphony)
Figure 10: Transmit power reduction for clients inseveral representative office locations.
90 80 70 60 50 40 30 20 10 0
s1s2s3s1s3s2s3s1s2
UD
P th
roug
hput
(M
bps) MAX
Symphony 1 0.8 0.6 0.4 0.2
0
18 15 12 9 6 3 0
CD
F
Tx. Power (dBm)
ORBIT (5 APs, 28 clients)Real testbed (3 APs, 6 clients)
(a) (b)
Figure 11: Experiments demonstrating (a) In-creased spatial reuse. (b) significant power reduc-tion even in a dense setup.
4.2 ResultsWe now describe our results from several experiments on
the above setups to demonstrate Symphony’s efficacy.
4.2.1 Static Experiments
Transmit Power Reduction: To get a measure of achiev-able transmit power reduction in near-typical indoor officeenvironments, we consider all nodes in Figure 8(a). We setupten 1 minute VOIP calls for each client. From the associatedAPs, the calls start at different times (separated by 5 min-utes) for each client. The white bars in Figure 10 show theaverage transmit power used by the Symphony APs for eachclient; in most typical user locations, the required transmitpower can be substantially lower than the default 18dBm.Further, the error bars plot the minimum and maximum ofthe average transmit power per call, showing that the op-timal power for maintaining a link’s performance can varywith time for even static locations. The other two bars showthe rate chosen by Symphony and the rate when transmit-ting at maximum power. Symphony causes minimum effecton the data rate chosen. In this setup, for the three cells withS1, S3 and S4 as APs, a per-cell solution would operate alllinks at the worst client’s transmit power, which is about 12dBm. In contrast, Symphony enables 75-80% of the clientsin the cells to settle at 3 to 12 dB (i.e. 50% to 94%) lowertransmit power than 12 dBm.
Spatial Reuse: Several studies demonstrate that transmitpower control leads to increased spatial reuse [36, 27]. Theseworks show simulation results over large topologies that cannot be easily realized in a prototype testbed. Here, we per-form a small-scale spatial reuse experiment, where we con-sider links (S1, z), (S2, x), and (S3, y) as in Figure 8(a) andmake a subset of them operate simultaneously. We considertwo cases: when the links operate at maximum power andwhen they operate with Symphony. Figure 11(a) shows theaggregate throughput of the links, and clearly demonstrates30-50% increased throughput for different combinations.
35
30
25
20
15
10
5
0
18
15
12
9
6
3
0
UD
P th
roug
hput
(M
bps)
Tx.
Pow
er (
dBm
)
Single link Asymmetry Symphony
Throughput (link y)Throughput (link x)
Tx. Power (link y)
30
25
20
15
10
5
0
18
15
12
9
6
3
0
UD
P th
roug
hput
(M
bps)
Tx.
Pow
er (
dBm
)
MAX Symphony
Throughput (link z)Throughput (link x)
Tx. Power (link z)Tx. Power (link x)
(a) (b)
Figure 12: Preventing asymmetric channel access.(a) Symphony’s ability to detect and avoid channelaccess asymmetry, (b) power control removes inher-ent link asymmetry.
Large-scale experiments: To assess the effect of highnode density on Symphony, we emulate dense deploymentson the indoor ORBIT testbed [42] with 5 APs and 28 clients,and on our office testbed with 3 APs and 6 clients (placedclose to s4 in Figure 8(a)). The inter-AP distance is 5 meterson ORBIT and 15m in our office testbed. Clients are within15 meters of each AP in both cases. We setup bi-directionaltraffic between each client and its associated AP, and enableSymphony on all nodes. Figure 11(b) shows the CDF of theaverage transmit powers used by clients in each second, overa period of 60 seconds. We observe that Symphony enablesclients to settle at much lower power levels in both sets of ex-periments. For instance, in the ORBIT experiment, clientssettle at transmit power of 0dBm over 60% of the time andwithin 9dBm over 80% of the time.
4.2.2 Problematic Scenarios
Avoiding Channel Access Asymmetry: To demonstratethat Symphony avoids channel access asymmetry by intelli-gently adapting the transmit power of a link, we perform twosets of experiments. In the first set, we consider links x and yas in Figure 8(b) (where AS1 and AS2 are senders and AR1and AR2 are receivers), and setup backlogged UDP trafficto measure the link throughput. Link x always operates atthe maximum power. We consider several cases—(i) links xand y running one-at-a-time with y running Symphony, (ii)links x and y running simultaneously with y at a fixed 0dBm, and (iii) links x and y running simultaneously with yrunning Symphony. Figure 12(a) shows the results over tenruns. In case (i) Symphony enables link y to operate at 0dBm and still achieve full throughput. If link y is operatedat 0 dBm together with link x, however, the throughput oflink y drops significantly compared to x, as shown in case(ii) due to asymmetric channel access. We validate this byobserving the difference in ETTs observed by links x and y.In case (iii), we show that Symphony increases the transmitpower of link y to between 6 and 9 dBm to avoid asymmetry.Observe that link y didn’t have to operate at the maximumpower to let link x perceive its transmission.
In the second set, we show that when there is inherentasymmetry between two links at default power, power con-trol is beneficial in removing it and increasing the through-put and fairness of links. As in Figure 8(b), a sender atlocation AS3 gets significantly affected when running in con-junction with a sender at AS1. For this experiment, we uselinks x and z and consider two cases: (i) both x and z run-ning together at maximum power, and (ii) x and z runningtogether with Symphony. Figure 12(b) shows results aver-
1
0
0 20 40 60 80 100 120 140
Rat
e tr
igge
r
Time (seconds)
Rate < Thresh
1
0
0 20 40 60 80 100 120 140
RT
S tr
igge
r
Time (seconds)
URTS < Thresh
181260
0 20 40 60 80 100 120 140Tx.
Pow
er (
dBm
)
Time (seconds)
Tx. Power
1
0
0 20 40 60 80 100 120 140
Rat
e tr
igge
r
Time (seconds)
Rate < Thresh
1
0
0 20 40 60 80 100 120 140
RT
S tr
igge
r
Time (seconds)
URTS < Thresh
181260
0 20 40 60 80 100 120 140Tx.
Pow
er (
dBm
)
Time (seconds)
Tx. Power
1
0
0 20 40 60 80 100 120 140
Rat
e tr
igge
r
Time (seconds)
Rate < Thresh
1
0
0 20 40 60 80 100 120 140
RT
S tr
igge
r
Time (seconds)
URTS < Thresh
181260
0 20 40 60 80 100 120 140Tx.
Pow
er (
dBm
)
Time (seconds)
Tx. Power
(a) 1 Second (b) 5 Seconds (c)10 Seconds
Figure 13: Efficacy in avoiding receiver side interference, which is introduced for 1-, 5-, and 10-seconddurations at different times. Utility of RTS and/or a decrease in rate trigger an increase in transmit power.
aged over ten runs. The graph shows that when operating atmaximum power, link z gets significantly lower throughputthan link x. When running x and z with Symphony, bothlinks achieve greater throughput because they are able to op-erate independently at the lower transmit powers, therebyalso demonstrating increased spatial reuse due to power con-trol. In both sets of experiments, Symphony increases thethroughput of asymmetry-affected links by three times.
Avoiding Receiver Side Interference: To show thatSymphony is effective in addressing receiver-side interferencein mobile environments, we consider links p and q in Fig-ure 8(b). Link q operates at maximum power, whereas linkp operates with Symphony. The setup is such that link p op-erates at 0 dBm when run individually, HS1 and HS2 sharethe channel at maximum power, and HS2 does not perceivetransmission on link p if p operates at 0 dBm and hencedestroys packets at HR1 (i.e. causes receiver side interfer-ence). In each run, we start a 20 Mbps UDP transfer on linkp for 3 minutes, and start a 5 Mbps transfer on link q for ashort periods (1 second, 5 seconds and 10 seconds) of timeat different times during the 3 minutes.
The bottom graphs in Figure 13 show that in response tolink q’s entry and exit, Symphony on link p increases anddecreases transmit power respectively to avoid the adverseeffect of receiver side interference. The graph shows thatSymphony is responsive to receiver side interference even atshort timescales of 1 second. The top two graphs in each ofthe cases (a), (b) and (c) show the rate and RTS triggersthat identify the condition that triggered increased power asin line 1 of Algorithm 3. We note that the utility of RTSis not always sufficient to detect receiver side interference,primarily because even RTS is sent at the chosen (lower)transmit power with Symphony, which may not be perceivedby HS2. In such a case, rate drops and leads to increasedtransmit power, thereby letting RTS reach HS2. Recall thatif RTS is useful, it reduces unnecessary reduction in rate.
4.2.3 Client MobilityTo demonstrate Symphony’s agility to client mobility, we
consider three AP locations and six client paths as shownin Figure 8(c). On each of the paths, the client is mobileat a speed of 0.75m/s. We again setup VOIP calls from
the AP to the client. Figure 14(a) shows for path p1 thatmoving the client away starts affecting the bitrate in theOPT phase, and hence Symphony increases transmit powerto maintain the bitrate to the same level as in the REFphase. As the client moves farther, even the rate in REFphase falls. Figure 14(b) shows that moving the client awayon path p2 makes Symphony increase transmit power, butit also reduces the power when the client returns to the APlocation. Overall, Symphony opportunistically enables a linkto operate up to 18dB lower than the default. Similar obser-vations can be made on other paths.
For the same experiment, Figure 15 shows the applica-tion level loss rate for Symphony in comparison to usingdefault maximum transmit power, and the difference in R-score. R-score is a popular performance metric for the qual-ity of voice calls [14]. An R-score of 70 or more is consid-ered good voice quality. While R-score depends on severalfactors [14], in brief, the difference in R-score can be simpli-fied to 40 × (log(1 + 10em) − log(1 + 10es)), where em andes represent the loss rate with maximum power and Sym-phony respectively. The graph shows that Symphony incurslittle extra impact on application level loss on all the paths.Further, in the worse case (path 4), the R-score using Sym-phony deteriorates only by 3.4 and the average R-score dete-rioration using Symphony is 2. While the actual R-score alsodepends on the end-to-end delay, we note that with even themaximum loss rate (as in path 4) using Symphony, in orderto achieve R-score as low as 70, the acceptable end-to-enddelay is over 300ms. Further, in-depth analysis of the lossesshows that significant part of the loss occurs when the clientis far away from the AP. In a real mobility enabled WLAN,mobile clients handoff to closer APs for better quality, andhence we believe that even this application-level loss will notoccur in practice.
4.2.4 Experiments with non-compliant nodesWe now consider the case when Symphony is incrementally
deployed in a setting where it has to operate in conjunc-tion with non-compliant nodes such as other legacy WLANs.We first investigate whether transmit power reduction canbe achieved in this situation. We consider the setup (Fig-ure 8(a)) with s3 as the AP location, and a,b,c,y as fourclient locations, with s3 running Symphony. We switch to
5448
36
2418126
0 10 20 30 40 50 60 70 80 90
1815129630
802.
11 R
ate
(Mbp
s)
Tx.
Pow
er (
dBm
)
Time (seconds) for mobile client
Rate (OPT)Rate (REF)
Tx. Power
5448
36
2418126
0 10 20 30 40 50 60 70 80 90
1815129630
802.
11 R
ate
(Mbp
s)
Tx.
Pow
er (
dBm
)
Time (seconds) for mobile client
Rate (OPT)Rate (REF)
Tx. Power
5448
36
2418126
0 10 20 30 40 50 60 70 80 90
1815129630
802.
11 R
ate
(Mbp
s)
Tx.
Pow
er (
dBm
)
Time (seconds) for mobile client
Rate (OPT)Rate (REF)
Tx. Power
(a) Path 1 (b) Path 2 (b) Path 3
5448
36
2418126
0 10 20 30 40 50 60 70 80 90
1815129630
802.
11 R
ate
(Mbp
s)
Tx.
Pow
er (
dBm
)
Time (seconds) for mobile client
Rate (OPT)
Rate (REF)
Tx. Power
5448
36
2418126
0 10 20 30 40 50 60 70 80 90
1815129630
802.
11 R
ate
(Mbp
s)
Tx.
Pow
er (
dBm
)
Time (seconds) for mobile client
Rate (OPT)Rate (REF)
Tx. Power
5448
36
2418126
0 10 20 30 40 50 60 70 80 90
1815129630
802.
11 R
ate
(Mbp
s)
Tx.
Pow
er (
dBm
)
Time (seconds) for mobile client
Rate (OPT)Rate (REF)
Tx. Power
(a) Path 4 (b) Path 5 (b) Path 6
Figure 14: Adaptation to mobility: Symphony’s behavior of rate and power in different paths.
8
6
4
2
0654321
0
2
4
6
8
Loss
rat
e (%
)
R-s
core
diff
eren
ce
Mobility Path
Loss rate - MAXLoss rate - Symphony
R-score difference
Figure 15: Application loss rate with mobility.
channel 6 in 802.11g, on which there are other active APsand clients from our office WLAN. By observing beaconsat the location s3, we determine that there are at least 13non-compliant APs on channel 6.
For each client, the Symphony AP makes a 2 Mbps trans-fer to every client every half an hour, to estimate the powerlevel appropriate for the clients. We perform this experi-ment over a period of 12 hours mostly during regular of-fice hours when the network is active. Figure 16(a) showsthe CDF of the average transmit power per client in eachrun, across several runs, for four clients. The graph showsthat Symphony opportunistically reduces the transmit poweron all links even when operating in conjunction with a non-Symphony-compliant network. For instance, links (s3, c) and(s3, y) operate 6dB lower than the default transmit power85% of the time.
We also study the effect of Symphony on non-compliantnodes in a controlled environment by conducting experi-ments on the ORBIT testbed. In this setup, we consider 2APs and 11 clients using Symphony, and 2 APs and 13 clientsare in legacy mode (using maximum transmit power andSampleRate for rate adaptation). For the legacy clients, weemulate realistic WLAN traffic (as described in [16]), whileusing two-way VOIP for the Symphony clients. We comparethe average packet error rate (PER) for legacy clients withand without transmit power control on the Symphony part ofthe network. Figure 16(b) shows the CDF of average PERper client. The graph shows that Symphony nodes have a
positive effect of reducing PER for the legacy clients. Sincethe legacy clients use higher transmit power than the Sym-phony nodes, when power control is enabled, their transmis-sions more likely benefit from the capture effect, which inturn reduces the PER. Reduced PER results in the usageof higher MAC bit-rates, as shown in Figure 16(c). Theseresults demonstrate Symphony’s incremental deployability.
4.2.5 Potential Battery Life Improvements
Due to lack of hardware support for measuring the exactenergy savings, we choose the analytical model in [38] todemonstrate the potential energy benefits of Symphony. Ac-cording to the model given by Equations 17 and 41 in [38],the power dissipated during transmission (Pd) can be repre-sented in terms of the transmit power (Pt) and the commonpower (Pc) that is consumed by the circuitry independentof the transmit power, as
Pd = Pc +Pt
0.02× 5[ 23×log10(Pt)]
(1)
where all quantities are in milliwatts. Using the above equa-tion and power consumption values from Broadcom’s BCM4328 card [1], we obtain Pc = 305mW . Using this value andthe above equation, we can calculate the power dissipatedat any transmit power.
Now, as an example, in the experiment correspondingto Figure 11(b), using the CDF and the power dissipatedby clients at each transmit power level, we can calculatethe average power dissipated by Symphony clients as PS
d =429mW for the ORBIT setup and PS
d = 497mW for the in-door office setup. In contrast, transmitting at the maximumtransmit power of 18dBm would lead to a power dissipationof PM
d = 766mW .Since battery life is inversely proportional to the power
dissipated, assuming that a card transmits and receives forequal amounts of time (and ignoring MAC protocol effectsfor simplicity and illustrative purposes), the active modebattery life improvement can be approximated as follows.
1
0.8
0.6
0.4
0.2
0
18 15 12 9 6 3 0
CD
F
Tx. Power (dBm)
cbya
(a) Transmit power reduction
1
0.8
0.6
0.4
0.2
0
0 10 20 30 40 50 60 70 80 90 100
CD
F
Avg. per-client PER (%) for legacy clients
Without TPCWith Symphony TPC
(b) PER reduction
1
0.8
0.6
0.4
0.2
0
54 48 36 24 18 12 6 0
CD
F
MAC Bit-rate (Mbps) for legacy clients
Without TPCWith Symphony TPC
(c) MAC bitrate increase
Figure 16: Interaction with an operational network that does not run Symphony.
At maximum transmit power, if LM is the battery life, andPr is the power dissipated during reception, then
LM =K
Pr + PMd + C
(2)
where K is a proportionality constant and C represents thepower consumed by the other components of the mobile(such as the processor, the graphics display, etc.) respec-tively. Similarly, if LS is the battery life with Symphony,then, LS = K
Pr+P S
d+C
. Then, the active mode battery life
improvement is LM−LS
LM. Substituting the Pd values calcu-
lated earlier and using the value for Pr = 295mW for theBCM 4328 card [1], we determine that the active mode bat-tery lifetime improvement with Symphony over using defaulttransmit power can be up to 46% for the ORBIT setup andup to 33% for the office setup (assuming that C is negli-gible). Compared to a per-cell power control solution [31],for Figure 10, the improvement for each client can rangefrom 0 to up to 26% with average being up to 17%. Thehigher the value of C, the lower will be the benefits of trans-mit power control. However, we envision that technologyimprovements will only reduce the value of C [43].
5. DISCUSSION AND LIMITATIONSWhile Symphony’s per-link power control improves net-
work throughput, its greedy approach may not achieve max-imum network throughput; a network wide optimizationproblem considering traffic profiles, locations of users, chan-nel conditions for all users, etc. may lead to higher networkthroughput, while compromizing some users. However, suchnetwork-wide optimizations are also much harder to realizein practice, especially with user mobility.
In this paper, we assume that clear channel assessmentthreshold (CCA) is fixed, mainly because commercial hard-ware does not openly allow modifying it to avoid its poten-tial abuse. However, Symphony’s transmit power control iscomplementary to CCA tuning and can be easily extendedto incorporate CCA tuning. In general, Kim et al. [27] ar-gue that fixing one parameter and tuning the other givesthe same effect, although fixing CCA threshold and varyingtransmit power has added benefits.
While Symphony does not need modifications to the MACprotocols, it does require synchronization that is currentlynot a common feature in WLANs. However, Symphony onlyrequires loose synchronization that can be easily achieved,as we do in our implementation. On the implementation
side, our AP-client synchronization is currently susceptibleto packet losses. If the broadcast packet from the AP forswitching phase is lost, a client will not switch phase andaffect Symphony functionality. However, this can be easilyfixed by utilizing the client’s local clock to switch phase atthe appropriate time if the broadcast message is not receivedwithin a tolerance, much like how NTP [4] functions.
Finally, the success of Symphony depends on the prevalanceof per-packet transmit power control feature in wireless cards.While this feature, to our knowledge, is only supported byAtheros cards today, we believe that with the increasingpopularity of mobile devices and the growing need to im-prove battery life, other manufacturers will also eventuallyprovide the above feature.
6. CONCLUSIONPer-link adaptive transmit power control in 802.11 WLANs
faces the following challenges: (1) receiver-side interferenceand asymmetric channel access, (2) incorrect data rate se-lection, and (3) mobility-induced channel variations at shorttimescales. In this paper, we propose Symphony—a novelsynchronous two-phase rate and power control system, whoseagility in adaptation enables us to systematically address thethree challenges, while increasing 802.11 network capacityand battery life of mobile devices. Through a detailed pro-totype study, we conclude that Symphony is (1) effective inachieving the goals set-forth, (2) easy to realize in a WLAN,(3) readily deployable even in the presence of non-compliantnodes, while increasingly providing power control benefitsas more nodes adhere to Symphony’s strategy.
7. ACKNOWLEDGMENTSWe thank our shepherd, Ranveer Chandra, and the anony-
mous MobiSys reviewers for their feedback on this paper.We also thank Mesut Ergin for sharing his setup to emulaterealistic WLAN traffic on the ORBIT testbed.
8. REFERENCES[1] http://www.broadcom.com/products/Wireless-LAN/
802.11-Wireless-LAN-Solutions/BCM4328.[2] Cisco Aironet 350 Series Access Points.
http://www.cisco.com/univercd/cc/td/doc/product/wireless/airo 350/accsspts/ap350hig/ap350ch2.htm.
[3] Infonetics research. http://www.infonetics.com/.[4] Network time protocol. http://www.ntp.org.[5] Vo-Fi and dynamic power control: A possible mismatch?
http://tinyurl.com/323at6.
[6] Where are the Wi-Fi phone power-save capabilities?http://tinyurl.com/3bcn4x.
[7] Atheros breaks the power barrier with new wi-fi solution formobile devices. http://atheros.com/news/AR6002.htm,October 2007.
[8] A. Akella, G. Judd, S. Seshan, and P. Steenkiste.Self-management in chaotic wireless deployments. InMobiCom, 2005.
[9] W. Alliance. Wmm power save for mobile and portablewi-fi certified devices. Technical report, 2005.
[10] S. Avallone, S. Guadagno, D. Emma, A. Pescape, andG. Ventre. D-ITG distributed internet traffic generator. InProc. QEST 2004, pages 316–317, September 2004.
[11] J. C. Bicket. Bit-rate selection in wireless networks.Master’s thesis, M.I.T., Cambridge, MA, February 2005.
[12] P. Chevillat, J. Jelitto, and H. L. Truong. Dynamic DataRate and Transmit Power Adjustment in IEEE 802.11Wireless LANs. Intl. Journal of Wireless InformationNetworks, 2005.
[13] M. Chiang and J. Bell. Balancing supply and demand ofwireless bandwidth: joint rate allocation and power control.In IEEE INFOCOM, March 2004.
[14] R. Cle and J. Rosenbluth. Voice over IP performancemonitoring. ACM Comp. Commn. Rev., 31(2), April 2001.
[15] R. Draves, J. Padhye, and B. Zill. Routing in multi-radio,multi-hop wireless mesh networks. In MobiCom, 2004.
[16] M. A. Ergin, K. Ramachandran, and M. Gruteser.Extended Abstract: Understanding the Effect of AccessPoint Density on Wireless LAN Performance. InMOBICOM, 2007.
[17] G. J. Foschini and Z. Miljanic. A simple distributedautonomous power control algorithm and its convergence.IEEE Trans. on Vehicular Technology, April 1993.
[18] P. Hande, S. Rangan, and M. Chiang. Distributed uplinkpower control for optimal sir assignment in cellular datanetworks. In INFOCOM, 2006.
[19] I. Haratcherev, K. Langendoen, R. Lagendijk, and H. Sips.Hybrid rate control for IEEE 802.11. In Intl. Workshop onMobility Management and Wireless Access, 2004.
[20] T. He, S. Krishnamurthy, J. A. Stankovic, T. Abdelzaher,L. Luo, R. Stoleru, T. Yan, L. Gu, J. Hui, and B. Krogh.Energy-efficient surveillance system using wireless sensornetworks. In MobiSys, 2004.
[21] G. Holland, N. Vaidya, and P. Bahl. A rate-adaptive MACprotocol for multi-hop wireless networks. In Proc. of ACMMOBICOM, Rome, Italy, 2001.
[22] J. Jeong, D. E. Culler, and J.-H. Oh. Empirical analysis oftransmission power control algorithms for wireless sensornetworks. In IEEE INSS, 2007.
[23] E.-S. Jung and N. H. Vaidya. A power control mac protocolfor ad hoc networks. In MobiCom, 2002.
[24] A. Kamerman and L. Monteban. WaveLAN-II: Ahigh-performance wireless LAN for the unlicensed band.Bell Labs Technical Journal, pages 118–133, Summer 1997.
[25] V. Kawadia and P. R. Kumar. Principles and protocols forpower control in ad hoc networks. IEEE JSAC, 2005.
[26] J. Kim, S. Kim, S. Choi, and D. Qiao. CARA:Collision-aware rate adaptation for IEEE 802.11 WLANs.In INFOCOM, 2006.
[27] T.-S. Kim, H. Lim, and J. C. Hou. Improving spatial reusethrough tuning transmit power, carrier sense threshold, anddata rate in multihop wireless networks. In MobiCom, 2006.
[28] M. Lacage, M. H. Manshaei, and T. Turletti. IEEE 802.11rate adaptation: a practical approach. In MSWiM, 2004.
[29] S. Lin, J. Zhang, G. Zhou, L. Gu, J. A. Stankovic, andT. He. ATPC: adaptive transmission power control forwireless sensor networks. In SenSys, 2006.
[30] MadWifi. Multiband Atheros Driver for WiFi.http://www.madwifi.org/.
[31] V. Mhatre, K. Papagiannaki, and F. Baccelli. Interferencemitigation through power control in high density 802.11WLANs. In Proc. of IEEE INFOCOM, 2007.
[32] J. Monks, V. Bharghavan, and W.-M. Hwu. A powercontrolled multiple access protocol for wireless packetnetworks. In INFOCOM, 2001.
[33] A. Muqattash and M. Krunz. Power controlled dual channel(pcdc) medium access protocol for wireless ad hoc networks.In Proc. of IEEE INFOCOM, pages 470–480, 2003.
[34] A. Muqattash and M. Krunz. A single-channel solution fortransmission power control in wireless ad hoc networks.IEEE JSAC, 2005.
[35] S. Narayanaswamy, V. Kawadia, R. S. Sreenivas, and P. R.Kumar. Power control in ad hoc networks: Theory,architecture, algorithm and implementation of the compowprotocol. In Proc. of European Wireless Conference, 2002.
[36] V. Navda, R. Kokku, S. Ganguly, and S. Das. SlottedSymmetric Power Control in managed WLANs,http://www.nec-labs.com/∼ravik/RESEARCH/contour.pdf. Technicalreport, NEC Laboratories America.
[37] J. Pavon and S. Choi. Link Adaptation Strategy for IEEE802.11 WLAN via Received Signal Strength Measurement.In Proc. of IEEE ICC, May 2003.
[38] D. Qiao, S. Choi, A. Jain, and K. G. Shin. Miser: anoptimal low-energy transmission strategy for ieee802.11a/h. In ACM MobiCom, pages 161–175, 2003.
[39] D. Qiao, S. C. A. Jain, and K. G. Shin. Adaptive transmitpower control in IEEE 802.11a wireless LANs. In IEEEVTC (Spring), volume 1, pages 433–437, April 2003.
[40] K. Ramachandran, R. Kokku, H. Zhang, and M. Gruteser.Synchronous Two-phase Rate and Power Control in 802.11WLANs. http://www.nec-labs.com/∼ravik/RESEARCH/symphony-tech.pdf.
[41] K. Ramachandran, H. Kremo, M. Gruteser, P. Spasojevic,and I. Seskar. Scalability analysis of rate adaptationtechniques in congested ieee 802.11 networks: An orbittestbed comparative study. In WoWMoM, 2007.
[42] D. Raychaudhuri, I. Seskar, M. Ott, S. Ganu,K. Ramachandran, H. Kremo, R. Siracusa, H. Liu, andM. Singh. Overview of the ORBIT radio grid testbed forevaluation of next-generation wireless network protocols. InProc. of IEEE WCNC, March 2005.
[43] C. W. S. Gaudin. Intel unveils new low-power chip/buildingblock. http://tinyurl.com/4wkxdr.
[44] V. Shah, E. Gelal, and S. V. Krishnamurthy. Handlingasymmetry in power heterogeneous ad hoc networks.Comput. Networks, 51(10):2594–2615, 2007.
[45] A. Sheth and R. Han. A Mobility-Aware Adaptive PowerControl Algorithm For Wireless LANs. In IEEE CAS LowPower Workshop, 2002.
[46] A. Sheth and R. Han. An Implementation of TransmitPower Control in 802.11b Wireless Networks. Technicalreport, Dept. of Comp. Science, Univ. of Colorado, 2002.
[47] A. Sheth and R. Han. Shush: Reactive transmit powercontrol for wireless mac protocols. In WICON, 2005.
[48] V. Shrivastava, D. Agarwal, A. Mishra, S. Banerjee, andT. Nadeem. Understanding the limitations of transmitpower control for indoor WLANs. In IMC, 2007.
[49] D. Son, B. Krishnamachari, and J. Heidemann.Experimental study of the effects of transmission powercontrol and blacklisting in wireless sensor networks. InProc. of IEEE SECON, 2004.
[50] S. H. Y. Wong, S. Lu, H. Yang, and V. Bharghavan.Robust rate adaptation for 802.11 wireless networks. InACM MOBICOM, 2006.
[51] M. Xiao, N. B. Shroff, and E. Chong. A utility-based powercontrol scheme in wireless cellular systems. IEEE/ACMTrans. on Networking, 11(2):210–221, 2003.