RRAA algoritmo

8/2/2019 RRAA algoritmo

1/12

Robust Rate Adaptation for 802.11 Wireless Networks

Starsky H.Y. Wong1, Hao Yang2, Songwu Lu1 and Vaduvur Bharghavan3Dept. of Computer Science, UCLA, 4732 Boelter Hall, Los Angeles, CA 90025 1

IBM T.J. Watson Research, 19 Skyline Drive, Hawthorne, NY 10532 2

Meru Networks, 1309 South Mary Avenue, Sunnyvale, CA 94087 3

{hywong1,slu}@cs.ucla.edu1, [email protected], [email protected]

ABSTRACT

Rate adaptation is a mechanism unspecified by the 802.11standards, yet critical to the system performance by exploit-ing the multi-rate capability at the physical layer. In this pa-per, we conduct a systematic and experimental study on rateadaptation over 802.11 wireless networks. Our main contri-butions are two-fold. First, we critique five design guidelinesadopted by most existing algorithms. Our study reveals that

these seemingly correct guidelines can be misleading in prac-tice, thus incur significant performance penalty in certainscenarios. The fundamental challenge is that rate adapta-tion must accurately estimate the channel condition despitethe presence of various dynamics caused by fading, mobilityand hidden terminals. Second, we design and implement anew Robust Rate Adaptation Algorithm (RRAA) that ad-dresses the above challenge. RRAA uses short-term loss ra-tio to opportunistically guide its rate change decisions, andan adaptive RTS filter to prevent collision losses from trig-gering rate decrease. Our extensive experiments have shownthat RRAA outperforms three well-known rate adaptationsolutions (ARF, AARF, and SampleRate) in all tested sce-narios, with throughput improvement up to 143%.

Categories and Subject Descriptors: C.2.1 [Computer-Communication Networks]:Network Architecture and De-sign[Wireless communication]

General Terms:Design, Experimentation, Performance

Keywords: Rate Adaptation, 802.11

1. INTRODUCTIONRate adaptation is a link-layer mechanism critical to the

system performance in IEEE 802.11-based wireless networks,yet left unspecified by the 802.11 standards. The current802.11 specifications mandate multiple transmission rates atthe physical layer (PHY) that use different modulation andcoding schemes. For example, the 802.11b PHY supportsfour transmission rates (111 Mbps), the 802.11a PHY of-

fers eight rates (654Mbps), and the 802.11g PHY sup-

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.

MobiCom06, September 2326, 2006, Los Angeles, California, USA.Copyright 2006 ACM 1-59593-286-0/06/0009 ...$5.00.

ports twelve rates (154Mbps). To exploit such multi-ratecapability, a sender must select the best transmission rateand dynamically adapt its decision to the time-varying andlocation-dependent channel quality, without explicit infor-mation feedback from the receiver. Such an operation isknown as rate adaptation. Given the large numerical spanamong the available rate options, rate adaptation plays acritical role on the overall system performance in 802.11-based wireless networks, such as the widely deployed WLANs

and the emerging mesh networks.In recent years, a number of algorithms for rate adapta-

tion [1, 2, 12, 8, 3, 4, 10, 5, 6, 7, 9] have been proposed in theliterature, and some [1, 12, 8] have been used in real prod-ucts. Their basic idea is to estimate the channel quality andadjust the transmission rate accordingly. This is typicallyachieved by using a few metrics collected at the sender andthe associated design rules. The widely used metrics includeprobe packets [1, 2, 8], consecutive successes/losses [1, 2, 6],PHY metrics such as SNR [4, 3, 6], and long-term statistics[12]. Examples of the commonly used rules include increas-ing rate upon consecutive successes, using probe packets toassess new rates, etc. While all such metrics and rules seemintuitively correct and each design has its own merits, little

is known about how effectively they perform in a practicalsetting. The fundamental problem is that real-world wire-less networks exhibit rich channel dynamics including ran-dom channel errors, mobility-induced channel variation, andcontention from hidden stations. Each of the above metricsand associated design rules has limited applicable scenarios.Consequently, each design has its own Achilles heel.

In this paper, we conduct a systematic and experimentalstudy to expose the challenges for rate adaptation and ex-plore new design space. To this end, we first use experimentsand simple analysis to critically examine five design guide-lines followed by most existing algorithms. These guidelinesinclude: (1) decrease transmission rate upon severe packetloss, (2) use probe packets to assess the new rate, (3) useconsecutive transmission successes/losses to decide rate in-

crease/decrease, (4) use PHY metrics to infer new transmis-sion rate, and (5) long-term smoothened operation producesbest average performance. For experimental comparison, weimplement three popular algorithms (ARF [1], AARF [2],SampleRate [8]) on a programmable AP platform, togetherwith the ONOE algorithm [12] available in MADWiFi [17].We not only identify the issues with these algorithms usingexperiments, but also take a microscopic view of their run-time behavior and gain insights on the root causes of theissues. Our experiments surprisingly show that the above

146


2/12

AP

P1P2

P3P4

H

P5R

Figure 1: Experimental floor plan.

five seemingly valid guidelines can be quite misleading inpractice, and may incur significant performance penalty ofup to 70% throughput drop. In fact, we even discoveredthat with mild link-layer contention, these rate adaptationdesigns not only fail to facilitate throughput improvement,but also reduce the throughput and aggravate channel con-tention because rate decrease is falsely triggered.

To address these challenges, we design and implement aRobust Rate Adaptation Algorithm (RRAA) based on twonovel ideas. First, we use short-term loss ratio in a win-dow of tens of frames to opportunistically guide the rateselection. Such a loss ratio provides not only fresh butalso dependable information to estimate the channel qual-

ity. Second, we leverage the per-frame RTS option in the802.11 standards, and use an adaptive RTS filter to sup-press collision losses with minimal overhead. We implementRRAA on a programmable AP platform and evaluate itsperformance using thorough experiments as well as field tri-als. Our results show that RRAA consistently outperformsthree well-known algorithms of ARF, AARF and SampleR-ate in all scenarios with 802.11a/b channels, static/mobilestations, TCP/UDP flows, with/without hidden stations,and in controlled/uncontrolled environments. The through-put improvement of RRAA over these algorithms can be ashigh as 143% in realistic field trials.

The two key contributions of this paper are as follows.First, we provide a systematic critique on five design guide-

lines in the state-of-art rate adaptation algorithms. Second,we design, implement and evaluate a robust rate adaptationalgorithm, which addresses all these identified issues and isfully compliant with the 802.11 standards.

The rest of the paper is organized as follows. Section2 introduces the background and Section 3 describes ourexperimental system and methodology. Section 4 examinesfive design guidelines in existing rate adaptation algorithms.Section 5 presents the design of our robust rate adaptationalgorithm, and Section 6 describes the implementation andevaluates its performance. Section 7 discusses the relatedwork, and Section 8 concludes the paper.

2. BACKGROUND

We consider a practical 802.11-based wireless LAN or meshnetwork scenario. Both clients and access points (APs)/meshrouters use 802.11 a/b/g devices. The clients may roambut the APs/mesh routers are typically static. The physi-cal layer operates at 2.4GHz for 802.11b/g or at 5Ghz for802.11a, which only has a limited number (e.g., 3 for 802.11b/g) of independent channels. Thus, multiple APs withina geographic locality may have to share one of these chan-nels. This readily leads to hidden stations among APs andclients. In our campus building environment, we can eas-ily sniff about 410 APs and 50100 clients on any given

802.11 b/g Channel 1, 6, or 11 during regular office hours,and they may act as hidden stations among one another.

The default operation mode for wireless LAN/mesh net-work is the 802.11 DCF, in which an DATA-ACK exchangeis performed between the client and the AP/mesh router af-ter carrier sensing. To avoid collisions from hidden stations,the 802.11 standards recommend to use RTS/CTS hand-shake. However, in practice RTS/CTS is turned off in mostdeployed wireless LANs to reduce the signaling overhead.

