Home
MATRIXX 5G Event Streaming
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 _glossary/cdr.html. 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.
Ordering of Events and Time Stamps
By default, Kafka streams CDRs in the order of the creation time, the time they are appended to the log. However, the CDR Aggregation Function (CAF) application uses a custom timestamp extractor to order the streamed events, based on invocationTimeStamp in the ChargingDataRequest. If the invocationTimeStamp is missing or is not in ISO 8601 format, the current milliseconds of the system time is used and a warning message is logged.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
MATRIXX Configuration
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
- About MATRIXX 5G Event Streaming
  MATRIXX 5G Event Streaming describes how to aggregate and stream charging data records (CDRs) from the SBA Gateway to an sFTP server using a Kafka broker.
- 5G Event Streaming Overview
  SBA Gateway can stream HTTP requests and MATRIXX Engine HTTP responses to a Kafka broker. The 5G event streaming applications convert the received JSON objects to ASN.1 binary format for export to Kafka applications and can optionally aggregate and route based on content. The GTP Prime Adapter microservice is provided for sending records from Kafka to a GPRS Tunneling Protocol (GTP) server.
- Converting CDRs to ASN.1 Format
  Charging data records (CDRs) are processed by the CDR ASN.1 Streamer Kafka client application to convert them from JSON into ASN.1 objects. After the ASN.1 objects are serialized as a binary message using Basic Encoding Rules (BER), they are placed in another Kafka topic for further processing. The ASN.1 sFTP Sink application then writes the message to file before transferring it over Secure FTP (sFTP).
- sFTP Sink Microservice Deployment
- ASN.1 Record Naming and Counting
  Each time the ASN.1 sFTP Sink application receives a batch of records, if the number of records is greater than or equal to the configured closure condition, the aggregated ASN.1 record is generated. Otherwise, the batch is held for the next ASN.1 record.
- 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 _glossary/cdr.html. 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.
  - Data Formats
    SBA Gateway can be configured to publish events to a Kafka topic for every Network interaction received on the N28 and N40 interfaces. The format of these events is JSON, and the key for these events is the ChargingDataRef.
  - Aggregated Record Key-Value Store Semantics
    The CDR Aggregation Function (CAF) application maintains a state store, which is a Kafka entity that holds state information for a stream processing application.
  - Handling Long or Orphaned Sessions
    A session is torn down sometimes by the SMF while the session and aggregation are still open in the CDR Aggregation Function (CAF).
  - Duplicate Checking
    Non-successful HTTP responses to a ChargingDataRequest received by the SMF can cause each SBA Gateway in a pair to publish the same failed request/response pair to the Kafka topic. The CDR Aggregation Function (CAF) application performs duplicate checking to prevent this.
  - Ordering of Events and Time Stamps
    By default, Kafka streams CDRs in the order of the creation time, the time they are appended to the log. However, the CDR Aggregation Function (CAF) application uses a custom timestamp extractor to order the streamed events, based on invocationTimeStamp in the ChargingDataRequest. If the invocationTimeStamp is missing or is not in ISO 8601 format, the current milliseconds of the system time is used and a warning message is logged.
  - Recording Information from a ChargingDataRequest for CDR Generation
    The primary function of the CDR Aggregation Function (CAF) application is to accumulate the values of volume and the number of interactions from incoming ChargingDataRequest CDRs for a session. Another function is to save fields from the request so that they can be used for mapping to fields of the eventually generated CDR.
  - Time and Change Condition Based Aggregation
    The CDR Aggregation Function (CAF) can be configured to produce an aggregated CDR periodically, at the end of the day, or in response to a change condition threshold trigger.
  - Aggregation Examples
    Aggregation is controlled by configuration properties shown in these examples.
  - Scalability
    When a CDR Aggregation Function (CAF) application instance starts, it registers its applicationId with Kafka. All instances of the CAF application must share the same applicationId to achieve coordination among the application instances.
  - Logging
    The CDR Aggregation Function (CAF) application uses the standard slf4j+log4j framework for logging messages related to application processing. The log4j2.xml file can be configured using standard log4j options to either log to a file or standard output.
  - CAF Metrics
    Prometheus can be used to monitor the CDR Aggregation Function (CAF) application and the Kafka cluster.
  - REST API Endpoints
    A REST API can be used to query the processing status of the CDR Aggregation Function (CAF) application.
- Content-Based CDR Routing
  The CDR Kafka router republishes each _glossary/cdr.html based on its content, either as received or enriched with additional data on a conditional basis.
- Write To Disk
  When Kafka is unavailable, the producer continues attempting to send to the Kafka broker until a timeout is reached. On timeout, the records are written to a separate log file on disk.
- Record Formats and Schemas
  Request and response records are sent in JSON format.
- Kafka Partition Key
  The Kafka partition key used is the SessionId for the exchange. If none is available, for example if there is an error returned by the engine, then no partition key is used.
- Installing 5G Event Streaming Applications
  The 5G event streaming applications are delivered as images for container creation in a Kubernetes cluster using a Helm chart. The following sections describe the installation process. The procedures assume you have knowledge of and access to the kubectl tool.
- Configuring 5G Event Streaming
  Configure 5G event streaming by providing values for properties in one or more Helm values files.
- Configuring the Applications
  The 5G event streaming applications are configured in the Helm values file, the nf.yaml file, and an application.yaml files for each application.
- Applying Configuration
  You can apply configuration for 5G event streaming applications in several ways using the Helm values chart. These methods are not mutually exclusive and can be used together.
- Appendixes
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

Ordering of Events and Time Stamps

By default, Kafka streams CDRs in the order of the creation time, the time they are appended to the log. However, the CDR Aggregation Function (CAF) application uses a custom timestamp extractor to order the streamed events, based on invocationTimeStamp in the ChargingDataRequest. If the invocationTimeStamp is missing or is not in ISO 8601 format, the current milliseconds of the system time is used and a warning message is logged.

Note: The CAF records if a session has been released. In the unlikely scenario that an update is received after a session has been released, the update is written out as an individual CDR.