2 Generating 5G Unrated CDRs with CHF and CGF
Learn about the architecture, processing flow, and capabilities used to generate 5G unrated Call Detail Records (CDRs) in Oracle Communications Elastic Charging Engine (ECE) composable services.
Topics in this document:
About the 5G Unrated CDR Generation Process
The ECE Charging Manager (CHF) and Charging Gateway Function (CGF) composable services can generate unrated CDRs for 5G charging requests and make them available to downstream systems for charging, billing, analytics, mediation, and reporting. These charging requests can include activities such as data sessions, SMS usage, voice calls, or other 5G network options.
During request processing, the ECE CHF and CGF composable services capture charging information, such as subscriber details, session information, timestamps, usage metrics, and charging context. The ECE CHF and CGF composable services format this information as standardized 3GPP-compliant charging records to support consistency and interoperability with external systems.
The ECE CHF and CGF composable services can generate partial CDRs during an active session, final CDRs when a session closes, or both, depending on the deployment. The ECE CGF composable service aggregates related charging requests into complete session-based records and handles duplicate events, out-of-sequence messages, and missing sequence numbers during processing.
The ECE CHF and CGF composable services publish the generated CDRs to Kafka topics for downstream consumption. External systems can consume these CDR streams independently for further processing and integration.
Architecture Overview and Components
The ECE CHF and CGF composable services use a modular, event-driven architecture to support usage event intake, CDR generation, persistence, and downstream consumption. This architecture consists of independently deployable services running in a Kubernetes environment. This approach supports scalability, high availability, and flexible integration with external systems.
The key components of the architecture include:
-
Network functions: External 5G components, such as the Session Management Function (SMF), that generate charging requests and interact with the charging system.
-
Charging Manager (CHF): Publishes received charging requests to Kafka as unrated events for downstream unrated CDR processing.
-
Event streaming layer (Kafka): Enables asynchronous communication and separates upstream and downstream components.
-
Charging Gateway Function (CGF): Consumes unrated events, generates and aggregates CDRs, and ensures data consistency.
-
Persistence layer (cnDBTier): A storage layer used for durability, intermediate data storage, and retry handling and georeplication of CDR data and CDR metadata.
-
Downstream consumers: External systems such as billing, mediation, or analytics platforms that consume CDRs for further processing.
Figure 2-1 shows the high-level architecture of ECE composable services and their major components.
Figure 2-1 ECE Composable Services Architecture Overview
Note:
In this architecture, Kafka 1 and Kafka 2 may be combined into a single Kafka deployment, or Kafka 2 may operate as an independent external component.
In Figure 2-1, you see how the ECE composable services transform charging requests into unrated 5G CDRs:
-
Network functions, like the SMF, generate charging requests and send them to the CHF.
-
The CHF processes these requests and produces unrated events.
-
The CHF publishes unrated events to Kafka.
-
The CGF consumes unrated events from Kafka and transforms them into structured CDRs.
During this stage, the CGF performs aggregation of partial records, handles duplicate and out-of-sequence events, and ensures the completeness and accuracy of the data. The CGF may also interact with the cnDBTier to store intermediate records and support retry mechanisms for reliable processing.
-
After processing, the CGF publishes unrated CDRs back to Kafka, making them available to downstream systems.
These systems consume the CDRs for purposes such as charging and billing.
About the Network Functions
Network functions are external 5G components that generate charging requests and interact with the charging system. In the ECE composable services architecture, the SMF generates charging requests associated with subscriber activities such as data sessions, session updates, and session termination requests. These requests are sent to the CHF composable service for charging and processing.
The NRF supports service discovery and communication between network services within the 5G environment.
About the CHF Composable Service
The CHF composable service receives charging requests from 5G network functions and publishes the request information for downstream unrated CDR processing.
About the Kafka Layer
The Kafka layer acts as the messaging backbone for transporting unrated events and unrated CDRs across the system. It enables asynchronous communication between components and allows upstream and downstream services to scale independently while maintaining reliable message delivery.
After processing charging requests, the CHF publishes unrated events to Kafka for downstream CDR processing. The CGF consumes these events, generates unrated CDRs, and publishes the resulting records back to Kafka for consumption by downstream systems.
Downstream systems can subscribe to these CDR streams for billing, mediation, analytics, and reporting purposes.
ECE composable services also support flexible deployment topologies by allowing unrated events and unrated CDR streams to use either shared or separate Kafka clusters, depending on deployment requirements.
About the CGF Composable Service
The CGF composable service processes charging requests received from Kafka and generates standardized CDRs for downstream consumption. The CGF aggregates related charging requests into session-based records, detects duplicate events, handles out-of-sequence messages, and manages missing sequence numbers.
The CGF also provides durable retry capabilities to help prevent data loss during temporary infrastructure or communication failures. After processing completes, the CGF publishes the unrated CDRs to Kafka for consumption by downstream systems.
About the cnDBTier
The cnDBTier provides storage support for charging and CDR processing operations. It stores intermediate records, supports retry mechanisms, maintains processing state, and ensures reliable message handling during failures.
It helps prevent data loss when publishing or downstream communication errors occur. The CGF interacts with the cnDBTier to temporarily store CDR-related information during processing and retry operations.
The cnDBTier can also store session-related or processing metadata required for event handling. Background cleanup operations remove expired records after a configurable retention period to ensure efficient database management while still supporting late-arriving or duplicate events.
CDR Processing Capabilities
The ECE CHF and CGF composable services provide capabilities that improve the reliability, accuracy, and scalability of CDR processing in a 5G environment. These capabilities help ensure consistent processing even when records arrive as partial events, arrive out of order, are duplicated, or are affected by temporary infrastructure failures.
The ECE CHF and CGF composable services support these capabilities through advanced CDR processing features implemented primarily within the CGF and supported by the Kafka messaging and database persistence layers. This includes CDR aggregation, sequencing support, duplicate detection, operational monitoring, and durable retry to help prevent data loss. Together, these features improve the consistency and reliability of downstream billing, mediation, analytics, and reporting systems.
About CDR Aggregation
The ECE CHF and CGF composable services support CDR aggregation to combine partial records into consolidated and complete CDRs. Aggregation helps produce accurate records that represent the complete lifecycle of a subscriber session and reduces downstream processing complexity by providing consolidated records instead of fragmented usage events.
Since charging data can arrive as complete events or in multiple partial events over time, the CGF supports the following aggregation modes:
-
DEFAULT Aggregation Mode
In DEFAULT mode, the CGF combines partial records into a single aggregated CDR. This mode is useful when multiple updates belong to the same subscriber session, such as session initiation, usage updates, and session termination events.
-
INDIVIDUAL Aggregation Mode
In INDIVIDUAL mode, the CGF processes each record independently without aggregation. This mode is useful when each event must remain separate.
You can configure the aggregation mode based on your deployment requirements. See "Setting Up the CGF Worker Messaging Service" in ECE Composable Services Installation and Administration Guide for more information.
About Improved Sequencing
The ECE CHF and CGF composable services offer sequencing capabilities that help maintain the correct order of charging events and records during processing. In distributed systems, events may arrive in the wrong order due to component or network failures, network delays, retries, or asynchronous processing.
The CGF can detect out-of-order arrivals and correctly reconstruct the charging session using invocation sequence numbers. The system can detect gaps in sequence numbers, track out-of-sequence records, and identify when missing records are later received.
These capabilities ensure that charging records are assembled and processed in the correct order, improving the accuracy and reliability of downstream billing operations. The ECE CHF and CGF composable services also expose metrics related to sequence gaps and gap recovery for operational visibility.
Tracking and Monitoring Events
The ECE CHF and CGF composable services can monitor and track the health and status of charging and CDR processing operations. The system exposes metrics related to request processing, message consumption, publishing activity, processing failures, duplicate detection, sequence gaps, and closed CDR counts.
These metrics can be integrated with monitoring platforms such as Grafana and Prometheus to provide real-time visibility into system behavior. These metrics are essential for identifying processing bottlenecks, detecting failures, monitoring throughput, and troubleshooting charging-related issues. The ECE CHF and CGF composable services also standardize error handling and response mapping to improve operational consistency and diagnostics.
Detecting Duplicate CDRs
The ECE CHF and CGF composable services provide duplicate detection capabilities to prevent the generation and downstream distribution of duplicate charging records. In distributed systems, duplicate events are common. Sometimes the same charging record is sent multiple times due to retries, network failures, or repeated submissions from upstream systems. The CGF includes logic to detect these records and avoid processing them repeatedly.
The CGF identifies duplicate charging events using identifiers, sequence information, and session context during processing. Duplicate detection metrics are also exposed to support operational monitoring and analysis.
Avoiding Data Loss
The CGF composable service provides durable processing and retry mechanisms to prevent data loss during charging and CDR publishing operations. A background retry process periodically attempts to republish failed records until successful delivery is achieved.
This durability mechanism ensures reliable event delivery even during temporary infrastructure outages or communication failures. The persistence layer maintains retry metadata, timestamps, and processing state required for recovery operations. The CGF composable service also supports cleanup policies to remove expired records after configurable retention periods, ensuring efficient long-term storage management while preserving processing reliability.
Establishing Security for Kafka Communication
The ECE CHF and CGF composable services support secure communication with Kafka brokers using TLS-based authentication and encryption. This ensures that charging events, unrated events, and generated CDRs are transmitted securely between processing components and messaging infrastructure. Secure Kafka communication helps protect sensitive subscriber and charging data from unauthorized access or interception during transport.
To establish secure communication, the ECE CHF and CGF composable services integrate with Kafka deployments configured with TLS authentication, such as Strimzi-based Kafka clusters. A Kafka user is created within the Kafka deployment environment. This process generates the required user certificates and cluster Certificate Authority (CA) certificates. These certificates are then provided to the ECE CHF and CGF composable services through Kubernetes Secrets or local configuration files.
The Kafka client configuration includes secure communication properties such as the security protocol, TrustStore location, KeyStore location, and associated passwords. During deployment, the ECE CHF and CGF composable services mount the required certificate Secrets into the application containers and use them to establish encrypted connections with Kafka brokers. When secure communication is enabled, the messaging layer uses SSL/TLS for both authentication and encryption of all Kafka traffic.