Managing Online Charging Sessions

14 Managing Online Charging Sessions

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

Topics in this document:

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.

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 by 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:

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 balances are added to a sharing group owner's account.

To enable server-initiated reauthorization requests:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
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.
- 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.

Customizing Server-Initiated Reauthorization for Sharing Groups

By default, when ECE performs a server-initiated RAR during a customer's ongoing session, it generates RAR notifications for all of the customer's ongoing sessions.

You can customize ECE to support server-initiated RARs for sharing group members. In this case, ECE initiates RAR notifications for all ongoing sessions of the customer responsible for triggering the RAR along with all ongoing sessions of the sharing group members. For example, assume a sharing group includes accounts A, B, C, and D, and accounts A and C have ongoing sessions using the sharing group balance. If an RAR is triggered for account C, ECE sends RAR notifications for account A's and C's ongoing sessions.

To do so, extend ECE at the prerating, post-charging, and post-rating extension points and use these ECE SDK sample programs: SampleRarPostChargingExtension, SampleRarPostRatingExtension, and SampleRarPreRatingExtension. See "Rating/Charging Extension – Triggering RAR Notifications" for more information.

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. 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 can return remaining-balance information for initiate and update usage requests. For DEBIT_UNIT usage requests, you can also configure whether ECE aggregates the currency and non-currency balance values returned in the response

