1. Coex Ad Hoc January Taipei Agenda and Report
July 2007
doc.: IEEE /2090r0
January 2008
Coex Ad Hoc January Taipei Agenda and Report
Date:
Authors:
Eldad Perahia (Intel)
Eldad Perahia (Intel)

2. July 2007
doc.: IEEE /2090r0
January 2008
Abstract
Coex Ad Hoc in November Atlanta agenda and report regarding comment resolution of LB115 (802.11n), including straw polls
Eldad Perahia (Intel)
Eldad Perahia (Intel)

3. July 2007
doc.: IEEE /2090r0
January 2008
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)
Eldad Perahia (Intel)

4. IEEE-SA Standards Board Bylaws on Patents in Standards
July 2007
doc.: IEEE /2090r0
January 2008
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)
Eldad Perahia (Intel)

5. IEEE-SA Standards Board Bylaws on Patents in Standards
July 2007
doc.: IEEE /2090r0
January 2008
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)
Eldad Perahia (Intel)

6. IEEE-SA Standards Board Bylaws on Patents in Standards
July 2007
doc.: IEEE /2090r0
January 2008
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)
Eldad Perahia (Intel)

7. Other Guidelines for IEEE WG Meetings
July 2007
doc.: IEEE /2090r0
January 2008
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)
Eldad Perahia (Intel)

8. Further Information January 2008 July 2007 doc.: IEEE 802.11-07/2090r0
IEEE Code of Ethics
IEEE-SA Affiliation FAQ
IEEE-SA Antitrust & Competition Policy
IEEE-SA LETTER OF ASSURANCE (LOA) FORM
IEEE-SA STANDARDS BOARD PATENT COMMITTEE (PATCOM) INFORMATION
IEEE-SA PATENT FAQ
IEEE 802 LAN / MAN STANDARDS COMMITTEE (LMSC) POLICIES & PROCEDURES
IEEE WLANS WORKING GROUP POLICIES & PROCEDURES
Eldad Perahia (Intel)
Eldad Perahia (Intel)

9. Overview Latest version of spreadsheet: 07/2693r5
July 2007
doc.: IEEE /2090r0
January 2008
Overview
Latest version of spreadsheet: 07/2693r5
Total number of unique unresolved comments: 174
Goals:
review first draft of submissions for all CIDs this session
Resolve CIDs for submissions previously presented
Resolve all remaining CIDs by March 2008
Eldad Perahia (Intel)
Eldad Perahia (Intel)

10. Coex Ad Hoc Rules / Procedure
July 2007
doc.: IEEE /2090r0
January 2008
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
Eldad Perahia (Intel)
Eldad Perahia (Intel)

11. Subgroups (1/2) January 2008 Coex 20-40 Coex reorg PCO L-SIG TXOP
July 2007
doc.: IEEE /2090r0
January 2008
Subgroups (1/2)
Coex 20-40
103 comments
Clause 7, , , , , , , 11.17, S.4.2
Assignee: Matt F.
07/2742 in progress
CID 5223
Assignee: Darwin Engwer, 07/2478r1
Coex reorg
8 comments
Clause 11.9, ,
Assignee: Matt, as part of Coex 20-40
PCO
16 comments
Primarily 11.16
Assignee: Tomo
Submission date: Jan 2008
L-SIG TXOP
11 comments
Clauses ,
Assignee: Yuichi
Eldad Perahia (Intel)
Eldad Perahia (Intel)

12. Subgroups (2/2) January 2008 Coex cca Coex protection mechanisms
July 2007
doc.: IEEE /2090r0
January 2008
Subgroups (2/2)
Coex cca
18 comments
Primarily clauses ,
Assignee: Eldad
Submission date: Jan 2008
Coex protection mechanisms
17 comments
Clauses , , ,
Assignee: Bjorn
07/2726 in progress
08/0004
CID 5796 assigned to Solomon
Coex GF
3 comments
Clause
Assignee: Doug Chan
07/2849 in progress
Misc
CID 5183
Commenter ed saying to reject comment
Eldad Perahia (Intel)
Eldad Perahia (Intel)

