1. TXTIME Calculation for MM-only HT STA
November 2006
TXTIME Calculation for MM-only HT STA
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
Bill McFarland, Atheros Communications, Inc.
Bill McFarland, Atheros Communication, Inc.

2. Issues With 1571r4 We have 3 concerns with 1571r4 as it stands now
November 2006
Issues With 1571r4
We have 3 concerns with 1571r4 as it stands now
It uses CCA in cases that the HT-SIG indications can not be interpreted due to reserved on unsupported features, and does not allow the use of the L-SIG
It calls for a CCA threshold that is unreliable in the presence of adjacent channel interference
It requires all devices to implement a new CCA procedure with multiple CCA thresholds
We could support this proposal with two modifications:
Add text to allow the use of the L-SIG for calculating TXTIME
Make the raw power CCA threshold the same as it has always been (20dB) above the noise floor
Bill McFarland, Atheros Communications, Inc.

3. Collision Avoidance – Mixed Mode
November 2006
Collision Avoidance – Mixed Mode
For mixed mode preamble packets, there are two equally valid ways to determine TXTIME
Calculate TXTIME on basis of HT-SIG
Difficult due to large number of options (20/40 MHz, Short guard interval, MCSs with unequal modulations, STBC, LDPC, any combination of the previous options)
Does NOT work if a reserved HT-SIG indication used
Makes all devices dependent upon less settled optional portions of the draft
Calculate TXTIME on basis of L-SIG
Simple – always based on 6 Mb/s rate that all devices understand
WORKS if a reserved HT-SIG indication is used
Automatically provides NAV if transmitter uses L-SIG-TXOP protection
Legacy devices will be using L-SIG method in all cases
Methods are equally valid – L-SIG method has advantages
Both should be allowed
Bill McFarland, Atheros Communications, Inc.

4. L-SIG Protection and TXOP Termination
November 2006
L-SIG Protection and TXOP Termination
A device using the L-SIG to establish TXTIME cannot have its NAV cleared by TXOP truncation
However TXOP truncation is not to be used with L-SIG TXOP protection. Section states:
“TXOP truncation shall not be used in combination with L-SIG TXOP Protection, because a CCA cannot be reset through the transmission of a MAC frame. This avoids potential unfairness or a capture effect for non-HT STAs.”
Not a big issue – devices just need to be accurate when using long NAV and L-SIG TXOP protection
Better than the other option – no way to communicate the NAV in networks with mixed capabilities
Bill McFarland, Atheros Communications, Inc.

5. Collision Avoidance – Greenfield
November 2006
Collision Avoidance – Greenfield
Current draft specifies sufficient behavior to insure mixed networks of GF and non-GF devices work correctly:
9.14.2: “All STAs in the BSS shall protect Green Field PPDUs when there is at least one non-HT or non-GF STA associated with this BSS.”
MAC protection is the correct choice
Necessary to communicate NAV when devices do not support all MCS/feature combinations
Necessary in order to allow future use of reserved HT-SIG indications
Necessary for the protection of legacy devices
MAC protection alleviates need for non-GF devices to decode GF HT-SIG and calculate TXTIME for all possible MCS/feature combinations
Given MAC protection, the new raw power CCA threshold is not needed
Bill McFarland, Atheros Communications, Inc.
Bill McFarland, Atheros Communication, Inc.

6. Collision Avoidance – Raw Power CCA
November 2006
Collision Avoidance – Raw Power CCA
1571r4 proposes that devices use raw power CCA at the reception sensitivity limit to substitute for TXTIME calculation in the following cases
MM devices that cannot calculate all possible TXTIMEs
Non-GF devices when receiving un-protected GF packets
GF devices when receiving reserved HT-SIG indications
This method is unnecessary for case 1
MM devices will see MAC protection for GF transmissions – no need to use raw power CCA
MM devices can use L-SIG for MM transmissions – simple and reliable
It is unnecessary or insufficient for case 2
Current raw power CCA limit worked fine for 11g
If current CCA limit doesn’t work for OBSS case, will need GF OBSS protection anyway
It may be useful for case 3
Don’t know of any way to better for case 3
However, may be unreliable. MAC protection may be required when GF is used with reserved HT-SIG indications
Bill McFarland, Atheros Communications, Inc.

7. Raw Power CCA at the Sensitivity Limit
November 2006
Raw Power CCA at the Sensitivity Limit
Raw power CCA at the reception sensitivity limit is likely to be undesirable
Real world sensitivity limits are much lower than what is specified in the draft – may still have collisions on packets that could have been received – better to use other mechanisms to establish NAV
Statistical variation in measuring the noise or receive signal power may cause failures
Unclear when to terminate sensitivity limit CCA – used in cases when TXTIME could not be determined
Transmit spectral leakage from adjacent channel devices can create persistent raw power above the sensitivity limit
If raw power detection at the sensitivity limit were reliable, we would be using it all the time
Bill McFarland, Atheros Communications, Inc.

8. Tx Spectral Mask and CCA
November 2006
Tx Spectral Mask and CCA
Only 20dB isolation required at edge of adjacent channel
Only 28 dB isolation required at the center of adjacent channel
40 dB isolation for alternate and greater offsets (legacy devices)
Bill McFarland, Atheros Communications, Inc.

9. Spectral Leakage and Raw Power CCA
November 2006
Spectral Leakage and Raw Power CCA
Spectral leakage is composed of distortion products. It appears as raw power and does not look like an preamble.
If put raw power CCA at minimum sensitivity level, get less than 28dB CCA isolation from adjacent channel, and less than 40 dB CCA isolation from legacy alternate and greater.
We do observe far higher channel busy times when the raw power CCA is lowered to the minimum sensitivity level.
If put raw power CCA at 20 dB above sensitivity level, allow 48dB CCA isolation adjacent and 60 dB CCA isolation to alternate
Bill McFarland, Atheros Communications, Inc.

10. Raw Power CCA Threshold – Historical Perspective
November 2006
Raw Power CCA Threshold – Historical Perspective
In 11g, protection was not required for legacy devices in an OBSS, and raw power CCA was left 20dB above the sensitivity limit
We are trusting raw power CCA at 20dB above the sensitivity limit to be sufficient to protect legacy devices from GF packets in OBSS case
1571r4 creates a new CCA mode that everyone will need to implement
New CCA behavior is mandated for case of reserved MCS indications
Would presumably be tested by WiFi to insure forward interoperability with future devices
Bill McFarland, Atheros Communications, Inc.

11. November 2006
Recommendations
We recommend making the following changes to the proposal in 1571r4:
Allow MM STAs to use L-SIG to determine TXTIME for MCS/feature combinations they do not support
Leave raw power CCA at 20 dB above the sensitivity limit as it has always been
Bill McFarland, Atheros Communications, Inc.