5.2.2 Diameter message flows

32.2753GPPCharging managementMultiMedia Telephony (MMTel) chargingRelease 17Telecommunication managementTS

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

5.2.2.0 Introduction

The flows described in the present document specify the charging communications between the different CTF entities and the charging functions for different charging scenarios. The SIP messages and Diameter 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 of all the SIP message flows discussed in TS 24.228 [221] and they depend on the Diameter Charging Data Requests triggers configured by the operator.

Although each MMTel supplementary service is described by separated flows illustrating the dedicated trigger(s) for this MMTel supplementary service, the Diameter Charging Data Request triggers (as stated in 5.2.1), may be configured with several MMtel supplementary services information.

5.2.2.1 Message flows – Successful cases and scenarios

5.2.2.1.0 Introduction

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

– Session Establishment – IMS Origination;

– Session Establishment- IMS Termination;

– Mid-Session Procedures;

– Session Release – Mobile Initiated.

5.2.2.1.1 Originating Identification Presentation (OIP) charging

Figure 5.2.2.1.1.1 shows the Diameter transactions that are required between AS and CDF, which implements the OIP service, and CDF after service execution.

Figure 5.2.2.1.1.1: Message sequence chart for offline charging of OIP service

5.2.2.1.2 Originating Identification Restriction (OIR) charging

Figure 5.2.2.1.2.1 shows the Diameter transactions that are required between AS and CDF, which implements the OIR service, and CDF after service execution.

Figure 5.2.2.1.2.1: Message sequence chart for offline charging of OIR service

5.2.2.1.3 Terminating Identification Presentation (TIP) charging

Figure 5.2.2.1.3.1 shows the Diameter transactions that are required between AS and CDF, which implements the TIP service, and CDF after service execution.

Figure 5.2.2.1.3.1: Message sequence chart for offline charging of TIP service

5.2.2.1.4 Terminating Identification Restriction (TIR) charging

Figure 5.2.2.1.4.1 shows the Diameter transactions that are required between AS and CDF, which implements the TIR service, and CDF after service execution.

Figure 5.2.2.1.4.1: Message sequence chart for offline charging of TIR service

5.2.2.1.5 Communication Hold (HOLD) charging

Figure 5.2.2.1.5.1 shows the Diameter transactions that are required between AS which implements the HOLD service, and CDF after service execution. The involvement of the AS is optional as it is involved to the HOLD service provision only for announcement purposes.

Figure 5.2.2.1.5.1: Message sequence chart for offline charging of HOLD service

NOTE: Based on TS 24.610 [207] a scenarion triggerted by Re-Invite is also possible.

5.2.2.1.6 Communication Barring – CB (ICB/ACB) charging

5.2.2.1.6.1 Communication Barring (CB) – ICB and Charging Data Request

Figure 5.2.2.1.6.1.1 shows the Diameter transactions that are required between AS and CDF, which implements the CB service, and CDF after service execution.

Figure 5.2.2.1.6.1.1: Message sequence chart for offline charging of CB service

5.2.2.1.6.2 Communication Barring (CB) – OCB

Figure 5.2.2.1.6.2.1 shows the Diameter transactions that are required between AS and CDF, which implements the CB service, and CDF after service execution.

Figure 5.2.2.1.6.2.1: Message sequence chart for offline charging of CB service

5.2.2.1.7 Communications Diversion (CDIV) charging

5.2.2.1.7.1 Communications Diversion (CDIV) – successful establishment

Figure 5.2.2.1.7.1.1 shows the Diameter transactions that are required between AS,implementing the CDIV service and CDF for a successful communication forwarding on no reply.

Figure 5.2.2.1.7.1.1 : Message sequence chart for offline charging of CDIV service – establishment

A communication is requested towards User B, user B has activated the CFNR

1. SIP INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) rules, indicating that User B is subscribed to the CDIV supplementary services, the communication is forwarded to an AS implementing AS implementing CDIV. Then SIP INVITE is forwarded to User B.

