CDR Gateway now supports the following functionality on ECE systems using an Oracle NoSQL database. In previous releases, this functionality was supported only on persistence-enabled ECE deployments.

• Closing open CDR sessions when a termination request does not arrive within a configurable duration.

• Adding a custom reason value to a CDR's causeForRecordClosing field that specifies why a CDR session was closed.

You configure this functionality by using the enableIncompleteCdrDetection, enableStaleSessionCleanupCustomField, and staleSessionCauseForRecordClosingString fields in the ECE_home/config/management/charging-settings.xml file. For more information, see "Setting Up ECE to Generate CDRs" in ECE Implementing Charging.

The HTTP Gateway (CHF) now supports SSL encryption between it and the NRF, PCF, and SMF network functions. You can enable this secure communication during the ECE deployment process or afterward.

For more information, see "Securing Communication Between the CHF and NRF, PCF, and SMF" in BRM Cloud Native System Administrator's Guide

Diameter Gateway has been enhanced to support dual-stack IPv4 and IPv6 in CCR requests.

For more information, see ECE Diameter Gateway Protocol Implementation Conformance Statement.

BRM now synchronizes the currency balances for both parent and child accounts with ECE during wholesale billing that occurs at the end of a billing cycle.

For information, see "About Wholesale Billing" in BRM Configuring and Running Billing.

ECE now supports the cleaning of stale Sy sessions from the DiameterPersistenceSySession cache. When this functionality is enabled, ECE automatically removes stale Sy sessions each time it receives a request from the Diameter client to initiate a Spending Limit Request (SLR).

For more information, see "Cleaning Sy Sessions from the Cache" in the ECE Implementing Charging.

In active-active disaster recovery systems, any changes to the ECE cache on one site are automatically federated to the ECE cache on other sites. This federation process can lead to situations where concurrent updates to the same data in different sites results in conflicts. For example, Site 1 processes Joe's purchase of 500 prepaid minutes, and, at the same time, Site 2 processes Joe's usage of 20 prepaid minutes. ECE uses custom conflict resolution logic to merge these changes at both sites.

However, ECE may occasionally be unable to resolve these conflicts. When this happens, ECE now:

• Logs details about unresolved conflicts to the ECS log files, which are located in the ECE_home/logs directory.

• Tracks information about conflict resolutions in a new ECE metric. Table 6-1 outlines the metric introduced in the 15.1 release.

  Table 6-1 New Coherence Federated Service Metric

  Metric Name	Type	Description
  ece.federated.service.change.records	Counter	Tracks the number of change records and tags them by conflict classification type: notModified error alreadyConflictResolved internallyModified externallyModified sameBinary sameRevisionNumber deleted conflictDetected

  For more information, see "About Conflict Resolution During the Federation Process" in BRM System Administrator's Guide.

External Module (EM) Gateways now verify whether an Elastic Charging Server (ECS) cluster is healthy before forwarding requests to it. When the number of healthy nodes in an ECS cluster falls below the minimum configured threshold, the EM Gateway returns an error to the BRM server and stops forwarding requests to the ECS cluster.

For more information, see "Supporting External Module Gateways in Degraded Mode" in BRM System Administrator’s Guide.

Client applications can contain their own request timeouts that activate when ECE takes too long to respond. When this occurs, the client application abandons the request, but ECE may continue to process the request and send a response, which the client discards. This extra processing is unnecessary and can be detrimental to ECE production systems approaching overload conditions. To improve performance, you can now configure the HTTP Gateway and Diameter Gateway to terminate requests that have timed out on the client side.

For more information, see "Checking for Client-Side Timeouts in HTTP Gateway" and "Checking for Client-Side Timeouts in Diameter Gateway" in ECE Implementing Charging.

You can now customize ECE to apply a fixed charge even if the associated usage charge is zero, when a subscription's charge offer contains both a fixed charge and a usage charge. By default, ECE does not apply any charges if the usage charge is zero.

