1. Proposed Protocol for 40 MHz Operations in 2.4 GHz
September 2006
doc.: IEEE /1458r0
November 2006
Proposed Protocol for 40 MHz Operations in 2.4 GHz
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. Moving forward with 40 MHz in 2.4 GHz
November 2006
Moving forward with 40 MHz in 2.4 GHz
It is apparent that the industry would like to have 40 MHz transmissions in 2.4 GHz
This feature has been announced and is already “on the box” for many vendors
Banning it not realistic
Not enforceable by IEEE, WiFi already allows 40MHz devices, questionable whether WiFi is legally allowed to ban 40MHz
Removing 40 MHz in 2.4GHz from the draft has problems too
Almost certainly means 40 with multiple vendor-specific 20/40 MHz interop schemes. Without WiFi: no performance requirements, no testing, reduced or no interoperability between vendors. With WiFi: TBD but expect belated testing at least. Not all n market segments may subject their products to WiFi testing.
But since there are many legacy devices and very little bandwidth available at 2.4 GHz, 40 MHz in 2.4 GHz is a privilege not a right
Therefore, IEEE should set conservative and fair limits for 40 MHz use
Specifications for this in current draft are too relaxed
Proposal in 06/1699r8 is a tremendous improvement but still requires tighter constraints
We propose here ideas for a protocol based on 06/1699r8 as a start to working towards a compromise that the majority of TGn body would agree with.
Hart et al (Cisco)

3. Objectives for 40 MHz operations in 2.4 GHz
November 2006
Objectives for 40 MHz operations in 2.4 GHz
Be a good neighbor
Enable 40MHz on the box
Protect the ability of WLANs to do frequency planning, which requires a minimum of 3 channels
Protect legacy devices
Protect QoS traffic 
Hart et al (Cisco)

4. Definition: Overlapping channels
November 2006
Definition: Overlapping channels
We define “overlapping channels” to be all 20 MHz channels allocated for the 2.4 GHz band that overlap with the secondary channel of a 40 MHz channel.
Example: 40 MHz operations in channels 1 and 5
Hart et al (Cisco)

5. Before starting a BSS, an AP shall verify:
November 2006
Before starting a BSS, an AP shall verify:
<TBD1a{e.g. 2}% ED on the secondary channel using a TBD2a{e.g. -72} dBm threshold over TBD3a{e.g. 2} sec
Excluding secondary transmissions of a 40 MHz BSS that share the same primary channel.
Note that since this is an energy detect, Bluetooth activities can be detected
And <TBD4{e.g. 2}% channel busy time summed from the busy time of all overlapping channels as measured by the PHY PLCP header, measured over TBD5{e.g. 1} sec per overlapping channel
i.e. sequential scanning of overlapping channels.
Every channel for OFDM, intermittent channels for DSSS
And no beacons in overlapping channels from QoS APs above TBD6a{e.g. -82}dBm and with a Station Count field > 1 in the QBSS Load IE measured over TBD7a{e.g. 2} sec per overlapping channel
Not complete protection of legacy BSSs
Yet ensures we neglect APs that broadcast beacons only
Hart et al (Cisco)

6. While associated to a BSS:
November 2006
While associated to a BSS:
STAs perform the MAC protection like proposed in 06/1699r8
This is "back off on the primary and perform clear channel assessment for DIFS on the extension channel”.
But with concerns fixed
STAs perform regular ED of the secondary channel as in 06/1699r8
That is, ED above TBD2b{e.g. -72} dBm for more than TBD1b{e.g. 2}% of the time measured over TBD3b{e.g. 2} sec to be detected
Note that since this is an energy detect, Bluetooth activity can be detected
APs perform regular beacon detection on overlapping channels:
Any beacon above TBD6b{e.g. -82} dBm in any overlapped channel to be detected within TBD8{60 sec}
The AP may require assistance from TBD{random or nearby} HT STAs if present, and 11k-like protocols should be defined to support this (11k itself is too heavy-weight here).
Hart et al (Cisco)

7. November 2006
Reverting to 20 MHz BSS:
The STA reverts to 20 MHz operation if the ED threshold is crossed.
The AP and BSS, including DLS links, revert to 20 MHz operation
If any QoS AP beacons with a Station Count field > 1 in the QBSS Load IE are detected
Hart et al (Cisco)

8. While attempting to return to 40MHz operation
November 2006
While attempting to return to 40MHz operation
Perform either of these
"Before starting a BSS" (in slide 5)
Wait TBD9{e.g. 5*TBD8} sec then successfully perform "While associated to a BSS" (in slide 6)
Hart et al (Cisco)

9. Determining the TBD Values
November 2006
Determining the TBD Values
We recommend picking single values for the above TBD parameters (i.e. we are standardizing a spec).
The alternative is to give a range of values with defaults (i.e. we are standardizing a protocol), and depend upon an industry body (WiFi) to enforce appropriate values.
There are arguments both ways but we are concerned that some market segments may chose to work outside of WiFi so that IEEE is the only source of checks and balances. 
These values should be determined via analysis and/or simulations.
If a range of values are standardized, then in the case of overlapping (in coverage and in frequency) HT BSSs, the more stringent 20/40 MHz parameters must be adopted by the neighboring APs.
Hart et al (Cisco)

10. Discussion Do you agree with the objectives in this proposed protocol?
November 2006
Discussion
Do you agree with the objectives in this proposed protocol?
Any suggestions for this proposed protocol?
We welcome discussion on this proposal to help us achieve an agreeable compromise.
Hart et al (Cisco)