LTE Voice Options (VoLTE, CSFB, SRVCC)

Introduction

LTE voice "options" are the three mechanisms — VoLTE, CSFB and SRVCC — that let an LTE subscriber make and keep a phone call even though the Evolved Packet System has no circuit-switched domain of its own. They are not competing features so much as three answers to one problem: how to deliver a conversational voice service on a network designed only for IP packets.

They enter the picture at different moments in the call lifecycle. VoLTE is used at call setup when the network has an IMS core and good coverage. CSFB is used at call setup when it does not, moving the UE to 2G/3G for the call. SRVCC is used mid-call, only after a VoLTE call already exists, to rescue it when LTE coverage runs out. Which one applies is driven by what the operator has deployed and by an explicit NAS indication the network sends during attach.

Why it matters: whether a call connects, how fast it sets up, and whether it survives the walk out of an LTE cell all depend on which option is in play and whether its prerequisites — IMS, the SGs interface, the Sv interface, a combined attach — are actually in place. Getting the decision tree straight turns a confusing list of acronyms into one clear model of how LTE voice works and how it migrates over time.

Why LTE Needs Voice "Options" at All

In 2G and 3G, voice rode a dedicated circuit-switched domain. The MSC set up an end-to-end circuit, reserved a fixed 64 kbit/s timeslot, and speech flowed over it for the whole call. LTE deliberately threw that model away. The Evolved Packet System defined in TS 23.401 is entirely packet-switched: there is no MSC, no CS bearer, no circuit inside LTE to place a call on. Everything — web traffic, video, and voice alike — is an IP packet riding an EPS bearer between the UE and the P-GW.

That is liberating for data and awkward for voice. A phone call is not just "some packets"; it is a low-latency, low-jitter, tightly bounded conversational flow that users judge harshly. So to deliver voice to an LTE UE you have exactly two families of answers. Either you carry the voice as packets over LTE itself using the IP Multimedia Subsystem (that is VoLTE), or you move the UE away from LTE to a radio access that still owns a circuit-switched domain (that is CSFB). A third mechanism, SRVCC, is not a way to start a call at all — it only matters once a VoLTE call already exists and LTE coverage is about to vanish underneath it.

Which option a given UE actually uses is not arbitrary. It is decided by what the network has deployed, what the UE is capable of, and an explicit indication the network sends during attach — the IMS Voice over PS support flag, covered later on this page. Get that mental model straight and the three options stop being a confusing list and become one decision tree.

VoLTE — Native Voice as Packets over IMS

VoLTE (Voice over LTE) is the target solution, and every other option on this page exists only to work around its absence. In VoLTE the entire call — both the signalling and the speech — is carried as IP packets over LTE, using the IP Multimedia Subsystem (IMS) with the Multimedia Telephony (MMTEL) service layered on top. The UE never leaves LTE, keeps its data session live throughout, and gets the best possible voice quality because the media stays on the fast, low-latency LTE air interface.

The two-bearer split is the single most important VoLTE detail and a perennial interview target. SIP is bursty, delay-tolerant control traffic, so it gets a non-GBR bearer at QCI=5 that is set up when the UE registers with IMS and stays up for the life of the IMS session. The voice media is a steady, delay-sensitive stream, so it gets its own GBR bearer at QCI=1 with a reserved bit rate, created only when there is an active call to carry. Standardised QCI characteristics live in TS 23.401.

The default (non-GBR) bearer used for ordinary internet data typically sits at QCI=9 (or QCI=8), which is why a VoLTE-capable UE ends up with a distinct bearer per traffic class: QCI=9 for data, QCI=5 for IMS SIP, and QCI=1 for the speech. The QCI=1 bearer is the only guaranteed-bit-rate one of the three, which is exactly what protects the conversation from congestion on the shared cell.

