1. Release Notes
  2. New Features in ECE

6 New Features in ECE

Learn about the new features in Oracle Communications Elastic Charging Engine (ECE) 15.0.

Topics in this document:

New Features in ECE 15.0.1

ECE 15.0.1 includes the following enhancements:

ECE Uses Non-Linear Rating by Default

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.

Configuring External Modules for High Availability

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.

Setting the Order to Consume Allowances

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 (15.0.1 or later)" in ECE Implementing Charging.

Active-Active Sy Session Re-Anchoring

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.

Creating Midsession-Rated Events for Product Changes

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.

Note:

This feature does not work if the product has a rate plan with multiple tiers.

Enhanced Rated Event Formatter Resiliency

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

New Features in ECE 15.0.0

This section lists the features introduced between ECE 12.0 Patch Set 8 and ECE 15.0.0.

For information about the features introduced between ECE 12.0 and ECE 12.0 Patch Set 8, see "New Features in ECE" in BRM 12.0 Patch Set Release Notes.

ECE 15.0.0 includes the following enhancements:

HTTP Gateway Now Supports Primary and Secondary NRFs

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.

Specifying to Consume Main Balance Before Loan Balance

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.

ECE Charging Refund Enhancements

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 Information Now Synchronized with ECE

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.

Extension for Customizing Notification Payloads

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.

Extension for Unrated Quantity Information

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.

Extension for Custom Reason Codes

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-1.

Table 6-1 Midsession Rated Event Reason Codes

Reason Code Description Value
CONFIGURED_VOLUME_REACHED

The event exceeded a configured volume, such as 100 MB.

1
CONFIGURED_DURATION_REACHED

The event exceeded a configured amount of time, such as 2 hours.

2
RATING_CONDITION_CHANGE

The trigger was caused by a change in tariffs.

3
CONFIGURED_TIME_OF_THE_DAY_CROSSED

The event crossed a configured time of day, such as midnight.

4
INTERNAL_TRIGGER

The trigger was caused by a context change.

5
EXTERNAL_TRIGGER

The midsession trigger condition was met.

6
MULTIPLE_USU

The event contained multiple Used Service Units (USUs).

ECE generates a midsession-rated event for each USU.

7
MULTIPLE_USU_AND_EXTERNAL_TRIGGER_OR_INTERNAL_TRIGGER

The event was caused by any of the preceding triggers.

8
PRE_MIDSESSION_CONDITION

The event reached a custom trigger at the prerating extension point.

9
POST_MIDSESSION_CONDITION

The event reached a custom trigger at the post-rating extension point.

10
ZONE_CHANGE

The trigger was caused by a change in zone.

Note: This reason code is new in BRM 15.0.

11
BALANCE_EXHAUST

The event was triggered after the complete exhaustion of an existing balance.

Note: This reason code is new in BRM 15.0.

12

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.

Extension for Generating RARs for Sharing Group Members

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.

Extension for Retrieving Worst Cost Setting

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.

Diameter Gateway Balance Query Response Enhancement

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.

CDR Generator Can Mark CDRs as Incomplete

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 Generator Can Detect Duplicate CDRs and Stale Sessions

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.

Dynamic Quota Not Granted When No RSU in Request

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 Supports Immediately Consuming Debit Discounts

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

Publish Notifications to Separate Kafka Topic

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 Now Supports Kafka JMX Metrics

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.

ECE Now Supports SSL Connections with Kafka Servers

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.

Improved Synchronization Between BRM and ECE

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.

Note:

Oracle DM rolls back the transaction in both the BRM database and the AQ database queue if the commit to either fails.

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

ece_brs_current_latency_by_type_seconds Metric Generates Latency Data Per Service

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.