Rate adaptation allows for each device to adapt the run-time transmission rate based on the dynamic channel condi-tion. It has been used by all 802.11a/b/g devices in reality.An 802.11b device can use four rate options of 1, 2, 5.5,11Mbps. An 802.11a device can use eight rate options of 6,9, 12, 18, 24, 36, 48, 54Mbps. An 802.11g device can useall twelve rate options. The goal of rate adaptation is tomaximize the transmission goodput at the receiver1. It ex-ploits the PHY multi-rate capability and enables each deviceto select the best rate out of the mandated options. Rateadaptation is typically implemented at both the AP and theclient, and the exact algorithm is left to the vendors.

In the current 802.11 standard, a receiver does not provideexplicit feedback information on the best rate or perceived

SNR to the sender. Therefore, most practical rate adap-tation algorithms [1, 2, 12, 8, 6, 10] make decisions solelybased on the ACK, which is sent upon successful delivery ofa DATA packet2. The sender assumes a transmission failureif it receives no ACK before a timeout.

3. EXPERIMENTAL METHODOLOGYThe evaluation results presented in this paper are all ob-

tained from real experiments. In this section, we describeour experimental platform, setup and methodology.Programmable AP Platform Our experiments are con-ducted over a programmable AP platform. The AP usesAgere 802.11a/b/g chipset and supports all three types ofclients. The 802.11 MAC is implemented in the FPGA

firmware, to which we have access. The platform has sev-eral appealing features that facilitate our research on rateadaptation. First, we can program our own rate adaptationalgorithm, import other existing algorithms, and run themat the AP. Second, it provides per-frame control functional-ities. We can perform per-frame tracing of various metricsof interests, such as frame retry count and SNR value. Themaximum retry count and RTS option can be configuredin real time on a per-frame basis. We may also controlthe transmission rate for each frame retry, similar to theMADWiFi device driver for Atheros chipset. Third, it sup-ports all 802.11a/b/g channels and devices, and is compliantto 802.11 standards. Fourth, the feedback delay from thehardware layer is small; this implies that timely link-layerinformation is available to rate adaptation.Experimental Setup We conduct all our experiments ina campus setting. Figure 1 shows the floor-plan of the build-ing where we run experiments. Spot AP is the location ofthe programmable AP, and spot H is another AP spot in-side a conference room. The AP at H periodically broad-casts packets for its clients, but acts as a hidden station for

1Goodput and throughput carry the same meaning in thispaper.2In this paper, we use packets and frames interchangeably,with a slight abuse of notation.

147


3/12

the programmable one at AP. Spots P1, P2, P3, P4, P5, Rrepresent six different locations where the receiving clientsare placed during the experiments.

In most cases, the AP serves as the sender for the wirelesstraffic since we only implement the algorithms on the AP. Allclient devices run the Linux 2.6 kernel with CISCO Aironet802.11a/b/g Adapters. The wireless device driver on theclient side is MADWiFi.Experimental Methodology We run experiments us-

ing various settings with static/mobile clients, on 802.11 a/bchannels, with/without hidden stations. All these scenariosoccur in realistic 802.11 networks. The static settings evalu-ate the stability and robustness of an algorithm, i.e., whetherit can stabilize around the optimal rate and how sensitiveit is to random losses. The mobility settings evaluate howresponsive an algorithm is in adapting to significant channelvariations perceived by mobile clients. Finally, the hidden-station settings assess how an algorithm performs under col-lision losses. This setup represents the real-life scenario ofad-hoc deployment of 802.11b/g APs sharing the 2.4GHzchannels in residential, campus, or city environments.

To conduct repeatable experiments and provide fair com-parison among different algorithms, we perform most exper-

iments in a controlled manner to minimize the impact of ex-ternal factors, such as people walking around, microwaves,and traffic from other AP or client devices. Specifically,these experiments are done during midnight when the of-fices are empty, and we use an additional sniffer to ensureno background traffic exists over the channel in use. We useChannel 14 for 802.11b experiments because our sniffer candetect at least 4 APs and 3050 clients over each of Chan-nels 1, 6, 11 at all time. For 802.11a experiments, we useChannel 60, and no AP or client is using this channel duringour experiments. Finally, we run a set of uncontrolled fieldtrials, using 802.11b Channel 6, during the office hours toevaluate how different algorithms perform in realistic sce-narios.

We conduct each experiment for multiple runs, and the

result presented is the average over all runs. Each run lastsfor 60 seconds in the static setting and the hidden stationcases. Each mobility test lasts about 200 seconds. We ex-periment with both UDP and TCP traffic. For UDP, Weuse iperf [14] as the traffic generator, and vary the sendingrate from 5Mbps to 30Mbps at an increment of 5Mbps. Theresults reported in the paper are based on the sending ratethat produces the highest goodput. We also vary the packetsize in our experiments. To stay focused, we only presentthe results with 1300-byte packets in this paper.

We evaluate and compare five rate adaptation algorithmsin our experiments. Four of them, i.e., ARF [1], AARF[2], SampleRate [8], and the proposed RRAA, are imple-mented by us and run on our programmable AP. The fifthone, ONOE [12], is implemented by MADWiFi [17], andruns on the Linux client devices.

These selected algorithms provide a good sample of rep-resentative designs in the literature. ARF is the first rateadaptation design for 802.11 networks and has inspired manyfollowup proposals [2, 5, 6]. It sends a probe packet uponeither 10 consecutive transmission successes or timeout of 15transmissions. A probe packet is sent at a rate higher thanthe current one in use. If the probe packet succeeds, ARFincreases the transmission rate. Meanwhile, ARF decreasesthe rate upon two consecutive transmission failures. While

the probing threshold is fixed as 10 consecutive successes inARF, AARF improves the stability by doubling the prob-ing threshold (with a maximum bound of 50) when a probepacket fails. The probing threshold is reset to its initialvalue of 10 whenever the rate is decreased. SampleRate isarguably the best reported algorithm for static settings. Itmaintains the expected transmission time for each rate, andupdates it after each transmission. A frame is transmitted atthe rate that currently has the smallest expected transmis-

sion time. In addition, for every 10 frames, SampleRate alsosends one probe packet at another randomly selected rate.While in principle receiver-based designs such as RBAR [3]and OAR [4] may yield good performance, they cannot beimplemented on current 802.11 devices without modifyingthe standard. Thus, we are unable to implement and evalu-ate such algorithms.

4. ON STATE-OF-THE-ART RATE ADAP-

TATION ALGORITHMSMost current rate adaptation designs follow a few guide-

lines that are conceptually intuitive and seemingly effective.However, our study shows that they can be misleading in

practice and incur significant performance p enalty. In thissection, we first revisit the solution space and categorize theexisting designs in Section 4.1. We then critically examinefive commonly adopted design guidelines using experimentsand simple analysis in Section 4.2.

4.1 Solution Space for Rate AdaptationAt its core, each rate adaptation algorithm should possess

at least two basic mechanisms:

Estimation: It either directly estimates the best transmis-sion rate based on the current channel and network condi-tions, or indirectly infers the best rate by gauging how wellthe currently chosen rate performs.

Action: Given the latest estimation result, it decides when

and how the transmission rate is updated.Based on how these two mechanisms are implemented, wecan categorize various rate adaptation designs into severalgeneral approaches.

4.1.1 Estimation

To design the estimation mechanism, one must addressthe following two questions. First, what information canbe used in the estimation? Specifically, which layer is theinformation collected from, and what types of messages aretaken into account? Second, given the collected information,how should the best transmission rate be estimated?

Which layer to use: There are three approaches that col-lect information from different layers of the protocol stack.

