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

2. January 2006
doc.: IEEE /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

3. January 2006
doc.: IEEE /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

4. 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

5. 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

6. 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

7. 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

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

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