Description
The Service Control Signalling Path is a logical communication channel defined in 3GPP specifications for the purpose of carrying service control signalling between the User Equipment (UE) and the Service Centralization and Continuity Application Server (SCC AS). This path is essential for enabling advanced services such as IMS Centralized Services (ICS) and Single Radio Voice Call Continuity (SRVCC), where the SCC AS acts as the anchor point for service control, managing session establishment, modification, and continuity across different access networks. The signalling path is not a physical link but rather a set of protocols and procedures that allow the UE and SCC AS to exchange control messages, regardless of the underlying access technology.
The architecture supporting the Service Control Signalling Path involves several key components. The UE initiates service control signalling to request services, modify sessions, or perform other control functions. The SCC AS, located in the home network, is the central control entity that coordinates service delivery and ensures continuity when the UE moves between access networks. The path can be established in two primary ways: directly via an IP-Connectivity Access Network (IP-CAN), such as LTE or 5G, or indirectly via Circuit-Switched (CS) network elements, such as the Mobile Switching Center (MSC) and the Visitor Location Register (VLR). The choice of path depends on the UE's capabilities, the available access networks, and the service requirements. For example, a UE with simultaneous CS and PS access might use the CS path for certain control signalling while using the IP-CAN for others.
The operation of the Service Control Signalling Path is governed by protocols such as SIP (Session Initiation Protocol) for IMS-based services, and specific procedures defined in 3GPP TS 23.237 and TS 23.292. When the UE wants to establish a service, it sends a control message (e.g., a SIP INVITE) towards the SCC AS. If the UE is on an IP-CAN, the message is routed through the IP-CAN's bearer and the IMS core network to reach the SCC AS. If the UE is on a CS access, the message may be encapsulated within CS signalling (e.g., using the CS domain's control channels) and then interworked to SIP at the MSC Server or IMS gateway. The SCC AS then processes the request, interacts with other network functions (e.g., HSS, PCRF/PCF), and sends responses back along the same path. This path is also used for service control signalling related to mid-call features, call waiting, and continuity procedures.
The Service Control Signalling Path is critical for ensuring that service control is maintained consistently regardless of the access network. It enables the SCC AS to remain in the signalling path for the duration of the service, allowing it to make decisions about session routing, access transfer, and policy enforcement. This is particularly important for voice services that need to seamlessly transition between LTE/5G and CS networks. Without a reliable signalling path, service continuity and centralized control would be impossible. The definition has evolved to explicitly include both direct IP-CAN and indirect CS paths, reflecting the need to support UEs that may not have simultaneous IP connectivity or that may be roaming in networks with limited IP capabilities.
In summary, the Service Control Signalling Path is a fundamental enabler for IMS Centralized Services and SRVCC. It provides the necessary transport for control messages between the UE and the SCC AS, ensuring that service control functions are always accessible. Its design accommodates various access technologies and network configurations, making it a versatile and robust component of the 3GPP service architecture.
Purpose & Motivation
The Service Control Signalling Path exists to provide a reliable and standardized means for the UE to communicate with the SCC AS for service control purposes. Before its definition, service control signalling was often fragmented and access-specific, making it difficult to maintain consistent service behavior across different networks. The introduction of this concept in Release 8 addressed the need for a unified signalling path that could support IMS Centralized Services (ICS) and later Single Radio Voice Call Continuity (SRVCC). The primary problem it solves is the need for a persistent control channel that remains available even when the UE moves between access technologies, such as from LTE to UTRAN/GERAN.
The motivation for defining this path was driven by the industry's push towards all-IP networks and the desire to offer voice and multimedia services over both packet-switched and circuit-switched domains. In early IMS deployments, service control was only possible when the UE had IP connectivity, which limited service availability in areas with only CS coverage. The Service Control Signalling Path allows the UE to maintain service control even when using CS access, by routing control messages through CS network elements to the SCC AS. This ensures that services like voice call continuity and centralized service control are available ubiquitously.
Furthermore, the path enables the home network to retain control over services even when the UE is roaming or using a different access network. This is crucial for enforcing home network policies, charging, and service personalization. The explicit inclusion of both direct IP-CAN and indirect CS paths in the definition (from Rel-9 onwards) reflects the practical need to support a wide range of UE capabilities and network deployments. It also aligns with the goal of providing a seamless user experience across heterogeneous networks. The Service Control Signalling Path is therefore a key architectural element that supports the vision of ubiquitous and continuous service delivery.
What changed in its specifications
The latest release-to-release comparison of specifications that define Service Control Signalling Path. Each summary describes the whole specification, not only this term.
Rel-19 brings only minor changes to TS 23.237: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TS 23.237 →Rel-19 brings only minor changes to TS 23.292: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TS 23.292 →Release Timeline
Evolution Across Releases
An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.
Definition revised to: 'Signalling path established between the UE and the SCC AS, either directly via an IP-CAN or via CS network elements for service control signalling.' This change explicitly added the two possible transport options (direct IP-CAN or indirect CS) and clarified the purpose as 'for service control signalling'.
Defining Specifications
3GPP specifications that define or reference Service Control Signalling Path, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.237 vj00 | IMS Service Continuity (ISC) Stage 2 | Rel-19 read |
| TS 23.292 vj00 | IMS Centralized Services (ICS) Architecture | Rel-19 read |