doc.: IEEE 802.11-09/0226r2€¦ · Web viewMoved Matthew, 2nd Naveen 9 yes, 0 no, 1 abstain –...

March 2009 doc.: IEEE 802.11-09/0226r2

IEEE P802.11Wireless LANs

Consolidated TGn SB0 – CRC minutes

Date: 2009-02-11

Author(s):Name Affiliation Address Phone email

Jon Rosdahl CSR Highland, Utah +1 (801)492-

4023 [email protected]

Sheung Li SiBEAM 555 N. Mathilda Ave, Sunnyvale, CA 94085

+1 (408) 245-3120 [email protected]

Adrian Stephens Intel +44 1954 204609 [email protected]

m

Minutes page 1 Jon Rosdahl, CSR

AbstractThis Document contains the cumulative minutes for the TGn Sponsor Ballot 0 (SB0) Comment Resolution Committee (CRC) meetings, starting with the 802.11 Interim Jan 19-22, 2009, and the telecons between then and the March 2009 plenary session. This file will be revised to include all the minutes for SB0 resolution meetings/sessions, and a new file used for processing the recirculation ballot.

Page 2: Jan 19-22 F2F sessionsPage 7: Jan 28, telcon4: Feb 4 telconPage 20: Feb 11 telconPage 24: Feb 18 telcon

March 2009 doc.: IEEE 802.11-09/0226r2

January 802.11 Interim Session – Los Angeles, California – F2F sessionsJan 19-22, 2009:Executive Summary (see also Chairs’ meeting doc 11-08-1460 and closing report doc 11-09-0107):

1. Draft 7.0 passed recirculation ballot LB138 with 281 approve, 14 not approve, 95.25% affirmative. This was a recirculation ballot on an unchanged draft leading to a sponsor ballot.

2. The first sponsor ballot for TGn completed on January 10, 2009. 277 were eligible to vote. 224 votes were received, and the vote passed with 158 approve, 45 not approve, 17 abstain, 77.8% affirmative.

3. 241 comments were submitted on the sponsor ballot. Resolution of these comments will continue into teleconferences after this meeting.

4. There were no changes to the timeline anticipating publication in March 2010.

Note 1: Relative to presentations, these minutes are intended to offer a brief summary (including document number) of each of the presentations to facilitate review and recall without having to read each of the presentations. Most of the ‘presentation related’ minutes are built directly from selected slides and therefore are not subjective. An effort was made to note obscure acronyms. As always Q&A is somewhat subjective on my part and therefore open to question.Note 2: Only motions resulting in changes to the draft are specially numbered. This is done so that there is a cross reference between specific resolutions and session votes.******************************************************************************

Detailed cumulative Session minutes follow:

Monday; January 19, 2009; 4:00 PM – 6:00 PM PST [~28 attendees, ~1 new]

1. Meeting is called to order by TGn chair at 4:03 pm.2. Chair’s (Bruce Kraemer) affiliation is Marvell.3. Vice-chair’s (Sheung Li) affiliation is SiBEAM. Also serving as secretary this week.4. Technical Editor’s (Adrian Stephens) affiliation is Intel.5. Chair’s opening report is currently 11-08-1460r0, closing document will to be 11-09-0107r0,

minutes are currently 11-09-0106r0, editor’s report is currently 11-09-0038r0.6. Primary meeting room is Santa Monica. Secondary meeting room is Olympic II. There will

be one parallel session this week – Weds PM1 only.7. Patent policy was presented, including call for patent assurances.8. There was no response to the request for essential patent claims, or any questions on the

patent policy.9. Executive summary of the minutes of the November 08 meeting (as listed in 11-08-1251r2)

presented.10. Motion to approve November ’08 (Dallas) TGn minutes as contained in 11-08-1251r2.

Moved by Sheung Li (SiBEAM), Seconded by Don Schultz (Boeing). Approved by unanimous consent.

11. 48 comment resolutions from LB136 resulting in no changes to the text were approved in November ’08 meeting.


March 2009 doc.: IEEE 802.11-09/0226r2

12. The working group had approved recirculation ballot LB138 on these comments, and granted conditional approval to move to sponsor ballot. Zero no votes were received in this process.

13. TGn moved ahead to the sponsor ballot, with ballot closed Jan 10, 2009.14. LB138, the sixth recirculation ballot for TGn Draft 7.0 resulted in 315 votes received, out of

325 eligible people in the ballot (96.9% return rate). The approval rate was 281 affirmative, 14 negative (95.25% affirmative). Composite comments from this ballot are in 11-08-1445r1.

15. The first sponsor ballot for TGn ran from Dec 11, 2008 to Jan 10, 2009. 277 were eligible to vote, 224 votes received, meeting the 75% return rate. The vote passed 158 yes, 45 no, 17 abstain (77.8% affirmative) with 241 comments received. A sponsor recirculation ballot is expected sometime after the Jan ’09 meeting.

16. Focus of the week will be comment resolution on the sponsor ballot.17. The meeting will largely be conducted in full session with various sub-groups meeting to

resolved their respective comments. The allocation of topics in slide 33 of 11-08-1460r0 was adjusted.

18. The group decides without objection to proceed with the TGn work plan as contained on slides 28-33 (with any minuted amendments in 1460r1).

19. Editor’s report in 11-09-0038r0 is presented by Adrian Stephens (Intel).20. Joe Levy (Interdigital) presents an overview of 11-09-0101r0, the General resolution

document for the EVE1 session.21. Eldad Perahia (Intel) presents an overview of the MAC comments.22. Vinko Erceg (Broadcom) presents an overview of the PHY/BEAM comments.23. Adrian reviews the Editorial comments in detail from 11-09-0025r0.24. Joe reviews the General comments in detail from 11-09-0101r0.25. Discussion by the group leads to a consensus of disagreement with the comments in CID

145, 146.26. Discussion of the group leads to mixed feelings about CID 21 and a consensus of

disagreement.27. TGn is recessed at 6:02 pm.

Monday; January 19, 2009; 7:30 PM – 9:30 PM PST [~17 attendees]

28. Meeting is called to order by TGn chair at 7:33 pm.29. Joe Levy (Interdigital) reviews the General comments in 11-09-0101r0, starting with CIDs

52-54, requests to remove sections of text. Similar resolution is possible for all of these comments – they do increase robustness and other advantages.

30. Joe presents and the group debates text on the resolution to CID 21 discussed earlier – “Disagree – While the features cited may not be of value to the commenter, the consensus of the Task Group N and Working Group 802.11 is that they have technical merit. The comment resolution committee sees merit in the features referred to in the comment, and therefore disagrees with the proposed change.”

31. Above resolution is mirrored in the proposed resolutions to CID 52, 53, 54, noting disagreement and discussion of merit points of the capabilities discussed.

32. CID 148 requests STBC (one of the capabilities to be removed above) be made mandatory. This has been addressed earlier in CID 2976, and a similar resolution will be used.

33. Patent issues in CID 57 and CID 144 are reviewed. One option is to push this back to Patcom, noting that the disputed piece of IP prevents this group from moving forward.

34. Proposal is made for the group take a poll to determine if patent-encumbered material be removed.


March 2009 doc.: IEEE 802.11-09/0226r2

35. The WG chair takes the action to take the package of material back to Patcom and Revcom for resolution.

36. CID 48 notes ambiguity in text, and a resolution to provide a better explanation is taken. The WG editor will provide this text.

37. CID 49 is transferred to Coex.38. CID 164 refers to QoS STA and AP definitions that are already in the baseline document, so

the comment is outside the scope of this Task Group.39. CID 64 references ambiguities in HT-STA definition that are not considered to be ambiguous

by the group.40. CID 82 references proper use of MIBs. Debate on this extends beyond the time available, so

work will be done offline.41. TGn is recessed at 9:30 pm.

Tuesday; January 20, 2009; 10:30 AM – 12:30 PM PST [~24 attendees]

42. Meeting is called to order by TGn chair at 10:32 am.43. Eldad Perahia (Intel) reviews 11-09-0063r0, the presentation on Coex issues, and 11-09-

0064r0 with proposed resolutions to the CID. There are no objections to the proposed resolutions.

44. The resolution to CID 111 is clarified to be normative.45. Yuichi Morioka (Sony) presents 11-09-0129r1 with updates to proposed resolution

characterization from “Reject” to “Disagree.”46. Matt Fischer (Broadcom) presents 11-09-0119r0, starting with CID 227. CID 152 is clarified

to note that 5 and 10 MHz channels are only used on a licensed basis, and coexistence is assured by regulatory means. No objections to proposed resolutions in this document.

47. TGn is recessed at 12:34 pm.

Tuesday; January 20, 2009; 1:30 PM – 3:30 PM PST [~14 attendees]

48. Meeting is called to order by TGn chair at 1:32 pm.49. Matt Fischer (Broadcom) reviews 11-09-0120r0, the MAC comment resolutions. There are

no objections to the proposed resolutions.50. TGn is recessed at 3:30 pm.

Wednesday; January 21, 2009; 8:00 AM – 10:00 AM PST [~22 attendees]