13. Submissions Related to Comment Resolution
July 2007
doc.: IEEE /2090r0
January 2008
Submissions Related to Comment Resolution
Bjorn
n-lb115-coex-comment-resolutions-protection-mechanisms.doc (15 min)
n-lb115-coex-comment-resolution-cid-5628.doc (15-20 min)
Group discussion on two transfers from Gen (open slot)
Tomo
n-lb115-submission-for-category-pco-in-coex-ad-hoc.doc (45 min)
Solomon
n-lb115-submission-cid-5796.doc
Yuichi
n-lb115-submission-coex-l-sig-txop.doc (1 hour)
n-lb115-submission-coex-l-sig-txop-misc.doc (Mon PM1)
Matt F. (Mon PM2, Mon Eve)
n-lb115-cid5279-coex doc (lots of time) (+)
Darwin (Mon PM1)
n-coex-cid-589.doc (updated to D3.01) (next week)
Eldad
n-coex-cca.doc (Wed AM1)
Misc (Mon PM1, Tues eve)
Brian (Wed AM1)
n-simulation-of mhz-cca-unfairness.ppt
Doug (GF) (Wed AM1)
Red indicates completed
submissions
(+) indicates submission
was discussed
Eldad Perahia (Intel)
Eldad Perahia (Intel)

14. Agenda for Friday Jan 11 Bjorn Tomo Matt F.
July 2007
doc.: IEEE /2090r0
January 2008
Agenda for Friday Jan 11
Bjorn
n-lb115-coex-comment-resolutions-protection-mechanisms.doc (15 min)
n-lb115-coex-comment-resolution-cid-5628.doc (15-20 min)
Tomo
(45 min)
Matt F.
n-lb115-cid5279-coex doc (lots of time)
Eldad Perahia (Intel)
Eldad Perahia (Intel)

15. Minutes for Friday Jan 11 07/2726r3 08/0004r0 January 2008
July 2007
doc.: IEEE /2090r0
January 2008
Minutes for Friday Jan 11
07/2726r3
CID 5796 assigned to Solomon and removed from submission
CID 5627 – no issues with proposed resolution
CID 5535 – no issues with proposed resolution
CID 5100 – no issues with proposed resolution
No objection to accepting submission as resolution to CIDs and bringing to motion
08/0004r0
Some discussion on having a note showing “-3”. There is already such a note in
Eldad: since the name of the parameter includes “convolutional” will we get someone asking what the value is with LDPC?
Eldad Perahia (Intel)
Eldad Perahia (Intel)

16. July 2007
doc.: IEEE /2090r0
January 2008
07/2990
Resolves Editor CID 5875, needs to be transferred to Coex
No objections to resolution
CID 5876
Bruce: question regarding “any channel width” phrase, any issue with limiting to 40MHz
Tomo: text in is the same type of wording
Eldad: “any channel width” is limited to Supported Channel Width Set
Everyone happy with current text, no objection with resolution
CID 5841 – no objections
CID 5359 – no objections
CID 5829 – no objections
CID 5109 – no objections
CID 5736 – no objections
CID 5737 – no objections
CID 5739
Adrian: Change the may to can in the second edit instruction
no objections to resolution with changes
CID 5740 – no objections
Eldad Perahia (Intel)
Eldad Perahia (Intel)

17. 07/2990 continued January 2008 CID 5741 CID 5830 – no objections
July 2007
doc.: IEEE /2090r0
January 2008
07/2990 continued
CID 5741
Adrian: can we make the second two sentences (in the first editor instruction) into a note, since they are informative. Limits comments.
No objections to change
No objections to resolution with changes
CID 5830 – no objections
CID 5831
Solomon: address the fact that traffic mixes are unknown in the rejection
CID 5360
Bruce: some grammar changes
Eldad: may needs to be changed to may
CID 5744 – no objections
CID 5358 – no objections
CID 5745 – no objections
No objection to accepting r1 of submission as resolution to CIDs and bringing to motion
Eldad Perahia (Intel)
Eldad Perahia (Intel)

18. July 2007
doc.: IEEE /2090r0
January 2008
08/0064
CID 5796
No intent to change meaning, just clarifications
Bruce: grammar corrections
No objection to accepting r1 of submission as resolution to CID and bringing to motion
Eldad Perahia (Intel)
Eldad Perahia (Intel)

