doc.: ieee 802.11-03/853r0grouper.ieee.org/groups/802/11/minutes/cons_minutes_nov-2003.pdfnovember...

November 2003 doc.: IEEE 802.11-03/853r2

IEEE P802.11 Wireless LANs

Approved Minutes of the IEEE P802.11 Full Working Group

November 10-14, 2003

Hyatt Regency Albuquerque, Albuquerque, New Mexico, USA

Joint 802.11 / 802.15 Opening Plenary: Monday, Nov 10, 2003 1.1. Introduction

1.1.1. 1.1.2. 1.1.3.

1.1.4.

1.2.1.

1.2.2.

1.3.1. 1.3.1.1. 1.3.1.2.

1.3.1.2.1.

1.3.1.3.

1.3.1.3.1.

1.3.1.4.

1.3.1.5.

1.3.1.6.

1.3.1.7. 1.3.1.8.

Meeting called to order by Stuart J. Kerry at 1:35PM. Straw Poll – new members at this meeting: 54 The agenda of the 82nd session of 802.11 is in doc: IEEE 11-03-805r2. This session is including 802.11, 802.15, 802.18 RREG TAG, 802.19 Coexistence TAG, and 802.20 MBWA. Secretary – Tim Godfrey

1.2. Announcements The chair of 802.19, Jim Lansford has resigned. The Chair pro-tem is Steve Shellhammer. Volunteers for the position are solicited. There are 462 people present in the room.

1.3. Policies and procedures Al Petrick reviews document 802.11-00/278r8

Review of WG officers and duties. Operating policies and procedures and the hierarchy of organizations

and rules are reviewed. The source documents are listed in document 278r8, and available on our server.

802.18 has approved policies and procedures, and they will be updated in January.

Rules for registration, photography, and media recording are presented.

Going forward, it will be required to have your badge and voting token to be recorded in a vote.

Review of the electronic attendance logging rules. Contact information must be maintained up to date by members on the server.

The rules for gaining and maintaining voting rights are presented. Document 462r14 “New Members Orientation” has further details.

The rules for voting rights and participation in working group, task groups, and study groups is reviewed.

Review of individual membership and anti-trust rules. Al Petrick reviews the rules on Patents, according to the standard

bylaws. All members must be aware of this policy. Al Petrick reads the following text to the group:

Minutes page 1 Tim Godfrey, GlobespanVirata


6. Patents

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. 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.

IEEE-SA Standards Board Bylaws on Patents in Standards

Slide #1 Approved by IEEE-SA Standards Board – December 2002

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 Administratorat [email protected]

Slide #2 Approved by IEEE-SA Standards Board – December 2002



1.3.1.9. 1.3.1.10.

1.3.1.10.1.

1.4.1.1.

1.4.1.1.1.

1.5.1. 1.5.2.

1.5.3. 1.5.3.1.

1.6.1. 1.6.2.

1.7.1. 1.7.2.

1.8.1.

1.8.2. 1.8.3.

1.8.4.

1.8.5. 1.8.5.1.

1.8.5.2. 1.8.6.

1.9.1.

1.9.2.

Al Petrick reviews the rules on copyrights. Questions

Should email addresses be in the minutes? No.

1.4. IP Statements Do any of the WG chairs need to be aware of any new IP

statements? None

1.5. Announcements Network support is by registration The chair notes that these are public spaces, and members should not leave computers unattended. Questions from the floor:

Where are these presentations located? In the Incoming folder of 802wirelessworld.com for 802.11.

1.6. Approval of the Agenda Stuart J. Kerry reviews the agenda in 802.11-03/805r2. The agenda is approved with unanimous consent

1.7. Approval of minutes Any matters arising from the minutes from Singapore The minutes are approved without objection.

1.8. Wireless Network and Attendance system Al Petrick reviews the network and attendance recording procedures in document 03/044r5 Documents are available by FTP and HTTP Al Petrick presents a tutorial on using the attendance recording software, and submitting documents. Members are notified that they must have up to date virus and worm protection. Questions

How long will it take to move documents submitted here to be available on the Internet at the IEEE site? We expect the server to be on-line next week. We will move all files late Friday, and they should be available Saturday.

What if an email address is changed? Notify Al Petrick for 802.11. Members are notified that you will show as “new members” in the software. We still do not have the voter status records loaded into the new software.

1.9. Interim Meetings for 2004 January 11-16, 2004, Vancouver, BC. Originally it was the Fairmont hotel. Now we have added the Hyatt as an additional hotel. The wireless groups will be located in Hyatt. Finding Hosts has become difficult. We need help for hosts to 2004. We cannot move directly to self-funded hosting of Interims. There is potential financial risk.



1.9.3.

1.9.4.

1.9.5.

1.10.1.

1.10.2. 1.10.3. 1.10.4.

1.11.1.

1.11.2. 1.11.3.

1.11.4.

1.11.5. 1.11.6. 1.11.7.

1.11.8.

1.11.9.

1.11.10.

1.11.11. 1.11.11.1.

1.12.1. 1.12.2. 1.12.3.

May 9-14, 2004. Host Appairent Technologies. Possibilities are Hyatt Anaheim or Hyatt Irvine. Straw Poll - 423 for Anaheim, 73 for Irvine. The meeting is at Anaheim. 802.16 may join us. September 12-17, 2004. Two choices. Esterel Hotel, Berlin, or the Hyatt Monterey. Meetings at Berlin would be more expensive for the registration fee – probably $500 registration fee. Straw Poll. 269 Berlin, 145 Monterey. There has been an offer from CRL in Japan. That was not an option because there is not enough time to set it up, and we would require major sponsorship to offset the much higher costs.

1.10. PARs on the ExCom agenda We have to reply on new PARs for each WG by 5:00PM

Tuesday. 802.3 10GbaseT 802 Handoff WG 802.1 Higher Layer LAN Protocols Working Group

1.11. Financials Bob Heile presents the financials on behalf of 802.11 and

802.15 Updating from September to November 2003. There are reserves for software development and 802

auditing. We have a new account that complies with policies and

procedures. We will transfer funds from the custodial account. The deficit from Singapore will be about $20K. We have purchased a server for about $3500 The current account balance is about $79K, but will be down

to $8700 by May 2004. There can be no further unplanned expenditures between

now and the May 2004 meeting. Report from the IEEE audit of the custodial accounts. The

appraisal was that the accounts were in compliance with procedures, and adequately documented.

The financial summary document is posted in the 802.11/15 websites. We have also posted the contract for the software development.

Questions What are the executive committees for 802.11 and 802.15? The

CACs (WG officers, TG chairs and vice chairs, and treasurers)

1.12. Report from 802 Executive Committee There were 1375 attendees in San Francisco. “Get 802” pilot program ends in May 2004. There are tutorials tonight and tomorrow night.



1.12.4.

1.12.5.

1.12.6.

1.13.1. 1.13.1.1. 1.13.1.2. 1.13.1.3. 1.13.1.4. 1.13.1.5. 1.13.1.6.

1.13.1.6.1.

1.13.2. 1.13.2.1. 1.13.2.2. 1.13.2.3. 1.13.2.4.

1.13.3. 1.13.3.1.

1.13.4. 1.13.4.1.

1.14.1.1. 1.14.1.1.1.

1.14.1.1.2. 1.14.1.2.

1.14.2. 1.14.2.1.

1.14.3.

1.15.1.

1.16.1. 1.16.1.1.

Looking at alternative organizations. The ExCom is considering splitting the organization to help with logistics to compensate the very large size of all of IEEE 802.

Working on a joint press release on network support services.

The officers of 802.20 were confirmed. Some ExCom members felt that IEEE did not fully indemnify them. Those members left the room during the confirmation vote.

1.13. Activities and plans for the week 802.11 Voter Summary

Document 01/402r15 454 voters to date 107 nearly voters Potentially 561 462 aspirants Questions?

Of the 562, how many companies are represented? The membership is individual, not by company.

802.15 Voter summary 186 voters to date 75 nearly voters 133 aspirant 262 potentially

802.18 voters About 10

802.20 voters 180 voters.

1.14. Approval of 802.11 agenda Any objection to adopting the agenda?

Request an agenda item for UWB ITU? Will be done on Wednesday in New Business.

Any other changes? None The agenda is adopted with unanimous consent.

Review of minutes from 802.11 minutes from SFO Minutes are adopted without objection

A vote will take place on Friday to update the 802.15 rules 1.15. 802.11 documentation update

Harry Worstell cannot monitor document formatting any more. The chairs of the working groups are responsible. Anyone can identify a document that is not formatted correctly (as per the Policies and Procedures) and prohibit presentation until the formatting is corrected.

1.16. Task Groups TGe – John Fakatselis

TGe will continue with comment resolutions from the last letter ballot. There have been teleconferences and an interim TGe meeting. All



comments except 100 have been resolved. We plan to complete them this week and conduct a recirculation ballot this week. We expect 90% approval.

1.16.2. 1.16.2.1.

1.16.2.2.

1.16.2.3. 1.16.2.3.1.

1.16.3. 1.16.3.1.

1.16.4. 1.16.4.1.

1.16.5. 1.16.5.1.

1.16.6. 1.16.6.1.

1.16.7. 1.16.7.1.

1.16.7.2.

1.16.8. 1.16.8.1.

1.16.9. 1.16.9.1.

1.16.10. 1.16.10.1.

1.16.10.2.

TGi - Dave Halasz Draft 7 had 95% approval. Planning to go to Sponsor Ballot. There

are 14 voters that have voted No. Some have changed their votes, and others will be talked to this week.

WAPI (Chinese security standard) will be discussed on Wednesday. There will be submission. There are political issues and questions that are still unanswered.

Discussion There is a web page with information on WAPI. Will pass

information to Dave Halasz for 802.11i TGj – Sheung Li

At Singapore, all comments from LB 6 have been resolved. There are two drafts that can resolve them all, but they have not been voted on. One will be selected at this meeting, and issue a recirculation ballot. TGk – Richard Paine

We had a requirement to work on the MIBs. An ad-hoc meeting generated some proposals. There will be a vote for a new Secretary. There will be technical presentations, and a LB vote. Issues are signal quality measurement. TGm – Bob O’Hara

Will address one interpretation request. Will proceed to the work items in the spreadsheet distributed in Singapore. TGn – Matthew Shoemake

Will be working on selection procedure, finalize channel models, and work on functional requirements and comparison criteria. Will not be able to complete until January. Will draft a call for proposals, and draft timelines for declaring intent to bring proposals. There will not be a CFP at this meeting. There are a large number of submissions that will be presented. WNG – TK Tan

Will have 5 sessions. Topics will be ESS mesh networking, wireless performance prediction, and wireless InterWorking. Also presentations on Security, and updates from liaisons.

The WG chair notes that the WNG will review their charter and report to the CAC on Thursday Fast roaming SG – Clint Chaplin

Meeting for the first time Tuesday. Working on PAR and 5C. Agenda in Doc 866. Will ask for extension of SG lifetime. Call for proposals for PAR and 5C. WAVE SG – Lee Armstrong

Meeting Tuesday and all day Thursday. Have received input on PAR and 5C, will be modifying this meeting. Technical Editor – Terry Cole

Doc 197r5. Coordination session on Tuesday for all TG editors. 802.11h is published and shipping. The 2003 reaffirmation CD is available. Notes that some members have signed in with bogus names. These cannot be published with standards, so they were deleted. Task Groups need to decide if a draft needs to be published.

Discussion



1.16.10.2.1.

1.16.11.

1.16.11.1.

The reaffirmed 2003 version that is available has a problem. The CD version given out here is missing chapter 17.

Liaison Letter from IST-Romantic project. From Barcelona Spain.

Stuart Kerry reads this letter: This project wishes to liaison with 802.11. The aim of Romantic is regarding resource management in multi-hop networks. For 3G and 4G networks. It would be of benefit to them to have access to the latest drafts of 802.11. In exchange, the project will present results to 802.11 at an appropriate time.




1.16.12.


1.16.13. 1.16.13.1.

1.16.14. 1.16.14.1.

1.16.15. 1.16.15.1.

1.16.16. 1.16.16.1.

1.16.17. 1.16.17.1.

1.16.18. 1.16.19.

1.16.20. 1.16.21.

1.16.22. 1.16.22.1. 1.16.22.2.

1.16.23. 1.16.23.1.

1.16.23.2. 1.16.23.2.1.

1.16.24. 1.16.24.1. 1.16.24.2.

1.16.24.3. 1.16.24.3.1.

1.16.24.3.2. 1.16.24.4.

802.15 TG3 TG3 will meet on Thursday. Will look at MAC enhancements or

errata in the standard. Will propose a SG on MAC enhancements. 802.15.3 –2002 is on the CD. (really 2003) 802.15.3a – Bob Heile

In the downselect process. Reset to Step 4. There are two remaining proposals. They will be downselected this week. 802.15.4 – Pat Kinney

Looking at MAC enhancements for security and performance. Also looking at alternative PHY layers. 802.15 SG4a – Larry Taylor

Reviewing proposals for CFA that closed before this meeting. There are 3 proposals. 802.15 MMwave SG – Reed FIsher

Meeting on Monday, and Thursday. Publicity – Glenn Roberts Presentations from packet pools, Wimax, and other liaisons. Review of

802.11 and 802.15 in the media. Review news bulletin. 802.15.1a – Tom Seip Will review the material in hand, and create a draft. Will conduct LB

between meetings. 802.18 – Carl Stephenson

Presentation in 802.18-03-066 Preparing replay comments and filings for FCC. Opposition for high

power UWB radar. Will prepare regulatory documents. Issues – R&O on 5GHz NPRM, NPRM on RF exposure, NPRM on part 15 revisions. ITU-R UWB – FCC is exporting UWB rules internationally. ITU is looking at protection mechanisms for UWB. Still looking at 802.11d passive scanning issues, and WAPI standard. 802.20 – Jerry Upton

Have formed 4 correspondence groups. Anyone can join the reflector lists. Will review requirements documents, modeling, and coexistence issues. Will have contributions and new business.

Questions What is 802.20 really about? It is a high speed mobility

MAC and PHY, for fast handoff while moving. Better than other mobile cellular systems. It looks like a high data rate cellular system. Licensed bands only below 3.5GHz.

Announcements Remember to sign in. We no longer accept forgotten sign-ins. The slots are all two hours long starting this week. All sessions are

equal Discussion

People have difficulty signing on to the 802wirelessworld site. The help desk has not been able to fix.

We will fix up people that have problems signing in. The IEEE SA board maintains a list of those that want to participate

in Sponsor Ballots.

1.17. Recess at 3:15PM



2. Wednesday Plenary, November 12, 2003 2.1. Opening

2.1.1.

2.1.2.

2.1.3.

2.2.1. 2.2.2.

2.3.1.

2.3.2.

2.4.1.

2.5.1. 2.5.2.

2.6.1. 2.6.1.1.

2.6.2. 2.6.2.1.

2.6.3. 2.6.3.1.

2.6.4. 2.6.4.1.

2.6.5. 2.6.5.1. 2.6.5.2.

2.6.5.2.1.

2.6.5.3. 2.6.5.4.

2.6.5.5.

The meeting is called to order by Stuart J. Kerry at 10:50AM. Following the agenda in 04/805r2. Changes to agenda – 802 policy and procedure, virus update, TGi Position on WAPI, Position on IST Romantic/Spain. New business: special event, UWB position in ITU, Mesh networking, Wireless prediction, TGi, Members information. There are 455 members in the room.

2.2. IP Statements The chair calls for any IP statements. There are none. The chair asks if any members are not aware of the IEEE IP policy. There are none.

2.3. Announcements TGm has adjourned for the week. There is one item for business on Friday. CAC meeting at 7:00AM

2.4. Attendance Recording Problems yesterday have been resolved.

2.5. Approval of the agenda Any changes to the agenda? None. The agenda is adopted with unanimous consent

2.6. Liaison Reports 802.11 to 802.1 – Dave Halasz

None 802.11 to 802.15 – Mike Seals

None – 2nd call 802.11 to 802.15 3a – Atul Garg

None – 2nd call 802.11 to 802.18 - Denis K

Later 802.11 to WiFi alliance – Bill Carney

Presentation in document 03/903. Passed milestone of 1000 certified products. 15 per week for

certification. 4 labs are running. More dual-band submissions. There are 4 certification programs. WPA and 802.11g are the latest this year.

The Chair notes that PC Magazine has put 802.11g up for an award at Comdex.

WPA2 will be the same as 802.11i, planned for 2Q 2004. WFA is preparing for QoS certification. MRD has been created, and

the test plans are under development. Looking an mid 2004 for QoS certification. There is a backup plan in case 802.11e is delayed. A pre-standard certification plan will be decided in March 2004 if necessary.

A recent group has started to look at 802.11n



2.6.6. 2.6.6.1. 2.6.6.2.

2.6.7. 2.6.7.1.

2.6.8. 2.6.8.1. 2.6.8.2.

2.6.8.3. 2.6.8.4.

2.6.8.5.

2.6.9. 2.6.9.1. 2.6.9.2.

2.7.1. 2.7.1.1. 2.7.1.2.

2.7.1.3.

2.7.1.4.

2.7.1.5.

2.7.1.5.1. 2.7.1.5.2. 2.7.1.5.3.

2.7.1.5.3.1.

2.7.1.5.3.2.

2.7.1.5.3.3.

2.7.1.6.

2.7.1.6.1. 2.7.1.7.

2.7.2. 2.7.2.1.

802.11 to JEDEC JC61 – Tim Wakeley Report in document 03/948 No presentation.

802.11 to CableLabs – Lior Ophir None – 2nd call

802.11 to IETF – Dorothy Stanley Presentation in document 03/923 802.11i dependencies – depending on AES/CCM specification. Now

RFC3610. Also depending on RFC2284bis. Has completed balloting and will be issued an RFC before completion of 802.11i.

BOFs – controlled provisioning of APs; Charter has changed. Radius extensions – new WG may be formed. 802.11i met with EAP

keying group. We are looking into whether liaison can be two-ways. We are trying

to get links to IETF documents on our web site. 802.11 to MMAC – Inoue-san

Report in document number 03/941 MMAC controls Japanese standards for radio systems. High Speed

Wireless access committee, and Wireless Home Link Committee. ARIB-standard T71 created January 2003 for 802.11a compatible WLANs. Will be compatible with 802.11j.

2.7. Old business Policies and Procedures

Document 03/946 Current P&P in 00/331r4. added changes from document 02/434r1.

00/331r6 was presented in July and posted on the server. Al Petrick reviews the changes to the P&P as detailed in document

02/434r1. Version r6 added P&P and the WG Treasury as approved by the WG

and in accordance with the Executive Committee. Motion: Move to approve document 00/331r6 as the policies and

procedures for the 802.11 working group. Moved Al Petrick Second Harry Worstell Discussion

in 3.6.3 teleconferences there is a limitation of every other week. But many groups have teleconferences weekly. Requests a change in the document to use the word “weekly”.

The chair asks if there is any objection to make the change of bi-weekly to weekly. No Objection.

The document under consideration is changed to 00/331r7

Motion on the floor: Move to approve document 00/331r7 as the policies and procedures for the 802.11 working group.

Vote: Motion passes 129 : 0 : 5. Version r7 of the P&P will be posted by the end of the day. The

member making the change will verify the update. Virus Protection Policies

We want to create a policy based on the discussion from the floor in Singapore.



2.7.2.2.

2.7.2.3. 2.7.2.4.

2.7.3. 2.7.3.1. 2.7.3.2.

2.7.3.3.

2.7.3.4.

2.7.3.5.

2.7.3.6.

A small group will meet off-line to make recommendations to be brought up by Friday.

Will meet at the IEEE registration desk at the break. This will be added to the Friday Agenda

TGi position with WAPI – Dave Halasz Document 913r0 China WLAN standards (WAPI) become compulsory December 1st

2003. The security mechanisms are different than 802.11i and WPA. These security mechanisms are not described.

802.11i experts from WiFi Alliance met with Chinese officials to share concerns regarding the WAPI standard. The Chinese SAC was not willing to delay the date, but would delay the onset of enforcement.

The security algorithm is not in the WAPI specification. The parameters are not finalized yet. The algorithm is not available to companies that are not Chinese. There was no specific solution offered for non-Chinese companies.

There may be efforts to harmonize the standards at some point in time.

The following letter was read by Stuart J. Kerry to the body:



2.7.3.7. Position statement in the 802.11i task group.

Meimei Dang Transmission and Access Research Department Institute of Communication Standards Research,CATR 11 Yue Tan Nan Jie Beijing,100045, P.R.China [email protected] Stuart Kerry Chairman, IEEE 802.11 Working Group c/o Philips Semiconductors, Inc. 1109 McKay Drive, M/S 48A SJ, San Jose, CA 95131-1706 [email protected] Dear Stuart, My name is Dang Meimei. I work in the Institute of Communication Standards Research in the China Academy of Telecommunication Research within the Ministry of Information Industry (MII). I am the managing engineer of transmission and access research department. As the first drafter and the leader, I am responsible for completing research on CCSA’s public wireless LAN (PWLAN) standard, which may potentially be adopted as a national PWLAN standard for China. We are interested in the use of IEEE 802.11 including its supplements for the MAC and PHY layers in our proposed standard. We are especially interested in 802.11i security model. To get the recent developments of 802.11 standard and assist our efforts of developing China PWLAN standards, we would like to request a formal liaison relationship with the 802.11 working group. We feel that this relationship would be beneficial to both organizations by allowing us to more freely exchange information on each of our efforts. From CCSA, I would propose that I be the liaison for our organization. Please let us know if the IEEE 802.11 working group is interested in establishing this relationship between our two organizations and can approve the formation of a formal liaison. Best Regards, Dang Meimei Nov 11th,2003



November 2003

D. Stanley, Agere, A. Khieu, HP, D. Halasz, CiscoSlide 2

doc.: IEEE 802.11-03/910r1

Submission

WAPI position• IEEE 802.11i was chartered by IEEE to specify MAC

enhancements for security – Plan to enter Sponsor Ballot November 2003– Ratification expected March/June 2004

• ISO has adopted IEEE 802.11 as an International Standard– IEEE 802.11 intends to advance the IEEE 802.11i amendment as

an ISO international standard

• The IEEE 802.11 process accommodates regulatory requirements– IEEE 802.11h and IEEE 802.11j for European and Japanese

regulatory requirements– Chinese security regulations could be similarly addressed

2.7.3.8. 2.7.3.9.

2.7.3.9.1. 2.7.3.9.2.

2.7.3.9.2.1. 2.7.3.9.2.2.

2.7.3.9.2.3.

2.7.3.9.2.4. 2.7.3.9.3.

2.7.4. 2.7.4.1.

2.7.4.2.

2.8.1. 2.8.1.1.

2.8.1.2.

2.8.1.3.

2.8.2. 2.8.2.1.

2.8.2.2.

2.8.2.3.

Motion: In regards to the Chinese national WLAN standards referred to as WAPI, Move to adopt document 03/910r1 as the Working Group’s position regarding WAPI.

Moved Dave Halasz on behalf of TGi Discussion

Request for a recap of the position. Terry Cole reports that ISO is in full support of

this position statement. Carl Stephenson 802.18 chair, has been

working with Dept of Commerce to prepare a letter to the Chinese encouraging them to open the standard. Wants to coordinate with that letter that will be brought the to closing plenary. The WG chair says it is appropriate to do both.

The motion is amended to document r1. Vote: Passes 131 : 0 : 4

Liaison Statement from Romantic Spain The purpose is resource management for multi-hop networks.

Richard Paine has requested clarification on what they want. Richard will liaison with Brian Matthews of Publicity.

2.8. New Business Special Event – 802.11h publication.

Stuart Kerry presents awards for the publication of 802.11h. A round of applause for Mika Kasslin, the TGh chair for his work. John Terry accepts an award for Mika Kasslin.

In addition, awards are presented to Andrew Myles, Simon Black, Terry Cole, and Al Petrick.

Certificates are presented to Peter Ecclesine, Christopher Hansen, Amjad Soomro, Evan Green, for their contributions to 802.11h.

UWB Position in ITU – Carl Stephenson TG18 met in ITUR. Discussed the needed protection criteria for

RLAN stations that have a primary allocation at 5GHz. 802.11a has a primary allocation in ITU, entitling protection from

services with lower regulatory status. A group of 802.11 experts needs to contribute a recommendation to ITU.

In addition 802.15.3a members will be allowed to participate as observers, but will not have veto power.



2.8.2.4. 2.8.2.5.

2.8.2.6.

2.8.2.7. 2.8.3.

2.8.3.1.

2.8.3.2. 2.8.3.3.

2.8.3.4.

2.8.3.5.

2.8.4. 2.8.4.1.

2.8.4.2. 2.8.4.3.

This group will meet today at 2:30 today in the 802.18 session. The objective is to determine what acceptable levels of interference

are for 802.11a RLANs. The proposal will be brought to the Friday plenary authorizing 802.18

to prepare a submission to ITU-R and seek approval from 802 ExCom. Al Petrick will represent the 802.11 chair at the meeting today.

ESS Mesh Network Study Group motion TK Tan reviews the contributions and discussions from Singapore.

The WNG group passed a motion to direct the WG to form a study group for ESS Mesh.

The vote will take place on Friday in the WNG motions time. The WG chair asks for volunteers. Steven Connor is a volunteer for

SG chair. Any other volunteers should contact Stuart Kerry. WNG also discussed Wireless Performance Prediction. A motion

passed to form a Wireless Performance Prediction SG. The vote will take place Friday.

We have a volunteer – Steve Berger. Other volunteers contact Stuart Kerry.

Pass Phrase for TGi Dave Halasz presents a response to the press articles on the use of

a pass phrase in the 802.11i draft. Document 03/932 The issue is the length of pre-shared keys. It is a matter of appropriate application of keys for the use. The draft already states the recommended length of the key. This paper calls attention to the appropriate sections in the draft.

The security characteristics of 802.11i are well understood. Motion: In regards to the article,

http://www.wifinetnews.com/archives/002452.html, move to adopt document 03/932r1 as the Working Group’s position. 2.8.4.3.1. 2.8.4.3.2. 2.8.4.3.3.

2.8.5. 2.8.5.1.

2.8.5.2.

2.8.5.3.

2.8.5.4. 2.8.5.5. 2.8.5.6.

2.8.5.7.

Moved Dave Halasz on behalf of TGi. Discussion – none Vote: Motion passes 118 : 0 : 6

Members Information Frank Howley gives a brief presentation on the inclusion of member

information, including contact information, in the WG minutes. There was a reflector message on this topic yesterday. This group has over 560 members, and it becomes difficult to work with members between meetings. We have stopped providing member’s contact information. Suggests that contact information be provided again for members who are willing to share it.

Stuart Kerry decides that this a procedural action, and has the right to decide it. He decides in favor of the motion and states that this will be forwarded directly to the Executive Committee on Friday. The ExCom still has the right to accept or reject.

Al Petrick states that the history has been that we present contact information. We were told by ExCom that we should not because of privacy issues. Only the IEEE maintains the contact information so they can contact individuals.

Stuart reaffirms that we will take this to the Executive Committee. Discussion In the past, we distributed the contact information on paper.

Comfortable with distributing the information in PDF format. We do need to be sure that it is not misused for commercial

purposes.


http://www.wifinetnews.com/archives/002452.html


2.8.5.8.

2.8.5.9. 2.8.5.10.

2.8.5.11.

2.8.5.12. 2.8.5.13.

2.8.5.14. 2.8.5.15.

2.8.5.16.

2.8.6. 2.8.6.1. 2.8.6.2.

3.1.1.

3.2.1.

3.2.2. 3.2.3.

3.3.1. 3.3.2. 3.3.3.

3.3.3.1.

3.3.4.

3.3.5.

3.3.6.

3.3.7.

3.3.8.

Supports releasing it in the format of Excel spreadsheet. There is no practical way to prevent misuse.

Would like the motion put to the body. The WG chair says the motion is out of order because the matter is

already decided. States that work in TGn has been impacted by lack of contact

information. Perhaps access could be limited to members only. Study Groups collect members names with contact information. LMSC also has to monitor for any one group dominating the

proceedings. Would it be helpful to get a show of support within 802.11. If we provide information, it should be in the form of PDF that does

not allow text cut and paste. Straw Poll – are members in favor of providing contact information?

154 for, 19 against, 18 abstain Recess at 12:30 PM

3. Closing Plenary, November 14, 2003 3.1. Opening

The meeting is called to order at 8:20AM by Stuart J. Kerry. The agenda is in 03/805r2.

3.2. Agenda The chair reviews the agenda for today’s session. We will finish at 12:30PM at the latest today. Any objection to adopt the agenda as presented? No objection. The agenda is adopted with unanimous consent

3.3. Announcements The CAC agenda has been posted. The TG minutes are due one week after this meeting. The WG chair asks for the group’s reaction to the even 2 hour slot change at this meeting?

When we overlap with groups that do not have the same meeting, we need to adjust the timing of the food and drink at breaks.

The WG chair encourages the group to bring new activities to the group so we can continue development, and as time is available as TG’s complete. The letter from Romantic has been transcribed and loaded on the server as document 975. There is a consideration of splitting 802 into wired and wireless sub groups to improve logistics. Another possibility is to improve the policies and procedures of 802 to make it work better. The Executive Committee will be on-site in January. Discussions will continue there Request for links on our reflector to items on the executive committee pages that relate to the splitting topic.



3.4. IP Statements 3.4.1. 3.4.2.

3.5.1.

3.5.2. 3.5.3.

3.6.1. 3.6.1.1. 3.6.1.2.

3.6.1.3. 3.6.1.4.

3.6.1.5.

3.6.1.6.

3.6.1.7.

3.6.2. 3.6.2.1. 3.6.2.2. 3.6.2.3. 3.6.2.4. 3.6.2.5. 3.6.2.6.

3.6.3. 3.6.3.1.

3.6.4. 3.6.4.1. 3.6.4.2. 3.6.4.3. 3.6.4.4.

3.6.5. 3.6.5.1. 3.6.5.2. 3.6.5.3. 3.6.5.4. 3.6.5.5.

The chair calls for any new IP statements. There are none. The chair asks if anyone is not aware of the IEEE IP policies? None

3.5. Documentation update The system is working well. It is the members responsibility to ensure that the formatting is correct. We are over 900 documents for the year so far. The policies and procedures require 4 hour posting in advance

3.6. Reports TGe – John Fakatselis

Report in 03/977 We have completed all resolutions for LB59. Draft 6.0 has been

approved for recirculation We are requesting LMSC procedure 10 to expedite the process. John explains the plan of procedure 10 so everyone can be prepared

for the votes in the motions section. It prevents waiting for the next Executive Committee to get approved for Sponsor Ballot.

The last condition requires that the recirculation not have any technical changes before going to sponsor ballot. We don’t know what the comments will be. The group can decide to leave 6.0 without changes and move forward with sponsor ballot.

If we have comments that require changes, we will follow a different path with interim meetings between meetings in January and February.

Next meeting objective will review comments from Recirculation – either forward to Sponsor Ballot, or recirculation

TGi – Dave Halasz Report in document 03/975 Will proceed to Sponsor Ballot LB62 had 95% approval. Editorial comments were addressed. 11 of 14 no voters changed to Yes votes. WAPI status and position are reflected in document 913 and 910. Next meeting will address comments from sponsor ballot.

Special Recognition There was an error in the awards for TGh. The chair recognizes Carl

Temme as the Study Group chair of TGh. TGj – Sheung Li

Report in document 03/799r0 Adopted draft 1.2 Comment resolutions in 03/337r6 Will request a recirculation ballot. There will be a motion to approve

resolutions, and invoke LMSC procedure 10 to go to Sponsor ballot TGk – Richard Paine

Report in document 03/979r1 Voted and accepted a MIB Group did not vote to go to Letter Ballot Remaining issues – signal quality, and security of action frames. Objectives of January – clean up specification, prepare for Letter

Ballot in March.



3.6.5.6. 3.6.6.

3.6.6.1. 3.6.6.2.

3.6.6.3.

3.6.6.4.

3.6.7. 3.6.7.1. 3.6.7.2. 3.6.7.3. 3.6.7.4.

3.6.7.5. 3.6.7.6. 3.6.7.7. 3.6.7.8.

3.6.7.9. 3.6.8.

3.6.8.1. 3.6.8.2. 3.6.8.3. 3.6.8.4. 3.6.8.5. 3.6.8.6.

3.6.8.7.

3.6.8.7.1. 3.6.9.

3.6.9.1.

3.6.9.2. 3.6.10.

3.6.10.1. 3.6.10.2.

3.6.10.3. 3.6.10.4. 3.6.10.5.

3.6.10.6.

3.6.10.7. 3.6.10.8.

3.6.10.8.1.

Will conduct weekly teleconferences Starting Dec 3rd. TGm – Bob O’Hara

Report in document 03/874r0 Meeting was dedicated to resolving one interpretation request

related to key mapping. Response in document 03/875. Will continue to address items from document 03/619 with other

maintenance items. Volunteers are requested to help on these items. Harry Worstell shows that the interpretations are posted on our web

site. It is under “Working Group” on the drop down menu, listed as “Interpretations”.

TGn – Garth Hillman Report in document 03/962r0 There were 20 general submissions Minutes in 831r0 Approved channel models, elected chair of functional requirements

and comparison criteria Usage models in 03/802r6 Usage models and functional requirements were not adopted. Comparison criteria were not started, will be picked up in January Call For Proposals will be issues when these preceding steps are

complete. Not before the end of the January meeting. Teleconferences will be held for the FRCC committee.

Publicity – Brian Mathews Report in document 03/976 Received reports from trade groups. WiMedia report in 15-03-485r0. WiFi alliance report in 03/903 Received a report from Via Licensing Reviewed PSK usage white paper, WAPI standards activity and

position, The chair ask if there are any objections to moving up the ANA item

to now? No Objection

ANA Report – Duncan Kitchin There was a request for 6 status codes for TGe. It has been issued

in R10 of the document. Other requests can be processed by email to Duncan Kitchin.

WNG SC – TK Tan Report in document 03/849r1 Covered wireless InterWorking, ESS mesh networking, Wireless

performance prediction. Will request formation of a SG for ESS mesh networking. Review scope and plans for ESS Mesh SG. Will move to form a study group on Wireless Performance Prediction

(WPP). Intention is to standardize prediction and evaluating WLAN systems.

Hoping to establish common metrics and test methodology. There was discussion on the differences between WPP and TGk. Discussion

The primary purpose for the meeting with TGk was to potentially form another Task Group. TGk was looking to



manage the wireless network as part of a wired network. The straw poll (57 : 1) to form a new SG of TGk. They are complementary to the WPP activities.

3.6.11. 3.6.11.1. 3.6.11.2. 3.6.11.3. 3.6.11.4.

3.6.11.5.

3.6.11.6.

3.6.12. 3.6.12.1.

3.6.12.2. 3.6.12.3.

3.6.13. 3.6.13.1. 3.6.13.2.

3.6.13.3. 3.6.13.4.

3.6.13.5. 3.6.13.5.1.

3.6.13.5.2.

3.6.14. 3.6.14.1. 3.6.14.2.

3.6.14.3. 3.6.14.4. 3.6.14.5.

3.6.15. 3.6.15.1. 3.6.15.2. 3.6.15.3. 3.6.15.4.

3.6.15.5.

Fast Roaming SG – Clint Chaplin Report in document 03/978 Voted to accept a draft PAR and 5C Study Group will be extended. Further changes to PAR and 5C will be accepted in January. They

will be forwarded for approval out the January meeting. The chair asks if there are any volunteers for the chair of the Fast

Roaming SG. None. Stuart Kerry appoints Clint Chaplin as the chair of the Fast Roaming

Study Group. The body accepts the appointment by acclamation. Wave SG – Lee Armstrong

The meeting this week was spent on refining the PAR and 5C. The output documents are PAR in 03/943r4 and 5C in 03/967r3

There will be a motion to accept these documents. In January group will continue to review the technical details of

requirements WG Technical Editor – Terry Cole

Report in 03/197r6 Will be working with TGe and TGi and TGj as they enter Sponsor

Ballot and move towards publication. Editors met and held tutorial on FrameMaker. The WG chair notes that Terry Cole was given an award for his

contribution in the 2003 edition of 802.11 Discussion

Is the 802.11-2003 version available? The 2003 edition is available for sale in the “value pack” In addition the original documents are included. It is $150. Includes an interactive PICS form and merged SDL files and compile-able MIB.

In the private members area of 802.11 the “802.11 compilation” is available to voting members.

802.18 RR TAG – Carl Stevenson Report in document 802.18-03-076 Prepared regulatory documents for FCC activities. Unanimously

approved by 802.16 and 802.15. Approved letter from 802 to China on WAPI. Will bring motion on protection criteria for RLANs to ITU. Approved SG to study use of unoccupied TV spectrum by unlicensed

devices. 802.19 Coex TAG – Steve Shellhammer

Report in document 802.19-03-030r3 Jim Lansford has stepped down, and Steve is acting interim chair. Re-evaluated TAG charter – simplified and clarified. Developed proposals for LMSC policies and procedures, for the

steps wireless groups would follow to ensure coexistence while developing standards. Will develop guidelines to predict interference. Will offer technical opinion on interference analysis on request of ExCom or wireless working groups. This would be done on a draft.

Will meet two times in Vancouver. Need volunteers to work on this. Have about 6, want to get above 10 people.



3.6.15.6. 3.6.15.6.1.

3.7.1. 3.7.1.1.

3.7.1.1.1. 3.7.1.1.2.

3.7.1.1.3. 3.7.1.1.3.1.

3.7.1.1.4. 3.7.1.2.

3.7.1.2.1. 3.7.1.2.2.

3.7.1.3.

3.7.1.3.1. 3.7.1.3.2.

3.7.1.4.

3.7.1.4.1. 3.7.1.4.2.

3.7.2. 3.7.2.1.

3.7.2.1.1. 3.7.2.1.2.

3.7.2.2.

3.7.2.2.1. 3.7.2.2.2.

3.7.2.2.2.1.

3.7.2.2.2.2.

3.7.2.2.2.3.

Discussion Request that 802.19 liaison with 802.18. There will be

liaisons to all wireless working groups.

3.7. Standing Orders – Motions TGe

Motion to enable the editor to produce 802.11e draft 6.0 based on the comment resolutions in 11-03/658r17 and, authorize a 15-day LB recirculation of 802.11 TGe draft 6.0 to conclude no later than 12/20/2003.

Moved John Fakatselis on behalf of TGe The WG Vice Chair is able to initiate the ballot in that