The first one is the Physical-layer approach that uses SNRor other PHY metrics to directly estimate the channel qual-ity (e.g., RBAR [3], or OAR [4]). The second one is theLink-layer approach that uses frame transmission results toindirectly infer the channel quality (e.g., ARF [1], AARF [2],SampleRate [8], ONOE [12]). The last one is the Hybrid ap-proach that combines both PHY and link-layer information(e.g., HRC [6]).

Which message to use: The link-layer information canbe collected based on either data or signaling frames, orboth. For the Data-frame approach, rate adaptation uses

148


4/12

only the data frames to assess the channel quality. It can befurther classified into two subcategories. The first one is aprobing approach in which a few data frames are occasion-ally transmitted at a rate different from the current one toprobe the channel (e.g., ARF [1], AARF [2], SampleRate[8]). The second one is the non-probing approach that neversends out probe frames (e.g., our proposed RRAA). For theSignaling-frame approach, rate adapataion takes into ac-count the RTS/CTS handshake to better infer the causes

of frame losses (e.g., RBAR [3], OAR [4], CARA [10]).

How to estimate: The physical-layer approach typicallytranslates the measured SNR into a best transmission ratebased on pre-defined mappings. On the other hand, thelink-layer (or hybrid) approach needs to estimate the chan-nel quality based on the outcome of previously transmittedframes. The estimation can be done via: 1) Deterministicpattern that treats consecutive frame successes/failures asthe indication of good/bad channel condition (e.g., ARF [1],AARF [2]), and 2) Statistical metrics that use long-term orshort-term frame statistics to statistically estimate the bestpossible rate (e.g., SampleRate [8] or RRAA).

4.1.2 Action

In general, there are two approaches to adjusting the ratebased on the aforementioned estimation. The first approachis Sequential rate adjustment, which means to increase (ordecrease) the current rate by one level when the channelis good (or bad). In other words, the rate is adjusted byat most one level at a time. The second one is Best rateadjustment, which means to immediately change the rate tothe one that may yield the best performance. In such cases,the rate may jump or drop by multiple levels at a time.

4.2 Critiques on Current Design GuidelinesGiven the above solution space for rate adaptation, the

state-of-the-art algorithms have been using several designguidelines streamlined through the extensive practice of var-ious algorithms over the past fifteen years. In this section,we use real experiments to provide a critique on them. Weshow that while such guidelines are useful in certain pre-sumed scenarios, they can be misleading in other cases. Inthe worst case, they yield unexpected, erroneous results.

4.2.1 Guideline#1: Decrease transmission rate uponsevere packet loss

The first guideline states that, whenever severe packet lossoccurs, rate adaptation should decrease its current transmis-sion rate. This has been widely used in almost all existingalgorithms [1, 2, 12, 8, 6]. Severe packet loss is typicallydetected via excessive retry counts, beyond-threshold framelosses, or successive transmission failures. The original mo-tivation for this rule is that, whenever the link condition

between the sender and the receiver deteriorates and thus in-curs significant losses at the current rate, the sender switchesto lower rates to adapt to the worsening channel condition.

The above rule is easily broken in practice when hiddenstations exist. In the presence of hidden stations, a receivermay experience significant packet losses. This subsequentlytriggers rate adaptation at the sender to decrease its rate ac-cording to the stated guideline. However, the sender shouldnot decrease its transmission rate upon hidden-station in-duced losses, because reducing the rate cannot solve the con-tention problem. In fact, reducing the rate will make channel

ARF AARF SampleRate FixedRateGoodput (Mbps) 0.65 0.56 0.58 1.46

Loss Ratio 61% 60% 59% 60%

Table 1: Performance of different rate adaptation algo-

rithms in the presence of hidden stations.

contention even worse because it prolongs the transmission

time for each packet, which aggravates channel collisions andfurther reduces the rate.

Our experiment also confirms the above findings as shownin Table 1. We place a hidden AP at spot H, a receiver atspot R, and a sender at spot AP. The sending AP and thehidden AP are not aware of each other. We compare ARF,AARF, and SampleRate with the operation of turning offrate adaptation and using fixed rate (called FixedRate). Inthe absence of hidden AP, all algorithms are sending morethan 95% of packets at the highest rate 11Mbps, and theframe loss ratio is also relatively low at about 5.5%. How-ever, when the hidden AP starts to broadcast packets to itsclients at a mild rate of 0.379Mbps, receiver R experiencesabout 60% losses for all algorithms. The heavy loss triggers

the senders rate adaptation algorithm to decrease its send-ing rate to 1Mbps. Overall, this leads to the throughputaround 0.560.65Mbps for ARF, AARF, and SampleRate.In contrast, if we turn off rate adaptation and fix the rateat 11Mbps, the throughput is 1.46Mbps, about 124.6% to160.7% higher than that of the three algorithms. These ex-perimental results show that improper rate adaptation notonly fails to improve the system performance, but also re-duces the achievable throughput. More results in the hiddenstation environment will be presented in Section 6.

The fundamental problem is that rate adaptation may ex-perience much richer set of packet loss scenarios in practice,which are well beyond the simplistic one of only fading/pathloss envisioned by the original designs. The guideline of de-creasing rate upon severe packet loss does not apply in other

lossy scenarios. The rate adaptation solution has to differ-entiate various losses and react accordingly.

4.2.2 Guideline #2: Use probe packets to assess pos-sible new rates

The second guideline uses one or multiple probe packetsto learn the channel status at transmission rates other thanthe one currently in use. The probe packets are data framessending at a different transmission rate. The goal is to de-termine whether other rates will yield better performance.If the results from such probe packets indeed lead to higherthroughput, rate adaptation will switch to the new, typicallyhigher rate. In the existing algorithms, probe packets willbe sent out at the next higher rate after multiple successful

transmissions at the current rate [1, 2, 6], or at a randomlyselected rate once every tens of packets [8].

The above design guideline also has two downsides, as il-lustrated by our simple analysis. First, a successful probecan be misleading and trigger incorrect rate increase. In theliterature, algorithms such as ARF, AARF, and HRC use asingle probe packet to assess the channel at a higher rate.Whenever such a single probe packet is successfully trans-mitted at the higher rate, such algorithms decide to increasethe rate accordingly. Now consider the following realisticcase. The sender and the receiver have near-perfect trans-

149


5/12

0 10 20 30 40 500

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of consecutive successes/failures

CDF

SuccessFailure

Figure 2: CDF of an additional suc-

cess/failure transmission after n con-

secutive success/failure transmissions.

0 5 10 15 2032

34

36

38

40

42

44

46

48

50

Time (second)

S

ignaltoNoiseRatio

(dB)

Figure 3: Evolution of SNR over time.

0 200 400 600 800 10000

0.01

0.02

0.03

0.04

0.05

Time elapsed between two transmissions (ms)

Mutualinformation

Figure 4: Mutual Information of two

packets separated by x ms in time.

missions at 12Mbps, but suffer from 40% loss at a higher rateof 18Mbps. That means, a single probe sent at 18Mbps has60% chance to get through. However, the expected through-put for sending packets at 18Mbps with 40% loss is smallerthan the one at 12Mbps with near zero loss. From our ob-

servations, most immediate higher rates in reality have lessthan 50% loss percentage. Therefore, the chance of successfor a single probe is usually higher than 50%, and such asuccess can be misleading.

Second, an unsuccessful probe can incur severe penalty onfuture rate adaptation. We use the SampleRate algorithm[8] as an example to illustrate the problem. In SampleRate,probe packets are regularly sent at every ten-packet inter-val and transmitted at a randomly chosen rate. The im-plementation of SampleRate in MadWiFi uses exponentialweighted moving average (with a weighting factor of 0.05for the latest sample) to statistically update the per-packetexpected transmission time at a given rate. The real issueis that such a statistical update based on probe is too sen-sitive to (possibly rare) failure of probe packets. This hap-

