Content for TS 32.240 Word version: 19.0.0

1… 3… 4… 4.2.3 4.2.4 4.3… 4.4… 4.5… 5… 5.3… A… C… D… E… F… G…

5.0 General 5.1 Charging data generation and quota supervision 5.2 Charging data transfer 5.2.0 General 5.2.1 Charging data transfer in offline charging 5.2.2 Charging data transfer in online charging 5.2.3 Charging data transfer in converged charging
...

5 Charging principles p. 43

5.0 General |R12| p. 43

The high-level requirements for charging are specified in TS 22.115. The following sub-clauses detail the charging principles on the basis of the architecture and framework defined in clause 4, in respect of:

Charging data generation and quota supervision;
Aspects of charging information transfer;
Charging levels and charging data correlation;
Charging information utilisation.

5.1 Charging data generation and quota supervision p. 43

The CTF embedded in all charging relevant network elements/network functions collects charging information within the NE/NF concerning the use of network resources by the mobile end users. These network resources may pertain to bearer (e.g. CS, PS), PDU session (e.g. 5GS), subsystem (e.g. IMS sessions) or service (e.g. MMS) usage / consumption. The various charging levels are further described in clause 5.3.

The purpose of offline charging is to transform the charging information into CDRs that are post-processed within the BD, e.g. for the purpose of generating bills. While the collection of charging information used for the CDRs occurs during the network resource usage, there is no impact of offline charging on the use of the resources. All activities involved in the transformation of the charging information into end user bills, and the collection of the end user charges incurred in these bills, occur offline to, or after, the network resource usage.

The purpose of online charging is to furnish charging information to the OCS/CCS in order to perform Credit-Control before the network resource usage is permitted. To this end, a prepaid subscriber account has to exist in the OCS/CCS, against which the resource usage can be billed. Hence all activities to assess the requested resource usage, to determine its value in monetary or other units, and to debit these units from the subscriber account, must occur prior to or at least, during the resource usage, i.e. online with respect to resource usage. Depending on the circumstances, a final evaluation must occur when resource usage ends. Hence, two cases must be distinguished:

Direct Debiting: the requested resource can be determined and billed in a one-off procedure. In that case, the resource usage is debited from the subscriber account immediately when processing the charging event, and the permission for the resource usage is returned to the network. An example of this may be the forwarding of a terminating short message from the MSC to the end user. In this scenario, it is generally required that the network can guarantee resource usage execution in order to avoid over-billing the user.
Unit Reservation: the OCS/CCS cannot a priori know the amount of resources that the end user may eventually consume, or it cannot be assumed a priori that the resource usage request can be (completely) fulfilled. In this case, a certain amount of (monetary or non-monetary) units is blocked, or reserved, on the subscriber's account on the OCS/CCS, and permission to use an amount of resources that matches the unit reservation is returned to the network. When the granted units have been used or a new, not yet authorised chargeable event occurs, the network must send a new request for unit allocation to the OCS/CCS. When resource usage has been executed, the actual amount of resource usage (i.e. the used units) must be returned by the NE/NF to the OCS/CCS so that eventually over-reserved amounts can be re-credited to the subscriber account, assuring that the correct amount gets debited.

Charging information is collected by the CTF based on chargeable events that describe the user(s) and their requested network resource usage. The chargeable events are specific to each domain / service / subsystem and specified in the respective middle tier TS. For each chargeable event, a matching charging event is formed and immediately sent to its destination, i.e. the CDF in offline charging,the OCF in online charging or CHF in the converged charging. Again, the event information is specific to the domain / service / subsystem and defined in the respective middle tier TS. While the accounting metrics (provided by the Accounting Metrics Collection part of the CTF) used in online, offline and converged charging are generally identical, the information comprising chargeable events (determined by the Accounting Data Forwarding part of the CTF) may be different between online,offline and converged charging. Note also that online and offline charging may occur simultaneously, i.e. for the same resource usage the CTF may send an offline charging event to the CDF and an online charging event to the OCF. In that particular case, Credit-Controloccurs for that resource usage but at the same time, CDRs are created in offline charging. Alternatively, if CDRs are required for online charged resource usage, this can be achieved by generating these CDRs in the OCS, as depicted in clause 4.3.2.3.