The remaining-balance information that ECE returns pertains to all balances impacted by the usage request.

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:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
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 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 valid sub-balances of (current balance + consumed reserved amount)}
```
- Debit_Unit: You can configure whether ECE returns aggregated or non-aggregated balance values for currency and non-currency balances in usage responses.
To configure the aggregation of balance values returned for DEBIT_UNIT usage requests, also set the following attributes:
- aggregateCurrencyBalanceForDebitUnit: Specifies whether ECE aggregates currency balance values in Debit_Unit usage responses.
  - true: When set to true, ECE returns aggregated currency balance values. This is the default.
  - false: ECE returns non-aggregated currency balance values.
- aggregateNonCurrencyBalanceForDebitUnit: Specifies whether ECE aggregates non-currency balance values in Debit_Unit usage responses.
  - true: ECE returns aggregated non-currency balance values.
  - false: ECE returns non-aggregated non-currency balance values. This is the default.
  Alternatively, you can configure these attributes in the ECE_home/config/management/charging-settings.xml file and then restart ECE for the changes to take effect.

Configuring Default Taxes in ECE

You configure taxes in Pricing Design Center (PDC). In PDC, you also define the following for each charge:

When to apply taxes: at event time, during billing, or dynamically.
How to apply taxes: with tax codes or tax selectors. Tax selectors apply tax codes based on account, service, event, and profile attributes.

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

PDC publishes this tax configuration information to BRM and ECE. ECE honors these tax assignments during rating.

If a charge does not include a tax time or tax rate, ECE applies tax during billing and assigns the default tax code and rate that you configure in ECE.

Note:

ECE supports only simple, fixed-rates, such as GST or VAT, for the default tax.

To configure ECE to apply a default tax rate, tax code, and general ledger ID (G/L ID) for a charge offer or a discount offer:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
Expand the ECE Configuration node.
Expand charging.taxation.
Expand Operations.
Click addTaxDetails.
Specify values for the following required parameters:

Note:

These parameters are mandatory. You must set all of them when configuring taxation.
- taxCode: Enter the tax code for the associated charge offer or discount offer. Use the same tax code you defined in PDC for the related charge or discount offer.
  
  ECE uses this tax code to look up the tax rate when processing usage for the associated offer.
- taxRate: Enter the tax rate to apply. For example, 0.20 applies a 20% tax to the total usage impact.
- taxGlId: Enter the G/L ID to use for the tax impact.
  
  Note:
  
  The taxGlId attribute specifies only the default tax G/L ID. To assign tax G/L IDs based on the rating period type or other event attributes, implement the logic in a custom extension at the post-rating extension point.
For each additional charge offer or discount offer that requires taxation, specify another set of values for taxCode, taxRate, and taxGlId.

Logging 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. Suppose the network reports that the number of used units during a session exceeds a customer's available allowance and credit limit. In that case, ECE charges the customer up to the available allowance. It can then add information about the overage amount to an overage log file. You can create a custom solution to reprocess the overage amount later on.

Note:

If your ECE system includes a Kafka Server, configure ECE to publish overage details to a Kafka topic instead. See "Understanding and Configuring ECE Prepaid Usage Overage".

To configure ECE to publish details about prepaid usage overage to its own log file:

Set the OVERAGE_LOG_DIR environment variable to the path where you want to create the overage log file.
In your ECE_home/config/ece.properties file, add the following line:
```
java.property.eceoveragelogdir=OverageLogDir
```
where OverageLogDir is the absolute path to the directory where you want to create the overage log file.

In your BRM_home/sys/dm_kafka/log4j2.xml file, add the following lines and set the XML elements to meet your business needs:

<RollingFile name="OVERAGE" createOnDemand="true" fileName="${OVERAGE_LOG_DIR}/overage.log" filePattern="${OVERAGE_LOG_DIR}/overage.log.%i">
    <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5p] [%t] %m%n"/>
    <Policies>
        <SizeBasedTriggeringPolicy size="100MB"/>
    </Policies>
    <DefaultRolloverStrategy max="1"/>
</RollingFile>

For more information about the XML elements, see "Rolling file appenders" in the Apache Log4j Manual.

Managing Direct Debit Data in ECE Cache

By default, ECE stores information about all direct debit events in its cache so it can validate any refund requests against one of the events.

However, some event types may not be eligible for refunds, so storing the direct debit information in the cache is unnecessary. To save space and improve performance, you can configure ECE not to store direct debit information in its cache for specific event types.

To prevent ECE from storing direct debit information in its cache for specific event types:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
Expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
In the excludedEventsForDebitRefundSessions attribute, list the event types separated by a comma. For example, enter EventDelayedSessionTelcoGsm, EventDelayedSessionTelcoGprs.

Configuring ECE to Redirect Subscriber Sessions to a Service Portal

You can configure ECE to redirect a customer session to a service portal when the customer is about to deplete the balance available for a service. A service portal is an external server where the customer can perform an action, such as adding funds to an account.

ECE evaluates redirection rules to determine whether to redirect a session. A rule specifies the service portal address, address type, and, optionally, the time during which the customer can access network resources while completing the action at the service portal.

A redirection rule can consider the following information:

Whether final-unit indication (FUI) is present in the usage response.
Whether the customer is roaming.
The customer's business profile, such as a prepaid or postpaid payment type or a voice or data subscription type.
The service type and attributes in the usage request.

Each rule can redirect a session to a different service portal. For example, you can redirect a roaming prepaid customer to a roaming top-up portal and a non-roaming prepaid customer to a home-network top-up portal.

When a credit-control client receives FUI in a usage response, it processes the session according to the Final-Unit-Action:

REDIRECT redirects the customer to the service portal specified by ECE.
TERMINATE ends the customer session.

If no configured redirection rule matches, ECE returns a Final-Unit-Action of TERMINATE.

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 14-1 shows redirection-rule conditions that you can use to create redirection rules.

Table 14-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 14-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:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
Expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
Set the matchFactorEnabled attribute to true.

Customizing Consumption Order of Loan and Default Balances

By default, ECE includes valid loan balance items when rating usage requests. To use default balance items instead for specific service or event types, configure the pre-rating extension to set

extensionContext.setUseLoanBalanceItem(false)

When this setting is false, ECE excludes valid loan balance items for that usage request and rates the request using only eligible default balance items, according to the configured rating and consumption rules. ECE resets the setting to true for the next usage request. This setting does not create, grant, or modify loan balances.

You can use a pre-rating extension to configure selected services or events to exclude loan balance items for selected services or events before the loan balance.

In your extension logic, evaluate the service type, event type, or other usage-request attributes. For requests that must use the default balance first, call the setUseLoanBalanceItem method with a value of false. For example:

if (usePrincipalBalanceFirst) {
    extensionContext.setUseLoanBalanceItem(false);
}

The setUseLoanBalanceItem method supports the following values:

true: ECE includes valid loan balance items during rating. This is the default.
false: ECE excludes loan balance items during rating and uses valid default balance items according to the rating and consumption rules.

Note:

The value of setUseLoanBalanceItem applies only to the current usage request. ECE resets the value to true at the start of each usage request. Therefore, an override made for one request does not affect subsequent requests.
The value controls only whether existing valid loan balance items are eligible for rating. It does not create or grant a loan balance.

For more information, see "Customizing Rating"

Location-Based Charging

Location-based charging allows you to alter the rate based on your customer’s location. For example, you could charge $5 per GB for customers located in Silicon Valley.

You configure location-based charging in PDC by:

Creating a value map that associates a value map name with a set of cell IDs. For example, you could create a value map named Silicon Valley associating with cell IDs 209, 408, 415, 650, and 510.

See "Configuring Value Maps" in PDC Creating Product Offerings for more information.
Creating a charge selector or discount selector that maps a value map name to a specific charge or discount.

For example, you could map the London value map to a 5 pound per GB charge and map the Manchester value map to a 6 pound per GB charge. See “Charge Selectors” in PDC Online Help.
Adding the charge selector to a charge offer, or adding the discount selector to a discount offer.

When ECE rates an incoming usage request, it determines whether a cell ID in the request is included in a value map. If it is included, ECE checks whether:

A charge selector associates the value map name to a charge amount.
A discount selector associates the value map name to a discount amount.

If ECE finds a match, it applies the charge or discount associated with the value map name.

About Processing Conditional Balance Impacts

You can create conditional balance impacts when designing charge offers in Pricing Design Center (PDC). See "About Conditional Balance Impacts" in PDC Creating Product Offerings.

However, the way ECE processes conditional balance impacts is dependent on the pricing names assigned to each charge in an offering:

Apply Multiple Conditional Balance Impacts: If you want multiple conditional balance impacts to apply for different types of charges within the same offer and day, use different pricing names for each charge. For example, to apply a charge for roaming in different countries, use unique pricing names for Zone 1 (Italy), Zone 2 (Austria), Zone 3 (Switzerland), and so on. This way, roaming in one zone won't affect the application of charges or grants in other zones. A customer in Italy consuming up to 1 GB of roaming data in a day is charged $5. However, a customer consuming data in both Italy and Austria on the same day is charged $10 (that is, $5 for 1 GB of roaming data in Italy and $5 for 1 GB of roaming data in Austria).
Apply a Single Conditional Balance Impact: If you want only one conditional balance impact to apply on a given day for a specific offering, ensure that all charges in the offering use the same pricing name. This is useful when you have specific logic to choose between different pricing configurations but want only one to take effect. For example, you could apply $5 per day for 1 GB of data when roaming in one or more zones.

When ECE rates events, it determines whether to apply a conditional balance impact by checking whether it is the first time the customer has used a bundle and pricing combination (called a bundle identifier) on that day.

Bundle identifiers use the following format: bundleName_pricingName

where bundleName is the bundle name assigned in PDC, and pricingName is the name assigned to the charge in PDC. For example, a bundle identifier could be Roaming_InternationalPricing or Roaming_Zone1Pricing.

Customizing ECE to Apply Fixed Charge for Zero Usage

By default, when a customer has a subscription with a charge offer that contains a fixed charge and a usage charge, ECE does not apply any charges if the usage charge is zero. For example, if a customer makes a call and it disconnects immediately, the reported usage is zero and the total charge becomes zero even if there is a fixed charge.

You can customize ECE to apply the fixed charge even if the usage charge is zero or rounded down to zero. To do this, extend ECE at the post-rating extension point to do the following:

Identify the pricingName for subscriptions with zero usage and exclude the usage charge for it.
Apply a fixed charge, by customizing the logic to create or modify the quantityRated, timeRange, validity, and quantityRange variables to set them to zero.

You can further let ECE re-calculate the NET_QUANTITY based on the newly created or modified data, applying the fixed charges.

For example:

for (ExtensionRatingPeriod erp : originalExtRatingPeriods) {
                if (erp.getChargeRatePlanName().equals("RATE_PLAN_VOICE_001")) { /* condition to detect 0 quantity case */
                    erp.markForDeletion();
                    if (erp.isFixedImpact()) {
                        LOG.debug("SamplePostRatingExtensionIJH.execute() : mutating fixed impact => {}", erp);
                        // Drop and recreate with 0 quantity ...
                        erp.markForDeletion();
 
                        Range timeRange = Range.make(erp.getTimeRange().start(), erp.getTimeRange().start());  // start - start
                        UnitValue qty = erp.getQuantity().subtract(erp.getQuantity());                         // 0.0
                        String aaResultTags = "";
                        if (erp.getAAResultTags() != null) {
                            aaResultTags = Arrays.asList(erp.getAAResultTags()).toString();
                        }
                        Range validity = null;
                        if (erp.getValidityFromTime() != null && erp.getValidityToTime() != null) {
                            validity = Range.make(erp.getValidityFromTime().toInstant().toEpochMilli(), erp.getValidityFromTime().toInstant().toEpochMilli());
                        }
                        QuantityRange quantityRange = QuantityRange.make(erp.getQuantityFrom(), erp.getQuantityFrom());
 
                        extensionContext.addRatingPeriod(
                           erp.getRatingPeriodId(),
                           timeRange,
                           erp.getImpact(),
                           erp.getRumName(),
                           erp.getCustomerId(),
                           erp.getBalanceId(),
                           erp.getProductId(),
                           erp.getBalanceElementId(),
                           erp.getBalanceElementCode(),
                           erp.getGeneralLedgerCode(),
                           erp.getTaxCode(),
                           erp.getTaxTime(),
                           erp.getTaxRate(),
                           erp.getOfferProfile(),
                           qty,
                           aaResultTags,
                           erp.getTimeTag(),
                           erp.getOrigZoneTag(),
                           erp.getPricingName(),
                           erp.getTimeModelName(),
                           erp.getZoneModelName(),
                           erp.getChargeRatePlanName(),
                           erp.getImpactCategory(),
                           erp.isFirstUsageGrant(),
                           validity,
                           quantityRange,
                           erp.getRatingPeriodType(),
                           erp.getCorrelationRatingPeriodId(),
                           new Pair<String, String>(erp.getItemType(), erp.getItemIdentifier()),
                           erp.isRecurringBundleImpact(),
                           erp.getRecurringBundleDetails(),
                           erp.getOrigZoneTag(),
                           erp.getPurchasedProductOfferingId(),
                           erp.getOfferingId(),
                           erp.getProductOfferingExternalId(),
                           erp.getCombinedZoneResult(),
                           erp.isCounterImpact(),
                           erp.isFirstUsageOffer(),
                           erp.isFixedImpact(),
                           erp.isCurrencyImpact(),
                           erp.getInitialZoneResultTag(),
                           erp.getUsedZoneModelName(),
                           erp.getImpact(),
                           erp.getOriginalBalanceElementId(),
                           erp.getTaxJurisdiction(),
                           erp.getRateTag(),
                           erp.getLineage(),
                           erp.getDiscountInfo(),
                           erp.getAlterationRatePlanName(),
                           erp.getAlterationConfigurationName(),
                           erp.getAlterationPricingName());
  
                    } else {
                        // Drop scaled impacts ...
                        LOG.debug("SamplePostRatingExtensionIJH.execute() : Dropping RATE_PLAN_VOICE_001 scaled impact => {}", erp);
                        erp.markForDeletion();
                    }
                }
            }

Accessing ECE Configuration MBeans

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

Log in to the driver machine.
Start the ECE charging servers (if they are not started).
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.
Start a JMX editor that enables you to edit MBean attributes, such as JConsole.
In the editor's MBean hierarchy, find the ECE configuration MBeans.

About Overload Protection in ECE

When the amount of incoming requests for ECE exceeds its capacity, it experiences an overload. This can lead to charging nodes becoming stuck or unresponsive. To avoid this, you can enable an overload protection mechanism.

When an overload happens, ECE starts rejecting the new incoming requests and informs the client about any submitted request that could not be processed. These requests can then be routed to some other alternative gateway or can be accepted by the same gateway once the overload condition is resolved.

You can configure ECE either to reject all incoming requests or to reject requests based on priority. For more information about how to configure ECE for overload protection, see "Configuring System Overload Protection" in BRM System Administrator’s Guide.

Note:

Priority-based overload protection is applicable only to HTTP Gateway and Diameter Gateway.

Redirecting Customer Sessions to a Service Portal

A redirection rule can consider the following information:

Whether final-unit indication (FUI) is present in the usage response.
Whether the customer is roaming.
The customer's business profile, such as a prepaid or postpaid payment type or a voice or data subscription type.
The service type and attributes in the usage request.

When a credit-control client receives FUI in a usage response, it processes the session according to the Final-Unit-Action:

REDIRECT redirects the customer to the service portal specified by ECE.
TERMINATE ends the customer session.

If no configured redirection rule matches, ECE returns a Final-Unit-Action of TERMINATE.

Returning FUI in Initiate Responses

Before configuring a redirection rule that uses @fui for an Initiate request, configure ECE to return final-unit indication (FUI) in the Initiate response. In the charging settings, set the enableFuiForInitiate parameter to true.

When enableFuiForInitiate is set to true and a Requested-Service-Unit (RSU) leaves the balance exactly at the effective ceiling, ECE classifies the result as CREDIT_CEILING_REACHED. The relevant RSU flow creates the special ceiling-reached service event, and response processing converts that event to the FINAL_UNIT_INDICATOR reason code. The response remains successful, and the CCA can contain FUI. The response does not include the CREDIT_CEILING_BREACH reason.

Note:

The FUI does not indicate that the Initiate request failed. ECE grants the remaining available units and directs the network to perform the final-unit action after the units are consumed.

If the available balance is already zero, the Initiate request fails regardless of the enableFuiForInitiate setting. The failure response can include reasons such as NO_RATING_GRAPH_CONFIGURED or NO_RATED_QUANTITY.

Configure the enableFuiForInitiate parameter using JConsole or by editing the charging-settings.xml file.

To configure the parameter using JConsole:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "".
Expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
Set the enableFuiForInitiate attribute to true.

To configure the parameter in the charging-settings.xml file:

Open the ECE_home/config/management/charging-settings.xml file.

Set the enableFuiForInitiate parameter to true:

enableFuiForInitiatetrue/enableFuiForInitiate

Save the file.
Restart ECE to apply the change.

Configuring Redirection Rules

ECE derives the service portal address from configurable instructions that you define in redirection rules. You can base a redirection rule on one or more customer conditions:

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, such as a BRM business profile for prepaid or postpaid customers or voice or data subscriptions.

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

Given a prepaid customer who is roaming, redirect the subscriber to http://roamingURL.
Given a prepaid customer who is not roaming, redirect the subscriber to http://roamingURL.

First, determine the content of your redirection rules. Then configure the completed rules in ECE using JConsole or by editing the charging-settings.xml file.

To determine the content of the redirection rules:

Create a temporary file in a text editor.
Create each redirection rule on a single line with no line breaks. The examples in this topic include line breaks only for readability.
Create additional rules as required. Separate multiple rules with semicolons and enter the complete configuration on one line when you set the redirectionRule parameter.

Redirection-Rule Syntax

Use the following syntax:

(redirection_condition1 [AND redirection_condition2 ... AND redirection_conditionN]) => [redirect_type:"redirectType",redirect_address:"redirectAddress",redirect_validity:"redirectValidity"];

where:

redirection_condition specifies a condition that must be met for ECE to send the specified redirect information in the usage response. See Table 14-2, "Conditions Allowed in Redirection Rules."
redirect_type specifies the service portal address type, such as URL.
redirect_address specifies the service portal address.
redirect_validity optionally specifies, in seconds, how long the customer can access network resources while completing the action at the service portal. If omitted, ECE uses the default reservation validity time.

Table 14-2 Conditions Allowed in Redirection Rules

Condition	Description
@fui	Checks whether final-unit indication is present in the charging result. This condition is required for redirection.
{business_profile([name:"BusinessProfileName"])} == "true"	Checks whether the customer has the specified BRM business-profile attribute set to true.
@roamingRequest	Checks whether the request is for a roaming customer. Use !@roamingRequest to check for a non-roaming request.
{request_attribute([name:"FieldName"])}	Checks for the presence of a usage-request attribute. To check a value, compare the expression with that value; for example, {request_attribute([name:"CELL_ID"])} == "1234" .
@productType	Retrieves the service type associated with the request.

To configure the redirection rules using JConsole:

Complete the redirection-rule configuration in a text editor.
Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
Expand the ECE Configuration node.
Expand charging.redirectionConfiguration.
Expand Attributes.
Set the redirectionRule attribute to the text rules you created.

The default value is an empty string. If no rule is configured or no rule matches, ECE does not redirect the session and returns a Final-Unit-Action of TERMINATE.

To configure the redirection rules in the charging-settings.xml file:

Complete the redirection-rule configuration in a text editor.
Open the ECE_home/config/management/charging-settings.xml file.
Set the redirectionRule attribute to the text rules you created.
Save the file.
Restart ECE to apply the change.

ECE begins using the updated redirection rules.

Note:

If a rule has invalid syntax, ECE logs a Rule Evaluation Failed error in the charging-server log files and leaves the redirection information empty in the usage response.
Edit the configuration in the text file where you created it, then copy the completed one-line configuration into JConsole or charging-settings.xml. This helps prevent errors when a rule is too long to view in full in JConsole.