1. Coex Ad Hoc May Montreal Agenda and Report
July 2007
doc.: IEEE /2090r0
July 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)
Eldad Perahia (Intel)

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

3. Overview Submissions Comment Resolution
July 2007
doc.: IEEE /2090r0
July 2007
Overview
Submissions
Comment Resolution
Latest version of spreadsheet: 07/0339r11
Eldad Perahia (Intel)
Eldad Perahia (Intel)

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

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

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

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

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

9. Further Information July 2007 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)

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

11. Subgroups (1/2) July 2007 July 2007 doc.: IEEE 802.11-07/2090r0
40-20 in 2.4GHz
243 comments
9.20.4
Matt F.
PCO
31 comments
11.16
Tomo
L-SIG TXOP
26 comments
9.13.4,
Yuichi
ECSA
Clause 7
1 comment
Bjorn
DFS & channel selection
14 comments
11.9.7,
Bjorn & Solomon & Matt F.
Eldad Perahia (Intel)
Eldad Perahia (Intel)

12. Subgroups (2/2) July 2007 July 2007 doc.: IEEE 802.11-07/2090r0
Channel switching
36 comments
(not include 2.4 GHz)
Solomon
CCA sensing
5 comments
9.20.2,
Assaf
40/20
24 comments
Miscellaneous 40/20 CIDs in , 9.20
Vinko
Protection mechanisms
69 comments
, 9.13
Bjorn
DSSS-CCK
9 comments
11.15
Need new volunteer
Eldad Perahia (Intel)
Eldad Perahia (Intel)

13. Submissions Related to Comment Resolution
July 2007
doc.: IEEE /2090r0
July 2007
Submissions Related to Comment Resolution
Matt F.
n-lb97-cid-2582-bss-width-switching.doc
n-lb97-cid coex.doc (+)
n-lb coex-2-4ghz.ppt (+)
n-LB97-CID-1832-Operating-Mode-Bits.doc (+)
Vinko
Solomon
n-tgn-lb97-coex-dfs-ch-sel.doc (+)
n-tgn-lb97-coex-ch-switching.doc
Yuichi
Continuation of (half done) (+)
Tomoko
Bjorn
07/2098r1: 5 remaining comments from 07/560r1 & EMR
Assaf
Richard
07/2100 (L-Length error) (+)
Doug
PIFS/DIFS
Red indicates completed
submissions
(+) indicates submission
was discussed
Eldad Perahia (Intel)
Eldad Perahia (Intel)

14. July 2007
doc.: IEEE /2090r0
July 2007
EMRs
CID 1737
CID calls for removal of a paragraph, which was actioned by the Editor
Issue: Resolution for CID 1737 also refers to CID 2243, which was deferred in Montreal
Proposal: accept EMR
CID 43
CID 43 used as the indicated for a group of edited CIDs
The real CID in question is 2581
In the latest database, the editor changed CID 43 was changed backed to EI and changed CID 2581 to ER
No immediate action is necessary by Coex Ad Hoc
CID 2581 is re-addressed in 07/2098r1 which points to 07/2020
Eldad Perahia (Intel)
Eldad Perahia (Intel)

15. Wed July 11 Agenda Submissions EMR
doc.: IEEE /2090r0
July 2007
Wed July 11 Agenda
Submissions
n-LB97-CID-1832-Operating-Mode-Bits.doc
11-07/0734r2
EMR
CID 1737 to be handled by Yuichi as part of 07/734
Eldad Perahia (Intel)
Eldad Perahia (Intel)

16. Minutes for Wed July 11 11-07-0591-07
doc.: IEEE /2090r0
July 2007
Minutes for Wed July 11
Set to 0: no non-HT STAs detected; Pure HT BSS (all are 20/40, or BSS is 20)
Set to 1: OBSS non-HT STA detected; all members of BSS are HT STAs
Set to 2: no non-HT STAs detected; 20/40 BSS w/ 20 HT-STA members
Set to 3:
There are members of BSS that are non-HT STA
Eldad Perahia (Intel)
Eldad Perahia (Intel)

