5 Charging principles

32.2403GPPCharging architecture and principlesCharging managementRelease 18Telecommunication managementTS

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

5.0 General

The high-level requirements for charging are specified in TS 22.115 [101]. 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

The CTF embedded in all charging relevant network elements collects charging information within the NE concerning the use of network resources by the mobile end users. These network resources may pertain to bearer (e.g. CS, PS), 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 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, 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 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, 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. When resource usage has been executed, the actual amount of resource usage (i.e. the used units) must be returned by the NE to the OCS 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 or the OCF in online 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 and offline charging are generally identical, the information comprising chargeable events (determined by the Accounting Data Forwarding part of the CTF) may be different between online and offline 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-Control occurs 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.

Both online and offline 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, 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 or the performance of a Credit-Control session in online charging. The following paragraphs describe the event versus session based charging in more detail for both online and offline charging.

– Event based charging. The (chargeable) event is recognised in the NE that handles it, based on e.g. signalling exchange between the user equipment and the NE. The event is then mapped onto a single charging event as specified in the middle tier TS that applies to that NE.

– 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) or "Immediate Event Charging" (IEC), respectively), as described above. Furthermore, if the procedure does include reservation, the OCS 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 that handles the session, based on e.g. signalling exchange between the user equipment and the NE. This chargeable event is then mapped onto a charging event as specified in the middle tier TS that applies to that NE.

– 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 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 determines not to authorise the chargeable event, it rejects the request sent by the network element, causing the NE 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 shall disallow the requested resource usage when the associated chargeable event is not authorised by the OCS. The most typical case for the OCS to refuse authorisation is the expiry of the subscriber account. However, depending on operator policy, even in the case of account expiry the OCS 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, the important aspect to note is that the OCS 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 (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.

NOTE: Some of the terminology used in this clause differs from IETF RFC 4006 [402] that forms the basis for the online charging application. For example, the DCCA uses "session" and "event" more in terms of the Credit-Control protocol rather than in terms of user activity, as the present document does. The mapping of the concepts and terminology used to describe the concepts, is described in TS 32.299 [50].

5.2 Charging data transfer

5.2.0 General

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

5.2.1.0 General

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

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 [50].

5.2.1.2 Transfer of CDRs via Ga

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.

Figure 5.2.1.2.1: Possible Configurations of Ga and Bx CDR Formats

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 [54]. The semantics and formal description of the CDR parameters are specified in TS 32.298 [51].

5.2.1.3 Transfer of CDR files via Bx

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 [52].

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 [52]. The semantics and formal description of the CDR parameters are specified in TS 32.298 [51].

5.2.2 Charging data transfer in online charging

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 [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 [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.

5.3 Charging levels and correlation

Editor’s note: To be completed. The use of EBCF and SBCF in the sub-clauses for all the three charging levels shall also be described here.

5.3.1 Bearer level charging

5.3.1.1 Bearer charging based on bearer / tele- / supplementary service

Editor’s note: To be completed.

Charging data are also collected for supplementary service activity.

5.3.1.2 Flow based bearer charging

Editor’s note: To be completed.

5.3.2 Subsystem level charging

Editor’s note: To be completed.

5.3.3 Service level charging

Editor’s note: To be completed.

5.3.4 Charging data correlation

5.3.4.0 General

The charging data correlation combines charging events generated by CTF while they are belong to the same bearer / session / service resource usage. The correlation provides an association of charging information for the mobile subscriber’s resource usage.

The correlation is based on specific access network charging identifier:

– Circuit Switched domain: MSC address and Call Reference Number;

– Packet Switched domain: P-GW address and EPC Charging ID;

– 5G Data connectivity domain: 5GC Charging ID;

– Fixed Broadband Access: Multimedia Charging ID;

– IM Subsystem: IMS Charging Identifier.

The charging information has to be aggregate for the same charging session and correlate for the same service.

5.3.4.1 Intra-level correlation

The intra-level correlation aggregates the charging events belonging to the same charging session, e.g. over a time period, and implies the generation of interim charging records.

5.3.4.2 Inter-level correlation

The inter-level correlation combines the charging events belonging to the same service but generated by different CTFs e.g. for PS access control via IM Subsystem.

5.3.4.3 Inter-network correlation

To enable the different operators involved in IMS sessions to identify each other, the Inter Operator Identification concept (IOI) is introduced. IOI allows operators involved with session signalling to identify each other by exchanging operator identification information within the SIP signalling. The IOI is composed of one pair of originating IOI and terminating IOI. Additionally, one or more transit IOI values may occur. The IOI concept may help to support inter operator charging.

The following requirements relate to the IOI concept:

a) The IOI concept shall allow operators to uniquely identify each other for the SIP based requests; for example between A’s Home PLMN and B’s Home PLMN or between an A’s Home PLMN and a A’s Visited PLMN.

b) The IOI concept can be used for inter operator accounting identification purposes.

c) It shall be possible to prevent the information used for IOI from being passed to the UE.

