1. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 1 Greenfield protection mechanism 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-15 Authors:

2. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 2 11g/11b-like MAC OBSS Protection is the best of the 4 choices for Greenfield protection 11abg devices need to be protected from Greenfield transmissions and vice versa We evaluate four levels of GF protection MAC OBSS Protection, similar to the 11g/11b protection method, is the most balanced solution This presentation addresses the following letter ballot comments: −CID 118, 4017, 4035, 4511, 4522, 10292, 12030, 12048, 12049, 12127

3. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 3 Greenfield and 11abg devices need to be protected from each other, yet the 11abg PHY doesn’t do this There are over 500 million legacy 802.11abg devices that will never decode Greenfield (GF) PLCP headers −Some vendors expect to sell 11abg devices for another 4 years and these devices will be in the field for another 4 years beyond that 11abg devices default to CCA protection via ED, with less than 6% of the BSS area protected −-62 dBm (OFDM), -73 dBm (CCK, typical) The result is 11abg devices will collide with GF in the 2.4 & 5 GHz bands These collisions will degrade voice & video traffic of 11abg & GF devices This problem will occur whenever there is a 11abg device within “range” of a GF device

4. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 4 Current Greenfield MAC protection only provides protection within the same BSS Draft 1.06 provides MAC GF protection for the same BSS It does not provide GF protection for the overlapping BSS −9.13.3.2 Greenfield protection −A STA that is associated with a BSS shall protect Green Field PPDUs using any of the protection mechanisms described in 9.13.5 (Ed: CID 2553) when its AP transmits an HT Information element with the Non-Greenfield STAs Present field set to 1. (Ed: CID 1298) −Ref: Draft 1.06

5. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 5 Enterprise customers with 11abg APs expect interoperation with neighboring GF APs and internal “hotspot” GF APs

6. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 6 The most balanced option for a complete solution is MAC OBSS Protection No GF MAC Protection MAC BSS Protection MAC OBSS Protection MAC OBSS GF Prohibition Protection Overhead Avoided? YesYes, reached gracefully over time N/A Good Voice/Video Service? No Yes Customer satisfaction? No YesReduced Flexible transition to 11n? No Yes Promotes GF? Yes No

7. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 7 No GF MAC protection causes very poor service, customer dissatisfaction & may require forklift upgrades Description GF packets are transmitted without any MAC protection, regardless of nearby co-channel 11abg devices Positives No GF MAC protection means no additional overhead Negatives Same-BSS or OBSS GF & 11abg devices: −Experience reduced voice & video QoS −Reduce handset standby time due to retries −Cause hard-to-debug customer issues, which may cause companies with 11abg investments to ban 11n −Cause impossible-to-fix customer issues when the devices are owned by adjacent companies Companies with significant 11abg investments may need to “forklift upgrade” all devices to gain benefit from 11n

8. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 8 BSS-only MAC protection still causes poor service, customer dissatisfaction & may require forklift upgrades Description GF packets have MAC protection when there are 11abg devices in the same BSS No MAC protection for other nearby co-channel 11abg devices In draft 1.06 Positives The GF MAC protection overhead gracefully disappears over time, as 11abg devices drop from use 11abg devices can interoperate with GF devices in the same BSS Negatives Overlapping BSS GF & 11abg devices: −Experience reduced voice & video QoS −Reduce handset standby time due to retries −Cause hard-to-debug customer issues, which may cause companies with 11abg investments to ban 11n −Cause impossible-to-fix customer issues near boundary walls from GF devices owned by adjacent companies Companies with significant 11abg investments may need to “forklift upgrade” all devices to gain benefit from 11n

9. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 9 OBSS MAC protection provides customer satisfaction and the overhead gracefully disappears over time Description GF packets are transmitted without MAC protection whenever there are no nearby 11abg devices GF MAC protection is used if there are any nearby co-channel 11abg devices This is the 11g/11b upgrade solution Positives The GF MAC protection overhead gracefully disappears over time, as 11abg devices drop from use 11abg devices can interoperate with GF devices irrespective of physical deployment Negatives No GF if an 11abg device is nearby −True, yet the collisions from a nearby active 11abg device are much worse

10. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 10 OBSS MAC prohibition is unlikely to be acceptable to TGn Description GF packets are transmitted without MAC protection whenever there are no nearby 11abg devices GF packets are unused if there are any nearby co-channel 11abg devices Positives GF gracefully appears over time, as 11abg devices drop from use 11abg devices can interoperate with GF devices irrespective of physical deployment Negatives Does not promote GF Unlikely to be acceptable to TGn

11. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 11 Q: How does OBSS MAC protection work? A: Same as 11g/11b. There are two bits: −An AP marks both bits in an IE in beacons & probe responses if a legacy device is present in its BSS −Bit1 tells its clients to use protection, bit2 notifies its neighboring APs of the situation −Neighboring APs see bit2 or APs beaconing legacy-only supported rates, and can use bit1 to tell their clients of the situation. −Neighbors of neighbors don’t see bit2 marked or anything else, so freely transmit GF

12. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 12 Questions? ?

13. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 13 Straw-Poll Do you support mandatory OBSS MAC protection for GF? Y N A

14. doc.: IEEE 802.11-06/1808r0 Submission November 2006 Hart et al (Cisco)Slide 14 Straw-Poll Do you support optional OBSS MAC protection for GF? Y N A