5.3 IMS online charging scenarios

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

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

5.3.1 Basic principles

IMS online charging uses the Credit-Control application that is specified in TS 32.299 [50].

Three cases for online charging are distinguished:

– Immediate Event Charging (IEC); and

– event charging with unit reservation (ECUR), and

– Session Charging with Unit Reservation (SCUR).

Both stage 2 and stage 3 mechanisms for the three cases for online charging are detailed in TS 32.299 [50].

In the case of Immediate Event Charging (IEC), granting units to the IMS Network Element is performed in a single operation that also includes the deduction of the corresponding monetary units from the subscriber’s account. The charging process is controlled by the corresponding Debit UnitsRequest which is sent for a given Credit-Control event.

In contrast, Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving, releasing and returning unused units for events. The deduction of the corresponding monetary units then occurs upon conclusion of the ECUR transaction. In this case, the Debit / Reserve Units Request is used to control the Credit-Control session.

Session Charging with Unit Reservation (SCUR) is used for Credit-Control of sessions. SCUR also includes the process of requesting, reserving, releasing and returning unused units for sessions, and the deduction of the corresponding monetary units. During a SIP session there can be repeated execution of unit reservation and debit operations as specified in TS 32.299 [50].

The IMS Network Element may apply IEC, where Debit UnitsRequest[event] messages are generated, or ECUR, using Reserve Units Request[Initial] and Debit Units Request[Terminate] or SCUR. The decision whether to apply IEC, ECUR or SCUR is based on the service and/or operator’s policy.

The CTF uses Debit / Reserve Units Request[Initial, Update, Terminate] in procedures related to successful SIP sessions. It uses Debit Units Request[event] or Reserve Units Request[Event or Initial, Terminate] depending on whether IEC or ECUR/SCUR applies) for unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the tables below.

It is operator configurable in the nodes for which SIP method a Debit / Reserve Units Request is sent. The table below describes all possible Debit / Reserve Units Requests that might be sent from an IMS GWF or an MRFC or an AS.

It is configurable for the operators to enable or disable the generation of a Debit / Reserve Units Request message by the IMS node in response to a particular "triggering SIP method".

Table 5.3.1.1: Debit / Reserve Units Request messages triggered by SIP methods for IMS-GWF or AS

message	Triggering SIP Method
Debit / Reserve Units Request [Initial]	SIP INVITE (SCUR)
	SIP NOTIFY (ECUR)
	SIP MESSAGE (ECUR)
	SIP REGISTER (ECUR)
	SIP SUBSCRIBE (ECUR)
	SIP REFER (ECUR)
	SIP PUBLISH (ECUR)
