On the Need for Efficiency in the 802.11 QoS Solution Month 2000 doc.: IEEE 802.11-00/xxx January 2001 On the Need for Efficiency in the 802.11 QoS Solution Author: Matthew Sherman AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 973-236-6791 mjsherman@att.com Date: January 16, 2001 Matthew Sherman, AT&T Labs - Research John Doe, His Company

January 2001 Some Observations 802.11e must compete in the market space with other solutions such as HIPERLAN/2 The performance of HIPERLAN/2 and other competing standards have “set the bar” for the performance goals of the 802.11e committee The committee should use these bars (in part) to determine if the performance level provided by 802.11e is sufficient to compete in the marketplace with other solutions Matthew Sherman, AT&T Labs - Research

Existing Comparisons of HIPERLAN/2 and IEEE802.11a January 2001 Existing Comparisons of HIPERLAN/2 and IEEE802.11a Currently aware of only one publicly available comparison Hui Li, Göran Malmgren, and Mathias Pauli, "Performance Comparison of the Radio Link Protocols of IEEE802.11a and HIPERLAN/2," IEEE VTS Fall VTC 2000. 52nd, Volume: 5, pages 2185-2191 Will refer to article as [HIPERLAN] in these slides Comparison only considers 802.11a DCF No known implementations of PCF with 802.11a Article claims HIPERLAN/2 superior to 802.11a in throughput provided to the user Delay Packet Error Rate (PER) Matthew Sherman, AT&T Labs - Research

Questions to Ask Is the analysis presented in [HIPERLAN] correct? January 2001 Questions to Ask Is the analysis presented in [HIPERLAN] correct? Is the analysis presented in [HIPERLAN] relevant? What additional simulations / analysis can be done comparing 802.11a and HIPERLAN? What modifications should be done as part of 802.11e to improve the performance of 802.11 in the comparisons? Matthew Sherman, AT&T Labs - Research

Considerations for Further Evaluation and Analysis January 2001 Considerations for Further Evaluation and Analysis Simulation model of HIPERLAN/2 not publicly available Extensive effort would be required to build HIPERLAN/2 model for simulation (not practical) Also would need to code appropriate scenarios Limits validation of data presented Some of the data presented in the article is analytical This can be validated and extended without much effort Matthew Sherman, AT&T Labs - Research

Approach to Analysis Consider relevance of data to real life January 2001 Approach to Analysis Consider relevance of data to real life Validate [HIPERLAN] numbers not requiring Sims Limits consideration to channel efficiency Extend analysis for PCF Extend analysis further to evaluate effect of key protocol changes Use for guidance in recommended enhancements for 802.11e Matthew Sherman, AT&T Labs - Research

Scenario Considered Only one scenario considered January 2001 Scenario Considered Only one scenario considered One BSS One AP One STA No contention FTP from Network (AP) to STA TCP/IP & Ethernet run “above” MAC Fixed FTP packets (512, 1024, 1500) Article posed complex PHY and Channel model Not relevant to overhead calculations Not included in analysis Matthew Sherman, AT&T Labs - Research

Relevance of Scenario Very simple, but probably relevant January 2001 Relevance of Scenario Very simple, but probably relevant Web-surfing most likely application Mostly focused on the downlink For channel efficiency and Web-surfing okay In real life many occurances where only two terminals are communicating Home applications and lightly loaded office WLAN 00/196R2 cites bulk data mix on slide 11 Average size of packet in mix is 452 byte Implies 512 byte packet size is most relevant for bulk data Overhead translate to user experience Lowest overhead produces highest performance Matthew Sherman, AT&T Labs - Research

Definitions of Overhead / Efficiency January 2001 Definitions of Overhead / Efficiency Channel Efficiency is defined as time channel is occupied by actual data divided by total time required to successfully transfer data Fraction of time channel actually occupied by data See example on following page Channel Overhead = (1 - Channel Efficiency) Overhead accounted MAC Overhead PHY Overhead See [HIPERLAN] paper for exact equations Following example gets same answer with simpler equations Matthew Sherman, AT&T Labs - Research

