5.1.2 IMS charging correlation

32.2603GPPCharging managementIP Multimedia Subsystem (IMS) chargingRelease 17Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1.2.1 Basic principles for IMS domain correlation

The IMS charging correlation information is encoded in the SIP P-Charging-Vector header as defined in the following sub clauses. The P-Charging-Vector header contains the following parameters: ICID, access network charging identifier and IOI.

The loopback-indication parameter identify when loopback apply.

General correlation mechanisms are defined in TS 32.240 [1], and further details about the usage of P-Charging-Vector are defined in TS 24.229 [204], TS 24.292 [210], and IETF RFC 7315 [406].

The enhanced MSC server for ICS charging in this specification refers the MSC server which performs IMS registration, as defined in TS 23.292 [219]. The enhanced MSC server for SRVCC charging in this specification refers the MSC server defined in TS 24.237 [217].

5.1.2.2 IMS Charging Identifier

The IMS domain correlation is based on IMS Charging Identifier (ICID) shared between IMS Network Elements involved with the same session/transaction. With ICID it is possible to correlate session/transaction related charging data generated in different IMS elements (i.e. x-CSCFs, ASs’). The ICID is included in all SIP methods, if the P-Charging-Vector header is present, and transferred through originating and terminating side nodes, except to UE.

The value of the ICID parameter is identical with the ‘icid-value’ parameter defined in TS 24.229 [204]. The ‘icid-value’ is a mandatory part of the P-Charging-Vector and coded as a text-based UTF-8 charset (as are all SIP messages). For further information regarding the composition and usage of the P-Charging-Vector refer to [204] and RFC 7315 [406].

The ICID value is globally unique across all 3GPP IMS networks for a time period of at least one month, implying that neither the node that generated this ICID nor any other IMS Network Element reuse this value before the uniqueness period expires. The one month minimum uniqueness period counts from the time of release of the ICID, i.e. the ICID value no longer being used. This can be achieved by using node specific information, e.g. high-granularity time information and / or topology / location information. The exact method how to achieve the uniqueness requirement is an implementation issue.

At each SIP session unrelated method, both initial and subsequent (e.g. SIP REGISTER, SIP NOTIFY, SIP MESSAGE etc.), a new, session unrelated ICID is generated at the first IMS Network Element that processes the method. This ICID value is contained in the SIP request and SIP response of that SIP transaction and must be valid for the duration of the transaction.

At each SIP session establishment a new, session specific ICID is generated at the first IMS Network Element that processes the session-initiating SIP INVITE message. Enhanced MSC server will generate an ICID for ICS and SRVCC originated calls as described in TS 24.229 [204]. This ICID is then used in all subsequent SIP messages for that session (e.g., SIP 200 OK, SIP (RE-)INVITE, SIP BYE etc.) until the session is terminated.

5.1.2.2A Related ICID

During the process of SRVCC access transfer, the Enhanced MSC server or the P-CSCF generates an ICID for the target access leg. For the purpose of charging correlation between the source access leg and the target access leg when the user is roaming the SCC AS and the ATCF includes the ICID used on the source access leg as the Related ICID for the target access leg as described in TS 24.229 [204]. Alternatively, when OneChargingSession is applied in the SCC AS and the ATCF, the ICID of the original access leg is preserved in the AS/ATCF CDR for the whole duration of the session, and the Related ICID contains the ICID used on the target access leg.

This Related ICID is sent in the 1xx and 2xx responses to the initial SIP INVITE as described in TS 24.237 [217].

5.1.2.3 Access network charging identifier

The access network charging identifier is the media flow level data shared among the IMS Network Elements for one side of the session (either the originating or terminating side). This information is used to correlate the access network charging data with the IMS charging data.
The access network is identified by access specific correlation identifier, e.g. for Packet Switched Access (PGW address and Charging Id per bearer) , for 5GS (SMF Address and Charging Id per PDU session) or Fixed Broadband Access (Multimedia Charging Identifier). The access network charging identifier is populated in the P-Charging-Vector using the access-network-charging-info parameter. For further information regarding the composition and usage of the access-network-charging-info parameter refer to TS 24.229[204] and RFC 7315 [406].

5.1.2.4 Inter Operator Identifier

The Inter Operator Identifier (IOI) identifies originating, terminating and transit networks involved in a session/transaction. The IOI may be generated from each side of session/transaction to identify the home networks associated with each side. The Orig-IOI and Term-IOI parameters of P-Charging-Vector represent the originating and terminating operator identifiers.

For interconnection scenarios in multi operator environments where one or more transit operators are between the originating and terminating operator, a list of Transit-IOI values may occur additionally to identify involved transit operators. Due to operator policy, a transit operator may also hide his identity by adding a void value. Addition and deletion of Transit-IOI values are operator configurable. For further information regarding the composition and usage of the parameters refer to TS 24.229[204], TS 24.292 [210], and IETF RFC 7315 [406].

NOTE: No transit networks are expected between the S-CSCF and a 3^rd party Application Server triggered by the initial filter criteria in the S-CSCF.

5.1.2.5 Void

5.1.2.6 IMS visited network identifier

The IMS visited network identifier identifies the visited network involved in a session/transaction. The IMS visited network identifier is available in the SIP P-Visited-Network-ID header of the SIP REGISTER, with the value according to 3GPP TS 24.229 [204], and should be used for all charging events associated with the user.

– For the roaming architecture for voice over IMS with local breakout, the value of IMS visited network identifier is a pre-provisioned string that identifies the network of the P-CSCF at the home network.

– For the roaming architecture for voice over IMS with home routed traffic, IMS visited network identifier is a string that identifies the visited network of the UE including an indication that the P-CSCF is located in the home network.

5.1.2.7 Loopback-indication

During the loopback the TRF will set the Loopback-indication parameter to identify when loopback applies. When the TRF receives responses to initial or subsequent requests from the terminating side, the TRF inserts in the P-Charging-Vector header field, if present, the "loopback-indication" header field parameter to the outgoing response.

5.1.2.8 Functional Entity (FE) Identifier List

The FE Identifier List contains one or more:

– IM CN subsystem functional entity address, and/or

– AS address and the corresponding application identifier

As defined in TS 32.240 [1] clause 5.3.4.4.2 the functional entity address is included when the IM CN subsystem functional entity does create charging information for the related CDR of this IM CN subsystem functional entity. As defined in TS 32.240 [1] clause 5.3.4.4.3 for AS hosting several applications the same AS address can appear several times, each accompanied with a different application identifier based on the application executed by the AS.

Values in SIP requests shall be ignored. The FE-Identifier header exchange via SIP signalling is defined in TS 24.229 [210].