Migrating the CHF and CGF Composable Services into an Existing ECE System

7 Migrating the CHF and CGF Composable Services into an Existing ECE System

You can migrate the Oracle Communications Elastic Charging Engine (ECE) Charging Manager (CHF) and Charging Gateway Function (CGF) composable services into an existing ECE multisite deployment to perform 5G rating and unrated CDR replication.

Topics in this document:

About Migrating CHF and CGF into an Existing ECE Deployment

You can deploy the ECE composable services in a standalone environment to generate 5G unrated CDRs. You can also integrate the ECE CHF and CGF composable services into an existing ECE cloud native deployment to support the following functions:

Generate 5G unrated CDRs: In this deployment model, the ECE CHF and CGF composable services replace the CDR Gateway and CDR Formatter components in the ECE cloud native deployment.
Perform quota-managed charging and spending limit control (SLC) processing: In this deployment model, the ECE CHF composable service is added to the ECE cloud native deployment. 5G clients send requests to the CHF rather than the HTTP Gateway.

The migration procedure assumes that the following conditions are met:

Two active sites are available, and traffic can be administratively redirected with negligible service impact.
Downstream consumers can process CGF-published unrated CDR payloads from the designated Kafka topics.
Kafka capacity and availability are sufficient at both sites.
Traffic consists of offline-only, quota-managed, or SLC processing requests.

Migrating CHF and CGF into an ECE Active-Active Deployment

Perform this procedure only when migrating the ECE CHF and CGF composable services into an existing ECE active-active deployment.

For clarity, the tasks in this document use the following terminology:

Primary Site: The site that processes all live traffic during the migration window.
Migrating Site: The site undergoing migration activities during the current migration cycle.

During the first migration cycle, the site roles are defined as follows:

Site 1 is the Primary Site.
Site 2 is the Migrating Site.

In the second migration cycle, the site roles are reversed.

The following sections describe the high-level tasks required to migrate CHF and CGF into an existing ECE active-active system:

Prepare and deploy the ECE composable services in each active ECE site. See "Preparing and Deploying Components".
Use simulator traffic and, optionally, a limited volume of friendly customer traffic during a controlled maintenance window, to send 5G offline-only charging requests to the CHF endpoint at each site. Then, do the following:
- Validate the end-to-end processing, aggregation, publication, and consumption of 5G unrated CDRs, including confirmation that all expected records are processed without data loss or duplication.
- Verify the replication status of the unrated CDR tables in the cnDBTier across Cluster 1 and Cluster 2.
- Confirm that the deployment meets the defined performance targets, including acceptable replication lag thresholds, throughput requirements, and system stability metrics.
Divert traffic away from the Migrating Site and disable HTTP Gateway and CDR generation. See "Redirecting Traffic and Disabling the HTTP Gateway-to-CDR Generation Flow".
Apply the endpoint migration changes to the Migrating Site. See "Applying Endpoint Migration Changes".
Enable the Migrating Site for live participation. See "Enabling Live Traffic Participation".
Validate the Migrating Site to confirm service availability, data consistency, and successful replication. See "Performing Canary Validation and Ramping Live Traffic".
Repeat the migration cycle for the remaining site. See "Repeating the Migration Cycle".
Restore the normal active-active traffic distribution configuration. See "Restoring Active-Active Traffic Distribution".
Scale down the CDR Gateway and Formatter components. See "Scaling Down CDR Gateway and Formatter Components".

Preparing and Deploying Components

Perform the following steps at each active ECE site before migrating live 5G charging traffic to the ECE CHF and CGF composable services:

Deploy the ECE CHF and CGF composable services in each active ECE site. See "Deploying the ECE Composable Services".

Ensure that the deployment includes the CGF cnDBTier database and verify that all CHF, CGF, and cnDBTier pods reach the READY state before proceeding.
In the nfProfile ConfigMap (configmap-nfprofile.yaml), set the nfStatus attribute to UNDISCOVERABLE:
```
"nfStatus": "UNDISCOVERABLE"
```
This setting prevents other NF services from recognizing and routing network traffic to the CHF.

Note:

