5 AoC principles and flows

32.2803GPPAdvice of Charge (AoC) serviceCharging managementRelease 17Telecommunication managementTS

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

5.1 Common charge advice principles

AoC is a supplementary service which provides AoC Information to the UE in real-time. It may contain Cost and/or Tariff Information for the requested service and may be provided at the beginning, during or at the end of service execution.

5.2 AoC in GSM networks (CAI description)

The Charge Advice Information (CAI) is described in TS 22.024 [203], TS 22.086 [204], TS 23.086 [205] and TS 24.086 [206].

5.3 AoC in IMS

5.3.1 Basic principles and definitions

AoC uses the Debit / Reserve Units operation that is specified in TS 32.299 [50].

AoC Information can be provided in two cases:

– AoC Enquiry – An independent request with no Credit-Control implications;

– Debit Unit Request – In conjunction with the Debit / Reserve Units Requests IEC, ECUR, SCUR.

In the ECUR & SCUR, the Advise of charge is supported as part of the Debit Units Request[Initial, Update, Terminate].

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

5.3.2 Message flows and types for offline charging

5.3.2.0 Introduction

The message flows in this clause are based on the signalling flows specified in TS 24.647 [208].

The basic IMS session establishment for a user registered to AoC service(s) is depicted in the annex B. This basic call-flow helps describing in the future the message flows for AoC-S, AoC-D, AoC-E and also including cases where information are received from RTTI messages.

Editor’s Note: The detailed AoC call-flows are FFS.

5.3.2.1 Successful session establishment: AoC-S with AoC Information in reliable 1xx response (originating side)

Figure 5.3.2.1.1 shows the transactions for the successful delivery of the AoC Information in 1xx response to the originating subscriber during session establishment originated by a UE.

Figure 5.3.2.1.1: Message sequence chart for session establishment (1xx Response) with AoC-S

– Step 1: An initial SIP INVITE request is received in the S-CSCF. This request is forwarded to the ACF.

– Step 2: The ACF received the AoC Type = [AoC-S] and queries the OCS for Tariff Information.

– Step 3: The AoC-S information is included in SIP 183 response.

– Step 4: The UE acknowledges the SIP 183 with PRACK.

– Step 5: AoC Function responses with SIP 200 OK.

– Step 6: The SIP INVITE request is received in the S-CSCF and forwards this request.

– Step 7: The S-CSCF receives the SIP 200 OK response and forwards this response.

– Step 8: The ACF queries the OCS and maps the Tariff Information into the AoC Information for further proceeding.

– Step 9: The ACF inserts the AoC-S and resulting "AoC information XML body" as defined in TS 24.647 [208], in the SIP 200 OK response, and the S-CSCF forwards it towards UE

– Step 10: The ACF sends a Charging Data Request with AoC service type and AoC Information indicating EVENT_RECORD to the CDF.

– Step 11: The CDF generates the ACF-CDR to record the AoC service type and AoC Information.

– Step 12: The CDF acknowledges the reception of the Charging Data Response.

5.3.2.2 Mid-session procedure: AoC-S with AoC Information in an SIP INFO request

Figure 5.3.2.2.1 shows the transactions for the successful delivery of the AoC Information to the originating subscriber when a tariff change is detected by AoC Function.

NOTE: This case is relevant when AoC-S is activated.

Figure 5.3.2.2.1: Message sequence chart for mid-session procedure with AoC-S

– Step 1: The ACF detects that tariff is changed and queries the OCS for Tariff Information.

– Step 2: SIP INFO request is send with AoC-S and resulting "AoC information XML body" as defined in TS 24.647 [208].

– Step 3: The ACF sends a Charging Data Request with AoC service type and AoC Information indicating EVENT_RECORD to the CDF.

– Step 4: SIP 200 OK is received.

– Step 5: The CDF acknowledges the reception of the Charging Data Response and generates the ACF-CDR.

5.3.2.3 Session release: AoC-E – originating party clears

