SRVCC — Single Radio Voice Call Continuity in LTE 4G

Introduction

Single Radio Voice Call Continuity (SRVCC), defined in TS 23.216, is the procedure that keeps a live VoLTE call from dropping when the UE runs out of LTE coverage mid-conversation. It is an inter-RAT handover with an IMS twist: the voice leg, which exists as an IMS session on a packet bearer, has to be re-established as an old-fashioned circuit-switched (CS) call on 2G/3G, all while the two people talking keep talking.

SRVCC only ever applies to a call that is already in progress on VoLTE. That single fact separates it from CS Fallback (which acts before a call, when there is no VoLTE at all) and is worth holding onto, because the two are constantly confused. SRVCC assumes an IMS session exists and must be continued; CSFB assumes no IMS session exists and one must be set up on legacy CS.

Because SRVCC is a tightly ordered chain across the UE, eNB, MME, MSC Server, IMS anchor, and target legacy RAN, a failure or a long audio gap almost always traces to one specific step — the measurement that never fired, the SRVCC flag that was never set, the Sv request that timed out, the session transfer that round-tripped to the home network. Walking the steps in order is exactly how you turn "the call dropped when I left the building" into a specific, testable root cause.

Why SRVCC is needed

VoLTE voice is not a "call" in the old telephony sense — it is an IMS session whose media is RTP packets riding a dedicated packet-switched (PS) EPS bearer, the GBR bearer marked QCI 1. That works beautifully while you sit inside LTE coverage. But LTE has hard edges, and the deployed 2G/3G footprint frequently reaches further out. When you cross that edge mid-call, the only voice service the legacy network can offer is the classic circuit-switched (CS) call over UTRAN or GERAN. SRVCC is the procedure that lifts your in-progress IMS/PS voice leg and re-establishes it as a CS voice leg, without dropping the conversation.

What SRVCC Is

The word that carries all the weight is "single." In a dual-radio device you could imagine a soft make-before-break: bring up the CS leg while LTE is still healthy, then release LTE. A single-radio UE cannot do that, which is exactly why SRVCC exists as a tightly choreographed network procedure. The network must prepare the target CS resources and re-point the media in IMS before it finally commands the UE to retune, so that the instant the radio lands on 2G/3G, a fully formed voice path is waiting for it.

Everything downstream in this page is in service of that ordering constraint: the trigger has to fire while LTE is still just healthy enough to deliver a handover command; the Sv handshake and the IMS session transfer have to complete before the command is sent; and the audio gap the two talkers hear is exactly the window between the media re-point and the UE landing on the CS leg. Minimising that gap is the whole engineering story of enhanced SRVCC later on.

The Trigger — How the Network Decides to Move

Nothing happens until the radio starts to weaken. The eNB has configured the UE with inter-RAT measurements aimed at legacy neighbours, and gates them so the UE only bothers reporting when the serving LTE cell is genuinely in trouble. The classic configuration is event-driven: the UE fires a MeasurementReport when serving quality drops and a suitable inter-RAT neighbour appears.

The event that captures "my serving LTE cell became worse than a threshold and an inter-RAT neighbour became better than a threshold" is event B2. Many networks instead combine event A2 ("serving becomes worse than a threshold" — the hint to start hunting) with event B1 ("inter-RAT neighbour becomes better than a threshold") to get the same effect in two stages. Either way, the intent is identical: do not tear a UE off healthy LTE, but the moment LTE is failing and a legacy cell is strong enough to hold a CS call, report it.

When the report arrives, the eNB recognises that this UE has an active voice bearer — it can see the GBR QCI 1 bearer in the UE context. That is the crucial discriminator: an ordinary data-only UE at the LTE edge would get a plain inter-RAT PS handover (or simply be redirected), but a UE with QCI 1 up is on a voice call, and its voice cannot survive as PS on the legacy CS-only leg. So the eNB sends the S1AP Handover Required to the MME and sets the SRVCC handover indication in it. That flag is the whole point of the trigger stage: it tells the MME "this is not a normal handover — split the voice part off to the CS domain."

Reading the trigger in the logs

The trigger stage leaves two footprints: the RRC MeasurementReport that fired the event, and the S1AP Handover Required that carries the SRVCC indication. If you see the measurement report but no SRVCC-flagged Handover Required, the eNB either did not recognise the QCI 1 bearer or SRVCC is not enabled for this UE.

Representative eNB log — illustrative, values vary by vendor/build:

The Sv Interface and the MME Split

A VoLTE UE often has two things in flight: the voice media on QCI 1, and possibly other data (a download, messaging, background sync) on other bearers. SRVCC moves only the voice; the rest stays packet-switched if the target can carry it. So when the MME receives the SRVCC-flagged Handover Required, it splits the handover into two parallel jobs.

• The voice (CS) component. The MME initiates a CS handover toward the MSC Server over the Sv interface, sending a GTP-based Sv PS to CS Request. This carries the STN-SR and the subscriber's C-MSISDN (Correlation MSISDN), so the CS side and IMS can identify the subscriber and correlate the exact session being moved.
• The remaining data (PS) component. Any non-voice bearers are handed as an ordinary PS handover toward the target packet core (for 3G, toward the SGSN), so data continues where the target supports it.