The online,offline charging and converged charging can be categorised into two distinct classes, namely event based charging and session based charging. Event based charging implies that a chargeable event is defined as a single end-user-to-network transaction, e.g. the sending of a multimedia message. This chargeable event is then mapped to an appropriate charging event, resulting in a single CDR or in a single Credit-Control and resource usage authorisation procedure. In contrast, session based charging is characterised by the existence of a user session, such as a circuit call, an IP CAN bearer, an PDU session, or an IMS session. This user session is then matched by a charging session, resulting in the generation of multiple chargeable/charging events and the creation of one or more CDRs in offline charging/converged charging or the performance of a Credit-Control session in online charging/converged charging. The following paragraphs describe the event versus session based charging in more detail for both online, offline charging. converged charging.

Event based charging: The (chargeable) event is recognised in the NE /NF that handles it, based on e.g. signalling exchange between the user equipment and the NE/NF. The event is then mapped onto a single charging event as specified in the middle tier TS that applies to that NE/NF.
- In online charging, the charging event is transferred to the EBCF via the Ro or CAP reference point, and the chargeable event is authorised after successfully performing Credit-Control on the subscriber account. The complete procedure must occur in real-time. If the chargeable event is not authorised by the OCS (e.g. when the subscriber account does not contain sufficient credit), the NE rejects the resource usage pertaining to that chargeable event.
- The event charging procedure may occur with or without reservation of units from the subscriber's account ("Event Charging with Unit Reservation" (ECUR),"Immediate Event Charging" (IEC) or "Post Event Charging" (PEC), respectively), as described above. Furthermore, if the procedure does include reservation, the OCS/CCS may choose to authorise one or more occurrences of the chargeable event (i.e. allot one or more "service"units). For example, multiple short messages may be authorised upon the first SMS request from the user.
- In offline charging, the charging event is transferred to the CDF via the Rf reference point. The CDF produces a matching CDR, which is then sent to the CGF via the Ga reference point. The CDR will eventually be transferred to the BD in a CDR file, together with other CDRs of the same or different types, according to file transfer configuration by the operator. While there is no real-time requirement on any particular part of this procedure, the system should be capable of completing the process from the detection of the chargeable event up to, and including, CDR transfer to the CGF, in near real-time.
Session based charging: The start of the user session is recognised by the NE/NF that handles the session, based on e.g. signalling exchange between the user equipment and the NE/NF. This chargeable event is then mapped onto a charging event as specified in the middle tier TS that applies to that NE/NF.
- In online charging, an "initial" charging event (session start) is transferred to the SBCF via the Ro or CAP reference point and the start of the user session is authorised after successfully performing Credit-Control on the subscriber account. The NE may delay the actual start of the user session until authorisation has been obtained (cf. 4.3.2.1). As there is no information available at this time concerning the overall evaluation of the session (e.g. complete duration or data volume of the session), session based charging always involves reservation of units from the subscriber's account ("Session based Charging with Unit Reservation" (SCUR)): the OCS reserves credit from the subscriber account and returns the corresponding quota (e.g. units specifying the number of minutes or bytes allowed) to the NE. The NE, in turn, uses the provided quota to supervise the actual network resource consumption. In the case that another chargeable event occurs for the session, the network element issues an "interim" charging event in order to also authorise this new chargeable event. When the quota is used up, the network element either issues another interim charging event, requesting further units to be allotted, or terminates the session if previously instructed to do so by the OCS. Once the session is terminated in the network element, the consumed units are reported back to the OCS with a "final" charging event. The credit control session is then terminated, and the OCS returns the value of any unused quota (as reported by the NE) to the subscriber's account. The complete procedure of receiving, processing and responding to an online charging event, must occur in real-time. Note that this procedure can occur in parallel for several concurrent services running on the same user session.
  For each charging event received during the session, the OCS/CCS decides whether to authorise the resource usage or whether to decline the request (e.g. when the subscriber account does not contain sufficient credit). If, at any time within the session, the OCS/CCS determines not to authorise the chargeable event, it rejects the request sent by the network element/network functions, causing the NE/NF to disallow the resource usage pertaining to that chargeable event. It must be noted that this does not necessarily terminate the user session. E.g. in the case of credit exhaustion, the session could be redirected to a credit recharging site.
