SMF Charging

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

SMF

Applicable Platform(s)

SMI

Feature Default Setting

Disabled – Configuration Required

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History
Revision Details Release
First introduced. Pre-2020.02.0

Overview

The SMF acts as a Charging Transfer Function (CTF). The CTF generates charging events toward the Charging Function (CHF), which is responsible for generating Charging Data Records (CDRs).

This SMF NF interacts with various interfaces such as N40, N4, N7, and N10, facilitating charging in entirety. Currently, the Cisco SMF uses the Nchf/N40 interface to generate charging events.

Figure 1. SMF as a Charging Transfer Function

The SMF Charging feature supports the following functionality:

  • Converged Online and Offline charging.

  • PDU session charging using the service-based interface.

  • Network slice instance charging.

  • Charging information collection per PDU session for UEs served under 3GPP access.

  • Each PDU session is assigned a unique identity number for billing purposes.

  • Data volumes on both the uplink and downlink directions are counted separately. The data volumes reflect the data as delivered to and forwarded from the user.

  • The charging mechanism provides the date and time information when the PDU session starts.

  • The SMF handles Charging Characteristics specific to a subscription or a subscribed DNN.

  • The SMF identifies data volumes, elapsed time, or events for individual service data flows (flow-based charging). One PCC rule identifies one service data flow.

  • SMF allows usage reporting of a service or a detected application per rating group or per combination of the rating group and service ID. This reporting level can be activated per PCC rule.

  • Quota management is done per Rating Group (RG) per PDU session.

  • SMF supports charging for IP-based PDU session types.

Converged Charging

The 5G system supports converged charging for offline and online charging scenarios.

The SMF performs converged charging for each of the following:

  • Charging data that is related to PDU session.

  • Charging data that are related to service-data flows within a PDU session.

The scope of convergent charging in this implementation includes quota management and usage reporting. For convergent charging, the SMF interacts with the CHF for charging data related to PDU sessions. The Charging Data Request and the Charging Data Response messages are exchanged between the SMF and the CHF based on session-based charging (SCUR scenarios). The Charging Data Request is issued by the SMF only when conditions that are related to chargeable events are met.

Chargeable Events

PCC rules can be activated, deactivated, and modified at any time during the PDU session lifetime.

The following attributes can be modified by the PCF in a dynamic PCC rule active in the SMF:

  • Charging Key

  • Service Identifier

  • Measurement Method

Activities on PCC rules and QoS flows are not chargeable events. However, change of charging rule in PCC rules lead to chargeable events such as:

  • Start of service data flow

  • Termination of service data flow, for the last service data flow for the original PCC rule

The charging key (that is, rating group) is used to request online charging quota.

Charging Identifier

The charging identifier corelates charging information between the SMF and CHF during the duration of a PDU session. The SMF generates and assigns a charging identifier when a PDU session is established. The charging identifier is unique for that PDU session and is used in all messages that are exchanged in that PDU session.

Charging Information

The SMF collects the following charging information for converged online and offline charging:

  • Usage of access and core network resources: Describes the amount of data that is delivered to and forwarded from the UE.

  • Usage duration: Time interval from PDU Session Establishment to PDU Session Release.

  • User: UE information used by the user for a PDU session.

  • Data network: Data network address as determined by the DNN.

  • Start time: PDU session start time.

  • User location: HPLMN and VPLMN reporting area.

For service-data flows (flow-based charging), the SMF collects the following information:

  • PDU session description.

  • Data that are transmitted in uplink and downlink directions based on the rating-group information, or a combination of rating-group and service ID during volume-based charging.

  • Duration of service data flow based on the rating group, or a combination of rating-group and service ID during event-based charging.

  • Events and timestamps based on rating-group or based on a combination of the rating-group and service ID during event-based charging.

The SMF collects charging information for service data flows per UPF, within a PDU session, based on the rating-group or based on a combination of rating-group and service ID.

How it Works

Charging Session

The SMF supports converged session-based charging (SCUR) as specified in 3GPP TS 32.290, Section 5.3.2.3.

The SMF establishes charging session with the CHF with the Charging Data Request and Response (Initial) exchange. During the life of the PDU session, usage is reported with Charging Data Request/Response (Update) exchange. After the session is released, Charging Data Request/Response (Termination) messages are exchanged.

Offline Charging and Online Charging

Charging is enabled for a session based on the input that is received from the PCF.

For offline charging, the SMF sends Charging Data Request Initial toward the Charging Function (CHF) based on the presence of charging descriptors and refChgData field set in the smPolicyDecision message from the PCF in SmPolicyControlCreate response.

On determining if charging is required during initial session establishment or post-session establishment, charging is enabled for the PDU session. Once charging is enabled, SMF sends the Charging Data Request (Initial) Message toward the CHF.

The SMF determines Volume/Time threshold value either locally or from Charging Data Response. These values are used to update Volume/Time threshold IE in URR and to set the reporting trigger accordingly. The measurement method that is used in URR is derived from charging data.

For online charging, the SMF receives the Volume/Time Threshold and Quota values from the CHF. These values are received in the Charging Data Response (Initial) or using a Charging Data Request (Update) during a PDU Session Establishment. The SMF relays these Volume/Time Threshold and quota values to the UPF in the corresponding URR.

NOTE: The threshold values from CHF always override the locally configured values.

The following table maps the IEs that are shared with the UPF during Create/Update URR during online/offline charging scenarios:

IE Online Offline Derived From
Volume Limit Yes Yes CHF Response/Local Configuration
Time Limit Yes Yes CHF Response/Local Configuration
Volume Quota Yes No CHF Response
Time Quota Yes No CHF Response
Quota Holding Time Yes — CHF Response
Monitoring Time Yes Yes

  • Local configuration for offline charging

  • CHF response for online charging
