You are on page 1of 36

CS services in LTE- An Overview

Prepared by: Darshan Patil


Sr. Engineer, Alcatel Lucent Managed Solutions India
Summary
What? To support CS services in LTE
Why? Need to support CS services in LTE
When? Different Phases of evolution of Voice over LTE
(VoLTE)
How? Network methodologies to implement CS services
in LTE network
WHAT?
LTE is All- IP data only support technology using
packet switching
This subjects to challenges for CS services in LTE as
referred to all the legacy networks which support
them currently
Solutions to provide CS services in LTE network
Inter-networking solutions to provide CS services in
LTE network
WHY?
Current legacy networks increase expectations to improve
the efficiency of the services they are providing
This includes Voice, SMS, Video Call, High data rate internet
and streaming etc. Services
The evolution of LTE technology is to significantly improve
the user experience, substantially improving end-user
throughputs, increasing sector capacity, and reducing user
plane latency
Though, due to lack of Circuit switching, the technology has
a need to find some way outs to provide CS service
solutions at par with the current legacy networks
Also, till the time when LTE completely swaps the legacy
networks there is a need for internetworking with them
WHEN?
Comparison between
Dual Radio Solutions
o use two always-on radios (and
supporting chipsets), one for
packet switched LTE data and one
for circuit switched telephony,
and as a data fallback where LTE
is not available
o have emerged for LTE-CDMA2000
network interworking driven by
time-to-market pressures
o Battery gets drained faster due to
two radio antennas and chipsets
Single Radio Solutions
o use one radio to handle both
types of traffic, and use network
signaling to determine when to
switch from the PS network to
the CS network
o this solution is universally
accepted for LTE-3GPP network
interworking solutions
o Power consumption of the
battery is fairly reduced due to
single antenna single chipset.
Phases of Single radio solutions for
VoLTE
Phase I:
Circuit Switched Fall Back (CSFB) addresses the requirements of the
first phase of the evolution of mobile voice services, which began on
commercial scale in 2011
primarily due to inherent cost, size and power advantages of single
radio solutions on the device side.
CSFB is the solution to the reality of mixed networks today and
throughout the transition to ubiquitous all-LTE networks in the future
phases of LTE voice evolution
All the voice traffic is handled by current legacy CS networks
(UMTS/GSM/CDMA)
All the data traffic is handled by LTE PS network wherever and
whenever available
The traffic will be able to fallback to 2G/3G network in non-LTE
network
Phases of Single radio solutions for
VoLTE
Phase II:
The second phase in LTE voice evolution introduces native VoIP on LTE (VoLTE)
along with enhanced IP multimedia services such as video telephony, HD Voice
and Rich Communication Suite (RCS) additions like instant messaging, video
share and enhanced/shared phonebooks
This phase also uses a single radio solution with Single Radio Voice Call
Continuity (SRVCC) that seamlessly maintains voice calls as mobile users move
between LTE and non-LTE coverage areas
CSFB continues to be deployed during phase 2, to provide voice services for
roamers and CSFB only devices
Without SRVCC, a VoLTE call on a device moving out of LTE coverage will be
dropped, since no operators currently support VoIP on 3G
Phases of Single radio solutions for
VoLTE
Phase III:
converges the native power of IP to deliver
enhanced capacity, value-added services (e.g.,
voice and video over IP and rich communication
services) and interoperability across network
access methods and operators (LTE, 3G/ HSPA, Wi-
Fi and legacy telephony domains)
HOW?
Phase I: CSFB
The architecture in Figure below shows a simplified view of
the parallel LTE and 2G/3G networks.
Phase I: CSFB CN procedures
The legacy network (2G/3G) and LTE network co-exists
To support CS Fallback signaling and SMS transfer for
LTE devices, the MME connects to the MSC Server
MME is the mobility management entity serving users
while in LTE access. It is responsible for maintaining
SGs association towards MSC, initiating paging
procedure towards eNodeB during CSFB
MME Support SMS procedures
MSC is responsible for maintaining SGs association
towards MME for EPS/IMSI attached UE
SGs interface
It is the reference point between the MME and MSC server. SGs
interface is used for the mobility management and paging
procedures between EPS and CS domain, and is based on the Gs
interface procedures.
It enables the users device to be both CS and PS registered while
on the LTE access network. This interface also enables the delivery
of CS pages via the LTE access, as well as SMS, without having the
device leave LTE.
The SGs reference point is also used for the delivery of both mobile
originating and mobile terminating SMS.
At MME - MSC Server interface a new protcol SGsAP is being added
to support CS fallback. SGsAP protocol is based on the BSSAP+.
Stream Control Transmission Protocol (SCTP) is used to transport
SGsAP signaling messages.
CSFB- Incoming Call
With the default LTE data network connection in operation, a
mobile terminating (incoming) CS voice call triggers a page via
LTE to the users device, as shown in below Figure
CSFB- Incoming Call continued..
This page initiates CSFB, as the device sends an extended
service request to the network to transition to 2G/3G, as
shown in below Figure
Once transitioned, the legacy call setup procedures are
followed to setup the CS call.
CSFB- Incoming Call continued..
When the voice call ends, the device returns to LTE via idle
mode or connected mode mobility procedures, as shown in
below Figure
CSFB- Outgoing call
Mobile originating (outgoing) calls follow the
same transition from LTE (PS) to 2G/3G (CS),
except for the paging step, which is not
needed.
Simultaneous PS and CS services in
CSFB
Depends on the DTM feature availability with the
legacy network
In 3G networks, PS data sessions can also move
for simultaneous voice and data services.
In 2G networks, PS data sessions may be
suspended until the voice call ends and the
device returns to LTE, unless the 2G network
supports dual transfer mode (DTM), which
permits simultaneous voice and data.
Phase I: CSFB RAN procedures
Acquisition of the 2G/3G network and setup of the call can employ one of two
procedures: handover or redirection.
Handover
Target cell is prepared in advance
Device enters in connected mode
during IRAT
Signal strength measurements
are done prior to HO to 2G/3G
(i.e in LTE access mode)
Process require more time to
identify the best cell
Under changing IRAT
environments, this method
proves to be not much efficient
Therefore it is not widely
followed method currently
Redirection
Target frequency is indicated
UE may choose other IRAT
frequency cell if no cell could be
found out in target frequency
After UE has access to legacy
network, call setup procedure has
to be initiated
IRAT measurements are not
required prior to Redirection
As per statistics, a marginal loss in
performance in this method as
compared to Handover based IRAT
can be accepted to compensate
variable IRAT RF environment
CSFB w/ Reselection
Three types of procedures according to System Information
Blocks sent to the UE
1. Release 8 Basic Redirection:
UE reads all the SIBs before having an access to the
target cell
2. Release 8 with SIB skipping
Mandatory SIBs like 1,3,5,7 are only read by the UE. After
it accesses the target cell, in connected mode it reads the
neighbor info present in SIB 11
3. Release 9 Enhanced (SI tunneling)
where SIB information can be tunneled from the target
Radio Access Network (RAN) via the core network to the
source RAN and be included in the redirection message
sent to the device. This can avoid reading any SIBs on the
target cell.
CSFB Performance Indices
After commercial deployments, CSFB have been par with
the 3GPP performance requirements for 3G UMTS.
These basic requirements includes Call setup time (mobile
originated and mobile terminated), Call reliability, LTE to 3G
cell handover time, PS data interruption time.
Call reliability in case of Handover based CSFB process is
poor due to variable RF environment
Call reliability in case of Redirection based procedure is
better than Handover based as per statistics due to no
delay in between identification and accessing the target
cell.
Rel9- SI tunneling has slightly better call reliability (about
99%- 100%) than Rel8- Basic Reselection.
CSFB Outgoing Call setup penalty time
Sr. No RAN procedure Transition to Sub category Call setup time
penalty
1 Handover Based 3G UMTS NA 0.4S > CST of 3G
2 Redirection 3G UMTS Rel8- Basic 2.5S > CST of 3G
Rel8- SIB skip 0.9S > CST of 3G
Rel9- SI tunnel 0.5S > CST of 3G
3 Handover 2G GSM NA 2.6S > CST of 3G
2.7S > CST of 2G
4 Redirection 2G GSM Rel9- Basic 2.6S > CST of 2G
2.5S > CST of 3G
Rel8- SIB skip NA
Rel9- SI tunnel 0.6S > CST of 2G
0.5S > CST of 3G
CSFB Incoming Call
Sr. No RAN procedure Transition to Sub category Call setup time
penalty
1 Handover Based 3G UMTS NA 0.4S > CST of 3G
2 Redirection 3G UMTS Rel8- Basic 2.5S > CST of 3G
Rel8- SIB skip 0.9S > CST of 3G
Rel9- SI tunnel 0.5S > CST of 3G
3 Handover 2G GSM NA NA
4 Redirection 2G GSM Rel9- Basic
Rel8- SIB skip
Rel9- SI tunnel
CSFB Data Interruption time
The active session PS data interruption time during LTE PS to
2G/3G CS and reverse
Sr. No RAN procedure Transition to Sub category Data
interruption
time
1 Handover Based 3G UMTS NA 0.3S
2 Redirection 3G UMTS Rel8- Basic 6.8S
Rel8- SIB skip 5.1S
Rel9- SI tunnel 4.8S
3 Handover 2G GSM NA NA
4 Redirection 2G GSM Rel9- Basic
Rel8- SIB skip
Rel9- SI tunnel
LTE to 3G cell Handover time
Time taken to handover is never identical due to varied Rf
environment
Delay added by LAU may increase Ho time. Further if the
Lte cell is overlapped with multiple LAs, the delay can
increase up to 1-2 seconds
Fewer times, apart from updating LAs TAs, there would be
need to update HLR data between diff overlapping MSCs.
More uncertainties can add to the delay further.
Solutions to the above:
IU/A Flex
MTRF
MSC pooled architecture planning
Phase II: VoLTE and SRVCC
Voice over IP can be implemented in two ways:
1. using Over the top (OTT) VOIP applications such as skype, Ekiga,
Goober etc..
2. using native VOIP using additional entities such as IMS and MMTel in
core network
Using OTT services is not recommended as the Qos is similar to NRT
services with no special priorities to voice. Therefore, even the
voice quality of current legacy CS services is not matched
VoLTE, in contrast, operates as a native application in the users
device, enabling prioritization over other data streams to deliver
quality of service levels consistent with established user
expectations
In non-LTE network, this quality is taken care by 2G/3G networks
which can be accessed using SRVCC (Single Radio Voice Call
Continuity) method of IRAT HO
SRVCC Network Architecture
MMTel and Sv
The 3GPP/NGN IP Multimedia Subsystem (IMS) multimedia
telephony service (MMTel) is a global standard based on the
IMS, offering converged, fixed and mobile real-time
multimedia communication using the media capabilities such
as voice, real-time video, text, file transfer and sharing of
pictures, audio and video clips. With MMTel, users have the
capability to add and drop media during a session.
Sv is defined in TS 23.216, where it is defined as the reference
point between the MME/SGSN and MSC Server.
SRVCC Procedure
1. User (UE) is in active voice call in LTE network using VoLTE with the help of
IMS as shown in below figure
2. User moves from a LTE network to a non-LTE network (3G-UMTS), the active
call remains under the control of IMS throughout the handover process
SRVCC Procedure
3. Two step process of SRVCC from LTE to 2G/3G
IRAT Handover
IRAT handover is the traditional handover of the
users device from LTE radio access to
WCDMA/GSM radio access
Session transfer
Session transfer is a new mechanism to move
access control and voice media anchoring from
the LTE Evolved Packet Core (EPC) to the legacy CS
core
SRVCC Procedure
4. The handover process is initiated by a session
transfer request to the IMS/MMTel as shown
below
SRVCC Procedure
5. The IMS/MMTel responds simultaneously with two commands
i. Sending an IRAT HO execution command to the LTE network on which
the voice call is in progress through MME & Lte RAN to instruct the UE
to prepare to move to CS network for the voice call
ii. Sending a session transfer response to the CS n/w where the users
voice call is being sent asking to prepare to accept the call in progress
SRVCC Procedure
Both the n/w send acknowledgements
respectively and under the control of the IMS/
MMTel, the call is switched to 2G/3G n/w
Network upgrades required for SRVCC
methodology
Sr. No Entity Up gradation required?
1 LTE E-UTRAN Yes
2 LTE EPS Yes
3 IMS Core/ MMTel Yes
4 2G/3G Core (MSC) Yes
5 2G/3G RAN No
6 UE (user equipment) Yes
PI for SRVCC
o Voice interruption time:
1. IRAT HO execution process requires more time than session
transfer procedure (of the order 0.01S). Therefore voice
interruption time is influenced primarily by the IRAT HO execution
time.
2. Further, we need to consider addition of time required to confirm
the HO execution after HO process
3. The total voice interruption time is at par with the 3GPP
guidelines of 0.3S
o Call Retention rate depends on:
1. Probability of IRAT failure
2. Probability of Session transfer failure
3. Current stats show it as 99%
References
3GPP specs
Qualcom(VoLTE phases)
China Mobile (CSFB)
Nokia Seimens (CSFB)
Ericsson (VoLTE phases)
Alcatel-Lucent (LTE Network Architecture)
Future Scope of VoLTE
Enhanced SRVCC Next article
Video SRVCC Next article
CSFB and VoLTE Roaming (Phase III)

You might also like