Example 802.11a Overhead Calc* January 2001 Example 802.11a Overhead Calc* Last Transmission 28 Byte Header 512 Byte MSDU DIFS Backoff POH+ MPDU @ 54 MBPS SIFS POH ACK @ 6 MBPS Duration in microsec 34 68 Avg. 20 80 16 20 24 MPDU efficiency = MPDU time / Total time = 80/(34+67.5+20+80+16+20+24) = 80/261.5 = .305 MSDU efficiency = MSDU size / (MSDU + Header) size =512/(512+28) = .948 Overall efficiency = MPDU efficiency * MSDU efficiency = .31*.948 = 0.290 “Overhead” = 1- .294 = 0.710 (0.708 in spreadsheet without rounding) + POH = PHY Overhead (PLCP Preamble & Signal). Approximations made include that the service, tail, and pad bits are not represented. MPDU is not rounded up to nearest 4 microsecond boundary. * Analysis closely follows that in [HIPERLAN]. Key differences, HIPERLAN set MAC header at 34 bytes and used 72 as average value of backoff. Values shown roughly rounded to nearest microsecond. Note that calculation of HIPERLAN overhead is similar but different since concept of “Frame” differs Matthew Sherman, AT&T Labs - Research

January 2001 Relevance of Example HIPERLAN claims channel efficiency of roughly 0.76 independent of packet size and rate Author has no expertise in HIPERLAN so can’t thoroughly check claims Did check arithmetic in paper which is correct HIPERLAN / 802.11 efficiency = 2.5 802.11 feels like 15.7 MBPS HIPERLAN/2 feels like 41 MBPS Implies that all other things being equal, for this scenario HIPERLAN user feels like he has two and a half times as much throughput as 802.11 user. Matthew Sherman, AT&T Labs - Research

Normalized Overhead for given packet size (Bytes) January 2001 DCF Results Modulation Code Rate PHY Rate (MBPS) Normalized Overhead for given packet size (Bytes) 512 1024 1500 BPSK 1/2 6 0.241 0.138 0.098 3/4 9 0.31 0.184 0.134 QPSK 12 0.367 0.226 0.166 18 0.458 0.298 0.225 16-QAM 24 0.525 0.357 0.275 36 0.62 0.451 0.359 64-QAM 2/3 48 0.683 0.52 0.426 54 0.708 0.549 0.454 Situations where HIPERLAN out performs 802.11a Situations where 802.11a out performs HIPERLAN Matthew Sherman, AT&T Labs - Research

Redo of Analysis for PCF January 2001 Redo of Analysis for PCF No PCF currently available for 802.11a At least to author’s knowledge If it were available, what would effect be? Matthew Sherman, AT&T Labs - Research

Downlink PCF Overhead Calc* January 2001 Downlink PCF Overhead Calc* Last Transmission 28 Byte Header 512 Byte MSDU DIFS Backoff POH+ MPDU @ 54 MBPS SIFS POH ACK @ 6 MBPS Duration in microsec 34 68 Avg. 20 80 16 20 24 DIFS + Backoff (122) becomes SIFS (16) Overhead reduced by 106 microseconds 28 Byte Header Last Transmission 512 Byte MSDU SIFS POH+ MPDU @ 54 MBPS SIFS POH ACK @ 6 MBPS Duration in microsec 16 20 80 16 20 24 * Uplink would use a CF_Poll or CF_Poll+Ack rather than Ack and overall performance should be similar to downlink Matthew Sherman, AT&T Labs - Research

