6 3GPP charging applications – Protocol aspects

32.2993GPPCharging managementDiameter charging applicationsRelease 17Telecommunication managementTS

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

6.1 Basic principles for Diameter offline charging

6.1.0 Introduction

In order to support the offline charging principles described in the present document, the Diameter client and server shall implement at least the following Diameter options listed in RFC 6733 [401], i.e. the basic functionality of Diameter accounting, as defined by the Diameter Base Protocol (RFC 6733 [401]) is re-used.

The charging architecture implementing Diameter adheres to the structure where all communications for offline charging purposes between the CTF (Diameter client) and the CDF (Diameter server) are carried out on the Diameter Rf reference point, where the CTF reports charging information to the Charging Data Function (CDF). The CDF uses this information to construct and format CDRs. The above-mentioned reference points are defined in TS 32.240 [1].

A configurable timer is supported in the CDF to supervise the reception of the ACR[Interim] and/or ACR[Stop]. An instance of the "Timer" is started at the beginning of the accounting session, reset on the receipt of an ACR[Interim] and stopped at the reception of the ACR[Stop]. Upon expiration of the timer, the CDF stops the accounting session with the appropriate error indication.

For offline charging, the CTF implements the accounting state machine described in RFC 6733 [401].
The server (CDF) implements the accounting state machine "SERVER, STATELESS ACCOUNTING" as specified in RFC 6733 [401], i.e. there is no order in which the server expects to receive the accounting information.

The offline charging functionality is based on the Network Elements reporting accounting information upon reception of various messages which trigger charging generation, as most of the accounting relevant information is contained in these messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [start, interim, stop and event] from the Network Elements to the CDF.

Following the Diameter base protocol specification, the following "types" of accounting data may be sent with regard to offline charging:

START session accounting data.
INTERIM session accounting data.
STOP session accounting data.
EVENT accounting data.

Two cases are currently distinguished for offline charging purposes:

Event based charging; and
Session based charging.

ACR types START, INTERIM and STOP are used for accounting data related to successful sessions. In contrast, EVENT accounting data is unrelated to sessions, and is used e.g. for a simple registration or interrogation and successful service event triggered by a Network Element. In addition, EVENT accounting data is also used for unsuccessful session establishment attempts.

The flows and scenarios for the above two described cases are further detailed below.

6.1.1 Event based charging

In the case of event based charging, the network reports the usage or the service rendered where the service offering is rendered in a single operation. It is reported using the ACR[Event].

Figure 6.1.1.1 shows the transactions that are required on the Diameter offline interface in order to perform event based charging. The operation may alternatively be carried out prior to, concurrently with or after service/content delivery.

Figure 6.1.1.1: Event based offline charging

Step 1: The Network Element receives indication that service has been used/delivered.

Step 2: The Network Element (acting as client) sends Accounting-Request (ACR) with Accounting-Record-Type AVP set to EVENT_RECORD to indicate service specific information to the CDF (acting as server).

Step 3: The CDF receives the relevant service charging parameters and processes accounting request.

Step 4: The CDF returns Accounting-Answer message with Accounting-Record-Type AVP set to EVENT_RECORD to the Network Element in order to inform that charging information was received.

6.1.2 Session based charging

Session based charging is the process of reporting usage reports for a session and uses the START, INTERIM and STOP accounting data. During a session, a Network Element may transmit multiple ACR Interims’ depending on the proceeding of the session.

Figure 6.1.2.1 shows the transactions that are required on the Diameter offline interface in order to perform session based charging.

Figure 6.1.2.1: Session based offline charging

Step 1: The Network Element receives a service request. The service request may be initiated either by the user or the other Network Element.

Step 2: In order to start accounting session, the Network Element sends a Accounting-Request (ACR) with Accounting-Record-Type AVP set to START_RECORD to the CDF.

Step 3: The CDF opens a CDR for current session.

Step 4: The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to START_RECORD to the Network Element and possibly Acct-Interim-Interval AVP (AII) set to non-zero value indicating the desired intermediate charging interval.

Step 5: When either AII elapses or charging conditions changes are recognized at Network Element (NE), the NE sends an Accounting-Request (ACR) with Accounting-Record-Type AVP set to INTERIM_RECORD to the CDF.

Step 6: The CDF updates the CDR in question.

Step 7: The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to INTERIM_RECORD to the Network Element.

Step 8: The service is terminated.

Step 9: The Network Element sends a Accounting-Request (ACR) with Accounting-Record-Type AVP set to STOP_RECORD to the CDF.

Step 10: The CDF updates the CDR accordingly and closes the CDR.

Step 11: The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to STOP_RECORD to the Network Element.

6.1.3 Offline charging error cases – Diameter procedures

6.1.3.1 CDF connection failure

When the connection towards the primary CDF is broken, the process of sending accounting information should continue towards a secondary CDF (if such a CDF is configured). For further CDF connection failure functionality, see clause "Transport Failure Detection" in the RFC 6733 [401].

If no CDF is reachable the Network Element may buffer the generated accounting data in non-volatile memory. Once the CDF connection is working again, all accounting messages stored in the buffer is sent to the CDF, in the order they were stored in the buffer.

6.1.3.2 No reply from CDF

In case a Network Element does not receive an ACA in response to an ACR, it may retransmit the ACR message. The waiting time until a retransmission is sent, and the maximum number of repetitions are both configurable by the operator. When the maximum number of retransmissions is reached and still no ACA reply has been received, the Network Element executes the CDF connection failure procedure as specified above.

If retransmitted ACRs’ are sent, they are marked with the T-flag as described in RFC 6733 [401], in order to allow duplicate detection in the CDF, as specified in the next clause 6.1.3.3.

6.1.3.3 Duplicate detection

A Diameter client marks possible duplicate request messages (e.g. retransmission due to the link fail over process) with the T-flag as described in RFC 6733 [401].

If the CDF receives a message that is marked as retransmitted and this message was already received, then it discards the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from duplicated message(s) is used.

6.1.3.4 CDF detected failure

The CDF closes a CDR when it detects that expected Diameter ACRs for a particular session have not been received for a period of time. The exact behaviour of the CDF is operator configurable.

6.2 Message contents for offline charging

6.2.1 Summary of offline charging message formats

6.2.1.1 General

The corresponding Diameter accounting application messages for the Charging Data Transfer operation is Accounting-Request (ACR) and Accounting-Answer (ACA) as specified in the Diameter Base Protocol Accounting (DBPA) application in RFC 6733 [401].

Table 6.2.1.1.1 describes the use of these messages which are adapted for 3GPP offline charging.

Table 6.2.1.1.1: Offline charging messages reference table

Command-Name	Source	Destination	Abbreviation
Accounting-Request	CTF	CDF	ACR
Accounting-Answer	CDF	CTF	ACA
Capabilities-Exchange-Request	CTF	CDF	CER
Capabilities-Exchange-Answer	CDF	CTF	CEA

Additional Diameter messages (i.e. DPR/DPA, DWR/DWA)are used according to the Diameter Base Protocol Accounting (DBPA) specification in RFC 6733 [401].

6.2.1.2 Structure for the Accounting message formats

The following is the basic structure shared by all offline charging messages. This is based directly on the format of the messages defined in the Diameter Base Protocol Application specification in RFC 6733 [401].

Those Diameter Accounting AVPs that are used for 3GPP offline charging are marked in table 6.2.2.1 and table 6.2.3.1 with a category as specified in TS 32.240 [1].

An AVP in grey strikethrough in the message format (in grey in the tables) is not used by 3GPP.

The following symbols are used in the message format definition:

– <AVP> indicates a mandatory AVP with a fixed position in the message.

– {AVP} indicates a mandatory AVP in the message.

– [AVP] indicates an optional AVP in the message.

– *AVP indicates that multiple occurrences of an AVP is possible.

6.2.2 Accounting-Request message

The ACR messages, indicated by the Command-Code field set to 271 is sent by the CTF to the CDF in order to send charging information for the requested bearer / subsystem /service.

The ACR message format is defined according to the Diameter Base Protocol in RFC 6733 [401] as follows:

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Accounting-Record-Type }

{ Accounting-Record-Number }

[ Acct-Application-Id ]

~~[ Vendor-Specific-Application-Id ]~~

[ User-Name ]

[ Destination-Host ]

~~[ Accounting-Sub-Session-Id ]~~

~~[ Acct-Session-Id ]~~

~~[ Acct-Multi-Session-Id ]~~

[ Acct-Interim-Interval ]

~~[ Accounting-Realtime-Required ]~~

[ Origin-State-Id ]

[ Event-Timestamp ]

* [ Proxy-Info ]

* [ Route-Record ]

[ Service-Context-Id ]

[ Service-Information ]

* [ AVP ]

NOTE: Similar information as in subscription_id should be added as 3GPP parameter, IMEI.

Table 6.2.2.1 illustrates the basic structure of a 3GPP Diameter Accounting-Request message as used for 3GPP offline charging.

Table 6.2.2.1: 3GPP Accounting-Request message contents

