5 Northbound API charging principles and scenarios
32.2543GPPCharging managementExposure function Northbound Application Program Interfaces (APIs) chargingRelease 17Telecommunication managementTS
5.1 Northbound API charging principles
5.1.0 General
The following are high level charging requirements for northbound API for Exposure Function which are specified in TS 23.682 [243] and TS 23.501 [200]:
For northbound API invocation/notification, the SCEF or NEF shall collect the following charging information:
– invocations/notifications count of the northbound APIs.
– identification of the SCS/AS or AF and the associated northbound API invocation/notification.
– timestamp of the northbound API invocation/notification.
– northbound API related information, e.g. location.
5.1.1 Northbound API procedures
All procedures that operate across the T8 reference point, as specified in 3GPP TS 23.682 [243] and TS 29.122 [230], are covered, which are the following:
– Monitoring
– Resource management of Background Data Transfer
– Changing the chargeable party at session set up or during the session
– Non-IP Data Delivery
– Device Triggering
– Group Message Delivery
– Reporting of Network Status
– Communication Pattern Parameters Provisioning
– PFD Management
– Enhanced Coverage Restriction Control
– Network Parameter Configuration
– Setting up an AS session with required QoS
– MSISDN-less Mobile Originated SMS
The following clauses 5.2 and 5.3 describe the trigger conditions and simplified message flows for Event Based Charging(IEC/ECUR), with interfaces specified in 3GPP TS 32.299 [50].
The Northbound APIs supported by the NEF via the set of exposed services defined in 3GPP TS 23.502 [201] are covered for converged charging, with the trigger conditions and message flows defined in clause 5.4.
5.2 Northbound API offline charging scenarios
5.2.1 Basic principles
If charging is supported by an SCEF, it shall be able to collect charging information per T8 transaction.
The SCS/AS is identified by the SCS Identifier, which T8 transaction between SCEF and SCS/AS can be determined by a T8 Long Term Transaction Reference ID (TLTRI). The Identifiers are stored on both the SCEF and the SCS/AS for the duration of the transaction.
The following chargeable events are defined for SCEF charging for all Northbound APIs:
– Northbound API invocation/ notification per T8 transaction.
– Expiry of an operator configured time limit per T8 transaction.
– Expiry of an operator configured Northbound API invocation limit per T8 transaction.
Management intervention may also force trigger a chargeable event.
The subscriber is the API invoker (e.g. SCS, AS) of the Northbound APIs.
5.2.2 Rf message flows
5.2.2.1 Triggers for charging events from SCEF
When a charging event is reported to the CDF, it includes the details such as SCEF address, charging information with corresponding charging events to the CDF.
The trigger conditions specified in Table 5.2.2.1.1 are applicable for charging information collection.
Table 5.2.2.1.1: Triggers for Charging Data Request from SCEF
|
message |
Triggering conditions |
|
Charging Data Request[Event] |
T8 transaction creation via HTTP POST |
|
T8 transaction update via HTTP PATCH message, HTTP PUT message received by SCEF |
|
|
T8 transaction termination via HTPP DELETE |
5.2.3 CDR generation
5.2.3.1 Introduction
For the exposure functions SCEF, an exposure function API CDR is generated for subsequent transfer to the Charging Gateway Function (CGF).
The following clauses describe the trigger conditions for these exposure function API CDRs creation, update and closure.
5.2.3.2 Triggers for EA-SCE-CDR creation and closure
5.2.3.2.1 Triggers for EA-SCE-CDR generation
A EA-SCE-CDR is used to collect charging information related to API invocation/notification offline charging from the SCEF.
A single EA-SCE-CDR shall be generated for each event when the API invocation or notification is encountered.
5.2.4 Ga record transfer flows
Details of the Ga protocol application are specified in TS 32.295 [54].
5.2.5 Bea CDR file transfer
Details of the Bea protocol application are specified in TS 32.297 [52].
5.3 Northbound API online charging scenarios
5.3.1 Basic principles
5.3.1.1 General
Northbound API online charging is performed by the SCEF using the common Ro based Credit-Control application specified in TS 32.299 [50]. In order to provide the data required for the management activities outlined in TS 32.240 [1], the SCEF shall be able to perform online charging for the following:
– Charging data related to northbound API invocation;
– Charging data related to northbound API notification.
Event based online charging IEC and ECUR are applicable scenarios for the SCEF.
5.3.2 Ro message flows
5.3.2.1 Event Based Charging
This clause contains message flows for the different operation models IEC and ECUR, when the one-time API invocation is per T8 interaction is activated. e.g. Enhanced Coverage Restriction Control API, MSISDN-less Mobile Originated SMS API.
Figure 5.3.2.1.1: Online charging in API Invocation for IEC
1) SCEF receives an API invocation Request.
2) The SCEF triggers a Debit Units Request message to the OCS.
3) The OCS performs the appropriate credit processing based on the received request.
4) The OCS responds with a Debit Units Response message to the SCEF.
5) If authorized, the SCEF continues the API invocation processing and send out the API Invocation Response.
Figure 5.3.2.1.2: Online charging in API Notification for IEC
1) SCEF receives a notification from 3GPP network element.
2) The SCEF triggers a Debit Units Request message to the OCS.
3) The OCS performs the appropriate credit processing based on the received request.
4) The OCS responds with a Debit Units Response message to the SCEF.
5) SCEF sends the notification to SCS/AS.
6) SCEF receives acknowledgement for the notification.
Figure 5.3.2.1.3: Online charging in API Invocation for ECUR
1) SCEF receives an API invocation Request.2) The SCEF triggers a Reserve Units Request [Initial] message to the OCS.
3) The OCS performs the appropriate credit processing based on the received request.
4) The OCS responds with a Reserve Units Response message to the SCEF.
5) If authorized, the SCEF continues the API invocation processing and send out the API Invocation Response.
6) The SCEF triggers a Debit Units Request [Terminate] message to the OCS reporting the successful event transaction.
7) The OCS performs the appropriate credit processing based on the received request.
8) The OCS responds with a Debit Units Response message to the SCEF.
Figure 5.3.2.1.4: Online charging in API Notification for ECUR
1) SCEF receives a notification from 3GPP network entities.
2) The SCEF triggers a Reserve Units Request [Initial] message to the OCS.
3) The OCS performs the appropriate credit processing based on the received request.
4) The OCS responds with a Reserve Units Response message to the SCEF.
5) SCEF sends the notification to SCS/AS.
6) SCEF receives acknowledgement for the notification.
7) The SCEF triggers a Debit Units Request [Terminate] message to the OCS reporting the successful event transaction.
8) The OCS performs the appropriate credit processing based on the received request.
9) The OCS responds with a Debit Units Response message to the SCEF.
5.4 Northbound API converged online and offline charging scenarios
5.4.1 Basic principles
5.4.1.1 General
Converged charging may be performed by the NEF interacting with CHF using Nchf specified in TS 32.290 [57] and TS 32.291 [58]. In order to provide the data required for the management activities outlined in TS 32.240 [1] (Credit-Control, accounting, billing, statistics etc.), the NEF shall be able to perform converged charging for the northbound API access.
The NEF shall be able to perform convergent charging by interacting with CHF, for charging data related to Northbound API access. The Charging Data Request and Charging Data Response are exchanged between the NEF and the CHF, based on PEC, either IEC or ECUR scenarios specified in TS 32.290 [57]. The Charging Data Request is issued by the NEF towards the CHF when certain conditions (chargeable events) are met.
Converged charging uses centralized or decentralized unit determination and centralized rating scenarios for event based convergent charging specified in TS 32.290 [57].
The contents and purpose of each charging event that triggers interaction with CHF, as well as the chargeable events that trigger them, are described in the following clauses.
A detailed formal description of the converged charging parameters defined in the present document is to be found in TS 32.291 [58].
A detailed formal description of the CDR parameters defined in the present document is to be found in TS 32.298 [51].
The selection of the CHF can be configured in the NEF but may also rely on NRF.
5.4.1.2 Applicable Triggers in the NEF
5.4.1.2.1 General
When a charging event is issued towards the CHF, it includes details such as Subscriber identifier (e.g. identifier of the AF).
Each trigger condition (i.e. chargeable event) defined for the NEF converged charging functionality, is specified with the associated behaviour when they are met.
Table 5.4.1.2.1.1 summarizes the set of default trigger conditions and their category which shall be supported by the NEF when charging is active for the corresponding NEF functionality. For "immediate report" category, the table also provides the corresponding Charging Data Request message sent from NEF towards the CHF.
Table 5.4.1.2.1.1: Default Trigger conditions in NEF
|
Trigger Conditions |
Trigger level |
Default category |
CHF allowed to change category |
CHF allowed to enable and disable |
Message when "immediate reporting" category |
|---|---|---|---|---|---|
|
API Invocation |
– |
Immediate |
Not Applicable |
Not Applicable |
IEC: Charging Data Request [Event] ECUR: Charging Data Request [Initial] |
|
API Invocation Response |
– |
Immediate |
Not Applicable |
Not Applicable |
PEC: Charging Data Request [Event] ECUR: Charging Data Request [Termination] |
|
API Notification |
– |
Immediate |
Not Applicable |
Not Applicable |
IEC: Charging Data Request [Event] ECUR: Charging Data Request [Initial] |
|
API Notification to NF |
– |
Immediate |
Not Applicable |
Not Applicable |
PEC: Charging Data Request [Event] |
|
API Notification acknowledgement |
– |
Immediate |
Not Applicable |
Not Applicable |
ECUR: Charging Data Request [Termination] |
5.4.2 Message flows
5.4.2.1 Introduction
The different scenarios below focus on the different messages from/to the NEF and corresponding interaction with the CHF, based on scenarios specified in TS 23.222 [202].
5.4.2.2 API Invocation – IEC
Figure 5.4.2.2.1 describes the scenario where there is an API invocation request at the NEF for IEC mode
Figure 5.4.2.2.1: API Invocation Request to NEF using IEC
1. NEF receives an API invocation Request from an AF.
1ch-a. The NEF sends Charging Data Request [Event] to CHF for the received API Invocation.
1ch-b. The CHF creates a CDR for this API Invocation.
1ch-c. The CHF acknowledges and grants authorization by sending Charging Data Response [Event] to the NEF.
2. NEF performs the actions needed to fulfil the API invoked.
3. If authorized, the NEF continues the API invocation processing and sends the API Invocation Response.
5.4.2.3 API Invocation – ECUR
Figure 5.4.2.3.1 describes the scenario where there is an API invocation request at the NEF for ECUR mode.
Figure 5.4.2.3.1: API Invocation Request to NEF using ECUR
1. NEF receives an API invocation Request from an AF.
1ch-a. The NEF sends Charging Data Request [Initial] to CHF for the received API Invocation.
1ch-b. The CHF opens CDR for this API Invocation.
1ch-c. The CHF acknowledges by sending Charging Data Response [Initial] to the NEF.
2. NEF performs the actions needed to fulfil the API invoked.
3. If authorized, the NEF continues the API invocation processing and sends the API Invocation Response.
3ch-a. The NEF sends Charging Data Request [Termination] to the CHF for terminating the charging associated with the API Invocation.
3ch-b. The CHF closes the CDR for this API Invocation.
3ch-c. The CHF acknowledges by sending Charging Data Response [Termination] to the NEF.
5.4.2.4 API Notification – IEC
Figure 5.4.2.4.1 describes the scenario where an API Notification is delivered from the NEF for IEC mode
Figure 5.4.2.4.1 API Notification from NEF using IEC
1. The NEF receives a notification from an NF.
1ch-a. The NEF sends Charging Data Request [Event] to CHF for the Notification.
1ch-b. The CHF creates a CDR for this Notification.
1ch-c. The CHF acknowledges and grant authorization by sending Charging Data Response [Event] to the NEF.
2. The NEF sends the notification to AF.
3. The NEF receives acknowledgement for the notification.
5.4.2.5 API event Notification – ECUR
Figure 5.4.2.5.1 describes the scenario where an API event Notification is delivered from the NEF for ECUR mode.
Figure 5.4.2.4.1: API Notification from NEF using ECUR
1. The NEF receives a notification from an NF.
1ch-a. The NEF sends Charging Data Request [Initial] to CHF for the Notification.
1ch-b. The CHF opens CDR for this API Notification.
1ch-c. The CHF acknowledges by sending Charging Data Response [Initial] to the NEF.
2. The NEF sends the notification to AF.
3. The NEF receives acknowledgement for the notification.
3ch-a. The NEF sends Charging Data Request [Termination] to the CHF for terminating the charging associated with the API event Notification.
3ch-b. The CHF closes the CDR for this API Notification.
3ch-c. The CHF acknowledges by sending Charging Data Response [Termination] to the NEF.
5.4.2.6 API Invocation – PEC
Figure 5.4.2.6.1 describes the scenario where there is an API invocation request at the NEF for PEC mode
Figure 5.4.2.6.1: API Invocation Request to NEF using PEC
1. NEF receives an API invocation Request from an AF.
2. NEF performs the actions needed to fulfil the API invoked.
3. If authorized, the NEF continues the API invocation processing and sends the API Invocation Response.
3ch-a. The NEF sends Charging Data Request [Event] to CHF for the received API Invocation.
3ch-b. The CHF creates a CDR for this API Invocation.
3ch-c. The CHF acknowledges by sending Charging Data Response [Event] to the NEF.
5.4.2.7 API Notification – PEC
Figure 5.4.2.7.1 describes the scenario where an API Notification is delivered from the NEF for PEC mode
Figure 5.4.2.7.1 API Notification from NEF using PEC
1. The NEF receives a notification from an NF.
2. The NEF sends the notification to AF.
2ch-a. The NEF sends Charging Data Request [Event] to CHF for the Notification.
2ch-b. The CHF creates a CDR for this Notification.
2ch-c. The CHF acknowledges by sending Charging Data Response [Event] to the NEF.
3. The NEF receives acknowledgement for the notification.
5.4.3 CDR generation
5.4.3.1 Introduction
The CHF CDRs for NEF charging are generated by the CHF to collect charging information that they subsequently transfer to the Charging Gateway Function (CGF).
The following clauses describe in details the conditions for generating, opening and closing the CHF CDR, which shall be supported by the CHF.
5.4.3.2 Triggers for CHF CDR
5.4.3.2.1 General
A Northbound API charging CHF CDR is used to collect charging information related to northbound API invocation and notifications chargeable events for PEC, IEC and ECUR.
5.4.3.2.2 Triggers for CHF CDR generation
A CHF CDR is generated by the CHF for each received Charging Data Request[Event].
5.4.3.2.3 Triggers for CHF CDR opening
A CHF CDR shall be opened when the CHF receives Charging Data Request[Initial].
5.4.3.2.4 Triggers for CHF CDR closure
The CHF CDR shall be closed when the CHF receives Charging Data Request[Termination].
5.4.4 Ga record transfer flows
Details of the Ga protocol application are specified in TS 32.295 [6].
5.4.5 Bea CDR file transfer
Details of the Bea protocol application are specified in TS 32.297 [5].