d) It shall be possible to apply the IOI concept on a peer to peer basis between operators. It shall be possible to use different identity values for operator identification between operators involved in IMS session related procedures and session unrelated procedures.

e) IOI identities shall be included within SIP signalling:

1) When a SIP request is passed out of an IMS network the IOI identity of that IMS network (referred as originating IOI) shall be included in the SIP signalling.

2) When a SIP response is returned the IOI identity of that responding IMS network (referred as terminating IOI) shall be included in the SIP signalling.

3) For interconnection scenarios where one or more transit operators are between the originating and terminating operator, the identities of involved transit operators (referred as transit IOI) may be included in the SIP signalling. It should be noted that transit operators can be selected independently for each SIP method and direction of request. Due to operator policy, a transit operator may also hide his identity by adding a void value. Addition and deletion of transit IOI values are operator configurable. Details are described in the TS 24.229 [211].

3a) The transit operator may provide IMS application servers to an operator network. The set of transit IOI values received in any SIP request or SIP response may be delivered to the IMS application server as per operator policy.

4) The set of originating IOI, transit IOI(s), and terminating IOI is applicable to a single inter IMS network signaling exchange (e.g., A’s Visited PLMN and A’s Home PLMN or A’s Home PLMN to B’s Home PLMN). When the SIP signaling progresses to another PLMN a new set of originating IOI, transit IOI(s), and terminating IOI is generated. The set of IOI values generated for one inter-operator signaling exchange should not be passed to the operators involved in a subsequent inter-operator signaling exchange. For example, the set of IOIs for the path from A’s Visited PLMN to A’s Home PLMN is different than for the path from A’s Home PLMN to B’s Home PLMN and the set of IOI values for one should not be transmitted across the other.

5) The path between an S-CSCF and an application server is an independent signaling exchange from those signaling exchanges between PLMNs. As such, the set of originating and terminating IOIs exchanged on those paths should not be transmitted on the path toward the application server. In addition, any set of originating and terminating IOIs for the path from the S-CSCF to an application server should not be transmitted on any other path from the S-CSCF. The set of transit IOI values received in any SIP request or SIP response may be delivered to the IMS application server as per operator policy. This set of transit IOI values delivered to the IMS application server do not reflect inter operator path between the S-CSCF and the application server, but rather the path either inbound to the S-CSCF or outbound from the S-CSCF and may be useful for operator-specific application processing in the application server.

NOTE 0: No transit networks are expected between the S-CSCF and a 3^rd party application server.

f) Each IMS network is responsible for including its own unique IOI Identity into the SIP signalling. The IOI Identity shall be unique for each IMS operator (for example the IOI Identity of Home Operator A is different from Home Operator B).

g) Three types of IOI shall be defined:

1) Type 1 IOI: between the Home PLMN and a Visited PLMN for an end user in roaming situation (case when the P-CSCF is located in a visited network);

2) Type 2 IOI: between the IMS network operator which holds the subscription of the originating end user and the IMS network operator which holds the subscription of the terminating end user. In case of redirection, Type 2 IOI can be used between IMS network operators which hold a subscription of the terminating end user, i.e. between the terminating party’s IMS network operator from which the session is redirected to the terminating party’s IMS network operator to which the session is redirected. In case Visited PLMN loopback is applied for Roaming Architecture for Voice over IMS with Local Breakout, Type 2 IOI can be used between A’s Visited PLMN and B’s Home PLMN.

3) Type 3 IOI: between the home IMS network operator and a service provider;

h) For Type 1 IOI, the P-CSCF is responsible for generating the originating IOI and the S-CSCF in the Home PLMN is responsible for generating the terminating IOI; For Type 1 IOI, the "enhanced MSC for ISC" is responsible for generating the originating IOI. In case Visited PLMN loopback is applied for Roaming Architecture for Voice over IMS with Local Breakout, Type 1 IOI is also used between A’s Home PLMN and Visited PLMN on the loopback path in which the S-CSCF is responsible for generating the originating IOI and the TRF is responsible for generating the terminating IOI.