time frame Discussion

None Vote on the motion: passes 103 : 0 : 1

Move to Request approval of a SB for draft 802.11e 6.0 by ExCom using LMSC Procedure 10 assuming that the conditions required for procedure 10 are met.

Moved John Fakatselis on behalf of TGe Vote on the motion: passes 106 : 0 : 1

Move to Authorize TGE to hold an interim meeting for the week of February 16, 2004 to resolve comments from the most recent 802.11e recirculation ballots, and to initiate any follow on letter ballots after resolving those comments as required.

Moved John Fakatselis on behalf of TGe Motion passes with unanimous consent

Move to Authorize the 802.11 January 2004 interim meeting to resolve comments from the most recent 802.11e recirculation ballot and to initiate any follow on letter ballots after resolving those comments.

Moved John Fakatselis on behalf of TGe Motion passes with unanimous consent

TGi Motion: Believing that comment responses in the document 03/842r3

and the IEEE 802.11i draft 7.0 demonstrate that the IEEE 802.11 WG Letter Ballot rules have reached an orderly endpoint, approve comment responses in document 03/842r3 and request the IEEE 802.11 WG Chair to move the IEEE 802.11i draft 7.0 to Sponsor Ballot at the Excom meeting on November 14th, 2003.

Moved Dave Halasz on behalf of TGi Vote on the motion: Passes 110 : 0 : 0

Motion: Request the IEEE 802.11 Working Group chair to make the IEEE 802.11i draft 3.0 available for purchase even when future IEEE 802.11i drafts and IEEE 802.11 standards are available.

Moved Dave Halasz on behalf of TGi Discussion

Inquiring: Explain the rationale. The WiFi Alliance WPA references this draft.

Against: 802.11i has said that the content of D3.0 is obsolete. We should make the statement that compliance is based on the current, correct drafts. The WFA should work out a way to make it available privately.

In favor: everyone knows it takes years to get a standard approved. We need a way to get implementers



to bring to market things that are not yet final standards. We might as well state our approval here.

3.7.2.2.3.

3.7.2.2.3.1. 3.7.2.2.3.2. 3.7.2.2.3.3.

3.7.2.2.4.

3.7.2.3.

3.7.2.3.1. 3.7.2.3.2.

3.7.3. 3.7.3.1.

3.7.3.1.1. 3.7.3.1.2.

3.7.3.2.

3.7.3.2.1. 3.7.3.2.2.

3.7.3.2.3. 3.7.3.2.3.1.

3.7.3.2.4. 3.7.3.3.

3.7.3.3.1. 3.7.3.3.2.

3.7.4. 3.7.4.1.

3.7.4.1.1. 3.7.4.1.2. 3.7.4.1.3.

3.7.4.1.3.1.

3.7.4.1.4. 3.7.5.

Move to table until the IEEE and WFA can get together and discuss.

Moved Harry Worstell Second Bob O’Hara Vote: Passes: 49 : 30 : 29

The WG chair will take this to the 802 chair and request an official position

Move to empower TGi to hold meetings beginning in January 2004 as required to conduct business necessary to progress the Sponsor Ballot re-circulation process, including creating and issuing drafts for Sponsor Ballot re-circulation, conducting teleconferences, and handling other business necessary to progress through the IEEE standards process.

Moved Dave Halasz on behalf of TGi The motion is approved by unanimous consent.

TGj Motion: Believing that comment responses in the document

mentioned below and the draft mentioned below 802.11j draft 1.2 demonstrate that the WG 802.11 LB rules have reached an orderly endpoint, approve comment responses in 11-03/337R6.

Moved Sheung Li on behalf of TGj The motion is approved by unanimous consent

Motion: Believing that comment responses in 11-03/337R6 and the draft mentioned below satisfy WG 802.11 rules for letter ballot recirculation and that a recirculation will likely result in approval of the draft, authorize a 40-day LB recirculation of 802.11j draft 1.2 to conclude no later than 1/9/2004 and request approval of a SB for draft 1.2 by ExCom using Procedure 10.

Moved Sheung Li on behalf of TGj Sheung notes that the LB is for 40 days to allow

members more time to familiarize themselves with the contents. Broady Cash will be present at the ExCom meeting to represent this motion.

Discussion Do we need additional language for procedure

10? No – it is well-known and specific. Vote on the motion: Passes 94 : 0 : 6

Move to authorize the 802.11 January 2004 interim meeting to resolve comments from the most recent 802.11j recirculation ballot and to initiate any follow on letter ballots after resolving those comments

Moved Sheung Li on behalf of TGj Motion passes by unanimous consent

TGk Move to authorize TGk to hold weekly teleconferences in 2004 from

Jan 1 until 30 days after the March plenary. Moved Richard Paine Seconded Peter Ecclesine Discussion

Is this required in the new P&P? The chair affirms that it is. The motion passes with unanimous consent

TGm



3.7.5.1.

3.7.5.1.1. 3.7.5.1.2.

3.7.6. 3.7.6.1.

3.7.6.1.1. 3.7.6.1.2.

3.7.6.1.2.1.

3.7.6.1.2.2. 3.7.6.1.3.

3.7.6.2.

3.7.6.2.1. 3.7.6.2.2.

3.7.6.2.2.1.

3.7.6.2.2.2.

3.7.6.2.2.3.

3.7.6.2.2.4.

3.7.6.2.2.5.

3.7.6.2.2.6.

3.7.6.2.2.7.

3.7.6.2.2.8.

3.7.6.2.3. 3.7.6.2.3.1.1.

3.7.6.2.4. 3.7.7.

3.8.1. 3.8.1.1.

3.8.1.1.1. 3.8.1.1.2.

3.8.1.1.2.1.

Motion: to request the working group to accept and forward the interpretation response contained in document 03-875r0 to Linda Gargiulo at the IEEE office as the official response of the 802.11 working group.

Moved Bob O’Hara on behalf of TGm The motion is passed with unanimous consent.

WNG Move that WNG request 802.11 Working Group to form a Study

Group for IEEE 802.11 ESS Mesh. Moved TK Tan on behalf of WNG Discussion

Regarding work going on at 802. ExCom level. Do we have the appropriate scope within 802.11 and within 802? Coordination is needed, but this is an SG, where the scope will be defined.

The chair recommends that a SG is appropriate Vote on the motion: passes 88 : 4 : 17

Move that WNG request 802.11 Working Group to form a Study Group for Wireless Performance Prediction (WPP)

Moved TK Tan on behalf of WNG Discussion

We have a lot of Study Groups. This is not a protocol change, but testing. This work should be done elsewhere.

This is appropriate for 802.11. It will not produce a standard, just recommended practices.

Against: but would support if limited in scope to performance of the MAC. The chair notes that the scope will be addressed in the SG.

Supports: this is the group that has the expertise to formulate metrics.

In favor: SGs are appropriate to explore the possibilities and sort out the scope.

In favor: it is premature to judge the outcome of the SG before it starts. It is a relevant topic.

Against: the WG needs to make standards, not comparison protocols.

For: the SG determines whether there is a need. Not all SGs result in a TG. We are not limited to layers 1 and 2. Call the question (Harry Worstell / John Kowalski)

Vote on calling the question: Passes 77 : 14 : 5

Vote on the motion: Passes 66 : 30 : 23 Recess for 30 minute break

3.8. Standing Orders – Motions – continued Fast Roaming SG

Request the IEEE 802.11 Working Group to extend the Fast Roaming Study Group for another 6 months

Moved Clint Chaplin on behalf of FRSG Discussion

Don’t the LMSC rules say that SG’s exist from Plenary to Plenary? Yes, but this one is running out of time due to the delayed start.



3.8.1.1.3. 3.8.2.

3.8.2.1.

3.8.3. 3.8.3.1.

3.8.3.1.1. 3.8.3.1.2. 3.8.3.1.3.

3.8.3.1.3.1.

3.8.3.1.3.2.

3.8.3.1.3.3.

3.8.3.1.3.4.

3.8.3.1.4. 3.8.3.2.

3.8.3.3. 3.8.3.4. 3.8.3.5. 3.8.3.6. 3.8.3.7.

3.8.3.7.1. 3.8.3.8.

3.8.4. 3.8.4.1.

3.8.4.1.1. 3.8.4.1.2. 3.8.4.1.3.

3.8.4.2.

3.8.4.2.1. 3.8.4.2.2. 3.8.4.2.3.

3.8.4.3.

Motion is passed with unanimous consent. Special announcement

Denis Kuahara expresses thanks for the concern and support of the body over the accident of his wife.

WG Motions Move to operate the IEEE 802.11 Working Group with a treasury, per

policies and procedures of November 12, 2003, document 00/331r7 section 2.11, item 1.

Moved Harry Worstell Second Carl Stevenson Discussion

This enables us to host our own interim meetings, and fund internal activities.

The chair notes that this brings us fully in alignment with 802 LMAC Policies and Procedures. We have a joint bank account with 802.15.

The signatures on the account are Stuart Kerry, Bob Heile, Paul Nicolich, and the IEEE contracts administrator.

Is 802.15 doing the same process and voting? Yes. We will hold the bank account, and also host 802.18 and 802.19. Vote on the motion: passes 84 : 0 : 0

The WG chair notes that now we have a treasury, we need a treasurer. Bill Carney has volunteered for this position. It is an appointed position by the chair.

Harry Worstell and Al Petrick will reverse roles. Al Petrick will handle policies and treasurer pro-tem. Harry Worstell will handle attendance, ballots, and documentation. Stuart Kerry appoints Al Petrick as the treasurer for 802.11. Is there any objection?

Is that pro-tem or permanent? It is until March 2004. The body accepts Al Petrick as treasurer by acclamation.

802.18 motions Motion to approve document 18-03-0072-01-0000-RR-

TAG_reply_comments_to_ET 03-137.doc, authorizing the Chair of 802.18 to do necessary editorial and formatting changes, seek EC approval as an 802 document, and file the document in a timely fashion with the FCC.

Moved Carl Stevenson Second Denis Kuahara Motion is approved by unanimous consent

To approve document 18-03-0073-00-0000_Cmts_ET_03-201_Pt15.doc, authorizing the Chair of 802.18 to do necessary editorial and formatting changes, seek EC approval as an 802 document, and file the document in a timely fashion with the FCC.

Moved Carl Stevenson Second Denis Kuahara Motion is approved by unanimous consent

Motion to approve document 18-03-0077-00-0000_WAPI_letter_To_China.doc, authorizing the Chair of 802.18 to do necessary editorial and formatting changes, seek EC approval as an 802 document, and deliver the letter in a timely fashion on behalf of 802 as delegated by the Chair.



3.8.4.3.1. 3.8.4.3.2. 3.8.4.3.3.

3.8.4.4.

3.8.4.4.1. 3.8.4.4.2. 3.8.4.4.3.

3.8.4.4.3.1.

3.8.4.4.4. 3.8.4.4.4.1.

3.8.5. 3.8.5.1.

3.8.5.1.1. 3.8.5.1.2.

3.8.5.1.2.1.

3.8.5.1.3. 3.8.5.1.4. 3.8.5.1.5.

3.8.5.2.

3.8.5.2.1. 3.8.5.2.2.

3.8.5.2.2.1.

3.8.5.2.2.2. 3.8.5.2.3.

3.9.1. 3.9.1.1.

3.9.1.2.

Moved Carl Stevenson Second Dave Halasz Motion is approved by unanimous consent

Motion to authorize the Chair of 802.18 to seek EC approval to craft an appropriately formatted (ITU-R format) input contribution for the upcoming meetings of ITU-R JRG 8A/9B and WP8A that accurately embodies the substance of the RLAN protection criteria agreement embodied in document 18-03-0078-00-0000_RLAN_protection_criteria.doc, and to submit the document to the ITU-R on behalf of IEEE 802 and present and advocate for it from the floor during the ITU-R meetings as necessary.

Moved Carl Stevenson Second Denis Kuahara Discussion

Was this also discussed in 802.15? What was the reaction? This document is the minutes of the joint meeting of 802.18 with experts from 802.11 and from 802.15. The 802.15 members were asked if they felt this was reasonable, and they were in favor. The motion passed unanimously in 802.15. Motion is approved by unanimous consent

Spectrum in the US is difficult to come by. The FCC has approved 255 MHz of spectrum in the UNII band. Carl has been instrumental in helping this process. The group gives Carl Stevenson a round of applause

WAVE Move to approve the PAR document IEEE 802.11-03/0943r4, and 5

Criteria document IEEE 802.11-03/0967r3, for WAVE, and forward to ExCom for Approval.

Moved Lee Armstrong on behalf of WAVE SG Discussion

The chair notes that the ExCom approval will be in March 2004 Vote on the motion: Passes 60 : 3 : 16. Discussion Is this technical or procedural. The chair notes that the

LMSC rules say PAR approvals require 75%. Moved: In order to accelerate the development of the document

proposed in the WAVE PAR (IEEE 802.11-03/0943r4 ), move that the WG extend the SG for another six months and authorize the WAVE SG to undertake investigative work beginning at the January meeting.

Moved Lee Armstrong Discussion

6 months would take you past the May meeting, and this TG would meet in May.

The ExCom authorizes the 6 month extension. Vote on the motion: Passes 64 : 0 : 8

3.9. WG Reports Virus protection policy.

Al Petrick presents document 03/981r0. This action was a response to the actions initiated in September.

5% of the attendees were infected with viruses and worms. 11 of the 48 infected people didn’t come forth. 5 of them had no virus protection, the remaining had not updated.



3.9.1.3.

3.9.1.4.

3.9.1.5.

3.9.1.6.

3.9.1.7.

3.9.1.8.

3.9.1.9.

3.10.1. 3.10.1.1. 3.10.1.2. 3.10.1.3.

3.10.1.3.1. 3.10.1.3.2. 3.10.1.3.3.

3.10.1.3.3.1.

3.10.1.3.4. 3.10.2.

3.10.2.1.

3.10.2.2. 3.10.2.2.1.

3.10.2.2.2.

3.10.3. 3.10.3.1.

3.10.3.2. 3.10.3.2.1.

Virus protection with current updates, MS patches, and personal firewalls are all necessary.

We will continue to monitor the level of infections. We will provide a notice to member to remind them to ensure their security protections are up to date and active.

If problems increase, we will institute more restrictive policies and procedures.

Rather than wait until January, could we publish information on the reflector? To help members get updated.

Some members are limited by IT departments regarding what they can install. How important are the personal firewalls? We will look into this.

Recommend that this on the session info page when registration is done for the meetings.

What action was taken when members were found to be infected? We trap clients that are probing IP addresses. They are shown a message when they try to log in.

3.10. New Business Publicity

Authorization of external communication Document 987 Motion: Noting that the document 11-03-0910r1 has been approved

as a WG position on WAPI, approve transmission of aforementioned document to a representative of the CCSA standards project in China responsible for developing WAPI.

Moved Brian Mathews Second Carl Stevenson Discussion

Do we need ExCom approval for this action? This will be from the WG chair. It will be posted with the 802 chair. Other letters from other wireless WGs will be added to this. The motion is approved with unanimous consent

Technical Editor Information item: There have been questions about the relation with

ISO. Terry Cole has started correspondence with Robin Tasker on the topic. He informs us that the approval process in ISO is a 2 step process. There are 2 ballots – a procedural check (Concluding Nov 28th), followed by a 90 day discussion ballot for comment. The results are forwarded to the 802.11 WG, where we resolve comments.

Discussion Could that information be written up and put on the

server, and posted to the reflector? Yes – Terry is somewhat reluctant to quote rules of

another group, but will provide something. 802.18

Information item: Carl Stevenson states the ITU-R council approved IEEE as a fee-waived sector membership which will allow us to input contributions into the ITU-R process as we see fit. We no longer have to have sponsoring member states. This will benefit IEEE substantially.

Discussion Will we gain access to ITU documentation? We are in

the process. We will need a member to manage the account. Carl Stevenson has offered to fulfill that role.




3.10.4. 3.10.4.1. 3.10.4.2.

3.10.4.3. 3.10.4.4. 3.10.4.5.

3.11.1.

Discussion of 802.11i D3.0 Stuart Kerry reviews the vote of the body on the vote on this topic. Jerry Walker of the IEEE staff says that we can make both draft

version available. This group tabled the motion because of dissenting views. It appears that the IEEE has a new flexibility on the matter. This will be brought up in the 802 ExCom meeting this afternoon.

3.11. Next Meeting The next meeting of 802.11 is January 11-16, 2004, at the

Hyatt Regency Vancouver, Vancouver, BC, Canada. The discount link for booking is not yet available.

3.12. The meeting is adjourned at 11:36AM

Last Name First Name Middle InitialAbbas FazalAboul-Magd Osama SAkahane MasaakiAlapuranen Pertti OAlexander ThomasAlimian AregAllen James D.Allen Kenneth CAllen Richard CAmer KhaledAnandakumar AnandAndelman DovAndrade Merwyn BAndren Carl F.Andrus David CAnton ButchAoki HidenoriAoki TsuguhideAramaki TakashiArmstrong Lee RArnett LarryAsai Hiroshi nullAsai YusukeAudeh MalikAwater Geert ABagby DavidBain JayBaker Dennis JBalachander Ramanathan nullBalakrishnan JaiganeshBarach David MBarber SimonBari FarooqBarkway Michael IBarr John R.Barry Kevin M.Bartel Charles R.Batta GautamBaysal Burak HBeck William BBenveniste MathildeBerger StephenBiba KenBilstad Arnold nullBims Harry

Black SimonBoer JanBonneville HerveBrasier William MBray Jennifer ABugeja AlexButtar Alistair GCam-Winget NancyCarney BillCarson PatCash Broady BChang KisooChaplin Clint FChen YeCheng HongChindapol AikChinitz Leigh MChoi Won-JoonChoi Yang-SeokChung ByunghoChung SimonCiotti FrankCoffey SeanCole Terry LConkling CraigConner W. StevenCook Charles ICook KennethCramer Mary ECrowley StevenCzoma BalazsDaneshrad BabakDe Vegt Rolf JDel Prado Pavon JavierDoi YoshiharuDonovan DaveDundar Baris BDurand Roger PDycian YaronEcclesine PeterEdney Jonathan PEdwards BruceEllis JasonEngwer DarwinErwin JeffEstrada Andrew X

Evans AllanEvensen KnutFakatselis John C.Falk Lars PFamolari DavidFantaske Steve WFeinberg Paul H.Feldman AlexFischer Matthew JFlygare HelenaFord BrianFormoso Ruben RFrigon Jean-FrancoisGarrett Albert LGerges Ramez LGhazi VafaGhosh MonishaGilb James P KGilbert Jeffrey MGodfrey TimGohda WataruGoldstein YuriGoren AvivGowans Andrew JGraulus RikGray Gordon PGreer Kerry LGuirguis SamGummadi SrikanthGupta RajeevGupta Vivek GHaisch Herman FHalasz David EHalford Steven DHamady Neil NHansen Christopher JHarada YasuoHarkins Daniel NHaslestad ThomasHasty VannHauser James P.Hayakawa Yutaka nullHe HaixiangHe XiaoningHermodsson Frans MHetherington Dave

Hiertz Guido R.Hillman Garth DHinsz Christopher SHjelm MikaelHock DouglassHollister AllenHorne William DHosur SrinathHowley Frank P.Hsu Yungping AHudak David E.Hunter DavidIkram Muhammad ZImamura DaichiInoue YasuhikoJackson Stephen SJacobsen Eric AJaewook ShinJang KyungHunJang Yeong MinJeannerod LaurentJechoux BrunoJeon TaehyunJeon Young-AeJeong Moo RyongJeong YeonkwonJiang DanielJimi KunikoJokela Jari EJones Christopher R.Jose BobbyKain Carl WKalker TonKandala SrinivasKarcz Kevin JKarimullah KhalidKarnik Pankaj RKawaguchi DeanKelly PatrickKennedy RichardKerry Stuart JKetchum John W.Khieu Andrew KKido RyojiKikuma TomohiroKim Byoung-Jo

Kim Nak MyeongKim YongbumKim YongbumKim YongsukKim YoungsooKitchin DuncanKlein John RKoga KeiichiroKowalski John MKraemer Bruce PKrishnan Gopal VKroninger RobertKubota ShujiKuehnel ThomasKumagai TomoakiKunihiro TakushiKuran ShihabKurihara Thomas MKuwahara DenisKwak JoeLAW Choi LLambert PaulLanzl ColinLau Vincent KinLeach David J.Lee DongjunLee HaeDongLee Jeong TaekLee Sok-kyuLefkowitz MartinLemieux MichaelLevy JosephLewis MikeLi QinghuaLim Sun BaeLim Wei LihLim Yong JeLiu Der-ZhengLiu I-RuLiu YongheLoc PeterLu XiaolinLung Yi-JenMahadevappa Ravishankar HMalik RahulMancini Massimiliano

Martell Jonn GMathews BrianMatsumoto YukinoriMatsuo RyokoMatta SudheerMcCann StephenMcGovern TimothyMcIntosh Bill JMcNew Justin PMedvedev IrinaMehta MehulMehta PratikMiller Marc CMiller Robert R.Mishra ParthoMiyoshi KenichiMonteban LeoMontemurro MichaelMoore Rondal JMoore Tim MMoreton MikeMorioka YuichiMorley Steven A. Mourot patrickMueller JosephMujtaba Syed AonMulder WillemMurphy Peter AMyles AndrewNagai YukimasaNaka KatsuyoshiNakahara MakotoNakao SeigoNakase HiroyukiNanda SanjivNarasimhan ParthaNarasimhan RaviNelson David B.Ngo ChiuNguyen Tuan PNissani (Nissensohn) Daniel NNoble ErwinO'Hara BobO'Hara Sean TOakes Ivan FObara Kei

Oguma HiroshiOhtani YoshihiroOlson Timothy SOno HiroshiOomen PeterOyama SatoshiPARK SOON-JOONPaine Richard HPalm StephenPark Chan YPark Joon GooParker SteveParsons GlennPatel VijayPerahia EldadPetrick AlPetroni Nick LPitarresi JoePluswick LeoPope Stephen PPotter AlPtasinski HenryPuri AnujPurkovic AleksandarRaab Jim ERajkumar AjayRangwala NomanRasor GreggReible Stanley AReuss EdwardRhodes Valentine JRing Edmund JRommer StefanRude MichaelSadowsky John SSakurai ShojiSampath HemanthSawai RyoSchaffnit TomSchreder BrianSeals MichaelSensendorf JoeSeo Chang WooSeo MyunghwanShah Biren IShan Peijun

Shankaranarayanan N. K.Sharony JacobShellhammer Stephen JSherlock IanSherman Matthew JShimada ShusakuShin Byung CShvodian William MShyy D. J.Simpson FloydSingh ManoneetSinivaara Hasse KSoomro AmjadSoranno Robert TSpiess Gary NSpurgeon William LStanley DorothySteck William KStephens Adrian PStevens William MStevenson Carl R.Stivers Fred SSu Michael C.-MSumanasena AbhayaSung SKSurineni Shravan KTAGIRI HIROKAZUTakagi MasahiroTakai MineoTakeda DaisukeTal NirTamaki TsuyoshiTan Teik-Kheong nullTanaka HidekiTang Wai-CheungTaniguchi TomohikoTanimoto TakumaTaylor Henry CTee Lai-King AnnaTemme CarlTerry John DThornton Timothy JThrasher JerryTomcik James D.Tsao JeanTsien Chih C

Tsurumi HiroshiTuch BruceTung DavidTurner Sandra LTzamaloukas Mike EUchida YusukeUeda TakashiUmehira MasahiroUrano NaokiVan Erven NielsVan Nee Richard D.J.Van Poucke BartVlantis George AVogtli NanciVon Herzen BrianWallace Brad AWandile VivekWang ArthurWang HuaiyuanWang StanleyWare Christopher GWatanabe FujioWatanabe FujioWells BryanWentink Menzo MWeytjens FilipWilhoyte Michael EWilliams Michael GlennWilliams RichardWilson James MWilson Steven KWinters Jack HWong Jin KueWong Timothy GWorfolk PatrickWorstell Harry RWright Charles RYANG YU-RENYee JamesYee JungYin JijunYokokawa TakashiYoon WonyongYu HeejungYu Patrick WYung Hon M

Yurtkuran Erol KZhong ZhundaSilva Marcusimamura kimihikosaracino concitaten Brink Stephanvan Leeuwen Richardvan Waes Nico J

November 2003 doc.: IEEE 802.11-03/xxxr0 IEEE P802.11 Wireless LANs

Minutes of 802.11 Task Group E MAC Enhancements - QoS

Albuquerque, New Mexico

Date: November 10-14, 2003

Author: David Hunter Vetronix / Bosch Phone: 805 966 2000 x3145 e-Mail: [email protected]

1. 4pm Monday Afternoon, November 10, 2003

1.1. Opening

1.1.1. 1.1.1.1.

1.2.1. 1.2.1.1.

1.2.1.2. 1.2.1.2.1.

1.2.1.2.2. 1.2.1.2.3. 1.2.1.2.4.

1.2.2. 1.2.2.1. 1.2.2.2.

1.2.2.3. 1.2.2.4.

1.2.2.5.

Call to order John Fakatselis (JohnF) called the meeting to order at 4:10pm (delayed due to

equipment setup).

1.2. Agenda

Review of the agenda (JohnF) Tentative meeting agenda: 11-03-805sjk1-W-802.11-WG-Tentative-Agenda-

November-2003.xls JohnF reviewed the proposed agenda.

Fixed Time agenda items will be handled at 4:45pm Thursday, November 13, 2003.

Review minutes from previous meeting. Call for papers. The Fixed Time agenda Items are listed on the agenda.

Approval of the agenda JohnF: Are there any comments on the agenda? David Hunter (DavidH): Propose that an item be included just before the last line

(to adjourn at 6:00pm) to continue the Technical Discussion, time permitting. JohnF: Fine; am making these changes. JohnF: I ask the voting members, are there any objections to approving this new

version of the agenda? JohnF: I see no objections, so we have an agenda for this meeting.

Minutes of 802.11 Task Group E, Novtember 2003 page 1 David Hunter, Vetronix/Bosch

November 2003 doc.: IEEE 802.11-03/xxxr0 1.3. Recirculation Ballot Discussion

1.3.1. 1.3.1.1.

1.3.1.2.

1.3.1.3. 1.3.1.4.

1.3.1.5. 1.3.1.6.

1.3.1.7.

1.3.1.8. 1.3.1.9. 1.3.1.10.

1.3.1.11. 1.3.1.12.

1.3.1.13. 1.3.1.14.

1.4.1. 1.4.1.1.

1.4.1.2.

1.4.2. 1.4.2.1.

1.4.2.2. 1.4.2.3.

1.4.2.4.

Recirculation vs. Letter Ballot Jennifer Bray (JenniferB): Is it legitimate to make another recirculation ballot,

instead of having a new Letter Ballot? Aren’t there more changes than that? JohnF: The recirculation ballot addresses just the comments that have been

made. JenniferB: Can any member comment? JohnF: The next ballot will go to the current ballot membership, though anyone

can make comments. JenniferB: As a new member I object to being locked out of voting. JohnF: Yes you will be locked out, but you can participate on anything we

discuss here. We do have to obey the general WG rules, including the fact that the Letter Ballot passed.

Andrew Myles (AndrewM): But any voting member could move that we go to Letter Ballot again.

JohnF: I haven’t see than happen before. AndrewM: That could happen. JohnF: That would be hard to do, because the Letter Ballot passed, and I would

expect to be challenged on that. We are close to 90% “Yes” votes, and that is very good for such a large group. I expect that we will send the draft directly to Sponsor Ballot after the next recirculation ballot. But this is not guaranteed. So I will have to see what we are allowed to do.

Mathilde Benveniste (MathildeB): What happens if it fails Sponsor Ballot? JohnF: It will go through the same process of changes and recirculations [in the

Sponsor Ballot procedures]. MathildeB: But with this same TGe group? JohnF: No, it is a different group of people, not the current 802.11 voters. You

need to ask Stuart to see whether that group can still be joined. Most of us will not be part of that balloting group. Announcements were made a couple of sessions ago on whether you want to be part of that group. That group will work like this group in recirculation ballots until the integrity is enough to pass Sponsor Ballot, but the members of that group will be different than the TGe group.

1.4. Reviews of voting rules and process

Process JohnF reviewed the general task group voting procedures and willingness for

open participation, but noted that motions must be made and voted by voting members.

JohnF: Technically only voting members can participate in discussion, but I will make an exception to allow all present to discuss. If you [are not a voting member and] want to make a motion, make sure you ask a member to make the motion. At times we will allow non-voting members to vote on some of the issues. Any other questions on voting and policies and rules?

Attendance Logging Procedures Khaled Amer (KhaledA): Question about attendance – how do we do this

electronically? JohnF reviewed the electronic attendance procedures. KhaledA: Unfortunately, I don’t get the list of current sessions where you do on

the page.

Minutes of 802.11 Task Group E, Novtember 2003 page 2 David Hunter, Vetronix/Bosch JohnF: Then you’ll need to talk to Al Petrick to see how to fix this.

November 2003 doc.: IEEE 802.11-03/xxxr0 1.4.2.5.

1.5.1. 1.5.1.1. 1.5.1.2. 1.5.1.3.

1.5.2. 1.5.2.1.

1.5.2.2.

1.5.2.3.

1.6.1. 1.6.1.1. 1.6.1.2.

1.6.1.2.1. 1.6.1.2.2. 1.6.1.2.3.

1.6.1.3. 1.6.1.3.1.

1.6.1.4. 1.6.1.4.1.

1.6.1.5. 1.6.1.6.

1.6.1.6.1. 1.6.1.6.2. 1.6.1.6.3. 1.6.1.6.4.

1.6.1.7. 1.6.1.7.1.

1.6.1.8. 1.6.1.8.1.

1.6.1.9.

1.6.1.10.

1.6.1.11. 1.6.1.12.

1.6.1.13.

1.5. Approval of minutes

Interim Ad Hoc Meeting JohnF: Have the minutes of the ad hoc meeting been issued? Tim Godfrey (TimG): Don’t believe they have been. JohnF: We will issue those this week and bring their approval up again later in

the week.

Minutes of the September 2003 Interim Meeting JohnF: Are there any questions or issues with the minutes of the September

2003 meeting in Singapore? JohnF: I hear none. The minutes of September 2003 are approved with

unanimous consent. JohnF: We need to do the same for the minutes of the Interim meeting in

Orlando, but I would like to postpone this until those minutes are available. Do I hear any objections to the postponement of this review? Hearing none, we will postpone this discussion until these documents are available.

1.6. Papers and Comment Resolutions

Call for papers JohnF: What papers are available to be presented? MathildeB: I have 2 or 3 papers

03/796, Lost Ack Problem (joint presentation with Menzo) 03/xxx, How to Respond to a TSPEC and Coordination Control 03/xxx, Power Management and Service Period

AndrewM: 1 paper; someone else will present this. 03/xxx, Downgrading Policy in EDCF

Floyd Simpson: 1 paper 03/883, Further Discussion on Lost Ack

JohnF: Any other papers? Amjad Soomro: 4 papers

Scheduling Power Save Mechanism Service Ending Time On Comment on Inclusion of Error Rate

Srini Kandala: 1 832r0, Changes to the Draft due to inclusion of TGg and TGh standards

JenniferB: 1 On Initiators

JohnF: Make sure the papers list up front the comments you’re addressing. Also make sure you coordinate your papers.

MathildeB: The lost Ack paper has been posted for two months without any feedback, so am surprised that anyone is working on this.

JohnF: It would be very helpful you all to get together MathildeB: Also please anyone who is working on EDCA, please get ahold of

me. Also approach me on the End of Service Period. Isaac: Would it be possible to list the papers?


November 2003 doc.: IEEE 802.11-03/xxxr0 1.6.1.14. 1.6.1.15. 1.6.1.16. 1.6.1.17.

1.6.2. 1.6.2.1.

1.6.2.2. 1.6.2.3. 1.6.2.4. 1.6.2.5.

1.7.1. 1.7.1.1.

1.7.1.2. 1.7.1.3. 1.7.1.4.

1.7.1.5.

1.7.1.6. 1.7.1.7. 1.7.1.8. 1.7.1.9. 1.7.1.10. 1.7.1.11.

1.7.2. 1.7.2.1.

1.7.2.2. 1.7.2.3. 1.7.2.4.

1.8.1. 1.8.1.1.

JohnF: Can the Secretary do this? DavidH: It’s in the middle of a bunch of comments. JohnF: Could you get in touch with Dave about that? Isaac: Sure.

TGe 4 Hour Rule JohnF: All papers that have normative text will have to be available for 4 working

hours. So make sure you follow this rule before you make a motion. JohnF: What papers will be available before the 6pm break? SriniK: Am ready now. MarkB: Would like to compare notes with Mathilde first. JohnF: I hear no others that are ready.

1.7. Comment Resolution Process

Ad Hoc Groups JohnF: We have in the past broken into ad hoc groups that work in parallel. I

would like to follow that process again, because it is faster. Srini, is there a logical way to break up the remaining comments?

SriniK: Three groups: EDCF, HCF, and the Rest (about 30 comments). JohnF: Clause numbers? SriniK: 9.1.3, 9.9.1 would be one Ad Hoc group; 9.9.2 would be the second

group. JohnF: I would like to propose to the group that we follow the editor’s

recommendation how to split this. It is about 30 comments per group. I hear no objection to this, so that’s what we will do. Are there any volunteers for leading these ad hoc groups?

Thomas Kuehnel (ThomasK): I’ll take the first group. JohnF: Any objection? Hearing none, I’ll appoint you to head that. AmjadS: I will take 9.9.2. JohnF: Any objection? Hearing none, I’ll appoint Amjad to head that. SriniK: I will take the remaining group. JohnF: Any objection? Hearing none, I’ll appoint Srini to head that.

Session Procedures JohnF: At the opening of each session I will ask whether there are any issues to

take to the TG. If none, then we will recess for Ad Hoc work. JohnF: SriniK, can you tell the group leaders how to find the related comments? SriniK: I can tell them how to filter the comments, offline. JohnF: With that, let’s divide up the groups to gather around the respective

leaders.

1.8. Closing

Recess for Ad-Hoc Group Work JohnF recessed the TG for Ad Hoc work at 5:03pm.


November 2003 doc.: IEEE 802.11-03/xxxr0

2. 7:30pm Monday Evening, November 10, 2003

2.1. Opening

2.1.1. 2.1.1.1.

2.2.1.1.

2.2.2. 2.2.2.1.

2.2.2.2. 2.2.2.3. 2.2.2.4.

2.2.2.5.

2.2.2.6.

2.2.2.7.

2.2.2.8.

2.2.2.9.

2.2.2.10.

2.2.2.11.

2.2.2.12. 2.2.2.13.

2.2.2.14. 2.2.2.15.

2.2.2.16.

Call to order JohnF called the session to order at 7:35 pm.

2.2. Papers JohnF: Are any of the papers ready? I see Mark and Floyd. I’ll give you each 10

minutes to present.

Document 03/0892, TIDs and Downgrading , Mark Bilstad Mark Bilstad (MarkB): There is no motion with this paper right now. I’d like to

lead to motions later in the week. This came up in the WiFi certification discussions, so I’m trying to pass some of those questions on to this group. The downgrade operation introduced in Draft 5.0 brought some of the ambiguities to the forefront. One of the things not captured in this presentation is that TGi also uses the TID as a queue index.

MathildeB: What is the confusion you mentioned? MarkB: If the TID is really an index, then lets treat it as such. MathildeB: You need 802.1d to make priority, so you have to make another field

to carry that? MarkB: Yes it does, but there are a number of scenarios in which you don’t have

to carry it (though you still can if you want). There are cases in which the 802.1d priority doesn’t get carried across the whole network, so 802.11 doesn’t have to carry it either. We can just follow the other 802.11 rules for where to carry it.

ThomasK: Do you mean that you would need only one bit to indicate downgrading?

MarkB: Yes, it does mean that you would get one bit back. But I don’t believe you still can put it in the frame because TGi would be messed up by this control bit messing up things. The problem is that these 4 bits mean something outside this TG.

ThomasK: You have two cases – lineout no admission control; but in the other case (“ACM based”) you could use multiple queues.

MarkB: When you use ACM downgrading, the other ambiguity is that you could just use other queues. You are right – depending on how that question is settled.

Menzo Wentink (MenzoW): I believe Draft 5.0 speaks about the second downgrade – there is no rerouting of frames. Do you agree that this is what is described in the Draft?

MarkB: I believe that the issue in the top half of Slide 4 is still there. This is also what Thomas alluded to.

Amjad Soomro (AmjadS): It does make a difference. MarkB: Agree. Simon Barber brought this up in one [teleconference] call: this

would give one queue with several backoff parameters. MenzoW: Yes it would allow a STA with multiple queues to be more aggressive. MarkB: My position is that it would only be allowed to use the queues advertised

by the AP. So it seems that there seems to be more work with respect to that. To summarize, I believe that you’re saying that my summary of the upper bullet is only my [own] summary.

MenzoW: I believe that the Draft 5.0 does not refer to the subject of the upper bullet at all. I will check this again.


November 2003 doc.: IEEE 802.11-03/xxxr0 2.2.2.17. 2.2.2.18.

2.2.2.19.

2.2.2.20.

2.2.2.21.

2.2.2.22.

2.2.2.23. 2.2.2.24. 2.2.2.25.

2.2.2.26.

2.2.2.27.

2.2.3. 2.2.3.1.

2.2.3.2.

2.2.3.3.

2.2.3.4.

2.2.3.5.

2.2.3.6.

2.3.1. 2.3.1.1.

2.3.1.2. 2.3.1.3.

2.3.1.4.

MarkB: So the final question is that should I draft text for this? AmjadS: One issue is that these TIDs values come from the MAC SAP. With

your proposal, when the value is the value of the queue index, how does it relate to the value coming from the MAC SAP?

MarkB: The major point is that we have to be clear about where TID means. We do have to keep the sequence number space meaning.

ThomasK: I would suggest always maintaining the 802.1d tag, whether downgrading or not. We need an end-to-end 802.1d tag.

MarkB: I believe this will come up again and we need to store the 802.1d priorities separately.

Charles Wright (CharlesW): I believe that the relevant text is in 9.9.1.7, especially “use an AC”.

ThomasK: But that could mean anything. CharlesW: Exactly. MarkB: Menzo, I believe that this is the ambiguous sentence. I am open to

discussion on how to work on this. AmjadS: If we retain the suggestion on the first bullet, then three queues could