Figure 5.3.2.3.1 shows the transactions for the successful delivery of the AoC Information to the originating subscriber when session is released by originating party.

NOTE: This case is relevant also when AoC-D is activated.

Figure 5.3.2.3.1: Message sequence chart for session release originating party clears

– Step 1: A SIP session is released by sending a SIP BYE message. The S-CSCF forwards this message to the ACF and forwards this request.

– Step 2: The ACF received the AoC Type = [AoC-E] and queries the OCS for Tariff Information.

– Step 3: The S-CSCF receives the SIP 200 OK response and forwards this response.

– Step 4: The ACF maps the Tariff Information into the AoC Information for further proceeding.

– Step 5: The ACF inserts the AoC-S and resulting "AoC information XML body" as defined in
TS 24.647 [208], in the SIP 200 OK response, and the S-CSCF forwards it towards UE

– Step 6: The ACF sends a Charging Data Request with AoC service type and AoC Information indicating EVENT_RECORD to the CDF.

– Step 7: The CDF generates the ACF-CDR to record the AoC service type and AoC Information.

– Step 8: The CDF acknowledges the reception of the Charging Data Response.

5.3.2.4 Session release: AoC-E – terminating party clears

Figure 5.3.2.4.1 shows the transactions for the successful delivery of the AoC Information to the originating subscriber when session is released by terminating party.

NOTE: This case is relevant also when AoC-D is activated.

Figure 5.3.2.4.1: Message Sequence Chart for Session Release Terminating Party Clears

– Step 1: A SIP session is released by sending a SIP BYE message. The S-CSCF forwards this message to the AoC Function and forwards this request.

– Step 2: The AoC Function queries the OCS and converts the Tariff Information to AoC Information for AoC-E.

– Step 3: The S-CSCF receives the SIP 200 OK response and forwards this response.

– Step 4: The AoC Function maps the Tariff Information into the AoC Information for further proceeding

– Step 5: The ACF inserts the AoC-E and resulting "AoC information XML body" as defined in
TS 24.647[208], in the SIP 200 OK response, and the S-CSCF forwards it towards UE.

– Step 6: The ACF sends a Charging Data Request with AoC service type and AoC Information indicating EVENT_RECORD to the CDF.

– Step 7: The CDF generates the ACF-CDR to record the AoC service type and AoC Information.

– Step 8: The CDF acknowledges the reception of the Charging Data Response.

5.3.2.5 AoC Function co-located with same AS providing the service

5.3.2.5.0 Introduction

The following flows show the transactions between an MMTel AS embedding the AoC Function for providing AoC as a MMTel supplementary service as defined in TS 22.173 [201].

5.3.2.5.1 Successful session establishment: AoC-S (originating side)

Figure 5.3.2.5.1.1 shows the transactions for the successful delivery of the AoC Information to the originating subscriber during session establishment for MMTel service originated by a UE.

Figure 5.3.2.5.1.1: Message sequence chart for session establishment with AoC-S for MMTel service.

– Step 1: An initial SIP Invite Request is received in the S-CSCF. This request is forwarded to the MMTel AS embedding also ACF.

– Step 2: The ACF received the AoC Type = [AoC-S] and queries the OCS for Tariff Information for MMTel service.

– Step 3: The AoC-S "AoC information XML body" as defined in TS 24.647[208], is included in SIP 183 response.

– Step 4: The UE acknowledges the SIP 183 with PRACK.

– Step 5: AoC Function responses with SIP 200OK.

– Step 6: The SIP Invite Request is received in the S-CSCF and forwards this request.

– Step 7: The S-CSCF receives the SIP 200 OK response and forwards this response.

– Step 8: The AoC Function queries the OCS for the Tariff Information for MMTel service

– Step 9: The ACF inserts the AoC-S and resulting "AoC information XML body" as defined in TS 24.647 [208], in the SIP 200 OK response, and the S-CSCF forwards it towards UE

– Step 10: The MMTel AS sends a Charging Data Request indicating START to the CDF, for the start of MMTel service, and includes AoC-S and AoC Information supplementary service.

