Proposal for SSPN Interface Cluster January 2006 doc.: IEEE 802.11-05/1xxxr0 January 2006 Proposal for SSPN Interface Cluster Date: 2006-01-06 Authors: 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>. Hong Cheng, Panasonic Hong Cheng, Panasonic

January 2006 doc.: IEEE 802.11-05/1xxxr0 January 2006 Abstract This document contains initial proposals to cover the SSPN Interface Cluster of the technical requirements for TGu. Hong Cheng, Panasonic Hong Cheng, Panasonic

January 2006 doc.: IEEE 802.11-05/1xxxr0 January 2006 WiNOT consortium This presentation is made on behalf of the WiNOT (Wireless NetwOrking Technology), comprising: Intel Nokia Siemens Panasonic STMicroeletronics BenQ Cingular T-Mobile Hong Cheng, Panasonic Hong Cheng, Panasonic

SSPN Interface Cluster January 2006 SSPN Interface Cluster Required: R8S1: Define the Authorization Information (originated from the SSPN) that shall be provided to the MAC and associated functionality. R8S2: Define how the information defined in R8S1 will be used. Optional: R8S3: Define functionality by which the information defined in R8S1 can be modified (by the SSPN) Out of Scope: R8S4: Make accessible accounting information for transfer to the SSPN. This shall include information about accepted TSPECs, their duration, and about actual traffic flows. Hong Cheng, Panasonic

Proposal for R8S1 (Required) January 2006 Proposal for R8S1 (Required) The definition of the contents of Authorization Information: Considerations: This should be the information visible to the MAC. How it is transported from SSPN to the local AN is out of scope. However, SSPN should provide adequate information in the AAA procedure to the local AN so that the following information could be properly derived. List of Information Elements: Authorized Priority Authorized MAX Bandwidth Accounting Interval Number of simultaneous connections allowed MTU allowed Session Time Out limit Defintion of the MIB entities comes at later stage Hong Cheng, Panasonic

Proposal for R8S2 (Required) January 2006 Proposal for R8S2 (Required) In the MAC specification, the use of Information Element defined in R8S1 should be described E.g. How AP MAC makes 11e mechanism should refer to the “Authorized Priority” or “Authorized MAX Bandwidth” Each Information Element suggested in R8S1 should attach some explanations that should cover R8S2 E.g. Authorized Priority AP MAC make use of this for the admission control to decide what is the suitable AC to be used Authorized MAX Bandwidth AP MAC make use of this for the admission control of the 11e HCCA type of request Accounting Interval This will decide the interval a MAC check the MIB for the accounting information update from the SSPN, e.g. when a user should be purged due to lake of credits Number of simultaneous connections allowed AP MAC decides how many simultaneous sessions a STA MAC should make MTU allowed The MAC size to be used. It could also be announced to the STA MAC for a session in the response message Session Time Out limit When the AP MAC considers a session is stopped. It is useful to timely remove a orphaned session. Hong Cheng, Panasonic

Proposal for R8S3 (Optional) January 2006 Proposal for R8S3 (Optional) The SSPN could change the information defined in R8S1 through the AAA procedure during an active session. This should be enforced at the AN without asking the user to re-establish the ongoing session. This means that if there is any change to the Authorization Information, a trigger should be sent to the MAC function to update relevant states & value. Use case: For example for the immediate purge of user as requested in the 3GPP use case, the SSPN needs to change the status of the user so that AN can remove it immediately to release resource for reuse. This type of update to the AN should trigger some type immediate action instead of just updating the MIB value (which may be act upon at a much later time) Hong Cheng, Panasonic

Proposal for R8S4 (Out of scope) January 2006 Proposal for R8S4 (Out of scope) No proposal Hong Cheng, Panasonic

References 11-05-0822-08-000u-suggested-tgu-requirements January 2006 Hong Cheng, Panasonic