Accounting and charging
Learn about the statistics collection from the BNG-UP, time-based and volume-based charging, RADIUS accounting configuration, and buffering of the RADIUS accounting messages for later retransmission.
BNG charging profiles
BNG charging profiles define the charging interfaces for a session. A session can be associated with multiple BNG charging profiles.
BNG charging profiles contain the configuration of the charging interfaces for a session; for example, the RADIUS accounting interface. Charging profiles are assigned to sessions during authentication.
Multiple charging profiles can be provisioned per session. The following example use cases enable the same charging interface in different contexts.
- Two charging profiles support duplicate RADIUS accounting to a main and a backup accounting server. The two charging profiles are identical, except for the target servers.
- Multiple charging profiles support multiple distinct logging systems using the same interface. For example, one profile for RADIUS packet/octet accounting, one for NAT port block logging, and one for session create/delete logging.
configure mobile-gateway profile charging
To
use a BNG charging profile for a specific set of sessions, use the
bng-charging-profile command in the following context.
configure mobile-gateway profile authentication-database entry charging
Except for the communication with the BNG-UP, there is no interaction between multiple charging profiles for the same session. Each charging profile uses the session data and the triggers (periodic interval or trigger events) to act according to its configuration. For example, a messaging failure for one profile does not affect retransmits in another profile.
Concerning the communication with the BNG-UP, the MAG-c tries to optimize the number of messages sent. For example, if the same event triggers multiple charging profiles to fetch BNG-UP data, the MAG-c attempts to send a single request to the BNG-UP instead of a request per charging profile.
Statistics collection from the BNG-UP
Configure the pull or push model to fetch mid-session PFCP usage reports from the BNG-UP.
A PFCP Usage Report IE contains incremental BNG-UP statistics per session. The usage report only includes statistics collected since the previous usage report. The MAG-c aggregates the statistics for the session. This incremental method is robust and can handle a BNG-UP failure. When a BNG-UP failure occurs, statistics collected since the previous report are lost. However, the MAG-c statistics remain correct and increase monotonically. Similarly, when BNG-UP resiliency is used, the MAG-c can add counters of both BNG-UPs to calculate the correct aggregate.
The MAG-c supports two models to fetch mid-session PFCP usage reports:
- pull model
The MAG-c explicitly requests a usage report in a PFCP Session Modification Request message when it needs up-to-date counters. The MAG-c does not send periodic unsolicited pull requests. For example, it requests a Usage Report for a RADIUS Accounting Request Interim Update message.
- push model
The BNG-UP sends an unsolicited PFCP Usage Report IE in a PFCP Session Report Request message. Upon receiving this message, the MAG-c records and stores the statistics. The push message does not trigger an update (for example, Radius Accounting Interim Update or CHF Nchf_ConvergedCharging_Update). However, the statistics update may trigger any reporting limit, threshold, or quota; for example, a CHF offline charging volume limit or CHF online charging quota.
The unsolicited usage report can either be periodic, or threshold- or quota-based. Both push models can be enabled simultaneously as follows:
- periodic push model
The BNG-UP sends a report within a fixed interval. If another report was generated (for example, pull-based or threshold-based), the interval is reset.
- threshold- or quota-based push modelThe MAG-c instructs the BNG-UP to send a report when the amount of collected statistics reaches a specific threshold or quota. For online charging use cases, the MAG-c can additionally instruct the BNG-UP to take immediate action when a specific quota is reached; for example, stop forwarding. See Online Charging for more information.Note: Because a URR can serve multiple applications, the threshold or quota values installed on the FWA-UP do not always match a specific application limit, quota, or threshold value. For example, a volume threshold of 1 GB may be installed by online charging, while a volume limit of 300 MB is installed by offline charging. Initially, the MAG-c installs a 300 MB threshold on the BNG-UP, matching the offline charging limit. However, after the third report 900 MB is consumed, the MAG-c installs a 100 MB threshold on the BNG-UP to match the remainder (1 GB - 3 × 300 MB) of the online charging threshold.
The following figure shows the statistics collection using the push model.
- periodic push model
configure mobile-gateway profile authentication-database entry charging statistics-collection-interval
A small push interval can reduce counter loss in case of BNG-UP failures, but increases the load on the MAG-c. The system must be dimensioned accordingly.
Push and pull modes can work in parallel. For example, the RADIUS accounting is enabled with an interval of 1 h (pull mode) and the BNG-UP reporting is enabled with an interval of 5 min (push mode). Every hour, the RADIUS accounting message triggers an explicit pull from the BNG-UP to fetch the latest counters, while the BNG-UP sends unsolicited usage reports every 5 min. This allows for a frequent counter update to avoid loss without overloading the AAA server and without the AAA server having outdated statistics.
If the pull interval is similar to the push interval, Nokia recommends disabling the push mode. Having similar intervals for the push and the pull mode increases the load without a direct benefit.
For resilient sessions, the MAG-c maintains one set of counters that are aggregated from all PFCP sessions that have been set up over the lifetime of the encompassing session. The incremental nature of the PFCP reports allow this without risking duplicate counters. The MAG-c can present these aggregated counters monotonically increasing to other interfaces such as RADIUS accounting, MAG-c charging, and show commands. Because of BNG-UP resiliency, back-end systems, such as accounting servers, do not need to account for sudden counter resets.
In case of hot standby BNG-UP resiliency, there are two PFCP sessions. When performing pull requests, the MAG-c pulls statistics from the active BNG-UP in steady state, because it does not expect traffic from the standby BNG-UP. During switchovers, the MAG-c pulls from both BNG-UPs to fetch the potentially still available final statistics from a failed BNG-UP. The MAG-c installs the push mode on both BNG-UPs. The Nokia BNG-UP , however, is optimized to only send push reports if the reported statistics contain non-zero values. The statistics of a standby BNG-UP in steady state normally contain only zero values.
Independent of mid-session statistics collection, final statistics are always fetched when the session is removed in a PFCP session deletion procedure.
The following statistics are supported:
-
aggregate number of bytes upstream and downstream
-
aggregate number of packets upstream and downstream, if the BNG-UP signals the MNOP function feature in the PFCP association procedure
-
detailed statistics as collected by the Nokia BNG-UP
Examples of detailed statistics are per queue statistics, per policer statistics, and separate IPv4 and IPv6 counters. The content of the detailed statistics depends on the BNG-UP QoS stat-mode configuration.
The MAG-c only collects statistics for sessions that are linked to a charging profile with at least one charging interface enabled (for example, RADIUS accounting). A charging profile can be assigned to a session during authentication.
configure mobile-gateway profile authentication-database entry charging detailed-statistics
When enabled, the MAG-c requests the BNG-UP to send detailed statistics.configure mobile-gateway profile charging bng-charging radius session include-attribute detailed-statistics
When the MAG-c detects a new stat-mode or SLA Profile, the detailed statistics are reset. The MAG-c sends the final detailed statistics for the previous stat-mode or SLA profile in RADIUS accounting messages if enabled. Because aggregated statistics are not dependent on the stat-mode nor on the SLA profile, they are not reset.
On a Nokia BNG-UP, both aggregate and detailed statistics are based on the QoS model. If multiple sessions of the same subscriber share QoS resources, the statistics are collected on a per-session basis, but they do not provide real usage of a specific session. The aggregate of the session statistics is correct for the shared QoS resource. If real usage of per session statistics are required in a multiple sessions per subscriber model, Nokia recommends enabling an SPI per session model on the BNG-UP.
MAG-c-based charging
Learn about time-based and volume-based charging.
Time-based charging
The MAG-c provides time-based charging using the session timeout mechanism. This session timeout starts after successful authentication. The MAG-c deletes the session when the timer expires.
Volume-based charging
For basic volume-based charging, the MAG-c compares the statistics to provisioned thresholds. The MAG-c compares the statistics with the thresholds for every received usage report.
The following thresholds are supported:
- total number of upstream bytes
- total number of downstream bytes
- total number of upstream and downstream bytes
configure mobile-gateway profile authentication-database entry charging
The threshold values can also be provided via RADIUS. For more information, see MAG-c RADIUS Attributes and IU Triggers.
As soon as one of the provisioned thresholds is reached, the MAG-c deletes the session.
For deterministic behavior, Nokia recommends combining the volume-based charging with periodic statistics collection.
RADIUS accounting
Learn about the RADIUS accounting configuration in the BNG charging profile and how to enable RADIUS accounting.
The MAG-c supports RADIUS accounting as defined in RFC 2866.
To enable RADIUS accounting, perform the steps in Enabling RADIUS accounting.
The RADIUS accounting configuration in the BNG charging profile includes the following parameters.
- RADIUS group
The RADIUS group provides the list of RADIUS servers and load-balancing parameters. It also defines the default interim interval used for sending periodic RADIUS Accounting Request Interim Update messages.
Use the radius-group command in the following context to reference the RADIUS group in the BNG charging profile.configure mobile-gateway profile charging bng-charging radius
Use the radius-group command in the following context to define and configure the RADIUS group parameters.configure mobile-gateway profile
- session accounting parameters
The accounting parameters for sessions include configuration of attributes to include in accounting messages, and triggers to send the RADIUS Accounting Request Interim Update message.
Use the session command in the following context for the session accounting parameters.configure mobile-gateway profile charging bng-charging radius
For more information about the accounting attributes, their content, the associated include-attribute configuration, and the messages they can appear in, see the MAG-c RADIUS Attributes and IU Triggers and the MAG-c CLI Reference Guide.
Enabling RADIUS accounting
-
Define a BNG charging profile.
Use the bng-charging command in the following context.
configure mobile-gateway profile charging
-
Configure RADIUS accounting for the BNG charging profile
Use the radius command in the following context.
configure mobile-gateway profile charging bng-charging
-
Reference the BNG charging profile.
Use the bng-charging-profile command in the following context.
configure mobile-gateway profile authentication-database entry charging
- Define match criteria for the ADB so that the BNG charging profile gets assigned to a session during authentication.
Session accounting
The MAG-c sends RADIUS accounting messages to start and stop session accounting. Interim update messages contain updates of the accounting data. The interim update messages can be periodic or triggered by an event.
Start and stop messages
When session accounting is enabled, the MAG-c sends an Accounting Request Start message to the RADIUS accounting server. The exact time when the message is sent in the session setup procedure depends on the session type. Sending the Accounting Request Start message is linked to the data plane creation on the BNG-UP and to the IP address assignment protocols.
configure mobile-gateway profile radius-group
Any
subsequent messages are sent to the same server. Only when the selected server fails, a new
server is selected.When the accounting is started, the MAG-c sends Accounting Request Interim Update (IU) messages. The MAG-c sends the IU messages periodically or based on triggers.
When the session is removed, the MAG-c sends an Accounting Request Stop message, including the final counters.
You can enable or disable session-level charging on a live system, but the new configuration affects only new sessions. Existing sessions continue with or without charging, based on the previous configuration.
Periodic interim updates
configure mobile-gateway profile charging bng-charging radius session update-triggers periodic
When the periodic sending is enabled, the interval for the Accounting Request Interim Update messages can be provisioned as follows, in order of precedence:
- during the session authentication; for example, using the RADIUS Acct-Interim-Interval attribute
- using the following
command
configure mobile-gateway profile charging bng-charging radius interim-update-interval
Note: When the value is changed using this command, existing sessions use the changed value after the next scheduled Accounting Request Interim Update message. - using the following
command
configure mobile-gateway profile radius-group interim-update-interval
The interval can be changed during the lifetime of a session by sending a RADIUS CoA with the Acct-Interim-Interval attribute. In this case, a session sends an immediate Accounting Request Interim Update message with the reason Interval-Changed and starts a timer with the new interval.
Triggered interim updates
The MAG-c sends a triggered Accounting Request Interim Update (IU) message when it detects changes in the session or subscriber data, or when an external system instructs to send an IU message.
The vendor-specific Alc-Acct-Triggered-Reason attribute in the IU message indicates the type of trigger.
See the MAG-c RADIUS Attributes and IU Triggers for information about supported trigger events.
When several trigger events occur at the same time, the MAG-c sends a single IU message with multiple Alc-Acct-Triggered-Reason attributes to include all trigger reasons.
In case one event triggers multiple IU messages, such as an SLA profile change, other simultaneous trigger events are included in the first IU message.
Message retransmission and buffering
RADIUS accounting messages are retried, but can also be buffered for later retransmission. Learn how to enable and configure the buffering of the different RADIUS accounting messages.
configure mobile-gateway profile radius
If
no accounting response is received after the retries, the MAG-c buffers the accounting messages to retransmit them later, if buffering is
enabled.configure mobile-gateway profile radius-group
When buffering is enabled, the MAG-c can buffer one Accounting Stop message per session. Optionally one Accounting Start, and up to five Interim Update messages can be buffered.
configure mobile-gateway profile radius-group accounting-buffer
configure mobile-gateway profile radius-group accounting-buffer
The following restrictions apply to buffering of the accounting messages.
- The lifetime of a buffered accounting message is configurable. The default lifetime
is 24 hours. Because of final retransmission attempts, the message can be kept
longer than the configured lifetime. To configure the lifetime of the buffered
accounting messages, use the lifetime command in the following
context.
configure mobile-gateway profile radius-group accounting-buffer
- The system limits the maximum number of buffered accounting messages, and generates a trap (with name tmnxMobGwAcctBuffResourceProblem) when the limit is crossed.
The MAG-c classifies the Accounting Interim Update messages as critical or non-critical depending on the trigger event.
- Non-critical messages do not reflect a significant state change and contain data
that is present either in the subsequent Accounting Interim Update messages, or in
the Accounting Stop message. For example, a periodic Interim Update message contains
only updated cumulative counters that are also present in a subsequent Interim
Update or Stop message. When buffering of the Interim Update messages is enabled,
the following rules apply.
- Only the last non-critical Interim Update message for a session is buffered. If there was a previous non-critical message buffered, this previous message is discarded and overwritten.
- When the session terminates, the optionally stored non-critical Intermediate Update message for that session is discarded and overwritten with the Stop message.
- Critical messages reflect a significant state change, and can contain data that is lost if not sent; for example, a stop of service and the final statistics related to that service. When buffering of the Interim Update messages is enabled, up to four critical Interim Update messages per session are buffered to prevent loss of data.
Periodic Interim Update messages are non-critical messages. Triggered Interim Update messages can be critical or non-critical depending on the trigger reason.
A non-configurable timer triggers a periodical retransmit of the buffered messages. The timer value changes depending on the load of the system. It uses exponential back-off when a server is unavailable and can increase to 1 hour.
CHF charging
The guidelines in this chapter provide the basic requirements and options for configuring the CHF function common interface Nchf_ConvergedCharging SBI service.
In a 5G core network, the Charging Function (CHF) provides both online and offline charging functionality using a common interface Nchf_ConvergedCharging SBI service. The Nchf_ConvergedCharging SBI service can offer online-only charging, offline-only charging, or simultaneous online and offline charging. See Service Based Interfaces for more information about SBI service communication.
Enabling CHF charging
This task describes the steps to enable a basic Nchf_ConvergedCharging SBI service.
To enable CHF communication, perform the following steps:
-
Use the following command to configure a CHF ConvergedCharging client
service.
configure mobile-gateway pdn sba-client-services chf-client nchf-convergedcharging
-
Use the following command to configure an interface for the MAG-c to use to communicate with the CHF server.
configure mobile-gateway pdn sba-client-services chf-client nchf-convergedcharging interface
-
Use commands in the following context to optionally configure the functionality
indicated:
configure mobile-gateway pdn sba-client-services chf-client nchf-convergedcharging
- Configure an FQDN to identify the service by other NF peers. For example, when generating callback functions, the MAG-c uses the FQDN in the URI, instead of the IP address; see URI construction for more information.
- Configure an HTTP2 profile to influence generic HTTP/2 and SBI parameters; see HTTP/2, OpenAPI, and Python for more information.
- Configure an API prefix that indicates the API version used in construction of any URIs. This only overrides the URI values and does not change the MAG-c behavior. See URI construction for more information.
CHF peer discovery
CHF peer discovery is implemented using a list of mechanisms in priority order.
The CHF extends the peer discovery (defined in NF peer discovery) with two additional sources for peer discovery. The CHF peer discovery is implemented in the following priority order:
- The PCF returns a primary and secondary CHF address in the primaryChfAddress and secondaryChfAddress attribute fields of the ChargingInformation data type when creating an SM policy. See PCF-based policy management for more information.
- A charging profile NF ID list is used, if configured using the following
command.
This command has the following purposes:configure mobile-gateway profile charging bng-charging chf chf-selection nf-id-list
- If the PCF signals a primary or secondary address, this list picks up the NF
instance ID associated with that address. If this list is not configured or
the peer is not found, the default UUID 11111111-0000-0000-0000-111111111111
is used. The MAG-c uses the UUID, for example, for statistics collection.Note: If the default UUID is used by multiple CHF peers, per-peer statistics are not available.
- If the PCF does not provide a primary or secondary address, this list provisions a specific set of CHF peers associated with this profile, which bypasses any NRF discovery.
- If the PCF signals a primary or secondary address, this list picks up the NF
instance ID associated with that address. If this list is not configured or
the peer is not found, the default UUID 11111111-0000-0000-0000-111111111111
is used. The MAG-c uses the UUID, for example, for statistics collection.
- Use the following command to configure the NF ID list. Discovery based on the NRF or
local NF ID list is used as defined in NF peer discovery.
configure mobile-gateway pdn apn charging nchf chf-selection nf-id-list
Selecting predefined CHF peers based on charging characteristics
A common use case for CHF peer selection is to select a set of predefined CHF peers based on the charging characteristics (CC) values returned by the UDM for FWA sessions.
To configure this on the MAG-c, do the following:
-
For each CC value, use the following command to create a BNG charging profile
with an NF ID list that corresponds to the CC value.
configure mobile-gateway pdn apn charging nchf chf-selection nf-id-list
- Create an ADB and configure it to match the CC value configured in step 1; see Authentication database for more information.
-
Under the ADB created in step 2, add an entry for
each CC value you want to map, and under that entry apply the corresponding BNG
charging profile using the following command.
configure mobile-gateway profile authentication-database entry charging bng-charging-profile
- Apply the ADB as one of the ADBs in the FWA authentication flow. See Selected and real APN for more information about how to configure the authentication flow for FWA sessions.
Charging sessions and rating groups
The steps in Starting a charging session toward the CHF describe how to establish a charging session between a MAG-c and CHF. However, any charging itself is performed at the level of a Rating Group (RG).
The following applies to charging RGs:
- RGs can be provisioned locally (see Session charging using a session RG ) or signaled by the PCF.
- Each RG defines exactly which traffic is subject to charging and which units (time or volume) are monitored.
- Each RG has a unique RG ID to identify it within a session.
- Each RG is subject to either offline or online charging. The PCF decides this by setting the online or offline charging IE. If the PCF does not signal the IE or the PCF interaction is disabled, the MAG-c follows the configuration of the default-charging-method command under the BNG charging profile. It is possible to simultaneously enable offline and online charging for the same RG.
A charging session uses the following operations of the Nchf_ConvergedCharging service:
- The Nchf_ConvergedCharging_Create operation starts the charging session. The MAG-c initiates this operation with an HTTP/2 POST message that includes the following
data:
- session metadata such as IMSI, MSISDN, APN, ULI, RAT, and S-NSSAI
- a list of RGs subject to charging and, if online charging is enabled, includes the requested units (by default set to zero)
- a notification callback URI for the Notify operation
- When the charging session starts successfully, the CHF responds with a 201 Created
status code that includes the following data:
- a CHF session URI (in the location header) that is used to identify the charging session on the CHF
- session-level trigger conditions for the Update operation
- the same list of RGs with RG-level trigger conditions for the Update operation and if online charging applies, also includes the granted quota units for that RG
- The Nchf_ConvergedCharging_Update operation is used for any updates, both at the
session and RG levels. The Update operation is performed when an installed trigger
condition is fulfilled or explicitly triggered via a Notify operation. See Charging update triggers for more information. The MAG-c initiates this operation with an HTTP/2 POST message toward the CHF session URI
to update the current charging session. The message includes the following data:
- trigger conditions that are fulfilled
- session meta data
- list of RGs that are subject to the fulfilled trigger conditions and, depending on the trigger type, signals for used units only or also requests for new updated quota units
- When successful, the CHF responds with a 200 OK status code that includes the
following:
- list of updated trigger conditions
- list of RGs with new trigger conditions or new granted quota units, if any
- The CHF uses the Nchf_ConvergedCharging_Notify operation to indicate the charging session changed and the MAG-c should either abort or reauthorize charging. The CHF initiates this operation with an HTTP/2 POST message toward the MAG-c notification callback URI. The message indicates whether charging should be terminated or reauthorized.
- When the Notify operation is successful, the MAG-c responds with a 204 No Content status code. The MAG-c subsequently triggers the Update procedure. See Charging update triggers for more information.
- The Nchf_ConvergedCharging_Release operation gracefully terminates the charging session. The MAG-c initiates this operation with an HTTP/2 POST message toward the CHF session URI. The message includes the final used units for all RGs.
- The CHF confirms with a 204 No Content status code that the charging session is removed.
The following figure shows a high-level flow for the Create, Update, and Release operations. See Charging update triggers for information and an example of the Notify operation.
Starting a charging session toward the CHF
To start a charging session toward the CHF, perform the following steps:
-
Use the following command to configure a BNG charging profile.
configure mobile-gateway profile charging bng
Ensure the BNG charging profile is used as defined in BNG charging profiles, for example using ADB.
-
Use the commands in the following context to configure the optional settings as
indicated:
configure mobile-gateway profile charging bng-charging chf
- Configure the default-charging-method command to determine which charging method is signaled when creating an SM policy association toward the PCF using online and offline IEs. See PCF-based policy management for more information.
- Configure the dnn-format command to determine which DNN is sent to the CHF. By default the selected DNN is used.
- Configure the chf-profile command to define any service communication behavior, including failure handling.
- Configure the nf-id-list command to select a specific set of peers for the CHF profile that takes precedence over NRF-based discovery. See CHF peer discovery for more information.
- Use the no shutdown command to enable CHF charging for the session.
Session charging using a session RG
The MAG-c supports charging for all traffic of a single session by creating a session RG. Use the following command to enable session charging by allocating a session RG ID.
configure mobile-gateway profile charging bng-charging chf session-charging rating-group
The session RG uses a single session URR to collect statistics from the FWA-UP, as described in Statistics collection from the BNG-UP. This URR is shared with other applications that require session-level statistics reporting or usage monitoring.
The session RG supports both online charging and offline charging.
Offline Charging
When offline charging is enabled for an RG, the MAG-c reports consumed units toward the CHF. Because the MAG-c uses the Nchf_ConvergedCharging SBI service, offline and online charging can be combined. Offline charging is implicitly enabled when online charging is enabled.
Consumed units are always signaled to the CHF when the RG is reported in the Nchf_ConvergedCharging_Update operation, including reports triggered by online charging. Additionally, periodic or volume limit-based reports for offline purposes only can be enabled.
To enable periodic reporting of used statistics to the CHF, the CHF must provide the TIME_LIMIT trigger with a corresponding time limit value for the RG. If this trigger is not set, the MAG-c does not generate periodic offline reports, even if there are periodic usage reports from the FWA-UP to the MAG-c. Upon sending a periodic report, the MAG-c fetches the most recent statistics from the FWA-UP, if the existing statistics are not current. When enabled, these reports are always generated on the specified period, independent of any other reports generated in the reporting period.
To enable volume limit-based reporting of used statistics, the CHF must provide the VOLUME_LIMIT trigger with a corresponding volume limit value for the session RG. This volume limit is always relative to the last report generated for this RG. That is, when the MAG-c generates any other report, for example periodic, the current volume limit is restarted.
Combination of time and volume limit
The following table shows a time sequence for an RG configured with a combination of a time and volume limit.
Time | Action |
---|---|
0 h 00 min | The RG is created with a time limit of 1 h and volume limit of 1 GB. |
0 h 45 min | The FWA-UP notifies the MAG-c that 1 GB of data has been consumed. The MAG-c reports this to the CHF based on the volume limit. The total consumed data at this point is 1 GB. |
1 h 00 min | The periodic time limit expires and the MAG-c requests the consumed data from the FWA-UP. The FWA-UP replies that an additional 300 MB of data has been consumed. The MAG-c reports this to the CHF. The total consumed data at this point is 1.3 GB. |
1 h 33 min | The FWA-UP notifies the MAG-c that 1 GB of additional data has been consumed. The MAG-c reports this to the CHF based on the volume limit. The total consumed data at this point is 2.3 GB. |
2 h 00 min | The periodic time limit expires and the MAG-c requests the consumed data from the FWA-UP. The FWA-UP replies that an additional 700 MB of data has been consumed. The MAG-c reports this to the CHF. The total consumed data at this point is 3 GB. |
3 h 00 min | The periodic time limit expires and the MAG-c requests the consumed data from the FWA-UP. The FWA-UP replies that an additional 150 MB of data has been consumed. The MAG-c reports this to the CHF. The total consumed data at this point is 3.15 GB. |
Online Charging
- indicate that quota management is not applicable
- send initial quota units
- time or volume quota, or both
- optional time or volume threshold or both
This threshold is a relative threshold for remaining quota. For example, if the CHF signals a volume quota of 10 GB and a volume threshold of 1 GB, the absolute threshold is hit after 9 GB.
- optional final unit indication
This indication can have the following values:
- TERMINATE – stop forwarding for the RG
- REDIRECT – redirect traffic when the quota are exhausted
- When a threshold is hit, the MAG-c initiates the Nchf_ConvergedCharging_Update operation with the QUOTA_THRESHOLD trigger set. The MAG-c reports the consumed units and requests new units for this RG.
- When a quota is hit and a final unit indication is provisioned, the MAG-c initiates the Nchf_ConvergedCharging_Update operation with the FINAL trigger
set. The MAG-c reports any consumed units but does not request new units for this RG.
Subsequently, the forwarding rules are updated based on the installed final unit
indication:
- final unit indication is set to TERMINATE
The MAG-c instructs the FWA-UP to block all traffic for this RG.
- final unit indication is set to REDIRECT
The MAG-c applies redirect actions specific to that RG. If no RG-specific redirect actions are defined, the MAG-c falls back to the forwarding rules for TERMINATE.
For more information about session RGs, see Session charging using a session RG.
- any other final unit indication (for example, RESTRICT)
The MAG-c falls back to the forwarding rules for TERMINATE.
- final unit indication is set to TERMINATE
- When a quota is hit and no final unit indication is provisioned, the MAG-c initiates the Nchf_ConvergedCharging_Update operation with the QUOTA_EXHAUSTED trigger set. The MAG-c reports the consumed units and requests new units for this RG. The MAG-c does not change any traffic-forwarding behavior in this case.
- The MAG-c enables quota and threshold monitoring on the FWA-UP, using the URR tied to the RG. This ensures that the FWA-UP generates a usage report soon after reaching the installed quota or threshold, upon which the MAG-c takes any action as described in the preceding content.
- If the final unit indication action equals TERMINATE, the MAG-c instructs the FWA-UP to immediately stop forwarding traffic when this quota is reached.
For more information, see Statistics collection from the BNG-UP
- Signal the CREDIT_CONTROL_NOT_APPLICABLE error in the creditManagementStatus field toward the PCF.
- Apply offline-only charging to the RG. Contrary to most error result codes, this does not block traffic for the RG.
In the case where online and offline charging is combined for the same RG, the Charging Data Update messages triggered by offline charging (for example, time and volume limits) do not request new units for online charging.
Charging update triggers
The MAG-c supports the CHF to install trigger conditions upon which the Nchf_ConvergedCharging_Update operation is called to request an update. A trigger is categorized as either immediate or deferred, and a default category for each trigger type is defined in 3GPP TS 32.255, table 5.2.1.4.1. As indicated in this table, the CHF can use the TriggerCategory IE to override the category for some triggers. When a deferred trigger condition is fulfilled, the MAG-c does not immediately perform the update operation, but stores the used units for each RG and restarts any ongoing measurements. The used units are included with any trigger that results in an immediate update. The MAG-c can exceptionally generate an update operation for a deferred trigger if the number of deferred reports becomes too large.
The following preinstalled trigger types are supported on the MAG-c :
- USER_LOCATION_CHANGE
This trigger type is triggered by any change to the session ULI value.
- TIME_LIMIT
This trigger type must be signaled with a corresponding timeLimit value. This triggers a periodic reporting of used units of RGs for offline charging purposes. If an RG is also subject to online charging, a new quota is not requested and the existing quota stays valid.
- VOLUME_LIMIT
This trigger type must be signaled with a corresponding volumeLimit value. This triggers reporting of consumed units for the specified RG for offline charging purposes. If the RG is also subject to online charging, a new quota is not requested, and the existing quota stays valid.
- QUOTA_THRESHOLD
This triggers reporting of consumed units and requesting new quota when the threshold is consumed. For more information, see Online Charging.
When a quota and quota threshold value are specified, this trigger type is automatically enabled for an RG and cannot be disabled.
- QUOTA_EXHAUSTED
This trigger type must be signaled with a corresponding quota value. It triggers reporting of consumed units and requesting new quota when the quota is consumed and no final unit action is specified. Additionally, the MAG-c enforces any installed out-of-quota actions. For more information, see Online Charging.
When a quota value is specified, this trigger type is automatically enabled for an RG and cannot be disabled.
- FINAL
This trigger type must be signaled with a corresponding quota value. It triggers reporting of consumed units when the quota is consumed and a final unit action is specified. Additionally, the MAG-c enforces any installed out-of-quota actions. For more information, see Online Charging.
When a quota value is specified, this trigger type is automatically enabled for an RG and cannot be disabled.
- VALIDITY_TIME
This trigger type must be signaled with a corresponding validityTime value; a quota value must be specified. It triggers reporting of consumed units and requesting new quota when the validity time expires. This allows a CHF to periodically assign new quota even if previous quota were not consumed, or if quota were consumed and no new quota were granted.
- MANAGEMENT_INTERVENTIONThis trigger type cannot be disabled and is always categorized as immediate. It is used whenever the MAG-c has to force an update, for example, when using the following command.
clear mobile-gateway pdn charging
- Configuration:
- Set a TIME_LIMIT trigger with a 10 minutes deferred reporting on the RG level.
- Set a TIME_LIMIT trigger with 1 hour immediate reporting at the session level.
- Result:
- The MAG-c generates a usage report for the RG every 10 minutes without sending it.
- After 1 hour, the MAG-c sends an immediate report with both the current and deferred statistics.
- terminate charging by performing the Nchf_ConvergedCharging_Release operation
- request an update using the Nchf_ConvergedCharging_Update procedure
The following figure illustrates the call flow for a reauthorization of all RGs.
CHF failure handling
The CHF supports failure handling as defined in Failure handling. During failure handling using the ap-continue option, the MAG-c performs the following actions to handle ongoing charging:
- The MAG-c stops any ongoing online charging. Quotas are no longer enforced and thresholds are no longer monitored.
- The MAG-c periodically tries to re-establish a charging session toward the CHF, as configured by the session-restore-retry-timer command. If this fails, the failure-handling behavior continues. If this succeeds, the failure-handling behavior stops and the CHF resumes normal charging. For offline charging, any collected statistics up to this point are cleared. For online charging, new quotas and thresholds are monitored starting from this point onward, and any units consumed before or during failure handling are not accounted for.
- The MAG-c can enable a grace period after which the session is removed if a CHF connection cannot be reestablished by the time the period expires. Use the fh-session-continue-timer command to enable this functionality.
- If PCF functionality is enabled and the PCF has enabled the
CM_SES_FAIL trigger, the MAG-c triggers the Npcf_SMPolicyControl Update operation for any CHF HTTP 4xx error
with a cause code specified in the following table. The MAG-c maps the CHF cause code to a value included in the PCF creditManagementStatus
code IE. No PCF report is generated for any other cause codes or for 3xx or 5xx HTTP
errors.
Table 2. CHF cause code to PCF creditManagementStatus code mappings CHF cause code PCF creditManagementStatus code CHARGING_FAILED RATING_FAILED CHARGING_NOT_APPLICABLE CREDIT_CONTROL_NOT_APPLICABLE USER_UNKNOWN USER_UNKNOWN END_USER_REQUEST_DENIED END_USER_SERVICE_DENIED END_USER_REQUEST_REJECTED END_USER_SERVICE_DENIED
Configure the commands for the preceding actions in the following context.
configure mobile-gateway profile charging ccfh-profile
- For any result code except QUOTA_MANAGEMENT_NOT_APPLICABLE, traffic for that RG is blocked, as if online charging is enabled with a TERMINATE action and quota are exhausted.
- For the QUOTA_MANAGEMENT_NOT_APPLICABLE result code, traffic is still forwarded but only offline charging is applied, even if the local configuration or PCF indicated that online charging should be performed.
- If PCF functionality is enabled and the PCF has enabled the CM_SES_FAIL trigger,
the MAG-c triggers the Npcf_SMPolicyControl Update operation for the result codes
specified in the following table. The MAG-c maps the RG result code to a value included in the PCF creditManagementStatus
code IE. No PCF report is generated for any other result code.
Table 3. CHF RG result code to PCF creditManagementStatus code mappings CHF result code PCF creditManagementStatus code RATING_FAILED RATING_FAILED QUOTA_MANAGEMENT_NOT_APPLICABLE CREDIT_CONTROL_NOT_APPLICABLE USER_UNKNOWN USER_UNKNOWN END_USER_SERVICE_DENIED END_USER_SERVICE_DENIED END_USER_SERVICE_REJECTED END_USER_SERVICE_DENIED