Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 32.240  Word version:  17.3.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.3…   5…   5.3…   A…

 

4.3  Charging functionsWord‑p. 23

4.3.1  Offline charging functionsWord‑p. 23

4.3.1.0  General |R12|Word‑p. 23

Figure 4.3.1.0.1 provides an overview of the offline part of the common charging architecture of Figure 4.2.2.1. The Figure 4.3.1.0.1 depicts the logical charging functions as well as the reference points between these functions and to the BD.
(not reproduced yet)
Figure 4.3.1.0.1: Logical ubiquitous offline charging architecture
Up
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.

4.3.1.1  Charging Trigger FunctionWord‑p. 24

The Charging Trigger Function (CTF) generates charging events based on the observation of network resource usage as described in clause 4.1.1. In every network element 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. The CTF is therefore a mandatory, integrated component in all network elements that provide offline charging functionality, as depicted in Figure 4.2.2.1. It is made up of two functional blocks:
  • Accounting Metrics Collection
    The process that monitors signalling functions for calls, service events or sessions established by the network users, or the handling of user traffic for these 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 resources and/or services in real-time. The exact behaviour and functionality of this process e.g.:
    • trigger conditions for collection of charging information,
    • information elements to collect,
    • which service events, signalling or user traffic to monitor,
    • relationship to services / bearers / sessions,
    depends on functions / services that the NE provides. The Account Metrics Collection can therefore be considered as the network element dependent part of the CTF.
    Depending on implementation choice, NE functions (e.g. the handling of service events or signalling / user traffic) may be distributed among multiple physical "devices" within the NE. In order to be able to capture the required charging information from the service events or signalling / user traffic, the design of the Accounting Metrics Collection has to match the physical design / distribution of these functions within the NE. This implies that in case of such distributed NE functionality, the Accounting Metrics Collection becomes a distributed functionality itself.
  • 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 these metrics. It then assembles charging events that match the detected chargeable events, and forwards the charging events towards the CDF via the Rf reference point. 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.
Even when distributed within the network element or service element, the CTF is considered to be part of the network element or service element. In service-specific cases, the CTF functional components of Accounting Metrics Collection and Accounting Data Forwarding are divided between the UE and the network element or service element. This architecture extension, conditionally required for specific services, is specified in Annex D.
The behaviour of the CTF with respect to the definition of the chargeable events, the matching charging events and the information elements to collect is specified per domain, subsystem and service in the respective middle tier TS 32.25x, TS 32.26x and TS 32.27x ([10] - [49]).
Up

4.3.1.2  Charging Data FunctionWord‑p. 26

The Charging Data Function (CDF) receives charging events from the CTF 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 from single charging events, i.e. a 1:1 relation between event and CDR.
  • CDRs may be constructed from a set of several 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) (refer to clause 4.5 for possible physical configurations of the logical charging functions). This includes the possibility of NEs of different types feeding charging events into the same CDF.
  • All charging events used to build a CDR must originate from the same NE, i.e. there is no cross-NE or cross-NE-type correlation of charging events in the CDF.
The results of the CDF tasks are 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 TS (e.g. TS 32.250 for the CS domain and TS 32.251 for the PS domain, etc,).
Up

4.3.1.3  Charging Gateway FunctionWord‑p. 26

The CDRs produced by the CDF are transferred immediately to the Charging Gateway Function (CGF) via the Ga reference point. The CGF acts as a gateway between the 3GPP network and the BD. It uses the Bx reference point for the transfer of CDR files to the BD. 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 the Ga reference point in near real-time. The protocols that may cross the Ga reference point are specified in TS 32.295.
  • 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 BD.
For further details of those functions see TS 32.297.
Up

4.3.1.4  Offline Charging System |R11|Word‑p. 26

The Offline Charging System (OFCS) is a grouping of charging functions used for offline charging. It collects and processes charging events from one or more CTFs, and it generates CDRs for subsequent offline downstream billing processes.

4.3.2  Online charging functionsWord‑p. 27

4.3.2.0  General |R12|Word‑p. 27

Figure 4.3.2.0.1 provides an overview of the online part of the common charging architecture of Figure 4.2.2.1. The Figure 4.3.2.0.1 depicts the logical charging functions in the network and the OCS and the reference points between these functions.
(not reproduced yet)
Figure 4.3.2.0.1: Logical ubiquitous online charging architecture
Up
CTF:
Charging Trigger Function
OCF:
Online Charging Function
ABMF:
Account Balance Management Function
RF:
Rating Function