51. Meeting is called to order by TGn chair at 8:02 am.52. Vinko Erceg (Broadcom) reviews 11-09-0147r0, the PHY comment resolutions.53. CID 22 was clarified as withdrawn by the commenter. Per sponsor ballot resolution

procedure, this is resolved as disagree with the e-mailed withdrawal cited.54. CID 232 inspired serious debate over how any proposed change could be meaningful for

such a specification statement55. Hongyuan Zheng (Marvell) reviews 11-09-150r1, the BEAM comment resolutions. No

objections to these resolutions.56. TGn is recessed at 10:04 am.

Thursday; January 22, 2009; 8:00 AM – 10:00 AM PST [~29 attendees]

57. Meeting is called to order by TGn chair at 8:05 am.


March 2009 doc.: IEEE 802.11-09/0226r2

58. John Barr (Motorola) presents 11-09-0127r0, a tutorial on adaptive frequency hopping Bluetooth.

59. Joe Levy (Interdigital) reviews 11-09-0101r1 on General comment resolutions.60. CID 145 and 146 will be taken offline for further tuning of the resolution.61. Matt Fischer (Broadcom) reviews 11-09-0119r2 on MAC comment resolutions. No

objections to the proposed comment resolutions except for CID 228, which will be deferred for later discussion.

62. There is no objection to motioning the MAC comment resolutions presented.63. TGn is recessed at 10:01 am.

Thursday; January 22, 2009; 4:00 PM – 6:00 PM PST [~26 attendees]

64. Meeting is called to order by TGn chair at 4:03 pm.65. Motion #387: Move to approve resolution of comments found on the tab labelled “coex

pending motion set 1” in document 11-09-0037r1. Moved by Eldad Perahia (Intel). Seconded by Peter Loc (Ralink). Approved by unanimous consent.

66. Motion #388: Move to approve resolution of comments found on the tab labelled “coex pending motion set 2” in document 11-09-0037r2. Moved by Eldad. Seconded by Matt Fischer (Broadcom). Approved by unanimous consent.

67. 58 coex comments remain unresolved.68. Motion #389: Move to approve resolution of comments in 11-08-1445-02-000n-lb138-

composite comments.xls tab “Comments” Moved by Adrian Stephens (Intel). Seconded by Ian Sherlock (TI). Approved by unanimous consent.

69. Motion #390: Move to accept the comment resolutions in document 11-09-0025-01-000n-tgn-sb-editor-comments.xls on the “Editorial” tab. Moved by Adrian. Seconded by Vinko Erceg (Broadcom). Approved by unanimous consent.

70. Motion #391: Move to accept the comment resolutions in document 11-09-0025-00-000n-tgn-sb-editor-comments.xls on the “Minor Technical” tab. Moved by Adrian. Seconded by Jon Rosdahl (CSR). Approved by unanimous consent.

71. Motion #392: Move to approve P802.11n D7.02 as the IEEE 802.11 TGn draft. Moved by Adrian. Seconded by John Barr (Motorola). Approved by unanimous consent.

72. Motion #393: Move to direct the editor to resolve all characteri-by-character duplicate comments by copying the “Resolution” and “Resn Status” field from “original” P802.11n sponsor ballot approved comment resolutions to their duplicates, identified by having a non-empty “Duplicate of CID” value that identifies the original comment. Moved by Adrian. Seconded by Ian. Approved by unanimous consent.

73. Motion #394: Move to accept comment resolutions in spreadsheet 11-09-0183-00-000n-SB-phy-beam-comment-resolution-spreadsheet.xls tabs. Moved by Vinko. Seconded by Jon. Approved by unanimous consent.

74. Motion #395: Move to accept comment resolutions in 11-09-0083r1 tab “motion_sb0_a”. Moved by Matt. Seconded by Adrian. Approved by unanimous consent.

75. Straw poll on 20/40 coexistence. (1) No change, (2) 802.19 does a recommended practice, (3) Add an informative annex on scanning in .11n, (4) Add optional scanning in .11n, (5) Add mandatory scanning in .11n or detection in .11n, (6) Remove 40 MHz in 2.4 GHz from .11n

76. Straw poll results for the above [Y-N] are (1) 13-14, (2) 8-9, (3) 6-11, (4) 0-16, (5) 3-14, (6) 5-13

77. Straw poll on should these options be submitted to the sponsor poll. 1 Yes to 14 No


March 2009 doc.: IEEE 802.11-09/0226r2

78. The teleconference schedule is adjusted per slide 61 of 11-08-1460r4.79. Discussion on amending the timeline to show recirculation sponsor ballot in Feb 2009

instead of May 2009, and publication in Nov 2009 instead of March 2010 results in a decision to make no changes now, and revisit the topic in the March 2009 session. There is no objection to this approach.

80. TGn is recessed at 5:56 pm.


March 2009 doc.: IEEE 802.11-09/0226r2

January 28, 2009 Telcon:Attendees:

Voting members: Doug Chan – Cisco; Dave Bagby Calypso Ventures, Inc.;, Joe Levy, Interdigital; Jon Rosdahl, CSR; Eldad Perahia, Intel; Vinko Erceg, Broadcom; Peter Loc, Matthew Fischer, Broadcom; Adrian Stephens, Intel; Naveen Kakani, Nokia; Bruce Kraemer, Marvel; Non-Voter: Paul Feinberg, Sony;

Meeting called to order by Joe Levy at 9:05amMinutes taken by Jon RosdahlProposed Agenda:

1. Attendance2. IPR and other relevant IEEE policies (see pointers above).3. Agenda for this call.

4. Gen comment resolution 11-09/0101r2

5. Mac comment resolution 11-09/0120r02

6. Adjourn

1. Attendance – 9 voters on call 1 non-voter

2. IPR and other relevant IEEE policies (see pointers above).

NOTE WELL: Please review the documents at the following links:- IEEE Patent Policy - http://standards.ieee.org/board/pat/pat-slideset.ppt- Patent FAQ - http://standards.ieee.org/board/pat/faq.pdf- LoA Form - http://standards.ieee.org/board/pat/loa.pdf- Affiliation FAQ - http://standards.ieee.org/faqs/affiliationFAQ.html- Anti-Trust FAQ - http://standards.ieee.org/resources/antitrust-guidelines.pdf- Ethics - http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf- IEEE 802.11 Working Group Policies and Procedures - https://mentor.ieee.org/802.11/public-file/07/11-07-0360-04-0000-802-11-policies-and-procedures.doc

3. Agenda for this call. – agreed as proposed.

4. Gen comment resolution 11-09/0101r2

4.1.0 – slide 5 CID 145/146 – proposed resolution:

• Disagree - 802.11 has from the onset created a PHY aware MAC that supports multiple PHYs. Having a MAC be PHY aware has provided a means to enhance the features that 802.11 has included in its current standard. Being able to advertise which MAC specific features are being supported enhances the feature sets that can be supported.

– Add comment on why restricted at this time and how it can be extended.

– Add PAR comment.


http://standards.ieee.org/board/pat/pat-slideset.ppt

https://mentor.ieee.org/802.11/public-file/07/11-07-0360-04-0000-802-11-policies-and-procedures.doc


http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf

http://standards.ieee.org/resources/antitrust-guidelines.pdf

http://standards.ieee.org/faqs/affiliationFAQ.html

http://standards.ieee.org/board/pat/loa.pdf

http://standards.ieee.org/board/pat/faq.pdf

March 2009 doc.: IEEE 802.11-09/0226r2

• Being able to advertise what MAC specific features are being supported enhances the feature sets that can be supported.

• Features that have been developed for specific PHYs have been indicated in variable and elements that are specific to the PHY being created. If a legacy PHY could make use of a new MAC feature, that would needs be verified, and a means to indicate when it would be viable or not in a generic means for compatibility with the legacy PHYs that do not make use of the new feature. No change to the HT-extended Capability field is warranted at this time.

4.1.1 Adjust the 2nd to last sentace of last bullet to read:

It would need to be verified if a legacy PHY can make use of a new MAC features. There maybe compatibility issue of Legacy devices not being aware of some new features.

4.1.2 remove “at this time” from the last sentence.

4.1.3 remove the redundant sentence from slide 5

4.1.4 need to add a specific PAR comment – it is there already in the first sentence.

4.1.5 – no objection to the final read:

Disagree - 802.11 has from the onset created a PHY aware MAC that supports multiple PHYs. Having a MAC be PHY aware has provided a means to enhance the features that 802.11 has included in its current standard.

Being able to advertise which MAC specific features are being supported enhances the feature sets that can be supported.

Features that have been developed for specific PHYs have been indicated in variable and elements that are specific to the PHY being created. It would need to be verified if a legacy PHY can make use of a new MAC feature. There may be a compatibly issue of legacy devices not being aware of some new features. No change to the HT-extended Capability field is warranted.

4.1.6 Motion Number 396: Move to accept resolution for CID 146/145

Moved: Jon R., 2nd Peter Loc – 10 yes, 0 no, 0 abstain -- passes

4.2 CID 148, 162, 64, 21, 48

