2 ECE System Architecture

This chapter describes the Oracle Communications Billing and Revenue Management (BRM) Elastic Charging Engine (ECE) system architecture.

Overview of ECE System Architecture

ECE is a grid application built on Oracle Coherence. A grid application is an application that leverages a data grid: a system composed of servers that work to manage information and related operations in a distributed environment. ECE implements distributed functions over a network of nodes. These nodes are Java applications that include Oracle Coherence libraries. Services are leveraged to implement application functions in the ECE components. The main components are:

  • Elastic Charging Server

    Elastic Charging Server (ECE charging server nodes) receives and calculates data from ECE clients (client applications). Elastic Charging Server carries out all charging business logic, such as usage charging, and performs query and update operations on ECE cache data.

    Elastic Charging Server sends information to external systems.

    To send requests from the network to Elastic Charging Server for processing, ECE clients must join the ECE cluster in order to access the ECE data and access other services required for sending requests. ECE clients that perform usage metering create usage requests that carry usage information to Elastic Charging Server in order to calculate usage. Client applications use the Elastic Charging Client (described below) to join the ECE cluster.

    Elastic Charging Server supports query requests from external systems, such as customer self-care or network mediation systems, so these systems can obtain data from ECE caches. For self-care systems, query requests are sent to Elastic Charging Server when customers query their account balance and account password information. ECE clients use the Elastic Charging Client (described below) to send query requests.

    See "About the Elastic Charging Server" for more information.

  • Elastic Charging Client

    The Elastic Charging Client is a client library installed on ECE clients that enables ECE clients to connect and send requests to ECE. When ECE clients start the Elastic Charging Client, they automatically join the cluster which provides access to ECE node data caches and the services required for sending requests. The Elastic Charging Client is used for sending all types of requests: usage requests, query requests, update requests, and management requests.

    See "About the Elastic Charging Client" for more information.

  • Diameter Gateway

    Diameter Gateway translates Diameter requests received from Diameter clients (for example, Application Servers, Policy Servers or IMS-GWFs) into Elastic Charging Engine Java API requests. It translates the response from the Elastic Charging Server back into Diameter requests and responds back to the requesting Diameter Client.

    The Elastic Charging Client is integrated in the Diameter Gateway.

    See "About the Diameter Gateway" for more information.

  • Customer Updater and Pricing Updater

    Customer Updater and Pricing Updater ensure that BRM customer information and balances are up-to-date, and that PDC pricing data is up-to-date, respectively, to ensure that ECE has the most current customer and pricing data with which to perform charging calculations.

    ECE processes update requests from BRM to ensure its customer data is current. ECE uses the Customer Updater to manage update requests from BRM. See "About Customer Updater" for more information.

    ECE also processes update requests from PDC to ensure its pricing data is current. ECE uses the Pricing Updater to manage update requests from PDC. See "About Pricing Updater" for more information.

  • BRM Gateway

    BRM Gateway synchronizes BRM data with ECE data by sending update requests from ECE to BRM. ECE sends update requests to BRM for various reasons. For example, ECE sends update requests to BRM to update the subscriber lifecycle state in BRM and to trigger billing in BRM for a customer. See "About the BRM Gateway" for more information.

  • Rated Event Publisher, Rated Event Formatter, BRM CDR Plug-in

    Rated Event Publisher, Rated Event Formatter, and BRM CDR Plug-in persist ECE-generated rated events and send them to external systems. ECE publishes ECE-generated rated events to the Oracle NoSQL Database by using the Rated Event Publisher. ECE formats rated events for the BRM system by using the Rated Event Formatter and the BRM CDR Plug-in. See "About Rated Event Publisher", "About Rated Event Formatter", and "About the BRM CDR Plug-in" for more information.

  • Elastic Charging Controller and Oracle Enterprise Manager Cloud Control

    Elastic Charging Controller (ECC) and Oracle Enterprise Manager Cloud Control monitor and maintain the ECE system. You install these applications on the driver machine, which is the server that is set up to be the primary administrator machine.

    A system administrator who wants to maintain, update and tune the ECE system uses ECC. ECC is the ECE command-line application used for day-to-day administration, managing and operating of the ECE system. See the discussion of using ECC in the BRM Elastic Charging Engine System Administrator's Guide for more information.

    A systems operator who wants to monitor the ECE system and perform basic operational tasks uses Oracle Enterprise Manager Cloud Control. ECE leverages Oracle Enterprise Manager Cloud Control for operations management. To use Oracle Enterprise Manager Cloud Control for ECE, you must install Oracle Application Management Pack for Oracle Communications. Oracle Application Management Pack for Oracle Communications provides management capabilities for BRM and other supported Oracle Communications applications. For detailed information about the management capabilities provided by Oracle Application Management Pack for Oracle Communications, see Oracle Application Management Pack for Oracle Communications System Administrator's Guide.

    For general information about monitoring and managing ECE components, see the discussion of monitoring and managing ECE in the ECE System Administrator's Guide.

  • External Manager Gateway

    External Manager Gateway enables BRM to send requests to ECE (and receive responses from ECE) by converting BRM opcode flists into ECE Java API-formatted requests. BRM sends requests to ECE for various reasons. For example, during rerating, BRM requests the calculation of usage charges for events that need to be rerated. See "About External Manager Gateway" for more information.

