1. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 1 Authorization Information in interworking Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-11-14 Authors:

2. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 2 Abstract This presentation is a contribution to the 801.11u pre- proposal presentation. The intension is to trigger discussion regarding some extra requirements.

3. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 3 The 802.11 AN architecture DSM AP Gateway DS AS Wn Wa STA Ww

4. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 4 The elements involved in access control Issues, questions, problems: –R3S1 & R3S2 covers A.I.-1, i.e. concerning over the air part However, would A.I-2 would also impact the service? –e.g. if Gateway cannot support the A.I.-2 requested, how should this be made known to AP/AS, and how should this be reflected in access control? –A.I. may not be supported by the AP due to its dynamic resources allocation Should this be made known to the STA? –e.g. if A.I. of a STA includes VoIP, but AP ACU decided not to admit any more VoIP, how should this made known to STA. –Should the whole authentication fail? (but STA can still use other services specified in the AI) Should wait for the STA to request through 11e and fail? –Is it possible for STA to know what QoS is supported before (11i) authentication? An AP would support multiple SSPNs (R3N3), and therefore, resources availability may depends on SSPN AP does not know about the SSPN an STA want to use at association time (esp. when SSPNs are not differentiated by the SSID) Upper Layer 11 MAC STA 11 MAC AP DSM Integration/Portal Gateway AS Application Req. (QoS Mapping R3U3) 11e TOE SSPN AAA (A.I.) ? (A.I.-1) ?? (A.I.-2)

5. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 5 Potential requirements It should allow the AI enforcement result made known to the STA –Is it related to R3S2 It should allow the STA to query the AP based on the SSPN it is going to access –The SSPN is not necessary able to be indicated with SSID

6. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 6 Motions Accept the following text as a TGu requirement for proposals, and include it in the requirements document, with requirement status set to “Optional”. –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. Proposed: Hong Cheng Seconded: Eleanor Hepworth Result (for/against/abstain):3,2,9

7. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 7 motions 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. Proposed: Seconded: Result (for/against/abstain):

8. doc.: IEEE 802.11-05/1138r1 Submission November 2005 Cheng Hong, PanasonicSlide 8 References 11-05-0822-03-000u-suggested-tgu-requirements