Motion to Slide 7, 11, 13, and 15 respectfully doc 101r3

Moved: Adrian, 2nd Jon R.

4.2.1 Slide 9 does not look complete? Not in motion.

4.2.1.5 – Bruce Kraemer joined call. 11 voters 1 nv at this time.

4.2.2 Motion did not look right, so it was retyped and formally remade


March 2009 doc.: IEEE 802.11-09/0226r2

4.2.3 Motion Number 397: Move to accept the resolutions for CID 148, 162, 64, 21, 48 as contained on slides 7, 11, 13, 15 as shown in 101r3.

Moved: Adrian, 2nd Jon R. -- 10 yes, 0 no, 1 abstain -- passes

4.3 CID 82 – Adrian and Brian have not proposed a new resolution – still pending AI.

4.4 CID 52, 53, 54 do not have text, and looking for a volunteer – Joe to try to craft start.

4.5 CID 63: see slide 21 for proposed resolution.

• Agree in Principle:

• Move PSMP (HTM 12.x) from table A.4.20.1 to table A.4.4.1 and label as PC 35.x

4.5.1 remove the “Detailed review necessary” from the proposed resolution.

4.5.2 checked with editor to ensure the instructions were sufficient.

4.5.3 Motion Number 398: Motion to approve the mofied resolution as contained in slide 21 in doc 09/101r3 as the resolution for CID 63:

• Agree in Principle:

• Move PSMP (HTM 12.x) from table A.4.20.1 to table A.4.4.1 and label as PC 35.x

Moved: Adrian, 2nd Jon -- 10yes, 0 no, 1abstain -- passes

4.6 CID 232/233 slide 24

• Propose to Agree 233

• Propose to Agree in Principle 232:

– Current text D7.0: RCPI shall equal the received RF power within an accuracy of +/- 0. 5 dB (95% confidence interval) within the specified dynamic range of the receiver.

– Proposed additional/replacement text: Improved RCPI accuracy is optional, the RCPI accuracy shall equal the receiver RF power within the accuracy indicated in table A.4.20.2 HT PHY features (95% confidence interval) within the specified dynamic range of the receiver.

4.6.1 Disagreement on resolution. This is possibly a MIB variable issue. There may need a MIB change, but the PICs entry may be sufficient. The accuracy of the device would be indicated by selecting the PICs entry.. this is to indicate that the device is at a higher accuracy than otherwise required. Concern that this may set a bad precedence for a standard. To have the device be able to report what the accuracy level being used may be better. If we can make this a more informative way and indicated in a different means.

4.6.2 Counter proposal, if we were to take the commenter’s proposed change, but change “may” to “can” then this would be sufficient. This would become


March 2009 doc.: IEEE 802.11-09/0226r2

P323L58 change " range of the receiver." to " range of the receiver. RCPI measurement can be made with improved accuracy.

4.6.3 Question on CID 233 which has a new set of PICs boxes. There were objections to adding any of the PICs boxes. Counter proposal to reject or add a MIB variable.

4.6.4 It was recalled that the objections in the F2F were against adding a MIB variable, and that the PICs seemed to be more palatable. Having a PICs on a note does not make sense to some on the call.

4.6.5 more time will be needed to address both CID 232 and 233… discussion will continue on the TGn reflector.

4.7 CID 57/144 Patent Issues – Proposed resolution is repeat of what we have done before, but the change of the comment resolution needs to have the comment type be changed to “Unresolvable”

4.7.1 Given we are waiting on further advice, it is truly Unresolvable.

4.7.2 New Proposed resolution after discussion of changes:

• Unresolvable

• 802.11 WG, TGn and the TGn CRC believe they have faithfully followed the procedures provided by PatCom concerning the soliciting of notice of potentially essential patents and associated LOAs as specified in: http://standards.ieee.org/board/pat/pat-slideset.ppt

• TGn CRC is restricted from any additional action beyond these procedures.

• TGn CRC has asked the WG11 chair to pass this comment on to PatCom for further review and advice. While awaiting further advice, TGn CRC and WG11 will continue to follow IEEE IP procedures.

4.7.3 See IEEE-SA Ops Manual, 6.3.1 Public Notice – one paragraph explains when LOAs are not received, and one for when LOAs are received. We need to look at the requirements of this Public notice policy, and then adjust accordingly. The editor to check on which Notice is actually in the draft and make reccomendations.

4.7.4 more time neeeded to be spent on this to address the specifics, The change to the header material should be noted in this resolution. Continue discussion on the TGn reflector. Defferred comment till new proposal and public notice field is checked.

4.8 General Ad-Hoc will take up deffered items on a subsequent call

5. Mac comment resolution

120r2 posted today.

5.1 CID 108 (page 12 120r2) -- Proposed Resolution:

Principle – Dual CTS protection used to allow NULL frame, but that has been deleted, so TGn editor to remove bullet item iii).



March 2009 doc.: IEEE 802.11-09/0226r2

Reviewed the cases and the context of the comment. And then decided that the comment should be “disagree” the new proposed text:

Disagree – The case described in item iii) is when Dual CTS protection has been used to protect the entire STBC exchange, in which case, it is no longer required to send control response frames during the exchange using a legacy rate (for example, an ACK frame in response to a DATA frame). This allows STBC STAs to exchange frames using STBC in both directions, which may be necessary, given their relative locations.

5.1.2 Motion Number 399: Move that CID 108 be resolved as noted in doc 09/120r3.

Moved by Matthew, 2nd Joe L. -- 10 yes, 0 no, 1 abstain -- passes

5.2 CID 109 (page 12 120r2)

Reviewed comment

Proposed resolution:

Disagree – I believe that this case is not allowed – that is, a control response frame is not allowed to have the MRQ bit set to 1

5.2.1 If you are not the Txop owner, you would not be able to set this. In 9.18.2 we may be able to note the descrepency. The problem is that if you are not the TXoP owner, and set the MRQ bit then you are setting a requirement that the Txop owner may not be able to honour. Page 167 line 46 has a sentence that precludes a need to do this. We may want to do this under the transmit beamforming that are not under the reverse direction protocol. The question is which way to go on the resolution.

5.2.2 Dave B. dropped due to power loss. Voters now at 10.

5.2.3 if bi-directional training is not allowed, then what is the choice?

5.2.4 page 118 item b change the subbullets and move them up to item a and thus delete item c. and change from a may to “Shall”

5.2.5 leave item c but delete the “what is a control frame” from 9.6.0e.1

5.2.6 CID 109

New Proposed Resolution:

Principle – TGn editor to delete the phrase “that is not a control response frame” from item c) in 9.6.0e.1.

5.2.7 Motion Number 400: Move to accept the resolution for CID 109 as documented in doc 9/120r3

Moved Matthew 2nd Bruce 7 yes, 0 no, 2 abstain – passes

5.3 CID 93 Proposed Resolution:


March 2009 doc.: IEEE 802.11-09/0226r2

Principle – two choices – either change “may” to “shall”, or change “the transmitting STA may transmit the frame using a rate supported by the receiver STA” to “the transmitting STA may transmit the frame using any rate that is supported by the receiver STA”

5.3.1 there is no difference in “may use a” is identical to “may use any”

5.3.2 the commenter is correct in that there is not away to block the sending of some rates.

5.3.3 discussion on the alternatives.

5.3.4 Motion Number 401: Move to adopt the following as the resolution:Principle – TGn Editor to change “may” to “shall”

Moved: Matthew 2nd Adrian -- 7 yes, 0 no, 2 abstain – passes

5.3.5Adrian had to drop from the call… 9 on the call

5.4 CID 202

5.4.1 Discussion on this topic has occurred in the past, but unable to provide a ready answer as this is a hard thing to evaluate.

5.4.2 proposed to remove the “equal to” portion of the statement.

5.4.3 related to this, is a discussion that ws hard to hear. The statement where you transmit a frame at a given rate. That the next transmission will be at a rate less than or equal to that frame. The next transmission is a new transmission and follows the original rules, so the ratcheting does not occur. The next transmission that is restricted on the rate selection for reverse direction, but it is unclear if that is true.

5.4.4 if we simply agree with the commentor’s proposed change:

"Eliminate from the CandidateMCSSet all MCSs that have a Data Rate greater than the Data Rate of the received PPDU (the mapping of MCS to Data Rate is defined in 20.6"

5.4.5 Dave returned; voter count is 10.

5.4.6 Motion Number 402: Move to accept the commentor’s proposed recommendation for CID 202

Moved Matthew, 2nd Naveen 9 yes, 0 no, 1 abstain – passes

5.5 CID 203

5.5.1 discussion and review of comment

Disagree – it is a note because it is a reminder of normative behavior described elsewhere, and therefore, it cannot be promoted to normative language. See the first sentence of 9.2.5.4.

5.5.2 the note was added before due to a comment. We have informative repetition to help the normative text. The issue in this case is that it may not support +HTC, which is not really allowed. This is a note to remind folks what is being supported.


March 2009 doc.: IEEE 802.11-09/0226r2