About Core ECE Components in the Cluster

Figure 2-1 shows the core ECE components or nodes in the cluster. The core components are shown in the Core Components in the ECE Cluster box.

Figure 2-1 How Core ECE Components Interact with External Applications

Description of Figure 2-1 follows
Description of "Figure 2-1 How Core ECE Components Interact with External Applications"

About the Diameter Gateway

Diameter Gateway translates Diameter requests received from Diameter clients (for example Application Servers, Policy Servers or IMS-GWFs) into Elastic Charging Engine Java API requests. It translates the response from the Elastic Charging Server back into Diameter requests and responds back to the requesting Diameter client.

Diameter Gateway serves as the Online Charging System (OCS) front-end server for the BRM system. It processes network requests for Gy, Sy, and Sh Diameter interfaces. It acts as a Diameter Server and presents the BRM Elastic Charging Engine to the network as a Diameter Credit-Control Application.

Diameter Gateway and ECE charging servers run on the same Coherence cluster which provides high availability and service continuity.

Diameter Gateway communicates with ECE charging servers through ECE Java API calls.

Diameter Gateway exposes custom interfaces for top-up and balance query operations.

Diameter Gateway reads from the ECE notification queue (JMS topic) and processes push notifications from the Elastic Charging Server. From the ECE push notifications (ECE re-authorization request (RAR) notifications, ECE spending limit notifications, and ECE subscriber preferences notifications), Diameter Gateway constructs Sy and Gy messages and sends them back to Diameter clients (for example, for answering back to Push-Notification-Request (PNR), Subscribe-Notifications-Request (SNR), and RAR notifications).

For information about adding Diameter Gateway nodes to your topology, connecting node instances to the network, and configuring node instances, see the discussion about post-installation tasks in BRM Elastic Charging Engine Installation Guide.

For information about using Diameter Gateway for processing Gy, Sy, and Sh interface request types, see the discussion about network integration for online charging using Diameter Gateway in BRM Elastic Charging Engine Implementation Guide.

For information about the Diameter standard attribute-value pairs (AVPs) and Oracle custom AVPs used by Diameter Gateway for processing Gy, Sy, and Sh interface request types, see BRM Elastic Charging Engine Diameter Gateway Protocol Implementation Conformance Statement.

About the Elastic Charging Server

The Elastic Charging Server uses its charging server nodes to carry out all charging business logic, such as usage charging, query, and update logic.

By using the Oracle Coherence in-memory data grid, ECE can distribute objects required for usage charging and their related processing across multiple physical servers, eliminating single points of failure and single points of bottleneck. In addition, Coherence enables vertical and horizontal scalability for ECE.

ECE charging servers receive usage requests containing usage information from the Elastic Charging Client. Customer and pricing data required to process ECE requests are cached within the ECE cluster (where transaction processing occurs) so the ECE charging servers are not required to perform data lookups in external applications.

About High Availability with the Elastic Charging Server

The ECE charging server has built-in high availability features. ECE components that are part of the overall charging system, such as gateways, clients, and the Oracle NoSQL database, also have built-in high availability features.

ECE charging servers use Oracle Coherence technology and leverage features of Coherence clusters for high availability, including:

  • Distribution of ECE objects across multiple physical servers.

  • Distributed processing, with no single points of failure or contention.

  • Storage of information in multiple nodes across multiple physical servers and racks to protect against node, machine, and rack failure.

About the Elastic Charging Client

The Elastic Charging Client is a client library installed on applications that enables them to connect and send requests to ECE. When these applications start the Elastic Charging Client, they automatically join the ECE cluster which provides access to ECE node data caches and the services required for sending requests. The Elastic Charging Client is used for sending all types of requests: usage requests, query requests, update requests, and management requests.

Real-time charging events and offline CDRs from the network are transformed by network mediation software programs into usage requests that use a format required by ECE. The network mediation software programs use the ECE charging API for creating the usage requests.

The API payload is extensible so that you can define charging attributes for creating usage requests that satisfy your business (and charging) requirements. These request specifications can be extended (or you can create new specifications) when you perform event definition in Pricing Design Center. See "About Usage Requests" for information about the usage-request construction required by ECE.

The Elastic Charging Client sends asynchronous usage responses back to client applications that send usage requests. It can send requests as a batch to the Elastic Charging Server. The Elastic Charging Client can also send batch requests that belong to a specific charging server node in the cluster.

The Elastic Charging Client knows in which charging server node on the cluster the customer data is cached; it leverages this information to route requests for processing so that the processing of the requests can occur where the data is located.

The Elastic Charging Client records latency tracking information for how requests were handled in the system.

Offline Mediation Controller is designed to integrate with ECE to send usage requests for offline charging. The Elastic Charging Client is installed on the Offline Mediation Controller distribution cartridge. See Oracle Communications Offline Mediation Controller Elastic Charging Engine Cartridge Pack User Guide for instructions on how to connect Offline Mediation Controller to ECE and submit requests to ECE for processing.

About the Elastic Charging Controller

The Elastic Charging Controller is used for managing the ECE server processes or nodes in the ECE cluster. The Elastic Charging Controller reads your topology file to know where all of the nodes of the cluster are located.The Elastic Charging Controller is installed on the driver machine.

The following are some examples of tasks you can perform using Elastic Charging Controller:

  • Starting and stopping ECE nodes in the cluster.

  • Pushing out configuration changes from the driver machine to all server machines across which the cluster is deployed.

  • Performing rolling upgrades of certain components into a running ECE system, such as changing JVM tuning properties, changing JMS configuration properties, or upgrading extension module customizations (changing extension JAR files).

For information about using Elastic Charging Controller, see the discussion about managing ECE nodes in BRM Elastic Charging Engine System Administrator's Guide.

About configLoader

When you use Diameter Gateway for network mediation for online charging, Diameter Gateway must have access to mediation specification data to create usage requests. The configLoader is a utility that loads ECE with mediation specification data that you configure in your mediation specification file.

For information about editing the mediation specification file, see the discussion about network integration for online charging using Diameter Gateway in BRM Elastic Charging Engine Implementation Guide.

About Pricing Updater

ECE must have access to pricing data to rate the usage requests it receives. ECE uses pricing data and pricing-related configuration data defined in PDC.

The Pricing Updater loads pricing data into ECE automatically when you publish pricing data in PDC for ECE.

When you publish pricing data in PDC, it writes the pricing data to a JMS queue. PDC sends pricing data in XML form in the PDC format.

The Pricing Updater listens on the queue. The Pricing Updater dequeues the data from the JMS queue, transforms the XML into the format understood by ECE (in ECE XML data format), and loads the data into ECE.

The Pricing Updater loads request specification data into ECE. Request specification data is required by ECE client applications for the creation of usage requests. PDC automatically generates the request specification data that is required in XML form in the PDC format. Similar to its handling of pricing data, the Pricing Updater dequeues the request specification data from the JMS queue, transforms the XML into the format understood by ECE (in ECE XML data format), and loads the data into ECE.

You provide information required for configuring the Pricing Updater when you install ECE. You can change this configuration if needed. See the discussion of implementing ECE with PDC in BRM Elastic Charging Engine Implementation Guide for information about configuring the Pricing Updater.

Caution:

The pricingLoader utility is used to load sample pricing data into ECE from XML files that are included the sample pricing data directory (ECE_Home/oceceserver/sample_data/pricing_data, where ECE_Home is the directory in which you installed ECE). Sample pricing data conflicts with pricing data created using PDC.

Do not use pricingLoader on a production deployment.

Do not run pricingLoader and Pricing Updater on the same ECE deployment.

About Customer Updater

The Customer Updater performs the initial extraction of customer data from BRM and loads the data into ECE. The Customer Updater handles update requests from BRM to ECE. The customer data stored in ECE that is relevant to charging usage requests must stay current with the customer data in the BRM database. When events occur in the BRM database that modify the customer data, that data is published by BRM to a database queue. For example, a CSR action such as an adjustment or a customer self-care action such as a top-up can change a customer balance. In addition, account information changes, such as the purchase of a charge offer or a change in account status can also impact the charging of usage requests.

The Customer Updater listens on the queue and processes the update requests to obtain the information relevant for updating customer data in ECE. The update requests coming from BRM include data for new customer creation events. All updates on the BRM system that are relevant for usage charging are synchronized with ECE through the Customer Updater.

The BRM Account Synchronization DM can send any event data to ECE that it is configured to send; it defines the events that trigger event notification for synchronization with ECE. BRM uses its Payload Generator External Module (EM) to create complete business events to send to the Account Synchronization DM. The Account Synchronization DM then sends the business events to the database queue.

All business events sent to ECE are stored in the database queue. To ensure that the ECE system is in sync with the BRM system before usage-processing begins, the Customer Updater dequeues all the messages from the database queue before putting ECE into a usageProcessing state.

Figure 2-2 shows the data flow from event notification to ECE update:

Figure 2-2 Data Flow from Event Notification to ECE

Description of Figure 2-2 follows
Description of "Figure 2-2 Data Flow from Event Notification to ECE "

The primary purpose of the Customer Updater (apart from extracting and loading the initial customer data from BRM upon startup) is to interact with BRM to receive update requests. The Customer Updater is a multi-threaded process.

For BRM, you configure the Customer Updater to listen on the database queue where BRM publishes business events (update requests for ECE). See the discussion of implementing ECE with BRM in the BRM Elastic Charging Engine Implementation Guide for information about configuring the Customer Updater.

Refer to the BRM documentation for information about how to set up event notification in BRM and configure the Account Synchronization DM.

Caution:

The customerLoader utility is used to load sample customer data into ECE from XML files that are included in the sample customer data directory (ECE_Home/oceceserver/sample_data/customer_data). Sample customer data conflicts with customer data created using BRM.

Do not use customerLoader on a production deployment.

Do not run customerLoader and Customer Updater on the same ECE deployment.

About External Manager Gateway

The External Manager Gateway is a JVM process that acts as a client to the Elastic Charging Server, sending requests to ECE from BRM.

The External Manager Gateway listens on a port for requests from BRM that are in opcode input flist format. The External Manager Gateway converts BRM opcode input flists into ECE requests and converts the subsequent ECE responses back into BRM opcode output flists.

The BRM rerating utility uses the External Manager Gateway to send rerating requests from BRM to ECE during the rerating process. See "About Rerating" for more information.

Custom BRM applications can use the External Manager Gateway to send balance query requests to ECE for querying the customer real-time usage balance that is managed in ECE.

For information about configuring the External Manager Gateway, see the discussion about implementing ECE with BRM in BRM Elastic Charging Engine Implementation Guide.

About the BRM Gateway

The BRM Gateway handles update requests from ECE to BRM (ECE sends requests to BRM to update data in the BRM database).

The BRM Gateway sends information to BRM when processes must be triggered in BRM or data must be updated in BRM due to ECE usage-request processing.

The BRM Gateway connects to and sends information to BRM for the following purposes:

  • Synchronize the first-usage validity initialized from ECE to BRM.

    See "About First-Usage Validity".

  • Update the subscriber lifecycle state in BRM.

    When changes occur to a customer's subscriber lifecycle state in ECE, ECE publishes a service event. The BRM Gateway uses the service event to send the subscriber lifecycle state information to BRM so that BRM can update the state in the BRM database.

    For example, the subscriber lifecycle state can go from a pre-active state to an active state in ECE when a customer activates a prepaid calling card from the network. ECE uses the BRM Gateway to send the new state information to BRM.

  • Trigger billing in BRM.

    If a customer starts a session immediately before billing is set to run in BRM, ECE sends a request to BRM to run billing for that customer. See "About Billing Notifications" for more information.

  • Refresh item POIDs in ECE.

    ECE gets a list of POID from BRM, caches them in ECE, and sets them in the rated event.

    For tracking a customer's balance impacts for a given billable item type, ECE maps the product type and event type combinations in a usage request to its relevant item type. ECE sends information to BRM to refresh the item POIDs in the BRM database.

The BRM Gateway is part of the ECE cluster, but it is not storage enabled; it is a Java process interacting with ECE through JMS. The primary purpose of the BRM Gateway is to interact with BRM to send update requests.

The BRM Gateway listens on the ECE notification queue for notification events that trigger update requests to BRM. When such a notification event occurs, the BRM Gateway connects to the BRM Connection Manager (CM) and sends the relevant data from the notification event to BRM. In sending the information, the BRM Gateway calls the necessary BRM opcodes that use the data for triggering processes in BRM.

You must configure the BRM Gateway to connect to the BRM CM. See the discussion of configuring the BRM Gateway in BRM Elastic Charging Engine Implementation Guide.

About Rated Event Publisher

The Rated Event Publisher takes rated event information in the ECE charging server and publishes this information into the Oracle NoSQL Database. The Rated Event Publisher takes ECE Java objects in the ECE charging server and publishes them in (Coherence) binary format to a NoSQL datastore.

About Rated Event Formatter

The Rated Event Formatter is a multi-threaded process that receives a stream of rated-event objects from the Oracle NoSQL Database and exports them in a format suitable for consumption by an external system. The Rated Event Formatter is designed to use different modules or plug-ins for formatting the rated event objects into whatever format is required by the system that needs to store the objects. The plug-in framework is designed for enabling integration with other downstream systems. For BRM, Rated Event Formatter includes the BRM CDR Plug-in. See "About the BRM CDR Plug-in".

See the discussion of configuring ECE in BRM Elastic Charging Engine System Administrator's Guide for information about configuring Rated Event Formatter.

About the BRM CDR Plug-in

The BRM CDR Plug-in is a module within the Rated Event Formatter, which is used to transform rated event objects into CDR files in BRM CDR format, and EDR text format.

The BRM Rated Event (RE) Loader loads the CDRs into BRM for updating customer account balances in BRM. See the BRM documentation for information about configuring RE Loader to load CDRs into BRM.

See the discussion of configuring ECE in BRM Elastic Charging Engine System Administrator's Guide for information about configuring the BRM CDR Plug-in.

About ECE as a Subscriber Profile Repository

When integrating PCRF policy clients with ECE, ECE acts as the Subscriber Profile Repository (SPR) because it stores the customer profile information used by the PCRF. ECE offers a combined Sp (implemented as Sh) and Sy interface which the PCRF uses to retrieve customer preferences and policy counter information. For more information, see "About ECE and Policy Clients" and see the discussion about PCRF policy clients in BRM Elastic Charging Engine Implementation Guide.

About ECE Request Types

ECE receives various types of requests from other applications. ECE processes the following types of requests:

  • Usage requests

  • Policy requests

  • Top-up requests (a type of update request)

  • Query requests

  • Management requests

  • Update requests

ECE offers services which expose its client APIs that applications can use to create these requests. For more information, see the ECE API Reference appendix in BRM Elastic Charging Engine Implementation Guide.