17. July 2007
doc.: IEEE /2090r0
July 2007 r2
CID 2250: in proposed resolution mention normative vs informative.
CID 2251: counter with “The TXOP holder should transmit a CF_End frame in a basic rate non-HT PPDU starting a SIFS after the L-SIG TXOP protected period, except during the 40 MHz phase of PCO operation (see 11.16).”
CID 2252: reject, context sensitive, different cases of CF-ED, A-MPDU vs L-SIG TXOP
CID 3322: counter, align text (including timing requirement) with
CID 2254: proposed change wants reference RXVECTOR. Currently there is no indication in RXVECTOR of a validity of L-SIG. Needs to be added to RXVECTOR, and the CID counter with modified resolution. Make as a separate submission.
CID 2256: reassign to Protection Mechanism group
CID 2259: change resolution to: Counter, resolved by CID 1852 per text in D2.04
Stopped at CID 2259
Eldad Perahia (Intel)
Eldad Perahia (Intel)

18. Thursday July 12 Agenda Submissions
doc.: IEEE /2090r0
July 2007
Thursday July 12 Agenda
Submissions
n-lb97-cid coex.doc
n-lb coex-2-4ghz.ppt
Eldad Perahia (Intel)
Eldad Perahia (Intel)

19. Minutes for Thursday July 12
doc.: IEEE /2090r0
July 2007
Minutes for Thursday July 12
n-lb coex-2-4ghz.ppt
Overview of 07/614
Specific definitions moved from clause 3 to clause
New “public” action frame, force Class 1
Discussion of data scanning (versus beacon scanning)
Data scanning allows for use of 40MHz if there is a legacy beacon but no data; beacon scanning is much more conservative in terms of not using 40MHz
Data scanning covers potential overlap of STA with OBSS STA where beacons are not heard
will have side discussion
Discussion on active scan dwell time
Dwell time allows for receipt of multiple responses
Eldad Perahia (Intel)
Eldad Perahia (Intel)

20. 11-07-614r7 Need to update resolutions in CID list
July 2007
doc.: IEEE /2090r0
July 2007 r7
Need to update resolutions in CID list
No interest in individualized STA OBSS scanning per control of the AP
Discussion on OBSS Scan RSSI Threshold
Need for threshold?
Range of MIB?
Intention was to ignore 1 or 2 Mbps beacons which have much further range than actual BSS
Eldad Perahia (Intel)
Eldad Perahia (Intel)

21. July 2007
doc.: IEEE /2090r0
July 2007
r7, continued
Strawpoll
Do you support the inclusion of an RSSI Threshold for OBSS Scan operations?
Y:11
N:6
A:4
Reasons for no vote
Too many thresholds
If detected should be reported, threshold can be abused
Threshold range is too wide
In STA 19 definition, do we need restriction to 25 & 40 channel width? There are only 25 & 40 channel in 2.4 GHz in Annex J.
Why 1 TU for the resolution for countdown timer?
Needs to be less than scan interval
40 MHz affected channel range equation
No objection to 25 MHz span on either side; allows 40 on channel 1&5 and legacy on 9,10,or 11
Eldad Perahia (Intel)
Eldad Perahia (Intel)

22. 11-07-614r7, continued MIB attributes July 2007
doc.: IEEE /2090r0
July 2007
r7, continued
MIB attributes
Scan interval (dot11BSSWidthTriggerScanInterval)
Maximum of 60 min, default of 30 min in r7
Change maximum value to 30 min
Change default value to 3 min (straw poll between 3min and 5min, 8 for 3min, 1 for 5min)
dot11BSSWidthChannelTransitionDelayFactor
Changed min to 5
Changed default 5
dot11OBSSScanActivityThreshold
strawpoll
5%: 5
3%: 6
Lots of debate on the percentage, not resolved
Eldad Perahia (Intel)
Eldad Perahia (Intel)

23. Friday July 13 Agenda 07/2110r1 (L-Length error)
doc.: IEEE /2090r0
July 2007
Friday July 13 Agenda
07/2110r1 (L-Length error)
n-LB97-CID-1832-Operating-Mode-Bits.doc r3
Eldad Perahia (Intel)
Eldad Perahia (Intel)