Reporting Trigger Yes Yes The respective triggers that are set as shown in the following table.
Reporting Trigger Derived From
Volume Threshold Trigger If Volume threshold is set
Time Threshold Trigger If Time threshold is set
Volume Quota Trigger If Quota Exhausted trigger is set from CHF
Time Quota Trigger If Quota Exhausted trigger is set from CHF
LIUSA Trigger If URR contains Linked URR
Quota Management

The SMF requests quota from the CHF upon meeting any of the following conditions:

  • The Rating Group (RG) is installed for the first time and the charging method is Online for the dynamic rule.

  • The start of traffic trigger is initiated from the UPF for the RG in the case of static or predefined rules.

  • A specific trigger type, as defined in the 3GPP specification 32.255, is received in the usage report for the online charging service from the UPF.

The SMF uses the quota request always CLI command to request the quota always. This CLI command is available in the Charging Profile configuration mode. Upon configuring this CLI command, the SMF always requests for quota when reporting the usage to the CHF for the online services. The quota requesting ends when the charging service stops.

Irrespective of the quota request [ always | standard ] CLI configuration, the quota request is disabled for the trigger type "qht" configured through the quota suppress triggers CLI command.

For command details, see the Charging Profile Configuration section in the SMF Charging chapter of this guide.

Service Units for Quota Management

The SMF sends Charging Data Request (CDR) to the Charging Function (CHF) for the service to be granted authorization to start, and to reserve the number of units. While triggering the CDR, the SMF requests volume (uplink, downlink, total) and time quota from CHF to support VoLTE and other use cases. The values of the requested units for static rules are obtained from the Diameter configuration under Active Charging Service. For the dynamic audio or video rules, the values for the requested service units are configured through the requested-service-unit CLI command in the Charging Profile Configuration mode. For command details, see the Charging Profile Configuration section in the SMF Charging chapter of this guide.

Support for Validity Time

The SMF uses time quota value and its corresponding trigger on N4 interface to arm the UPF about the time when the SMF needs the reporting of validity time.

The CHF arms the SMF to report the usage for the rating group when the timer associated with the validity_time expires.

Based on the presence of Validity Quota and Time Quota, the SMF behaves as specified in the following ways:

  • When the CHF sends only the Time Quota and not the Validity Quota, the SMF relays the CDR-U to the CHF and reports as Quota_EXHAUSTED upon receiving the usage report from the UPF.

  • When the CHF sends only the Validity Quota and not the Time Quota, the SMF relays the CDR-U to the CHF and reports as VALIDITY_TIME upon receiving the usage report from the UPF.

  • When the CHF sends both the Validity Quota and the Time Quota, the SMF determines the lower value of time_quota and validity_time, and then relays the CDR-U to the CHF accordingly. The SMF sends the "VALIDITY_TIME" trigger when the validity_time is lesser than the time_quota value. Similarly, when the validity_time is greater than the time_quota value, the SMF sends the "Quota_EXHAUSTED" trigger.

CHF Selection

The CHF selection, that is, CHF address determination by the SMF is performed during PDU Session Establishment. This selection is based on the following in order of priority:

  1. PCF provides one or more CHF addresses as part of the PCC rule.

  2. UDM-provided charging characteristics.

  3. NRF-based discovery.

  4. SMF locally provisioned charging characteristics.

NOTE: The local configuration is currently used to get CHF IP/port.

Charging Activities at SMF

URR Generation Toward N4

The SMF receives charging-data and usage-monitoring-data from the PCF. Based on this information, the SMF derives URR toward N4. In case the SMF is configured with volume/time limit at the session level, the SMF creates session-level URR.

Handling of Initial Event in Charging Component

The session context of SMF is configured with trigger/threshold as per the default described in 3GPP TS 32.255. It overrides the same based on configuration present in the charging profile. The same values can be further overridden by CHF Charging Data Response Initial. Currently, trigger/threshold cannot be overridden when in PDU Establishment state.

The charging profile is referenced from the charging-characteristic profile. The CC profile is taken from UDM subscription for PDU session. If the CC profile is not mentioned in the UDM response, it is taken from the DNN profile.

After trigger/threshold/quota are determined, the SMF N4 Setup Request with set of Create URRs are derived from charging-data with one session-level URR.

If the session-level reporting is determined, the session-level URR is associated to each SDF URR.

The following triggers are supported:

  • Volume/Time trigger at session/RG level

  • AMBR change

  • QoS change

  • Quota threshold and quota exhausted

  • Quota handling time

  • Tariff time change

Obtaining Threshold Values at SMF

Threshold values, during online charging, are always obtained from the CHF. Whereas the threshold values, during offline charging, are obtained either from the CHF or from the charging profile configuration.

If charging profile is not determined during PDU establishment, the SMF refers to the charging profile from the DNN profile. Once the Charging Profile is determined, the SMF uses the determined Charging Profile to obtain the threshold values for Session/SDF URR.

The configuration has threshold values at a session level or rating-group level. The rating-group level threshold values are generic and not about a rating-group. These threshold values are overwritten by CHF response.

NOTE: The CHF response has various triggers. If some trigger is present at the session level or rating-group level, and if the volume or time threshold value is not available, then these values are assumed to be disabled at the corresponding level.

Trigger Determination at SMF

The SMF has triggers enabled by default, as specified in 3GPP TS 32.255, Section 5.2.1.4.

These triggers can be overwritten at a session level by trigger configurations present in the charging profile. Further, these triggers can also be overwritten by CHF responses.

Trigger configuration in charging profile is only applicable at a session level. It is not applicable for rating-groups.

NOTE: The CHF response has various triggers. If some triggers are present at a session or rating-group level and other triggers are not present, then these triggers are assumed to be disabled.

Reporting Category

The charging trigger can be of two reporting categories – Immediate and Deferred. The usage report of the immediate category must be reported to the CHF immediately. For reporting events that must be deferred, the SMF will store the usage report locally, and will publish either when the next trigger of the immediate category is invoked, or when the storage limit is exhausted.

