Description
Single Radio Voice Call Continuity (SRVCC) is a complex mobility procedure defined by 3GPP to maintain an active voice call when a User Equipment (UE) moves from a packet-switched (PS) LTE or 5G NR access network, which supports voice over IP (VoIP) via IMS (VoLTE/VoNR), to a legacy circuit-switched (CS) network like GERAN, UTRAN, or 1xRTT. The core challenge SRVCC addresses is that the UE has only a single radio transceiver, meaning it cannot simultaneously maintain the PS VoIP call on LTE and perform measurements or signaling on the target CS network. The procedure is orchestrated by the network, requiring tight coordination between the Evolved Packet Core (EPC) or 5G Core (5GC), the IMS, and the CS core network (MSC).
Architecturally, SRVCC introduces several key functional entities and reference points. In the EPC, the MME plays a central role. It receives measurement reports from the eNodeB indicating deteriorating LTE signal strength and the availability of a suitable CS target cell. The MME then initiates the SRVCC procedure by sending an SRVCC PS to CS Request message to the MSC Server (enhanced for SRVCC, often called an MSC Server enhanced for SRVCC or eMSC). This MSC Server interfaces with the IMS network via the Sv interface to the SRVCC Application Server (SRVCC AS) or the Service Centralization and Continuity Application Server (SCC AS) in the IMS. The SCC AS is the anchor point for the voice call session in IMS, enabling it to manipulate the media path.
During the handover execution, the MSC Server performs a CS handover procedure with the target BSS/RNS and establishes a CS bearer path. Concurrently, it signals the SCC AS via the Sv interface (or using ISUP/SIP interworking) to transfer the IMS leg of the call from the PS access to the newly established CS access. The SCC AS updates the remote end's media path to point to the CS network's Media Gateway (MGW). From the UE perspective, it receives a handover command from the LTE network, tunes its single radio to the target CS frequency/channel, and accesses the CS network, where it sends a handover complete message. The voice media is then seamlessly switched from the VoIP packet flow over LTE to the CS voice channel. For the calling party, this transition is nearly imperceptible, with only a very brief potential audio interruption.
SRVCC also encompasses variants like enhanced SRVCC (eSRVCC), introduced in 3GPP Release 10, which significantly reduces handover interruption time by anchoring the call locally in the serving network's MSC and IMS architecture, rather than involving the home network's SCC AS for the media update. Reverse SRVCC (rSRVCC) handles mobility from CS back to LTE/5G. In 5G systems, SRVCC principles are extended for handover from 5G NR (VoNR) to EPS (VoLTE) or to UTRAN/GERAN, with the AMF and N26 interface (when present) playing roles analogous to the MME and Sv interface.
Purpose & Motivation
SRVCC was created to solve a critical business and technical problem during the initial rollout of 4G LTE networks. LTE was designed as a pure packet-switched (PS) network, optimized for high-speed data, with no native circuit-switched (CS) domain for voice telephony. The industry's solution for voice over LTE was to use Voice over IP (VoIP) via the IP Multimedia Subsystem (IMS), known as VoLTE. However, LTE coverage was not ubiquitous at launch and often lagged behind the extensive 2G and 3G CS coverage. Without a continuity mechanism, a VoLTE call would simply drop when a user moved out of LTE coverage, leading to a poor user experience that was unacceptable for a primary telephony service.
The primary motivation was to enable mobile operators to deploy LTE as a data-optimized network while leveraging their existing, widespread CS networks for voice service continuity. This allowed for a phased migration strategy. Operators could launch LTE for high-speed data and VoLTE in dense urban areas, while relying on SRVCC to provide seamless voice service in suburban and rural areas still covered only by 2G/3G. It protected the operator's substantial investment in CS infrastructure and spectrum, while meeting customer expectations for reliable, uninterrupted voice calls.
Prior to SRVCC, dual-radio devices could use Circuit Switched Fallback (CSFB) to place or receive calls by temporarily falling back to a 2G/3G network, but this was not suitable for handover of an active call. SRVCC specifically addressed the active call continuity scenario for single-radio devices, which are the norm due to cost and complexity. It was a foundational enabler for the commercial success of VoLTE, as it guaranteed that the voice service quality and reliability on LTE would be at least as good as on legacy networks, thereby removing a major barrier to LTE adoption for voice.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (40 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the SRVCC function was enhanced to support IMS emergency sessions initiated in their early dialogue phases, specifically during pre-alerting and alerting. This release also introduced clarifications for enabling SRVCC during mobility from 5GS to EPS and for the usage of the pre-alerting SRVCC feature tag. Furthermore, procedures were defined for handling SRVCC handover failures for emergency calls and for Secondary RAT Usage Data Reporting related to SRVCC.
- PS to CS SRVCC for IMS emergency session in early dialogue phase TS 23.237CR0504
- PS to CS SRVCC for emergency session in alerting or pre-alerting phase TS 24.237CR1271
- SRVCC HO failure for Emergency handling TS 23.216CR0344
- Secondary RAT Usage Data Reporting for SRVCC TS 23.216CR0346
- Clarification on the enabling SRVCC during 5GS to EPS connected mode mobility TS 23.216CR0348
- Clarification on basic voice support TS 38.300CR0095
+ 2 more changes
In Release 16, the SRVCC function was extended to introduce 5G-SRVCC, enabling voice call continuity from NG-RAN to legacy networks like UTRAN, including for emergency sessions. The release also enhanced robustness by introducing support for multiple EATF instances in Emergency SRVCC procedures. Furthermore, it addressed deployments without IMS-level roaming interfaces and included clarifications and corrections for ciphering and procedure behavior during these handovers.
- Adding 5G SRVCC description to scope and definition to 23.216 TS 23.216CR0352
- 5G-SRVCC procedure TS 23.216CR0354
- Introduction of support of multiple EATF instances in Emergency SRVCC procedures TS 23.237CR0509
- SRVCC in deployments without IMS-level roaming interfaces TS 24.237CR1285
- Introduction of 5G SRVCC TS 24.237CR1292
- Further introduce support for 5G-SRVCC TS 24.237CR1296
+ 17 more changes
In Release 17, SRVCC enhancements included defining procedures for when an SRVCC handover is cancelled, requiring an IMS session re-establishment indicator via NG-RAN, and specifying failure cases for SRVCC from NR to UTRAN. The release also addressed the missing `g.3gpp.srvcc-alerting` media feature tag in signaling flows and defined AMF interaction with the GMLC for SRVCC during an emergency session.
- SRVCC handover cancelled, IMS session re-establishment required indicator via NG-RAN TS 24.237CR1303
- Failure cases for SRVCC from NR to UTRAN TS 23.216CR0373
- g.3gpp.srvcc-alerting media feature tag missing in flows TS 24.237CR1304
- Avoid linkage between security functions and UE Radio Access Capabilities TS 33.401CR0708
- MBS corrections for multicast configuration and service continuity TS 38.300CR0613
- AMF interaction with GMLC at SRVCC for an Emergency session TS 23.216CR0374
In Release 18, SRVCC was enhanced to support the IMS Data Channel, enabling the continuity of an IMS emergency session that includes media other than voice, such as video or session-mode text. This allows for SRVCC procedures to be applied when an emergency session contains additional media components alongside or instead of voice. The update ensures session continuity for these multimedia emergency calls during access transfer from E-UTRAN or NG-RAN to a CS network.
In Release 19, the SRVCC function was enhanced to include the transfer of emergency sessions containing media other than voice, such as video or text, to a CS voice channel when handing over to a legacy network. The specification clarified procedures for when a PSAP supporting voice and other media adds new media during an ongoing IMS emergency session. Furthermore, it detailed domain selection rules for emergency session attempts, ensuring continuity for sessions initiated in either the PS or CS domain for UTRAN, E-UTRAN, and NG-RAN accesses.
- Clarification of the single SCS per frequency restriction TS 38.300CR1053
Explore further
Broader topics and technologies where SRVCC plays a role.
Defining Specifications
3GPP specifications that define or reference SRVCC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.167 vj11 | IMS Emergency Sessions | Rel-19 |
| TS 23.216 vj00 | SRVCC Architecture Enhancements | Rel-19 |
| TS 23.237 vj00 | IMS Service Continuity (ISC) Stage 2 | Rel-19 |
| TS 23.272 vj10 | CS Fallback in EPS | Rel-19 |
| TS 23.334 vj00 | IMS-ALG to IMS-AGW Interface (Iq) Stage 2 | Rel-19 |
| TS 23.885 vb00 | SRVCC Feasibility Study for Reverse Handover | Rel-11 |
| TS 23.886 va00 | Feasibility Study on Video SRVCC | Rel-10 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 24.237 vj00 | IMS Service Continuity Protocol Details | Rel-19 |
| TS 24.802 vc10 | IMS II-NNI Traversal Scenario Determination Study | Rel-12 |
| TS 25.300 vj00 | UTRA Radio Interface Enhancements Overview | Rel-19 |
| TS 25.306 vj00 | UE Radio Access Capabilities Specification | Rel-19 |
| TS 25.413 vj00 | Radio Access Network Application Part (RANAP) | Rel-19 |
| TS 26.114 vj10 | IMS Multimedia Telephony Media Handling | Rel-19 |
| TR 26.919 vj00 | Study on 5G Conversational Media Handling | Rel-19 |
| TR 26.954 vj00 | UE Headset Electrical Interface Testing | Rel-19 |
| TS 29.165 vj10 | Inter-IMS Network to Network Interface (NNI) | Rel-19 |
| TS 29.238 vj00 | H.248 Profile for IBCF-TrGW Interface | Rel-19 |
| TS 29.277 vj00 | S102 Interface Protocol Specification | Rel-19 |
| TS 29.334 vj00 | IMS-ALG to IMS-AGW Interface Protocol | Rel-19 |
| TS 29.806 vc10 | P-CSCF Restoration Analysis & Solutions | Rel-12 |
| TR 29.949 vj00 | VoLTE IMS Roaming Architecture & Procedures | Rel-19 |
| TS 32.250 vj00 | Circuit Switched Offline Charging | Rel-19 |
| TS 33.102 vj10 | 3G Security Architecture Specification | Rel-19 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TS 33.838 vb00 | Study on Protection against Unsolicited Communication for IMS | Rel-11 |
| TS 33.856 vg10 | Security for 5G to 3G Voice Continuity | Rel-16 |
| TS 38.300 vj00 | NG-RAN Overall Description | Rel-19 |