Professional Documents
Culture Documents
Fallback
Ultra-Flash CSFB
White Paper
Senior Researcher: Xiaobo Wu, Wireless MBB Research Department, Wireless Network Research Department, Huawei
Area of expertise: LTE Voice, CSFB, VoLTE/SRVCC
Xiaobo Wu has over eight years of experience in telecommunications. As a leading technical member of Huawei’s Wireless
Service and Network Evolution Research team, he is responsible for voice solution research and its standardization, e.g.
CSFB, VoLTE/SRVCC.
Xiaobo Wu is also a delegate representing Huawei in 3GPP’s working group for system architecture. His expertise in LTE
voice is broadly acknowledged by the 3GPP standards community and he is recognized as an outstanding delegate of that
3GPP working group.
1
Ultra-Flash CSFB White Paper
LTE Voice Solutions Introduction A voice interruption of shorter than 300 ms is mandatory
for commercial voice services, which requires excellent
Long Term Evolution (LTE) has become a globally deployed synchronization between SRVCC IRAT Handover and
standard. However, as an all-IP, data-only transport SRVCC Session Transfer procedures.
technology utilizing packet switching, LTE and LTE-capable
terminals introduce new challenges for meeting the This synchronization is one of the biggest challenges for
quality of service expectations established by SRVCC. 3GPP consequently introduced enhanced SRVCC
circuit-switched mobile telephony. (eSRVCC) in Rel-10 for better synchronization, which
comes with a new Access Transfer Control Function
3GPP developed two approaches for providing voice (ATCF)/Access Transfer Gateway (ATGW) in the IMS
services with LTE: Circuit-Switched Fallback (CSFB) and signaling/media path.
Voice over LTE (VoLTE), which is supported by Single Radio
Voice Call Continuity (SRVCC). Figure 1 CSFB Architecture
Compared to a native 2/3G CS call, a main drawback of Besides long call-setup times, there are other difficulties
legacy CSFB is the amount of steps that are added for inherent to CSFB deployment and its evolution towards
switching from LTE to 2/3G networks before the voice call, VoLTE/SRVCC in the future. Specifically, CSFB requires
which incurs longer call-setup times, especially in case of strict mapping between the Tracking Area (TA) and
LTE to GSM CSFB, as shown in Figure 3. Location Area (LA) as well as the upgrading of all MSC
Servers surrounding the LTE coverage.
Figure 3 CSFB Call Delay
Also, since mapping between TA and LA cannot be 100%
accurate, operators have to do a lot of CSFB-specific
network planning/configuring, like adjusting existing 2/3G
Location Areas (LA) for better mapping to LTE Tracking
Areas (TA).
As shown in Figure 5, with a default LTE data network Figure 5 Starting a CSFB call
connection in operation, the UE triggers a mobile
originating (outgoing) CS voice call by sending an Extended
Service Request message to the MME.
These two steps bring major gains for the call setup time,
even with the longer CSFB-specific time needed for
switching the RAT.
In other words, Ultra-Flash CSFB can provide an even The Second Aspect
shorter call-setup time than a native 2/3G CS call. One The MSC Server has already obtained some key
may wonder why this can happen. information for the CS call during the SRVCC IRAT
Handover procedure, so it can skip some NAS procedures
The key factor is Ultra-Flash CSFB triggers the SRVCC IRAT when the UE initiates the CS call via 2/3G after the
Handover during the CSFB procedure, which results in switching, specifically:
faster call-setups even for scenarios involving switching Skipping the authentication procedure as the UE
from LTE to 2/3G. and network generate a CS security key during the
SRVCC procedure.
Faster call-setup times from Ultra-Flash CSFB are possible Skipping IMSI/IMEI retrieval procedures as the MSC
due to the following three aspects: Server gets them from MME.
Skipping or delaying TMSI Reallocation procedure.
The First Aspect
During a SRVCC IRAT Handover procedure, Ultra-Flash The Third Aspect
CSFB performs some CS call-related procedures in parallel In case of Ultra-Flash CSFB to GERAN, the call-setup
to switching from LTE to 2G/3G, specifically: signaling exchange between UE and GERAN is very quick
During CSFB-triggered switching, the CS RAB is with the pre-allocated radio resource, where all the
already pre-allocated by the SRVCC IRAT Handover signaling is transmitted via a fast signaling channel that
procedure, so there is no need for the CS RAB
uses the traffic channel.
Table1 Mobile Originated call-setup times for Ultra-Flash CSFB compared to native UTRAN CS calls, PS HO-based CSFB
and redirection-based CSFB. (All units are in milliseconds.)
Native UTRAN Redirection- PS HO- Ultra-Flash
UTRAN Mobile Originating
CS Call Based CSFB Based CSFB CSFB
Service Request for CSFB 0 150 150 150
IRAT Measurement 0 0 200 200
Handover from LTE to UTRAN 0 0 500 500
Redirection from LTE to UTRAN 0 1100 0 0
CS Call-Setup Procedure 4850 5750 5650 2750
Total 4850 7000 6500 3600
Above data for CSFB to CSFB and Ultra-Flash CSFB to Ultra-Flash CSFB based on Huawei Lab test data. Call-setup
times are from “UE triggering CS call” to “UE receiving Alerting”.
Analysis shows Ultra-Flash CSFB to GERAN is similar to UTRAN. But legacy CSFB to GERAN is much worse than to
UTRAN as shown in Figure 3.
Call-setup time shown for legacy CSFB may even need to add another 1 to 2 seconds when the CSFB needs to
include a Location Area Update or MTRR/MTRF procedure.
Ultra-Flash CSFB White Paper
Figure 7 Mobile Originated call-setup Times for UTRAN (All units are in milliseconds)
Figure 8 below shows the major phases of Voice with IMS is gradual with some early deployments and
evolution. trials. In this phase, CS services such as voice and
emergency calls are still mainly delivered using Ultra-Flash
The initial phase in LTE voice evolution introduces CSFB, CSFB even when IMS is deployed.
which currently is under way. CSFB means all voice traffic
is handled by legacy Circuit-Switched (CS) networks, while The final phase of LTE voice evolution introduces native
data traffic is preferably handled by LTE Packet-Switched VoLTE and full SRVCC functionality (including SRVCC IRAT
(PS) for LTE capable terminals. Handover and SRVCC Session Transfer). Please note that
Ultra-Flash CSFB is still heavily used at this stage especially
During the next phase in LTE voice evolution currently for roaming terminals from networks without IMS and
under way, Ultra-Flash CSFB based on SRVCC IRAT emergency call services.
Handover will be introduced. Transition to VoLTE/SRVCC
Conclusions
Transition to VoLTE will be gradual and will not occur over call-setup time and comes as an easy and future-proof
a short period of time. CSFB will remain in place and deployment.
co-exist with VoLTE for a long time.
Furthermore, Ultra-Flash CSFB relies on only a subset from
This, however, does not change the fact that legacy CSFB the overall SRVCC and supports easy evolution to
has a long call-setup time and some difficulties for VoLTE/SRVCC, which heavily saves operator investments.
deployment as well as for evolution towards It might, however, require some limited software updates
VoLTE/SRVCC. in the eNB (optional for UTRAN)/MME/MSC Server
compared to standard SRVCC functionality.
Compared to legacy CSFB, Ultra-Flash CSFB requires
deploying the IRAT Handover from SRVCC but has no In the scope of this paper, it is assumed all that UEs
impact on LTE-capable terminals and GERAN/UTRAN. support SRVCC IRAT Handover. Ultra-Flash CSFB is also
possible with a non-SRVCC IRAT Handover-capable UE and
Due to using the SRVCC IRAT Handover procedure, can provide decent call-setup improvements, but enabling
Ultra-Flash CSFB can significantly improve the CSFB this requires some additional small updates for
GERAN/UTRAN RATs.
References
[1] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".
[2] 3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2".
Copyright © Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any
means without prior written consent of Huawei Technologies Co., Ltd.
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other
trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the commercial contract made
between Huawei and the customer. All or partial products, services and features described in this
document may not be within the purchased scope or the usage scope. Unless otherwise agreed
by the contract, all statements, information, and recommendations in this document are provided
“AS IS” without warranties, guarantees or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made
in the preparation of this document to ensure accuracy of the contents, but all statements, information,
and recommendations in this document do not constitute the warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com