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…

 

5.3  Charging levels and correlationWord‑p. 43

5.3.1  Bearer level chargingWord‑p. 43

5.3.1.1  Bearer charging based on bearer / tele- / supplementary serviceWord‑p. 43

Charging data are also collected for supplementary service activity.

5.3.1.2  Flow based bearer chargingWord‑p. 43

5.3.2  Subsystem level chargingWord‑p. 43

5.3.3  Service level chargingWord‑p. 43

5.3.4  Charging data correlationWord‑p. 43

5.3.4.0  General |R12|Word‑p. 43

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

5.3.4.1  Intra-level correlationWord‑p. 44

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 correlationWord‑p. 44

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 correlationWord‑p. 44

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.
  4. 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.
  5. 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.
  6. 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.
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.
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.
Up

5.3.4.4  Determination of completeness of charging information in IMS |R14|Word‑p. 46

5.3.4.4.1  GeneralWord‑p. 46
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 informationWord‑p. 46
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.
Up
5.3.4.4.3  Tracking of applications generating charging informationWord‑p. 46
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.
Up

5.4  Charging data configurationWord‑p. 46

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.
(not reproduced yet)
Figure 5.4.1: Logical diagram illustrating the different parameter categories
Up
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.
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: 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.
Up

5.5  Charging information utilisationWord‑p. 48

5.5.0  Introduction |R12|Word‑p. 48

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

5.5.1  Subscriber chargingWord‑p. 48

5.5.1.0  General |R12|Word‑p. 48

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

5.5.1.1  Calling party charging |R7|Word‑p. 49

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

5.5.1.2  Alternate party charging for IMS |R7|Word‑p. 49

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

5.5.2  Credit-Control and balance managementWord‑p. 49

5.5.2.1  Use of credit poolingWord‑p. 49

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].
Up

5.5.3  Inter-operator settlement of ChargesWord‑p. 49

5.5.3.1  Inter-PLMN accountingWord‑p. 49

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 PLMNsWord‑p. 49

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

5.5.3.4  'Home' subscribers roaming in other PLMNsWord‑p. 50

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

5.5.3.5  Fixed network operators and other service providersWord‑p. 50

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

5.5.3.6  IMS Interconnection |R11|Word‑p. 50

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

5.5.3.7  Charging Principles for Roaming Architecture for Voice over IMS with Local Breakout |R12|Word‑p. 50

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.
Details are described in the TS 32.260
Up

5.5.3.8  Charging Principles for roaming architecture for voice over IMS with home routed traffic |R14|Word‑p. 51

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

5.5.4  Advice of ChargeWord‑p. 51

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

Up   Top   ToC