1

How to apply Adaptation principle: case study in 802.11

2

How to apply adaptation??

• Roadmap of a successful adaptive solution– What to adapt to? → problem space– How to adapt? → solution– How well it can adapt ? → evaluation

3

Steps

• What should an adaptive solution adapt to?– Identify all possible scenarios

• How to adapt ?– Handle different scenarios one by one

• How to evaluate the solution?– Evaluations that can accurately reflect normal

usage

4

Case study: Rate Adaptation in 802.11

• What to adapt to?– Identify all possible scenarios

• How to adapt ?– Handle all possible scenarios accordingly

• How to evaluate?

5

What is Rate Adaptation?

• The PHY-layer transmission rate is adjusted to the channel condition in real-time

Sender Receiver

54MbpsSignal is goodSignal becomes weaker

12Mbps

6

IEEE 802.11 Rate Adaptation

• Discrete PHY rate options in the standard– 802.11b, 4 rate options

– 802.11a, 8 rate options

– 802.11g, 12 rate options

• Unspecified by the 802.11 standards– Vendors have freedom

7

Why Rate Adaptation?

• Better exploit the PHY multi-rate capability

• Rate adaptation affects the throughput performance!

– Rate too high → loss ratio increases → throughput decreases – Rate too low → under-utilize the capacity → throughput

decreases

8

Step 1: What to adapt?

• Identify different channel conditions– #1: Collision loss (hidden terminal, contention)– #2: Non-collision losses:

• #1: random channel error• #2: mobility loss

9

Existing Solutions?

• Performance-driven solutions– 802.11 Standard compliant

• ARF, AARF, SampleRate, Onoe, AMRR, CARA, …

– Non-Standard compliant• RBAR, OAR, etc.

• Can they adapt to all scenarios ?– Work well in some cases– Not so well in other cases

10

Design Guidelines in Existing Rate Adaptation

• Examine 10+ existing algorithms

• Performance-driven guidelines1. Decrease rate upon severe loss2. Use deterministic success/loss patterns3. Use long-term statistics4. Use probe packets5. Use PHY-layer metrics

• Can they adapt well in all cases?

11

Guideline #1: Decrease transmission rate upon severe packet loss

ARF AARF SampleRate Fixed Rate

UDP Goodput (Mbps)

0.65 0.56 0.58 1.46

SenderReceiverHiddenStation

A sender should switch to lower rates when it faces severe loss

Logic: severe loss indicates bad channel

hidden-station case?

The sender performs worse with Rate Adaptation!

12

• The sender should not decrease the rate upon collision losses– Decreasing rate increases collisions !

Guideline #1: Decrease transmission rate upon severe packet loss

Severeloss

DecreaseTx

rateIncrease

Txtime

Increasecollision

Prob.

Fail to handle hidden-station!

13

Guideline #2: Use deterministic patterns to increase/decrease rate

• Case 1: 10 consecutive successes → increase rate– ARF, AARF

48Mbps

54Mbps

increase rate!

14

Guideline #2: Use deterministic patterns to increase/decrease rate

– The probability of a success transmission followed by 10 consecutive successes is only 28.5%

• Result: The rule has 71.5% chance to fail!

28.5%

15

Guideline #2: Use deterministic patterns to increase/decrease rate

• Case 2: 2 consecutive failures → decrease rate– ARF, AARF

54Mbps

48Mbps

36Mbps

16

Guideline #2: Use deterministic patterns to increase/decrease rate

– The probability of a failure transmission followed by 2 consecutive failures is only 36.8%

• Result: The rule has 63.2% chance to fail!

36.8%

Fail to handle random channel loss!

17

Guideline #3: Long-term statistics produces the best average performance

• Example: Use 10 seconds as sampling period– ONOE, SampleRate

• ONOE Performance

Fail to handle short-term channel variations (include mobility)!

18

Design guidelines (cont’d)

• Other guidelines:– #4: Use probe packets to assess possible new rates– #5: Use PHY metrics like SNR to infer new

transmission rate

• None of them can handle all possible scenarios

19

Step 2: How to adapt?

RRAA solution components:

• Loss Estimation – Short-term statistics– Handle

• random loss• mobility

• Adaptive RTS – Infer collision level– Handle

• collision

Software

Hardware

PHYfeedba

ck

802.11 MAC

AdaptiveRTS

Loss EstimationRate Selection send

RTSOption

RRAA

20

Loss Estimation

• Short-term statistics: – Loss ratio over short estimation window (20~100ms)

– Channel coherence time

– Exploit short-term opportunistic gain

• Threshold-based rate change:– if loss ratio > PMTL → rate decrease

– if loss ratio < PORI → rate increase

– Otherwise, retain the current rate and continue sliding window

21

Illustrative Example• For 9Mbps

– ewnd = 10, PMTL = 39.32%, PORI = 14.34%

s s s s s s s X s s

s X s X X s s Xs

s s X X s s s s s X

1 failure, loss ratio = 10%Increase rate

4 failures, loss ratio = 40%decrease rate

3 failures, loss ratio = 30%Rate unchanged

s

s

s

s

1.Robust to random channel loss- No deterministic pattern

2.Responsive to mobility- Short estimation window

How to set these thresholds? (see Mobicom’06)

22

RTS/CTS Background

• Short control messages to protect lengthy data tx.

• RTS-CTS makes the yellow node back off during DATA-ACK Transmission

RTS

CTS

Data

Ack

Step 1:

Step 2:

Backoff

a b c

a b c

23

Adaptive RTS

• Use RTS to handle collisions– Tradeoff between overhead and benefits of RTS

• Infer collision level– (1) Packet loss without RTS

• Possibly due to collisions• Additively increase # of packets sent with RTS

– (2) success without RTS, or (3) packet loss with RTS• Most likely no collisions, or RTS doesn’t help• Exponentially decrease # of packets sent with RTS

24

Illustrative Example

RTScounter RTSwnd

0 0

DATA1 1

0 1DATA

2 2

1 1

0 1

0 0

0 0

DATA

DATA

DATA

DATA

DATA

No collision

No collision

Collision may occur

Collision may occur

More packets are sent with RTS if the collision level is high

25

Implementation

• Programmable AP using with embedded OS– Real-time tracing and

feedback, per-frame control functionalities, etc

26

Implementation Challenges

• No floating point calculation in embedded AP– Translate increase/decrease thresholds to packet

count

• No explicit signal for RTS loss– Check time duration of transmission

• Transmission time of a RTS frame is much shorter than that of a typical DATA frame

27

Step 3: Evaluate adaptation

• Experimental Setup– Controlled experiments:

• Midnight over clear channels on 11a/g

– Field Trials:• 4pm - 10pm weekdays in campus buildings, Channel 6, 7~11

other APs, 77~151 other clients, people walking around• Enterprise setting

– Stationary clients, mobile clients, hidden terminals

• Comparison with 4 other algorithms– ARF, AARF, SampleRate, Cisco

28

Field Trials

• Campus Environment– Compare with ARF, AARF, SampleRate– With realistic flow models– Results

• Statistic clients: will put later• Mobile clients: will put later

• Enterprise setting– Compare with Cisco AP– Results:

• Average 70%, range 32.6%~212.3%

29

Summary

• Existing adaptive solutions tend to optimize performance in some scenarios, but overlooked others– Adaptation has to be done in the right form at the right

time in the right way

• Need to identify all possible scenarios before develop a solution

30

Another look at Step 3

• How well can it adapt?– Do existing evaluation approaches accurate

enough over time ?

31

Revisiting wireless traffic flows

• A flow is a stream of packets– i.e. TCP flows (~90% of traffic) Internet

32

Findings

• Wireless traffic behaviors can be well captured by existing modeling approaches– But parameters also change over time !

• Flow models need to be updated over time– Wireless networks are evolving over time– Study the evolution help us to understand better

33

Lesson Learnt

• Adaptations need to be used in correct way– Before develop a solution, we need to know “what to

adapt to”– Otherwise it may hurt the performance

• Evaluation plans need to be updated over time– Static setting does not work– Outdated dynamic setting does not work too