i) For Type 2 IOI, the S-CSCF in the originating party’s home IMS network or the E-CSCF in the originating party’s local network or the originating MGCF is responsible for generating the originating IOI and the S-CSCF in the terminating party’s IMS home network or the terminating MGCF is responsible for generating the terminating IOI. In case of redirection by the S-CSCF, the S-CSCF-in the terminating party’s IMS network operator from which the session is redirected- is responsible for generating the originating IOI and the S-CSCF in the terminating party’s IMS network operator or the terminating MGCF- to which the session is redirected- is responsible for generating the terminating IOI. In case of Visited PLMN loopback is applied for Roaming Architecture for Voice over IMS with Local Breakout, the TRF in A’s Visited PLMN is responsible for generating the originating IOI, and the S-CSCF in the B’s Home PLMN is responsible for generating the terminating IOI.

NOTE 1: The originating IOI generated by the MGCF may not be reliable depending on Operators’ network configuration.

j) For Type 3 IOI, when forwarding a request to an AS, the S-CSCF in the Home PLMN is responsible for generating the originating IOI and the AS contacted by this S-CSCF is responsible for generating the terminating IOI. For a Type 3 IOI, when an AS initiates a request, the AS is responsible for generating the originating IOI and the S-CSCF or I-CSCF contacted by this AS is responsible for generating the terminating IOI. For Type 3 IOI, when the E-CSCF forwards a request to the EATF or to the LRF, the E-CSCF is responsible for generating the originating IOI, and the EATF and LRF are responsible for generating the terminating IOI. For Type 3 IOI, when the LRF initiates a request to the E-CSCF, the LRF is responsible for generating the originating IOI, and the E-CSCF is responsible for generating the terminating IOI.

k) IOI Identities received in the session signalling shall be incorporated into the CDRs produced by the IMS network elements. The operator identification information may be used for inter operator accounting purposes.

l) The allocation of the IOI values for the operators is outside the scope of 3GPP standardization.

NOTE 2: The relationship of the IOI concept with security aspects between operators is not specified in this document.

5.3.4.4 Determination of completeness of charging information in IMS

5.3.4.4.1 General

The completeness of charging information is determined within the BD which itself is out of scope of 3GPP standardization. Thus based on operator policy different rules for generating and processing of charging information apply. In order to allow determination of completeness of charging information by the processing within the BD, the IMS NEs and ASs shall include additional information in SIP signalling.

This is applicable to offline charging only in this release.

5.3.4.4.2 Tracking of IMS NEs generating charging information

Based on operator policy, each IMS NE for which the CTF is generating charging events, shall include its own address or specific NE identifier into the initial SIP request to be sent out within the trust domain.

The final SIP response sent back by the last element of the trust domain shall contain the list of addresses and identifiers received within the initial SIP request.

The list of addresses or identifiers received in the final response shall be included in the charging event generated by the CTF.

5.3.4.4.3 Tracking of applications generating charging information

Based on operator policy, each application for which the hosting AS CTF is generating charging events on its behalf, shall include the address or identifier of the AS as described in clause 5.3.4.4.2 and its application identifier into the initial SIP request to be sent out within the trust domain.

The final SIP response sent back by the last element of the trust domain shall contain the list of addresses and application identifiers received within the initial SIP request.

The list of addresses or identifiers and application identifiers received in the final response shall be included in the charging event generated by the CTF.

5.4 Charging data configuration

Charging interface applications are specified for Rf and Ro in TS 32.299 [50], for Nchf in TS 32.291[58], for Ga in TS 32.295 [54], and for Bx in TS 32.297 [52] and TS 32.298 [51]. The middle tier TSs determine per domain / service /subsystem which of the reference points exist as open interfaces and which of them are internal to integrated NEs (see charging architecture mapping discussion in clause 4.5). In accordance with these prerequisites, the content of charging events, i.e.Information Element (IE), and CDRs, i.e. CDR parameter, is also specified in the middle tier TSs on all the open network interfaces that exist in the respective domain / subsystem / service. The rules governing the presence of IEs or CDR parameters on these interfaces are summarized in this clause. A logical diagram illustrating the possible presence requirements for IEs / CDR parameters ("field categories") is shown in figure 5.4.1.

Figure 5.4.1: Logical diagram illustrating the different parameter categories