be running EDCF parameters. MarkB: I agree.

Document 03/883r1, Further Discussion on “Lost Ack”, Floyd Simpson FloydS: There is no motion about this, and there are some comments coming up

on Draft 5.1. At the Singapore meeting we brought in the concept of an “Unscheduled Service Period”. It is arguable whether you need a solution to this problem. This problem is also in the 1999 draft, where there is a mechanism to mitigate it. You can mitigate this problem, but not totally solve it. See Clause 9.2.5.3 in the 1999 Edition. We believe that the 1999 mechanism is also the one to use for the current Lost Ack issue.

MathildeB: We are concerned still with the Lost Ack for the PS-Poll, and this issue is exacerbated in the current solution. We do have a solution that we will propose tomorrow. So I’d appreciate waiting until tomorrow.

FloydS: I agree. We should talk about it in the light of certain specific requirements.

MenzoW: I believe that Mathilde’s is a more precise solution that will be worthwhile to implementers. So we should wait until tomorrow.

AmjadS: On the first line of Slide 3: we tried to be clear earlier in the draft that, during a service period, a STA has to remain awake to receive any traffic from the AP. A QAP might need a STA to remain awake to receive a new schedule later. So this distinction, which I would like to see maintained, should be addressed in your proposal.

FloydS: I agree. This should be addressed along with a number of other specific requirements.

2.3. Closing

Recess JohnF: Are there any more papers that are ready? I see none, so I would like to

recess once again for the Ad Hoc groups to work again. Srini had to go to an editor’s meeting. Who is appointed to substitute for him?

FloydS: I am. JohnF: Is there any objection to recessing for the rest of the night for Ad Hoc

group work? I see no objection, so that’s what we’ll do. JohnF recessed the meeting at 8:25pm for Ad Hoc work.



3. 8am Tuesday Morning, November 11, 2003

3.1. Opening

3.1.1. 3.1.1.1.

3.2.1. 3.2.1.1.

3.3.1. 3.3.1.1.

3.3.1.2.

3.3.1.3. 3.3.1.4.

3.3.1.5.

3.3.1.6. 3.3.1.7.

3.3.1.8.

3.3.2. 3.3.2.1.

3.3.2.2. 3.3.2.3.

Call to order JohnF called the session to order at 8:10 am.

3.2. Agenda Discussion

Papers JohnF: We have all day today, 8am to 9:30pm, but do not have a session

tomorrow. Thursday there won’t be much time – probably only one session to resolve comments. And then we will need to approve changes that we have come up with. I would first like to give the floor to the Ad Hoc group leaders. Are there any other papers ready? Hearing none, then does everyone agree that we should continue with the ad-hoc group work and reconvene at the 10:30 session? Hearing none, that’s what we’ll do.

3.3. Ad-Hoc Work Review

Ad Hoc Reports AmjadS: My group is working on Clause 9.9.2. We have 20+ comments.

Yesterday we resolved 5 comments and discussed some comments on NAV in detail, to understand multiple NAV. We expect to complete another 5 comments this morning, so we will be on target to complete our group work.

FloydS: I was sitting in for Srini late last night and we resolved 4 comments – mostly the power save comments in Clause 11, how to use the MoreData bit and Lost Data bit together.

MathildeB: I will be presenting on that topic, too. SriniK: The Misc group has resolved 7 comments and have another 20, but we

expect to be done today. JohnF: To be done today is a good thing. If the Ad Hoc groups can publish what

they have done by lunchtime, then we can start approving these by the end of the day today. Keep in mind you don’t need to have a consensus at the Ad Hoc level. It is more important to have a resolution than a consensus in the Ad Hoc group right now. Please just bring it forward it with the note that this reflects just a majority of the members present.

JohnF: Are there any papers ready for presentation? I see two papers. MarkB: I have no paper but have a single comment I’d like to resolve on the

floor. JohnF: Ok, lets start with Mark and then move to Mathilde and Srini.

Response to Comment 449, Mark Bilstad MarkB: This is comment 449. The Ad Hoc group had a recommended

disposition in a September teleconference, but I don’t think it’s gone through the session yet.

MarkB read the comment about QAP actions. MarkB: The Ad Hoc group recommended to decline this, with reference to Table

17 that specifies the AP usage of these. The commenter wanted to preserve the ability to advertise. The response I am recommending is to accept the comment: “In the paragraph before table 17, add a final sentence stating “A QAP sets the QoS, CF-Pollable, and a CF-Request subfield values in


November 2003 doc.: IEEE 802.11-03/xxxr0 Association Responses and Reassociation Response management frames corresponding to the QoS capabilities that are active and allowed for this association.”

3.3.2.4.

3.3.2.5. 3.3.2.6.

3.3.2.7.

3.3.2.8.

3.3.2.9.

3.3.2.10.

3.3.2.11. 3.3.2.12.

3.3.2.13. 3.3.2.14.

3.3.2.15.

3.3.2.16.

3.3.2.17. 3.3.2.18. 3.3.2.19. 3.3.2.20.

3.3.2.21.

3.3.2.22.

3.3.2.23.

3.3.3.

3.3.3.1.

3.3.3.2.

MarkB: This contrasts with the Ad Hoc group’s recommendation to decline the comment with reference to “The QoS facilities in EDCA and HCCA could be denied by admission control mechanism for a particular association. Furthermore, the proposed solution would increase protocol complexity of QSTA by having …” . I agree with the latter half of this, but would like to deny that because we won’t know the SSID until association time, and can deny the association after that.

SriniK: But that is on the station side. MarkB: The server side would not know that a QoS is available on one of the

STAs. SriniK: Why do you want to do this? We did not understand the need expressed

in the comment. MarkB: Customers want all sorts of strange policies. There are some cases

where the administrator would not want to support QoS facilities. SriniK: To me the whole policy of standardizing on QoS and then allowing this to

be set to 0 defeats the purpose. MarkB; These capabilities are here to be able to enable it, so I am only asking to

enable it on an SSID basis. SriniK: Why should this group specifically provide a mechanism not to use QoS? MarkB: My general answer is only to be able to enable/disable on SSID basis. I

don’t know all the reasons why people would want to do this. There can be a single AP that can support more than one SSID.

SriniK: I don’t see why people would want to do this. ThomasK: People would want to overload multiple SSIDs onto one AP, so it

could serve multiple operators. SriniK: But then they are multiple logical BSSIDs. Then they are different

beacons. Matthew Fischer (MatthewF): There’s no need for this, since you can’t put

multiple SSIDs into the same beacon. ThomasK: You will send out different beacons, alternating. MatthewF: You need multiple beacons, and so its unambiguous. MarkB: But with active scanning you would need this. SriniK: But you still will have several probe responses, so then the STA still will

know the QoS of each. MarkB: I can see that this is not flying well. This is just to support what the

administrators want to do. SriniK: But this will not help them. They already can differentiate on different

SSIDs. MarkB: So for right now I’ll withdraw this suggestion.

Document 03/832, TGe Draft Changes for TGg and TGh Drafts, Srini Kandala

SriniK: There is no formal presentation. This document just outlines the changes that need to be made to match the changes they [the TGg and TGh drafts] have made. We need to go through each of the changes they have made and see how it affects our draft. The one significant difference is that TGh wanted to make all action frames Class 1 frames, and TGe wanted them to be Class 3. This proposal is to make just the Spectrum Management action frames Class 1 frames, and the rest Class 3.

SriniK: The second issue is about CTS frame formats. This means that, when you start an EDCF session, you could start a ???



3.3.3.4.

3.3.3.5.

3.3.3.6. 3.3.3.7.

3.3.3.8.

3.3.3.9. 3.3.3.10.

3.3.3.11. 3.3.3.12. 3.3.3.13. 3.3.3.14.

3.3.3.15.

3.3.4. 3.3.4.1.

3.3.4.2.

3.3.4.3.

3.3.4.4.

3.3.4.5. 3.3.4.6. 3.3.4.7.

SriniK: The next one is in the Capability Information field. TGg added an amount of text. This needs to be added to the DLP request and response [definitions] to match. You need to have similar encoding for DLP as you do associations. The next change is multi-frame support – this only changed a couple of lines. The next is CTS figures. This basically comes in parallel with every other line, sending a data frame or management frame or fragment. And that’s it. There’s really not much there. This is basically consistent with the TGg draft.

SriniK: So I want to bring in a motion at this time: “Move to instruct the editor to incorporate the changes in 03/832r0. Further resolve comments 714, 728-735 with the following recommended disposition: ‘Comment accepted. Incorporate the changes in 03/832r0 into the next TGe draft.’ ”

JohnF: Any suggestion for changes, before I recognize a second? Seeing none, I recognize John.

John Kowalski (JohnK): Second. JohnF: Any discussion? I see no discussion. I ask the voting members, is there

any objection to accepting this motion unanimously? I see none, so this motion is passed unanimously.

SriniK: I have one more motion, so that I can incorporate the changes as soon as possible. I move to “Accept the entries in ‘recommended disposition’ cells 03/658r13 as the resolutions for the comments that are marked green (with status column set to TBA) with the exception of comments 351, 448, 449, 598, 804 and 813. Further instruct the editor to incorporate the suggested changes in the recommended disposition into the next TGe draft.”

AmjadS: These comments were from the teleconferences? SriniK: These were the comments in the teleconferences, at the end of the

September meeting and the ones in the October Ad Hoc Interim. There were a number accepted by the Ad Hoc group, not the TGe.

JohnF: Any more discussion? JohnK: Second. AmjadS: Could we see those comments? SriniK: Go to the status column in the Excel file and select “TBA” to see the ones

that are not yet approved. The ones for September 18 were from the last day of the Singapore meeting that were not resolved by the Task Group.

JohnF: Any more discussion from the task group? Therefore I would like to ask the voting members only, is there any objection to accepting this motion? I see none, so this motion is accepted unanimously.

Document 03/0919, Clarifications in APSD, Mathilde Benveniste MathildeB: I have had to circulate this document on a flash card, since I have not

been able to get on the server (can’t get an IP address). MathildeB: This presentation does not have a number yet, because we have not

been able to get on the server this morning. This addresses the comments 445, 473, 497 and 942. Two of these comments come from an individual who has accepted this clarification.

MathildeB: The subject is signaling in APSD. APSD was proposed by Keith Amann and I added more on the delivery mechanism. That has been accepted into the current draft. So now the questions are why do we have two fields for the service period, and do we need them both? The answer is yes. More Data indicates whether or not there is more data pending; the ESOP bit indicates ??? This distinction is explained by example in this paper. These clarifications will come just in editorial changes to be made by Srini.

Matthew Sherman (MatthewS): If More Data is 0, then will the EOSP bit ever be 0?

MathildeB: No. MatthewS: Then I suggest that sleep should only be based on the ESOP bit. MathildeB: Is that clear in the draft?



3.3.4.9.

3.3.4.10. 3.3.4.11.

3.3.4.12. 3.3.4.13. 3.3.4.14.

3.3.4.15.

3.3.4.16.

3.3.4.17. 3.3.4.18.

3.3.4.19.

3.3.4.20. 3.3.4.21.

3.3.4.22.

3.3.4.23. 3.3.4.24. 3.3.4.25.

3.3.4.26. 3.3.4.27.

3.3.5.

3.3.5.1.

3.3.5.2.

3.3.5.3.

SriniK: It seems so; we can make it more clear if someone points out that it is needed.

MathildeB: Does anyone object to removing the MoreData bit as a means of signaling End of Service?

Ye Chen (YeC): I’d like to hear why. MathildeB: You are using it only for signaling. In D5.1 the APSD has a single

mechanism for delivery, indicated by the Schedule bit. Schedule would be set to 0 if Reverse Polling is use. This signaling applies both to scheduling APSD and Reverse Polling APSD.

YeC: We think there is some conflict between admission and the draft right now. MatthewS: I suggest we decouple this [issue from the current presentation]. MathildeB: This proposal is only about the Draft 5.1. Does anyone have any

preference for either option? Anyone want to use ESOP bit alone to indicate the End of Service Period?

MarkB: I thank you for bringing this up. Second, I believe we should just have a single set of status rules on whether it accepts frames or not.

MathildeB: I do not believe that this clarification changes anything that TGe has voted into our draft.

FloydS: ESOP is really not a method for APSDs. MathildeB: This is what the normative text says. This has nothing to do with

whether your delivery mechanism is Scheduled or Reverse Polling. I’d like a straw poll: how many want to leave as is, and how many want to use just the ESOP bit as the single signaling mechanism for APSD? I count 5 versus 10.

MarkB: What does it mean to say we want to use Draft 5.1, when Comment 401 is still open. Draft 5.1 says “and” in one place and “or” in another.

MathildeB: I believe the “and” must be a typo – I meant “or” in the draft. AmjadS: Initially one of the uses for the scheduling mechanism was for APSD.

The introduction of the EOSP bit requires that the STA stays awake for a new schedule to be published and received.

MathildeB: Before we move off this schedule, I ask whether I can make a motion this afternoon, since this was distributed by flashcard this morning.

JohnF: Yes, that will be appropriate. MatthewS: I have question on Slide 6. MathildeB: What is on the screen is not the fully edited version; please see the

version from the flash card. JohnF: Matthew, are you ok with this? MatthewS: Yes.

Document 03/0917, Remedy to the ‘Missing Ack Problem’, Mathilde Benveniste and Menzo Wentink

MathildeB: In Singapore we introduced a new mechanism, reverse polling or unscheduled APSD. This paper addresses comments 441, 210, 209, 330, 331, 324, 325, 460, 466, 467, and 526. A lot of us voted for Reverse Polling with a promise that there would be a fix for the Lost Ack problem. We wouldn’t have voted for that without such a remedy. In Singapore I made an initial proposal, then there was much discussion, and this is the most recent proposal.

MathildeB: Schedule APSD is not vulnerable to the Lost Ack problem, so this only occurs with APSD with Reverse Polling.

MatthewS: I would prefer a different mechanism. For me the key is trying to keep the power save STA synchronized. I believe that the mechanism to keep the STA awake long enough for it to hear a transmission from the AP to another STA.



3.3.5.5.

3.3.5.6. 3.3.5.7.

3.3.5.8. 3.3.5.9.

3.3.5.10.

3.3.5.11. 3.3.5.12. 3.3.5.13. 3.3.5.14. 3.3.5.15. 3.3.5.16.

3.3.5.17.

3.3.5.18.

3.3.5.19.

3.3.5.20. 3.3.5.21. 3.3.5.22.

3.3.5.23.

3.3.5.24.

3.3.5.25. 3.3.5.26.

3.3.5.27.

3.4.1. 3.4.1.1. 3.4.1.2.

3.4.1.3.

MathildeB: I proposed that in 03/793, but got back the response that people did not want to waste battery life, but, since this is a probability event, then it would be better to have this fix. I just went along with this.

MenzoW: I would like to thank Mathilde for putting all this energy into this proposal. Matthew’s suggestion would require that the AP use a rate that is decodable by both STAs, which would require the AP always to use a lower rate. I believe that that is a severe problem.

YeC: I speak in favor of this solution. This is a more efficient mechanism. ThomasK: I have one comment on Matthew’s proposal. Another argument is

that if people bring in diversity, then the second transmit by the AP might not be seen at all by the first STA.

MatthewS: I am more on the fence than I was before. AndrewM: The QAP sends a data frame that is lost, then another one that is lost,

and it then assumes the STA has gone to sleep, when it has not, just hasn’t heard [the transmission]. So now we have gone from the Lost Ack problem to the Lost Frame problem.

MathildeB: In Singapore I was trying to keep the STA awake. Since we aren’t doing that any more, we can allow the implementer to do her/his own analysis and make her/his own choice.

AndrewM: On what basis can the implementer decide to choose 1 or 3 retries? MathildeB: It is up to their own choice. MarkB: What is the last downlink transmission reference? FloydS: Generally I am in agreement, but what about the ??? MathildeB: That applies to scheduled or unscheduled. MatthewF: I still would like to propose that there be at least one retransmit

during the service period; with that, I would agree 100% with what you have. MathildeB: I believe it is better to give explicit permission rather than try to figure

it out. MatthewF: Fundamentally, do you agree with the point that you should have one

transmission? MenzoW: The text here is different from the normative text, which says “and

*may* wait until the next service period”. MatthewF: I’m with you except for the last point about lasting for a lifetime limit. MathildeB: In other words, you can do this, or you might not. MatthewF: I’d just like to see the exact wording and can propose a clarification

when the motion is made. MathildeB: I ask that you come to us right away with suggestions for normative

text because we have the 4 hour rule. ThomasK: I agree with Matthew’s comments about making it clear which

mechanism should be used. It may make it unclear about expected behavior. MathildeB: The AP doesn’t have to retransmit; it may retransmit if it wants. ThomasK: There are now two options for discounting the frame – one on the

service period and one on lifetime, and the STA doesn’t know which to apply. MathildeB: The point that Matthew is making applies all the time, anyway.

3.4. Closing

Recess JohnF: Anyone have another presentation ready? AmjadS: I have a presentation, but have not been able to put it on the server,

because of server problems. JohnF: Anyone else have a paper ready? I see none. Let’s recess now for the

break and take up Amjad’s paper when we reconvene after the break.



4.1.1. 4.1.1.1.

4.2.1.

4.2.1.1.

4.2.1.2.

4.2.1.3.

The meeting recessed at 9:56am until the next session.

4. 10:30 am Tuesday Morning, November 11, 2003

4.1. Opening

Call to order JohnF called the session to order at 10:35 am.

4.2. Papers

Document 03/973, Signaling Acceptable Error Rate in TSPEC, Amjad Soomro, et. al.

AmjadS: I have not been able to put this document on the server or obtain a document number. We can share this paper via flash card.

AmjadS: This paper is in response to Comment 931. The question is why do we need yet another parameter. I will try to convince you that it is something that is not covered yet.

AmjadS: Even after retries, residual errors remain at the MAC SAP. So how, in that case, do APs decide when to delete or not to delete a TSPEC? Some applications are tolerant of errors; some are not. Medical applications have very low error tolerance. HDTV can tolerate 2 packets/second -- see the http://wwww.atsc.org/Standards Document. The proposal is that applications can explicitly specify the amount of errors they can tolerate in the TSPEC, in the field Maximum Tolerated Error Rate. So now the QAP knows when not to delete a TSPEC. This helps in doing delay vs. loss tradeoffs.

4.2.1.4.

4.2.1.5. 4.2.1.6.

4.2.1.7.

4.2.1.8. 4.2.1.9.

4.2.1.10. 4.2.1.11.

4.2.1.12. 4.2.1.13. 4.2.1.14. 4.2.1.15. 4.2.1.16. 4.2.1.17.

SriniK: Without this parameter the QAP is not allowed to deliver TSPECs. So is this needed? We already have a stronger requirement. It is up to a higher layer to initiate that.

AmjadS: Ok. Wei Lih Lim (Isaac): Because retransmit is a function of the sending session,

and the error rate is only used by QAP to create more retransmissions. AmjadS: There also is the counter downlink case. How can the AP know if this

information is not passed to the MAC? The information needs to pass through the AP somehow. So this is useful in both the uplink and downlink cases.

Isaac: So you’re saying this is not useful for admission control? AmjadS: This is useful for uplink traffic; for downlink traffic the AP can slow down

the transmissions, at the cost of additional delay. SriniK: Isn’t this information already there? So why do we need this? AmjadS: But nothing in the TSPEC says how many errors can be tolerated by

that application. SriniK: The STA will keep retrying until the delay bound is exceeded. AmjadS: But that is only for one application. SriniK: That is in the spec now. AmjadS: But the spec right now is written only for one type of application. SriniK: How would the AP make a decision then? AmjadS: Depending on the value, it could do more retries, because these are

the less tolerant of error rate but more tolerant of delay.


http://wwww.atsc.org/Standards


4.2.1.19.

4.2.1.20.

4.2.1.21.

4.2.1.22.

4.2.1.23. 4.2.1.24. 4.2.1.25.

4.2.1.26.

4.2.1.27. 4.2.1.28.

4.2.2. 4.2.2.1. 4.2.2.2.

4.2.2.3.

4.2.3. 4.2.3.1.

4.2.3.2.

4.2.3.3.

4.2.3.4. 4.2.3.5. 4.2.3.6. 4.2.3.7.

4.2.3.8. 4.2.3.9.

SriniK: Why is it not sufficient to use the current values? The application knows what is best. I think it becomes very complex; there are way too many things to check.

AmjadS: The problem that I see is how best to use the available MAC. How could the application know how to meet [to go about meeting] the requirements?

Bob Miller (BobM): I believe that one issue is that these are coupled, but that the conditions of the coupling change. It is a misuse of the current parameters to try to accompany this. Delay and errors are not synonymous.

AmjadS: This distinction is important in a wireless network. To Srini’s second point that this is too cumbersome for some applications to use: I agree, but believe it should be up to the application whether to use this or not.

Isaac: On the tradeoffs: error rate is converted into a maximum service interval is one use.

AmjadS: If that is there, then it clearly needs to be fixed. Isaac: Section 11.4.2 in any of the recent drafts. BobM: I believe that Amjad’s proposal is at the heart of wireless. To introduce

an artificial connection between error rate and delay introduces more problems.

AmjadS: I believe this section (11.4.2) is fine. This supports my position. I am proposing to have explicit communication to tell the AP what is the tolerated error rate and not to have to do this artificial calculation.

BobM: This all is informative, just giving guidelines. AmjadS: Please contact me with any changes you would like. I hope to have a

motion on this, this afternoon.

Additional Papers JohnF: Any more papers available now? MathildeB: I do have one, but can’t find the related comment right now. Srini is

looking this up. JohnF: Then present that now.

Admission Control, Mathilde Benveniste MathildeB: This is some cleanup for Admission Control. We still are not able to

get this paper on the server, so will have to have a motion later. This paper is available on flash card now.

MathildeB: The AP must transmit frames destined to a legacy STA in the best effort AC.

MatthewS: On Slide 2, I generally like this proposal, but don’t know whether it’s necessary to put it in the standard. On Slide 3, this seems to be limiting the choices of the AP. It is easier just to say those frames shall not be transmitted on that AC and just leave it open. I am worried about it being too much specificity. On the last bullet, I believe that it already says this in Clause 6.

MathildeB: If you can show me that, I’ll agree on removing it. MatthewS: I believe it may not be very clear, so I agree with clearing it up. Stephen Wang (StephenW): What about doing this with ACM=0? ThomasK: The reasoning behind it is that it may be a policy set by the operator

to not allow any transmissions that do not have valid admission control. StephenW: Then I believe that the first bullet on Slide3 should be rewritten. MathildeB: Then I will put this suggested normative text in the motion that we will

have in the afternoon.


November 2003 doc.: IEEE 802.11-03/xxxr0 4.3. Closing

4.3.1. 4.3.1.1.

4.3.1.2.

5.1.1. 5.1.1.1.

5.2.1.1. 5.2.1.2. 5.2.1.3.

5.2.1.4.

5.2.1.5. 5.2.1.6.

5.3.1. 5.3.1.1.

5.3.1.2.

6.1.1. 6.1.1.1.

Recess for Ad Hoc Group Work JohnF: Any more presentations? I hear none. Any more motions? I hear none

of those either. Any more comments? I hear none, so we will recess for Ad Hoc group work until the 1:30pm session. I would like to start then with reports by the Ad Hoc group leaders and then we can entertain motions to approve the progress they have made so far. Any objection to recessing for Ad Hoc work? Hearing none, we are recessed for Ad Hoc work until 1:30pm.

The task group session recessed for Ad Hoc group work at 11:25am.

5. 1:30pm Tuesday Afternoon, November 11, 2003

5.1. Opening

Call to order JohnF called the session to order at 1:38pm.

5.2. Ad Hoc Group Work Review JohnF: Are there any reports of Ad Hoc activity? SriniK: We haven’t had any Ad Hoc activity since the last report. JohnF: Is anyone here available to take the Thomas and Amjad groups? I hear

none so we’ll recess for Ad Hoc work. JohnF: I also want to announce that the minutes of the Ad Hoc Interim meeting

in Florida have now been published as document 03/909. So please review those minutes and I’d like to approve them in the next session.

SriniK: Thomas is coming. So we really only need a volunteer for Clause 9.9.2. BobM: I’ll start working on them until Amjad gets here.

5.3. Closing

Recess for Ad Hoc Group Work JohnF: Then the three groups will be available. Does anyone object to recessing

for Ad Hoc work until the next session at 4pm today? Hearing none, we are in recess.

The meeting recessed for Ad Hoc work at 1:48pm.

6. 4:00pm Tuesday Afternoon, November 11, 2003

6.1. Opening

Call to order JohnF called the session to order at 4:05pm


November 2003 doc.: IEEE 802.11-03/xxxr0 6.2. Ad Hoc Group Reports

6.2.1.1.

6.3.1. 6.3.1.1.

7.1.1. 7.1.1.1.

7.2.1.1.

7.2.1.2. 7.2.1.3.

7.2.1.4.

7.2.1.5.

7.2.1.6.

7.3.1. 7.3.1.1.

JohnF: I see that the groups are all very busy right now, so lets recess again for Ad Hoc work until this evening session at 7:30pm. Any objections? Hearing no objections, we are in recess until the next session.

6.3. Closing

Recess for Ad Hoc Group Work The session recessed for Ad Hoc Group work at 4:07pm.

7. 7:30pm Tuesday Evening, November 11, 2003

7.1. Opening


7.2. Ad-Hoc Work JohnF: During the break I received a report that the different Ad Hocs have

made great progress, and that there are only about 23 comments to go. Since we are making great progress, let’s do things right and finish the 23 comments tonight. If you don’t get them done, I’d like Srini’s personal recommendations. I know Bob has a document [describing his Ad Hoc group’s results] and believe it has been consolidated into Srini’s document, so that we have a single [Ad Hoc report] document. So then, if the full set is put out even by Noon tomorrow, people will have time to review them and we will be able to start the approval process first thing Thursday morning.

SriniK: We have 03/658r14 on the website now. JohnF: Then everyone look for 03/658r15 on the website after Noon tomorrow.

This will include all of the comments resolved by the Ad Hoc groups through this evening.

BobM: For convenience we also put 03/0936 and 03/0937 on the website that covers our group’s work. These are now a subset of the full 658r14.

JohnF: Ok, everyone look for those documents as a subset of r14. Srini, if you have to come up with your personal recommendations, please make that a separate document on the website by Noon tomorrow.

JohnF: Are there any objections to that plan? Hearing none, then we are in recess until Thursday morning at 8:00am.

7.3. Closing

Recess The session recessed at 7:43pm for work in the Ad Hoc Groups.



8. 8:00 am Thursday Morning, November 13, 2003

8.1. Opening

8.1.1. 8.1.1.1.

8.2.1.1.

8.2.1.2. 8.2.1.3.

8.2.1.4. 8.2.1.5.

8.2.1.6.

8.2.1.7.

8.2.1.8. 8.2.1.9.

8.2.1.10. 8.2.1.11.

8.3.1. 8.3.1.1.

8.3.1.2.

8.3.1.3.

Call to Order JohnF called the session to order at 8:10am.

8.2. Discussion of Procedures JohnF: I would like to start with comment resolutions, starting with the

resolutions by the committees, then to individual proposals. The goal is to decide by the 4pm meeting whether we can go to recirculation. But first I would like to have a discussion on what’s next. Obviously we’re trying to go to sponsor ballot. In parallel to the recirc, we can use Procedure 10 in the LMSC document to enable us to not have to wait until the next plenary meeting. The catch is the ExCom must approve the Sponsor Ballot. Technically that does not occur until the March meeting. However, all the members of the ExCom will be in the January Interim meeting. So I am trying to get them to hold a special meeting of the ExCom in January.

Q: What is your estimate of the chances they will do that? JohnF: I can’t speculate on that. We just hope to be able to do that. Hopefully

by 4pm we will have some solid news of the outcome of this effort. It is questionable in my mind whether it is feasible to have an Interim meeting before January.

SriniK: We could do one near the beginning of December. Q: The deadline for going to RevCom is February 13. After the January meeting

you only have 4 weeks, and that is too little time to get the Sponsor Ballot done.

JohnF: I think it will take at least two rounds on the Sponsor Ballot, so it is unlikely to go to RevCom by March, anyway. But we will have to look at that.

Q: TGg did two recirculations, even with no comments. Six months is a good estimate of what it would be to have approval of Sponsor Ballot.

JohnF: It certainly would be out of the norm of 802 to go [faster than that]. Q: Just to be clear, it will be the June meeting of RevCom, and the deadline for

that is April. JohnF: That seems realistic. And I believe TGi will be in the same time frame. JohnF: We now have SriniK to go over the current Ad Hoc resolutions, and after

that Mathilde will present on some more resolutions.

8.3. Approval of Comment Resolutions

Ad Hoc Group Proposed Resolutions SriniK: The first document is 03/658r16. The only comments you will see here

are the ones from the Ad Hoc Groups. The second document is 03/954r1, which describes the resubmitted comments – about 10 comments. And 03/957r0 is my request to the ANA for status codes’ this is in response to the removal and integration of status code fields.

SriniK: In 658r16 see the comments marked in green or marked “TBA” in the status column.

SriniK: I move to “Accept the entries in the ‘recommended disposition’ cells in 03/658/r16 as the resolutions for the comments that are marked green (with status column set to TBA). Further instruct the editor to incorporate the suggested changes in the recommended disposition into the next TGe draft.”



8.3.1.5. 8.3.1.6. 8.3.1.7.

8.3.1.8. 8.3.1.9. 8.3.1.10. 8.3.1.11.

8.3.1.12. 8.3.1.13. 8.3.1.14.

8.3.2. 8.3.2.1.

8.3.2.2. 8.3.2.3.

8.3.2.4.

8.3.2.5. 8.3.2.6.

8.3.3. 8.3.3.1.

8.3.3.2. 8.3.3.3.

8.3.3.4.

8.3.3.5.

8.3.3.6.

JohnF: Any friendly amendments, especially any comments they would like to include out of this group for individual discussion)?

AmjadS: I have a paper on service periods. SriniK: Those resolutions were previously approved. JohnF: We can take those up later in motions to reconsider. Mathilde also will

be bringing up some motions to reconsider. MatthewF: Please exclude 351. JohnF: Any other exclusions? BobM: 822 SriniK: So now we have the new version: I move to “Accept the entries in

‘recommended disposition’ cells in 03/658/r16 as the resolutions for the comments that are marked green (with status column set to TBA) with the exception of comments 351 and 822. Further instruct the editor to incorporate the suggested changes in the recommended disposition into the next TGe draft.”

JohnF: Any other friendly amendments? Hearing none, I’ll accept a Second. ThomasK: Second. JohnF: Is there any discussion? Hearing none, is there any objection, and this is

to the voting members only, to accepting these resolutions as the comment resolutions of the TGe group? Hearing none, this motion is passed unanimously and these are the resolutions of the TGe.

Document 03/954r1, Editor's resubmitted comments, Srini Kandala SriniK: Document 954r1 is the list of recirculated comments. The ones marked

green are just cleaning up the resolutions, resolutions that are changed to make them consistent with the other resolutions.

SriniK reviewed each of the proposed comment resolutions in this document. SriniK: I move to “Accept the entries in ‘recommended disposition’ cells in

03/954r1 as the resolutions for the comments that are marked green (with status column set to TBA), with the exception of comment 871. Further instruct the editor to incorporate the suggested changes in the recommended disposition into the next TGe draft.”

JohnF: Any recommended changes to this motion? Any questions? Hearing none, I would like to ask for a Second.

AmjadS: Second. JohnF: Is there any discussion of these resolutions? Hearing none, is there any

objection, and this is to the voting members only, to accepting these resolutions as comment resolutions of TGe? Hearing none, this motion passes unanimously.

Document 03/957r1, TGe’s Request to ANA, Srini Kandala SriniK: Document 957r1 is a request to the ANA for status codes. The table lists

the needed status code numbers. These are the immediately available numbers, which I am presuming will be the logical choices of the ANA.

BobM: Could you review the individual codes? SriniK reviewed the meanings of each of the requested codes. For instance,

Status Code 37 is used for DLP requests. SriniK: I move to request the ANA to assign Status Codes for the described

settings in Slide 3 of Document 03/957r1, preferably with the values in the left column of this table.

JohnF: Any recommended changes to this motion? Any questions? Hearing none, I would like to ask for a Second.

AmjadS: Second.



8.3.4. 8.3.4.1. 8.3.4.2. 8.3.4.3. 8.3.4.4.

8.3.4.5.

8.3.5.

8.3.5.1.

8.3.5.2. 8.3.5.3.

8.3.5.4. 8.3.5.5.

8.3.5.6.

8.3.5.7. 8.3.5.8.

8.3.5.9.

8.3.5.10.

8.3.5.11. 8.3.5.12. 8.3.5.13. 8.3.5.14. 8.3.5.15.

8.3.5.16. 8.3.5.17. 8.3.5.18.

8.3.5.19.

8.3.5.20. 8.3.5.21.

8.3.5.22.

8.3.5.23.

JohnF: Is there any discussion of this motion? Hearing none, is there any objection to passing this motion? Hearing none, this motion is passed unanimously and these will be the requests of the TGe to the ANA.

Comment Resolutions, Srini Kandala JohnF: Are those the only comments that are to be resolved? SriniK: Yes. JohnF: Would you like to go over the comments that were excluded? SriniK: I would like to discuss those with the requesters first, and then bring up

the proposed resolutions later. JohnF: Fine. With that, we’re on to the previous requests.

Document 03/796r2, Remedy to the Lost Ack Problem while Power Saving, Mathilde Benveniste

MathildeB: This is about the missing ACK problem that Menzo and I described two days ago. Is there any need to discuss this further?

AmjadS: I would appreciate a discussion of the changes. MathildeB: In 917r0 the presentation was on both the legacy power

management and the new versions we introduced. Matthew Fischer had the request to strike out the last clause (that the AP may drop a frame if it wants to). So now we have 03/917r1. See slide 4 on the QAP. The normative text is now in 03/796r2, which applies to 11.2.1.4 after subclause h and 11.2.3.1 after subclause c.

MarkB: So you are changing the legacy behavior. MathildeB: Yes, you may. But you are not required to do this. It is an option.

You can still use the max retry limit as a cap. There are no "shalls" here. MarkB: So you are allowing an AP to drop a frame when it has not been allowed

to in the past? MathildeB: Yes. MarkB: I was worrying about whether the Legacy stations not conveying QoS

traffic would comply. MathildeB: Oh yes, there is no requirement to drop that packet. This allows the

QAP to do so. MarkB: But what about normal traffic? Is the QAP allowed to drop the last

packet? MathildeB: The QAP is allowed to do either. MarkB: I’m just trying to understand what the proposal is for legacy behavior. Stephen Wang: This looks like an additional restriction on the AP. MathildeB: This only says QAP, not AP. MatthewF: It is a legacy station you are transmitting to, but does not restrict the

AP. AmjadS: This is that the QAP is allowed to transmit one less frame. MathildeB: I believe the requester agreed to this version. MatthewF: With respect to the first paragraph, I thought I had agreed to the

version without this one phrase. MenzoW: I remember that we had removed the Max Retry Limit phrase. Please

go back to the PowerPoint presentation on this. MathildeB showed Slide 4 of an 03/xxxr0 .ppt file. MatthewF: I believe that this refers to retries within this service period. I believe

this text is still a little bit ambiguous. MenzoW: Could switch the order and add “but at least once” after within the

same service period, and then replace “shall” with “may” after that. MatthewF: And further retransmissions.



8.3.5.25. 8.3.5.26. 8.3.5.27.

8.3.5.28. 8.3.5.29.

8.3.5.30. 8.3.5.31.

8.3.5.32. 8.3.5.33.

8.3.5.33.1.

8.3.5.34.

8.3.5.35. 8.3.5.36. 8.3.5.37. 8.3.5.38. 8.3.5.39.

8.3.5.40. 8.3.5.41. 8.3.5.42.

8.3.5.43.

8.3.5.44.

8.3.5.45.

8.3.5.46. 8.3.5.47. 8.3.5.48. 8.3.5.49. 8.3.5.50.

8.3.5.51.

8.3.5.52.

Richard van Leeuwen (RichardL): Could you say that you reached the max retry limit and have one more?

MathildeB: Don’t think that is allowed, because this is your last frame. RichardL: Could be the next service period. MenzoW: Could wait for the next service period and try again. This could say to

retry forever. MathildeB: That’s a good point. MenzoW: How about restricting this to the next frame after the current service

period? MathildeB: But the Max retry limit still governs. RichardL: How about “at least once, provided that the max retry limit is not

reached”? MenzoW: But then always go to the max retry limit. MathildeB: Any objection to including this in the normative text? I hear none. So

the change in the normative text will make this document 03/796r3: After subclause c in section 11.2.3.1: If the QAP does not receive an

acknowledgement to a directed MPDU or management frame sent with the More Data sub-field set to 0 or the EOSP set to 1, it may retransmit the frame fewer times than the Max Retry Limit within the same service period, but it shall retransmit that frame at least once within the same service period – subject to the Max Retry Limit and the MSDU Lifetime limit. If an Ack to the retransmission is not received, it may wait until the next service period to further retransmit that frame.

MatthewF: With respect to the last sentence, within the next service period this is not a retransmission. Do you *have* to retransmit at least one more time?

Bruce ?: Is your intent to do 2 and then 1 and then 1? MathildeB: You may stop after the first 1. Bruce ?: I believe that is correct. MatthewF: I believe it is confusing in its current wording. SriniK: Is there a need for this to be in the standard? Is this not an

implementation detail? MathildeB: Without this you do not have a solution to the Missing Ack problem. JohnF: We’re out of time, so why not make this a formal motion. MathildeB: The editor can clean up the language, but the motion would be as

above. I’d like to hear from Matthew. MatthewF: There are a couple of possible solutions in the current draft that are

not here. MathildeB: The double ack wastes bandwidth. We would like to put a limit on

retransmissions. This enables an AP to reduce the number of retransmissions.

MathildeB: I move to adopt the normative text of 03/796r3 in the second paragraph.

MenzoW: Second. JohnF: I’d like a queue for discussion. MenzoW: I call the question. SriniK: Second. JohnF: Is there any objection to calling the question? Hearing none, the

question is called. JohnF: Is there any objection to passing this motion? I see one, so we will have

a vote. Who votes for this motion, voting members only show your voting tokens. This motion is technical and it passes with the vote 13:2:2.

MatthewF: There’s no such thing as a Service Period here – technically this just up until the next TIM, just a slight terminology problem. And there’s another at the end of the next sentence.



