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.
To configure BNG charging profiles, use the bng-charging command in the following context.
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.

Caution: The MAG-c guarantees unique charging identifiers (such as Acct-Session-Id) per session but not per profile and session. If the same servers are used in two profiles, the servers may not be able to distinguish between log events which leads to unpredictable behavior. Nokia recommends that you do not define multiple charging profiles with interfaces to the same set of servers; for example, two profiles using the same RADIUS group.

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.

    Figure 1. Statistics collection using the pull model
  • 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 model
      The 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.

    Figure 2. Statistics collection using the push model
To enable the periodic push model, configure the push interval using the following command.
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.

Note:

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.

Detailed statistics are collected and available for reporting if the detailed-statistics is enabled (set to true) in the ADB using the following command:
configure mobile-gateway profile authentication-database entry charging detailed-statistics
When enabled, the MAG-c requests the BNG-UP to send detailed statistics.
If detailed statistics are collected and available for reporting, they can be included in the RADIUS accounting messages. Use the following command to send detailed statistics in the RADIUS accounting messages.
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.

Note:

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
To configure the thresholds in the ADB, use the cp-volume-tracking command in the following context.
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

  1. Define a BNG charging profile.
    Use the bng-charging command in the following context.
    configure mobile-gateway profile charging
  2. Configure RADIUS accounting for the BNG charging profile
    Use the radius command in the following context.
    configure mobile-gateway profile charging bng-charging
  3. Reference the BNG charging profile.
    Use the bng-charging-profile command in the following context.
    configure mobile-gateway profile authentication-database entry charging
  4. 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.

The server selection for the Accounting Request Start message follows the generic load-balancing configured in the following context.
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

Periodic sending of Accounting Request Interim Update messages needs to be explicitly enabled using the following command.
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:

  1. during the session authentication; for example, using the RADIUS Acct-Interim-Interval attribute
  2. 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.
  3. 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.

Note: If during RADIUS authentication or CoA an Acct-Interim-Interval attribute with value 0 is sent, periodic interim updates are explicitly disabled. In this case, it is not possible to re-enable periodic interim updates for the session.
When multiple BNG charging profiles are configured, the periodic interim update interval can be provisioned or changed per BNG charging profile using the RADIUS Alc-Charging-Profile-Interim-Interval VSA.
Note: Nokia recommends provisioning the same interval for all charging profiles with periodic interim updates enabled. In this case, the MAG-c runs a common interval timer, and sends only one message per periodic interim update interval to fetch the statistics from the BNG-UP for all the periodic Accounting Request Interim Update messages.

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.

The MAG-c retries RADIUS accounting messages using the configuration of the acct-retry-count, acct-retry-timeout, and max-peer-reselections commands in the following context.
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.
To enable buffering of accounting messages, use the accounting-buffer command in the following context.
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.

To enable buffering of the Accounting Interim Update messages, use the interim-update command in the following context.
configure mobile-gateway profile radius-group accounting-buffer
To enable buffering of one Accounting Start message per session, use the start command in the following context.
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:

  1. Use the following command to configure a CHF ConvergedCharging client service.
    configure mobile-gateway pdn sba-client-services chf-client nchf-convergedcharging
  2. 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
  3. 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:

  1. 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.
  2. A charging profile NF ID list is used, if configured using the following command.
    configure mobile-gateway profile charging bng-charging chf chf-selection nf-id-list
    This command has the following purposes:
    • 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.
  3. 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:

  1. 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
  2. Create an ADB and configure it to match the CC value configured in step 1; see Authentication database for more information.
  3. 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
  4. 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:

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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.

Figure 3. Charging Session operations

Starting a charging session toward the CHF

To start a charging session toward the CHF, perform the following steps:

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

  2. 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.
  3. 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.

Table 1. Time sequence for an RG with 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

When online charging is enabled for an RG, the MAG-c requests initial quota units from the CHF. The CHF can reply in two ways:
  • indicate that quota management is not applicable
  • send initial quota units
When quota management is applicable, the CHF sends a combination of the following quota or thresholds:
  • 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
The MAG-c monitors the consumed units of the RG based on usage reports from the FWA-UP and takes the following actions:
  • 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.

  • 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 performs the following to expedite quota or threshold monitoring:
  • 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

When quota management is not applicable, the CHF sends the QUOTA_MANAGEMENT_NOT_APPLICABLE result code. The MAG-c takes the following actions:
  • 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_INTERVENTION
    This 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
Triggers can be set on the session level, the RG level, or both. At both levels, the triggers act as separate sets and do not hierarchically override each other. In the following example, both trigger levels are combined:
  • 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.
WARNING: The MAG-c ignores unsupported triggers. To prevent a change in behavior when these triggers are supported in a future release, Nokia recommends not enabling any unsupported triggers.
Although the FORCED_REAUTHORISATION trigger type is not preinstalled, it is supported on the MAG-c. The CHF explicitly triggers this trigger type via the Nchf_ConvergedCharging_Notify operation. In this operation, the CHF indicates one of the following actions:
  • 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.

Figure 4. CHF-triggered update

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
When the CHF session is successful, but the CHF returns an RG-specific result code that does not equal SUCCESS to indicate an RG-level error, the MAG-c performs the following actions:
  • 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