Reserve Units Request [Update]	SIP 2xx acknowledging a SIP INVITE, RE-INVITE or SIP UPDATE [e.g. change in media components] (SCUR)
	RE-INVITE or SIP UPDATE [e.g. change in media components, terminating identity change] (SCUR)
	Expiration of quota, Validity time expiry or other authorization triggers (quota threshold reached, …). (SCUR)
	Any SIP message (except those triggering a Debit / Reserve Units Request[Initial] or those not covered by the above triggers for Reserve Units Request[Update] conveying a SDP offer or its associated SDP answer before SIP session establishment (SCUR)
	SIP 1xx provisional response, mid-dialog requests, mid-dialog responses and SIP INFO embedding RTTI XML body
	SIP response (4xx, 5xx or 6xx), indicating an unsuccessful SIP RE-INVITE or SIP UPDATE (SCUR)
Debit / Reserve Units Request [Terminate]	SIP BYE message (both normal and abnormal session termination cases) (SCUR)
	SIP 2xx acknowledging a SIP BYE message (only when last user location information of originating/ terminating party is required by operator for legal purpose).
	SIP 2xx acknowledging non-session related SIP messages (ECUR)
	Aborting a SIP session set-up procedure, using an internal trigger, or a SIP CANCEL.(SCUR/ECUR)
	Deregistration (SCUR/ECUR)
	SIP Final/Redirection Response 3xx (SCUR/ECUR)
	SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session set-up procedure (SCUR)
	SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure (ECUR)
Debit Units Request [Event]	SIP NOTIFY (IEC)
	SIP MESSAGE (IEC)
	SIP REGISTER (IEC)
	SIP SUBSCRIBE (IEC)
	SIP REFER (IEC)
	SIP PUBLISH (IEC)
	SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure (IEC)

Table 5.3.1.2: Debit / Reserve Units Request messages triggered by SIP methods for MRFC

message	Triggering SIP Method
Debit / Reserve Units Request [Initial]	SIP INVITE(SCUR) for initiating a multimedia ad hoc conferencing session
Reserve Units Request [Update]	SIP RE-INVITE or SIP UPDATE[e.g. change in media components](SCUR)
	SIP BYE message
	Expiration of quota, Validity time expiry or other authorization triggers (quota threshold reached, …). (SCUR)
Debit / Reserve Units Request [Terminate]	SIP BYE message(both normal and abnormal session termination cases)(SCUR)
	SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing session(SCUR)
	SIP CANCEL(SCUR)

5.3.2 Message flows and types

5.3.2.0 Introduction

This clause describes the message flows for the event charging procedures on the Ro interface. The IMS functions providing online charging via the Ro interface are the S-CSCF with IMS GWF, the AS and the MRFC.

NOTE: The following sub-clauses only show the scenarios of the S-CSCF with IMS-GWF case and the AS case. The scenarios of the MRFC are FFS.

5.3.2.1 Immediate Event Charging (IEC)

5.3.2.1.0 Introduction

This clause provides the details of the "Debit Units" operation specified in TS 32.299 [50].

5.3.2.1.1 Message flows – successful cases and scenarios

5.3.2.1.1.1 IEC – Debit Units operation

The transactions that are required on the Ro interface in order to perform IEC with Debit Units operations are carried out as described in TS 32.299 [50] where CTF refers to IMS Network Element. The Debit Units operation may alternatively be carried out prior to, concurrently with or after service/content delivery. the IMS Network Element must ensure that the requested service execution is successful, when this scenario is used.

Editor’s Note: Must be aligned with TS 32.299 [50].

5.3.2.1.1.2 Scenarios

Figure 5.3.2.1.1.2.1 shows the Debit Units transactions that are required between the IMS-GWF/AS and the OCS for session-unrelated IMS procedures, i.e. those that relate to the Debit Units Request[event], as listed in table 5.3.1.1.

SIP messages and Charging Data transactions associated with these charging scenarios are shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive and depend on the Debit Units Request triggers configured by the operator.

Scenario 1: Successful session unrelated case

NOTE: The Debit Units operation is carried out prior to service/content delivery.

Figure 5.3.2.1.1.2.1: Message sequence chart for session-unrelated procedure

1) A session unrelated SIP request (e.g. SUBSCRIBE) is received in the S-CSCF. The S-CSCF forwards this request to the IMS-GWF/AS.

2) The IMS-GWF/AS sends a Debit Units Request[Event] to the OCS, requesting units in order to provide the service.

3) The OCS sends the Debit Units Response to acknowledge the Debit Units Request, granting the requested units.

4) The IMS-GWF/AS and the S-CSCF forward the SIP request.

5.3.2.1.2 Message flows – error cases and scenarios

5.3.2.1.2.0 Introduction

This clause describes various error cases and how these should be handled.

The failure handling behaviour is locally configurable in the IMS Network Element. If the Direct-Debiting-Failure-Handling AVP is not used, the locally configured values are used instead.

5.3.2.1.2.1 Reception of SIP error messages

If SIP errors in SIP response (4xx, 5xx or 6xx) occur during service delivery, as defined in TS 24.228 [202] and TS 23.218 [203], it is up to the IMS Network Element to determine to what extent the service was delivered before the error occurred and act appropriately with respect to charging. This may imply that no units at all (or no more units) are debited.

5.3.2.1.2.2 Debit Units operation failure