2. 180 ringing is sent back from User B.

3. The non-reply timer in the AS is started .

4. The timer expires.

5 to 7. The AS implementing the CDIV service performs the Call Forwarding No Reply logic: release the communication to User B, and forward the call towards user C (SIP INVITE request including URI-C as destination).

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

9. Upon reception of the final response, the AS implementing the CDIV service sends a Charging Data Request [Start/Event] to record call forwarding execution (start of the forwarded leg from User B to User C): basic communication information are transferred with specific call forwarding information (service mode= "CFNR", associated number = " user B" as the user who invoked the call forwarding).

10. The CDF acknowledges the reception of the data and opens/creates an AS CDR to record the forwarded leg from User B to User C.

NOTE : Although only the "call forwarding on no reply" case is depicted here , it serves as a basis for all other call forwarding modes description (Call Forwarding Unconditional, Call Deflection, Call Forwarding on Busy, Call Forwarding Not Logged-in ) for Charging Data Request generation : In all these cases, the AS AS implementing the CDIV service sends a Charging Data Request [Start] to record call forwarding execution (whatever the mode), when the final response is received from user-C.

5.2.2.1.7.2 Communications Diversion (CDIV) – release

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

Figure 5.2.2.1.7.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 Charging Data Request [Stop] to record stop the call for which User B has been forwarded.
The AS CDR is closed.

5.2.2.1.8 Communication Waiting (CW) charging

Figure 5.2.2.1.8.1 shows the Diameter transactions that are required between AS, which implements the CW service and CDF for the callee (subscriber of CW).

Figure 5.2.2.1.8.1: Message sequence chart for offline charging of CW service

1-2. The communication is initiated by UE-A by sending an SIP INVITE request. The Request URI includes the URI of UE-B. After IFC evaluation in the S-CSCF the SIP INVITE request is routed to the CW AS.

2a. The AS detects the CW condition and inserts a CW indication into the SIP INVITE request per procedures.

3-4. The SIP INVITE is routed to UE-B.

5. UE-B recognizes the CW indication per procedures.

6. UE-B sends back a 180 (Ringing) response.

6a. Out of scope: user B uses the HOLD service or releases a session in order to free resources.

7-8. The SIP 180 (Ringing) response is routed back to the AS.

8a. The AS optionally inserts a Alert-Info with a ‘CW’ URN into the 180 (Ringing) response.

9-10.The SIP 180 (Ringing) response is routed back to the communication origin.

9a. The AS may initiate an announcement to the calling user that the communication is a waiting communication, in accordance with TS 24.628 [4].]

11-14. UE-B sends back a SIP 200 (OK) response to the CW AS and CW AS sends it to the S-CSCF.

15-17. The CW AS sends a Charging Data Request [Start]/ Charging Data Request [Event] to CDF, then the CDF opens/creates an AS CDR for the Communication Waiting with CW indication on the AS CDR and returns Charging Data Response to the CW AS.

18. S-CSCF sends back a SIP 200(OK) response to UE-A.

5.2.2.1.9 Explicit Communication transfer (ECT) charging

5.2.2.1.9.1 Explicit Communication transfer (ECT): Blind Transfer

Figure 5.2.2.1.9.1.1 and figure 5.2.2.1.9.1.2 show the Diameter transactions that are required between ASs implementing the ECT service (for the transferor and for the transferee) and CDF: a successful Blind Transfert from User A to User C, initiated by User B.

For diagram simplification, only one CDF is shown.

Figure 5.2.2.1.9.1.1: Message sequence chart for offline charging of ECT service –
Blind Transfer (part1)

