1. Coex Ad Hoc May Montreal Agenda and Report
October 2006
doc.: IEEE /1560r1
May 2007
Coex Ad Hoc May Montreal Agenda and Report
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
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

2. October 2006
doc.: IEEE /1560r1
May 2007
Abstract
Coex Ad Hoc in May Montreal agenda and report regarding comment resolution of LB97 (802.11n), including straw polls
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

3. Overview Submissions Comment Resolution
October 2006
doc.: IEEE /1560r1
May 2007
Overview
Submissions
Comment Resolution
Latest version of spreadsheet: 07/0339r7
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

4. October 2006
doc.: IEEE /1560r1
May 2007
Highlights of the IEEE-SA Standards Board Bylaws on Patents in Standards
Participants have a duty to tell the IEEE if they know (based on personal awareness) of potentially Essential Patent Claims they or their employer own
Participants are encouraged to tell the IEEE if they know of potentially Essential Patent Claims owned by others
This encouragement is particularly strong as the third party may not be a participant in the standards process
Working Group required to request assurance
Early assurance is encouraged
Terms of assurance shall be either:
Reasonable and nondiscriminatory, with or without monetary compensation; or,
A statement of non-assertion of patent rights
Assurances
Shall be provided on the IEEE-SA Standards Board approved LOA form
May optionally include not-to-exceed rates, terms, and conditions
Shall not be circumvented through sale or transfer of patents
Shall be brought to the attention of any future assignees or transferees
Shall apply to Affiliates unless explicitly excluded
Are irrevocable once submitted and accepted
Shall be supplemented if Submitter becomes aware of other potential Essential Patent Claims
A “Blanket Letter of Assurance” may be provided at the option of the patent holder
A patent holder has no duty to perform a patent search
Full policy available at 1
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

5. IEEE-SA Standards Board Bylaws on Patents in Standards
October 2006
doc.: IEEE /1560r1
May 2007
IEEE-SA Standards Board Bylaws on Patents in Standards
6.2 Policy
IEEE standards may be drafted in terms that include the use of Essential Patent Claims. If the IEEE receives notice that a [Proposed] IEEE Standard may require the use of a potential Essential Patent Claim, the IEEE shall request licensing assurance, on the IEEE Standards Board approved Letter of Assurance form, from the patent holder or patent applicant. The IEEE shall request this assurance without coercion.
The Submitter of the Letter of Assurance may, after Reasonable and Good Faith Inquiry, indicate it is not aware of any Patent Claims that the Submitter may own, control, or have the ability to license that might be or become Essential Patent Claims. If the patent holder or patent applicant provides an assurance, it should do so as soon as reasonably feasible in the standards development process. This assurance shall be provided prior to the Standards Board’s approval of the standard. This assurance shall be provided prior to a reaffirmation if the IEEE receives notice of a potential Essential Patent Claim after the standard’s approval or a prior reaffirmation. An asserted potential Essential Patent Claim for which an assurance cannot be obtained (e.g., a Letter of Assurance is not provided or the Letter of Assurance indicates that assurance is not being provided) shall be referred to the Patent Committee.
A Letter of Assurance shall be either:
a) A general disclaimer to the effect that the Submitter without conditions will not enforce any present or future Essential Patent Claims against any person or entity making, using, selling, offering to sell, importing, distributing, or implementing a compliant implementation of the standard; or
b) A statement that a license for a compliant implementation of the standard will be made available to an unrestricted number of applicants on a worldwide basis without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination. At its sole option, the Submitter may provide with its assurance any of the following: (i) a not-to-exceed license fee or rate commitment, (ii) a sample license agreement, or (iii) one or more material licensing terms. 2
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