When reporting stored usage reports to the CHF, the usage report is triggered because of the trigger type in UsedUnitCategory and the message is triggered because of the trigger type in ChargingDataRequest.

Sometimes, a scenario can have two triggers hit at the same time. AMBR_Change and QoS Change can happen at the same time. In which case, all the triggers as applicable at the RG level or session level will have multiple trigger values.

A trigger can be enabled at the RG level, and for some RG it can be immediate reporting and for others it can be deferred reporting. When a trigger event is hit, various usage reports will have a corresponding category filled respectively in usedUnitContainer.

Deferred CDR will be relayed in the following scenarios:

  • An immediate category event happens.

  • Maximum number of charging conditions are crossed.

  • Configured number of maximum deferred reporting is crossed.

Maximum Charging Characteristics (CC) is reset whenever there are push CDRs. This could be because of maximum CC limits being crossed or because of immediate category reporting.

NOTE: Currently, SMF does not support two charging descriptors with the same rating group.

Handling Reporting Level

The reporting category is classified into the following:

  • Rating Group (RG) level: The RG is mandatory at this level.

  • Service ID level: The RG and service ID is mandatory at this level.

  • Sponsor ID level: The RG and Sponsor ID is mandatory at this level.

The reporting level is conveyed to the SMF from PCF in the Charging Data Request. If the reporting-level is RG, RG is the primary key. If the reporting level is Service_level or SponserLevl, the primary key becomes RG and Service ID or RG or Sponsor ID respectively. The SMF drops the charging descriptors from the PCF if the above requirement is not satisfied.

Re-Authorization

The CHF triggers Reauthorization of charging descriptors using Charging Notify request. Reauthorization is implemented at the session-level or at a RG-level for both online and offline charging.

The SMF processes the reauthorization details (which contain an array of RG, ServiceId, QuotaMgmtIndicator) received in CHF Notify and retrieves the charging descriptors associated with the current PDU session. Any unmatched reauthorization item is skipped.

For the charging descriptors identified for reauthorization, the SMF queries for usage reports from UPF and sends it to the CHF.

As part of the CHF response, the SMF detects any change in quota/threshold information and performs N4 Session Modification to update URRs.

Final Unit Indication Support

The SMF supports Final Unit Indication (FUI) in the Charging Data Initial/Update Response from CHF as per 3GPP TS 32.291, Section 6.1.6.2.1.12.

On receiving FUA, the SMF installs new FAR and associates it's FAR-ID in the URR, in the FAR ID Quota Action IE. If a FAR with same parameters exists, the SMF uses it's FAR-ID in the Create/Update URR. The UPF initiates appropriate actions set in FAR after quota exhaustion.

Currently, the SMF only supports Terminate and Redirect FU actions.

NOTES:

  • At any instance, CHF provides granted unit (Quota) to the SMF along with FUI.

  • When SMF receives the granted unit with FUI, the SMF creates FAR toward N4 and associates it to the corresponding URR which carries the Quota information.

  • UPF on receiving FAR associated with the URR, the corresponding FAR action is implemented when the quota exhausts.

Static and Predefined Rules for Charging

Configuration of static/predefined rules is similar to the procedures on SMF and UPF. The layout of configured is as follows:

  1. Rulebase: A one-to-many rule base is configurable. For a single PDU session, a single rule base can be activated at a given time. The rule base can be activated at SMF by the PCF by sending the rule base name in the PCC rule.

  2. Ruledef: Each rule base can have one-to-many ruledef configurations. A ruledef can either be of static or predefined type. Each ruledef is assigned to a charging action.

  3. Charging Action: Contains QoS and charging information.

The SMF derives charging data for each charging action in the rule base. Charging action associated to static rules in the rule base is immediately derived and updated in the PDU context. Charging action associated to predefined rules is derived and updated when the said predefined rule is activated at SMF from PCF.

The charging action derived URR has the following behavior:

  • Online charging is identified by the "cca charging credit " configuration under charging action.

  • Offline charging is identified by the "billing action egcdr " configuration under charging action.

  • Armed triggers for volume-limit and time-limit are under the gtpp group configuration, under APN. The UPF automatically detects these values and sends the respective usage reports.

  • The SMF, unlike the dynamic case, does not send the Create URR immediately for charging data that is derived from configured rules.

  • Only when charging action is configured with "cca charging credit preemptively-request ", the SMF sends the Create URR message. In all other cases, the SMF does not send the Create URR.

    NOTE: This CLI is not qualified in the current release.

  • For URR derived from configured rules, the SMF generates URR-ID from "urr-list ". This configuration has one URR-ID for each set of RG and service ID.

    Therefore, when the UPF sends the usage report for a URR ID, the SMF does not identify the corresponding URR, RG/service ID to be used for reporting toward the CHF.

  • Using the online charging method, the UPF sends usage report with trigger "Start". The SMF uses CHF to derive the quota for the RG and relays the same information to the UPF in the Update URR message.

  • The UPF threshold can be configured at a rule base level. It creates a rulebase-level URR that is linked to all ruledef-level URR within the rule base.

Modification Scenarios in Charging

PCF Update

The PCF performs the following actions during a modification scenario:

  • Addition of PCC rules

  • Modification of reference data

  • Deletion of PCC rules

  • Content update in charging data - using Measurement method

CHF Response

The CHF response, during an exchange, sends updated volume and time thresholds and quota. The SMF relays the updated URR toward N4.

A change in threshold/trigger/quota triggers an Update URR, which leads to the N4 relay.

The Update URR is sent based on the following triggers:

  • Volume/time threshold

  • Volume/time quota

  • Tariff time change

  • Quota holding time, and so on

URR Linking

  • If session-level volume/time value is configured locally or is received from the CHF, the SMF creates session-level URR and links it to all URR corresponding to offline charging descriptors.

  • If multiple charging descriptors received by PCF are of the same rating group, the SMF creates extra URR and links it to all URR derived from charging descriptors of the same rating group.