Figure 5.2.2.1.9.1.2: Message sequence chart for offline charging of ECT service –
Blind Transfert (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 for which, based on the Initial Filter Criteria (IFC) rules indicating that User B is subscribed to the ECT supplementary service, the SIP INVITE was forwarded to an AS implementing ECT (for User A and User B).

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.

2. this subsequent request is forwarded to the AS implementing ECT.

3. AS generates an "ECT Session Identifier" replacing User C as the new destination information, for remaining in the loop, for transferor’s role.

4. On SIP REFER receipt, this request is forwarded the AS implementing ECT.

5. The SIP REFER is accepted by User A, and 202 Accepted is transferred from User A to User B.

6-9. User B sends SIP BYE for terminating original SIP INVITE with User A, acknowledged by SIP 200 OK from User A.
AS B releases the media between User A and User B which are on hold, then sends a Charging Data Request [Stop] to record termination of the dialogue between User A and User B.

10. More signalling between (User A,x-CSCF,AS-A ) and (x-CSCF,AS-B,User B) : User A sends SIP NOTIFY(100 Trying) associated to the received REFER, and User B acknowledges by SIP 200 OK..

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

12. AS implementing the ECT service correlates this SIP INVITE to the initial session to be transferred and replaces "ECT Session Identifier" with User C for creating an SIP INVITE towards UE-C.

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

14. Upon reception of the final response, the AS implementing the ECT service for the transferor, sends a Charging Data Request [Start] to record Transfer execution.

15. The CDF acknowledges the reception of the data and opens/creates an AS CDR.

16. Upon reception of the final response, the AS implementing the ECT service for the transferee, sends a Charging Data Request [Start] to record User A is transferred, with specific indicator of whether the transferee was engaged in an originating call or in a terminating call before the transfer execution.

17. The CDF acknowledges the reception of the data and opens/creates an AS CDR.

NOTE 1: The "Consultative transfer" scenario mainly differs from the "Blind transfer" on the transfer establishment phase : when User B has put User A on Hold, User B establishes a communication towards User C and puts User C on Hold, then User B initiates the SIP REFER for the transfer triggering. The Charging Data Request [Start] for recording Transfer execution occurs at the same steps for both scenarios: on the final response associated to SIP INVITE towards User C for the transferor and for the transferee.

NOTE 2: The "Assured transfer" scenario mainly differs from the "Blind transfer" on the transfer establishment phase: User B may include an Expires header field in the Refer-To URI of the SIP REFER request when initiating transfer. If User B has not received a SIP NOTIFY request indicating the end of the transfer operation within the duration of the Expires header allow or received a SIP NOTIFY indicating that the Assured transfer attempt failed, User B may request to terminate the transfer attempt by sending a SIP REFER request in the original communications dialog. Then User B may decide to retrieve the original communication by sending a SIP re-INVITE message in the original SIP dialog.
A Charging Data Request [Event] when the termination SIP NOTIFY is send out.
A Charging Data Request [Interim] when the retrieving SIP re-INVITE is sent out.

5.2.2.1.9.2 Explicit Communication transfer (ECT): Release

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

Figure 5.2.2.1.9.2.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 Charging Data Request [Stop] to record stop the call for which User A has been transferred.

4-5. At session termination the AS implementing the ECT service for the transferor, sends a Charging Data Request [Stop] to record stop the call transferred by User B. The AS CDR is closed.

5.2.2.1.10 Message Waiting Indication (MWI) charging

Figure 5.2.2.1.10.1 shows the Diameter transactions that are required between AS (MWI), which implements the MWI service and CDF.

Figure 5.2.2.1.10.1: Message sequence chart for offline charging of MWI service

1-6. UE subscribes to AS (MWI) and the AS (MWI) returns SIP 200 OK.

7-10. The AS (MWI) sends SIP NOTIFY request to S-CSCF and the subscriber UE acknowledges the SIP NOTIFY request.

11-13. The AS (MWI) sends Charging Data Request [Event] message to CDF, CDF creates an AS CDR and returns Charging Data Responseto the AS (MWI).

5.2.2.1.11 Conderence (CONF) Charging

5.2.2.1.11.0 Introduction

During a conference, the user could create the conference, join a conference, invite another user to the conference and leave the conference, according to TS 24.605 [203]. The following subclauses respectively show the Diameter transactions that are required between AS, which implements the CONF service and CDF corresponding different conference scenarios.

5.2.2.1.11.1 CONF charging – user creating a conference

Figure 5.2.2.1.11.1.1 : Message sequence chart for offline charging of CONF service –
User creating a conference

1-2. The communication is initiated by UE#1 by sending an SIP INVITE request to S-CSCF. And S-CSCF sends back 100 Trying reponse to inform UE#1 to wait for a while because the request is being treated.

3-4. S-CSCF transfers SIP INVITE request from UE#1 to CONF AS and the CONF AS sends back 100 Trying response to inform S-CSCF to wait for a while because the request is being treated.

5. The CONF AS allocates the conference URI.

6-16. After the media resource negociation process, the CONF AS sends back SIP 200 OK response.

17-19. The CONF AS sends Charging Data Request [Start]/Charging Data Request [Event] to CDF, then the CDF opens/creates an AS CDR for the conference with CONF indication on the AS CDR and returns Charging Data Response to the CONF AS.

5.2.2.1.11.2 CONF charging – user joining a conference

5.2.2.1.11.2.1 shows the Diameter transactions that are required between AS, which implements the CONF service and CDF corresponding to the conference scenario: user joining a conference.

Figure 5.2.2.1.11.2.1: CONF charging – user joining a conference

1-2. The conference has already been created. UE#1 sends an SIP INVITE request to S-CSCF in order to join in the conference. And S-CSCF sends back SIP 100 Trying reponse to inform UE#1 to wait for a while because the request is being treated.

3-4. S-CSCF transfers SIP INVITE request from UE#1 to CONF AS and the CONF AS sends back SIP 100 Trying response to inform S-CSCF to wait for a while because the request is being treated.

5-15. After the media resource negociation process, the CONF AS sends back SIP 200 OK response.

16-18. The CONF AS sends Charging Data Request [Interim/Event] to CDF, CDF updates or creates an AS CDR for the conference and returns Charging Data Response to the CONF AS.

5.2.2.1.11.3 CONF charging – user inviting another user to a conference

Figure: 5.2.2.1.11.3.1 shows the Diameter transactions that are required between AS, which implements the CONF service and CDF corresponding to the conference scenario: user being invited into a conference.

Figure5.2.2.1.11.3.1: CONF charging – user inviting another user to a conference

1-2. The conference has already been created. UE#1 sends a SIP REFER request to S-CSCF in order to invite UE#2 into the conference.

3-4. The CONF AS sends back 202 Accepted response to UE#1 via some related NEs like S-CSCF to indicate that he has received the SIP REFER request successfully.

5-6. The CONF AS sends a SIP NOTIFY request corresponding the SIP REFER request to UE#1.

7-8. UE#1 sends back SIP 200 OK reponse to the CONF AS.

9-10. The CONF AS sends an SIP INVITE request to UE#2 in order to invite him into the conference. And UE#2 sends back SIP 200 OK response to the CONF AS.

11-13. The CONF AS sends Charging Data Request [Interim/Event] to CDF, CDF updates or creates an AS CDR for the conference and returns Charging Data Response to the CONF AS.

5.2.2.1.11.4 CONF charging – user leaving a conference

Figure: 5.2.2.1.11.4.1 shows the Diameter transactions that are required between AS, which implements the CONF service and CDF corresponding to the conference scenario: user leaving a conference.

Figure: 5.2.2.1.11.4.1: CONF charging – user leaving a conference

1-2. The conference has already been created. UE#1 sends a SIP BYE request to the CONF AS in order to quit the conference.

3-5. The CONF AS sends Charging Data Request [Interim/Event] to CDF, CDF updates or creates an AS CDR for the conference and renturns Charging Data Response to the CONF AS. Conference termination should refer to the description of clause 5.3.2.7 in TS 24.147 [220], e.g. if there is not any conference policy and the last online conference user quits the conference could be considered as the conference termination, when the last online conference user quits the conference (sends a SIP BYE request to the CONF AS), the CONF AS sends Charging Data Request [Stop/Event] to CDF, CDF stops or creates an AS CDR for the conference and returns Charging Data Response to the CONF AS.

6-7. The CONF AS sends back SIP 200 OK response to UE#1.

8-10. The CONF AS sends a SIP NOTIFY request to other conference participants that UE#1 has quitted the conference.

11-12. Other conference participants send back SIP 200 OK response to the CONF AS.

5.2.2.1.11.5 Three-Party (3PTY) charging – successful establishment

Figure 5.2.2.1.11.5.1 shows the Diameter transactions that are required between AS, which implements the 3PTY service and CDF corresponding to the 3PTY scenario: 3PTY service successful establishment.

AS (3PTY)

Figure 5.2.2.1.11.5.1: Three-Party (3PTY) charging – successful establishment

1. UE-A and UE-B has established communication. UE-A puts UE-B on hold before invoking the 3-Way Calling with UE-C.

2-4. UE-A establishes a call with UE-C following normal call setup procedure and gets UE-C’s permission to start the 3-Way Calling.

5. UE-A sends an SIP INVITE request to the 3PTY AS to establish a 3PTY session.

6-7. The 3PTY AS sends a SIP 200 OK response and receives an ACK request from UE-A.

8-9. UE-A sends a SIP REFER request to UE-B with the Refer-To header set to the address of the 3PTY AS; UE-B accepts the SIP REFER request.

10-11. UE-B sends a SIP NOTIFY request to UE-A to indicate that UE-B is acting on the SIP REFER request.

12. UE-B sends an SIP INVITE request to the 3PTY AS to join the 3PTY session.

13-14. The 3PTY AS sends a SIP 200 OK response to UE-B and receives an ACK request.

15-16. UE-B sends a SIP NOTIFY request to UE-A to indicate that it has finished action required by the SIP REFER request.

17-18. UE-A sends a SIP BYE request to terminate the call between UE-A and UE-B.

19-20. Repeats step 8 to 18 on UE-Aand UE-C to terminate the call between UE-A and UE-C.

21-23. 3PTY AS sends an Charging Data Request [Start/Interim/Event] to CDF, CDF opens or updates or create an 3PTY AS CDR for the 3PTY service and returns Charging Data Response to the 3PTY AS.

5.2.2.1.11.6 Three-Party (3PTY) charging – release

Figure 5.2.2.1.11.6.1 shows the Diameter transactions that are required between AS, which implements the 3PTY service and CDF corresponding to the 3PTY scenario: release the 3PTY service.

Figure 5.2.2.1.11.6.1: Three-Party (3PTY) charging – release

1. The 3PTY has already been established. UE-A sends a SIP BYE request to the 3PTY AS in order to release from the 3PTY service.

2-4. At session termination 3PTY AS, sends an Accounting-Request [Stop/Event] to CDF, CDF stops or creates an AS CDR for the 3PTY service and returns Accounting Answer to the 3PTY AS.

5. The 3PTY AS sends back SIP 200 OK response to UE-A.

6. The 3PTY AS sends a SIP NOTIFY request to other participants that 3PTY service has released.

5.2.2.1.12 CCBS charging

Figure 5.2.2.1.12.1 shows the Diameter transactions that are required between AS and CDF, which implements the CCBS service, and CDF after service execution.

Figure 5.2.2.1.12.1 : Message sequence chart for offline charging of CCBS service

1-5) The communication is initiated by UE-A by sending an SIP INVITE request.

6) UE-B answers with a SIP 486 (Busy Here) response. The SIP 486 (Busy Here) response is routed back to the terminating AS.

7-8) The terminating AS inserts a Call-Info header field in the SIP 486 (Busy Here) response. The Call-Info header field contains the URI of the terminating AS with an "m" header field parameter set to "BS" (busy subscriber). It further includes a "purpose" header field parameters set to "call-completion". The SIP 486 (Busy Here) response is routed back to the originating AS.

9-10) The originating AS sends back a SIP 183 (Session Progress) response to UE-A and initiates IVR procedures.
User A is informed that CCBS is possible. User A activates CCBS.

11-14) The originating AS subscribes for the call-completion event package. The terminating AS accepts the subscription and starts busy state supervision procedures on the callee.

15-17) The terminating AS sends a notification to the originating AS.

18-20) The originating AS sends Charging Data Request [Event] to CDF, then the CDF creates an AS CDR for the CCBS service subscriber with CCBS indication on the AS CDR and returns Charging Data Response to the originating AS.

21) After confirmation of the notification the originating AS starts announcements procedures informing about the activation of CCBS.

22-23) The originating AS forwards the SIP 486 (Busy Here) response to UE-A.

24-27) When UE-B becomes available, the terminating AS sends a SIP NOTIFY request to the originating AS,

