Accounting and charging

CHF peer discovery is implemented using a list of mechanisms in priority order.

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

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.

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

When offline charging is enabled for the session RG (see Charging sessions and rating groups), MAG-c creates a single URR to collect statistics from the FWA UP as described in Statistics collection from the BNG-UP.

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 session RG. If this trigger is not set, the MAG-c does not generate periodic offline reports, even if there are usage reports from 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.

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 choose to override the category for some triggers using the TriggerCategory IE. 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 trigger types are supported:

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

Some triggers can be set on either the session level or the RG level. This does not act as a hierarchical override, but as two separate sets of triggers. For example, it is possible to combine both effects by setting a TIME_LIMIT with a 10 minutes deferred reporting on the RG level, as well as a TIME_LIMIT with 1 hour immediate reporting at the session level. In this case, the MAG-c generates a usage report for that RG every 10 min but does not send it; after 1 hour, it sends an immediate report with both the current and deferred statistics.

Additionally, MAG-c also supports the FORCED_REAUTHORISATION trigger. This trigger is not preinstalled on the MAG-c, but explicitly triggered by the CHF itself via the Nchf_ConvergedCharging_Notify operation. In this operation the CHF indicates to either terminate charging by performing the Nchf_ConvergedCharging_Release operation, or to request an update using the Nchf_ConvergedCharging_Update procedure.

The following figure illustrates the call flow for a reauthorization of all RGs.

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.

Configure the commands described for these actions in the following context.

configure mobile-gateway profile charging ccfh-profile