5.5.3 suggest that we add to the Note the reverence from the resolution to the Note to help clarify the location of the normative location. The normative definitions are in one place, and then we have these informative note to help indicate where it is.

5.5.4 The reference in the notes is precendence.

5.5.5 Proposed Resolution: Agree in Principle – it is a note because it is a reminder of normative behavior described elsewhere, and therefore, it cannot be promoted to normative language – TGn editor to change the note by adding “as described in 9.2.5.4.” to the end of the cited sentence.

5.5.6 Motion Number 403: Move to adopt proposed resolution for CID 203 as contained in 09/120r3.

Moved: Matthew, 2nd Naveen -- 9 yes, 0 no, 1abstain -- passes

6. Adjourn by mandatory cut-off of the call at 1pm EST

Additional documents of interest:

11-09/0206r0 Proposed SB IP Comment Resolution Text

11-09/0024r1 TGn SB Composite Comments

11-08/1460 TGn Meeting Report – Jan 09

11-08-0024-00-000n TGn SB Composite Comments

11-08-0023-00-000n Sponsor Ballot Comment Attachment

https://mentor.ieee.org/802.11/file/09/11-09-0101-02-000n-802-11-tgn-gen-ad-hoc-overview.ppt

https://mentor.ieee.org/802.11/file/09/11-09-0120-02-000n-sb0-mac-all-cids.doc







March 2009 doc.: IEEE 802.11-09/0226r2

Feb 4, 2009 Telecon:Attendees: 18 attendees:

LastName FirstName MI Affiliation StatusAdachi Tomoko - Toshiba Corporation VoterBagby David - Calypso Ventures, Inc. VoterBarr John R Motorola, Inc. VoterChan Douglas S Cisco Systems, Inc. Voterde Vegt Rolf J Qualcomm Incorporated VoterErceg Vinko - Broadcom Corporation VoterFischer Matthew J Broadcom Corporation VoterHart Brian D Cisco Systems, Inc. VoterKakani Naveen K Nokia Corporation VoterKraemer Bruce P Marvell VoterLevy Joseph - InterDigital

Communications, LLCVoter

Loc Peter - Ralink Technology, Corp. VoterMesecke Sven - Buffalo Technology, Inc. VoterPerahia Eldad - Intel Corporation VoterReuss Edward - Plantronics, Inc. VoterRosdahl Jon W CSR VoterSherlock Ian - Texas Instruments VoterStephens Adrian P Intel Corporation VoterBanerjee Kaberi - NXP non-

voter

Called to order 11:05 EST by Bruce Kraemer;

Tentative Agenda TGn CRC Teleconference:1. Attendance2. IPR and other relevant IEEE policies (see pointers below).3. Agenda for this call 4. COEX comments and proposed resolutions for:· 40 MHz in 2.4 GHz· CID 49· CID 2285. Next call6. Any other business7. Adjourn

Primary meeting discussion document will be:11-09-0224: https://mentor.ieee.org/802.11/file/09/11-09-0224-00-000n-sb0-coex-40mhz-other-systems.doc

1. Attendance: 17 on the call with 1 non-voter2. IPR and other relevant IEEE policies (see pointers below).

NOTE WELL: Please review the documents at the following links:- IEEE Patent Policy - http://standards.ieee.org/board/pat/pat-slideset.ppt- Patent FAQ - http://standards.ieee.org/board/pat/faq.pdf- LoA Form - http://standards.ieee.org/board/pat/loa.pdf- Affiliation FAQ - http://standards.ieee.org/faqs/affiliationFAQ.html






https://mentor.ieee.org/802.11/file/09/11-09-0224-00-000n-sb0-coex-40mhz-other-systems.doc


March 2009 doc.: IEEE 802.11-09/0226r2

- Anti-Trust FAQ - http://standards.ieee.org/resources/antitrust-guidelines.pdf- Ethics - http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf- IEEE 802.11 Working Group Policies and Procedures - https://mentor.ieee.org/802.11/public-file/07/11-07-0360-04-0000-802-11-policies-and-procedures.doc3. Agenda for this call – approved without objection.

4. COEX comments and proposed resolutions for:· 40 MHz in 2.4 GHz· CID 49· CID 228Start with document discussion: 11-09-0224: https://mentor.ieee.org/802.11/file/09/11-09-0224-00-000n-sb0-coex-40mhz-other-systems.doc

This document proposes resolutions for the following SB comments:27, 165, 168, 14, 129, 171, 47, 6, 42, 167, 9, 37, 31, 39, 17, 86, 1, 2, 3, 89, 179, 41, 38, 36, 55, 11, 5, 8, 30, 127, 155, 46, 157, 166, 170, 156, 128, 132, 125, 85, 56, 182, 183, 173, 4, 13, 7, 131, 239, 130, 32, 35, 122, 40, 84, 45, 29, 184

Comment Content Summary13, 173, 131 40 MHz 11n uses 50% - 75% the available spectrum in 2.4GHz, reducing availability to other

systems13 Other systems designed based on 20 MHz & channel 1,6,1113, 170-c2 Reference to

11-08-0992-01-000n-20-40-mhz-11n-interference-on-bluetooth11-08-1140-00-000n-11n-40-mhz-and-bt-coexistence-test-results11-08-1101-05-000n-Additional-40-MHz-Scanning-Proposal

6 Draft includes mandatory scanning for legacy 802.11, but not for 802.1514 Backward compatibility with legacy 802.11129 Coexistence with all 802 PHYs171, 55, 179 40 MHz operation is 2.4 GHz is not appropriate due to other systems11, 30, 157, 132, 85, 56

The current draft includes a note recommending that 40 MHz PPDU's not be transmitted

179 The interoperabilty requirement for 802-based systems gets violated.170-c2 19-08-0027-02-0000-40MHz-11n-impact-on-bluetooth.ppt184 Coexistence analysis missing

Proposed Change Content Summary13, 171, 6, 3, 179, 41, 55, 30, 128, 125, 182, 131, 130, 29

Ban 40 MHz in 2.4 GHz

11, 6, 86, 1, 2, 179, 55, 157, 132, 125, 85, 56, 84

introduce adequate detection mechanisms to prevent undue interference to 802.15

14 Backward compatibility with legacy 802.1114 Fair Coexistence with 802.15129 Coexistence with all 802 PHYs17 As energy, security, and other PANs using 802.15.4 - specifically ZigBee - are deployed

ubiquitously by utilities, commercial buildings, and consumers, the number of devices operating in this public spectrum is set to grow by one or two orders of magnitude - ten to 100 times the number of 802.11n devices.

86 Colocated 802.11n 40MHz device operating in the 2.4GHz band should switch back to 20MHz operation when detecing such overlapping non-802.11 devices.

127, 155, 157, 128 add the normative sentence "If a STA is operating in the 2.4GHz ISM band and has no mechanism to know whether any non-802.11 communication devices are operating in the area








March 2009 doc.: IEEE 802.11-09/0226r2

or has knowledge that a non-802.11 communication device is operating in the area, then it shall assert the 40MHz Intolerant bit in its HT Capabilities IE."

155 Implement a TDMA-approach, similar to 802.15.2's "Alternating wireless medium access"156 implement the PCO mechanism could be extended to allow periods when non-802.11 devices

can access the medium184 Add annex evaluating coexistence with all existing IEEE standards which use these bands,

including 802.15.1 and 802.15.4

Almost Duplicates13 165, 27-c1, 168-c1, 47 (proposed change), 41 (proposed change), 38, 4, 13(comment),

4(comment), 173(proposed change), 4(proposed change), 7, 239, 32, 35, 122, 40, 4511 27-c2, 168-c2, 5, 41(comment), 8, 1666 27-c3, 168-c3, 47(comment), 167, 9, 86(comment)47 42, 37, 31, 39, 1741 36, 46, 170-c1, 170-c2127 89182 183

Proposed resolution is about 4-5 pages long, see the document #224r1 for the details:

Resolution (for all CIDs): Disagree -

802.11n defers both 20 and 40 MHz transmissions to any radio energy detected above the specified threshold …

Discussion: Question on mandated detection to keep the channel clear while energy is above the threshold. In the standard, it is not clear that energy detect is not clear.R2 will have the note remove the last sentence of the first paragraph on page 7.

Issue with the time synchronized or TDMA in the context of the resolution. Frequency Hop Spread Spectrum (FHSS) and TDMA is not necessarily the same. BT is FHSS.

This may be a word issue, as the MAC has access on time slots, but the PHY is FHSS. So there are both time and hop synchronousChange made too second paragraph—change TDMA to FHSS and Time slot access system.

Concern on the waveform compare would need 20MHz, and some systems have only 1 or 5 MHZ radios, so this is not a given.

Page nine: 802.15 systems do not stay long enough to be able to scan continuously, but they do optional energy detect, and then do adaptive channel selection.

Discussion of how 11n is looking to detect and avoid 11 systems, and some other non-11 systems.

How often do 802.15.1 check for the conflict? Not every packet. Specific changes to text was not identified.

In the channel sense systems in 802.11, they defer transfer the immediate packet, but in the 802.15.1 systems, they check for a particular channel, but it will go out but may be on the next channel. The packet is going to be transmitted on a channel and there is a distinction that needs to be kept clear.