URR Format

The URR ID format is as given below:

  • URR ID is 32 bit.

  • MSB (32nd) bit for static/predefined URRs is set to 1, and for dynamic URRs is set to 0.

  • First four LSB bits are set for interface type.

    • 1 for offline

    • 7 for online

  • Bit 4-31 is for URR ID number.

    For example: Dynamic first URR if ID is 1:

    0x00 00 01 01 Offline

    0x00 00 01 07 Online

    Static/Predefined first URR if ID is 1:

    0x80 00 01 01 Offline

    0x80 00 01 07 Online

Local Configuration

The following figure illustrates how local configuration works.

NOTES:

  1. The SMF supports up to 16 charging characteristic profiles.

  2. Each CC profile comprises of charging group and charging profile.

  3. The charging server group and charging profile are linked to the DNN profile. Currently, the charging profile supports configuration for trigger and thresholds.

Call Flows

This section presents the following call flows:

PDU Session Establishment

The following figure illustrates the call flow of PDU session establishment.

Step Description
1. Call Setup
2.

SMF performs a Policy Create exchange with PCF. In this exchange, the SMF might receive Charging Data that is associated to a PCC Rule. This indicates that charging is enabled for the session in progress.

It is possible that PCF has enabled Static/Predefined rules. These rules can be also enabled with charging, based on the configuration.
3.

Once charging is detected at SMF, it initiates a Charging Data Request Initial exchange with CHF. In this exchange SMF may receive the following from CHF:

  • CC triggers at session or RG level

  • Session level Time or Volume limits

  • Time or Volume limits at RG level

  • Quota at RG level
4. N1N2 Exchange and SM Context Update Exchange
5. SMF initiates N4 session establishment request exchange with UPF, and in the same request it relays information that is related to charging in the Create URRs.

Standards Compliance

The SMF Charging feature complies with the following standards:

  • 3GPP TS 32.255

  • 3GPP TS 32.290

3GPP June 2019 Compliance for Charging Interface

The SMF is compliant with the 3GPP June 2019 specification TS 32.290 version 15.3.0.

For the June release the messages goes over the version "v2" as indicated below in URI format.


nchf-convergedcharging/v2/chargingdata

The CLI command for compliance configuration is: service nchf-convergedcharging . If this CLI command or version is not configured, the default version from 3GPP December 2018 is applied.

With the 3GPP June 2019 compliance, the following new information elements (IE) are added:

  • Authorized QoS

  • Subscribed QoS

  • IEs in QoSData

  • Serving Network Function ID

Configuring SMF Charging

SMF Charging involves the following configurations:

  • DNN Profile Configuration

  • Charging Characteristics Profile Configuration

  • Charging Profile Configuration

DNN Profile Configuration

Use the following configuration to configure a DNN profile for SMF Charging.

configure 
   profile dnn profile_name 
      charging-profile profile_name 
      network-element-profiles { amf | chf | pcf | udm } profile_name 
      end

NOTES:

  • charging-profile : Specifies the Charging Profile configuration.

  • network-element-profiles : Specifies the network element profile. Network element profile can be one of the following:

    • amf : Specifies the AMF network element profile.

    • chf : Specifies the CHF network element profile.

    • pcf : Specifies the PCF network element profile.

    • udm : Specifies the UDM network element profile.

  • profile_name must be a string.

Charging Characteristics Profile Configuration

Use the following configuration to configure charging characteristics profile for SMF Charging.

configure 
   profile charging-characteristics cc_value 
      charging-profile profile_name 
      end

NOTES:

  • cc_value : Specifies the charging characteristics value which is an integer from 1 to 16.

Charging Profile Configuration

Use the following configuration to configure the charging profile parameters for SMF charging.

