IMS Communication Service Identifier

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.

Key Features

• Uniquely identifies a standardized IMS Communication Service (e.g., MMTel, RCS)
• Carried within SIP signaling headers (e.g., P-Asserted-Service) for session identification
• Used by the S-CSCF to match Initial Filter Criteria (iFC) and route sessions to the correct Application Server
• Enables the application of service-specific network policies for QoS, charging, and security
• Allows a single UE to register once for IMS but invoke multiple different services
• Facilitates interoperability between UEs and networks from different vendors and operators

Evolution Across Releases

Defining Specifications