1. TGn Sync MAC Response to Reasons and Cures Relating to Link Adaptation
Month Year
doc.: IEEE yy/xxxxr0
May 2005
TGn Sync MAC Response to Reasons and Cures Relating to Link Adaptation
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

2. Authors (continued): May 2005 Month Year doc.: IEEE 802.11-yy/xxxxr0
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

3. Comments: MCS Feedback
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Comments: MCS Feedback
Summary of Comments #3, 12, 20, 36, 47, 85
Immediate (SIFS) MCS Feedback is complex, adds too much overhead and shows no benefit
MCS Feedback must be optional since HCCA simulations showed no performance benefit
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

4. Month Year
doc.: IEEE yy/xxxxr0
May 2005
Responses #3, 12, 20, 36, 47, 85
We have previously shown in document 05/1630r1
MCS Feedback provides significant performance advantage over so-called “open loop” schemes that rely on ACK/NAK feedback to adjust MCS.
Open loop must back-off on data rate to meet very low latency and PER requirements of media distribution applications.
Closed loop MCS feedback
Is able to maximize throughput under latency and PER constraints.
SIFS feedback is NOT necessary.
Can be provided with very low overhead.
The following analysis is further evidence of the value and cost/benefit of MCS Feedback.
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

5. Channel model B Spatial spreading SNR = 20 dB 2x2
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Channel model B Spatial spreading SNR = 20 dB 2x2
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

6. WLAN Channel Variations
Month Year
doc.: IEEE yy/xxxxr0
May 2005
WLAN Channel Variations
2x2. Channel model B.
Spatial spreading only
SNR = 20 dB
Significant channel SNR variations
Per stream SNR (averaged across frequency bins) for SS varies between 5dB and 20dB.
Fading cycle is a few tens of ms.
To maintain a target PHY PER of 2%
Either, track channel variations with MCS Feedback latency of 10 ms
Or, with open loop or long MCS Feedback latency need to back-off from average SNR by 10 dB.
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

7. MCS Feedback Latency and Back-off
Month Year
doc.: IEEE yy/xxxxr0
May 2005
MCS Feedback Latency and Back-off
Study the tradeoff between MCS Feedback latency and PHY Data Rate back-off to maintain target PER.
Link simulations
Consider fixed back-off values of 1 dB, 2 dB and 3 dB
Higher back-off is required to achieve target PER but results in loss of data rate.
Limit the size of the fixed back-off at the PHY, since PHY does not know the delay with which the MCS Feedback will be delivered and used by the MAC.
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

8. PHY Rate versus SNR Mean PHY Rate (Mbps) Backoff SNR = 10 dB
Month Year
doc.: IEEE yy/xxxxr0
May 2005
PHY Rate versus SNR
Mean PHY Rate (Mbps)
Backoff
SNR = 10 dB
SNR = 20 dB
SNR = 30 dB
1 dB 18 68
140
2 dB 13 63
130
3 dB 9 56
125
Channel Model B, Spatial Spreading, 2x2.
Backoff must be increased to meet target PER.
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

9. PER versus MFB Latency for 3 dB Backoff
Month Year
doc.: IEEE yy/xxxxr0
May 2005
PER versus MFB Latency for 3 dB Backoff
Channel Model B, Spatial Spreading, 2x2.
At higher SNRs, fixed back-off = 3 dB is insufficient to maintain target PER
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

10. Observations from Link Simulations
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Observations from Link Simulations
However, even a fixed 3 dB backoff is insufficient to achieve a target 2% PER if the MCS feedback latency exceeds 10 ms.
Require even larger backoff to bring down the PER when the MCS feedback latency is larger than ms.
Back-off value of 1-2 dB allows the PER target to be met if the latency is less than 10 ms.
Low latency MCS feedback to maximize data rate while achieving target PER.
This case is studied next using system level simulations with an “outer loop” that adjusts backoff to achieve a target PER.
Large MCS feedback latency results in large backoff.
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

11. System level simulation setup
Month Year
doc.: IEEE yy/xxxxr0
May 2005
System level simulation setup
PHY Parameters
2x2
Link Distance: 32 m. SNR = 20 dB
Channel model B with no impairments
Spatial Spreading
System simulation parameters
One AP-STA FTP flow; 150 Mbps offered; 1500 B packets; Delay req: 300ms
Outer loop targets 2% PER
Delayed Block Ack
MCS Feedback (MFB) latency varied between 2 to 200 ms.
Report
MAC goodput (MSDU correct and within delay requirement)
Mean PHY mean rate
PHY PER
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

12. Impact of MCS Feedback Delay
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Impact of MCS Feedback Delay
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

13. Observations from System Simulation
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Observations from System Simulation
With MFB every 20 ms MAC rate is ~15% lower compared to MFB every 2 ms
With MFB every 100 ms MAC rate is less than half the rate achieved with MFB every 2 ms
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

14. Complexity of MCS Feedback
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Complexity of MCS Feedback
Generation of MCS Feedback is very low complexity.
The estimate of post-detection SNR is a by-product of the spatial equalizer that the receiver implements to decode the received frame.
Mapping the SNR to MCS feedback introduces little additional implementation complexity.
So, immediate MCS feedback comes at virtually no additional cost.
MCS feedback latency of ms would be sufficient to adapt to SNR variations in typical WLAN channels.
Performance results show that immediate MCS feedback (within SIFS) is not necessary.
Immediate MCS Feedback is not mandated.
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

15. Conclusions on MCS Feedback
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Conclusions on MCS Feedback
We find significant performance advantage of low latency MCS Feedback compared to “open loop”
MCS feedback latency of ms is sufficient to adapt to SNR variations in typical WLAN channels.
Immediate MCS Feedback is not mandated.
Performance results show that immediate MCS feedback (within SIFS) is not necessary.
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

16. Beamforming and Calibration
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Beamforming and Calibration
MAC Related Reasons: 14, 82, 83, 86, 93, 95
Beamforming must be truly optional
Calibration related procedures should be optional and part of capability negotiation. Possibly mandatory for AP.
Beamforming is not effective for TGn Sync MAC. (Incompatibility of beamforming with MRA)
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company

17. Response: Beamforming and Calibration
Month Year
doc.: IEEE yy/xxxxr0
May 2005
Response: Beamforming and Calibration
A-PPDU and A-MPDU have similar properties regarding beamforming (from MAC point of view)
Cannot change beamforming training during the packet.
PPDU Bursting is effective with beamforming
Each PPDU may contain an aggregate (A-MPDU)
Each PPDU directed to a single RA may use beamforming
Support for Calibration is optional at the STA
We have added a new HT Capability bit “Calibration Supported”
Sanjiv Nanda, Qualcomm Inc., et al
John Doe, Some Company