Abstract— Long Term Evolution (LTE) as an evolution of fourth
generation (4G) technology offers high data rate of upto 100
Mbps for data applications. But it lacks native support for
Circuit Switched (CS) voice service which has been the main
revenue generator for operators. This introduces the problem of
how to provide voice call when a user is in LTE and how to
ensure voice call continuity when it moves out of LTE coverage.
There are possible technical solutions e.g CS fallback, Single
Radio Voice Call Continuity (SRVCC), Voice over LTE via
Generic Access (VoLGA), third party services like skype for
providing voice call and voice call continuity over LTE. The
paper compares various aspects of these solutions and suggests
possible roadmap that operators can adopt to provide seamless
voice over LTE.
Keywords-LTE, CS fallback, SRVCC, VoLGA, VoLTE
I. INTRODUCTION
LTE as an evolution of 4G technology is becoming popular as the next generation technology supporting high data rates. It is the next step in the evolution of cellular communication data networks which will support mobile broadband services with peak data rates 100 Mbps (downlink) and 50 Mbps (uplink). The main motivation for LTE has been data services and as a result it has only Packet Switched (PS) domain support. Traditionally in second and third generation i.e 2/3G cellular networks the voice call has been provided over CS domain. Also, voice call application has been the primary application since cellular networks inception and how much ever the data services become popular, users still expect voice as a basic service provided by the operator.
Lack of the CS domain raises the question of how to provide the voice call over LTE and how to ensure the voice call continuity when the user moves from LTE to 2/3G networks. The paper discusses various solutions available in the market today i.e Circuit Switched fallback[2], SRVCC[3], VoLGA [5] and third party Voice over Internet Protocol (VoIP) solutions like skype. The paper also compares them on the basis of criteria like impact on the network nodes and User Equipment (UE), cost of deployment, disruption of other PS services besides voice, utilization of existing 2/3G infrastructure etc. Based on the analysis the paper also suggests the suitable alternatives for the operators considering various deployment scenarios.
II. BACKGROUND
A. Native CS Service and its necessity
Traditionally voice calls were initiated with fixed phones
and using the functionality of Public Switched Telephone
Network system. The technology relied on the wired network,
connected together with Switching Centers. With advance in
technology, the wireless telecommunication systems were
introduced and instead of fixed telephones being used in the
PSTN system, mobiles can be used. The users could be talking
while on the move. The telecommunication system utilizes the
PSTN’s circuit switched technology to deliver voice calls.
Using circuit switched technology means the entire
communication resources between the source and target are
reserved for the duration of the voice call. Of course this is
expensive solution but at the same time this is very effective
for voice communication due to quality of service (QoS)
guarantee and low latency during communication.
But this leads to a problem of wasting the reserved
resources for the duration of the call. Packet system alleviates
this problem by breaking information into packets with source
and destination addresses, with sequence information and they
can be reassembled on reaching the target. VoIP utilizes the
packet switched technology for the voice call. The service is
really cheap as compared to circuit switched technology as the
resources can be shared amongst users but still the circuit
switched calls are preferable over VoIP based calls. The
simple reason is the reliability for transferring the information
with CS calls; VoIP calls are based on best effort service and
are subject to packet loss during congestion. Another reason is
reutilizing the huge investment already made in PSTN
networks.
With packet switched system becoming more popular for
carrying data, the Internet Protocol Multimedia Subsystem
(IMS) was introduced to ensure QoS for various multimedia
services including voice. This alleviates the problem with VoIP
calls and ensures that a voice call quality could be as good as
the circuit switched based voice call. The downside of IMS is
that it is huge investment with no clear cut benefit over the
existing internet based applications. Hence, practical IMS
deployments are yet to occur. This is in essence the different ways in which voice
services can be provided i.e CS based voice calls which are more reliable and there is already a huge 2/3G infrastructure in place, VoIP by using skype like services which is a very inexpensive option with no QoS guarantee or using voice
service provided by IMS which is very costly alternative. The initial cellular systems i.e 2/3G supported both CS and PS domains, CS domain being used for voice calls and PS domain primarily for data services. With the introduction of the LTE system, which promised data rates of 100 Mbps approximately, data service became even more important for multimedia streaming, conferencing and broadcasting. The missing feature with the LTE is that is supports only PS domain and hence lacks native support for CS based voice calls and other CS services like Short Message Service(SMS). Both CS based voice call and SMS have been the major revenue generators for network operators and missing on these two features will be a big disadvantage for both the users and the operators. The paper analyses different solutions for providing seamless voice over LTE.
III. CURRENT SOLUTIONS
Current available solutions for the operators are: 1. CS fallback, 2. SRVCC, 3. VoLGA, and 4. Third party VoIP services like skype.
A. CS fallback
CS fallback solution utilizes the existing 2/3G infrastructure by performing a handover of the UE to 2/3G whenever the UE in LTE makes/receives a call [2]. The prerequisite here is that LTE coverage is always with in the 2/3G coverage. The architecture for CS fallback is as shown in Figure 1.
Figure 1: CS fallback architecture
The solution introduces a new interface, SGs, between the Mobility Management Entity (MME) in LTE and the legacy Mobile Switching Center (MSC) in 2/3G. The SGs reference point is used for the mobility management and paging procedures between Enhanced Packet Service (EPS) and CS domain, and is based on the Gs interface between the Serving GPRS Support Node (SGSN) and MSC.
For a mobile originating call, the UE requests the MME for performing the CS fallback. The MME in turn requests the eNodeB to perform CS fallback by sending appropriate signaling message. The eNodeB triggers inter-RAT handover towards the target 2/3G and the UE receives a handover
command to move to the 2/3G side. The UE initiates the voice call on reaching the target Universal Terrestrial Radio Access network (UTRAN) /GPRS EDGE Radio Access Network (GERAN) side. While the UE was on the source LTE side, it might have other PS connections ongoing besides the PS connection for voice call. Those PS connections are either suspended or continued based on the target cell’s capability. In either case the user will experience degradation in the QoS.
For a terminating call in CS domain, the MSC receives the message for an incoming call and sends a paging request to the MME. The MME in turn sends the paging request to the eNodeB which starts handover procedure for the UE. The UE receives the call after moving to 2/3G target side.
The CS fallback approach has impacts on the UE, the eNodeB, the MME and the legacy MSC. The UE should be able to access LTE and 2/3G access networks simultaneously and should be able to perform a combined EPS/IMSI attach i.e attaching to the MME in LTE as well as the MSC in 2/3G network. The MME requires additional functionality of maintaining the SGs association towards the MSC for the EPS/IMSI attached UE. It also has to perform paging when the MSC receives a paging request in the 2/3G network. The MME also needs to derive the Visited Location Registrar (VLR) number of the MSC to contact when the UE attaches to the LTE network and also maintain the tracking area lists appropriately. For CS fallback the MME has to update the tracking area list allocation process so that the TAI list doesn’t span over multiple location areas unlike normal tracking area list allocation. The legacy MSC requires changes i.e maintains the combined attached status of the UE and page the UE over SGs association when a paging request for incoming call is received for the UE in LTE. The eNodeB also needs update for forwarding the CS paging requests to the UE, directing it to the target RAT and facilitating the tracking area list management.
B. SRVCC
Single Radio Voice Call Continuity is an IMS based solution which involves updates to the legacy MSC, MME and the UE [3]. The precondition for SRVCC solution is that the UE should have initiated a voice call using IMS in the LTE coverage and the application server used for IMS session transfer should have been introduced in the IMS signaling path during voice call session establishment. This particular procedure is known as anchoring the call in application server. The architecture for SRVCC solution is as in Figure 2.
The solution uses a combination of handover procedure at the access network and the IMS session continuity procedure at the IMS. The UE indicates its SRVCC capability to the MME during the mobility management procedures which in turn provides a ‘SRVCC operation possible’ indication to the eNodeB. Whenever an SRVCC capable UE is losing LTE coverage, the eNodeB detects it and triggers handover procedure towards the MME. The MME supports a new Sv interface towards the MSC server enhanced for SRVCC, and forwards the SRVCC handover request towards the target 2/3G network via the MSC server. The MSC server acts as an inter-working function (IWF) and prepares the target side for handover. In parallel to the target preparation it also triggers
session transfer procedure at the Services Centralization and Continuity Application Server (SCC AS). The target 2/3G preparation is completed and the core network performs a hand over of the UE to the target side by sending a handover command, also the IMS session transfer is completed in parallel.
xxxx
xx
Figure 2: Single Radio Voice Call Continuity procedure
The solution involves changes to the UE for signalling its
‘SRVCC capability’ towards the network and for maintaining the CS call state machine. The eNodeB needs enhancement in order to prepare appropriate information for the target RAN and trigger SRVCC handover. The MME separates the bearer carrying voice from other bearers and also signals MSC server about the SRVCC handover. The MSC server acts like an IWF and legacy MSCs needs enhancement or a new MSC server itself can be deployed.
1) VoLTE initiative by GSMA In order to bring a single implementation solution for
providing voice service over LTE GSM Association (GSMA) started VoLTE initiative in February 2010[6]. This encompasses providing a single implementation specification for the various interfaces like User Network Interface (UNI), the roaming network interface (R-NNI) and the Interconnect Network Network interface (I-NNI), this will help in supporting roaming. For voice call continuity option Single Radio Voice Call Continuity solution is selected whose profiling work is already done as part of One Voice Initiative [8].
C. VoLGA
Voice over LTE via Generic Access is based on the GAN standard [4] which is already being used by operators [7]. These operators use the GAN standard to extend 3GPP coverage by using dual mode mobiles which can access the 3G services over Wifi. The GAN idea is to introduce a gateway between Wifi and 3GPP network which transfers the signaling between the terminal and the 3GPP network. The architecture adapted for LTE voice call continuity is shown in Figure 3.
xx
xx
xx
Figure 3: Architecture for VoLGA
There are no changes to the existing LTE network, RAN or
target legacy side, rather a new gateway called as VolGA Access Network Controller i.e VANC has been introduced. The VANC securely supports the A/Iu-cs interface towards the target MSC/VLR and is seen as a Base Station Controller (BSC) by GERAN or Radio Network Controller (RNC) by UTRAN target network. It also supports SGi interface towards the Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) and hence seen as an application function by the SGW/PGW. The VANC also includes a security gateway function that terminates a secure remote access tunnel from each UE providing mutual authentication, encryption and integrity protection for signaling traffic. A new protocol runs between the UE and the VANC and VANC converts the messages received from the UE to appropriate signaling towards the MSC. For handover SRVCC functionality is to be reutilized.
D. Using services like skype
Apart from all the above solutions, another simple way to provide voice call over LTE is to utilize the third party VoIP services like skype. So, there will be no changes to the network and the terminal. The user can simply download the VoIP application and use it over the existing LTE data connection.
IV. ANALYSIS
1) Pros and Cons for CS fallback: The CS fallback approach offers the advantage that the
operators can utilize their existing 2/3G infrastructure to provide the voice call over LTE. The main problem with CS fallback solution is the additional increase in call set up time. This is because of the handover to 2/3G for initiating/receiving the call, thereby degrading the user experience. And it is not only for the initial call; the procedure has to be repeated for every single call. Another problem with CS fallback solution is that every time the user initiates/receives a voice call, the UE will be handed over to 2/3G and the user will see degradation in QoS of the existing PS data connections besides voice. Worse still if the target is GERAN without simultaneous CS and PS domain support, no data service can be obtained during
the voice call. The solution requires legacy MSC update which is not favorable from operators’ point of view as the MSC updates are not straight forward and very costly.
2) Pros and Cons for SRVCC: The advantage of SRVCC compared to CS fallback is that
it is triggered only when the UE is losing the LTE coverage hence the user experiences degradation in QoS for other data connections only when the UE starts losing coverage. SRVCC is being supported by the operators and industry by IMS ‘One Voice’ profile which aims to achieve an industry agreement on a harmonized way to implement voice and SMS based on existing standards – “Voice over IMS Profile’ specification [8]. Also Voice over LTE initiative by GSMA is supporting SRVCC solution. On the other hand the drawback of SRVCC solution is that it is based on IMS which is a costly and complex solution and it will take a long time before large scale commercial IMS deployments can be available. If LTE is deployed only as very small islands initially then the SRVCC operation might be triggered very frequently bringing the disadvantage similar to the CS fallback.
3) Pros and Cons for VoLGA: The biggest advantage of VoLGA is that UE can access
both voice using CS domain and data service using LTE simultaneously unlike CS fallback which requires a handover to the target 2/3G every time a call is made/received. It reutilizes the current CS infrastructure without increasing the call setup time. It doesn’t impact existing core network nodes like the MME, the SGSNs or the MSCs. The VoLGA solution is not only applicable for voice but also for other circuit switched services like SMS. The problem with VoLGA is that it has not been adopted and standardized by 3GPP with most of the operators not showing an interest in it. The work is still ongoing for VoLGA and it requires a GAN based dual mode terminal also having SRVCC capability for voice call continuity. The solution for roaming is problematic because for supporting the roaming the visited network also needs to deploy additional VANCs just for supporting roaming UEs. Of course the solution requires new network node i.e VANC.
4) Pros and Cons for third party VoIP solutions like
skype: This is a very simple solution with no/very little extra cost
for the operators. And especially helpful for operators which do not have a legacy network for CS fallback or VoLGA like solutions and who don’t want to invest in IMS either for the time being. It’s quick to start with absolutely no impacts on the terminal or network nodes. On the other hand the solution doesn’t guarantee the QoS. Also, Voice call continuity can not be ensured when UE moves out of LTE which might be very serious if LTE coverage is small.
Different operators have different LTE deployment plans for example some operators already have 2/3G infrastructure and plan to deploy LTE in small areas overlapping with 2/3G deployments. Some operators might aim for IMS as the final solution for providing rich multimedia services in future even though they have legacy 2/3G network.
On the other hand some operators might deploy LTE afresh along with IMS deployment. Such operators lack any legacy
circuit switched support. Another set of operators might just deploy LTE without having legacy 2/3G or IMS support. Some operators also have existing GAN deployments e.g. T-mobile [7].
The possible technical solutions can be directly correlated with the network operator plan of deployment as in Table 1:
CS fallback SRVCC VoLGA Third party
VoIP solution e.g
Skype
Operator has legacy 2/3G network and
doesn’t plan
to deploy IMS
Yes, more disruptive for data
services
No Yes, less disruptive but more
costly as it
has requires new UEs
and
VANCs.
Yes, inexpensive with no QoS
guarantee.
Has legacy
2/3G but plans to
deploy IMS
later.
Yes, can
serve as intermediate
solution
Yes, as
final solution
when IMS
is deployed
Yes, can
serve as intermediate
solution.
Yes
inexpensive with no QoS
guarantee
Operator doesn’t have
legacy 2/3G and plans to
deploy IMS
No Yes. One Voice and
VoLTE initiatives
are
supportive.
No No
Operator
doesn’t have legacy 2/3G
and doesn’t
want to deploy IMS.
No No No Yes.
Inexpensive. No QoS
guarantee.
Operator has GAN
deployment
No Combination of VoLGA and SRVCC for service
continuity
Yes
Table 1: Possible alternatives based on the deployment
scenarios
V. CONCLUSIONS
The possible solutions for providing voice call while a user is in LTE are CS fallback, SRVCC, VoLGA and third party VoIP services like skype. For CS fallback the call is always initiated in 2/3G hence voice call continuity doesn’t apply and for skype calls, the call can’t continue if user moves to 2/3G. The solution for IMS based voice calls and VoLGA is to use SRVCC when user starts moving to 2/3G.
Based on the above analysis it is always possible for an operator to utilize third party services like skype for faster LTE deployment when it doesn’t plan to deploy IMS. This solution is quick and inexpensive but doesn’t guarantee QoS and voice call continuity. For operators who have legacy 2/3G network and do not intend to deploy IMS in future, CS fallback and
VoLGA are other alternatives which guarantee QoS. For operators which have 2/3G network but plan to deploy IMS eventually can use either CS fallback or VoLGA as intermediate solutions and use SRVCC later when IMS is deployed. For operators who are deploying IMS along with LTE the choice is simple i.e use SRVCC. For operators who have GAN deployments, enhancing the existing GAN controller for VANC and using VoLGA for voice solution is a feasible approach. The only problem is that VoLGA solution is not standardized in 3GPP.
Group Services and System Aspects; Generic Access Network (GAN)
[5] Technical Specification VoLGA Stage 2, Voice over LTE via Generic Acess
[6] www.gsmworld.com
[7] T-Mobile Introduces Unlimited Calling Over Wi-Fi With the National Launch of T-Mobile HotSpot @Home, Available: http://www.t-mobile.com/company/PressReleases_Article.aspx?assetName=Prs_Prs_20070627&title=T-Mobile%20Introduces%20Unlimited%20Calling%20Over%20Wi-Fi%20With%20the%20National%20Launch%20of%20T-Mobile%20HotSpot%20@Home
[8] “The One Voice Initiative “ Available: http://www.nokiasiemensnetworks.com/portfolio/products/convergedcore/onevoiceinitiative
![Network Configuration Example Deploying Secure Multicast ...€¦ · 172.16.2.0/24 172.16.21.0/24 172.16.31.0/24 172.17.2.0/24 [edit]](https://static.documents.pub/doc/80x56/608d306b6650eb33e0106229/network-configuration-example-deploying-secure-multicast-172162024-1721621024.jpg)