pens when the expected transmission times for two rates arevery close. For example, in 802.11a/g devices, the losslesstransmission times at 54Mbps and 48Mbps are 534ms and560ms3, respectively, for 1400B packets. Consider the casewhere SampleRate currently operates at 48Mbps but probesat 54Mbps. A single probe failure (say, the total retry countis 4) at 54Mbps will update the expected transmission timeat 54Mbps as 625ms. Therefore, this single probe failureprevents the rate adaptation from switching to 54Mbps foran extended period of time. A detailed calculation showsthat it takes 25 lossless probes for SampleRate to change625ms into a value smaller than 560ms, the lossless time at48Mbps. Considering that each probe packet is sent onceevery ten frames, it takes 250 frame transmissions for Sam-pleRate to eventually switch to 54Mbps. The consequenceis that this suboptimal rate reduces throughput even withrare probe failure. Our real experiments also confirm thisdiscovery in reality, as we will document in Section 6.

The fundamental problem is that statistically small num-ber of probe samples may yield inaccurate rate adaptation.It can be overly optimistic upon a probe success, or toopessimistic upon a probe failure.

3We obtain these values by using the equation given in [8].

4.2.3 Guideline #3: Use consecutive transmissionsuccesses/losses to increase/decrease rate

The third guideline states that, upon multiple consecutivetransmission successes (say, 10 in ARF [1], AARF [2], andHRC [6]), the current rate should be increased to the next

higher rate; upon back-to-back transmission failures (say, 2in ARF, AARF and HRC, or 4 in SampleRate), the rateshould be decreased to a lower one.

Our experiments show that the above design guideline isnot valid in many practical scenarios. In our experiments,we turn off rate adaptation as well as the frame retry. Weplace the AP and the client at different spots, and manuallyfix the transmission rate which gives the highest through-put, for each experimental run. The success/failure eventfor each packet transmission is recorded inside the AP. Thecumulative distribution probability for n consecutive trans-mission successes/failures is plotted in Figure 2.

We make two observations from Figure 2. First, the prob-ability for a failed transmission following at least two con-secutive failures is only 36.8%. This result means that with

63.2% chance, a successful tranmission will occur after twoor more consecutive failures. Therefore, decreasing currentrate upon consecutive transmission failures may not be theright choice statistically. Second, the probability for a suc-cessful transmission following at least 10 consecutive suc-cesses is only 28.5%. Thus, the chance for a failed transmis-sion following 10 consecutive successes is 71.5%. This resultindicates that consecutive transmission successes cannot bea reliable metric to predict the next transmission rate.

The fundamental problem is that most realistic scenar-ios exhibit randomly distributed loss behaviors. Any deter-ministic pattern of transmission successes/failures may notoccur with large probability in all cases.

4.2.4 Guideline #4: Use PHY metrics like SNR toinfer new transmission rate

The next guideline suggests to use the physical-layer met-rics, such as the signal-to-noise ratio (SNR), for rate estima-tion. This has been used to estimate rates in the presenceof client mobility in HRC [6]. It has also been applied in thereceiver-based rate adaptation algorithms such as RBAR [3]and OAR [4]. In theory, such physical-layer metrics mayindeed lead to an accurate rate estimation.

However, the above design rule encounters severe diffi-culties in practical 802.11 systems for two reasons. First,

150


6/12

Sampling intervals (ms) 5000 1000 500 100UDP Goodput (Mbps) 14.9 15.3 16.5 17.1

Table 2: Performance of ONOE with different sampling

intervals.

earlier experimental studies [13, 8] already show that thereis no strong correlation between SNR and delivery proba-

bility at a rate in a general case. Second, our experimentsshow that the SNR variations also make the rate estimationhighly inaccurate. In our experiment, we send back-to-backUDP packets from the AP to the client (located at P1) andsample the SNR value. Figure 3 plots the SNR value for eachreceived packet. The figure indicates that it is common forthe SNR value to have variations of 5dB between consecu-tive transmissions. In some cases, the variation can be aslarge as 1014dB. This large SNR variation can easily leadto more than one-rate-level deviation out of the multi-rateoptions when translating to the transmission rate, based onthe goodput versus SNR mapping (Figure 7 of [5]).

In our experiments, we also tried other two physical-layermetrics, the background energy level (with the intention todifferentiate fading loss and collision loss), and received sig-

nal strength indication (RSSI). However, neither metric canbe directly used to estimate the rate accurately, nor can onebe used to differentiate loss causes.

4.2.5 Guideline #5: Long-term smoothened opera-tion produces best average performance

This guideline suggests to use long-term smoothened op-eration in the presence of random losses over the channel.The operation can be either rate estimation or rate changeaction, or both. In rate estimation, this rule recommends touse long-term statistical information to estimate the optimaltransmission rate. For example, popular algorithms ONOE[12] and SampleRate [8] both collect packet-level statistics(in terms of loss and throughput) over a period of one to tenseconds. In rate change decision, this rule suggests to onlychange rates infrequently, say, once every 1 or 10 seconds.In both cases, the underlying hypothesis is that long-termestimation/action will smoothen out the impact of randomerrors and lead to best average performance. Our experi-ment and analysis based on information theory invalidateboth claims.

We first show through experiments that long-term rateestimation and rate change action over large sampling pe-riods will not yield best average performance. The experi-ment is conducted using the ONOE algorithm implementedin MADWiFi. ONOE uses one second as the default sam-pling interval. It changes its rate based on the packet-levelloss statistics collected over each sampling period. In the ex-periment, the sender located at P2 of Figure 1 uses ONOE

to send packets to the AP. We vary the sampling period andthe results are given in Table 2. The table clearly shows thatsmall sampling period of 100ms actually produces the bestaverage performance in the long term. Using large samplingperiod may lead to 12.9% throughput reduction. In fact,similar results have also been reported in early studies (Fig-ure 3.5 of [8]). One reason for this performance drop is thatthe algorithm is unable to exploit the short-term opportunis-tic gain over the wireless channel, which typically occurs atthe time scale of hundreds of milliseconds.

We next use the concept of mutual information [16] to

show that long-term rate estimate over large sampling pe-riods does not help even in the presence of random loss.Mutual information indicates the mutual dependency of tworandom variables, i.e., how much information one randomvariable can tell about the other. We treat the transmis-sion success/failure event at a given time as a random vari-able and calculate the mutual information for two events atdifferent time instants. In an experimental setting similarto section 4.2.3, we disable rate adaptation and the frame

retry, and record the time for each success/failure transmis-sion. We then calculate the mutual information for eachpair of packets separated by an interval of x ms. Figure 4plots the mutual information evolution with respect to dif-ferent x. The figure shows that their mutual informationbecomes negligible when two packets are separated by morethan 150ms over time. This implies that the success/failureevent occurred 150ms earlier can barely provide any usefulinformation for the current rate estimation. We also con-duct similar experiments at different locations. All resultsshow that mutual information diminishes when the samplingperiod becomes larger than 150250ms. This experimentalresult shows that large sampling periods, ranging from a fewseconds to tens of seconds, do not lead to more accurate rate

estimation. In this case, how to assign different weightingfactors for samples over time becomes a challenging issue.The next experiment shows that long-term, infrequent

rate change decision may also lead to performance penalty.The experiment is set up for the client mobility case, inwhich a person carries the receiver and walks at approxi-mately constant pedestrian speed of 1m/s. The experimentis in 802.11b and the route is P1 P2 P3 P4 P5 P4 P3 P2 P1 (see Figure 1), and each triptakes about 200 seconds. In the test, we compare the perfor-mance of ARF and SampleRate4. Both ARF and SampleR-ate use relatively short-term rate estimation. ARF sends aprobe packet no later than 15 transmissions. SampleRateimplementation uses EWMA with a factor of 0.05, whichimplies that roughly only the recent 50 samples carry major

