This chapter is an overview of Oracle Communications Billing and Revenue Management (BRM) Elastic Charging Engine (ECE).
Elastic Charging Engine is the core charging-engine technology of the BRM system. ECE is the single charging engine for both offline and online charging. Built on Oracle Coherence, ECE is scalable and resilient, and as its name suggests, ECE can scale (like an elastic band can stretch) when tasked with processing thousands of transactions per second. The ability of ECE to scale with its in-memory charging technology supports low service latencies and high performance. See "ECE System Architecture" for more information about ECE and Oracle Coherence.
You can use ECE to charge customers for their use of any product on any network, using any service, and using any payment type. For a convergent charging system, ECE can perform both online charging and offline charging when rating events from the network.
In the BRM system, ECE performs usage charging. ECE rates events and calculates charges for services such as telephony usage and content downloads. Specifically, ECE does the following:
Receives event information from a network mediation system.
For example, ECE receives event information from the ECE Diameter Gateway (the supported Diameter interface) or a third-party network mediation system.
Measures the event.
Applies a charge to the resulting measurement.
Adds the charge to the customer's account balance.
To receive event data, ECE processes usage requests that are created and submitted by online and offline network mediation software programs. Usage requests contain event information that is used for online charging and offline charging of network usage, such as the duration of a call or the amount of data that is downloaded.
To rate event data, ECE uses pricing data. ECE uses pricing data from Pricing Design Center (PDC), which defines rates and rating rules that are used to determine the price of an event.
To rate event data, ECE also uses customer data. ECE uses customer data from BRM, which defines the products that the customer owns.
ECE performs real-time balance management, calculating how much quota a customer can use based on his balance. For example, ECE calculates how many minutes a caller can use based on his balance.
ECE has APIs for integrating with other systems in an integrated charging solution such as with the Policy and Charging Rules Function (PCRF) for implementing policy-driven charging and with top-up systems for applying top-ups to customer balances.
Figure 1-1 shows how ECE receives inputs from and provides outputs to other systems in an integrated charging solution.
Figure 1-1 ECE Inputs and Outputs To and From Other Systems in an Integrated Charging Solution
ECE can publish notifications when specific events occur in the ECE charging servers. Other applications can subscribe for receiving the notifications to use the data for their own processing. ECE uses notifications, for example, to provide network mediation systems with balance information for prepaid authorizations. ECE also uses notifications to provide balance updates to BRM.
In addition to usage requests, ECE processes various other types of requests. See "About ECE Request Types" for information.
The following procedure describes how ECE typically processes a usage request for online charging.
The online network mediation system receives charging events from the network. For example, the ECE Diameter Gateway receives Diameter credit control messages from a mobile cellular network.
The online network mediation system extracts the event attributes and maps them to ECE usage attributes in the ECE usage request.
The online network mediation system submits the usage requests to ECE.
ECE processes the usage request. Rating, alterations, sharing and taxation are part of the calculation of charges. See the discussion of alterations, sharing, and taxation charge calculations in "Understanding Charging Scenarios".
For example, ECE reads the duration of an event in the usage request and calculates the charges.
ECE also supports debit and refund operations for which the charges are passed in the input.
ECE updates the customer balance so that it is synchronized with the customer balance in BRM. In addition, reservations and active sessions are also updated.
ECE manages the current state of customer balances within the online charging system.
ECE sends a usage response to the online network mediation system.
Figure 1-2 illustrates how online network mediation systems work with ECE.
Figure 1-2 Online Mediation System and ECE
The following procedure describes how ECE typically processes a usage request for offline charging.
The offline network mediation system collects charge data records (CDRs) from a known location where the network Charging Data Function (CDF) has written them.
The offline network mediation system optionally uses the CDRs to perform further processing such as duplicate checking and aggregation.
The offline network mediation system transforms the CDRs into ECE usage requests.
The offline network mediation system extracts the event attributes and maps them to ECE usage request parameters.
The offline network mediation system submits the usage requests to ECE.
ECE calculates the charges based on the request attributes. ECE supports debit and refund operations for which the charges are passed in the input.
If ECE detects errors (for example, it does not find a valid offering for charging for the request), then it rejects the request. It sends a negative usage response to the offline mediation system which then rejects the CDR.
ECE manages the current state of customer balances within the charging system so that it is synchronized with the balance information in BRM.
Figure 1-3 describes how the offline network mediation system interacts with ECE.
Figure 1-3 Offline Mediation System and ECE
ECE must have access to pricing data to rate the events contained in the usage requests it receives. ECE uses pricing data and pricing-related configuration data defined in PDC.
You design pricing components in PDC such as charge offers and discount offers. You also design setup components that support the creation of pricing components such as balance elements, impact categories, time models, rateable usage metrics (RUMs), service-event maps, and zone models. ECE uses the criteria in your pricing components to calculate the price of your services.
In PDC, you set up your event definitions for the events that you created in BRM. Your event definitions contains the request specification data that ECE client applications use for sending requests to the ECE charging servers. Your event definition includes the definition of usage attributes that ECE can accept when processing usage requests. You perform network enrichment of the event definition for your events in PDC. You add network attributes for all event attributes in the event definition that apply to usage-request charging operations. For information about event definition and mapping event attributes to network attributes, see PDC User's Guide.
See "About Pricing Updater" for a discussion on how PDC data is sent to ECE.
After rating an event, ECE needs to send that rated event to BRM so that BRM can update the customer balance (debit or credit the customer balance) so the customer can be billed.
ECE first publishes the rated event to the Oracle NoSQL database data store that you previously configured for use by ECE. From the Oracle NoSQL database data store, the data is subsequently:
The Rated Event Formatter reads and extracts the rated event information from the Oracle NoSQL database data store so that it can be formatted.
Rated Event Formatter uses its BrmCdrPlugindDirect Plug-in to format the rated event information into CDR files in BRM CDR format.
Loaded into the BRM database
The BRM Rated Event (RE) Loader subsequently loads the CDRs into the BRM database which updates the customer account balances in BRM.
BRM sends data to ECE when updates to customer data occur in the BRM system that must be pushed to ECE. See "About Customer Updater" for a discussion about how BRM data is sent to ECE.
BRM sends rerating requests to ECE (usage requests and usage responses that are sent for rerating). See "About Rerating" for a discussion about how BRM data is sent to ECE for rerating.
To support policy-driven charging, ECE offers a policy management API. Policy clients, such as Diameter Gateway, can use the API to retrieve data from the ECE data grid that is relevant for policy enforcement.
Policy-driven charging in ECE is based on the Policy and Charging Rules Function (PCRF), defined in the 3GPP TS 23.203 v9.9.0 (2011-06) specification. The PCRF can integrate with ECE through your online network mediation software.
ECE exposes its cached in-memory data so that your online network mediation software can retrieve policy counter information and policy-related subscriber preference information. ECE publishes notifications containing the policy information and your online network mediation software uses the notifications to send the information to the PCRF for evaluation. For information about how ECE interacts with your online network mediation software for policy-driven charging, see "How ECE Processes Policy Requests for Online Network Mediation Software".
For more information about how ECE supports policy-driven charging, see "About Policy-Driven Charging".
For information about the ECE policy management API and the XML structure of ECE policy notifications, see the discussion about integrating policy clients with ECE in BRM Elastic Charging Engine Implementation Guide.
Figure 1-4 illustrates how ECE fits into a charging system that implements policy-driven charging.
Figure 1-4 ECE and Policy Client Integration
The following procedure describes how ECE processes requests for policy-driven charging from your online network mediation software (or from Diameter Gateway).
A customer starts to use a service which starts a network session.
For example, the customer turns on a mobile phone which connects to a wireless network.
At the start of the network session, the Policy and Charging Enforcement Function (PCEF) obtains from the Policy and Charging Rules Function (PCRF) a policy configuration.
The PCEF uses the Gx interface to obtain the policy configuration for the network session.
The PCRF requests the policy counters and subscriber preferences from your online network mediation software (or Diameter Gateway).
The PCRF uses the Diameter Sy/Sp interface.
Your online network mediation software initiates a policy session with ECE which does the following:
Requests policy counter and status label information.
Requests the policy counters for a specific product and subscribes for receiving notifications when the values of the policy counter information changes.
Requests policy-related subscriber preferences information by doing one of the following:
Retrieves the value for a specified set of subscriber preferences and subscribes for receiving notifications when the values of the preferences change during the policy session.
Retrieves only the values for a specified set of subscriber preferences and does not subscribe for receiving notifications when the values of the preferences change during the policy session.
Your online network mediation software (and also Diameter Gateway) uses the PolicySessionRequest ECE Java combined Sy/Sp (implemented as Sh) interface which uses the SubscribeNotificationRequest procedure and the UserDataRequest procedure.
ECE sends a policy response to your online network mediation software (or to Diameter Gateway) which does the following:
Indicates whether the request succeeded or failed and a list of reasons supporting the response.
Sends the status of the policy counters as follows for the product specified, or if the product types were not specified, returns the information for all products:
Sends the offer profile name configured for the product.
Sends the status label associated with the policy counter.
Sends an effective time for the values of the policy counters. After the effective time expires, the PCRF is expected to send another request for policy counter and status label information (send another SpendingLimitReportRequest).
Sends the label name of the next probable status that will apply after the effective time expires. For example, Medium_QoS.
Sends the delay interval. The PCRF can use the delay interval and the effective time to determine when to query for the policy counters again.
ECE uses the SpendingLimitReportResponse procedure of the ECE Java Sy interface.
The information listed above is only a subset of the response. For all information included in the response, see BRM Elastic Charging Engine Java API Reference.
Sends the subscriber preferences for the specified set of subscriber preferences.
ECE uses the SubscribeNotificationResponse procedure of the ECE Java Sp interface.
The PCRF rules engine interprets the information and installs a policy on the PCEF which the PCEF enforces.
A charging session is established and the PCEF sends a Ro message to your online network mediation software (or Diameter Gateway).
Your online network mediation software (or Diameter Gateway) initiates a charging session with ECE.
ECE publishes policy notifications for the following:
Changes to the policy counter status for the policy counters the PCRF subscribed for (Sy data) at the beginning of the policy session.
Changes to the subscriber preferences the PCRF subscribed for (Sp data), if any, at the beginning of the policy session.
For information about policy notifications, see "About Notifications Used by Policy Clients".
Your online network mediation software (or Diameter Gateway) consumes the policy notifications and sends the data to the PCRF.
For information about policy notification data format, see the discussion about integrating ECE with policy clients in BRM Elastic Charging Engine Implementation Guide.
As the charging session continues, ECE performs credit control functions: rates events, authorizes usage events only if adequate balance is available, administers threshold checks based on the current balance and consumed reservation of the customer balance.
For information about how ECE processes usage requests, see "How ECE Charges Usage Requests for Online Network Mediation System".
When ECE detects a policy threshold breach during the charging session, it publishes a policy notification to the JMS notification queue containing the new status of the policy counter. Your online network mediation software (or Diameter Gateway) sends the data to the PCRF.
The customer balance change that causes the policy threshold breach could occur because of any of the following:
Usage requests coming from the network mediation system
Update requests coming from BRM (a subscription activity in the customer management system)
Top ups coming from top-up systems
The PCRF evaluates the new policy counter values and the associated policy status labels and installs a new policy configuration on the PCEF.
The new policy is established dynamically during the charging session.
The customer stops using his service which ends the network session.
Your online network mediation software (or Diameter Gateway) terminates the charging session with ECE.
Your online network mediation software (or Diameter Gateway) terminates the policy session with ECE.
To integrate client applications such as mediation systems, Policy and Charging Rules Function (PCRF) clients, and top-up systems with ECE, you use the ECE APIs. See the Elastic Charging Engine API Overview in BRM Elastic Charging Engine Implementation Guide for a summary of the ECE APIs. Refer to BRM Elastic Charging Engine Java API Reference for detailed information about each type of ECE API.
For sending usage requests to ECE, client applications must call the ECE charging APIs according to the usage request builder defined. See the discussion of usage requests in BRM Elastic Charging Engine Implementation Guide for information about how usage requests are built and the supported operation types.
An ECE SDK is included with the software and contains sample programs that demonstrate the arguments and methods programs must use when calling the ECE APIs. See the discussion of using ECE testing tools in BRM Elastic Charging Engine Implementation Guide for information about the sample programs.
When you introduce different ways of charging customers for the use of your products, you can extend existing usage requests or create new usage requests to support the attributes required for the different ways of charging. When extending or creating usage requests to handle new charging attributes, you must update integration points in the charging system so that products that surround ECE can handle the new attributes.
In addition to integrating client applications, you also need to format data from these applications to conform to the ECE data schema files. See the discussion of loading data in BRM Elastic Charging Engine Implementation Guide.