19. 07/2742 January 2008 July 2007 doc.: IEEE 802.11-07/2090r0
Reviewed changes based on conference call discussion
CID 5045, 5485, 5424, 5447, 5850
CID 5850
Still have issue with changing channel width in IBSS when there is no DFS owner, changed color to green
Solomon: we have the same issue with changing channel in IBSS
Matt: general issue of dynamic parameters in IBSS when no one is in charge (see CID 5276 in MAC in 07/2999)
Adrian: might get a mix of DFS and non-DFS capable devices
Issue is held open by CID 5872
CID 5117
Adrian: making assertion the operation is fair, its never been tested. But we don’t necessary care if its fair.
Matt: changed “fair” to “sufficiently adequate user experience”
Allert: is this a “counter”
Luke is ok with “counter”
No further objection
CID 5485
Added rejection resolution text since conference call
No objections
Eldad Perahia (Intel)
Eldad Perahia (Intel)

20. 07/2742 continued January 2008 CID 5851 CID 5852, 5854 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5851
Matt: Term BSS includes IBSS
Matt: Changed IDO STA to FC HT STA 17 to broaden the language to allow a non-DFS owner to start IBSS, but changes will be un-done since DFS rules in state a STA starting an IBSS in DFS band shall be the DFS owner.
Changed to reject
No objections
CID 5852, 5854 – no objection
CID 5180
Lots of discussion on whether to change “5 GHz” to “not 2.4GHz”, points raised:
There was only 2.4 & 5 GHz at time of 11n starting, now we have 11y
We have only thought about 2.4 & 5 GHz we don’t know what the 40 MHz coex issues would be in other bands
Tomo: FC 17 restricts to 5 GHz, which is in many other places. Changes only to would not be enough
To make all the changes to draft would be complicated, reject and leave for next task group
Allert: change to FC HT AP restricts to HT device in “other band”
Since the change was un-done, “FC HT” is not added anymore
No objection to rejection
Changes based on 5180 un-done
Eldad Perahia (Intel)
Eldad Perahia (Intel)

21. 07/2742 continued January 2008 CID 5853, 5855 CID 5856, 5858 CID 5857
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5853, 5855
Changed to reject, refer to 5851
No objections
CID 5856, 5858
CID 5857
Changed “HT AP or IDO STA” to “HT AP or IDO STA that is also an HT STA” in
CID no objections
CID 5030
Resolution text modified to indicate changes based on 2.4GHz language and 5 GHz language
CID 5860
Eldad Perahia (Intel)
Eldad Perahia (Intel)

22. 07/2742 continued CID 5861 CID 5862 – no objections CID 5031
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5861
Added reference to CID 5851 in resolution
No objections
CID 5862 – no objections
CID 5031
Added resolution text stating that the use of scan results is implicit on existing rules
Tomo: is there a reference to rules?
Matt: anything that causes a trigger event must follow the trigger
Continue with CID 5808 tomorrow
Eldad Perahia (Intel)
Eldad Perahia (Intel)

23. Agenda for Saturday Jan 12
July 2007
doc.: IEEE /2090r0
January 2008
Agenda for Saturday Jan 12
Review progress
Yuichi
n-lb115-submission-coex-l-sig-txop.doc (1 hour)
Matt F.
n-lb115-cid5279-coex doc (remainder of time)
Eldad Perahia (Intel)
Eldad Perahia (Intel)

24. Status at end of Friday Jan 11
July 2007
doc.: IEEE /2090r0
January 2008
Status at end of Friday Jan 11
Unresolved CIDs (not approved by ad hoc to be motioned in TGn): 144
20/40 group: 103
CCA: 16
GF: 3
Protection: 2
Reorg: 8
L-SIG TXOP: 11
Misc: 1
PCO: 0
CIDs in 07/2724 w/ no objections: 31
CIDs still needing review: 113
Eldad Perahia (Intel)
Eldad Perahia (Intel)

25. Minutes for Saturday Jan 12
July 2007
doc.: IEEE /2090r0
January 2008
Minutes for Saturday Jan 12
07/2994
CID 5629 – no objections
CID 5470
Withdrawn by commenter (Yuichi)
CID 5630
Modified resolution by change the paragraph below
L-SIG TXOP Protection may be used even when not all HT STA in the BSS support the feature, provided that the frames using L-SIG TXOP Protection are not directed to a recipient that does not support L-SIGTXOP Protection.
changing may to can and change to note
No objection to new resolution
CID 5471 – no objection
CID 5632, 5472 – no objection
CID 5633
Discussion on whether note is enough explanation or proper explanation
Adrian crafted new language explaining the use of HT_MF on the third PPDU
no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