For more information, see "Customizing ECE to Apply Fixed Charge for Zero Usage" in ECE Implementing Charging.

The HTTP Gateway (CHF) now supports OAuth 2.0 authentication for 5G services. If this feature is enabled, the HTTP Gateway now only serves incoming requests from the network functions after validating the authentication of these requests. This applies to only 5G standalone REST APIs.

For more information, see "ECE REST API Security" in BRM Security Guide and REST API for Elastic Charging Engine.

New ECE Metrics along with updates to the existing metrics have been made. For more information, see "ECE Metrics" in BRM System Administrators Guide and "ECE Cloud Native Metrics" in BRM Cloud Native System Administrators Guide.

ECE now allows you to monitor Apache Kafka producer and consumer metrics.

For more information, see the following in BRM System Administrators Guide:

• About Monitoring Kafka Servers

• Kafka Client Metrics

HTTP Gateway (CHF) now supports 3GPP R17 for 5G services, alongside R16. This applies to 5G standalone (CHF) APIs only.

For more information, see REST API for Elastic Charging Engine.

RADIUS Gateway can now manage disconnect request messages, which are sent to immediately end a customer's usage session that is in progress.

For more information, see the following:

• "About RADIUS Gateway Disconnection" in ECE Implementing Charging

• "Configuring ECE and RADIUS Gateway to Manage Disconnect Requests" in ECE Implementing Charging

You can now customize the RADIUS Gateway to retrieve subscriber profile information, including customer and balance data, enabling its use for decision-making during the authentication process.

For more information, see "About RADIUS Gateway Authentication" in ECE Implementing Charging.

You can now configure primary and secondary SCP authorities for each HTTP Gateway instance in your system. This enables your system to send 5G traffic notifications for each HTTP Gateway instance.

For more information, see "Configuring Communication Through SCP" in ECE Implementing Charging.

You can now configure ECE to automatically renew granted allowances once the resources of the previous grant have been depleted. For example, you can automatically renew 5 free minutes after each consumption of 10 MB data. This enables continuous access to the granted resource without requiring manual renewal.

For more information, see "About Automatically Renewing Granted Allowances" in ECE Implementing Charging.

ECE now uses non-linear rating for all usage rating, but you can configure ECE to use linear rating for specified products or product-and-event combinations. In previous releases, the default was linear rating.

For information, see "About Linear and Non-Linear Rating" in ECE Implementing Charging.

The External Manager (EM) Gateway now supports the same load-balanced and active-passive failure modes previously only available for Data Managers (DMs).

In the CM pin.conf, you can now define a single em_pointer entry with multiple host and port pairs that will be tried in order when attempting to establish a connection (permitting active-passive semantics). This is in addition to the previous configuration with multiple em_pointer entries which allowed only load-balanced connection attempts (permitting active-active semantics).

Note that only one type of configuration may be used for a given EM, but different EM components may use either configuration type. For example, connections to ECE's EM Gateway might use active-passive logic, while connections to the Pipeline Manager might use active-active logic.

In a cloud native environment, you configure a service and port pair, where a Kubernetes service acts as a logical target for multiple components. In this model, you can connect to a preferred Kubernetes service (on, say, site 1), which would load-balance across several EMs configured on site 1. In this model, you can connect to a preferred Kubernetes service (on say, site 1) and that would load-balance across a number of EMs configured on site 1.

So, for cloud native, you can, in effect, mix HA and load-balanced configurations (although they are always configured as HA or load-balanced in the CM).

For more information on EM Gateway, see "Configuring ECE for High Availability" in BRM System Administrator's Guide.

You can now configure the order in which ECE consumes allowances from offers with the same priority. To do so, use the new offerSelectionModeOnEquiPriorityOffers entry in your charging-settings.xml file, values.yaml file, or ECE configuration MBeans. You can specify whether to consume allowances from offers based on the earliest validity start date or the earliest validity end date.

