2 ECE System Architecture

This chapter describes the Oracle Communications Billing and Revenue Management 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 to access the ECE data and other services required for sending requests. ECE clients that perform usage metering create usage requests that carry usage information to Elastic Charging Server 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 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 that 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, query, update, and management.

    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 IP multimedia subsystem gateway functions) into ECE Java API requests. It translates the response from Elastic Charging Server back into Diameter requests and responds back to the requesting Diameter client.

    The Elastic Charging Client is integrated in Diameter Gateway.

    See "About Diameter Gateway" for more information.

  • RADIUS Gateway

    RADIUS Gateway translates RADIUS requests received from RADIUS clients into ECE Java API requests. It translates the response from Elastic Charging Server back into RADIUS requests and responds to the requesting RADIUS client.

    The Elastic Charging Client is integrated in RADIUS Gateway.

    See "About RADIUS Gateway" for more information.

  • Customer Updater and Pricing Updater

    To ensure that ECE has the most current data to use in charging calculations:

    • Customer Updater manages customer data update requests from the BRM server to ensure that customer data and balances are current in the ECE cache. See "About Customer Updater".

    • Pricing Updater processes update requests from Pricing Design Center (PDC) to ensure that pricing data is current in the ECE cache. See "About Pricing Updater".

  • BRM Gateway

    BRM Gateway synchronizes Oracle Communications Billing and Revenue Management BRM data with ECE data by sending update requests from ECE to BRM. ECE sends update requests to BRM for various reasons: for example, to BRM to update the subscriber life-cycle state in BRM and to trigger billing in BRM for a customer. See "About BRM Gateway" for more information.

  • Rated Event Publisher and Rated Event Formatter

    Rated Event Publisher and Rated Event Formatter persist ECE-generated rated events and send them to external systems. ECE publishes rated events to the Oracle NoSQL database by using Rated Event Publisher. ECE formats rated events for the BRM system by using Rated Event Formatter. For a non-BRM system, rated events are formatted via a custom plug-in. See "About Rated Event Publisher" and "About Rated Event Formatter" 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 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 about monitoring and managing ECE in ECE System Administrator's Guide.

  • External Manager Gateway

    External Manager (EM) Gateway enables BRM to send requests to 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 ECE Components in the 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 Diameter Gateway

Diameter Gateway translates Diameter requests received from Diameter clients (for example, application servers, policy servers, or IP multimedia subsystem gateway functions) into ECE Java API requests. It translates the response from 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 ECE to the network as a Diameter credit-control application.

Diameter Gateway and Elastic Charging Server run on the same Coherence cluster, which provides high availability and service continuity.

Diameter Gateway communicates with Elastic Charging Server 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 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-notification-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 BRM Elastic Charging Engine System Administrator's 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 RADIUS Gateway

Important:

RADIUS Gateway is an optional component that requires a separate license.

RADIUS Gateway translates RADIUS requests received from RADIUS clients into ECE Java API requests. It translates the response from Elastic Charging Server back into RADIUS requests and responds to the requesting RADIUS client. You use RADIUS Gateway to process authentication and accounting requests when your customers use terminal servers or Network Access Server (NAS) to connect to ECE.

RADIUS Gateway serves as the OCS front-end server for the BRM system. It acts as a RADIUS server and presents ECE to the network as a RADIUS application.

RADIUS Gateway provides custom interfaces for processing authentication and accounting requests from RADIUS clients.

RADIUS Gateway is included in the ECE server installation, and you can deploy RADIUS Gateway nodes into the ECE cluster the same way you deploy other ECE nodes. RADIUS Gateway has ready-to-use example configuration files to facilitate implementation.

For information about adding RADIUS Gateway nodes to your topology and configuring node instances, see BRM Elastic Charging Engine System Administrator's Guide.

For information about mapping RADIUS network attributes to event attributes and customizing the RADIUS data dictionary in ECE, see the discussion about configuring and customizing RADIUS Gateway in BRM Elastic Charging Engine Implementation Guide.

For more information about using RADIUS Gateway for processing authentication requests, see the discussion about authentication using RADIUS Gateway in BRM Elastic Charging Engine Implementation Guide.

For more information about using RADIUS Gateway for processing accounting requests, see the discussion about accounting using RADIUS Gateway in BRM Elastic Charging Engine Implementation Guide.

For information about the custom interfaces and the extension points available for processing requests from RADIUS clients, see BRM Elastic Charging Engine Extensions.

For information about the RADIUS standard AVPs and messages used by RADIUS Gateway for processing requests from RADIUS clients, see BRM Elastic Charging Engine RADIUS Gateway Protocol Implementation Conformance Statement.

About Elastic Charging Server

Elastic Charging Server uses its charging server nodes to perform 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 Elastic Charging Server

Elastic 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 server nodes 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 ECE clients that enables ECE to connect and send requests to ECE. When ECE clients start the Elastic Charging Client, they automatically join the cluster that 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, query, update, and management.

Real-time charging events and offline call details records (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 PDC. 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 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.

Oracle Communications Offline Mediation Controller integrates 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 Elastic Charging Controller

Elastic Charging Controller is used for managing the ECE server processes or nodes in the ECE cluster. Elastic Charging Controller reads your topology file to know where all of the nodes of the cluster are located.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 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

Both RADIUS Gateway and Diameter Gateway must have access to mediation specification data to create authentication, accounting, or usage requests. configLoader is a utility that loads ECE with mediation specification data that you configure in your mediation specification file.

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

For information about editing the RADIUS mediation specification file, see the discussion about configuring and customizing RADIUS 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.

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

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

Pricing Updater listens on the queue. 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.

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, 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 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 Pricing Updater.

Caution:

The pricingLoader utility is used to load sample pricing data into ECE from XML files that are included in the sample pricing data directory (ECE_home/oceceserver/sample_data/pricing_data, where ECE_home is the directory in which ECE is installed). 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

Customer Updater does the following:

  • Performs the initial extraction of customer data, credit profiles, offer profiles, configuration objects, and pricing cross-reference data from BRM and loads the data into ECE

  • Handles asynchronous updates from BRM to ECE of the following data: rerating, account migration, discount, and product

The rerating, account migration, discount, and product data stored in ECE must stay current with the corresponding data in the BRM database.

When events occur that update that data in the BRM database, the updates can be published asynchronously (not in real time) to ECE through Customer Updater. To do so, the updates are sent in business events to Account Synchronization Data Manager (DM), which publishes the business events to an Oracle Advanced Queuing (Oracle AQ) database queue. Customer Updater retrieves the business events from the queue and updates the ECE cache accordingly.

To ensure that the ECE cache is synchronized with the BRM database before usage processing begins, Customer Updater dequeues all requests from the database queue before putting ECE into a usageProcessing state.

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

Figure 2-2 Data Flow from Event Notification to ECE Update through Customer Updater

Description of Figure 2-2 follows
Description of ''Figure 2-2 Data Flow from Event Notification to ECE Update through Customer Updater''

For general information about configuring event notification, account synchronization, and business event payloads, see the BRM documentation.

For information about configuring ECE event notification and payloads, see the discussion about loading the ECE configuration files into your BRM system in BRM Setting Up Pricing and Rating.

For information about configuring Customer Updater, see the discussion about implementing ECE with BRM in BRM Elastic Charging Engine Implementation Guide.

For information about updating customer data in real time, see "About Synchronizing BRM and ECE Customer Data".

Caution:

Running the customerLoader utility without any parameter loads sample customer data into ECE from XML files included in the sample customer data directory (ECE_home/oceceserver/sample_data/customer_data). Sample customer data conflicts with customer data created using BRM. Running the customerLoader utility with the incremental parameter loads customer data incrementally, in batches or in bulk, from BRM into ECE.

Do not run customerLoader without the incremental parameter on a production ECE deployment.

About External Manager Gateway

External Manager (EM) Gateway is a Java Virtual Machine (JVM) process that acts as a client to Elastic Charging Server, sending requests to ECE from BRM.

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

The BRM server uses EM Gateway to publish customer data updates from the BRM database to the ECE cache. For more information, see "About Synchronizing BRM and ECE Customer Data".

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

Custom BRM applications can use EM 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 EM Gateway, see the discussion about implementing ECE with BRM in BRM Elastic Charging Engine Implementation Guide.

About BRM Gateway

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

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.

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 life-cycle state in BRM

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

    For example, the subscriber life-cycle 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 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 POIDs 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.

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 BRM Gateway is to interact with BRM to send update requests.

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

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

About Rated Event Publisher

Rated Event Publisher takes rated event information in Elastic Charging Server and publishes this information into the Oracle NoSQL database. Rated Event Publisher takes ECE Java objects in Elastic Charging Server and publishes them in (Coherence) binary format to a NoSQL datastore.

About Rated Event Formatter

Rated Event Formatter translates rated events into a format that can be loaded by Rated Event Loader. Rated Event Loader loads rated events into the BRM database. You can configure Rated Event Formatter to translate and send rated events in the required format to external systems, such as a data warehouse.

Rated Event Formatter runs plug-ins to translate rated events in different formats. The BrmCdrPluginDirect Plug-in transforms events from the Oracle NoSQL database into CDR files in the BRM CDR format. For a non-BRM system, you can configure a custom plug-in to transform rated events in different formats, such as XML and JSON.

When you use a custom plug-in, the custom plug-in and the BrmCdrPluginDirect Plug-in process the rated events simultaneously. When the rated events are processed by the non-BRM system and the BRM database, the rated events are purged from the BRM database.

For more information about the BrmCdrPluginDirect Plug-in, see the discussion about configuring the BrmCdrPluginDirect Plug-in in BRM Elastic Charging Engine Implementation Guide.

About ECE as a Subscriber Profile Repository

When integrating policy and charging rules function (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 that 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.