26. 07/2994 continued January 2008 CID 5634 CID 5635 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2994 continued
CID 5634
Tomo: also delete the language “except during the 40
MHz phase of PCO operation (see (Phased Coexistence Operation)).”
No objection to new resolution
CID 5635 – no objection
CID 5636 – no objection
CID 5637
Discussion on TXOP truncation used in conjunction with L-SIG TXOP
Modified resolution by adding a new note
no objection
No objection to accepting r2 of submission as resolution to CIDs and bringing to motion
Yuichi requested to not withdraw his comment and action his comment. Decision was made to remove CID 5470 and 5630 from document and making it r3. No objection to accepting r3 of submission as resolution to CIDs and bringing to motion
Eldad Perahia (Intel)
Eldad Perahia (Intel)

27. 07/2742 continued January 2008 CID 5808 CID 5078
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5808
Add to resolution text that capability is not changed
And delete a particular use of “shall set STA Channel Width field to 0”
No objection
CID 5078
Discussion on use of operators
modification to note to define “==“
CID 5079 – no objection
CID 5863, 5864, 5865 – no objection
CID 5080
Use the comments choice of 25 MHz
CID 5032
Create new acronyms for secondary channel offset = 1 and another acronym when = 3
Eldad Perahia (Intel)
Eldad Perahia (Intel)

28. 07/2742 continued CID 5319 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5319 – no objection
CID 5716, 5809 – no objection
CID 5081 – no objection
CID 5866
Modified resolution to say it must be a DFS only
No objection
CID 5867 – no objection
CID 5868 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

29. 07/2742 continued CID 5869 CID 5870 CID 5871 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5869
Changed from reject to counter
modification to resolution text to indicate that IBSS is forbidden from making channel width changes
Comment left open for now pending MAC changes
CID 5870
Changed IDO STA to DFS owner
No objection
CID 5871 – no objection
CID 5320 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

30. 07/2742 continued January 2008 CID 5717, 5810 Adrian
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5717, 5810
Adrian
We have two methods of changing width: secondary channel offset and E-CSA
Secondary channel offset does not impact connectivity, E-CSA could
Discussion of the issue – if secondary channel offset is changed to switch the BSS to 20 MHz, the regulatory class still remains at 40 MHz. Is this ok?
In principle, does a change of channel width imply a change of regulatory class?
Possible solution:
Allow an AP to operate a 20 MHz BSS in a 40 MHz regulatory class
Regulatory class represents what is possible, secondary channel offset represents what is current situation
Any frame that contains a new reg class field (E-CSA frame & element) with a value that corresponds to 40 MHz channel shall also include a secondary channel offset field
Comment still open
Eldad Perahia (Intel)
Eldad Perahia (Intel)

31. 07/2742 continued January 2008 CID 5082, 5083 CID 5011 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5082, 5083
No need for record of STA Channel Width of STAs
Change to counter and delete the last paragraph of
No objections to new resolution
CID 5011 – no objection
CID 5182 – no objection
CID 5084 – no objection
CID 5085
Slight modification to resolution
no objection to modified resolution
CID 5718 – no objection
CID 5719 – no objection
CID 5474 – no objection
CID 5086, 5720 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

32. July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5087, 5890
Discussion regarding Notify Channel Width Action Frames
Need to continue discussion of these CIDs
Eldad Perahia (Intel)
Eldad Perahia (Intel)

33. July 2007
doc.: IEEE /2090r0
January 2008
Status at end of Sat Jan 12
Unresolved CIDs (not approved by ad hoc to be motioned in TGn): 136
20/40 group: 103
CCA: 16
GF: 3
Protection: 3
Reorg: 8
L-SIG TXOP: 2
Misc: 1
PCO: 0
CIDs in 07/2724 w/ no objections: 51
CIDs still needing review: 85
Eldad Perahia (Intel)
Eldad Perahia (Intel)

34. Agenda for Mon Jan 14 PM1 Status and review from pre-meeting Darwin
July 2007
doc.: IEEE /2090r0
January 2008
Agenda for Mon Jan 14 PM1
Status and review from pre-meeting
Darwin
n-coex-cid-589.doc
Yuichi
n-lb115-submission-coex-l-sig-txop-misc.doc
Eldad Perahia (Intel)
Eldad Perahia (Intel)