This case comprises situations where either no, or an erroneous response, is received from the OCS. The "no response" case is detected by the IMS Network Element when the connection supervision timer Tx expires (IETF RFC 4006 [402]) before a Debit / Reserve Units Response is received. The case of receiving an erroneous response implies that the IMS Network Element receives a Debit / Reserve Units Response, which it is unable to process, while Tx is running. The failure handling complies with the failure procedures for "Direct Debiting" scenario described in IETF RFC 4006 [402].

5.3.2.1.2.3 Duplicate detection

The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as possible the duplicate detection, the all-against-all record checking should be avoided and just those records marked as potential duplicates need to be checked against other received requests (within a reasonable time window) by the receiver entity.

The IMS Network Element marks the request messages that are retransmitted after a link failover as possible duplicates with the T-flag as described in TS 23.228 [201]. For optimized performance, uniqueness checking against other received requests is only necessary for those records marked with the T-flag received within a reasonable time window. This focused check is based on the inspection of the Session-Id and CC-Request-Number AVP pairs.

5.3.2.2 Event Charging with Unit Reservation (ECUR) and Session Charging with Unit Reservation (SCUR)

5.3.2.2.0 General

This clause provides the details of the "Reserve Units" and "Debit Units" operation specified in TS 32.299 [50].

5.3.2.2.1 Message flows – successful cases and scenarios

5.3.2.2.1.1 ECUR and SCUR – Reserve / Debit Units operations

The transactions that are required on the Ro interface in order to perform ECUR/SCUR with Reserve / Debit Units operations is carried out as described in TS 32.299 [50] where CTF refers to an IMS Network Element. Multiple replications of both of these operations are possible.

5.3.2.2.1.2 Expiration of reservation validity

This clause defines how reserved units are returned, if not used, within a reasonable time. It should be possible that both, reservation and SIP sessions are cancelled or only the reservation is cancelled without removing the SIP session.

5.3.2.2.1.3 Scenarios

5.3.2.2.1.3.0 Introduction

The following figures show the Reserve Units transactions that are required between the IMS-GWF/AS and the OCS for session-related and session-unrelated IMS procedures.

The SIP messages and Charging Data transactions associated with these charging scenarios are shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive and they depend on the Reserve Units Request triggers configured by the operator.

All of the scenarios depict originating sessions only.

5.3.2.2.1.3.1 Session related procedures (SCUR)

Scenario 1: Successful session establishment

Figure 5.3.2.2.1.3.1.1 shows the Reserve Units transactions that are required in the IMS-GWF/AS during a SIP session establishment.

Figure 5.3.2.2.1.3.1.1: Message sequence chart for successful session establishment

1) An initial SIP Invite Request is received in the S-CSCF. This request is forwarded to the IMS-GWF/AS.

2) The IMS-GWF/AS sends a Reserve Units Request[Initial] to the OCS requesting service units. The online Credit-Control session is initiated.

3) The OCS grants units in the Reserve Units Response.

4) The IMS-GWF/AS and S-CSCF forward the initial SIP INVITE.

5) A final response is received in the IMS-GWF/AS.

6) If the trigger is active, the SIP 200 OK answer triggers a Reserve Units Request[Update] in the IMS-GWF/AS in order to update the Credit-Control session. New service units are requested. Also the used service units (if any) are reported.

7) The OCS sends the Reserve Units Response to acknowledge the Reserve Units Request. New service units are granted.

8) The final answer is forwarded.

Scenario 2: Successful session establishment with early media negotiation

Figure 5.3.2.2.1.3.1.2 shows the Charging Data transactions that are required in the IMS-GWF/AS during a SIP session establishment in which SDP negotiation is completed before a final response to the initial SIP INVITE is exchanged.

Figure 5.3.2.2.1.3.1.2: Message sequence chart for session establishment with early media negotiation

1) An initial SDP offer is conveyed in a SIP INVITE message. The SIP INVITE message received in the S-CSCF is forwarded to the IMS-GWF/AS.