- In offline charging, the "initial" charging event is transferred to the CDF via the Rf reference point. Upon termination of the subscriber session, or when a new chargeable event occurs (as specified in the respective middle tier TS), further charging events ("final" or "interim" events, respectively) are sent for the session from the NE to the CDF. The CDF formats one or more of these events into CDRs according to CDR formats specified in the middle tier TSs, and in accordance with CDR generation triggers configured by the operator. Upon its completion, the CDR will be sent forward to the CGF via the Ga reference point, and a new CDR will be opened by the CDF for the same session. Finally, the CDRs will eventually be transferred to the BD in a CDR file, together with other CDRs of the same or different types, according to file transfer configuration by the operator.
  The system should be capable of completing the process of chargeable event detection and charging event forwarding, CDR generation / closure and CDR forwarding as closely as possible in real-time. However, a significant time may pass between the reception of the first charging event for a CDR and the time the CDR is closed, depending on the CDR generation triggers configured by the operator.

For both event and session based charging, it has been specified above that the NE/NF shall disallow the requested resource usage when the associated chargeable event is not authorised by the OCS/CCS. The most typical case for the OCS/CCS to refuse authorisation is the expiry of the subscriber account. However, depending on operator policy, even in the case of account expiry the OCS/CCS may determine to allow the resource usage to occur / to continue. For example, if the interruption of the user session renders the complete session useless to the end user, it would be unfair to debit the user's account for the portion of the session that was executed. While the decision making procedures and the special treatment of this situation are internal to the OCS/CCS, the important aspect to note is that the OCS/CCS must grant authorisation towards the network in order to allow the event to occur or the session to continue, effectively making the event or (remainder of the) session free of charge.

Clause 5.2 provides a detailed analysis of the possible relationships between charging events, Credit-Control processes, CDRs and CDR files as well as their triggers.

Both CDR and online charging data generation and contents should be flexible and unnecessary redundancy in data should be avoided. Clause 5.4 describes how the generation of charging data can be configured by the network operator in order to support the above requirement.

Charging data are collected for successful and selected unsuccessful resource usage attempts. The resource usage attempt is seen as being successful in the network element/network function (where the chargeable event is detected) when the user event is successfully completed, or the user session has started. Further details, such as the indication of failure and failure reasons in charging events and CDRs, are specified in the middle tier TSs.

5.2 Charging data transfer p. 45

5.2.0 General |R12| p. 45

Clause 5.1 describes the generation of charging information, events and records and quota supervision across the various logical functions. In the present clause, the relation between the events, records, Credit-Control sessions and CDR files is explained.

5.2.1 Charging data transfer in offline charging p. 45

5.2.1.0 General |R12| p. 45

In offline charging, charging events mirroring the resource usage request of the user are transferred from the CTF to the CDF via the Rf reference point. The CTF determines whether the request corresponds to an event (event based charging) or whether a session shall be started (session based charging). Generally, this property is built into the network capability, or service, that the NE provides, and described in the middle tier TSs.

5.2.1.1 Transfer of charging events via Rf p. 46

In event based charging, a network / user event (e.g. MM submission) corresponds to a single chargeable event. In session based charging, at least two chargeable events are needed, one each to describe the start and the end of the session, respectively. Multiple interim events are possible in order to describe changes to session characteristics (generally termed "change of charging condition", e.g. tariff time switch, change of PDP context QoS or change of IMS session media types), or when certain limits, e.g. time or volume, are exceeded. The CTF transforms each chargeable event into a charging event and forwards these charging events to the CDF in real-time.

The relation between chargeable events and charging events is 1:1. For event based charging, the relation between charging events and CDRs is 1:1. For session based charging, the relation between charging events and CDRs is m:n with m ≥ n. The middle tier TSs specify the chargeable events per domain / service / subsystem even if Rf does not exist as an open interface in the respective domain / service / subsystem, as it is always required to identify the connection between chargeable events and triggers for CDR generation and information addition.

If charging events are generated for unsuccessful resource usage attempts, the charging event must describe the reason and the circumstances of the failure. Details, including if and when those events are generated, are specified in the middle tier TSs.