The IE and CDR parameter description tables in the middle tier TSs specify the Mandatory (M), Conditional (C) and Operator provisionable (OC or OM) designations. The category of an IE or CDR parameter can have one of two primary values:

M This parameter is Mandatory and shall always be present in the event / CDR.

C This parameter shall be present in the event / CDR only when certain Conditions are met. These Conditions are specified as part of the parameter definition.

All other parameters are designated as Operator provisionable (O). Using network management functions or specific tools provided by an equipment vendor, operators may choose if they wish to include or omit the parameter from the charging event / CDR. Once omitted, this parameter is not generated in an event / a CDR. To avoid any potential ambiguity, the CTF / CDF / CGF shall be able to provide all these parameters. Only an operator can choose whether or not these parameters should be generated in their system, i.e. included in the charging event / CDR.

Those parameters that the operator configures to be present are further divided into mandatory and conditional categories:

OM This is a parameter that, if provisioned by the operator to be present, shall always be included in the events / CDRs. In other words, an OM parameter that is provisioned to be present is a mandatory parameter.

OC This is a parameter that, if provisioned by the operator to be present, shall be included in the events / CDRs when the specified conditions are met. If provisioned by the operator not to be present, shall not be included in the events / CDRs even the specified conditions are met. In other words, an OC parameter that is configured to be present is a conditional parameter.

The IE and CDR parameter tables provide a brief description of each charging event / CDR in the corresponding middle tier TSs. The full definitions of the CDR parameters, sorted by the CDR parameter name in alphabetical order, are provided in TS 32.298 [51].

The following principles apply for Information Element (IE) and CDR parameter category across the specifications:

– Category for IEs common between the middle tier TSs (stage 2) and TS 32.290 [57]: IE category in the middle tier TSs takes precedence;

– IE category in the middle tier TSs takes precedence over the corresponding IE stage 3 category and syntax in TS 32.291[58] and TS 32.299[50].

– CDR parameter category in the middle tier TSs takes precedence over the corresponding ASN.1 field syntax in TS 32.298 [51].

5.5 Charging information utilisation

5.5.0 Introduction

To be completed. This clause should be separated between offline charging / CDRs / billing and online charging / Credit-Control. OCS aspects will also be included (e.g. OCS CDRs), e.g. the following text: "It is important to note that also in the online charging case, operators may wish to apply similar billing analyses (e.g. statistics) and, obviously, inter-operator accounting, as in the offline charging case. If this is required, the OCS is responsible to generate CDRs similar in scope to the ones described in offline charging above. "

The MSC server and Gateway MSC server are responsible for the collection of all charging relevant information for each MS and PSTN connection and for the storage of this information in the form of CDRs.

Circuit switched calls can be charged in one MSC server (the anchor MSC server) where all relevant data is available. That is guaranteed by routing all signalling information though the anchor MSC server even if the traffic channel of a call is routed through another MSC server due to handover.

The Gateway MSC server acts as a gateway into other PLMN or fixed networks. Within the PLMN, the GMSC server is responsible for the generation of CDRs for calls routed from or into other networks.

If subscribed CAMEL services apply to MS, the (G)MSC servers contain CAMEL subscription data providing the information required for invocation of the CAMEL dialogues for controlling the MS terminating and MS originating calls. CDR parameters resulting from the CAMEL treatment applying to MS calls is derived from the CAMEL subscription data.

In addition to user subscribed services, specific dialled CAMEL services might be invoked which also influence existing records or even trigger the generation of separate records steered by service logic.

In addition to the information collected from these network elements, network management functions are required for the administration of on-line charging data stored in the network nodes. This data is employed to drive the charge display on the User Equipment (UE) as required by the Advice of Charge (AoC) service in TS 21.115 [101] and charging perspective of AoC is defined by TS 32.280 [40].

5.5.1 Subscriber charging

5.5.1.0 General

The charging data collected from the HPLMN, interrogating PLMN, and/or VPLMN network elements is employed to determine the network utilization charges for the basic and supplementary services utilized by the home subscribers of the PLMN. The charges calculated are then combined with the network access (subscription) charges and billed to those customers directly serviced by the PLMN.

For those subscribers handled by Service Providers, the billing information is employed for both wholesale (Network Operator to Service Provider) and retail (Service Provider to Subscriber) billing. Consequently, having been processed by the PLMN billing system, the charging data collected from the network elements may also be sent to the Service Provider for further processing.

5.5.1.1 Calling party charging

This applies to calling party pays in charged party principals defined in TS 22.115 [101].