PCF (Downlink) Results January 2001 PCF (Downlink) Results Modulation Code Rate PHY Rate (MBPS) Normalized Overhead for given packet size (Bytes) 512 1024 1500 BPSK 1/2 6 0.162 0.089 0.062 3/4 9 0.208 0.117 0.083 QPSK 12 0.250 0.143 0.103 18 0.321 0.192 0.139 16-QAM 24 0.379 0.235 0.173 36 0.471 0.309 0.234 64-QAM 2/3 48 0.539 0.370 0.286 54 0.566 0.396 0.31 Situations where HIPERLAN out performs 802.11a Situations where 802.11a out performs HIPERLAN Matthew Sherman, AT&T Labs - Research

Consideration of No Ack and Delayed Ack January 2001 Consideration of No Ack and Delayed Ack No Ack implies no Ack required for frame Delayed Ack allows group of frames to be acknowledged at once For Delayed Ack have assumed that every 16th frame delivered, sender requests Ack Ack would indicate for last 16 frames which were received Otherwise data frame would indicate no Ack required Assume new Ack policy implemented without effect to current Data frame / Ack frame size Matthew Sherman, AT&T Labs - Research

DCF 802.11a with No ACK January 2001 Last Transmission 28 Byte Header 512 Byte MSDU DIFS Backoff POH+ MPDU @ 54 MBPS SIFS POH ACK @ 6 MBPS Duration in microsec 34 68 Avg. 20 80 16 20 24 SIFS+POH+ACK Eliminated Overhead reduced 60 microseconds Last Transmission 28 Byte Header 512 Byte MSDU DIFS Backoff POH+ MPDU @ 54 MBPS Duration in microsec 34 68 Avg. 20 80 Matthew Sherman, AT&T Labs - Research

Normalized Overhead for given packet size (Bytes) January 2001 DCF with No ACK Results Modulation Code Rate PHY Rate (MBPS) Normalized Overhead for given packet size (Bytes) 512 1024 1500 BPSK 1/2 6 0.202 0.113 0.080 3/4 9 0.261 0.151 0.108 QPSK 12 0.312 0.185 0.135 18 0.395 0.247 0.183 16-QAM 24 0.460 0.300 0.226 36 0.556 0.386 64-QAM 2/3 48 0.622 0.453 0.362 54 0.649 0.481 0.388 Situations where HIPERLAN out performs 802.11a Situations where 802.11a out performs HIPERLAN Matthew Sherman, AT&T Labs - Research

DCF with Delayed ACK Results* January 2001 DCF with Delayed ACK Results* Modulation Code Rate PHY Rate (MBPS) Normalized Overhead for given packet size (Bytes) 512 1024 1500 BPSK 1/2 6 0.205 0.115 0.081 3/4 9 0.264 0.153 0.11 QPSK 12 0.315 0.188 0.137 18 0.399 0.25 0.186 16-QAM 24 0.464 0.303 0.229 36 0.56 0.39 0.304 64-QAM 2/3 48 0.626 0.457 0.366 54 0.652 0.486 0.392 * Averages performance for 15 frames without Ack, and 1 frame with Ack. Assume Ack frames same size as before. (Omit’s sequence field and Ack map - a minor additional overhead) Matthew Sherman, AT&T Labs - Research

PCF 802.11a with No ACK January 2001 Last Transmission 28 Byte Header 512 Byte MSDU DIFS Backoff POH+ MPDU @ 54 MBPS SIFS POH ACK @ 6 MBPS Duration in microsec 34 68 Avg. 20 80 16 20 24 DIFS + Backoff (122) becomes SIFS (16) SIFS+POH+ACK (60) Eliminated Overhead reduced by 166 microseconds Last Transmission 28 Byte Header 512 Byte MSDU SIFS POH+ MPDU @ 54 MBPS Duration in microsec 16 20 80 Matthew Sherman, AT&T Labs - Research