March 2009 doc.: IEEE 802.11-09/0226r2

The text for the comparison of the 11n, 15.1, and 15.4 was not clearly agreed to, so we need to revisit this one.

The FCC rules of 15 MHz is required, concern that we are only citing one regulatory ruling, and that in Europe it is believed that 20MHz is the requirement, but needs to be verified.

Concerned that the test/demo shown in LA at the interim meeting, showed that BT systems were robust, but not the impact of the systems collocated. What was the added energy required for the retransmissions, what was the throughput loss? The test showed audio results, but the quality of the packet stream did not have enough errors to cause any notable problems.

Text for changes for this section needs to be revisited.

ETSI spec does show 20 channels that are required. Add the ETSI requirement after the FCC notice.

Issue on the FCC intent, and what the actual regs state. The FCC rules in total is a bit different than if we look at only a portion of the rules in isolation.

The minimum amount of of Spread Spectrum that a system shall use is 15 MHz.

In the ETSI rules, there are 2 types of FH systems one is adaptive and one is non-adaptive, so one has to use no less than 20 channels (adaptive) , and the other is 15 channles (non-adaptive).

No specific wording change proposed, need to look back again.

Second to last paragraph of page 9 – the signal strength when measured is in the co-located bands, the tolerance is not what was wanted. There is some concern on how the details are noted, but specific changes were not suggested.

There is 20 db bandwidth called out for the FH bandwidth, so it is common, ETSI also uses 20db below peak, so it seams to be reasonable.

“Minority view” that 802.11n should include detection…The 802.11n has put in protection for 802.11 systems, but the question is why did more protection not be put in for other legacy systems. The “Minority” is from the sponsor ballot and the 802.11 group, but the group that has added 11n is the majority of 802.11. Other legacy devices should not expect that their ISM band be guaranteed, as the rules say that it is not isolated.

Page 10, paragraph one 802.19 Coexistence Usage Scenarios: Question on 802.19 coexistence scenarios. The agreement of the test cases is disputed. There are 802.11 documents, but no 802.19 ruling or minutes to show this. The test cases in 11-08/984 has most of the 971 test cases plus extra case to allow for stereo headsets. There were no votes noted in the 802.19 minutes, but the discussion that was facilitated did produce the test cases that were used.

There were differences in how the measurements and generation were noted between the two cases that were produced.

The question of viewpoint was made. Request to remove the companies being cited, but the breadth of the companies was wanted to be kept.


March 2009 doc.: IEEE 802.11-09/0226r2

Resequence the paragraph to more accurately reflect the timeline. it is believed that no change is necessary in the order.

Question on removing “an individual from Motorola” from the second to last sentence.Replace last 2 sentances with New sentence “An additional use case was added to include the BT device as a stereo headset receiving streaming music, additional details in 11-08/984.”

[19 now on call]

General comment: there are 13 comment cagegories and the comment resolution seems to only address 3 of them.

Concern that a comment on the scanning method, specifically on a note is not discussed. It was pointed out that on page nine (“It is evident….”) that a recommendation was made and the note was addressed.

Concern that the comments are not fully addressed. CID 11, 30, 157, 132, 85, 56. The suggestion is that we change from a note to optionality, or remove the note all together. A recognized option and not be just a recommendation. Take these 6 CIDs and put in a separate resolution.

This document (09-224) was written to disagree with the comments in total and not make a change, and the comment resolution is to decline the proposed changes.It was noted that the process we were following is that we were discussion the resolution as proposed, and that if there is a group of comments that are wanted to be removed and addressed on a subsequent call agenda. This was noted that any individual could request this, but that a subsequent submission is required.

BT is a registered trademark, and so we need to use the full spelled out BlueTooth.

BT voice link may not be accurate, it is was pointed out that this is BT Voice modeled by BT data. More accurate would be a voice data was transmitted by BT data methods.

Request to reword the last sentence (page 10, 2nd to last paragraph).“In this test setup, the stored voice data was transferred over a BT IP (data) link tagged as a voice traffic category.”

The submitter was willing to accept the compromise on rewording this sentence.

The comments and the proposed resolution is intended to be closed and sent out to the ballot pool as we will have more rounds of discussions.

The concern is that the implication that because there are lots of devices that do coexist today, that no change is required.

The assertion that coexistence requires zero interference is not required.

Request to include that there are lots of devices (Millions of 802.11 and Billion 802.15 devices). The argurement of is the space overtaken by lots of devices


March 2009 doc.: IEEE 802.11-09/0226r2

or by devices that use more channel bandwidth. The amount of channel being used is cumulative with lots of devices, and the other argument is that with 11n, it is adding 40, so is this worse or better than what is being offered by the legacy devices.

--- Now lets go back and try to resolve the tagged items.Request to just take it to motion, because it seems only a minority has issue.

** Page 9 Bullet “Energy detect”, -- the wording was presented to 802.19, and it was accepted. SO the question of on this call, who has an issue with this text?

On the call in 19 – only one person had issue, requested to change None to Optional with some details, but the submitter did not agree. Only one person has issue, so no change may be warranted.

** Page 9, 2nd to last paragraph, 2nd to last sentence: issue with “good results”, there were 2 noted requests to have this sentence changed.

Peter Loc would like to remove the 6 CIDs and address there specifics.

**Change “Good Results” to “uninterrupted a2dp audio streaming”

R2 has now been generated but not posted.

We then reviewed each of the changes in the document. These changes are indicated with the track changes on.

Motion number 404: -Moved: Approve resolution of comments found on the tab labeled “COEX 20-40 - other systems” in document 11-09/0037r3 with resolutions in document 09/0224r2.Moved: Eldad Perahia, 2nd David Bagby18 on the call – Question on the future presentation on the 6 CIDs that Peter may want to discuss. The current motion would fill the resolutions in, but the new proposal on the reconsidered CIDs would be discussed on a future call (next week).

Roll call vote: Ed R.: approveEldad P.: approveAdrian S.: approveJoe L: approveJohn B.: DisapproveDavid B.: approveBrian H.: -- no responseSven M: ApproveNaveen: ApproveTomo A.: AppoveVinko E.: ApproveJon R.: approveMatt F.: approvePeter L.: ApproveRolf DV.: ApproveIan S.: DisapproveBruce K: AbstainOne Non-Voter – Kaberi B.Results: 14 Yes, 2 No, 1 Abstain

5. Next call:


March 2009 doc.: IEEE 802.11-09/0226r2

Peter Loc to prepare submission on alternate resolution on 6 CIDs

2 CIDs: 49 and 228 are still pending.

Continue with anyother comment not resolved by prior call.

PHY has one comment left and will be prepared for next week.

Gen and MAC have a few CIDs left, and so we will have a composit call next week.

Editor needs more input on 3 CIDs. (Approved CID but need more clarity).

Sequence will be suggested in an e-mail that will be sent out with the meeting announcement.

6. Any other business

Question – How does the comment resolution get sent to the Ballot Pool?

A: there are two methods; there will be an e-mail to the Sponsor Ballot Pool as well as the issuance of the recirculation ballot…

7. Adjourn 13:00 EST

2009-02-11 teleconBruce Kraemer, Marvell (Chair)Dave Bagby, Calypso VenturesDoug Chan, CiscoVinko Erceg, BroadcomMatthew Fischer, BroadcomNaveen Kakani, NokiaPeter Loc, RALINKEd Reuss, PlantronicsAdrian Stephens, IntelLiwen Chu, STMicroelectronicsKaberi Banerjee, Independent – non voterSven Mesecke, BuffaloJohn Barr, Motorola (part)Eldad Perahia, Intel (part)

Approved Agenda:

1. Attendance2. IPR and other relevant IEEE policies (see pointers below).3. Agenda for this call 4. Recycled resolutions from the editor plus remaining Unresolved comments and proposed resolutions:

PHY Editor MAC


March 2009 doc.: IEEE 802.11-09/0226r2

COEX1. Alternative for Intolerant bit setting in 2.4 GHz (15 minute limit)2. CID 493. CID 228

GEN

5. Next call plans [Feb 18 916-356-2663, Bridge 2, 2597635]6. Any other business7. Adjourn

Minutes:

Chair opened meeting at 11:00am Eastern, 2009-02-11

1. IP policies. Chair points to links in agenda email. Nobody wanted any of the material rehearsed.

2. Chair issues call for essential patents. No response.

3. Recycled resolutions from the editor plus remaining Unresolved comments and proposed resolutions:

a. PHYi. Vinko Erceg presents from 11-09-0147r2

1. CID 143a. Discussion.b. The response cites a “NACK”. We don’t have one.c. A: The term NACK is used in their presentation.

2. Straw Poll: is there any objection to accept resolution for CID 143

3. Motion 405: approve resolution of CID 143 in 11-09-0147r2

a. Erceg/Kakanib. Result 9Y,0N,1A, passes

b. Editori. Adrian Stephens presents 11-09-0236r0

1. CID 81a. Q does channel agility relate to frequency hopping:b. A: yes

