C-MSISDN

Correlation Mobile Station International Subscriber Directory Number

Identifier →
Introduced in Rel-8 Also in: Services

C-MSISDN is a temporary MSISDN assigned to a UE during a VCC session to correlate the CS and IMS legs of a call, enabling seamless handover and continuity between these domains.

Category
Identifier
Introduced
Rel-8
Where
Core Network › Evolved Packet Core
Also touches
1 segments
Specifications
6 specs
C-MSISDN Description Purpose Related Classification Detected Changes Specifications

Description

The C-MSISDN is a critical identifier within the Voice Call Continuity (VCC) architecture defined in 3GPP Release 8 and later. It functions as a temporary, session-specific Mobile Station International Subscriber Directory Number assigned by the VCC Application in the IMS network when a UE initiates or receives a VCC-enabled call. This temporary number is distinct from the user's primary MSISDN and is used exclusively for the duration of the VCC session to facilitate domain transfer procedures.

Architecturally, the C-MSISDN operates within the VCC Application, which resides in the IMS core network. When a VCC-capable UE registers with the network, the VCC Application may pre-allocate a pool of C-MSISDNs or allocate them on-demand. During call setup, if the call is subject to VCC procedures, the VCC Application assigns a C-MSISDN to the UE and stores the mapping between this temporary identifier, the user's primary identity (such as IMS Public User Identity), and the current call session information. This mapping is maintained in the VCC Application's database throughout the call session.

The C-MSISDN enables the network to correlate the two legs of a VCC call: the Circuit-Switched leg (typically over GERAN/UTRAN) and the IMS leg (over E-UTRAN or other IP-CAN). When a domain transfer is initiated (for example, from IMS to CS), the VCC Application uses the C-MSISDN to identify the target UE in the CS domain. The network routes the CS call leg to this temporary number, which is recognized by the VCC Application. The application then bridges the incoming CS leg with the existing IMS leg, maintaining call continuity without requiring the called party to redial or re-establish the connection.

Key components involved in C-MSISDN handling include the VCC Application itself, the Home Subscriber Server (HSS) for subscriber data management, the MSC Server for CS domain control, and the Serving-Call Session Control Function (S-CSCF) for IMS session control. The C-MSISDN must be routable in both CS and IMS domains and typically follows the same numbering format as regular MSISDNs, though it is allocated from a dedicated number range managed by the operator.

From a protocol perspective, the C-MSISDN appears in various signaling messages including SIP messages within IMS (particularly in the P-Asserted-Identity header) and ISUP/BICC messages in the CS domain. The VCC Application ensures that the C-MSISDN is properly inserted into relevant signaling paths and that the correlation between domains is maintained throughout the call session, including during mid-call transfers and call termination procedures.

Purpose & Motivation

The C-MSISDN was created to solve the fundamental problem of maintaining voice call continuity when a user equipment moves between different access network technologies, specifically between Circuit-Switched (CS) domains (like 2G/3G networks) and IP Multimedia Subsystem (IMS) domains (like LTE/5G networks). Before VCC and the C-MSISDN mechanism, calls would typically drop when transitioning between these fundamentally different network architectures because there was no standardized way to correlate the two independent call legs that existed in separate domains.

Historically, as operators began deploying IMS-based voice services (VoLTE) alongside traditional CS voice networks, they needed a solution for seamless handover between these domains, particularly for areas with patchy LTE coverage. The C-MSISDN provides the essential correlation mechanism that enables Single Radio Voice Call Continuity (SRVCC) and other VCC variants to function properly. Without this temporary identifier, the network would have no way to associate an incoming CS call leg with an ongoing IMS session, making domain transfers impossible without call interruption.

The C-MSISDN addresses several specific limitations of previous approaches: it eliminates the need to expose the user's actual MSISDN during domain transfer procedures (enhancing privacy), provides a clean separation between user identity and session routing, and enables standardized interworking between CS and IMS networks from different vendors. By serving as a session-specific routing address, the C-MSISDN allows operators to implement VCC without requiring changes to existing CS network elements or breaking existing charging and lawful interception systems.

Classification

Part ofMSISDN

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (7 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-15.

Rel-15 1 change

In Release 15, the C-MSISDN was formally integrated into the 5G-SRVCC handover procedure via the N26 interface, enabling session correlation for voice continuity from 5GS to 3GPP CS networks. Specifically, the AMF was defined to include the C-MSISDN, along with the STN-SR and a 5G-SRVCC HO Indication, in the handover signalling to the MME for a non-emergency session. This allowed the C-MSISDN, received by the AMF from the UDM/HSS as part of the subscription data, to be used for correlating the PS and CS legs during the SRVCC handover.

  • CP-190170 clause numbers updated after information provided by RAN2 "See clauses 22.3.6.2 and 22.3.6.3 of 3GPP TS 36.300 [19]." TS 29.274
Rel-16 1 change

In Release 16, the C-MSISDN was formally integrated into the 5G-SRVCC procedure via the N26 interface, where the AMF includes it alongside the STN-SR in handover signaling to the MME for non-emergency sessions. Furthermore, the specification now explicitly states that the C-MSISDN is part of the subscription data downloaded from the UDM/HSS to the AMF, and its presence, together with the STN-SR, indicates 5G-SRVCC subscription.

  • Sequence Number in RAB Context TS 29.274CR1959
Rel-17 2 changes

In Release 17, the specification was corrected to fix a reference number and to address an error in the octet numbering for a GTPv2 Information Element related to C-MSISDN. The core technical function of the C-MSISDN itself, as a number used for correlating sessions during SRVCC and 5G-SRVCC handovers, remained consistent with its established role in subscription data transfer between network functions like the HSS, MME, and AMF.

  • Correct the reference number TS 29.274CR2051
  • GTPv2 IE with wrong octet numbering TS 29.274CR2009
Rel-18 3 changes

In Release 18, the primary new function for C-MSISDN was its explicit transfer during Inter-MME/AMF mobility procedures specifically for Lawful Interception purposes. This builds upon its existing role in SRVCC handovers, where it is part of the subscription data sent from the HSS/UDM to the MME or AMF and is included in handover request messages to an MSC Server. The release also included corrections to related parameters, such as the AMF identifier's instance number.

  • MSISDN transfer during Inter-MME/AMF mobility for Lawful Interception TS 29.274CR2070
  • Correct the instance number of the AMF Identifier TS 29.274CR2085
  • Rejection cause if the number of UEs in the network slice has been exceeded TS 29.274CR2103

Explore further

Broader topics and technologies where C-MSISDN plays a role.

Defining Specifications

3GPP specifications that define or reference C-MSISDN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.216 vj00 SRVCC Architecture Enhancements Rel-19
TS 23.237 vj00 IMS Service Continuity (ISC) Stage 2 Rel-19
TS 23.292 vj00 IMS Centralized Services (ICS) Architecture Rel-19
TS 24.237 vj00 IMS Service Continuity Protocol Details Rel-19
TS 29.060 vj00 GPRS Tunnelling Protocol (GTP) version 1 Rel-19
TS 29.274 vj50 GTPv2-C Control Plane Protocol Specification Rel-19