1 / 33

How to apply Adaptation principle: case study in 802.11

How to apply Adaptation principle: case study in 802.11. 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. Steps. What should an adaptive solution adapt to?

oistin
Download Presentation

How to apply Adaptation principle: case study in 802.11

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related