AVP	Category	Description
Session-Id	M	This field identifies the operation session.
Origin-Host	M	This field contains the identification of the source point of the operation and the realm of the operation originator.
Origin-Realm	M	This field contains the realm of the operation originator.
Destination-Realm	M	This field contains the realm of the operator domain. The realm will be addressed with the domain address of the corresponding public URI.
Accounting-Record-Type	M	This field defines the transfer type: event for event based charging and start, interim, stop for session based charging.
Accounting-Record-Number	M	This field contains the sequence number of the transferred messages.
Acct-Application-Id	O_M	The field corresponds to the application ID of the Diameter Accounting Application and is defined with the value 3.
Vendor-Specific-Application-Id	–	Not used in 3GPP.
Vendor-Id	–	Not used in 3GPP.
Auth-Application-Id	–	Not used in 3GPP.
Acct-Application-Id	–	Not used in 3GPP.
User-Name	O_C	Contains the user name determined by the domain: bearer, sub-system or service as described in middle tier TS.
Destination-Host	O_C	This field contains the destination address of the CDF.
Accounting-Sub-Session-Id	–	Not used in 3GPP.
Accounting-Session-Id	–	Not used in 3GPP.
Acct-Multi-Session-Id	–	Not used in 3GPP.
Acct-Interim-Interval	O_C	This field contains the proposal for instructions to produce records continuously during a session.
Accounting-Realtime-Required	–	Not used in 3GPP.
Origin-State-Id	O_C	This field contains the state associated to the CTF.
Event-Timestamp	O_C	This field corresponds to the exact time the accounting is requested.
Proxy-Info	O_C	This field contains information of the host.
Proxy-Host	M	This field contains the identity of the host that added the Proxy-Info field.
Proxy-State	M	This field contains state local information.
Route-Record	Oc	This field contains an identifier inserted by a relaying or proxying node to identify the node it received the message from.
Service-Context-Id	O_M	This field indicates the service and the corresponding ‘middle tier’ TS.
Service-Information	O_M	This parameter holds the individual service specific parameters as defined in the corresponding ‘middle tier’ TS.
AVP	Oc	This field contains extended Information.

NOTE: A detailed description of the AVPs is provided in clause 7.

6.2.3 Accounting-Answer (ACA) message

The ACA messages, indicated by the Command-Code field set to 271 is sent by the CDF to the CTF in order to reply to the ACR.

The ACA message format is defined according to the Diameter Base Protocol in RFC 6733 [401] as follows:

< Session-Id >

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

{ Accounting-Record-Type }

{ Accounting-Record-Number }

[ Acct-Application-Id ]

~~[ Vendor-Specific-Application-Id ]~~

[ User-Name ]

~~[ Accounting-Sub-Session-Id ]~~

~~[ Acct-Session-Id ]~~

~~[ Acct-Multi-Session-Id ]~~

[ Error-Message ]

[ Error-Reporting-Host ]

[ Acct-Interim-Interval ]

[ Failed-AVP ]

~~[ Accounting-Realtime-Required ]~~

[ Origin-State-Id ]

[ Event-Timestamp ]

* [ Proxy-Info ]

* [ AVP ]

Table 6.2.3.1 illustrates the basic structure of a 3GPP Diameter Accounting-Answer message as used for offline charging. This message is always used by the CDF as specified below, regardless of the CTF it is received from and the ACR record type that is being replied to.

Table 6.2.3.1: 3GPP Accounting-Answer (ACA) message content

AVP	Category	Description
Session-Id	M	This field identifies the operation session.
Result-Code	M	This field contains the result of the specific query.
Experimental-Result	O_C	This field contains the Experimental result of the specific query.
Origin-Host	M	This field contains the identification of the source point of the operation and the realm of the operation originator.
Origin-Realm	M	This field contains the realm of the operation originator.
Accounting-Record-Type	M	This field defines the transfer type: event for event based charging and start, interim, stop for session based charging.
Accounting-Record-Number	M	This field contains the sequence number of the transferred messages.
Acct-Application-Id	O_M	The field corresponds to the application ID of the Diameter Accounting Application and is defined with the value 3.
Vendor-Specific-Application-Id	–	Not used in 3GPP
Vendor-Id	–	Not used in 3GPP
Auth-Application-Id	–	Not used in 3GPP
Acct-Application-Id	–	Not used in 3GPP
User-Name	O_C	Contains the user name determined by the domain: bearer, sub-system or service as described in middle tier TS.
Accounting-Sub-Session-Id	–	Not used in 3GPP
Accounting-RADIUS-Session-Id	–	Not used in 3GPP
Acct-Multi-Session-Id	–	Not used in 3GPP
Error-Message	O_C	This field contains a human readable error message.
Error-Reporting-Host	O_C	This field contains the identity of the Diameter host that sent the Result-Code AVP to a value other than 2001 (Success) if the host setting the Result-Code is different from the one encoded in the Origin-Host AVP.
Acct-Interim-Interval	O_C	This field contains the instructions to produce records continuously during a session.
Accounting-Realtime-Required	–	Not used in 3GPP
Failed-AVP	OC	This field contains the AVP that could not be processed sucessfully. This field can occur only once.
Origin-State-Id	O_C	This field contains the state associated to the source point of the operation.
Event-Timestamp	O_C	This field contains the time when the operation is requested.
Proxy-Info	O_C	This field contains information of the host.
Proxy-Host	M	This field contains the identity of the host that added the Proxy-Info field.
Proxy-State	M	This field contains state local information.
AVP	O_C	This field contains extended Information.

6.3 Basic principles for Diameter online charging

6.3.1 Online Specific Credit-Control application requirements

For online charging, the basic functionality as defined by the IETF Diameter Credit-Control Application is used.
The basic structure follows a mechanism where the online client (CTF) requests resource allocation and reports Credit-Control information to the Online Charging System (OCS).

The usage and values of Validity-Time AVP and the timer "Tcc" are under the sole control of the Credit-Control server (OCS) and determined by operator configuration of the OCS.

The online client implements the state machine described in RFC 4006 [402] for "CLIENT, EVENT BASED" and/or "CLIENT, SESSION BASED". I.e. when the client applies IEC it uses the "CLIENT, EVENT BASED" state machine, and when the client applies ECUR defined in 3GPP it uses the "CLIENT, SESSION BASED" state machine for the first and final interrogations.

The OCS implements the state machine described in RFC 4006 [402] for the "SERVER, SESSION AND EVENT BASED" in order to support Immediate Event Charging and Event Charging with Unit Reservation.

6.3.2 Diameter description on the Ro reference point

6.3.2.1 Basic principles

For online charging the Diameter Credit-Control Application (DCCA) defined in RFC 4006 [402] is used with additional AVPs defined in the present document.

Three cases for control of user credit for online charging are distinguished:

– Immediate Event Charging IEC; and

– event charging with unit reservation (ECUR).

– Session Charging with Unit Reservation (SCUR)

In the case of Immediate Event Charging (IEC),the Credit-Control process for events is controlled by the corresponding CC-Requested-Type EVENT_REQUEST that is sent with Credit-Control-Request (CCR) for a given Credit-Control event.

In the case of Event Charging with Unit Reservation (ECUR) the CC-Request-Type INITIAL / TERMINATION_REQUEST are used for charging for a given Credit-Control event, however, where a reservation is made prior to service delivery and committed on execution of a successful delivery.

Session Charging with Unit Reservation is used for Credit-Control of sessions and uses the CC-Request-Type INITIAL / UPDATE and TERMINATION_REQUEST.

The Network Element may apply IEC, where CCR event messages are generated, or ECUR, using CCR Initial and Termination. The decision whether to apply IEC or ECUR is based on the service and/or operator’s policy.

6.3.3 Immediate Event Charging (IEC)

Figure 6.3.3.1 shows the transactions that are required on the Ro reference point in order to perform event based Direct Debiting operation. The Direct Debiting operation may alternatively be carried out prior to service/content delivery.
the Network Element shall ensure that the requested service execution is successful, when this scenario is used.

Figure 6.3.3.1: IEC – Direct Debiting operation

Step 1. The Network Element receives a service request.
The Direct Debiting operation is performed as described in RFC 4006 [402].

Step 2. The Network Element performs direct debiting prior to service execution. Network element (acting as DCCA client) sends CCR with CC-Request-Type AVP set to EVENT_REQUEST to indicate service specific information to the OCS (acting as DCCA server). The Requested-Action AVP (RA) is set to DIRECT_DEBITING. If known, the Network Element may include Requested-Service-Unit AVP (RSU) (monetary or non-monetary units) in the request message.

Step 3. Having transmitted the CCR message the Network Element starts the communication supervision timer ‘Tx’ (RFC 4006 [402]). Upon receipt of the Credit-Control- Answer (CCA) message the Network Element shall stop timer Tx.

Step 4. The OCS determines the relevant service charging parameters.

Step 5. The OCS returns CCA message with CC-Request-Type AVP set to EVENT_REQUEST to the Network Element in order to authorize the service execution
(Granted-Service-Unit AVP (GSU) and possibly Cost-Information AVP (CI) indicating the cost of the service and Remaining-Balance AVP are included in the CCA message).
The CCA message has to be checked by the Network Element accordingly and the requested service is controlled concurrently with service delivery. The Refund-Information AVP may be included in the CCA message in order to be sent during the REFUND-ACCOUNT mechanism, see below scenario.

Step 6. Service is being delivered.

NOTE: It is possible to perform also, CHECK_BALANCE and PRICE_ENQUIRY using above described mechanism RFC 4006 [402].

Figure 6.3.3.2 shows the transactions for refund purpose.

Figure 6.3.3.2: IEC – Direct Debiting operation for refund purpose

The Direct debiting operation is performed, previously, as described in RFC 4006 [402].

Step 1. The service charged previously through Direct Debiting Operation is finally proved to be unsuccessfully delivered.

Step 2. As a consequence, the Network Element performs direct debiting operation in order to perform the related refund. Network element (acting as DCCA client) sends CCR with CC-Request-Type AVP set to EVENT_REQUEST to indicate service specific information to the OCS (acting as DCCA server). The Requested-Action AVP (RA) is set to REFUND-ACCOUNT.
The Network Element includes Refund-Information AVP if received in the previous IEC CCA.