28-29) The originating AS starts the CCBS recall by sending an SIP INVITE request to UE-B. In order to mark the SIP INVITE request as a prioritized request for call-completion, the originating AS adds the "m" SIP URI parameter with the value ‘BS’ to the Request-URI.

5.2.2.1.13 CCNR charging

Figure 5.2.2.1.13.1 shows the Diameter transactions that are required between AS and CDF, which implements the CCNR service, and CDF after service execution.

Figure 5.2.2.1.13.1: Message sequence chart for offline charging of CCNR service

1-5. The communication is initiated by UE-A by sending an SIP INVITE request.

6. UE-B answers with a 180 (Ringing) response. The 180 (Ringing) response is routed back to the terminating AS.

7-8. The terminating AS inserts a Call-Info header field in the 180 (Ringing) response. The Call-Info header field will contain the URI of the terminating AS with a "m" header field parameter set to "NR" (no reply). It further includes a "purpose" header field parameter set to "call-completion". The 180 (Ringing) response is routed back to the originating AS.

9-10. The originating AS removes the Call-Info header field, forwards the 180 (Ringing) response to UE-A and initiates IVR procedures. User A is informed that CCNR is possible. User A activates CCNR.

11-14. The originating AS subscribes for the call-completion event package. The terminating AS accepts the subscription and starts activity supervision procedures on the callee.