4.3.2.1  Charging Trigger FunctionWord‑p. 27

As outlined in clause 4.1.2, online charging is a process where charging information is collected in the network element in the same fashion as in offline charging. This implies that, from the functional perspective, the CTF defined in clause 4.3.1.1, also creates the charging events used for online charging. While the accounting metrics used in online charging are generally the same as in offline charging (i.e. the charging mechanism is transparent to the Accounting Metrics Collection), the following functional enhancements concerning the Accounting Data Forwarding are required in the CTF in order to support online charging:
  • The information collected for, and included in, the online charging events is not necessarily identical to the offline charging case (i.e. the chargeable events may not necessarily be identical to those observed in offline charging);
  • The charging events are forwarded to the Online Charging Function (OCF) in order to obtain authorisation for the chargeable event / network resource usage requested by the user;
  • The CTF must be able to delay the actual resource usage until permission by the OCS has been granted;
  • The CTF must be able to track the availability of resource usage permission ("quota supervision") during the network resource usage;
  • The CTF must be able to enforce termination of the end user's network resource usage when permission by the OCS is not granted or expires.
The underlying principles for requesting, granting and managing resource usage permissions are described in detail in clause 5.1.
Note that the S-CSCF, although involved in online charging, does not create any online charging events, therefore clauses 4.3.2.1 and 4.3.2.2 are not completely applicable to the S-CSCF. Clause 4.3.2.2.2 describes online charging specifically for the S-CSCF.
The charging events for online charging are transferred to the OCS using the CAP or Ro reference points. Refer to Figure 4.2.2.1 for information on the applicability of CAP or Ro per NE type.
Up

4.3.2.2  Online Charging SystemWord‑p. 28

4.3.2.2.0  General |R12|Word‑p. 28
The following sub-clauses summarise the tasks of the functions comprising the OCS. Details of the OCS, and the role of each of its functional components, are described in TS 32.296.
4.3.2.2.1  Online Charging FunctionWord‑p. 28
The OCF consists of two distinct modules, namely the Session Based Charging Function (SBCF) and the Event Based Charging Function (EBCF).
The Session Based Charging Function is responsible for online charging of network / user sessions, e.g. voice calls, IP CAN bearers, IP CAN session or IMS sessions.
The Event Based Charging Function performs event-based online charging (also referred to as "content charging") in conjunction with any application server or service NE, including SIP application servers.
Online charging in the CS and PS domains may be performed using the CAP reference point from the MSC and SGSN, respectively, to the OCF (refer to TS 23.078 for details on CAP). Online charging communication between the S-CSCF and the SBCF is described in clause 4.3.2.2.2. All other network elements employ the Ro reference point for online charging (refer to TS 32.299). Refer to TS 32.296 for details on the relation between the network elements (i.e. the embedded online enhanced CTF) and the SBCF or EBCF, respectively.
Up
4.3.2.2.2  S-CSCF online charging / IMS Gateway FunctionWord‑p. 28
As stated above, the S-CSCF does not trigger any online charging events and thus does not include the CTF online charging enhancements described in clause 4.3.2.1 (in contrast, it does have a CTF for offline charging, as described in clause 4.3.1.1). Instead, the ISC interface is employed by the S-CSCF online charging, implying that online charging is transparent to the S-CSCF and appears like any other service logic controlled by a SIP application server. Therefore, if support for Ro based online charging is required instead of / or in addition to application server or MRFC, a special CTF is needed in order to mediate between the Ro based SBCF and the SIP based service control. This role is taken by the IMS Gateway Function (IMS GWF), which translates between SIP service control towards the S-CSCF and Ro Credit-Control on the OCS side.
From the perspective of the online charging architecture, the IMS GWF is an online charging capable CTF; from the perspective of the S-CSCF, the IMS GWF is a SIP application server and is triggered the same way. It is out of scope of the 3GPP standards whether the IMS GWF is embedded in the S-CSCF, embedded in the OCS/SBCF, or exists as a stand-alone component.
Up
4.3.2.2.3  Rating FunctionWord‑p. 28
The Rating Function (RF) determines the value of the network resource usage (described in the charging event received by the OCF from the network) on behalf of the OCF. To this end, the OCF furnishes the necessary information, obtained from the charging event, to the RF and receives in return the rating output (monetary or non-monetary units), via the Re reference point. The RF may handle a wide variety of rateable instances, such as:
  • Rating of data volume (e.g. based on charging initiated by an access network entity, i.e. on the bearer level);
  • Rating of session / connection time (e.g. based on charging initiated by a SIP application, i.e. on the subsystem level);
  • Rating of service events (e.g. based on charging of web content or MMS, i.e. on the service level).