2) In this example, the SDP offer is conveyed in a SIP request which implies the start of the online Credit-Control session towards the OCS. The IMS-GWF/AS sends a Reserve Units Request[Initial] to the OCS requesting service units. The online Credit-Control session is initiated.

3) The OCS grants units in the Reserve Units Response.

4) The IMS-GWF/AS and S-CSCF forward the SIP request conveying the SDP offer.

5) A non-final SIP message (e.g. a provisional reliable response) conveying an SDP answer is received in the IMS-GWF/AS.

6) The received SDP answer triggers a Reserve Units Request[Update] in order to update the session. New service units are requested. Also the used service units (if any) are reported.

7) The OCS sends the Reserve Units Response to acknowledge the Reserve Units Request. New service units are granted.

8) The SDP answer is forwarded.

Scenario 3: Mid-session procedures

Figure 5.3.2.2.1.3.1.3 shows the Charging Data transactions that are required in the IMS-GWF/AS when receiving a SIP RE-iNVITE in mid-session, e.g. in order to modify media component(s), or when the hold and resume procedure is executed.

Figure 5.3.2.2.1.3.1.3: Message sequence chart for mid-session procedures

1) A SIP RE-INVITE request is received in the S-CSCF. This request is forwarded to the IMS-GWF/AS.

2) Upon receiving the SIP RE-INVITE request, the IMS-GWF/AS sends a Reserve Units Request[Update] to update the previously initiated session. New service units are requested. The used service units (if any) are also reported.

3) The OCS grants new service units in the Reserve Units Response.

4) The RE-INVITE request is forwarded.

5) The RE-INVITE request is acknowledged with a SIP 200 OK.

6) If the trigger is active, the IMS-GWF/AS sends a Reserve Units Request[Update] to the OCS to update the session. New service units are requested. The used service units (if any) are also reported.

7) The OCS grants new service units in the Reserve Units Response.

8) The SIP 200 OK message is forwarded.

Scenario 4: Session release

Figure 5.3.2.2.1.3.1.4 shows the Debit / Reserve Units operation that are required in the IMS-GWF/AS for a session release scenario with SIP BYE triggering online Credit-Control session termination.

Figure 5.3.2.2.1.3.1.4: Message sequence chart for session release (SIP BYE triggering Credit-Control session termination).

1) A SIP session is released by sending a SIP BYE message. The S-CSCF forwards this message to the IMS-GWF/AS.

2) Upon receiving the SIP BYE message, the IMS-GWF/AS forwards the SIP BYE request to the UE.

3) In case there is an ongoing online control session, the IMS-GWF/AS sends a Reserve Units Request[Terminate] reporting the used granted units.

4) The OCS sends a Reserve Units Response. The online Credit-Control session is terminated.

5) The final answer to the SIP BYE message is forwarded.

Figure 5.3.2.2.1.3.1.4A shows the Debit / Reserve Units operation that are required in the IMS-GWF/AS for a session release scenario with SIP 200 OK triggering online Credit-Control session termination.

Figure 5.3.2.2.1.3.1.4A: Message sequence chart for session release (SIP 200 OK triggering Credit-Control session termination).

1) A SIP session is released by receiving a SIP BYE message. The S-CSCF forwards this message to the IMS-GWF/AS.

2) Upon receiving the SIP BYE message, the IMS-GWF/AS forwards the SIP BYE request to the UE. In case there is an ongoing online control session, and the IMS-GWF/AS is configured to wait for SIP 200 OK acknowledging SIP BYE, the counter of used granted units is stopped.

3) The release is acknowledged by SIP 200 OK forwarded to the IMS-GWF/AS by the S-CSCF.

4) In case there is an ongoing online control session, the IMS-GWF/AS sends a Reserve Units Request [Terminate] reporting charging information (e.g. user location received in SIP 200 OK) together with the used granted units.

5) The OCS sends a Reserve Units Response. The online Credit-Control session is terminated.

6) The final SIP 200 OK answer to the SIP BYE message is forwarded.