Details on the protocol application for the open Rf interface, including the message types and the domain / subsystem /service independent contents of the messages, can be found in TS 32.299.

5.2.1.2 Transfer of CDRs via Ga p. 46

Upon receiving a charging event, the CDF uses the event to create/open a CDR (both event and session based charging), or to add information to an existing open CDR. As there is a 1:1 mapping between charging events and CDRs in event based charging, CDRs are created promptly after receiving and processing the event, and are then ready for transfer on to the CGF via the Ga reference point.

In session based charging, a CDR is opened when the initial charging event, specifying the start of a user session, is received. Information is added to the CDR upon receiving interim charging events. The CDR may be closed due to a number of reasons configured on the CDF or dependent on implementation, including but not limited to:

time limit;
volume limit;
limit of change of charging conditions;
end of user session, e.g. reception of the final charging event describing the session termination;
limits (e.g. memory size) imposed by implementation.

The CDR generation could be suppressed to limit the number of CDRs based on operator configuration.

When a CDR is closed and the session is still active, a subsequent CDR is opened. Hence multiple "partial CDRs" may be needed to completely describe the session. This implies that opening and closure of CDRs may occur completely asynchronously to the reception of the charging events.

The size of partial CDRs could be optionally reduced by allowing a reduced format for partial CDRs, implying that some information can be eliminated rather than repeated in all the partial CDRs. This means that only changes from one CDR to the next, in addition to mandatory information, is reported. All the missing information can be reconstructed from fields in previous partial CDRs. For example, if location information is captured in CDRs but the user did not change location, the corresponding partial CDR would not include any location information.

Therefore, two formats are considered for Partial CDRs:

a Fully Qualified Partial CDR that contains the complete set of CDR Fields, and
a Reduced Partial CDR that contains all the Mandatory fields (M) and ONLY the changes that occurred in any other field relative to the previous partial CDR.

The first CDR generated when a session is opened shall be a Fully Qualified Partial CDR. Subsequent partial CDRs may be Reduced Partial CDRs. Thus, the convention is that when any non-mandatory field is missing from a Reduced Partial CDR, it should be interpreted that the same field as in the previous partial CDR could be used. Refer to clause 5.4 for the definition of "mandatory" and other CDR field categories.

All CDFs and CGFs from all vendors shall be able to generate or receive Fully Qualified Partial CDRs. Generation and reception of Reduced Partial CDRs on the Ga interface is optional. However, if Reduced Partial CDRs are transmitted on the Ga interface they must comply with the rules specified in this clause.

If the CDFs are generating Reduced Partial CDRs on the Ga interface, the CGF must be able to convert the CDRs into Fully Qualified Partial CDRs. However, if according to operator choice, the BD can support Reduced Partial CDRs, no conversion to the Fully Qualified Partial CDR format is required.

The possible charging configurations that can be supported on both the Ga and the Bx interfaces are illustrated in Figure 5.2.1.2.1. Configuration a) is the default arrangement that MUST be supported by all systems. The other configurations are optional and may be supported IN ADDITION to configuration a). Configuration b) illustrates the case where the CGF is converting Reduced to Fully Qualified Partial CDRs. Configuration c) depicts the case were Reduced Partial CDRs can be received in the BD and no conversion is needed.

Copy of original 3GPP image for 3GPP TS 32.240, Fig. 5.2.1.2.1: Possible Configurations of Ga and Bx CDR Formats

Figure 5.2.1.2.1: Possible Configurations of Ga and Bx CDR Formats
(⇒ copy of original 3GPP image)

When a CDR is closed, it is immediately transferred to the CGF. The exact timing may be determined by configuration parameters of the protocol used on Ga. The CDF shall be capable of receiving and processing charging events and generating and forwarding the resulting CDRs in near real-time.

Details on the protocol application for the open Ga interface can be found in TS 32.295. The semantics and formal description of the CDR parameters are specified in TS 32.298.

5.2.1.3 Transfer of CDR files via Bx p. 47

The CGF is responsible for persistent CDR storage, for preparing CDR files and transferring them to the BD via the Bx reference point. To this end, the CGF provides one or more files on which to store the CDRs after potential reformatting to comply with the Bx file format specified in TS 32.297.