Up
4.3.2.2.4  Account Balance Management FunctionWord‑p. 29
The Account Balance Management Function (ABMF) is the location of the subscriber's account balance within the OCS or the CCS. The ABMF is put into functional context within TS 32.296.

4.3.2.3  CDR generation for online charged subscribersWord‑p. 29

In offline charging, CDRs are generated in the network and forwarded to the BD for further processing, e.g. generating subscriber bills. In online charging, network resource usage is granted by the OCS based on a subscriber account on the OCS. If required by the operator, CDRs may additionally be generated for online charged subscribers. One way of achieving this is by performing online charging and offline charging simultaneously for these subscribers. Alternatively, the OCS can accomplish this by the use of the appropriate offline charging functions as follows:
  • A CDF, as specified in clause 4.3.1.2, is employed by each of the OCFs that are required to generate CDRs from the charging events they receive from the CTF;
  • A CGF, as specified in clause 4.3.1.3, is employed by the OCS in order to generate / manage CDR files and provide these files to the BD.
Up

4.3.3  Converged charging functions |R15|Word‑p. 29

4.3.3.0  GeneralWord‑p. 29

Figure 4.3.3.0.1 provides an overview of converged charging architecture. The figure 4.3.3.0.1 depicts the logical charging functions in the network and interface between these functions and to the BD.
This charging architecture is used for 5G system.
(not reproduced yet)
Figure 4.3.3.0.1: Logical ubiquitous converged charging architecture
Up
CTF:
Charging Trigger Function
CHF:
CHarging Function
ABMF:
Account Balance Management Function
RF:
Rating Function
CGF:
Charging Gateway Function
BD:
Billing Domain. This may also be a billing system/ billing mediation device.

4.3.3.1  Charging Trigger Function (CTF)Word‑p. 29

The Charging Trigger Function (CTF) interacts with the Charging Function (CHF) of the Converged Charging System (CCS) using Nchf interface for consuming CHF services as defined in TS 32.290:
  • converged charging (Nchf_ConvergedCharging service) wich operates:
  • with quota management (online charging);
  • without quota management (offline charging);
  • offline only charging (Nchf_OfflineOnlyCharging service).
The behaviour of the Charging Trigger Function (CTF) embedded in the service element, sub-system component or Core Network element is specified in the respective middle tier charging specifications.
Up

4.3.3.2  Converged Charging System (CCS)Word‑p. 30

4.3.3.2.0  General |R16|Word‑p. 30
The Converged Charging System (CCS) consists of four distinct modules, namely the CHF, the Account Balance Management Function (ABMF), the Charging Gateway Function (CGF) and the Rating Function (RF).
The converged charging system interacts with CTF using Nchf interface and interacts with the BD using Bx interface.
4.3.3.2.1  Charging Function (CHF) |R16|Word‑p. 30
The CHF includes:
  • Online Charging Function (OCF) specified in TS 32.296, providing quota management functionality under Credit-Control terminology.
  • Charging Data Function (CDF) specified in clause 4.3.1.2, providing CDRs generation functionality for charging events received from the CTF or CEF via Nchf.
4.3.3.2.2  Account Balance Management Function (ABMF) |R16|Word‑p. 30
The ABMF is described in clause 4.3.2.2.4.
4.3.3.2.3  Rating Function (RF) |R16|Word‑p. 30
The Rating Function (RF) is described in clause 4.3.2.2.3.
4.3.3.2.4  Charging Gateway Function (CGF) |R16|Word‑p. 30
The Charging Gateway Function (CGF) is described in clause 4.3.1.3.

4.3.3.3  Charging Enablement Function (CEF) |R16|Word‑p. 30

The Charging Enablement Function (CEF) is a consumer of Nchf charging services, and for the purpose of charging information collection may consume management services, services exposed by other network functions or both.

4.4  Reference pointsWord‑p. 31

4.4.1  Offline charging reference pointsWord‑p. 31

4.4.1.1  RfWord‑p. 31

The Rf reference point supports interaction between a CTF and a CDF. The following information may flow across this reference point in real-time:
  • Charging events for offline charging from the CTF to the CDF;
  • Acknowledgements for these events from the CDF to the CTF.