weights in the estimation. However, the rate change actionsin both algorithms are quite different. ARF allows for ratechange every 10 or 15 packets, while SampleRate takes 2 sec-onds to switch to a new rate (unless four consecutive lossestrigger rate decrease). Our experimental results show that,the average UDP goodput for ARF and SampleRate are3.85Mbps and 3.50Mbps, respectively. ARF performs 10%better than SampleRate in the mobile client case, whichshows that the delayed rate-change decisions hurt the re-sponsiveness of SampleRate.

5. DESIGNIn this section, we present the design of RRAA, a Ro-

bust Rate Adaptation Algorithm for 802.11-based wirelessnetworks. Overall, RRAA tries to maximize the aggregatethroughput in the presence of various channel dynamics.Specifically, it seeks to achieve the following goals:

4We implemented SampleRate based on their source codesin MADWiFi, which is different from the algorithm de-scribed in [8]. First, while [8] averages the transmission timeover a 10-second window, the implementation uses EWMAwithout any window. Second, while [8] suggests p er-packetrate decision, the rate is only changed every 2 seconds orupon four consecutive losses in the implementation.

151


7/12

OptionRTS

...

RRAA

ChangeRate new rate

AdaptiveRTS Filter

LossEstimation

802.11 MAC

Send

Software

Hardware

Queue

LinklayerRetx

CSMA

PHY

feedback

Figure 5: Modules and interactions in RRAA.

Robust against random loss: The design should main-tain stable rate behavior and throughput performancein the presence of mild, random channel variations.

Responsive to drastic channel changes: The algorithmshould respond quickly to significant channel changes.Specifically, we want the design to be highly respon-sive in the following two scenarios: (a) The algorithmis able to quickly track the rate decrease/increase as-sociated with the channel change, when the channelquality deteriorates/improves as a mobile user walksaway/towards the AP. (b) The algorithm is able to re-spond properly in the presence of severe channel degra-dation induced by interfering sources, e.g., hidden ter-minals due to other 802.11 devices, and sources such asmicrowaves and cordless phones operating in the samefrequency band.

While the existing algorithms may achieve certain aspectsof the above goals, they are unable to achieve all of them.

The design of RRAA is based on two novel ideas. First, ituses short-term loss ratio to assess the channel and oppor-tunistically adapt the runtime transmission rate to dynamicchannel variations. Second, it leverages the RTS option inan adaptive manner to filter out collision losses with smalloverhead. As shown in Figure 5, RRAA consists of threeclosely interacting modules:

Loss Estimation: It assesses the channel condition bykeeping track of the frame loss ratio within a shorttime window (5 40 frames in our implementation).

Rate Change: It decides whether to increase, decrease,or retain the rate based on the estimated loss ratio.

Adaptive RTS Filter: It selectively turns on RTS/CTSexchange to suppress collision losses, and adapts thenumber of RTS-protected frames to the collision level.

We next describe the loss estimation and rate change design

in Section 5.1, then the adaptive RTS filter in Section 5.2,and finally their integration in Section 5.3.

5.1 Loss Estimation and Rate ChangeTo ensure standard compatability, RRAA uses only the

link-layer information of frame successes or losses in decidingthe transmission rate. However, unlike existing link-layer-based rate adapatation algorithms [1, 2, 8], RRAA neveruses probe packets to assess possible new rates. Instead,RRAA always adjusts the rate based on the frame loss ratioover the previous short-term time window. Compared to

1 R=highest_rate;2 counter=ewnd(R);3 while true do4 rcv_tx_status(last_frame);5 P = update_loss_ratio();6 if( counter == 0 )7 if (P > PMTL) then R = next_lower_rate();9 elseif (P < PORI) then R = next_high_rate();10 counter = ewnd(R);11 send(next_frame,R);12 counter--;

Figure 6: Loss estimation and rate change in RRAA-

BASIC.

a probe frame which either succeeds or fails, the loss ratioover many transmission samples provides more dependableinformation to estimate the rate. As a result, the rates se-lected by RRAA are highly robust to the random channellosses.

The loss estimation and rate change algorithm in RRAAis illustrated in Figure 6, which we refer to as RRAA-BASICin this paper. In RRAA-BASIC, each rate is associated withthree parameters: an estimation window size, a MaximumTolerable Loss threshold (MTL), and an Opportunistic Rate

Increase threshold (ORI). We will describe in Sections 5.1.1and 5.1.2 how these parameters are chosen to select the bestrate. For simplicity, we first assume identical lengths for allframes, then relax this assumption in Section 5.1.3.

The algorithm starts with the highest rate (i.e., 54 Mbpsfor 802.11a/g or 11 Mbps for 802.11b), and adapts the trans-mission rate in the following manner. Whenever a new rateis chosen, it is used to transmit the next ewnd frames, whichwe call an estimation window. The loss ratio is estimatedbased on how many frames over this window are lost. Specif-ically, the runtime loss ratio is calculated as

P =# lost frames

# transmitted f rames(1)

where both numbers of lost frames and transmitted framesare counted over the window and include all re-tries. Whenthe window finishes, a new rate is chosen based on the es-timated loss ratio. As shown in Lines 7-11 of Figure 6, therate is decreased to the next lower one if the loss ratio islarger than PMTL. It is increased to the next higher one ifthe loss ratio is smaller than PORI . In these two cases, anew estimation window starts for the newly selected rate.However, if the loss ratio is between PMTL and PORI , thecurrent rate is retained, and the estimation window keepssliding forward, until the loss ratio of the most recent ewndframes leads to a rate change. Once the rate is changed, anew estimation window is started accordingly.

The intuition behind the above algorithm is that a suf-ficiently low (high) loss ratio indicates good (bad) channel

conditions, thus the rate should be increased (decreased) ac-cordingly. However, it is non-trivial to design a rate adapta-tion algorithm based on this seemingly simple idea. In par-ticular, the design must address two issues: (i) what are theloss ratio thresholds for rate increase and decrease ( PMTLand PORI ) respectively? and (ii) how long is the estimationwindow (ewnd)? We next address these two questions.

5.1.1 Loss Ratio Thresholds

In RRAA, the loss ratio thresholds are chosen such thatthe new rate can maximize the expected throughput in the

152


8/12

Rate Critical PORI PMTL ewnd(Mbps) Loss Ratio (%)

6 N/A 50.00 N/A 69 31.45 14.34 39.32 10

12 22.94 18.61 28.68 2018 29.78 13.25 37.22 2024 21.20 16.81 26.50 4036 26.90 11.50 33.63 4048 18.40 4.70 23.00 40

54 7.52 N/A 9.40 40

Table 3: RRAA implementation parameters for 802.11a.

next window. In short, when the loss ratio exceeds PMTL,the expected throughput at the current rate becomes lowerthan that at the next lower rate, thus the rate should bedecreased. On the other hand, when the loss ratio is belowPORI , the channel is very likely ready for higher rates, andthus the rate should be opportunistically increased.

We first consider PMTL, the threshold for rate decrease.Given a fixed frame size, we can assess the loss-free through-put at different rates, then define a critical loss ratio as fol-lows. For any rate R other than the base rate out of the

multiple rate options, let the next lower rate be R. Thecritical loss ratio P for R is defined as:

P(R) = 1T hroughput(R)

T hroughput(R)= 1

tx time(R)

tx time(R)(2)

That is, with a loss ratio of P, the goodput at R becomesthe same as the loss-free goodput at R. In other words,one should not tolerate a loss ratio larger than P(R) atrate R to maximize goodput, assuming the channel becomeslossless when the rate drops. However, given that the lossratio at R is likely non-zero in practice, we choose PMTL =P(R), where 1 is a tunable parameter, to anticipatecertain level of losses at R.

Equation (2) also tells us that, given the transmission rateand the frame size, the throughput can be calculated basedon the transmission time, which includes all PHY and MACoverheads such as PHY preamble, SIFS, DIFS, slot time,ACK, and random backoff. In our implementation, we usethe minimum backoff in the calculation, which provides usthe maximum PMTL and optimistic rate decisions.

