Improved Non-Optimized LTE-eHRPD Handover to Support VoIP

1. Improved Non-Optimized LTE-eHRPD Handover to Support VoIP Mike Dolan January 2011

2. Outline GOAL: Improve non-optimized handover from LTE to eHRPD to support VoIP handover in 500 ms or less. • Classify Handovers • Discuss Pre-registration • Explain “Lock PDN Connection” concept • Important air interface components of non-optimized handover • Timings: • Regular NOHO • Locked PDN NOHO • Locked PDN + No-Hash + CDMA System Time • Some Impacts to UEs and HSGWs • Summary

3. Classifying LTE to eHRPD Handovers • Non-Optimized handover: Single Transmitter Devices • The topic of this discussion. • Non-Optimized handover: Dual Transmitter Devices • Not being discussed here. • Will require a separate, compatible approach using a new attach type. • Optimized handover: Involves the use of S101 to tunnel signaling. • Not being discussed here.

4. Pre-Registration • To meet VoIP handover timing, it is necessary that the UE has previously registered in eHRPD. For optimized handover, this would be done over S101. For non-optimized handover today, this would only occur occasionally and is not guaranteed. • A new method to guarantee pre-registration for VoIP capable devices is necessary. The details will vary for a single transceiver vs. dual transceiver device. • Several proposals have already been made in this area. This presentation does not focus on the details of the pre-registration options that might be standardized, only points out that it is necessary to add this technique. • In addition, under current NOHO the pre-registration (partial) context is only held for a relatively short time. It is recognized that the time that the pre-registered context is kept in the HSGW while the UE is attached on LTE will need to be increased.

5. Lock PDN Connection - Background • When designing handover from eHRPD to LTE, it was decided for simplicity to delete all PDN connection context from the HSGW and keep only “partial context” involving registration, authentication, and A10 connections. • When the UE returns to eHRPD from LTE, all PDN connections and bearers need to be re-established using VSNCP and VSNP signaling. • This VSNCP and VSNP signaling requires approximately 500 ms. • The HSGW keeps “partial context” until a Context Maintenance timer expires, or until the UE returns to the eHRPD radio. • THE PROBLEM The current design forces this extra 500 ms. into the voice gap for VoIP services.

6. Lock PDN Connection - Concept • The “Lock PDN Connection” concept is simple: • Create a PDN connection on eHRPD and “lock” it as a part of partial context. • The HSGW will keep the locked PDN connection context, even when the UE goes to LTE, in addition to the registration, authentication, and A10 connections it already keeps in partial context. • The UE guarantees the HSGW that it will make no changes to the PDN connection configuration and bearers while on LTE. • When the UE returns to eHRPD from LTE, the VSNCP and VSNP signaling are avoided, and the HSGW simply binds the PMIP tunnel with the P-GW so that packets can begin flowing (approximately 25 ms). • Targeted specifically at handovers of VoIP calls from LTE to eHRPD.

7. Lock PDN Connection – Procedure (part 1)

8. Lock PDN Connection – Procedure (part 2)

9. No-Hash, CDMA System Time Two important air interface components of improved non-optimized Handoff: • No-HASH: • When a UE finds multiple eHRPD channels in the information it receives from the eNodeB, it chooses one and moves to it. eHRPD requires receiving the channel configuration and then hashing to a specific channel for load distribution. Hashing can use a significant amount of time. • Avoiding this hashing in HO from LTE saves about 700 ms. • See the backup slides for more information on No-Hash. • CDMA System Time from LTE: • Provisions are made in E-UTRAN to provide the CDMA system time to the UE, thus avoiding the time needed to acquire sync on the eHRPD radio. • Use of this facility in E-UTRAN saves about 200 ms.

10. Timings Assumptions: UE may have a dual receiver. - The SIB8 contains information to help the UE find eHRPD. - UE has previously been on eHRPD, so an eHRPD radio session exists. * Typical Times: Values represent median sunny day scenarios from lab traces with early devices.

11. Some Impacts to UEs • Impacts to System Selection • UE needs to go to eHRPD first (if available) and set up (at least) the locked PDN connections, then go idle on eHRPD and reselect to LTE. • If UE loses radio contact longer than the Context Maintenance timer on the HSGW allows, it must go to eHRPD upon return to coverage to re-establish locked PDN connections context. Then it will go to eHRPD idle and reselect to LTE. • Context saving • UE must save locked PDN connection while on LTE. • LTE attach • UE must do “handoff attach” for established PDN connections when attaching to LTE, instead of “initial attach”. • Radio • Add the No-Hashing capability for HO from LTE to eHRPD. • Use the LTE-provided CDMA System Time.

12. Some Impacts to HSGWs • Implement PDN connection locking: • Accept and respond to a PDN connection locking request. • Add locked PDN connections to HSGW partial context procedures. This will have implications on how much storage is needed per UE, and consequently on the HSGW if many/most devices use locked PDN connections. • If H1 is implemented, add locked PDN connections to the context sent to the target HSGW. • Create PMIP bindings for locked PDN connections immediately when the UE returns from LTE.

13. Summary • Locked PDN connections, in conjunction with the “no-hash” and CDMA system time capabilities from LTE, can provide a NOHO voice gap time in the range of 430 ms. • There will be impacts on the UE and HSGW, including system selection. • The locked PDN connection concept can also assist dual transmitter devices, to solve the problem of recreating PDN connections upon temporary loss of eHRPD radio coverage.

14. BACKUP SLIDES