The protocol(s) crossing this reference point shall support the following capabilities:
  • Real-time transactions;
  • Stateless mode ("event based charging") and statefull mode ("session based charging") of operation;
  • Provide its own reliability mechanisms, e.g. retransmission of charging events, to run also on unreliable transport.
In addition, the protocol should support changeover to a secondary destination (alternate CDF(s)) in case of the primary CDF not being reachable.
This interface application is defined in TS 32.299. The information contained in the charging events and the relevant chargeable events are specific to the domain / subsystem / service and are detailed in the respective middle tier TSs.
Up

4.4.1.2  GzWord‑p. 31

The Gz reference point is functionally equivalent to Ga for Legacy PS domain and to Ga or Rf for Evolved PS domain, and hence is replaced by Ga or Rf within the common charging architecture. See also clause 4.2.

4.4.1.3  GaWord‑p. 31

The Ga reference point supports interaction between a CDF and a CGF. The following information may flow across this reference point:
  • CDRs are sent from the CDF to the CGF;
  • Acknowledgements for these CDRs are returned from the CGF to the CDF.
The protocol(s) crossing this reference point shall support the following capabilities:
  • Near real-time transactions;
  • Send one or more CDRs in a single request message;
  • Changeover to secondary destinations (alternate CGFs) in case of the primary CGF not being reachable;
  • Provide its own reliability mechanisms, e.g. retransmission of charging events, to run also on unreliable transport.
This interface application is defined in TS 32.295. The content of the CDRs, and the CDR trigger conditions, are specific to the domain / subsystem / service and are detailed in the middle tier TSs.
Up

4.4.1.4  BxWord‑p. 31

The Bx reference point supports interaction between a CGF and the BD. The information crossing this reference point is comprised of CDR files. A common, standard file transfer protocol (e.g. FTAM, FTP) shall be used, including the transport mechanisms specified for the selected protocol.
This interface application is defined in TS 32.297. The information contained in the files corresponds to the CDRs defined per domain/subsystem/service, as stated in clause 4.4.1.3.
Up

4.4.1.5Void

(Void).

4.4.1.6  Gzn |R12|Word‑p. 32

The Gzn reference point is functionally equivalent to Ga or Rf in PS domain, and hence is replaced by Ga or Rf within the common charging architecture. See also clause 4.2.

4.4.2  Online charging reference pointsWord‑p. 32

4.4.2.1  RoWord‑p. 32

The Ro reference point supports interaction between a CTF and an OCF. The following information may flow across this reference point:
  • Charging events for online charging from the CTF to the OCF.
  • Receive Acknowledgements for these charging events from the OCF to the CTF. The acknowledgement grants or rejects the network resource usage requested in the charging event, according to the decision taken by the OCS.
The protocol(s) crossing this reference point shall support the following capabilities:
  • Real-time transactions;
  • Stateless mode ("event based charging") and statefull mode ("session based charging") of operation;
  • Provide its own reliability mechanisms, e.g. retransmission of charging events, to run also on unreliable transport.
In addition, the protocol should support changeover to a secondary destination (alternate OCF(s)) in case of the primary OCF not being reachable.
This interface application is defined in TS 32.299. The information contained in the charging events and the relevant chargeable events are specific to the domain / subsystem / service and are detailed in the respective middle tier TSs.
Up

4.4.2.2  CAPWord‑p. 32

The CAP reference point provides similar functionality for online charging as Ro, however, it is based on CAMEL techniques. It is kept within the overall charging architecture as CAMEL may be used in the CS and PS domains. See TS 23.078 for details on CAMEL.

4.4.2.3  GyWord‑p. 32

The Gy reference point is functionally equivalent to Ro, and hence is replaced by Ro within the common charging architecture. See also clause 4.2.

4.4.2.4  ReWord‑p. 32

The Re reference point supports interaction between the OCF and a Rating Function (RF) in order to determine the value of chargeable events in terms of monetary or non-monetary units. This interface application is defined in TS 32.296.

4.4.2.5  RcWord‑p. 32

The Rc reference point allows the interaction between the OCF and an Account Balance Management Function (ABMF) in order to access the account of the subscriber on the OCS. See TS 32.296 for further information.

4.4.2.6Void

(Void).

4.4.2.7  Gyn |R12|Word‑p. 33

The Gyn reference point is functionally equivalent to Ro, and hence is replaced by Ro within the common charging architecture. See also clause 4.2.