24. July 2007
doc.: IEEE /2090r0
July 2007
07/2110
L-Length fixed (and CID 402 resolved) by 07/2110 with no objections
No objections to bringing to motion
Eldad Perahia (Intel)
Eldad Perahia (Intel)

25. 07-0591r8 No objections to resolve CIDs
July 2007
doc.: IEEE /2090r0
July 2007 r8
No objections to resolve CIDs
No objections to bringing to motion
Eldad Perahia (Intel)
Eldad Perahia (Intel)

26. 11-07-734 July 2007 Grey: deferred from Montreal
doc.: IEEE /2090r0
July 2007
Grey: deferred from Montreal
New resolution is the upper text
Blue: agreed on resolution on Wed
Pink: modified resolution
No objection to new resolutions for CID 39, 2250, 2252, 3322, 2256, 2259 (in red font)
2251
New Resolution: Counter w/ “The TXOP holder should transmit a CF_End frame in a basic rate non-HT PPDU, including non-HT duplicate PPDU, starting a SIFS after the L-SIG TXOP protected period, except during the 40 MHz phase of PCO operation (see 11.16).”
1524
Issue with proposed resolution is that NAV reset is no longer restricted to RTS
Alternate solution is to restrict the LSIG TXOP initiation to RTS/CTS
Issue with control wrapped RTS frame
No objection to transfer to MAC
174
Strawpoll
Do you support limiting MF HT-Length to value equivalent to duration of (4095/6Mbps)?
Y 2+18
N 1
A 0
Eldad Perahia (Intel)
Eldad Perahia (Intel)

27. July 2007
doc.: IEEE /2090r0
July 2007
Monday July 16 (5-6pm) r8
Green highlight shows difference between r7 and r8
Data scanning would require
Scanning period on the order of secs to not disturb OBSS traffic (like TCP flows)
Passive scanning
May need 10s of msec dwell
Scan multiple channels
RSSI Threshold
Comments:
Max of 0dBm allows for override of CCA mechanism, perhaps to change max to CCA threshold
Perhaps compromise is to report RSSI value and move decision to AP
Eldad Perahia (Intel)
Eldad Perahia (Intel)

28. July 2007
doc.: IEEE /2090r0
July 2007
Strawpoll
Do you support the inclusion of an RSSI Threshold for OBSS Scan operations?
Y:2
N:53
Eldad Perahia (Intel)
Eldad Perahia (Intel)

29. 11-07-614r8 continued Issues with 07/614 which would lead to no vote
July 2007
doc.: IEEE /2090r0
July 2007
r8 continued
Issues with 07/614 which would lead to no vote
Activity threshold
100 – 400
Data traffic scanning
Against 40 MHz in 2.4 GHz
Clean up of resolution column
Eldad Perahia (Intel)
Eldad Perahia (Intel)

30. Agenda for Wednesday July 18, 1:30-3:30pm
doc.: IEEE /2090r0
July 2007
Agenda for Wednesday July 18, 1:30-3:30pm
EMR
Resolve CID 1737
Discuss CID 43
Approve for motion the previously resolved LSIG TXOP comments in n-coex-lsigtxop-motion-ready.xls r9
Eldad Perahia (Intel)
Eldad Perahia (Intel)

31. Minutes for Wednesday July 18, 1:30-3:30pm
doc.: IEEE /2090r0
July 2007
Minutes for Wednesday July 18, 1:30-3:30pm
No objection to accepting EMR of CID 1737
No objection to bring to motion LSIG TXOP CIDs in n-coex-lsigtxop-motion-ready.xls
07/614r9
RSSI parameter of OBSS Scan parameters deleted
dot11BSSWidthTriggerScanInterval
Strawpolls
Unhappy with value of 180
Y:19
N:10
Would like 1800: 0
Choose one:
600: 23
300: 7
neither: 1
r10 has default value change to 600
Eldad Perahia (Intel)
Eldad Perahia (Intel)