8.3.5.54. 8.3.5.54.1.

8.3.5.55. 8.3.5.56.

8.3.6. 8.3.6.1.

8.3.6.2.

9.1.1. 9.1.1.1.

9.1.2. 9.1.2.1. 9.1.2.2. 9.1.2.3. 9.1.2.4. 9.1.2.5.

9.1.2.6. 9.1.2.7.

9.1.3. 9.1.3.1. 9.1.3.2.

9.1.3.3. 9.1.3.4. 9.1.3.5. 9.1.3.6.

Bruce ?: Also, there might not be enough time left, so we need to add “time permitting”.

MathildeB: So I’ll revise it to the new version in 0796r3: In section 11.2.1.4 after subclause h: If the QAP does not receive an

acknowledgement to a directed MPDU or management frame sent to a STA in power-save mode following receipt of a PS Poll from that STA, it may retransmit the frame fewer times than the Max Retry Limit before the next TIM, but it shall retransmit that frame at least once before the next TIM, time permitting – subject to the Max Retry Limit and the MSDU Lifetime limit. If an Ack to the retransmission is not received, it may wait until the next TIM to further retransmit that frame subject to the Max Retry Limit an the MSDU Lifetime limit.

MathildeB: Any further change? MarkB: In the case of APSD and the service periods, you can argue that the

STA can make an intelligent choice. But the legacy STA can’t do that. One suggestion is that this happens only between QAPs and QSTAs. That’s my only concern.

Recess JohnF: We’re out of time in this session. Let’s come back in the next and

continue this discussion. The meeting recessed at 10:03am.

9. 10:30 Thursday Morning, November 13, 2003

9.1. Opening

Call to order JohnF called the session to order at 10:34am.

Discussion of Procedures JohnF: Mathilde still has the floor. How many more people have motions? Duncan Kitchin (DuncanK): I have one. MarkB: Stephen and I have another. JenniferB: I have one. JohnF: We have four plus Srini’s. So I’ll allocate about 15 minutes per person or

we won’t get done. Srini will have about 1 hour to get done with everything from the Ad Hoc groups. We need all of the comments done by Noon.

MathildeB: I have three or four papers. JohnF: Just go to the motions; your papers have been available for a while and

people could have read them. For now you have only 15 minutes.

Continuation of Document 03/796r3, Mathilde Benveniste MathildeB: Any further questions? MarkB: I was concerned about the first paragraph because I though it allowed a

premature dropping of a packet. But that paragraph has been removed, so this is fine.

MathildeB: I move to adopt the normative text of 03/796r3 in the first paragraph. MenzoW: Second. MathildeB: I call the question. DuncanK: Second.



9.1.3.8.

9.1.4.

9.1.4.1. 9.1.4.2. 9.1.4.3. 9.1.4.4.

9.1.4.5.

9.1.4.6. 9.1.4.7. 9.1.4.8.

9.1.4.9. 9.1.4.10.

9.1.4.11. 9.1.4.12. 9.1.4.13.

9.1.4.14. 9.1.4.15.

9.1.5.

9.1.5.1.

9.1.5.2.

9.1.5.3. 9.1.5.4.

9.1.5.5. 9.1.5.6. 9.1.5.7. 9.1.5.8. 9.1.5.9.

JohnF: Is there any objection to calling the question? Hearing none, the question is called.

JohnF: Is there any objection to passing this motion? I see one, so we will have a vote. Who votes for this motion, voting members only show your voting tokens. This motion is technical and it passes with the vote 9:2:1.

Documents 03/922r0 and 03/924r0, Clarifications on Call Admission Control for EDCA and Normative Text Changes for Call Admission Control in EDCA, Mathilde Benveniste

MathildeB: The normative text is in 03/924. MenzoW: Why required to have admission control? MathildeB: Else admission control won’t work. SriniK: I can think of case where you don’t want to have admission control for

voice, but do want to have for video, and this denies that. Why can’t we leave this a matter for policy?

MathildeB: That’s a legitimate point, so let’s just move on the second paragraph in 924 right now.

AmjadS: This is not of QAP? ThomasK: It is always initiated by the STA, but you can specify the direction. MathildeB: This requirement says that, if you don’t have a downlink TS, then you

can’t use that AC. JohnF: We’re running out of time, so we need to make the motion now. MathildeB: I move to adopt the text changes in the second paragraph of

03/924r0. {About clause 9.9.1.7.} DavidH: Second. JohnF: Any discussion on this? MarkB: I believe that a similar principle to what Srini said about the first

paragraph applies – do we want to make this mandatory? SriniK : I yield. JohnF: Any more discussion? Hearing none, is there any objection to pass this

motion as shown? I see one. So we will take this to a vote. Who is in favor of this motion? This is a technical motion and it fails 2:6:10.

Document 03/959r0a and 959r0, Enforcing QAP Policy to Deliver QoS Traffic, Amjad Soomro

AmjadS: This might just need a clarification, but I have some concerns about the APSD mechanism. There is Legacy Power Save and APSD. One complication is that the QAP must accept all requests for unscheduled data delivery. When the number of QSTAs exceeds some number (see document 03/861r1), the throughput degrades dramatically. Then the delivery of scheduled data delivery in the QBSS is compromised. The proposed normative text is in 03/959r0.

AmjadS: I move to instruct the editor to modify the referred paragraph in subclause 11.2.3 as follows: “{... if the} QAP will use scheduled or unscheduled service periods when servicing that QSTA.” {Complete text is in Document 03/959r0.}

MathildeB: Second. AndrewM: The assumption of the demonstration seemed to be that there is no

admission control. AmjadS: The purpose is to show that throughput goes down. AndrewM: But the problem is that there simply are too many admitted. AmjadS: There is no limit on the number of power save stations AndrewM: The AP doesn’t have to send the packets. DuncanK: I’ll pass.



9.1.5.11.

9.1.5.12.

9.1.5.13. 9.1.5.14.

9.1.5.15. 9.1.5.16.

9.1.5.17. 9.1.5.18.

9.1.5.19. 9.1.5.20. 9.1.5.21.

9.1.5.22. 9.1.5.23.

9.1.5.24.

9.1.5.25.

9.1.6.

9.1.6.1.

9.1.6.2.

9.1.6.3. 9.1.6.4. 9.1.6.5.

9.1.6.6.

9.1.6.7. 9.1.6.8.

MenzoW: I believe the QAP can decline requests with an unscheduled APSD and only accept scheduled APSD requests. So this already is possible.

AmjadS: If that were the case, then I’d withdraw my motion. But I don’t see where that is required.

MarkB: I speak against the motion. It was always intended that the TSPEC mechanism could be used to reject requests.

FloydS: I concur with Mark. SriniK: I am speaking neither against nor for. If it is clear then I can make an

editorial change to the motion. I move to amend this motion. JohnF: Please write this down. SriniK: I move to instruct the editor to modify the referred paragraph in

subclause 11.2.3 as follows: “to add the following text to the next TGe draft: “The Unscheduled Service Period set up through the ADDTS request may be declined by the QAP”. Further instruct the editor to remove any statements in the draft that conflict with this statement.

DavidH: Second. John: Is there any more discussion? Hearing none, I call the question. Who is

in favor of the motion to amend? This motion to amend is technical and it passes unanimously 9:0:4.

FloydS: I move to amend to place “Scheduled and” in this amended motion SriniK: Second. AmjadS: I would like to clarify that this applies only for the Power Save

mechanism. I move to amend this by adding “for power save delivery” after “Unscheduled Service Period”.

SriniK: Second. JohnF: Is there any discussion for this motion to amend the amendment?

Hearing none, is there any objection to passing this motion to amend the amendment? Hearing none, this motion to amend the amendment is passed unanimously.

JohnF: So now we have the amended amendment. Any more discussion of this motion? Hearing none, is there any objection to pass this amendment as shown? Hearing none, this motion to amend passes unanimously.

JohnF: Now we have the amended motion. Any more discussion of this motion? Hearing none, is there any objection to pass this motion as shown? Hearing none, this motion passes unanimously.

Document 03/963r0, Clarification on usage of MD and EOSP bits with APSD, Stephen Wang, Floyd Simpson, Ye Chen, Mark Bilstad

MarkB: We believe this is where everyone was at Tuesday. This is very much in line with what Mathilde presented Tuesday. We are leaning toward adding the included table in the draft. Note especially the top and bottom rows.

MathildeB: This is a trivial issue that only arises because of a confusion. When we added APSD signaling, the EOSP was not in the draft. This just takes a simple change. I don’t believe that we need to maintain these two new conditions. I’d like to suggest to wait until I can present the normative text on this that will make a much simpler change.

MarkB: This will be document 920? MathildeB: No, one much later than that. MenzoW: I agree with Mathilde; I believe that that this can be a simpler change.

The AP might want the STA to stay awake, so I don’t believe we need this restriction.

MarkB: I generally agree with that, but now would like to know about putting this table in as an informative table.

MathildeB: I believe that text would be more useful and can write that. FloydS: I believe that this table could be useful.


November 2003 doc.: IEEE 802.11-03/xxxr0 9.1.6.9. 9.1.6.10. 9.1.6.11.

9.1.6.12. 9.1.6.13.

9.1.6.14.

9.1.6.15. 9.1.6.16.

9.1.6.17.

9.1.7. 9.1.7.1.

9.1.7.2. 9.1.7.3.

9.1.7.4.

9.1.7.5.

9.1.7.6. 9.1.7.7. 9.1.7.8.

9.1.8.

9.1.8.1. 9.1.8.2. 9.1.8.3. 9.1.8.4. 9.1.8.5. 9.1.8.6.

9.1.8.7.

9.1.8.8. 9.1.8.9. 9.1.8.10.

AndrewM: I believe that tables in general are much easier to read. MatthewF: Just to be clear, there is no restriction on using the 00 case? MarkB: Correct. The core here is just to decide on the table and to go from

there. MatthewF: There is a “shall” in this table, so it shouldn’t be informative. StephenW: I’m rewriting this as “engages” and “e.g.” instead of “i.e.” So the

document now becomes r1. MarkB: I move to instruct the editor to add the table on Slide 5 of document

03/963r1 into the TGe draft. FloydS: Second. JohnF: Any more discussion? Hearing none, is there any objection to passing

this motion unanimously? I see one, so we will take it to a vote. The motion is technical and still passes unanimously: 14:0:2.

JohnF: Jennifer has reported that her motion is now combined with someone else’s, so she passes. SriniK is not here now, so he loses his turn. Mathilde, you’re next up.

Document 03/964r0, Resolution to Comment 497, Mathilde Benveniste MathildeB: This is about the differences between the More Data and ESOP

functions. This is the result of a suggestion by Isaac. MarkB: This works nicely with the table we inserted. MathildeB: I move to instruct the editor to incorporate the alternate resolution to

comment 497 as stated in 03/964r0. MatthewF: Friendly amendment, change the beginning to “The QAP shall use

ESOP=1…” MathildeB: So now my motion becomes: I move to instruct the editor to

incorporate the alternate resolution to comment 497 as stated in 03/964r1. MatthewF: I’m happy with this. AndrewM: Second. JohnF: Is there any further discussion on this motion? Hearing none, is there

any objection to accepting this motion as shown? Hearing none, this motion passes unanimously.

Document 03/0920r1, Normative Text for Clarifications in APSD , Mathilde Benveniste

MathildeB: The next topic is just a minor cleanup. SriniK: There are some other changes to these sections. MathildeB: This is purely editorial. SriniK: There is a “must” there. MathildeB: Am changing this to a “shall” FloydS: Friendly amendment: to the beginning of the second paragraph add

“APSD defines two different types of delivery mechanisms, depending upon the SP used.” And at the beginning of the last sentence of this paragraph add “Additionally,”

JohnF: This makes the document now r2. Let’s go quickly to the motion because we’re out of time.

MathildeB: I move to adopt the normative text changes in document 03/920r2. SriniK: Second. JohnF: Is there any further discussion on this motion? Hearing none, is there

any objection to accepting this motion as shown? Hearing none, this motion passes unanimously.


November 2003 doc.: IEEE 802.11-03/xxxr0 9.1.9.

9.1.9.1. 9.1.9.2.

9.1.9.3.

9.1.9.4.

9.1.9.5.

9.1.9.6.

9.1.9.7.

9.1.9.8. 9.1.9.9.

9.1.9.10. 9.1.9.11. 9.1.9.12. 9.1.9.13.

9.1.9.14.

9.1.9.15.

9.1.9.16.

9.1.9.17.

9.1.9.18.

9.1.9.19. 9.1.9.20.

9.2.1. 9.2.1.1. 9.2.1.2.

Document 03/658r16, Letter Ballot 59 Comments, Srini Kandala SriniK: Comment 351. MatthewF: The party will allow the work to move forward (but doesn’t really

accept this solution). SriniK: Any objections to accepting this resolution? Hearing none, then I will go

on . Comment 497 has been resolved. I’ll skip Comment xxx until the author is back in the room. Comment 747 is rejected only to move on. It will have to be done later. Comment 772 is declined just because we thought we needed more information on the comment and a suggested remedy. Comment 882 is declined for the same reason, and also to suggest a remedy.

BobM: The comment seems a bit sweeping and represents data that has been there for a long time.

SriniK: This comment was made by several people, so there seems to be some ambiguity there.

BobM: Does this apply to only this one section? How about making it a little less violent.

SriniK: Ok, I’ll finish the rest and come back. Comment 930: I’ll state “comment declined. The commenter is invited to provide more information.” Will the commenter tolerate this resolution for now?

AmjadS: All right. SriniK: Comment 931: again the recommended disposition is to provide more

information. AmjadS: Agree. With the next round I’ll bring in suggested normative text. ThomasK: Aren’t expansions of the TSPEC closed? AmjadS: We’ll discuss this offline. SriniK: Comment 871: the proposal is to add the QoS Null to the list of frames in

the first column, second row of Table 3.1. SriniK: Comment 402: Comment declined. This is similar to comment 772. We

need more information from both Matthew and Andrew on this. SriniK: Comment 303: Comment declined. The TG believes the current figure

accurately reflects the architecture. This is difficult because it is something that is broken in the base architecture; this problem is just reflected here.

SriniK: Comment 543 needs more discussion. If we don’t finish quickly now, will have to bring this up in the next session.

ThomasK: This is only about the receiver. So I would like add a description similar to what is suggested.

SriniK: So I’m writing an alternate resolution to instruct the editor to add the text: “The receive sequence number at the receiver shall be advanced only upon correctly received acknowledgements including block Acks.”

Ivan ?: What does this do to normal Legacy operations? SriniK: Add “, for the TID for which the Block Ack is set,“ between “number” and

“at the receiver”.

9.2. Closing

Recess JohnF: We’re now out of time and need to continue after lunch. The session recessed at 12:30pm.



10. 1:30 pm Thursday Afternoon, November 13, 2003

10.1. Opening

10.1.1. 10.1.1.1.

10.2.1.1.

10.2.2. 10.2.2.1.

10.2.2.2.

10.2.2.3.

10.2.2.4. 10.2.2.5. 10.2.2.6. 10.2.2.7. 10.2.2.8.

10.2.2.9.

10.2.2.10. 10.2.2.11.

10.2.2.12.

10.2.2.13. 10.2.2.14. 10.2.2.15.

10.2.2.16.

10.2.2.17. 10.2.2.18.


10.2. Comment Resolutions JohnF: First Srini will finish with his comments. Then I have a request from

Duncan. And we’ll finish up with all of the comments in this session.

Continuation of Ad Hoc Group Comment Resolution SriniK: For Comment 543 we had agreed on some text, but the commenter

wanted some other text. ThomasK: There is a lot of logic involved and people who are implementing this

mechanism need to check that. SriniK: Then I will some craft some text just to get a resolution now: “Comment

declined. The task group felt that that is an implementation detail.” We had drafted some text, but then found holes in it. So we’re putting this back on the drawing board.

ThomasK: That is ok for now. SriniK: Comment 497. Has a formal resolution been written and accepted? MathildeB: Yes, that was in 03/964r1, which was passed this morning. SriniK: Comment 822 is still unresolved. BobM: I believe this text has been in there for a long while, and believe that this

issue is, at best, a benign problem. SriniK: I’ll just try to write a resolution now and see where it goes. I move to

accept the recommended change for comment 822 described in document 03/658r. I’d also like to point out the commenter isn’t asking for any particular change in that comment. I believe the commenter is referring to the first sentence of the second paragraph of 9.1.3.2. I interpret the comment to be saying that the draft should not say and HC shall always have a CFP.

Isaac: I believe that it is up to the decision of the QAP. SriniK: Agreed. There is a related statement in 9.9.2.3: an HC *may* generate

a CF Parameter Set, and it is clear that a CF Parameter Set is required for there to be a CFP.

MatthewF: I think the problem is just the term “the CFP”. If we change this to “any CFP belonging to this BSS” that should satisfy this comment.

SriniK: How about splitting the sentence between “CFP” and “CP”? CharlesW: How about “any locally generated CFP or CP”? SriniK: I agree with that. Also, we definitely do not use CFP all the time – only

generated when there is a CF Parameter Set. So I’ll capture the text Charles suggested: “Accepted. Replace ‘both the CFP and CP’ with ‘the CP and any locally-generated CFP’.

BobM: I think we’ve been religious about producing specificity here. I’ll agree to it, but reserve the right to comment, myself.

SriniK: Then I’ll include that in the general motion. SriniK: I move to accept the entries in ‘Recommended disposition’ cells in

document 03/658r17 as the resolutions for the comments that are marked green. Further instruct the editor to incorporate the changes given in these cells.



10.2.2.20. 10.2.2.21.

10.2.3. 10.2.3.1.

10.2.4.

10.2.4.1.

10.2.4.2. 10.2.4.2.1.

10.2.4.3. 10.2.4.4.

10.2.4.5. 10.2.4.6. 10.2.4.7.

10.2.4.8.

10.2.4.9. 10.2.4.10. 10.2.4.11. 10.2.4.12. 10.2.4.13.

10.2.4.14.

10.2.4.15.

10.2.4.16. 10.2.4.17.

10.2.4.18.

10.2.4.19. 10.2.4.20.

10.2.4.21. 10.2.4.22. 10.2.4.23.

JohnF: Is there any discussion before I ask for a second? Hearing none, do I hear a second?

CharlesW: Second. JohnF: We now have the formal motion on the floor. Is there any further

discussion on this motion? Hearing none, is there any objection to accepting this motion as shown? Hearing none, this motion passes unanimously.

Procedures JohnF: At a minimum, we can now go to recirculation, because we have

resolved all of the comments. But in the time remaining we want to revisit some of the past issues. Duncan is next.

Document 03/0892r0, Miscellaneous 802.11e Cleanup, Duncan Kitchin

DuncanK: There are a few corner cases where we’ve found problems, especially with Block Acks. First sequence numbering; there is an ambiguity in mapping TIDs.

DuncanK: I move to instruct the editor to add the following to the draft: “On receiving a TID corresponding to an EDCF AC, the QSTA shall

consider all context, including block ack status, to be related to each AC.“.

??: In terms of mechanics, how do you propose to do this? DuncanK: Just need to make sure for Block Acks to do the same mapping

everywhere, so the same TID is treated the same everywhere. Isaac: When set up a block ack, how do you decide which to use? DuncanK: Either, as long as it is consistent. ThomasK: We changed the parameters of an AC in downgrading. Is this

affected by your proposal? DuncanK: No. If you ran out of bandwidth, there is no limit on reordering for

others; you are only limited to a particular AC. AmjadS: Believe that this could have some clarifying text. DuncanK: That would be alright, though not necessary. MenzoW: Second. JohnF: Any friendly amendments? JohnF: We now have the formal motion on the floor. Is there any further


DuncanK: The next is on mixed normal and block acks: currently once a block ack is set up, all frames must be sent with a block ack.

SriniK: I think this might be gone. The intent was that there is a line that is in conflict. We intended to delete that.

DuncanK: Let’s defer this for now. DuncanK: Opportunistic TXOP: currently we are not permitted to send a polled

TXOP even if the medium is idle for a sufficient period. DuncanK: I move to instruct the editor to modify the text in subclause 9.9.2.3 to

remove the restriction preventing opportunistic use of EDCF TXOPs for frames subject to a polled TSPDC which permits EDCF access.

JohnF: Any friendly amendments? MathildeB: We relaxed the restriction on EDCF access on certain conditions,

because we didn’t want a greedy STA to define lots of TXOPs. SriniK: Furthermore, the HC has the highest priority anyway. MathildeB: We don’t want to give a STA the incentive to do both. DuncanK: You can’t do it within the same TSID. It would be pretty difficult to

abuse. At first you have to obey the TSOP rules.



10.2.4.25. 10.2.4.26. 10.2.4.27. 10.2.4.28.

10.2.4.29.

10.2.4.30. 10.2.4.31. 10.2.4.32. 10.2.4.33.

10.2.4.34. 10.2.4.35.

10.2.4.36.

10.2.4.37. 10.2.4.38. 10.2.4.39.

10.2.4.40. 10.2.4.41.

10.2.4.42.

10.2.4.43. 10.2.4.44. 10.2.4.45. 10.2.4.46. 10.2.4.47. 10.2.4.48.

10.2.4.49. 10.2.4.50. 10.2.4.51.

10.2.4.52. 10.2.4.53.

10.2.4.54.

MathildeB: I don’t see the benefit to do that. Don’t take the channel time for a low priority thing.

DuncanK: Can still set the AP to the policy that allows these. MathildeB: The mix of polled and EDCF access is optimal DuncanK: I agree. You are only allowed to do this if you don’t get the polls. MathildeB: I suggest the friendly amendment: add to the end “in the case of a

lost ACK”. DuncanK: I don’t agree. I don’t want to put back in the sentence we took out last

time. JohnF: I hear no more discussion, so I’ll ask for a second. SriniK: Second. JohnF: Now I’ll take a queue for discussion. MathildeB: I speak against. If there is an idle, the STA can choose polled

access or its own access. That’s nice for the STA. But then we’re wasting channel time. This provides an incentive to waste channel time. I am in favor of supporting this in a restricted case – but only when an uplink frame doesn’t receive an ack. I would like to vote against this and bring in an alternate proposal.

ThomasK: I speak in favor. This motion allows simultaneous polling and EDCA. SriniK: Am not against or for. This is true when the access policy is ???

Second, whether you put it at the beginning or end of the queue. DuncanK: I want to respond to Mathilde’s point about greedy STAs. When

people test silicon, they find out whether we are doing this. The implementer should be free to do stupid things. And I call the question.

JohnF: Is there a second to call the question? ??: Second. JohnF: Is there an objection to call the question: I see one. So we will have

vote: Who is in favor, against, abstain? This motion to call the question takes a 2/3 vote and fails with a vote of 6:8:13.

MenzoW: I speak in favor of this motion. The channel is idle; why not use it? MathildeB: To answer Duncan’s point about STAs having plenty of ways to

cheat: let’s not add one more. To answer Menzo’s point: the high priority STA is counting down and will seize the channel before the lower priority STA. If you don’t use the polls, you should not be setting up a TS. You’re just wasting bandwidth.

JohnF: Is there any objection to limiting this to 5 minutes, because there are other people want to make motions. I see no objection, so I’ll take a queue.

Matthew Sherman (MatthewS): Must you use the same TSID? DuncanK: The TSID field must be populated with the same value. MatthewS: I like that. MarkB: Is the STA allowed to use EDCF to do retransmissions? SriniK: If its access policy is strict HCCA. DuncanK: But only if it is in the TSPEC. Otherwise no. But that has nothing to

do with this motion, though I would also support that sort of change. MatthewF: You can refuse a TSPEC with a policy that you can’t do that. DuncanK: Agree. MathildeB: One clarification on this: you’re saying that it is possible to use this

for error recovery and missed polls? DuncanK: This is talking to a different set of conditions. JohnF: The 5 minutes are over so I call the question. This is a technical motion

and takes 75%. The motion passes with 14:4:10. DuncanK: I’ll discuss the remaining motion with Srini.



10.2.5.

10.2.5.1.

10.2.5.2.

10.2.5.3. 10.2.5.4.

10.2.5.5. 10.2.5.6. 10.2.5.7. 10.2.5.8. 10.2.5.9.

10.2.5.10. 10.2.5.11. 10.2.5.12. 10.2.5.13. 10.2.5.14.

10.2.5.15.

10.2.5.16. 10.2.5.17.

10.2.6. 10.2.6.1.

10.2.6.2. 10.2.6.3.

10.2.6.4. 10.2.6.5.

JohnF: I see only two people who want to make more motions. Remember that everything is done at 3:30pm. So next is Mathilde.

Document 03/924r1, Normative Text Changes for Call Admission Control in EDCA, Second Paragraph, Mathilde Benveniste

MathildeB: I received some feedback on why the motion this morning failed. So we might need to have a motion to reconsider. The issue is about section 9.9.1.7 and, again, is in response to part of Comment 577. The new proposal is to insert the following at the end of this section: “If an ADDTS request has not been accepted for downlink traffic with a UP that maps to an AC with ACM equal to 1, the QAP shall lower the UP of such traffic so that it is transmitted in an AC that does not require admission control.”

MarkB: One question: I believe there is an alternative way to solve this. When you use AC and assign a TSID, the AP can have a separate queue to make sure there is no mixture of admitted and non-admitted.

MathildeB: You can do all sorts of other clever things. MarkB: That’s my point; you have other alternatives. You can use more queues

to solve this. MenzoW: How about changing “shall” to “should”? MarkB: That’s better. MathildeB: We don’t have a “shall” for the downlink. MenzoW: But this allows a particular behavior. MathildeB: So change this to insert the following at the end of this section: “If an

ADDTS request has not been accepted for downlink traffic with a UP that maps to an AC with ACM equal to 1, the QAP should lower the UP of such traffic so that it is transmitted in an AC that does not require admission control.”

MarkB: This is the issue I presented earlier this week. The UP is the AC. SriniK: Let’s think about this for the next vote. JohnF: Let’s make a motion now or go to the next. DavidH: Should there be a motion to reconsider first? JohnF: A motion to reconsider is 2/3 and this technical motion is 75%. I would

like to bypass the motion to reconsider. Is there any objection to that? I hear none, so that is what we’ll do.

MathildeB: I move to insert the following at the end of this section: “If an ADDTS request has not been accepted for downlink traffic with a UP that maps to an AC with ACM equal to 1, the QAP should lower the UP of such traffic so that it is transmitted in an AC that does not require admission control.”

MenzoW: Second. JohnF: We have a formal motion on the floor. Is there any objection to passing

this motion? I see one, so we’ll vote. This is a technical motion; I count the vote: 3:1:15. So it passes with 75%.

Document 03/953r1, , Jennifer Bray JenniferB: Both of the papers behind this paper have been on the server for 4

hours, but this merged paper has not. Is that allowed? JohnF: Since both papers have been on for over 4 hours, I will allow this. JenniferB: The two papers had almost the same solutions, so that’s why we

merged these papers. The proposal modifies text in subclause 9.10. The first change is that you don’t need the initiator field. The key is that the ADDBA request is by the originator only. Then there are many minor changes deleting “initiator” from the parameter sets. There are other changes in 11.4.4.

DuncanK: Block acks are still unidirectional? JenniferB: Yes.



10.2.6.7. 10.2.6.8. 10.2.6.9.

10.2.7.

10.2.7.1.

10.2.7.2.

10.2.7.3.

10.2.7.4. 10.2.7.5.

10.2.8.

10.2.8.1.

10.2.8.2. 10.2.8.3. 10.2.8.4.

10.2.8.5.

10.2.8.6. 10.2.8.7.

10.2.8.8.

10.3.1. 10.3.1.1.

11.1.1. 11.1.1.1.

JenniferB: I move to instruct the editor to incorporate the changes specified in document 03/953r2 into the TGe Draft.

JohnF: Any suggestions for modification. Hearing none, is there a second? Isaac: Second. JohnF: We now have a formal motion on the floor. Is there any further


Document 03/924r1, Normative Text Changes for Call Admission Control in EDCA, Third Paragraph, Mathilde Benveniste

MathildeB: This is about the third paragraph on this page in Document 924. This is in response to another part of Comment 577.

MathildeB: I move to accept the normative text changes in the third paragraph of document 03/924r1 into the next TGe draft.

JohnF: Are there any friendly amendments to this motion? Hearing none, I ask for a Second.

MarkB: Second. JohnF: We now have the formal motion on the floor. Is there any further


Document 03/924r1, Normative Text Changes for Call Admission Control in EDCA, First Paragraph, Mathilde Benveniste

MathildeB: Finally I get to the first paragraph of this. This is a “should”, not a “shall”.

MarkB: How about changing to “ACM flag set to 1” instead of admission control. MathildeB: Agreed. MathildeB: I move to accept the normative text changes in the first paragraph of

document 03/924r1 into the next TGe draft. And this about the final portion of Comment 577.

JohnF: Are there any friendly amendments to this motion? Hearing none, I ask for a Second.

MarkB: Second. JohnF: We now have this formal motion on the floor. Is there any further


JohnF: We’re now out of time, so we’ll recess until our final session.

10.3. Close

Recess The session recessed at 3:32pm.

11. 4:00 pm Thursday Afternoon, November 13, 2003

11.1. Opening

Call to order JohnF called the session to order at 4:29pm (delayed due to conference with the

802.11 Leadership about the current procedures).


November 2003 doc.: IEEE 802.11-03/xxxr0 11.2. Discussion of Papers

11.2.1. 11.2.1.1.

11.3.1. 11.3.1.1.

11.3.1.2.

11.3.1.3. 11.3.1.4.

11.3.1.5. 11.3.1.6. 11.3.1.7. 11.3.1.8.

11.3.1.9.

11.3.1.10.

11.3.1.11.

11.3.1.12.

11.3.1.13.

11.3.1.14. 11.3.1.15. 11.3.1.16. 11.3.1.17. 11.3.1.18.

Schedule JohnF: We now have on the agenda Old Business, New Business, Srini’s review

of all of the comment resolutions, and finally a decision on the draft.

11.3. Fixed Agenda Items

Old Business, New Business JohnF: Is there any Old Business? Hearing none, we go to New Business. We

expect the percentage of approval to go up. If that is true, we should be able to wrap up everything in January and package everything that the 802.11 Exec Committee will need. Official Procedure 10 will allow us to accelerate to go to Sponsor Ballot. Stuart Kerry is here to tell us what that means. I would suggest to the group to approve that plan. If we later decide something is broken, we don’t have to accept Procedure 10 and we can then go back to work on the technical details.

Stuart Kerry: LMSC Procedure 10. You have to show the vote tally, ballot information, etc. We cannot do an actual ExCom meeting in January because it is not scheduled. But Procedure 10 is allowed if there are no new negative comments that have not been circulated before, and No voters. The first step is to decide whether to go to recirculation.

Q: Would this mean sponsor ballot after January? JohnF: Yes. There is nothing to stop us unless there are new negative

comments or No voters. Q: This is about Draft 6.0? JohnF: Yes. Q: And we won’t be any worse off by doing this? JohnF: No. We can still decide from the comments we receive from this

recirculation whether to go to Sponsor Ballot. StuartK: The next RevCom meeting will be in the June timeframe, so you’ll have

plenty of time after that. You then could also go into an enhanced process that involves telephone contacts.

JohnF: I don’t believe Draft 6.0 will be done by tomorrow, but Srini tells me it is about 90%. I hope no one objects on that basis – though, if they do, it is a valid objection. I will also ask the WG plenary to approve interim meetings in case we need to have those meetings to do resolutions. We’ll assign three weeks for Interims – at least in December and February.

ThomasK: Companies are already implementing and there will be Plugfests starting up. Is there any way for results of those to feed back into the standard, if we try to rush it too fast?

StuartK: I understand your point; in this group it is easy to bring it back in. In the Sponsor Ballot it is a closed group who are the only ones who are allowed to make comments. Then you have to make sure any comments you have come through a sponsor balloting ballot member.

Terry Cole (TerryC): If you have changes that come in, will this group will be equipped to make changes? That is, if you decide you won’t be able to go to sponsor ballot, will you have the authority to go to another recirculation ballot?

JohnF: We are going to try to authorize interim meetings to do that. TerryC: I’m satisfied – I can see you’re going with both belt and suspenders. AmjadS: Is an interim meeting empowered to issue a recirculation ballot? JohnF: An Interim Meeting is so empowered. This is what we have done before. JohnF: We not have our special orders to review the Comment Resolutions, so I

pass the floor to Srini.


November 2003 doc.: IEEE 802.11-03/xxxr0 11.3.2.

11.3.2.1.

11.3.2.2.

11.3.2.3.

11.3.3.

11.3.3.1.

11.3.3.2. 11.3.3.2.1.

11.3.3.2.1.1.

11.3.3.2.1.2.

11.3.3.2.2.

11.3.3.3. 11.3.3.4.

11.3.3.5. 11.3.3.6. 11.3.3.7.

11.3.3.8.

11.3.3.9.

11.3.3.10.

11.3.3.11.

11.3.3.12.

11.3.3.13. 11.3.3.14. 11.3.3.15. 11.3.3.16.

11.3.3.17.

Comment Resolution Review: Document 03/658r17, Srini Kandala SriniK: This is the file in which all comments are resolved. We had a total of 951

comments, 550 technical and 401 editorial. Any questions on this document? SriniK: I have been working on the next draft (Draft 5.2 currently is on the server)

and have incorporated about 90% of the comments. Any questions on this? I don’t hear any here, either.

JohnF: Mathilde, you wanted to change something on these draft resolutions?

Document 03/972r1, Use of EDCA Access During HCF Polling, Mathilde Benveniste

MathildeB: This is a response following Duncan’s motion. This was just to make a minor change that occurred after Duncan’s change.

MathildeB: I want to discuss a motion: “Instruct the editor to modify the text in subclause 9.9.2.3 of the TGe

draft to permit use of EDCA to transmit MSDUs belonging to traffic streams for which there is a strict HCCA policy under the following conditions:

The MSDU has been sent previously but an acknowledgement has not been received.

The poll for the MSDU is missing; i.e., a poll has not been received by the non-AP QSTA within a time interval since the time of the last received poll that is equal to the maximum service interval.

When frames associated with a TSPEC are transmitted over contention-based channel access, they shall use the EDCA parameters associated with the UP specified in the TSPEC.”

SriniK: What do you do when a STA does not obey this? MathildeB: This group has eliminated the better alternative. To some of us this

is an important option to have, because it is much more efficient. SriniK: I would suggest that maybe you should also go for a third mode. MarkB: I was going to say the same thing. Maybe a forth policy. MathildeB: This is something we had in the Draft until today. The recovery is

going to happen quite open and it is important for many implementers to simplify this.

DuncanK: But we didn’t touch this text. We didn’t have the option to do this before.

SriniK: Duncan just added the new mode, and didn’t move the old modes. I believe we can keep both.

MathildeB: I just want to be able to specify that a STA that has an established TSPEC after negotiation with an AP, … After Duncan’s motion, I don’t believe we can do that any more.

DuncanK: I believe you’re correct about that. You can still restrict HCCA or do something less restrictive (after my motion). I agree that we changed this capability that you had before.

MathildeB: I agree. And that’s not enough for what we need to do. Srini, how about changing the proposal to create a third, hybrid, HCCA which basically what we had before?

JohnK: What is the application that needs to be covered by this facility? MathildeB: You want to do HCCA polling and the channel is very busy. JohnF: We are running out of time, we must have a motion now. MathildeB: Strawpoll: how many would vote against this if we used the term

“hybrid” for a third HCCA policy. JohnF: I count 9 people.



11.3.3.19. 11.3.3.20.

11.3.3.21. 11.3.3.22.

11.3.4. 11.3.4.1.

11.3.4.2.

11.3.4.3. 11.3.4.3.1.

11.3.4.3.2.

11.3.4.4. 11.3.4.5. 11.3.4.6.

11.3.4.7. 11.3.4.8. 11.3.4.9.

11.3.4.10. 11.3.4.11.

11.3.4.11.1.

11.3.4.12. 11.3.4.13.

11.3.4.14. 11.3.4.15.

11.3.4.15.1.

11.3.4.16. 11.3.4.17. 11.3.4.18. 11.3.4.19. 11.3.4.20. 11.3.4.21.

11.3.4.22.

MathildeB: Strawpoll: how many would vote against this if we used the term “strict” HCCA policy?

JohnF: I count 9 people. So do you want to make a motion? MathildeB: I now see people voting against this who earlier said they wouldn’t,

so I won’t make a motion. JohnF: Srini, do you have more to cover? SriniK: No, I’m done.

Procedural Motions JohnF: We have a main plan and a contingency plan. Main plan: recirculation

ballot, examine for new negative comments and No votes – if none, then reject the remaining comments.

JohnF: The contingency plan is invoked if the main plan doesn’t work. This plan is to authorize interim meetings to cover the new ballot comments.

SriniK: I move to: Enable the editor to produce 802.11e draft 6.0 based on the comment

resolutions in 11-03/658r17 and, Authorize a 15-day LB recirculation of 802.11 TGe draft 6.0 to conclude

no later than 12/20/2003. DuncanK: Second. MarkB: Would having a longer recirculation disrupt anything we are trying to do? SriniK: There’s something wrong if you go for longer than 15 days and then

invoke procedure 10. AmjadS: We should conclude as soon as possible. JohnF: 15 days for recirculation is the norm by 802.11 standards. JohnF: I would like to take a count, so everybody who is in favor of this motion

raise your tokens; against; abstain? The motion passes unanimously with 26:0:6.

JohnF: Next motion: JohnK: I move to:

Request approval of a SB for draft 802.11e 6.0 by ExCom using LMSC Procedure 10 assuming that the conditions require for procedure 10 are met.

SriniK: Second. JohnF: I would like to take a count, so everybody who is in favor of this motion

raise your tokens; against; abstain? The motion passes unanimously with 29:0:4.

JohnF: The next motion: JohnK: I move to:

Authorize TGe to hold an interim meeting for the week of February 16, 2004 to resolve comments from the most recent 802.11e recirculation ballots and to initiate any follow on letter ballots after resolving those comments as required.

SriniK: Second. JohnF: Is there any discussion on this motion? MathildeB: We will have this interim anyway? JohnF: No, I’ll only call this meeting if the other fails. MathildeB: What will happen to the comments from the recirculation ballot? JohnF: Either of two things: if we reject the remaining comments, we can go on

with Procedure 10. If we don’t then we won’t go to Sponsor Ballot and will continue with the comment resolution process.

