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?

CSFB v/s SRVCC:

• 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.