Step 4. The OCS reads the AVPs included in the CCR and performs the refund accordingly.

Step 5. The OCS returns CCA message with CC-Request-Type AVP set to EVENT_REQUEST and the related result code.

6.3.4 Event Charging with Unit Reservation (ECUR)

Figure 6.3.4.1 shows the transactions that are required on the Ro reference point in order to perform the ECUR. ECUR is used when event charging needs separate reserve and commit actions.

Figure 6.3.4.1: ECUR – Session based Credit-Control

Step 1. The Network Element receives a service request. The service request may be initiated either by the user or the other Network Element.

Step 2. In order to perform Reserve Units operation for a number of units (monetary or non-monetary units), the Network Element sends a CCR with CC-Request-Type AVP set to INITIAL_REQUEST to the OCS. If known, the Network Element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary units) in the request message.

Step 3. If the service cost information is not received by the OCS, the OCS determines the price of the desired service according to the service specific information received by issuing a rating request to the Rating Function. If the cost of the service is included in the request, the OCS directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the users account.

Step 4. Once the reservation has been made, the OCS returns CCA message with CC-Request-Type set to INITIAL_REQUEST to the Network Element in order to authorize the service execution (Granted-Service-Unit and possibly Cost-Information indicating the cost of the service and Remaining-Balance AVP are included in the CCA message). The OCS may return the Validity-Time (VT) AVP with value field set to a non-zero value. The OCS may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined treshold of this account.

Step 5. Content/service delivery starts and the reserved units are concurrently controlled.

Step 6. When content/service delivery is completed, the Network Element sends CCR with CC-Request-Type AVP set to TERMINATION_REQUEST to terminate the active Credit-Control session and report the used units.

Step 7. The OCS deducts the amount used from the account. Unused reserved units are released, if applicable.

Step 8. The OCS acknowledges the reception of the CCR message by sending CCA message with CC-Request-Type AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the cumulative cost of the service and Remaining-Balance AVP are included in the CCA message).

NOTE: This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown in the figure 6.3.4.1.

6.3.5 Session Charging with Unit Reservation (SCUR)

Figure 6.3.5.1 shows the transactions that are required on the Ro reference point in order to perform the SCUR.

Figure 6.3.5.1: SCUR – Session based CCredit-Control

Step 1. The Network Element receives a session initiation. The session initiation may be done either by the user or the other Network Element.

Step 5. Content/service delivery starts and the reserved units are concurrently controlled.

Step 6. During session delivery, in order to perform Debit Units and subsequent Reserve Units operations, the Network Element sends a CCR with CC-Request-Type AVP set to UPDATE_REQUEST, to report the units used and request additional units, respectively. The CCR message with CC-Request-Type AVP set to UPDATE_REQUEST shall be sent by the Network Element between the INITIAL_REQUEST and TERMINATION_REQUEST either on request of the Credit-Control application within the validity time or if the validity time is elapsed. If known, the Network Element may include Requested-Service-Unit AVP (monetary or non monetary units) in the request message. The Used-Service-Unit (USU) AVP is complemented in the CCR message to deduct units from both the user’s account and the reserved units, respectively.

Step 7. The OCS deducts the amount used from the account. If the service cost information is not received by the OCS, the OCS determines the price of the desired service according to the service specific information received by issuing a rating request to the Rating Function. If the cost of the service is included in the request, the OCS directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the users account.

Step 8. Once the deduction and reservation have been made, the OCS returns CCA message with CC-Request-Type set to UPDATE_REQUEST to the Network Element, in order to allow the content/service delivery to continue (new Granted-Service-Unit (GSU) AVP and possibly Cost-Information (CI) AVP indicating the cumulative cost of the service and Remaining-Balance AVP are included in the CCA message). The OCS may include in the CCA message the Final-Unit-Indication (FUI) AVP to indicate the final granted units. The OCS may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined threshold of this account.

Step 9. Session delivery continues and the reserved units are concurrently controlled.

Step 10. The session is terminated at the Network Element.

Step 11. The Network Element sends CCR with CC-Request-Type AVP set to TERMINATION_REQUEST to terminate the active Credit-Control session and report the used units.

Step 12. The OCS deducts the amount used from the account. Unused reserved units are released, if applicable.

Step 13. The OCS acknowledges the reception of the CCR message by sending CCA message with CC-Request-Type AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the cumulative cost of the service and Remaining-Balance AVP are included in the CCA message).

NOTE: This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown in figure 6.3.5.1.

6.3.6 Error cases and scenarios

6.3.6.0 Introduction

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

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

6.3.6.1 Duplicate detection

The detection of duplicate request is needed and shall 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 (in real-time ) by the receiver entity.

The Network Element marks the request messages that are retransmitted after a link fail over as possible duplicates with the T-flag as described in RFC 6733 [401]. 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.

Note that for EBCC the duplicate detection is performed in the Correlation Function that is part of the OCS.
The OCS that receives the possible duplicate request should mark as possible duplicate the corresponding request that is sent over the ‘Rc’ reference point. However, this assumption above is for further study and needs to be clarified.

For Credit-Control duplicate detection, please refer to the Diameter Credit-Control.

6.3.6.2 Reserve Units / Debit Units operation failure

In the case of an OCS connection failure, and/or receiving error responses from the OCS, please refer to RFC 6733 [401] and RFC 4006 [402] for failure handling descriptions.

6.3.7 Support of tariff changes during an active user session

6.3.7.1 Support of tariff changes using the tariff switch mechanism

After a tariff switch has been reached, all the active user sessions shall report their session usage by the end of the validity period of the current request and receive new quota for resource usage for the new tariff period.

In order to avoid the need for mass simultaneous quota refresh, the traffic usage can be split into resource usage before a tariff switch and resources used after a tariff switch.

The Tariff-Time-Change AVP is used to determine the tariff switch time as described by RFC 4006 [402].
In addition to the scenarios described in RFC 4006 [402], the Tariff-Time-Change AVP may also be used in the context of continuously time-based charging.

The Tariff-Change-Usage AVP is used within the Used-Service-Units AVP to distinguish reported usage before and after the tariff time change.

The Tariff-Change-Usage AVP is not used directly within the Multiple-Services-Credit-Control AVP.

6.3.7.2 Support of tariff changes using Validity-Time AVP

Changes to the tariffs pertaining to the service during active user sessions may also be handled using the Validity Time AVP.

NOTE: RFC 4006 [402] does not directly describe how tariff changes are handled with validity time.
If validity time is used for tariff time changes it might overload the client and the server.

6.3.8 Support of re-authorization

Mid Diameter CC session re-authorizations of multiple active resource quotas within a DCC session can be achieved using a single Diameter Credit-Control- Request/ Credit-Control- Answer message sequence.

The OCS may also re-authorize multiple active resource quotas within a DCC session by using a single Diameter Re-Auth-Request/Answer message sequence.

New quota allocations received by the Network Element override any remaining held quota resources after accounting for any resource usage while the re-authorization was in progress.

6.3.9 Support of failure handling

The Credit-Control-Failure-Handling AVP as defined in RFC 4006 [402] determines what to do if the sending of Diameter credit-control messages to the OCS has been temporarily prevented. The usage of Credit-Control-Failure-Handling AVP gives flexibility to have different failure handling for credit-control session.

This AVP may be received from the OCS or may be locally configured. The value received from the OCS in the Diameter CCA message always override any already existing value.

As defined in RFC 4006 [402], the Tx timer is introduced to limit the waiting time in the CTF for an answer to the CCR sent to the OCS. When the Tx timer elapses the CTF takes an action to the end user according to the value of the Credit-Control-Failure-Handling AVP.

It is possible that several concurrent CCR messages are triggered for the same online charging session. In this case, each CCR message shall reset the Tx timer as defined in RFC 4006 [402].

6.3.10 Support of failover

As defined in RFC 4006 [402] if a failure occurs during an ongoing credit-control session, the CTF may move the Credit-Control message stream to an alternative OCS if the primary OCS indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP. In case CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED the Credit-Control message stream is not moved to a backup OCS.

For new Credit-Control sessions, failover to an alternative OCS should be performed if possible. For instance, if an implementation of the CTF can determine primary OCS unavailability it can establish the new Credit-Control sessions with a possibly available secondary OCS.

Since the OCS has to maintain session states, moving the credit-control message stream to a backup OCS requires a complex charging context transfer solution. This charging context transfer mechanism by OCS is out of the scope of the 3GPP standardization work.

6.3.11 Credit pooling

Credit pooling shall be supported as described in TS 32.240 [1].

NOTE: Credit pooling is not applicable to IEC since there is no quota management between CTF and OCF.

6.4 Message formats for online charging

6.4.1 Summary of online charging message formats

6.4.1.1 General

The corresponding Diameter Credit-Control application messages for the Debit / Reserve Unit Request operation is Credit-Control-Request (CCR) and for the Debit / Reserve Unit Response operation is Credit-Control-Answer (CCA) as specified in RFC 4006 [402].

The Diameter Credit-Control Application (DCCA) specifies an approach based on a series of "interrogations":

1. Initial interrogation.

2. Zero, one or more interim interrogations.

3. Final interrogation.

In addition to a series of interrogations, also a one time event (interrogation) can be used e.g. in the case when service execution is always successful.

All of these interrogations use CCR and CCA messages. The CCR for the "interim interrogation" and "final interrogation" reports the actual number of "units" that were used, from what was previously reserved. This determines the actual amount debited from the subscriber’s account.

Table 6.4.1.1.1 describes the use of these Diameter messages which are adapted for 3GPP online charging.

Table 6.4.1.1.1: Online charging messages reference table

