ICID

IM CN subsystem Charging Identifier

Identifier →
Introduced in Rel-2 Also in: Core Network

ICID is a unique identifier used in IMS charging to correlate charging data records from different network functions for a single service session.

Category
Identifier
Introduced
Rel-2
Where
Services › IMS
Also touches
1 segments
Specifications
8 specs
ICID Description Purpose Related Classification Detected Changes Specifications

Description

The IM CN subsystem Charging Identifier (ICID) is a critical charging parameter defined within the 3GPP IP Multimedia Core Network Subsystem (IMS) architecture. Its primary function is to provide a unique correlation key that links all Charging Data Records (CDRs) generated for a specific IMS service session across multiple network functions. An IMS session, such as a Voice over LTE (VoLTE) call or a video conference, involves several IMS nodes: the Proxy-Call Session Control Function (P-CSCF) which is the first contact point, the Serving-CSCF (S-CSCF) which handles session control, and potentially Application Servers (AS) providing services. Each of these nodes can generate charging events independently.

The ICID is generated by the first IMS network entity that initiates charging for a session, typically the P-CSCF or S-CSCF, at the start of a dialog or transaction. This identifier is a globally unique string, often constructed using a combination of the generating node's hostname or IP address and a timestamp or sequence number to ensure uniqueness. Once generated, the ICID is included in all Diameter-based charging messages (like Accounting-Request (ACR) commands using the Ro or Rf reference points) sent from IMS nodes to the Charging Data Function (CDF) or Online Charging System (OCS). It is also propagated within IMS signaling, using SIP headers like P-Charging-Vector, to ensure all subsequent nodes involved in the session use the same ICID for their charging reports.

At the billing system or Charging Gateway Function (CGF), the ICID acts as the primary key to correlate partial CDRs from the P-CSCF, S-CSCF, and AS into a single, consolidated session record. This correlation is essential for generating an accurate, unified bill for the user. The architecture relies on the Diameter protocol's flexibility to carry the ICID as an Attribute-Value Pair (AVP) and on the SIP protocol's extensibility to transport it between IMS nodes, ensuring a seamless flow of charging information aligned with the session's signaling path.

Purpose & Motivation

The ICID was introduced to solve the problem of charging correlation in the decomposed, session-based architecture of IMS. Prior to IMS, circuit-switched voice calls typically involved a single switching node (MSC) that could generate a single CDR for the entire call. IMS, however, is a distributed, IP-based system where control and service functions are separated and can be provided by different physical nodes. Without a common identifier, the billing system would receive disjointed charging events from the P-CSCF, S-CSCF, and AS with no reliable way to link them as part of the same user session, leading to billing errors, duplicate charges, or lost revenue.

Its creation in 3GPP Release 5 was motivated by the need for a robust online and offline charging framework for IMS services, as defined in TS 32.260. The ICID provides the foundational mechanism for session correlation, which is a prerequisite for any sophisticated charging models, such as event-based charging, session-based charging, or composite charging for services involving multiple applications. It addresses the limitation of earlier packet data charging, which often relied on identifiers like the PDP context, which were not suitable for the application-layer, multi-node nature of IMS sessions. The ICID enables operators to implement accurate and reliable billing for complex next-generation services, which was critical for the commercial viability of IMS.

Classification

Part ofIMS

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-2, normative work from Rel-16.

Rel-16 2 changes

In Release 16, support for the P-Charging-Vector header field was extended to the BYE and PRACK SIP methods, ensuring the ICID and other charging parameters are properly conveyed during session termination and provisional response acknowledgement. This builds upon the existing procedures where the S-CSCF includes the ICID and charging function addresses in messages to Application Servers. The release also included corrections to the II-NNI specifications concerning the same header field to maintain consistency in inter-network charging.

  • Corrections on the II-NNI specifications on the P-Charging-Vector header field TS 29.165CR1006
  • Support of P-Charging-Vector header field in BYE and PRACK TS 29.165CR1015

Explore further

Broader topics and technologies where ICID plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.218 vj00 IMS Call Model Specification Rel-19
TS 23.815 v1500 IMS Charging Implications Rel-5
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 24.802 vc10 IMS II-NNI Traversal Scenario Determination Study Rel-12
TS 29.165 vj10 Inter-IMS Network to Network Interface (NNI) Rel-19
TR 29.949 vj00 VoLTE IMS Roaming Architecture & Procedures Rel-19
TS 32.850 ve00 IMS Charging Correlation Methods Study Rel-14
TR 33.978 v1800 Interim Security for Early IMS Rel-8