This chapter provides instructions for configuring charging runtime options for Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).
This sections describes the charging runtime options you configure in ECE:
ECE supports a fixed rate tax (a flat-rate taxation which is also known as GST or VAT).
You can apply a tax on both charges and alterations (discounts).
For information about configuring taxation, see "Configuring Taxation".
For information about notifications you can configure, such as those for online charging (typically for use by the online network mediation system), as well as those used for sending data to other applications in the charging system, see the discussion about notifications in BRM Elastic Charging Engine Concepts.
ECE supports server-initiated reauthorization requests (RAR).
ECE can perform server-initiated reauthorization during an ongoing session. This allows 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 by the following:
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 resource that expires mid-session, a resource 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:
A subscriber is in a call session. The subscriber adds the called number of that session to a Friends and Family list.
Because a Friends and Family discount might change the charge amount, ECE sends a request to the network.
In response, the network sends a reauthorization request.
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 resources are added to a sharing group owner's account.For information about configuring server-initiated RAR in ECE, see "Configuring Support for Server-Initiated Reauthorization Requests".
For a debit request, ECE returns a correlation ID in the usage response and stores the correlation ID in a debit map for each product. If a refund request is later received for the debit request, ECE uses the correlation ID to validate the refund request (refund requests are valid only when they are associated with a debit request correlation ID).
The debit request information in the debit map is transient data, and you can configure the number of debit requests to be retained per product. By default, debit request information is stored for 10 debit request operations (for each product) at any given time. For example, if there are 10 entries in the debit map and a new debit request is received, the entry for the oldest debit request is deleted from the debit map and an entry for the new debit request is added.
For information about configuring debit request history, see "Configuring Debit Request History".
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. See "Configuring Open-Session Management for Network Element Failures" for instructions.
This section provides instructions for configuring charging-related runtime options:
Configuring the Return of Remaining Balances in Usage Responses
Configuring ECE to Align the Validity Start and End of Conditional Balance Impacts
Configuring Support for Server-Initiated Reauthorization Requests
Configuring Open-Session Management for Network Element Failures
To configure taxation:
Note:
For taxation to work in the ECE runtime environment, you must set the following mandatory parameters.Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.taxation.
Expand Operations.
Click addTaxDetails.
Specify values for the following parameters:
Important:
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.
Specify an additional taxCode, taxRate, and taxGlId value for each charge offer or discount offer to which a tax applies.
You can configure ECE to return the 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 resources that were impacted by the session; that is, the resources to which the session applied balance impacts.
For charge distribution scenarios (charge sharing), ECE returns the remaining-balance information for the resources impacted by the sharer's usage.
For detailed information about the remaining-balance information returned in the usage response, see the documentation for oracle.communication.brm.charging.messages.usage (for remaining balance information) in BRM Elastic Charging Engine Java API Reference.
To configure ECE to return remaining-balance information in the usage response:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
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)}
When you design your pricing components in PDC, you can create charges for which conditional balance impacts are configured. See PDC User's Guide for information about conditional balance impacts.
You can configure ECE to align the validity start and validity end of a conditional balance impact based on the period start set in PDC.
For example, if a customer activates a conditional balance impact that is valid for three days and period start is set to ALIGN_WITH_OFFER_START, and the purchased charge offer is no longer valid after one day, this configuration specifies whether the conditional balance impact can still be used after the purchased charge offer validity has ended. If ECE does not align the validity end of the conditional balance impact with the validity end of the purchased charge offer, the balance could be used by another charge offer.
To configure ECE to align the validity start and end of conditional balance impacts:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
Set the alignRecurringImpactsToOffer attribute to true.
At run time, if this is set to true and ECE receives a usage request for which a conditional balance impact applies, ECE compares the validity start and end of the conditional balance impact with the usage validity start and end of the associated charge offer that the customer purchased. If the validity start or end of the conditional balance impact breaches the validity start or end of the associated purchased charge offer, ECE aligns both the validity start and end of the conditional balance impact with those of the charge offer.
To enable server-initiated reauthorization requests (RAR):
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
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.
Under the ECE Configuration node, expand charging.server.
Expand Attributes.
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.
By default, this parameter is set to END_TIME.
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.
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.To configure the debit request history:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
Set the debitRefundSessionEvictionSize attribute to the maximum number of debit requests to log in the debit map at one time.
This is the number of debit requests to keep in history so that refunds can be made against them.
To configure how to manage open sessions in ECE when a network element associated with those open sessions fails:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
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.