4.4.3  Charging services Reference point |R17|Word‑p. 33

The common charging architectures are mapped into the specific domain/subsystem/service charging architectures in the respective middle tier TSs, which contain in their reference point representation, the following reference points:
N28:
Reference point between PCF and CHF defined in TS 23.501.
N40:
Reference point between SMF and the CHF defined in clause 4.2 of TS 32.255.
N41:
Reference point between AMF and CHF in HPLMN defined in clause 4.2.2 of TS 32.256.
N42:
Reference point between AMF and CHF in VPLMN defined in clause 4.2.2 of TS 32.256.
N44:
Reference point between NEF and CHF defined in clause 4.4 of TS 32.254.
N45:
Reference point between IMS Node and CHF defined in clause 4.4 of TS 32.260.
N46:
Reference point between SMS Node and CHF defined in clause 4.4 of TS 32.274.
Up

4.5  Architecture mappingWord‑p. 33

4.5.0  General |R12|Word‑p. 33

The following sub-clauses describe how the logical ubiquitous charging architecture can be mapped onto physical components and interfaces within the scope of 3GPP standards.

4.5.1  Offline mappingWord‑p. 33

The Figures Figure 4.5.1.1 - Figure 4.5.1.4 below depict the mappings of the ubiquitous offline charging architecture onto physical implementations that are identified within the 3GPP standards. As stated previously in the present document, the CTF is a mandatory component of all NEs that have offline charging capabilities. In contrast, the CDF and the CGF may be implemented in any of the following ways:
1)
CDF and CGF integrated in the NE. In this implementation, all network charging functions are embedded in the NE, i.e. the NE is fully self-contained in terms of offline charging. The (physical) NE itself produces the CDR files that are then transferred to the BD. Consequently, only the Bx reference point needs to be implemented as a physical interface.
(not reproduced yet)
Figure 4.5.1.1: CDF and CGF integrated in the NE
Up
2)
CDF integrated in the NE, CGF in a separate physical element. In this implementation, the (physical) NE generates CDRs and sends them to an external CGF. Hence the Ga reference point must be implemented in the NE as a physical interface. If the CGF is a stand-alone entity, it must implement both the Ga and the Bx reference point as physical interface. As a variation of this construct, the CGF may be integrated in the BD, in which case the Bx reference point is internal to the BD.
(not reproduced yet)
Figure 4.5.1.2: CDF integrated in the NE, CGF in a separate physical element
Up
3)
CDF and CGF in two separate physical elements. This scenario represents the fully distributed implementation where all reference points must be implemented as physical interfaces on the NE, CDF and CGF, respectively. Again, as a variation of this approach, the CGF may be an integral component of the BD, in which case the Bx reference point becomes internal to the BD.
(not reproduced yet)
Figure 4.5.1.3: CDF and CGF in two separate physical elements
Up
4)
CDF and CGF in the same separate physical element. In contrast to scenario 3, there is no physical Ga interface, whereas the Rf and Bx reference points must exist as distinct interfaces in the same fashion as in scenario 3. The variation of the combined CDF/CGF being embedded in the BD is again possible, resulting in the Rf reference point being the only one that appears as a physical interface.
(not reproduced yet)
Figure 4.5.1.4: CDF and CGF in the same separate physical element
Up
Details of the possible implementation options per domain / subsystem / service (usually a subset of the overall possible variants described above) are specified in the respective middle tier TS.

4.5.2  Online mappingWord‑p. 35

The CTF is a mandatory integrated component of all network elements that are involved in online charging as depicted in Figure 4.2.2.1, with the exception of the S-CSCF (see clause 4.3.2.2.2). If CDR generation by the OCS is required, as described in clause 4.3.2.3, then a CDF is integrated in each OCF that is required to produce the CDRs. All other possibilities for physical mapping, including e.g.:
  • integrated versus distributed CGF in the OCS,
  • use of another CGF by the OCS,
  • IMS GWF integrated in S-CSCF or OCS, or a stand-alone entity,
are not specified within the 3GPP standards and are therefore implementation specific. The same is true for the composition of the OCS and its logical functions.
Up

4.6  Service based interface |R15|Word‑p. 35

4.6.1  NchfWord‑p. 35

The Nchf interface is a service based interface, which supports interaction between a Charging Trigger Function and the Charging Function.
The services and protocol(s) of this interface are described in TS 32.290 and TS 32.291.

Up   Top   ToC