JohnF: I will again take a count, so everybody who is in favor of this motion raise your tokens; against; abstain? The motion passes unanimously with 31:0:0.




11.3.4.23. 11.3.4.24.

11.3.4.24.1.

11.3.4.25. 11.3.4.26.

11.3.4.27.

11.3.4.28.

11.3.4.29.

11.3.4.30. 11.3.4.31. 11.3.4.32.

11.3.5. 11.3.5.1.

And the final motion: SriniK: I move to:

Authorize the 802.11 January 2004 interim meeting to resolve comments from the most recent 802.11e recirculation ballot and to initiate any follow on letter ballots after resolving those comments.

Kiwin Palm: Second. JohnF: I will again take a count, so everybody who is in favor of this motion raise

your tokens; against; abstain? The motion passes unanimously with 30:0:0. JohnF: I believe that these are all of the motions that we need. Is there any

other procedural motion that someone would like to bring to the floor? Hearing none, are there any other comments?

MathildeB: I am worried about the notion that we are going to reject all comments from the next recirculation ballot, because we have been working on the basis that we could make more technical changes.

JohnF: If we decide in the next meeting that we do not need any technical revision to Draft 6.0, then we may invoke Procedure 10. If we need more technical changes, then we simply can’t invoke Procedure 10.

DuncanK: I move to adjourn. BobM: Second. JohnF: Does anyone object to passing this motion. I see one, so everybody who

is in favor of this motion raise your tokens; against; abstain? The vote is 7:5:12. Looking up Robert’s Rules, I see that it requires a majority vote, so we are adjourned.

Meeting close The TGe November 2004 meeting closed at 5:50pm.



TGi Albuquerque NM Plenary Meeting Minutes November 2003


Author: Frank Ciotti Apacheta Corporation 25231 Grogan’s Mill Rd. Suite 330 The Woodlands, TX 77380 Phone: 281-465-4949 Fax: (413) 556-3532 e-Mail: [email protected]

Abstract

Minutes of the 802.11 Task Group I meetings held during the 802.11 WLAN Working Group Plenary Session in Albuquerque, New Mexico from November 10th – 14th, 2003.

Minutes page 1 Frank Ciotti, Apacheta


Monday, November 10, 2003 4:00pm

Call to Order & Agreement on Agenda Meeting called to order on Monday, November 10, 2003 at 4:02pm by Chair Dave Halasz.

Secretary: Frank Ciotti

Agenda discussion - Proposed Agenda: • Approve Agenda • Approve Meeting minutes from Herndon (03/830) & Singapore (03/823) • Review IP policy & Letters received • Chair’s status

– LB52, LB57, LB60, LB61 & LB62 • Discuss going to Sponsor Ballot

– LB62 comments, 03/842 spreadsheet – Any new subjects in LB62 comments? – Re-affirm motion (Task Group, Working Group)

• Draft D7.0 available from IEEE? • Public comments about 802.11i draft • Not meet on Tuesday (work in ad-hoc) • Comment resolution of LB62 • Prepare package for SB motion in ExComm • WAPI position • Submission presentation

– OUI Usage (03/840) – Controlled port location

• Prepare for next meeting

Chair: In order to go to SB, a motion is needed. ExComm is comprised of all the WG chairs. All no votes must be described in a package and what was done to try to address them.

Chair: Stuart asked me to give a presentation on Wednesday on WAPI. China passed a law in May 2003 requiring WAPI security for WLANs. The law goes into effect on December 1st. There are questions about legacy equipment and manufacturing of non-WAPI devices in China.

Comment: Do we know if WAPI is secure?

Chair: We don’t have an answer for that yet.

Comment: Will the WAPI presentation be in TGi or the WG?

Chair: In the WG.

Chair: Regarding the “Public comments about 802.11i draft”. A public document has been written about the TGi draft. All our submissions are public. We need to let ExComm know that we are aware of the public document and wish to go to SB despite it.

Chair: do we want to meet only part of the day on Tuesday instead of not at all?

Comment: I want to make sure we don’t loose time and we can get to SB. There are times on Thursday that we can give up and attend the Fast Roaming SG meeting if we do not need the time.

Comment: How do we address the Comments that get converted from No to Yes?

Chair: Many have been addressed already. For those that haven’t we can simply reject. We could invoke Procedure 10. During this Plenary, we have to state that we plan to go to SB at the next Interim (January). I feel this is not a good idea. There is a lot of consensus currently. You can’t go to SB if a Yes comment is changed to a No. There



were 14 No votes – that is now down to six. We want to get the No vote down as much as we can so that the package we give to ExComm is as small as possible.

Comment: Will any of the technical people from China be here for the WAPI presentation?

Chair: no.

Comment: The English version of the document describing how the WAPI meeting went is very different than the Chinese version.

Comment: I propose that we meet Tuesday in ad-hoc until at 4:00pm, and then continue with agenda at that time.

New agenda:

• Approve Agenda • Approve Meeting minutes from Herndon (03/830) & Singapore (03/823) • Review IP policy & Letters received • Chair’s status

– LB52, LB57, LB60, LB61 & LB62 • Discuss going to Sponsor Ballot

– LB62 comments, 03/842 spreadsheet – Any new subjects in LB62 comments? – Re-affirm motion (Task Group, Working Group)

• Draft D7.0 available from IEEE? • Public comments about 802.11i draft • Meet Tuesday at 4:00pm (work in ad-hoc until 4:00pm) • Comment resolution of LB62 • Prepare package for SB motion in ExComm • WAPI position • Submission presentation

– OUI Usage (03/840) – Controlled port location

• Prepare for next meeting

Chair: Any Objection to agenda?

none

Meeting minutes approval

Motion by Dorothy Stanley Move to approve the TGi minutes from Herndon, VA meeting (document 03/830) and Singapore meeting (03/823)

Second: Dave Nelson

Chair: any objection?

None

Motion Passes

Review IP Policy Two slides requested by WG chair “IEEE-SA Standards Board Bylaws on Patents in Standards” and “Inappropriate Topics for IEEE WG Meetings” were shown and read.



Any objections regarding IP Policy are to be made to either the WG or TG chairs.

Chair: Does anybody have a patent they wish to disclose?

No.

Chair’s Status LB52 passed 76% (2074 comments) that allowed us to issue re-circs. LB62 passed with 95% (230 comments).

Comment: Is the 230 comments going to be an issue with going to SB?

Chair: this shouldn’t be an issue since most are editorial and non-technical.

Comment: how long to get through SB?

Chair: I’ll get to that later in the agenda.

802.11i Sponsor Ballot Discussion Chair: will need to address the current 03/842

Straw Poll by Dave Halasz TGi should proceed to Sponsor Ballot at this session?

Discussion:

Chair: This straw poll is to get a feel for the direction we should take, and that the Agenda is correct.

Comment: If we feel there are errors in the draft that will be caught in SB, should be go to SB?

Chair: SB voters must be a member of IEEE SA to be eligible. Then one must sign-up stating they are interested in being a SB voter. A pool will be selected from those interested parties. The TGi SB pool was recently re-formed.

Comment: How do you know if you are on the pool?

Chair: you would get a response back.

Comment: is the list of SB Pool members available?

Chair: the SB Pool is not publicly available.

Chair: There pool is limited to about 100.

Comment: who selects the pool members?

Chair:Stuart Kerry. He selects a balanced set of members based on profile of 802.11 involvement.

Comment: there may be a comment that reveals a significant flaw.

Chair: we need to re-affirm this after reviewing the LB comments.

Comment: How tied are we to the comments in the SB process?

Chair: If we go to SB now and do not reach 75%, we must run another 30day SB.

Chair: Also, with a SB you must reach a 75% return rate. If not met, then the time is extended.



Chair: If we don’t go to SB now, we push this out 4 months. We have a good shot at this. If we go through all the comments and find one that is a valid comment on new subject matter, it may make sense to invoke Procedure 10 at that time.

Comment: How soon do we have to get the SB out?

Chair: After a draft passes SB, it goes to RevComm. RevComm meets only 4 times a year.

Chair: ExComm will meet on Friday to determine which drafts go to SB.

Chair: If we go to SB, we have a chance to go to RevComm in March. March is the earliest. June is realistic.

Chair: The SB processing for the TG is the same as for Letter Ballots. We address comments returned from the SB votes.

Result: 32-0-6

Making Draft 7.0 Available Chair: If we make Draft 7.0 available, draft 3.0 will go away. People and organizations are relying on draft 3.0.

Comment: WPA relies on draft 3.0 with editing instructions. If draft 3.0 goes away, then WPA will need to get permission to insert the text from draft 3.0 into the WPA draft. I don’t see this happening.

Chair: This came up as a reason to make the draft available to the people working on WAPI.

Comment: why can’t IEEE make both draft 3.0 and draft 7.0 available. They can sell both.

Chair: I hope to find out if this is possible by Thursday.

Comment: When TGi is final, will any draft that is posted go away?

Chair: not sure. We will need to find this out as well.

Comment: if they are making money, why pull them?

Motion by Frank Ciotti Motion to postpone discussion on making draft 7.0 available for purchase until Thursday’s morning session.

Second: Paul Lambert

Discussion:

None

Any objection?

None

Motion passes

Public comments on 802.11i draft Chair: Someone may ask a ExComm member how they could agree to go to SB with this documented issue not being resolved.

Comment: Are we specifically talking about comments from Bob Moskowitz’s paper?

Chair: yes

Comment: I’m not sure this is a technical issue. Did Bob vote no on going to SB based on this?

Chair: No, the author of the paper voted yes to go to SB.



Comment: This is really a matter of educating the user on the level of security.

Comment: There are certain algorithms that use PSK’s that are not subject to offline dictionary attacks (e.g. IKE with PSK)

Comment: This is also an implementation issue. The vendor could mandate or recommend a more secure passphrase. The device could also validate a suitable PSK.

Comment: I have no problem with Bob’s article. I’m concerned that the press will pick-up on this and claim that PSK is broken.

Comment: WiFi has already released a comment on this.

Comment: It would not be fruitful for the Task Group to publicly address this paper. It may sound defensive. A short statement from Bob would be more powerful.

Chair: This is correct for us to address as the IEEE responsibility will fall on us. A statement from Bob will help as well.

Comment: Bob has written a good paper on this. We don’t need another position paper.

Chair: We can’t respond to the article by saying “go read the article”. It points out some of the known issues.

Comment: The paper known issues that users should be aware of. We should not present anything that is defensive.

Comment: At one point in the paper, it states “This offline attack should be easier to execute than the WEP attacks”. This is misleading/wrong. Nor does he describe what it takes to truly mitigate it.

Comment: Are we attempting to address Bob’s paper, or the press’ interpretation of the paper?

Comment: What we are trying to manage here is the public’s perception. We want to convince people that PSK is not broken if used properly.

Chair: It is proper for TGi to create a position paper on this.

Comment: the position should be that we welcome Bob’s paper, however it does not state that PSK is broken.

Comment: There is also a new article stating that WPA may be less secure than WEP.

Chair: Let’s address the paper itself, rather than the press. It would be unmanageable.

Comment: Responding to this could put us in a viscous cycle of responding to all future articles on 802.11 security.

Comment: Bob mentioned that he would write an article about this for one of the magazines, so he may be doing a little damage control for us.

Chair: we still need to respond to this. The WG chair has asked for us to follow up on this.

Chair: Do we have volunteers to help draft a response to this?

The position paper ad-hoc group is: Dave Nelson, Frank Ciotti, Mike Moreton, Andrew Kheiu (See Dave N.). They will have a draft ready by Thursday

Since we are not meeting in the morning, the position paper ad-hoc group will meet tomorrow morning in the TGi meeting room.

LB62 Comment Resolution Tim Moore will work with Dave Halasz in changing appropriate comments from Technical to Editorial.

The LB comment processing ad-hoc work will be done in the meeting room tomorrow afternoon.

WAPI Position from the Task Group • Suggestion

– IEEE 802.11i is working on MAC enhancements for security.

– Desire is for IEEE 802.11i to become an international standard



– Regulatory domain sometimes have concerns. IEEE 802.11 has done work to accommodate, such as IEEE 802.11h and IEEE 802.11j. If there are some regulatory concerns, they can be addressed by a new PAR.

Chair: Stuart has asked that we draft a position paper on WAPI.

Chair: if there are volunteers to help draft a position paper, please see me.

Chair: Any objection to recessing until tomorrow at 4:00pm, with a LB comment resolution ad-hoc at 1:30?

None

Recessed at 6:00pm

Tuesday, November 11, 2003 4:00pm

<resumed at 4:07pm>

ch: We postponed the discussion on draft 7 available until Thursday. We have ad-hoc work to do. The WAPI Position paper is 03/910. The WAPI status is 03/913. 03/842r2 is the LB Comment. The Public Comments doc is 03/932.

I was also following up with the no voters. Down to 3 no voters, down from 14. There are four core comments.

I would like to modify the agenda to discuss the LB No Comments then address the WAPI Position, and then move to LB comment processing. Is there any objection to modifying the addenda?

None

LB 62 No Vote Status Ken Clements:

- No SDL updates. Comment rejected

Simon Barber:

- TGi does not encrypt address 3 & address 4. Comment rejected - TGi did not perform authentication before association. Comment rejected

Russ Housley:

- Would like to have TGi’s key ID’s to be synchronized with EAP the working group’s Key ID’s. At the time we met with EAP WG, they did not have these defined. Comment rejected

Chair: We appear to be in good shape for ExComm.

WAPI Status – Dave Halasz – doc 03/913 Chair: We went there as part of the WiFi Alliance. We are best off letting an organization like WiFi handle this.

Comment: Does the Dec 1st deadline allow no encryption?

Chair: yes.



Chair: The Chinese were not aware of WPA or IEEE. They know of 802.11 via ISO.

Comment: I believe the Chinese know of 802.11i, but there has been some misunderstanding. The Chinese govt and military is not permitted to use 802.11b or 802.11g because of the security issues.

WAPI Position paper – doc 03/910r0 Comment: IEEE 802.11 is not an international standard. The ISO version of it is. IEEE is not an international standards body.

Comment: There was some discussion on not sending the re-affirmation to ISO.

Comment: the Chinese security solution is not public. How are we going to accommodate their requirements?

Motion by Dan Harkins Adopt position stated in submission 03/910r1 regarding WAPI.

Second: Andrew Khieu

Discussion:

None

Vote: 22-0-1 Passes

The chair will make a motion based on this at the mid-session Plenary tomorrow.

LB62 Comment Status Comment: You should be very careful about re-classifying a comment from technical to editorial. The commenter could get very upset based on this and use process to disrupt the progress.

Chair: we need to have the TG approve the comments that were re-classified or rejected.

Comment: I don’t see how you can change a person’s comment.

Comment: We are rejecting all editorial comments at this time because we do not want to touch the draft. We can’t if we want to go to Sponsor Ballot.

Comment: So what reason do we put in the spreadsheet for rejecting?

LB62 Technical Comment Resolution Review – doc 03/842 Comment 41

Commenter was happy with suggested resolution.

Comments 43, 44, 45, 46, 47, 48, 49, 50, 51, 55, 56, 57, 58, 60, 61, 63, 64, 65, 66, 67, 69, 70, 74, 75, 76, 77, 78,

Chair: any objection to recessing until 7:30pm?

None



<recessed at 5:47pm>

<resumed at 7:50pm>

The chair spoke with several chairs regarding the proper way to move forward to SB with remaining editorial comments. The suggestion is to reject the comments with the reason stated as “To be addressed in Sponsor Ballot”.

Comments 79, 80, 81, 82, 83, 84, 85, 86, 87, 89, 92, 93, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 110, 120, 122, 123, 226, 227, 228, 229, 230

Chair: The spreadsheet document (03/842) will be changed to rev 3 and put it on the server tonight. This will allow us to vote on the motion at the 1:30 session tomorrow afternoon.

Chair: the next item on the agenda is to prepare the package for SB. We can work on that in an ad-hoc fashion.

Chair: Is there any objection to proceeding with the position paper on public comments agenda item now instead of on Thursday?

None

Submission: Dave Nelson – doc 03/932r0 Dave: we reviewed this with Bob and he was happy with it. He also acknowledged that all the information highlighted in his paper was present in the draft.

Chair: Do we want to address the mis-representation by the press?

Dave: We thought it would be best to leave that response to the publicity committee. We simply supply the facts.

Motion by Dave Nelson Move that the Task Group adopt document 03/932r0 as a position statement with the following changes:

• The PMK in the title changed to PSK • Capitalize Key Management in the opening paragraph

Second: Tim Moore

Discussion:

These changes are reflected in 03/932r1.

Vote: 14-0-0 Passes

Motion by Dave Nelson Move to instruct the TGi chair to move on behalf of the Task Group that the 802.11 Working Group adopt document 03/932r1 as the Working Group’s position.

Second: Clint Chaplin



Discussion:

None

Vote: 14-0-0 Passes

Motion by Dave Nelson Move to instruct the TGi chair to move on behalf of the Task Group that the 802.11 Working Group adopt document 03/910r1 as the Working Group’s position.

Second: Clint Chaplin

Discussion:

None

Vote: 14-0-0 Passes

Chair: Next on the agenda are the Submission Presentations

Submission: Dave Halasz – doc 03/840 – OUI Usage Dave: Xerox owns the OUI 00:00:00. In Herndon we replaced the OUI’s with TBDs. The RAC Chair has indicated that TGi does not have the right to use 00:00:00 without Xerox’s permission. The suggestion is to use TBD’s until the draft is issued to Sponsor Ballot. A tutorial was also requested on the use of the OUI since this is a new use.

Comment: Can we go to SB with the TBDs in the draft?

Dave: yes. We will change this to an assigned value sometime in Sponsor Ballot

Chair: Is there any objection to us recessing until 1:30pm tomorrow?

None

Recessed at 9:10pm

Wednesday, November 12, 2003 1:30pm

LB62 Comment resolution discussion – doc 03/842r3 Chair: we need a reaffirmation vote to approve the comment responses to LB62, as well as to indicate that we wish to advance the draft to Sponsor Ballot



Motion to Approve Comments and Proceed with Sponsor Ballot Believing that comment responses in the document 03/842r3 and the IEEE 802.11i draft 7.0 demonstrate that the IEEE 802.11 WG Letter Ballot rules have reached an orderly endpoint,

Approve comment responses in document 03/842r3 and request the IEEE 802.11 WG Chair to move the IEEE 802.11i draft 7.0 to Sponsor Ballot at the Excom meeting on November 14th, 2003.

TGi Movers: Nancy Cam-Winget/Dorothy Stanley

Discussion:

None

TGi Vote: 26-0-0 Passes

Chair: The next agenda items are to prepare the SB package and to prepare for the next meeting.

Chair: I believe the SB is a 30 day ballot. I don’t see us having a meeting before the January interim, given the holidays.

Chair: I don’t see any major issues arising. If you know of any that may, let us know so that we can plan accordingly.

Chair: I plan to work on the SB package in ad-hoc this afternoon. At 5:30pm we can return and possibly vote on the SB motion.

Chair: Any objection to working in an ad-hoc fashion until 5:30pm?

None

<recessed at 2:00pm until 5:30pm>

<resumed at 5:38pm>

Chair: Dorothy and I worked on the ExComm SB Package document during the recess. I asked Stuart to review the document and he made some good suggestions. The Abstract needs to have more detail. I need to get input from more ExComm members and then make any appropriate changes. Given the four hour rule, we will not be able to vote on any changes today. The next time available to vote on this would be at tomorrow afternoon’s session.

Chair: Is there any objection to recessing until tomorrow at 1:30pm?

None

<recessed at 5:45pm>

Thursday, November 13, 2003 1:30pm

Chair: We left off with preparing the SB package motion for ExComm. Submission 03/956r4 is on the server. I appreciate the help I received from the TG and ExComm member.



Chair: Stuart stated that we do not need to make a motion in the Task Group to approve the ExComm “No Voter” package doc 03/956r4.

Chair: The next agenda item is the making of draft 7.0 available. Stuart indicated that if we make draft 7.0, then draft 3.0 must go away. So we probably do not want to do this.

Comment: Once you go to SB, draft 7.0 will automatically be made available to the public.

Chair: Does that mean that draft 3.0 will go away.

Comment: yes.

Comment: Someone may want to let the WiFi liaison know this.

Comment: Is there anything we can do to allow draft 3.0 remain available?

Chair: Stuart is the one to ask this question. A motion can be made to request this.

Motion by Dorothy Stanley Request the IEEE 802.11 Working Group chair to make the IEEE 802.11i draft 3.0 available for purchase even when future IEEE 802.11i drafts and IEEE 802.11 standards are available.

Second: Al Potter

Discussion:

Comment: Against - There is no basis for TGi to make this motion. The appropriate path is for the WiFi liaison to make this request.

Comment: For - TGi created draft 3.0 and it is being used by others. I think this is appropriate.

Comment: For - TGi originally asked for draft 3.0 be made available.

Comment: Against - Making draft 3.0 available was a bad idea in the first place. Subsequent drafts state older drafts are obsolete and incorrect.

Chair: The outcome of this will give direction to the WiFi alliance of our direction on these types of matters in the future.

Vote: 9-5-6 Passes

Discussion: Clint Chaplin – Maintaining 802.11 security after TGi completes. Clint: This topic came up in the WNG SC meeting this morning. A method to address this is to form a Standing Committee to advise the WG Chair and to act as consultants to the Task Groups. A Standing Committee cannot draft a standard.

Comment: how is a SC started?

Clint: A charter is drafted and a formal request is made to Stuart. I suspect this request will come from the WNG SC.

Comment: How do I participate in crafting the charter?

Chair: Follow the work in WNG.

Comment: Not all wireless groups use the same security method.

Clint: It has been discussed to form a Technical Advisory Group (TAG) for security for all of 802. It’s possible that the security SC may evolve into a TAG.




Chair: are there any other discussion topics or submissions?

None

Prepare for Next Meeting Chair: If the SB closed before the Jan mtg and did not reach 75% then another 30 day is required. If we did reach 75%, then we could do a 15day re-circ and have an ad-hoc mtg before the March meeting.

Motion by Clint Chaplin Move to empower TGi to hold meetings beginning in January 2004 as required to conduct business necessary to progress the Sponsor Ballot re-circulation process, including creating and issuing drafts for Sponsor Ballot re-circulation, conducting teleconferences, and handling other business necessary to progress through the IEEE standards process.

Second: Nancy Cam-Winget

Discussion:

None

Vote: 16-0-1 Passes

Chair: That concludes all the agenda items.

Chair: Are there any other items that anyone would like to discuss?

None

Chair: Is there any objection to adjourning?

None

Adjourned at 2:45pm

July 2003 doc.: IEEE 802.11-03/570r0


Meeting Minutes 802.11j November 2003

Date: November 10, 2003

Author: Stephen Pope Texas Instruments [email protected]

Chair calls the meeting to order at 7:30. There are no IP statements. Chair presents the agenda, which is adopted. Chair asks Inoue if there are any updates on Japanese regulatory issues; there are none. John Sadowsky -- Intel -- document 880 John describes that long multipath is most significant at long range, attenuated signals, BPSK or QPSK modulation. ISI results from multipath impulse response extending past the guard interval. Even under pessimistic assumptions, the SIR due to multipath is not large for BPSK and QPSK modes. End of technical presentations. Chair describes how there are two proposed texts on the server. Chair asks if there are objections to a straw poll. There are none. Chair conducts a straw poll between Proposal 2 -- double cyclic option; Proposal 4 -- no double cyclic option. for proposal 2 -- 5 against proposal 2 -- 3 for proposal 4 -- 7 against proposal 4 -- for any other proposals that may be made -- 0 against any other proposals that may be made -- 0 Move to adopt document "115 proposal 4" text resulting from above straw poll Moved -- Pope; seconded Peter Ecclesine. Question (Al Garret) -- can we be given till later this week to review the documents? Discussion; consensus is no because it has been on the server since September. Motion adopted 8-1-0. Motion (Pope seconded Ecclesine) that the chair move before the working that the adopted text be issued as a recirculation ballot.

802.11j Minutes for July 2003 page 1 S. Pope, Texas Instruments

July 2003 doc.: IEEE 802.11-03/570r0

802.11j Minutes for July 2003 page 2 S. Pope, Texas Instruments

Question (Myles) is a letter ballot more appropriate than a recirculation? Discussion; consensehus is no.

Motion passes 9-0-2. The text being adopted will be renamed TGJ draft 1.2.

Chair will update the comment resolution document (new document number 337r6) Motion to adjourn (Myles) adopted.



Tentative Minutes for the TGk November 2003 Session


Author: Paul Gray AirWave Wireless, Inc.

1700 El Camino Real Suite 500 San Mateo, CA 94025 Phone: 650-286-6107 Fax: 650-286-6101

e-Mail: [email protected]

Monday, November 10, 2003 4:00 PM – 6:00 PM

Chair: Richard Pain Secretary: Paul Gray 1) Chairperson called the meeting to order at 4:00 PM 2) Attendance 3) Agenda

a. Approve and Modified Agenda b. Review IEEE802 & 802.11 Policies and Rules IP Patent Policy Inappropriate Topics Documentation Voting Roberts Rules

4) Review Objectives a. Resolve Technical Issues b. Specification Submission c. Letter Ballot Work

5) Harry Requests a Motion to Nominate a new Security Motion: Nominate Paul Gray as New Sectary. Moved by Harry Worstell Second by Steve Pope For 19 Against 0 Abstain 0 Motion Passes @ 100%

6) Harry Worstell Presentation for New Study Group a. Auto Configuration of Access Ports b. Dynamic Control of Channel & Xmit Power c. Question of meeting contention – the meetings will be ad-hoc during breaks. d. Question of overlap with LWAPP – Nothing currently defined at layer 1 or 2 in LWAPP.

Minutes page 1 Paul Gray, AirWave


e. Comment that the statement of purpose should be refined. Harry answered question by stating that is why we form a study groups to build and refine the statement of purpose.

f. Comment that IETF is pushing LWAPP that controls the AP over the wire and this group will focus on controlling the stations over the air.

g. Question if control issues fall under the 802.11k charter. Answer no. h. Question about making a motion for formation of the group on Friday. Harry is

working with Richard on proposal. i. The new working group can’t interfere with 802.11k meetings/calls must be ad-

hoc. 7) Technical Presentation of Seattle Ad-hoc MIB Development - Tim Olson and J Kim -

- Documents – 876r0 a. 666R4 - Original MIB drafted by J Kim b. 809r0 - “bare bones” drafted from Ad hoc meeting in Seattle c. 809r1 – Fixes minor errors in 809r1 so it will compile d. 837r0 - Adds one variable to enable dynamic row management on the request

table. Clarifies texts in index usage for reports tables e. 837r3 modifications

Enables dynamic row management Removed max table size for report tables Site report configuration is now dynamic

f. Comment that 837r3 supersedes 837r0. 8 g. Comment on the status of the document. It is on the server and has been there for

the required time period. h. 809r, 837r0, and 837r3 are all candidates, but we will ask for a vote on 837r3 i. Comment that the proposal does not contain the required normative text. j. Question on using TUs. We have already voted TUs into the draft. k. TSF is included in 809r3. Either we put in TSF or totally rely on SysUptime. l. Questions on bins, are they fixed or variable. Noise Histogram has fixed number

of bins, but not Medium Sense Histogram. m. Tim proposes a straw poll of which document to submit. n. Question as to why Tim thinks 837r3 is cumbersome to implement. Tim

responded that the AP might not be running an SNMP agent. If you do not have an SNMP agent you can’t implement this functionality.

o. Comment on potential collisions from multiple network management systems. A response was given that the use of proxies should alleviate the collision problems.

p. Question about what is gained from dynamic tables. J believes that APs are running SNMP v2 today and they can take advantage of this functionality. It does not preclude an AP or station from not using SNMP and/or dynamic capabilities.

q. Comment that we need to ensure that we focus on clients as well as APs. r. Recess until 7:30.



Monday, November 21, 2003

7:30 PM – 9:30 PM

Attendance Richard Pain Paul Gray Tim Olson Mikael Hielm Shoji Sakurai Moo Ryong Jong Simon Black Hasse Sinivaara Gopal Krishnan Mike Lemieux Roger Durand Marc Miller Mike Wilhoyte Sudheer Matta Malik Audeh Leigh Chinitz Steve Jackson Zhun Zhong Massimiliano Maricini John Klien Lars Falk Balazs Czoma Fred Haisch Tomoko Adachi N.K. Shankaranarayanan Merwyn Andrade Patha Narsimhan David Bagby Joe Kwak Carl Andren Harry Wortsell 1) Chairperson called meeting to order at 7:31 PM. 2) Returned to approved agenda 3) Technical Presentation - Directed Probe Request Clarification – Marty Lefkowitz –

Documents 0834r1 and 833r0. a. 2003 specification has problems in Clause 7 and Clause 11 b. Clause 7.2.3 - Destination Address in unclear c. Clause 11 - mentions only SSID and active/passive scanning. d. Marty would like everyone to review normative text document 834r1 and the PPT 833 e. Comment - The SDL is very clear and takes precedence. Any SDL changes are outside

the scope of our PAR. f. Comment - Probe Request and Probe Response ambiguity could be address in 802.11m. g. Question - regarding IBSS and scanning. h. Comment - there needs to be an ACK in the Probe Response i. Marty will take comments and produce revised document.

4) Richard relinquishes the Chair to Roger Durand 5) Technical Presentation – Use Scenarios - Richard Pain – Document 633r0

a. Reviewed Station Measurements b. Comment - Inter Symbol Timer would be needed to determine location/vector c. Comment - Bit error rate should be changed to packet error rate. d. Richard asked everyone to look at the document and question if we have covered all of

the scenarios and measurements which we sat out to do. e. Discussion of Rogue detection in the enterprise (Client/Wired/AP). Client scanning by

itself is not a solution and should not be included in the draft. f. Comment - Client scanning is only a piece of the overall solution, but must be included. g. Comment – Need to include information to enhance roaming across subnets. h. Question on antenna diversity. The standard does not provide good measurements,

because we don’t know which antenna that packets are coming in on. i. Comment - Battery levels, signal quality, and antenna are missing.

6) Marty desires a letter of clarification on directed probe request which Stuart Kerry would present to TGm; dependent on the outcome of straw polls. a. Straw Poll #1:

Would you support clarification of directed probe request with individual MAC Address in Destination Address field in the ieee 802.11 standard?



Yes 16 No 0 Abstain 15

b. Straw Poll #2 Do you agree that directed probe request belongs in the 802.11 standard?


c. Straw Poll #3 Are directed probe requests with the individual MAC Address in Destination Address field allowed in the 1999 ieee 802.11 standard?


7) Marty requested a Motion to have S. Kerry ask TGM for clarification on directed probe requests Motion: To have S. Kerry ask TGm for clarification on whether directed probe requests with the individual MAC Address in Destination Address field are allowed?

Moved by Marty Lefkowitz

Second by Harry Wortsell

For 16 Against 0 Abstain 6 Motion Passes 100%

8) Recess until tomorrow 8:00 AM



Tuesday, November 11, 2003 8:00 AM – 10:00 AM

Attendance

Richard Pain Malik Audeh Simon Barber Paul Gray David Bagby Tim Olson Harry Worstell J Kim Jin Wong Gary Spiess Roger Durand Mikael Hielm David Famolari Alek Purkovie Anuj Purl Kazuyala Sakaba Ken Cook WC Tang Poomen A Garrett Tsuguhide Aoki Zhun Zhong Kumiko Jimi Harry Bims Niels Van Erven Joe Mueller Leo Mantebam Marc Miller Massimiliano Marcini John Klien John Klien Lars Falu Shoii Sakurai Pratik Mehta Carl Andren Matrin Lefkowitz Jan Krnys Sudheer Matta Michael Lemieux Patrick Worfolk Bobby Jose Bala Balachandar Dov Andelman Tomoko Adachi Chuck Bartel 1) Meeting was called to order by Roger Durand (current chairperson) at 8:01 AM 2) Richard Paine asked for a received approval to reclaim the chair 3) Motion to Amend Agenda

a. Add Simon Black to today’s Agenda b. Add vote on 837r3 to today’s Agenda c. Add Roger Durand to the weekly Agenda “Data Rate is Signal Quality” d. Add Sudheer to the weekly Agenda for technical presentation “Probe Response with

RCPI Element” e. Moved by Harry Wortsell f. Second by Paul Gray g. Motion to amend agenda passes unanimously

4) Technical Presentation -“PICs Proforma” – Simon Black – Documents 889r0 and 869 a. ISO-IEC 8802-11 Annex A b. PICs Status Symbols c. PICs Format d. Review of 869 normative text e. Parallel Measurements Discussion of Parallel Bit as being optional. Comment that we need parallel

measurements and this bit should not be optional. Optional gets votes and not specification. Parallel measurement is not very well defined in current draft.

f. Comment - mandatory means you have to respond with “no”. We are not able to define a scheduling mechanism.

g. Comment - We need to add the normative text and if it is optional the market will weed out the APs that don’t support measurements.

h. Comment - Protocol and functional requirements are different. i. Question - How are PICs approved? Experience from 802.11i & 802.11e is that is comes

in latter stages. It can and does change as the draft evolves. If we vote in the MIB, there must be accompanying PICs.

j. Comment that we can vote the entire document in and make revisions as we go along.



k. Question - why is there not a reference for RCPI for 802.11g? We need a mandatory measurement for measuring interference or noise, because currently both are optional.

l. Simon Black requests a straw poll Straw Poll: Would you support PICs as currently defined in 869r0? Yes 15 No 7 Abstain 16

m. Tim Olson requests an additional straw poll Straw Poll: Who would support PICs if parallel measurements and noise histogram were made mandatory? Yes 8 No 9 Abstain 21

5) Resumption of Technical Presentation – “Summary of Seattle MIB” – J Kim – Document 837r3 a. 809r1 – fixes various minor edits b. 837r0 – adds one variable to enable dynamic row management c. 837r3 – removed maximum size, made site report table dynamic d. Request for Motion

Motion: To instruct the editor to incorporate the MIB text 11-03-837r3 into the current TGk 0.8 draft. Moved by J Kim Second by Carl Andren Discussion on Motion to incorporate MIB text Comment against the motion, because there is not accompanying normative

text. Comment for the motion stating that the MIB can be changed as we progress;

we need a starting point. If needed we can make correlations to the primitive later.

Comment for the motion stating that this is the bare bones definitions as defined in the Seattle Ad hoc meeting. It is not cast in stone, the MIB can be altered.

Comment for the motion because this represents the best effort of two groups in Seattle and it is a good starting point.

Comment that MIB as defined is missing the conformance groups. Motion: Motion to Call the Question Moved by Harry Wortsell Second Tim Olson For 17 Against 1 Abstain 13 Motion Passes @ 94% 48 Attendees



Back to Main Motion To instruct the editor to incorporate the MIB text 11-03-837r3 into the current TGk 0.8 draft. For 18 Against 1 Abstain 13 Motion Passes @ 95% 48 Attendees

6) Technical Presentation - Add TBTT Offset Field – Marty Lefkowitz – Document 860r1 a. Reviewed example code b. Comment - that we could use the beacon report, the definition is outside the scope of this

document c. Comment - TBTT is a good concept, but it is difficult to implement. There would require

a great amount of resync. d. Response - It is optional and only mandatory to send the 2 bytes in the site report. e. Comment - There are other methods to perform passive scanning. f. Marty will take the comments are rework document.

7) Chairperson notes that Harry is crafting a paper “Need to manage ieee 802.11 devices” during the break outside the meeting room.

8) Recess until Wednesday morning at 8:00 AM



Wednesday, November 12, 2003 8:00 AM – 10:00 AM

Attendance

Richard Pain Paul Gray Bob Miller David Bagby Balazs Czoma Tomoko Adachi Yasuhiko Inoue Burak Baysal Joe Kwak Mike Lemieux Robert Kroniuger Patrick Mourot Zhun Zhong Bala Balachander Yu-ren Yang David Famolari Vivek Gubta Malik Audeh David Leach Tim Godfrey Pertti Alapuranen Noman Rangwala Hasse Sinivaara Massimiliano Marcini Marc Miller Steve Pope Lars Falk Shoji Sakurai Leo Manteban Steve Jackson Bruce Edwards Simon Black Tim Olson Mark Bilstud Mikael Hjelm Kue Wong Tom Kirmp Harry Worstell John Klien

1) Chairperson calls meeting to order at 8:00 AM 2) Review Agenda

a. Probe Response Adding Info Element (Matta) b. Vote on PICs (Black) c. TGh Amendments for TGk (Marion) 786r1 d. Extensions to SMT Notifications (Marion) 789r2 e. Directed Probe Request f. Border Flag (Black) g. Periodic Measurements (KWAK)

3) Technical Discussion – Summary from TGm meeting on Directed Probe – Marty Lefkowitz a. This not active scanning and there is nothing in the specification that states that

this can’t be done. b. TGm suggested an action frame as opposed to probe request. This way a legacy

station will just ignore an action frame. c. Marty is updating his document with the suggestion of TGm. d. Question - would the action frame be acknowledged? Yes it will be acknowledge.

We will define a null action frame. e. Question - what happens on retries. Create a new rule for fast scanning. f. TGm suggested creating a KTIM like a DTIM to allowing timing and preserve

power-saving. Comment that KTIM will need to synchronize to DTIM. 4) Simon Requested a Motion to add the PICs Proforma 869r0 to Draft

Motion: To instruct the editor to add the contents of submission 11-03-0869r0 into the next version of the IEEE802.11k draft. Moved by Simon Black Second by Simon Barber

Discussion on Motion Comment - the parallel Bit and Noise Measurement be mandatory.



Comment against the motion because voting now is inappropriate. There are 45 orthogonal lines. Every line item needs review.

Comment for the motion - The draft is early and needs additional improvement. PICs can be voted on at the very end when it meets our expectation.

Comment for the motion - We can vote PICs in now and make changes as we go. It does 2 things (a) gets people thinking about it and (b) there is a good level of agreement as witnessed by the straw poll.

For 16 Against 6 Abstain 7 Motion Fails @ 72%

5) Tim Olson Requests an Amendment to Motion Motion: To instruct the editor to add the contents of submission 11-03-0869r0 into the next version of the IEEE802.11k draft with the following two changes; item RRM 3.1 Parallel Measurements and RRM 7 Noise Histogram be changed to mandatory and RRM 7.1 and RRM 7.2 no longer needs to be conditional on RRM 7. Moved by Tim Olson Second by Simon Barber Discussion on Motion Joe Kwak requested a friendly amendment Tim declined the friendly amendment