35. Minutes for Mon Jan 14 PM1 07/2478r1 08/0105r0 January 2008
July 2007
doc.: IEEE /2090r0
January 2008
Minutes for Mon Jan 14 PM1
07/2478r1
Matt: why IDO STA using Tspecs?
Delete “ or IDO STA”
No objection to accepting r2 of submission as resolution to CID and bringing to motion
08/0105r0
Bruce: wording for “non supported HT STAs” is awkward, clearer wording?
Adrian: reference specific value of the capability field in HT Info element
IBSS?
George: one bullet is positive, one is negative, needs to be fixed
Discussion regarding rewording of the bullets
No objection to accepting r1 of submission as resolution to CID and bringing to motion
Eldad Perahia (Intel)
Eldad Perahia (Intel)

36. Agenda for Mon Jan 14 PM2 Matt
July 2007
doc.: IEEE /2090r0
January 2008
Agenda for Mon Jan 14 PM2
Matt
n-lb115-cid5279-coex doc
Eldad Perahia (Intel)
Eldad Perahia (Intel)

37. Minutes for Mon Jan 14 PM2 07/2742 CID 5087, 5890 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
Minutes for Mon Jan 14 PM2
07/2742
CID 5087, 5890 – no objection
CID 5893
Luke stated that Andrew said comment can be rejected
Resolution changed to reject
CID 5721
Similar to CID 5717, 5810
Still open, but no objections to proposed solution from 5717 & 5810
CID 5892 – no objection
CID 5722, 5088, 5089 – no objection
CID 5723 – no objection
CID 5724 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

38. 07/2742 continued January 2008 CID 5872 CID 5097
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5872
Changing resolution to refer to 5869
Allert: in DFS with radar detection on secondary, would changing to 20MHz primary be allowed?
Matt: no
Still open pending 5869
CID 5097
Discussion on setting of MIB activity threshold MIB variable
no objection
CID 5091 – no objection
CID 5090
Remove “must scan twice” since it we don’t specify the separation between scans anyways
Leave open until edited
Need to transfer related CIDs 5092, 5093 from general to Coex
CID 5096 – no objection
CID 5098 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

39. Agenda for Mon Jan 14 Evening
July 2007
doc.: IEEE /2090r0
January 2008
Agenda for Mon Jan 14 Evening
Matt
n-lb115-cid5279-coex doc
Eldad Perahia (Intel)
Eldad Perahia (Intel)

40. Minutes for Mon Jan 14 Evening
July 2007
doc.: IEEE /2090r0
January 2008
Minutes for Mon Jan 14 Evening
07/2742
CID 5725
Discussion pro and con on deleting activity threshold
Strawpoll: do you support deleting the activity threshold parameter and associated behavior?
Y: 3
N: 7
Abs: 10
Matt: suggestion for choosing MIB parameters for individual stations
No objection to rejecting
Naveen: interested in allowing exemptions to scanning for individual stations
Eldad Perahia (Intel)
Eldad Perahia (Intel)

41. 07/2742 continued January 2008 CID 5475 – no objection to rejecting
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5475 – no objection to rejecting
CID 5894 – no objection
CID 5279 – no objection
CID 5106 – no objection
CID 5277
Guido: question about Probe Response with group address?
Matt: receiver doesn’t have to worry about it since it is an illegal tx
Guido will think about it more and come back if has further issue
No other objection
CID 5731
Discussion on it makes sense for 20 MHz AP to permit 40MHz BSS
Eldad: could be used with DLS
Adrian: edits make the STA Channel Width in HT Info element becomes redundant with this change
Matt: has historical value
No objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

42. 07/2742 continued January 2008 CID 5107 CID 5108 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5107
Modify resolution text based on 5731
No objection
CID 5108 – no objection
CID 5811 – no objection
CID 5732
Slight modification to edits
No objection to modified text
CID 5278
The CID removes the countdown timer, now report at end of scan interval
Michael: what is the STA action when it receives a request? Need to add that you create the frame report upon request
Text modified accordingly
No objections to modified edits
CID 5110 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

43. 07/2742 continued CID 5747 CID 5111 CID 5748 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2742 continued
CID 5747
Adrian: slightly worried that this station isn’t qualified enough
Text modified to limit to setting address if actually transmitting frame
No objections to modified edits
CID 5111
Change resolution to counter and delete paragraph
CID still open
CID 5748 – no objection
CID 5807 – no objection
CID 5749 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

