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 and octet accounting, one for NAT port block logging, and one for session create and delete logging.

To configure BNG charging profiles, use the following command.

subscriber-management profiles charging-profile

To use a BNG charging profile for a specific set of sessions, use the following command.

subscriber-management authentication-database entry charging profiles

Except for the communication with the MAG-u, 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.

The cMAG-c tries to optimize the number of messages sent in the communication with the MAG-u. For example, if the same event triggers multiple charging profiles to fetch MAG-u data, the cMAG-c attempts to send a single request to the MAG-u instead of a request per charging profile.

Caution: The cMAG-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 server selection profile.

Statistics collection from the MAG-u

Configure the pull or push model to fetch mid-session PFCP usage reports from the MAG-u.

A PFCP Usage Report IE contains incremental MAG-u statistics per session. The usage report includes only statistics collected since the previous usage report. The cMAG-c aggregates the statistics for the session. This incremental method is robust and can handle a MAG-u failure. When a MAG-u failure occurs, statistics collected since the previous report are lost. However, the cMAG-c statistics remain correct and increase monotonically. Similarly, when MAG-u resiliency is used, the cMAG-c can add counters of both MAG-u nodes to calculate the correct aggregate.

The cMAG-c supports two models to fetch mid-session PFCP usage reports:

pull model
The cMAG-c explicitly requests a usage report in a PFCP Session Modification Request message when it needs up-to-date counters. The cMAG-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 MAG-u sends an unsolicited PFCP Usage Report IE in a PFCP Session Report Request message. Upon receiving this message, the cMAG-c records and stores the statistics. The push message does not directly 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, Volume-based charging.
The unsolicited usage report is periodic. The MAG-u sends a report within a fixed interval. If another report was generated (for example, pull-based), the interval is reset.
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.

subscriber-management authentication-database entry charging up-statistics-collection push-interval

A small push interval can reduce counter loss in case of MAG-u failures but increases the load on the cMAG-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 6 h (pull mode) and the MAG-u reporting is enabled with an interval of 15 min (push mode). Every six hours, the RADIUS accounting message triggers an explicit pull from the MAG-u to fetch the latest counters, while the MAG-u sends unsolicited usage reports every 15 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.

Note: The cMAG-c may optimize to not pull the stats if the current stats are very recent, for example, because of a push or other pull directly before the event that would cause a pull request. This optimization is however not guaranteed to occur in every instance.

For resilient sessions, the cMAG-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 cMAG-c can present these aggregated counters monotonically increasing to other interfaces such as RADIUS accounting, cMAG-c charging, and show commands. Because of MAG-u resiliency, back-end systems, such as accounting servers, do not need to account for sudden counter resets resulting from MAG-u failure.

In case of hot standby MAG-u resiliency, there are two PFCP sessions. When performing pull requests, the cMAG-c pulls statistics from the active MAG-u in steady state, because it does not expect traffic from the standby MAG-u. During switchovers, the cMAG-c pulls from both MAG-u nodes to fetch the potentially still available final statistics from a degraded MAG-u. The cMAG-c installs the push mode on both MAG-u nodes. The Nokia MAG-u, however, is optimized to only send push reports if the reported statistics contain non-zero values. The statistics of a standby MAG-u 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 MAG-u signals the measurement of number of packets (MNOP) function feature in the PFCP association procedure
detailed statistics as collected by the Nokia MAG-u

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 MAG-u QoS stat-mode configuration.

Detailed statistics are collected and available for reporting if the detailed-statistics is enabled (set to true) in the ADB using the following command.

subscriber-management authentication-database entry charging up-statistics-collection detailed

When enabled, the cMAG-c requests the MAG-u 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.

subscriber-management profiles charging-profile radius session include-attributes detailed-statistics

When the cMAG-c detects a new stat-mode or SLA Profile, the detailed statistics are reset. The cMAG-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 MAG-u, 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 SLA profile instance (SPI) per session model on the MAG-u.

cMAG-c-based charging

Learn about time-based and volume-based charging.

Time-based charging

The cMAG-c provides time-based charging using the session timeout mechanism. This session timeout starts after successful authentication. The cMAG-c deletes the session when the timer expires.

Volume-based charging

For basic volume-based charging, the cMAG-c compares the statistics to provisioned thresholds. The cMAG-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 following commands.

subscriber-management authentication-database entry charging cp-volume-tracking total
subscriber-management authentication-database entry charging cp-volume-tracking uplink
subscriber-management authentication-database entry charging cp-volume-tracking downlink

The threshold values can also be provided via RADIUS. For more information, see cMAG-c RADIUS Attributes and IU Triggers.

As soon as one of the provisioned thresholds is reached, the cMAG-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 cMAG-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 server selection profile
The RADIUS server selection profile provides the list of RADIUS servers and load-balancing parameters.
Use the following command to reference the RADIUS server selection profile in the BNG charging profile.
```
subscriber-management profiles charging-profile radius server-selection-profile
```
Use the following command to define and configure the RADIUS server selection profile.
```
subscriber-management profiles radius-server-selection-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 commands in the following context for the session accounting parameters.
```
subscriber-management profiles charging-profile radius session
```

For more information about the accounting attributes, their content, the associated include-attribute configuration, and the messages they can appear in, see the cMAG-c RADIUS Attributes and IU Triggers and the cMAG-c Data Model Reference Guide.

Enabling RADIUS accounting

Define a charging profile.

subscriber-management profiles charging-profile

Configure RADIUS accounting for the BNG charging profile.
```
subscriber-management profiles charging-profile radius
```

Reference the BNG charging profile.

subscriber-management authentication-database entry charging profiles

Define match criteria for the ADB so that the BNG charging profile gets assigned to a session during authentication.

Session accounting

The cMAG-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 cMAG-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 MAG-u 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.

subscriber-management profiles radius-server-selection-profile

When the stickiness command in the preceding context is set to true, subsequent messages are sent to the same server. When the selected server fails, a new server is selected. When the stickiness command is set to false, load-balancing is applied to each accounting message.

After accounting is started, the cMAG-c sends Accounting Request Interim Update (IU) messages. The cMAG-c sends the IU messages periodically or based on triggers.

When the session is removed, the cMAG-c sends an Accounting Request Stop message, including the final counters.

Periodic interim updates

Periodic sending of Accounting Request IU messages is on by default and can be optionally disabled using the following command.

subscriber-management profiles charging-profile radius session update-triggers periodic

When the periodic sending is enabled, the interval for the Accounting Request IU 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
```
subscriber-management profiles charging-profile radius default-interim-update-interval
```
Note: Changing the value by using this command updates existing sessions after the next scheduled Accounting Request Interim Update message. This command does not establish an interim update interval for sessions that do not already have one, because there is no scheduled IU message to trigger the change.

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 IU message with the reason Interval-Changed and starts a timer with the new interval.

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 cMAG-c runs a common interval timer, and sends only one message per periodic interim update interval to fetch the statistics from the MAG-u for all the periodic Accounting Request IU messages.

Triggered interim updates

The cMAG-c sends a triggered Accounting Request 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 cMAG-c RADIUS Attributes and IU Triggers for information about supported trigger events.

When several trigger events occur at the same time, the cMAG-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 cMAG-c retries RADIUS accounting messages using the configuration of the following commands.

subscriber-management ref-points aaa radius server retry-count
subscriber-management ref-points aaa radius server retry-timeout

If no accounting response is received after the retries, the cMAG-c buffers the accounting messages to retransmit them later, if buffering is enabled.

To enable buffering of accounting messages, use the following command.

subscriber-management profiles charging-profile radius buffering

When buffering is enabled, the cMAG-c can buffer one Accounting Stop message per session. Optionally one Accounting Start, and up to five IU messages can be buffered.

To enable buffering of the Accounting IU messages, use the following command.

subscriber-management profiles charging-profile radius buffering interim-update

To enable buffering of one Accounting Start message per session, use the following command.

subscriber-management profiles charging-profile radius buffering start

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 following command.

subscriber-management profiles charging-profile radius buffering lifetime

The cMAG-c classifies the Accounting IU 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 IU messages or in the Accounting Stop message. For example, a periodic IU message contains only updated cumulative counters that are also present in a subsequent IU or Stop message. When buffering of the IU messages is enabled, the following rules apply:
- Only the last non-critical IU 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 IU 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 IU messages is enabled, up to four critical IU messages per session are buffered to prevent loss of data.

Periodic IU messages are non-critical messages. Triggered IU 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.

Sending Accounting-On and Accounting-Off messages

cMAG-c supports sending Accounting-On and Accounting-Off messages to a RADIUS server based on the configuration.

Enable sending Accounting-On and Accounting-Off messages to mark the start and end of accounting toward the RADIUS server.

Note: Because the cMAG-c is a cloud-native solution and individual components can be restarted any time, there is no support for the traditional boot, reboot, and shutdown triggers for Accounting-On and Accounting-Off messages as mentioned in RFC 2866.

Create and configure a RADIUS server.
Note: Do not commit the configuration yet, because the cMAG-c does not generate Accounting-On messages for an already configured server.

Use the commands in the following context.
```
subscriber-management ref-points aaa radius server
```

Enable Accounting-On and Accounting-Off messages.

subscriber-management ref-points aaa radius server accounting-on-off true

Commit the configuration for the new server.
```
commit
```
Note: Setting the accounting-on-off configuration to true after the server is initially created does not result in the generation of an Accounting-On message.

The cMAG-c sends Accounting-On messages to the RADIUS server until the RADIUS server acknowledges the message.
When the server is removed from the system, for example by deleting the server configuration, the cMAG-c sends a single Accounting-Off message to the deleted server.