2. CID 933. CID 134 and 1354. Motion 406: approve resolution of CID 81, 93, 134 and

135 in 11-09/01236r0a. Stephens/Fischerb. Result 10,0,1, passes

c. MACi. Matthew Fischer presents 11-09-0120r4

1. CID 95a. Resolution: Disagree, TGn preceeds TGv in the

official timeline and therefore this comment is not


March 2009 doc.: IEEE 802.11-09/0226r2

appropriate for TGn, but would be appropriate for TGv.

b. Motion 407: Move to accept proposed resolution for 95 cited above.

c. Fisher/Stephensd. Result 10,0,1, passes

2. CID 225a. Motion: 408: Move to accept resolution for CID 225

in the cited documentb. Fischer/Stephensc. Result 9,0,2, passes

3. CID 112a. Initial proposal: “Disagree – the idea of allowing a

non-AP STA the ability to send to multiple RAs using contiguous RDs within a single TXOP was discarded during earlier discussions in TGn as being unfair, not withstanding the TXOPLimit which could impose such fairness, provided that all frames are of the same TID/AC.”

b. Discussion:i. The 1-bit signaling came from simplifications

early in the TGnsync proposal, when simulations showed no benefit for a more complex signaling.

ii. The issue about fairness comes from STA giving other STA more channel access opportunities. The STA is acting a bit like an AP.

c. Modified proposal: “Disagree – the idea of allowing a non-AP STA the ability to send to multiple RAs using contiguous RDs within a single TXOP was discarded during earlier discussions in TGn as not providing any additional performance to the network as provided by simulations at the time.”

d. Straw poll: any objectionsi. No objections

4. CID 1615. CID 160

a. Proposed resolution: “Replace "WinSizeR, which is set to the value of the Buffer Size field of the associated ADDBA response frame that established the Block Ack agreement." with "WinSizeR, which is set to the smaller of 64 and the value of the Buffer Size field of the associated ADDBA response frame that established the Block Ack agreement." Make a similar change on p 140 line 4 and another on p 141 line 57”

b. Straw poll. Any objection?i. No objections

c. Discussion:i. What is the lower bound for the buffer size?


March 2009 doc.: IEEE 802.11-09/0226r2

ii. We should leave it up to the market to decide. There is no requirement, e.g. to select the highest supported MCS on a link.

6. Motion 409: approve resolution of CIDs 112, 161, 160 in 11-09/0120r5 (r5 as amended during the telecon)

a. Fischer/Barrb. Result 8,0,4, passes

d. COEXi. Alternative for Intolerant bit setting in 2.4 GHz (15 minute)

1. Peter Loc Presents 11-09-0233r02. Discussion

a. Knowledge of non-802.11 communication doesn’t necessarily imply the need to stop using 40MHz, as shown by the demonstration at the last 802.11 meeting. This new material changes that. The note was carefully crafted.

b. “Has knowledge of non-802.11 devices operating” doesn’t necessarily mean there’s a coexistence problem. Need a phrase that is less rigid. Suggest something like “has knowledge that its operation could interfere with non-802.11 devices”

c. Comment resolution is non-responsive to CID30 because the commenter clearly wants to ban use of 40MHz in 2.4, and the proposed change doesn’t achieve that.

d. “Has knowledge of” is vague. Trying to mandate a ‘shall’ on a vague condition.

e. Not sure if this resolution replaces the previously agreed one, or adds to it.

i. Peter: intention is to replace the previously-approved resolution with the ones in this document.

f. Would the group be willing to suppot an updated submission along the same lines?

g. By turning on 40MHz, non-11 devices in the neighborhood will detect this and drop to 20MHz. Support the proposal.

3. Straw poll: Is there enough support to justify reworking proposal over the next week?

a. Result 5,4,4ii. CID 49

1. Matthew Fischer presents document 11-09-0120r42. Motion 410: accept resolution of CID 49 as in 11-09-

0120r4a. Fischer/Perahiab. Result 10,0,3, passes

iii. CID 228 – not covered due to timee. GEN – not covered due to time

4. Next call plans [Feb 18 916-356-2663, Bridge 2, 2597635]a. Complete resolution of all open commentsb. Circulate resolutions and get agreement on reflector prior to call

i. Action: Eldad, Matt, Joseph


March 2009 doc.: IEEE 802.11-09/0226r2

5. Any other business6. Adjourn

a. Adjourned at 13:00 Eastern

Teleconference minutes from February 18, 2009

Tentative Agenda TGn CRC Teleconference:

1. Attendance: 2. IPR and other relevant IEEE policies (see pointers below).3. Agenda for this call 4. Unresolved comments and proposed resolution changes:

Editor recycles (if needed) None as of today (Feb 18) GEN – 8 to consider (20 Mins) MAC – 7 to consider (60 Mins) COEX (30 Mins)

1. CID 2282. 40 MHz in 2.4 GHz

Comments on Resolutions from Ballot GroupReassess at 12:30 for finalizing plan.

5. Steps remaining to sponsor recirculation ballot6. Next call [Feb 25 916-356-2663, Bridge 2, 8978953]7. Any other business8. Adjourn

DocumentsFor pending comment resolutions the primary meeting discussion documents will be found at: https://mentor.ieee.org/802.11/documents

GEN 11-09-0101 r5MAC 11-09-0120 r5MAC 11-09-0083 r3 xls spreadsheet

Other reference documents:

Composite of comments from SB0 11-09-0024 r3Composite of CRC minutes 11-09-0226 r1COEX comments 11-09-0037 r4 and 11-09-0224 r2

1 Attendance:

LastName FirstName MI Affiliation


https://mentor.ieee.org/802.11/documents

March 2009 doc.: IEEE 802.11-09/0226r2

1 Adachi Tomoko - Toshiba Corporation Voter2 Bagby David - Calypso Ventures, Inc. Voter3 Chan Douglas S Cisco Systems, Inc. Voter4 Chu Liwen ST Voter5 de Vegt Rolf J Qualcomm Incorporated Voter6 Erceg Vinko - Broadcom Corporation Voter7 Fischer Matthew J Broadcom Corporation Voter8 Kakani Naveen K Nokia Corporation Voter9 Kraemer Bruce P Marvell Voter

10 Levy Joseph - InterDigital Communications, LLC Voter11 Loc Peter - Ralink Technology, Corp. Voter12 Perahia Eldad - Intel Corporation Voter13 Ramamurthy Harish Marvell Voter14 Reuss Edward - Plantronics, Inc. Voter15 Rosdahl Jon W CSR Voter16 Stephens Adrian P Intel Corporation Voter17 Zhang Hongyuan Marvell Voter

18Banerjee Kaberi - Independent non-

voter

2. IPR and other relevant IEEE policies (see pointers below).Meeting Guidelines

NOTE WELL: Please review the documents at the following links:- IEEE Patent Policy - http://standards.ieee.org/board/pat/pat-slideset.ppt- Patent FAQ - http://standards.ieee.org/board/pat/faq.pdf- LoA Form - http://standards.ieee.org/board/pat/loa.pdf- Affiliation FAQ - http://standards.ieee.org/faqs/affiliationFAQ.html- Anti-Trust FAQ - http://standards.ieee.org/resources/antitrust-guidelines.pdf- Ethics - http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf- IEEE 802.11 Working Group Policies and Procedures - https://mentor.ieee.org/802.11/public-file/07/11-07-0360-04-0000-802-11-policies-and-procedures.doc

3. Agenda for this call – Approved without objection

4. Unresolved comments and proposed resolution changes:4.1 Editor recycles (if needed) – None as of today (Feb 18)

4.2 GEN – 8 to consider (20 Mins)

4.3 GEN 11-09-0101 r5 Starting with CID 52, 53 and 54 slide 22

4.3.1 Motion # 411: Move to accept the resolution on slide 22 of 11-09-0101r5 for CID 52, 53, and 54.Moved by Joe Levy, 2nd EldadVote: unanimous without objection. (18 on call)

4.4 Slide 24 11-09-0101r5: Proposed resolution for CID 57 and 144: Unresolvable:










March 2009 doc.: IEEE 802.11-09/0226r2

802.11 WG, TGn and the TGn CRC believe they have faithfully followed the procedures provided by PatCom concerning the soliciting of potentially essential patents and associated LOAs as specified in: http://standards.ieee.org/board/pat/pat-slideset.ppt

TGn CRC is restricted from any additional action beyond these procedures. TGn CRC has asked the WG11 chair to pass this comment on to PatCom for further review and advice. While awaiting further advice, TGn CRC and WG11 will continue to follow IEEE IP procedures.

It has also been noted that the status of LOAs believed relevant to P802.11n will need to be reviewed prior to a request for Standards Board approval and publication as there are potentially two paragraphs that could be selected from the IEEE-SA Ops Manual (sub-clause “6.3.1 Public Notice”) for inclusion in the P802.11n front matter (currently page iv of the draft). One paragraph applies when LOAs are not received, and one for when LOAs are received.