Normalized Overhead for given packet size (Bytes) January 2001 PCF with No ACK Results Modulation Code Rate PHY Rate (MBPS) Normalized Overhead for given packet size (Bytes) 512 1024 1500 BPSK 1/2 6 0.115 0.061 0.043 3/4 9 0.144 0.078 0.054 QPSK 12 0.170 0.093 0.066 18 0.219 0.124 0.088 16-QAM 24 0.263 0.152 0.109 36 0.336 0.203 0.148 64-QAM 2/3 48 0.397 0.248 0.184 54 0.423 0.269 0.201 Situations where HIPERLAN out performs 802.11a Situations where 802.11a out performs HIPERLAN Matthew Sherman, AT&T Labs - Research

PCF with Delayed ACK Results* January 2001 PCF with Delayed ACK Results* Modulation Code Rate PHY Rate (MBPS) Normalized Overhead for given packet size (Bytes) 512 1024 1500 BPSK 1/2 6 0.118 0.063 0.044 3/4 9 0.148 0.080 0.056 QPSK 12 0.175 0.097 0.068 18 0.226 0.128 0.091 16-QAM 24 0.270 0.157 0.113 36 0.345 0.210 0.154 64-QAM 2/3 48 0.406 0.256 0.191 54 0.432 0.277 0.208 * Averages performance for 15 frames without Ack, and 1 frame with Ack. Assume Ack frames same size as before. (Omit’s sequence field and Ack map - a minor additional overhead) Matthew Sherman, AT&T Labs - Research

Playing “Devil’s Advocate” January 2001 Playing “Devil’s Advocate” [HIPERLAN] analysis did not consider overhead on TCP Ack Difference only applies to 802.11 data Difficult to Analyze TCP Ack for 802.11 TCP Ack backoff occurs at same time TCP Data backoff Increase channel efficiency Two terminals may still collide Reduces channel efficiency No collision accounted in current analysis Not clear if channel efficiency goes up or down In the end, most of traffic should be downlink for Web surfer, so believe current analysis relevant Matthew Sherman, AT&T Labs - Research

Reminder Taken From IEEE 802.11-00245r1 January 2001 Reminder Taken From IEEE 802.11-00245r1 “ 3. QoS Requirements 3.1. Corrections and enhancements to the PCF that may be required to best meet QoS performance objectives must be incorporated. 3.2. Differential handling of MSDUs supplied to the MAC with additional priorities and classes of service. 3.3. Bounded delay, prioritized acess, and bounded latency per MDSU (allocatable services), power management bypass mechanisms (which has priority in iBSS and BSS may need a mechanism for separable handsets). 3.4. MAC SAP support for 802.1D/802.1q. 3.5. Support for multiple simultaneous streams with differing priority and class requirements. 3.6. Transmit Power Control. 3.7. To provide the hooks in the MAC to obtain remote channel information. ” Matthew Sherman, AT&T Labs - Research

Personal Comments and Conclusions January 2001 Personal Comments and Conclusions As service provider, would be uncomfortable deploying DCF only solution Efficiency issue very important to AT&T Might opt for HIPERLAN if not addressed Existence of current level 1 gives an easy out for equipment providers PCF option in current standard not deployed since largely not supported EPCF is critical for providing EFFICIENT QoS Regardless of DCF enhancements, support for EPCF should be mandatory for all QoS Solutions Includes EAP Matthew Sherman, AT&T Labs - Research

Comments To Publicity Task Group January 2001 Comments To Publicity Task Group Analysis would be better if more “Holistic” Should include back link Tradeoff of efficiency with other parameters such as End to End Delay and Jitter Technical Articles apparently exist professing advantages of HIPERLAN/2 over 802.11 Have not seen similar articles for 802.11 over HIPERLAN/2 Would encourage 802.11 Publicity Task Group to Maintain a survey of existing 802.11 related articles Consider efforts to promote development of technical articles promoting effectivness of 802.11 solutions Consider developing HIPERLAN/2 model for closer scrutiny Matthew Sherman, AT&T Labs - Research