3 Integrating Composable Services with ECE Cloud Native

Learn about integrating the 5G charging capabilities of the Oracle Communications Elastic Charging Engine (ECE) Charging Manager (CHF) and Charging Gateway Function (CGF) composable services with an existing ECE cloud native deployment.

Topics in this document:

About Composable Services for 5G Charging

The ECE CHF and CGF composable services process 5G charging requests and generate charging records for downstream systems. They support session-based and event-based charging, online and offline charging flows, session management, charging request mediation, and CDR generation and processing within a scalable, event-driven architecture.

When integrated with an ECE Cloud Native deployment, the CHF and CGF composable services extend the existing charging system and provide processing, mediation, event streaming, and CDR handling capabilities while preserving the existing ECE charging environment.

Integrating Composable Services with ECE for 5G Charging

You can integrate the ECE CHF and CGF composable services into an existing ECE deployment to support real-time rating, quota management, spending limit control, and charging-event processing for 5G charging scenarios.

In this deployment model, the ECE CHF composable service serves as the public-facing Nchf endpoint for 5G converged charging and spending limit control requests. The CHF receives charging requests from 5G network functions, applies mediation and request-processing logic, evaluates online charging requirements, and routes eligible requests to the ECE Elastic Charging Server (ECS) component for rating and policy enforcement.

The integration also provides request and response mediation, session-aware charging request handling, Kafka-based event streaming, and unrated CDR generation through the ECE CGF composable service. ECS continues to serve as the primary charging engine responsible for real-time rating, quota management, balance management, and spending limit enforcement.

Architecture Overview

The key components of the integrated architecture for 5G charging functionality include:

  • CHF: Provides the public Nchf interfaces, performs request mediation and orchestration, evaluates online charging requirements, and routes charging requests to ECS.

  • HTTP Gateway: Provides the ECS bridge layer for request routing and asynchronous notification delivery.

  • ECS: Performs real-time rating, balance management, quota management, charging-session processing, and spending limit enforcement.

  • Kafka: Provides asynchronous event streaming and event distribution for charging workflows.

  • CGF: Consumes Kafka unrated events and generates unrated 5G CDRs.

    When enabled, it also consumes rated events and generates 4G and 5G rated CDRs. See "Integrating Composable Services with ECE for Rated Event Publishing" for more information.

  • NRF Management Agent: Registers CHF services with the Network Repository Function (NRF) and manages service discovery and health reporting.

Figure 3-1 shows the integrated architecture for the ECE CHF and CGF composable services and an existing ECE deployment for 5G charging functionality.

Figure 3-1 Integrated Architecture for 5G Charging



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 3-1, you see how the ECE CHF and CGF composable services and an existing ECE deployment work together for 5G charging:

  1. The SMF and PCF generate charging and spending limit control requests and notifications, while the NRF supports service discovery for charging-related network functions.

  2. The CHF processes these requests.

    The CHF acts as the public-facing Nchf endpoint and processes charging and spending limit control requests by validating subscriber information, managing session lifecycle operations, applying charging logic, and generating unrated events.

    The CHF also integrates mediation and transformation capabilities to normalize ingress charging and spending limit control requests and responses before further processing.

  3. The HTTP Gateway component acts as a bridge between the CHF and the ECS, forwarding charging requests requiring rating as well as spending limit control requests to ECS.

  4. The ECS processes these requests and generates charging decisions and 5G network notifications.

  5. The Kafka layer transports unrated events and 5G network notifications to downstream processing components.

  6. The HTTP Gateway bridge and Kafka messaging layer deliver the 5G network notifications to network functions, supporting asynchronous notification handling within the system.

  7. The CGF consumes the unrated events generated by the CHF and transforms them into structured CDRs.

    The CGF also interacts with the cnDB-Tier persistence layer to support durable processing, retry handling, and reliable message delivery.

  8. After processing, the CGF publishes generated unrated CDRs back to Kafka, making them available to downstream CDR consumer systems.

About ECS

ECS is the core real-time charging and rating engine in ECE. ECS processes high-volume charging requests, performs real-time rating, manages balances and quotas, and enforces spending limit control policies.

In an integrated CHF and ECE architecture, ECS processes charging and spending limit control requests that CHF forwards through the HTTP Gateway.

About the ECS Bridge

The ECS Bridge provides the integration layer between CHF and ECS. It uses the HTTP Gateway component to route eligible charging requests and spending limit control requests from the CHF to ECS for rating and charging.

The ECS Bridge allows CHF to provide 5G charging capabilities while continuing to use ECS as the primary real-time charging and rating engine.

In addition to request routing, HTTP Gateway supports asynchronous delivery of charging and spending limit notifications generated by ECS. It distributes notifications through Kafka-based event processing and delivers them to external 5G network functions by using the notification URIs associated with the charging or spending limit sessions.