Title: Interworking with LTE Source: Mike Dolan, Tony Lee Abstract: 3GPP2 WRKSP-20120315-xxxr0 2012 Workshop Planning Title: Interworking with LTE Source: Mike Dolan, Tony Lee Abstract: Draft Presentation on Interworking with LTE Recommendation: Review and Approve. © 2012 3GPP2 The 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. The 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 the 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 the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and to any intellectual property of the contributors other than provided in the copyright statement above.

Interworking with LTE Outline At the Core and RAN Level LTE  eHPRD How eHRPD connects to the same Enhanced Packet Core (EPC) Handoff LTE  cdma2000® 1x CSFB, eCSFB SMS At the Radio Level xxx

LTE  eHPRD How eHRPD connects to the same Enhanced Packet Core (EPC) HSS/AAA Internet 3GPP2 AAA PCRF PDN Gateway Home Agent MME Serving Gateway HSGW PDSN Signaling Data eNodeB eAN/ ePCF AN/ PCF UE

Non-Optimized Handoff from LTE to eHRPD HSS/AAA Internet PCRF PDN Gateway MME Serving Gateway HSGW Signaling Data eNodeB eAN/ ePCF UE

Optimized Handoff from LTE to eHRPD Step 1 – Establish context on eHRPD via tunneled signaling HSS/AAA Internet PCRF PDN Gateway MME Serving Gateway HSGW Signaling S101 Data eNodeB eAN/ ePCF UE

Optimized Handoff from LTE to eHRPD Step 2 – UE moves to eHRPD, bearers are moved HSS/AAA Internet PCRF PDN Gateway MME Serving Gateway HSGW Signaling Data eNodeB S101 eAN/ ePCF UE

Comparison of Optimized vs. Non-Optimized Optimized handoff takes less than 300 msec. Non-optimized handoff can take as much as 5-7 seconds. Optimized handoff requires in addition to what non-optimized needs: S101 tunneling Upgrades on the UE, MME, eAN/ePCF, HSGW

Circuit Switched Fall Back (CSFB) Core network and RAN Uses tunneled signaling to the UE across the S102 interface between the IWS and MME. This supports: CSFB, enhanced CSFB (eCSFB) SMS

CSFB MSC IWS Page sent to IWS. IWS sends page to UE via MME and eNodeB using S102. UE moves to 1x. UE sends a normal page response on the 1x access channel. Call proceeds. MME S102 eNodeB 1x BS UE Signaling Data

eCSFB MSC Page sent to IWS. IWS sends page to UE via MME and eNodeB using S102. UE sends a page response via the eNodeB and MME. IWS sends a handoff command (UHDM) to the UE via S102, and sets up the traffic channel on 1x in preparation for the UE. UE does a handoff to the 1x traffic channel. 1x call proceeds. IWS MME S102 eNodeB 1x BS UE Signaling Data

Comparison of CSFB to eCSFB CSFB requires extra time on 1x due to hashing and other procedures. For eCSFB, the traffic channel is prepared and waiting for the UE to arrive. Some issues at the radio level will be discussed later, when the radio level is covered.

SMS Both mobile originated and mobile terminated are supported. MSC IWS MME MT-SMS SMS are sent via S102 to the UE UE does not leave LTE. MO-SMS SMS are sent via S102 from the UE S102 eNodeB 1x BS UE Signaling Data

Interworking with LTE Radio Level LTE  eHPRD (optimized handoff) Requires S-101

HRPD-LTE Dual Mode Protocol Structure

New protocols New protocols to support LTE to eHRPD Default Signaling Adaptation Protocol (no counterpart in HRPD) InterRAT Initialization Protocol InterRAT Idle State Protocol InterRAT Route Update Protocol InterRAT Overhead Message Protocol InterRAT Signaling Adaptation Protocol (no counterpart in HRPD) Additional new protocols to support LTE to eHRPD with air interface that support C.S0024-B InterRAT Quick Idle State Protocol Subtype 1 based InterRAT Route Update Protocol InterRAT Overhead Message Protocol for C.S0024B

Existing protocols affected (1) Default Airlink Management Protocol Default Connected State Protocol Default Packet Consolidation Protocol Application layer: Muliti-Flow Packet Application Enhanced Multi-Flow Packet Application Multi-Link Mulit-Flow Packet Application Session layer: Default Session Management Protocol Default Address Management Protocol

Existing Protocols affected (2) Subtype 3 RTC MAC Subtype 2 Physical Layer Subtype 4 RTC MAC Subtype 3 Physical Layer