44. July 2007
doc.: IEEE /2090r0
January 2008
Status at end of Mon Jan 14
Unresolved CIDs (not approved by ad hoc to be motioned in TGn): 133
20/40 group: 102
CCA: 16
GF: 3
Protection: 3
Reorg: 8
L-SIG TXOP: 0
Misc: 1
PCO: 0
CIDs in 07/2724 w/ no objections: 82
Total CIDs in Coex still needing review: 51
Eldad Perahia (Intel)
Eldad Perahia (Intel)

45. Minutes for Tues Jan 15 Evening
July 2007
doc.: IEEE /2090r0
January 2008
Minutes for Tues Jan 15 Evening
07/2742r5
CID 5869
Previously reviewed, but open CID, now with resolution in r5
Adrian: wondering if channel selection rules still apply to IBSS
First follow rules in , then keep the value
Adrian: is there an issue with changing channels in DFS?
CID remains open
CID 5090, 5091
No objection
CID 5111
CID 5112 – no objection
CID 5750 – no objection
CID 5827
George objected to resolution
CID 5792 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

46. 07/2742r5 continued CID 5132 CID 5473 – no objection
July 2007
doc.: IEEE /2090r0
January 2008
07/2742r5 continued
CID 5132
Modified resolution to refer to 5473
No objection
CID 5473 – no objection
CID 5710 – no objection
CID 5133 – no objection
CID 5181 – no objection
CID 5714 – no objection
CID 5137 – no objection
CID 5102 – no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)

47. Individual CIDs January 2008 CID 5183 CID 5790 CID 5122 Reject
July 2007
doc.: IEEE /2090r0
January 2008
Individual CIDs
CID 5183
Reject
Making CF15 mandatory for CF16 would make all of 11y mandatory for 11n. This is not what we want to do. TGn has the following line in : “For an HT STA, the following MIB attributes shall be set to true: dot11RegulatoryClassesImplemented, dot11RegulatoryClassesRequired, and dot11ExtendedChannelSwitchEnabled.”
no objection to resolution and bringing to motion
CID 5790
Accept (deletion of S.2)
Doug may come back with a rewrite of S.2, in which case this CID will be revisited
CID 5122
counter
Comment refers to S.2 which was deleted based on CID 5790
Eldad Perahia (Intel)
Eldad Perahia (Intel)

48. Status at end of Tues Jan 15
July 2007
doc.: IEEE /2090r0
January 2008
Status at end of Tues Jan 15
Unresolved CIDs (not approved by ad hoc to be motioned in TGn): 130
20/40 group: 102
CCA: 16
GF: 3
Protection: 1
Reorg: 8
L-SIG TXOP: 0
Misc: 0
PCO: 0
CIDs in 07/2724 w/ no objections: 95
Total CIDs in Coex still needing review: 35
Eldad Perahia (Intel)
Eldad Perahia (Intel)

49. Pending Motions January 2008 July 2007 doc.: IEEE 802.11-07/2090r0
Eldad Perahia (Intel)
Eldad Perahia (Intel)

50. July 2007
doc.: IEEE /2090r0
January 2008
Motion #
Moved: Approve resolution of comments found on the tab labelled “coex pending motion set 2” in document 11-07/2693r7.
Resolves CID 5183 with reject, CID 5790 with accept, and CID 5122 with counter
All passed by no objection in ad hoc
TGn vote:
Eldad Perahia (Intel)
Eldad Perahia (Intel)

51. Approved Motions January 2008 July 2007 doc.: IEEE 802.11-07/2090r0
Eldad Perahia (Intel)
Eldad Perahia (Intel)

52. July 2007
doc.: IEEE /2090r0
January 2008
Motion # 285
Moved: Approve resolution of comments found on the tab labelled “coex pending motion set 1” in document 11-07/2693r6.
Based on resolutions in the following submission:
07/2478r2 (CID 5223)
07/2726r3 (protection mechanisms)
08/0064r0 (CID 5796)
08/0004r0 (CID 5628)
07/2944r2, 08/0105r1 (L-SIG TXOP)
11-07/2990r1 (PCO)
Resolves 44 comment with As, Cs, and Rs
All passed by no objection
TGn vote: passed by no objection
Eldad Perahia (Intel)
Eldad Perahia (Intel)