Command-Name	Source	Destination	Abbreviation
Credit-Control-Request	CTF	OCS	CCR
Credit-Control-Answer	OCS	CTF	CCA
Capabilities-Exchange-Request	CTF	OCS	CER
Capabilities-Exchange-Answer	OCS	CTF	CEA

Additional Diameter messages (i.e. ASR/ASA, DPR/DPA, DWR/DWA, RAR/RAA) are used according to the Diameter Base Protocol Accounting (DBPA) specification in RFC 6733 [401] and to the DCCA specification in RFC 4006 [402].

6.4.1.2 Structure for the Credit-Control message formats

The following is the basic structure shared by all online charging messages. This is based directly on the format of the messages defined in RFC 4006 [402].

Those Diameter accounting AVPs that are used for 3GPP online charging are marked in the table of contents 6.4.2 and 6.4.3 with a category as specified in TS 32.240 [1].

In the definition of the Diameter commands, the AVPs that are specified in the referenced specifications but not used by the 3GPP charging specifications are marked with strikethrough, e.g. ~~[ Acct-Multi-Session-Id ]~~.

The following symbols are used in the message format definitions:

– <AVP> indicates a mandatory AVP with a fixed position in the message.

– {AVP} indicates a mandatory AVP in the message.

– [AVP] indicates an optional AVP in the message.

– *AVP indicates that multiple occurrences of an AVP is possible.

6.4.2 Credit-Control-Request message

The CCR messages, indicated by the Command-Code field set to 272 is sent by the CTF to the OCF in order to request credits for the request bearer / subsystem /service.

The CCR message format is defined according to RFC 4006 [402] as follows:

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Auth-Application-Id }

{ Service-Context-Id }

{ CC-Request-Type }

{ CC-Request-Number }

[ Destination-Host ]

[ User-Name ]

~~[ CC-Sub-Session-Id ]~~

~~[ Acct-Multi-Session-Id ]~~

[ Origin-State-Id ]

[ Event-Timestamp ]

*[ Subscription-Id ]

~~[ Service-Identifier ]~~

[ Termination-Cause ]

~~[ Requested-Service-Unit ]~~

[ Requested-Action ]

*[ Used-Service-Unit ]

[ AoC-Request-Type ]

[ Multiple-Services-Indicator ]

*[ Multiple-Services-Credit-Control ]

*[ Service-Parameter-Info ]

[ CC-Correlation-Id ]

[ User-Equipment-Info ]

[ OC-Supported-Features ]

*[ Proxy-Info ]

*[ Route-Record ]

[ Service-Information ]

*[ AVP ]

Table 6.4.2.1 illustrates the basic structure of a 3GPP Diameter CCR message as used for online charging.

Table 6.4.2.1: 3GPP CCR message content

AVP	Category	Description
Session-Id	M	This field identifies the operation session.
Origin-Host	M	This field contains the identification of the source point of the operation and the realm of the operation originator.
Origin-Realm	M	This field contains the realm of the operation originator.
Destination-Realm	M	This field contains the realm of the operator domain. The realm will be addressed with the domain address of the corresponding public URI.
Auth-Application-Id	M	The field corresponds to the application ID of the Diameter Credit-Control Application and is defined with the value 4.
Service-Context-Id	M	This field indicates the supported protocol version.
CC-Request-Type	M	This field defines the transfer type: event for event based charging and initial, update, terminate for session based charging.
CC-Request-Number	M	This field contains the sequence number of the transferred messages.
Destination-Host	O_C	This field contains the destination peer address of the OCS identity.
User-Name	O_C	Contains the user name determined by the domain: bearer, sub-system or service as described in middle tier TS.
CC-Sub-Session-Id	–	Not used in 3GPP.
Acct-Multi-Session-Id	–	Not used in 3GPP.
Origin-State-Id	O_C	This field contains the state associated to the CTF.
Event-Timestamp	O_C	This field corresponds to the exact time the quota is requested.
Subscription-Id	O_M	This field contains the identification of the user that is going to access the service in order to be identified by the OCS.
Subscription-Id-Type	M	This field determines the type of the identifier, e.g. t value 0 is used for the international E.164 format according to ITU-T E.164 numbering plan.
Subscription-Id-Data	M	This field contains the user data content e.g. the MSISDN.
Service-Identifier	–	Not used in 3GPP.
Termination-Cause	O_C	This field contains the reason the Credit-Control session was terminated.
Requested-Service-Unit	–	Not used in 3GPP, see Multiple-Services-Credit-Control.
CC-Time	–	Not used in 3GPP.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	–	Not used in 3GPP.
CC-Input-Octets	–	Not used in 3GPP.
CC-Output-Octets	–	Not used in 3GPP.
CC-Service-Specific-Units	–	Not used in 3GPP.
AVP	–	Not used in 3GPP.
Requested-Action	O_C	The field defines the type of action if the CC-Request-Type indicates EVENT.
AoC-Request-Type	Oc	This field denotes if AoC Information is requested and what type of information is needed.
Used-Service-Unit	–	Not used in 3GPP, see Multiple-Services-Credit-Control.
Tariff-Change-Usage	–	Not used in 3GPP.
CC-Time	–	Not used in 3GPP.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	–	Not used in 3GPP.
CC-Input-Octets	–	Not used in 3GPP.
CC-Output-Octets	–	Not used in 3GPP.
CC-Service-Specific-Units	–	Not used in 3GPP.
AVP	–	Not used in 3GPP.
Multiple-Services-Indicator	O_M	This field indicates whether the CTF is capable of handling multiple services independently.
Multiple-Services-Credit-Control	O_C	This field contains all parameters for the CTF quota management and defines the quotas to allow traffic to flow.
Granted-Service-Unit	–	Not used in CCR.
Tariff-Time-Change	–	Not used in CCR.
CC-Time	–	Not used in CCR.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	–	Not used in CCR.
CC-Input-Octets	–	Not used in CCR.
CC-Output-Octets	–	Not used in CCR.
CC-Service-Specific-Units	–	Not used in CCR.
AVP	–	Not used in 3GPP.
Requested-Service-Unit	O_C	This field contains the amount of requested service units for a particular category or an indication that units are needed for a particular category, as defined in DCCA [402].
CC-Time	O_C	This field contains the amount of requested time.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	O_C	This field contains the requested amount of octets to be sent and received.
CC-Input-Octets	O_C	This field contains the requested amount of octets to be received.
CC-Output-Octets	O_C	This field contains the requested amount of octets to be sent.
CC-Service-Specific-Units	O_C	This field contains the requested amount of service specific units, e.g. number of events.
AVP	–	Not used in 3GPP.
Used-Service-Unit	O_C	This field contains the amount of used non-monetary service units measured for a particular category to a particular quota type.
Reporting-Reason	O_C	Used as defined in clause 7.2.
Tariff-Change-Usage	O_C	This field identifies the reporting period for the used service unit, i.e. before, after or during tariff change.
CC-Time	O_C	This field contains the amount of used time.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	O_C	This field contains the amount of sent and received octets.
CC-Input-Octets	O_C	This field contains the amount of received octets.
CC-Output-Octets	O_C	This field contains the amount of sent octets.
CC-Service-Specific-Units	O_C	This field contains the amount of service specific units, e.g. number of events.
Event-Charging-TimeStamp	Oc	Used as defined in clause 7.2.
AVP	–	Not used in 3GPP.
Tariff-Change-Usage	–	Not used in 3GPP .
Service-Identifier	O_C	This field contains identity of the used service. This ID with the Service-Context-ID together forms an unique identification of the service.
Rating-Group	O_C	This field contains the identifier of a rating group.
G-S-U-Pool-Reference	–	Not used in CCR.
G-S-U-Pool-Identifier	–	Not used in CCR.
CC-Unit-Type	–	Not used in CCR.
Unit-Value	–	Not used in CCR.
Value-Digits	–	Not used in CCR.
Exponent	–	Not used in CCR.
Validity-Time	–	Not used in CCR.
Result-Code	–	Not used in CCR.
Final-Unit-Indication	–	Not used in CCR.
Final-Unit-Action	–	Not used in CCR.
Restriction-Filter-Rule	–	Not used in CCR.
Filter-Id	–	Not used in CCR.
Redirect-Server	–	Not used in CCR.
Redirect-Address-Type	–	Not used in CCR.
Redirect-Server-Address	–	Not used in CCR.
Time-Quota-Threshold	–	Not used in CCR.
Volume-Quota-Threshold	–	Not used in CCR.
Unit-Quota-Threshold	–	Not used in CCR.
Quota-Holding-Time	–	Not used in CCR.
Quota-Consumption-Time	–	Not used in CCR.
Reporting-Reason	O_C	Used as defined in clause 7.2.
Trigger	O_C	Used as defined in clause 7.2.
Trigger-Type	O_C	Used as defined in clause 7.2.
PS-Furnish-Charging-Information	–	Not used in CCR.
Refund-Information	O_C	Used as defined in clause 7.2.
AF-Correlation-Information	O_C	Used as defined in clause 7.2.
Envelope	O_C	Used as defined in clause 7.2.
Envelope-Start-Time	M	Used as defined in clause 7.2.
Envelope-End-Time	O_C	Used as defined in clause 7.2.
CC-Total-Octets	O_C	Used as defined in clause 7.2.
CC-Input-Octets	O_C	Used as defined in clause 7.2.
CC-Output-Octets	O_C	Used as defined in clause 7.2.
CC-Service-Specific-Units	O_C	Used as defined in clause 7.2
Envelop-Reporting	O_C	Used as defined in clause 7.2.
Time-Quota-Mechanism	O_C	Used as defined in clause 7.2.
Service-Specific-Info	O_C	Used as defined in clause 7.2.
Service-Specific-Type	O_C	Used as defined in clause 7.2.
Service-Specific-Data	O_C	Used as defined in clause 7.2.
QoS-Information	O_C	This field contains authorized QoS applicable for service data flow, which initially triggers the activation of this MSCC instance. Included in first quota request to rating group if service data flow specific QoS control is in use, see TS 29.212 [215] for more information. For IP-CAN bearer specific Rating Group/Service Identifier this field is not included. For TDF, this field contains bandwidth limitation applicable for application traffic and only the Max-Requested-Bandwidth-UL and the Max-Requested-Bandwidth-DL are used.
QoS-Class-Identifier	M	See TS 29.212 [215] for more information.
Max-Requested-Bandwidth-UL	O_C	See TS 29.212 [215] for more information.
Max-Requested-Bandwidth-DL	O_C	See TS 29.212 [215] for more information.
Extended-Max-Requested-BW-UL	O_C	See TS 29.212 [215] for more information.
Extended-Max-Requested-BW-DL	O_C	See TS 29.212 [215] for more information.
Guaranteed-Bitrate-UL	O_C	See TS 29.212 [215] for more information.
Guaranteed-Bitrate-DL	O_C	See TS 29.212 [215] for more information.
Extended-GBR-UL	O_C	See TS 29.212 [215] for more information.
Extended-GBR-DL	O_C	See TS 29.212 [215] for more information.
Bearer-Identifier	O_C	See TS 29.212 [215] for more information.
Allocation-Retention-Priority	O_C	See TS 29.212 [215] for more information.
Priority-Level	O_C	See TS 29.212 [215] for more information.
Pre-emption-Capability	O_C	See TS 29.212 [215] for more information.
Pre-emption-Vulnerability	O_C	See TS 29.212 [215] for more information.
APN-Aggregate-Max-Bitrate-UL	O_C	See TS 29.212 [215] for more information.
APN-Aggregate-Max-Bitrate-DL	O_C	See TS 29.212 [215] for more information.
Extended-APN-AMBR-UL	O_C	See TS 29.212 [215] for more information.
Extended-APN-AMBR-DL	O_C	See TS 29.212 [215] for more information.
Announcement-Information	O_C	Not used in CCR.
3GPP-RAT-Type	O_C	This field contains the RAT Type of the IP-CAN bearer that is first reported for the Rating Group or Rating Group / Service Identifier. If traffic from multiple access types is included in this report, only one field is included. This field is only applicable when NBIFOM is accepted for the IP-CAN session. See TS 29.061 [207] for more information.
Related-Trigger	O_C	This field contains the trigger types for a related trigger for another access in a multi-access PDN connection. This field is only included when the Trigger AVP contains a Trigger-Type AVP with value of "indirect change condition" which is applicable when charging per IP-CAN session for a multi-access PDN connection.
AVP	–	Not used in CCR.
Service-Parameter-Info	–	Not used in 3GPP.
Service-Parameter-Type	–	Not used in 3GPP.
Service-Parameter-Value	–	Not used in 3GPP.
CC-Correlation-Id	O_C	This field contains information to correlate CCRs generated for different components of the service, e.g., transport and service level.
User-Equipment-Info	O_C	This field contains the identification of the identity and terminal capability the subscriber is using for the connection to mobile network if available.
User-Equipment-Info-Type	M	This field determines the type of the identifier. The used value is 0 for the international mobile equipment identifier and software version according to TS 23.003[224].
User-Equipment-Info-Value	M	This field contains the user IMEI.
OC-Supported-Features	O_C	Used as defined in IETF 7683 [411], for more details see clause B.
OC-Feature-Vector	O_C	Used as defined in IETF 7683 [411], for more details see clause B.
Proxy-Info	O_C	This field contains information of the host.
Proxy-Host	M	This field contains the identity of the host that added the Proxy-Info field.
Proxy-State	M	This field contains state local information.
Route-Record	O_C	This field contains an identifier inserted by a relaying or proxying node to identify the node it received the message from.
Service-Information	O_M	This parameter holds the individual service specific parameters as defined in the corresponding ‘middle tier’ TS.
AVP	O_C	This field contains extended Information.