15-17. The terminating AS sends a notification to the originating AS,.

18-20. The originating AS sends Charging Data Request [Event] to CDF, then the CDF creates an AS CDR for the CCNR service subscriber with CCNR indication on the AS CDR and returns Charging Data Response to the originating AS.

21. After confirmation of the notification the originating AS starts announcements procedures informing about the activation of CCNR.

5.2.2.1.14 Flexible Alerting (FA)

5.2.2.1.14.1 Flexible Alerting (FA) – establishment

Figure 5.2.2.1.14.1.1 shows the Diameter transactions that are required between AS, implementing the FA service and CDF, with answer from one of FA group members.

Figure 5.2.2.1.14.1.1: Message sequence chart for offline charging of FA service – Answered

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 Identiry".

2. The AS implementing FA maps the Pilot Identity to the list of FA group members: UE-B and UE-C, and forwards SIP INVITE to all FA members.

3 to 4. SIP INVITE forwarded towards UE-B and alerting phase signalling occurs with UE-A.

5 to 6. SIP INVITE forwarded towards UE-C and alerting phase signalling occurs with UE-A.

7. UE-C answers.

8 to 10. Upon reception of the SIP 200 OK answer from UE-C, AS implementing the FA service:

– Sends Charging Data Request [Start] with FA MMTel supplementary service indication.
The CDF creates an AS CDR and returns Charging Data Response to the AS.