For information, see "Configuring the Consumption Order for Offers with the Same Priority" in ECE Implementing Charging.

In active-active disaster recovery systems, a prolonged Diameter Gateway outage on one site may cause Sy sessions to not re-anchor to the next available Diameter Gateway. This occurs because PCRF does not send update requests back to the available Diameter Gateway in the same deployment site or in another deployment site.

To fix this, ECE contains new JMX commands that instruct Diameter Gateway to:

• Start consuming from a specified partition ID

• Stop consuming from a specified partition ID

When one or more Diameter Gateway instances fail, you can use the JMX command to enable the active Diameter Gateway instance to start consuming from specific Kafka partitions for the failed Diameter Gateway instance.

For more information, see "Active-Active Sy/Gy Session Re-Anchoring" in BRM System Administrator's Guide.

You can now configure ECE to generate midsession-rated events when rating moves from one product to another for the consumption of resources. For example, assume a session consists of the following:

• Total Used Service Units (USU): 800 MB

• First 220 MB is rated using Product 1

• Next 500 MB is rated using Product 2

• Remaining 80 MB is rated using Product 3

In this case, ECE would generate the two midsession-rated events:

• CDR 1 for 220 MB

• CDR 2 for 500 MB

The remaining 80 MB being rated using Product 3 stays in the active session.

For more information, see "Generating Midsession-Rated Events for Charge Offer Changes" in ECE Implementing Charging.

Rated Event (RE) Formatter has been enhanced to continue processing events when temporary database connectivity issues occur.

Sometimes, database issues can cause database writes to fail while database reads succeed. This causes rated events to remain in the Coherence cache and not persist in the database. After the database issue is resolved, rated events in the cache are written to the database. However, the RE Formatter checkpoint for formatting rated events has already advanced, causing the rated events to be lost. This causes a data resiliency issue.

To fix this, RE Formatter now monitors the rated event persistence activity by ECS nodes. If persistence stops, RE Formatter pauses the checkpoint. Checkpoint advancing restarts only after:

• The database write issue is resolved

• The persistence backlog by the ECS nodes is cleared

You can now configure primary and secondary Network Repository Function (NRF) registration servers in HTTP Gateway. When a heartbeat to the primary NRF server fails, HTTP Gateway retries the heartbeat for a configurable number of times. If all retries fail, HTTP Gateway initiates a registration request on the secondary NRF server.

You configure one or more primary NRF servers using the existing nrfRestEndPointUrl MBean attribute, and you configure one or more secondary NRF servers using the new nrfSecondarySiteRestEndPointUrls MBean attribute.

To configure primary and secondary NRF registration servers:

1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans" in ECE Implementing Charging.

2. Expand the ECE Configuration node.

3. Expand charging.nfProfileConfigurations.

4. Expand Attributes.

5. Specify the value for the following attributes:

   • nrfRestEndPointUrl: Set this to the endpoint URL of one or more primary NRF servers. To configure multiple primary NRF servers, list the endpoint URLs, in order, separated by a comma (,).

   • nrfSecondarySiteRestEndPointUrls: Set this to the endpoint URL of one or more secondary NRF servers. To configure multiple secondary NRF servers for a primary, list the endpoint URLs, in order, separated by a semicolon (;). If you have multiple primary NRF servers and want to map each to a different secondary NRF server, separate the endpoint URLs by a comma (,).

     For example, the following specifies that the primaryNRF_1 NRF server has two secondary NRF servers (secondary_NRF_1 and secondary_NRF_2). The primaryNRF_2 NRF server has only one secondary NRF server (secondary_NRF_3):

     nrfRestEndPointUrl="www.primaryNRF_1.com,www.primaryNRF_2.com"
     secondaryNrfEndpointUrl="www.secondary_NRF_1.com;www.secondary_NRF_2.com,www.secondary_NRF_3.com"