For 13 Against 8 Abstain 6 Motion Fails @ 61%

6) Technical Presentation – TGh Amendments - Joe Kwak – Document 786r1 a. Document breaks TGh draft in 3 groups TPC relevant sections from P802.11h/D3.11 that are needed, but where no changes

are necessary shall be incorporated into the 11k draft “as is”. They are listed in the beginning of the text proposal.

TPC relevant sections from P802.11h/D3.11 that are needed, but where changes are necessary shall be incorporated into the 11k draft with the highlighted changes as shown in the text proposal.

Non relevant TPC sections. b. Comment - TPC is valuable in TGk, but do we need all of the TGh text. c. Response - Sections could be deleted or changed after inclusion into the draft. d. Joe requested a motion

Motion: To instruct the editor to add the contents of submission 11-03-0786r1 into the next version of the IEEE802.11k draft. Moved by Joe Kwak Second by Simon Barber For 9 Against 2 Abstain 15 Motion Passes 81%

7) Technical Presentation – Extensions to SMTnotification Table – Joe Kwak - Document 789r2



a. 4 non controversial extensions Add A STA associated (= “successfully”) Add A STA association attempt failed” Add A STA reassociated (= “successfully”) Add A STA reassociation attempt failed”

b. MIB Changes dot11AssociateStation - This attribute holds the MAC address from the

Address 1 field of the most recently transmitted association response frame. If no association response frame has been transmitted, the value of this attribute shall be 0

dot11AssociateID dot11AssociateFailStation dot11AssociateFailStatus

c. Question – How is client quality determined? This is not included in normative text, only in the document for future thought.

d. Comment - SMT notifications are not time critical and measured in seconds. e. Comment - Timing issue on re-association with IAPP. f. Comment - Notification should happen at the end of the association. g. Question - How practical are SNMP notifications, because these will become

traps in an AP. h. Comment - When designing MIBs one should expose the state of the machine for

reads and traps as well. i. Comment - 802.1x MIB is a good example of exposing the state of the machine. j. Joe Requested a Motion

Motion: To instruct the editor to add the contents of submission 11-03-0789r2 into the next version of the IEEE802.11k draft. Moved by Joe Kwak Second by Carl Andren Discussion on Motion Question - Are these amendments actually measurements. Comment for the motion - We already have notifications defined in the spec

For 11 Against 1 Abstain 22 Motion Passes 91%

8) Technical Presentation - Probe Response with RCPI Information Element – Sudheer Matta - Document 916r0 a. Case #1 - AP and station hear each other good. Depicted here is only one possible

scenario b. Case #2 - AP hears the station, but station barely receives AP Signal c. Case #3 - Station receives AP signals good, but the AP barely hears the station d. Introduce a new information element or use an existing information element to

convey to the station, in the probe response the RCPI of the probe request, which prompted this response.

e. Stations are hanging on to an AP way to long. f. Question - Is probe response is going to be expensive to provide RCPI



g. Comment - Include a selection antenna selection, because scenarios can change for each antenna.

h. Comment – Proposal should not determine what the stations do with these measurements. i. Comment - Could be a misleading indicator because the client responds to probes at max

power and the drops down during association. j. Comment - This proposal would not keep stations from hanging on to the AP. Some

clients don’t even probe. Microsoft is always probing every minute. Question is every minute enough?

k. Sudheer requests a Straw Poll Straw Poll Voting Members Only: Would you support RCPI measurements of the probe request in probe responses? Yes 21 No 0 Abstain 6

9) Marty Requested a motion to have Stuart Kerry ask TGM for clarification on directed probe requests Motion: To have Stuart Kerry ask TGm for clarification on whether directed probe requests with the individual MAC Address in Destination Address field are allowed?

Moved by Marty

Second by Harry

For 16 Against 0 Abstain 6 Motion Passes @ 100%

10) Meeting in recess until 1:30



Wednesday, November 12, 2003 1:30 PM – 3:30 PM

Attendance

Paul Gray Richard Pain Chih Tsien Ryoko Matsuo Tomoko Adachi Carl Andren David Bagby Mikael Hielm Zhun Zong Jin Kue Wong John Klien Ian Sherlock Patrick Worfolk Bruce Edwards Matthew fischeer Hasse Sinivaara Marc Miller Lars Falk Massimiliano Marcini Simon Black Leo Manteban Steve Pope Tim Olson Joe Kwak Marty Lefkowitz Malik Audeh

1) Chairperson calls meeting to order at 1:30. 2) Review Agenda 3) Technical Presentation – WiFi Interoperability – Richard Pain – Document 852r0

a. Question - Are ready to go to WiFi. How have others TGs done it in the past? b. Comment - We are the experts and we should produce recommended

interoperability test for WiFi. c. Comment – We should not approach WiFi now or ever. They have done a very

poor job in the past of implementing recommendations (example WPA). d. Comment - We should coordinate with WPP (Wireless Performance and

Prediction) as well. WPP was approved as study group this week. e. Comment - WPP is dedicated to testing and should not overlap our group. f. Richard made a suggestion that we meet with WNG mid morning tomorrow.

4) Technical Presentation – Probe Request with No Response Option – Marty Lefkowitz – Document 857r2 a. Add new scan type “Fast Scan” b. Clause 10 required change - parameter must contain an individual address, not a

broadcast address c. Clause 11.1.3 – incorporate Fast Scan mode and specify null action frame d. 11.3.2.2 – 3 methods for exit (a) success, (b) timeout can’t access media, and (c)

timeout no ACK e. Comment - ScanConfirm modifies BSSDescription with accompanying normative

text. f. Comment - Section 7.4.2 is not complete. g. Question – Is this RRM. h. Response - Gaining power measurements will keep the client from always

scanning. i. Question - Do we really want to use an Action Frame for this? j. Question - Why we didn’t extend one of our existing reports to incorporate this

mechanism. k. Response - This was defined as a real-time measurement for clients. l. Comment - We should not define a frame as “Null Action. We should change the

name to RadioActionPing. m. Discussion - Action frames are not currently classified. Can an AP request a

measurement from a STA when the STA is not associated with it? Action frames are classified in TGe. TGe is not approved.

n. Question - Where you would use this feature.



o. Response - If you are VoIP phone and trying to access the environment and maintain your call quality you will need to do fast background scanning.

p. Discussion - we have RTS frames defined that will give a CTS reply. Why add another frame. What do you do with the NAV? RTS followed by CTS without a data frame it is not a valid sequence. If we decide to use RTS we will need to define proper data sequence. Advantages of changing RTS/CTS text are (1) it will be much smaller change in the draft and (2) most APs will not require a data frame in the sequence.

q. Comment - Action frames could get retried up to 7 times. r. Response - This text specifies not to retry. s. Comment – Change ACK to include (Power Level and How I received the Ping). t. Question – I don’t understand text “the STA may observe EIFS rules” and “normal retry

rules do no apply”. u. Comment - Need to interleave Fast Scan and Active Scan. We have the site report which

gives you targets of interest. v. Marty will address the comments and try to bring it to a vote on Thursday.

5) Technical Presentation – Frame Request Periodic Measurements – Joe Kwak – Document 896r0 a. Our current framework is request and reply only. b. Adding Transmitter Address – allows filtering to a single address. If you want all then

set the address to the broadcast address. If you are interested in the link between you and a particular transmitter. Transmitter Address is the only new element. The other elements are already defined in Beacon Request.

c. Adding dot11RRMRqstFrameReportCondition d. Question – How to cancel periodic measurement when I roam to another AP? e. Response - We addressed in the BeaconRequest. f. Comment - This defines the AP, but what about a client. We should add some text

regarding disassociation to stop taking periodic measurements. g. Question – How to set multiple periodic measurements on a single station. The station

should act on latest request and makes it the highest priority. h. Comment - The AP will have to track state on previously requested measurements. We

have protocol limitation that we will need to address for periodic measurements. Reference section 11 for more details.

i. Question - If a station receives a unicast request and then receives a broadcast request, which take precedence.

j. Response - Priority for precedence of responding to a request is Unicasts, Multicast, and Broadcast.

k. Comment - Do we need to support multiple upper layer applications or application meaning a single entity? Do we have the obligation?

l. How do we authenticate these requests? m. Response - Management frames have no security. It is an open question. John is coming

tomorrow to talk about security of action/management frames. n. Joe will rework the document for vote later in the session.

6) Chair asked Simon Black to prepare a presentation of deficiencies. 7) Meeting in recess until 4:00 PM.



Wednesday, November 12, 2003 4:00 PM – 6:00 PM

Attendance Paul Gray Tim Olson Chih Tsien Bruce Lung Ryoko Matsuo Tomoko Adachi Carl Andren John Klein Shoji Sakurai Bob Miller Harrry Worstell Michael Su Zhun Zhong Mikael Hielm Stefan Rommer Niek Van Erven Jin Kue Wongg Partha Narasimhan Peter Ecclesine Patrick Worfolk Yaron Dycian Bruce Edwards Matthew Fischer D.J. Shyy Vivek Gupta Anuj Puri Mike Lemieux David J. Donovan David Leach Bob Kroninger Malik Audeh Marty Lefkowitz Areg Alimian Steve Commer Roger Durand Sudheer Matta Hasse Sinivaara Hidenori Aoki Farooq Bari Burak Baysal Marc Miller Lars Falk Mike Moreton Jon Edney Fred Haisch Massimiliano Marcini Simon Black Leo Mateban Amjad Soomro Steve Pope David Bagby Joe Kwak Richard Pain

1) Chairperson calls meeting to order at 4:01 PM 2) Review Agenda 3) Technical Presentation – Border Flag in IEEE802.11k Site Reporting – Simon Black

– Document 947r0, 944r0 a. Based on previous proposals 11-03-338r0, STA Statistics & RRM Information Distribution 11-03-0544r0, Revised BSS Neighbourhood Distribution

b. The principle of the border bit is to identify in Site Reports the BSSs close to the ‘exit points’ of ESS coverage such that: A strong hint for dual-mode WLAN-cellular terminals that a hand-off to a

network beyond the WLAN may be required shortly Preparatory activities may take place while the WLAN signal quality is

acceptable Unnecessary inter-network transitions which may involve significant

signalling and higher probability of service disruption are avoided c. Typically the border flag would be set by a system administrator and the

normative text proposal assumes that control of this is made available via the TGk MIB.

d. Changes to MIB Remove - dot11RRMSiteReportESSBorder TruthValue Replace - dot11RRMSiteReportESSMatch TruthValue Replace - dot11RRMSiteReportCapMatch TruthValue Replace - dot11RRMSiteReportSuppRatesMatch TruthValue

e. Question - If this flag would clash with what other Task Groups are doing. There is 802.11 study group looking at roaming between WLAN and WAN?

f. Question - Should this be included in the site report?



g. Comment – Hopefully network providers won’t use to hoard stations in multi-network environments.

h. Comment - This is simple mechanism that provides useful information without specifying what is done with the bit.

i. Comment - This bit is defined as a binary flag what does zero mean. We need to be clear in the text.

j. Comment - This could serve as IDS in some scenarios. k. Question - What would happen if there are multiple provides without single

administrative Domain. l. Comment - This is an ESS boarder. m. Comment – It seems that the boarder flag will always be set. n. Comment - Since we are not defining the client functionality, then it is hard to engineer

what happens when the bit is set. There is too much ambiguity to be useful. o. Comment - The site report supports multiple ESSs. p. Comment - The Boarder Bit is only hint and not the entire algorithm. q. Simon will take comment and amend the document for a later vote.

4) Tim Olson Requested a Straw Poll Straw Poll: Does the group feel it is acceptable to conclude TGk without having a mandatory Radio Measurement? Request for friendly amendment to change “Noise” to “Interference” Tim accepts friendly amendment

Does the group feel it is acceptable to conclude TGk without having a mandatory Interference Measurement?


5) Technical Presentation - Channel Information in Probe Request - Leo Monteban – Document 952r0 a. Include the DS Parameter Set information element in the probe-request and extend the

rules for reacting to a probe-request to include a check on/off channel reception. b. Question - Is TGk is the correct task group to fix it. c. Question - Can this functionality be disabled, because in some instances it would be

valuable to still have off channel reception? d. Response - The current document does not have an on/off option, but it could be added. e. Question - Regarding backward capability. Legacy stations should ignore it. f. Comment - This is not a new element, so legacy stations would not ignore it and probably

would not know how to process it. g. Question - Should this go into Fast Roaming and Fast Handoff group. h. Comment Fasting Roaming will not address this. i. Leo Requests Two Straw Polls

Straw Poll: Should we consider Channel Information in Probe Request in TGk? Yes 35 No 0 Abstain 5 Straw Poll:



Should we consider Channel Information in Probe Request in TGk as a unique and new element?


j. Comment – Should tie this submission to only TGk capable devices. If we don’t we can make it backward compatible to AP via firmware upgrade.

k. Leo Requests Motion Motion: Move to instruct the editor to add the normative text in submission 11-03-0952r0 into the next version of the IEEE802.11k. Moved by Leo Monteban Second by Sudheer Matta Motion to Amend: To amend the current motion to read “To instruct the editor to add the normative text in submission 11-03-0952r0 into the next version of the IEEE802.11k draft striking the RRM bit requirement text from document 11-03-0952r0”. Moved by Marty Lefkowitz Second by Tim Olson For 16 Against 3 For 4 Motion Passes @ 84% Motion to Postpone: Move to postpone the original motion until tomorrow morning at 8:00 AM Moved by Harry Worstell Second by Simon Black

Motion Passes Unanimously

l. Meeting in recess until 8:00 AM tomorrow.



Thursday, November 13, 2003 8:00 AM – 10:00 AM

Attendance Paul Gray Simon Black Jon Edney David Bagby Leo Nonteban Massimiliano Marcini Lars Falk Marc Miller Hase Sinivaara Dave Leach Jin Kue Wong John Klien Malek Audeh Sudheer Matta Gopal Krishnan Mikael Hielm Fred Hzisch Andrew Khieu Bala Balachander Vivek Gupta Steve Pope Marty Lefkowitz Tim Olson

1) Chair calls meeting to order at 8:00 AM 2) Review Agenda 3) Resumption of motion to instruct the editor to add the normative text in submission 11-03-

0952r0 into the next version of the IEEE802.11k. a. Request a Motion

Motion: To postpone the motion on the channel inclusion in probe request to 1:30.

Moved by Simon Black Second by Dave Bagby

For 16 Against 0 Abstain 1 Motion Passes Unanimously

4) Technical Presentation – Protection Action Frames – Jon Edny – Document 854r0 a. Straw poll in TGi was passed overwhelmingly. b. No security protection for action frames (integrity, privacy). c. External monitoring could reveal information such as the location of stations in a

building. d. Suggested Approaches Use data frame with special Ethertype Protect all actions frames using key derived from group key Protect unicast with pair wise key and multicast with group key

e. Question - What information is exposed in action frames prior to association? Is there additional information exposed in action frames while a stations is associating.

f. Comment – This is not applicable to Hot Spots. 802.11i APs are unsecured by default. g. Comment - This presentation is an assertion that TGi can’t fix the problem. We should

push this back to TGi. h. Comment - There is a difference between class 1 and class 3 frames. We might be able

to ignore particular frame classifications. i. Comment - APs now have multiple SSIDs and keys per ESS might be a drawback. j. Response - There is a price for security. k. Comment - TGi will not address the action frame security issue. l. Jon will continue to refine the document.

5) Technical Presentation - Reassociation Counter – Lars Falk – Document 737r0 a. Lars Requests a Motion

Motion:



Move to instruct the editor to incorporate the Reassociation Counter proposal of 03/737r0 into the TGk draft where appropriate and, if necessary, modify the text to be consistent with the draft.

Discussion on Motion Comment - Counter32 is a circular counter which resets to zero and that is not

what you want. Questions - Is this a counter for successful reassociations or unsuccessful

reassociations. Response - Only for successful, but unsuccessful is a good idea. Comment against motion - If you are using TUs that would require that the

AP update the MIB every TU. Period counter is not very well defined. Comment against – This looks to be a feature creep and the number of

questions validates this assertion. Comment against - This does require sending messages like other counters

defined in 802.11k. Comment – we could convert it to a notification like the SMT notifications

that we voted in yesterday. Moved by Lars Falk Second by

b. Lars Withdraws the motion c. Meeting in recess until 10:30 AM.




1) Chairperson calls meeting to order at 10:31 AM 2) Meeting in recess until 11:15, because WGN working is running late.




Attendance

1) Chairperson calls meeting to order at 11:15 AM 2) Technical Presentation – Managed IEEE 802.11 Devices – Harry Worstell -

Document 950r1 a. Review History of WLANs b. Comment - Simon Black was present in the discussion and asked that his name be

stricken from the document. His participation in the discussion is in no way an endorsement by him or his company Nokia. Simon requested this be noted in the minutes.

c. Comment - WGN has been discussing forming a study group focusing on inter workings between WLAN and cellular. There might be a potential overlap.

d. Comment for - Customers are asking for these services today. We need to integrate WLANs into the tiered networks of large telecom.

e. Question - Are there other alternatives to forming a study group? f. Response - This is the normal process of forming a PAR within 802.11 and IEEE. g. Question – about overlap with other groups and what is trying to be defined. h. Response - This group is focused on layer 1 and 2. i. Comment for – Layer 2 MLME is the entity that provides conformance to

regulations. j. Comment for – This work will make .11 networks efficient and easier to control. k. Harry requests a Straw Poll

Straw Poll: Would you support forming a study group to evaluate the need to enable external network management entities extend the managed services of the wired networks through to the wireless devices attached to those networks, which is a logical extension of the measurement work now underway in TGk? Yes 57 No 1 Abstain 9

3) WNG Discussion a. Comment - Document are posted on the server, please review b. Comment – WPP first created taxonomy and built measurements upon this

taxonomy. c. TGk is proposing new protocols that are live on air. WPP is proposing ways to

standardize test matrices used to evaluate products. d. Comment - WWP does not know what is required from TGk and we should

discuss the overlaps possibilities. e. Meeting in recess until 1:30 PM.



Thursday, November 13, 2003 1:30 PM – 3:30 PM

Attendance

1) Chairperson calls meeting to order at 1:30 PM 2) Proposed Agenda for Thursday

a. Request a Motion Motion: To amend agenda by moving Adrian’s Presentation to later this afternoon. Moved by Harry Worstell Second by J Kim Motion Passes Unanimously

3) Resumption of Channel Information in Probe Request motion a. Motion on the floor as of postponement on Wednesday.

Motion to Amend: To amend the current motion to read “To instruct the editor to add the normative text in submission 11-03-0952r0 into the next version of the IEEE802.11k draft striking the RRM bit requirement text from document 11-03-0952r0”. Moved by Marty Lefkowitz Second by Tim Olson For 16 Against 3 Abstain 4 Motion Passes @ 84%

b. Motion to Amend the Amended Motion Motion: To amend the current motion to read to instruct the editor to add the normative text in submission 11-03-0952r1 into the next version of the IEEE802.11k draft. Moved Simon Black Second Dave Bagby For 24 Against 0 Abstain 4 Motion Passes @ 100%

c. Amended Motion Motion: Move to instruct the editor to add the normative text in submission 11-03-0952r1 into the next version of the IEEE802.11k draft Moved Leo Monteban Second Sudheer Matta For 27 Against 0 Abstain 1 Motion Passes @ 100%



4) Technical Presentation – Quality Measurement Discussions – Joe Kwak Document 970r0 a. Introduce Straw Polls for voting in a later session.

5) Technical Presentation – Data Rate is Signal Quality - Roger Durand – Document 866r0 a. It is simple and easy to implement b. A means to better determine the need to initiate a possible roaming event c. A means to infer (Excess Interference, High Multipart, Excessive Collisions, Poor

Radio Performance d. Two valid Indexes – PSNI, EVM, but not consensus e. Question – which data rate would be utilizing. Transmitter data rate for the link. f. Question – would this approach have the ability to allow a client to determine

which APs to roam to. g. Question – Is this the last transmitted data rate or max data. h. Response - Average of last number of packets. i. Comment – There is not a single data rate, because packets can be sent out at

different data rates j. Comment – when polling APs that you are not actually associated it – you don’t

have a data rate. k. Comment – Gathering data on an adjacent AP; a station still monitors traffic on

other APs and CRC on the packets. The STA would know the AP’s quality. l. Comment – it is not only what you receive, but what you transmit as well. m. Question – what if you have a 2 megabit only phone how would judge quality. n. Comment – you also have QoS issues where the AP is only transmitting at a

low/high data rate. o. Roger Requests a Straw Poll

To endorse the value of using data rates as a means to discern signal quality? Yes 14 No 11 Abstain 16

6) Technical Presentation - An Effective Signal Quality Measure Using OFDM Pilot Symbols - Brian Johnson – Document 844r1 a. Establish evaluation method for signal quality measure effectiveness. b. Define a signal quality measure using OFDM pilot symbols. c. Analyze effectiveness of proposed signal quality measure. d. Describe scenarios for use of signal quality measurements. e. Comment – the power amplifier could be creating an artificial floor. f. Comment – there will be variation at low constellation. g. Comment – these measurements are not catching all variables. Potentially add the

link margin. h. Comment – there could be misconceptions about EVM. i. Comment – this is an improvement over prior proposals. By using Pilots you

decreasing the processing requirements. j. Question – how can you make this measurement work for non OFDM devices? k. Comment – we need to get agreement on a measurement. l. Comment – This does not fix collision or interference issues, but it is something

we need. Suggest using a training packet m. Comment – the silicon vendors want 11k standard soon so they can re-spin their

silicon. 7) Meeting in recess until 4:00 PM




Attendance

1) Chairperson calls meeting to order at 4:00 PM 2) Review Agenda

a. Motion: To amend agenda moving move Sudheer’s Presentation up

Moved Harry Worstell Second Malek Audeh Motion passes unanimously

3) Technical Presentation – RCPI information element in the probe - Sudheer Matta- Document 961r3 a. For legacy stations will pass RCPIMeasurement field of 255 b. Comment – do we need to have text regarding non 11k station? c. Comment – Clause 10 only defines a single confirm. You need to define a confirmation

per individual AP. d. Comment – Element ID 41 and 42 are already defined by another Task Group. e. Comment - Draft standards can define Element IDs as TBD. f. Comment – Define a new set “measurement set” g. Sudheer will rework document and submit for a potential vote at 9:30

4) Technical Presentation – PSNI: New PHY Measurement for Link Quality – Joe Kwak - Document 899r0 a. RSSI is defined at antenna input connector but is not fully specified: no unit definitions,

no performance requirements (accuracy, testability). b. Comment – concerned about testing environment a sample method not truly

representative of the real world. c. Question – Is this an improvement over what we have today and is it worth the work to

implement. d. Comment – could not find document 316 on the server. It not accessible from the IEEE

web interface, because it is too old. e. Comment – a thousand packets is overkill in normative specification. f. Comment – With measurements taken at 50 nanoseconds would you have to increase

number of packets with the addition of interference. g. Comment – we should cut down the number of packets and increase the inaccuracy, so

we have a more usable measurement. h. Comment – 1000 packets may be too many, we can change the normative text to match

real world. i. Comment - Putting into the draft allows more people to see the text and recommend

changes. j. Comment – 100 packets correlates to 1000 in accuracy, we should change to 100.

5) Joe Kwak request vote on his previous Straw Polls Straw Poll (Joe Kwak #1): Does TGk need a QUANTITATIVE link quality indicator?




Straw Poll (Joe Kwak #2): Is a “black box” specification preferred over a detailed functional, “how-to” specification which mandates a certain implementation?


Straw Poll (Joe Kwak #3): If TGk decides to specify HOW to implement a quality indicator, is EVM the best basis for an implementation spec? Yes 3 No 5 Abstain 29 Straw Poll (Joe Kwak #4): Is a tabular performance specification (specifying indicator performance at limited number of points) adequate? Yes 13 No 0 Abstain 21 Straw Poll (Joe Kwak #5): Should the link quality indicator accurately reflect output quality in both AWGN and fading conditions (using variance adjustment or equivalent)? Yes 13 No 1 Abstain 23 Straw Poll (Joe Kwak #6): Would members support a link quality measurement based on OFDM pilot tones for OFDM based PHYs and some link quality measurement for 802.11b? Yes 8 No 3 Abstain 22 Straw Poll (Joe Kwak #7): Would members support, as mandatory, any signal quality spec that will likely require a silicon revision to claim 11k compliance? Yes 1 No 26 Abstain 7

6) Dave Bagby call orders of the day 7) Meeting in recess until 7:30 PM.




Attendance

1) Call to order 2) Proposed Agenda for Thursday

a. Request a Motion to accept the amended agenda b. Motion passes

3) Technical Presentation – PICs Proforma – Simon Black – Document 8689r1 a. Simon Request a Motion

Motion: To instruct the editor to add the contents of submission 11-03-0869r1 into the next version of the IEEE802.11k draft. Moved by Simon Black Second by Tim Olson For 21 Against 0 Abstain 1

Motion Passes @ 100%

4) Technical Presentation – Director Probe Request - Marty Lefkowitz - Documents 857r2 a. Changes in Clause 10 Scan Types – Passive, Active, and Fast Changes to the ResultCode – added ACK_TIMEOUT and CHANNEL_TIMEOUT

b. Changes in Clause 11 During a FASTSCAN you will get a response in MinChannelTime

c. Comment – This is a good measurement for scanning and we should expose this to SME and define it in a MIB. Implement it as measurement request and change the name to something different.

d. Response – It is a real time measure and sending it to the upper layers may diminish its value.

e. Comment – Internally it can be used real time and externally you can the MLME. f. Comment – A NMS can’t utilize it unless it is defined in the MIB. g. Comment – Our future direction is to include any additions into the MIB. h. Comment – This has merit because it is a valuable scanning mechanism which is faster

than the BeaconReport. i. Comment – Change the name of Null Action Frame to Radio Ping. j. Question – Does IBSS in address 1 work? Active scanning will work because address 1

is a broadcast address. k. Question – Can we deal with IBSS in address 1 when the MIB modifications are made? l. Comment – We need to correct IBSS issues as we see them, but there are others already

in the draft. We should go back and scrub the entire document. m. Comment – There is no way to know from the confirmation that it was a fast scan. The

device will have to keep state on the request. n. Marty Requests a Motion

Motion:




To instruct the editor to add the contents of submission 11-03-0857r2 into the next version of the IEEE802.11k draft. Moved by Marty Lefkowitz Second by Sudheer Matta For 21 Against 10 Abstain 6 Motion Fails

o. Motion to amend the Agenda Motion:

To move Roger Durand’s Presentation to the end of Agenda Moved by Roger Durand Second by David Bagby Motion Passes Unanimously

5) Joe Kwak Request Completion of Straw Polls Straw Poll (Joe Kwak #8): Would members support, as optional, a signal quality spec that will likely require a silicon revision to claim 11k compliance? Yes 7 No 11 Abstain 15 Straw Poll (Joe Kwak #9): Would members support reserving and defining the required bit fields for a future signal quality measurement that could be defined as mandatory in TGn? Yes 3 No 19 Abstain 12

6) To amend the Agenda to allow the Chair to best conduct business Motion: To allow Chair to modify Agenda as need to conduct business.

Moved by David Bagby Second by Simon Black

Motion Passes Unanimously

7) Richard Requests a Straw Poll Straw Poll Is TGk ready to go to working group letter ballot? Unanimously disapproved

a. Comment – Conduct internal TGk letter ballot.

8) Richard Request a Motion to adjourn Motion: To adjourn - Moved by Roger Durand - Second by Harry Worstell - Motion Passes Unanimously

9) Meeting is adjourn

November 2003

Bob O'Hara, Airespace, Inc.Slide 1

doc.: IEEE 802.11-03/874r0

Report and Minutes

802.11m ReportNovember 2003

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Goals for November 2003

• Interpretation requests– Draft responses to requests and forward to WG

• Develop updates to standard– Begin work from spreadsheet of work items– Volunteers needed

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Submissions?

• Are there any submissions?• Are there any new interpretation requests?

– Some noises from TGk about a request to interpret Probe Request operation

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Proposed Agenda

• Review IEEE Patent Policy• Review interpretation request procedure• New business

– Review interpretation requests received– Draft responses to interpretation requests– Forward to full WG– Begin work on updates to standard

• Adjourn

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Motion to adopt Agenda

• Moved: to adopt the agenda• Mover: Leo Monteban/Joe Kwak• Passes: 5/0/0

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

6. PatentsIEEE 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. 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.

IEEE-SA Standards Board Bylaws on Patents in Standards

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

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 Administratorat [email protected]

Approved by IEEE-SA Standards Board – December 2002

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Interpretation Procedure

• http://standards.ieee.org/reading/ieee/interp/• Send email to Linda Gargiulo

([email protected])• IEEE forwards requests to the WG• WG responds

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Interpretation Requests

• Key Mapping Key Usage• Probe Request Usage• Probe Response Usage

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Interpretation RequestWhat are Key Mapping Keys intended for?

– Five scenarios were described.

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Interpretation Response• The standard describes scenarios 1, 2, 4, and 5. These are all the same

scenario, where the AP is performing the distribution service for a frame received from a mobile STA associated with it. This case is unambiguously described in the pseudo code of clause 8.3.2 for both transmission and reception. That is, key mappings are for use between a single RA/TA pair only. Scenario 3 is forbidden by not allowing a proper frame to be constructed with such addresses in clause 7.1, Table 2 and 7.3, Table 4.

• The standard is unambiguously describes the use of the same key from the dot11WEPKeyMappingsTable for both transmission and receptionin the pseudo code of clause 8.3.2. There is nothing in the dot11WEPKeyMappingsTable in the MIB to allow differentiation of a transmission key from a reception key when key mapping is being used.

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Motion to adopt 03-875

• Moved: That document 03-875r0 be adopted as the response to the interpretation request regarding key mapping key usage.

• Moved: Terry Cole• Seconded: Andrew Myles• Vote: 5/0/2

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Motion to forward to WG

• Motion: to request the working group to accept and forward the interpretation response contained in document 03-875r0 to Linda Gargiulo at the IEEE office as the official response of the 802.11 working group.

• Moved: Darwin Engwer• Seconded: Tim Wong• Vote: 5/0/1

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Additional Work

• Individuals assumed responsibility to address items from document 03/619

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Output Documents

• 874r0: This report• 875r0: Interpretation Response 1-11/03• 619r1: Status of Work Items (unchanged)

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Adjourn

• Motion to adjourn• Moved: Andrew Myles• Seconded: Simon Black• Passes: 5/0/1• Meeting adjourned at 5:29pm

November 2003


doc.: IEEE 802.11-03/874r0

Report and Minutes

Attendance

• Darwin Engwer• Joe Kwok• Terry Cole• Leo Monteban• Mikael Hjelm• Tim Wong• Andrew Myles• Richard Paine

November 2003 doc.: IEEE802.11-03/0831-00


Minutes of High Throughput Task Group Meetings


Author: Garth Hillman Advanced Micro Devices 5204 East Ben White Blvd, Austin, TX 78741 Mail Stop - PCS4 Phone: (512) 602-7869 Fax: (512) 602-5051 e-Mail: [email protected]

Abstract Minutes of the High Throughput Task Group meetings held during the IEEE 802.11/15 Interim meeting in Albuquerque from November 10 through 14, 2003. Executive Summary (see closing report doc. 11-03-962r0):

2. Approved document 11-03-940r1 as the official 802.11n Channel Models –Channel Model Special Committee has been dissolved

3. Elected Adrian Stephens ([email protected]) as the Chairperson of the Functional Requirements and Comparison Criteria (FRCC) Special Committee

4. •Current draft of Usage Models is in document 11-03-802r6 5. Motion to adopt Usage Models in doc. 11-03-813r6 was tabled 6. Motion to adopt Functional Requirements in doc. 11-03-813r8 was tabled

Detailed minutes follow: Monday November 10; 4:00 –6:00 PM [~145 attendees] :

1. Meeting was called to order by Task Group chairperson Matthew Shoemake at 4:08 PM 2. New participants in .11n ~40 3. Chair reviewed history and overview of process and objectives for the week for 802.11n [ doc. (03-872r1)]

Minutes of TGn page 1 Garth Hillman, AMD


4. Original schedule in [doc. 1(1-03/348)] 5. Objectives for the week are to adopt:

a. Functional Requirements (FR) Special Committee Output document – Adrian Stephens b. Channel Models (CM) Special Committee Output document – Venko Erceg is not here; Colin Lanzl will handle

Venko’s duties this week c. Selection Procedure – doc. 03-0665 r3 d. Call for Proposal time permitting e. Functional Requirements and Comparison Criteria time permitting f. Hold elections for secretary – 8 AM Wednesday morning

6. Election of Officers was a hot topic at CAC meeting a. Directed that .11n delay election of vice-chair and editor until special committees are concluded

7. Tentative Agenda doc 11-03/788r4 8. Motion to adopt agenda by Colin Lanzl and seconded by Adrian Stephens 9. Motion to Amend by George Vlantis and seconded by John Kowalski:

a. Include issuing a call for Submissions b. Passed unanimously

10. Main motion to accept the agenda as amended passed (48-0-5) 11. Motion to approve minutes of September meeting (doc 756r0) by Colin Lanzl was seconded by John Kowalski and passed

unanimously 12. Call for submissions 13. Submissions are listed in [doc. (11-03 – 0891r3)] 14. Channel Model report – Colin Lanzl [doc. (11-03-848r2)] included the following topics:

a. K Factors b. Doppler Power Spectral Modelling c. Stadium Models d. Old Channel Model doc. (11-03-161r2) becomes (11-03-0871r0)

15. FR&CC Report - Adrian Stephens [doc 11-03-0855r0] included reference to the following docs: a. 11-03-813 – Functional Requirements b. 11-03-814 - Comparison Criteria c. 11-03-815 – Cumulative meeting minutes d. 11-03-802 – Usage model doc

16. Draft Call for Proposals; John Terry; [doc. (11-03-0858r0)] included the following paragraphs for discussion: a. Formal Call b. Deadlines for Partial or Complete Proposals c. Submissions d. Functional Requirement (FR) [doc (11-03-813)]



e. Comparison Criteria (CC) [doc (11-03-814)] i. John presented [doc (11-03-0859r0)] timelines for three scenarios and noted that our selection criteria requires

that the proposals be on the server for at least 30 days prior to presentation: 1. Scenario #1 – Call issued at the close of this meeting and Proposals heard at March meeting; this would

offer ~12 weeks between the call and putting the proposals on the server. 2. Scenario #2 – Call issued at the close of January meeting and Proposals heard at March meeting; this

would offer ~4 weeks between the call and putting the proposals on the server. 3. Scenario #3 – Call issued at the close of March meeting and Proposals heard at May meeting; this would

offer ~ 2 weeks between the call and putting the proposals on the server. f. Discussion

i. 30 day requirement for proposals to be on server ii. Notification of intent from Proposers

iii. Issue is how long does the membership think it needs for preparing proposals and issuing intent after FR&CC and CM are completed?

iv. Purpose of Call for Intent is for the Chair to schedule time for the presenters v. Straw Poll – After the Call for Proposals is issued, how much time should be allowed before proposals must be

on the server? A - 3 weeks (6), 2 months (27), 3 months (65) vi. No one wants to present their proposals first

vii. Why generate the proposals list? A – create opportunity to communicate/merge 17. Recessed Early at 5:41 PM as no short (<20 minutes) submissions were identified

Monday November 10; 7:30 – 9:30 PM

18. Chair read IEEE-SA Bylaws on Patents slide #1

a. Danni Nissani indicated he had a patent application on behalf of himself pending on information he will discuss tomorrow in paper [doc. (11-03-0669r1)]

19. Inappropriate topics were reviewed by Chairperson – standard IEEE slide #2 20. Chair noted Submissions [doc (11-03-891r0)] list was on the server 21. Submission #1 – Eric Jacobsen, Intel, LDPC FEC System [doc. (11-03-0865r1)]

a. Iterative FECs (turbo codes, turbo product codes, Low density Parity Check Codes (LDPC)) b. LDPC – good performance, low complexity for short Blocks c. Encoder can be complex d. 8 Iterations a good trade-off e. SIFs budget drives complexity trade-off f. Arbitrarily selected 1 us to do decoding g. BCJR (did not define) computation engine is memory efficient but 2x complexity over Min-Sum kernel



h. 240 Mbps (240cycles at 240 MHz) i. Discussion

i. How do you handle variations in code rate? A - Concatenate code words ii. H matrix is 1600x400 and 4 bits per column

iii. Is there IP associated with BCJR engine; A – not sure but there is none associated with LDPC 22. Submission #2 – MIMO Experimental Test bed for OFDM Research [METeOR] UCLA EE ; Babak Dabeshrad; [Doc. (11-03-

0806r0)] a. 2x2 setting, 120 Mbps non-real time for this paper b. UCLA Goal 8x8 real system by 2005 c. Need Channel inversion algorithm converted to silicon? d. GUI for Very flexible phy layer e. Developed unique packet structure over last 3 years f. Problems

i. IQ Mismatch ii. Phase noise

g. QPSK on 190 useable subcarriers h. .18u CMOS ASIC i. Uncoded system today with goal of 10-3 BER j. Discussion:

i. IQ correction process? A – DFE and Joint Detection Algorithm ii. Mobility effects? A – Not at this time

iii. Channel Estimation Algorithm – RLS 23. Submission #3 – Transmit Diversity for MIMO OFDM, Sumeet Sandhu; Intel; [Doc (11-03-0847 r0)]

a. Cyclic Delay Diversity (CDD) compared with Alamouti (Orthogonal Space-Time Block Codes) b. For > 3x3 Alamouti gain decreases c. As rate decreases Alamouti gain is lower d. Alamouti is best code for 1 receive antenna at 3 dB e. 3 RX antennas Alamouti only gains <1 dB wrt CDD f. CDD is compatible with .11a g. Discussion

i. Channel Model – based on real measurements h. Meeting Adjourned until 10:30 AM tomorrow.

Tuesday 11-11-03; 10:30AM-12:30PM

24. Chair reviewed our schedule:



a. 20 submissions total b. 16 hours left c. 17 more submissions d. Important FR&CC and CM work to do e. We could end up using all our time for submissions; is this what we want to do?

25. Straw Poll – Shall we limit presentation time per submission to no more than 30 minutes (including Q&A), thereby guaranteeing approximately 8 hours of time to work on and/or approve Channel Model and FR&CC? passed unanimously!

26. Submission #4 – Hardware Implementation of Indoor MIMO WLAN Channel Models; Electrobit (Finland) Tommi Jamsa, [doc. (11-03-0824 r0)]