Next we explain how to set PORI , the threshold for rateincrease. The challenge here is the lack of a good method toestimate how the loss ratio changes when the rate increases.As a result, the design may suffer either from premature rateincrease (when the threshold is too high) or from missing theopportunity to switch to a higher rate (when the thresholdis too low). In our design, we use a simple heuristic thatsets PORI = PMTL(R

+)/, where PMTL(R+) is the PMTL

of the next higher rate. The rationale is that, the loss ratio

at the current rate R has to be small enough to make theconsequent rate increase stabilize at R+ and not quicklyjump back to R. This way, the algorithm will not keep onoscillating between R and R+. An illustrative example forthese two thresholds in 802.11a is shown in Table 3 with = 1.25 and = 2.

5.1.2 Estimation Window Size

The estimation window size ewnd is a critical parameterin RRAA that affects the accuracy of loss ratio estimation.It is well known in statistics that estimation based on a small

number of samples may significantly deviate from the actualvalue, due to randomness in the samples. This seems to ar-gue for the use of large estimation windows. However, asshown in Section 4, the channel condition may fluctuate alot as time evolves. Thus the loss ratio in a large window isless meaningful in guiding rate adaptation, as it is skewed byobsolete samples. This problem can be further exacerbatedwith multiple active stations, because the packets of one sta-tion are spread out due to channel contention (for upstream

traffic) or multiplexing at the AP (for downstream traffic).Our design balances the two conflicting needs of obtain-

ing meaningful statistics and avoiding obsolete information.Specifically, we count the window size by the number oftransmitted frames. Because our algorithm compares theloss ratio against PORI and PMTL, we first ensure 1ewnd 0) then

12 TurnOnRTS(next_frame);13 RTScounter--;

Figure 7: Adaptive RTS (A-RTS) filter in RRAA.

tation of [8], while other algorithms such as ARF, AARF,and ONOE assume the same frame size for all packets.

5.2 Adaptive RTS FilterTo be robust against hidden terminals, RRAA uses an

adaptive RTS filter to suppress collision losses when it esti-mates the loss ratio. The basic idea is to leverage the per-frame RTS option in 802.11 standards, and selectively turnon RTS/CTS exchange to suppress collision losses. While

RTS is well known as an effective means to handle hiddenterminals, the main challenge faced by our design is to de-cide when and how long RTS should be turned on or off.Design Options There are two straightforward designchoices to suppress hidden-station-induced losses. The firstone is to turn on RTS for every frame. However, the down-side is the excessive overhead of RTS/CTS exchange, whichcan be significant with high transmission rates. This is alsowhy RTS is disabled in most real-life 802.11 wireless net-works. Therefore, when RRAA decides to turn on RTS, thethroughput gain from better rate adaptation must outweighthe overhead of RTS.

The second choice is to turn on RTS upon a frame loss andturn off RTS upon a frame success. This is the design used inCARA [10] to handle a different problem of multi-client con-tention in a single collision domain. However, when hiddenterminals exist, it suffers from the drawback of RTS oscilla-tion, which alternates on and off for RTS. In the worst case,one of every two frames is lost, resulting in more than 50%throughput reduction. From the rate adaptation perspec-tive, the sender may still experience heavy collision lossesand eventually drop the data rates.Adaptive Scheme in RRAA As illustrated in Figure7, RRAA uses an adaptive RTS (A-RTS) scheme to adaptto the dynamic collision level incurred by hidden stations.The key state maintained by A-RTS is RTSwnd, the RTSwindow size within which all frames are sent with RTS on(the actual number of frames being sent with RTS on isrecorded by RT Scounter). RTSwnd is initially set as 0,

which disables RTS. It is then adapted to the estimated col-lision level as follows. When the last frame was lost withoutRTS, RTSwnd increments by one because the loss was po-tentially caused by collisions. However, when the last frametransmission was lost with RTS, or succeeded without RTS,RTSwnd is halved because the last frame clearly did notexperience collisions. When the last frame succeeded withRTS on, RTSwnd is kept unchanged. Note that RTSwndis an integer. When it is halved from the value 1, it becomes0 which disables RTS again. An example showing RTSwndevolution and RTS on/off schedule is illustrated in Figure 8.

0 0 00 0 00 0 01 1 11 1 11 1 1 0 00 00 01 11 11 1 0 00 00 01 11 11 1 0 00 01 11 1 DATARTSFrame transmitted

0 0 010 0 2 1

Loss

1 0 010 1 2 1RTSwnd

RTScounter

Figure 8: An example ofRTSwnd evolution.

1 while true do2 rcv_tx_status(last_frame);3 A-RTS();4 if(!RTSFail) then5 RRAA_BASIC();6 if(RTSWnd > 3) then7 fix_re_tx_rate();

Figure 9: The complete RRAA design: Integrating

RRAA-BASIC and A-RTS.

With A-RTS, more frames are sent with RTS on when col-lision losses are severe, as RTSwnd is gradually increasedby such losses. This not only protects the frame transmis-sions from collisions but also avoids the loss ratio estimation

being poisoned by the collision losses. On the other hand,when collision losses are mild or absent, RTSwnd is small(say 1 or 2) due to multiplicative decrease, and the overheadof RTS/CTS exchange is minimized. We will evaluate theeffectiveness of A-RTS via experiments in Section 6.

5.3 Integrating RRAA-BASIC and A-RTSWhile RRAA-BASIC and A-RTS address channel fluctu-

ations and hidden terminals respectively, one might thinkthat a simple combination of both algorithms would suffice.However, their coherent integration is actually non-trivialbecause RTS frames may also be lost due to collisions withthe hidden terminals.

Such RTS losses have dual impacts on rate adaptation.

First, when RTS fails, it is considered as a frame loss eventhough the data frame is not transmitted at all, which tendsto over-estimate the loss ratio. Second, the RTS losses willtrigger retries executed in the firmware of the Atheros/Agerechipset, which use rates lower than the one set by the soft-ware rate adaptation algorithm. Because an RTS frame ismuch smaller than a typical data frame, subsequent re-triesof RTS may still collide with the ongoing data transmissionof a hidden terminal. In the worst case, the data frame isdiscarded or transmitted at the base rate during the lastretry executed by the chipset firmware, regardless of the de-cisions made by the software rate adaptation.

As shown in Figure 9, RRAA addresses these two issuesby applying two checks in integrating RRAA-BASIC andA-RTS. First, a frame loss due to RTS failure is not counted

toward the loss ratio estimation. Secondly, when RTSwndin the A-RTS algorithm exceeds a threshold (3 in our ex-periments), which indicates severe collisions, we disable thefirmware rate adaptation. That is, the firmware is informedto fix the rate in the re-transmissions as specified by thesoftware rate adaptation module.

6. IMPLEMENTATION AND EVALUATIONIn this section, we describe our implementation effort and

154


10/12

evaluate the performance of RRAA, using both controlledexperiments and uncontrolled field trials.

6.1 ImplementationWe implement RRAA-BASIC and RRAA on a programmable

AP platform. We also import the implementation of threeother algorithms, namely ARF, AARF and SampleRate,into our platform for comparison purposes.

There are two non-trivial challenges that our implemen-tation must address. First, our AP platform avoids floating-point calculation, thus the runtime short-term loss ratio andthe associated two thresholds are not directly applicable.To address this issue, we count the number of lost frames,rather than to calculate the decimal loss ratio. Specifically,we maintain a counter to record the number of lost frameswithin the current estimation window, while the loss ratiothresholds are translated into the number of frame lossesbefore we load them into the AP.

Second, to filter out collision losses, RRAA needs to knowwhether a frame loss is incurred by RTS failures or by datatransmission errors after a RTS success. While the exact losstype may ultimately be available from the 802.11 chipsets,many existing systems do not use this information. In our