For information, see "Configuring Multiple Primary and Secondary NRF Registration Servers" in ECE Implementing Charging.

By default, ECE consumes a customer's loan balance before consuming the customer's principal balance. You can now configure at the service level to consume the principal balance before consuming the loan balance. You might do this, for example, to prevent fraud by customers using their loan balance and leaving before paying it back.

For information, see "Customizing Consumption Order of Loan and Principal Balances" in ECE Implementing Charging.

By default, ECE temporarily stores information about direct debit requests in its cache to validate any refunds against one of the requests. However, some event types may not be eligible for refunds, so storing the direct debit request information in the cache is unnecessary. You can now configure ECE not to store direct debit requests in its cache for specific event types.

To prevent ECE from storing direct debit request information in its cache for specific event types:

1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans" in ECE Implementing Charging.

2. Expand the ECE Configuration node.

3. Expand charging.server.

4. Expand Attributes.

5. In the excludedEventsForDebitRefundSessions attribute, list the event types separated by commas.

For information, see "Managing Direct Debit Data in ECE Cache" in ECE Implementing Charging.

Rollover data is now included in the balance data synchronized from BRM to ECE. This allows ECE to include the rollover data in:

• In-session notifications sent to your customers

• Responses to balance queries sent from the ECE Java API

For information, see "About Balance Query Requests" in ECE Implementing Charging.

ECE now includes extensions for customizing the data contained in notification payloads. For example, add the subscriber ID and event time stamp to all notification payloads.

For information, see "Post-Update Extension - Enriching External Notifications" in ECE Implementing Charging.

ECE now includes extensions for writing any unrated quantity that occurs during offline charging to a CDR or notifications payload.

For information, see "Configuring ECE to Support Prepaid Usage Overage" in ECE Implementing Charging.

When ECE generates a midsession-rated event, it automatically records why the event was split in the event's midSessionCDRSplitReason field. ECE sets the field to one of the preconfigured reason codes in Table 6-2.

You can now extend ECE to add these preconfigured reason codes to midsession-rated events generated by custom criteria. To do so, you extend ECE at the pre-rating and post-rating extension points. For more information, see these ECE SDK sample programs: SamplePostRatingMidSessionExtension and SamplePreRatingMidSessionExtension.

For information, see "Viewing Reason for Midsession-Rated Event" in ECE Implementing Charging.

When changes in charging occur during an active session, ECE sends a reauthorization request (RAR) to the network. By default, ECE sends an RAR for all active sessions initiated by that subscriber.

You can now extend ECE to send RARs for all active sessions using a sharing group balance. For example, assume a sharing group includes accounts A, B, C, and D, and accounts A and C currently have active sessions using the sharing group balance. If an RAR is triggered for account C, ECE sends RARs for account A's and C's active sessions.

For more information about extending ECE to support RARs for sharing group members, see these ECE SDK sample programs: SampleRarPostChargingExtension, SampleRarPostRatingExtension, and SampleRarPreRatingExtension.

For information, see "Customizing Server-Initiated Reauthorization for Sharing Groups" in ECE Implementing Charging.

You can now extend ECE to retrieve the value of the isAdjustedForWorstCost parameter, which specifies whether to reserve the worst possible cost during the authorization process. To do so, you extend ECE at the post-rating and post-charging extension points.

For information, see "Customizing Worst-Case Rating Reservation" in ECE Implementing Charging.

By default, Diameter Gateway includes information about the main balance in balance query responses. You can now configure Diameter Gateway to include both the main and loan balance information in balance query responses.

To configure it to do so, in the ECE Balance Java API, set the balancequerymode to TURBO. For more information about balancequerymode, see the documentation for oracle.communication.brm.charging.messages.query in ECE Java API Reference.

When CDR generation is enabled, each site in an active-active system contains a CDR Generator, and each site can generate unrated CDRs for external systems. When one of the active sites goes down, the CDR database retains all in-progress CDR sessions, and subsequent 5G usage requests are diverted to another active site, which generates CDRs for those in-progress CDR sessions.