For subscription related chargeable events the charging information shall indicate the charged party is normally the calling party. It should be possible for multiple leg calls (e.g. forwarded, conference or roamed) to be charged to each party as if each leg was separately initiated. However, in certain types of call, the originating party may wish/be obliged to pay for other legs (e.g. SMS MO may also pay for the MT leg.).

It shall be possible to change the chargeable party at the call set-up.

5.5.1.2 Alternate party charging for IMS

This applies to the alternate charged party in charged party principles defined in TS 22.115 [101].

In IMS offline and online charging as an alternative it is possible that neither calling nor called party can be charged for the IMS session. The alternate charged party need not be registered at the time that the charges are made. It is required however, that the alternate charged party be a verifiable charged party. Selection and verification is done through internal actions in the SIP-AS. The Subscription Identification contains the identity of alternate charged party. The IMS session is then processed in the normal manner.

NOTE: The method for verifying the alternate charged party is not covered in the current release.

5.5.2 Credit-Control and balance management

Editor’s note: There may be more issues to consider in this clause, e.g. consideration of proper amounts for reservation.

5.5.2.1 Use of credit pooling

Credit fragmentation can occur when it is necessary to grant separate quotas. Granting each quota causes some of the user’s credit to be reserved at the Server. It is then possible that all the user’s credit may be reserved when the user wishes to start using a new service. The new service may then be denied, despite the fact that there remains unused credit in the user’s account.

To avoid such credit fragmentation and unnecessary load on the server, it is possible for multiple quotas provided to be linked into a credit pool. The client may then consider the quotas to form a single pool of credit, from which all services draw units.

The reference to a credit pool includes a translation factor derived from the rating parameter, which translates from units of a specific type (time/volume) to the abstract units in the pool.

The use of credit pooling is described in IETF RFC 4006 [402].

5.5.3 Inter-operator settlement of Charges

5.5.3.1 Inter-PLMN accounting

Inter-PLMN accounts for roaming traffic are determined in accordance with ITU-T principles (see ITU-T Recommendation D.93 [300]) and are settled by means of the GSM Association’s Transferred Account Procedure (TAP).

5.5.3.2 ‘Visitors’ from other PLMNs

The CDRs collected from the network also include details of the services employed by visiting (roaming) subscribers. The charges for Mobile Originated Calls (MOCs) and for supplementary services used are calculated as for home subscribers, converted to an agreed accounting currency and included in the CDRs for the TAP. Even if Mobile Terminated Calls (MTCs) are zero-priced in the visited network (VPLMN), in the absence of ‘optimized routing’ the MTC TAP records are still required by the home network (HPLMN) in order to determine the re-routing charges from the HPLMN to the VPLMN.

The TAP records generated are exchanged with each HPLMN on a regular basis. These TAP records form the basis of the invoice submitted by the VPLMN for the traffic carried.

5.5.3.4 ‘Home’ subscribers roaming in other PLMNs

The HPLMN receives TAP records from each VPLMN for services employed by home subscribers whilst roaming. These records are employed to verify the invoices from the VPLMN and to bill the home subscribers for the services used. The charges contained in the TAP records are converted from the accounting currency to the local currency and a handling surcharge (mark-up) is added if required. The TAP records are subsequently passed to the subscriber billing process described in clause 5.1.2.1.

5.5.3.5 Fixed network operators and other service providers

The settlement of accounts with the operators of fixed networks for traffic carried, is generally performed on a bulk basis according to the principles outlined in the ITU-T D-series recommendations.

The traffic accounted for in this manner may include:

– outgoing (Mobile to Land) traffic;

– incoming (Land to Mobile) traffic;

– transit traffic, carried by intermediate networks;

– signalling (MAP/SCCP, CAP/SCCP) traffic such as location updates.

Accounting information may also be required for the use of services provided by other operators such as short message service centres and other Value Added Service (VAS) providers.

The charges for the various traffic shares may be determined on the basis of the CDRs generated by the network elements or on the basis of bulk counters (accounting meter records) in the gateway MSC servers (GMSC servers). For the purpose of the present document, the management information required is assumed to be derived from CDRs. The management of accounting meters is outside the scope of the present document.

5.5.3.6 IMS Interconnection

IMS Interconnection may include the following scenarios

– Interworking between several IMS-based networks

– Interworking between IMS-based networks and PSTN/ISDN

– Interworking between IMS-based networks and TISPAN NGN supporting PSTN/ISDN Emulation

