This chapter provides instructions for configuring usage-charging business rules for Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).
This section describes the different usage-charging business rules you can configure.
For information about configuring usage-charging business rules, see "Configuring Usage-Charging Business Rules".
ECE authorizes and reserves a balance or active reservation for a session request. ECE bases the active reservation on the requested service units of the session request (Initiate or Update request types). ECE sends the validity time for the active reservation or reservation validity back to the network mediation client. The reservation validity specifies how long a session can continue before the client must ask for a reauthorization of resources for further usage.
ECE supports a configurable reservation expiration, which specifies how long a session can continue before the client must report the consumed usage to ECE.
ECE uses the used service units to record the reserved balance as a consumed reservation. If the network mediation client does not communicate the used service units within the reservation expiration, ECE considers the reserved balances to be available balances for subsequent session requests. The reserved balances that are available are cleaned up as part of administrative processes when the session terminates.
Setting the reservation expiration time too low takes network activity to report usage. Setting the value too high increases the risk of revenue leakage if the customer uses up the balance before the reservation expiration time expires.
You configure the reservation validity as a systemwide setting.
ECE sends the reservation expiration and reservation validity information in the usage response.
The validity time is set for each session and gets reset upon each interim request received for the session.
After the validity time for a session expires, any resources reserved are released and become available to other active sessions for the same product.
For information about configuring reservation validity, see "Configuring Reservation Validity and Expiration".
When ECE receives usage requests in which the REQUESTED_UNITS block is not set (the Requested-Service-Units AVP value is missing), ECE uses the systemwide quota you specify. For each product and rateable usage metric (RUM) combination, you configure a systemwide initial quota and a systemwide incremental quota for reservation. For usage requests that have an Initiate operation type, ECE uses the systemwide initial quota for the reservation. For usage requests that have an Update operation type, ECE uses the systemwide incremental quota for the reservation.
For information about configuring reservation quota, see "Configuring Reservation Quota for Products".
For information about setting the reservation quota when using incremental or cumulative accounting, see "Using Incremental or Cumulative Accounting for Usage Requests".
You can configure a minimum quantity for reservation for charging events.
Some charging events cannot be charged in fragments. For example, you cannot charge for half of an SMS message. In this case, you would set a minimum quantity reservation of 1 for charging an SMS event.
If the customer does not have enough balance to reserve the minimum quantity of the charging event, ECE sends a usage response for the request as INSUFFICIENT_RATED_QUANTITY.
For information about configuring minimum quantity reservation, see "Configuring a Minimum Quantity for Reservation".
ECE provides the capability to provide Advice of Promotion (AoP) information enabling the operator to notify the customer that a better price could be obtained for the service they are about to use. ECE provides the AoP information as defined by 3GPP (TS22.086). The operator can choose to use this information in whatever way is relevant to the specific service being offered. For example, a network operator can send the AoP information in an Interactive Voice Response (IVR) pre-call announcement for a Voice service.
The AoP function can be used to notify a customer of a preferential price that would be available within the configured time window. If a reduced rate is available within this window, the AoP will be returned with an indication of the price to which the new rate would be applicable.
To support AoP, ECE determines whether a better rate for using a service is available near the time that the customer's usage request is received. ECE relays that information back to the network mediation system, which passes the message on to the customer.
ECE implements AoP as follows:
A customer makes a request to initiate a session, to debit a specific or calculated amount of a resource, or to generate a price estimation for using a resource.
The ECE charging server calculates the charge for the request.
If AoP is enabled, ECE adds a time offset to the start and end time of the request and recalculates the charge using the offset time period (the new start and end time).
You configure how much of a time offset to use. See the discussion about usage-charging configuration in BRM Elastic Charging Engine System Administrator's Guide for instructions.
If the recalculated charge is less expensive for the customer, ECE sends the information about potential savings back to the network mediation system in the usage response.
ECE applies AoP when AoP is configured at the ECE system level. Configure AoP at the system level by using the configuration service. See "Configuring Advice of Promotion" for information about configuring AoP.
Note the following details about AoP:
AoP is a systemwide configuration (it is not configured on a per-charge offer basis).
The default configuration of AoP gives advice based on time.
When applying AoP, ECE uses charge offers and discount offers that are eligible when the request is received to recompute the charge for the offset time period. If a different charge offer or discount offer applies to the future offset time period, AoP may advise a promotion where there is none or may not advise a promotion when a promotion is available.
When using AoP, ensure that your rate plans have tiered consumption configured accurately so as to prevent a credit breach of noncurrency balance elements.
By default, ECE uses the rounding rules configured in Pricing Design Center (PDC) for a currency or noncurrency resource to round the balance impact amount for processing stages like charging, discounting, and taxation. Rounding rules can be different for each processing stage. For information on configuring the rounding rules for resources in PDC, see the PDC Help.
However, you can also configure rounding in ECE for a currency or noncurrency resource by specifying rules for how the ECE rounds the balance impact amount for processing stage like charging, discounting, and taxation. The rounding rules you specify are applied at the system level so the same rule is applied across all processing stages. The rounding is also applied to reverse-rating calculations.
If a rounding rule is not configured in PDC for a resource, ECE uses the rules configured at the system level to round the balance impact amount. For information about resource rounding, see the discussion about resource rounding in BRM Setting Up Pricing and Rating.
The rules you can specify for rounding are as follows:
Scale
You can specify a rule for how many digits to the right of the decimal point to allow. The default scale is 2.
Rounding mode
You can specify a rule for the rounding behavior according to the Java math rounding enum. The default is HALF_UP.
Go to the Java SE technical documentation web site for information about using the Java math rounding enum:
http://docs.oracle.com/javase/6/docs/api/java/math/RoundingMode.html
For information about configuring rounding for currency and noncurrency resources, see "Configuring Rounding for a Currency Resource" and "Configuring Rounding for a Noncurrency Resource".
Example of Currency Rounding for a Charge
If you allow two digits to the right of the decimal point and you round down towards zero (DOWN rounding mode), ECE takes a calculated charge of 0.509 USD and rounds it to 0.50 USDs.
Example of Noncurrency Rounding for a Charge
If you allow zero digits to the right of the decimal point and you round towards positive infinity (UP rounding mode), ECE takes a charge of 0.509 bonus point and rounds the value to 1 bonus point.
Examples of Currency Rounding for Discounts
If you allow zero digits to the right of the decimal point and you round down towards zero (DOWN rounding mode), ECE takes a discount of -2.5 USD and rounds the value to -2 USD.
If you allow zero digits to the right of the decimal point and you round towards negative infinity (FLOOR rounding mode), ECE takes a discount of -2.5 USD and rounds the value to -3 USD.
If you allow two digits to the right of the decimal point and you round down towards zero (DOWN rounding mode), ECE takes a discount of -0.075 USD and rounds the value to -0.07 USD.
When ECE applies reverse rating for a service in which events are rated by using multiple RUMs (for example, when applying reverse rating for a session event where both Occurrence and Duration are RUMs by which the event is measured), fractional values of the authorized resource quantity may result. You can enable ECE to round up the authorized resource quantities to the nearest whole number.
Rounding up the authorized resource quantity may result in customers exceeding their credit limits.
If your business requires that your customers must be able to use all of their balances, configure ECE to round up the authorized resource quantity.
For information about configuring rounding for reverse rating when rating is based on multiple RUMs, see "Configuring Rounding for Reverse Rating on Multiple RUMs".
Unlike credit limits, which prevent revenue loss and are strictly enforced by Oracle Communications Billing and Revenue Management (BRM), policy tier thresholds must be crossed to trigger implementation of business rules, such as reduced quality of service (QoS) for subscribers who download an excessive amount of data.
In both cases, BRM calculates authorization amounts as a subscriber nears a limit or threshold:
For credit limits, BRM authorizes the remaining balance and sends a final unit indicator (FUI), which makes the entire remaining balance available for use. If the balance is not topped up before it is completely consumed, the session is terminated.
For policy tier thresholds, BRM cannot authorize an amount above the threshold, even if the subscriber's credit balances are sufficient to cover the charges. Instead, BRM authorizes the remaining balance up to the policy threshold but does not send an FUI. Therefore, only about 80 percent of the remaining balance is made available for use. The session ends when the remaining balance becomes so small that the service can no longer be supported.
To enable subscribers to continue using a service as they near a policy tier threshold, you must configure a breach tolerance for the threshold. A breach tolerance is the amount of usage exceeding the threshold for which a customer can be authorized. It permits BRM to authorize a usage amount that crosses the policy tier threshold. When the threshold is crossed, the service continues under a new business rule, such as lower QoS for larger download totals.
For example, suppose the network sends a usage request for 200 MB, but adding that to a subscriber's current 1.9 GB policy counter balance will cause the balance to breach a 2 GB policy tier threshold. In this case, BRM does one of the following:
Without Breach Tolerance: If a breach tolerance is not configured, BRM makes only about 80 MB available to prevent the usage from exceeding the policy tier threshold. When usage reduces the 80 MB balance to the point that the remaining balance cannot support the service, the session ends.
With Breach Tolerance: If a breach tolerance of 100 or more MB is configured, BRM authorizes the entire 200 MB request. This enables the subscriber's usage to cross the 2 GB policy tier threshold by 100 MB. As soon as the policy tier threshold is crossed, a change in the quality of service is triggered, and the service continues under the new policy.
You can set a breach tolerance for each balance element used in a policy counter. You decide what tolerance value is appropriate for your business needs.
For information about configuring a tolerance for credit limit breaches, see "Configuring a Tolerance for Policy-Tier Threshold Breaches for Policy-Driven Charging".
This section provides instructions for configuring usage-charging business rules in the ECE runtime system.
For information about the different usage-charging business rules, see "About Usage-Charging Business Rules".
To configure usage-charging business rules, see the following topics:
For more information about each usage-charging attribute, see the BizParamConfigMBean package in BRM Elastic Charging Engine Java API Reference.
For information about reservation validity, see "About Reservation Validity".
To configure the reservation validity and expiration:
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.reservationConfig.
Expand Attributes.
Specify values for the following attributes:
validityTime: Enter the amount of time, in seconds, to use as the reservation validity. This specifies how long a session can continue before the client must ask for a reauthorization. The default value is 3600 (one hour).
reservationDuration: Enter the amount of time, in seconds, to use as the reservation expiration. This specifies how long a session can continue before the client must report the consumed usage to ECE. The default value is 3600 (one hour).
For detailed information, see ReservationConfigMBean in the BizParamConfigMBean package of BRM Elastic Charging Engine Java API Reference.
For information about reservation quota, see "About Reservation Quota".
To configure the reservation quota for products:
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.reservationConfig.
Expand Operations.
For each product that you offer, do the following:
Select setDefaultReservationQuota.
Specify values for the following parameters:
productType: Enter the name of the product defined in the ECE request specification data (for example, VOICE or SMS).
rum: Enter the name of the attribute defined in the ECE request specification data.
Important:
Though the parameter name is rum, its value must be the attribute name specified in the REQUESTED_UNITS block of the request specification data, not the RUM name. For example, if you send attribute INPUT_VOLUME in the usage request, enter INPUT_VOLUME as the rum attribute's value.initialQuota: Enter the initial quota for this product-RUM combination. The value must be decimal-compliant (Java BigDecimal). ECE uses this value to populate the REQUESTED_UNITS blocks of all Initiate-type usage requests whose Requested-Service-Units AVP value is missing.
incrementalQuota: Enter the incremental quota for this product-RUM combination. The value must be decimal-compliant (Java BigDecimal). ECE uses this value to populate the REQUESTED_UNITS blocks of all Update-type usage requests whose Requested-Service-Units AVP value is missing.
unit: Enter the unit of measurement for the quota, such as seconds, minutes, events, or megabytes.
Click the setDefaultReservationQuota button.
For information about minimum quantity for reservation, see "About Minimum Quantity for Reservation".
To configure the minimum quantity for reservation:
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.reservationConfig.
Expand Operations.
Select setMinAuthorizedQuota.
Specify values for the following parameters:
productType: Enter the name of the product for which you are setting a minimum quantity reservation. Enter the name as it is defined in the ECE request specification data (for example, VOICE or SMS).
rum: Enter the name of the attribute defined in the ECE request specification data.
Important:
Though the parameter name is rum, its value must be the attribute name specified in the REQUESTED_UNITS block of the request specification data, not the rateable usage metric (RUM) name. For example, if you send attribute INPUT_VOLUME in the usage request, enter INPUT_VOLUME as the rum attribute's value.minAuthorizeQuota: Enter the minimum amount of the specified unit that can be reserved for this product-RUM combination.
unit: Enter the unit of measurement for the quota, such as seconds, minutes, events, or megabytes.
Click the setMinAuthorizedQuota button.
You configure Advice of Promotion (AoP) as a systemwide setting.
See "About Advice of Promotion" for information about how ECE supports AoP.
To configure Advice of Promotion:
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.
Specify values for the following attributes:
aopEnabled: Enter true to enable AoP or false to disable AoP.
aopVariance: Enter an amount of time in the ISO 8601 duration format (for example, PT10M, which specifies 10 minutes).
ECE uses the time you specify to offset the start and end times of the request and recalculate the charge for the offset period.
For more information about the duration format, see the ISO 8601 documentation.
You can configure rounding for a currency resource by specifying rules for how the rating engine rounds the balance impact amounts it calculates. See "About Rounding Charging Results" for information about rounding rules.
The rules you specify are applied as a systemwide configuration for rounding the balance impact amounts of all charges, discounts, and chargeshares. The rounding is also applied to all reverse rating calculations and taxation calculations.
To configure rounding for a currency resource:
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.
Specify values for the following attributes:
currencyScale: Enter the number of digits you allow to the right of the decimal point for a calculated impact amount.
For example, enter 2 if you allow two digits to the right of the decimal point.
The default is 2.
currencyRoundingMode: Enter the rounding mode that determines the rounding behavior by entering the string representation of the Java math rounding enum.
For more information, see the Java SE technical documentation web site:
http://docs.oracle.com/javase/6/docs/api/java/math/RoundingMode.html
For example, enter UP to round up away from zero or DOWN to round down towards zero.
The default is HALF_UP.
You can configure rounding for a noncurrency resource by specifying rules for how the rating engine rounds the balance impact amounts it calculates. See "About Rounding Charging Results" for information about rounding rules.
The rules you specify are applied as a systemwide setting and apply for rounding the balance impact amounts of all charges, discounts, and chargeshares. The rounding is also applied to all reverse rating calculations and taxation calculations.
To configure rounding for a noncurrency resource:
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.
Specify values for the following attributes:
nonCurrencyScale: Enter the number of digits you allow to the right of the decimal point for a calculated impact amount.
For example, enter 2 if you allow two digits to the right of the decimal point.
The default is 2.
nonCurrencyRoundingMode: Enter the rounding mode that determines the rounding behavior by entering the string representation of the Java math rounding enum.
For more information, see the Java SE technical documentation web site:
http://docs.oracle.com/javase/6/docs/api/java/math/RoundingMode.html
For example, enter UP to round up away from zero or DOWN to round down towards zero.
The default is HALF_UP.
When ECE performs the reverse rating service in which events are rated by using multiple RUMs, fractional values may result for the authorized resource. You configure whether to round up the fractional value of the impacted resource quantity as a systemwide setting. ECE authorizes an additional RUM unit when the quantity is a fraction.
To configure whether to round up the fractional value of the authorized resource quantity by authorizing an additional RUM unit:
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 reverseRateUseAllBalances attribute to one of the following values:
To round up the fractional value of the authorized balance quantity, enter true.
This option allows customers to use all balances even if they might exceed their credit limits by a small amount.
To disallow the fractional value of the authorized balance quantity to be rounded up, enter false.
This option does not allow customers to exceed their credit limits.
The default is false.
You can configure a tolerance for policy-tier threshold breaches when you implement policy-driven charging. See "About a Tolerance for Policy-Tier Threshold Breaches for Policy-Driven Charging" for information.
To configure a tolerance for policy-tier threshold breaches:
Before charging servers are started, open ECE_home/oceceserver/config/management/charging-settings.xml and uncomment the following lines:
<toleranceConfigMappingGroup config-class="java.util.ArrayList">
<toleranceConfig
config-class="oracle.communication.brm.charging.appconfiguration.
beans.policy.ToleranceConfig"
balanceElementId="12345" tolerance="1.25"/>
<toleranceConfig
config-class="oracle.communication.brm.charging.appconfiguration.
beans.policy.ToleranceConfig"
balanceElementId="34567" tolerance="3"/>
</toleranceConfigMappingGroup>
Save the file.
On the driver machine, change directory to the ECE_home/oceceserver/bin directory.
Start Elastic Charging Controller (ECC):
./ecc
Start your charging servers:
start server
Access the ECE MBeans:
Log on to the driver machine.
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.policyConfig.
Expand Operations.
Select setPolicyTolerance.
For each balance element (policy counter) to which offer profiles apply in your system, do the following:
Specify values for the following parameters:
beid: Enter the balance element ID of the balance element.
tolerance: Enter the RUM units allowed to exceed the authorized usage quantity that ECE returns to the network for a specified charging session.
The value must be greater than 0. Base it on your business needs.
Your customers can use all balances and exceed their policy-tier threshold limits by the specified number of RUM units.
Click the setPolicyTolerance button.
When more than one validity-based subbalance is available for a usage request, consumption rules determine from which balance bucket ECE is to consume first. For example, if a customer has several groups of free minutes that expire at different times, you use consumption rules to indicate which minutes to use first, based on the validity period start time and end time. Consumption rules are typically configured at the balance element level when you define pricing in the pricing application such as PDC. Consumption rules can also be configured at the customer balance level by the customer and subscription management components of the BRM system. For information about configuring consumption rules in PDC and BRM, see the PDC documentation and the BRM documentation.
When ECE receives a usage request for which no consumption rules are configured, ECE applies its own systemwide consumption rules for processing the usage request.
To configure ECE systemwide consumption rules:
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 systemConsumptionRule attribute to one of the following systemwide consumption rules:
EARLIEST_START
LATEST_START
EARLIEST_EXPIRATION
LATEST_EXPIRATION
EARLIEST_START_LATEST_EXPIRATION
EARLIEST_START_EARLIEST_EXPIRATION
LATEST_START_LATEST_EXPIRATION
LATEST_START_EARLIEST_EXPIRATION
EARLIEST_EXPIRATION_EARLIEST_START
EARLIEST_EXPIRATION_LATEST_START
LATEST_EXPIRATION_EARLIEST_START
LATEST_EXPIRATION_LATEST_START
NONE: When the attribute is set to NONE, the default consumption rule is not configured, and the order for consuming balances is undefined.
By default, this attribute is set to EARLIEST_START_EARLIEST_EXPIRATION.
Credit profiles define the credit limits, credit floors, and credit threshold combinations that can be associated with balance elements. You design credit profiles in BRM and can customize them for individual customers. Credit profiles are applied to individual customers as part of the registration process, when customers purchase your products.
ECE must have systemwide (or default) credit profiles. Systemwide credit profiles are used by ECE when it receives a usage request for which the customer's credit profile has not been defined for the customer. ECE uses systemwide credit profiles to establish the credit for customers who have no credit profile.
You define the systemwide credit profiles in BRM. You must include definitions for the ECE systemwide credit profiles for currency (ID = 0) and for noncurrency (ID = 2).
Service providers can redirect a subscriber session to a service portal, 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 web site 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 http://myPrePaidHomeNetworkRedirect.com.
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.
To redirect a subscriber session to a service portal:
Create your redirection rules in a text editor and save the file.
If you have multiple redirection rules, you must 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.
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.redirectionConfiguration.
Expand Attributes.
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.
Tip:
Modifying a redirection-rule configuration in the JConsole window 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.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.
The following scenario:
When the customer is roaming
The redirect address is http://RedirectRoaming.com
The redirect address type is URL
Is redirected by using the following redirection rule:
"( (@fui AND @roamingRequest) => [redirect_type:"URL",redirect_address: "http://RedirectRoaming.com"];
The following scenario:
When the customer is Postpaid
And the customer is roaming
The redirect address is http://RedirectRoaming.com
The redirect address type is URL
The redirection must be performed within 900 seconds
Is redirected by using the following redirection rule:
"( (@fui AND ({business_profile([name:"POSTPAID"])} == "true" )) AND
@roamingRequest) => [redirect_type:"URL",redirect_address:
"http://RedirectRoaming.com",redirect_validity:"900"]"
Table 9-1 shows redirection-rule conditions that you can use to create redirection rules.
Table 9-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" ) For example:
{business_profile([name:"POSTPAID"])} == "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. |
|
@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:
Note: These fields are not provisioned in ready-to-use event specifications. 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 product type. 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 9-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 web site 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.
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 http://myPostPaidRoamingRedirect.com 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 http://myPostPaidHomeNetworkRedirect.com 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 http://myPrePaidRoamingRedirect.com.
Given a subscriber with an account using a prepaid payment type who is not roaming, redirect the subscriber to http://myPrePaidHomeNetworkRedirect.com.
By default, ECE generates a rated event for a network session only when a Diameter terminate operation ends the session. You can also configure ECE to generate a rated event whenever a Diameter update operation occurs during the network session. Such events are called midsession rated events. For more information, see the discussion about midsession rated events in BRM Elastic Charging Engine Concepts.
To generate midsession rated events, you enable the feature and then define conditions, called triggers, that initiate the generation of such events. Triggers are based on one or more of the following criteria:
Duration (for example, every 4 hours that a session is active)
Quantity (for example, whenever downloaded data totals 70 MB or more)
Time of day (for example, daily at 23:00:00 during the life of the session)
Each trigger is associated with a service-event pair. If an ongoing session meets the trigger conditions at the time an update operation occurs, a midsession rated event for the specified service is generated.
Note:
Trigger conditions are examined only during update operations. If a trigger condition is "every 200 MB" but an update operation does not occur until the total is 288 MB, the rated event is for 288 MB, not 200 MB. The same applies to duration criteria.For example, the following code triggers the generation of a rated /data_usage event for a DATA service's ongoing network session if at least one of the following conditions is true:
The combined values of the event's input_volume and output_volume fields total 70 MB or more.
The current time minus the time the last midsession rated event was generated is greater than or equal to 7 hours.
The current time is greater than or equal to 11 p.m.
<midSessionCdrConfiguration config-class="oracle.communication.brm.charging.appconfiguration.beans.midsessioncdr.MidSessionCdrConfiguration" midSessionCdrEnabled="true"> <productConfigurationGroup config-class="java.util.ArrayList"> <productLifecycleConfiguration config-class="oracle.communication.brm.charging.appconfiguration.beans. midsessioncdr.MidSessionCdrConfiguration" productType="DATA"> <eventConfigurationGroup config-class="java.util.ArrayList"> <eventConfiguration config-class="oracle.communication.brm.charging.appconfiguration.beans. midsessioncdr.MidSessionCdrConfiguration" eventType="DATA_USAGE"> <triggerConfiguration config-class="oracle.communication.brm.charging.appconfiguration.beans. midsessioncdr.MisSessionCdrTriggerConfiguration" durationunit="HOURS" durationvalue="7"/> <triggerConfiguration <!-- Use ";" to separate fields. Values in the fields are summed. --> quantiytfields="input_volume;output_volume" quantityunit="MEGABYTES" quantityvalue="70"/> <triggerConfiguration config-class="oracle.communication.brm.charging.appconfiguration.beans. midsessioncdr.MidSessionCdrConfiguration" timeofday="23:00:00"/> </eventConfiguration> </eventConfigurationGroup> </productLifecycleConfiguration> </productConfigurationGroup> </midSessionCdrConfiguration>
Note:
All conditions in a TriggerConfiguration block must be met (criteria are assumed to be joined by AND).
If a trigger contains multiple TriggerConfiguration blocks, the conditions in only one block must be met (blocks are assumed to be joined by OR).
To configure ECE to generate midsession rated events:
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.midSessionCdrConfiguration.
Expand Attributes.
Set the midSessionCdrEnabled attribute to true.
Define trigger conditions for one or more service-event pairs:
Expand Operations.
Click addOrUpdateMidSessionCdrTriggerDetails.
Specify values for the parameters listed in Table 9-2:
Table 9-2 Parameters for Defining Midsession Rated Event Triggers
| Parameter | Description |
|---|---|
|
productType |
Name of the service for which you are creating the trigger (for example, "DATA"). |
|
eventType |
Name of the event for which you are creating the trigger (for example, "DATA_USAGE"). |
|
triggerName |
Name of the trigger you are defining. |
|
qtyFields |
Name of one or more event fields to which a quantity condition applies (for example, "input_volume; output_volume"). Use a semicolon ( ; ) to separate field names. Values in the fields are summed. |
|
qtyUnit |
Unit of measure for conditions based on quantity (for example, "MEGABYTES"). |
|
qtyValue |
Total quantity of the unit that triggers event generation (for example, "70"). |
|
durationUnit |
Unit of measure for conditions based on duration (for example, "HOURS"). |
|
durationValue |
Amount of the unit that triggers event generation (for example, "70"). |
|
timeOfDay |
A particular time of day in a 24-hour clock at which to generate the event (for example, "23:00:00", which indicates 11 p.m.). Use the hh:mm:ss format. |
A trigger with one TriggerConfiguration block is created for the specified service-event pair. All conditions in the block (quantity, duration, time of day) must be met to generate a midsession rated event.
(Optional) Do one of the following:
To define another trigger, click the plus sign in the panel's upper right corner, and repeat step 4 for a different service-event pair.
To add a TriggerConfiguration block to the current trigger, click the plus sign in the panel's upper right corner, and repeat step 4 for the same service-event pair.