6.4.3 Credit-Control-Answer message

The CCA messages, indicated by the Command-Code field set to 272 is sent by the OCF to the CTF in order to reply to the CCR.

The CCA message format is defined according to RFC 4006 [402] as follows:

< Session-Id >

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

{ Auth-Application-Id }

{ CC-Request-Type }

{ CC-Request-Number }

~~[ User-Name ]~~

[ CC-Session-Failover ]

~~[ CC-Sub-Session-Id ]~~

~~[ Acct-Multi-Session-Id ]~~

~~[ Origin-State-Id ]~~

~~[ Event-Timestamp ]~~

~~[ Granted-Service-Unit ]~~

*[ Multiple-Services-Credit-Control ]

[ Cost-Information]

[ Low-Balance-Indication ]

[ Remaining-Balance ]

~~[ Final-Unit-Indication ]~~

~~[ Check-Balance-Result ]~~

[ Credit-Control-Failure-Handling ]

[ Direct-Debiting-Failure-Handling ]

~~[ Validity-Time]~~

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Redirect-Host]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

*[ Proxy-Info ]

*[ Route-Record ]

[ Failed-AVP ]

[ Service-Information ]

*[ AVP ]

Table 6.4.3.1 illustrates the basic structure of a 3GPP Diameter CCA message as used for online charging. This message is always used by the OCF as specified below, independent of the receiving CTF and the CCR record type that is being replied to.

Table 6.4.3.1: 3GPP CCA message content

AVP	Category	Description
Session-Id	M	This field identifies the operation session.
Result-Code	M	This field contains the result of the specific query.
Experimental-Result	O_C	This field contains the Experimental result of the specific query.
Origin-Host	M	This field contains the identification of the source point of the operation and the realm of the operation originator.
Origin-Realm	M	This field contains the realm of the operation originator.
Auth-Application-Id	M	The field corresponds to the application ID of the Diameter Credit-Control Application and is defined with the value 4.
CC-Request-Type	M	This field defines the transfer type: initial, update, terminate for session based charging and event for event based charging.
CC-Request-Number	M	This field contains the sequence number of the transferred messages.
User-Name	–	Not used in 3GPP.
CC-Session Failover	O_C	This field contains an indication to the CTF whether or not a failover handling is to be used when necessary.
CC-Sub-session-Id	–	Not used in 3GPP.
Acct-Multi-Session-Id	–	Not used in 3GPP.
Origin-State-Id	–	Not used in 3GPP.
Event-Timestamp	–	Not used in 3GPP.
Granted-Service-Unit	–	Not used in 3GPP, see Multiple-Services-Credit-Control.
Tariff-Time-Change	–	Not used in 3GPP.
CC-Time	–	Not used in 3GPP.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	–	Not used in 3GPP.
CC-Input-Octets	–	Not used in 3GPP.
CC-Output-Octets	–	Not used in 3GPP.
CC-Service-Specific-Units	–	Not used in 3GPP.
AVP	–	Not used in 3GPP.
Multiple-Services-Credit-Control	O_C	This field contains all parameters for the CTF quota management and defines the quotas to allow traffic to flow.
Granted-Service-Unit	O_C	This field contains the amount of granted service units for a particular category.
Tariff-Time-Change	O_C	This field contains the switch time when the tariff will be changed.
CC-Time	O_C	This field contains the amount of granted time.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	O_C	This field contains the amount for sent and received octets.
CC-Input-Octets	O_C	This field contains the amount for received octets.
CC-Output-Octets	O_C	This field contains the amount for sent octets.
CC-Service-Specific-Units	O_C	This field contains the amount for service specific units, e.g. number of events.
AVP	–	Not used in 3GPP.
Requested-Service-Unit	–	Not used in CCA.
CC-Time	–	Not used in CCA.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	–	Not used in CCA.
CC-Input-Octets	–	Not used in CCA.
CC-Output-Octets	–	Not used in CCA.
CC-Service-Specific-Units	–	Not used in CCA.
AVP	–	Not used in 3GPP.
Used-Service-Unit	–	Not used in CCA.
Reporting-Reason	–	Not used in CCA.
Tariff-Change-Usage	–	Not used in CCA.
CC-Time	–	Not used in CCA.
CC-Money	–	Not used in 3GPP.
Unit-Value	–	Not used in 3GPP.
Value-Digits	–	Not used in 3GPP.
Exponent	–	Not used in 3GPP.
Currency-Code	–	Not used in 3GPP.
CC-Total-Octets	–	Not used in CCA.
CC-Input-Octets	–	Not used in CCA.
CC-Output-Octets	–	Not used in CCA.
CC-Service-Specific-Units	–	Not used in CCA.
Event-Charging-TimeStamp	–	Not used in CCA.
AVP	–	Not used in 3GPP.
Tariff-Change-Usage	–	Not used in 3GPP.
Service-Identifier	O_C	This field contains identity of the used service. This ID with the Service-Context-ID together forms a unique identification of the service.
Rating-Group	O_C	This field contains the identifier of a rating group.
G-S-U-Pool-Reference	O_C	Only used in ECUR and SCUR.
G-S-U-Pool-Identifier	M	Used as defined in DCCA [402].
CC-Unit-Type	M	Used as defined in DCCA [402].
Unit-Value	M	Used as defined in DCCA [402].
Value-Digits	M	Used as defined in DCCA [402].
Exponent	O_C	Used as defined in DCCA [402].
Validity-Time	O_C	This field defines the time in order to limit the validity of the granted quota for a given category instance.
Result-Code	O_C	This field contains the result of the query.
Final-Unit-Indication	O_C	This field indicates that the Granted-Service-Unit AVP containing the final units for the service.
Final-Unit-Action	M	Used as defined in DCCA [402].
Restriction-Filter-Rule	O_C	Used as defined in DCCA [402].
Filter-Id	O_C	Used as defined in DCCA [402].
Redirect-Server	O_C	Used as defined in DCCA [402].
Redirect-Address-Type	M	Used as defined in DCCA [402].
Redirect-Server-Address	M	Used as defined in DCCA [402].
Time-Quota-Threshold	O_C	Used as defined in clause 7.2.
Volume-Quota-Threshold	O_C	Used as defined in clause 7.2.
Unit-Quota-Threshold	O_C	Used as defined in clause 7.2.
Quota-Holding-Time	O_C	Used as defined in clause 7.2.
Quota-Consumption-Time	O_C	Used as defined in clause 7.2.
Reporting-Reason	–	Not used in CCA.
Trigger	Oc	Used as defined in clause 7.2.
Trigger-Type	O_C	Used as defined in clause 7.2.
PS-Furnish-Charging-Information	O_C	Used as defined in clause 7.2.
Refund-Information	O_C	Used as defined in clause 7.2.
AF-Correlation-Information	–	Not used in CCA.