6. IEEE-SA Standards Board Bylaws on Patents in Standards
October 2006
doc.: IEEE /1560r1
May 2007
IEEE-SA Standards Board Bylaws on Patents in Standards
Copies of an Accepted LOA may be provided to the working group, but shall not be discussed, at any standards working group meeting.
The Submitter and all Affiliates (other than those Affiliates excluded in a Letter of Assurance) shall not assign or otherwise transfer any rights in any Essential Patent Claims that are the subject of such Letter of Assurance that they hold, control, or have the ability to license with the intent of circumventing or negating any of the representations and commitments made in such Letter of Assurance.
The Submitter of a Letter of Assurance shall agree (a) to provide notice of a Letter of Assurance either through a Statement of Encumbrance or by binding any assignee or transferee to the terms of such Letter of Assurance; and (b) to require its assignee or transferee to (i) agree to similarly provide such notice and (ii) to bind its assignees or transferees to agree to provide such notice as described in (a) and (b).
This assurance shall apply to the Submitter and its Affiliates except those Affiliates the Submitter specifically excludes on the relevant Letter of Assurance.
If, after providing a Letter of Assurance to the IEEE, the Submitter becomes aware of additional Patent Claim(s) not already covered by an existing Letter of Assurance that are owned, controlled, or licensable by the Submitter that may be or become Essential Patent Claim(s) for the same IEEE Standard but are not the subject of an existing Letter of Assurance, then such Submitter shall submit a Letter of Assurance stating its position regarding enforcement or licensing of such Patent Claims. For the purposes of this commitment, the Submitter is deemed to be aware if any of the following individuals who are from, employed by, or otherwise represent the Submitter have personal knowledge of additional potential Essential Patent Claims, owned or controlled by the Submitter, related to a [Proposed] IEEE Standard and not already the subject of a previously submitted Letter of Assurance: (a) past or present participants in the development of the [Proposed] IEEE Standard, or (b) the individual executing the previously submitted Letter of Assurance. 3
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

7. IEEE-SA Standards Board Bylaws on Patents in Standards
October 2006
doc.: IEEE /1560r1
May 2007
IEEE-SA Standards Board Bylaws on Patents in Standards
The assurance is irrevocable once submitted and accepted and shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal.
The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of those Patent Claims, or for determining whether any licensing terms or conditions are reasonable or non-discriminatory.
Nothing in this policy shall be interpreted as giving rise to a duty to conduct a patent search. No license is implied by the submission of a Letter of Assurance.
In order for IEEE’s patent policy to function efficiently, individuals participating in the standards development process: (a) shall inform the IEEE (or cause the IEEE to be informed) of the holder of any potential Essential Patent Claims of which they are personally aware and that are not already the subject of an existing Letter of Assurance, owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents; and (b) should inform the IEEE (or cause the IEEE to be informed) of any other holders of such potential Essential Patent Claims that are not already the subject of an existing Letter of Assurance. 4
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

8. Other Guidelines for IEEE WG Meetings
October 2006
doc.: IEEE /1560r1
May 2007
Other Guidelines for IEEE WG Meetings
All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws.
Don’t discuss the interpretation, validity, or essentiality of patents/patent claims.
Don’t discuss specific license rates, terms, or conditions.
Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings.
Technical considerations remain primary focus
Don’t discuss fixing product prices, allocation of customers, or dividing sales markets.
Don’t discuss the status or substance of ongoing or threatened litigation.
Don’t be silent if inappropriate topics are discussed… do formally object.
If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at or visit
See IEEE-SA Standards Board Operations Manual, clause and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details.
This slide set is available at 5
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

9. October 2006
doc.: IEEE /1560r1
May 2007
Rules / Procedure
As a general rule, we will NOT be reviewing CIDs on a one by one basis
Resolution of comments will in most cases be based on submissions
Coex Ad Hoc chair will bring resolutions which passed by 75% or more for motion in TGn, with affirmation of Ad Hoc
Votes between 50% - 75% may be brought to TGn for further discussion and votes to break deadlock
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

10. Subgroups (1/2) May 2007 October 2006 doc.: IEEE 802.11-06/1560r1
40-20 in 2.4GHz
240 comments
9.20.4
Matt F.
PCO
31 comments
11.16
Tomo
July
L-SIG TXOP
43 comments
9.13.4,
Yuichi
ECSA
Clause 7
11 comments
Bjorn
DSSS-CCK
9 comments
11.15
Srini
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

11. Subgroups (2/2) May 2007 October 2006 doc.: IEEE 802.11-06/1560r1
DFS & channel selection
46 comments
11.9.7,
Bjorn
Channel switching
36 comments
(not include 2.4 GHz)
Solomon
July
CCA sensing
15 comments
9.20.2,
Assaf
40/20
24 comments
Miscellaneous 40/20 CIDs in , 9.20
Vinko
Protection mechanisms
69 comments
, 9.13
Srini
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

