Section: 5.2.2 Charging data transfer in online charging
Content: 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[ Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; Stage 2 ]  [207] 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: 1) The OCS rejects the resource usage request. In this case, the NE disallows the resource usage. 2) 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. NOTE 1: The triggering of the refund action is implementation and service dependent. 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: 1) The OCS rejects the resource usage request. In this case, the NE disallows the resource usage. 2) 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. NOTE 2: Returning previously reserved amounts of units to the user’s account is up to operator policy in the OCS. The authorization of multiple chargeable events as per the "event based charging" description in clause 5.1 is not yet covered in the above scenario. 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: 1) 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. 2) 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. 3) 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 4) The OCS may send unsolicited termination commands with the same effect as described in item 3 above. 5) 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. NOTE 3: the intention of the above clause is not to enforce closing the user session when the Credit-Control session breaks down. 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[ Telecommunication management; Charging management; Diameter charging applications ]  [50] 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.