Envelope-Reporting	O_C	Used as defined in clause 7.2.
Time-Quota-Mechanism	O_C	Used as defined in clause 7.2.
Time-Quota-Type	M	Used as defined in clause 7.2.
Base-Time-Interval	M	Used as defined in clause 7.2.
AF-Correlation-Information	–	Not used in CCA.
Service-Specific-Info	–	Not used in CCA.
QoS-Information	–	Not used in CCA.
Announcement-Information	O_C	This field contains the Announcement service parameters. Each instance specifies a single announcement to be played to the specified user.
Announcement-Identifier	M	This field contains a code identifying an announcement to be played.
Variable-Part	O_C	This field contains the parameters necessary to define playback of a variable within the announcement.
Variable-Part-Order	O_C	This field identifies the order of the variable to be played back.
Variable-Part-Type	M	This field identifies the type of the variable to be played back.
Variable-Part-Value	M	This field identifies the value of the variable to be played back.
Time-Indicator	O_C	This field instructs the announcement to be connected at the specified time before granted quota is exhausted.
Quota-Indicator	O_C	This field indicates whether granted quota is to be used during announcement setup and playback.
Announcement-Order	O_C	This field contains the order in which announcements should be connected for playback when there are multiple announcements provided in a single message with the same timing indicator.
Play-Alternative	O_C	This field indicates the call party toward whom an announcement is directed.
Privacy-Indicator	O_C	This field indicates whether the announcement is considered private and is only to be played to the requested party.
Language	O_C	This field contains a code indicating the language of the announcement that should be played.
3GPP-RAT-Type	–	Not used in CCA.
Related-Trigger	–	Not used in CCA
AVP	–	Not used in 3GPP.
Cost-Information	O_C	Used as defined in DCCA [402].
Unit-Value	M	Used as defined in DCCA [402].
Value-Digits	M	Used as defined in DCCA [402].
Exponent	O_C	Used as defined in DCCA [402].
Currency-Code	M	Used as defined in DCCA [402].
Cost-Unit	O_C	Used as defined in DCCA [402].
Low-Balance-Indication	Oc	This field indicates whether the subscriber account balance went below a designated threshold set by his account.
Remaining-Balance	O_C	This field contains the remaining balance of the subscriber.
Unit-Value	M	Used as defined in DCCA [402].
Value-Digits	M	Used as defined in DCCA [402].
Exponent	O_C	Used as defined in DCCA [402].
Currency-Code	M	Used as defined in DCCA [402].
Final-Unit-Indication	–	Not used in 3GPP, see Multiple-Services-Credit-Control.
Final-Unit-Action	–	Not used in 3GPP.
Restriction-Filter-Rule	–	Not used in 3GPP.
Filter-Id	–	Not used in 3GPP.
Redirect-Server	–	Not used in 3GPP.
Redirect-Address-Type	–	Not used in 3GPP.
Redirect-Server-Address	–	Not used in 3GPP.
Check-Balance-Result	–	Not used in 3GPP.
Credit-Control-Failure-Handling	O_C	Used as defined in DCCA [402].
Direct-Debiting-Failure-Handling	O_C	Used as defined in DCCA [402].
Validity-Time	–	Not used in 3GPP.
OC-Supported-Features	O_C	Used as defined in IETF 7683 [411], for more details see clause B.
OC-Feature-Vector	O_C	Used as defined in IETF 7683 [411], for more details see clause B.
OC-OLR	O_C	Used as defined in IETF 7683 [411], for more details see clause B.
Redirect-Host	O_C	Used by redirect agent function as specified in [401]. Contains the host the request should be forwarded to.
Redirect-Host-Usage	O_C	Used by redirect agent function as specified in [401]. Dictates how the routing entry resulting from the Redirect-Host is to be used.
Redirect-Max-Cache-Time	O_C	Used by redirect agent function as specified in [401]. Contains the maximum number of seconds the peer and route table entries, created as a result of the Redirect-Host, will be cached.
Proxy-Info	O_C	This field contains information of the host.
Proxy-Host	M	This field contains the identity of the host that added the Proxy-Info field.
Proxy-State	M	This field contains state local information.
Route-Record	O_C	This field contains an identifier inserted by a relaying or proxying node to identify the node it received the message from.
Failed-AVP	O_C	This field contains the AVP that could not be processed successfully. This field can occur only once.
Service-Information	O_C	This parameter holds the individual service specific parameters as defined in the corresponding ‘middle tier’ TS.
AVP	O_C	This field contains extended Information.

6.4.4 Re-Auth-Request message

The DCCA RAR message format is defined according to the Diameter Base Protocol in RFC 6733 [401] and DCCA specification in RFC 4006 [402]:

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

{ Re-Auth-Request-Type }

[ User-Name ]

[ Origin-State-Id ]

*[ Proxy-Info ]

*[ Route-Record ]

~~[ CC-Sub-Session-Id ]~~

[ G-S-U-Pool-Identifier ]

[ Service-Identifier ]

[ Rating-Group ]

*[ AVP ]

Table 6.4.4.1 illustrates the basic structure of a Diameter Credit-Control Re-Auth-Request message as used for online charging.

Table 6.4.4.1: RAR message contents for online charging

AVP	Category	Description
Session-Id	M	This field identifies the operation session.
Origin-Host	M	This field contains the identification of the source point of the operation and the realm of the operation originator.
Origin-Realm	M	This field contains the realm of the operation originator.
Destination-Realm	M	This field contains the realm of the operator domain. The realm will be addressed with the domain address of the corresponding public URI.
Destination-Host	M	This field contains the destination peer address of the OCS identity.
Auth-Application-Id	M	The field corresponds to the application ID of the Diameter Credit-Control Application and is defined with the value 4.
Re-Auth-Request-Type	M	This field is used to inform the CTF of the action expected upon expiration of the Authorization-Lifetime
User-Name	O_C	This field contains the username.
Origin-State-Id	O_C	This field contains the state associated to the CTF.
Proxy-Info	O_C	This field contains information of the host.
Proxy-Host	M	This field contains the identity of the host that added the Proxy-Info field.
Proxy-State	M	This field contains state local information.
Route-Record	O_C	This field contains an identifier inserted by a relaying or proxying node to identify the node it received the message from.
CC-Sub-Session-Id	–	Not used in 3GPP.
G-S-U-Pool-Identifier	O_C	This field contains an identifier to indicate the credit pool.
Service-Identifier	O_C	This field contains identity of the used service. This ID with the Service-Context-ID together forms an unique identification of the service.
Rating-Group	O_C	This field contains the identifier of a rating group.
AVP	O_C	This field contains extended Information.

6.4.5 Re-Auth-Answer message

The DCCA RAA message format is defined according to the Diameter Base Protocol in RFC 6733 [401] and DCCA specification in RFC 4006 [402]:

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ User-Name ]

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

[ Failed-AVP ]

*[ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Host-Cache-Time ]

*[ Proxy-Info ]

~~[ CC-Sub-Session-Id ]~~

~~[ G-S-U-Pool-Identifier ]~~

~~[ Service-Identifier ]~~

~~[ Rating-Group ]~~

*[ AVP ]

Table 6.4.5.1 illustrates the basic structure of a Diameter Credit-Control Re-Auth-Answer message as used for online charging.

Table 6.4.5.1: RAA message contents for online charging

AVP	Category	Description
Session-Id	M	This field identifies the operation session.
Result-Code	M	This field contains the result of the specific query.
Origin-Host	M	This field contains the identification of the source point of the operation and the realm of the operation originator.
Origin-Realm	M	This field contains the realm of the operation originator.
User-Name	O_C	This field contains the username.
Origin-State-Id	O_C	This field contains the state associated to the source point of the operation.
Error-Message	O_C	This field contains a human readable error message.
Error-Reporting-Host	O_C	This field contains the identity of the Diameter host that sent the Result-Code AVP to a value other than 2001 (Success) if the host setting the Result-Code is different from the one encoded in the Origin-Host AVP.
Failed-AVP	O_C	This field contains the AVP that could not be processed sucessfully. This field can occur only once.
Redirect-Host	O_C	Used by redirect agent function as specified in [401]. Contains the host the request should be forwarded to.
Redirect-Host-Usage	O_C	Used by redirect agent function as specified in [401]. Dictates how the routing entry resulting from the Redirect-Host is to be used.
Redirect-Max-Cache-Time	O_C	Used by redirect agent function as specified in [401]. Contains the maximum number of seconds the peer and route table entries, created as a result of the Redirect-Host, will be cached.
Proxy-Info	O_C	This field contains information of the host.
Proxy-Host	M	This field contains the identity of the host that added the Proxy-Info field.
Proxy-State	M	This field contains state local information.
CC-Sub-Session-Id	–	Not used in 3GPP.
G-S-U-Pool-Identifier	–	Not used in 3GPP.
Service-Identifier	–	Not used in 3GPP.
Rating-Group	–	Not used in 3GPP.
AVP	O_C	This field contains extended Information.

