4 Advice Of Charge (AOC)

24.6473GPPAdvice Of Charge (AOC) using IP Multimedia (IM) Core Network (CN) subsystemRelease 17TS

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

4.1 Introduction

The Advice Of Charge (AOC) service allows the served user to be informed of IP Multimedia session related charging information.

4.2 Description

4.2.1 General description

The AOC service is limited to INVITE-initiated sessions.

The AOC service is not meant to replace the charge metering inside the network which is considered to be correct in all cases.

The charging information given shall relate to the charges incurred in the current network.

4.2.2 Charging information at communication set-up time (AOC-S)

When the AOC-S service is activated, the network shall provide the user with information about the charging rates at communication establishment. In addition, the network shall inform the served user if a change in charging rates takes place during the communication.

4.3 Charging information during the communication (AOC-D)

When the AOC-D service is activated, the network shall provide the user with charging information for a communication during the active phase of this communication. The supplied charging information shall be provided as a cumulative charge incurred so far for the communication (i.e. charges recorded from the start of the communication and until the moment the charging information is sent to the served user), or as charging units.

When the call is released, the network shall send the recorded charges for the communication to the served user.

4.4 Charging information at the end of the communication (AOC-E)

When the AOC-E service is activated, the network shall provide the served user with charging information indicating the recorded charges for a communication when this communication is released.

4.5 Operational requirements

4.5.1 Provision/withdrawal

The AOC services shall be provided to the served user after prior arrangement with the service provider or, as a service provider option, be generally available. Withdrawal of these services shall be made on the served user’s request or for service provider reasons.

When available the AOC services shall be provided for all communications (permanent mode).

4.5.2 Requirements on the originating network side

No specific requirements are needed in the network.

4.5.3 Requirements on the terminating network side

No specific requirements are needed in the network.

4.6 Coding requirements

The INFO method according to IETF RFC 6086 [4] with legacy INFO usage is needed in support of AOC-D.

The AOC XML schema is defined in annex D. The AOC XML schema shall be transported as a SIP MIME body. The MIME type for the AOC information is "application/vnd.etsi.aoc+xml" (see subclause 5.1). Any SIP message that transports a body with AOC information shall identify the payload as MIME type "application/vnd.etsi.aoc+xml", the MIME type associated with AOC information (see subclause 5.1), and shall identify in the "sv" or "schemaversion" parameter’s value the versions of AOC XML Schema that can be used to validate the AOC information XML body (part). If both the "sv" and "schemaversion" parameters are present, then the P-CSCF shall ignore the value of the "schemaversion" parameter. The versions – of the MIME type associated with AOC information (see subclause 5.1) – indicated shall correspond with a value of the version attribute of the <schema> XML element of an AOC XML Schema (see e.g. annex D).

4.7 Signalling requirements

4.7.1 Activation/deactivation

The AOC service is activated at provisioning and deactivated at withdrawal.

4.7.1A Registration/erasure

The AOC service requires no registration. Erasure is not applicable.

4.7.1B Interrogation

Interrogation of AOC is not applicable.

4.7.2 Invocation and operation

4.7.2.0 Introduction

Basic communication procedures according to 3GPP TS 24.229 [2] shall apply, with the additions outlined in the subclauses below.

4.7.2.1 Actions at the served UE

The served UE shall support the INFO method according to IETF RFC 6086 [4] with legacy INFO usage and the AOC XML schema defined in annex D.

If methods or responses are received which contain AOC information, this information may be rendered to the user. The UE can render the AOC information e.g. as received or in a form as recalculated in the UE. The incremental cost is calculated as the difference between the subtotal charge of the currently received AOC information and the subtotal charge of the last received AOC information.

In addition to the procedures according to 3GPP TS 24.229 [2], the served UE shall include the Accept header field with:

– "application/vnd.etsi.aoc+xml", the MIME type associated with AOC information (see subclause 5.1), and indicate the versions of the AOC XML Schema it supports. The versions – of the MIME type associated with AOC information (see subclause 5.1) – indicated shall correspond with a value of the version attribute of the <schema> XML element of an AOC XML Schema (see e.g. annex D); and

– any other MIME type the served UE is willing and capable to accept.

4.7.2.2 Actions at the AS of the served user

4.7.2.2.0 General

