Description
CSI is a comprehensive service architecture defined by 3GPP that bridges the gap between traditional Circuit-Switched (CS) domain services, primarily voice and SMS, and the emerging IP Multimedia Subsystem (IMS) domain services, which include multimedia telephony, video calling, and rich communication services (RCS). The architecture is designed to allow these two distinct service delivery platforms to coexist and interoperate, presenting a unified service logic and user experience to the subscriber. It achieves this through a set of standardized functional entities and reference points that coordinate service execution between the CS core network (MSC) and the IMS core (CSCF).
At its core, CSI introduces the concept of service interaction and coordination. When a CSI-enabled subscriber initiates or receives a session, the network must determine how to route and handle the service components. For a voice call, this might be handled natively by the CS domain for wide-area reliability, while supplementary services or concurrent multimedia sessions (like video or file transfer) are anchored and managed by the IMS. The architecture defines mechanisms, such as the IMS Service Control (ISC) interface and enhancements to the CAMEL (Customised Applications for Mobile network Enhanced Logic) protocol, to facilitate this coordination. A key functional component is the CSI Application Server (AS) within the IMS, which hosts the combined service logic and interacts with both the Serving-CSCF (S-CSCF) via the ISC interface and, indirectly, with the CS domain to orchestrate the service flow.
The technical operation involves session establishment and control procedures. For an originating mobile-originated CSI session, the User Equipment (UE) indicates its CSI capability. The network, often via policy decisions in the IMS, may split the media components: real-time voice is routed over the CS bearer using traditional call control (e.g., via the MSC), while other media streams (e.g., video) are established as separate IP flows via the Packet-Switched (PS) bearer, controlled by the IMS using the Session Initiation Protocol (SIP). The IMS acts as the service control anchor, ensuring that billing, supplementary services (like call hold or transfer), and service logic are applied consistently across both domains. This requires tight synchronization between SIP signaling in the IMS and ISUP/BICC signaling in the CS core.
CSI's role in the network is fundamentally transitional and integrative. It serves as a critical enabler for network operators migrating from 2G/3G CS-centric architectures to 4G/5G all-IP networks based on IMS and VoLTE/VoNR. By allowing the CS network to act as a reliable voice media bearer while IMS provides advanced service control, CSI protects investments in legacy infrastructure and ensures service availability during the migration period. It also enables the early introduction of IMS-based multimedia services to subscribers who may not yet have full IMS-capable devices or radio access, thereby accelerating the adoption of new revenue-generating services.
Purpose & Motivation
CSI was created to address a fundamental challenge in the evolution of mobile networks: the transition from circuit-switched, voice-dominated networks to packet-switched, multimedia-capable all-IP networks. In the early 2000s, with the standardization of IMS in 3GPP Release 5, operators faced a dilemma. IMS promised a future of rich, integrated multimedia services but required a completely new core network architecture. Meanwhile, the existing CS network represented a massive, reliable, and ubiquitous investment for voice telephony, the primary revenue source. A 'big bang' replacement was economically and technically infeasible. CSI was conceived to solve this by allowing both domains to work together, enabling a gradual, risk-managed migration path.
The primary problem CSI solves is service fragmentation and subscriber experience degradation during the transition. Without CSI, a network deploying IMS would create two separate service silos: basic voice/SMS on the CS network and advanced multimedia on IMS, with little to no interaction between them. A subscriber might have two separate identities, address books, and service profiles. CSI eliminates this by providing a unified service layer. It allows operators to introduce IMS-based service innovation—like combining voice with instant messaging or video—while still utilizing the mature, high-quality voice bearer of the CS network. This was particularly important for ensuring seamless service coverage and interoperability with legacy networks and devices.
Historically, CSI addressed the limitations of pre-IMS service architectures, which were either purely CS-based (lacking multimedia flexibility) or early PS multimedia attempts that were non-standardized and lacked robust session control. By standardizing the interaction, CSI provided a clear blueprint for vendors and operators. It motivated the creation of a hybrid service delivery model that maximized asset utilization, ensured backward compatibility, and paved the way for the eventual full migration to IMS-based Voice over LTE (VoLTE) and Voice over NR (VoNR), where the CS bearer is finally retired in favor of a full IP Multimedia Telephony service over the packet core.
Key Features
- Unified service control across CS and IMS domains
- Simultaneous CS voice and IMS multimedia session support
- Service continuity and consistent user experience during network transition
- Reuse of existing CS infrastructure for reliable voice bearer
- IMS-based service innovation and application server hosting
- Standardized coordination mechanisms (e.g., enhanced CAMEL, ISC interface)
Evolution Across Releases
Introduced the foundational CSI architecture in the 3GPP specifications. Defined the core concept of combining CS and IMS services, establishing the initial principles for service interaction, bearer splitting, and the role of the IMS as a service control anchor for sessions involving CS bearers. This release laid the groundwork for subsequent enhancements by specifying the basic functional entities and reference points needed for coordination.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 21.978 | 3GPP TS 21.978 |
| TS 23.279 | 3GPP TS 23.279 |
| TS 23.806 | 3GPP TS 23.806 |
| TS 26.141 | 3GPP TS 26.141 |
| TS 26.235 | 3GPP TS 26.235 |
| TS 29.078 | 3GPP TS 29.078 |
| TS 29.163 | 3GPP TS 29.163 |
| TS 29.278 | 3GPP TS 29.278 |
| TS 33.126 | 3GPP TR 33.126 |
| TS 33.127 | 3GPP TR 33.127 |
| TS 36.201 | 3GPP TR 36.201 |
| TS 36.211 | 3GPP TR 36.211 |
| TS 36.212 | 3GPP TR 36.212 |
| TS 36.213 | 3GPP TR 36.213 |
| TS 36.300 | 3GPP TR 36.300 |
| TS 36.302 | 3GPP TR 36.302 |
| TS 36.306 | 3GPP TR 36.306 |
| TS 36.307 | 3GPP TR 36.307 |
| TS 36.321 | 3GPP TR 36.321 |
| TS 36.331 | 3GPP TR 36.331 |
| TS 36.741 | 3GPP TR 36.741 |
| TS 36.825 | 3GPP TR 36.825 |
| TS 36.855 | 3GPP TR 36.855 |
| TS 36.867 | 3GPP TR 36.867 |
| TS 36.871 | 3GPP TR 36.871 |
| TS 36.878 | 3GPP TR 36.878 |
| TS 38.133 | 3GPP TR 38.133 |
| TS 38.174 | 3GPP TR 38.174 |
| TS 38.176 | 3GPP TR 38.176 |
| TS 38.211 | 3GPP TR 38.211 |
| TS 38.212 | 3GPP TR 38.212 |
| TS 38.213 | 3GPP TR 38.213 |
| TS 38.214 | 3GPP TR 38.214 |
| TS 38.321 | 3GPP TR 38.321 |
| TS 38.331 | 3GPP TR 38.331 |
| TS 38.522 | 3GPP TR 38.522 |
| TS 38.551 | 3GPP TR 38.551 |
| TS 38.808 | 3GPP TR 38.808 |
| TS 38.810 | 3GPP TR 38.810 |
| TS 38.824 | 3GPP TR 38.824 |
| TS 38.825 | 3GPP TR 38.825 |
| TS 38.830 | 3GPP TR 38.830 |
| TS 38.838 | 3GPP TR 38.838 |
| TS 38.843 | 3GPP TR 38.843 |
| TS 38.869 | 3GPP TR 38.869 |
| TS 38.889 | 3GPP TR 38.889 |
| TS 38.903 | 3GPP TR 38.903 |