configure 
   profile charging profile_name  
      limit [ rating-group ] { duration duration_value | volume volume_value } 
      max-charging-condition max_cc_value  
      max-deferred-urr max_urr_value  
      method { none | offline | online } 
      quota request [ always | standard ] 
      quota suppress triggers [ qht ] 
      reporting-level { offline | online { [rating-group] | rating-group | service-id } 
      requested-service-unit time seconds volume downlink downlink_value uplink uplink_value total total_value 
      tight-interworking-mode { false | true } 
      triggers session session_level_triggers 
      end

NOTES:

  • limit : Specifies the threshold limit.

  • duration : Specifies the duration threshold for charging. The threshold value ranges from 0 through 2147483647.

  • volume : Specifies the volume threshold for charging. The threshold value ranges from 0 through 9223372036854775807.

  • rating-group : Specifies the volume and duration threshold for a Rating Group.

  • max-charging-condition max_cc_value : Specifies the maximum number of changes to the charging condition. max_cc_value must be an integer ranging from 0 through 500. The default value is 20.

  • max-deferred-urr max_urr_value : Specifies the maximum number of deferred USU containers. max_urr_value must be an integer ranging from 0 through 200. The default value is 50.

  • method : Specifies the charging method. The default charging method is offline.

  • quota request [ always | standard ] : Controls the requesting of quota from the CHF for online charging services based on the configuration. If the quota request always is configured, the SMF always requests for quota. If the no quota request or quota request standard CLI command is configured, then the SMF requests the quota for specific trigger types as defined in standard, which is the default behaviour.

  • quota suppress triggers [ qht ] : Suppresses the quota from the CHF upon configuring the usage report trigger type "qht".

  • reporting-level : Specifies the reporting level configuration to be used for offline and online charging.

    The default value is [rating-group] level.

  • requested-service-unit: Configures the value for the requested service units.

    • time seconds : Configures the time quota value in seconds from 1 through 4000000000.

    • downlink downlink_value : Configures the downlink volume in bytes from 1 through 4000000000.

    • uplink uplink_value : Configures the uplink volume in bytes from 1 through 4000000000.

    • total total_value : Configures the total volume in bytes from 1 through 4000000000.

  • tight-interworking-mode : Configuration to enable tight interworking mode for online/offline charging methods.

  • triggers : List of triggers to be configured.

  • session session_level_triggers : Specifies the list for Session Level Triggers. The list of Session Level Triggers is as follows:

    • repor3gpp-ps-change

    • ambr-change

    • max-number-of-changes-in-charging-conditions

    • plmn-change

    • qos-change

    • rat-change

    • serv-node-change

    • tarrif-time-change

    • ue-pra-change

    • ue-time-change

    • upf-add

    • upf-rem

    • user-loc-change

The following is a sample configuration for SMF Charging:

configure 
   charging-server ch1 
      fqdn abc.com 
      capacity 10 (default : 10) 
      priority 1 (default: 1) 
      ip-address 127.0.0.1 
      port 1234 
      ! 
      ! 
   dnn-profile dnn1 
      charging-server-name [ chserv1 ] 
      charging-profile chProf1 
      ! 
   profile charging ch1 
      limit volume tot 2000 
      limit duration 20 
      limit rating-group volume tot 4000 
      limit rating-group duration 40 
      triggers session [ ambr-change qos-change] 
   max-charging-condition 20 
      max-deferred-urr 100 
      reporting-level service-id 
      requested-service-unit time 20 volume downlink 8000 uplink 2000 total 10000 
      ! 
   profile charging-characteristics 1 
   charging-profile ch1 
   !

Static PCC Rules Configuration

For information on Configuring Static PCC Rules for Charging, refer to Configuring the Static PCC Rules Support on SMF section in the Policy and User Plane Management chapter.

The following is an example Static PCC Rule configuration:


configure 
active-charging service acs 
   credit-control group 1 
      diameter ignore-service-id true 
      pending-traffic-treatment forced-reauth drop 
      pending-traffic-treatment noquota pass 
      quota holding-time 10 
      usage-reporting quotas-to-report based-on-grant report-only-granted-volume 
      exit 
   urr-list urrlocal 
      rating-group 320011 service-identifier 10 urr-id 1 
   charging-action ca95 
      billing-action egcdr 
      cca charging credit 
      content-id         320011 
      service-identifier 10 
   exit 
   charging-action test 
     cca charging credit preemptively-request //This is not in scope of current release 
   exit 
   rulebase rb1 
      action priority 10 ruledef rd95 charging-action ca95 
      action priority 11 dynamic-only ruledef rd93 charging-action ca93 
   exit 
 
gtpp group group1 
   gtpp egcdr service-data-flow threshold interval 1234 
      gtpp egcdr service-data-flow threshold volume downlink 13000 
      gtpp egcdr service-data-flow threshold volume uplink 17000 
      gtpp egcdr service-data-flow threshold volume total 22222 
   exit

Mapping of Charging Scenario on Various Interfaces

Feature Description

SMF supports charging on the N7, N40, and N4 interfaces. Based on the charging data information that SMF receives, it provides reporting level support for online and offline charging. The behavior of SMF changes according to the messages received on the N7, N4, and N40 interfaces.

How it Works

SMF provides the different reporting levels for online and offline charging with the following rules:

  • Configured rules are derived from the static or predefined charging actions.

  • Session-level Usage Reporting Rule (URR) is derived from CHF trigger or local configuration.

  • SMF does not associate session-level URR for online and offline method charging description.

  • SMF does not associate session-level URR to the configured charging-action URRs.

  • Rulebase URR is applicable only for the offline configured URR.

  • For the configured online or online-offline charging method, if Ignore Service ID configuration exists, the URR list must contain "rg x urr-id y". Else, the SMF drops the charging actions as malformed.


Important

SMF supports multiple charging methods within the same rating group.

Charging Mapping

The N7 interface uses Charging Data from PCC rules or local configuration, N4 interface uses URR or Packet Detection Rule (PDR), and N40 interface uses Used Unit Container (UUC).

SMF charging mapping on N7, N4, and N40 interfaces with various charging methods is described as follows.

Offline Method When Charging Data is Derived from One PCC Rule

  • Reporting level: Rating Group level or Service ID level

  • N4 interface:

    • First URR is derived from the first Charging Data. Charging data limits from rating group trigger or local configuration.

    • Second URR is derived from Session Limit, which is CHF or local configuration.

    • Second URR is linked to the first URR.

    • First PDR is derived from the first PCC rule.

    • First and second URRs are linked to the first PDR.

  • N40 interface:

    • First UUC is derived from the usage report of the first URR.

    • First UUC may or may not have a service identifier.

NOTES:

  • Session-level URR is not associated to the configured URRs.

  • If configured, rulebase URR replaces session-level URR.

  • If configured and rulebase URR exists, it is linked to the first URR.

Online Method When Charging Data is Derived from One PCC Rule

  • Reporting level: Service ID level or Rating Group level

  • N4 interface:

    • First URR is derived from the first Charging Data, which is threshold or quota from rating group granted-unit.

    • Second URR is derived from Session Limit, which is CHF or local configuration.

    • Second URR is linked to the first URR.

    • First PDR is derived from the first PCC rule.

    • First and second URRs are linked to the first PDR.

  • N40 interface:

    • First UUC is derived from usage report of the first URR.

    • First UUC may or may not have a service identifier.

NOTES:

  • Session-level URR is not associated to the configured URRs.

Offline Method When Charging Data is Derived from Two PCC Rules

  • Reporting level: Service ID level

  • N4 interface:

    • First URR is derived from the first Charging Data. Charging data has no limit and the rating trigger must be LIUSA.

    • Second URR is derived from the second Charging Data. Charging data has no limit and the rating trigger must be LIUSA.

    • Third URR is derived from rating group level, which limits from Rating-Group trigger or local configuration.

    • Fourth URR is derived from Session Limit, which is CHF or local configuration.

    • The third and fourth URRs are linked to the first and second URRs.

    • First PDR is derived from first PCC rule.

    • Second PDR is derived from second PCC rule.

    • First, third, and fourth URRs are linked to the first PDR.

    • Second, third, and fourth URRs are linked to the second PDR.

  • N40 interface:

    • First UUC is derived from the usage report of the first URR.

    • Second UUC is derived from the usage report of the second URR.

    • Both the first and the second UUCs have a service identifier.

NOTES:

  • Session-level URR is not associated to the configured URRs.

  • If configured, rulebase URR is linked to the first and second URRs.

Online Method When Charging Data is Derived from Two PCC Rules

  • Reporting level: Service ID level

  • N4 interface:

    • First URR is derived from the first Charging Data. Charging data has no limit and the rating trigger must be LIUSA.

    • Second URR is derived from the second Charging Data. Charging data has no limit and the rating trigger must be LIUSA.

    • Third URR is derived from rating group level, which is threshold or quota from the rating group granted unit.

    • Fourth URR is derived from Session Limit, which is CHF or local configuration.

    • Third and fourth URRs are linked to the second and fourth URRs.

    • First PDR is derived from the first PCC rule.

    • Second PDR is derived from the second PCC rule.

    • First, third, and fourth URRs are linked to the first PDR.

    • Second, third, and fourth URRs are linked to the second PDR.

  • N40 interface:

    • First UUC is derived from usage report of the first URR.

    • Second UUC is derived from the usage report of the second URR.

    • Both the first and the second UUCs have a service identifier.

NOTES:

  • Session-level URR is not associated to the configured URRs.

  • If Ignore Service ID is configured, this method is not valid.

Offline-Online Method When Charging Data is Derived from One PCC Rule

  • Reporting level: Service ID level or Rating Group level

  • N4 interface:

    • Offline URR is derived from the first Charging Data, which limits rating group trigger or local configuration.

    • Online URR is derived from the first Charging Data, which limits from the granted unit.

    • First PDR is derived from the first PCC rule.

    • Offline and online URRs are linked to the first PDR.

  • N40 interface:

    • First UUC is derived from the usage report of the offline URR.

    • Second UUC is derived from the usage report of the online URR.

Offline-Online Method When Charging Data is Derived from Two PCC Rules

  • Reporting level: Service ID level

  • N4 interface:

    • First offline URR is derived from the first Charging Data. Charging data has no limit and the rating trigger must be LIUSA. Charging data has the linked URR ID as URR_Off3.

    • Second offline URR is derived from the second Charging Data. Charging data has no limit and the rating trigger must be LIUSA. Charging data has the linked URR ID as URR_Off3.

    • Third offline URR is the rating group level, which limits the rating group trigger or local configuration.

    • First online URR is derived from the first Charging Data. Charging data has no limit and the rating trigger must be LIUSA. Charging data has the linked URR ID as URR_Online3.

    • Second online URR is derived from the second Charging Data. Charging data has no limit and the rating trigger must be LIUSA. Charging data has the linked URR ID as URR_Online3.

    • Third online URR is the rating group level, which limits from the granted unit.

    • First PDR is derived from the first PCC rule.

    • Second PDR is derived from the second PCC rule.

    • First offline URR, first online URR, third offline URR, and third online URR are linked to the first PDR.

    • Second offline URR, third online URR, third offline URR, and third online URR are linked to the second PDR.

  • N40 interface:

    • First UUC is derived from the usage report of the first offline URR and has a service identifier.

    • Second UUC is derived from the usage report of the second offline URR and has a service identifier.

    • Third UUC is derived from the usage report of the first online URR and has a service identifier.

    • Fourth UUC is derived from the usage report of the second online URR and has a service identifier.

Offline-Online Method When Charging Data is Derived from One PCC Rule with No Service Identifier

  • Offline Reporting level: Service ID level

  • Online Reporting level: Rating Group level

  • Prerequisite: No Reporting Level from PCF

  • CLI:

    • Tight interworking mode

    • Ignore Service Identifier

    • Offline Reporting: Service Identifier

    • Online Reporting: Rating Group

NOTES:

  • SMF ignores the volume or time limit trigger from CHF at the rating group level.

  • Session-level URR is not associated to URRs that are derived from the first Charging Data.

  • N4 interface:

    • Offline URR is derived from the first Charging Data. Charging data has no limit and the rating trigger must be LIUSA. Charging data has the linked URR ID as URR_Online.

    • Online URR is derived from the first Charging Data, which limits from the granted unit.

    • First PDR is derived from the first PCC rule.

    • Online URR and offline URR are linked to the first PDR.

  • N40 interface:

    • First UUC is derived from the usage report of the offline URR and has a service identifier.

    • Second UUC is derived from the usage report of the online URR and does not have a service identifier.

NOTES:

  • Session-level URR is not associated to the configured URRs.

  • If URR is configured, URR rulebase is derived from egcdr and is linked to both the offline and the online URRs.

Offline-Online Method When Charging Data is Derived from Two PCC Rules with No Service Identifier

  • Offline Reporting level: Service ID level

  • Online Reporting level: Rating Group level

  • Prerequisite: No Reporting Level from PCF

  • CLI:

    • Tight interworking mode

    • Ignore Service Identifier

    • Offline Reporting: Service Identifier

    • Online Reporting: Rating Group

NOTES:

  • SMF ignores the volume or time limit trigger from CHF at the rating group level.

  • Session-level URR is not associated to URRs that are derived from the first Charging Data.

  • N4 interface:

    • First offline URR is derived from the first Charging Data. Charging data has no limit and the rating trigger must be LIUSA. Charging data has the linked URR ID as URR_Online.

    • Second online URR is derived from the second Charging Data. Charging data has no limit and the rating trigger must be LIUSA. Charging data has the linked URR ID as URR_Online.

    • URR_Online is derived from the second Charging Data, which limits from the granted unit.

    • First PDR is derived from the first PCC rule.

    • Second PDR is derived from the second PCC rule.

    • First offline URR and URR_Online are linked to the first PDR.

    • Second offline URR and URR_Online are linked to the second PDR.

  • N40 interface:

    • First UUC is derived from the usage report of the first offline URR and has a service identifier.

    • Second UUC is derived from the usage report of the second offline URR and has a service identifier.

    • Third UUC is derived from the usage report of the URR_Online and does not have a service identifier.

NOTES:

  • Session-level URR is not associated to the configured URRs.

  • If URR is configured, URR rulebase is derived from egcdr and is linked to both the first and second offline URRs along with URR_Online.

Limitations

This feature has the following limitations:

  • Same rating group is not supported for multiple Charging-action of rulebase and Dynamic Charg-Desc.

  • Tight interworking mode is not supported for the service which is at the rating group level.

  • One service at the rating group level and another service at service ID level are not supported.

Standards Compliance

The Different Reporting Level Support for Online and Offline Charging feature complies with the following standards:

  • 3GPP TS 32.255

  • 3GPP TS 32.290

Error Handling Scenarios

This section describes the different handling scenarios associated with the errors that are encountered during SMF charging.

Application Error and Result Code Handling

SMF supports the application error codes from CHF at command level as defined in section 6.1.7.3 of specification 3GPP 32.291, v15.3.0. The SMF also supports RG-level result codes as defined in section 6.1.6.3.14 of specification 3GPP 32.291, v15.3.0.

The following labels are defined under "chf_appl_err_stats" counter to indicate the CHF response failures at the application level.

  • http2_err_code - The possible values are:

    • 403

    • 400

    • 404

  • appl_err_code - The possible values are:

    • END_USER_REQUEST_REJECTED

    • END_USER_SERVICE_DENIED

    • QUOTA_LIMIT_REACHED

    • CHARGING_NOT_APPLICABLE

  • appl_err_action - The possible values are:

    • drop_traffic

    • disable_charging

    • terminate

  • appl_err_exchg_type - The possible values are:

    • initial

    • update

Application Error Codes

The following table provides details of the application error codes with the corresponding SMF action.

Application Error/Session Level

HTTP2 Code

SMF Action

CHF Expected Actions

Limitations

CHARGING_FAILED

400

Terminate

None

None

RE_AUTHORIZATION_FAILED

400

None

Take corrective action

-

CHARGING_NOT_APPLICABLE

403

Continue subscriber session without Charging (no offline charging as well)

None

None

USER_UNKNOWN

404

Terminate

None

None

END_USER REQUEST_DENIED

403

Terminate

None

None

QUOTA_LIMIT_REACHED

403

Drop traffic for the online services. Offline services are not impacted.

CHF sends notify (RAR) after this condition is recovered for the session

NOTES:

  • The error code 403 is not configured in the failure handling template.

  • CHARGING_NOT_APPLICABLE (Disable charging) for static and predefined rules is achieved by sending a proprietary IE “Charging Disabled” in subscriber params in N4 modification / establishment request, so that UPF does not generate Start of Traffic for the URRs pending for activation.

RG-level Result Codes

The following table provides details of the result code with the corresponding SMF action.

Result code/RG level

HTTP Status Code

SMF Behaviour

CHF Expected Behaviour

Limitations

RATING_FAILED

200

Drop traffic corresponding to the rating group

None

None

QUOTA_MANAGEMENT_NOT_APPLICABLE

200

Convert to offline

None

None

USER_UNKNOWN

200

Ignored (supported only at session level)

Not expected from CHF

None

END_USER SERVICE_DENIED

200

Drop traffic corresponding to the rating group

CHF sends notify (RAR) after this condition is recovered for the rating group.

Traffic will be dropped for offline service as well for online/offline services.

QUOTA_LIMIT_REACHED

200

Drop traffic corresponding to the rating group

CHF sends notify (RAR) after this condition is recovered for the session

None

END_USER SERVICE_REJECTED

200

Drop traffic corresponding to the rating group

CHF sends notify (RAR) after this condition is recovered for the session

None

CHF Server Reconciliation

The SMF falls back to the first available offline CHF server when the NF selected by NRF discovery is unreachable. The CHF Reconciliation feature involves deleting the existing subscribers that are associated to a set of offline NFs, and the subscribers that are in offline fallback mode.

The CHF server reconciliation works when any of the following two conditions are met:

  1. if the NRF detects that an offline CHF server is now active

  2. if the RAR is recieved from the CHF server on an offline converted session

For the condition #2, the session gets deleted directly. With the NRF discovery, this feature involves the following steps:

  1. SMF subscribes for the notification of NF instance IDs from NRF through NF_LIB component of Rest-ep.

  2. If the NF discovery query determines that all the NFs are down, the NF_LIB component treats these set of NFs as offline. If any one of the NFs is available again, the NRF triggers notification for the same to the SMF.

  3. The SMF performs NRF discovery after re-validation timer. If the NRF detects any new NF, the SMF receives the corresponding notification from the NRF.

  4. When the SMF learns that an NF is online and it satisfies the NF discovery query parameters, then the SMF initiates the CHF server reconciliation.

The following labels are introduced as part of this feature:

  • disc_pdurel_chf_reconciliation: This label is defined under SMF_DISCONNECT_STATS to indicate the disconnect reason.

  • chf_reconl_pdu_sess_rel: This label is defined under smf_service_stats metric to display the number of times the PDU session release procedure is initiated.

Dynamic Configuration Change Support

Feature Description

The Failure Handling Profile contains the configurations that are invoked when a failure occurs. Now, the Failure Handling feature supports the N11 and GTPC interface. With the dynamic configuration, you can change the dynamic attributes associated with the Failure Handling Profile while SMF is running.

Similarly, the Dynamic Configuration Change Support feature allows SMF to dynamically handle the configuration changes of the Charging Profile parameters while minimizing the configuration errors. The existing and new SMF Charging parameters can implement dynamic configuration updates. This feature supports the following charging configurations:

  • Charging Profile

  • Charging Characteristics

  • Charging-Action

  • Credit-Control-group

  • Urr-Id Map

  • Rulebase and GTPP Group

  • Upf-Apn Configuration Group

Limitations

In this release, the Dynamic Configuration Change Support for Charging Profile has the following limitations:

  • For online charging, the URR ID configuration and creation time on SMF and UPF may differ causing a discrepancy in the following configurations:

    • Rating Group (RG) and Service ID configuration within the Charging-Action

    • URR-ID list that contains the URR IDs created for static or predefined URR

    • Ignore-Service in Credit-Control group

    • Mapping of Ruledef with the Charging-Action Profile

  • Dynamic configuration of changes for the methods within the charging-action configuration are not supported.

How it Works

This section describes how dynamic change in configuration works for the supported Failure Handling Profile and Charging Profile configuration.

Failure Handling Profile

The Failure Handling Profile defines the various parameters for failure handling.

The following table lists the configurations that allow dynamic update.

Table 3. Failure Handling Profile Parameters

Configuration Parameters

Configuration

Dynamic Change

Impact on Existing Sessions

profile failure-handling 

profile failure-handling name interface gtpc/n11 message message cause-code  cause_code actionaction timeout timeout max-retry retry_count

Supported values:

  • interface: gtpc or n11

  • message:

    • gtpc-message:

      • S5S8CreateBearerReq

      • S5S8CreateBearerReq

      • S5S8CreateBearerReq

    • N11-message: n1n2transfer

  • cause-code:

    • gtpc-cause-code: temp-fail

    • N11-cause-code: temp-reject-handover/ temp-reject-register

  • action: retry/clear/terminate

  • timeout: Range: [1000-5000] (default: 1000)

  • max-retry: Range: [0-5] (default: 1)

Note 

  • The timeout and max-retry parameters are applicable only if the action is set to ‘retry’.

  • The CLI supports only the ‘retry’ action.

Allowed

Sessions that use the old value in a call flow and procedure continues to use the old value.

Charging Profile

The Charging Profile supports dynamically updating the configuration based on the values that you pass during the runtime. The refresh operation of the values takes place considering the following scenarios:

  • Configuration reflects in the next encounter to access: If the values are updated while an operation is in-progress, the SMF ignores the new values and continues to use the old values. For example, Limits in Charg-Profile, CC triggers.

  • Configuration reflects only on a new session: If the configuration is specific to a session and the session has already ingested the values, then SMF does not consider the new values. For example, PduContext (DB entry). This indicates that any update to the configuration does not impact the sessions that are already created. For instance, Charging Method in Profile or Charg-Profile in Charging Characteristics.

  • Configuration reflects instantly: Configurations immediately ingest the dynamic values whenever they are updated. If SMF has already used a configuration and it is later updated, then it uses the latest values.

If a session is created using a Charging Profile, which later gets deleted from the Ops Center, the session might attempt to access the configuration structure of the deleted profile. In such cases, the Smf-Service pod maintains a default profile mapped to the sessions whose profiles are missing.

The Charging Profile is responsible for handling the SMF charging parameters.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 4. Charging Profile Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

limit rating-group duration

Allowed

New values are used during the new URR creation or the subsequent URR update for the existing sessions.

Note 

The dynamic configuration does not initiate a URR update.

max-charging-condition

Allowed

No impact

max-deferred-urr

Allowed

No impact

metering-method

Allowed

New values are used during the new URR creation for the existing sessions.

method

Allowed

No impact

reporting-level

Allowed

No impact

requested-service-unit time

Allowed

No impact

tight-interworking-mode

Allowed

No impact

triggers session

Allowed

No impact

Request Quota

Allowed

No impact
Charging-Characteristics Profile

The Charging-Characteristics Profile configuration defines the various parameters for a managing a charging characteristics for SMF Charging.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 5. Charging-Characteristics Profile Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

charging-profile

Not Allowed

The configuration is used only once while setting up the session.
Charging-Action Profile

The Charging-Action Profile configuration defines the QoS and charging related parameters associated with the rule definitions.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 6. Charging-Action Profile Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

Rating group and Service ID

Allowed

No impact
Usage Reporting Rules ID Profile

The Usage Reporting Rules (URR-ID) specifies the configuration for the rating and service groups.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 7. URR-ID Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

URR ID for rg and ServID*

Allowed

No impact
Credit-Control-Group Profile

The Credit-Control-Group configuration defines the parameters to be used for subscribers who use the mapped rulebase.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 8. Credit-Control-Group Profile Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

Ignore Service ID

Allowed

No impact
Rulebase Profile

The Rulebase configuration parameters define the protocol rules to match a flow and associated actions to be taken for matching flow.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 9. Rulebase Profile Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

Ruledef association to Charging-action

Allowed

No impact

Credit-Control-Group

Allowed

The configuration is used only once while setting up the session.
GTPP Group Profile

The GTPP Group Profile configuration specifies the parameters for creating the GRPP group.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 10. GTPP Group Profile Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

Limits for offline configured urrs

Allowed

New values are used during the new URR creation for the existing sessions.
Upf-Apn Configuration Profile

The Upf-Apn Configuration Profile configuration defines the various parameters for the Upf-Apn parameters.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 11. Upf-Apn Configuration Profile Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

Association of gttp Group

Allowed

The configuration is used only once while setting up the session.
Network Profile for Peer CHF

The network profile for peer CHF configuration defines the various network configurations.

The following table illustrates if configuration parameters allow dynamic configuration change.

Table 12. Network Profile for Peer CHF Parameters

Configuration Parameters

Dynamic Change

Impact on Existing Sessions

Set of CHf’s configured

Allowed

No impact