The CDRs may be routed to one of several simultaneously open files inside the CGF depending on certain CDR parameters, such as CDR type, or on other criteria such as the originating CDF. CDR files are closed on the CGF based on certain operator configured parameters, for example:

file size limit,
file duration (time) limit,
time of day,
maximum number of CDRs.

This implies that the closure of a CDR file occurs asynchronously to the reception of CDRs on the CGF. When a CDR file is closed, the CGF must assure that a new CDR file is available to store incoming CDRs in line with the CDR routing facility described above.

Once CDR files are closed, they are ready for transfer to the BD. The CGF shall support both "push" transfer mode (i.e. CGF triggers and controls file transfer to BD) and "pull" transfer mode (i.e. BD triggers and controls file transfer). In push mode, the CGF uploads the files to the BD according to operator specified parameters, such as time of day, number of available files, etc. In pull mode, the BD may request the files from the CGF at any point in time at the discretion of the BD.

For all procedures involved in CDR reception, processing and storing, the CGF shall be capable of complying with near real-time requirements. Details on the protocol application for the open Bx interface and the functionality of the CGF can be found in TS 32.297. The semantics and formal description of the CDR parameters are specified in TS 32.298.

5.2.2 Charging data transfer in online charging p. 48

In online charging, charging events mirroring the resource usage request of the user are transferred from the CTF to the OCF via the Ro reference point. The CTF determines whether the request corresponds to an user / network event (event based charging, e.g. MMS) or whether a session shall be started (session based charging, e.g. IP CAN bearer). Generally, this property is built into the network capability, or service, that the NE provides, and described in the middle tier TSs.

Note that TS 23.078 also specifies online charging capability in the SGSN and MSC based on CAMEL, i.e. using the CAP reference point towards the OCS. This functionality is outside the scope of the present document.

In event based charging, a network / user event (e.g. MM submission) corresponds to a single chargeable event. In session based charging, at least two chargeable events are needed, one each to describe the start and the end of the session, respectively. Multiple interim events are possible in order to describe changes of session characteristics (e.g. change of IP CAN bearer QoS or change of IMS session media types), or when certain limits, e.g. time or volume, are exceeded. The CTF transforms each chargeable event into a charging event and forwards these charging events to the OCF in real-time.

For event based charging, the Credit-Control procedure in the OCS may or may not involve reservation of units from the subscriber account, as described in clause 5.1. In the case of event based charging without reservation (IEC):

The CTF forwards the charging event to the OCS;
The OCS determines the value of the requested resource usage and debits this value from the subscriber account;
The OCS returns the resource usage authorisation to the network element;
The network element executes the resource usage according to the user request and the OCS authorisation.

The following exceptions and abnormal cases are defined for the IEC scenario:

The OCS rejects the resource usage request. In this case, the NE disallows the resource usage.
Subsequent to resource usage authorisation and execution of the resource usage, the resource usage fails and the CTF may return the failure to the OCS to initiate a refund for the original resource usage.

If the Credit-Control procedure does involve reservation (ECUR):

The CTF forwards the charging event to the OCS;
The OCS determines the value of the requested resource usage and reserves this value from the subscriber account;
The OCS returns the resource usage authorisation to the network element;
The network element executes the resource usage according to the user request and the OCS authorisation.
After completion (or failure) of the resource usage, the NE informs the OCS accordingly about the completion or failure;
In line with the result report from the network element, the OCS either debits the reserved amount from the subscriber account (success), or it returns the reserved amount back to the subscriber account (failure).

The following exceptions and abnormal cases are defined for the ECUR scenario:

The OCS rejects the resource usage request. In this case, the NE disallows the resource usage.
The resource usage execution fails, e.g. due to network failure or user abort. In this case, the network element informs the OCS of the failure, and the previously reserved amounts are returned onto the subscriber account.