6.4.6 Capabilities-Exchange-Request message

The Capabilities-Exchange-Request message structure shall be as specified in RFC 6733 [401] clause 5.3.1.

6.4.7 Capabilities-Exchange-Answer message

The Capabilities-Exchange-Answer message structure shall be as specified in RFC 6733 [401] clause 5.3.2.

6.4.8 Device-Watchdog-Request message

The Device-Watchdog-Request message structure shall be as specified in RFC 6733 [401] clause 5.5.1.

6.4.9 Device-Watchdog-Answer message

The Device-Watchdog-Answer message structure shall be as specified in RFC 6733 [401] clause 5.5.2.

6.4.10 Disconnect-Peer-Request message

The Disconnect-Peer-Request message structure shall be as specified in RFC 6733 [401] clause 5.4.1.

6.4.11 Disconnect-Peer-Answer message

The Disconnect-Peer-Answer message structure shall be as specified in RFC 6733 [401] clause 5.4.2.

6.4.12 Abort-Session-Request message

The Abort-Session-Request message structure shall be as specified in RFC 6733 [401] clause 8.5.1.

6.4.13 Abort-Session -Answer message

The Abort-Session-Answer message structure shall be as specified in RFC 6733 [401] clause 8.5.2.

6.5 Other procedural description of the 3GPP charging applications

6.5.1 Re-Authorization

6.5.1.1 Idle timeout

The server may specify an idle timeout associated with a granted quota using the Quota-Holding-Time AVP.
If no traffic associated with the quota is observed for this time, the client shall understand that the traffic has stopped and the quota is returned to the server. The client shall start the quota holding timer when quota consumption ceases. This is always when traffic ceases, i.e. the timer is re-started at the end of each packet. It applies equally to the granted time quota and to the granted volume quota. The timer is stopped on sending a CCR and re-initialised on receiving a CCA with the previous used value or a new value of Quota-Holding-Time AVP if received.

Alternatively, if this AVP is not present, a locally configurable default value in the client shall be used.
A Quota-Holding-Time AVP value of zero indicates that this mechanism shall not be used.

6.5.1.2 Change of charging conditions

There are a number of mid-session service events (re-authorization triggers), which could affect the rating of the current service usage, e.g. end user QoS changes or location updates. When allocating resources, the server may instruct the Credit-Control client to re-authorize the quota upon a number of different session related triggers that can affect the rating conditions. The server instruct the Network Element to monitor for such events by using the Trigger AVP containing one or more Trigger-Type AVPs in the CCA command. These events are in addition to the static triggers defined in the service specific document (middle tier TS).

Once the OCS has armed one or more triggers using the Trigger AVP at the Network Element, these triggers shall remain in effect until another Trigger AVP is received for the same Rating Group, where the Network Element shall arm all triggers present in the Trigger AVP and reset all other triggers. The presence of the Trigger AVP without any Trigger-Type AVPs in a CCA allows OCS to disable all the triggers that were armed in a previous Trigger AVP.

NOTE: This removes the need for the OCS to send trigger information in every CCA message when they have not changed.

When one of the armed triggers happen, a credit re-authorization shall be sent to the server including information related to the service event even if all the granted service units have not been used. The quota is also being reported.

For example, if the Trigger AVP is used, then the client shall only re-authorize the quota for the service usage associated with events which were included in the last received Trigger AVP.

If the server does not control the events for re-authorization using the Trigger AVP, the Network Element shall only monitor for default events defined in the relevant service specific document (middle tier TS).

6.5.1.3 Reporting quota usage

The Credit-Control client shall report the quota usage under a number of circumstances. When this happens, the reason for the quota being reported is notified to the server through the use of the Reporting-Reason AVP in the CCR. The reason for reporting credit usage can occur directly in the Multiple-Services-Credit-Control AVP, or in the Used-Service-Units AVP, depending on whether it applies for all quota types or a particular quota type respectively. It shall not be used at command level. It shall always and shall only be sent when usage is being reported.

When the reason is RATING_CONDITION_CHANGE, the Trigger AVP shall also be included to indicate the specific armed trigger events which caused the reporting and re-authorization request.

6.5.1.4 Quota consumption

The consumption of quota is captured using mechanisms described in clause 6.5.1.3.

Volume quota is considered used or consumed in the normal way, corresponding to actual traffic.

The consumption of time quota may be controlled by Quota-Consumption-Time as described in clause 6.5.4, or by extended mechanisms as described in clause 6.5.7.

6.5.2 Threshold based Re-Authorization triggers

The server may optionally include as part of the Multiple-Services-Credit-Control AVP, when it is providing a quota, an indication to the client of the remaining quota threshold that shall trigger a quota re-authorization.
The Time-Quota-Threshold AVP indicates the threshold in seconds when the granted quota is time, and the Volume-Quota-Threshold AVP indicates the threshold in octets when the granted quota is volume.
The Unit-Quota-Threshold AVP indicates the threshold in service specific units, that are defined in the service specific documents, when the granted quota is service specific.

If the threshold triggers were included along with the quota granted, the Credit-Control client, then, shall seek re-authorization from the server for the quota when the quota contents fall below the supplied threshold. The client shall allow service to continue whilst the re-authorization is progress, until the original quota had been consumed.

6.5.3 Termination action

The termination action is sent over the Ro reference point. Two different approaches are specified:

– The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does not include any other information. When the user has consumed the final granted units or zero quota has been granted by the OCS, the Network Element shall terminate the service. This is the default handling applicable whenever the client receives an unsupported Final-Unit-Action value. The Network Element shall send CCR message with CC-Request-Type AVP set to the value UPDATE_REQUEST and report the Used-Service-Unit AVP for the service that has terminated, as defined in RFC 4006 [402].

– Another termination action consists in re-directing packets corresponding to a terminated service (consumption of the final granted units or zero quota has been granted by the OCS) to an application server. This allows the client to redirect user originated requests to a top-up server so that network access can be re-instated. This functionality is achieved with the server returning a "REDIRECT" and redirect-to URL in the Final-Units-Action AVP of the Multiple-Services-Credit-Control AVP. Upon receiving this result code, the Network Element shall apply the redirection. The URL should be categorized so that the End-User’s ability to reach it is guaranteed.

When zero quota has been granted by the OCS, the termination action shall be enforced at the reception of the CCA message.

6.5.4 Quota consumption time

The server may optionally indicate to the client that the quota consumption shall be stopped after a period equal to the Quota Consumption Time in which no packets are received or at session termination, whichever is sooner. This is indicated by including the Quota-Consumption-Time AVP in the CCA. The idle period equal to the Quota Consumption Time is included in the reported usage. The quota is consumed normally during gaps in traffic of duration less than or equal to the Quota-Consumption-Time. Quota consumption resumes on receipt of a further packet belonging to the service data flow.

If packets are allowed to flow during a CCR/CCA[Update] exchange, and the Quota-Consumption-Time AVP value in the provided quota is the same as in the previously provided quota, then the Quota-Consumption-Time runs normally through this procedure. For example, if 5 seconds of a 10 second QCT timer have passed when a CCR[Update] is triggered, and the CCA[Update] returns 2 seconds later, then the QCT timer will expire 3 seconds after the receipt of the CCA and the remaining unaccounted 5 seconds of usage will be recorded against the new quota even though no packets were transmitted with the new quota.

In the case of a new quota with the Quota-Consumption-Time AVP, or when packets are blocked during the CCR/CCA [Update] procedure then the Quota-Consumption-Time stops running (if it was running) and quota consumption begins again when the next service data flow packet matching the Charging Rule is received.

If a Quota-Consumption-Time AVP value of zero is provided, or if no Quota-Consumption-Time AVP is present in the CCA, the quota is consumed continuously from the point at which it is granted.

6.5.5 Service termination

The OCF may determine that a service requires termination. The OCF may perform this termination synchronously if it has a CCR pending processing by returning CCA with Result-Code AVP with value DIAMETER-AUTHORIZATION-REJECTED. If the OCF does not have a pending request (asynchronous), the OCF may trigger an ASR to terminate the Diameter session related to the service. On reception of an ASR, the CTF shall close the associated Credit-Control session by sending a CCR [Terminate]. The behaviour of the CTF, in relation to the user session, on reception of an ASR is detailed in the middle-tier TS. As an alternative to the ASR, the OCF may trigger a RAR to which the CTF behaves as described in RFC 4006 [402] and the OCF shall return a CCA with Result-Code AVP with value DIAMETER-AUTHORIZATION-REJECTED for the resulting CCR.

6.5.6 Envelope reporting

6.5.6.1 Envelope reporting in Online Charging

The OCF may determine the need for additional detailed reports identifying start time and end times of specific activity in addition to the standard quota management provided in RFC 4006 [402]. The OCF controls this by sending a CCA[INITIAL] with Envelope-Reporting AVP. The OCF may request reports for just time, time and volume, time and number of events, or time and volume and number of events, through appropriate values in Envelope-Reporting AVP.

