Tuesday, September 7, 2010

Single Radio Voice Call Continuity (SRVCC)

SRVCC is an LTE functionality that allows a VoIP/IMS call in the LTE packet domain to be moved to a legacy voice domain (GSM/UMTS or CDMA 1x).

Consider a case where a new LTE network operator wants to move voice services to VoIP over IMS in conjunction with the deployment of an LTE access network. In the absence of other options, this operator would need to provide ubiquitous LTE coverage on day 1 to have a competitive VoIP service. However SRVCC enabled LTE may not require complete LTE coverage.

SRVCC provides the ability to transition a voice call from the VoIP/IMS packet domain to the legacy circuit domain. Variations of SRVCC are being standardized to support both GSM/UMTS and CDMA 1x circuit domains. For an operator with a legacy cellular network who wishes to deploy IMS/VoIP-based voice services in conjunction with the rollout of an LTE network, SRVCC offers VoIP subscribers with coverage over a much larger area than would typically be available during the rollout of a new network.

SRVCC functions as follows. As an SRVCC-capable UEe engaged in a voice call determines that it is moving away from LTE coverage, it notifies the LTE network. The LTE network determines that the voice call needs to be moved to the legacy circuit domain. It notifies the MSC server of the need to switch the voice call from the packet to the circuit domain and initiates a handover of the LTE voice bearer to the circuit network. The MSC server establishes a bearer path for the mobile in the legacy network and notifies the IMS core that the mobile’s call leg is moving from the packet to the circuit domain. The circuit-packet function in the IMS core then performs the necessary inter-working functions. When the mobile arrives on-channel in the legacy network, it switches its internal voice processing from VoIP to legacy-circuit voice, and the call continues.


If the legacy circuit network also has an associated packet capability and is capable of supporting concurrent circuit/packet operations, the subscriber’s data sessions can be handed over to the legacy network in conjunction with switching the voice call from the packet to the circuit domain. In this case when the voice call finishes and the mobile re-enters LTE coverage, these packet sessions can be handed back to the LTE.

If operators look to limit LTE deployments to high traffic areas and at the same time wish to transition voice service in those areas to VoIP, then SRVCC is exactly what they need.

If on the other hand operators do not plan to migrate their voice service to VoIP, then SRVCC is not for them. If an operator does plan to migrate to VoIP and also plans to roll out ubiquitous LTE coverage, then the question of whether or not to adopt SRVCC is more complicated. While SRVCC does not require modifications to what is certainly the operator’s largest legacy investment, the RAN, it does require a significant modification of the operator’s legacy core and also requires full deployment of IMS circuit-packet continuity services. Given the cost of these changes, deployment of SRVCC purely as an interim measure to allow early rollout of VoIP-based services may not make financial sense.

Source: Motorola's WhitePaper on "LTE Inter-technology Mobility"

13 comments:

Mahesh said...

Why not the same PS call(IMS) will not do a HO to UTRAN as a general PS handover. In that case what is the use of SRVCC.

Samarth said...

Here, in SRVCC, we are talking about the scenario where UE is moved out of LTE coverage area. Since, there is no LTE coverage, PS calls for voice(VOIP,using IMS)is not possible.So, we have to fallback to enhanced MSC for voice using SRVCC(Using CS domain).

Samarth said...

follow up if you have any further queries...

Kirn Gill said...

Except that the classic UTRAN supports packet sessions. HSPA and it's evolution, HSPA+, can in practice provide low enough RAN latency to allow packet-switched voice service to be handed over to a HSPA or HSPA+ data session. There is no real reason to fall back to CS unless there is real concern that the legacy RAN's PS performance is just that bad.

Bandwidth isn't a concern with a HSPA-enabled UTRAN. A VoLTE PS call only needs ISDN bandwidth (64kbit/s full duplex) + IP packet header overhead (about an additional 20%), which could be reduced significantly by using the legacy AMR or GSM-EFR voice codecs - which may even enable PS voice sessions to persist over a GERAN/ERAN, if the latency isn't too great. IMS is based on SIP and RTP, and I've have numerous successful and usable, jitter-free SIP/RTP calls over GPRS/EDGE using the AMR codec - there is no reason to believe that a VoLTE call using the right codec could not fall back to the PS domain of UTRAN or GERAN and still deliver adequate end-user performance.

Utkarsh Kumar said...

Functionally, for an end user... there is no difference between CSFV and SRVCC.. correct ?

Saikiran V said...

Have a query, suppose the UE and EPC supports SRVCC, is it mandatory for UE to do combined attach or is it fine for UE to do EPS only attach and can still do SRVCC

Samarth said...

Eps attach only...combined attached is for csfb

Samarth said...

Yes probably...

Adesh Kumar said...

I agree with Kirn Gill. Why isn't a PS handover of the VOIP PS Bearer be done to UMTS/GERAN instead of the SRVCC (PS Bearer handed over to CS Bearer)

kiran prabhakar koona said...

so in case of SRVCC if it is a EPS attach only, how does UE know about the neighbour 2G/3G network? is it just from the SIB's sent by EPC? When the LTE coverage is bad and UE has to switch from LTE to CS network is it a fresh registration to the CS network?

akshay said...

SRVCC is possible only when UE is in CS/PS modes of operation as in PS only modes, MSC will never come into picture. In both these cases the specification states that combined attach is performed. Hence we can conclude that combined attach is performed.

Tomek said...

Hi,

During INITIAL ATTACH in LTE UE has to indicate that is capable of SRVCC and request COMBINED EPS/ IMSI ATTACH

In case of ATTACH ACCEPT network need to accept COMBINED EPS/ IMSI ATTACH and should indicate whether voice over IMS is supported or not:


IMSVoPS = (IMS Vo PS Session in S1 Mode supported)


Regarding neighbours:

The UE shall support measuring UTRAN/ GERAN carriers in the RRC connected state.

Network is telling UE which cell should be measure by measurement request/config in RRC RECONFIGURATION MESSAGE


TROMEK

Henry De Dios said...

The difference between CSFB and SRVCC is that CSFB take place when an UE places or receives a new call. SRVCC is a mechanism used to transfer (handover) an active, already in place, voice call from a VoLTE scenario to a CS scenario.