If the NRF is not used to control the NF network traffic flow to the CHF, defer bringing up the CHF until the traffic is ready to be restored.
Configure the CHF producer and CGF consumer for the internal 5G CHF-to-CGF unrated event messaging topic.

Verify that the messaging topic configuration is identical across both sites and confirm that producer and consumer connectivity is operational before enabling traffic processing.
Configure the CGF Kafka producer cluster and topic for external publication of 5G unrated CDRs.

Ensure that the Kafka bootstrap server configuration, topic names, authentication settings, and replication parameters are validated before enabling traffic processing.
Enable CGF cnDBTier replication between the active sites.

Verify that database replication initializes successfully and that replication status remains healthy before proceeding with traffic validation activities.
During the migration window, do not republish pricing data from PDC for updated or newly created offers and price plans.

The ReplicatedFederatedCache federated service manages pricing caches across the active sites. Republishing pricing data during the migration window can cause inconsistencies between the active sites and may result in inconsistent charging behavior.

Redirecting Traffic and Disabling the HTTP Gateway-to-CDR Generation Flow

Perform the following steps to redirect live traffic to the Primary Site, prevent new traffic from reaching the Migrating Site, and safely disable the HTTP Gateway-to-CDR generation flow before enabling CHF-based processing.

Move all 5G network traffic processing to the Primary Site using operator-defined procedures.

Before proceeding to the next step, ensure that the Migrating Site is not processing any 5G network traffic.
In your override-values.yaml file for oc-cn-ece-helm-chart, set the skipActiveActivePreferredSiteRouting key to true only if the current value is false. Then, run the helm upgrade command to apply the change.

Note:

This configuration change is required only during the first site migration cycle.
Stop ReplicatedFederatedCache federation between the Migrating Site and the Primary Site.

Verify that cache synchronization activity from the Migrating Site has stopped before continuing.
Disable CDR generation on the Migrating Site by setting the following key in the override-values.yaml file for oc-cn-ece-helm-chart. Then, run the helm upgrade command and restart the affected composable services, if required.
```
cdrGenerationEnabled: false
```
At the Migrating Site, ensure that the active CDR Formatter processes all pending CDR records.

Before continuing, verify that no unprocessed CDR records remain in the ECE tables and that all queued CDR records have been successfully formatted and delivered.
At the Migrating Site, verify the HTTP Gateway registration status in the NRF. If the NRF still shows the service as registered, deregister the HTTP Gateway entry.
In the override-values.yaml file for oc-cn-ece-helm-chart, remove the nrfRestEndPointUrl configuration from the HTTP Gateway deployment. Run the helm upgrade command to apply the change.

This configuration change prevents the HTTP Gateway from sending NRF heartbeat requests.
Restart the HTTP Gateway deployment.

After the restart completes, verify that the HTTP Gateway no longer sends heartbeat requests and that the NRF deregisters the service successfully.

Applying Endpoint Migration Changes

Perform the following steps to transition external charging traffic handling from the HTTP Gateway to the CHF deployment at the Migrating Site.

At the Migrating Site, configure the CHF deployment as the public nCHF endpoint.
- Replace the HTTP Gateway endpoint configuration with the CHF endpoint configuration so external network functions route charging requests directly to the CHF service.
- Verify that the NRF registration information, service endpoint configuration, ingress settings, and load balancer mappings correctly reference the CHF deployment.
At the Migrating Site, configure the ECE HTTP Gateway bridge information for the CHF deployment.
- Ensure that the CHF configuration references the appropriate HTTP Gateway bridge endpoints and communication parameters required for ECS-generated notifications and related charging workflows.
- Verify that the bridge configuration supports the delivery of RAR and SLC notifications to the appropriate 5G network composable services.

Enabling Live Traffic Participation

Perform the following steps to enable the Migrating Site to receive live charging traffic.

Start ReplicatedFederatedCache federation between the Migrating Site and the Primary Site.

Verify that cache federation initializes successfully and that cache synchronization remains healthy before enabling live traffic participation.
In the NF Profile ConfigMap (configmap-nfprofile.yaml), set the nfStatus attribute to REGISTERED:
```
"nfStatus": "REGISTERED"
```
This setting re-enables NRF discovery after validation completes and allows live traffic to route safely to the Migrating Site.

