Tunneling Protocol Support for 1x CSFB from E-UTRAN Source: Qualcomm Inc: Masa Shirota(mshirota@qualcomm.com), Ravindra Patwardhan, Peerapol Tinnakornsrisuphap, George Cherian, David Ott and Jun Wang China Telecom: Mei Cheng Li (Meichl@ctbri.com.cn) Notice ©2009. All rights reserved. Contributors 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. Contributors 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 contributors 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. Contributors specifically reserve 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 contributors other than provided in the copyright statement above.

Introduction 1x CSFB (Circuit Switched FallBack) from E-UTRAN has been defined in 3GPP as one of the Release 8 features. Stage 2 requirements can be found in TS23.272. Major Stage 3 requirements can be found in TS36.331 (RRC), TS36.413 (S1), TS29.274 (GTPv2) and TS29.277 (S102). 1x CSFB Design Principles in 3GPP specifications: The UE can perform the 1x registration and receive the 1x page message while it stays in E-UTRAN. 1x messages (LAC PDUs) are exchanged between the UE and the MME over the transports provided by RRC and S1. The MME interfaces to the 1x IWS though S102. S102 is defined as a subset of A21 interface. E-UTRAN directs the UE when it should fall back to an 1x. When the UE performs an 1x call origination, it firstly connects E-UTRAN by initiating the CSFB service request to get the redirection. After the UE receives the redirection, it tunes to an 1x based on the information (Band Class and Frequency number) in the redirection information. Then, it sends an ORM. When the UE receives an 1x page message, it initiates the CSFB service request to get the redirection. After the UE receives the redirection, it tunes to 1x based on the information (Band Class and Frequency number) in the redirection information. Then, it sends a PRM. E-UTRAN may require the UE to measure 1x network during the measurement gaps.

1x CSFB Architecture Reference: 3GPP TS23.272

Issues with current 3GPP 1x CSFB Design No tunneling protocol (similar to CSNA) is used to transport 1x Encapsulated LAC PDU between the cdma2000 upper layer in UE and MME (endpoint for A21 interface). RRC provides a tunnel between UE and eNB. S1 provides a tunnel between eNB and MME. Some parameters, such as RAND, Cell ID, Mobile Subscription Information, etc., can be exchanged over those interfaces. No clear requirements for how to populate LAC fields, e.g., ARQ fields and Radio Environment Report fields, are defined. 1x Message control is not supported. An IWS and UE cannot understand if LAC PDU is formed as for common channel or dedicated channel. If the logical channel is not identified, the message cannot be parsed as the format of the LAC PDU changes depending on the logical channel. 1x CSFB uses common channel messages basically. But, SRVCC uses dedicated channel messages (handoff direction, see annex Stage 2 call flow from 3GPP document). Layer 2 ack is not supported. Some 1x messages, such as the Registration Message, require L2 ack. If the cdma2000 LAC layer does not receive L2 ack, it continues to resend the message. These issues occur due to lack of CSNA-like tunneling protocol to exchange 1x messages.

Proposal for New Tunneling Protocol Define a CSNA-Lite tunneling protocol to be used between A21 endpoint and cdma2000 upper layer. This new tunneling protocol can be used for any interworking scenarios between 1x and non-3GPP2 technologies. This new protocol will have subset of functions from CSNA. Other Access Technologies need to provide a transport channel for this tunneling protocol. (We do not intend to change 1x CSFB design in 3GPP. Only message encapsulation and L2 ack defined by the new protocol can apply.) Thus, major changes are not expected in 3GPP documents for 1x CSFB. Updates A.S0008 to support this new generic tunneling protocol by A21 interface in addition to CSNA.

Functions for CSNA-Lite Protocol CSNA-Lite tunneling protocol supports: 1x LAC PDU encapsulation Message control (L2 acknowledgement, Protocol Revision, and Logical Channel Indication) 1x parameters provisioning 1x message filter negotiation between AT and A21 end point will not be defined. Protocol revision of CSNA-Lite Protocol will indicate which 1x messages can be exchanged.

Recommendations Define a CSNA-Lite tunneling protocol which can generally apply to interworking any access technologies (except for HRPD). Primarily to support 1x CSFB from E-UTRAN. But, it is not limited to it. (This tunneling protocol can be used for SRVCC as well.)

Annex A: A21 and CSNA Brief Overview A21 assumes the AN supports CSNA. A21 supports: 1x LAC PDU encapsulation (AN and IWS can exchange 1x message over A21.) Message control L2 acknowledgement 1x parameters provisioning Event Notification Service Request (for HRPD page delivery) Radio Parameter Update CSNA supports: 1x LAC PDU encapsulation (AT and AN can exchange 1x message over HRPD.) Message control (L2 acknowledgement, Protocol Revision, Logical Channel Indication) 1x message filter negotiation

Annex B: SRVCC Call Flow Reference: 3GPP TS23.216