– Interworking between IMS-based networks and non-IMS-based networks

– IMS transit scenarios in multi operator environments where one or more transit operators are between the originating and terminating operator.
For IMS transit scenarios, all involved transit operators get captured in the signalling, as described in clause 5.3.4.3. Depending on the operator specific policy, IMS transit charging may be limited to the immediately adjacent transit operators only, or consider all involved transit carriers within the multi-operator environment.

IMS Interconnection charging is described in TS 32.260 [20].

5.5.3.7 Charging Principles for Roaming Architecture for Voice over IMS with Local Breakout

The Roaming Architecture for Voice over IMS with Local Breakout is described in the TS 23.228 [209].

The roaming charging procedures for Roaming Architecture for Voice over IMS with Local Breakout shall be based on the existing principles described in clauses 5.5.3.1, 5.5.3.2 and 5.5.3.4.

Additionally, roaming charging data for Roaming Architecture for Voice over IMS with Local Breakout shall provide the following information:

– Indicator whether loopback or home routing has been applied

– Final destination for the session when loopback is applied

– Indicator whether OMR (Optimal Media Routing) has been applied

– Charging data created by VPLMN after the loopback must be assigned to a user identified by the P-Asserted-Identity.

NOTE: this is different from charging data collected for interconnection accounting, where identity of served user is optional and not relevant for post-processing.

Details are described in the TS 32.260 [20]

5.5.3.8 Charging Principles for roaming architecture for voice over IMS with home routed traffic

The roaming architecture for voice over IMS with home routed traffic is described in the TS 23.228 [209]. The breakout point for both the IMS signalling and media traffic is in the home network for a roaming UE, i.e. for 3GPP systems, the P-GW/GGSN/SMF-UPF for a roaming UE is in the HPLMN of the UE.

Based on GSMA BA.27 [500], the VPLMN will not have awareness of the services being used over the IMS APN and cannot support service-aware wholesale charging. Data roaming charges will apply for all traffic traversing S8 or Gp interface per the existing data roaming agreement. The HPLMN operator will be responsible for all interworking connectivity and call termination fees associated with call or service termination.

Specifically, the serving PLMN identifier of the UE is needed for the home network.

Details are described in the TS 32.260 [20].

5.5.3.9 Charging principles for 5G Roaming architecture with local breakout

The 5G System roaming architecture with local breakout is specified in TS 23.501 [215]. The breakout point for both the control plane signalling and user plane traffic is in the VPLMN, i.e. the vSMF and vUPF respectively.

The VPLMN charging mechanism collects charging information related to the 5G data connectivity usage for each UE detected as in-bound roamer. The information collected include details of the services used by the visiting subscriber and it is conveyed to both the CHF in VPLMN and to the CHF in the HPLMN.

The CHF in the VPLMN uses the collected charging information for wholesale charging including service aware towards the HPLMN

The CHF in the HPLMN uses the collected charging information for retail charging towards the home subscriber while roaming.

Charging for Roaming with Local Breakout is covered by the 5G data connectivity domain converged charging architecture specified in TS 32.255 [15], using the SMF embedding the CTF.

5.5.3.10 Charging principles for 5G non roaming Mobile Virtual Network Operators (MVNOs) charging

For scenarios in which subscribers have a subscription with an MVNO which allows usage of 5G data connectivity while in the home MNO, the MNO shall be able to collect charging information related to 5G data connectivity usage for each MVNO, for wholesale. The MVNO deploys their own billing and charging (CHF), but no other NFs.

The charging mechanism in the MNO collects charging information related to the 5G data connectivity usage for each UE and conveys this charging information to the MVNO for each UE.

The MVNO uses the charging information collected for retail charging (MVNO to subscriber). Charging for MVNO scenario is covered by the 5G data connectivity domain converged charging architecture specified in TS 32.255 [15].

N47 reference point is also used when an additional actor (i.e. MVNO) performs retail charging for its own subscribers. In such a case N47 is the reference point between SMF in the MNO and CHF in the MVNO.

5.5.4 Advice of Charge

The charging data collected from the network elements may be used to provide tariff information concerning the use of services, by both home and visiting subscribers, within the network. The appropriate tariff information to the network elements is distributed by the Advice of Charge supplementary service. The function is specified in TS 32.280 [40].

An alternative mode of AoC can also be used to indicate the occurrence of new charges to the user, e.g. when a monthly allowance is being exceeded, or when a service is requested that is not included in the subscription fees, while others are. This topic is for further study.