Description
The IMS Communication Service Identifier (ICSI) is a standardized alphanumeric token (e.g., 'urn:urn-7:3gpp-service.ims.icsi.mmtel' for Multimedia Telephony) defined by 3GPP. It is a crucial mechanism for service identification and differentiation within the IP Multimedia Subsystem. The ICSI is associated with a specific IMS Communication Service (ICS), which is a standardized set of capabilities and procedures (like MMTel for telephony). When a User Equipment (UE) initiates or receives a session, it includes the relevant ICSI value within the SIP signaling, typically in the Contact header field or the P-Asserted-Service header.
Upon receiving a SIP request containing an ICSI, network elements like the P-CSCF, S-CSCF, and Application Servers (AS) can inspect this identifier. This allows them to determine precisely which service is being requested. This identification triggers the application of service-specific policies, routing logic, and charging rules. For example, a VoLTE call identified by its ICSI can be routed to a specific Telephony Application Server (TAS), be subject to different QoS (Quality of Service) prioritization than a best-effort data session, and be charged according to voice tariff plans.
The ICSI works in tandem with the IMS Application Reference Identifier (IARI), which identifies specific applications within a service. The ICSI provides the broader service context. The S-CSCF uses filter criteria in the user's service profile, which can be matched against the ICSI, to decide whether to forward the session to a particular Application Server. This enables a modular service architecture where new services can be introduced by defining a new ICSI and the corresponding network logic, without fundamentally altering the core IMS routing machinery. The ICSI is essential for enabling multiple, concurrent services over a single IMS registration and for ensuring backward and forward compatibility between UEs and network nodes of different releases.
Purpose & Motivation
The creation of the ICSI was driven by the need to move beyond a monolithic 'IMS service' concept to a world where multiple, distinct communication services could coexist and be independently developed, deployed, and managed over the same core infrastructure. Prior to its standardization, service identification was often implicit or based on non-standard extensions, leading to interoperability issues and difficulty in introducing new services.
It solves the problem of unambiguous service selection and invocation. In a scenario where a user's device supports VoLTE, ViLTE, and RCS chat, the network needs to know which specific service is being used for a particular session to apply the correct treatment (e.g., emergency service routing for voice, video codec negotiation for video, message store-and-forward for chat). The ICSI provides this clear, standardized signal.
Furthermore, it enables efficient service triggering and policy enforcement. Network operators can configure rules based on ICSI values to direct traffic to the appropriate application servers, apply specific QoS profiles, and implement accurate charging. This granularity is fundamental for commercial service offerings, allowing operators to create differentiated service plans and ensure a consistent user experience for each type of communication service. It formed a cornerstone for the commercialization of IMS, starting with MMTel (VoLTE/ViLTE) and expanding to other services.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (24 CRs across 6 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-7, normative work from Rel-15.
In Release 15, the ICSI function was enhanced to enable the S-CSCF to analyze SIP requests and include an Authenticated ICSI value, which acts as a summary of the request's contents for service triggering. This allows the network to ensure that the contents of any request correspond to zero or one ICSI for a given subscriber. Furthermore, the ICSI value can be sent to Application Servers, with trusted ASes including an authenticated value and external ASes including an unauthenticated one.
- IMS multimedia telephony communication service and supplementary services TS 24.173CR0122
- UE behaviour for MO MMTel voice call when service request failure TS 24.173CR0123
- MMTel -PS Data Off for 5GS TS 24.173CR0125
- Unified Access Control for MMTel TS 24.173CR0126
- 3GPP PS Data Off2 and MMTEL voice and MMTEL video TS 24.173CR0127
- No unified access control check when adding or removing media during MMTEL session TS 24.173CR0130
In Release 16, the ICSI function was enhanced to include the capability for the S-CSCF to analyze SIP header fields and SDP media types to derive and include an Authenticated ICSI value in requests sent to Application Servers. This authenticated value acts as a summary of the request's contents to aid in service triggering. Furthermore, the release specified that an AS within the trust domain can include an authenticated ICSI value, while an AS outside it can include an unauthenticated one.
In Release 17, enhancements for the ICSI function included specifying the handling of a communication security context when using a functional alias and defining procedures for handling lower layer congestion notification specifically for MMTEL video services. Furthermore, the release introduced support for MMTEL Voice and MMTEL Video communication services when accessed via non-3GPP access networks.
In Release 18, the ICSI function was enhanced to support service continuity during active sessions, specifically enabling migration procedures for ongoing group and private communications. Additionally, new procedures were defined to allow subsequent MCVideo and MCData communications following an adhoc group emergency alert. The release also introduced support for Prose direct communication within the IMS framework.
- Migration during an ongoing group communication TS 23.280CR0315
- Migration procedure during and ongoing private communication TS 23.280CR0330
- Partner MC service server stores necessary information for communication redirection TS 23.280CR0355
- Updates procedures for allowing subsequent MCVideo and MCData communications after an adhoc group emergency alert TS 23.280CR0378
- Support of Prose direct communication TS 24.481CR0070
In Release 19, the ICSI function was updated with new procedures specific to avatar communication. The changes, detailed across multiple Change Requests, focused on updating and refining the process for this service. This involved modifying the existing procedural model for handling SIP information related to avatar communication sessions.
In Release 20, the ICSI function was enhanced to explicitly include Mission Critical Data (MCData) services within the generic procedures for migration during both ongoing private and ongoing group communications. This provided specific handling for MCData sessions within the existing IMS service continuity framework. The release also included clarifications on the application of these procedures for point-to-point communication scenarios.
Explore further
Broader topics and technologies where ICSI plays a role.
Defining Specifications
3GPP specifications that define or reference ICSI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.218 vj00 | IMS Call Model Specification | Rel-19 |
| TS 23.280 vk10 | Common Architecture for Mission Critical Services | Rel-20 |
| TS 24.167 vj00 | 3GPP IMS Management Object Specification | Rel-19 |
| TS 24.173 vj00 | Multimedia Telephony Service and Supplementary Services in IMS | Rel-19 |
| TS 24.186 vj60 | IMS Data Channel applications | Rel-19 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 24.259 vj00 | Personal Network Management (PNM) Protocol Details | Rel-19 |
| TS 24.481 vj20 | Mission Critical Services (MCS) group management | Rel-19 |
| TR 29.949 vj00 | VoLTE IMS Roaming Architecture & Procedures | Rel-19 |
| TS 32.850 ve00 | IMS Charging Correlation Methods Study | Rel-14 |