The catch is exactly the one VoNR faces in 5G: VoLTE needs the full stack ready end to end and good enough LTE coverage to sustain a GBR voice bearer without dropping packets. Where IMS is not yet deployed, or where the network operator has not enabled it, VoLTE is simply not on the table and the network must use CSFB instead. And where VoLTE is running but the UE walks past the edge of LTE, SRVCC is what stops the call from dropping. Those are the next two sections.

CSFB — Fall Back to 2G/3G for the Call

CSFB (Circuit-Switched Fallback), specified in TS 23.272, is the classic interim answer for networks that do not yet have VoLTE/IMS. The idea is blunt: the UE does its data on LTE, but the instant a voice call needs to be set up, the network moves the UE down to 2G/3G — which still has a real circuit-switched domain — and the call runs there as an ordinary CS call. There is no voice on LTE in a CSFB network at all; LTE is used only for data and to trigger the drop.

The trigger sequence is a favourite exam question, so it is worth memorising as four steps:

1. At power-on the UE does a combined EPS/IMSI attach; the MME registers it with the MSC over the SGs interface, so the CS domain always knows which tracking area the UE is in.
2. For a mobile-terminated call the MSC sends an SGsAP-PAGING-REQUEST to the MME, which pages the UE on LTE; the UE replies with an Extended Service Request carrying the CS fallback indicator. (A mobile-originated call skips paging — the UE just sends the Extended Service Request directly.)
3. The eNB moves the UE to GERAN/UTRAN — either an inter-RAT handover (smoother, uses UE measurements, keeps the PS session via PS handover) or RRCConnectionRelease with redirection (faster to issue, but the UE must re-acquire and re-connect on the target).
4. On 2G/3G the UE completes the call as a normal circuit-switched call; when it ends, the UE returns to LTE by reselection or fast return.

SRVCC — Keep a VoLTE Call Alive When LTE Runs Out

SRVCC (Single Radio Voice Call Continuity), defined in TS 23.216, solves a completely different problem from CSFB, and conflating the two is the most common mistake. In SRVCC the call is already a live VoLTE/IMS call running on LTE, and the UE is about to leave LTE coverage — typically because VoLTE coverage is a smaller footprint than legacy 2G/3G. Without intervention the packet call would simply drop as the LTE radio link fails. SRVCC hands the in-progress packet voice call over to a 2G/3G circuit-switched leg so the conversation continues without interruption.

Two subtleties are worth carrying into an interview. First, SRVCC needs the enhanced MSC Server and the Sv interface (MME ↔ MSC-S) — a plain legacy MSC will not do, because the transfer has to be anchored and coordinated with IMS session continuity. Second, the reason "single radio" matters at all is battery and cost: earlier dual-radio VCC schemes needed the UE to run two radios at once, which SRVCC explicitly avoids by making the network do the switch while the UE keeps just one transmitter active.

IMS session continuity across the switch is what actually stops the media from dropping, and it hinges on the call being anchored in IMS before the transfer. Modern deployments place the ATCF (Access Transfer Control Function) and ATGW (Access Transfer Gateway) in the media path so that, at the moment of SRVCC, only the access leg is redirected while the far end and the IMS anchor stay put — giving a faster, more reliable transfer than re-anchoring the whole session. The UE signals its SRVCC capability so the network knows the option is available.

The key contrast to memorise: CSFB moves the UE before the call starts — there is no LTE voice call yet because the network has no VoLTE — whereas SRVCC moves a call that is already running on VoLTE. Put differently, CSFB is what a network without VoLTE does for every call; SRVCC is what a network with VoLTE does only when a call is about to fall off the edge of LTE coverage. The dedicated SRVCC page walks the full handover signalling.

Prerequisites — What Each Option Demands

None of these options is free; each requires specific network elements, interfaces, and NAS procedures to be in place before it can work. Laying the prerequisites side by side is the quickest way to see why operators cannot simply "turn on VoLTE" overnight, and why CSFB was the pragmatic first step for almost everyone.

Beyond call setup, there is a second prerequisite thread that trips people up: the network must tell the UE, explicitly, whether packet voice is even available, and it must have a plan for SMS. Both are handled by NAS-level indications and by choosing an SMS transport.

