1. doc.: IEEE 802.11/06-1707r0 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-10 Authors:

2. doc.: IEEE 802.11/06-1707r0 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 2 MM vs. GF Mixed-Mode (MM) Packet –It 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 could 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)

3. doc.: IEEE 802.11/06-1707r0 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 3 Benefit & Problems with GF Preamble There is marginal benefit brought by GF preamble –IEEE 802.11/06-0452r2 proves the throughput brought by GF preamble is just a few percent in likely scenario GF preamble causes serious problems –GF preamble is not interoperable by legacy devices –The lack of L-SIG 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

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

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

6. doc.: IEEE 802.11/06-1707r0 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 6 Collision Avoidance – Raw Power CCA It has been proposed that devices could use a raw power CCA at the reception sensitivity limit to substitute for TXTIME calculation in the following cases 1.GF devices when receiving reserved HT-SIG indications 2.Non-GF devices when receiving un-protected GF packets from OBSS 3.MM devices that do not want to determine all possible TXTIMEs 4.MM devices that do not utilize L-SIG This method is unnecessary for cases 3 and 4 –MM devices will see MAC protection for GF transmissions – no need to do raw power CCA –MM devices can use L-SIG – simple and reliable It is insufficient for case 2 –Legacy devices in OBSS will be effected by GF packets as well –Need protection when OBSS has any type of non-GF device – HT or legacy

7. doc.: IEEE 802.11/06-1707r0 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 7 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 –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 In 11g, protection was not required for legacy devices in an OBSS, and raw power CCA was left 20dB above the sensitivity limit

8. doc.: IEEE 802.11/06-1707r0 Submission November 2006 Bill McFarland, Atheros Communications, Inc.Slide 8 Recommendations Allow MM STAs to use L-SIG to determine TXTIME 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 Specify a mechanism to protect legacy devices in OBSS from GF packets (or trust raw power CCA at 20 dB above the sensitivity limit to be sufficient) Require that future devices which use reserved HT-SIG indications, together with GF preamble, precede those transmissions with MAC protection mechanisms