Nov, 2005
doc.: IEEE 802.11-05/1136r0
IEEE P802.11
Wireless LANs
Approved Minutes of the IEEE P802.11 Full Working Group
Date: 2005-11-13
Author(s):
Name
Tim Godfrey
Company
Link-7
Address
Phone
+1-913-664-2544
email
t.godfrey@link-7.com
Abstract
Minutes of the 802.11 full working group.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Minutes
page 1
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
Opening Plenary: Monday, November 14, 2005
1.1.
Introduction
1.1.1. Meeting called to order by Stuart J. Kerry at 13:30.
1.1.2. The agenda of the 94th session of 802.11 is in doc: IEEE 11-05-917r1.
1.1.3. Secretary – Tim Godfrey
1.1.4. Officers and Chairs of 802.11:
IEEE 802.11 WORKING GROUP OFFICERS
Name
Position
Work Phone
eMail
Stuart J. Kerry
IEEE 802.11 WG Chair
+1 (408) 474-7356
stuart@ok-brit.com
+1 (321) 725-1520 x204
apetrick@widefi.com
+1 (973) 236-6915
hworstell@research.att.com
+1 (913) 664-2544
tgodfrey@link-7.com
+1 (512) 602-2454
terry.cole@amd.com
+1 (650) 829-2618
simon@devicescape.com
+1 (215) 340-2226
nancivogtli@concrete-logic.com
Philips Semiconductors, Inc.,
1109 McKay Drive, M/S 48A SJ,
San Jose, CA 95131-1706, USA
Fax:+1 (408) 474-5343
Al Petrick
WG Vice-Chair / Treasurer
Policies & Treasury
Harry R. Worstell
WG Vice-Chair
Attendance, Ballots, Documentation & Voting
Tim Godfrey
WG Secretary
Minutes & Reports
Terry Cole
WG Technical Editor
Standard & Amendment(s) Coordination
Simon Barber
WG Co-Technical Editor
Standard & Amendment(s) Coordination
Nanci Vogtli
WG Publicity
Communications
Teik-Kheong "TK" Tan
WNG SC Chair
+1 (408) 474-5193
tktan@ieee.org
Richard H. Paine
TGk Chair
+1 (206) 854-8199
richard.h.paine@boeing.com
Bob O'Hara
TGm Chair
+1 (408) 853-5513
boohara@cisco.com
Assigned Numbers Authority
Bruce P. Kraemer
TGn Chair
+1 (321) 327-6704
bruce.kraemer@conexant.com
Sheung Li
TGn Vice-Chair
+1 (408) 773-5295
sheung@atheros.com
Lee Armstrong
TGp Chair
+1 (617) 244-9203
LRA@tiac.net
Clint Chaplin
TGr Chair
+1 (408) 528-2766
cchaplin@sj.symbol.com
donald.eastlake@motorola.com
Donald E. Eastlake 3rd
TGs Chair
+1 (508) 786-7554
Charles R. Wright
TGT Chair
+1 (978) 268-9202
charles_wright@azimuthsystems.com
Stephen McCann
TGu Chair
+44 (1794) 833341
stephen.mccann@roke.co.uk
Pat R. Calhoun
TGv Chair
+1 (408) 853-5269
pcalhoun@cisco.com
Jesse Walker
TGw Chair and ISO JTC1-SC6 AHC Chair
+1 (503) 712-1849
jesse.walker@intel.com
Peter Ecclesine
CBP SG Chair
+1 (408) 527-0815
petere@cisco.com
Minutes
page 2
Tim Godfrey, Link-7
Nov, 2005
1.2.
doc.: IEEE 802.11-05/1136r0
Approval of the Agenda
1.2.1. Stuart J. Kerry reviews the agenda for the group
1.2.2. Any modifications or new items for the agenda?
1.2.2.1.
None
1.2.3. The agenda is approved with Unanimous consent.
1.3.
Approval of Minutes
1.3.1. 802.11 minutes from Sept 2005.
1.3.2. Are there any matters arising from the minutes?
1.3.2.1.
None
1.3.3. The minute are approved with Unanimous consent
1.4.
Announcements
1.4.1. The courtesy notices are reviewed for the body.
1.4.2. Audio and video recording is prohibited by our procedures. Still cameras
require express permission from the WG chair.
1.4.3. Members who are attending for the first time: 42
1.4.4. There are 325 people in the room
1.5.
Financial report
1.5.1. Al Petrick presents the Joint Wireless groups treasury report in doc
1152r0.
1.5.2. From Augusts to November, the balance is $101K
1.5.3. There are reserves of $22K for legal fees (50% of fees per ExCom), $20K
for server replacement, $14K for Hawaii meeting, and $133K for 2006
meeting expense
1.5.4. We had net income of $381K and $287 expense, with a net gain of $94K
for Garden Grove meeting.
1.5.5. January meeting registration is $550 early. $750 after Dec 9th. Expect a
loss of $13K.
1.5.6.
1.6.
Announcements
1.6.1. Tutorials this week:
1.6.1.1.
1.6.1.2.
1.6.1.3.
1.6.1.4.
Systems concept for 1Gbit and beyond. Monday 6:30
Licensed devices in TV bands Monday 8:30
Something from Bob Grow
Discussion with 802 vice chair.
1.6.2. Stuart J. Kerry notes that members should be careful of their property.
There have been burglars coming off the street and stealing computers.
1.7.
Review of Policies and Procedures
1.7.1. Al Petrick presents document 11-05-781r3 to the body.
1.7.2. Review of working group officers and duties for all wireless working
groups. Members are encouraged to wear their voting tokens. Voting
rights are also indicated by a printed indication on the badge.
Minutes
page 3
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
1.7.3. Review of operating policies and procedures, registration, payment of
fees. 802.11 P&P is in 11-05-456r0, which is posted on the web site.
Roberts Rules are revision 10 (Gold Book)
1.7.4. Review of registration requirements
1.7.5. Review of rules against photographs, tape recording, and media briefings.
1.7.6. Review of procedures for server access and reflector subscriptions.
1.7.7. Review of voting rights and process for obtaining voting rights, and signing
up for email and reflectors. The email confidentiality disclaimer was
presented.
1.7.8. Review of process and requirements for gaining and keeping voting rights.
1.7.9. Membership representation and anti-trust laws are reviewed.
1.7.10.
Attendance recording procedures are reviewed
1.7.10.1.
There is a sign in sheet that must be signed once per day, from 7:30 to 17:30
each day.
1.7.10.2.
Attendance credit pools is based on all sessions, but evening sessions
(tutorial) are optional.
1.7.10.3.
There is no tutorial Tuesday – unless one is scheduled, there is no optional
credit.
1.7.11.
Al Petrick reads the following statements to the body:
ANTI-TRUST STATEMENT
Each Member acknowledges that the Members are committed to fostering
competition in the development of new products and services. The
Members further acknowledge that they or their employers may compete
with one another in various lines of business and that it is therefore
imperative that they act in a manner which does not violate any applicable
antitrust laws and regulations.
Without limiting the generality of the foregoing, the Members acknowledge
that the Members will not, in meetings or informal gatherings associated
therewith, discuss issues relating to product pricing, methods or channels
of product distribution, any division of markets, or allocation of customers
or any other topic which should not be discussed among competitors in the
context of standards meetings or informal gatherings associated therewith.
Accordingly, each individual Member sponsor hereby assumes the
responsibility to behave in an appropriate manner in this respect and to
limit their discussions to subjects that relate to the purposes of the IEEE
Standards making process and adhere to IEEE policies and procedures,
whether or not such discussions take place during formal meetings or
informal gatherings associated with IEEE standards meetings.
Minutes
page 4
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
July 2005
doc.: IEEE 802.11-05/0781r0
Inappropriate Topics for
IEEE WG Meetings
• Don’t discuss licensing terms or conditions
• Don’t discuss product pricing, territorial restrictions or market share
• Don’t discuss ongoing litigation or threatened litigation
• Don’t be silent if inappropriate topics are discussed… do formally object.
If you have questions,
contact the IEEE Patent Committee Administrator
at patcom@ieee.org
Approved by IEEE-SA Standards Board – December 2002
Submission
Slide 16
Stuart J. Kerry,Philips Semiconductors
1.7.12.
1.7.13.
Al Petrick reads the following text to the body regarding IEEE
patent policy:
1.7.13.1.
There were changes made to the patent policy this morning in the 802
ExCom, however we do not have access to those updates at this time.
July 2005
doc.: IEEE 802.11-05/0781r0
IEEE-SA Standards Board Bylaws on Patents
in Standards
6. Patents
IEEE standards may include the known use of essential patents, and patent applications, provided the IEEE receives assurance from
the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the
standard. This assurance shall be provided without coercion and prior to approval of the standard (or reaffirmation when a patent
becomes known after initial approval of the standard). This assurance shall be a letter that is in the form of either
a) A general disclaimer to the effect that the patentee will not enforce any of its present or future patent(s) whose use would be
required to implement the proposed IEEE standard against any person or entity using the patent(s) to comply with the standard or
b) A statement that a license will be made available without compensation or under reasonable rates, with reasonable terms and
conditions that are demonstrably free of any unfair discrimination
This assurance shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal and is
irrevocable during that period.
Approved by IEEE-SA Standards Board –, March 2003, May 2005
1.7.14.
1.7.15.
1.7.16.
Submission
Minutes
Stuart J. Kerry,Philips Semiconductors
Review of copyright status of submissions
Review of standards compliance disclaimers
1.7.16.1.
1.7.17.
Slide 17
Claims of compliance to unapproved drafts are not allowed
Review of meeting etiquette.
page 5
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
1.7.18.
Al Petrick asks if there are any questions about patent policy.
1.7.18.1.
None.
1.7.18.2.
Stuart J. Kerry asks again for questions and insures that everyone is aware
of the polices and procedures.
1.8.
IEEE SA Letters of Assurance
1.8.1. New LOA from Apple Computer for 802.11s
1.8.2. New LOA from Autocell for 802.11k and 802.11p
1.8.3. Any other LOAs?
1.8.3.1.
1.9.
None
Interim Meetings
1.9.1. January 2006 – Hilton Waikoloa Village, Big Island, Hawaii.
1.9.2. March 5-10, 2006 – Denver Hyatt Convention
1.9.3. May 14-19, Jacksonville FL
1.9.4. July 16, San Diego
1.9.5. September. Undecided
1.9.5.1.
Brisbane, Melbourne, Kuala Lumpur, Thailand, India.
1.9.5.2.
Preference between Melbourne and India? Straw Poll – Melbourne is
majority.
1.9.6. November Dallas
1.9.7. January 2007. Hilton London Metropol.
1.10. ExCom report
1.10.1.
Introduction of Mike Kipness, new IEEE staff liaison.
1.10.2.
Review of MyBallot/MyProject status
1.10.3.
ProCom investigation of undue influence or affiliation. Stuart will
bring more information from ExCom later this week.
1.10.4.
European patent office wants access to 802.11 documents.
1.10.5.
Approval of legal bill sharing between IEEE and Wireless groups for
the Ideal Software legal case.
1.10.6.
Attendance recording software and documentation management –
we believe that it is needed for all of 802, and 802 should provide the
funding.
1.10.7.
802 P&P revision continues.
1.10.8.
Appeal in 802.20 will be heard in March 2006.
1.10.9.
All 802 officers are up for election in March 2006.
1.11. Voter Summary
1.11.1.
Harry Worstell reviews the voter status.
1.11.2.
We have 513 voting members, 55 potential members, there are 66
nearly voters, and 281 aspirants.
1.11.3.
You have to attend 12 out of 16 for 75%.
1.11.4.
We have 1216 documents for this year.
1.11.5.
Attendance sign in is 7:30 to 17:30
1.12. WG Policies and Procedures
Minutes
page 6
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
1.12.1.
Currently in document 05/456r0, on the server and web site.
1.13. Timeline Planning and publicity – Nanci Vogtli
1.13.1.
The timeline chart from the web site has not been changed since
the last meeting. The format has been improved to provide more
information for tracking the overall history of each project.
1.13.1.1.
Stuart J. Kerry shows the changes. There are links to ballot results, links to
current open PARs, TG status. Approved standards remain present and show all
actual dates of the progress, and link to the actual standard document. There are
links to the calendars of ExCom and IEEE SA.
1.13.2.
The Publicity committee will generate a press release for TGk and
TGp.
1.13.3.
Discussion
1.13.3.1.
Make the timeline available as a downloadable file.
1.14. WNG Update – Stephen McCann
1.14.1.
WNG agenda in 1131r1. Will meet today at 4:00 to have two papers
of future of 802.11 in spacecraft. Any further presentations?
1.15. TGe awards
1.15.1.
Stuart J. Kerry states that TGe was published on November 11,
2005.
1.15.2.
John Fakatselis may be here some time this week, but is not here
now.
1.15.3.
Awards are given to John Fakatselis, Srini Kandala, Duncan
Kitchin, Matthew Sherman.
1.15.4.
Contributor certificates go to Keith Amman, Mathilde Benveniste, Greg
Chesson, Sung Yun Choi, Wim Diepstraten, Michael Fischer, Jin Meng Ho,
David Hunter, John Kowalski, Thomas Kuehnel, Bob Miller, Al Petrick, Floyd
Simpson, Amjad Soomro, Menzo Wentink, Harry Worstell.
1.16. TGk – Richard Paine
1.16.1.
Comments from LB78 are in 1045. Results are not in yet. Will
process comments this week.
1.17. TGm – Bob O’Hara
1.17.1.
The 802.11m revision is in sponsor ballot. Concludes on Sunday.
Voters are still needed. No updates for ANA
1.18. TGn – Sheung Li for Bruce Kraemer
1.18.1.
The Joint Proposal group will present status updates. Will have
voting on presentations
1.19. TGp – Lee Armstrong
1.19.1.
Will review current draft and comments, and possibly submit for
letter ballot.
1.20. TGr – Clint Chaplin
1.20.1.
The agenda is 1111r1. A new session has been added Tuesday at
13:30. Goal is to issue LB.
1.21. TGs – Donald Eastlake
Minutes
page 7
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
1.21.1.
In proposal downselection. There are 3 remaining proposals.
Agenda in doc1035r4
1.22. TGT – Charles Wright
1.22.1.
Will hear proposals, possibility accepting into draft. Current draft
version 0.4.
1.23. TGu – Stephen McCann
1.23.1.
Agenda in 1060r1, will have pre-proposal presentations, finalize
downselection process, and issue formal CFP this week. Will have joint
meetings.
1.24. TGv – Pat Calhoun
1.24.1.
Will have motions to accept submissions into base draft. Process is
in 05/719r2. Proposers are responsible for merging into draft.
1.25. TGw – Jesse Walker
1.25.1.
Agenda is in 1150r0. Goals are to hear proposals. Three proposers
have written text so far. There will be a presentation regarding a gap
between 11i and 11e.
1.26. JTC1 Update:
1.26.1.
Agenda is in 1149. Goals are to identify volunteers to work on
documentation to support our position on the WAPI fast track ballots.
Have developed comments on the ballot, which will be provided to
national bodies voting on fast track. Working on becoming registration
authority for constants in 802.11 standard. Working on responses to
contradictions between WAPI and 802.11 standards. Will develop
outreach letter.
1.27. CBP SG – Peter E
1.27.1.
Will meet twice this week, to respond to issues with PAR and 5C.
Currently the PAR and 5C are on ExCom agenda and will be considered
Friday. 802.11 will re-confirm the PAR and 5C in this meeting.
1.28. Editor Status Report – Simon Barber
1.28.1.
Document 804r3
1.28.2.
Will align plans for editing with overall timeline.
1.28.3.
Will have editors meeting 7am Tuesday.
1.28.4.
IEEE has prepared a new special edition CD for purchase.
1.28.5.
Internationalization – 802.11-2003, 802.11g, and 802.11h. 802.11i
has the WAPI fast track ballot issue. Balloting in process. There have
been 9 filed contradiction submissions indicating contradictions with
WAPI, and indicating that WAPI is not appropriate for fast track balloting.
However ISO proceeded with ballot anyway.
1.28.5.1.
802.11e and 802.11j are approved for international submission, but no action
planned. 802.11ma has a plan for international submission.
1.28.5.2.
The 802.11e draft D13 is on the CD.
1.29. IEEE CD
Minutes
page 8
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
1.29.1.
Once a year, 802 provides a CD to attendees with current
standards. The approved 802.11e is on the CD.
1.30. Joint Interchange / Other business
1.30.1.
Charles Wright reports that he was contacted by the FAA, who
wants to write a Technical Standard Order (TSO) for performance of
wireless LANs in aircraft. Asks the group how we can respond.
1.30.1.1.
Discussion
1.30.1.1.1.
This is effectively an interpretation request. Bob O’Hara normally
handles Interpretation Requests, but this was not received through
proper channels.
1.30.1.1.2.
Charles states that this is not really an interpretation request, in
the normal sense. The FAA wants help filling out a specification.
1.30.1.1.3.
Suggestion that there are many consultants who could help, but
this body does not officially perform such a function.
1.30.2.
Motion from CBP
1.30.2.1.
Move to re-confirm sending 11-05-0565r3 draft PAR and 11-05-0351r4 Five
Criteria draft to ExCom for approval.
1.30.2.1.1.
Moved Peter Ecclesine
1.30.2.1.2.
Second Larry Arnett
1.30.2.1.3.
Vote: Motion passes 129 : 0 : 23
1.31. Recess at 3:05pm
2.
Wednesday, November 16, 2005
2.1.
Opening
2.1.1. The meeting is called to order by Stuart J. Kerry at 10:30AM.
2.1.2. Agenda in doc 917r2
2.1.3. Stuart reviews the changes to the agenda since Monday.
2.1.4. Further modifications to the agenda?
2.1.4.1.
The CBP group accepted comments and modified the PAR and 5C and have
them on the server. Would like to have a discussion and motion in this session.
2.1.4.2.
Stuart calls attention to the removal of the joint meeting of TGu and TGv.
They will be separate sessions.
2.1.5. The modified agenda is approved with Unanimous consent.
2.2.
LOA update
2.2.1. Any new LOAs? None
2.3.
Announcements
2.3.1. There will be the usual Thursday evening CAC meeting.
2.3.2. Harry Worstell reminds the members to sign in. Missing a day will result in
under 75%.
2.3.3. Stuart reminds members to always wear their badge and watch for
suspicious people.
2.3.4. Awards for Sharp and Spectralink are given out to colleagues.
2.3.5. LB78 TGk letter ballot passed with a vote of 295 : 75 : 33, with a 78.4%
return ratio
2.3.6. There are 282 people in the room
Minutes
page 9
Tim Godfrey, Link-7
Nov, 2005
2.4.
doc.: IEEE 802.11-05/1136r0
Liaison Reports
2.4.1. 802.18 – Denis Kuahara
2.4.1.1.
2.4.1.2.
2.4.1.3.
Report in document 11-05-1201r0
Updating ITU M.1415, characteristics of RLANs for current 802.11 standards.
There are three other consultations described in 11-05-1201.
2.4.2. 802.19 – Sheung Li
2.4.2.1.
All new work requires a coexistence statement. 802.19 is developing a
standard process for coexistence analysis. 19-04-0022.
2.4.3. 802.22 – Peter Ecclesine
2.4.3.1.
802.22 for use of Digital TV bands has received 9 proposals and is hearing
them this week. There was a straw poll on the PAR for wireless microphones.
2.4.3.2.
Requests time on Friday to discuss their final action on that PAR.
2.4.4. 802 architecture - Roger Durand
2.4.4.1.
Document 05/1200r0
2.4.4.2.
Discussed 802.3 QoS capabilities, Power saving regulatory issues, Report
on 802 wireless architecture, and other presentations.
2.4.5. WiFi Alliance – Clint Chaplin
2.4.5.1.
2.4.5.2.
2.4.5.3.
There has not been a meeting since September
An update is on the server as 05/1208.
Next meeting in Phoenix in December.
2.4.6. JEDEC – no report
2.4.7. IETF – Dorothy Stanley
2.4.7.1.
Report in 05/1196r0
2.4.7.2.
Work on EAP method standardization at last IETF meeting. Will create a WG
to update EAP-TLS.
2.4.7.3.
IETF has requested 802.11 to review EAP Keying requirements and key
management extensions documents.
2.4.7.4.
Discussion
2.4.7.4.1.
Stuart asks about the liaison letters we sent – has there been
any response? None yet – Dorothy will check back with them.
2.4.8. JTC1-SC6 – Jesse Walker
2.4.8.1.
2.4.8.2.
2.4.8.3.
2.4.8.4.
2.4.8.5.
document minutes 1145
Position paper 05.967r9
Document 11-05-1205 contains comments on JTC1 documents.
There will be motions regarding these documents.
2.4.9. 3GPP – Sabine Demel
2.4.9.1.
2.4.10.
3GPP has received liaisons statements from TGu
TIA – Ariel
2.4.10.1.
Document 05/1162r1
2.4.10.2.
Broadband Task Group currently working to integrate public safety uses,
based on 802.11 in 4.9GHz. Need to standardize a 5Mhz channel mode, which
needs to be added to 802.11j
2.4.10.3.
Described potential use cases for this band.
2.4.10.4.
Discussion
2.4.10.4.1.
How are the differences between 802.11 and 802.16 being
reconciled? They are both proposed, but 802.11 seems to be most
appropriate
2.4.11.
Minutes
3GPP2 – Facim
page 10
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
2.4.11.1.
Sent a liaison to 3GPP2. There was no response yet
2.4.11.2.
The TGu requirements are being discussed, expect a reply by January or
March.
2.4.11.3.
3GPP2 has looked at WLAN as a black box. Will consider enhancements to
WLAN as a longer term issue.
2.4.11.4.
The document is 1142r0
2.4.12.
Wireless Ad Hoc – Tom Siep
2.4.12.1.
Document 1197r1
2.4.12.2.
This group is no longer an ad-hoc. It is not a part of 802.1. It is now part of an
EC Standing Committee. The group does not function to mandate a fixed common
architecture. It is meant to find common problems and identify directions toward
common solutions. It is a group for discussion of inter-WG topics, but doesn’t actually
do the work.
2.4.12.3.
If a topic of interest is identified, a group will be formed to consider forming a
Study Group.
2.4.12.4.
There were presentations on QoS and mesh networking.
2.4.12.5.
Considering a new name, to remove the word Architecture, and make a noncontroversial name.
2.5.
New Business
2.5.1. CBP PAR and 5C
2.5.1.1.
Peter Ecclesine presents document 05/565r4, the latest version of the CBP
PAR.
2.5.1.2.
The CBP SG accepted the suggested changes from 802.16. He reviews the
changes in yellow with the group.
2.5.1.3.
In document 05/351r5, the 5C document, additional changes that were made
are identified and presented.
2.5.1.4.
In document 1202r1, motions are presented.
2.5.1.5.
Move To submit draft CBP PAR 05/565r4 and Five Criteria Draft 05/351r5 to
ExCom and forward to NesCom.
2.5.1.5.1.
Moved Peter Ecclesine
2.5.1.5.2.
Second Garth Hilman
2.5.1.5.3.
Vote: Motion passes 108 : 1 : 11
2.5.2. 802 LMSC Policies and Procedures Straw Poll
2.5.2.1.
An email was sent out regarding the changes in 802 P&P. Changes to
bringing WG out of hibernation, changing SG lifetime to session to session, changes
to membership gaining and maintaining to 2 out of 3 plenaries.
2.5.2.2.
Straw poll on changing membership rules to 2 out of 3. 802.1, 3, 15, and 20
are against it?
2.5.2.3.
Discussion
2.5.2.3.1.
The document is other changes? Yes. The other document has
issues. We should be able to give more specific feedback than an overall
report on the whole package. This straw Poll is on one particular issue of
membership changes.
2.5.2.3.2.
There is no intention of changing the substitution of one interim
for a plenary.
2.5.2.3.3.
Announcement – the drafts are on the local server in
/var/ftp/11/Drafts. This is the only time drafts are available to non-voting
members.
2.5.2.3.4.
2.5.2.4.
Straw Poll:
2.5.2.4.1.
Reduction to 2 out of 3: 2 votes
2.5.2.4.2.
Leave it as it is (2 out of 4): 157 votes
2.5.2.4.3.
Don’t care or abstain: 7 votes
Minutes
page 11
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
2.5.3. Announcements
2.5.3.1.
2.5.3.2.
There will be a TGs ballot at 4pm today
Any objection to modify the agenda to bring forward motions? None
2.5.4. JTC1 Motions
2.5.4.1.
This is an editorial update to documents that were adopted in Garden Grove
2.5.4.2.
Move to approve doc 11-05-0967-09 as the position of the IEEE 802.11
Working Group in regard to WAPI, replacing 11-05-0967-05.
2.5.4.2.1.
Moved Jesse Walker
2.5.4.2.2.
Second Alex Chang
2.5.4.2.3.
Discussion
2.5.4.2.3.1.
Why do we need to do this? Paul Nicolich suggested
that we pass this motion.
2.5.4.2.3.2.
This is actually asking 802 to take a position – should we
re-word it appropriately.
2.5.4.2.3.3.
Motion amended to remove the forwarding to Excom
without objection.
2.5.4.2.4.
Vote: passes 109 : 1 : 16
2.5.4.3.
Move to approve doc 11-05-1205-00 as the current set of comments of the
IEEE 802.11 Working Group on ISO/IEC JTC1 doc 1N7904 (WAPI) and forward to
IEEE 802 ExCom for approval.
2.5.4.3.1.
Moved Jesse Walker
2.5.4.3.2.
Second Clint Chaplin
2.5.4.3.3.
Vote: passes 101 : 0 : 19
2.5.5. Announcements
2.5.5.1.
The joint session of TGv and TGu will be delayed until January. These will be
individual sessions.
2.5.5.2.
Has the document from TIA-TR42 been reviewed and commented upon?
2.5.5.2.1.
Al Petrick states that we addressed this at the last meeting and
forwarded a response. We are waiting for a reply.
2.6.
3.
Recess
2.6.1. The meeting is recessed at 12:00
Friday, November 18, 2005 Closing Plenary
3.1.
Opening
3.1.1. The meeting is called to order at 08:00 by Stuart J. Kerry.
3.1.2. Agenda is in document 05/917r2, and will become r3 after any changes
3.1.3. There are 170 people in the room.
3.1.4. Stuart J. Kerry reviews the agenda for the group
3.1.5. Any modification to the agenda? Any new Items?
3.1.5.1.
Adding 4.6.1: Comments on tickets at the social event.
3.1.5.1.1.
New business item. Added to old business due to Garth having
to leave early. No objection from the floor.
3.1.5.2.
Continuation of liaison report from 802.22
3.1.5.3.
.Report on FAA TSO
3.1.6. Approval of the modified agenda
3.1.6.1.
3.2.
The agenda is approved with Unanimous consent
Letters of Assurance
3.2.1. There are no new LOAs
Minutes
page 12
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
3.3.
Announcements
3.3.1. CAC chairs are reminded to check the dates for providing minutes and
reports, conference calls, web site updates, etc.
3.3.2. Discussion of 802 rules change straw Poll: Stuart reports that there is
general confusion on what is changing in the P&P. The matter is being
withdrawn for the present time. The general WG consensus is to not make
any changes, from other groups as well as 802.11.
3.3.3. Matt Sherman states that the original text from the P&P has been
restored. There will be a vote on other changes in the P&P today. There
will be no change for membership.
3.4.
Documentation
3.4.1. We are considering an interim solution for attendance and documentation.
We will adapt the 802.16 software written by Roger Marks. We should be
able to have electronic sign-in until such a time as the 802 ExCom can
implement a solution for all of 802. This is unlikely to occur anytime soon,
since the RFP can’t even go out until July 06. Implementation in 07 is
most likely.
3.4.2. Discussion
3.4.3. At the end of this year the document numbers should change to 11-06, but
last year they didn’t. Harry assures that there will not be a problem this
year. Harry will change the year number in advance this time.
3.4.4. Is there a way for 802.11 to accelerate the establishment of attendance
and documentation software? We had previous bids – can we use those
as a starting point?
3.5.
Policies and Procedures
3.5.1. Al Petrick has not received any changes on the P&P. Doc 05/456r0 is the
current version.
3.6.
Timeline and Publicity
3.6.1. Nanci Vogtli states that the publicity group completed a press release for
TGk this week.
3.6.2. The Timeline had a few minor updates. It will be posted on the website on
Monday.
3.7.
Editor Report
3.7.1. Simon Barber presents document 05/804r4
3.7.2. Editors group reviewed 2005 style guide, and created a modified
document submissions template for the purpose of submitting draft text.
The new submissions template is being tested. It used the correct styles
and has instructions to the style guide.
3.8.
Meeting Location
3.8.1. Straw Poll – do members like this location and want to come back? 100%
like the location and want to come back. None opposed.
3.9.
WNG Report
3.9.1. Steven McCann presents 05/1222r1
Minutes
page 13
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
3.9.2. Two papers presented, applications in space, and on video transmission.
3.9.3. In January 2006, a follow up on video transmission, as well as a
presentation on OBAN (European project)
3.10. TGk Report
3.10.1.
Richard Paine presents 05/1235r0
3.10.2.
Conducted comment resolution on LB78 for the entire meeting.
Comments were organized and assigned, and resolution was started.
3.10.3.
190 comments were resolved
3.10.4.
Objectives for January are to conduct recirc letter ballot.
3.10.5.
Teleconferences will continue
3.10.6.
Stuart J. Kerry announces that those in the Sponsor Ballot pool
should have received a letter. If you want to sign up for 802.11k Sponsor
Ballot, do so in the next 30 days.
3.11. TGm Report
3.11.1.
Bob O’Hara presents document 05/1166r0
3.11.2.
TGm started processing comments already received in sponsor
ballot underway.
3.11.3.
The ballot does not close until Sunday. There were 84 comments
received so far, and 75 proposed resolutions were written.
3.11.4.
Snapshots of comments and resolutions are in document 06/1167
3.11.5.
In January, will complete processing of comments, and initiate a
recirculation ballot.
3.11.6.
There are no ANA requests received.
3.12. TGn Report
3.12.1.
Garth Hillman presents 05/1228r0
3.12.2.
The group discussed the merged proposal this week.
3.12.3.
There was not a confirmation vote, and the editor was not elected.
The proposal team was not finished. They will continue working until
January, and will bring a baseline document ready for a confirmation vote
to the January meeting.
3.12.4.
There will be a coexistence assurance document issued with the
first draft.
3.12.5.
Minutes are completed as 05/1148r0
3.12.6.
If proposal in January meets 75% criteria, there will be an editor
election. Will try for a draft 1.0 Letter Ballot in March.
3.12.7.
Discussion
3.12.7.1.
The 1221 document is currently at revision 1. The MAC and PHY documents
will be updated later.
3.13. TGp Report
3.13.1.
Lee Armstrong presents document 05/1239r0
3.13.2.
Reviewed draft 0.24, and resolved 73 comments. 43 comments
were closed. There are still open comments.
3.13.3.
Will have teleconferences to continue work
Minutes
page 14
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
3.13.4.
3.13.5.
Will have draft 0.25 by November 28th
Will complete comment resolution in January.
3.14. TGr Report
3.14.1.
Clint Chaplin presents document 05/1233r0
3.14.2.
Will have teleconferences starting Dec 14th, and have an ad-hoc
meeting in February.
3.14.3.
The group generated draft 1.0 this week.
3.14.3.1.
3.14.4.
3.14.5.
Thanks to the editor Bill Marshall for his excellent work.
Will have a motion to forward Draft 1.0 to Letter Ballot.
In January, will resolve comments on the LB.
3.15. TGs Report
3.15.1.
Donald Eastlake presents document 05/1232r1
3.15.2.
Minutes in 05/1156
3.15.3.
There will be one teleconference in January
3.15.4.
There was a downselect vote and one proposal (Mesh Networks
Alliance) was eliminated.
3.15.5.
Goals for January will be to downselect from two to one proposal.
3.16. TGT Report
3.16.1.
Charles Wright presents document 05/1141r0
3.16.2.
There were technical presentations and proposals. Reviewed
current draft 0.4 and approved changes.
3.16.3.
Four proposals were accepted for inclusion into the draft.
3.16.4.
Expect Draft D0.5 by December 15th.
3.16.5.
There will be teleconferences between now and the next meeting.
3.16.6.
There was a request from the FAA for assistance in reviewing a
TSO document.
3.16.6.1.
Proposed reply: Remove Ethernet from the document. References to 11a/b/g
should be removed, but should rather refer to the base standard and amendments.
There was an incorrect reference to 802.11.2.
3.16.6.2.
The individual did not request an official response from 802.11
3.17. TGu Report
3.17.1.
Stephen McCann presents report in 1223r0
3.17.2.
Approved functional requirements, Scenarios and assumptions,
and downselection procedure.
3.17.3.
Had 7 pre-proposal presentations
3.17.4.
Will issue formal Call For Proposals. Initial proposal presentation in
March 2006.
3.17.5.
Had joint meeting with 802.21
3.17.6.
In January 2006, will respond to liaisons, and have joint sessions
with TGv and 802.21.
3.17.7.
No teleconferences
3.18. TGv Report
Minutes
page 15
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
3.18.1.
Pat Calhoun presents document 05/1139r0
3.18.2.
There were a number of submission received and presented.
3.18.3.
Q&A for four submissions was pushed out until January.
3.18.4.
Will continue with motions for submissions to merge with base draft
in January
3.18.5.
Submissions for normative text can continue to be brought in, but
cannot be added in January.
3.18.6.
There will be a joint meeting with TGu to discuss virtual AP and
E911
3.19. TGw Report
3.19.1.
Jesse Walker presents document 05/1226r0
3.19.2.
Heard proposals addressing requirements
3.19.3.
Completed selection process, and voted the BUMP proposal as
basis for Draft 0.0
3.19.4.
Discussed gap between 802.11e and 802.11i. Issue was
determined to be outside the scope of 11w, but should move to 802.11ma.
An Ad Hoc committee will bring text to 802.11ma in January.
3.19.5.
Had a motion to adopt baseline proposal.
3.19.6.
Will have teleconferences.
3.19.7.
In January will refine draft towards Letter Ballot
3.19.8.
Discussion
3.19.8.1.
Request for more details on 802.11e/I gap issue? There are unresolved
issues on DLS. The key generation is not described. There is no synchronization
mechanism.
3.19.8.2.
Who was in the ad-hoc group resolving the issue? Jesse doesn’t remember.
Will be circulated amongst the security people. Will bring to 802.11ma. Will also bring
to reflector? Will be on main WG reflector
3.20. JTC1 Report
3.20.1.
Jesse Walker presents 05/12254r0
3.20.2.
This report covers the Ad Hoc and Study Group
3.20.3.
Ad Hoc was to review the ISO fast-track status. Started process for
becoming registration authority for 8802-11.
3.20.4.
Will continue outreach to get WAPI proponents to work within our
process.
3.20.5.
Will generate a PAR to do the harmonization work.
3.20.6.
Position paper was updated to Rev 9 and was adopted
Wednesday.
3.20.7.
Will meet again in January to receive comments from SC6,
continuing through fast track balloting process, which ends in July.
3.21. CBP SG
3.21.1.
3.21.2.
3.21.3.
Minutes
Peter Ecclesine presents 05/1202r0
Revised draft PAR and 5C and forwarded to WG for approval.
Held joint meeting with 802.1, and 802.18
page 16
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
3.21.4.
NesCom will not vote on PARs until December, so SG was
extended.
3.21.5.
Roger Marks will second the motion to approve the 802.11y PAR.
3.22. Old Business – Motions
3.22.1.
Move to empower the 802.11 WG, Task Groups, Ad-hocs, and
SGs, SCs to hold meetings beginning November 30, 2005 through March
30, 2006 to conduct business as deemed necessary.
3.22.1.1.
3.22.1.2.
3.22.1.3.
Moved Al Petrick
Second Donald Eastlake
Vote: Motion approved with Unanimous consent
3.22.2.
Move to empower the following TG(s)/SG(s)/Ad-Hoc to hold
teleconference calls beginning no sooner than December 4, 2005 through
15 days past the end of the March, 2006 Plenary Session.
Group
Start Date
Duration
Time
CBP-SG
January 4, 2006
Bi-Weekly
13:00 ET
Ad-Hoc JTC1
August 24, 2005
Weekly
19:00 – 20:00 ET
Task Group “k”
December 15, 2005
Weekly
11:30 ET
Task Group “m”
NA
NA
NA
Task Group “s”
January 4,2006
Once
11:00 ET
Task Group “T”
December 15, 2005
January 12th, 2006
Once
Once
12:00 ET
Task Group “p”
December 13, 2005
Weekly
12:00 ET
Task Group “r”
December 14, 2005
Weekly
11:00 ET
Task Group “n”
NA
NA
NA
Task Group “u”
NA
NA
NA
Task Group “v”
December 6, 2005
Weekly
10:00 ET
Task Group “w”
January 31, 2006
Bi-Weekly
11:00 ET
Task Group “y”
January 4, 2005
Bi-Weekly
11:00 ET
3.22.2.1.
3.22.2.2.
3.22.2.3.
3.22.3.
and,
Moved Al Petrick
Second Denis Kuahara
Vote: Motion approved with Unanimous consent
Moved: Whereas, the trial use period of 802.11F has expired
Whereas, there has been no significant deployment of 802.11F
implementations and,
Whereas, the functionality provided by 802.11F is being addressed
in other standards fora,
The 802.11 working group approves the withdrawal of IEEE Trial
Use Recommended Practice 802.11F and requests the LMSC Executive
Committee to forward the withdrawal request to the IEEE-SA Standards
Board.
3.22.3.1.
Moved Bob O’Hara
3.22.3.2.
Second Clint Chaplin
3.22.3.3.
Discussion
3.22.3.3.1.
The reason this is being made is because the Standards Board
Operation manual states a Trial Use document has a lifetime of 2 years.
The document remains open for comment for the first 18 months. There
Minutes
page 17
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
were no comments received on 802.11F. The document is approved as
a full-use standard upon request of the sponsor. To move to a full use
standard, it has to be revised.
3.22.3.3.2.
At this point we have to either approve or withdraw the
document.
3.22.3.3.3.
Believes the work going on in IETF such as CAPWAP address
the needs that 802.11F attempted to satisfy. 802.11F did not satisfy the
needs that it was originally intended to address.
3.22.3.3.4.
No Task Group has taken advantage of any 802.11F features in
the past two years.
3.22.3.3.5.
We should withdraw it so we don’t have to provide ongoing
maintenance to the document.
3.22.3.4.
Vote: Motion passes 81 : 3 : 21
3.22.4.
Move to approve IEEE 802.11k press release doc:05/1240r0 and
forward to IEEE 802 ExCOM for approval release for media publication.
3.22.4.1.
3.22.4.2.
3.22.4.3.
Moved Nanci Vogtli
Second Richard Paine
Vote: Motion passes 85 : 0 : 9
3.22.5.
Move to authorize a 40-day Working Group Letter Ballot of 802.11r
draft 1.0 to start no later than 12/02/2005, asking the question “Should the
802.11r draft 1.0 be forwarded to sponsor ballot?”
3.22.5.1.
3.22.5.2.
Moved Clint Chaplin on behalf of TGr
Vote: Approved with Unanimous consent
3.22.6.
Move to authorize an IEEE 802.11 TGr ad-hoc meeting on
February 7th,2006 through February 9th, 2006
3.22.6.1.
3.22.6.2.
Moved Clint Chaplin on behalf of TGr
Vote: Approved with Unanimous consent
3.22.7.
Move to extend the ISO/IEC JTC1/SC6 study group up to and
including the March 2006 plenary session.
3.22.7.1.
3.22.7.2.
3.22.7.3.
Moved Jesse Walker
Second Clint Chaplin
Vote: motion passes 92 : 0 : 5
3.22.8.
Move to extend the CBP study group up to and including the March
2006 plenary session.
3.22.8.1.
3.22.8.2.
3.22.8.3.
3.22.9.
Moved Peter Ecclesine
Second Bob O’Hara
Vote: motion passes 92 : 0 : 4
Comments on Social
3.22.9.1.
Garth Hillman notes that he has been unable to get drink tickets for the last 3
socials. Requests a better process for distributing these valuable tickets. Proposes
that drink tickets are provided with registration badges.
3.22.9.2.
Motion to include concession tickets in the membership badge at registration.
3.22.9.2.1.
Moved Garth Hillman
3.22.9.2.2.
Second Charles Wright
3.22.9.2.3.
Discussion
3.22.9.2.3.1.
Like the concept, but should not specify the number.
Friendly amendment accepted with no dissent
3.22.9.2.3.2.
Should we establish a study group to address this
problem…
3.22.9.2.4.
Vote: Motion passes 87 : 0 : 4
3.23. 802.22 Liaison Report
Minutes
page 18
Tim Godfrey, Link-7
Nov, 2005
doc.: IEEE 802.11-05/1136r0
3.23.1.
Peter Ecclesine reports that the PAR for 802.22.1 will come up this
afternoon at ExCom. He urges that we don’t take any position on it
3.23.2.
Discussion
3.23.2.1.
Carl Stephenson, 802.22 chair, clarifies that 802.22 is not developing a
standard for wireless microphones, but will develop a mechanism for unlicensed
devices to detect and protect the operation of these licensed devices.
3.24. New Business
3.24.1.
None
3.25. Announcements
3.25.1.
Stuart J. Kerry has received emails regarding use of EDT for
balloting. The P&P documents state that ballots are based on time at IEEE
headquarters in New Jersey.
3.25.2.
Dave Bagby comments on contact lists. Previously full contact
information was published. Recently this information has been withheld
due to privacy concern. Suggests that full contact information could be
provided on an opt-in basis, as a means of helping the body find other
members and work with them.
3.25.3.
Denis Kuahara suggests that individuals use IEEE aliases for their
email addresses if they wish to remain unaffiliated.
3.25.4.
Stuart J. Kerry announces that the next agenda for January is
document 05/1234 and will be posted 30 days before the next session.
3.26. Adjourn
3.26.1.
The meeting is adjourned at 09:30
3.26.2.
The next meeting is January 15th-20th, 2006 at the Hilton Waikoloa
Village, Big Island, HI USA
Minutes
page 19
Tim Godfrey, Link-7
Abbott
Aboul-Magd
Abraham
Adachi
Agarwal
Agre
Aldana
Alexander
Alfvin
Amann
Andrade
Andrus
Aoki
Aramaki
Ariyavisitakul
Armstrong
Arnett
Asai
Aso
Astrin
Audeh
Bagby
Bahr
Baker
Baker
Bangolae
Bao
Barber
Bari
Basson
Batra
Baysal
Benko
Benveniste
Berkema
Berry
Bhandaru
Bjerke
Black
Calhoun
Cam-Winget
Canpolat
Carney
Cash
Chaplin
Chari
William
Osama
Santosh
Tomoko
Puneet
Jonathan
Carlos
Thomas
Richard
Keith
Merwyn
David
Tsuguhide
Takashi
Lek
Lee
Larry
Yusuke
Keigo
Arthur
Malik
David
Michael
Dennis
Dennis
Sangeetha
feng
Simon
Farooq
Gal
Anuj
Burak
John
Mathilde
Alan
Don
Nehru
Bjorn
Simon
Pat
Nancy
Necati
Bill
Broady
Clint
Amalavoyal
CHEN
Chen
Chen
Cheng
Cheng
Cho
Choudhury
chu
Chung
Ciotti
Conner
Cook
Cooklev
Crowley
Das
Davari
de Vegt
Demel
Dickey
Doi
Dorsey
Douglas
DuMas
Durand
Durand
Dure
Eastlake 3rd
Ecclesine
Eckard
Edney
Einhaus
Elbakoury
Emeott
Emmelmann
Engwer
Epstein
Epstein
Ergen
Eroz
Faccin
Falk
Fedyk
Feinberg
Fischer
Fisher
Foegelle
CHIEN-HUNG
Jeng-Hong
Yi-Ming
Alexander
Hong
Jaeweon
Abhijit
liwen
Simon
Frank
W. Steven
Charles
Todor
Steven
Subir
Shahram
Rolf
Sabine
Susan
Yoshiharu
John
Brett
Phillip
Chris
Roger
Sebastien
Donald
Peter
Richard
Jonathan
Michael
Hesham
Stephen
Marc
Darwin
Joe
Leonid
Mustafa
Mustafa
Stefano
Lars
Donald
Paul
Matthew
Wayne
Michael
Ford
FREMONT
Gifford
Godfrey
Goel
Golden
Gong
Grandhi
Gray
Gray
Green
Green
gurevich
Haisch
Hares
Hart
Hartman
Haslestad
Hattig
Hauser
Hayase
Hayes
Hedberg
Henderson
Hermodsson
Heubaum
Hiertz
Hillman
Hinsz
Hirano
Hoghooghi
Honary
Hu
Hunter
Hwang
Ikram
Inoue
Ishida
Ishidoshiro
Ishii
Iyer
Jacobsen
Jauh
Jetcheva
Ji
Johnson
Brian
Benoît
Ian
Tim
Sandesh
Stuart
Michelle
Sudheer
Gordon
Paul
Evan
Larry
david
Herman
Susan
Brian
Chris
Thomas
Myron
James
Shigenori
Kevin
David
Gregory
Frans
Karl
Guido
Garth
Christopher
Jun
Michael
Hooman
Wendong
David
Hyo sun
Muhammad
Yasuhiko
Kazuhito
Takashi
Yoshiyuki
Lakshmi
Eric
Yuh-Ren
Jorjeta
Lusheng
Todd
Jokela
Jones
Joshi
Kado
Kain
Kakani
Kangude
Karaoguz
Kasher
Kato
Kavner
Ketchum
Khieu
Kikuma
Kim
Kim
Kim
Kim
Kim
Kim
Kim
Kim
Kim
Kimhi
Kleindl
Kneckt
Kobayashi
Kobayashi
Koga
Kolze
Kose
Kraemer
Krishnan
Kruys
Kunihiro
Kuratani
Kurihara
Kvarnstrom
Kwak
Landt
Lee
Lee
Lee
Lee
Lee
LEE
Jari
VK
Avinash
Youiti
Carl
Naveen
Shantanu
Jeyhan
Assaf
Masato
Douglas
John
Andrew
Tomohiro
Dongho
Jae-Hyon
Jaeyoel
JinKyeong
Joonsuk
Kyeongsoo
Min-Soo
Tae-eun
Youngsoo
Ziv
Guenter
Jarkko
Kiyotaka
Mark
Keiichiro
Thomas
Cenk
Bruce
Gopal
Jan
Takushi
Yasutaka
Tom
Bo
Joseph
Jeremy
Dongjun
Insun
Jihoon
Myung
Sok-Kyu
SUNG-WON
Lefkowitz
Levy
Li
Lin
Liu
Liu
Liu
Loc
Lojko
Lou
Madhavan Pillai
Mani
Mano
Mantri
Marshall
MARUYAMA
Matache
MATSUMOTO
Matsuo
Maufer
McCann
Mcclellan
McFarland
McNamara
Mcnew
Medvedev
Mehta
Merrill
Meyer
Meylan
Miller
Min
Molisch
Montemurro
Moreton
MORIOKA
Morioka
Muck
Mujtaba
Murali
Myles
Nagai
Nakache
Nakamura
Nakao
Nakase
Martin
Joseph
Yuan
Huashih
Hang
Jun
Yong
Peter
Peter
Hui-Ling
Krishna
Mahalingam
Hiroshi
Vijay
William
NAOTAKA
Adina
TOMOYUKI
Ryoko
Thomas
Stephen
Kelly
William
Darren
Justin
Irina
Pratik
Mark
Klaus
Arnaud
Robert
Seungwook
Andreas
Michael
Mike
Hitoshi
Yuichi
Markus
Syed
Partha
Andrew
Yukimasa
Yves-Paul
Tetsuya
Seigo
Hiroyuki
Nanda
Narasimhan
Narkadamilli
Ngo
Niu
Noble
Noens
Ogawa
Oguma
O'Hara
Ojard
Olson
OVADIA
Paine
Palm
Panish
Perahia
Perillo
Petranovich
Petrick
Pirzada
Pitarresi
Pollock
Poojary
Ptasinski
Qi
Qian
Raab
Rahman
Raissinia
Ramesh
Rayment
Reddy
Rios
Rosdahl
Roy
Rude
Rudolf
Sadeghi
Sadot
Saleem
Sarrigeorgidis
Sashihara
Sastry
SATAPATI
Saxena
Sanjiv
Partha
Purushothamarao
Chiu
Huaning
Erwin
Richard
Masakatsu
Hiroshi
Bob
Eric
Timothy
SHLOMO
Richard
Stephen
Paul
Eldad
Mark
Jim
Al
Fahd
Joe
Tony
Neeraj
Henry
Emily
Lu
Jim
Shah
Ali
Sridhar
Stephen
Joseph
Carlos
Jon
Richard
Michael
Marian
Bahareh
Emek
Syed
Konstantinos
Toshiyuki
Ambatipudi
SURESH
Monica
Schylander
Sensendorf
Shao
Sharma
Sharon
Shen
Sherlock
SHIRALI
Shvodian
Siep
Simpson
Singh
SITI
Skafidas
Smith
sood
Soomro
Soranno
Stanley
Stephens
Stevens
Stibor
Stolpman
Strutt
Sugawara
Surineni
Suzuki
Takagi
Takagi
Takahashi
Takai
Takeda
Tan
Tanaka
Tao
Taori
Tavares
Thrasher
Tokubo
Tolpin
Towell
Trainin
Trecker
Tsien
Tsoulogiannis
Tung
Erik
Joe
Huai-Rong
Neeraj
Ariel
BZ (Ba-Zhong)
Ian
KEDAR
William
Thomas
Floyd
Balraj
MASSIMILIANO
Efstratios (Stan)
Matt
kapil
Amjad
Robert
Dorothy
Adrian
Fabrice
Lothar
Victor
Guenael
Tsutomu
Shravan
Hideyuki
Eiji
Masahiro
Seiichiro
Mineo
Daisuke
Teik-Kheong
Yasuhiro
Jeffrey
Rakesh
Clifford
Jerry
Eric
Alexander
Tim
Solomon
Christopher
Chih
Tom
David
Turner
Tzamaloukas
van Nee
van Waes
van Zelst
Varas
Victor
Vlantis
Wakeley
Walker
Wallace
Wandile
Wang
Ward
Ward
Ware
Watanabe
Wells
Wentink
Weytjens
Whitesell
WILSON
Winters
woodyatt
Worstell
Wright
Xhafa
YAGI
YAMAMOTO
Yamaura
Yang
Yao
Yu
Zaks
Zeira
Zhang
Zhu
Zorlu-Ozer
Zuniga
Zweig
Sandra
Mike
Richard
Nico
Allert
Fabian
Dalton
George
Timothy
Jesse
Brad
Vivek
Huaiyuan
Dennis
Lisa
Christopher
Fujio
Bryan
Menzo
Filip
Stephen
james
Jack
james
Harry
Charles
Ariton
AKIYOSHI
Takeshi
Tomoya
Liuyang
Zhonghui
Heejung
Artur
Eldad
Bing
Jeffrey
Sebnem
Juan Carlos
Johnny
November 2005
doc.: IEEE 802.11-05/1177r4
IEEE P802.11
Wireless LANs
Minutes of TGk Vancouver Meeting
Date: 2005-11-17
Author(s):
Name
Paul Gray
Company
AirWave Wireless
Address
Phone
1700 S. El Camino San Mateo,
CA
email
650-678-5633
paul@airwave.com
Abstract
This document contains TG 11k minutes from Vancouver Meeting.
.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
11/14/05 PM1 Session:
Meeting called to order at 14:00
1. Chair provided the standard IEEE policies and procedures.
a. Patent Policy
b. Inappropriate Topics
c. Documentation and Presentation rules
d. LB 78
2. Review Category Assignments
3. Review Comment Resolution Process
a. Present draft is 3.0
b. Documents must be on the server before presenting
c. For lb78 comment processing, need a document with changes to D3.0 + (if necessary) a
Powerpoint to present them + draft motion to instruct the editor.
d. 1049 spreadsheet should not be used for proposition resolved comments.
e. Per editor, if the resolution is more than 3 lines within a cell, then it should be separate word
document.
4. Assign owners for comments without owners and split up larger comment groups
Blank Comments
- 7.0 – reassigned to 7.3.2.21 (Black)
- 7.3.2 ANA – Paine
- 9.10 – Paine
- 10 – Simon Black
- 7.3.2.17 – should be renumber to 7.3.2.27 (Marty)
- 7.3.2.20 – assign to Roger
- 7.3.2.9 – should be renumbered to 7.2.3.9 (Tim)
- 7.3.2.4.21.13 – 7.3.2.21.13 (Black)
- 11.12.1 – Marty Neighbor validation
- 11.12.2 – Marty
- 11.12.3 - Marty
- 11.2.3 – Change to 11.12.3 and assign Marty
Comment Reassignment:
- 7.3.2.21.11 – Peter
- 7.3.2.22.11 – Peter
- 7.3.2.21.4 – Joe
- 11.11.9.4 – Joe
- 7.3.2.21.10 – Joe
- 7.3.2.22.10 – Joe
- 7.3.2.21.13 – Simon
- 7.3.2.22.13 – Simon
- 7.3.2.22.7 – Matta
- 7.3.2.21.7 – Matta
- 11.11.9.2 - Matta
- 7.3.2.21.5 –Joe
- 7.3.2.22.5 - Joe
- 7.3.2.22.4 – Joe Channel Load
Submission
page 2
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
5. List of people willing to change their vote
a. Peter
b. Nancy
c. Andrew
d. Steve Emeott
6. Meeting in recess at 5:57 until PM 2 tomorrow
Submission
page 3
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
11/15/05 PM1 Session:
Meeting called to order at 16:00
1. Review Agenda
a. Vote on Garden Grove minutes
b. Call from presentations
c. Update from editor
d. Review new comments submitted after Vancouver meeting began
2. Motion to approve agenda passes unanimously
a. Marty’s comments were approved but never made it into the draft
b. Simon Black objects and states that the current text is the will of the group and we should not
amend the text. We should not include Marty’s comments in 3.0. It can go into 3.1, but 3.0
is a snapshot in time.
c. Tabled the discussion until Marty and Simon Barber are in the room.
3. Review Comment Resolution Process
e. Present draft is 3.0
f. Documents must be on the server before presenting
g. For lb78 comment processing, need a document with changes to D3.0 + (if necessary) a
Powerpoint to present them + draft motion to instruct the editor.
h. 1049 spreadsheet should not be used for proposition resolved comments.
i. Per editor, if the resolution is more than 3 lines within a cell, then it should be separate word
document.
4. Motion to approved agents passes unanimously
5. Technical Presentation – LB78 Clause 7.1 Comment Resolution – Olson – 1174r0 (xls) and 1173r0
(doc) - Olson
a. Resolves comments - 120, 142, 161, 201, 278, 386, 820, 835, and 901 (1173r0)
b. Spreadsheet – 1174r0 and word document is 1173r0
c. Comments regarding proposal
Question – why is their informative text in normative section? Answer – I try to give a brief
description which has been done in the past.
Comment – you should include comment #1410 – we should follow up on this comment.
Motion for Counter Comments
Move to counter TGk LB78 comments 120, 152, 161, 201, 278, 386, 820, 835, 901 and
instruct the TGk editor to apply the changes found in document 05/1173r0 to the next TGk
draft.
Discussion on Motion
Question – should you include power saving in your description? Answer – power saving is
a result of link margin and this is the way
Moved: Olson
Second: Simpson
For: 10
Against: 0
Abstain: 0
Motion passes unanimously
Submission
page 4
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
d. Comment #107 – The comment is accepted and no changes are required, because the motion
matches the draft. See comment #511 for the editorial error which caused this
misunderstanding.
Motion (Accepts)
Move to accept TGk LB78 comments number 107 with a comment resolution described on
line 107 of document 05/1174r1.
Discussion on Motion
None
Moved: Olson
Second: Simpson
For: 8
Against: 0
Abstain: 1
Motion passes unanimously
e. Comment #511
Motion
Move to accept TGk LB78 comment number 511 and instruct the TGk editor to apply the
changes found in the comment resolution column on row 511 in document 05/1174r0 to the
next TGk draft..
Discussion on Motion
None
Moved: Olson
Second: Simpson
For: 7
Against: 0
Abstain: 1
Motion passes unanimously
6. Technical Presentation – LB78 Comment Resolution – Simpson – 1179r0 (xls) and 1173r0 (doc)
[same as Tim’s] - Simpson
a. Resolves comments – 300, 1313, and 1410
b. Motion
Motion
Move to counter TGk LB78 comments 300, 1313, and accept comment 1410 and instruct the
TGk editor to apply the changes found in document 1173r0 into the next TGk draft.
Discussion on Motion
None
Moved: Simpson
Second: Olson
For: 9
Submission
Against: 0
page 5
Abstain: 1
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
Motion passes unanimously
7. Technical Presentation – LB78 Clause 11.1.3.2.1 (sending a probe response) Comment Resolution –
Simpson – 1193r0 (PPT) - Simpson
Issue #1
a. Comment #775 – add the following sentence in first paragraph of clause 11.1.3.2.1
If the DS Parameter Set information element is present in the probe request, a STA where
dot11RadioMeasurementEnabled is true shall respond only if the channel number from
the DS Parameter Set element matches the channel in use by the STA. If the DS
Parameter Set information element is present in the probe request, a STA where
dot11RadioMeasurementEnabled is false may respond only if the channel number from
the DS Parameter Set element matches the channel in use by the STA.
b. Discussion about spreadsheet
Marty has an objection about the spreadsheet not be complete.
Discussion was out of order and discussion regarding comment #775 continued.
c. Discussion on the comment
Question – is a legacy STA considered an 11k STA w/o RRM enabled. Answer – it is based
on the existence of 11k STA, so legacy STAs do not apply.
Comment – a legacy STA could not parse it.
Issue #2
d. Comment #777 – “Currently a legacy STA might respond to a probe request including the DS
Parameter Set (on the basis of ignore the IEs you don't understand). This clause would make
such behaviour retrospectively illegal, and an ammendment should avoid doing that.
e. Discussion on the comment
Comment – I agree with this and I wish it were mandatory
Comment – make it optional by configuration option or get rid of it.
Comment – the commenter is rejecting this because it is a broadcast which is not valid
Comment – we are trying to avoid the other channels from responding and his solution does
not address it.
Comment – comment #1441 is analogous to this comment
f.
Straw Poll #1
Do you support removing the DS parameter set based modifications from clause 11.1.3.2.1?
Yes: 1
No: 5
g. Straw Poll #1
Do you support making the DS parameter response side optional at runtime under MIB
control in clause 11.1.3.2.1?
Yes: 1
No: 6
Issue #3
h. The text changes introduced by TGk does not integrate well with base text. For example,
base text 1st sentence says: “STAs, subject to criteria below, receiving Probe Request frames
shall respond with a probe response only if the SSID in the probe request is the broadcast
SSID or matches the specific SSID of the STA.”
- TGk text changes conflicts with this statement because the probe request could be to
a broadcast SSID, but because the DS Parameter Set channel number does not match
the channel in use by the STA receiving the probe request, the 11k STA would not
respond.
Submission
page 6
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
-
i.
The text in this section need better overhaul to properly describe how 11k enabled
STA operation is different, if indeed, it is or should be.
Discussion on the comment
Comment – The sentence do not flow well together.
Comment – remove the “only”
Comment – you can’t the “only” without losing some clarity.
Comment – Start new sentence with “Additionally”
8. Approved Ad Hoc minutes
Motion
Move to approve the minutes of the Vancouver Ad Hoc 11/14/05 in document 05/1153r0.
Moved: Ecclesine
Second: Olson
For: 6
Against: 0
Abstain: 2
9. Comment by secretary – we need to approve Garden Grove minutes.
10. Technical Presentation – LB 78 Comment Resolutions dealing with 11.9.2 – 1191r0 (xls) and 1192r0
(doc) – Olson
a. Decline comments
Comment #18 – Clause 11.9.2 - Soranno
Problem - A unit of measurement should be provided for "power level". Note that this is not
the first instance of this term. It appears from the statement that it should be in dB. Later, in
Section 15.4.8.5, p. 78, lines 12-13, it is defined in dBm.
Remedy - Specify units of "power level" as dBm.
Resolution – decline - Since this section is a general discussion of power limits the units are
not needed here. By leaving the units out in this section the equations and discussion are
relevant to any of the various units used in the individual PHY sections.
Comment #371 & 1384 – Clause 11.9.2
Problem - This seems like duplicate information that already exists in the beacon and probe
responses as a result of the country information element.
Resolution – decline – This information is not always redundant and an administrator may
decide to include regulatory parameters in either or both locations.
Motion
Move to decline TGk LB78 comments 18, 371, 1384 with comment resolution described on
row 18, 371, and 1384 respectively of document 05/1191r1.
Moved: Olson
Second: Simpson
Discussion on Motion
None
For: 5
Against: 0
Abstain: 1
Motion passes unanimously
b. We did not vote on these comments. Comment #781, 782, 1083, and 1084 which are
addressed in 1192r0.
11. We need to ensure that Figures and Tables get resolved in final text.
12. We should review the document as a task group prior to putting out a draft.
Submission
page 7
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
13. Meeting in recess until AM1 tomorrow.
Submission
page 8
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
11/16/05 AM1 Session:
Meeting called to order at 08:00
1. Review Agenda
a. Vote on Garden Grove minutes
b. Presentations
c. Olson vote
d. Review new comments
2. Motion to approve agenda passes unanimously
3. Review new comments which arrived after Vancouver.
4. Motion to approve Garden Grove minutes
Motion
Move to approve the minutes of the Garden Grove meeting (05/933r6).
Moved: Kwak
Second: Gray
Discussion on Motion
Motion passes by unanimous consistent.
5. Technical Presentation LB79 comment resolution for section 11.9 - Olson - 1191r2 (xls) & 1192r1
(doc)
a. Address the following comments: 781, 782, 1083, 1084
b. 1192r1 (doc) addresses comments - 781, 782, 1083
c. Accepted comments – 781, 782, 1084
d. Countered comments – 1083
Motion
Move to counter TGk LB78 comment 1083 and accept comments 781, 782, 1084 and to
instruct the TGk editor to apply the changes found in document 05/1192r1 to the next TGk
draft.
Moved: Olson
Second: Miller
Discussion on Motion
None
For: 8
Against: 0
Abstain: 1
Motion passes unanimously.
6. Meeting in recess until 9:45.
7. Resumption of meeting at 9:45.
Submission
page 9
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
8. Discussion on controversial issues which we should address as a group.
a. BSS Load – Should we keep it in? We will address it after the plenary.
b. QoS Metrics – some discussion, but we are not going to address it as a group.
c. LCI – make sure the groundwork we laid will be extensible. Should we leave it in 11k or
move it over to 11v. Will this meet the needs for 911? The only way to know 911 is
available is to get a rejection.
9. Meeting in recess until 13:30.
Submission
page 10
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
11/16/05 PM1 Session:
Meeting called to order at 13:30
1. Review Agenda
a. Update from editor
b. BSS Load Discussion
c. LCI Discussion
d. Discussion about baseline spreadsheet
2. Update from Editor
a. Resolved all of broken text comments
b. Question – (Simon Black) has a problem with MS word styles. Answer – Editor is going to
wait until conversion to FrameMaker to convert styles.
c. Editor recommends using the 2005 template on the server.
d. Comment – Draft templates are different from the submission template. Editor will make a
recommendation on Friday to take care of this.
e. Editor – assign all formatting errors to editor. Email Secretary with the comment numbers
which have formatting errors (page break, broken figures) and these will be assigned to
Editor in the master spreadsheet 1049.
f. Question – how could the last draft get out with all of the errors? Answer – we had a hard
deadline and Editor began merging 11h and 11e which caused the conflict. We need to word
the motion correctly in the future so we don’t have this deadline.
g. Question (Simon Black) – How do you want to handle Figure Numbering? If you use the
same field codes that are in the draft, then the figure numbering will automatically work. It
will only be consistent within the draft itself. You should put a note to the editor. Put the
Title from the original figure in case the numbering has changed.
h. Comment – The draft that we are preparing can not be based on 11ma.
3. Discussion on doing a recirculation in Hawaii
a. We must have all comment resolved and papers ready when we arrive for next meeting.
b. There must be a draft that is very close that pre-includes the drafted resolutions.
c. We need to find a way for the entire Group to review the draft prior to putting it out.
d. Question/Comment (Marty) – How can we go to recirculation? Shouldn’t we consider doing
another LB if there substantial change. We should not make a premature decision in regards
to recirculation or LB.
e. Comment – we don’t have to address the “yes” comments.
f. Comment – we need to address them, because they will come back again. Legally no, but
practically yes.
4. Discussion on BSS Load
a. Comment - We have a large number of comments on what is its meaning and why is it
optional. Simon Black has a comment resolution which should address the optional
comments.
b. Comment - Scaling is problem as well. We can use RCPI as model.
c. Comment – There is correlation with QoS.
d. Comment – If you find BSS Load comments in your section they should be re-assigned, then
send to the Secretary. Secretary will reassign and publish new spreadsheet.
5. Discussion on LCI
a. Tim and others are putting together a complete E911/LCI solution in TGv. Do we want to
leave LCI in 11k? It has some merit, but it is not complete.
Submission
page 11
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
b. Problem - If I have 10 measurements going and I want an LCI measurement, I will have to
cancel all of the 10 pending measurements.
c. Simon Black – 11k we have passed the LB and 11v does not have a formal set of defined
objectives. 11v is some ways off.
d. Peter – has resolved already addressed many of the LCI comments.
e. Joe Kwak – E911 should be resolved in a single group. Currently it is impacting 11u, 11v, or
other.
f. Marty – there probably should be a separate E911 group. Combining E911 with all of the
other issues in 11k presents a great deal of problems. Marty would recommend removing the
“where are you” “here I am” stuff.
g. Tim – 11k does not solve E911. Timing will be a problem in any other group 11v, 11u, or
other. It would far cleaner and easier to implement in 11v. Maybe LCI can be used for other
purposes.
h. Joe Kwak – Our goal is to be location aware and not solving E911. If we come up with
something that is superior, then we can deprecate LCI in 11k.
i. Peter – There are 4 scenarios that are requirements for LCI (location awareness), 3 excluding
E911. The privacy requirements that are not going to be addressed, but we should still
continue.
j. Emily – LCI has value other than E911.
k. Tim – we have not defined a location measurement. We have defined a framework
(request/report) to exchange location between two peers. We have not defined measurements
for locating.
l. Darwin – E911 is a complex area which may need to be addressed in multiple groups. We
should listen to E911 group and enumerate the requirements and assign out the tasks.
m. Joe – LCI is the exchange and not a measurement. However, if I ask you “where am I”, then
it is clearly a location measurement. If you know where you are at then you can locate the
other device.
n. Emily – It is similar to the Neighbor Report and provides environment information which can
provide a great deal of value.
o. Peter – 05/1039r3 is the CDP objectives. CDP is going to cross many task groups which
have timing issues as well.
6. Discussion about the baseline spreadsheet
a. 1049r18 is a baseline
b. Marty – if you don’t have all of the comments then you might not make the most informed
decision based on all of the comments.
c. Peter – we have always looked at comments as a divide and conquer
d. Tim – the vote is 75% on the motion on any particular comment.
e. Joe Kwak – always try to use the latest version of the 1049 (master spreadsheet). This way
you will be up-to-date on all comments and their resolution current status/resolution.
f. Tim – you should incorporate all information and we don’t have guidelines which restrict
you. All comments must get voted on. The comments left out in the beginning will
eventually be addressed and the text might be changed. I don’t want to be required to always
keep up with the latest spreadsheet.
g. Peter – Robert’s rules allow us a serial sequential process and it is in our hands to do the right
thing.
7. Meeting in recess until 4:00 PM.
Submission
page 12
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
11/16/05 PM2 Session:
Meeting called to order at 16:00
1. Meeting in recess for 11s vote until 17:45
2. Meeting resumes at 17:45
3. Discussion regarding ANA number assignment – Peter will determine if we need to get a number.
The only way ANA will assign a number is by passed resolution in a Task Group
4. The following comments were resolved by Simon Barber in 1214r0 related to Incorrect References.
These comments were labeled as “Technical” when they were clearly “Editorial”. The Chair made
the decision that these comments could be recategorized as editorial. 131, 132, 133, 134, 296, 316,
318, 321, 327, 337, 338, 340, 345, 402, 403, 404, 405, 406, 407, 411, 412, 710, 913, 1308, 1329,
1331, 1334, 1340. 1350, 1351, 1353, 1483, 1521.
Submission
page 13
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
11/17/05 PM1 Session:
Meeting called to order at 13:30
1. Review Agenda
a. Chair announcements
Sponsor Ballot has been formed and is available on MyBallto
Sponsor Ballot will be released in an email
Sponsor Ballot invitation announcement will be made in the Closing Plenary
Met this morning with the WFi group channelling me through their process
b. Presentations
c. Simon Black issues
PICS
Noise
Other
d. Vote on teleconferences
e. Vote on ad hoc
f. Vote on interim
2. Future plans
a. Recirc
b. Teleconferences – only if necessary
3. Technical Presentation – LB79 Comment Resolutions related to Clause 11.1.3.2.1 - 1211r1 (xls) and
1209r1 (doc) – Simpson
a. Decline comments
Comment #255
Resolution – decline – the intent of the sentence is clear and through straw polls it represents
the consensus of the group.
Comment #774
Resolution – decline – A requirement stating “…shall respond only if condition A…” is
shorthand for a compound requirement which need not be written. The compound equivalent
requirement is “…shall respond if condition A and shall not respond if condition not A.”
Comment – this resolution does not address the commentor’s problem.
Comment #776
Resolution – decline - Both 802.11-1999 (R2003) and 802.11-REVma use the term probe
request in this clause without writing them in uppercase. Since it is not clear when to use
upper case vs. not, the TG chose to keep the style of the base draft.
Comment #777
Resolution – decline - TG straw polls on this issue shows a majority decision to mandate the
behaviour indicated in this clause for STA with dot11RadioMeasurementEnabled=true
Comment #1441 - Lefkowitz
Resolution – decline – TG straw polls on this issue shows a majority decision to mandate the
behaviour indicated in this clause for STA with dot11RadioMeasurementEnabled=true
05/0409r0 John Klein drafted a document (05/0409r0) to address comment #63, #198 from
LB73. We might not want to delete the paragraph.
b. Counter comments
Submission
page 14
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
Comment #775
Resolution – counter – The TG generally agrees with commenter, but proposes a different
resolution, which is to delete the indicated sentence in 1209r1.
Comment – about the editing instructions within 1209r1.
Comment #1442
Resolution – counter - The text is redundant and has been deleted as indicated in doc 1209r1
Comment #1558
Resolution – counter – The TG generally agrees with the commenter, but proposes a different
resolution, which is to delete the indicated sentence as unnecessary and as shown in doc.
1209r1
c. Discussion – we should leave it in and come up with the justification on why we should leave
it in.
d. Change the resolution comments for comment #1442 – The text clarifies the operation of
probe request containing a Request element as asked for by comment #198 in doc
05/0191r70. Probe Rqst/Response mechanism …
e. Motion
Motion
Move to decline TGk LB78 comments 255, 774, 776, 777, 1441, 1442 with the comment
resolutions described in document 05/1211r2.
Moved: Simpson
Second: Kwak
Discussion on Motion
For: 12
Against: 0
Abstain: 2
Motion passes unanimously
4. R.R. Miller assumes secretarial duties
5. Technical Presentation – Noise Measurement Comment Resolution - Simon Black
a. Last meeting we voted that we wanted a mandatory noise measurement
b. Straw Poll on keeping the noise histogram measurement mandatory.
Straw Poll
Should the noise histogram measurement remain a mandatory measurement in 11k?
Roger D – suggests an amendment “should it become optional?” instead.
Simon accepts this amendment
Should the noise histogram measurement become an optional measurement in 11k?
Yes 3
No 9
Abstain 2
6. Technical Presentation – LCI Comment Resolutions – Simon Black
a. LCI is mandatory, but this seems a contradiction. It says that if you can’t supply the info, you
should say “incapable” but this seems incompatible with mandatory.
Submission
page 15
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
Comments
Peter - Right now if you cannot respond to LCI then you set the incapable bits. In other
frames the bits mean only one thing. Here it could be two.
Joe - One of the reasons for putting location in 802.11 was the regulatory issue. I thought a
good reason for making LCI mandatory was to prepare for these. We could ensure that it
would be in the PICS.
Simon Black - But why would we specify a mandatory “bucket” without saying how to fill it?
Peter - It’s a single coordinate system over the whole world. If we make this mandatory we
can make sure it’s the same everywhere, like the ISO standard. Services around where the
station is would be represented in only one form.
Simon - We have only one comment on this, and I haven’t spoken to the commenter. I
recommend that we make it mandatory on the basis of this discussion.
Peter - If it is represented as mandatory, the station simply has to respond, not necessarily
with complete information.
Simon - OK. There’s only one more. We have a station selected mode either passive or
active and both are mandatory. It seems like station selected should also be mandatory. I
recommend that it becomes mandatory.
7. Meeting in recess at 15:28.
Submission
page 16
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
11/17/05 PM2 Session:
Meeting called to order at 16:00
1. Discussion on Process
a. Discussion
Larry - All the work this week has been aimed at creating another draft? Does he have the
ability to post another draft himself? Answer - Yes. However Harry has researched this, and
has found that we are supposed to review before submitting.
Joe - The task group needs to look at the draft before it is released to make sure the editor has
created an acceptable document.
Char - We may have to check the rules to determine the rules for this.
JoeK - We could have an interim task meeting to check the editor’s draft.
b. Motion for weekly teleconferences
Move to request the Working Group to empower TGk to hold weekly teleconferences
(Thursdays at 11:30 am Eastern time) through 2 weeks after the Denver meeting 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: Black
Second: Kwak
Discussion
Comment - The idea would be that now that we have the authority, we should send a notice
on the reflector announcing that the meeting is cancelled (should it be).
Comment - This turned out differently in “n”, so I’m confused.
Chair - What is the confusion?
Comment - In “n” it seemed that the teleconference didn’t have to be on the main 802.11 list.
Chair - That does not track with my understanding of the correct process.
Comment – That was not my experience either.
For: 7
Against: 0
Abstain: 0
Motion passes unanimously
2. Meeting in recess at 16:20 until 17:50 for comment resolution
3. Meeting convened at 17:50
4. Recirculation Discussion
c. Question - Can we get the process in the minutes for proceeding with the draft? Answer -We
can get the document ready to go, and at the end of the Hawaii meeting, Simon will prepare
the document.
d. Editor - If anyone is entertaining editorial changes, please forward them to me as early as
possible, so that I can put them in before the meeting starts, leaving technical changes for the
meeting.
e. Question - If the editorial change involves technical data can still be editorial? Answer
(Editor) Yes, as long as it is just correction of the text.
f. Comment - If the changes are marked with strikeout bars, then people can see the change and
approve it. I may have two documents one with, one without just in case…
g. Comment (Editor) - If the changes are small and clearly editorial, I can put them in early.
h. Comment (Chair) - The process (allowing for 4 hour rule) would mean that we would have
only the two sessions on Thursday to accomplish the updates.
Submission
page 17
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1177r4
i.
Comment - The process then must make sure that things viewed as controversial would be
covered in a separate document. Is that OK? Answer (Chair) Yes, but for Simon let me
describe the process. We shall approve a 15 day letter ballot for the whole working group to
approve the draft for recirculation. Then we go 15 days, and if 75% of votes come back as
“yes”, then we go for a 10 day recirculation ballot.
j. Question - Whenever the editor is done, there will be a group of us within the task group to
look at the draft, then it will go to the 15 day ballot, and only then will we go to recirculation.
That’s the way it will go, right? Answer (Chair) - Yes.
k. Question - So, when you send this out, does the actual draft go with it? Answer - The draft
has to be posted.
l. Question - What if it is not approved? Answer – Then we have to go to Denver and fix it.
m. Comment - Then in Denver we shall have no comments to work.
n. Question - Does it make sense to do this at all, then? Answer - If we do this right, it
addresses all comments, and this is the best case with all included. We have reached the end
of our allotted time.
5. Meeting adjourned at 18:00.
Submission
page 18
Paul Gray, AirWave
November 2005
doc.: IEEE 802.11-05/1166r0
Report and Minutes of TGm
November 2005
DATE: November 2005
Author(s)
Name
Bob O’Hara
Company
Cisco
Systems
Address
3625 Cisco Way, San
Jose, CA 95134
Phone
email
+1 408 853 5513
bob.ohara@cisco.com
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in
this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE
Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement
"IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is
essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being
developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at < patcom@ieee.org>
Report and Minutes
Slide 1
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Abstract
Report and minutes of the meeting of TGm at the
November 2005 session.
Report and Minutes
Slide 2
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Goals for November 2005
• (Begin to) Process comments received on the opening
sponsor ballot
• Process any interpretation requests received
• Discuss and respond to FAA TSO inquiry
Report and Minutes
Slide 3
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Submissions
• Submissions
– 05/1167: Snapshot of sponsor ballot comments
Report and Minutes
Slide 4
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Proposed Agenda
• Consent agenda:
– Approve minutes and report from September 2005 meeting
• Review IEEE Patent Policy
• Review interpretation request procedure
• New business
– Submissions
– Process comments received to date from sponsor ballot
– Address FAA TSO inquiry
• Adjourn
Report and Minutes
Slide 5
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Motion #1 to adopt Agenda
• Moved: to adopt the agenda
• Mover: Andrew Myles, Ivan Oakes
• Passes: 3/0/0
Report and Minutes
Slide 6
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
IEEE-SA Standards Board Bylaws on Patents
in Standards
• http://standards.ieee.org/board/pat/pat-slideset.ppt
Report and Minutes
Slide 7
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Interpretation Procedure
•
•
•
•
http://standards.ieee.org/reading/ieee/interp/
Send email to Linda Gargiulo (l.gargiulo@ieee.org)
IEEE forwards requests to the WG
WG responds
Report and Minutes
Slide 8
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Processing of Sponsor Ballot Comments
• As a committee of the whole, the comments received to
date were discussed and proposed resolutions written
Report and Minutes
Slide 9
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Work Completed
Comments at start of session
0
Comments received during session
84
Total comments received
84
Comment resolutions written
75
Resolution writing completion
89.3%
Previously adopted resolutions
0
Comment resolutions adopted during session
0
Comment resolutions undone
0
Resolution adoption completion
Report and Minutes
Slide 10
0.0%
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Output Documents
• 05/1166r0: This report
• 05/1167: Snapshots (r0 through r3) of sponsor ballot
comments and resolutions
Report and Minutes
Slide 11
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Goals for January
• Complete processing comments received on the opening
sponsor ballot
• Initiate recirculation ballot
• Process any interpretation requests received
Report and Minutes
Slide 12
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Adjourn
• Meeting adjourned at 6:00pm on November 17, 2005
Report and Minutes
Slide 13
Bob O'Hara, Cisco Systems
November 2005
doc.: IEEE 802.11-05/1166r0
Attendees
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Andrew Myles
Ivan Oakes
Darwin Engwer
Mike Moreton
Jeremy Devries
Jeremy Kent
Ariel Sharon
Donald Eastlake
Adrian Stephens
Jon Rosdahl
Dorothy Stanley
Johnny Zweig
Tim Godfrey
Tom Maufer
Paul Gyugyi
Jan Kruys
David Leach
Dave Halasz
Peter Ecclesine
Report and Minutes
Slide 14
Bob O'Hara, Cisco Systems
November 2005
doc.:IEEE 802.11-05/1148r0
IEEE P802.11
Wireless LANs
[Minutes of High Throughput Task Group .11n Session]
Date: 2005-11-14
Author(s):
Name
Garth
Hillman
Company
Advanced
Micro Devices
Address
Phone
5204 East Ben White
Austin TX 78741
MS: 625
(512) 6027869
email
Garth.hillman
@amd.com
Abstract
Cumulative minutes of the High Throughput Task Group meetings held during
the IEEE 802.11 Plenary session in Vancouver from November 14 through 18,
2005. The session was chaired by TGn vice-chair Sheung Li from Atheros.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
Executive Summary (also see Chairs’ meeting doc 11-05-1154r2 and closing report doc. 1105-1228r0):
1. JP team gave a status update (process used, functions agreed to; remaining open
issues) in the following documents:
a. 11-05-1051r1 – JP Opening Report
b. 11-05-1160r0 – Advanced Coding Timeline
c. 11-05-1165r1 – MAC Details
d. 11-05-1161r0 – Phy Details
2. JP progress this week was stated in document 11-05-1221r1 and can be summarized
as “They are 75% complete and confident they will finish the baseline technical
proposal at the January Interim meeting.”
3. The current state of the baseline documents is contained in:
a. Phy – 11-05-1102r2
b. MAC – 11-05-1095r2
4. The mandate for the Joint Proposal Team was extended through the January
Interim Meeting
5. Goals for January meeting:
a. Comment on Baseline draft proposal
b. Hold Confirmation vote
c. Hold a Technical Editor election (assuming vote meets 75% threshold)
d. Issue call for Internal Review in prep for a March LB
Note: Relative to presentations, these minutes are intended to offer a brief summary
(including document number) of each of the presentations to facilitate review and recall
without having to read each of the presentations. Most of the ‘presentation related’ minutes
are built directly from selected slides and therefore are not subjective. An effort was made
to note obscure acronyms.
******************************************************************************
Detailed cumulative minutes follow:
Monday; November 14, 2005; 4:00 AM – 6:00 PM [~ 140 attendees]
1. Meeting was called to order by Task Group vice-chair person at 4:00PM
2. Chairs’ Meeting Doc 11-05-1154r1
3. Chair read IEEE-SA Standards Board Bylaws on Patent Policy and additional Pat Com
Guidance
4. Chair reviewed topics NOT to be discussed during the meeting – licensing, pricing, litigation,
market shared
5. Letters of Assurance (LOA) can be sent to Pat Com but details should not discussed here
6. Attendance reminder – for this meeting attendance will be manual (IEEE registration desk)
and on an honour system
7. Reminders:
7.1. Make sure your badges are visible especially when voting
7.2. No company logos on presentations
Submission
page 2
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
8. Chair reviewed Sept - Nov progress in order to provide the background to set the agenda for
this meeting:
8.1. Goal - draft to be available Nov. 7
8.2. JP should continue meeting ‘off-line’
8.3. Draft proposal was not available on Nov 7
9. Motion by Jon Rosdahl to approve Sept minutes, 11-05-0946r1, was seconded by Jim
Petranovich and approved unanimously
10. Chair proposed an agenda for this meeting (granted 12 hours total) as shown in the following
table:
Time
Monday
Tuesday
8:0010:00
X
MAC/PHY X
Wednesday
Thursday
Friday
X
Details
10:30- X
12:30
Not Used
X
JP Progress
Report;
Plans for
Jan
13:30- X
15:30
X
Not Used
TBD
16:00- Set
18:00 Agenda;
X
X
X
X
X
X
JP
Opening
19:30- X
21:30
11. Chair called for additional presentations:
11.1.
None
12. Chair asked for comments on the proposed agenda
13. Floor noted Doc 1051, 1060, 1061 and 1065 would fit well into Monday and first block on
Tuesday and that we could give back the 2nd Tuesday block and Wednesday block shown in
red above
14. Motion to approve modified agenda by Jim Petranovich and seconded by Jon Rosdahl
passed without objection
15. Presentation: 11-05-1051r1; Joint Proposal (JP) Opening Report introduced by Jon Rosdahl
15.1.
155 authors
15.2.
Phy status presented by Aon Mujtaba and Jim Petranovich
15.2.1. Items agreed upon prior to Den Haag
15.2.1.1. Convolutional Encoder – Mandatory
Submission
page 3
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
15.2.1.1.1. Generator polynomial (1338, 1718)
15.2.1.1.2. Rate = ½
15.2.1.2. Puncturing rates and patterns – Mandatory
15.2.1.2.1. Rate = 2/3, 3/4, and 5/6
15.2.1.3. Interleaver – Mandatory
15.2.1.3.1. Block based
15.2.1.3.2. One for each spatial stream
15.2.1.3.3. Spatial streams separated by frequency rotations
15.2.1.4. RF
15.2.1.4.1. 20MHz mandatory (64 point FFT)
15.2.1.4.2. 40MHz optional (128 point FFT)
15.2.1.5. MCS set – mandatory and optional equal modulation
15.2.1.5.1. 1 to 4 Spatial Streams
15.2.1.5.2. BPSK, QPSK, 16-QAM, and 64-QAM
15.2.1.5.3. Rate = 1/2, 2/3, 3/4, and 5/6
15.2.1.6. Long Mixed Mode Preamble
15.2.1.7. Pilots in 20 MHz
15.2.1.7.1. 4 pilot tones at -21, -7 , 7, 21
15.2.1.8. Number of Data Tones
15.2.1.8.1. 52 in 20 MHz
15.2.1.8.2. 108 in 40 MHz
15.2.2. Items Agreed to in Den Haag
15.2.2.1. Number of pilots in 40 MHz
15.2.2.1.1. 6 pilots in 40 MHz
15.2.2.1.2. Pilot location in 40 MHz TBD
15.2.2.2. Space Time Block Codes
15.2.2.2.1. STBC defined for
15.2.2.2.1.1.
2x1
15.2.2.2.1.2.
3x2
15.2.2.2.1.3.
4x2
15.2.2.2.1.4.
4x3
15.2.2.2.2. Mandatory or Optional is TBD
15.2.3. Items agreed to after Den Haag
15.2.3.1. Pilot location in 40MHz:
15.2.3.1.1. {±11, ±25, ±53}
15.2.3.2. Interleaver parameters:
15.2.3.2.1. Depth:
15.2.3.2.1.1.
20MHz: 13
15.2.3.2.1.2.
40MHz: 18
15.2.3.3. Frequency rotation:
15.2.3.3.1. 20MHz: 11
15.2.3.3.2. 40MHz: 29
15.2.3.4. OFDM processing for beam forming
15.2.3.4.1. QAM and antenna mappers
15.2.4. Work in Progress
15.2.4.1. Beam Forming
15.2.4.2. Rate feedback
15.2.4.3. Support for Single Spatial Stream devices
15.2.4.4. Short Preamble
Submission
page 4
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
15.2.4.5. Unequal MCS sets
15.2.4.6. 256 QAM
15.2.4.7. Parser
15.2.4.8. Antenna mapping
15.2.4.9. GI
15.2.4.10. Dual versus single encoder
15.2.5. Advanced Coding
15.2.5.1. LDPC Code Structure and Complexity Constraints passed.
15.2.6. Items yet to be considered in detail
15.2.6.1. None!!!!!!
15.3.
Matt Fischer presented the MAC status
15.3.1. Completed since Sept meeting
15.3.1.1. MSDU Aggregation
15.3.1.2. Power Save/Multi-poll (PSAD/MMP)
15.3.1.3. Reverse Direction Data Flow
15.3.2. Convergence Emerging
15.3.2.1. Block ACK
15.3.2.2. HT Control Field
15.3.2.3. EPP (Enhanced Phy Protection) or (PLCP length spoofing)
15.3.3. Under Discussion
15.3.3.1. Coexistence
15.3.3.2. PSDU Aggregation
15.3.3.3. EIFS
15.3.3.4. Link Adaptation
15.3.4. Yet to be Discussed
15.3.4.1. Capability Advertisement
15.3.4.2. Extended Range
15.4.
Next Steps
15.4.1. January Meeting for final JP
15.4.2. Confirm vote
15.4.3. Draft owned by TGn
15.5.
Questions can be emailed to authors at any time
16. Presentation: 1160r0; Advanced Coding Timeline by George Vlantis, Eric Jacobsen
16.1.
Status in Anaheim – agreed upon a code structure to generate codes except for the
sub-block code size which is dependent on the number of pilots (52 vs 54)
16.2.
Process to reach a decision was reviewed
16.3.
Reviewed the work of the team in detail over the last 4 months
16.4.
Resulting Code words adopted were presented
16.5.
This Weeks goal – reach decision on PPDU Encoding/Concatenation Rules
16.6.
Questions - none
17. Motion to recess for the day by Jim Petranovich and seconded by Jon Rosdahl passed
unanimously
18. Chair recessed the meeting at 5:46 PM until tomorrow morning at 8:00
Tuesday; November 15, 2005; 8:00 – 10:00 AM [~90 attendees]
1. Chair called the session to order at 8:05 AM
2. Presentation: 11-05-1165 r1; JP MAC Report by Adrian Stephens
Submission
page 5
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
a. Completed functions were discussed in detail (I added some comments not
included in the presentation)
i. MSDU Aggregation
1. units of A-MSDU reduces IRQs)
2. A-MSDU limits 3839 (4096-256-1) and 7935 (8192-256-1)
ii. Power Save Multi-poll
1. Mgt Action Frame
2. 8 B per station in PSMP sub-frame
3. PSMP followed by Down Link and Up Link packets
4. Start TX without reference to carrier sense
5. PSMP good for handsets
iii. Reverse Direction Data Flow
a. two STA operating together
b. reduces number of channel access attempts
c. Good benefit even for SS6 case
b. Questions:
i. None
3. Presentation: 11-05-1161r0; JP Phy Report
a. (Jim Petranovich) Agreed to functions:
i. Process used - Straw poll on abstract principals; votes on draft text
ii. Only Parser is “under discussion” (group parser or bit parser or hybrid)
iii. Mandatory - Vanilla SDM get us ~ 150 Mbps
iv. Optional – closed loop TX beam forming get ~ 600 Mbps
v. STBC – 2x1, 3x2, 4x2, 4x3; no feedback needed, good compromise
b. (Aon Mujtaba) To be Determined: [This is clearly a lesson in Engineering defined
as the art of making trade-offs !!!!] I tried to capture comments not included in the
presentation:
i. Beam Steering – big item; has MAC dependency
ii. 256 QAM and Asymmetric MCS are really part of the Beam Steering
decision
iii. Encoders/decoders (one or two) will be very complex at high data rates
(e.g., 600 Mbps)
iv. Bit wise parsing will not work if modulation is asymmetric
v. Group parsing works everywhere but it decreases performance on
symmetric modulation which is typical configuration
vi. 256 QAM discussion dominated by EVM (linearity) consideration
vii. Beam Steering dominated by –
1. format of sounding packet
2. feedback mechanism (implicit => reciprocity)
viii. Half GI – useful in channels with limited delay spread
ix. Short Mixed Mode Preamble – came out of the JP process
x. Greenfield and short preamble are orthogonal
xi. Imbalance of Eigen-channel S/N ratio should be taken advantage of
xii. Summary
1. resolution will depend on compromise rather than clear technical
evidence
c. Questions:
i. None
Submission
page 6
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
4. Motion to adjourn by Adrian Stephens and seconded by Jon Rosdahl passed
unanimously
5. Chair adjourned the session until Thursday at 10:33 AM
Thursday, November 17, 2005; 10:30 – 12:30 PM session [~150]
1. Chair called the session to order at 10:40
2. Presentation 11-05-1221 r0; JP Closing Report; Jon Rosdahl did intro
a. 155 co-authors
b. Progress reports
3. Phy Progress this week by Jim Petranovich
a. Mixed-mode Pre-amble definition
b. Adopted Modulation of HT-SIG
i. Q-BPSK
c. Adopted STBC as Optional
d. Items (Prioritized) Still Under Discussion
i. Beam Forming
ii. Rate feedback
iii. Support for Single Spatial Stream devices
iv. Short Preamble
v. 256 QAM
vi. Unequal MCS sets
vii. Parser
viii. Antenna mapping
ix. GI
x. Dual versus single encoder
e. 11-05-1102r2 Joint Proposal PHY specification has been posted to
802wirelessworld.
i. Sean Coffey – PHY Editor
ii. 30 pages
iii. Approximately 75% complete
4. Advanced Coding Milestones by George Vlantis
a. LDPC Code design phase completed 19 Oct 2005.
b. IEEE Fading Channel results completed 02 Nov 2005.
c. Final LDPC Code selection completed 09 Nov 2005.
d. Formal Motion on LDPC Code to ballot 23 Nov 2005.
e. PDU Concatenation Rules to complete 23 Nov 2005 in Vancouver.
f. Formal motion on PDU Concatenation Rules to ballot on 30 Nov 2005.
5. MAC Progress this week by Adrian Stephens
a. Convergence emerging
i. EPP (PLCP length spoofing)
1. Close to a ballot
ii. HT Control field
1. Signaling for several HT features
2. Consensus in principle has been established
3. Straw polls ongoing to determine format/signaling
iii. Coexistence
1. Draft Text Reviewed. Close to ballot.
Submission
page 7
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
b. Under Discussion
i. Rate feedback (link adaptation)
1. Cross MAC/PHY team continues to work
2. Draft Text from sub-team reviewed/modified, ready for balloting
ii. EIFS
1. Issues identified in presentation from sub-group to larger MAC
body
2. Impact of these issues still being worked through
iii. Capabilities advertisement
c. 11-05/1095r2 Joint Proposal MAC Specification has been posted to
802wirelessworld
i. Adrian Stephens – MAC editor
ii. 37 pages
iii. Approximately 75% complete
6. Summary by Jon Rosdahl
a. Good Progress
b. Good Compromise
c. Resolved to be Complete by January Interim meeting, 2006
7. Motion by Jon Rosdahl to continue the time for the JP to complete the merger of
MITMOT, TGn Sync and WWiSE proposals until Jan Meeting 2006 was seconded
by Jim Petranovich
a. Discussion
i. When relative to January meeting? A – don’t want to commit
ii. Should have doc early in week and schedule confirm vote later in the
week
8. Motion for friendly amendment to include a date in the motion as ‘through the end
of the 802.11 interim session’ by Dave Bagby was accepted
a. Discussion
i. Does this mean there will NOT be a confirmation vote in January? A – no,
it is only a contingency action
ii. Confirmation vote is very likely in January
iii. Specification should be delivered to the TG at the start of the meeting
regardless of its state of completeness
iv. JP feels it will continue between now and well before the next meeting;
guarantees there will be a spec BEFORE the next meeting and some
adjustment may be made during the early part of the January meeting.
9. Motion as amended passed (134,0,0)
10. Other motions? No
11. Status update of .19
a. .19 met for 1 day to discussion impact on .11k and .16h
b. Methodology doc number is 19-05-022
c. .19 voted to create SG to produce PAR and 5C for a recommended practice on
CA
12. Any need for Conference Calls between now and March? A – no
13. Discussion
a. Chair said Editors don’t need special authorization to work on spec
b. CA needed for WG LB but not for TG Review so would not need CCs
c. So no CCs needed since there will not be a formal WG LB authorized in Jan
14. .11 Timeline
Submission
page 8
Garth Hillman, Advanced Micro Devices
November 2005
doc.:IEEE 802.11-05/1148r0
a. As of Monday Official Timeline said a WG LB in January but this does not seem
likely so will change timeline for first LB to March, 2006
b. We will hold a TG Review of baseline text between Jan and March
15. Confirmation vote on Tech Proposal will be held in Jan
16. Editor will be elected assuming a 75% approval Confirmation Vote
17. Editors will then create a draft amendment AFTER the January meeting. The editors job
will be to add all the editorial directions so that the amendment can be added to the
standard
18. Discussion:
a. So what level of detail will the Tech Spec have? A – all the tech details but not
the editorial directions; tech spec is part of a package that meets the requirements
doc.
b. OK so when should the Tech spec doc be posted on server? A – JP said a
document would be available on the server 7 days before the January meeting
c. Note: It would be advantageous that the draft from the editors be available early
in the Jan-March period so TG comments can be received and resolved in the
March meeting with the goal being to take the draft to a 1.0 level and ask the WG
for a LB at the end of the March meeting. This is admittedly aggressive
d. Recall that a CA must accompany the first LB draft so this will be very difficult to
accomplish in January even if the baseline doc was ready
e. The Requirements doc stands as the doc against which the Tech Spec proposal
will be measured
19. Any other business? No
20. The closing report number will be 11-05-1228r0
21. Motion to adjourn by Chris Hansen was seconded by Adrian Stephens and passed
unanimously
22. Chair adjourned the meeting at 12:07 PM
Submission
page 9
Garth Hillman, Advanced Micro Devices
November 2005
doc.: IEEE 802.11-05/1229r0
IEEE P802.11
Wireless LANs
November 2005 TGp/WAVE Minutes
Date: 17 November 2005
Author(s):
Name
Filip Weytjens
Company
TransCore
Address
8600 Jefferson Street NE
87113, Albuquerque, NM
Phone
email
+1 (505) 856-8145
filip.weytjens@transcore.com
Abstract
This document includes the meeting minutes for the IEEE 802.11 WAVE Task Group held in
Vancouver, BC, from November 14th to 18th, 2005, under the TG Chairmanship of Lee Armstrong of
Armstrong Consulting and editor Wayne Fisher of ARINC. Minutes were taken by Filip Weytjens of
TransCore.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Filip Weytjens, TransCore
November 2005
doc.: IEEE 802.11-05/1229r0
Tuesday November 14, 2005, 10:30 AM Session
Lee Armstrong chair of the TGp working group opened the meeting at 10:30AM.
The policies, rules, and objectives were presented to the working group including IEEE-SA Standards
board bylaws on patents, inappropriate topics and meeting etiquette.
Lee discussed the agenda and requested whether the agenda was acceptable as submitted to the server.
The working group approved the agenda. The primary objectives are to resolve the comments and get
ready for ballot. The minutes of the September meeting were approved and it was agreed to move the
discussion on the action items to the afternoon session.
Mary Ann Ingram (Georgia Institute of Technology) presented the presentation “WAVE Motion-Related
Channel Model Development” (doc.: IEEE 802.11-05/1176r0). The modelling approach was discussed,
the results of an example express way model, how BER measurements can be used to validate the model,
and the generation of the channel emulator based on the measurement results.
Over the last two months it was challenged whether the modifications to the document were made without
going through the formal process. It was shown that all changes were made according to IEEE procedures
and this controversy has been closed.
The meeting was recessed at 11:50AM.
Tuesday November 15, 2005, 4:00 PM Session
Lee Armstrong chair of the TGp working group convened the session at 4:00 PM.
Tom Kurihara discussed the liaison with 1609 and 1556. In 1609 there are 4 standards in final stages of
approval. It is expected that sponsor ballot ends in December. If comments are addressed between end
December 05 and end of January 06, the draft should be available for Ref Com approval at the end of
February. There will be maintenance on the standards till the end of March. The March drafts will be
updated with input from the prototype development. Lee stated that IEEE 1556 became IEEE 1609.2.
For ISO TC 204/16 (Calm M5) a draft was distributed for review.
The meeting minutes for the September meeting were discussed including following action items.
ACTION # 19, 20 & 21: Measurements explanation asked from Koga – Broady Cash
Background: It was questioned which information was used to derive the requirement for the adjacent
channel rejection, Minimum sensitivity, and Alternate adjacent channel rejection in table 20.3.10.1.1.
Same question came up for sections 20.3.10.3 to 9. It was mentioned that measurements were performed
and that calculations showed that this requirement could be met. It was decided that the available
documentation will be made available and will be discussed off-line. A list will be developed on which
tests need to be performed in order to verify the requirements. The list will be presented next meeting.
Open: The information has been released but they still have restricted lettering. This is being resolved.
ACTION # 34: Provide test clause comments from OmniAir “Device Certification” perspective – Randy
Roebuck
open
Submission
page 2
Filip Weytjens, TransCore
November 2005
doc.: IEEE 802.11-05/1229r0
ACTION # 40: Richard Noens and Randy Roebuck to get together to submit new comments on test
parameters in clause 20.3.10. – Randy Roebuck, Richard Noens
Open
ACTION # 41: A definition will be provided for message stream and safety message. – Scott Andrews
Closed, Overtaken by events
ACTION # 42: Provide, as part of the liaison with TC204, additional information that will be included in
the WAVE Announcement action frame for Calm (V2V communications). (Knut Evensen)
Open
ACTION #43: Resolve comment nr 8 raised by Wayne Fisher. (Wayne Fisher)
Deferred
ACTION #44: The naming convention such as for “DSRC device” and “WAVE device” needs to be
reviewed. (Knut, Broady)
Closed
ACTION #45:Comment Bobs/9 needs to be reviewed off-line. (BobS, Justin)
Closed
ACTION #46: A conference call will be setup to discuss the differences between a BSS, IBSS, and
WBSS. (Lee)
Closed
ACTION #47: Additional information will be provided in the standard to address the difference between
a BSS, IBSS, and WBSS. (Justin)
Closed
ACTION #48: A format is required for the solution that will be generated by Mary Ann for the channel
model. The channel format must be provided in such a form that the requirements can be verified. (Dick,
BobS, Koga)
Closed
Wayne Fisher proceeded with the discussion on the comments that were submitted for P802.11p D0.24.
The resolution of the comments were documented in doc.: IEEE 802.11-05/0954.
Wayne discussed each of the comments. Modifications were made during the meeting directly to the draft
standard or the comment sheet.
The question was raised whether the 802.11p MIB compiled. Since the original 802.11 MIB does not
compile, the 802.11p doesn’t compile either, as it cannot be used standalone.
The group accepted the modifications to Carl Kain/1-12 as discussed and document during this session.
These comments are closed.
Submission
page 3
Filip Weytjens, TransCore
November 2005
doc.: IEEE 802.11-05/1229r0
The group accepted the modifications to Scott Andrews/1-7 as discussed and documented during the
session. These comments are closed.
The meeting was adjourned at 6:05PM.
Wednesday November 16, 2005, 8:00 AM Session
Lee Armstrong chair of the TGp working group started the session at 8:00 AM.
Wayne Fisher continued with the resolution of the comments following document 11-05-1181-00-000pP802.11p_d0.24_Comments.xls.
The group accepted the resolution of Soranno Robert/1- 24 as discussed and documented during the
session. These comments are either closed or deferred.
ACTION #49: Justin/Jason will review the 11ma document to look for potential conflicts with the
802.11p document.
The meeting was adjourned at 10:00 AM.
Thursday November 17, 2005, 8:00 AM Session
Lee Armstrong chair of the TGp working group started the session at 8:00 AM.
Wayne Fisher continued with the resolution of the comments following document 11-05-1181-00-000pP802.11p_d0.24_Comments.xls.
ACTION #50: Bob Soranno to clarify Soranno Rober/25.
The meeting was recessed at 10:00 AM.
Thursday November 17, 2005, 10:30 AM Session
Lee Armstrong chair of the TGp working group convened the session at 10:30 PM.
Wayne Fisher continued with the resolution of the comments following document 11-05-1181-00-000pP802.11p_d0.24_Comments.xls.
There was a long discussion on section 20.3.10.6 “WAVE Performance in vehicular environments”. It
was decided that the channel model (doc.: 11-05-1178-00-000p-wavechanmodel.doc) would be included
in an annex (Annex L).
Straw poll vote on the following proposed language for section 20.3.10.6:
1) WAVE stations shall be capable of operating in accordance with the channel model as defined in
Annex L. The packet error rates shall be less than 10 % for 1000 octet PSDUs for the mandatory
data rates.
2) Stations using WAVE functions are capable of operating in a mobile vehicular environment. The
WAVE mobile environment imposes a continuously varying degree of multi-path propagation
comprising both slow and fast fading, amplitude variations and signal drop-outs as vehicles
traverse through rural, highway, suburban, and city environments. Mandatory requirements,
Submission
page 4
Filip Weytjens, TransCore
November 2005
doc.: IEEE 802.11-05/1229r0
determined through actual data collection and validated modeling are defined in Annex L which
prescribe the number of taps, and for each tap, a specified excess delay, a power-density spectrum
(with a certain maximum Doppler shift), and a Rician channel K-factor, for data rates of 3, 6 and
12 Mbps. For all of these cases, success shall be determined by a packet error rate of < = 10% for
the specified packet length. For this verification the input level shall be 10 dB above the receiver
sensitivity as specified in Table p8.
Results: 7 in favour of proposal 1, 9 in favour of proposal 2
Following up on the result of the straw poll the action item was taken by Lee to integrate the two
proposals and bring the result back for discussion within the task group.
ACTION #51: Lee to integrate the two proposals and bring the result back for discussion within the task
group.
It was requested to delete annex K.6 “WAVE Control Channel congestion”. It was agreed that instead of
deleting, new language would be proposed to be included in the standard.
ACTION #52: Lothar to come up with suggested wording for WAVE Control Channel congestion.
A motion will be presented during the plenary for a teleconference call starting December 13. This
teleconference call will take place every Tuesday @ 12:00 EST till the January IEEE meeting. Additional
information will be made available before the conference call.
The group accepted the resolution of Soranno Robert/26 - 36 as discussed and documented during the
session. These comments are either closed or deferred.
It was mentioned that only modifications would be made to the .24 draft document, which are a result of
closed comments. It was voted on accepted the comments as they were discussed and resolved during this
IEEE meeting. (Favour: 24, Abstain: 0, Against: 0)
The sheet with the resolved comments will be posted to the server as revision 1.
New draft will be available on December 1st. Comments need to be back to Wayne Fisher by January 6.
The meeting was adjourned at 12:30 PM.
Open action items from previous meetings:
ACTION # 19, 20 & 21: Measurements explanation asked from Koga – Broady Cash
Background: It was questioned which information was used to derive the requirement for the adjacent
channel rejection, Minimum sensitivity, and Alternate adjacent channel rejection in table 20.3.10.1.1.
Same question came up for sections 20.3.10.3 to 9. It was mentioned that measurements were performed
and that calculations showed that this requirement could be met. It was decided that the available
documentation will be made available and will be discussed off-line. A list will be developed on which
tests need to be performed in order to verify the requirements. The list will be presented next meeting.
Open: The information has been released but they still have restricted lettering. This is being resolved.
ACTION # 34: Provide test clause comments from OmniAir “Device Certification” perspective – Randy
Roebuck
open
Submission
page 5
Filip Weytjens, TransCore
November 2005
doc.: IEEE 802.11-05/1229r0
ACTION # 40: Richard Noens and Randy Roebuck to get together to submit new comments on test
parameters in clause 20.3.10. – (Randy Roebuck, Richard Noens)
Open
ACTION # 42: Provide, as part of the liaison with TC204, additional information that will be included in
the WAVE Announcement action frame for Calm (V2V communications). (Knut Evensen)
Open
New action items:
ACTION #49: Document .11ma will be reviewed for potential conflicts with the .11p document including
sections 11.7 (.11p) and 11.1.3 (.11ma). (Justin/Jason)
ACTION #50: Bob Soranno to clarify Soranno Rober/25.
ACTION #51: Lee to integrate the two proposals and bring the result back for discussion within the task
group.
ACTION #52: Lothar to come up with suggested wording for WAVE Control Channel congestion.
Submission
page 6
Filip Weytjens, TransCore
November 2005
doc.: IEEE 802.11-05/1112r1
IEEE P802.11
Wireless LANs
TGr Meeting Minutes November 2005 Session
Date: 2005-11-18
Author(s):
Name
Michael
Montemurro
Company
Chantry
Networks
Address
Phone
1900 Minnesota Cr, Suite 125.
Mississauga, ON. L5N 3C9
905-363-6413
email
michael.montemurro@siemens.com
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
Tuesday November 15, 2005
8:00am
•
•
•
•
•
•
•
•
•
Call to order
Agenda – document 11-05/1111r1
Review operating rules for a Task Group.
Review IEEE 802 policies and procedures for Intellectual Property.
Approve minutes from the September session – document 11-05/899r0
• Minutes are approved unanimously.
Approve minutes from the Teleconference sessions – document 11-05/1038r2
• Minutes are approved unanimously.
Discussion on Agenda – document 11-05/1111r1
• Revised agenda will be updated as document 11-05/1111r2
Presentation of TGr draft 0.09 by Bill Marshall
Discussion of document 11-05/1037r8 by Bill Marshall
• No discussion.
MOTION: To accept the comment resolutions highlighted in yellow in document 11-05/1037r8
and instruct the editor to incorporate them into the draft.
By: Bill Marshall
Second: Michael Montemurro
Discussion:
• None.
Result: 18 – Yes; 0 – No; 1 – Abstain. Motion Passes.
MOTION: Instruct the editor to change all occurrences of “AP1” to “Current TAP” and “AP2”
to “Target TAP” in figures 121c, 121d, 121e, 121f, and 121h.
By: Kapil Sood
Second: Nancy Cam-Winget
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion of document 11-05/1048r1 by Michael Montemurro
• None.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1048r1 into the
draft.
By: Michael Montemurro
Second: Bill Marshall
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion of document 11-05/1099r0 by Nancy Cam-Winget
• The IETF is replacing the term “AAA key” to MSK. We should craft a motion later in the
meeting to replace the occurrences of “AAA key” with MSK.
Submission
page 2
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
MOTION: Instruct the editor to incorporate the changes from document 11-05/1099r0 into the
draft.
By: Nancy Cam-Winget
Second: Timothy Wong
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion of document 11-05/1116r0 by Nancy Cam-Winget
• We should eliminate the term NAS from the TGr draft. We would need to craft another
motion to eliminate the NAS from the TGr draft.
• The term NAS means nothing in IEEE 802.11. It is used much too liberally in the TGr
draft.
• The NAS term is used in many places in the document. Another submission would have
to address the use of the term in the draft.
• We should change the use of NAS in this document to R0KH-ID
• There are two independent changes in this document: the clarification on key holder IE
and the removal of the R1KH-ID.
• Discussion on the removal of the R1KeyHolder ID from the FTIE:
• We have three entities: R0KeyHolder, R1KeyHolder, and AAA Server. This looks to
be a three-party protocol. We should define an 802.11 protocol that supports the
components.
• We should not move the R1KeyHolder ID from the FTIE. By removing it, we remove
the ability of a TSTA to decide whether it is possible to transition to that target TAP.
• If we define keys, we should be managing them. The only key that the IETF defines
is the top level key.
• An extension to the IETF protocols could address the multiple level key hierarchies.
• We currently don’t have any binding to the key holder IE’s. The R1 Key Holder IE
does not need to be named.
• We should provide a solution to address how future EAP versions will work with TGr
in the future.
• TGr constructed a key hierarchy that is based on one piece of key material in the EAP
authentication.
• If we are using the MSK, we need to be consistent to ensure that we are using EAP
properly.
• The draft should be reviewed by external experts to ensure that we are using EAP
correctly.
• If the Authenticator is split between multiple boxes, then there is no way for the STA
to authenticate the authenticator.
• The IETF will not address keying hierarchy specified by TGr.
• The obligation of TGr is to define a clean interface to EAP, which will preserve TGr
mechanisms as EAP changes.
• There may be a benefit to advertising the physical topology by including the
R1KeyHolder.
• Submission 11-05/555r0 suggested that there are at least 4 architectures that could
support this key hierarchy. This submission implies that there is really only one key
hierarchy.
Submission
page 3
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
•
•
We should be defining requirements based on our key hierarchy and passing them on
to the IETF.
• The R1KeyID is required to authenticate both the R0Key holder and the R1Key
holder.
• The key derivations are dependent on the Key Holder IE’s. They need to be
advertised so that the STA can derive keys.
• The R1KeyID is not an NAS ID, only R0KeyID is a NAS ID
• The R1KeyID it is a logical entity.
• From the R0 standpoint, whoever got the R0 had to do 802.1x authentication. The R1
is a TGr construct. We have defined naming conventions and protocols to address the
R0 and R1 keys in the TGr draft.
• This concept should be taken offline and addressed by another submission.
• We need to clarify the definition for the R0KeyID and R1KeyID.
Discussion about the clarification on the R0KeyHolder IE:
• The mobility domain IE should be able to replace the need for the R0KeyHolder IE.
AP’s could advertise the same mobility domain IE but different KeyHolder IE’s.
• If the AP advertises the mobility domain IE, it can get to the R0KeyHolder IE.
• If we don’t advertise the R0KeyHolder ID’s, the STA cannot roam. The STA will
need to probe or beacon before it roams.
• This change takes an explicit construct and makes it an implicit construct.
• By addressing the problem in this manner, we can elminiate configuration issues.
• The mobility domain was introduced to identify potential roaming candidates to ta
TAP and guarantees reachability of TAP within the domain.
• Removing the KeyHolder IE could affect the delivery of keys in the infrastructure.
• The implication of this approach is that key delivery may be guaranteed.
• The implicit naming is less flexible. However this particular part of the amendment
does not require flexibility.
MOTION: To instruct the editor to incorporate the proposed comment resolutions for 324, 330,
333, 336, and 337, from document 11-05/1037r8 into the draft.
By: Nancy Cam-Winget
Second: Michael Montemurro
Discussion:
• None.
Result: Motion passes unanimously.
•
Discussion removal of clause 5.4.5.2 by Michael Montemurro
• We decided on the conference call that if someone wants to preserve it, they should
provide new text.
• No text has been proposed.
MOTION: Remove section 5.4.5.2 from the draft and renumber the following sections
appropriately.
By: Michael Montemurro
Second: Kapil Sood
Discussion:
• The information in 5.4.5.2 describes problems with the current standard. This text
should not appear in the TGr amendment.
Submission
page 4
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
• The text really describes the problem statement.
• We should not leave this text in the draft if it is irrelevant.
Result: 16 – Yes; 0 – No; 12 – Abstain.
•
Recess until the 1:30pm session.
Submission
page 5
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
Tuesday November 15, 2005
1:30 pm
•
•
Call to order
Discussion on document 11-05/957r0 by Michael Montemurro
• If a clause is Mandatory, then all content of that clause is mandatory
• QoS should be dependent on IEEE 802.11e (CF12)
• This is a first cut of the PICS, and all items are subject to change.
• Change CF12 needs to be changed to CF13
• The QoS procedures need to be classified as mandatory to implement.
• The base fast transitioning mechanism is optional. If an implementor decides to
implement FT, then they have to implement all mandatory elements of FT.
• The reservation mechanism should be optional to use, but mandatory to implement for an
AP.
• The PICS deals with implementation, not use. All compliant implementations should
meet the mandatory PICS requirements.
• Pre-reservation should be optional. It should not be mandatory on AP and optional on
TSTA. The FTIE can advertise the options, if the pre-reservation has been implemented.
• Motion to be done tomorrow based on document 11-05/957r1.
•
Discussion on document 11-05/1184r0 by Jon Edney
• The restructuring is good, but information was missing when the draft was restructured.
• The text is missing the third error condition where there is a policy violation.
• Pg 60, section 8A.5 discusses the MLME primitives that are called when the resources
are provisioned in the MAC.
• Section 8A.5.6.1, the “shall” should be changed to “may”
• The conditional “shall” should not be a “may”
• The purpose of the RIC was to replace a series of ADDTS requests after re-association.
• This text change is fine as long as you make sure that the flowchart is consistent.
MOTION: To instruct the editor to incorporate the text from document 11-05/1046r0, with the
2nd paragraph of 8A.4.5.1 replaced with the following text: “In generating the RD information
element for a Traffic Stream, if the TS is a downstream flow then the RD may also include one
or more TCLAS object(s) (defined in section 11e 7.3.2.16), and (if multiple TCLAS objects are
included) a TCLAS Processing object (defined in section 11e 7.3.2.18).”
By: Jon Edney
Second: Bill Marshall
Discussion:
• none
Result: Motion passes unanimously.
•
Discussion on document 11-05/1097r0 by Nancy Cam-Winget
• Does that mean that we are requiring implementations to compute the MIC in the
hardware/lower MAC level?
• We are implying that the header information needs to be conveyed to the supplicant.
• We now need to send the information in the EAPKIE as well as the frame header.
• The IE’s before the count IE would not be included in the MIC
Submission
page 6
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
MOTION: Instruct the editor to incorporate the changes from document 11-05/1098r0 into the
draft.
By: Nancy Cam-Winget
Second: Kapil Sood.
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion of document 11-05/884r1 by Kapil Sood.
• The authentication using PSK for TGr is consistent with 802.11i.
• The use of the term “authentication” in the proposed text should be clarified.
• The term XXKey is confusing.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1054r1 into the
draft, deleting the first sentence of the first paragraph, and changing the second sentence of the
first paragraph, so that the sentence says “The Fast BSS-Transition key hierarchty can be used
with either IEEE 802.1X EAP authentication or PSK.”
By: Kapil Sood
Second: Bill Marshall
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion on fast transition back to the same AP
• What is the situation under which this happens?
• Devices do this to change their association parameters. You could explicitly prohibit this
operation.
• The usage scenarios between TGw and TGr are different.
• In the TGw document, un-protected re-associations were not allowed.
• A fast transition to the same AP requires that you go back to the FT-Auth state.
• We do not have text in the draft to explicitly state that the port is closed until the Auth
completes.
• One of the submissions that we have today, we say that the port is opened at the reassociation response.
• When you transition to the next AP, the port is blocked. The port is only opened after reassociation is complete.
• The port has to be blocked while the PTK is negotiated.
• If the port is opened and the FT fails, does that mean that the port is closed.
• The simple solution is to say that once you send the “FT Auth Request”, the port is
blocked.
• When you initiate the FT, you block the port.
•
Discussion about a request assigned numbers from the ANA
• We should not request the numbers now; otherwise they may need to be blocked in future
as the TGr amendment evolves.
• We should request the assigned numbers from the ANA at the last moment.
Submission
page 7
Michael Montemurro, Chantry Networks
November 2005
•
doc.: IEEE 802.11-05/1112r1
At the editors meeting, TGr was going to be following TGk and TGp. As a result, it looks at
though TGr will preceed TGp. The TGr draft will have to be updated to reflect this.
MOTION: Instruct the technical editor to produce the new draft incorporating the changes that
have been accepted by the Task Group.
By: Bill Marshall
Second: Dorothy Stanley
Discussion:
• None.
Result: 14 – Yes; 0 – No; 1 – Abstain.
•
•
Discussion on the “To-Do List” – Document 11-05/853r9
• The “To-Do List” document will be updated as Document 11-05/853r10
Recess until the Wednesday 8am session.
Submission
page 8
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
Wednesday November 16, 2005
8:00 am
•
•
Call to order
Presentation of document 11-05/1185r0 by Kapil Sood
• None.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1185r0 into the
draft, changing the mib variable names as necessary.
By: Kapil Sood
Second: Nancy Cam-Winget.
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Presentation of document 11-05/1195r0 by Kapil Sood
• None.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1195r0 into the
draft.
By: Kapil Sood
Second: Bill Marshall
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Presentation of document 11-05/1199r0 by Rajneesh Kumar
• The text to describing how MLME primitives are used in QoS procedures was
inconsistent with the MLME primitives themselves. This text clarifies the QoS
procedures.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1199r0 into the
draft.
By: Rajneesh Kumar
Second: Bill Marshall
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Presentation of document 11-05/957r1 by Michael Montemurro
• The “TBD” should be updated because there is now text to describe the TGr mechanism
for PSK. The clause should be 8.5A.4.
Submission
page 9
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
MOTION: Instruct the editor to incorporate the changes from document 11-05/957r1 into the
draft, changing “TBD” to “8.5A.4”.
By: Michael Montemurro
Second: Bill Marshall
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Presentation of document 11-05/1089r1 by Jon Edney
• When the STA is not in PS-mode, the AP would indicate that there are frames waiting.
The STA could use that information to influence when the STA would BSS-Transition.
• This proposal introduces race conditions that would occur depending on whether or not
the STA is or is not powersave mode.
• Often a STA will roam when there is degradation in link quality. This could influence the
STA to postpone Fast Transitiion even though the link quality is poor.
• If your link quality is poor, you should fast transition earlier.
• This bit would have to be in use continuously at the AP. The STA would start observing
the bit prior to BSS-Transition.
• The AP knows when to set the bit to 0 – when there were no packets buffered for a STA.
• This bit will be set depending on the size of the buffer on the AP.
• If frames are coming in every 10ms, there are no issues. This really proposal addresses
traffic burst.
• The probability of the STA losing packets is no different regardless of whether the “more
data” bit is set, because the STA would not know the scheduling of the traffic.
• When the STA goes back to active mode after PS, how does it know when to stop the PSPolling? After the next beacon? The STA only uses PS-Poll when it is in power-save
mode.
• The STA has to make a decision whether the “more data” bit is set. In some cases it could
be helpful if the AP knows the traffic pattern.
• The “more data” bit is set by the AP when there is more than one packet buffered for the
STA.
• This “more data” bit could be weighed into the transition algorithm on the STA.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1091r0 into the
draft.
By: Jon Edney
Second: Guenter Kleindl
Discussion:
• This would be better handled at a higher level where a switch could indicate that there
is data waiting for the STA.
• This solution would not be useful when there is congestion because the “more data”
bit would always be set.
• In the case when there is bursty traffic because the STA does not know the traffic is
scheduled to arrive.
• This proposal would change the bias of the STA in deciding when to roam.
• For some traffic patterns it will work; for others it won’t.
Submission
page 10
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
•
There has been a set of rules defined by IEEE 802.11e to interpret the “more data”
bit. In IEEE 802.11e, the bit was only set when the STA was in a PS mode. This
proposal only affects behavior when the bit is active mode.
• In IEEE 802.11e, there are triggers that are defined based on Access Categories. The
usage of the “more data” bit could conflict with some PS modes as defined by IEEE
802.11e.
• When the STA goes out of PS-mode, it transmits a frame with the PS-bit to indicate
that it has become active.
• There was quite a bit of discussion in IEEE 802.11e. TGr needs to ensure that the
“more data” bit rules in this proposal do not affect the behaviour defined by IEEE
802.11e.
• This is a clever way of improving transition algorithms. This is an opportunity for
innovation.
CALL THE QUESTION: 6 – Yes; 2 – No. The question is called.
Result: 11 – Yes; 6 – No; 3 - Abstain. Motion Fails.
•
Presentation of document 11-05/1105r0 by Jon Edney
• The RTT/CTT frame transmissions occur prior to re-association.
• The data frames at the new AP would need to be buffered. This buffering behaviour may
be linked to the re-association deadline.
• These messages need to be added to the FT mechanism because they need to occur just
prior to transition.
• If older frames trickle in, the AP would just drop the frames.
• The old AP would have to monitor frames and traffic.
• It would be nice to roll these concepts into the existing messages.
• How does the AP know when to signal the STA that it should move?
• The STA does not transmit data during this period, it would only receive data. The STA
does not send data frames after it sends an RTT.
• There have not been any detailed simulations to quantify the performance improvements.
It would help to support this proposal.
• Once the STA issues the RTT to an AP, it then must transition to that AP.
• This proposed mechanism does not require channel switches.
• The target TAP should not send the CTT until the DS has been updated. Unfortunately,
we cannot specify what goes on in the DS.
• This mechanism occurs at the beginning of the re-association process, rather than the end
of the reservation process.
• If the STA does not receive the CTT, it would still complete the transition. When the
STA issues the RTT, it sets a timer. When the timer expires without receiving the CTT,
the STA would complete the re-association.
• The spirit of the proposal is good.
• You would need to update the replay counters to maintain security.
• A quantification of the performance gain would support this proposal.
STRAW-POLL: Does the group believe that this type of approach is of value to TGr?
Result: 22 – Yes; 0 – No;
•
Discussion of document 11-05/1190r0 by Frank Ciotti
• The ResourceRequestLimit is applied on a STA per STA basis, not on a BSS basis.
Submission
page 11
Michael Montemurro, Chantry Networks
November 2005
•
doc.: IEEE 802.11-05/1112r1
• The dot11ResourceRequestTimeout should be expressed in TU’s as a unsigned32
Recess until the 4pm session.
Submission
page 12
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
Wednesday November 16, 2005
4:00 pm
•
•
Call to order.
Discussion of document 11-05/1204r0 by Kapil Sood
• The statement “Replace the following on page 36, line 30 with the following” is
ambiguous. The intention is to replace the PMK-R0 and R0Name derivation with those
defined in this submission.
• This Clause numbers are missing with this submission. However the editor has agreed
that he can work with the submission as it is.
• The MD-ID should be added to the acronym definition clause.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1204r0 into the
draft.
By: Kapil Sood
Second: Michael Montemurro
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion on document 11-05/1190r1 by Frank Ciotti
• None.
MOTION: Instruct the editor to incorporate the changes from document 11-05/1190r1 into the
draft, where on dot11Compliance the changes to make the element dot11SMTbase6, and in the
description of the dot11SMTbase6 should begin “The SMTbase6 object…”
By: Frank Ciotti
Second: Nancy Cam-Winget
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion on document 11-05/1210r0 by Bill Marshall
• It wasn’t clear that the messages applied to the same key.
• The key lifetime in the text was bound to the lifetime of the PTK.
• We need some performance study to determine the default values of
dot11RemoteRequestTimeout and dot11RemoteRequestLimit.
• The dot11RemoteRequestTimeout should be expressed in TU’s.
MOTION: Instruct the editor to incorporate the resolutions given in document 11-05/1210r0 into
the draft, changing the default on slide 8 to “dot11RemoteRequestTimeout = 2000 TU’s”, and
the section number on slide 6 to 8.5.2.
By: Bill Marhsall
Second: Kapil Sood
Discussion:
• None.
Result: Motion Passes Unanimously.
Submission
page 13
Michael Montemurro, Chantry Networks
November 2005
•
doc.: IEEE 802.11-05/1112r1
Discussion on the “AAA key” term
• We discussed changing the term “AAA key” to “MSK” this week.
• We are using the “AAA key” as a variable, why does the term have to be the same.
• The “AAA key” has been removed from the EAP document and replaced by “MSK”.
• The term “MSK” appears in IEEE 802.11i once. The “AAA key” is used throughout the
IEEE 802.11i draft.
• The changes to the base standard will be done through sponsor ballot comments to the
IEEE 802.11ma draft.
MOTION: Instruct the editor to replace the instance of “AAA key” to “MSK” in the TGr draft.
By: Nancy Cam-Winget
Second: Bernard Aboba
Discussion:
• None.
Result: Motion Passes Unanimously.
•
Discussion on some inconsistencies in the PMK-R1 definition in the draft
• Bullet 2 of 8.5A.2 on line 1 of draft 0.10 is inconsistent. The PMK-R1 is derived from
PMK-R0.
MOTION: To change in 8.5A.2 first paragraph, bullet item 2, “R1 Key holder, R1KH”, to “R0
Key Holder, R0KH”, and delete from the three bullet items the naming of the keys.
By: Frank Ciotti
Second: Kapil Sood
Discussion:
• None.
Result: Motion Passes Unanimously.
•
•
•
•
The following motion will produce the next draft, which should be labelled draft 0.11.
The change history can be left in the draft as an editor’s comment.
We have not added any new references, but we may need to reference something in the
future.
The neighbour report clause will be left in – but will not include proposed text at this time.
MOTION: Instruct the technical editor to produce a new draft incorporating the changes that
have been accepted by the Task Group.
By: Michael Montemurro
Second: Jesse Walker
Discussion:
• None.
Result: 21 – Yes; 0 – No; 0 – Abstain.
•
Discussion of document 11-05/1216r0 by Dorothy Stanley
• TGr does not currently specify a mechanism for how PMK-R1 keys are distributed. This
introduces a dependency on the IETF.
• We have to make sure that we can move forward with this while we continue work in
TGr.
Submission
page 14
Michael Montemurro, Chantry Networks
November 2005
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
doc.: IEEE 802.11-05/1112r1
The document could be put through an individual submission in either the informational
track or the standards track. You could publish a draft on a standards track and get it
submitted within a year.
The TSTA’s are completely unaware of this protocol. TGr would write the individual
submission to the IETF to resolve the issue with key distribution.
The TGr draft has to state the protocol requirements and refer as an example to a
particular IETF RFC.
We would follow a similar process to what was done by IEEE 802.11i for RADIUS.
They refer to using RADIUS as an example mechanism for authentication.
We need to make a reference in the TGr amendment to an internet draft that we write and
submit to the IETF. When the draft becomes an RFC, we amend the TGr draft to refer to
the RFC.
The timeline for RFC publication and TGr line up well.
This work would define a third AP to AP protocol in TGr.
The RRB is purely a transport mechanism. It has an Ethertype defined, and is an L2
protocol.
Pre-authentication is between an STA and a target AP over the DS.
The currently defined protocols do no resolve what is being defined here.
We are using it for this particular task, but it could be generalized for other uses.
IEEE 802.11 is currently concerned with MAC and PHY. However IEEE 802.11i
specified an Authentication Server.
We need to determine the content for an IETF submission.
We need to identify a set of people to work on this in an adhoc fashion, but the adhoc
group should report status: Michael Montemurro, Clint Chaplin, Nancy Cam-Winget,
Kapil Sood, Jesse Walker, Dorothy Stanley, and Frank Ciotti. Anyone who is interested
can email Dorothy Stanley.
Recess until the 10:30am session.
Submission
page 15
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
Thursday November 17, 2005
10:30 am
•
•
Call to order.
Discussion on next steps – Next Meetings/Ad-hoc meetings/Teleconferences
• Start teleconferences on December 14th on a weekly basis
MOTION: Hold weekly IEEE 802.11 TGr teleconferences for one hour duration starting
December 14th 2005 at 11:00 ET and continuing through the end of March 2006.
By: Michael Montemurro
Second: Nancy Cam-Winget
Discussion:
• We can cancel meetings as needed.
Result: Motion passes unanimously.
•
•
We would have an adhoc meeting after the January meeting.
The meeting could be on February 7-9 with possible locations of Toronto (Michael
Montemurro), Boston (Michael Montemurro), Chicago (Frank Ciotti), Phoenix (Kapil
Sood), and Herndon VA (Dorothy Stanley).
MOTION: Hold an IEEE 802.11 TGr ad-hoc meeting on February 7-9, 2006.
By: Jesse Walker
Second: Donald Eastlake III
Discussion:
• The WG requires the meeting location to be specified 30 days before the meeting. We
will need to announce the location by that time.
• The letter ballot would need to start no later that December 2nd – so we should have
letter ballot comments to address.
Result: Yes – 17; No – 0; Abstain – 0.
•
Recess into adhoc session until noon.
Submission
page 16
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/1112r1
Thursday November 17, 2005
12:00 noon
•
•
Call to order.
Discussion on going to letter ballot.
MOTION: Instruct the technical editor to rename IEEE 802.11r draft 0.11 as IEEE 802.11r draft
1.0.
By: Bill Marshall
Second: Kapil Sood
Discussion:
• None.
Result: 18 – Yes; 0 – No; 0 – Abstain.
MOTION: Believing the draft to be complete and free of unresolved technical issues, Task
Group r resolves to forward 802.11r draft 1.0 to the working group for the purpose of conducting
a 40-day working group letter ballot. The purpose of the working group letter ballot is to
forward the draft to sponsor ballot.
– The text of the motion to be presented to the working group will be “Move to authorize a 40day Working Group Letter Ballot of 802.11r draft 1.0 to start no later than 12/02/2005, asking
the question “Should the 802.11r draft 1.0 be forwarded to sponsor ballot?””
By: Kapil Sood
Second: Bill Marshall
Discussion:
• None.
Result: 19 – Yes; 0 – No; 0 – Abstain.
•
•
The process that was used to address comments from the task group review should be used
for letter ballot comments.
Adjourn for the week.
Submission
page 17
Michael Montemurro, Chantry Networks
November 2005
doc.: IEEE 802.11-05/0965r0
IEEE P802.11
Wireless LANs
November 2005 Mesh Minutes
Date: 2005-11-18
Author(s):
Name
Stephen G. Rayment
Company
BelAir
Networks
Address
603 March Road,
Kanata, ON, Canada
K1S 1W1
Phone
email
+1 (613) 254-7070
srayment@belairnetworks.com
Abstract
Minutes of the meeting of the IEEE 802.11 ESS Mesh Networking Task Group held at the Hyatt
Regency Hotel in Vancouver, BC, Canada, from November 14th to 17th, 2005, under the TG
Chairmanship of Donald Eastlake III of Motorola Laboratories. Minutes were taken by Stephen
Rayment. The Minutes were edited by Donald Eastlake III. The final Agenda for the meeting is in
document number 11-05/1035r8. The Closing Report is in document 11-05/1232r1.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
Contents
Minutes ......................................................................................................................................................................... 3
Detailed Record ............................................................................................................................................................ 6
Appendix: Balloting Results....................................................................................................................................... 12
Submission
page 2
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
Minutes
Session I, Monday, November 14th, 16:00-18:00, Hyatt Regency Hotel –
Regency D
The meeting was called to order at 16:00 by Donald Eastlake III - Chair, Stephen Rayment – Recording
Secretary
The Chair explained and reminded all to use the Manual Attendance Recording System for this meeting,
each day from 07:30 to 17:30
The Chair reminded all concerning 802.11 policy restrictions on recording and photographs
The Chair reviewed the IEEE 802 and 802.11 Policies and Procedures on Intellectual Property and
Inappropriate Topics. Apple has submitted a Letter of Assurance regarding the use of their US Patent
6,069,887
The Chair outlined the week’s Agenda, including the two options identified in the 2 November
Teleconference (which differ by when balloting occurs), per slides 3 - 12 of document 11-05/1035r4.
Vote on schedule options
Option 1 – 4
Option 2 – 37
Abstain – 2
adopting the Option 2 schedule
Approved the Minutes of the September 2005 Meeting, 11-05/965r0, by unanimous consent
Approved the Minutes of the Teleconference held 2 November 2005, 11-05/1055r0, by unanimous
consent.
The Chair briefly reviewed the status of the Task Group
- 35 intents to submit proposals received
- 15 proposals submitted, presented and balloted in July
- 6 presented and balloted in September
- 3 remaining proposals to be presented and balloted at this meeting
- See 11-05/112r14, 11-05/274r10, 11-05/597r14
The Chair led a discussion on Presentations and Discussion on Process, using document “TGs Process”,
Donald Eastlake 3rd, 11-05/1137r0, including a timeline to completion.
The Chair recessed the session at 16:56.
Session II, Tuesday, November 15th, 13:30-15:30, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 13:32
The Chair reviewed yesterday’s accomplishments, reminded everyone to use the manual Attendance
system and reviewed the Agenda and structure for this and the remaining sessions.
13:35 Proposal Slot A, G:7 SEE Mesh
Submission
page 3
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
“Simple Efficient Extensible Mesh (SEE Mesh) Proposal Overview”, 11-05/0567r7, Vann Hasty
(Motorola), Shantanu Kangude (Texas Instruments) et al
Questions ensued…
The Chair reviewed tomorrow’s agenda and adjourned the session at 15:32.
Session III, Wednesday, November 16th, 08:00-10:00, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 08:05, reviewed the day’s Agenda (document 11-05/1035r6), reminded
about the Manual attendance system, and made announcements
16:08 Full Proposal Slot C: Wi-Mesh Alliance (B:31)
“Wi-Mesh Alliance Proposal for 802.11 TGs”, 11-05/573r5, Juan-Carlos Zuniga (Interdigital), Susan
Hares (NextHop) et al
Questions ensued…
Chair recessed the session at 9:52
Session IV, Wednesday, November 16th, 13:30-15:30, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 13:30, reviewed the day’s Agenda (document 11-05/1035r7), reminded
about the Manual attendance system, and made announcements
13:35 Slot C, H:9 Mesh Networks Alliance
“Mesh Networks Alliance IEEE 802.11 TGs Proposal submission”, 11/05-0600r3, Guido Hiertz
(ComNets)
There were no questions.
The Chair recessed the session at 15:25
Session V, Wednesday, November 16th, 16:00-18:00, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 16:01, reviewed the accomplishments to date (document 1105/1035r7), and the briefly outlined the agenda for this session
Five minute summaries of each proposal were presented (numbering per documents 11-05/274r10, 1105/597r11, times below are approximate)
16:05 G:7 SEE-Mesh, 11-05/0567r8, Shantanu Kangude
16:10 B:31 Wi-Mesh Alliance, Juan Carlos Zuniga
16:15 H:9 Mesh Networks Alliance, 11-05/0788r2, Guido Hiertz
The Chair reviewed tomorrow’s Agenda.
The logistics for voting were then described by the Chair, with the official ballots being given out at the
head table by the TG Chair and Secretary and WG Vice Chair Al Petrick. The completed official ballots
Submission
page 4
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
were collected at a side table by the WG Chair Stuart Kerry and Vice Chair Harry Worstell. Balloting
occurred using the November 2005 TGs ballot forms with voters being called up by the first letter of their
last name from S through R.
The Chair adjourned the session at 16:25 after all ballots had been cast.
The results of the ballot are summarized in the Appendix.
The results were announced by Stuart Kerry on the WG Reflector later in the evening to allow informal
discussion prior to Thursday’s meeting.
Session VI, Thursday, November 17th, 16:00-18:00, Hyatt Regency Hotel –
Regency C
The Chair convened the session at 16:02, reviewed the accomplishments to date (document 1105/1035r7), made the manual attendance system reminder, made several announcements,
The Chair summarized the results of yesterday’s ballot.
The Chair briefly outlined the agenda for this session.
The Chair led a discussion on process, using document “TGs Process”, 11-05/1137r1, Donald Eastlake,
which shows the latest projected schedule for TGs. There were no comments.
It was agreed unanimously to hold a TGs teleconference at 1:00PM EST on Wednesday January 4th, 2006
Technical Presentation #2: “WDS” Clarifications’, 11-05/710r0, Darwin Engwer
Technical Presentation #3: “Implementation and Evaluation of AODV with Proactive Route
Announcements”, 11-05/1108r0, Susan Hares
The Chair adjourned the session sine die at 17:23
Submission
page 5
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
Detailed Record
Session I, Monday, November 14th, 16:00-18:00, Hyatt Regency Hotel –
Regency D
The meeting was called to order at 16:00 by Donald Eastlake III - Chair, Stephen Rayment – Recording
Secretary
The Chair explained and reminded all to use the Manual Attendance Recording System for this meeting,
each day from 07:30 to 17:30
The Chair reminded all concerning 802.11 policy restrictions on recording and photographs
The Chair reviewed the IEEE 802 and 802.11 Policies and Procedures on Intellectual Property and
Inappropriate Topics. Apple has submitted a Letter of Assurance regarding the use of their US Patent
6,069,887
The Chair outlined the week’s Agenda, including the two options identified in the 2 November
Teleconference (which differ by when balloting occurs), per slides 3 - 12 of document 11-05/1035r4.
Comments on the schedule options…
• Option 1 (later balloting) would allow more participation in technical discussion
• Clarification – Option 2 (early balloting) – results would be announced to WG mailing list on
Wednesday after balloting
Vote on schedule options
Option 1 – 4
Option 2 – 37
Abstain – 2
adopting the Option 2 schedule
Approved the Minutes of the September 2005 Meeting, 11-05/965r0, by unanimous consent
Approved the Minutes of the Teleconference held 2 November 2005, 11-05/1055r0, by unanimous
consent.
The Chair briefly reviewed the status of the Task Group
- 35 intents to submit proposals received
- 15 proposals submitted, presented and balloted in July
- 6 presented and balloted in September
- 3 remaining proposals to be presented and balloted at this meeting
- See 11-05/112r14, 11-05/274r10, 11-05/597r14
The Chair led a discussion on Presentations and Discussion on Process, using document “TGs Process”,
Donald Eastlake 3rd, 11-05/1137r0, including a timeline to completion
Questions…
• How to refine final proposal before Letter Ballot, eg use internal Task Group “ballot”? Experience is
that doing it once is beneficial, beyond that less so, TGs has not decided what to do.
• What happens if WG fails LB? TG can make it own decisions and actions, note first ballot gets 40
days, re-circirculation (which happens after 75% approval) gets 15 days, would expect TG to respond to
WG comments. Note: in re-circirculation draft can only resolve comments.
Submission
page 6
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
Technical Presentation #1: “Avoiding Adjacent Channel Interference in Multi-Radio Mesh Points”, 1105/1123r0, Mathilde Benveniste
Comment…
• Qwest has looked at this problem and saw similar or worse reductions in total network capacity, also
with VoIP you may get 6 calls on a single node, will get the same with a 30 node mesh!
The Chair recessed the session at 16:56.
Session II, Tuesday, November 15th, 13:30-15:30, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 13:32
The Chair reviewed yesterday’s accomplishments, reminded everyone to use the manual Attendance
system and reviewed the Agenda and structure for this and the remaining sessions.
13:35 Proposal Slot A, G:7 SEE Mesh
“Simple Efficient Extensible Mesh (SEE Mesh) Proposal Overview”, 11-05/0567r7, Vann Hasty
(Motorola), Shantanu Kangude (Texas Instruments) et al
Questions ensued…
• How do you address concentration with multi-radio MPs?
Suggest this be left for administrator to do, don’t describe how, implementation choice
• Assuming a central administrative entity?
No assumptions, implementation choice
• Mesh MAC, EDCA mandatory, CCF optional, don’t impose sync requirements on MPs that use EDCA.
If you don’t restrict them from tx’ing during CCW, puts CCF at disadvantage, if you loose opportunity
to reserve during P you can only tx short frame, so what is gained by CCF if you don’t impose sync on
EDCA MPs? How does sync for EDCA help them from not txing in CCW? Sync or not doesn’t matter.
• EDCA MPs may tx any time, without preventing that how do you enable CCF to function?
Design choice, don’t want to restrict EDCA only legacy MPs.
• Suggest this be re-examined, if CCF is to enhance
• AODV, uses MAC address?
Yes
• Has this been done before?
Yes
• Congestion control effect on TCP?
Haven’t analyzed, proposal only specifies signalling
• Slide 62, wanted to use 4 addr format, what type, if data frames no bits to signal mesh control?
QoS control tells that it is a mesh frame.
• Slide 25, no PSK limit, it is a higher level application, based on whether using PTK or GTK, nothing to
do with authentication, only PTK with CCM, not a correct statement
• Slide 28, working with TGw, mgmt frames should not be seen by STAs, keys for 11s should be
different from mgmt, key selector needs to be expanded
• Slide 27, use of pairwise keys for auth, 11i when a link goes down, with caching you save auth but still
need 4 way handshake, we will still have that when a link goes down, some way to optimize?
• Slide 12, broadcast interworking, do you unicast back to root?
Looked for simplicity, define rules that allowed for propagation based on sequence numbers. In unicast
it’s for a frame you know.
Submission
page 7
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
• Think about support for multicast which you map to a broadcast.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Decided framework is flexible to optimize on broadcast replication.
ARP will drive towards a solution
Traffic engineering, power saving section had no bearing on routing.
Not defined. Only defined hop by hop. Node should hold packets until neighbour back.
Provide reference on converting AODV and OLSR IP protocol to MAC
When only single frequency available, do you use EDCA?
Yes
Measurements of impact on performance with multiple hops?
Simulations exist, not in documents yet.
What’s impact of lowering EDCA parameters on VoIP?
What you do with info is up to MPs
No mandatory solution on what to signal with congestion?
No, administrator has to specify
What if unbalanced traffic across APs with different parameters?
Depends on policies, all MAPs follow same policies, haven’t specified
CTS to self to allows AP to silence its BSS, if you have neighbouring stations which don’t hear what is
effect on performance?
CTS to self is for silencing BSS. If stations don’t hear they are not relevant
Slide 32, since MAC is EDCA, when you send request, if you are surrounded by EDCA devices they
won’t understand and will take over, making things worse?
This is EDCA in a BSS. Implementation choice of how to slow down, eg use CTS to self.
What if you don’t have control over BSS?
Responsibility of MAP. If belongs to different mesh can’t do anything. It is intra-mesh congestion
control only.
Power save and routing protocol?
OLSR has selection functionality, willingness parameter is submitted by each MP, can use that to
exclude MPRs
Do you expect MPs running on battery?
Not MAPs, don’t go into power save state, MPs could.
What application?
Cellphones, PDAs, cleans up interoperation issues of IBSS
Present results (delay and jitter) on mixed case with EDCA and CCF MPs
Effect of independent Wi-Fi users in traffic channel?
CCF can’t extend reservation, causes waste?
Has other fairness issues
“I’ll be back” feature could be useful for PS and routing, used in OSPF, called hitless restart
The Chair reviewed tomorrow’s agenda and adjourned the session at 15:32.
Session III, Wednesday, November 16th, 08:00-10:00, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 08:05, reviewed the day’s Agenda (document 11-05/1035r6), reminded
about the Manual attendance system, and made announcements
16:08 Full Proposal Slot C: Wi-Mesh Alliance (B:31)
“Wi-Mesh Alliance Proposal for 802.11 TGs”, 11-05/573r5, Juan-Carlos Zuniga (Interdigital), Susan
Hares (NextHop) et al
Submission
page 8
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
Questions ensued…
• Slide 43, multi portals and load balancing, which section?
See hybrid AODV, use external port info
• How can you prevent multi portals connected to same segment forming a loop?
Need to improve doc. Metrics in common hello give topology info and distance to weight two
announcements. Prevents if going to roots that obey STP, assume they insert metrics. Translation has
to be done carefully. Note, rBridge would also allow this to work.
• Slide 54, are comparisons apples for apples? Is there an RFC for MANET OSPF? AODV, HLSR
contain elements from existing proven protocols. Agree at component level - top level and applications
are new.
• Is superframe used by all MAC modes?
No longer 3 modes, one co-ordinated, superframe is feature of
• DCCA requires synchronization, what kind, strict or loose?
Yes. SF’s must be aligned. Annex talks about Beacon Access Protocol. Beacons don’t have to be at
same time. Strict for all nodes in mesh. Can also do more loosely, like IBSS, may get collisions.
• How synch to one time reference and propagated?
In IBSS you sync to fastest clock
• How long do you use CFP, is it up to implementation?
CFP defined in beacons, just take control of BSS domain, duration is up to implementation
• Any co-ordination between CFP and other contention traffic?
No, only affects own administrative domain
• Slide 79, mesh extensions, track .11w, it will provide extra protection, possible after authentication
• Single mutual authentication by electing supplicant / authenticator, is inadequate, OK in simple case, in
case where existing MP from different mesh don’t have clear role.
Maybe change state machine, work through various scenarios.
• Requires strict synch? Very difficult. IBSS assumes topology doesn’t change
Synch gives traffic segregation. Basic EDCA operation is allowed. Just use IBSS for beacon
generation. Also can do in more precise fashion, with beacon access protocol, described in Annex.
• How do you mark MTXOP future time – beacon slot?
Only relevant to mesh link
• Are other nodes prevented from tx’ing on MTXOP
No agree with neighbour, up to neighbour, hope he knows about environment, that’s what he conveys
in response, each MP keeps knowledge
• Could be a problem with newly joining nodes?
Still have to do carrier sense
• So still a contention based reservation?
Yes, compete with others outside network
• Even though MTXOP is pairwise, do other neighbours need synchronization?
• How far in advance do you allow MTXOP reservation?
One time, multiple reservations possible in one management packet
• What happens if link fails in future window?
Chair recessed the session at 9:52
Session IV, Wednesday, November 16th, 13:30-15:30, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 13:30, reviewed the day’s Agenda (document 11-05/1035r7), reminded
about the Manual attendance system, and made announcements
Submission
page 9
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
13:35 Slot C, H:9 Mesh Networks Alliance
“Mesh Networks Alliance IEEE 802.11 TGs Proposal submission”, 11/05-0600r3, Guido Hiertz
(ComNets)
There were no questions.
The Chair recessed the session at 15:25
Session V, Wednesday, November 16th, 16:00-18:00, Hyatt Regency Hotel –
Regency D
The Chair convened the session at 16:01, reviewed the accomplishments to date (document 1105/1035r7), and the briefly outlined the agenda for this session
Five minute summaries of each proposal were presented (numbering per documents 11-05/274r10, 1105/597r11, times below are approximate)
16:05 G:7 SEE-Mesh, 11-05/0567r8, Shantanu Kangude
16:10 B:31 Wi-Mesh Alliance, Juan Carlos Zuniga
16:15 H:9 Mesh Networks Alliance, 11-05/0788r2, Guido Hiertz
The Chair reviewed tomorrow’s Agenda.
The logistics for voting were then described by the Chair, with the official ballots being given out at the
head table by the TG Chair and Secretary and WG Vice Chair Al Petrick. The completed official ballots
were collected at a side table by the WG Chair Stuart Kerry and Vice Chair Harry Worstell. Balloting
occurred using the November 2005 TGs ballot forms with voters being called up by the first letter of their
last name from S through R.
The Chair adjourned the session at 16:25 after all ballots had been cast.
The results of the ballot are summarized in the Appendix.
The results were announced by Stuart Kerry on the WG Reflector later in the evening to allow informal
discussion prior to Thursday’s meeting.
Session VI, Thursday, November 17th, 16:00-18:00, Hyatt Regency Hotel –
Regency C
The Chair convened the session at 16:02, reviewed the accomplishments to date (document 1105/1035r7), made the manual attendance system reminder, made several announcements,
The Chair summarized the results of yesterday’s ballot.
The Chair briefly outlined the agenda for this session.
The Chair led a discussion on process, using document “TGs Process”, 11-05/1137r1, Donald Eastlake,
which shows the latest projected schedule for TGs. There were no comments.
It was agreed unanimously to hold a TGs teleconference at 1:00PM EST on Wednesday January 4th, 2006
Technical Presentation #2: “WDS” Clarifications’, 11-05/710r0, Darwin Engwer
Submission
page 10
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
Questions…
• What is the WDS?
Not defined – name new applications that make use of 4 address structure.
Technical Presentation #3: “Implementation and Evaluation of AODV with Proactive Route
Announcements”, 11-05/1108r0, Susan Hares
Questions…
• Used just one channel per MP?
Yes, Two would change results
• Did you consider the long range dependence of the Pareto data distribution, loose some statistical
characteristics if parameters not chosen well, need long time to get mean value
Yes traffic source is Pareto average of 5 different runs
• What was minimum speed?
No mobility
• How many simulations done per data point in graph?
All run for 900 s
• Slide 12, decreases for one data flow, number control packets only depends on number MPs, why does
it change?
• Slide 16, why is there route discovery latency for proactive? There is no route discovery.
Some of the latency is when routes time out, changing active route timeout would change it
• Wouldn’t you configure those timeouts large?
• Slide 22, routing overhead for proactive is larger than for pure, slide 28 summary doesn’t agree with
this
Agree, should say latency not overhead
• Have packet delivery ratio results also to test simulation, for when connectivity varies
PDR is about 99%
The Chair adjourned the session sine die at 17:23
Submission
page 11
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/0965r0
Appendix: Balloting Results
After adjournment, the ballots were counted and cross checked by Stuart Kerry, Harry Worstell, Al
Petrick and Donald Eastlake. The results, as announced by email from Stuart Kerry to the WG Reflector,
and by the Chair at the Thursday session, were as follows:
Rank
1 G
2 B
3 H
Proposal
SEE-Mesh
Wi-Mesh Alliance (WiMA)
Mesh Networks Alliance
Yes
123
56
20
No
35
85
115
Abs
4
21
27
Yes Ratio
77.67%
39.79%
15.07%
As per the process in 11-05/274r10, those proposals with a Yes Ratio ranking in the bottom 40% (but at
least one) are eliminated except that they may merge with other proposals. As a result, Proposal H is
eliminated.
Submission
page 12
Stephen G. Rayment, BelAir Networks
November 2005
doc.: IEEE 802.11-05/1189r0
IEEE P802.11
Wireless LANs
Minutes for the Task Group T November 2005 Session
Date: 2005-11-15
Author(s):
Name
Emmelmann, Marc
Company
Technical University
Berlin
Address
Einsteinufer 25
10587 Berlin
Germany
Phone
email
+49–30–31424580
emmelmann@ieee.org
Abstract
This document contains the minutes for the 802.11 TGT meetings during the Vancouver 802.11
Plenary session.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Minutes
page 1
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
Tuesday 2005-11-15
TGT chair, Charles Wright– calls the meeting to order at 13.34h.
Marc Emmelmann volunteers to act as an interim secretary for this meeting.
Chair reads through standard policies, i.e. patent policies, Letters of Assurance (LOAs), anti-trust
policies, attendance logging and attendance credit
Chair reminds audience to sign the attendance sheets at the registration desk.
Chair reminds that a permanent secretary is still needed.
Chair reads meeting objectives.
Chair provides an update on progress since Garden Grove meeting (05-1140r0 slide 9).
Chair presents proposed agenda (05-1140r0 slide 10). Tentative presentations are included according to
their announcement during Monday’s ad-hoc session.
Approval of minutes of Garden Grove Meeting (11-05/955r0):
Approved by u. consent.
Approval of telecon minutes:
Minutes of telecons since Garden Grove (11-05/1100r1)
are approved without objections
Chair apologizes for confusion due to change of session slots from this morning to the afternoon.
Call for presentations:
1.T. Alexander, 11-05/676r1, “Link Layer Metrics Proposal” 45 min (Tues)
2.D. Ward, 11-05/1043r0, 11-05/1044r0, “Test Practices and Test Equipment” 45 min (any time)
3.D. Ward, 11-05/1101r0, “Suggested additions to the test template” 30 min (any time)
4.L. Green, “Theoretical throughput limits” 11-05/1050r0, 30 min (any time)
5.M. Foegelle, 11-05/1040r0, “Understanding the implications of link budgets”, 30 min (any
time)
6.S. Bangolae, 11-05/537r2, “Test Methodology Proposal for Measuring Fast BSS/BSS
Transition Time” 30 min (Wednesday)
7.F. Pirzada, 11-05/0969r1, “Document Framework Section”, 30 min (Wed)
8.Fanny Mlinarsky, 11-05/1109r0 “Latency Sensitive Usage Case”, 45 min (Wed needed)
9.Uriel Lemberger, 11-05/1158r0, “Receiver sensitivity”, (proposed draft text: 11-05/1157r0), 60
min (maybe today, better Wed)
10.U. Lemberger, 11-05/????, “Video testing methodology”, 60 min (Wed/Thu)
11.U. Lemberger, 11-05/????, “Transmit EVM”, 60 min (Thursday)
Authors indicate their preferred time to present.
Agenda reflecting announced presentations (05-937r0)
accepted without objections.
Minutes
page 2
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
Editor’s Report
ACI metric has been included in the draft now having 64 pages.
Editor calls for more proposals to be voted into the draft.
Question on when the draft is considered to be finished.
11-05/912r1 outlines TGT process. Task group has to vote on the draft to be technical complete
in order to go to letter ballot.
Chair reminds that more people should review the draft and provide comments.
Presentation 11-05/0676r1 “Link Layer Metric Proposal”
Presented conductive test environment is according to current draft.
Question if generator / WLCP should be connected to wired or SW traffic generator.
No as for link layer metrics, packets to be sent are a priori well known.
<Dennis> Just showing RF-paths in figure is not enough. We agreed during our last meeting that
combiners / splitters etc. have to be specified and included in the figures.
<Charles> Is the precise knowledge of imposed attenuation between sender and receiver required.
<Tom> No, not for link layer metric.
<Larry> Tom’s picture is simply a logical connection figure which does not need to include
specific means on how to connect cables.
General comments that figure seems confusing as it is unclear if included “connections” between
components, i.e. test controller and attenuator, represent actual cables or simply logical
functions.
<Tom> Might be true. But figure is directly taken from draft. If it is confusing, the draft should
be adopted as well.
<Fahd> Does metric only apply to APs or to STA as well?
<Tom> Both. But for the test experiments, I only dealt with APs
<Fahd> In proposal text, only APs are mentioned.
<Tom> Title can be accordingly changed.
<Fanny> It is necessary to measure NIC-AP as a pair in addition to just measuring a DUT for
itself.
<Pratik> Could test be done without “wires”?
<Tom> Yes, but results depend highly on environment. Only thing you could say is that results
would be the same or worse.
<Fanny> There are so many parameter to this measurements that the number of permutations
make a OTA test almost impractical due to time it takes to arrange the OTA set-up.
<Fanny> We should stick to the term “link layer forwarding rate” for the draft in order to define
throughput other than the formal IETF definition.
<Fahd> What is the permissible error margin regarding repeatability?
<Tom> 3%. It’s
Minutes
page 3
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
TGT in recess from 15:40h until 16:10h
<Neeraj> Regarding the association rate measurement, it should be paid attention that the
Authentication Server is not the bottleneck
Straw Poll:
How many would yes if a motion to accept the proposal were put on the floor?
Y/N: 6:0
Presentation 11-05/1043r0 “Test Equipment and Practices”
<Pratik> We may not assume people using the recommended practice to have an EE background.
<Michael> People might just go to test labs and have educated people do the tests.
<Dennis> Some institutes, e.g. universities, might not have the budget to do this but have non-EE
people do the tests.
<Charles> We have to know where to stop explaining things. We could assume people having at
least a BSCE/BSEE or equivalent.
<Larry> How well are we doing so far? Is the draft addressing the audience?
<Dennis> In my opinion, the draft is by far too ambiguous.
Ongoing discussion where to put the additional text Dennis is proposing. The approach is well
supported in the group; especially if included in a general, introductive section.
Presentation 11-05/1044r0
<Fahd> General definition should not specify particular “numbers” without an accompanying
methodology proposal.
<Charles> Does your proposal make explicit changes to the draft?
<Dennis> No.
<Charles> Thus, if we include it in the draft, the latter might not be consistent and the group has
to go back and make it consistent.
<Mark K.> Wait till the next meeting before including it in the draft to allow people look at the
numbers and provide feedback.
Presentation 11-05/1101r0
<Michael> 802.11.2 has to be written as if it were a standard even though it is “only” a
recommended practice as people will require in real life measurements to be conducted
according to 802.11.2.
TGT in recess from 18:03 until 13:30h tomorrow.
Chair calls TGT to order at 13:35h
Presentation 11-05/1050r0 “Theoretical Throughput Limits”
Assumptions include: no encryption, no QoS
Minutes
page 4
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
Contention window as indicated in presentation is not in usec but in slots
Assumptions also include ACK is always transmitted in base-rate
<Charles> Are you showing MAC throughput?
<Larry> Yes
<Charles> So if you are interested in (application layer) throughput, you multiply the frame rate
on slide 8 with the actual payload size you assumed.
<Andrew> Contention can help as possible within the back-off another NIC might transmit in this
interim.
Also, a frame mix might increase the throughput.
<Charles> This is true but only for the throughput observed at the AP. For several NICs, each one
will observe lesser throughput.
<Charles> Similar presentation in TGN around March might enhance given presentation
<Neeraj> Could you comment on MAC efficiency.
<Larry> Not includes so far.
<Charles> MAC efficiency included in TGN presentation showing that even giving an unlimited
bandwidth, max throughput is around 70 Mbps due to MAC overhead.
Graphical presentation is more favourable than including mere tables in draft.
<Fahd> Do you have draft text to consider for inclusion in the draft.
<Larry> Not so far.
<Tom> Tables are useful. If, e.g., you’re doing a rate vs. range test, PHY rate will degrade. Thus,
the tables might be useful in order to evaluate what results to expect.
Work could be included in Appendix.
<Pratik> People usually understand that they will not get the stated 54Mbit throughput when they
move away from the AP. How to place this in draft?
<Larry> It’s a very soft proposal to include the results somehow in, e.g,. an appendix.
<Pratik> Have to provide text that better relates to non-appendix-part of draft proposal.
<Charles> In favour for something like this in the draft. This will help to decider when to stop
optimizing transmitting-algorithms built in equipment.
<Fanny> In order to avoid confusing customers, simply focus on frame rate rather than
throughput. Latter can be calculated anyway.
<Andrew> Very useful. Should be included.
<Dalton> Good work but doubts that it should be included in draft.
<Tom> No reason why not placing this in, e.g., an appendix.
<Fahd> Please provide draft text clearly stating underlying assumptions. Might even evolve in a
methodology. .11e provides test-vectors in an informative annex.
<Dennis> Very useful for endusers.
Business
Agenda change to reflect new order of remaining presenters accepted without objections.
Presentations on Liaison MetroEthernetForum and TGT by Fanny added to new business.
Presentation 11-05/1040r0 “Understanding the Implications of Link Budgets”
Presentation 11-05/0969r2 “Document Framework Section”
<Tom> Is there accompanying draft text?
<Fahd> The presentation is the draft text.
Minutes
page 5
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
<Dennis> Get rid of the parentheses
<Charles> Would you allow further sections that do not fit into usage cases to be placed in this
new section 4, e.g. RF related information.
<Fahd> Yes. E.g., the material Dennis is providing might be put in there.
<Pratik> It is not going to be limited to the presented sections.
<DJ> Usually, “Usage Case” refers to environment, e.g. home, office, military, etc. There might
be confusion on this.
Motion
Instruct the editor to add section 4 in TGT draft to include the contents of slides 2-8 from
document IEEE 802.11-05/969r2
Mover:
Second:
Yes/No/Abstain:
Fahd Pizada
Pratik
15/0/3
Motion passes.
Discussion:
<DJ> Typical usage case, e.g. outdoor, indoor, etc are missing.
<Dennis> Too early to include these usage cases. It’s a good placeholder that should be
included
<Charles> Accepting this text means having further expectations
<Pratik> Calls questions
No objection.
TGT in recess from 15:15 until 15:45h
Chair calls TGT to order at 15:50h
Presentation 11-05/1213r0 “BSS Transition / Fast BSS Transition Methodology”
<Mark K.> Why two attenuators per path.
<Fanny> So monitor hears both, AP and STA, at any time.
<Dennis> Please comment on +/- 10% error margin.
<Charles> Actual accuracy of attenuation not important as long as handover is forced.
<Dennis> Just leave is out.
<Fanny> Can be accepted as friendly amendment.
<Pratik> Rather clarify than remove it.
Motion:
Move to accept proposal 11-05/537r3 into the P802.11.2 draft with the
following text replacing sections 2.3.3 and 3.3.3:
Prior to beginning the test, the test equipment described above
shall be calibrated, and all test software verified. The test setup may
be monitored during the test to ensure that the test conditions do not
change. At any time assure that the wireless monitor should be able to
listen to the test traffic during test run. The error margins for these
Minutes
page 6
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
metrics pertain to the timing of airlink events. For consistency and
repeatability, timing of airlink events should be 10 to 20 times more
accurate than the shortest measured BSS transition time
Moved:
Second:
Technical (75%) Y/N/A:
Fanny
Pratik
13/0/4
Discussion on the motion:
<Dalton> Comment on fact that 802.11r is still not approved.
<Tom> Not uncommon.
No objection to call the question.
Presentation 11-05/1109r1 “Framework for Testing Latency Sensitive Use Cases”
<Larry> Requests the document to be put on the server.
<Charles> Not focus of this group to provide PESQ models. Thus, we have rather focused, e.g.,
on the E-Model.
<Fahd> The presentation is not on metrics. What are the actual metrics we are talking about.
<Fanny> packet loss, delay, jitter
<Joe> Need to look at different sample traffic in terms of male/female voice, different languages,
etc.
<Pratik> Have this been addressed in other organizations?
<Fany> Adopted by WiFi Alliance.
Group generally in favour to follow this work in include this framework.
Order of Day.
Request to modify agenda as:
Request has been made to give another presentation by DJ.
Groups is willing to give time after all presentations scheduled for today have been given.
Agenda not modified.
Presentation 11-05/1158r0 “Rx Sensitivity Metrics in Conductive Test Environment”
<Michael> Is there a reason for the given fixed step size of 1dB. You might step down in larger
steps until you’re starting to loose packets. Basically it’s a search algorithm.
<Uriel> It’s just that way to keep the measurement procedure simple.
<Charles> Goal to characterize Rx sensitivity over the entire power range?
<Sasha> Originally only to measure min and max but it may be used for that purpose.
<Dennis> Reporting should include employed methodology as the latter influences the results
even on the same DUT. It might, e.g., employ any kind of “hysteresis”.
<Dennis> No information on measurement uncertainty in draft text.
<Michael> Before approving text, would be nice to adjust text to reflect capability that a wired
monitor might not be able to be directly connected to the DUT.
Minutes
page 7
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
Intense discussion if proposed test environment is able to test DUTs for which either a monitor
might not be attached or a monitor software might not be run on it.
Michael points out that there are several ways to solve this problem by other means, thus being
flexible.
Discussion that there could also be an entirely new submission handling this problem, but
attention has been brought to the fact that this could be easily included in the presented text.
<Mark K.> Propose to replace “wired” analyzer with “logical” analyzer in draft text.
<Dennis> Tolerance band regarding specified temperature missing
<Pratik> Calls order of the day
Meeting in recess until Thursday, 13.30
Chair call meeting to order at 13.38h
Presentation 11-05/1194r0 “Video Testing Methodology”
<Charles> Are you comparing to VQM?
<Uriel> No, GED is an additional evaluation method.
<Pratik & Charles> Should read “<” on slide 13.
<Marc E.> Is this methodology to be included in the draft or simply used to assess .11 metrics,
i.e. jitter, latency, loss, etc. with expected video quality.
<Uriel> No, this is just in order to develop a model which can later on be used to evaluate video
performance over .11 LAN.
<Charles> This is what you usually do in developing a quality metric for any kind of medium
ultimately sensed by some part of the human sensory system. Comparable to models
applicable to voice.
Presentation 11-05/1198r0 “TGT Power and EVM measurements”
<Michael> Concerned on where to exactly conduct the EVM. Be more specific.
<Michael> If there is no variation in the signal, you are always biasing.
<Uriel> We proposing the frequency domain to avoid such issues. But still need to define
considered bandwidth.
<Don> Should a spectrum mask be specified?
<Charles> This is a FCC test. We should not include conformance testing since this is out of our
scope.
<Fahd> Are changes to methodology necessary if we go to 256 QAM.
<Uriel> No, its independent.
<Charles> EVM requires to demodulate the received signal. Thus you might have to wait for
vendors to upgrade their test equipment.
<Michael> Good contribution. When it goes into the draft, attention should be paid on how to test
devices to which you may either not connect a cable or might run test software on.
Minutes
page 8
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
<Dennis> Are you planning to use this as a calibration step in some of the other methodologies
already included in the test
<Uriel> Yes.
Order of day
Chair request opinion of group on how to proceed with announced motions.
<Pratik> Uriel was giving a presentation yesterday when he was interrupted due to the session
break. He should be given time to finish discussion and present motions.
Group agrees that this can be done under New Business.
New Business
Discussion on Proposed draft text 11-05/638r2.
Request have been made to hold back the throughput related proposal as well. Tom is willing to do
that
Marc E. raises concerns regarding different definitions of “Throughput” to be included in the draft.
Tom will consider this as editor and give a presentation of a corresponding definition at one of the
following meeting.
<Dalton> Where does the “at least 7 retries” in the throughput test comes from?
<Tom> Experimentally.
Marc E. expresses concerns that text is going to be voted into the draft that is only considering DUT
tests even though the metrics should also apply on SUTs.
Tom’s response is that this why, e.g., the latency traffic has been left out in the motion.
Motion:
Move to adopt the contents of document 11-05-0638/r2 into the P802.11.2 draft,
with the exception of section 6, “Unicast ESS (Access Point) Latency and
Latency Variation”.
Moved:
Second:
Y/N/A (Technical 75%) :
Tom Alexander
Larry Green
13/0/5
Discussion on Motion:
<Fahd> Is retransmission limit a modified.
<Tom> Yes.
<Jo> Is this strictly a cable test or is there an RF environment.
<Tom> Conducted.
<Charles> Section 1.3.3 Permissible error margins. To what do the percent-values refer to?
<Tom> To results of measurement.
Motion change the 802.11.2 draft to clarify the test.
Minutes
page 9
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
Move to replace references to “wired traffic generator” and “wired traffic analyzer” in the
figures of the IEEE 802.11.2 draft with “traffic generator” and “traffic analyzer”, and to grant
editorial license to make the text consistent with this change. This change should be applied to
contributions accepted into the draft text as of the November 2005 meeting as well.
Moved: Tom Alexander
Second: Mark K.
Y/N/A (Technical 75%)
Put on table.
Discussion:
Should apply to “wired traffic analyzer” as well Æ Accepted as friendly amendment.
<Pratik> Concern that this is not purely editorial.
Charles steps down as chair.
<Charles> Speaks against the motion as just making this change generic might make the
figures inconsistent.
<Pratik> Suggest it’s better to ask people to ask for specific changes to specific sections
<Pratik> Rather than passing this motion, could we ask the editor to make comment list
identifiying each intended replacement.
<Charles> Block diagram should only contain equipment needed for the test.
Omit logical entities at all in figures.
<Michael> This reflects my previous concerns that things get in the draft and
later on we will solve concerns with certain figures as blocks are not commonly used. Otherwise should
have a block diagram for each test. This might
<Fahd> Request to the Order of the day
Motion to Move to table.
Moved: Fahd
Second: Dalton
Passed without objections.
Chair position passed back to Charles
TGT in recess from 15:40 to 16:00h
Chair calls TGT to order at 16:10h
Discussion on 05-1157r1
Motion:
Move to adopt the content of document 11-05-1157/r1 into the 802.11.2 draft. With
the following modifications to section 1.2.5:
• Temperature setting tolerance is +/-2degC
• The maximum acceptable measurement uncertainty for the Rx sensitivity is +/1dB.
Moved:
Second:
Y/N/A (Technical 75%):
Minutes
Uriel
Sasha
13/0/1
page 10
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
Discussion on motion:
Uriel presents changes from r0 to r1 in compliance to the e-mail
“[802-11TGT] Updated doc 11-05-1157/r1 posted on
the server“ distributed via the TGT e-mail reflector
on Nov. 16, 2005, 23:20h GMT-8.
<Charles & Michael> As data frames entering the receiver are counted on the air
link, retransmissions are messing up results. Setting retry-limit to zero would solve the problem.
<Dennis> My comment temperature was misunderstood. Specify the range of
temperate. As it is not measured, it should not be part of the test uncertainty.
<Michael> What you are currently saying is that the temperature shall be exactly
20 degrees Celsius. But your thermometer might have an uncertainty as specified. This is not what
we want. Fix it by saying: Temperature is +/- 2 degrees.
<Charles> If there is an error in the temperature measurement, and not in the
temperature window, this is what goes in the permissible error margin.
Ongoing confusion what the difference between temperature window / tolerance
and accuracy of temperature measurement is.
<Dennis> How accurate are your measurement devices.
<Michael> In the way the text is written, no one can conduct the test as the
uncertainty of each used component sums up to be larger than the required uncertainty of the results.
<Charles> What is missing for all RF related metrics, is a standard way on how to do the
calibrations.
<Michael> Have to specify both, accuracy and uncertainty.
<Charles> Rather specify the power level (input / output) and not the equipment in the
path as the spec of the power level would indirectly lay a spec on the used equipment.
<Pratik> Go ahead with an undefined number and fill it in later?
<Dennis> Methodology is fine, i.e. this kind of test. Authors should go back and get data
on their test uncertainty. Should not be voted in the draft. Strongly disagree with leaving it t.b.d or
just pulling numbers from the air and vote it in the draft.
<Uriel> Overall accuracy has to be +/- 1dB. Now what would we have to put in the draft
text to fix that.
Michael offers to work on the section in order to bring it back later.
<Tom> This is a problem throughout the draft.
<Pratik> Agrees with Tom. If expected outcome is off limits specified in the proposed
text, then the text is not useful at all.
<Tom> Be very cautious about test that nobody can implement.
No objection to call the question.
Motion:
Move the following:
A) Traffic Generator is an entity generates data traffic from WLCP/DUT to
DUT/WLCP on top of layer 2. It can be a device connected by cable embedded SW
etc. that fulfill this purpose. “Add to definitions section”
B) Traffic Analyzer is an entity that gathers delivered data payload over time
through an interface on top of layer 2. It can be a device connected by cable
embedded SW etc. that fulfill this purpose. “Add to definitions section”
Minutes
page 11
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1189r0
C) Instruct the editor to remove the prefix “wired” from wired traffic analyzer and
wired traffic generator in sections 4.3,4.4,4.5,4.6,4.7,5.2,5.3,5.4,5.5,5.7 (where the
use is with this interpretation), to be applies in the draft.
D) Instruct the editor to remove the prefix “wired” from wired traffic analyzer and
wired traffic generator in doc 11-05-1157/r1 and 11-05-0638/r2.
Moved:
Second:
Y/N/A (Technical 75%)
Uriel Lemberger
Amar Hassan
11/0/1
Discussion:
<Dalton> Would like time to go through it.
<Tom> Consider this as a technical motion. Gone through motion to verify referenced
sections.
Question called by Michael. No objections.
Presentation 11-05/1212r0
<Larry> Fine with cooperation but this group should not figure out what “meshed networking” is.
<Charles> Welcomes if representative from other group brings knowledge on Meshed networks
as well as proposed measurement methodologies into TGT.
Update on Theoretical Throughput
Larry points out that there is a .11 document dealing with this subject. He will announce the DCN
via the TGT-e-mail reflector.
Charles presents further ideas on how to calculate theoretical throughput for various parameters /
conditions.
Future Telecons
Proposed dates:
1. 1. Dec 2005: DJ Shyy presentation, summary of Vancouver
2. 15. Dec 2005: Discussion of Draft-0.5
3. 12. Jan 2005: preparation Hawaii, announcement of proposals & presentations
Motion:
Empower for telecons.
Mover: Fahd
Second: Michael
Accepted by unanimous consent.
Update on list of expected proposals for achieving the draft to be “mostly complete”
Update regarding progress. New revision will be posted as 11-05/912r2 (slide 11)
Issues List: Chair reminds to use the spreadsheet to intensively comment on the draft.
Motion to adjourn by Mark K., Larry Green second.
No objection.
TGT adjourns at 17:59h.
Minutes
page 12
Marc Emmelmann, TU Berlin
November 2005
doc.: IEEE 802.11-05/1241r1
IEEE P802.11
Wireless LANs
TGu Minutes for November 2005 Session
Date: 2005-11-21
Author(s):
Name
Hong Cheng
Company
Panasonic
Address
BLK1022 TaiSeng Ave #063530
Singapore 534415
Phone
email
+65-65505477
hong.cheng@sg.
panasonic.com
Abstract
Minutes for the TGu sessions of the IEEE 802.11 plenary meeting during the week of 14th – 18th
November 2005 at Vancouver, Canada.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Executive Summary:
Documents discussed:
1. Latest Draft Requirement Document 05/822r8
2. Motions raised during the session 05/1175r3
3. Updated timeline document 05/049r5
4. 3GPP2 liaison 05/1143r0
5. Pre-proposal presentations
a. Huawei/Intel (11-05-1168r0/1169r0)
b. Siemens (11-05-0870r1)
c. Panasonic (11-05-1138r0)
d. STMicroelectronics (11-05-1062r0)
e. FMCA (11-05-1088r0)
f. Root Inc (11-05-1093r0)
g. Nokia (11-05-0971r0)
6. Virtual AP Issue
a. 05/1219r0 – paper – 05/1120r1
7. E911 Issues
a. 05/1096r0
b. 05/1119r0
8 motions were raised during the sessions.
TG agreed to issue Call for Proposal after the meeting. The first formal presentation of the proposals will
be in March meeting. The first formal presentation does not require the formal text to be proposed.
Action Point: Summarize the agreed process regarding TGu’s support of IEEE802.21 requirements.
Action Point: Obtain information regarding IEEE802.21 document access.
Chair: Stephen McCann
Secretary: Hong Cheng
1. Tuesday Morning Session: (15th November, 1030 - 1230)
1.1
Meeting called to order by the chair at 10:30
1.2
Review of the IEEE 802 and IEEE 802.11 policies & procedures (05/1060r1)
Chair went through the policies and procedures. Chair went through the patent ruling from
PatCom.
1.3
Approval of the September 2005 minutes (05/1028r0)
The minutes were approved by unanimous consent
1.4
Approval of Agenda (05/1060r1)
-Comment: Cingular is to be taken out from the pre-proposal presentation list.
-Chair: Do we want to approve the working group document now, or leave it to the end of the
meeting?
- Comment: Better have the document approved so that we have the baseline for discussion.
Submission
page 2
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
The agenda is updated to 05/1060r2, and is approved by unanimous consent.
1.5
Review of September 2005 TGu session (05/1017r0)
Chair went through the closing report for last TGu session.
1. 6
Decision from Monday Ad-Hoc sessin
1.6.1 Down Selection Update (05/1155r0)
Details of the down selection procedure were gone through, and further discussion was schedule
on Thursday.
1.6.2 Call for Proposal
Will come back to this topic on Thursday session.
1.7
Approval of requirements document (05/1175r0; 05/822r4)
Suggested Motion Text:
Move that TGu approve document 11-05-0822r4, as a task group document
Mike Moreton (Editor) presented the new version of requirements document.
Comment: Regarding the changed text, does the “direction relationship” mean “direct roaming
agreement”?
Answer: We don't use “roaming agreement”. But, it is the same.
Comment: “Roaming agreement” is used two lines below.
Comment: Can this document help to describe what TGu is doing within 1 min?
Answer: This document is meant for helping people to submit proposals. There is no official high
level summary for all the requirements. Also, it is not a common practice for other groups.
Comment: Suggest doing that.
Answer: Some of the requirements are deliberately drafted to avoid implementation specific
language. So, it is difficult to describe them in simple words.
Comment: The PAR describes what the group is trying to do.
Chair: A high level description is available on the TGu webpage. There is a background and
objectives and goals section. It provides a concise summary of what TGu is trying to do. We can
copy this to the requirement document.
Comment: Have not read it, but it should be a good way.
Comment: Don't feel it should go into the requirement document, although something like this is
good for the group.
Comment: What does it mean by “use of Ethernet” in the summary?
Chair: We will be working with network based on Ethernet. We are not working to interwork
with other type of network, e.g. 802.18.
Comment: it sounds like the interworking is with L2, but actually we are working to interwork
with L3
Chair: Yes. That part will be updated offline.
Motion 1:
Move that TGu approve document 11-05-0822r4, as a task group document.
Proposed: Mike Moreton
Submission
page 3
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Seconded: Stefano Faccin
Result: (for-against-abstain) 10-0-4
Motion passed.
1.8
Open Issues (05/1031r0)
No comments for the issue.
1.9
RFC1321 order selection procedure
Comment: The data to be used fro the selection needs to be published before it is really used to
generate the sequence.
Chair: Will do that next time.
1.10
Pre-proposal presentation
1.10.1 Interworking architecture/ Network Sharing Architecture (05/1168r0;
05/1169r0) Zhonghui Yao
Comment: What is a virtual STA?
Answer: It is a concept to support simultaneous services for one STA that requires different
authentication.
Comment: Previous presentation on the SSID issue made in TGu should be considered when
evaluating this proposal.
Comment: Regarding Network Owner ID in first presentations (slide 15), we are talking about
STA has a relationship with SSPN. How is the Network Owner ID relevant at all?
Answer: It could be useful for an enterprise interworking scenario, where the APs are belonging
to the same enterprise.
Comment: For the interworking capability, there are several capability aspects. How can a single
bit indicate those?
Answer: Yes. Maybe one bit is not sufficient for that. But, this bit proposed is just to indicate this
network is 11u enabled.
Comment: So, it is a kind of “public access” bit.
Answer: Yes.
Comment: On slide 16, what is the interworking type? Where is that provided, and who define
that?
Answer: Need more discussion about that.
Comment: It depends on what and how the SSPN decides to provide for interworking. If SSPN
only provides a tunnel, it doesn’t matter.
Comment: On slide 17, is this suggesting a new interface between AP and entrance? Who define
that?
Answer: It is a discussion point. Entrance has more information about the ESS.
Comment: We are here talking about defining a new architecture. Not sure it is ok for our scope.
Comment: What is entrance? Is that L2 or L3?
Submission
page 4
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Answer: It is a borderline between the WLAN and external network. IEEE802.11 is only about
MAC and PHY. So, Entrance is just a interface between the IEEE802.11 network and external
network.
Comment: Need to mention how that is used in real networks.
Comment: Would like to see why the exiting entity, e.g. portal, is not sufficient and a new entity
needs to be defined. Please analyze the advantage and disadvantage.
Answer: Maybe need to add the Entrance function to the portal entity. It could be portal, but we
may need to bring more function to portal, that is why it is given a new name.
1.10. 2 Initial Network Selection Concept (05/870r1r0) Eleanor Hepworth
Comment: AP can cache the supported roaming information. It is the same case for the AAA.
This can avoid always using a round trip for obtaining the information. There is a similar scheme
in TGr doing that.
Comment: Regarding the harsh key, does it need the AAA to do that? There may be some
scalability issues.
Answer: That is just about the next hop information.
Comment: There could be lots of things to do with hash. It could be used for some unreliable
probing.
Comment: Is the NAI to be included in MAC IE to do that? Will there be any compatibility issue?
Answer: It is to reuse the SSID field.
Comment: Will the legacy AP supports this?
Answer: Yes. If legacy AP doesn't recognize it, it will just not ignore.
Comment: AP that supports it may announce that capability in the beacon.
Comment: It was discussed in 3GPP SA2, and it was worried that if the SSID is enough to carry
all the information.
Comment: Yes. 3GPP cannot change the MAC, but we can change the MAC in our group. So,
new MAC function could be introduced here.
Comment: Would it getting too big that it may require fragmentation? This may require some
consideration.
1.10.3 Authorization Information for Interworking (05/1138r0) Hong Cheng
Comment: Within 3GPP SA2, there is some work on QoS for WLAN interworking. The WLAN
is treated as a black box. It may be useful if this information is actually processed within the
WLAN itself to enforce some AP policies. Can the STA determine if the AP actually has QoS
capabilities?
Answer: AP can indicate QoS capabilities. However, here we also need to indicate the result of
the AP policy enforcement.
Comment: And the STA has to know what QoS is supported.
Answer: Perhaps we can put some information within the response to indicate to the STA.
Further discussion scheduled for the afternoon session.
Session recessed for the lunch break.
Submission
page 5
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
2. Tuesday Afternoon Session (15th November 2005, 1330 - 1530)
Meeting called to order at 13:30.
2.10.3 Authorization Information for Interworking (05/1138r0) Hong Cheng
It is felt that some requirements could be derived. A slot is scheduled on Thursday for further
discussion.
2.10.4 Shared Infrastructure (05/1062r0) Mike Moreton
Suggested motion text:
Accept the following text as a TGu requirement for proposals, and include it in the requirements
document, with requirement status set to “Optional”.
- Define how shared infrastructure architectures where the DS is shared by directly competing
operators will be supported.
- Informative Note: This is an environment where the normal trust model within the DS does not
apply. While the actual implementation may prove to be outside the scope of this TG, our
architecture should have some idea of how this would be achieved.
Comment: Every operator will have some relationship with the owner of the network.
Answer: It is about a different scenario, where the owner of the network is not operator.
Comment: Who pays for AP?
Answer: E.g. the airport authority. It is different from roaming.
Comment: There are different ways to achieve that, e.g. DS sharing or having higher layer
control. It may drift to a particular solution.
Comment: Will update the text.
Comment: Why it is not covered by requirement N3?
Answer: It is addressing a different scenario. In N3, the SSPN trusts the AN. This is where there
is no such trust.
Comment: If SSPN does not treat the AN, it may not be workable. Not sure if it is needed.
Comment: This is a problem statement, but it may or may not be required for TGu.
Comment: Changing the status to “Optional” will make it in scope. But, it is not sure if it could
be solved.
Answer: It is the feedback from WiFi Alliance for us to think about the problem. In the end, we
can reply that we had considered it and on solution could be identified.
Motion 2:
Accept the following text as a TGu requirement for proposals, and include it in the
requirements document, with requirement status set to “Optional”.
- Define how shared infrastructure architectures where the APs and network that connects
them are shared by different operators will be supported.
- Informative Note: This is an environment where the normal trust model within the DS
does not apply. While the actual implementation may prove to be outside the scope of this
TG, our architecture should have some idea of how this would be achieved.
Proposed: Mike Moreton
Seconded: Andrew Myles
Result (for/against/abstain): 7,1,3
Motion passed.
Submission
page 6
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
2.10.5 FMCA Discussion Point for IEEE802.11u (05/1088r0) Paul Fidler, Rodrigo
Donazzolo
Comment: There is no way to stop bridging. And it adds no security value for us to do that.
Answer: Agree that bridging is hard to stop. The worry here is more about Trojan attack.
Comment: Enrolment solution is outside of our scope. We can only advertise that the enrolment is
supported.
Comment: 11u only specify single interface (IEEE802.11).. Whether there are other interfaces is
out of scope.
Comment: The FMCA enrolment solution could be useful for us.
Comment: What is the multiple profile?
Answer: We have the multiple profile concepts. But, the context behind that needs more
discussion.
Comment: Is that the user has multiple subscriptions?
Answer: There are different kinds of subscription. Some provider provides transport, and some
provides the actual services.
Comment: If we have multiple profiles, we need to find out which one to roam, e.g. for all or just
one. That is the thinking behind it.
Comment: It is good to bring in the multiple profile concept for further discussion and identify
what exactly is needed.
Comment: It is the same concern from 3GPP regarding the bridging. It does not need to be
standardized.
Comment: In IEEE802.11k, there is information to be added to beacon to tell the location. Let us
know if you feel that it is not enough.
Comment: There are different operators of different requirements, depending on regulatory
requirements in different country.
Chair: What sort of feedback are you looking for? Should we have a written response?
Comment: Would like to have some response from 11u regarding the context behind the
requirements we are struggling with.
Chair: It would be useful for FMCA to send a liaison letter to IEEE802.11, spelling out those as
individual questions. That will allow us to work on them.
Comment: What is the cycle of the comments?
Chair: Usually a TG is authorized to work for 4 years. When the TG goes to LB, it would have 4
or 5 month cycle. But we will not get to that step next year.
2.10.6 MISP based Authentication Framework (05/1093) Hitoshi Morioka
Comment: This is a brand new security structure to replace IEEE802.1x. Is the proposal suggest
to throw away IEEE802.11i?
Answer: Yes.
Comment: TGr, TGi are doing the security. Doing security from scratch is not workable.
Comment: The new proposal is no better than IEEE802.1x. About using one message, there may
be multiple rounds of message depends on the authentication method.
Comment: How realistic of the scheme is questionable.
Comment: Is it suggesting IEEE to assign SSPNIDs?
Submission
page 7
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Answer: Yes.
2.10.7 Presentation from Nokia is withdrawn
2.10.8 Shared Infrastructure, 2nd half (05/1062r0) Mike Moreton
Comment: Does it mean that we need to define in detail what a gateway is in IEEE802.11u?
Answer: That may be unavoidable. So far, all the requirements we have are pointing to that.
Chair: What will happen after the Letter Ballot?
Comment: If we got reason to do things, and got good technical solutions, people will accept.
Chair: We need to think about it.
Comment: If CAPWPA is to involved, we need to talk about architecture. That is not in TGu.
TGu need to live with and without CAPWAP.
Comment: Some of the concerns now more become the network concerns. If we don't do it, no
one will do it for us.
Comment: There could be other architecture than CAPWAP. So, if we assume CAPWPA, how
many others we are going to dealt with?
Comment: It is just one possible solution.
Comment: Is it IEEE802.11f for the transport between AP and gateway?
Comment: IEEE802.11f is over IP. We don't have to define how the message is passed.
Chair: How is this relates to the wireless architecture group?
Comment: Not sure yet.
2.11
Discussion of the agenda (05/1060r2)
Hitoshi will present some measurement of how much bandwidth probed and response take on
Thursday.
Regarding IEEE802.21 joint session, a requirement document has been drafted to address
IEEE802.11 media.
Comment: Are they aware that each of their requirements needs a motion to be accepted in TGu?
Chair: No. We can prepare some template and help them to draft out the text.
Comment: Where is the document for the requirement?
Chair: It is a IEEE802.21 document: 21-05-0350-05-0000.
Chair: The motions will not be addressed in the joint session since they only need to be voted by
IEEE802.11 voting members.
Session recessed for the break.
3.
Wednesday afternoon session: (16th November 2005, 1330 1530)
Meeting call to order by the chair at 1330.
Submission
page 8
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
3.12 Joint Session with IEEE802.21
3.12.1 Joint Session Agenda & issues (05/1206r0) Stephen McCann, TGu Chair
The Chair went through the slides for TGu/IEEE802.21 joint session
Comment: Where is the requirement D16M2?
Stephen (TGu Chair): That is not in the current TGu document (as D16M2).
Comment: It is from the suggested requirement document: 05/279r16. In the current requirement
document (05/822r4), it is R3M2..
3.12.2 IEEE802.21 requirements on IEEE802.11 (21-05-0446-00-0000) Vivek Gupta
Document will be uploaded to IEEE802.11 server after the meeting.
Comment: Regarding requirement 1.1, do you want to use word “SAP”? It is a bit specific.
Probably it is pointing to a specific solution.
Answer: We can change the language.
Comment: Maybe use an "e.g." before it would be better.
Comment: The requirement is vague. For TGu to do something we need some details, e.g. the
SAP may need some more details, like parameters, etc. You need to do more work for us to
address this.
Answer: Had joint meeting with IEEE802.16. Same discussion was carried out. We made some
initial changes to IEEE802.16g to accommodate IEEE802.21. Agree that we may need to do the
same for IEEE802.11. But providing too much detail will overlap requirement and solution.
Stephen (TGu Chair): Do you think the requirements here are sufficient, or do you need more
detail?
Comment: Would be useful to have more details discussed. We can accept the requirement, but
just afraid people may not come with solution later.
Comment: Regarding requirement 1.2, is there any requirement on efficiency for transmit over
the air?
Answer: Not sure what is the best way to present that, although we had a lot of discussion in .21
already. Would like to have TGu work on the problem.
Comment: Need to have some concrete proposal to help the TGu to understand what to do.
Comment: So, the requirement will need to come with proposals.
Stephen (TGu Chair): The requirement could come as an attachment to the liaison letter to TGu.
We can then respond formally to that.
Comment: Is the objective to add the IEEE802.21 requirement into TGu requirement? Or
IEEE802.21 need to submit them individually?
Stephen (TGu Chair): Whatever IEEE802.21 submission to IEEE802.11u needs to go through the
formal liaison process at IEEE802 level.
Comment: In TGu, requirements are in different clusters. It is possible that these (cluster of)
requirements may not receive any proposals. So, the best way is to provide the details about what
you want to do.
Comment: What if there is no proposal received for a cluster/requirement?
Comment: Depends on what the TG want. We can drop it. The requirement would not force us to
do anything.
Submission
page 9
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Comment: There is a very good chance that people will provide a proposal in TGu regarding
IEEE802.21.
Comment: If you are confident that it will happen, it is OK.
Comment: These requirements are derived from the proposal in IEEE802.21.
Stephen (TGu Chair): What we have in TGu requirement document is similar to what you have
here. But, we have some informative text to address those requirements.
Comment: Having a requirement doesn't necessarily make that into the specification. It is up to
people if they are interested in propose a solution to that.
Ajay (IEEE802.21 Chair): Confused about whether it is useful to have higher level requirement
or detail solution.
Comment: Two aspects: high level for requirement, and more details needed to make sure that
someone will come to do the work.
Stephen (TGu Chair): To take these requirements, we need to go through the same approval
process in TGu. They will be approved by IEEE802.11 voting members. Therefore, we will not
do it in TGu/IEEE802.21 joint session.
Comment: Another way is to clearly define the interface between IEEE802.21 and IEEE802.11,
and agree on the interface. Then, we can know what to do where.
Comment: One way is to have IEEE802.21 to provide a detail solution, and ask TGu to check if it
makes sense.
Comment: The other way is to have a general requirement, and provide more details for TGu
people to understand it and work on it.
Comment: How will it be dealt with, if IEEE802.21 just go and submit a proposal to TGu? People
still need to understand both the IEEE802.11 and IEEE802.21 to evaluate that.
Comment: Could just have a requirement in TGu saying "do IEEE802.21 stuff".
Comment: From experience for the collaboration between IEEE802.11 and IEEE802.1, we need
to go through the slow and painful process of understanding each other.
Stephen (TGu Chair): Within TGu, we will produce a blanket requirement that it will support
IEEE802.21 as a compromise. Any thing relevant to IEEE802.21 will be within the scope. And at
the same time liaison will be carried out to address how to deal with the details.
Comment: Current IEEE802.11u PAR did not mention IEEE802.21.
Comment: IEEE802.21 member has no voting right in IEEE802.11. How would the process
work? Anything submitted to TGu has to be supported by IEEE802.11u members
Stephen (TGu Chair): That depends on how the volunteer want to do the work.
Comment: There will be different proposals for the cluster for IEEE802.21 related requirements,
And, if IEEE802.21 provides a proposal through liaison, most likely TGu members will not
support other proposals since they know this one is officially from IEEE802.21.
Ajay (IEEE802.21 Chair): If IEEE802.11 requires a proposal through a liaison, it can be done.
IEEE802.21 will seek to have a harmonized solution and send it to IEEE802.11.
Comment: No need to worry too much about the procedure. Everything in our specificiation
needs to go through the Letter Ballot. There will be comments coming and that could be
addressed jointly.
Stephen (TGu Chair): Agree with that.
Comment: Can we summarize the process?
Stephen (TGu Chair): In TGu, we will add a blanket requirement saying that IEEE802.11u
specification will support IEEE802.21. Additionally, we will expect IEEE802.21 to send a
Submission
page 10
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
proposal through liaison to IEEE802.11 and forward to TGu, for TGu to add a solution to its
specification. To go through the review process may require some interaction with IEEE802.21
(in joint sessions)
Comment: What is the review process?
Stephen (TGu Chair): We have a down selection process. The down selection will be done for
each of the cluster.
Comment: Do you expect IEEE802.21 proposal through the liaison or individually?
Stephen (TGu Chair): Both.
Ajay (IEEE802.21 Chair): IEEE802.21 proposal will come through liaison, and there will not be
any other proposal. So, it will be selected.
Stephen (TGu Chair): No. It has to go through normal process, since there is possible other
individual would propose.
Comment: If there is a single proposal. We can still vote it down and state that there is no viable
solution. We can choose to down select to zero.
Stephen (TGu Chair): Yes. We have a confirmation process. Prefer not to discuss the detail here.
Comment: The decision is to be made in TGu. How the proposal is sent over doesn't matter. If it
is sent from liaison, it probably will be treated a bit more seriously.
Comment: IEEE802.21 solution could solve some requirement in IEEE802.11u, but the
IEEE802.21 is also addressing something that is not in IEEE802.11u scope, e.g. the mobility.
Comment: Is it the objective that the solution selected for a cluster will eventually go into the
IEEE802.11u spec?
Stephen (TGu Chair): There is no guaranteed that any solution for any of the cluster will be
accepted because there is a confirmation voting process.
Comment: It is not the TGu but the IEEE802.11WG that makes the decision on that.
Comment: Do we expect high level solution from IEEE802.21 and TGu to add details?
Ajay (IEEE802.21 Chair): My understanding was that IEEE802.11 will not allow IEEE802.21 to
specify the details. But just now, the discussion concludes that 11 may not want to work on the
details. So, IEEE802.21 is expected to come with the details. .
Comment: Does IEEE802.21 think they can meet the time frame?
Ajay (IEEE802.21 Chair): There is already a detail document developed in IEEE802.21. We will
be able to meet your timeline.
Comment: We have the review process to guarantee that no overlapping solution will be put into
the specification.
Stephen (TGu Chair): If any IEEE802.21 member wants to submit a proposal in IEEE802.11u
individually, no one can stop that.
Comment: What happened to the old IEEE802.21 requirement in TGu?
Stephen (TGu Chair): We decided to take out the four requirements in San Francisco meeting,
since we felt that it is not proper for TGu member to judge what IEEE802.21 needs.
Comment: If IEEE802.21 is to work on the detail solution, it is doing the majority of the job. Is it
feasible to have a joint meeting to continue the same model for the next few meetings?
Stephen (TGu Chair): Yes. It is for the WG chairs to set up that.
Comment: Could also arrange for IEEE802.21 to review the IEEE802.11u solutions.
Submission
page 11
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Comment: If IEEE802.11 doesn't understand what is inside the thing transported for IEEE802.21,
we may not be able to use the same mechanism in IEEE802.11 for other purpose, e.g. TGr.
Ajay (IEEE802.21 Chair): IEEE802.21 document could be accessible from the ieee802 (group)
private area.
Ajay (IEEE802.21 Chair): As for what information is transported, it could be obtained from
IEEE802.21 draft.
Stephen (TGu Chair): Is it possible for IEEE802.21 chair to present to TGu IEEE802.21's
proposal? We can then consider that in TGu.
Ajay (IEEE802.21 Chair): Will check IEEE802.21 members for that.
Ajay (IEEE802.21 Chair): For IEEE802.11u member, is IEEE802.21 alien to them? It would be
better for them to know IEEE802.21 so that proposal will be understood.
Stephen (TGu Chair): Wouldn’t that be obvious in the proposal itself?
Ajay (IEEE802.21 Chair): Proposal is only the changes to be applied to IEEE802.11.
Comment: It would be good to have a few slides to summarize what the process is.
Stephen (TGu Chair): Could do that. Also need to have exchange of documents.
Comment: There are something in IEEE802.21 that are out of scope of TGu. Not sure how to
handle that problem. Can TGu address these issues out of their PAR?
Stephen (TGu Chair): We cannot address issues that are not in our PAR. If IEEE80.21 passes a
proposal to TGu, they should only have bits that are relevant to IEEE802.11. Otherwise, it would
be rejected.
Comment: There could be also other groups to work on the issue in IEEE802.11. TGu is not the
only group.
Comment: Capability bit may not in TGu PAR, and link layer commands is not in TGu PAR.
Stephen (TGu Chair): TGu is about interworking services.
Comment: Information service is in the scope.
Stephen (TGu Chair): Yes.
Comment: Regarding requirement 3.1, 3.2, are these in scope for TGu?
Comment: That might be nearer to TGv or TGr.
Stephen (TGu Chair): The conclusion is that it may not all fit into TGu. There could be a split.
But that is the discretion of member of TGu or even all IEEE802.11 members. We cannot just say
yes or no here.
Ajay (IEEE802.21 Chair): The summary is that TGu's preference is to have a blanket
requirement, and IEEE802.21 will develop the proposal as detail as possible. TGu member will
have their own sight to decide what is in the scope.
Comment: Can we have two IEEE802.21 clusters for IS and ES/CS?
Comment: Not feel it is necessary.
Comment: Can TGu Chair (Stephen) find out how TGu member can get hold of the IEEE802.21
document?
Stephen (TGu Chair) Will talk to Ajay to find out details.
3.12.3 Discussion on TGu Requirement R5M2 (05/822r5)
Ajay (IEEE802.21 Chair): What does it mean by “same network”?
Stephen (TGu Chair): Same BSS.
Comment: Is there a similar requirement in L2 in the scope?
Stephen (TGu Chair): Not now.
Comment: If it is at L2, that is what TGr is about.
Stephen (TGu Chair): Yes. That is why we also forwarded it to TGr.
Submission
page 12
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Comment: It is not the same BSS, it is the same subnet.
Comment: This is not in the scope of TGr.
Comment: Yes. The question is if that is for L2 (or network).
The session is recessed until Thursday.
4.
Tuesday morning Session: (17th November 2005, 0800 -- 1000)
4.13 TGu/TGv Joint session postponed to next meeting
Modified Agenda 1060r4 is approved with unanimous consent.
4.14
Virtual AP issues (05/1120r1 & 05/1219r0) Subbu Ponnuswamy
Comment: Legacy STA will join the base AP instead of the virtual AP.
Answer: Yes.
Comment: The broadcast bit need to be extended further, assuming the virtual AP AID is the first
one.
Answer: Yes.
Stephen (TGu Chair): How do you see this fit into the TGu requirement?
Answer: It is originally submitted to TGv. We want a way to do virtual AP, not care where to do
that.
Comment: TGu is not working to define the virtual APs.
Comment: For us, the virtual AP does not solve the TGu problems.
Comment: The attempt here is not to define virtual AP. It is more of the multiple SSID problem.
That is where it helps.
Comment: The problem still exists. STA still needs to find out which of the SSID to use..
Comment: This proposal will help the STA to do the query
Comment: There are other mechanisms that don't need to query at all.
Comment: If there is a mechanism that doesn't need query at all, it is OK. But if you need to
query, it needs to do it efficiently.
Stephen (TGu Chair): Would like to invite Subbu to come back in Jan to clarify what needs to do
in different groups.
Comment: In roaming case, STA needs to send a query of what your home network is. Need to be
careful about that. Some mechanism allow query to come in and find there are multiple SSIDs.
Comment: There are two issues. The operators share the network, and in additional, STA still
wants to find out if it can authenticate to the network. It will be coupled to see how that can solve
the network select issue.
Comment: May need a combination of the techniques.
4.15 E911 issues
4.15.1 Emergency Call Support (05/1096r0) Mike Moreton
Comment: Does the STA or the network need to support E911, or both?
Submission
page 13
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Answer: The network, e.g. AP, needs to indicate it supports, and the STA also needs to
understand that.
Comment: Now, does FCC forces the operator or the STA to support?
Comment: No requirement at the moment, but it may come later.
Comment: FCC makes requirements on the overall functionality, not the equipment.
Comment: Who is the "we" referring to?
Comment: There could be an advertisement to indicate the support of IEEE802.11u, but that
depends on the proposal.
Comment: Seems that the first bullet imply some solution. But, not sure that is the only one.
Could be done at higher layer.
Comment: it is just to say that we will need to have an architecture to support multiple virtual
network.
Comment: Is this a requirement?
Comment: This is not a requirement. It is talking about solution. Who is going to define the
virtual network for the E911? There are 3GPP E911, 3GPP/2 E911, etc. That is not in the TGu
scope
Comment: It is just saying that there is a possibility. It depends on the proposal.
Comment: There is a difference between virtual AP and virtual network.
Comment: There could be a 1 to 1 mapping relationship.
Comment: But that is implementation specific. The concepts are different.
Comment: These are all out of scope of this group. They are all for higher layer.
Comment: It is about L2 encapsulation.
Comment: Why it is needed? Why need to bring higher layer function to lower laye?
Comment: That apply to all the L2 functions we are trying to do here.
Comment: The encapsulation is L2, but for the emergency call center to call back, an
authentication is needed.
Comment: But there is no SIM.
Comment: In different country that may be different. Call back maybe necessary for emergency
in certain countries.
Comment: It is possible to call back even without SIM. The traffic segmentation is not higher
layer function.
Comment: VLAN could be used to do that.
Comment: VLAN is not higher layer function.
Comment: But, it doesn't need to be standardized.
Comment: Would like to see a solution that can do segmentation without L2 function. Do not
think it is possible.
Comment: Would the IP add be reliable enough to do the call back?
Comment: Not sure. Using a device ID?
Comment: The MAC address would be useful.
Comment: Not sure that could be done.
Comment: Regarding the monitoring issue, some temp keys could be used. Without pre-set
credential, it is subject to Men-in-the-middle attack. But that is not likely to be a problem for this.
Comment: There is a requirement for MAC anonymity. Does that impact the E911 support?
Comment: MAC address can be changed. Seems hard to support.
Comment: Last bullet is not consistent with cellular. The AP doesn't know about the SIP, or
whatever higher layer protocol.
Comment: It doesn't have to be consistent.
Submission
page 14
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Comment: But this would be implemented by the 3GPP/2 operators. It is better to have
consistency.
Comment: Need to look at the best solution. Not all network will be IMS.
Comment: It is much better to have a solution that let IEEE802.11 to setup the channel for the
traffic to flow go through. The rest, e.g. call set up, has nothing to do with IEEE802.11, because
we don't know how many need to be supported there. IEEE802.11 layer has no knowledge about
what is happing.
Comment: If we know that the traffic needs to go to a specific small range of address, it is better
to have a server in the network.
Comment: There are other issues, e.g. three class of frames, the E911 needs to be data frames. To
do that, class 1 & 2 processes need to take place. How would these get through?
Comment: There is the open authentication.
Comment: Does IEEE802.11i allow that?
Comment: Yes.
Comment: Is that similar for IEEE802.16 and WiMAX?
Comment: No.
Comment: Will ask this in excom
Comment: The feature how IEEE802.16 works is very different from IEEE802.11. Not sure we
will have a common solution.
Stephen (TGu Chair): Would like to invite Mike to come back in Jan with more details.
Stephen (TGu Chair): There is a liaison letter to 3GPP in last meeting.
Comment: There is a timing issue. IMS is in Rel7, which will be fixed in end of 2006. But, TGu
may not end then. 3GPP may have a solution by end of 2006.
Comment: Any solution will be limited without L2 support.
4.15.2 Support for emergency calls (05/1119r0) Alistair Buttar
Comment: Slide 4, EAS, will that go to WLAN?
Comment: Yes. Some broadcast mechanism could be used, e.g. 3GPP MBMS. DVB-H.
Comment: IEEE802.11k only has the container, but doesn't have real information.
Comment: We may want to update the requirement text.
Comment: Has the lawful interception been considered?
Comment: Not Yet. We may need some external advice on that issue.
Comment: GETS. Is that going to apply to what TGu is doing?
Comment: It does not apply to TGu, more for internet instead.
Comment: Legal interception. There is nothing to be done in L2.
Comment: It is independent from access.
Comment: Difficult to allow EAS in L2. Probably will be an application layer thing.
Stephen (TGu Chair): Would like to invite the presenter to come back in Jan with more details.
Stephen: Would also like to have some Japanese aspects covered. Maybe we can have a E911
session in Jan meeting.
4.16 IEEE802.21 Requirement
Suggested Motion Text:
Accept the following text as a TGu requirement for proposal and include it in the requirement
Submission
page 15
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Comment: There is no detail.
Comment: the objective is agreeable. Regarding the bit, we don't know the details, we don't know
what to do.
Stephen (TGu Chair): We just want a single general require for IEEE802.11 to support
IEEE802.21.
Comment: We can change text.
Stephen (TGu Chair): Do we want a general requirement?
Comment: Do they have a fix solution?
Stephen (TGu Chair): Not sure.
Comment: IEEE802.11u can speak for IEEE802.11. So, it should be IEEE802.11u to ask
IEEE802.11 whether IEEE802.21 should be supported. IEEE802.11 may not decide to have that
in TGu.
Comment: What happens if we don't have this? We need some place holder so that IEEE802.21
proposal can be accept to be consider here.
Comment: IEEE802.21 has a requirement doc. Should we wait for it be frozen? We cannot wait
for a frozen version.
Comment: We may need to set a reference to a set of document. Also, its scope may need to be
clarified.
Comment: All the IEEE802.21 issue should be in scope for TGu based on the PAR.
Comment: Some requirements from IEEE802.21 are relevant to network management, and thus
should be relevant to TGv.
Comment: There is some gray area.
Comment: How long is TGv open for input?
Comment: They have a set of areas. If those fit in, they could be accepted.
Coment: TGu was an entry point for IEEE802.21 to IEEE802.11. That should still stand.
Comment: IEEE802.21 now is considering some mobility issues that need to be pushed down to
IEEE802.11. Not sure that is fully in IEEE802.11u scope.
Comment: Maybe we should still maintain being the contact point.
Comment: We cannot do that. It has to be in the IEEE802.11 WG level.
Comment: Why it is required?
Comment: It is to be put in a separate cluster.
Comment: Want to know why it mentioned AP. Does that allow for STA?
Comment: Would need to update the text
Session recessed for the break.
5.
Tuesday morning Session: (17th November 2005, 1030 -- 1230)
5.16 IEEE802.21 Requirement
Motion 3:
Accept the following text as a TGu requirement for proposals, and include it in the requirements
document, with requirement status set to “Required”.
Provide a mechanism to support Media Independent Handoff capability
Submission
page 16
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Informative Note: This is a single requirement enabling IEEE802.11u to support Media
Independent Handoff (IEEE802.21 Project) requirements that are in cope for IEEE802.11u. The
objectives of the IEEE802.21 project are described in the requirement document 21-05-0446-000000-802-11-requirements.doc.
Proposed: Stefano Faccin
Seconded: Mike Moreton
Result (for/against/abstain): 12,0,0
5.17 Down selection procedure (05/1155r0) Mike Moreton
Comment: We have a Misc. cluster. What are we going to do with that?
Comment: Will discuss that when we go to the new requirement doc.
Stephen: Can u clarify for e.g. for .21 cluster, when there is no proposal passes confirmation,
what will happen
Answer: We restart from the old proposals.
Comment: If there is only one on the table.
Comment: Same. Keep on going to the confirmation
Comment: Can we drop it out?
Comment: We need to have some common sense to address this scenario.
Motion 4:
Move that TGu approve document 11-05-1155r0, as a task group document.
Proposed: Mike Moreton
Seconded: Eleanor Hepworth
Result: 9/0/4
Comment: After the initial presentation, at the third step “discard the unmerged proposals”, who
will discard? Is the group discard or the individual?
Comment: Important is whether it is still partial.
Comment: If the proposal claims to be partial, it would be discarded at this stage. If it claims to
be full, and if there are people object to that, the group would vote if it is partial.
Comment: Can we accept proposal saying that certain requirement should be discarded?
Comment: If people agree on that, it would be accepted..
Comment: If a proposal demonstrated that a requirement cannot be done, could the requirement
be deleted?
Stephen (TGu Chair): Yes. It requires 75% vote to pass.
Comment: What is the status of the "optional" requirements?
Comment: They don't count.
5.18 Authorisation Information for Interworking (05/1138r1) Hong Cheng
Two additional requirements text proposed
Motion 5:
Accept the following text as a TGu requirement for proposals, and include it in the requirements
document, with requirement status set to “Optional”.
Submission
page 17
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Define functionality by which the use of information defined in R3S1 at AP can be made known to
the STA.
Informative Notes: Information defined in R3S1, originated from the SSPN, may need to be
coupled with the AP local policy or status to decide the actual service to be offered to the STA. The
result of this adaptation should be made known to STA, so that it would not resort to try and fail to
find out what are the actual authorisation information in use by the AP.
Comment: Can you think of any scenarios where this would be used?
Answer: Yes. For example, when a dynamic policy control is used in the AP to decide the actual
service to be provided to the STA.
Comment: This seems to be about higher layer access control and authentication.
Answer: It can be done with higher layer, but requires AP to export information to higher layer,
and requires end to end signaling.
Comment: But high speed roaming may then fail.
Comment: This is no required at the MAC layer. It could be done with EAP.
Answer. EAP is end to end, and does not allow AP to insert information in.
Comment: There is possible way to change EAP to achieve that.
Proposed: Hong Cheng
Seconded: Eleanor Hepworth
Result (for/against/abstain):3,2,9
Motion failed.
Another suggested requirement text:
Suggested Motion text:
Accept the following text as a TGu requirement for proposals, and include it in the requirements
document, with requirement status set to “Optional”.
Define the functionality to allow a STA to retrieve information from an AP before authentication
in a network where R3N2 or R3N3 is supported.
Informative Notes: When a AP is shared by multiple SSPNs, or a STA has multiple credentials,
the query results may depend on the SSPN or credential it associated with. This requirement
addresses the case when STA is not yet authenticated, and thus the SSPN and the credential it
intended to use is not known to the AP in advance.
Comment: This is modifying the response from the SSPNs.
Answer: It is not about SSPN information. It is to allow STA query local information based on
SSPN it associated with.
Comment: Not sure what the word query means.
Answer: It means for example. Probe/Response in the current IEEE802.11. But, in the
requirement the Probe/Response should be avoided since it is solution.
More offline discussion would be done. The motion will be brought back next meeting.
5.19
Approval of task group working documents
New version of the requirement document is uploaded 05/0822r7
Submission
page 18
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
The Misc cluster is split into two sections: General and Individual
Text to be updated for the requirement document online to generate a new version 05/0822r8.
There is no objection to produce the new version of the document on screen.
Updated requirement document (05/0822r8) is uploaded onto the server for the voting, and there
is no objection to that.
Motion 6:
Move that TGu approve that the functional requirements document 11-05-0822r8, as task group
document.
Proposed: Mike Moreton
Second: Eleanor Hepworth
Result: (for,against,abstain) 13,0,1
Motion passed.
Motion 7:
Move that TGu approve document 11-05-0355r7, as a task group document
Proposed: Sabine Demel
Seconded: Thomas Haslestad
Result: (for,against,abstain) 12,0,2
Motion passed.
5.20 Call for Proposals
Suggested Motion text:
Move that TGu approves the Call for Proposals and requests IEEE802.11 WG Chair to issue an
appropriate announcement,
Comment: When will we start the merging process?
Comment: The 30 days requirement is hard for next meeting.
Stephen (TGu Chair): So, we will start down selection from March.
Motion 8:
Move that TGu approves the Call for Proposals and requests IEEE802.11 WG chair to issue an
appropriate announcement.
The deadline for these proposals will be 30 days prior to the March 2006 meeting.
Comment: The first official presentation of proposals is to be done in March.
Comment: That is just the presentation. There will also be others, e.g. text.
Stephen (TGu Chair): There will be lots of mergers. We will go along TGr route. We will only
require presentation for the first round
Proposed: Mike Moreton
Seconded: Sabine Demel
Result: (for,against,abstain) 13,0,0
Submission
page 19
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1241r1
Motion passed.
Comment: Why it needs to be 30 day?
Comment: We could discuss about that next meeting.
Stephen (TGu Chair): Since it is formal, we better allow others to have time to go through them.
5.21 3GPP2 LS (05/1143r0) Stefano Faccin
Stefano: We need to generate a LS in Jan meeting.
5.22 Teleconf Requirement:
There is no teleconference required.
5.23 Timeline document discussion (05/049r4)
The time line is update to 05/049r5.
5.24 Prepare for the Jan meeting
There will be joint sessions with TGv and IEEE802.21
Comment: Do we need a session with TGw?
Stephen (TGu Chair): Could have an one hour joint session. Will talk to Jesse about it.
5.25 Measurement of the probe (05/1224r0)
Will present again in Jan.
5.26 AOB
No issue.
Meeting adjourned till January meeting at Waikoloa, Hawaii.
Submission
page 20
Hong Cheng, Panasonic
November 2005
doc.: IEEE 802.11-05/1171r1
IEEE P802.11
Wireless LANs
Minutes of 802.11 Task Group V
Wireless Network Management
Vancouver, BC, Canada
November, 2005
Date: 2005-11-17
Author(s):
Name
R. R. Miller
Company
AT&T
Address
180 Park Ave, Florham Park NJ
Phone
973-236-6920
email
rrm@att.com
Abstract
This document records minutes of the 802.11v Task Group meeting of November, 2005 at Vancouver,
British Columbia, Canada..
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
R. R. Miller, AT&T
November 2005
1.
doc.: IEEE 802.11-05/1171r1
Tuesday Morning Session, November 15, 2005
1.2. Opening
1.2.1. Call to order
1.2.1.1.
1.2.1.2.
1.2.1.3.
Pat R. Calhoun (PatC): I call the meeting to order.
Meeting convened at 0800 hours.
I’ve had some requests to review the process we shall be using. We shall
also review the agenda, patent policy, and attendance. Attendance will be
recorded by signing on a list available from 0800 to 1700 each day. It is your
responsibility to sign this sheet each day.
1.3. Process
1.3.1. Review of Patent Policy
1.3.1.1.
PatC: I would like to read the patent policy shown on the screen from
document 05/1139r0. Are there any questions on the policy? None. Let us
proceed.
1.3.2. Review of Agenda
1.3.2.1.
PatC: You see before you the proposed agenda from document 05/1139r0.
1.3.3. Approval of the agenda
1.3.3.1.
PatC: Is there any objection to accepting the agenda as shown? None. The
motion to approve the agenda passes unanimously.
1.3.4. Approval of Minutes from Last Session
1.3.4.1.
1.3.4.2.
1.3.4.3.
1.3.4.4.
1.3.4.5.
1.3.4.6.
PatC: I call your attention to the minutes recorded in document 05/0931r2.
May I have a motion to approve the minutes?
TimO: I so move.
Motion: To accept the minutes as shown.
PatC: Is there a second?
Roger Durand seconds.
PatC: Is there any objection to passing this motion? None. The minutes are
approved unanimously.
1.3.5. Presentation of Document 05/1064r0
1.3.5.1.
1.3.5.2.
1.3.5.3.
Submission
Emily Qi (Cisco) presents a Proposal for Load Balancing contained in
document 1064r0.
The presentation reviews design goals to support AP and STA cooperative
load balancing via exchange of information, protocols, and facilitation of
roaming. Roaming management frames are proposed, including procedures
and usages. The proposal also urges examination of whether the outlined
solution should be extended to frames exchanged prior to
association/authentication sequences.
PatC: Are there any questions?
page 2
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
1.3.5.4.
1.3.5.5.
1.3.5.6.
1.3.5.7.
1.3.5.8.
1.3.5.9.
1.3.5.10.
1.3.5.11.
TimO: Remembering work flow from TGk, this doesn’t seem to fit well. There
are several items in the presentation that do not seem to interlace well with
the information provided by TGk.
EmilyQ: There is value in using the proposed process for roaming. The
roaming candidate may not be in the neighbor list, for example.
TimO: Wouldn’t that be an error condition?
JoeK: Not necessarily. Roaming candidates may not be in the neighbor list.
But, in the larger sense, the group will have to decide the interdependence of
TGv on other task group work. Until we make that decision, we can’t know
whether we should accept these elements or not.
TimO: The TGk framework allows not having the same information for each
request. It can be specifically tailored to the requestor. We could make this
scheme tie in well with the TGk neighbor list. BSSID can be used as an index
into the neighbor list, and here’s a recommendation for a load balance target.
EmilyQ: I agree, we should look at that. My proposal also carries load
information.
PatC: Any other questions? No. Let’s proceed with the next presentation
Larry: Some manufacturers use the same BSSID for different radios. This
could pose a problem.
1.3.6. Presentation of Document 05/1126r0
1.3.6.1.
1.3.6.2.
1.3.6.3.
1.3.6.4.
1.3.6.5.
1.3.6.6.
1.3.6.7.
1.3.6.8.
1.3.6.9.
1.3.6.10.
1.3.6.11.
1.3.6.12.
1.3.6.13.
1.3.6.14.
1.3.6.15.
Submission
RogerD: I’d like to introduce Floyd Backes, with Autocell, who has had much
experience in 802.11 standards-setting.
FloydB: The presentation 05/1126r0 is on the server, treating Load Balancing.
The purpose of the presentation is to explain how the proposed process works
using credit-based admission control. The goal is to distribute STAs across
available APs by trading off potential data rate against load in a stable way
with scalable characteristics. Stations should be authenticated prior to
participation in load balancing. The core algorithm is an auction-bid economic
model, motivated by benefit to a particular station. This type of algorithm has
been shown to work well in client-server applications since the 1980s.
Stations can use power-save background scan to look for available APs.
PatC: Questions?
Unknown: One station for auction interval seems problematic. With roaming
you may be in changing conditions. Do you have information on this?
FloydB: You and opt them out of the load balancing, or can enhance the
algorithm to allow more than one station at a time.
JoeK: What’s your concept of “load” and how does that tie in with 11e “load
category” ?
Floyd: Station with higher data rate would be a higher load.
JoeK: So load is based on all access categories equally?
Floyd: The algorithm does not currently take into account the type of traffic.
JoeK: How would this work in a hierarchical, central control situation?
Floyd: I see this as hierarchical, as when you use a candidate list the
algorithm uses the list of candidates as in Emily’s proposal.
PatC: If you look at the auction scheme, it seems like “first come first
served”...
FloydB: No, rather the “level of pain”.
FloydSimpson: Is this based on signal quality?
Floyd: We make an estimate based on how many dB away you are from the
access point, so available rate is part of the choice. If you are far away, you
may get a rate that would be too low, even though the AP is not heavily used.
page 3
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
1.3.6.16.
1.3.6.17.
1.3.6.18.
1.3.6.19.
1.3.6.20.
1.3.6.21.
1.3.6.22.
1.3.6.23.
1.3.6.24.
1.3.6.25.
1.3.6.26.
1.3.6.27.
1.3.6.28.
1.3.6.29.
1.3.6.30.
EmilyQ: The load factor calculated should take into account the type of traffic.
For VoIP, you may have accepted many calls. We meant to keep it simple, but
the algorithm can be enhanced---for example separate auctions could be held
for each traffic class.
RogerD: 802.11e already has admission control based on traffic type via
TSPECs, so these fields could bias the load balancing algorithm rather than
just spreading the load for all types as discussed here.
EmilyQ: Is it in scope to specify an algorithm?
Floyd: I think we have to ensure that the system will remain stable.
Marty: You can’t reserve bandwidth with this right now?
Floyd: No.
SimonB: There seems to be some implied communication between STA and
AP? How do you do this?
LarryStefani: That’s my fault. In this presentation we restricted the
discussion to the algorithm.
Simon: But can you clarify the process?
Floyd: Background scanning builds a list of known BSSs. It picks to ones it
might go to and formulates a bid. The AP collects bids from all comers and
picks the one that best meets the balance criteria.
TimO: There seems to be a lot missing. Would this work every beacon
interval? How to you handle load balancing fast enough?
Floyd: Response is an architectural choice, rate could be based on beacon
interval.
Larry: Stations don’t know that they lost the auction. Other stations aren’t
load balancing. Each station is always evaluating the situation. By the time
the auction is over, an STA might not choose to go there.
TimO: Why not do this go through a separate TSPEC request rather than a
new data frame?
PatC: We’re out of time. Perhaps this can be taken off-line?
1.3.7. Presentation of Document 05/1125r0
1.3.7.1.
1.3.7.2.
1.3.7.3.
1.3.7.4.
1.3.7.5.
Submission
Floyd Backes presents Channel Selection, document 05/1125r0 on server.
The presentation advocates negotiation of the best channel map using graph
coloring algorithm. Overall quality of channel map is determined by criteria.
The process involves recursion of prescans (to determine other APs), develop
a channel quality index, then bit on the channel using Adjacency Channel
sum, and bid. The order in which APs are allowed to camp is determined by
Adjacency Vector Sum, which adds all of the contributions. Those in center of
network hear lots of other radios so larger AVS, others at edge have lower
AVSs. You pick the channel using the channel quality index, which rates cochannel congestion (weighted), adjacent channel interference (spill-over
weighted by distance away and PHY), and in band noise (measure noise
floor, then weight by taking into account non-linearity effect of noise on rate).
Then finally, you take all of these and pick the lowest.
MarianR: How well does the algorithm work with APs that are not part of the
common network?
Floyd: The technique is robust, but overall quality suffers with increasing
number of APs not participating. If those were around the edge, they’d pick
their channels first.
MarianR: APs that have different scan rates, etc. Could this affect the
algorithm because computation could be asynchronous?
Floyd: Algorithm is robust against this.
page 4
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
1.3.7.6.
1.3.7.7.
1.3.7.8.
1.3.7.9.
1.3.7.10.
1.3.7.11.
1.3.7.12.
1.3.7.13.
1.3.7.14.
1.3.7.15.
1.3.7.16.
1.3.7.17.
1.3.7.18.
1.3.7.19.
1.3.7.20.
1.3.7.21.
1.3.7.22.
1.3.7.23.
SudheerMatta: It appears to me that other algorithms exist that don’t require
distributed action.
Floyd: There are many algorithms out there that operate with central control,
since that’s simpler.
SudheerMatta: Is there a difficulty if everyone doesn’t start together? Can it
be made to run continuously?
Floyd: Yes
Unknown: There can be a ripple effect when stations do this out of phase.
Floyd: You can set thresholds for continuous operation, with hysteresis to
improve stability further..
Necati: How can access points execute the algorithm together continuously?.
Also, could stations could share information with access points?
Floyd: You think channel selection should be continuous, not event driven
and second is that STAs should share information with APs during the
process is that right? Yes.. We could do that, but no customer has asked for
it yet.
TimO: I’ve been looking at algorithms for a number of years. With an accessdriven system, I’ve found that it may not be better to make a uniform
interference environment. How does the power setting work?
Floyd: Power is covered in Roger’s presentation. Backoff of power can be
adjusted.
Roger: Collocation complicates the power control process.
TimO: You need to set power before scanning. What do you do on the
measurement, Max power?
Floyd: Yes
JoeK: This is working in a product? In a typical environment with many APs,
how long does it take for the process to converge?
Floyd: On the order of number of channels not APs. Minutes. Depends on
number of channels.
JoeK: Has there been any microwave oven trouble?
Floyd: No.
PatC: We’re out of time. Next presentation?
1.3.8. Presentation of Document 05/1070r1
1.3.8.1.
1.3.8.2.
1.3.8.3.
Submission
Emily Qi presents document 05/1070r1 - Normative Text for Troubleshooting
and Diagnostics, with Tim Olson. Design goal was to create an extensible
framework for network diagnostics and troubleshooting. The alert is
introduced, triggered by a problem or failure. Types of alerts can include a
transition alert during roaming, weak coverage or network instability, an RSNA
alert where too many RSNA failures have occurred indicating encryption
troubles or hacking, and a Blacklisted BSS alert where barred BSSs have
been detected which may require exclusion from Neighbor Lists. The
presentation proposes the Alert channel element that contains the trigger for
an alert, as well as logging. TimO then continued the presentation with the
concept of a Diagnostic Channel. It allows diagnostics to be conducted driven
by a trouble report, and offers several tests, including Client Report
(exchanges client information), 802.11 Authentication (requests authentication
with specific WLAN, Reassociation (determines if client can associate with
designated WLAN). Built on action class frame: Request/Report Frames.
MarianR: Could you better describe what is the Diagnostic Channel?
TimO: This actually creates a channel with a special SSID for diagnostics
only, not used anywhere else in the network. Then one can direct an STA to
directly attempt to contact the diagnostic channel. The technique could also
page 5
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
1.3.8.4.
1.3.8.5.
1.3.8.6.
1.3.8.7.
1.3.8.8.
1.3.8.9.
1.3.8.10.
1.3.8.11.
1.3.8.12.
use AI to automatically find and diagnose problems. More tests could also be
added.
MarianR: Some of the tests seem to be unencrypted?
TimO: Yes but could subsequently move to an authenticated/encrypted
channel as the first tests are completed.
JoeK: Do you turn logging on and off?
TimO: The diagnostics may request logging, or triggers may cause log to be
started automatically.
JoeK: This is a mechanism for accessing log, then?
TimO: Yes. We will eventually have to have ways to signal that a client can
actually support the logging functions.
JoeK: In TGk we explored diagnostics. Do you think TGv is an appropriate
place to do this?
TimO: Yes. The tests are 802.11 Layer 2 diagnostics, so I think this is a good
place.
PatC: We are out of time, so we should recess. We will start after break at
1040, instead of 1030 due to trouble in my schedule-making. If you have a
presentation that is not in document 05/1139 let me know before Thursday.
1.4. Closing
1.4.1.
Recess
1.4.1.1.
1.4.1.2.
PatC: Is there any objection to recessing for the break? Hearing none, we are
recessed.
Recess at 0955.
1.5. Opening
1.5.1. Call to order
1.5.1.1.
1.5.1.2.
Pat R. Calhoun (PatC): I call the meeting to order.
Meeting convened at 1040 hours.
1.6. Process
1.6.1.
Presentation of Document 05/0927r2
1.6.1.1.
1.6.1.2.
1.6.1.3.
1.6.1.4.
1.6.1.5.
Submission
Tim Olson presented document 0927r2 - Client Management Protocol
Details. This is a continuation of previous work, and has been further
integrated with the work of TGk, which provides for measurement frames and
action frame categories. The presentation expands managed object request
elements with GetRequest and SetRequest for obtaining and implanting
information. Companion elements GetResponse, GetBulkResponse and
SetResponse are also outlined. Companion document 05/1083r0 Client
Management Protocol Normative Text creates suggested normative text
implementing these constructs. Author admits mixed feelings about writing
this, and could use feedback from group as to whether this seems like the
direction it wants to go.
LarryS: There seem to be several approaches that would work.
TimO: Yes, one could run either this or SNMP on clients.
LarryS: One would not have to do a full SNMP.
TimO: Yes, but this is still a substantial group of functions to handle. Last
time we generally agreed that we probably didn’t want to go the SNMP route.
page 6
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
1.6.1.6.
1.6.1.7.
1.6.1.8.
1.6.1.9.
1.6.1.10.
1.6.1.11.
1.6.1.12.
1.6.1.13.
1.6.1.14.
1.6.1.15.
1.6.2.
1.6.3.
Presentation of Document 05/1077r0
1.6.2.1.
Simon Black presented document 05/1077r0, Triggered Measurements as a
framework for 11v diagnostic alerts. A companion document, 05/1076,
Framework for 11v Diagnostic Alerts Normative Text, provides suggested
normative text. Similar to Emily’s presentation thrust. 11v has an objective
to provide diagnostic feedback. This could be derived from 11k where a
triggered mechanism already exists. The theme of this presentation is to use
the “k” basis rather than “reinvent the wheel”. However, the presentation
adds the capability of multi-radio coordinated measurements, which “k”
doesn’t have. Multicast performance reporting can also be accommodated
using the triggered approach.
1.6.2.2.
TimO: There may difficulties with using the “k” approach: Having the
overhead of duration fields might be OK. But here there are overheads that
may not be appropriate.
1.6.2.3.
SimonB: If you think about ”k”, you don’t have to use the duration field on
some of them.
1.6.2.4.
1.6.2.5.
TimO: Yes, but those “k” ones don’t well support “v” needs.
1.6.2.6.
1.6.2.7.
SimonB: QoS is the only one that offers triggering capability.
1.6.2.8.
PatC: Time’s up. Next presentation, please?
JoeK: Why didn’t you include all the other radio measurements of “k”, rather
than just QoS?
JoeK: Seems like this may be restrictive, and charging into normative text
too soon.
Presentation of Document 05/1068r1
1.6.3.1.
Submission
JoeK: A question on object characteristics: Are you modifying the object
type, with write, read-only, etc? How is that handled? Is everything open,
regardless?
TimO: One can define permissions, but it looks as if there is little to gain by
doing that since it is implicit in the nature of the action.
JoeK: Then the station using the interface has the responsibility to make this
work properly?
TimO: Yes.
EmilyQ: Thanks for putting this work together. Since we have not completed
an access control framework yet, it seems like SNMP would be better.
PatC: We covered this many times before. Many devices limit the
mechanisms by which they can be controlled.
JesseW: I’d like to push back. If I think how this info might be useful, you
might need it before you have a link. 802.11w will not support this until state
3, making it necessary to run SNMP since you don’t have an IP address yet.
MarianR: Would this be useful for readout of station objects or for real-time
use?
TimO: Very flexible, could be used for either, but would probably be more
effective (due to delays) for fixed objects.
PatC: Next presentation, please.
Roger Durand presented document 05/1068r1, MultiRFPower showing
normative text. There is another presentation, 1114r0 Dynamic Multilevel
Power Control provides background Powerpoint information. There are two
added fields and how they are used is described. There are compatibility
issues associated with regulatory and legacy devices for power control. I
decided to extend the 11h field to communicate power control capability.
page 7
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
Use of power control can dramatically increase the capacity of the network,
and that is the objective of this proposal: to minimize the amount of energy
needed to communicate. If a power control command is ill-formed it could
prevent radar detection. This is a simple concept, as outlined in 1114r0,
using radio sensitivity threshold adjustments. With legacy equipment without
power control, coverage may be maximized, but not capacity. This requires
power shaping if one does not have a specialist lay out the system with
appropriate cell separation and overlap (assuming all APs on the same
frequency) together with static power levels. This proposal advocates
dynamically adjusting power, providing best coverage and maximized
capacity using management frames at full power, but reduced power for
closer clients and max’d power for clients at cell edges. Likewise, radio
sensitivity adjustment allows sensitivity to be reduced to compensate for
interference, and transmit power is increased.
1.6.3.2.
TimO: I don’t exactly understand what you get for what you receive. Why
can’t I adjust my local power constraint?
1.6.3.3.
Roger: It’s necessary to get the coverage and capacity simultaneously. With
only one type of power set capability, management and data frames can’t set
management and communication powers separately. The technique also
can allow APs to hear each other.
1.6.3.4.
1.6.3.5.
1.6.3.6.
TimO: For management frames you want APs to hear each other?
1.6.3.7.
JoeK: Good approach for default power control capability. But in order to
gain from technique one should qualify on not only frame, but destination
address. Suggest this would move forward, but could be better if MAC
address based. We are not changing any PHY characteristics, so the
changes might be better viewed as squelch (masking) rather than sensitivity.
1.6.3.8.
1.6.3.9.
1.6.3.10.
1.6.3.11.
1.6.3.12.
1.6.3.13.
RogerD: Sensitivity is a legitimate variable.
Roger: Yes but there are few of those.
TimO: Sometimes 80-90% of traffic is beacons, though. You really need to
de-sense receive and transmit together.
JoeK: Are you suggesting that TGv will vary sensitivities?
RogerD: Yes
EmilyQ: You want to treat beacons?
RogerD: Yes
EmilyQ: Can you expand on what these adjustments would do to
associations?
1.6.3.14. RogerD: Radio sensitivity and CCA are separate, but similar in function.
CCA has a non-real component (virtual via NAV), which distinguishes it from
sensitivity.
1.6.3.15. JesseW: All the diagrams reference a small number of devices. What if
large number devices. Can this remain stable with lots of devices?
1.6.3.16. RogerD: Data power is based on associations, management power is set
relative to nearest access points. This remains stable with more participants.
1.6.3.17. TimO: I agree with your CCA observations, but they are not the same.
1.6.3.18. RogerD: We can add normative text to clarify this.
1.6.3.19. PatC: Time for the next presentation.
1.6.4.
Presentation of Document 05/1073r0
1.6.4.1.
Submission
Jarkko Kneckt (Nokia) presented document 05/1073r0 - Advanced Power
Saving. The presentation compares APSD mechanisms and concludes
page 8
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
improvement is possible. APSD has no scheduling possibility, while
scheduled operation has no way to prevent unnecessary awakening, but
turns on clients always at the same time. Limitations due to inability to use
voice coder silence intervals. Suggest use of scheduled APSD + HCCA.
Some codecs produce synchronized outputs encouraging repeating
collisions with APSD. Suggest distributing (randomizing) APSD triggers at
client. If AP does not support scheduling, the ADDTS response might be
used.
1.6.4.2.
Marian: Would you say this is particularly useful for optimizing transmit
opportunities?
1.6.4.3.
1.6.4.4.
Jarkko: Yes
1.6.4.5.
PatC: You have a point, but the process that was proposed for queuing
proposals was rejected by the group. This presentation thus fits the
”anything is in” view of the group. You could make your views known on
Thursday. Rather than try to fill the remaining time and have to split a work
in progress, I suggest that we recess until the afternoon session 15 minutes
early.
MarianR: We held many straw polls regarding whether things like this were
in scope, and it seems that this is not.
1.7. Closing
1.7.1.
Recess
1.7.1.1.
1.7.1.2.
2.
PatC: Is there any objection to recessing? Hearing none, we are recessed.
Recess at 1215 until 1330.
Tuesday Afternoon Session, November 15, 2005
2.2. Opening
2.2.1. Call to order
2.2.1.1.
2.2.1.2.
2.2.1.3.
Pat R. Calhoun (PatC): I call the meeting to order.
Meeting convened at 1330 hours.
PatC: Since Mr. Jokela is not here, and he was scheduled to present at this
time, we will swap presentations, taking document 1079r1 now instead.
2.3. Process
2.3.1. Presentation of Document 05/1079r1
2.3.1.1.
2.3.1.2.
Submission
Stuart Golden presented document 05/1079 r1 (on server) - Key Issues
about WiFi Location Presentation. The presentation advocates
establishment of AP location database integrity, since location information
may be critical to delivery of help or response. Whether an AP database is
valid is an important consideration. A validity metric is proposed. The need
for a control mechanism to set the measurement rate is also examined. The
presentation advocates location probe/response mechanism to support
signal strength, TOA, and TDOA location methods.
RogerD: I support what you’re doing here. I feel that some might feel that
their present radio designs don’t support the resolution you need, but I feel
that 11n-like PHYs would provide this capability because they have a much
higher sampling rate.
page 9
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
2.3.1.3.
2.3.1.4.
2.3.1.5.
2.3.1.6.
2.3.1.7.
2.3.1.8.
2.3.1.9.
2.3.1.10.
2.3.1.11.
2.3.2.
Stuart: We rely on the Nyquist rate with a matched filter to set the accuracy.
RogerD: If you are dealing with matched filters, they must be the same at
both ends of the link.
Stuart: But the filters will influence both the transmitted and received packets
at each end, and thus compensate.
Roger: In your diagram if the AP and STA have different filters, then the
TOA will “move” according to the filter used.
Stuart: The turn-around time is also included to minimize this effect.
JoeK: In a multipath environment, path effects will exacerbate the filter
problem. Moreover clock drift will also reduce accuracy. How much
hardware might it take to support these problems?
Stuart: With multipath, you can compute the time difference taking into
account multipath mitigation. The time approach almost always works better
than signal strength, which is currently used. As to the clock oscillator, the
time for the exchange is so short that the drift is not a problem.
JoeK: But the time is more than 10,000 times the required resolution!
PatC: We must move to the next presentation, so please work this offline.
Presentation of Document 05/1075r1
2.3.2.1.
2.3.2.2.
2.3.2.3.
2.3.2.4.
Jari Jokela (Nokia) presented 05/1075r1 - bc-and-mc-enhancements. The
presentation examines power save issues with bc/mc services. Power save
currently depends on the DTIM mechanism, which may incite traffic peaks
hazarding scalability with future streaming bc/mc services. Moreover
reliability of these services may be troubled due to no acknowledgements
and high error rates characteristic of the wireless medium. Currently there is
only a single and fixed power save mechanism for a wide variety of services.
Terminal standby times may vary also causing problems. The presentation
advocates bc/mc to unicast mapping to solve the difficulties and provide
more reliable service, with flexible mc service intervals. Also advocated are
RRM capabilities sent in beacon and probe response frames and ability for
non-AP STAs to advertise their capabilities. A multicast-to-unicast
conversion process is outlined. Multicast diagnostics are introduced to
determine if problems are present using TGk Triggered Autonomous
Reporting. An 802.11n “aware” method could “piggyback” many
acknowledgements to provide higher efficiency with the benefit of
acknowledged receipts from all clients.
PatC: Questions?
LarryS: I am nervous about the bc/mc to unicast conversion. It seems like
this could lead to problems .
TimO: With multiple modes operating simultaneously, there could be
considerable complexity.
2.3.3. Presentation of Document 05/1085r1
2.3.3.1.
Submission
Joe Kwak (InterDigital) presented document 05/1085r1 with companion
document 05/1084r0 providing normative text for Managed BSS Channel
Switch. BSSs switch channels primarily due to interference (e.g. radars).
Depending on power level of interferer, STAs may behave differently due to
local conditions. STAs and APs may have different priorities in selecting
alternative channels. TGh addressed Dynamic Frequency Selection for
Radar Avoidance by using a BSS announcement in the beacon. This
proposal builds on that framework by adding a protocol that allows AP/STA
negotiation, STA initiated switching, AP polling STAs for their preferences.
The AP makes the decision of where and when to switch. Each STA decides
to follow the AP switch or roam instead; if following it must acknowledge. A
protocol sequence chart is provided. The technique is said to work with both
page 10
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
2.3.3.2.
2.3.3.3.
2.3.3.4.
2.3.3.5.
2.3.3.6.
2.3.3.7.
2.3.3.8.
2.3.3.9.
2.3.3.10.
2.3.3.11.
distributed and central control architectures. Behavior is similar in approach
to Load Balancing, as reviewed earlier.
ChrisZegelin: If all access points are on different channels there may be not
many channels left. If STAs can request changes, could channel change
“storms” erupt? Also, if power-saving devices are present, one must ensure
that the notification broadcast of switching covers the longest of them.
JoeK: If the AP is part of a coordinated network, instability is unlikely and
this protocol allows the process to proceed. If not, policies can be set to
ensure stability.
RogerD: I generally support this proposal, but I do have concerns. If an AP
announces a switch to a possible radar channel there may be issues about
using the channel. If the switch is synchronized, it tells exactly when to
switch, right?
JoeK: Yes. APs must do quiet time assessment before changing channels.
This is meant to enhance TGh, but work more flexibly.
Marty: I’m not sure the power-save stations can work with such broadcasts.
JoeK: That was Chris’ second point. The broadcast has to be special so as
to ensure that all power-save devices are informed.
FloydB: If the AP changes to a channel, can that cause another station to
request a channel change due to a changed interference regime?
JoeK: There may be a ripple effect, however if the AP is part of a network, it
should have enough information to determine the best target for the switch
that produces the minimum ripple potential.
FloydB: So the implementation is up to individuals?
JoeK: Yes this is only the signaling mechanism.
2.3.4. Presentation of Document 05/1115r1
2.3.4.1.
2.3.4.2.
2.3.4.3.
2.3.4.4.
2.3.4.5.
2.3.4.6.
2.3.4.7.
2.3.4.8.
Submission
Roger Durand (Autocell) presented document 05/1115r1 - Interference
Detection and Signature Matching, with companion normative text document
05/1067r01. The presentation outlines ways that interference can be
detected using capabilities already present in 802.11 radio implementations.
The process involves measuring the noise floor and then sampling the
energy periodically in an interval. The signatures of the interference then
become apparent and may be compared and added to a catalog. Various
interferer signatures are illustrated. The capability is targeted at improved
channel selection and more rapid response to S/N degradations with
consequent high error rates caused by appearance of interference.
JoeK: This seems fundamental to characterizing interference assessment.
In TGk we had a proposal to measure these parameters (a histogram) using
long-time sampling. We considered that, but discarded it two meetings ago.
Based on that history, what do you see as the prospect for including it in
TGv?
RogerD: This is different from what was proposed in TGk, with a more
generalized approach. The trouble with “k” was that it couldn’t separate
regular traffic from interference. This actually interrupts the channel to make
this happen.
SimonB: What does congestion interference mean I the normative text?
RogerD: This is an artifact of a previous proposal, and should be removed.
SimonB: The signature examples are included as informative?
RogerD: Yes. If you measure the pulse width you can actually do a lot of
identification.
TimO: In “k” we wanted to preclude silicon changes, and that’s why we
pulled it out. What makes you think this won’t impact silicon?
page 11
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
2.3.4.9.
2.3.4.10.
2.3.4.11.
RogerD: I am very confident, having measured a vast sample of radios, that
all of them have the ability to do this now.
EmilyQ: Would you propose using the “h” method for getting a quiet period?
RogerD: A long NAV could also do this, while supporting all legacy
equipment.
2.3.5. Discussion regarding scheduling of Thursday motions
2.3.5.1.
2.3.5.2.
2.3.5.3.
2.3.5.4.
2.3.5.5.
2.3.5.6.
2.3.5.7.
2.3.5.8.
2.3.5.9.
2.3.5.10.
2.3.5.11.
2.3.5.12.
2.3.5.13.
2.3.5.14.
2.3.5.15.
2.3.5.16.
2.3.5.17.
2.3.5.18.
2.3.5.19.
2.3.5.20.
2.3.5.21.
2.3.5.22.
2.3.5.23.
2.3.5.24.
Submission
PatC: Emily mentioned that on Thursday we could get trapped on motion
language. We might run out of time, and hazard getting all the motions
completed.
JoeK: Remember of the 14 presentations we’ve had, we can eliminate 5
because they don’t have normative text.
RogerD: Some of the motions may attempt to be reworded due to
amendments, and I am concerned about running out of time.…
JoeK: I think we have very different proposals. Some need more work than
others. If we consider merging serially, with discussion. If we run out of
time, we should continue in January. I think we should avoid bad decisions
due to rushing.
Sudheer: I agree
Marty: If we run out of time, do we have a draft?
PatC: Currently we don’t have a draft.
TimO: We don’t have a draft either way, as these votes are only to merge
text into a document.
Marty: Do all 14 have to be voted upon to have “merged text”? Maybe we
should pick a preferred order to speed the process.
PatC: That’s why these have been on the server for a week
Dick: Perhaps we could use “n” time since many of the sessions have been
canceled?
PatC: There may be conflicts with “k” though.
EmilyQ: We could simplify the vote to simply “merge” or “not merge” with a
paper ballot approach.
PatC: If a contribution doesn’t make it in this time, it just means that it won’t
be in the first draft.
JoeK: Although expeditious, I think this prevents an exchange of views of
the group, which I view as important.
Sudheer: All of us seem to think we need discussion time. Isn’t there
something we can do to get more time?
PatC: Let’s have a straw poll - Should we change the process? 16 yes, 1
no, 10 abstain. Any recommendations? I heard suggestions that we
postpone the merges.
Marty: I think that’s unfair to those who have been preparing on the basis of
the current process.
FloydB: Another possibility is to wait to see how we make out using the
process, and decide later to extend if necessary.
JoeK: Moreover, I suggest that we direct the editor to include those already
approved as an interim draft.
Marty: The question is, what is a complete draft?
PatC: We could extend the motion time to the full two hours…
JoeK: We could also discard the joint session with “u”, which would give us
an extra hour.
TimO: Again remember: We are not voting text in, we are only approving
merging. Between now and the next meeting, I suggest improving the text,
page 12
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
2.3.5.25.
2.3.5.26.
2.3.5.27.
2.3.5.28.
2.3.5.29.
2.3.5.30.
so that in January we will have clean text. I see no problem with changing
the procedure so that we work systematically. We’ll still end up with a draft in
January either way.
RogerD: I have seen it happen before that a chair cooperates with another
group to facilitate progress, but we can run aground on orders of the day, etc.
We could persuade “k” from delaying its call to order to fix this….
PatC: A possible option. I like to have folks forward suggestions to me on
this. The real problem is getting a room to extend the TGv meeting time.
Sudheer: All I want is to allow people to have the necessary time to have
their questions answered.
PatC: We could do that and still continue the progress in January. What do
people want to do with the joint agenda. 3GPP sent a liaison to ask for E911
support. We are the location part of the E911 problem, which motivated joint
v/u time. We were also going to revisit the “virtual AP” work. What do
people want to do with the “u” session? Straw Poll: How many people are
against having the “u”: joint session and using the time for “v”? 15 yes, 0 no,
3 abstain.
Marty: I wish to move…
PatC; Our time has expired. I will check with the Chair and report back to
the group.
2.4. Closing
2.4.1. Recess
2.4.1.1.
2.4.1.2.
3.
PatC: Is there any objection to recessing? Hearing none, we are recessed.
Recess at 1530.
Thursday Morning Session, November 17, 2005
3.2. Opening
3.2.1. Call to order
3.2.1.1.
3.2.1.2.
3.2.1.3.
Pat R. Calhoun (PatC): I call the meeting to order.
Meeting called to order at 0800.
Last time members expressed a desire to better understand the substance of
the presentations via questions, so we have cancelled our joint session with
TGu and will use the recovered time to handle presentations, questions and
vote on merging.
3.3. Process
3.3.1. Discussion
3.3.1.1.
3.3.1.2.
3.3.1.3.
3.3.1.4.
Submission
RogerD: I suggest that we instead handle all presentations and questions
first and then have votes.
PatC: Let’s have a straw poll to continue all presentation questions now.
Yes 17, 0 No, 3 Abstain.
PatC: Very well, let’s proceed.
page 13
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
3.3.2. Presentation of Document 05/1081r0
3.3.2.1.
3.3.2.2.
3.3.2.3.
3.3.2.4.
3.3.2.5.
3.3.2.6.
3.3.2.7.
3.3.2.8.
3.3.2.9.
3.3.2.10.
3.3.2.11.
3.3.2.12.
3.3.2.13.
3.3.2.14.
3.3.2.15.
3.3.2.16.
3.3.2.17.
JoeEpstein (Meru) presented document 05/1081r0 - Proposal for Simple
Diagnostics. The presentation advocates letting the implementer own the
space of diagnostic messages, based on the belief that most stations will
have more reasons for doing things than can be assigned in TGv. The
proposal idea would be analogous to syslog. The presentation describes a
log message action frame to accommodate the function. The approach is
said to allow extensibility since a fixed catalog of error or status codes may
not cover the full range of possibilities that would be useful.
BobM: Are you suggesting that this facility should supplement a catalog of
common diagnostics such as have already been proposed? I think it will be
useful to have a foundation of diagnostics that all equipment types recognize
in addition to proprietary ones.
JoeE: Yes. I view this as a supplement with a common frame exchange
format.
TimO: I agree totally, however IE may limit you to 256 characters, which
may prove limiting.
JoeE: It may be necessary to separate the classes of diagnostics/results.
TimO: Syslog format may require standardized report types.
JoeE: Yes, and this may cause difficulty for proprietary reports specific to
particular equipment.
EmilyQ: We should make sure that the diagnostics are both human and
machine-readable.
JoeE: There’s a lot of agreement here. The important issue is that we keep
the framework extensible, since it would be hard for the standard to keep up
with all of the diagnostic needs going-forward.
RogerD: Your intention is to couple diagnostics to specific vendor OUIs?
JoeE: No, because that would be too hard to keep up to date.
JesseW: What would keep this from becoming a separate data channel?
JoeE: Nothing.
PatC: I think there should be a catalog of common and proprietary types.
JoeK: A container for proprietary information seems counter to what’s been
done in the past. Rather than a generalized container, I suggest that
vendors be required to make the proprietary information public.
TimO: This seems more restrictive than the framework already in place for
putting in syslog-like diagnostics.
BobM: I advocate a group of common diagnostics based on making
networking of 802.11 practical, like ODB-II in automobiles which became
powerful only when a common set of diagnostics was prescribed. Then
proprietary ones arose as a supplement , and later these also became public.
3.3.3. Presentation of Document 05/1087r0
JoeEpstein (Meru) presented document 05/1087r0 - Virtual APs. Beacon
information is becoming a loading consideration, since a lot of information is
now being included. Simple virtual AP support would advertise the radio the
frame is transmitted from and advert cell state operation. Adding some
complexity can still provide the necessary information without building load
unnecessarily by partially decoupling advertisement from cell state operation.
Doing such would merge the different BSSs into one while preserving most
of the semantics as today. BSSs would take turns transmitting beacons. It
would act like a “root” BSS with coupled supplementary information.
Submission
page 14
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
TimO: I was thinking about how the root BSSID gets coupled to all the
others. How does the root (0 address ID) couple to the others? How do I
know which of all the others are coupled?
JoeE; In this presentation, that wouldn’t be supported, but it might be added.
I loathe adding mapping, though, because I don’t like that construct.
TimO: So a group would have the same root BSSID, which could be a
pattern matching problem since clients would have to keep lists of coupled
BSSIDS, and this could be processing intensive.
JoeE: That was a requirement that we should address anyway. The other
issue is how to scan and “collect” BSSIDs. When you receive a sub-BSSID,
you could trigger a scan to look for the others. I don’t think I really envision a
strong need for scanning
BobM: I think this is a good idea for lowering overhead, which will be needed
going-forward to cope with ever-growing system information needs. I see
parallels to TDMA systems with hierarchical frame sequences that contain
progressively more information, but transmitted less often.
JoeE: Yes cutting overhead was the thrust here.
Peter: I have another approach on this.
TimO: If I’m trying to build hash tables linking many BSSIDs, that could be
troublesome. Experience shows bitmapped coupling works well for this, at
low processing complexity. It will be important to determine which virtual
APs are part of the “root”.
JoeE: I have some difficulty with a map, but I think if we started somewhere
we could add on and make the idea better. Regarding Peter’s observation, I
think adoption of this one would allow us a starting point that we could build
upon.
3.3.4. Review of Proposals for Questioning
PatC: Let’s begin with Emily’s presentation of Load Balancing 1065r0.
TimO: I am unclear about the use of roaming list vs. neighbor list. Why do
we need both?
Emily: The neighbor report is less dynamic. The roaming list is more “realtime”.
TimO: There is nothing in “k” that indicates it’s not real time. I’d hate to add
another message structure when one we have already would be usable.
Marty: The neighbor list is not “static”, it just contains information that
frequently doesn’t change.
JoeK: When will we discuss what a TGv terminal will be? Will all terminals
that handle “k” also support “v” or not? Tim assumes that all “v” terminals will
have “k”. We have to answer this bigger issue.
JoeE: The neighbor list doesn’t exactly couple to the load balancing function,
and as such has to be interpreted. This proposal suggests a mechanism
directly coupled to the purpose.
TimO: Buy why have a different frame and build overhead and complication?
Seems simpler to build on what already exists? I would like to move to
complete Q&A. for all the presentations to save enough time for the
acceptance process.
PatC: You have a motion prepared?
TimO: Yes.
Move to amend the agenda to postpone the TGv merge vote to after the
Q&A session for the individual proposals.
Moved: Tim Olson
Seconded: Sudheer Matta
Submission
page 15
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
PatC: Discussion? Yes
RogerD: This seems inappropriate. I fear that with the Q&A and when the
motions are presented we will run out of time because the discussion on the
motions will amount to another Q&A.
PatC: We’ve already taken a lot of time just on Emily’s proposal.
JoeE: I am concerned as well. I’d like to see votes extend to January.
BobM: I support JoeE’s January vote extension proposal.
JoeK: I agree with Roger and JoeE. We should flush out the questions and
then resolve to do all of the voting at this meeting. We should vote serially
on each presentation, and continue in January if necessary. We could get a
time concession from TGk. Our editing tasks would also be simplified.
Marty: I’m confused about running out of time. Is it for this meeting?
PatC: Yes we must close at 12:30 today.
HarryWorstell: Point of order. You are not allowed to change the meeting
on such short notice, as requires “notice” time when doing so.
Marty: We need to talk among us before voting and the current process
might lead to the possibility that a very small number of people could control
the process for keeping material in the draft going-forward.
RogerD: The questions may overlap so a vote on each could cross-impact.
TimO: This is not an editor issue, as there will not be a base draft in January
anyway. If we limit discussion now, we would have so little time to vote it is
not reasonable. I think it is not likely we could finish. I support getting
together in January as many of the current proposals could merge as we go
toward January.
PatC: But we had a process in 918r2.
JoeE: I would like to amend the motion to say:
Move to amend the agenda to postpone the TGv merge vote to after the
Q&A session for the individual proposals, with the voting starting no sooner
than the January 06 meeting.
Seconded JesseW
PatC: The mover accepts the amendment? Yes.
Marty: I call the question.
PatC: Do I hear any objection calling the question for the amended motion?
No.
RogerD: Point of Order: Has the amendment been approved?
PatC: Yes, the amendment has been accepted. Is there any objection to
calling the question? No.
Vote is 33 Yes,1 No, 7 Abstain The motion passes.
PatC: The questioning continues. Roger Durand is next.
Roger Durand accepts questions on documents 1069r0 and 1126r0.
JoeK: I have the strong opinion that incorporation of specific algorithms is
bad practice.
FloydB: I disagree.
BobM: I feel that this was a hard lesson learned by cellular, since not
specifying them can lead to system difficulties.
Emily: But I suggest more than one be adopted.
BobM: In my experience, more than one is more dangerous because of the
need to evaluate all possible interactions which could lead to instability.
Marty: Do you recommend mandatory or optional treatment?
FloydB: I vote mandatory.
Submission
page 16
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
JoeE: It seems like it will be hard to put in just one algorithm. I suggest a
number of authorized ones with specified behavior based on whether or not a
client supports them. The chosen ones would have to be shown to
converge.
Floyd: I’m OK with this, but feel that convergence is required and is implicit.
TimO: I think other groups have had trouble with this, and it might require,
for example, having to harmonize the standard with IETF, etc. I’m also
worried about behavior in a highly mobile environment.
FloydB: I hear that you want enhancements. We have looked at those, but
we wanted to make the proposal understandable, but extensible. I think I
heard that you’re not against an algorithm, but that it needs a governing
system.
SudheerM: The algorithm’s behavior is likely to be dependent on beacon
interval. If the beacon interval changes, can we show that the algorithm still
works?
Floyd: We could bring in simulations to show that. We chose this algorithm
to be tolerant of these effects.
JesseW: I speak strongly for this algorithmic inclusion as you must assure
that the network doesn’t collapse. But we have to make sure that it works in
all cases and is “bulletproof”. I advocate mandatory.
TimO: I’d like to see how security issues would be handled and the
infrastructure implications, e.g. layer 2 as well as layer 3 impacts.
FloydB: I perceive a “Catch-22”. We may not be able define an algorithm
without layer three, so we must use layer 3 to make it work.
TimO: Both your submission and PowerPoint doesn’t talk about how
messages are exchanged.
LarryS: Simon asked about this on Tuesday. I added the clause 10
messaging found in an 11 “r” draft. The bids and accepts are data frames
sent through the associated AP. All the messages and responses can be
accommodated.
FloydB: The protocol was specifically designed to accommodate non-reliable
transport.
JesseW: It’s not necessary to cover all of the functions without assuming
some additional back end protocols (experience from “i”). It’s better to build
a robust system that spans standards.
BobM: Floyd, I’d like to ensure that the contribution is expanded to betteraccommodate QoS as this will become an important driver for having a
coordinated network going forward, such as multimedia services and high
speed capabilities (such as “n”) will provide.
FloydB: We agree that this has to be included and we welcome and solicit
additional contributions to make this part of the capability going-forward.
TimO: I thank Jesse for his inputs. It will be necessary to make sure that all
layer 2 and layer 3 capabilities are there in order to make this work.
Emily: We want to extend 11v to be compatible with back end applications.
Also VoIP and QoS will be critical components of load balancing.
PatC: Next we have Roger Durand with documents 05/1125 and 05/1066.
covering channel selection. Are there any questions for Roger? No.
PatC: Next we have Emily Qi with documents 05/1070 and 05/1224,
Proposal for Diagnostics and Troubleshooting. Any questions for Emily? Yes.
JoeK: Based on the earlier discussion about overlapping with other
diagnostic schemes, what is the author’s opinion about whether a merge with
JoeE’s proposal is practical?
TimO [With Emily]: I believe these are compatible. However this one uses
an action frame. Joe’s is limited to an IE’s maximum of 255 bytes and this
Submission
page 17
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
could be too restrictive. A regular syslog might easily exceed this constraint.
We are philosophically well-aligned, though.
JoeK: What is your view about the practicality of a client’s need to
accommodate logs and the like? Triggering background operations,
although a good idea, can severely tax the processing capability of many
clients. It seems like the idea is catching on, but how much resource might
this take?
Emily: Some vendors already have implementations (event log) kept locally,
and it does not seem to cause trouble.
TimO: I am more worried about the memory demands rather than the
triggered processing, since most of the variables are MIB-based anyway.
Depending on how often data is collected, memory demands could be
significant.
JoeE: Extensibility?
TimO: [Shows Event Log Type definitions] We can go to 255 log type
definitions. Years from now, a new log type can be added. Vendors can add
their own new syslog based on the type. The system won’t know what the
fields are, but the information exchange can be accommodated within the
framework.
JoeE: What about the fixed fields? Isn’t that restrictive?
TimO: We could have another set of log elements to accommodate different
reports with different amounts of information.
JoeE: Is there a way that a vendor could customize this using categories
and sub-categories for vendor-specific information?
TimO: I have trouble about making decisions about how much freedom a
vendor can have.
JoeK: Now that I understand that, why don’t you implement some things
such as software code events---not a trigger, but like an address to show that
a debug event happened. Why be so restrictive? If implemented all stations
in the network could be monitored for a rare event. Some manufacturers
may be able to use this.
TimO: I won’t comment on the usefulness. In terms of the structure we are
proposing, if it’s a specific enough thing, you can add a log type and specify
the information to be sent back. If you want to send back a syslog, you can
fit it into the schema.
Emily: I don’t understand Joe’s question.
JoeE: If you were more extensible, there would be more potential for diverse
uses.
TimO: What is the ability to handle arbitrary information if you don’t know
how to interpret it?
BobM: A philosophical concern: With overlap in “k” and “v” I’d like to
understand how the triggering and logging functions are partitioned so that
there are no outages or conflicts.
PatC: We must recess for the break now.
3.4. Closing
3.4.1. Recess
3.4.1.1.
3.4.1.2.
Submission
PatC: Is there any objection to recessing for the break? Hearing none, we
are recessed.
Recess at 1000.
page 18
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
3.5. Opening
3.5.1. Call to order
3.5.1.1.
3.5.1.2.
3.5.1.3.
3.5.1.4.
3.5.1.5.
3.5.1.6.
3.5.1.7.
3.5.1.8.
3.5.1.9.
3.5.1.10.
3.5.1.11.
3.5.1.12.
3.5.1.13.
3.5.1.14.
3.5.1.15.
3.5.1.16.
3.5.1.17.
3.5.1.18.
3.5.1.19.
3.5.1.20.
3.5.1.21.
3.5.1.22.
3.5.1.23.
3.5.1.24.
Submission
Pat R. Calhoun (PatC): I call the meeting to order.
Meeting called to order at 1031.
PatC: Emily, you are still handling questions. Are there any more questions
for Emily? No. Tim Olson, are you ready for questions?
TimO: Yes, I shall entertain questions on 05/927r2 and 05/1083r0. However
I would also like to know if the group feels we should really do this.
LarryS: I had some concerns off-line, regarding private MIBs. Tim thought
we could change the text to include a “compressed” using a supplementary
field where one was fully-qualified IEEE, as well as other separate ones. On
the web, there are MIBs with extensions greater than 255. On the SNMP
issue, having had experience with clients, SNMP would work OK. There are
implementations now that use SNMP, but others that also support proposals
such as this.
JoeK: I like this approach, but I think it’s incomplete. We can agree that it is
incomplete and can add it as we go along.
TimO: We should go ahead, but I am not sure that over the air we can
assume layer 3 is in place.
JoeK: The PAR says we are doing interfaces to upper layers.
PatC: The PAR says the MIB is accessible.
JoeK: I’m not saying that an AP MIB interface is not useful.
Sudheer: I’d like to understand the security aspects of this. I strongly
support the presentation, but would like to know about this.
TimO: Emily and I have talked about the access issue, and we concluded
that we could not submit anything. TGw will be great for protecting over the
air frames, but it won’t actually handle access to MIB permissions. We view
this as a separate issue. We need a solution for that, and it’s not addressed
in my presentation.
Sudjeer: What connections do we have with “w”.
PatC: We contacted them early-on, so they know that linkages exist and
have to be worked jointly.
Emily: We should work with “w”.
Sudheer: However, I think we should lead here.
JoeE: We may not be able to send these things until layer 3 is “up” anyway.
LarryS: SNMP requires a lot of stuff. I’d like to hear more feedback.
BobM: This information is close to the “nuclear core” of the 802.11 MIB. I
believe penetration in clients will depend on complexity, and this will keep
cost lower, and thus allow the solution to propagate into more devices. Also
the non-SNMP approach means a less-uncontrolled linkage to another
standard.
PatC: Any more questions? No. Simon, are you ready?
SimonBlack: Yes I am prepared for questions on 05/1066, and Powerpoint
05/1077 on Triggered Protocols.
TimO: Are all triggers set by the action category?
SimonBlack: Alerts will be coupled to measurement type along with triggered
measurements for diagnostic tests.
TimO: I’m confused about trigger-response limitations w.r.t. the QoS frame.
If all you do is want to get information, it seems inappropriate to couple it to a
triggered overhead, as this tampers with an already-present measurement
page 19
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
3.5.1.25.
3.5.1.26.
3.5.1.27.
3.5.1.28.
3.5.1.29.
3.5.1.30.
3.5.1.31.
3.5.1.32.
3.5.1.33.
3.5.1.34.
3.5.1.35.
3.5.1.36.
3.5.1.37.
3.5.1.38.
3.5.1.39.
3.5.1.40.
3.5.1.41.
3.5.1.42.
3.5.1.43.
3.5.1.44.
3.5.1.45.
3.5.1.46.
3.5.1.47.
3.5.1.48.
3.5.1.49.
Submission
program. If this is a case where information delivery only is needed, it seems
like LCI is a better way to go.
SimonB: I agree. However, this mechanism doesn’t stop you from doing just
that.
PatC: Any other questions on this proposal? No. Roger, are you ready?
RogerD: I am ready to accept questions on documents 05/1068 with
05/1114 Powerpoint – MultiRFPower.
BobM: Are there any simulations on this? I think this issue is so
fundamental to system operation that folks may appreciate some assurance
that the change does not cause troubles.
RogerD: I can bring simulations to the next meeting.
TimO: Can you elaborate on power modification in the case where you have
reduced the sensitivity with respect to the local power constraint? Do I have
to hear the neighbor?
RogerD: [Describes an example implementation]
TimO: Is that in your proposal?
RogerD: No, but I could bring other examples?
JoeK: You are regulating two different parameters, which could be viewed
as a PHY change. There seems to be two ways to do this, so are you sure
that doing a PHY change is the right thing to do instead of the MAC?
RogerD: This is not a PHY change, but rather controlling the PHY through
the MAC.
JoeK: You’re saying that no manufacturers will have trouble with this
because everybody’s implementation can do this?
RogerD: Yes.
JoeK: I think it might be useful to try a different approach just to avoid
trouble in case this isn’t universally true.
JoeE: It seems to me that we have to be careful about “twiddling” the PHY in
comparison to ignoring things in the MAC, however I think we could
accommodate both approaches.
TimO: Your power control element goes in the beacon?
RogerD: Yes.
TimO: Clients, in my experience, do not necessarily follow every beacon.
Might we have to add language to force tracking of all beacons?
RogerD: That’s a good point. If you have an 11h client, you are required to
listen to this, but if not we might have to have a “required listening” feature.
Emily: I’m concerned about the beacons getting bigger and bigger.
Roger: The intention of this is to enable a dynamic capability rather than
static so that clients/APs could respond to conditions, say , in a room. If you
are associated, you can handle this.
BobM: This is a good opportunity to dovetail with the beacon/sub-beacon
approach proposed by JoeE. The dynamic nature of power control has a big
effect on how a radio network works, and we could set language that
specifies the sampling rate and dynamic capabilities of power control to
ensure stability in the network.
Larry: There are provisions in “j” that might interact with this.
LarryS: There is no intention to “kill” clients by using this power control
capability, and I think we can work around it.
JoeE: I’d like to build on Bob’s comment about ever-growing beacons. We
have to address the rate at which beacon information can change the system
networking parameters. If there are many clients that ignore beacons, that
page 20
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
3.5.1.50.
3.5.1.51.
3.5.1.52.
3.5.1.53.
3.5.1.54.
3.5.1.55.
3.5.1.56.
3.5.1.57.
3.5.1.58.
3.5.1.59.
3.5.1.60.
3.5.1.61.
3.5.1.62.
3.5.1.63.
3.5.1.64.
3.5.1.65.
3.5.1.66.
3.5.1.67.
Submission
would be a problem. We’ve got to nail down how stations will react to
beacons.
LarryS: If it’s a new type of management frame than that could be
accommodated, and would not impact the beacon behavior, that might also
be a solution. Otherwise, we’ve got to define the rules under which clients
will react to beacon information.
TimO: This is definitely a dynamic field. In “k” and “h” I added language that
cautions changes have to be applied carefully. I support the sensitivity
adjustment approach.
JoeK: But I’m not sure this does enough to extend to all of the possibilities
that could occur going forward from “h”. How do we get to the things we
really want to control? I don’t see how we get to all these things from this
foundation.
RogerD: This is a simple first step, that gives maximum gain from minimum
complexity. If there is something that you see could prevent per-station
power control, I welcome your suggestions. I feel that per-station control will
deliver less benefit compared to this, but with considerable complexity
overhead.
Emily: We must also examine the protection for beacons and adding system
disruption vulnerability.
RogerD: The field exists now. So I see no threat greater threat than exists
now. The worst case scenario would seem to be possible now, even before
adding this capability.
TimO: “h” indicated no protection for minimum power constraint hacking and
this was also brought up in “k”. However we added text to caution against
lowering the local power constraint to the point where communication can’t
occur.
JoeE: I believe Emily has opened a good point. I would like to see “w”
address this. I’d also like to say w.r.t JoeK’s comment regarding individual
power control, that we have to do something about this. But it could prove
intractable.
JarkkoKneckt: There is normally sensitivity to the number of clients involved
in most power control schemes.
RogerD: If we can maximize the capacity of the network with this, that’s the
objective. In a particular cell with lots of clients, this devolves into a load
balancing issue.
LarryS: With one AP alone on the channel, you’re not backing off power.
Emily: With load balancing, is there any relationship that we should be
looking at.
RogerD: The amount of capacity available to the network is one point; the
amount available to each client is different. The RF loss and channel
occupancy is the important part for load balancing. You want to make sure
that the best links can be produced because a client’s channel occupancy is
very short at higher speeds.
TimO: But one has to load balance not based on number of clients, but
rather the amount of data that will be communicated.
RogerD: Yes. I concluded that future throughput can’t be predicted by past
throughput.
TimO: Fortunately, we now have TSPECs which better define what clients
will actually require in terms of resource allocations.
JoeE: It seems like it will be easy to tell when you should be doing this and
when not.
PatC: Any other questions for Roger? No. Jarkko Kneckt. Jarkko,you’re
your ready?
page 21
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
3.5.1.68.
3.5.1.69.
3.5.1.70.
3.5.1.71.
3.5.1.72.
3.5.1.73.
3.5.1.74.
3.5.1.75.
3.5.1.76.
3.5.1.77.
3.5.1.78.
3.5.1.79.
3.5.1.80.
3.5.1.81.
3.5.1.82.
3.5.1.83.
3.5.1.84.
3.5.1.85.
3.5.1.86.
3.5.1.87.
3.5.1.88.
3.5.1.89.
3.5.1.90.
3.5.1.91.
3.5.1.92.
3.5.1.93.
3.5.1.94.
3.5.1.95.
Submission
Jarkko: Yes I am ready to accept questions on 05/1072r0 with Powerpoint
05/1073r1.
EmilyQ: Do you have any simulations showing power-saving benefits with
the scheduled approach.
Jarkko: Yes.
PatC: Can you bring this with you in January?
Jarkko: Yes.
JoeK: I think I may be missing something. What happens when something
goes wrong with the channel. A nice feature about non-scheduled is that it
has a built-in recovery mechanism. Likewise the polls in HCCA make the
process-self recovering. Is there a way that the value is jeopardized if drifts
occur absent these mechanisms?
BobM: It would be helpful if you could bring data to show how this process
would work to save power when, say, cellular and 802.11 are working
concurrently, as with dual-mode phones. Also schedulers in HCCA would
have a recovery if too many exchanges are missed.
Jarkko: Yes, I can bring information, but it is hard to assemble for concurrent
operation.
JoeE. To Bob’s point, with HCCA I acknowledge that the scheduler will
recover from missed frames, but here small drifts in awakening could cause
trouble. I am concerned with implicit synchronization timing, so that overruns
begin to occur. If you provide guard times to combat this, then you waste a
lot of airtime.
BobM: I think I didn’t fully understand Jarkko’s concept. Thank you for
helping me. I agree with your comments.
PatC: Jari Jokela is next, however I want to put a placeholder motion in
place for Teleconferences in preparation for tomorrow’s plenary…
Motion:
Move to hold teleconferences on a weekly basis, starting December 6th, 2005
at 12 AM ET.
Moved: Dick Eckard
Second: Roger Durand
Any discussion? Yes.
SeanC: The Peking time is 1am.
Emily: Perhaps we could use morning or evening.
RogerD: We accommodate a lot of people by putting Pacific participants at
the crack of dawn so that Europe would be late at night.
Friendly amendment:
Move to hold teleconferences on a weekly basis, starting December 6th, 2005
at 10 AM ET.
SeanC: Could we use 9pm Eastern.
PatC: That’s 2 am Europe.
RogerD: I accept the amendment
Anyone objection to passing the motion? No. The motion passes
unanimously.
PatC: We now return to Jari Jokela’s presentations, documents 05/1075 and
05/1074.
TimO: What do you think about the efficiency “hit” of converting multicast to
unicast?
Jari: Always a tradeoff. If it is not feasible from a capacity standpoint, you
shouldn’t do it.
page 22
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
3.5.1.96.
3.5.1.97.
3.5.1.98.
3.5.1.99.
3.5.1.100.
3.5.1.101.
3.5.1.102.
3.5.1.103.
3.5.1.104.
3.5.1.105.
3.5.1.106.
3.5.1.107.
3.5.1.108.
3.5.1.109.
3.5.1.110.
3.5.1.111.
3.5.1.112.
3.5.1.113.
3.5.1.114.
3.5.1.115.
3.5.1.116.
3.5.1.117.
3.5.1.118.
3.5.1.119.
Submission
TimO: I understand you are leaving it up to the coordinator to determine if
the mapping is done?
Jari: Yes
JoeE: When you transmit a multicast as unicast, you lose information in the
address. Are you expecting any consequences? A unicast L2 frame may
look something like its spoofed and a client might drop it. How will you
indicate that a mapping has occurred to prevent a client from ignoring it?
JariJ: Station implementation should make sure this is handled correctly.
JoeE: I don’t think this is practical. If there are arbitrary services, you have
removed information that would prohibit the client from properly reacting.
JariJ: I agree that there could be cases where this would happen. Originally
this was only to address IP-Level multicast.
LarryS: This could work OK with specific stations that very well know what
they’re doing, but it could be pretty difficult for generic clients. You would
have to be really smart to properly do this. Bridging would also be a
problem, because the content wouldn’t go through a bridge. Also, it appears
the first legacy station to join causes default back to regular behavior,
though, so virtually all stations would have to be “smart”.
TimO: A client might have to snoop into a lot of packets in order to
determine which packets to throw away if both are running at once.
Jari: Yes.
Jarkko: A special port address could be used for this purpose.
Marty: Did I read in the TGe spec that multicast is handled differently (e.g.
multicast ACK)?
JoeK. Your presentation suggests that the conversion could be done without
losing something. Have you examined “n” acknowledgement methods? It
seems like it would be more useful to only use it for clients that need it using
unicast? Is that included here, or left to the future?
JariJ: I view this as an AP implementation issue.
JoeK: You’re not proposing any kind of multicast ACK? I think this is a
critical issue if you use the conversion. Maybe we should give “n” more time
rather than using this, because it could really “chew up” resources. We really
need feedback.
PatC: Any more questions? No. Bin Wang, can we have one slide
clarification of the Adaptive Rate Control proposed in the ad-hoc Monday?
Bin Wang presents added illustrative slide in 0630r2 (r2 showing example
process) for dynamic rate adaptation. Bin Wang describes the process by
which the forward channel quality evaluation works with handshake to
change rate at both ends of the link.
TimO: 802.11 already has a rich rate control capability, but this seems like a
lot of overhead. I would favor a “lighter” approach.
Emily: This is the concept, just the recommendation.
JoeE: The graphic helped, but are you proposing that TGv work this issue,
or adopt this method?
SeanC: This just shows a way the benefit could be captured, not a specific
way.
JoeK: I don’t think we need a new requirement for adaptive rate control,
because it is connected so closely with power control and it’s already in
scope. We welcome progress and contributions in this area.
PatC: But following procedure, let’s have a straw poll.
Straw Poll: Should TGv take Adaptive Rate Control as a new objective?
9 Yes, 1 No, 6 Abstain.
page 23
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1171r1
3.5.1.120. PatC: Very well, adaptive rate control is “in”. JoeK, are you ready for
questions?
3.5.1.121. JoeK: Yes, I am ready for questions on 05/1085r1 and 05/1084r0 on channel
switching.
3.5.1.122. PatC: I’d like to note that if we do not have time to complete this item, we will
resume at the next meeting following the agenda, patent instructions, etc.
3.5.1.123. LarryS: Did you intend the channel switching element as a new frame?
3.5.1.124. JoeK: The channel switch is now a new category in a management frame.
3.5.1.125. TimO: Is this to assist channel change for any reason at all, say with “h”?
3.5.1.126. JoeK: I view this as generalized, but I believe it can be used to enhance “h”
has well. [revisits the process].
3.5.1.127. TimO: APs may already have much of the information to do this using
today’s capabilities. I am unclear about what one is getting from the
additions.
3.5.1.128. JoeK: I agree.
3.5.1.129. TimO: What do you get out of the TGk measurements?
3.5.1.130. JoeK: You can run a scan on all possible neighbors, as now you have no
way of retrieving the best roaming candidate in terms of frequency, only BSS.
3.5.1.131. TimO: If I’m going to change to a new channel, why do I care whether all
clients will want to follow me?
3.5.1.132. JoeK: We don’t have any measurement in “k” that could provide the same
capability.
3.5.1.133. TimO: Can I get a quick summary of the response part of the proposal?
3.5.1.134. JoeK: There is a lot of context info in an AP that will require influence the
switch. This is a way to establish who’s staying and who’s going. Right now
there is no handshake to make sure that sessions in progress are preserved.
3.5.1.135. LarryS: Did you consider where a management report of interference on the
channel could be used to precipitate a switch with a number of channel
trouble measurement notifications?
3.5.1.136. JoeK. The AP can query the others who didn’t announce trouble after it gets
one trouble report.
3.5.1.137. PatC: We are out of time. I’d like to encourage people with similar proposals
to consider merging ASAP. If these are voted on as merged in January, that
would be more efficient, saving us a lot of meeting cycles.
3.5.1.138. JoeK: I thought merging was an editor function?
3.5.1.139. PatC: Our process document 918r2 states that people with similar material
have the responsibility to merge, not the editor.
3.5.1.140. JoeK: Who’s merging? My material is already merged.
3.5.1.141. PatC: The process is documented, and individuals are required to follow the
process. We are out of time.
3.6. Closing
3.6.1. Adjourn
3.6.1.1.
3.6.1.2.
Submission
PatC: Is there any objection to adjourning? Hearing none, we are adjourned
for this meeting.
Adjourn at 1232.
page 24
R. R. Miller, AT&T
November 2005
doc.: IEEE 802.11-05/1237r0
IEEE P802.11
Wireless LANs
TGw Meeting Minutes November 2005 Plenary Session
Date: 2005-11-17
Author(s):
Name
Nancy
Cam-Winget
Frank Ciotti
Company
Cisco Systems
Motorola
Address
3625 Cisco Way,
San Jose CA 95134
7700 W. Parmer Lane PL67
Austin, TX 78726
Phone
+1-408-853-0532
512-996-5753
email
ncamwing@
cisco.com
frank.ciotti@
motorola.com
Abstract
Minutes of the 802.11 TGw Task Group meeting held during the IEEE 802 November 2005 Plenary
Session in Vancouver, Canada, from November 14th – 18th, 2005.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Minutes
page 1
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1237r0
Monday, November 14, 2005, 4:00pm
Call to Order
Meeting called to order
Chair: Jesse Walker
Secretary (Acting): Nancy Cam-Winget
Chair: Go to the IEEE concierge’s desk and sign in once a day. The chair reviewed slides on the
following:
•
•
•
•
•
•
•
Membership & Anti-Trust
IEEE-SA Standards Board Bylaws on Patents in Standards
Inappropriate Topics for IEEE WG Meetings
Request to review of selection procedure:
o In September, 5 proposals were presented with slides only
o This meeting is expected to have presenters include draft text. At this meeting, we need
to look at the proposed text to see if any of the text will meet the TGw requirements
o January meeting will have vote to adopt some of the text as the basis of the TGw draft.
DoCoMo did not submit any draft text, but would still like to present their proposal. Their
proposal will be a technical presentation versus a proposal presentation.
BUMP Proposal Presentation by Kapil Sood Doc #: 11-05-894r2
o Propose to protect unicast and broadcast management frames. Confidentiality for unicast
only and forgery protection for both unicast and broadcast management frames.
o Proposal text is in Doc #11-05-1045r1 on the reflector.
o Discussion of design goals
o Overview of BUMP proposal including unicast management protection reusing CCMP
and TKIP from 802.11i and introduction of BIP for broadcast with special consideration
for disassociation and deauthentication. Finally, policy mechanism of multiple unicast
protection (MUP).
o Discussion of MUP and analysis of alternatives to broadcast management frame
protection.
o Discussion of TKIP and market need to allow for field upgradable solution. TKIP
composition is similar for management frame as that of data; however header needs
protection so introduction of header clone IE is required.
o Discussion of broadcast management frames. Important note that the MIC is required to
allow for the mixed mode to persist and allow backward compatibility.
ƒ Why not just use the AES-CBC component of CCMP? We want to add as little
overhead as possible. It should not require hardware changes. Some are
concerned that there may be a required hardware change.
ƒ Discussion on the use of SHA-256 vs. SHA-1; this proposal includes SHA-256 to
better address forward looking issues and requirements (by NIST). Request is
that whatever proposal TGw adopts will require outside security review.
o Discussion of “no good single solution” for protection of broadcast management frames.
o Discussion of draft text
ƒ Discussion that protection of TKIP header is required to ensure attacker can not
swap frame types between data and management.
Comment: first opportunity to adopt the draft is at the next meeting. Is there a way that this text
could get adopted at this meeting? If this approach is adopted, then text is owned by the entire
membership versus the proposal members, so it may be beneficial to have it adopted as a draft
sooner rather than later.
o Chair rules that under current selection process, commenter is correct that we can not
adopt until the next meeting. Although one could modify the current process and the
group could consider the new procedural rules.
Minutes
page 2
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1237r0
Commenter: should we have the process updated and up on the reflector to meet the 4
hour rule.
o Commenter: looking at the process slides, this meeting can have a “yes” and “no” vote.
So we have to do at least that. Chair recognizes that as a minimum unless the process is
changed.
o Commenter: after that vote, then someone could make a motion to include the proposal as
the first draft; chair could rule it out of order. Though 75% vote could change anything.
Suggestion is to do the vote but make sure we go through the other proposals.
o Commenter: concerned that we are not going to get through all the proposals this week.
Straw Poll: “ Should BUMP proposal (11-05-1045r1) be included in the first draft”?
o Yes: 16
o No: 0
o Abstain: 0
o Comment: does this mean that we can not vote for other proposals? Chair is willing to
allow affirmative votes for other proposals as well, so all proposals may be included as
part of the TGw draft.
Commenter: we had a strict requirement that proposals should not require a hardware change. So
what happens if the group determines that it needs a hardware change? Chair recognizes that if
the group determines that is the case then we would have to revisit the proposal.
Presentation by Jon Edney Doc #: 11-05-1063r0
o Abbreviated version of this morning’s presentation
o Discussion of whether the lockout problem is that critical
o Comment: does 802.11i state what it should do when it receives a (re)association request
that in unprotected? Response is that currently it has to.
Presentation by Jon Edney Doc #: 11-05-1094r0
o Discussion of Dynamic Wireless Medium Address
o Discussion of whether PTK derivation needs to include the AMID or the base MAC
address.
o Review of proposed draft text
o Comment: would this be optional or mandatory? Response: yes, it would be optional.
o Comment: keeping state is required in either place but the multiplexing for the two
addresses may require a new encapsulation?
o Comment: if an attacker can spoof the MAC address, they can also fake the DWM; so the
multiplexing problem is still there.
o Comment: premise is that key state is lost, so need to overcome this state. How likely is
it to occur? Response: if reboot during a software crash or unexpected or uncontrolled
reboot.
o Comment: what happens if you add a 4th option to accept the request and delete the state?
Response: there may be a DoS attack if you keep having to reassociate
More Q&A will continue in next session.
Recess until Thursday November 15 2005 1:30
o
•
•
•
•
•
•
Thursday, November 17, 2005, 1:30pm
Meeting called to order at 1:36pm
Secretary (Acting): Frank Ciotti
Chair: Last we were hearing comments on Jon Edney’s proposal. Any further discussion?
None
Submission: 05/0895r2 – Marcus Wong – Broadcast Forgery Protection
Detailed proposal in doc 05/1052r0
Minutes
page 3
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1237r0
Discussion:
Comment: Is there any normative text?
Marcus: No.
Comment: Looks like micro Tesla. Is synchronization necessary?
Marcus: Synchronization is not required.
Comment: Synchronization is required to prevent forgeries, or it must be replaced with something else.
Marcus: It is our opinion that synch is not required.
Comment: It is suggested that a proof be performed.
Comment: There is an issue with how the key chain is generated. 802.11 has a high PER. The AP can
only compute a finite number of keys. The AP may have to stop transmitting broadcasts to rekey the
IGTK. The IGTK is being reused.
Marcus: We can use different keying material or derive a new key instead of using the IGTK directly.
Chair: The next step is to have a vote on the 3 proposals:
• 05/895r2 Tesla
• 05/1045r1 BUMP
• 05/1094 DWMA
Jon Edney asked the chair to for an agenda item to be added for an update on BUMP
Selection Process Vote:
The proposal is worthy of further consideration:
895r1 – Modified Tesla
Result: Yes:19, No:1, Abstain:8
1045r1 – BUMP
Result: Yes:15, No:1, Abstain:13
1094 DWMA
Result: Yes:11, No:0, Abstain:15
Submission: Jon Edney doc 05/1045r2 – Normative Text for BUMP Proposal
Updates to BUMP text based on discussions and feedback.
Discussion:
None
Motion:
Move to terminate with immediate effect the adopted selection procedure described in doc
11-05-0717-01-000w-tgw-selection-process.ppt and instruct the editor to create TGw Draft
0.0 by incorporation of the text contained in doc 11-05-1045-02-000w-normative-text-bumpproposal.doc
Moved by Jon Edney
Minutes
page 4
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1237r0
Second: Thomas Maufer
Discussion:
Comment: I want to make sure this does not preclude any further proposals.
Jon: No
Comment: Is 75% still required?
Chair: Yes, since this will be the new draft which requires 75% approval.
Comment: How is r2 different from r1?
Chair: Editorial changes
Comment: Do the other 2 proposals still carry forward?
Chair: Yes
Call the question
Chair: Any objection to calling the question?
None
Chair: Question called
Vote: Yes:16, No:0, Abstain:5
Motion Passes
Chair: I encourage all members to work towards harmonization on the proposals.
Submission: Shlomo Ovadia 05/1058r1, 05/1059r0 – STAKey Design Flaws
Discussion:
Chair: Is this work necessary?
Shlomo: I’ve seen PAR changes happen all the time. Since many of the security experts are in TGw, it
would best to solve this problem here.
Comment: There is no mechanism to negotiate the cipher. Would that be included as well?
Chair: We would want to address all of the problems it makes sense to address.
Chair: There are several options:
• 802.11 doesn’t want to fix this
• 802.11 does want to fix it, but not in TGw
• 802.11 does want to fix it in TGw.
Comment: At the time 11i was completed, DLS wasn’t complete as it was part of TGe. If it is viewed as
part of 11i, the SB ballot comments should happen now with 11ma. If viewed as deficiency of 11e, then
wait until re-circ of when 11e is incorporated into spec. Task Groups that complete on time don’t go
outside of their PAR. The argument that TGw is the Task Group to fix this problem because all the right
people are here and not because it is work that should be done by the Task Group does not make sense.
Comment: Several 11i members gave suggestions to 11e on how to fix this, but they were not
incorporated. We may find more issues that are QoS related as well security related, so this may not be
the best place to solve this problem. Also, we need to be careful of feature creep.
Minutes
page 5
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1237r0
Shlomo: We would like to see this problem resolved quickly as possible, and the people in this TG as
well as from TGe are the right mix to do this. If the PAR requires a change, this should not be avoided.
Comment: This should be a maintenance item. It would finish quicker via maintenance rather than going
through TGw.
Comment: Rather than focusing on whose fault it was, we should focus on what is the quickest solution.
Given that, it would be much quicker to attempt to resolve this in the maintenance PAR. While PARs can
change, it is frowned upon, and will consume time away from the real work in TGw.
Shlomo: My concern is that we may have a smaller body of reviewers if we choose the maintenance
route.
Comment: It is incumbent upon the people that present in TGm to have all of the resources required to
make their argument.
Chair: The consensus is to work the problem through .11ma. We need some guidance.
Comment: You will need to find somebody who is part of the SB pool to submit a comment. When 11e
gets put into the 802.11 spec, that is the window to do this, if it is considered an 11e issue.
Chair: We need a solution written, get it reviewed, and no overlap between 11e & 11i changes to 11ma.
Comment: When you say “we” that does not mean TGw, but rather some TBD group to address this
issue?
Chair: Yes
Comment: I suggest we discuss this further outside this group.
Chair: Any objection to following that course?
None
Chair: Any objection to recessing until 4:00pm?
None
Chair: Anyone interested in the STAKey problem see Jesse to organize a group.
Resume: 4:00pm
Submission: Zulfikar Ramzan – doc 05/1186r0 – Disassociation and Deauthentication in BUMP
using Length-Two-Hash Chain
Discussion:
Comment: A simpler way to solve this problem is to redefine Disassociation to mean Disassociation &
Deauthentication.
Comment: The state machine you showed was old. There may be some value in this work based on the
new state machines in 11r.
Comment: If there is a sub-group of STA’s you want to Deauthenticat, and then Deauth another subgroup, this may be able to be used in this case.
Minutes
page 6
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1237r0
Comment: the Disassoc and Deauth is an OR not an AND
Comment: The value of this is in the security threat model of the Disassoc Vs. the Deauth. In 11i, when
Disassociating, all security context is released. In 11r, the STA can move to state 2 during transition. We
have no way of revoking PMKSA’s, only PTKSAs.
Comment: could the CGTK and SGTK be de-coupled?
Zulfikar: Yes
Comment: But you would have to send two commitment values, so this is an optimization.
Comment: We want to do this in a slightly different manner. The CGTK is subject to the hidden node
problem where a rogue could generate a de-auth forgery.
Comment: The hidden node problem exists in the BASE proposal anyway.
Comment: BUMP provides for the protection of the sender. This may not be a problem and requires
further analysis.
Comment: Allowing an attacker to gain access to the CGTK may allow them to do something with the
SGTK.
Comment: There doesn’t seem to be a case for an AP to ever send a broadcast disassociate.
Chair: Summary The consensus for the STAKey resolution is to go the route of 802.11ma. Jesse has assembled names for
a group to work on this problem and a chair. Correspondence for this group will take place on the main
802.11WG reflector.
Comment: What is our process moving forward?
Chair: We have instructed the editor to prepare a draft, and we will begin accepting proposals for changes
to that draft.
Chair: Do we need to schedule conference calls?
Motion:
Move for TGw to hold bi-weekly conference calls beginning January 31, 2006 at 11:00am
EST for 1 hour each and ending March 21, 2006
Moved by: Nancy Cam-Winget
Second: Jon Edney
Discussion:
None
Chair: Any objection to the motion?
None
Motion passes by unanimous consent
Comment: Is the STAKey group part of the IEEE 802.11 process?
Minutes
page 7
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1237r0
Chair: No, it a group of interested parties working outside the group.
Chair: Is there any further business?
None
Motion:
Move to adjourn.
Moved by: Jon Edney
Second: Nancy Cam-Winget
Chair: Any objection to the motion?
None
Motion Passes
Adjourned.
Minutes
page 8
Frank Ciotti, Motorola
November 2005
doc.: IEEE 802.11-05/1227r1
IEEE P802.11
Wireless LANs
CBP-SG Vancouver November Minutes
Date: 2005-11-18
Author(s):
Name
Company
Jim Raab
OakTree Consulting
Thomas
Maufer
Nvidia
Address
Phone
Austin, TX
email
512-577-7117
Jim.raab@oaktreewir
eless.com
Abstract
Contention-based protocol Study Group minutes from November IEEE Plenary
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Minutes of November CBP-SG Plenary
page 1
Thomas Maufer, Jim Raab
November 2005
doc.: IEEE 802.11-05/1227r1
November 16, 2005 8:00am PT
Discussion leader: Peter Ecclesine: petere@cisco.com +1 408-527-0815
Notes Scribe: Thomas Maufer accepted role of recording secretary
Opening of the meeting:
The chair, Peter Ecclesine, formally called the meeting to order at 8:07 (Pacific Standard Time).
1) Roll call
The following names were recorded as present for at least part of the meeting:
Name
Primary WG affiliation
Yusuke Asai
11
David Bendelsky
11
Charles Cook
11
Roger Durand
11
Peter Ecclesine
11
Lars Falk
11
Li Feng
11
Joseph Levy
11/19
Barry Lewis
16
Thomas Maufer
11
Bob Mayer
11
Andrew Myles
11
Subbu Ponnuswany
11
Marian Rudolf
11
Steve Shellhammer
19
Fabian Varas
11
Dennis Ward
11
Chris Ware
11
2) Approval of agenda
Proposed Agenda:
• Contention-Based Protocol Study Group Agenda
• Review EC, WG comments on PAR, 5 Criteria documents
• Develop plans for work after Plenary closes
•
•
•
•
•
•
•
* SG Meeting Call to Order
Chair
* Appointment of SG Recording Secretary
Chair/All
* Review of IEEE/802 and 802.11 Policies and Rules
Chair
MI Approve or Modify Agenda
Chair/All
MI Review and approve minutes of September interim meeting
Chair/All
II Chair’s Status Update and Review of objectives for the session
DT Call for Submissions, Presentations
Chair
Minutes of November CBP-SG Plenary
page 2
Chair
Thomas Maufer, Jim Raab
November 2005
doc.: IEEE 802.11-05/1227r1
•
•
•
•
•
•
DT Review of WG comments submitted to EC and draft responses
MI Review and approve minutes of teleconferences since July meeting
DT Presentations, discussion
Chair/All
DT Proposed SG/TG plans
All
M Motions for Working Group
* Adjourn
Chair
All
Chair
•
•
•
* - consent agenda
All agenda items are General Orders, i.e. time is not fixed, unless otherwise noted
Recess and adjournment times are fixed.
•
Agenda (802.11-05/1202r0) approved by group.
3) Read out of the IEEE Patent policy
The required statements about the IEEE patent policy were read by the chair Peter Ecclesine.
There were no questions or statements from those present.
•
The chair (Peter Ecclesine) read the usual preliminary slides re: policies and procedures,
patents, and appropriate discussion topics.
4) Summary of the September meeting and Approval of minutes, 802.11-05/0936r0
Peter summarized the September meeting, and the October 19th and November 2nd
teleconference discussions.
•
Minutes of September meeting (802.11-05/0936r0) approved by group (unanimous consent).
5) Discussion of Draft PAR comments received from 802.16
•
Discussed proposed changes to the PAR included in document 802.16-05/084 (“Comments
of IEEE 802.16 Working Group on Proposed P802.11y PAR”).
•
Made changes to the Five Criteria resulting from changes accepted to the PAR.
•
Voting on first motion (below).
6) Discussion of candidate Requirements and Objectives
•
Discussion of 11-05/1039r3.
Meeting was adjourned at 0927 (see motion below).
•
Minutes of November CBP-SG Plenary
page 3
Thomas Maufer, Jim Raab
November 2005
doc.: IEEE 802.11-05/1227r1
Wednesday Motions:
1. Move to submit draft CBP PAR 05/565r4 and Five Criteria Draft 05/351r5 to 802.11 WG
for approval and forwarding to ExCom.
•
•
Moved: Thomas Maufer
Seconded: Joseph Levy
Discussion on the motion: None.
•
•
•
Yes: 12
No: 0
Abstain: 2
2. Move to recess until Thursday 17-Nov-2005 at 0800.
•
Moved: chair
Discussion on the motion: None.
•
Approved by unanimous consent.
November, 17 2005, 8:02am meeting called to order
Discussion leader: Peter Ecclesine: petere@cisco.com +1 408-527-0815
Notes Scribe: Jim Raab accepted role of recording secretary
) Roll call
The following names were recorded as present for at least part of the meeting:
Name
Primary WG affiliation
Peter Ecclesine
11
Jeff Schiffer
18
Jim Raab
11
John Notor
18
Chantel Davis
20
Guido Hiertz
11
Tae Ewn Kim
11
Barry Lewis
16
Johnny Dixon
22
Bill Kunz
20
Winston Caldwell
22
Peter Murray
18
Yashuhiko Inoue
11
Denis Kuwahara
11
Michael Lynch
18
-
Agenda Discussed
Minutes of November CBP-SG Plenary
page 4
Thomas Maufer, Jim Raab
November 2005
doc.: IEEE 802.11-05/1227r1
-
Approval of past teleconference minutes No objections, unanomous consent
ƒ August 24, 05/1056r0
ƒ October 19 05/1041r1
ƒ November 2 05/847r1
- Review of Meeting on Tuesday and 802.16h comments and document
- Review of FCC actions taken – no visible activities noted.
- This non-action has given confidence that the study group can proceed, noting that there
have not been any major changes to their perspective on this topic.
- Proposed SG/TG Plans - Challenges for SG
- Looking at activities in other groups (e.g. 11 n/p/s/t/v/w) that could impact this group, and
needs to be considered during the ongoing process of working as a SG.
- Motion: move that the WG empower the SG/TG to hold teleconferences and
interim meetings up to the 25th of March, 2006. Moved by Denis Kuwahara,
second Peter Murray. 11 for, 0 against, 1 abstain.
Adjourn 8:30 am
Minutes of November CBP-SG Plenary
page 5
Thomas Maufer, Jim Raab
November 2005
doc.: IEEE 802.11-05/1227r1
References:
(A1) To access IEEE 802.11 SG documents on the web:
http://www.802wirelessworld.com/index.jsp
Register or Login - Register to have a login email address and password, or perform Login
Click on 802.11 WLAN WG http://www.802wirelessworld.com/group
Click on Documents under 802.11 WLAN WG tab on left http://www.802wirelessworld.com/docs
On Document Listing tab,
choose DCN (Document Content Number) or Title as appropriate
scroll to document
Click to download
Or at bottom of Document Listing tab,
scroll down and use FTP Access tab
(A2) CPB-SG document list:
The following documents have been filed by the study group:
11-05-0223-00-0wng-3650-3700-mhz-fcc-action.ppt
11-05-0328-00-0000-coordination-contention-interference-resolution.doc
11-05-0328-01-0000-coordination-contention-interference-resolution.doc
11-05-0331-00-0000-cbp-sg-telecon-minutes-6-april.doc
11-05-0336-00-0000-cbp-sg-telecon-minutes-13-april.doc
11-05-0340-00-0000-cbp-sg-contention-based-protocol-and-802-16-qos.ppt
11-05-0344-01-0000-cbp-sg-telecon-minutes-20-april.doc
11-05-0349-01-0000-cbp-sg-telecon-minutes-27-april.doc
11-05-0351-05-0000-CBP-SG-Five-Criteria-Draft.doc
11-05-0480-00-0000-CBP-SG-Cairns-closing-report.ppt
11-05-0484-00-0000-CBP-SG-Cairns-May-minutes.doc
11-05-0556-00-0000-cbp-sg-telecon-minutes-4-may.doc
11-05-0527-00-0000-cbp-sg-telecon-minutes-25-may.doc
11-05-0533-01-0000-cbp-sg-par-and-five-criteria-draft.doc
11-05-0565-04-0000-cbp-sg-draft-par.doc
11-05-0604-00-0000-cbp-sg-telecon-minutes-15-june.doc
Minutes of November CBP-SG Plenary
page 6
Thomas Maufer, Jim Raab
November 2005
doc.: IEEE 802.11-05/1227r1
11-05-0616-00-0000-cbp-sg-telecon-minutes-22-june.doc
11-05-0671-00-0000 cbp-sg-telecon-minutes-13-july.doc
11-05-0751-02-0000-cbp-sg-sf-closing-report.ppt
11-05-0795-01-0000-cbp-sg-sf-july-minutes.doc
11-05-0847-01-0000-cbp-sg-telecon-minutes-24-august.doc
11-05-0919-01-0000-cbp-sg-gg-closing-report.ppt
11-05-0936-00-0000-cbp-sg-gg-september-minutes.doc
11-05-1039-02-0000-cbp-sg-candidate-requirements-and-objectives.doc
11-05-1041-00-0000-cbp-sg-telecon-minutes-19-october.doc
11-05-1056-00-0000-cbp-sg-telecon-minutes-2-november.doc
11-05-1202-02-0000-cbp-sg-van-closing-report.ppt
For reference, the following is an alphabetical list of people who have expressed interest in the
CBP-SG:
Malik Audeh
Dennis Baker
Farooq Bari
Scott Blue
Edwin Brownrigg
Carlos Carderio
Clint Chaplin
Narasimha Chari
Remi Chayer
Gerard Chouinard
Charles Cook
Roger Durand
Peter Ecclesine
Mariana Goldhamer
Nada Golmie
Ahren Hartman
Amer Hassan
James P. Hauser
John Humbert
Yasuhiko Inoue
Lusheng Ji
Stuart Kerry
Byoung-Jo "J" Kim
Changhoi Koo
Bruce Kraemer
Andrew Kreig
Jan Kruys
Minutes of November CBP-SG Plenary
page 7
Thomas Maufer, Jim Raab
November 2005
doc.: IEEE 802.11-05/1227r1
Joseph S. Levy
Changwen-Liu
Dan Lubar
Mike Lynch
Tim Ma
Roger Marks
Mike Moreton
Andrew Myles
Masoud Olfat
Barry O’Mahony
Richard H. Paine
Kourosh Parsa
Victoria Poncini
Jim Raab
Richard Roy
Marian Rudolf
Andy Sago
Stephen J. Shellhammer
Ian Sherlock
Ramachandran Shyamal
David Steer
Adrian P. Stephens
Carl R. Stevenson
Karl Stringer?
Jeff Tao
Paul Thompson
Jim Tomcik
Wen Tong
Jerry Upton
Fabian Varas
Lisa Ward
Lily L. Yang
Eldad Zeira
Minutes of November CBP-SG Plenary
page 8
Thomas Maufer, Jim Raab