Home
MATRIXX 5G Event Streaming
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.

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

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.

For example, a closure size condition of 200 KB causes a batch containing 1000 KB of data to generate one ASN.1 record. If the next batch has 201 KB of data, a second ASN.1 record is created. The first record is 1000 KB, and the second is 201 KB.

The fact that batches do not always have the same number of records can lead to ASN.1 records of different sizes and volumes with different file names that include the running count/file issued number (RC).

For example, assuming a closure size condition of 200 KB, a batch containing data for 1000 KB generates one ASN.1 record, but in recovery mode, there is no guarantee that the batch to reprocess is also 1000 KB. It might be 500 KB, generating two files to reprocess the original 1000 KB. Or, if two 500 KB batches were originally processed, creating two ASN.1 records, in recovery mode, the same data might be reprocessed as one 1000 KB batch generating only one ASN.1 record.

For more information, see the discussions about file closure control properties and conditions and the discussions about file naming.