13 Managing Online Charging Sessions

Learn how to configure online charging sessions in Oracle Communications Elastic Charging Engine (ECE).

Topics in this document:

• Configuring ECE to Support Prepaid Usage Overage

• Managing Dynamic Charging Overrides for Online Sessions

• Processing Granted Allowances Before Applying Usage Charges

• Enabling Server-Initiated Reauthorization Requests

• Configuring ECE to Return Remaining-Balance Information in Usage Responses

• Configuring Taxation in ECE

• Configuring How ECE Manages Active Sessions When Network Elements Fail

• Configuring ECE to Redirect Subscriber Sessions to a Service Portal

• Enabling Match Factor in ECE

• Configuring Diameter Gateway to Bypass Rating During ECE Downtime

• Accessing ECE Configuration MBeans

Configuring ECE to Support Prepaid Usage Overage

You can configure ECE to capture any overage amounts by prepaid customers during an active session, which can help you prevent revenue leakage. If the network reports that the number of used units during a session is greater than a customer's available allowance and credit limit, ECE charges the customer up to the available allowance. It then creates an overage record with information about the overage amount and sends it to the ECE Overage topic. You can create a custom solution for reprocessing the overage amount later on.

Note:

Prepaid usage overage is supported on Kafka Server only. It is not supported on WebLogic Server.

For example, assume a customer has a prepaid balance of 100 minutes, but uses 130 minutes during a session. ECE would charge the customer for 100 minutes, create an overage record for the remaining 30 minutes of usage, and write the overage record to the ECE Overage topic.

To configure ECE to support prepaid usage overage, do the following:

1. Ensure that you created an ECE Overage topic and connected ECE to your Kafka Server. See "Connecting ECE to Kafka Topics".

2. Enable ECE to check for and capture any usage overage:

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

   2. Expand the ECE Configuration node.

   3. Expand charging.server.

   4. Expand Attributes.

   5. Set the checkReservationOverImpact attribute to true. (The default is false.)

Managing Dynamic Charging Overrides for Online Sessions

Dynamic charging allows you to override an offer's default rate on a per customer basis based on the date. For example, you could create a dynamic override that charges new customers $0.04 per MB for the first six months, $0.05 per MB for the next four months, and then the default rate for all subsequent months.

You define dynamic charging overrides by creating a pricing tag and associating it with an event type, date ranges, and an amount. For example, you could create a pricing tag named MyPrice associated with a $0.05 per MB charge for /event/session/telco/gsm events from June through September. You could then add the pricing tag to your offers' balance impacts.

You configure dynamic charging overrides using PDC or the ImportExportPricing utility. See "Configuring Dynamic Pricing for Usage Events" in PDC Creating Product Offerings.

BRM stores information about dynamic charging overrides in the /offering_override_values object.

During rating, ECE determines whether a pricing tag in a balance impact matches a pricing tag and date range combination in the /offering_override_values object. If it finds a match, ECE charges the amount associated with the pricing tag. If it does not find a match, ECE charges the default amount.

Processing Granted Allowances Before Applying Usage Charges

ECE processes a customer's granted allowances and usage charges in the order in which they appear in the product offerings you define in PDC. For example, assume you configure a product offering in PDC that grants 5 GB of free data per month and then charges $10 per additional GB of data. If a customer purchases the product offering and uses 8 GB of data in a month, ECE would first consume the 5 GB of free data and then apply a $30 charge for the remaining 3 GB of data usage.

To configure charges in PDC to process granted allowances before applying usage charges, see "Configuring Pricing to Consume Granted Allowances Before Charging" in PDC Creating Product Offerings.

Enabling Server-Initiated Reauthorization Requests

ECE can perform server-initiated reauthorization requests (RAR) during an ongoing session. This enables you to update a session in response to changes that occur to a customer's product offerings or balance (for example, a change to a charge offer or to a Friends and Family promotion). When ECE notifies the network, the network sends a reauthorization request and, if there is a change in the charge, ECE can base the reauthorization on the new charge.

A server-initiated reauthorization can be triggered from the following conditions:

• Changes to offers, such as the creation, modification, or deletion of a subscriber's charge offer or alteration offer.

• Changes to balances that affect rating (for example, a balance that expires mid-session, a balance that becomes available from a top-up, or changes to the customer balance due to an accounts receivable action).

• Changes to promotions, such as changes to Friends and Family or a Special Day offer.

• Changes to charge sharing or alteration sharing groups. For example, a new member is added to the group or a member is removed mid-session.

For example:

1. A subscriber is in a call session. The subscriber adds the called number of that session to a Friends and Family list.

2. Because a Friends and Family discount might change the charge amount, ECE sends a request to the network.

3. In response, the network sends a reauthorization request.

4. ECE sends a reauthorization, using the Friends and Family charge amount.

Note:

A reauthorization request is not triggered by a top-up or by rerating when balances are added to a sharing group owner's account.

To enable server-initiated reauthorization requests:

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

2. Expand the ECE Configuration node.

3. Expand charging.notification.

4. Expand Attributes.

5. Set the rarNotificationMode attribute to ASYNCHRONOUS.

   This enables RAR notifications, which are required for server-initiated reauthorization requests. ECE generates an external notification and sends it to a notification queue (JMS topic) when the RAR_NOTIFICATION_EVENT service event is created. When specific condition changes occur during a session, ECE generates a RAR notification to inform the network to request a reauthorization.

6. Under the ECE Configuration node, expand charging.server.

7. Expand Attributes.

8. Set the offerEligibilitySelectionMode attribute to PERIOD.

   • In PERIOD mode, ECE selects applicable charge offers valid any time between the start and end time of the session to determine charges for events. You use this mode when implementing server-initiated reauthorization requests so that ECE can rate based on changes to a customer's subscription, such as the purchase of a promotional offer, during the session.

   • In END_TIME mode, ECE selects charge offers valid at the end time of the session to determine charges for events. END_TIME mode must be used when using a version of BRM that does not support PERIOD mode. This is the default.

   Note:

   Events rated in PERIOD mode might result in a different charge from the charge calculated when the event is rerated. This happens because the event is rerated using only the pricing applicable at the event end time.

Configuring ECE to Return Remaining-Balance Information in Usage Responses

You can configure ECE to return a customer's remaining-balance information in the usage response (as an in-session notification). For example, you could use the information to send customers a low-balance notification when they are about to use up all of their available balance for a service or they reach a balance amount set in your system to trigger such notifications.

ECE sends remaining-balance information for initiate and update usage requests.

The remaining-balance information that ECE returns pertains to all balances impacted by the session (that is, the balances to which the session applied balance impacts).

For charge distribution scenarios (charge sharing), ECE returns the remaining-balance information for the balances impacted by the sharer's usage.

To configure ECE to return remaining-balance information in usage responses:

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

2. Expand the ECE Configuration node.

3. Expand charging.server.

4. Expand Attributes.

5. Set the remainingBalanceCalcMode attribute to one of the following values:

   • NONE: (Default) Sends no remaining-balance information in usage responses.

     ECE does not calculate the remaining balance.

   • CURRENT_BALANCE: Sends remaining-balance information for the current balance, excluding the credit limit, in the usage response. Use this option to notify your customers of their plain vanilla remaining balance.

     ECE calculates the remaining balance by adding all sub-balances valid for the session, including the consumed reserved amount of ongoing sessions. The remaining balance is calculated as follows:

     remaining balance = sum of for valid sub-balances of (current balance + consumed reserved amount)

   • UPTO_CREDIT_LIMIT: Sends remaining-balance information capped at the credit limit in the usage response. Use this option to notify your customers of the credit limit up to which you allow them to use the balance.

     ECE calculates the remaining balance by adding all sub-balances valid for the session, including the consumed reserved amount of ongoing sessions (the consumed reservation of the balances ECE reserved for ongoing sessions) and subtracts that value from the credit limit.

     ECE calculates the remaining balance as follows:

     remaining balance = {credit limit - sum of for valid sub-balances of (current balance + consumed reserved amount)}

Configuring Taxation in ECE

By default, you configure taxation in Pricing Design Center (PDC) and the information is published to BRM and ECE. ECE then applies taxes during rating using the following:

• Tax codes, which apply simple flat taxes.

• Tax selectors, which apply tax codes based on account, service, event, and profile attributes.

• Tax exemption selectors, which reduce or eliminate the amount of tax your customers pay based on account, service, event, and profile attributes.

See "About Calculating Taxes" in BRM Calculating Taxes for more information.

You can also configure simple, fixed-rate tax, such as GST or VAT, for both charges and alterations (discounts) directly in ECE.

To configure taxation in an ECE runtime environment:

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

2. Expand the ECE Configuration node.

3. Expand charging.taxation.

4. Expand Operations.

5. Click addTaxDetails.

6. Specify values for the following parameters:

   Note:

   These parameters are mandatory. You must set all of them when configuring taxation.

   • taxCode: Enter the tax code used by the charge offer or discount offer to which the tax applies.

     The tax code is used by charge offers and discount offers to point to the tax rate that must be applied when a usage request is processed for the charge offer or discount offer.

     Enter the same tax code entered in PDC when the taxation section of the charge offer and discount offer was defined.

   • taxRate: Enter the tax rate to apply.

     For example, entering 0.20 applies a 20% tax on the total usage impact.

   • taxGlId: Enter the General Ledger ID used for the tax impact.

7. Specify an additional taxCode, taxRate, and taxGlId value for each charge offer or discount offer to which a tax applies.

Configuring How ECE Manages Active Sessions When Network Elements Fail

When a network element associated with active sessions in ECE fails, ECE receives an accounting on/off request from the network element. You can configure ECE to cancel or terminate active sessions when processing accounting on/off requests.

To configure how ECE manages active sessions when network elements fail:

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

2. Expand the ECE Configuration node.

3. Expand charging.server.

4. Expand Attributes.

5. Set the accountingOnOffMode attribute to one of the following values:

   • TERMINATE: Active sessions that have a state of Initiated are terminated when an accounting on/off request is processed.

   • CANCEL: Active sessions in ECE that have a state of Initiated are canceled when an accounting on/off request is processed.

Configuring ECE to Redirect Subscriber Sessions to a Service Portal

Service providers can redirect a subscriber session to a service portal, which is a server outside of the online charging system where specific services can be offered to the subscriber. During an online charging session, if a subscriber is about to deplete funds for the use of a service, the subscriber can be redirected to a website to top up the account. You can configure ECE to send service portal addresses back to credit-control clients. Credit-control clients use the information for redirecting a subscriber session to the service portal applicable to the business scenario.

ECE derives the service portal address (to send back to credit-control clients) based on configurable instructions that you define in redirection rules. Your redirection rules can be based on any of the following customer conditions (typically based on a combination of them):

• Whether the customer has insufficient funds

• Whether the customer has an inactive account

• Whether the customer is roaming or not roaming

• Whether the customer belongs to a specific customer segment (for example, customer accounts associated with a BRM business profile for which the payment type is Prepaid or Postpaid or the subscription type is Voice or Data).

Each redirection rule can send the session to a different service portal. For example, you might configure two redirection rules for the following business scenarios:

• Given a customer with an account using a prepaid payment type who is roaming, redirect the subscriber to http://myPrePaidRoamingRedirect.com.

• Given a customer with an account using a prepaid payment type who is not roaming, redirect the subscriber to the http://myPrePaidHomeNetworkRedirect.com URL address.

After ECE derives the service portal addresses and address types based on your redirection rules, ECE sends the address back to the credit-control client.

When the credit-control client receives the Final-Unit-Indication in the answer from ECE, the credit-control client behavior depends on the value, TERMINATE or REDIRECT, indicated in the Final-Unit-Action AVP. If you do not configure redirection rules, ECE indicates a Final-Unit-Action of TERMINATE in the usage response.

To configure ECE to redirect subscriber sessions to a service portal:

1. Create your redirection rules in a text editor and save the file.

   If you have multiple redirection rules, separate them by semicolons and save them as a single line. The single-lined redirection configuration should contain all of the redirection rules for the business scenarios that require redirecting subscriber sessions to applicable service portals.

   See "Creating Redirection Rules".

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

3. Expand the ECE Configuration node.

4. Expand charging.redirectionConfiguration.

5. Expand Attributes.

6. Set the redirectionRule attribute to a copy of your redirection-rule configuration.

   The default value is an empty string.

   If no rule is provided, no redirection is done. ECE terminates the session.

   ECE begins using the redirection-rule configuration at runtime.

   If your redirection rule uses incorrect syntax, ECE logs the Rule Evaluation Failed error at runtime in the charging-server node log files (ecs log files) and leaves the redirection rule field in the usage response empty.

   Note:

   Modifying a redirection-rule configuration in JConsole may be error prone because you cannot see the entire rule. Modifying a redirection-rule configuration in the file where you created it is recommended. Pressing Ctrl + A in the Value column of the redirectionRule variable selects all contents.

Creating Redirection Rules

A redirection rule contains conditions that must be met for the subscriber session to be redirected to a service portal.

Your redirection configuration might contain a Voice redirection rule and a Data redirection rule for redirecting subscribers to service portals relevant to those services.

You must use allowed redirection-rule conditions.

For example, the following redirection rule specifies that when a customer is roaming, the redirect address is http://RedirectRoaming.com and the redirect address type is URL:

"( (@fui AND @roamingRequest) => [redirect_type:"URL",redirect_address:
"http://RedirectRoaming.com"];

This redirection rule specifies that when a customer is both postpaid and roaming, the redirect address is http://RedirectRoaming.com, the redirect address type is URL, and the maximum redirection time is 900 seconds:

"( (@fui AND ({business_profile([name:"POSTPAID"])} == "true" )) AND 
@roamingRequest) => [redirect_type:"URL",redirect_address:
"http://RedirectRoaming.com",redirect_validity:"900"]"

Table 13-1 shows redirection-rule conditions that you can use to create redirection rules.

Table 13-1 ECE Redirection-Rule Conditions

ECE Redirection-Rule Conditions	Description
@fui	Checks in the charging result if the customer has insufficient funds (finds the Final Unit Indicator in the service context). @fui is required.
{business_profile([name:"BusinessProfileName"])} == "true" )	Accesses a business profile by looking up a business profile name and comparing its value to true. Valid values for BusinessProfileName are names of attributes you defined in the attribute-value pairs of your BRM business profiles. For example: {business_profile([name:"POSTPAID"])} == "true" )
@roamingRequest	Checks if the request is for a customer who is roaming. @roamingRequest denotes roaming. !@roamingRequest denotes not roaming. The check is done on the value of the following Diameter credit-control-request fields: GGSN-MCC-MNC-3GPP IMSI-MCC-MNC-3GPP Note: These fields are not provisioned in ready-to-use event definitions. You must provision these network fields when you enrich your event definitions in PDC.
{request_attribute([name:"FieldName"])}	Reads a payload field from a usage request. For example, the following condition reads the simple attribute 3GPP-IMSI-MCC-MNC from the payload of the usage request: {request_attribute([name:"3GPP-IMSI-MCC-MNC"])} Use this construct to use any request attribute field as a condition in your redirection rule. For example, if you want subscribers to be directed to a different URL if they have a 1234 cell phone ID, you might use the condition: {request_attribute([name:"CELL_ID"])} == "1234")
@productType	Retrieves the service. For example, a redirection rule using this condition: ( (@productType == 'DATA') AND ( {request_attribute(name:"GGSN-MCC-MNC- 3GPP"])} == "1234") ) => [redirect_type:"URL",redirect_address:"myDataTopUpRedirect.com"]

Redirection-Rule-Configuration Syntax

You configure one or multiple redirection rules in a single-lined redirection configuration with each redirection rule separated by semicolons.

The syntax for a redirection rule is the following:

((redirection_condition AND redirection_condition) AND redirection_condition) => [redirect_type:"redirect_type",redirect_address:"redirect_address",redirect_validity:"redirect_validity"];

where:

• redirection_condition is a condition that must be met for ECE to send the specified redirect type, redirect address, and redirect validity in the ECE usage response. See Table 13-1 for accepted redirection-rule conditions.

• redirect_type is the type of the service portal address (for example, URL)

• redirect_address is the service portal address (for example, a website address)

• redirect_validity is the time, in seconds, that the subscriber being redirected has to complete the task that must be done at the service portal. The value you enter here overrides the default reservation validity time of ECE. If you do not specify a redirect validity in your reservation rule, then the default reservation validity time of ECE is sent back to the credit-control client.

When you design your redirection rules, it can be helpful to create a user scenario for each and show the translation in a table, as shown in the following examples.

Example Redirection Rules

The following is an example of redirection rules.

Tip:

For visual clarity, this example shows a carriage return after each redirection rule. Your redirection-rule configuration would be one line comprised of these four redirection rules separated only by semicolons.

"( (@fui AND ({business_profile([name:"POSTPAID"])}  == "true" )) AND  @roamingRequest) => [redirect_type:"URL",redirect_address:"http://myPostPaidRoamingRedirect.com",redirect_validity:"900"];

( (@fui AND ({business_profile([name:"POSTPAID"])}  == "true" )) AND  !@roamingRequest) => [redirect_type:"URL",redirect_address:"http://myPostPaidHomeNetworkRedirect.com",redirect_validity:"900"];

( (@fui AND ({business_profile([name:"PREPAID"])}  == "true" )) AND  @roamingRequest) => [redirect_type:"URL",redirect_address:"http://myPrePaidRoamingRedirect.com"];

( (@fui AND ({business_profile([name:"PREPAID"])}  == "true" )) AND  !@roamingRequest) => [redirect_type:"URL",redirect_address:"http://myPrePaidHomeNetworkRedirect.com"]"

The four redirection rules support redirecting subscribers who have depleted funds in their account to a service portal for these scenarios:

• Given a subscriber with an account using a postpaid payment type who is roaming, redirect the subscriber to the http://myPostPaidRoamingRedirect.com URL address and allow the subscriber to use network resources for 900 seconds.

• Given a subscriber with an account using a postpaid payment type who is not roaming, redirect the subscriber to the http://myPostPaidHomeNetworkRedirect.com URL address and allow the subscriber to use network resources for 900 seconds.

• Given a subscriber with an account using a prepaid payment type who is roaming, redirect the subscriber to the http://myPrePaidRoamingRedirect.com URL address.

• Given a subscriber with an account using a prepaid payment type who is not roaming, redirect the subscriber to the http://myPrePaidHomeNetworkRedirect.com URL address.

Enabling Match Factor in ECE

ECE supports the match factor in discounting.

To enable the match factor in ECE:

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

2. Expand the ECE Configuration node.

3. Expand charging.server.

4. Expand Attributes.

5. Set the matchFactorEnabled attribute to true.

Configuring Diameter Gateway to Bypass Rating During ECE Downtime

During a planned maintenance activity or in an unplanned downtime of an ECE node, you can configure Diameter Gateway to continue receiving the CCRs and responding to the service network without rating the CCRs in real-time.

When Diameter Gateway is configured to bypass rating, it persists the Diameter CCRs to the Oracle NoSQL database. Later, when ECE nodes are restored, you can replay the persisted CCRs to the ECE charging servers for rating and updating balance impacts. With this functionality, services can be delivered to your subscribers without any interruption.

To configure Diameter Gateway to bypass rating, perform the following procedures:

1. Enable the ocsBypassExtension charging extension.

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

   2. Expand the ECE Configuration node.

   3. Expand charging.extensions.

   4. Expand Attributes.

   5. Specify the fully qualified class name of the extension for the ocsBypassExtension attribute.

2. Start the persistence of the diameter messages. See "Managing the Persistence of Usage Requests During ECE Downtime".

3. After the ECE nodes are restored, use Diameter Replayer to replay the CCRs to ECE for rating and updating balance impacts. See "Replaying Persisted Requests into ECE".

Managing the Persistence of Usage Requests During ECE Downtime

When Diameter Gateway is configured to bypass rating during a planned maintenance activity or in an unplanned downtime of ECE, Diameter Gateway receives CCRs and persists them to Oracle NoSQL Database. Later, when the ECE nodes are restarted, you stop the bypass rating extension and replay the persisted messages to the ECE charging servers for rating and updating balance impacts.

