1. Legacy protection mechanism
September 2006
doc.: IEEE /1458r0
November 2006
Legacy protection mechanism
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
Hart et al (Cisco)
Joonsuk Kim, Broadcom Corp.

2. November 2006
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 abg 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
Hart et al (Cisco)

3. November 2006
Current Greenfield MAC protection apparently does not provides legacy protection within the same BSS
Draft 1.06 apparently does not provide MAC GF/11abg protection for the same BSS
It does not provide GF protection for the overlapping BSS
Greenfield protection
A STA that is associated with a BSS shall protect Green Field PPDUs using any of the protection mechanisms described in (Ed: CID 2553) when its AP transmits an HT Information element with the Non-Greenfield STAs Present field set to 1. (Ed: CID 1298)
HT Information element
Non-Greenfield STAs Present: Set to 0 if all HT STAs that are associated are Greenfield capable Set to 1 if one or more HT STAs that are not Greenfield capable are associated
Ref: Draft 1.06
Hart et al (Cisco)

4. November 2006
Enterprise customers with 11abg APs expect interoperation with neighboring GF APs and internal “hotspot” GF APs
Hart et al (Cisco)

5. November 2006
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?
Yes
Yes, reached gracefully over time
N/A
Good Voice/Video Service? No
Customer satisfaction?
Reduced
Flexible transition to 11n?
Promotes GF?
Hart et al (Cisco)

6. November 2006
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
Current state in draft 1.06?
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
Hart et al (Cisco)

7. November 2006
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
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
Hart et al (Cisco)

8. November 2006
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 closely models on 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 can be much worse
Hart et al (Cisco)

9. OBSS MAC prohibition is unlikely to be acceptable to TGn
November 2006
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
Hart et al (Cisco)

10. November 2006
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?
Yes
Yes, reached gracefully over time
N/A
Good Voice/Video Service? No
Customer satisfaction?
Reduced
Flexible transition to 11n?
Promotes GF?
Hart et al (Cisco)

11. September 2006
doc.: IEEE /1458r0
November 2006
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
Hart et al (Cisco)
Joonsuk Kim, Broadcom Corp.

12. Q: How does OBSS MAC protection work? A: Same as 11g/11b.
November 2006
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
For 11n, bit1 is the Operating Mode bit in HT IE and bit2 is a new bit we propose to add.
Hart et al (Cisco)

13. November 2006
Questions? ?
Hart et al (Cisco)

14. November 2006
Motion
Accept 06/1818r2 as a resolution to comments 4522, 10292, , 12048, 12049?
Yes No
Abstain
Hart et al (Cisco)