– Step 11: The CDF generates the MMTel-CDR recording also the AoC-S and AoC Information.

– Step 12: The CDF acknowledges the reception of the Charging Data Response.

5.3.2.5.2 AOC-D for serving party in SIP INFO request

The following figure 5.3.2.5.2.1 shows the transactions for AoC-D delivery to the serving subscriber, when a tariff change is detected by ACF during MMTel service.

Figure 5.3.2.5.2.1: Message sequence chart for AoC-D to serving party

– Step 1: The ACF detects that tariff is changed for MMTel service and queries the OCS for Tariff Information.

– Step 2: SIP INFO request is send with AoC-S and resulting "AoC information XML body" as defined in TS 24.647 [208].

– Step 3: The MMTel AS sends a Charging Data Request indicating INTERIM _RECORD to the CDF and includes AoC-D and AoC Information as supplementary service.

– Step 4: SIP 200OK is received.

– Step 5: The CDF acknowledges the reception of the Charging Data Response and updates the MMTel-CDR with AoC-D and AoC Information.

5.3.2.5.3 Session release: AoC-E – serving party clears

Figure 5.3.2.5.3.1 shows the transactions for delivery of the AoC-E to the serving subscriber when it releases MMTel service.

Figure 5.3.2.5.3.1: Message sequence chart for AoC-E when serving party clears

– Step 1: A SIP session is released by sending a SIP BYE message. The S-CSCF forwards this message to the MMTel AS and forwards this request.

– Step 2: The ACF queries the OCS for Tariff Information in order to perform AoC-E for MMTel service.

– Step 3: The S-CSCF receives the 200 OK response and forwards this response.

– Step 4: The AoC Function maps the Tariff Information into the AoC Information for further proceeding.

– Step 5: The ACF inserts the AoC-S and resulting "AoC information XML body" as defined in
TS 24.647 [208], in the SIP 200 OK response, and the S-CSCF forwards it towards UE

– Step 6: The MMTel AS sends a Charging Data Request indicating STOP_RECORD to the CDF and includes AoC-E and AoC Information as supplementary service.

– Step 7: The CDF closes the MMTel-CDR with AoC-E and AoC Information included.

– Step 8: The CDF acknowledges the reception of the Charging Data Response.

5.4 AoC in Inter-connected

5.4.1 Principles

In case of interconnection scenarios or 3^rd Party Services, the AoC service may be based on RTTI provided by the external network or service provider, as described in clause 4.3.3.3.

5.4.2 Scenarios

AoC Use cases based on RTTI are described in Annex A.1.2 and A.1.3.

5.4.3 Message flows

RTTI related signalling flows are described in TS 29.658 [209].

5.5 AoC support for PSTN/ISDN Emulation

The IMS based PSTN/ISDN Emulation Sub-system (PES) as defined in ETSI TS 182 012 [212] supports the emulation of PSTN/ISDN services for analogue/ISDN terminals connected to the NGN through residential gateways or access gateways. The Voice over IP Gateway (VGW) is a SIP-based gateway device that connects legacy equipment to the NGN. It plays the role of an IMS UE with regards to the P-CSCF. The Access Gateway Control Function (AGCF) is a SIP-based media gateway controller, which plays the combined role of an IMS UE and a P-CSCF with regards to the
S-CSCF.

NOTE: This paragraph provides background information for AoC support for PES.
The normative definitions of PES are provided by ETSI TS 183 043 [213].

In order to support the emulation of AoC service for analogue terminals, the AoC Information is transferred to a VGW or an AGCF according to the AoC Extended XML schema defined in ETSI TS 183 043 [213].
The AoC Extended XML schema contains the following additional AoC Information elements: ‘pes_aoc-s_phase_duration’ and ‘pes transitioning behaviour’.

The decision which "AOC information XML body" is applicable depends on signalling information. Further details, as well as general rules how to populate the AoC Extended XML parameters are defined in ETSI TS 183 043 [213].

For ISDN terminals, the AoC emulation is based on TS 24.647 [208].