Performing Canary Validation and Ramping Live Traffic

Perform the following steps to gradually introduce live traffic to the Migrating Site and verify system stability before restoring normal traffic distribution.

Redistribute a small percentage of live 5G traffic to the Migrating Site using operator-defined policies.

Use a limited traffic volume during the initial validation phase to minimize operational impact if issues occur.
Verify that the CHF, CGF, Kafka messaging, cnDBTier replication, and related charging services process traffic successfully without errors or abnormal performance conditions.

Monitor system metrics, logs, alarms, replication lag, throughput, latency, and resource utilization throughout the soak period.

Note:

Proceed only after the deployment remains stable throughout the defined soak interval.
Incrementally increase the amount of live traffic directed to the Migrating Site. Gradually adjust traffic-steering policies in controlled increments until the Migrating Site processes the planned production traffic volume.
Validate system stability after each traffic increase. Confirm that charging requests, unrated CDR generation, Kafka publication, notification delivery, and database replication continue to operate normally after each traffic increase.

Before proceeding to the next traffic increment, verify that no service degradation, abnormal latency, replication backlog, or message-processing failures have occurred.

Repeating the Migration Cycle

Perform the following steps to reverse the site roles and repeat the migration procedure for the remaining active site.

Verify that both sites are operating normally after federation restoration and live traffic ramp-up complete.
- Confirm that charging traffic processing, Kafka publication, cnDBTier replication, notification delivery, and cache federation operate successfully across both sites.
- Review system logs, alarms, dashboards, and replication metrics to verify that no critical errors or performance issues exist before continuing.
Swap the site roles for the next migration cycle:
- Site 2 becomes the new Primary Site.
- Site 1 becomes the Migrating Site.
Ensure that traffic-steering policies, NRF registration information, and operational procedures are updated to reflect the revised site roles before continuing.
Repeat steps 3 through 6 in "Migrating CHF and CGF into an ECE Active-Active Deployment" to migrate the remaining site and validate live traffic processing in the updated active-active deployment configuration.

Restoring Active-Active Traffic Distribution

Perform the following steps to restore the normal active-active traffic distribution model after both sites successfully complete the migration procedure:

In the override-values.yaml file for oc-cn-ece-helm-chart, set the skipActiveActivePreferredSiteRouting key to false only if you changed the value earlier during the migration procedure. After running the helm upgrade command, verify that the updated routing configuration is applied successfully across the deployment.
Incrementally redistribute live traffic across both active sites by adjusting the SMF and PCF traffic-steering configuration in controlled increments until the deployment reaches the normal production traffic distribution model.
Confirm steady-state traffic processing across both active sites. Verify that the CHF, CGF, Kafka messaging, cnDBTier replication, and cache federation services operate normally at both sites.

Confirm that charging requests, unrated CDR processing, notification delivery, and database replication complete successfully without errors or performance degradation. Review system logs, alarms, dashboards, throughput metrics, latency metrics, and replication status to confirm stable long-term operation across the active-active deployment.

Scaling Down CDR Gateway and Formatter Components

Perform the following steps after the migration procedure completes and both active sites successfully process live traffic through the CHF and CGF deployment:

Verify that the CGF processes all charging requests successfully. Perform the following validation activities:
- Confirm that unrated CDR aggregation, Kafka publication, notification processing, and downstream integrations operate normally at both active sites.
- Review system logs, dashboards, alarms, and Kafka topic metrics to verify that no processing failures or message backlogs exist.
Verify that no pending CDR records exist in the ECE tables at either site.
- Ensure that the active Formatter deployment processes and exports all remaining CDR records successfully before continuing.
- Confirm that no queued, partially processed, or failed CDR records remain in the system.
Scale down the CDR Gateway deployment at both active sites. Verify that all CDR Gateway pods terminate successfully and that no traffic continues to route through the legacy HTTP Gateway-to-CDR generation flow.
Scale down the Formatter deployment at both active sites.

After the scale-down operation completes, verify that the deployment no longer runs Formatter processing workloads and that all charging traffic continues to process successfully through the CHF and CGF deployment.