a. Hardware simulator increased Simulation Speed b. Real Devices can be tested c. Results between Hardware and software can differ due to non ideal hardware characteristics d. 10 ns delay separation in hardware e. Evaluated in Matlab what the impact was by constraining the delay accuracy to 10 ns and found almost no difference

(<1 dB) f. Measure amplitude and phase accuracy in a 2x4 MIMO system; < 0.5 dB g. Delta was +/- 0.3 dB for a delay spread of 0.5 to 5 ns in delay h. 16 fading channels in proposed test set-up i. Conclusion – delay accuracy inaccuracies not critical up to 10 ns; test set up suggested j. Discussion:

i. Bi-directional system or unidirectional; if so does delay include both directions? A – Unidirectional; latency was 4 us round trip

ii. Bi-directional would double hardware? A - yes 27. Submission # 5 – Novel MIMO Transmission Method, Daniel Nissani, (Nissensohn) [doc. (11-03-669r0)];

[email protected] a. Cross-talk interference is a very significant factor in MIMO systems b. Can be predicted and Controlled contrary to popular opinion c. Real cause is Imperfect MIMO Cross talk Channel estimation d. 20 dB improvement over ZF (zero force), LSE, MMSE at 1E-6 BER e. Basic MIMO Model analysed f. Estimation error depends on Mag. of error estimation and channel structure itself g. Majority of channels have crosstalk much worse that thermal noise h. Crosstalk interference depends on the structure of H!! in a simple manner i. How to exploit? j. Pre-equalizer to transform bad channel into a good channel using two short burst preambles (6 symbols) k. Hn=noisy channel; Hm=modified channel



l. Result – single matrix multiplication at BOTH TX and RX m. 20 dB gain ! in his simulations at 1E-6 BER n. Discussed gain in range relative to existing systems (.11a) for a 3x3 MIMO technique o. Discussion

i. What type of channel estimation? A-Flat fading Raleigh channel ii. Why is a really good estimate of V not good enough? A – not practical; Control of crosstalk is UNIQUE to

MIMO systems however!! iii. Overhead – how is info fed back to Transmitter in order to calculate V; A – feedback symbols before data is

transmitted 28. Submission #6; Wi-Fi Alliance TGn MRD; Paul Feinberg; Wi-Fi Alliance (WFA); [doc (11-03-878r0)];

a. Salient Requirements i. 100 Mbps @ 15m

ii. 10 Mbps @ 100m iii. 95% coverage iv. Single Phy which could be used in Residential, Enterprise or Hot Spot market segments v. Backward Compatibility

vi. HT does not constrain operation in non-BSS topology (e.g., mobile) b. Target Market Segments

i. Infotainment ii. Business

iii. Hot Spot c. Environments

i. Stratified Market Segments into about 3 each d. Document will be maintained through December to complete WFA comment resolution e. Discussion:

i. Where is MRD? A-[Doc – (11-03-879)] ii. How do we insert these inputs into .11n? A – close liaison like today

iii. Will WFA go its own way like it did for WPA? A- not at this time iv. Will WFA add additional requirements? A – possibly but only for interoperability v. Goal? A – align activities but will not spec performance levels

29. Submission #7; Simulation Methodologies and Radio Impairment Modelling for Fair TGn Proposal Comparisons, Jeff Gilbert from Atheros Communications; [doc. (11-03-888r2)]

a. The Problem – Radio impairment models and Phy abstraction used in MAC are not specified b. Radio Impairments to specify

i. Link margin (e.g., antenna gain, EIRP, RX noise floor) ii. Synthesizer Phase Noise and Frequency offset (e.g., pilot schemes, constellation size, offset like .11a or .11g)



iii. Nonlinearities (PA, mixer) iv. Baseband impairments (IQ mismatch, A/D conversion resolution, baseband noise floors)

c. Phy Modelling and System Simulations i. TGn differs (both MAC and PHY w/throughput at MAC SAP)

ii. PHY abstraction used in MAC/System simulation iii. Time varying channels will impact feedback schemes

d. Possible Solutions suggested e. Interference Model f. Layer 3 and above Parameters (e.g., TCP parameters, aggregation) g. What to do? Separate Simulation group? h. Key is balance accuracy and effort i. Discussion:

i. Where does detailed specification stop? A – will not define implementation ii. Have you considered just offering Atheros model? A – too difficult to integrate into .11n process

iii. Very complex; could they be grouped? A – yes some grouping could be done; not as difficult as channel model iv. Agree Phy abstraction problem in particular needs to be recognized v. Not in FR&CC

vi. Which is more important FRCC or Simulation Methodology vii. What happened in .11g? A by Chair – like .11b; 10 FRs and 20-30 CCs; pointer to CM document BUT this was

only a new PHY!; nothing RX based viii. We don’t know what BW and channelization are yet so how can we do this?

ix. See as tightly tied to Channel Models j. Straw polls for later if this topic arises:

i. Should 802.11n specify radio Characteristics (either ideal or impaired?) ii. Should 802.11n specify PHY/MAC simulation methodologies?

iii. How should this be accomplished? 1. Separate group/document referenced by FRCC? 2. Just add to Usage Models? 3. Just add to Fnc Requirements/Comparison Criteria? 4. Just add to Channel Models?

30. Adjourned for Lunch and will reconvene at 1:30 PM

Tuesday, November 11/03; 1:30 – 3:30 PM 31. Chair called meeting to order at 1:33PM



32. Submission #8; Packet Error Probability Prediction for 802.11 MAC Simulation; John Sadowski, Qinghua Li, Intel; [Doc. (11-03-0863r0)]

a. Define Phy Model for MAC simulator b. MAC Simulator includes

i. Multiple Apps and STAs ii. Channel Models

iii. PHY Model (not full link level simulation) c. Static channel throughout PDU d. Same model for all packet lengths, (Model D) e. Assumes OFDM symbols are independent events f. 40 MHz SISO Simulations g. Trade-off Modulation Coding Schemes versus model parameters h. SNR is a very poor predictor of Symbol Probability of Error i. Proposed a compressor predictor j. Accuracy is best in region where it is important, i.e., higher error rates k. Discussion:

i. How to determine Viterbi soft Metric SNRs? A – averaged or used Pb for lowest quality bit ii. Interleaving? A – not a critical factor

iii. Geometrical Average; is it comparable to compression function used? A- yes 33. Submission #9; Simulation for Spatial Covariance Matrix; Antonio Forenza, UT, [Doc. (11-03- 0821r0)]

a. Analytical Model i. p is laplacian distribution

ii. Compared with (3GPP, Bessel fncs in .11n, Fast-R) b. Performance Results

i. Fast-R method is 200 times faster than .11n simulation ii. Current model assumes Tap AS~Cluster AS; what is justification for this

c. Conclusions i. Fast-R method is a practical alternative ~200x faster

34. Submission #10 ; Receive Sensitivity Tables for MIMO OFDM 802.11n, Stephan ten Brink, Realtek Semiconductors; [doc. (11-03-0845r0)]

a. Purpose – Develop Rate versus RX sensitivity Tables to determine # antennas b. Options to increase data rate

i. Modulation order ii. Increase channel code rate

iii. Increase BW iv. Increase # TX antennas



c. Assumption for simulations i. Perfect channel knowledge

ii. Idealized Multipath MIMO Channel; iii. Packet quasi static iv. 1000 bit packets v. 10 dB noise figure

vi. 5 dB implementation margin vii. 10% PER

d. Tables i. For increasing range use Alamouti not MIMO

ii. Don’t use 2x2 but rather 2x3 e. MIMO Detector Comparison

i. Zero Forcing detection is adequate f. Summarize

i. Range – use Alamouti ii. Use RX=TX+1 i.e., one more receiver than transmitter for higher rates

iii. ZF is close to APP detection for higher rates iv. Can achieve 150 Mbps with two transmit antennas

g. Discussion: i. Was TX power normalized? A – yes

35. Submission #11; Usage Model Simulation Results; George Vlantis, ST Microelectronics [doc (11-03-0841r1)] a. Simulated Scenarios – 1,2,4,6 b. Simulation Tools – NS .11b model generalized to .11g; MAC models available; Traffic generators; Channel models are

difficult to simulate well in NS c. Using DLP d. Channel Model – exponential path loss e. Covered Residential Scenario#1 in detail (residence with an AP) f. Get to > 50 Mbps only in QoS applications g. Delay and jitter suffer when aggregation enabled h. If TCP traffic removed than desired throughput is achieved i. Other scenarios behave similarly j. Discussion:

i. Are simulations implementable in a realistic TGn proposal? A – this work shows it will be tough even with 300 Mbps at the PHY layer for all the features

ii. No rate control?; A - Yes 36. Submission #12; Intel Validation of TGn Simulation Scenarios; Adrian Stephens, Intel; [doc (11-03-835 r1)]



a. Purpose – yes the scenarios are implementable in a realistic protocol b. Tool - Op Net version 9; 1 year with 2 people c. Implementation – only considered UDP flows; don’t have EDCF or HCCA yet (i.e., no TCP traffic); SISO channel

width 80 MHz which is thought to be roughly = to 2x2 MIMO at 40 MHz d. Summary of results

i. Only scenarios 2,9,11 have not been simulated ii. Recommends accepting simulation scenarios

e. Reviewed many Scenarios in detail f. Discussion:

i. Will 20 MHz channelization work? A – think so since 4 spatial channels=80 MHz ii. Results with Submission #11 are similar but conclusions are different; why? A – first, #12 assumed TCP and

this study did not 37. Meeting adjourned until 4 PM

Tuesday, November 11/03; 4:00-6:00 PM

38. Submission #13; IEEE 802.11e Performance Evaluation; Javier del Prado; Philips [doc. (11-03-0861 r0)] a. Simulator OpNetv2 b. Throughput as a function of frame size and number of stations c. Answer – Are the Usage Scenarios Implementable? d. Protocols considered

i. DCF ii. EDCF

iii. EDCF wo ACK iv. HCCA v. HCCA wo ACK

e. Simulations Results given for many scenarios including the most challenging VoIP i. ~90% Efficient for large frames

ii. ~55-80% efficient for 1500 Byte frames iii. Simulation scenario #1 – for 216 Mbps PHY system is close to limit iv. HCCA Independent of number of Stations v. Do we need to relax the simulation scenarios especially for small packets

f. Discussion i. Are scenarios implementable? A – not if all impairments included

ii. Average MAC efficiency ~ 25%



39. Submission #14; Direct Path to Multipath Ratio (DPMPR) and RMS Delay Spread Measurements in an Office and a Lab Environment; Eldad Perahia, Cisco Systems; [doc.(11-03-846r0)]

a. K-factors are defined in .11n channel model were converted b. Reviewed Data Acquisition scenarios – small office and lab c. Conclusions

i. Corresponds to Model C ii. LOS similar to model C

iii. NLOS NOT similar to model C iv. Suggested modifications to Model C v. Model D compared well

d. Discussion i. Power profile should dictate K-factor but here the K-factor is related to the DPMPR

40. Submission #15;Bell-Spike Power Doppler Spectrum Model; George Vlantis, ST Microelectronics; [doc. (11-03-0839r1)] a. Impact of vehicular motion b. Proposed model formula; vo=stationary c. This work has been incorporated into 11-03-161r3 as proposed

41. Submission #16 MIMO Channel Measurements Using Super Resolution Techniques, Nir Tal, Metalink Broadband; [doc. (11-03-890r0)]

a. Purpose i. Present new results

ii. Validate channel model iii. Statistics on Fluorescent Modulation

b. Measurement Information – lower UNII band, 2m above ground, 1.5 Lambda antenna spacing c. Measurement Set-up- simultaneous 2x2 MIMO d. Why super resolution techniques

i. Long sampling periods 100ms over slow 46 MHz sampling (vs 500 MHz sampling for instance) reduces memory significantly

e. Results i. Channel impulse responses between four antennas pairs e.g. TX1<->RX2

ii. Taps are independent iii. Taps vary somewhat over 100 ms measurement period iv. Cluster approach does actually work v. Statistical Results

vi. No strict correlation between RMS Delay Spread and Distance vii. Conclusion

1. Good correlation to model



2. Cluster model works 3. Fluorescent effect works 4. Doppler Spectrum close enough

viii. Discussion 1. Slide 11 – typo fast -> slow? A – yes 2. Slide 20 – measurements in same location? A-yes

42. Submission #17; 802.11n Channel Model Validation; Qinghau Li, Intel: [doc (11-03-0894)] a. Channel Model Tutorial b. User Interface c. Measurements d. Summary

i. Intel Results 1. RMS delay spread matches

ii. Zyray Measurements 1. Cover D,E and some F, large space matches model 2. Overall good match

iii. Metalink 1. MIMO capacity is ~ 2x each channel 2. Again good correlation

e. Discussion i. Were results other than average obtained? A-

43. Submission #18; Ricean K-factor in an Office Cubicle Environment;; Qinghau Li, Intel: [doc (11-03-0895)] a. Measurement Set-up and Analysis b. Locations c. Results d. Conclusion – K-factor is small due to aggregation of scatterers in office cubicle environment

44. Submission #19; Elevation Effect on MIMO Channel; Qinghau Li, Intel: [doc (11-03-0934r0)] a. Office Environment again b. 2.4 GHz and 5.2 GHz c. 2 in antenna d. Channel Capacity – 4x4 ch capacity at SNR 15 dB, varies in a small range with change in elevation e. Conclusion

i. Elevation changes channel capacity by only 1-10% ii. AP sees slightly fewer Apps if Elevation not included

iii. AS at AP is only about 5% iv. Effects are generally small.



Tuesday, November 11/03; Evening 7:30-9:30 PM

45. Submission #20; Measured Ricean K-Factor in a 5 GHz Band; Yasuhiko Inoue, NTT Japan; [doc (11-03-0884r1)] a. Overview, derivation of K-factor b. Measurement Apparatus c. Plot measure results on theoretical K-factor plots to determine value d. Apartment, Corridor, Office Meeting Room e. Summary of results

i. Apartment – LOS/NLOS 7/7 => correspondence to B-LOS/C-NLOS channel models ii. Corridor – 17 (near), 10 (Far)/9 => NA/F-NLOS

iii. Office – 8/8 => D-LOS/D-NLOS iv. Meeting room – 10/NA => DLOS

46. Channel Model discussion – Colin Lanzl; [doc. (11-03-0871r1)] f. Review of Updates to document

i. Added model G, Stadium Model with 600 ms delay ii. Shadow fading has been reduced from 10 down to 4-8

iii. Updated Table IIa iv. Added Table IIb v. ST Micro work (doc 11-03-831r1 )was added to Doppler shift chapter

vi. A detailed antenna correlation model for cross-polarized antenna was NOT included g. Committee feels models are adequate for simulations and recommends adoption h. Discussion

i. Stadium model based on SISO measurements of RMS delay spreads ii. Add statement that Stadium model is based on limited measurements and SISO results

iii. Nothing about phase noise as it is not really a channel concern iv. To get the MatLab model you must sign up on line with the University of Belgium; see link in doc. v. Interference is also not part of the channel model because it ends up being a radio simulation model

vi. This document is a tool vii. You can use your own code or the University of Belgium’s

viii. Is Stadium model out of scope? ix. Straw Poll – Should the Usage cases (optional outdoor park and point to multipoint backhaul cases) that

reference the “Stadium Model” be deleted from the Usage Cases, and should the “stadium Model” be deleted from the Channel Models?” (passed 73,4)

x. Motion – Updating Usage Model document by removing the two usages cases - optional outdoor park and point to multipoint backhaul – passed unanimously with no objection



xi. Given that the usage cases no longer exist the Channel Model document was edited to remove all references to the stadium model, model G. This became [doc (11-03-0871r2)].

xii. Motion by Colin Lanzl and seconded Nir Tal that the Task Group adopt the Channel models in [doc (11-03 871r2)]

xiii. Debate: 1. Channel fading applies to whole channel 2. By removing stadium model is the PAR being violated? A-No 3. Does document dominate? A yes, not the Matlab code and correlation data

xiv. Main motion passed – (56,0,8) xv. TG officially thanked Venko Erceg for all his hard work

xvi. Colin will give the doc a final check and give it a new title xvii. .11n was recessed at 8:45 PM and FRCC ad hoc committee meeting was convened

1. FRCC ad Hoc Meeting a. Agenda

a. Appoint secretary b. Fix usage models [doc. (11-03-802rx)] c. Fix simulation scenarios

i. Note: fix time limit for a & b ii. Note: Colin volunteered to fix channel model references in b with Adrian off line

d. No objection to limiting b & c to 2 hours e. Discuss Functional Requirements (FR) f. Discuss Comparison Criteria(CC)

b. Edit [doc. (11-03-802r3)] to yield (11-03-802r4) a. Removed usage models 7&8 and simulation scenarios 8 per motion above b. Review Mary Cramer’s changes for Large Enterprises c. ACI will need to be handled on an case by case basis d. Added frequency reuse (CCI) in Appendix 1 e. 2-D model (no elevation) f. added CCI calculation proposed by Mary Cramer g. Who thinks we should leave 2nd para. on ACI in usage model 4 or move it to comparison criteria (CC). Unanimous

decision was to move it to the CC h. In Usage Model 4, Large Enterprise has two versions

A - first section assumes 10 STAs were doing all classes of traffic (UDP and TCP) B - second section assumes the 10 STAs divided the traffic among them



Note: this was a major difference between George Vlantis and Adrian Stephen’s simulations; George assumed situation ‘A’ above while Adrian assumed ‘B’

i. Straw Poll – remove the ambiguity in Usage Model 4 by removing the top half above the red note so that the Usage Model is based on the 10 STAs doing a selection of the applications as noted in the bottom half. Passed (38,2,6)

j. Each of the local file transfers is an offered load of 30 Mbps k. Straw poll – should we close this topic and move on passed visually about 8:1 l. Straw Poll – should the Usage Model 4 be accepted was (Y18,N10, ?12) but it is a technical motion and therefore

the motion fails m. Meeting was adjourned for the evening

Wednesday, November 12; Morning 8-10:00AM

1. Meeting was convened by Chair at 8:09 AM 2. Announcements:

a. Channel Model doc. now renamed TGn Channel Models and renumbered as [doc. (11-03-940r0)] b. 4 Mbyte limit in documents so, for large files try to convert to pdf first to compress document c. Don’t forget to sign-in; if system goes down it will allow retroactive attendance sign-in

3. Return to FR&CC Special Committee meeting but NOT in an ad hoc mode so binding votes can be taken 4. Return to edit 11-03-0802 r5; left off at Usage Model #4 5. Proposed changes by George Vlantis - 6 TCP traffic STA -> 4 STAs and 2 STA video conferencing STAs -> 4 STAs 6. Discussion:

a. All within a single BSS? A – yes b. TCP traffic much harder to simulate than UDP traffic

7. Straw Poll – should proposal be adopted failed at (17,15) since it was a technical vote and therefore required 75%. 8. Discussion:

a. Commenters should caucus 9. Hot Spot Model 6

a. Also ambiguous b. How to make unambiguous? c. Motion – to keep top section of Usage Model 6 and delete the bottom half of Usage Model 6 by Adrian Stephens

and seconded by John Kowalski d. Debate offered; none taken e. Motion passed (21,3,17)

10. Proposed Changes to Large Enterprise Model 4 were withdrawn by George Vlantis 11. Motion –accept Usage model 4 as edited yesterday (11-03-802 r4) moved by Adrian and seconded by Javier del Prado

a. Debate offered; none take



b. Motion passed (23,3,15) 12. Now all usage models have been adopted 13. Reviewed final edits to Usage Model [doc (11-03-802 r4)] in preparation for acceptance vote later in the day 14. Discussion

a. Need delay limit suitable for UDP traffic in Application 18? A - 100 ms was proposed by Adrian; Srini suggested 50 ms;

b. Straw Poll – Yes for <=50 ms and No for > 50 ms was (Y23,N9) c. Straw Poll – should we use 50 ms passed (24,1) d. Adrian Propose the Traffic type 21 be removed (point to point backhaul) was accepted unanimously e. Ref. Usage Model 9 and corresponding traffic types; note that it references bands; suggested leave out .11b stations f. Define legacy system at start of document as .11g stations in 2.4 band and .11a stations in 5 GHz bands g. For mixed mode consider only .11a and .11g systems h. Need a precise definition for legacy system i. Edited note in Usage Model 9 to read “legacy system means 802.11a (i.e., without 802.11e and 802.11h

amendments) in the 5 GHz bands and both .11b and .11g in the 2.4 GHz band j. Straw Poll to strike .11b in note above passed (25,7) k. Intent that STAs are on the same channel since only 1 AP l. Straw Poll – should we have a regulatory domain statement in Usage Model failed unanimously m. Motion – remove “both .11b and” from note in Usage Model 9 by Adrain Stephens and seconded by John

Kowalski n. Motion to amend text to add “operating at 54 Mbps” to both .11a and .11g references in the note by Javier del

Prado and seconded by Amjad. o. Motion to table main motion as amended by Adrian and seconded by Shrini; no debate allowed on motions to table

and the motion requires a simple majority passed (20,0,4) p. Discussion

i. consult with .19 ii. remove ‘common conditions’ table

q. Motion by Jeff Gilbert and seconded by John Kowalski to remove section called ‘Common Conditions’ r. Debate:

i. Contains valuable info so speak against ii. Against since need something to simulate against now

iii. Question was called s. Motion failed by visual count

15. Functional Requirements [doc.(11-03-0813 r4)] Discussion a. Document was reviewed b. What would happen if no single proposal met all FRs? Ruled ‘out of order’



c. Para. 1.1 made ‘Informative’ d. Para 1.2 appended ‘in clause’ e. Para 1.3 replaced para. by “Individual functional requirements may reference terms or metrics defined in the 802.11

TGn comparison criteria document [2] or the simulation scenarios defined in the 802.11 TGn Usage Model doc [3]” f. Para 1.4 restructured as “Can be verified from an examination of the proposed submission or a reasonable

simulation environment”; objection to ‘Should be relevant to one or more mandatory use cases in UM doc (TBD)’ i. Discussion – redundant?

ii. Straw Poll – remove ‘Should be relevant to one or more mandatory use cases in UM doc (TBD)’ passed (50,6)

g. Para 1.4 note ‘at the September TGn meeting, it was decided that this document should relate only to mandatory features of the proposal. Optional features, qualities, performances are considered in [2]’ was accepted without comment

16. Session adjourned at 10:00 AM until 1:30 PM this afternoon. Wednesday, November 12/03; 1:30 – 3:30 PM

17. Chair called the meeting to order at 1:41PM 18. FR Clause 2 Discussion started 19. Adrian noted that the FR document only contains MANDATORY requirements 20. Discussion on FR Table entries which the secretary is numbering herein as they are discussed

a. #1 Single Link High Rate Supported i. Should a range number be retained at all

ii. FR doc is a Y/N document and the CC doc will reflect detail requirements such as range iii. Range is fundamental and should be retained iv. There must be a minimum v. Straw Poll – do we keep the range spec in this FR? (Y=38, N=34)

vi. Lack of consensus noted vii. Should indicate “mandatory” usage models defined in Usage Model document”

viii. We don’t have a usage model that is a single link ix. Therefore let’s remove this requirement x. Terminate statement after MAC and not have any range constraint

xi. Eliminate ‘single link’ adjective xii. Too complicated since multiple parameters required (usage models, channel models, range)

xiii. Straw Poll – should there be a 100 Mbps requirement anywhere in the FR passed (98,2) xiv. Straw Poll - Should 100 Mbps be measured at the top of the MAC SAP passed (99,5)



xv. Straw poll - Should the 100 Mbps figure be measured in the context of a single link unidirectional (73) or an existing simulation scenario? (9)

xvi. Straw Poll - Should we define a usage model for a single-link unidirectional data flow? (Y=51, N=25) xvii. Model A was specifically defined for evaluation purposes, could we use it?

xviii. Proposal to separate link and range into separate requirements xix. Straw Poll – Supports a single link of 100Mbps at the top of the MAC Data SAP measured in the context of

the simulation scenario TBD passed (40,9) b. #2 Straw Poll – Should it read “The single link high throughput rate measured in FR1 is met at a range of 15m.”

(withdrawn) i. Discussion was tabled until simulation scenario defined

c. #3 WFA input – Supports a point to point throughput of 10 Mbps at the top pf the MAC at a range of 100m (TBD) for channel models (B,C,D-TBD) defined in [4]

i. Discussion 1. Let’s move to comparison criteria was accepted without opposition

d. #4 Continuous coverage of high throughput range and 10 Mbps range should be at least 95% (i.e., maximum of 1 out of 20 stations within range specified may have to accept lower throughput; also provides for mobile stations and movement in the environment)

i. Discussion 1. Let’s move to comparison criteria was accepted without opposition

e. #5 Supports BSS (1 AP, 1 STA) operation with throughput of 100 Mbps at the top of the MAC at the range of 15m (TBD) for channel models (B,C,D-TDB)defined in [4] and in the presence of two other APs operating on the same channel each within 15m of the AP under test (small enterprise)

i. Discussion 1. Not achievable 2. Straw Poll

a. Assign to further discussion on FRCC teleconferences (5) b. Should just delete or ask WFA to resubmit (51) c. Should just move to CC (5)

f. #6 “Backward compatibility with existing 802.11 devices and software such that the current MAC-SAP functionality is retained”

i. Discussion 1. 802.11 only defines interfaces 2. modified as “Backward compatibility with existing 802.11 architectural interfaces such that the

current MAC-SAP functionality is retained” 3. Straw Poll – approve #6 as modified (32, 13)



g. #7 Point-point throughput at 100 Mbps shall be met using a 20 MHz channel in at least one of the modes of operation

i. Discussion: 1. Accept 2. Why not define a usage scenario as we did for #1 3. Modify as follows “Point-point throughput at 100 Mbps as measured by the 20 MHz

throughput/range comparison shall be met in all the modes of operation” 4. Straw Poll – “All modes of operation operate in a single 20 MHz channel?” (Y=23,N=65) 5. Straw Poll – Proposal supports an optional or mandatory mode of operation that supports 100 Mbps

in a 20 MHz channel? Passed (84,13) 21. Meeting adjourned at 3:30 until 4:00PM.

Wednesday November 12/03; Late Afternoon 4:00 – 6:00 PM

22. Chair reviewed the FRs that were used for .11g and noted that there were 10 in total 23. Chair reviewed the CC that was used for .11g and noted that there were 34 in total 24. #8 Protocol supports .11j 10 MHz channels

a. Discussion i. Straw Poll – do we require a proposal to support a mode of operation that is compatible with .11j 10 MHz

channels failed (Y12,N69) 25. #9 The protocol supports 2.4 GHz ISM and 5 GHz UNII bands

a. Discussion i. Straw Poll – do we require all proposals to specify a mandatory or optional mode of operation using the 2.4

GHz ISM band (Y42,N45) ii. Since no consensus this cannot be a FR

iii. Straw Poll - do we require all proposals to specify a mandatory or optional mode of operation using the 5 GHz bands (including those specified by .11a)? passed (Y92,1)

iv. Should be go back to the PAR and 5C? No by visual response v. #9 was edited to “Protocol supports 5 GHz bands (including those supported by .11a)”

26. #10 Protocol provides options that allow low-cost lower performance variants and high-cost higher performance variants or alternatively protocol provides options that allow performance and cost trade-offs for different modes of operation.

a. Discussion i. Remove #10 was adopted by unanimous consent

27. #11 The protocol defines a mandatory or optional mode of operation in which .11n STA can communicate with a legacy .11b AP

a. Discussion



i. Since it is optional let’s make it a comparison criteria ii. Let’s just reuse the PAR language which is “Some of the modes of operation defined in the proposal shall

be backwards compatible and interoperable with 802.11 and/or 802.11g” iii. “If it supports 2.4 GHz Some of the modes of operation defined in the .11n proposal shall be backwards

compatible and interoperable with 802.11 and/or 802.11g” iv. Straw Poll – vote on combined form (as currently in PAR) or as two separate statements (Combined 26,

Separate 35) v. Straw Poll – “backwards compatible with” means “supports all mandatory modes of operation?” (Y54,N2)

vi. Straw Poll - Some of the modes of operation defined in the proposal shall be backwards compatible and interoperable with 802.11a (Y77,N1)

vii. Straw Poll - If the protocol supports 2.4 GHz some of the modes of operation defined in the .11n proposal shall be backwards compatible and interoperable with 802.11g (69,9)

28. #12 A HT STA including the AP can communicate directly with a legacy .11b/g STA and /or .11a STA (depending on the frequency band of operation) in both BSS, managed by a HT or legacy AP, and IBSS modes

a. Discussion i. No objection to deleting the requirement since it was covered by #10 and #11

29. #13 .11b BSS compatibility was removed similarly 30. #14 11g BSS compatibility was removed similarly 31. #15 11a BSS compatibility was removed similarly 32. #16 11b STA compatibility was removed similarly 33. #17 .11g STA compatibility was removed similarly 34. #18 11a STA compatibility was removed similarly 35. #19 11b IBSS compatibility was removed similarly 36. #20 .11g IBSS compatibility was removed similarly 37. #21 .11a IBSS compatibility was removed similarly 38. #22 Activation of legacy CSMA/CA MAC procedures are user controlled

a. Discussion i. No problem moving to CC

ii. Intention – to allow an IT manager to program the devices iii. Alternate wording proposed – “A .11n HT AP can be configured to reject or accept associations from legacy

stations because they are legacy stations” passed (Y49,N17) 39. #23 All HT STA shall support the channel access mechanisms provided by .11e

a. Discussion i. Must support this to do simulations

ii. Alternate wording “No HT STA shall inhibit the 802.11e QoS functionality” iii. Straw Poll – “All HT STA shall support the channel access mechanisms provided by .11e” (Y52,N30)



iv. Chair interjected that all FR will require 75% support v. Straw Poll “The proposal shall permit the implementation of 802.11e options within a .11n STA” (Y70,N6)

40. Meeting adjourned at 5:58 PM until tomorrow morning at 8:00 AM Thursday November 13/03; 8:00 –10:00 AM

41. Elections for Channel Model and FRCC Special Committee Chairs a. Motion – Whereas the Channel Model Special Committee has completed its work and TGn Channel Models have

been adopted in Document 11-03-0940, move to dissolve the Channel Model Special Committee by Colin Lanzl and seconded by Eric Jacobson passed unanimously (39,0,0)

b. Chair nominated Adrian Stephens as chair of the Channel Model Special Committee; c. Adrian was elected unanimously

42. Meeting returned to the resolution of the Functional Requirements and was chaired by Adrian Stephens 43. Adrian decided to discuss the Simulation Scenarios chapter in the Usage Model [doc. (11-03-802r5)] and the need to add a

simulation scenario #16 to simulate the first functional requirement dealing with 100 Mbps data rate; Adrian removed the word informative for that chapter; Adrian and Colin reviewed the edits to the Simulation Scenarios chapter which were made to reflect the final Channel Model document. Adrian put [doc. (11-03-802r5)] on the server.

44. Returning to Functional Requirement [doc. (11-03-813r5)] a. #24; Proposal does not redefine mechanisms in the baseline that does not pertain to higher throughput

i. Discussion: 1. Does not belong in FR 2. Straw Poll – (Y14, N17) 3. No consensus so it will be removed

b. #25; Spectrum Efficiency; Adrian requested the PAR be put on the screen; appropriate language from the PAR “In order to make efficient use of scarce spectral resources in unlicensed bands, the highest throughput mode defined by the HT amendment shall achieve a spectral efficiency of at least 3 bits per second per Hertz for the PSDU. ….

i. Discussion: 1. Do we have a requirement for spectral efficiency? 2. Yes and it is covered appropriately in the PAR 3. Should explicitly state the spectral efficiency? 4. Straw Poll – Should we have a FR relating to spectral efficiency? (Y66,N1) 5. What should content of FR be? Current wording is taken from the PAR and is “the highest

throughput mode defined by the HT amendment shall achieve a spectral efficiency of at least 3 bits per second per Hertz for the PSDU.” This was accepted unanimously.

6. Should we set the bar as in the PAR or should we raise the bar?



7. You may use higher modulation orders in lowest BW channel but the highest throughput (TP) might actually be achieved in a higher BW channel using lower order modulation.

8. Straw Poll – “the highest throughput mode defined by the HT amendment shall achieve a spectral efficiency of at least 3 bits per second per Hertz for the PSDU.” Passed unanimously(Y73,N0)

c. #26; Fair Sharing; i. Discussion

1. Tough to do as a FR 2. Adrian believes a suitable definition can be achieved and sighted it is the CC 3. Like range discussion so let’s leave it to the CCs 4. Straw Poll – “Given that we can achieve a suitable definition of fairness, should we have a FR that

mandates fair sharing of the medium with legacy BSSs” (Y14,N51) 5. Fair Sharing was removed

d. #27; Increased range for current rates: i. Discussion:

1. Whole issue of range is without consensus and therefore should not be an FR 2. Ranges for legacy systems are ill defined so we should not try and make a FR out of range 3. Straw Poll – “Should the FR require increased ranges in its modes of operation that match (or come

close to) existing rates?” (Y17,N39) 4. Increased range was removed

e. #28; Fair Medium Sharing was removed unanimously because it has been considered as #26 f. #29; Power Management

i. Discussion: 1. Should be removed because it was covered in the QoS discussion yesterday 2. How could we prove support for existing power saving modes 3. Straw Poll – Should we have a FR relating to support for existing 802.11(+e) power-saving modes of

operation (Y0, N42) 4. Power Management FR was removed

g. #30; Regulatory; The protocol provides signalling of any constraints on modes of operation specific to regulatory constraints due to geopolitical or regional regulations

i. Discussion: 1. Beating a dead horse since regulatory is already supported in our baseline document 2. Should we be building standards that are illegal anywhere in the world? 3. Straw Poll – If the proposal introduces any new regulatory dependencies it shall also define the

mechanisms to comply with them” (Y16, N12) 4. No consensus so it stands a strong chance of being removed



h. #31 Regulatory Compliance; All HT operating modes shall be compliant with current and emerging regulations affecting 802.11 products

i. Discussion: 1. Should be anticipatory of migrating into news bands 2. How can this, the future , be tested 3. Does it really apply to all countries? E.g., Namibia, Japan? 4. Insuring we are able to work with new spectrum 5. Should we be defining any modes that are illegal in any of our proposed markets? 6. WFA intended this comment to relate to only major markets such as European Union, North

America, Japan, Korea, Japan , China 7. Silly to put in FR since untestable 8. Straw Poll – “All HT operating modes shall be compliant with current regulations affecting 802.11

products in the following specific regulatory domains: EU, NA, Japan, Korea, China” (Y15,N62) 9. Regulatory compliance will be removed

i. #32; Anticipating new Spectrum; Proposal shall not prevent use of future bands provided regulations using those bands are consistent with regulations for which .11a/.11g is currently deployed.

i. Discussion 1. Identify any known non compliance may be identified 2. How do you show compliance 3. Base assumption is flawed 4. Simply put should be possible to accommodate new spectrum 5. We did not do it in.11a and so now we have to do .11j and delay product introduction 6. Straw Poll - : Anticipating new Spectrum; Proposal shall not prevent use of future bands provided