4.4.1 Motion #412: Move to accept the resolution for CID 57 and 144 as seen on slide 24 of 11-09-0101r5.Move Joe Levy, 2nd Mathew Fisher

4.4.2 Discussion: why delay the review more? Which paragraph is chosen is not important at this point, but it should be done prior to sending to IEEE-SA.

4.4.3 Q: The 2nd bullet should be stricken, as it is not quite factual. A different technical path could be taken. So removing the first sentence of the third bullet.

4.4.4 Final resolution: Unresolvable: 802.11 WG, TGn and the TGn CRC believe they have faithfully

followed the procedures provided by PatCom concerning the soliciting of potentially essential patents and associated LOAs as specified in: http://standards.ieee.org/board/pat/pat-slideset.ppt

TGn CRC has asked the WG11 chair to pass this comment on to PatCom for further review and advice. While awaiting further advice, TGn CRC and WG11 will continue to follow IEEE IP procedures.

It has also been noted that the status of LOAs believed relevant to P802.11n will need to be reviewed prior to a request for Standards Board approval and publication as there are potentially two paragraphs that could be selected from the IEEE-SA Ops Manual (sub-clause “6.3.1 Public Notice”) for inclusion in the P802.11n front matter (currently page iv of the


March 2009 doc.: IEEE 802.11-09/0226r2

draft). One paragraph applies when LOAs are not received, and one for when LOAs are received.

4.4.5 Motion #412: move to accept the resolution for CID 57 and 144 as seen on slide 24 of 11-09-0101r5 with one sentence removed (see above).

Move Joe Levy, 2nd Mathew FisherVote: Attendance: 18

Tomo Adachi – YesDave Bagby – NoDoug Chan – YesVinko Erceg – YesMatthew Fischer – YesKaberi Banerjee – non-voterBruce Kraemer – AbstainJoe Levy – YesPeter Loc - YesEldad Perahia - YesEd Reuss – YesJon Rosdahl– AbstainAdrian Stephens – YesNaveen Kakani - YesLiwen Chiu – YesRolf deVegt– Yes

Count: 12 yes; 1 no; 2 abstain; 1 non-voter; 2 no responseMotion Passes

4.4 CID 232 and 233 have proposed resolution in 11-09-212r0.4.4.1 MOTION #413: Moved to accept the resolution in 11-09-

212r0 for CID 232 and 233.Moved: Joe Levy, 2nd Eldad Perahia

Tomo A.– yesDave B. – abstainDoug C. – yesRolf dV.– yesVinko E. – yesMathew F.– yesNaveen K.– yesBruce K.– abstainJoe L. – noPeter L.– yes


March 2009 doc.: IEEE 802.11-09/0226r2

Eldad P. – yesEd R. – abstainJon R. – abstaainAdrian S. -- yesLiwen C. – yesKaberi – non-voter

18 on call.10 yes; 1 no; 4 abstain; 1 non-voter; 2 no response.

4.5 CID 82 – proposed resolution: • Proposed:• Out of Scope – While the commenter has pointed out several MIB

variables which may have questionable value; the MIB, as it currently exists, has many variables of equal value. It is not within the scope of the TGn PAR to correct and/or restructure the whole MIB. The CRC believes that this type of correction is in scope for TGmb and will forward this comment to TGmb so it can be addressed in REVmb.

4.6 Motion 414: move to approve the proposed resolution for CID 82.Moved by Joe L. 2nd Jon RAccepted without objection: 18 on call.

5 MAC – 7 CIDs to consider5.1 MAC 11-09-0120 r5 – CID 226

5.1.1 Review the comment and proposed change.5.1.2 Concern that the proposed resolution may not match the

concern.5.1.3 Question if more time was needed to finalize the proposed

resolution. It seemed that there was some concern that it was not complete enough.

5.1.4 It was not clear that moving the WinEnd on the recipiant side was sufficient.

5.1.5 Need to have a statement that the recipient cannot move the WinEnd on a particular case

5.1.6 Will delay and come back to this one.5.2 CID 101

5.2.1 Review the comment and proposed change and resolution.

5.2.2 No objection to the proposed resolution5.2.3 Will be part of the proposed motion later.

5.3 CID 1025.3.1 Review the comment and resolution.5.3.2 No objection and will be part of proposed motion later.

5.4 CID 103:5.4.1 Review the comment and resolution.5.4.2 Proposed resolution:


March 2009 doc.: IEEE 802.11-09/0226r2

5.4.2.1 Principle – with the change to the PSMP support bit location, non-HT STA can participate in PSMP, thereby either requiring those STA to use MTBAR/BA or requiring a change to PSMP to allow non-MT BAR/BA within the PSMP exchange.

5.4.3 Discussion on when the non-HT STA can use the PSMP and other features. This resolution needs some adjustments.

5.4.4 Look at the text in 9.165.4.5 9.16.1.4 – PSMP bursts -- BA and BAR were listed5.4.6 9.16.1.5 in note 3, review frames listed.5.4.7 This has been discussed on the reflector previouisly, and

we could use the reserved bit for some of these frames. Would a single BA agreement may be created and sufficient? The transmitter must get the bit correct. And the field should be unreserved from immediate use.

5.4.8 The field is reserved for a case where it is not allowed.5.4.9 Unreserve the ACK reserve bit for PSMP use and indicate

when it can be used in the immediate. Reserved means that the receiver cannot (should not) even look at it.

5.4.109.16.1.4 we could say add BA with Block Ack Policy set to NoAck. Then in the frame section, change reserve field.

5.4.117.2.17 and 7.2.18 needs to change the reserve field.5.4.12Stop frame transmit outside the PSMP policy with NoAck

set.5.4.13BAR and BA control field. There have been some changes

already approved, so we need to say that this is the BA policy subfield and add a statement under value 1 that value 1 is not used for HT-immediate BA outside PSMP sequence.

5.4.14 Make the statement for BAR in 7.6h and make matching changes in 7.6j

5.4.15 New proposed resolution: read out.5.4.16Check the note, there is another reserved bit that may be

an issue. See Note 6.5.4.16.1 The non-MT version may not apply.5.4.16.2 However, the tables are for all conditions and

so we may need to make further changes.5.4.17The title of the table would need to be changed at the

very least. We cannot reserve the field at anytime, whether you look or not depends on PSMP or not. So the bit is to help identify when you are in PSMP.

5.4.18Currently the value reserved is 0. so in the table you need to indicate that MTBA and MTBA only use zero

5.4.19In 7.2.1.4 where the MTBAR variant is described, the BAR control field or the ack policy could be set to override what is in the PSMP fields.

5.4.20One of two ways: in 7.6h and 7.6j, we exclude MTBAR or in 7.2.14 we reserved the BAR ack policy subfield.

5.4.21 9.16.1.7 -- end of note…change note 65.4.22 Also change table in 6h and 6j. Note needs to be

changed.


March 2009 doc.: IEEE 802.11-09/0226r2

5.4.23Resolution from 120r6. – 5.4.24Principle – TGn editor to change the sentence “This value represents the

minimum time the STA is provided to react to MTBA and data frames received during the PSMP-DTT with data and MTBA frames transmitted in the PSMP-UTT.” To “This value represents the minimum time the STA is provided to react to MTBA, BA, MTBAR, BAR and data frames received during the PSMP-DTT with data, BA, BAR, MTBAR and MTBA frames transmitted in the PSMP-UTT”. In 9.16.1.4 change the four bullet items containing BlockAck and BlockAckReq to BlockAck and BlockAckReq with the NoAck policy bit set to one. In 7.2.1.7 – table 7-6h for the value 1, add a statement that says that the value of one is not used in the BlockAckReq frame outside of the PSMP sequence, and the value one is not used in MTBAR, and change the sentence preceeding the table to read “the BAR Ack Policy subfield has the meaning shown in Table 7-6h”, change the caption of the table to “BAR Ack Policy subfield”. Make a similar set of changes for 7.2.1.8. table 7-6j. Also change note6 in 9.16.1.7 to read “MTBA and MTBAR transmitted during PSMP use the normal acknowledgement setting of the Ack Policy subfield of the BAR control field.” Also in table 7-6j, delete the note that appears in the row with the value 0.

5.5 CID 141 5.5.1 Review comment and suggested changes5.5.2 Review proposed resolution from 120r5.

5.5.2.1 Disagree – the format of the text is as a “normative recommendation” – the specified behavior is not mandated, but suggested, leaving implementers full choice over the behavior implemented.

5.5.3 No objection on this for a motion later on.5.6 CID 180

5.6.1 Review the comment and suggested changes.5.6.2 Proposed resolution:

5.6.2.1 Disagree – Traditionally, the MLME-CHANNELSWITCH.confirm primitive contains only a result code and vendor specific information, as with many other .confirm primitives. The commenter should note that .confirm primitives usually do not provide any end-to-end information – they merely reflect/acknowledge the receipt of a command between layers. In the case of the channel switch, a new message and SAP for .indication would be required in order to provide an end-to-end confirmation of the channel switch between the AP and each of its associates. This same information can be determined through other means.

5.6.3 Did we check/confirm that the channel switch does not include the secondary channel info?