12. Submissions Related to Comment Resolution
October 2006
doc.: IEEE /1560r1
May 2007
Submissions Related to Comment Resolution
Matt F.
n-lb97-cid coex.doc (2 hours more)
n-LB97-CID-1832-Operating-Mode-Bits.doc (30min)
Eldad
n coex-in-2-4ghz.ppt
Bjorn
n-lb97-coex-dfs-channel-selection-comments-resolutions.doc
n-lb97-coex-ecsa-comments-resolutions.doc
Assaf
n-lb97-mac-cca-comments-resolutions.doc
n-lb97-double-cca-comments-resolution-doc.doc
Vinko
Yuichi
John Barr
n-LB97-CID Coex.ppt
Red indicates completed
submissions
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

13. Wed May 9 Agenda Submissions Old submission New submission May 2007
October 2006
doc.: IEEE /1560r1
May 2007
Wed May 9 Agenda
Submissions
Old submission
n-lb97-mac-cca-comments-resolutions.doc
n-lb97-double-cca-comments-resolution-doc.doc
n-lb97-coex-ecsa-comments-resolutions.doc
New submission
n-lb97-coex-dfs-channel-selection-comments-resolutions.doc
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

14. October 2006
doc.: IEEE /1560r1
May 2007
Minutes on 07/0568
CID 70
Add sentence mentioning that OBSS is not synchronized
Doug wants to think about it more, response by beginning of Friday
Doug will provide submission in July (Th 5/10/07)
CID 187
Do we need to add mitigation to reason? Reference Srini sims.
CID 2963
George will provide submission in July.
No objection to resolving non deferred CIDs with 07/568r2 and bringing to TGn Full for motion
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

15. October 2006
doc.: IEEE /1560r1
May 2007
Minutes on 07/0569
No objection to resolving CID 2470 with 07/569r2 and bringing to TGn Full for motion
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

16. October 2006
doc.: IEEE /1560r1
May 2007
Minutes on 07/0524
Modify “The TGn editor has removed E-CSA text from the 11n D No further action required.” to “Remove E-CSA text from 11n D2.0” in CIDs 294, 297, 2118, 2119
CID 3024 changed to defer
No objection to resolving non deferred CIDs with 07/524r2 and bringing to TGn Full for motion
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

17. October 2006
doc.: IEEE /1560r1
May 2007
07/560r0
CID 651, 3003
change to Defer
Possible resolution is reordering and
Another Possible resolution is to add in a reference to , after we see TGy changes to
CID 2572, 2575, 2893, 2894, 1770
Change to defer. Assign to Solomon
CID 3279
Assign to Matt F.
CID 589
Defer. Bjorn to ask Darwin to provide submission for draft text
There is reason code field as part of DELTS frame format. Should be possible to add reason code there.
Stopped at 1770, continue with 1870
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

18. Thursday May 10 Agenda Submissions
October 2006
doc.: IEEE /1560r1
May 2007
Thursday May 10 Agenda
Submissions
Continue with n-lb97-coex-dfs-channel-selection-comments-resolutions.doc
n-lb97-cid coex.doc
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

19. 07/560r0 May 2007 Stopped at 1770 on Wed, continue with 1870 1870 2581
October 2006
doc.: IEEE /1560r1
May 2007
07/560r0
Stopped at 1770 on Wed, continue with 1870
1870
There is potentional contradiction between Secondary Channel Offset and E-CSA. E-CSA changes the BSS from 40 to 20 via regulatory class, but Secondary Channel Offset may remain indicating 40.
However, this is not related to the CID, but we will use this comment to address issue.
Defer comment, Bjorn to revisit
2581
CID resolution changed to Accept
2582, 2583, 2585
Matt to provide tables and normative text which illuminate the of use of all the fields available for 20/40 capability and operation for AP, STA, BSS. Also include E-CSA
Defer for Matt’s table
3083
Defer, Bjorn to commenter for clarification on comment
Bjorn to remove deferred comments & undo changes due to those comment from document as load as R1.
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

20. October 2006
doc.: IEEE /1560r1
May 2007
07/614r2
Straw poll
What is your scanning preference:
AP directed using measurement request frame (D2.0): 11
STA initiated only (07/614):4
Abstain: 5
Question: can we add a statement that a STA SHOULD report detected OFDM traffic (valid FCS) on all channels not equal to primary or secondary? Or traffic in general?
Question: can a STA set the 20 MHz BSS width request to 1 for any reason?
Question: add optional allowance to operate at much faster transition delay (switch down from 40 to 20 MHz BSS) based on using fast traffic detection?
Stopped at edits to HT Capabilities Info field
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

