If you liked it, or content was helpful to you please add "+1" to article you used or share it on facebook or so.
Make it easier to find for others who could need those information, allow them find these articles on the spot. But.. it's your call.
Recommendations until now


Jan 13, 2012

Offline Charging System (OFCS) - introduction to Gx interface

Last time I tried to familiarize You with Online Charging System (OCS), with was a introduction to Gy based on a diameter. But before I will go to the diameter, and all those CCRs and CCAs just I wanted to talk about Offline Charging System.

What is Offline Charging System (OFCS)?
According to TS 32.240 and TS 32.299 3GPP documentation:
Offline charging is a process where charging information for network resource usage is collected concurrently with that resource usage. The charging information is then passed through a chain of logical charging functions, which are described below. At the end of this process, CDR files are generated by the network, which are then transferred to the network operator's Billing Domain for the purpose of subscriber billing and/or inter-operator accounting (or additional functions, e.g. statistics, at the operator’s discretion). The BD typically comprises post-processing systems such as the operator's billing system or billing mediation device.

Generally offline charging is a mechanism where charging information does not affect, in real-time, the service rendered.
As it's always good to start with a high level design picture, let's start.
Fig. 1. Offline Charging high level architecture
Where:
CTF: Charging Trigger Function
CDF: Charging Data Function
CGF: Charging Gateway Function
BD: Billing Domain. This may also be a billing system/ billing mediation device.


Offline Charging functions
Below CTF, CDF and CGF functions are described.

Charging Trigger Function
The CTF (Charging Trigger Function) generates charging events based on the observation of network resource usage as described above. In every network and service element that provides charging information, the CTF is the focal point for collecting the information pertaining to chargeable events within the network element, assembling this information into matching charging events, and sending these charging events towards the  CDF (Charging Data Function). The CTF is therefore a mandatory, integrated component in all network elements that provide offline charging functionality. It is made up of two functional blocks:

Accounting Metrics Collection
The process that monitors signaling functions for calls, service events or sessions established by the network users, or the handling of user traffic for those calls, service events or sessions, or service delivery to the user via these calls, service events or sessions. It is required to provide metrics that identify the user and the user's consumption of network resource and/or services in real-time. The exact behaviour and funcionality of this process are:
  • trigger conditions for collection of charging information
  • information elements to collect
  • which service events, signaling or usertraffic to monitor
  • relationship to services/bearers/sessions
depends on functions/service that the network element provides. The Account Metrics Collection can therefore be considered as the network element dependent part of the CTF.

Accounting Data Forwarding
This process receives the collected accounting metrics and determines the occurrence of chargeable events from a set of one or more of there metrics. It then assembles charging events that match the detected chargeable events, and forwards the charging events towards the Charging Data Function via the Rf interface. (Being completely honest, Gx interface is being used between PCRF and PGW to transfer policy and charging rules, and it is described in more details in TS 29.212) The charging events provide information pertinent to the chargeable event, i.e. characterising the network resource usage together with an identification of the involved user(s). There is no assumption of any synchronisation between the reception of individual accounting metrics, however, it must be possible for the Accounting Data Forwarding to complete its overall functionality per charging event in real-time.

While the exact information received by the Account Data Forwarding from the Account Metrics Collection, and the relevant chargeable events, are specific to each type of network element, the overall functionality of receiving, assembling and forwarding the charging information can be considered generic. Hence the Accounting Data Forwarding is considered the NE independent part of the CTF.

Charging Data Function
The CDF (Charging Data Function) receives charging events from the CTF (described above) via the Rf reference point. It then uses the information contained in the charging events to construct CDRs. This procedure is characterised by the following conditions:
  • CDRs may be constructed fro single charging events, i.e. a 1:1 relation between event and CDR.
  • CDRs may be constructed from a set of serval charging events, i.e. a n:1 relation between event and CDR
  • Each charging event is used for exactly one CDR, i.e. a 1:n relation between event and CDR (with n>1) is not possible
  • Multiple charging events that are used to create a single CDR may not necessarily be of the same type
  • There is no requirement or assumption of any synchronisation between the reception of the charging event(s) and the creation of the resulting CDR. However, the CDF shall be capable of receiving and processing charging events and generating the resulting CDR in near real-time
  • The relationship between CDF and CTF may be 1:1 (integrated CDF) or 1:n (separated CDF). This includes the possibility of network elements of different types feeding charging events in the CDF
The result of the CDF tasks are Charging Data Records (CDRs) with a well-defined content and format. The content and format of these CDRs are specified per domain/subsystem/service in the related middle tier charging specification, e.g. 3GPP TS 32.250 for the CS domain and 3GPP TS 32.251 for PS domain.

Charging Gateway Function
The CDRs produced by CDF are transferred immediately to the Charging Gateway Function (CGF) via the Ga interface point. The CGDBs interface for transfer of CDR files to Billing Domain. The entity relationship between the CDF and the CGF is m:1, i.e. one or more CDFs may feed CDRs into a single CGF. The CGF comprises the following main functions:
  • CDR reception from the CDF via Ga interface in near real-time.
  • CDR pre-processing
    • Validation, Consolidation and (Re)Formatting of CDRs
    • CDR error handling
    • Persistent CDR storage
  • CDR routing and filtering, i.e. storing CDRs on separate files based on filtering criteria such as CDR type, CDR parameters, originating CDF, etc.
  • CDR File Management, e.g. file creation, file opening / closure triggers, file deletion
  • CDR file transfer to the Billing Domain

Charging scenarios
There are two basic scenarios that are being used:
  • Event based Charging
  • Session based Charging
Event Based Charging
In the following scenario, CTF asks the CDF to store event related charging data.
Fig. 2. Event Based Charging
1. Request for resource usage: UE-A requests the desired resource from the network element.
2. Content/Service Delivery: the network element delivers the content/service.
3. Charging Data Generation: the CTF generates charging data related to service delivery
4. Record Charging Data Request: the CTF requests the CDF to store event related charging data for CDR generation purposes.
5. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR generation configuration.
6. Record Charging Data Response: the CDF informs the CTF that charging data was stored.

Session Based Charging
In the following scenario, CTF asks the CDF to store session related charging data.
Fig. 3. Session Based Charging
1. Request for resource usage: UE-A requests the desired session from the network element.
2. Session ongoing: the network element establish the session
3. Charging Data Generation: the CTF generates charging data related to session.
4. Record Charging Data Request: the CTF requests the CDF to store session related charging data for CDR generation purposes.
5. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR generation configuration.
6. Record Charging Data Response: the CDF informs the CTF that charging data was stored
7. Charging Data Generation: the CTF generates charging data related to session due of e.g. intermediate timer expiry
8. Record Charging Data Request: the CTF requests the CDF to store session related charging data for CDR generation purposes.
9. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR generation configuration.
10. Record Charging Data Response: the CDF informs the CTF that charging data was stored
11. Session release: the session is released
12. Charging Data Generation: the CTF generates charging data related to session due of session termination.
13. Record Charging Data Request: the CTF requests the CDF to store session related charging data for CDR generation purposes.
14. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR generation configuration.
15. Record Charging Data Response: the CDF informs the CTF that charging data was stored.


Event and Session based charging are performed by the use of the Charging Data Transfer (CDF) operation:
  • Charging Data Request, sent from CTF --> CDF. This message is sent after detecting a chargeable event, the CTF sends a Charging Data Request to the CDF.
  • Charging Data Response, sent from CDF --> CTF. CDF replies with a Charging Data Response, which informs the CTF that charging data was recived.

Sources: