Accounting and charging

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 config>mobile>profile>charging context. To use a BNG charging profile for a specific set of sessions, use the bng-charging-profile command in the config>mobile>profile>adb>entry>charging context.

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 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. A usage report only includes statistics that are 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, the statistics collected since the previous report are lost. However, the MAG-c statistics remain correct and increase monotonically. Similarly, when the BNG-UP resiliency is used, the MAG-c can add counters of both BNG-UPs to calculate a 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 periodically sends an unsolicited PFCP Usage Report IE in a PFCP Session Report Request message. On reception of the message, the MAG-c records and stores the statistics but does not take any further action.
Figure 2. Statistics collection using the push model

To enable the 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 to disable 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 for 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 optionally 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 are enabled 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 are 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 config>mobile>profile>adb>entry>charging context.

The threshold values can also be provided via RADIUS. For more information, see CMG BNG CUPS RADIUS Attributes.

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. Any configuration that defines attribute content such as configuration by the radius-avp-options command and the calling-station-id command is ignored. Failure handling configuration is not supported for BNG RADIUS charging and is also ignored. For more information about generic RADIUS support, see 7750 SR MG and CMG Configuration Guide, section RADIUS Interface.
Use the radius-group command in the config>mobile>profile>charging>bng>radius context to reference the RADIUS group in the BNG charging profile.
Use the radius-group command in the config>mobile>profile context to define and configure the RADIUS group parameters.
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 config>mobile>profile>charging>bng>radius context for the session accounting parameters.

For more information about the accounting attributes, their content, the associated include-attribute configuration, and the messages they can appear in, see CMG BNG CUPS RADIUS Attributes.

Enabling RADIUS accounting

Define a BNG charging profile.
Use the bng-charging command in the config>mobile>profile>charging context.
Configure RADIUS accounting for the BNG charging profile
Use the radius command in the config>mobile>profile>charging>bng-charging context.
Reference the BNG charging profile.
Use the bng-charging-profile command in the config>mobile>profile>adb>entry>charging context.
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, is a new server 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:

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

Note: Nokia recommends to provision 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 the 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 config>mobile>profile>radius context. 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 config>mobile>profile>radius-group context.

If buffering is enabled, you must not enable support of session deletion when the configurable amount of accounting interim retries is exhausted, that is, do not execute the delete-session-acct-interim-exh command in the config>mobile>pdn>radius context.

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 config>mobile>profile>radius-group>accounting-buffer context.

To enable buffering of one Accounting Start message per session, use the start command in the config>mobile>profile>radius-group>accounting-buffer context.

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 config>mobile>profile>radius-group>accounting-buffer context.
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.