Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
Part-4: What happens when a user performs a voice call from an LTE/4G network? - SRVCC
December 02, 2016 | By Leonardo Zanoni Pedrini @ Telefônica
Online viewer:
Comments (10)

We are pleased to share with you all an interesting article contributed by Leonardo Zanoni Pedrini.


Leonardo Zanoni Pedrini
Telecom Consultant at Telefônica Brasil (Telefônica | Vivo)



All Articles by Leonardo Zanoni Pedrini

  How to contribute your article to Netmanias.com !  
  List of Contributors  



4. SRVCC - Single Radio Voice Call Continuity

Finally, we come to our last alternative listed at the beginning of this SRVCC (Single Radio Voice Call Continuity).


The SRVCC however is not an alternative for delivery, but a rather a handover process of a voice call previously started in the LTE (whether One Voice - VoLTE LTE or IMS Full Voice).


It is a call transfer method (handover), in a simplified and reliably way, when an LTE user has an active voice session in IMS and is moving to areas without LTE coverage, but with legacy 2G/3G coverage.


The main advantage is that the call will not drop - will only be transferred to the CS domain of the legacy networks.


If in the above case the UE moves out of LTE coverage area with an active call (but goes to legacy 2G/3G coverage), we must maintain the continuity of this active voice call. In this case, the SRVCC is used: the procedure where the context of an active voice call on the IMS is transferred to the CS legacy network (e.g. IMS node context transfer to the MSC).





The challenge with SRVCC is to perform the handover while the UE is connected to only a single radio at any given moment.


There are two versions of SRVCC:

  • SRVCC handover to GSM or UMTS, defined by 3GPP;
  • SRVCC Handover to 1xRTT networks defined by the 3GPP2.


To allow SRVCC both the UE and LTE networks, as also the legacy, must support SRVCC. For this, a new special SV interface is introduced between the MME and the MSC, which runs on GTPv2 protocol.





To support SRVCC, the IMS network should also include an application server, called SCC AS (Server Centralization and Continuity Application Server).


This application server is who manages the signaling required for the process.


Let's see a simplified example of some SRVCC procedures from LTE to GSM.

  • When an UE that supports VoLTE is in an LTE coverage area, it starts voice sessions via the IMS network, which will host the session and provide applications and session control based on SIP.
  • When the UE moves from an LTE coverage area for a CS 2G/3G coverage area, with the active IMS session, the IMS switches the session to the CS domain, maintaining both parts aware of the handover session.


4.1. Example of SRVCC Handover


Realizing that its LTE signal level begins to decrease, the UE with an active IMS voice session signals it to the eNodeB, initiating the SRVCC handover.


The eNodeB then identifies the best available network to receive the service, and sends the handover request (specifying that it is the SRVCC type) to the MME.


The new voice call request is then sent to the IMS, using a SR STN (Session Transfer Number for SRVCC) - a unique number that is generated by each UE, and is stored in HSS.


This unique number is sent by the MME to the HSS when the UE first comes into contact with the network.


Upon receiving the STN SR number, the SCC AS believes that the corresponding call should be transferred to a different network, and starts the redirecting process for the transfer point (handover) to the legacy network.


After resource preparation is completed, the MME confirms the handover request, previously provided by the eNodeB.


The eNodeB then transmits this acknowledgment to the UE, while still providing the required information about the target network.


In the final stages, the UE is detected in legacy networks, and the call is re-established in it.


Thus we have the completion of the SRVCC handover.


Voice packets and also packets that are not voice can be transferred using this method, but the data rates will be limited by the capabilities of the legacy networks.


Once the SRVCC is a procedure for inter-RAT handover based on IMS LTE network to the CS legacy network 2G/3G, it is much more complex than that of handovers legacy networks 3G / 2G. The question is how to maintain a handover performance comparable to or better acceptable.


In order to improve the performance of the SRVCC handover, one WI (Work Item) called eSRVCC (SRVCC enhancement) was established in the 3GPP SA2 in Release 10. The anchoring solution is based on the IMS, and introduces new entities ATCF (Transfer Control Access Function) and ATGW (Transfer Access Gateway).


Again, the deepening of this subject escapes from our goal.


Finally, we will enumerate some of the main advantages and disadvantages (or pros and cons) of each alternative.



5.  Advantages and disadvantages of each alternative

Call setup time: When operators use CSFB, one of the biggest problems faced (and one of the major disadvantages of CSFB) is the increase in call setup time due to retuning procedures in 2G/3G radios.


An efficient CSFB solution requires the TAC -> LAC mapping is so that the fallback to an external MSC/LAC be avoided, since this will further increase the call setup time.


Call quality: call quality in LTE is better when compared with the same third-party applications (OTT). This is due to specific QoS allocated to the call IMS, which may not be present in common data applications.


Resource limitations for VoLTE: AMR-NW LTE requires much less resources and data rate than GSM, and we will have many more users on the same bandwidth (spectral efficiency).


Investment x Current Network: if everything is 'working well', what would be the reason for investment, since surely such investments generate resistance from commercial and business areas?


The comparison that must be done is: Investment versus (all) Benefits of IMS/MGW/BGCF.


Future: In any way all that discussion hereafter will more significance. Currently we still have extensive legacy networks, capable of supporting these voice calls.