21. Friday May 11 Agenda Submissions
October 2006
doc.: IEEE /1560r1
May 2007
Friday May 11 Agenda
Submissions
n-lb97-cid coex.doc
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

22. 07/614r2 May 2007 October 2006 doc.: IEEE 802.11-06/1560r1
Continue with edits to HT Capabilities Info field
Question: should we the HT Information field be expanded to 4 octets?
Question: should we make the HT Information Exchange frame be made an element?
Question: should we add explicit statement that this is not encrypted?
Question: Does there need to be an explicit statement that an “RSN” receiver process class 1 frames (including HT Information exchange) even if its unencrypted?
9.20
Question: Is it required for a STA to transmit Extended Capabilities element? Need to add requirement that it is sent if the HT Information element is set.
Strawpoll
Should 20/40 MHz BSS in IBSS be allowed in 2.4GHz? Y:3; N:13; A:7
Should 20/40 MHz BSS in IBSS be allowed in 5GHz? Y:14; N:3; A:6
Should we include “An HT-STA-19 that is a member of an IBSS shall not set the Secondary Channel Offset field of the HT Information element to a non-zero value in transmitted frames.” in 07/614? Y: 14; N:0; 7
Question: Should PCO be excluded from 9.20?
Should PCO be excluded from ? Y: 0; N:10; A: 13
Question: Should L-SIG TXOP be excluded from ?
Action: statements on PCO and L-SIG are deleted from , as covered by blanket statement of all 20/40 capable STAs must obey 9.20
Stopped at end of edits
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

23. Monday May 14 Agenda “Old” Submissions
October 2006
doc.: IEEE /1560r1
May 2007
Monday May 14 Agenda
“Old” Submissions
n-lb97-coex-dfs-channel-selection-comments-resolutions.doc
n-lb97-cid coex.doc
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

24. backup May 2007 October 2006 doc.: IEEE 802.11-06/1560r1
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

25. Deferred Comments May 2007 October 2006 doc.: IEEE 802.11-06/1560r1
3007
Comment: A 40MHZ channel bandwidth should Not be used in the 2.4GHz Band. It completely destroys the band for other users.
Proposed Change: Remove the 40MHz channelization in the MHz band in all instances of the draft.
Discussion/submission?
170
Comment: Allowing operation with 40 MHz channels in 2.4 GHz spectrum will not coexist with over 1 billion Bluetooth (IEEE a) devices present around the world. In addition, operation of 40 MHz channels in 2.4 GHz spectrum will be subject to high levels of interference from Bluetooth devices. With only 80 MHz allocated in 2.4 GHz spectrum allocation of half of that spectrum to a single WLAN limits access by other radios sharing that spectrum. Coexistence analysis shows a significant degradation of n performance in the presense of Bluetooth devices, even with significant separation. Many devices include both Bluetooth and making inteference even more significant. AFH defined in IEEE was designed to allow IEEE devices to reasonably avoid 20 MHz wide devices. None of the billion Bluetooth devices deployed at this time have been designed to avoid 40 MHz n devices.
Proposed Change: Change When using 40 MHz channels, it can operate in the channels defined in (Channel allocation in the 2.4 GHz Band) and (Channel allocation in the 5 GHz band)." to "When using 40 MHz channels, it can only operate in the channels defined in (Channel allocation in the 5 GHz band)." Also change other places in the draft that imply operation with 40 MHz channels in 2.4 GHz spectrum.
2906
Comment: The protection mechanism is inadequate for OBSSs, particularly during the scanning period started once an OBSS is detected.
Proposed change: Add duplicate DSSS to allow for the well-known MAC protection mechanisms in 20/40 MHz operation in 2.4 GHz.
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

26. Straw Poll for CID 3007, 170 Do we want to remove 40 MHz from 2.4 GHz?
October 2006
doc.: IEEE /1560r1
May 2007
Straw Poll for CID 3007, 170
Do we want to remove 40 MHz from 2.4 GHz?
Yes:
No:
Abstain:
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)

27. Straw Poll for CID 2906 Do we want to add duplicate DSSS in 2.4 GHz?
October 2006
doc.: IEEE /1560r1
May 2007
Straw Poll for CID 2906
Do we want to add duplicate DSSS in 2.4 GHz?
Yes:
No:
Abstain:
Eldad Perahia (Intel)
Matthew Fischer (Broadcom)