Scenario 5: Successful session establishment with reception of RTTI message

Figure 5.3.2.2.1.3.1.5 shows the Debit / Reserve Units operationthat are required in the IMS-GWF/AS during a SIP session establishment when RTTI message is received embedded in the SIP 200 OK.

Figure 5.3.2.2.1.3.1.5: Message sequence chart for successful session establishment with reception of RTTI message

1) An initial SIP INVITE request is received in the S-CSCF. This request is forwarded to the IMS-GWF/AS.

2) The IMS-GWF/AS sends a Reserve Units Request[Initial] to the OCS requesting service units. The online Credit-Control session is initiated.

3) The OCS grants units in the Reserve Units Response.

4) The IMS-GWF/AS and S-CSCF forward the initial SIP INVITE.

5) A final response is received in the IMS-GWF/AS, which embeds a RTTI XML body.

6) If the trigger is active, the SIP 200 OK answer triggers a Reserve Units Request[Update] in the IMS-GWF/AS in order to update the session and take into account the RTTI XML body within the SIP 200 OK (see NOTE). New service units are requested. Also the used service units (if any) are reported.

7) The OCS sends the Reserve Units Response to acknowledge the Reserve Units Request. New service units are granted.

8) The final answer is forwarded.

NOTE: The mapping of RTTI XML body on Tariff Information structure is described in TS 32.280 [36].

5.3.2.2.1.3.2 Session unrelated procedures (ECUR)

Scenario 1: Successful session unrelated procedure

Figure 5.3.2.2.1.3.2.1shows the Debit / Reserve Units operation that are required in the IMS-GWF/AS for a session unrelated procedure.

Figure 5.3.2.2.1.3.2.1: Message sequence chart for session-unrelated procedures

1) A session unrelated SIP request (e.g. SIP SUBSCRIBE) is received in the S-CSCF. The S-CSCF forwards this request to the IMS-GWF/AS.

2) The IMS-GWF/AS sends a Reserve Units Request[Initial] to initiate a Credit-Control session. Service units are requested to the OCS.

3) The OCS grants service units in the Reserve Units Response.

4) The IMS-GWF/AS and the S-CSCF forward the SIP request

5) Depending on the used SIP method, there might be additional signalling between steps 4 and 5.

6) The SIP request is acknowledged by a SIP response.

7) The IMS-GWF/AS sends a Debit Units Request[Terminate] to the OCS. It also reports the used granted units.

8) The OCS sends a Debit Units Response to acknowledge the Debit Units Request. The online session is terminated.

9) The IMS-GWF/AS and S-CSCF forward the SIP response.

5.3.2.2.2 Message flows – error cases and scenarios

5.3.2.2.2.0 Introduction

This clause describes various error cases and how these should be handled.

The failure handling behaviour is locally configurable in the IMS Network Element. If Credit-Control-Failure-Handling AVP is not used, the locally configured values are used instead.

5.3.2.2.2.1 Reception of SIP error messages

If SIP errors occur during service delivery, as defined in [202] and [203], it is up to the IMS Network Element to determine to what extent the service was delivered before the error occurred and act appropriately with respect to charging. This may imply that no units at all (or no more units) are reserved or debited.

5.3.2.2.2.2 Debit / Reserve Units operation failure

The Debit / Reserve Units operation failure mechanism is specified in TS 32.299 [50] clause 6.3.6.2.

5.3.2.2.2.3 Duplicate detection

For Debit / Reserve Units operation duplicate detection is performed only for possible duplicate event requests related to IEC as mentioned in clause 5.3.2.1.2.3, as retransmission of ECUR/SCUR related Debit / Reserve Units Requests is not allowed.

5.3.2.2.2.4 Aborted session setup

If a trigger occurs during session establishment to release a session during the establishment procedure, the IMS Network Element shall initiate procedures to cancel the session establishment as defined in TS 24.229 [204].
On completion of the cancellation procedure, the IMS Network Element shall close the credit-control session (for SCUR and ECUR) indicating an appropriate cause code.

