How to apply Adaptation principle: case study in 802.11

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. 54Mbps Signal is good Signal becomes weaker Receiver What is Rate Adaptation? 12Mbps Sender • The PHY-layer transmission rate is adjusted to the channel condition in real-time

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 guidelines • Decrease rate upon severe loss • Use deterministic success/loss patterns • Use long-term statistics • Use probe packets • Use PHY-layer metrics • Can they adapt well in all cases?

11. Guideline #1: Decrease transmission rate upon severe packet loss • A sender should switch to lower rates when it faces severe loss • Logic: severe loss indicates bad channel • hidden-station case? Hidden Station Receiver Sender The sender performs worse with Rate Adaptation!

12. Decrease Tx rate Increase Tx time Severe loss Increase collision Prob. Guideline #1: Decrease transmission rate upon severe packet loss • The sender should not decrease the rate upon collision losses • Decreasing rate increases collisions ! Fail to handle hidden-station!

13. Guideline #2: Use deterministic patterns to increase/decrease rate • Case 1: 10 consecutive successes → increase rate • ARF, AARF increase rate! 54Mbps 48Mbps

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! Fail to handle random channel loss! 36.8%

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 802.11 MAC RRAA Loss Estimation Rate Selection send Adaptive RTS RTS Option feedback Hardware PHY

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% • Robust to random channel loss • - No deterministic pattern • Responsive to mobility • - Short estimation window 1 failure, loss ratio = 10% Increase rate s s s s s s X s s s s 4 failures, loss ratio = 40% decrease rate s s X s X s X X s s s 3 failures, loss ratio = 30% Rate unchanged s s X X s s s s s X s How to set these thresholds? (see Mobicom’06)

22. RTS Data CTS Ack RTS/CTS Background Step 1: • Short control messages to protect lengthy data tx. • RTS-CTS makes the yellow node back off during DATA-ACK Transmission a c b Step 2: Backoff a c b

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. 1 1 0 1 2 2 1 1 0 1 0 0 No collision No collision 0 0 Collision may occur Collision may occur Illustrative Example RTScounter RTSwnd 0 0 DATA DATA DATA DATA DATA DATA DATA 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