1. Enhanced xHRPD Overview Masa Shirota and Jun Wang Qualcomm Inc. March 18, 2014 3GPP2 Kyoto Meeting Recommendation: FYI Notice QUALCOMM Incorporated grants 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. QUALCOMM Incorporated is 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 QUALCOMM Incorporated 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 QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.

2. Requirements from SBM contribution [1] Voice Capacity Enhancements EPC support New Band Class Advanced Access Control It is desired to reuse native HRPD or eHRPD solutions as much as possible to reduce the complexity for implementation. [1] AC00-20140318-043 Proposals on xHRPD rev.A

3. Voice Capacity Enhancements (1) xHRPD Rev.0 voice capacity is forward link limited. – Reverse link can support up to 192 narrow band channels. (All channels can not be allocated to traffic channel as some channels have to be used for access channel.) – Assuming 2 kbps full rate users, each user generates 40-bit packet and 8 users result in a 734 bit payload including all overheads. This is much smaller than 2048-bit packet size (assumed 307.2 kbps bearer). – If Multi User Packet 16 can be used in Rev.A, the forward link capacity clearly doubles since the payload size can still fit within 2048 bits. – Multiple User Packet 16 is already supported in HRPD rev.B. It is proposed to support Multi User Packet 16 in xHRPD rev.A.

4. Voice Capacity Enhancements (2) xHRPD only supports Single User paging (one UATI value in the paging message). Considering the use case (disaster) SBM brought up, there will be large amount of incoming calls. MultiAT Page message was defined in C.S0024-C for reduction of paging message traffic over the control channel. MultiAT page is necessary to increase paging capacity to support the large amount of users efficiently. It is proposed to support MultiAT in xHRPD rev.A.

5. EPC Support It should be clarified that interworking between LTE and xHRPD (active handover, idle handover, session negotiation over the tunnel, etc.) is NOT required. – Thus, InterRAT related protocols defined in C.S0087 are not necessary to be supported in xHRPD. xHRPD already supports Enhanced Multi Flow Packet Application. EMPA is also used in eHRPD. – It would be good to clarify how to populate PDN-ID in the ReservationLabel. C.S0087 can clarify this. – eHRPD related specifications (C.S0087, A.S0022 and X.S0057) should be added in the reference. Based on the referencing method being used in HRPD documents, it is not necessary to describe specific procedures with respect to ReservationLabel in xHRPD specification. From network perspective, we can consider to support xHRPD in X.S0057-C and A.S0022 or new addendum of the earlier revisions. – Minimum to add C.S0098 in the reference section.

6. New Band Class Support A new band class should be defined in C.S0057 Band Class Specification. Also, AT Minimum Performance Specification for the new band should also be developed. Updating C.S0104 is required.

7. Advanced Access Control This is a completely new feature for xHRPD (even for native HRPD). – Current xHRPD/HRPD only supports the Persistence Test for sending access probes. There is no differentiation of data service type. Service Based Access Control enables the network to control access channel traffic based on the services. Data services can include: – VoIP – SMS over IP – Chat over IP – Other data services Data services can also include emergency service and non emergency services

8. High Level Proposal Currently Packet Filter are used for QoS treatment – UE applies TFT after the traffic channel has been established – Lack of PF based access control mechanisms Propose packet filter based access control mechanisms – Uses PF for access control before traffic channel has been setup When the MS/UE receives data from the application, it matches PF and then applies corresponding access control parameters for the service

9. Potential Solution The RAN derives different access parameters (for example persistence values) for different access control classes and send them through OTA overhead messages based on ACC received from core network or based on pre-configuration The HSGW associates access control classes (ACC) with packet filters and communicates it to the UE using TFT transported using RSVP signaling. Or, ACC with packet filters can be configured in AT though out of band mechanism. The UE uses different access parameters based on packet filters and the parameters obtained from the RAN UEAppRAN HSGWP-GW 6. TFT Setup (Flow ID, PF, QoS, ACC) 5. Air interface Session/PPP Session/PDN Connection Setup 1. Sending ACC to RAN or Preconfigure ACC in RAN 8. Matches data to TFT and applies to ACC 7. Data is sent (e.g,VoIP) 2. Derive Access Parameters for each ACC 3. Access Parameters 4. Access Control for Session setup signaling (high Priority)

10. Example of ACC Types ACC TypesValue Control Traffic000000 Emergency VoIP000001 Emergency SMS000010 Emergency Data000011 Non-Emergency VoIP000100 Non-Emergency SMS000101 Any other non emergency services 000110 Reserved000111-111111

11. Some Feedback from Discussions Is it necessary to indicate ‘xHRPD’ as a network type to EPC? Is it ok to reuse ‘eHRPD’? – EPC could be agnostic about xHRPD. xHRPD can be considered as one of eHRPD option. – From 3GPP perspective, they do not differentiate eHRPD from HRPD. Are there any impact on Multi Mode System Selection? – C.S0016-D does not differentiate eHRPD from HRPD in the System Type table in MMSS. – There may not have impact since the AT can differentiate xHRPD (if necessary) using Band Class Information in the ACQ_TYPE in PRL. – xHRPD currently works for BC21 and BC22 only. A new Band Class for IMT MSS band is also applicable to xHRPD.