5.2.1 Basic principles
32.2553GPP5G data connectivity domain chargingCharging managementRelease 17Stage 2Telecommunication managementTS
5.2.1.1 General
Converged charging may be performed by the SMF 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 SMF shall be able to perform converged charging for each of the following:
– Charging data related to PDU session;
– Charging data related to service data flows within the PDU session.
Converged charging includes quota management and usage reporting.
The SMF shall be able to report charging events to CDF for CDR generation.
The SMF shall be able to perform convergent charging by interacting with CHF, for charging data related to PDU sessions. The Charging Data Request and Charging Data Response are exchanged between the SMF and the CHF, based on SCUR scenarios specified in TS 32.290 [57]. The Charging Data Request is issued by the SMF towards the CHF when certain conditions (chargeable events) are met.
The quota management is always per rating group, reporting level can be either per rating group or per combination of the rating group and service id, which is defined per PCC rule.
Converged charging uses centralized or decentralized unit determination and centralized rating scenarios for session based convergent charging specified in TS 32.290 [57].
The charging information collected per PDU session includes the network slice instance the PDU session belongs to.
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 sub-clauses.
The SMF initiates a charging session with Charging Data Request/Response [Initial], updates the charging session with Charging Data Request/Response [Update], and terminates the charging session with Charging Data Request/Response [Termination].
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].
In order to avoid a charging session remaining inactive for a long period of time, upon expiry of the Unit Count Inactivity Timer, the charging session may be terminated by the SMF sending Charging Data Request [Termination], indicating the PDU session shall continue and the CHF can expect a later Charging Data Request [Initial] request for the same PDU session with the original Charging ID and new session identifier. The SMF may send its locally configured value of the Unit Count Inactivity Timer to the CHF. The CHF may respond with a new Unit Count Inactivity Timer for use in the SMF. Whether the CHF may respond with a value of the Unit Count Inactivity Timer, independent of if the CHF has received one previously from the SMF, is vendor specific
5.2.1.2 Applicable Triggers in the SMF
5.2.1.2.1 General
When a charging event is issued towards the CHF, it includes details such as Subscriber identifier (e.g. SUPI), Charging-id, etc. and also containers identifying the volume count (separated for uplink and downlink traffic), with charging condition change information.
Each trigger condition (i.e. chargeable event) defined for the 5G data connectivity converged charging functionality with the associated behaviours when metis specified in this document and the basic trigger mechanism is specified in the TS 32.290[57].
Two categories of chargeable events are identified:
– immediate report: chargeable events for which, when occurring, the current counts are closed and sent together with the charging data generated by the SMF towards the CHF in a Charging Data Request. New counts are started by the SMF.
– deferred report: chargeable events for which, when occurring, the current counts are closed and stored together with the charging data generated by the SMF. The stored counts will be sent to the CHF in next a Charging Data Request. New counts are started by the SMF.
When more than one trigger condition to be met at same time (i.e. time stamp of triggers is the same) for the same count in the SMF, the SMF reports the used unit container with these triggers.
When a PDU session starts, and the converged charging is activated, the SMF invokes a Charging Data Request [Initial] towards the CHF to get authorization to start based on the default triggers. The SMF is optionally provided in a Charging Data Response [Initial] to override the default triggers, with a set of chargeable event triggers to be enabled, and the associated category (i.e. immediate or deferred report).
The triggers remain active until they are updated or disabled by subsequent Charging Data Response [Update] from the CHF or the PDU session is terminated.
A set of chargeable events are based on trigger thresholds and default ones can be configured in Charging Characteristics which are described in Annex A.
The SMF is optionally provided in the Charging Data Response [Initial], with trigger thresholds which override the default ones configured in the Charging Characteristics selected by the SMF for the PDU session. They remain active until they are updated by subsequent Charging Data Response [Update] from the CHF or the PDU session is terminated.
When a trigger is enabled, the SMF needs to ensure that monitoring in UPF and subscription from RAN are setup so that SMF can report the charging information to the CHF if the chargeable event occurs.
5.2.1.2.2 Flow Based Charging (FBC) triggers
The set of chargeable events and associated category, which shall be supported by the SMF as the default, is specified in the sub-clause 5.2.1.4 for Flow Based Charging.
Two level of triggers can be supplied by the CHF:
– Triggers associated to the PDU session.
– Triggers associated to a rating group within the PDU session.
The set of triggers along with their category (i.e. immediate or deferred report) and level (i.e. per PDU session or per rating group), which can be supplied by the CHF to the SMF for 5G data connectivity converged charging or offline only charging are detailed in the sub-clause 5.2.1.4 for Flow Based Charging.
5.2.1.2.3 QoS flow Based Charging (QBC) triggers
The set of chargeable events and associated category, which shall be supported by the SMF as the default for QoS flow Based Charging, when applicable, is specified in the sub-clause 5.2.1.6.
Two level of triggers can be supplied by the CHF:
– Triggers associated to the PDU session.
– Triggers associated to a QoS Flow within the PDU session.
The set of triggers along with their category (i.e. immediate or deferred report) and level (i.e. per PDU session or per QoS Flow), which can be supplied by the CHF to the SMF for 5G data connectivity converged charging are detailed in clause 5.2.1.6 for QBC.
In home routed scenario, when QBC is used in the context of roaming, the set of triggers, their associated category, and trigger thresholds, compose the "Roaming Charging Profile", which governs the SMF charging data generation, synchronously between the V-SMF and the H-SMF when shared.
In local breakout scenario, the default "Roaming charging profile" for the V-SMF is based on the “Charging characteristics”, and may be set, changed, applied, and transferred in the following order:
1. Default set by V-SMF and transferred to V-CHF
2. Changed by V-CHF and transferred to V-SMF
3. Transferred from V-SMF to H-CHF
4. Changed by H-CHF and transferred to V-SMF
5. Applied in V-SMF and transferred to V-CHF
In local breakout scenario, support for "Roaming changing profile" exchange is done by transferring it i.e., an NF may only change the "Roaming charging profile" if it has received it. The "Roaming charging profile" resulting from the exchange between the VPLMN and HPLMN shall remain valid until it is replaced.
In local breakout scenario, the "Roaming charging profile" overrides any triggers set or updated by the CHF for Roaming QBC.
5.2.1.3 PDU session charging
Converged charging allows the SMF to collect charging information related to data volumes sent to and received by the UE/MS per user per PDU session. The user can be identified by SUPI.
If PDU session specific converged charging is supported, this is achieved by FBC charging, with specific rating group/service identifier, see clause 5.2.1.4.
5.2.1.4 Flow Based Charging (FBC)
For FBC charging, the SMF categorizes the service data flows within PDU session data traffic by rating group and / or combination of the rating group and service id. The level of the reporting and charging method is defined per PCC rule. Details of this functionality are specified in TS 23.503 [202] and TS 32.240 [1].
The SMF can include the QoS Information per rating group or per combination of rating group/service id. If the QoS Information cannot be unambiguously determined per rating group or per combination of rating group/service id, it should be omitted.
NOTE: The SMF can only include one QoS Information occurrence per combination of rating group/service id. This implies if an operator wishes to be able to separate usage according to 5QI and ARP for the same charging method, they will need to ensure that service data flows having different 5QI and ARP do not have the same:
– rating group in cases where rating reporting is used;
– rating group/service id where rating group/service id reporting is used.
When a service data flow is governed by a PCC Rule indicated with "Online" charging method, quota management is required for the service data flow. It may also indicate if authorization for the service data flow is needed or not before service delivery, i.e. blocking or non-blocking mode.
When a service data flow is governed by a PCC Rule indicated with "Offline" charging method, quota management is not required for this service data flow. Usage reporting is required for this service data flow without affecting the delivery.
According to TS 23.503 [202], FBC shall support different charging models per PCC rule. These charging models may be based on volume and/or time and on number of events matching a specific service data flow template in PCC rule. When a chargeable event occurs for which quota needs to be requested by the SMF to the CHF, the type of requested quota may depend on measurement method configured for the PCC rule.
In general, the charging of a service data flow shall be linked to the PDU session under which the service data flow has been activated.
The amount of data counted shall be the user plane payload at the UPF separated between UL and DL.
For PDU session specific charging, time metering shall start when PDU session is activated.
Table 5.2.1.4.1 summarizes the set of default trigger conditions and their category which shall be supported by the SMF. For "immediate report" category, the table also provides the corresponding Charging Data Request [Initial, Update, Termination] message sent from SMF towards the CHF.
Table 5.2.1.4.1: Default Trigger conditions in SMF
Trigger Conditions |
Trigger level |
Converged Charging default category |
Offline only charging default category |
CHF allowed to change category |
CHF allowed to enable and disable |
Message when "immediate reporting" category |
---|---|---|---|---|---|---|
Start of PDU Session. |
PDU session |
Immediate |
Immediate |
Not Applicable |
Not Applicable |
Charging Data Request [Initial] |
Start of the Service data flow and no charging session exists. |
RG |
Immediate |
Immediate |
No |
No |
|
Change of Charging conditions |
Charging Data Request [Update] |
|||||
QoS change |
PDU session/ RG |
Deferred |
Deferred |
Yes |
Yes |
|
GFBR guaranteed status change |
RG |
Deferred |
Deferred |
Yes |
Yes |
|
User Location change |
PDU session/ RG |
Deferred |
Deferred |
Yes |
Yes |
|
Serving Node change |
PDU session/ RG |
Deferred |
Deferred |
Yes |
Yes |
|
Change of UE presence in Presence Reporting Area(s) |
PDU session/ RG |
Deferred |
Deferred |
Yes |
Yes |
|
Change of 3GPP PS Data off Status |
PDU session/ RG |
Deferred |
Deferred |
Yes |
Yes |
|
Tariff time change |
PDU session/ RG |
Deferred |
Deferred |
No |
No |
|
UE time zone change |
PDU session/ RG |
Immediate |
Deferred |
Yes |
Yes |
|
PLMN change |
PDU session/ RG |
Immediate |
Deferred |
Yes |
Yes |
|
RAT type change |
PDU session/ RG |
Immediate |
Deferred |
Yes |
Yes |
|
Session-AMBR change |
PDU session |
Immediate |
Deferred |
Yes |
Yes |
|
Addition of UPF |
PDU Session/RG |
Immediate |
Deferred |
Yes |
Yes |
|
Removal of UPF |
PDU session/RG |
Immediate |
Deferred |
Yes |
Yes |
|
Insertion of I-SMF |
PDU Session |
Deferred |
Deferred |
Yes |
Yes |
|
Change of I-SMF |
PDU Session |
Deferred |
Deferred |
Yes |
Yes |
|
Removal of I-SMF |
PDU Session |
Deferred |
Deferred |
Yes |
Yes |
|
Handover cancel |
PDU session |
Immediate |
Deferred |
Yes |
Yes |
|
Handover start |
PDU session |
Immediate |
Deferred |
Yes |
Yes |
|
Handover complete |
PDU session |
Immediate |
Deferred |
Yes |
Yes |
|
Addition of access |
PDU session/ RG |
Immediate |
Deferred |
Yes |
Yes |
|
Removal of access |
PDU session/ RG |
Immediate |
Deferred |
Yes |
Yes |
|
Redundant transmission change |
RG |
Immediate |
Deferred |
Yes |
Yes |
|
Limit per PDU session |
||||||
Expiry of data time limit per PDU session |
PDU session |
Immediate |
Immediate |
No |
Yes |
|
Expiry of data volume limit per PDU session |
PDU session |
Immediate |
Immediate |
No |
Yes |
|
Expiry of data event limit per PDU session |
PDU session |
Immediate |
Immediate |
No |
Yes |
|
Expiry of limit of number of charging condition changes |
PDU session |
Immediate |
Immediate |
No |
Yes |
|
Limit per Rating group |
||||||
Expiry of data time limit per rating group |
RG |
Deferred |
Deferred |
Yes |
Yes |
|
Expiry of data volume limit per rating group |
RG |
Deferred |
Deferred |
Yes |
Yes |
|
Expiry of data event limit per rating group |
RG |
Deferred |
Deferred |
Yes |
Yes |
|
Quota management |
||||||
Time threshold reached |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Volume threshold reached |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Unit threshold reached |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Time quota exhausted |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Volume quota exhausted |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Unit quota exhausted |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Expiry of quota validity time |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Expiry of quota holding time |
RG |
Immediate |
Not applicable |
No |
Yes |
|
Re-authorization request by CHF |
RG |
Immediate |
Not applicable |
No |
No |
|
Start of service data flow, in case no valid quota for this rating group |
RG |
Immediate |
Not applicable |
No |
No |
|
Start of SDF additional access, in case no valid quota for this access rating group |
RG |
Immediate |
Not applicable |
No |
No |
|
Others |
||||||
Termination of service data flow – last service data flow under a given Rating Group. |
RG |
Immediate |
Immediate |
No |
No |
|
Management intervention |
PDU session |
Immediate |
Immediate |
No |
No |
|
Expiry of Unit Count Inactivity Timer |
PDU session |
Immediate |
Not applicable |
No |
No |
Charging Data Request [Termination] |
End of PDU session |
PDU session |
Immediate |
Immediate |
No |
No |
|
CHF response with session termination |
PDU session |
Immediate |
Not applicable |
No |
No |
|
Abort request is received from the CHF |
PDU session |
Immediate |
Immediate |
No |
No |
|
NOTE 1: If GFBR guaranteed status change is enabled, SMF needs to ensure the request for the notification from the access network (i.e. 3GPP RAN) when the GFBR can no longer (or can again) be guaranteed for a QoS Flow during the lifetime of the QoS Flow. |
The default "Limit" trigger conditions are trigger thresholds configured in the Charging Characteristics applied to the PDU session. It shall be possible for the CHF to override these default triggers when providing Charging Data Response [Initial], either to disable the triggers, or to enable triggers new thresholds value.
When the traffic is counted in more than one UPF, the CHF overrides these default triggers of volume limit for the all UPFs.
For converged charging, the following details of chargeable events and corresponding actions in the SMF are defined in Table 5.2.1.4.2:
Table 5.2.1.4.2: Chargeable events and their related actions in SMF
Chargeable event |
Conditions |
SMF action |
---|---|---|
Start of PDU session |
Charging Data Request [Initial] with a possible request quota for later use. |
|
Start of service data flow |
If quota management is required, and valid quota for this rating group does not exist |
Charging Data Request [Update] to request quota with a possible amount of quota. |
If service identifier level reporting is required by the PCC rule |
Start new counts with time stamps for the combination of the rating group and service id |
|
If rating group level reporting is required by the PCC rule |
Start new counts with time stamps for the rating group |
|
If sponsored connectivity level reporting is required by the PCC rule |
Start new counts with time stamps for the combination of the rating group, sponsor identity and application service provider identity |
|
If charging resource, i.e. charging session, for the PDU session does not exist |
Charging Data Request [Initial] with a possible request quota |
|
Start of SDF additional access |
If ATSSS is supported with access differentiated rating groups, quota management is required, and valid quota for this access rating group does not exist. |
Charging Data Request [Update] to request quota with a possible amount of quota. |
If ATSSS is supported with access differentiated rating groups, service identifier level reporting is required by the PCC rule |
Start new counts with time stamps for the combination of the access rating group and service id |
|
If ATSSS is supported with access differentiated rating groups, rating group level reporting is required by the PCC rule |
Start new counts with time stamps for the access rating group |
|
If ATSSS is supported with access differentiated rating groups, sponsored connectivity level reporting is required by the PCC rule |
Start new counts with time stamps for the combination of the access rating group, sponsor identity and application service provider identity |
|
Termination of service data flow |
If service identifier level reporting is required by the PCC rule and this is the last service data flow for this combination of the rating group and service id |
Close the counts with time stamps |
If rating group level reporting is required by the PCC rule and this is the last service data flow utilizing that specific rating group |
Close the counts with time stamps |
|
If sponsored connectivity level reporting is required by the PCC rule and this was the last active service data flow for this combination of rating group, sponsor identity and application service provider identity |
Close the counts with time stamps |
|
Expiry of the Unit Count Inactivity Timer for the PDU session |
If the corresponding trigger is enabled |
Charging Data Request [Termination], indicating that charging session is terminated, and the PDU session is still active May include the configured Unit Count Inactivity Timer value |
End of PDU session in the SMF |
Charging Data Request [Termination] Close the counts with time stamps |
|
Quota specific chargeable events (e.g. threshold reached, QHT expires, quota exhaustion, validity time reached, forced re-authorization, expiry of quota holding time) |
If the corresponding trigger is enabled |
Charging Data Request [Update] with a possible request quota Close the counts and start new counts with time stamps |
Change of charging condition in the SMF (e.g. QoS change, Session-AMBR change, user location change, Radio access type change, PLMN change, Serving Node change, UE Time Zone change, change of UE presence in Presence Reporting Area(s), change of 3GPP PS Data Off status, handover cancel, GFBR guaranteed status change) |
If the corresponding trigger is enabled |
Close the counts and start new counts with time stamps for all active service data flows |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update] with a possible request quota. |
|
Handover start |
If the corresponding trigger is enabled |
Close the counts with time stamps and start new counts with time stamps for active service data flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update] with a possible request quota. |
|
Handover cancel |
If the corresponding trigger is enabled |
Close the counts with time stamps and start new counts with time stamps for active service data flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update] with a possible request quota. |
|
Handover complete |
If the corresponding trigger is enabled |
Close the counts with time stamps and start new counts with time stamps for active service data flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
Addition of UPF |
If the corresponding trigger is enabled |
Start new counts with time stamps for the added UPF. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" with the quota management is being performed and quota is granted per each UPF |
Charging Data Request [Update] to request quota with a possible amount of quota. |
|
Tariff time change |
Close the counts and start new counts with time stamps |
|
CHF response with session termination (e.g. Not Applicable), abort request |
Charging Data Request [Termination] Close the counts with time stamps |
|
Removal of a UPF |
If the corresponding trigger is enabled |
Close the counts with time stamps for the removed UPF |
If the corresponding trigger is enabled and the category is set to "immediate reporting" with quota management is being performed and quota is granted per each UPF |
Charging Data Request [Update]. |
|
Insertion of I-SMF |
If the corresponding trigger is enabled |
Close the counts with time stamps for all active service data flows in SMF, open new accounts for all active service data flows with I-SMF information. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" with quota management is being performed and quota is granted per each UPF |
Charging Data Request [Update] to request quota with a possible amount of quota. |
|
Removal of I-SMF |
If the corresponding trigger is enabled |
Close the counts with time stamps for the removed I-SMF |
If the corresponding trigger is enabled and the category is set to "immediate reporting" with quota management being performed and quota is granted per each UPF |
Charging Data Request [Update]. |
|
Change of I-SMF |
If the corresponding trigger is enabled |
Close the counts with time stamps for the removed I-SMF, open active traffic flows’ counts for the new I-SMF |
If the corresponding trigger is enabled and the category is set to "immediate reporting" with quota management being performed and quota is granted per each UPF |
Charging Data Request [Update]. |
|
Addition of access |
If the corresponding trigger is enabled |
Close the counts with time stamps for all active service data flows usage report in SMF, open new counts for all active service data flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update] with a possible request quota. |
|
Removal of access |
If the corresponding trigger is enabled |
Close the counts with time stamps for all active service data flows usage report in SMF, open new counts for all active service data flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update]. |
|
Redundant transmission change |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update]. Close the counts and start new counts with time stamps. |
Expiry of time limit per rating group |
If the corresponding trigger is enabled |
Close the counts with time stamps |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If any matching service data flow is still active |
Start new counts with time stamps |
|
Expiry of data volume limit per rating group |
If the corresponding trigger is enabled |
Close the counts with time stamps |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If any matching service data flow is still active |
Open a new service data container |
|
Expiry of data event limit per rating group |
If the corresponding trigger is enabled |
Close the counts with time stamps |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If any matching service data flow is still active |
Open a new service data container |
|
Expiry of data event limit per PDU session |
If the corresponding trigger is enabled |
Charging Data Request [Update] Close the counts with time stamps |
If the PDU session is still active |
Start new counts with time stamps |
|
Expiry of time limit per PDU session |
If the corresponding trigger is enabled |
Charging Data Request [Update] Close the counts with time stamps |
If the PDU session is still active |
Start new counts with time stamps |
|
Expiry of data volume limit per PDU session |
Charging Data Request [Update] Close the counts with time stamps |
|
If the PDU session is still active |
Start new counts with time stamps |
|
Expiry of a limit of number of charging condition changes per PDU session |
Charging Data Request [Update] Close the counts with time stamps |
|
If the PDU session is still active |
Start new counts with time stamps |
|
Management intervention |
Charging Data Request [Update] Close the counts with time stamps |
|
If the PDU session is still active |
Start new counts with time stamps |
When event based charging applies, the first occurrence of an event matching a service data flow template in PCC rule shall be considered as the start of a service.
How the termination of service data flows is detected, is specified in TS 23.503 [202]. Termination of the service data flow itself does not trigger Charging Data Request [Update].
The CDR generation mechanism processed by the CHF upon receiving Charging Data Request [Initial, Update, Termination] issued by the SMF for these chargeable events, is specified in clause 5.2.3.
5.2.1.5 SSC Mode and Triggers
There are two cases related to quota management when the granted quota is volume for multiple UPFs and per Operator’s policy, the traffic is counted in more than one UPF:
– Quota shared by UPFs means that SMF manages the shared quota consumption per RG for multiple UPFs and reports the total quota consumed to CHF;
– Quota granted for each UPF means that the CHF manages the quota granted for each UPF and SMF manages and reports the quota consumption per UPF.
For configurations involving multiple UPFs and Operator’s policy is to count the traffic in a single UPF (e.g. BP), the quota is granted to the SMF for this single UPF per RG for the whole traffic.
The following scenarios describe configurations in which the traffic is counted in more than one UPF:
In case of SSC mode 3 PDU Session Anchor with IPv6 Multi-homed PDU Session,
– The addition of UPF2 and BP (Change the part of traffic from UPF1 to UPF2):
– if quota granted for each UPF, SMF triggers the chargeable event of Start of SDF for UPF2 to request the quota;
– if quota shared by UPFs, SMF requests UPF1 report usage of quota, caches the usage from UPF1 and re-allocates the remaining quota to UPF2 and UPF1(if needed). When the granted quota from CHF is used up, the SMF reports total usage of quota to CHF.
– The removal of UPF1and BP:
– In case the quota management and quota granted for each UPF, UPF1 reports final counts to SMF, SMF triggers the chargeable event of Remove the UPF to report final counts from UPF1;
– In case the quota management and quota shared by UPFs, UPF1 report final counts to SMF, SMF caches the final count from UPF1. SMF sends counts from UPF1 and UPF2 to the CHF together in next Charging Data Request.
– In case without the quota management or offline only charging, UPF1 report final count to SMF, SMF caches the final count from UPF1 and sends counts from UPF1 and UPF2 to the CHF together in next a Charging Data Request. In case of Addition of additional PDU Session Anchor and Branching Point or UL CL.
– The addition of UPF2 and BP (Change the part of traffic from UPF1 to UPF2):
– if quota granted for each UPF, SMF triggers the chargeable event of Start of SDF for UPF2 to request the quota for Rating group;
– if quota shared by UPFs, SMF indicates UPF1 report usage of quota, caches the usage from UPF1 and re-allocates the remain quota to UPF2 and UPF1(if needed). When the granted quota from CHF is used up, the SMF reports total usage of quota to CHF.
In case of Removal of additional PDU Session Anchor and Branching Point or UL CL:
– The removal of UPF1 and BP (Change traffic from UPF1 to UPF2):
– In case the quota management and quota granted for each UPF, UPF1 report final counts to SMF, SMF triggers chargeable event of Remove the UPF to report final counts from UPF1.
– In case the quota management and quota shared by UPFs, UPF1 report final counts to SMF, SMF caches the final count from UPF1 and re-allocates the remain quota to UPF2. SMF sends counts from UPF1 and UPF2 to the CHF together in next a Charging Data Request.
– In case without the quota management or offline only charging, UPF1 report final count to SMF, SMF caches the final count from UPF1 and sends counts from UPF1 and UPF2 to the CHF together in next a Charging Data Request. In case of Change of additional PDU Session Anchor for IPv6 multi-homing or UL CL and Simultaneous change of Branching Point or UL CL and additional PSA for a PDU Session.
– The additional of UPF2 (Change the part of traffic from UPF1 to UPF2):
– if quota granted for each UPF, SMF triggers the chargeable event of Start of SDF for UPF2 to request the quota for Rating group;
– if quota shared by UPFs, SMF indicates UPF1 report usage of quota, caches the usage from UPF1 and re-allocates the remain quota to UPF2 and UPF1(if needed). When the granted quota from CHF is used up, the SMF reports total usage of quota to CHF.
– The removal of UPF1:
– In case the quota management and quota granted for each UPF, UPF1 report final counts to SMF, SMF triggers chargeable event of Remove the UPF to report final counts from UPF1.
– In case the quota management and quota shared by UPFs, UPF1 report final counts to SMF, SMF caches the final count from UPF1 and re-allocates the remain quota to UPF2. SMF sends counts from UPF1 and UPF2 to the CHF together in next Charging Data Request.
– In case without the quota management or offline only charging, UPF1 report final count to SMF, SMF caches the final count from UPF1 and sends counts from UPF1 and UPF2 to the CHF together in next a Charging Data Request.
5.2.1.6 QoS flow Based Charging (QBC)
QoS flow Based Charging allows the SMF to collect charging information related to data volumes per PDU session, categorized per QoS Flow. QBC doesn’t support quota management.
The user can be identified by SUPI.
For a given PDU session, QBC shall be performed by the SMF within the same charging session used for Flow Based Charging. For the case where QBC is performed from SMF in VPLMN, Flow Based Charging is not applicable and there is no possibility to have quota management for the PDU Session. For the case where QBC is performed from SMF in HPLMN, FBC can be performed or not performed at the same time according to operator’s policy.
The SMF categorizes the volume within PDU session by QoS Flow identified by QoS Flow Identifier (QFI).
The amount of data counted for the QoS Flow shall be the user plane payload at the UPF.
Table 5.2.1.6.1 summarizes the set of default trigger conditions and their category which shall be supported by the SMF in QBC. For "immediate report" category, the table also provides the corresponding Charging Data Request [Initial, Update, Termination] message sent from SMF towards the CHF.
Table 5.2.1.6.1: Default Chargeable events in SMF for QBC
Chargeable event |
Trigger level |
Default category |
CHF allowed to change category |
CHF allowed to enable and disable |
Message when "immediate reporting" category |
---|---|---|---|---|---|
Start of PDU session |
PDU session |
Immediate |
Not Applicable |
Not Applicable |
Charging Data Request [Initial] |
Start of a QoS Flow |
QoS Flow |
Deferred |
Not Applicable |
Not Applicable |
Charging Data Request [Update] |
Change of Charging conditions |
|||||
QoS change |
QoS Flow |
Deferred |
Yes |
Yes |
|
GFBR guaranteed status change |
QoS Flow |
Deferred |
Yes |
Yes |
|
User Location change |
PDU session |
Deferred |
Yes |
Yes |
|
Serving Node change |
PDU session |
Deferred |
Yes |
Yes |
|
Change of UE presence in Presence Reporting Area(s) |
PDU session |
Deferred |
Yes |
Yes |
|
Change of 3GPP PS Data off Status |
PDU session |
Deferred |
Yes |
Yes |
|
Tariff time change |
PDU session |
Deferred |
No |
No |
|
UE time zone change |
PDU session |
Immediate |
Yes |
Yes |
|
PLMN change |
PDU session |
Immediate |
Yes |
Yes |
|
RAT type change |
PDU session |
Immediate |
Yes |
Yes |
|
Session-AMBR change |
PDU session |
Immediate |
Yes |
Yes |
|
Addition of UPF |
PDU session |
Immediate |
Yes |
Yes |
|
Removal of UPF |
PDU session |
Immediate |
Yes |
Yes |
|
Handover cancel |
PDU session |
Immediate |
Yes |
Yes |
|
Handover start |
PDU session |
Immediate |
Yes |
Yes |
|
Handover complete |
PDU session |
Immediate |
Yes |
Yes |
|
Redundant transmission change |
QoS Flow |
Immediate |
Yes |
Yes |
|
Limit per PDU session |
|||||
Expiry of data time limit per PDU session |
PDU session |
Immediate |
No |
Yes |
|
Expiry of data volume limit per PDU session |
PDU session |
Immediate |
No |
Yes |
|
Expiry of data event limit per PDU session |
PDU session |
Immediate |
No |
Yes |
|
Expiry of limit of number of charging condition changes |
PDU session |
Immediate |
No |
Yes |
|
Limit per QoS Flow |
|||||
Expiry of data time limit per QoS Flow |
QoS Flow |
Deferred |
Yes |
Yes |
|
Expiry of data volume limit per QoS Flow |
QoS Flow |
Deferred |
Yes |
Yes |
|
Others |
|||||
End of QoS Flow |
QoS Flow |
Deferred |
Yes |
Yes |
|
Management intervention |
PDU session |
Immediate |
No |
No |
|
End of PDU session |
PDU session |
Immediate |
No |
No |
Charging Data Request [Termination] |
Abort request is received from the CHF |
PDU session |
Immediate |
No |
No |
|
NOTE 1: If GFBR guaranteed status change is enabled, SMF needs to ensure the request for the notification from the access network (i.e. 3GPP RAN) when the GFBR can no longer (or can again) be guaranteed for a QoS Flow during the lifetime of the QoS Flow. NOTE 2: The columns CHF allowed to change category, and CHF allowed enable and disable are only applicable for the PDU session establishment, for other cases they are not applicable. |
The default "Limit" trigger conditions, are trigger thresholds configured in the Charging Characteristics applied to the PDU session for QBC. It shall be possible for the CHF to override these default triggers when providing Charging Data Response [Initial], either to disable the triggers, or to enable triggers new thresholds value.
For QBC the following details of chargeable events and corresponding actions in the SMF are defined in Table 5.2.1.6.2:
Table 5.2.1.6.2: Chargeable events and their related actions in SMF for QBC
Chargeable event |
Conditions |
SMF action |
---|---|---|
Start of PDU session |
Charging Data Request [Initial]. |
|
Start of a QoS Flow |
Start of the QoS Flow associated with the default QoS rule |
Charging Data Request [Update]. |
Start of a QoS Flow |
Start new counts with time stamps. |
|
End of a QoS Flow |
Close the counts with time stamps for the QoS flows |
|
End of PDU session |
Charging Data Request [Termination] Close the counts with time stamps |
|
Change of charging condition in the SMF (e.g. QoS change, Session-AMBR change, user location change, Radio access type change, PLMN change, Serving Node change, UE Time Zone change, change of UE presence in Presence Reporting Area(s), change of 3GPP PS Data Off status, GFBR guaranteed status change) |
If the corresponding trigger is enabled |
Close the counts and start new counts with time stamps for all active QoS flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
Handover start |
If the corresponding trigger is enabled |
Close the counts with time stamps and start new counts with time stamps. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update]. |
|
Handover cancel |
If the corresponding trigger is enabled |
Close the counts with time stamps and start new counts with time stamps for active QoS flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update]. |
|
Handover complete |
If the corresponding trigger is enabled |
Close the counts and start new counts with time stamps for active QoS flows. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
Redundant transmission change |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update]. Close the counts and start new counts with time stamps. |
Addition of UPF |
If the corresponding trigger is enabled |
Start new counts with time stamps for the added UPF. |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update]. |
|
Removal of UPF |
If the corresponding trigger is enabled |
Close the counts with time stamps for the removed UPF |
If the corresponding trigger is enabled and the category is set to "immediate reporting" |
Charging Data Request [Update]. |
|
Expiry of time limit per QoS Flow |
If the corresponding trigger is enabled |
Close the counts with time stamps. |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If the QoS Flow is still active |
Start new counts with time stamps |
|
Expiry of data volume limit per QoS Flow |
If the corresponding trigger is enabled |
Close the counts with time stamps |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If the QoS Flow is still active |
Start new counts with time stamps |
|
Expiry of time limit per PDU session |
If the corresponding trigger is enabled |
Close the counts with time stamps for all QoS flows. |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If the PDU session is still active |
Start new counts with time stamps for all active QoS flows |
|
Expiry of data volume limit per PDU session |
If the corresponding trigger is enabled |
Close the counts with time stamps for all QoS flows. |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If the PDU session is still active |
Start new counts with time stamps for all active QoS flows |
|
Expiry of a limit of number of charging condition changes per PDU session |
If the corresponding trigger is enabled |
Close the counts with time stamps for all QoS flows. |
If the category is set to "immediate reporting" |
Charging Data Request [Update] |
|
If the PDU session is still active |
Start new counts with time stamps for all active QoS flows |
|
Management intervention |
Charging Data Request [Update] Close the counts with time stamps for all QoS Flows |
|
If the PDU session is still active |
Start new counts with time stamps |
|
Abort |
Charging Data Request [Termination] Close the counts with time stamps |
The CDR generation mechanism processed by the CHF upon receiving Charging Data Request [Initial, Update, Termination] issued by the SMF for these chargeable events in QBC, is specified in clause 5.2.3.
5.2.1.7 Roaming QoS flow Based charging (QBC)
When QoS flow Based Charging specified in 5.2.1.6 is used in a context of roaming, a "Roaming Charging Profile" is defined to allow, when shared, QBC synchronized between both PLMNs and includes:
– The set of chargeable events as per Table 5.2.1.6.1 and associated category.
– The set of thresholds for chargeable events based on trigger thresholds.
– An indication on whether the "Default partial record" or the "Individual partial record" mechanism per clause 5.2.3, is used by CHF.
A default "Roaming Charging Profile" is specified for the SMF and comprises:
– The set of chargeable events and associated category specified as the default per Table 5.2.1.6.1.
– The default set of thresholds configured in the Charging Characteristics for QBC.
– The "Default partial record" mechanism indicated as the one used by CHF.
In the VPLMN, at PDU session establishment or PDU session transfer from a different VPLMN, the default "Roaming Charging Profile" in the new V-SMF may optionally be overridden by a new "Roaming Charging Profile" supplied by the CHF in the Charging Data Response [Initial] with:
– updated set of chargeable events and associated category.
– updated thresholds for chargeable events based on trigger thresholds.
– the selected partial record mechanism ("Default partial record" or "Individual partial record").
This updated "Roaming Charging Profile" is transferred from the new V-SMF to the H-SMF and may be acknowledged or replaced by the HPLMN selected "Roaming Charging Profile" to be used by the new V-SMF.
In the HPLMN, at PDU session establishment or V-SMF change for a PDU session, the "Roaming Charging Profile", when received by the H-SMF from the new V-SMF, may be updated by the CHF in the HPLMN in the Charging Data Response [Initial] to H-SMF. This HPLMN CHF selected "Roaming Charging Profile" is used by the H-SMF and transferred towards the VPLMN.
The "Roaming Charging Profile" resulting from the exchange between the VPLMN and HPLMN at PDU session establishment shall remain unchanged during the PDU session lifetime, unless there is a V-SMF change.
At each V-SMF change in Home routed scenario, the "Roaming Charging Profile" may be renegotiated between the VPLMN and HPLMN and shall remain unchanged during the PDU session lifetime with the actual V-SMF.
The capability specified in clause 5.2.1.2.1 for the CHF to be able to update the triggers after the PDU session is established for a given VPLMN shall not be applicable for Roaming QBC.
5.2.1.8 Termination action
The termination action applies only in case of online charging, i.e. quota management is active. It indicates the action, which the UPF should perform when no quota is granted. A packet for a specific rating group is subject to a termination action in the following cases:
– Zero units have been granted;
– The final granted units have been used;
– Quota limit reached;
– End user service rejected;
– End user service denied;
– Rating failed.
The defined termination actions include:
– Allowing the packets to pass through;
– Dropping the packets;
– The SMF Default Termination Action;
– The re-direction of packets to an application server (e.g. defined in the termination action).
NOTE Such a re-direction may trigger a new charging session to be initiated.
A Default Termination Action for all rating groups, for which no quota is granted and there is no specific termination action, shall be pre-configured in the SMF according to operator’s policy. For instance, the default behaviour may consist of allowing packets of any terminated service to pass through the UPF.
When final units are granted for a given rating group, the CHF shall provide a termination action using finalUnitAction for this rating group. For the rating group, the CHF provided termination action shall be used instead of SMF pre-configured termination action for “The final granted units have been used” case.
5.2.1.9 Sponsored data connectivity charging
The Sponsor Identifier and Application Service Provider Identifier are provided for sponsored data connectivity to the PCF from the AF, according to TS 23.503 [215].
The Sponsor Identifier and Application Service Provider Identity may be included in PCC rules with "offline" charging method for non-roaming or home routed roaming scenarios from the PCF to the SMF. In this case, charging information collected by the SMF includes the Sponsor Identity and the Application Service Provider Identity. Correlation of charging information from multiple users per sponsor and/or application service provider can then be based on Sponsor Identity and Application Service Provider Identity.
5.2.1.10 Branching point or UL CL controlled by I-SMF
The interaction between I-SMF and SMF for the support of traffic offload by UPF controlled by the I-SMF is specified in the clause 5.34.6 TS 23.501[200].
There are two cases related to quota management when the granted quota is volume for multiple UPFs and per Operator’s policy for the scenarios, i.e.Addition, Removal and Change of PDU Session Anchor (PSA2), Branching Point or UL CL controlled by I-SMF, the traffic is counted in more than one UPF:
– Quota shared by UPFs (PSA)
– Quota granted for each UPF (PSA)
In the scenario UL CL/BP controlled by I-SMF, the I-SMF forwards traffic usage information of UPF (PSA2) to the SMF as specified clause 5.34.4 and clause 5.34.5 in TS 23.501 [200].
5.2.1.11 CHF-Controlled Quota Management
Quota management process is initiated by NF consumer, e.g. SMF, for service data flows handled with the online charging method for a given Rating Group. For the provision of the service to the end user, NF consumer requests quota from CHF via Charging Data Request messages [Initial / Update]. CHF-Controlled Quota Management in this context allows CHF to suspend/resume the quota management process for that Rating Group within a PDU session.
When an NF consumer issues a Charging Data Request [Initial / Update] CHF may decide to authorize the service and suspend the quota management for that Rating Group. This means that: the service is authorized without granted units and that all quota management triggers for that Rating Group within a PDU session are ignored by the NF consumer.
Usage will continue to be reported via the remaining default active triggers. It is the sole responsibility of CHF to activate other applicable triggers if additional reporting is needed.
When an NF consumer issues a Charging Data Request [Update] in which a given Rating Group has quota management previously suspended, CHF may decide to resume quota management for that Rating Group. This means that all previously set quota management triggers for that Rating Group are considered by the NF consumer and granted units are reconfigured by the CHF.
CHF may want to resume quota management at any time, for this Re-authorization mechanisms can be used to trigger NF consumer to subsequently issue a Charging Data Request [Update].Procedures enabling CHF-Controlled Quota Management to suspend/resume the quota management are described in TS 32.290 [57].
5.2.1.12 URLLC Charging
The CHF can be aware of redundant transmission type (i.e.dual connectivity, redundant transmission on N3/N9 and redundant transmission at transport layer) and provide the quota allocation based on the redundant transmission type:
– For dual connectivity based end to end redundant user plane paths, the granted quotas is allocated for each PDU session.
– For the redundant transmission on N3/N9 interfaces, the CHF grants the quota regardless if packets were duplicated or not.
– For the redundant transmission at transport layer, the CHF grants the quota regardless if packets were duplicated or not.
For dual connectivity based end to end Redundant User Plane Paths, SMF shall collect and report the usage for each redundant PDU session.
For redundant transmission at N3/N9 interface, the SMF shall collect and report the usage not counting redundant packets.
During the PDU session life, the SMF may decide to active or deactive the redundant transmission and reports the usage based on the redundant transmission change trigger.
For redundant Transmission at transport layer, the SMF shall collect and report the usage not counting redundant packets.
5.2.1.13 NR REDCAP Charging
The SMF provides for NR RedCap UE using NR the RAT Type NR_REDCAP, according to clause 5.41 of TS 23.501 [200].
5.2.1.14 Additional actor (MVNO) Charging
5.2.1.14.1 General
The SMF provides charging information collection and reporting per PDU session for 5G non-roaming Mobile Virtual Network Operators (MVNOs) charging, according to clause 5.5.3.10 of TS 32.240 [1].
The charging principle for local breakout roaming scenario is applied to MVNOs (with an A-CHF) charging, with the following differences on the SMF interactions with the CHF in the MNO and A-CHF in the MVNO:
– V-SMF in V-PLMN is replaced by the SMF in MNO;
– V-CHF in V-PLMN is replaced by the CHF in MNO;
– H-CHF in H-PLMN is replaced by the A-CHF in MVNO.
NOTE: CHF selection as well as trigger handling and negotiation, are not specified and may be deployment dependent.