The AS shall assume that the served user’s UE supports version 1.0 of the MIME type associated with AOC information (see subclause 5.1), if support for the MIME type associated with AOC information in the Accept header is not indicated. The versions – of the MIME type associated with AOC information (see subclause 5.1) – indicated shall correspond with a value of the version attribute of the <schema> XML element of an AOC XML Schema (see e.g. Annex D).

When sending AOC information, the AS shall encode this information according to the XML-schema defined in annex D. In addition, for this MIME body the AS shall:

– set the Content-Type header to "vnd.etsi.aoc+xml", the MIME type associated with AOC information (see subclause 5.1), and shall include in its "sv" or "schemaversion" parameter’s value the versions of AOC XML Schema that can be used to validate the AOC information XML body (part). If both the "sv" and "schemaversion" parameters are present, then the P-CSCF shall ignore the value of the "schemaversion" parameter. The versions – of the MIME type associated with AOC information (see subclause 5.1) – indicated shall correspond with a value of the version attribute of the <schema> XML element of an AOC XML Schema (see e.g. Annex D); and

– set the Content-Disposition to "render" with the "handling" parameter set to "optional".

In the case the AOC information is transported in a message that is forwarded by the AS that contains already a content body, the AS shall generate a multipart/mixed MIME body containing two sub-parts:

– one with the AOC information; the Content-Type and Content-Disposition of this sub-part should be coded as specified for non-multipart bodies;

– one with the received body; headers describing the content of the received SIP message (e.g. Content-type) should be moved into the headers of the this subpart.

In the case the AOC information is transported in a message that is forwarded by the AS, that contains already a content body and the served user’s UE has not indicated support for multipart content, the AS shall forward the message unchanged.

NOTE: The above subclause ensures that a communication setup is not affected in case a terminal does not support multipart content.

4.7.2.2.1 Actions for AOC-S

4.7.2.2.1.1 Served user is the originating user

When an INVITE request is received, and the served user is subscribed to AOC-S service, the AS shall either (network operator option) operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] and in IETF RFC 3262 [5] and include the AOC information in the content body of a reliable 1xx provisional responses, or operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] and include the AOC information in the content body a 200 (OK) response forwarded by the AS.

If the charging rates change during the communication, the AS shall send the AOC information to the UE of the served user in the content body of a mid-dialog request forwarded by the AS or an INFO request generated by the AS.

NOTE: If no charging information is available, then the AS can, as a network option, stop the communication establishment before the session is confirmed by sending a 504 (Server Time-out) response to the originating user and a BYE request to the terminating side. The BYE request contains a Reason header field with a reason value with the protocol set to "SIP" and the cause set to "504" and optionally a reason value with the protocol set to "Q.850" and the cause set to "31".

4.7.2.2.1.2 Served user is the terminating user

The AS shall operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2].

When an INVITE request is received, and the served user is subscribed to the AOC-S service, the AS shall include the AOC information in the content body in the INVITE request before sending the INVITE request to the terminating UE.

NOTE: If no charging information is available, then the AS can, as a network option, not forward the communication invitation and send a 504 (Server Time-out) response to the originating side.

4.7.2.2.2 Actions for AOC-D

The AS shall operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2].

The procedures for AOC-D service at the AS are the same for the originating and the terminating user.

If the user is subscribed to AOC-D service, the AS may provide charging information to the user at any moment during the active phase of the communication. When sending the charging information, the AS shall include the AOC information in the content body of a mid-dialog request or mid-dialog response forwarded by the AS to the served user or an INFO request to the served user generated by the AS. The supplied charging information shall be provided as a cumulative charge incurred so far for the communication (i.e. charges recorded from the start of the communication until the moment the charging information is sent to the served user).

When the communication is terminated, the AS shall include the recorded AOC information for the communication in the content body of either the BYE request or the final response to the BYE request sent to the served user. If the communication is free of charge, then the AS shall indicate the charged amount as zero in the AOC information.

4.7.2.2.3 Actions for AOC-E

The AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2].

The procedures for AOC-E service at the AS are the same for the originating and the terminating user.

If the user is subscribed to AOC-E service, when the communication is terminated the AS shall include the recorded AOC information for the communication in the content body of either the BYE request or the final response to the BYE request sent to the served user. If the communication is free of charge, then the AS shall indicate the charged amount as zero in the AOC information.