Content for TS 32.260 Word version: 17.5.0
5 Charging principles
5.1 IMS charging principles
5.1.0 Introduction
5.1.1 IMS charging applicability
5.1.2 IMS charging correlation
5.1.3 SDP handling
5.1.4 Trigger conditions
5.1.5 IMS support of real-time tariff transfer
5.1.6 Served user identification
5.1.7 Single charging session from AS/ATCF acting as B2BUA
...
...
5 Charging principles p. 21
5.1 IMS charging principles p. 21
5.1.0 Introduction |R12| p. 21
The IMS node shall maintain the integrity of all received or created charging-related information when forwarding the information to the offline, online and converged charging systems, whatever the length of the value of any particular parameter is. For example, the IMS Charging Identifier (ICID) may be generated by one IMS node (e.g. the P-CSCF) and forwarded to another IMS node (e.g. the S-CSCF). Both may generate charging information and ensure that the data integrity is maintained, in order to make possible correlation based on the ICID.
5.1.1 IMS charging applicability |R8| p. 21
The IMS node may select charging method, i.e. online, offline or converged. The selection can be made based on local configuration or a combination of local configuration and received OCS/CDF addresses.
If a combination of local configuration and received OCS/CDF addresses and:
- only OCS address received, then either online charging (over Ro) or converged charging (over Nchf) may be used based on local configuration.
- only CDF address received then either offline charging (over Rf), converged charging (over Nchf) or offline only charging (over Nchf) may be used based on local configuration.
- both OCS and CDF address received then either online and offline changing (over Ro and Rf), or converged charging (over Nchf) may be used based on local configuration.
- neither OCS nor CDF address received then depending on IMS node any of the above may be used based on local configuration.
5.1.2 IMS charging correlation p. 21
5.1.2.1 Basic principles for IMS domain correlation p. 21
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, and further details about the usage of P-Charging-Vector are defined in TS 24.229, TS 24.292, and RFC 7315.
The enhanced MSC server for ICS charging in this specification refers the MSC server which performs IMS registration, as defined in TS 23.292. The enhanced MSC server for SRVCC charging in this specification refers the MSC server defined in TS 24.237.
5.1.2.2 IMS Charging Identifier p. 21
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. 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 TS 24.229 and RFC 7315.
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. 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 |R11| p. 22
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. 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.
5.1.2.3 Access network charging identifier p. 22
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 and RFC 7315.
5.1.2.4 Inter Operator Identifier p. 22
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, TS 24.292, and RFC 7315.
5.1.2.5 Void
5.1.2.6 IMS visited network identifier |R11| p. 22
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 TS 24.229, 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 |R13| p. 23
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 |R14| p. 23
The FE Identifier List contains one or more:
- IM CN subsystem functional entity address, and/or
- AS address and the corresponding application identifier
5.1.3 SDP handling |R8| p. 23
SDP information on SIP can have two different meanings; SDP offer or SDP answer. This is captured in the charging information by a SDP-type parameter that indicates if the SDP Media Component is an SDP offer or SDP answer. SDP offers can be sent by either the calling or called party and the Media Initiator Flag identifies who sent the first SDP offer in a SDP negotiation. SDP can be negotiated more than once in an SIP INVITE or SIP RE-INVITE dialog.
Each occurrence of the List of SDP Media Components in the corresponding CDRs may include either SDP offer or SDP answer. For the first negotiation, the SDP answer defines which media are used in the session, therefore it shall be recorded in case of successful session setup. Additionally the corresponding SDP offer may be recorded. In case of unsuccessful session setup the SDP offer may be recorded, if available.
When session re-negotiations occur, multiple occurrences of List of SDP Media Components may be used to include a series of SDP negotiations in which each occurrence holds an SDP offer or SDP answer as for the first SDP negotiation.
5.1.4 Trigger conditions |R8| p. 23
This clause contains the details for trigger conditions listed in Table 5.2.1.1 for offline charging messages (Charging Data Request and Charging Data Response) and Table 5.3.1.1 for online charging messages (Debit / Reserve Units Request and Debit / Reserve Response) triggered by SIP methods or ISUP messages for all IMS nodes except for MRFC and AS.
The I-CSCF and BGCF, which need not be present in the signalling path for subsequent requests after the first SIP INVITE, do not support session-based charging using Charging Data Request [Start, Interim, and Stop]. In these (and only in these) IMS Network Elements, successful session set-up completion triggers Charging Data Request [Event]. Use of session-based charging when the I-CSCF or the BGCF is call stateful is not described in this release.
The initial registration, user-initiated re-registration, and user-initiated de-registration chargeable events relate to SIP REGISTER to trigger Charging Data Request [Event] / Debit / Reserve Units Requests, while network-initiated deregistration event relates to SIP NOTIFY to trigger Charging Data Request [Event] / Debit / Reserve Units Requests provided that subscription to registration events has been applied (see TS 24.229).
If at the time when the SIP 200 OK is received only the SDP offer is available, the CTF may trigger Charging Data Request [Start] immediately (subsequent SIP ACK containing the SDP answer triggers Charging Data Request[Interim]) or may trigger Charging Data Request [Start] once the SIP ACK has been received. The precise behaviour shall depend on operator policy.
If capturing the last user location information and/or UE Time Zone of one specific party (originating or terminating) at session release is required by operator (e.g. for legal purpose), and such information is not available at the time the SIP BYE is received, the CTF shall delay the Charging Data Request[Stop] until the reception of SIP 200 OK acknowledging the SIP BYE. Otherwise, the CTF shall trigger Charging Data Request[Stop] once the SIP BYE request has been received.
If capturing the last user location information and/or UE Time Zone of one specific party (originating or terminating) at session release is required by operator (e.g. for legal purpose), and such information is not available at the time the SIP BYE is received, the CTF shall delay the Debit / Reserve Units Request [Terminate] until the reception of SIP 200 OK acknowledging the SIP BYE. Otherwise, the CTF shall trigger Debit / Reserve Units Request [Terminate] once the SIP BYE request has been received. In any case, the granted quota shall not be used once the SIP BYE is received.
If capturing a user location change during a session is required by operator (e.g. for legal or statistics purposes), the CTF should trigger Charging Data Request or Debit / Reserve Units Request on any SIP method received containing user location information.
5.1.5 IMS support of real-time tariff transfer |R9| p. 24
The TS 29.658 describes the Real-time Transfer of Tariff Information (RTTI) in SIP. The RTTI may be supported for the requested service (e.g. tariff information of a value added service residing in the called network or in a specific AS).
According to the procedures described in the TS 29.658, tariff information may be included in the content body of the following SIP messages: 1xx provisional response or SIP 200 OK at session setup, mid-dialog requests or responses. The following IMS Network Elements, IBCF, MGCF, S-CSCF and AS may pass tariff information and record the tariff information in the corresponding CDRs for IMS offline charging. For online charging, the AS and the IMS-GWF may send charging information related to the content body of RTTI message over Ro interface to the OCS.
The following security mechanisms shall be used for RTTI:
- IBCF shall accept RTTI information only from trusted IMS networks and filter out RTTI information from non trusted IMS networks.
- If RTTI information has to be sent over unsecure domain networks, the security of the domains interconnection shall rely on Network Domain Security specifications: TS 33.210 and TS 33.310.
- The S-CSCF responsible for the handling of RTTI messages shall follow the common IMS security specification TS 33.203 to protect against malicious UE that try to bypass the P-CSCF.
5.1.6 Served user identification |R11| p. 24
Subscriber Identifier is an Information Element used in both online and offline charging information to identify the served user for the specific leg of an IMS session. A list of Subscription Id(s) for IMS CDR shall contain the Public user Id(s) for the served user.
In the case when the served user is obtained from the P-Header P-Served-User (can be available in P-CSCF, S-CSCF and AS) then it shall also be used as Subscription-Id in both online and offline charging.
The Subscriber Equipment Number field contains the identification of the mobile device (e.g. IMEI) that the subscriber is using.
An Instance Id is defined as a URN generated by the device that uniquely identifies a specific device amongst all other devices (fixed or mobile). The Instance Id is transported in the sip.instance feature tag in the Contact header of a SIP request associated with the served user.
5.1.7 Single charging session from AS/ATCF acting as B2BUA |R11| p. 24
When a session-initiating SIP INVITE message is received by an AS/ATCF, this AS/ATCF, per application logic needs, acting as a B2BUA, may decide ICID for the outgoing dialog to be the same as received or different.
In case the same ICID is preserved between incoming and outgoing dialog by the AS/ATCF acting as a B2BUA, a single charging session for both dialogs can be created by this AS/ATCF. This option, refered-to as "OneChargingSession" in the different descriptions, is applicable per Operator configuration.