implementation, we develop a RTS failure detection tech-nique as follows. The key idea is that the transmission timeof a 20-byte RTS frame is much shorter than that of a typ-ical DATA frame. Thus by checking the time duration of atransmission, we can infer whether RTS has failed or not.

Specifically, we use the hardware feedback timestamps (ingranularity ofs) to approximate the time duration T1 spentby the current transmission, which includes all frame retries.In our system, we can extract the number of retries and thebackoff value used in each retry. This way, we can calculateT2 as the time spent to complete all frame retries withoutany RTS failure. If the difference between T1 and T2 ex-ceeds a threshold, we infer that a RTS failure has occurred.Note that this technique cannot detect the loss types withperfect accuracy due to unknown factors such as hardware

processing latency and carrier sensing time. However, ourexperiments have confirmed that it can detect the vast ma- jority of RTS failures in practice.

6.2 Performance EvaluationIn this section, we evaluate the performance of RRAA-

BASIC and RRAA using extensive experiments and fieldtrials. We compare them to three existing algorithms, i.e.,ARF, AARF and SampleRate, in various settings of staticclients, mobile clients, and hidden stations. The results showthat RRAA constantly outperforms other algorithms in allscenarios. Note that the performance of ARF, AARF andSampleRate fluctuates significantly across different scenar-ios.

6.2.1 Static Clients

We first evaluate RRAA and RRAA-BASIC in static set-tings where the AP and the clients remain stationary through-out the experiment. The goal is to assess how well these al-gorithms, as well as ARF, AARF, and SampleRate, respondto random channel losses. We p erform tests at five differ-ent locations, P1, P2, P3, P4, P5 of Figure 1, where thereceiving client perceives quite different channel conditionand transmission rate. We run b oth UDP and TCP, over802.11a and 802.11b channels. For the 802.11a tests, since

our system does not implement RTS over 802.11a channels,we only evaluate RRAA-BASIC. The result does not includeP5, since P5 is out of the 802.11a communication range.

Figures 10(a) and 10(b) show the goodput results on 802.11achannels for RRAA-BASIC, ARF, AARF, and SampleRateat four locations of P1P4, using UDP and TCP, respec-tively. In all cases, RRAA-BASIC always outperforms theother three algorithms. For the UDP case, its throughputgain ranges from 4.5% to 67.4% at these four locations. In

the TCP scenario, the throughput gain of RRAA-BASIC isbetween 10.3% and 45.3% compared with the worst of theother three algorithms.

To understand why RRAA-BASIC is better than othersin the static setting, we record the rate decision made byeach algorithm during the experiment. Figure 11 plots therate distribution at the sender when the client is locatedat spot P3. The figure shows that RRAA-BASIC trans-mits 79% of its packets at the rate of 24Mbps, while theother three algorithms send only 59%66% of packets atthis rate. Both ARF and AARF are too sensitive to ran-dom channel losses. Therefore, ARF and AARF sent around28% and 37% of packets at 18Mbps. Compared with ARFand AARF, RRAA-BASIC will not decrease its transmission

rate unless the loss ratio is greater than the threshold. Thisshows that RRAA-BASIC is more robust to random chan-nel losses. Our experiments at other locations also revealsimilar rate distributions.

The UDP throughput results for different algorithms atfive locations using 802.11b channels are plotted in Fig-ure 10(c). In general, RRAA-BASIC performs better thanRRAA because RRAA-BASIC never sends the probing RTSmessages by default. The maximum performance differencebetween RRAA and RRAA-BASIC is 4.6%, which happensat spot P5. However, RRAA still achieves 0.3%48.2%throughput gain compared with the other three algorithms.

Comparing Figures 10(a) and 10(c), we also make anotherinteresting observation. SampleRate works better than ARFand AARF in the 802.11b environments. This is because

SampleRate tolerates some random channel errors and doesnot drop to lower transmission rates as frequently as ARFand AARF. However, SampleRate performs worse than bothARF and AARF at spots P1 and P4 in 802.11a. P1 is theclosest location from the receiver to the AP sender. Thepoor performance of SampleRate at P1 is already explainedin Section 4.2. Our experiments show that SampleRatetransmits only 82% of its packets at 54Mbps, while all otheralgorithms transmit 99% of packets at this rate. The poorperformance of SampleRate at P4 can be explained by oneheuristic used by its implementation. Its implementation5

explicitly skips 9Mbps in its rate decisions. Therefore, Sam-pleRate only uses 12Mbps and 6Mbps at P4, while skip-ping the rate of 9Mbps for its packets. Unfortunately, mosttransmissions at 12Mbps have failed. In contrast, ARF andAARF send 50% of their packets at 9Mbps at P4, whileRRAA transmits 67% of data packets at 9Mbps.

6.2.2 Mobile Clients

We now compare RRAA and RRAA-BASIC with otheralgorithms ARF, AARF, and SampleRate, in the case ofclient mobility. While the static setting mainly assesses sta-bility and robustness of a rate adaptation algorithm, the

5We used the source code of MADWiFi dated on March 14,2006.

155


11/12

P1 P2 P3 P40

5

10

15

20

25

30

Receiver location

UDPgoodput(Mbps)

RRAABASIC

ARF

AARFSampleRate

4.5%

47.5%

28.2%

67.4%

(a) UDP goodput in 802.11a.

P1 P2 P3 P40

5

10

15

20

25

Recevier Location

TCP

Throughput(Mbps)

RRAABASICARF

AARFSampleRate

10.3%

45.3%

28.2%

33.5%

(b) TCP throughput in 802.11a.

P1 P2 P3 P4 P50

1

2

3

4

5

6

7

Receiver location

UDP

Goodput(Mbps)

RRAA

RRAABASICARFAARF

SampleRate

0.3% 7%41.9%

48.2%

23.5%

(c) UDP goodput in 802.11b.

Figure 10: TCP/UDP performance of ARF, AARF, SampleRate, RRAA-BASIC and RRAA. The numbers pointed

by arrows are performance gains of RRAA (in 802.11b) or RRAA-BASIC (in 802.11a) over the worst one.

ARF AARF SampleRate RRAA0

10

20

30

40

50

60

70

80

RateDistribution(%)

36Mbps

24Mbps

18Mbps

12Mbps

Figure 11:

0 1 2 3 4 5

ARF

AARF

SampleRate

BASICRRAA

RRAA

UDP Goodput (Mbps)

Figure 12:

ARF AARF SampleRate RRAA0

20

40

60

80

100

Ratedis

tribution(%)

UDPgo

odput(Mbps)

11 Mbps

5.5 Mbps

2 Mbps

1 Mbps

0.2

0

0.4

0.6

0.8

1.0

1.2

0.65 Mbps

1.13 Mbps

0.58 Mbps0.56 Mbps

Figure 13:Distribution of rates in each algorithm when

the receiver is located at P3 (802.11a).

UDP goodput in 802.11b with client

mobility.

UDP throughput and rate decision

distribution in the hidden-terminal case

(802.11b).

mobile setting gauges its responsiveness. The experimentalsetup is the same as the one we have described in Section

4.2.5.Figure 12 shows the average throughput of different algo-

rithms using UDP for the mobile client. We can see thatboth RRAA and RRAA-BASIC perform better than ARF,AARF, and SampleRate. The throughput improvementsof RRAA over ARF and SampleRate are about 10.0% and27.6%, respectively. This clearly demonstrates that RRAAis highly responsive to significant channel variations incurredby client mobility.

Another interesting observation is that SampleRate per-forms the worst out of all algorithms. In its implementation,SampleRate tries to limit the minimum duration betweensuccessive rate changes to be at least 2 seconds. In contrast,both ARF and AARF perform better because they have atimeout mechanism that results in probing the channel atleast once every 15 packets.

6.2.3 Setting with Hidden Terminals

