CDR Aggregation Function

Every request received by SBA Gateway from the SMF results in the creation of a 5G event, also known as a network charging data record (CDR). To avoid sending excessive records to a downstream system, CDRs must be aggregated on a per session basis so that only summary level CDRs are sent to third-party CGF or the BSS domain. The CDR Aggregation Function (CAF) application is a Kafka Streams application that aggregates network interactions handled by SBA Gateway on the 5G N40 interface.

Based on the Individual Partial record mechanism outlined in TS 32.255, SBA Gateway streams an event to the Kafka topic for every network Interaction. The CAF aggregates network interactions of type ChargingDataRequest and ChargingNotifyRequest. All other interactions are ignored. The CAF can be configured to perform aggregation on the basis of volume, session termination, and the number of events per-session-per-rating-group. It can also be configured to aggregate these parameters based on just the session, that is, across all rating groups in a session. In the context of 5G charging requests, the sessionId is the ChargingDataRef returned to the SMF by the SBA Gateway.

Each event in the input topic is processed that meets the following filtering criteria:

  • The SessionId from the key is not null.
  • The request body is not null.
  • The event has an operationName of Nchf_ConvergedCharging_Create|Update|Release or Nchf_ConvergedCharging_Notify.
  • If the request if of type Nchf_ConvergedCharging_Notify, then check if the HTTP status code is not 204 (No-Content).

Any events that do not pass the filter criteria are ignored. Depending on the type of request, the following business logic is applied.

ChargingDataRequest Processing

Events of type ChargingDataRequest are processed in the following steps:

  1. If an aggregated record exists, it is found with the SessionId.
  2. If an aggregated record does not exist, a new record is created.
  3. Duplicate checking is performed. If the record is a duplicate, it is ignored.
  4. In case of a Create request or the start of an aggregation, the JSON body is copied into the aggregation record.
  5. In case of a record of type ChargingDataRequest-Update or Release, any newly received fields are copied from the JSON request body.
  6. Each multipleUnitUsage element from the list of multipleUnitUsage are processed in the request body. If no usedUnitContainer elements are found, the next multipleUnitUsage element is processed.
  7. For each usedUnitContainer element that is found, perform the following:
    1. For each rating group, the totalVolume is calculated, either based on the presence of the totalVolume field or if that is not present, the sum of uplink/downlink volumes. The aggregation record for that rating group is incremented with the volume.
    2. The interactions counter for that rating group is also incremented.

In session-based aggregation, if the sessionReleaseEnabled parameter is set to true, and if this is a ChargingDataRequest-Release, an aggregated record is created in the output topic and all aggregated counters are reset. If not, the total volume and total number of interactions are calculated. If either the accumulated volume or interactions in the aggregated record have breached their thresholds, an aggregated record is created in the output topic and the aggregated record counters are reset for this session.

In context-based aggregation, if sessionReleaseEnabled is set to true, an aggregated record is created in the output topic for each rating group that has been recorded in a state store for this session. If the session is not released, for each rating group in the aggregation record in the state store, check if thresholds have been breached and create an aggregated record in the output topic.

ChargingNotifyRequest Processing

Events of type ChargingNotifyRequest are processed in the following steps:

  1. If an aggregated record exists, it is found in the state store.
  2. If none is found, a warning is posted to logs indicating that this is a try to reauthorize a non-existent session.
  3. If an aggregated record is found, the session is released and an aggregated record is created in the output topic depending whether aggregation is session-based or volume-based.