doc.: ieee 802.11-04/1055r0grouper.ieee.org/groups/802/11/minutes/cons_minutes_sept... · 2013. 6....

Sept 2004 doc.: IEEE 802.11-04/1055r0

IEEE P802.11 Wireless LANs

Tentative Minutes of the IEEE P802.11 Full Working Group

Sept 13 - 17, 2004

Estrel Hotel, Berlin, Germany

9th Joint 802 Wireless Opening Plenary: Monday, Sept 13, 2004 1.1. Introduction

1.1.1. Meeting called to order by Stuart J. Kerry at 8:10AM 1.1.2. The agenda of the 87th session of 802.11 is in doc: IEEE 11-04-

818r3. This session is including 802.11, 802.15, 802.18 RREG TAG, 802.19 Coexistence TAG, 802.20 MBWA, and 802.21.

1.1.3. Secretary – Tim Godfrey 1.1.4. People attending for the first time at this meeting: 54 1.1.5. Officers and Chairs of 802.11:

Name Position Work Phone eMailIEEE 802.11 WG ChairPhilips Semiconductors, Inc., 1109 McKay Drive, M/S 48A SJ, San Jose, CA 95131-1706, USAFax:+1 (408) 474-5343 WG 1st Vice-Chair / TreasurerPolicies & TreasuryWG 2nd Vice-Chair / WNM SG ChairAttendance, Ballots, Documentation & VotingWG SecretaryMinutesWG Technical EditorStandard & Amendment(s) CoordinationWG Publicity SC ChairCommunications & Reports

Teik-Kheong "TK" Tan WNG SC Chair +1 (408) 474-5193 [email protected] Fakatselis TGe Chair +1 (321) 327-6710 [email protected] Kitchin TGe Vice-Chair & ANA Lead +1 (503) 264-2727 [email protected] Sheung Li TGj Chair +1 (408) 773-5295 [email protected] Richard H. Paine TGk Chair +1 (206) 854-8199 [email protected] Bob O'Hara TGm Chair +1 (408) 635-2025 [email protected] P. Kraemer TGn Chair +1 (321) 327-6704 [email protected] Chaplin TGr Chair +1 (408) 528-2766 [email protected] E. Eastlake 3rd TGs Chair +1 (508) 786-7554 [email protected] R. Wright TGt Chair +1 (978) 268-9202 [email protected] Stanley APF SG Chair +1 (630) 979-1572 [email protected] Armstrong WAVE SG Chair (TGp Chair Elect) +1 (617) 244-9203 [email protected] Stephen McCann WIEN SG Chair +44 (1794) 833341 [email protected]

Terry Cole +1 (512) 602-2454 [email protected]

Brian Mathews +1 (321) 259-0737 [email protected]

Harry R. Worstell +1 (973) 236-6915 [email protected]

Tim Godfrey +1 (913) 664-2544 [email protected]

Al Petrick +1 (321) 235-3423 [email protected]

IEEE 802.11 WORKING GROUP OFFICERSStuart J. Kerry +1 (408) 474-7356 [email protected]

Minutes page 1 Tim Godfrey, Conexant

Sept 2004 doc.: IEEE 802.11-04/1055r0

1.2. Review of Policies and Procedures 1.2.1. Harry Worstell (for Al Petrick) presents document 04/424r4 to the

body. 1.2.2. Review of working group officers and duties for all wireless working

groups. 1.2.3. Review of voting rights, participation requirements, and voting

token procedures. 1.2.4. Will conduct spot checks on attendance at this meeting. 1.2.5. Review of operating policies and procedures, registration, payment

of fees. 1.2.6. Review of rules against photographs, tape recording, and media

briefing. 1.2.7. Review of attendance recording process, and contact information

updating procedures. 1.2.8. Membership representation and anti-trust laws are reviewed. 1.2.9. Harry Worstell reads the following text to the body regarding IEEE

patent policy:

September 2004

Stuart J. Kerry - Philips Semiconductors, Inc.Slide 12

doc.: IEEE 802.11-04/424r4

General Agenda Information

A d b SA S d d d h 2003

6. Patents

IEEE standards may include the known use of essential patents and patent applications provided the IEEE receives assurance from the patent holder or applicant with respect to patents whose infringement is, or in the case of patent applications, potential future infringement the applicant asserts will be, unavoidable in a compliant implementation of either mandatory or optional portions of the standard [essential patents]. This assurance shall be provided without coercion and prior to approval of the standard (or reaffirmation when a patent or patent application 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 either mandatory or optional portions of the proposed IEEE standard against any person or entity complying with the standard; or

b) A statement that a license for such implementation 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

Approved by IEEE-SA Standards Board – March 2003 (Revised February 2004)


Sept 2004 doc.: IEEE 802.11-04/1055r0

September 2004

Stuart J. Kerry - Philips Semiconductors, Inc.Slide 13

doc.: IEEE 802.11-04/424r4

General Agenda Information

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-SA Standards Board Patent Committee Administrator at [email protected] or visit http://standards.ieee.org/board/pat/index.html

Approved by IEEE-SA Standards Board – March 2003 (Revised February 2004

1.2.10. Any questions on patent policy?

1.2.10.1. Clarification of wording? The chair confirms that slide’s wording is correct.

1.2.11. Review of IEEE copyright policy. 1.2.12. Review of IEEE meeting etiquette.

1.3. IP Statements (Letters of Assurance) 1.3.1. Stuart J Kerry calls for any letters of assurance related to IP for any

Working Groups represented in this joint meeting (802.11, 802.15, 802.18, 802.19, 802.20, 802.21) 1.3.1.1. Is anyone aware of any issues? 1.3.1.2. Stuart Kerry notes a previous issue regarding a patent from TI on

Mesh Networks. Stuart has sent a letter to TI per our rules. The letter has been sent 3 times without a response. Stuart will send a record of his actions to PatCom.

1.3.1.3. Stuart receives a letter from Airespace regarding 802.11K and 802.11R.

1.3.2. 1.4. Announcements

1.4.1. Social – there are 6 boats, departing every 20 minutes. Members are asked to be at the dock 15 members before boat departures. Members may exchange tickets for different boats. Boat 1 leaves at 5:45pm

1.4.2. There are 406 people in the room. 1.5. Approval of Joint Agenda

1.5.1. The agenda in document 11/04/818r3 is presented.


Sept 2004 doc.: IEEE 802.11-04/1055r0

1.5.2. Any objection to adopting the agenda? The agenda is approved with Unanimous consent.

1.6. Minutes from July 2004 Portland 1.6.1. The minutes are approved with Unanimous consent.

1.7. Review of Interim Meetings 1.7.1. Bob Heile reviews future interim meetings

1.7.1.1. January 2005 – Hyatt Monterey, California 1.7.1.2. May 2005 – Sydney Australia 1.7.1.3. September 2005 – Considering Alaska, St Louis, New York City. 1.7.1.4. January 2006 – Based on Poll in Portland, locations under

consideration are Hawaii, or Cancun 1.7.1.5. May 2006 – considering Yokohama Japan, Taiwan, Korea, Istanbul

1.8. Review of Financial and Treasury 1.8.1. John Barr presents the status of the joint treasury. 1.8.2. Document 11/1035r0. 1.8.3. Surplus after Anaheim was $82K 1.8.4. Berlin budget was for 500 attendees, with $587K income. Projected

surplus was $99k. 1.8.5. We have 672 registered so far. $712K income. Expenses have

gone up. Fixed expense was $300K, and variable expense has gone up $100 per person.

1.8.6. We project a surplus of $27K for this meeting. 1.8.7. Treasury in July had $55K balance. Recent payments to Ideal for

$10K, leaving balance of $45K. 1.9. Report of ExCom activities and plans

1.9.1. This has been presented on the reflector. 1.9.2. 802.11e to RevCom was withdrawn. 802.11t was approved. 802.11j

was sent to RevCom. 1.10. 802.21 Activities

1.10.1. Ajay Rajkumar presents 802.21 agenda for this meeting. Meeting in room ECC3. Review of session times during the week.

1.10.2. Will finalize handover requirements at this meeting. 1.10.3. Internal server is called “Handover” at 10.0.1.21 1.10.4. Document 21-04-0142

1.11. 802.20 activities 1.11.1. Jerry Upton presents the 802.20 agenda and plans for the

week. Document 802.20/04/075 1.11.2. Will use manual attendance at this meeting. 1.11.3. Will meet in room 6, and room 5 Wednesday and Thursday. 1.11.4. Reminder of affiliation statement requirements for 802.20

members. 1.11.5. Will start of technology selection process at this meeting.


Sept 2004 doc.: IEEE 802.11-04/1055r0

1.12. 802.19 activities 1.12.1. Steve Shellhammer presents the 802.19 agenda and plans.

Document 802.19/04/030. 1.12.2. Review status of 802 rules change. ExCom Letter Ballot was

approved 11: 2 : 3. The document is 19/04/0029 with votes and comments.

1.12.3. Will have comment resolution this week. Will send an updated rules document to 802 ExCom, and will have a final vote in November.

1.12.4. 802.19 has set up liaisons with 802.11, 802.15. 802.16 and 802.20 are open.

1.12.5. Will meet all day Tuesday and Wednesday this week. 1.13. 802.18 activities

1.13.1. Carl Stephenson is not in the room 1.14. 802.15 activities

1.14.1. 802.15.1 – Tom Seip 1.14.1.1. 802.15.1a Task Group updating Bluetooth specification. Completed

sponsor ballot. Results are 98% approval with 59 valid votes. There are 375 comments.

1.14.1.2. 802.15.1b is working on becoming a task group to add enhanced data rate features from BT Sig as an addendum to 802.1a. Will develop PAR and 5C this week.

1.14.2. 802.15.3a – Bob Heile 1.14.2.1. Continue in the selection process. Confirmation vote is next up for

Wednesday AM. There has been email traffic regarding the standards association. Will slightly modify procedures in 802.15.3a.

1.14.3. 802.15.3b – John Barr 1.14.3.1. Amendment to 802.15.3 standard. Have completed evaluation of

proposals for amendment. Working on drafting text. Hoping to have text for WG LB this week. Will discuss performance PAR for testing of devices.

1.14.4. 802.15.3c – Reed Fisher 1.14.4.1. MMwave PAN. Study Group. Will meet Tuesday, and work on PAR

and 5C this week. 1.14.5. 802.15.4a – Pat Kinney

1.14.5.1. Alternate PHY for 802.15.4. Addressing ranging and enhanced range and mobility. Will hear preliminary presentations from call for intent. Will complete channel model and selection document.

1.14.6. 802.15.4b – Robert Poor 1.14.6.1. 802.15.4 revision work. Developing clarifications and enhancements,

and addressing new spectrum allocations. Will work on agreeing on what changes will go into the draft. Planning to have LB after November meeting.

1.15. 802.11 activities 1.15.1. Voters Summary

1.15.1.1. Harry Worstell presents document 04/1038r0. 1.15.1.2. There are 411 voting members, 122 nearly voters, 349 aspirant

members as of Sept 10th 2004. There are 1869 names on the master


Sept 2004 doc.: IEEE 802.11-04/1055r0

attendance list. 220 participants did not respond to the audit and have lost voting rights. All nearly voting members must request voting privileges by email.

1.15.1.3. Documentation: There will be new templates for documents after this meeting. PPT, DOC and XLS. There will be cover sheets. All documents must conform to the new templates once they have been published.

1.15.1.4. The membership is responsible to alert Harry Worstell if any non-compliant documents are found, per the P&P rules. Harry cannot review every submission.

1.15.1.5. After attending a session, members must request reflector membership, or do it automatically. There are instructions on the web site.

1.15.1.6. There will be templates for requesting voting rights, and requesting reflector membership.

1.15.1.7. If any member has difficulty getting off the reflector, contact Harry Worstell or Stuart Kerry. Updating contact information on 802wirelessworld will not update reflector email information.

1.15.2. 802.11 WG Agenda 1.15.2.1. Stuart Kerry reviews the 802.11 agenda in 802.11/04/0818. 1.15.2.2. Motion to adopt the agenda

1.15.2.2.1. Colin Lanzl. 1.15.2.2.2. Second Jon Rosdahl 1.15.2.2.3. The agenda is approved with Unanimous consent

1.15.2.3. Matters arising from the minutes? 1.15.2.3.1. None

1.15.2.4. The 802.11 minutes from Portland are approved by Unanimous consent.

1.15.2.5. WG Policies and Procedures 1.15.2.5.1. No other updates

1.15.3. Task Group E – John Fakatselis 1.15.3.1. Completed a Sponsor Recirc. 183 comments were addressed and

Portland and will be worked on here. Depending on work here, we will decide when to submit to RevCom. To submit to RevCom in December, the standard must be on the agenda in October.

1.15.3.2. Ballot results for last Sponsor Recirc will be announced at the TGe meeting, and at Wednesday.

1.15.3.3. Stuart Kerry notes that TI has notified 802.11e that the acronym DLP is trademarked.

1.15.4. Task Group J – Sheung Li 1.15.4.1. Thanks for the WG and Sponsor Ballot groups for their work. Draft

1.6 has been submitted to RevCom for final approval. TGj will not meet this week.

1.15.5. Task Group K – Richard Paine 1.15.5.1. LB71 closed Saturday. 1000 comments received. Will resolve

comments this week. There are 20 categories. Will meet every day. Teleconferences are held weekly.

1.15.6. Task Group M – Bob O’Hara 1.15.6.1. Will meet most days this week. Will cover an interpretation request

and submission for country codes for areas without regulatory domains. Received submission on multirate operation that need to be corrected.

1.15.7. Task Group N – Bruce Kraemer 1.15.7.1. Will be in session all slots this week. Will begin technical proposals

this week, and conclude Thursday evening. Will be in room ECC1.


Sept 2004 doc.: IEEE 802.11-04/1055r0

1.15.8. Task Group R – Clint Chaplin 1.15.8.1. Call For Proposals last meeting, 13 responses. Proposals will be

made in November. Will deal with definitions this week. 1.15.9. Task Group S – Donald Eastlake

1.15.9.1. Document 831r3 agenda. 16 presentations this week. Terms, usage cases, scope.

1.15.10. Task Group T – Charles Wright 1.15.10.1. Since July TGT became a task group. Still listed as WPP some

places. Will appoint a full time editor, and looking for a secretary. Since Portland, have had teleconferences on metrics and test templates. Will hear technical presentations.

1.15.10.2. Stuart Kerry notes that meetings cannot proceed without a secretary. 1.15.11. WNG Standing Committee – TK Tan

1.15.11.1. Two sessions this week. Updates from liaisons. Can still schedule any new presentations.

1.15.12. SG APF – Dorothy Stanley 1.15.12.1. Access Point Functionality. Agenda in document 04/1036. Looking

for secretary. 1.15.13. WAVE SG – Lee Armstrong

1.15.13.1. Objective is to review draft. Document is fairly complete. There were requests from NesCom regarding the WAVE PAR regarding whether this was an amendment to 802.11-1999, or a later revision. There was another question about transfer of IP from ASTM and IEEE. ASTM says they will transfer rights when we are ready for ballot.

1.15.14. WIEN SG – Stephen McCann 1.15.14.1. Agenda in document 04/1015. Objectives are technical

presentations, complete PAR and 5C, Reviewing IETF internet drafts. 1.15.15. WNM SG – Harry Worstell

1.15.15.1. Will have 4 sessions, review PAR and reformat to new format. Need to appoint secretary and chair for Task Group. Will have presentations during the sessions this week.

1.15.16. WG editor – 1.15.16.1. Terry Cole is not present. No report.

1.15.17. Publicity 1.15.17.1. Greg Rasor and Al Petrick are not present. No Report.

1.16. Announcements 1.16.1. Stuart Kerry reminds the group that projectors are the

responsibility of chairs. Do not leave projectors unattended. 1.16.2. Members are advised to not leave computers unattended.

This is an open forum. 1.16.3. Bob Heile acknowledges and thanks Nanotron technologies

who have been helpful in coordinating this meeting. 1.17. Adjourn joint meeting, recess WG meetings at 9:31am

2. Wednesday Plenary Session, September 15, 2004 2.1. Opening

2.1.1. The meeting is called to order by Stuart J. Kerry at 10:30AM


Sept 2004 doc.: IEEE 802.11-04/1055r0

2.1.2. There are 460 people in the room. 2.1.3. The chair has conformed that there are 216 voters present at this

meeting as of 8:00AM today. 2.2. Agenda

2.2.1. Review of the Agenda in document 04/818r4. 2.2.2. Changes of names from WPP to TGT. 2.2.3. Added items in new business

2.2.3.1. MIMO description 2.2.3.2. APF description changes 2.2.3.3. WIEN PAR and 5C

2.3. Announcements 2.3.1. Greg Rasor is the joint chair of Publicity. Asks for inputs for publicity

group from 802.11 chairs. 2.3.2. The TGs Secretary selection will take place Thursday morning.

2.4. Letters of Assurance 2.4.1. Stuart J. Kerry asks for any new letters of assurance from the

members. 2.4.1.1. TK Tan presents a LOA on behalf of Philips regarding TGn.

2.4.2. He displays the 802.11 web site for the membership, and the IP and Patents link that shows the listing of LOA from the IEEE site. There are new postings for 802.11n that have been posted. He reviews the location of cover letters and LOA templates on the web site.

2.4.3. He reviews the web site area for IEEE SA Standards Development Online.

2.5. Attendance 2.5.1. Chairs are reminded to attend the Thursday AM CAC session 2.5.2. Harry Worstell reports on the status of the attendance list. He is still

working with members with problems with voting rights, he believes he has responded to everyone at this point.

2.6. Approval of Agenda 2.6.1. Stuart J. Kerry reviews the changes to the agenda so far. 2.6.2. Any further modification or new items?

2.6.2.1. Duncan Kitchin has sent out slides regarding motions needed to fix discrepancies on Assigned Numbers.

2.6.2.2. WAVE SG still has an outstanding request to ANA. 2.6.2.3. The ANA update is added to new business on the agenda.

2.6.3. The agenda is approved with Unanimous consent 2.7. Reports from Liaisons

2.7.1. 802.11 to 802.15.3a – Atul Garg 2.7.1.1. not present. 3rd call – liaison removed, volunteers requested.

2.7.2. 802.11 to 802.18 – Denis Kuahara


Sept 2004 doc.: IEEE 802.11-04/1055r0

2.7.2.1. 802.18 will be comments to the FCC NPRM on the unlicensed use of the TV bands. There are representatives from the incumbents working with us.

2.7.2.2. Working on resolving the case for point to multipoint systems. The comment deadline is extended to Dec 1, 2004.

2.7.2.3. Will conduct F2F meeting in October, and finalize in November plenary meeting.

2.7.2.4. Radio Regulatory group has a Study group to standardize equipment for the TV band. This SG will eventually become 802.22

2.7.3. 802.11 to 802.19 – Colin Lanzl 2.7.3.1. document 11/04/1084r1 2.7.3.2. Working on EC letter ballot on 802 P&P regarding coexistence.

ExCom voted 11/2/3 in favor of new rules. 2.7.3.3. All comment on the LB have been resolved. 2.7.3.4. The results of the LB and comments are in 19/04/29r0 2.7.3.5. Resolutions are in 19/04/33r0, changes in 19/04/32r0, minutes in

19/04/31r0 2.7.3.6. In November will present revised P&P changes, and hear technical

presentations on CA methodology. 2.7.3.7. Colin Lanzl will not participate in the future – looking for new 802.11

to 802.19 liaison. 2.7.3.8. Stuart J. Kerry requests any interested parties to contact him or the

vice-chairs, or contact by email before November. 2.7.4. 802.11 to WiFi Alliance – Bill Carney

2.7.4.1. document 11/04/1078r0 2.7.4.2. WPA2 certification initiated on Sept 1, 2004. There is an 18 month

period before it becomes mandatory. 2.7.4.3. 37 devices have been certified in the first 2 weeks. 2.7.4.4. WFA has started certification for QoS. The WMM certification based

on subset of 802.11e draft. Further features will be certified as they are rolled out.

2.7.4.5. Certification for WMM has started on Sept 8, 2004. 2.7.4.6. WFA has created interoperability certificates. It has been updated to

include WPA2 and WMM. 2.7.4.7. WFA has started a new WWAN/WiFi convergence group. 2.7.4.8. Stuart J. Kerry notes that 802.11 and WFA are coordinating future

meeting dates and locations. 2.7.5. 802.11 to JEDEC JC-61 – Tim Wakeley

2.7.5.1. document 11/04/1085r0 2.7.5.2. Norman Rangwala is new chair of JC-61 2.7.5.3. BB-RF Interface standard has been published. 2.7.5.4. MRD for interoperability has been completed. 2.7.5.5. Working on extension, adding additional clock for higher rates. 2.7.5.6. Next meeting Nov 12th in San Antonio – week before 802 plenary.

2.7.6. 802.11 to IETF – Dorothy Stanley 2.7.6.1. document 11/04/1041r0 2.7.6.2. IETF has been working on 802.11 EAP method requirements.

802.11 has requested publication as an RFC. It has been published. 2.7.6.3. CAPWAP WG is nearly complete with first output document.

Comments and feedback is requested. Taxonomy is in last call for comments.

2.7.6.4. EAP network discovery – two documents are ongoing development


Sept 2004 doc.: IEEE 802.11-04/1055r0

2.7.6.5. IETF Radius Extensions WG work is starting, drafts available for review and comments.

2.7.6.6. Stuart J. Kerry notes that meeting dates should also be coordinated between IETF and 802

2.7.7. 802.11 to MMAC – Inoue-san 2.7.7.1. document 11/04/1071r0 2.7.7.2. Japanese organization for wireless standards. Has an 802.11 WG,

maintaining ARIB STD T71, which is 802.11a compatible standard, including 802.11j

2.7.7.3. Planning to update ARIB STD T71 to include 802.11j, and support 5.470GHz band, starting in October.

2.7.7.4. Discussion 2.7.7.4.1. What are the Japanese regulations on 5.15 to 5.25?

Why is a frequency shift needed? Today the center frequency is shifted by 10Mhz compared to the US. Japan is desiring to make them the same.

2.8. Old Business 2.8.1. CAC Bonneville team

2.8.1.1. Brian has not provided an update. Will put off till Friday, or November.

2.8.1.2. Stuart requests a resolution by the November meeting opening plenary session.

2.8.2. CAC secretary’s team. 2.8.2.1. Harry has been unable to complete. 2.8.2.2. Stuart notes that the membership audit has taken priority. Harry has

done an excellent job.

2.9. New Business 2.9.1. Letter Ballot 71 results

2.9.1.1. 77% return. One email ballot from Satoshi Oyama was not received by Stuart and the vice-chairs. Since the rules require ballots be sent to the chair and vice chairs, that ballot was not counted.

2.9.1.2. 211 for, 75 against, 32 abstain. 2.9.1.3. Approval ratio 73.8%.

2.9.2. MIMO and its description 2.9.2.1. document 11/04/1097r0 2.9.2.2. Motions on the pronunciation of MIMO, either My Moe or Mee Moe.

2.9.2.2.1. Moved Sheung Li 2.9.2.2.2. Second Colin Lanzl

2.9.2.3. Discussion 2.9.2.3.1. What about the ITU phonetics? 2.9.2.3.2. Why is this necessary – everyone knows what it means,

either way. 2.9.2.3.3.

2.9.2.4. One Motion: vote for either pronunciation. 2.9.2.5. Call the question – Colin Lanzl

2.9.2.5.1. Vote: “My Moe”: 69 “Mee Moe” : 24 Abstain: 35 2.9.2.6. “My Moe” is selected as the standard pronunciation for MIMO.

2.9.3. Access Point Functionality Description changes. 2.9.3.1. document 11/04/1036r1 2.9.3.2. Background


Sept 2004 doc.: IEEE 802.11-04/1055r0

2.9.3.2.1. The purpose of APF is to add clarifying information, not define new functions. Its purpose does not support a PAR and 5 Criteria. The APF work aligns better with the activities of TGm.

2.9.3.2.2. Desire to form an Ad-Hoc group, operating under SG rules, create submission for TGm, to be provided by March 2005. Work to be reviewed in TGm and in full WG as part of TGm balloting.

2.9.3.3. Discussion 2.9.3.3.1. Stuart J. Kerry asks Bob O’Hara, TGm chair, if this could

be a subcommittee of TGm, rather than an Ad Hoc group. Bob says that is one way to conduct the group, but it wouldn’t enable operating under SG rules. A TG subcommittee would operate under TG rules.

2.9.3.3.2. The APF SG would naturally expire in November if not renewed. Bob states that this corresponds to the Chairs Ad Hoc formed to address CAPWAP comments.

2.9.3.4. On behalf of the APF SG, Move to request formation of an Ad-Hoc Group by WG Chair to create a submission to TGm. The submission will provide the text for the AP Functionality Description listed in 04/1036r1 2.9.3.4.1. Moved Dorothy Stanley, on behalf of APF SG 2.9.3.4.2. Discussion

2.9.3.4.2.1. The 802 ExCom wants to control work in the WG. Recommends following the process of SG and TG, rather than the Ad Hoc methods. This is inconsistent with 802 procedures.

2.9.3.4.2.2. The APF SG did discuss that. This is not a new process, but it has been approved by ExCom in the amended PAR of TGm.

2.9.3.4.2.3. Against this from a formal standpoint. The history of 802.11 includes an architecture, but the document is the link layer only. The issue is whether AP functionality is part of the 802.11 document. Concerned about the omission of WDS – it should also be discussed. Would prefer the text was put in some other document. It is how to implement an AP. The cleanest approach would be to make a Task Group, and write a recommended practice for AP implementations, describing what an AP does.

2.9.3.4.2.4. If the group wishes to submit to TGm, it should do it informally as an ad-hoc group. Any group of members can submit a document for consideration to a TG. Against the motion.

2.9.3.4.2.5. In favor – the preceding points are not relevant to the motion. The SG has determined that there is existing mentions of the AP in the current standard, but much is missing or implied. The place to clarify is in the current location. The APF is not creating new descriptions such as how to create an AP. All that is needed is to clarify what is already there in the current standard.

2.9.3.4.2.6. This is not an issue with 802 process. This is just a quick way to accomplish the work. There is nothing new or controversial in the process, and there is adequate procedural and technical review.

2.9.3.4.2.7. Question for the TGm chair: Does the scope of the work described in this motion fit into the scope of TGm? The TGm chair, Bob O’Hara, states that he believes it does fit in the scope of 802.11ma.


Sept 2004 doc.: IEEE 802.11-04/1055r0

2.9.3.4.2.8. This motion doesn’t have any effect. Anyone could make a submission. The only difference is that this group could have scheduled meeting time and places. In favor.

2.9.3.4.2.9. Is the goal of the ad hoc group limited to section 5.2 of the standard? Slide 9 shows the intended scope – also including 7.1.3.1.

2.9.3.4.2.10. If the SG dissolves, couldn’t those people just join the work of TGm? Was that considered? Yes, but TGm is not a place where new description can be created. The other difference is operating under TG rules rather than the preferred SG rules.

2.9.3.4.2.11. Is the issue that there are many non-voters? The intent is to have many contributors.

2.9.3.4.2.12. Against the motion. Doesn’t think WDS should be out of scope. Desires to amend motion – but not sure how to achieve the objective.

2.9.3.4.3. 5 minute recess while the chairs review the optimum wording for a revised motion

2.9.3.5. Motion to amend: Add the following text to the end of the motion: “slide 9, except for the WDS restriction” 2.9.3.5.1. Moved Dave Bagby 2.9.3.5.2. Second Colin Lanzl 2.9.3.5.3. Call the question (Colin L/ John F)

2.9.3.5.3.1. Vote on calling the question: passes 58 : 7 : 19 2.9.3.5.4. Vote on the motion to amend: passes 37 : 12 : 26

2.9.3.6. Motion as amended, on the floor: 2.9.3.7. On behalf of the APF SG, Move to request formation of an Ad-Hoc

Group by WG Chair to create a submission to TGm. The submission will provide the text for the AP Functionality Description listed in 04/1036r1, slide 9, except for the WDS restriction 2.9.3.7.1. Discussion

2.9.3.7.1.1. Notes that is in the discretion of the WG chair to allow everyone to vote.

2.9.3.7.1.2. Stuart J. Kerry has read 3.6, it does state the TG can make its own voting rules.

2.9.3.7.2. Vote on the main motion: passes 65 : 6 : 18 2.9.4. WIEN SG PAR and 5C

2.9.4.1. Background 2.9.4.1.1. As chair of WIEN SG, Stephen McCann announces that

the SG has approved the PAR and 5C. They are on the server. 2.9.4.1.2. The Group has decided to move forward and create an

amendment. It has received input from 3GPP, and reviewed IETF internet drafts. Have support of 6 companies that have contributors, and 4 operators. The WIEN SG has attempted to separate the scope from 802.21. This PAR is only to change the 802.11 MAC layer technology, and not generic solutions. Although there are interworking solutions on the market, they are proprietary. This body can create an interoperable standard.

2.9.4.2. Move to approve the PAR document IEEE 802.11-04/506r8, and 5 Criteria document IEEE 802.11-04/507r2, for the WIEN Study Group, and forward to ExCom for Approval. 2.9.4.2.1. Moved Stephen McCann on behalf of WIEN SG 2.9.4.2.2. Discussion

2.9.4.2.2.1. Resolving of the use of “Task Group” changed to “Study Group”


Sept 2004 doc.: IEEE 802.11-04/1055r0

2.9.4.2.2.2. Request to delay vote until Friday to give members time to read the PAR and 5C. The documents have been on the server since yesterday AM. The mover wishes to proceed with the vote.

2.9.4.2.3. Any objection to call the question? None 2.9.4.2.4. Vote: passes 62 : 3 : 32 (95% for) 2.9.4.2.5. Stephen McCann notes that he is a candidate for chair

of TGu. No other nominations. He is accepted by acclamation. 2.9.5. ANA Update

2.9.5.1. Background 2.9.5.1.1. The WG needs to pass motions to reconcile ANA

numbers. 2.9.5.2. Motion: Request the assigned numbers authority to assign three

Element ID codes for the use of TGk. The element IDs 51, 52 and 53 are specifically requested to be assigned. 2.9.5.2.1. Moved Jesse Walker 2.9.5.2.2. Second Richard Paine

2.9.5.3. Discussion 2.9.5.3.1. Why not wait until sponsor ballot? We don’t want any

early implementations. 2.9.5.3.2. Does Duncan support these motions? Yes, he

recommended them. 2.9.5.3.3. Any objection to remove the words “If Available”. None 2.9.5.3.4. In previous ballots we were told that drafts should not be

sent out with TBDs. It is appropriate to assign these. 2.9.5.3.5. Call the question (John) no objection

2.9.5.4. Vote on the motion: passes 66 : 2 : 9 2.9.5.5. Request the assigned numbers authority to assign one capability

information field bit for the use of TGk. Bit 12 is specifically requested to be assigned 2.9.5.5.1. Moved Jesse Walker 2.9.5.5.2. Second John F 2.9.5.5.3. Discussion

2.9.5.5.3.1. TGe has requested the bit. 2.9.5.5.3.2. In light of that, if this passes, TGe will have to

request. 2.9.5.5.3.3. The WG chair rules that this motion will be

deferred until Friday to resolve this issue. 2.9.6. The chair has re-conformed that there are 216 voters present at

this meeting. 2.10. Recess at 12:30pm

3. Friday Plenary Session, September 17, 2004 3.1. Opening

3.1.1. The meeting is called to order by Stuart J. Kerry at 8:20am. 3.2. Review of Agenda

3.2.1. 04/818r4 is on the server after the Wednesday. 3.2.2. Any modifications to the agenda?

3.2.2.1. None 3.2.3. The agenda is approved with Unanimous consent


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.3. Announcements 3.3.1. CAC teleconferences are Oct 4th. Graphics have been sent out to

the reflector. 3.3.2. Reports and minutes due by Sept 20th 3.3.3. The chair announces we have a Quorum at this meeting with 216

members, which was re-confirmed at 12:30 with 213 members. 3.3.4. The WIEN PAR approval was voted and confirmed with a Quorum

present 3.3.5. APF is looking for a chair. 3.3.6. There are 214 people in the room.

3.4. LOA 3.4.1. Airespace, Philips, and Agere have submitted LOA this week. 3.4.2. Any other LOA?

3.4.2.1. None 3.4.3. Stuart J. Kerry asks the membership if everyone understands and

adheres to the IEEE patent policy. There are no questions. There is general assent to the policy.

3.5. Review of Objectives for this session 3.5.1. We have 411 voters in 802.11. We lost 200 voters in the audit. We

now have an accurate record of voters. Members are reminded to send email to request voting rights to chair and vice chairs. Next opportunity to gain voting rights is November.

3.6. Reports 3.6.1. TGe - John Fakatselis

3.6.1.1. Report in document 04/1137. 3.6.1.2. Last SB recirc had 87% approval, with 181 comments. All comments

have been resolved. Will submit for recirculation at this meeting. 3.6.1.3. The editor has produced a new draft ready for ballot. 3.6.1.4. Discussion

3.6.1.4.1. Resolution of DLP trademark issue from TI? A comment was introduced, and was resolved by changing the acronym to DLS – Direct Link Setup.

3.6.1.4.2. What is the intention of the TG to go to RevCom? TGe will announce an ad-hoc meeting the week of Oct 17th. We will resolve comments, and have additional recirculation. In November, either we reject all comments and move to closure in February, or continue with recirculations, hoping to still meet February RevCom deadline.

3.6.2. TGj – John Kowalski 3.6.2.1. Report in 04/1145r0 3.6.2.2. Task group did not meet in Berlin 3.6.2.3. P802.11J-D1.6 has been submitted to RevCom for approval. 3.6.2.4. There are no further TGj meetings expected.

3.6.3. TGk – Richard Paine 3.6.3.1. Objectives were to process LB71. Did comment resolution. LB71

failed with less than 75%. 3.6.3.2. Started comment resolution categorization and resolution.


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.6.3.3. Working on neighbor reports, histograms, beacon reports and requests. Had 13 presentations, processed 46 comments.

3.6.3.4. Objectives for November- new Letter Ballot. 3.6.3.5. Will have ad-hoc week of 10/18 in Seattle. Will continue weekly

teleconferences. 3.6.3.6. Will continue LB71 comment resolution in November 3.6.3.7. Discussion

3.6.3.7.1. Will all LB71 comments be dealt with? Yes, the TG expects to deal with every comment.

3.6.4. TGm – Bob O’Hara 3.6.4.1. Report in document 04/1033r0 3.6.4.2. Two submissions were received. These submissions, and 18 other

work items were adopted. 3.6.4.3. Closed 2 work items, resolved 19 and sent to editor, leaving 37 work

items remaining. 3.6.4.4. November – will consider new submissions, process work items,

toward WG letter ballot in March 2005 3.6.4.5. TGm was unable to process interpretation request. Calling for

volunteers that are expert in OFDM encoding in 802.11g 3.6.4.6. See Bob O’Hara or Stuart Kerry. 3.6.4.7. Draft 0.3 of 802.11-ma revision has been created. Rollup of all

amendments including 802.11i, and comments through July session. 3.6.4.8. It will be on the 802.11 web site member private area.

3.6.5. TGn – Bruce Kraemer 3.6.5.1. Report in document 04/1081 3.6.5.2. Goal was to hear 32 presentations of proposals. 3.6.5.3. Plans for November. Agenda was not completely set. Will review

presentations first, and will move to next steps in selection procedure. Expect to have at least one vote.

3.6.6. TGr – Clint Chaplin 3.6.6.1. Report in 04/1142r0 3.6.6.2. Decided on downselect process 3.6.6.3. Gave 4 preliminary proposals, and other presentations. 3.6.6.4. Down-select process in 04/1121r2 3.6.6.5. There is a sunset provision – the group will vote to rescind PAR if

75% is not reached for a proposal. 3.6.6.6. Minutes in 1034 3.6.6.7. In November, 13 proposals will be given, and starting selection

procedure. 3.6.7. TGs – Donald Eastlake

3.6.7.1. Report in 04/1128r0 3.6.7.2. TGs elected secretary, had 16 presentations. Adopted terms and

definitions, usage models, and scope. 3.6.7.3. TGs announces that the intent is to issue CFP in January, with

proposals to be submitted before July 2005 meeting. 3.6.7.4. Goals for November. Will work on requirements and other

documents referenced in CFP. 3.6.7.5. Held joint meeting with TGr – decided that there is no need for

automatic joint meetings. Further joint meetings will be scheduled as needed.

3.6.7.6. Will have teleconferences on Wednesdays at 13:00 US Pacific time.


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.6.7.7. The WG Chair states that this WG uses only Eastern time. Donald Eastlake notes that announcements will use Eastern Time.

3.6.8. TGT – Charles Wright 3.6.8.1. Report in document 04/1025r0 3.6.8.2. Editor and Secretary were not appointed. Had 4 presentations on

general topics. 3.6.8.3. presentation of 04/1009 was a proposed framework. Document

04/1131 proposed an interpretation of 04/1009, that everyone agreed to. 3.6.8.4. Planning teleconferences starting Sept 30th at 12:00noon Eastern

time. 3.6.9. Publicity – Harry Worstell

3.6.9.1. None of the key people were present at the meeting. There were 6 people there, but no participants. The meeting was adjourned early.

3.6.10. APF SG – Dorothy Stanley 3.6.10.1. Report in document 04/1140r0 3.6.10.2. Initial work on PAR and 5C. Will use existing TGm mechanisms

instead of new TG to add informative APF text to standard. 3.6.10.3. In November, will review and refine submissions and provide status

to TGm. 3.6.10.4. Will have 2 teleconferences. 3.6.10.5. The goal is to finish work with text to TGm by March 2005, for first

TGm Letter Ballot. 3.6.10.6. This Ad Hoc Group will disappear in March 2005. 3.6.10.7. The WG chair asks for any volunteers for APF Ad Hoc Chair? None 3.6.10.8. Dorothy Stanley is appointed as APF Ad Hoc Chair by acclamation.

3.6.11. WNG – TK Tan 3.6.11.1. Report in document 04/1044r1 3.6.11.2. Had 3 submissions: DVB for wireless home networks., 11

management and control frame protection. IEEE 1588 over 802.11b, 3.6.11.3. Discussed architectural issues for next generation WLANs 3.6.11.4. Plans for November. Will issue request for proposals and ideas,

updates from liaisons, and Next Generation Requirements. 3.6.12. WIEN – Stephen McCann

3.6.12.1. Report in document 04/1112r0 3.6.12.2. Approved PAR and 5C 3.6.12.3. Reviewed IETF EAP draft 3.6.12.4. had presentations on AR identifier, network detection, and extending

802.11 MAC management. 3.6.12.5. Met as WIEN Ad Hoc committee. Reviewed IETF draft and produced

response in 04/1109r1. Will ask WG to forward to IETF. 3.6.12.6. there will be 2 minutes – one for SG and one for Ad Hoc 3.6.12.7. November meeting – will have initial requirements discussion, review

another IETF draft on EAP.

3.7. Special Orders 3.7.1. TGe Motions

3.7.1.1. Believing that the reason code 45 should be reserved and owned by TGe, Request the assigned numbers authority to assign a reason code for the use of TGe. The reason code 45 is specifically requested to be assigned, if available 3.7.1.1.1. Moved John Fakatselis on behalf of TGe 3.7.1.1.2. Vote: Approved by Unanimous consent


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.7.1.1.3. Believing that the capability information field bit 15 should be reserved and owned by TGe, Request the assigned numbers authority to assign one capability information field bit for the use of TGe. Bit 15 is specifically requested to be assigned, if available. 3.7.1.1.3.1. Moved John Fakatselis on behalf of TGe

3.7.1.1.4. Vote: Approved by Unanimous consent 3.7.1.2. Believing that the information element “QoS Action” is owned by Tge,

Request that the ANA release the 45th information element with the name “QoS Action”. Moved John Fakatselis on behalf of TGe 3.7.1.2.1. Moved John Fakatselis on behalf of TGe 3.7.1.2.2. Vote: Approved by Unanimous consent

3.7.1.3. Believing that sponsor ballot comment responses in 11-04/988R4 and the document mentioned below satisfy IEEE-SA rules for sponsor ballot recirculation, Authorize a SB recirculation of 802.11e draft 10.0, to conclude no later than 11/14/2004. 3.7.1.3.1. Moved John Fakatselis on behalf of TGe 3.7.1.3.2. Discussion

3.7.1.3.2.1. Does the WG have to authorize this? The WG chair prefers to get confirmation.

3.7.1.3.3. Vote: Approved by Unanimous consent 3.7.1.4. Believing that their work will be progressed significantly and the work

conducted per 802.11 rules, believing the ad hoc meeting will be announced at the closing plenary meeting of WG 802.11, and believing the meeting will be announced at least 30 day in advance using the WG 802.11 reflector, Announce an ad hoc meeting to be held by TGe on 10/19-20/2004 at Portland, OR. 3.7.1.4.1. Moved John Fakatselis on behalf of TGe 3.7.1.4.2. Vote: Approved by Unanimous consent

3.7.1.5. Believing that TGe will pass motions resulting in sponsor ballot comment responses and a draft that satisfies IEEE-SA rules for sponsor ballot recirculation at a duly authorized meeting conducted in good order, Conditionally authorize TGe to request a SB recirculation ballot to conclude no later than 11/15/2004, conditional on the existence of a comment response database and document by TGe meeting rules for sponsor ballot. 3.7.1.5.1. Moved John Fakatselis on behalf of TGe 3.7.1.5.2. Discussion

3.7.1.5.2.1. The last time we had a recirculation as a result of an interim meeting. Believes it would be better to recirculate after the plenary meeting. Doesn’t like having all these interim meetings in Portland.

3.7.1.5.2.2. This was discussed, delay could cost the approval 4 months. We might have the opportunity to meet the RevCom deadline. If we don’t we have to ask for Procedure 10, which is risky. If there is any issues or comments, we will still re-circulate in November.

3.7.1.5.2.3. TGe has gone on for 5 years. This is not rushed. We don’t need WG authorization for a SB recirculation.

3.7.1.5.2.4. More meetings means more time to do the work. This is the best procedure we’ve got at the current time.

3.7.1.5.2.5. This motion is about a recirculation, not about a meeting location.

3.7.1.5.2.6. Doesn’t mind the interim meeting, but wants to wait until the plenary for further recirculation.

3.7.1.5.3. Motion ID 504 3.7.1.5.4. Vote: Motion passes 62 : 1 : 15


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.7.2. TGk Motions 3.7.2.1. Move to request the Working Group to empower TGk to hold an ad

hoc meeting in Seattle the week of 10/18 as required to conduct business necessary to progress the Letter Ballot 71 comment resolution process, including creating drafts for Letter Ballot, conducting teleconferences, and handling other business necessary to progress through the IEEE standards process. 3.7.2.1.1. Moved Richard Paine on behalf of TGk 3.7.2.1.2. Discussion

3.7.2.1.2.1. Why teleconferences? For those who cannot attend the interim meeting in Seattle. The Seattle meeting will set up a teleconference for remote participants.

3.7.2.1.2.2. The WG chair notes that comment resolution is not normally open for teleconferencing. Do teleconferences give equal access to all? We have had complaints where there was not general access. There will be access for anyone who wants to participate.

3.7.2.1.2.3. Giving this meeting will not send out a LB, do we need to empower it to take votes. Richard Paine affirms that there will be no votes taken. All resolutions will be reviewed at the plenary.

3.7.2.1.2.4. Harry Worstell notes that comment resolution via teleconferences don’t work. Ad Hoc meetings with teleconferences are disruptive.

3.7.2.1.2.5. An alternative to a teleconference during the meeting would be to have set times during the meeting for teleconferences on specific comments.

3.7.2.1.2.6. The WG chair asks the TG chair to consider that option.

3.7.2.1.2.7. Clarification on what it means to not have votes. Some votes would be necessary.

3.7.2.1.2.8. Richard Paine states that a teleconference will not be conducted at this meeting.

3.7.2.1.2.9. Stuart Kerry asks if there is any objection to striking out the words “conducting teleconferences” from the motion? 3.7.2.1.2.9.1. An objection from the floor. – this motion

was made on behalf of TGk. A motion to amend 3.7.2.1.2.9.2. Question is called ( Bob O / John R) no

objection 3.7.2.1.3. Motion ID 505 3.7.2.1.4. Vote on the main motion: Passes 65 : 0 : 6

3.7.2.2. Believing that the capability information field bit 12 should be reserved and owned by TGk, Request the assigned numbers authority to assign one capability information field bit for the use of TGk. Bit 12 is specifically requested to be assigned, if available. 3.7.2.2.1. Moved Richard Paine on behalf of TGk 3.7.2.2.2. Vote: Motion approved by Unanimous consent

3.7.2.3. Believing that the management action category code 5 should be reserved and owned by TGk, Request the assigned numbers authority to assign a management action category code for the use of TGk. The category code 5 is specifically requested to be assigned, if available. 3.7.2.3.1. Moved Richard Paine on behalf of TGk 3.7.2.3.2. Discussion

3.7.2.3.2.1. What was the TGk vote? If this is a motion from TGk? Do we need a second.


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.7.2.3.2.2. This was not voted on in TGk 3.7.2.3.3. Second by Bob O’Hara 3.7.2.3.4. Vote: Motion approved by Unanimous consent

3.7.3. TGn – no motion 3.7.4. TGr – no motions 3.7.5. TGs – no motions 3.7.6. TGT – no motions 3.7.7. Publicity – no motions 3.7.8. WNG – no motions 3.7.9. APF – no motions 3.7.10. WAVE – no motions 3.7.11. WIEN – Stephen McCann

3.7.11.1. Introduction 3.7.11.1.1. The WIEN Ad Hoc committee generated the letter in

document 04/1109r1 in response to the IETF draft document ““Identity selection hints for Extensible Authentication Protocol (EAP)” (draft-adrangi-eap-network-discovery-03)”

3.7.11.1.2. Regarding network discovery using EAP. 3.7.11.1.3. The draft provides an effective solution, but we feel it

does no apply to the work to be undertaken in the 802.11 WIEN TG.

3.7.11.2. Move to request the IEEE 802.11 Working Group to approve document 11-04-1109r1 and request the IEEE 802.11 Working Group chair to forward it to the IETF. 3.7.11.2.1. Moved Stephen McCann on behalf of WIEN SG 3.7.11.2.2. Discussion

3.7.11.2.2.1. When we are asked to approve external document, we should also send a note to the reflector so the body can be aware.

3.7.11.2.2.2. The TG chair agrees, and will endeavor to comply in the future. WG chair agrees, and will bring to the CAC.

3.7.11.2.3. Vote: approved with Unanimous consent 3.7.12. WNM – Harry Worstell

3.7.12.1. Move to request the 802.11 WG chair to start a 40 day WG letter ballot for the purpose of approving the WNM SG PAR and 5 Criteria and move the forward to the 802 SEC to start a Task Group 3.7.12.1.1. Move Harry Worstell 3.7.12.1.2. Second Al Petrick 3.7.12.1.3. Discussion

3.7.12.1.3.1. The CGI-based web form for PAR has caused major problems. Request the WG to formally protest to IEEE and request that PARs are submitted and reviewed in Word DOC format.

3.7.12.1.3.2. Does it have to be 40 days? The WG states it does.

3.7.12.1.3.3. Can we add document numbers to the motion? No objections.

3.7.12.1.3.4. Will there be an opportunity to make comments? Yes, this is a WG LB. Comments on the question are in order.

3.7.12.1.3.5. Will there be comment resolution in November?


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.7.12.1.3.6. At the end of July, the PAR and 5C were brought forward and discussed. Why didn’t that get completed. The WNM formally withdrew the PAR and 5C at that time. He wanted to have a meeting where it could be discussed, rather than wordsmithing via a letter ballot process.

3.7.12.1.3.7. Suggests that a letter to the reflector would notify the body if a motion was withdrawn. The WG chair notes the comment.

3.7.12.1.3.8. In this situation where the PAR is very difficult to manipulate, can we have separate motions? We have always treated them as one package.

3.7.12.1.3.9. 3.7.12.2. Motion as modified: 3.7.12.3. Move to request the 802.11 WG chair to start a 40 day WG letter

ballot for the purpose of approving the WNM SG PAR (11-04-0537-r7) and 5 Criteria (11-04-0068r1) and move the forward to the 802 SEC to start a Task Group 3.7.12.3.1. Discussion

3.7.12.3.1.1. How will comment resolutions be handled? 3.7.12.3.2. The WNM chair requests withdrawing the motion 3.7.12.3.3. Discussion

3.7.12.3.3.1. Why are we not voting on this document. It has been on the server for 4 hours. It is not corrupted.

3.7.12.3.3.2. Some members had problems opening the document.

3.7.12.3.3.3. The WG chair follows the request of the WNM Chair and asks to withdraw the motion.

3.7.12.3.3.4. There is no need to delay – comments can be resolved in November, and results re-approved in November.

3.7.12.3.3.5. There is no requirement that any comment be address on this email ballot. This email ballot is to substitute to discuss and debate this motion today. If the motion passes, it passes.

3.7.12.3.3.6. If the comments come in, they will be duly noted, but there is no need to formally resolve. Any members with objections should post to the reflector during the letter ballot process. This is not a draft. It is just asking the group a question like it was done in a meeting.

3.7.12.3.3.7. Given there is an opportunity to submit comments, it would b polite to answer them.

3.7.12.3.3.8. As we are more dependant on electronics, problems like this will occur. If we can certify that the procedure has been followed with good faith, we should make an exception to the 4 hour rule.

3.7.12.3.3.9. The WG chair respects the advice of the 802 parliamentarian.

3.7.12.3.3.10. The WG chair notes that he will lodge a formal protest of the problems with the IEEE PAR process.

3.7.12.3.4. Motion ID 507 3.7.12.3.5. Vote: Motion passes 73: 2 : 4 3.7.12.3.6. Discussion

3.7.12.3.6.1. We need a change of rules in the 4 hour rule to handle this type of issue.

3.8. Recess at 10:07 until 10:30


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.8.1. 802.18 – no motion 3.8.2. 802.19 – no motions

3.9. New Business 3.9.1. None

3.10. Reports – continued 3.10.1. WAVE SG – Lee Armstrong

3.10.1.1. Report in 04/1148r0 3.10.1.2. Have worked out process to transfer copyright from ASTM to IEEE

for existing ASTM E2213 standard. There is an agreement signed, transfer will take place when 802.11p is completed.

3.10.1.3. Will the WG have to do anything? No, this is automatic as soon as 802.11p is officially approved. It will automatically replace ASTM E2213.

3.10.1.4. 802.11p will be an amendment to the latest version of 802.11 available at the time 802.11p goes to ballot. Expected to be based on the 2003 reaffirmation.

3.10.1.5. 802.11p hopes to go to sponsor ballot in March 2005. The next revision of 802.11 takes place when there are 3 outstanding amendments. Also in 2005.

3.10.1.6. At this meeting, there was a proposal for an amendment draft that was reviewed. There are some sections that need further work.

3.10.1.7. Planning to have LB at January 2005 meeting. 3.10.1.8. Discussion

3.10.1.8.1. The process is to provide an amendment to the current standard plus all approved amendments. Yes, the current draft does consider existing amendments.

3.10.1.8.2. The SG chair will revise the report to note this. 3.10.1.8.3. What clauses are impacted? There are a number of

them. How could we get to sponsor ballot in March? It doesn’t seem possible.

3.10.1.8.4. What is the document number for the proposal for an amended draft? We cannot put a draft on the server as a SG.

3.10.1.8.5. The WG Chair requests putting it in some area. It is a draft, and must be in a private area. We will take off-line to consider how to proceed.

3.10.1.8.6. The WAVE Editor will provide the draft to any member who asks.

3.10.2. WNM – Harry Worstell 3.10.2.1. Report in document 04/1146r0 3.10.2.2. Discussed the PAR and 5C, and made some changes to reflect

comments. Will conduct LB on PAR and 5C. Had presentations from Joe Kwak.

3.10.2.3. In November, WNM will have presentations of scenarios, discuss direction of group, start requirements documents.

3.10.2.4. Discussion 3.10.2.4.1. Is there a requirements document yet? No, this work has

not started yet. Not done in the SG.

3.11. Motions 3.11.1. WG Motions

3.11.1.1. Move to empower the following TGs/SGs/AHC to hold teleconferences beginning no sooner than September 27th, 2004 and continuing as indicated below:


Sept 2004 doc.: IEEE 802.11-04/1055r0

5:00 PM5:00 PM5:00 PM4:00 PM

Development of functional specification and comparison criteria

Wednesday, September 29, 2004Wednesday, October 13, 2004Wednesday, October 27, 2004Wednesday, November 10, 2004

TG “s”

Hear presentations and discuss issues

Process letter ballot comments,Creating & Issue Draft for letter ballot

Discuss AP functionality draft text

Purpose Time (Eastern Time)

DateGroup

12:00 NoonThursday, September 30, 2004Weekly until December 1, 2004

TG “T”

11:30 AM Wednesday, September 29, 2004 Weekly until December 1, 2004

TG “k”

12:00 NoonWednesday, October 13, 2004Wednesday, November 3, 2004

APF-AHC

5:00 PM5:00 PM5:00 PM4:00 PM

Development of functional specification and comparison criteria

Wednesday, September 29, 2004Wednesday, October 13, 2004Wednesday, October 27, 2004Wednesday, November 10, 2004

TG “s”

Hear presentations and discuss issues

Process letter ballot comments,Creating & Issue Draft for letter ballot

Discuss AP functionality draft text

Purpose Time (Eastern Time)

DateGroup

12:00 NoonThursday, September 30, 2004Weekly until December 1, 2004

TG “T”

11:30 AM Wednesday, September 29, 2004 Weekly until December 1, 2004

TG “k”

12:00 NoonWednesday, October 13, 2004Wednesday, November 3, 2004

APF-AHC

3.11.1.1.1. Moved Harry Worstell 3.11.1.1.2. Second Al Petrick 3.11.1.1.3. Discussion

3.11.1.1.3.1. Need to fix one entry in July. 3.11.1.1.3.2. Change to Sept 29th – no objection. 3.11.1.1.3.3. Will this be on the web site? Will this document

be on the document server? 3.11.1.1.3.4. Harry will put this on the server no later than

Wednesday of next week. 3.11.1.1.4. Motion ID 508 3.11.1.1.5. Vote: The motion is approved with Unanimous consent

3.12. New Business 3.12.1. Point of Information

3.12.1.1. Does TGe need a motion to empower actions out of the meeting? The Ad Hoc needs to be empowered to send ballot

3.12.1.2. The motions passed for TGe are read, and the WG chairs and vice chairs rule that the meeting is duly authorized and empowered to initiate a sponsor ballot recirculation

3.12.2. Whereas the 802.11 wireless world document server is the primary access to 1000+ document for this year alone, and the linear oriented search capabilities currently provides are inadequate for this volume of document, move that 802.11 directs the 802.11 chair to arrange to have the 802wirelessworld document server enhanced to provide a) filtered sorts of documents by TG b) a jump to document number ability. These facilities to be provided ASAP, but in any case no later than the end of the November 2004 plenary meeting 3.12.2.1. Moved Dave Bagby 3.12.2.2. Second Denis Kuahara 3.12.2.3. Discussion

3.12.2.3.1. This motion empowers Stuart to expend our treasury on this software development.

3.12.2.3.2. Note that members may use a 3rd party FTP client to achieve these goals

3.12.2.3.3. The WG chair notes that the date is dilatory. We have a dispute between the WG and the contractor, and this work cannot be completed on this timescale.


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.12.2.3.4. The mover has no objection to setting another date, but doesn’t want it to be indefinite.

3.12.2.3.5. Harry Worstell is in favor of the motion, but not sure that we can promise any date to implement this.

3.12.2.3.6. 802 has almost taken this over from us. The current software was just supposed to be a first step. It is difficult to do anything with the software.

3.12.2.3.7. Stuart J. Kerry notes that the funding issue is that maintenance has to be approved by 802 ExCom. It is not a matter of our treasury.

3.12.2.3.8. In favor of similar motion. This motion references 802wirelessworld . We are not sure what the future is with our current software vendor. We should consider a more comprehensive document management system. In general, FTP is not the ideal approach for this system. Have worked with another vendor for other alliance activities.

3.12.2.3.9. The WG chair notes that the contract with the contractor is with IEEE directly. The legal department of IEEE is working with the contractor.

3.12.2.3.10. Object to the chair’s characterization of the motion as dilatory.

3.12.2.3.11. The chair notes that the date is dilatory – it cannot be achieved.

3.12.2.3.12. Dilatory means the motion is wasting time of the body. The chair has a different interpretation of dilatory.

3.12.2.3.13. We are not appraised of the full scope of issues that are being dealt with. The membership feels like we have authorized that this software be implemented, and now feels that maintenance is necessary. We need a tool that meets our needs.

3.12.2.3.14. The WG chair doesn’t want to prejudice the body, and cannot discuss legal actions.

3.12.2.3.15. Would just these two features be all that is added? If we are taking months for implementation, should we not add more of the needed features? For example, multiple downloads?

3.12.2.3.16. We have heard November cannot be met. What date could be met. Would also just drop the date totally. Would be willing to say a generic 802.11 document server. Don’t want to add more features to the list. Feels these are simple and give good value.

3.12.2.3.17. The WG chair feels that the end of the year is achievable.

3.12.3. Motion to amend: Take out 802WIrelessWorld, change the date to “the end of December, 2004”. 3.12.3.1. Moved Dave Bagby 3.12.3.2. Second Clint Chaplin 3.12.3.3. Call the question

3.12.3.3.1. Dave B/ Chris Hansen 3.12.3.3.2. Vote on calling the question: question is called 44 : 1 : 5

3.12.3.4. Vote on motion to amend: passes 49 : 0 : 3 3.12.4. Motion as amended: Whereas the 802.11 wireless world

document server is the primary access to 1000+ document for this year alone, and the linear oriented search capabilities currently provides are inadequate for this volume of document, move that 802.11 directs the 802.11 chair to arrange to have the document server enhanced to provide a) filtered sorts of documents by TG b)


Sept 2004 doc.: IEEE 802.11-04/1055r0

a jump to document number ability. These facilities to be provided ASAP, but in any case no later than the end of December 31, 2004. 3.12.4.1. Discussion on the motion as amended

3.12.5. Motion to amend: add a “C” sub task with the ability to download multiple documents. 3.12.5.1. Moved Garth Hillman 3.12.5.2. Discussion

3.12.5.2.1. This is counter to the intent of the mover to keep the task list short.

3.12.5.2.2. The mover is informed that this would not be a simple change to the software.

3.12.5.2.3. The mover withdraws the motion to amend, with the hope that this could be addressed in a future version.

3.12.5.3. Discussion on the main motion 3.12.5.3.1. Question called (Mike M/ Chris H) no objection

3.12.6. Motion on the floor: Whereas the 802.11 wireless world document server is the primary access to 1000+ document for this year alone, and the linear oriented search capabilities currently provides are inadequate for this volume of document, move that 802.11 directs the 802.11 chair to arrange to have the document server enhanced to provide a) filtered sorts of documents by TG b) a jump to document number ability. These facilities to be provided ASAP, but in any case no later than the end of December 31, 2004. 3.12.6.1. Motion ID 508 3.12.6.2. Vote on the motion: passes 47 : 0 : 0

3.12.7. Discussion 3.12.7.1. There are two ways to download – the FTP method allows for

multiple downloads now. 3.12.7.2. The WG chair states that the intent is to change the

802wirelessworld web site. 3.12.8. The working group believes that each TG should be allowed

to establish an official email reflector for discussion relating to the work of the TG, subject to the policies and procedures of the IEEE for email reflectors. 3.12.8.1. Moved Mike Moreton 3.12.8.2. Second Denis Kuahara 3.12.8.3. Discussion

3.12.8.3.1. The WG chair states that establishing extra reflectors is possible and can be done in 2 days. The WG chair objects to private information – if it concerns our business, it should be open.

3.12.8.3.2. Harry Worstell notes that the Standards Companion requires that the standards development process is completely open. Openness means everyone has access to all documents, and materially interested parties can participate.

3.12.8.3.3. Harry would prefer having a single reflector, and have members use Task Group tags in the subject lines. That would allow members to sort according to their needs.


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.12.8.3.4. The WG chair notes that we had a similar discussion last July, which was minuted.

3.12.8.3.5. Against this motion – believes that separate email reflectors requires an explicit opt-in, members might forget to subscribe and miss important information. Request that tagging message on the main reflector would be required in our WG rules. Why is there a need for separate reflectors?

3.12.8.3.6. Stuart notes that he can’t remember if we moved to modify the rules.

3.12.9. Motion to amend to: Move that the working group directs the TG/SG/AdHoc to educate their participants to utilize the 802.11 reflector for all official email reflector for discussion relating to the work of the TG, subject to the policies and procedures of the IEEE for email reflectors and utilize a tag to indicate the respective group. 3.12.9.1. Moved Jon Rosdahl 3.12.9.2. Discussion

3.12.9.2.1. Point of order – this completely changes the intent of the original motion.

3.12.9.2.2. The WG chair and Vice chair are of the opinion that this changes the original argument. Maybe a separate motion should be made?

3.12.9.2.3. The mover requests that this text be kept for a future motion.

3.12.9.2.4. The motion to amend is withdrawn 3.12.9.2.5. Whether or not an amendment is hostile doesn’t matter.

It is germane. 3.12.9.2.6. The chair has ruled, so we are back to the original

motion. 3.12.9.3.

3.12.10. Motion on the floor: The working group believes that each TG should be allowed to establish an official email reflector for discussion relating to the work of the TG, subject to the policies and procedures of the IEEE for email reflectors. 3.12.10.1. Discussion

3.12.10.1.1. In favor – members might like to not subscribe to certain topics.

3.12.10.1.2. A member requests to be added to the CAC reflector in the spirit of openness.

3.12.10.1.3. The motion should say TG/SG/Ad Hoc? 3.12.10.1.4. The mover is happy with it as is. 3.12.10.1.5. In favor – believes that separate email reflectors per task

group is more efficient. 3.12.10.1.6. It is easy to have a special reflector that combines all

TGs for those that only want one subscription. 3.12.10.1.7. Call the question ( Mike M / Clint C) no objection

3.12.10.2. Motion ID 510 3.12.10.3. Vote on the main motion: Motion passes 39 : 4 : 6

3.13. Next Meeting 3.13.1. San Antonio, TX, November 14-19, 2004, the 88th meeting of

802.11 3.13.2. The hotel reservations are open.


Sept 2004 doc.: IEEE 802.11-04/1055r0

3.13.3. The agenda has been discussed in the CAC. Each TG gets 14 hours, except for TGn and TGr with 18 hours.

3.13.4. The WG chair reviews the schedule graphic. 3.13.5. Stuart notes that the opening plenary has been changed,

according to discussions of the CAC. The Monday session will be a normal 802.11 WG session, not joint. There will be a ½ hour section for external group interchange.

3.13.6. We have 413 members. 3.13.7. Stuart notes the change for Thursday evening. There will be

no meetings Thursday night. The CAC will meet for this slot to prepare motions for the Friday sessions and Executive Committee. This meeting is open to anyone interested.

3.13.8. Discussion 3.13.8.1. Does this change for Thursday effect the 4 hour rule? Maybe there

should be a dummy session? The session hour limits do not include CAC meetings.

3.13.8.2. The agenda shows there will be Task Group sessions during the Tutorials. True. The general consensus is that there is insufficient meeting time, and concurrent TG meetings is necessary.

3.14. Adjourn at 12:05pm


September 2004 doc.: IEEE 802.11-04/1101r1

Minutes of 802.11 Task Group E, September 2004 Page 1 R. R. Miller, AT&T


Minutes of 802.11 Task Group E MAC Enhancements - QoS

Berlin, Germany

Date: September 13-17, 2004

Author: R. R. Miller AT&T Labs - Research Phone: 973-236-6920 e-mail: [email protected]

1. Monday Afternoon Session, September 13, 2004

1.1. Opening

1.1.1. Call to order 1.1.1.1. JohnF (John Fakatselis): I call the meeting to order. 1.1.1.2. Meeting convened at 4:05 pm.

1.2. Agenda

1.2.1. Review of Meeting Times 1.2.1.1. JohnF: Now and after dinner, then Tuesday and Wednesday, with Thursday as

the final opportunity to conduct business.

1.2.2. Review of the agenda 1.2.2.1. JohnF: The first order of business is the agenda (on screen). I would like to walk

you through the agenda, and subsequently approve it. I suggest the traditional items: objectives, rule review for new people, review minutes of last meeting and interim meeting, discussion of any outstanding matters, then a call for papers, followed by the comment review process. After dinner, we shall continue to review resolutions and continue with that until Thursday when we conclude. We shall also discuss the TI trademark request (adds to agenda). DLP is a trademark of TI, used with a projector product. Some of these products may use Wi-Fi, so there could be some confusion with DLP as we’ve defined it. I’d like to discuss this and make a decision on it on Thursday evening. We shall go over the proposed changes to the draft and decide how to proceed.

1.2.2.2. Srini: Is there any reason to have special orders? If we want to end early, will we be able to do that?

1.2.2.3. JohnF: Yes. We are discussing the acceptability of the agenda. Are there any questions or other items/changes that might be necessary?

1.2.2.4. Amjad: Does the agenda cover the discussions in Portland held to review comments?

1.2.2.5. JohnF: Yes that will be covered. Are there any other questions? I am going to change the agenda to reflect that the draft vote is converted to a “black” (non



scheduled) agenda item. That way, if we happen to finish early, we shall not be encumbered by a particular time when we must act. Are there any other changes? Hearing none, is there any objection to adopt the agenda? None. The agenda is approved unanimously.

1.2.3. Review Objectives for the Session 1.2.3.1. JohnF: There are about 183 comments. The team participating in resolution

covered all of the comments. The minutes of that meeting are on the server as document 1040r0. The objective for the end of the week is a clear plan to bring this to closure. We want to go to RevCom in December. To participate, we need by Oct 14 to have paperwork submitted. We shall prepare the process at the November meeting. We shall be in a position to reject new comments (if reasonable), we can submit by October 14. We will possibly have to schedule another resolution meeting. At the end of the week, after we see what comments are outstanding we shall be in a better position to develop a contingency plan. Are there any questions on what we would like to do this week.

1.2.4. Approval of the agenda 1.2.4.1. JohnF: Are there any objections to adopting the agenda as shown? None.

Hearing none, the agenda is approved.

1.2.5. Rules Review for New Members 1.2.5.1. JohnF: How many newcomers? There are four people who have not participated

before. For your information, we follow Robert’s rules to manage the process. You will see people bringing motions and then voting. Bringing motions and voting is by voting members only, but you can petition one to vote on your behalf if you are not yet a voter yourself. When we discuss a motion, you will be recognized and can share your comments, however. Any questions from new members? None.

1.2.6. Last Meeting Summary 1.2.6.1. JohnF: Last meeting we went to recirculation, got 183 comments, and had a

meeting of Sep 5th in Portland. Srini, where do we stand on approval? 1.2.6.2. Srini: 3 “no” to “yes”, one “yes” to “no”. We have still about 16 no votes, only 1

“no” voter is in the room. 1.2.6.3. JohnF: Are there any questions or inaccuracies on the minutes? None. Hearing

none, voting members is there any objection to accepting the minutes from the last Plenary meeting? None. Minutes are approved unanimously. Is there any objection to accepting the minutes from the Portland meeting. I have been notified that the Portland minutes are blocked on the server.

1.2.6.4. BobM: I will investigate the difficulty.

1.2.7. Call for Papers 1.2.7.1. Request for presentation. 1.2.7.2. JohnF: Does the paper address a specifc comment or comments? If so, it is in

order. Otherwise, please explain why you would like to present the paper. 1.2.7.3. JarkkoK: These relate to some problems we have seen with HCCA. 1.2.7.4. JohnF: I appreciate your effort to share the problem. The only way we can act

directly is a comment. As we review comments, I suggest you look in document 988r2 and see if you can fit your suggestions into the changes we are permitted to make.

1.2.7.5. Amjad: Document 03-973r1 attaches to one of my comments. 1.2.7.6. JohnF: Are there any other papers appropriate to present at this session? None.

How much time remains in the session? 20 minutes. 1.2.7.7. Are there any more papers? None.



1.3. Process

1.3.1. Review of Voting/Comment Resolution 1.3.1.1. JohnF: In Portland, resolutions were developed for every one of the comments. I

suggest we recess to review and discuss these resolutions. Identify any resolutions you would like to remove for further discussion. We shall approve as a block the ones that have not been subject to exception. I will have Amjad present his paper. Look at what he suggests. I shall then recess to allow you to look at the remaining comments. We shall build an inventory of comments we wish to act upon. At 10:30 tomorrow, I shall follow a similar pattern---depending on the number of comments involved---we will either handle them as a group or assign several ad-hoc groups to work on them in areas. Are there any questions? No. Are there any suggestions? No. Is there any objection to follow the plan I just verbalized? No objections. OK. Hearing no objection, then that’s what we’d like to do between now and Thursday evening.

1.3.2. Presentations 1.3.2.1. JohnF: Amjad are you going to take the floor?

1.3.3. Presentation of document 03/9734r1 1.3.3.1. Amjad: Document 03-973r1 is on the screen, “Signaling Acceptable Error Rate

in TSPEC”. TSPECs were originally designed for HCF operation. This issue now takes on more importance, because the current draft now allows additional use of TSPECs, not only for polling in HCF. In HCF a schedule is developed based on the TSPEC that includes the requested parameters. Anything beyond the TSPEC was optional. The idea of the TSPEC was to differentiate the way the QSTA allocates time. Originally it was based only on access parameters, but now it includes more information. My thrust is to introduce information in the TSPEC to allow differentiation of the traffic streams by the scheduler. The motivation is use of WiFi for medical applications, including life-critical applications. There is not enough information in the current TSPEC to handle this.

1.3.4. Discussion 1.3.4.1. [Discussion followed regarding utility of the suggested additional field, and

whether it could be defined with sufficient specificity]. 1.3.4.2. JohnF: The gentleman with the other paper? Were you able to find a comment

to act as a vehicle for justification of presenting your paper? Yes. I will give you some time to prepare. Is there any other business in the remaining 10 minutes?

1.3.5. Approval of Portland minutes 1.3.5.1. The minutes of the Portland ad-hoc meeting are on the server now as 1040r1,

correcting the server problem that produced the file error. These minutes are the same as before, simply resubmitted as Revision 1. Is there any objection to the material in those minutes from the members who attended the meeting? I’ll give you an opportunity to review them. I hope you’ve had enough time to accept the minutes of the ad-hoc meeting. Are there any objections to accepting these minutes? None. Accordingly, the minutes are accepted.

1.4. Closing

1.4.1. Recess 1.4.1.1. JohnF: Is there any objection to recess for dinner? Hearing no objections, we

are in recess for dinner. 1.4.1.2. Meeting closed at 5:55 pm.



2. Monday Evening Session, September 13, 2004

2.1. Opening

2.1.1. Call to order 2.1.1.1. JohnF (John Fakatselis): I call the meeting to order. 2.1.1.2. Meeting convened at 7:47 pm. (~3 people attending).

2.2. Process

2.2.1. Comment Resolution 2.2.1.1. Are there any comments/resolutions to be pulled out? No. Very well, we shall

defer further action until 10:00am Tuesday.

2.3. Closing

2.3.1. Recess 2.3.1.1. JohnF: Is there any objection to recess? Hearing none, we are recessed until

10:00 am tomorrow 2.3.1.2. Meeting closed at 7:50 pm.

3. Tuesday Morning Session, September 14, 2004

3.1. Opening

3.1.1. Call to order 3.1.1.1. JohnF (John Fakatselis): I call the meeting to order. 3.1.1.2. Meeting convened at 10:40 am.

3.2. Process

3.2.1. Comment Resolution 3.2.1.1. Does anyone have any exceptions or alternate resolutions with reference to the

results of the Portland meeting? 3.2.1.2. Srini: Based on discussions with various members, I have been notified that

lines 3,5,9,85,102,113,152,159,160,163,166,168,169,170,172,173,175,176 should be added to the exception list for alternate resolutions.

3.2.1.3. JohnF: I would like to start with the resolutions developed in Portland which have not been removed.

3.2.1.4. Srini: Many members who commented are not here. 3.2.1.5. JohnF: We shall have to continue anyway. 3.2.1.6. Srini: There are a few resolution edits I would like to suggest, based on further

thought and examination. WRT to line 87: This comment was resubmitted asking for clarification on round-up to TX-OP limit. The ad-hoc committee said comment accepted, but suggests additional language in resolution based on 001 and 002. Likewise, Under comment 152, refers to bulleted list. Had declined comment, but because QoS local multicast was removed as part of other comments. Differences between Frame and Word caused confusion about which bullets were modified with edits. In order to correct, I have



changed the resolution to a counter-resolution to the indicated text removed due to O’Hara/1 resolution. WRT to Comment Adashi/5 going back and reading, this key exchange seems to be done before the DLPT is actually set. What we should do is send a DLPT response frame with a result code to key mismatch, therefore I want to change this resolution.

3.2.1.7. JohnF: Is there any objection to accepting this resolution? None. 3.2.1.8. Srini: There is another comment identical to this: 176 Takagi/3. I would like to

refer to the resolution of the previous comment on this one as well showing as a counter.

3.2.1.9. JohnF: Are there any objections? No. Let us formally accept each one as we proceed. Is there any objection to accept 176 as shown? None. Seeing none, the comment is unanimously accepted.

3.2.1.10. JohnF: On 5 any objection to accept? No. Accepted. How about 85? Is there any objection to accept 85. None. Accepted. You will create a follow-up document, Srini?

3.2.1.11. Srini: Yes. We also discussed 152 3.2.1.12. JohnF: Is there any objection to accept 152. None. Accepted. 3.2.1.13. Srini: Next is 102. Usually I do editorial, then technical. This comment is

asking to rewrite a sentence. We accepted the comment, but there is another comment which also affects this (line 106). We accepted the first part, but not the second. The resolution deletes the sentence flagged in 102. The resolution, therefore should be changed to “Overidden… ”

3.2.1.14. JohnF: Is there any objection to accepting this? None. Accepted. Please remove113 from the exception list.

3.2.1.15. Mathilde: I would like to add 31 to the exception list. 3.2.1.16. Srini: WRT to comment 3. Relates to EDCA. Commenter asks that the backoff

be removed after a transmission failure. It seemed possible that multiple transmissions could occur. I now recommend that we change this to accept the commenter’s suggestion as it would clear a “no” vote and seems the right thing to do.

3.2.1.17. JohnF: Is there any objection to accept comment 3? None. Comment 3 as modified is accepted (backoff removed).

3.2.1.18. Srini: Another comment from Takagi (175) suggests a similar resolution. Since we accepted the previous one, I suggest we accept this one also.

3.2.1.19. JohnF: Is there any objection to accepting the resolution to comment 175 as shown on the screen? None. Accepted.

3.2.1.20. Srini: Seeing that other members of the group are now here, I would like to address some other resolutions.

3.2.1.21. JohnF: So what about the rest of the list? 3.2.1.22. Amjad: I would like to talk about a comment. 3.2.1.23. JohnF: Do you have resolutions? 3.2.1.24. Amjad: I would like to address 159, 160, 166, 168, 170, 171; I have resolutions

for all of these. 3.2.1.25. JohnF: Could you show the resolutions like Srini did? We can approve one-by-

one as Srini did. 3.2.1.26. Amjad: WRT comment 168: I don’t understand the rationale for adding the

sentence. The implementation of the scheduler should determine the service interval, rather than specifying a max or min as best. If the station tells the AP parameters it would be OK with, it seems that freedom should be preserved to choose what works best. My resolution proposal is that since the sentence was added, it should be removed.

3.2.1.27. JohnK: This was designed to correct an error in the standard related to the spacing of max and min service interval. If they are too close, it is not clear what should be done. It doesn’t have anything to do with scheduler behavior, rather just resolving and indeterminate condition that can result.



3.2.1.28. Amjad: But if max and min are widely separated, the situation is changed, and the comment doesn’t make the same sense. For example if there are long intervals reserved for power save, this sentence’s effect may not be appropriate.

3.2.1.29. Srini: 9.9.3.2 does not address power-save. I submit that this particular text does not address power save. We should avoid two separate spec references which affect power save. Hansen/11 asked to eliminate power-save reference here, and it was accepted.

3.2.1.30. Amjad: I request a Straw Poll--- “Would you favor removing the sentence “The HC uses the Max service interval for the initial scheduling only as there may be situations… “ referencing Line 12-14 on page 92 of draft in section 9.9.3.0? Would you favor retaining the sentence? No position/Abstain? Vote is 2,6,1.

3.2.1.31. JohnF: Do you have a motion? No. Let’s go back to the resolution. How many are in favor of the resolution as shown by Amjad? Vote is 0,8,4. The vote fails.

3.2.1.32. Thomas: I am disturbed that the commenter did not vote for his own resolution. This seems a waste of time.

3.2.1.33. JohnF: I can limit discussion, but not suppress it. Is there an alternate resolution?

3.2.1.34. JohnK: I would like to go back to original resolution. 3.2.1.35. JohnF: Is there any objection to limit discussion to 5 minutes? No. Discussion

is hereby limited. Is there anyone to speak against? No. Call the question. Those wishing to vote on the resolution for 168 as shown, show your tokens. Vote is 9,0,4. The vote passes.

3.2.1.36. Amjad: Does the group wish me to continue, or do you feel we are wasting time? I am a sponsor ballot commenter as well as a TGe commenter. [Group wants to continue] Very well, I draw attention to comment 169. A line in the draft said that if a TSPEC has been submitted that the station shall be awake to receive polls. The rationale was that the station might be in power-save mode. Then what takes priority, power-save or polling? The original sentence was put in to resolve an ambiguity. Removing it would re-introduce problems. It seems that if a statement was placed in the APSD clause, it would be better.

3.2.1.37. JohnF: Is there any objection to accepting Amjad’s resolution to undelete the sentence?

3.2.1.38. Srini: Maybe Amjad is correct. I would like to check clause 11.2. 3.2.1.39. JohnF: We shall give you time to check. 3.2.1.40. Srini: I object. I feel that 11.2 includes sufficient detail as it stands, and that

leaving the sentence in would produce two instances of the same behavior. 3.2.1.41. JohnF: I would like to take a formal vote on Amjad’s alternate resolution. The

vote requires 75%. Vote is 3,5,2. The vote fails. 3.2.1.42. JohnK: I move to accept the ad-hoc group’s resolution. Seconded Srini. 3.2.1.43. JohnF: Is there any discussion? Then we shall vote. Vote is 6,3,2. The vote

fails; the comment remains open. 3.2.1.44. Amjad: The next comment relates to multiple NAV, comment 170. The

discussion leading to the sponsor ballot caused the group to reach the conclusion that multiple NAVs seemed too hard to implement. Accordingly some fields were made mandatory to specify the absolute minimum needed to create a schedule that would conform to the TSPEC requirements. With respect to surplus bandwidth allowance, a field should be provided to allow the station to specify how much surplus bandwidth allowance is needed. After the 1st sponsor ballot, the group reversed its position. I want the capability to communicate the fact that I do not wish to specify a surplus bandwidth allowance.

3.2.1.45. JohnK: There is not a possibility for a schedule to be created without starving streams. I move to accept the ad-hoc team’s resolution. Seconded by TimG.

3.2.1.46. JohnF: Is there discussion on the motion?



3.2.2. Discussion on the Motion 3.2.2.1. JohnK: I call the question. Second Tim. 3.2.2.2. JohnF: We vote on calling the question. Vote is 5,5,1. Question is not called. 3.2.2.3. JohnF: Is there further discussion? No. Then we vote on accepting the ad-hoc

comment on the screen “Remove the…”. The vote is 4,6,1. The vote fails. 3.2.2.4. MathildeB: Move to accept Amjad’s resolution on screen. Jennifer seconds. 3.2.2.5. JohnK: Motion to table. Srini seconds. 3.2.2.6. JohnF: The motion is non-debatable. All those in favor for tabling please show

your voting tokens. Vote is 4,4,1 50% required, I believe. Yes, 50% required. In addition, as chair I vote in favor, making it a majority. The motion is tabled. This comment is unresolved. We have about 8 minutes remaining before lunch.

3.2.2.7. Amjad: I should move to modify the agenda to provide time to handle unresolved contents.

3.2.2.8. JohnF: The motion to table should have been a motion to postpone to another time. We could to do it 1:30-3:30 today. Suggest 8-10 Wednesday. We shall leave it open, since it was a motion to table. There is no specific time.

3.2.2.9. JohnK: Can we change the agenda? 3.2.2.10. JohnF: It would require a motion to reconsider requiring a 2/3 vote. 3.2.2.11. Srini: I move to reconsider. JohnK seconds. 3.2.2.12. JohnF: Is there any discussion on the motion? All those who wish to vote on

reconsidering the agenda show your tokens. Vote is 4,4,0 requires 2/3, motion fails. Anyone can bring the motion back when they achieve 50%.

3.3. Closing

3.3.1. Recess 3.3.1.1. JohnF: We are past time for lunch. Is there any objection to recess? Seeing

none, we are recessed until 1:30 pm. 3.3.1.2. Meeting closed at 12:37 pm.

4. Tuesday Afternoon Session, September 14, 2004

4.1. Opening

4.1.1. Call to order 4.1.1.1. JohnF (John Fakatselis): I call the meeting to order. 4.1.1.2. Meeting convened at 1:40 pm.

4.2. Process

4.2.1. Comment Resolution 4.2.1.1. JohnF: We shall continue on. Amjad had the floor. He is not here yet. Out of

the resolutions discussed in Portland, we have some exceptions. Moving on with the same order of business. I would like to see the alternate resolutions. Does anyone have alternate resolutions for those remaining on the exception list? Srini, do you want to put this on the screen?

4.2.1.2. Srini: Would Mathilde like to go first? 4.2.1.3. Mathilde: I have a time limit on my presentation.



4.2.1.4. Srini: I shall continue, then. The first comment is on line 12. The Portland group accepted the comment. The rationale was that we did a search, showing that the QAP PS Buffer State had no behavior associated with it. We received a message on the reflector asking for reconsideration.

4.2.1.5. Mathilde: I would like to offer an alternative to draft a sentence that clarifies the reason for the field. I will prepare suggested text.

4.2.1.6. JohnF: Amjad can take the floor while Mathilde and Srini compose an alternative resolution.

4.2.1.7. Amjad: On 159 and 160 a new term was introduced: “EDCAF”. Prior to that we had EDCA and HCCA as access methods for the HCF. On the surface this change looks simple, however EDCAF has a chance of being misunderstood. I suggest we name it something else other than EDCAF so as not to confuse people confusion that HCF includes both EDCA and HCCA.

4.2.1.8. Srini: EDCAF is basically a change of name for channel access function. If a new reader encounters this, it is differentiated by access function and coordination function. If the commenter feels strongly, I would accept an alternate name. This could be an editorial change.

4.2.1.9. Amjad: I move that we stick with EDCA and “EDCA function” as an alternate resolution: remove EDCAF from the draft and spell it out. The function would still appear in the draft. BobM seconds.

4.2.1.10. JohnF: Discussion limited to 5 minutes. None. We vote on accepting the proposed resolution. Vote is 3,7,2. The motion fails.

4.2.1.11. JohnF: Is there an alternate resolution for Line 162, comment 159? 4.2.1.12. JohnK: I would like to move to postpone to 8 am tomorrow. Srini seconds. 4.2.1.13. Mathilde: I do not see reason for postponing of a minor editorial comment.

Why should we delay progress? 4.2.1.14. Amjad: Move to amend. 4.2.1.15. JohnF: The motion is not amendable. 4.2.1.16. JohnK: We want to get a draft out. I call the question. Srini seconds. 4.2.1.17. JohnF: We shall vote. Vote is 7,6,0. The motion to postpone passes. 4.2.1.18. Amjad: Is there any change in the agenda as a result of this vote? 4.2.1.19. JohnF: No. 4.2.1.20. Amjad: Multiple NAVs were introduced as a compromise to handle multiple

cases where overlapping BSSs could occur. This was designed to produce additional protection for those who wish to provide the option. You only need to adopt 1 NAV, but you could implement more. The option would still be compatible with 802.11 and would provide a way to prove-in interference management without burdening all implementations.

4.2.1.21. JohnF: Is there a motion? 4.2.1.22. Mathilde: No, because information has not on the server long enough. 4.2.1.23. JohnF: Let us move to one where a clear resolution is proposed. 4.2.1.24. Amjad: I propose comment 172. 4.2.1.25. Srini: The case addressed would happen only in error. If it happens, it is

suggested that to process the error, the system would have to construct a TSPEC for a stream of unknown characteristics.

4.2.1.26. Amjad: In the past it was possible to send a single packet with the polling flag set, indicating that the MAC should produce a TSPEC “automatically”, and this was added to allow simple “round-robin” scheduling.

4.2.1.27. BobM: In Portland, Srini convinced me that as a result of the current draft provisions, possibly resulting from material that may have been removed in the past, this condition would only happen in error. Moreover, it seems that if polling is really desirable, it is reasonable to ask the client to forward a TSPEC to start the process.



4.2.1.28. Amjad: Thank you for that background. With respect to line 172. I move to accept the resolution I have produced to undelete the sentences. Second JohnK.

4.2.1.29. JohnF: Is there any discussion? No. Let us vote on Amjad’s proposed resolution. Vote is 0,9,3 Vote fails.

4.2.1.30. Srini: I move to accept the resolution as created by the ad-hoc. JohnK seconds 4.2.1.31. JohnF: Hearing no discussion, we vote. Motion passes 9,0,2. 4.2.1.32. Amjad: We should now discuss 173. This touches on my presentation of

yesterday. Rather than go through the presentation again… 4.2.1.33. JohnK: I would like to take a straw poll. “Who would be in favor of declining the

comment”. 9 votes. I move to decline the comment as per the ad-hoc group recommendations. Second Srini.

4.2.1.34. JohnF: Is there any discussion on the motion? 4.2.1.35. Amjad: The surplus bandwidth allowance is dependent on the type of PHY

being used. 4.2.1.36. JohnK: I call the question on 173. MikeP seconds. 4.2.1.37. JohnF: A vote of 75% is required. The vote is 9,3,1. The vote passes. 4.2.1.38. Srini: I wish to move to accept the responses as written in 04/988r2 with the

exception of comments 3,5,9,31,85,102,152,159,160,163,166,168,169,170, 172,173,175, and 176. Moved by Srini. Seconded by MikeP.

4.2.1.39. JohnK: Is there any discussion? None. Hearing none, is there any objection. to accepting this motion. None. The motion passes unanimously. We have 20 minutes to go.

4.2.1.40. Mathilde: I propose an alternate resolution for comment 9. Counter: add at the end of subclause h of clause 11.2.1.5 the following text: “The QAP may also provide the additional information regarding the power save buffer state by filling in the PS Buffer State subfield of the QoS Control field according to the rules in clause 7.1.4.5.7”.

4.2.1.41. Mathilde: I move that this resolution be accepted. Seconded by Srini. 4.2.1.42. JohnF: Are there any objections to accepting this motion as shown? Yes. Let

us vote. Vote is 6,6,2. The vote fails. We still have. 8, 159, 160, 163, 166, 169,170,and 31 to go. We shall recess until tomorrow morning at 8:00 am.

4.3. Closing

4.3.1. Recess 4.3.1.1. JohnF: Is there any objection to recess? Seeing none, we are recessed until

8:00 am. 4.3.1.2. Meeting closed at 3:32 pm.

5. Wednesday Morning Session, September 15, 2004

5.1. Opening




5.2. Process

5.2.1. Comment Resolution 5.2.1.1. JohnF: We have 8 comments yet to resolve. 5.2.1.2. AndrewE: I would like to bring a motion to decline one of the comments. 5.2.1.3. JohnF: You will be next after the resolutions already in progress. 5.2.1.4. JohnK: Regarding comment 159: I would like to move that the ad-hoc’s output

be accepted. 5.2.1.5. JohnF: Is there discussion on the motion? Yes. 5.2.1.6. JohnK: I call the question. Srini seconds. 5.2.1.7. JohnF: Is there any objection to calling the question? No. 5.2.1.8. JohnF: Is there any objection to accepting the motion? Yes. We shall vote.

Vote is 14,3,3. The motion passes. 5.2.1.9. Srini: Similar comment 160: Motion to accept the same resolution. Second

JohnK. 5.2.1.10. JohnF: Is there any objection to accepting the motion as shown? Yes. We

shall vote. The vote is 15,5,2 . The motion passes. 5.2.1.11. AndrewE: I wish to address comment number 9. We discussed this comment

yesterday from John Barr. The comment was asking to delete PS Buffer state, based on a case that it is redundant. However as written in the draft it is not redundant. Further, the bits are optional. The field only takes 1 reserved bit. For devices which choose not to use these bits, 6 are still reserved. I move to decline the comment on this basis with the text. “Declined for the following reasons: - the information in these bits is not provided anywhere else - the information is useful to some implementations. The QAP may also provide the additional information regarding the power save buffer state by filling in the PS Buffer State subfield of the QoS Control field

- if this feature is not used, the extra bits become reserved and thus available for later utilization

- this feature is optional and therefore represents minimal overhead to applications that do not need the capability”

5.2.1.12. Second Jennifer.

5.2.2. Discussion on the motion 5.2.2.1. JohnF: I call the question. Any objection to accepting? None. Accepted. We

now have 163,166,169,170,171 left for action. 5.2.2.2. Srini: I ask Andrew to address 163 as well, copying the previous text. 5.2.2.3. AndrewE: I wish to move that we decline comment 163 for the same reason

and with the same text as the previous. Second Mathilde. 5.2.2.4. JohnF: Is there any discussion on the motion? No. Is there any objection to

accepting the motion? No. The proposed resolution on163 is accepted unanimously.

5.2.3. Presentation of document 1093r0 5.2.3.1. Mathilde: This is an old subject dealing with NAV protection. The presentation

I wish to provide was placed on the server yesterday, document 04/1093. [Provides presentation reviewing NAV processes]

5.2.4. Discussion 5.2.4.1. TimG: If this causes no observable differences, why not allow it to be

implemented by makers privately. Why does it have to be standardized? 5.2.4.2. Srini: [Several objections]



5.2.4.3. Mathilde: I’d like a straw poll. “Who would vote for this proposal?” 3 yes, 11 no. I shall not make a motion.

5.2.4.4. JohnK: I should like to make a motion to accept the resolutions provided in the Portland comment resolution meeting to comments 31, 166, 169, 170.

5.2.4.5. JohnF: Please hold your motion temporarily.

5.3. Closing

5.3.1. Recess 5.3.1.1. Before we go forward, is there any objection to a 5 minute recess? No

objection. We are recessed. 5.3.1.2. Meeting closed at 9:40 am.

5.4. Opening


5.5. Process

5.5.1. Comment Resolution 5.5.1.1. JohnF: We shall continue on. I wanted to refresh our memory on what motions

were tabled, postponed, etc. Comment 170 was tabled. 5.5.1.2. JohnK: I move to bring back 170 from the table. Srini seconds 5.5.1.3. JohnF: Is there any objection to bringing this motion back from the table?

None. The motion is brought back from the table. 5.5.1.4. JohnK: I move to accept the resolution to comment 170 as provided from the

Portland comment resolution meeting (Document 988r2). TimG seconds. 5.5.1.5. JohnF: Is there any discussion on the motion? Yes. 5.5.1.6. JohnK. I call the question. Srini seconds. 5.5.1.7. JohnF: We shall vote on calling the question. The vote is 41,1,1. The question

is called. We shall now vote on the motion. The vote is 18,6,2. The motion passes.

5.5.1.8. JohnK: Motion to accept the resolution to comment 31 and 166 as provided from the Portland comment resolution meeting (988r2).

5.5.1.9. JohnF: Is there any objection to passing this motion? None. The motion passes unanimously.

5.6. Closing

5.6.1. Recess 5.6.1.1. Is there any objection to recessing. No objection. 5.6.1.2. Closed at 9:58 am.



6. Wednesday Afternoon Session, September 15, 2004

6.1. Opening

6.1.1. Call to order 6.1.1.1. JohnF (John Fakatselis): I call the meeting to order. 6.1.1.2. Meeting convened at 1:40 pm

6.2. Process

6.2.1. Comment Resolution 6.2.1.1. JohnF: We shall recommence with discussion of comment 169. 6.2.1.2. JohnK: I wish to move: 6.2.1.3. Decline comment Soomro/11 with the following reason: Since the commenter

of Hansen/11 has indicated his likliness to vote “yes” if the text referenced is not present, consensus will be increased by keeping this text deleted.

6.2.1.4. JohnF: This does not include technical detail. I suggest that Hansen be referenced with technical content.

6.2.1.5. JohnK: I will reword the motion: 6.2.1.6. Decline comment Soomro/11 with the following reason: The group believes

that the deleted text is already contained in 11.2.1.4 and 11.2.1.9. Srini seconds.

6.2.1.7. JohnF: Is there any discussion on this motion? No. Is there any objection to accepting this motion? No. The motion is passed unanimously.

6.2.1.8. JohnK: I would now like to address new comment 181 (regarding use of trademarked acronym “DLP”) from the chair of 802.11 using the following text:

6.2.1.9. Accepted. Instruct the editor to replace all occurrences of “protocol” with “set-up” and replace “DLP” with “DLS”. Further, instruct the editor to make relevant adjustments to the text.

6.2.1.10. JohnF: Is there a second for this motion? TimG seconds. Is there any discussion on this motion? None. Hearing none, is there any objection to accept? Yes. We shall vote on the motion. The vote is 9,2,0. The motion passes. Can we know reasons for the two “no” votes, since this may be a legal issue? One “no” voter didn’t like the new name, the other didn’t want to set a precedent for change due to such circumstances.

6.2.1.11. JohnF: Thank you for that information. 6.2.1.12. Srini: I would like to share several motions I would like to make later. 6.2.1.13. JohnF: Very well. We shall address these on Thursday. It seems like we

are technically done with our work until Thursday. I believe we are entitled to invoke Procedure 10 if necessary. Is there any other business? A gentleman has asked to present an informative paper. Is there any objection to give the gentleman 10 minutes for his paper?

6.2.2. Presentation 1080r0 6.2.2.1. Todor Cooklev provides a presentation, available on server.

6.2.3. Comment Reconsideration 6.2.3.1. Srini: I would like to request a reconsideration for a comment. 6.2.3.2. JohnF: You were the mover? 6.2.3.3. Srini: Yes. I had several discussions with the commenter, and suggest

changing the resolution. I would like to bring forward comment 5.



6.2.3.4. JohnF: This will require 2/3 vote. If it passes we can entertain a new resolution.

6.2.3.5. Srini: I move to reconsider resolution to comment Adachi/5. JohnK seconds. 6.2.3.6. JohnF: Are there any objections to reconsideration? Yes. Accordingly, we

shall vote. The vote is 7,3,0. The vote passes, the reconsideration is approved.

6.2.3.7. Srini: I wish to change the resolution to “accepted” (DLP is mentioned in the comment).

6.2.3.8. BobM: Point of information, there is no longer any DLP. 6.2.3.9. Srini: We will modify the language to take this into account. I move to accept

the resolution as now restated. JohnK seconds. 6.2.3.10. [Discussion] 6.2.3.11. JohnF: The chair calls the question. Is there any objection to accepting the

motion? Yes. We shall vote. The vote is 7,2,1. The motion passes. 6.2.3.12. Srini: I wish to reconsider comment 176 Seconded by JohnK. 6.2.3.13. [Discussion] 6.2.3.14. JohnF: Is there any objection to reconsideration. Yes. We shall vote on

reconsideration. The vote is 9,2,0. The reconsideration passes. Comment 176 is now open for reconsideration.

6.2.3.15. Srini: I would like to change the resolution to “Comment accepted. As the comment is somewhat identical to the comment Adachi/5, the editor is instructed to implement the changes in Adachi/5. ANA assigned a reason code of 45.”

6.2.3.16. BobM: I move to amend the motion to change “somewhat identical” to “somewhat similar”.

6.2.3.17. JohnF: Is there any discussion on this amendment? No. Is there any objection to accepting the amendment? The amendment is accepted, the motion is changed. The chair calls the question. Is there any discussion on the motion? No. Is there any objection to approving the motion? Yes. We shall vote. The vote is 8,1,1. The motion passes.

6.3. Closing

6.3.1. Recess 6.3.1.1. JohnF: We appear to have concluded all of the business we had planned for

today. Do I hear a motion to recess until the Thursday meeting? 6.3.1.2. JohnK: I so move. Seconded MikeP 6.3.1.3. JohnF: Is there any discussion? No. Is there any objection to recess? None.

Seeing none, we are recessed. 6.3.1.4. Meeting closed at 2:37 pm.

7. Thursday Afternoon Session, September 15, 2004

7.1. Opening

7.1.1. Call to order 7.1.1.1. JohnF (John Fakatselis): I call the meeting to order. 7.1.1.2. Meeting convened at 4:10 pm



7.2. Process

7.2.1. Comment Resolution 7.2.1.1. JohnF: Would anyone like to present a paper? Yes. But first, is there anyone

who would like to reconsider any of the resolutions produced yesterday? No. I believe that we can complete our business in this session. If so, we may be able to dispense with the evening session. We shall see about this later.

7.2.1.2. Srini: I would like to put in place a set of motions including an ANA request. 7.2.1.3. JohnF: We will cover that as soon as we hear the presenter.

7.2.2. Presentation of document 1045r2 7.2.2.1. Jarkko Kneckt presented a document 04/1045-02, HCCA TXOP handling

difficulties. [The presentation is interrupted for discussion of a correction to the specification covered in a previous comment. As a result, a motion is made to reconsider and strike the offending specification text.]

7.2.2.2. Srini: Motion: reconsider the resolution of comment Seip/8 of the original sponsor ballot (see doc:IEEE 802.11-04/546) Seconded Jennifer

7.2.2.3. JohnF: Is there any discussion on the reconsideration of this comment? No. Is there any objection to reconsidering the comment? None. Hearing none the comment is open for reconsideration.

7.2.2.4. Srini: Move to accept comment Seip/8 of the original sponsor ballot (see doc:IEEE 802.11-04/546).. second Jennifer

7.2.2.5. JohnF: Is there any discussion on the motion? None. Is there any objection to passing this motion? No. The motion passes unanimously.

7.2.2.6. JohnF: I pass the chair to Tim Godfrey for a short time [JohnF leaves at 4:37] 7.2.2.7. [Jarkko suggests changing the Q-ACK option and set EOSP in QOS CF-

POLL+CF-ACK Frame. The group agrees this should be considered as an improvement to the specification, although there is no comment to which it can be attached for immediate action. [JohnF returns 4:40 pm, reclaiming chair]

7.2.2.8. Jarkko: Pursuant to my presentation on slide 5 of document 1045/02, I would like to have a straw poll… “A QAP shall not set the EOSP bit to 1 in a QOS +CF-ACK frame that is addressed to QSTA that is different from the intended recipient of the acknowledgement”. Does the body agree with this statement and would it like to submit it to TGm for consideration? Yes-11, No-0 Abstain-1 (15 attendees present in meeting including chair).

7.2.2.9. [The following minutes were taken by Tim Godfrey, who graciously agreed to assist the TGe secretary to allow him to attend another meeting]

7.2.3. Presentation of document 957r4 7.2.3.1. Srini Kandala 7.2.3.2. Regarding submissions to ANA for specific numbers for 802.11e. 7.2.3.3. Motion: Believing that the reason code 45 should be reserved and owned by

TGe, request the assigned numbers authority to assign a reason code for the use of TGe. The reason code 45 is specifically requested to be assigned if available.

7.2.3.3.1. Moved Srini 7.2.3.3.2. Second John 7.2.3.3.3. Motion passes with Unanimous consent.

7.2.3.4. Capability Information Field 7.2.3.5. Motion: Believing that the capability information field bit 15 should be reserved

and owned by TGe, request the assigned numbers authority to assign one capability information field bit for the use of TGe. Bit 15 is specifically requested to be assigned if available.

7.2.3.5.1. Moved Srini 7.2.3.5.2. Second John K



7.2.3.5.3. Motion passes with unanimous consent 7.2.3.6. Move to request the ANA to convert the designation of bit 14 to “Delayed

Block Ack” 7.2.3.6.1. Moved Srini, 7.2.3.6.2. Second Inoue 7.2.3.6.3. Motion passes with unanimous consent

7.2.3.7. Believing that the information element “QoS Action” is owned by Tge, Request that the ANA release the 45th information element with the name “QoS Action”.

7.2.3.7.1. Moved Srini 7.2.3.7.2. Second John F 7.2.3.7.3. Motion passes with unanimous consent

7.2.4. Discussion 7.2.4.1. Tom Seip visits the meeting, and says he is satisfied with comment resolutions,

and will withdraw his “No” vote.

7.3. New Business 7.3.1.1. ANA and TI trademark issues have been resolved 7.3.1.2. No other new business

7.4. New Draft

7.4.1. P802.11e-D9.1 has been posted to the private drafts area on the server. 7.4.1.1. It contains all changes up to yesterday. 7.4.1.2. There will be one more editorial review before it is released as Draft 10. 7.4.1.3. There is one entry changed in the table. 7.4.1.4. Motion: Believing that sponsor ballot comment responses in 11-04-988r3 and

the document mentioned below satisfy IEEE-SA reuls for sponsor ballot recirculation, authorize a SB recirculation of 802.11e Draft 10.0 to conclude no later than 11/14/2004

7.4.1.4.1. Moved Srini 7.4.1.4.2. Second John

7.4.1.5. Motion to amend: change R3 to R4 to accommodate comment resolved today in this session.

7.4.1.5.1. Moved Jennifer 7.4.1.5.2. Second Mathilde

7.4.1.6. Discussion 7.4.1.6.1. Document 04-988r3 is updated to r4, containing all comment

resolutions. 7.4.1.6.2. Vote: Motion to amend passes with unanimous consent

7.4.1.7. Motion on the floor: Believing that sponsor ballot comment responses in 11-04-988r3 and the document mentioned below satisfy IEEE-SA rules for sponsor ballot recirculation, authorize a SB recirculation of 802.11e Draft 10.0 to conclude no later than 11/14/2004

7.4.1.7.1. Vote: Motion passes 15 : 0 : 0

7.4.2. Discussion 7.4.2.1. We have already announced an October meeting (In July). 7.4.2.2. Srini notes that the announcement has not been on the reflector.



7.4.2.3. We need to have a motion for a new date, at least a month from tomorrow: The week of October 18th.

7.4.2.4. Motion: Believing that their work will be progressed significantly, and the work conducted per 802.11 rules, believing the ad hoc meeting will be announced at the closing plenary meeting of WG 802.11, and believing the meeting will be announced at least 30 days in advance using the 802.11 WG reflector, announce an ad hoc meeting to be held by TGe on October 19-20, 2004 in Portland, Oregon.

7.4.2.4.1. Moved Srini 7.4.2.4.2. Second John 7.4.2.4.3. Discussion

7.4.2.4.3.1. Can we have teleconference capability? The WG chair has ruled that we should not set up teleconferences for these types of meetings.

7.4.2.4.3.2. JohnF – this motion does not preclude. If we can work it out, we will provide teleconference support.

7.4.2.4.4. Vote: Motion passes with unanimous consent. 7.4.2.5. Motion: Believing that TGe will pass motions resulting in sponsor ballot

comment responses, and a draft that satisfies IEEE-SA rules for sponsor ballot recirculation at a duly authorized meeting conducted in good order, Conditionally authorize TGe to request a SB recirculation ballot to conclude no later than 11/15/2004, conditional on the existence of a comment response database and document by TGe meeting rules for sponsor ballot.

7.4.2.5.1. Moved Srini, 7.4.2.5.2. Second John K 7.4.2.5.3. Vote: motion passes 6: 3 : 0

7.5. Closing

7.5.1. Adjourn 7.5.1.1. Is there any objection to adjourning TGe? No objection. 7.5.1.2. Closed at 6:00PM.

September 2004 doc.: IEEE802.11-04/1050-01


Minutes for the TGk September 2004 Session

Date:

September 17, 2004

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]

Minutes TGk page AirWave Wireless, Inc. 1


Monday, September 13, 2004 10:30 AM – 12:30 AM

1. Chair calls the conference to order at 10:30 AM 2. Attendance 3. Review IEEE 802 & 802.11 Policies and Rules

a. Patent Policy b. Inappropriate Topics c. Documentation – 4 hour rule for changes that are normative d. Voting e. Roberts Rules

4. Objectives for Meeting 04-739r1 a. LB71 Comment Resolution b. Produce recirc – prior to San Antonio Meeting

5. Proposed Agenda a. Comment Incorporation into new draft (D1.1) b. Technical Comment Resolution c. Next major milestone: Letter Ballot Recirc

6. Categorization and Assignment of Technical Comments Email was sent to the reflector with all comments and their categories a. Security - All b. Neighbor Report, Capability Bits, Channel Report, and PowerSave – O’Hara c. Parallel Bit, Randomization Interval d. Periodic - Kwak e. RCPI (11g) - Kwak f. Noise Histogram – Amjad Soomro g. TPC - Black h. STA - Olson i. MIB - Gray j. PICS - Black k. Editorial – Teleconferences l. Hidden Node - Black m. ANA - All n. Signal Quality - Kwak o. Miscellaneous p. Sensing Time Histogram, Bin Duration, and Bin Offset q. Ballot Comments – Barber – recheck that all comments are in master spreadsheet Comment – run 3 simultaneous comment resolution Comment – Andrew Myles states only 4 of his comments are in the comment resolution submission and he made 71. Comment – Steve Emeotte – one of his comments was not included. Comment #941 there is a comment, but it is not assigned to Steve.

7. Meeting in recess at 11:23 to work on comment resolutions in bold groups above.



Monday, September 13, 2004 1:30 PM – 3:30 PM

1. Chair calls meeting back into session at 3:07 PM 2. Motion to amend agenda to allow technical presentations – motion passes unopposed

a. Amjad Presentation – 9/13/04 10 min b. Emeott Presentation – 09/13/04 10 min

3. Technical Presentation – Proposal and Normative Text for a Scheduled Autonomous Probe Response Generation Function – Steve Emeott - 11-04/1010r0

a. Question – Why can’t I send a beacon or more beacons? Answer – Probe responses don’t have constraints of having to be sent at a certain time.

b. Question – are there benefits other than “frequency of occurrence” over normal Beacons? c. Comment – We are proactively taking measurements in advance to find out where our

best next AP is located. d. Comment – Legacy clients can probably use Beacons, but 802.11e clients may require. e. Comment – Requiring STAs to send beacons ever 10ms for every virtual AP would cause

a great deal of traffic. f. Comment – the Neighbor Table should be able to provide all the information we need.

You should know exactly when the Beacon is coming. 4. Meeting in recess until 8:00 AM tomorrow morning.



Tuesday, September 14, 2004 8:00 AM – 10:00 AM

1. Chair calls the meeting to order at 8:00 AM. 2. Review Agenda – we have added an additional session this evening

a. Review comment categories - 1048r1 – Richard has updated with missing comments • Neighbor Report/Capability Bits/Channel Report/Powersave – O-Hara • RCPI (11g) – Kwak • Noise Histogram – Amjad Soomro • Miscellaneous – Emeott – 04/1004r0

b. Technical presentation – Amjad – 20 minutes c. Technical presentation – Emeott – 15 minutes - Neighbor Report 04/1004r0 d. Vote on Teleconference Minutes e. Vote on ANA numbers f. Recess for comment category work g. Reconvene for status/presentations

3. Motion to accept agenda Motion Move to accept the agenda Moved by Amjad Seconded by Black Motion passes unopposed

4. Technical Presentation – Radar Avoidance 5GHz – Amjad - 11-04/1007r0 (PPT) a. Question – Why are you adding map information? If there is radar then it would not be in

the neighbor report. Answer – I left the map information to simplify the protocol. b. Comment – If the radar-bit is set then you should not be on the channel. Regulators will

not allow this. They only trust the AP on the channel at that time. c. Question – Have you ask the regulators? Answer – no. I must have a presentation prior to

presenting or ask the regulators. d. Comment – 802.11j has a method for this, so you probably don’t need this. e. Comment – stations don’t have the same regulatory restrictions as an AP. f. Comment – Radar avoidance is not completely addressed in 802.11h.

5. Technical Presentation – Neighbor AP Selection Criteria – Emeott - 11-04/1004r0 a. Address comment #800 b. Comment – the “unknown” case is the same as reachable. c. Question – why would a client ever want information for APs that do not match its

characteristics? d. Comment – the neighbor report should streamline the client’s process, so only querying the

APs that match you might get a response from an AP behind a column. e. Comment – the power of the neighbor report is that it is fully broadcast to all. f. Comment – it may not be appropriate to broadcast the neighbor report as often in a densely

populated wireless configuration. g. Comment – We should make the neighbor report available on association. It is likely the

neighbor report will be used for roaming. h. Comment – you could have legacy APs and 11k capable APs in your area. The legacy AP

might be your best roaming candidate, so you would want to know about APs that don’t currently match the station.



i. Comment – we should quantify the usefulness of this proposal. What is the likelihood of stations making these requests?

j. Comment – Clients can operate in multiple modes (a, b, and g) so it might need to know the capability of APs that do not match its current state.

k. Comment – the country code is not mandated to be broadcast in every beacon. This would reduce the demands of broadcasting the entire information element for every beacon.

6. Vote on teleconference Minutes Motion Move to accept minutes Portland-Berlin in document 11-04-01024r0. Moved: Kwak Seconded: Klein

Motion passes unanimously

7. Discuss ANA numbers proposed by Kitchin 8. Emeott requests a slot for technical presentation at 2:00 PM. 9. Motion to amend agenda – passes unanimously. 10. Meeting in recess at 9:27 AM for comment resolution. 11. Chair brings the meeting back into session at 12:21 PM from recess. 12. Discussion on status of working groups

a. Neighbor group has been simplified to only on focus within an ESS. We don’t need information from neighboring ESS, because we don’t support fast roaming. It is based on SSID.

i. Comment – we can only solve problems we have today. ii. Comment – The timing information is valuable for passive scans so it should not be

deleted. iii. Comment – The authors of this text will want this for fast roaming and handoff, but

they are not here. b. RCPI & Periodic

i. 94 comments and there are several sub categories ii. Simon is addressing 10

iii. PHY comments – should we present a PHY interface. iv. 40 in process and 50 are outstanding v. 3 comments which are mis-classification

c. Misc. i. 8 comments resolved

ii. Probably comments which should be handled by other groups 13. Chair wants working groups to note architectural issues.

a. Fast Handoff b. Neighbor Report

• Passive Scanning • Address 11r

14. Meeting in recess until 1:30 PM today.



Tuesday, September 14, 2004 1:30 PM – 3:30 PM

1. Letter Ballot task groups worked out of session from 1:30 PM – 2:13 PM 2. Chair brings the meeting back into session at 2:13 PM 3. Technical Presentation – No Probe Channel Report Information Element – 11-04-0976r0 – E

a. Comment – Radar is assumed to be there unless it has been probed in less than 60 seconds. b. Question – In which circumstances would 11a AP not hit every channel? c. In the US this would not be allowed. There is a differing opinion on the legality of this

submission. d. We have 3 channel lists (1) Neighbor Report, (2) Channel Report, and possibly (3) No

Probe Channel Report. e. Why wouldn’t you send all of this information in the Channel Report? You do not get

BSSID in Channel Report. 4. Meeting is in recess until 3:15 today. 5. Chair calls meeting back in session at 3:18 6. Review status of working groups

a. RCPI – 1 comment left b. Misc. – has not made much progress. c. Neighbor Report – Done – Bob will provide a list of changes to Richard

7. Add review assignments to the Agenda for tonight 8. Meeting is in recess until 7:30 PM tonight.




1. Chairperson calls meeting back in session at 7:35 2. Review Agenda 3. Technical Presentation – Comment Review – 143, 144, and 145 - Amjad Soomro

a. Comment #144 – How can we measure non 802.11 energy during CCA i. Comment – We need to decide if we need a TGk informative section where we give

use-cases for each measurement. ii. Comment - Clause 7 should only describe the frame format and Clause 11 should

describe how measurements are intended to be used iii. Comment – Pictures are worth a thousand words. We used to have a PPT which

gave a great visual clue for first time readers. iv. Comment – Other TG have not added normative text in Clause 7. v. Comment – CCA is irrelevant, because you should only be measuring when you are

not receiving. If it is a real frame, then you should not be measuring. vi. Comment – We could explicitly say physical and virtual CCA in Noise and Load.

vii. Comment – If you have multiple PHYs, it might be difficult for an 11b STA to distinguish 11g from noise.

viii. Question – what is the Noise Histogram Report measuring? Answer – it is measuring non 802.11 signals.

ix. Question – How can you measure it? Answer – through high energy. Noise is everything that is not an 802.11 frame.

x. Comment – If I heard a weak 802.11g packet from a remote AP, it would be noise. xi. Question – What is the purpose of the measurement? To measure non 802.11

energy. xii. Question – Has anyone ever tested this? Answer – Cisco purposed this..

xiii. Comment – I have tested this in the real world, but not with this particular mechanism.

b. Resolution for Comment #144 i. Fix the definition

ii. Move normative text iii. We need to fix all of our measurements moving normative text to Clause 11 with a

reference link in Clause 7. c. Comment #159 – Time Sensing Histogram d. Comment #151 – It is complex and it is not justified.

i. The mechanism uses the signals that are already present and keepst track in the 802.11 MAC.

4. New Assignments a. TPC – Klein b. STA – Myles & O’Hara c. Parallel & Randomization Interval –Black

5. Motion to recess Motion Move to recess until tomorrow at 1:30 Moved by Simon Black Seconded by Joe Kwak



Wednesday, September 15, 2004 1:30 PM – 3:30 PM

1. Chair calls the meeting to order at 1:32 2. Review Agenda 3. Review outstanding issues with comment resolution

a. Neighbor Architectural Issues i. Fast Handoff

b. Neighbor Issues i. Passive Scanning

ii. Neighbor list should work for 11r c. Histograms

i. Noise and interference d. RCPI Architectural issues e. RCPI Issues

4. Comment – we have no obligation to respond to every comment, because we did not receive 75% approval in Letter Ballot. a. We can add new things to the draft b. We are preparing for a new Letter Ballot

5. Discussion as to work approach a. 25% of the comments are simple answers do those as you process them b. Some take more time and thought, but can go in a category submission c. 25% of the comments will need to go before the group as controversial d. Comment – we can present the easy comments to the Editor and have him read through and

approve. e. Comment – we should take a holistic approach by reading all the comments and then

building an overall scheme. Chair – disagrees with this point, because we have categorized the comments and assigned to the best people to available to answer the question.

f. Comment – After reviewing the comments, there is a feeling that TPC should not be mandatory.

g. Comment – The things we can do here is decide on what is important and guide the group to resolve these important item. I worked for 3 hours in meeting time on drafting response to comments; it might not be the best use of meeting time.

h. Comment – Clause 11 seems to be where we need to focus. i. Comment – We should continue working on the process we began with a goal of producing

a draft 14 of the Letter Ballot Comment Spreadsheet. The spreadsheet should contain categories and sub categories.

6. Modified agenda a. Include architectural and detail issues relate to each group b. Hiertz Presentation c. Recess for comment category work d. Reconvene for status Motion “To accept the proposed agenda” Moved by Myles Seconded by Black




7. Simon has posted a new document “RCPI in Active Scan Procedure” – 11-04/1095r0 for some of his comment resolutions.

8. Technical Presentation – Mesh Networks – s11-04-1075r0 (PPT) - Hiertz a. Comment – You can control interference by controlling your transmit power. b. Comment – This is inverse to Noise Histogram which tries to measure non 802.11 energy.

This presentation is trying to measure 802.11 energy. c. Comment – Non network (not on the same SSID) is non 802.11 energy d. Comment – There is PeerStats table in the MIB, which can contain associated peers or

unassociated peers. There is an element of LastReceivedRCPI. 9. Discussion Comment Category

a. Add a new category Beacon Request Category b. Amjad’s category is close to Beacon Request should we combine. c. Comment – we should not merge Amjad’s with Beacon Request d. Assign comment short name for column Q

Security Neighbor Parallel Periodic RCPI Noise Histogram STA MIB PICS Editorial Hidden ANA QoS Misc Medsense Ballot Beacon

10. Meeting is in recess for comment resolution until 5:15 PM 11. Chair calls meeting back in session at 5:15 PM 12. Discussion comment resolution status

a. Comment – If we are doing a block of comments then we need submit it to the server and allow everyone to review it.

b. Comment – If we do the comments one by one then we can vote these in as we go. This would take to long.

c. Comment – We need to have high level goals, because some of these comments could impact other comments in the spreadsheet.

d. Comment – There are some big issues that we need to discuss to give us guidance. e. Chair – send a list of high-level issues that need to be addressed by the full group. Chair

will email a reminder.



Thursday, September 16, 2004 1:30 PM – 3:30 PM

1. Chairperson calls meeting to order at 1:30 PM 2. Review the Agenda

a. Review comment category work progress b. Presentations on architectural and specific issues for each category c. Architectural Down Selection d. Recess for work on comment resolution e. Reconvene for status and motions for closing plenary Motion Move to adopt the agenda – motion passes unanimously

3. Discussion regarding Steve Emeott’s comments 4. Technical Presentation – Security Comment Resolution – 1068r0 – Richard Paine

a. Discussion on Neighbor Report Comment – adding text to Neighbor Report to state that you can request within the

same SSID. Comment – If you ask for neighbors in the same SSID – it is inherent that security is

established. Comment – If I am qualified, I want to be able to pass between SSIDs. Comment – There is no concept for cross SSID roaming – only AP to AP roaming. Question – what about a multi SSID AP. Comment – Transfer this comment 741 from Security to Neighbor Report

b. Discussion on Comment 912 c. Comment – make two motions on element orders and ANA.

5. Technical Presentation – Comment Resolution Neighbor – no doc – Andrew Myles a. Discussion of ill-defined “neighbor” b. Discussion timestamp and offset fields in the Neighbor Report elements – suggest deletion

Lower Time Stamp Reference, Neighbor TBTT Offset, Beacon Interval Comment - This is very important for passive scanning and active scanning is being

phased out. Comment – We should not delete text for deletion shake, but this text does not

provide passive scanning – the station should go off and do it. Comment – Because something is poorly defined is no justification to remove. Comment – There only 2 comments that state “remove it”. Comment – All of this listening and learning is inherently inaccurate. This shortcut

will save milliseconds and most of the devices don’t have resources. Comment – Think about how long is that first time 60-90 seconds. Comment – There might be a middle ground – simplify and reword. Comment – This will help in the voice environment.

c. Discussion on BSSID information field in the Neighbor Report Element – suggest deletion Comment - The original author envisioned 100s of BSSIDs in which this element

would be useful. Comment – In an enterprise you only want information about your SSID

d. Discussion on Require a measurement report reply to a measurement request - delete 11h required a response to a measurement request, either answer request, send a

refusal indication, or send an incapable indication



Comment – a measurement request is not a request. The request is in the elements. The refusal is at the element level. It should be a two pass process.

Comment – agree, we should not ignore request. Comment – we should tighten with a response. Comment – speak in favor – we need a “I’m working on it”. The station submitting

the request (because there is a Queue of 1) you could reissue the request killing your first frame.

Comment – you echo the frame back with a 0,1,2 status Comment – you need a time limit.

e. Discussion – how do we send a management action frame to a station in power save mode? f. Should neighbor report information come from a MIB or some other interface?

Comment - There should be a MIB element to allow you to read the report and configure.

Comment - If the information is delivered over-the-air then it should not be in the MIB.

Comment - There is nothing stopping us from describing an SME MIB. Comment - The MIB in 802.11 does not have anything to do with SNMP. It is a

mechanism to talk to upper-layers. Comment - The original purpose was for SNMP management. Comment – You created it and it lives for other purposes.

g. Open Issues with Contention How do we send a management action frame to a station in power save Should neighbor repot information come from a MIB. Should we allow/expand autonomous probe responses Should we have disassociation imminent? – There is a mechanism defined in 11h

which might take some technical rework. There are 2 types of TPC in 11h (1) regulators and (2) dynamic TPC which is all about measurement.

6. Technical Presentation – RCPI Mandatory – 1095r0 – Black a. Comment – your presentation is good, but I think you should go farther. You should not

have to respond with the RCPI element. Why would you want the AP to respond with the RCPI element when it is already responding? Answer – This is consistent with what 11d is doing.

7. Meeting in recess at 3:30 until 4:00 PM



Thursday, September 16 2004 4:00 PM – 6:00 PM

1. Chairperson calls meeting to order at 4:00 PM 2. Discussion regarding Probe Request Response 3. Technical Presentation – TPC Comment Summary – 1118r0 – John Klein

a. Accept 13,19, 273 – TPC Power Adaptation b. Accept 24 c. Accept 37 d. Accept 786 e. Accept 787 – Change Table 5 to Table K2 f. Accept 821 – Now Link Margin g. Decline 740 h. Decline 941 – Do not probe element – leave it open

i. Comment – Rewrite changing the name ii. Comment – We should keep it TCP, we are making more work for our group. It

might be short sided to by pacifying the commenter. iii. Comment – The thought was 11k is measurement and TPC is control – people will

get confused iv. Comment – We are not sure on the regulation of probing. Steve is under the

impression (from his regulators) that a STA can take open channel list from the AP. v. Comment – The US military interpretation – things could be handled at a system

level. I would not worry too much about regulations until FCC has full control. i. Open 56 – Reclassified j. Open 93 – What happens when there is an 11h measurement – It may be possible for the

STA to send a refuse. i. Comment – Merging 11.6.6 (TGh) and 11.7.6 (TGk) making a single measurement

protocol (Simon Black). ii. Comment – We should deprecate all 11h measurements.

k. Open 276 – 2.4GHz and TPC i. Draft a response as to why Link Margin is a good thing

ii. How do you calibrate what you are hearing? You might get varying responses. l. Open 929 – What’s the need for Autonomous Reporting

i. No resolution m. John will produce new draft for vote.

4. Technical Presentation – Noise Histogram - Amjad – no document a. 11 Comments and 8 people commented b. Definition Issues

i. When CCA is idle ii. Noise could occur while CCA is busy

iii. RCPI measures power over 802.11 received frames c. Comment – We need to clarify the intent to measure non 802.11 energy. d. Comment – When you are measuring noise it could be 802.11 and non 802.11 energy. e. Comment – Energy is a Red Hearing. CCA includes energy detect. We should use the

NAV. f. Elements of Proposed Definition

i. Measure power while NAV not set ii. Measure while no PHY reception in progress

iii. Change PHY SAP to measure power all the time



g. Comment – create 2 new primitives (1) turn noise measurement on and (2) turn noise measurement off. Have PHY store the measurements locally and append Noise history on burst.

h. Justification Comments i. Seek volunteers to write justification

i. Modification Comments i. Decline on the basis of time dependencies.

5. Technical Presentation – Beacon Request/Report – Steve Emeott – no document a. Reporting Condition subfield

i. Complexity & number options in k4 b. Clause 7 Conditional Reporting Behavior

i. Put normative text in Clause 11 ii. Sort out a suitable averaging procedure – the requesting station should be doing the

averaging. iii. Comment – the averaging is on the Threshold.

c. Clause 11 Normative Behaviors i. Missing

d. Comment – Danger of thresholds, when you go under the threshold you report ; and when you go back over the threshold you don’t report. It could put a great deal of load on the channel.

e. Comment – It could help you find a dead spot in you WLAN. 6. Discussion on Interim meeting in Seattle schedule for the week of 10/18 7. Motion to recess – passes unopposed 8. Meeting in recess at 5:55 PM until 7:30 PM




1. Chairperson calls meeting to order at 8:00 PM 2. Motion to Update Figure 27

Motion Instruct the editor to update figure 27 to show the ANA assigned capability bits (comments 349,351, 352, 353, 355,356,360,361, 362): Moved by Simon Black Second by Amjad For: 8 Against: 0 Abstain: 1 Motion Passes at 100%

3. Motion to Adopt ANA Assignments Motion Instruct the editor to apply the ANA assigned values for action category, capabilities bit and element ids in preparing the next version of the 11k draft (comments 343, 344, 345, 347, 983, 350, 354, 347, 983, 350, 354, 357, 358, 363, 364, 365, 366, 370, 371, 372, 373, 963, 984( Moved: Amjad Soomro Seconded: Peter Ecclesin For: 8 Against: 0 Abstain: 1 Motion Passes at 100%

4. Motion to Correct Order Conflicts Motion Instruct the editor to assign appropriate order values in Table 5, Table 7, Table 9, Table 11, and Table 12 in preparing the next version of the TGk draft (comments 329, 330,332, 333): Moved: Amjad Soomro Seconded: Steve Emeotte For: 10 Against: 0 Abstain: 0 Motion Passes at 100%

5. Motion to Adopt 1095r0 Motion Instruct the editor to apply the changes described in document 04/1095r0 in preparing the next version of the TGk draft (comments 25, 27, 28, 31, 336, 337, 339, 775, 777, 942): Moved: Simon Black Seconded: Paul Gray For: 9 Against: 0 Abstain:1 Motion Passes 100%

6. Motion to Resolve TPC Comments Motion Move to accept resolutions for: decline comments 41, 280, 281.



Moved: John Klein Seconded: Steve Emeott For 8: Against: 0 Abstain:1 Comment a. Question – should we delete 280? Answer – this is an issue with TGh not our draft..

7. Motion to Resolve TPC Comment #56 Original Motion Replace paragraph 11.7.2 with the following: “All stations are responsible for maintaining an association or membership with the BSS or IBSS respectively, on the serving channel while performing measurements on on-serving channels.” Replace the sentence in 11.7.2, line 29 that states “Rather, the measuring station is responsible for maintaining data services by using Power Save notification or other techniques.” with “All stations are responsible for maintaining an association or membership with the BSS or IBSS respectively, on the serving channel while performing measurement on non-serving channels.” Moved: Ecclesine Seconded: Klein Comment a. Don’t we lose in packets with this proposal? b. We need to amend the motion, because 11. Motion to Amend Replace paragraph 11.7.2 with the following: “All stations are responsible for maintaining data services and an association or membership with the BSS or IBSS respectively, on the serving channel while performing measurements on on-serving channels.” Replace the sentence in 11.7.6, line 29 that states “Rather, the measuring station is responsible for maintaining data services by using Power Save notification or other techniques.” with “All stations are responsible for maintaining data services and an association or membership with the BSS or IBSS respectively, on the serving channel while performing measurement on non-serving channels.” Moved: Klein Seconded: Ecclesine For: 4 Against: 1 Abstain: 5 Motion to amend Passes @ 80% Comment c. Not sure this fixes the problem d. We need to amend the motion, because 11. Amended Motion



Replace paragraph 11.7.2 with the following: “All stations are responsible for maintaining data services and an association or membership with the BSS or IBSS respectively, on the serving channel while performing measurements on on-serving channels.” Replace the sentence in 11.7.6, line 29 that states “Rather, the measuring station is responsible for maintaining data services by using Power Save notification or other techniques.” with “All stations are responsible for maintaining data services and an association or membership with the BSS or IBSS respectively, on the serving channel while performing measurement on non-serving channels.” Comment e. Comment- the station may not be responsible for maintaining data services – example

during hand-off Moved: Ecclesine Seconded: Klein For: 3 Against: 5 Abstain: 3 Motion Fails

8. Motion Empowerment for Ad Hoc Meeting Motion Move to request the Working Group to empower TGk to hold an ad hoc meeting in Seattle the week of 10/18 as required to conduct business necessary to progress the Letter Ballot 72 comment resolution process, including creating drafts for Letter Ballot, conducting teleconferences, and handling other business necessary to progress through the IEEE standards process. Moved: Soomro Seconded: Kwak For: 9 Against: 0 Abstain: 1 Motion passes @ 100%

9. Empowerment for Teleconferences Motion Move to request the Working Group to empower TGk to hold weekly teleconferences (Wednesday s at 11:30am Eastern time) through 2 weeks after the San Antonio plenary as required to conduct business necessary to progress the Letter Ballot process, including creating and issuing drafts for Letter Ballots and handling other business necessary to progress through the IEEE standards process. Moved: Barber Seconded: Soomro For: 10 Against: 0 Abstain: 0 Motion passes @ 100%

10. Technical Presentation – Comment Resolution Summary RCPI - 11-04/1139r1 – Kwak a. 94 Comments b. 4 Reassigned



c. 1 Unknown d. Comment Resolutions are located 11-04/1141r0

11. Meeting adjourned until San Antonio


September 2004

Bob O'Hara, Airespace, Inc.Slide 1

doc.: IEEE 802.11-04/1033r0

Report & Minutes

802.11m ReportSeptember 2004

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Goals for September 2004

• Address interpretation request– xxx

• Develop updates to standard– Address submissions received

• 04/982• 04/985

– Continue work from spreadsheet of work items

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Submissions

• Submissions– 04/982 Non-country Regulatory Domain

Maintenance– 04/985 Clarification to 11g Multirate Support

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Proposed Agenda

• Review IEEE Patent Policy• Review interpretation request procedure• New business

– 04/982– 04/985– Interpretation Request– Continue with items from 04/801

• Adjourn

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #1 to adopt Agenda

• Moved: to adopt the agenda• Mover: Keith Amann, Richard Paine• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

IEEE-SA Standards Board Bylaws on Patents in Standards

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

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

September 2004


doc.: IEEE 802.11-04/1033r0

Report & 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

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #2

• Moved: to instruct the editor to incorporate the contents of 04/982r1 into the 11m draft

• Mover: Richard Paine, Mike Moreton• Passes: unanimously

– Note: this resolves item #103

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #3

• Motion: to instruct the editor to incorporate the text in 04/985r0 into the 11m draft.

• Mover: Mike Morton, Keith Amann• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #4

• Moved: To adopt the following as the resolution to item #43 in 04/801:– In 11.2.1.6 a), change "after" to "before".

• Moved: Keith Amann, Richard Paine• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #5• Motion: to adopt the following text as the

resolution to item #45 in 04/801:– Add the following at the end of the first paragraph of

11.2.2.1: "To maintain correct information on the power save state of other stations in an IBSS, a station needs to remain awake. If a station changes to the PS mode, it needs to assume that all other stations are in the PS mode also.“

• Moved: Richard Paine, Keith Amann• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #6

• Moved: to adopt the following as the resolution to item #58 in 04/801:– In the equation below Table G.3, change

"1<=k<=160" to "1<=k<=159“• Moved: Donald Eastlake, Keith Amann• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #7

• Moved: to adopt the following as the resolution to item #59 of 04/801:– In the equation G.4.5, change "1<=k<=80" to

"1<=k<=79“• Moved: Keith Amann, Donald Eastlake• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #8• Moved: to adopt the following as the resolution to item

#34 in 04/801:– In the penultimate paragraph of 11.2.1.1, change "To change

Power Management modes, a STA shall inform the AP through a successful frame exchange" to "To change Power Management modes, a STA shall inform the AP through a successful Data frameframe exchange". At the end of that same paragraph of 11.2.1.1, add the following text: "The Power Management bit shall not be set in any management frame.“

• Moved:• Passes:

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #9

• Moved: to adopt the following as the resolution to item #70 of 04/801:– Change

"dot11MultiDomainOperationImplemented" to dot11MultiDomainCapabilityImplemented" on pages sta_Start_Ibss_3d(8) and 3201_d\StationConfig(5) and in 14.8.2.20

• Moved: Nancy, Jesse• Passes: Unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #10

• Moved: to adopt the following as the resolution to item #62 of 04/801: – In the first paragraph of 9.3 change "a CF-Pollable STA

may transmit only one MPDU, which can be to any destination (not just to the PC)," to "a CF-Pollable STA may transmit only one MPDU, which shall be sent to the PC but may have any destination,“

• Moved: Jesse Walker, Nancy Cam-Winget• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #11

• Moved: to adopt the following as the resolution to item #99 of 04/801: – In Table 29, delete the row containing "CF-

Poll(no data){+CF-Ack} – Data(dir) – ACK“• Moved: Nancy Cam-Winget, Jesse Walker• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #12

• Moved: to adopt the following as the resolution to item #74 of 04/801:– on page 3201_d\StationConfig(5), change

"dot11AuthenticationResponseTimeout Integer nodelay;" to “dot11AuthenticationResponseTimeout TU nodelay;“

• Moved: Jesse Walker, Nancy Cam-Winget

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #13• Moved: to adopt the following as the resolution to

item #75 of 04/801:– In 14.8.2.20, change

"dot11MultiDomainOperationImplemented" to dot11MultiDomainCapabilityImplemented" and on page 3201_d\StationConfig(5), change "dot11MultiDomainOperationImplemented Boolean = true" to "dot11MultiDomainCapabilityImplemented Boolean = false"


September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #14

• Moved: to adopt the following as the resolution to item #77 of 04/801:– On pages sta_Start_Ibss_3d(8) and

ap_Start_Bss_2c(3), replace "yBytp" with "yBtp" in the decision symbol.


September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #15

• Moved: to adopt the following as the resolution to item #82 of 04/801:– In AP_Start_Bss_2c, change "operation" to

"capability“• Moved: Jesse Walker, Nancy Cam-Winget• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #16

• Moved: to adopt the following as the resolution to item #92 of 04/801:– On page sta_join_4, change

"MLMEStart.confirm" to "MLMEJoin.confirm"


September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #17

• Moved: to adopt the following as the resolution to item #87 of 04/801:– On page ap_TSF_bss_3c(3), replace "7.3.2.14"

with "7.3.2.12"• Moved: Tim Godfrey, Jesse Walker• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #18

• Moved: to adopt the following as the resolution to item #101 of 04/801:– Resolve in the same fashion as item #86 (Use

04/425r1 as a template.)• Moved: Jesse Walker, Tim Godfrey• Passes: Unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Motion #19

• Moved: to adopt the following as the resolution to item #109 of 04/801:– Add a row to Table 20, placing the next

available value in the "Status Code" column and "Association denied because the ListenInterval is too large" in the "Meaning" column.

• Moved: Tim Godfrey, Jesse Walker• Passes: unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes


item #110 of 04/801:– Above the two bold arrows at the upper right of this

figure, attach PHY_TXEND.request and PHY_TXEND.confirm, respectively. Also, replace "number supplied in the DSSS PHY preamble" with "number supplied in the TXVECTOR" in the second paragraph below the figure.

• Moved: Jesse Walker, Tim Godfrey• Passes: Unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes


item #111 of 04/801:– In the description of

dot11AuthenticationAlgorithmsEnable in the MIB, replace "The default value of this attribute shall be 1 for the Open System table entry and 2 for all other table entries." with "The default value of this attribute shall be true when the value of dot11AuthenticationAlgorithm is Open System and false otherwise."

• Moved: Tim Godfrey, Jesse Walker• Passes: Unanimously

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Work completed

• Adopted submission 04/982• Adopted submission 04/985• Adopted resolutions to 18 work items

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Summary

Work Items at start 58

Work Items added 0

Work Items closed 2

Work Items to Editor 19

Work Items remaining 37

Percentage completion 66%

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Output Documents

• 1033r0: This report• 801r1: Tracking list of work items

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Adjourn

• Meeting adjourned at 9:05am on September 16, 2004

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Attendance• Richard Paine• Keith Amann• Mike Moreton• Donald Eastlake• Nancy Cam-Winget• Jesse Walker• Tim Godfrey• Florent Bersani

September 2004


doc.: IEEE 802.11-04/1033r0

Report & Minutes

Goals for September

• Consider new submissions• Continue to process items in 04/801• Continue to stay on track for March 2005

Working Group letter ballot

Sept 2004 doc.: IEEE802.11-04/0983-01


Minutes of High Throughput Task Group .11n Meetings

Date: Sept 13-17, 2004

Author: Garth Hillman Advanced Micro Devices 5204 East Ben White Blvd, Austin, TX 78741 Mail Stop – PCS5 Phone: (512) 602-7869 Fax: (512) 602-5051 e-Mail: [email protected]

Abstract Cumulative minutes of the High Throughput Task Group meetings held during the IEEE 802.11 Interim meeting in Berlin from September 13 through 17, 2004. Executive Summary (also see closing report doc. 11-04-01082r0):

1. This was a marathon session where .11n met every possible hour of the week. 2. 28 Partial proposals were presented on schedule and within the one hour time limit. 3. 4 complete proposals (nSync group, Mitsubishi/Motorola, WWiSE group and Qualcomm) were presented on schedule

and within the one hour time limit. 4. A straw man agenda for November which includes the “low hurdle” vote was agreed to by the group. Note: these minutes are intended to offer a brief (even though the comments averaged about 2 pages per presentation) summary (including document number) of each of the presentations to facilitate review and recall of the session without having to read each of the presentations. Most of these minutes are built directly from selected slides of the various presentations and therefore are not subjective. An effort was made to note obscure acronyms. The Q&A was difficult to capture due to the wide scope of most of the presentations but an attempt was made.

Detailed minutes follow:

Minutes of TGn page 1 Garth Hillman, AMD

Sept 2004 doc.: IEEE802.11-04/0983-01

Monday September 13, 2004; 10:30 AM – 12:30 PM [~ 220 attendees] :

1. Meeting was called to order by Task Group chairperson elect Bruce Kraemer at 10:31 AM 2. Chairs’ Meeting Doc 11-04-1030r0 3. Chair read IEEE Patent Policy 4. Chair reviewed topics not to be discussed during the meeting 5. New participants in .11n ~42 6. Motion by Colin Lanzl to approve July minutes was seconded by Stuart Kerry passed without comment 7. Weeks’ Agenda for .11n

a. 34 hours available b. Reviewed speaking order – 32 presentations at 1 hour per presentation c. To accommodate a personal hardship case the speaking slots were adjusted by 1 hour to allow speaker #30 to speak first d. Speaking logistics were reviewed – 1 hour each e. Nov. – complete proposals repeated, panel session and first voting f. If speakers finish early the excess time will be used for recess

8. Motion to approve agenda including speaking order by Jon Rosdahl and seconded by Tim Wakeley was approved unanimously

9. Document format requirements reviewed by the chair a. E.G. – PDF only by exception, not ZIP files b. Members comments are encouraged to help with formatting mistakes and corrections c. Doc format issues will be minuted this session and reviewed in the Nov meeting.

10. #1 11-04-0942r1; Mustafa Eroz, Hughes Network Systems; HNS Proposal for 802.11n Physical Layer a. Partial Proposal

i. The air interface is built upon IEEE 802.11a (1999) PHY specifications and associated overhead a. OFDM Modulation with PSK and QAM b. (20/64) MHz channel spacing, 52 Sub-carrier set

a. 48 data carriers and 4 pilots (center location not used) c. Preamble modified for MIMO

a. Compatible with 802.11a air-interface d. 2, 3 and 4 TX antenna HT modes support e. One TX Antenna mode for legacy STA support f. PHY-MAC maximum efficiency of 60% assumed

a. In AP-STA test, 100Mbps at MSDU 167 Mbps at PHY b. Key is LDPC code and preambles c. Max Likelihood Estimation receiver


Sept 2004 doc.: IEEE802.11-04/0983-01

d. Support short (50B) packets and long (1000) packets e. FEC codes: LDPC codes easier to handle than turbo codes due to parallel arch? f. Decoders for short LDPC codes are much simpler than for long LDPC codes g. Chose LDPC code length of 192 bits h. Only needed two codes ½ and 2/3 to meet virtually all rates i. Larger blocks are supported by simply concatenating base LDPF codes and adding one extra base block of parity checks

on select LDPC bits j. Translated Matlab channel simulation code into C code k. Conclusion:

i. FEC and MIMO alone achieve the .11n goal ii. 1x and 2x 20 MHz applicability

iii. Simple to implement iv. Highly flexible

l. Q&A i. 64 QAM and R=2/3? A-yes

ii. Why limit to 2/3? A – could do higher especially if fewer TX antennas however, LDPC coder does become more complex

11. #2 Victor Stolpman, Nokia; 11-04-0992 r2; Irregular LDPC Codes and Structured Puncturing a. LDPC Introduction

a. Regular versus Irregular ⇒ Irregular codes have better performance b. Structured versus Unstructured ⇒ Structured codes have better latency

ii. Irregular Structured LDPC Codes a. Seed and Spreading Matrices – Building blocks for structured codes b. Expanded and Exponential Matrices – LDPC code construction

iii. Simulations a. BLER in AWGN ⇒ Performance improves with codeword length b. Conventional BP versus Layered BP ⇒ Layered BP offers good performance with fast convergence and

efficient silicon solutions c. Significant performance improvement over the legacy FEC solution for both small and large packet

sizes in 802.11n channels iv. Structured Puncturing

b. Best performing FEC code i. High Performance with Low Latency

c. Features i. Forward compatibility and hardware reuse

a. Existing seed sets already support longer codeword lengths


Sept 2004 doc.: IEEE802.11-04/0983-01

b. Additional seed are easily added for different channel models, additional code rates, and to accommodate tradeoffs in silicon

ii. “Architecture Aware” constructions that allow for Layered-BP a. Fast convergence ⇒ high performance and low latency b. Efficient silicon solutions

iii. Wide range of block sizes reduces zero-padding inefficiencies iv. Upper triangular seed matrices ⇒ linear time encoding v. In the pipeline …

a. Seed matrices for additional code rates 5/6 and 7/8 b. Additional seed sizes for different number of data sub-carriers (e.g. 40MHz channel bonding)

d. Summary a. Irregular Structured LDPC codes have great performance b. Offers forward-compatibility and hardware reuse c. Already supports codeword lengths greater than 2304 d. “Architecture Aware” constructions ⇒ Layered-BP (belief propagation) decoding e. Efficient silicon solutions with high throughput and low latency f. Wide range of block sizes reduces zero-padding inefficiencies g. Upper triangular seed matrices ⇒ linear time encoding h. Structured puncturing allows for additional code rates for use with spatial stream adaptation in MIMO

systems e. Nico van Waes, Nokia; 11-04-946r1; MAC Partial Proposal for .11n

i. Introduction a. MAC efficiency is an important aspect of the goal of achieving 100 Mbps at the MAC SAP in a robust,

economically attractive fashion. b. Power Efficiency is a critical aspect of making 802.11n suitable for the handset market. c. The following MAC features are proposed for achieving these goals:

a. Multi data rate frame aggregation b. Power Efficiency in aggregation c. MAC Header Compression d. Aggregate ACK

ii. Summary a. The proposed MAC features substantially improve MAC throughput, as well as power efficiency, which

is critical for handset applications b. The features can be introduced easily by modifying/enhancing the existing procedures and frame

structures c. Analysis has been provided to show the benefit


Sept 2004 doc.: IEEE802.11-04/0983-01

f. Q&A i. How do you handle multiple streams? A – (I missed it)

ii. How should .11n choose between the many LDPC codes? A – evaluate on performance and flexibility against a set of requirements dedicated to FEC

iii. Comparison to convolutional codes? A – no 12. #3 Bruno Jechoux, Mitsubishi; 11-04-0916r3; Response to CFP for 802.11n;

a. Background i. Complete proposal resulting from a joint effort of Mitsubishi Electric ITE and Motorola to make 802.11n the

system of choice for Consumer Electronics market while enhancing the service for 802.11 PC/enterprise historical market.

ii. Goal is to provide an efficient MAC handling of QoS sensitive applications taking full benefit of a high throughput MIMO based PHY while keeping compatibility with legacy systems

iii. Various environments supported a. Enterprise b. Home environment c. Hot Spot

iv. Proven and simple solutions b. Alexandre Ribero Dias, Motorola, presented the PHY

i. Transmission of 1, 2 or 3 parallel streams using: a. Space-Time Block Coding (STBC), Spatial Division Multiplexing (SDM) or robust hybrid solutions

(STBC/SDM) b. optimize the rate vs link budget trade-off

ii. 2, 3 or 4 transmit antennas a. The number of receive antennas determines the maximum number of spatial streams that can be

transmitted. b. The capability of decoding 2 parallel data streams is mandatory c. all the devices have to be able to decode all the modes where the number of spatial streams is lower or

equal than the number of receive antennas in the device. d. It is required for a device to exploit all its antennas in transmission even for optional modes.

iii. 2 or more receive antennas a. With STBC or STBC/SDM, asymmetric antenna configurations can be supported

iv. Importance of configurations in which NTx ≠ NRx a. NTx > NRx e.g. between AP and mobile handset (in DL) b. NTx < NRx e.g. between MT and AP (UL), or if MT have upgraded multi-antenna capabilities

compared to AP (infrastructure upgrade cost) v. Conclusion:


Sept 2004 doc.: IEEE802.11-04/0983-01

a. Proposal: MIMO extension of IEEE802.11a addressing b. Short term implementation needs through mandatory modes relying on a mix of STBC and SDM c. Take into account device size constraints allowing asymmetric TX/TX antenna configuration

independent upgrade of APs / MTs possible d. Enable PHY throughput covering 54Mbits/s 180 (234) Mbps

c. Bruno Jechoux, Mitsubishi, presented the MAC portion: i. MAC is inefficient

ii. Proposed new function – ECCF – Extended Centralized Coordination Function Driving idea: Efficient even for Bursty and uncharacterised flows a. Solution

a. TDMA with variable duration time interval (TI) allocation i. Fast resource request/grant scheme

ii. In-band signalling in already allocated TI iii. Dedicated contention access TI for resource requests iv. Resource announcement

b. How does ECCF handle mixed traffic? i. Fast resource request/grant scheme permits to adapt in real time to application needs

variations ii. Resource request can be sent to the RRM through in-band signalling in any TI allocated

to the transmitter (whatever its destination), iii. Otherwise it can be sent in a signalling-dedicated contention access TI. iv. TI allocation broadcast at the beginning of each TDM frame

iii. Conclusion: a. QoS requirements supported (throughput and delay)

a. In all scenarios b. High level MAC efficiency

a. Above 65 % in all scenarios b. Efficient with QoS flows as non QoS flows

c. Very good scalability a. Constant efficiency versus PHY rate

d. Backward compatibility e. Flexibility ensured, without context-dependent tuning f. Full support of all mandatory 11n simulations scenarios with a 120 Mbps PHY layer g. Nothing futuristic

a. TDMA has been used for 20-30 years b. Present in many systems (GSM, 802.15, 802.16…)


Sept 2004 doc.: IEEE802.11-04/0983-01

c. Just one step further than HCCA h. Proven technologies

a. Centralised RRM b. Simple scheduler c. Classical ARQ

i. Moderate complexity implementation a. not more complex than 802.11e (HCCA)

iv. Q&A a. Reservation mechanisms? A – Contention periods

13. #4 Scott Leyonhjelm, WaveBreaker; 11-04-0929r2; A “High Throughput” Partial Proposal a. Executive Summary

i. Fully backward compatible with 802.11a/g a. All enhancements are simple extensions to 11a/g OFDM structure. b. STS and LTS sequences are used in conjunction with progressive cyclic delay per antenna

ii. Higher Data Throughput due to combination of PHY technologies a. MIMO-OFDM - Spatial Multiplexing, up to 3 transmit spatial streams (mandatory), 4 spatial streams

(optional) b. Fast Rate adaptation on a per stream (mandatory) or a per subgroup (optional) level c. Higher order modulation - 256QAM (mandatory)

iii. Higher Data Throughput due to combination of MAC enhancements a. Frames with NO short and long training sequences (mandatory) b. Frame aggregation (mandatory) c. Shorter SIFS, down to 8 us. (Optional)

iv. Minimizing Hardware Complexity a. Frame format designed to increase available time for inverting channel estimate.

b. Frame Format i. Three new MIMO frames

a. Sig 1 = MIMO frame b. Sig 2 = MIMO mode c. Sig3 = Reverse Link Channel State Information

c. PHY i. Fast Rate Adaptation Concept => Higher Average Data Throughput

a. Based on Closed loop feedback of CSI transported by ACK frame b. Optimizes Data rate to channel condition on a per packet basis c. Low implementation cost vs High performance gain d. Small impact on MAC efficiency


Sept 2004 doc.: IEEE802.11-04/0983-01

a. 4 bits per spatial stream e. Overcomes spatial multiplexing singularity in LOS conditions

a. Naturally falls back to transmission of a single stream d. Conclusion

i. Higher Data Throughput due to combination of PHY technologies a. MIMO-OFDM – 1 to 3 data streams using Spatial Multiplexing b. Rate Adaptation c. Higher order modulation – 256QAM

ii. Higher Data Throughput due to combination of MAC enhancements a. Frames with NO training sequences b. Frame aggregation – up to 16kbytes

iii. Backward Compatibility is ensured by a. Operation within a 20MHz bandwidth with the same 802.11a/g spectral mask. b. Single and RTS/CTS frame transmission modes are fully compatible with legacy 802.11a/g devices.

iv. All Functional Requirements are met v. 100Mbps Goodput @ 10m achieved when

a. 20MHz and >=3 transmit data streams b. > 144Mbps Average PHY data rate c. With Rate Adaptation!

e. Q&A i. What Doppler Shift? A - (Ch F) 40 Kph vehicle?

ii. Slide 7 – no training for Type 2 frames? A – Yes iii. Slide 7 – training time for Type 1? A - .25 us

14. #5 John Kowalski, Sharp & NTT; 11-04-0939r2; Technical Proposal for IEEE 802.11n a. Features of PHY

i. 2 Tx chains are mandatory. 3 and 4 Tx chains are optional. ii. Channelization greater than 20MHz is out of scope.

iii. Modified scattered-type preamble for MIMO channel estimation is newly introduced. iv. Pilot preambles to track time varying channels can be inserted flexibly for reliable long burst transmission. v. EXTENDED SIGNAL and MIMO packets are encapsulated after the Legacy PLCP header including PLCP

preamble and legacy SIGNAL in order to keep backward compatibility with legacy devices, vi. Most of all other specifications on PHY layer are the same as that of 802.11a with the exception of MIMO

communication function and addition of an new PHY mode of 64QAM R=7/8; this results in minimizing impacts of modifications for 802.11n.

b. Features of MAC


Sept 2004 doc.: IEEE802.11-04/0983-01

i. MSDUs that belong to the same TID and sent to the same reception address can be aggregated in a MAC frame in order to improve MAC efficiency.

ii. Each MSDU in an aggregated frame is selectively re-transmitted in SR-ARQ manner. iii. Bit-map-type multiple ACK is introduced instead of block-ACK based on 802.11e. iv. Random back-off mechanism is slightly modified, and unnecessary contention window extension that is not

caused by contention can be avoided. v. Optional highly accurate synchronization function between stations is introduced.

vi. Signaling to control use of Tx and Rx resources is introduced. c. Key - Transmit new data along with retried old data d. Simulation Methodology

i. This simulation methodology is mainly based on “Unified “Black Box” PHY Abstraction Methodology” (IEEE 802.11-04/0218r3).

ii. With the aim of high-speed simulation, we classified the total simulation into following three steps that do not require co-simulation;

iii. Phy Simulation a. PHY simulations are run to obtain Look Up Tables (LUTs), which are the tables of Channel Capacity

(CC) vs. PER for all PHY modes and channel models. iv. Pre-MAC Simulation

a. With TGn channel model, time varying MIMO channel is simulated. b. Time varying PER is estimated by CC value for the MIMO channel, and it is recorded in a PER data

file. v. MAC/System Simulation

a. MAC/System level simulation is executed with time varying PER that is recorded PER data files for all links.

e. 15-20 hours required per simulation to get Packet Error Rates! f. Meets all FRs g. Reports for all CCs given h. Q&A

i. Does Japan forbid MIMO? A- Don’t know ii. Agg Ack, RX must respond? A – yes

iii. What if no bit map is included? A – adjunct contention window iv. Interaction between Agg Ack and Block Ack? A – under consideration v. Slide 45, Impact of Hidden Node? A – 2nd order effect

vi. Slide 9, if frame aggregation frame fails all fails? A – yes but it is a short frame and less prone to failure vii. Why not transmit header with preamble? A – yes

15. #6 Sumei Sun, Infocomm; 11-04-0876r2; TGn MIMO-OFDM PHY Partial Proposal – Presentation


Sept 2004 doc.: IEEE802.11-04/0983-01

a. Summary i. OFDM modulation over 40MHz channel with FFT size of 128;

ii. Support of two concurrent 11a transmissions in downlink; iii. Peak data rate of 216Mbps; iv. Mandatory support of 2×2 MIMO

a. Spatial multiplexing (SM); b. Orthogonal STBC.

v. Optional support of 4×2 MIMO for downlink (from access point to terminal station ) a. groupwise STBC (GSTBC); b. orthogonal STBC; c. antenna beam forming; d. antenna selection.

vi. Efficient training signal design (preambles) that supports robust frequency and timing synchronization and channel estimation;

vii. Bit-interleaved coded modulation (BICM) a. Mandatory support of K=7 convolutional code; b. Optional support of low-density parity check (LDPC) code.

viii. An optional 2-D linear pre-transform in both frequency and spatial domain to exploit the frequency and spatial diversities.

b. 2-D interleaver is simply a method of putting the OFDM bits into alternate streams c. STBC = space time block coding d. Modes = Group STBC, STBC, fixed beam forming, 2x2 spatial mux e. GSTBC – open loop structure f. Next Step would be 4x4 MIMO with Singular Value Decomposition beam forming for optimal Spatial Mux g. 8 short preambles

i. Same for all transmit antennas; i. Occupying 6.4 µs, for signal detection, AGC, frequency and time synchronization

h. Summary and Conclusions i. 2×2 SM and STBC as the mandatory modes, and 4×2 GSTBC, STBC, beam forming, and antenna selection as

the optional modes; ii. GSTBC provides significant performance gain over SM;

iii. Subcarrier arrangement can support two concurrent 11a transmissions in downlink; iv. Novel and efficient preamble design that supports robust FOE (frequency offset error) and channel estimation; v. Proposed LDPC in the optional mode which provides large performance gain over convolutional code for the

peak data rate support; vi. Proposed PT (pre-transform) in the optional mode which can be used for range extension .


Sept 2004 doc.: IEEE802.11-04/0983-01

i. Q&A i. Slide 25 – will legacy devices be compatible with long preambles? A-yes

ii. What about ½ L antenna? A – not simulated yet iii. Slide 10 – what was the reference doc? A – doc 11-04-0875

j. #7 Michiharu Nakamura, Fujitsu; 11-04-0937r0; Partial Proposal .11n Physical Layer i. Summary

a. VISA based MIMO processing b. PLCP frame structure c. 2 and 4 Tx antenna MIMO d. Keep .11a Coding and Modulation e. Reuse .11a blocks (FFT, coding, Puncturing, Interleave)

ii. No conclusion slide iii. No Q&A

16. Chair recessed the meeting – 9:25 PM

Tuesday 9-14-04; 8 AM – 9:30 PM

1. Chair reconvened the meeting at 8:00 AM 2. #8 Jeng-Hong Chen, Winbond Electronics; 11-04-943r2; A 3-Dimensional Joint Interleaver for 802.11n for MIMO Systems

a. Challenges of MIMO Interleaver: i. L=Number of OFDM symbols from FEC outputs

ii. NI=Number of OFDM symbols per 3D Joint Interleaver iii. NOFDM= Number of OFDM symbols are transmitting at the same time iv. M=Number of transmitter antennas (M≥ NOFDM) v. NCBPS=Number of coded bits per OFDM symbol

vi. NSC=Number of data sub-carriers per OFDM symbol vii. NBPSC=Number of coded bits per sub-carrier

viii. Example: L=18, NI =6, NOFDM =2, M=3, and Nsub=48 (see next page) ix. How to choose an appropriate interleaver size, NI, for a MIMO system? x. How to transmit NOFDM (≤M) OFDM symbols at the same time from M TX Ant.?

xi. How to interleave total NI*NCBPS coded bits from FEC outputs and map into 1. NI*Nsub sub-carriers (frequency domain) and various NBPSC for different QAM 2. M TX antennas (spatial domain) and 3. NI total OFDM symbols and NOFDM at the same time?

b. Purpose of 3D Joint Interleaver


Sept 2004 doc.: IEEE802.11-04/0983-01

i. Backward compatible with 11a interleaver and preserve all good properties ii. To separate consecutive bits by 3*NBPSK or 3 sub-carriers.

iii. To assign consecutive bits to different OFDM symbols c. Motivation of Interleaver 3D-A

i. Properties of proposed 3D interleaver: ii. (A) Guaranteed separation of coded bits in the same subcarrier is Ncolumn bits

iii. (B) Guaranteed separation of consecutive coded bits is NSCPC subcarriers. iv. (C) Guaranteed separation of coded bits in consecutive subcarriers is (NI×Ncolumn) bits v.

vi. If Ncolumn >> dfree of a convolution code, interleaver 3D performs well. vii. However, if Ncolumn ≤ dfree, the separation in statement (A) is not enough.

viii. ix. Solution: x. Preserve the good properties in original 3D interleaver and

xi. Apply further rotation to increase the frequency diversity (subcarriers) xii.

xiii. Note: xiv. The improvement from interleaver 3D to 3D-A is small if Ncolumn is large xv. Further permutation can be applied for any specified MIMO system from this 3D interleaver structure

d. Discussion i. The structure of 3D interleaver best fits the space, time, and frequency domains of a MIMO system.

ii. A best visible structure (tool) for designers to distribute correlated bits uniformly and systematically into all diversities

iii. The generalized 3D interleavers can be designed to optimize a MIMO system with specified parameters: 20/40 MHz, NSC, Ncolumn, NI,…

iv. In cases if Ncolumn is small relative to dfree, Interleaver 3D-A is recommended to have further permutations in frequency domain.

e. Part II Circulation Transmission i. Transmission Options:

1. Circular Spatial Multiplexing (CSMX) 2. Circular Space-Time Alamouti (CALA)

ii. Circulation Options:

1. (C) OFDM Symbol Based Circulation (S_BC) 2. (D) Sub-carrier Based Circulation (Sub_BC)


Sept 2004 doc.: IEEE802.11-04/0983-01

NOTE: The same proposed 3D Joint Interleaver is applied for all above options. f. Transmission options

i. (A) Circular Spatial Multiplexing (CSMX) 1. Transmitting NOFDM (≤M) OFDM Symbols from M TX Antennas 2. High throughputs if high SNR

ii. (B) Circular of Space-Time Alamouti Code (CALA) 1. Simple to encode and decode 2. Can be easily modified to be compatible with 11a/g 3. Circular Alamouti is applied if more than two transmit antennas 4. Circulation bases on two OFDM symbols to preserve orthogonality

Definition: NOFDM (M) denotes a MIMO system transmits NOFDM OFDM symbols at the same time from M TX antennas

g. RF and BB Issues i. RF Total TX Power for 2(3) MIMO Systems

1. Assuming max power of each subcarrier is p, 2. Total power of OFDM symbol based circulation = 48 * p * 2 = P 3. Total power of subcarrier based circulation= 32 * p * 3 = P 4. Power per antenna is P/2 for S_BC and P/3 for Sub_BC

ii. Baseband (BB) hardware requires 1. Two IFFT/FFT for S_BC and Three for Sub_BC 2. NOTE: Bigger NI implies bigger HW size and longer decoding delay

a. Example: 2(4) CSMX requires NI=12 for S_BC and NI=2 for Sub_BC

iii. If the power consumption of more active TX antennas at RF and more active IFFT/FFT at BB are acceptable, Sub_BC is recommended with minimal decoding delay and interleaver size.

h. Conclusion i. Proposed 3D interleaver distributes FEC coded bits to all available diversities in space, time, and frequency

ii. Proposed 3D interleaver is backward compatible to 802.11a systems iii. Proposed 3D interleaver is applicable to both 20MHz and 40MHz bandwidths with total 64 or 128 I/FFT

subcarriers iv. Proposed TX circulation outperforms TX scheme without TX circulation (CSMX v.s. SMX, CALA v.s. ALA) v. Proposed Sub-BC TX circulation which have smaller intereleaver size and decoding delay is highly

recommended. i. Q&A

i. Impact on system memory? A – very little


Sept 2004 doc.: IEEE802.11-04/0983-01

3. #9 Qiang Ni, National University of Ireland; 11-04-0949r0; AFR Partial MAC Proposal for IEEE802.11n a. Outline

i. Ideal throughput analysis for 802.11n ii. Actual effective throughput analysis under noisy environments

iii. Our packet Aggregation with Fragment-Retransmission (AFR) proposal iv. Simulation analysis

b. Q&A i. What about delay bounds? A – to be simulated

ii. Slide 3, mean back-off = ½ CW min? A – yes, assuming only one STA as it simulates the best case iii. If N STAs CWaverage will be CW/N not 2? A – let’s take off-line iv. Slide 13, fragment sizes fixed? A – yes, same size and small v. BER assumed? A – 10-5

vi. Is this worst case? A – no, need to consider fading environment vii. Slide 15, what fragment size? A – best case, automatically chosen by simulator

4. #10 , Marie-Helene Hamon, French Telecom; 11-04-0903r1; Partial Proposal: Turbo Codes a. Turbo codes used in 3G and Satellites and .16 b. TC for .11n exactly = .16 c. Gates

i. 164,000 @ Clock = 100 Mhz ii. 82,000 @ Clock = 200 Mhz

iii. 54,000 @ Clock = 400 Mhz d. RAM

Data input buffer + 8.5xk for extrinsic information + 4000 for sliding window (example: 72,000 bits for 1000-byte block)

e. Part II: Turbo Codes for 802.11n i. Why TC for 802.11n?

ii. Flexibility iii. Performance

f. Purpose i. Show the multiple benefits of TCs for 802.11n standard

ii. Overview of duo-binary TCs iii. Comparison between TC and .11a Convolutional Code iv. High Flexibility


Sept 2004 doc.: IEEE802.11-04/0983-01

v. Complexity g. Properties of Turbo Codes

i. Rely on soft iterative decoding to achieve high coding gains ii. Good performance, near channel capacity for long blocks

iii. Easy adaptation in the standard frame 1. (easy block size adaptation to the MAC layer)

iv. Well controlled hardware development and complexity v. TC advantages led to recent adoption in standards

h. Conclusions i. Mature, stable, well established and implemented

ii. Multiple Patents, but well defined licensing

1. All other advanced FECs also have patents

iii. Complexity: 1. Show 35% decrease in complexity per decoded bit over binary TCs 2. Performance is slightly better than binary TCs

iv. Significant performance gain over .11a CC:

1. 3.5 - 4 dB on AWGN channel 2. 2.5 - 3 dB on 802.11n channel models

i. Q&A i. Complexity penalty for block size and code rate? A – length and memory

ii. Adaptive Coding? A – puncturing is simple as convolutional codes iii. Multiple rates on different spatial streams? A – remove parity bits iv. How .11n to choose best code? A- 2-3 size examples with 2-3 rates and 3 channels and count the gates v. How many parallel engines? A – minimum of 4 and multiples of 4

vi. Define perfect block code? A - Perfect block code can be viewed as a circle vii. Slide 9, what is latency? A – 2x decoding time

viii. TC vs CCs wrt channel model? A – not aware of studies ix. How critical is choice of puncturing patterns? A – not sensitive x. Consider constellation shaping? A – No

5. #11 Stephano Valle, ST Microelectronics; 11-04-900r4; ST Microelectronic LDPCC Partial Proposal for 802.11n CFP a. Motivation

i. Performance is significantly better than 64-state CC [1]. ii. LDPCC are intrinsically more parallelizable than other codes.


Sept 2004 doc.: IEEE802.11-04/0983-01

iii. LDPCC can be designed to have good performance at every rate (i.e. avoiding puncturing or shortening) without exploding HW complexity.

iv. LDPCC performances have been demonstrated with 12 iterations: technology evolution will make feasible a larger number of iterations providing further gains.

v. The LDPCC class described in this proposal [2] is the optional advanced coding technique in the WWISE complete proposal [3].

b. Proposal – Variable Rate Structured LDPCC i. The performance of different matrices show, in general, slight differences for short block lengths.

ii. Implementation complexity is a key factor. iii. Structured parity check matrices allow a higher degree of decoder parallelization compared to random matrix

design. iv. Rate-compatibility, i.e. good performance at every rate while avoiding puncturing or shortening, is essential. v. A common shared HW architecture for all the rates and all the codeword lengths ensures low cost devices.

c. Advantages of Variable Rate LDPC i. A new method to design LDPCC for a variety of different code rates that all share the same fundamental

decoder architecture. ii. An important advantage of this approach is that all code rates have the same block length (a key performance

factor). iii. The same variable degree distribution is maintained for all the rates. Although not optimum, a single variable

node degree distribution can be employed that works well for all the different code rates of interest. iv. Low-complexity encoding (because of block-lower triangular structure) is preserved for all the code rates. v. Different ‘mother’ parity-check matrices, to provide different block sizes, can be added at the expense of small

extra-HW complexity (basically, ROM for matrix storage). vi. Other approaches (i.e. puncturing and shortening) suffer from performance degradation.

d. Complexity i. Massive HW re-use is possible because all the rates are derived from the “mother” rate ½ and the same sub-

matrix size is adopted for all the codeword lengths. ii. The encoder has a linear complexity thanks to its lower triangular structure that permits the back substitution.

iii. A different mother matrix for each code size implies extra-ROM, as the use of the same structure for the basic building blocks (27x27) allows efficient re-use of parallel processors.

iv. Main targets in the table can be met. v. Area 800 k gates

vi. Iterations = 12 vii. Decoder freq = 240 MHz

viii. Latency = 6 us e. Conclusion


Sept 2004 doc.: IEEE802.11-04/0983-01

i. This proposal contains LDPCC designed with a powerful/well performing technique to generate variable rate codes up to rate 5/6.

ii. Performances are significantly better than 64-state CC (>= 2dB @ 10-2 PER for all code rates higher than 1/2). iii. In order to optimize padding management and/or handle short packets, different code-size matrices have been

designed; they can coexist at low extra HW complexity and yield similar performances. iv. These codes result in a reasonable overall complexity / latency / performance trade-off. v. Results have been obtained with 12 iterations: technology evolution will make feasible a larger number of

iterations providing further gains. f. Q&A

i. Compare complexity wrt Turbo codes at 84 K gates and 200 MHz? A – LDPC gives better performance ii. How to support multiple rates in a single code block? A – parallel codecs

iii. How should .11n select the best FEC? A – as pervious speaker said, construct a simple set of simulations iv. Yesterday Regular vs Irregular LDPCC; which is yours? A – irregular v. Size of RAM? A- off-line

vi. Throughput 100 vs 300 Mbps A – yes 6. #12 Johann Chiang, Un Texas; 11-04-1003r1; Quantized Pre-Coding with Feedback, .11n Partial Proposal

a. Main Features i. Closed-loop MIMO-OFDM with limited feedback (LF)

ii. Robust optional mode when RTS/CTS is on iii. Proposed PHY features

1. Quantized precoding with feedback b. TX Beam forming (BF) c. Spatial multiplexing (SM) d. Multi-mode adaptation

iv. Proposed MAC features 1. Extended RTS/CTS frames for feedback

v. Backward compatible with 802.11a b. Feedback Structure

i. No physical feedback channels available in 802.11 ii. Exploit control frames in existing or emerging standards as logical feedback channels

iii. Propose extension to existing 802.11 MAC 1. Use RTS for estimation and CTS for feedback

c. Why and When to use RTS/CTS i. Efficient when # of active STAs is large

1. Reduce collision overhead in hotspots ii. Useful in DCF (no AP, peer-to-peer)


Sept 2004 doc.: IEEE802.11-04/0983-01

1. Alleviate hidden terminals issue iii. Low overhead when frame size is large

1. Benefit from frame aggregation iv. Required for backward compatibility

1. Should maximize the worth of legacy mechanism v. Capable of Improving MAC throughput

1. Use dynamic RTS/CTS threshold (IEEE 802.11-04/312r0) d. MAC Extension

i. Extension to legacy RTS frame 1. Append training sequences for multiple antennas

ii. Extension to legacy CTS frame 1. Exploit free 10 bit available, required to fill OFDM symbol

a. Mode selection 2. Use higher order modulation (QPSK) for limited feedback

a. 48 bits => 1 OFDM symbol e. Conclusion

i. Quantized precoding with feedback is practical to improve goodput even if RTS/CTS is on ii. Subcarrier clustering reduces feedback for OFDM

iii. Multi-mode precoding provides for diversity- multiplexing tradeoff and compatible with rate adaptation 7. WG Chair, Stuart Kerry gave permission for three minutes for the audience to take pictures of the .11n body due to its

unprecedented size. 8. #13 Jon Rosdahl, Samsung; 11-04-0887r2; TGn nSync Complete Proposal

a. Phy Summary i. MIMO evolution of 802.11 OFDM PHY – up to 4 spatial streams

ii. 20 and 40MHz* channels – fully interoperable iii. 2x2 architecture – 140Mbps in 20MHz and 315Mbps in 40MHz iv. Scalable up to 630Mbps v. Preamble allows seamless interoperability with legacy 802.11a/g

vi. Optional enhancements 1. Transmit beam forming with negligible overhead at the client 2. Advanced channel coding techniques (RS, LDPC) 3. 1/2 guard interval (i.e. 400ns) 4. 7/8 rate coding

b. MAC Summary i. Supports 802.11e

ii. Frame aggregation, single and multiple* destinations


Sept 2004 doc.: IEEE802.11-04/0983-01

iii. Bi-directional data flow iv. Link adaptation with explicit feedback and control of channel sounding packets v. Protection mechanisms for seamless interoperability and coexistence with legacy devices

vi. Channel management (including management of 20/40MHz operating modes) vii. Power management for MIMO receivers

c. PHY was presented by Aon Mujtaba, Agere i. Mapping of Spatial Streams

1. Number of spatial streams = Number of TX antennas a. 1 spatial stream mapped to 1 antenna b. Spatial division multiplexing c. Equal rates on all spatial streams

2. Number of spatial streams ≤ Number of TX antennas

a. Each spatial stream mapped to all transmit antennas b. Optional orthogonal spatial spreading

i. Exploits all transmit antennas ii. No channel state info at TX required

3. Optional transmit beam forming a. Focusing the energy in a desired direction b. Requires channel state info at TX c. Supports unequal rates on different spatial streams

4. With per spatial stream training, no change needed at the RX ii. Summary of HT-LTF

1. Robust design a. Tone interleaving reduces power fluctuation b. 2 symbols per field

i. 3dB of channel estimation gain with baseline per-tone estimation ii. Enables additional frequency offset estimation

2. Per spatial stream training

a. HT-LTF and HT-Data undergo same spatial transformation b. Number of HT-LTFs = Number of spatial streams

d. 20/40 MHz Interoperability i. 40 MHz PPDU into a 40 MHz receiver

1. Get 3dB processing gain – duplicate format allows combining the legacy compatible preamble and the HT-SIG in an MRC fashion


Sept 2004 doc.: IEEE802.11-04/0983-01

ii. 20 MHz PPDU into a 40 MHz receiver

1. The active 20 MHz sub-channel is detected using energy measurement of the two sub-channels 2. Inactive tones at the FFT output (i.e. 64 out of 128) are not used

iii. 40 MHz PPDU into a 20 MHz receiver

1. One 20 MHz sub-channel is sufficient to decode the L-SIG and the HT-SIG

iv. See MAC slides for additional information on 20/40 inter-op e. MAC presented by Adrian Stephens

i. MAC Challenges 1. HT requires an improvement in MAC Efficiency 2. HT requires effective Rate Adaptation 3. HT requires Legacy Protection

ii. New MAC Features 1. Aggregation Structure 2. Aggregation Exchanges

a. Protocol for link adaptation b. Protocol for reverse direction data c. Single and multiple responder

3. Protection Mechanisms 4. Coexistence & Channel Management 5. Header Compression 6. MIMO Power Management

iii. Robust = single point of failure iv. IAG=Initiate Aggregate Control v. RAC=Responder Aggregate Control

vi. RDL=reverse direction limit vii. RDR=reverse direction request

viii. RDG=Reverse direction grant ix. MRAD=Multi-receiver Address Descriptor x. Periodic MRAggregation great for VoIP

xi. Long NAV Protection 1. Provides protection of a sequence of multiple PPDUs 2. Provides a solution for .11b


Sept 2004 doc.: IEEE802.11-04/0983-01

3. Comes “for free” with polled TXOP 4. Gives maximum freedom in use of TXOP by initiator

xii. Pairwise Spoofing Protection 1. Protects pairs of PPDUs (current and following) 2. Very low overhead, suitable for short exchanges, relies on robust PHY signalling 3. Places Legacy devices into receiving mode for spoofed duration 4. Spoofing is interpreted by HT devices as a NAV setting

xiii. Operating Mode Selection 1. BSS operating mode controls the use of protection mechanisms and 20/40 MHz width switching by HT

STA a. Supports mixed BSS of legacy + HT devices

2. HT AP-managed modes a. If only the control channel is overlapped, managed mixed mode provides a low overhead

alternative to mixed mode b. If both channels are overlapped, 20 MHz base mode allows an HT AP to dynamically switch

channel width for 40 MHz-capable HT STA xiv. Summary of Key Features

1. 20 and 40 MHz channels – fully interoperable 2. Scalable to 630 Mbps 3. Legacy interoperability – all modes 4. Robust preamble 5. Transmit beam forming 6. Robust frame aggregation 7. Bi-directional data flow 8. Fast link adaptation

xv. Q&A 1. What is optional and mandatory? A – beam forming O, 20 MHz – mandatory, spatial Division mux M SR and LDPC are optional 2. Position on IP – RAND or RANDZ or not enforce rights? A – companies have all declared they will

adhere to IEEE patent policy 3. Question was ruled in order by .11n chair and Stuart Kerry was asked to consult on the acceptability of

the answer 9. #14 Andy Molish, Mitsubishi Electric Research Labs in Cambridge Mass.; 11-04-0996r2; PHY and MAC Proposal for

IEEE802.11n a. Andy Molish ;presented the PHY solution b. Goals


Sept 2004 doc.: IEEE802.11-04/0983-01

i. Dramatic increase of data rate in PHY 1. 100 Mbps required throughput at MAC SAP

ii. High MAC efficiency and QoS iii. Backward compatibility

1. Compatible with existing 802.11 standards iv. Low complexity

c. Approach Taken i. Maintain backward compatibility

1. Rely on mature technology & existing standard framework ii. Be innovative

1. Develop new technologies which can be easily incorporated to achieve high data rate and high efficiency

iii. Focus on inexpensive solution 1. Optimize the performance/cost ratio

d. Baseline PHY i. Basic MIMO-OFDM system with layered structure (VBLAST)

ii. Receiver uses linear processing and successive interference cancellation iii. 2x2 antenna modes with 20 MHz channelization as mandatory, 3x3 and 4x4 as optional iv. Convolutional codes, with coding rates of ½, 2/3, ¾, and 7/8, mandatory for backward compatibility. v. Low-density parity check (LDPC) codes as options

e. Key Proposed Technologies i. Statistical rate allocation for different layers

ii. RF-baseband processing for antenna selection iii. QBD-LDPC coding for layered systems

Each above technology, or any form of their combination, can be used for performance enhancement f. Their Statistical Rate Allocation

i. We propose to statistically determine the optimal data rates for different layers to avoid instantaneous rate feedback

1. Detection order of the layers is fixed; different layers cycle through different transmit antennas 2. Different layers have different data rates that are statistically determined by the channel quality. Due to

V-BLAST principle, different layers have different capacities 3. Data rates for the layer are chosen so that meeting a certain outage probability is guaranteed!

g. RF Pre-processing with Antenna Selection i. Problem with antenna selection: significant loss of SNR in correlated channels

1. Mean SNR gain is determined by number of RF chains ii. Our solution:


Sept 2004 doc.: IEEE802.11-04/0983-01

1. Perform processing in RF domain, i.e., before selection is done 2. Reduce implementation cost by using only phase-shifter and adder in RF processing 3. Solution can be based on instantaneous channel state information (CSI), average CSI, or no CSI 4. Maintains diversity gain AND mean-SNR gain

h. Why LDPC i. Capacity approaching performance

ii. Parallelizability of decoding, suitable for high speed implementation iii. Flexibility: LDPC is simply a kind of linear block code and its rate can be adjusted by puncturing, shortening,

etc. i. Quasi-Block Diagonal LDPC Space-time Coding (QBD-LDPC) for Layered Systems

i. Feature: The encoding of different layers is correlated as compared with conventional layered systems. ii. Advantage: The space-time LDPC is designed such that the code can be decoded partially with the help of other

layers (undecoded part) by the introduction of correlation between different layers j. Summary of PHY Technologies k. The proposed solution provides a good tradeoff between performance, complexity and compatibility requirements and

cost. i. Low complexity: The complexity of linear processing + SIC scales linearly with the number of layers.

ii. Low cost: Joint RF-baseband processing reduces the number of RF chains needed in antenna selection. iii. Backward compatibility:

1. Existent convolutional codes can be used. 2. No explicit feedback mechanism is needed.

iv. Flexibility: Multiple modes for various number of receive antennas. l. Jinyun Zhang presented their MAC Solution

i. MAC Structure 1. Retain 802.11e super frame structure 2. Enhance 802.11e for high efficiency 3. Maintain the same QoS support as 802.11e 4. Backward compatible with 802.11/802.11e

ii. Proposed Techniques 1. Adaptive Distributed Channel Access (ADCA) 2. Sequential Coordinated Channel Access (SCCA) 3. Frame Aggregation 4. Efficient Block Ack All above technologies can be used together or separately to increase 802.11/802.11e MAC efficiency

iii. SCCA Overview 1. Scheduled transmission based on request


Sept 2004 doc.: IEEE802.11-04/0983-01

a. Scheduled transmission order with STAs assigned with incrementally different backoff time b. Scheduled transmission duration

2. Ensure parameterized QoS 3. Combine the merits of TMDA and polling mechanisms

a. Eliminate the polling overhead, and retain its flexibility b. Avoid the TDMA’s stringent synchronization, and achieve its efficiency

4. Consist of five distinct phases a. Resource request b. Resource allocation c. Data transmission d. Resource renegotiation e. Resource relinquishment

iv. Frame Aggregation 1. Frame aggregation at multilevel

a. At MSDU and/or PSDU level b. In both contention period and contention free period c. Flexible and efficient BlockACK mechanism for frame aggregation d. Novel internal collision resolution mechanism

2. Frame aggregation at MSDU level a. Aggregation condition: With identical traffic class and same <source, destination> pair

3. Frame aggregation at PSDU level a. Frames can have different destination addresses, but they must be the same traffic class b. Frames can be the different traffic class, but they must be involved in the internal collision →

internal collision resolution v. Efficient Block Ack

1. The blockAck bitmap field in the legacy BlockAck frame contains more than it needs 2. A more efficient BlockAck frame design can save more than 90% of bandwidth

a. Single traffic class b. Sequence number bitmap (at most 8-byte long) for acknowledgement to 64 frames c. Readily extensible to support acknowledgement to more than 64 frames

i. Enlarge the block size field in BAR/BA field ii. Extend the sequence number bitmap to accommodate the number of frames to be

acknowledged. d. The 2-bit type field in BAR/BA field

i. 0x02: streamlined BlockACK ii. 0x03: BlockAck for frame aggregation in contention free period.


Sept 2004 doc.: IEEE802.11-04/0983-01

vi. Summary of MAC Proposal 1. We proposed four major enhancements for 802.11e MAC

a. Adaptive Batch transmission b. Sequentially coordinated channel access & frame format c. Efficient and flexible frame aggregation at MSDU and/or PSDU level d. Efficient BlockAck

2. All these enhancements improve 802.11e MAC efficiency while retaining the reliability, simplicity, interoperability and QoS support of 802.11/802.11e MAC

vii. Conclusions 1. We have proposed a variety of important techniques for performance enhancements to both PHY and

MAC 2. These techniques can be individually or jointly included in the upcoming 802.11n standard 3. We will continue to develop further enhancements for possible adoption 4. We are open for any collaboration to establish a baseline proposal for 802.11n standard

m. Q&A i. Efficient Block Ack – reducing number of fragments? A – yes

ii. SCCA period – what happens if the frame transmission fails? A – no CSMA iii. Packet limit? A -8192 B iv. Single CRC? A – I missed the answer

10. #15 Abel Dasylva, Nortel; 11-04-0879r4; Class-Based Contention Periods (CCP) for 802.11n MAC a. General Description of CCP

i. Two types of contention periods 1. Explicit CPs (ECPs) allocated by the HT AP 2. Legacy CPs (LCPs)

ii. In each ECP a subset of ACs contend according to EDCA rules iii. ECPs are delimited by

1. ECP-Start 2. ECP-End or 3. ECP-Start+ECP-end frames

iv. Two access modes for ECPs 1. Default mode: a channel access function can access the channel within an ECP if its AC is allowed in

the ECP 2. QoS negotiation mode: the HT AP grants access to the channel access function after a QoS negotiation

phase b. Motivation fro CCP

i. The need for a simple and effective QoS provisioning mechanism


Sept 2004 doc.: IEEE802.11-04/0983-01

ii. Improve the throughput efficiency of EDCA by 1. Allowing non-QoS (TCP) traffic to contend more aggressively for the available bandwidth 2. Maintain and improve the performance of QoS traffic (with EDCA) by better isolation from non-QoS

flows iii. The complexity and polling overhead (especially the associated preamble+PLCP overhead) of HCCA iv. The difficulty of accurate QoS provisioning with EDCA v. Solution CCP: blend features of HCCA and EDCA

1. Centralized allocation and scheduling of ECPs 2. Distributed channel access within ECPs 3. QoS provided by the proper selection of ECP lengths and scheduling

c. Conclusion i. A simple framework for effective QoS provisioning

ii. A wide variety of bandwidth allocation and QoS policies supported iii. Full backward compatibility with 802.11/802.11e iv. The requirement for admission control to ensure QoS within real time ECPs (beyond the scope of this work)

d. Q&A i. Subset of ACs contend for channel, how? A – schedule them; legacy is protected by long NAV

ii. Both EDCA an HDCA are not meant to be isochronous and your techniques is meant to make traffic uniform, what about overlapping BSSs? A – yes need to simulate but CCP provides a nice fine tuning mechanism

iii. Improvement of MAC efficiency due to isolating traffic? A – yes 11. Stuart Kerry asked the group for permission to suspend the rule prohibiting TG chairs from carrying communications devices

(i.e., cell phones) for this meeting only in order to mitigate possible electrical and audio problems like we had last night? The group agreed without comment.

12. #16 TK Tan, Philips; 11-04-0945r3; Philips Partial Proposal to IEEE802.11n (Enhancements of 802.11 a/g MIMO based System

a. Complementary to nSync b. TK Tan Introduced the paper c. Monisha Gosh presented the PHY portion of the paper as follows: d. PHY Outline

i. 128-FFT in 20 MHz ii. Advanced Coding

1. ¼-rate Convolutional Code 2. Concatenated RS-CC coding

iii. Embedded Signaling e. Benefits of 128 FFT

i. Increase data rate by 11% comparing to 64-FFT


Sept 2004 doc.: IEEE802.11-04/0983-01

1. 2 x 2 ,rate ¾ 64QAM: 2. goes from 108Mbps to 120Mbps (127 Mbps with half GI). 3. Extra rate can be used as is, or combined with RS code to increase robustness with no extra overhead.

ii. Better performance in long delay spread channels 1. Longer symbol time relative to GI makes the 128-fft system more robust in long delay spread channels.

iii. Better performance in half GI. iv. Low overhead preamble design.

1. Channel estimation for 2 antennae can be accomplished in 8msec, the same time that is currently used by 802.11a systems for 1 antenna.

f. Conclusion for 128 FFT i. Highly optimized signal design using 128-fft presented.

1. 6 pilots to enable phase tracking performance. 2. Extremely low-overhead preamble design, suitable for long-delay-spread channels. 3. Joint interleaving over antennae to maximize utilization of frequency diversity.

ii. Extra 11% data rate is obtained with no performance penalty, even with impairments. 1. Better performance than 64-fft in long-delay spread channels (results shown later).

g. Overview of Advanced Coding i. Improved robustness and increased coverage is key to the success of CE market

ii. Besides other techniques, we propose stronger FEC without introducing too much complexity from the mandatory modes.

iii. The proposed solution is to 1. concatenate (220, 200) RS 2. extend CC from ½ to ¼.

iv. Both are well known in the industry and have manageable complexity h. Simulation Results for RS coding and 128 FFT

i. 128-fft system parameters: 1. Option 1 preamble (8 ms), with LS channel estimation. 2. Frequency offset estimation on legacy, phase tracking with 6-pilots/OFDM symbol. 3. Joint interleaver. 4. RS coding.

ii. 64-fft system parameters 1. Tone-interleaved preamble (14.4 ms), per-tone channel estimation. 2. Additional fine-frequency offset estimation on MIMO preamble, phase-tracking with 4 pilots/OFDM

symbol. iii. Impairments:

1. Phase noise = -100 dBc/Hz.


Sept 2004 doc.: IEEE802.11-04/0983-01

2. Frequency offset = -13.67 ppm at 5.25 GHz. 3. Channel models B, D, E and F.

i. Conclusion for RS code and 128 FFT i. RS coding is a cost-effective way to obtain 2 to 4 dB of additional coding gain.

ii. Combined with a 128-fft system, there is no additional overhead as compared to a 64-fft system. j. Properties of the Rate Extended ¼ CC

i. It is a non-catastrophic extension of used rate-½ convolutional code (133,171) ii. Among all codes that extend (133,171) it:

1. has largest minimum free distance (20), 2. of all the codes satisfying 1, has minimum number of paths at free distance 20. 3. of all the codes satisfying 2, has minimal number of paths at free distance 21 4. following the same principle, has minimal number of paths at free distance to 32

iii. Proposed Rate ¼ code: (133,171,135,175) 1. rate 1/3 code (133, 171, 135) 2. free distance: 15.

iv. Optimal code of all rate 1/3 codes 1. free distance: 15. 2. Optimal code of all rate 1/3 codes 3. Punctured from 1/4-rate (133,171,135,175) 4. extension of 1/2-rate (133,171)

k. Pen Li presented Embedded Signaling i. Goals

1. Signal in legacy-compatible way the start of an HT transmission during the legacy SIGNAL field a. .11n device is informed whether an HT transmission is following, b. Legacy devices are not aware of this additional signaling c. Additional possibility is to encode the number of spatial streams or transmit antennas

i. .11n device can prepare for MIMO training right after decoding legacy signal field 2. Extend the capacity of legacy SIGNAL field with a few bits, which can only be seen by 11n devices

ii. Benefits 1. Earliest signaling of HT transmission during legacy SIGNAL to enable more robust and/or shorter HT

header by placing the HT training before the HT header a. Transmit HT header in more robust modes (e.g. LDPC, Turbo or RS+1/4 CC protection for HT

header) b. Shorten the header by moving all HT header into the higher-rate HT modes

2. Incremental increase of header size without the need for an additional OFDM symbol iii. Legacy Signaling Principal


Sept 2004 doc.: IEEE802.11-04/0983-01

1. During legacy signal field, HT information is embedded by slightly distorting BPSK constellation points in the Q-direction

2. Legacy device can still decode legacy signal field iv. Conclusions from Simulations

1. With 1 dB power employed by embedded signal, it is more robust than the companion legacy SIGNAL 2. Note that because of multiple receive chains in 11n devices, the error rate of the embedded signal and

the legacy SIGNAL will be lower than the error rate of SIGNAL in legacy 11a/g devices. v. Conclusion and Proposal

1. With 1 dB power employed by embedded signal, it is more robust than the companion legacy SIGNAL 2. Note that because of multiple receive chains in 11n devices, the error rate of the embedded signal and

the legacy SIGNAL will be lower than the error rate of SIGNAL in legacy 11a/g devices. l. Joerg Habetha presented the MAC proposal

i. Multiple MCS and Receiver Aggregation 1. Benefits

a. Increases throughput efficiency significantly b. Reduces buffering delay because MPDUs of different receivers can be aggregated c. Receivers can have different link qualities and data rates: d. Furthest receiver will not limit throughput of all other stations e. Aggregation of different Modulation and Coding Schemes (MCS)

ii. Conclusions on MAC 1. Multiple receiver aggregation reduces delay compared to single receiver aggregation 2. Aggregates with different MCS may either be aggregated or sent separately (MMRA versus SMRA) 3. MMRA is much more power efficient than SMRA 4. For MMRA trade-off between power and throughput efficiency 5. Chosen MMRA is not only more efficient than SMRA in terms of power consumption but also in terms

of throughput efficiency in most scenarios

6. MMRA (Multiple MRA) should be always preferred over SMRA (Single MRA) iii. One Page Summary on the Proposal by Pen Li

1. CE market requirements a. High throughput b. Increased robustness c. Extended coverage

2. Contributions a. 128-FFT for 20MHz will increase data rate with better error performance. b. Concatenated RS-CC improves robustness and extends range at low complexity.


Sept 2004 doc.: IEEE802.11-04/0983-01

c. Embedded signaling enables robust and efficient HT header transmission. d. Multiple MCS and Receiver Aggregation reduces power consumption and increases MAC

efficiency. iv. Q&A

1. Any interleaver between RS and CC? A – No 2. Slide 37, rate1/4 code? A – still doing simulations 3. Embedded signaling, what angle for only 1 bit? A – 1-bit for .47 rad

13. #17 Jim Allen, Appairent Technologies; 11-04-909r0; IEEE 802.15.3 MAC Elements for 802.11n a. Goals

i. The primary purposes of .11n (from various sources including Wi-Fi document 11-03-0736-00-000n) are: 1. to get higher throughput 2. more range 3. more robustness 4. uniform coverage 5. broaden the class of applications (like “Phase II” video hotspots) 6. backwards compatibility mode with .11 7. Get to market faster…

ii. 802.11 MAC 1. The 802.11 MAC is experiencing asymptotic throughput limit as a function of data rate. 2. QoS priority method permits “priority cheating” and collapses back into access issues 3. CAP still allows the network to be affected by network loading. Needs Access denial capability

iii. 802.15.3 MAC 1. Experiences asymptotic throughput at a much higher data rate and allows ways to reduce effect (like the

CAP is optional and there are ways to send multiple unique packets in one CTA) 2. Once a Time slot is assigned, inefficient contention for it stops 3. Uses access denial to prevent QoS reduction

iv. As a Result 1. As a result, we see:

a. Proprietary .11 extensions starting to appear b. …that work for small networks but not entertainment systems (e.g. synchronized video and

speakers) c. Promises by .11 members to produce “.11n” products before the standard is done

2. We also see: a. 802.15.3/3b is gaining traction b. …and can technically move easily in to IP services.

3. Market segmentation:


Sept 2004 doc.: IEEE802.11-04/0983-01

a. PC entertainment and CE entertainment will converge b. causing unnecessary choices by OEMs

v. Technology Realities 1. 802.11 already has excellent AP technology that is already being adapted to 802.15.3 designs 2. The 802.11 Mesh requirements outline MAC functions already in 802.15.3. Both groups have mesh

teams 3. Radio measurement and other .11 groups will add functionality that is also of interest to 802.15.3 4. 802.15.3 has coexistence capabilities that make it a good partner for 802.11 (like TPC and .11 channel

plan) 5. 802.15.3 has very efficient (>80%) TDMA based MAC capabilities but 802.11is probably the right

asynchronous approach 6. 802.15.3 had advance power save and ad hoc capabilities 7. 802.11 and 802.15.3 can use the same RF sections. Dual mode devices are on product roadmaps 8. 802.11 and 802.15.3 both use 128 bit AES CCM 9. 15.3 Rate Roadmap

a. 802.15.3 is a 55 Mbps standard TODAY. b. Currently available methods can increase rate to 167 Mbps at 2.4 GHz c. 802.15.3a sets the expectations at >110 Mbps (data rate) d. UWB activities already forcing the MAC to 480 Mbps chips by mid 2005. e. UWB customers expect 1 Gbps by start of 2006.

vi. The Opportunity 1. If we can get over the political hurtles and NIH (Not Invented Here) syndromes: 2. We have an opportunity to converge technologies 3. Simplifies OEM choices 4. Improve performance for all 5. Take advantage of the technologies developed in both groups 6. Get to market faster

vii. Joint Project 1. Fast process

a. Standard + Standard = Standard i. Specify correct link points

ii. Specify correct interface iii. Spend most of .11n resources on PHY improvements

b. The 15.3 MAC is already operational so testing can be done as the draft is written. c. This can speed the .11n total process


Sept 2004 doc.: IEEE802.11-04/0983-01

2. There may be an opportunity for Wi-Fi to take over WiMedia’s role for 15.3 allowing it to control the convergence message

viii. How to Support 1. This is a partial proposal (per 11-03/0665)

a. It can’t be voted on by itself so the analysis for the full proposal will be done after a merger b. Consider this a solicitation for Merger c. A judgment is needed as to whether this is within the scope of the PAR

14. Chair recessed the meeting at 8:54 PM Wednesday 9-15-04; 8:00 AM – 6:00 PM

1. Chair convened the meeting at 8:06 AM 2. #18 Sean Coffey, TI for WWiSE Group; 11-04-0951r2; WWiSE Group Partial Proposal on Turbo Codes

a. Overview i. The WWiSE complete proposal contains an optional LDPC code to enable maximum coverage and robustness

ii. FEC coding fits into the system design in a modular way, and in principle any high-performance code could be used instead of the LDPC code

iii. This partial proposal highlights an alternative choice for optional advanced code iv. The system proposed is identical to the WWiSE complete proposal in all respects except that the optional LDPC

code is replaced by the turbo code described here b. Motivation for Advanced Rate Coding

i. Advanced coding translates into higher achievable throughput at the same robustness ii. In particular, in most configurations the BCC (Binary Convolutional Codes – i.e., the .11 convolutional coder)

of rate ¾ and turbo code of rate 5/6 have approximately the same performance iii. Thus advanced coding enables a rate increase from ¾ to 5/6 without robustness penalty iv. At any given rate, advanced coding enhances coverage and robustness v. In addition, the modularity of the design means that the advantages carry over to every MIMO configuration

and channel bandwidth c. Complexity

i. Compare to state complexity of 64-state BCC decoding equivalent throughput ii. System assumptions: M-state constituent codes, I iterations, soft-in soft-out algorithm extra cost factor of a,

BCC duty factor of b iii. Decoder must process 2 x 2 x I x b trellis transitions (I iterations, 2 constituent codes, forward-backward for

each, less duty factor), each of which costs aM/64 as much 1. Overall complexity is 4I abM/64 times as much as 64-state code 2. E.g., with M = 8, I = 7, a = 1.5, b = 0.7, we have 3.675 times the state complexity


Sept 2004 doc.: IEEE802.11-04/0983-01

3. This does not account for other differences such as memory requirements and interleaver complexity d. Comparison of Turbo Codes and LDPC Codes

i. Turbo codes have a more extensive and stable literature, build on Viterbi decoding, have straightforward encoders

ii. LDPC codes have more flexibility, which may in principle be used to allow code design matched to decoder structure; more amenable to analysis

iii. To first order, both give the same performance tradeoffs e. Conclusion

i. Turbo code compensates for code rate increase to 5/6 from ¾ ii. Very well studied, extensive literature on performance and implementation

iii. Latency at end of packet may be handled by tailing; applicable to LDPC codes also iv. Generally similar issues and tradeoffs as LDPC codes

f. Q&A i. Bocks sizes, efficiency loses due fixed block A – 512 blocks is a good trade-off

ii. How to integrate into design for multiple streams? A – shorter block sizes but this is not desirable/ideal iii. What is the list of requirements so we can make a choice? A – choice of code is relatively orthogonal to rest of

system design and so use trial and error iv. How do you determine interactions? A – depends on parallelism; a trade-off. v. What is more important complexity or flexibility? A – tough to say as both LDPC and Turbo codes can do the

job 3. #19 George Vlantis, ST Microelectronics; 11-04-0899r3; ST Microelectronic MAC Partial Proposal for 802.11n CFP

a. Main Features Enhancements to the 802.11n MAC i. 802.11e Draft 9.0 Compatible:

1. Mandatory features: EDCA 2. Optional operation: HCCA and DLP

ii. Enhancements: 1. MSDU aggregation (mandatory) 2. Enhanced Block ACK for PPDU bursting (mandatory) 3. Piggybacking (optional) 4. Neighbor-list LC-EDCA (optional) 5. Super-frame LC-EDCA (optional)

Note: LC=low collision b. Neighbor List LC-EDCA (no central coordinator) c. How to support HT and retain QoS d. MSDU Aggregation

i. Multiple MSDUs in a single AMSDU (as in the WWiSE proposal [7])


Sept 2004 doc.: IEEE802.11-04/0983-01

ii. No changes to MAC-PHY interface iii. Increased MPDU sizes (max size = 8K) iv. An ACK for each aggregated MPDU

e. Enhanced Block Ack (EBA) for PPDU bursting i. Block Ack as in IEEE P802.11e/D9.0 but with:

1. Reduced 2us IFS (RIFS) for multiple destinations that require power adaptation 2. Zero IFS (ZIFS) for single destinations or when power amplifier is unchanged

f. Used NS2 as simulation environment g. MSDU Aggregation + Enhanced Block Ack: Conclusions

i. These two features are consistent with the WWiSE consortium proposal. ii. The penalty for the extra preamble replication for the Enhance Block Ack burst is not significant, but adds the

capability to adjust power levels in the case of multiple destinations and adds robustness to errors. iii. The combination of deciding the length of the aggregated MSDU and deciding the burst policy (i.e. single vs.

multiple destinations) is key to the scheduler. h. Piggybacking mode: Conclusions

i. Piggybacking mode performance heavy depends on the simulation scenarios. ii. Piggybacking is most effective when “symmetric” flows with low data rates and restrictive delay constraints

(e.g. VoIP flows) occur in a congested network. i. Neighbor-List LC-EDCA (Low Contention-EDCA)

i. Neighbor-list LC-EDCA is only used in an independent BSS. 1. A neighbor list is maintained in each STA. 2. Each STA allocates one weight to each of its neighbors.

ii. Two STA priorities are used to lower the collision probability 1. One STA has highest priority (it can transmit the first frame after a shorter LCIFS idle medium time) 2. Other STAs have low priority (they use the standard EDCA medium access method)

iii. The TXOP owner (the highest or low priority STA) selects the next highest priority STA (NHPS). This adds robustness and quick recovery in a scenario where packets are lost.

j. Neighbor-List LC-EDCA (NHPS selection) i. The NHPS is selected in a round-robin fashion, based on order in each STA’s table

ii. In each STA’s neighbor-list, each entry is of the form (STA ID, weight) iii. For the current NHPS, the weight is decremented on each TxOP. iv. When the remaining weight reaches zero the next neighbor becomes NHPS.

k. Super-Frame LC-EDCA i. Used in a BSS only

ii. The AP allocates the service period to each STA according to each STA’s load estimation iii. Two STA priorities are used


Sept 2004 doc.: IEEE802.11-04/0983-01

1. Highest priority in its own service period (SP) 2. Low priority in other STA’s service period

iv. A more effective power saving mode can be used 1. A non-AP STA becomes active in its own SP and in AP’s SP 2. The AP is always in active mode

v. STA in its own SP 1. Services more than one Access Category 2. Gets the first medium access right after the medium is idle for LCIFS 3. Uses the highest priority backoff timer (LCIFS, LCCACWmin, LCCACWmax) to get back the medium

access right with high probability again 4. Transmits the next frame at a SIFS period following the successful transmission of a frame if the

remaining SP allows the next frame transmission vi. STA in other STA’s SP

1. Uses the EDCA medium access method to access the medium. l. Neighbor-List LC-EDCA and Super-frame LC-EDCA: Conclusions

i. Collisions can be reduced in a distributed way for an IBSS using Neighbor-list LC-EDCA ii. Similarly, collisions can be reduced in a centralized way for a BSS using Super-frame LC-EDCA

iii. Both techniques reduce the wasted deferring time of EDCA iv. A simple round robin scheduler can be implemented. v. A weighting algorithm is demonstrated for selecting the Next-Highest Priority Station (NHPS).

vi. In super-frame LC-EDCA, when the highest priority station has no packets to send, the EDCA mechanism allows all the other low priority stations to contend for the media, thus reducing unused time.

m. Q&A i. When should different aggregation mechanism be used? A – best results if use both simultaneously

ii. Can you use Block Ack when piggybacking? A – yes although we did not simulate it. iii. Slide 10, Phy 121 mbps meaning? A – yes all streams are at this rate iv. Slide 10. enhanced Block Ack requires immediate block Ack? A – no v. Block Ack with multiple destinations, TA specs which RA should issue the block Ack? A – yes

vi. Legacy STA or Hidden node considered in LC-EDCA mode? A – EDCA is always running so legacy should be handled but you are correct we did not simulate

4. #20 Keith Chugg, TrellisWare; 11-04-0953r3; Flexible Coding for 802.11n MIMO Systems a. Overview

i. TrellisWare’s Flexible-Low Density Parity Check (F-LDPC) Codes 1. FEC Requirements for IEEE 802.11n 2. Introduction to F-LDPC Codes 3. F-LDPC Turbo/LDPC alternative interpretations


Sept 2004 doc.: IEEE802.11-04/0983-01

ii. Example Applications of F-LDPC Codes to the IEEE 802.11n PHY Layer 1. SVD-based MIMO-OFDM with Adaptive Rate Allocation 2. Open-loop Spatial Multiplexing MIMO-OFDM

a. MMSE Spatial Demultiplexing iii. Conclusions

b. FEC Requirements i. Frame size flexibility

1. Packets from MAC can be any number of bytes 2. Packets may be only a few bytes in length 3. Byte-length granularity in packet sizes rather than OFDM symbol

ii. Code rate flexibility 1. Need fine rate control to make efficient use of the available capacity

iii. Good performance 1. Need codes that can operate close to theory for finite block size and constellation constraint

iv. High Speed 1. Need decoders that can operate up to 300-500 Mbps

v. Low Complexity 1. Need to do all this without being excessively complex

vi. Proven Technology 1. Existing high-speed hardware implementations

c. TrellisWare’s Flexible F-LDPC Code i. A Flexible-Low Density Parity Check Code (F-LDPC)

1. Systematic code overall ii. Concatenation of the following elements:

1. Outer code: 2-state rate ½ non-recursive convolutional code 2. Flexible algorithmic interleaver 3. Single Parity Check (SPC) code 4. Inner Code: 2-state rate 1 recursive convolutional code

d. Irregular LDPC interpretation e. Decoder Throughput

i. Structure of the code lends itself to low complexity, high speed decoding ii. We have used a baseline high speed architecture with a nominal degree of parallelism of P=1

1. P=n throughput is n times higher, and complexity is n times greater iii. Plots for both throughput normalized to the system clock (bps per clk) and actual throughput with a number of

system clock assumptions iv. Existing P=8 FPGA prototype


Sept 2004 doc.: IEEE802.11-04/0983-01

1. System clock of 100 MHz 2. Throughput is 300 Mbps @ 10 iterations 3. Xilinx XC2V8000

f. Decoder Latency i. Example: Decoder latency needs to be < ~6 µs

1. Last bit in to first bit out ii. This can be achieved by a P=8 decoder with a 200 MHz clock

1. 12 iterations 2. < ~2048 bit code words

iii. With large MAC packets just ensure that final code word of packet is <2048 bits iv. As technology improves (higher clock or larger P) this minimum code word size can be increased

g. Proven Technology h. F-LDPC High Speed Implementation

i. FPGA implementations of F-LDPC 1. 300 Mbps @ 10 iterations with 100 MHz clock 2. Xilinx XC2V8000

ii. ASIC implementation of FlexiCode 1. A version of the F-LPDC with 4-state codes 2. More complex than F-LDPC with more features 3. BER of 10-10 in all modes 4. 196 Mbps @ 10 iterations with 125 MHz clock 5. 0.18 µm standard cell process

iii. Conclusions: IEEE 802.11n FEC requirements well met by the F-LDPC 1. Frame size flexibility

a. 3 bytes – 1000 bytes in single byte increments b. Simplifies MAC interface & allows latency requirements to be met

2. Code rate flexibility a. ½ - 32/33 in 45 steps (~0.25 dB SNR steps) b. Maximizes throughput and minimizes pad bits

3. Good performance a. Operates within 1 dB of theory across entire range

4. High Speed a. Decoders can be easily built to operate 500+ Mbps

5. Proven Technology/Low Complexity a. 300 Mbps FPGA-based decoders already built

iv. Q&A


Sept 2004 doc.: IEEE802.11-04/0983-01

1. In test block did UCLA do all BB simulations and you just gave them the object code for encoder and decoder? A – yes

2. Include UCLA test bed web links in bibliography? A – OK 3. Is ‘stopping criteria’ practical? A – yes 4. Slide 5, how do you handle different code rates for special streams? A – yes could vary rates within a

code block since systematic code 5. Modern codes have a constraint length over the entire block whereas convolutional codes only have a

local constraint rate 6. Performance over a fading Raleigh Channel? A – no

5. #21 Jon Rosdahl, Samsung; 11-04-0917r2; Partial MAC Proposal for 8032.11n a. New MAC Features

i. Two-level frame aggregation 1. Supports multiple destinations and multiple rates in a PPDU

ii. MAC header compression 1. Allows more efficient medium usage when multiple MPDUs are aggregated in a PSDU

iii. A service period for aggregation exchanges 1. Initiated by MP frame and is combined with dynamic TDM and CSMA/CA without collision and

unnecessary backoff delay iv. Smart Block ACK

1. Uses a two-level bitmap with a variable size instead of a fixed 128 octets as in the 802.11e Block ACK v. Three error recovery mechanisms

1. Used with the two-level frame aggregation mechanism vi. Operating modes

1. For coexistence between legacy STAs and HT STAs b. MP = multi-poll frame c. Error Recovery Mechanisms

i. MP-Frame: Immediate Error Recovery ii. MP-Frame: Coordinated Error Recovery

iii. MP-Frame: Implicit Error Recovery (use only in a very stable channel) d. Operating Modes

i. Pure mode 1. There are only HT STAs without any legacy STAs

ii. Mixed mode 1. There are legacy STAs and HT STAs together 2. Protection mechanisms (CTS-to-Self, RTS/CTS) are used in the CP

iii. Managed mode


Sept 2004 doc.: IEEE802.11-04/0983-01

1. HT AP can manage the access control between HT STAs and legacy STAs 2. CP for HT STAs is assigned in CFP.

6. Chair requested a volunteer to replace Colin Lanzl in his capacity as liaison to .19 for .11. This will become critical as .11n considers 40 MHz channelization. Apparently 802.15.1 has already prepared a letter stating that they had chosen their hopping sequence to coexist with .11’s 20 MHz channelization and this will be compromised if .11n adopts 40 MHz channelization.

7. Chair recessed the meeting at 3:08 PM 8. Chair reconvened at 4:00 9. #22 Fatih Ozluturk, InterDigital Communications Corp; 11-04-0932r1; Partial MAC and PHY Proposal for 802.11n

a. Outline i. MAC Proposal Highlights

1. MAC Characteristics 2. MAC Enhancements

a. Scheduled Resource Allocation Advantages b. Flexible Resource Management

3. MAC Legacy Support 4. MAC Simulation Results

5. PHY Proposal Highlights 6. PHY Enhancement

a. MIMO System Overview b. PHY Design c. SFBC with Eigen-beamforming

ii. PHY Simulation Results Summary

iii. Conclusions b. MAC Features and Advantages

i. Eliminates hidden node problem ii. Higher performance for non real time services:

1. Better stability and fairness towards AP iii. Higher performance for real time services while guaranteeing QoS:

1. Reduced STA power consumption and Higher MAC efficiency iv. Enhanced peer to peer direct transfer of data under control of the AP v. Backward compatibility:

1. With 802.11 MAC - 802.11e - 802.11k 2. STA and AP

vi. Support of efficient PHY operation


Sept 2004 doc.: IEEE802.11-04/0983-01

1. Multiplex of UL and/or DL users vii. Flexible design efficiently supports:

1. MIMO, FEC and H–ARQ 2. OFDMA support

viii. Both 20MHz and 40MHz HT STA in the same superframe c. Advantages of Scheduling (SRA)

i. Significant improvement in battery life 1. Enables new devices

ii. Efficient data management/processing 1. Allows simplified Radio Resource management (RRM) 2. Customization of devices to implement new features

iii. High MAC efficiency for stringent latency, low data rate applications (VoIP, new applications) iv. Scheduled resource allocations allows for true QoS management

d. Advantages of Flexible Management i. Enables efficient NRT allocations

ii. Higher MAC throughput 1. Eliminates hidden nodes 2. Common broadcast packet for all the allocation information within super frame (No 802.11 ACKs)

iii. Consistent and predictable MAC operation iv. Removed 802.11 contention overhead

1. No Exponential Back off after every attempt 2. Small Request Packet for Contention in slotted Aloha

v. Flexible, fair and efficient management of resources 1. Driven by application and PHY characteristics

e. Resource Coordination Function (RCF) i. RCF Management Channel Access (RMCA) for small packet transfers and schedule requests/reservations

ii. RCF Scheduled Channel Access (RSCA) for contention free data transfer providing full QoS support f. MAC Conclusions

i. Proposed MAC builds on 802.11 and 802.11e ii. MAC architecture enables

1. Elimination of hidden nodes 2. Prolonged battery life 3. Higher throughput 4. Radio Resource Management 5. Support of multiple PHYs

iii. Performance improvements have been demonstrated


Sept 2004 doc.: IEEE802.11-04/0983-01

g. PHY Features and Advantages i. Robust performance in all channel conditions, with or without channel state information

ii. Low complexity at both transmitter and receiver iii. Scalable solution: data rate, throughput iv. Accommodates any antenna configuration v. Flexible PHY that supports both backward compatibility and enhanced MIMO capability

1. Backward compatible with 802.11a/g 2. High throughput by leveraging OFDM MIMO

h. Motivation i. Maintain backward compatibility while supporting high throughput

ii. Find the best compromise between diversity gain and spatial multiplexing gain iii. Simplified operational modes

1. Open loop : -Initial acquisition, support of legacy equipment

2. Closed loop : -High throughput capability

iv. Simple scalable architecture i. High Throughput Using Closed Loop Eigen Beam forming Mode (CL-EBM)

i. Space-frequency coding (SFC) followed by eigen-beamforming (EBM) ii. Eigen-beamforming is based on Singular Value Decomposition (SVD) decomposition

1. Eigen-beamforming provides spatial multiplexing (high throughput) at a reasonable complexity 2. SVD splits the processing between the receiver and the transmitter 3. Channel is orthogonalized into eigenbeams that assure effective spatial-multiplexing 4. Does not require complicated receiver processing (no MMSE, SIC, etc) 5. Relaxed latency and feedback rates due to frequency non-selectivity of eigen-values

iii. SFC provides diversity gain iv. Robust link maintained with closed loop operation, Channel State Information (CSI) through feedback or

reciprocity j. Spatial beams instead of Eigen beams k. BFN = beam forming network l. PHY Conclusions

i. Robustness through Space-Frequency Coding ii. Spatial-multiplexing efficiency through eigen-beamforming

iii. Low implementation complexity is distributed between the transmitter and the receiver iv. Backward compatible with 802.11a/g v. Scalable to various antenna configurations


Sept 2004 doc.: IEEE802.11-04/0983-01

m. Overall Proposal Conclusions i. Partial proposals for backward compatible MAC and PHY

ii. MAC provides high efficiency and stability, reduces battery consumption and eliminates hidden nodes iii. Scalable PHY provides high throughput and robust performance, with low complexity

n. Q&A i. What was reference .11 MAC? A – EDCA

ii. How many eigen modes did you use to transmit data? A – all four with appropriate power loading iii. Does receiver need to know how many eigen beams? A – yes iv. In correlated channel only 1 eigen value? A – yes v. Could use technique to do 4x2? A – no, 2x2 or 4x4; 4x2 to be determined

vi. TGs doing AP to AP communication, could your technique be used to facilitate this? AP- possibly; centralized scheduled access versus polled access is easier for mesh networking

10. #23 Markus Muck, Motorola; 11-04-0913r4; IEEE 802.11n PHY Motorola HT Partial Proposal a. Outline

i. Overall goal and key features of proposal ii. Turbo Codes

iii. Multiple-Antenna schemes iv. OFDM modulator and data rates v. Preamble definitions

vi. Simulation results vii. Hardware complexity estimation

b. Goals Modification of IEEE 802.11a-1999 PHY in order to provide new OFDM PHY modes meeting the IEEE802.11n PAR with:

i. High spectrum efficiency for achieving target performance with increased data rates 1. Data streams transmitted in parallel using multi-antenna transceivers 2. Optimized multi-carrier modulation with lower overhead 3. Enhanced forward error correction schemes

ii. Improved link budget for lower to medium data rates 1. Providing the IEEE802.11a PHY data rates with increased range/link quality 2. Adapted to the support of services requiring small packet size such as VoIP 3. Exploit multi-antenna capabilities for robust transmission modes 4. Turn gains in spectral efficiency into link budget advantages

iii. Favored short term implementation and deployment with robust, low complexity techniques


Sept 2004 doc.: IEEE802.11-04/0983-01

1. Open-loop multi-antenna solutions: simple, robust and without protocol overhead (feedback signalization)

2. Improve operation in limited Outdoor environments with support of long channel impulse responses c. Key Features

i. Multi-antenna extension: 1. MIMO with at least 2Tx/2Rx antennas scaling up to 4Tx 2. Support for asymmetric antenna configurations to accommodate various classes of devices 3. Open-loop modulation technique

ii. Second OFDM modulator (optional): 1. 2 bandwidths supported: 20MHz and 40MHz 2. Optionally 128 carriers in 20/40MHz with 104 data carriers, and guard interval of 32 samples

a. 8% PHY rate increase for 20MHz mode b. 117% PHY rate increase for 40MHz mode vs 20MHz/64-carriers

iii. Turbo Codes: Increase robustness iv. New nPLCP preambles for MIMO support

(same for 64- and 128-point IFFT/FFT) v. High order modulation (optional): 256-QAM

vi. Space/frequency interleaver vii. Compatibility to legacy systems:

1. IEEE 802.11a convolutional code with code rates 1/2, 2/3, 3/4 and 5/6 d. Conclusion

i. Proposal: MIMO extension of IEEE802.11a addressing ii. Short term implementation needs through mandatory modes relying on a mix of STBC and SDM

iii. Take into account device size constraints allowing asymmetric TX/RX antenna configuration independent upgrade of APs / MTs possible

iv. Enable PHY throughput covering 54Mbits/s 180 (468) Mbps

e. Q&A i. Differences between your presentation and the other Mitsubishi/Motorola presentation? A – Turbo codes,

OFDM new modulation extensions including 40 MHz ii. Backward compatibility of pre-ambles? A – not compatible with legacy, no mixed mode capability

11. Chair recessed the meeting at 5:40 Thursday 9-16-04; 8:00 – 9:30 PM

1. Chair called TGn to order at 8:00 AM


Sept 2004 doc.: IEEE802.11-04/0983-01

2. #24, Heejung Yu, ETRI; 11-04-0922r0; ETRI Proposal to IEEE802.11 TGn a. Outline

i. Proposed technologies for >200Mbps in PHY 1. MIMO-OFDM 2. Dual band

ii. Detail Standard iii. Simulation Results iv. Conclusions

b. Candidates i. Legacy IEEE 802.11a => 20MHz BW, 54Mbps

ii. To achieve more than 100Mbps at the top of the MAC SAP, we need x3 or x4 data rate. 1. Depending on MAC efficiency

iii. To extend x4 transmission 1. MIMO (improve spectral efficiency) 2. Bandwidth extension 3. High order modulation 4. High rate coding

c. MIMO i. Data rate can be increased with the number of Tx antennas.

ii. We have some problem in using 3 and more stream. 1. Implementation complexity 2. Limitation on antenna spacing, high MIMO channel correlation can be a problem.

iii. So, we cannot fully rely on the MIMO technology for 3 or 4x data rate.

d. Bandwidth Extension i. Clock doubling

1. 802.11a modem with clock switching function 2. Protection mechanism for compatibility

ii. Dual band 1. 802.11a modem (2 units) or 802.11a modem with some change( using 128 point FFT) 2. Compatible with legacy 802.11a (refer specification part)

iii. New OFDM parameter 1. 802.11a + new modem with new OFDM parameters( # of subcarrier, # of CP, etc.) 2. Protection mechanism for compatibility

e. Dual Band i. Merits


Sept 2004 doc.: IEEE802.11-04/0983-01

1. More flexible implementation 2. We extend threefold, fourfold BW systematically by increasing number of FFT or FFT size. 3. Compatible preamble and SIGNAL field is possible. 4. More robust to DC-offset (11 DC-carrier)

ii. Demerits

1. Reduce the number of channel 2. In some countries, only 20MHz channel usage is allowed

f. Max Data Rate Mandatory i. # of Tx and Rx antennas = 3

1. We use 2 Tx antennas out of 3 antennas (include Tx antenna selection option) ii. # of Tx streams (MIMO gain) = 2

iii. Dual-band (data rate gain) = 2 iv. Achievable Data Rate = 2 x 2 x (legacy rate) = 216Mbps v. In optional mode, 288Mbps (256-QAM, 3/4 code rate) is possible.

g. Main Features of ETRI Proposal i. Compatible with IEEE 802.11a

ii. Bandwidth : 20 or 40MHz iii. Multiple antennas : 2 Tx antennas

1. 3 Rx antennas are recommended. 2. Tx antenna selection is available.

iv. Modulation : Legacy OFDM, SDM-OFDM, STBC-OFDM v. Data Rate

1. 20MHz BW:6,9,12,18,24,36,48,54,72,96,108,128,144 Mbps 2. 40MHz BW : doubled

h. Taehyun Jeon presented the simulation results i. Detection Method

1. In Legacy OFDM, Maximal Ratio Combining method is used. 2. In SDM-OFDM, Zero Forcing scheme is used.

a. The simplest and reasonable method considering both implementation complexity and performance

b. In higher order modulation and smaller number of Nt case, SNR loss between ZF and ML (Maximum Likelihood) becomes lower.

i. Conclusion i. In this proposal, MIMO-OFDM with 2 transmit antennas and dual band scheme are used for higher data rate

(throughput).


Sept 2004 doc.: IEEE802.11-04/0983-01

1. SDM-OFDM : double data rate 2. Dual band : double data rate 3. STBC-OFDM : increase link reliability (optional)

ii. To satisfy the FR (100Mbps throughput in 20MBz), 256-QAM is added (144Mbps in 20MHz band) iii. Compatible with 802.11a (Preamble and SINGAL structure)

j. Q&A i. Slide 36, Maximal ratio combining, what are you combining? A – both streams

ii. Slide 6, double clock rate and yet 64 FFT, what about guard interval? A – did not change 3. #25, Sean Coffey, WWiSE Proposal (Airgo, Bermai, Broadcom,Conexant, RealTek, STMicroelectyronics, Texas

Instruments); 11-04-935r3; WWiSE IEEE 802.11n Proposal a. WWiSE Approach

i. WWiSE = World Wide Spectrum Efficiency ii. The partnership was formed to develop a specification for next generation WLAN technology suitable for

worldwide deployment iii. Mandatory modes of the WWiSE proposal comply with current requirements in all major regulatory domains:

Europe, Asia, Americas iv. Proposal design emphasizes compatibility with existing installed base, building on experience with

interoperability in 802.11g and previous 802.11 amendments v. All modes are compatible with QoS and 802.11e

vi. Maximal spectral efficiency translates to highest performance and throughput in all modes b. Key Mandatory Features

i. The WWiSE proposal’s mandatory modes are: 1. 2 transmit antennas 2. 20 MHz operation 3. 135 Mbps maximum PHY rate 4. 2x1 transmit diversity modes, 20 MHz 5. Mixed mode preambles enabling on-the-air legacy compatibility 6. Efficient greenfield preambles – no increase in length over legacy 7. Enhanced efficiency MAC mechanisms 8. All components based on enhancement of existing COFDM PHY

2x2 MIMO operation in a 20 MHz channel: Goal is a robust, efficient, small-form-factor, universally compliant 100 Mbps mode that fits naturally with the existing installed base

ii. Key Optional Features 1. The WWiSE proposal’s optional modes are:

a. 3 and 4 transmit antennas b. 40 MHz operation


Sept 2004 doc.: IEEE802.11-04/0983-01

c. Up to 540 Mbps PHY rate d. 2x1, 3x2, 4x2, 4x3 transmit diversity modes e. Advanced coding: Rate-compatible LDPC code

iii. 1600 ns cyclic shift nice property is tones alternate 1, -1, 1, -1, ….. iv. Mathew Fischer presented the MAC Features

1. The WWiSE proposal builds on 802.11e functionality as much as possible, in particular EDCA, HCCA, and Block Ack

a. Block Ack mandatory 2. Backward compatibility 3. Simplicity

a. Shorter time to standardization b. Shorter time to productization

4. Effectiveness a. Eliminate the big bottlenecks

v. Aggregation 1. Bursting and Aggregation:

a. MSDU aggregation i. Increased maximum PSDU length, to 8191 octets

2. PSDU aggregation = HTP burst: a. sequence of MPDUs from same transmitter b. Reduced interframe spacing

i. 0 usec if at same Tx power level and PHY configuration ii. 2 usec otherwise (with preamble)

iii. Not dependent on RA vi. HTP Burst vs. MSDU Aggregation

1. HTP burst allows aggregation without incurring latency cost (on-the-fly aggregation) 2. HTP allows multiple RA per burst 3. HTP allows multiple rates within burst 4. HTP allows varying TX power within burst

vii. Block Ack 1. Block Ack frames now have ACK policy bits

a. Allows: i. Normal ACK behavior per 802.11e draft

ii. No-ACK iii. other settings reserved

b. Reduces Block Ack overhead


Sept 2004 doc.: IEEE802.11-04/0983-01

i. by eliminating explicit ACKs (as an option) c. Allows multiple RA + Block Ack Frames within a single HTP burst

i. if immediate ACK required: 1. HTP burst broken to allow SIFS + ACK 2. HTP burst single RA, ending with Block Ack Request + SIFS + ACK 3. HTP burst single RA, ending with Block Ack Request + Block Ack + ACK

ii. without immediate ACK 1. HTP burst is allowed to continue 2. HTP burst may contain multiple Block Ack Request to multiple RA

d. Effectively allows additional, more efficient modes of use for Block Ack mechanism viii. Legacy Interaction

1. N-STA detection/advertisement a. Identification of TGn and non-TGn devices and BSSs b. Extends ERP information element c. Uses proven 802.11g signaling

2. Legacy Protection mechanisms a. Existing protection mechanisms (extended to N/G case) b. Addition of PLCP length spoofing

3. 40/20 MHz channel switching supported a. Equitable sharing of resources with legacy

ix. Simulations 1. PHY model in MAC simulations

a. Detailed description in IEEE 802.11-04/877r3 b. TGn MIMO Channel Models c. Impairments as specified by FRCC d. Union bound technique to estimate PHY layer frame errors e. Performance closely matches full simulations for mandatory phy configurations

i. Binary convolutional coding f. Executes as MATLAB routine called by MAC simulator in NS

x. Ways of achieving 100 Mbps throughput robustly: 1. 2x2, 20 MHz channel, 121.5 Mbps mode, BCC, MMSE detection.

a. Requires high MAC efficiency; achievable with both HCCA and EDCA 2. 2x2, 20 MHz channel, 135 Mbps mode, LDPC, MMSE detection 3. 2x3, 20 MHz channel, 135 Mbps mode, BCC, MMSE detection.

a. Requires third radio receive chain; meets feasibility threshold easily


Sept 2004 doc.: IEEE802.11-04/0983-01

4. 2x2, 20 MHz channel, 135 Mbps mode, near-ML detection

a. Requires reduced-complexity algorithms for detection xi. 40 MHz is NOT mandatory but rather an option

xii. WWiSE Patent Position 1. Essential patent claims owned or controlled by WWiSE companies will be available on zero royalty

basis a. Important information on terms & conditions available at

i. http://www.wwise.org/IPinformation.htm ii. http://www.wwise.org/IPstatement.htm

2. IEEE strictly limits discussion of licensing terms & conditions at IEEE meetings

a. WWiSE representatives can answer any questions outside of IEEE meetings b. Please feel free to contact any of the WWiSE representatives shown on next slide…

c. Q&A i. Are Patent Policy links allowed in the presentation material? A – Chair said slide complied within the limits set

by the IEEE patent disclosure policy. 4. #26, John Ketchum, Qualcomm; 11-04-0873r2; High-Throughput Enhancements for 802.11: Features and Performance of

QUALCOMM’s Proposal a. Main Points

i. 20 MHz operation ii. Maximum PHY data rates:

1. 202 Mbps for 2 Tx; 404 Mbps for 4 Tx iii. Backward compatible modulation, coding and interleaving iv. Highly reliable, high-performance operation with existing 802.11 convolutional codes used in combination with

Eigenvector Steering spatial multiplexing techniques v. Fall-back to robust Spatial Spreading waveform for uninformed transmitter

vi. Backward compatible preamble and PLCP with extended SIGNAL field. vii. Adaptation of rates and spatial multiplexing mode through low overhead asynchronous feedback. Works with

TXOPs obtained through EDCA, HCF or ACF. viii. PHY techniques proven in FPGA-based prototype

b. MAC portion was presented by Sanjiv Nanda c. Objectives

i. Preserve the simplicity and robustness of distributed coordination ii. Backward compatible

iii. Enhancements for high throughput, low latency operation


Sept 2004 doc.: IEEE802.11-04/0983-01

iv. Build on 802.11e, 802.11h feature set: 1. TXOPs, 2. Block Ack, Delayed Block Ack, 3. Direct Link Protocol 4. Dynamic Frequency Selection 5. Transmit Power Control

d. MAC Feature Summary i. Low overhead Rate Feedback

ii. Frame aggregation iii. Eliminate Immediate ACK for MIMO transmissions iv. PPDU Aggregation from AP to multiple STAs using SCHED and SCAP

1. Reduced IFS v. Managed Peer-to-Peer

vi. Adaptive Coordination Function (ACF) vii. Compressed Block Ack

viii. QoS-capable IBSS with round-robin scheduling e. Low latency operation is critical

i. To operate with small buffers. This is critical at high data rates. ii. For MIMO operation with EDCA, HCCA or ACF

1. Rate and Mode Feedback 2. Eigenvector Steering

iii. To meet low delay guarantees for multimedia applications in all operating regimes f. Different access methods can provide low latency in different operating environments

i. EDCA/HCCA with lightly loaded system ii. RRBSS (with or without AP)

iii. Scheduled operation for heavily loaded system g. Simulation Methodology

i. The simulator is based on ns2 ii. Includes physical layer features

1. TGn Channel Models 2. PHY Abstraction determines frame loss events

iii. MAC features 1. EDCA 2. HCCA 3. Adaptive Coordination Function (ACF): SCHED and SCAP 4. Frame Aggregation


Sept 2004 doc.: IEEE802.11-04/0983-01

5. ARQ with Block Ack. No compressed Block Ack 6. Closed Loop Rate Control (DRVF and DRV) 7. MIMO Modes (ES and SS)

iv. Scheduler 1. Based on delay requirement and buffer status of flows. Similar to 802.11e Annex H

v. Transport 1. File Transfer mapped to TCP 2. QoS Flows mapped to UDP

h. Fixed Simulation Conditions i. The following parameters are fixed for all system simulation results.

1. Bandwidth: 20 MHz. 2. Frame Aggregation 3. Fragmentation Threshold: 100 kB 4. Delayed Block Ack 5. Adaptive Rate Control 6. Adaptive Mode Control between ES and SS

i. Varied Simulation Conditions i. Bands:

1. 2.4 GHz 2. 5.25 GHz

ii. MIMO: 1. 2x2: All STAs with 2 antennas 2. 4x4: All STAs with 4 antennas 3. Mixed:

a. Scenario 1: the AP and the HDTV/SDTV displays are assumed to have 4 antennas; all other STAs have 2 antennas.

b. Scenario 6: AP and all STAs, except VoIP terminals have 4 antennas; VoIP terminals have 2 antennas.

iii. OFDM symbols 1. Standard: 0.8 µs Guard Interval, 48 data subcarriers 2. SGI-EXP: 0.4 µs Shortened Guard Interval, 52 data subcarriers

iv. Access Mechanisms 1. ACF (SCHED/SCAP) 2. HCF (Poll/CAP) 3. EDCA with additional AC for Block Ack

j. Simulation Observation Summary


Sept 2004 doc.: IEEE802.11-04/0983-01

i. MAC Efficiency with Frame Aggregation 1. ACF: between 0.65-0.7 (2x2) reduces to 0.6 (4x4) 2. HCF: around 0.5 (2x2) reduces to 0.4 (4x4) 3. EDCA: around 0.45 (2x2) reduces to 0.23 (4x4). No increase in throughput of EDCA with 4x4.

ii. More QoS flows are satisfied with HCF than with EDCA. However, ACF is required to address stringent QoS requirements.

iii. Frame Aggregation is not enough, need ACF for a future-proof MAC iv. Throughput versus Range

1. Throughput above the MAC of 100 Mbps is achieved at: a. 29 m for 2x2, 5.25 GHz b. 40 m for 2x2, 2.4 GHz c. 47 m for 4x4, 5.25 GHz d. 75 m for 4x4, 2.4 GHz e. The plots for Channel Model B and Channel Model D are roughly similar.

2. Significantly higher range compared to other proposals. k. John Ketchum presented the PHY portion of the proposal; PHY Design Highlights

i. Fully backward compatible with 802.11a/b/g 1. 20 MHz bandwidth with 802.11a/b/g spectral mask 2. OFDM based on 802.11a waveform

a. Optional expanded OFDM symbol (4 add’l data subcarriers) and shortened guard interval ii. Modulation, coding, interleaving based on 802.11a

1. Expanded rate set iii. Scalable MIMO architecture

1. Supports a maximum of 4 wideband spatial streams iv. Two forms of spatial processing

1. Eigenvector Steering (ES): via wideband spatial modes/SVD per subcarrier a. Tx and Rx steering b. Over the air calibration procedure required

2. Spatial Spreading (SS): modulation and coding per wideband spatial channel a. No calibration required b. SNR per wideband spatial stream known at Tx

v. Use of Eigenvector steering extends the life of low-complexity 802.11 BCC vi. Sustained high rate operation possible via rate adaptation

1. low overhead asynchronous feedback. vii. PHY techniques proven in FPGA-based prototype

l. Feedback for ES and SS Modes


Sept 2004 doc.: IEEE802.11-04/0983-01

i. Rate adaptation 1. Receiving STA determines preferred rates on each of up to four wideband spatial channels

a. One rate per wideband spatial channel – NO adaptive bit loading 2. Sends one 4-bit value per spatial channel, differentially encoded, (13 bits total) to inform corresponding

STA/AP of rate selections a. Corresponding STA/AP uses this info to select Tx rates b. Piggy-backed on out-going PPDUs

3. SS Mode can use single rate across all spatial streams ii. Channel state information

1. For ES operation, Tx must have full channel state information 2. This is obtained through exchange of transmitted training sequences that are part of PLCP header

a. Very low overhead. 3. Distributed computation of steering vectors (SVD calculation)

a. STAs do SVD, send resulting training sequence to AP 4. For SS operation, unsteered training sequences transmitted in PLCP header to support channel

estimation at receiver iii. Feedback operates with asynchronous MAC transmissions

m. Highlights of PHY Simulation Results i. Highest PHY throughputs achieved in Eigenvector Steering mode

1. Eigenvector steering is very effective in combination with 802.11 convolutional codes 2. 256-QAM contributes substantially to throughput in ES mode. ES array gain overcomes effects of

receiver impairments in these cases ii. Convolutional codes not as effective in Spatial Spreading mode

1. High SNR variance across subcarriers within an OFDM symbol on an SS spatial channel degrades the performance of convolutional codes

2. This is particularly pronounced on channel B and on link with 4 Tx and 2 Rx. 3. Reducing number of streams (NS < min(NTx,NRx)) reduces variance and improves overall performance.

iii. Rate adaptation has clearly demonstrated benefits 1. Many cases where a given fixed rate has poor average performance, but using rate adaptation, higher

overall throughput is achieved with lower PER 2. Part of rate adaptation is controlling the number of streams used

iv. Use of shortened guard interval and extra data subcarriers contributes to increased throughput 1. Increased vulnerability to delay spread and ACI. 2. Improved receiver design should help with this 3. Optional mode can be turned off in the presence of too much delay spread


Sept 2004 doc.: IEEE802.11-04/0983-01

4. Many environments where high rates will be required, such as residential media distribution, have naturally low delay spread.

n. Q&A i. Is one bit in PLCC header sufficient protection? A – can be changed

ii. On Slide 45 why does TP rise at high SNRs? A – Not perfectly calibrated iii. How stable is calibration? A – stable from day to day

5. #27, Wei Lih, Panasonic; 11-04-0907r2; Partial Proposal for TGn a. Panasonic focus is the home – A/V, VoIP, Command b. Required MAC throughputs (short term target) of 80Mbps for AV streaming applications

i. Home environments ii. Varying channel conditions (LOS/NLOS included)

c. Lower throughputs required for handheld equipment in hotspot environments d. TGn proposals should provide QoS support for

iii. Long packets (eg: AV streaming) iv. Short packets (eg: VoIP & Command)

e. Candidate Solutions i. MAC

1. Reuse of .11e QoS mechanisms 2. Improved medium utilization

a. Aggregated data frames b. Reduced access overheads

ii. MIMO OFDM PHY

1. Reuse of .11a modulation schemes 2. 2x2 and 3x3 antenna configurations 3. Good performance in different conditions

a. New pilot structure for improved channel estimation b. New interleaving scheme for improved performance

f. PHY portion was presented by Takashi Fukagawa i. Scattered & Staggered Pilot Subcarriers - Motivation

1. Legacy continuous pilot subcarriers are not suitable for TGn: a. In a selective fading environment, received power of particular subcarriers may be very low. b. In MIMO transmission, when residual frequency offset between each branch or phase noise

exists, receiver performance will deteriorate. ii. Scattered & Staggered Pilot Subcarriers - Features

1. Proposed pilot scheme improves receiver performance


Sept 2004 doc.: IEEE802.11-04/0983-01

a. Four pilot subcarriers in each OFDM symbol i. Pilot positions are scattered in every OFDM symbol

ii. Robustness in a frequency selective fading environment 2. Pilot insertion is staggered in OFDM symbols from different transmit branches

a. Enables phase offset estimation on each path 3. Results show that proposed pilot scheme is effective in canceling out the residual frequency offsets and

compensating for phase noise iii. Varying Interleave Patterns – Motivation

1. Spatial MUX may be used for high rate transmissions a. Assumption for best performance – uncorrelated channels

i. However in real deployments, there may be channel correlation, detracting from the benefits of spatial MUX

2. Viterbi decoding introduces burst errors a. Iterative decoding helps improve BER performance

iv. Varying Interleave Patterns – Approach 1. Proposed enhancement 2. Reduce correlation between different spatial streams through the use of different interleavers on

different streams 3. Use of different interleavers, when combined with iterative decoding also reduces the burst error effects

that are introduced during Viterbi decoding v. Varying Interleave Patterns – Summary

1. Results show an improvement with VIP in both LOS and NLOS environments 2. It is possible to implement VIP in several ways

a. Single encoder/interleaver implementation also possible (see Annex A1) 3. VIP receiver implementation is vendor dependent

a. enhanced architectures can realize higher gains g. Q&A

i. None 6. #28 Aryan Saed, IceFyre Semiconductor; 11-04-882r2; Optimized MIMO

a. A Strawman – What could happen i. Mandatory: HT-n (High Throughput 802.11n)

ii. SMX 2x2 iii. MAC with feedback allowance for fast rate adaptation (SNR based), feedback fields for CSI, calibration, beam

forming, with parts of 802.15 “best practices” for convergence iv. 20MHz for maximum cell density and pan-regulatory coverage v. BCC 64QAM (64pt FFT) for proven robustness


Sept 2004 doc.: IEEE802.11-04/0983-01

1. performance meets PAR 2. MAC is ready for TGn-options (below) 3. TGn label is credible and label is fast to market on the shelves from broad range of vendors 4. ready for high volume, high yield 5. pan regulatory 6. dense cell planning

b. Optional: for VHT-n (optimizations for Very High Throughput) i. SMX 3x3, 4x4,

ii. STBC NxM (M<N) for heavy-AP and light-STA, e.g. 4x2 iii. Beam forming for low RF cost where Doppler allows iv. 40MHz for low RF cost where cell density and regulations allow v. High performance FEC (LDPC/TC) for extended reach where latency allows

vi. 128QAM & 256QAM where high quality RF (phase noise and distortion) allows (combinations of 1-6 allowed)

1. enables very high throughput 2. flexibility in terms of how very high throughput may be achieved, depending on application and

deployment circumstances 3. ready for future analog and RF design improvements and circuit techniques

c. Vendor discretionary optimization: Mandatory mode has MAC level feedback mechanisms in place for

i. RF level beam forming ii. Beam forming matrix calculation (SVD, other), includes spatial averaging (Hadamard or Fourier) for broadcast

1. Leverages 11n into realms of vendor distinction in broad or niche high performance markets 2. Enables vendors / labs to experiment with future technology for ultra high throughput standards

compliant systems d. Proposal for Optimized MIMO

i. MIMO using channel diagonalization ii. Allow vendor discretionary optimization for maximum rate and/or maximum reach without adding complexity

and options iii. Allow vendor discretionary optimization of hardware and overhead through mutual signaling of MIMO

complexity without adding options e. Implications of SVD

i. SVD maximizes theoretical (Shannon) capacity ii. SNR per stream is ranked according to singular values of channel matrix H


Sept 2004 doc.: IEEE802.11-04/0983-01

iii. In practical TGn channels the SNR per sub-carrier can differ by 10dB..20dB as a result of singular value spread iv. To maximize practical capacity, rate depends on SNR v. Usually only the strongest mode can support maximum rate (e.g. 256-QAM)

vi. rates in all other modes are then backed-off, some only support a fraction (half, quarter, eighth) of the maximum (e.g. 16-QAM)

vii. Rate across multiple streams not equal. Example: one stream at 54Mbps, another at 24Mbps. Data-bit multiplexing becomes a PHY function, keeping both streams equal duration (e.g. 0.25 ms)

viii. Large portion of bits on the strongest mode. Remainder of bits on remaining weaker modes. f. Implications of QR-Eig

i. QR-Eig has equal SNR across streams ii. Same rate and length per stream

iii. Same interleaver and FEC iv. Same latency, and same PER v. Data-bit multiplexing can be a MAC function: one MSDU per stream.

g. QR-Eig has value in 10-12 meter range h. Objective

i. To allow vendor choice of algorithm : SVD, QR-Eig or other vendor algorithm ii. optimized for particular usage scenario (reach, rate, latency, low cost RF, and rapid 11n deployment). Consider

that -IM4 Phase Noise is 0.5deg rms -IM1 RAPP PA model is -40dB EVM

iii. Ensure mechanisms are in place in TGn to allow calculation of T and R matrix at one side of the link, and iv. to communicate matrix from STA to AP or from AP to STA so that matrix can be operated at both sides (Tx

and Rx side) of link v. To ensure mechanisms are in place in standard to allow reduced overhead from coefficient exchange

vi. Example: AP requires grouping of 4 sub-carriers due to its reduced hardware complexity. vii. Groups of 4 or 8 sub-carriers reduces T and R matrix calculation and update overhead by a factor of 4 and 8

respectively. viii. STA and AP must communicate their capabilities

i. Overview i. Some further implications of MIMO with diagonalization:

ii. Stream splitting: FEC, interleaving iii. MIMO Header

j. MIMO Header Service Field signifies


Sept 2004 doc.: IEEE802.11-04/0983-01

i. During Link Set-up, sub-carrier grouping: no grouping (52 matrices), groups of four (16 matrices), groups of eight (8 matrices).

ii. During Link Set-up, supported rates, equal rate across all streams or stream dependent rate Service Field (STA side calculation)

iii. During Link operation: regular feedback of channel estimation from AP to STA for matrix calculations iv. During Link operation: regular update of Tx side diagonalization coefficients from STA to AP

k. Proposal Summary i. Frequency domain diagonalization

ii. Vendor discretionary algorithm (e.g. SVD, QR with Eigenvector, other) iii. Orthogonal LTS for MIMO Channel Estimation iv. Vendor discretionary grouping of sub carriers (no grouping, grouping with 4, or 8 adjacent sub carriers)

l. Q&A i. Complexity to calculate SVD or QR-Eig? A – can’t give an exact number

ii. What about STBCs? A – did actually consider these iii. How many decompositions did you try? A – 3 or 4 and was surprised that QR-Eig performed so well iv. Dynamic range of coef values? A – Q is orthonormal so well behaved, R is well behaved; SVD has higher

variation v. Limitations? A – power coming out of the two Pas in a 2x2 system are not the same

vi. Slide 16, difference in performance is because the bit rate was constrained? A – that was the point, we were after range.

vii. Did you experiment with different ADC resolution? A – no viii. PAPR measurements? A – no

7. #29, Aleksandar Purkovic, Nortel; 11-04-0885r0; Stuctured LDPC Codes for Advanced Coding Scheme for 802.11n a. Motivation

i. LDPC codes have matured and become a strong advanced coding candidate due to a significant activity in the coding community, especially during the last several years

ii. LDPC codes are proved to achieve coding gains comparable to turbo codes iii. Benefits of LDPC codes as a serious advanced coding candidate were introduced to the 802.11n in the past ([5],

[6], [16]) iv. Main problem associated with the LDPC decoder design is usually requirement for highly irregular hardware

interconnectivity v. Considerable effort has been invested in finding effective hardware architectures in order to benefit from the

sparseness of the LDPC parity check matrix vi. LDPC codes based on a structured parity check matrix greatly reduce decoding hardware bottlenecks with

tolerable performance penalty


Sept 2004 doc.: IEEE802.11-04/0983-01

vii. LDPC parity check matrices with lower (upper) triangular segments enable efficient encoding, eliminating another obstacle, typically associated with implementation of LDPC codes

b. Effective code length of example is 4 c. Performance Evaluation Methodology

i. PHY model based on the 802.11a spec. [12]; code rate 7/8 added. ii. Simulation environment

1. Partial compliance with CC59 and CC67 2. One spatial stream, 20MHz configuration 3. AWGN channel 4. Fading Channel Model D with power delay profile as defined in [13], NLOS, without simulation of

Doppler spectrum. This implementation utilizes reference Matlab code [14]. 5. Simulation scenario assumed:

a. Ideal channel estimation b. All packets detected, ideal synchronization, no frequency offset c. Ideal front end, Nyquist sampling frequency

iii. K = 1000 bytes, minimum 100 frame errors, down to PER of 10-2 iv. Code specific

1. Convolutional codes: Viterbi decoding algorithm 2. LDPC codes:

a. Iterative Sum-Product decoding algorithm with maximum of 20 iterations b. Concatenated codewords c. Channel interleaver was not used (no need for it)

d. Summary and Conclusion i. Family of structured LDPC codes has been designed for the 802.11n application.

ii. Design objectives: iii. Performance improvement over existing convolutional codes iv. Simple encoding algorithm v. Coverage of a broad range of information packet lengths and code rates

vi. Support for additional code rates higher than the current maximum (3/4) vii. Enable efficient decoder hardware implementation

viii. These structured LDPC codes are designed to be “architecture aware”, [15], and can overcome most of the implementation issues, associated with practical implementations so far.

ix. LDPC codes presented in this contribution can be further refined to fit better 802.11n standard as it shapes up, especially considering various MIMO schemes.

e. Q&A i. Slide 4; irregular LDPC code? A – yes or quasi regular


Sept 2004 doc.: IEEE802.11-04/0983-01

8. In the remaining meeting time for this slot the chair introduced the topic of logistics for November a. Reviewed progress to date b. Suggested 2 hours for each complete proposal followed by a panel discussion c. The two hours would provide adequate time for Q&A d. Don’t know for sure how many complete proposals there will be e. There appear to be requests for general presentation time f. We only get 16 hours in Nov. g. Assuming 5 completes => 10 hours h. Panel Discussion => 2 hours (all Q&A) i. Additional Consensus Building Presentation = 2 hours j. 5 min. summary each => 30 min k. Low hurdle vote => 30 min l. That leaves 1 hour m. Discussion – what about officer elections n. Reminder - 11-03-665r9 is the selection procedure document o. Deadline for new completes is 10 days before the Nov. meeting including FRCCs p. Why 2 more hours for consensus building presentations? Chairs answer - comparison of alternatives, for example

advanced coding techniques q. Would panel discussion of partials be possible? Chair answered yes time permitting

9. #30 Pangan Ting, CCL/ITRI; 11=-04-1014r4; Partial Proposal for 802.11n: ITRI Preamble Specification a. Outline

i. System block diagram ii. Proposed preamble structure

iii. Short training symbol 1. Purpose of short training symbol 2. Construction of short training symbol 3. Numerical Results

iv. Long training symbol 1. Purpose of long training symbol 2. Construction of long training symbol 3. Numerical Results

v. Conclusion b. Short Training Symbol

i. Purposes of STS 1. Frame detection, AGC and Coarse frequency offset estimation 2. The new STSs from different Tx antenna have zero cross-correlation.


Sept 2004 doc.: IEEE802.11-04/0983-01

3. The preamble consists of several concatenated copies. ii. Backward compatibility

1. Assume there exists a protection mechanism similar to the case of 11g and 11b. 2. We propose that the new STSs should not be detected by legacy systems. 3. The new STS should have the period longer than the legacy systems.

c. The properties of the proposed STSs i. Period of 32 samples

ii. Zero cross-correlation of the STSs iii. Low detection probability for 11a systems

d. The short training symbols are designed in frequency domain. e. Time domain waveform of the ith STS is obtained by

∑=

=63

0

642

)(641)(

k

nkj

ii ekSnsπ

f. Long Training Symbols i. Purposes of LTS

1. fine frequency offset estimation, fine timing, MIMO timing synchronization, Channel estimation

ii. The proposed LTS 1. 2 x 2 system: the LTS occupies 2 OFDM symbol periods 2. 3 x 3 system: the LTS occupies 4 OFDM symbol periods 3. 4 x 4 system: the LTS occupies 4 OFDM symbol periods

iii. The proposed LTSs are constructed with a basis sequence L. iv. We choose L the same as the long training sequence described in 11a v. The properties of the proposed LTSs are determined by L.

vi. With the proposed LTSs, the receiver can effectively and efficiently estimate the frequency domain responses of MIMO channel.

g. Conclusion i. We propose STSs with the properties of

1. Period of 32 samples 2. Zero cross-correlation of the STSs 3. Low detection probability for 11a systems

ii. With the proposed LTSs, the receiver can effectively and efficiently estimate the frequency domain responses of MIMO channel.

h. Q&A


Sept 2004 doc.: IEEE802.11-04/0983-01

i. None 10. Chair asked the group to modify the agenda to let Nakase san present his proposal early since the last presentation finished 40

min early. Group offered no objection 11. #31, Hiroyuki Nakase, Tohoku Univ.; 11-04-1032r3; Enhanced MAC Proposal for High Throughput

a. Outline i. Background

ii. Frame aggregation for high throughput single link using UDP – Simulation – iii. New MAC procedure iv. Polling with MAC frame aggregation of different IP link v. Dual PHY method

vi. Development of WLAN terminal b. Frame format for aggregation

i. Aggregation of MAC frame to send same destination STA. ii. Aggregation Header is defined in addition to MAC header.

iii. Subheader is attached to each frame c. Proposal for Enhanced PCF

i. MAC PCF procedure with Static Beacon Timing 1. Individual polling 2. MAC frame aggregation for multicast polling

ii. Concept 1. Improvement of system throughput 2. All traffics of STAs are controlled by AP in BSS 3. Suppression of overhead in low data rate traffic

iii. Enhanced PCF with static beacon timing 1. AP sends broadcast information for EPCF using Beacon packet 2. Beacon interval is fixed. (Ex. 10 msec) : Easy control for power saving 3. Transmission available by only AP in guard duration 4. Duration of EPCF and EDCF are alternated 5. Length of frame for each STA is defined by AP due to request 6. All STAs are controlled by AP even if STA adhoc communication

iv. Definition of EPCF 1. Polling request and accept 2. STA sends a request frame to AP during DCF when STA has an application with fixed data rate

streaming. 3. EX: HDTV, SDTV, VoIP, etc. 4. AP assigns the polling sequence number for the STA, and send a acceptance frame to the SAT.


Sept 2004 doc.: IEEE802.11-04/0983-01

v. Polling List Table 1. AP has a polling list table for management of PDF duration. 2. Data

vi. Problem 1. Wasted duration of PHY preamble and SIGNAL field of 16+4msec in low data rate frame.

a. Ex: 0.096Mbps (VoIP) i. Preamble and SIGNAL: 20msec

ii. MAC Header + Data + FCS @ 216Mbps: 8msec 1. (36Byte + 120Byte + 4Byte)/(216Mbps)

2. Solution :Reduce the number of PHY preamble

a. Aggregation of downstream for low data rate!! i. MAC frame Aggregation for low data stream of < 1Mbps

vii. Scenario Config 1. HDTV, gaming ~30Mbps 2. FTP ~2Mbps 3. Video streaming ~2Mbps 4. Video Phone ~500kbps 5. VoIP, MP3 ~100kbps

viii. Is 100 Mbps needed for VoIP? 1. Comparison between 11n and 11a

a. VoIP stream every 10msec : 960 bit i. DIFS(32usec)+Backoff(0usec)+preamble(20usec)+MAC(240bit)+Body +FCS(32bit)

+SIFS(16usec)+preamble+MAC+Body+FCS b. VoIP on 11n (216Mbps): 88usec + 8 usec =96 usec

i. 32+20+(240+960+32)/216+16+20+(240+960+32)/216 c. VoIP on 11a (54Mbps): 88usec + 24 usec = 112 usec

i. 32+20+(240+960+32)/216+16+20+(240+960+32)/216 2. If there are some MIMO training symbols, duration for VoIP is the same between 11n and 11a. 3. It is not efficient usage of 100Mbps.

ix. Proposal: Dual PHY Communications 1. All packet of STA-AP connection are small size. 2. IFS and preamble for ACK and low rate packet in STA-AP connection are wasted duration for 11n.

a. AP-STA and STA-AP connection are used the same frequency band : Time Division Duplex (TDD)

x. Suggested Solution


Sept 2004 doc.: IEEE802.11-04/0983-01

1. In order to increase throughput, different band is used for STA-to-AP connection : Employment of Freqency Division Duplex (FDD) using 11a/b/g

a. Ack, low rate packet for STA-AP connection 2. Dual PHY Protocol Stack

a. Definition of MAC sub-layer for using different PHY b. For STA-AP, legacy devices is used. c. For AP-STA connection, 11n is used.

3. Employment of legacy devices for STA-AP connection 4. AP-to-STA streaming without IFS to achieve higher throughput. 5. Simulation results are shown later

xi. WLAN Terminal Implementation 1. We have a national project to implement 5GHz high throughput WLAN terminal.

a. Project was started in 2002. b. Budget of Ministry of Education, Culture, Sports, Science and Technology, JAPAN c. Development with Mitsubishi Electric Co. and NetCleus Systems Co.

2. Band expansion based on 11a PHY format. a. 6 channels expansion available b. FPGAs of Xillinx and Altera were used for implementation.

d. Conclusion i. MAC proposal

1. MAC frame aggregation of multi-destination in PCF duration. 2. FDD mode using 11n and legacy devices 3. Every proposal has improvement of MAC throughput superior to conventional MAC procedure.

12. Chair reintroduced the topic - consideration of logistics for Nov. meeting a. Comment made that time NOT be made for “comparison” presentations at the Nov. meeting

13. Chair recessed at 5:04PM for dinner 14. Chair reconvened at 7:30 PM

a. Kim Wu, Inprocomm; 11-04-878r1; Inprocomm PHY Proposal for IEEE802.11n: MASSDIC-OFDM i. Content

1. Assumptions in the proposal 2. Main features of the proposal 3. Proposed Multiple-Antenna Signal Space Diversity Coded OFDM (MASSDIC-OFDM) PHY System

architecture a. Modulation, precoding, FEC, proposed receiver structure

4. PLCP Frame format 5. Preamble


Sept 2004 doc.: IEEE802.11-04/0983-01

6. FEC Coding 7. Compatibility to 802.11a 8. Simulation Results 9. Summary

ii. Assumptions 1. The proposal is targeted at the physical layer 2. A MAC efficiency of 60% is assumed 3. To reach the 100 Mbps MAC Goodput, a minimum of 167 Mbps is required. 4. The proposal shall have another portion of MAC enhancement proposal. It can be amended later.

iii. Main Features 1. This proposal inherits the good features of 802.11a OFDM standard

a. Spectrally efficient, robust against narrowband interference b. Low complexity in channel equalization c. No ISI and inter-carrier interference (ICI) if channel max delay is less than the guard interval d. Good performance by bit-interleaved convolutional coded modulation

2. This proposal uses MIMO (2x2 Mandatory) architecture to double the capacity. 4x4 and 3x3 configurations are optional

3. This proposal uses variable guard intervals to optimize the data rate against different channel delay spread

4. The operation bandwidth is 20 MHz. 5. This proposal uses 256-QAM to boost bandwidth efficiency 6. The number of subcarriers in an OFDM symbol is increased from 64 to 128 to gain guard interval

efficiency. 7. This proposal explores the signal and space diversity without sacrificing BW via linear constellation

precoding technique (LCP) (optional) a. With low rate (e.g. 3/4) FEC, OFDM is shown to be inferior to single-carrier transmission due to

loss of multipath diversity b. This problem is resolved by artificially making ICI among independent subcarriers c. The LCP is a kind of signal-space diversity coding

8. Only PHY data rates more than 53 Mbps are newly defined 9. For HT devices transmitting legacy data rates, space-time block coding (STBC) schemes are used to

enhance system performance. 10. No more overhead is needed for the PHY header relative to legacy frame format 11. New preamble structures are designed to minimize the overhead without sacrificing performance.

a. Only one OFDM symbol time interval is used for channel estimation b. Long training symbols transmit higher power than other fields.


Sept 2004 doc.: IEEE802.11-04/0983-01

12. The maximum data length is extended from 4096 bytes to 65536 bytes. 13. This proposal uses modern powerful error control code: extended irregular repeat-accumulated (eIRA)

low density parity check (LDPC) code to improve performance a. Coding rates of 1/2, 2/3, 3/4 are separately designed with codeword length 2667 to optimize

performance. b. A new scheme to shorten codewords with hybrid code rate combination is proposed.

b. Compatibility with 802.11a i. The proposed 802.11n is compatible to 802.11a by defining the same PHY and MAC as that of 802.11a in low

data rate mode (6Mbps~54Mbps mode). ii. A 802.11n device can distinguish between 802.11a and 802.11n packets by detecting different format of packet

preambles. iii. A Legacy device can recognize the packet from 802.11n devices in LN mode. iv. Upon detection of 802.11a packets, the 802.11n device turns to operate in the 802.11a mode

c. Summary i. The proposed 802.11n is compatible to 802.11a by defining the same PHY and MAC as that of 802.11a in low

data rate mode (6Mbps~54Mbps mode). ii. A 802.11n device can distinguish between 802.11a and 802.11n packets by detecting different format of packet

preambles. iii. A Legacy device can recognize the packet from 802.11n devices in LN mode. iv. Upon detection of 802.11a packets, the 802.11n device turns to operate in the 802.11a mode

d. Q&A i. How is Frequency Offset Estimation done? A – detail I will discuss later

ii. Does the group span more than one antenna? A- yes iii. Complexity slide- is it gate count or operation complexity? A – number of additions

15. That completes the 32 presentations!!!!!!!!!!! 16. The chair returned to a discussion of the logistics for November

a. Doc. 11-04-1030r2 i. Good news

ii. 32 presentations completed iii. Because the presentations did not fill every available meeting minute there was adequate time to caucus and, at

least tentatively, explore possible mergers which would result in new completes or revised completes.

iv. Bad News v. Complete presentations did not have adequate time to present or answer audience questions.

vi. Not enough time to conduct panel discussion or additional selection steps. vii. Not known how many completes will exist in November


Sept 2004 doc.: IEEE802.11-04/0983-01

b. November Agenda Challenge i. Panel Discussion

ii. Possible inclusion of one or more additional complete proposal iii. Extended presentation and Q&A time for completes iv. Additional technical presentations anticipated v. Need to refresh audience memory

vi. .11n will only have 18 hours at the Nov. meeting c. Recall from 11-03-665r9 – the Selection Procedure Sequence Summary

i. Call for proposals ii. Classify as partial or complete

iii. Presentations iv. Panel discussion v. Allow mergers and additional presentation

vi. Do not conduct votes on partials vii. Merger process

viii. 5 minute summary and then low hurdle vote ix. Allow mergers and revisions x. 60 minute presentations for remaining proposals

xi. Skip if only one proposal xii. Down Select vote

d. In step 7, note the ‘10 day on the server’ rule for mergers between meetings e. Reviewed the voting process

i. “Low hurdle” vote ii. “Down Select” vote

f. Chair proposed a Plan A straw man for discussion and straw poll for voting members only i. Re-present the complete presentations at 2 hours each = 10 hours

ii. Panel Discussion at 2 hours = 12 cumulative iii. 5 Minute summary discussion at 5 min. each => .5 hours = 12.5 hours iv. Low Hurdle Vote at 5 min. = 13 hours v. Time out of session to revise proposals

vi. Revise Presentations at 1 hour each => 4 hours = 17 hours vii. Down Select Vote at .5 hours = 17.5 hours

viii. Plan for January at .5 hours = 18 hours g. Chair proposed a Plan B straw man

i. Difference was to replace down select vote with time to present partial proposals and have a partial proposal panel session.


Sept 2004 doc.: IEEE802.11-04/0983-01

h. Discussion of proposed straw poll i. Suggest presentations on Monday and Tuesday with vote on Thursday

ii. Hold ad hoc meetings between now and Nov; chair noted this alternative was not well received in the past iii. Plan A – one down selection vote iv. Plan B – sacrifice down selection vote for partial proposal discussion v. Plan A math was incorrect

vi. Can only get 4 hours on Monday in Nov. meeting vii. 10 day merge rule means Nov 5

viii. Put technical presentation early in week (2) ix. Switch timing between partial and complete presentations in Plan B x. Don’t hurry with down selection

xi. Allocate Q&A time in the 2 hours to about ½ hour xii. If a merger occurs in the middle of a session the group decides the timing

xiii. What about officer elections? xiv. Is 2 minutes enough for partials? xv. Must consider meeting intro and close in the Nov. agenda time slots

xvi. Put one page for each of the partials in one document i. Straw Poll – choose either Plan A or Plan B

i. Results – A – 26 B – 50 j. Straw Poll – How to handle partial proposal presentations: Presentation collection process and jump right into Q&A

versus 2 min. verbal presentation including Q&A k. Option 2 (verbal) – 10 Option 1 (one page presentations) – 52 l. One page Partials submitted 10 days before hand just like mergers was agreed to without discussion m. Straw Poll: Submit questions in writing 5 days before the Nov. meeting to act as a seed

i. Option 1 written - 19 Option 2 verbal only – 10 n. Adrian asked for a straw poll vote on electing a vice chair at the Nov meeting o. Option 1 – yes = Option 2 – no = p. Vote was not taken due to “orders of the day” q. Chair adjourned the session at Thursday 9:36 PM


September 2004 doc.: IEEE 802.11-04/1158

Minutes of 802.11 Study Group WAVE, September 2004 Page 1 W.K.Fisher,ARINC


Minutes of 802.11 Study Group WAVE Wireless Access in Vehicular Environments

Berlin, Germany


Author: W. K. Fisher ARINC, Inc Phone: 410-266-4958 e-mail: [email protected]

1. Tuesday Afternoon Session, September 14, 2004

1.1. WAVE SG MEETING CALLED TO ORDER

1.1.1. Lee Armstrong, WAVE SG Chairman, called the meeting to order.

1.1.2. The meeting was convened at 4:10 pm.

1.2. REVIEW IEEE/802 & 802.11 POLICIES and RULES

1.2.1. Lee presented the policies and rules that govern the meeting according to the 802.11 WG.

1.3. REVIEW OBJECTIVES FOR THIS SESSION

1.3.1. Lee reviewed the objectives of the session 1.3.1.1. To make attendees aware of the status of the WAVE Study Group 1.3.1.2. To provide a draft of the 802.11p being prepared 1.3.1.3. To review the draft and discuss significant areas of interest and recent

inputs.



1.4. REVIEW AND APPROVAL OF AGENDA

1.4.1. The agenda was presented and approved

1.5. REVIEW AND APPROVE MINUTES FROM PORTLAND MEETING

1.5.1. The minutes from the Portland were presented and approved without change.

1.6. OVERALL WAVE PROGRAM STATUS REVIEW, FCC ACTIONS

1.6.1. Lee discussed the present status of the WAVE Study Group 1.6.1.1. The WAVE Study Group will remain as a study group for this meeting.

The group will become a Task Group at the beginning of the November IEEE 802.11 WG meeting in San Antonio, TX.

1.6.1.2. A draft of the WAVE amendment to IEEE 802.11 is available at the meeting to interested attendees.

1.6.2. The US Federal Communications Commission has published in the Federal Register the rules concerning the WAVE/DSRC implementation in the US 1.6.2.1. The FCC released the Report and Order adopting the final licensing and

service rules for DSRC service in the 5.9 GHz band. The rules were published in the Federal Register in August. Petitions regarding the adoption were due September 2, 2004. Final responses are due in the beginning of October 2004.

1.6.2.2. The FCC Report and Order forms a part of the rules governing the implementation of DSRC devices operating WAVE applications in the US.



1.7. RESULTS OF EXCOM BALLOT

1.7.1. The ExCom approved the WAVE PAR after having to redo it using the new on-line PAR template. This cause some troubles, but the results were ultimately accepted. The PAR is now before the NesCom, with some additional questions being asked with regards to Intellectual Property rights transfer between ASTM and IEEE and which version of 802.11 would be applicable. These questions have been answered, apparently to the satisfaction of the NesCom

1.8. REVIEW OF PROCESSES/TIMELINE LEADING TO STANDARD

1.8.1. The current document being presented this week is expected to be modified and made ready by the November meeting to be presented to the WAVE TG as the draft amendment. It is expected that there would be at least two rounds of comments with resolutions before sending it to the WG for voting. This would place the WAVE ballot sometime around April of 2005.

1.9. REVIEW OF Draft WAVE Standard compared to ASTM document

1.9.1. The WAVE standard is being created from the ASTM E 2213-03 standard and the efforts of the earlier DSRC committee

1.9.2. The ASTM E 2213-03 document expanded on the IEEE Std 802.11a to define the requirements necessary to implement applications in a mobile environment

1.9.3. Many of the parameters required for WAVE operations were determined by extensive analyses and actual high-speed testing

1.10. Recess

1.10.1. Lee asked if there were any objection to recess. There were none so the meeting was in recess for dinner.

1.10.2. Meeting closed at 6:00 pm.

2. Tuesday Evening Session, September 14, 2004

2.1. Opening

2.1.1. Call to order 2.1.1.1. Lee called the meeting to order. 2.1.1.2. The meeting convened at 7:30 pm. (~8 people attending).



2.2. P802.11p Draft Review

2.2.1. Review of P802.11p Draft 2.2.1.1. The draft document and other related documents were made available to the

attendees 2.2.1.2. Recent changes and updates and areas that needed resolution and agreement

were identified and presented 2.2.1.3. There were significant discussions on the relationship of the P802.11p draft to

the earlier ASTM E 2213-03 document, the FCC Rules, and the family of P1609 documents which further describe the use of WAVE in mobile environments. These extended discussions were helpful to newcomers to better understand the additional requirements being added to the present IEEE Std 802.11.

2.2.1.4. Some requirements defined in the ASTM document did not easily fit into the format and structure of the 802.11 documents. The led to a review of the ASTM document and how some information is also referenced in the P1609 documents. From this there was an attempt to fit these requirements into the P802.11p draft.

2.2.1.5. At the end of the document discussions Srinivas Kandala, editor of the P802.11e, recommended that we consider changing our document and create a separate Clause for the WAVE PHY specifications for WAVE applications. This would follow the structure in place for DSSS PHY, FHSS PHY, IR PHY, and the OFDM PHY specifications. This will allow a clause that specifically describes the WAVE PHY and may also streamline the comment and review process for the WAVE amendment.

2.3. Closing

2.3.1. Recess 2.3.1.1. The meeting was recessed and closed at 9:15 PM.

3. Wednesday Morning Session, September 15, 2004

3.1. Opening

3.1.1. Call to order 3.1.1.1. Lee called the meeting to order. 3.1.1.2. The meeting convened at 8:00 AM. (~8 people attending).

3.2. P802.11p Draft Review, Continued

3.2.1. Review of P802.11p Draft 3.2.1.1. An updated draft document and other related documents were made available to

the attendees. 3.2.1.2. A number of changes/additions were made to the document including:

3.2.1.2.1. “5.1.2 Differences to support vehicular environments” This clause gives a brief description of WAVE and wireless communications in high-speed mobile conditions.

3.2.1.2.2. “5.1.2.3 WAVE Applications” This clause describes the communications capabilities required for robust communications required for emergency and public safety communications in the mobile environment.

3.2.1.2.3. “5.1.2.6 Control Channel and Service Channels” and “5.1.2.7 WAVE Channel Implementation” These clauses have been updated and



discusses the concept of a fixed control channel where most communications originate and switching to a service channel to conduct extended transactions.

3.2.1.2.4. “5.9 Implementation of WAVE Mode” This clause describes communications between RSUs and OBUs, initialization for WAVE, the 5.9GHz frequency band, and figures of communication zones envisioned for WAVE applications.

3.2.1.2.5. “Limits of Control Channel usage for private applications” This section describes some requirements essential to ensure that no channel is overloaded for an extended period of time. Mechanisms must be in place to ensure that emergency public safety communications can get through.

3.2.1.2.6.

3.3. Closing

3.3.1. Recess 3.3.1.1. The meeting was recessed and closed at 10:00 AM in time for the Mid-session

plenary

4. Thursday Morning Sessions, September 16, 2004

4.1. Opening

4.1.1. Call to order 4.1.1.1. Lee called the meeting to order. 4.1.1.2. The meeting convened at 8:15 AM. (~6 people attending).

4.2. P802.11p Draft Review, continued

4.2.1. Review of P802.11p Draft 4.2.1.1. The draft document and other related documents were made available to any

new attendees. 4.2.1.2. The discussions of the changes to the draft continued.

4.2.2. Updated P802.11p Draft 4.2.2.1. The changes to the draft document will be incorporated and will be distributed at

the next session. 4.2.2.2. The changes will again be presented and discussed. The intent is to finalize, to

the greatest extent possible, a draft document that is then submitted and comes under the formal comment and review process.

4.3. Closing

4.3.1. Adjourn 4.3.1.1. The meeting was adjourned at 10:00 AM. 4.3.1.2. Following the formal closing of the meeting ad-hoc work was continued in

updating the document in response to inputs received during the meeting.



TGr Meeting Minutes for September 2004 Session


Author: Michael Montemurro Chantry Networks 1200 Minnesota Ct, Mississauga, ON, CANADA Phone: 905-567-6900 e-Mail: [email protected]

Monday September 13, 2004

10:30am Chair: Clint Chaplin Secretary: Mike Montemurro • Call to order • Agenda – Document 11-04/1037r0 • Review operating rules for a Task Group. • Review IEEE 802 policies and procedures for Intellectual Property. • Any comments on the minutes in document 11-04/747r0 from the July meeting? • Approve meeting minutes from last meeting 11-04/747r0.

• No objections to approving the minutes. • Discussion on the agenda for this meeting:

• Presentations from the last session • Security adhoc sent updates to the Requirements document – we should discuss this topic

at this meeting. • No joint presentations available for TGr and TGs – should have joint sessions with TGs

only on a as needed basis. • Discussion on the scope and requirements documents – should limit the discussion to

security and measurements. • Any submissions other then those already listed? • Call for presentations: None. • We need a discussion on what should be on the document server and whether the

presentations alone are sufficient – add to the agenda. • We need to discuss the down-select process.

• Any objections to approving the agenda? None • The agenda is unanimously approved. • Discussion on the requirements for proposal submissions:

• The “devil is in the details”. A proposal can sound good as a presentation but there are other technical challenges become evident once the text is written.

Submission page 1 Michael Montemurro, Chantry Networks

mailto:[email protected]


• If we are going to expand the scope for the proposal submissions at the next meeting, everybody needs to follow that process.

• Suggestion that everybody presents a brief description on their proposal at this meeting. In that way we can create more opportunity for proposal groups to merge.

• Why can’t the groups present brief presentations on their proposals at this meeting? Not all 13 proposals are here.

• Allow the groups who are here to present so that we can present the opportunity to consolidate proposals for the next meeting.

• That’s fine, but there are many similar presentations. STRAW POLL: How many of the proposal groups are attending this week? 5 out of 13

a) Number Discussion: • None

Result: a – 5 out of a possible 13 proposals. STRAW POLL: How many people are ready to give a proposal this week?

a) Number Discussion: • None

Result: a – 4 out of a possible 13 proposals.

• We can use our Thursday sessions to listen to the proposals. • The current dates we have decided for the proposal selection process is the following:

• October 15: presentations available on the server • November 15: give presentations • January 15: give final proposals (draft text and slides)

• It will be difficult to evaluate the technical proposals because the presentations won’t have enough details.

• Not sure whether all the groups would be ready to submit text for the October deadline. • Are we going to begin the down-select process in November? No, we will not have

enough information on the proposals until January, so the down-select process would make more sense to do in January.

• We would begin the formal down-select process in the January session. • Propose that we would have draft text available for mid-December. • Concern that there won’t be enough time between mid-December and the November

meeting to consolidate proposals. • You don’t get much writing time by pushing out the date. You could push out the down-

select until March. • The assumption is that there would be in-formal down selection between the November

meeting and the January meeting. • We could submit more extensive presentations in January with preliminary draft text;

provide the draft text in February; and begin the formal down-select process in March. • The preliminary draft text would be required in December. The final/complete draft text

would be available in January. • The January session could serve to give feedback to presenters before the formal down-

select process begins.



• We might want to submit to some cryptographic review during the process. This should likely be done after the selection process.

• This should be done after we’ve down-selected to one or a few proposals. • We might want to investigate/review other components of the solution other than

security. • We need to decide how much time we will give to each proposal in the November and

January sessions.

MOTION: Move that we adopt the following schedule for proposal submissions. September 16th: Give informal preliminary presentations (optional) October 15th: Preliminary proposals will be available on the server. November 15th: Give preliminary presentations. December 15th: Preliminary draft text available on the server. January 17th: Give extensive (two hour) presentations based on preliminary draft text. February 14th: Have final draft text and presentations available on the server. March 14th: Give final proposals and start the formal down-select process By: Jesse Walker Second: Henry Ptasinski Discussion: • None. Result:

Yes – 16; No – 0; Abstain – 2. Motion Passes.

• Chair will post the schedule on the server. • Presentation from Measurement Adhoc Group by Charles Wright – Document 11-04/989r1

• You could instrument the AP’s to identify when the 802.1x controlled port is opened or closed.

• The ACK frame means that the MSDU was received without error, it does not mean that the frame has been bridged to the DS.

• The packet that is captured over the air would be an MPDU. • MSDU is a packet that has made it through the AP. • Security and QoS state needs to be successfully completed prior to successful data

transmission. • It’s unreasonable to require that the implementations show metrics before March. • We need a methodology in place so that we can evaluate proposals with quantifiable

metrics. • Looking at the number of messages is one way to do it. However that metric does not

take into account the time it takes to generate the messages. • This method of monitoring data messages is still valid – successful transmission of

invalid MSDU’s is a broken solution. • We may have to take PHY transmission rate into account in order to address its affect on

fast BSS-Transition. We may need to address this in our requirements. • The roam was induced by decreasing the signal level thereby forcing the client to roam. • These results take scanning into result. The results show the last data packet transmitted

to the first packet transmitted. • We need to take into account the probability of fast BSS-Transmission failure. • Discussion on this document will continue during the next session.



• Recess until the 1:30pm session



Monday September 13, 2004 1:30pm

• Call to order. • We need to modify the agenda to include presentations by Marian Rudolf on Tuesday

morning. • Discussion on Fast BSS-Transition a low data rates:

• Transmission at low data rates exceeds a Fast BSS-Transition budget. • We could decide that the proposals should be benchmarked at a particular data rates. • Some proposals may break at low data rates. • We should make it a requirement that the proposals state their data rate assumptions. • Don’t see the need to address large size packet transmissions. We should look at the

canonical application, which we’ve decided was VoIP. VoIP uses small packet sizes. • The effect of packet size and rate on roaming latency is twofold: The amount of time it

takes to transmit large packets; and the amount of latency introduced by message exchange sequences.

• We need to consider any delays that are due to processing and key derivation. • Do we require final proposals to list the packets and their maximum sizes that are

sent/received during the roaming process that would affect the roam times? Also delays between packets due to key derivation authorization processing, etc.

• We need to consider how different proposals handle channel utilization. • Each proposal will have its own selection criteria which is specific to its details. • We will find a common set of criteria which is common to all proposals. • The acceptance criteria may be broader than the selection criteria. • We have not made any conclusions on these issues. However we will likely gain

consensus as we evaluate the proposals. • Presentation from the Security Adhoc Group in document 11-04/1048 by Jesse Walker

• The statement of more than two parties knowing the keys is invalid. • The third party is a special case. It is trusted. It must make the assumption that the third

party will not impersonate the other two parties, or transmit the PMK to another party. • You could make an assumption that the switch is also a trusted third party. • Algorithms that want to provide the same security as 802.11i cannot share PMK’s with

other AP’s. A trusted third party cannot share PMK’s between other devices. • The context of the usage of the PMK’s can be only be used between two parties for a

particular session. • The MAC addresses are not very stable identifiers. • The authentication credentials should include the MAC address and bind them to the key. • MAC addresses can always be changed by the bad guys. If the MAC address is bound in

the authentication, the security will be maintained. • It is assumed that the authentication server will not share key with any other party other

than the pair. If that is true, there is an end-to-end security relationship between the parties, and shared with the authentication server.

• The problem is that there must be a trusted, secure relationship between the Authenticator and the Authentication Server.

• This is a problem with RADIUS that was identified in 1996. DIAMETER solves this problem. EAP is a two-party protocol and has been applied in the trusted third-party case.



• There is nothing binding the MAC address identities to the PMK, and that will be a problem for TGr.

• This is an issue for TGr, which means we will have to define how the MAC address will be transmitted as part of EAP.

• It’s very sophisticated to create a protocol that will use the keys in the correct context. Perhaps we need to agree on who can share what and define a threat model on who can access what information.

• There are AP’s with multiple MAC addresses, which would violate this rule. • We need to comprehend the problem with 802.11i in understanding how the protocol and

cryptography can be extended to address security. • This task group needs to solve the problem of mapping the keys to the MAC addresses. • Should TGr fix problems that TGi has introduced? TGr will have to address the problem

to provide a secure solution. • If we try and define this problem in TGr, we will end up with a patchwork of multiple

solutions to the problem. • One vendor has a product where the authenticator and the authentication server are co-

located. • We need to capture these requirements and decide on what TGr will be solved. • We will need to demonstrate that the solution for TGr will not reduce the security that

was introduced by 802.11i. • There is no provision for the STA to know whether the key is going to be valid. The

solution should recover from a missing key. • A PMK timer could be introduced to solve this issue. • This document should use BSSID in all cases rather than AP MAC address. • There needs to be a handshake every time between key establishment and any break in

communications. • Remembering the last key counter is not sufficient to synchronize the replay counters. A

packet can be replayed later as it was a valid packet. • Is there a way of defining an acceptable time window where synchronization is valid?

The system needs to be flexible enough to detect man in the middle attacks • There needs to be window where the liveness is considered to be valid. • This document lists the security requirements for 802.11 in general, not for TGr. These

sound like the limitations for 802.11i. • The key scoping should be defined to address secure fast roaming. • This document should be cleaned up and clearly define what are going to be addressed

for TGr. It should also clearly define what needs to be decided by the working group as a whole.

• Recess until the 8:00am session tomorrow.



Tuesday September 14, 2004 8:00am

• Call to order. • Continue with Presentation by Charles Wright on Document 11-04/989r1

• The scope document states that for the Fast BSS-Transition, the STA must come out of powersave. This would happen before the transition event.

• AP aggregation architectures should not affect power-save. • For 802.11i, you can simply look at the four-way handshake. This needs to take place

before (non-802.1x) data transmission can take place. • Any encrypted traffic after the four-way handshake will definitely be data traffic. • Once we go to 802.11r, we need to determine what the identifiable event will be that will

allow data traffic to pass. • You will have to adapt the analysis mechanism to fit the BSS-Transition proposal. • The scan measurement time is measured between the last un-ACK’d data packet and the

Authentication request. • The roaming times should be measured using packets on the wire. • The purpose of this presentation is to demonstrate how we can measure BSS-Transition

times. How we can determine whether we are successful. • This presentation measures transition time. It assumes a successful BSS-Transition. It

does not deal with failure cases. • This presentation does not deal with transitions that could fail because the AP cannot

establish a QoS stream. • Need to consider transition times under load as well. • This methodology is a good basic method of measuring transition times. Other test and

mechanisms of analysis could be used to evaluate BSS-Transition proposals. • Discussion on adding preliminary presentations of proposals. Call for Proposals:

• Jesse Walker • Jon Edney/Stephano Faccino – Flexible pre-key • Paul Newton – QoS Aspects of Fast Roaming • Pat Calhoun – VFF roaming • How much time is appropriate? We could simply limit each presentation to five minutes

and discussion to ½ hour. • Presentation by Marian Rudolf on Document 11-04/1052

• If you deploy a VLAN-based ESS, everything belongs to the same ESS, therefore the TGr solution would be applicable. Scenario 2 is a logical representation of the physical network in Scenario 1.

• The Mobile IP concept would be agnostic to the link layer. Mobile IP should not care. • Mobile IP sends out router updates so that the client knows it has moved across router

boundaries. In 802.21, people in the Mobile IP community have asked for handoff triggers.

• The Mobile IP community wants a trigger to push a message to the client when it moves between different L2 networks.

• The scope of 802.21 includes support for Mobile IP, cellular to 802 roaming, and roaming between different 802 networks.

• 802.21 is still at the requirements stage at this time.



• Groups such as 802.21 chartered with work across technologies often fail. If 802.21 want to make an exception to that rule. Then 802.21 should come to this meeting and present solutions to us. They should sell their solution to us.

• If there is a typical trigger mechanism that is needed to make Mobile IP work, so 802.21 should work.

• 802.21 needs to determine how to roam between the 802.11 and 802.3 networks on the same network.

• The purpose of this presentation is to demonstrate what 802.21 is looking to do. • 802.21 have called security out of scope. But they are still looking to use the existing L2

security mechanisms. • If there is a conflict between 802.21 and 802.11. 802.21 should come to us so that we can

resolve any potential overlap. • 802.21 is very early in the process. It will be a long time before they will be entertaining

proposals. • There is no confusion in TGr about what TGr is going to do. • If 802.21 stops trying to dig into 802.11, they won’t get confused on TGr scope versus

802.11 scope. • 802.21 is looking to solve inter-domain roaming between different 802 technologies. • There needs to be a clearly defined boundary for 802.21.

• Presentation by Carlos Zuniga on Document 11-04/718r0 • A lot of the tools to address scanning are already included in the TGk submission. • TGk has specified the tools. TGr needs to build on the work done by TGk. None of this

functionality is mandatory in TGk. • We should mandate that all implementations do discovery in the same manner. • It is good to have effective discovery mechanisms, but it isn’t really part of this discovery

work. • Roaming times will come down as implementers choose to address the discovery

problems. • Recess until the 10:30am session.



Tuesday September 14, 2004 10:30am

• Call to order. • Presentation by Marian Rudolf on Document 11-04/719r0

• TGk should give more consideration to mobility scenarios. We should bring these requirements to the attention of TGk.

• There needs to be a mechanism to push RF information from the AP to the STA to trigger a handover.

• TGr may want to mandate TGk features which are specified as optional. • This scanning mechanism should be informational. • The last two presentations have suggested that network discovery should be in scope. We

could potentially modify our PAR to include network discovery or create a new PAR. • The network discovery issue may be in the scope of WNM, however currently the scope

of WNM is quite large. • The line of BSS-Transition is fuzzy when QoS is taken into account. The interpretation of

what’s in scope will need to be addressed as we evaluate proposals. • Presentation by Haixiang He on Document 11-04/827

• There are two types of pre-authentication in the standard. 802.11 pre-authentication and 802.1x pre-authentication. This presentation addresses 802.11 pre-authentication.

• The idea of tentative association is that you can establish that state with multiple AP’s at the same times.

• We can specify any group of messages in the tentative association state. • We need to define what a “secure channel” for communications in this case.

• Presentation by Florent Bersani on Document 11-04/1062r0 • Section 8.1.4 is informative so that you cannot conclude that the PMK is explicitly

prohibited. • The clause is accurate because it is based on the concept of a logical AP. • The intent of the section is to make a point that there is a key boundary between the

Authenticator and the Supplicant. • We all agree that you can’t share the PMK. The issue is that we can’t agree on the

boundary of the security relationship. • There is a binding of the key hierarchy with the MAC addresses. The AP is identified by

its BSSID. • The PMKid’s were necessary to identify PMK sharing between neighbours. • Section 8.1.4 is important in that it describes the key relationships in 802.11i. • Section 8.1.4 is open to interpretation and it is therefore ambiguous. • The lifetime of the PTK is essentially the same as the PMK, because it’s derived from the

PMK. • There is nothing to prevent the PTK from being used by another STA – there is not tie to

the binding. The basic issue is that you are trying to use a two-party protocol for a three party problem.

• We are trying to rely on 802.11i in the TGr solution, so we need to adapt the key mechanisms in 802.11i to TGr solutions.

• We need to specify how keys are used in TGr. • We should think about whether we want to analyse proposals to address new classes of

denial of service attacks that may result.



• The proposals should address what denial of services attacks that they may introduce. • The re-associate message is a common method of denial of service attacks. It we want to

address denial of service by protecting that message. • In 802.11i, the PMK is the token proving that you are authorised. The authorization

completes after the four-way handshake. The RADIUS server can send back different attributes that could cause the AP not to authorize the station.

• We don’t need to come to agreement on what is reasonable now. It would be a desirable goal to come to agreement on the security requirement for our solution.

• Having this conversation is useful in getting everyone on the same page. We can use this as a foundation for discussing proposals as they come forward.

• Every time you change the system, you change the security requirements. • This is not a security problem. TGr is tasked with making AP to AP transition fast. The

key is that the transition must be secure. • At some point, QoS will introduce different requirements on TGr.

• Discussion on the down-select procedure for proposals: • The procedure for TGn will not work in TGr. You could potentially have multiple

solutions adopted by TGr. • We haven’t defined any metrics for evaluating proposals for TGr. • We’ve talked about codifying the Acceptance Criteria for a proposal. We haven’t seen

any proposals so far. It will be difficult to decide on the Acceptance Criteria beforehand. • It will be difficult to decide on how well our solution addresses market requirements.

Perhaps we could look at how the solution addresses voice, video, and gaming applications.

• TGr is implementation dependent, so somehow we have to measure that. • Deploying TGr in different environments will be have to be taken into account (e.g.

hotspots, SOHO, and enterprise). • Complete versus partial proposals does not fit into TGr. • Ultimately there needs to be one proposal, even if it includes multiple solutions. • Are simulations useful in evaluating different proposals for TGr? Simulations are only

valuable if they are done correctly. • TGn has a yes/no vote for each proposal. In that way, the windowing vote can be used to

pair down the contending proposals. • There may be some interesting aspects of certain proposals that can be merged into

others. The issue is how you decide on which combinations of proposals are viable. • It would be nice to settle on the down select procedure before we start hearing proposals. • We’ve done a lot of discussion but we haven’t made many motions. • The TGn voting mechanism seems reasonable for down selecting proposals. • We will have to delay the motion until either the afternoon session or Thursday.

MOTION: In Phase 1, every voting member present may vote yes/no for each proposal, and any proposal that does not receive at least 33% yes votes is eliminated. Phase 1 shall occur at the end of presentations in the November 2004 session.

By: Jesse Walker Second:

• This business will be discussed during the next available session. • Recess until the 1:30pm session.



Tuesday September 14, 2004 1:30pm

• Call to order • For the minutes of the combined TGr/TGs session, please see TGs meeting minutes which

are included in document 11-04/831r6 1MOTION: In Phase 1, every voting member present may vote yes/no for each proposal, and any proposal that does not receive at least 33% yes votes is eliminated. Phase 1 shall occur at the end of presentations in the November 2004 session.

By: Jesse Walker Second: Nancy Cam-Winget Discussion: • You may have different groups of people available at a given time on a particular

proposal. • The proposals are made available a month in advance. • POINT OF INFORMATION: We will need to audit votes for the proposals so that

they cannot be disputed. • Don’t think proposals should be eliminated at this stage. • It’s the responsibility of the chair to eliminate block voting, and this motion does not

address that problem. • We will naturally weed down to 2 or 3 proposals without this process. • We need some sort of process to move things along. If this is not the correct process,

please vote against it. • It is important to record votes on proposals to gage support. Result:

Yes – 8; No – 8; Abstain – 6. Motion Fails.

• We do need a process to proceed. • We could change the limit from 33% to 25% would we support it. • Instead of trying to tweak the motion, could the people who say they need a process

present an alternative on Thursday? • Why don’t we use straw polls instead of voting? • Anyone who has a proposal for the first phase of the selection process can submit the

process on Thursday for a vote. • Recess until the Thursday 4:00pm session.

1 The following meeting minutes shown in italics are not an officially scheduled TGr meeting.



Thursday September 16, 2004 4:00pm

• Call to order. • Discussion on changes to the agenda. • List of “Intent to Propose” submissions:

• Bernard Aboba • Bob Beach • Bob Beach • Bob O'Hara • Donald Eastlake • Fujio Watanabe • Haixiang He • Juan Carlos Zuniga • Mike Moreton • Nancy Cam-Winget • Stefano Faccino • Steve Emeott • Xiaoning He

• IEEE 802.21 has an official response to 11-04/1052 which they will give at the next meeting. • Document 11-04/1052 does not accurately reflect the feelings IEEE 802.21

• The TGr activity in the joint TGr/TGs session is not an official TGr session. The minutes from the unofficial session are recorded clearly marked in the minutes.

• Continued discussion on the down-select process – Jesse Walker – document 11-04/1121 • Jesse Walker withdraws his motion from the floor. No objections. • A proposal that misses Step 1 cannot be considered in Step 2. • Any proposals that have been voted out needs to combine with a proposal that has

continued to the next step. • The motion is worded clearly to demonstrate that this is an elimination phase. • The reason why proposals are given re-consideration after step 3 to address the

possibility that no proposals would be given the 75% vote after this step. • The intent of the sunset rule was to address the case if all proposals fail to achieve the

75% vote. • There is a probability that we have a draft with two or more proposals. It will take a 75%

vote to remove them. It will be difficult to put together a coherent draft at that time. • If TGr adopts one proposal, it will be unlikely to adopt a second one. If more than one

proposal is adopted, TGr would work through compatibility mechanisms to allow for both proposals.

• The editor would have to add potentially two incompatible proposals to the draft. One proposal would have to be selected first to provide the beginning of the draft text. The onus would be on the other proposals to suggest merges to the draft text.

• The TG editor volunteers to combine the proposals in the draft text. • The changes must be editorial only. The editor will combine the drafts and submit a

motion for the combined text. • POINT OF ORDER – this document does not have to sit on the server for four hours

before we vote. We have spent the last time word-smithing the document. • The most likely result of step 2 is to have only one proposal going into step 3.



• In other groups have always effectively had two proposals before one is selected. • There is a possibility that all proposals will be eliminated in step 2. • There would be nothing to stop TGr from modifying the process or deciding on any other

remedy if all proposals are rejected. • This proposed process starts out in the right direction. • POINT OF INFORMATION: The chair prefers that this document is placed on the server

before we vote on it. • If the group at the end of step 2 was happy with a single proposal before the end of the

January meeting. Step 3 could be done in the January meeting. • If no proposal is chosen 75% after step 3, the vote to rescind the part is puts a very

negative context on the work we are doing. • With our allotment at the November session, we will be given enough meeting time to

give each proposal one hour. • There can be a motion to rescind the PAR at any time. • After step 3, any proposal under re-consideration must be presented as an edit to the TGr

draft. MOTION: Adopt the process as defined in Document 11-04/1121r2 as the down-select process for proposals made to TGr.

By: Jesse Walker Second: Bob O’Hara Discussion: • There are no distinctions between full and partial proposals.

Result: Yes – 17; No – 0; Abstain – 9. Motion passes. • Discussion on presentation by Dan Harkins on document 11-04/1072r1:

• When Bill Arbagh collected his results, he did not have any traffic load on the AP’s. • In Bill Arbagh’s work, his machine was a P4 machine. There are handheld devices that

don’t have that processing power, and it would be useful to test it as well. • Pre-authentication would be a reasonable method for pre-loading the keys in the AP. • There are ways to solve the pre-authentication problems outside of the IEEE.

• The order of the presentations will be: 11-04/1127, 11-04/1089, 11-04/1117, and 11-04/1114. • Discussion by Pat Calhoun on document 11-04/1127:

• It’s unnecessary for the controller to derive PMK’s when the AAA server could accomplish the same thing.

• A RADIUS server does not currently perform this function. • The DPMK derivation could be done on a stand-alone AP. • The GTK should be in the re-association response. • The association can take place with either an Association or a Re-Association. • The MIC is keyed with the PTK during the Association response. • The PTK can be computed by both the AP and the STA. • The DPMK is a required component of this proposal. • The key hierarchy and the handshake are independent. However both are required to get

the performance. • The context transfer has not been completely specified. • The DPMK limits the scope of compromise to a single AP.

• Recess until the 7:30pm session.



Thursday September 16, 2004 7:30pm

• Call to order • Discussion by Paul Newton on document 11-04/1089r0:

• The token has a new status field to address whether the ADDTS will be services once the STA associates.

• The AP could negotiate the validity period in its response suggested by the STA. • This presentation is a pre-setup of TSPEC’s prior to roaming. • A new Ethernet type could be used to transmit packets through the DS to the new AP. • The timestamp attached to the TSPEC request could present a mechanism for a DoS

attack by consuming resources on the AP. • The secondary timestamp seems to be redundant. The Activity Interval parameter in the

ADDTS could be used as an alternative. • A number of products do not support pre-authentication for 802.11i. This would only

work if the AP’s were installed on the same subnet. • Discussion by Jesse Walker on document 11-04/1117r0:

• This proposal is independent of how the PMK is delivered to the AP. There are a number of mechanisms that are being considered for PMK distribution.

• Different mechanisms for modification to the four-way handshake are being considered. They depend on the mechanism for the PMK distribution.

• The aggregation of a number of requests in the re-association procedure will have to be explained and addressed in the full proposal.

• The four-way handshake messages are triggered on the Authenticator state machine. It is possible but it is additional work.

• Discussion by Jon Edney on document 11-04/1114r0: • The SNONCE does not have to be in the 4-way handshake.

• Groups with similar proposals are welcome collaborate and merge their proposals. • The Security Adhoc group for TGr will continue to complete their action from the last

meeting. • The meeting is adjourned.


September 2004 doc.: IEEE 802.11-02/xxxr0


ESS MESH Network Task Group Meeting Minutes

Date: September 27th, 2004

Authors: Stephen G. Rayment BelAir Networks 603 March Road Ottawa, ON, K1S 1W1, Canada Phone: +1 (613) 254-7070 e-mail: [email protected]

and

Donald E. Eastlake III Motorola Laboratories

111 Locke Drive Marlboro, MA, 01752, USA Phone: +1 (508) 786-7554

e-mail: [email protected]

Abstract

Minutes of the meeting of the IEEE 802.11 ESS MESH Networking Task Group held in Berlin, Germany from September 13th to 16th, 2004 under the TG Chairmanship of Donald Eastlake III of Motorola Laboratories. Minutes were taken by Stephen Rayment (with notes for Session I from Lakshman Krishnamurthy) and edited by Donald Eastlake III. An agenda for the meeting is in document 11-04/0831r8.

Contents

Minutes ........................................................................................................................................................................................2 Detailed Record ...........................................................................................................................................................................6

TGs September 2004 Minutes page 1 Stephen Rayment, BelAir Networks


Minutes Session I, Monday, September 13th, 10:30am – 12:30pm, ECC Room 4 Meeting was called to order at 10:32 by Donald Eastlake 3rd, Chair, with Lakshman Krishnamurthy acting as secretary. The IEEE and 802.11 policies concerning Patents and Inappropriate topics were explained by the chair and there were no questions. The Minutes of July 2004 Meeting (11-04/853r0) were approved by unanimous consent. The Minutes of the ad hoc Teleconference held 25 August 2004 (11-04/975r0) were approved by unanimous consent. Presentation #1: “Draft Terms and Definitions for 802.11s”, Tricci So (Nortel), 11-04/0969r2 Presentation #2: “Usage Cases”, Steve Conner (Intel), 11-04/0662r10 Presentation #3: “Proposed 802.11 TGs Scope”, Tricci So (Nortel), 11-04/0970r3 Session II, Monday, September 13th, 1:30pm – 3:30pm, ECC Room 4 Stephen Rayment took over as acting Secretary. Further discussion of the first three presentations:

Presentation #1: “Draft Terms and Definitions for 802.11s”, Tricci So (Nortel), 11-04/0969r2 Presentation #2: “Usage Cases”, Steve Conner (Intel), 11-04/0662r10 Presentation #3: “Proposed 802.11 TGs Scope”, Tricci So (Nortel), 11-04/0970r3

Presentation #4: “802.11s Military Usage Case”, J. Hauser (NRL), D. J. Shyy (MITRE), Max Green (MCTSSA), 11-04/1006r0 Presentation #5: “Routing and Forwarding Separation”, Tricci So (Nortel), 11-04/098r0 Session III, Tuesday, September 14th, 1:30pm – 3:30pm, ECC Room 4 Joint TGs / TGr Meeting. Each TG chair presented a brief overview Straw poll held on automatically holding standing joint TGs/TGr meetings – result 0 in favour, many against. TGs (only) session: Presentation #6: “MANET Routing Protocols”, Avinash Joshi, Vann Hasty, MeshNetworks Inc., Michael Bahr, Siemens Corporate Technology, 11-04/1047r0 Session IV, Tuesday, September 14th, 4:00pm – 6:00pm, ECC Room 4



Presentation #7: “Issues for Mesh Media Access Coordination Component in 11s”, Lily Yang (Intel), 11-04/1077r01. Presentation #8: “Military Usage Example”, Jack Burbank (John Hopkins/APL), 11-04/1016r0. Presentation #9: “Clock Synchronization Issue in Ieee 802.11 TGs”, Yeonkwon Jeong (ICU), 11-04/1027r0. Presentation #10: “Interface Awareness”, Guido Hiertz (Aachen University),11-04/1075r0. Presentation #11: “A new MAC scheme for better support of Mesh networks with QoS”, Rui Zhao (Aachen University),11- 04/0991r0. Session V, Tuesday, September 14th, 7:30pm – 9:00pm, ECC Room 4 The chair led a discussion on process - see document 11-04/1058r0. Presentation #12: “TGs Reference Architecture Considerations”, Tricci So (Nortel), 11-04/0981r0. Motion to adopt document “Draft Terms and Definitions for 802.11s”, 11-04/0969r2 as a working document of TGs subject to change by a majority vote. Moved Tricci So, seconded Guido Hertz No objections, adopted by unanimous consent Motion to adopt document “Usage Models”, 11-04/0662r10 as a working document of TGs subject to change by a majority vote. Moved Steve Conner, seconded Kue Wong No objections, adopted by unanimous consent Motion to adopt document “Proposed 802.11 TGs Scope”, 11-04/0970r3 as a working document of TGs, subject to change by majority vote of the TGs members. Vote held and motion passed 12-1-2 Session VI, Thursday, September 16th, 8:00am – 10:00am, Paris Salon The Permanent Task Group Secretary position was filled by acclamation by Stephen Rayment (BelAir Networks). Discussion on presentation #11 from yesterday “A new MAC scheme for better support of Mesh networks with QoS”, Rui Zhao (Aachen University), 04/0991r1 Presentation #13: “MAC Modification Possible Technical Targets for 11s Mesh Network”, Akira Yamada, Yoichi Matsumoto, and Hidenori Aoki (NTT DoCoMo), 11-04/1067r2 Presentation #14: “Routing Requirements”, Jim Harford, 11-04/1028r0 Presentation #15: “802.11s Security Concepts”, Jasmeet Chhabra (Intel), 11-04/1115r2 Straw polls…

When to do Call for Proposals: (votes for-against) After September 2-25 After November 21-12



After January 28-4 Window for submitting proposals:

2 months 0 4 months 25 6 months 10

Session VII, Thursday, September 16th 10:30am – 12:30noon, Paris Salon Tricci So presented document “TGs Selection Procedure Recommendation”, 11-04/1107r1 Steve Connor presented updated document “Possible Options for 802.11 TGs Call for Proposals”, 11-04/1083r1. Straw poll on the options in that document:

Option 1 4 Option 2 11 Option 2.5 29 Option 3 0

The following motion was moved by Peter Eccelsine, and seconded by Clint Chaplin:

Moved, to direct the TGs chair to announce at the closing September 2004 802.11 plenary session and post to the 802.11 mailing list that TGs plans to issue a call for proposals shortly after the _______ 802.11 meeting with proposals to be submitted before and presented to TGs at the second 802.11 meeting thereafter.

The Chair adopted fill in the blank process. “November 2004”, “January2005”, and “March 2005” were nominated to fill the blank. The vote on “November 2004” was 7 in favour, 11 opposed so it failed. The vote on “January 2005” was 17 in favour, 2 opposed so it was selected to fill the blank. By unanimous consent, “or before” was inserted just after the last “at” in the motion. It was moved to amend the motion by striking “second” and inserted “third” in place thereof. Vote 10 – 5 so this amendment was adopted. The amended motion then read

Moved, to direct the TGs chair to announce at the closing September 2004 802.11 plenary session and post to the 802.11 mailing list that TGs plans to issue a call for proposals shortly after the January 2005 802.11 meeting with proposals to be submitted before and presented to TGs at or before the third 802.11 meeting thereafter.

It was adopted by a vote of 10 – 0 – 7 The following motion was moved by Steve Connor, and seconded by Vann Hasty: Moved, that TGs have bi-weekly teleconferences at 13:00 Pacific Standard Time Wednesday starting 29 September through 27 October. Notice will be given, including UTC time, at least 10 days in advance. There was no debate on the motion. It passed 17 – 0 – 2. Presentation #16: “Routing in Mesh Networks”, Myung. J Lee, Chunhui Zhu (CCNY), 11-04/1042 The chair summarized the planned TGs Report to the 802.11 Plenary, document 11-04/1128r1.



Without objection, TGs adjourned for the week at 12:32pm\.



Detailed Record Session I, Monday, September 13th, 10:30am – 12:30pm, ECC Room 4 Meeting was called to order at 10:32 by Donald Eastlake 3rd, Chair, with Lakshman Krishnamurthy acting as secretary. The IEEE and 802.11 policies concerning Patents and Inappropriate topics were explained by the chair and there were no questions. The Minutes of July 2004 Meeting (11-04/853r0) were approved by unanimous consent. The Minutes of the ad hoc Teleconference held 25 August 2004 (11-04/975r0) were approved by unanimous consent. o Chairman stated that today’s meetings will focus on three submissions. Preliminary Discussion of the ad hoc

submissions (~30 minutes each) followed by further discussion later. o “Draft Terms and Definitions for 802.11s”, Tricci So (Nortel), 11-04/0969 o “Usage Cases”, Steve Conner (Intel), 11-04/0662r10 o “Proposed 802.11 TGs Scope”, Tricci So (Nortel), 11-04/0970

o Chairman described the scope of the TGr joint meeting. Stated that there is no specific agenda yet and agenda will have to determined at the start of that joint meeting

o Chairman went thru the agenda and list of presentations for the series of meeting on Tuesday and Monday, stated that he hopes that documents will be sumitted before their presentation

o Chairman calls for any comments on the agenda o A question was asked and clarified that all documents that have a motion should be posted 4 hours before

their consideration o Chairman clarified that the presentation has to be on the server o Agenda was approved by unanimous consent Presentation #1: “Draft Terms and Definitions for 802.11s”, Tricci So (Nortel), 11-04/0969r2

• Tricci stated that she would like to propose a motion in one of the follow on meetings to make this an official document.

• There was question on integration services, as specified by the integration services in 802.11 Presentation #2: Usage Cases, Steve Conner (Intel), 11-04/0662r10

• Steve covered various use cases for 802.11s based on results of a strawpoll o Home o Office o Community o Public safety

• Stated that the hope is to have this document adopted as official working document. Will bring a motion tomorrow.

• There were questions of mobility support and scope • TGs is not going to go back and change the PHYs • Is the group related to 802.21, taking into account handoffs

o The chairman We are having a meeting with TGr to discuss handoff issues

Presentation #3: “Proposed 802.11 TGs Scope”, Tricci So (Nortel), 11-04/0970r3 • Clarify the TGs scope



• Work with TGs members to agree with scope and interpretation of the PAR • Would like to define network reference architecture • Define the selection criteria • Should like at 802.11s portability to 802.11n • Next step is to drive completion of this documents • Will propose motion to make this a working group document • Outside the PAR to consider 802.16

Session II, Monday, September 13th, 1:30pm – 3:30pm, ECC Room 4 Session convened at 1:35PM Stephen Rayment was introduced as a volunteer for Permanent Secretary. Formal approval will occur at the Thursday meeting so this can be announced at the mid-week 802.11 plenary to give any other volunteers the chance to come forward. Chair opened the floor for further comments on the morning’s documents considered one at a time. Presentation #1: “Draft Terms and Definitions for 802.11s”, Tricci So (Nortel), 11-04/0969r2 It was underlined this is a living document… Question on who edits adhoc documents – could be either TG editor or original author. Author of this doc volunteered. Accepted by TG editor. Question on why have these separate adhoc documents at all? It was noted that Figure 1 in version 11-04/969r1 uses pbrush which is not compliant with IEEE document standards. Several people volunteered to help the author fix this problem and version r2 was submitted later during the meeting with it fixed. Presentation #2: “Usage Cases”, Steve Conner (Intel), 11-04/0662r10 Title of document and other headings contains “Field Codes”. Table 4 – what is value of showing cumulative performance parameters when you will likely have multiple hops involved? Presentation #3: “Proposed 802.11 TGs Scope”, Tricci So (Nortel), 11-04/0970r3 Announced that interested people should meet 9:00AM Tuesday to further refining this document. In Table 2, clarification was looked for on administrative domain vs managed / unmanaged network? Comment on mobility – already covered by the PAR? Chair invited new presentations… Presentation #4: “802.11s Military Usage Case”, J. Hauser (NRL), D. J. Shyy (MITRE), Max Green (MCTSSA), 11-04/1006r0 Urged inclusion of military applications in usage models – similar to the First Responder case – listed key functional requirements – showed mapping of combat scenario to .11s terminology – how to interconnect multiple meshes? Showed numerous Operations Scenarios: Amphibious, Urban Opns, Convoy Ops, Military Experimental Ops. Questions… Clarification on security – 802.11i may meet requirements. Spectrum requirements? Can use transverters for military bands. Co-existence with commercial devices in same bands? Yes. Do meshes have to break and re-join (hard to do at IP layer)? Yes. Needs to support Ad Hoc operation for many scenarios – is that in scope for .11s? Clarification that Car to Car was eliminated due to high speed. Questions on error



performance. What routing scheme? Broadcast to distribute Link State and SPF. Throughput? Most people appeared to agreed that military requirements could be subsumed into public safety Presentation #5: “Routing and Forwarding Separation”, Tricci So (Nortel), 11-04/098r0 Suggested the separation of control and data plane / processing. eg. SPT may require all data to be refreshed if network goes down, forwarding has to wait for control updates. Agreed with by some, argued by others. Session recessed 3:30PM Session III Tuesday, September 14th, 1:30pm – 3:30pm, ECC room 4 Joint TGs / TGr meeting – convened at 1:35PM No presentations had been previously submitted. Each TG chair presented a brief overview of status of their group: TGr – Call for Proposals at last meeting – 13 place holder responses received - discussing security - PAR says it can’t be lessened – by Oct 15th only proposal submissions must be in place – presentations at November meeting – down select TBD TGs – Not as far along – 18 +16 presentations – many aspects – Usage models – Proprietary solutions – Straw Poll on presentation after November – several working groups – docs will likely be referred to by proposals. Straw poll held on automatically holding a joint TGs/TGr meeting at every 802.11 meeting – result 0 in favour, many against. Suggestion made that group chairs decide on adhoc basis when to hold joint meetings. The chairs decided to divide the remainder of the 2 hour session into a TGs and a TGr meeting with order deterimined by a coin toss. TGs (only) session convened at 1:50PM Presentation #6: “MANET Routing Protocols”, Avinash Joshi, Vann Hasty, MeshNetworks Inc., Michael Bahr, Siemens Corporate Technology, 11-04/1047r0 Tutorial presentation. Contrasted proactive, reactive and hybrid routing protocols. Gave MANET group update. Walked through example of reactive (OLSR) and proactive (AODV) protocol. More complex IETF problems have been moved to IRTF. Provided a summary of the common / differing elements between IETF and TGs requirements. Also highlighted current areas of research. Questions followed on performance. One commenter noted there is not much difference between many approaches. Must use Link Quality – more important than specifics of routing protocol. Clarification was requested on MANET’s L3 vs TGs’s L2 approach. Also questions on TGs security assumptions. Session IV, Tuesday, September 14th, 4:00pm – 6:00pm, ECC Room 4 Session started at 4:05PM



Chair reviewed accomplishments to date Presentation #7: “Issues for Mesh Media Access Coordination Component in 11s”, Lily Yang (Intel), 11-04/1077r01 Presentation is a summary of “Issues for Mesh Media Access Coordination Component in 11s”, Lily Yang (Intel), 11-04/0968r5. Result of work of AdHoc Group. Document provides a list of challenges any proposal might want to address. Two phases to operation Discovery/Establishment and Normal Operation. 11 issues identified: eg. Hidden Node, Exposed Terminal are all exacerbated in Mesh. Multi-hop Flow Control, need for Load Balancing and Scheduling, Distributed Admission Control and QoS Management, mixture of BSS and Forwarding Traffic, Scalability for different usages, Channelization to reduce interference, how to use Multiple Radios. Questions / comments followed. Comment that this is useful but difficult to know what to simulate. Clarified that this group is not proposing solutions (yet), and it was asked that the group prioritize. Clarify impact on upper or lower MAC. Suggested these issues be converted into evaluation criteria – discuss later! PAR does allow for MAC enhancements. Suggested that impact of beacons be evaluated. Presentation #8: “Military Usage Example”, Jack Burbank (John Hopkins/APL), 11-04/1016r0 Outlines military requirements and uses. Military desire to use commercial solutions and integrate into JTRS to enable network-centric warfare. The need for mesh is application in areas where infrastructure does not exist, instant infrastructure, without pre-planning. Examples of current military deployments – 2RAD, EPRLS, SecNet, etc. Future is Future Combat System (FCS) and Joint Tactical Radio System (JTRS). Various military mesh scenarios (including bullets!) were listed and key required characteristics – including MANET commonality - were identified. Comment was repeated that usage may be incorporated into Public Safety category? Military security requirements may not allow commonality with commercial needs. NATO previously looked for 400MHz 802.11 – is that of need – again frequency translation was envisaged. Comment on commonality between IETF OSR and wireless needs. Comment that L2 expects reliable transport underneath – MANET type routing may not be able to act on that info. Comment that usual IEEE process requires contribution of solutions as well as requirements. Presentation #9: “Clock Synchronization Issue in Ieee 802.11 TGs”, Yeonkwon Jeong (ICU), 11-04/1027r0 Outlined the needs for clock synch in current 802.11 networks and how TSF is implemented. The problems with using this approach in multi-hop configurations was explained and propoed solution presented. It was commented that TGk was looking at TSF problems – with no solutions! It was noted that this presentation assumed an iBSS mode mesh. Presentation #10: “Interface Awareness”, Guido Hiertz (Aachen University), 11-04/1075r0 Ranges based on interference, CCA (Clear Carrier Assessment) modes, RTS/DTS and data ranges were calculated. The effects on multi-hop situations of interference were shown and the case made that current CCA and RTS/CTS are inadequate. Comments again that TGk would be interested, also TGe is allowing only certain rate STAs to enter. Clarification on why mesh CCA is worse than wired case – mostly for single frequency meshes. Agreement that this presentation highlighted a major performance factor for mesh networks



Presentation #11: “A new MAC scheme for better support of Mesh networks with QoS”, Rui Zhao (Aachen University), 11-04/0991r0 The presentation gave an overview of W-CHAMB (Wireless CHannel Oriented Ad-hoc Multi-hop Broadband), which incorporates both L2 and L3 functions. It is a TDMA system that adds the concept of an Access Channel, Traffic Channel and Energy Signal Channel. It uses an access method similar to HiperLAN/1. Decentralized control is used. It was showed how this approach could give better Multi-hop support through the use of timeslots to avoid transmission / interference / sensing range problems. The QoS capabilities of W-CHAMB even under heavy loads, due to its channel oriented approach, were shown. The synchronization scheme of W-CHAMB, based on periodic beacons and clock shift compensation were described. Significant throughput advantages of WCHAMB over 802.11 were shown through simulation. Session V, Tuesday, September 14th, 7:30pm – 9:00pm, ECC Room 4 Session convened 7:45PM Chairman reviewed accomplishments so far. The chair led a discussion on process - see document 11-04/1058r0 Typical timeline based on prior standards and a possible schedule for TGs was outlined. The Ad Hoc subgroup activities and their status were outlined. The status of these groups’ submissions was also reviewed. A summary of previous straw polls on possible dates for a Call for Proposals was presented. Steve Conner presented document “Possible Options for 802.11 TGs Call for Proposals”, 11-04/1083r0 Outlined 3 possible criteria, with varying “rigour”, upon which a Call for Proposals could be based. Comments… • Need to see proposals first. What criteria are mandatory? • Significant deltas between TGs and TGn – TGn is a tougher problem than ours – size, criteria much larger,

progress to date, Option 1 will take a long time to compare proposals. • There is much more variation across requirements in TGs than in TGs, eg. in rate of change of topology, need

to refine those more, better to spend time • Map 3 options to timeline? Option 1 now, Option 2 may be achievable in November time, Option 3 shoud be

shorter than TGn • How long can Call for Proposal extend – 12 months is a long time! • Can there be intermediate proposals? Earlier presentations are OK • Can there be multiple proposals on various aspects maybe sequentially, maybe with parallel downselects. It is

expected we will in fact get that. • Quality of proposals will likely increase with time waited. • MANET did exhaustive simulation scenarios and made very slow progress. Iterative approach like Option 2

may be better. • TGe started with a long list of MAC changes. Pulled out many aspects along the way. TGs starts with a long

list of ESS changes. TGn is not the right parallel – this is tougher! • Defining criteria doesn’t necessarily ensure apple for apples. Need some requirements though. How do we

decide on down-selecting method? TGr has some ideas • How about a proposal for minimum requirements? Do on an area by area basis. • MANET is slow because there are no functional requirements or consistent modeling criteria.



Chair proceeded to discuss ways to accelerate progress and presented a possible future schedule based on Call for Proposals after November. Presentation #12: “TGs Reference Architecture Considerations”, Tricci So (Nortel), 11-04/0981r0 Proposed that 802.1D MAC Bridging be used as a starting point for TGs architecture. The interface to the bridge is the ISS (Internal Sublayer Service). Comments… • .1D is relevant mostly at the Mesh Portal, don’t want to use .1D protocols inside the mesh • TGi ignored portals. TGi has multiple logical ports per physical. May be relevant • FCS field – most people don’t use • 802.1D will probably have to get text from TGs in the future! Motion to adopt document “Draft Terms and Definitions for 802.11s”, 11-04/0969r2 as working document of TGs subject to change by a majority vote. Moved Tricci So, seconded Guido Hertz No objections, adopted by unanimous consent Chair explaint that, under Robert Rules, to change something previously adopted normally takes a 2/3 vote or prior notice; however, by adopted the “subject o change by a majority vote” proviso, a simple majority without advance notice will work. Motion to adopt document “Usage Models”, 11-04/0662r10 as working document of TGs subject to change by a majority vote. Moved Steve Conner, seconded Kue Wong No objections, adopted by unanimous consen Motion to adopt document “Proposed 802.11 TGs Scope”, 11-04/0970r3 as a working document of TGs, subject to change by majority vote of the TGs members. Some objection because Scope should be as stated in PAR. Vote held and motion passed 12- 1-2 Session adjourned at 9:21PM Session VI, Thursday, September 16th, 8:00am – 10:00am, Paris Salon Session convened at 8:04AM Chair outlined agenda for the day. The Permanent Task Group Secretary position was filled by acclamation by Stephen Rayment (BelAir Networks). Discussion on updated presentation #11 from yesterday: “A new MAC scheme for better support of Mesh networks with QoS”, Rui Zhao (Aachen University), 04/0991r1 Highlighted differences from HyperLAN. Also showed co-existance support (slide 20). Questions on synchronization – uses periodic beacons – assumes max. 300m time delays. Are people ready to “dump” RTS / CTS? Clarify centralization of synch – no – there is a mechanism for beacon prioritization / contention (see slide 7). Another presentation made in WNG - 04/1080 – was mentioned – may be too complex.



Presentation #13: “MAC Modification Possible Technical Targets for 11s Mesh Network”, Akira Yamada, Yoichi Matsumoto, and Hidenori Aoki (NTT DoCoMo), 11-04/1067r2. Identified 3 levels of MAC modifications for .11s of varying magnitude of change from current .11. (1) Showed impact of tweaking TXOP on throughput of 5 hop mesh. (2) Showed possible Mesh Control field for Hop Count. (3) Showed possible use of .11n MAC feaures – e.g. framing aggregation. Some had concern over excessive MAC changes for .11s. Others argued that significant changes will be required. Maybe compromise on tweaks to .11e MAC. Comment that flow control may be required. Presentation #14: “Routing Requirements”, Jim Harford, 11-04/1028r0 Summary of input from routing ad hoc group, email from Peter Ashwood-Smith, and IETF RFC2501. Commented that routing group needs to advance. Comments on frequency of sleeping nodes – is it a mesh node? Re-prioritize Networking Context to make them more radio aware. Is unicast in scope? Is multi-cast group registration in scope. Alternative to sleeping mesh node is changing it to a STA. We do not consider mix of STAs and APs, just APs. Sleeping is of course just an issue for battery powered units. Presentation #15: “802.11s Security Concepts”, Jasmeet Chhabra (Intel), 11-04/1115r2 Outlined goals, requirements and assumptions. Assumptions included fact that authenticated Mesh Points can be trusted. Presented a basic security model in which new Mesh Point does standard 4-way handshake to extend security bubbble. Compared distributed and centralized authentication – probably need to support both. 802.11i does not provide management frame security – will need to submit requirements to the new protected management frame study group. Question on applicablilty of .11i to multi-hop routed environment? Are there problems with making management frames regular data frames? No group view yet. Is PAR’s single administrative domain assumption valid? Protected management frame SG will meet in San Antonio – suggested that TGs present there. Two four way exchanges is 8 messages – excessive? On Open Questions slide – add synchronization of servers. How to handle broadcast / multicast – at most, 2 keys at any one time – will need to solve roll-over problem. Chair introduced Task Group Process, Take 2, using 11-04/1058r1. This again covered discussions of process, informal subgroups, and schedule. The question was posed of how should we proceed toward a draft? With specific emphasis on Functional Requirements. Chair proposed to re-take Straw Poll. Comment that .11n (evaluation) process document was good, simplify, maybe use it. Not relevant to WHEN to do call for proposal. TGr did call and definition of selection criteria in parallel. Clarification requested on scope of proposals. Some areas of Requirements need flushing out. There will be iterations before getting out of Letter Ballot regardless. Suggested more discussion on scope before straw poll. How about doing two (or more) calls for proposals? Gives something to discuss. Rushing call does not necessarily guarantee earlier letter ballot – circular discussions. Will standard be perfect – no – it’s iterative – try to avoid .11n process – middle ground. Straw polls… When to do Call for Proposals;

After September 2-25 After November 21-12



After January 28-4 Window for submitting proposals;

2 months 0 4 months 25 6 months 10

Comments on when will requirements be in place?! Perhaps call will identify requirements? Will call be voted on? Chair again outlined possibilities to accelerate schedule such as ad hoc meeting outside of 802.11 meetings and teleconferences. Session adjourned at 9:58 Session VII Thursday, September 16th, 10:30am-12:30pm, Paris Salon Session convened at 10:34AM Tricci So presented document “TGs Selection Procedure Recommendation”, 11-04/1107r1 Based on TGn process, but without its Partial Proposal stage. Adds a Comparison Criteria document that TGs currently does not have. Proposed to base Criteria on TGn document, stripped down to remove system simulation step. Steve Connor presented document “Possible Options for 802.11 TGs Call for Proposals”, 11-04/1083r2. Some feedback received caused him to add a new: Option 2.5 with “Light Weight” Requirements and no mandatory simulation based comparisons. Comment that adding 2.5 is a good compromise. Need criteria but don’t want to drag on. Proposed to generate Comparison Criteria in parallel with Call for Proposal. But, how do people know if their proposal will be adopted without criteria? Alternatively, define first draft of all documents before with right to change. Comment that market wasn’t pulling for .11n, were for .11i. Straw poll on options in 11-04/1083r2…

Option 1 4 Option 2 11 Option 2.5 29 Option 3 0

The following motion was moved by Peter Eccelsine, and seconded by Clint Chaplin:

Moved, to direct the TGs chair to announce at the closing September 2004 802.11 plenary session and post to the 802.11 mailing list that TGs plans to issue a call for proposals shortly after the _______ 802.11 meeting with proposals to be submitted before and presented to TGs at the second 802.11 meeting thereafter.

The Chair adopted fill in the blank process. “November 2004”, “January2005”, and “March 2005” were nominated to fill the blank. The vote on “November 2004” was 7 in favour, 11 opposed so it failed. The vote on “January 2005” was 17 in favour, 2 opposed so it was selected to fill the blank.



By unanimous consent, “or before” was inserted just after the last “at” in the motion. It was moved to amend the motion by striking “second” and inserted “third” in place thereof. Vote 10 – 5 so this amendment was adopted. The amended motion then read

Moved, to direct the TGs chair to announce at the closing September 2004 802.11 plenary session and post to the 802.11 mailing list that TGs plans to issue a call for proposals shortly after the January 2005 802.11 meeting with proposals to be submitted before and presented to TGs at or before the third 802.11 meeting thereafter.

It was adopted by a vote of 10 – 0 – 7 Chair posed question on activities before next session. Suggestion that generation of requirements and specific documentss be the priority of TG at the next meeting? The following motion was moved by Steve Connor, and seconded by Vann Hasty: Moved, that TGs have bi-weekly teleconferences at 13:00 Pacific Standard Time Wednesday starting 29 September through 27 October. Notice will be given, including UTC time, at least 10 days in advance. There was no debate on the motion. It passed 17 – 0 – 2. Presentation #16: “Routing in Mesh Networks”, Myung. J Lee, Chunhui Zhu (CCNY), 11-04/1042r0. This overview presentation covered; definitions, features, desireable qualitative properties (from IETF), quantitative metrics, and basic classifications. The basic components of routing protocols were described. A major part of the presentation focussed on non-MANET routing protocols; Geographical and Position-based Routing, Directional Antenna Based Routing, Power, Link Quality and other Cost-based Routing, Multi-path Routing and Load Balancing, Binary Tree Routing, Virtual Backbone Based Routing, Sensor Network Routing, Layer 2 Data Forwarding and Layer 2.5 Routing. Finally, a summary of IETF and IRRTF activities was given. The chair announced that, since ECC Room 4 would be free, an adhoc meeting of TGs to work on documents required by Call for Proposals would be held there Thursday 1:30PM- 3:30PM. The Chair summarized planned TGs Report to the 802.11 Plenary, document 11-04/1128r1. TGs adjourned for the week at 12:32pm.


September 2004 doc.: IEEE802.11-04/1166r0


Minutes for the Task Group T September 2004 Session

Date:

September 14 - 16, 2004

Authors: Areg Arimian, Roger Skidmore

e-Mail: [email protected], [email protected]

Minutes TGT page Wireless Valley 1





1. Chair calls the meeting to order at 4:00 PM – Charles Wright 2. Chair comments 3. Mike Goettemoeller appointed secretary for Tom Alexander who is absent 4. Chair asks for objections for Portland minutes, none noted, Portland minutes accepted. 5. Chair asks for objections to agenda, none noted, agenda accepted. 6. Chair has made a call for presentations

a. 11-04/1009 – “Framework, Usages, Metrics Proposal for TGT”, Pratik Mehta b. 11-04/1017 – “Comments on Wireless Performance & Prediction Metrics”, Mark

Kobayashi c. 11-04/xxxx – “Systems supporting devices under test”, Mike G.

7. Chair asks for approval of modifications to agenda, note noted, revised agenda accepted. 8. Discussion of timeline going forward, progress since Portland – IEEE NesCom approval to

form TGT, technical presentations, re-present ideas. 9. Chair requested to comment on teleconferences and status of group as a whole – agreed that

metrics need to be derived first before going forward. 10. Chair makes move to recess until 4pm tomorrow; Roger makes motion, Lars 2nds. Approved

by acclaimation.


11. Chair calls the meeting to order at 6:00 PM – Charles Wright 12. Roger Skidmore appointed secretary 13. Technical Presentation – Framework, Usages, Metrics Proposal for TGT – 11-04/1009r1 –

Pratik Mehta a. Comment – Requesting an example of a submetric as described on slide 11. b. Comment – Presenter response is that packet loss would be an example submetric of the

throughput metric. c. Comment – On slide 12, directionality could be an important factor in non-data oriented

applications as well. d. Comment – Chair calls for discussion. e. Comment – Engineers tend to emphasize the confidence level of wireless measurements. f. Comment – Presenter responds that confidence levels and similar things of a statistical

nature are part of the methodology used to measure a given metric/submetric. g. Question – Taking an application-centric approach will allow the group to better yield

results in a reasonable amount of time? h. Comment – Presenter refers to slide 10, responding that it is better to map where the

group wants to be as part of the process. i. Comment – Testing a device for the home may be very different from testing a device for

an enterprise even for the same application. j. Comment – Presenter responds that defining the usage and environment (per slide 10)

helps partition the problem.



k. Question – How do you know that you are actually testing an “average” device rather than a “best-of-the-batch” or “worst-of-the-batch” type device?

l. Comment – Presenter responds that some sort of calibration, normalizing, or random sampling procedure may be required.

m. Comment – Being sensitive to the amount in variability in the tested response of a device is important.

n. Question – Any thought to common sources of interference and how those affect certain receive architectures?

o. Comment – Presenter responds that no specific thoughts have been centered on that topic as yet.

p. Chair – As in interferers unduly affecting a test? q. Comment – Uses in a home may involve myriad devices including non-802.11 devices. r. Chair – Topic begins to border on a co-existence issue. s. Comment – Certain radios have more robust interference rejection. t. Question – Does this mean that multiple environments need to be introduced for

individual metrics? u. Comment – Presenter responds that it is possible that metrics and submetrics will be

tested differently across different use cases. v. Comment – Prediction folks should be able to identify what types of interference

scenarios should be analyzed. w. Question – Is this considering a single device under test or a linked set of devices? x. Comment – Presenter responds that typically single devices have been considered, but the

group needs to take this as a point to discuss. y. Comment – Should be looking at packet errors as a metric tested against multipath and

other physical layer things. Can deduce throughput from packet error rate. z. Comment – Presenter responds that the user expectation/view is typically in terms of

throughput, but that packet loss could/should be a metric listed on slide 13. Slide 13 was not intended to list every possible metric.

aa. Question – Final step in process on slide 10 is prediction. When will there be a focus on prediction?

bb. Comment – Presenter responds that predictions will have a better chance of being accurate with measurement data. Group should certainly tackle predictions.

cc. Chair – The group is no longer predicting performance. dd. Question – Was prediction was cut from scope? ee. Chair – Yes. It is within scope “to enable prediction”. The development of prediction

models and prediction algorithms do not fall within the scope of the group. ff. Question – Beginning to hear talk of device classification. Is it within the scope of the

group to discuss device classes? gg. Chair – Device classifications or qualifying devices is outside of scope. Ranking or

qualifying devices is not the goal of the group. The output of the group could be used to enable device ratings, but the goal of the group is not create ratings.

hh. Comment – Believe that group is on track to enabling measurements, but do not have a feeling on what the group can do to enable predictions. Request for presentation on predictions and what is needed to enable them.

14. Technical Presentation – Comments on Wireless Performance & Prediction Metrics – 11-04/1017r0 – Mark Kobayashi a. Comment – On slide 10, producing something that simply says system A is “better” that

system B is worthless. Need something quantifiable. For example, quantifying device range.



b. Chair – Comment that range may vary depending on the type of test. c. Comment – Presenter comments that could develop categories of particular tests (e.g.,

bad channel models) that may help simulate actual conditions. d. Chair – In other words, want to map “user experience” into some form of repeatable test.

What do people think about the channel models developed for .11n? e. Comment – You’ll get differing responses on that. f. Chair – Need to solicit input on channel models from the larger 802.11 group. g. Comment – 802.19 utilizes channel models for coexistence. h. Comment – Interference and multipath can be tested separately from channel models.

Certain “barebones” metrics need to be tested and dealt with separately. i. Question – Does the material presented in 1017r0 conflict with that in 1009r1? j. Comment – Presenter indicates that 1017r0 and 1009r1 are very complimentary in terms

of the basic framework. Presenter prefers to look at usage model 1, 2, and 3 and produce a set of common metrics across all usage models; the goal being to identify similarities in the tests performed for each usage models.

k. Comment – Is a timeline being proposed? l. Comment – Presenter indicates no specific timeline is being suggested, but believes work

needs to get underway. m. Comment – Need to limit time spent discussing metrics in order to help move the work

flow along. n. Comment – Considering common metrics across platforms/usage models will be

beneficial. o. Comment – The presentations 1017r0 to 1009r1 appear to have distinct approaches.

1009r1 appears to address “real” usage models and seems to cover a large audience. The specific test environment for a given submetric test (per 1009r1) can characterize the submetric/metric very well. If the group were to only do Cabled Environment (for example), and then go one metric at a time, it will be somewhat limiting in terms of the usability of the group’s output.

p. Comment – Presenter indicates that sets of identical/near identical tests need not be repeated for different usage models.

q. Question – Would it be beneficial to mimic a measured channel using a waveform generator with devices in an anechoic chamber in order to achieve repeatability in a controlled environment?

r. Comment – Presenter indicates that the suggestion is possibly a good way of performing a test.

s. Comment – There will be a flow of data building up from semiconductor companies, to manufacturer, to system integrator, to IT manager. Each one higher up the chain is relying on decisions/results of those below them. TGT should try to get everyone along the chain talking the same language.

t. Comment – 1017r0 and 1009r1 are actually very different from one perspective. What is needed first is a test from the point of view of the user. Then afterwards, when that particular use case is finished, begin working backward to deal with other usage cases. Commenter is concerned that time will be wasted trying to analyze too many potentially very different usage models looking for commonalities rather than tackling one particular set of usage models, finishing them, and then proceeding.

15. Meeting in recess at 6:00 until 7:30.




1. Chair calls meeting to order at 7:40 PM 2. Chair – Open forum for discussion on previous presentations – brainstorming 3. Comment – Need to avoid discussions of metrics without having an end goal or at least a particular

use case in mind. 4. Comment – What about a test configuration? 5. Comment – Can’t discuss a test configuration without knowing what metric you’re searching for.

Suggest considering metrics in different levels geared towards a particular audience (e.g., system integrators, semiconductor, etc.).

6. Comment – Should not want to specify a particular vendor’s test equipment (i.e., “golden node”). For example, could have two devices under test where you simply set them up side-by-side, but that may not be valid.

7. Comment – Difficult to completely mimic all test conditions without some form of standardization of test equipment. Is a faulty test due to the device under test or because the test equipment or conditions were ever so slightly off?

8. Comment – Possible test flaws could be listed as test preconditions (e.g., could a listed as limitations of testing systems) or test “gotchas”. Then if test was not 100% repeatable, would be due to one or more of the possible test preconditions.

9. Comment – For throughput and forwarding rate, we know what theoretical maximums are. For latency and jitter, have no minimums other than zero. So preconditions could also include bounds.

10. Comment – Varying degrees of test could also be a measure of the repeatability of the test. The more repeatable the test, the closer the test preconditions would need to be to the required, precise test conditions and/or setup.

11. Question – Is non-repeatable/instantaneous measurement testing infringing on .11k? 12. Comment – .11k could serve as a vehicle for fulfilling the mechanism or procedure used in the test. 13. Comment – There is a big difference between a company with heavy investment in test

equipment/labs and significant experience in equipment analysis and an IT manager who is evaluating a product offering. Those two categories of “consumers” for TGT’s output are very different in their needs.

14. Comment – There is no way to simulate in a lab every possible scenario an IT manager may experience, it is possible to specify sets of tests an IT manager could take the time to setup and perform. The sets of tests may have varying complexity and/or range of error based on how closely the IT manager can duplicate the test conditions/preconditions.

15. Comment – Do we know how current IT managers qualify equipment and network configuration? 16. Comment – It varies widely. The wireless knowledge of IT managers factors heavily into this. 17. Question – Is this group going to focus on how to deploy a network? 18. Chair – No, this is outside of the scope of this group. This group is focused on measuring device

performance under certain test conditions and then utilizing that information to make performance predictions later.

19. Comment – At the end of the day, we need to measure metrics. 20. Comment – The types of tests that you need to run will vary depending on who is doing the

testing. Semiconductor companies need different tests than IT managers. Need categories of tests for categories of users.

21. Example PHY layer metrics a. Packet error rate (PER) b. Factors inherent in the device (recommended practice would specify bounds on the

following for particular PER tests)



i. Error vector magnitude (EVM) ii. Transmit power

iii. Receive sensitivity 22. Comment – What is the most representative controlled test for 802.11 wireless performance?

a. It would exercise the entire device in one test. b. It would focus only on performance aspects affected by the MAC, PHY, or antenna. c. It would be a “macro” measurement, not a “micro” measurement (e.g., focus on

“communication system” level metrics – forwarding rate, loss, delay, jitter, antenna gain, FER vs. input signal level).

23. Comment – Why use layer 2 traffic for testing? a. TGT must stay in the domain of 802.11 b. Using true or simulated application traffic obscures the effects of wireless

i. TCP is a common offender. c. Specifying application level traffic makes it hard to decide where to stop (e.g., which

favorite video or voice standard do we exclude?) 24. Comment – The “big four” layer 2 measurements are forwarding rate, MSDU loss, packet delay,

and jitter all made under various conditions (e.g., with and without multipath, with and without adjacent channel interferers, and varying signal levels)

25. Question – Is multipath still an issue with OFDM? 26. Comment – Yes. OFDM may be resistant to multipath, but papers presented here have shown that

multipath needs to still be considered. 27. Comment – All of the metrics we are discussing measuring for wireless have already been defined

as well as procedures for measuring them on wired networks. TGT should focus on layer 2 metrics and leave upper layers alone (e.g., application layer).

28. Meeting in recess at 9:35 PM until 4:00 PM Thursday afternoon.




1. Chair calls the meeting to order at 4:00 PM 2. Announcement regarding file server being temporarily unavailable for uploading documents 3. New items added to today’s agenda:

a. Technical Presentation -- 11-04/1131r1, “A Metrics and Methodology Starting Point for TGT”, Charles Wright, Mike Goettemoeller, Shravan Surineni, Areg Alimian

b. Motions or straw polls arising from 11-04/1009r1 and 11-04/1131r1 c. Technical Presentation -- 11-04/1106r0, “Systems Supporting Device Under Test”, Mike

Goettemoeller d. Technical Presentation -- 11-04/1132r0, “Enabling Prediction of Performance”, Roger

Skidmore 4. Amendments to the agenda accepted by unanimous consent 5. Technical Presentation – 11-04/1131r1, “A Metrics and Methodology Starting Point for TGT”,

Charles Wright, Mike Goettemoeller, Shravan Surineni, Areg Alimian a. Comment – Presentation 11-04/1131r0 is available from the document server, but only via

a FTP client due to the problems with the file server. b. Comment – Presentation 11-04/1131r1 available on the document server does not precisely

match the presentation being shown. Presenter indicates the wrong file must have been uploaded to the file server, and that the problem will be corrected after the meeting. The presentation continues without objection.

c. Comment – Presentation 11-04/1131r1 and 11-04/1009r1 seem somewhat orthogonal to one another.

i. Presenter – Presentations are actually complimentary as they are focusing on different parts TGT’s work.

d. Comment – On slide 6, others may interpret the diagram of the proposed test bed too literally.

i. Presenter – A note will be added to the slides that the image is not intended to be final at this stage.

e. Question – Are the four separate diagrams in the presentation indicative of a setup a user must have to carry out the test?

i. Presenter – TGT is a recommended practice, and all output from the group will be labeled as a “should” rather than a “must”.

f. Question – Do multipath simulators have RF In and RF Out. i. Presenter – There should be. Also believe it is one of our jobs in the group to

determine what set of channel models to recommend for the tests we describe. g. Question – Are you considering devices other than APs and STAs?

i. Presenter – Yes. Other “atypical” 802.11 devices will fit in the same test paradigm. h. Question – On slide 6, “Ethernet” should be “Ethernet (suggested)”?

i. Presenter – Yes. i. Question – On slide 6, if you have an atypical 802.11 device the user may have need of

additional test or analysis equipment not shown in the diagram to actually carry out the test or data analysis?

i. Presenter – Yes. j. Question – With regard to testing atypical 802.11 devices, if the device can adhere to the

basic requirements of the test system, does TGT plan to introduce some form of statistical “workaround” if the device simply does not fit in the given chamber.



i. Comment – May be getting too deep into the details of the test setup at this stage rather than focusing on the bigger picture of the appropriate direction for TGT as a whole.

ii. Presenter – A great time to begin that discussion will be when the group approaches the end of the scheduled agenda today.

6. Motion a. “Move that TGT adopt the framework and approach outlined in document 11-04/1009r1

from slide 10 to the end.” i. Mover: Pratik Mehta

ii. Second: Areg Alimian iii. Vote: 5 / 0 / 1 Motion passed.

b. “Move that TGT adopt and focus on the three “usage + environment” cases outlined on slide 12 of document 11-04/1009r1.”

i. Mover: Pratik Mehta ii. Second: Areg Alimian

iii. Vote: 4 / 0 / 2 Motion passed. 7. Straw Poll

a. “Is TGT in favor of accepting the metrics and test methodology approach described in 11-04/1131r1?”

i. Vote: 7 / 0 8. Technical Presentation -- 11-04/1106r0, “Systems Supporting Device Under Test”, Mike

Goettemoeller a. Question – On slide 4, is there a definition of the term “device under test”?

i. Presenter -- The device under test I am considering here is the embedded wireless card or component of a larger wireless device. This is how I recommend mitigating other “external” effects that are caused by other components comprising the larger host system.

b. Comment – Suggest that in the future we always clarify whether an entire device or simply a component is the “device under test” to avoid confusion.

c. Question – On slide 8, the cardbus spec indicates that the card needs to be able to support 800 mA?

i. Presenter – That’s correct. d. Question – On slide 8, you recommend using an external power supply, and how your test

procedures help you state anything useful about the cards you yourself develop? i. Presenter – Yes (power supply). Our internal tests help us counter negative

comments we may receive back from our customers as we can point to factors other than our own equipment fault as being the true issue.

e. Comment – On slide 12, request for clarification of how the measurement readings were collected.

i. Presenter – Probe was run along the outside of a laptop PCMCIA controller. f. Comment – Appears to be a great start on beginning to define an accurate test setup,

especially an open air test. g. Comment – One of the things we may want to consider is that this is on the same path as a

“golden node” vs. “no golden node” type of discussion, though. There are plusses and minuses to both paths. This is a great presentation adding to that topic.

h. Comment – This is a very good presentation highlighting a number of real-world issues that are possible, especially when dealing with PCMCIA card devices that are reliant on other devices (e.g., laptops). Sort of goes back to what is the user level perceived performance issue.



i. Comment – I believe the issue of the “device under test” (DUT) depends considerably on what comes as part of the “kit” you buy. If a separate PCMCIA card is in the kit, the PCMCIA card may need to be considered as a separate DUT.

j. Comment – Defining the DUT should be an important topic for TGT to work on. k. Comment – I think it is very important that the platform be specified as part of the test.

9. Areg Alimian takes over as TGT secretary as Roger Skidmore must leave for another engagement. 5:40 PM Mike G finished the presentation. If PC magazine was doing review of wireless cards, it’s preferable so that it works not with one but with every laptop out there.

Pratik: If you want to know the real answer, you should give them a laptop with PCMCIA card.

Charles: Question: Are the guidance things like if you are going to run a test where the host system is not coupled with the NIC, should the group include recommended practices for voltage regulation measurements, etc as outlined in Mike G. presentation 1006.

Charles: Such recommendations, as outlined above, should be listed as more of recommended practices vs normative test environment setup/configuration.

There would be a separate section in the test document which will list such system behavior impacting conditions.

Chair: We have 15 minutes left, does anyone want to bring business related to what we’re going to do after this meeting closes, so that we can do it now and not have to stay till 9:30. Example of teleconferences. If there is no objection talking about telecoms….

We’ve been having weekly telecoms since the study group commenced their sessions. I brought this up in Portland and people still want to continue having weekly teleconferences. I would like to suggest for the group not to have a teleconference for a given date if there are no particular presentations available for that telecom.

There was a consensus in the group on the above.

Pratik: The hope is that we will have teleconferences more often than not. It will send a wrong message to the working group if by default we don’t have a telecom unless specified.

Mark: I’m wondering if there should be a minimum of two telecoms between IEEE meetings. This way people can get caught up.

Chair: Rather than meeting every week, we can meet every other week unless cancelled.

Pratik: You will have hard time getting back to weekly mode if there is more going on.

The group agrees to have weekly teleconferences as before.

Chair: I will send a cancellation notice to the reflector prior to the meeting. Also next week I will be at WiFi and there will be no teleconference. We shall also keep the same teleconference time, which is 12pm EST.

We should empower ourselves to conduct the teleconferences during the working group meeting this Friday. A motion is drafted to be presented at the WG meeting this Friday.



Motion #3. Move to request empowerment for the TGT to hold weekly teleconferences scheduled at 12 noon Eastern time Thursdays.

The group recessed until 7:30 pm at which time Roger Skidmore will make a presentation on enabling wireless performance.



Thursday, September 16, 2004

7:00 PM – 9:30 PM

1. Chair calls the meeting to order at 7:00 PM 2. Technical Presentation -- 11-04/1132r0, “Enabling Prediction of Performance”, Roger Skidmore 3. Meeting adjourned. 9:07 pm.



IEEE P802.11

Wireless LANs Minutes of Wireless Interworking with External Networks Study Group

(WIEN SG) Meetings

Date: Sept 13 - 14, 2004

Contact: Cheng Hong Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Avenue #06-3530 Tai Seng Ind Est - 534415 Singapore Phone: +65 6550 5477 Fax: +65 6550 5459 e-Mail: [email protected]

Abstract Minutes of WIEN SG meetings held during the IEEE 802 Interim meeting in Berlin, Germany, from September 13 - 14, 2004. Monday afternoon Session of WIEN: September 13th 1600 - 1800

1. Logistics WIEN Meeting called to order by Stephen McCann (Chair) at 1600. Agenda was reviewed (04/1015r0) and approved. The IEEE 802 & IEEE 802.11 Policies and Rules were reviewed. Patents and By-laws read out by the chair, together with licensing terms and associated conditions. 2. Report from last meeting and Teleconference The chair gave an overview of the last meeting outcome (04/0834r0). Minutes of the last meeting 04/851r1 is reviewed and approved. Minutes of the teleconference from August 11th 2004 04/896r0 is reviewed and approved. 3. General review of the current PAR and 5Criteria The chair gave an general overview of the PAR (04/506r6) and 5Criteria (04/507r1). The detail technical comments were addressed on Tuesday. - PAR (04/506r6) Comment: This work would be about a single interface. Wouldn’t it need two interface to address handover? Stephen McCann: Handover would be dealt by IEEE 802.21. This PAR is only about interworking.

Submission page 1 Hong Cheng, Panasonic



Comment: What does WIEN do? Stephen: WIEN will deal with QoS, policy, issues concerning the air interface, etc, that may have impact on the IEEE 802.11 spec. Mobility is out of scope of the group. - 5Criteria (04/507r1) Michael Mantemurro: Is the Wi-Fi alliance a standardization body? It is more of a marketing body. Stephen: will get back to that on Tuesday when discussing the technical issues. 4. Presentation on 3GPP2 WLAN interworking (04/1054r0) Stefan Rommer Sabine Demel: Does the Authentication method apply only to 3GPP scenario 1 or also to 3GPP scenario 2? Stefan Rommer: Only to 3GPP scenario 2. Sabine: This is secure enough for 3GPP scenario 2? Stefan: Yes. Stephen: Does that mean that the session key is unrelated to that used for the air interface Stefan: Similar to what is done in 3GPP, it is derived from session key, not really unrelated. Stephen: Do you think we need a liaison (LS) to 3GPP2 based on what you have said? Stefan: Yes, a LS to 3GPP should also be copied to 3GPP2. Stephen: Is it the time right to contribute to their work Stefan: Yes. They are talking about network selection issue Stephen: will you be a LS officer? Stephen: To address that offline. Jan Kruys: Can you mention more about UMA (Unlicensed Mobile Access). Stephen: UMA is a forum instead of standardization body. Stefan: UMA re-uses GSM mobility solutions. Jan: So it will be in the list of liaison list Stephen: Yes. Will also send LS to that group. Dorothy Stanley: UMA is providing a method to access GSM services. UMA could be a user of WIEN's capability (e.g. network selection). But it is not posing any requirements on WIEN. Stephen: So, it is more of a one way communication. Dorothy: They could use what we are doing, but not need/require what we are doing. 5. Outgoing Liaison The Chair calls for volunteer for LS officer. Andrew Myers: 3GPP has asked for a LS. They are looking forward for LS from this group, about the link layer protection Stephen: Is that related to IEEE 802.11i? Andrew: No. Stephen: Who volunteers to be the Liaison officer Yashuyoshi: What is the purpose of the LS? Stephen: It will state the areas we are working on, and we feel will be issues for 3GPP, and state that those issues will be dealt within IEEE 802.11 6. Network Discovery and Selection (04/1020r0) Stephen McCann Comment: What is RFC2486bis? Stephen: It is Network Access Identifier (NAI) Michael Mantemurro: Why isn't it a combination of all the possible methods? For using EAP you need to have to have a connection Stephen: That is the 3GPP choice. In the Wednesday afternoon session we could comment more on that.



Stephen: Comments will be made on the two Internet Drafts (I-D) on Wed, and result will be an input document to the IETF. Stefan: Is that reasonable to have multiple solutions? Mike: There is a solution to have accommodate both Sabine: The 3GPP are trying to choose one that will not affect IEEE. That is why we need work here to find out a way to solve it within IEEE. Stephen: Yes. We are in a position to change IEEE 802.11 Stephen: But we could also take it to a higher level to make it generic for IEEE 802. Monday Evening Session Sept 13th 1930 -- 2130

7. Network Discovery (document file 04/1021r0, slides 04/1061r0) Eleanor Hepworth Jon Edney: Is it overlapping with IEEE 802.11r? e.g. QoS capability discovery. Maybe the mechanism could be generalized to accommodate IEEE 802.11r Jan Kruys : Why it has to be at the MAC layer, and not left to IP? Eleanor Hepworth: There are different phases. The earlier you get the information, the better for the terminal to make better decisions instead of wasting resources, e.g. getting the IP connection. Jan : Why would the hotspot broadcast not work? Eleanor: The terminal cannot have IP connection at that stage. Jan : There is so much information to broadcast, and it may not be all from AP, and it could from other place/layers. Mike Moreton: This is a IEEE 802.11 issue. And it needs to be sorted out in IEEE 802.11. IP issues will be dealt with in other groups Stephen: EAP based solutions will be discussed on Wednesday. Stephen: Isn’t the Layer 2.5 issue conflicting with IEEE 802.21 Eleanor: It is complementary Stephen: Should we try to present this information in IEEE 802.21 later. 8. Extending 802.11 MAC (1079r1) Eric Njedjou Jon Edney: Are you suggesting this to WIEN as a new association procedure? Or it is a IEEE 802.21 recommendation? Eric Njedjou: It is out of scope of IEEE 802.21. It is more of a IEEE 802.11 issue Subir Das : Why you think it is necessary to be at the MAC layer? Eric: When you roam into a BSS and not associated, how you get the info? Using the MAC layer could be a solution Subir Das: Don't see any problem using the current solution to assistant handover Eric: It is not about latency optimization. It is about a mobility manager helping selection before the initiate MIP procedure. Subir Das: What are the problems we are facing? And the type of info specified here, could be done at higher layer. Eric: But it also need to select which is the best connection. Mobile IP does not support that. Subir Das: Is it suggesting network selection need this? Don't see the need and advantage. Eric: The MAC layer is more efficient than using IP for the network info transport Subir Das: Network has to do something instead of just getting the info to work. Eric: STA can help to get the info about that for the network. ??: You can do it much later if it is done after authentication (ciphering). Need to talk to the security groups regarding this. Eric: This is just to bring to the attention of the groups. Stephen: Maybe useful for IEEE 802.21 and IEEE 802.11r. Layer 2.5 is out of scope of WIEN.



Eric: It is a selection issue, and could be before mobility procedure starts (IEEE 802.21) Stephen: Will have a network selection session on Wed. Could discuss the issue there. 9. Reviews of the PAR and issue list Subir Das: About the MAC address anonymity, it is conflicting with the IEEE 802.11r presentation regarding security from Jesse Walker Stephen: Will discuss that tomorrow morning. Sabine: What is the Network Selection issue? Is that related to IEEE 802.21 Stephen: It is a IEEE 802.11 problem, but not necessary a WIEN problem. WIEN is only working for the interworking not mobility issue. IEEE 802.21 works on mobility issues, and at some point of time, they will come back to WIEN to apply changes to IEEE 802.11. Tuesday Morning session Sept 14th 0800 - 1230

10. ARID issues (04/1019r0) Daniel Park Stephen McCann (Chair): This issue is in the list of open issues in 04/1066r1. We need to decide whether it is in the scope or not according to the decision of last meeting. Eleanor Hepworth: Not sure what information is it, and may need to check with IEEE 802.11r & IEEE 802.21 for that Stephen: Is it a request for clarification of the motion? Eleanor: No sure. ◊ Motion: Move to request that the IEEE802.11 WIEN SG accepts that the Access Router ID

(ARID) is regarded as work to be done within the PAR Result: 7-2-10 Motion passed.

Open issue list 04/1066r1 updated according to the result to 04/1066r2 11. Discussion of PAR and 5Criteria - Discussion of the PAR (04/0506r6) Jan Kruys: Are we sure we have the signaling issues here? Not sure where the interworking happens. Why should the air interface need to be modified? Stephen McCann: The specific interfacing issue is not clearly stated. It is not explicit now. Regarding air interface, it is included since there may be changes in the MAC. Jan: To change the MAC need a real problem, and could not be solved by other ways. Stephen: Yes. Agree to that. Stephen: Will it be good to have the list in the PAR and describe each in more detail? Jan: Yes. Stephen: Will do that at the end of the PAR document Jan: Regarding section IEEE 802.16 about single interface, cannot not imagine multiple IEEE 802.11 interface. Stephen: IEEE 802.21 is talking about terminal with multiple interfaces of different technologies. Here, we are only concentrating on IEEE 802.11.



Cheng Hong: What it is trying to say is this project only considers IEEE 802.11 issues instead of other technology. Whether it is multiple interfaces is irrelevant. Stefan Rommer: It does not matter even if the terminal has multiple interfaces. This project would only consider the IEEE 802.11 interface. Stephen: Yes. Stefan Rommer: Maybe should not constrain the terminal in the PAR Stephen: Yes. Jan: Suggest to state "This project only considers the IEEE 802.11 air interface" Stephen: How about the network side? Eleanor: This section is only stating the difference to IEEE 802.21, not the full scope of the group. Cheng: It is more than air interface, maybe should be “issues related to” David Hunter: This group’s work should be more than the air interface. Wording like “air interface”, may prevent the group to work on management issues. Stephen: Propose the wording "issues which impact upon the IEEE 802.11 air interface” Jan: Is there a document for the agreement between IEEE 802.21 and WIEN? Stephen: It is in the minutes. Not a document. Jan: It would be good to have a document as a prove. Stephen: Maybe a liaison with IEEE 802.21 would be good. Stephen: Will add an open issue list to the end of the PAR Stephen: Will we discuss the issue on the screen, or go to ad hoc mode for the editorial? Sabine: Need to add a bit explanation to each of the bullet to help people to understand it Stephen: Recess until the morning break to edit the text ad hoc. Meet again at 10:30 12. Discussion of PAR and 5Criteria resulted from the Ad Hoc editing session - Discussion of the 5criteria document (04/507r1) Section 6.1 Stephen: Is there any other organization should be listed for the 3G subscriber? Sabine: Should it be 2G/3G? There may be 2G users also accessing the services David: Just say cellular subscriber. Stephen: How is the situation in Japan? David: Have both 3GPP and 3GPP2 Section 6.1.b Jan: The attendance is a small percent of the IEEE 802.11 attendance. Can it claim “significant”? Mike Moreton, David Hunter, Stephen McCann: Feel there is significant interest. Also outside of the scope of the study group (SG). Section 6.3 David: Should IEEE 802.11r be mentioned in the list? Stephen: IEEE 802.11r is still within the IEEE 802.11 working group. This section only mentions about 802 groups. Jan: Wi-Fi Alliance is not standardization body. Stephen McCann, Stefan Rommer: "industry associations" Stephen: Does it have to be an exhaustive list? David, Cheng Hong: No, since there is a "such as" there. Section 6.3.c Jan: This sound a subset of .21



Stefan: .21 is not on interworking, they are on handover Jan: Should be consistent with the using of the interworking amendments. The point is that this standard only address interworking elements. The updated 5Criteria (04/507r2) is uploaded to the server. - Discussion of the PAR revision (04/506r7) Section 19, about the open issue list: Sabine: First point. What are the characteristics of the network? Stephen: We may need to decide if the network side issue is in the scope regarding the beacon scalability: Jan: seems like usual interface. Not seeing any MAC modifications necessary Eleanor : Need to have some mechanism to support the change of information Jan: There are various solutions to that problem. This is looks like it is the only solution Eleanor: There are presentations in SG stage discussed about that. Jan: Standard should only specify only the minimum part, and not beyond that (those nice to have not have to have) Sabine: Maybe saying it should be investigated. Jan: This is a PAR, it needs to means there is a problem to be solved. ◊ Straw Poll: Would you like to see specific point of the Secure Portal Page/IEEE802.11i co-

existence be exist in the PAR Result: 10-1 The point is listed

Stefan: What does it mean for the list? Do we have to work on that or we "can" work on that? Stephen: This list should be clear example of the issues we want to include Stephen: however, the list is not exhaustive. Sabine: About the MAC anonymity, to be in the list means we need to find a solution? Stephen: we will try to find a solution. We have identified as an issue, (may not find one) Jan: It is vague about the policy Stephen: Any additional to that text? Jan: No. Jan: How the charging is done at MAC level if the MAC address is anonymous? Cheng: AP should be able to identify the terminal, maybe using other means, after authentication. Stephen: that goes to the solution instead of problem definition PAR is uploaded to the server as 04/507r8 ◊ Motion: Move to accept the IEEE802.11 WIEN SG PAR (506r8) and 5 Criteria (507r2) and to

forward these documents to the IEEE 802.11 WG Result: 15-1-0

13. Roadmap of the group (04/712r1) Stephen McCann Stephen McCann (Chair) presented the roadmap (04/712r1) for the group for the next few meetings The Meeting adjourned till next meeting in November 2004.




Minutes for the Study Group WNM September 2004 Session

Date:

September 14, 2004

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]

Minutes page Paul Gray, AirWave Wireless, Inc. 1



1. Chair calls the conference to order at 6:00 PM 2. Attendance 3. Review IEEE 802 & 802.11 Policies and Rules

a. Patent Policy b. Inappropriate Topics c. Study Group Function, Formation, Continuation, Operation d. Documentation – 4 hour rule for changes that are normative e. Voting f. Roberts Rules

4. Objectives for Meeting 04-739r1 a. PAR & 5 Criteria

5. Chair – we need to elect a new Chair either now or future. 6. Call for papers

a. Joe Kwak tonight b. Joe Kwak has 2 additional presentations if time allows

7. Review Proposed Agenda 8. Motion to approve agenda Motion Move to approved the agenda for Study Group WNM

Moved by Joe Kwak Second by Andrew Myles Motion passes unanimously

9. Motion to accept minutes Motion Move to accept the minutes from teleconferences

Moved by Lars Falk Seconded by Roger Skidmore Motion passes unanimously

10. Presentation - Review PAR & 5 Criteria – 11-04/537r7 - Worstell a. PAR & 5 Criteria b. Comment – Our scope is too vague and encompasses everything. Answer – we placed

some additional explanatory notes to address this. c. Comment – we should delay the start of this group until 802.11k is complete and vendors

and researchers have had time to figure out what is needed. d. Comment – We left the scope very broad so we have flexibility to come back and change

it. e. Question – How do we measure success or how do we know when we are done? Answer

– In TGk at the end of every meeting we asked the question “Are we ready for Letter Ballot”.

f. Question – Are there any real world scenarios? Answer – We defined a Use Case Scenario document 11-04/548r0 at a previous meeting.



g. Chair – Some of our research focused on other industries that are doing a great job of provisioning and configuration like Cell/Telecom industry.

h. Question – You are planning to get it to ExCom by February? Answer – yes i. Question – What is the motivation of getting the Study Group defined ASAP? Answer –

802.11 does not like Study Groups to exist for long periods of time. They give you 6 months and we have already exceeded the 6 months. The Study Group’s purpose is to create a Task Group.

j. Comment – nobody is using the standard 802.11 MIB from an AP perspective. The MIB only focuses on the STA.

k. Comment – We do not want to restrict the interface to be a MIB. l. Comment – we should not do all the research in the Study Group that is what the Task

Group does. m. Comment – the word “management” is very broad. n. Question – How will we communicate to the client? Answer – in 802.11k we used a

layer 2 tunnel. o. Comment – in the future we will have all types of devices on the network which will

have limited memory and processing capabilities. p. Comment – My vision on WNM would be able to get statistics from clients, because

clients currently do not provide any interface (SNMP). q. Comment – 11k is providing statistical interface on the station. r. Comment – We are defining 2 interfaces (1) interface between client and AP and (2)

interface between AP and NMS. Who would consume the AP to NMS interface? s. Comment – CAPWAP believes the interface between the AP and client is

complementary. t. CAPWAP – Is studying how to centrally manage all devices from an overall perspective. u. Comment – we should formally ask CAPWAP what they require. Answer to Comment –

we have done this in the past. v. Question – are we going to support CAPWAP or not? w. Comment – what are the other forums? (1) UPN and (2) CAPWAP

11. Meeting in recess at 6:00 until 7:30.




1. Chair calls meeting to order at 7:35 PM 2. Review SG WEIN Par and 5 Criteria document 506r6 3. Continue presentation - Review PAR & 5 Criteria – 11-04/537r7 – Worstell

a. We should provide detail like WEIN. 4. Motion to amend agenda to allow technical presentations – motion passes unopposed

a. Comment – provide an interface for configuring the clients from the AP b. Comment – we should document that 11k is focused on measurement and we are focusing

on configuration. c. Comment – we used the term “management” to encompass both control and monitoring. d. Comment – we should keep devices and not define clients and APs. e. Comment – we should have detailed explanations for IETF CAPWAP, IETF SNMP, and

802.21. This would include an overview of what each of these are doing and how it overlaps with wnm.

f. Proposed Purpose Text (Pat Calhoun) – “The purpose of this document is to provide amendments to the IEEE 802.11 PHY/MAC layers which enables a management entity to manage (e.g. monitoring, configuring, and firmware updating) attached stations through a layer 2 mechanism. While the 802.11k task group is defining messages to retrieve information from the station, the ability to configure the station is not in its scope.”

14a. Reason: The current IEEE 802.11 specification assumes that stations are managed via SNMP. The use of SNMP introduces the following problems: - Very few stations in the market include SNMP capabilities - The use of secure SNMP protocol (e.g. SNMPv3) requires significant pre-

configuration of the station - The use of SNMP to manage a station exposes a device (from a management

perspective) from any device on an IP network (security risk) - Management of a station may be required prior to the establishment of an IP

connection (there are cases where a device must be managed because it cannot get IP connectivity)

The proposed task group will collaborate with external SDOs, such as CAPWAP

g. Comment - We are now redefining the purpose and reducing scope. h. Comment - We have too many hooks and APIs in the spec currently. 802.11h and 802.11k

define a great deal of nice hooks, but nobody knows how to use them. i. Comment - We need a simple API which allows a group of devices to function as a

network. j. Comment - CAPWAP only deals with AP to AC on the LAN – we should make the

distinction that WNM is over the air. k. Comment – The line above the MAC will be addressed by CAPWAP and MAC and below

802.11 IEEE will define. l. Comment – CAPWAP is going into Layer 2 – doing layer-2 control over a layer 3 tunnel. m. Comment – Can we see the scope of CAPWAP? Answer – yes.

i. WNM – NMS in NOC ii. AC – 802.1x authenticator and MAC management – associate phase and messages

iii. AP – Splits the AP and pushes some above and below iv. WTP – thin AP



v. WNM – talking to stations There are 2 interfaces on a legacy APs and thin APs.

n. Comment – we must make the definition generic enough so this will work with UPP, etc. o. Comment – CAPWAP cannot expect IEEE to change things to accommodate CAPWAP.

5. Technical Presentation – Vision for IEEE 802.11 Wireless Network Management – Joe Kwak - 11-04/1059r1

a. Comment – Vision 1 and 2 is very compatible with CAPWAP b. Comment – the only thing that is not compatible is load balancing algorithm c. Comment – we should make it broad enough to encompass other management entities. d. Comment – we need to encapsulate some of the vision and some of Pat’s proposed scope

into our vision statement and not Purpose. 6. Meeting in recess at 9:37 PM until 8:00 AM tomorrow morning.



Thursday, September 15, 2004 8:00 AM – 10:00 AM

1. Chair calls the meeting to order at 8:19 AM. 2. Review Agenda

a. Approve Agenda b. Revise Par & 5 c. Presentation d. Review Next Steps

3. Motion to approve the agenda Motion

Move to approve the Agenda

Moved: Bob Miller Seconded: Joe Kwak Motion passes unanimously

4. Technical Presentation – Proposed Par & 5 – 11-04-1087r0 – Bob Miller a. Comment – This is a very broad scope. b. Comment – I thought the prior PAR from last night was fine. c. Question – Chair wants to know if we want to stay with the older PAR or the new proposal. d. Comment – wnm should be delayed until TGk is at Letter Ballot because (1) we not sure if

we need these measurements, (2) we need to learn from TGk, (3) there not that many people coming to TGk and those people need to focus.

e. Comment – When TGk started it was believed that we should address both measurement and management, but the scope would be too large. We have done this and TGk has served well in determining what the inputs are. We need to do these simultaneously so we have the option to expand what we miss in TGk.

f. Comment – Agree, when is the logical end of TGk. We have not learned from TGk. g. Comment – Many of the companies here have developed these component in other

industries like 3G, etc. h. Comment - The overlap can be avoided by not holding meetings in parallel. i. Comment – Learning occurs in real implementations, done by real companies. j. Comment – There is model based research which will allow us to proceed. k. Comment – 11e provides a good example of modeling (HCCA). Real experience in the

field is where we learn. l. Straw Poll

Straw Poll Do people want to start WNM as Task Group as soon as possible with the assumption that TGk and WNM don’t meet in parallel sessions? For: 11 Against: 2

5. Work on Par & 5 – Pat Calhoun Presenting a. Proposed Text 14 – “The purpose of this document is to provide amendments to the IEEE 802.11 PHY/MAC layers which enables management in a centrally or in a distributed fashion (e.g. monitoring, configuring, and firmware updating) attached stations through a layer 2 mechanism. While the 802.11k task group is defining messages to retrieve information from the station, the ability to configure the station is not in its scope.” The proposed task group will also create an AP MIB.



14a. Reason: The current IEEE 802.11 specification implies that stations are managed via SNMP. The use of SNMP introduces the following problems: 1. Very few stations in the market include SNMP capabilities 2. The use of secure SNMP protocol (e.g. SNMPv3) requires significant pre-

configuration of the station 3. Management of a station may be required prior to the establishment of an IP

connection. There are cases where a device must be managed because it cannot get IP connectivity.

Therefore a standardized approach to manage stations is required.

802.11 APs have significantly increased in complexity and features, which cannot be controlled via the current MIB. The task group needs to expand on the existing MIB (or create a MIB) to support these new devices. The proposed task group will collaborate with external SDO to ensure that its output is useful to those groups.

b. Question – Should we leave “through a Layer 2 mechanism” in the purpose? c. Question – How does the AP MIB get terminated in the MLME? We are now addressing

this issue in TGk. d. Straw Poll

Should the purpose include the phrase “through a Layer 2 mechanism”. For: 8 Against: 4

Straw Poll Passes

6. Meeting in recess until 10:30 AM



Thursday, August 15, 2004 10:30 AM – 12:30 PM

1. Chair calls the meeting to order 10:35 AM 2. Quick review of updated Par & 5 from previous session

a. Question – any additional notes for inclusion? Answer – none. 3. Review current document

a. Question – What does “or upper layers” mean? Answer – we will interface with upper layers.

b. Comment – we don’t have access upper layers. c. Comment – we can’t modify upper layers. There is nothing in the 802.11 PAR that

restricts us from doing this. d. Comment – This is technically correct, but nobody has tested the waters. e. Comment – we are striking “and upper layers” from Section 13 f. Question – Does anyone object to section 13? Answer – none.

4. Section 14 discussion - Purpose a. Question – is there another type of management besides centralized or distributed? b. Question – Does anyone object to section 14? Answer – none.

5. Section 15 discussion – Intellectual Property 6. Section 16 discussion – Similar Scope 7. Section 17 discussion 8. Section 18 discussion – Healthy and Safety 9. Section 19 discussion – Additional Notes 10. Motion

Motion Move to adopt document 11-04-0537-07-0wnm-WNM Draft PAR and documented 11-04-0684-01-0wnm-draft-5-criteria-wireless-network-management.doc and forward them to the 802.11 Working Group for approval to start a Task Group. Moved by Richard Paine Seconded by Joe Kwak For: 14 Against: 1 Abstain: 1 Motion Passes

11. Technical Presentation – Wireless Network Management Issues – 11-04/1103r1 – Joe Kwak 12. Technical Presentation – Support for Advanced Antennas & Techniques in WNM – 11-04-

1102r1 – Joe Kwak a. Question – If new measurements came up and TGk did not address would wnm address?

Answer – yes. 7. Technical Presentation – Management of Wireless Networks (XML) – 11-04/1104r0 – Joe

Kwak a. Comment – XML management is not close to an RFC b. Comment – There is way to much SNMP management out there for it to go away.

8. Complete Agenda 9. Meeting adjourned until San Antonio



Attendance Name Email Address Harry Worstell [email protected] Richard Paine [email protected] Gray [email protected] Sebastien Dure [email protected] Roger Skidmore [email protected] Bo kuaenstrom [email protected] Stefan Rommer [email protected] John Klein [email protected] Simon Black [email protected] Dmitri Varsanofiev [email protected] Andreas Floros [email protected] Platis [email protected] Benveniste [email protected] He [email protected] Montemurso mike@chant Dorothy Stanley [email protected] Myles [email protected] Godfrey [email protected] O’Hara [email protected] Calhoun [email protected] Miller [email protected]
















mailto:mike@chant








Minutes of APF Study Group, Berlin, September 2004 Page 1 J.P. Edney, Nokia


Minutes of 802.11 APF Study Group

Berlin, Germany


Author: J.P. Edney InTalk2k Ltd. e-mail: [email protected]

Tuesday 14th Sept., 16:00

1. Call to Order Dorothy Stanley took the chair

Jon Edney acted as secretary

2. Review IEEE 802 and 802.11 Policies and Procedures The chair presented:

Rules on voting presented

Bylaws on patents and IP presented

Rules on inappropriate topics of discussion presented

3. Approve Agenda The proposed agenda was presented as per doc 11-04-1036-01-0apf-september-apf-agenda.ppt

Chair called for submissions: no submission are offered

Chair called for any additional items for the agenda: none are offered

Chair: Any objection to approving agenda: no objection raised.

Agenda is adopted

4. Approve Meeting Minutes from conference call Minutes of the conference call on 1st Sept which are in doc:

11-04-1013-00-0apf-apf-sg-teleconference-minutes-sept01.doc

Chair: Are there any objections to approve minutes? No objections raised

Minutes are approved.



5. Chair’s status Summary The study group was approved in July Plenary meeting.

A conference call was held on Sept 1st to discuss the process for going forward and other topics.

Next steps are to consider the issue of PAR and 5 criteria and discuss ultimate processes.

Recap of discussion on conference call: On the call 4 options were discussed regarding how to proceed:

1. Create a PAR & 5 criteria document to move towards a task group. Several people on the call felt that the nature of the work did not require a task group

2. Use the TGm process as a way to incorporate additional text into the standard. Work from the study group would be submitted to TGm for inclusion in letter ballot. The TGm ballot schedule requires that we have material to submit within 6 months. The idea would be to form a WG chair’s Ad-Hoc group with intent to feed into TGm

3. Creation of an unofficial ad-hoc group within TGm. This was not supported on the teleconference

4. Submission of an interpretation request into TGm. It was felt that the overhead of this process was more than was needed

During the conf call a straw poll was held to determine whether the formation of a task group is necessary to accomplish the goals of the group. This indicated low support for a task group but support for option (2).

6. Discussion - PAR & 5 Criteria/Options KEY:

‘FL’: Comment from the floor

‘CH’ Comment from the chair

‘CHM’ Comment from the chair of TGm (not necessarily on behalf of TGm)

There was a discussion on what is likely to be included in the text generated by the group.

FL: This activity was started with intent to feed into CAPWAP activity wasn’t it?

CH: This was started because of request from a number of groups including CAPWAP. Output is not intended to feed back only to CAPWAP but to the .11 standard that would be available to CAPWAP

FL: Assuming it is of value to CAPWAP how does it fit into their schedule? Will it be relevant or not?

CH: Yes it can be relevant but we need to make an assumption about their schedule. I would expect that their next phase takes 6 – 12 months. What we produce should be available in some form in that timeframe

FL: Yes it needs to be timely in order to be useful.

FL: Is the text mainly expected to go towards clause 5 [of the 802.11 standard]

CH: Clause 5, clause 7 and perhaps an appendix.

FL: On the process options: I don’t see anything that talks about options that don’t produce something for formal standards inclusion. Is it necessary for CAPWAP that what we do goes into an IEEE official document?



CH: CAPWAP will go forward regardless of what we do. The decision to form this group had a number of inputs not just CAPWAP. It was felt this was a good thing to do. Obviously if we conclude in timely manner it is more useful to CAPWAP. The question is, when creating text: where’s the right place to put it? General consensus on the conf call was that we didn’t want to create a document that had to track in parallel to the standard. So the standard is the right place for it.

FL: To which internal task groups is it of interest?

CH: Those dealing with definitions of BSS and ESS e.g. TGr

FL: My opinion is that the text produced should be entirely informative

CH: yes but you can’t rule out normative text as a possibility.

FL: So we are not documenting WDS?

CH: Well it’s for the group to decide but…

FL: but are protocol definitions in scope?

FL: presumably not because this would be beyond the scope of clarification and correction.

CH: To the extent that WDS is specified in the standard but not clearly defined it is in scope

FL: Yes but there is so little there that it is more that clarification.

FL: We can’t decide what is in scope until we hear what is the question being asked

CH: The question would go back to TGm – what scope of changes are possible?

CHM: Our scope is to roll up any changes that are approved by the end of this year and allow minor additional functionality. I don’t see how anything to do with WDS has anything to do with this group

CH: If we have an ad-hoc group to create submission we need to do work to create content in a timely way – something solid in the January timeframe so it can go to TGm ideally before the end of the March meeting.

FL: Would changes to the MIB be in scope?

CHM: Changes to the MIB are normative changes. In discussion on forming the study group an assumption was that the work in this group is information and not normative. However, the problem with trying to create a task group is that it has to generate new functionality and this is not an aim of this group. The other possibility of a recommended practice is not applicable - it should tell you how to configure the existing standard for some particular application. A guide is help on how to use a standard and that doesn’t fit either. So I can’t see how a task group is viable here.

CH: Yes a number of people felt the same and that’s why we looked for alternatives

CH: regarding the MIB question it seems like the existing TGm process could be used separately from this group?

FL: Yes but what counts as a small change? I think a number of MIB things should be standardized but might be too much for TGm

FL: The TGm PAR includes the words “as well as to define behavior” so doing WDS might actually be in scope.

FL: Can you discuss more what led to the options 2, 3, 4 and what are the relative merits?

CH:

re: (3) Creation of an unofficial ad-hoc group within TGm.

This was discussed but viewed as less desirable because TGm does not exist to solve problems – only to consider direct requests



re: (4) Creation of an interpretation request into TGm.

Thinking was whether we could phrase the case as an interpretation request which would put the work on TGm

CHM: Regarding interpretation requests, these are to clarify the meaning of the standard. Usually the response of TGm is to interpret but not modify the standard. “The standard is what it says” but TGm may forward the issue to other task groups for possible future change – the change may not be done in TGm.

CH: yes so it boils down to someone doing work – so we might as well do that directly. That’s what brought us to bullet (2).

7. Straw Poll CH: I propose a straw poll to asses the thinking of the group over the options.

“The APF study group should recommend formation of Ad-Hoc Group by WG Chair to create a submission to TGm. The submission will provide the text describing AP functionality.”

CH: Any suggested changes? none offerred.

Vote taken.

Result: 22:2:3

CH: Would those who voted no like to explain why?

FL: I prefer the task group approach because if this is important then it should have the full review of the group

CH: But the whole group will review TGm document

FL: But it won’t get the EXCOM and NESCOM review that would occur in creating a new task group.

CH: we could create a PAR and if it failed to be approved we could still come back to the proposed approach.

FL: It would depend on the reasons for rejection of the PAR

CH: By going this route we acknowledge that the creation of a task group is for new functionality which is not what we are trying to do. There would be trouble getting a PAR approved

FL: Is there any process to determine what comes out of an ad-hoc group? For a task group there is clear process.

CH: The process would be that the ad-hoc group creates a submission and passes to TGm.

FL: But then the WG has no review until it comes out of TGm.

FL: Ad-Hoc is under jurisdiction of the WG chair who could require a WG review.

FL: I voted no because I was uncomfortable with the freedom of an ad-hoc group. Waiting until the TGm process may be too late. Voters do not have chance to give feedback until the TGm letter ballot.

CH: maybe you could have a working group letter ballot on the submission

FL: But the process is too ill defined. We need to define scope and process.

CH: Scope is proposed as follows:



• Scope of Submission -AP Functionality Description

– Better Description of data flow in an AP – similar to figure in Clause 7.1.3.1.

– Clarification between AP function & AP device

• Enumerating AP abstract functional blocks within an AP device

• Description of AP functions

– Details on integration function in an AP

– Address questions about Distribution System and its associated services (portal, DSS, etc.)

– Intent – informative descriptions be provided

– Any normative functionality must fall within TGm “minor new functionality to address technical corrections”, and “define AP behavior that is hinted at in the existing standard but not defined.”

FL: Its OK to be more informal with informative text but once you start talking about protocol and normative changes you need proper process.

FL: But the last clause in the TGm PAR opens up the scope a lot. We should restrict the scope to AP functionality. For example this could include WDS.

CH: Could we have an extra line saying WDS is not in scope? Or we could leave it up to the Ad-Hoc group.

FL: Is the ad-hoc group subject to any procedure?

CH: I expect it would operate under study group rules.

FL: Is membership open?

CH: Yes the intent is for it to be open

CH: What is view on WDS

FL: Some people say exclude it.

CH: So we add “WDS definition is not in scope”

8. Process CH: Let’s talk about process.

CH: proposal:

1. form ad hoc group

2. create submission

3. Take submission to TGm no later than March 2005

4. Full WG review as part of TGm process

FL: In bullet 3– will it have full WG review prior to submission to TGM?

CH: we have to discuss that. If we have full review prior to (4) then it pushes out the time windows. Being a submission it would be on the server for review.



CH: We have to go to the WG and justify why we are deciding not to move to task group.

CH: Creates a slide to summarize the rationale.

• PAR & 5 criteria approval requires

– Introduction of new functionality

– Evidence of expanded market potential

– Unique identity (different from what currently exists or is being developed)

• Main objective of APF is description of existing AP functions, NOT definition of new ones

– Aligns with TGm purpose

FL: When would this be presented to the WG

CH: Options are Wed or Friday. I would say tomorrow is best.

Discussion on proposed scope in 1036r1 slide 9.

Straw poll “Who would like the WDS definition to be not in scope”

Result: 11:0:6

FL: Will it be late? If subject to task group approval and so on?

CH: In this process TGm creates a draft and goes to WG letter ballot in March 05. The intent is to have this text in that draft. Submission has to be accepted within TGm. What is the approval process in TGm?

CHM: Generally it is like any other group– make a submission and presentation then propose a motion.

FL: It could also be modified the TGm by normal processes

Proposed process in 1036r1 Slide 10:

• Ad-Hoc group operates under SG rules

• Ad-Hoc group formed

• Create submission, Take submission to TGm

– No later than March 05 meeting

– Subject to normal TGm review process

• Full WG review as part of TGm draft review

9. Motions Motion: “On behalf of the APF SG, move to request formation of an Ad-Hoc Group by WG Chair to create a submission to TGm. The submission will provide the text for the AP Functionality Description listed in 04/1036r1.”

Moved: Haixiang He

Second: Clint Chapman



Call for discussion: none

Vote

Motion passes: 17:0:6

10. Conclusion of session CH: No meeting 8 – 10 tomorrow. If formation is approved on Wed then Thursday slot used to discuss creation of a submission. Any objections: None.

CH: Are there any submissions: none

CH: Any objection to recess until Thursday at 1:30 : none

CH: We are recessed.

Thursday 16th Sept., 16:00

11. Call to Order Reminder for on-line attendance

CH: I propose to add an agenda item to report on mid-week plenary.

CH: Any objection to add to agenda? no objection

Doc 1036r2 now has agenda.

12. Report of mid-week plenary The motion, as approved on Tuesday, was submitted to plenary and passed (after modification to remove WDS restriction.). The effect of the motion is that the WG agrees to the use of Tgm for submitting changes rather than going for full task group.

Another impact is that an APF task group will be formed.

CH: If anyone is interested in becoming chair of the Ad-Hoc group they state this.

Dorothy Stanley indicated interest.

CH: We have signed up for aggressive schedule. Tgm first letter ballot is at the end of the March meeting. Goal for Ad-hoc group work is that initial submission be available in November and that the Nov meeting be used to review and refine those submissions. Also try to get a session with Tgm to discuss during November.

CH: Slide 16 breaks down the pieces that are identified:

1. Better Description of data flow in an AP – similar to figure 22 in IEEE 802.11i draft 10, Clause 7.1.3.1.

2. Clarification between AP function & AP device

a. Enumerating AP abstract functional blocks within an AP device



b. Description of AP functions

3. Details on integration function in an AP

4. Address questions about Distribution System and its associated services (portal, DSS, etc.)

CH: We probably should schedule some conference calls between now and November. The following dates are proposed: Oct 13th, Nov 3rd.

FL: When is IETF?

CH: Nov 8th – 12th

CH: Any objection to scheduling calls on these days? none

CH: Meetings will be announced at Friday plenary for time of 12 noon EST

CH: These are also some people not present at the meeting who want to be involved.

CH: Call for participation by members in the room.

FL: There have been some submission as part of creating this group. Could we use some of those as well?

CH: Absolutely there is a list of these docs in doc 1013 (notes from the conf call)

CH: Call for volunteers for bullet 1 (Slide 16)

FL: There is already text in the standards for all of these issues. Are we looking to replace what is there?

CH: The intent is to clarify – that requires replacement on text then we can do that.

CH: Second bullet item – call for volunteers.

FL: Jon Edney volunteers

CH: Darwin Enger has also indicated interest in this area.

CH: How about the third bullet item?

FL: Isn’t integration and portal closely linked?

CH: Unclear

FL: Seems to me those bottom two bullets should be combined. Does anyone agree?

FL: Yes I think so.

CH: OK we will combine it here and it can be split again later if the work shows this is necessary.

FK: Mike Morton volunteers for combined bullet (3 & 4)

CH: The next step should be to reiterate the need for volunteers in the plenary and on the reflector

FL: Nehru Bhandaru volunteers to help on bullet (3 & 4)

FL: It’s possible that the first groups work will depend on the results of the second two groups

CH: Please contact other people to see who is interested to participate.

FL: Was there any prior debate whether it was acceptable to change the functions? A lot of people have problems with the portals etc. One approach is to find a different way to describe the behavior

CH: What was approved was the functionality that was described in plenary. This says that changes are limited to scope of Tgm.

FL: In some sense the DS is just a concept – not a description.



FL: But this does change the architecture even if not the function

CH: It’s something we could look at as we move through the process.

FL: But this will be slow – we need to decide now

FL: If we were to change the description it would be to make it more like the conventional 802 model.

CH: For work on the last bullet does Mike Morton need direction on this?

CH: Intent is to help newcomers understand without disenfranchising the existing technical group.

Morton: That’s sufficient guidance.

13. Conclusion of Session CH: Call to contact Morton or Edney to participate in the effort.

CH: Plan of action is two conference calls. In the next meeting looks like 4 hours of meeting time.

CH: Call for other discussion : none

CH: Any object to adjourning: none

CH: Thanks to Jon Edney for acting as secretary.

Session is adjourned


Minutes of WNG SC September 2004 page 1 E. Hepworth, Siemens Roke Manor


Minutes of Wireless LAN Next Generation Standing Committee Meeting

Date: September 12th-17th, 2004

Contact: E Hepworth Siemens Roke Manor Old Salisbury Lane Romsey, SO51 0ZN Phone: +44 1794 833146 e-mail: [email protected]

Abstract Minutes of WNG SC meetings held during the IEEE 802.11 Interim meeting in Berlin, Germany from September 12th-17th, 2004. 1. Executive Summary:

1. Digital Video Broadcast – Wireless Home Network: summarizing some on-going work looking at the use of IEEE 802.11 technology to support DVB services in the home.

2. Security for Management Frames Discussion – reviewing current proposed PAR for further discussion in San Antonio.

3. IEEE 1588 over IEEE 802.11b: outlining work in IEEE 1588 to support clock synchronization over WLAN.

4. Discussion as to whether IEEE 802.11 should develop a technical architecture.

Morning Session Monday 08:00-10:00

2. Logistics WNG Meeting called to order by TK Tan (Philips) at 08:00. The objectives of the session were reviewed. The IEEE 802 & IEEE 802.11 Policies and Rules were reviewed. Patents and By-laws read out by TK Tan, together with licensing terms and associated conditions. There was a single session on Wednesday 15th September 2004. The agenda was reviewed (1044r1), and the IEEE 1588 over IEEE 802.11 item was added. The minutes from the Portland 2004 meeting (811r0) were reviewed. There was no discussion on the minutes and no objection to approve as presented. Move to accept minutes: TK Tan, seconded: Richard Paine, minutes approved. There were no industry updates at this meeting.



3. DVB – WHN Digital Video Broadcast – Wireless Home Network: 1082r0, Stephen McCann This presentation was for information to update the IEEE 802.11 community about some work being carried out by a European DVB project looking at the use of IEEE 802.11b in the home to support distribution of DVB services. The project has drafted a set of commercial requirements intended to allow the production of a DVB/ETSI standard to enable carriage of DVB services via IEEE 802.11. Peter Ecclesine: is this group analogous to cable labs, or is it a standalone standards group, or part of ETSI? Stephen: I think this is a separate group spun out of ETSI. Jan Kruys: you mentioned 802.11h as pertaining to interference mitigation issues in Europe. In Europe we have solved this problem by complying with CEPT radar regulations, but the problem still exists in the US. TK Tan: Does WNG SC need to respond to this group in any way; pursue a liaison or just encourage them to come and talk to us? Stephen: this presentation is only informational at the moment. When the commercial requirements are complete, they may invite 802.11 to review these requirements, and perhaps also the final solution. It’s too early for a liaison, but watch this space. Peter Ecclesine: looking at the URL in your presentation, it looks like this is a group rather like cable labs outside any standards body. 4. Security for Management Frames Discussion, Jesse Walker

A new Study Group to look at the issue of securing management frames will meet for the first time in San Antonio in November. However, it is useful to illicit comments this week on a proposed PAR to have something more concrete to discuss at the first meeting.

The draft PAR is document 1048r0 on the server.

Peter Ecclesine: talking to Lee Armstrong, the IEEE SA is insisting that the only PAR form that should be used is the form on the online web page. Need to make sure your document aligns with what they require.

Stephen McCann: there is an activity in progress within the Chairs group to produce a suitable template, and this should be available in November. The WIEN and WNM Study Groups both have a suitable version of the PAR form based on the online form that could be reused here.

Jon Edney: comment on the scope statement, one of the things I’ve noticed is that there is a lot of pressure on study groups to make the scope as broad as possible. We need to avoid this within this group, otherwise you might find any task group becomes the place where any security problems are brought.

Jesse: I share your concerns.

Jan Kruys: is it possible to do this work without considering security policies that users might have? In some cases, we’re talking about an access network providing service to legal entities – who is responsible for which parts of the problem, and who will delegate what to whom in order to fix this?

Peter Ecclesine: is this in scope, are we providing apparatus?



Jan Kruys: not up to us to define the security policies, but how do we ensure that what we will a future proof solution that does the job.

Richard Paine: I think that we probably need to consider within WNG some overall architecture; we don’t currently have a picture of how everything fits together. With regard to the scope statement, I would remove the “but this is not required for project completion.” I don’t think this belongs in the scope statement. Peter Ecclesine: not sure that I’m happy with the ambiguity in the second sentence.

Jesse: the intent of putting that in was that the first sentence takes three of the security claims made by 802.11i and says we’re going to extend these for selected management frames. Second sentence takes fourth claim, and says we might do that too. I didn’t want to be in the position where someone could argue that we can’t take 802.11i and extend it to cover management frames because they can argue data confidentiality is out of scope.

Jan Kruys: the intent is clear; perhaps it is better to add data confidentiality to the first sentence and delete the second.

Jesse: OK, will make change for San Antonio.

Peter Ecclesine: suggest you modify purpose to say “defend and protect”

Jesse: and keep active attack?

General consensus it should just be “from attack”

Nancy Cam-Winget: Purpose should be management plane, not control plane.

Peter Ecclesine: in the additional explanatory notes, perhaps we should add notes about what 802.11i ended up as and its impacts on other authorized work.

Jesse: One item I want to point out is the related TG section. 802.11r includes security of re-association frames, and if this is done in 802.11r then this would be out of scope of our group, and we would reuse the TGr results.

Peter Ecclesine: assume the part about SeaMoby is boiler plate?

Jesse: That’s left over from WNM PAR.

Nancy: Need to at least make sure it is interoperable with TGr, but we want to avoid too much of a dependency. Also need to make it clear we are looking at management frames.

Peter Ecclesine: Want to point out that some of the addresses in the contact information are out of date.

Jesse – thanks for the discussion, I will prepare an updated document for San Antonio.

5. IEEE 1588 over IEEE 802.11b: 1080r0, Todor Cooklev Presentation provided an overview of another IEEE standard, IEEE 1588, that has been going on for quite some time looking at clock synchronization, and is now working on how to run this protocol over wireless networks. This protocol has mainly industrial applications. IEEE 1588 supports the sub-microsecond synchronization of real-time clocks, and work here is expected to lead to a supplement to 1588 defining how it can be implemented over wireless networks.



After that, they may move on to look at implementation over heterogeneous networks, but first stage will be over IEEE 802.11b. Guido R Hertz: in your tests you were measuring two cards that were very close together with no interference. Would your approach still work in environments with high interference? Todor: yes, I still believe these results are applicable. We have ignored interference for now, and in a typical industrial environment there will be hundreds of these nodes that will be connected, and we still think this approach will work. Guido R Hertz: Have you got some analytical results or calculations giving an upper bound on the number of nodes that can be synchronized in this way? Todor: no results yet, but it is something we need to do. 6. Discussion on IEEE 802.11 Technical Architecture, Richard Paine Richard Paine: One of the things we seem be struggling with is the cacophony of things going on, and I think we need to make some recommendations as the WNG SC to the CAC as to what sort of architectural issues there might be associated with the TGs and to identify problem areas that might arise from all these different activities. I believe it is up to the leadership to make decisions on architecture, but we need technical input from WNG as to what these issues and problem areas are going to be. We seem to be losing the big picture in 802.11 because we are too fragmented. Peter Ecclesine: what we really need is a wireless LLC. We are now building systems with many stations and expressly an ESS, we’re fleshing out structure and hierarchy, networks that fall apart and come back together, all things beyond just sending and receiving packets. We have to face the fact that 802 itself does not actually have an architecture for the things we’re doing. It is hard to find a single unifying point of view, we’re looking at scenarios beyond those originally envisaged for IEEE 802.11 technology, extending STA to STA communications to much more complex situations. Who would produce such an architecture that could capture all this? It would be difficult to get the engineering effort to develop this, because there is much more need for those people to work on the technical problems we have accepted. Floor: I think what Richard is suggesting is that WNG should recommend a technical architecture SG to make some recommendations to CAC. Peter: fine, as long as it only lasts 6 months and doesn’t go on for 18! TK Tan: It has been raised at previous meetings the fragile architecture of IEEE802.11. WNG provides an incubator for new ideas, architectural considerations can be handled in other ways, for example in a TAG. Richard: this issue has been tackled before but with limited success, we still have no formal architecture. The reason to discuss it here is that it relates to what WNG SC is tasked to do. Need to make sure WNG SC incubates the right stuff. Peter Ecclesine: don’t agree. The reason 802.11 is successful is because the technology works and is cheap. We don’t want to make the solution more complicated. And I don’t think we can pick a point of view that would encompass all possible uses of 802.11. Richard: but we could highlight the technical issues.



Peter Ecclesine: things like manageability, security, QoS, yes we could. Floor: as I listen to the discussion, it seems more like we need a framework to build on, not that excludes or limits development, but something that can grow to accommodate the expanding scope. Richard: agree Peter Ecclesine: success of this technology is the opportunistic ability to deliver value in license exempt bands. There is no single definition of that environment. Richard: unless we get some handle on what we do with 802.11 we'll be obsolete. Floor: I am confused what going on, this is an expanding universe, and we need some kind of structure so we can work out how things slot together and where the gaps are. Think this would be a worthwhile effort, but also hugely draining in effort to build it in first place and to maintain it. Jim Harford: It is difficult to have a common architecture when the technology is being used in so many different ways. Richard: IETF was very successful in the early days, technology was simple, fast and demonstrable. IETF has reached overload, having so many people involved (and also no L2 considerations) has got them into trouble. Now IEEE 802.11 is in same sort of position and at critical crossroads. Peter Ecclesine: a complementary view, as long as the technology and the solutions built out of it are manageable, the technology will keep going. Guido R Hertz: technology is also being widely used in the home using non-standard ways of hooing them together. As long as technology remains easy to use and is cheap, it will continue its success. The market will decide. Richard: to summarize, perhaps it is not a good idea to have a technical contribution out of WNG as a suggestion for a framework or an architecture. Stephen: Two things, I think there is a lot of background material looking at such architecture, e.g. IST BRAIN and MIND, Hiperlan/2 and initiatives in Japan. Regarding the general discussion, perhaps this should be moved somewhere else, e.g. the chair’s meeting, to think of ways forward with this issue. Richard: I was involved in Hiperlan/2, and actually I agree that it would be too complicated to develop a similar thing for IEEE 802.11. Example framework makes much more sense; in some way describing what 802.11 structurally is all about. Reason I'm here is because I think WNG as an incubator that could be a place to provide technical input for a framework. However, there doesn’t seem to be much support for this. TK Tan: Suggest we bring this up with the CAC for a high-level discussion, where we can have input from all chairs, and then perhaps discuss it again within WNG. Haixiang He: this effort looks useful, but it would be useful to have more information so others can provide help. Maybe a few slides or some documents? Richard – OK. TK Tan: as there are no further topics on the agenda today, I would like to adjourn. Motion to adjourn session, no objections.



Session adjourned.