Content for TS 32.240 Word version: 18.1.0
5.3 Charging levels and correlation
5.3.1 Bearer level charging
5.3.2 Subsystem level charging
5.3.3 Service level charging
5.3.4 Charging data correlation
5.4 Charging data configuration
5.5 Charging information utilisation
5.5.0 Introduction
5.5.1 Subscriber charging
5.5.2 Credit-Control and balance management
5.5.3 Inter-operator settlement of Charges
5.5.4 Advice of Charge
6 Service specific charging
6.1 Introduction
6.2 5G LAN-type service charging
6.3 5G Edge computing services charging
...
...
5.3 Charging levels and correlation p. 46
5.3.1 Bearer level charging p. 46
5.3.1.1 Bearer charging based on bearer / tele- / supplementary service p. 46
5.3.1.2 Flow based bearer charging p. 46
5.3.2 Subsystem level charging p. 46
5.3.3 Service level charging p. 46
5.3.4 Charging data correlation p. 46
5.3.4.0 General |R12| p. 46
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.
5.3.4.1 Intra-level correlation p. 47
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 p. 47
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 p. 47
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:
f)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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:
h)
- 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);
- 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.
- Type 3 IOI: between the home IMS network operator and a service provider;
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.
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.
5.3.4.4 Determination of completeness of charging information in IMS |R14| p. 49
5.3.4.4.1 General p. 49
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 p. 49
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 p. 49
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 p. 49
Charging interface applications are specified for Rf and Ro in TS 32.299, for Nchf in TS 32.291, for Ga in TS 32.295, and for Bx in TS 32.297 and TS 32.298. 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
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
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
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:
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.
OM
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.
The following principles apply for Information Element (IE) and CDR parameter category across the specifications:
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.
- Category for IEs common between the middle tier TSs (stage 2) and TS 32.290: 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 and TS 32.299.
- CDR parameter category in the middle tier TSs takes precedence over the corresponding ASN.1 field syntax in TS 32.298.
5.5 Charging information utilisation p. 51
5.5.0 Introduction |R12| p. 51
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 22.115 and charging perspective of AoC is defined by TS 32.280.
5.5.1 Subscriber charging p. 51
5.5.1.0 General |R12| p. 51
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 |R7| p. 52
This applies to calling party pays in charged party principals defined in TS 22.115.
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 |R7| p. 52
This applies to the alternate charged party in charged party principles defined in TS 22.115.
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.
5.5.2 Credit-Control and balance management p. 52
5.5.2.1 Use of credit pooling p. 52
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 RFC 4006 [402].
5.5.3 Inter-operator settlement of Charges p. 52
5.5.3.1 Inter-PLMN accounting p. 52
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 p. 52
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 p. 53
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.2.1.
5.5.3.5 Fixed network operators and other service providers p. 53
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.
5.5.3.6 IMS Interconnection |R11| p. 53
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.
5.5.3.7 Charging Principles for Roaming Architecture for Voice over IMS with Local Breakout |R12| p. 53
The Roaming Architecture for Voice over IMS with Local Breakout is described in the TS 23.228.
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.
5.5.3.8 Charging Principles for roaming architecture for voice over IMS with home routed traffic |R14| p. 54
The roaming architecture for voice over IMS with home routed traffic is described in the TS 23.228. 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.
5.5.3.9 Charging principles for 5G Roaming architecture with local breakout |R17| p. 54
The 5G System roaming architecture with local breakout is specified in TS 23.501. 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, using the SMF embedding the CTF.
5.5.3.10 Charging principles for 5G non roaming Mobile Virtual Network Operators (MVNOs) charging |R17| p. 54
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.
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 p. 55
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.
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.
6 Service specific charging |R17| p. 55
6.1 Introduction p. 55
There are services that spans domains, systems and functions to provide the service, this clause gives an overview of these services and which specifications that could be used to charge for the service.
6.2 5G LAN-type service charging p. 55
6.2.1 General p. 55
The 5G LAN-type service charging specified in the clause 5.34.10 of TS 23.501, including the 5G VN group management and 5G VN group communication.
The 5G VN group configuration is either provided by OA&M or provided by an AF to the NEF.
The 5G VN group management charging is applicable for the 5G VN group addition/deletion/modification (i.e.5G VN members), including the following two optional architecture specified in TS 32.254. which optional charging architecture to be used is depended on the operator's decision.
- CEF based charging: obtains the 5G VN group information from UDM by CEF, and reports to CHF.
- NEF based charging: reports the 5G VN group charging information by NEF based on the API invocation from AF. NEF exposure function Northbound Application Program Interfaces (APIs) charging, using the NEF embedding the CTF.
6.3 5G Edge computing services charging p. 55
Edge Computing support in 5GS is defined in TS 23.501, TS 23.502 and TS 23.548. The architecture for enabling Edge Applications is specified in TS 23.558.
The charging principles for the Edge Computing domain are specified in TS 32.257 and TS 32.255.
The architecture of Edge Computing in Local Breakout roaming scenario and charging for Edge Computing in local breakout follows the principles in clause 5.5.3.9 are specified in TS.23.501 [215].
