1 Overview of the ECE Composable Service Deployment
The Oracle Communications Elastic Charging Engine (ECE) composable services are deployed in a containerized and orchestrated deployment architecture.
For more information about the ECE composable services, see ECE Composable Services User's Guide.
Topics in this document:
About Deploying the ECE Composable Services
The ECE composable services are deployed in a cloud native environment. They support a Kubernetes-orchestrated containerized multiservice architecture to facilitate continuous integration, continuous delivery, and DevOps practices.
The ECE composable services support the following deployment models:
-
On Private Kubernetes Cluster: The ECE composable services can run on a general deployment of Kubernetes.
-
On Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE): The ECE composable services can run on Oracle's hosted Kubernetes OKE service.
-
On Oracle Cloud Native Environment: The ECE composable services can run on the Oracle Cloud Native Environment.
ECE Composable Services Architecture
In the ECE composable services architecture, each service runs as a container and is deployed as a Kubernetes pod, which is the fundamental building block of Kubernetes. The services can be deployed and managed as multiple replicas within a Kubernetes replica set.
About the ECE Composable Service Pods
Table 1-1 lists the ECE composable service pods, their containers, and the services exposed through them.
Table 1-1 ECE Composable Service Pods
| Pod Name | Admin Port | Container Port | Service Type (Default) |
|---|---|---|---|
|
cgf-coordinator |
8081/TCP |
NA |
ClusterIP |
|
charging-gateway |
8081/TCP |
NA |
ClusterIP |
|
nchf-converged-charging |
8081/TCP |
8080/TCP |
ClusterIP |
|
nchf-nrf |
8081/TCP |
NA |
ClusterIP |
About the ECE Composable Service Processors
The ECE composable services use a processor-based framework to control how requests are handled. Processors define the individual steps that a service performs on events or records as they move through its pipeline. Each processor performs a specific function within the request-processing pipeline, such as mediation, transformation, or logging. By combining processors into a processing chain, you can control how a service handles incoming events and prepares them for downstream systems.
Processors run sequentially within a service. The output from one processor becomes the input to the next processor in the chain. This modular approach allows you to customize processing behavior while keeping the configuration flexible and easier to maintain.
Table 1-2 lists the processor types supported by the ECE CHF and CGF composable services.
Table 1-2 Processor Types Used by ECE Composable Services
| Processor Type | Composable Services that Use It (by Default) | Description |
|---|---|---|
|
AGGREGATOR_PROCESSOR |
CGF |
This processor aggregates unrated events into unrated 5G CDRs based on the configured partial-record method. The processor also detects duplicate events, missing invocation sequence numbers (ISNs), and out-of-order events during processing. Use this processor as the primary mechanism for generating unrated 5G CDRs from incoming unrated events. |
|
CLOUDEVENT_LOGGER |
CGF |
This processor writes CloudEvent payloads to the application logs for debugging and operational analysis. The processor does not transform or publish the event. Use this processor to inspect CloudEvent data as it moves through the processing pipeline. |
|
COMPOSITE_PROCESSOR |
CGF and CHF |
This processor groups multiple processors into a single logical processing chain. Use this processor to organize related processing steps, such as deduplication and publishing, within a unified workflow. This processor simplifies configuration and improves pipeline maintainability. |
|
DEDUP_PROCESSOR |
CGF |
This processor detects and suppresses duplicate events based on a configured deduplication key and time window. It helps prevent duplicate processing that can occur because of retries, retransmissions, or at-least-once delivery semantics. Use this processor to improve data integrity and reduce duplicate downstream records. |
|
KAFKA_PUBLISHER_PROCESSOR |
CGF and CHF |
This processor publishes processed records to outbound Kafka topics for downstream consumption. It supports durable retry handling, message key generation, topic creation, and topic modification. Use this processor to provide reliable event delivery between ECE composable services, such as from CHF to CGF, and from the ECE composable services to external consumers, such as CGF delivery of rated and unrated CDRs to billing systems and other external consumers. |
|
LOGGING_PROCESSOR |
CGF and CHF |
This processor writes request and event details to the application logs to help operators monitor processing activity and troubleshoot issues. This processor does not modify the payload or affect message routing. Use this processor to improve operational visibility within the processing pipeline. |
|
MUTATOR_PROCESSOR |
CHF |
This processor applies request or response transformations by using configurable mutation rules and expressions. Use this processor for payload enrichment, normalization, or session identifier manipulation. |
|
NCHF |
CHF |
This processor is the core CHF orchestration processor responsible for evaluating charging requests, coordinating downstream processing, and managing charging workflow behavior. |
|
NCHF_LOGGING |
CHF |
This is a specialized logging processor for capturing and logging CHF request and response details. It is typically used for troubleshooting or request tracing. |
|
NCHF_REST_PROCESSOR |
CHF |
This processor forwards eligible online charging requests to the ECE HTTP Gateway for rating, quota management, and charging-session processing. It supports retry and circuit-breaker fault-tolerance policies. |
|
REST_PROCESSOR |
CHF |
This processor sends REST requests to ECE composable services or external services. It is commonly used for spending limit control integration and notification-related processing. |
Configure processors to run in the order that matches the logical flow of event processing. In most deployments, processors that inspect or validate data run first, processors that transform or aggregate data run next, and processors that publish or deliver data run last.
For example, a typical unrated 5G CDR pipeline in CGF uses the following order:
-
LOGGING_PROCESSOR: Logs incoming events for troubleshooting and operational visibility.
-
AGGREGATOR_PROCESSOR: Aggregates unrated events into unrated 5G CDRs and detects duplicates, gaps, and out-of-order events.
-
KAFKA_PUBLISHER_PROCESSOR: Publishes the unrated 5G CDRs to an outbound Kafka topic.
Using a clear processor order helps ensure predictable processing behavior, improves troubleshooting, and reduces the risk of duplicate or incomplete downstream records.