15. Latency Reduction for LTE->eHRPD Redirection Dave Rossetti

16. Background • China Telecom submitted a contribution to 3GPP2 TSG-S wrt 1x CSFB call setup optimizations. • S00-20090511-038r2 • After ongoing discussions in CCSA, ALU submitted a 3GPP2 TSG-C contribution for reducing latency due to hashing behavior during 1x Circuit Switch Fallback. • ALU C20-20090615-019 • The ALU technique has been summarized as a “No Hash” technique. An alternative technique has also been discussed which is summarized as “pre-hash” although there has been no such contribution to 3GPP2. • A similar issue exists for LTE ->eHRPD redirection, albeit to a lesser extent. • If a UE is redirected to a multi-carrier eHRPD system, it may suffer hashing related latency impacts on the order of .5 to 1 second prior to attaching through eHRPD.

17. Redirection Scenario showing area of impact UE eNB MME 1xEVDO UE is in RRC_CONNECTED 2. RRC connection reconfiguration (meas config, reporting configuration, measurement gaps) 3. Measurement report (event B2) 4. RRC Connection Release with Redirection info (CDMA Carrier) S1 UE Context Release Procedure 1xEV-DO session establishment/re-establishment Hashing Delay

18. Performance Impact for Multi-carrier redirection • After the UE receives the RRC Redirection to eHRPD, it will attempt to acquire the specified eHRPD carrier. • Once on eHRPD it will attempt to access the AN (to transmit UATIRequest or ConnectionRequest etc based on eHRPD session state). • In order to access the eHRPD AN, it needs to acquire CDMA system time and HRPD overhead information. • Assume CDMA system time is available from LTE SIB8. • HRPD overhead includes SystemParameters, QuickConfig, and AccessParameters messages. • However, in a multicarrier eHRPD network, the SystemParameters message (SPM) will contain multiple Channels/ExtendedChannels. • If a BTS is transmitting a N-channel SPM, then (N-1)/N of the ATs will end up hashing upon acquiring that sector.

19. Latency Impact • Per C.S0024-A, the recommended maximum number of control channel cycles between 2 consecutive SectorParameter transmissions is 4 (NOMPSectorParameters) • Each control channel cycle is 256 slots, or 426.7ms. So this means that the UE could wait up to 1.7 seconds to get the SectorParameters, only to be told it needs to hash to another carrier. • Average delay would be ½ of this, 853ms. • In deployments, the SectorParameters is generally repeated every other cycle, so the delay would only be up to 853ms. • The SectorParameters can be a large message, so repeating it faster is impractical. • Each HRPD sector is an independent AN*, so after hashing to the new channel, the UE still needs to re-receive the overhead messages on the new sector. • However, if the UE has previously monitored this sector, and the signature has not changed, it could restore previously received configuration without further delay. *A “sector” as specified in C.S0024-A is identified by (SectorID, CDMA Channel); perhaps more conventionally called a sector-carrier.

20. Potential Solutions • So we have shown that in a N-carrier eHRPD system, some ATs may suffer up to 1.7second latency due to hashing. Assuming an every-other-cycle repeat, then the average latency is (N-1)/N * 853ms. So in a 2 carrier BTS the average hashing latency is 427ms. • Two basic solutions can be considered to eliminate the hashing latency without otherwise changing the callflow: • 1) No Hash – UEs in this state do not hash from their assigned carrier. • 2) Pre-Hash – During the redirection, the UE is given sufficient information so it can select the correctly hashed eHRPD carrier initially.

21. No Hash Solution • With the No Hash solution, the UE performs overhead acquisition normally, but does not actually hash to a different carrier in the normal sunny day case. The UE simply acquires overhead on the target carrier and accesses the target carrier. • To avoid becoming lost, the UE only remains in this special no hash state for a long enough time to setup a connection after the redirection. Otherwise it reverts to normal behavior. • This type of behavior already exists in eHRPD—when the UE is listening to a BCMCS flow, it may suspend hashing and remain indefinitely on a non-hashed BCMCS carrier. • Critical issue to be addressed is load balancing.

22. Load Balancing • The main reason for hashing is to balance RAN access & control channel loading across all the serving carriers. • Note that regardless of which carrier the UE uses to access the network, the AN can always assign a different carrier for a traffic connection. • Hashing balances the load in aggregate, but is often ineffective at balancing the instantaneous load. • If 2 UEs are simultaneously redirected to a 2 carrier eHRPD system with hashing, then there is a 50% chance that they would both hash to the same carrier. i.e. the load was not balanced. • Access/Control channel load balancing may not truly be necessary if sufficient access/control channel resources are equipped. • With the No Hash option, if load balancing is desired it can be accomplished by simple round-robin redirection from the eNB.

23. Pre-Hash The pre-hash solution would require tight coupling between the EUTRAN and the underlying eHRPD network. eNB would need to know detailed information about the underlying eHRPD network, and this information would need to be changed in real time if the underlying eHRPD network changed. It also would require 3GPP and 3GPP2 standards changes, which would delay availability. While the pre-hash solution is adequate, Alcatel-Lucent believes the “No Hash” Solution to be superior.

24. Next Steps • Alcatel-Lucent will bring a contribution to 3GPP2 TSG-C proposing to add text to C.S0087 stating that the UE will temporarily skip the performance of channel hashing after redirection from LTE. • Changes to UE are required. • No changes to eHRPD RAN or LTE EUTRAN are required, although implementation of the round robin assignment in the eNB would be optional.