1. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 1 TXTIME Calculation for MM-only HT STA Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2006-11-12 Authors:

2. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 2 Issues With 1571r4 We have 3 concerns with 1571r4 as it stands now 1.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 2.It calls for a CCA threshold that is unreliable in the presence of adjacent channel interference 3.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

3. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 3 Raw Power CCA There are reasons that the Raw Power CCA limit has traditionally been 20dB above the minimum receive sensitivity –More robust in the face of statistical variation in noise measurement –Spectral leakage from transmissions in the adjacent channel

4. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 4 Tx Mask Spectral Leakage

5. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 5 MM vs. GF Mixed-Mode (MM) Packet –Has both legacy and HT portion in preamble –Due to its legacy-device friendly property, MM is mandatory in 802.11n draft 1.0 Greenfield-Mode (GF) Packet –Its preamble can not be understood by legacy device –As a result, it is optional as defined in 802.11n draft 1.0, and GF packet protection is mandatory if there is legacy or non-GF STA associated –Many votes, over more than a year, consistently show preference for GF to be optional –Most recent poll showed 62% favor GF optional (July meeting in San Diego)

6. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 6 Benefit & Problems with GF Preamble There is marginal benefit brought by GF preamble –IEEE 802.11/06-0452r2 proves the throughput enhancement of the GF preamble is just a few percent in likely scenario GF preamble has disadvantages –GF preamble is not interoperable by legacy devices –The lack of an L-SIG in the GF preamble prohibits NAV protection for legacy devices - L-SIG TXOP protection –GF preamble itself introduces signal processing difficulties Time acquisition – if popular cross-correlation based algorithm is used Channel estimation – if GF is used along with TxBF The benefit in throughput does not justify burdening all devices with GF capability

7. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 7 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

8. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 8 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 9.13.5.2 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.”

9. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 9 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 Requiring decoding of GF HT-SIG, AND calculation of TXTIME is equivalent to making GF mandatory – nothing can be saved

10. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 10 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 1.MM devices that cannot calculate all possible TXTIMEs 2.Non-GF devices when receiving un-protected GF packets from OBSS 3.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

11. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 11 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 –Transmit spectral leakage from adjacent channel devices can create persistent raw power above the sensitivity limit –Unclear when to terminate sensitivity limit CCA – used in cases when TXTIME could not be determined If raw power detection at the sensitivity limit were reliable, we would be using it all the time

12. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 12 Raw Power CCA Threshold 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

13. doc.: IEEE 802.11/06-1707r1 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 13 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 Trust MAC protection mechanisms to allow non-GF devices to skip calculating TXTIME for all possible MCS/feature combinations Leave raw power CCA at 20 dB above the sensitivity limit as it has always been