The time envelope of the activity to be reported is determined by the mechanism indicated by the OCF in this CCA[INITIAL], to control the time quota consumption in the CTF.

The selected mechanism is used by the CTF to generate the envelopes, reporting the start and end of each time envelope, and the data volume transferred and / or the number of events that occurred for the duration of the envelope

NOTE: Envelope reporting is independent of quota management (i.e. there is no interaction).

6.5.6.2 Envelope reporting in Offline Charging

When a particular time quota consumption mechanism is selected by the OCF, the need for reporting detailed time envelopes in offline charging, may be statically configured in the CTF or dynamically controlled by the OCF using Offline-Charging AVP.

The selected time quota consumption mechanism is used by the CTF to generate the envelopes, reporting the start and end of each time envelope, and the data volume transferred and / or the number of events that occurred for the duration of the envelope.

6.5.6.3 Envelope reporting – Quota consumption time

In case the time quota consumption mechanism selected by the OCF is per clause 6.5.4, and the OCF indicated the need for envelope reporting,.the CTF, on receiving the command, monitors the traffic for a period of time controlled by the Quota-Consumption-Time AVP and reports each period as a single envelope for each Quota-Consumption-Time expiry where there was traffic, in Envelope AVP.

6.5.6.4 Envelope reporting – Combinational quota

In case the time quota consumption mechanism selected by the OCF is per clause 6.5.7, and the OCF indicated the need for envelope reporting, the CTF, on receiving the command, monitors the traffic based on information included in Time-Quota-Mechanism AVP, and reports each corresponding envelope in the Envelope AVP in the CCR.

In case of Continuous Time Period (CTP):

– the first envelope starts on the first traffic, and subsequent envelopes start on the first traffic following the closure of the previous envelope.

– each envelope ends at expiry of the first base time interval which contains no traffic.

The envelope for CTP includes the last base time interval, i.e. the one which contained no traffic. The end of an envelope can only be determined "retrospectively".

In case of Discrete Time Period (DTP), an envelope corresponds to exactly one base time interval.

6.5.7 Combinational quota

The Quota-Consumption-Time mechanism, described in clause 6.5.4, may be extended (and replaced) when granting time based quota to provide potentially more efficient use of the online charging interface, i.e. reduced traffic and the algorithms in the OCF are potentially simpler. The alternative handling mechanisms that are defined in this clause are:

1. Continuous Time Period (CTP)

2. Discrete Time Period (DTP)

The mechanisms selected by the OCF is indicated to the CTF with the Time-Quota-Mechanism AVP in the CCA.

The base time interval, specified by the Base-Time-Interval AVP, is a basic unit for consuming quota. Quota is deemed to be consumed at the start of each base time interval. The CTF shall allow traffic to pass for the duration of the base time interval.

For DTP, the base time interval defines the length of the discrete time period. Quota consumption resumes only on the first traffic following the expiry of the DTP.

For CTP, quota consumption continues during consecutive base time intervals in which traffic has occurred up to and including the first base time interval which contains no traffic. Quota consumption shall be stopped after this first base time interval expiry which contained no traffic. Quota consumption resumes only on the first subsequent traffic.

If the CTF receives a Multiple-Services-Credit-Control AVP with both the Quota-Consumption-Time AVP and Time-Quota-Mechanism AVP, then the Time-Quota-Mechanism AVP takes precedence and the CTF shall behave accordingly.

6.5.8 Online control of offline charging information

The Offline-Charging AVP is used on the Ro interface by the OCS to control the CTF in relation to the mechanism by which the CTF generates offline charging information, e.g. for flow based charging controls the formation of service data containers. The information contained, within the Offline-Charging AVP, takes precedence over the default configuration at the CTF. If the Offline-Charging AVP is not sent in the CCA, the OCS does not control the offline charging mechanisms and therefore the default configuration at the CTF is employed.

Controls over time usage, defined in clause 6.5.6 and clause 6.5.7, are included.

6.5.9 Support of multiple service

The support of multiple services within a single Diameter session in 3GPP is limited to services that are grouped in one of the middle tier TSs specified through the Service-Context-Id AVP.

6.5.10 Supported Features mechanism

6.5.10.1 Introduction

Supported Features mechanism is used for 3GPP Charging Applications as specified in TS 29.229 [204] clause 7.2, based on the Supported-Features AVP.

6.5.10.2 Defining a feature

The concept of feature used by the Supported Features mechanism, applies under a specific domain / subsystem / service, and is defined as an extension of the base offline and online charging functionality specified in the corresponding middle tier.

For each middle tier, the base functionality is the one specified by the 3GPP Rel-14 version, and for any extension introduced from Rel-15, the Supported Features mechanism is required.

For any middle tier created from Rel-15, the Supported Features mechanism is required to be introduced.

Applicability of a feature is defined separately between offline (Rf) and online(Ro) charging.

Any feature specified for offline and online charging, when invoked by the client, is defined as mandatory to be supported by the server.

As specified in TS 29.229 [204] clause 7.1.1, if new AVPs are added as part of the feature definition, they shall have the ‘M’ bit cleared and shall not be defined mandatory in the command ABNF.

6.5.10.3 Supported Feature handling

Any request initiated by the client which makes use of a feature to construct the request, and requires the feature to be supported by the server, shall include the feature associated to the service-context in the Supported-Features AVP.

The client shall include in the request feature(s) and only feature(s) which are needed to construct the request.

In case multiple features are needed to construct the request, they shall all be included by the client.

As defined in TS 29.229 [204], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs.

The value 10415 (3GPP) is used as Vendor-Id, and the Feature-List-ID and Feature-List are defined per middle tier TS.

Upon receiving any initial Ro or Rf request for a specific domain / subsystem / service, which does not include any Supported-Features AVP, the server shall include in the answer, if supported, Supported-Features AVPs identifying the complete set of features supported by the server for this domain / subsystem / service. This applies regardless of the answer is successful or not.

Upon receiving any initial Ro or Rf request for a specific domain / subsystem / service, which includes the Supported-Features AVP, the server shall behave as follows:

– If all features indicated in the Supported-Features AVP are supported, and the process for online or offline charging is successful, a successful answer with the Result-Code AVP set to DIAMETER_SUCCESS is returned and includes, if supported, Supported-Features AVPs identifying the complete set of features supported by the server for this domain / subsystem / service.

– If not all the features indicated in the Supported-Features AVP are supported, the answer is returned with Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED and includes the Supported-Features AVPs containing lists of all features supported by the server.

– If Supported-Features AVP is not supported by the server, the answer is returned, as per ‘M’ bit set rule, with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED and a Failed-AVP AVP containing at least one Supported-Features AVP as received in the request.

During the lifetime of the Diameter session, the client shall use the set of features which are common between its own set of supported features and the set of supported features indicated by the server during the Diameter session establishment, in session based charging.

6.6 Bindings of the operation to protocol application

6.6.0 General

This clause aims to describe the mapping between the protocol independent messages and parameter with the Diameter messages and AVP utilized on the 3GPP offline and online charging.

6.6.1 Bindings of Charging Data Transfer to Accounting

Table 6.6.1.1 describes the bindings of the Charging Data Transfer operation parameter to the DBPA AVP for 3GPP offline charging.

Table 6.6.1.1: Bindings to Accounting

Charging Data Transfer element	Diameter Accounting AVP
Operation Number	Accounting-Record-Number
Operation Type	Accounting-Record-Type
Operation Identifier	Acct-Application-Id
Operation Interval	Acct-Interim-Interval
Destination Domain	Destination-Realm
Error Reporting Host	Error-Reporting-Host
Origination Timestamp	Event-Timestamp
Originator Host	Origin-Host
Originator Domain	Origin-Realm
Origination State	Origin-State-Id
Proxy Information	Proxy-Info
Operation Result	Result-Code
Route Information	Route-Record
Service Information	Service-Information
Session Identifier	Session-Id
Operation Token	Service-Context-Id
User Name	User-Name

6.6.2 Bindings of Debit / Reserve Units to Credit-Control

Table 6.6.2.1 describes the bindings of the Debit / Reserve Units operation parameter to the DCCA AVP for 3GPP 0nline charging.

Table 6.6.2.1: Bindings to Credit-Control

Debit / Reserve Units element	DCCA AVP
AoC Type	AoC-Request-Type
Cost Information	Cost-Information
Destination Domain	Destination-Realm
Destination Host	Destination-Host
Failed parameter	Failed-AVP
Low Balance Indication	Low-Balance-Indication
Multiple Operation	Multiple-Services-Indicator
Multiple Unit Operation	Multiple-Services-Credit-Control
Operation Correlation	CC-Correlation-Id
Operation Failover	CC-Session-Failover
Operation Failure Action	Credit-Control-Failure-Handling
Operation Identifier	Auth-Application-Id
Operation Number	CC-Request-Number
Operation Result	Result-Code
Operation Token	Service-Context-Id
Operation Type	CC-Request-Type
Origination State	Origin-State-Id
Origination Timestamp	Event-Timestamp
Originator Domain	Origin-Realm
Originator Host	Origin-Host
Proxy Information	Proxy-Info
Redirection Cache Time	Redirect-Max-Cache-Time
Redirection Host	Redirect-Host
Redirection Host Usage	Redirect-Host-Usage
Remaining Balance	Remaining-Balance
Requested Action	Requested-Action
Route Information	Route-Record
Service Information	Service-Information
Session Identifier	Session-Id
Subscriber Equipment Number	User-Equipment-Info
Subscriber Identifier	Subscription-Id
Termination Cause	Termination-Cause
User Name	User-Name

6.7 Securing Diameter messages

For secure transport of Diameter messages used for offline and online charging application, see 3GPP TS 33.210 [246].