– Sends SIP CANCEL to other FA group member being alerted, UE-B.

5.2.2.1.14.2 Flexible Alerting (FA) – call release

Figure 5.2.2.1.14.2.1 shows the Diameter transactions that are required between AS, implementing the FA service and CDF, when previous successfully established call is released.

Figure 5.2.2.1.14.2.1: Message sequence chart for offline charging of FA service – Release

1. UEC initiates release of the communication.

2 to 3. At session termination the AS implementing the FA service, sends Charging Data Request [Stop] and the AS CDR is closed.

5.2.2.1.15 Malicious Communication Identification (MCID)

Figure 5.2.2.1.15.1 shows the Diameter transactions that are required between AS implementing the MCID service and CDF for a successful MCID delivery for permanent mode or temporary mode.

Figure 5.2.2.1.15.1: Message sequence chart for offline charging of MCID service

A communication is requested towards User B, and User B is subscribed to MCID service.

1. SIP INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) rules, indicating that User B is subscribed to the MCID supplementary services, the communication is forwarded to an AS implementing MCID.

2-4. In case of MCID temporary mode, AS stores relevant data temporarily, in case permanent mode AS registers the data and sends Accounting-Request [Event] to record invocation of MCID, acknowledged by the CDF when AS CDR is created.Then SIP INVITE is forwarded to User B.

5. SIP 200 OK answer received from User B.

6. Further SIP signalling for communication establishment, or mid-communication take place, before SIP BYE from User-B.

7-10. Upon reception of SIP re-INVITE from User-B, indicating temporary MCID request, AS registers the data previously stored and sends Charging Data Request[Event/interim] message to CDF to record invocation of MCID, the CDF creates/updates AS CDR and returns Charging Data Response.

5.2.2.1.16 Customized Alerting Tone (CAT)

Although CAT Supplementary services may be delivered according to different models (CAT forking, CAT early session, CAT Gateway) as described in TS 24.182 [217], only one scenario is depicted here, and serves as a basis for CAT charging description, as the same principle applies.

Figure 5.2.2.1.16.1 shows the Diameter transactions that are required between AS implementing the CAT service and CDF for a successful communication establishment with CAT delivery.

More SIP signalling

Figure 5.2.2.1.16.1: Message sequence chart for offline charging of CAT service delivery

A communication is requested towards User B, user B has subscribed to CAT service.

1. SIP INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) rules, indicating that User B is subscribed to the CAT supplementary service, the communication is forwarded to an AS implementing CAT.

2. The AS proceeds to CAT resources reservation and forwards SIP INVITE towards User B..

3. 180 ringing is sent back from User B.

4. The AS sends a reliable 183 (session progress) response to User A with codecs to be used for CAT., acknowledged by PRACK from User A.

5 to 7. Upon acknowledgment from User A (SIP PRACK), the AS starts CAT media playing (alerting tone), and sends SIP 200 OK response to SIP PRACK towards User A.

8 to 11. Upon SIP 200 OK answer received from User B, AS stops CAT media playing (alerting tone), and sends a Charging Data Request [Start/Event] message to CDF, CDF opens/creates an AS CDR and returns Charging Data Response.

NOTE: The same following principle applies for all others CAT delivery scenarii:
a Charging Data Request [Start] is sent from AS to record beginning of alerting tone playing, and Charging Data Request[Stop] is sent to record end of alerting tone playing.

5.2.2.1.17 Closed User Group (CUG)

5.2.2.1.17.1 Closed User Group (CUG): Originating

Figure 5.2.2.1.17.1.1 shows the Diameter transactions that are required between AS implementing the CUG service and CDF for a successful originating communication from User-A CUG member.

Figure 5.2.2.1.17.1.1: Message sequence chart for offline 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 : AS forwards SIP INVITE 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…), CUG information is not included, and non-CUG communication charging applies.

3. SIP signalling for communication establishment.

