March 2008 doc IEEE 802 11 080276 r

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Coex Ad Hoc March Orlando Agenda and Report Authors: Submission Date: 2008 -03 -18 1 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Abstract Coex Ad Hoc in March Orlando agenda and report regarding comment resolution of LB 115 (802. 11 n), including straw polls Submission 2 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 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 http: //standards. ieee. org/guides/bylaws/sect 6 -7. html#6 Submission 3 Eldad Perahia (Intel) 1

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 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. Submission 4 Eldad Perahia (Intel) 2

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 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. Submission 5 Eldad Perahia (Intel) 3

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 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 Submission 6 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 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 patcom@ieee. org or visit http: //standards. ieee. org/board/pat/index. html See IEEE-SA Standards Board Operations Manual, clause 5. 3. 10 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 http: //standards. ieee. org/board/pat-slideset. ppt Submission 7 5 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Further Information • IEEE Code of Ethics – • IEEE-SA Affiliation FAQ – • http: //standards. ieee. org/board/pat/faq. pdf IEEE 802 LAN / MAN STANDARDS COMMITTEE (LMSC) POLICIES & PROCEDURES – • http: //standards. ieee. org/board/pat/index. html IEEE-SA PATENT FAQ – • http: //standards. ieee. org/board/pat/loa. pdf IEEE-SA STANDARDS BOARD PATENT COMMITTEE (PATCOM) INFORMATION – • http: //standards. ieee. org/resources/antitrust-guidelines. pdf IEEE-SA LETTER OF ASSURANCE (LOA) FORM – • http: //standards. ieee. org/faqs/affiliation. FAQ. html IEEE-SA Antitrust & Competition Policy – • http: //www. ieee. org/web/membership/ethics/code_ethics. html http: //grouper. ieee. org/groups/802/policies-and-procedures. pdf IEEE 802. 11 WLANS WORKING GROUP POLICIES & PROCEDURES – Submission http: //www. ieee 802. org/11/Doc. Files/06/11 -06 -0812 -03 -0000 -802 -11 -policies-and-proceedures. htm 8 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Overview • Latest versions of spreadsheet – 07/2693 r 11 • Two changes from r 10: CID 5099 withdrawn by commenter and CID 5099 recycled – 07/2693 r 12 • speculative resolutions for Coex 20 -40 subgroup of CIDs that had no objection in Coex Ad Hoc • Total number of unique unresolved comments: 128 • Goals: – Resolve all remaining CIDs! Submission 9 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Coex Ad Hoc 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 Submission 10 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Subgroups (1/2) • Coex 20 -40 – – – • Coex reorg – – – • 8 comments Clause 11. 9, 11. 9. 8, 11. 15. 1 Assignee: Matt, as part of Coex 20 -40 Resolutions included in 07/2742 All 8 CIDs have resolutions with no objection in January PCO – • 102 comments Clause 7, 11. 9. 8, 11. 15. 1, 11. 15. 2, 11. 15. 3, 11. 15. 4, 11. 15. 10, 11. 17, S. 4. 2 Assignee: Matt F. 07/2742 in progress 100 CIDs have resolutions which were reviewed with no objection in January complete L-SIG TXOP – Submission complete 11 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Subgroups (2/2) • Coex cca – – • Coex protection mechanisms – – • 1 comment Clauses 7. 3. 2. 53, 9. 13. 4, 11. 15. 6 Assignee: Bjorn 08/0239 in progress Coex GF – – • 12 comments Primarily clauses 11. 15. 7, 11. 15. 8 08/0035 r 1 Assignee: Eldad 3 comments Clause 9. 13. 3 Assignee: Doug Chan 08/0111 presented in February 20 th conference call Recycled – CID 5099 Submission 12 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Submissions Related to Comment Resolution • Matt F. – 11 -07 -2742 -13 -000 n-lb 115 -cid 5279 -coex-20 -40. doc – 11 -08 -0273 -00 -000 n-lb 115 -cid 5123 -coex-gf. doc (+) • Bjorn – 11 -08 -0239 -01 -000 n-LB 115 -coex-comment-resolution-CID-5534. doc • Eldad – 11 -08 -0035 -02 -000 n-coex-cca. doc • Doug – 11 -08 -0301 -00 -000 n-voip-traffic-by-draft-n-greenfield-devices-causesfalse-radar-detection-on-dfs-channels. ppt (+) – 11 -08 -0302 -00 -000 n-text-for-preventing-detrimental-greenfield-effects-on -dfs-channels. doc (+) Red indicates completed submissions Submission 13 (+) indicates submission was discussed Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Agenda for Wednesday March 12 • 11 -07 -2742 -11 -000 n-lb 115 -cid 5279 -coex-20 -40. doc • 11 -08 -0035 -01 -000 n-coex-cca. doc • 11 -08 -0239 -00 -000 n-LB 115 -coex-comment-resolution. CID-5534. doc • Recycled comment Submission 14 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Minutes for Wednesday March 12 • 07/2742 r 11 – Reviewed updates from r 8 to r 9 to r 10 to r 11 – Strawpoll • Remove CID 5077 and CID 5827 from 07/2742 r 11 and create 07/2742 r 13 and bring all remaining CIDs in 07/2742 r 13 to motion in TGn full • No objections (9 participants) – Will be brought to motion on Tues AM 2 – Discuss 5077 tomorrow – Discuss 5827 in TGn full on Tues AM 2 • 11 -08 -0035 -01 -000 n-coex-cca. doc – Modified reason for rejection for 5377, 5493, 5066, 5351, which becomes 08/0035 r 2 – Strawpoll • Bring 08/0035 r 2 to motion in TGn full • No objections (9 participants) Submission 15 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 08/0239 r 0 • CID 5534 • Bruce: in sentence “NOTE – the rules stated above allow an HT AP to select HT non-HT mixed mode at any time according to implementation-defined criteria. ” what does “according to implementationdefined criteria” add? – Delete “according to implementation-defined criteria” • 08/0239 r 1 includes above modification • Strawpoll – Bring 08/0239 r 1 to motion in TGn full – No objections (9 participants) Submission 16 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 CID 5099 • Created the following resolution – Counter - Refer to CID 5357, which calls for removal of 11 n extensions to the MP including 7. 3. 2. 52. 2. • No objection to resolution and bringing to TGn full for motion (9 participants) Submission 17 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Agenda for Thursday March 13 • EMR CID 5849 • Greenfield Submission 18 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Minutes for Thursday March 13 • CID 5849 – Modified edits in 2742 r 13 to match D 3. 05 for this CID, creating 2742 r 14 – No objections to 2742 r 14 and bringing to motion in TGn full (10 participants) Submission 19 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Greenfield • 08/0301 r 0 – Joe: was any other traffic type beyond ping added to Vo. IP traffic? • Doug: no, but multiple Vo. IP streams was also tried also resulting in radar detects – Guido: were any tests outside screen room? • Doug: no. But false detects occurred immediately after GF traffic started – When was ping traffic started? • Doug: one test had regular GF pings in background, then GF Vo. IP was start – Tushar: all but G. 711 packet sizes have much smaller pulse sizes that “bin 5” test – Tushar: this is beyond a corner case – Allert: sounds like a poor radar detect, should be improved to differentiate between GF and chirp – John: when in the screen room, was Tx power reduced? Will you get lots of reflections and desensitize receivers? • Doug: no – Dave: are there enough members that perceive that this is a problem? Submission 20 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 08/0302 r 0 • • Eldad: currently in 802. 11 (& 11 n. D 3), behavior limit set 4 (DFS) is not required in US Allert: FCC only required bin 5 since July 2007 Eldad: then “legacy 11 a” does not apply to US 11 a devices certified prior July 2007. This issue only applies to new 11 a devices in the US Adrian: Do we have a statement that OBSS Non-HT STAs Present field of the HT Information element to 1 in IBSS? – Doug: reserved for IBSS – Adrian: then current definition of this field is incompatible • Tushar: is active scan permitted in DFS bands? – Differing answers among the group • • Adrian: there is an issue that there are three states of a station, but we have only defined two states in capability bit. STA is only GF until the first HT capability element is transmitted Eldad: “Before an HT STA changes the HT…” forces non-AP STA to scan Submission 21 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 08/0302 r 0 continued • Bruce: IBSS should have to keep scanning for radar • Joe: as soon as HT-greenfield subfield of HT Capability element is set to 0, then the AP is not GF device and can ignore the timer rules • Joe: after time hits zero, should AP rescan? • Adrian: In “A GF AP shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to HT_GF if its OBSS Non-HT STAs Present field of its last transmitted HT Information element is set to 0. A GF non-AP STA shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to HT_GF if the last frame received from its AP containing an HT Information element has the OBSS Non-HT STAs Present field set to 0. ” both 0’s need to be changed to 1 Submission 22 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 08/0302 r 0 continued • Strawpoll – Do you support the concept in 08/0302 r 0? • Y: 1; N: 4; Abs: 6 – Do you believe that restricting GF transmissions on the DFS channels is required to protect 11 a? • Y: 1; N: 7: Abs: 3 Submission 23 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 08/0273 r 0 • Strawpoll – Do you support the resolution and proposed resolution text in 08/273 r 0 for CIDs 5123, 5363? • Y: 4; N: 2; Abs: 5 – Do you support rejecting CIDs 5123, 5363 with the resolution text “The problem of false detections in legacy devices is not limited to GF receptions” • Y: 7; N: 1; Abs: 3 – Do you support changing in 9. 13. 3. 3 “When non-HT devices are detected, the STA may enable protection of its HT greenfield format” to “When non-HT devices are detected, the STA shall enable protection of its HT greenfield format”? • Y: 4; N: 4; Abs: 2 Submission 24 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Strawpoll • Do you support for CID 5124 the resolution “Reject: 802. 11 n thresholds are -82 d. Bm for GF capable STAs, and -72 d. Bm for non-GF capable STAs. It is not necessary to lower the threshold further. Lowering the thresholds for 802. 11 a/b/g is out of scope. The invocation of the protection mechanisms for GF transmissions found within 9. 13 are based on the bits found in the HT Information element, which provide sufficient signaling of information to cover all of the cases when GF protection is expected to be useful. ” – Y: 7; N: 1; Abs: 2 Submission 25 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Strawpoll • Do you support for CID 5827 the resolution “Reject – The group has repeatedly voted to permit 40 MHz operation in 2. 4 GHz. The group further believes that the mechanism is warranted to enable 40 MHz operation in 2. 4 GHz. ” – No objection Submission 26 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Strawpoll • Do you support for CID 5077 the resolution “Reject – the group consensus is that there are many other parameters that can affect the best choice of a set of channels for 20/40 MHz BSS operation, including, but not limited to: traffic load, channel state of other channels, power limitations of channels, relative separation between overlapping BSSs – a change to shall as indicated disallows the consideration of a complete set of parameters. Since destructive overlap affects both BSSs, implementers will strive to create algorithms that select channel operating conditions that maximize throughput for all BSSs involved. ” – No object Submission 27 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Summary of Pre-meeting • • All CIDs resolved and approved to be brought to motion in TGn full Coex CCA sub-group – 12 CIDs resolved by 08/0035 r 2; all by reject; passed by no objection – Refer to “coex pending motion set 1” in document 11 -07/2693 r 13 • Coex protection mechanisms sub-group & Recycled CID – 1 protection mechanism CID resolved by 08/0239 r 1 and recycled CID 5099 both resolved with counter; passed by no objection – Refer to “coex pending motion set 2” in document 11 -07/2693 r 13 • 20 -40 & re-org sub-group – 108 CIDs in 07/2742 r 14 with As, Cs, and Rs; all passed by no objection – CIDs 5827 and 5077 resolved by reject; passed by no objection – Refer to “coex pending motion set 3” in document 11 -07/2693 r 13 • Greenfield sub-group – – Submission Resolves CIDs 5123, 5124, 5363 all by reject CIDs 5123 and 5363 passed in the Coex Ad Hoc with a vote of Y: 7; N: 1; Abs: 3 CIDs 5124 passed in the Coex Ad Hoc with a vote of Y: 7; N: 1; Abs: 2 Refer to “coex pending motion set 4” in document 11 -07/2693 r 13 28 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Pending Motions Submission 29 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Motion # 299 • Moved: Approve resolution of comments found on the tab labelled “coex pending motion set 1” in document 11 -07/2693 r 13. – Based on resolutions in the following submission: • 08/0035 r 2 (Coex CCA sub-group) – Resolves 12 comments with Rs – All passed by no objection • TGn vote: no objection Submission 30 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Motion # 300 • Moved: Approve resolution of comments found on the tab labelled “coex pending motion set 2” in document 11 -07/2693 r 13. – Based on resolutions in the following submission: • 08/0239 r 1 (Coex protection mechanisms sub-group) – Recycled CID 5099 – Resolves 2 comments with Cs – All passed by no objection • TGn vote: no objection Submission 31 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Motion # 301 • Moved: Approve resolution of comments found on the tab labelled “coex pending motion set 3” in document 11 -07/2693 r 13. – Based on resolutions in the following submission: • 07/2742 r 14 (Coex 20 -40 & re-org sub-group) – CIDs 5827 and 5077 (Coex 20 -40 sub-group) – Resolves 110 comments with As, Cs, and Rs – All passed by no objection • TGn vote: no objection Submission 32 Eldad Perahia (Intel)

March 2008 doc. : IEEE 802. 11 -08/0276 r 4 Motion # 302 • Moved: Approve resolution of comments found on the tab labelled “coex pending motion set 4” in document 11 -07/2693 r 13. – Resolves CIDs 5123, 5124, 5363 with Rs (Coex greenfield subgroup) – CIDs 5123 and 5363 passed in the Coex Ad Hoc with a vote of Y: 7; N: 1; Abs: 3 – CIDs 5124 passed in the Coex Ad Hoc with a vote of Y: 7; N: 1; Abs: 2 • TGn vote: 28 -23 -9, motion fails Submission 33 Eldad Perahia (Intel)