regulations using those bands are consistent with regulations for which .11a/.11g is current deployed.” (Y1, N54

7. Anticipating New Spectrum was removed j. #33; Universal Use; “Proposals shall be legal in major markets in the world”

i. Discussion 1. Should we be defining any modes that are illegal in any of our proposed markets? 2. Different from previous FR since it had the word ‘All’” 3. Proposal shall explicitly state which regulatory requirements the proposal complies with 4. Hard to tell without actually submitting equipment for compliance testing especially in the US 5. Should be a CC 6. Intent was to weed out clear violations 7. Straw poll –The proposal shall be legal in major markets in the world” (Y19, N61) 8. Universal Use was removed



45. Meeting was recessed at 10:00 until 10:30AM Thursday November 13; 10:30AM-12:30 PM

46. Adrian – proposed using the remaining time as follows - let’s finish discussion on FRs (only one remains); discuss marginal FRs; attempt to approve doc and if not then handle on conference calls between now and January meeting; members agreed with the agenda.

47. Returned to Usage Model doc 11-03-802r5; vote will be on whole document. a. Discussion:

i. Does it include common conditions? A – Yes ii. Then will vote against

iii. How about adding the following note: “11-03-888r2 describes issues with the specification of the simulation conditions that have yet to be addressed as of r6 of this document”

b. Motion – by Adrian that [doc. (11-03802r6)] be adopted as the updated Usage Models for IEEE 802.11n seconded by Colin Lanzl

i. Debate 1. How can we do this given it is incomplete, ? 2. Helps to go forward with simulations 3. There are TBDs 4. One normative TBD – point to point link rate test in #1 5. Procedure question – if we do this now can we change it later? A – yes 6. Motion to table by John Kowalski and seconded by Steve Halford; non debatable, simple majority

passed (34,3,10) c. Interjection – Colin has reformatted Channel Model document d. Motion to adopt [doc. (11-03-0940 r1)] as the official Channel Models for IEEE 802.11n by Colin Lanzl and

seconded by John Kowalski passed unanimously e. Final FR, #34; Baseline; The protocol builds on the specification defined in 802.11 ..

i. Discussion: 1. Straw Poll – Should we have an FR that describes the baseline standard upon which HT is built?

(Y6, N18) 2. What does build-on mean? A – same as it meant in the PAR 3. Propose language in the PAR 4. PAR is clear so why do we need an explicit FR? A – so we can have a single document to compare

proposals against. 5. Need a crisp definition



6. PAR language is – “The scope of the MAC and PHY enhancements assume a baseline specification defined by 802.11 and its amendments and anticipated amendments a, b, d, e, g, h, i and j. The enhancements shall be to support higher throughput. The amendment shall not redefine mechanisms in the baseline that do not pertain to higher throughput.”

7. Straw Poll – The proposal complies with all the mandatory requirements of the PAR [5] and 5 Criteria [6] passed (Y71,N0); relabelled Compliance to PAR.

48. Are there additional FRs that we may have missed??????? 49. How are applications reflected in the FRs and CCs; A – As stated in Selection Procedure - must meet FRs but need only

address CCs 50. Straw Poll by John Kowalski to add a FR that the Proposal shall support the mandatory 802.11n Usage Models (Y38, N26) 51. Added an FR – “Support of .11n Usage Models” 52. Now, comb FRs to find which ones do not meet the 75% threshold; Adrian put [doc. (11-03-813r6)] on the server 53. Are any FRs ambiguous? 54. Yes – HT rate supported in 20 MHz channel needs to be redefined 55. Straw Poll – “Proposal supports at least one mode of operation that supports 100 Mbps throughput at the top of the MAC

SAP in a 20 MHz channel” was accepted unanimously 56. Adrian proposed combing FRs using Straw Polls with voting members only and NO debate; if 75% is not achieved than

that FR will be removed; received unanimous consent; a. Single Link HT rate supported (40,8) b. Single link HT rate supported at specified range (18,20) fails c. SAP Compatibility (29,12)fails d. HT rate supported in 20MHz channel (45,5) e. Supports 5GHz bands (48,0) f. .11a backwards compatibility (48,1) g. .11g backwards compatibility (50,0) h. Control of support for legacy STA from .11n AP (33,9) i. .11e QoS support (Rahual Proposal) (34,15) fails j. .11e QoS support (John Kowalski Proposal) (39,0) k. Spectral Efficiency (53,0) l. Regulatory (14,29) fails m. Compliance to PAR (56,0) n. Support of HT usage models (31,21) fails

57. [doc. (11-03-813r7)] was uploaded to retain a copy of the votes 58. A new clean revision, [doc. (11-03-813r8)] was created and uploaded 59. Adrian reviewed surviving FRs




60. Motion by Adrian Stephens to adopt [doc (11-03-813r8)] as the official IEE 802.11n Functional Requirements was seconded by Colin Lanzl;

a. Debate: i. Not enough time

ii. Still has a TBD iii. More of a compatibility document than a Functional Requirement iv. Poor timing v. Motion to table main motion by Ralf de Vengt and seconded by Steve Halford is non debatable and

requires a simple majority passed (33,10,18) 61. Teleconferences scheduled biweekly Nov 18, Dec 2, Dec 16, Dec 30 62. Next 802.11n session is Jan 12-16, 2004 63. Straw Poll – Would you be in favor of changing the CC to weekly; failed. 64. Straw Poll – Should Dec. 30 meeting be replaced by one on Jan. 6, 2004 passed unanimously. 65. Conclusion – Teleconference calls will be held on Nov 18, Dec 2, Dec 16 and Jan 6 2004; details will be on reflector. 66. Meeting and Session was adjourned at 12:30 PM



Minutes of WAVE Study Group


Author: Filip Weytjens Transcore [email protected]

Tuesday, November 11, 2003 10:30AM Session The meeting was convened at 10:30AM by Lee Armstrong (Armstrong Consulting). Lee introduced himself as chair of the WAVE Study group and went over the procedures and rules applicable to the WAVE study group. Lee expressed appreciation for the attendance of each member and presented the agenda. The agenda was reviewed and approved by the group. It was mentioned that the meeting minutes of the Singapore meeting were not posted on the server yet because they were not in the IEEE 802 format. This will be corrected ASAP. For the convenience of the group, Lee went over the meeting minutes of the Singapore meeting. A presentation was presented describing the history of WAVE to IEEE and the current status of DSRC standards developments. The standards development that was on going within ASTM, comes into IEEE as a work in progress. Lee explained the organization and responsibilities of various SDO groups that have been involved up to this point. Involved organizations include ASTM, IEEE, SAE, and ISO. A number of different activities (ITS-A, VSCC, Omni-Air) have been underway and this work comes into IEEE 802.11 in various states of completion. The overall schedule was presented including prototyping, standards development, and supporting activities. It was mentioned that one of the DoT requirements for WAVE technology were the creation of an interoperable environment with support from the vehicle industry. It was asked whether the channelization sublayer was part of the lower layers or the upper layers. It was answered that it was part of the IEEE 1609 work in the upper layer. It was asked what the relation was between the invehicle network bus and the WAVE technology and how the security was guaranteed over the in-vehicle bus. This question was answered by demonstrating how information was passed between the WAVE media and the in-vehicle bus. To secure the in-vehicle bus, the car manufacturers are putting in gateways. The relation between the WAVE work and initiatives in Europe was questioned. This question was answered by representatives from Europe, America, and Japan who were attending the WAVE meeting. It was mentioned that there are several programs either in start-up or on going in different parts of the world. Where possible they are coordinated. ISO TC204/WG16 is working on a global standard and has representatives from Asia, North America, and Europe. A formal cooperation is in place between the WAVE work and the ISO working group. The overall status of the existing DSRC program is that draft standards for the upper layers are available (1609.xx) are available and the goal is to have them for balloting within the next 2 months. The PAR (IEEE-SA Standards Board Project Authorization Request (PAR) Form (2001-Rev 1)), including the changes made in Singapore, was reviewed. In Singapore the name was changed from DSRC to WAVE (Wireless Access in a Vehicular Environment). A question was raised on what changes to the IEEE 802.11 and IEEE 802.11a standards were incorporated to the ASTM standard. Also, some were concerned about the channel addressing mechanism. Broady Cash (ARINC), the author of the ASTM 2213-02 document, presented an overview of the changes that were made to the IEEE 802.11 and IEEE 802.11a. Broady explained the relation with the 802.11j addressing scheme, the different power masks, and performance requirements for the base band clock frequency.

Minutes page 1 Filip Weytjens, Transcore


It was questioned why this group moved from ASTM to IEEE. Broady and Lee described the overlap between the two groups (WAVE is based on IEEE802.11a), and the advantages for the WAVE community and IEEE of having one technology that could address the multiple bands. Also, the relationship of ASTM E2213 and the proposed IEEE standard was questioned. Broady explained that ASTM has agreed to transfer responsibility for the DSRC lower layers to IEEE once IEEE has a proposed standard in place. It was mentioned that it would be advisable to synchronize with IEEE 802.11h to work with them on new models. In the PAR, section 9 scope of proposed project, it was mentioned that the technology supports all forms of surface transportation, including rail and marine. It was questions what the relation was with the FCC ruling. It was made clear that this section did not want to restrict the use of the technology but that the technology had to be conformant with the applicable FCC ruling in the 5.9 GHz band. It was questioned whether high speed was the most important problem and that it may be better to include multipath as well because this could end up being more important. It was made clear that the scope of the task group was not limited to difficulties related to communications in a high speed mobile environment but the scope would also address multipath and other technical parameters. It was mentioned that in section 12, ” very high bursts up to 27 Mb/s”, was not enough. It should also include 54 Mbit/s since 20 MHz channels are allowed in the 5.9 GHz band. The meeting was adjourned at 12:40PM. . Thursday, November 13, 2003 8:00AM Session The meeting was convened at 8:00AM by Lee Armstrong. Lee reviewed the agenda for this session and stated that the meeting would be dedicated to finalizing the WAVE PAR and the five Criteria, both leading to the creation of a DSRC Task Force. Lee introduced the group to the PAR and continued the discussion on the “scope of the proposed project”, where we left it on Tuesday. It was questioned whether more information should be added on the distances that are supported by this system. It was decided to mention that the system supports operating ranges up to 1000m The section “purpose of the proposed project” was discussed. No changes had to be made. The relation between WAVE and IEEE 802.16 was discussed and after investigating the PAR of IEEE 802.16e it was clear that there were important differences between the two groups. In section “Are you aware of any other standards or projects with a similar scope?” of the PAR we added that IEEE 802.16e is not using an 802.11a flavour and does not support the short latency or direct vehicle to vehicle communications. It was decided to include “surface transportation” safety applications in section 14 “Is this project intended to focus on health, safety or environmental issues?” No other changes were made to the PAR. Lee continued with the discussion on the document describing the five dsrc criteria (11-03-0779-05-dsrc-five-criteria-dsrc.doc). In section “Broad market attention” it was mentioned that not “many” applications would connect to the internet but that it was more accurate to have “some” applications would connect to the internet. Also “most likely” was changed to “as early as”.



In the section “compatibility”, the version number of the ASTM document was changed to 03 (ASTM E2213-03). Also “roaming over” was changed by ”operation in” and “such as IEEE 802.11h and incorporating IEEE 802.11i when it is completed ” was included. In the section “distinct identity” we changed the following sentence (to) “… the most severe of wich is to be able to establish communications and complete transactions in the order of milliseconds with and between vehicles moving at speeds up to a minimum of 200 km/h.” to emphasize the use of this system in transportation and for safety applications, we added “, especially safety related services,”. We also changed “The modification” to “amendment to”. A motion was made on whether we should add transportation mobility in front of “especially safety related services” to become “especially transportation mobility and safety related services”. It was made clear that transportation mobility was directly related to the driving vehicles. The motioned passed with 5 in favour, 4 against, and 0 abstains. In the section “technical feasibility” we changed “conducted” to “continued” and changed the calendar years to 2004 and 2005. The wording “building out the” was changed to “deploying an interoperable”. We also changed “implemented with” with “using minor enhancements to”. We added “The resulting devices will be fully compatible with the existing IEEE 802.11a standard.” We added “anticipated” to “reducing the economic risk are the anticipated plans for the automobile manufacturers” and added “Existing manufacturers of comparable equipment will also be providing devices which can be aftermarket additions to existing vehicles”. No further additions were made to the document. The meeting was recessed for a break During the break, the minutes from the September meeting in Singapore were added to the server (11-03-0966-00-wave-Minutes-of-WAVE-SG-September-2003). Lee went over the final version of the PAR. In the scope of the project the following was added: “and only be applicable when using this amended PHY”. In the same section we took out the reference to the IEEE 802.11 MAC and IEEE 802.11a PHY since this was contradictory with the five criteria document. A motion was raised for the PAR document number 943-03 by Pankaj Karnik (JHU/APL) to be presented at the plenary meeting to the 802.11 WG on November 14th, 2003. The motion was seconded by Bob Soranno (JHU/APL). The motion passed with 21 votes in favour, 0 votes against, and 0 abstains. The document was submitted to the server. Lee went over the final version of the five WAVE criteria. In the section broad market potential, the name “National architecture” was changed to the official name “National ITS Architecture.” In distinct identity we changed “extreme levels of service quality” to “level of reliability and performance needed by the safety applications”. In the section on “Technical feasibility”, we added “ASTM standard” to be more detailed on what testing is done by the automobile manufacturers. We also detailed the standards that we would be testing. In the section on “economic feasibility” we added detail on the use of the WAVE devices for accessing the unii band. A motion was raised by Pankaj Karnik (JHU/APL) for document number 0967-02 describing the five WAVE criteria to be presented at the plenary meeting to the 802.11 WG on November 14th, 2003. The motion was seconded by Bob Soranno (JHU/APL). The motion passed with 22 votes in favour, 0 votes against, and 0 abstains. The document was submitted to the server. The meeting was recessed for lunch at 12:30PM. Lee proposed the motion to be made at the 802.11 WG closing plenary on November 14th, 2003. The motion that was voted on was described as: “Move to approve the PAR document 11-03-0943-03-wave-WAVE-PAR.doc, and 5 criteria document 11-03-0967-02-WAVE-five-criteria.doc, for WAVE, and forward to ExCom for Approval.” Lee presented this motion and asked whether there were objections by the group. No objections.




The meeting was recessed until 3:00 PM. After the break, comments were received for the par and for the five criteria. These were added to the documents. The changes required a new vote and update of the motion. A motion was raised by Pankaj Karnik (JHU/APL) for the PAR (document number 943-04) and for the five criteria (document number 0967-03) to be presented at the plenary meeting to the IEEE 802.11 WG on November 14th, 2003. The motion was seconded by Bob Soranno (JHU/APL). The motion passed with 26 votes in favour, 0 votes against, and 0 abstains. The document was submitted to the server. The meeting was recessed at 3:20 PM until 4:00 PM. Lee presented the next topic on the agenda which is the plan for future progression. Broady will be editing the standard that will be standardized for WAVE within the IEEE process. Broady will also present simulation results to the group and if the task group is accepted, amendments for some minor modifications to the 802.11a PHY and 802.11 MAC can be expected. It is advised to introduce the IEEE community to the details of wave including the concepts, applications, technology, … It is expected that this introduction can take several meetings. The question was asked how IEEE deals with the international operation of this technology. It was mentioned that the goal is to make it an international technology but that the group needs to come up with suggestions. Knut Evensens (Qfree) suggested that we should distribute the requirements that were found within the CALM M5 group. Lee agreed with this suggestion and will add this to the agenda for the next meeting. The WAVE study group was adjourned at 4:15 PM. .



Minutes for the Fast Roaming SG


Author: Michael Montemurro Chantry Networks 1200 Minnesota Ct, Mississauga, ON, CANADA Phone: 905-567-6900 e-Mail: [email protected]

Tuesday November 11, 2003

8:00am

Chair: Clint Chaplin Secretary: Mike Montemurro Attendance: • Call to order 8:00am • Chair Opening comments – Document 864r0

• SG operating rules • Introduction • Read IEEE-SA patent policy • Read inappropriate topics policy • Roll call

• Agenda – Document 866r0 • Review Agenda • Add a discussion on FRFH Requirements to the Agenda • Discussion on Agenda

• No comments • MOTION: Approve Agenda with the addition of FRFH Requirements added .

• By: Mike Montemurro • Second: Chris Hinsz Discussion: None

Result: Motion Passes Unanimous • Fast Roaming – Fast Handoff introductory discussion – What are other groups doing?

• 802.11i tried to provide a solution for security but they couldn’t resolve it • Dave Johnson is looking at the 802 level for fast roaming/ handoff across ESS –

different layer 2 networks – this study group needs to solve the problem within the ESS

• IETF – looking at handoff at the layer 3 and higher levels

Submission page 1 Michael Montemurro, Chantry Networks

mailto:[email protected]


• Fast roaming and fast handoff terms are used interchangeably – perhaps we want to define the terms – we should have definitions for fast roaming – fast handoff

• Fast roaming fast handoff may require communications between Access Points – will it have any bearing on IAPP? Not necessarily.

• IAPP is only a recommended practice so we can use it as part of the standard – we can include parts of the text

• 802.11e tried to provide a mechanism for fast roaming for setting up data streams by adding content to the association messages

• We need to work with TGi and TGe to provide QoS with secure fast roaming • Discussion on Requirements for fast roaming/fast handoff:

• What problem are we trying to solve? Getting keys in place? Do we want to know that the connection will be secure before roaming takes place?

• Do we want to solve fast handoff? We want to have “assured” handoff. How can we guarantee that we can roam successfully at a particular service level?

• Are we trying solve everybody QoS and security problems or should we put a mechanism in place and let others to solve their own problems?

• Nobody uses generic mechanisms – we don’t want publish a standard to do this.

• Proposal to break the problem into two parts: establish service contract, fast roaming.

• The GSM definitions for roaming and handoff are as follows: • Handoff is movement from one base station to another; • Roaming is movement from one network to another. • Should we adopt these “GSM” definitions? We really need clear

definitions. • Another way to look at roaming and fast handoff definitions is:

• Roaming is client driven. Roaming is what we see in 802.11. • Handoff is centrally directed. Handoff is what we see in cellular

networks. • 802.11k is looking to provide metrics to the client to facilitate roaming. • Do we want to solve the problem of “roaming as quickly as possible”? • Handoff by defining rules based on TGk metrics may be interesting. • The term ‘roaming’ does not appear in the 1999 Standards. There is no

official 802.11 definition so that we can define it • We need to solve the problem of setting up the STA state in the Access

Point before roaming takes place. • We are interested in VoIP calls not being disrupted – the requirements for

VoIP are given in document 11-03-430 • The problem we want to solve is to establish a STA state in an AP before

the station roams – we should target the state to a particular application • Suggestion that we call the group “Fast Roaming” and get rid of the

“Handoff” issue • What is “Fast Roaming”? We want to setup the STA state in the new access

point to allow the STA to roam quickly. • Certain applications are sensitive to loss of data communication when

roaming occurs.



• Should we create a Task Group to solve this problem? • Will we amend the standard to solve this problem?

• Recommended practice is too narrow a scope to address this issue. • Results reported by the TGi meeting in Hernden showed that roaming times were

acceptable. But they only included a 2-way handshake. • There is lots of controversy in this area – we need to agree on what tests are

applicable; how the metrics are measured; and what are the targets/acceptable values. • We need to establish what the goals are for this SG – we should to put metrics into

the PAR. • We should measure up to, but not including 4-way handshake • Document 11-03-440 slide 9 has criteria for fast handoff – should we use

this as a basis for selection criteria? Do we add information to support TGe flow control?

• The solution must meet security requirements and QoS requirements • Chair proposes that we move to the PAR description discussion:

• Do want to resolve the roaming problem within the ESS? We can define it. • We should scope it to within an ESS

• Document number 868: Reaffirm the FR/FH: • MOTION: Request the IEEE 802.11 Working Group to extend the Fast Roaming/Fast

Handoff Study Group for another 6 months • By: Mike Morton • Second: Nancy Can Winget

Discussion: None. • MOTION TO AMMEND: Remove the term Fast Handoff

• By: Dave Nelson • Second: Henry Ptasinski

Discussion: None Result: Motion passes unanimously • MOTION: Request the IEEE 802.11 Working Group to extend the Fast Roaming

Study Group for another 6 months • By: Mike Morton • Second: Nancy Cam Winget

Discussion: None Result: For- 46, Against- 0, Abstain- 6 - Motion passes 46-0-6 • Further Discussion on the PAR

• Need to create list of key issues that are going to be resolved in the PAR • The study group should simply state the problem – the task group define the solution

criteria and metrics • We need to exactly define what the problem is in order for the PAR to progress

quickly • We’ve defined two criteria:

• “fastness” of roaming • limited to roaming within ESS

• Need to put bounds around the problem – the tighter we can define the problem we’re going to solve, the better off we’ll be

• We don’t know whether the existing 802.11e and 802.11i specification provide sufficient mechanisms to support the applications that we need to address (e.g. VoIP)



• We need a call for proposals for the study group. Focus should be on proposals defining the fundamental problems rather than the solution.

• The Study Group’s mandate is to understand and define the problem – we need to see more quantified results to define the problem.

• There are already preliminary documents to support that Fast Roaming is a problem – we should go back to these documents and define the problem using these data

• Should 802.11e and 802.11i be in place in order to define this problem? • We are not trying to solve 802.11e or 802.11i issues. Those task groups

should solve their own problems. • Is there any data from 802.11e on how long it takes to set up flows when a

STA roams? • Does everybody believe that roaming is fast enough? Everybody has already

agreed that a problem exists. • STRAW POLL: Performance of existing roaming mechanisms are sufficient

for our most demanding application? • Response categories: Yes, No, Not enough data

Result: Yes- 2, No- 23, Not enough data- 33 • STRAW POLL: Direction in the immediate future should be to collect data?

• Response categories: Yes, No Result: Yes- 45, No- 1

• How do we want to gather the data? • We should make measurements for performance limited hardware

(embedded devices), not laptops • We need a call for measurements • Does a problem exist for fast roaming? • We need to define metrics. We need to define how we measure them. • If we do more characterization of roaming, we need to test with a broad set

of devices, not just laptops • MOTION: To adjourn for break until 10:30.

Result: Motion passes unanimously

10:00am Break – 10:30 Session

• It will take too much time to collect and interpret the data. We want to do this work as a task group, not a study group.

• One way around this problem is to define a “pre-setup” state on the Access Point – one answer is to redefine the problem

• Refine the task group objective to define a mechanism to set up state on a new AP before a roam

• This could theoretically allow a STA to re-associate with the ESS in zero time – solves the problem for fast roaming (accounting for some exceptions e.g. devices travelling at a high velocify)

• The solution to the setup state problem could cause another problem with the speed of the pre-setup on the new AP

• STRAW POLL: Define task group to define a mechanism to set up state on a new AP before a roam:

• Response categories: Yes, No



Result: Yes- 25, No- 5, Abstain- 13 • This PAR could appear to look more like 802.11f rather than a Fast Roaming PAR.

The differences are: • 802.11f provides a mechanism that is not solution specific • 802.11f works after the change STA’s have already roamed

• Should we propose a motion based on the last straw poll? No • We should define PAR and 5 criteria based on this straw poll. • Do we want to start with the proposed PAR definition by the chair as a beginning? No

discussion. • Discussion on the Proposal for PAR and 5 Criteria: Based on Doc 11-03-0771-r1

• Make the language of the PAR more explicit so that we are only solving the problem of roaming within an ESS

• Remove all references to Handoff, we are only solving Roaming • Add an explicit exclusion of an IBSS • Add an explicit statement that the solution will work for Re-association • Explicitly define roaming as part of the definition • Modify the definition to state that the STA and the new AP negotiate an initial state

before roaming • Define what the PAR refers to as state. • By adding the “negotiation” statement, we are excluding other possible solutions to

this problem by limiting the PAR definition. • The PAR should state that we are looking to resolve is initialisation of state for a STA

at a new AP prior to roaming • Scope of changes to the standard is to address the time span between when the STA

makes the decision to roam and when it completes the roaming sequence. • Do we have to limit the definition of data connectivity to passing Class 3 frames? No. • Do we have to explicitly limit the PAR definition to communications between a STA

and an AP. • Do we need to explicitly address other cases? • STRAW POLL: Should the PAR explicitly exclude negotiation of direct link setup?

• Response Categories: Yes, No, Abstain Result: Yes- 16, No- 5, Abstain- 25

• Should the PAR explicitly exclude negotiation of mesh link setup? • We shouldn’t explicitly exclude it because we don’t know what it is yet • We should declare it out of scope now because if we don’t, it introduces requirements

on this PAR • Mesh networks should not impose requirements on Fast Roaming, Fast Roaming

should impose requirements on mesh • STRAW POLL: Should the PAR explicitly be limited to only the STA-AP state?

• Response Categories: Yes, No, Abstain Result: Yes- 28, No- 1, Abstain- 17

• How far do we have to go to limit the scope for the PAR? Should we limit it to changes of the 802.11 MAC?

• Strictly speaking, we are not updating the DS state – we simply inform the DS that a STA has roamed – mesh networking should not be excluded as we understand the solution now



• Where do we draw the line? Limit it to the 802.11 MAC? The 802.11 PAR is limited to the MAC and PHY only, so by extension we are limited to the 802.11 MAC.

• Do we need to include the setup the 802.1x state between the STA and the AP? • Are we talking about the SME state as well? • We should likely include SME state in the par? • The 802.11 standard provides a mechanism for the MAC layer of a STA to

connect to the MAC layer of an AP and pass data • Can we move any type of MAC state between AP’s – this could introduce some

complex synchronization problems • Limit the scope of the PAR definition to only include negotiation for state

required for the operation of the MAC • Clint will update the PAR proposal base on this discussion – Doc 11-03-0771r2 • MOTION: To recess until 1:30pm Result: Motion passes unanimously



Tuesday November 11, 2003 1:00pm

• Call to order

• Roll call • Proposal for PAR has been updated and is on the server - doc 11-03-0771-r2

• No questions on the PAR document • Continue with the Five Criteria Discussion: Doc 11-03-0772r1

• Editorial changes to sentence wording • We should specify a metric in the 5 criteria • Do we specify metrics and definitions as part of the PAR and 5 criteria? • Could we put a mathematical model together to predict what the theoretical

roaming time and include its results as part of the PAR and 5 criteria • Could we measure number of packets exchanged and present roaming metrics as

the number of messages that are exchanged in a roaming sequence? • We want to decrease the amount of management packet transmissions to facilitate

faster data transfer – the metric could be the number of handshakes. • How do we define the number of handshakes? Before or after association • The problem is not the with theoretical time for roaming, it’s the real, measured

roaming times? And there is no consensus on the validity of test or their results. • We worded this PAR proposal to get around the specification of metrics. How do

we get closure on this PAR? Should we vote on this PAR proposal now and then introduce motions to modify the definitions?

• MOTION: Use the PAR as proposed in Doc 11-03-0771r2 as a draft to move forward

• By: Chris Hinsz • Second:

• POINT OF ORDER • The document has not be on the server for four hours • Motion is out of order Result: Motion is tabled as invalid.

• Discussion on section 6.4 of the 5 criteria: • We need a reply for the technical feasibility section of the 5 criteria – lets search

for other 5 criteria documents for appropriate response • We could state that proprietary solutions exist for fast roaming – is that good

enough description for this section? • Testing section – we should use the similar descriptions to what 802.11k and

802.11j used. • • IEEE 802.11i and IEEE 802.11k provide mechanisms that

facilitate fast roaming – however fast roaming is not part of their PAR? Do we really need this PAR?

• IEEE 802.11i and IEEE 802.11k provide mechanisms that facilitate fast roaming – however fast roaming is not part of their PAR? Do we really need to modify the standard to address Fast Roaming?

• If all the pieces are there, then isn’t it up to Wi-Fi to define the fast roaming solution? Does this group really need to exist?



• Will relative metrics will measure success as well as discrete metrics • MOTION: To adjourn for break until 4pm.

Result: Motion passes unanimously.

3:30pm Break – 4:00pm Session

• The 802.11k PAR does not include criteria or metrics as part of their definition • The 802.11i PAR simply states that they want to improve security • There are presentations on security that illustrate that the 4-way handshake and key

hierarchy are too slow for VoIP – the 4-way handshake takes too long • Don’t we want to leave metrics out of the PAR, but use metrics to compare

alternative solutions • Do we want to make a motion to decide whether we go forward? • MOTION: The outcome of the Fast Roaming Study Group is to create a PAR and 5

criteria and move to the WG to create a Task Group. • By: Fred Stivers • Second: Chris Hinsz • Discussion: None

Result: For- 20; Against- 0; Abstain- 7 – Motion passes • Next task would then be the PAR and 5 criteria • We would need two motions: one to create the draft text, and the other to move it

forward to the working group • We need to PAR document to simply explain that we want to establish a state in the

new AP to allow the roaming to occur as quickly as possible • We need to make sure that the PAR is specific enough to what we’re going to do? • The PAR wording should be more general. • Perhaps we need to start voting on changes – but first we need to accept a document

that we can vote changes into • Adhoc text modification forces us to keep revisiting the draft • Other study groups have accepted a draft and voting to move ahead until the draft is

complete • If there isn’t agreement on where we want to go, we’re not ready for a PAR • The intent with the vote is to get to the point at which we solidify the document • We then can use straw polls to do the wording • The wording that refers to “negotiating a initial state before re-association” before

roaming • Inconsistencies between PAR document and the 5 criteria – the scope is to specific

for some people – make the scope more general – not tied to a specific solution • We need to be done with the draft before the Thursday evening session in order to be

ready for a motion on Friday • Ask TGi chair to make part of their time available earlier on Thursday • Make draft available earlier than Thursday evening so that we can accept • If we miss submitting the PAR and 5 criteria • The first time that ExecCom can rule on PAR and 5 criteria for this study group is

the first day of the March session – there is a four month window



• STRAW POLL: Should we make the following changes to the existing PAR draft Doc 11-03-771r2:

1. Remove “by allowing negotiation of an initial state before reassociation” from the sentence beginning “Enhance the 802.11 Medium Access Control (MAC) layer” from section 12 (Scope of Proposed Project).

2. Replace the third sentence in section 13 with “A mechanism is needed to minimize or eliminate the time required for the set up of state with a new AP in the same ESS.”

• Response Categories: Yes, No, Abstain Result: Yes- 17, No- 0, Abstain- 6 • Draft document 11-03-0771r3 will be posted with changes as specified in this

straw poll: • MOTION: To adjourn until 7:30pm

Result: Motion passes unanimously.



Tuesday November 11, 2003 7:30pm

• Call to order • Roll call • MOTION: To adopt 11-03-772-02 as our draft 5 criteria

• By: Chris Hinsz • Second: Michael Montemurro

Discussion: None Result: For- 8, Against- 0, Abstain- 10 - Motion passes 8-0-10

• MOTION: To Recess until 9:20


9:20 Session

• MOTION: To adopt 11-03-771-03 as our draft PAR • By: Chris Hinsz • Second: Fred Stivers • Yes- 13 , No- 0, Abstain- 2

Discussion: None Result: For- 13, Against- 0, Abstain- 10 - Motion passes 13-0-10

• MOTION: To Recess until Thursday evening Result: Motion passes unanimously



Thursday November 13, 2003 7:30pm

• Call to order • Roll call • Any objections to updating header changes for PAR and Five Criteria – none • The latest draft of the PAR and Five Criteria 11-03-771r4 and 11-03-772r3 have been

update and posted on the server – the only change is the header date • PAR and 5 Criteria must be available 30 days before a plenary session • Suggestion to approve the PAR and Five Criteria now • It isn’t necessary for us to complete the PAR and Five Criteria at this meeting. The

next ExecCom meeting is in March and we have 30 days before that meeting to submit the documents.

• We want to spend time over the next couple of months to refine the wording of the submissions.

• Roaming it is a term that has been used in the cellular industry and other groups in IEEE 802. We should change the name of this group so that it can be clearly differentiated.

• MOTION: Replace roaming with re-association in the PAR and five criteria documents

• By: Mike Morton • Second: Dave Hunter

Discussion: • The idea is a good one but re-using the re-association term would be more

confusing • The roaming term is overloaded with multiple definitions, but changing the

name would simply cause multiple definitions for re-association. • How about calling it “Multiple Access Point re-association”? • Re-association is not a good term, some clients actually do an association

instead of a re-association when they move from one AP to another in an ESS.

• Fast Roaming is a term that has meaning, while fast re-association would be an entirely new term.

CALL THE QUESTION – by: Mike Morton • No Objections

Result: For- 2 , Against- 17, Abstain- 6 – Motion Fails 2-17-6 • Clint has been appointed as an interim chair for the Fast Roaming Study Group. If

anyone else would be interested in the chair’s position, see Clint if you are interested. • Any other business - None • MOTION: To Adjourn for the week.





Attendance for the Fast Roaming Study Group Nancy Cam Winget Robert Kroninger Masahiro Takagi Keiichiro Koga Thomas M. Kurihara Yu-ren Yang Stephen McCann Eleanor Hepworth Mike Moreton Gopal Krishnan Frank Ciotti Sandy Turner Takashi Aramaki Haixiang He Steve Wilson Dave Hudak Leigh Chinitz Timothy Thornton Henry Ptasinski Jeong Taek Lee Kevin Karcz Sam Guirguis D. J. Shyy Ruben Formoso Burak Baysal Pat Kelly Timothy G Wong Yaron Dyclan Chris Hinsz Haedong Lee ByungHo Chung Tomohzro Kikuma Jari Jokela Alistar Buttar Tim McGovern Areg Alimian Yonghe Liu Al Potter Leo Pluswick John Martell Fujio Watanabe Mikael Hielm Tim Moore Paul Lambert Merwyn Andrade Partha Nakasimhan Chuck Bartel Nick Petrom John Klein Fazal Abbas Michael Lemieux Roger Durand Bill Brasier Vivek Gupta Tom Alexander Alex Feldman Hidenori Aoki Rajeev Gupta Bill McIntosh Stefan Rommer Dan Harkins Patrick Mourot Cheng Hong Leo Monteban Dave Nelson Dennis Baker Jim Hauser Bill Brasier Vann Hasty Yutaka Hayakawa Vijay Patel Dorothy Stanley Yi-Jen Lung Yasuhika Inoue Cheng Hong Jon Edney Pertti Alapurann Thomas Haslestad Charles R. Wright Lee Armstrong Broady Cash Fred Stivers Daniel Jiang Balazs Czoma Bob Soranno Panakaj Karnik Justin McNew Yi-Jen Lung Carl Kain Mark Bilstad Dave Halasz Mike Tramalovicas Harry Bims Richard van Leenwen David Hunter Mathilde Benveniste Byung-Cheal Shin Ian Sherlock



Minutes of Wireless LAN Next Generation Standing Committee Meetings

Date: November10-14, 2003

Contact: Bruce Kraemer GlobespanVirata 2401 Palm Bay Road, Palm Bay, FL, 32905 Mail Stop – 62-024 Phone: 321-724-7000 Fax: 321-724-7886 e-Mail: [email protected]

Abstract Minutes of WNG SC meetings held during the IEEE 802 Plenary meeting in Albuquerque, NM from November 10 to 14, 2003. Executive Summary:

1. Update from MMAC 2. ESS Mesh presentation and motion to request that 802.11 WG form Study Group approved 3. Radio regulatory update 4. Wireless Performance Prediction presentations and and motion to request that 802.11 WG form Study Group approved 5. Wireless Interworking presentations (WIG) and plans to request study group formation in January 6. Discussion on how to establish the capability to provide ongoing security advice and maintenance support 7. Discussion on need to establish Radio Management study group in Joint meeting with TGk

Minutes of the IEEE 802.11 WNG SC, Monday 10 November, 4-6 pm. Meeting called to order by TK Tan (Philips) at 4:02 pm - 50 attendees WNG MEETING CALLED TO ORDER REVIEW OBJECTIVES FOR THIS SESSION Meeting Logistics REVIEW IEEE/802 & 802.11 POLICIES and RULES REVIEW MINUTES OF Singapore meeting doc: 0726

Motion to approve: TK Tan, Second: Steve McCann

Submission page 1 Bruce Kraemer, GlobespanVirata


No discussion, No objection to approve as presented, minutes approved unanimously Update from MMAC Inoue doc:0881

Requested Inoue–san include more detail on activities during January meeting Comment that MPHPT was beginning to consider the addition of 5.47-5.725 GHz spectrum

AGENDA Agenda presented in document 0849

No discussion, No objection to approve as presented, agenda approved unanimously Presentation on Adhoc ESS Subnet - Aoki (Panasonic) doc: 0867 Motion to form ESS Mesh study group

“Move that WNG request the 802.11 WG to forward to the 802 Executive Committee a request to form a study group for IEEE 802.11 ESS Mesh.” Move: Steve Connor; Second: Vann Hastings Yes: 38; No: 0; Abstain: 8 Motion passed

Motion to recess : TK Tan, Second: Bruce Kraemer approved without objection

WNG recessed at 5:15 pm Evening Session 7:30 – 9:30 pm Monday November 10, 2003 =============== Primary activity was scheduled to be radio regulatory update Carl Stevenson could not be located Motion to recess unitl Wednesday morning approved without objection Recessed at 7:45 pm Morning Session 8:00 – 10:00 am Wednesday November 12, 2003 =============== RR-TAG Overview Carl Stevenson doc: 18-03-0066 Motion to amend previous mesh study group motion to read. “Move that WNG request 802.11 WG to form a study group for IEEE Mesh networking” Move : Steve Connor Second; Petere Ecclesine Yes: 50; No: 0, Abstain: 9 Motion passes Presentation on Security Maintenance Clint Chaplin (Symbol) Doc: 0629r2 Suggestion to investigate WG TAG as mechanism to review ongoing security tasks



Wireless Performance Prediction WPP – Introduction & Overview Pratik Mehta (Dell) doc: 0927 WPP – Approaches to Issue Bill Mandeville (IOmetrics) doc 0928 RF Performance Testing Chris Hansen (Broadcom) doc 0933 WPP – Simulating Field Performance Jerry Carr (NewsIQ) doc: 0931 WPP – User Experience Tom Alexander (VeriWave) doc: 0930 Suggested that more user scenarios be created. WPP – Summary, Roadmap, Work Plan & Proposal Stephen Berger (TEM Consulting) doc: 0929 After all presentations were made, the motion to create a study group on wireless performance prediction was made. Move : Berger Second: Mehta passed with the result 36/14/15 Recess at 10:00 am Morning Session 8:00 – 12:30 am Thursday November 13, 2003 Morning Session 8:00 – 10:00 am Wednesday November 13, 2003 =============== Meeting called to order at 8:05 Review of agenda for the day and plans for joint meeting with TGk Presentation on WLAN Control Cheng Hong & Tan Pek-Yew (Panasonic) doc; 0843 Updated discussion on Security maintenance options Clint Chaplin no document Co-existence of Different Authentication Models Eleanor Hepworth (Siemens Roke Manor) doc: 0827 Discussion on multiple groups trying to solve same problem, each their own way Recess until 10:30 Morning Session 10:30 – 12:30 am Wednesday November 13, 2003 =============== Meeting called to order 10:35 Overview of plans to create Security Standing Committee in January and socialize concept with other task groups.




Presentation on Requirements for ESS Mesh Network Development Dave Hudak (Karlnet) doc: 0912 Question on how divergent this mesh concept is from those previously expoused Interference range typically much larger than receive range Handoff ECSG may have overlapping interest Move to joint meeting with ECSG to continue on topic of Radio Management Prsentattion on need for Radio Management The Need for Managed IEEE 802.11 Devices Harry Worstel (At&T) Minutes contained in TGk meeting minutes WNG adjourned for the week at 12:15



Publicity Committee Minutes

Date: November 11, 2003

Author: Brian Mathews AbsoluteValue Systems Melbourne, Florida, USA Phone: +1 321-259-0737 e-Mail: [email protected]

Abstract This document contains minutes from the November 2003 meeting of the 802.11/15 Publicity Committee.

1November meeting of the 802.11/15 Publicity Committee

1.1Agenda Reports from industry groups Via Licensing presentation Discussion of 802.11/15 press coverage

1.2Attendees Approximately 12 in the room, no roll call taken.

1.3Summary of Actions INDUSTRY GROUP UPDATES: Zigbee - Ed Callaway 1st draft of spec due ~2wks, release and cert. program mid '04 Zigbee Alliance providing feedback to 802.15.4 for improvements/enhancements Next meeting is next week in San Jose w/ open session Wed. afternoon with tutorials and demos No document, verbal presentation only WiMedia Alliance - Glyn Roberts Convergence arch. structure defined, to be basis for "WiMedia Common Radio Platform" Spec release and cert. program planned for Q4 '04 See document 15-03-0485r0 Wi-Fi Alliance - Bill Carney Excellent progress in certified products, new cert. pgms (11g, WPA) and WiFi Zone pgm See document 11-03-0903r0 VIA LICENSING IP POOL PRESENTATION Ron Moore of Via Licensing presented an IP pool proposal Describes a possible structure for a one-stop shop for 802.11 IP licensees/licensors See document 11-03-0882r0

Submission page 1Brian Mathews, AbsoluteValue Systems, Inc.


Submission page 2Brian Mathews, AbsoluteValue Systems, Inc.

1.4Discussion Brief discussion of press coverage. Only notable topics were WAPI situation with China and the whitepaper on PSK usage with WPA. TGi is preparing a list of points they will propose as an 802.11 position regarding WAPI. TGi is also considering if any action is needed regarding the whitepaper on PSK usage with WPA.

2References [1] IEEE 802 15-03-0485r0, WiMedia Alliance update [2] IEEE 802 11-03-0903r0, WiFi Alliance update [2] IEEE 802 11-03-0882r0, Via Licensing IP Pool presenation