3GPP2 X xxx Title: Subscriber QoS Profile Support in eHRPD System Sources: China Telecom, ZTE Contact: CT: Peirong Li Wenyi ZTE: Rajesh Bhalla Mao Yuxin Abstract: This contribution highlights that subscriber QoS profile is also needed for the eHRPD system. This contribution proposes two proposals for how to resolve this issue. Recommendation: Review and adopt option 2 Contributing companies grant a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Contributing companies are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by Contributing companies to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on contributors. Contributing companies specifically reserve the right to amend or modify the material contained herein and to any intellectual property of contributors other than provided in the copyright statement above.
2 Background In HRPD system, when UE attaches to the network, Subscriber QoS profile has to be returned to the PDSN and in turn to the RAN via A11 signaling message when the UE is authenticated The PDSN uses the Subscriber QoS Profile as input to the authorization for A10 connections. The RAN uses it for QoS request authorization and traffic policing purposes. Subscriber QoS Profile has been defined In X.S0011 Specification. It consists of the following attributes: The Maximum Authorized Aggregate Bandwidth for Best-Effort Traffic The Authorized Flow Profile IDs for each direction The Maximum per Flow Priority The Allowed Differentiated Services Markings The Service Option Profile The Allowed Number of Persistent TFTs The Inter-User Priority for best effort traffic
3 Background ( cont. ) In current eHRPD system, for QoS control, PCC framework is applied to provide QoS policy to the HSGW. The X.S0057 spec. only depicts which contained in the QoS policy can map to the Flow Profile ID at HSGW Other QoS attributes defined in the Subscriber QoS Profile are also useful for QoS authorization, but it’s not clear how to derive such QoS attributes in the current implementation of X.S0057 specificaitons For example, the ‘Inter-User Priority for best effort traffic’ is applied by the operator to differentiate the priority of BE traffics which are used by different users.
4 Background ( cont. ) Furthermore, PCC may not be deployed in the initial deployments of eHRPD system. E.g. operators may upgrade HRPD to eHRPD without PCC in their first network evolution step. Therefore, how will the HSGW and eAN obtain QoS profile to perform admission control and A10 connection authorization?
5 Problem statement Issue: It would be desirable that the Subscriber QoS Profile parameters defined in X.S0011 are available in eHRPD system also to ensure HSGW and eAN can perform QoS authorization without PCC Method: The HSGW obtains Subscriber QoS Profile when UE is authenticated The HSGW adds some QoS parameters from Subscriber QoS Profile into the A11 signaling message and sends to the eAN How to obtain Subscribe QoS Profile by the HSGW?
6 Proposed solution(1) Option 1: Storing Subscriber QoS Profile in the HSS/3GPP AAA and sending it from 3GPP AAA to HSGW over STa and Pi* interface when UE authentication is successful Subscriber QoS Profile may be stored at HSS or 3GPP AAA as 3GPP format or 3GPP2 format –If it is stored as 3GPP format, QoS mapping into 3GPP2 format may performed at 3GPP2 AAA proxy or HSGW. STa and Pi* interfaces need to enhance to support QoS profile transmission It could be difficult to make such enhancements in 3GPP specs as 3GPP may not want to go into non-3GPP access specific details
7 Proposed solution(2) Option 2: Storing Subscriber QoS Profile in 3GPP2 AAA proxy/server. On receiving authentication response from 3GPP AAA; 3GPP2 AAA proxy/server adds subscriber QoS profile parameters to the message and returns them to the HSGW Enhancement limited to 3GPP2 domain, only Pi* reference point needs to support such QoS profile parameters User subscription related information will be stored at separate places (subscriber QoS profile is stored at 3GPP2 AAA and authentication vector is stored at the HSS). It would result in high maintenance cost for the operators
8 Recommendations Discuss and adopt Option 2 Thanks