To prevent downstream mediation systems from processing the in-progress CDR sessions, you can now configure CDR Generator to mark them as incomplete.

To enable CDR Generator to detect and mark CDRs as incomplete:

1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans" in ECE Implementing Charging.

2. Expand the ECE Configuration node.

3. Expand cdrFormatters.

4. Expand Attributes.

5. Set the enableIncompleteCdrDetection attribute to true. The default value is false.

For information, see "Generating CDRs for External Systems" in ECE Implementing Charging.

CDR Gateway can now detect and mark the following:

• CDR sessions that fail because a production site went down in an active-active disaster recovery system. When this feature is enabled, CDR Generator adds the causeForRecordClosing field to each CDR file, indicating why the CDR was released.

• Duplicate usage updates when a CDR is split across two sites in an active-active disaster recovery system. In this case, CDR Gateway adds a custom field to the record's extensions.

To enable duplicate CDR detection and stale session detection:

1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans" in ECE Implementing Charging.

2. Expand the ECE Configuration node.

3. Expand charging.cdrGatewayConfigurations.

4. Expand Attributes.

5. Set retransmissionDuplicateDetectionEnabled to true.

6. Under ECE Configuration Node, expand cdrFormatterPlugins.

7. Expand Attributes.

8. Specify values for the following fields:

   • staleSessionCauseForRecordClosingString: Set this to PARTIAL_RECORD.

   • enableStaleSessionCleanupCustomField: Set this to true.

For information, see "Generating CDRs for External Systems" in ECE Implementing Charging.

When a usage request is missing the requested service unit (RSU) AVP, ECE no longer returns the dynamic quota in the usage response to the network.

For information, see "Managing Dynamic Quotas for Online Sessions" in ECE Implementing Charging.

ECE, like PDC, has added support for immediately deducting currency-based discounts from customer account balances.

By default, ECE publishes asynchronous notifications for external applications to the ECE Notification topic. You can now configure ECE to publish one or more asynchronous notifications to multiple partitions in a separate Kafka topic (called the ECE External Notification topic). ECE routes notifications using the customer ID as a partition key, meaning each notification has a dedicated partition for a given customer. You can now configure ECE to publish all external notifications to one Kafka topic. In this case, the topic is named ECE.

For information, see "Publishing Asynchronous Notifications to a Separate Kafka Topic" in ECE Implementing Charging.

ECE can now expose Kafka JMX standard metrics for monitoring notification messages. You can analyze and view these metrics using Prometheus and Grafana.

For information, see "Kafka JMX Metrics" in BRM System Administrator's Guide.

You can now create an SSL-enabled connection between ECE and the Kafka server. You enable SSL and specify the TrustStore location during the ECE installation process.

When customer data is updated in the BRM database, the updates must be applied synchronously (in real-time) to ECE. For example, when a CSR adds, cancels, or modifies an account or when an adjustment such as a cycle fee is applied to an account balance, that information must be updated in ECE so that ECE can rate service usage events properly. Previously, BRM used the Account Synchronization Manager to synchronize data with ECE. In the 15.0 release, Account Synchronization Manager has been obsoleted.

To improve performance, BRM now uses the Oracle Data Manager (DM) to synchronize data between ECE and the BRM database. Oracle DM sends customer data in business events to Oracle Advanced Queuing (AQ) database queues in the BRM database. Then, the ECE Customer Updater retrieves the business events from the queues and updates the information in the ECE cache. For information, see "Synchronizing Account Data between BRM and ECE" in BRM System Administrator's Guide.

The BRM 15.0 installation includes scripts and configuration files to help you create and configure the AQ database queues.

The ece_brs_current_latency_by_type_seconds metric now generates latency data per service type, such as by data, voice, and SMS. For information, see "BRS Metrics" in BRM System Administrator's Guide.