4-6. SIP 200 OK answer received from User B, and AS sends Charging Data Request [Start/Event] message to CDF to record start of the CUG-communication for User A CUG member. The CDF opens/creates an AS CDR and returns Charging Data Response

5.2.2.1.17.2 Closed User Group (CUG): Terminating

Figure 5.2.2.1.17.2.1 shows the Diameter transactions that are required between AS implementing the CUG service and CDF for a successful terminating communication towards User-B CUG member.

Figure 5.2.2.1.17.2.1: Message sequence chart for offline charging of CUG service – terminating call

User-B is subscribed to CUG service.

1. incoming SIP INVITE request 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: AS forwards SIP INVITE 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.

3. SIP signalling for communication establishment.

4-6. SIP 200 OK answer received from User B, and AS sends Charging Data Request [Start/Event] message to CDF to record start of the CUG-communication for User B CUG member. The CDF opens/creates an AS CDR and returns Charging Data Response.

5.2.2.1.18 Personal Network Management (PNM)

Figure 5.2.2.1.18.1 shows the Diameter transactions that are required between AS implementing the PNM service and CDF for a successful "PN UE redirection" for a terminating communication, as described in TS 23.259 [218].

Figure 5.2.2.1.18.1: Message sequence chart for offline charging of "PNM-redirection" service

1. Incoming SIP INVITE request for UE-1 of User B. Based on the Initial Filter Criteria (IFC) rules, for UE-1, the communication is forwarded to the AS implementing PNM. From PN-user’s PN configuration, the PNM AS determines the initial request is to be redirected to the default UE of the PN, i.e. to the UE-2.

2. SIP INVITE is forwarded towards UE-2.

3. Based on the Initial Filter Criteria (IFC) rules, for UE-2, the communication is forwarded to the AS implementing PNM.

4. From PN-user’s PN configuration, the PNM AS determines the initial request is to be sent to the default UE of the PN, i.e. to the UE-2. SIP INVITE is forwarded towards UE-2.

5. The destination UE-2 party answers and a final response is received.

6. Upon reception of the final response, the AS implementing the PNM service sends Charging Data Request [Start] to record "PN UE redirection" execution to CDF.

7. The CDF acknowledges the reception of the data and opens/creates an AS CDR.

5.2.2.1.19 Customized Ringing Signal (CRS)

Although CRS Supplementary services may be delivered according to different models (download and play model, DTMF…) as described in TS 24.183 [219], only one scenario is depicted here, and serves as a basis for CRS charging description, as the same principle applies.

Figure 5.2.2.1.19.1 shows the Diameter transactions that are required between AS implementing the CRS service and CDF for a successful communication establishment with CRS delivery.

Figure 5.2.2.1.19.1: Message sequence chart for offline charging of "CRS" service delivery

A communication is requested towards User B, user B has subscribed to CRS service.

1. SIP INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) rules, indicating that User B is subscribed to the CRS supplementary service, the communication is forwarded to an AS implementing CRS. The INVITE is forwarded towards User B.

2. SIP 180 ringing is sent back from User B.

3 to 4. Upon acknowledgment from User A (SIP PRACK), the AS reserves CRS media, and forwards PRACK towards User B.

5-6. Upon SIP 200 OK(SIP PRACK acknowledgment) from User B, the AS starts CRS media playing, and forwards SIP 200 OK towards User A.

7-10. Upon SIP 200 OK answer received from User B, the AS stops CRS media playing, and sends Charging Data Request [Start/Event] message to CDF, CDF opens/creates an AS CDR and returns Charging Data Response. The AS forwards SIP 200 OK towards User A.

NOTE: The same following principle applies for all others CRS delivery scenarii:
a Charging Data Request [Start/Event] is sent from AS to record CRS service delivery.

5.2.2.1.20 Advice of Charge (AoC)

The information flows showing the transactions between AS implementing the AoC service and CDF for AoC-S, AoC-D and AoC-E are described in TS 32.280 [69].