Why the Inter RAT protocols? To handle connection between HRPD upper layer to LTE lower layers HRPD upper layer = Connection Layer and above LTE lower layer = MAC and below The behavior of the HRPD control protocols are very different when connected to the LTE tunnel Tunneled mode/state: This mobile enters this mode when it is connected to LTE SIB 8 provides the overhead parameters, such as System Time, Neighbors PN, etc “Tunneled State” describes the behavior of the HRPD protocol when the mobile is connected to the LTE tunnel Under tunneled state, each IRAT protocol behave differently as compare to their normal state Provide periodic pilot measurement

Functionalities of IRAT protocols when in tunneled mode (1) IRAT Initialization state protocol “Bypass” pilot acquisition and synchronization state It uses the SIB 8 information to establish timing IRAT Idle state protocol Introduced “Tunneled state” in the state transition diagram No sleep or wake up No monitoring of control channel Perform pilot measurement

Functionalities of IRAT protocols when in tunneled mode (2) IRAT Route Update Protocol Pilot supervision is disabled Radius based RUP message is disabled IRAT Overhead Message Protocol Store overhead parameters from SIB 8 Transmit the OtherRATNeighborList Message Does not activate supervision timers

Signaling Adaptation Protocol - Context

SAP functionalities It keeps record of which air interface (HRPD or non-HRPD) the access terminal is currently receiving service in When requested by upper layer protocols, it provides a virtual connection service between the access terminal and the access network over a non- HRPD radio access technology tunnel when the access terminal is receiving service in a non-HRPD radio access technology Provides encapsulation of HRPD packets when sent over a non-HRPD radio access technology tunnel Triggers idle and active handoffs from a non-HRPD radio access technology to HRPD access networks It has a control plane as well as a user plane functionality

SAP states Close State: The virtual connection does not exist Setup State: The virtual connection setup is in progress Open State: In this state the virtual connection is open.

Changes to Application Layer Added alternate packet application subtype for: MFPA -> Alternate MFPA EMFPA -> Alternate EMFPA MLMFPA -> Alternate MLMFPA The alternate packet application subtype is to identify the support of eHRPD Introduce Protocol ID 7 and 8

Changes to MAC and PHY Layer Initial output power calculation X0 = - Mean RX Power (dBm) + OpenLoopAdjust + PilotInitialAdjust where: PilotInitialAdjust = InitialAdjust + min(PilotStrengthCorrectionMax, max(PilotStrengthNominal – PilotStrength, PilotStrengthCorrectionMin)), This is necessary due to no access probe power correction

eHPRD to LTE

Two ways : OtherRATNeighborList Message InterRATRedirect Broadcast by Overhead Message Protocol Contains E-UTRAN information for AT to search for E-UTRAN system Threshold InterRATRedirect Send by Airlink Management Protocol Contains E-UTRAN redirection information

OtherRATNeighborList: E-UTRAN record Broadcast by Overhead Message Protocol

InterRATRedirection: E-UTRAN redirection record

eHRPD to E-UTRAN redirection

Circuit Switch Fall Back

LTE to 1x tunneling

Supported Layer 3 PDU All supported layer 3 messages are listed under C.R1001 The supported messages are based on revision and class Revision 0 Class 0 = Release 8 1xCSFB Revision 1 Class 0 = Release 9 e1xCSFB Revision 0 Class 1 = SRVCC Example: Messages supported under Release 8 1x CSFB Data Burst (F/R) Authentication Challenge (F) Shared Secret Data Update (F) General Page Message (F) Registration Accepted/Rejected/Request Order (F) Base Station Challenge Confirmation Order Registration Message

TLAC header Stands for: Tunneling LAC Contains essential layer 2 fields Two set of fields: r-csch Addressing Sublayer Record r-csch Authentication and Message Integrity Sublayer Record

GCSNA header Field Length (bits) MessageID 8 GCSNAOption AlternativeGCSNAOption_INCL 1 NumAlternativeGCSNAOptions 0 or 8 If NUMAlternativeGCSNAOptions field is included, NumAlternativeGCSNAOptions occurrences of the following field: Otherwise, 0 occurrences of the following field: { AlternativeGCSNAOption } IWSIDIncl IWS_ID 0 or 16 AckRequired StopDupDetect MessageSequence 6 Reserved 0 to 7 TLACEncapsulated1xL3PDU Variable

Example GCSNA Callflow

Idle handoff to LTE In 1x Rev E, the Alternate Technology Information Message can carries the E-UTRAN record as defined in C.S0097

www.3GPP2.org