5.6.3.1 It does seem that it is not there and the resolution is correct.

5.6.4 Objection to the resolution, it is a bit condensending. It may be that we should state the fact that we are not providing an “end-to-end” confirm.


March 2009 doc.: IEEE 802.11-09/0226r2

5.6.5 Proposed change: take out the “the commenter should not”….

5.6.6 Proposed change:5.6.6.1 Disagree – Traditionally, the MLME-

CHANNELSWITCH.confirm primitive contains only a result code and vendor specific information, as with many other .confirm primitives. The .confirm primitives usually do not provide any end-to-end information – they reflect/acknowledge the receipt of a command between layers. In the case of the channel switch, a new message and SAP for .indication would be required in order to provide an end-to-end confirmation of the channel switch between the AP and each of its associates. This same information can be determined through other means.

5.6.6.2 Also we have still an example of what we are saying we are not doing.

5.6.6.3 The request and the indication are the pair that are the end-to-end. The confirmation says that they got the command not that the command was acted on.

5.6.6.4 .confirm primitives – confirm the command was received. The effect of the command is then given in the indication.

5.6.6.5 Associate.confirm, it provides more info than what we would generally associate with a “confirm”.

5.6.6.6 Not all the .confirms are stict followers of the rules.

5.7 CID 1815.7.1 Review comment and proposed changes5.7.2 Proposed resolution:

Principle – TGn editor shall add appropriate subclauses and editing instructions and accompanying modification to the MLME-DLS.request primitive to effect the addition of the HT Capabilities parameter. In addition, the use of each of the SAPs is not clear, and may need clarification that may include additional modifications of parameter lists.

5.7.3 10.3.25.2 has confirm and indication primatives5.7.4 The pattern used was to “add” the HT information5.7.5 STA have to send a prob request in order to know if you have a

full communication channel.5.7.6 The 2007 revision may be missing the capabilities field see

10.3.25.1 DLS request5.7.7 We need to add the capabilities and the HT-capabilities parameters

to the DLS.request .5.7.8 We need to also add the extended capabilities parameter also for

consistency.5.7.9 New Proposed Resolution:


March 2009 doc.: IEEE 802.11-09/0226r2

5.7.9.1 Principle – TGn editor shall add appropriate subclauses and editing instructions and accompanying modification to the MLME-DLS.request primitive to effect the addition of the HT Capabilities parameter.

5.7.9.2 No other issues.

5.8 Motion #415: Move to accept the comment resolutions For CID 101 102, 103, 141, 180, 181 (see 11-09-120r6).Moved Matt F. 2nd AdrianNo objection to accept the motion: 17 on the call.

5.9 There is only one CID and the Bonus CIDs left in the document to resolve.

6 COEX6.1 CID 228

6.1.1 Review the comment and proposed change.6.1.2 This is similar to 227, so the proposed resolution is the

same.6.1.3 Proposed resolution:

DISAGREE - The 5GHz band is different from the 2.4 GHz band – in 5 GHz, any overlap is complete with either the primary or secondary channel of the 20/40 MHz BSS, whereas varying degrees of overlap are possible in the 2.4 GHz band. A complete overlap of the primary channel creates no new problems as compared to existing possible 5 GHz BSS overlapping situations, where the existing protocols simply allow the BSSs to share the channel through ordinary DCF behavior. Overlapping in the secondary channel is different, in that not all control channel information is conveyed to the secondary channel, but the elements exist in the protocol to allow the 20/40 MHz BSS to convey such information to a secondary channel OBSS, use of such elements can be determined outside of the scope of the standard, as suggested by the commenter.

6.1.4 no objection to the resolution:

6.2 Motion #416: move to accept the proposed resolution for CID 228 in 11-09120r5.

6.2.1 Moved Matthew F. 2nd Eldad6.2.2 No objection – 17 on call.

7 Check on Status:7.1 We have one open CID and the revisit topic on 40MHz in 2.4 GHz.

8 Recycle comment s on 40 MHz in 2.4 GHz 8.1 With this issue, it is thought that this may help resolve a number of

negative voters from the sponsor ballot.8.2 From the e-mail from Peter L.:

Based on comments sent in so far, I am adding the following option to replace the NOTE 2 on page 227 (lines 15-17) of the IEEE802.11n Draft 7.0. with


March 2009 doc.: IEEE 802.11-09/0226r2

“ In addition to the restrictions on transmission of 40 MHz mask PPDUs found in subclauses 11.14.4.1 to11.14.4.4, if a STA operating in the 2.4 GHz ISM band has knowledge of non-802.11 communication devices operating in the area that a) are not co-located with the STA radio and b) may be affected by the 40 MHz operation the STA shall report to the AP via the 20/40 BSS coexistence management frame or 20/40 BSS coexistence management element with the Forty MHz Intolerant field set to 1 “If there is no further comment, I will submit this proposed text as the resolution to the related COEX SB0 CIDs (see submission 11-09/233r0 for more detail) for approval during the IEEE802.11TGn teleconference call on Feb 18.

8.3 This would cover CIDs: 11, 30, 157, 132, 85, 568.4 From the doc 09-233r1:

Proposed resolution

AGREE in Principle with CIDs 11, 30, 157, 132, 85, 56

TGn editor : replace NOTE 2, page 227, lines 15 to 17, with the following:

In addition to the restrictions on transmission of 40 MHz mask PPDUs found in subclauses 11.14.4.1 to11.14.4.4, if a STA operating in the 2.4 GHz ISM band has knowledge of non-802.11 communication devices operating in the area that a) are not co-located with the STA radio

and b) may be affected by the 40 MHz operation the STA shall report to the AP via the 20/40 BSS coexistence management frame or 20/40 BSS coexistence management element with the Forty MHz Intolerant field set to 18.4.1 Comments: we have objections to this resolution.

8.4.1.1 The note that was crafted was put in as a compromise last year, and even though it is pointed out that there may be 5-7 voters to change, this is not significant to the total vote tally. More want it as is than want it to change. Also not certain that this is technically correct and may in-fact be unenforceable.

8.4.1.2 A second commenter agreed.

8.4.2 Response: the compromise was made with a different group, and the 24 no-voters that have issue with this are looking for this new compromise. This is a new compromise to address those that were not included in the previous discussion.


March 2009 doc.: IEEE 802.11-09/0226r2

8.5 Motions: #417: Move to accept the proposed resolution for CIDs 11, 30, 157, 132, 85, 56 as documented in 11-09-0233r1

8.5.1 Moved Peter L, 2nd Ed RTomo A.– yesDavid b – NoDoug C. – NoLiwen C – yesRolf dV– abstainVinko E– noMatthew F – noNaveen K– noJoe L – abstainPeter L – yesEldad P– no Ed R – yes Jon R - yes Adrian S.– no Harish R– no Hongyuan Z - No8.5.2 On the call -- 178.5.3 5 yes 9 no 3 abstain8.5.4 On the call is 158.5.5 Motion fails.

9 CID 226 last CID:9.1 Described new proposed resolution. Or reject the comment.9.2 Proposed to reject. It is documented in r6.9.3 Motion #418: accept the resolution to reject as documented in 09-

120r6.9.4 Moved Matthew 2nd Naveen9.5 No objection – motion passes – on call 15

10 Comment Database review:10.1 Gen approved 8 comments10.2 MAC approved 7 comments10.3 Coex approved 1 comment, and left several as were approved

previously.

11 Comments on Resolutions from Ballot Group11.1 Motion #419: Having approved comment resolutions from IEEE

P802.11 initial sponsor ballot, instruct the editor to prepare Draft P802.11n D8.0 containing the approved resolutions and approve a 15-day recirculation sponsor ballot of Draft P802.11n D8.0 as soon as possible.Moved: Adrian 2nd Eldad

Tomo A: yesDave B – noDoug C– yesLiwen C – yesRolf dV.– yes Vinko E.– yesMatthew F. – yes


March 2009 doc.: IEEE 802.11-09/0226r2

Naveen K.– yesBruce K. – abstainJoe L. – yesPeter L – yesEldad P – yesEd R – yesJon R–yesAdrian S– yesHongyuan Z– yesHarish R.– yes

15 yes; 1 no; 1 abstain.Motion passes.

12 teps remaining to sponsor recirculation ballot9.1 If there is any issue found, this will be reviewed on the next call.

13 Next call [Feb 25 916-356-2663, Bridge 2, 8978953]10.1 if no issues are found and we are in recirc, then we will cancel the call.

14 Any other business14.1 The objection to going to recirc on the principle that the last

comment did not get full time to discuss, and would like to ensure all technical discussions have full airing.

14.2 Question on how long the editorial review and logistics to get the recirc started. Believed to be able to get this done by tomorrow.

15 Adjourn


doc.: IEEE 802.11-09/0226r2€¦ · Web viewMoved Matthew, 2nd Naveen 9 yes, 0 no, 1 abstain –...

Documents

Transcript of doc.: IEEE 802.11-09/0226r2€¦ · Web viewMoved Matthew, 2nd Naveen 9 yes, 0 no, 1 abstain –...