Managing persistence of diameter requests involves starting and stopping the persistence of the requests. Before persisting the incoming diameter requests, ensure that the ocsBypassExtension charging extension is enabled. See "Configuring Diameter Gateway to Bypass Rating During ECE Downtime" for information on configuring Diameter Gateway to bypass rating.

For planned maintenance activities, you start the persistence of usage requests before the ECE nodes become unavailable. During an outage, persistence of diameter requests starts only if the ocsBypassExtension charging extension is enabled. If only the extension is enabled and bypass rating is not started, the usage requests do not flow to the ECE Charging Server nodes. In such a scenario, Diameter Gateway returns Error 5012 for the requests.

Note:

The bypass rating functionality is supported for Gy diameter messages only.

To persist incoming diameter requests:

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

2. Expand the DiameterGateway node.

3. Expand BFTTask.

4. Expand Operations.

5. Click startByPass.

   The Diameter Gateway starts persisting the incoming requests.

In planned maintenance activities or in unplanned downtime, once the ECE nodes become available and start running, you must stop the persistence of the requests. Otherwise, messages are persisted even after the ECE nodes are up and running, which results in a large volume of requests that need to be replayed.

To stop persisting the requests, click stopByPass. Before doing this, you can check if persistence of requests is running by clicking BFTRunning. If bypassing rating is enabled, this field shows True. Otherwise, it shows False.

Replaying Persisted Requests into ECE

When Diameter Gateway is configured to bypass rating during a planned maintenance or unplanned downtime of ECE, Diameter Gateway persists the incoming CCRs to the Oracle NoSQL Database. Later, during a non-peak period, you replay the persisted CCRs to the ECE charging server when the ECE server is restored and is ready to process real-time requests. When you replay the persisted CCRs, the requests are passed to the ECE charging server, which then rates the CCRs and updates the balance impacts. You can plan for when to start replaying the persisted messages, considering replaying the persisted messages can have performance impacts while real-time requests are also processed. Before replaying the persisted requests, ensure that bypass rating extension is disabled and the ECE nodes are up and running. To check if bypass rating is stopped, click BFTRunning in ECE MBeans.

To replay the persisted requests into ECE:

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

2. Expand the DiameterGateway node.

3. Expand BFTTask.

4. Expand Operations.

5. Click persistedMessageCount to view the number of requests that have been persisted and are ready for replay.

6. Click startBFTReplayer.

   The replayer starts replaying the persisted messages to the ECE charging servers. As messages are replayed to the servers, the number of persistedMessageCount keeps decreasing until it becomes 0.

   The replayedMessageCount field shows the number of requests that are being replayed. As requests are replayed, the number of replayedMessageCount keeps increasing until it matches the initial count of persistedMessageCount.

You stop replaying the messages once all the persisted messages are replayed into the ECE charging servers.

To stop replaying the persisted messages:

1. Check the status of the replayer by clicking BFTReplayerRunning. Ensure that this field shows Running.

2. Check the status of the replayedMessageCount field. Ensure that this field shows 0, which indicates that all the persisted messages are replayed into the ECE charging servers.

   • replayedMessageCount shows the number of Diameter messages that are replayed to the ECE charging server by the current instance of Diameter Replayer.

   • persistedMessageCount shows the number of Diameter messages that have been persisted to Oracle NoSQL database, but are yet to be replayed.

3. Click stopBFTReplayer.

   Replaying of messages is stopped.

Accessing ECE Configuration MBeans

For all configurations, start by accessing the ECE configuration MBeans:

1. Log on to the driver machine.
2. Start the ECE charging servers (if they are not started).
3. Connect to the ECE charging server node enabled for JMX management.

   This is the charging server node set to start CohMgt = true in the ECE_home/config/eceTopology.conf file, where ECE_home is the directory in which ECE is installed.

4. Start a JMX editor that enables you to edit MBean attributes, such as JConsole.
5. In the editor's MBean hierarchy, find the ECE configuration MBeans.