The IMS Voice over PS indication (commonly the IMS VoPS flag inside the EPS network feature support IE) is sent to the UE in the Attach Accept and TAU Accept. If it says voice over PS is supported in the current tracking area, the UE knows it may attempt VoLTE; if it says not supported, a voice-capable UE knows it must rely on CSFB instead. This is what lets the UE make the VoLTE-versus-CSFB decision per registration area, rather than guessing.

SMS is the other loose end, because a text message historically also rode the CS domain. There are two answers, and which one a network uses tracks its migration stage:

The Operator Migration Path

The three options are not competing products an operator picks between forever — they are stages on a road. Reading them as a timeline explains why almost every operator deployed them in the same order, and why CSFB and SRVCC are gradually being switched off.

Stage 1 — LTE data, CSFB voice. When LTE first launched there was no IMS core and coverage was patchy. Operators lit up LTE for its headline data speeds and pointed all voice at the existing, trusted 2G/3G circuit via CSFB, with SMS over SGs for texts. This got LTE handsets to market quickly with zero risk to the voice service, at the cost of slower call setup and a brief data interruption on every call.

Stage 2 — VoLTE plus SRVCC. As the IMS/MMTEL core was deployed and LTE coverage densified, operators enabled VoLTE so voice finally rode LTE natively. But because VoLTE coverage still had holes, they simultaneously turned on SRVCC so that a VoLTE call reaching the coverage edge could be handed to the 2G/3G circuit instead of dropping. In this stage the network signals IMS VoPS "supported" where VoLTE is available and falls back to CSFB only where it is not.

Stage 3 — VoLTE everywhere, legacy sunset. Once VoLTE coverage matches the legacy footprint and SMS over IP is in place, the CS domain is no longer needed. Operators refarm 2G/3G spectrum for LTE/NR, and the need for both CSFB and SRVCC fades — there is no longer anywhere to fall back to, nor any coverage gap to bridge. This is also why 5G, which never had a CS domain to begin with, uses EPS Fallback to VoLTE rather than any true circuit fallback.

Comparing the Three Options

The three options answer different questions, so the cleanest way to hold them in your head is a single table plus a decision tree. Start with the comparison across the four axes that matter — where the voice actually runs, what it requires, the resulting quality, and when the network uses it.

How does the UE know which of these to expect? During attach the network signals the IMS Voice over PS support indication (the IMS VoPS flag in the EPS network feature support IE) in the Attach Accept / TAU Accept. If it says voice over PS is supported, the UE knows it can attempt VoLTE; if not, and the UE has voice capability, it uses CSFB. Combined with the UE's own configured voice domain preference, this fixes which option is used per registration. The decision tree below folds all three options together.

Summary

LTE has no circuit-switched domain, so voice has to be reconstructed — and the three options are the three honest ways to do it. VoLTE carries the call as IMS packets natively on LTE, splitting SIP signalling onto a non-GBR QCI=5 bearer and the voice media onto a guaranteed QCI=1 bearer; it is the target end-state and the default whenever the IMS core and coverage allow. CSFB is the pre-VoLTE workaround that moves the UE to a 2G/3G circuit at call setup, needing the SGs interface and a combined EPS/IMSI attach. SRVCC is the mid-call rescue that hands an already-running VoLTE call to a circuit at the coverage edge, needing an SRVCC-capable MSC-S and the Sv interface.

The cleanest mental test is timing and starting point: CSFB acts before the call and there is no LTE voice call at all; SRVCC acts during a call that is already VoLTE. The IMS VoPS indication in the Attach/TAU Accept, plus the UE's voice-domain preference, decides VoLTE versus CSFB per registration area. Read as a migration timeline — CSFB first, then VoLTE+SRVCC, then VoLTE everywhere with the CS domain retired — the whole set falls into place, and its 5G echo (VoNR with EPS Fallback) follows the same logic.

Quick Q&A