November, 2006 doc.: IEEE 802.11-06/1740r0

IEEE P802.11 Wireless LANs

Tentative Minutes of the IEEE P802.11 Full Working Group

Date: 2006-11-13

Author(s): Name Company Address Phone Email Tim Godfrey Freescale +1-913-814-7883

Abstract Minutes of the 802.11 full working group.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Minutes page 1 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

Opening Plenary: Monday, November 13, 2006 1.1. Introduction 1.1.1. Meeting called to order by Stuart J. Kerry at 13:40. 1.1.2. The agenda of the 100th session of 802.11 is in doc: IEEE 11-06-1455r3. 1.1.3. Secretary – Tim Godfrey 1.1.4. Officers and Chairs of 802.11: IEEE 802.11 WORKING GROUP OFFICERS

Name Position Work Phone eMail Stuart J. Kerry IEEE 802.11 WG Chair +1 (408) 474-7356 [email protected] NXP Semiconductors 1109 McKay Drive, M/S 48A SJ, San Jose, CA 95131-1706, USA

Fax:+1 (408) 474-5343 Al Petrick WG Vice-Chair / Treasurer +1 (321) 725-1520 x204 [email protected] Policies & Treasury Harry R. Worstell WG Vice-Chair +1 (973) 236-6915 [email protected] Attendance, Ballots, Documentation & Voting Tim Godfrey WG - Secretary & Publicity +1 (913) 813-7883 [email protected] Minutes, Reports, & Communications Terry Cole WG Technical Editor +1 (512) 602-2454 [email protected] Standard & Amendment(s) Coordination Simon Barber WG Co-Technical Editor +1 (650) 829-2618 [email protected] Standard & Amendment(s) Coordination Teik-Kheong "TK" Tan WNG SC Chair +1 (408) 474-5193 [email protected] Richard H. Paine TGk Chair +1 (206) 854-8199 [email protected] Bob O'Hara TGma Chair +1 (408) 853-5513 [email protected] Assigned Numbers Authority Darwin Engwer TGma Vice-Chair +1 (408) 495-7099 [email protected] Shlomo Ovadia TGma Vice-Chair +1 (408) 765-1844 [email protected] Bruce P. Kraemer TGn Chair +1 (321) 427-4098 [email protected] Sheung Li TGn Vice-Chair +1 (408) 773-5295 [email protected] Lee Armstrong TGp Chair +1 (617) 244-9203 [email protected] Clint Chaplin TGr Chair +1 (408) 528-2766 [email protected] Donald E. Eastlake 3rd TGs Chair +1 (508) 786-7554 [email protected] Charles R. Wright TGT Chair +1 (978) 268-9202 [email protected] Stephen McCann TGu Chair +44 (1794) 833341 [email protected] Pat R. Calhoun TGv Chair +1 (408) 853-5269 [email protected] Jesse Walker TGw Chair and ISO JTC1-SC6 AHC Chair +1 (503) 712-1849 [email protected] Peter Ecclesine TGy Chair (Pro-Tem) +1 (408) 527-0815 [email protected]

Minutes page 2 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

1.2. APPROVE OR MODIFY 802.11 MEETING AGENDA 1.2.1. Changes from R2 to R3 1.2.1.1. TGr gets PM2 on Tuesday 1.2.1.2. The agenda has not changed otherwise 1.2.2. Stuart asks if there are any further changes to the agenda. There are none. 1.2.3. The agenda is approved with unanimous consent. 1.3. REVIEW & APPROVE THE 802.11 MINUTES OF Melbourne (Sept.2006) SESSION 1.3.1. Stuart asks if there are any matters arising from these minutes? There are none. 1.3.2. The minutes from Sept 2006 are approved with unanimous consent. 1.4. Announcements 1.4.1. Stuart reviews the courtesy notices in the agenda presentation. 1.4.2. There are 220 people in the room 1.4.3. There are 12 attendees here for the first time. 1.5. Treasury report 1.5.1. Al Petrick presents joint treasury document 15-06-458r0. • September 17, 2006 - $166,870.71 • November 9, 2006 - $146,825.71 – Tour Hosts Deficit - $20,000.00 – Wire Transfer Fee - $45.00 • Additional funds remain in Tour Host and Face-to-Face Events accounts: –F2F≈ $86,607 – Tour Hosts - AU$0.00 •Reserves: – Deficit for Melbourne - $4,721.15 – Meeting Expense Reserve - $228,711.56 1.5.2. Melbourne Meeting - September 2006 • Registration = AU$363,200 (Impacted by 802.20 suspension)

• Expenses - AU$389,597 (approximate costs below) – Conference Facility - AU$85,000.00 – Food & Beverage - AU$78,186 – Social - AU$51,570 – AV - AU$43,500 – Network - AU$42,000 – Management Fees - AU$38,056 – Shipping - AU$25,000 – Bank Charges - AU$14,000 – Misc - AU$11,400 • Deficit = AU$32,225 (US$24,721) 1.5.3. 1.6. Review of Policies and Procedures 1.6.1. Al Petrick presents document 11-06-0430r5 to the body.

Minutes page 3 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

1.6.2. Review of working group officers and duties for all wireless working groups. Members are encouraged to wear their voting tokens. Voting rights are also indicated by a printed indication on the badge corner. 1.6.3. 802 LMSC P&P is Nov_2005_r051204.doc approved and revised in January 2006 1.6.4. Review of 802.11 operating policies and procedures, registration, payment of fees. 802.11 P&P are in IEEE 802.11-11-06-812-03, which is posted on the web site. Roberts Rules are revision 10 (Gold Book). 1.6.5. Review of registration requirements 1.6.6. Review of rules against photographs, video and audio tape recording, and media briefings. 1.6.7. Review of procedures for server access and reflector subscriptions. Members must participate in 75% of meetings before being added to reflector per current 802.11 P&P. 1.6.8. Review of voting rights and process for obtaining voting rights, and signing up for email and reflectors. The email confidentiality disclaimer was presented. 1.6.8.1. Members are reminded that confidentiality notices on emails posted to the reflector are not allowed. 1.6.8.2. Any material with confidentiality or copyright disclaimers attached will not be accepted for IEEE 802. 1.6.9. Review of the process and requirements for gaining and keeping voting rights. 1.6.10. Attendance recording procedures are reviewed 1.6.10.1. Signing in for 802.11 attendance is required for gaining and maintaining voting rights. There is no opportunity to sign in late if you forget. 1.6.10.2. There is an electronic web based sign in sheet that must be signed per meeting slot. 1.6.10.3. Attendance credit pool is based on all daytime sessions, and evening sessions and tutorial are optional and are extra credit if attended. 1.6.10.4. Al Petrick reads the following statements to the body:

November 2006 doc.: IEEE 802.11-06/0430r5

Submission Slide 17 Stuart J. Kerry, NXP Semiconductor

Minutes page 4 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

November 2006 doc.: IEEE 802.11-06/0430r5

Submission Slide 19 Stuart J. Kerry, NXP Semiconductor

November 2006 doc.: IEEE 802.11-06/0430r5 Membership & Anti-Trust • Individual membership – In all IEEE standards meetings, membership is by individual, hence you do not represent a company or organization.

• Anti-Trust laws – The Anti-Trust laws forbid the discussion of prices within our meetings.

Submission Slide 18 Stuart J. Kerry, NXP Semiconductor

1.6.11. Review of copyright status of submissions 1.6.12. Review of standards compliance disclaimers 1.6.12.1. IEEE 802 “Unapproved Drafts” are to be used for the purposes of IEEE Standardization activities 1.6.12.2. IEEE 802 “Unapproved Drafts” must NOT be used to claim conformance/compliance, as Drafts are subject to change 1.6.12.3. You are at RISK if IEEE 802 “Unapproved Drafts” are USED for anything other that IEEE Standardization activities 1.6.13. Review of meeting etiquette for the wireless working groups. 1.6.14. Al Petrick asks for any questions. 1.6.14.1. There are none.

Minutes page 5 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

1.7. IEEE SA Letters of Assurance 1.7.1. Stuart J. Kerry asks if there are any questions on the patent policy or letters of assurance. 1.7.2. There are no questions. Stuart deems that members are knowledgeable of the policy and are operating accordingly. 1.7.3. Are there any LOA that the WG should be aware of? 1.7.3.1. There are none. 1.8. Announcements 1.8.1. Social will be indoors on Wednesday evening 1.8.2. There is a special website for notification of meeting ending regarding AV equipment. It has been posted to the CAC reflector. 1.8.2.1. Charles asks when the reporting is needed. It is only for closing for the evening. 1.8.3. Al Petrick notes that the London meeting will be 802 hosted, so there will be some deficit. 1.8.4. There will be one annual update for the LMSC (802) Policies and Procedures from now on. The current LMSC P&P is still under revision. 1.8.5. Denis Kuahara is our liaison to 802.18. This is his last meeting. Volunteers for 802.18 liaison are requested by Wednesday. 1.9. Interim meetings 1.9.1. January 14-19 2007, Hilton London Metropole 1.9.1.1. An 802 sponsored interim in one location. 1.9.2. March 11-16, 2007, Orlando 1.9.3. May 13-18, 2007, Montreal 1.9.3.1. Queen Elizabeth Fairmont. 1.9.4. July 2007 – San Francisco 1.9.5. Sept 16-21, 2007, Hilton Waikoloa, Big Island 1.9.6. November 2007 – Atlanta 1.9.7. January 2008. Sydney Australia (sponsored 802 event) 1.9.8. March 2009. Geneva (802 plenary joint with ISO) 1.10. ExCom Meeting Report 1.10.1. There was discussion on the coexistence assurance document. TGn, TGs, and TGy are expected to provide those statements. 1.10.2. The architecture group will no longer meet on Sundays of plenaries. It has not been productive. They will only have meetings when deemed necessary. 1.10.3. Geoff Thompson will be re-appointed to the RAC. 1.10.4. The 802.20 appeals are still being addressed, but will not be heard until 2007. 1.10.5. Meeting planner and network services contracts are being re- negotiated. 1.10.6. Stuart notes that the notice for the London Interim is now on the website. It is for hotel and registration.

Minutes page 6 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

1.11. 802 PAR updates 1.11.1. Al Petrick presents the 5 PARs from other working groups that are up for approval this week. They have been out for review for 30 days. The 802.11WG has to reply with comments by Tuesday evening. 1.11.2. P802.1AB: Station and MAC Connectivity Discovery (Revision). 1.11.2.1. Are there any comments from the members? None. 1.11.3. P802.1Qav: Forwarding and Queuing Enhancements for Time- Sensitive Streams. 1.11.3.1. Adrian Stephens comments that he is concerned that 802.1 is not taking wireless networks in account. We want to bridge media streams between 802.16 and 802.11 MAC through an 802.1 standard mechanism. The 802.1 standard needs to comprehend the details of wireless MACs. Feels that if 802.1 does not address wireless, this work will not be helpful. Adrian will participate in writing a comment letter. Myron will assist in these comments. 1.11.3.2. Al Petrick will reserve a meeting room tomorrow morning for this effort. 1.11.3.3. Harry notes that there was an 11ab study group approved at the last meeting need to coordinate with the 802.1 study group. Harry will determine when a meeting can be set up. Since we did not have a quorum, we will re-vote the confirmation of the study group. This will be brought to the floor today. 1.11.4. P802.1Qaw: Management of data driven and data dependent connectivity faults 1.11.4.1. Are there any comments from the members? None. 1.11.5. P802.15.4d: Amendment (950 MHz in Japan) 1.11.5.1. Are there any comments from the members? None. 1.11.6. 802.16m: Advanced Air Interface 1.11.6.1. Bruce K notes that there will be a tutorial on this topic this evening. Until we have heard the tutorial, we can’t make a proper response. We need an opportunity tomorrow, and potentially provide feedback on this PAR. 1.11.6.2. Stuart asks if the tutorial materials are posted. Bob O’Hara says they are posted now. 1.12. Tutorials 1.12.1. Monday Tutorial 1: 802.11s WLAN Mesh Networking (to be moderated by Donald Eastlake) 1.12.2. Monday Tutorial 2: 802.16m IMT (Roger Marks) 1.12.3. Tuesday Tutorial 1: 802.15.5 WPAN Mesh (Bob Heile) 1.12.4. Tuesday Tutorial 2: CALM European network 1.13. Voter summary and Attendance recording update 1.13.1. Harry reviews the voter status for the 802.11 working group as of the start of this meeting. 1.13.2. Document 06-1736r1 1.13.2.1. 403 voters 1.13.2.2. 47 potential voters 1.13.2.3. 450 Total Voters 1.13.2.4. 36 nearly voters (have not requested voting rights) 1.13.2.5. 226 Aspirant Voters 1.13.3. Stuart notes that this meeting is by definition a quorum per 802 LMSC P&Ps.

Minutes page 7 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

1.13.4. There are 16 official meeting slots, with 2 extra-credit (tutorials). Each slot is 6.25% of attendance credit. 1.13.5. Drafts have not been uploaded to the local server yet, but it will be done this week. 1.13.6. 802wirelessworld is for document upload only – not contact information. Do not attempt to update your contact information, just cancel or click another link. Send contact info directly to Harry Worstell. 1.13.7. Harry reviews the attendance recording and sign-in process. 1.13.8. Harry states that there is now a 5 minute grace period before and after each meeting slot. 1.13.9. Members note that some members are in the list more than once. Harry will attempt to fix this. There as some issues with the different meeting planners used in September. This is due to an error with Member IDs by the meeting organizers. 1.13.10. When we tie into myProject, we will have consistent ID numbers assigned by IEEE. 1.13.11. Harry reviews the document server locations and organization. 1.14. Policies and Procedures Update 1.14.1. Al is collecting information for the next P&P update. 1.15. Reports 1.15.1. Publicity and Timeline – Tim Godfrey 1.15.1.1. There have been no publicity enquiries in the last 2 months 1.15.1.2. The timeline will be updated on Friday. 1.15.2. WG Editor – Simon Barber 1.15.2.1. There will be an editors meeting Tuesday at 7:00am. 1.15.2.2. Terry Cole will not be here this week. Simon Barber is handling editor responsibilities 1.15.2.3. Harry will attend the meeting to discuss draft numbering. 1.15.3. WNG SC – TK Tan 1.15.3.1. At the Melbourne meeting, there was a motion at the closing. We need to re- affirm this motion since there was no quorum: 1.15.3.2. Move to reaffirm: To form an 802.11 WG Study Group to examine DLS (Direct Link Setup) operation with non 802.11e APs and to examine power saving extensions to DLS with the intent to create a PAR and five criteria to form a new task group. 1.15.3.2.1. Moved Al Petrick 1.15.3.2.2. Second Harry Worstell 1.15.3.2.3. Discussion 1.15.3.2.3.1. Darwin requests more explicit description of “non 802.11e” AP. The standard defines exactly what a QoS AP is. Would prefer “QoS AP”. 1.15.3.2.3.2. Charles W suggests that the amendment could refer to a PICs item. (CF12) 1.15.3.2.3.3. Jon R states that any amendments would make this a new motion, not a reaffirmation. 1.15.3.2.4. Stuart rules that we reaffirm the previous motion from Melbourne because no quorum was present: 1.15.3.2.5. Vote: Motion passes: 71 : 3 : 44. 95.9%

Minutes page 8 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

1.15.3.3. Volunteers for chair of the new Study Group should notify Stuart J. Kerry or TK Tan. They should consider the comments from Darwin in the creation of the PAR and 5C. 1.15.3.4. WNG SC will consider multicast for multimedia applications, and cooperative communication in the session this week. 1.15.4. TGk – Richard Paine 1.15.4.1. TGk is working on LB90 that closes Thursday evening. Requests members send in comments early to allow them to be resolved this week. That could enable going to sponsor ballot this week. TGk will ask for conditional approval. 1.15.4.2. Stuart J. Kerry requests that Richard make the vote early request on the reflector. 1.15.5. TGma – Bob O’Hara 1.15.5.1. There are no requests for new assigned numbers to the ANA. 1.15.5.2. TGma completed the final sponsor recirculation last week. It will go to RevCom for conditional approval. It will go to RevCom on early consideration process. It will not be approved by the standards board in March 2007. It will become 802.11-2007. There are five remaining negative voters, and 51 remaining unsatisfied comments. 1.15.5.3. There is one interpretation request to be processed this week. There are three different rules in 802.11i to deal with replay protection. Bob requests experts on the TKIP replay protection mechanism to attend. 1.15.6. TGn – Bruce Kraemer 1.15.6.1. TGn continues comment resolution on LB84. There are 20% of comments to be resolved. Expect next LB after the January session. 1.15.7. TGp – Lee Armstrong 1.15.7.1. There is a new draft available that will be reviewed this week. Should be ready for letter ballot at the end of this week. 1.15.7.2. Stuart notes that Harry needs 3 days to process a letter ballot 1.15.8. TGr – Clint Chaplin 1.15.8.1. The TGr agenda is 11/06-1664r2. The comments are in 06/1576r7. There are groups and issues. Groups 1-4 are editorial or trivial technical. Want to vote on them this afternoon. 1.15.8.2. Issues 99: the TG doesn’t know how to address them. 1.15.8.3. There will be a discussion on Key Distribution issues on Tuesday AM1. 1.15.8.4. Mostly working on addressing comments on LB87. 1.15.8.5. Some chance of being ready for letter ballot this week. 1.15.8.6. Stuart J. Kerry notes that there was an error in LB78 on 802.11r D3.0. There are problems with members with multiple badge numbers in the web-based voting system. 1.15.8.7. The audited results are: 1.15.8.7.1. 317: 53: 63 1.15.8.7.2. 83.6% return, 85.7% approve 1.15.8.8. This was the first time the affirmation rate has gone down during recirculation. 1.15.9. TGs – Donald Eastlake 1.15.9.1. There will be a tutorial this evening. 1.15.9.2. TGs will resolve informal comments from review. 1.15.9.3. Agenda in 1568r3. 1.15.10. TGT – Charles Wright 1.15.10.1. Will meet for 12 hours this week. Goal is to resolve comments from internal review to improve the draft. Expect letter ballot following January meeting. There are 202 technical comments, half have been addressed.

Minutes page 9 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

1.15.11. TGu – Stephen McCann 1.15.11.1. Stephen thanks Harry Worstell for chairing in Melbourne. Agenda in doc 1653. There are 8 hours of session. Will address liaisons and internal comments. 1.15.11.2. There is an incoming liaison letter from 3GPP SA3. 1.15.12. TGv – Pat Calhoun 1.15.12.1. Not present 1.15.13. TGw – Jesse Walker 1.15.13.1. Thanks Donald Eastlake for chairing TGw in Melbourne. 1.15.13.2. Jesse requests voters to vote on LB88 during this week 1.15.13.3. TGw has 5 sessions, document 1730r1 is agenda. Will address the 460 comments that have been submitted so far. 1.15.13.4. TGw is looking for a new secretary. 1.15.14. TGy – Peter Ecclesine 1.15.14.1. There are three meeting sessions. 1.15.14.2. Will have joint meeting with 802.16 on Thursday AM. 1.15.14.3. Thursday afternoon will review draft for possible Letter Ballot. 1.15.15. TGv – Emily Qi for Pat Calhoun 1.15.15.1. Will continue presentations and address internal comments. 1.16. Joint Interchange items 1.16.1. Stephen McCann and TK Tan will coordinate mid-week plenary joint interchange agenda. 1.17. Announcements 1.17.1. Stuart reminds that liaison reports that are due on Wednesday. 1.18. Recess 1.18.1. The session is recessed at 15:09.

2. Wednesday, November 15, 2006 2.1. Opening 2.1.1. The meeting is called to order by Stuart J. Kerry at 10:30 2.1.2. Stuart welcomes members to the 100th session of 802.11. Cake and champagne was provided for everyone. 2.1.3. Stuart asks permission from members for permission for photographs. There is no objection. Photographs are permitted for this part 2.1.4. Stuart welcomes a special guest: Vic Hayes, 802.11 Chair from 1990 to 2000. 2.1.5. The officers of 802.11 WG and TGs take photos while cutting the cake and opening the champagne. 2.2. Agenda 2.2.1. The review has been slightly adjusted for the celebration 2.2.2. Are there any other modification? None 2.2.3. The agenda is approved with unanimous consent 2.3. LOA 2.3.1. Stuart asks if there any new LOAs. There are none

Minutes page 10 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

2.3.2. Stuart asks if all members aware of the patent and LOA policy? There is no dissent. Stuart states that we are running according to that policy. 2.4. Attendance 2.4.1. There were some duplicate names in the database. We have removed some, so members may need to sign in again. 2.4.2. There are 418 people in the room 2.5. CAC 2.5.1. The CAC will meet Thursday evening at 7:30pm. 2.6. Announcements 2.6.1. TGw will meet at 16:00 at Cumberland “g” 2.6.2. TGy will meet at cottonbowl at 08:00 2.6.3. TK Tan will discuss the AV DLS study group with Tony Jeffree (802.1 Chair). 2.7. Presentation by Vic Hayes on 802.11 and WiFi 2.7.1. Document 1816r0 reviews the history of 802.11 2.7.2. Stuart notes that Vic will receive an award from IEEE next year. 2.7.3. Darwin Engwer shows a presentation minutes of the 802 meeting in July 1990 where the “through the air group” was first formed and discussed. Vic Hayes was elected chair of this ad-hoc group. 2.7.4. A framed copy of the first minutes of 802.11 is presented to Vic Hayes 2.7.5. Stuart states that photographs are no longer permitted for the remainder of the meeting. 2.8. Liaison Reports 2.8.1. 802.18 Liaison Report – Denis Kuahara 2.8.1.1. Document 11-06-1798r0 2.8.1.2. Have been working on submission for ITU-R to WP 8A. 2.8.1.3. Also working on response to FCC R&O regarding TV “white space”. Comments received from 802.22. 2.8.1.4. Reviewing GlobalStar petition regarding terrestrial repeaters. 2.8.1.5. There is a concern over 40MHz channelization in both 2.4GHz band and 5GHz band. In 2.4GHz it is coexistence, in 5GHz it is DFS. IEEE 802.11 needs to demonstrate that there is not a problem. RR-TAG is requesting substantive documentation to take back to regulators to avoid regulatory mandates. 2.8.1.6. Denis Kuahara will not continue to attend, and notes that the Liaison position is open. 2.8.1.7. A photograph of Denis is taken with the groups assent. 2.8.1.8. Discussion 2.8.1.8.1. There are issues with the 40MHz channelization and TGn. Bruce Kraemer notes that TGn is working hard to address these issues. Has 802.18 give the clearest possible directive to TGn? TGn needs a good representative in 802.18. 2.8.1.8.2. Denis expects Peter Murray to take over as 802.18 liaison 2.8.1.8.3. Denis notes that the approach of WFA was not trying to avoid the concerns that the regulators had with 802.11g. We need to keep regulators informed, and get them on board. 2.8.1.9. Stuart thanks Denis for his contributions to 802.11 and 802.18.

Minutes page 11 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

2.8.2. 802.19 liaison report – Sheung Li 2.8.2.1. Document 11-06-338r4 (TGn CA document) was approved by TGn and reviewed by 802.19. 2.8.2.2. Document 19-06-41 is a contribution to .19 with links to an open source program for evaluating coexistence of arbitrary wireless systems. 2.8.2.3. Stuart asks if Sheung is transferring to a different 802 group. Sheung says it is only a rumor. 2.8.3. 802.21 liaison report – David Hunter 2.8.3.1. Media Independent Handover 2.8.3.2. Report in 11/06-1820 2.8.3.3. 802.21 is in recirculation balloting, expecting sponsor ballot in March 2007. 2.8.4. 802 Architecture – Andrew Myles 2.8.4.1. There was no new material presented on Sunday. The group discussed the future of the group, and concluded that the 802 architecture will no longer meet every Plenary. It will only meet on an as-needed basis to address specific issues. Such meetings would occur during plenary tutorial slots, so everyone can attend. 2.8.4.2. Stuart and Andrew have discussed the liaison and decided to discontinue the official liaison position. 2.8.4.3. Andrew mentions that the 802 Wireless Architecture group has also been dissolved. 2.8.5. WiFi Alliance Liaison report – Andrew Myles 2.8.5.1. Clint Chaplin has stepped down as WFA Liaison. 2.8.5.2. Stuart approves Andrew Myles as the new liaison 2.8.5.3. Report in document 06-1803 2.8.5.4. Clint Chaplin has changed employers and has resigned as WFA chair. Andrew Myles has been elected as the chair of the WFA board of directors. 2.8.5.5. Andrew points out how the pace of IEEE is hampering progress of WFA in some areas. 2.8.5.6. There is existing or potential misalignment between WFA and IEEE standards. 2.8.5.7. Andrew provides suggestions for improving the IEEE 802.11 process. 2.8.5.8. Discussion 2.8.5.8.1. Stephen McCann asks about the drivers and movers of WFA. Feels he is missing a lot of important information on the direction of WFA, etc. Proposes organizing a joint 802.11 and WFA meeting at some point. If 802.11 needs some direct input from WFA – perhaps a tutorial by WFA. Or possibly during the Wednesday interchange session. Possibly members of WFA could make presentations to task groups to identify gaps and make improvements. 2.8.5.8.2. Andrew answers that in the short term there are a large number of people that attend both groups. Hopes they are providing the needed feedback. 2.8.5.9. Stuart challenges WFA and the liaison to provide a tutorial in January for the mid-week plenary. 2.8.6. IETF - Dorothy Stanley 2.8.6.1. Presentation in document 06-1782r0 2.8.6.2. There was an SDO workshop in October for IETF ECRIT (emergency services) 2.8.6.3. At the IETF meeting last week, the EAP WG met. It is finalizing two documents. The WG’s will be closing in Dec 06. 2.8.6.4. A new handover keying group has been formed. 2.8.6.5. The CAPWAP WG has broken output into two documents – protocol and binding extensions. Minutes page 12 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

2.8.6.6. Radius extensions are being worked on in RADEXT WG. 2.8.7. TIA 2.8.7.1. No updates 2.8.8. 3GPP 2.8.8.1. Open Position – no volunteers have offered to serve as this Liason 2.9. 802.11 Interchange 2.9.1. Stephen McCann presents a summary of the Emergency Services workshop. 2.9.1.1. Document 06/1723. 2.9.1.2. There was input from IEEE 802.11, 802.1ab, IETF, 3GPP2, 3GPP, TIA LLDP-MED, TIA TR-45, OMA, ITU-T, ETSI, OCG, EU, COMCARE, ESIF, ANSI, USDOT, NENA, and others. 2.9.1.3. It appears to be a daunting task to coordinate overlaps of so many groups and standards to convey location information over disparate networks. Everybody wants to control this area. 2.9.1.4. There is a possibility that network-push emergency alerts will be mandated. 2.9.2. Discussion 2.9.2.1. Scott H notes that the E911 centers are developing their own protocols to handle E911 functions, not only the push alerts, but inter-agency communication. There is also an FCC order that mandates that all wireless VoIP providers support E911 to the level of cellular carriers. That means locating the subscriber with infrastructure. The Calea requirements are even more stringent on location. 2.9.2.2. Lee A asks about the scope of the workshop: is it regarding voice services only? Stephen agrees, although there may be other initiatives. 2.9.2.3. Scotts adds that there was discussion of non-voice emergency applications. 2.9.2.4. Harry W thanks Stephen McCann for doing a great job supporting this workshop. 2.9.2.5. Harry also notes that this is an appropriate issue for the 802 architecture group to take on. Andrew agrees, and requests materials summarizing the situation. 2.10. 802.11 newsletter 2.10.1. Stuart has been discussing the possibility of a wireless newsletter with Fanny Mlinarsky and the IEEE. 2.10.1.1. Fanny presents document 06/1802 with a proposal for a newsletter. Fanny is founder and CTO of Azimuth, but is no longer involved actively with the company. She is unaffiliated, so could provide unbiased input. 2.10.1.2. Initially wanted to do a newsletter on 802.11. Now the proposal is for all of 802 – as the 802 Insider. 2.10.1.3. Fanny feels that a newsletter would put everything into context and represent multiple points of view. 2.10.1.4. There would be sub-sections for each 802 working group. 2.10.1.5. There would be a subscription price charged by the IEEE. 2.10.1.6. Content would be obtained from interviews from active members, and there would be invited authors. 2.10.1.7. Newsletters would be published after every plenary. 2.10.2. Straw Poll on the general concept: would it be useful to have a regular newsletter? 2.10.2.1. Nearly unanimous in favor. 2.10.3. Feedback and discussion from the floor 2.10.3.1. Is this officially IEEE? How will the content be approved? If this is private then it doesn’t matter.

Minutes page 13 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

2.10.3.2. Stuart says the details have not been sorted out. It would come from interviews, but yes there is a possibility of disagreement among individuals. 2.10.3.3. Fanny suggests a formal review process with the chairs. Thinks it should be official IEEE, and published by IEEE. 2.10.3.4. Dorothy S feels the concept is useful to allow 802.11 to review other groups. How would this affect the rule of TG chairs being not allowed to speak for their groups? 2.10.3.5. Stephen McCann asks if this is a spoken and recorded interview. Fanny says yes. 2.10.3.6. Stephen asks if the information is moderated? Are TG chairs speaking as chairs or individuals? 2.10.3.7. Fanny wants to understand the issues and the different sides of issues. It will be important to interview more than the chairs, but the chairs should review. 2.10.3.8. Adrian S would like to see the dissenting positions within groups, without being sanitized, even if the chair would be uncomfortable. Would prefer a true “insider” publication. 2.10.3.9. Peter E notes that TG chairs have to be interviewed during the week. 2.10.3.10. Aryan thinks it is valuable to distribute information. Suggests that the website needs improvement. Minutes and updates are scattered. 2.10.3.11. Stuart solicits volunteers to help with the website. However, most of the key information is on two pages, the timeline and the reports page. 2.10.3.12. Aryan is concerned about a fee-based mechanism for better information. Perhaps the fees should come from the regular meeting fees. 2.11. Any other business 2.11.1.1. Darwin E reminds that configuration was difficult in the early days. Darwin has observed that some people have trouble, and reminds members to help “real world” people having trouble with 802.11. 2.12. Recess 2.12.1. The meeting is recessed at 12:31

3. Friday, November 17, 2006 3.1. Opening 3.1.1. The meeting is called to order by Stuart J. Kerry at 08:00 3.1.2. There are 138 people in the room 3.2. Agenda update 3.2.1. The agenda is in r4 3.2.2. There is an update, striking out task groups that have no motions or actions. 3.2.3. There is no new business 3.2.4. Stuart asks for any other changes for the agenda – there are none. 3.2.5. The agenda is approved with unanimous consent 3.3. IEEE SA LOA 3.3.1. Does the chair need to be aware of an LOA – there are none 3.3.2. Members are aware of the policies and it is deemed they will participate accordingly. 3.4. CAC 3.4.1. There will be email updates for the CAC call schedule Minutes page 14 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.5. Documentation update 3.5.1. Harry Worstell states that we have over 1850 documents, not including revisions. We have more documents this year than any single year previously. 3.5.2. Documents are still on 802wireless world, and ftp.802wirelessworld.com is the easiest mechanism for accessing. The HTTP site is still the only way to get document numbers. 3.5.3. We will try to have a replacement document control mechanism soon provided by the IEEE IT Staff. 3.5.4. Stuart notes that if 802wirlesssworld asks for contact details, just click “cancel”. The update does not work. 3.5.5. Harry notes that the templates have been updated because Stuart’s email address has changed. Members are instructed that it will be mandatory to use the new templates starting December 1st, 2006. 3.6. Working Group policies and procedures 3.6.1. Al Petrick reviews doc 06/812r3, which is the current P&P. We are collecting changes to the P&P which will be posted at the end of this session. 3.6.2. If the members have any suggestions for changes to the P&P, they should email to Al Petrick. 3.7. Timeline Update 3.7.1. Tim Godfrey reviews the changes to the timeline, which has been updated to incorporate the results of this meeting. 3.8. WG Editor Update 3.8.1. Simon Barber presents doc 1882r0 3.8.2. Simon Barber will provide updates the ANSI/ISO publications dates for 11g and 11h for the timeline. 3.8.3. The minutes for the editors meeting are in 06/1776 3.8.4. Discussion 3.8.4.1. Bruce K asks if we have decided what to do with international standardization of 802.11rev-ma? 3.8.4.2. Simon says we will take 11ma to ISO, but we have not officially decided. Simon will check with Terry Cole on how to proceed. 3.8.4.3. Stuart asks Bob O’Hara to check and see if the PAR for 11ma indicates ISO. Simon believes it does. 3.8.4.4. Andrew M suggests we wait until ISO and IEEE resolve how they will work together. 3.9. Venue straw poll 3.9.1. How many members liked the venue and would come back again? 121 Yes, 60 No. 3.9.2. Stuart notes that the small celebration on Wednesday was Stuart’s gift to the membership for their hard work and diligence over the years. 3.10. WNG Report 3.10.1. Document 1743r1.

Minutes page 15 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.10.2. The meeting consisted presentations of four documents related to multicast and cooperative communications. 3.10.3. There were no motions. 3.11. TGk Report 3.11.1. Richard Paine presents document 1880r0 3.11.2. LB90 does not close until mid-night tonight. 3.11.3. TGk will not be able to go to recirculation ballot or sponsor ballot. This is a 4 month setback. The issue was that the first procedural LB was delayed by an insufficient return rate. 3.11.4. Richard encourages anyone to send him questions about outstanding ballots. 3.11.5. 177 early submitted comments were addressed. 3.11.6. In January, will continue LB90 comment resolution and recirculation ballot. 3.11.7. Discussion 3.11.8. Jon R asks for clarification on the closing time of LB90. Richard answers that LB90 closes tonight and there will be more comments to resolve in January. 3.12. TGma and ANA 3.12.1. Bob O’Hara presents report in 1752r0 3.12.2. TGm processed an interpretation request regarding replay protection for TKIP. The response is in document 1751r0. The standard is not ambiguous – there is only one normative statement. 3.12.3. In January, TGm will process any new interpretation request, and develop PAR for 802.11mb maintenance work. 3.12.4. There were no requests for ANA identifiers. 3.13. TGn Report 3.13.1. Bruce Kraemer presents document 1811r0 3.13.2. The CA document has been completed 3.13.3. Editorial, Beamforming and Link adaptation ad-hocs have completed their work. 3.13.4. There are still unresolved comments in Frame, PHY, MAC, and Coexistence. 3.13.5. Entering this week, there were 590 unresolved technical comments. Now, there are 370 comments remaining unresolved. 3.13.6. The draft will be updated to D1.07, incorporating all comment resolutions this week. 3.13.7. The most controversial topic is 40MHz operation in the 2.4GHz band. 3.13.8. Conference calls are scheduled, and there will be an ad-hoc preceding the January meeting in London. 3.13.9. TGn expects to leave the January meeting with all comments resolved, and soon after the meeting D2.0 will go to Letter Ballot.

Minutes page 16 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.13.10. Bruce reminds members that intend to attend the London Ad Hoc to please notify Bruce or Jon Rosdahl so we can calculate the meeting size. 3.13.11. Discussion 3.13.11.1. Bruce states that the AdHoc plan has been modified to be three days. Saturday is not a meeting day. 3.14. TGp Report 3.14.1. Lee Armstrong presents document 1868r1 3.14.2. All comments from the previous letter ballot have been resolved, and a new draft has been approved and posted. 3.14.3. The Task Group approved conducting a new Letter Ballot. 3.14.4. The document has been greatly simplified compared to the previous draft. 3.15. TGr Report 3.15.1. Clint Chaplin presents document 06/1877r0 3.15.2. TGr has addressed all comments from previous letter ballots: LB82 and LB87, and will conduct a recirculation letter ballot following this meeting. 3.15.3. The Task Group heard document 06/1867 on general security requirements. Clint asks members to consider whether the draft actually meets these requirements. 3.15.4. Stuart suggests that this document should be referenced in the cover letter for the letter ballot. 3.15.5. There will be an Ad Hoc February 21st. 3.15.6. The TG voted to conduct an external security review of P802.11r- D4.0. 3.15.7. In January TGr will process comments on the recirculation ballot. 3.16. TGs Report 3.16.1. Donald Eastlake presents 06/1879r0 3.16.2. TGs processed informal comments and developed draft 0.6, which will be submitted for letter ballot. 3.16.3. The TG voted to submit D0.6 to Letter ballot. 3.16.4. There will be an ad hoc February 6-8 to resolve LB comments. 3.17. TGT Report 3.17.1. Charles Wright presents document 06/1720r0 3.17.2. TGt heard 6 presentations, and resolved comments from internal review. 3.17.3. After this week there are 47 deferred comments remaining. 3.17.4. TGT believes that a letter ballot is possible after the January meeting. 3.17.5. TGT comment resolution is in 1872r23. 3.17.6. There will be three teleconference 3.18. TGu Report

Minutes page 17 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.18.1. Stephen McCann presents 1869r1 3.18.2. TGu refined requirements and scope during the week and edited the baseline draft to D0.02. 3.18.3. There were 4 submissions 3.18.3.1. MSSID (11-06-1473r1) 3.18.3.2. Intersystem roaming (11-06-1848r0) 3.18.3.3. User Plane QoS mapping (11-06-1772r1) 3.18.3.4. Limiting GAS response messages (11-06-1784r1) 3.18.4. There were liaison documents developed and approved. These will be brought for WG approval. 3.18.4.1. 3GPP SA3 (11-06-1814r0) : MAC Address 3.18.4.2. 3GPP SA2 (11-06-1813r1) : 23.234 (730) 3.18.4.3. WFA (11-06-1838r2) : TGu review 3.18.4.4. IEEE 802.21 (11-06-1873r0) : Requirement R12N8 3.18.5. There will be 2 teleconferences. In January TGu will review D0.2 comments from review. 3.19. TGv Report 3.19.1. Pat Calhoun presents Report in 1878r0 3.19.2. TGv has resolved 201 comments, and will generate a new draft 0.7 including resolved comments and new normative text. 3.19.3. In January, TGv will continue comment resolutions. 3.20. TGw Report 3.20.1. Jesse walker presents doc 1876r0 3.20.2. TGw started the comment review of LB88. This LB closes this coming Sunday. It appears that about half the members have voted so far. 3.20.3. There have been 500 comments received so far, which were reviewed. 3.20.4. About 30 resolutions were completed. 3.20.5. TGw is still looking for a permanent secretary. 3.20.6. There was one presentation this week 06/1655 3.20.7. The TG voted to create an updated draft based on resolved comments. 3.20.8. There will be bi-weekly teleconferences starting Dec 12th. There will be an ad-hoc meeting in Santa Clara January 21st. 3.20.9. In January will continue resolving comments on LB88 3.21. TGy Report 3.21.1. Peter E presents 1675r2 3.21.2. WG internal technical review was conducted on P802.11y D0.01, 163 comments and resolutions are recorded in 06/1609 3.21.3. The following normative text has been accepted and will be integrated into the next TGy draft 3.21.3.1. 06-0955-03-000y-ofdm-phy-3650-mhz-band.doc 3.21.3.2. 06-0864-04-000y-3650-mhz-mobile-service-enablement.doc 3.21.3.3. 11-06-1432-01-000y-extended-csa.doc Minutes page 18 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.21.4. TGy passed a motion to accept 06/1727r2 draft normative text changes and instruct the editor to prepare P802.11y D0.02, which will be sent to Letter Ballot. 3.22. Task Group Motions 3.22.1. (TGm) Moved: to accept document 06/1751r0 as the response to the interpretation request #1. 3.22.1.1. Moved Bob O’Hara on behalf of TGm 3.22.1.2. Vote: motion passes 76 : 0 : 11 3.22.2. (TGp) Move to authorize a 30-day letter ballot, and renumber Draft P802.11p_D1.5 as P802.11p_D2.0, with the ballot to begin as soon as practical asking the question “Should Draft P802.11p_D2.0 be forwarded to Sponsor Ballot?” 3.22.2.1. Moved Lee Armstrong 3.22.2.2. Second Clint Chaplin 3.22.2.3. Vote: motion passes 76 : 0 : 10 3.22.3. (TGr) MOTION: Move to authorize a 15-day Working Group Recirculation Letter Ballot of 802.11r draft 4.0, asking the question “Should the 802.11r draft 4.0 be forwarded to sponsor ballot?” 3.22.3.1. Moved Clint Chaplin on behalf of TGr 3.22.3.2. Vote: motion passes 79 : 0 : 4 3.22.4. MOTION: Move to authorize an IEEE 802.11 TGr ad-hoc meeting on February 21st through February 23rd, 2007 3.22.4.1. Moved Clint Chaplin on behalf of TGr 3.22.4.2. Vote: Approved with unanimous consent 3.22.5. Motion: Believing that 802.11s draft D0.06 satisfies all 802.11 WG rules for letter ballot, Moved, To request the 802.11 Working Group to renumber 802.11s Draft D0.06 as D1.0 and authorize a 30-day Letter Ballot asking the question “Should 802.11s draft D1.0 be forwarded to Sponsor Ballot?” 3.22.5.1. Moved Donald Eastlake on behalf of TGs 3.22.5.2. Vote: motion passes 79 : 1 : 8 3.22.6. Moved, To approve a TGs ad hoc meeting in Hillsboro, Oregon, February 6-8, 2007, to resolve Letter Ballot comments 3.22.6.1. Moved Donald Eastlake on behalf of TGs 3.22.6.2. Vote: Approved with unanimous consent 3.22.7. Move to approve liaison document (11-06-1813r1) and ask the IEEE 802.11 WG chair to forward it to 3GPP SA3 informing them about the decision of IEEE 802.11u to remove MAC Address anonymity as a requirement. 3.22.7.1. Moved Stephen McCann 3.22.7.2. Second Charles Wright 3.22.7.3. Vote: motion passes 70 : 1 : 10 3.22.8. Move to approve liaison document (11-06-1814r0) and ask the IEEE 802.11 WG chair to forward it to 3GPP SA2 informing them about concerns that IEEE 802.11u has about document 3GPP TS 23.234 (730) 3.22.8.1. Moved Stephen McCann 3.22.8.2. Second Charles Wright

Minutes page 19 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.22.8.3. Vote: motion passes 72 : 0 : 9 3.22.9. Move to approve liaison document (11-06-1838r2) and ask the IEEE 802.11 WG chair to forward it to WFA (WiFi Alliance) inviting them to participate in an informal IEEE 802.11u review of the IEEE 802.11u baseline draft D0.02. 3.22.9.1. Moved Stephen McCann 3.22.9.2. Second Ian Sherlock 3.22.9.2.1. Discussion 3.22.9.2.1.1. Peter E asks if there is any additional expertise in WFA that is not present in IEEE 802.11? 3.22.9.2.1.2. Stuart cannot speculate on that. 3.22.9.3. Vote: motion passes 69 : 4 : 9 3.22.10. Move to approve liaison document (11-06-1873r0) and then asks the IEEE 802.11 WG chair to forward it to IEEE 802.21 asking them about whether they wish to work on IEEE 802.11u requirement R12N8 (online subscription methods) within their project. 3.22.10.1. Moved Stephen McCann 3.22.10.2. Second Charles Wright 3.22.10.3. Vote: motion passes 68 : 0 : 11 3.22.11. Motion: Moved to authorize TGw to hold an ad hoc meeting, to propose resolutions to LB 88 comments, in Santa Clara, CA, January 29- 31, 2007 3.22.11.1. Moved Jesse Walker on behalf of TGw 3.22.11.2. Vote: Approved with unanimous consent 3.22.12. Move to authorize a 30-day Working Group Letter Ballot of P802.11y draft 1.0, asking the question “Should the P802.11y draft 1.0 be forwarded to sponsor ballot?” 3.22.12.1. Moved Peter Ecclesine on behalf of TGy 3.22.12.2. Vote: motion passes 69 : 0 : 10 3.23. 802.16m PAR response 3.23.1. Presentation by Roger Marks 3.23.2. Comments on 802.16m PAR. Response is in document 11-06- 1884r0 3.23.3. Roger Marks, 802.16 chair, provides an overview of the 802.16m PAR. 3.23.4. Roger clarifies that 802.16 is not proposing making an entire ITU standard. The updated PAR clarifies that 802.16 is only targeting the cellular layer in the ITU IMT-advanced standards program. Roger notes that 802 needs to think about how we can build the connecting technologies to interconnect the various 802 standards into a complete network. 3.23.5. Roger states that he has a good relation with ITU and can help communicate to them. 3.23.6. Discussion from the floor 3.23.7. Bruce K thanks Roger for the adjustments to the PAR based on our suggestions. He feels that 802.11 will need to start working to fill in the gaps in this ITU architecture. He looks forward to working with 802.16 on this joint work.

Minutes page 20 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.23.8. Stuart asks if there should be a joint liaison for working toward a complete system solution. Bruce clarifies that we are not ready to start a SG now, but eventually it would be needed. 3.23.9. Stephen McCann notes that if we approve the 16m PAR,802.11 will have to follow with a SG, as well as 802.15 and 802.20. Feels that the 802 architecture group should address this system/network issue. We need some harmonization on this and set some appropriate precedents. 3.23.10. Stephen also notes that the overall network diagram seems like it is suited to 802, but it also appears to be suited to 3G. Worried about the 3G standards bodies also deciding to standardize their own WLAN and other 802 areas. 3.23.11. Roger states that IMT-Advanced will not choose one and exclude others. They tend to adopt multiple interfaces simultaneously. But 802 has strengths at the hotspot and PAN layer. Be 802 is limited because it stops at layer 2. We need to move higher to integrate the entire network solution. 3.24. 802.1Qav PAR Response 3.24.1. Al Petrick reviews doc 1883r0, which contains the 802.11 response to 802.1 3.24.2. 802.11 proposes changes to scope: (including mixed wired and wireless networks). 3.24.3. Adrian Stephens is concerned that there is not much engagement between 802.1 and 802.11. There are usage models that need the attention of 802.1 to complement what happens in wireless groups. For example bridging WiMax to WiFi – there is a need to standardizing bridging to properly support QoS. We have the expertise in our wireless MAC, but we don’t have a mechanism to coordinate. 3.24.4. Al notes that we can bring this to their attention when the PAR comes up at ExCom 3.24.5. Jon Rosdahl notes that this group has not taken a position of what we would like to see happen at ExCom. Will there be a motion to provide a position for the chair to take to ExCom? 3.24.6. Al Petrick suggests a straw poll to get the members opinion. The members have no disagreement that a straw poll would be a good mechanism to determine the opinion. 3.24.7. Straw Poll: Who is in favor of the PAR for 802.1Qav? About half the people are in favor, and none are against. 3.24.8. Adrian notes that this straw poll might have captured the intent. Proposes new straw poll. 3.24.9. Straw Poll: Does the membership support the comments that have been submitted on the 802.1Qav PAR? >50% are for, none are against. 3.24.10. Straw Poll – who is in principle for the 802.16m PAR? About 40% for and 1% against 3.25. WG Motions: 3.25.1. Move to empower the following TG(s)/SG(s)/Ad-Hoc(s) to hold teleconference calls beginning no sooner than November 26, 2006 through 15 days past the end of the March 2007 Plenary Session.

Minutes page 21 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

Group Start Date Frequency Time

Task Group “k” November 30, 2006 Weekly 12:00 ET

Task Group “m” N/A N/A N/A

Task Group “n” November 29, 2006 Weekly 11:00 ET

Task Group “p” N/A N/A N/A

Task Group “r” December 6, 2006 Weekly 11:00 ET Task Group “s” January 3, 2007 Once 17:00 ET

Task Group “T” November 30, 2006 Once 12:00 ET December 14, 2006 Once January 11, 2007 Once Task Group “u” December 12, 2006 Once 10:00 ET January 4, 2007 Once February 13, 2007 Once March 6, 2007 Once Task Group “v” December 14, 2006 Once 1600 ET January 11, 2007 Once 1600 ET January 30, 2007 Bi-weekly 1200 ET Task Group “w” December 12, 2006 Bi-weekly 1600 ET

Task Group “y” December 5, 2006 Bi-weekly 13:00 ET January 9, 2007 Once 3.25.1.1. Moved Harry Worstell 3.25.1.2. Second Al Petrick 3.25.1.3. Vote: approved with unanimous consent 3.25.2. Move to empower the 802.11 WG, Task Groups, SGs, and SCs to hold meetings during the January 2007 Interim Session to conduct business as deemed necessary. 3.25.2.1. Moved Al Petrick 3.25.2.2. Second Harry Worstell 3.25.2.3. Vote: approved with unanimous consent 3.25.3. Straw Poll: The IEEE 802.11 Working Group resolves that no venues in Australia shall be considered for Interim Sessions prior to January 2010. 3.25.3.1. Discussion 3.25.3.1.1. Stuart notes that Sydney is being considered for a joint 802 hosted interim location. 3.25.3.1.2. Stephen McCann: isn’t this a political statement? It is out of order. 3.25.3.1.3. Jon R notes that he has spoke with Larry, and the concern is we have been to Australia 3 times in 4 years. Would like to consider other venues in Asia/Pac region. 3.25.3.1.4. Dave B agrees with the motion. These venues are expensive, have long flights, and have lower attendance. We should stop doing this. 3.25.3.1.5. Jim P agrees with Dave B’s position. 3.25.3.2. Straw Poll Results: 28 for, 64 against (Fails) 3.26. TGn Motions 3.26.1. Move to request authorization for TGn to conduct an ad hoc meeting for the purpose of comment resolution from Wednesday 10- January 2007 through Friday 12-January 2007 at the London UK Hilton Paddington Hotel

Minutes page 22 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.26.1.1. Moved Bruce Kraemer on behalf of TGn 3.26.1.2. Vote: approved with unanimous consent 3.26.2. Request authorization for TGn to investigate venues at which it could conduct ad hoc meetings for the purpose of comment resolution following the close of letter ballot for Draft 2.0 both 1. Immediately following the March plenary meeting in Orlando with the preferred location being the Caribe Royale Hotel 2. An acceptable location during mid-April 2007. pending final review/approval to be held during the January interim meeting in London 3.26.2.1. Moved Bruce Kraemer on behalf of TGn 3.26.2.2. Discussion 3.26.2.2.1. Stephen McCann – is this either or both? Bruce says it could be both. Stephen suggests changing “either” to “both”. 3.26.2.2.2. 3.26.2.3. Second Jon R 3.26.2.4. Vote: approved with unanimous consent 3.26.3. Request authorization for TGn to investigate venues at which it could conduct an ad hoc meeting for the purpose of comment resolution following the close of letter ballot for Draft 2.0 to be held just prior to the May Interim in Montreal Canada Wednesday May 9 thru Friday May 11 2007 with the preferred option being the Fairmont Hotel, pending final review/approval to be held during the March plenary meeting in Orlando 3.26.3.1. Moved Bruce Kraemer 3.26.3.2. Discussion 3.26.3.2.1. Harry asks if we need authorization since there is a March Plenary. Bruce answers that we can’t do the venue planning in that timeframe. It must be done before the March plenary session. It takes about 6 months to locate hotel space. 3.26.3.3. Vote: approved with unanimous consent 3.27. Other Business 3.27.1. Harry notes that there is a low turnout in letter ballot responses. Voting rights by some members are being lost due to non-response on letter ballots, per relevant P&Ps. The WG Chair reviews every individual case request for re-establishment of voting rights. 3.27.2. Harry states that members must address attendance and voting issues before meetings, as there is not enough time during our sessions. 3.27.3. Members are advised to sign in for today’s attendance. 3.27.4. We are at break time. There is no objection to continuing to conclusion. 3.27.5. Charles states that the updated templates are not yet available. Stuart says Harry will update them before December 1st. Harry will post a reminder to the reflector. 3.27.6. Stephen McCann was secretary for WNG, and noticed that many submissions are sloppy with respect to headers and footers and document properties. Please take care to follow the procedures and formats. Stuart requests all Chairs to make sure the P&Ps related to this issue are being followed.

Minutes page 23 Tim Godfrey, Freescale

November, 2006 doc.: IEEE 802.11-06/1740r0

3.27.7. Stuart asks if there is any other business. There is none. 3.28. Next Meeting 3.28.1. The next meeting of 802.11 is at the Hilton London Metropole, London UK. Jan 14-19, 2007. It will be our 101st meeting, and will be sponsored by IEEE 802. Members are encouraged to book early. 3.29. Adjourn 3.29.1. The meeting is adjourned at 10:14am

Minutes page 24 Tim Godfrey, Freescale

November 2006 doc.: IEEE 802.11-06/1758r23

IEEE P802.11 Wireless LANs

Minutes of TGk Dallas Meeting

Date: 2006-11-13

Author(s): Name Company Address Phone email 1700 S. El Camino San Mateo, Paul Gray AirWave Wireless 650-678-5633 [email protected] CA

Abstract This document contains TG 11k minutes from Dallas Meeting.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

11/13/06 PM1 Session:

Meeting called to order at 16:11

1. Chair provided the standard IEEE policies and procedures. a. Patent Policy – Chair read and reviewed new Patent Policy b. Inappropriate Topics – Chair read and reviewed the Policy c. Documentation and Presentation rules

2. Presentation of Agenda – agenda passes unanimously

3. Comment Resolution LB 90 Comment Resolutions

CID #10 – Accepted CID #9 – Accepted CID #11 – Accepted CID #12 – Accepted CID 18 - Deferred CID 19 - Deferred CID 35 – Accept CID 36 – Accepted (should use +/-) CID 58 – Accepted CID 37 – Accepted CID 38 – Accepted defer to Editor CID 63 – Accepted CID 39 – Accepted CID 62 – Accepted CID 40 – Accepted CID 68 – Counter change “Delay error trigger” to “Delay exceeding the Delay Threshold” CID 40 – Accepted CID 64 – Accepted– Editor to implement same change in all places in this clause CID 29 – Decline - On pages 38, 39, and 40 the table title indicates that this is a continued table from the prior page CID 30 – Decline “No complex LIFO intended or required here” CID 65 – Decline – P41 L 17indicates that the “x” is not part of the Annex Variable name, but must be replace with 0-7 to obtain the correct Annex D variable names. The Annex D descriptions are correct. CID 66 – Accepted – same as 11 CID 67 – Accepted – P41L42-44 does not address behaviour for non-AP stations, it addresses behaviour for non-QoS APs. The commenter is correct that a statistics request should be rejected by a non-AP station. No changes needed. CID #68 – Counter - P44L27, change: "Delay error trigger" to "delay exceeding the Delay Threshold" CID#48 - Deferred

4. Meeting ends at 18:00

Submission page 2 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

11/14/06 AM2 Session:

Meeting called to order at 10:31

1. Chair provided the standard IEEE policies and procedures. a. Patent Policy – Chair read and reviewed new Patent Policy b. Inappropriate Topics – Chair read and reviewed the Policy c. Documentation and Presentation rules

2. LB 90 Comment Resolutions

• CID #33 – Accepted • • CID #41 – Deferred – focus on the use of “service” - It is “a” measure of service load, not “the” - It is a weak measure of service load - Access Delay is better a high loading

• CID #42 –Deferred Comment - The logarithmically scaled bins are unnecessarily complicated to implement: they require about 512 octets to store the thresholds, and 8 iterations of a binary search. Replace by a 3-level if/else/right-shift with about 6 octets of storage

- dB scale does not require a lookup scale - Hart can provide a 3 line implementation.

• CID #43 – Accept with discussion on how to resolve.

• CID #60 – Comment - If there is microwave oven operating around the AP, the Access delay could be larger than 50usec. Would the microwave oven interference be considered as the service load? IMHO, Access Delay projects the kind of traffic load, but it is cannot give the indication of AP service load.

- 1000 uses of the word “service” and only 3 uses of the word “load” - Similar to CID #41

• CID #69 – Accepted defer to Editor prerogative Comment - It is stated that the value 0 indicates that this AP is not currently serving any STA. However on line 38 the value 0 has the meaning access delay < 50us which seem to indicate that the AP is serving some STAs and access delay is < 50 us.

• CID #70 – Deferred and editor will Comment - In beacon report 7.3.2.22.6 page 34 lines 40-43 antenna ID value usage described in the case the preamble is received with different antenna than the frame body. According to that the antenna ID used for the frame body is reported. According to this the value should be 255 if the antennas were switched during the measurement. Does it also apply to the case different antennas are used for preamble and body.

- The antenna id should identify the antenna used for the associated measurement. - We should not address switching - Add remove the 255

Submission page 3 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

• CID #40 – Accept (Editorial)

• CID #31 – Deferred Comment - I don't see how the "BSS Available Admission Capacity element provides any additional information beyond the existing BSS Load Element in the .11-REVma- D8.0 draft. It seems like the granularity in this new element is not very useful and just serves to increase the number of information elements that are bloating the beacons.

- It is good for a multi media handset that is roaming in a CAC environment. - It does not give you an incremental gain over the cost. - We have to fight the beacon bloat in the base standard - Could we change to “may be present’ instead of “shall be present” - It will help roaming performance - If it is optional people will not implement it. - Keep it mandatory, but scale it down to 1 or 2 bytes. - We could eliminate if you have 1 or less QoS category - It should go in beacon probe response

Straw Poll Would you support an available admission capacity IE that is omitted entirely if only 0 or 1 ACM bits are set in EDCA parameters element for resolving LB 90 CID #31?

Yes: 7 No: 2

• CID #32 - Deferred Comment - I don't see how the "BSS AC Access Delay element provides any additional information beyond the available medium time information in the existing BSS Load Element in the .11-REVma-D8.0 draft. It seems like the granularity in this new element is not very useful and just serves to increase the number of information elements that are bloating the beacons.

- Related to Beacon bloat. - Consider moving items to Neighbor Report

• CID #45 – Deferred (same as 41)

• CID #46 – Deferred (same as 42)

• CID #47 – Accepted

• CID #76 – Accepted – Editor should review all references in the PICs.

• CID #4 – Declined – Commenter withdrawals the comment

• CID #23 – Accepted – Editor to modify text in Annex J refreshing J referencing tables J.1-3 to align with new table titles.

• CID #65 – Change to Deferred

• CID #20 – Accepted

• CID #27 – Accepted P5 L42

Submission page 4 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

• CID #28 – Accepted same as 63

• CID #34 – Deferred – assigned to Paine

• CID #49 – Counter – “MeasurementEnabled”

• CID #50 – Counter – replacement “target” with “Maximum” in all places

• CID #52 – Accept – Editor to clarify per description in 7.4.6.1.

• CID #53 – Accepted

• CID #54 – Counter – Delete the sentence

3. Session ends at 12:35.

Submission page 5 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

11/14/06 PM2 Session:

Meeting called to order at 16:00

1. LB 90 Comment Resolutions 1739r7

• CID #55 – Deferred – Joe will get with Brian Hart to discuss

• CID #56 – Accepted

• CID #57 – Declined – see spreadsheet for resolution Comment - Also P90L7, P90L15. Reporting MPs only when no beacons are received at all seems sub-optimal. MP info should may still be reported if there are no beacons from that BSSID

• CID #77 – Declined – discussion with commenter has revealed that a misunderstanding. BBS Average access delay does not replace QBSS load (now BSS load in 11ma)

Comment - BSS load is changed to the BSS Average Access Delay. In order to have more precise information, AC (access category) level information is needed besides average access delay. Since AC average access delay IE is defined in D6.0, it is better to focus on the "inaccurate info" instead of "general average access delay".

• CID #78 – Declined – This comment does not relate to changed text nor does it relate to a carried forward no vote comment.

• CID #79 – Declined – This comment does not relate to changed text nor does it relate to a carried forward no vote comment.

• CID #80 – Declined – This comment does not relate to changed text nor does it relate to a carried forward no vote comment.

• CID #81 – Declined – This comment does not relate to changed text nor does it relate to a carried forward no vote comment.

• CID #82 – Declined – This comment does not relate to changed text nor does it relate to a carried forward no vote comment.

• CID #59 – Declined – The commenter for the ref. LB83 comment has accepted the declination of the comment and has changed his vote.

Comment - Measurement Pilot Link SNR Ceiling -- this needs to be removed Related to comment LB 83 CID 684

• CID #71 – Accepted

• CID #72 – Accepted

• CID #73 – Accepted

• CID #74 – Accepted

• CID #75 – Accepted

Submission page 6 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

• CID #60 – Accepted – Richard will draft text

2. LB 90 Comment Resolutions (Deferred Comments) 1739r7

• CID #24 – Accepted – The two definitions are similar but not identical and cannot be merged as described in the definitions, the IPI values do not consider the NAV (virtual cs) which is only located in the MAC and maybe used to filter IPI values to indicate ANPI. Additional clarification is found on P93 L4-9 where the MAC filtering of IPI layers is described. P2 L11: change “an indication” to “a MAC indication”. P2 L18: change “an indication” to “a PHY indication”.

Comment - Also P90L7, P90L15. Reporting MPs only when no beacons are received at all seems sub-optimal. MP info should still be reported if there are no beacons from that BSSID

• CID #14 – Counter – P92 L18 and 11ma P173 L19: change “normalized to 255” to “linearly scaled with 255 representing 100%”.

Comment - "the percentage of time, normalized to 255," This is utterly meaningless. Percentage is a normalisation. Normalization to 255 is a different normalisation. Choose one, but doing both isn't possible.

• CID #15 – Counter – See new wording in CID #14

• CID #18 – Decline – The commenter refers to base 802.11 text unchanged by TGk. The concept of a station of supporting a feature or support an information element is common within 11ma. There are 220 occurrences of support used in this way. TGk will not endeavour to make a uniform set of changes within 11ma to improve this commonly used term. In addition this is text that his been in 802.11 for many years and is (so far) found to be acceptable to the 11ma review process. The commenter is urged to take his comment to TGmb.

Motion Move to accept the above text as a declination resolution to LB 90 CID #18.

Moved: Kwak Second: Ecclesine

Discussion

For: 7 Against: 0 Abstain: 2

Motion Passes

• CID #19 – Decline – The commenter refers to base 802.11 text unchanged by TGk. The statement that the STA “may ignore” an information element or a request occurs several times in the 11ma draft. There are 20 occurrences of “ignore” used in this way. TGk will not endeavour to make a uniform set of changes within 11ma to improve this commonly used term. In addition, this is text that his been in 802.11 for many years and is (so far) found to be acceptable by the 11ma review process. “ignore” is used to indicate the special circumstances under which an exception may be made to a requirement stated elsewhere. The commenter is urged to take his comment to TGmb.

Submission page 7 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

Motion Move to accept the above text as a declination resolution to LB 90 CID #19.

Moved: Kwak Second: Ecclesine

Discussion None

For: 8 Against: 0 Abstain: 2

Motion Passes

• CID #31 – Decline – This comment and all from Bahr are invalid, because Bahr is not part of the voting pool.

Discussion on how to reduce Beacon Bloat Too many mechanisms to check for admission controls

• CID #32 – Decline – This comment and all from Bahr are invalid, because Bahr is not part of the voting pool.

• CID #34 – Accepted – Document 06/1806r0 is provided for review and vote tomorrow.

• CID #41 – Counter – Remove “the service” quote from the referenced text

• CID #42 – Deferred

• CID #45 – Counter – Remove “the service” quote from the referenced text

• CID #43 – Deferred

3. Vote on the Melbourne Minutes

Motion Move to accept the Melbourne minutes found in 06/1457r3

Moved: Ganesh Second: Hart

Discussion None

For: 9 Against: 0 Abstain: 0

Motion Passes

4. Discuss on Sponsor Ballot. We must go to recirc again, because we have missed the timeline for Sponsor Ballot.

Submission page 8 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

5. Session ends 16:00

Submission page 9 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

11/16/06 PM2 Session:

Meeting called to order at 16:00

1. Agenda • LB 90 Comment Resolution • Approve Telcon Minutes • Vote on LB • Vote on SB • Review Timelines • Review Closing Plenary Report

2. LB 90 Comment Resolution 1739-12 • CID # 48 – Accepted – “P43L19, Change "azimuth of radio reception" to "azimuth of the bearing of the requestor with respect to the responder."

• CID #42 – Counter – Modify log scaling to be piece wise linear scaling in the following microsecond ranges: 8-120, step size equal 8; 128-1584, step size equal 16; 1600-6048, step size 32; 8192-24576, step equal 4906.

• CID #46 Counter – Modify log scaling to be piece wise linear scaling in the following microsecond ranges: 8-120, step size equal 8; 128-1584, step size equal 16; 1600-6048, step size 32; 8192-24576, step equal 4906.

• CID #55 – Decline - 802.11ma D9.0, in clause 9.2.9.4 clearly indicates that the NAV is not updated in a STA when the RA of the received frame is equal to that STA’s MAC address. In other words while a STA is receiving frames addressed to it the NAV is not updated and equal to 0. So the noise measurement time calculation in the referenced clause is not double counter Trx. The reference calculation is correct.

• CID #60 – Counter - The commenter is correct in that Access Delay is sensitive to channel load generated by interferes. If an interferer or microwave triggers CCA, the channel is blocked (loaded) by the interference and this will delay normal channel access. This interference delay is part of the measured access delay. An interferer loads the channel, but this is not a service. The word “service will” be removed from the referenced text.

• CID #65 – Counter - On P41L17, indicates that the X is not a part of the Annex D variable name, but must be replaced with 0-7 to obtain the correct Annex D variable names. This is an error. 802.11ma D9.0, P1024L13, in Annex D indicates that these counters are accessed in a columnar array of QoS counter values, indexed by the variable dot11QosCountersIndex. The table has 16 columns representing TIDs 0-15. The draft will be corrected to show that dot11QoSUp2TransmittedFragmentedCount is actually the dot11QoSTransmittedFragmentCount variable located in the third column of the QoS counters Table. Editor to make consistent correction throughout the draft.

• CID #70 – Accept – P51L42, replace “measurement.” with “measurement duration. However, in a Beacon Report or Frame Report, the Antenna ID always identifies the antenna used to receive the reported beacon or frame. If during the frame reception different antenna is used to receive the preamble … more see spreadsheet.

• CID #83 – Decline – It is inappropriate to change the length of the existing IE which is fixed in .11ma or to add additional fields to the existing IE that has the fixed fields in .11ma. It

Submission page 10 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

violates backward compatible requirement. It will cause parsing error for a non-802.11k device (but it is an .11e device) when this device receives QBSS Load from a .11k/11e AP.

Motion To decline CID #83

For: 3 Against: 1 Abstain: 0

Discussion on the Motion

Mover: Kwak Second: Gray

Motion passes

• CID #84 – Decline – New text has been added to P97L3-12 clarifying the purpose and justification for Measurement Pilot.

To decline CID #83

For: 4 Against: 1 Abstain: 0

Discussion on the Motion

Mover: Kwak Second: Gray

Motion passes

• CID #85 – Decline – the term “QoS Metric” is directly related to quality of service facility in 11ma (Clause 3.1.20). QoS Metrics is a specific measurement to quantify the performance of a TS or TC which is a QoS facility that was added by TGe

• CID #86 – Decline – Per recommendation of the 802.11ma editor section 7 shall only contain frame format descriptions. We will move the only normative sentence P8 L40 in the stricken clause to P85 L25 in 802.11ma D9.0.

• CID #101 – Accept

• CID #106 – Accept

• CID #110 – Accept

• CID #126 – Accept – change editing instructions P11 L3 change”6” as follows “below order 4 row”

• CID #127 – Counter – Editor to verify the ANA spreadsheet

• CID #130 – Accept

• CID #134 – Accept

• CID #137 – Accepted

Submission page 11 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

• CID #138 – Accepted

• CID #142 – Accepted-

• CID #154 – Counter – see comment resolution #42 and #46

• CID #156 – Counter – see comment resolution #42 and #46

• CID #163 – Accept

• CID #164 – Accept

• Blanket vote to accept all open Editorial comments (140, 141, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 155, 157, 158, 159, 160, 161, 162, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178)

4. Motion to approve resolved comments Move to accept the resolutions for TGk LB90 comments as written in spreadsheet document 06/1739r12 and instruct the editor to incorporate all such resolutions therein into the next TGk draft..

Moved: Ganesh Second: Kwak

For: 4 Against: 0 Abstain: 1

5. Motion to approve a procedural LB Approve the issuance of a 15 day Procedural Letter Ballot, starting on or after 2006-11-27, asking the question; “Do you believe the TG “k” draft 7.0 is technically complete and ready for LB recirculation?”

Moved: Kwak Second: Ganesh

For: 5 Against: 0 Abstain: 1

6. WG Motion for Recirc Following Proc LB Believing that comment responses in 06/1739r12 and the draft mentioned below satisfy WG 802.11 rules for letter ballot recirculation,

Authorize a 15-day LB recirculation of 802.11k draft 7.0 assuming approval of the current draft by a 15 day procedural LB. Letter Ballot recirculation to conclude on or later than 2006-12-30.

Moved: Kwak Second: Ganesh

For: 4 Against: 0 Abstain: 2

Motion passes

7. Approve Ad-hoc minutes

Submission page 12 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1758r23

Move to accept the Dallas Monday Ad Hoc minutes found in 06/1738r0

Moved: Kwak Second: Ganesh

For: 5 Against: 0 Abstain: 1

Motion passes

8. Ad-hc comment resolutions Move to accept the comment resolutions of the Monday AD Hoc Accepts: 2, 21, 13, 16,3, and 22 Declines: 6 Counters: 2, 5, and 8 and instruct the editor to incorporate in the next draft all such resolutions therein into the next TGk draft. (Ref 06/1739r12)

Moved: Ganesh Second Gray

For: 5 Against: 0 Abstain: 1 Motion passes

9. Richard’s Technical Presentation Move to incorporate the comment resolutions in 06/1806r0 into the next TGk draft.

Moved: Ganesh Second Gray

For: 4 Against: 0 Abstain: 1

Motion passes

10. WG Motion to Conditioally Approve SB Move to request the WG chair to request the 802 Executive Committee to conditionally approve a sponsor ballot per the LMSC Policies and Procedures.

Moved: Kwak Second Ganesh

For: 5 Against: 0 Abstain: 0

Motion passes

11. Meeting Adjourns

Submission page 13 Paul Gray, AirWave

November 2006 doc.: IEEE 802.11-06/1752r0 Report and Minutes of TGm November 2006 DATE: 2006-11-17 Author(s) Name Company Address Phone email

Bob O’Hara Cisco 3625 Cisco Way, San +1 408 853 5513 [email protected] Systems Jose, CA 95134

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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

Report and Minutes Slide 1 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0

Abstract

Report and minutes of the meeting of TGm at the November 2006 session.

Report and Minutes Slide 2 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Goals for November 2006

• Prepare response to interpretation requests received

Report and Minutes Slide 3 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Submissions

• Submissions

Report and Minutes Slide 4 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Proposed Agenda

• Consent agenda: – Approve minutes and report from September 2006 meeting (document 06/1392r0) • Review IEEE Patent Policy • Review interpretation request procedure • Old business

• New business – Prepare response to interpretation requests • Adjourn

Report and Minutes Slide 5 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Motion #1 to adopt Agenda

• Moved: to adopt the agenda • Mover: Darwin Engwer/Dorothy Stanley • Passes: 7/0

Report and Minutes Slide 6 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 IEEE-SA Standards Board Bylaws on Patents in Standards • http://standards.ieee.org/board/pat/pat-slideset.ppt

Report and Minutes Slide 7 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Question to the members

• Chair: Are there any patents or patent applications of which the members are aware, for which the Working group chair needs to be notified?

• Response: No response was made to this question.

Report and Minutes Slide 8 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Interpretation Procedure

• http://standards.ieee.org/reading/ieee/interp/ • Send email to Rona Gertz ([email protected]) • IEEE forwards requests to the WG • WG responds

Report and Minutes Slide 9 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Interpretation Request #1

• The rules of replay protection for TKIP are ambiguous – Clause 6.1.5 describes two contradictory rules for performing replay protection – Clause 8.3.2.1.2a describes a third rule for performing replay protection – Clause 8.3.2.4 describes replay protection consistent with the second rule in 6.1.5 – Clause 8.3.2.6f describes replay protection consistent with the first rule in 6.1.5

Report and Minutes Slide 10 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Interpretation Response #1

• The standard is not ambiguous on this point. There is only a single requirement in the standard, stated in 8.3.2.4, for the detection and discarding of a given MPDU using the TSC and TSC replay counter. However, there is additional descriptive material in the clauses indicated by the requester (6.1.5, 8.3.2.1.2a, and 8.3.2.6f) that leads to confusion on how to implement this requirement. • In 8.3.2.6f and in 6.1.5, the term “replay detection” refers to the larger replay protection mechanism using the TSC replay counter, not just to the comparison of the values of the received TSC and the TSC replay counter. • This issue will be forwarded to the 802.11 Working Group for consideration in a future revision of the standard.

Report and Minutes Slide 11 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Motion #2

• Moved: to accept document 06/1751r0 as the response to the interpretation request #1.

• Moved: Dorothy Stanley/Darwin Engwer • Passes: 5/0

Report and Minutes Slide 12 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Output Documents

• 06/1752r0: This report • 06/1751r0: Interpretation Response #1 (November 2006)

Report and Minutes Slide 13 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Goals for January

• Process any interpretation requests received • Craft PAR for 802.11mb maintenance work

Report and Minutes Slide 14 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Adjourn

• Meeting adjourned at 5:25pm on Monday, November 13, 2006.

Report and Minutes Slide 15 Bob O'Hara, Cisco Systems November 2006 doc.: IEEE 802.11-06/1752r0 Attendees

• Dorothy Stanley • Darwin Engwer • Roger Durand • Allan Thomson • Marc Emmelmann • Marty Lefkowitz • Andrew Myles

Report and Minutes Slide 16 Bob O'Hara, Cisco Systems Nov 2006 doc.: IEEE 802.11-06/1713r0

IEEE P802.11 Wireless LANs

[Minutes of High Throughput Task Group .11n Session]

Date: 2006-11-13

Author(s): Name Company Address Phone email 5204 East Ben White Garth Advanced (512) 602- Garth.hillman Austin TX 78741 Hillman Micro Devices 7869 @amd.com MS: 625

Abstract Cumulative minutes of the High Throughput Task Group meetings held during the IEEE 802.11 Plenary session in Dallas from Nov 13 through 17, 2006. The session was chaired by TGn chair Bruce Kraemer from Marvell.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

Executive Summary (also see Chairs’ meeting doc 11-06-1662r6 and closing report doc. 11- 06-1811r1): 1. The meeting was devoted to LB84 comment resolution. Out of a total of 22 hours 12 were devoted to ad hoc meetings and 10 hours were devoted to full body voting meetings. 2. Coming into the meeting ~1863 unique technical comments out of 3077 had been resolved leaving 1214 to be resolved. 37 motions were passed directly related to the draft text and resolution of ~ 859 comments. This means ~88.5% of the unique technical comments have now been resolved. 3. Confidence is high that the remaining ~350 comments can be resolved at the January Interim session. The goal is to go to Letter Ballot after the January meeting and resolve comments from that Letter Ballot at the March session. 4. There will be an ad hoc meeting Wednesday Jan 10 thru Friday Jan 12 in London prior to the January Interim session 5. There will be four ad hoc teleconference meetings on the following Wednesdays from 11:00 to 13:00 ET – Dec 6, 13, 20 and Jan 3 6. Joint meetings were held with .11k to synchronize amendments in process. Synchronizing text changes will be proposed by both groups at the January session. 7. Similar synchronization meetings were proposed with .11r for the January session 8. The most contentious issue was standardizing 40 MHz channel usage in the 2.4 GHz band. Two proposals were voted on and both failed to attain the 75% super- majority. 9. The Time Line was considered and the consensus was to leave it unchanged - .11n will be published in April 2008.

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/interpretive on my part and therefore open to question. When recording Q&A an ‘A’ is used in the minutes to denote “answer” Note 2: Only motions resolving CIDs are specially numbered. This is done so that there is a cross reference between specific resolutions and official votes. ******************************************************************************

Detailed cumulative minutes follow:

Monday; Nov 12, 2006; 4:00 PM – 6:00 PM [~ 98 attendees; 3 new]

1. Meeting was called to order by TGn chair at 4:03 PM 2. Chairs’ Meeting Doc 11-06-1662r0 3. Chair read IEEE-SA Standards Board Bylaws on Patents in Standards and additional Pat Com Guidance; chair noted Feb 2006 version 4. Chair reviewed topics NOT to be discussed during the meeting including – licensing, pricing, litigation, market share, etc. 5. Attendance reminder – Electronic using http://newton

Submission page 2 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

6. Chair reviewed history and timelines (slide 8) including goals and progress from inception for new members 6.1. Created Draft 1.05 out of September meeting and updated to Draft 1.06 (now 388p) 6.2. Approved 568 technical resolutions in September 7. Chair reviewed the timeline 8. Chair listed ad hocs completed and future ad hocs 9. Ad hoc committees and leaders were presented (slide 11) – divide and conquer! 10. Ad hoc spread sheet (slide 12) status was presented 11. Chair reviewed 802.11 Draft Revision Procedure 12. Chair reviewed draft revision history (slide 14) 13. CR summary on Slides 15/16/17 – 3077 total = 1863 approved + 624 pending + 590 to be addressed 14. Exec Summary from Sept minutes, 11-05-1408r1, presented 15. Motion by Jon Rosdahl to approve September minutes, 11-06-1408r1 was seconded by Venko Erceg and approved unanimously 16. Agenda discussion 16.1. Any new presentation requests? 16.1.1. Eldad requested a change in scheduling – move his paper to 2nd half of PM1 due to a conflict with Coexistence Assurance [1744r0 – Phy status per Jim Petranovich] 16.1.2. Joint ad hoc meeting with TGk (PHY issues (RCPI) and General topics) in PM1 on Tuesday. TGk experts will be shuttled between the Phy and Gen meeting rooms

Tue Wed Thu

Beam Coex PHY FF MAC Beam Coex PHY FF MAC Beam Coex PHY FF MAC am1 am2 pm1 Group Topics + Votes pm2 Group Topics + Votes Group Topics + Votes Group Topics + Votes

17. Motion to approve November ’06 TGn agenda as contained in slides 23-29 was made by Don Schultz and seconded by Marc de Courville passed unanimously (with minuted amendments) 18. Need an Ad Hoc in London but expensive; Jon recommended to check in to Paddington on Wed, Thursday, Friday and then change to Metropole; what to do with Saturday? 19. Committee Reports 19.1. Adrian Stephens presented technical report in (11-06-1668r1) 19.2. All related documents are stated on slide 4 19.3. PLEASE use Draft 1.06 (i.e., latest draft) 19.4. Approved comments in 11-06-0541 19.5. 800 CRs required 4 weeks of processing time total – 2 to implement and 2 weeks to review 19.6. 82% resolved; 60% approved 19.7. How to get to LB by end of Jan meeting?

Submission page 3 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

19.7.1. Adrian described 4 scenarios on slide 14 19.7.2. Scenario #3 could get us to a completed LB by the March 2007 session 19.7.3. Assumes 30 day LBs 19.8. Naveen Kakani Chair of PSMP ad hoc (11-06-1735r0) 19.8.1. 40 comments for voting tomorrow 19.8.2. no remaining 19.9. CA – Sheung Li (no doc) will present the revised doc to .19 tomorrow morning 19.10. Peter Loc Chair of Frame 19.10.1. 107 comments left 19.10.1.1. 37 comments remain to be addressed 19.10.1.2. 36 deferred until presentations 19.10.1.3. 5 ER 19.10.1.4. 2 ERM 19.10.1.5. 8 transferred to BF 19.11. If agenda needs to be changed a 2/3 vote is required 19.12. Jim Petranovich chair of Phy (11-06-1744r0) 19.12.1. 389 remain 19.12.2. 234 resolved 19.12.3. 155 remain (15 unassigned) 19.12.4. Need to resolve PLCP procedure 19.12.5. Goal resolve all comments by the end of the London ad hoc 19.13. Matt Fischer chair of MAC ad hoc (no doc) 19.14. Don Schultz/Eldad Perahia co-chairs of Coexistence (no number) 19.14.1. 384 in September 19.14.2. 150 resolved 19.14.3. 184 remain and deferred 19.14.4. Note: Straw Poll in ad hoc asking Forbid 40 MHz in 2.4 GHz was passed by a super majority 19.15. John Ketchum Chair of BF and Link Adaptation (no doc) 19.15.1. 154 out of Melbourne 19.15.2. 59 resolved in Oct ad hoc 19.15.3. 66 resolved in Dallas ad hoc 19.15.4. leaving 29 to be resolved 19.15.5. Calibration is biggest remaining issue 19.15.6. 3 motions to be presented this week 19.16. Jon Rosdahl chair of General (11-06-0688r43) 19.16.1. 8 resolution ready for this session 19.16.2. 1 motion 19.17. Adrian will not hold an editorial ad hoc at this meeting 20. Tim Godfrey volunteered to be interim secretary for the Tuesday and Wednesday formal sessions. Garth will return for the Thursday session 21. #74 Motion by Jon Rosdahl and seconded by TK Tan:

Whereas the TGn Ad Hoc group has been assigned 17 new comments to propose resolutions for since the Sept. 2006 session, Move to accept the resolutions proposed for the 7 CIDs as listed below and documented in "11-06-0688-41-000n-tgn-general-comment- adhoc-group" (also in r42,43&44)

64 - C; 769 - R; 770 - R; 3615 - C; 793 – C; 4823 – A; 10347 – R

Submission page 4 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

Passed unanimously

22. Straw Poll “Could you support forbidding 40 MHz in 2.4 GHz?” 23. Need more background 23.1. Coexistence group agreed to requesting this straw poll 23.2. Actually there were 3 straw polls at this mornings meeting one of which was to forbid 40 MHz in 2.4 GHz. If this is the will of the body then the other 2 straw polls would not be needed 24. New Straw poll text – Would you prefer forbidding 40 MHz in 2.4 GHz or counting to work on a compromise solution? Vote for one of the following 24.1. Forbid 40 MHz (70) 24.2. Continue working (29) 24.3. Abstain (6) 25. No further business 26. Chair recessed the meeting at 5:56PM until 4:00 PM on Tuesday

Tuesday November 14, 4:00 – 6:00 PM

1. Meeting was called to order by TGn chair Bruce Kraemer at 4:00PM 2. Substitute Secretary is Tim Godfrey 3. Chairs’ Meeting Doc 11-06-1662r0 4. Bruce reviews the agenda for the ad hoc sessions. 4.1. A r1 version of 1662 will be used for any updates (if needed) 4.2. Discussion from the floor 4.2.1. What was the attendance for Frame? Peter Loc states there were 27 in attendance. 4.2.2. A member states there needs to be a different alignment of sessions so members will attend frame. Suggests MAC is replaced with Frame on Wednesday AM. 4.2.3. Matt Fischer states that MAC is getting many transfers of comments. How many outstanding comments are in frame? Frame has about 30 comments, and 19 deferred. Ali Raissinia resolved every comment that was assigned to Srini Kandala. 4.2.4. Bruce asks if we can add another Frame ad-hoc slot. 4.2.5. Jon Rosdahl states that while this divide and conquer system is not ideal, it is needed to get the work done. Suggests that we return to orders of the day unless there is a motion to modify the agenda. 4.3. Jim Petranovich moved to swap the PHY and Coex meeting times on Thursday was seconded by Sanjiv Nanda? 4.3.1. Discussion on the motion to amend 4.3.1.1.If there is compromise on Thursday, how many MAC people want to participate in the Coex session? There are MAC sessions both AM1 and AM2 – it makes no difference. 4.3.1.2. Jon Rosdahl points out that General is down for Thursday AM. If Coex moves there, it would impact General. Suggests that General be moved to AM2 4.3.2. Vote: 20 Y 7 N 25 A. Passes with > 2/3 approval 4.4. Bruce adjusts the agenda 4.5. Jon Rosdahl motion to change the agenda, changing the General session Thursday from AM1 to AM2 was seconded by Naveen Kakani and approved unanimously without objection

Submission page 5 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

4.6. Bruce reminds the membership that the joint work with TGk will continue at 9:00AM to 10:00AM at the General ad-hoc. 4.7. Discussion from the floor 4.7.1. Peter Loc requests swapping Wednesday slots for PHY and Coex. There are many members of Frame that attend Coex. Would prefer they attend Frame Ad Hoc. Withdraws request after brief sidebar. 4.7.2. There is still a problem that there is too low of attendance in Frame sessions. 4.8. Bruce requests that other ad-hoc group chairs should remind their members that there is a concurrent Frame session so members don’t forget. 4.9. Bruce Requests Jon Rosdahl report on the TGr session 4.9.1. Jon states that TGr requested a tutorial on the TGn MAC. This would be done during the January WG Wednesday session. They are particularly interested in protocol negotiation times and changes as STAs move from one AP mode to another. They are concerned with the cipher suites, and the issues with mixed encryption and aggregation. They are concerned with the null data frame. They need to understand any new frame types being proposed in TGn. They ask for TGn to specify impact on QoS and Security settings. 4.10. Bruce requests that Jon distribute his notes to TGn via email. We will coordinate with Matt Fischer and try to execute on those requests before January. 4.11. Bruce states that the new agenda in 1662r1 will be posted to the server. 5. General Discussions and motions on topics from the Ad-Hocs. 5.1. Bruce requests counts of motions 5.1.1. PSMP: Naveen Kakani – 1 motion, 5 minutes 5.1.2. Frame: Peter Loc – none 5.1.3. PHY: Jim Petranovich – 4 motions, 60 minutes 5.1.4. MAC: Matt Fischer – not present 5.1.5. COEX: Don Schultz– none 5.1.6. Beam: John Ketchum – 1 motion, 10 minutes 5.1.7. General Jon Rosdahl – none 5.1.8. Editorial: Adrian – none 5.2. These motions will fit in the time for today. 6. Motions from PSMP Ad Hoc 6.1. Motion #75: Move to approve the comment resolutions shown in the “PSMP” Tab of document 11-06-0687/r38 6.1.1. Moved Naveen Kakani 6.1.2. Second Adrian Stephens 6.1.3. Vote: the motion is approved unanimously with no objection 6.1.4. Bruce recognizes that the PSMP Ad Hoc has completed its work. 7. Motions from PHY Ad Hoc 7.1. Motion #76: Move to approve resolution of comments found on the tab labelled “pending motion set 9” in document 11-06-0693r69. 7.1.1. Moved Jim Petranovich 7.1.2. Second Don Schultz 7.1.3. There is no discussion or questions 7.1.4. Vote: the motion is approved unanimously with no objection 7.2. Motion #77: Move to approve resolution of comments found on the tab labelled “pending motion set 10” in document 11-06-0693r69. 7.2.1. Moved Jim Petranovich 7.2.2. Second Don Schultz

Submission page 6 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

7.2.3. There is no discussion or questions 7.2.4. Vote: the motion is approved unanimously with no objection 7.3. Motion #78: Move to approve resolution of comments found on the tab labelled “pending motion set 11” in document 11-06-0693r69. 7.3.1. Moved Jim Petranovich 7.3.2. Second Don Schultz 7.3.3. There is no discussion or questions 7.3.4. Vote: the motion is approved unanimously with no objection 7.4. Motion #79: Move to approve resolution of comments found on the tab labelled “pending motion set 12” in document 11-06-0693r69. 7.4.1. Moved Jim Petranovich 7.4.2. Second Andy Molesch 7.4.3. Discussion 7.4.3.1.Allert Van Zelst states that CID 131 is related to the description in document 1571. Would like to postpone this motion 7.4.3.2.Jim Petranovich displays the resolution matrix. 7.4.3.3.Allert withdraws his request. 7.4.4. Vote: the motion is approved unanimously with no objection 8. Motions for Beam Ad Hoc 8.1. Motion #80: Motion to approve resolution of comments found on the tab labelled “Pending Motion 1” in document 11-06-0675r46; based on resolutions agreed at Portland ad hocs. 8.1.1. Moved John Ketchum 8.1.2. Second Joonsuk Kim 8.1.3. There is no discussion 8.1.4. Vote: the motion is approved unanimously with no objection 9. Bruce asks if there are any other topics that the Ad Hoc chairs wish to bring forward. There are none 10. Bruce asks if there any other business? Adrian Stephens brings the editorial motions and presents document 06-1668r1 10.1. Motion #81: Whereas the editor found it necessary to make minor modifications in the incorporation of TGn comment resolutions approved in September, identified with an “Edit Status” of “EM”, and whereas 11-06/0706r21 has 95 “EM” Comments on the “Edited in D1_05” tab: CIDs: 12, 150, 356, 357, 381, 402, 414, 507, 551, 630, 636, 659, 681, 701, 876, 891, 1001, 1002, 1005, 1015, 1016, 1028, 1048, 1083, 1152, 1156, 1162, 1164, 1166, 1250, 1302, 1349, 1350, 1351, 1353, 1354, 1359, 1363, 1366, 1374, 1376, 1390, 1400, 1406, 1410, 1444, 1467, 1490, 1526, 2371, 2750, 2767, 2772, 2773, 2774, 3374, 3495, 3590, 3700, 3808, 3848, 3858, 3862, 3864, 3865, 3901, 3906, 3992, 4238, 4692, 4773, 6906, 6919, 6923, 7070, 7265, 7504, 7613, 7629, 7631, 7634, 7722, 7723, 7902, 7910, 8221, 10031, 10032, 11923, 11945, 11947, 11949, 12133, 12169, 7049 Move to accept the resolution of the comments as amended by the “Edit Notes” column where the comment has an “Edit Status” of “EM” (Edited with modifications) in document 11-06/0706r21 on the “Edited in D1_05” tab 10.1.1. Moved Adrian Stephens 10.1.2. Second Assaf Kasher 10.1.3. There is no discussion on the motion

Submission page 7 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

10.1.4. Vote: the motion is approved unanimously with no objection 10.2. Motion #82: Whereas P802.11n D1.06 contains the implementation of comment resolutions approved by TGn in September 2006; Approve P802.11n D1.06 as the TGn Draft 10.2.1. Moved Adrian Stephens 10.2.2. Second Don Schultz. 10.2.3. There is no discussion 10.2.4. Vote: the motion is approved unanimously with no objection 11. Bruce asks if any ad hoc chair or any member have anything to bring forward 11.1. Don Schultz suggests that we try to develop the agenda in advance so people can plan where they want to be. Don will release a more detailed Coex agenda. 11.2. Jim Petranovich is concerned that if the agenda is too detailed, we could get in trouble if we need to deviate. Bruce indicates the agenda can be a general sequence without fixed time. Don agrees it is not guaranteed timing. 11.3. Joe Kwak says that the agenda allows people to hop between sessions and choose what they are interested in. 11.4. Peter Loc suggests we should have a Frame meeting in the extra hour today from 5pm to 6pm. 11.5. Jim Petranovich says the PHY group has already set agenda. Doesn’t see any problem with a Frame meeting now. 11.6. Peter proposes we do the Frame ad-hoc meeting now. 11.7. Bruce asks if there is any objection to recess the Full TGn session and convert to a frame format ad-hoc meeting. 11.8. There is no objection 12. The TGn meeting is recessed at 5:03pm

Wednesday; Nov 15, 2006; 4:00 PM – 6:00 PM

1. Meeting was called to order by TGn chair Bruce Kramer at 4:00PM 2. Substitute Secretary is Tim Godfrey 3. Chairs’ Meeting Doc 11-06-1662r2 on the server 4. Agenda review 4.1. There are two ad-hoc slots tomorrow. AM1 and AM2. 4.2. The groups and locations are on slide 49 of doc 1662r2. 4.3. Bruce asks for any updates or amendments to the plan. There are none. 4.4. Bruce reminds the members that PM1 and PM2 are full TGn meetings. We will complete any ballots and timeline updates in the full meetings. 4.5. The agenda will be posted on the server and around the meeting rooms. 4.6. PSMP and Coexistence Assurance Ad Hocs have completed their work. 4.7. The Frame group does not have anything. PHY has 5 motions. MAC has 4 tabs, Coex has 6 tabs, Beam 2 tabs, General status only, Editorial one motion. 5. Sheung Li presents a status update on CA. 5.1. Eldad presented doc 11-06-0338r4, the CA document. It analyzed coexistence of 802.11n with all known wireless standards. It was reviewed and accepted by 802.19. There is nothing that needs to be changed before the next TGn letter ballot. 6. Timing of presentations 6.1. Coex cannot present until 5:40PM due to 4 hour rule 6.2. PHY will go second to last. 6.3. General will go first

Submission page 8 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

7. General Ad Hoc Motions 7.1. Jon Rosdahl states that General met this morning and will meet again tomorrow. Working on doc 11-06-1681. R1 is on the server, showing the relations between 11k and 11n, and identifies issues. 7.2. Bruce asks if we will be prepared to vote on 1681 tomorrow. Jon Rosdahl states that some things will take more time. If we have resolutions brought tomorrow they would have to be at the end. 8. MAC Ad Hoc Motions 8.1. Matt Fischer presents document 11-06-1807r1, which is a sub-group report 8.2. Adopted doc 11-06-1557r4 8.2.1. General topic of rate selection rules for response frames + others 8.2.2. Addresses 20 CIDs (some of those are recycled) 8.3. Adopted doc 11-06-1345r10 8.3.1. General topic of HT Block Ack rules 8.3.2. Addresses 47 Technical CIDs (some of those are recycled) 8.3.3. Addresses 17 Editorial CIDs (all are recycled) 8.4. Resolved 62 CIDs individually 8.5. Spreadsheet is 11-06-0690r48 8.6. Motion #83: Move to accept comment resolutions in 11-06/0690r48 tab "motion_061114” 8.6.1. Bruce asks if there is any content that would violate the 4 hour rule. Matt states that everything was uploaded last night. 8.6.2. Moved Matt Fischer 8.6.3. Second Adrian Stephens 8.6.4. Vote: the motion is approved unanimously with no objection 8.7. Motion #84: Move to accept comment resolutions in 11-06/0690r48 tab "motion_1710” from row 2 through row 21 inclusive 8.7.1. Matt notes that there was a spreadsheet problem and extra CIDs were included beyond row 22. They should be ignored, and are not part of the motion. 8.7.2. Moved Matt Fischer 8.7.3. Second Mark de Courville 8.7.4. Discussion 8.7.4.1.CID 6783 should be taken out to be dealt with tomorrow. 8.7.4.2.Another member notes that 6783 is not a part of the motion anyway, so there is no need for any change. 8.7.5. Vote: the motion is approved unanimously with no objection 8.8. Motion #85: Move to accept comment resolutions in 11-06/0690r48 tab "motion_1649” 8.8.1. Matt notes that this contains both technical and editorial 8.8.2. Moved Matt Fischer 8.8.3. Second Solomon Trainin 8.8.4. Discussion 8.8.4.1.There are CIDs on partial and full state block Ack. Members want to revisit this. Please take out 3826, 3828 and 7306. 8.8.5. Motion to amend – append the phrase “excluding CIDs 3826, 3828 and 7306” 8.8.5.1.Moved Matt Fischer, Second Naveen Kakani 8.8.5.2.Amendment accepted without objection 8.9. Motion #85 (as amended): Move to accept comment resolutions in 11-06/0690r48 tab "motion_1649” excluding CIDs 3826, 3828 and 7306

Submission page 9 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

8.9.1. Vote: the motion is approved unanimously with no objection 9. Editorial Ad Hoc Motions 9.1. Motion #86: Accept the resolution to comments contained in 11-06/0706r22 on the “Editorials” tab. 9.1.1. Moved Adrian Stephens 9.1.2. Second Naveen Kakani 9.1.3. No discussion 9.1.4. Vote: the motion is approved unanimously with no objection 10. Beam Ad Hoc Motions 10.1. Motion #87: Approve resolution of comments found on the tab labelled “Pending motion 2” in document 11-06/0675r46. 10.1.1. Moved John Ketchum 10.1.2. Second Joonsuk Kim 10.1.3. No discussion 10.1.4. Vote: the motion is approved unanimously with no objection 10.2. Motion #88: Approve resolution of comments found on the tab labelled “Pending motion 3” in document 11-06/0675r46. 10.2.1. Moved John Ketchum 10.2.2. Second Vincenzo Scarpa 10.2.3. Discussion 10.2.3.1. Massimiliano Siti states the description of the reason for rejection is not a true resolution of the comment. 10.2.3.2. Bruce asks if there is an amendment. Can we know which CID to remove? We assume the group was comfortable with this group since they are brought forward for approval. 10.2.3.3. Massimiliano Siti withdraws his objection. 10.2.4. Vote: the motion is approved unanimously 11. PHY Motions 11.1.1. Jim Petranovich explains that the texts of motions are in the resolution document, but the motions are not on the server. 11.1.2. Bruce verifies that as long as the resolutions are there, we are OK. 11.1.3. Bruce adds that the motions can be developed real time however the resolutions the motion refers to must have been on the server for 4 hours since they pertain to text going into the draft 11.2. Motion #89: Approve resolution of comments found on the tab labelled “pending motion set 8” in document 11-06/0693r72. 11.2.1. Moved Jim Petranovich 11.2.2. Second Bjorn Bjerke 11.2.3. Vote: the motion is approved unanimously with no objection 11.3. Motion #90: Approve resolution of comments found on the tab labelled “pending motion set 13” in document 11-06/0693r72 except for the resolution proposed in CID 3944. 11.3.1. Moved Jim Petranovich 11.3.2. Discussion 11.3.2.1. There are concerns about CID 3944. These concerns would be corrected by document 1780r2. This should be deferred until tomorrow. Just remove CID 3944 from the tab. 11.3.2.2. Document 1780r2 needs to change to 1780r3. We need to change references in the documents.

Submission page 10 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

11.3.2.3. We could either delay the whole motion until tomorrow, or remove this CID. 11.3.2.4. Only this one CID would be affected by the r3 version, so there is no problem with editing in two phases. 11.3.2.5. Jim P would like to get it partially done for the editor. 11.3.3. Second Don Schultz 11.3.4. Vote: the motion is approved unanimously with no objection 11.3.5. Jim Petranovich will upload this with the tab updated, and CID 3944 moved to an individual motion. 11.4. Motion #91: Approve resolution of comments found on the tab labelled “pending motion set 14 (S)” in document 11-06/0693r72. 11.4.1. Moved Jim Petranovich 11.4.2. Seconded Bjorn Bjerke 11.4.3. No discussion 11.4.4. Vote: the motion is approved unanimously with no objection 11.5. Motion #92: Approve resolution of comments found on the tab labelled “pending motion set 15 (M)” in document 11-06/0693r72. 11.5.1. Moved Jim Petranovich 11.5.2. Discussion 11.5.2.1. Jim notes that this was passed in the PHY group with a majority but under 75%. 11.5.3. Second Vinko Erceg 11.5.4. Vote: the motion is approved unanimously with no objection 11.6. Motion #93: Approve resolution of the comment with CID 1564 as found on the tab labelled “pending individual motions” in document 11-06/0693r72. 11.6.1. Moved Jim Petranovich 11.6.2. Second Don Schultz 11.6.3. Discussion 11.6.3.1. Eldad Perahia states that this CID calls for a tighter spectral mask in 40MHz and a dBm/MHz lower floor in the spectral mask. A device that meets the current 40MHz spectral mask would have to back off an extra 1.2dB. There are complex techniques in the draft to gain 1dB, and we are throwing it away here. Would prefer to keep the 1.2dB of range in this. Speaks against the motion. 11.6.4. Vote: motion fails 21 Y : 40 N : 24 A 12. Coexistence Motions 12.1.1. Bruce asks the members if it is acceptable to make these motions with the CIDs in this form. This is just a representation of the contents of the spreadsheet. 12.1.2. VK Jones is looking at motion tab 4. 12.1.3. Don says there are several motion tabs in Rev 41 12.2. Motion #94: Approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 2 and Motion Tab Comments of document 06/0724r41 which resolves the 31 comments listed below:

Submission page 11 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

CIDs Approved Unanimously D1.0 Clause Title D1.06 1556 11.16 156 3 Phased Coexistence Operation 11.17 4277 11.16 156 3 Phased Coexistence Operation 11.17 7774 11.16 156 5-7 Phased Coexistence Operation 11.17 7775 11.16 156 Phased Coexistence Operation 11.17 5 11.16 156-158 Phased Coexistence Operation 11.17 7490 11.16 Phased Coexistence Operation 11.17 7491 11.16 Phased Coexistence Operation 11.17 4650 11.16.1 157 6 Phased Coexistence Operation 11.17 7779 11.16.1 157 10-12 Phased Coexistence Operation 11.17 7197 11.16.1 157 10-12 Phased Coexistence Operation 11.17 7780 11.16.1 157 42-44 Phased Coexistence Operation 11.17 4530 11.16.1 157 Phased Coexistence Operation 11.17 7778 11.16.1 157 Phased Coexistence Operation 11.17 7492 11.16.1 Phased Coexistence Operation 11.17 7875 11.16.2 158 6 Phased Coexistence Operation 11.17 7876 11.16.2 158 11 Phased Coexistence Operation 11.17 7877 11.16.2 158 15 Phased Coexistence Operation 11.17 10 11.16.2 158 8-10 Phased Coexistence Operation 11.17 7765 11.16.2 158 8-10 Phased Coexistence Operation 11.17 7907 11.16.2 158 8-10 Phased Coexistence Operation 11.17 11 11.16.2 158 11-13 Phased Coexistence Operation 11.17 7908 11.16.2 158 11-13 Phased Coexistence Operation 11.17 4633 11.16.2 158 11-13 Phased Coexistence Operation 11.17 7766 11.16.2 158 11-13 Phased Coexistence Operation 11.17 7782 11.16.2 158 15-18 Phased Coexistence Operation 11.17 7781 11.16.2 158 24-26 Phased Coexistence Operation 11.17 1060 11.16.1 157 4 Rules for Operation at PCO AP 11.17.1 7783 11.16.1 157 6 Rules for Operation at PCO AP 11.17.1 4532 11.16.1 157 6 Rules for Operation at PCO AP 11.17.1 11377 7.4.7.3 59 8 PCO Phase Request Management Action Fr 7.4.8.6 1232 7.4.7.3 PCO Phase Request Management Action Fr 7.4.8.6

12.2.1. Moved Don Schultz 12.2.2. Second Eldad Perahia 12.2.3. Discussion 12.2.3.1. Why are we not doing motion group 1 first? A - It will be done tomorrow. 12.2.4. Vote: the motion is approved unanimously with no objection 12.3. Motion #95: Approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 3 and Motion Tab Comments of document 06/0724r41 which resolves the 21 comments listed below.

CIDs Approved Unanimously D1.0 Clause Title D1.06 3100 20.3.7 221 22 Regulatory Requirements (HT PLCP) 21.4.13 7116 20.3.8 221 31 Channel Numbering and Channelization (HT PLCP) 21.4.14 3104 20.3.8 221 31 Channel Numbering and Channelization (HT PLCP) 21.4.14 7170 20.3.8 221 32 Channel Numbering and Channelization (HT PLCP) 21.4.14 400 20.3.8 221 32 Channel Numbering and Channelization (HT PLCP) 21.4.14 456 20.3.8 221 32 Channel Numbering and Channelization (HT PLCP) 21.4.14 8051 20.3.8 221 32 Channel Numbering and Channelization (HT PLCP) 21.4.14 12036 20.3.8 221 32 Channel Numbering and Channelization (HT PLCP) 21.4.14 12054 20.3.8 221 32 Channel Numbering and Channelization (HT PLCP) 21.4.14 3101 20.3.8 221 33 Channel Numbering and Channelization (HT PLCP) 21.4.14 10381 20.3.8 221 33 Channel Numbering and Channelization (HT PLCP) 21.4.14 10895 20.3.8 221 33 Channel Numbering and Channelization (HT PLCP) 21.4.14 7542 20.3.8 Channel Numbering and Channelization (HT PLCP) 21.4.14 7543 20.3.8 Channel Numbering and Channelization (HT PLCP) 21.4.14 1754 20.3.8 Channel Numbering and Channelization (HT PLCP) 21.4.14 10383 20.3.8.1 222 4 Channel Allocation in the 5 GHz Band (HT PLCP) 21.4.14.2 10382 20.3.8.1 222 8 Channel Allocation in the 5 GHz Band (HT PLCP) 21.4.14.2 1545 20.3.8.1 222 12 Channel Allocation in the 5 GHz Band (HT PLCP) 21.4.14.2 8052 20.3.8.1 222 7-12 Channel Allocation in the 5 GHz Band (HT PLCP) 21.4.14.2 10384 20.3.8.2 222 16 Channel Allocation in the 2.4 GHz Band (PLCP) 21.4.14.1 1546 20.3.8.2 223 9 Channel Allocation in the 2.4 GHz Band (PLCP) 21.4.14.1

12.3.1. Moved Don Schultz 12.3.2. Second Eldad Perahia 12.3.3. Vote: the motion is approved unanimously with no objection 12.4. Motion #96: Approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 4 and Motion Tab Comments of document 06/0724r41 which resolves the 11 comments listed below.

Submission page 12 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

CIDs Approved Unanimously D1.0 Clause Title D1.06 4341 9.14 105 2 Protection mechanisms for different HT PHY options 9.13 3837 9.15 26 L-SIG TXOP Protection 9.13.4 870 9.15 105 L-SIG TXOP Protection 9.13.4 869 9.15 105 L-SIG TXOP Protection 9.13.4 3843 9.15 106 5 L-SIG TXOP Protection 9.13.4 7365 9.15 106 5-11 L-SIG TXOP Protection 9.13.4 8277 9.15 106 11-12 L-SIG TXOP Protection 9.13.4 6784 9.15.1 106 15 L-SIG TXOP Protection Rules at the Initiator 9.13.4.2 11999 9.15.3 106 34 L-SIG TXOP Protection Rules at Third Party HT 9.13.4.2 8278 9.15.3 106 35 L-SIG TXOP Protection Rules at Third Party HT 9.13.4.2 7374 Generally (9.16.1) Protection mechanisms for Aggregation Exchange Sequences 9.14.2

12.4.1. Moved Don Schultz 12.4.2. Second Eldad Perahia 12.4.3. Vote: the motion is approved unanimously with no objection 12.5. Motion #97: Approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 5 and Motion Tab Comments of document 06/0724r41 which resolves the 11 comments listed below:

CIDs Approved Unanimously D1.0 Clause Title D1.06 7348 A4.15.2 271 15 PHY Enhancements for Higher Throughput A.4.17.2 10229 A4.15.2 271 15 PHY Enhancements for Higher Throughput A.4.17.2 570 3 2 15 Definitions 3 1077 3 2 16 Definitions 3 7236 7.3.2.47.5 46 Table n18 Extended HT Capabilities Info field 7.3.2.46.8 3874 9.2.5.4.1 84 21 Dual CTS Protection 9.2.5.5a 3873 9.2.5.4.1 Dual CTS Protection 9.2.5.5a 7659 9.2.5.4.1 Dual CTS Protection 9.2.5.5a 7900 9.23.7 131 1 CF-End in duplicated mode 9.21.7 3890 9.23.7 131 1 CF-End in duplicated mode 9.21.7 53 9.23.7 131 1-2 CF-End in duplicated mode 9.21.7

12.5.1. Moved Don Schultz 12.5.2. Second Eldad Perahia 12.5.3. Vote: the motion is approved unanimously with no objection 12.6. Motion #98: Approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 6 and Motion Tab Comments of document 06/0724r41 which resolves the 9 comments listed below.

CIDs Approved Unanimously D1.0 Clause Title D1.06 713 20.3.14.6 226 8 Reduced Interframe Space (RIFS) 21.4.20.6 4432 20.3.14.6 226 8 Reduced Interframe Space (RIFS) 21.4.20.6 7905 20.3.14.6 226 8 Reduced Interframe Space (RIFS) 21.4.20.6 10036 20.3.14.6 226 8 Reduced Interframe Space (RIFS) 21.4.20.6 10295 20.3.14.6 226 8 Reduced Interframe Space (RIFS) 21.4.20.6 8044 20.3.14.6 226 8-10 Reduced Interframe Space (RIFS) 21.4.20.6 3449 20.3.14.6 226 Reduced Interframe Space (RIFS) 21.4.20.6 10037 20.3.14.6 Reduced Interframe Space (RIFS) 21.4.20.6 7521 20.3.14.6 Reduced Interframe Space (RIFS) 21.4.20.6

12.6.1. Moved Don Schultz 12.6.2. Second Eldad Perahia 12.6.3. Vote: the motion is approved unanimously with no objection 12.7. Motion #99: Approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 7 and Motion Tab Comments of document 06/0724r41 which resolves the 3 comments listed below. Submission page 13 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

CIDs Approved by Majority D1.0 Clause Title D1.06 1516 9.23.1 129 23 Rules for operation in 40/20Mhz BSS 9.21.1 3605 11.16 Phased Coexistence Operation 11.17 10315 Annex A 267 HTM7 PICS Page 267

12.7.1. Moved Don Schultz 12.7.2. Second Eldad Perahia 12.7.3. Vote: the motion is approved unanimously with no objection 13. Review of the agenda for tomorrow 13.1. Bruce states that the ad-hoc agenda will be posted on the server and meeting room doors. 13.2. We have voted on all CIDs prepared by the ad-hoc groups 13.3. We have completed all the work for today. 13.4. Bruce states that there is a document on the server 11-06-1681r1, which contains a commentary on what is needed to change in the TGn draft to accommodate TGk. Members should review this document and be prepared to consider text tomorrow. 13.5. Jon Rosdahl requests that feedback is sent directly to Joe Kwak, or join the General ad-hoc in AM2 in Revershon B. 13.6. Jim Petranovich states that the PHY ad-hoc hopes to finish the PLCP procedure, which may be the last big issue. It will happen in the 2nd hour. Interested members are invited to join. It is document 11-06-1571r6. 13.7. Bruce notes that the Beam ad-hoc has finished the work, and will have a motion tomorrow. They will be done tomorrow. Frame is also very close to completion. 14. Adrian Stephens presents a status update from the comments database 14.1. We are at 84% resolved but this doesn’t include those just approved. 14.2. There are 343 comments still TBD 14.3. Don Schultz confirms that they are accurate as of before this session (2 hours ago) 15. Motion to recess by Jon Rosdahl and seconded by Jim Petranovich passed without objection 15.1. The meeting is recessed at 5:23pm

Thursday November 16, 1:30 – 6:00 PM

1. Chair called the TGn Full meeting to order at 1:33PM 2. Chair reviewed agenda for the afternoon 3. Formal votes will be: PM2 for Phy, MAC; Coexistence (1 in PM1 and PM2); BF&LA, Frame and Gen in PM1, Editorial – no motions, due to 4 hour rule 4. Peter Loc: Frame motions in presentation (11-06-1774r1) 4.1. #100 Motion by Peter Loc and seconded by Doug Chen to approve resolutions of comments found on the tab labelled “Pending Motion 4(A)” in document 11- 06/0717r45 excluding CIDs - 660, 1235, 1236 passed unanimously

4.2. #101 Motion by Peter Loc and seconded by John Ketchum to approve resolutions of comments found on the tab labelled “Pending Motion 5(C)” in document 11- 06/0717r45 passed unanimously

4.3. #102Motion by Peter Loc and seconded by Adrian Stephens to approve resolutions of comments found on the tab labelled “Pending Motion 6(R)” in document 11- 06/0717r45 passed unanimously

Submission page 14 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

5. #103 Motion (11-06-1886r00 by Don Schultz and seconded by Eldad Perahia to approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 1 and Motion Tab Comments of document 06/0724r43 which resolves the 29 comments listed below passed unanimously.

CIDs Approved Unanimously D1.0 Clause Title D1.06 7770 11.15 153 3 40/20 MHz Operation 11.16 7772 11.15 154 3 40/20 MHz Operation 11.16 1049 11.15.1 151 22 Basic functionality in BSS 40/20Mhz mode 11.16 1050 11.15.1 151 24 Basic functionality in BSS 40/20Mhz mode 11.16 1051 11.15.1 151 25 Basic functionality in BSS 40/20Mhz mode 11.16 9887 11.15.1 151 25 Basic functionality in BSS 40/20Mhz mode 11.16 6866 11.15.1 152 5 Basic functionality in BSS 40/20Mhz mode 11.16 6867 11.15.1 152 13 Basic functionality in BSS 40/20Mhz mode 11.16 439 11.15.1 152 15 Basic functionality in BSS 40/20Mhz mode 11.16 823 11.15.1 152 15 Basic functionality in BSS 40/20Mhz mode 11.16 12118 11.15.1 152 15 Basic functionality in BSS 40/20Mhz mode 11.16 1052 11.15.1 152 Basic functionality in BSS 40/20Mhz mode 11.16 7483 11.15.1 Basic functionality in BSS 40/20Mhz mode 11.16 7485 11.15.1 Basic functionality in BSS 40/20Mhz mode 11.16 7484 11.15.1 Basic functionality in BSS 40/20Mhz mode 11.16 7486 11.15.1 Basic functionality in BSS 40/20Mhz mode 11.16 6869 11.15.2 152 16 Operating Modes (40/20MHz) 11.16 6868 11.15.2 152 16 Operating Modes (40/20MHz) 11.16 9889 11.15.2 152 19 Operating Modes (40/20MHz) 11.16 824 11.15.2 153 3 Operating Modes (40/20MHz) 11.16 440 11.15.2 153 3 Operating Modes (40/20MHz) 11.16 9890 11.15.2 153 3 Operating Modes (40/20MHz) 11.16 9891 11.15.2 153 3 Operating Modes (40/20MHz) 11.16 4579 11.15.2 153 Operating Modes (40/20MHz) 11.16 7038 11.15.2 154 3 Operating Modes (40/20MHz) 11.16 8042 11.15.2 Operating Modes (40/20MHz) 11.16 2853 11.15.3 155 6 STA Capabilities (40/20MHz) 11.16 10600 11.15.3 155 6 STA Capabilities (40/20MHz) 11.16 9892 11.15.3 155 STA Capabilities (40/20MHz) 11.16

6. #104 Motion by John Ketchum and seconded by Joonsuk Kim to approve resolution of comments found on the tab labelled “Pending motion 4” in document 11-06/0675r52.

Based on resolutions agreed to at Dallas ad hoc meetings during week of November 13. Includes modifications to 40 previously approved comment resolutions. These are resolutions that modified text in D1.0 sub clause 7.4.7.4 and 7.4.7.5, which have been removed as a result of accepting the text in 06/1411r7, or modify related sections. These are included in rows 47 through 86 of the referenced tab.

6.1. Motion to amend #104 by George Vlantis to remove CIDs 7357 and 7371 was seconded by Massimiliano Siti 6.1.1. Discussion 6.1.2. Resolution does not address the original comment 6.1.3. Not fair to remove CIDs that were agreed upon in ad hoc 6.1.4. OK to pull out but should be immediately motioned separately 6.1.5. These comments have been directly addressed in 11-06-1411r7 6.1.6. Colleagues comments were ignored 6.1.7. Motion to call the question by Adrian Stephens and seconded by Jon Rosdahl (requires a 2/3 majority) passed (66, 0, 1) 6.2. Motion to amend failed (5, 47, 11)

Submission page 15 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

6.3. Main motion #104 passed (62, 3,11)

7. Status report from General ad hoc chair Jon Rosdahl (doc 11-06-0688r46) 7.1. 4 outstanding comments related to .11k being finished first 7.2. Joe Levy presented the .11k rationalization in 11-06-1589r2 7.2.1. Beacon measurement – no change needed 7.2.2. Channel load measurement – no need to change 7.2.3. Noise histogram – no need to change 7.2.4. Frame report request measurement – will not yield any info on secondary 20 MHz channel 7.2.5. Station statistics report and request – need to report in groups; any change in order? 7.2.6. Location config info – no change 7.2.7. Neighbor report – work around has been found; define one HT sub-field and put remainder into an extension field 7.2.8. Link measurement – RF ping; no need for change 7.2.9. QoS metrics – has not been addressed 7.2.10. RCPI issues – how to define; no need to affect the antenna info elements 7.2.11. PCO issues – none 7.2.12. Additional Phy measurements – open to suggestion 7.3. Questions: 7.3.1. Next steps; how to handle opens? A – waiting for proposals; nothing has been broken but there is opportunity to improve 7.3.2. Which areas will be addressed immediately? A – STA statistics; neighbor report 7.3.3. Additional Measurements just nice to have? A – yes 8. Chair noted that Richard Paine and Joe Kwak have done yeoman service and should be recognized 9. After ‘change’ text available it will be circulated through .11k before January ad hoc 10. Chair - there is a similar synchronization due diligence with .11r which needs to be addressed, likely by MAC ad hoc. 11. MAC ad hoc chair responded that a doc similar to Joe’s would be helpful; no .11r work is active at the moment. Most of the .11r issues are security related 12. Request to .11n from .11r – give .11n tutorial to .11r in January 13. .11n has not received a .11k tutorial from .11k 14. No further motions from BF&LA; it is done!!! 15. Phy discussion topics or planning for January? A - Planning won 16. Time line discussion; (11-06-1662r4) (slides 56,57) 16.1. Exec Com meetings are key to time line 16.2. No published calendar for 2008 but we can guess (slide 58) 16.3. Jan 15-19 in 2008, no EC meeting unfortunately which puts April 2008 publishing in jeopardy so, (slide 61) would need to complete Sponsor Ballot by Nov 2007 or push out SB to March 2008 which would push publication date to July 2008 16.4. Discussion? 16.4.1. Assuming LB in March successful it is highly unlikely we could meet the Nov 2007 SB goal; in fact any of the 3 options 16.4.2. Body asked chair to gather some history from other groups to help guide us? Chair agreed 16.4.3. Should not leave as is since then change would be massive in January

Submission page 16 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

16.4.4. Chair asked for show of hands - Leave as is (14), Assert SB Earlier (24), Push out (5) 16.5. Straw poll to adopt finishing the SB in November as the basis for the time line which would therefore be unchanged (12,12,23) => inconclusive 16.6. Straw poll to leave the timeline plan of record as it is currently (46,4,4) 17. Motion by Jon Rosdahl and seconded by Don Shultz to Request authorization for TGn to conduct teleconferences for the purpose of comment resolution every Wednesday from 11:00 to 13:00 ET from 29-November to 2 weeks after the close of the 802 March plenary (March 16, 2007) passed unanimously. 17.1. 7 opportunities exist; Nov 22 is TG week 17.2. Gen ad hoc wants Dec 20 17.3. Phy ad hoc wants Dec 13 17.4. Coexistence wants Dec 6 and Jan 3 17.5. None for Nov 29, Dec 27, 17.6. Group agreed to these teleconference assignments without further discussion 18. Recall September motion to Request that 802.11 WG authorize TGn to conduct an ad hoc meeting for the purpose of comment resolution in London, UK during the period from Wed Jan 10, 2007 to Saturday Jan 13, 2007 at the London UK Hilton Paddington Hotel. With confirmation obtained from TGn during the Nov Plenary 18.1. Discussion 18.1.1. If we do not do Saturday cost is $900; Saturday would cost extra. 18.1.2. Think 3 days will be enough? Willing to remove Saturday? 18.1.3. Straw poll – who believes Saturday is needed (8)? Stop on Friday (13)? 19. Motion by Jon Rosdahl and seconded by Don Schultz to Request that 802.11 WG authorize TGn to conduct an ad hoc meeting for the purpose of comment resolution in London, UK during the period from Wed Jan 10, 2007 to Friday Jan 12, 2007 at the London UK Hilton Paddington Hotel passed unanimously 19.1. Who plans on attending? (39) 19.2. Registration will open in Dec 1 20. Chair – we need to anticipate comments on .11n LB#2 21. Motion by Jim Petranovich and seconded by Adrian Stephens to request authorization for TGn to investigate venues at which it could conduct ad hoc meetings for the purpose of comment resolution following the close of letter ballot 2.0 either

1. Immediately following the March plenary meeting in Orlando with the preferred location being the Caribe Royale Hotel or 2. An acceptable location during mid-April 2007. pending final review/approval to be held during the January interim meeting in London passed unanimously 22. Motion by Jim Petranovich and seconded by Don Schultz to request authorization for TGn to investigate venues at which it could conduct an ad hoc meeting for the purpose of comment resolution following the close of letter ballot 2.0 to be held just prior to the May Interim in Montreal Canada Wednesday May 9 thru Friday May 11 2007 with the preferred option being the Fairmont Hotel pending final review/approval to be held during the March plenary meeting in Orlando passed unanimously 23. Chair recessed for 30 minute break at 3:30 PM 24. Chair reconvened at 4:04 PM

Submission page 17 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

25. #105 Motion (11-06-1866r0) by Don Schultz and seconded by Marc de Courville to approve the recommendations of the Coexistence Ad hoc group for the comments contained in Motion Tab 8 and Motion Tab Comments of document 06/0724r43 which resolves the 4 comments listed below passed unanimously

CIDs Approved Unanimously D1.0 Clause Title D1.06 91 9.2.5.4.1 84 10 Dual CTS Protection 9.2.5.5a 12110 9.2.5.4.1 84 10 Dual CTS Protection 9.2.5.5a 12220 9.2.5.4.1 84 10 Dual CTS Protection 9.2.5.5a 12244 9.2.5.4.1 84 10 Dual CTS Protection 9.2.5.5a

26. #106 Motion (11-06-1488r8) by Jim Petranovich and seconded by George Vlantis to accept submissions 1694r0, 1689r0 and 1717r0 as instructions to the TGn technical editor Note that these do not relate to CIDs but do relate to text 27. Informal discussion related to motion set 16 in deference to 4 hour rule (need to wait 6 minutes) 27.1. page 14 line 33 in1571r6 – Eldad Perahia proposed new text related to minimum sensitivity 27.2. 4 hour rule is now satisfied at 4:22 PM 28. #107 Motion (11-06-1488r9) by Jim Petranovich and seconded by VK Jones to approve resolution of comments found on the tab labelled “pending motion set 16” in document 11-06-0693r75 amended “as changed in 1571r7 page 14 line 32-34” passed unanimously 29. Phy has about 80 comments remaining 30. Matt Fischer Chair of MAC ad hoc reviewed progress from the last two days. 31. #108 Motion by Matt Fischer (11-06-1807r2) and seconded by Srini Kandala to accept comment resolutions in 11-06/0690r50 tab "motion_061116” passed unanimously 32. 40 MHz in 2.4 MHz topic discussion: 32.1. Many authors and many compromises 32.2. Assaf Kasher reviewed changes proposed in (11-06-1699r6): 32.3. Too many options so reduced to 2 bits (4 options) per field 32.4. Proposed an alternative in 2.4 GHz which effectively is a protocol to fall back to 20 MHz from 40 MHz for a specific duration if a specific adjacent channel threshold is exceeded 32.5. Body suggested amending text as follows: The receiver shall hold the 20 MHz primary channel CCA signal busy for any signal 20 dB above the minimum modulation and coding rate sensitivity (–62 dBm) in the 20 MHz primary channel. When the primary channel is idle, the receiver shall hold the 20 MHz secondary channel CCA signal busy for any signal 20 dB above the minimum modulation and coding rate sensitivity (–62 dBm) in the 20 MHz secondary channel. [change previous sentence to] The receiver shall hold both the 20 MHz primary channel CCA and the 20 MHz secondary channel CCA busy for any 40 MHz signal 20 dB above the minimum modulation and coding rate sensitivity (~59 dBm)

Also, in 9.20.2 change ‘DIFS’ to ‘minimum of AIFS and DIFS’ in all three places in the third para

Also, in 11.9.8.4 last sentence of the second para. It may transmit on the primary channel. [and delete] 40MHz upper or 40MHz lower transmissions.

Submission page 18 Garth Hillman, Advanced Micro Devices

Nov 2006 doc.: IEEE 802.11-06/1713r0

Add the following para after the second para in 11.9.8.4 “An AP operating in 20/40 MHz BSS in the 2.4 GHz band shall switch the BSS to 20/40 MHz mode if it receives notification from all the STA in the BSS that they have switched to 20/40 MHz. Straw poll (2 for and 39 against). [Secretary’ note - I do not believe I captured the text of this straw poll exactly however it is close and was defeated in any case.] Amendment was unanimously accepted prior to the motion so a motion to amend was not required 32.5.1. Discussion 32.5.1.1. power save not properly addressed 32.5.1.2. VOIP calls in secondary channel may get dropped 33. #109 Motion by Assaf Kasher to accept the text in 1699r6 as amended by the body as above was seconded by Tim Towell 33.1. Motion to amend table in 1699r6 text by Assaf Kasher and seconded by Jim Petranovich to change 12% to 10% to be consistent passed unanimously 33.2. Main motion fails (37,28,14) as it requires 75% being technical 34. #110 Motion by Jim Petranovich to adopt text in (11-06-1841r1 prohibiting 40 MHz in 2.4 GHz band) was seconded by Adrian Stephens 34.1. Discussion: - Motion to call the question passed (69,3,6) 34.2. Motion failed (40,31,13) as it is technical and therefore requires a 75% super majority 35. Motion by Jason Trachewsky and seconded by Dave Andrus to incorporate all of the comment resolutions approved during the November plenary into Draft 1.06 to create Draft 1.07 and request a 15 day Working Group Letter Ballot to approve Draft 1.07 to become Draft 2.0 and that Draft 2.0 be sent to Working Group Letter Ballot requesting that Draft 2.0 be forwarded to Sponsor Ballot 36. Motion by Jim Petranovich and seconded by George Vlantis requesting a roll call vote passed (40,21,4) 36.1. Discussion: 36.1.1.1. Remarkably precipitous at this late date 36.1.1.2. Motion to call the question by Chris Hansen and seconded by Dave Andrus failed (30,39,3) 36.1.1.3. Will slow down the process instead of speeding it up 36.1.1.4. Let’s get a snap shot due to the large volume of changes already made 36.1.1.5. Orders of the day 37. Chair adjourned the session at 6:02 PM

Submission page 19 Garth Hillman, Advanced Micro Devices

November 2006 doc.: IEEE 802.11-06/1890r0

IEEE P802.11 Wireless LANs

November 2006, TGp/WAVE Minutes

Date: 12 - 17 November 2006

Author(s): Name Company Address Phone email 8600 Jefferson Street NE Filip Weytjens TransCore +1 (505) 856-8000 [email protected] 87113, Albuquerque, NM 1321 Valwood Pkwy, Suite 620 Randy Roebuck Sirit Inc +1 (972) 243-7208 [email protected] Carrellton, TX 75006

Abstract This document includes the meeting minutes for the IEEE 802.11 TGp WAVE Task Group held in Dallas, TX from November 12th to 17th, 2006, under the TG Chairmanship of Lee Armstrong of Armstrong Consulting and editor Wayne Fisher of ARINC. Minutes are taken by Randy Roebuck of Sirit and Filip Weytjens of TransCore.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Filip Weytjens, TransCore

November 2006 doc.: IEEE 802.11-06/1890r0

Monday November 13, 2006, 8:00 AM Session

Lee opened the meeting at 8:05am. Call for temporary secretary until Filip Weytjens arrives. Randy Roebuck to act as temporary secretary until Filip arrives. Minutes are: • Lee covered anit-trust and patent policies, attendance sign-in. Randy Roebuck gave recommendation that they should have attendance sign-in information at registration and information boards. • Questions raised about 4 hour rule clarification. All changes need to be done by Tuesday evening. • Dick Roy gave update on CALM in Cornwell last month and invited everyone to this evening on CALM tutorial in Landmark B. Europe plans to adopt 802.11p “WAVE” mode as M5 (DSRC). Also, Dick discussed interface requirements and interference studies for Europe. No written presentation. • Tom Kurihara gave 1609 staus (all trial use) in presentation # 1712. o 1609.2 Security is released. o 1609.3 Network Services draft is getting ready for recirculation ballot. Changed PSID / PSC from ACID and ACM. Preparing tutorial for Registration Authority. o 1609.4 Multi-Channel Operations was approved November 2006 and go to publication shortly. o Next meeting in San Antonio at SwRI is February 6-8. • P802.11p /D1.4 draft was approved ( second Dick Roy) for the committee to review. Wayne Fisher, editor started to review the process. • Justin McNew raised FCC regulation issue on peak power. Broady Cash gave background information and could not find peak power reference in part 90. Dick Roy mentioned average peak power should be used. Broady Cash researched the issue with chipset manufacturer and they used XXXX power. Doug Kavner raised issue on the requirements regarding Masks A, B, C & D. Alastair raised whether we should discuss regulation issue in this meeting since we have no control. Broady showed Class C spectral mask example. Justin and Dick raised multiple scans are needed to show the variability. Dick agreed that this regulation issue and power definition used is not 802.11 issue. Broady/Dick to work wording in appendix I.2.3. Dick raised the issue on “relative to the station power class”. • Dick asked everyone to look at new feature “TSF” that applies to “WAVE” and other 802.11 activities.

Tuesday November 14, 2006, 4:00 PM Session

Lee Armstrong chair of the TGp working group opened the session at 4:10PM.

The session started with a discussion on two proposals for the definition of the spectral mask.

Doc IEEE 802.11-06/1796r0 – Proposal 1 - Broady ‘s proposal to define the mask of the transmitted spectrum. Changes included: 1) To be clear that we added the dB relative to the maximum density of the signal. 2) Reworded the sentence “In all cases, …” to make it more clear.

Doc IEEE 802.11-06/8725r0 – Proposal 2 - Dick’s proposal. Changes included modifications to Annex J and section I.2.3. This document was not available on the server.

Question was raised what it means when a chip set is configured for 17 dBm. This is the average of the peak points over the bandwidth.

Straw poll: Who is in favour of using proposal 1 to define the transmitted mask?

Favour: 11

Submission page 2 Filip Weytjens, TransCore

November 2006 doc.: IEEE 802.11-06/1890r0

Against: 3 Abstain: 12

As a result of the vote, Broady followed up with a discussion on proposal 1.

Modifications: 1) Alastair: change transmitted spectrum to transmitted spectral density. 2) Doug: Editorial changes 3) Doug: Specify operation for 10 MHz channels (excluding 20 MHz).

Justin brought up that the definition is still different from how a spectral mask is defined in 802.11. His proposal was to generate a paragraph for each mask using the same language as we have in 802.11ma today. Broady will generate a new proposal based on this comment.

Lee requested which other technical concerns should be addressed in the standard?

1) Daniel: Expressed reservation about the need for the TSF set/get primitive. Justin believes that it is useful to exchange time information to a unit that does not have access to a GPS unit. Document 1542r1, discussed in Melbourne, addresses the need for the TSF Get/Set feature. 2) Alastair brought up a concern on the timing. He will provide updated language to Wayne. 3) Dick went through document “Draft P802.11p-D1.4+JPM111306_RR1.doc” and discussed proposed modifications. A presentation will be prepared to support the changes discussed. This presentation will include the motions on which we will take a vote on Wednesday evening.

The session was recessed on 6:05 PM.

Wednesday November 15, 2006, 4:00 PM Session

Lee Armstrong chair of the TGp working group opened the session at 4:05PM.

Broady presented the language he created as a response to the transmit spectral mask action item (Doc 1769r1). Carl requested some editorial changes to the proposed language.

Following the editorial changes that Broady made to the original language and updating the language with the comments received from Carl, Lee asked whether there was an objection to accept this change. No objections. The updated language was posted to the server as IEEE 802.11-06/1796r2.

Broady continued with a discussion on document IEEE 802.11-06/1827. The proposal was to refer to the channel model as informational.

Dick expressed his concern with including this information in the standard as it was informational and an implementer was not required to comply.

Bryan and Daniel were concerned about adding this information to the standard, as there was no precedent for such information.

Jerry explained that it was important to have this information in the document to give guidelines to a developer.

A straw poll on this language resulted in a tie.

A motion will be created and presented during the Thursday morning session.

Submission page 3 Filip Weytjens, TransCore

November 2006 doc.: IEEE 802.11-06/1890r0

Alastair continued with a discussion on the regulatory language (doc: IEEE 802.11-0/1825r0). This documented was posted to the server by Wayne.

A motion on this subject will be presented during the Thursday morning session.

Dick Roy proceeded with a discussion on doc: IEEE 802.11-06/1826r0. Dick made clear that the deletion in the beginning of the document was not part of the proposal. He requested the group to look at the changes he would discus during his presentation.

It was proposed to change WBSS to WSS. Bryan supported this. Justin felt that changing the name would only add confusing.

Changes where made to the document and approved by the body except for: 1) Definitions 2) WBSS to WSS change 3) Peer -> Destination MAC Address 4) SyncRequest in the MLME-WAJoin.request

A straw poll was requested on who was in favour for keeping the WBSS and not changing it to WSS. Favour: 16 Against: 1

A straw poll on whether we should keep provider and not change it to announcer. Favour: 11 Against: 5

Session was recessed at 6:05 PM.

Wednesday November 16, 2006, 10:00 AM Session

Lee Armstrong chair of the TGp working group opened the session at 10:30AM.

Lee mentioned that TGn was planning to remove the 10 MHz BW from their standard. They will have a motion this afternoon.

Doc IEEE 802.11-06/1833r0

Motion: Move that recommendations of IEEEE 802.11-06/1825r0, as amended during PM2 TGp session on Nov 15, 2006, be incorporated into draft 1.5 of TGp.

Moved by: Wayne Fisher Seconded: Justin Mcnew Vote for: 15 Vote against: 1 Vote abstain: 3

Motion passed.

Lee continued with a discussion on the proposed changes in 1827r1.

Move to accept the proposed changes to the 11p draft (D1.4) as presented in this document and to instruct the TGp editor to make these changes with the appropriate formatting.

Submission page 4 Filip Weytjens, TransCore

November 2006 doc.: IEEE 802.11-06/1890r0

Discussion: Broady explained that this motion adds information to annex I. The first sentence of the annexes points to regulatory information in a section that describes radio performance specifications.

The advantage of putting this in is that this document better identifies how a radio should react when put in the actual environment. Access to this channel model would help a developer.

The downside is that a channel model has not yet been used within 802.11.

Bryan: Where can we put it? Broady: In the ASTM standard Bryan: Would this give us the same result? Broady: Yes Alastair: Does ASTM references 802.11p? Lee: No Broady: 802.11 references the FCC document and the FCC document references the ASTM document. Alistair: Can’t we reference to the ASTM standard Broady: The ASTM standard is not complete and therefore can’t be referenced to. Lee: It could be put in the ASTM testing standard but this document does not exist.

Any further discussion?

Jerry: If we include this information in our present p draft (my preference) would this negatively impact the letter ballot? Lee: Probably yes. Jerry: Does anybody has personal experience on what effect this would have on the letter ballot?

Bryan: It would impact my vote negatively.

Broady: Can we have a straw poll? Lee: Yes Broady: What is the group preference? Continue considering adding this information or to move this information into a different standard.

Lee: Point of order. There is not yet an official motion on the floor. Therefore we can take a straw poll vote at this point.

Straw poll: Should we recommend bringing this up to the ASTM Committee Vote for: 7 Vote against: 1 Vote abstain: 13

Straw poll: This information being considered in 11p? Vote for: 3 Vote against: 5 Vote abstain: 17

The motion was not brought before the group and the editor is not obligated to take any action on it.

Dick continued with a discussion on 11-06-1826-01-000p-rr-dot11p-changes.doc. Because there were some deletions within the document we could not act on the document as presented.

Modifications where made to the document during the discussion. Accepted changes included: - Changes to the introduction Submission page 5 Filip Weytjens, TransCore

November 2006 doc.: IEEE 802.11-06/1890r0

- Changes to the list of participants - Definitions: Wireless Access in Vehicular Environments (WAVE) – Changed “complying with” to “conforms to” - WBSS: A set of cooperating stations operating in WAVE mode consisting of a single WBSS provider and 1 or more WBSS Users. - WSI - Clause 5.2.2A - Clause 5.2.3.3 - Clause 7.1.3.3.3 – Language modified during session. - Clause 9.1.4 - Clause 9.15 – Language was modified during the session. - Clause 10 - Clause 11 – Language was modified during the session. - Annex J – Change to the 6th paragraph as described, others are covered through previous motions.

Motion: Move to accept the proposed changes to the 11p draft (D1.4) as presented in document IEEE 802.11-06/1826r2 and to instruct the TGp editor to make these changes with the appropriate formatting.

Moved by: Dick Roy Seconded by: Jerry Landt

Discussion? No.

Vote for: 12 Vote against: 0 Vote abstain: 4

Following motion documented in IEEE 802.11-06/1832r1

Motion: Believing that 802.11p draft 1.4 (with approved changes to become 1.5) satisfies all WG 802.11 rules for letter ballot, move to request the 802.11 WG to authorize a 40-day letter ballot to being as soon as practical asking the question “Should the attached 802.11p draft 1.5 be forwarded to Sponsor Ballot?”

Questions? No

Moved by: Jerry Landt Seconded by: Broady Cash

Discussion? Yes

Dick: The Mib entries are completely insufficient for international operation; especially European operations. Daniel: The document is produced hasty and we have not been able to discuss all details. Lee: That is only true for changes made this week. Justin: There is nothing in the document that is going to cause major objections. Randy: Concern about the changed shall’s and its impact to the PIC’s document. Brian: According to IEEE rules he believes that the document needs to be technically complete.

Vote for: 12 Vote against: 3 Vote abstain: 5

Motion passes.

Submission page 6 Filip Weytjens, TransCore

November 2006 doc.: IEEE 802.11-06/1890r0

Session was closed at 12:35 PM.

Submission page 7 Filip Weytjens, TransCore

November 2006 doc.: IEEE 802.11-06/1690r1

IEEE P802.11 Wireless LANs

TGr Meeting Minutes November 2006 Session

Date: 2006-11-17

Author(s): Name Company Address Phone email Michael Research In 5090 Commerce Dr, 905-629-4745 [email protected] Montemurro Motion Mississauga, ON. L4W 5W4 Ext 4999

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Monday November 13, 2006 (Adhoc Session) 8:00 am

Attendees: Clint Chaplin Bill Marshall Jouni Malinen Lily Chen Paal Engelstad Keith Amann Mahalingam Mani Matthieu Monpetit David Goddall Dan Harkins Kapil Sood David Hunter Frank Ciotti Bob Miller

• Call to order • Agenda for the November 2007 TGr session is document 11-06/1664r0

• Ad-hoc Agenda – 8:00am – 10:00am • Anonce • Comments Resolution

• Review IEEE 802 policies and procedures for Intellectual Property. • The following slides from 06/1664r2 were presented to the Task Group: • The slide titled “IEEE-SA Standards Board Bylaws on Patents in Standards” • The slide titled “Inappropriate Topics for IEEE WG Meetings” • The slide titled “Copyright” • The IEEE holds the copyright for all submissions at these meetings. • Chair asked if anybody has any questions about the patent policy. • None

• Anonce discussion • For PSK mode, there is an issue with the PMK-R0 Name being the same across all Initial Associations. Example of LB Comment is 897. The Key Lifetime known between the R0KH & R1KH can become out of synch. • Since PSK’s are administered out-of-band, all KH’s have a fixed lifetime for a PSK that is equal. Suggestion is to ignore the Key Lifetime field for PSK – 45 days is the maximum lifetime that can be indicated. Setting the lifetime field to zero can be used to convey that the key does not expire. • There were comments that TGr should not address PSK at all. That comment has been resolved as indicated that PSK is needed for certain deployments. • One option mentioned on the reflector is going to 32 bits for the lifetime field. • This option may not resolve the issue. It would require synchronized clocks on all KH’s

Submission page 2 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Straw Poll: Which of the following alternatives for comment resolution of 897 are acceptable (yes/no for each): a) Simple Anonce solution present in the comment resolution of 897 in the 1596 spreadsheet: 2 yes, 4 no b) Rescind comment 11-06-1147 (accept 11-06-1636): 2 yes, 5 no c) A new R0 Nonce (11-06-1663): 5 yes, 4 no d) Define the key lifetime = 0 to mean never expires (needs submission): 10 yes, 1 no

• Discussion on Issue Group 99 • Comment 20 – The Target AP does not obtain all the AS information from the initial association. • The 3 party protocol provides a mechanism to transport the AS information to the R1KH. • An informative note would be helpful explaining how this is performed. • Comment 1619 – it is not clear how much work is required to resolve this. We cannot make changes to 802.1X. Is there any other mechanism to invoke the session timeout behaviour? Jouni will take a closer look at this to see what options are available.

• Discussion on Groups 1-4 • There will be a motion at 17:30 today to accept the resolutions for these comments. • Are there any issues on Groups 1-4 at this time? • Comment 1531 – Accepted to place sub-clause immediately after main clause number per IEEE style manual.

• Discussion on General Encapsulation Scheme (comments 1835, 1860) • Bill Marshall drafted submission 06/1622 to address these comments. The STA will use ordinary data packets rather than Action Frames. The receipt of the frame by the Target AP is sent down to the SME and then back up such that it appears to be received as any other management frame. • The current scheme is received by the RRB and sent to SME to be processed. Current draft uses the “Reservation Local” interface. This new scheme a cleaner approach. • Is the processing of over-the-DS and over-the-air frames at the Target AP now the same? Yes. • The RRB mechanism we have is fine. This is still a management frame, just encapsulated in a data frame. With this the STA must create both a management frame and then encapsulate it in a data frame. It is more work for the STA. • The group agrees that for greenfield, the encapsulation scheme is cleaner. • Are you proposing to use data frames for both over-the-air and over-the-DS? • No, continue to use Auth frames for over-the-air. • The processing will be different on the Target AP. • Adjourned at 9:30 am.

Submission page 3 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Monday November 13, 2006 4:00 pm

• Call to order • Review IEEE 802 policies and procedures for Intellectual Property. • The IEEE owns the copywrite for all submissions at these meetings. • Chair asked for information on any Patents or Patent Applications that are applicable to the subject discussed during this meeting – None were given. • Review operating rules for a Task Group. • Attendance reminder. • Approve minutes from the September session – document 11-06/1477r1 • Minutes are approved unanimously. • Approve minutes from the Teleconference sessions – document 11-06/1575r2 • Minutes are approved unanimously. • Approve minutes from the TGr October Adhoc meeting – document 11-06/1606r0 • Minutes are approved unanimously. • Agenda – document 11-06/1664r2 • Any changes to the agenda will be posted in document 11-06/1664r3 • Discussion on security assumptions for TGr. • What assumptions is TGr security built upon? • We need to understand what the trust relationships are for TGr. • There was a section in draft 2.2 that stated the requirements but no the assumptions. • For instance, there is an implicit assumption that the R0KeyHolder does not divulge the key to an untrusted party. • It would be beneficial to bring the text back from draft 2.2 and updated as discussed. • The text from draft 2.2 is included in all three submissions to address the key distribution comments from the last letter ballot. • Document 11-06/1754r0 will be updated based on this discussion and submitted by Bill Marshall. • Discussion around PSK support within IEEE 802.11r • There are cases in the home with HDTV that PSK support is required. Cordless phones are required for Fast Transition. • PMK caching can handle the home case. • PSK support was previously required for FIPS. • The only savings is the 4-way handshake in the pre-shared key case. We already have a solution for PSK. • Most of the time in a home scenario, there will be no fast transitions. • If you enable IEEE 802.11r and IEEE 802.11e, then there is an issue with Fast Transition. • In the enterprise, wireless switches have addressed the roaming problem. • Once there are multiple controllers, there is a problem with roaming. • The problem that IEEE 802.11r addresses occurs when QoS and security both enabled. • The 4 message or 6 message exchanges for Fast Transition resolve the QoS problem. • There is a synchronisation problem with key lifetimes. That was resolved at this morning’s adhoc meeting.

Submission page 4 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

• Discussion on comment resolutions for groups 1 through 4 in comment resolution document 11-06/1576r7 • Comments 279, 499, and 1969 should not be considered in this blanket motion. • We have rejected comment 490 because it requested the insertion of a summary table. However we had taken the table out to address another comment. • Comments 1713 and 1714 will be accepted.

MOTION at 5:30pm: Accept the comment resolutions in document 11-06/1576r7 in comment group #1 through comment group #4, with the exceptions of comments 279, 499, and 1969. By: Rajneesh Kumar Second: Bob Miller Discussion: • None. Result: 9 – Yes; 0 – No; 1 – Abstain. Motion Passes.

• Discussion on comments in group 99 in 11-06/1576r7. THE TG EDITOR REQUESTS A RULING FROM THE TGr CHAIR ON THE VALIDITY OF COMMENTS IN GROUP 99. • The IEEE SA policy rules state that comment resolutions must contain a proposal of changes to the draft that if accepted, would convince the no vote to a yes vote. • The comments in group 99 do not have sufficient details for the task group to provide normative text. • Nobody from the task group has provided normative text to address this comment. • Comment 18 should be valid because it asks more description on the relationship between the Key Holders and the Authenticator. • IEEE SA rules state that it’s up to the commentor to provide enough details so that the task group can resolve the comment and change the no vote to a yes vote. • It’s up to the commentor to be specific enough for the task group to address the comment. • We may lose information if we just reject comments as a blanket ruling. • The IEEE requires that the editor to create an auditable trail of all changes to the document. • If some of the comments are ruled invalid, but normative text to address the comment is presented during this session, then the comments can be updated and resolved by the draft. • We should be due diligence done to address these comments, so that we can move forward to address these comments. • There is a big difference between rejecting a comment and declining a comment. These comments should be declined. • We have just address comments that should also be rejected. • Comments 20 and 1619 should not be included in this ruling. • The rules of the IEEE SA are very clear. The rules were made by the IEEE SA are created to move the process forward. • If the editor cannot show an auditable trail, REV CON can instruct a Task Group to start over again. • This group should not revert to policies and procedures to reject comments. • A comment must provide enough details for the task group to determine how to addresss the comment. • The chair will make a ruling later in the week. • Recess until Tuesday at 8:00am Submission page 5 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Tuesday November 14, 2006 8:00 am

• Call to order • The comment resolution document has been updated to document 11-06/1576r8 • We will continue discussion on comments in issue 99 in 11-06/1576r8 at a later time. • Discussion on PMK-R1 Distribution Security Analysis by Lily Chen as document 11- 06/1765r0 • Document gives background on key distribution issues and how they have been addressed in TGr. • The content of these messages are not out of scope for TGr. The transport of the content is out of scope for TGr. • There is no risk of replay attacks for this three party protocol. • There is still no trust relationship defined between the R0KeyHolder and the R1KeyHolder. • The transaction that takes place between the R1KeyHolder and R0KeyHolder is in-line with the Association exchange. Also, the R1KeyHolder may take time to discover the R0KeyHolder. • The MK encryption could be replaced by a PRF function to address the problem with the key hierarchy. • The PMK-R0 and the MK are independently derived from the MSK. The MK cannot be separated across multiple PMK-R1’s. • In both the push and pull model, the R0KeyHolder and the STA can agree that the R1KeyHolder is trusted. • If there is no push or pull model, there is no basis for the relationship between the R0KeyHolder and the R1KeyHolder. The R1KeyHolder can lie about what identity that the R1KeyHolder presents to the STA. • This problem is an authorisation problem. The STA and the R0KeyHolder need to identify and agree on the identity of the R1KeyHolder. However it is not part of the push or pull model. • The proposed three party push or pull model solves a fundamental flaw with TGr. • This is really a 3 party problem and the STA has no reason to trust the R1KeyHolder unless the STA and the R0KeyHolder agree on the identity of the R1KeyHolder. • There still is not an explicit mechanism to define how the R1KeyHolder is authorised to receive the PMK-R1. • The STA always provides the contribution key, regardless if the model is a push or pull model. This will be presented in the submission today. • The problem is that we have not agreed on a common system definition so that we cannot complete the security definition. • This presentation asks the question “how does the R1KeyHolder obtain the PMK-R1 and how is it authorized to receive it”

• Discussion on document 11-06/1612r2 by Bill Marshall. • None.

Submission page 6 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

MOTION at 9:13am: Accept the submission contained in document 11-06/1612r2, and instruct the editor to incorporate the changes into the draft. By: Bill Marshall Second: Kapil Sood. Discussion: • This motion brings back a known security flaw and brings us back to a place we shouldn’t be. • Draft 2.2 was a good draft and the process took a take a step backwards in our progress. • If we are going to have a pull or a push model, we need to go back to base assumptions so that we call the question. • These push or pull models address the security requirements for TGr. Result: Yes – 23; No – 9; Abstain – 10. Motion fails.

• Discussion on document 11-06/1613r2 by Bill Marshall. • None. MOTION at 9:20am: Accept the submission contained in document 11-06/1613r2, and instruct the editor to incorporate the changes into the draft. By: Bill Marshall Second: Michael Montemurro. Discussion: • None. Result: Yes – 9; No – 13; Abstain – 13. Motion fails.

• Discussion on comments in Group 5 in the comment resolution spreadsheet document 11- 06/1576r8. • The previous submissions were presented to address these comments. • We are going to have to decide what the technical reason is for rejecting these comments.

• Discussion on document 11-06/1596r3 by Bill Marshall. • None.

MOTION at 9:34am: Accept the submission contained in document 11-06/1596r3, and instruct the editor to incorporate the changes into the draft. By: Bill Marshall Second: Bob Miller. Discussion: • None. Result: Yes – 10; No – 10; Abstain – 16. Motion fails.

• The task group would like to thank Bill Marshall for all his hard work is preparing these submissions.

• Discussion of document 11-06/1628r0 by Dorothy Stanley • None.

Submission page 7 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

MOTION at 9:43am: Accept the submission contained in document 11-06/1596r3, and instruct the editor to incorporate the changes into the draft. By: Dorothy Stanley Second: Journi Malinen. Discussion: • None. Result: Yes – 26; No – 0; Abstain – 5. Motion passes.

• We need to bring up a motion to accept the comment resolutions that we have addressed today. • Recess until 1:30pm.

Submission page 8 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Tuesday November 14, 2006 1:30 pm

• Call to order • Discussion on MDIE Policy Bit Definitions by Michael Montemurro in document 11- 06/1640r2. • The AP should be able to indicate to the STA that it cannot handle RIC’s as part of the base mechanism.

MOTION at 1:46 pm: Accept the submission contained in document 11-06/1640r2, and instruct the editor to incorporate the changes into the draft. By: Michael Montemurro Second: Rajneesh Kumar Discussion: • None. Result: Yes – 10; No – 0; Abstain – 6. Motion passes.

• Discussion on Key Derivation (Technical Issue number 8); document 11-06/1745r1 Key Lifetime for PSK. • This document was revised to address comment 560 as well.

MOTION at 1:50 pm: Accept the submission contained in document 11-06/1745r1, and instruct the editor to incorporate the changes into the draft. By: Bill Marshall Second: Michael Montemurro Discussion: • None. Result: Yes – 15; No – 0; Abstain – 2. Motion passes.

• Discussion on document 11-06/1622r0 by Bill Marshall • We already have a mechanism for the STA that works. We are changing it because there were two comments on the last letter ballot. • The MLME-RemoteManagement could maintain a table of destination MAC’s. • In IEEE 802.11e, only management messages are allowed to be transmitted using AC_VO without a TSPEC. • This submission only removes the term RRB. • We already use a similar mechanism in IEEE 802.11i for communications over the wire. • This imposes more additional work in sending frames across the DS between AP’s. • This proposed solution is much simpler for an Access Point to implement. • One of the messages that can be sent back from the target AP to the STA is a disassociate message. This is a technical flaw in this proposal. The target AP should not be able to send a disassociate frame to the STA. • We need a mechanism to provide over-the-DS communication. This mechanism is simpler and more extensible. This provides a generic mechanism is extensible and adding the definition of new management frames. • Action frames are needed to communicate between a STA and an AP. • For the STA, it has to create a management frame “over-the-Air”, and create a management frame and encapsulate the frame in a data frame “over-the-DS”.

Submission page 9 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

• This proposal is a good start in addressing this issue.

MOTION at 1:50 pm: Accept the submission contained in document 11-06/1622r0, and instruct the editor to incorporate the changes into the draft. By: Bill Marshall Second: Journi Malinen Discussion: • The reason why we used action frames is to transmit the FT frames using AC_VO. • An easy way to fix this is to update a QoS-enabled AP to implement a packet classifier. • There are different solutions to address QoS for this proposal. Result: Yes – 6; No – 4; Abstain – 10. Motion fails.

• Discussion on document 11-06/1718r0 by Bill Marshall on TGr state machines • There is more tolerance to errors in informative text versus normative text. • We could delete the state machine definitions. • We could fix the state machine issues. • The state machines confuse the reader and do not clarify how the protocol works. • The intention of creating the state machines is to take the normative text and to clearly indicate how the normative text works. • These state machines do not provide the only way to implement TGr correctly. If so, they should be informative. • The state machine simply repeats the normative requirements. It is not good practice to repeat the description of normative procedures. • There is nothing in this presentation to indicate why the state machines should not be normative. • The state machines are very useful. They drive out issues. • Why would these state machines be informative given that the IEEE 802.11i state machines are normative? • The state machines should be included in the draft. They are useful in providing a security analysis. • If the state machines are left informative, then there is no onus on updating the state machines. • This resolution applies to 2 comments. The other 198 comments have already been resolved.

MOTION at 2:43 pm: Motion to resolve comment #1529 as “Accepted”, and #1530 (and all others with that proposed resolution) as “Accepted. 8A.6 moved to informative annex” , and instruct the editor to make the changes to the draft. By: Bill Marshall Second: David Hunter Discussion: • Whether this motion passes, we can make another motion to remove the text. • We could also leave the text and fix the bugs. Result: Yes – 7; No – 9; Abstain – 6. Motion fails.

Submission page 10 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

MOTION at 2:49 pm: Motion to resolve comment #1529 as “Counter. 8A.6 has been deleted.”, and #1530 (and all others with that proposed resolution) as “Accepted. 8A.6 has been deleted.” , and instruct the editor to make the changes to the draft. By: Stephen Palm Second: David Hunter Discussion: • There other issues with the state machines in the draft. It would be better if the text was move them to an informative annex. • The comments 1529 and 1530 provide a specific solution, but do not provide sufficient reason for changing. • The state machines are useful for developing the protocol. However they do not need to be normative or even needed in this specification. • The state machines have been a very effective tool for understanding what we describe in the text. Whether they need to be included in the text as normative is a secondary question. • The state machines should remain a separate solution and used as a tool to develop our protocol. • IEEE 802.11i provides normative state machines. • State machines are very valuable. However the state machine should not be included as normative text. The normative text describes the behaviour. The state machine limits the flexibility in implementing the standard. • Each use of the word “shall” requires an entry in the PICS. We would need PIC’s entries for every action in the state machine. • By including the state machines, we are repeating • The interpretation of the IEEE SA is that figures are informative but the text is normative. However, the IEEE style guide has been updated to state that all content in a normative clause is normative. • The view on the IEEE 802.11i state machines is that they are informative. • Anything implementation specific information in the state machines should be removed. CALL THE QUESTION Result: Yes – 5; No – 12; Abstain – 4. Motion fails.

• Discussion on co-ordination between TGr and TGn for content that would dependent on the two amendments. • There was a discussion on the email list and the consensus was that there was nothing in TGr that would affect TGn or visa versa. • We will need to validate this discussion at regular intervals. • If an issue arises, it would need to be addressed at the time it has been discovered. • It would be good to have a tutorial on the content for TGn. • Anything that would need to be negotiated in TGn would be dependent on TGr. • The tutorial on the TGn should go to a broader audience than just TGr. • TGn should do something similar to what TGs gave last night. • This tutorial could be given to a much broader audience than just IEEE 802.11. • Mixed-mode deployments could be affected. When you roam between mixed AP’s, you cannot degrade the security.

Submission page 11 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

• This amendment modifies the MAC; it would be of interest to TGn to describe its changes to the MAC behaviour. • We could put the TGn tutorial in the mid-term plenary. • If there’s any discussion to changes in cipher suites; or aggregation of management frames; then there could be issues with TGr. • It might be better to have a few people cover TGn in detail. • Given that there were 12000 comments for TGn; it would be productive to hold a tutorial to educate the working group on the content of TGn. • The QoS Null data frame aggregated with embedded management frames have been removed. • A joint meeting won’t likely take place before January. • Recess until 4:00pm.

Submission page 12 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Tuesday November 14, 2006 4:00 pm

• Call to order • Continued discussion on TGr state machines. • We should reject comment 1529 because it was not specific enough. • Comment 1529 should be rejected because the normative description of the TGr state machine is consistent with what was done to TGi.

• Discussion on document 11-06/1781r0 on the Key Holder requirements by Kapil Sood. • This document was reviewed at the adhoc on Monday and based upon the adhoc submission. • This is a standalone submission, not based on any other submissions that were rejected earlier. • If this document was accepted, we would have to determine which comments were rejected. • We discussed submission 11-06/1612r0 this morning but it was not on the server long enough.

MOTION at 4:19pm: Accept the submission contained in document 11-06/1612r2, with changes given in slide #14 of document 11-06/1765r0 and instruct the editor to incorporate the changes into the draft. POINT OF ORDER: The chair rules that it is a different motion because of addition of slide 14. By: Bill Marshall Second: Kapil Sood Discussion: • Slide 14 contained the assumptions on the key holders. • We are thrashing back and forth on putting this text in and out. • After creating submission 11-06/1613r0, it is extremely difficult to replace a key distribution protocol. It’s much easier to add a key distribution protocol starting from what is draft 2.2. • This goes back to the content that was included in draft 2.2. • What was included in draft 3.0 is not a key distribution protocol. CALL THE QUESTION. Result: Yes – 8; No – 2; Abstain – 2. Motion passes.

• Discussion on document 11-06/1617r0 by Bill Marshall • Nothing technical will be changing in the draft. However, it is a major change so it will require a vote.

MOTION at 4:31 pm: Accept the submission contained in document 11-06/1617r0 and instruct the editor to incorporate the changes into the draft and comment resolution spreadsheet. By: Bill Marshall Second: Journi Malinen Discussion: • None. Result: Yes – 10; No – 0; Abstain – 2. Motion passes.

Submission page 13 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

• Discussion on document 11-06/1754r0 by Bill Marshall • This submission adds two sentences to the draft. • The first sentence is a requirement. It should use the word “shall”. • This text has been created to remain consistent with RevMA • We could accept this text and address it later.

MOTION at 4:31 pm: Accept the submission contained in document 11-06/1754r0 and instruct the editor to incorporate the changes into the draft and comment resolution spreadsheet. By: Michael Montemurro Second: Harry Worstell Discussion: • Why don’t we make the correct changes to the draft and update it four hours from now. • We could move to table the motion until the updated text has been made available for four hours. MOTION TO WITHDRAW. No Objections.

• Edits to the discussion will be recorded in a document updated as 11-06/1754r1.

• Discussion on document 11-06/1769r1 by Journi Malinen • The current draft uses the ForceAuthorized variable to open the control port. However, this variable stops the EAPoL state machines. This presentation removes the need for use of this variable in TGr. • The Authenticator would have to use the new state. • We could trigger a restart using the MIB variables. • IEEE 802.1af is looking at cleaning up the state machines for reauthentication. • If the STA transitions to a new R1KeyHolder, we need to establish which R1KeyHolder triggers the reauthentication. • We’ve propagated the key lifetime throughout the key hierarchy. • It also looks like we have split the IEEE 802.lX state machine across two entities. • IEEE 802.1af is very early on in the discussions on how to modify the state machines.

MOTION at 5:09 pm: Accept the submission contained in document 11-06/1769r1r0 and instruct the editor to incorporate the changes into the draft and to accept the comment 1619 in LB87 with the resolution of “Accepted. Addressed with the acceptance of 11-06/1769r1”. By: Journi Malinen Second: Henry Ptasinski Discussion: • None. Result: Yes – 9; No – 0; Abstain – 2. Motion passes.

• Discussion on document 11-06/1766r0, a ruling from the TGr chair at the request of Bill Marshall. The Chair has ruled that comments in issue 99 are invalid • During the editors meeting, the IEEE SA staff confirmed all the supporting information contained in the ruling is valid. • The submission of document 11-06/1619r0 was an exception to this ruling. • The chair has ruled that comments are invalid, so that they can no longer be declined.

Submission page 14 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

• The commentors are welcome to create submissions based on these comments, or provide more specific comments on the next letter ballot. • TGr could make a motion to make a ruling that a comment is invalid. • Any member can ask the chair for the ruling on the validity of the comment. The Chair would have to consult the Technical Editor to determine the validity of a comment. • These rules are governed by IEEE SA. • This is supposed to be a fair and open process. However two individuals made this ruling. • Anybody who did not accept the ruling by the chair may appeal the ruling to the higher levels of IEEE 802. • The task group could make a motion could vote to rule comments invalid. APPEAL ON THE CHAIR’S RULING: There was no second to the appeal. • Recess until Wednesday at 8:00am.

Submission page 15 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Wednesday November 15, 2006 8:00 am

• Call to order • Status report on comment resolution as recorded in document 11-06/1576r10 • We have 8 remaining comments. • Discussion on comment 499. • This comment was originally rejected in document 11-06/1640r3. It should be accepted

MOTION at 8:20 am: Motion to resolve comment #499 as “Accept.” By: Bill Marshall Second: Rajneesh Kumar Discussion: • None. Result: Yes – 9; No – 0; Abstain – 2. Motion passes.

• Discussion on comment 819 • This comment was part of document 11-06/1640r3. It should be countered.

MOTION at 8:23 am: Motion to resolve comment #520 as “Countered. Changed to “Resource Request Protocol Supported”” By: Bill Marshall Second: Frank Ciotti Discussion: • None. Result: Yes – 9; No – 0; Abstain – 1. Motion passes.

• There were two comments 619 and 1306 that were marked invalid, but updated with document 11-06/1628r0 • The feeling of the task group is that these comments should remain invalid.

• Discussion on resolution to comment 7 and comment 22 • The resolution to comment 22 needs to be updated.

MOTION at 8:26 am: Motion to resolve comment #22 as “Countered. Changed to “AES-128- CMAC”” By: Bill Marshall Second: Donald Eastlake Discussion: • None. Result: Yes – 8; No – 0; Abstain – 3. Motion passes.

• Discussion on the resolution to comments regarding the More Data bit. • The commentor accepts the current resolutions.

MOTION at 8:32am: Accept the proposed resolutions for comments 279 and 1969 in the comment resolution spreadsheet 11-06/1576r19 By: Bill Marshall

Submission page 16 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Second: Donald Eastlake Discussion: • None. Result: Yes – 7; No – 0; Abstain – 5. Motion passes.

• Resolution to comments regarding the TGr security state machines – comments 1529 and 1530 • If the state machine is normative, then the state machine must be implemented to the behaviour specified by these state machines.

MOTION at 8:41am: Motion to resolve comments 1529 and 1530 as “Rejected. State machines intended to be accurate and specify behaviours that are applicable to all implementations. Comments are invited to help reach that goal.” By: Rajneesh Kumar Second: Donald Eastlake Discussion: • None. Result: Yes – 8; No – 0; Abstain – 3. Motion passes.

• Comments regarding the general encapsulation scheme – comment 1835 and 1860 • The task group confirmed the existing function of the RRB to solve this encapsulation problem. • The intention of comment 1860 to add a sub-type to the RRB encapsulation. This could be brought up as a separate submission.

MOTION at 8:51am: Motion to resolve comments 1835 and 1860 as “Rejected. General encapsulation schemes are overly complex for the function needed in IEEE 802.11r”. By: Michael Montemurro Second: Rajneesh Kumar Discussion: • None. Result: Yes – 6; No – 0; Abstain – 4. Motion passes.

• Comment resolution to “Make before break” comment 10

MOTION at 8:55am: Motion to resolve comment 10 as “Rejected. The comment does not provide any concrete reasons for why the existing protocol is considered complex and why the commentor feels that it violates the PAR.” By: Rajneesh Kumar Second: Kapil Sood Discussion: • None. Result: Yes – 7; No – 0; Abstain – 2. Motion passes.

• Discussion of PSK support • We have resolved all the comments on pre-shared key support. • People are going to implement PSK regardless of whether TGr includes it or not. It would be better to have something in the amendment to address this problem.

Submission page 17 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

• Document 11-05/1054r1 described an analysis and recommendations for keeping PSK in. • It’s the will of the task group at this time to keep pre-shared keys in.

• Discussion on document 11-06/1805r0 by Jouni Malinen • We have already addressed authorization attributes in draft 3.0 • Option 3 seems like the best approach to address this issue. • This information is transferred with the PMKSA because it resides within the network; it does not get transmitted to the STA. • Draft 3.0 on page 46, the text refers to the Authenticator behaviour. • The authorization information is different between the STA and the Key Holders • We should likely get Option 3 now and clarify the section in the later draft.

• Discussion on document 11-06/1810r0 by Bill Marshall • We need to include the FTIE in the probe response. If the STA asks for an FTIE in the probe request; the AP must provide the FTIE in the probe response. • The STA can request a list of IE’s in the probe request. • We can add a paragraph to describe what is included in the FTIE to transmit information in the probe response.

• Discussion on document 11-06/1640r5 by Bill Marshall • None.

• Discussion on document 11-06/1765r0 by Bill Marshall • Mutual authentication will require some sort of infrastructure support. The reference to Mobility Domain controller is not required.

• Recess until the Wednesday 1:30pm session.

Submission page 18 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Wednesday November 15, 2006 1:30 pm

• Call to order • Discussion on document 11-06/1810r0 • None.

MOTION at 1:39 pm: Accept the submission contained in document 11-06/1810r0 and instruct the editor to incorporate the changes into the draft and comment resolution spreadsheet. By: Bill Marshall Second: Michael Montemurro Discussion: • None. Result: Yes – 9; No – 0; Abstain – 1. Motion passes.

• Discussion on document 11-06/1640r5 • None.

MOTION at 1:44 pm: Accept the highlighted portions in yellow contained in document 11- 06/1640r5 and instruct the editor to incorporate the changes into the draft and comment resolution spreadsheet. By: Bill Marshall Second: Michael Montemurro Discussion: • None. Result: Yes – 8; No – 0; Abstain – 0. Motion passes.

• Discussion on document 11-06/1765r1 • We have accepted another motion that removes all references to MDC.

MOTION at 1:47 pm: Instruct the editor to delete from the draft, the embossed portion in slide 14 in document 11-06/1765r1. By: Bill Marshall Second: Rajneesh Kumar Discussion: • None. Result: Yes – 8; No – 0; Abstain – 1. Motion passes.

• Discussion on document 11-06/1805r0 • None.

MOTION at 1:56 pm: Move to instruct the editor to apply the proposed changes (option 2) from document 11-06/1805r0 and to accept the comment 20 in LB87 with the resolution of “Accepted. Addressed with the acceptance of option 2 in 11-05/1805r0”. By: Jouni Malinen Second: Frank Ciotti Discussion: • None. Submission page 19 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Result: Yes – 9; No – 0; Abstain – 2. Motion passes.

• Discussion on comment 1240

MOTION at 2:00pm: Motion to resolve comment 1240 as “Accepted. Text changes are given in document 11-06/1810r3.” By: Kapil Sood Second: Henry Ptasinski Discussion: • None. Result: Yes – 9; No – 0; Abstain – 0. Motion passes.

• Discussion on teleconferences • The call is either much too long or much too short. • There were two teleconferences and we only managed to resolve one comment. • We are not efficient about moving from a teleconference to the email thread. • It’s hard to get consensus on emails and teleconferences. • The policies and procedures state that no more than one teleconference call may be held per week. • We have been effective of resolving comments with the existing teleconference calls. • We do not have an adhoc scheduled for December, so it might be beneficial to increase the length of teleconference calls. • TGk holds 3 hour teleconferences. • We are only looking at holding two teleconferences on Dec 20 and Jan 10 before the January session.

MOTION at 2:14pm: Motion to hold weekly IEEE 802.11 TGr teleconferences starting December 6th, 2006 at 11:00 ET and continuing through the end of March 2007, for a duration of two hours on December 20th, 2006 and January 10th, 2007, and one hour on the other dates. By: Rajneesh Kumar Second: Bill Marshall Discussion: • None. Result: Yes – 9; No – 0; Abstain – 2. Motion passes.

• Discussion on a February adhoc meeting.

MOTION at 2:20pm: Motion to hold an IEEE 802.11 TGr ad-hoc meeting February 21th through February 23th, 2007. By: Bill Marshall Second: Kapil Sood Discussion: • None. Result: Yes – 10; No – 0; Abstain – 3. Motion passes.

• Recess until 4pm.

Submission page 20 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Wednesday November 15, 2006 4:00 pm

• Call to order • Discussion on pre-authentication in Comment 725 • Dorothy Stanley will update the pre-authentication proposal, but will be willing for the comment to be rejected at this point.

MOTION at 4:15pm: Motion to resolve comment 725 as “Rejected. In most applications of the TGr, the Mobility Domain is expected to include numerous BSS’s and the additional IEEE 802.1X authentications when moving to a new Mobility Domain is acceptable.” By: Rajneesh Kumar Second: Pat Calhoun Discussion: • None. Result: Yes – 13; No – 1; Abstain – 6. Motion passes.

• Discussion on preparing a new IEEE 802.11r draft.

MOTION at 4:19pm: Motion to request the technical editor to create an updated IEEE 802.11r draft as version 3.1. By: Dorothy Stanley Second: Bill Marshall Discussion: • None. Result: Yes – 16; No – 1; Abstain – 1. Motion passes.

• Discussion on the comment resolution spreadsheet

MOTION at 4:21pm: Motion to accept document 11-06/576r11 as comment resolutions of LB87 comments. By: Bill Marshall Second: Bob Miller Discussion: • None. Result: Yes – 15; No – 1; Abstain – 3. Motion passes.

• Recess until Thursday at 1:30pm.

Submission page 21 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

Thursday November 16, 2006 1:30 pm

• Call to order

MOTION at 1:50pm: Moved: Instruct the technical editor to rename 802.11r draft 3.1 as 802.11r draft 4.0. Having addressed all comments arising from LB87, Task Group r resolves to forward 802.11r draft 4.0 to the working group for the purpose of conducting a 15-day working group recirculation letter ballot. The purpose of the working group recirculation letter ballot is to forward the draft to sponsor ballot. –The text of the motion to be presented to the working group will be “Move to authorize a 15- day Working Group Recirculation Letter Ballot of 802.11r draft 4.0, asking the question “Should the 802.11r draft 4.0 be forwarded to sponsor ballot?” By: Bill Marshall Second: Journi Malinen Discussion: • None. Result: Yes – 9; No – 1; Abstain – 3. Motion passes.

• Discussion on doing a security review of IEEE 802.11r • This review would be going to non-IEEE 802.11 members. • We can choose who reviews the draft; we don’t need to include their names in the motion. • The comments of the reviewers will be submitted along with the body of the IEEE 802.11 working group.

MOTION at 1:50pm: Move to request the IEEE 802.11 Working Group Chair to allow the latest version of the draft of IEEE 802.11r to be distributed to selected security experts for the purposes of an external security review of the draft. By: Dorothy Stanley Second: Journi Malinen Discussion: • Should we kick start the process now, or with a future draft. • The motion should be more specific. • We can have a separate discussion on when and to who will review the draft. Result: Yes – 13; No – 0; Abstain – 1. Motion passes.

• Thank you to everyone who participated in this comment resolution process, with special thanks to Bill Marshall for his efforts.

• Discussion on document 11-06/1867r0 by Russ Housley • There is a requirement that is not met for PSK. An Nonce is required to generate the PMK-R0. • Given the work done in CAPWAP, there is a security relationship between the R0 and R1 Key Holders • Does the group need to explicitly define the relationship between the R0 and R1 Key Holders? No.

Submission page 22 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/1690r1

• It would be appropriate for this body define the requirements on the relationship between the R0 and R1 Key Holders; and the conditions under which keys were transferred. • The STA could authorise keys to be pushed from the R0 to R1 Key Holders. • A two party protocol would be sufficient to address these requirements. A three party protocol would definitely address the requirements. • There are advantages of a three party protocol solution over a two party protocol. • We need to decide the right thing to do. We have to make sure that there are no design deficiencies. • There has been no argument for why we should not use two party protocol or three party protocols to resolve security issues in TGr • The protocol between the key holders will need to be an IP protocol. There would have to be tunnelling between the STA and the other components participating in IEEE 802.11r. • This represents the minimal requirements for IEEE 802.11r. • We should use EAP channel binding to fix both IEEE 802.11i and IEEE 802.11r. • If the R1KeyHolder receives a new PMK-R1, the new PMK-R1 replaces its existing PMK-R1. • Each party that has the PMK-R1 knows the other parties who posess the PMK-R1. • In deriving a PMK-R1, the STA knows which R1KeyHolder holds the PMK-R1. This condition occurs at the point where the STA uses the PMK-R1. • The STA can always pre-calculate these keys. The R0KeyHolder can always pre- calculate these keys. • The STA trusts the R0KeyHolder to pass a PMK-R1 to a trusted R1KeyHolder. • The STA cannot prove the trust relationship until it completes the Fast Transition.

• Adjourn for the week.

Submission page 23 Michael Montemurro

November 2006 doc.: IEEE 802.11-06/nnnnr0

IEEE P802.11 Wireless LANs

November 2006 Mesh Minutes

Date: 2006-11-28

Author(s): Name Company Address Phone email 603 March Road, BelAir Stephen G. Rayment Kanata, ON, Canada +1 (613) 254-7070 [email protected] Networks K1S 1W1

Abstract Minutes of the meeting of the IEEE 802.11 ESS Mesh Networking Task Group held at the Hyatt Regency Hotel in Dallas, TX , USA, from November 14th to 16th, 2006, under the TG Chairmanship of Donald Eastlake III of Motorola Laboratories. Minutes were taken by Stephen Rayment. The Minutes were reviewed and edited by Donald Eastlake III. The final Agenda for the meeting is in document number 11-06/1568r7. The Closing Report is in document 11-06/1879r0.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Contents

Minutes ...... 3 Detailed Record ...... 10

Submission page 2 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Minutes

Session I, Tuesday November 14th, 10:30-12:30, Hyatt Regency - Reunion E Room

The session was called to order at 10:31 by Donald Eastlake III - Chair, Stephen Rayment - Recording Secretary.

The Chair outlined the Agenda for the meeting, as contained in document 11-05/1568r4, including a review of the accomplishments from the Adhoc meeting held on Monday November 13th.

The Chair reminded everyone to use the on-line automated Attendance System and made numerous Miscellaneous Announcements as shown in the agenda.

The Chair reviewed the IEEE 802 and 802.11 IPR Notice Procedure as shown in slide 10, the Policies and Procedures on Intellectual Property as shown in slide 11, and Inappropriate Topics for IEEE TG meetings as shown in slide 12. There were no responses from members regarding IPR or any patent or patent application of which the 802.11 WG Chair should be made aware.

Presentation 11-06/1770r0 was added to the list of documents to be presented.

There were no objections to the Agenda so amended, hence it was approved by unanimous consent.

The September 2006 Meeting Minutes, 11-06/1565r0, were approved by unanimous consent

The Teleconference Minutes listed below were approved by unanimous consent; 4 October 2006, 11-06/1569r0 18 October 2006, 11-06/1602r0 8 November 2006, 11-06/1676r0

The Ad Hoc Meeting Minutes listed below were approved by unanimous consent; 2-3 November (Munich) Ad Hoc Meeting Minutes, 11-06/1652r1 13 November (Monday) Ad Hoc Meeting Minutes, 11-06/1763r0

The Chair then reviewed the TG Process using document 11-06/1753r1. There were no comments or discussion.

The Editor gave an update on the status of the D0.04 Draft using the Comment Resolution spreadsheet, document 11-06/602r17.

The Chair outlined that the resolution for CID 69, 70, 71 and 208 adopted in September had been deemed by the CAC to be outside the scope of the TGs PAR and would be reserved.

Moved, to adopt D0.04 with the above noted comment retraction Moved: Mathilde Benveniste Second: Guenael Strutt For: 26 Against: 1 Abstain: 2 Motion passes

Presentation: “Interworking with Multi Portals in Wireless Mesh Network”, Yonggyu Kim et al, 11- 06/1678r1

Straw Poll

Submission page 3 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Are you in favour of the multi-domain mesh network to resolve interworking problems in multi portal configuration? Yes: 7 No: 8 Abstain: 20 Are you in favour of the single-domain mesh network to resolve interworking problems in multi portal configuration? Yes: 1 No: 6 Abstain: 34

Presentation: “Editorial Cleanup of Clause 5.2.7”, W. Steven Conner, document 11-06/1637r1 Request to defer vote until afternoon session. Agreed unanimously.

Presentation: “RFI Update Munich Meeting”, Guenael Strutt, document 11-06/1629r2 Presenter indicated the HWMP document will be submitted tomorrow.

Presentation: “Problems with CCF”, Mathilde Benveniste, 11-06/1777r0

Straw Poll Are you concerned about the inclusion of CCF in the Draft? Yes: 19 No: 4 Abstain: 18

Straw Poll Should we expect to go to Letter Ballot by the end of the week? Yes: 24 No: 7 Abstain: 11

The Chair recessed the session at 12:29

Session II, Tuesday November 14th, 16:00-18:00, Hyatt Regency – Reunion E Room

The Chair convened the session at 16:04

The Chair reviewed the status of the meeting so far and the topics for this session using document 11- 06/1568r5

Presentation “Secure Mesh Formation”, Harkins et al, 11-06/1092r2

Moved, to instruct Editor to incorporate the changes in 11-06/883r2 into the Draft Moved: Dan Harkins Second: Christian Kuhtz For: 5 Against: 14 Abstain: 15

Straw Poll Would you support comminus as an optional authentication method? Yes: 19 No: 6 Abstain: 19

Presentation: “Update to Efficient Mesh Security and Link Establishment” Walker, Braskich, et al, 11- 06/1625r1 (presented by Jesse Walker) Overview proposal found in document 11-06/1470r3

Moved, to accept the submission contained in document 11-06/1470r3 and instruct the Editor to incorporate the changes resolving CIDs: 120, 121, 122, 199, 236, 237, 239, 240, 243, 244 Moved: W. Steve Conner Second: Ariel Sharon For: 30 Against: 8 Abstain: 6 Motion passes

Submission page 4 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Moved, to instruct the Editor to incorporate the changes in document 11-06/1637r1 into the Draft as the resolution of CID 256. Moved: Steve Conner Second: Guido Hiertz For: 29 Against: 0 Abstain: 0 Motion passes

Request to add item 11-06/1778 and document 11-06/1787 and 11-06/1797 to tomorrow’s agenda. There were no objections.

The Chair recessed the session at 17:49

Session III, Wednesday November 15th, 13:30-15:30, Hyatt Regency – Reunion E Room

The Chair convened the session at 13:33

The Chair reviewed the Agenda, using document 11-06/1568r6. Request was made to add document 11- 06/1822r0.

The chair reminded all to use the On-line Attendance System.

Presentation: “HWMP Specification Update”, Guenael Strutt, 11-06/1800r0

Moved, to accept resolution described in 11-06/1778r1 and instruct the Editor to replace clause 11A.4 in Draft D0.04 resolving CIDs 168, 169, 170, 171, 173, 174, 175, 176, 178, 179, 181, 185, 186, 188, 189, 190, 191 and 192. Moved; Guenael Strutt Second: Jan Kruys For: 29 Against: 0 Abstain: 6 Motion passes

Presentation: “Update on Interworking”, Jan Kruys, 11-06/1797r1

Moved, to accept document 11-06/1787r0 as text for interworking in the draft TGs standard and instruct the Editor to incorporate the document in the current Draft. Moved: Jan Kruys Second: Joseph Kim For: 28: Against: 0 Abstain: 4 Motion passes

Presentation: “Some thoughts on broadcast frame delivery in mesh”, Kazuyuki Sakoda, 11-06/1619r0 and document “The definition of broadcast in mesh”, Kazuyuki Sakoda, 11-06/1732r0

Moved, to direct the Editor to incorporate the changes in 11-06/1732r0 into the Draft Moved: Kazuyuki Sakoda Second: Dee Denteener Motion withdrawn without objection, will try to re-introduce tomorrow.

Presentation: “Concerns regarding CCF”, Michelle Gong et al, 11-06/1716r4

Moved, to direct the Editor to remove all references in the Draft to CCF according to slide 13 of 11- 06/1716r4 Moved: Michelle Gong Second: Mathilde Benveniste

Moved, to call the question Moved: Andrew Myles Second: Jesse Walker

Submission page 5 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Objections were raised, so a vote was taken For: 25 Against: 16 Motion to call the question fails.

Questions/Comments continued…

Moved, to call the question Moved: Guido Hiertz Second: Andrew Myles For: 48 Against: 3 Abstain: 0

Motion to call the question passes, vote on the main motion. For: 30 Against: 18 Abstain: 8 Motion fails (< ¾)

Presentation: “Minor Update to Clause 11A.1.5 for Draft Consistency”, W. Steve Conner, 11-06/1815r0

Moved, to instruct the Editor to add text in slide 3 of the document to the end of Clause 11.A.1.5.1 Moved: W. Steve Conner Second: Jesse Walker For: 18 Against: 0 Abstain 6 Motion passes

Presentation: “Resolution of informal comments received May 1, 2006”, Hrishikesh Gossain, 11- 06/1822r0

Moved, to adopt the comment resolutions in 11-06/1822r0 and direct the Editor too incorporate them into the Draft Moved to: Guido Hiertz Second: Kazuyuki Sakoda

Moved, to direct the Editor to produce a Draft D0.05 Moved: Steve Conner Second: Guido Hiertz There were no objections, adopted by unanimous consent

The Chair recessed the session at 15:27.

Session IV, Thursday November 16th, 08:00-10:00, Hyatt Regency – Reunion E Room

The Chair convened the session at 08:05.

The Chair requested that the session be recessed for 15 minutes to allow Draft D0,05 to be uploaded to the server. There were no objections.

The Chair reconvened the session at 08:31.

The Chair reviewed the progress of the session so far using Agenda document 11-06/1568r7.

The Chair recommended against further changes to the Draft at this stage, given the time left for the TG to review.

The movers of the last Motion from yesterday (on document 11-06/1822r0) agreed to withdraw it (until a future session).

Believing that the 802.11s Draft D0.05 satisfies all 802.11 WG rules for letter ballot,

Submission page 6 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Moved, to request the 802.11 Working Group to renumber 802.11s Draft D0.05 as D1.0 and authorize a 30-day Letter Ballot asking the question “Should 802.11s Draft D1.0 be forwarded to Sponsor Ballot” Moved: Steve Conner Second: Erik Schylander For: 31 Against: 11 Abstain: 8 No request to take a standing vote Motion fails 73.8%

Previously withdrawn motion (on document 11-06/1822r0) was brought up: Moved: Guido Hiertz Second: Kazuyuki Sakoda For: 38 Against: 0 Abstain: 7 Motion passes

Request to bring up a new motion to address several open comments. Chair asked those with existing comment resolutions already on the Agenda if they objected – no objections.

Moved, to remove CCF from the Draft resolving CIDs 22, 72, 73, 74, 75, 76, 77, 79, 123, 124, 125, 126, 128, and 129. Moved: Mathilde Benveniste Second: Jorjeta Jetcheva Speech in favour of motion using Presentation: “Problems with CCF”, Benveniste, 11-06/1771r1

Moved to amend motion to include text on slide 13 of 11-06/1716r4 Moved: Bob O’Hara Second: Guenael Strutt

Point of order - this Motion failed yesterday, this is improperly bringing up same topic again.

The Chair ruled the Motion in order even though it made the same technical change on the grounds that it included resolution of many additions comments, that the text was changed so that it referred to Draft D0.05 rather than to Draft D0.04, and that there had been substantial progress in votes and debate since this technical change was previously considered.

The decision of the Chair was appealed and the appeal seconded.

Moved, to call the question on the appeal. Moved: Malik Audeh Second: Dan Harkins For: 37 Against: 8 Vote on sustaining the Chair’s ruling under appeal For: 42 Against: 3 There was a call for a recount: For: 33 Against: 12 Chair: It appears that the negative votes in one half of the room had been erroneously added to the positive votes when the first count was held. It is the belief of the chair that the actual two votes were identical. Ruling of the Chair is sustained. Motion is in order.

Mover agreed with the change text provided by the Seconder which editorially updated to correspond with Draft D0.05.

Moved, to Amend the Motion using text provide by the Seconder, specifically to read as follows: Moved, to remove CCF from the TGs draft D0.05 by the following changes - Page 4: remove lines 15, 16, 17 - Page 5: remove line 5 Submission page 7 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

- Section 7.1.3.1.2: page 13, Table 1, remove RTX/CTX type - Section 7.2.1.9: remove the section - Section 7.2.1.10: remove the section - Section 7.3.2.36: page 23, Figure s15 and Table s2, remove “Multi-channel capability” element. Page 23, remove line 27 to line 6 (page 24) and Figure s19 - Section 9.14: remove the section resolving CID 22, 72, 73, 74, 75, 76, 77, 79, 123, 124, 125, 126, 128,129.

As the scheduled time had arrived, the Chair recessed the session at 10:00.

Session V, Thursday November 16th, 10:30-12:30, Hyatt Regency – Reunion E Room

The Chair convened the session at 10:31

The Chair reminded all to use the online Attendance System

Debate on the Amendment on the floor from the previous session… There was no objection to the Amendment which was adopted by unanimous consent.

Further debate on the Motion as amended

Moved, to call the question Moved: Anil Sankwala Second: Many!! No objections For: 45 Against: 14 Abstain: 7 Motion as amended passes

Editor will provide updates resulting from the two motions into Draft D0.06 shortly to the Chair

Any objection to directing the Editor to make these changes? Discussion ensued…

Moved, to direct the Editor to produce a Draft D0.06 incorporating the changes adopted thus far today. Moved: Bob O’Hara Second: Mathilde Benveniste For: 32 Against: 7 Abstain: 8 Motion passes

The Chair requested to recess the session for ½ hour to allow upload of Draft. There were no objections.

The Chair reconvened the session at 11:58

The Chair recognized that Agenda hadn’t been formally modified today to insert the Motions on CCF and approving Letter Ballot and apologized to presenter Kazuyuki Sakoda.

There were no objections to changing the Agenda to reflect these changes.

Draft D0.06 is now on the server.

Believing that the 802.11s Draft D0.06 satisfies all 802.11 WG rules for letter ballot, Moved, to request the 802.11 Working Group to renumber 802.11s Draft D0.06 as D1.0 and authorize a 30-day Letter Ballot asking the question “Should 802.11s Draft D1.0 be forwarded to Sponsor Ballot”

Submission page 8 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Moved: Ariel Sharon Second: Jan Kruys

Comment, the link to clean version appears to be broken on the server. The Chair recessed again to check the status. There were no objections. The link was repaired (problem due to a filename error)

The meeting was re-convened. For: 38 Against: 3 Abstain: 5 Motion carries

Presentation: “TGs Process November”, Eastlake, 11-06/1753r2

In the presentation, it was proposed to hold a teleconference, mostly to review the Agenda of the January meeting, at 5PM on Wednesday 3 January 2007.

It was noted that a conflict exists with the Wi-Fi Alliance Mesh Marketing Group at same time. Can it be moved? Suggested the Chair follow-up with the head of that Wi-Fi Alliance group.

Proposed to move the teleconference to 8AM EST. Strawpoll 8AM: 5 5PM: 17 Unanimous consent for teleconference at 5PM Wednesday 3 January 2007.

The presentation also proposed to pre-approve an adhoc meeting between the January and March 2007 meetings, possibly 6-8 February.

Offers were made to hold the adhoc in Hillsboro Oregon, Munich Germany, Schaumberg Illinois or Eindhoven Netherlands. Strawpoll Hillsboro: 12 Munich: 5 Schaumberg: 9 Eindhoven: 10 Strawpoll Hillsboro: 14 Schaumberg: 6 Eindhoven: 10 Strawpoll Hillsboro: 16 Eindhoven: 11 Hillsboro Oregon is chosen by elimination

Moved, to pre-approve an ad hoc meeting in Hillsboro Oregon, between the January and March 2007 meetings, 6-8 February, for comment resolution. Moved: Steve Conner Second: Kazayuki Sakoda There were no objections, Motion approved by unanimous consent

The chair pointed out that, although there were additional presentations on the agenda list, there was insufficient time remaining.

The Chair adjourned the session sine die at 12:27

Submission page 9 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Detailed Record

Session I, Tuesday November 14th, 10:30-12:30, Hyatt Regency - Reunion E Room

The session was called to order at 10:31 by Donald Eastlake III - Chair, Stephen Rayment - Recording Secretary.

The Chair outlined the Agenda for the meeting, as contained in document 11-05/1568r4, including a review of the accomplishments from the Adhoc meeting held on Monday November 13th.

The Chair reminded everyone to use the on-line automated Attendance System and made numerous Miscellaneous Announcements as shown in the agenda.

The Chair reviewed the IEEE 802 and 802.11 IPR Notice Procedure as shown in slide 10, the Policies and Procedures on Intellectual Property as shown in slide 11, and Inappropriate Topics for IEEE TG meetings as shown in slide 12. There were no responses from members regarding IPR or any patent or patent application of which the 802.11 WG Chair should be made aware.

Presentation 11-06/1770r0 was added to the list of documents to be presented.

There were no objections to the Agenda so amended, hence it was approved by unanimous consent.

The September 2006 Meeting Minutes, 11-06/1565r0, were approved by unanimous consent

The Teleconference Minutes listed below were approved by unanimous consent; 4 October 2006, 11-06/1569r0 18 October 2006, 11-06/1602r0 8 November 2006, 11-06/1676r0

The Ad Hoc Meeting Minutes listed below were approved by unanimous consent; 2-3 November (Munich) Ad Hoc Meeting Minutes, 11-06/1652r1 13 November (Monday) Ad Hoc Meeting Minutes, 11-06/1763r0

The Chair then reviewed the TG Process using document 11-06/1753r1. This included a Procedure for Resolving Drafts / Developing Submissions as shown in slide 6. The Motion passed in Melbourne to direct certain individuals who lead adhoc teams was deemed inappropriate by the 802 WG Chair. (This motion was the last motion prior to adjournment at the end of the TGs September meeting.) The projected schedule as shown in slide 8 projects a Letter Ballot authorized by the TG at this meeting. It also highlighted the allowed activity between meetings as shown in slide 12, much of which depend in whether the TG goes to LB at this meeting. There were no comments or discussion.

The Editor gave an update on the status of the D0.04 Draft using the Comment Resolution spreadsheet, document 11-06/602r17. Fifteen comments were voted to close in Melbourne. 181 of 283 comments collected in May have been closed. The remaining comments have been classified by priority. 31 comments are Defer-NS (Need Submission) indicating relatively high priority, 69 are Defer-RPS (Reconsider Pending Submission) the rest are Defer-TG (needs TG decision). D0.04 clean (P802.11s) and redline (document 11-06/1605) has been on the members area of the server since October. Changes are summarized in the document history.

The Chair outlined that the resolution for CID 69, 70, 71 and 208 adopted in September had been deemed by the CAC to be outside the scope of the TGs PAR and would be reserved.

Submission page 10 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Moved, to adopt D0.04 with the above noted comment retraction Moved: Mathilde Benveniste Second: Guenael Strutt Questions • How did CAC come to know of this? There was email on 802.11 WG Reflector highlighting that this was a PHY change and suggestion that it was out of scope. • Good to identify these issues sooner rather than later. • Are there minutes of the CAC with details? This CAC meeting held Sunday evening November 12, chaired by Harry Worstell and Al Petrick, suggest you contact Harry is you have questions on this decision. For: 26 Against: 1 Abstain: 2 Motion passes

Presentation: “Interworking with Multi Portals in Wireless Mesh Network”, Yonggyu Kim et al, 11- 06/1678r1 Questions/Comments… • How dynamic will this be in the face of portal loss, any difference between the 2 model in this regard? Will cover whole of mesh network – will be one group – in both cases both solutions use same algorithm. • Broadcast frame – who generates the sequence number. Each MP sets it sequence number to maximum will be dropped at boundary. • So MP will drop? Broadcast frame will come again and again. • Will intermediate MPs think they have already received and drop? • Incrementing the maximum? There is only one Maximum. • Can’t distinguish multiple copies of the same broadcast flood? Yes – solve using sequence number for each host. • Both portals must generate the same sequence number – hard to co-ordinate Yes. • How does MP know which group he belongs to? See page 9 – each MP tries to send Portal Announce message, use hop count

Straw Poll Are you in favour of the multi-domain mesh network to resolve interworking problems in multi portal configuration? Yes: 7 No: 8 Abstain: 20 Are you in favour of the single-domain mesh network to resolve interworking problems in multi portal configuration? Yes: 1 No: 6 Abstain: 34

Presentation: “Editorial Cleanup of Clause 5.2.7”, W. Steven Conner, document 11-06/1637r1 Questions/Comments… • Request to defer vote until afternoon session. Agreed unanimously.

Presentation: “RFI Update Munich Meeting”, Guenael Strutt, document 11-06/1629r2 Presenter indicated the HWMP document will be submitted tomorrow. There were no Questions/Comments.

Presentation: “Problems with CCF”, Mathilde Benveniste, 11-06/1777r0 There were no Questions/Comments.

Submission page 11 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Straw Poll Are you concerned about the inclusion of CCF in the Draft? Yes: 19 No: 4 Abstain: 18

Straw Poll Should we expect to go to Letter Ballot by the end of the week? Yes: 24 No: 7 Abstain: 11

The Chair recessed the session at 12:29

Session II, Tuesday November 14th, 16:00-18:00, Hyatt Regency – Reunion E Room

The Chair convened the session at 16:04

The Chair reviewed the status of the meeting so far and the topics for this session using document 11- 06/1568r5

Presentation “Secure Mesh Formation”, Harkins et al, 11-06/1092r2 Questions/Comments • This is between two MPs across a single link? Yes. • Slide 11 – 802.11i doesn’t offer PFS – what if attacker obtains PSK here? CCMP key based on results of Diffie-Hellman exchange, would also have to break it. • If I have that key? PFS is that you can’t decrypt from earlier or future runs, which you can in 802.11i. • PFS means all past sessions are still secure, but future aren’t. • Slide 7 – no need for external AS – does author envisage use more often with certificates? Get CRLs once you have connection. • Certificate, how is it carried? In Beacons and Probe Requests/Responses. • One IE to carry a cert? Typical X509v3 certificates are 4K bytes! Good point. • Relationship with Pure Link Establishment? None. • Build around current protocol? Yes. • Peer link happens first? No – this is done using 802 authentication frames, association happens after comminus and can thus be protected. • Who initiates first? Either. • Slide 12 – GTKs in last two messages – how do you confirm delivery of keys? Assumed reliable medium, could add logic to retransmit message 3. • Occurs before association request? Goes on data packets? No it’s an 802.11 authentication exchange. Today with set to open-auth say authenticate me, then association request, then EAPOL start. Don’t do open here, do comminus, then use key to protect subsequent association request.

Submission page 12 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

• Either side can be the originator, what if both sides send message at same time? Super-ordinate is a term for initiating protocol. Need to add a statement that after exchanging, side with highest MAC wins. • Did you model this in the reference implementation? No, you’d end up with two authenticated CCMPs, throw away one with exchange initiated by lowest MAC address

Moved, to instruct Editor to incorporate the changes in 11-06/883r2 into the Draft Moved: Dan Harkins Second: Christian Kuhtz Question • Is this optional? Doesn’t remove 802.1Z or 802.11i, removes PSK, and adds this as mandatory authentication step. For: 5 Against: 14 Abstain: 15

Straw Poll Would you support comminus as an optional authentication method? Yes: 19 No: 6 Abstain: 19

Presentation: “Update to Efficient Mesh Security and Link Establishment” Walker, Braskich, et al, 11- 06/1625r1 (presented by Jesse Walker) Overview proposal found in document 11-06/1470r3 Questions/Comments • We have various mesh usage models, which one do you see this being used for? Haven’t analyzed – will cover 80%, some consumer, most of enterprise and public, this is just a framework, expect changes. • Consumer? Yes, PSK models are inappropriate, need this or nothing. • Any implementation detail yet? Have done state machine validation. • Have you presented yet results of that yet? No, will present at appropriate time. • Clarification on slide 10 – no process to ensure supplicant has to match key with distributor, implicit assumption of trust For initial contact, have to follow entire 802.11i model, including EAP limitations. • Are any parts optional or separable? Don’t have to implement all 3 boxes on slide 10, could collapse into one. Slide 11 might be optional. Haven’t defined optional vs. mandatory parts yet. Signalling needn’t happen over air. Currently mandatory. EAP transport message is optional. • Slide 11 – when is it necessary to obtain derived key? Depends on path existing to MKD. Will depend on how network is deployed. • In 3 party key distribution you need authorization, does this need it? Yes. Could adapt proposal to adopt that feature. • Mandatory? Everything except back end link layer protocol. • Role determination? To work through race conditions you have to deal with termination. Will give presentation on this. • Addresses shortcoming of AS requirement. Two entities getting together, neither has contact to AS, would they simplify to simple PSK Auth and Supp? Provisions provided in document as a start. Submission page 13 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

• Slide 27 – state machines have problems with open and close, what about multiple attempts? There are instance identifiers. • How do they handle the case of two MPs coming and going? How rapidly? Haven’t simulated yet. • Two types of state machines. Got all correct first. Now need to deal with contentions and varying signals. • MKD becomes such by saying he is – is that acceptable? We don’t spec how selected – administrative decision. MKD will have to authenticate himself somehow. • MKD does not have to be Mesh Portal? No. MKD to AS communication is outside scope. AS can be inside the mesh • If it’s outside and not a portal, do you know a-priori? This proposal doesn’t address that. Each of MPs must have unambiguous way to authenticate this one device. Not part of proposal. • Proposal currently says MKD has access to AS, acts as proxy AS. • This can’t bootstrap, requires an MKD. • Typically MKD is at a Portal, other bootstrapping approaches allowed. • If MKD not at Portal, must you provide physical security? Yes. It needs to be a “protected” node, equivalent to a RADIUS server.

Moved, to accept the submission contained in document 11-06/1470r3 and instruct the Editor to incorporate the changes resolving CIDs: 120, 121, 122, 199, 236, 237, 239, 240, 243, 244 Moved: W. Steve Conner Second: Ariel Sharon • Introduces single point of failure into mesh, not acceptable in large deployment. • POL model is derived using a nonce, MA can’t determine, key distribution method doesn’t work. MA obtains info when Supplicant contacts. • 802.11r put a lot of work into 3 part security protocol, this requires such a thing, hard to get. • Sort it out later? Premature to put whole thing in. Speaking in favour • This is a framework to get to LB, objective was to get consensus in this update to proposal • Addresses many shortcomings, eg. two way handshake. • Was introduced in Melbourne, reviewed at Munich adhoc For: 30 Against: 8 Abstain: 6 Motion passes

Moved, to instruct the Editor to incorporate the changes in document 11-06/1637r1 into the Draft as the resolution of CID 256. Moved: Steve Conner Second: Guido Hiertz For: 29 Against: 0 Abstain: 0 Motion passes

Request to add item 11-06/1778 and document 11-06/1787 and 11-06/1797 to tomorrow’s agenda. There were no objections.

The Chair recessed the session at 17:49

Session III, Wednesday November 15th, 13:30-15:30, Hyatt Regency – Reunion E Room

Submission page 14 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

The Chair convened the session at 13:33

The Chair reviewed the Agenda, using document 11-06/1568r6. Request was made to add document 11- 06/1822r0.

The chair reminded all to use the On-line Attendance System.

Presentation: “HWMP Specification Update”, Guenael Strutt, 11-06/1800r0 Questions/Comments • Is there a presentation describing protocol? See Tutorial document on IEEE 802 homepage.

Moved, to accept resolution described in 11-06/1778r1 and instruct the Editor to replace clause 11A.4 in Draft D0.04 resolving CIDs 168, 169, 170, 171, 173, 174, 175, 176, 178, 179, 181, 185, 186, 188, 189, 190, 191 and 192. Moved; Guenael Strutt Second: Jan Kruys For: 29 Against: 0 Abstain: 6 Motion passes

Presentation: “Update on Interworking”, Jan Kruys, 11-06/1797r1 Questions/Comments • Protocol specifies what? Portal announcement messages and what nodes are to do. • Does it modify messages at each hop? Ask for delivery and desirable if metric is updated. • Better to break delivery and how it’s done? • Can portal announcement be carried in another protocol? Yes. • Difference between r3 and r2? One line – have to properly configure portals so they do announcement. • Is this a guideline or spec? Neither because outside of scope! • Posted when? 10:38AM

Moved, to accept document 11-06/1787r0 as text for interworking in the draft TGs standard and instruct the Editor to incorporate the document in the current Draft. Moved: Jan Kruys Second: Joseph Kim For: 28: Against: 0 Abstain: 4 Motion passes

Presentation: “Some thoughts on broadcast frame delivery in mesh”, Kazuyuki Sakoda, 11-06/1619r0 and document “The definition of broadcast in mesh”, Kazuyuki Sakoda, 11-06/1732r0 Questions/Comments • Resolution also covers CID 50, counter proposes that we first need a clear definition of broadcast, need independent forwarding of management frames, dedicate 11.8.2.5 to forwarding of management. Suggestion to combine this resolution and the Chair’s (11-06/1801). Valid, couldn’t find proper place. • Is location the only issue? Location PLUS types of broadcasting. • Better to put something in Draft before going to Letter Ballot.

Submission page 15 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Moved, to direct the Editor to incorporate the changes in 11-06/1732r0 into the Draft Moved: Kazuyuki Sakoda Second: Dee Denteener Questions/Comments continued • “Two types of broadcasting mechanism” defining two types is confusing, intent to provide background on different configuration given frame formats, agree in long run good to combine with mechanisms, for now this is helpful for new readers, make this informative sub-clause at this stage, refine and make normative later. • How can informative text have “shall”? • Would it help to change “type” to “scope”? Delete word “mechanism”? Motion withdrawn without objection, will try to re-introduce tomorrow.

Presentation: “Concerns regarding CCF”, Michelle Gong et al, 11-06/1716r4 Questions/Comments • What about bottleneck of common channel? Only one pair can transmit. Longer the TXOP higher the inefficiency. Agree. • Four concerns, three can be resolved? Maybe, but no resolution for co-existence. • Co-existence is real. Same problem in 802.11n Different 802.11n receive can sense adjacent channel, so if on primary can sense on secondary. Here all channels are orthogonal, can’t sense. • Assumed work in 802.11n could feed back to 802.11s Co-existence is biggest issue in 802.11n, staw poll in 802.11n to eliminate 40MHz. No, TGn has not achieved consensus, take care moving work from one TG to another until it is complete.

Moved, to direct the Editor to remove all references in the Draft to CCF according to slide 13 of 11- 06/1716r4 Moved: Michelle Gong Second: Mathilde Benveniste Questions/Comments • Many concerns on CCF have been addressed, not a show stopper. • Discussion came up in Melbourne, only resolution proposed was to lower threshold, was found out of scope by CAC, not allowed to use reflector to discuss, will cost a lot of no votes. • CCF good protocol by itself, hard to co-exist with CSMA/CA. • Focus on this motion, CAC did not say can’t use reflector. • TGs at last meeting instructed particular groups to post to reflector – that was ruled to be out of order because they weren’t formal groups, didn’t say what you can post. • Two issues; 1. Resolution of comment related to CCF, which required making a change in threshold. 2. Proper use of reflectors.

Moved, to call the question Moved: Andrew Myles Second: Jesse Walker Objections were raised, so a vote was taken For: 25 Against: 16 Motion to call the question fails.

Questions/Comments continued… • In favour – can’t modify PHY, only recourse is to remove CCF, otherwise all other networks in vicinity affected.

Submission page 16 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

• Against – consumer electronics wants this feature, removing it now will limit abilities to experiment. Current Draft is framework, doesn’t excludes multi-channel, motion does not instruct Editor to remove, but CCF is not solution. • Against – discussion started Jan 2005, became simple mechanism where single device can take advantage of multi channels, so you have to switch, do you think we should enable this? Numbers depend on assumption, simulation showed scenarios in which CCF gives gain. Comments have continued to be resolved. Continue to explore solutions. Haven’t had time to respond to CAC concern. • In favour – have discussed for over a year, without resolution, can’t defend these features to WG.

Moved, to call the question Moved: Guido Hiertz Second: Andrew Myles For: 48 Against: 3 Abstain: 0 Motion to call the question passes, vote on the main motion. For: 30 Against: 18 Abstain: 8 Motion fails (< ¾)

Presentation: “Minor Update to Clause 11A.1.5 for Draft Consistency”, W. Steve Conner, 11-06/1815r0 Moved, to instruct the Editor to add text in slide 3 of the document to the end of Clause 11.A.1.5.1 Moved: W. Steve Conner Second: Jesse Walker For: 18 Against: 0 Abstain 6 Motion passes

Presentation: “Resolution of informal comments received May 1, 2006”, Hrishikesh Gossain, 11- 06/1822r0 Moved, to adopt the comment resolutions in 11-06/1822r0 and direct the Editor too incorporate them into the Draft Moved to: Guido Hiertz Second: Kazuyuki Sakoda Questions/Comments • Four hour rule? Document posted at 11:34 today. • Must postpone motion to tomorrow’s session.

Moved, to direct the Editor to produce a Draft D0.05 Moved: Steve Conner Second: Guido Hiertz There were no objections, adopted by unanimous consent

The Chair recessed the session at 15:27.

Session IV, Thursday November 16th, 08:00-10:00, Hyatt Regency – Reunion E Room

The Chair convened the session at 08:05.

The Chair requested that the session be recessed for 15 minutes to allow Draft D0,05 to be uploaded to the server. There were no objections.

The Chair reconvened the session at 08:31.

The Chair reviewed the progress of the session so far using Agenda document 11-06/1568r7.

The Chair recommended against further changes to the Draft at this stage, given the time left for the TG to review.

Submission page 17 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Discussion ensued… • There were comments in favour of resolving as many comments as possible • The Draft must be technically complete – can that be the case if there are outstanding issues? Yes, there are no place holders or missing sections. • Submissions do include changes. We have categorized changes important before Letter Ballot, these have been addressed. • There were many comments yesterday that elements were truly broke, Chair was asked for his opinion. Chair responded one feature will work well in some circumstances not in others, it’s optional. • Numerous comments are controversial, can’t go to Letter Ballot. • Didn’t only have concerns yesterday, others were in favour of proceeding, discussion was around an optional feature. • Each comment was qualified in urgency by ad hoc groups, arguments about CCF not valid. • If comment is outstanding and a proposal to address exists, proceed with proposal.

The movers of the last Motion from yesterday (on document 11-06/1822r0) agreed to withdraw it (until a future session).

Discussion continued… • If we don’t have all comments resolved we can’t proceed to Letter Ballot. No, these aren’t formal comments, not real Letter Ballot comment, so there is no procedural reason we cannot go to letter ballot. Very small subset of WG is involved so far, would be helpful to get more guidance from the wider group. • Is the Draft sufficiently mature to not waste the time of the broader WG membership? Think it’s complete but there will always be issues until ratification. Editor responded the Draft is not as refined as required for Sponsor Ballot. Sufficient to get feedback from WG in Letter Ballot. • Important to have a complete specification. Editor believes it is. Disagreement is only about features to add. Doesn’t dictate completeness. Letter Ballot may help solve some of the disagreement. If TGs goes to Letter Ballot now, timeline allows closure before January. If delayed, Letter Ballot will happen in parallel with two other TG’s. Proceeding now will facilitate most attention on the Draft Chair said group decides when to proceed. Also it is dangerous to project when other TG’s go to Letter Ballot. • Are concerned about getting a complete review as we are a small group? We have received feedback from the WG about a serious problem. Risk of having PAR withdrawn due to lack of backward compatibility • Yes, Draft is well written, but does it address controversial issues? • Some other groups going to Letter Ballot is not relevant to us. Problem for other groups also. • Up to TG to decide for itself. We have a Draft the TG thinks is good enough. Why change? Chair said we only had a strawpoll on going to Letter Ballot. • When will we vote? When Draft is on server. • Straw poll was taken before changes were made to Draft during this session, it may not now be relevant. • Noted that the withdrawn Motion (on document 11-06/1822r0) has nothing to do with yesterday’s discussion (on CCF). • Should it be interpreted that because we had informal review and didn’t addressed all comments, the group has decided which comments are priority, ie. reserves the right to decide which comments matter, doesn’t motivate people to comment.

Submission page 18 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Chair responded, the steps from informal review to Letter Ballot are the same as if LB had failed, group is free to do as it pleases with regard to comments. • In one case had ballot in other did not, chose to respond or not to comments. • Timeliness was not considered a major point, had just asked for Chair’s opinion. • When you do internal review and pick up as much as you can, trying to achieve majority that agrees. When Letter Ballot fails comments are usually reviewed. Just because someone makes comments that are not taken, group may not want to do what is in the comment, feedback to the group as a whole, group doesn’t have to incorporate all comments into Draft. Chair indicated many of comments have been rejected previously. • Draft has been uploaded. • Is strawpoll to go to LB relevant? Possibly not because people were hoping all outstanding comments could have been resolved, haven’t, so strawpoll may not be valid. Chair responded can’t tell what people were hoping. • Chair indicated we could vote now or do other presentations. • The document on the server says version 4 inside. The webpage link is incorrect. Refreshed and it is OK, just a stale copy of webpage. • What about the requirement that the Draft must be technically complete? Chair said completeness does not mean there are no comments or controversies. • Comment resolution process was thorough and has reached the limit of what we can do in the TG. Particularly the issues in the MAC group may not be known to all, but the process they have used was thorough. If we don’t go to Letter Ballot then use more formal process in TG. • Isn’t there a four hour requirement? Chair clarified, no, latest P&P revision states technical changes must be on the server for 4 session hour hours, but no requirements on editorial changes or on the draft itself.

Believing that the 802.11s Draft D0.05 satisfies all 802.11 WG rules for letter ballot, Moved, to request the 802.11 Working Group to renumber 802.11s Draft D0.05 as D1.0 and authorize a 30-day Letter Ballot asking the question “Should 802.11s Draft D1.0 be forwarded to Sponsor Ballot” Moved: Steve Conner Second: Erik Schylander For: 31 Against: 11 Abstain: 8 No request to take a standing vote Motion fails 73.8%

Previously withdrawn motion (on document 11-06/1822r0) was brought up: Moved: Guido Hiertz Second: Kazuyuki Sakoda For: 38 Against: 0 Abstain: 7 Motion passes

Request to bring up a new motion to address several open comments. Chair asked those with existing comment resolutions already on the Agenda if they objected – no objections.

Moved, to remove CCF from the Draft resolving CIDs 22, 72, 73, 74, 75, 76, 77, 79, 123, 124, 125, 126, 128, and 129. Moved: Mathilde Benveniste Second: Jorjeta Jetcheva Speech in favour of motion using Presentation: “Problems with CCF”, Benveniste, 11-06/1771r1 Questions/Comments • Against, PAR does not say about compatibility, mesh doesn’t talk to clients, APs do. Today’s networks don’t use NAV, rely fully on physical carrier sense, and they work • Resolution not complete, should define detailed procedures to modify Draft.

Submission page 19 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

• Chair: Does Editor think the instructions are adequate? Editor: Would prefer more guidance.

Moved to amend motion to include text on slide 13 of 11-06/1716r4 Moved: Bob O’Hara Second: Guenael Strutt

Point of order - this Motion failed yesterday, this is improperly bringing up same topic again. • This deals with resolving specific comments, Motion yesterday only dealt with amending Draft. • Motion addresses comments not addressed yesterday. • Do we keep removing pieces until things get approved??!!

The Chair ruled the Motion in order even though it made the same technical change on the grounds that it included resolution of many additions comments, that the text was changed so that it referred to Draft D0.05 rather than to Draft D0.04, and that there had been substantial progress in votes and debate since this technical change was previously considered.

The decision of the Chair was appealed and the appeal seconded. • Chair noted the previous motion was more specific, did list CIDs. • Need to provide complete details of what needs to be changes, can’t tell what you’re changing. • Motion yesterday included what’s in 11-06/1777, so this is the same as yesterday’s presentation. • All references are good material, doesn’t mean motion shouldn’t be considered. Same resolution cannot be brought up for same comment twice in same meeting, same resolution can be used for different comments. Moved, to call the question on the appeal. Moved: Malik Audeh Second: Dan Harkins For: 37 Against: 8 Vote on sustaining the Chair’s ruling under appeal For: 42 Against: 3 There was a call for a recount: For: 33 Against: 12 Chair: It appears that the negative votes in one half of the room had been erroneously added to the positive votes when the first count was held. It is the belief of the chair that the actual two votes were identical. Ruling of the Chair is sustained. Motion is in order.

Mover agreed with the change text provided by the Seconder which editorially updated to correspond with Draft D0.05.

Moved, to Amend the Motion using text provide by the Seconder, specifically to read as follows: Moved, to remove CCF from the TGs draft D0.05 by the following changes - Page 4: remove lines 15, 16, 17 - Page 5: remove line 5 - Section 7.1.3.1.2: page 13, Table 1, remove RTX/CTX type - Section 7.2.1.9: remove the section - Section 7.2.1.10: remove the section - Section 7.3.2.36: page 23, Figure s15 and Table s2, remove “Multi-channel capability” element. Page 23, remove line 27 to line 6 (page 24) and Figure s19 - Section 9.14: remove the section resolving CID 22, 72, 73, 74, 75, 76, 77, 79, 123, 124, 125, 126, 128,129.

As the scheduled time had arrived, the Chair recessed the session at 10:00.

Submission page 20 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Session V, Thursday November 16th, 10:30-12:30, Hyatt Regency – Reunion E Room

The Chair convened the session at 10:31

The Chair reminded all to use the online Attendance System

Debate on the Amendment on the floor from the previous session… • Yesterday, Michelle’s presentation responded to comments, original motion was out of order, this motion is the same. Have the page and line numbers been checked? Yes, so it refers to Draft D0.05. Also this is different due to CIDs. It has already been judged to be in order. There was no objection to the Amendment which was adopted by unanimous consent.

Further debate on the Motion as amended • Against, because proceeding with CCF in will get valuable input from the whole WG on the CCF option. • In favour, CCF is technically broken, damages co-existence, will stomp over existing networks, leaving in the Draft will be a magnet for comments, give proponents of CCF a way to re-insert in a way that co- exists. • Against, we are precluding outcome of Letter Ballot. • In favour, CCF explicitly breaks carrier sense, violates standard. • Against, CCF is a feature with backing in consumers industry and will serve many usage scenarios, leaving in will attract further contribution. • In favour, we should fix CCF before Letter Ballot. • Against, have tried to address concerns, improvements can be made, thinking no at this stage is premature. • In favour, has been debated for a year. • Against, consumer requirements want this, it is an option, offers good performance in those scenarios. There are also scenarios when it doesn’t make sense, then don’t use it.

Moved, to call the question Moved: Anil Sankwala Second: Many!! No objections For: 45 Against: 14 Abstain: 7 Motion as amended passes

Editor will provide updates resulting from the two motions into Draft D0.06 shortly to the Chair

Any objection to directing the Editor to make these changes? Discussion ensued… • Does 4 hour rule apply? • Yes technical portion, being in Michelle’s previous submission, was on server from yesterday. • But we voted no on Michelle’s motion. • 4 hour doesn’t say how many times it can be voted on. • But doesn’t that mean it was the same motion. No, assembly it was in order, presumably because there were enough non-technical changes. • These are changes to Draft D0.05, so 4 hour rule does not apply. • The technical changes to the Draft are the same, the rest is editorial.

Submission page 21 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Moved, to direct the Editor to produce a Draft D0.06 incorporating the changes adopted thus far today. Moved: Bob O’Hara Second: Mathilde Benveniste For: 32 Against: 7 Abstain: 8 Motion passes

The Chair requested to recess the session for ½ hour to allow upload of Draft. There were no objections.

The Chair reconvened the session at 11:58

The Chair recognized that Agenda hadn’t been formally modified today to insert the Motions on CCF and approving Letter Ballot and apologized to presenter Kazuyuki Sakoda.

There were no objections to changing the Agenda to reflect these changes.

Draft D0.06 is now on the server.

Believing that the 802.11s Draft D0.06 satisfies all 802.11 WG rules for letter ballot, Moved, to request the 802.11 Working Group to renumber 802.11s Draft D0.06 as D1.0 and authorize a 30-day Letter Ballot asking the question “Should 802.11s Draft D1.0 be forwarded to Sponsor Ballot” Moved: Ariel Sharon Second: Jan Kruys

Comment, the link to clean version appears to be broken on the server. The Chair recessed again to check the status. There were no objections. The link was repaired (problem due to a filename error)

The meeting was re-convened. For: 38 Against: 3 Abstain: 5 Motion carries

Presentation: “TGs Process November”, Eastlake, 11-06/1753r2

In the presentation, it was proposed to hold a teleconference, mostly to review the Agenda of the January meeting, at 5PM on Wednesday 3 January 2007.

It was noted that a conflict exists with the Wi-Fi Alliance Mesh Marketing Group at same time. Can it be moved? Suggested the Chair follow-up with the head of that Wi-Fi Alliance group.

Proposed to move the teleconference to 8AM EST. Strawpoll 8AM: 5 5PM: 17 Unanimous consent for teleconference at 5PM Wednesday 3 January 2007.

The presentation also proposed to pre-approve an adhoc meeting between the January and March 2007 meetings, possibly 6-8 February.

Offers were made to hold the adhoc in Hillsboro Oregon, Munich Germany, Schaumberg Illinois or Eindhoven Netherlands. Strawpoll Hillsboro: 12 Munich: 5 Schaumberg: 9 Eindhoven: 10 Strawpoll Hillsboro: 14 Schaumberg: 6 Eindhoven: 10 Strawpoll Hillsboro: 16 Eindhoven: 11 Submission page 22 Stephen G. Rayment, BelAir Networks

November 2006 doc.: IEEE 802.11-06/nnnnr0

Hillsboro Oregon is chosen by elimination

Moved, to pre-approve an ad hoc meeting in Hillsboro Oregon, between the January and March 2007 meetings, 6-8 February, for comment resolution. Moved: Steve Conner Second: Kazayuki Sakoda There were no objections, Motion approved by unanimous consent

The chair pointed out that, although there were additional presentations on the agenda list, there was insufficient time remaining.

The Chair adjourned the session sine die at 12:27

Submission page 23 Stephen G. Rayment, BelAir Networks

November 2007 doc.: IEEE 802.11-06/1795r00

IEEE P802.11 Wireless LANs

Meeting Minutes November 2006 Plenary

Date: 2006-11-14

Author(s): Name Company Address Phone email Einsteinufer 25 Technical University Emmelmann, Marc 10587 Berlin +49–30–31424580 [email protected] Berlin Germany 8770 SW Nimbus, Tom Alexander VeriWave, Inc Beaverton, OR +1-503-803-3534 [email protected] 97008

Abstract TG T meeting minutes of • ad-hoc session of TG T on Monday 9.30 – 11.00 AM, and • the Dallas 2006 meeting.

Technical presentation, including proposed comment resolutions, are given in: • 11-06/1703r0, The Continuing Need for TRP and TIS Test Methodologies in 802.11.2 • 11-06/799r2, Addressing Multipath Fading in the TGT Draft • 11-06/1756r1, Calibrated Over Air Test (COAT) Methodology • 11-06/1768r0, Proposal for resolution of comments for P802.11.2-D0.10 • 11-06/1770r0, Proposal for resolution of comments for P802.11.2-D0.10 • 11-06/1839r2, MIMO Testing In A Conducted Environment • 11-06/1859r0, questions of the editor on how to handle certain editorial comments

Additional documents: • 11-06/1719r0, Agenda and Meeting slides • 11-06/872r20, Internal review comment list

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you Submissionhave questions, contact the IEEE Patent Committee Administratorpage 1Marc at < [email protected], >Technical. University Berlin

November 2007 doc.: IEEE 802.11-06/1795r00

Meeting Minutes

1. Ad-hoc session of TG T on Monday 9.30 – 11.00 AM 1.1. Minutes were taken by the Chair, Charles Wright 1.2. Meeting came to order at 9.35 AM 1.3. Chair suggested that activity for the ad-hoc to continue with comment resolution based on document 11-06/872r18 1.4. Considered CIDs: 101 – 107, 109, 111, 295, 108, 115, 118, 170, 110, 113 1.5. The record of the resolutions are captured in 11-06/872r19 1.6. Meeting closed at 11.15 AM. 2. IEEE 802.11T Sanger Tuesday 8.00 AM 2.1. Sessionn chair: Charles Wright Secretary: Marc Emmelmann & Tom Alexander 2.2. Chair opened the meeting at 8.05 AM. Tom Alexander was recording secretary for the meeting. The opening presentation was 11-06/1719r0. 2.3. Chair reviewed the patent policy. 2.4. Chair reviewed the meeting objectives. He noted that the editor had created D0.10 and recommended that comment resolutions should be checked against D0.10 to ensure that they were still relevant. 2.5. The minutes for the Melbourne meeting were reviewed and approved without objection. 2.6. The tentative agenda was then presented and reviewed. The editor stated that he would make his report verbally. The Chair made a call for presentations. Chair further noted that presentations should note the comment IDs that they resolved, as priority was given to presentations that resolved comments. 2.7. Presentation requests were received from Pertti Vissuri, Sasha Tolpin, Dalton Victor, Neeraj Sharma, Michael Foegelle and Charles Wright, and added to the agenda. Chair also noted that the current version of the comment resolution spreadsheet was document 11-06/872r19. The order of the presentations was modified after some discussion. 2.8. The agenda was accepted without objection. 2.9. The editor presented the editor's report. He noted that 64 comments required changes to the draft, and D0.10 was created as a result and posted in October. No feedback or complaints had been received after the posting, so it was assumed that everything was well with the draft. 2.10. The Chair reviewed the plan for the week and the timeline. The list of comments requiring work was also reviewed. The Chair then placed a motion before the floor to accept the comment resolution during the teleconferences. 2.11. Motion #1 2.11.1. Move to accept resolutions from comment IDs: 290, 174, 81, 287, 272, 85, 293, 88, 90, 91, 294, 92, 93, 95, 98. 2.11.2. Moved: Dalton Victor; Second: Sasha Tolpin 2.11.3. For: 9 / Against: 0 /Abstain: 1 2.11.4. Motion (technical) passes 2.12. The Chair noted that these comment resolutions were based on the spreadsheet document 11-06/872r19. 2.13. Motion #2 2.13.1. Move to accept resolutions from comment IDs as resolved during the Monday 11/13/06 ad-hoc, in document 11-06/872r19: 111, 295, 115, 113. 2.13.2. Moved: Dennis Ward/ Second: Michael Foegelle 2.13.3. For: 7 / Against: 0 /Abstain: 4 2.13.4. Motion (technical) passes. 2.14. Dennis Ward requested that comment ID 66 (which he submitted) should be withdrawn. Chair requested him to send an e-mail to this effect. 2.15. Presentation of 11-06/1703r0, The Continuing Need for TRP and TIS Test Methodologies in 802.11.2

Submission page 2Marc Emmelmann, Technical University Berlin

November 2007 doc.: IEEE 802.11-06/1795r00

2.15.1. Michael Foegelle presented document 11-06/1703r0, on the continuing need for TRP and TIS metrics in the TGT draft. 2.15.2. Questions were asked by the group. There was considerable discussion. Pertti suggested that a phantom should be introduced into the draft to represent the users of the devices being tested. Dennis supported the presentation and suggested that the applicability could be extended to other products. Charles and Dennis debated this point. Pratik noted that some handset vendors may do the test, and some don't. There was considerable debate between Pratik and Michael. Pertti asked if other organizations have TRP/TIS, and asked for the real reason why the group did not support this methodology. Fahd objected to Michael discounting all the work that currently exists in the draft document and proposed that the set of tests in the draft constitute a minimum set. Dalton said that he did not see how any consumer of the draft document would use the results of the TRP and TIS measurements. Mark echoed Fahd's comment. 2.16. The meeting having gone beyond the allotted time, Dennis called orders of the day. The Chair recessed the meeting until 1.30 PM. 3. IEEE 802.11T Sanger Tuesday 1.30 PM 3.1. The Chair calls TGT to order at 1.25 PM 3.2. Presentation of 11-06/799r2, Addressing Multipath Fading in the TGT Draft 3.2.1. Perti Visuri presended document 11-06/799r2 addressing Multipath Fading in the TGT Draft. 3.2.2. During discussion, the question came up if proposal required changes to the reporting requirements. This is not the case as necessary changes have been already covered. 3.3. Motion #4 3.3.1. Move to modify the P802.11.2 draft 0.10 in accordance with the instructions of document 11-06/799r2 slides numbered 4 through 6. 3.3.2. Moved: Perti Visuri / Larry Green 3.3.3. Y/N/A: 9/0/1 3.3.4. Motion (technical) passes. 3.4. Presentation of 11-06/1756r1, Calibrated Over Air Test (COAT) Methodology 3.4.1. Dalton Victor presented document 11-06/1756r1 3.4.2. Intense discussion on the presentation. The question arises how the accuracy of the test equipment should be gained. As the text makes this only a reporting requiremnt, it does not specify how to get corresponding numbers. They may be retrieved either from vendor sheets 3.4.3. Discussion on how to deal with phantom loss not yielding to a common view of the audience. 3.4.4. A definition of "quiet zone" missing in the document. 3.4.5. There is discussion whether or not all information influencing the measurement is reported in the proposed text but no consensus is reached. 3.5. Motion #4 3.5.1. Move to incorporate the contents of 11-06/1756r1 into the P802.11.2 draft 3.5.2. Moved: D. Victor / L. Green 3.5.3. Y/N/A: 9/0/3 3.5.4. Motion (technical) passed. 3.6. TGT reverts to resolve comments from internal review as found in 11-06/872r20 3.6.1. The following comments were resolved: CID 117, 112, 269, 162, 153, 154, 99, 100, 234, 230 3.6.2. Resolutions and actions were noted in 11-06/872r20. 3.6.3. Tom Alexander and Larry Green volunteered to go through the draft and check if a mere editorial change of PER into FER is possible or if it is a technical change. 3.6.4. Tom Alexander volunteered to look at all remaining editorial comments and decide if they are editorial or technical. 3.7. TG T recesses at 3.37 PM 4. IEEE 802.11T Sanger Wednesday 8.00 AM Submission page 3Marc Emmelmann, Technical University Berlin

November 2007 doc.: IEEE 802.11-06/1795r00

4.1. Chair opened the meeting at 8.00 AM. Dennis Ward and then Tom Alexander were recording secretaries for the meeting. 4.2. Presentation of 11-06/1768r0, Proposal for resolution of comments for P802.11.2-D0.10 4.2.1. Sasha Tolpin presented document 11-06/1768r0, on the resolution of the various comments against the throughput metrics. 4.2.2. There was discussion and questions. Charles asked to see the sections that were brought in from the existing draft. Tom had a comment on the reference to subclause 5.2.2.1, as to whether the subclause was to be cut and pasted or whether it should be merely referred to; Sasha said that the intent was to make a reference, the contribution made an editorial mistake in instructing a cut-and-paste. The editor then stated that he would take it under advisement when making the actual draft changes, to not duplicate the subclause but instead to reference it. There were no other questions, so a motion was made to accept the contribution. 4.3. Motion #5 4.3.1. Move to incorporate the contents of 11-06/1768r0 into the P802.11.2 draft. 4.3.2. Moved: Sasha Tolpin, Seconded: Neeraj Sharma 4.3.3. Y: 7 N: 0 A: 1 4.3.4. Motion (technical) passes. 4.4. The Chair thanked Sasha for his presentation, and then invited Neeraj Sharma to present. 4.5. Presentation 11-06/1770r0, Proposal for resolution of comments for P802.11.2-D0.10 4.5.1. Neeraj presented document 11-06/1770r0, proposing resolutions to several comments. 4.5.2. Some discussion ensued. Dennis wanted to know if the previous day's motion on changing the rotation speed of the turntable would affect the current contribution; the editor replied that he would implement these comment resolutions first, and then apply the motion, so that everything would come out correctly. Dennis expressed some concern with the new Figure 8, because the third sub-figure showed antennas sticking straight out from the wall. After some discussion, the final agreement among the group was to remove the third sub-figure. Charles asked why the angle of the lid was changed from 120 to 110; Neeraj responded that there were different settings used by various people, and most of the people set it to 110; there was not too much difference between 110 and 120 degrees. Fahd also backed this up. There was some discussion on the use of the term "STA" in place of "DUT" meaning "client"; Tom pointed out that "STA" in the main 802.11 standard referred equally to clients and APs, so one had to use something like "non-AP STA" to refer to a client. The discussion went on for some time. Finally, there were no other questions, so a motion was placed on the floor. 4.6. Motion #6 4.6.1. Move to incorporate the contents of 11-06/1770r0 into the P802.11.2 draft, removing the rightmost figure of new Figure 8 of the proposal 4.6.2. Moved: Neeraj Sharma, Seconded: Dalton Victor 4.6.3. Y: 7 N: 0 A: 1 4.6.4. Motion (technical) passes. 4.7. The Chair thanked Neeraj for the presentation. 4.8. Pratik asked for some clarification from the Chair on the disposition (accept, decline, counter, deferred, withdraw) of comments. There was some discussion on this topic. 4.9. The Chair then reviewed the agenda. As the last remaining presentation would not be ready until Thursday morning, the Chair turned the proceedings towards comment resolution, starting with updating the status of all the comments that were resolved by the contributions. A number of previously deferred comments were reviewed and found to have been resolved by presentations and other accepted/declined comments, and so their status was updated. The Chair agreed to upload a new version of the comment resolution spreadsheet. 4.10. At 10.00 AM, the Chair observed that the time for the meeting was up, and called for the orders of the day. 4.11. Meeting recessed at 10.05 AM. 5. IEEE 802.11T Sanger Wednesday 1.30 PM Submission page 4Marc Emmelmann, Technical University Berlin

November 2007 doc.: IEEE 802.11-06/1795r00

5.1. Chair calls TG T to order at 1.32 PM 5.2. Chair proposes to go through deferred comments in document 11-06/873r21 and check if some of them were already resolved by accepted comment resolutions. 5.3. The following CIDs were believed to be resolved by earlier presentations or during the session: 176 (by document 11-06/1768), 74, 75, 76, 245, 161, 12, 16, 24, 28 5.4. The following comments were declined: 5.4.1. CID 248 (declined as commenter did not provide a clarification as requested), 5.4.2. CID 96, 5.5. CID 239 is still deferred. N. Sharma and M. Foegelle are assigned to work out a resolution. 5.6. CIDs 97, 94, and related: D. Ward is asked to go through the current draft (D0.10) and check if they are still valid or can be withdrawn. 5.7. CID 286: 5.7.1. Discussion if TCP should be used to benchmarking as this has no group done before. It is by far more favourable to use UDP. The group is entirely aware that TCP-based throughput testing does not produce reproducible results for different platforms. There is dissent whether reporting specific TCP parameters is sufficient to reproduce of measurements. 5.7.2. An ad-hoc group will produce a resolution: F. Pirzada, L. Green 5.8. CID 198: affected contributers are asked to go through their draft contributions and provide appropriate actions to resolve the comment. 5.9. CID 268 and 269 assigned to F. Pirzada 5.10. CID 303 asigned to F. Prizada 5.11. CID 21 assigned to D. Ward, D. Victor and M. Foegelle 5.12. CID 27 assigned to Mark K. and D. Ward, D. Victor, M. Foegelle 5.13. Order of the day called by Chair at 3.30 PM. 5.14. TGt in recess at 3.35 PM 6. IEEE 802.11T Sanger Thursday 10.30 PM 6.1. Chair call group to order at 10.33 AM 6.2. Chair presents status of resolution of internal comments 6.2.1. According to the editor, some editorial comments have to be changed to “technical” and should be reconsidered. 6.2.2. Additonally, some editoral comments require fundamental changes to the draft. 6.3. Presentation 11-06/1839r2, MIMO Testing In A Conducted Environment 6.3.1. Charles Wright asks Roger Durand to chair the session during the presentation 6.3.2. Roger agrees 6.3.3. Charles W. presents doc. xxx on MIMO testing in a conducted environment 6.3.4. Discussion 6.3.4.1. Dennis W. notes that some devices might use more channels for reception, e.g. 4x6 or 4x7. Is the presented 4x4 MIMO channel fixed to “4”. Charles notes that the number is not fixed to “4” but would not like to go to a generic statement using a “NxN” channel. 6.3.4.2. Tom A. comments that it might be necessary to test a specific device having lambda/2 antenna spacing with a lambda or 4*lambda channel model. 6.3.4.3. What to do if a device being tested uses another antenna spacing? Open issue, one might pick the one of the three given in the .11n channel model which is closest to the one of the device. 6.3.4.4. Discussion on the parts of the draft that would be affected. 6.3.4.5. Charles welcomes volunteers helping him to draft a contribution (standard draft text) for the January meeting. If this does not work out, he will make a technical comment during the letter ballot and submit such a text as a resolution later on. 6.3.4.6. Discussion on how long a test run should last as the channel model has statistical properties. 6.3.5. Charles asked if he should continue with his work regarding the MIMO testing; TGT feels, he should (heads nodding yes). 6.3.6. Roger returns the chair to Charles. Submission page 5Marc Emmelmann, Technical University Berlin

November 2007 doc.: IEEE 802.11-06/1795r00

6.4. Comment resolution phase 6.4.1. Resolutions are captured in 11-06/872r23 6.4.2. Group jointly goes through 11-06/1859r0 6.4.2.1. Editor points to comments which in his opinion are not editorial 6.4.2.2. The following comments were changed from editorial to technical: 127, 241, 292 6.4.2.3. The editor asks the task group to take a look at the following comments and their proposed editorial resolutions before he implements them into the draft as the draft is tremendeously affected. 242, 238 6.4.2.3.1. Editor is asked to incorporate CID 242 into a separate document and present it to the group at the next meeting for final approval and final incorporation into the draft. 6.4.2.3.2. The same applies for CID 238 6.4.2.3.3. Both comments are thus deferred until the next meeting. 6.4.2.4. CID 297, 298, 301: editor is asked to include the suggested resolution as being considered technical 6.4.2.5. CID 193, 194, 195, and related: 6.4.2.5.1. Larry G. points out that his most favourable resolution is “STA” 6.4.2.5.2. Discussion points out that STA can be both, an AP and a client. 6.4.2.5.3. Roger in favor of Larry G.’s resolutions as during letter ballot, people will come back to this issue. 6.4.2.5.4. Michael F. thinks that possibly the terms DUT and “wireless counterpart” are possible to use to resolve this issue as well. 6.4.2.5.5. Group suggests to introduce a new term and corresponding definition of “endstation.” 6.4.2.6. Declined comments: 114, 119 6.4.2.7. Accepted comments: 133 6.4.2.8. Deferred comments: 152 6.5. Orders of day called. 6.6. TGT in recess at 12.35 PM 7. IEEE 802.11T Sanger Thursday 1.30 PM 7.1. Chair calls TGT to order at 13.36 7.2. Comment resolution phase 7.2.1. Resolutions are captured in 11-06/872r23 7.2.2. CIDs 89, 94, & 97 7.2.2.1. Comments are, according to the commenter D. Ward, resolved by doc. 11-06/1768r0 7.2.2.2. The document resolving the comments has been on the server for the required 4- session period. 7.2.3. Editor notes that he and Larry G. went through the draft and every occurence of “PER” can be replaced by “FER.” The draft will not change the technical meaning of the draft as the term “PER” was used having the meaning of „FER.“ The editor is instructed to incorporate the suggested change. 7.2.4. Accepted comments: 142, 7.2.5. Countered comments: 236, 36 7.2.6. Declined comments: 284, 142 7.2.7. CID 72: N. Sharma and D. Ward to provide draft text resolving the comment. 7.3. Fixed time agenda at 14.15 7.3.1. Motion #7 7.3.2. Move to accept resolutions for comment IDs as contained in document 11-06/872r22 161, 19, 16, 12, 24, 28, 248, 57, 58, 122, 68, 69, 71, 73, 74, 75, 76, 176, 96, 245 and 178, 40 (withdrawn by commenters). 7.3.3. Moved/Seconded: D.Ward / D.Victor 7.3.4. Discussion; question called; no objections Submission page 6Marc Emmelmann, Technical University Berlin

November 2007 doc.: IEEE 802.11-06/1795r00

7.3.5. Y/N/A: 7/0/1 7.3.6. Motion (technical) passes. 7.4. Comment resolution: 7.4.1. CID 265 assigned to F. Pirzada as of 09/21/2006 7.4.2. CID 167: Sasha and Dalton volunteered to work on figures 7.4.3. Comments which seem to be unresolveable as group has not a common opinion on a possible resolution: 240 7.4.4. Accepted comments: 288 7.5. Timeline Discussion 7.5.1. TGt agrees to leave timeline as it is. 7.5.2. TGt feels it is very important to be ready to go to letter ballot in January in case TGn gets further delayed. The possibility to (optionally) reject all the remaining deferred comments and encourgage the commenter to re-submit during letter ballot was discussed. This option allows to avoid going in parallel with TGn to letter ballot. 7.6. New Business 7.6.1. Discussion on time allocations for January meeting 7.6.2. Telecons: Every other Thursday, continuing the current schedule, as announced via the reflector (11-30, 12-14, 01-11) 7.6.3. Motion #8 7.6.3.1. Move to empower TGT to held telecoms on 11-30, 12-14, 01-11. 7.6.3.2. Moved/Second: L. Green / T. Alexander 7.6.3.3. Y/N/A: 6/0/0 7.6.3.4. Motion passes. 7.6.4. No ad-hoc meetings 7.6.5. Motion 7.6.5.1. Move to adjour 7.6.5.2. Moved/Seconed: D. Ward / L. Green 7.6.5.3. Y/N/A: no objections to adjorn 7.7. TGr adjourns at 15.45 PM

Action Items

Assignment of CIDs to TGt members asked to propose a resulution text at the January meeting.

CIDs Assigned to Status 239 N. Sharma, M. Foegelle 89, 97, 94, and D. Ward done related 286 F. Pirzada, L. Green 268, 269, 147, 148, F. Pirzada 280, 303, 100 303 F. Prizada 21 D. Ward, D. Victor, and M. Foegelle 27 D. Ward, M. Kobayashi, D. Victor, M. Foegelle 72 N. Sharma and D. Ward 265 F. Pirzada 167 Sasha and Dalton V. 270, 36, 49 Charles Wright 142 C. Warren 239 N. Sharma / M. Foegelle 240 M. Foegelle, P. Visuri

Submission page 7Marc Emmelmann, Technical University Berlin

November 2006 doc.: IEEE 802.11-06/1792r0

IEEE P802.11 Wireless LANs

Task Group U Meeting Minutes for November 2006 Plenary Session (Dallas, Texas, USA)

Date: 2006-11-13

Author(s): Name Company Address Phone email Matthew 5753 W. Las Positas Blvd Trapeze Networks +1 925 474 2273 msg@trapezenetwor Gast Pleasanton, CA 94588 USA ks.com

Abstract Minutes of the 802.11 Task Group U meeting held during the IEEE 802 Plenary Session in November 2006 in Dallas, Texas, USA from November 13th – 17th, 2006.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

Tuesday, November 14, 2006, 1:30 PM to 3:30 PM Chair: Stephen McCann Recording secretary: Matthew Gast

Call to order and agenda

Meeting called to order on Tuesday, November 14 at 1:30 pm Central Standard Time (CST) by Stephen McCann. The chair then reviewed the following topics from the agenda (11-06/1653r1):

• Attendance reminder • IEEE Policies and Procedures o IEEE Patent policy o IEEE Copyright policy • Agenda review o Emergency alerts and IBSS mode were added to the agenda at the end of Tuesday under the heading "Open issues" o The revised agenda was approved by unaninmous consent (24 attendees present) • Approvals of the minutes of past meetings o September 2006 meeting minutes (document 11-06/1441r3) • The chair asked for corrections; none were required • The chair moved for approval by unanimous consent • There was no objection from the task group, so the minutes are approved o November 7, 2006 teleconference (document 11-06/1667r0) • The chair asked for corrections; none were required • The chair moved for approval by unanimous consent • No objection from the task group, so the minutes are approved o November 13, 2006 ad hoc (document 11-06/1749r1) • The chair asked for corrections or comments; none were made • The chair moved for approval by unanimous consent • No objection from the task group, so the minutes are approved • Approval of agenda and goals

Agenda item: Liason letters • Stephen McCann has drafted liason letters (no document numbers available yet) o 3GPP SA3: Two issues: remove MAC address anonymity, and request more information about "link layer encryption indicators" o 3GPP SA2: Their inter-working document is at odds with TGu, and we must coordinate better. We plan two liason letters. o IETF ECRIT o Wi-Fi Alliance

Agenda item: Emergency services • At an emergency services workshop, it was discussed that the FCC may require emergency alert capability. Depending on the final FCC rules, it may be necessary to include emergency services within the TGu draft as a new requirement. • Alistair Buttar: Presented on this topic a year ago (doc# 05/1119r0) o Stephen McCann: Not aware of a mandate being put on WLAN. o Dave Stephenson: Concerned that such a mandate and developing proposals may take time. ƒ Response (Stephen McCann): We currently hope for letter ballot in January/March, but there is a possibility that letter ballot may receive a comment that requires resolving emergency alerts anyway. o Alistair Buttar: FCC has put up a web site that we can study Submission page 2 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

• As far as Stephen is aware, we are the only IEEE 802 group with concerns on emergency support.

Discussion: TGu Requirements (11-05/822r12), Necati Canpolat • Changed R12A1 to "not required, out of scope" from "not required, optional" • Need to amend requirements to remove MAC address anonymity due to lack of justification from 3GPP.

Motion: "Move to direct the editor to remove 'Protection Cluster' in TGu Requirements doc 05/822r12. The document will then be updated to r13." • Moved by Necati Canpolat, seconded by Andrew Myles • Discussion on the motion o Dave Stephenson: Speak in favor of motion. The MAC address is so fundamental to 802.11 that there are potential large ripple effects to using temporary addresses. • No objection to calling the question • Vote: 17 in favor, 0 not in favor, 7 abstain • Motion passes

Discussion: D0.01 to D0.02 changes, Necati Canpolat • Two new proposals confirmed and incorporated into base draft: MIH and network selection

Revised downselection procedure: 11-06/1567r0, Matthew Gast • Discussion o Stephen McCann: The internal review will include everybody, including non-voting members o Dave Stephenson: question on requirement check: is this only mandatory? ƒ Answer: yes, can revise it on the slide o Dave Stephenson: Does "75%" mean votes or resolved comments? ƒ Answer: votes, not comments • Changes were incorpoated as revision 1 and will be uploaded after the vote

Motion: "Move that TGu adopt the procedure in 11-06/1567r1 as the revised downselection procedure." • Moved by Matthew Gast, seconded by Srini Sreeemanthula • No discussion on the motion, and no objection to calling the question • Vote: 20 in favor, 0 not in favor, 2 abstain • Motion passes (75% required)

Presentation: 11-06/1647, Emergency Call number support Donghee Shim • Discussion o Necati Canpolat: Concern about Beacon and Probe expansion, especially for something that is not application layer. ƒ Answer: The station use this to learn the emergency call number before beginning call. The reason for bringing this to the IEEE is that it makes the most sense. o Comment: It was the intent to do this at SIP level rather than layer 2. o Matthew Gast: This is data that should be authenticated for best response time, and Probe/Beacon is not authenticated. That could lead to an unacceptable delay in contacting emergency services. o Dave Stephenson: Can explain the situation where there is a problem: the phone has not yet SIP registered, so this enables the situation where the first call is to to the emergency services. This lets the phone interpret the number as a local emergency number rather than a partial number or mistake dialing. o Srini Sreemanthula: Right now, the terminals are configured with all emergency numbers where the phones can be used, and the terminal can detect that is an emergency call and Submission page 3 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

generates appropriate signaling. Once the terminal identifies it as an ougoing emergency call, it does not matter where it is going. ƒ Answer: Many phones do not store all the emergency call numbers for all of the countries. There are also numbers that may be used for emergency calls in one country but are used by operators in other countries. o Carl Kain: The way that the U.S. PSTN works is that N11 is not a valid area code, and the value of N (911, 711, 511, 311, etc) determines routing. o George Baumiller: Will there be rules that allow unregistered calls to make terminals? ƒ Answer (Necati Canpolat): Our current draft allows them to make calls while not registered. • Stephen McCann: It seems that there is something to check here. o Dave Stephenson: This is a good topic for ad hoc or teleconferences.

Presentation: 11-06/1648, STA Location for emergency call support in SSPN Interface, Donghee Shim • Comment on slide 4, Dave Stephenson: First bullet point is incorrect. Availability of 11k/11v location data does not depend on regulation. • Stephen McCann: This appears to be a L3/L4 facility, and therefore out of scope for 802.11. • Dave Stephenson: Practically, this is difficult to accomplish. 11k/11v may be good enough? • Srini Sreemanthula: Why does location information come from SSPN? The access network may provide this data. • Necati Canpolat: We must draw the line somewhere and provide basic, focused L2 connectivity for call transport. • Matthew Gast: Why does the location data need to be more accurate than existing wired technology? o Answer (Stephen McCann): This comes from the cellular world, and the regulations are independent of technology and may nonetheless apply to WLAN.

The chair asked if there was an objection to recess until 8:00 Wednesday. Seeing no objection, the meeting recessed at 3:33 pm.

Wednesday, November 15, 2006, 1:30 PM to 3:30 PM Co-Chairs: Vivek Gupta and Stephen McCann Recording secretary: Matthew Gast

Meeting called to order by Stephen at 8:08 am CST. Agenda is 21-06/0815r1.

• Attendance reminder • 802.11 private members area password can now access 802.21 private area • Internal TGu review: 802.21 members are allowed to make comments

Presentation: 11-06/1789r0 (also 21-06/817), Inputs from 802.21 to questions from TGu, Vivek Gupta • Comment: Concern that not all operators run physical infrastructure (e.g. Skype) • Comment: Need vendor-specific element in 802.21 query language • Comment (Dave Stephenson): QoS stats depend on AP load and configuration; that makes this a request for dynamic data o Answer: Can a range capture the general characteristic, and would that be useful? • Comment (George Babut): Should QoS be definied by QoS classes? That would minimize need of computation in terminal, and it is easier to match a class. • Comment (Christian Kuhtz): From an operator perspective, it is hard to justify QoS separation. It makes much more sense to define QoS "products" that map onto each of the access media. • Comment (Christian Kuhtz): IMS is sometimes excluded Submission page 4 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

• Comment (Nada Golmie): The descriptors characterize app requirements, and do not necessarily get used to extract access network measurements, so this is left as implementation-dependent. • Comment (Stephen McCann): One requirement in TGu was mapping 11e QoS to the network side (end-to-end QoS), but our conclusion was this is not possible due to complexity and vendor- specificity, but more importantly, we didn't have any good proposals for a complete way to do this. From a practical point of view, this is not part of 802.11. If anybody finds this important, submit a contribution to 11u. • Comment (Dave Stephenson): How is information extracted? For handover, the network information is most important (e.g. ESSID), so to what extent is AP-level information required? Thousands of APs can be deployed in a network, and that requires synchronization of lots of information between AP management system and 802.21 services. o Stephen McCann: agree, need to think of management entity within 802.11 AN, such as Capwap centralized controller. o Subir Das: Dyanmic info is useful for more specific queries o George Babut: 802.11 APs used outside homes, so AP operator needs to provide emergency services for regulators. The first emergency call that is not terminated will result in a lawsuit. Legal interception is also important. o Dave Stephenson: Two concerns. One – how much information is synchronized, which is separate from the question of how much data can be requested from a server. Location is a service, and we should discuss that. Who is responsible for providing location information for emergency calling? Lawful intercept is an infrastructure requirement, and may not be needed for handover decisiosn. o Scott Henderson: There is an ongoing series of emergency services workshops. The FCC has mandated that anything above a certain level of VoIP service must provide location, so any intermediate service must provide information. o Stephen McCann: Lawful intercept and emergency services location are network functions, and are within 11u. Location is out of scope of 802.21. • Answer (Vivek Gupta): We only provide location reporting mechanism, but there is no specification for calculation. o George Babut: Would be happy with "yes/no" as to whether location is supported. Agree that location is out of scope for 802.21. • Comment (Necati Canpolat): There is no security in state 1, and this should be considered for a state 1 query. There should be a protected field in the query. • Comment (Stephen McCann): Can't think of a use case in state 3, and the important thing is state 1 queries. • Question (Stephen McCann): What is the format of the operator identifier? o Answer (Vivek Gupta): It's a network type and a free-form identifier. o Comment (Stephen McCann): That is an SSPN. • Question (Dave Stephenson): What about having the interworking services supported at network level instead of PoA? o Answer (Vivek Gupta): Query is on a per-AP basis, but the query language can be changed in the draft. • Comment (Subir Das): We also have the capability to support a true/false response for a query such as "is emergency services supported"? • Comment (Christian Kuhtz): Why is channel excluded? It is useful in a WLAN-MAN (citywide mesh with several channels)? o Answer (Vivek Gupta): We received feedback that it was not good. Perhaps this could be an option that vendors could include. • Question (George Babut): On the query "Is VoIP supported on this WLAN?" Are we defining services now? o Answer (Vivek Gupta): We may need to add this, but it is up to the working group. o Follow-up (George Babut): If we are going to define services, we should be consistent with QoS.

Submission page 5 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

Presentation: 11-06/1784r0, Limiting the GAS State 1 Query Response Length, Dave Stephenson • Comment (Yoshi Ohba): Good idea, but query request can also be large. o Answer (Dave Stephenson): There is no means within GAS to transport more than one MSDU in query, so the query limited to 2,000 octets. Is that sufficient? • Question (Subir Das): Can response be 2 MSDUs? o Answer: Yes, operator can configure anything between 0-64K. • Question: How does MN know size of response? What if response is too big? o Answer: The AP drops any response that is too big. If useful, we could return a percentage of the response. • Comment (Necati Canpolat): If MIH response fails, we need a way to redo the query

Straw Poll: "Shall draft text in accordance with 11-06/1784r0 be developed for inclusion into the respective 802.21 and TGu amendments?" • Vote: 33 in favor, 0 not in favor, 10 abstain

The meeting recessed 10:05 am.

Thursday, November 16, 2006, 10:30 AM to 12:30 PM Chair: Stephen McCann Recording secretary: Matthew Gast

Call to order and agenda

Meeting called to order on Thursday, November 16 at 10:33am Central Standard Time (CST) by Stephen McCann. The chair reviewed the agenda for the day (11-06/1653r2).

• Dave Stephenson requested a motion slot to bring the text from 11-06/1784r1 to a vote • Attendance reminder

Presentation: 11-06/1860r0, LLDP, Manfred Arndt • Organize joint meeting in March with 802.1ab.

Document Discussion: D0.02, Necati Canpolat • Some clean-up may be required due to overlapping proposals.

Requirements Discussion: 11-06/1852r0, Necati Canpolat • Procedure notes o Stephen McCann: We don't need to vote on gray/green items, since those are partially satisfied. What matters is that we have addressed the requirement. • R12N2: Network selection must allow a multi-credential STA to select correct credentials o Dave Stephenson: We have enabled a STA to pick, but how it does so is a STA- implementation decision. o Dave Hunter: We say must allow it, but the requirement doesn't say that we have to tell how to do it. We do not conflict. o Stephen McCann: Any objection to make R12N2 green? Seeing no objection, it was made green. • R12N3: Authentication with multiple SSPNs through a single AP. o Left as gray/green in light of upcoming tech presentation • R12N8: Advertise online enrolment/subscription methods o Dave Stephenson: On-line entrollment at layer 2 is the wrong place. Propose doing two things: Formally request 802.21 to do this, and vote it as not required.

Submission page 6 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

o Simon Barber: This requirement is for discovery of enrollment, but not the enrollment process itself. o Dave Hunter: The AP says you can get on in the clear anyway, and it is easy to see if it allows anybody on. 802.21 won't know what to do with this requirement. o Angelo Centonza: In 802.21, information is about cost and roaming partners, and this is useful information taken in conjunction with that. o Simon Barber: Simplest thing is to request that 802.21 add identification of enrollment availability to their work, but until they have accepted that, we will not have answered requirement. We cannot change the requirement until 802.21 addresses it. o Dave Hunter: Why is this not already addressed by 11i/11r? ƒ Simon Barber: There is a legal question about using a network without authorization. If the network advertises enrollment, then it provides solid legal ground for a user to connect to the network. A Beacon advertises presence, but not whether it is OK to connect. o Stephen McCann: Is a liason statement sufficient to address the hanging requirement so we can move to internal review?

Straw Poll: "Should TGu set the requirement class of R12N8 to: (1) required, (2) not required, or (3) optional." • Vote: 1 required, 4 not required, 12 optional

Motion: "Move that the requirement class of requirement R12N8 be set to 'Optional' and incorporate this change into document r13." • Moved by Necati Canpolat, seconded by Matthew Gast • No discussion on the motion, and no objection to calling the question • Vote: 15 in favor, 1 not in favor, 2 abstain • Motion passes

Motion: "Move that a liason request be sent to IEEE 802.21 asking them to consider requirement R13N8 and whether this is an appropriate requirement for their project." • Moved by Necati Canpolat, seconded by Dave Stephenson • No discussion on the motion, and no objection to calling the question • Vote: 17 in favor, 0 not in favor, 0 abstain • Motion passes

Motion: "Move that step 13 of the down selection process (re: 11-06-1567r1) has been satisfied and therefore commence an IEEE 802.11u internal review of the baseline draft document D0.02, finishing 1 week prior to the start of the January 2007 London interim." • Moved by Dave Hunter, seconded by Matthew Gast • No discussion on the motion, and no objection to calling the question • Vote: 16 in favor, 0 not in favor, 0 abstain • Motion passes

With no objection, the meeting recessed at 12:29 pm.

Thursday, November 16, 2006, 4:00 PM to 6:00 PM Chair: Stephen McCann Recording secretary: Matthew Gast

Call to order and agenda

Meeting called to order on Thursday, November 16 at 4:00 pm Central Standard Time (CST) by Stephen McCann. The chair reviewed the agenda for the day (11-06/1653r4). Submission page 7 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

• Liason business o David Hunter, 802.21 liason. There are three 802.11u issues for 802.21: (1) that the know a liason letter is forthcoming based on the motion in the last session, (2) they are encouraged to participate in the TGu internal review, and (3) they want to get on to the TGu reflector, but not other 802.11 reflectors

Technical Presentation: 11-06/1473r1, Multiple SSID, Dave Stephenson • Question (Christian Kuhtz): This is one BSSID advertising multiple SSIDs. That approach has seen to be non-functional with legacy stations. o Answer: We have gone to great lengths to make this legacy capable. • Question (StephenMcCann): Is there any possibility of harmonizing mSSID and mBSSID? o Answer: In a way, this is already harmonized because they are already complemtary. • Question (Matthew Gast): Does this require mapping on NAI? o Answer: Yes • Question (Matthew Gast): Do we need to keep state from Probes to ensure VLAN mapping? o Answer: No, use association requests. • Question (Srini Sreemanthula): Original requirement was different SSPN uses different credentials. There is almost no discussion of multiple SSPNs. The problem was reduced to supporting multiple SSIDs, with a 1:1 mapping between SSID and SSPN. Is it realistic to assume AP knows every SSPN? o Answer: it is realistic for AP to know SSID and BSSID. When the query goes out to the 802.21 server, that server must create binding between SSPN and (ESSID+SSID) pair. Once the client has that information, the SSPN is not important information. • Question (Necati Canpolat): How will it work on roaming from APs? o Answer: It is the responsibility of infrastructure to assume that an ESSID has same services everywhere. • Question (Junping Zhang): If two stations access one SSID and belong to different groups, there will be decrypt errors. o Answer: If two clients are on same SSID, they must belong to the same group. There is a GTK per SSID. • Question (Angelo Centonza): In 802.21, a query request could provide a single SSID. Won't you get the same information twice? o Answer: That is necessary to support the architecture. • Stephen McCann proposed moving further discussion to the reflector.

Straw Poll: "Is Task Group U supportive of 11-06/1473r1 and interested in having authors draft normative text for potential inclusion into TGu draft?" • Vote: 16 in favor, 0 opposed

Technical Presentation: 11-06/1848r0, WLAN-Based Assistance for Roaming Between Heterogenous Networks, Dave Stephenson • Question (Matthew Gast): How is the egress AP identified? o Answer: The AP manufacturer would have to set how to make it configurable. The operator would designate something as an egress AP. • Question (Angelo Centonza): Is there an assumption that indoor WLAN is better than cell? o Answer: No. That may be true in some cases, but is not necessarily true. • Question (Angelo Centonza): In, say, an aiport, the indoor cell coverage may be good and handover is not necessarily needed. o Answer: The intent is to provide information to the STA to help it make good roaming decisions. The STA does not have to use information, or even use it in a particular way. • Comment (Angelo Centonza): Average RSSI is more reliable, so a time-average is better.

Submission page 8 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

• Question (Necati Canpolat): This does not fit into requirements. Why TGu instead of TGv? How does this fit into the overall TGu problem domain? This is also only valid in enterprise scenario, where you can mark an edge AP. What about the home, where there is one AP? In the case of mesh, devices may move around. o Answer: This is clearly in scope, and getting on and off network is a fundamental problem. This is more related to client networks than client management. This is not as useful in residential or meshes. • Question (Franz Hermodsson): 3GPP's voice call continuity project is an existing standard. • Question (Srini Sreemanthula ): Will there be impact on native 802.11 roaming, since there is an AP marked out for special treatment? You are still relying on the RSSI. As you are moving indoors, you see more APs, but when you move outdoors, you don't see more APs? o Answer: You can't get away from measuring RSSI. • Question (Christian Kuhtz): Why not TGv? o Answer: Nothing limits it to voice, and most of the other applications will use external networks.

Straw Poll: "Is Task Group U supportive of 11-06/1848r0 and interested in having author draft normative text for inclusion into TGu draft?" • Vote: 8 in favor, 1 opposed

Technical Presentation: 11-06/1772r1, Proposal for User Plan Support for QoS Mapping, Junping Zhang • Question (Srini): Is the QoS Map element already in frame? o Answer: Yes, this is a modification.

Straw Poll: "Is Task Group U supportive of this proposal and interested in having authors draft normative text for potential inclusion into TGu draft?" • Vote: 0 in favor, 0 opposed

Technical Presentation: 11-06/1784r1, Limiting GAS State-1 Query Response Length, Dave Stephenson • Question: 802.21 doesn't care about client state. How does long query in state 3 coexist with short query? o Answer: The Client in state 1 has no IP address. The AP and advertising server must negotiate lower size. In state 3, the client queries directly over IP and the query can be any length. • Question (Angelo Centonza): What happens when query is larger than max, what happens? o Answer: Two options are drop or truncate. It's hard to see what good a partial query would be, so this proposal drops a partial.

Motion: "Move to adopt 11-06/1784r1 text as shown on slide #5 into TGu draft text D0.02 resulting in D0.03." • Moved by Dave Stephenson, seconded by Necati Canpolat • Discussion on the motion o Amjad Soomro: I am not clear on how this improves the DoS attack. o Dave Stephenson: This limits the exposure of an unauthenticated station to take up network capacity. o Hesham Elbakoury: We could let switch store and forward. o Dave Stephenson: That would be a strain on the memory of the AP. o Amjad Soomro: I think it would be more proper to have more time to consider this. ƒ Motion: to table the question. ƒ Moved by Amjad Soomro, seconded by Hesham Elbakoury ƒ Vote: 5 in favor, 4 against, 9 abstentions

Submission page 9 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1792r0

ƒ Motion passes. • Motion is tabled.

Agenda re-order • Stephen McCann proposed re-ordering the remaining agenda items as follows: o Timeline o Teleconferences and ad hoc meetings o Any other business o Liasons. • No objection to reordering agenda.

Timeline discussion, Stephen McCann • Stephen McCann: Suggest moving the initial letter ballot to March 2007 and recirculation to July 2007. The sponsor ballot pool should form in July 2007, with other dates remaining unchanged. • No objection to the proposal, adopted by unanimous consent

Teleconferences and ad hoc meetings, Stephen McCann • Proposal o November 29, 2006 (joint with 802.21) to be verified by 802.21 and subject to their approval o December 12, 2007 o January 4, 2007 o February 13, 2007 o March 6, 2007 o All are at 10:00 am Eastern U.S. time • No vote is necessary because there is a blanket authority

Any other business? • Dave Stephenson: 802.21 has all APs in the database in the information server. They don't know if they can abstract the AP configuration to a network configuration. If TGu can agree on what an ESSID represents, there is a way to help them and define such an information element for the 802.21 IS.

Liasons, Stephen McCann • 802.21 liason created in accord with earlier motion, to be presented as a working group motion.

No objections to adjourning. Meeting adjourned at 6:00 pm CST.

Submission page 10 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1757r2

IEEE P802.11 Wireless LANs Minutes of 802.11 Task Group V Wireless Network Management Dallas, Texas November, 2006 Date: 2006-11-17

Author(s): Name Company Address Phone email R. R. Miller AT&T 180 Park Ave, Florham Park NJ 973-236-6920 [email protected]

Abstract This document records minutes of the 802.11v Task Group meeting of November 2006 at Dallas, Texas.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at . Submission page 1 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

1. Tuesday Afternoon Session, November 14, 2006

1.2. Opening

1.2.1. Call to Order 1.2.1.1. Pat Calhoun (PatC): I call the meeting to order. The TGn MAC meeting is in another room. 1.2.1.2. Meeting convened at 1332 hours. 1.2.1.3. PatC: I show the pre-meeting information 06/1702r1 on the screen.

1.3. Process

1.3.1. Review of Patent Policy 1.3.1.1. PatC: I would like to read the patent policy shown on the screen from document (06/1702r1). [reads] Are there any questions on the policy? None. Does anyone know of any patents that the chair should be advised of at this time? No. Let us proceed.

1.3.2. Review of Inappropriate Topics 1.3.2.1. PatC: I would like to read a list of topics that will be forbidden in meetings. [reads] Any questions? No.

1.3.3. Approval of the agenda 1.3.3.1. PatC: Does anyone want to change the agenda shown in 1702/r1? Yes [negotiates new agenda items]. Any other changes? Joe Kwak wanted to present Thursday. Emily, could you present today? No. Any objections to approving the agenda. No. 1.3.3.2.

1.3.4. Approval of Minutes from Last Session 1.3.4.1. PatC: Does anyone wish to move to adopt the minutes from the last meeting? Yes. 1.3.4.2. EmilyQ: I wish to move: 1.3.4.3. Move to approve meeting minutes in 11-06-1551-00-000v-tgv-minutes- september 2006-session. 1.3.4.4. Moved Emily Qi 1.3.4.5. Seconded: Victoria Poncini 1.3.4.6. Is there any objection to accepting the meeting minutes unanimously? No. The motion passes unanimously.

1.3.5. Review Objectives 1.3.5.1. PatC: We shall be examining some contributions and will be moving forward with some motions. Emily, are you ready with a motion? Yes. 1.3.5.2. Motion: Move to approve the TGv internal review comment resolutions for the comments that are marked as “Accepted” and “Counter” in spreadsheet document 11-06-1615r5. 1.3.5.3. Moved: Emily Qi

Submission page 2 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

1.3.5.4. PatC: Is there discussion before we second? Yes. 1.3.5.5. RogerD: Emily, are you aware there is an updated revision on the server? 1.3.5.6. EmilyQ: Yes for the later revisions, I went through the comments by category. We are now up to R7. 1.3.5.7. PatC: Is there any further discussion on the motion? No. 1.3.5.8. Motion: Move to approve the TGv internal review comment resolutions for the comments that are marked as “Accepted” and “Counter” in spreadsheet document 11-06-1615r5. 1.3.5.9. Moved: Emily Qi 1.3.5.10. Seconded: Allan Thomson 1.3.5.11. PatC: Is there discussion? No 1.3.5.12. For 10, Against 0, Abstain 4 1.3.5.13. PatC: The motion passes. Let’s consider some presentations on technical comments. Is there anything else someone would like to do this week? Yes. 1.3.5.14. Emily: 943r6 requires action. I would like to add this. 1.3.5.15. PatC: Very well, it has been added. Let’s start the presentations…

1.3.6. Presentation of Document 06/1700r0 1.3.6.1. Qi Wang places document 06/1700r0 “Channel Switch Announcement with Extension” on the screen. The presentation addresses one of the comments from the internal review process. It treats the inclusion of a “secondary channel offset” and a new regulatory class IE. If a channel switch is made it may require a change of regulatory class, which is now accommodated. A secondary channel offset IE is also defined and appended to the existing frame body. An Extended Channel Switch Announcement IE is proposed that can be variable in length. The proposal reduces the number of CSA- related IEs, accommodates additional information in a CSA frame, and eliminates the need to define multiple CSA frames. May I ask the group’s opinion? 1.3.6.2. Allan: The proposal would replace the existing CSA? 1.3.6.3. Qi: Yes. 1.3.6.4. Allan: It is meant to clarify how stations can implement the channel switch. 1.3.6.5. VictoriaP: TGy is using the CSA in its work, so it may be prudent to harmonize. 1.3.6.6. Qi: I welcome that. However, I think the best approach is to include all the information necessary in one container. 1.3.6.7. EmilyQ: This would seem to support only TGn devices. Could an a/b/g device also act on this? 1.3.6.8. Qi: Yes, there is enough information, but a byte is wasted. 1.3.6.9. Sudheer: In your normative text (1701r0) in the beacon format section, shouldn’t this be contingent on presence of an actual channel switch announcement? 1.3.6.10. Qi: This must be appended, if necessary. This is not enough all by itself. 1.3.6.11. Sudheer: Shouldn’t this be specified in the normative text? 1.3.6.12. Qi: How to use the information is defined in the normative text 7.4.1.4.5 which discusses the exact procedure. 1.3.6.13. Sudheer: Is there no text regarding channel switching in 11? 1.3.6.14. Qi: The channel switch is specified, but that’s all. 1.3.6.15. EmilyQ: It seems like the relationship between TGn and TGv could result in de-synchronization between the two standards.

Submission page 3 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

1.3.6.16. Qi: If we have agreement in both TGv and TGn there is no problem, but some information in TGv may be lost. 1.3.6.17. Allan: I suggest, as Victoria suggested, that TGy will finish before TGn, so harmonizing with that one first would seem prudent. 1.3.6.18. Qi: Perhaps a joint session? 1.3.6.19. PatC: I don’t think a joint session would be appropriate. 1.3.6.20. Victoria: We have several people liaising with TGn, so harmonizing with TGy would seem to accomplishing your goal. But I think a joint session might be a good idea. 1.3.6.21. PatC: I’ll discuss with the chair, but this seems like overkill. Do you have a motion? 1.3.6.22. Qi: I wanted to achieve a result by the end of this week, however I shall not offer a motion now (assuming I can do so later). 1.3.6.23. PatC: Jari, you’re next.

1.3.7. Presentation of Document 06/0646r7 1.3.7.1. Jari Jokela places document 06/0646r7 on the screen. This presentation has been given earlier, but has been modified as a result of ongoing discussions with those who presented concerns. It treats degradations that may arise as a result of dual radio operations in the same device. It proposes an interference notification capability that allows a station to report if it is experiencing difficulty due to interaction between two radios operating concurrently. A mechanism is included for rate-limiting reports. The response fields have been identified showing a number of characteristics. Highlights were presented on areas of normative text that have changed in companion document 06/0645r3. Questions? 1.3.7.2. BobM: Is this optional? 1.3.7.3. Jari: No, all stations must implement the feature. 1.3.7.4. BobM: Can the AP suppress reports? 1.3.7.5. Jari: Yes. 1.3.7.6. BobM: Are the returned interference parameters measured? 1.3.7.7. Jari: No, they need not be. They. can simply be fed from the other air interface via the device host processor. JariJ: I wish to move: 1.3.7.8. Move to include normative text in document 11-06-0645-03-000v- interference-diagnostic into the TGv draft. 1.3.7.9. Moved: Jari Jokela 1.3.7.10. Seconded: Jason Trachewsky 1.3.7.11. For 10, Against 2, Abstain 6 1.3.7.12. PatC: The motion passes.

1.3.8. Presentation of Document 06/1688r0 1.3.8.1. Dong Hyun presented document 06/1688r0. This presentation treats time reduction to acquire FBMS and achieve power efficiency. It proposes that and association request/response frame be used to include FBMS. The process for doing this is covered in the document. 1.3.8.2. PatC: Do you have normative text? 1.3.8.3. AllanT: I think this may already have been covered. 1.3.8.4. Dong Hyun: I do not know the process as I am not a voting member 1.3.8.5. PatC: Someone can make the motion for you.

Submission page 4 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

1.3.8.6. AllanT: There is already a resolution logged into the comment spreadsheet covering this. Comment 74 addresses this, 1.3.8.7. PatC: Is there someone who will make this motion on Dong’s behalf? Yes. Allan Thomson volunteers. 1.3.8.8. Move to include normative text in document 11-06-1650-00-000v-Proposed changes to the 802.11v into the TGv draft. 1.3.8.9. Moved: Allan Thomson 1.3.8.10. Seconded: Roger Durand 1.3.8.11. For 9, Against 0, Abstain 7 1.3.8.12. PatC: The motion passes. Since we have had our scheduled presentations, may we start with assignment of comments? Emily, you broke this down into categories? 1.3.8.13. Emily: Yes. 1.3.8.14. PatC: Would anyone object to addressing these by category? No. Can I get a show of hands on who would like to volunteer for the categories? [Shows a list] 1.3.8.15. General – Emily Qi 1.3.8.16. Event – [No one volunteers] 1.3.8.17. Diagnostics – Bob Miller, Alex Ashley 1.3.8.18. Multicast Diagnostics – Jari Jokela, Subbu 1.3.8.19. Station Statistics – Emily Qi 1.3.8.20. FBMS – Allan Thomson, Qi Wang, Jari Jokela 1.3.8.21. Presence – Allan Thomson 1.3.8.22. Roaming Management - Joe Epstein, John Bahr, Bob Miller 1.3.8.23. Extended Channel Switch – Allan Thomson, Qi Wang, Victoria Poncini 1.3.8.24. Virtual AP – Subbu, Joe Epstein 1.3.8.25. PatC: Are there any other volunteers? No. Very well, is there any objection to recessing to an ad-hoc meeting until 4 pm? No.

1.4. Closing

1.4.1. Recess 1.4.1.1. PatC: Is there any objection to recessing until 1600. No. 1.4.1.2. Recess at 1500.

1.5. Opening

1.5.1. Call to Order 1.5.1.1. Pat Calhoun (PatC): I call the meeting to order. 1.5.1.2. Meeting convened at 1604 hours. 1.5.1.3. PatC: We shall resume presentations by those available.

1.6. Process

1.6.1. Presentation of Document 06/1672r0 1.6.1.1. Donghee Shim presented 06/1672r0 on STA Provided Location. The document provides a mechanism for allowing an STA to forward its location to the AP.

Submission page 5 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

1.6.1.2. AllanT: I believe the STA can provide its location via a presence response message. 1.6.1.3. Donghee: There still must be a request from the AP. 1.6.1.4. AllanT: The protocol is bi-directional; the capability is already there. 1.6.1.5. DorothyS: I’d like to understand what you are proposing that is in addition to what we already have. 1.6.1.6. Donghee: What about the case where the AP knows its location and would like to include the STA location in a response in an unsolicited way. 1.6.1.7. Dorothy: The way the request format is designed now, the descriptor is available, but not the actual location. 1.6.1.8. Donghee: I’m advocating adding the actual location data. 1.6.1.9. Emily: Why can’t you use the present response message? 1.6.1.10. Donghee: The station cannot respond unless requested. 1.6.1.11. JoeK: We have had similar suggestions before, in TGk for example. It would be useful to have a way to transport the data in an unsolicited manner. This feature exists for some measurements. 1.6.1.12. PatC: I checked the text Dorothy/Emily suggested and found that the current text does not cover unsolicited responses. 1.6.1.13. Allan: I understand unsolicited location for measurements, but not for location. Why would a station need this capability? 1.6.1.14. Donghee: I attended a conference on emergency call procedures and this was marked as a useful capability. 1.6.1.15. Emily: For emergency service, the station provides its info to an application, but not to an AP. 1.6.1.16. Donghee: In UTRA the AP can send location data to the SSPN, for example. 1.6.1.17. BobM: Are there opportunities for misuse and privacy concerns? 1.6.1.18. Donghee: It would seem that such misuse was possible, but the information might also be obtained with similar existing methods. 1.6.1.19. BobM: Do you contemplate possible periodic or multiple “pushes”? 1.6.1.20. Donghee: I haven’t considered this, but I guess it could be done. 1.6.1.21. Allan: I’d like to call your location to Service Location Parameter Request. In this case the return of information could be periodic. 1.6.1.22. Donghee: Yes but this is not unsolicited. 1.6.1.23. Allan: The station might be providing its location to an AP that did not want to get the information. 1.6.1.24. Dorothy: We have the ability to set the presence bit, indicating interest in presence information. So the AP can request the location. I’m not sure I see the harm of adding this. For an AP, it could provide information one message sooner. I’d like to think about this. 1.6.1.25. Donghee: So you think you need more time to consider? 1.6.1.26. Dorothy: We didn’t consider this initially, but it might be valuable. 1.6.1.27. Donghee: Perhaps I can have discussions with interested parties and then come back. 1.6.1.28. PatC: Dorothy can work with you. You want to hold your motion---or rather hold off asking someone to move for you. 1.6.1.29. Donghee: Yes, I shall wait.

1.6.2. Presentation of Document 06/1671r0 1.6.2.1. Donghee Shim presented 06/1671r0 on Location Notification. There are several positioning methods that can be used to determine location, but no way to notify the AP which one is being used. Such knowledge could be

Submission page 6 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

valuable for negotiation of positioning method between STA and AP. The presentation suggests that addition of capability parameters in the Presence Configuration Frame could be considered to accommodate this. A table of identifier options is offered as an example. 1.6.2.2. Allan: So the beacon and probe responses already have presence parameters. Why did you not choose to look at these? 1.6.2.3. Donghee: You are saying the presence parameter can provide this? 1.6.2.4. Allan: It can provide the container for such information. 1.6.2.5. Donghee: If that capability exists, then I should consider it. But how can an STA advertise its capability. 1.6.2.6. Allan: The information could be contained, for example, in an association request. 1.6.2.7. Dorothy: We have the capability to ask for a location service, but we cannot ask explicitly an AP, “I want to use a certain method”. Is this a non-AP STA, or all STAs? What’s the difference between STA and STA-assisted? 1.6.2.8. Donghee: Assisted means the AP can calculate the location, non-assisted means actual location is provided. 1.6.2.9. Dorothy: This could be done, but we did not call out this capability. The availability of such a feature would seem OK. 1.6.2.10. Allan: The AP can advertise what it’s capable of, so this could simply be re- applied to STAs. Thus, any number of location formats could be supported. 1.6.2.11. Dorothy: We would have to extend this to allow direct or assisted capabilities. 1.6.2.12. Allan: We should take this offline. 1.6.2.13. PatC: Let’s move JoeK to Thursday. Does anyone need any more time to present? Joe, do you understand this rescheduling and approve? Yes. Is this agenda change acceptable to the body? Yes. I have placed the modified agenda on the server as 1702r2 as shown below • Review IEEE patent policy • Approve Agenda • Approve minutes from last meeting • Review weekly goals and objectives • TGv Text Submissions • 14:09-14:39 – 11-06-1700-00-000v-channel-switch-anouncement-with-extension • 14:39-15:09 - 11-06-0645-02-000v-interference-diagnostic • 15:09-15:30 - 11-06-1650-00-000v_proposed-changes-to-802-11v-draft • 15:30 – Break • TGv Text Submissions • 16:00-16:45 – 11-06-1672-00-000v-sta-provided-location • 16:45-17:30 - 11-06-1671-00-000v-location-capability-negotiation • 17:30-18:00 - • 18:00 - Recess 1.6.2.14. PatC: Are there any objections to going to ad-hoc mode to continue with comment resolution? No. 1.6.2.15. DorothyS: I shan’t need 45 minutes for my presentation on Thursday.

1.7. Closing

1.7.1. Recess 1.7.1.1. PatC: Is there any objection to recessing for the ad-hoc? No. We are recessed. 1.7.1.2. Recess at 1649.

Submission page 7 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

2. Wednesday Morning Session, November 15, 2006

2.2. Opening 2.2.1.1. Secretarial note: The secretary would like to extend thanks to Dorothy Stanley for recording notes at the Wednesday morning TGv meeting in the secretary’s absence.

2.2.2. Call to order 2.2.2.1. PatC: I call the meeting to order. 2.2.2.2. Meeting convened at 0804. 2.2.2.3. PatC: I would like to remind you to record your attendance on the server. We shall now begin our scheduled presentations.

2.3. Process

2.3.1. Presentation of Document 06/0943r6 2.3.1.1. Emily Qi presented document 06/0943r6, Idle Mode Operation in IEEE 802.11 WLANs. This presentation has been given previously, but incorporates updates including Added Paging Service Protection for Idle Mode Request/Response, a terminology change from Paging Domain to Mobility Domain, alignment of the Paging Server with the PMK-R1 key holder, and other improvements. Motivation is to provide an additional mechanism for power save, minimizing the "awake" time at DTIM and Listen Interval, and eliminating unnecessary BSS Transition scenario. Today, a mobile station must transition and associate to every BSS it traverses. We did some experiments in our office location, with an ultra-light phone. Standby hours for the [802.11] phone is 53 hours. Average enterprise use – walk around for 5 minutes per hour, standby time dropped to 45 hours. This is typical enterprise usage. Other applications – e.g. nurses walking around will use more. The presentation introduces a “deep sleep mode” – the entire device is idle – radio and OS. Paging is introduced to provide a mechanism to tell the STA that a frame is waiting for it. Some concepts have been reused from 3GPP and [802.16] paging services. A Paging Group is a group of APs in which a STA can be paged. STAs will re-associate when it moves between paging groups. An example of WLAN paging architecture and deployment options is included. The protocol includes a paging capability and service discovery via changes in the Beacon and Probe Response. Idle Mode Request and Response are used to enter and exit idle mode and to provide updates. For advertising and discovery – one bit has been added in the wireless network management capability. A Paging IE has also been added with four new fields which indicates when the next paging info will be delivered. A new Paging indication element – similar to the TIM was added, as were Idle Mode Request and Response frames. 2.3.1.2. PatC: Why is the update needed? 2.3.1.3. EmilyQ: For the STA to update the network of its status. The infrastructure knows where the STA is. [802.16] uses a similar location update: the STA sends out idle mode updates. 2.3.1.4. EmilyQ: [resumes presentation] The proposal also includes a keep-alive timer, prompting the STA to send out update messages. Paging service key hierarchy was reinstituted, since there were concerns here. This is used to protect idle mode request and response frames from forgery. An example of message flow is provided, along with an idle mode and paging scenario. In summary: Idle mode extends the mobile device standby time as well as a paging service.

Submission page 8 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

2.3.1.5. Floor: Question on slide 9. Paging groups have physical proximity. Can Paging groups overlap? 2.3.1.6. EmilyQ: Yes. This chart gives an example. 2.3.1.7. Floor: If it is allowed, then how would that improve things? The STA will see multiple paging groups, and then re-associate. 2.3.1.8. EmilyQ: The STA doesn’t reassociate until it loses sight of the paging group, which still significantly reduces the number of roams. Slide 11, 14 – paging Server ID, a paging server can serve multiple paging groups. 2.3.1.9. Floor: I’d like to understand how the keys are derived. On Slide 14, no unique identification of the group ID is shown. Is there a protocol used for the exchange? 2.3.1.10. EmilyQ: Yes, the Idle Mode request and response. 2.3.1.11. Floor: Is this a 3 message exchange? 2.3.1.12. EmilyQ: No, this is a 2-message exchange. 2.3.1.13. Floor: This is the first time looking at the slides. 2.3.1.14. EmilyQ: Communication is between an STA and the Paging Server. Paging groups are handled within a paging server. Paging Group ID defines them. There is a dependency on the TGr mobility domain. The paging group defines the area that a STA can be paged in. But the protection is between the STA and the Paging Server. A power consumption analysis has been conducted. Consider the use cases and test cases. We looked at determining the effect on standby time. Assumptions include the number of roams per hour, the wake-up interval, the roaming awake time, periodic background scanning time and power consumption. The study examines a range of 0-30 BSS transitions per hour. Device usage ranges from 100 to 800 ms of wake time. We assume that the system is always active. Also, 802.11r does not cover the discovery and scanning time – it only addresses the actual transition time. Periodic background scanning time has a range of 50-500. Referring to Slide 21, Paging mode compared with the Legacy PSM. The benefit at 0 roams gives 10% improvement in standby time. Grows to 20% with increased number of roams. In Slide 22, compare with Legacy PSM, with background scanning 2.3.1.15. Floor: Was there any comparison done with a TGv client with FBMS? 2.3.1.16. EmilyQ: This scenario assumed that no broadcast or multicast was involved. The two are orthogonal. FBMS – your prerogative. This assumes that you stay awake 0 time for broadcast. 2.3.1.17. Floor: Let me see if I can summarize this… Have a salt and pepper arrangement. If I run around like a maniac, this will help, saving 8%. If I send real traffic, I have 4% improvement. I am concerned that we have a lot of complexity as well as potential security concerns. 2.3.1.18. EmilyQ: That’s not true. 24/7, the [802.11] phone is connecting to every AP that you hit. If you are in a contiguous work area, now you don’t have to do the associations. In-call power saving is an already-solved problem. 2.3.1.19. Floor: I accept the fact that there is benefit to this if one receives one call per day and stay in the same area. Suppose it is 10 %, though. I see the additional complexity, beacon bloat, mean complexity cost. We need to evaluate this for what appears to be a tiny gain. I see this as marginal. 2.3.1.20. EmilyQ: For an [802.11] phone, “standby hours” is a critical requirement. This proposal addresses that. I would like to make a motion: 2.3.1.21. Move to include normative text in document 11-06/0943r6 into the TGv draft. 2.3.1.22. Mover: Emily Qi 2.3.1.23. Seconder: Roger Durand 2.3.1.24. For 13, Against 5, Abstain 3 2.3.1.25. PatC: The motion fails Submission page 9 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

2.3.2. Presentation of Document 06/1783r0 2.3.2.1. Kevin presented document 06/1783r0, “Timing Measurement Enhancement for Synchronization of AV streams”. The motivation for this presentation is support for [802.11-equipped] speakers. There is a mix of wireless and wired speakers. There is a lot of demand for [802.11-equipped] speakers. Use cases are portable speakers with coverage of the home. Such applications need 10ms of synchronization accuracy. Lip synchronization is easier. The application needs to regenerate the clock locally if you don’t buffer a lot locally. Example: Media push application. Implementations above the MAC don’t have the facility to get the required level of accuracy. There are other initiatives including P802.1AS – Time Synchronization, and other groups for Stream Reservation Protocol, Traffic Shaping, and potential recommended practices. Slide 5 shows how presence works today. Requestor sends a Presence Request, records ACK times, then the Presence Response sent, and time differences can be used to determine the link delay. 2.3.2.2. Floor: This assumes the transmit and receive delay are constant. These also may not be the same. 2.3.2.3. Kevin: Yes this accounted for, as the stamp is taken at same point so biases are built in. 2.3.2.4. Floor: In different implementations, there may be different delays. 2.3.2.5. Kevin: The same issue applies in wired cases. By sampling in both directions, one can see this, and also take multiple samples. Accuracy of timestamps is typically within 40 nanoseconds, with multiple samples per second. 2.3.2.6. Floor: What level of accuracy is required? 2.3.2.7. Kevin: Clock quality, microseconds. 2.3.2.8. Floor: In WLANs you are looking at variability in the access delay. I’m not sure you’ll get meaningful results with the formula. 2.3.2.9. Kevin: The stream itself is independent of the timestamps. The ends agree on the “Time it is” with this measurement, and synchronize the clocks. IEEE 1588 uses this for automation control. 2.3.2.10. Floor: For video streaming – not sure if this will work. 2.3.2.11. Kevin: This is getting the clock distributed. The intended use is high quality audio, which needs 11ms. To regenerate a clock which is derived from another clock, then one needs to look at the accuracy of clocks. It is very important where the timestamp is taken – on the output of the MAC, not in 802.1. For rates – 40ns, Fast Ethernet takes the measurement is at the bottom of the MAC. 2.3.2.12. Floor: Even for the location, need to take the measurements close to the PHY. 2.3.2.13. Floor: If we want 40 ft of accuracy, then you’ll meet your requirements. 2.3.2.14. Floor: The problem is that a hardware change is going to be required. With location, we assumed that special devices would be used. Such devices would be needed on both sides. 2.3.2.15. Floor: Ethernet switches will have to support this. All devices in the cloud will need to be compliant. 2.3.2.16. Kevin: [continues] Changes to the text are optional. Inserted a new Report Interval Units field in the Presence element, to provide less than a one second interval. Add a timing Offset Measurement element, indicated as an option in the Presence Request Option field. Add an Ingress Timestamp field to the Timing Measurement Field, formatted in a consistent manner with 802.1AS. Then text for procedures. 2.3.2.17. Kevin: I wish to move

Submission page 10 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

2.3.2.18. Motion: Move to include the normative text in document 11-06/1614r0 into the TGv draft, replacing microseconds with milliseconds in table v1. 2.3.2.19. Mover: Emily Qi 2.3.2.20. Seconder: Allan Thomson 2.3.2.21. PatC: Is there discussion on the motion? Yes. 2.3.2.22. Floor: The 802.1QAV PAR builds upon 802.1AS timestamping. 2.3.2.23. Kevin: Comments on the PAR from the 802.11 vice chair specifically asked for 802.11 support to be included. 2.3.2.24. PatC: Is there any more discussion? No. 2.3.2.25. For 11, Against 0, Abstain 10 2.3.2.26. PatC: The motion passes.

2.3.3. Presentation of Document 06/1461r2 2.3.3.1. Peter Ecclesine presented document 06/1461r2, “Null Beacon Energy Conservation concept”. This presentation focuses upon the need to minimize power being used when the radio is on. Idle time is when the devices are not being used. A lot of power could be saved by small or larger changes in beacon processing, for example if one processes the beacon, and just the address fields. This is the absolute minimum beacon that could be processed. The null beacon says “there is nothing happening” and uses less energy to process. Companion normative draft text may be found in document 06/1728. The proposed Null Beacon is generated when the TIM is empty, with no channel switch announcements, and no buffered traffic. 2.3.3.2. Floor: Can you comment on backward compatibility? When is this sent? 2.3.3.3. PeterE: When there is no activity. 2.3.3.4. Floor: Are you sure that by changing the size of the beacon that you are really saving something? 2.3.3.5. PeterE: I am assuming that power consumption is related to traffic. I have no measurements to back this up. 2.3.3.6. Floor: You made a claim of 50% power saving. Compare this to reducing the number of beacons. Can you provide data here? 2.3.3.7. PeterE: I would like to do this. Manufacturers should be looking at reducing power consumption. There are no measurements on power consumption in 802.11k, or 802.11v. 2.3.3.8. Floor: Adaptation to diurnal human behavior should also be considered. 2.3.3.9. Floor: Have been going through power saving analysis with Idle mode. Need to see some analysis on this proposal. 2.3.3.10. PeterE: Measurement pilots were supposed to have done this. 2.3.3.11. Floor: Would it save more power if you double the DTIM? That reduces the beacons? 2.3.3.12. PeterE: I understand that. Less energy in the air, less energy at the receiver and transmitter. 2.3.3.13. Floor: Time you spend in the process of waking up to capture the beacon dominates. 2.3.3.14. PeterE: Agree completely. 2.3.3.15. Floor: One job of the beacon is time synchronization, the other is to deliver information. I am concerned [with compatibility] for legacy device. The STA also uses the beacon to know where it is. 2.3.3.16. PeterE: Beacons are unacknowledged. Every device has to provide for a beacon being missed. Count on the fact that beacons will not be received all the time.

Submission page 11 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

2.3.3.17. Floor: If the BSS has no associated STAs, and there is no buffered data, then every beacon is a DTIM. STAs doing passive scanning would not receive any beacons. 2.3.3.18. PeterE: Suggest a statement to add. Power saving is not the only argument. Also want to be efficient over the air. It also lowers interference. 2.3.3.19. Floor: Separate the physical from logical elements, via user management frames. Assuming now that there are no VLANs, not acknowledging this. 2.3.3.20. PeterE: A Multiple BSSID proposal addressed this. I don’t disagree that using less airtime is good. But when a phone is scanning for beacons, now it has to wait longer, and for passive scanning this also Increases the amount of time waiting. 2.3.3.21. Floor: Get a neighbor report, then know the area. 2.3.3.22. PeterE: Reducing beacon availability will hurt those guys. 2.3.3.23. Floor: Need more qualifications. 2.3.3.24. Floor: The problem is that you’re mandating operation. People may find better alternatives. The standard does not mandate 100ms---the market simply settled there. 2.3.3.25. PeterE: I appreciate the feedback. I shall come back in January with data, as well as present a better understanding of the benefits. 2.3.3.26. Secretarial note: The regular secretary resumed minutes at this point.

2.3.4. Review of Comment Resolutions 2.3.4.1. PatC: Can we have any information on ad-hoc progress? 2.3.4.2. AlexA: Diagnostics completed all items, but have deferred many back to the group. 2.3.4.3. AllanT: I think we should re-enter ad-hoc mode. 2.3.4.4. Emily: We should think about putting the comments into the master spreadsheet. 2.3.4.5. Dorothy: We should put everything into one document, and should be careful about the four-hour rule. 2.3.4.6. Allan: There are a lot of comments to work through. 2.3.4.7. Emily: We already voted on the editorial comments. 2.3.4.8. Dorothy: The only other option is to create another document. 2.3.4.9. PatC: If we have more documents, we’ll have a merge problem. 2.3.4.10. Emily: I suggest that each group trim the spreadsheet to that group’s list and use that document as a working document. 2.3.4.11. PatC: Are there any objections to going into ad-hoc mode? No.

2.4. Closing

2.4.1. Recess 2.4.1.1. PatC: Is there any objection to recessing for the ad-hoc? No. We are recessed. 2.4.1.2. Recess at 0940.

Submission page 12 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

3. Wednesday Afternoon Session, November 16, 2006

3.2. Opening

3.2.1. Call to order 3.2.1.1. PatC: I call the meeting to order. 3.2.1.2. Meeting convened at 1330. 3.2.1.3. PatC: We shall now resume our scheduled presentations.

3.3. Process

3.3.1. Presentation of Document 06/1705r0 3.3.1.1. Brian Wells presented 06/1705r0, Medium Congestion Control (MCC). This framework proposes control of local congestion using the MAC. The concept differs from other congestion control methods, as it uses no signaling which can be problematic in congested systems. For ad-hoc operation, such as in mesh and WAVE, this approach could have value. The proposal measures channel utilization, measures STA contributions to congestion, and provides measurements to clients. A client-server architecture is modeled with a client (e.g. SME) and with a server (e.g. MLME). Some examples of measurements are included. 3.3.1.2. Question: These are snapshots, not averages right? 3.3.1.3. Brian: Yes. The MCC program handles averaging them. Control can be either basic or adaptive. The control process sets up a loop between the SME and MLME that orchestrates measurements and adjustments. Companion normative text may be found in 06/1706r1. I welcome questions. 3.3.1.4. AllanT: Is there a way of establishing client policies? 3.3.1.5. Brian: We are not supplying an algorithm, but rather encouraging different implementations using the method. 3.3.1.6. AllanT: On the Basic Control slide, you’re suggesting policy. 3.3.1.7. Brian: No we are really only treating the MLME part embodying the measurement and control interfaces. 3.3.1.8. PatC: Brian, would you like a straw poll? Yes. 3.3.1.9. Straw Poll #1: 3.3.1.10. Is the proposed MCC Framework appropriate and relevant to TGv? 3.3.1.11. PatC: Anyone can vote 3.3.1.12. Yes 4, No 3 3.3.1.13. Straw Poll #2 3.3.1.14. Should TGv include appropriate normative text describing the MCC Framework in the TGv draft? 3.3.1.15. Yes 1, No 5 3.3.1.16. Straw Poll #3: 3.3.1.17. Should TGv include the text in 802;11-06/1706r0 to be used as a baseline for text to be included in the TGv draft? 3.3.1.18. Yes 0, No 5 3.3.1.19. Any comments? 3.3.1.20. BobM: As long ago as Berlin, TGv members indicated emphasis of effort would be directed to infrastructure mode service with large systems. 3.3.1.21. DorothyS: Would this be [more] useful in mesh and WAVE? 3.3.1.22. Brian: Yes, I think so. Submission page 13 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

3.3.1.23. DorothyS: I recognize there are many flavors of mesh, for example but it would seem many of these envision a 1-tier mesh as a replacement for a BSS. It seems like the fit in such an area would be good. 3.3.1.24. JoeK: TGk includes many similar features. What is new here? 3.3.1.25. Brian: Many of those measurements are over the air. I believe that these supplement the TGk over the air framework. 3.3.1.26. JoeK: With TGk the interface to upper layers is specified. 3.3.1.27. Brian: This operates within the MLME, it can all be done locally. 3.3.1.28. JoeK: It can still be done locally. 3.3.1.29. Brian: This is all inside one device. It doesn’t go over the air. It allows a local station to monitor it’s perception of congestion and then adjust its behavior. We don’t want to impose additional messaging. 3.3.1.30. JoeK: But TGk reports many of the parameters (e.g. queue depth). I need to understand what’s new. 3.3.1.31. PatC: We are out of time. Perhaps this can be discussed off-line. Is there any objection to continuing the ad-hoc activity? No. Alex would you like to summarize the work of the Diagnostic sub-group? OK.

3.3.2. Review of Comment Resolutions 3.3.2.1. Alex Ashley presented document 06/1819r0, “comment-resolution-tgv- internal-review-diagnostics-category” with suggested comment spreadsheet resolutions for the “Diagnostics” subgroup. These are results of going through the comments in the diagnostic sub-group of Alex Ashley and Bob Miller. 3.3.2.2. Secretarial note: The following is an abbreviated record of the dialog on these comments. It is suggested that members review the detailed spreadsheet resolutions for better understanding. 3.3.2.3. Comment 47: Accepted, reduce to 1 octet. OK Alan? Yes. 3.3.2.4. Comment 49: This is one of several similar comments. Table rearrangement to put reserved at bottom. Deferred because of consistency with other uses. Group recommendation is to accept commenter’s approach: Instruct editor to rearrange table to put “reserved” on bottom, “none” on top and move those in the middle down. 3.3.2.5. Comment 50: Abort reason 0 is strange. We countered with “unknown”. Allan suggests “unspecified” No objections. 3.3.2.6. Comment 51: The profile ID appears to refer to the programmed characteristics of a device. Seems to require a contribution, with Tim Olsen or Bob O’Hara encouraged to respond with a contribution (nominated by chair). 3.3.2.7. Comment 53: Similar to previous table rearrange. A lot of discussion and conjecture. Agreement this section needs work. Emily volunteers to address. Similar to 199, also directed to Emily. 3.3.2.8. Comment 76: Suggests that diagnostics should not be limited to 1 at a time. BobM says precedent exists in TGk. Allan argues that if station can support nesting, why not? Agreement: Take offline with Emily, Joe Kwak, and Allan. 3.3.2.9. Comment 77: Suggests removal of STA-STA diagnostic capability. Some feel channel load, etc. could be useful. Others, including BobM and Allan feel that in infrastructure mode there seems little reason for this to be used. Resolution: Counter: Import table 79A from TGk outlining permissible STA- STA measurements and duplicate service for diagnostics. Emily will add table. Dorothy: Since we are an amendment, we could reference the table instead of pasting. Allan: The TGk schedule may change, though. Dorothy: This is a reference to a non-approved amendment. We believe it will be available though. Agreed: Allan will provide normative text.

Submission page 14 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

3.3.2.10. Comment 198: Resolution is to assign to Bob O’Hara (assigned by chair), since Abort Reason is not used elsewhere. 3.3.2.11. Comment 227: Resolve to incorporate TGn rates: Expand number of octets. Granularity rounding not an issue with expanded field. OK with group? Yes. 3.3.2.12. Comment 232: Assigned to Bob O’Hara by chair 3.3.2.13. Comment 233: “Radio channels” does not specify regulatory class. Accepted. OK? Yes. 3.3.2.14. 246: Regulatory domain. Dorothy: This has to do with much proprietary stuff. All part of same section. What are operating parameters and where are they defined? They seem to be like manufacturer model string, OIY, etc. PatC: Section is not labeled well. Dorothy: All of these are in Diagnostic Information Elements. When client asks for 7.3.2.39.1, this defines which DIEs are used for a client report. I also found this confusing. The client report for manufacturer information is 9 items, then operating parameters is another 9, so a subset of all items. Subbu: This is decided by AP anyway, the client can’t choose these. Should reject comment, as regulatory domain is determined by the AP. 3.3.2.15. Comment 330: Accepted. Recall on phone conference the names were said to be confusing. OK? Yes. 3.3.2.16. Comment 332: Accepted. OK? Yes. 3.3.2.17. Comment 333: Accepted. OK? Yes 3.3.2.18. Comment 334: Dorothy: I was referring to the heading, which seems better characterized by “Diagnostic Information Element”. PatC: That’s pretty lengthy. Dorothy: Yes, but accurate. Emily: Originally Diagnostic Information Element was meant to refer only to things mentioned in TGv. Dorothy: The language is very overloaded…element, sub-element, etc. Deferred and Assign to Emily, who will make this consistent with other edits. 3.3.2.19. Comment 335: Change “Abort Reason” to “Reason Code” Accepted. OK? Yes. 3.3.2.20. Comment 337: Change client to STA everywhere. Accepted. OK? Yes. 3.3.2.21. Comment 341: Accepted. OK? Yes. 3.3.2.22. Comment 344: Accepted. OK? Yes. 3.3.2.23. Comment 348. Some feel layering is a good thing. Dorothy: This doesn’t use many of the 255 states, and it seems reasonable to migrate the client report breakouts directly into the parent table. Dorothy agrees to create a recommended structure as a contributution. 3.3.2.24. Comment 396: Accepted. OK? Yes. 3.3.2.25. Comment 299: Moved to Roaming Management Group. OK? Yes. Emily: Yes this was an error, and I will move it to the correct category. 3.3.2.26. PatC: This completes review of the comments on Diagnostics. Shall we recess to ad-hoc groups? No objection.

3.4. Closing

3.4.1. Recess 3.4.1.1. PatC: Is there any objection to recessing for the ad-hoc? No. We are recessed. 3.4.1.2. Recess at 1518

Submission page 15 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

4. Thursday Morning Session, November 16, 2006

4.2. Opening

4.2.1. Call to Order 4.2.1.1. Pat Calhoun (PatC): I call the meeting to order. 4.2.1.2. Meeting convened at 0800 hours. 4.2.1.3. PatC: Today, we shall begin with scheduled presentations, and then address comments.

4.3. Process

4.3.1. Review of Agenda 4.3.1.1. PatC: JoeK, you will be presenting first? 4.3.1.2. JoeK: Yes. 4.3.1.3. EmilyQ: I will need some time for a presentation this afternoon. 4.3.1.4. PatC: OK.

4.3.2. Presentation of Document 06/0956r2 4.3.2.1. Joe Kwak presented document 06/0956r2, “Preferred Channel for Power Saving”. The concept was developed primarily for low-power (e.g. dual mode) devices. This presentation has been updated to include European rules for using fixed channels, which disallow non-uniform channel allocations. Accordingly the new submission moves the channel each day. The presentation identifies currently-specified channel space, but choice of channel is not fixed. Passive scanning by stations is used to determine which channel is active at a particular time. 4.3.2.2. PatC: What happens if radar is detected on one of the channels? 4.3.2.3. JoeK: The AP would have to detect the presence of the radar via passive scanning or other information, and not use the channel. 4.3.2.4. Paul: What if the radar disappears? How do you know? 4.3.2.5. JoeK: The channel is cleared by the AP. Periodically the AP revisits the channel. If the radar is no longer present, the channel can be used again. 4.3.2.6. JoeK: [resumes] A preferred channel set is provided. The channel to be used is determined by the RC-4 random number generator, also used by WEP. The seed is based on the date. The Preferred Channel Order is used to indicate the chosen channel to STAs. [802.11] phones use more power than regular handsets currently, and coverage of [802.11] is more spotty than cellular. Accordingly, the approach results in perhaps 80% power saving. An STA can “bootstrap” into the network by listening for a channel where the NetAd (Net Advice) information is present from other STAs (or from an AP). The APs control the process of NetAd transmission by STAs. 4.3.2.7. DavidHunter: Legacy devices couldn’t do this? 4.3.2.8. JoeK: Only 802.11v and beyond devices. The AP will instruct at least one STA currently in use to transmit the NetAd frame every beacon period to ensure that entering STAs will hear it when scanning. A “baton pass” procedure is used to spread the NetAd transmission duty among all participating STAs. The method eliminates the need to have a separate AP to transmit NetAds. The presentation shows how STA states are maintained for NetAd “duty”. Companion document 06/1462r1 contains proposed normative text.

Submission page 16 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

4.3.2.9. BobM: What happens at the edge of two cells? 4.3.2.10. JoeK: The STAs may advertise “across the edge”, but since the channel will be the same, there shouldn’t be a problem. 4.3.2.11. AlexA: Can you explain how different channel selections are made since this is a random process? 4.3.2.12. JoeK: We are just encouraging randomness on the channel determination, however since the seed is based on the date, the channel chosen everywhere will be the same. 4.3.2.13. AlexA: Then it’s really just a hash on the date? 4.3.2.14. JoeK: Yes. 4.3.2.15. DavidH: I’m concerned about legacy stations. Will they ignore these frames, but otherwise be unaffected? 4.3.2.16. JoeK: Yes, but of course they will not benefit either. 4.3.2.17. Subbu: Would this work with IBSSs? 4.3.2.18. JoeK: No, I don’t believe so. It’s really only for network-connected systems. 4.3.2.19. AllanT: I’d like to understand the randomization function. A set of APs will choose the same channel for all of them? 4.3.2.20. JoeK: Yes, they will all choose the same channel because they will all use the same seed. The date produces the seed. 4.3.2.21. AllanT: Then two separate networks side-by-side would choose the same channel? 4.3.2.22. JoeK: Yes. 4.3.2.23. AllanT: But you don’t really want that, right? 4.3.2.24. JoeK: Yes you do. Everyone uses the same preferred channel. 4.3.2.25. Jari: This seems a good idea. However, I have concerns regarding distributed NetAd. How can an AP know how STAs will distribute the information? Should the AP use baton pass or perhaps another method? 4.3.2.26. JoeK: Thanks, Jari. I believe it is premature for adoption of text. I’d like to work further on this concept. Other considerations may also have to be taken into account for STA duty assignments. Features must also be in place to read STA MIB variables. 4.3.2.27. BobM: Can a station refuse “duty” if it is very busy? 4.3.2.28. JoeK: Yes, if it is too busy to transmit a NetAd in a frame, it may skip a frame or more, for example, with no real effect on STAs seeking the preferred channel other than a little delay. Real time activities in the STA always take precedence. 4.3.2.29. BobM: Does this impact frequency reuse in adjacent cells? 4.3.2.30. JoeK: No, it shouldn’t. It simply tells what the preferred channel is. 4.3.2.31. QiW: How do two networks resolve channels from day to day? 4.3.2.32. JoeK: All of the STAs will be competing for NetAd duty, and it is up to the AP to choose whether the advertisement will be turned on or off. 4.3.2.33. Subbu: But if turned off, you still have to go through a virtual information process? 4.3.2.34. JoeK: APs may choose that they don’t want to advertise the channel, and then the channel would have to be deduced. STAs have to listen. 4.3.2.35. PatC: Is there a Straw Poll? Yes. 4.3.2.36. Do you support use of Net Advice on designated Preferred Channels to improve STA power saving? 4.3.2.37. Yes 11 4.3.2.38. No 6 4.3.2.39. Abstain 13

Submission page 17 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

4.3.2.40. Sudheer: If you took a straw poll but left out the STA duty-sharing, would that be valuable? 4.3.2.41. JoeK: That option is available already. 4.3.2.42. Sudheer: No, I mean no STA transmissions. 4.3.2.43. JoeK: OK, I see. 4.3.2.44. PatC: Joe, do you want another poll? Yes. 4.3.2.45. Do you support use of NetAd on designated Preferred Channels by APs to improve STA power savings? 4.3.2.46. Yes 12 4.3.2.47. No 1 4.3.2.48. Abstain 12 4.3.2.49. JoeK: The only issue with this is that it could take some time for TGv APs to propagate the information, and the default state of the enable bit could be a problem. 4.3.2.50. PatC: Joe, we’re out of time on this one. Have you another?

4.3.3. Presentation of Document 06/0388r5 4.3.3.1. Joe Kwak presented document 06/0388r5, “Extended Channel Switch Response”. This presentation proposes to add provides a simple response frame to address TGv objective #2000, Dynamic Channel Selection. This requires a switch with no interruptions. It augments the announcements in beacons and in the stand-alone frame adopted in the last meeting, providing a needed feedback mechanism to ensure continuity of service. The response is optional. We add the optional dialog token to invoke a response before the STA switching. Document 06/1485r1 provides companion normative text. Extended Channel Switch Response (6) state is added to the operative Extended Channel Switch Announcement Frame field. The STA can also indicate that it is switching, but will not sustain the session. The response feature is particularly important for QoS streams, for which transfers are made more seamless and reliable. 4.3.3.2. Sudheer: Was there another channel switch proposal in this session? 4.3.3.3. PatC: Yes, it focused on consistency with TGn and TGy. 4.3.3.4. Sudheer: The TGy one is doing a little more than this one. I suggest that you coordinate with the other authors. 4.3.3.5. AllanT: An AP can learn which stations will go with him. What does this add on top of that? 4.3.3.6. JoeK: Channel Switch was never intended to treat availability or desirability of the channel for switching. This allows TGk to make measurements of prospective channels to aid in the choice. This is a very rare event, but needs to be reliable. 4.3.3.7. AllanT: In Rev 802.11ma rev9, there already seems to be a mechanism. JoeK: The decision to switch the channel may not be preceded by an extended process of data gathering such as expressed in that procedure. 4.3.3.8. BobM: May I understand that two important applications might be for radar and channel reuse reorganizations when you have to bring sessions along. 4.3.3.9. JoeK: Hadn’t actually thought a lot about the applications, but I guess that’s so. 4.3.3.10. PatC: Do you want a straw poll? Yes 4.3.3.11. Do you support the addition of an Extended Channel Switch response to improve seamless channel switching? 4.3.3.12. Yes 9 4.3.3.13. No 2

Submission page 18 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

4.3.3.14. Abstain 14 4.3.3.15. PatC: Any other business, Joe? No.

4.3.4. Adjustment of Agenda 4.3.4.1. PatC: Emily, you wanted to reserve time? 4.3.4.2. Emily: Yes 5-10 minutes. I also need another slot. 4.3.4.3. PatC: Would 1630 to 1640 be OK? 4.3.4.4. Emily: Yes 4.3.4.5. Donghee: I also need 20 minutes. For two documents. 4.3.4.6. PatC: OK. Emily, what’s your document number? 4.3.4.7. Emily: 06/1851 4.3.4.8. PatC: Very well, I have modified the agenda as shown:

TGv Text Submissions – 08:00-08:45 - 11-06-1462-00-000v-Preferred Channel Power Saving – 08:45-09:00 – 11-06-0387-01-000v-BSS Channel Switch – 09:00-09:40 – 11-06-1828-00-000v-admission-control-traffic-request – 09:40-10:00 – 11-06-1851-00-000v-tgv-internal-reviewcomment-resolution-event-log (part 1) • 10:00 – Break • TGv Text Submissions – 16:00-16:30 – 11-06-1725-00-000v-normative-text-proposal-QoS-aware-load-balancing – 16:30-16:40 – 11-06-0943-06-000v-Idle Mode Operation in IEEE 802.11 WLANs – 16:40-17:00 – 11-06-1836-00-000v-sta-provided-location – 17:00-17:05 – 11-06-1828-01-000v-admission-control-traffic-request – 17:00-17:30 – 11-06-1851-00-000v-tgv-internal-reviewcomment-resolution-event-log • Address Internal Review Comments • Timeline Chart Discussion • Objectives Review • Plans for November • New/Old Business • Adjourn

4.3.4.9. PatC: Does everyone approve these changes? Yes.

4.3.5. Presentation of Document 06/1828r0 4.3.5.1. Dorothy Stanley presented document 06/1828r0, “Admission Control Traffic Request”. This is a proposal for the addition of capability for a station to indicate a traffic request via a probe response and determine if such traffic entry would be granted. This is meant to be a “pre-association” method for determining if resources are available and admission would be granted. Now stations have to infer whether a specific request for service would be granted; this would provide a more direct method. This is shorter than a TSPEC. 4.3.5.2. AllanT: In 802.11k there is an Admission Class Compatibility Element, which includes the category 7.3.43 in 11k, at the bottom of page 53. 4.3.5.3. DorothyS: 802.11k works on an aggregate basis, not as specific information. There is no guarantee that if the 11k response is received that the entry would be granted. 4.3.5.4. DaveStephenson: You are asking the AP to say what could happen in the future. This seems superfluous in light of the availability of the 11k information. 4.3.5.5. Dorothy: But this does not require association. 4.3.5.6. Sudheer: I have semantic suggestions, however I think the idea is good. I suggest the word “query” or “indication” rather than request. I agree with the general comment regarding the 11k feature. Why don’t you include the available admission capacity instead of a new metric? 4.3.5.7. DorothyS: This is not a guarantee, but is a specific response to an STA.

Submission page 19 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

4.3.5.8. Sudheer: We should not say, “the STA shall reserve the medium…” 4.3.5.9. JoeK: This could be useful to gather pre-“r” information. It would be useful if we could coordinate all of these “beacon things”, though. The beacons are getting overloaded. It would help to package loading, latency, and other information into a separate “package”, perhaps such as this. 4.3.5.10. Sudheer: This is also allowed in probe response. 4.3.5.11. JoeK: The probe response would be a good way to do this. 4.3.5.12. Dorothy: The proposal is here, and I am not interested in rolling all of this together. I just want feedback on this specific piece. I’d like to ask Pat for10 minutes this afternoon to present the wording change. 4.3.5.13. PatC: Would 5 minutes suffice? Yes. 4.3.5.14. BobM: What does the AP return, a real value, or just an indication? 4.3.5.15. Dorothy: Codes that show various conditions. 4.3.5.16. DaveS: Even if this were to happen, there is no guarantee that when the station associates, the resource would be granted. Also I’m confused about the use case. The aggregate information has been mentioned, but I can’t foresee a case where this different information would be valuable. 4.3.5.17. DorothyS: There are many things that could happen to change the conditions. 4.3.5.18. DaveS: There are many factors which contribute to BSS load. I worry about accuracy. 4.3.5.19. BobM: That’s why I asked about a real value, or just an indication. 4.3.5.20. Dorothy: This is just to help the STA get information with less complexity than forwarding a TSPEC. 4.3.5.21. DaveS: I thought you made a statement that the aggregated basis is not enough information. What case would require otherwise? 4.3.5.22. DorothyS: The station might need information to respond a specific request. 4.3.5.23. Nehru: Use of beacons could affect interoperability. This also puts a load on the AP for computing the response. This could impact service. 4.3.5.24. BobM: For HCCA, this is just an abbreviated scheduler request. 4.3.5.25. Sudheer: I have a problem with probe requests. Also the available medium time is now presented in a variety of ways: admission capacity, load element, etc. Your request and TSPEC request are enough different so that there could be a conflict that might produce a different interpretation for the STA. 4.3.5.26. DorothyS: Let’s work on the reason codes. I do not think we introduce multiple definitions of the same parameter. 4.3.5.27. Sudheer: We could simply put in, for example, available admission capacity. 4.3.5.28. Dorothy: I don’t think that accomplishes what we had in mind. 4.3.5.29. PatC: OK. Is anyone here from DoCoMo? He was here yesterday, but not now. OK let’s look at comments resolutions. Emily, are you ready?

4.3.6. Review of Comment Resolutions 4.3.6.1. Emily Qi presented the latest TGv informal comment resolution spreadsheet, 06/1851r0. If you have any concerns about the accepted comments, make note of them. Let us view primarily deferred and countered… 4.3.6.2. Secretarial note: The following is an abbreviated record of the dialog on these comments. It is suggested that members review the detailed spreadsheet resolutions for better understanding. 4.3.6.3. Comment 312: suggests remove “filter”. Emily: OK? Yes.

Submission page 20 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

4.3.6.4. Comment 314: “associated” APs are also confusing. Dorothy: suggest leave as “source” for now, and reject. PatC: reject how? Dorothy: (it’s her comment) It’s as good as “associated”. 4.3.6.5. Comment 317: Counter. PatC: Everyone OK with recommendation? Yes. 4.3.6.6. Comment 318: OK with response?. Objections? None. 4.3.6.7. Comment 326: The field would be included only when needed, but there are new ATMs coming. Generalization would be valuable. Decline and let 11r publish. PatC: OK? Yes. 4.3.6.8. Comment 70: If STA is incapable of generating event report, the STA shall return “incapable”. AllanT: If STA does support the feature but can’t respond to that one, fine. But shouldn’t we have another one if STA isn’t equipped to support any? Emily: Maybe just at that moment the STA can’t report right away. AllanT: your extensions make sense if the client can support, but if not able to respond on any, then he shouldn’t advertise the capability. If that is in the text OK, otherwise it should be added. Emily: I think this is in the document. Page 135, lines 39-41. 4.3.6.9. Comment 72: Emily: On 72, Allan are you going to take that one? Allan: Yes, I will accept.. 4.3.6.10. Comment 73: Line 22, 11.15.2.2 Group examines sentence in comment. PatC: That seems to cover it. Allan, is that not what it means to you? Yes, OK. 4.3.6.11. Comment 236: Declined. Request type is a needed thing. AlexA: OK, agree. 4.3.6.12. PatC: We have reached 1000 hours, so we must stop. I think we may be able to finish this afternoon, but we won’t be able to vote on anything. 4.3.6.13. EmilyQ: We haven’t changed anything, so we may be able to vote these in. 4.3.6.14. DorothyS: We learned from Bob O’Hara yesterday, that things that direct the editor to change the draft have to be approved subject to the 4-hour rule. 4.3.6.15. PatC: I shall check with Bob O’Hara. We also may have to authorize an ad- hoc. 4.3.6.16. AllanT: For the record - FBMS shows 100 mSec. 4.3.6.17. Joe: Emily, In your next draft will you be publishing red-lines? 4.3.6.18. Emily: Yes. There will be information on resolutions and adopted material.

4.4. Closing

4.4.1. Recess 4.4.1.1. PatC: Is there any objection to recessing? No. We are recessed. 4.4.1.2. Recess at 1003 hours.

5. Thursday Afternoon Session, November 16, 2006

5.2. Opening

5.2.1. Call to Order 5.2.1.1. Pat Calhoun (PatC): I call the meeting to order. 5.2.1.2. Meeting convened at 1600 hours. 5.2.1.3. PatC: Emily has asked me if we could rearrange the presentations so she could go first. I there any objection to changing the order of presentations on the agenda? No. Seeing none the agenda is rearranged.

Submission page 21 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

5.3. Process

5.3.1. Presentation of Document 06/0943r8 5.3.1.1. Emily Qi presented document 06/0943r8, Idle Mode Operation in IEEE 802.11 WLANs. This presentation was given on Wednesday. At that time two suggestions received. One deals with security, and it has been dealt with. We have also added a new ACK within the idle mode. 5.3.1.2. PatC: Is there any objection to allowing Allan to provide an update on the power-saving data? No.

5.3.2. Presentation of Document 06/1872r0 5.3.2.1. Allan Thomson presented document 06/1872r0 “Idle Mode Power Saving Analysis”. Emily presented a Paging vs. Legacy analysis without background scanning. Clients have to scan to find a beacon in order to receive a page. If a client isn’t moving there will be no savings. The graph shows paging with scanning and legacy without scanning. This is an apples/oranges comparison. With background scanning the analysis shows 14%, but it is actually only 7%. Paging vs. Legacy with background scanning at 1 roam per hour saves 30 minutes of battery life over the course of 50 hours. This appears unrealistic. In a competing analysis a more realistic roam rate was assumed as one roam per hour, over a 10 hour workday. An assumed single trip away from the desk roaming causes passing 8 APs going to/from meeting. Therefore, there are 8 roams per hour in 10 hours. Over 24 hours, the average roam rate is 3.3 roams/hour. Difference is 50.8 hours standby to 50.2 hours standby time, only a 1.2% improvement. 5.3.2.2. On the infrastructure side, this proposal engenders significant complexity, and this seems to deliver insufficient benefit. Summarizing: small power savings for unjustified complexity. 5.3.2.3. Emily: This was a team effort and we ran several simulations by various teams. These agreed well. 5.3.2.4. AllanT: I think we should look at other systems, including simpler ones, and hold them all up to the same metrics. 5.3.2.5. Emily: We did not count the background scanning. Paging mode is idle mode, so no scanning is required. For legacy devices, connectivity must always be maintained, requiring a lot of scanning. On slide #4, if the roaming number would appear to be zero, however legacy devices do not have an idle/paging mode. 5.3.2.6. JoeE: Allan, on slide 6, the thesis is that if there is not a lot of roaming, there is not much benefit, right? Where did the roaming assumptions come from? 5.3.2.7. AllanT: This was measured at our company. 5.3.2.8. JoeE: These assumptions would seem to indicate “r” is superfluous, if you believe your data. In some usage cases, it is possible that handoffs may actually occur when clients are stationary. Next point is slide three, bullet three. Active and passive are mentioned, why? 5.3.2.9. AllanT: Scanning could be either. At 5 GHz you could use active, but mostly the activity would be passive. 5.3.2.10. JoeE: On slide 5, you asked if 50 reassociations cost 30 minutes of battery life. We think that turning on your transmitter is quite inefficient. This presentation seems insufficiently documented to delay consideration of this proposal. Do you have real data or is this intuition? 5.3.2.11. AllanT: I believe if you could show a strong case for savings, we would not be debating the issue. 5.3.2.12. JoeE: So is the data based on intuition? 5.3.2.13. PatC: Asked and answered. Submission page 22 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

5.3.2.14. BobO’Hara: Every two seconds the station needs to awake and see if something is there for it. How do you account for this? 5.3.2.15. Emily: For paging, two seconds. But background scanning was not covered in slide three of Allan’s presentation. We believe background scanning is more appropriate. 5.3.2.16. BobO: The channel report is available in 11k. Why would an idle mode/paging client be better at using this than a legacy device? 5.3.2.17. Emily: If you refer to my presentation, you will see both modes without scanning. 5.3.2.18. BobO: The paging mode station turns off everything, but a legacy system can’t? 5.3.2.19. Emily: The legacy client has to stay in active mode, while a paging mode client can reduce its power. 5.3.2.20. BobO: But any (even legacy) device could turn off if it believes it will have no need to connect. The roaming analysis would seem to indicate 1 roam/hour over the life of the battery costs a lot of power. The whole process would seem to cost only 300 frames. You are saying that the 150 transmissions and receptions cost a lot of power? 5.3.2.21. Sudheer: I am one of the authors of this presentation. Allan asks a very fair question. Our analysis appears flawed. There is a very significant advantage, and we want to come back with a corrected analysis. The numbers chosen represented the very best legacy case. We should probably come back with some numbers. 5.3.2.22. Emily: Can you go back to slide 6, Allan? This is a typical enterprise user. I am a good example: I am almost always in motion. This represents a case like me at work. There is another case considered that is even more mobile. In citywide applications, where there is even more walking. 5.3.2.23. Allan: In enterprise cases, though, users don’t really take their phones home, so they don’t actually care about 24 hours of use time. 5.3.2.24. RogerD: I believe Allan’s assumptions are PC-related, not mobile handheld device-based. 5.3.2.25. Allan: I think this use case is just one use case. 5.3.2.26. RogerD: I think the scanning scenarios [in Emily’s proposal] are very realistic for legacy devices, so I think the analysis would show significant benefits. 5.3.2.27. AndrewMyles: At least one of the authors feels the analysis is flawed. I think we should withdraw the motion and come back next time after working with Allan for a better presentation. 5.3.2.28. Rajnish: Even if we roam once per hour we still need security. I see yet another security issue. Also STAs are also APs. 5.3.2.29. Henry: I have a concern about Legacy vs. Idle mode. I get the impression people are using the terms differently. Another item is differentiating a “new” STA (e.g. TGma and TGk) taking advantage of everything in the standard currently, as differentiated from the “pure” legacy case? 5.3.2.30. MooY: We are talking about the power saving component of paging, but it is not just for power savings. There are other advantages: Fewer handoffs, reduction of messaging, and reducing of AP overhead. This may not be significant for all cases, but it will help a lot in some. If we have this capability as in this room and everyone leaves, all the people in the room will try to handoff at the same time. With paging, we can distribute this activity. 5.3.2.31. Allan: I think paging does reduce some messages, but it also increases beacon loading. Depending on how many people are going into paging, this will use a lot of capacity, and that will affect all of those who are listening to beacons. We are saving some messages, but we’re also adding a lot of overhead.

Submission page 23 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

5.3.2.32. JoeE: I want to emphasize that we originally wanted paging so that it reduces handoff volume which can improve system stability. Also my “back of envelope” analysis here shows perhaps 3W of savings which is significant. 5.3.2.33. PatC: Yes but your impromptu analysis is not compelling at this point. 5.3.2.34. Dorothy: For the record, the additional key hierarchy mentioned by Rajnish is optional. 5.3.2.35. PatC: Let’s move ahead as we are already past our allotted time. 5.3.2.36. Move to include normative text in document 11-06/0943r8 into the TGv draft. 5.3.2.37. Moved: Emily Qi 5.3.2.38. Seconded: Sudheer Matta 5.3.2.39. PatC: Is there discussion? Yes. 5.3.2.40. AndrewM: We should table this motion until next meeting, as the presenters have admitted the analysis is flawed. 5.3.2.41. Sudheer: The analysis is not flawed, I was only indicating that the assumptions may not be the right ones. 5.3.2.42. Henry: I think we need an analysis of how much traffic this reduces. 5.3.2.43. Point of order: Don’t we have to complete this motion? 5.3.2.44. AndrewM: I wish to make a motion to table the motion on the floor. 5.3.2.45. Harry: [to floor] Please speak only when recognized by the chair. 5.3.2.46. Myron: Point of Order. Don’t we have to finish this motion? 5.3.2.47. PatC: No. The motion to table ends debate. 5.3.2.48. AndewMyles: 5.3.2.49. Move to table Emily’s motion until 2nd meeting of the January Session of TGv in January, London. 5.3.2.50. Moved: Andrew Myles 5.3.2.51. Seconded: Henry Ptasinski 5.3.2.52. PatC: Is there discussion? Yes. 5.3.2.53. Emily: I speak against the motion. This is the eighth draft, and has been gaining support for several meetings. 5.3.2.54. BobO: You must speak of this motion not the original. 5.3.2.55. JoeE: I speak against the motion. We should give the proposal an up/down vote. 5.3.2.56. PatC: Any further comments? No. 5.3.2.57. For 10, Against 28, Abstain 1 5.3.2.58. The motion fails. 5.3.2.59. PatC: We are now back to the original motion. Any discussion? 5.3.2.60. Joe E: Call the question. 5.3.2.61. PatC: Is there any objection to calling the question? No. Very well, we shall vote on the motion. 5.3.2.62. For 25, Against 12, Abstain 4. The motion fails. 5.3.2.63. EmilyQ: Thank you.

5.3.3. Presentation of Document 06/1726r1 5.3.3.1. Fujio Watanabe presented document 06/1726r1, on “QoS-Aware Load Balancing”. The presentation suggests gathering more data to better- execute load balancing of QoS streams. It advocates use of an enhanced statistics request/report which provides data by access category. This information can be used for better AP selection during load balancing. 5.3.3.2. Sudheer: Referring to the frame format, the Number of Stations Count was a flawed concept at the outset, because it means nothing since it doesn’t map Submission page 24 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

to real load. I suggest not propagating this TGk “misery” further. Second, there is an available admission capacity IE already available that would seem to accommodate what you’d like to do. I think it would be better to use existing capabilities. 5.3.3.3. Fujio: This information is considered after the AP decides on admission control, then the AP will notify regarding the process. 5.3.3.4. Sudheer: But you don’t know what the maximum is, so you should take into account current parameters. 5.3.3.5. AllanT: Same point. 5.3.3.6. JohnBahr: I agree with Sudheer on station count. You should be aware that in TGk there is an admission count that basically gives you what you want here. It gives you channel utilization vs. access category. You could infer the number of stations with this. K and ma also have load elements which could be used. I suggest you present this document in TGk. 5.3.3.7. BobO: Point already made. 5.3.3.8. Straw Poll 5.3.3.9. Is Task Group V supportive of 11-06/1725r0 and interesting in having author draft normative text for inclusion into the TGv draft. 5.3.3.10. Yes 12 5.3.3.11. No 11

5.3.4. Presentation of Document 06/1835r0 5.3.4.1. Donghee Shim presented document 06/1835r0 on Location Capability, which was presented before. Comments were received from Dorothy and Allan, and their suggestions have been incorporated. There is no current ability to allow an STA to send location information unsolicited. The presentation advocates addition of a Location Descriptor Element in the Presence Parameters Element List. Normative text may be found in 06/1836r0 5.3.4.2. PatC: Donghee cannot make a motion, as he is not a voting member. Is anyone else willing to make the motion on his behalf? Yes. 5.3.4.3. Move to include normative text in document 11-06-1836-00-000v-location- capability changes to the 802.11v into the draft 5.3.4.4. Moved: Dorothy Stanley 5.3.4.5. Seconded: Allan Thomson 5.3.4.6. PatC: Is there any discussion? No. 5.3.4.7. For 9, Against 0, Abstain 9. The motion passes

5.3.5. Presentation of Document 06/1828r1 5.3.5.1. Dorothy Stanley presented document 06/1828r1 on “Admission Control Traffic Request”. In the interest of not repeating everything, only changes from revision 0 will be covered. The terminology has been changed to admission control query, with expansion of reason codes. There is no implication that admission will be granted. 5.3.5.2. PatC: Are there questions? Yes. 5.3.5.3. Allan: This request is going to cause the AP to answer. Do you expect it will be able to do that in a timely way? 5.3.5.4. Floor: That is an implementation issue. 5.3.5.5. Subbu: So you’re basically going to probe to an AP that you may not associate with, building airtime use. There are mechanisms in TGk to handle this without expanding the message vernacular. 5.3.5.6. Dorothy: This is not going to change the overall volume, just the way the information is obtained.

Submission page 25 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

5.3.5.7. BobOHara: The only difference is that it shifts the burden to the AP from the station and in doing so forces it to compute the traffic to all stations. 5.3.5.8. Subbu: It is not a requirement to do this. One can set policies that determine the extent to which this is necessary. 5.3.5.9. Move to include normative text in document 11-06/1828r1 into the TGv draft. 5.3.5.10. Moved: Dorothy Stanley 5.3.5.11. Second: Sudheer Matta 5.3.5.12. PatC: Is there discussion on the motion? No. 5.3.5.13. For 6, Against 5, Abstain 9 5.3.5.14. The motion fails.

5.3.6. Review of November Plans 5.3.6.1. PatC: Do we need to plan for ad-hocs or teleconferences? 5.3.6.2. Dorothy: Can we get a status on the progress of the sub-groups? 5.3.6.3. PatC: We are done with the Diagnostics sub-group. Who is working on multicast diagnostics? Dorothy: I think they’re done. Station Statistics? Emily: Done. FBMS: Essentially Done. Presence? Roaming Management 3/28. Extended Channel Switch. Next one? Dorothy: I think they’re done. 5.3.6.4. PatC: Could sub-group folks send me the individual spreadsheets? 5.3.6.5. Dorothy: I suggest we have two ad-hoc teleconferences, one in December, and one in January. 5.3.6.6. PatC: How many contributions are anticipated in January? 5.3.6.7. Dorothy, Alex, and Emily (Idle Mode Paging) express intention to present. 5.3.6.8. PatC: I’ll put together a plan based on these presentations. I’ll plan what we’ll need in terms of meeting time accordingly, allowing some time for new presentations. Do we need to revisit the Timeline chart? I think we won’t change this. 5.3.6.9. Dorothy: I think we have to pick the times of the teleconferences. 5.3.6.10. PatC: What are the rules on this? 5.3.6.11. Floor: 10 days notice. 5.3.6.12. Sudheer: Lots of groups who are anticipating January activities are also planning for teleconferences between January and March. 5.3.6.13. Harry: It is typical that any motion made will extend 15 days past the next meeting, so you can pick up automatically after the next meeting. The last time this is done, e.g. quorum, it is better to pick the dates between this plenary and 15 days past the next plenary. It can always be changed. 5.3.6.14. PatC: Can we say Dec 14th? Dorothy: What time? Perhaps 9 PST (12 EST). In January? 5.3.6.15. Sudheer: I suggest two weeks from the previous meeting. 5.3.6.16. PatC: Then let’s adopt the following… 5.3.6.17. 12/14 at 12 pm Eastern 5.3.6.18. 1/11 at 12 pm Eastern 5.3.6.19. Starting on the 30th of January, until 3/27 every other Tuesday at 12 pm Eastern. 5.3.6.20. PatC: We need an internal motion for teleconferences 5.3.6.21. Motion: Move to empower a TGv teleconference on the following dates: 5.3.6.22. December 14th, 1200 (EST) 5.3.6.23. January 11th, 1200 (EST) 5.3.6.24. Every other Tuesday starting January 30th at 1200 (EST), ending on March 27th

Submission page 26 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

5.3.6.25. Moved: Dorothy Stanley 5.3.6.26. Seconded: Brian Wells 5.3.6.27. Any discussion? Yes. 5.3.6.28. Floor: It would be good to account for the new year. 5.3.6.29. Donghee: I am from Korea. I would like to join. 5.3.6.30. Let’s change the motion… 5.3.6.31. Motion: Move to empower a TGv teleconference on the following dates: 5.3.6.32. December 14th, 2006 1600 (EST) 5.3.6.33. January 11th, 2007 1600 (EST) 5.3.6.34. Every other Tuesday starting January 30th 2007 at 1600 (EST), ending on March 27th 5.3.6.35. PatC: Is there any other discussion? No. Is there any objection to passing this by unanimous consent? Yes 5.3.6.36. Floor: In Europe this is the middle of the night. 5.3.6.37. PatC: We can’t please everyone. How about a compromise as shown? 5.3.6.38. December 14th, 2006 1600 (EST) 5.3.6.39. January 11th, 2007 1600 (EST) 5.3.6.40. Every other Tuesday starting January 30th 2007 at 1200 (EST), ending on March 27th 5.3.6.41. PatC: Is there any objection to accepting this motion unanimously? None. The motion is passed unanimously. 5.3.6.42. Emily: Do we need a motion to empower the editor? 5.3.6.43. Alex: Yes. We need to do that. 5.3.6.44. PatC: I show a motion… 5.3.6.45. Motion: 5.3.6.46. Move to approve the TGv internal review comment resolutions for the comments that are marked as “Accepted” and “Counter” in spreadsheet document 11-06-1819r1. 5.3.6.47. Moved: Alex Ashley 5.3.6.48. Seconded: Emily Qi 5.3.6.49. For 8, Against 0, Abstain 3 5.3.6.50. Emily: We should also empower the editor to create a new draft. 5.3.6.51. PatC: Yes, I show a motion… 5.3.6.52. Motion: 5.3.6.53. Move to instruct the editor to create a TGv draft 0.06 incorporating all of the TGv internal comments that have been approved at the November session. 5.3.6.54. Moved Emily Qi 5.3.6.55. Seconded: Bob Miller 5.3.6.56. For 10, Against 0, Abstain 0 5.3.6.57. PatC: Our last motion will cover the editor’s new draft 5.3.6.58. Motion: 5.3.6.59. Instruct the editor to create a TGv draft 0.07, incorporating accepted normative text proposals from the November 2006 meeting. 5.3.6.60. Moved: Emily Qi 5.3.6.61. Seconded: Brian Wells 5.3.6.62. PatC: Is there any discussion on the motion? No 5.3.6.63. For 10, Against 0, Abstain 0 5.3.6.64. PatC: Let’s go back to the agenda. We have completed all of our old business. Is there any new business? No. Submission page 27 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1757r2

5.4. Closing

5.4.1. Adjourn 5.4.1.1. PatC It is also the end of our session time. Is there any objection to adjourning TGv? No. TGv is adjourned. 5.4.1.2. Adjourned at 1800 hours.

Submission page 28 R. R. Miller, AT&T

November 2006 doc.: IEEE 802.11-06/1759r0

IEEE P802.11 Wireless LANs

Task Group W Meeting Minutes for November 2006 Plenary Session (Dallas, Texas, USA)

Date: 2006-11-13

Author(s): Name Company Address Phone email Matthew 5753 W. Las Positas Blvd Trapeze Networks +1 925 474 2273 msg@trapezenetwor Gast Pleasanton, CA 94588 USA ks.com Nancy Cam- 190 W Tasman Dr., San Jose, [email protected] Cisco +1 408 853 0532 Winget Ca 95134 m

Abstract Minutes of the 802.11 Task Group W meeting held during the IEEE 802 Plenary Session in November 2006 in Dallas, Texas, USA from November 13th – 17th, 2006.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1759r0

Monday, November 13, 2006, 2:00 PM to 4:00 PM Chair: Jesse Walker Recording secretary: Matthew Gast

Call to order and agenda

Meeting called to order on Monday, November 13 at 2:00 pm Central Standard Time (CST) by Jesse Walker. The chair then reviewed the following topics from the agenda:

• The TG Agenda is document number 11-06/1730r1 • Attendance reminder • Jesse Walker read the IEEE patent policy o The membership understood the policy o No letters of assurance were forthcoming from the membership • Other policies and procedures o Inappropriate topics for meetings o IEEE Copyright policy • Policies and procedures o Copyright o Member pledge • Approvals of the minutes of past meetings o September 2006 meeting minutes (document 11-06/1518r0) • The chair asked for corrections; none were required • The chair moved for approval by unanimous consent • There was no objection from the task group, so the minutes are approved o November 2, 2006 teleconference (document 11-06/1634r0) • The chair asked for corrections • The abstract document refers to a TGs teleconference, not TGw. • The chair moved for approval by unanimous conset • Approval of agenda and goals o The chair discussed the agenda for the meeting from 11-06/1730r1 and asked if corrections were necessary • No corrections were necessary, and the agenda was adopted by unanimous consent o The chair asked for submissions • Matthew Gast will present 11/06-1655 on Wednesday o Discussion of how to handle outstanding comments • Comments are in 11-06/1729r1 • The editorial comments were given to the editor to propose solutions to • 188 technical comments remain to be addressed • Jesse Walker suggested working in ad hoc sessions to propose resolutions that go to full task group for approval.

Motion: "Request the editor to propose resolutions of editorial comments received in response to LB88" (This motion is slide 14 in 11-06/1730r1) • Moved by Suman Sharma, seconded by Donald Eastlake • No discussion, and no objection to calling the question • No objection to adopting the motion by unanimous consent (7 voting members present) • Motion passes

Submission page 2 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1759r0

Comment division for ad hocs: The chair asked if there was any objection to recessing to divide the comments. • The group recessed at 2:37 pm CST to divide comments. • After assigning comment IDs and re-sorting to create 11-06/1729r2, the task group re-convened at 2:49 pm CST. • Two group leaders were identified: Jesse Walker and Suman Sharma. The comments were divided at clause 8.4, into technicals CIDs 6-228 and technical CIDs 229-452.

With the comments divided for ad hoc groups, there was no objection to task group recessing until Tuesday at 10:30 am.

Tuesday, November 14, 2006, 10:30 AM to 12:30 PM Chair: Jesse Walker Recording secretary: Matthew Gast

Call to order and agenda

Meeting called to order on Monday, November 13 at 10:32 am Central Standard Time (CST) by Jesse Walker. The chair then reviewed the following topics from the agenda:

• Attendance reminder • Call for presentations o No additional presentations to be added to the agenda

Motion: "Move to accept the resolutions marked group 1 in document 11-06-1729-01" • Moved by Suman Sharma, seconded by Matthew Gast • No discussion, and no objection to calling the question • Vote: 4 in favor – 0 not in favor – 1 abstention • Motion passes

The chair asked if there was an objection to recessing until Wednesday, November 15 at 4:00 pm to enter ad hoc mode at 10:38 am. Seeing no objection, the group recessed into ad hoc mode.

Wednesday, November 15, 2006, 4:00 PM to 6:00 PM Chair: Jesse Walker Recording secretary: Matthew Gast

Call to order and agenda

Meeting called to order on Monday, November 13 at 2:03 pm Central Standard Time (CST) by Jesse Walker. The chair then reviewed the following topics from the agenda:

• Attendance reminder • Agenda o No updates

Presentation: 11-06/1655r0, Pre-Association Frame Authentication, Matthew Gast • Question: When do you get the certificate? After receiving probe? o Answer: The AP uses some set of credentials to sign. If you have not been provisioned by some means, can get the certificate from the AP. The client has no where else to go. It has to have at least the root. • Question: There is no provision for certificate exchange? o Answer: Client can ask for AP's certificate. Submission page 3 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1759r0

• Question: Trying to understand problem statement. Are you trying to protect some pre- association management frames? o Answer: Don't want the client to connect to a rogue AP. Only want to connect to authorized APs. Want more than hints prior to association. Want to address TGu requirement to find legitimate instead of rogue AP to service emergency service. • Comment: The Army wants Probe Responses authenticated. • Question: Are the IE's in signature list ordered? What about fragmented or Duplicate IEs? o Answer: This is not addressed in the normative text, and would need to be addressed.

On completion of the presentation, Jesse Walker suggested recessing until Thursday at 1:30 pm to enter ad hoc mode for further comment resolution. Seeing no objection, the group recessed into ad hoc mode at 3:05 pm CST.

Thursday, November 16, 2004, 1:30pm to 3:30pm

Chair: Jesse Walker Recording Secretary: Nancy Cam-Winget

Call to order and agenda. • Attendance reminder • Call for presentations o No additional presentations to be added to the agenda • No motions

No objections to recess until 16:00pm.

Group recesses until Thursday November 16, 4pm

Thursday, November 16, 2004, 4:00pm to 6:00pm Chair: Jesse Walker Recording Secretary: Nancy Cam-Winget

Call to order and agenda. • Attendance reminder • Call for presentations o No additional presentations to be added to the agenda • No motions

Submission page 4 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1759r0

Discussion for need to meet as adhoc between January and March 2007.

Straw Poll: • Where should we have an ad hoc to resolve LB 88? o Boston: 2 o Santa Clara: 2 (Intel to host)

• When should the ad hoc be held? o January 29-31: 2 (Chosen date) o February: 12-14: 2 o February 26-28: 1

• Teleconferences every other week: o Wednesday 1-2 ET: 3 o Tuesday 4-6 ET: 3 (Chosen date) o Friday 12-1 ET: 1

Motion: Move that TGw hold teleconference bi-weekly starting December 12 2006 at 16:00 ET through the March 2007 meeting. o Moved: Nancy Cam-Winget Second: Jouni Malinen o Passes unanimously

Motion: Move that TGw hold an ad hoc meeting to propose resolutions to LB 88 comments in Santa Clara, CA, January 29-31 o Moved: Donald Eastlake Second: Nancy Cam-Winget o Passes unanimously

Motion: Moved to authorize the editor to create a draft P802.11w D1.01, incorporating the technical resolutions adopted at this meeting and such editorial resolutions as the editor sees fit. o Moved: Donald Eastlake Second: Jouni Malinen o Passes: Yes: 5 No: 0 Abstain: 0

Session adjourns

Submission page 5 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1759r0

References:

Submission page 6 Matthew Gast, Trapeze Networks

November 2006 doc.: IEEE 802.11-06/1871r0

IEEE P802.11 Wireless LANs

TGy Meeting Minutes from Nov 2006 Dallas Plenary Session

Date: 2006-11-25

Author(s): Name Company Address Phone email MS SJ-10-5 Peter Cisco Systems 170 W. Tasman Dr., San Jose, +1-408-527-0815 [email protected] Ecclesine CA 95134-1706 Al Petrick 802.11 WG Vice Chair [email protected] 4450 Arapahoe Ave, #100, Dan Lubar RelayServices +1-877-569-5069 [email protected] Boulder, CO 80303

Abstract Minutes from TGy’s three meetings during the Nov. 2006 Dallas Plenary Session.

Notice: This document has been prepared to assist IEEE 802.11. 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 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

Submission page 1 Dan Lubar, RelayServices

November 2006 doc.: IEEE 802.11-06/1871r0

TGy Meeting Minutes from Nov 2006 Dallas Plenary Session

Proceedings

Tues AM1, Dallas - 19 Attendees - Recording Secretary, Dan Lubar -- Cumberland C meeting room

Agenda ƒ Call to order ƒ Review IEEE Patcom Statement and P&P info ƒ Approval/discussion of Plenary agenda ƒ Review & Approval of prior meeting and telecon minutes ƒ Discussion of Plenary goals and review of current state of draft text ƒ Discussion of PHY & MAC topics ƒ Recess until Thursday AM1

Chair calls meeting to order at 4 minutes past the hour

Chair reminds attendees of Membership and Antitrust requirements associated with participation in the 802 WG

Chair reads IEEE SA patent policy statement and reviews inappropriate topics for discussion

Chair asks all attendees if they understand the statement as read or if any clarification is needed.

Chair asks “Are any matters that the WG chair needs to be aware of?” Hearing none..

Chair asks for Approve and/or Modifications to Agenda (06/1675r0)

Chair asks if there are any changes to Interim minutes (06/1537r0) or subsequent telecon calls (06/1561r0, 06/1608r0), Hearing none..

MOTION: Move to accept the minutes of the TGy Melbourne meeting 06/1537r0 and also minutes from subsequent teleconferences 06/1561r0, 06/1608r0, 06/1674r0 Mover Eldad P Seconder Dan L Approved unanimously MOTION PASSES

Review of Goals for Dallas Plenary Session

Review of Tues AM and Thurs AM agendas

Discussion of 11-06/1432r1 (ECSA)

Discussion of 06/1727r2 (contains changes/text edits specified in Nov 7th Telecon call)

Review of 11-06/1727r2

Discussions include DFS & DEI

Discussion/Review of modulo 256 math and need for self-beaconing. (ie an unsolicited beacon based on traffic flow)

Submission page 2 Dan Lubar, RelayServices

November 2006 doc.: IEEE 802.11-06/1871r0

MOTION: Move to accept 06/1727r2 draft normative text changes and instruct the editor to prepare P802.11y D0.02 Mover Victoria P Seconder Rich K Approved unanimously MOTION PASSES

Begin review of DraftP802.11y_D0.02 (Reference made to footnotes 107 & 109 in FCC 05-56)

Recessed until Thursday AM

Thurs AM1, Dallas – 45 Attendees -- Recording Secretary, Al Petrick - Cottonbowl meeting room

Agenda ƒ CBP TGy/.16h Joint meeting call to order ƒ Agenda approvals or changes--if any ƒ Presentation of TGy D0.02 by Peter E. ƒ Presentation of .16h D1 by Mariana G ƒ Presentation of UCP by Paul P ƒ Further personal comments by 16h chair ƒ Joint meetings adjourned

Joint* 802.11(TGy) & 802.16h Meeting Minutes - 11/16/2006

1. Meeting comes to order at 8:00AM on 11/16/2006 2. Meeting Chairs include; Mariana Goldhamer 802.16h, Al Petrick 802.11y (for Peter Ecclesine TGy Chair) 3. Meeting time 8AM – 10:00 4. Recording Secretary – Al Petrick 5. 45 people in the room 6. Approve Agenda a. No opposition to approve the Agenda as proposed i. Approved by unanimous consent 7. Presentation given by Peter Ecclesine a. Reviewed 802.11y draft D0.02 November 2006 i. Some discussion on Beacon periods ii. Peter E. to make material available to 802.16 WG after documents are posted on 802.11 server (see 06/1830r0 & 06/1865r0) 8. Presentation given by Mariana Goldhamer a. Doc: IEEE802.16h-06/121r1 i. Some discussion 9. Presentation given by Paul Piggin a. Doc: IEEE802.16h-06/117 (Overview of 802.16h Uncoordinated Coexistence approach in 3.65- 3.7GHz i. Some Discussion 10. Presentation given by Mariana Goldhamer: Doc: IEEE 802.16h-06/122 i. Some Discussion on 4msec requirement for 802.11 11. Next steps a. Meet up in January 2007 in London – continue discussion 12. Meeting Adjourn

*also present were dot 18 & dot 19 TAG’s

Submission page 3 Dan Lubar, RelayServices

November 2006 doc.: IEEE 802.11-06/1871r0

Thurs PM1, Dallas – 21 Attendees – Recording Secretary, Dan Lubar -- Cumberland C meeting room

Agenda ƒ Call to order ƒ Approval of agenda ƒ Planning Through March of 07 ƒ Introduction of motions for future work ƒ Meeting Adjournment

Chair calls PM1 meeting to order

Discussion of schedule and goals for upcoming LB’s and also the Interim in London

Introduction of motions to allow LB’s to occur in a timely fashion

MOTION: Instruct the technical editor to rename 802.11y draft 0.02 as P802.11y draft 1.0. Having addressed all comments arising from the WG internal technical review, Task Group y resolves to forward P802.11y draft 1.0 to the working group for the purpose of conducting a 30-day working group letter ballot. The purpose of the working group letter ballot is to forward the draft to sponsor ballot.

The text of the motion to be presented to the working group will be: “Move to authorize a 30-day Working Group Letter Ballot of P802.11y draft 1.0, asking the question “Should the P802.11y draft 1.0 be forwarded to sponsor ballot?”” Mover Victoria P Seconder Dan L Vote: For 11, Against 0, Abstain 0 MOTION PASSES

MOTION: Move to authorize TGy to initiate a Working Group Recirculation Letter Ballot before the March 2007 Plenary, provided all technical comments from WG letter ballot on draft P802.11y D1.0 are resolved. The purpose of the working group letter ballot is to forward the draft to sponsor ballot. The text of the motion to be presented to the working group will be “Move to authorize a 15-day Recirculation Letter Ballot of P802.11y draft 2.0 to be completed on or before March 5, 2007, asking the question “Should the P802.11y draft 2.0 be forwarded to sponsor ballot?” Mover: Victoria P Seconder: Marc J Vote: For 15, Against 0, Abstain 0 MOTION PASSES

Motion to adjourn at 19 past the hour

Meeting Adjourned

References:

FCC 05-56 ( http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-56A1.pdf )

IEEE 802.11 Drafts (in IEEE Member Area) P802.11-REVma-D9.0.pdf P802.11y-D0.02.pdf

TGy Reference Docs: (in ftp.ieeewirelessworld.com) 11-06-0571-00-000y-cbp-tg-telecon-minutes-19-april.doc Submission page 4 Dan Lubar, RelayServices

November 2006 doc.: IEEE 802.11-06/1871r0

11-06-0607-00-000y-TGy-telecon-minutes-3May.doc 11-06-0668-01-000y-3650-3700-mhz-fcc-action.ppt 11-06-0680-01-000y-may-chairs-report.ppt 11-06-0740-00-000y-joint-tgy-rr-tag-may-minutes.doc 11-06-0855-03-000y-Annex-and-J-3650-MHz-band.doc 11-06-0863-02-000y-tgy-june-14th-2006-conference-call-minutes.doc 11-06-0864-04-000y-3650-mhz-mobile-service-enablement.doc 11-06-0867-02-000y-references-mobile-service-enablement.doc 11-06-0873-00-000y-tgy-june-28th-2006-conference-call-minutes.doc 11-06-0922-00-000y-tgy-july-11th-2006-conference-call-minutes.doc 11-06-0955-03-000y-ofdm-phy-3650-mhz-band.doc 11-06-1023-01-000y-proposal-tgy.ppt 11-06-1024-02-000y-tgy-july-chairs-report.ppt 11-06-1120-00-000y-Minutes-from-San-Diego-Plenary-2006.doc 11-06-1374-00-000y-aug15th-and-aug29th-2006-conference-call-minutes.doc 11-06-1427-00-000y-sept12th-2006-conference-call-minutes.doc 11-06-1432-01-000y-extended-channel-switch-announement-normative-text.doc 11-06-1433-00-000y-extended-channel-switch-announement-presentation.ppt 11-06-1466-01-000y-tgy-September-chairs-report.ppt (from Melbourne Interim) 11-06-1536-00-000y-proprosed-draft-revision.doc 11-06-1537-00-000y-melbourne-minutes-september.doc 11-06-1561-00-000y-tgy-sept-26th-2006-conference-call-minutes.doc 11-06-1609-04-000y-tgy-internal-review-comment-submissions.xls 11-06-1830-00-000y-dse-in-licensed-band-operations.doc 11-06-1675-02-000y-tgy-November-chairs-report-ppt.ppt (from Dallas Plenary) 11-06-1865-00-000y-tgy-brief-intro-to-tgy.doc 11-06-1871-00-000y-TGy-2006-Dallas-Plenary-Minutes.doc (this document)

IEEE 802.16 Drafts (in IEEE Member Area) Annex h of dot 16 Draft: IEEE 802.16h-06/004 dot 16h Reference Docs: (from dot16.org) C80216h-06_108r3.doc C80216h-06_121r1.ppt S80216h-06_117.pdf C80216h-06_122.ppt C80216h-06_074r2.pdf

Acronyms/Abbreviations:

DEI dependent enablement identifier DSE dependent station enablement UCP uncoordinated coexistence protocol ECSA extended channel switch announcement

Submission page 5 Dan Lubar, RelayServices

November 2006 doc.: IEEE 802.11-06/1854r0

IEEE P802.11 Wireless LANs

Minutes of WNG SC November 2006 Session

Date: 2006-11-14

Author(s): Name Company Address Phone email Roke Manor Stephen Roke Manor Research, Research Ltd (A +44 1794 833341 [email protected] McCann Romsey, UK Siemens Company)

Abstract

Minutes of WNG SC meeting held during the IEEE 802.11 interim session in Dallas, Texas, USA from November 13th-17th, 2006.

Contents

Executive Summary ...... 2 Morning Session Tuesday 08:00 – 10:00 ...... 2 Multicast Issues Multimedia Application: 11-06-1687r0, Jiyoung Huh ...... 2 Power Saving Limitation for Multicast Applications: 11-06-1747r0, Hang Liu...... 3 Cooperative Cross-Layer Communication: 11-06-1767r0, Monisha Ghosh...... 3 CoopMAC: A cooperative MAC compliant with IEEE 802.11: 11-06-1642r0, Thanasis Korakis ...... 4

Minutes page 1 Stephen McCann, Roke Manor Research

November 2006 doc.: IEEE 802.11-06/1854r0

Executive Summary

Multicast Issues Multimedia Application: 11-06-1687r0 Power Saving Limitation for Multicast Applications 11-06-1747r0 Cooperative Cross-Layer Communication 11-06-1767r0 CoopMAC: A cooperative MAC compliant with IEEE 802.11 11-06-1742r0

Morning Session Tuesday 08:00 – 10:00

WNG SC (Wireless Next Generation Standing Committee) Meeting called to order by TK Tan at 08:03.

The IEEE 802 & IEEE 802.11 Policies and Rules were reviewed. Patents and By-laws read out by TK Tan, together with licensing terms and associated conditions.

3 new people within WNG.

The agenda was reviewed (11-06-1743r0). No comments were raised.

The minutes from the September 2006 meeting (11-06-1493r0) were reviewed. No comments were received.

Move to approve minutes Second: Stephen McCann Unanimous

Multicast Issues Multimedia Application: 11-06-1687r0, Jiyoung Huh

Premise is that current multicast support in IEEE 802.11, is not suitable for high speed video Multimedia transmission. This submission builds on that initially presented in WNG in July 2006. It would be useful to allow multicast transmission for the home environment and possibly the enterprise environment.

Talks about the current unreliable multicast mechanism, which does not use an acknowledgement mechanism. The submission presents 4 separate issues which need to be addressed.

Outcome is to ask for the creation of a new study group to consider this issue.

Comment: Some of these issues (i.e. the multicast acknowledgment) are currently being discussed in TGn

Question: TGv has also added features for multicast adaptation. Is this suitable for this concept, or is more work required. Answer: The work in TGv is only for unicast frames, not multicast. Question: No, in the last meeting, support for multicast rate adaptation was added to TGv. Answer: Ok, this needs to be checked.

Straw poll

Require mechanisms that solve the multicast-related problems and new study group to discuss these

Good idea: 23 Bad idea: 2 Abstain: 22

Minutes page 2 Stephen McCann, Roke Manor Research

November 2006 doc.: IEEE 802.11-06/1854r0

Power Saving Limitation for Multicast Applications: 11-06-1747r0, Hang Liu

This submission presents an overview of the power management scheme in IEEE 802.11 standards and discusses its limitation with regard to the multicast cases. This would be typically useful to live TV and Video on Demand transmissions.

Again it refers to the limitations of the current IEEE 802.11 multicast scheme, especially when considering power saving. It is felt that this is important for light weight battery terminals (e.g. PDAs). Results are shown for various IEEE 802.11 power saving modes.

The conclusion is that a new power conservation system should be designed for STAs.

Question: Have you any idea of a possible solution at this stage? Answer: We have performed some experiments by tuning the system which showed some improvements.

Cooperative Cross-Layer Communication: 11-06-1767r0, Monisha Ghosh

This submission introduces various PHY layer cooperative communication concepts to the IEEE 802.11 community. Significant performance (throughput, range, reliability, etc.) enhancements are possible by the “cooperative” use of STAs in an IEEE 802.11 network, as opposed to “combative” use. Following these strategies all the STAs in a cell can win.

This concept is different from multihop, where STAs are essentially relays within a network. Co- operation can use a partner STAs within the network and utilizes macro-diversity in the receiver as shown in slide 3 (i.e. simultaneous reception of the same frame from difference sources).

The paper then goes onto to present various co-operative methods which have currently being discussed within academia. These operate at both PHY and MAC layers. They would be very useful for in-home networks and provides considerable benefits for video distribution.

Question: Do have any performance comparisons between this system and MIMO. Answer: Only in the academic literature. Errors are a problem. There is a slight protocol overhead. Question: Is this 10%, 20% etc? Answer: Let’s wait for the next presentation

Question: What does cross layer refer to? Answer: This is the interaction of the PHY and MAC layer.

Question: What about antenna relationship between the transmitter, the partner and the receiver. Answer: This work has just assumed single antenna devices. Multiple antennas complicate the issue.

Question: How have you quantified your performance gains? Answer: It depends on various assumptions in the systems.

Questions: Regarding slides 9 and 10, surely this scheme requires synchronization of the transmitter, sender and helper, otherwise phase noise will be suffered during the QAM symbol rotation? Answer: No, as the two sets of received frames are not necessarily received at the same instance. This is a macro diversity scheme not micro.

Question: Regarding slides 11 and 12, doesn’t this imply some extra protocol overhead, in that the sender and the helper have to communication to allow the co-operation to occur. Answer: Yes, but this overhead does not appear to be too much.

Minutes page 3 Stephen McCann, Roke Manor Research

November 2006 doc.: IEEE 802.11-06/1854r0

CoopMAC: A cooperative MAC compliant with IEEE 802.11: 11-06-1642r0, Thanasis Korakis

Again deals with cooperation between the MAC and PHY layers. It presents some of the motivations of co-operation. Essentially co-operation is useful as the wireless link is unreliable.

It builds on the previous submission and shows how receiver combining can work in practice. In addition is has some performance results for IEEE 802.11g with and without co-operation. The results also show channel access delay and energy efficient measurements when using this system.

A demo was constructed with 4 laptops, utilizing 2 helps (partners) and results were presented.

The conclusion is that co-operation in the MAC layer, significantly improves the performance of the system.

Questions: This looks very similar to mesh networking. Answer: Simply because the co-operative scheme does not have to contend for the 2nd hop. This is a clear benefit over mesh networking. Question: But I think you should compare the performance of these two systems. Answer: I don’t really think that is necessary.

Question: I also think this is similar to one-hop mesh, which uses just 1 forwarding station. Answer: Yes, but this co-operative scheme does not use layer 3. Question: I don’t understand, as everything in mesh can be done at layer 2.

Question: What happens if the helper is not available? Answer: But the MAC layer can sense this before hand. Question: But then the helper can collide with other STAs in the same area. Answer: No, as the CTS/RTC protocol will ensure that the helper’s channel is clear.

Chair: we have reached the end of the presentations; as far as I’m aware we have no other presentations queued. There is a WNG session in January 2007, and I would encourage you to send your ideas and topics for presentation to me.

Chair: any final thoughts?

Question: Can we have a straw poll for the need to have a study group for co-operative mechanisms

Straw Poll

Yes : 22 No : 2 Abstain : 22

Chair: Like to encourage people to come back in January to investigate these issues further.

Chair: Move for WNG to adjourn Second: Stephen McCann

No objections.

Meeting adjourned.

Minutes page 4 Stephen McCann, Roke Manor Research