In this experiment, we evaluate whether RRAA can quicklyinfer collision losses and adjust its rate accordingly in thepresence of hidden terminals. The experimental setting isthe same as the one described in Section 4.2.1.

Figure 13 plots the UDP goodput and the distributionof transmission rates for the four algorithms. The resultsshow that RRAA always performs the best. Its throughput

gain over SampleRate and AARF is about 101%, and itsgain over ARF is about 74%. We also observe that RRAA

sends 50% of its packets at 11Mbps, while ARF and AARFsend more than 85% of packets at 1Mbps and SampleRatetransmits about 42% of its packets at 1Mbps and 2Mbpseach. It is clear that ARF, AARF and SampleRate havereduced their rates to 12Mbps due to the collision lossesincurred by the hidden AP. In RRAA, we can differentiatemost of such losses from fading errors using the adaptiveRTS filter mechanism described in Section 5.

6.2.4 Field Trials

After we have gained insights on the pros and cons ofdifferent algorithms using controlled experiments, we finallyconduct a series of uncontrolled field trials over a two-dayperiod. The purpose is to understand how these algorithms

perform under realistic scenarios, in which various sourcesof dynamics co-exist in a complex manner.

Our first field trial involves static clients only. We run sixsets of experiments and each lasts an hour. The time spanis over 6 hours from 410pm. Each experiment uses fourstatic clients, two of them are located at spot P1, and theother two are placed at spot P2. A TCP connection is runfrom the AP sender to each receiver. We intentionally selectChannel 6, which is also used by other clients and APs in thesame building. During our experiments, the sniffer detectsabout 711 APs and 77151 clients over Channel 6. People

156


12/12

0

1

2

3

4

5

ARF AARF SampleRate RRAA

Aver

ageTCPThroughput(Mbps)

Static clients

Mobile client

Figure 14: TCP performance in field Trials.

are walking in the corridor, stepping into and out of offices,and even turning on microwaves during the experiments.

Figure 14 shows the experimental results with static clientsin the first field trial. The throughput gain of RRAA overSampleRate is 3.8% on average, and the gain increases to15.3% over ARF. In all cases, RRAA outperforms the otherthree algorithms.

We also conduct another field trial using the mobile set-ting presented earlier in Section 4.2.5, except that we useChannel 6 during the 6-hour trial. As the client movesaround, it apparently experiences hidden terminals once awhile, due to other APs and active clients on Channel 6.Figure 14 gives the throughput of different algorithms. Theresults show that, RRAA achieves throughput improvementof 35.6% over SampleRate and 143.7% over ARF during eachone-hour experiment.

7. RELATED WORKRate adaptation has been an active research topic in re-

cent years and a number of algorithms [1, 2, 3, 4, 5, 6, 7, 8,9, 10, 12] have been proposed. It is one of the few algorithmsthat are left to the vendors by the IEEE 802.11 standard,yet its design is critical to the overall system performance.Most existing algorithms follow the design guidelines iden-tified in Section 4. They do not address all the robustnessissues against random channel loss, mobility, and hidden-terminal-induced contention loss. Therefore, they do notwork well and suffer from performance penalties in realisticsettings with mobile clients, static clients with lossy chan-nels, or hidden clients/APs.

The two components in RRAA bear superficial similarityto some existing designs but have fundamental differencesfrom them. The loss ratio threshold-based scheme seemssimilar to the one used in ONOE [12]. However, ONOE

uses long-term estimation (i.e. 1 second), while RRAA usesshort-term metrics to exploit the opportunistic gain asso-ciated with transient channel dynamics. In addition, thethreshold values in ONOE are set in a rather ad hoc man-ner, while RRAA computes its thresholds based on the ex-pected cost and gain associated with the rate changes. TheRTS mechanism is also used in CARA [10]. However, CARAseeks to solve a different problem of multiple clients contend-ing for the same AP over wireless LANs. Because CARAdid not intend to address rate adaptation in hidden-terminalsettings, its design is much simpler than the adaptive RTS

filter in RRAA and suffers from RTS oscillation with hiddenstations. Moreover, CARA is designed on top of ARF, thusinheriting the drawbacks of ARF.

8. CONCLUSIONRate adaptation offers an effective means to facilitate sys-

tem throughput improvement in 802.11-based wireless net-works by exploiting the physical-layer multi-rate option upon

dynamic channel conditions. In this paper, we have cri-tiqued on five design guidelines for existing algorithms, andproposed a new Robust Rate adaptation Algorithm (RRAA).The key insight learned is that the rate adaptation algo-rithm has to infer different loss behaviors and take adap-tive reactions accordingly. We have implemented RRAA ona programmable AP platform and compared it with threeother popular algorithms of ARF, AARF, and SampleR-ate. Through extensive experiments, we demonstrate thatRRAA consistently outperforms all these algorithms, andimproves throughput by up to 35.6% over SampleRate andby up to 143.7% by ARF in field trials. We believe thatour solution will benefit the widely-deployed 802.11-basedWLANs as well as the emerging mesh networks.

9. ACKNOWLEDGMENTSWe appreciate the constructive comments by our shep-

herd, Dr. Edward Knightly and the anonymous reviewers.We also thank Dr. Songchun Zhu, Mr. Jerry Cheng andMr. Xiaoqiao Meng for many helpful discussions.

10. REFERENCES[1] A. Kamerman and L. Monteban. WaveLAN II: A

high-performance wireless LAN for the unlicensed band. BellLabs Technical Journal, Summer 1997.

[2] M. Lacage, M. H. Manshaei, and T. Turletti. IEEE 802.11Rate Adaptation: A Prac tical Approach. ACM MSWiM, 2004.

[3] G. Holland, N. Vaidya, and V. Bahl. A Rate-Adaptive MACProtocol for Multihop Wireless Networks. ACM MOBICOM,2001.

[4] B. Sadeghi, V. Kanodia, A. Sabharwal, and E. Knighlty.Opportunistic Media Access for Multirate Ad Hoc Networks.ACM MOBICOM, 2002.

[5] D. Qiao, S. Choi, and K. Shin. Goodput Analysis and LinkAdaptation for IEEE 802.11a Wireless LANs. IEEE TMC,1(4), October 2002.

[6] I. Haratcherev, K. Langendoen, R. Lagendijk and H. Sips.Hybrid Rate Control for IEEE 802.11. ACM MobiWac, 2004.

[7] I. Haratcherev, K. Langendoen, R. Lagendijk and H. Sips. Fast802.11 Link Adaptation for Real-time Video Streaming byCross-Layer Signaling. ISCAS, 2005.

[8] J. Bicket. Bit-rate Selection in Wireless Networks. MITMasters Thesis, 2005.

[9] D. Qiao and S. Choi. Fast-responsive Link Adaptation forIEEE 802.11 WLANs. IEEE ICC, 2005.

[10] J. Kim, S. Kim, S. Choi, and D. Qiao. CARA: Collision-awareRate Adaptation for IEEE 802.11 WLANs. IEEE INFOCOM,2006.

[11] S. Choi, K. Park, and C. Kim. On the PerformanceCharacteristics of WLANs: Revisisted. ACM SIGMETRICS,2005.

[12] Onoe Rate Control.

http://madwifi.org/browser/trunk/ath rate/onoe.[13] D. Aguayo, J. Bicket, S. Biswas, G. Judd, and R. Morris.

Link-Level Measurements from an 802.11b Mesh Networks.ACM SIGCOMM, 2004.

[14] Iperf v2.0.2. http://dast.nlanr.net/Projects/Iperf/.

[15] AiroPeek v2.0. http://www.wildpackets.com/.

[16] Thomas M. Cover, Joy A. Thomas. Elements of InformationTheory. John Wiley & Sons, 1991.

[17] Multiband Atheros Driver For WIFI. http://madwifi.org/.

157

Documents

RRAA algoritmo