32. 07/614r9 July 2007 dot11OBSSScanActivityThreshold
doc.: IEEE /2090r0
July 2007
07/614r9
dot11OBSSScanActivityThreshold
Discussed changing period from “dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval seconds” to “dot11BSSWidthTriggerScanInterval” seconds
Discussion of minimum, maximum, and default
Straw polls
Time interval to measure activity for exemption from scanning:
“dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval” seconds: 36
“dot11BSSWidthTriggerScanInterval” seconds: 13
Straw poll
Do you wish to modify the minimum value of the dot11OBSSScanActivityThreshold?
Y: 27
N: 14
Do you wish to the minimum value to be:
1: 13
100: 27
Neither: 6
Eldad Perahia (Intel)
Eldad Perahia (Intel)

33. July 2007
doc.: IEEE /2090r0
July 2007
07/614r9
Do you wish to modify the maximum value of the dot11OBSSScanActivityThreshold?
Y: 24
N: 17
Do you wish the maximum value to be 500?
Y: 25
Do you wish the default value to be:
500: 30
300: 17
100: 18
Eldad Perahia (Intel)
Eldad Perahia (Intel)

34. July 2007
doc.: IEEE /2090r0
July 2007
07/614r10
Do you accept 07/614r10 as resolution to the CIDs in said document?
Y: 22
N: 29
Do you accept 07/614r10 as resolution to the CIDs in said document, with the displayed change of “should” to “shall”?
N: 23
Remove all references to 40 MHz operation in 2.4 GHz band
Y: 21
N: 17
A: 21
Eldad Perahia (Intel)
Eldad Perahia (Intel)

35. Minutes for Wednesday July 18, 5:30-6pm
doc.: IEEE /2090r0
July 2007
Minutes for Wednesday July 18, 5:30-6pm
11-07/2054r0
Proposes that 4 CIDs (2572, 2893, 2575, 2894 ) are transferred to TGy
Issue is that TGy is going to sponsor ballot
It is believed that the draft 3.0 of TGy resolves the CIDs; this needs to confirmed
Defer these CIDs in 07/2054r1
No objection to resolving CID 1770 based on 11-07/2054r1
Eldad Perahia (Intel)
Eldad Perahia (Intel)

36. Motions July 2007 July 2007 doc.: IEEE 802.11-07/2090r0
Eldad Perahia (Intel)
Eldad Perahia (Intel)

37. Motion # 179 (approved unanimously)
July 2007
doc.: IEEE /2090r0
July 2007
Motion # 179 (approved unanimously)
Moved: Approve resolution of comments found on the tab labeled “coex pending motion set 1” in document 11-07/0339r13.
Based on resolution for L-Length in 07/2110r2
Resolves 1 comment with C
Passed by unanimous consent
Eldad Perahia (Intel)
Eldad Perahia (Intel)

38. Motion # 180 (approved unanimously)
July 2007
doc.: IEEE /2090r0
July 2007
Motion # 180 (approved unanimously)
Moved: Approve resolution of comments found on the tab labeled “coex pending motion set 2” in document 11-07/0339r13.
Based on resolutions for the Operating Mode Bits in r8
Resolves 16 comments with As and Cs
Passed by unanimous consent
Eldad Perahia (Intel)
Eldad Perahia (Intel)

39. Motion # 181 (approved unanimously)
July 2007
doc.: IEEE /2090r0
July 2007
Motion # 181 (approved unanimously)
Moved: Approve resolution of comments found on the tab labeled “coex pending motion set 3” in document 11-07/0339r13, excluding CID 1853.
Based on resolutions for the L-SIG TXOP group in n-coex-lsigtxop-motion-ready.xls
Resolves 11 comments with As, Cs, and Rs
Passed by unanimous consent
Eldad Perahia (Intel)
Eldad Perahia (Intel)

40. July 2007
doc.: IEEE /2090r0
July 2007
Motion #
Moved: Approve resolution of comments found on the tab labeled “coex pending motion set X” in document 11-07/0339rY.
Based on resolutions for the ???? group
Resolves YYY comments with As, Cs, and Rs
Passed by unanimous consent
Eldad Perahia (Intel)
Eldad Perahia (Intel)