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

2. 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 e committee
The committee should use these bars (in part) to determine if the performance level provided by e is sufficient to compete in the marketplace with other solutions
Matthew Sherman, AT&T Labs - Research

3. 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 nd, Volume: 5, pages
Will refer to article as [HIPERLAN] in these slides
Comparison only considers a DCF
No known implementations of PCF with a
Article claims HIPERLAN/2 superior to a in
throughput provided to the user
Delay
Packet Error Rate (PER)
Matthew Sherman, AT&T Labs - Research

4. 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 a and HIPERLAN?
What modifications should be done as part of e to improve the performance of in the comparisons?
Matthew Sherman, AT&T Labs - Research

5. 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

6. 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 e
Matthew Sherman, AT&T Labs - Research

7. 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

8. 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

9. 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

10. Example 802.11a Overhead Calc*
January 2001
Example a Overhead Calc*
Last
Transmission
28 Byte Header
512 Byte MSDU
DIFS
Backoff
POH+
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/( ) = 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” = = (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

11. 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 / efficiency = 2.5
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 user.
Matthew Sherman, AT&T Labs - Research

12. 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 a
Situations where a out performs HIPERLAN
Matthew Sherman, AT&T Labs - Research

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

14. Downlink PCF Overhead Calc*
January 2001
Downlink PCF Overhead Calc*
Last
Transmission
28 Byte Header
512 Byte MSDU
DIFS
Backoff
POH+
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+
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

15. 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 a
Situations where a out performs HIPERLAN
Matthew Sherman, AT&T Labs - Research

16. 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

17. DCF 802.11a with No ACK January 2001 Last Transmission 28 Byte Header
512 Byte MSDU
DIFS
Backoff
POH+
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+
54 MBPS
Duration in
microsec 34
68 Avg. 20 80
Matthew Sherman, AT&T Labs - Research

18. 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 a
Situations where a out performs HIPERLAN
Matthew Sherman, AT&T Labs - Research

19. 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

20. PCF 802.11a with No ACK January 2001 Last Transmission 28 Byte Header
512 Byte MSDU
DIFS
Backoff
POH+
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+
54 MBPS
Duration in
microsec 16 20 80
Matthew Sherman, AT&T Labs - Research

21. 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 a
Situations where a out performs HIPERLAN
Matthew Sherman, AT&T Labs - Research

22. 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

23. Playing “Devil’s Advocate”
January 2001
Playing “Devil’s Advocate”
[HIPERLAN] analysis did not consider overhead on TCP Ack
Difference only applies to data
Difficult to Analyze TCP Ack for
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

24. Reminder Taken From IEEE 802.11-00245r1
January 2001
Reminder Taken From IEEE r1 “
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

25. 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

26. 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
Have not seen similar articles for over HIPERLAN/2
Would encourage Publicity Task Group to
Maintain a survey of existing related articles
Consider efforts to promote development of technical articles promoting effectivness of solutions
Consider developing HIPERLAN/2 model for closer scrutiny
Matthew Sherman, AT&T Labs - Research