1. Proposed Changes to Requirements
January 2006
doc.: IEEE /00xxr0
January 2006
Proposed Changes to Requirements
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

2. January 2006
doc.: IEEE /00xxr0
January 2006
Abstract
This submission contains some suggested changes to the TGu requirements in response to the liaison responses received from various organisations.
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

3. January 2006
doc.: IEEE /00xxr0
January 2006
R8E1
R8E1 is “Define functionality by which the STA is able to determine what online enrolment (also called online subscription) methods are supported by the network.”
Common question – “Is enrolment only with the local network, or is it to SSPNs as well?”
Suggest we should only require enrolment with the local network
Also add new optional requirement for enrolment with an SSPN.
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

4. January 2006
doc.: IEEE /00xxr0
January 2006
Motion
Direct the editor to add the word “local” to R8E1 so that the complete requirement becomes:
“Define functionality by which the STA is able to determine what online enrolment (also called online subscription) methods are supported by the local network.”
and add a new requirement to the “E” cluster as follows, setting the status to “Optional - Not Required”:
“Define a way in which the functionality defined in requirement R8E1 can be extended to support enrolment with SSPNs.
Informative Note: It is expected to be much more challenging to define a mechanism for enrolment with remote networks.”
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

5. January 2006
doc.: IEEE /00xxr0
January 2006
R8N1
R8N1 is “Define functionality by which a STA can determine whether its subscription to an SSPN would allow it to access a particular AN before actually joining a BSS within that AN. Proposals must describe their consideration of scalability.”
There have been questions about how this information is split between passive/broadcast information (for example in beacons) and active/query responses (for example probing).
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

6. January 2006
doc.: IEEE /00xxr0
January 2006
Motion
Direct the editor to add the following note to the informative notes for requirement R8N1:
“Proposals are expected to provide both active (e.g. probe & response) and passive (e.g. beacon) mechanisms.”
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

7. Backwards Compatibility
January 2006
doc.: IEEE /00xxr0
January 2006
Backwards Compatibility
3GPP2 are concerned that we might break their existing mechanisms for network selection.
We should have some sort of general purpose requirement that an AP be able to simultaneously give access using legacy mechanisms while giving access to other STAs using the 11u mechanisms.
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

8. January 2006
doc.: IEEE /00xxr0
January 2006
Motion
Direct the editor to add the following requirement to the General Cluster, and set its status to “Required”:
“All proposals must allow (subject to policy) APs to serve legacy devices as well as STAs that have been upgraded to 11u. Proposals must describe how this is achieved.
Informative Note: In general new 11u features will only be available to STAs that have been upgraded to 11u. But we can’t exclude the huge existing population of legacy devices from accessing 11u APs.”
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics