5.3.2 Diameter message flows

32.2753GPPCharging managementMultiMedia Telephony (MMTel) chargingRelease 17Telecommunication managementTS

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

5.3.2.0 Diameter message flows

The flows described in the present document specify the charging communications between the different CTF entities and the charging functions for different online charging scenarios. The SIP messages and Diameter transactions associated with these online charging scenarios are shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [221] and they depend on the Diameter Debit / Reserve Units Request triggers configured by the operator.

Each MMTel supplementary service is described by specific flows illustrating the dedicated trigger(s) for this MMTel supplementary service.

Following message flows are defined in TS 32.260 [20], and can be re-used for charging the basic multimedia telephony capabilities:

– Successful Session Establishment;

– Successful Session Establishment with Early Media Negotiation;

– Mid-Session Procedures;

– Session Release.

For OCS-provided announcement service during online charging session from the AS providing MMTel service for Session charging with Unit Reservation (SCUR), the message flows defined in TS 32.281 [41] apply.

5.3.2.1 Message flows – Successful cases and scenarios

5.3.2.1.0 Interaction with IMS-GWF

As an MMTel principle, when online charging has to be applied for an MMTel supplementary service, and the trigger list includes IMS-GWF together with MMTel AS (implementing the MMTel supplementary service), filter criteria should be configured to have the MMTel AS triggered before IMS-GWF, in order to prevent improper charging.

Figure 5.3.2.1.0.1 shows the Diameter transactions that are required between MMTel AS, IMS-GWF and OCS, when online charging is applied for MMTel supplementary service.

Figure 5.3.2.1.0.1: Message sequence chart for online charging – IMS-GWF, MMTel AS and OCS

1. User-A initiates a session by sending SIP INVITE request. Based on the Initial Filter Criteria (IFC) rules, indicating that User A is subscribed to the MMTel supplementary service X, the communication is forwarded to an AS implementing this service.

2-3. As "online charging" is activated for User A, the AS sends a Reserve Units Request [Initial, service X, ICID] to the OCS for requesting units for the X supplementary service. The OCS grants units in the Reserve Units Response response for this request.
The AS forwards SIP INVITE via the S-CSCF.

4. As "online charging" is activated for User A, IMS-GWF is triggered by the S-CSCF, and IMS-GWF sends a Reserve Units Request [Initial, ICID] to the OCS for requesting units for the session identified by ICID.

5-6. The OCS detects this request is within a session for which there is already an ongoing online Credit-Control Diameter session (same ICID). Based on operator policy the OCS can use either Credit_Control_not_applicable to supersede online charging in S-CSCF or grant appropriate service units (GSU).

5.3.2.1.1 Communications Diversion (CDIV)

5.3.2.1.1.1 Communications Diversion (CDIV) – successful establishment

Figure 5.3.2.1.1.1.1 shows the Diameter transactions that are required between AS implementing the CDIV service and OCS, when online charging is applied to a successful CFU communication.

Figure 5.3.2.1.1.1.1: Message sequence chart for online charging of CDIV service – establishment

A communication is requested towards User B: CFU and online-based charging activated for user B.

1. SIP INVITE request incoming for User B. Based on the iFC, indicating that User B is subscribed to the CDIV supplementary service, the communication is forwarded to AS implementing CDIV, where CFU is detected.

2. As the subscriber is "online charging", the AS sends a Reserve Units Request [Initial, service CDIV, ICID..] to the OCS for requesting units for the CDIV (CFU) supplementary service.

3. The OCS grants units in the Reserve Units Response response for this request.

4. The CDIV (CFU) can now be delivered: a SIP INVITE is sent towards user C via the S-CSCF. Any potential announcements to be played to the served party, provided by the OCS within the Reserve Units Response [Initial] , shall be discarded due to CDIV.

5-6. On answer from User-C (SIP 200 OK), the AS sends a Reserve Units Request [Update, USU] with possible already used units and requests new units to continue.

7. New units are granted via Reserve Units Response and the SIP 200 OK is propagated. Any potential announcements to be played to the served party, provided by the OCS within the Reserve Units Response, shall be discarded due to CDIV.

5.3.2.1.1.2 Communications Diversion (CDIV) – release

Figure 5.3.2.1.1.2.1 shows the Diameter transactions occurring on release of the previous established communication, initiated by user C:

Figure 5.3.2.1.1.2.1: Message sequence chart for offline charging of CDIV service -release

1. User C initiates release of the communication.

2. At session termination the AS implementing the CDIV service, sends a Debit Units Request [Terminate, used service units] for ending Credit-Control.

5.3.2.1.2 Flexible Alerting (FA)

Figure 5.3.2.1.2.1 shows the Diameter transactions that are required between AS implementing the FA service and OCS, when online charging is applied to a successful FA communication.

Figure 5.3.2.1.2.1: Message sequence chart for online charging of FA service

UE-B and UE-C are FA group members of the FA group identified by the "Pilot Identity".

A communication is requested from UE-A towards the "Pilot Identity".

1. SIP INVITE request incoming for "Pilot Identity". Based on the Initial Filter Criteria (IFC), indicating the request must be forwarded to an AS implementing FA for this "Pilot Identity".

2. As "online charging" is activated for the "Pilot Identity", the AS implementing FA has to initiate parallel SIP INVITE towards each of FA group members.

3. For FA member User B, the AS sends a Reserve Units Request [Initial, service FA, ICID-B] to the OCS for requesting units for the FA supplementary service.

4. The OCS grants units in the Reserve Units Response response for this request.

5. SIP INVITE is sent towards User B via the S-CSCF.

6. Alerting phase signalling occurs with UE-A.

7. A parallel (from step 3 to step 6) scenario occurs towards User-C with session identified by ICID-C.

8-9. Upon reception of the SIP 200 OK answer from UE-C, AS sends SIP CANCEL to other FA group member being alerted (UE-B).

10. More signalling for SIP CANCEL transactions.

11-13. When the last SIP CANCEL transaction is terminated, AS sends a Reserve Units Request [Update, USU] with possible already used units, and requests new units to continue the communication between User A and User C.

14. New units are granted via Reserve Units Response.

15. SIP 200 OK is propagated towards User A.

During AS FA supplementary service execution and interaction with OCS, announcements to be played to the served party may be provided by the OCS within Reserve Units Responses [Initial/Update]. Announcement procedures handling by the AS are those specified in TS 32.281 [41].

5.3.2.1.3 Closed User Group (CUG)

5.3.2.1.3.1 Closed User Group (CUG): Originating

Figure 5.3.2.1.3.1.1 shows the Diameter transactions that are required between AS implementing the CUG service and OCS, when online charging is applied to a successful originating communication from User-A CUG member.

Figure 5.3.2.1.3.1.1: Message sequence chart for online charging of CUG service – originating call

User-A is subscribed to CUG service, and initiates a communication towards User B.

1. User-A initiates a communication towards User B sending SIP INVITE request. Based on the Initial Filter Criteria (IFC) rules, indicating that User A is subscribed to the CUG supplementary service, the communication is forwarded to an AS implementing CUG.

2. AS performs checks from the request received regarding User A CUG subscription profile, and determines the CUG-communication is allowed for CUG member User-A towards User-B.

3-4. As "online charging" is activated for User A, the AS sends a Reserve Units Request [Initial, service CUG, ICID] to the OCS for requesting units for the CUG supplementary service. The OCS grants units in the Reserve Units Response response for this request.
The AS forwards SIP INVITE via the S-CSCF towards User-B with CUG information included.

NOTE: In case the result from AS checks indicates non-CUG communication behaviour (for CUG communication with outgoing access…), non-CUG communication charging applies, and CUG information is not included in the forwarded SIP INVITE.

5. SIP signalling for communication establishment.

6-8. SIP 200 OK answer received from User B, and AS sends a Reserve Units Request [Update, USU] with possible already used units, and requests new units to continue the CUG communication between User A and User B. New units are granted via Reserve Units Response, and SIP 200 OK is propagated towards User A.

During AS CUG supplementary service execution and interaction with OCS, announcements to be played to the served party may be provided by the OCS within Reserve Units Responses [Initial/Update]. Announcement procedures handling by the AS are those specified in TS 32.281 [41].

5.3.2.1.3.2 Closed User Group (CUG): Terminating

Figure 5.3.2.1.3.2.1 shows the Diameter transactions that are required between AS implementing the CUG service and OCS, when online charging is applied to a successful terminating communication towards User-B CUG member.

Figure 5.3.2.1.3.2.1: Message sequence chart for online charging of CUG service – terminating call

User-B is subscribed to CUG service.

1. Incoming SIP INVITE request with CUG information towards User-B.Based on the Initial Filter Criteria (IFC) rules, indicating that User B is subscribed to the CUG supplementary services, the communication is forwarded to an AS implementing CUG.

2. AS performs checks from the request received regarding User B CUG subscription profile, and determines the CUG-communication is allowed for CUG member User-B from User A.

3-4. As "online charging" is activated for User B, the AS sends a Reserve Units Request [Initial, service CUG, ICID] to the OCS for requesting units for the CUG supplementary service.The OCS grants units in the Reserve Units Response response for this request. The AS forwards SIP INVITE via the S-CSCF towards User-B.

NOTE: In case the result from AS checks indicates non-CUG communication behaviour (incoming access from non-CUG member…), non-CUG communication charging applies.

5. SIP signalling for communication establishment.

6-8. SIP 200 OK answer received from User B, and AS sends a Reserve Units Request [Update, USU] with possible already used units, and requests new units to continue the CUG communication between User B and User A. New units are granted via Reserve Units Response, and SIP 200 OK is propagated towards User A.

5.3.2.1.4 Conference (CONF)

5.3.2.1.4.0 Introduction

Figure 5.3.2.1.4.1.1 to figure 5.3.2.1.4.5.1 show the Diameter transactions that are required between AS implementing the CONF service and OCS, when online charging is applied to different conference scenarios.

For CONF service, two different set of scenarios are provided for illustrating the situation where ECUR or SCUR apply, depending on operator’s policy.

5.3.2.1.4.1 CONF – user creating a conference – ECUR mode

Figure 5.3.2.1.4.1.1: Message sequence chart for online charging of CONF service- User creating a conference – ECUR mode

1. User-A initiates a conference by sending an SIP INVITE request to S-CSCF. Based on the Initial Filter Criteria (IFC) rules, indicating that User A is subscribed to the CONF supplementary service, the communication is forwarded to an AS implementing CONF.

2. The CONF AS allocates the conference resource.

3-4. As "online charging" is activated, the AS sends a Reserve Units Request [Initial, service CONF, creation] to the OCS for requesting units for the CONF supplementary service creation.
The OCS grants units in the Reserve Units Response response for this request.

5. Media resource negociation process.

6-7. The AS (CONF) sends a SIP 200 OK response replied by SIP ACK from UE-A.

8-9. On successful service delivery, AS (CONF) sends Reserve Units Request [Terminate, USU] for ending Credit-Control, with granted units used for CONF creation.

5.3.2.1.4.2 CONF – user creating a conference – SCUR mode

Figure 5.3.2.1.4.2.1: Message sequence chart for online charging of CONF service- User creating a conference – SCUR mode

2. The CONF AS allocates the conference resource.

5. Media resource negociation process.

6-7. The AS (CONF) sends a SIP 200 OK response replied by ACK from UE-A.

8-9. As CONF charging is based on duration or other CONF parameters, from start of the service on step 7), new units are subsequently requested by sending Reserve Units Request [Update, USU]with already used units, for continuing the service when new CONF parameters or values are provided.

During AS CONF supplementary service execution and interaction with OCS, announcements to be played to the served party may be provided by the OCS within Reserve Units Responses [Initial/Update]. Announcement procedures handling by the AS are those specified in TS 32.281 [41].

5.3.2.1.4.3 CONF – user joining a conference (SCUR mode)

Figure 5.3.2.1.4.3.1: Message sequence chart for online charging of CONF service- User joining a conference – SCUR mode

1. The conference has already been created by User A. User-B sends an SIP INVITE request to S-CSCF in order to join in the conference identified by the conference URI. The communication is forwarded to AS addressed by conference URI.

2. Media resource negociation process for adding UE-B to the conference.

3-4. The AS (CONF) sends a SIP 200 OK response replied by SIP ACK from UE-B.

5-6. This step applies for SCUR mode, when "Nb of participants" is needed for the "online charging" running for this conference: the AS (CONF) sends a Reserve Units Request [Update, USU]) with possible already used units, for requesting new units with new number of participants. The OCS grants units in the Reserve Units Response response for this request.

The OCS may provide announcements to be played to the served party UE-A within Reserve Units Response [Update]. Announcement procedures handling by the AS are those specified in TS 32.281 [41].

5.3.2.1.4.4 CONF – user inviting another user to a conference (SCUR mode)

Figure 5.3.2.1.4.4.1: Message sequence chart for online charging of CONF service – user inviting another user to a conference – SCUR mode

1. The conference has already been created by User A. User A sends aSIP REFER request to S-CSCF with the conference URI in order to invite User B into the conference. The communication is forwarded to the AS addressed by conference URI.

2-4. Sequence between UE-A and AS (CONF) to proceed the SIP REFER (accept, SIP NOTIFY…).

5. User B is invited to the Conference by SIP INVITE from AS (CONF).

6. Media resource negociation process for adding UE-B to the conference.

7-8. UE-B sends SIP 200 OK response when he joins the conf, replied by ACK from AS (CONF).

9-10. This step applies for SCUR mode, when "Nb of participants" is needed for the "online charging" running for this conference: the AS (CONF) sends a Reserve Units Request [Update, USU] with possible already used units, for requesting new units with new number of participants. The OCS grants units in the Reserve Units Response response for this request.

The OCS may provide announcements to be played to the served party UE-A within Reserve Units Response [Update]. Announcement procedures handling by the AS are those specified in TS 32.281 [41].

5.3.2.1.4.5 CONF – user leaving a conference (SCUR mode)

Figure 5.3.2.1.4.5.1: Message sequence chart for online charging of CONF service – user leaving a conference SCUR mode

1. The conference has already been created. User B sends a SIP BYE request request to the AS (CONF) in order to quit the conference.The communication is forwarded to the AS addressed by conference URI.

2-3. This step applies for SCUR mode:

– In case "Nb of participants" is needed for the "online charging" running for this conference, and UE-B leaving does not cause conference termination: the AS (CONF) sends a Reserve Units Request [Update, USU] with possible already used units, for requesting new units with new number of participants. The OCS grants units in the Reserve Units Response response for this request.

– In case UE-B leaving does cause conference termination, the AS(CONF) sends a Reserve Units Request [Terminate, USU] with used units, for ending Credit-Control.

4. The AS (CONF) sends back SIP 200 OK response to UE-B.

5-6. The AS (CONF) sends a SIP NOTIFY request to UE-B for unsubscribe UE-B to conf event package, replied by SIP 200 OK from UE-B.

7. This step does not apply if conference has terminated:
Other conference participants are Notified UE-B has quit the conference.

5.3.2.1.4.6 CONF (3PTY) – successful establishment

Figure 5.3.2.1.4.6.1 shows the Diameter transactions that are required between AS implementing the CONF (3PTY) service and OCS, when online charging is applied to a successful 3PTY conference scenario.

Figure 5.3.2.1.4.6.1: Message sequence chart for online charging of CONF (3PTY) service – establishment

1. UE-A and UE-B have established communication. UE-A puts UE-B on hold.Before invoking the 3-Way Calling UE-A establishes a communication with UE-C.

2. UE-A sends an SIP INVITE request to the AS (CONF) to establish a 3PTY session.

3-4. As "online charging" is activated, the AS (CONF) sends a Reserve Units Request [Initial, service CONF (3PTY)] to the OCS for requesting units for the service.The OCS grants units in the Reserve Units Response response for this request.

5-6. The AS (CONF) sends a SIP 200 OK response replied by SIP ACK from UE-A.

7. UE-A sends a SIP REFER request to UE-B with the Refer-To header set to the address of the AS (CONF).

8. Sequence for 3PTY establishment:

– SIP REFER sequence (accept, SIP NOTIFY…) between UE-B and UE-A.

– SIP INVITE from UE-B sequence for joining

– Original communication UE-A UE-B sequence termination

– SIP REFER sequence (accept, SIP NOTIFY…) between UE-A and UE-C.

9-11. SIP INVITE from UE-C sequence for joining the CONF (3PTY)

12-13. In case ECUR mode applies to CONF (3PTY) Charging, on SIP ACK receipt, AS (CONF) sends Reserve Units Request [Terminate, USU] for ending Credit-Control, with granted units used for 3PTYcreation.

In case SCUR mode applies to CONF (3PTY) charging (charging to be based on duration or other parameters), from ACK receipt, new units are subsequently requested by sending Reserve Units Request [Update, USU] with already used units, for continuing the service when new CONF parameters or values have are provided.

14. Original communication UE-A UE-C sequence termination, occuring at any time from step 11.

During AS CONF (3PTY) supplementary service execution and interaction with OCS, announcements to be played to the served party may be provided by the OCS within Reserve Units Responses [Initial/Update]. Announcement procedures handling by the AS are those specified in TS 32.281 [41].

5.3.2.1.5 Explicit Communication transfer (ECT)

5.3.2.1.5.0 Introduction

Figure 5.3.2.1.5.1.1 and figure 5.3.2.1.5.1.2 show the Diameter transactions that are required between ASimplementing the ECT service and OCS, when online charging is applied to a successful Blind Transfert from User A to User C, initiated by User B.

For diagram simplification, only one OCS is shown.

5.3.2.1.5.1 Explicit Communication transfer (ECT): Blind Transfer with sending SIP REFER

Figure 5.3.2.1.5.1.1: Message sequence chart for online charging of ECT service establishment – Blind Transfer (part 1)

Figure 5.3.2.1.5.1.2: Message sequence chart for online charging of ECT service establishment – Blind Transfer (part 2)

In this scenario User A is the transferee, User B is the transferor, and User C is the transfer target.

User A and User B are in an established communication, User B puts User A on Hold.

1. User B sends SIP REFER request in the existing A-B dialog, to initiate transfer User A to User C. Based on the iFC, indicating that User B is subscribed to the ECT supplementary service, the communication is forwarded to AS implementing ECT.

2-3. As "online charging" is activated, the AS sends a Reserve Units Request [Initial, service ECT] to the OCS for requesting units for the ECT supplementary service. The OCS grants units in the Reserve Units Response response for this request. The AS generates an "ECT Session Identifier" replacing User C as the new destination information and forwards SIP REFER towards User A. Any potential announcements to be played to the transferor, provided by the OCS within the Reserve Units Response [Initial], and subsequent Reserve Units Responses [Update], shall be discarded due to ECT.

4-5. As "online charging" is activated for User A, the AS sends a Reserve Units Request [Initial, service ECT] to the OCS for requesting units for the ECT supplementary service for the transferee. The OCS grants units in the Reserve Units Response response for this request. The AS forwards SIP REFER towards User-A. Any potential announcements to be played to the transferee, provided by the OCS within the Reserve Units Response [Initial], shall be discarded due to ECT.

6. More signalling between (User A, x-CSCF, AS-A) and (x-CSCF, AS-B,User B) for SIP REFER acceptation sequence and terminating previous media between User A and User B.

7. User A initiates a new session by sending an SIP INVITE request with "ECT Session Identifier".

8-9. AS implementing the ECT service for the transferee correlates this SIP INVITE to the transfer being processed, and new units are requested by sending Reserve Units Request [Update, USU] with already used units, for continuing the service. The AS forwards SIP INVITE request. Any potential announcements to be played to the transferee may be provided by the OCS within Reserve Units Responses [Update]. Announcement procedures handling by the AS are those specified in TS 32.281 [41].

10-11. AS implementing the ECT service for the transferor correlates this SIP INVITE to the initial session to be transferred and new units are requested by sending Reserve Units Request [Update, USU] with already used units, for continuing the service, prior to forwarding SIP INVITE towards UE-C.

12. The destination User C party answers, and a final response is received.

13-14. On transfer execution, the AS sends a Reserve Units Request [Update, USU] with possible already used units and requests new units for transferor to continue.

15-16. On transfer execution, the AS sends a Reserve Units Request [Update, USU] with possible already used units and requests new units for transferee to continue.

NOTE 1: For "Consultative Transfer" scenario, the same steps apply for interactions with OCS for transferee and transferor: Reserve Units Request [Initial] on SIP REFER initiating, intermediate Reserve Units Request [Update] for more units on SIP INVITE for new session, and Reserve Units Request [Update] for more units on transfer execution when User C answers.

NOTE 2: For "Assured Transfer" scenario, the same steps apply for interactions with OCS for transferee and transferor: Reserve Units Request [Initial] on SIP REFER initiating, intermediate Reserve Units Request [Update] for more units on SIP INVITE for new session, and Reserve Units Request [Update] for more units on transfer execution when User C answers.Besides, Reserve Units Request [Terminate] on transferring timeout or failure, and Reserve Units Request [Update] for more units on original dialog retrievemet.

5.3.2.1.5.2 Explicit Communication transfer (ECT): Blind Transfer with 3PCC

Figure 5.3.2.1.5.2.1: Message sequence chart for online charging of ECT service establishment – Blind Transfer with 3PCC

In this scenario User A is the transferee, User B is the transferor, and User C is the transfer target, and the User B’s AS acts as a 3PCC (Third Party Call Control) initiating B2BUA:

User A and User B are in an established communication, User B puts User A on Hold.

2-3. As "online charging" is activated, the AS sends a Reserve Units Request [Initial, service ECT] to the OCS for requesting units for the ECT supplementary service. The OCS grants units in the Reserve Units Response response for this request. Any potential announcements to be played to the transferor, provided by the OCS within the Reserve Units Response [Initial], and subsequent Reserve Units Responses [Update], shall be discarded due to ECT.

4-5. AS B performs the SIP REFER procedure with User B, and sends SIP INVITE towards User C.

6-8. On Provisionnal response from User C, the AS sends a Reserve Units Request [Update, USU] with possible already used units and requests new units for transferor to continue.

9. AS B sends SIP Re-INVITE towards User A on existing dialog. From User A side, the basic SIP RE-INVITE procedure applies (ECT service not invoked).

10-13. On SIP 200 OK response from User A, the AS sends a Reserve Units Request [Update, USU] with possible already used units and requests new units for transferor to continue, and sends ACK back to User A.

14-16. On SIP 200 OK response from User C, the AS sends a Reserve Units Request [Update, USU] with possible already used units and requests new units for transferred communication to continue.

5.3.2.1.5.3 Explicit Communication transfer (ECT): Release

Figure 5.3.2.1.5.3.1 shows the Diameter transactions that are required between ASs implementing the ECT service for the transferor and for the transferee, and OCS: release from User A, after a successful Blind Transfer from User A to User C, initiated by User B.

Figure 5.3.2.1.5.3.1: Message sequence chart for offline charging of ECT service – release

1. User A initiates release of the communication.

2-3. At session termination the AS implementing the ECT service for the transferee, sends a Reserve Units Request [Terminate, USU] with used units, for ending Credit-Control.

4-5. At session termination the AS implementing the ECT service for the transferor, sends a Reserve Units Request [Terminate, USU] with used units, for ending Credit-Control.

NOTE: For "Blind Transfer with 3PCC" release scenario, only interactions between AS-B and OCS apply for ECT service.

5.3.2.2 Message flows – error cases and scenarios

Error cases and scenarios for SIP related procedures and Diameter related procedures used for MMTel service and Supplementary services charging are defined in TS 32.260 [20].