1. Title: Interworking with LTE Source: Mike Dolan, Tony Lee Abstract:
3GPP2 WRKSP xxxr0
2012 Workshop Planning
Title: Interworking with LTE
Source: Mike Dolan, Tony Lee
Abstract:
Draft Presentation on Interworking with LTE
Recommendation:
Review and Approve.
© GPP2
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.

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

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

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

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

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

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

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

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

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

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

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

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

14. HRPD-LTE Dual Mode Protocol Structure

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

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

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

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

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

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

21. Signaling Adaptation Protocol - Context

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

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

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

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

27. eHPRD to LTE

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

29. OtherRATNeighborList: E-UTRAN record
Broadcast by Overhead Message Protocol

30. InterRATRedirection: E-UTRAN redirection record

31. eHRPD to E-UTRAN redirection

32. Circuit Switch Fall Back

33. LTE to 1x tunneling

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

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

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

37. Example GCSNA Callflow

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