Session based online charging always involves reservation within the Credit-Control procedure (SCUR), as there is no way for the OCS to predict the amount of resource usage that occurs during the user session. To begin with, the CTF forward generates a charging chargeable event that corresponds to the resource usage request and maps onto the user session, and forwards it to the OCF. In the OCS, the online charging session is started and a certain amount reserved from the user subscriber account. This amount is determined by the OCS based on the information in the charging event and on local configuration, i.e. operator policy. A resource usage quota, matching the reserved amount, is then returned by the OCS, at which point the user session starts in the NE. Further charging events are sent from the NE to the OCS upon the detection of further chargeable events within the session .e.g. the expiry of in intervals configured on the NE or instructed by the OCS, or when the authorised quota expires, or when session characteristics change (e.g. change of QoS of an IP CAN bearer). The OCS then furnishes a new quota to the NE as required, or rejects the charging event, e.g. due to expiry of credit on the subscriber account. The OCS also furnishes the NE's behaviour on quota expiry (termination action). When the user session terminates normally in the NE, a final statement on the actually used network resources is returned to the OCS, enabling the OCS to calculate the final value of the actual resource usage session and to properly debit the corresponding final amount from the subscriber account (possibly resulting in a re-crediting of previously reserved amounts). This also terminates the Credit-Control session for the particular user session. The following exceptions and abnormal cases are defined for the SCUR scenario:

For optimisation purposes, the network element may allow the user session to start prior to receiving the initial authorisation from the OCS, i.e. prior to the start of the Credit-Control session.
The OCS rejects the initial resource usage request at session start, i.e. no Credit-Control session is started. In this case, the NE disallows the start of the session or, if the session was already allowed to start as described in item 1 above, enforces the termination of the user session.
The OCS rejects the resource usage request in mid-session. In this case, the NE's behaviour conforms to the instruction returned by the OCS, e.g.:
- terminate the user session;
- limit the characteristics of the user session, e.g. allow only Web/WAP pages that are free of charge;
- direct the session to a special notification site or an account recharging server
The OCS may send unsolicited termination commands with the same effect as described in item 3 above.
Unexpected termination of user session, e.g. due to network failure or due to user abort. In this case, the behaviour of the network is as specified above for session termination, but all available information of the failure is returned to the OCS in the final statement. Further action of the OCS in regard of calculating the session value and debiting or crediting the user's account depends on the exact circumstances and operator policy.

In any of the above cases, the termination of the user session coincides with the termination of the Credit-Control session, e.g. even when a user session is allowed to continue upon account expiry, the Credit-Control session will also continue, but "zero" rated.

It is important for operators to carefully consider the reservation policy on the OCS. On the one hand, if small amounts are reserved, the NE must renew the authorisation very frequently, creating high signalling and processing loads. Additionally, this policy has a comparatively high likelihood of longer, or higher-value, user sessions being forcefully terminated due to expiry of the subscriber account after many small quotas have been used for small chunks of the subscriber session. In contrast, assigning high reservations avoids the above problems, but may interdict the user from the execution of additional, parallel resource usages: due to the high previous reservation, there is no credit left on the account for another resource usage request. The situation described in this paragraph is particularly complex when correlation between multiple charging levels is necessary, see clause 5.3.4. A potential method of relieving this problem is the pooling of credit quotas as described in clause 5.5.2 below.

The middle tier TSs specify the chargeable events and the content of the associated charging events and responses. TS 32.299 specifies the interface application for the Ro reference point, including the message types and the domain / subsystem / service independent contents of the messages. In addition to the Credit-Control functions, the OCS may also be capable of producing CDRs based on the execution of the above Credit-Control procedures. To this end, the OCS must implement a CDF, and it uses the Ga and Bo reference points to forward its CDRs to a CGF and the CDR files to the BD. These functions of the OCS, however, are outside the scope of 3GPP standardisation.

5.2.3 Charging data transfer in converged charging |R17| p. 50

In converged charging, charging events mirroring the resource usage request of the user are transferred from the CTF or CEF to the CHF via the Nchf service-based interface.

The CTF determines whether to use Event based charging (IEC and PEC) or Session based charging (SCUR and ECUR).
The CEF determines the type of Event based charging (IEC and PEC) to use.

The charging data transfer for the converged online and offline charging is the converged operation of the online and offline charging specified in the clause 5.2.1 and 5.2.2.

Details on the protocol application for the Nchf interface, including the message types and the domain / subsystem /service content of the messages, can be found in TS 32.290 and TS 32.291.