5.3.2.3 IMS service termination by OCS

5.3.2.3.0 Introduction

Annex B describes several scenarios related to IMS service termination.

NOTE: The annex B only shows the scenario of the S-CSCF with IMS-GWF case.

For IMS session related scenarios charged by means of SCUR in the IMS-GWF, service termination shall imply the rejection of a request for IMS session establishment or the release of an established session that is possibly associated to an online charging session.

For IMS session unrelated scenarios charged by means of ECUR in the IMS-GWF, Service Termination shall imply the rejection of the SIP method triggering the Reserve Units Request as defined in TS 32.299 [50].

For IMS session unrelated scenarios charged by means of IEC prior to service/content delivery in the IMS-GWF, service termination shall imply the rejection of the SIP method triggering the Debit Units Request as defined in TS 32.299 [50].

5.3.2.3.1 Triggers on Ro interface which imply the termination of the IMS service

The procedures in Ro interface which may trigger the IMS Service termination are the following:

– Reception of an unsuccessful Operation Result different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (TS 32.299 [50]) in the Debit / Reserve Units Response message.

– Reception of an unsuccessful Result Code different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (TS 32.299 [50]) within the multiple units operation in the Debit / Reserve Units Response message when only one instance of the multiple units operation field is used.

– Execution of the termination action procedure as defined in TS 32.299 [50] when only one instance of the Multiple Unit Operation field is used.

– Execution of the failure handling procedures when the Failure Action is set to ‘Terminate’ or ‘Retry & Terminate’.

Reception in the IMS-GWF of an Abort-Session-Request message from OCS.

In case either a Final-Unit-Indication or an erroneous Result-Code at multiple units operation level trigger the IMS service termination and the charging is based on ECUR or SCUR, the IMS-GWF shall close the online session by sending a Debit Units and Reserve Units operation of Type ‘Terminate’.

Refer to TS 32.299 [50] for a detailed description of these procedures.

5.3.2.3.2 Indication to the UE of the reason for IMS service release

As a result of service termination triggering in IMS-GWF, the IMS service shall be denied to end-users. The network should provide an indication to UEs of the reason the service has been released or rejected. The procedure shall depend on:

– The charged party.

The network should provide UEs with an indication of the reason the service has been released or rejected. However, this reason shall depend on whether the UE is the charged party or not. The premise is that only the charged party should know that the IMS service is being rejected / released because of OCS interaction.

– IMS specific protocol issues as defined in TS 24.229 [204].

A) In this scenario, the Response Code of the SIP response shall indicate the server understood the request but is refusing to fulfil it and that this request should not be repeated. The SIP response may include additional information about the cause to reject/release the IMS service. The presence of this additional error information in the response shall be operator configurable.

The additional information included in the SIP response may contain a SIP URI. The UE may treat the SIP URI as if it were a Contact in a redirect and generate a new SIP INVITE, resulting, for example, in a recorded announcement session being established. If announcement information is present in the Debit / Reserve Units Response message then a SIP URI should not be provided in the SIP response for redirection purposes.

B) The IMS-GWF generates a SIP request (e.g. SIP BYE or SIP CANCEL) as a result of the IMS Service Termination procedure:

In this scenario, the IMS-GWF may include a ‘Reason’ field in the request which provides additional information about the cause to reject/release the IMS service. The presence of this additional information in the request shall be operator configurable.

In both scenarios, it shall also be operator configurable both per SIP method and per Originating/Terminating side, the content of the additional error information sent to the UEs. This error information shall also be configurable based on the procedure in Ro interface which has triggered the release/rejection of the IMS service according to clause 5.3.2.3.1. In particular when the service termination is triggered by the reception of an unsuccessful operation result (different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE as defined in TS 32.299 [50]) in the Debit / Reserve Units Response message or the reception of an unsuccessful Result Code (different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE as defined in TS 32.299 [50]) within the multiple units operation in the Debit / Reserve Units Response message, the additional error information/reason shall also be configurable based on the Result Code received through Ro interface.