The Sv interface is the dedicated reference point between the MME (in EPC) and the MSC Server (enhanced for SRVCC) in the CS core. It is the SRVCC-specific control channel and it exists for exactly this: to let a packet-core node ask a circuit-core node to prepare a CS handover for a call that is currently PS. It is emphatically not the same as the SGs interface used by CS Fallback — more on that distinction later.

The MSC Server is the coordinator on the CS side. On receiving PS to CS Request it does two things in parallel: it asks the target MSC/BSC/RNC to allocate CS radio resources (the "prepare handover" toward 2G/3G), and it triggers the IMS session transfer that actually moves the media path. Those two must both complete before the UE is told to jump.

Session Transfer, STN-SR and the ATCF/ATGW

Preparing CS radio resources is only half the job. The far end of the call — the person you are talking to — is still sending media toward your old IMS/PS access leg. Someone has to re-point that media stream to your new CS leg. That "someone" is IMS, and the trigger it responds to is the STN-SR (Session Transfer Number for Single Radio).

The MSC Server effectively places a call toward the STN-SR. IMS recognises that number as "a subscriber is arriving on the CS side; transfer their existing session there." Historically the anchor point that performs this re-pointing is the SCC AS (Service Centralization and Continuity Application Server) in the subscriber's home IMS. It correlates the incoming session-transfer request (matched via the C-MSISDN) with the ongoing call and swaps the remote party's media from the old access leg to the new CS access leg. The two ends never renegotiate the call — they just experience a brief media gap.

Anchoring in the home SCC AS can be slow when the user is roaming, because the session-transfer signalling has to travel back to the home network. To cut the media interruption, later releases introduced enhanced SRVCC (eSRVCC), which adds two functions in the serving (visited) network:

• ATCF (Access Transfer Control Function) — a control-plane anchor placed in the signalling path in the serving network. It anchors the session locally so the transfer can be executed close to the UE instead of round-tripping to the home SCC AS.
• ATGW (Access Transfer Gateway) — the media-plane anchor the ATCF controls. Because the media is already pinned at the ATGW, the transfer only re-points the UE-side leg between the ATGW and the access; the remote party’s media toward the ATGW is untouched, so the switch is far faster and the audio gap is much shorter.

The following table pins down who does what across the interfaces and anchors involved.

The SRVCC Handover Flow

Putting the pieces in order: the measurement report, the SRVCC-flagged request, the CS handover preparation over Sv, the IMS session transfer through the ATCF/SCC AS, and finally the handover command that retunes the single radio to 2G/3G. Read the diagram top to bottom — time runs down the page, and each horizontal arrow is one message.

Notice the ordering. The media transfer in IMS and the CS resource preparation both complete before the Sv PS to CS Response comes back and the handover command is finally sent. By the time the UE retunes, the remote party’s audio is already flowing to the CS side. The goal is that the two people talking hear at most a short gap.

Step-by-Step: Node and Interface

Every SRVCC step lives on a specific node and interface. This is the table worth memorising for interviews — it is the flow above rendered as a checklist.

Reading the whole SRVCC handover in the logs

End to end, the MME trace stitches the chain together: the SRVCC-flagged request in, the Sv handshake to the MSC Server, and the handover command out. The single most useful thing to measure is the elapsed time from PS to CS Request to Handover Command — that window bounds the audio gap the user hears.

Representative MME log — illustrative, values vary by vendor/build:

SRVCC vs CSFB, and the Reverse Direction

Both SRVCC and CS Fallback (CSFB) end with the UE getting voice from a 2G/3G circuit-switched network, which is why freshers mix them up. The difference is when they happen relative to the call, and it changes almost everything else.

There is also a reverse case. Once you are on the CS leg and later come back into LTE/VoLTE coverage, rSRVCC (reverse SRVCC) can hand the CS call back to a VoLTE/IMS session, restoring the packet-switched voice leg. Conceptually it mirrors SRVCC — the MSC Server and IMS anchor cooperate to transfer the session the other way — but it is used far less in practice, because the common deployment story is "LTE island shrinking, legacy blanket everywhere," so the pressing need is the outbound SRVCC direction.

Summary

SRVCC exists because a single-radio UE on a live VoLTE call cannot straddle two RATs: when LTE coverage fails mid-call, the IMS/PS voice leg must be actively handed over to a 2G/3G circuit-switched call before LTE is lost. The chain is fixed — a gated measurement (B2, or A2+B1) fires; the eNB, seeing the QCI 1 GBR bearer, sends an SRVCC-flagged Handover Required; the MME splits voice off over Sv to the MSC Server; IMS transfers the session via the STN-SR (correlated by C-MSISDN, sped up by the ATCF/ATGW); and only then does the UE get the command to retune.

To root-cause an SRVCC problem, walk that chain and find the first broken link. No SRVCC-flagged request? Look at the measurement config and the QCI 1 recognition. Request sent but no response? Look at Sv, the MSC Server, and CS resource preparation. A long audible gap? Look at whether eSRVCC anchoring is in place. Call drops right after retune? Look at the target CS cell. The single durable contrast to keep: SRVCC is Sv, during a call; CSFB is SGs, before a call.

Interview Quickfire