March, 2005 doc.: IEEE 802.11-05/0286r0

IEEE P802.11 Wireless LANs

Approved Minutes of the IEEE P802.11 Full Working Group

Date: 2005-03-14

Author(s): Name Company Address Phone email Tim Godfrey Conexant +1-913-664-2544 [email protected]

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, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

Opening Plenary: March 14, 2005 1.1. Introduction 1.1.1. Meeting called to order by Stuart J. Kerry at 13:30. 1.1.2. The agenda of the 90th session of 802.11 is in doc: IEEE 11-05-0111r3. 1.1.2.1. Stuart notes the proper use of trademarks for the “802.11” name. 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] Philips Semiconductors, Inc., 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 +1 (913) 664-2544 [email protected] Minutes & Reports Terry Cole WG Technical Editor +1 (512) 602-2454 [email protected] Standard & Amendment(s) Coordination Nanci Vogtli Publicity Chair (P SC) +1 (215) 340-2226 [email protected] Communications Teik-Kheong "TK" Tan WNG SC Chair +1 (408) 474-5193 [email protected] John Fakatselis TGe Chair +1 (321) 327-6710 [email protected] Duncan Kitchin TGe Vice-Chair +1 (503) 264-2727 [email protected] Richard H. Paine TGk Chair +1 (206) 854-8199 [email protected] Bob O'Hara TGm Chair +1 (408) 635-2025 [email protected] Assigned Numbers Authority Bruce P. Kraemer TGn Chair +1 (321) 327-6704 [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) 635-2023 [email protected] Jesse Walker ADS SG Chair +1 (503) 712-1849 [email protected] Dorothy Stanley APF AHC Chair +1 (630) 979-1572 [email protected] 1.2. Approval of the Agenda 1.2.1. Stuart notes that the meeting times are noted in 24-hour format. 1.2.2. The agenda is adopted by unanimous consent 1.3. Courtesy notices 1.3.1. Stuart reminds the members about cell phones and prohibitions on photography, per our policies and procedures and IEEE rules. 1.3.2. Anti Trust: Stuart reads the following text to the body: 1.3.2.1. Each Member acknowledges that the Members are committed to fostering competition in the development of new products and services. The Members further acknowledge that they or their employers may compete with one another in various lines of business and that it is therefore imperative that they act in a manner which does not violate any applicable antitrust laws and regulations. 1.3.2.2. Without limiting the generality of the foregoing, the Members acknowledge that the Members will not, in meetings or informal gatherings associated therewith, discuss issues relating to product pricing, methods or channels of product distribution, any division of markets, or allocation of customers or any other topic

Minutes page 2 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

which should not be discussed among competitors in the context of standards meetings or informal gatherings associated therewith. 1.3.2.3. Accordingly, each individual Member sponsor hereby assumes the responsibility to behave in an appropriate manner in this respect and to limit their discussions to subjects that relate to the purposes of the IEEE Standards making process and adhere to IEEE policies and procedures, whether or not such discussions take place during formal meetings or informal gatherings associated with IEEE standards meetings. 1.3.2.4. Any questions? 1.3.2.4.1. None 1.4. Approval of Minutes 1.4.1. Any matters from the minutes of Monterey? None 1.4.2. The minutes of Monterey are approved with Unanimous consent. 1.5. Straw Poll 1.5.1. First time attending an 802.11 meeting: 21 1.5.2. Total number of people in the room 286. 1.6. Treasurers Report 1.6.1. Al Petrick presents document 802.15 05/143r0 1.6.2. Final summary of Berlin meeting. Profit of $54K AU left in AU $ for May meeting.. 1.6.3. Summary for January. Profit for meeting $64K US. 1.6.4. Treasury has $64K as of January. 1.6.5. Discussion 1.6.5.1. What period does the $4500 network equipment storage cover? 2 months. That seems like a lot. Stuart notes we will investigate further, and report to the group. 1.7. Review of Policies and Procedures 1.7.1. Al Petrick presents document 04/424r5 to the body. 1.7.2. Review of working group officers and duties for all wireless working groups. 1.7.3. Review of voting rights, participation requirements, and voting token procedures. There is a new system for indicating voting rights – instead of tokens, there is a printed indication on the badge. 1.7.4. Review of operating policies and procedures, registration, payment of fees. Our P&P is in 04/510r0, which is posted on the web site. Roberts Rules are revision 10 (Gold Book) 1.7.5. Review of rules against photographs, tape recording, and media briefing. 1.7.6. Review of attendance recording process, and contact information updating procedures. 1.7.7. Review of process and requirements for gaining and keeping voting rights. 1.7.8. Membership representation and anti-trust laws are reviewed. 1.7.9. Al Petrick reads the following text to the body regarding IEEE patent policy:

Minutes page 3 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

January 05 doc.: IEEE 802.11-04/424r4 IEEE-SA Standards Board Bylaws on Patents in Standards 6. Patents IEEE standards may include the known use of essential patents, and 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. This assurance shall be provided without coercion and prior to approval of the standard (or reaffirmation when a patent becomes known after initial approval of the standard). This assurance shall be a letter that is in the form of either a) A general disclaimer to the effect that the patentee will not enforce any of its present or future patent(s) whose use would be required to implement the proposed IEEE standard against any person or entity using the patent(s) to comply with the standard or

b) A statement that a license will be made available without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination This assurance shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal and is irrevocable during that period.

Approved by IEEE-SA Standards Board –, March 2003, July 2004

General Agenda Information Slide 12 Stuart J. Kerry - Philips Semiconductors, Inc. 1.7.10. 1.7.11. Al Petrick reads the following slide to the body:

January 05 doc.: IEEE 802.11-04/424r4 Inappropriate Topics for IEEE WG Meetings • Don’t discuss licensing terms or conditions

• Don’t discuss product pricing, territorial restrictions or market share

• Don’t discuss ongoing litigation or threatened litigation

• Don’t be silent if inappropriate topics are discussed… do formally object.

If you have questions, contact the IEEE Patent Committee Administrator at [email protected]

Approved by IEEE-SA Standards Board – December 2002

General Agenda Information Slide 14 Stuart J. Kerry - Philips Semiconductors, Inc. 1.7.12. 1.7.13. Review of copyright status of submissions 1.7.14. Review of meeting etiquette. 1.7.15. Discussion 1.7.15.1. How does a new voter get a voting token? Will answer off-line. 1.8. IEEE SA Letters of Assurance 1.8.1. Stuart Kerry asks for new LOAs

Minutes page 4 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

1.8.2. Masahiro Nakagaki notifies the body that Toshiba has filed an LOA for 802.11n. 1.8.3. He will forward letter to Stuart and Dave Ringle at IEEE 1.9. Announcements 1.9.1. Stuart Kerry announces that Jesse Walker will not be present due to the death of his mother. The group observes a moment of silence. Stuart announces that the group will send flowers to Jesse. 1.9.2. The second edition of the IEEE 802.11 handbook is now available. Bob O’Hara and Al Petrick will be available for signing. 1.9.3. Chairs and CAC members now have ID badges. Harry Worstell personally had these made. We thank Harry for his gesture. 1.9.4. We have created an Email Reflector request form. It will become active after this meeting. 1.10. Key Working Group Events 1.10.1. Interim Sessions 1.10.1.1. May 2005: Cairns Australia. 1.10.1.2. January 2006 – Hawaii – Hilton Waikoloa Village has been contracted. Jan 15-20 1.10.1.3. Considering for May 2006- Seoul, Athens, Istanbul 1.10.1.4. The Yokohama meeting will not be considered due to the meeting fee being $2000 1.10.1.5. Discussion 1.10.1.5.1. Could we consider a possible site in India. Will discuss offline. 1.10.2. 802.11 Website 1.10.2.1. Stuart and Harry display the prototype for the new IEEE website layout. We will get rid of frames. 1.11. Report of ExCom Activities 1.11.1. Report in document 15-05-146 1.11.1.1. Standards board will be meeting here at the end of the week. 1.11.1.2. Dealing with P&P issues, ISO coordination, China. 1.11.1.3. Get802 downloads have exceeded 2 million. Top downloads are 802.11a,b, and g. 1.11.1.4. Downloaded purchased standards have problems with DRM. 1.11.1.5. IEEE ExCom is considering holding one Plenary session internationally. It narrowly passed. Would take effect in 2008. 1.11.1.6. ExCom affirmed that individual membership will continue, (as opposed to entity voting) 1.11.1.7. Quorums at Interims were discussed. There is no resolution yet. 1.11.1.8. A Broadband over Powerline (BPL) PAR was proposed. Already in another part of IEEE (P1900). 1.12. Tutorials 1.12.1. Although we have meetings, 802.11 supports the 4G networks tutorial tonight. 1.12.2. There is also a routing/bridging tutorial tomorrow night. 1.12.3. The WG has affirmed the desire to run meetings during the tutorial timeslots.

Minutes page 5 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

1.12.4. Discussion 1.12.4.1. Recalls that the membership voted to have one evening left open. Request the chair to look into this and address it on the Wednesday plenary session. The WG chair agrees to address this again. 1.13. Network Update 1.13.1. Starting with July, a new network service provider will be used. 1.14. WG Reports 1.14.1. WG Voters Summary 1.14.1.1. We have 482 voting members. We have 89 potential members, and 103 nearly voters. 1.14.1.2. Potential members have met attendance and sending requests. 1.14.1.3. Nearly voters have not sent the email request to establish rights. 1.14.1.4. Harry can handle late requests only as time permits. Please give him time to update voting status. 1.14.1.5. We have an outstanding RFP for new documentation and attendance software. 1.14.1.6. Harry reiterates rules for documentation and formatting. 1.14.1.7. Documents with company logos and advertising will be removed. 1.14.2. Review of the position on tutorials from November meeting. 1.14.2.1. Stuart J. Kerry states to the members that after reviewing the minutes, we did decide that one evening slot would be set aside for tutorials relevant to 802.11. Stuart apologizes for forgetting to set aside one evening. It is too late to change at this time. 1.14.3. WG Policies and Procedures 1.14.3.1. Al Petrick reviews 05/94r0 detailing changes to the 802.11 P&P. The version of the P&P with these updates is document 04/510r1. 1.14.4. WG Timeline 1.14.4.1. Nanci Vogtli presents the WG timeline for best projections of TG ballots and completion goals. It will be kept on the website. It will be as timelines.htm on the website. It will be updated after each session. 1.14.4.2. Stuart Kerry notes that these are the official timelines of the Working Group. They will be reconfirmed at the Friday session. 1.14.5. WG Editors Status 1.14.5.1. Al Petrick will run the editors meeting Tuesday, since Terry Cole is not here. 1.15. Standing Committee Reports 1.15.1. Publicity – Nanci Vogtli 1.15.1.1. Will update content for the website. In conjunction with 802.15 in session tomorrow morning. 1.15.2. WNG – TK Tan 1.15.2.1. Will meet on Wednesday AM at 8am. 1.15.2.2. Will have an overview of NAN, and Service Provider Requirements, and timestamps. 1.16. Task Group Reports 1.16.1. TGe – John Fakatselis 1.16.1.1. Concluded a sponsor recirculation 1.16.1.2. About 11 no-vote comments will be processed. Hopefully there are no changes to the draft. If we can reject them, we achieve closure. 1.16.2. TGk – Richard Paine

Minutes page 6 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

1.16.2.1. Will address comments to LB73, and prepare for a recirculation. Comments are in document 05/191r0 1.16.2.2. 400 comments so far. Ballot closes Tuesday evening 1.16.3. TGm – Bob O’Hara 1.16.3.1. No ANA requests have been received. 1.16.3.2. Intend to compete a draft this week, and ask the WG to conduct a letter ballot. It will be a rollup of approved amendments and corrigendum into a single ballot. The entire document is subject to comment when balloting. 1.16.3.3. TGm will receive submissions from APF ad-hoc. 1.16.4. TGn – Bruce Kraemer 1.16.4.1. In the process of proposal review of two remaining proposals. Will have a Q&A session, followed by a downselect vote, and confirmation vote. 1.16.4.2. Will vote on technical editor on Thursday. Nominations are open. 1.16.4.3. Will meet in Centennial 2 starting at 4pm. Downselect on Wednesday at 4pm. Confirmation on Thursday AM at about 9am. 1.16.5. TGp – Lee Armstrong 1.16.5.1. Will review the current draft this week. Reviewing and resolving comments. Will have a ballot as soon as possible, perhaps after May meeting. 1.16.5.2. 802.11p is working with P1609 (upper layers) and P1556 (security). 1.16.6. TGr – Clint Chaplin 1.16.6.1. There are two proposals remaining. The plan of record will have presentations and another down-select vote on Thursday. There have been discussions of possible changes of agenda in the first session. 1.16.6.2. Update from ISO-IEC JTC1 SC6 meeting. It was a discussion of security for WLAN (802.11i and Chinese WAPI). 802.11i is still on fast track ballot for ISO standard. 1.16.6.3. The session here on ISO JTC1 will be chaired by Al Petrick. 1.16.7. TGs – Donald Eastlake 1.16.7.1. Will meet Wednesday and Thursday, Agenda in 05/113r3. In CFP phase. Deadline for intent was last week – received 34 proposals. 9 proposers will present at this meeting. We have 4 presentations not related to proposals. Will continue proposals in May. 1.16.8. TGT – Charles Wright 1.16.8.1. Wireless Performance: Will have presentations on test metrics and methodologies. Have 6 presentations so far. Will meet all day Tuesday. TGT still needs to find a permanent secretary. 1.16.9. TGu – Steven McCann 1.16.9.1. Agenda in 05/152r2. Will complete scenarios 1.16.9.2. Looking at InterWorking requirements from other bodies. 1.16.10. TGv – Pat Calhoun 1.16.10.1. Network Management – what is needed to manage the stations and APs. Will focus on identifying requirements. 1.16.11. ADS SG and APF Ad-Hoc – Dorothy Stanley 1.16.11.1. ADS agenda in 05/198. Will address comments on PAR and 5C from other 802 groups. 1.16.11.2. APF ad hoc has created AP functionality description. Work will end this week. Submissions will be given to TGm for inclusion into TGma draft. Submissions in 05 - 105, 110, and 120. Other work will remain as a reference document. 1.17. Interchange Groups 1.17.1. New PARs

Minutes page 7 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

1.17.1.1. There is the 802.11W PAR is our own. 1.17.1.2. The 802.15.3C PAR for millimeter wave alternative PHY. Any position from the floor? 1.17.1.2.1. What is the difference between this PHY and the 3a PHY? What is the different problem it is addressing? 1.17.1.2.2. Al Petrick asks for a show of hands for those that are interested in forming a comment group. There will be a meeting tomorrow AM. 802.11 has to return comments by tomorrow at 5pm. 1.17.1.2.3. There is also an issue with the incorrect version of the form? It has been corrected. 1.17.1.3. 802.3at PAR for residential Ethernet? Any positions or comments? None. The chair will support this PAR on Friday. 1.17.2. TIA TR42 TSB on cabling 1.17.2.1. Stuart Kerry reads a letter from the chair of TIA TR42: The purpose of this letter is to inform the IEEE 802.11 working group that TIA TR42 has started work on a project to develop a Telecommunications Systems Bulletin (TSB) on cabling and cabling infrastructure guidelines to support wireless access points. The project scope is shown below: The TSB will provide guidelines on the topology, design, installation, and testing of telecommunications cabling infrastructure, in compliance with ANSI/TIA/EIA-568-B.1 and TIA-569-B, for supporting wireless local area networks (WLAN) in customer owned premises. The TSB will include the cabling between LAN equipment and wireless access points including pathways and spaces to support the cabling and wireless access points. We welcome your input and participation as we develop this document and will keep you informed as this project is further developed. Best regards, Bob Jensen, Chair TIA TR-42 1.17.2.2. Looking for liaison for this group (voting membership required) Kourosh Parsa volunteers, but is not yet a voter. 1.17.3. Presentation of ideas from WNG – TK Tan 1.17.3.1. TK Tan and Stephen McCann have developed a presentation on the overall architecture of 802.11. Regarding extensibility, etc. 1.17.3.2. Stephen McCann presents document 05/171r0 “802.11 Future Directions” 1.17.3.3. Consideration of extending 802.11 beyond MAC and PHY. 1.17.3.4. Consideration of position 802.11 architectural extension with 802.21 activities. 1.17.3.5. Discussion 1.17.3.5.1. There are several ways to split this. Can we diffuse 802.11 into other groups? Or should we keep everything within 802.11 for better control? What about preserving the “purity” of the 802.11 brand? 1.17.3.5.2. We will continue to discuss this in WNG. 1.17.3.5.3. WFA has taken a lot of responsibility from 802.11. They have service providers involved also. We should try to understand how specific users will deploy their networks. 1.17.3.5.4. Operators will bring up similar topics in WNG session. 1.17.3.5.5. There is confusion within the WiFi Alliance regarding 802.11 TG activities. 1.18. Recess at 3:25pm

Minutes page 8 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

2. Wednesday Plenary, March 16, 2005 2.1. Opening 2.1.1. The meeting is called to order at 10:35 by Stuart J. Kerry. 2.1.2. The chair moves to Al Petrick 2.1.3. There are 304 people in the room. 2.2. Review of the agenda 2.2.1. Document 11-05-0111r4 2.2.2. The agenda for this session is displayed and reviewed. 2.2.3. Any additions or changes? None 2.3. Approval of the agenda 2.3.1. The agenda is approved with Unanimous consent. 2.4. Letters of Assurance 2.4.1. No new LOAs from the floor. 2.5. Announcements 2.5.1. The CAC meeting will be Thursday evening to prepare for the closing plenary Friday. 2.5.2. Social is tonight at 6:00pm. It will be in the lower floor convention area. 2.6. Attendance recording 2.6.1. Harry Worstell reports that we don’t have the registered attendees count at this time. The last count was over 1600 for the entire 802 plenary. 2.7. Liaison Reports 2.7.1. 802.18 – Denis Kuahara 2.7.1.1. Document number 11-05-0243r1 2.7.1.2. Liaison - IEEE 802 Wireless WGs - National and International Regulatory Agencies 2.7.1.3. Supports WWGs Spectrum Requirements 2.7.1.4. Tracks regulatory actions and provides advice to regulators to foster effective use of licensed and unlicensed spectrum 2.7.1.5. Significant Events 2.7.1.6. Continue Comments on UK OfCom Consultation 2.7.1.7. Three telecons on Consultation, emails 2.7.1.8. Industry Canada Consultation: 2.7.1.9. SMSE-002-05 Using UWB Technology 2.7.1.10. Industry Canada Access 2.7.1.11. //strategis.ic.gc.ca/epic/internet/insmt-gst.nsf/en/sf08283e.html “Consultation Paper on the Introduction of Wireless Systems Using Ultra-wideband Technology” 2.7.1.12. Docket Work 2.7.1.13. Rapporteurs 2.7.1.14. Spectrum Framework – Jim Raab 2.7.1.15. Spectrum Implementation – John Notor 2.7.1.16. UWB – Winston Caldwell 2.7.1.17. Presentation to 802.20 2.7.1.18. Joint Session with 802.15 3a, 4a 2.7.1.19. Follow up sessions with both groups

Minutes page 9 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

2.7.1.20. Expect Four Motions on Consultations 2.7.1.21. Future Plans 2.7.1.22. Review Consultations from Regulators 2.7.1.23. Next meeting – Cairns 15-20 May 05 2.7.2. 802.22 – Peter Ecclesine 2.7.2.1. Document 05-11-220 Abstract 802.22 topics this meeting: Proposed Schedule acceleration Wireless microphone beacon study group

Meeting website http://10.0.1.18/RadioReg/802.22/2005_Mar

802.22 Schedule Requirements definition March-May 05 [FCC Apr-Jun R&O] Wireless microphone beacon study group approved March ‘05 .22 Proposals/Contributions in May-July ‘05, Need WG Tech Editor July ’05 Wireless microphone beacon PAR and 5C July ’05 Wireless microphone beacon Proposals/Contributions Sept-Nov ‘05 .22 Consolidation in Nov ‘05 .22 WG 1st Draft by Jan ‘06 mid ‘07 to Sponsor Ballot 802.22 Discussions

References FCC Cognitive Radio R&O 05-57 http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-57A1.pdf

FCC 3650-3700 MHz R&O 05-56 http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-257309A1.pdf http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-56A1.pdf

FCC Cognitive Radio R&O 05-58 http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-58A1.pdf 2.7.2.2. Discussion 2.7.2.2.1. This has no effect on the frequency bands used by 802.11? Correct 2.7.3. 802.19 – Tom Seip 2.7.3.1. No report at this time. 2.7.3.2. Will have report on Friday 2.7.4. 802 Architecture Group – Andrew Myles 2.7.4.1. Document 11-05-256 2.7.4.2. 802 created a standing committee to improve alignment of Working groups and the overall 802 architecture. 2.7.4.3. 802.11 has been assigned certain issues. 2.7.4.4. Members should think about 802 architecture issues, and work on reflector. Andrew will make a summary to discuss in WNG in May to be ready for the next Plenary meeting.

Minutes page 10 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

2.7.4.5. Discussion 2.7.4.5.1. We need to do more than just talk about this. There is a dichotomy between wired and wireless groups. The wireless groups have a lot at stake in getting these issues solved. Propose that the wireless groups have a joint session to discuss these issues. Management is a key issue that the wired groups don’t seem to have an interest in. We should have a common wireless architecture group. 2.7.4.5.2. Andrew agrees. How could joint time be allocated? 2.7.4.5.3. Andrew will get the meeting scheduled. 2.7.4.5.4. Stuart states that the matter should be brought to the joint chairs meeting for Wireless. 2.7.5. Wi-Fi Alliance – Bill Carney 2.7.5.1. Document 11-05-258r0 2.7.5.2. 15% increase in members, 70% increase in certifications, and 40% decrease in certification cost. 2.7.5.3. Certification is faster – taking a day or two. 2.7.5.4. Wi-Fi Alliance membership dues have been reduced. 2.7.5.5. Security group has completed extended EAP. 2.7.5.6. QoS technical is starting work on APSD. WMM-SA is working on test plan, and planning plugfest in June, and certification by end of 2005. 2.7.5.7. Application Specific Devices – working on alternative approach for ASD testing. 2.7.5.8. Next meeting in Chicago in June. 2.7.6. JEDEC JC-61 – Norm Muwella 2.7.6.1. No presentation 2.7.6.2. Met this week, submit the first revision of draft (1.1) to JEDEC board of directors. Working on interop and compliance for 802.11n. Next meeting in San Francisco before plenary in July. 2.7.7. IETF – Dorothy Stanley 2.7.7.1. Document 11-05-189r2 2.7.7.2. IAB draft on Link Indications, see http://www.drizzle.com/~aboba/IAB/draft- iab-link-indications-01.txt 2.7.7.3. Link-layer Event Notifications for Detecting Network Attachments http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt 2.7.7.4. Input to the EAP Keying draft, see http://www.ietf.org/internet-drafts/draft-ietf- eap-keying-05.txt. Initial discussion held in TGr, in November 04, see 11-04-1498-00- 000r-ieee-802-11-keying-requirements.doc. EAP Keying draft is being split into two documents, one describing current EAP keying usage, and a second describing future extensions. Need to re-visit 04/1498. 2.7.7.5. IETF WG formed 1Q04, Control And Provisioning of Wireless Access Points, re-chartered Nov04 WG Website: http://www.ietf.org/html.charters/capwap- charter.html Taxonomy document completed Next steps: Objectives Document, Protocol evaluation and base protocol selection document, CAPWAP protocol standard, MIB support standard. 2.7.7.6. Request for IEEE 802.11Review of CAPWAP objectives document Objectives Draft available early April 05; Will forward to reflector, requesting comments Recommend IEEE 802.11 Chair to form Ad-Hoc to prepare response Recommend Ad-hoc Conference Call April 27, 2005 Noon Eastern Draft and approve response at May 05 Cairns meeting Request for plan to resolve authenticator identity issue. The centralized model encourages AC implementations to use one PMK for many different WTPs. This practice facilitates speedy transition by a station from one WTP to another WTP that is connected to the same AC without establishing a separate PMK. However, this leaves the station in a difficult position. The station cannot distinguish between a compromised PMK and one that is intentionally being

Minutes page 11 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

shared. This issue must be resolved, but the resolution is beyond the scope of the CAPWAP working group. The venue for this resolution is to be determined by the IEEE 802 and IETF liaisons. Liaison discussion underway 2.7.7.7. Benchmarking Methodology WG Work described in http://www.ietf.org/internet-drafts/draft-alexander-wlan-meth-00.txt is in scope for TGT IEEE 802.11 WG position – work should be done in IEEE 802.11 With updates to BMWG (Tom Alexander) Action: Document access by BMWG members Review of 802wireless world access presented to BMWG members Access to TGT draft in members area (when available), per 802 agreement, to BMWG Chairs 2.7.7.8. Other areas of interest MIPv6 Signaling and Handoff Optimization (mipshop) Mobile IPv6 Fast Handovers for 802.11 Networks, see http://www.ietf.org/internet- drafts/draft-ietf-mipshop-80211fh-03.txt IRTF IP Mobility Optimization (mobopts) See http://www.irtf.org/charters/mobopts.html 2.7.7.9. Discussion 2.7.7.9.1. Stuart J. Kerry states that the WG will form a new Ad Hoc Group to address the CAPWAP Object Draft response. Dorothy Stanley will chair it and find volunteers. There will be one teleconference or one meeting. 2.7.7.10. 2.7.8. MMAC – Inoue-san 2.7.8.1. document 235r1 2.7.8.2. Review of MMAC activities and organization 2.7.8.3. ARIB standard T-71 is related to 802.11a standards. 2.7.8.4. Have incorporated 802.11j amendment 2.7.8.5. Discussion 2.7.8.5.1. Does MMAC want the 5.15 and 5.25 bands to have the channel centers change? It is easy for us to change them. Inoue-san states that the review will be open next month. They will report back and we could make a change to 802.11J in July. 2.7.9. JTC1 SC6 – Alex Chan 2.7.9.1. No Report 2.7.9.2. There was a meeting in Frankfurt. 802.11 needs to have internal meetings to discuss how to respond to this meeting. 2.7.9.3. Al Petrick states that this will be in an Ad Hoc meeting today. 2.7.10. 3GPP 2.7.10.1. New Position: Open for nominations 2.7.10.2. Stephen McCann (TGu chair) nominates Sabine Demel 2.7.10.3. Sabine Demel is appointed liaison by acclamation. 2.8. Old Business 2.8.1. Secretary Guidelines 2.8.1.1. Harry Worstell is still receiving updates. Not ready for a new release yet. Will be finalized soon. 2.8.2. Documentation Update 2.8.2.1. We have finished an RFP for a new documentation and attendance software. These are being reviewed by the wireless working group chairs. There are a number of companied under consideration and providing bids. 2.8.3. 802.15 3C PAR 2.8.3.1. The chair moves to Stuart J. Kerry 2.8.3.2. Al Petrick states that he met to review the 802.15.3C PAR, which proposed a PHY for 25GHz and above. We have these comments: We need a definition of frequency bands, and license/unlicensed status. We also need minimum and maximum data rates to be specified. Any MAC changes need to be specified.

Minutes page 12 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

2.8.3.3. These comments will be on the server later. 2.8.3.4. The chair moves to Al Petrick 2.9. New Business 2.9.1. Announcement 2.9.1.1. TGs will meet in a small room this afternoon. 2.10. Recess at 11:30

3. Closing Plenary, Friday, March 18, 2005 3.1. Opening 3.1.1. The meeting is called to order by Stuart J. Kerry at 08:00. 3.1.2. Agenda in 11-05-111r4 3.1.3. Any changes to the agenda? None 3.1.4. The agenda is approved with Unanimous consent 3.2. Announcements 3.2.1. Letters of Assurance 3.2.1.1. Any new Letters of Assurance? 3.2.1.2. None 3.2.2. Chairs updates 3.2.2.1. Reports and minutes are due March 21st, and updates to the websites. 3.2.3. From the floor 3.2.3.1. A member thanks to Buzz Rigsbee for arranging to the breakfast earlier in the morning. 3.2.4. Nominations for 802.19 Liaison 3.2.4.1. Currently Stephen Whitesell and Tom Seip 3.2.4.2. Any other nominations? 3.2.4.3. None 3.3. Working Group Reports 3.3.1. Documentation 3.3.1.1. Harry Worstell reminds the membership that logos and advertisement are not allowed on submitted documents. 3.3.1.2. Stuart Kerry reminds the members that membership is individual, not corporate. 3.3.1.3. From the floor? 3.3.1.3.1. Any updates on the documentation software? 3.3.1.3.2. The RFP is out for review with the wireless WG chairs. Next week, we will send out the RFP. 3.3.2. Working Group Policies and Procedures 3.3.2.1. Al Petrick announces that there are no new comments on the version on the server. It will be voted on in May 3.3.2.2. The document update is 04-510r1 3.3.3. Working Group Timelines 3.3.3.1. Timeline will be document 11-05-0313 3.3.3.2. There have been some updates this week. 3.3.3.3. Stuart notes that this is the official plan and dates of 802.11 3.3.4. Straw Poll regarding this meeting location

Minutes page 13 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

3.3.4.1. Everyone who likes this location for a meeting? Almost unanimous. 3.3.5. Publicity Update – Nanci Vogtli 3.3.5.1. Document 05/0302 3.3.5.2. Developed calendar of events for .11 and .15. 3.3.5.3. Wrote release for formation of 802.11u and 802.11v 3.3.5.4. Updated calendar of events 3.3.5.5. Generated release for upcoming formation of TGw. 3.3.6. 3.4. Task Group Reports 3.4.1. TGe – John Fakatselis 3.4.1.1. Report in document 05/0311 3.4.1.2. The previous sponsor recirc resulted in no new No votes, but there were 11 new comments. There are 4 remaining No voters. All comments were addressed, and a new Sponsor Recirculation will be done. We don’t expect any further comments. 3.4.1.3. The next recirc will be next month. We will seek ExCom approval in July. The RevCom approval will be September. 3.4.2. TGk – Richard Paine 3.4.2.1. Report 05/307 3.4.2.2. Had LB73 comment resolution. There have been votes on some comment resolutions. 3.4.2.3. In May, will continue comment resolution 3.4.2.4. In July, will have another Letter ballot 3.4.2.5. Teleconference will continue. 3.4.2.6. LB73 results will be announced next week. 3.4.2.7. There are about 1600 comments received. 3.4.3. TGm – Bob O’Hara 3.4.3.1. Report in document 05/205 3.4.3.2. Interpretation request regarding the quiet information element in 802.11h. It was decided that the request was not really for interpretation, but for consultation on how to do something. 3.4.3.3. The TG completed processing all material for incorporation into the 802.11REV-ma draft. In addition, the APF ad-hoc material was incorporated. The TG will request the WG to conduct a Letter Ballot on 802.11REV-ma D1.0. 3.4.3.4. The TG request the WG to make the draft available for purchase. 3.4.3.5. There were 8 work items to complete. There are 3 closed unaddressed. 97% of work items were completed. 3.4.3.6. Discussion 3.4.3.6.1. Is a Coexistence Assurance document required? No, the legacy requirement states that existing standards are not required to create a CA 3.4.3.7. There are no updates for Assigned Numbers, and no requests 3.4.4. TGn – Bruce Kraemer 3.4.4.1. Document 05/297r0 3.4.4.2. Heard presentations and had interactive Q&A, held down select and confirmation votes. 3.4.4.3. Technical editor was not selected. 3.4.4.4. The confirmation vote failed with 181 to 140, not meeting 75%. 3.4.4.5. Stuart Kerry displays the audited, corrected counts. There was one extra ballot. The vote was 182 to 140..

Minutes page 14 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

3.4.4.6. The group has determined the procedure between now and the May meeting. There will be reasons for no-votes and suggested cures. There will be proposal updates to address the comments. 3.4.4.7. In May, there will be 6 hours of presentations, 4 hours of Q&A. 3.4.4.8. There were some press releases following the procedures this week. 3.4.4.9. Stuart J. Kerry warns the membership that due to the auditing process, early vote counts can be incorrect. He re-iterates the rules that state that only the WG chairs and vice-chairs are allowed to make statements to the press. 3.4.4.10. Stuart reads the following letter from Sheung Li regarding press coverage attributed to him: To the 802.11 WG members:

Yesterday afternoon, an article appeared online citing an internal e-mail I had written to certain colleagues at my company on the TGn vote.

I apologize for this article. I never communicated with its author, nor did I ever authorize this e-mail to be passed along externally.

I take my responsibilities to the working group seriously, and will make sure this does not happen again.

Sheung Li 3.4.4.11. .The official TGn vote is 56.5% for confirmation and 43.5% against. This document will be on the server 3.4.4.12. Discussion from the floor 3.4.4.12.1. Appreciate that Sheung has issued an apology. Will he address the next session of 802.11n? Yes, we will request that he re-state the apology in May. This is so ordered by the WG chair. 3.4.5. TGp – Lee Armstrong 3.4.5.1. Report in document 05/309r0 3.4.5.2. Preparing draft for WG Letter Ballot 3.4.5.3. Draft D1.2 was not completed. There were 129 comments, and 93 were addressed. 3.4.5.4. There were comments on channel management and signal strength. 3.4.5.5. There will be a teleconference to change wording on signal strength. 3.4.5.6. Will have teleconference April 6, and have a draft available by March 25th. 3.4.5.7. Planning WG Letter ballot after July meeting 3.4.6. TGr – Clint Chaplin 3.4.6.1. Document 05/290r1 3.4.6.2. The two remaining proposals are working on merging. 3.4.6.3. Step 3 of the down-select process was postponed until May. 3.4.6.4. Will hold ad-hoc meeting in April, and biweekly teleconferences. 3.4.6.5. In May will continue working on draft text and complete selection process 3.4.7. TGs – Donald Eastlake 3.4.7.1. Report in document 05.285r1 3.4.7.2. Last week was deadline for notice of intent to propose. 35 have been received. 3.4.7.3. 9 proposals were presented this week, and 4 more will be in May.

Minutes page 15 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

3.4.7.4. The Task Group developed a selection process in 274r3, but did not adopt it due to the lack of 75% approval 3.4.7.5. . Stuart notes that the 75% is part of the P&P which should always be adhered to. 3.4.7.6. There will be ad-hoc meeting August 30th. 3.4.7.7. Discussion 3.4.7.7.1. Request for clarification of the selection procedure document. Why it requires 75%? Stuart Kerry notes that pure procedural matters are 50%. But the members believe that the selection procedure affects the technical content and thus requires 75%. 3.4.7.7.2. Suggests discussing the selection procedure on the mailing list before next meeting. 3.4.7.7.3. Stuart J. Kerry notes that a 40 day letter ballot could also be used to approve the procedure. 3.4.8. TGT – Charles Wright 3.4.8.1. Document 05/153r1 3.4.8.2. Heard technical presentations, and proposals for draft organization, guidelines for metrics and methodologies. 3.4.8.3. Started list of definitions for draft 0.1 3.4.8.4. Still looking for permanent secretary 3.4.8.5. Will continue teleconferences 3.4.8.6. In May, will hear full proposals 3.4.9. TGu – Stephen McCann 3.4.9.1. Document 05/301r0 3.4.9.2. Worked on requirements, and met with 802.21. 3.4.9.3. Had a presentation on MAC address anonymity. 3.4.9.4. Reviewed IETF draft on link indications. Will continue work in teleconferences, and approve in May. 3.4.9.5. Completed draft requirements document 05-279, assumptions, scenarios and scope (0092) and Terms and definitions 3.4.9.6. In May, will address requirements and older SG documents. Will start work on CFP and selection procedure. 3.4.10. TGv – Gene Calhoun 3.4.10.1. Report in document 05.225r1 3.4.10.2. Had 5 presentations this week 3.4.10.3. Started tracking requirements in 05/224 and prioritizing. 3.4.10.4. Minutes in 292r0 3.4.10.5. In May meeting, will continue to work on requirements, and have presentations to address those requirements. 3.4.10.6. Looking for permanent secretary and editor. 3.4.11. Technical Editors Report 3.4.11.1. Al Petrick presents the report for Terry Cole 05/314r0 3.4.11.2. There are no WG drafts currently in process at IEEE 3.4.11.3. Notes that the number 802 is a registered trademark. 3.4.11.4. Editors should start working early in Framemaker 7.1 3.4.11.5. All definitions will be moved to a separate document in July. 3.4.11.6. A backup editor will be selected in May 3.4.12. WNG SC – TK Tan 3.4.12.1. Report in 05/188 3.4.12.2. There was one session with 7 presentations 3.4.12.3. 3.6GHz allocation

Minutes page 16 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

3.4.12.4. Service providers requirements on 802.11n 3.4.12.5. Future directions of 802.11 – discussion will continue in May 3.4.12.6. Discussion 3.4.12.6.1. The 802 architecture committee may be interested in the future directions of 802.11 discussion. Andrew Myles will track this. 3.4.13. ADS SG – Dorothy Stanley 3.4.13.1. Report in 05/308r0 3.4.13.2. Management Frame Security 3.4.13.3. There were no comments on the PAR and 5C. Will extend SG just in case. 3.4.13.4. Heard submissions on requirements and solutions 3.4.13.5. In May will review draft requirements, possibly issue CFP. Will determine timeline. 3.4.13.6. Chair and secretary elections 3.4.13.7. Stuart J. Kerry thanks Dorothy for her efforts in the APF SG on behalf of the Working Group. 3.4.14. APF Ad Hoc – Dorothy Stanley 3.4.14.1. Report in document 05/306 3.4.14.2. Completed work of submissions for inclusions in the 802.11REV-ma revision in document 05/120r9 3.4.14.3. Describes Access Point Functionality 3.4.14.4. Permanent reference submissions 04/1225 and 05/159 will be available as references material on the website. 3.4.14.5. Will requested liaison with 802.1 3.4.14.6. APF completes work this week. Any further work will be in TGm. Thanks to those that participated. 3.4.15. JTC1 – Clint Chaplin 3.4.15.1. Report in document 05/312 3.4.15.2. created report on P8802.11i in ISO 3.4.15.3. Wrote liaison letters. 3.4.15.4. Motions to authorize teleconferences and appoint liaison 3.4.15.5. In May, will address any issues that have arisen. The ballot doesn’t’ close until June. 3.5. Special Orders 3.5.1. Generic Teleconference empowerment

Minutes page 17 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

Motion Move to empower the following TG(s)/SG(s)/Ad-Hoc to hold teleconference calls beginning no sooner than March 23, 2005 through 15 days past the end of the July, 2005 Plenary Session.

Group Start Date Duration Time Ad-Hoc CBP April 6, 2005 Weekly 13:00 ET Ad-Hoc IETF – April 27, 2005 Once 12:00 ET CAPWAP Ad-Hoc JTC1 June 14, 2005 Weekly 19:00 – 20:00 ET Task Group “k” March 23, 2005 Weekly 11:30 ET Task Group “s” April 20,2005 Once 14:00 ET Task Group “T” March 24, 2005 Weekly 12:00 ET Task Group “p” April 6, 2005 Once 14:00 ET Task Group “r” May 25, 2005 Bi-weekly 11:00 ET Task Group “n” June 6, 2005 Bi-weekly 17:00 ET Task Group “u” April 20, 2005 Once 16:00 ET May 4, 2005 Once 09:00 ET Moved: Al Petrick Second: Harry Worstell 3.5.2. 3.5.2.1. Approved with Unanimous consent 3.5.3. Generic empowerment for Interim Session 3.5.3.1. Move to empower the 802.11 WG, Task Groups, Ad-hocs, and SGs, SCs to hold meetings beginning March 18, 2005 through July 30,2005 to conduct business as deemed necessary. 3.5.3.2. Moved by: Al Petrick 3.5.3.3. Seconded: Peter E. 3.5.3.4. Approved with Unanimous consent 3.5.4. Publicity Motions 3.5.4.1. Motion: Adopt the text in document 05-0310 as the press release to announce formation of Task Group w, Protected Management Frames. 3.5.4.1.1. Moved Nanci Vogtli on behalf of Publicity SG 3.5.4.1.2. Discussion 3.5.4.1.2.1. The motion needs to be in the ExCom box. Bob O’Hara will send by email 3.5.4.1.2.2. The motions was approved unanimously. 3.5.4.1.2.3. Clarify why this motion appears now? TGw has already been approved in the previous session. 3.5.4.1.3. Vote: passes 92 : 0 : 6 3.5.4.2. Stuart states that Roberts Rules is now available in electronic form, and displays the program. The approved edition 10 is now available. 3.5.5. WNG Motions 3.5.5.1. Motion: To request that the 802.11 Working Group form a study group to study the opportunity afforded by FCC Report and Order and Memorandum Opinion and Order (FCC 05-56), with the intent to create a PAR and five criteria to form a new Task Group, and forward to the Executive Committee for Approval. 3.5.5.1.1. Moved TK Tan on behalf of WNG 3.5.5.1.2. Discussion 3.5.5.1.2.1. The Study Group will be CBP (Contention Based Protocol) 3.5.5.1.2.2. What is the meaning of the FCC document? It is regarding the 3.6Ghz allocation with up to 25 watts, fixed or Minutes page 18 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

mobile. It is part 15 unlicensed operation. It is nationwide, and a step towards cognitive radio, with negotiation for bandwidth. 3.5.5.1.3. Motion ID 512 3.5.5.1.4. Vote: motion passes 88 : 5 : 9 3.5.5.2. Move to request empowerment for the Contention-Based Protocol SG to hold teleconferences through August 5th, and create a PAR and 5 Criteria, and have the WG vote on Friday May 20th, 2005 to put them on the 802 Executive Committee agenda, and have a re-confirmation vote on Monday July 18th, 2005 3.5.5.2.1. Moved TK Tan 3.5.5.2.2. Second Peter Ecclesine 3.5.5.2.3. Vote: motion approved by Unanimous consent 3.5.6. TGe Motions 3.5.6.1. Believing that sponsor ballot comment responses in 11-05/0131R3 and the document mentioned below satisfy IEEE-SA rules for sponsor ballot recirculation, Authorize a SB recirculation of 802.11e draft 13.0 to conclude no later than 04/15/2005 3.5.6.1.1. Moved John Fakatselis on behalf of TGe 3.5.6.1.2. The WG chair recuses himself due to involvement in the next motion. The chair moves to Al Petrick 3.5.6.1.3. Discussion 3.5.6.1.3.1. None 3.5.6.1.4. Vote: motion passes 90 : 0 : 4 3.5.6.2. Move that the Task Group requests to forward all “disapprove” comments by Amjad Soomro, Javier del Prado and Stuart Kerry to Task Group “m” for consideration for a future revision of the standard. 3.5.6.2.1. Moved John Fakatselis on behalf of TGe 3.5.6.2.2. Discussion 3.5.6.2.2.1. This seems odd – why would a Task Group do this? Please explain. 3.5.6.2.2.2. The Task Group has declined the comments with the necessary technical process. The No Voters will reverse those votes if we follow this process. 3.5.6.2.2.3. Is it in order for the mover in TGe to be the same person named in the motion? The WG chair rules it is in order. 3.5.6.2.2.4. Against the motion. 3.5.6.2.2.5. Any member could bring an issue to TGm. What does this motion do? These members are capable to take these issues to TGm. 3.5.6.2.2.6. Bob O’Hara, TGm Chair, states that he has no personal opinion. Either way is OK. TGm cannot work on 802.11e until it is approved. 3.5.6.2.2.7. Asking TGm to address this is asking them to change functionality that should be addressed in TGe. 3.5.6.2.3. Motion to put the motion on the floor on the table. 3.5.6.2.3.1. Moved Dave Bagby 3.5.6.2.3.2. Discussion 3.5.6.2.3.2.1. What is the intent? The intent is to not bring it back at as specific time. 3.5.6.2.3.2.2. If the intent is to get rid of the motion, then we should call the question and vote it down. 3.5.6.2.3.3. No Second – motion dropped 3.5.6.2.4. Call the question on the main motion (Donald/John) Unanimous consent – no objection 3.5.6.2.5. Motion ID 513 3.5.6.2.6. Vote on the main motion: passes 19 : 16 : 50 3.5.6.2.7. Point of Information

Minutes page 19 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

3.5.6.2.7.1. Stuart J. Kerry states that he will send his personal sponsor ballot comments to TGm 3.5.7. Discussion 3.5.7.1.1. It is time to recess, but we are in the special orders section. 3.5.7.1.2. The chair moves to Stuart J. Kerry. 3.5.7.1.3. Why are some special orders special and some not? Would prefer to deal with special orders according to the agenda. We should continue to follow the special orders, according to the numerical value. 3.5.7.1.4. Any objection to continue on without regard to the times. 3.5.8. TGm Motions 3.5.8.1. Moved: To conduct a 40-day working group letter ballot for the purpose of forwarding 802.11REV-ma draft 1.0 to sponsor ballot. 3.5.8.1.1. Moved Bob O’Hara on behalf of TGm 3.5.8.1.2. Vote: passes 94 : 0 : 1 3.5.9. TGn Motions 3.5.9.1. Move that the working group approves TGn to hold teleconferences at 17:00 ET every 2 weeks beginning on Monday June 6 for the purpose of preparing a Coexistence Assurance document, subject to reconfirmation by the 802.11 WG during the May 2005 session. 3.5.9.2. Moved : Bruce Kraemer 3.5.9.3. Second: Harry Worstell 3.5.9.4. Discussion 3.5.9.4.1. Given the emotions in the group, there should be restrictions. 3.5.9.5. Changes to the wording are accepted by Unanimous consent 3.5.9.6. Discussion 3.5.9.6.1. When does this end? According to the previous teleconference motion? 3.5.9.7. Vote: The motion is approved with Unanimous consent 3.6. Break until 10:40 3.6.1. ADS Motion 3.6.1.1. Move to request that the IEEE 802.11 Working Group extend the ADS Study Group for an additional 6 months and forward to ExCom for approval. 3.6.1.1.1. Moved by Dorothy Stanley on behalf of ADS 3.6.1.1.2. Second Harry Worstell 3.6.1.1.3. Vote: motion passes 70 : 0 : 1 3.6.2. APF Motion 3.6.2.1. Motion: 3.6.2.2. Request Stuart Kerry 802.11 WG chair to forward the liaison request in 05/185r2 to the IEEE 802.1 Working Group, on behalf of the IEEE 802.11 Working Group. 3.6.2.2.1. Moved Dorothy Stanley 3.6.2.2.2. Second Denis Kuahara 3.6.2.2.3. Vote: approved by Unanimous consent 3.6.3. JTC1 Motion 3.6.3.1. Teleconferences have already been approved 3.6.3.2. Move to recommend to the IEEE 802.11 WG chair that Stuart Kerry, Chair, IEEE 802.11, and Alex Cheng, member IEEE 802.11, be appointed as contact points from IEEE 802.11 to CCSA TG5/WG3. 3.6.3.2.1. Moved Dorothy Stanley 3.6.3.2.2. Second Denis Kuarhara 3.6.3.2.3. Vote: approved by Unanimous consent

Minutes page 20 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

3.7. New Business 3.7.1. TGs Selection Procedure 3.7.1.1. Move to conduct 40 day 802.11 working group letter ballot for the purpose of approving the TGs selection procedure described in document 11-05/0274r3. 3.7.1.1.1. Moved Juan-Carlos Zuniga 3.7.1.1.2. Second Guido Hertz 3.7.1.1.3. Discussion 3.7.1.1.3.1. The purpose is to not lose the work done this week in TGs and to have more members input into the procedure. 3.7.1.1.3.2. Worried that the TG didn’t decide this. Should the WG have to answer this? Why didn’t the TG get the necessary approval level? 3.7.1.1.3.3. Donald Eastlake (TGs Chair) states that the group has adopted the procedures for May. 3.7.1.1.3.4. Why can’t this wait until May? 3.7.1.1.3.5. It could be decided at the May meeting. 3.7.1.1.3.6. Is the document on the server? Yes 3.7.1.1.3.7. This document was debated and had majority approval but not 75%. Discussions on the reflector and teleconferences should be able to resolve this. 3.7.1.1.3.8. Against the motion – the TG should resolve at the May meeting. 3.7.1.1.3.9. For the motion – there was a misunderstanding of rules in TGs. The TGs group didn’t understand the 75% threshold. Many members will not be able to attend in May. This allows the maximum number of people to review the document. 3.7.1.1.3.10. Against the motion – the TG should do this in May, and if not there, in July. 3.7.1.1.4. Call the question (Juan/Gunnar) 3.7.1.1.4.1. Vote on calling the question: passes 62 : 3 : 7 3.7.1.1.5. Motion ID 514 3.7.1.1.6. Vote on the main motion: fails 24 : 36 : 18 3.7.2. Discussion 3.7.2.1. TIA intends to bring up a liaison with IEEE. A formal request will be brought in July. 3.7.2.2. Stuart Kerry officially calls for TIA 42 to be considered on Wednesday in the May meeting. 3.7.3. Interim Locations 3.7.3.1. Samsung offers Seoul for May for 2006. 3.7.3.2. May is the first choice, but September would be possible if required. 3.7.3.3. Stuart will take this to the other Wireless WG chairs for consideration 3.8. Next Meeting 3.8.1. May 15th-20th, 2005, Cairns, Queensland, Australia 3.8.1.1. April 2nd is the next cutoff for registration. 3.8.1.2. A visa is required for Australia 3.9. Closing 3.9.1. The meeting is adjourned at 11:15

Minutes page 21 Tim Godfrey, Conexant

March, 2005 doc.: IEEE 802.11-05/0286r0

References:

Minutes page 22 Tim Godfrey, Conexant

Abbott William Abdelilah Youssef Aboul-Magd Osama Abraham Santosh Adachi Tomoko Adams Jon Adlard Jo Afkhamie Kaywan Agre Jonathan Aldana Carlos Alexander Thomas Amstadt Todd Anantha Veera Ananthaswamy Ganesh Andren Carl Andrews Scott Andrus David Aoki Hidenori Aoki Mikio Aoki Tsuguhide Aramaki Michimasa Ariyavisitakul Sirikiat Lek Armstrong Lee Arnett Larry Asai Yusuke Astrin Arthur Audeh Malik Awater Geert Bagby David Bahr Michael Baker Dennis Balachander Ramanathan Barber Simon Barnwell Richard Barr John Barry Kevin Bartel Charles Batra Anuj Baysal Burak Benko John Benveniste Mathilde Berry Don Bjerke Bjorn Black Simon Blaney Timothy Blue Scott Boros Tibor Brownlee Phillip Butler Jerry Buttar Alistair Cain Peter Calhoun Pat Cam Richard Cam-Winget Nancy Canpolat Necati Carney Bill Carson Pat Cash Broady Cha Inhyok Chang Chung-Yao Chaplin Clint Chari Amalavoyal Chen Michael Chen Yi-Ming Chen Jeng-Hong Chen Michael Chen Shiuh-Yuan Cheng Alexander Cheng Hong Chesson Greg Cho SongYean Choi Sunghyun Choi Won-Joon Choi Yang-Seok Chu Liwen Chuang Dong-Ming Chung Simon Clements Ken Coffey John T. Conner W. Steven Cook Charles Daswani Neil de Courville Marc De Vegt Rolf Demel Sabine Devlin Paul Dick Kevin Dielacher Franz Doi Yoshiharu DuMas Phillip Durand Chris Durand Roger Dure Sebastien Eastlake Donald Ecclesine Peter Eckard Richard Edney Jonathan Edwards Bruce Egan John Elaoud Moncef Ellis Jason Emeott Stephen Emmelmann Marc Engwer Darwin Ennis Greg Epstein Joseph Eroz Mustafa Estrada Andrew Euscher Christoph Faccin Stefano Fakatselis John Falk Lars Fantaske Steve Faulkner Michael Feinberg Paul Fischer Matthew Fisher Wayne Flygare Helena Foegelle Michael Ford Brian Fosmark Klaus Frederiks Guido fremont benoit Fujiwara Atsushi Fukagawa Takashi Funk Paul Furukawa Hiroshi Gambiroza Violeta Gardner James Garrett Albert Genossar Michael Ghazi Vafa Ghosh Monisha Gilb James Gilbert Jeffrey Godfrey Tim Goel Sandesh Goettemoeller Mike Gohda Wataru Golden Stuart Gossain Hrishikesh Goubert Gerard Grandhi Sudheer Gray Gordon Gray Steven Green Larry Gryder Roxanne Gu Daqing Gumamdi Srikanth Gurevich David Haisch Fred Hall, P.E. Robert J Halpert Ben Hamon Marie-Helene Hansen Christopher Harkins Daniel Harriman Adam Hart Brian Hartman Chris Haslestad Thomas Hassan Amer Hasty Vann Hasty William Hattig Myron Haugdahl Scott Hauser James Hayase Shigenori Hayes Kevin He Haixiang Hedberg David Hepworth Eleanor Hermodsson Frans Heubaum Karl Hideaki Odagiri Hiertz Guido Hillman Garth Hinsz Christopher Hocevar Dale Hoghooghi Michael Holt Keith Honary Hooman Horng Henry Housley Russell Hrastar Scott Hsu Yungping Hsu Terng-Yin Ikram Muhammad Inoue Yasuhiko Ishida Kazuhito ITO Takumi Iyer Lakshmi Jackson Stephen Jacobsen Eric Jalfon Marc Jang KyungHun Jauh Yuh-Ren Jeon Ho-In Jeon Taehyun Jetcheva Jorjeta Ji Lusheng Jian Yung-Yih Jiang Jessie Johnson Todd Jokela Jari Jones VK Joshi Avinash Jou Tyan-Shu Kain Carl Kakani Naveen Kandala Srinivas Kangude Shantanu Kanterakis Emmanuel Karaoguz Jeyhan Karcz Kevin Kasher Assaf Kato Masato Kavner Douglas Kelly Patrick Kerry Stuart Ketchum John Kikuma Tomohiro kim dongho KIM Jaeyoel Kim Joonsuk Kim KyungTae Kim Taekon Kim Yongsuk Kim Youngsoo Kimhi Ziv Klein John Klein Jay Kleindl Guenter Kneckt Jarkko Kobayashi Kiyotaka Kobayashi Mark Koga Keiichiro Kolze Thomas Kondylis George Kong Jiyoung Koomullil George Kopikar Rahul Kopikare Milind Kowalski John Kraemer Bruce Krishnan Gopal Kruys Jan Kuehnel Thomas Kukshya Vikas Kumar Rajneesh Kumar Rajneesh Kunihiro Takushi Kuo Ted Kurihara Thomas Kuwahara Denis Kvarnstrom Bo Kwak Joe Kwon Edwin Lambert Paul Landeta David Landt Jeremy Lauer Joseph Leach David Lee Dongjun Lee Myung Lee Sok-kyu Lee Byoung-Joon Lee Wooyong Lefebvre Vincent Lefkowitz Martin lemberger uriel Levy Joseph Li Pen Li Sheung Liang Haixiang Liang Jie Lim Wei Lih Lin Huashih Lin Victor Liu Albert Liu Changwen Liu Der-Zheng Liu Ed Liu Hang Liu Yong Liu Jun Liu Sean S.T. Loc Peter Lojko Peter Lou Hui-Ling MacKenzie Phil Makishima Doug Malek Majid Malinen Jouni Mani Mahalingam Marshall Bill Martin Art Matsumoto Taisuke MATSUMOTO TOMOYUKI Matsumoto Yoichi Matsuo Ryoko Mayer Matthew McCann Stephen McClellan Kelly McFarland William McIntosh Bill McNamara Darren McNew Justin Medvedev Irina Mehta Pratik Merrill Mark Meyer Klaus Meylan Arnaud Miki Morgan Miki Hirosuke Miller Robert Min Seungwook Mittelsteadt Cimarron Miura Akira Mlinarsky Fanny Mody Apurva Molisch Andreas Montavont Nicolas Montemurro Michael Moorti Rajendra Moreton Mike Morioka Yuichi Morley Steven Mourot patrick Muck Markus Mujtaba Syed Munaka Tatsuji Murray Peter Myles Andrew Nagai Yukimasa Nakamura Tetsuya Nakao Seigo Nakase Hiroyuki Nallapureddy Bhaskar Nam Seung Hoon Nanda Sanjiv Nassi Ike Nedic Slobodan Nee Richard Newton Paul Ngo Chiu Nitsche Gunnar Noens Richard Ogawa Masakatsu Oguma Hiroshi O'Hara Bob Ojard Eric Olson Chandra Olson Timothy Oostveen Job Oyama Satoshi Paine Richard Paljug Michael Palm Stephen Pare Thomas Park Jong Ae Parker Steve Parsa kourosh Patel Vijay Peleg Yaron Perahia Eldad Petrick Al Pirzada Fahd Pitarresi Joe Ponnuswamy Subbu Poojary Neeraj Portaro James Ptasinski Henry Purkovic Aleksandar Qi Emily Qian Luke Quinn Liam Raab Jim Raissinia Ali Ramesh Sridhar Rangwala Noman Rappaport Ted Rayment Stephen Reible Stanley Repice Joe Ribeiro Dias Alexandre Ribner David Riess Eilon Robinson Phil Roebuck Randy Rosca Justinian Rosdahl Jon Roy Richard Roy Pulakesh Rude Michael Rudolf Marian Sadeghi Bahareh Sadot Emek Sadowsky John Saed Aryan Sakoda Kazuyuki Salhotra Atul Sampath Hemanth Sandhu Sumeet Sarca Octavian Sargologos Nicholas J Sarrigeorgidis Konstantinos Sashihara Toshiyuki Sastry Ambatipudi Saxena Monica Schnacke Richard Schylander Erik Sennett DeWayne Sensendorf Joe Seth Vikram Shellhammer Stephen Sherlock Ian Sherman Matthew Shieh Hugh Shono Takashi Shvodian William Shyy D. J. Simons John Simpson Floyd Sinha Amit Siti Massimiliano Sivanesan Kathiravetpillai Skidmore Roger Smith Matt So Tricci Sood Kapil Soomro Amjad Soranno Robert Spalla Filippo Sridhar T Srinivasan Ranga Stacey Robert Stafford Robert Stanley Dorothy Stark Barbara Staszak Martin Stephens Adrian Stevens Fabrice Stolpman Victor Strutt Guenael Sun Feng-Wen Surineni Shravan TAGIRI HIROKAZU TakagiEiji Takagi Masahiro Takahashi Seiichiro Takai Mineo Takeda Daisuke Tambe Sonal Tan Pek-Yew Tan Teik-Kheong Tanahashi Mike Tanaka Hideki Tanaka Yasuhiro Tang Kevin Tao Jeffrey Taori Rakesh tavares clifford ten Brink Stephan Thoen Steven Thrasher Jerry Tilden Charles Ting Pangan Todd Terry Tokubo Eric Tolpin Alexander Tomcik James Towell Timothy Trachewsky Jason Trainin Solomon Tsao Jean Tseng Rodger Tsien Chih Tung David Turner Sandra Tzamaloukas Mike Uchida Yusuke Van Erven Niels Van Nee Richard van Waes Nico van Zelst Allert Varas Fabian Varsanofiev Dmitri Vaysburg Dimitry Victor Dalton Visscher Bert Vlantis George Vleugels Katelijn Vogtli Nanci Wakeley Tim Walker Jesse Wallace Brad Wandile Vivek Wang Huaiyuan Ward Robert Ware Christopher Warren Craig Watanabe Fujio Webster Mark Wells Bryan Wentink Menzo Weytjens Filip Whitesell Stephen Wilhoyte Michael Williams Richard Wilson James Winters Jack Wong Marcus Wong Timothy Woodyatt James Worstell Harry Wu Gang Wu Songping Xhafa Ariton Xia Bo Yamamoto Takeshi Yamaura Tomoya Yao Zhonghui Yaqub Raziq Ye Huanchun Yee James Yin Jijun Young Chris Yu Heejung Yu Heejung Yung Hon Yurtkuran Erol Zaks Artur Zeira Eldad Zhang Honggang Zhang Jinyun Zhu Chunhui Zhu Jeffrey Zuniga Juan-Carlos Zweig Johnny Zyren James March 2005 doc.: IEEE 802.11-05/0272

IEEE P802.11 Wireless LANs Minutes of 802.11 Task Group E MAC Enhancements – QoS Atlanta, GA March, 2005 Date: 2005-03-16

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.11e Task Group meeting of March, 2005 at Atlanta, Georgia..

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

March 2005 doc.: IEEE 802.11-05/0272

1. Monday Afternoon Session, March 14, 2005

1.2. Opening

1.2.1. Call to order 1.2.1.1. JohnF (John Fakatselis): I call the meeting to order. 1.2.1.2. Meeting convened at 1613 hours. 1.2.1.3. [Secretary’s note: Time Notations will be made in 24 hour format, subject to new 802.11 guidelines.] 1.2.1.4. JohnF: I refer attendees to the R3 agenda shown on the screen before you.

1.3. Process

1.3.1. Review of Agenda 1.3.1.1. JohnF: This meeting we have time reserved until this evening, then we shall meet again tomorrow. We will approve the minutes, make a call for papers, and then engage in technical comments and discussion. We have two slots allocated tomorrow, and Wednesday is our final day. We shall wrap up any comment resolutions in preparation for Wednesday. Any questions on the agenda? Hearing none, we shall proceed with approval of the agenda.

1.3.2. Approval of the agenda 1.3.2.1. JohnF: Is there any objection to adopting the agenda as shown? None. Hearing none, the agenda is approved. We shall now follow the agenda.

1.3.3. Review Objectives for the Session 1.3.3.1. JohnF: Let me review the objectives of the session. We just closed a sponsor ballot recirculation. We shall address the resulting comments, and then decide how to move forward. Any questions on the objectives? Hearing none, we shall proceed.

1.3.4. Rules and Status Review for New Members 1.3.4.1. JohnF: Are there any first-time attendees? Yes. The process we use is Robert’s Rules of Order. Only voting members can vote, however my policy is that non-voters can participate. You can be recognized if you would like to comment. If you have a motion, approach a voting member to bring a motion on your behalf. Are there any questions on rules, how we manage the meetings, or other process-related activities? No. Hearing none, we shall proceed with a status review. 1.3.4.2. JohnF: We had five “no” voters on the fifth recirculation. We ended up with no new “no” votes, however we received 11 new comments. We made provisions for an ad-hoc meeting in NJ. We were hoping for no further comments. We got comments, though, so we decided not to hold the meeting. We will address them instead at this meeting, and then proceed from there. Any questions? None. Hearing none, we shall proceed.

1.3.5. Approval of Minutes from Last Session 1.3.5.1. JohnF: The next item is approval of the minutes. Are there any questions on the minutes submitted from the last meeting in Monterey? Is there any

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

March 2005 doc.: IEEE 802.11-05/0272

objection to accepting the minutes? No. Hearing none, the minutes are approved. There are no matters arising from the minutes.

1.3.6. Call for Papers 1.3.6.1. JohnF: The next item is a call for papers. Are there any papers relevant to the comments. None. Hearing none, let us discuss the comment resolution process.

1.3.7. Discussion of Comment Resolution Process 1.3.7.1. JohnF: Srini, please give us an update on the letter ballot recirculation. 1.3.7.2. Mathilde: Are you going to consider papers on open comments? 1.3.7.3. JohnF: Yes, as long as the comment is open. 1.3.7.4. Srini: The comments are in document 131r0. There are 11 “no” comments, all from one commenter. 1.3.7.5. JohnF: We have to respond to these comments. I want to advise the group that if it determines good reasons to reject them and there are consequently no changes to the draft, then we can close the process as far as balloting. In July we could get final approval from ExCom. The next date for that, if we go to July, would be September for finalizing the standard through RevCom. If we make changes, we might go through several more recirculations. In this case the process could run until December or next year. 1.3.7.6. Mathilde: What would be the implications of Bob O’Hara’s maintenance activity? Is Bob’s activity a “rolling” one? 1.3.7.7. JohnF: One would have to go through a new PAR. This requires a formal request. So, we have 11 new technical comments. Amjad is here. You are one of the “no” voters? 1.3.7.8. Amjad: Yes. 1.3.7.9. Srini: Amjad had no comments from the last ballot. 1.3.7.10. Amjad: Yes they were outstanding from a previous ballot. 1.3.7.11. JohnF: If we make any changes on the draft, there could be a risk of not being ready by July. If we make no changes, we shall be moving toward closure. Let us look at the 11 comments, and see if we can “escape” with no changes. After completing these comments, then we can revisit, upon request, any other outstanding comments we answered previously. What I prefer to do is what we have done in the past: Discussion in an ad-hoc fashion with recommended resolutions. We can then try to act on them in formal session. Have you worked any of them? 1.3.7.12. Srini: All of the new comments are from Stephen Palm. 1.3.7.13. JohnF: I would like to recess the meeting into an ad-hoc meeting. 1.3.7.14. Srini: In my opinion at least 9 of the 11 are invalid. but I would prefer not to work these as moderator. 1.3.7.15. JohnF: Srini I would appreciate it if you could do it, as you are in the best position as editor to avoid protests. 1.3.7.16. Srini: OK, I will assist the process.

1.4. Closing

1.4.1. Recess 1.4.1.1. JohnF: That said, is there any objection to recess for the ad-hoc group by anyone? None. Hearing no objection, we shall recess until 1745 at which time we will reconvene formally. Are there any objections? No objections noted. Therefore, we are recessed.

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

March 2005 doc.: IEEE 802.11-05/0272

1.4.1.2. Recess at 1632.

1.5. Opening

1.5.1. Call to Order 1.5.1.1. JohnF: I call the meeting to order. 1.5.1.2. Meeting reconvened at 1745.

1.6. Process

1.6.1. Process and Comment Resolution 1.6.1.1. JohnF: Srini, could you summarize the ad-hoc group progress? 1.6.1.2. Srini: We have responded to all 11 comments from Palm and have recommended declining them. For the other 12 comments, we may wish to continue considering them. For the last few minutes in ad-hoc, we have been discussing Mathilde’s comments on multiple NAVs. I believe of the remaining 12 comments, the technical ones are easy to address. 1.6.1.3. JohnF: Are there comments on changes? 1.6.1.4. Srini: Most of them are not. 1.6.1.5. JohnF: We need to reject these with a politeness. We can then say that the editorial changes will not change the text materially, and we shall say the draft is not changed. Is that approach viewed as satisfactory by the group? 1.6.1.6. Srini: Some of the comments will be handled by the IEEE editors as well. 1.6.1.7. JohnF: I suggest orders of the day. I would like to work forward on the proposed resolutions for the 1030 meeting tomorrow. Let’s recess at 6:00 to allow the secretary to present his 802 tutorial. The rest of us can work on resolutions. We have a 1030 session tomorrow until 1530. I want to be within the 4 hour rule on anything we submit for action tomorrow morning. Sometime before 1530 we can act on them. Is there any discussion on the plan I discussed? None. We’ll make the 1930 slot available to the ad-hoc group. Accordingly we shall begin the ad-hoc discussion at 1930.

1.7. Closing

1.7.1. Recess 1.7.1.1. JohnF: Is there any objection to recessing until 1030 tomorrow? None. Hearing none, we are recessed until 1030 Tuesday morning. 1.7.1.2. Recess at 1800.

2. Tuesday Morning Session, March 15, 2005

2.1. Opening

2.1.1. Call to order 2.1.1.1. JohnF (John Fakatselis): I call the meeting to order. 2.1.1.2. Meeting convened at 1035.

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

March 2005 doc.: IEEE 802.11-05/0272

2.2. Process

2.2.1. Comment Resolution 2.2.1.1. JohnF: Let me just review status for those who may not have attended yesterday. We went through a sponsor ballot recirculation between meetings and reduced our “no” voter complement, however we received some 11 comments more. We have worked in ad-hoc to treat the 11 comments. I hope to approve these resolutions today at 1135. We might be complete this work before lunch. Given that, Srini, can you give us an update? 2.2.1.2. Srini: 131r2 is the document that shows the resolutions, and it is on the server. 2.2.1.3. JohnF: Between now and 1100, I would like to have a discussion on any comment not part of the last 11, but may still be open. Examples would be a persistent “no” vote from a commenter. I’d be happy to entertain these discussions now. After 1100, I’d like the membership to examine the proposed resolutions and take part in a block vote to approve them together. However, I would also like to offer the opportunity for members to mark any resolutions as exceptions to the block. At 1130 I shall ask for exceptions. At 1135 I shall act upon votes to accept the resolutions that are not excepted. Any objection to following the approach? None. Having said that, we shall proceed. Mathilde, did we finish discussion on your topic? 2.2.1.4. Mathilde: Is there anyone who supports additional NAV protection? 2.2.1.5. Amjad: I put some comments on the reflector that say that it would be better to have a mechanism for handling [multiple NAVs] than not. However, at the Berlin meeting it was decided by some that it should be optional and removed. I have not persisted with advocacy of the capability because its re-insertion would add delay. 2.2.1.6. Mathilde: The NAV that we have does not give the same protection as the current standard. This will have an effect on VoIP and streaming media, and the performance of EDCA will suffer. Document 04/1093r5 is the reference for these. 2.2.1.7. JohnF: Are there any other comments? 2.2.1.8. One question regarding data flows using HCCA.

2.2.2. Discussion on the Question 2.2.2.1. Question relates to latitude of HCCA to send other traffic following the completion of CF-Poll + Data and Ack sequence. Answer was that HC has the power to send arbitrary traffic in such a case, whether or not power control is in process.

2.2.3. Comment Resolution Process 2.2.3.1. JohnF: Are there any other items? 2.2.3.2. Srini: Comments 9 and 10 by Mathilde still require resolutions. Shall we work on them now? 2.2.3.3. JohnF: Yes 2.2.3.4. Srini: What resolution would be acceptable to you Mathilde? 2.2.3.5. Mathilde: I’d like a straw poll: How many feel lack of dual NAV will have no effect? I would like responses for "no effect”, and “don’t know” 3 votes for “no effect”, and 5 “don’t know”. 2.2.3.6. Srini: May I suggest a resolution for comment 9 based on this discussion? 2.2.3.7. Resolution “ Comment declined. The task group could not reach a consensus that the proposed mechanism provides significant improvement in performance”

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

March 2005 doc.: IEEE 802.11-05/0272

2.2.3.8. Moved Srini. Osama seconds. 2.2.3.9. JohnF: Is there any discussion on accepting the proposed resolution? None. Hearing none, we shall vote. Vote passes unanimously 12 “for”, 0 “against”, 4 “abstain”. 2.2.3.10. Srini: I propose to address comment 10 similarly. I move to accept the resolution: 2.2.3.11. “Comment declined. The task group could not reach a consensus that the proposed mechanism provides significant improvement in performance” 2.2.3.12. Moved Srini, Second Steven 2.2.3.13. JohnF: Is there any discussion on the motion? None. Hearing none, we shall vote. I call the question. Is there any discussion? No, the question is called. We shall vote on the motion. The motion passes 12 “for”, 1 “against”, and 4 “abstain”. 2.2.3.14. Srini: We still have Amjad’s old comments (not from this re-circ). 2.2.3.15. Amjad: I believe the comments are still valid. However, I shall not discuss them now, because I do not see a resolution. Moreover, it could require changes in the document which would extend the time to finish the process. I have offered that I am willing to request the working group chair to take these comments into consideration by the maintenance task group. I shall be willing to support the draft by changing my “no” votes to “yes”. It is up to the task group to handle the comments as they would like. 2.2.3.16. Mathilde: It may be as long as three years from the time “e” is certified until “m” can act. It could mean a lot of legacy product gets into the field before problems can be resolved with new equipment. 2.2.3.17. JohnF: I shall see to handling Amjad’s comments as he has suggested. I would like to give the next 15 minutes to the membership... 2.2.3.18. Srini: I propose a motion to deal with Amjad’s comments: 2.2.3.19. “Move that the Task Group requests to forward all “disapprove” comments by Amjad Soomro, Javier del Prado, and Stuart Kerry to Task Group “m” for consideration for a future revision of the standard.” 2.2.3.20. Moved Amjad/Srini seconds. 2.2.3.21. JohnF: If we make no changes to the draft, we may move the process forward materially. In my view this would be a good thing to do. 2.2.3.22. Mathilde: I believe there has to be a delay in processing issues through the maintenance group. Moreover, I am unclear on the rules regarding the need to re-circulate if a change of no to yes votes remove the comment and other commenters want to attach to those comments. 2.2.3.23. Mat Sherman: As long as there is no new “no” vote, no recirculation should be necessary. 2.2.3.24. JohnF: Is there any further discussion on the motion? None. Very well, let us vote on the motion. The vote passes unanimously, 16 “for”, 0 “against”, 2 “abstain”. 2.2.3.25. Mat: I shall check during the break on the details of Mathilde’s question and get back to her. 2.2.3.26. JohnF: In accordance with our plan, I would like to recess until such time as we act on the block of resolutions.

2.3. Closing

2.3.1. Recess 2.3.1.1. JohnF: Is there any objection to recess for 10 minutes? None. Very well, we are recessed. 2.3.1.2. Meeting recessed at 1122. Submission page 6 R. R. Miller, AT&T

March 2005 doc.: IEEE 802.11-05/0272

2.4. Opening

2.4.1. Call to order 2.4.1.1. JohnF (John Fakatselis): I call the meeting to order. 2.4.1.2. Meeting convened at 1132. 2.4.1.3. Srini, can you prepare a motion to accept the resolutions in the new document? 2.4.1.4. Srini: I wish to so move: 2.4.1.5. “Move to accept the resolutions as written in 05/131r2 for the comments contained therein. 2.4.1.6. Moved Srini. Seconded Andrew 2.4.1.7. JohnF: Before I ask for a second, would anyone like to pull out a comment for individual discussion? Would any one like to propose an exception. None. Seeing no indication of exception, is there any discussion on the motion? None. Seeing none, we shall vote. The vote to accept the proposed resolutions passes unanimously 12 “for”, 0 “against”, and 2 “abstain”. This concludes all of the mandatory responses and discussion on outstanding comments. We can conclude the meeting if we create the motions necessary to proceed without changes to the draft and recirculation. Technically, people cannot add any more comments, and all areas have been closed. If there is a comment made, it is up to the group to consider it. We may now move quickly toward closure. The next step is to present the final draft to Revcom. That requires a meeting in July, so we may have an approved standard by September. 2.4.1.8. Srini: I have prepared a motion: 2.4.1.9. “Believing that sponsor ballot comment responses in 11-05/0131R3 and the document mentioned below satisfy IEEE-SA rules for sponsor ballot recirculation, Authorize a SB recirculation of 802.11e draft 13.0 to conclude no later than 04/15/2005. Movers: Srini, Andrew Estrada seconds TGe: Result: WG: x/x Result: x-x-x” 2.4.1.10. JohnF: Is there any discussion on this motion? None. Hearing none, we shall vote. The vote passes unanimously. 15 “for”, 0 “against”, 0 “abstain” 2.4.1.11. JohnF: Barring any other items, I declare that the work of the task group is completed for this plenary session.

2.5. Closing

2.5.1. Recess 2.5.1.1. JohnF: Is there any objection to adjourning the task group? None. Hearing none, we are closed. 2.5.1.2. Meeting adjourned at 1147.

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

March 2005 doc.: IEEE 802.11-05/0305

IEEE P802.11 Wireless LANs Minutes of 802.11 Task Group K Radio Resource Measurements Atlanta, GA March, 2005 Date: 2005-03-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.11k Task Group meeting of March, 2005 at Atlanta, Georgia for Thursday sessions. The author has substituted for the TGk secretary at the request of the chair due to the absence of the designated group secretary.

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 Submhave questions,ission contact the IEEE Patent Committee Administratorpage 1 at . R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

1. Thursday Afternoon Session, March 17, 2005

1.2. Opening

1.2.1. Call to order 1.2.1.1. Richard: [Richard Paine]: I call the meeting to order. 1.2.1.2. [Secretary’s note: Time notations will be made in 24 hour format, subject to new 802.11 guidelines.] 1.2.1.3. Meeting convenes at 1332.

1.3. Process

1.3.1. Review Objectives for the Session 1.3.1.1. Richard: This afternoon we shall work on comment resolution, but also have a few presentations relating to this work. These presentations are scheduled to begin at 1430. Is there any objection? None. Very well, we shall proceed.

1.3.2. Overview of Presentations 1.3.2.1. Richard: I have been asked to allow a representative of 802.11p to address the meeting. Is there any objection? None.

1.3.3. Discussion of 802.11p Activities 1.3.3.1. Jeffrey Zhu: 802.11p is working on High Precision RSSI , would request “k” help developing fabric/ensuring coherence. 1.3.3.2. JoeKwak: You might be able to use “k” as foundation with tightened precision (currently +/- 5 dB in k). I recommend that “k” should help with the “p” process.

1.3.4. Discussion of 802.11k Help to Other Groups 1.3.4.1. Richard: A number of other groups with activities underway have requested liaison/consultation regarding “k” interactions. 1.3.4.2. BruceKraemer: We have been through situations before where task groups have been asked to “stretch” to other domains, but they must be careful as if PAR is exceeded, the “help” might have to be “ripped” out. 1.3.4.3. JoeKwak: There are already interactions with “v”, some of which I have been pursuing. 1.3.4.4. Richard: (puts slide on screen suggesting options for ballot pool modifications during comment resolution, opening new ballot or recirculation discussion) 1.3.4.5. JoeK: We should improve the draft to the point of letter ballot of acceptability for the existing pool first. We’re not going to short circuit requirements, but should stay in recirculation until 75% is exceeded. New letter ballots will draw a bigger voter pool and more comments, which will slow the process. 1.3.4.6. FloydS: We should consult the IEEE rules on this. 1.3.4.7. Richard: I’ve put a representative motion on the screen, however we do not yet know the official results of that last ballot. First, lets look at what we have to complete in this session: presentations, perform comment resolutions, and vote on teleconferences according to the agenda. Until the presentations, lets

Submission page 2 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

talk about resolutions. Many comments relate to the sheer bulk of the “k” draft. 1.3.4.8. Floyd: Many are repeats of previous comments by the same people. 1.3.4.9. SimonBlack: The draft’s been around a while now, so a number of people in the room have entered a lot of comments with small things. Generally, these are quick to solve. A large number of comments doesn’t necessarily translate into a long resolution period. There are a lot of comments that also repeat with different commenters. Many comments looking for more clarity or questioning “Why have that?” over and over. 1.3.4.10. Richard: Every clarification is a lot of work 1.3.4.11. JoeK: Between the last ballot and this one, many responded with a lot of comments suggesting “take out” a feature, and we didn’t address these very well. We should give better reasons, or add an appendix so as not to provoke more “no” comments. We need to point to a document or annex to show that the measurements are useful and warranted for 802.11 networks. 1.3.4.12. Richard: We should bring this to a close, but I must check on some rules before we make motions on the voter pool. Perhaps use of the Powerpoint “pitch” to crisply describe what “k” is about would help to speed the process by showing those not familiar with the draft how we expect the measurements to be used. 1.3.4.13. StephenWang: Many folks haven’t paid attention to the details in the draft and made comments that do not allow precise treatment. We should find a way to encourage suggested repairs, rather than putting the burden on us. 1.3.4.14. TimOlson: We have to discourage comments that say “just delete it”. 1.3.4.15. Richard: Yes, we need to do that.

1.3.5. Presentation of Document 05/1637r4 1.3.5.1. On the server. 1.3.5.2. Presentation by Emily Qi. Discussion of statistical measurements. In this proposal additional QoS measurements are proposed to expand performance metrics on QoS sessions. A new measurement type for QoS is defined. Want to measure delay for video and voice, and need delay histogram.

1.3.6. Discussion on the Presentation 1.3.6.1. General discussion about how metrics would be used: 1.3.6.2. FloydS: The AP can make request of station and vice versa, but where would the information for both up and down reside? 1.3.6.3. TimO: The information can reside at the AP. 1.3.6.4. Discussion regarding what provisions are allowed with respect to request of information between APs and STAs, and what addresses appear in the request and reply. 1.3.6.5. StephenW: There are also power save delay implications. I wonder how useful the information will be given this uncertainty. 1.3.6.6. TimO: Not every station will have power save. 1.3.6.7. StephenW: Still, I don’t understand what the measurement is useful for, given the complication different situations can cause. 1.3.6.8. TimO: It allows APs to monitor behavior of the network. For example, one might want to monitor behavior of power-save clients, for example. 1.3.6.9. AmjadSoomro: This was an objective presentation of value. Many good things were discussed. However I’d like to know, “When are the measurements performed?” “While traffic is in progress?” The AP has to know beforehand to issue the measurement to make it useful. Submission page 3 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

1.3.6.10. EmilyQ: The requester can ask for an autonomous report, ongoing. 1.3.6.11. AmjadS: Would prefer to see metrics kept over the lifetime of a session while the session is active, without an explicit start and stop. 1.3.6.12. SimonBlack: I have a presentation that speaks to this point. I agree with Amjad, but Emily’s ideas are an important first step. 1.3.6.13. JoeKwak: There is a selection of counters. As a traffic stream measure this presentation adds detail about a particular stream. But we could also get information from existing traffic stream counters. Why not collect all of the counters and filter them? 1.3.6.14. SimonB: The counters here are the key ones that enable you to understand exactly why impairments are happening, rather than simply noting that they happened. The suggestion here is to remove system overhead in the station to measure constantly. 1.3.6.15. [Unknown]: The “CF Polls Lost” counter is currently part of the measurement suite. 1.3.6.16. SteveEmiott: Can you address anticipated usage in parallel with other measurement messages? This could use a lot of resources. Can this be used in conjunction with other measurements? Can one keep measurements going in parallel? 1.3.6.17. TimO: Every request must include all measurements, or existing will be canceled. 1.3.6.18. AmjadS: These are the right things to capture, but I have concerns about how statistics are defined in the draft. It is important for QoS to measure delays of frames that went through, but also those that did not go through. This measurement would give a rosy picture, because only shows successful packets. 1.3.6.19. EmilyQ: There are other counters that treat this problem. 1.3.6.20. AmjadS: It would be nice to make definition consistent including all packets, though. 1.3.6.21. SimonB: For example, you know how many of the packets didn’t arrive due to lifetime. 1.3.6.22. AmjadS: Yes, but can’t know why they were discarded. 1.3.6.23. JoeK: Our multiple retry count could have been clearer. You currently lose in the counter how many were transmitted 2,3, or more times. 1.3.6.24. TimO: Each retry is not counted as a separate delay. 1.3.6.25. AmjadS: In the contention-based EDCA mode, retry count makes sense, but not so much in the HCCA where packets are at the mercy of the QAP. Metrics depend on many poll characteristics. I recommend more information captured in another parameter. 1.3.6.26. TimO: We are simply logging delay, not clear about what extra statistics are needed. 1.3.6.27. AmjadS: Having a large multiple retry count doesn’t necessarily imply trouble. 1.3.6.28. SimonB: There are currently no QoS measurements like this in “e” 1.3.6.29. StephenWang: Little difference between discarded and failed counts. 1.3.6.30. SimonB: Discard gives MDSUs due to lifetime or retry limits, but failed count shows “hits” due to retrys or long medium access delays. I think these do give useful information. 1.3.6.31. SandeshG: Should delay for failed MSDUs should be taken into account for average delay? 1.3.6.32. JoeK: You can compute this. 1.3.6.33. SandeshG: Can one AP request this of another AP? 1.3.6.34. EmilyQ: It depends on policy. There is a comment about this. Submission page 4 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

1.3.6.35. FloydS: Struggling with use cases I have questions regarding reports and where they reside based on who asked? 1.3.6.36. TimO: This is why measurements are needed. An example is “Is the trouble with the wireless network or the whole network?” One can look at just wireless with these measurements, so one can partition problems. 1.3.6.37. AmjadS: I have a statistics-collection question. Average delay is important, but you need a lot of samples for accuracy, perhaps 4-5 seconds for long packets. This is a long measurement time, so the process must continue running causing much overhead. We might need a simple measurement scheme running all the time looking for problem rather than this method. 1.3.6.38. EmilyQ: more complicated… 1.3.6.39. AmjadS: Not necessarily. 1.3.6.40. SimonB: We need to get the measurement properly defined as a first step. 1.3.6.41. TimO: I’m confused. It seems like a measurement for 5 sec is better than all the time in background. 1.3.6.42. AmjadS: But it could preclude other measurements at same time. 1.3.6.43. TimO: “k” allows that. How is this different, as it seems like same measurements are still being done. 1.3.6.44. AmjadS: Simple counter updates are less overhead than interpretive (e.g. average measurements). 1.3.6.45. SteveE: A question regarding STA-STA measurements: Can a station ignore the request if it doesn’t have an association? 1.3.6.46. TimO: The STA only does it according to the table in the draft. There were many comments about the station-to-AP case. STA-STA cases are only allowed in IBSS currently. 1.3.6.47. Richard: Is there a motion connected to the presentation? Yes. 1.3.6.48. “Move to instruct the editor to include 11-05-1637r4 in the next 11k draft” 1.3.6.49. Moved Emily Qi 1.3.6.50. Second: Simon Black 1.3.6.51. Richard: Is there discussion on the motion? 1.3.6.52. TimO: I speak in favor. System manufacturers have trouble debugging VoIP phones, and can’t partition trouble because of no measurement capability. Even if this isn’t the right solution, they still need something. 1.3.6.53. AmjadS: I agree with Tim, such a measurement is needed. After this goes into draft could it be modified? 1.3.6.54. JoeK: I speak in favor: As a group we recognized that VoIP time-domain measurements were important. So far we haven’t adopted any time-based proposals. We should put this into the draft to fix a hole and encourage improvement. 1.3.6.55. Richard: Is there any further discussion? No. Seeing none, we shall vote. The vote passes unanimously: 13 “For”, 0 “Against”, 6 “Abstain”.

1.3.7. Presentation of Document 05/294r0 1.3.7.1. SimonB: This presentation, on the server, treats a new twist on autonomous measurements, and fits well with previous discussion. We need a QoS measurement scheme that runs continuously but alerts only when needed. The idea needs a triggering mechanism, though. This idea sets up measurement with a “trigger condition”. The QAP has knowledge of the setup, format, and results. However it needs to define the trigger using new trigger fields. Trigger thresholds specifications are described.

Submission page 5 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

1.3.8. Discussion on the Presentation 1.3.8.1. FloydS: How do you cancel the process? 1.3.8.2. SimonB: One could send another measurement command or DELTS. 1.3.8.3. StephenWang: Could you turn on and off the measurement keyed to the TSPEC? What happens to the measurement if a TSPEC is overridden by another? Does the measurement change? 1.3.8.4. SimonB: One would have to modify the measurement if one wanted to do that. 1.3.8.5. Stephen: If I first set up a TSPEC, then send another for say power save or HCCA? 1.3.8.6. SimonB: One would send another measurement condition. 1.3.8.7. SteveE: This sounds similar to conditional reporting. Might we want to adopt similar nomenclature? 1.3.8.8. SimonB: Beacon reporting conditions work only at the time when the condition is met, this is a requested periodic measurement that reports whenever the condition is met. 1.3.8.9. SteveE: See this as similar. Is there any “duration” in this concept? 1.3.8.10. BobM: Is there a problem if many clients running this all report at once in a synchronized “storm”? Could this bring a system down or violate parameterized traffic guarantees simply by reporting? 1.3.8.11. SimonB: Perhaps, the AP should probably not have this running on a lot of clients at once. 1.3.8.12. JoeK: Suggest that we adopt similar nomenclature for similar things to simplify the draft. We probably also need to describe the priority of measurement processes. We might need to limit measurements as separate with exceptions for parallel measurements. If one runs in background, it implies implicit parallelism. We may trigger objections raised before. 1.3.8.13. SimonB: Some periodic measurements force radio to go to another channel, but this doesn’t fit in the same category. These are not inherently disruptive to channel processes running at the time. Before, you could have conflicts with in-process operations that interfere. 1.3.8.14. TimO: I support this concept. I see a difference between this and beacon periodic measurement. This could run for total length of stream. A better solution than setting arbitrary periodicity. 1.3.8.15. JoeK: If this could be done in background always on serving channels, we might also be able to do this for other measurements that can be done on channel. For example could we have two types of measurements: “1 frame only”, and “permanent” on a channel?. Let’s not confuse this with “autonomous”. 1.3.8.16. SimonB: This runs continuously, but triggers only when something abnormal happens. 1.3.8.17. BobM: So this is a debugger? 1.3.8.18. SimonB: Well, yes, sort of. 1.3.8.19. FloydS: It appears that the time between the trigger condition and report could affect usefulness. 1.3.8.20. SimonB: These are simple measurements, not likely to cause this trouble as autonomous might. 1.3.8.21. Richard: Can we continue with Simon’s straw poll? We are out of time. I suggest we pick up with the poll after the break. Simon is that acceptable? 1.3.8.22. SimonB: Yes

Submission page 6 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

1.4. Closing

1.4.1. Recess 1.4.1.1. Richard: Is there any objection to recess for the break? None. Hearing none we are recessed until 1600. 1.4.1.2. Recess at 1532.

1.5. Opening

1.5.1. Call to Order 1.5.1.1. Richard: I call the meeting to order. 1.5.1.2. Meeting reconvened at 1600.

1.6. Process

1.6.1. Process and Comment Resolution 1.6.1.1. Richard: Is there any objection to adding a vote on the minutes to the agenda? None. Hearing none, it is so added. Is there any objection to having Simon’s straw poll at this time, continuing the process from before recess? None. 1.6.1.2. SimonB: I would like a straw poll: 1.6.1.3. “Do you support the concept of Triggered QoS Measurements?” Yes, No, Abstain. 1.6.1.4. Vote 11 “Yes”, 4 “No”, 1 “Abstain” 1.6.1.5. BobM: Just want to point out that triggered reports can produce an internal denial of service attack if misused. 1.6.1.6. Richard: I think Simon can work that. 1.6.1.7. Victor: Should map down to smaller set of mandatory measurements, with others optional. Would encourage implementers to choose to implement some rather than being daunted by complexity and never implement anything. 1.6.1.8. Richard: Let’s extend thinking on that. Perhaps we should define a “core set”. What would be make mandatory and what optional? 1.6.1.9. SimonB: We already have few mandatory, more optional. 1.6.1.10. Victor: Many may not be aware of this partitioning, I suggest education. 1.6.1.11. Richard: I need to hear the group’s preference: Shall we recess now until 5:30 have votes then finish up? Agreement. 1.6.1.12. SimonB: Before we break, I’ve uploaded some information that I would like feedback on. Document 252r1 addresses comments from 191r12. 1.6.1.13. JoeK: I’d like some clarification on the process for comment resolution. We need to ensure efficient partitioning of comments with no overlap. Currently, we’ve divided the comments into sub-groups with highlighted treatment on a master, work on them separately in sub-groups, and then bring them back to the larger group. 1.6.1.14. Richard: In Austrialia I would like to see recommended blocks of “easy” comments that could be acted upon, but would also like resolutions for the “hard” ones. 1.6.1.15. JoeK: About 40% appeared to have simple responses. 1.6.1.16. Richard: I think it will be worse going-forward.

Submission page 7 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

1.6.1.17. JoeK: But how do we divide them? QoS comments refer to many areas of the text, not just a particular section. Who has the clause-to-category relationship? 1.6.1.18. SimonB: That should be in r12. 1.6.1.19. Richard: I need to know the result from Harry before we can act responsibly. I expect that 10% of comments will have to be moved. 1.6.1.20. FloydS: Could lead to a lot of “orphaned” comments. 1.6.1.21. JoeK: I favor only one clearinghouse for comments. 1.6.1.22. SteveE: I created a new spreadsheet offering suggestions for moves. Is there a standard way we want to do that? 1.6.1.23. SimonB: That’s why I did the Powerpoint, so that many comments were treated as a logical group. 1.6.1.24. Richard: So you have enough comments that aren’t going to change. The others could be treated later. 1.6.1.25. JoeK: I can take a first cut and then give them to you. We need a single master list. Paul and I will work out a list of categories and comments that belong to them. 1.6.1.26. TimO: Addition of suggestions for treatment currently prevent sorting. I suggest deleting them to re-allow sorting.

1.7. Closing

1.7.1. Recess 1.7.1.1. Richard: Is there any objection to recess until 1730? None. Hearing none we are recessed until 1730. 1.7.1.2. Recess at 1637.

2. Thursday Evening Session, March 17, 2005

2.1. Opening

2.1.1. Call to order 2.1.1.1. Richard: I call the meeting to order. 2.1.1.2. Meeting convened at 1730.

2.2. Process

2.2.1. Agenda Items 2.2.1.1. Richard: We must accept the teleconference minutes. We had only one conference. Would someone like to move. 2.2.1.2. “Move to accept the Monterey-Atlanta teleconference minutes 05/0230r1” 2.2.1.3. Moved Joe Kwak. Seconded Simon Black 2.2.1.4. Richard: Is there any objection to accepting the minutes? None. The minutes are accepted. I show a motion: “Empowerment for Teleconferences Move to request the Working Group to empower TGk to hold weekly teleconferences (Wednesdays at 1130 Eastern time) through 2 weeks after the Cairns interim as required to conduct business necessary to progress the Letter Ballot process, including creating and issuing drafts for Letter Ballots Submission page 8 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0305

and handling other business necessary to progress through the IEEE standards process.” 2.2.1.5. Moved Simon Black, Seconded John Klein 2.2.1.6. Richard: Is there any discussion on the motion? None. Seeing none, is there any objection to passing this motion? None. 2.2.1.7. Vote is unanimous (13 members present)

2.2.2. Comment Resolution 2.2.2.1. Richard: I was not able to get a hold of Paul. 2.2.2.2. SimonB: I have been successful in getting the spreadsheet to sort correctly again. 2.2.2.3. Richard: I deleted the troublesome lines, but could not contact Paul. The only thing left to do, is to prepare the closing report, document 05/186r3. On the server it will be r4. I show r3 on screen [shares some edits]. 2.2.2.4. Richard. I show for the membership that the next Telecom is on 03/23/05 as shown in the previous motion and the r4 document, for the purpose of editorial resolution. 2.2.2.5. Richard: We shall wait for Harry’s vote tally, and I shall craft an appropriate recirculation strategy.

2.3. Closing

2.3.1. Recess 2.3.1.1. Richard: Is there any more business? No. Do I hear a motion to adjourn? Yes. Moved Black/Tim Olson. Is there any objection to adjourning? None. Hearing none, we are adjourned. 2.3.1.2. Meeting adjourned at 1753.

Submission page 9 R. R. Miller, AT&T Thursday TG minutes, standing in for TGk secretary.

March 2005 doc.: IEEE 802.11-05/0205r0

Report of TGm – March 2005

DATE: March 2005 Author(s) Name Company Address Phone email

Bob O’Hara Airespace 110 Nortech Pkwy, San 408 635 2025 [email protected] 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 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 < [email protected]>

Report and Minutes Slide 1 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0

Abstract

Report of the meeting of TGm at the March 2005 session.

Report and Minutes Slide 2 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Goals for March 2005

• Integration of content from AP Functional Description SC • Process any interpretation requests received • Issue of draft to working group letter ballot

Report and Minutes Slide 3 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Submissions

• Submissions – Darwin Engwer: 04/639, 05/69r2 – Simon Black: 05/209 – Output of APF: 05/120, 05/105, 05/257, 05/262

Report and Minutes Slide 4 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Proposed Agenda

• Review IEEE Patent Policy • Review interpretation request procedure • New business – Submissions – Continue with items from 04/801r3 – APF SC submission – Instruct Editor to create 802.11REVma/d1.0 – Approve draft – Forward draft to working group for letter ballot – Interpretation Request • Adjourn

Report and Minutes Slide 5 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #1 to adopt Agenda

• Moved: to adopt the agenda • Mover: Andrew Myles, Darwin Engwer • Passes: unanimous

Report and Minutes Slide 6 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 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, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Interpretation Procedure

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

Report and Minutes Slide 8 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Report from APF Group

• Dorothy Stanley presented documents 05/120, 05/105, 05/262, and 05/257. – 05/120 will be included as an informative annex – 05/105 provides changes predominately in clause 5 – 05/257 will be included as an informative annex – 05/262 provides description of a DS service interface • Documents 04/1225 and 05/159 provide additional background information on the material in the above documents

Report and Minutes Slide 9 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #2

• Moved: to adopt the text in document 05/105r4 and incorporate it into the 802.11REV-ma draft. • Moved: Dorothy Stanley, David Hunter • Passes: unanimous

Report and Minutes Slide 10 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #3

• Moved: to incorporate the text from document 05/257r0, plus the examples from 05/159 (the result shown in 05/257r1), and incorporate it in the 802.11REV-ma draft. • Moved: Sandra Turner, Darwin Engwer • Passes: unanimous

Report and Minutes Slide 11 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Straw Poll

• Question: should we continue with the definition of the DS service interface presented in 05/262? –Yes:6 –No: 2 • Question: How should this be done: – Clause 6: 4 – Informative annex: 5

Report and Minutes Slide 12 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #4

• Moved: to resolve item #71 with the text in document 05/209r0. • Moved: Darwin Engwer, Jon Edney • Passes: unanimous

Report and Minutes Slide 13 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #5

• Moved: To resolve item #93 with the text in document 05/209r0. • Moved: Darwin Engwer, Dorothy Stanley • Passes: unanimous

Report and Minutes Slide 14 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #6

• Moved: to resolve item #39 with the text in document 04/639r1 • Moved: Darwin Engwer, Fred Haisch • Passes: 7-0-6

Report and Minutes Slide 15 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #7

• Moved: to adopt the text in document 05/120r9 and incorporate it into the 802.11REV-ma draft. • Moved: Darwin Engwer, Roger Durand • Passes: unanimous

Report and Minutes Slide 16 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #8

• Moved: to resolve item #35 with the text – Append to the end of the second paragraph of 9.3.2.1: If there are buffered multicast or broadcast frames, the PC shall transmit these prior to any unicast frames. • Moved: Roger Durand, Darwin Engwer • Passes: unanimous

Report and Minutes Slide 17 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #9

• Moved: to resolve item #29 with the text – In the last sentence of 11.1.2, replace "us" with "symbols“ and delete “for PHYs of 1 Mb/s, or greater”. • Moved: Roger Durand, Darwin Engwer • Passes: unanimous

Report and Minutes Slide 18 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Interpretation Request

It's unclear from the said specification (802.11h) how the following condition is to be handled: Suppose you wanted a periodic quiet period after EVERY Beacon. What should appear in Quiet Count in the Quiet Element that is in each Beacon? According to the specification, a value of "1" would indicate that the quiet period is after the NEXT Beacon; and a value of 0 is reserved (not allowed). Hence the question.

Report and Minutes Slide 19 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Interpretation Response (Motion #10)

• Moved: Resolved that the task group considers the interpretation request is a request for consultation on the use of 802.11h and not a valid request for interpretation of the standard. We believe that it is possible to accomplish what the questioner asked using the mechanisms and values currently defined in the standard. We request the WG chair to respond appropriately to the requester. • Moved: Andrew Myles, Roger Durand • Passes: unanimous

Report and Minutes Slide 20 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #11

• Moved: to adopt the text in document 05/262r1 and incorporate it into the 802.11REV-ma draft. • Moved: Darwin Engwer, Dorothy Stanley • Passes: 3-0-1

Report and Minutes Slide 21 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #12

• Moved: to update the resolution to item 13a by adopting the text in document 05/69r2 and incorporate it into the 802.11REV-ma draft • Moved: Darwin Engwer, Roger Durand • Passes: unanimous

Report and Minutes Slide 22 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #13

• Moved: to direct the editor to incorporate the material adopted by the task group in this session into 802.11REV- ma draft 1.0. • Moved: Andrew Myles, Dorothy Stanley • Passes: unanimous

Report and Minutes Slide 23 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #14

• Moved: Believing the draft to be complete and free of unresolved technical issues, Task Group m resolves to forward 802.11REV-ma draft 1.0 to the working group for the purpose of conducting a 40-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 “To conduct a 40-day working group letter ballot for the purpose of forwarding 802.11REV-ma draft 1.0 to sponsor ballot.” • Moved: Darwin Engwer, Andrew Myles • Passes: unanimous

Report and Minutes Slide 24 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Motion #15

• Moved: request the IEEE 802.11 Working Group chair to make the IEEE 802.11REV-ma draft 1.0 available for purchase. • Moved: Darwin Engwer, Dorothy Stanley • Passes: unanimous

Report and Minutes Slide 25 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Work completed

• Adopted resolutions to 6 work items

Report and Minutes Slide 26 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Summary

Work Items at start 8

Work Items added 0

Work Items assigned 0

Work Items closed 5

Work Items to Editor 6* *one previous item updated Work Items remaining 3* *these items closed: unaddressed Percentage completion (117 items) 97.4%

Report and Minutes Slide 27 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Output Documents

• 05/0205r0: This report • 05/22r2: Tracking list of work items • 802.11ma-d0.6: current working draft on server • 802.11REVma-d1.0: to be available soon

Report and Minutes Slide 28 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Goals for May

• Process comments from WG ballot • Issue new draft to working group recirculation ballot (stretch) • Process any interpretation requests received

Report and Minutes Slide 29 Bob O'Hara, Airespace March 2005 doc.: IEEE 802.11-05/0205r0 Adjourn

• Meeting adjourned at 3:30pm on March 17, 2005

Report and Minutes Slide 30 Bob O'Hara, Airespace March 2005 doc.:IEEE 802.11-05/0162r0

IEEE P802.11 Wireless LANs

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

Date: 2005-03-18

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 Atlanta, GA. from March 14 through 18, 2005. The session was chaired by chair person elect Bruce Kraemer from Conexant.

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

March 2005 doc.:IEEE 802.11-05/0162r0

Executive Summary (also see Chairs’ meeting doc 11-05-0095r6 and closing report doc. 11- 05-0297r1):

1. Both the TGn Sync and WWiSE proposals were updated and presented 2. An additional 12 technical presentations we made; all were related to the proposals and associated Q&A 3. 8 hours was devoted to Q&A – responses to email questions and questions from the floor 4. A joint meeting with .19 was held to review the process of generating a Coexistence Assurance document 5. A Down Selection vote was held with the result: 331 respondents, Sync 178 (53.8%), WWiSE 153 (46.2%) 6. The 1st Confirmation Roll Call Vote was then held with the result: 322 respondents, Confirm 182 (56.5%) and Not Confirm 140 (43.5%). Since a 75% threshold must be met for the confirmation vote to pass, the vote failed 7. Sean Coffey, (RealTech) and Adrian Stephens (Intel) accepted nominations for Technical Editor 8. The election of the Technical Editor was tabled until the May meeting since a baseline document had not been confirmed 9. Plans for the May meeting include the 2nd Confirmation Vote and discussion of the Time Line

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 of the various presentations and therefore are not subjective. An effort was made to note obscure acronyms.

Note: 2) Relative to Q&A, Q&A was particularly hard to capture and is subjective. Please contact the secretary regarding errors and omissions. ******************************************************************************

Detailed cumulative minutes follow:

Monday, March 14, 2005; 4:00 PM – 9:30 PM [~ 210 attendees];

1. Meeting was called to order by Task Group chairperson at 4:07 PM 2. Chairs’ Meeting Doc 11-05-0095r0 3. Chair read IEEE-SA Standards Board Bylaws on Patent Policy and additional Guidance 4. Chair reviewed topics not to be discussed during the meeting – licensing, pricing, litigation, market share 5. New participants in .11n ~= 22 6. Chair gave a status update from Jan meeting in Monterey and interim period 7. In particular results of the Jan. down selection vote and tentative plans for this meeting as presented at the Jan meeting were summarized 8. Motion by Jon Rosdahl to approve Jan minutes, 11-05-1593r2, was seconded by John Eagan passed without comment

Submission page 2 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

9. Chair reviewed plans for this meeting: 9.1. Update Both Complete Proposal presentations (2 hrs) 9.2. “x” Comparison & Market Application Presentations 9.3. “y” Technical presentations regarding Proposals 9.4. Q&A (8 hrs) 9.5. Hold Down Select vote 9.6. Preliminary planning for generating Coexistence Assurance doc with .19 9.7. Hold Confirmation vote 9.8. Hold Technical Editor election 9.9. Formulate Plans for May 10. Discussion: 10.1. Chair reviewed where we are in the selection procedure and in particular step 17 10.2. Down selection will occur in Wednesday 4 PM slot as a special order? 10.3. Chair asked floor for comments on down selection vote procedure: 10.3.1. 5 minute summary speech prior to down selection vote was requested 10.4. Chair asked if the floor wanted a roll call down selection vote? 10.4.1. No one from the floor indicated that they would ask for a roll call down selection vote 10.5. Confirmation vote will occur in Thursday 9 AM session as a special order? 10.6. Chair asked floor for comments on confirmation vote process 10.6.1. Floor had none 10.7. Chair called for Nominations for Technical Editor and noted that the nomination period was open 10.8. The following nominations were received: 10.8.1. Steve Shellhammer nominated Adrian Stevens, Intel 10.8.2. Bill Carney nominated Sean Coffey, RealTek 10.9. Chair informed candidates of an 802.11 editors meeting tomorrow morning and suggested the candidates attend 10.10. Move technical editor election until the 10:30 to 12:30 slot in order that the results of the confirmation vote be known before the technical editor vote 10.11. Floor did not object to not having the election of the technical editor as a special order but simply during the 10:30 – 12:30 slot 10.12. .19 joint meeting will be Thursday 8-9 AM; no objection from the floor 10.13. Chair asked for latitude in scheduling this evenings agenda topics due to uncertainty related to number of comparison presentations 11. Motion to approve the agenda made by Adrian Stephens and seconded by David Bagby passed unanimously

Submission page 3 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

12. Documents which have been submitted were enumerated by the chair in doc 11-05-0095r0 13. Additional Presentations? 13.1. 11-05-0193-00-000n by TGn Sync 14. Email questions responses: 14.1. 11-05-0180 WWiSE Response to Questions 14.2. 11-05-0182 nSync Response to Questions 15. Technical/Comparison Presentations: 15.1. New: Richard Williams 15.2. New: Eldad Perahia 15.3. 11-05-0146 John Benko 15.4. 11-05-0183 John Ketchum 15.5. 11-05-0181r0 Chris Young 16. Presentation #1 John Benko, France Telecom: Advanced Coding Comparisons; 11-05-0146r2 16.1. Historical Perspective 16.2. Requirements 16.2.1. Better than PBCC 16.2.2. Low cost 16.2.3. Low latency 16.3. Recommendations 16.3.1. Modular so implementation independent 16.3.2. Difficult to compare complexity without further study 16.3.3. Rethink advanced coding 16.3.4. Form a separate advanced coding sub-group to consider this module? 17. Presentation #2 Chris Young, Broadcom: Legacy Device Testing with Mixed Mode Preambles; 11- 05-0181r0 17.1. Yes WWiSE agrees there is an issue with their proposed preambles and legacy devices 17.2. WWiSE has updated its preamble

Submission page 4 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

17.3. Test Set Up described 17.4. Tx Signal Details described 17.5. Results of new preamble were reviewed for legacy devices 17.6. Conclusions: 17.6.1. 200ns-400ns cyclic shift seems to be the best compromise 17.6.2. Make STS and LTS shifts the same 17.7. Questions: 17.7.1. Delay spreads > 50 ns are also of interest 17.7.2. Were antennas correlated? A – no 18. Chair recessed meeting until 7:30 at 5:48 PM

19. Chair reconvened the meeting at 7:30 PM 20. Sheung Li, vice-chair, proposed the following process for generation of the .19 CA document: 20.1. .11n will likely be the first group to produce a CA document 20.2. To generate the CA will require knowledge of other group activates in order to assess coexistence; this will take member participation 20.3. TGn will charter a sub-group which will use .11n session time as appropriate 20.4. .11n will be asked to also authorize ad hoc conference calls on the CA task 20.5. Discussion: 20.5.1. When would methodology doc be available? A – hopefully about 4 months 20.5.2. When is the first LB draft expected to be available? A – July per the official .11n time line published by Publicity SC 21. Chair lead the discussion of the confirmation voting process/clarification of the down selection procedure, 03-0665r9 step 17 21.1. Step 17 does not explicitly define when the reasons for the ‘no’ vote should be submitted in the case that the confirmation vote does not reach the 75% threshold? 21.2. Suggested procedure: 21.2.1.1. Hold Confirmation vote Thursday March 17 21.2.1.2. Submission of explanation for ‘no’ vote and cure by email by March 25 to TGn officers 21.2.1.3. Officers would compile results and distribute to the TGn reflector by April 1 21.2.1.4. Proposal authors would receive the compilation and post responses by April 29 21.2.1.5. Members would then have 2 weeks to review 21.2.1.6. Next meeting starts May 16 21.3. Discussion: 21.3.1. So, in effect, you have a week to complete your vote? A – effectively yes since the rationale and actual vote are coupled 21.3.2. Merger activities could be impacted by this “artificial deadline”; why April 29 and not May 16? 21.3.3. Post step 17, what happens if the draft does NOT reflect the successful baseline, can the TG edit the draft before issuing as a LB? A – yes; once accepted the baseline doc becomes the property of the TG 21.3.4. Two weeks will be needed for evaluation so April 29 is OK 21.3.5. Assuming the proposal has been changed to reflect the responses to NO votes or a merger occurs then what happens in May meeting? A – a new baseline candidate doc will be put forward and a new confirmation vote held; the process would be repeated 21.3.6. What constitutes a valid NO vote reason? A – not documented; just act professionally as the reasons will be made public 21.3.7. Proposal responders will be very busy; could the count be done at the meeting even though the rationale (i.e., NO votes) has not been submitted? A - vote and explanation are coupled as the vote 21.3.8. Will an unedited result be given? A – no 21.3.9. The faster the results can be disclosed the more time for mergers will be gained

Submission page 5 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

21.3.10. Could results be published when valid votes are in but not compiled; i.e., decouple compilation of ‘no’ vote rationale and distribution? A – yes that is possible 21.3.11. Could we modify the selection procedure to get the vote results faster? A – yes, if that is the will of the group. 21.3.12. There are no additional/changed votes after March 17? A – that is correct 21.3.13. What happens if the voter does not want to give his reasons? A – that is his right 21.3.14. Issue is the delay this coupling process creates 21.3.15. .15.3 does not use this process? A – true 21.3.16. ‘Request’ not ‘demanded’ is the language used in 665r9’ so the count should be released and then the reasons for the ‘NO’ vote collected; i.e., decouple? A – the body should decide 21.3.17. We need a mechanism to record the reasons but we also need time so this should be decoupled 21.4. Motion by Adrian Stephens: “As clarification to 11-03-665r9, on confirmation ballots, A ‘NO’ vote shall not be invalidated for lack of supporting reasons and cures” was seconded by Jim Zyren 21.5. Chair ruled the vote as clarifying 665r9 and hence procedural requiring a majority vote 21.6. Chair asked for objections? There was one by Stuart Kerry so a counting vote was held. 21.7. Voting results were – (93,0,17) 21.8. Discussion: 21.8.1. Since the reasons and votes have now been decoupled why not send the reasons to the officers and the reflector? A – OK 21.8.2. Is April 29 a good date? A – a compromise between time the proposers need and what the body needs to comprehend the changes 21.8.3. Propose changing April 29 to May 6? A – OK body has reached consensus 21.9. Motion to accept the Confirmation Vote Procedure on slide 41 of 11-05-0095 r1 as the procedure to be followed for the confirmation vote per 11-03-0665r9 by Tim Wakeley and seconded by Adrian Stephens passed unanimously. 22. Chair introduced for discussion the TG time line as follows: 22.1. PAR approval Sept 11, 2003 22.2. 1st WG LB July 2005 22.3. 1st SB March 2006 22.4. Final WG/SEC approval Nov 2006 22.5. Revcom approval December 2006 23. As things stand now this is the official time line the Publicity Standing Committee will publish 24. There was no comments from the floor 25. Chair recessed the meeting at 9:00 PM until 1:30 PM tomorrow.

Tuesday March 15, 1:30 – 9:30 PM

1. Chair called the session to order at 1:31 PM 2. The agenda item is to hear the updated TGn Sync and WWiSE proposals 3. Chair updated document list for March in his opening report -11-05-0095r2 4. Eldad Perahia asked that his proposal be removed from the list 5. A coin toss was used to determine who would present their proposal first; WWiSE will go first. 6. Sean Coffey, RealTek Semiconductor presented WWiSE updated Complete proposal, doc. 11-05- 0150r2 a. What’s new b. New membership – Motorola, Nokia, NTT, Ralink, Itri, France Telecom c. Enhanced support for Handheld devices i. Asymmetric antenna support ii. Support for heterogeneous traffic iii. Simple yet robust iv. Range extension for outdoor environments d. Changes since Jan: Submission page 6 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

i. Enhanced single-receiver-antenna modes ii. Enhanced design for backward compatibility iii. New LDPC code design iv. Beacon enhancement e. Some Proposal Summary Highlights: i. Phy: 1. BW (10,20,40) 2. Preamble (mixed, green field) 3. Spatial Streams, # TX antennas 4. Modulation/code rate 5. FEC code (convolutional or LDPC) ii. MAC 1. Aggregation 2. High Throughput PHY (HTP) burst 3. NO-ACK, Block ACK iii. Other 1. Rate recommendation from the receiver 2. Channel State Information from the RX 3. 20/40 coexistence mechanisms 4. N-Beacon, Long SIG f. Bruce Edwards, Broadcom, presented the details of the MAC portion of the proposal i. Built on EDCA, HCCA, and Block ACK from .11e => Backward compatibility ii. Simplicity buys 1. shorter TTM 2. Faster certification g. Sean Coffey returned to discuss Differences with TGn Sync i. Major one is performance with asymmetrical antenna 1. WWiSE – STBC 2. TGn Sync uses Beam Forming ii. Aggregation: Larger packets are more efficient; multiple receive addresses in a frame make sense but this cannot be used with BF since beam is focused on one receiver. iii. Summary: 1. Actually much convergence 2. E.G. - 40 MHz is now optional in both proposals 3. Sean outlined 9 differences which still seem to be issues 4. WWiSE goal was to meet FRCCs, simplicity, TTS (time to standard) 5. Baseline draft candidate exists 7. Jon Rosdahl, Samsung Corp, introduced the updated TGn Sync Complete proposal; doc 11-04- 888r11 a. Overview i. New emerging markets – Communications and Consumer Electronics (not just computer networking) ii. Sync arch is scalable iii. Broad applicability iv. Fastest Path to .11n standard b. Detailed MAC discussion by Adrian Stephens, Intel i. Improved efficiency based on more than just aggregation ii. Modifications in last two months 1. removed TRMS 2. removed header compression 3. Improved TSF Sync 4. Bounded MAX PSDU iii. MAC is scalable Submission page 7 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

iv. Comparison with WWiSE 1. MRMRA (Multi-receiver, Multi-responder Aggregation) is critical for VoIP and not supported by WWiSE 2. Bi-directional data not supported by WWiSE 3. WWiSE cannot aggregate management frames 4. A-MPDU is superior to A-PPDU 5. IAC/RAC can be considered a form of RTS/CTS and facilitates VoIP 6. More efficient (18-55%) than WWiSE v. Conclusion 1. Most effective c. Detailed PHY discussion by Aon Mujtaba, Agere i. Superior performance ii. Complete spec iii. Market driven architecture iv. Modifications since Monterey 1. 40 MHz now optional 2. adopted 56 tones in 20 MHz (52 data + 4 tones) 3. Highest coding rate is now 5/6 4. Streamlined BF (beam forming) v. Some Key Features 1. Q Transformation (maps Spatial Streams to # antennas) 2. Unified Data Path – seamless overlay of BF modes 3. Common receiver architecture 4. MIMO modes: Rx does not need to know that basic BF is being performed at the TX 5. Basic BF vs Advanced BF (extended MCS, bi-directional BF) vi. Differences with WWiSE 1. Q Mapper 2. WWiSE RX must be STBC aware 3. 400 ns GI vs 800 ns 4. Preambles 5. Per spatial stream training 6. 2 pilots inadequate for single antenna RX vii. Summary 1. Complete 2. Superior performance 3. Rapid launch possible yet extensible viii. Jon’s Conclusion 1. Best Rate Range Efficiency Solution 2. Extensible/Future Proof 3. Get to standard sooner 8. Chair recessed the session at 3:30 until 4:00 PM

9. Chair reconvened the session at 4:02 PM and asked proposers to address email questions: 10. TGn Sync addressed the email questions; 11-05-0182r0; Aon Mujtaba addressed PHY questions and Adrian Stephens addressed MAC questions a. Basic BF data? A – see 11-04-894r4; do not have simulation results for 4x2 spatial spreading yet b. Can BF be used with single antenna legacy devices? A – yes; the AP can determine the channel without using sounding packets by using RTS/CTS; a single antenna which does smoothing will not have a problem c. In Table 31 why are MCS 0-6 needed? A – legacy PPDUs do not support advanced features (e.g., aggregation, sounding, coding)

Submission page 8 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

d. Why do we need explicit MCS feedback? A – frankly because we don’t understand all the error mechanisms and explicit MCS feedback provides faster adaptation e. Why not define a handheld capability class? A – probably a good idea but too early at the moment f. Can TX always over ride the RX rate recommendation? A – yes g. Is RX feedback given to the TX immediately? A – not constrained; may need to time stamp the feedback ultimately h. What do range curves look like with 5/6 rate with 1/2GI and 5/6 with full GI? A – beyond scope of CC simulations i. How much memory buffer for aggregation? A – it all depends on memory partitioning and on-chip/off-chip memory as it impacts aggregation packet length j. GI? A – yes, we should have provided a GI bit k. Why not longer GI for out door environments? A- worth considering in the draft phase l. PHY RX sensitivity going to be spec’d? A – it is work in progress m. Mandatory or optional features wrt AP and STA? A – Adrian Stephens presented a spread sheet for the MAC (slides 21-24) n. Advanced coding – since it is modular, should it be selected separately? A – possibly but this was not asked for in the FRCCs o. LDPC codes are untested and complex so why spec them? A – not unknown technology; for a complexity estimate see 11-03-0865 for example. p. Are all LOAs wrt LDPC codes received? A – each company has an independent obligation to supply LoAs to IEEE 11. TGn WWiSE addressed their email questions in doc 11-05-0180r0; Chris Hansen, Broadcom presented a. Why not extend 20 MHz MCS down to BPSK code rate ½? A – to limit complexity b. Range difference at 2.4 and 5.3 GHz between 2x2 Nss=2 6.75 Mbps and STBC Nss=1 6.75 Mbps? A – no time to simulate c. BSS performance? i. .11n Greenfield mode with RTS/CTS protection for 11bg? ii. .11n mixed mode preamble? 1. A – work in progress, will report soon d. Why not spec minimum CCA sensitivity? A – insure interoperability e. Preamble testing on legacy devices; what about Cisco radios? A – see 11-05-0181r0 f. One antenna and STBC, how are 2 pilots adequate? A – see 11-05-161r1; average over two symbols g. LDPC codes are untested and complex so why spec them? A – whatever the body wants h. Need accurate complexity estimates? A – WWiSE has adopted a design based on Layered Belief Propagation which we feel lends itself to low complexity i. Why LDPC codes? A – superior performance j. Are all LOAs wrt LDPC codes received? A – each company has an independent obligation to supply LoAs to IEEE 12. Jeff Gilbert from TGn Sync handled questions submitted by WWiSE just before the break 11-05- 0182r1 a. Is 256 QAM rate 5/6 practical for TX BF? A – use 256 with beamforming when channel permits, also, diversity with more than 4 TX antennas can take advantage; offers extensibility b. Why is top open loop rate higher than the top closed loop rate? A – closed loop just allows to pick the optimal MCS c. Why not use 3 spatial streams instead of ABF if streams are different in quality? A – see slide 43 from 11-04-888r11 d. Why two methods for auto-detect (BPSK axis shift and pilot polarity)? A – one is fast and the other is more robust albeit more complex e. Why such a long HT-SIG field mode? A – one mode meets PER req’ts, reduces complexity and improves interoperability Submission page 9 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

f. Why a Interaction between ABF and LDPC codes TBD? A – still not resolved g. ½ length Cyclic Prefix constraints? A – see 11-05-0222-00-000n; good cost benefit trade- off h. Why so many choices to TX legacy portions of pre-amble? A – flexibility without complexity i. Why no STBCs? A – TX BF is superior to STBC 13. Control returned to Chair 14. Chair asked for questions from the floor a. Sync - 40 MHz channel; VoIP needs channel continuity; how will channel overlap be mitigated? A – 29 independent channels in 5 GHz band b. Sync - Were all legacy cases tested? A – I am sure there are more, we did the best we could c. Sync - Why two methods of auto-detect? A – BPSK robust and simplest, QPSK more robust and slightly more complex; flipping 4 pilots d. WWiSE - Nx1 STBC bidirectional? A – yes e. WWiSE - Delay spread function wrt antennas? A - Total delay spread assumed to be50 ns f. Sync and WWiSE - Status of LOAs; we need a better answer? A – it is a dynamic situation which is not within our control was the answer by both teams g. Sync - The WWiSE proposal contains 5 Mandatory datarate modes, versus 32 Mandatory datarate modes for the TGn Synch proposal (6x the complexity); furthemore, the TGn Synch proposal contains over 500 optional datarate modes; Why is the most complicated spec (TGn Sync) the fastest to a standard? A – because Sync has a well documented spec which will therefore provoke less controversy and can be made normative faster. It was also pointed out that it would not be easy to build a product based on the WWiSE spec either. h. WWiSE - Why only delay Block ACK when that generates jitter? A – because it is most efficient but it is not a requirement i. WWiSE - Which features are mandatory and optional? A – Chris Hansen put up slide 11 from 11-05-0150r1 and verbalized result j. Sync - Short preamble turned out to be very important for .11a; doesn’t overhead of Sync mixed mode preamble defeat advantage of TX BF? A – actually due to aggregation there is still a large advantage k. Sync - How useful is 256 QAM given complexity? A – actually simulations show 256 QAM is very effective even under full impairments. l. Sync - What would range be? A – need to simulate m. WWiSE –STBC vs BF? A - slide 35, 11-05-0150r1; large gain for BF are when conditions are ideal n. Sync, why are there differences in performance of their respective LDPC codes? A – the WWiSE coders gets .1 or .2 dB better but their coder is much more complex 15. Chair recessed the session at 6:01 PM until 7:30 PM

16. Chair reconvened meeting at 7:31 PM 17. Presentation: 11-05-0213; David Tung, Ralink Tech; On the Efficiency of TGn Sync Preambles a. Review legacy preambles b. Impact of longer Sync preamble can be significant for 1536 B packets c. Conclude that TGn needs a Greenfield preamble 18. Rebuttal Presentation by John Sadowsky, Intel; 11-05-0229r0 a. Packets were too short given aggregation b. MAC protection (RTS/CTS) is required for Greenfield preambles; for short packets this would be a prohibitive penalty c. Calculation over simplified and counter productive d. Suggest we rely on the formal CCs for TGn

Submission page 10 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

19. Chair asked that the queue before break be rebuilt by vice-chair 20. The floor was opened for questions: a. Sync - Mandatory versus optional; what about preferred modes? A – on PHY no preferred mode but rather a progression; on MAC side depends on application b. Sync - A-MPDU when combined with BF; how would that work in an AP case? A – BF is on a per station basis c. WWiSE - How would a RX detect the different signal fields? A – use a correlator which is already in the RX d. Sync - EDCA coordination fnc were used in the CC simulations; is HCCA really best? A – HCCA is rarely implemented in .11e solutions today except for application specific solutions. e. Sync - Video application requirements are essentially 3 x 19.6 streams per house; preambles will make a difference? A – Sync does have the most efficient MAC for large pay loads f. ? - FRCCs use constant EIRP and use back-off as more antennas are added; this reduces power efficiency? A – don’t really have a choice. g. Sync - Are the authors of 11-05-0229 aware that the formula used in 213 paper was from a text book and not arbitrary? A – no but it was still used inappropriately. h. Sync - In WWiSE only 5 mandatory date rates whereas Sync have 32 mandatory rates; how can that additional complexity result in a faster standard? A – because it is well documented. i. Sync - did not use STBCs because BF is more efficient; what about multiple receivers? A – in that case the packets would be short and so BF would not be applicable. j. WWiSE - how does your proposal handle channels with a large delay spread such as 500ns as would be found in a hot spot? A – have not run the simulations k. Sync - Data rate and preamble crossover for Sync occurs at 3700B; aren’t there going to be useful applications having shorter packet sizes than 3700B? A – of course l. WWiSE - Channel estimator (time domain estimation); the WWiSE proposal has hidden complexity what impulse response did you assume in the channel estimator? A – cannot recall m. Sync - Was rate feedback frame included in simulations? A – no n. WWiSE - Home Video Gateway to multiple HD TVs; same program to multiple TVs in the house; how? A – aggregate and send to TVs in round robin fashion; multicast mechanism may work but it would introduce complexity; range may play a roll; WWiSE can send same aggregate to multiple stations whereas Sync would use spatial spreading o. What happens if a 40 MHz channel can’t sustain the channel, how quickly can the TX switch to 20 MHz? A - ? p. WWISE - does delayed block ACK impact buffering requirements? A – A–PPDU device can aggregate by station and accommodate buffer issues accordingly q. Sync - which MAC features are mandatory and optional? A – see simulation methodology doc; bi-directional data, RX assisted link adaptation, MRMRA, aggregation are the alternatives r. Sync - what happens to ABF efficiency if there is an error in the channel estimation; are 100 estimations enough? A – yes s. Sync - Other channel estimates? A – throughput is better measure than PER t. WWiSE - what is n-Beacon? A – new beacon with optional STBC u. WWiSE - So how will that work with a broadcast beacon? A – will clarify tomorrow v. Sync - what limitations does implicit channel feedback impose? A – calibration is defined in spec; some mismatch w. WWiSE - are pure Greenfield preambles really practical? What about neighboring BSS that is not Greenfield; how does one autodetect legacy in mixed mode? A – multiple decodes 21. Chair recessed at 9:33 PM until 8:00 AM tomorrow morning.

Submission page 11 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Wednesday March 16, 2005 8-10 AM

1. Chair reconvened the meeting at 8:01 AM 2. Chair reviewed agenda for the day 3. 5 Presentations are scheduled 4. Question queue from last night was rebuilt by vice-chair 5. WWiSE; in spec 9.13.1 How does this OFDM Protection (spoofing) work? A – ours is similar to TGn Sync 6. WWiSE; in preamble of 40 MHz mixed mode; what is SS40GF in Fig 12, 14, 16 used for since there is not a comparable field in the 20 MHz mixed mode? A – SS40GF is defined on page 51 and it is to train the AGC to access the tones in the middle between the two 20 MHz bands 7. Presentation by John Ketchum; 11-05-0183r1; Preamble requirements of Beamforming (Continuation and Elaboration of Presentation on Smoothing of Steered MIMO channel estimates 11-05-1635r1) a. Mathematical Issues related to Channel Estimation which is essential for good BF and Spatial Multiplexing b. If Eigen vectors are close then smoothing (interpolation) can result in large errors c. For S/N <20 dB there does not seem to be a problem d. Concludes – TGn should not mandate smoothing 8. Presentation by John Ketchum; 11-05-0255r0; Response to WWiSE Presentation (slide 40,41 of 11-05-0150r2) on Beam Forming a. Tx BF actually simplifies receiver design; the RX does not need to be BF aware b. WWiSE comments are completely without merit 9. Return to Questions: a. Sync re: A–MSDU; What is throughput and MAC efficiency without this feature? A – can achieve 100 Mbps without A-MSDU. b. Sync; Since A–MSDU is optional (pg 29 line 24 thru 27, 11-05-0149); how will the network know when to use this feature; what is the mechanism? A – TBD c. WWiSE; When will your BF details be made available to the body? A – we have offered a frame format to facilitate channel feedback and will be offering more details on our BF techniques shortly d. Sync; 2 or 4 Pilot tones; what was the rationale for choosing 4 pilots? A – performance but it is true that the interleaver must be optimized. e. Sync; Is 256 QAM practical? A – very practical in good channels f. WWiSE; Considering Carrier Phase noise sensitivity; why would you want 2 pilots? A – extra data in other tones justifies the choice g. WWiSE; slides 38, 39 from 11-05-0150r2, Power Discontinuity, what is the issue the legacy stations would have? A – potential large power discontinuity cannot be handled by some legacy devices. h. Comment - Wi-Fi does test RF performance in this case i. WWiSE; for a RX in a WWiSE network how do the stations know whether to use a double SIG field or not? A – do a correlation and, also, there is a bit in the beacon for the extended mode. j. WWiSE; what support for VoIP; issues and your solutions? A – market requirements; latency issues; short preambles, flexible MAC k. WWiSE; duplicate beacon – is there a new RTS/CTS required for legacy and .11n capable STAs some of which support STBC? A – no new protection mechanisms; poll stations to make silent in extended range modes; this may be problematic for overlapping BSSs l. WWiSE; A-PPDU; 4k and 8k MSDUs are inconsistent with .11e MSDU limit? A – take off-line m. WWiSE; where are the address fields for the sub-frames; would you use Sync fields? A – yes

Submission page 12 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

n. Sync; calibration – when will the spec be more quantitative on channel estimation? A – sounding packets are transmitted within SIFS; action item – see 6.2.3.2 for details o. WWiSE; slide 22 of 11-05-0150r2 is the configuration single TX and 40 MHz, mandatory? A – no, all optional and all at 40 MHz p. Sync; re interleaver design with 52 tones in Jan but now 56 tones; has interleaver been redesigned? A - it is true the tones have changed and the interleaver has been redesigned and reflected in our latest spec q. Sync; substantial power drop in switch from omni-directional to BF is possible; for OFDM there is no CRC in header so is there a test that you have run to verify that when the switch occurs the packet will not be rejected by a legacy device? A – legacy should have decoded the SIG field and backed off but it is true we may have to test 10. Chair recessed the meeting at 9:58 until 1:30 PM

Wednesday March 16, 2005 1:30 – 6:00 PM

11. Chair reconvened the meeting at 1:31 PM 12. Two papers remain – Richard Williams and Anuj Batra 13. Two new presentation requests – 1) Switch to Beam Forming Power Step and 2) Issues with an N-Beacon 14. Chair recommended: a. Old Papers b. Old Q&A queue c. New Papers 15. Group, through a straw poll, wanted to hear papers and, time permitting, return to Q&A 16. Presentation 11-05-0214r0; WWiSE LDPC Performance; Dale Hocevar, TI a. Most of the benefit from the WWiSE LDPC codes can be achieved after 15 iterations b. Standard Belief Propagation versus Layered Belief Propagation Comparison 17. Presentation 11-05- 0211; Beamforming Should be Smooth; Richard Williams, TI a. Premises: i. To allow arbitrary beamforming to be received without prior knowledge the receiver must use a certain class of techniques for stream separation ii. A general receiver structure doesn’t allow all types of beamforming but can approach optimal performance without channel knowledge b. A general receiver can outperform a constrained receiver by 5dB c. A general receiver restricts beamforming techniques to those that produce a smooth transmitted signal d. Preambles can be shortened with a Smooth BF Techniques e. The throughput burden of additional 12.8 us of preamble was quantified f. Conclusion i. Unrestricted Beamforming is not a good idea ii. The increased preamble size required by TGn Sync requires huge data payloads to compensate for its inefficiency iii. The WWiSE approach of minimizing preambles by requiring smooth beamforming techniques is the right technical solution 18. Presentation, Mark Webster, Conexant, 11-05-0265 r0; Switch to Beamform Power Step a. LOS scenario b. NLOS scenario c. Conclusion: This submission has illustrated that more than a 10 dB power jump can occur in switch-to-beamform packets in some cases i. Unlike 802.11b, OFDM does not have a CRC check on the Signal Field (header) 19. Presentation, 11-05-0270r0; Sanjiv Nanda, Qualcomm; Issues with an N-Beacon a. Optional STBC beacon – increases range for STBC stations, but cannot be understood by devices not implementing this option

Submission page 13 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

b. Need MAC protection for stations that do not understand STBC packets; this adds overhead c. Conclusion: d. MAC level support required for optional feature: SIG-N, STBC e. This is a particularly critical issue since the only single stream modes that the WWiSE proposal supports are using STBC 20. Return to Q&A from the floor: a. Sync; Block ACK, 7.3.1.14 of .11e; A-MDSU would require a footnote update? A - ? b. Sync (Ketchum, Qualcomm and Jeff Gilbert, Atheros) presented 11-05-0269r0; Updated Answers to some WWiSE Questions i. ABF and LDPC Interaction TBD - is an editorial oversight ii. Interleaver impact because of using 52 tones and 4 pilots? – Interleaver was redesigned and has performance equal to the WWiSE interleaver iii. Calibration accuracy (on the part of the RX) of transmit beamforming and BF exchange – no additional accuracy req’t c. Sync; slide 16 of 11-05-183r1; for channel E delay can exceed window size, have you looked at longer window size? A – no d. WWiSE; STBC with Multi-cast; consider the following scenario - 4 TVs watching same channel; how is this accomplished? A – higher level multicast protocols e. Sync; Should all BF functions be mandatory? A – since there are not very many functions it should not be problematic f. Comment - Duplication of SIG field; need add a description to spec for STBC device working in a non-STBC environment g. WWiSE; do you have any further results related to BF ? A – not yet h. WWiSE; N-Beacon and duplicate SIGs; when will merger with MITMOT be complete? A – it is; we cannot be experts at everything i. Sync; how do you handle overlapping BSS? A – simulation and hardware show good receiver design mitigates the situation. j. Sync; What about BF calibration? A – true, calibration could fail and so recalibration will be required but that is a simple background task k. WWiSE and authors of 11-05-0214 r0; good that the LDPC has been changed to be closer to TGn Sync but still in error? A – could still be an error l. WWiSE re HT diversity 11-05-0016r2; what is PHY config? A – see the spec for TX power and number of TX antennas m. WWiSE; What is Richard proposing? A – Richard said WWiSE not sure that the combination of short preamble and Beamforming is viable and therefore reluctant to make a proposal in detail on BF at this time n. Sync; slide 30 of 11-04-0888r11 re EDCA and HCCA; why not just use HCCA since it is consistently better than EDCA? A – sort of agree but EDCA is our baseline and so we need to do both o. WWiSE; re PHY; how does the RX distinguish the preambles (Greenfield and mixed mode) a for single vs dual antenna cases? A – yes there is some latency but that was taken into consideration in defining the preambles. p. WWiSE; slide 34 of 11-05-0150r1 says WWiSE supports BF; slide 40 states Sync BF requires calibration; does WWiSE require calibration? A - Implicit feedback would result in the same performance as Sync; explicit feedback has not been defined yet. q. WWiSE comment - 11-05-0271r1; N-Beacon Clarification has been uploaded. r. WWiSE; why did they focus on optimizing the LDPC code when it resulted in fractions of a dB ( inches to feet); A – reduced complexity 21. Chair recessed until 4:00 PM at 3:29 PM

22. Chair reconvened the session at 4:03PM 23. Chair noted that the down selection vote would be held in this time slot

Submission page 14 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

24. By means of a coin toss the WWiSE team, Sean Coffey, presented a 5 minute summary first, 11- 05-0273r0 a. Keep complexity low b. Leverage AP to the benefit of the STA (asymmetric antenna configurations) c. Need STBC AND Beamforming d. WWiSE MAC much less complex e. Next steps – much work no matter what 25. TGn Sync team lead by Jon Rosdahl presented a 5 minute summary; 11-05-0266r0 a. Broadest support b. Well documented/fastest path – WWiSE proposal is incomplete and, like TGe will result in a protracted Letter Ballot process c. Best Performance d. Most Extensibility e. Backward compatibility 26. Chair reviewed next steps: a. Reviewed the ballot itself b. Noted - Only one mark per ballot 27. TGn will reconvene at 8:00 AM tomorrow morning with the joint meeting with .19 28. The down selection ballot results will be given at this time 29. The joint meeting will be followed by the confirmation vote 30. NO confirmation votes are expected to provide a reason and remedy by email by march 25 31. Jon Rosdahl moved that TGn proceed with down selection step 16; the motion was seconded by Dave Bagby and passed without objection 32. The down selection vote was completed at 5:53 PM 33. A representative of WWiSE, Jim Zyren, and TGn Sync, Jon Rosdahl witnessed Stuart Kerry destroy the sheets mapping vote numbers to voting members names. Stuart said he mapping was used to make sure votes were not misplaced/lost/destroyed/duplicated. 34. Chair recessed the meeting at 5:58 PM until tomorrow morning at 8:00 AM without objection.

Thursday March 17, 2005 8:00 – 12:00 noon

1. Chair called the meeting to order at 8:00 AM 2. Stuart Kerry, Chair of WG, announced the results of the down selection vote as a. Returned votes 100% of 331 ballots issued b. WWiSE 153 (46.2%) c. TGn Sync 178 (53.8%) d. Chair turned the podium over to Steve Shellhammer, Chair .19 to lead the group in a discussion of Compatibility entitled “What is a CA Document”; 19-05-06r0. e. Steve referenced the 802 Policy & Procedures document on main 802 web site f. Changes to 802 P&P to incorporate Coexistence were: i. Added a procedure to PAR called “Coexistence of 802 wireless standards specifying devices for unlicensed operation” ii. Added Procedure #22 in 5C for Coexistence Assurance document iii. Steve clarified the related paragraphs 1. For example, the CA document is purely internal to 802.11 and does not get published with the final standard 2. No threshold of acceptability, it depends on the application 3. Shall – Currently approved relevant standards 4. Should – other wireless systems, draft standards 5. Purpose – provide letter ballot pool with additional information 6. CA Model components iv. Goal for producing a CA methodology document 1st draft – July 2005 g. Questions for Steve? none 3. .11 chair returned to the discussion of the confirmation voting process Submission page 15 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

4. Noted that if a member issues a NO confirmation vote the member is expected to give the reason in an email and a cure that would result in the member changing the NO vote to a YES vote by March 25 5. Confirmation voting process discussion – verbal roll call vote? 6. Discussion: a. Chair confirmed - Providing a reason and cure is NOT required as part of a vote b. Floor asked that the reason/cure is purely “voluntary” be added to the procedure slide, slide 66, to chairs 11-05-095 r5 document. c. Paper ballot is preferred by members whose first language is not English d. Step 17 calls for a roll call vote e. Use 11:59 instead of mid-night on process slide f. Change to ‘Paper’ roll call vote g. Verify “return of ballot” only to speed up process h. “Printed” Name must go on the paper roll call ballot 7. Straw Poll held: a. Paper Ballot Confirmation Vote process - 108 b. Verbal Ballot Confirmation Vote Process – 32 8. Motion to recess for 5 min by Steve Shellhammer and seconded by Al Petrick to allow the Chair to edit the roll call voting procedure slide #66 passed unanimously 9. Chair reconvened the meeting at 9:08 AM 10. Chair noted that the confirmation vote requires a 75% majority 11. March 25 for submission of reason for no vote and cure IFF the 75% threshold is not achieved 12. David Bagby made a motion to hold a “paper” ballot roll call vote and was seconded by Aon Mujtaba. 13. Discussion: a. Does this vote include the name issue? A – No only paper vs verbal 14. Motion passed (215,3,4) 15. Chair noted that PRINTED name must be on the ballot and that only the “returned” ballot will be recorded 16. Motion by Jon Rosdahl and seconded by Clint Chapman that we proceed with the roll call vote passed unanimously. 17. Discussion: a. Jon Rosdahl reviewed the reasons for why the group needs to confirm the baseline and provide the reasons as soon as possible – start working on compromise/proposal enhancements b. Floor remarked that it would be bad to pass this confirmation now so that merging and compromise between TGn Sync and WWiSE is encouraged c. Question was called without objection 18. The confirmation vote was held starting at 9:22 AM 19. The confirmation vote was closed at 10:56 AM 20. Chair lead process of electing a technical editor a. Chair called for additional nominations and none were offered b. Sean Coffey made his candidacy speech (doc 11-05-0288r0) i. Noted that the tech editor job is too demanding for a single person and would recommend adoption of an editorial team ii. Noted Clear ‘chain of evidence’ is important c. Adrian Stephens made his candidacy speech (doc 11-05-0287r0) i. Noted that the tech editor job is too demanding for a single person and would recommend adoption of an editorial panel d. Questions from the floor? i. How would you structure an editing team in the TGn? ii. Adrian – about 5 folks – 2 MAC, 2 PHY, 1 process iii. Sean – need F2F meetings during session; enlist experts in particular areas from time to time Submission page 16 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

e. What about a joint editorialship? f. Move to postpone election until the May 2005 session by Dave Bagby and seconded by Jim Zyren g. Discussion: i. Wait on this motion until the results of the confirmation vote is known 21. Stuart Kerry announced the results of the confirmation vote as: i. TGn Sync confirm – 181 (56.4%) [later changed to 182 (56.5%)] see roll call vote results below ii. TGn Sync Not Confirm – 140 (43.6%) 22. Discussion continued: i. In favor since such a move would encourage compromise ii. Not in favor, need an identified leader iii. Move to call the question by Dave Bagby seconded by Chris Hansen passed without objection 1. Discussion: a. Clarification - Postpone means that the process would be picked up where we left off here in the interest of expediency (i.e., no further nominations will be considered) b. The motion passed (115, 60,6) as the motion is procedural 23. Chair returned the discussion to the selection procedure a. Slide 71 of 11-05-0095r5 24. Plans between now and the May session a. Review updated TGn Sync proposal b. Consider Reasons and cures submitted c. Hold confirmation vote #2 d. Submit Responses to ‘Reasons and Cures’ by May 6 e. Email questions will be allowed f. Update proposals g. Q&A h. Confirmation Vote i. Technical Editor vote j. If still don’t reach 75% then we reset to step 16 k. CA document discussion l. Plans for July 25. Discussion: a. Reasons and Cure discussion 6 hours rather than 4 (discuss reasons, remedies, updated proposal) b. Q&A – 4 hours about right c. New technical information d. Confirmation vote #2 e. Hold Technical Editor election 26. Chair introduced discussion of time-line a. No discussion or comments 27. Motion by Jon Rosdahl and seconded by Tim Towell to adjourn session until May passed unanimously 28. Chair adjourned the session at 11:47 AM

The results of the first TGn roll call vote were:

March 2005 First Confirmation Roll Call Vote Last Name First Name Middle TGn None Initial Ballot Sync of returned above

Submission page 17 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Zyren James 1 1 Zuniga Juan-Carlos 1 1 Zhu Jeffrey C. Zhu Chunhui 1 1 Zhang Jinyun 1 1 Zeira Eldad 1 1 Zaks Artur 1 1 Yurtkuran Erol K Yung Hon M 1 1 Yu Heejung 1 1 Young Chris 1 1 Yin Jijun Yee Jung Yee James 1 1 Ye Huanchun 1 1 Yasuhiro Tanaka Yaqub Raziq 1 1 Yang Lily Yamaura Tomoya 1 1 Yamamoto Takeshi Yamada Katsuhiko Yagi Akiyoshi Xia Bo 1 1 Xhafa Ariton 1 1 Wu Gang Wright Charles R Worstell Harry R 1 1 Woodyatt James 1 1 Wong Timothy G 1 1 Wong Jin Kue Wojtiuk Jeffrey J Winters Jack H 1 1 Wilson James M 1 1 Williams Richard 1 1 Williams Michael Glenn Wilhoyte Michael E Whitesell Stephen R 1 1 Weytjens Filip 1 1 Wentink Menzo M 1 1 Wendt Jim Wells Bryan Webster Mark A 1 1 Wax Mati A 1 1 Watanabe Fujio 1 1 Submission page 18 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Warren Craig D Ware Christopher G 1 1 Ward Robert Wang Stanley Wang Huaiyuan 1 1 Wandile Vivek 1 1 Walrant Thierry Walker Jesse R Wakeley Tim 1 1 Vogtli Nanci 1 1 Vlantis George A 1 1 Visscher Bert 1 1 Victor Dalton T 1 1 Varsanofiev Dmitri Varas Fabian 1 1 Vandenameele Patrick van Zelst Allert 1 1 van Waes Nico J 1 1 Van Poucke Bart 1 1 Van Nee Richard D.J. 1 1 van Leeuwen Richard 1 1 Van Erven Niels Valle Stefano 1 1 Uchida Yusuke 1 1 Tzannes Marcos Tzamaloukas Mike E Turner Sandra L Tung David 1 1 Tsoulogiannis Tom Tsien Chih C 1 1 Tseng Rodger 1 1 Tsao Jean Trerotola Ron Trainin Solomon B. 1 1 Trachewsky Jason 1 1 Towell Timothy 1 1 Tomcik James D. 1 1 Tolpin Alexander 1 1 Tokubo Eric T 1 1 Ting Pangan 1 1 Thrasher Jerry Thornton Timothy J ten Brink Stephan 1 1 Temme Carl Submission page 19 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Taylor James 1 1 Tao Jeffrey 1 1 Tang Kevin 1 1 Tanaka Yasuhiro 1 1 Tanaka Hideki 1 1 Tan Teik-Kheong 1 1 Tan Pek-Yew 1 1 Tamaki Tsuyoshi Tal Nir Takeda Daisuke 1 1 Takaoka Katsumi Takai Mineo Takahashi Seiichiro 1 1 Takagi Masahiro 1 1 TAGIRI HIROKAZU 1 1 Surineni Shravan K 1 1 Sun Sumei 1 1 Sun Feng-Wen 1 1 Sugawara Tsutomu 1 1 Strutt Guenael T 1 1 Stolpman Victor J 1 1 Stevenson Carl R. Stevens William M Stephens Adrian P 1 1 Steck William K Staszak Martin J 1 1 Stanley Dorothy 1 1 Stacey Robert Srinivasan Ranga 1 1 Spiess Gary N Spalla Filippo 1 1 Soranno Robert T 1 1 Soomro Amjad Sood Kapil 1 1 So Tricci 1 1 Smith Matt 1 1 Skidmore Roger R Skafidas Efstratios (Stan) Siti Massimiliano 1 1 Singh Manoneet Simpson Floyd 1 1 Siep Thomas M 1 1 Shyy D. J. 1 1 Shvodian William M 1 1 Submission page 20 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Shirakata Naganori Shimada Shusaku Sheu Ming Sherman Matthew J Sherlock Ian 1 1 Shen Yangmin Shellhammer Stephen J 1 1 Seth Vikram Sensendorf Joe Seals Michael Schylander Erik 1 1 Schreder Brian Schnier Steven D Schnacke Richard N Schiffer Jeffrey L 1 1 Schaffnit Tom scalise fabio M Saxena Monica 1 1 Sawamura Mariko Sastry Ambatipudi R 1 1 Sashihara Toshiyuki Sarrigeorgidis Konstantinos 1 1 Sarca Octavian V 1 1 Sanwalka Anil Sandhu Sumeet 1 1 Sampath Hemanth Salhotra Atul Sakurai Shoji Sakoda Kazuyuki 1 1 Saifullah Yousuf 1 1 Saed Aryan Sadowsky John S Sadot Emek 1 1 Sadeghi Bahareh 1 1 Rudolf Marian X 1 1 Rude Michael Rosdahl Jon W 1 1 Rosca Justinian 1 1 Rommer Stefan Rollet Romain Roebuck Randy 1 1 Robar Terry M 1 1 Rios Carlos A Riess Eilon 1 1 Submission page 21 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Riegel Maximilian Ribner David Ribeiro Dias Alexandre Reuss Edward Repice Joe A 1 1 Reible Stanley A 1 1 Reede Ivan Rayment Stephen G Rasor Gregg 1 1 Rappaport Ted Rangwala Noman Ramesh Sridhar 1 1 Rajkumar Ajay Raissinia Ali 1 1 Raab Jim E Quinn Liam B. Qian Luke 1 1 Qi Emily H 1 1 Purkovic Aleksandar 1 1 Ptasinski Henry 1 1 Potter Al Portaro James D 1 1 Pope Stephen P Pitarresi Joe 1 1 Pirzada Fahd 1 1 Petrick Al 1 1 Petranovich James E 1 1 Perahia Eldad 1 1 Peleg Yaron Patel Vijay 1 1 Parker Steve 1 1 Park Jong Ae 1 1 Panish Paul W Palm Stephen Paljug Michael J Paine Richard H Pai Pratima M Ozer Sebnem Z Oyama Satoshi Ota Atsushi Ophir Lior Oostveen Job 1 1 Oomen Peter Ono Hiroshi Submission page 22 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

O'Nan Jon 1 1 Olson Timothy S 1 1 Olson Chandra S 1 1 Ojard Eric J 1 1 Ohtani Yoshihiro O'Hara Sean T O'Hara Bob 1 1 Oguma Hiroshi 1 1 Odman Knut T Oakes Ivan F Noens Richard H 1 1 Noble Erwin Niu Huaning 1 1 Nitsche Gunnar 1 1 Ni Qiang Ngo Chiu 1 1 Newton Paul D 1 1 Nedic Slobodan 1 1 Narasimhan Ravi Narasimhan Partha Nanda Sanjiv 1 1 Nakase Hiroyuki 1 1 Nakao Seigo 1 1 Nakamura Michiharu 1 1 Naka Katsuyoshi Nagai Yukimasa 1 1 Myles Andrew 1 1 Myers Andrew D Murray Peter Murphy Peter A Mujtaba Syed Aon 1 1 Mueller Joe Muck Markus D 1 1 Mourot patrick Morley Steven A. 1 1 Morioka Yuichi 1 1 Moreton Mike 1 1 Moorti Rajendra T Moore Tim M Moore Rondal J Montemurro Michael 1 1 Monteban Leo Molnar Peter R Molisch Andreas F 1 1 Submission page 23 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Mlinarsky Fanny Miyoshi Kenichi Mittelsteadt Cimarron 1 1 Miller Robert R. 1 1 Miki Morgan H 1 1 Meylan Arnaud 1 1 Meyer Klaus Mehta Pratik 1 1 Medvedev Irina 1 1 McNew Justin P McNamara Darren P 1 1 McIntosh Bill J McGovern Timothy McFarland William J 1 1 McClellan Kelly P 1 1 McCann Stephen Maufer Thomas A Matta Sudheer Matsuo Ryoko 1 1 Matsumoto Yoichi Mathews Brian Martin Art 1 1 Marshall Bill 1 1 Mankin kevin Mani Mahalingam Malinen Jouni K Malik Rahul Malek Majid m 1 1 Makishima Doug K 1 1 Mahadevappa Ravishankar H Love Robert D Lou Hui-Ling 1 1 Lojko Peter M 1 1 Loc Peter 1 1 Liu Xiaoyu Liu I-Ru Liu Ed W 1 1 Liu Der-Zheng 1 1 Liu Changwen 1 1 Liu Albert 1 1 Lin Victor 1 1 Lin Huashih A 1 1 Lim Yong Je Lim Wei Lih 1 1 Submission page 24 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Liang Jie Liang Haixiang 1 1 Li Yuan 1 1 Li Sheung 1 1 Li Pen 1 1 Li Jia-Ru 1 1 Leyonhjelm Scott Levy Joseph 1 1 Lemberger Uriel 1 1 Lefkowitz Martin 1 1 Lee Tae-Jin Lee Taejin Lee Sok-kyu 1 1 Lee Myung J 1 1 Lee Dongjun 1 1 Leach David J. Lauer Joseph P Lanzl Colin Landt Jeremy A 1 1 Landeta David S 1 1 Lambert Paul 1 1 Kwon Edwin Kwak Joe 1 1 Kvarnstrom Bo 1 1 Kuwahara Denis Kurihara Thomas M Kuo Ted 1 1 Kunihiro Takushi 1 1 Kumar Rajneesh 1 1 Kumagai Tomoaki Kuehnel Thomas 1 1 Kruys Jan P 1 1 Kraemer Bruce P Kowalski John M Kopikare Milind Koomullil George P Kondylis George 1 1 Kolze Thomas 1 1 Kojukhov Andrei Kojima Yasuyoshi Koga Keiichiro 1 1 Kobayashi Mark M 1 1 Kobayashi Kiyotaka 1 1 Kneckt Jarkko 1 1 Submission page 25 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Kleindl Guenter Klein John R 1 1 Kimhi Ziv Kim Youngsoo 1 1 Kim Yongsuk 1 1 Kim Taekon Kim Joonsuk 1 1 Kim Byoung-Jo J Kikuma Tomohiro Kido Ryoji Khieu Andrew K Ketchum John W. 1 1 Kerry Stuart J 1 1 Kennedy Richard Kelly Patrick Kavner Douglas 1 1 Kato Masato 1 1 Kasher Assaf Y 1 1 Karnik Pankaj R Karimullah Khalid Karcz Kevin J Karaoguz Jeyhan 1 1 Kang You Sung Kandala Srinivas Kakani Naveen K 1 1 Kain Carl W Jou Tyan-Shu 1 1 Jose Bobby Jones VK 1 1 Jokela Jari E 1 1 Johnson Walter Jiang Daniel Jian Yung-Yih 1 1 Jetcheva Jorjeta G Jeon Taehyun 1 1 Jeon Ho-In J Jechoux Bruno Jang KyungHun 1 1 Jalfon Marc 1 1 Jacobsen Eric A 1 1 Jackson Stephen S ITO Takumi 1 1 Ishidoshiro Takashi Ishida Kazuhito 1 1 Submission page 26 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Inoue Yasuhiko 1 1 Imamura Daichi Ikram Muhammad Z 1 1 Hunter David Hsu Yungping A 1 1 Howley Frank P. Horng Henry 1 1 Horne William D Honary Hooman 1 1 Holt Keith 1 1 Hollister Allen Hoghooghi Michael M Ho Chin Keong Hinsz Christopher S 1 1 Hillman Garth D Hiertz Guido R. 1 1 Hideaki Odagiri 1 1 Heubaum Karl F 1 1 Hetherington Dave Hermodsson Frans M 1 1 Hepworth Eleanor Heile Robert F Hedberg David J 1 1 He Xiaoning He Haixiang 1 1 Hayes Kevin N. Hayakawa Yutaka Hauser James P. 1 1 Hasty Vann 1 1 Hassan Amer A Haslestad Thomas 1 1 Harriman Adam Harkins Daniel N Harford James J Harada Yasuo Hansen Christopher J 1 1 Hanaoka Seishi 1 1 Hamady Neil N Hall, P.E. Robert J Halford Steve D Halasz David E Haisch Fred 1 1 Habetha Joerg K Gupta Vivek G 1 1 Submission page 27 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Gummamdi Srikanth 1 1 Gu Daqing Green Larry Gray Paul K 1 1 Gray Gordon P Goubert Gerard Gohda Wataru 1 1 Goettemoeller Mike 1 1 Goel Sandesh 1 1 Godfrey Tim 1 1 Gilbert Jeffrey M 1 1 Gilb James P K 1 1 Ghosh Monisha Ghazi Vafa Gerson Eran Garrett Albert L 1 1 Gardner James 1 1 Fukagawa Takashi 1 1 fremont benoit 1 1 Frederiks Guido 1 1 Formoso Ruben R Ford Brian 1 1 Foegelle Michael D. Flygare Helena 1 1 Fisher Wayne K Fischer Matthew J Filauro Valerio Feldman Alex Feinberg Paul H. 1 1 Faulkner Michael 1 1 Falk Lars P 1 1 Fakatselis John C. 1 1 Faccin Stefano M 1 1 Euscher Christoph 1 1 Estrada Andrew X 1 1 Eroz Mustafa 1 1 Eriksson Patrik Engwer Darwin 1 1 Emeott Stephen P 1 1 Ellis Jason 1 1 Egan John V 1 1 Edwards Bruce 1 1 Edney Jonathan P 1 1 Ecclesine Peter 1 1 Submission page 28 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Eaton Dennis Eastlake Donald E. 1 1 Dycian Yaron Dure Sebastien 1 1 Durand Roger P Durand Chris 1 1 Dundar Baris B Douglas Brett L. Doi Yoshiharu 1 1 Dick Kevin 1 1 Demel Sabine Del Prado Pavon Javier De Vegt Rolf J 1 1 de Courville Marc 1 1 Crowley Steven 1 1 Cramer Mary E 1 1 Cook Kenneth Cook Charles I 1 1 Connors Dennis Conner W. Steven 1 1 Conkling Craig Cole Terry L Coffey John T. 1 1 Cnudde Peter Ciotti Frank Chung Simon Chung Byungho Chuang Dong-Ming 1 1 Chu Liwen 1 1 Choi Yang-Seok Choi Won-Joon 1 1 Choi Sunghyun Choi Eunyoung Chindapol Aik Chhabra Jasmeet Chesson Greg L Cheng Hong 1 1 Cheng Alexander L 1 1 Chen Yi-Ming 1 1 Chen Ye Chen Shiuh 1 1 Chen Michael 1 1 Chen Jeng-Hong 1 1 Chen James Submission page 29 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Chari Amalavoyal Chaplin Clint F 1 1 Chang Ron Chang Kisoo Cash Broady B Carson Pat Carney Bill 1 1 Cam-Winget Nancy 1 1 Calhoun Pat R 1 1 Buttar Alistair G Brunel Lo?c Bray Jennifer A Brasier William M Bowles Mark V 1 1 Bonneville Herve Boer Jan 1 1 Blue Scott Black Simon 1 1 Bjerke Bjorn A 1 1 Bilstad Arnold Bhandaru Nehru 1 1 Bersani Florent Berry Don Benveniste Mathilde Benko John L 1 1 Baysal Burak H 1 1 Bartel Charles R. 1 1 Barry Kevin M. Barr John R. 1 1 Barnwell Richard N Barel Avi Barber Simon Balachander Ramanathan 1 1 Baker Dennis J 1 1 Bahr Michael Bagby David 1 1 Awater Geert A Audeh Malik Aubin Raymond Astrin Arthur W. 1 1 Asai Yusuke 1 1 Arnett Larry 1 1 Armstrong Lee R 1 1 Ariyavisitakul Sirikiat Lek Submission page 30 Garth Hillman, Advanced Micro Devices

March 2005 doc.:IEEE 802.11-05/0162r0

Aramaki Takashi 1 1 Aramaki Mitch 1 1 Aoki Tsuguhide 1 1 Aoki Hidenori Andrus David C 1 1 Andren Carl F. 1 1 Andrade Merwyn B Andelman Dov 1 1 Ananthaswamy Ganesh Amer Khaled Amann Keith Allen Richard C Alimian Areg Alexander Thomas Aldana Carlos H 1 1 Agre Jonathan R Adams Jon 1 1 Adachi Tomoko 1 1 Abraham Santosh P 1 1 Aboul-Magd Osama S 1 1 Aboba Bernard D

TGnSync None Ballot of Column returned above E+F

322 182 140 322 56.5% 43.5% 100.0%

Submission page 31 Garth Hillman, Advanced Micro Devices

March 2005 doc.: IEEE 802.11-05/0320r0

IEEE P802.11 Wireless LANs

March 2005 TGp/WAVE Minutes

Date: 16 – March -2005

Author(s): Name Company Address Phone email 8600 Jefferson Street NE Filip Weytjens TransCore +1 (505) 856-8145 [email protected] 87113, Albuquerque, NM

Abstract Minutes of the meeting of the IEEE 802.11 WAVE Task Group held in Atlanta, CA, from March 14th to 18th, 2005, under the TG Chairmanship of Lee Armstrong of Armstrong Consulting. Minutes were taken by Filip Weytjens.

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

March 2005 doc.: IEEE 802.11-05/0320r0

Monday, March 14, 2005, 4:00 PM Session

The meeting was convened at 4:00 PM.

The policies and rules were presented to the working group.

The main objective of the meetings is to make the document ready for the May meeting.

Lee went over the agenda including the action item list that was prepared during the Monterey meeting.

It was requested whether there was an action to change the RSSI name for WAVE. This was changed to WRSS mode.

ACTION 1: Provide input to the draft standard to include a cancel primitive. (Brian Wells, Justin McNew) - Jan 28 DONE

ACTION 2: Provide a more detailed description on the use of RSSI for WAVE and differentiate it from existing use of RSSI within the 802.11 contexts. (Jeffrey Zhu) – See Section Thursday – Need to look at Annex k (.11p) DONE

ACTION 3: We need to determine when we need to prevent changing the MAC address. - This action item is deferred to P1609. DONE

ACTION 4: Random MAC address duplication will be removed from the standard. (Wayne Fisher) DONE

ACTION 5: The draft standard needs to be updated to include ETSI as the “approval standard” for Europe and there is no approval authority in Europe (table 28). (Wayne Fisher) DONE

ACTION 6: Sensitivity numbers need to be updated (Table 35, 36). (Wayne Fisher) - We need to verify that the numbers match the sensitivity numbers in ASTM 2213. DONE

ACTION 7: The MIB needs to be reviewed to address any potential changes to the body of the draft standard. (Jason Liu) – Feb 15 On-going

ACTION 8: An email needs to be sent out to the TGp list with a request to download and review the draft standard. Comments need to be provided in the standard IEEE comment form. (Wayne Fisher) – Feb 21: email to download/review – March 7: Comments back to editor DONE – Schedule was delayed March 31 – Comments due to editor on current draft.

ACTION 9: Annex A needs to be reviewed/updated. (Rick Moens, Ariel Sharon) – Feb 15 DONE

ACTION 10: Jason Liu will work with Jeffrey Zhu and Jerry Landt to investigate identified options. (see minutes) Options discussed in the Monterey minutes: “It was requested whether we needed additional space to store the RSSI value. Jason Liu discussed that we had two options: one is stand-alone and the other one is

Submission page 2 Filip Weytjens, TransCore

March 2005 doc.: IEEE 802.11-05/0320r0 to reserve a new measurement type in 11h similar to 11k measurement extensions. Jason will work with Jeffrey Zhu and Jerry Landt to investigate these options.” DONE – New 11h measurement type will be included.

ACTION: 11 Jason Liu will investigate whether we need to add a MIB attribute indicating the RSSI performance of the unit. DONE

ACTION 12: Jeffrey Zhu will define and describe the test condition for this measurement and provide it to Wayne. This needs to be coordinated with the chip manufacturers to make sure that it is possible. – Due Feb 18 DONE

ACTION 13: (Doug Kavner/Justin McNew) Following items require coordination with 1609 and need more detail: - SAP/Services required in TGp to update MAC addresses - Buffering of MAC addresses: part of 802.11p or not. - Where is the randomisation standardized (802.11p or 1609)

None of this needs to be addressed in the TGp Amendment. We do need to include a requirement on how long it takes to reset the MAC Address.

ACTION 14: Wayne Fisher will contact the car industry to get this resolved. Language in the Monterey meeting minutes: “5.9.9: Not clear what the “equivalent on a commercial vehicle” means as this is not defined for a commercial vehicle. This is referring to the reference point for the antenna location not the point where tests occur. It is not clear whether this height could change with different bumpers or whether we need a point that is the same for all cars. It was requested to bring this up with the Car manufacturers. DONE – The reference point is as identified in the draft.

ACTION 15: Organize a meeting between TGp and TGu. (Lee Armstrong) On-going.

After discussing the Action items the minutes were approved.

ISO Liaison: They got our P1609/IEEE 802.11p documents for review. IEEE 1609: Doug Kavner: Draft documents are available and are in the process of being delivered to the IEEE 1609 Working group. Ballot will be in early June/July. IEEE 1556/Security: William White: An overview will be provided at the next meeting.

FCC Licensing: The license is approved but the site registration is under development.

Wayne went through the comments to the draft documents “IEEE P802.11/D1.2, March 2005”.

It was questioned by Bryan Wells how his comments were addresses. His concern was that the new language did not clearly identify the changes?

ACTION 16: It was discussed that the Excel spreadsheet should be used for comments. Wayne will use the approved comments form and will put it on the server. Will be available tomorrow. In the mean time comments are available on the memory stick.

Changes to the draft were made on the fly. The meeting was adjourned at 6:00PM

Submission page 3 Filip Weytjens, TransCore

March 2005 doc.: IEEE 802.11-05/0320r0

Monday, March 14, 2005, 7:30 PM Session

The meeting reconvened at 7:35 PM.

The document (TGp amendment) needs to be reformatted to make sure that there is no overlap between 1609.4 and IEEE 802.11p.

Section 5.9.4 was discussed and changes to the draft were made on the fly. A follow on discussion resulted in a change to the WIBSS. Words for the WIBSS will be provide by Doug Kavner to Wayne Fisher.

ACTION 17: Words for the WIBSS will be provide to Wayne Fisher (section 5.9.4). (Doug Kavner)

It was discussed that there should be no references in this document to IEEE 1609.3.

ACTION 18: Broady Cash will update the language in section 3.52, 5.9.2, 5.9.3 addressing the relation made to the In-vehicle bus.

Meeting adjourned at 9:25 PM.

Tuesday, March 15, 2005, 8:00 AM Session

The meeting was convened at 8:05 AM.

Wayne Fisher continued with the discussion on the draft amendment for TGp. Changes to the document were made on the fly.

It was mentioned that it was not clear whether section 20 was addressing 10MHz, 20 Mhz or both. Clarification was added to section 20.1 to clarify that section 20 was addressing a 10 MHz bandwidth.

A question was raised on the coexistence of 10 MHz and 20 MHz channels. This for instance becomes a problem when vehicles would be allowed to use 20 MHz. These vehicles could drive into a 10 MHz communication zone. It was decided that we would prevent the use of the 20 MHz for OBU-OBU communication.

The resolution of 0.2 dB was discussed and it was questioned whether the resolution made sense for a plus minus 3 dB accuracy. It was stated by Jeffrey Zhu that this was a relative number and that the numbers would be tested using an RF cable and by this limiting the impact of varying channels. No decision was made on whether the .2dB resolution was feasible with existing chip sets.

Meeting adjourned at 10:00 AM.

Tuesday, March 15, 2005, 10:30 AM Session

The meeting reconvened at 10:35 AM.

Wayne Fisher continued with the discussion on the draft amendment for TGp. Changes to the document were made on the fly.

It was questioned which information was used to derive the requirement for the adjacent channel rejection, Minimum sensitivity, and Alternate adjacent channel rejection in table 20.3.10.1.1. Same question came up for sections 20.3.10.3 to 9. It was mentioned that measurements were performed and that calculations showed that this requirement could be met. It was decided that the available Submission page 4 Filip Weytjens, TransCore

March 2005 doc.: IEEE 802.11-05/0320r0 documentation will be made available and will be discussed off-line. A list will be developed on which tests need to be performed in order to verify the requirements. The list will be presented next meeting.

ACTION 19: Provide available information on the measurements that were performed justifying the requirements that were stated in 20.3.10.3 to 9. This will be provided as a package. (Broady Cash)

ACTION 20: Preparation of a list with measurements that need to be performed in order to verify the requirements stated in 20.3.10.3 to 9. (Broady Cash, K. Koga)

ACTION 21: Presentation of the list of measurements during the next meeting. (Broady Cash, K. Koga)

The document will be updated based on comments received. The updated document will be discussed during the Thursday morning session.

A draft will be made available March 25. Comments to the draft need to be back on April 12.

Next sessions we will go through the comment sheets that were provided to the editor before the Atlanta meeting.

Meeting adjourned at 12:10 PM.

Wednesday, March 16, 2005, 4:00 PM Session

The meeting was convened at 4:05 PM.

Wayne Fisher started discussing the comments received to date and discussed how the changes were reflected in the document. Where necessary the document was updated on the fly.

Comments were addressed up to row 32 in the comments sheet (doc: 11-05-0281-00-000p-p802-11p-d1- 1-review-comments)

The meeting was adjourned at 6:00 PM.

Thursday, March 16, 2005, 8:00 AM Session

The meeting was convened at 8:10 AM.

Jason Liu presented an overview of the WRSS. The presentation addressed the frame structures, the message exchanges, and accuracy and resolution. A question was raised on how the RSU could know that the OBU successfully entered the measurement mode. A message exchange will be added to inform entering and stopping the measurement mode.

ACTION 22: The action was taken to resolve questions the body has on the WRSS concept. (Jeffrey zhu, [email protected]) Questions/comments need to be sent to Jeffrey by March 24. Responses will be provided by Jeffrey before April 5 and 6. During the week of April 5, a presentation will be presented by Jeffrey Zhu addressing the questions and comments from the group.

A few years ago a presentation was presented by Jeffrey Zhu on this subject. This presentation will be incorporated in the new presentation that will be provided in the week of April 5.

ACTION 23: Chip set manufacturers will be contacted to attend an adhoc meeting during the May interim. (Jeffrey Zhu)

Submission page 5 Filip Weytjens, TransCore

March 2005 doc.: IEEE 802.11-05/0320r0

ACTION 24: Setup an adhoc meeting/teleconference in the week of April 5. (Doug Kavner)

Wayne Fisher continued with a discussion on the draft document for TGp.

A straw pole was taken to have this latest draft made available to the 802 member site. Straw pole past unanimously.

The meeting was adjourned at 10:00AM.

Thursday, March 16, 2005, 10:30 AM Session

The meeting was convened at 10:40AM.

Wayne Fisher continued with a discussion on the draft document for TGp. Where necessary the document/comment sheet was updated on the fly.

Comments were addressed up to row 43 in the comments sheet (doc: 11-05-0281-00-000p-p802-11p-d1- 1-review-comments)

Action items

ACTION 7: The MIB needs to be reviewed to address any potential changes to the body of the draft standard. (Jason Liu) – Feb 15 Status Atlanta: On-going

ACTION 15: Organize a meeting between TGp and TGu. (Lee Armstrong) Status Atlanta: On-going.

ACTION 16: It was discussed that the Excel spreadsheet should be used for comments. Wayne will use the approved comments form and will put it on the server. Will be available tomorrow (Tuesday March 15). (Wayne Fisher)

ACTION 17: Words for the WIBSS will be provide to Wayne Fisher (section 5.9.4). (Doug Kavner)

ACTION 18: Update the language in section 3.52, 5.9.2, 5.9.3 where a relation is made to the In-vehicle bus. (Broady Cash)

ACTION 19: Provide available information on the measurements that were performed justifying the requirements that were stated in 20.3.10.3 to 9. This will be provided as a package. (Broady Cash)

ACTION 20: Preparation of a list with measurements that need to be performed in order to verify the requirements stated in 20.3.10.3 to 9. (Broady Cash, K. Koga)

ACTION 21: Presentation of the list of measurements during the next meeting. (Broady Cash, K. Koga)

ACTION 22: The action was taken to resolve questions the body has on the WRSS. Questions/comments need to be sent to Jeffrey by March 24. Responses will be provided by Jeffrey before April 5 and 6. During the week of April 5, a presentation will be presented by Jeffrey Zhu addressing the questions and comments from the group. (Jeffrey zhu, [email protected])

ACTION 23: Chip set manufacturers will be contacted to attend an adhoc meeting during the May interim. (Jeffrey Zhu)

Submission page 6 Filip Weytjens, TransCore

March 2005 doc.: IEEE 802.11-05/0320r0

ACTION 24: Setup an adhoc meeting/teleconference in the week of April 5. (Doug Kavner)

Submission page 7 Filip Weytjens, TransCore

March 2005 doc.: IEEE 802.11-05/0204r0

IEEE P802.11 Wireless LANs

TGr Meeting Minutes March 2005 Session

Date: 2005-03-17

Author(s): Name Company Address Phone email Michael 1900 Minnesota Cr, Suite 125. 905-567-6900 Chantry Networks [email protected] Montemurro Mississauga, ON. L5N 3C9 x237 m

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, Chantry Networks

March 2005 doc.: IEEE 802.11-05/0204r0

Tuesday March 15, 2005 8:00am

• Call to order • Agenda – Document 11-05/0203r0 • Review operating rules for a Task Group. • Review IEEE 802 policies and procedures for Intellectual Property. • Approve minutes from the January session – Document 11-05/1620r1. • Presentation of Document 11-05/0197r0 by Nancy Cam-Winget:

MOTION: Move to postpone Step 3 of TGr Process as defined in Document 11-04/1121 until May 2005 TGr meeting. By: Nancy Cam-Winget Second: Chris Durand Discussion: • The vote in May would be to adopt the proposal text as the initial TGr draft. • The sunset rule would still apply. • It seems like this group is starting from scratch. • The two proposals already have draft text. That would provide the basis for this work. • If two proposals came out of step 3, it was up to the technical editor to merge the drafts. In this case, the body has the option of participating in what goes into the merged draft. Result: 35 – Yes; 0 – No; 4 – Abstain.

• The revised agenda would be Document 11-05/0203r2. • No objections to approving the agenda as Document 11-05/0203r3 • Presentation of Document 11-05/0151r0 by Jon Edney: • The More Data bit is targeted at a Traffic ID. This proposal addresses a more general usage of the More Data bit. • This couldn’t be applied across the board. This would be directed to TGr-enabled stations. The behaviour of the AP should be mandatory for this proposal. • If the AP has the information available, it will set the bit. It’s not a mandatory to define the implementation. • This case doesn’t address power-save mode. Another approach could be to keep the STA active prior to BSS-transition. • In a previous discussion, we concluded that the STA should remain active when it makes a Transition. • Presentation of Document 11-05/0199r1 by Kapil Sood: • The PCP is a policy configuration point. Its position could be in different positions depending on the network. The diagram is a representative of different architectures. • The policy should be enforced at the AP. • The policy mechanism needs to be standardised over the air. It shouldn’t be standardised across the backend network. • TGr should define different policies. Network operators should be free to define their own policies. • The proposals are providing basic constructs to define policies. • Presentation of Document 11-05/0201r0 by Michael Montemurro:

Submission page 2 Michael Montemurro, Chantry Networks

March 2005 doc.: IEEE 802.11-05/0204r0

• Some of the ideas were not in this submission were not in the two proposals. • In JIT, these ideas had been discussed but not added. For TAP, they were using over-the- air mechanism, so they would not have addressed this. • Have we evolved from a merge of two proposals to a new complete solution? This violates the TGr process. Technically good work, but this is big change from the process. Need to bring the process forward. • Proposals were never static, and have been evolving from last year. Nothing in down- select process mentions the proposal cannot be modified. • If technical content changes dramatically, then whole group should be allowed to participate. How does TGr as a whole select among the various good technical ideas? There may be a change in process, and that must be recognized. • There is a feeling that the TGr body has given rights to create a solution to a small group of people on the two proposal teams. • Recall step 3, the editor can figure out how to merge. This new motion allows the TGr to participate. JIT and TAP were very similar looking, but had different mechanisms. So, everyone’s issues could be addressed. • Purpose of the new motion is to bring-in the TGr membership. Without this, the TGr could not even have looked into what was merged, if the editor was merging them, as per the original process. • If sub-teams were unwilling to include the TGr, then they would be hurting themselves. • Technical editor in TGr is well capable of merging. • Process should be ideally of merging the 2 proposals. A lot of new ideas could derail this merger with a lot of new ideas. • The term “mobility domain” is a concept; it is open to how that is defined. L3 may not be reachable via the DS. How the backend forwards is dependent on backend. • An idea to send reservations request over the air, and responses over the DS. • Presentation of Document 11-05/0210r0 by Jon Edney • This topic will be discussed as part of the “over the air”/”over the DS” adhoc. • Presentation of Document 11-05/0218r0 by Nancy Cam-Winget • On slide 4, the place that the keys reside depends on the backend infrastructure. The Authenticator holds the DA-PMK. • The boxes on slide 4 represent logical components that store the keys. • The query mechanism could be used to provision keys. Alternatively, the keys could be provisioned pro-actively. • TAP didn’t have a query mechanism. Once the key hierarchies are confirmed, then the mechanisms will be decided. • Recess until the 10:30 session.

Submission page 3 Michael Montemurro, Chantry Networks

March 2005 doc.: IEEE 802.11-05/0204r0

Tuesday March 15, 2005 10:30am

• Call to order • Break into adhoc groups and work until 12:30pm. • Recess until 1:30pm.

Submission page 4 Michael Montemurro, Chantry Networks

March 2005 doc.: IEEE 802.11-05/0204r0

Tuesday March 15, 2005 1:30pm

• Call to order • Break into adhoc groups and work until 3:30pm. • Recess until Thursday at 8:00am.

Submission page 5 Michael Montemurro, Chantry Networks

March 2005 doc.: IEEE 802.11-05/0204r0

Thursday March 17, 2005 8:00am

• Call to order • Presentation of Document 11-05/0239r0 by Rajneesh Kumar and Michael Montemurro • If AP advertises over the air or DS, it is up to the station to decide the final choice. • Over the air is query allowed, but reservation must be protected over the air. • Use current AP • Either wait for TGw work to complete • Mobility domain could be use to define roaming policy for WVoIP sets. • Presentation of Document 11-05/0250r0 by Nancy Cam-Winget • Consensus has not been reached. Document will be updated after further discussions. • Recess until the 10:30am session.

Submission page 6 Michael Montemurro, Chantry Networks

March 2005 doc.: IEEE 802.11-05/0204r0

Thursday March 17, 2005 10:30am

• Call to order • Discussion on TGr Adhoc meeting: • The earliest we can hold a meeting will be April 20-22.

STRAWPOLL: Will the meeting take place April 20-22 or April 27-29? RESULT: a) April 20-22: 16 b) April 27-29: 4

STRAWPOLL: Will the location of the meeting take place at Airespace (San Jose), Chantry Networks (Toronto) or Intel (Portland)? RESULT: a) San Jose: 14 b) Toronto: 13 c) Portland: 2

STRAWPOLL: Will the location of the meeting take place at Airespace (San Jose) or Chantry Networks (Toronto)? RESULT: d) San Jose: 8 e) Toronto: 10

• The TGr adhoc meeting will occur from April 20-22 in Toronto.

MOTION: Hold a TGr ad-hoc meeting on April 20-22, hosted by Chantry Networks in Toronto. By: Nancy Cam-Winget Second: Henry Ptasinski. RESULT: Yes – 19; No – 2; Abstain – 0.

• If we need approval for Teleconferences between now and the plenary, we should do it now. • Draft text could be a submission for the May meeting. • We should authorize teleconferences for after the May meeting. Bi-weekly after the May meeting. • Proposal is that we hold teleconferences on Wednesdays at 11:00 am ET.

MOTION: Hold bi-weekly IEEE 802.11 TGr teleconferences for one hour duration starting May 25th, at 11am ET and continuing through to the end of July. By: Henry Ptasinski Second: Nancy Cam-Winget RESULT: Yes – 18; No – 0; Abstain – 2.

• The meeting is Adjourned.

Submission page 7 Michael Montemurro, Chantry Networks

March 2005 doc.: IEEE 802.11-05/0045r0

IEEE P802.11 Wireless LANs

March 2005 Mesh Minutes

Date: 21-March-2005

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 11 Locke Drive, Motorola Donald E. Eastlake III Marlboro, MA, USA +1 (508) 786-7554 [email protected] Laboratories 01752 2111 NE 25th Ave, Bahareh Sadeghi Intel Corp. JF3-206 +1 (503) 217-8367 [email protected] Hillsboro, OR 97124

Abstract Minutes of the meeting of the IEEE 802.11 ESS Mesh Networking Task Group held in Atlanta, GA, from March 16th to 17th 2005, under the TG Chairmanship of Donald Eastlake III of Motorola Laboratories. Minutes were taken by Stephen Rayment (except for the last hour where they were taken by Bahareh Sadeghi) and edited by Donald Eastlake III. The final agenda for the meeting is in document number 11/05-113r8.

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

March 2005 doc.: IEEE 802.11-05/0045r0

Contents

Minutes ...... 3 Detailed Record ...... 8

Submission page 2 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Minutes

Session I, Wednesday, March 16th, 08:00-10:00, Hyatt Regency Hotel – Centennial I Ballroom

The meeting was called to order at 08:06 by Donald Eastlake III - Chair, Stephen Rayment - Secretary, W. Steven Conner - Editor

The Chair reviewed the overview of the week’s agenda, page 3 of 11-05/113r5

The Chair reminded everyone to use the On-line Attendance system.

The IEEE and 802.11 Policies concerning Patents and Inappropriate topics were explained by the Chair and there were no questions.

Approval of the Minutes of the January 2005 Meeting, 11-05/45r0 by unanimous consent

Approval of the Minutes of the Teleconference held 23 February 2005, 11-05/135r1 by unanimous consent

Adoption of Agenda, 11-05/113r5 by unanimous consent

The Chair reviewed the Status of Task Group 35 Notices received of intent to submit a proposal 34 Accepted, 11-05/112r7 9 requests for proposal linked presentation slots at this meeting 2 requests so far for proposal linked presentation slots at May meeting (deadline is midnight May 13th EST)

Moved, to accept the following 35th notice of intent to submit a proposal which was received before the deadline but had only been addressed to the TGs Chair and not also to the TGs secretary and 802.11 Chair as required by the Call for Proposals (11-04/1430r12): Contact Person: Bing Zhang Phone Number: +81-774-95-1533 Email: [email protected] Tentative title: Proactive Mesh Networks (ProM) Moved Guido Hiertz Second Stephen Rayment Yes 32 No 0 Abstain 1

08:24, Slot A, Intent #10, “Proposed Extensible Approach for WLAN Mesh Standardization”, W. Steve Conner (Intel) and Hidenori Aoki (NTT DoCoMo), 11-05/165r1 Straw poll on TGs interest in receiving further information: Yes 51 No 0

08:48, Slot B, Intent #14, “802.11 TGs Mesh Networking Proposal”, 11-05/196r2, Stefano M. Faccin, Carl Wijting, Jarkko Kneckt and Ameya Damle (Nokia) Straw poll on TGs interest in receiving further information: Yes 40 No 0

09:12, Slot C, Intent #24, “The Advantages of Invisibility and Cooperation”, 11-05/166r1, Ike Nassi, Jorjeta Jetcheva (Firetide) Submission page 3 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Straw poll on TGs interest in receiving further information: Yes 45 No 1

09:25, Slot D, Intent #4, “Cooperative Communication in Mesh Networking”, 11-05/143r0, Klaus Fosmark (University of Texas at Dallas) Straw poll on TGs interest in receiving further information: Yes 14 No 6

The Chair recessed the session at 09:46

Session II, Wednesday, March 16th, 13:30-15:30, Hyatt Regency Hotel – Dunwoody Room

The Chair reconvened the session at 13:30 and reminded everyone to use the on-line attendance system.

13:30 Slot E, Intent #5, “A routing protocol for WLAN mesh networking”, 11-05/174r2, Hang Lui, Jun Li and Saurabh Mathur (Thomson, Inc.) Straw poll on TGs interest in receiving further information: Yes 47 No 1

13:54 Slot F, Intent #23, “Deployment Considerations in Wireless Mesh Networking”, 11-05/268r0, Veera Anantha and Roger Skidmore (Wireless Valley) Straw poll on TGs interest in receiving further information: Yes 28 No 0

14:08 Slot G, Intent #3, “Proposal for a Dynamic Backbone Mesh”, 11-05/142r0, Dennis Baker, James Hauser (NRL) Straw poll on TGs interest in receiving further information: Yes 50 No 0

14:32 Slot H, Intent #26, “Proposal for Higher Spatial Reuse”, 11-05/267r0, Jack Winters (Motia) Straw poll on TGs interest in receiving further information: Yes 43 No 1

14:58 Slot I, Intent #32, “Proposal for ESS Mesh”, 11-05/263r0, Song Yean Cho, Jihoon Lee (Samsung), Philippe Jacquet (INRIA), Thomas Clausen (Ecole Polytechnique) Straw poll on TGs interest in receiving further information: Yes 47 No 0

The Chair recessed the session at 15:16

Session III, Wednesday, March 16th, 16:00-18:00, Hyatt Regency Hotel – Dunwoody Room

The Chair reconvened the session at 16:00

Presentation #1 “RBridges: Transparent Routing”, subset of 11-05/241r0, Radia Perlman Questions Presentation #2 “End to end Performance Considerations in Wireless Bridges”, 11-05/168r0, V. Gambiroza (Rice University), B.Sadeghi (Intel), E. Knightly (Rice University)

Presentation #3 “TGs Proposal Presentation Procedures”, 11-04/1539r4, Donald Eastlake

Submission page 4 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Presentation #4 “TGs Selection Procedure Recommendation”, 11-05/274, Tricci So, Juan Carlos Zuniga, D. J. Shyy, Tyan-Shu Jou, Guido R. Hiertz

Presentation #5 “TGs Process”, 11-05/207r1, Donald Eastlake

The Chair adjourned the session at 17:55

Session IV, Thursday, March 17th, 13:30-15:30, Hyatt Regency Hotel – Centennial II Ballroom

The Chair convened the session at 13:32, reminded everyone to us the on-line attendance system And reviewed the latest agenda, 11-05/113r6, and accomplishments of the TG to date

Presentation #6 “Exposed terminal problem solution by using multiple channels”, Atsushi Fujiwara (NTT DoCoMo), 11-05/247r1

Presentation #7 “MAC Components in IEEE 802.11s”, Bahareh Sadeghi, Lily Yang (Intel), Akira Yamada (NTT DoCoMo) 11-05/167r1

First Panel of Proposal Intenders #10 “Proposed Extensible Approach for WLAN Mesh Standardization”, 11-05/165r1, W. Steve Conner, #32 “Proposal for ESS Mesh”, 11-05/263r0, (Samsung) #14 “802.11 TGs Mesh Networking Proposal”, 11-05/196r2, Jarkko Kneckt #24 802.11s Mesh Portals “The Advantages of Invisibility and Cooperation”, 11-05/166r1, Ike Nassi

Each panelist provided an overview of their proposal, responded to questions from the floor and provided concluding remarks.

Second Panel of Proposal Intenders #3 “Proposal for a Dynamic Backbone Mesh”, 11-05/142r0, Dennis Baker #5 “A routing protocol for WLAN mesh networking”, 11-05/174r2, Hang Lui #23 “Deployment Considerations in Wireless Mesh Networking”, 11-05/268r0, Veera Anantha #26 “Proposal for Higher Spatial Reuse”, 11-05/267r0, Jack Winters

Each panelist provided an overview of their proposal, responded to questions from the floor and provided concluding remarks.

The Chair recessed the session at 15:22

Session V, Thursday, March 17th, 16:00-18:00, Hyatt Regency Hotel – Centennial II Ballroom

The Chair re-convened the session at 16:01, reminded everyone to use the on-line attendance system and quickly reviewed the Agenda for the session.

Presentation #8 “A security model for wireless meshs”, Robert Moskowitz (ICSA Labs), 11-05/172

The Chair proposed that the existing five documents on process be presented, allowing clarifying questions. Then there would be discussion to try to converge on process

Submission page 5 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Presentation #9 “TGs Process”, Donald Eastlake, 11-05/207r2 The Chair reviewed this document again, which included the Chair’s projected schedule for the group.

Motion to adopt the following motto for the TG “Perfection is achieved not when there is nothing left to add but when there is nothing left to take away” Moved Guido Hiertz, Second James Woodyatt For 19 Against 1 Abstain 17

Presentation #10 “Proposal Presentation Procedures for July and later”, Donald Eastlake, 11-04/1539r4

Presentation #11 “Selection Procedure”, Juan Carlos Zuniga, 11-05/274r1

Presentation #12 “Selection Procedure Recommendation”, Timothy Wakeley, 11-05/300r0

Presentation #13 “TGs Downselect alternative timeline”, Chair, 11-05/295r0

Chair states that we will first approve changes in 11-04/1539r4, then on changes in 11-05/0274 (including the changes suggestion in 11-05/300), vote to choose between the amended 1539 and the amended 274, and finally vote on adopting the chosen document.

Document 04/1539r4 Vote: In favor of the change presented in document 11-04/1539r4 to drop the bottom quarter of proposals. Result: about 20 to 2 (no accurate counting was done, the Chair asked if there was any objection to declaring the vote passed and there was no objection) The first alternative in the document, providing for dropping the bottom 25% of proposals, is approved.

Document 05/274 Vote on whether people should be required to give reason for the no votes in the final stage of downselect: No 7 Yes 18 Abstain 2

Vote on incorporation of the provision compelling merger of the two last proposals under some circumstances: Yes 18 No 5 Abstain 4.

Vote by show of hands/voting-tokens on removing item 9 from 05/174: Yes 10 No 10 Abstain 7. There being a tie, the Chair voted in favor and declared the motion passed which would have resulted in item 9 being removed from the document. There was a demand for a Division (a standing counted voted). Results: Yes 10 No 12 Abstain 6 Based on this more reliable count the Chair declared the motion lost and: Step 9 remains in the document.

The Chair offered to do yet another recount by an even more reliable method but no one requested it so the results immediately above stand. The Chair then proceeded to the choice between 11-05/1539r3 as amended and 11-05/274 as amended.

Vote to choose between documents 274 and 1539 as amended: 11-04/1539: 10 11-05/274: 11 Abstain: 6

The Chair then proceeded to the vote on adopting 11-05/274 as amended. The Chair called for debate but there was none. Vote to adopt document 11-05/274 as amended: Yes 12 No 6 Abstain 8 Submission page 6 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

The Chair declared document 11-05/274 adopted as amended. It was later uploaded as 11-05/274r3.

[IMPORTANT NOTE: The policy in 802.11 and its task groups, as set by the Chair of 802.11, is that the adoption or amendment of proposal selection procedures is considered a Technical matter as it involves choices between technical approaches. Therefore, document 11-05/274 as amended (later uploaded as 11- 05/274r3) was NOT adopted as the vote in its favor was only 2/3, not the required 3/4. The Chair publicly apologized for his error during the 802.11 Closing Plenary Friday morning the following day.]

The Chair suggested that TGs hold one teleconference between the March and May meetings on 20 April 2005 at 14:00 Eastern US time. The Chair called for alternative dates and times but none were offered. The Chair proceeded to a vote: Yes 21 No 0 Abstain 1

Discussion ensued on holding an Ad hoc meeting. Date: Aug 30 - Sep 1 Place: Portland, Oregon Purpose: Discussion of proposals

Intel has offered to host this meeting. The Chair called for alternative dates or locations or hosts. There were none offered.

Vote on requesting permission to hold an ad hoc meeting Yes 9 No 4 Abstain 7

The Chair adjourned the session sine die at 18:01pm.

Submission page 7 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Detailed Record

Session I, Wednesday, March 16th, 08:00-10:00, Hyatt Regency Hotel – Centennial I Ballroom

The meeting was called to order at 08:06 by Donald Eastlake III - Chair, Stephen Rayment - Secretary, W. Steven Conner - Editor

The Chair reviewed the overview of the week’s agenda, page 3 of 11-05/113r5

The Chair reminded everyone to use the On-line Attendance system.

The IEEE and 802.11 Policies concerning Patents and Inappropriate topics were explained by the Chair and there were no questions.

Approval of the Minutes of the January 2005 Meeting, 11-05/45r0 by unanimous consent

Approval of the Minutes of the Teleconference held 23 February 2005, 11-05/135r1 by unanimous consent The Chair reviewed the remainder of the Agenda in detail. The Chair indicated in response to a question from the floor that any additional proposals on post – July process are accommodated by the Agenda on Wednesday and/or Thursday PM

Adoption of Agenda, 11-05/113r5by unanimous consent

Straw poll on repeating the full Perlman presentation on rbridges Yes 15 No 40

The Chair reviewed the Status of Task Group 35 Notices received of intent to submit a proposal 34 Accepted, 11-05/112r7 9 requests for proposal linked presentation slots at this meeting 2 requests so far for proposal linked presentation slots at May meeting (deadline is midnight May 13th EST)

Moved, to accept the following 35th notice of intent to submit a proposal which was received before the deadline but had only been addressed to the TGs Chair and not also to the TGs secretary and 802.11 Chair as required by the Call for Proposals (11-04/1430r12): Contact Person: Bing Zhang Phone Number: +81-774-95-1533 Email: [email protected] Tentative title: Proactive Mesh Networks (ProM) Moved Guido Hiertz Second Stephen Rayment Yes 32 No 0 Abstain 1

08:24, Slot A, Intent #10, “Proposed Extensible Approach for WLAN Mesh Standardization”, W. Steve Conner (Intel) and Hidenori Aoki (NTT DoCoMo), 11-05/165r1 Straw poll on TGs interest in receiving further information Yes 51 No 0

Submission page 8 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

08:48, Slot B, Intent #14, “802.11 TGs Mesh Networking Proposal”, 11-05/196r2, Stefano M. Faccin, Carl Wijting, Jarkko Kneckt and Ameya Damle (Nokia) Straw poll on TGs interest in receiving further information Yes 40 No 0

09:12, Slot C, Intent #24, “The Advantages of Invisibility and Cooperation”, 11-05/166r1, Ike Nassi, Jorjeta Jetcheva (Firetide) Straw poll on TGs interest in receiving further information Yes 45 No 1

09:25, Slot D, Intent #4, “Cooperative Communication in Mesh Networking”, 11-05/143r0, Klaus Fosmark (University of Texas at Dallas) Questions ensued, including how does the relay know that there was an error in the original transmission? Straw poll on TGs interest in receiving further information Yes 14 No 6

The Chair recessed the session at 09:46

Session II, Wednesday, March 16th, 13:30-15:30, Hyatt Regency Hotel – Dunwoody Room

The Chair reconvened the session at 13:30 and reminded everyone to use the on-line attendance system.

13:30 Slot E, Intent #5, “A routing protocol for WLAN mesh networking”, 11-05/174r2, Hang Lui, Jun Li and Saurabh Mathur (Thomson, Inc.) Straw poll on TGs interest in receiving further information Yes 47 No 1

13:54 Slot F, Intent #23, “Deployment Considerations in Wireless Mesh Networking”, 11-05/268r0, Veera Anantha and Roger Skidmore (Wireless Valley) Questions ensued, particularly regarding the plug and play nature Straw poll on TGs interest in receiving further information Yes 28 No 0

14:08 Slot G, Intent #3, “Proposal for a Dynamic Backbone Mesh”, 11-05/142r0, Dennis Baker, James Hauser (NRL) Questions ensued, including node synchronization, hidden nodes, configuration Straw poll on TGs interest in receiving further information Yes 50 No 0

14:32 Slot H, Intent #26, “Proposal for Higher Spatial Reuse”, 11-05/267r0, Jack Winters (Motia) Questions ensued, including details of smart antenna details, access vs backhaul use, specific MAC changes Straw poll on TGs interest in receiving further information Yes 43 No 1

14:58 Slot I, Intent #32, “Proposal for ESS Mesh”, 11-05/263r0, Song Yean Cho, Jihoon Lee (Samsung), Philippe Jacquet (INRIA), Thomas Clausen (Ecole Polytechnique) Straw poll on TGs interest in receiving further information Yes 47 No 0

The Chair recessed the session at 15:16

Submission page 9 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Session III, Wednesday, March 16th, 16:00-18:00, Hyatt Regency Hotel – Dunwoody Room

The Chair reconvened the session at 16:00

Presentation #1 “RBridges: Transparent Routing”, subset of 11-05/241r0, Radia Perlman Questions What’s IPR status of RBridges? It’s been released in IETF in accordance with their rules so if IETF standardizes it, we should be safe building on that. In addition, efforts are underway to get a separate Letter of Assurance for IEEE 802.11 TGs as a back up. Why encapsulate? To provide for a hop count and to make sure that intervening bridges and RBridgess are not confused into thinking that a device was on the local link when it’

Presentation #2 “End to end Performance Considerations in Wireless Bridges”, 11-05/168r0, V. Gambiroza (Rice University), B.Sadeghi (Intel), E. Knightly (Rice University)

Presentation #3 “TGs Proposal Presentation Procedures”, 11-04/1539r4, Donald Eastlake The Chair reviewed the minor changes being suggested for this document which was adopted at the last meeting in so far as it outlines the process until July.

Presentation #4 “TGs Selection Procedure Recommendation”, 11-05/274, Tricci So, Juan Carlos Zuniga, D. J. Shyy, Tyan-Shu Jou, Guido R. Hiertz The document is based on the TGn procedure and a previous TGs document 11-04/1107r1 Questions Why have a low hurdle which won’t reject anything? How to distinguish complete from partial proposals when it is the submitter that declares compliance with functional requirements? How to merge partial proposals based on technical merit?

Presentation #5 “TGs Process”, 11-05/207r1, Donald Eastlake The Chair reviewed this overall process document, which includes a new timeline after July. Questions General concern over the time required to down-select given the large number of proposals

The Chair adjourned the session at 17:55

Session IV, Thursday, March 17th, 13:30-15:30, Hyatt Regency Hotel – Centennial II Ballroom

The Chair convened the session at 13:32, reminded everyone to us the on-line attendance system And reviewed the latest agenda, 11-05/113r6, and accomplishments of the TG to date

Presentation #6 “Exposed terminal problem solution by using multiple channels”, Atsushi Fujiwara (NTT DoCoMo), 11-05/247r1 Question How is channel allocation performed?

Submission page 10 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Presentation #7 “MAC Components in IEEE 802.11s”, Bahareh Sadeghi, Lily Yang (Intel), Akira Yamada (NTT DoCoMo) 11-05/167r1 Questions… - Multi or single frequency solution? Both - How can you do single frequency with EDCA? Deal with mesh and client traffics separately, different queues. - How does EDCA help in half duplex? Off-line discussion - Explain which Mesh Points beacon and which don’t. Trade-off as explained in presentation, needs work - Is beaconing overhead that high? Studies mentioned - Clarify beaconing? Intent here was beacon for whole mesh. Term not in current terms document PCF can co-exist with EDCA

First Panel of Proposal Intenders #10 “Proposed Extensible Approach for WLAN Mesh Standardization”, 11-05/165r1, W. Steve Conner, #32 “Proposal for ESS Mesh”, 11-05/263r0, (Samsung) #14 “802.11 TGs Mesh Networking Proposal”, 11-05/196r2, Jarkko Kneckt #24 802.11s Mesh Portals “The Advantages of Invisibility and Cooperation”, 11-05/166r1, Ike Nassi

Each panelist provided a brief overview of their proposal

Questions…

What part of proposal is immutable? #24 – doesn’t address APs, draw line between L2 and L3, mesh is for backhaul #14 – very open, home applicaitions, simplicity, power consumption for handhelds #32 – self configuring, security, extensibility, don’t be too evolutionary if it doesn’t serve multi-hop mesh needs #10 – working on complete proposal, enabler for new WLAN opportunities, multi-vendor interop is key, so open to other proposers’ input

Scalability / stability of routing with large routing tables Chair reminded people of the PAR target of 32 forwarding nodes #10 – unlike MANET, focus on self configuring for common usage scenarios, limit number since we’re working at L2 #32 – agree #14 – home networks #24 – with mesh nodes and mesh portals can build larger networks, unify with management

Comment – Larger networks are happening, how does limited TGs fit and scale?

Power of AP and STA – how does it relate to meshes and not APs #14 - MP has both, would like it battery operated, leave STA AP interface untouched

Separate forwarding from AP logically or physically? #24 – should be able to use existing APs, build meshes out of different units, may have same elements but used for backhaul, if you combine you get more complexity, no need given Moore’s Law #10 – given scope of PAR and evolution of BSS, need to consider implementation on single physical device but should logically separate #32 – separate protocol from implementation

Power consumption – is there really a requirement for a handheld to act as a mesh device? #14 – maybe not now but the standard should cover the future as well

Concluding comments Submission page 11 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

#10 – interoperability is key reason for standard, optimizations, e.g. video, VoIP, etc. identify common framework foundation across scenarios to allow interoperability while allowing vendors to add optimization on top #32 – everything to everyone vs interop, build baseline with enough hooks to allow .11 to progress, self configuring will be key #14 – presentations in line, go forward plan should be resolved now because there are more presenters #24 – prefer small tight standard, can address large number of nodes with current technology, Internet is a mesh

Second Panel of Proposal Intenders #3 “Proposal for a Dynamic Backbone Mesh”, 11-05/142r0, Dennis Baker #5 “A routing protocol for WLAN mesh networking”, 11-05/174r2, Hang Lui #23 “Deployment Considerations in Wireless Mesh Networking”, 11-05/268r0, Veera Anantha #26 “Proposal for Higher Spatial Reuse”, 11-05/267r0, Jack Winters

Each panelist provided an overview of their proposal

Questions…

#26 – Is smart antenna not orthogonal to mesh? See presentation – substantial reduction in performance, allows adjacent cell frequency re-use, spatial multiplex at same time, otherwise loose advantages in mesh, order of magnitude increase in capacity will dwarf mesh routing techniques, e.g. hidden node, adjacent channel, etc.

How will meshes be used? #3 – focus that they resemble Ethernet LANs #5 – home networks for delivering video, voice and data #23 – several, see Use Cases, outdoor campus and public safety is interest, up front design and management #26 – residential with multimedia from multiple vendors with good performance

Aren’t smart antenna problems equal in BSS, why not just cover in .11n #26 – Can’t, .11n only considers link not network, alternatively could be covered in .11v

Concluding comments #26 – want to dispel myth that algorithm complexity increases, small increase justified by performance gains #23 – want to ensure group thinking about adequate control mechanisms for management initially and with growth, e.g. where are Mesh Portals, which MPs beacon with optimized overhead, etc. Also site specific knowledge must be incorporated when deploying #5 – new technology will benefit from standardization with solid foundation for interop and flexibility eg. for QoS, security, etc. Have propose hybrid mesh routing protocol but look to co-operate with others #3 – important to build on stable foundation, in this case ability to co-ordinate and broadcast, have a solid protocol to do that, applicable to many applications with know performance, overhead. Willing to offer. Hoping to build full proposal on it.

The Chair recessed the session at 15:22

Session V, Thursday, March 17th, 16:00-18:00, Hyatt Regency Hotel – Centennial II Ballroom

Submission page 12 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

The Chair re-convened the session at 16:01, reminded everyone to use the on-line attendance system and quickly reviewed the Agenda for the session.

Presentation #8 “A security model for wireless meshs”, Robert Moskowitz (ICSA Labs), 11-05/172

Questions… - Can you use Certificates in wide area networks, here APs can’t be pre-configured in factory, so you don’t get autoconfig? Would use a user, not vendor, installed certificate. Need some minimum level of configuration for security. - EAP/RADIUS forces static IP, isn’t that fixed with IPv6? Only a problem only if you put RADIUS through IPSec. IETF is discussing. RADIUS Server has to know IP address to configure.

The Chair proposed that the existing five documents on process be presented, allowing clarifying questions. Then there would be discussion to try to converge on process

Presentation #9 “TGs Process”, Donald Eastlake, 11-05/207r2 The Chair reviewed this document again, which included the Chair’s projected schedule for the group.

Motion to adopt the following motto for the TG “Perfection is achieved not when there is nothing left to add but when there is nothing left to take away .” Moved Guido Hiertz, Second James Woodyatt For 19 Against 1 Abstain 17

Presentation #10 “Proposal Presentation Procedures for July and later”, Donald Eastlake, 11-04/1539r4 The Chair reviewed this document again, which was produced but not adopted at the last meeting by the TG, largely because July was far away. The proposal called for the elimination of the bottom 25% in July, a key procedure element to be discussed.

Presentation #11 “Selection Procedure”, Juan Carlos Zuniga, 11-05/274r1

Questions - Item 7 - When does first low hurdle vote occur? Intention is it is the meeting when all proposals have been presented - Item 10 – Binary down select process - can proposers bring proposals back? Only proposals that have passed can be considered. Urge those voted out to merge.

Presentation #12 “Selection Procedure Recommendation”, Timothy Wakeley, 11-05/300r0

Presentation #13 “TGs Downselect alternative timeline”, Chair, 11-05/295r0

Floor open for discussions - There are many different functional areas which might require more work for convergence of the proposals. We might not be able to speed things up a lot. - Experience from TGr shows a low threshold for elimination does not do anything. At the end the editor is responsible to merge the surviving proposals, which is not something that the proposal writers liked and hence they did it themselves. - Agree that a shorter process is better. We need enough time though for fair technical evaluations. My hope would be final vote in November. - Since we have 45 minutes let’s set up the goal for today. At the minimum we should decide what the process for July is. Another comment, the optimistic analysis presented by Chair in 11-05/295r0 could consider less than 24 proposals. - Chair: After some discussions we will start a tree and go through the proposals and first vote on the revisions on each and then do the vote between them and finally vote on the adoption of one left.

Submission page 13 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

- Suggestion to do a straw poll on document 274. It needs to include other people’s comments too. - The comments are in the documents and we can modify the documents on the fly. - Suggestion on merging during down selection process based on TGr experience (not very clear to understand) - Suggestion to mix and match among different pieces of proposals and hence taking more time to do it during the down select process. - There is so far only one official document on the floor; if adopted as is, will lead to more confusion in the future as it is not very accurate. It is a good start but requires more accurate wording. - The comments on the document were minor. We want the process completed now. Suggest clarification and polishing of the word on the fly now.

Chair states that we will first approve changes in 04/1539r4, then on changes in 05/0274 (including the changes suggestion in 11-05/300), vote to choose between the amended 1539 and the amended 274, and finally vote on adopting the chosen document.

Document 04/1539r4 Vote: In favor of the change presented in the document to drop the bottom quarter of proposals. Vote: about 20 to 2 (no accurate counting was done, the Chair asked if there was any objection to declaring the vote passed and there was no objection) The first alternative in the document, providing for dropping the bottom 25% of proposals, is approved.

Document 05/0274 Discussion on applying the similar change to this document to drop the bottom 25%. - Suggestion: copy the wording from the other document as it was more precise. “The lowest ranking one quarter of the proposals and any proposal with a yes ratio of 25% or less will be eliminated from consideration except that they may merge with a remaining presentation.” as stated in items 5 and 6 from doc# 04/1539-r4 - Other items from document 05/1539r4 can also be adopted. (Most of them already are)

Vote on whether people should be required to give reason for the no votes in the final stage of downselect. No 7 Yes 18 Abstain 2 Giving reason is required. Discussion on the editorial changes in the document 11-05/0274. - Section 12… Addition of what was voted on? - Section 7: change of last word from proposal to presentation. - Item no 8: change in Section 7 requires change of wording at the beginning of 8.

Document 05/0300r0 Discussion - It is already captured in 274 - It is forcing 2 proposals to merge. Which is not right. Request the remove. - Merge of the 2 proposals will be a 3rd proposal? (No: then there is only one) The language does not say withdraw. (Withdraw is the result of “merge”)

Vote on incorporation of the provision compelling merger of the last two proposals under some circumstances: Yes 18 No 5 Abstain 4. The language stays in the document.

More discussion on document 05/0274: - There is inconsistency between 7 and 9. Step 9 is a weaker elimination step compared to step 7. Suggestion to remove step 9 from the down-selection process. - An alternative to removing step 9 could be increasing the percentage

Submission page 14 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

- A low hurdle vote does not help based on the experience, and step 9 is very weak compared to 7… will only delay progress. Suggestion: drop the low hurdle vote. - The intent is not slowing down the process, rather to spend time to review all the proposals. - The point of low hurdle is to foster cooperation - Removing step 9 is a good idea especially since we have an ad hoc meeting scheduled. - Removing step 9 seems too aggressive and too strong for the down selection process. - In favor of removing item 9 from the document. We do not need that much time for studying the proposals and this step does not have any affect.

Vote by show of hands/voting-tokens on removing item 9 from 05/274 Yes 10 No 10 Abstain 7. There being a tie, the Chair voted in favor and declared the motion passed which would have resulted in item 9 being removed from the document.

There was a demand for a Division (a standing counted voted). Results: Yes 10 No 12 Abstain 6 Based on this more reliable count the Chair declared the motion lost and: Step 9 remains in the document.

The Chair offered to do yet another recount by an even more reliable method but no one requested it so the results immediately above stand. The Chair then proceeded to the choice between 11-05/1539r3 as amended and 11-05/274 as amended.

Discussion to choose between documents 1539 and 274. - In favor of adoption of 1539. Not enough time and chance to perfect document 274. - In favor of 274, because it accommodates everyone’s opinion. This document is trying to expedite rather than slowing the process, but it is important to give people enough time to discuss and merge. - Why can’t we adopt both (the motion is to choose one) - In favor of 1539, we have not had enough time to discuss it here, it should be adopted in May - In favor of 274, there will not be many voters in May. We need to fix the process before asking people to submit their proposals. - In favor of 1539, document 274 needs more discussion which is not possible now due to time limitations

Vote to choose between documents 274 and 1539 as amended 11-041539: 10 11-05/274: 11 Abstain: 6

The Chair then proceeded to the vote on adopting 11-05/274 as amended. The Chair called for debate but there was none. Vote to adopt document 11-05/274 as amended: Yes 12 No 6 Abstain 8

The Chair declared document 11-05/274 adopted as amended. It was later uploaded as 11-05/274r3.

[IMPORTANT NOTE: The policy in 802.11 and its task groups, as set by the Chair of 802.11, is that the adoption or amendment of proposal selection procedures is considered a Technical matter as it involved choices between technical approaches. Therefore, document 11-05/274 as amended (later uploaded as 11- 05/274r3) was NOT adopted as the vote in its favor was only 2/3, not the required 3/4. The Chair publicly apologized for his error during the 802.11 Closing Plenary Friday morning the following day.]

The Chair suggested that TGs hold one teleconference between the March and May meetings on 20 April 2005 at 14:00 Eastern US time. The Chair called for alternative dates and times but none were offered. The Chair proceeded to a vote: Yes 21 No 0 Abstain 1

Submission page 15 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0045r0

Discussion on holding an Ad hoc meeting. Requesting the meeting does not guarantee it as we can always cancel or request approval for an alternative date and/or location. Date: Aug 30 - Sep 1 Place: Portland, Oregon Purpose: Discussion of proposals

Intel has offered to host this meeting. The Chair called for alternative dates or locations or hosts. There were none offered. - Date is too early. (If this date or later we don’t need to adopt it now)

Vote on requesting permission to hold an ad hoc meeting Yes 9 No 4 Abstain 7

The Chair adjourned the session sine die at 18:01pm.

Submission page 16 Stephen G. Rayment, BelAir Networks

March 2005 doc.: IEEE 802.11-05/0304r0

IEEE P802.11 Wireless LANs

Minutes for Task Group T Atlanta Session, March 2005

Date: 2005-03-13 Author: Name Company Address Phone email

9600 SW Oak St. Tom Alexander VeriWave, Inc Suite 380 +1 503 473 8358 [email protected] Portland, OR 97223

Abstract

This document contains the meeting minutes from the TGT Task Group session held in Atlanta, GA, between March 15 and March 17, 2005.

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 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

Tuesday, March 15, 2005 0800 – 1000 EST

Charles Wright (Chair, TGT) called the meeting to order at 0800 EST. He presented his opening report (document 11-05-0153/r0). He went through the standard introductory material (IEEE bylaws, patents, etc.) Tom Alexander was appointed temporary recording secretary for the session until a permanent one could be found.

Charles mentioned that the 802.11 WG had requested timelines from all the groups, and that there would be a discussion on timelines in the group. He then reviewed the proposed agenda. The agenda was approved by acclamation. The minutes from the Monterey meeting (document 11-05-0087/r0) were also approved.

Charles then issued a call for presentations. Craig and Fanny requested a slot on Thursday to present on the document structure. Craig also requested a slot to present on a diversity test (document 11-05-0194/r0) and an ACI test (document 11-05-0215/r0). Uriel noted that the document for the definitions ad-hoc output was 11-05-0206/r0, and he would be presenting it. Fahd said that Pratik would be presenting document 11-05-0177/r0 and he himself would present document 11-05-0178/r0. Uriel also requested some time for an open discussion. Mark requested a slot for an update of the over-the-air testing methodology work, to be presented by Dalton (document number to be provided).

A discussion on presentation ordering then took place. Pratik's slot was set at 1030 EST and Uriel's slot was set to 1330 EST. Craig volunteered to present his diversity test at about 1600 EST on Tuesday. Charles also added a 1 hour slot for general discussion of metrics. There were some topics left over from the Monterey meeting: subclause X.3.3 from the document template (11-05-1540/r2) and the criteria for formal proposals (11-04-1553/r1). Charles elected to discuss the criteria for formal proposals at 9 AM on Tuesday, and subclause X.3.3 at the end of the session if time permitted.

There were no objections to the modified agenda, so it was approved by acclamation.

Charles then opened a discussion on the TGT timeline. He noted that the WG leadership was requesting a set of formal milestones and some fairly accurate estimation of when these milestones would be met. Charles proposed that we could have a draft by November of 2005 and go for first letter ballot.

There was an extensive discussion on the draft timeline. Pratik noted that he'd presented a draft of a timeline previously that had a letter ballot scheduled for March, which was probably a bit optimistic. Charles noted that it was better to do some rounds of internal review before forwarding to letter ballot. There was some discussion on the TGk process and how they got to the first draft. Simon Barber, TGk editor, was present and clarified some of the timeline and process. There was much discussion on the various dates and process.

Charles then drafted up a list of action items for the group. There was some discussion on the requirements for formal proposals. Charles clarified that this would be done starting with document 11-04-1553/r1, which had been revised to 11-04-1553/r2. He showed the revised document to the group. There was extensive discussion on the need for a presentation

Minutes page 2 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0 accompanying the draft text, and whether this could be something that was "recommended" rather than "mandatory". Some wordsmithing of the document ensued.

The meeting was recessed at 1000 EST.

Tuesday, March 15, 2005 1030 – 1230 EST

Charles called the meeting to order at 1030 EST. He then gave the floor to Pratik, as the first presenter on the agenda.

Pratik presented document 11-05-0177/r0, which dealt with Dell’s viewpoints on the aims and target audience of TGT. He noted that the group was all about performance and the user experience, not about compatibility and interoperability. He briefly reviewed the stakeholders and the general process used by TGT to derive and use metrics. He also provided Dell's view of the expected outputs from TGT and the effort required to get there. He elaborated on the usage cases (data, streaming, latency-sensitive) and explained what he meant by each one, and then talked about primary and secondary metrics. There was some discussion on when a secondary metric would be measured as opposed to a primary metric.

Michael expressed a concern about correlation across different test environments, as opposed to the correlation from test results to applications. A discussion on correlation and environments ensued. Tom pointed out the distinction between correlation and equivalence, where correlation was defined in terms of similar trends in values and equivalence was defined in terms of identical values. Further discussion on correlation across environments took place.

The question was asked: Why are we measuring under different environments? Should we not be specifying one environment in which a measurement must be made? This sparked further discussion about why multiple environments were useful.

Pratik went on to discuss the difference between primary and secondary metrics, and the value of primary vs. secondary metrics. He showed an example, drawn from a typical battery life benchmark, illustrating how the primary and secondary metrics were defined and what the methodology was. He then gave a similar example applied to wireless benchmarking, showing how a throughput and range measurement could be set up for data applications.

Fanny noted that throughput and range are closely correlated and so the measurement should be more like throughput vs. range instead of throughput independently of range.

Pratik concluded by saying that it would be likely that we would have to combine the measurement - both primary and secondary metrics. We might do both.

Some questions were asked about interference, antenna radiation patterns, etc. Michael noted that it seemed like there was a lot of informative material related to the models and it might be a problem. Craig asked if there had been any work on setting up the models; Pratik noted that they had been talked about but nothing was settled. A question on the timeline for any of this was raised; Pratik replied that this had been dealt with in the morning. Some discussion about timelines and a sense of urgency took place. It was noted that the TGn channel models could be

Minutes page 3 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

used as-is, at which point another member wanted to know what relevance channel models had to the TGT effort. A discussion took place on channel models as applied to TGT.

Dongho noted that the conducted test environment seemed more like a component test, as it did not take the antenna into account, while the other three OTA environments would be treated more as a system-level test. It was noted that one could take the antenna radiation pattern into account to get correlation between the conducted and OTA tests.

With this, Charles thanked Pratik for the presentation, and requested Fahd to take the floor for his talk.

Fahd presented document 11-05-0178/r0 on testing with streaming media applications. He started off by saying that he wanted to take this opportunity to draw differences between streaming media and data-oriented applications. He gave some of the metrics that impacted streaming media performance and noted that there were a large number of these. He discussed some of the metrics involved. Craig noted that ACI could be a significant contributor to the performance of streaming applications, due to interference and retries. Questions were also asked about whether subjective measurements (made by human viewers of the video stream) would be applicable here.

Fahd presented some actual measurements on equipment. Questions were asked about the influence of the Windows OS on the measurements. Discussion took place on the meaning of various aspects of the results. Fahd then showed a measurement process that was performed in an actual house, using TCP streams and measuring the number of retransmissions. A question was asked as to whether Fahd had actually used TCP, or whether he was running some kind of streaming protocol; Fahd said that he had actually run TCP.

After this, Fahd presented some measurements taken at multiple locations in a house, using different clients. He observed that there was clearly a correlation between the throughput at various locations for different clients, even though the absolute throughput varied between locations. He also showed how the user-perceived video quality would vary based on the amount of background traffic that was injected. Craig made the comment that this would also be driven by things such a QoS in the AP and so forth, which would become very important when you started adding background data to the mix.

Fahd then showed a test where there were multiple video streams streamed over the air to multiple clients located quite close to an AP. He noted that the key thing was that the video quality was very poor unless QoS was enabled, even though there was a substantial amount of bandwidth available (as evidenced by the amount of background traffic that got through). He said that this was clearly indicating that it was not sufficient to just measure throughput when looking at video streaming applications, there was clearly something else at work here.

There was a question of how much background load was introduced. Fahd replied that this was about 20 Mb/s without any video streams, decreasing as more video streams are introduced.

Fahd then went on to describe the performance metrics that he thought the group should look at in terms of streaming media applications. Craig wanted to know whether things like codecs would impact the results of measurements of performance with things like, say, VoIP. Fahd said that it would certainly do so. Fanny asked if these measurements were made in a live

Minutes page 4 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

environment; Fahd said that they were. Fanny then said that the key issue was to make the measurements repeatable, but if there was something like a standard house model it would be very useful. Pratik said that these were the kinds of things that people are actually doing; Fanny replied that she liked the measurements, but we had to find a means to be thorough about it.

Fahd concluded by saying that clearly the streaming media applications required a different set of metrics from data applications, and we have to tie the metrics to the end-user performance. He also said that we have to be careful to capture all of the benchmarks, or we would land up in a situation with two different benchmarks, one from TGT and one from some industry consortium.

Dongho wanted to know why Fahd had not used the throughput and throughput deviation in the measurements on streaming video applications. Fahd agreed that this could be done too. The question of looking at delay and jitter came into this also.

With this, Charles thanked Fahd for his presentation and recessed the meeting for lunch at 1230 EST. He announced that the meeting would resume in the afternoon at 1330 EST.

Tuesday, March 15, 2005 1330 – 1530 EST

Charles called the meeting to order at 1330 EST. He first reviewed the agenda; he noted that Michael was the leader of the definitions ad-hoc teleconferences, and had a presentation related to the one being given by Uri. With that, Charles turned the floor over to Uri for his presentation.

Uri presented document 11-05-206/r0. He went over the definitions one by one. There was some discussion on individual definitions. Some disagreement came from the group regarding the definition of "metric". Tom offered to go off and come back with a few alternative choices for the word "metric" and put them before the group to allow them to select one (or a combination).

There was some debate about the definition of "repeatable". Michael suggested that the word "uncertainty" should be used in place of "accuracy" or "precision" as this was becoming more prevalent in metrology. The same topic also came up when discussing the definition of "controlled test environment". With regard to the definition of "environment", Michael noted that this was just the dictionary definition and was put there as a starting point.

There was a good deal of discussion and debate about the term "interference test signal". Michael noted that RF noise could fall within this term. Fahd wanted to know how detailed the definitions should be; Tom replied that they should be as detailed as necessary to enable everyone to agree with them. Craig then observed that there was no definition of “DUT” or “SUT”; it was clear that this was missing.

There was considerable discussion on "channel". The discussion then turned to the acronyms. There was no particular issue except for "VoW", which some people expanded as "Voice over Wireless" instead of "Video over Wireless".

Charles noted that it was not necessary to enumerate all of the different test cases (indoor LOS, outdoor NLOS, etc.), if we separated them out into the various groups and explicitly stated that combinations were possible.

Minutes page 5 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

There was some discussion on having an ad-hoc for further polishing of the definitions and ironing out some of the more controversial ones. Tom suggested that the definitions were intended to let people understand each other, and we should stop polishing them, put them in the document and let them “grow on people”. Fahd supported that as well. There was an objection to "VoW", and it was proposed that it should be taken out.

Charles then thanked Uriel for having presented, and turned it over to Michael for presentation of additional material on definitions.

Michael presented 11-05-0232/r0, which he said represented the output of the definitions ad-hoc. He went through the definitions one by one and gave the explanation and background material for them. There was discussion as to the differences between the various tentative definitions. There were some suggestions for how to resolve the differences. Tom proposed that both definitions could be put into one document with an editor’s note indicating that there would be a choice between them made in the future, after people had a chance to decide which was better.

Charles proposed the following instructions to the editor: ‘Take document 11-05-0206/r0 and 11- 05-0232/r0 and create a definitions section in the draft based on those definitions. Where there are definitions that are competing, put both of them together with an "or" and an editor's note stating that both definitions are being considered.’ However, Pratik suggested that we should instead have Uri and Michael get together and combine their definitions into one document so that the group can look at it on Thursday. The instructions to the editor were not considered further.

With that, Charles thanked Michael for his presentation and turned the floor over to Uriel for a presentation on metrics.

Uriel presented some candidate metrics from document 11-05-0003/r1, authored by Steve Shellhammer and originally contributed at the Monterey meeting. There was some debate on the various metrics he discussed. Craig wanted to know what the difference was between “FER” and “FLR”. There was considerable discussion on the topic. Charles suggested that “FER” referred to FCS errors and “FLR” referred to frames lost due to excessive retries. Fanny gave some perspectives based on half-duplex Ethernet. Other suggestions were also made.

In discussing the various use cases, it was noted that voice was also highly dependent on range. There was a significant discussion on range effects and their applicability. There was also a long discussion on packets vs. frames.

Gerard brought up the issue of dealing with application-layer metrics such as R values, and asked how to indicate what was a good result versus a bad result. Fanny explained that there was a section on such application-layer metrics, and the group wasn't supposed to assign subjective qualities to the results. There was a fair amount of discussion on the list of metrics.

Pratik noted that this document was a good start as it enabled people to think about the various metrics and to get an idea of the use cases. He also alluded to the "parking lot for metrics" that had been created earlier.

Charles thanked Uriel for his presentation, and then checked to see if the other presenters were ready to go after the recess. He also asked for new presentations. Marc requested a slot to discuss

Minutes page 6 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

a new presentation, on the subject velocity effects on handover decisions (document 11-05- 0236/r0). The agenda was modified to include Marc’s presentation without objection.

Charles then recessed the meeting at 1530 EST, to be resumed at 1600 EST.

Tuesday, March 15, 2005 1600 – 1800 EST

Charles called the meeting to order at 1600 EST. He reminded everyone to register on the server, and then turned the floor over to Craig to present document 11-05-0194/r0, on diversity testing.

Craig started by saying that his presentation was more along the ‘nuts and bolts’ of testing rather than the high-level stuff we had been discussing to date. He showed a diagram of the test setup first and then discussed the basic diversity test. He then ran through the slides explaining the basic test procedure. Michael wanted to know what the switching time on the attenuator itself was relative to the switching time allowed for the diversity test. The general response was that it could be in the microsecond range.

Craig then explained the hysteresis diversity test, and how this checked for oscillations and throughput loss during the diversity switching. He also discussed the threshold diversity test. There was a question regarding an influence of the slope of the attenuator change, and an effect on the speed. Craig said that there was definitely an influence due to the algorithm used to calculate RSSI, resulting from the averaging time. Craig closed by showing the proposed metrics for acceptance.

Fanny commented that "starting" and "ending" were a bit confusing, as we were discussing a cyclic process here, and there is no real way to define this. Fahd wanted to know how scalable this was for a MIMO solution; Craig noted that this was a SISO test and not applicable. This led to a discussion on MIMO and diversity in general.

Dick commented that in the first test Craig was actually looking at how balanced the antenna paths were, and wanted to know how much variability there was in the throughput results. Craig replied that the variability was device dependent. Tom noted that this is a switching diversity test and possibly the two metrics being measured are really static throughput (no diversity switching) and dynamic throughput (diversity switching).

Michael asked about using a full channel simulator in this application; Craig noted that a channel simulator could indeed be used. It was also noted that with a channel simulator we could have a real MIMO test. There was a long discussion about presenting the results in an appropriate manner. Fanny suggested integrating the throughput over time. Tom suggested normalizing (dividing) by the maximum static throughput to enable the results to be compared across PHY technologies. Charles suggested further dividing by the time period of the test to ensure that the integration was normalized to unit time. Dalton further remarked that the outage time was essential, as for HDTV he was more concerned about a 20 Mb/s dip for 1 second vs. a 1 Mb/s dip for 20 seconds. There were numerous other comments and suggestions, including the statistical calculation of a beta.

With that, Charles thanked Craig for the presentation, and invited Marc to step up for his talk.

Minutes page 7 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

Marc presented document 11-05-0233/r1, about velocity effects in handover decisions. He started off by remarking that his talk was similar to the preceding presentation on diversity. Here, however, he was interested in seamless handover in a high-speed train scenario. For this, he was interested in the influence of velocity on the handoff delay.

Marc remarked that there was a lot of low pass filtering and hysteresis being done on the RSSI to remove fast fading effects and minimize flapping. However, it looked like velocity would make a difference here. He presented the scenario and then the general algorithms. He also noted that the faster the speed the less the switching time. Fanny remarked that the algorithms are typically designed by firmware people who may or may not have done it correctly; Marc said that they found the same thing. There was an extensive discussion.

Marc remarked that the overlap could be controlled to control the handover frequency. He then said that newer WLANs with millimeter-wave frequencies would have similar issues, in that millimeter-wave WLANs would experience, at pedestrian walking speeds, one handoff per second. With these parameters the required overlapping for zero delay handover would be 80%.

One suggestion Marc had was to make the hysteresis margin inversely proportional to the velocity. This works because the handoff works better as the velocity increases, and slower velocities are more prone to cause flapping. He recommended that the velocity of a mobile terminal should be a factor in the metrics defined in TGT, and that performance evaluations involving handover should conduct experiments involving various speeds.

Charles then thanked Marc for his presentation, and asked Dalton to take the floor.

Dalton then came up to present document 11-05-0235/r1, which was a continuation of the updates given on a controlled open air test methodology. He started with a review of the PAR & 5 Criteria, and then gave an overview of the methodology. He said that the methodology had now been extended to include the quiet zone and other comments from previous meetings. The equipment was extended to include laser positioners that generated crosshairs, and these were used to facilitate antenna positioning. He noted that the sharks shown in the picture did not contribute to the measurements.

Dalton then showed some actual OTA measurements compared to conducted. He also described the quiet zone variation measurements, and noted that the measurements within the quiet zone was constant to within +/- 0.5 dB while the measurements outside the quiet zone were accurate only to +/- 1 dB.

In conclusion, he noted that the laser positioners had enhanced the accuracy and also that the quiet zone was found to be fairly uniform.

There were several questions about the general test procedure and the observed variation in the test results. Michael commented that for the measurement setup described, the results were pretty good for that size chamber. There were some questions about the setup and the loss between the antennas. Fanny asked about the near field effects; Michael explained that there were two types of near-field effects, one being the standard Fraunhofer zone and the other being the reactive near-field, where the coupling between the DUT and the probe is reactive and modifies the behavior of the DUT. A discussion of the quiet zone measurements also ensued.

Minutes page 8 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

Charles then thanked Dalton for his presentation, and reviewed the agenda. He noted that we were up to item 9 on the list of technical presentations (not available until Thursday), and hence were making very good progress. He then went over the rest of the agenda, and focused on the formal proposal requirements. He put up document 11-05-1553/r2 on the screen to explain some topics. There was a discussion on the formal proposals, including a question on whether people were required to follow the formal proposal requirements. Fahd asked for clarification on the process. Fanny remarked that there should be some editorial leeway but the output should be voted on by the group. Charles went through a discussion of the editorial process. There was a discussion on the voting process for the draft. It was finally concluded that the process was as follows: first, the formal proposals would be voted in; then, the editor would insert them into the draft; then, the modified draft would be circulated for review; and, finally, at the next meeting people would come with new proposals and changes to existing draft text, which would all be voted on as well. This segued into a discussion on adopting the requirements for a formal proposal; it was ultimately agreed that the group would treat these as guidelines, but no vote would be taken on them.

A discussion on the program for Tuesday evening then took place. It was finally decided, in light of the progress, to recess for the day, and resume on Thursday afternoon.

The end of the appointed meeting time having arrived, Charles recessed the meeting at 1800 EST Tuesday, to resume at 1330 EST Thursday.

Thursday, March 17, 2005 1330 – 1530 EST

Charles called the meeting to order at 1330 EST. He noted that the group had two presentations (items #9 and 10), plus a new business item from Uriel on the revised acronyms. With that, he turned the floor over to Craig for his presentation on ACI testing.

Craig presented document 11-05-0215/r0, which dealt with the basic ACI approach as well as the approach for margin testing. He noted that this setup was the same as for diversity testing, but a spectrum analyzer was added for determining the power levels at the DUT. He gave a basic description of the ACI test, which was focused on rejection of an interfering signal, and discussed the various differences between a, b and g PHYs. He noted that the metric that came out of this was adjacent channel rejection. Charles clarified that this was a secondary metric.

Craig also noted that a golden NIC was involved in the calibration process, or alternatively a power meter. The basic procedure was presented, including the various signal levels and pass/fail requirements for the various PHY standards. He mentioned that the standards were a bit confusing on FER and PER. Uriel clarified that the difference was in the lengths used. The frame error count was equal to the number of retransmitted packets. Michael clarified that the count of retries was included in the total count of packets.

Craig then noted that he started looking at this and was dissatisfied with the test, as it did not relate directly to the real-world experience of the users, where there were multiple interferers on different channels at various spacings. He wanted to go beyond a single interferer and FER, and measure throughput instead. Charles suggested that this would make it a primary metric, instead of a secondary metric. There was some discussion on this topic.

Minutes page 9 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

The margin ACI procedure was then discussed. Craig noted that the test would not be focused on 10% or 8% FER, but instead to find the point where throughput impacts the user experience. In addition, association requests must be done as well, measuring time-to-connect. Mark wanted to know if Craig proposed measuring ACR at different channel spacings for the interferer; Craig said that this was a possibility. Michael also pointed out that the characteristics of the golden unit (the interferer) would be a factor. There was a lot of discussion about the spectral mask issues. The point was made that the test was multiplying the spectral mask of the transmitter against the ACI rejection filter of the receiver, and there was a lot of discussion on this point.

Charles noted that the frequency planning and channel selection aspects of the test would be the key factors here. Michael noted that an interoperability style test would be virtually impossible to perform because of the variety of devices involved, and you need to fill the spectral mask of the transmitter to the limit before you can test a DUT. Tom asked the question about what a vendor could do to improve his or her performance on the test. Craig responded that there were higher layer effects that would also be a part of the test. Dick noted that you could get good ACR with interferers that were 2 channels or more apart, but as soon as you got two interferers bracketing a DUT it became very difficult for the DUT to function. Dalton wanted to know about non- compliant interferers on adjacent channels. Charles noted that this is coexistence, and Steve Shellhammer would be welcome some involvement on this topic.

Charles then thanked Craig for his presentation, and invited Fanny to take the floor to present on document structure.

Fanny presented document 11-05-0296/r0. She presented a table of contents to the group; the first 3 clauses were standard boilerplate. The fourth clause dealt with test environments, describing the various types of environments. The fifth clause talked about primary metrics, and would be a fairly large one. The sixth clause would deal with secondary metrics. The seventh clause dealt with application performance; the various application scenarios would be treated here.

There were questions about BER vs. FER, battery life, whether the subclause headings were to be retained as-is, whether LOS was a subset of NLOS, what AP stream capacity meant, whether there was any value in splitting “data” into “non-real-time data” and “interactive data”.

Fanny offered to keep a record of all the different types of traffic models and so forth. Michael noted that the chamber could be anechoic, semi-anechoic, and so on, but what was more important were the requirements for the various chambers. Mark wondered what the differences were between section 5 and 7; what was the point of application performance vs. primary metrics? The answer was that Clause 7 is more informative and explains how to relate the metrics to applications, but Clause 5 is about the actual measurements. Kourosh asked about the range tests, and Joe wanted clarification on this as well. A discussion took place about antennas and rate vs. range testing, and converting between path loss and distance. Kourosh felt that the value that TGT was offering was that we could not only define the test but also the environment. Fahd clarified that the range and data rate issue was heavily determined by what application was being used. Marc said that we should not impute any of these values or limits to the test metrics, and the test metric should be entirely independent of these assumptions. A lot of discussion took place on this topic.

Minutes page 10 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

Tom noted that a missing section was “reporting requirements”, so that vendors would have to report the DUT configuration with the tests. Fanny added this to the document. Charles also remarked that path loss could be approximated in various ways in order to translate into range. There was a lot of discussion on this topic. The issue of antenna radiation patterns came up. More discussion followed. Pratik wanted more time to review this contribution.

Charles then thanked Fanny for her presentation. A discussion took place on what to do next. Charles asked Uriel whether he was ready to present, and whether it could be done in 15 minutes. Uriel came up and presented his document.

Uriel presented document 11-05-0206/r1. He said that this document did not have choices in it. Michael said that his understanding was that the Tuesday discussion left him with the impression that where there were multiple definitions, there should be multiple choices in the document that would be left to future choice. There was a good amount of discussion about this. Tom gave an editorial rant.

There was a discussion about a motion to accept these definitions and pass them to the editor for review and incorporation. It was announced that ice cream was available, whereupon (the time being 1530 EST) the orders of the day were called.

Charles recessed the meeting at 1530 EST, to resume at 1600 EST.

Thursday, March 17, 2005 1600 – 1800 EST

Charles called the meeting to order at 1606 EST. He requested Uriel to put the definitions up on the screen again, and go through some of the more controversial ones. Uriel went through: metric, environment (all), conducted.

Tom noted that the discussion on the definition of environment is over, but asked if the discussion on environment itself was over. Uriel said that he certainly expected a lot of discussion when we got to test environments for metrics, but at least we had some tools to work with.

There was also a question on changing the definitions after they were introduced into the draft. Tom noted that the definitions section was actual editorial and informative in nature, and also subject to the requirements of the IEEE staff editors. He noted that while controversial definitions that affected technical issues would be voted on using the 75% rule, the majority of the definitions should be strictly editorial and should be fairly straightforward.

Motion #1: Move to direct the editor to adopt the content of 11-05/206r1 into the draft, creating revision 0.1 of the TGT draft.

M: Pratik Mehta S: Dalton Victor

Y: 12 N: 0

Minutes page 11 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

A: 1

Motion passes.

Following passage of the motion, members now began to offer editorial comments to some of the definitions. In definitions, change in LOS/NLOS to “For example, this channel is usually modeled using Rician statistics” and “For example, this channel is usually modeled using Rayleigh statistics”. Tom will add a note stating that this definition is controversial and will be changed once there is draft text that requires the definition of these items, and this definition is still subject to review and change. The editor was also directed to take a crack at the definition of “Model” with inputs from various people.

Pratik noted in closing that this was a good achievement that brings a lot of things to the group and while it will evolve over time it was a good start.

Charles then brought up the guidelines (originally, requirements) document, document 11-04- 1553/r2, and asked whether anybody would like to make a motion to adopt. Michael wanted to know if we could require people to use changebars in their submissions so that we could see what had changed. Charles felt that this was not necessary to include as a formal motion.

Pratik then moved to accept the proposal requirements document, provided that within MS-Word all changes were accepted in the document. Charles performed this MS-Word command before the group, thereby creating document 11-04/1553r3.

Motion #2: Move to accept the guidelines document (11-04/1553r3) as part of the process in TGT.

M: Pratik Mehta S: Michael Foegelle

Question was called by Mark Kobayashi. There was no objection so the question was called. Y: 13 N: 0 A: 1

Motion passes.

Charles then brought up the topic of how we go forward. He said that we needed to figure out how to make progress in the next few months, because a straw poll had indicated that a large number of people would not be able to make it to Cairns. He suggested that we could do more work in the teleconferences if there was more open and honest discussion, more open criticism, and more focus on making decisions. He then moved to a discussion of action items.

Pratik asked about quorum rules and also about how many people would attend the Cairns meeting. There was some discussion about the Cairns meeting and possible conflict with TGn. Charles then asked if anyone had a significant issue with the outline that Fanny presented; he said that he was not going to ask for a straw poll, but that people who liked the outline should submit proposals using it. Pratik said that some of the more informative material would be useful to have in the draft for new people to come up to speed and so all this should be retained. This

Minutes page 12 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0304r0

led to a long discussion on the template and the content of the draft. Eric felt that the draft should be minimalist and should not include tutorial material. Tom explained that there was a balance between bare specification and tutorial material, and that the group would decide this over time.

Uri noted that we should use the reflector more, and Charles agreed. Tom agreed to send an initial request to the reflector for the definition of “channel” to start a discussion going.

Charles then brought up a motion to hold teleconferences. Gerard offered to set up a SIP server for the group.

Motion #3: Move to empower TGT to hold teleconferences on Thursdays at 12.00 noon Eastern time for 1 hour starting on March 24 2005.

M: Mark Kobayashi S: Michael Foegelle

Mark Kobayashi called the question. There was no objection so the question was called. Y: 15 N: 0 A: 0

Motion #4: Move to adjourn.

M: Tom Alexander S: Michael Foegelle Passed by acclamation.

The meeting was adjourned at 1730 EST.

Minutes page 13 Tom Alexander, VeriWave

March 2005 doc.: IEEE 802.11-05/0316r0

IEEE P802.11 Wireless LANs

TGu Minutes for March 2005 Session

Date: 2005-03-18

Author(s): Name Company Address Phone email BLK1022 TaiSeng Ave #06- Cheng Hong Panasonic 3530 +65-65505477 [email protected] Singapore 534415

Abstract This is the draft minutes for the IEEE802.11 TGu sessions of IEEE802.11 plenary meeting during the week of 14th – 18th March 2005 at Atlanta, GA.

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 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Executive Summary:

Documents discussed: 1. Agenda of the TGu session (05/152r3) 2. Last meeting minutes (04/097r0) 3. Report of last WIEN session (04/085r2) 4. Terminology for TGu (05/1619r0) 5. Assumptions, scenarios and scope (05/092r0) 6. Technical Requirement (05/279r1) 7. Session MAC address and anonymity (05/170r0) 8. 3GPP technical requirement (05/141r2) 9. 3GPP operator’s requirement (05/160r0) 10. WiFi alliance WLAN requirement (05/195r0) 11. Draft response to IAB link indication ID (05/283r0)

- Two future teleconferences were approved for requirement document drafting

1. Monday Afternoon Session: (14th March 2005, 1600 – 1800)

1.1 Meeting called to order by the chair at 1600

1.2 Review of the IEEE 802 and IEEE 802.11 policies & procedures (05/152r3) Chair went through the policies and procedures. The chair went through the patent ruling from PatCom.

1.3 Approval of the last meeting minutes (05/097r0) The minutes were approved with unanimous consent

1.4 Approval of Agenda (05/152r3) A new 802.21 joint ad-hoc session is added to Tuesday afternoon.

Question: Will the drafting of the requirement document done in the meeting time, or offline? Stephen (chair): Will be done during the meeting hours. It is a working item for the Thursday slots. Stephen (chair): A skeleton for the requirement document is available from the Jan meeting.

Question: Drafting of liaison (LS) to other groups was discussed in last meeting. We should think about that. Stephen (chair): Will work that on Thursday and add it to the agenda.

The modified agenda is approved with unanimous consent

1.5 Review of last TGu session (05/085r2) Chair went through the closing report for last TGu session

Question: Are we going to review the timeline plan this time? Stephen (chair) Yes. Will review it (05/049r0).

The chair went through the preliminary timeline. Will review the actual dates on Thursday.

Submission page 2 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

1. 6 Approval of Teleconference Minutes

1.6.1 February Teleconference Minutes (05/0127r1) Stephen (chair): The question regarding a new recommended practice was discussed. What is the group’s opinion? Comment: General rule should be one document per task group (TG). Comment: It will become clearer after we have done the requirements document. Stephen (chair): Yes. Will start with the scenario doc, and from there we will draw the formal requirements, and then decide if we need to amend the 802.11 standard. The requirement document could be the document we send as LS to external bodies, e.g. 3GPP, 3GPP2. Comment: We now have quite a lot issues listed. After we done the requirements draft, and if we found there are things that doesn’t require amendments to the MAC, could be worked out in a new study group (SG) or somewhere else. Comment: It is more proper for the TG to generate a PAR for a new SG. Stephen (chair): This could be a good way. Try to avoid losing some higher layer stuff that may not fall in the 802.11 scope. Will talk to WG chair regarding this. Comment: May not be good to have two groups work on the same/similar issue. It could be good to have an internal doc, e.g. arch doc in the group and document some assumptions, and then decide what to go along with. Stephen (chair): will discuss that later.

The minutes were approved by unanimous consent.

1.6.2 March Teleconference minutes (05/0147r0) Sabine will give an update of the presentation given during this teleconference. Questions were raised in the teleconference regarding “charging” to be in scope of TGu. Comment: Maybe will rephrase charging to billing Comment: Billing is a wrong word in operator’s language. Comment: Yes. Billing information collection could be better. Stephen: To have that clarified in the terminology document

Action Point: * Stephen (chair) Will clarify the term previous known as "charging" in the terminology document.

The minutes were approved by unanimous consent.

1.8 Requirement document

1.8.1 Chair presented a template for the requirement document

Question: How does this doc constrains the proposal? Does the proposal need to meet the requirements? Stephen (chair): Yes. Will go on to define the selection criteria after finished this. That process will define how to make use of the document to do selection Comment: It is not the chair decides if the proposal meets the requirement. It is the group who decides. This will be a hint to the proposers. Comment: Which means we may see some proposals that may contain something not listed here? Comment: Yes.

Submission page 3 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Stephen (chair): Will finish the scenarios doc/assumption doc, then will populate details here.

Stephen (chair): The requirements doc can capture requirements that are out of scope of the PAR, as long as they are marked “out of scope”. Comment: It is for the group to then express that they don't want to work on them.

Question: Can things be approved step by step, so that issues will not come back again? Comment: In TGs, they are doing that. But there is no way to stop people bringing motions to change anything later. Stephen (chair): Yes. For a draft, we don’t need motions to change anything. But it is too earlier to approve anything yet.

1.8.2 The chair went through the scenario doc template:

In the annex includes earlier presentations about the requirements.

Question: About the 3G scenarios, there are two groups working on it: GAN and WLAN. GAN will implement UMA, WLAN is working on loose coupling. Which are we working on here? Comment: the UMA is to work for access technology. It is likely that we will not see any requirements on WLAN technology from this group. Stephen (chair): Most requirements from UMA may be for 802.21 Stephen (chair): Loose coupling is in scope. We will look at the 3G doc and see what is there, and if it affects 802.11 technology and requirements any changes. Comment: The submitted presentation is about the 3GPP loose coupling.

Document 05/1584r1 contains a list of documents presented within 802.11 WNG and also the WIEN SG (Wireless Interworking with External Networks Study Group), which would be useful to review at some point (perhaps at the Cairns meeting).

Comment: It mentioned about forming ad hoc groups. We could form ad hoc groups after presenting the requirements from 3GPP/2, etc. and work on those requirements. Stephen (chair): We could draft in ad hoc, and still need to come back and approve it. Comment: We could start putting things together informally. Stephen (chair): We could do that in the ad hoc mode on Tuesday and Thursday Question: Is it within the session time or outside? Stephen (chair): Usually in the session time.

1.9 Editor nomination Two editors were needed, for the Draft Scenario Document and Draft Requirements Document respectively.

Mike Moreton volunteers to serve as the editor for the Draft Requirements Document. Sabine Demel volunteers to serve as the editor for the Draft Scenario Document.

1.10 Liaison Issues

Sabine Demel volunteers to be an 802.11 LS officer to 3GPP. Her nomination will be raised at the WG mid-week plenary for approval.

Sabine: There are lots of sub-groups in 3GPP. Will only attend some sub-groups. But, will convey LS between 3GPP and IEEE.

Submission page 4 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Stephen (chair): SA2 is the main group handling the WLAN interworking issues.

1.11 Open issues review (05/152r3)

Comment: The requirement of network selection will be mentioned in the 3GPP requirement presentation. Stephen: Then, leave it to the presentation time.

Stephen (chair): Will leave the secure portal page discussion to the WiFi requirement presentation.

Stephen (chair): The MAC address anonymity will be left to the new presentation slot to discussion.

Comment: When we do the presentation, we should formalize the requirements afterwards. Stephen (chair): Could stop after each presentation and note down the requirements derived.

Comment: The policy requirement is from the 3GPP requirement Question: What is the example of such a policy? Comment: Network only wants to see traffic from authorized user. Network could send some authorization information, and enforce it. Stephen (chair): Is that only packet filtering? Is that L2 or L3? Comment: It could be L2 or L3 Stephen (chair): If it is L2, we will do it. If it is L3, it is out of scope Comment: It is not defined Comment: It doesn't matter. It is about DS. We should not be concerned about that

Question: Are we talking about AP or access network? Stephen: APF ad hoc is working on that. We can make use some of the output Question: Should we dealing with distribution?

Stephen: So, even there are requirements on L2, we may not work on it Comment: At this stage, before CAPWAP finish its work, we still work on them, assuming the AP as a whole. Comment: CAPWAP is not changing IEEE standards.

Dorothy: APF is clarifying the terms to use in the doc. When this group talking about interface to outside, we need to be sure about the terms used. Are we talking about the AP function in the box or the station function in the box? Stephen: Would you recommend that we get familiar with the work of APF? Dorothy: You will have to, at some point in the future. Stephen: Could someone from your group present on your output? Dorothy: Will depends on the output from wed. If the TGm accepts those changes, all the members here will need to review those changes. Stephen: Will TGu be aware of those changes Comment: APF is not proposing any changes. Just clarification.

Comment: Will bring QoS issue up in the presentation of the 3GPP operator requirements Comment: It is not about authentication. It is more about setting up the TSPEC. Stephen: There are two separate issues here: The mapping, and the admission control. Comment: It came from the two points, and the group decided to merge them..

Comment: Not sure how 3G could map that. Stephen: Will have to do some translation. Comment: Not seeing 3G QoS to be map to WLAN.

Submission page 5 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Comment: Not sure it should be excluded at this stage. We could look at it if there is anyone else is doing it. If there are others doing it, we should work on that. Comment: The point is not talking about mapping 3G QoS to WLAN, but more of how WLAN provide a QoS control interface to outside world. Comment: Is that 3G has already have mapping to the WLAN? Comment: Not seeing that existing in 802.11 Stephen: Is that in the 3G requirement presentation? Comment: That is not the 3G requirement, more of individual contributor’s views Comment: If we working on 3G mapping, we have to work on other layer 3 (L3) issues also. Stephen: Probably more for the control, not for how the mapping is done.

Comment: QoS mapping is more of priority. Admission control is of control Comment: Admission control is one of the requirements to achieve QoS from external network. Comment: QoS may be more than simply priority. E.g. for the same AC if the other parameters, e.g. Cmin, Cmax, are different, the result will be different also.

Comment: Should have a clarification. How the charging is done. Is that standardized? Stephen: We need to ask if we want to standardize that, or it is implementation specific, or, just left to the network side. This is an operator requirement for the technology. Comment: Not sure how we can do it here? Stephen: Are we starting seeing AP generating charging info now? If it is yes, the question is do we want to standardize it? Comment: It is also relates to the QoS. Since charging also relates to QoS Stephen: Is it in TGv? Comments: It goes to 802.1 Stephen: Would like to have a joint session with 802.1 about the issue. If there is a generic solution we may still need to have a wireless specific solution.

Comment: Is the tutorial (4G) addressing this? Comment: Should we ask WiFi if there have anything to say? Stephen: Yes. Will write down some formal requirements and will sent that out to external bodies. Will also sent to WiFi, and get their opinion.

Stefano: Will do a presentation about that (AR ID). This may belong to 802.21, but it still needs to be done here to have specific transport. Comment: It also falls into TGr, but they are still calling for proposals. Comment: 802.11r dropped it since it is out of their scope, since they don't need to care about L3. 802.11r cannot handle it.

The meeting recessed for dinner.

2. Monday Evening Session (14th March 2005, 1930 - 2130)

Meeting is called to order at 19:35.

2.12 Session MAC address for Anonymity (05/170r0) Jon Edney

Comment: it doesn't solve the other problem (probing) Jon: For anonymous service, it could be done at other layer. If the service and authentication can be separated, then you need this. Otherwise you don’t need it. Submission page 6 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Comment: Outside of the distribution system (DS), the actual MAC address is still known. Jon: Yes. If you want to protect the router, then the conversion will be moved to the router Comment: If that is moved to the router, it means the MAC address needs to be unique within a larger domain. Jon: It is concentrating at providing protection at the wireless link. For extending it to the network, you need to consider more issues.

Jon: It is also mentioned in TGp Stephen: Will we need any liaison with TGp? Jon: There is some work done there, but not sure if they understand the issue. May not need a joint session, but could ask the question to them Comment: TGp is to do something at higher layer. They have some different problem space.

Comment: Some thing from DNA, binding of the IP address, may also need some protection. Jon: Sometimes the MAC address is stored in the AAA with the credentials. That will impact this scheme. The AP would know the MAC address. Comment: Could configure the RADIUS server not to use that address. Jon: Yes. That is more of an application issue

Comment: 3GPP also has the MAC address sent to the AAA sever. Jon: Depends on how that is put in the message. This solution is a problem if the MAC address is taken at the AP Comment: Can it be extended into the ESS? Jon: Had that in previous proposals, but it may have issue of ensuring the uniqueness. To have the BSS do conversion will take away that issue.

Straw Poll: Whether you think this present should have requirements abstracted regarding the MAC anonymity for TGu? Result: (Yes-no-abstain) 12-2-13

Jon/Stefano will write requirements out of that and submit to Mike Moreton.

Comment: For IPv6, will they solve it? Stefano: Do they connect to the MAC? We have the same problem

The session recessed until Tuesday afternoon.

3. Tuesday Afternoon Session: (15th March 2005, 1600 – 1800 ) Meeting call to order by the chair at 1600. There is an ad hoc joint session with 802.21 (from 1600 – 1700)

3.13 IETF Draft Review (Ad hoc joint session with 802.21)

Comment: Big difference between definition of link in IETF and IEEE. IETF is for a connection; IEEE is an association between stations. That diff should be described in the doc. Comment: The link in IETF is defined as the area could be reach by a link local or all nodes broadcast. Stephen (chair): Is this a comment we want to write down to sent to IETF? Comment: potentially. Stephen (chair): Will write this down and come back to this later.

Submission page 7 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Comment: This draft is most for the routing. What part the doc is applicable to us?

Comment: For a link up indication, the draft handles it as a link for a good connection. But it should have a link available indication. And that is not in the draft. It could be a result of a new services offered in a new network.

Comment: Should be careful about the link up. IETF's link up is that there is a valid network configuration (you can use IP on top of that link), which is diff from ours.

Comment: About link quality presentation. Wireless Link is different from that of 802.3. Wired doesn't need the on or off. This document about the L3 on and off is different. Suggest coming up with different terms.

Comment: How much value is it for application when we provide link up and down? Link quality is more important than physical link up or down. Comment: Cost is also important. For a smart terminal, what link up or down mean maybe different from physical up or down.

Comment: If only handover one session onto a link. It is diff from the link up or down Comment: When move the session on that link, how you make the decision? That is based on application. It is not just link up or down. How I make sure it is a good link I moved to? Comment: Could have a more soft term... link looks good... Comment: Or, link poll... could be relevant than link up or down. Link up or down is more of the PHY layer info. May not be needed by the application. Comment: Yes. The link up and down probably is a too simplified concept

Ajay (.21 chair): Link up or down could be composite trigger that includes more info than the status of the link at that point of time, e.g. PHY layer info.

Diagram (figure 1) ------

Comment: There is major difference about the link we are describing. In this link up or down, is that all the link gone down? There may be several segments (from MT to router). For IEEE, it is just one hop. Stephen (chair): Could feedback to IETF.

Comment: Most handover depends on detection if a AP is gone away. Would not wrap the rest of the network into it. Comment: There are other situations. Certainly, there is need to ask for clarification Stephen (chair): Capture that and ask for clarification

Stephen (chair): have a list of issues mentioned, and run through it see if we want to response to that

Last paragraph before the figure 1------

Comment: Does it mean that a different link up and down? The IP beyond the point is not changing. It could be useful, e.g. for TCP control...Some info could be captured... e.g. link up in this section Comment: They talk about layering... Do we have ideas about l2 to l3 interfaces..? We can get the info here. Comment: DNA chair suggests that all info to be pass to L3... This paper also propose that.. L3 insulates upper layer from lower layer. In 802.21 we are proposing take some of that burden. Some dialog could be good Submission page 8 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Comment: Yes. Someone has to take up that job. We also need to understand what the upper layer needs

Comment: Here the Link down follows a link up should be interpreted as not congestion. Why do we want to isolate from this information. Or, are we just trying to make this more informative to the upper layer? Comment: In some sense. Layering is autonomous Comment: we want to say that some info is useful for the transport? Is that the message here? Comment: Not think that is the message. There could be two models... everyone goes to the link and get the info. The other is that someone gets the info and understand what upper layer wants, and pass that.. This is what we are trying to do here.

Comment: Don't have to call L2 and L3 link both link. Could use some other name.

Comment: Link is to provide service to the next layer up. If there is a L2 between bridges down, no way to have that known.. Need something to inform the ends (LLC is not at there)

Stephen (chair): Can this be draft as a 802.21 LS to IETF, since more comments are 802.21 related? Michael (.21 chair): It is up for the 802.11u to provide the link normalization...

Comment: the later part of draft saying that if you don't have understanding of the info ... don't use it. Stephen (chair): Will capture that, and come back with draft LS letter on Thursday joint session.

3.14 3GPP technical requirements on WLAN AN (05/141r2) Sabine Demel

Comment: It is an individual submission. Stephen (chair): Will analysis this and draft requirements and sent to 3GPP/2 and ask for comments

Question: If you know your service provider, does it means you can have access of 3GPP services? Sabine: No. There are different subscriptions. Question: So there will be service authentication? Sabine: Yes. That is a specific requirement of 3GPP.

Question: Is the current 3GPP solution based on IP address filtering for the DoS attack avoidance? Sabine: Yes.

Stephen (chair): Will take the reference list of the doc to the end of the requirement doc.

Action Point: * Stephen (chair) will add that list of documents in agenda for Cairns, and review them.

3.15 3GPP operator’s requirements (05/160r0) Sabine Demel

Question: Not to use EAP for network selection is for the timing concerns? Sabine: There is a requirement to do it at a earlier stage. Not need to go through authentication.

Submission page 9 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Sabine: There should be a way for translating the info so the MT can read it. Question: Could it do a probe for a MT to specify a preferred one? Sabine: It can be done. There are diff procedures defined in 3GPP. Question: Can the MT specify an operator? Sabine: User should not be allowed to specify other network in his home network. If he is in foreign network, it is OK.

Comment: Is this pre-association? Sabine: It is intent to be before authentication Comment: So it has to be done at L2 Sabine: The current solution is just a trick...we prefer some clean solution Question: Is that to have info in the beacon? Sabine: Prefer it to be done at a earlier stage... Comment: The issue is whether we want to broaden the requirements

Comment: For cellular, some operators only can provide half service. It would be a good to have the info (about whether the service is fully available) to the user. Sabine: That is the level of interworking that would help for the MT to decide interworking

Question: Have you looked at UMA? Comment: Yes. The UMA is media independent. Therefore, it is out of scope. There is no requirement from UMA that affects the specific technology beneath.

Question: UMA is just using tunneling. It is waste of bandwidth. Stephen (chair): Currently, no requirements from UMA.

Comment: Battery life also affected by number of beacons you receive. Comment: in CIF mode, you need much more power to receive frames. Stephen (chair): Can redirect that to 802.11k. Comment: It is a general requirement.

Comment: virtual AP is also worth discussion, due to the scalability issue. Stephen (chair): Will cover that in the WiFi requirement.

Requirement changed online, and sent to Mike later. Session recessed for dinner.

4. Tuesday evening Session: (15th March 2005, 1930 - 2130)

4.15 - Continue of the discussion for 3GPP operator’s requirement

Question: What about the equivalent of TGe TSPEC? Question: We can decide the QoS is a scope for us.. But don't think that is a requirement from 3GPP Sabine: this is more of an operator's point of view. Comment: 3G has look at this earlier, and feel that it is 802.11 stuff, and don’t want to touch that.

Comment: It was discussed about 3G interacts with the admission control. Sabine: Actual there is no mechanism design how to interface AAA to the AP...AAA knows user profile and we have generate charging based on that... this is from AP interfacing to AAA Question: Who knows the MAC address? Does it go deeper into network? Sabine: In 3GPP AAA knows the MAC address, there is always opportunity to bind it. Submission page 10 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Comment: It that SIM based? Sabine: In WLAN access network, it is not to bind to 3GPP identity. It is for the 3GPP access network. Comment: With 802.11i, it doesn't bind authentication to the MAC address... there is possibility that other people authenticated and use your MAC address.. Sabine: For user access Internet service, user drop out, and others could make use of your address. For scenarios where user access 3G service, 3GPP will filter user traffic and use tunnels. If the user doesn't have a right key, it will be dropped. If the MAC is use at the same hotspot, is there a conflict? Comment: Depends. MAC is unique only within the local domain limited by 802.1

Comment: It could an issue for the billing.

Action Point: Put the RADIUS issue in the requirement assumption section

Sabine; it is very 3GPP specific. We may want to rephrase it. Comment: it is OK. When we review other requirements, we could come up with general requirement Sabine: Should note that the requirement is from operator, not from 3GPP.

Question: In the RADIUS, is there are already fields for QoS provided? Sabine: Could be done by 3GPP RADIUS...we are more looking at how to filling the info. Question: The consequence is that probably also provide info about what QoS you get (besides what u offer). Sabine: will check further... Question: What you granted may not be what you received. Sabine: We charge for what you request. Comment: That is correct since you pay for what you rights to request/reserve. Comment: You should pay for what you get. It is not difficult to based on MAC to count

Sabine will provide some requirements later.

Comment: Is this routing enforcement a requirement for WLAN? It is not what the AP does Comment: it is worth to have a document to say this is how we assume how the system works...then we can decide if it is out of scope. Comment: we are doing coarse level of requirement gathering now. Comment: Do we want to state what this requirement requires us to do? Comment: We are at quite earlier stage, and we are having the classifying thing to indicate it is in scope or out of scope. Comment: Is this related to the MAC address anonymity? Comment: It is still supported, since it binds to the session MAC address. Sabine: This is more for the access the Internet. Comment: It is still have DOS for the PDG for the 3G access case.

4.16 3GPP2 Requirements – Stefano (05/200r0)

Stefano: The requirements from Sabine cover both 3GPP and 3GPP2.

Sabine will email the document to Stefano for update and sent to Mike later.

4.17 WiFi Alliance Requirements for Public Access (05/195r0) Eleanor Hepworth

Submission page 11 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Question: Do we think it will still use UAM in the future? Eleanor: Will migrate all to WPA, but now, they co-exist. Question: Is that just to recognize that protected bit? Comment: Would like to ask the user. Question: Isn't just a user interface issue? Comment: It also doesn't specify what authentication mechanism you support.. That may also be needed Comment: It is back to the roaming agreement.

If have an 802.11i only hotspot. how a user to get those info to sign up (e.g. to get credit card info) Stephen: Is that a issue for TGw? Comment: They only work on management frame Stephen: then that will be a requirement for TGu Eleanor: Would see operator’s view on that. Question: Could do virtual AP to do that. Eleanor: Could do something better... Comment: if 802.11i provides bootstrapping, then no need to look at it Comment: Hotspot wants to control

Comment: It is not a issue for 3GPP users.

Comment: Not sure how big the gap is there for the UMA and 802.11i transition. Comment: It may not relate to the roaming issue. It is more to get the user on board with PKI or PGP Comment: Could do the scratch card for the coffee shop access. Comment: Could do that out band...

Question: The current standard is that with same SSID you cannot have both secure and insecure access at the same time. There are different ways to build a solution...Depends on what kind of money u want to spend on that.

Question: Could also change the client for access? (The MAC address)

Comment: If you have pre-association solution. Will it solve it? Eleanor: but you also have the limitation, e.g. scalability..

Question: Does WiFi require VLAN technique..? Eleanor: They recommend it.. (not requiring)

Stephen (chair) has ask the question about the virtual AP to the WiFi, the answer is that it is only for the separation of WPA and UAM...not for the multiple operators case.

Sabine will compile a list of the assumptions in a document.

Virtual AP issues should also go to the requirements draft.

Sabine: is the assumptions divided for groups, e.g. 3GPP, WiFi, etc. Stephen: Should be general for all the network Sabine: then it should be in the requirement draft. Stephen: Revisit that on Thursday

Submission page 12 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

5. Thursday Morning Session: (17th March 2005, 0800- 1000)

5.18 Documents Review

5.18.1 Terminology and definition document (05/1619r0)

Comment: We have discussed it. Stephen (chair): Yes. Comment: Do we just added text to it? Or call for contribution for it? Stephen: We just added to it. It is not matured yet.

Action Point: Stephen: check the status of the document on the server, and post the result in the mailing list

5.18.2 Scenario Document (05/092r0)

Stephen (chair): Is this a sort of doc we want Comment: We just stick to this, and can it change later. Stephen (chair): we can move some assumptions we identified on Tue to this doc

Will be upload to the server later today. Sabine will be the editor for this document

Sabine: Have we decided anything to put in? Stephen (chair): We have identified some from Tue, and will invite people to input. Also may put in the 3GPP/2, and WiFi assumptions into that, the presentations could be in the annex.

5.18.3 Requirement Document (05/279r1)

Comment: On 3GPP requirement, some of the things are not really directly out of 3G document, e.g. QoS needs not to be marked as 3GPP

Question: Where does the WiFi requirement come from? Comment: it is also an individual input Stephen (chair): we will sent our requirements to all the external body to comment after we capture all the points

Stephen (chair): How should the comments to be handled? Mike: To send email to the mailing list. If things could not be agreed by consensus, will have to do adoption vote

Question: The requirement only from WiFi, 3GPP/2? Comment: So far, yes. We can add in others, if new things come up. Question: Certification of AP could be useful .e.g. AP is using SSID, but it doesn't mean too much. ...certification of the AP could help the MT to decide which is the correct one to connect to. Stephen (chair): Is this a network detection issue? Mike: It will be noted down, and go through that again later. Submission page 13 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Mike will update the draft and upload later.

5.19 Review of DNA Draft Link-layer Event Notifications for Detecting Network Attachments - http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt

Eric provided a short presentation on the draft (Document will be uploaded to the server later)

Stephen (chair): Does 802.11 need to provide you those missing part shown in the doc as hint? Nicolas: Yes. Eric: In Bernard’s draft, there are different situations, where you have a link up but you still cannot use the link since the IP is not set up. This draft is to address that issue. It is to define how to make use of the link info to decide... it relates to this group that how the link info be prepared Stephen (chair): Are you asking how the 802.11 tech could help? Nicolas: IETF to define info needed , and 802.11 to transport Comment: Wrong layer to do that. Actually needed is a L2 identifier that can tell if you are still the on the same L2 link. What you want is a L2 id, not L3. Eric: Yes. Comment: VLAN is able to provide info (ID) to use to identify if it is still a L2. It should be what L2 is doing. Stephen (chair): Can we have this in our requirement draft? Comment: Yes. Eric: We have identified a few hints from 802.11.

Stephen (chair): should we as TGu write a LS to DNA? Comment: TGr should be doing this. It is to do with fast roaming not the external network. If TGr is not going to it then we will do it. Stephen (chair): TGr has looked at ARID draft, and concluded that we should do it. Comment: This problem is slightly diff from the solution they have reviewed (ARID) Stephen (chair): Will put this in the requirement and check with TGr.

Eric: Need to talk to DNA chair to decide what the LS should be Stephen: Will not create LS this time, will review DNA's activities first Comment: Once decided which TG should deal with this issue, then we could decide to draft the LS.

Session recessed till 1030

6. Thursday Morning Session: (17th March 2005, 1030- 1230)

6.20 Response to the IAB draft (05/283r0) Joint session with 802.21

Dorothy: Bernard is the LS officer from IETF to IEEE802.

Comment: There is no definition of link in IEEE. When the bridge inserted into the picture, it is not clear what the link is. Comment: the term link is overloaded. Comment: IEEE is L2 link, IETF is more of L3 link. For 802.11, it is more of wireless link.

Submission page 14 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Comment: Should be written down that there are multiple definitions of link and IETF should be aware of that. Dorothy: Not to use the term alone.. to use wireless link, IP link e.g. to be more specific

Comment: what does multiple hops mean? Multiple link or multiple elements?

Comment: If one of the L2 link down, 21 can switch to another link and keep the L2 on Stephen (chair): That is for the multiple mode terminal... should that be written down? Comment: Could use a link_changed indication besides link_down

Comment: Link up could be more than radio connection, e.g. LLC has been established.

Comment: DNA insulates upper layer from link at L3, here, we are doing the same at L2. Lots of comments made in the draft are comments are wired link are different from wireless link. Could be used by 802.21 to make wireless link to appear as wired link.

Comment: link quality should be handled in the heterogeneous environment.

Stephen (chair): Should we make any reference to 802.21 doc? Ajay (.21 chair): There is not formal 802.21 doc, only the requirement doc. Ajay (.21 chair): Why need to reference to those doc? Stephen (chair): For the external party to get info about the standards we are dealing with

Will have a teleconference about the draft at certain point of time before it is sent to IETF. .21 will announce that in the ML, and will be relayed to the 802.11u.

6.21 TGu Requirement draft review

Chair went through the working document about the requirement in 802.21

Comment: We have not voted on the document yet. It is just a working doc. Ajay: Is it available to 802.21? Stephen (chair): It is on the 802.11 server. Ajay: Can it be put in public domain? Comment: All the submissions are in the public domain, only drafts will be in private area.

.21 member could login the www.802wirelessworld.com site for document access.

6.22 Process document review (05/152r3)

The Timeline doc is (05/49r0). It will be discussed in the agenda item AOB later.

Stephen (chair): Any name suggestion for the scenarios doc? Comment: Assumptions, scenarios and scope doc

Functional requirement document is (05/279r0)

Selection criteria: to be drafted in July.

6.23 Teleconference requirements

Submission page 15 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Straw poll: Would you like to have ad hoc teleconference to discuss IETF IAB draft on 31st Mar at around 09:00 - 802.11:00am ET, which is the time that 802.21 have selected? Result: 4-2 (yes-no)

Stephen will talk to Ajay to confirm the date and time

TGU teleconference: suggestion: Wed, 4th May, 802.11:00 ET Question: it would be too late for Europe?

Straw poll: Among the members, who likely would join the teleconference? Result: US: 1 EU: 6 AS: 1

Move to 09:00 ET

To have another teleconference regarding technical requirement on Wed 20th April 04:00 ET.

Motion: Move to approve the following teleconference: - Wed 20th April 2005 04:00 ET - Wed 4th May 2005 09:00 ET

Mover: Eleanor Hepworth Seconded: Sabine Demel

Result: 8-0-2 (Yes-no-abstain)

6.24 Preparation of May meeting (05/301r0) A few items suggested for the next meeting: - Requirements review open issue list WIEN and TGu presentation TiSPAN, and other non-cellular system (spacewire, PDC) IETF requirements

- Liaison creation 3GPP 3GPP2

- Proposals to downselection

6.25 AOB - Timeline document (05/049r0) Call for proposal in July. Finish the requirement by then.

Comment: See the requirement finish until we received all the comments back from other groups.

Submission page 16 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0316r0

Stephen (chair): When new requirements come, we can modify the document. And the down selection criteria could be loose Comment: When get to the review process, we can receive comments, and accept those

Question: Would also send LS to WiFi and others? Stephen (chair): LS about the requirement will be sent to anyone that we felt relevant.

Timeline Document updated as 05/49r1

Motion: To approve the Timeline Document The document approved by unanimous consent.

TGu adjourned until May meeting.

Submission page 17 Cheng Hong, Panasonic

March 2005 doc.: IEEE 802.11-05/0219r0

IEEE P802.11 Wireless LANs

Minutes of TGv Meeting for January 2005

Date: 2005-1-17

Author(s): Name Company Address Phone email 110 Nortech Parkway +1 408-635- Pat R Calhoun Airespace [email protected] San Jose, CA 95134 2023

Abstract Task Group “v” minutes for the March 2005 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 Pat R Calhoun - Airespace

March 2005 doc.: IEEE 802.11-05/0219r0

Tuesday March 15, 2005, Atlanta, CA

Task Group V, 08:00-12:30 meeting

Meeting was called to order at 08:00.

Patent policy was read to the task group.

No agenda changes were requested. A motion was made to accept the agenda by Harry Worstell, seconded by Bob Miller. The motion was passed unanimously.

The chair discussed the current status of the task group. This session will be focused on gathering requirements.

A call was made for a permanent secretary. Bob Miller announced that he would be willing to take on that role once 802.11e is completed. No other candidates announced themselves.

A call was made for a technical editor. No volunteers for this position.

Richard Paine discussed document 11-03/0490r0, which was the use case scenario document that was used in 802.11k during its infancy. It was proposed that TGV use a similar format. No one volunteered to take on this task, so Pat Calhoun agreed to come up with the first pass at a template that would be filled in by the task group.

A discussion on requirements was lead by the chair. Many of the task group members volunteered various requirements, all of which can be found in document 11-05/0224r1. For every requirement, the chair attempted to find an “owner”, meaning someone that is willing to either donate some text, make a presentation to the group on the subject or lead a discussion on the topic. The requirements document includes the owners for every requirement.

A comment was made that a main goal is to provide extensions to the MAC/PHY layer to allow the infrastructure (AP) to control the station, for many different ways such as load balancing and RF configuration. The task group felt that while it is important to understand what the algorithms would be for any RF management, the task group should not define them.

Lars Falk discussed document 11-05/0169r0, which describes a set of operator requirements for 802.11 network management. All requirements not previously discussed have been noted in the TGV requirements document.

Mariam Rudolf presented document 11-05/0076r0, which lists possible services for TGV. Mariam discussed the highlights of the document, some of which were discussed in the requirements discussion. The goal of the document is to list a set of requirements, and specify which standard is responsible for every one of them (some of them are really 802.11k requirements).

Tatsuji Munaka presented document 11-05/0048r0, which describes use case scenarios for sensor overlay networks. This document discusses requirements for industrial automation. The group felt that the requirements in this document really should be discussed in 802.11s, but agreed that industrial automation should be listed in the TGv use case scenario document.

Pat Calhoun presented document 11-05/1595r0 on behalf of Rohan Mahy. Although this document was presented in Monterey, the group felt that this document should be presented again. The document describes two main topics; Network selection and auto enrollment. There was a long discussion about this document and its relevance to TGv. A straw poll showed that the group is not interested in pursuing the ideas in this document as they feel it is outside the scope of the TG (yes: 5, No: 6, Abstain: 0).

Security – there was a question on the floor as to what security issues exist in TGV, and whether Jesse’s group will be addressing all of the issues. One outstanding security related issue is one of policy, which is not being addressed by Jesse. Harry will be present at Jesse’s e-mail and will pose the question.

Submission page 2 Pat R Calhoun - Airespace

March 2005 doc.: IEEE 802.11-05/0219r0

The meeting was recessed until Thursday 08:00.

Pat R Calhoun - Acting Secretary

Tuesday March 15, 2005, Atlanta, CA

Task Group V, 08:00-12:30 meeting

Meeting was called to order at 08:00.

The meeting started by continuing the TGV requirements discussion, by identifying whether any requirements in document 11-05-0024 that did not have an owner was really a requirement. Volunteers were being identified for these sections, and discussions on these items occurred to identify that they were in fact a requirement.

A discussion around security entailed, whereby the group identified that configuration items to the client need to be categorized into “buckets”, where some items may be more sensitive to others. For instance, configuring a temporary transmit power setting on a station may be permitted at all times, while downloading firmware to a station may require a special policy, and may only be allowed under certain circumstances.

The group felt that a joint meeting with TGw would be desirable in the May session. The goal would be to present our current thoughts in terms of client control and configuration, and understand whether TGw could satisfy our needs (and to make them aware of our requirements).

Joe Kwak presented document 11-05/0280r1 which describes support for advanced antennas and techniques for TGv. This presentation stated that it would be desirable for TGv to define “configuration” extensions to allow for advanced antennas to be managed. There is a question as to whether this would be useful work, since TGn already defines antenna management. If this is an interim step between today and TGn, then by the time TGv is completed, this may become invalidated. Further, changing the PLCP on existing stations is not a simple thing to do. There is a question as to whether this may be useful between APs (for inter-AP communication). Perhaps we should wait until TGn is further down the road to make sure that these features are handled by TGn. There is a comment that parts of the presentation that modifies the PHY is probably out of scope of TGv, but the management components (e.g., beacon, probe) could be useful in TGv. If the goal is to change the PHY frame format, so we break backward compatibility, then it is felt that this is outside the scope of the task group.

There was a question in the task group as to whether TGv must put together a document of requirements for .19. Pat Calhoun will look into this.

The requirements document is expected to be finalized in the May session. The idea is that individual item owners will present their thoughts on each area, and the group will determine whether an area is a requirements or not. Items that are identified to be non-requirements will be moved to the non- requirements section. Individuals are encouraged to contribute even if their names are not assigned to an area. Items that have no owners are more likely to be dropped as a requirement. In the July timeframe, individual technical solutions would be solicited. It is important to note that the requirements document is a living document, so it is possible to add or remove requirements after the may meeting.

A comment was made that it would be necessary to identify whether a requirement is optional or mandatory. There is concern that if everything is optional, or if clear behaviour is not specified, then stations will be allowed to ignore messages create din TGv. It was also noted that the TG should be clear

Submission page 3 Pat R Calhoun - Airespace

March 2005 doc.: IEEE 802.11-05/0219r0 as to why a specific feature exists in the standard – eliminating the possibility to receive similar comments to those received in TGk.

Pat Calhoun will compile the usage scenarios, and a meeting slot will be dedicated to discussing this document. Veerma Anantha has agreed to help out with this document, and suggested we look at the TGs usage scenario document.

Meeting was adjourned at 12:07

Pat R Calhoun - Acting Secretary

Submission page 4 Pat R Calhoun - Airespace

March 2005 doc.: IEEE 802.11-05/0284r11

IEEE P802.11 Wireless LANs

Minutes of WNG March 2005 Session

Date: 2005-03-17

Author(s): Name Company Address Phone email Siemens Roke Manor Research, Eleanor Hepworth Roke +44 1794 833146 [email protected] Romsey, UK Manor

Abstract

Minutes of WNG SC meeting held during the IEEE 802 Plenary Session in Atlanta, GA from March 13th-18th, 2005.

Contents

Executive Summary...... 2 Morning Session Wednesday 08:00-10:00...... 2 Logistics ...... 2 3650-3700 MHz FCC Action: 11-05-0223r0, Peter Ecclesine...... 2 Usage of Timestamps in WLAN for Localization and other Applications: 11-05-0161r0, Stuart Golden ...... 3 Service Provider Requirements for 802.11n Detailed: 11-05-0109r4, Brian Ford...... 3 4G Neighbourhood Area Networks: 11-05-0173r1, Bob Miller ...... 4 Ambient Networks Scenario: 11-05-0157r0, Stephen McCann...... 4

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 Eleanor Hepworth, Siemens Roke Manor

March 2005 doc.: IEEE 802.11-05/0284r11

Executive Summary 1. 3650-3700 MHZ FCC Action: request to start a SG to investigate opportunities for IEEE 802.11 operation in this band. 2. Usage of Timestamps in WLAN for Localization and other Applications: discussion of how timestamps can be used to support determination of location in 802.11 networks. 3. Service Provider Requirements for 802.11n Detailed: describing service provider requirements on IEEE 802.11 technology to support subscriber services. 4. 4G Neighbourhood Area Networks: discussing whether a new concept of neighbourhood area network is required, and what the particular requirements of such a network would be. 5. Ambient Network Scenario: highlighting some of the concepts under development in the IST Ambient Networks project.

Morning Session Wednesday 08:00-10:00

Logistics

WNG Meeting called to order by TK Tan (Philips) at 08:00.

The objectives of the session and 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.

The agenda was reviewed (11-05-188r0), and a correction was requested by Peter Ecclesine to remove the 802.22 liaison from the agenda as this will presented in the IEEE 802.11 plenary instead. Modified agenda approved.

The minutes from the January 2005 meeting (11-05-0056r0) were reviewed. No comments were received.

Move to accept minutes; proposed TK Tan, seconded Peter Ecclesine, minutes approved.

3650-3700 MHz FCC Action: 11-05-0223r0, Peter Ecclesine The FCC has just opened up spectrum for wireless broadband in the 3650 to 3700 MHz band with minimal regulatory requirements. It was proposed that a study group be established to assess whether there is justification to form a task group to define an IEEE 802.11 standard for operation in this band. Usage of this ban has to co-exist with some high powered devices located geographically in continental USA. The FCC ruling forbids use of new devices in this band within a 75 mile radius of three prescribed locations. This work is analogous to that undertaken by TGj and the study group would be responsible for determining the impacts on IEEE 802.11, for example, co-channel sensing requirements and definition of a contention-based protocol.

Lars Falk: What are the high powered devices? Peter Ecclesine: Navy radars, the document has more details of what is protected and what is not.

TK Tan: When will the documentation be available on the FCC website? Peter Eccelsine: By the end of this week, and it would certainly be available by the time the SG would meet for the first time.

Bob Miller: is it possible to detach this work from specific bands? Peter Ecclesine: IEEE 802.11 tends to examine these opportunities as and when they become available, it is too much effort to go through all spectrums ourselves, the spectrum policy task force exists for this purpose. However, this type of work has been done in the past; for example in TGj, and the concepts are re-usable in this scenario.

Submission page 2 Eleanor Hepworth, Siemens Roke Manor

March 2005 doc.: IEEE 802.11-05/0284r11

Charles Wright: The only encumbants in this frequency band are those three stations mentioned in the document, but elsewhere we’d have to co-exist with the primary usage. Peter Ecclesine: We’d need to develop contention based protocols with an obligation to ensure that mobiles only operate when they hear a signal from fixed stations.

Motion: Move that the WNG SC recommends that the IEEE 802.11 WG form a study group to examine the opportunity afforded by the FCC Report and Order and Memorandum Opinion and Order (FCC 05- 56) with the intent to create a PAR and fiver criteria to form a new Task Group.

Moved: Peter Ecclesine Second: Charles Wright Result: 25, 0, 5

Usage of Timestamps in WLAN for Localization and other Applications: 11-05- 0161r0, Stuart Golden Presentation of how the use of timestamps could be used to enable location services in IEEE 802.11 networks. This would operate as a compliment to outdoor techniques, such as GPS, that do not operate well indoors. The methods available for providing this functionality were discussed, asserting that signal strength did not provide sufficient accuracy, and describing how timestamps can be used to provide TOA and TDOA approaches.

Pat Calhoun: It is useful for the infrastructure to have knowledge of client location, for example to handle malicious devices, and you can’t always trust the information the client tells you about its location. The proposal here places the emphasis on the client to determine its location, it there a way to support the infrastructure to calculate client location and pass the information back to the client.

Stuart Golden: Both applications are very important, and the notion of timestamp in this proposal is bi- directional. TDOA can be used by the infrastructure, but performance will be degraded. Could also employ TDOA for course estimates, and ask trusted clients for participation to get better accuracy.

Straw Poll: Is there interest in localization and/or a SG to investigate these issues. Results: 23,0,10

Service Provider Requirements for 802.11n Detailed: 11-05-0109r4, Brian Ford This was an expansion of two earlier presentations, one from the Monterey 2005 meeting, and one from the March 2005 session Monday evening tutorial on 4G Neighbourhood Area Networks. It essentially addresses the areas of the IEEE 802.11 standard that service providers perceive as weaknesses. The presentation is focussed on IEEE 802.11n as this standard is felt to be a key enabler for triple play services (voice, video, data). Areas of concern include QoS, management, rate versus reach, mobility and testability (including evaluation models). Scenarios involve multi-dwelling support with curb-side or pole mounted APs.

Peter Ecclesine: (slide 8) half or full duplex, i.e. 25 and 25 or just 25? Brian Ford: not specified, expected to be half duplex.

Haixiang He: What is the backhaul? Brian Ford: backhaul can be accomplished in a number of ways, fibre to the node or wireless backhaul (if there is sufficient capacity). This ties in with the neighbourhood areas network ideas to be presented by Bob (Miller).

Question from floor: earlier you stated that IEEE 802.11n was tied up doing other business, so are you waiting until the end of the down selection before approaching TGu with these requirements?

Submission page 3 Eleanor Hepworth, Siemens Roke Manor

March 2005 doc.: IEEE 802.11-05/0284r11

Brian Ford: we would like to work out what needs to be handled where, and what is outstanding. Possibly in WNG, possibly in a new SG or TG.

Andrew Myles: you are asking for a lot of performance guarantees. IEEE 802.11 typically operates in unlicensed bands with lots of interference. How are you planning of providing the sorts of guarantees in the type of environment. Brain Ford: unlicensed spectrum does make us very nervous, but we are using it only is small bubbles and that is a risk we are willing to take.

Fanny Mlinarsky: there are activities in TGT discussing requirements for these types of application. TGT would welcome any inputs on requirements for applications.

4G Neighbourhood Area Networks: 11-05-0173r1, Bob Miller Identified the need for a new networking area, neighbourhood area networks, where there is currently no wireless standard that is optimised for this environment. WLANs claim to extend to this distance, but is not really optimised for this range and outdoor environment. Would like some further investigation of this concept of NANs.

Peter Ecclesine: Until we have a standard with a PHY layer with mandated power levels adjustable for coverage and cyclic frequency protection we cannot use the spectrum efficiently. We need to put this functionality into the PHY standards to support automatic detection and adjustment so that apparatus does not interfere with each other, and get the regulators to change the rules when there are licensed and unlicensed equivalents. Bob Miller: agree with this, and also suggest that the problems are worse for mobile users. It is useful to compartmentalise the different network areas to gain ground with the FCC in a way that side steps power control, throughput and effective quality.

Stephen McCann: I would argue that the current work in 802.11, 802.16 and 802.21 are already starting to address this technical area. Where is the NAN going to fit in? Have we already missed this opportunity? Bob Miller: Agreed, and I gave a tutorial in 802 to try and spur the evolution of the technology. However, for reasons given in the last two slides, this issue has not been addressed yet.

Ambient Networks Scenario: 11-05-0157r0, Stephen McCann This presentation gave a brief introduction into some of the work being carried out by the EU funded 6th framework project Ambient Networks. The work of the group was illustrated through a short DVD highlighting an Ambient Network “” scenario, the storyline for which is summarised in this presentation.

TK: this brings us to the end of our WNG session for this meeting.

Move to adjourn, no objections, session adjourned.

Submission page 4 Eleanor Hepworth, Siemens Roke Manor

March 2005 doc.: IEEE 802.11-05/0323r0

IEEE P802.11 Wireless LANs

ADS Study Group Meeting Minutes March 2005 Session

Date: 2005-03-17

Author(s): Name Company Address Phone email Sandy LANL Los Alamos, NM 505-665-6820 [email protected] Turner

Minutes of the 802.11 ADS Study Group meeting held during the IEEE 802 March 2005 Plenary Session in Atlanta, GA from March 13th – 18th, 2005.

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 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0323r0

Wednesday, March 16, 2005 Call to Order Meeting called to order on Wednesday, March 16, 2005 by Dorothy Stanley at 8:03 am. Chair: Dorothy Stanley Secretary: Sandy Turner

Chair: Please take time to do attendance. Jesse Walker had a death in the family, and cannot be here this week.

Review IEEE 802 and 802.11 Policies and Procedures Chair showed the two slides requested by the WG chair: “IEEE SA Standards Board Bylaws on Patents in Standards” and “Inappropriate Topics for IEEE TG Meetings”.

Chair: Are there any questions?

None.

Agenda discussion Proposed Agenda (11-05/0198r1): • Call to Order • Review IEEE 802 and 802.11 Policies and Procedures – Review IP policy: “Slide 1” and “Slide 2” – Voting: All committee members may vote; 75% approval required – Attendance: Reminder to sign the electronic attendance form • Approve Agenda • Chair’s status • Wednesday 8:00-10:00am – Motion to Extend Study Group – Resolve Any Comments on the PAR & 5 Criteria – Presentations • 05/237 Fabrice Stevens – Requirements on Mgt Frame Protection (30 min) • 05/238 Fabrice Stevens – An 802.11i based proposal (15 min) • Thursday 1:30-3:30pm – Presentations • Adjourn

Chair: Let’s walk through the agenda.

Comment: Attendance is required for study groups.

Chair status Key points included: • There were no comments on the PAR & 5 Criteria • Two presentations each were added to the Agenda for Jon Edney with his suggested time durations and in an agreed upon order.

Chair: Any objections to adopting the agenda before you?

None.

Revised Agenda (11-05/0198r2): • Call to Order • Review IEEE 802 and 802.11 Policies and Procedures

Submission page 2 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0323r0

– Review IP policy: “Slide 1” and “Slide 2” – Voting: All committee members may vote; 75% approval required – Attendance: Reminder to sign the electronic attendance form • Approve Agenda • Chair’s status • Wednesday 8:00-10:00am – Motion to Extend Study Group – Resolve Any Comments on the PAR & 5 Criteria – Presentations • 05/237 Fabrice Stevens – Requirements on Mgt Frame Protection (30 min) • 05/139 Jon Edney – Which Management Frames need protection (30) • 05/238 Fabrice Stevens – An 802.11i based description (15 min) • 05/140 Jon Edney – Session MAC Address (30) • Thursday 1:30-3:30pm – Presentations – Emily Qi – 05/148r0 – TGw Planning • Adjourn

Chair: I have one slide on status (slide 7).

Comment: Does it go to Nescom on Friday?

Chair: The PAR and 5 Crieria go first to Excom on Friday and then to Nescom, which is meeting Sunday.

Comment: Nescom is meeting this weekend.

Motion to Extend Study Group Chair: Let’s talk about the motion to extend the life of the Study Group.

MOTION: Move to request that the IEEE 802.11 Working Group extend the ADS Study Group for an additional 6 months. Moved: Clint Chaplin Second: Nancy Cam-Winget

Chair: Any discussion on the motion?

None.

Chair: Let’s vote on the motion. This is a Study Group. All can vote. Motion Passes: Yes-14, No-0, Abstain-0

Presentations Requirements for Management Frame Protection Schemes - Fabrice Stevens, Sebastien Dure – doc 05/0237r0 Key points include: • (slide 5 “Overall design goals”) IBSS was included as an observation, not for a specific reason. • (slide 10 “Data origin authentication 3/3”) “Assume that EAP methods will bring explicit AP authentication” refers to the trust relationship between the AP and the AS. For example: the AP says Service Provider A. Service Provider B does not know about it. • (slide 11 “Confidentiality”) There was discussion on whether location information requires confidentiality or not. Comments included: o If you can do the measurements yourself, confidentiality would not be required.

Submission page 3 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0323r0

o What advantage do you gain from location information? o TGk had asked for this protection. o Internal networks might not require this protection. o TGv may have needs. o Maybe we should provide two protection mechanisms – one with confidentiality, one without. o Whether you encrypt or not, there should be no change to the key structure or the negotiation of the security relationship. • (slide 12 “Replay protection”) Jon Edney gave some history of this group. Originally, TGk attempted to do a protection. One proposal was to protect the whole frame, while the another proposal was to just protect the IE. An objection to the per-IE approach was the difficulty in ensuring the ordering of IEs. He felt it was still worth looking at this distinction. • (slide 18 “Needs for 802.11k frames”) Comments included: o Requests place demands on resources, which is another type of DoS attack. o Some APs are turned into constant measurement devices – like a sniffer. o Is it the work of this group to decide which TGk frames to protect? Or should the protection be generic to categories of management frames (e.g. Action Frames) and then other groups (e.g. TGs) can make use of it as well.

Chair: Are there any other questions?

None.

Which Management Frames Need Protection? – Jon Edney – doc 05/0139r0 Key points include: • Jon felt one difference between his and Fabrice’s presentation was he treated the action frame as opaque and didn’t look inside the frame. • (slide 6 “Issues with protecting Discover Group”) Comments included: o Why is replay important? Typically most information in the beacons stays consistent. o Some schemes put information in the beacons, such as moving counter information. o Timers can be used for replay protection. • (slide 8 “Protecting Access Messages”) Comments included: o Deauthentication/disassociation attacks can be caused by the following: ƒ Internet tools ƒ Some products send these messages on purpose to rogue APs ƒ Misconfigurations • (slide 10 “Summary of Mandatory Protections”) Comments included: o Association/reassociation requests are hard to protect since there are no keys in place. We can leverage off TGr’s work with providing protection for these messages. Jon Edney assumed TGr will eventually be used everywhere. o TGi had rejected an idea to put more than the RSN IE in Messages 2 and 3 of the 4way handshake. Maybe we can now leverage off the TGr JIT proposal’s RIC container to include more information.

Comment: When do we do general requirements?

Chair: The group needs to decide the next steps and work items. The typical process is general requirements, call for proposals and evaluation requirements. Kapil said Emily will be here on Thursday. Is there any objection to putting Emily’s presentation on the agenda for Thursday?

None.

Submission page 4 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0323r0

Chair: Do you have a number for the document?

Comment: I’m waiting on that.

Chair: I’d like to remind people to do the attendance server sign in and the attendance sheet. Next presentation is 0238r0, Fabrice.

PMF, take one A simple 802.11i extension - Fabrice Stevens, Sebastien Dure – doc 05/0238r0 Key points include: • This is a simple 802.11i extension, not a proposal. • Short recess for a new projector. • This is only post-11i. Pre-11i has a lot of work to do. • Management frames can be protected the same way you do data frames (reference proposals 04/482r1, 05/148r0).

Chair: Any other questions on this presentation?

None.

Session MAC Address Solves Deadlocks – Jon Edney – doc 05/0140r0 Key points include: • This is not a proposal. It was presented in TGu. • There are issues with 11i. The STA’s real MAC is used as the identity to bind both the PMK-SA and the PTK-SA. The PMK-SA is defined by the station and BSSID MAC addresses. If the AP only knows the session MAC and the real MAC after authentication, it’s a question of timing. Jon Edney and Nancy Cam-Winget were going to sit down with a piece of paper and step through this process after the meeting. • If the AP reboots, it’s not a problem since the STA can reassociate with a new session MAC. • The STA can detect a reboot if it transmits frames and does not get any response (although this could be a long time – 15 minutes). You could possibly force the STA to re-establish the SA sooner. • Jon Edney wasn’t sure of the details for pre-authentication. He was suggesting that the PMKID, which binds the STA MAC address, would use the real MAC address of the STA - not the session address. This is because when it is cached and the STA returns, the session ID would be different. When the STA returned, it would advertise the PMKID it has and then proceed with the 4-way handshake using the session ID. This would only suceed if the STA had the real PMK. Nancy Cam-Winget and Jon were going to look into this in more detail. • Developers and testers will hate this. People memorize MACs when debugging. The same argument can be made for TGi, in which you can’t see the IP address in the packet because it’s encrypted. You pay a price for protection. Administrators could give a STA a range of 20 MACs. • When TGp looked at MAC address allocation, the RAC had a concern about duplicate addresses. TGp looked into not remembering MACs in NVRAM between reboots and falling back to random starting points, but this still did not address the RAC’s concerns.

Chair: Any other questions for Jon?

None.

Chair: The next session is Thursday from 1:30-3:30. We will have Emily’s presentation and TGw planning (slide 4) – requirements, time frame, authors, volunteers. One final reminder for electronic attendance. Is there any objection to recessing?

Submission page 5 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0323r0

None

Adjourn 9:57 am.

Thursday, March 17, 2005 Call to Order Meeting called to order on Thursday, March 17, 2005 by Dorothy Stanley at 1:30 pm.

Management Frame Protection – Emily Qi, Jesse Walker – doc 05/0148r0 Key points include: • A new feature from 04/0482r2, is replay protection (slide 13 “Replay Protection”). The receiver has a new receive counter for management frames. • If any management frame has zero data, there will be interoperability problems. • Legacy systems may not be looking at the protected bit. • We will have an issue with a single counter if we need finer resolution (e.g. subtypes, priorities).

Chair: A reminder to fill out the attendance sheet. Are there any other presentations?

None.

TGw Planning Chair: The only other item to talk about is planning for TGw (slide 4 “TGW Planning”). Is there a desire for teleconferences between now and May?

None.

Chair: Let’s open it up on how to proceed. • Jon Edney volunteered to put Fabrice’s presentation (05/0237r0) into text form. It will be available 2 weeks before the May meeting on the reflector. • The following timeline was negotiated and agreed upon:

ADS Study Group Agenda – Dorothy Stanley – doc 05/0198r3 slide 4 • Proposal Requirements Document – Timeframe – • Post to server with notice to the reflector 2 weeks prior to May meeting • Goal – adopt at May meeting – Authors – Jon Edney (base on 05/237) • Call for Proposals – Timeframe – May meeting (or when requirements doc approved) T – Submission of Proposal – Power-point summary = T+45 days – Submission of Proposal – Draft Text = (T+45) + 45 • Proposal Selection Process – Timeframe – Draft in May, Adopt in July • Presentation of Proposal text – After adoption of Selection process • Call for volunteers – – Permanent secretary - now – Editor TGw draft – Chair - now

Chair: Are there any other items of business that we have or people would like to discuss. I’ll entertain a motion to adjourn

Submission page 6 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0323r0

Moved: Clint Chaplin Second: Paul Lambert

Chair: Any objection to adjourning?

None.

Chair: Seeing no objections, we’re adjourned.

Adjourn 2:23pm

Attendees: Nancy Cam-Winget Fred Haisch Henry Ptasinski Clint Chaplin Paul Lambert Marian Rudolf Chris Durand Jia-ru Li Emily Qi Sebastien Dure Victor Lin Emek Sadot Dick Eckard Phil Mackenzie Kapil Sood Jon Edney Jouni Malinen Dorothy Stanley Joe Epstein Kelly McClellan Fabrice Stevens Lars Falk Mike Montemurro Sandy Turner Steve Fantashe Paul Newton Fujio Watanabe Nada Golme Paul Nguyen Zhonghui Yao Hrishikesh Gossain Paul Pamish Artur Zaks

Submission page 7 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0323r0

References:

Submission page 8 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

IEEE P802.11 Wireless LANs

Access Point Functionality Ad Hoc Meeting Minutes March 2005 Session

Date: 2005-03-15

Author(s): Name Company Address Phone email Sandy Turner LANL Los Alamos, NM 505-665-6820 [email protected]

Abstract Minutes of the 802.11 Access Point Functionality (APF) Ad Hoc Committee meetings held during the IEEE 802 March 2005 Plenary Session in Atlanta, GA from March 13th – 18th, 2005.

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 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

Tuesday, March 15, 2005 4:00 pm

Call to Order & Agreement on Agenda Meeting called to order on Tuesday, March 15, 2005 by Dorothy Stanley. Chair: Dorothy Stanley Secretary: Sandy Turner

Chair status Chair: Agenda discussion Proposed Agenda (11-05/0187r1):

• Call to Order • Review IEEE 802 and 802.11 Policies and Procedures – Review IP policy: “Slide 4” and “Slide 5” – Voting: All committee members may vote; 75% approval required – Attendance: Reminder to sign the electronic attendance form • Approve Agenda • Approve Meeting Minutes from conference calls – See 05/117 (Feb 3), 05/158 (Feb 16th), 05/202 (Mar 9th) • Chair’s status • Tuesday 4:00-6:00pm – 05/120 – Description of AP (60 min) – 04/1225 – AP Function Details (15 min) – 5:30 – 6:00pm – 05/240 -N. Finn – Generalized LAN Emulation • Tuesday 7:30-9:30pm – Request for 802.1 work (7:30pm) – 05/105,115 –Text errors and clarifications, DS Interfaces – 05/159 – Integration Function Description • Wednesday 1:30-3:30 – Presentations and Motions in TGm • Adjourn

Review IEEE 802 and 802.11 Policies and Procedures Chair showed the two slides requested by WG chair “IEEE SA Standards Board Bylaws on Patents in Standards” and “Inappropriate Topics for IEEE WG Meetings”.

Chair: Are there any questions?

None

Chair status (cont.) Chair went over the following: • Background of group (slide 6) • Voting: All committee members may vote; 75% approval required • Attendance: Reminder to sign the electronic attendance form

Approve Agenda Chair: Any there any changes to the agenda?

Submission page 2 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

None

Approve Meeting Minutes from conference calls Chair: Are there any objections to approving the Meeting Minutes from the February 3rd, February 16th and March 9th conference calls?

None

Chair status (cont.) Chair went over the Options & Deliverables (slide 7), explaining that the shadowed items were discussed but were not done either because they couldn’t be done in our time frame or there were no volunteers.

AP Functional Description – Darwin Engwer – doc 05/120r6 Chair explained that this document would be accessible on the web. It will not be submitted to IEEE TGm. Key points from Darwin Engwer’s (DE) summary of the document:

Body • UML style use case diagrams are used to pace APs in context with other elements in the WLAN System. This extensible framework allows other groups to easily build on existing diagrams, without requiring detailed knowledge of the underlying AP functions. Footers provide specific UML syntax information. • There is an unstated condition that without an AP, the MU and DS can’t do anything. • An Access Unit, which is an instantiation of a WLAN System, is a collection of AP functions which include the ACM STA, a Distribution System and a Portal. • The IBSS is not considered a Wireless LAN. • A correction was made to the “Primary ACM STA Functions” section to state that the MU will join with the ACM STA and associate with an AP (instead of associate with the ACM STA). Primary ACM STA Functions • Secondary functions not included in this document include the following: o Moving management frames between the MU and the AP is considered a secondary function of the STA. This document only covers primary functions. Primary AP Functions • This describes functions of a bridge without mentioning the term. • Virtual ports in 802.11i are considered a secondary function. Primary DS Functions • The functional interface to the DS, as described in Mike Moreton’s 05/115 document, is not included in this document. • Broadcast and multicast are special cases of moving data. Ask Dorothy if the actual DS interface is out of scope? • The Authentication Server is considered outside the WLAN System (Figure 3). Primary Portal Function • The WDS is not included since it is not a primary function. WDS is not a form of a DS. It is an unfortunate name. Mike Morteon did a document on this (05/105r4). Summary • A DS could be part of a different DS, although this does not apply to a physical entity.

Submission page 3 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

• The WDS does not reside in any of the components or path in Figure 2 or 4. It’s a special function of the ACM STA that allows it to deliver MSDUs to an attached entity – not a MU. • A mesh network is not defined in the standard.

AP Function Summary – Jon Edney, Darwin Engwer – doc 04/1225r8 Key points include: AP Analysis • Darwin explained Use case 2 in terms of the Associate Request. The Assocate Response frame would go over the air, and not go up to the DS, since there is no interface between the AP and the DS. Mike’s interface would solve this.

Generalized LAN Emulation – Norman Finn – doc 05/0240r0 Key points include: Slide 3 What is an “Emulated LAN”? • The emulated LAN appears as a fat yellow coax from people above (slide 6). It is an attempt to make a bunch of point-to-point and/or point-to-multipoint links look to the bridge, like a shared medium. Slide 14 Observation • An AP appears as point-to-point links to STAs. The STAs are dependent on the bridge for communication. Slide 37 A small “Emulated LAN” • The relay function was not shown. • If the orange link were to fail, it doesn’t work. That’s why VPLS and ATMLAN do it differently. If a link fails, they can signal to recover. Slide 41 Head PA Forwarding Rules • The bottom line for control is the Head PA Forward Rules. Slide 54 802.11 • An AP is an example of what’s covered in a small addition to the forwarding rules. The four-address format is required to allow a Bridge to be a Station.

Adjourn 6:02 pm

Tuesday, 7:30pm March 15, 2005 Reconvene 7:31pm

Agenda (11-05/0187r1): • Tuesday 7:30-9:30pm – Request for 802.1 work (7:30pm) – 05/105,115 –Text errors and clarifications, DS Interfaces – 05/159 – Integration Function Description

Suggested Liaison to IEEE 802.1 – Mike Moreton, Dorothy Stanley– doc 05/0185r1 Key points include: • The Chair gave some background on our November 2004 Joint meeting with 802.1. If the Ad Hoc Committee agreed to the suggested liaison and it was approved on Friday, we could ask Stuart Kerry to forward the request to Tony Jeffree. • 802.11 was just one of the many activities Norm Finn’s earlier presentation was geared to. Submission page 4 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

• Potential applications in 802.11 include: o Virtual ports (using a different key for unicast versus broadcast) o Forwarding table update ƒ Most AP manufacturers overcome this by sending out either a broadcast frame or using the 802.11F XID frame. • The Bernard Aboba comment in the “Forwarding Table Update” did not seem to be relevant and was removed. Chair: Any objections to sending this to 802.1?

None

Chair: Hearing one, from a process point of view, should we send this as an individual or on behalf of the group? If the latter, we need to have a vote.

MOTION: Request Stuart Kerry to forward the liaison request in 05/185r2 to IEEE 802.1 Working Group, on behalf of the IEEE 802.11 Working Group.

Mover: Darwin Engwer Seconder: Jon Edney Results: Yes-5, No-0, Abstain: 1

Comment: In ad hoc mode, anyone can vote.

DS Clarifications – Mike Moreton – doc 05/0105r3 The Chair mentioned one hour was allotted to go over comments. She said a fair amount of time had been spent in the February conference calls going over this document. She knew there were a lot of comments and would create an r4 with the changes we agreed on. We might not get through all of it. She was open to suggestions.

Comment: Is there an agreement that this is required?

Chair: That is one option. Let’s go through the changes suggested.

Comments included: Uncontrolled Port Frames to AP Do Not Transit the DS ƒ Delete the middle paragraph since the delivery of uncontrolled port frames can’t be going to the DS. ƒ Delete the last descriptive paragraph. Clarification of ESS ƒ Remove the descriptive text and change the definition to say integrated LAN devices are not part of the ESS. Changes to BA and ESA ƒ Change “geographical area” to “area”. Definition of WDS ƒ WDS is an unfortunate name since it doesn’t have anything to do with the DS. ƒ Need to look at the definition Mike Moreton added. 3.5 association ƒ ”MSDU Relay Service” has an implication on the architecture. 3.13 basic service area

Submission page 5 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

ƒ Change “geographical area” to “area”. 3.14 basic service set ƒ Change the first sentence from “that have executed the synchronization procedure” to “set of stations that have synchronized using the procedure”. 3.31 MSDU Relay ƒ Remove. 3.43 extended service area ƒ Remove geographical. 3.123 Wireless Distribution System ƒ Wireless going building to building has nothing to do with the distribution system. It should be a mechanism for wireless communication. The four address frame format is useful. 5.2.2 Distribution system concepts ƒ Remove the changes to the fourth paragraph. ƒ Undelete the last sentence in the first paragraph after Figure 2. ƒ Remove the last two paragraphs. 5.2.2.1 Extended service set ƒ Clarification of ESS. 5.3.2 DSS ƒ Delete Figure 7 – it’s including non-802.11 things (e.g. portal, integrated LAN). 5.2.4 Integration with wired LANs ƒ Remove the “terminating any protocols that might be required to maintain the STA to AP location mapping” in the last sentence in the paragraph after Figure 6 since it is not true. 5.3 Logical service interfaces ƒ Delete “MSDU Relay”. 5.3.2 DSS ƒ Delete the last paragraph. ƒ Delete “MSDU Relay”. 5.33 Multiple logical address spaces ƒ DSM is ok.

Chair: Time check – one hour is up. We should look at documents 05/115 and 05/159.

Comment: Should we send one document to m?

Comment: Finish this one.

Chair: You had work to do on 05/115.

Comment: Let’s get through this and just talk about 05/115 and 05/159 about our disposition.

Chair: That’s an agreed upon plan.

5.33 Multiple logical address spaces (cont.) ƒ Change “reachability” to “transparency” two paragraphs above 5.4

5.4.1.1 MSDU Relay ƒ Delete.

Submission page 6 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

5.4.2.2 Association ƒ Only modify the last paragraph. ƒ Don’t change Figure 9. 6.1.4 MSDU format ƒ Change the last sentence from “STA whether it is an AP or not” to “non-AP STA”. ƒ Cut and pasted the Primary Portal Function 802.1H reference in 05/120 (“along with a selective translation table (STT) that handles a few specific network protocols”) and place it in this paragraph.

Chair: We will accept all changes and post this as r4. Read through the document and provide comments:

Adjourn 8:36 pm

Wednesday, 1:30pm March 16, 2005 Joint Meeting with TGm 1:30 pm

Call to Order & Agreement on Agenda Meeting called to order on Tuesday, March 15, 2005 by Dorothy Stanley. Chair of TGm: Bob O’Hara Chair of APF: Dorothy Stanley Secretary of APF: Sandy Turner

Chair of TGm Chair: Agenda discussion Proposed Agenda (11-05/0205r0): • Review IEEE Patent Policy • Review interpretation request procedure • New business – Submissions – Continue with items from 04/801r3 – APF SC submission – Instruct Editor to create 802.11REVma/d1.0 – Approve draft – Forward draft to working group for letter ballot – Interpretation Request • Adjourn

Review IEEE 802 and 802.11 Policies and Procedures Chair showed the two slides at http://standards.ieee.org/board/pat/pat-slideset.ppt, requested by WG chair “IEEE SA Standards Board Bylaws on Patents in Standards” and “Inappropriate Topics for IEEE WG Meetings”.

Chair: Are there any questions?

None

APF SC submission

Submission page 7 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

Chair of APF: Four documents were to be submitted for reference material: 05/120, 05/105, 05/257, 05/262. Two documents were to be reference material: 04/1225, 05/159.

AP Functional Description – Darwin Engwer – doc 05/0120r6 Dorothy Stanley gave an overview of the document. The intent is an informative annex in the standard.

DS Clarifications – Mike Moreton, Darwin Engwer, Jon Edney, Johnny Zweig – doc 05/0105r4 Dorothy Stanley gave an overview of the document.

Comment: The addition of the paragraph in 6.1.4 will conflict with what I’m (Darwin Engwer) am going to suggest in a different paragraph.

Proposed Integration Function Informative Annex – Johnny Zweig – doc 05/0257r1 Darwin Engwer arrives (1:46 pm) and informs us 05/262 is not ready yet. Johnny Zweig gave an overview of 05/0257r1. Key points include: ƒ He mentioned 05/159 explains how to do this, but he was hesitant about putting all the text in the annex. ƒ Bob O’Hara said it is appropriate to have elaborate examples in the annex (e.g. Annex G explains how to do OFDM encoding).

Chair of TGm: We could do 05/105, but 05/120, 05/257 and 05/262 haven’t been on the server long enough.

AP Functional Description – Darwin Engwer – doc 05/0120r7 Key points included the following: ƒ DE added a reference in clause 2 for 802.1H. Even though this is in 05/105, the editor will figure it out. ƒ UML use cases came in 2.0. Since UML use case came in 2.0 and there is a reference to a UML manual before 2.0 came out, DE will change the reference to the 2004 specification instead of the manual.

Proposed DS Service Interface – Darwin Engwer, Johnny Zweig – doc 05/0262r1 Key points included the following: ƒ DE discussed how he still had two more primitives to define the interface between the MAC and DS. This will make it easier to talk about the DS. ƒ After walking through what he had, DE asked if there was value in doing this and if so, where should it be included. ƒ Since there is no new functional requirement, this is just clarifying what’s there. If you red the standard carefully and use common sense, you’ll be okay. ƒ Since the front cover says MAC and PHY specifications, would adding this allow interoperability earlier than later? ƒ Why not describe what the DS does, especially broad cast and multicast. ƒ MSDU stuff is in Clause 6 and the LME stuff is in Clause 10.

Submission page 8 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

ƒ A Cisco 1200 is not an AP. It is an access unit – an implementation that includes an AP.

Moved: to adopt the text in document 05/105r4 and incorporate it into the 802.11REV-ma draft. Moved; Dorothy Stanley, David Hunter

Chair of TGm: Any discussion on the motion?

Comment (DE): I missed when you went over this. Are people happy with this, in particular Mike? Can you live with this?

Comment (Mike Moreton): I’m ok with it as far as I know

DE: And Jon?

Chair of TGm: Seeing no discussion, is there any objection to adoption of this on the screen?

None.

Chair of TGm: Seeing no objection, it’s adopted unanimously.

Moved: to adopt the text in document 05/105r4 and incorporate it into the 802.11REV-ma draft. Moved: Dorothy Stanley, David Hunter Passes: unanimous

Moved: to incorporate the text from document 05/257r0, plus the examples from 05/159 (the result shown in 05/257r1), and incorporate it in the 802.11REV-ma draft.

Chair of TGm: Any crafting of this motion before it is moved and seconded?

Chair of APF: Do we need to say informative annex?

Chair of TGm: Are the instructions are already in there?

Chair of APF: Yes

Chair of TGm: Any questions?

Moved: Sandra Turner, Darwin Engwer

Chair of TGm: Any discussion?

None.

Chair of TGm: Any objections?

None.

Chair of TGm: Seeing none, it passes unanimously.

Submission page 9 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

Moved: to incorporate the text from document 05/257r0, plus the examples from 05/159 (the result shown in 05/257r1), and incorporate it in the 802.11REV-ma draft. Moved: Sandra Turner, Darwin Engwer Passes: unanimous

Chair of TGm: That leaves 120 and 156.

DE: I’d like feedback with a straw poll.

Straw Poll Question: should we continue with the definition of the DS service interface presented in 05/262? Yes: 6 No: 2

Chair of TGm: Where do you want to put it?

Straw Poll Question: How should this be done: Clause 6: 4 Informative annex: 5

Chair of TGm: Is there anything else the APF group would like to do?

Chair of APF: That covers everything. I’m delighted 105 and 257 are in and 120 and 252 tomorrow.

Chair of TGm: As long as there is intelligent people in the room, lets go through some of the items in 05/22r1. Simon had been assigned action item #71, which concerns clarification of the PHY Parameter Set element of a BSSDescription when no PHY parameter set is received in a Probe Response/Beacon (e.g. 802.11a). He produced 05/209r0 that changes Clause 5. We reviewed in on Monday and it’s been on the server since Monday afternoon. Does anyone want to make a motion?

Moved: to resolve item #71 with the text in document 05/209r0. Moved: Darwin Engwer, Jon Edney

Chair of TGm: Any objection to adopting the motion before you?

Moved: to resolve item#71 with the text in document 05/209r0 Moved: Darwin Engwer, Jon Edney Passes: unanimous

Chair of TGm: Similarly, Item 93 concerns a problem with the SDL description in Annex C whereby a probe request frame is routed to the Distribution_Service block rather than the MLME_AP block.

Moved: To resolve item #93 with the text in document 05/209r0. Moved: Darwin Engwer, Dorothy Stanley

Submission page 10 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

Chair of TGm: In the SDL, it can get pretty ugly. Someone came up with a simple solution to a problem. The probe request is being sent to the DS interface, instead of the MAC management interface. Simon in 05/209r0, found a simple change in the SDL that would correct this. Any discussion?

Comment: Should we change anything we’re not maintaining?

Chair of TGm: This implies it’s being maintained. There are a large number of SDL bugs – some were rather important and are blatant problems. A number of other SDL bugs we’ll not tackle. Still some that are open will be closed without action at the end of this week. I understand the opinions on both sides. As long as we’re publishing it, keep it correct.

Comment: Could we make a statement that we’re not maintaining it.

Chair of TGm: The Working Group has not taken that position yet.

Comment: I’d like it corrected as much as possible. Make all cost effective corrections. Leaving something wrong that’s easy to fix is bad to me.

Chair of TGm: This is done with all volunteer labour.

Comment: Will things that are chosen to not be fixed stop you from getting a working implementation?

Chair of TGm: If you implemented a MAC literally according to the SDL, you couldn’t do it and get it to work with existing products out there.

Comment: Would it function and not be compliant with standard compliant products (e.g. not set certain bits)?

Chair of TGm: I’m not aware of those types of errors. There is a difficulty in that some things are described only in SDL, some only in text and some in both - but inconsistently.

Comment: Are any in normative text?

Chair of TGm: Both are normative.

Comment: Diverging from the motion on the floor, are we capable of making that change?

Chair of TGm: Graphically or using a SDL editor Terry dug up. Any further discussion?

None.

Chair of TGm: Any objection to adopting?

Moved: To resolve item#93, with the text in document 05/209r0 Moved: Darwin Engwer, Dorothy Stanley Passes: unanimous

Submission page 11 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

Char of TGm: One more. There was a discussion a long time ago that the actual assocation/reassociation primitive and authentication primitive didn’t reflect what’s described in the rest of the document - especially Clause 11. Everyone has built a MU request association to the AP and it indicates out of the MLME it’s received a request. It sends back a response to the mobile station as described in Clause 11. In Clause 10, the AP indicates the station is associated.

Comment (DE): (Brings his laptop up and shows 04/639r1 Figures 1 and 2.) What’s missing is the response. The indication is improperly described.

Chair of TGm: Ok, thank you.

Moved: to resolve item #39 with the text in document 04/639r1 Moved: Darwin Engwer, Fred Haisch

Chair of TGm: Any discussion on the motion?

Comment: You’re adding the response correctly and modifying the confirm. Are you modifying the confirm parameters as to compared with what’s in the standard?

DE: There is no change in the 1.1.1.2.2 authenticate confirm. In the case of the associate confirm in 1.1.2.2.2, it previously only sited the result code, but other info comes back to be passed to the SME per request – capability information, associationID, supported rates. Similarly in the reassociate.confirm – same change. We tried and Simon recommended the path with the least amount of changes as possible. In the case of other primitives, the request additional parameters need to perform the reassociation response procedure. Instead, the MLME already has this information in its internal state.

Comment: Did you change the authenticate as well?

Chair of TGm: He added the response.

Comment: The MAC level authentication is more purely a MAC function.

Chair of TGm: Not necessarily. Something other than open system, shared key requires an external challenge.

Comment: Then you need the WEP key in the MAC?

Comment: The existing primitive does not let the SME be involved in the process. If you use the shared key, it needs another parameter – or use what’s included in the MLME internally.

Comment: A real authentication would go into the next state – Hello MAC, I’m here.

Chair of TGm: This would happen if the SDL was correct.

Comment: If it was me, I wouldn’t do it.

Comment: Do you feel strong enough to amend it?

Submission page 12 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

Comment: No. There is little description in the pre-11i text of the protocol when it gets in this state.

Comment: The STA always responds with success.

Chair of TGm: Any other discussion?

Comment: Call the question.

Chair of TGm: Any objection?

Moved: to resolve item #39 with the text in document 04/639r1 Moved: Darwin Engwer, Fred Haisch Passes: 7-0-6

Chair of TGm: This brings us to the end. We will meet at 1:30 in Baker tomorrow to consider the remaining two motions on the AP material, any other work items on the spreadsheet, create a draft and forward it with a letter ballot and make the draft available for sale. There are two meeting slots – 1:30 and 4. The absolute latest documents can be on the server is just before the end of the 12:30 slot in the morning. Four meeting hours is no later than 12 noon. The earlier the better.

Adjourn 3:26 pm

Attendees: Jim Burns Paul Congdon Russel Dietz Phil Dumas Donald Eastlake Jon Edney Hiroshi Furukawa Fred Haisch Srinivas Kandala Tetsuya Kawikani Bo Kuaenstrom Jouni Malinen Michael Montemurro Robert Moskowitz Andrew Myles Paul Newten Don O'Connor Paul Panish Ken Patton Yaron Peleg Jessy Rouyer Marian Rudolf Emek Sadot Dorothy Stanley

Submission page 13 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

Sandy Turner Genadi Velei Zhong Yao Artur Zaks Johnny Zweig

Submission page 14 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0299r0

References:

Submission page 15 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0324r0

IEEE P802.11 Wireless LANs

JTC1 SC6 Ad Hoc Meeting Minutes March 2005 Session

Date: 2005-03-17

Author(s): Name Company Address Phone email Sandy [email protected] LANL Los Alamos, NM 505-665-6820 Turner v

Minutes of the 802.11 JTC1 SC6 Ad Hoc Committee meeting held during the IEEE 802 March 2005 Plenary Session in Atlanta, GA from March 13th – 18th, 2005.

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 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0324r0

Thursday, March 17, 2005 Call to Order Meeting called to order on Thursday, March 17, 2005 by Clint Chaplin at 4:04 pm. Chair: Clint Chaplin Secretary: Sandy Turner

Review IEEE 802 and 802.11 Policies and Procedures Chair showed the two slides requested by the WG chair: “IEEE SA Standards Board Bylaws on Patents in Standards” and “Inappropriate Topics for IEEE TG Meetings”.

Chair: Are there any questions?

None.

Chair: Are there any issues from the January meeting?

None.

Chair: Are there any objections to approving the minutes?

None.

Chair: Seeing none, the minutes are approved. As a reminder, do your attendance.

Agenda discussion Proposed Agenda (11-05/0289r1):

• Minutes – Approval of Minutes of January 2005 Meeting - 11-05-0098-00-0jtc-jtc1-ad-hoc- meeting-minutes-january-2005-session.doc • Approve Agenda • Status report • Submission of 802.1X to ISO/IEC JTC1/SC6 • Ask to have IEEE 802.11 JTC1/SC6 Ad-Hoc committee through July 2005 Plenary • Authorize weekly teleconferences to resolve P8802.11i fast track ballot comments – weekly on Tuesdays at 1900 ET starting at June 14 and continuing through July 26 • Work on text for Roger Marks liaison letter to various organizations in China. • Next steps for IEEE 802.11 – Recommend to appoint Alex Cheng as IEEE 802.11 liaison to CCSA. – Meeting in China • Adjourn

Chair: The agenda is before you. Roger, when do you have to go?

Comment: Not until 7.

Chair: Are there any comments on the proposed agenda or changes?

None.

Chair: Are there any objections to approving the agenda?

Submission page 2 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0324r0

None.

Chair Status Key points included: • P8802.11i was suspended for one month to allow questions. The suspension ended March 15th and the ballot closes June 9th. The web site has not been updated with this information. • Comments and resolutions will be handled by this committee. The resolutions must be completed before the July meeting and approved by the full Working Group before they are submitted to JTC1. • 802.1X, which is referenced by 802.11i, will not be submitted to ISO due to things such as 802.1 workload and limited resources. This has been a policy for 802.1 since 1998. A Class A JTC1 liaison, in which any standard that comes up would become an ISO standard, is also being investigated. IEEE is currently a Class C liaison to JTC1.

Comment: Can you give a brief review of the Frankfurt trip?

Chair’s key points:

• There was an ad hoc meeting to talk about the technical issues of WLAN security with members from various national bodies. • The first two days were procedural discussions. IEEE then gave two technical presentations (technical aspects of WAPI – 30 minutes, technical aspects of 802.11i – 6 hours), and a presentation expanding on the response letter from IEEE 802 to ISO JTC6/SC1. • The Chinese left Wednesday mid-morning before the IEEE technical presentations. • WAPI is not a submission right now.

Comment: My impression was WAPI was a new project request that needed to be on the ballot for SC6 before it could be moved to JTC1. It was never put on the agenda for SC6 ballot and went no further.

MOTION: Authorize IEEE 802.11 JTC1 Ad-Hoc Committee weekly teleconferences to resolve P8802.11ii fast track ballot comments, Tuesdays at 1900-2000 ET (2300-2400 UTC) starting at June 14 and continuing through July 26. By: Dorothy Stanley Second: Alex Cheng Result: Yes-13, No-0, Abstatin-4

Work on text for Roger Marks liaison letter to various organizations in China Key points included:

• Roger Marks reviewed and received input on drafts of 3 letters he will submit to MII, CCSA and CESI. He gave a background on each of the organizations, some prior communications and key contacts. • There was a 5 minute recess during the discussion. • The letters will be forwarded to Stuart Kerry and then discussed at the EC meeting tomorrow. • Based on feedback, a new model will be used to setup meetings outside North America. Instead of IEEE people doing the scouting, we will first find a host, tell them our specs and then let them make a proposal. Face-to-face will still do the local details. • We want to start a liaison relationship with CCSA. Desired characteristics include the following: native speaker, someone at the 802.11 officer level.

Submission page 3 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0324r0

MOTION: Recommend to the IEEE 802.11 WG Chair that Alex Cheng be appointed to liaison from IEEE 802.11 to CCSA. By: Henry Ptasinski Second: Ho-In Jeon Result: Yes-7, No-1, Abstatin-4

Chair: We’ve covered everything in the agenda. Is there anything else? We’re also investigating contacts with the TAG for voting on ISO JCT1, who have been abstaining. There is no technical knowledge within the TAG. Is there a motion to adjourn?

By: Dorothy Stanley Second: Henry Ptasinski

Chair: Are there any objections to adjourning?

None

Chair: Seeing none, we’re adjourned.

Adjourn 5:52pm

Attendees:

Clint Chaplin Alex Cheng Sebastien Dure Jon Edney Fred Haisch Haixiang He Russ Housley Jari Jokela Roger Marks Andrew Myles Paul Panich Yaron Peleg Henry Ptasinski Emily Qi Dorothy Stanley Fabrice Stevens Sandy Turner

Submission page 4 Sandy Turner, LANL

March 2005 doc.: IEEE 802.11-05/0324r0

References:

Submission page 5 Sandy Turner, LANL