In this case, it is no problem to continue using this available infrastructure. Resistance will only decrease when such capacity also decrease. But in an LTE network, if the IMS is supported can make a VoIP call. So why would we need to make a CS voice call?



  • It is not necessary to implement both solutions (CSFB and SRVCC) at the same time, if the network has a wide LTE coverage and a complete IMS backbone.
  • If we implement CSFB, it means we will not make the call setup using existing IMS Core, and that could take care of that call in LTE.
  • In respect to the SRVCC: assuming the Backbone IMS is available. In this case, if the register in the IMS is successful, the users do not need to do CSFB - A voice call can be simply initiated in LTE network using IMS.
  • CSFB is a service handover procedure while SRVCC is a coverage handover procedure.


6. Case Studies and Analogies


With all that we have seen, let's imagine some scenarios.


First, imagine that you are in a network that does not have LTE IMS. Then the only way to make a voice call, whether originated or terminated, is through using legacy 2G/3G.


You need to be redirected /released from LTE to legacy 2G/3G network to make a voice call. Like a 'reselection' from cell LTE to the 2G/3G. Once the legacy network, you can make the call normally, as you're already used to.


And so, you just saw the CSFB in practice!


Now suppose you are watching a video stream on 4G network, and receive a voice call. In this case, you need to go to the 3G network (in idle mode), and get the resources for to make that call in 3G.


After you end your voice call, you keep watching the video stream, but now in the 3G network (the handover from 3G to 4G is not yet defined).


You just saw the CSFB with an active data call!


Now let's imagine that you are in another LTE network, this time with IMS. In this case, you can make a voice call using IP packets.


We have just seen a VoLTE call!


Further, imagine that you are in one of these voice calls using packets in 4G. Suppose further you reach your 4G cell coverage edge. So the only option to keep your call is to handover it to the 3G (assuming this is the existing coverage). Your call will then continue on the 3G network, but now as one CS voice call. SRVCC!


If the SRVCC is not supported, the call is dropped as soon as it leaves the LTE coverage area.


If the SRVCC is supported, a set of messages are exchanged, and the voice call is transferred (handover) from LTE IMS to CS domain of the 2G/3G network.


And so, we have just seen an example of SRVCC handover!


I hope this information has managed to be useful for you that somehow are interested voice in LTE networks.



7. Conclusion

We saw in this in a very general way, the main ways to make voice calls (and SMS) in LTE networks.


The options or alternatives depend on several factors, such as available network topology and the operator's strategy.


Depending on the situation, the call can be originated in LTE via data applications (OTT VoIP), be purely originated on LTE IMS (VoLTE), sent to be performed on other networks through mechanisms developed for this purpose (CSFB) or transferred via handover - if active VoLTE call - to a legacy network (SRVCC).


So, for a user who is a LTE coverage area, a number of considerations should be checked, as the type of device that it uses (whether supports CSFB), if the LTE network has an IMS that allows outgoing calls, if the cells supports SRVCC, etc.


Based on the concepts seen here, I hope you have a position to fully understand what happens when a user performs a voice call from an LTE network.






lai 2016-12-22 17:32:38

Dear Expert,

One interesting question, after SRVCC, what is the call type? CS call , PS call, SIP call?

vinitshandilya@outlook.com 2017-01-13 01:32:53

After SRVCC, the SCC-AS will store the ADS as CS domain and the eMSC will terminate the call. However, the call control logic will still be executed in the IMS domain. So, this will be a SIP call. All B-number routing and breakout to other networks (if required) will occur in IMS.

vinitshandilya@outlook.com 2017-01-13 01:28:33

Nice article! One question though. In the network architecture shown above, why is the Sv interface shown connected from SCC-AS to MSC-S? Shouldn't it be from MME to MSC-S (for SRVCC procedures)?

trungdd2 2017-02-14 17:27:45

Excelent. Clear to understand. Thank you indeed.

Ravish 2017-02-15 02:38:23

Good one, Clear understanding.

IDDI SELEMANI 2018-10-22 21:53:15

Very nice and clear article..Well understood. Thanks for sharing.

MiranSturm 2018-12-14 02:10:14

One question.

Let's assume that after SRVCC (done by MSC-S enhanced for ICS, but has no GSM radio access) and call termination, the user stays in GSM area.

My question is, how the IMS registration shall be done, if the user (with non-ICS terminal) performed LUP in non-ICS MSC/VLR and wants to be still registered in IMS (indicating that he is in CS domain) and using the IMS services?

eirene 2019-03-29 05:43:47

When making a call I have 3 active carriers, 1 default for data, 1 default for ims and 1 dedicated for the call.

When the molvil makes srvcc, it makes handover of two bearer by default but not of the dedicated bearer.

What happens with the bearer default when it arrives at the SGSN, is still active or has to be canceled????

shiveshkims 2020-05-05 21:37:56


Where we can find the complete detail and call flow of eSRVCC?

Anamitra 2020-05-20 19:34:55


We notice S10 and S8 have different SRVCC call for the same drive route and time .S10 has higher number of SRVCC call ratio than S8 , how can this be explained?

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.

[HFR Private 5G: my5G]


Details >>







Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file







View All (858)
4.5G (1) 5G (102) AI (8) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (56) KT (43) Korea (20) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (11) QoS (3) RCS (4) Railway (1) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.