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.

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:

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

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

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

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

To enable server-initiated reauthorization requests:

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

2. Expand the ECE Configuration node.

3. Expand charging.notification.

4. Expand Attributes.

5. Set the rarNotificationMode attribute to ASYNCHRONOUS.

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

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

7. Expand Attributes.

8. Set the offerEligibilitySelectionMode attribute to PERIOD.

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

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

   Note:

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

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

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

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

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

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

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

2. Expand the ECE Configuration node.

3. Expand charging.server.

4. Expand Attributes.

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

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

     ECE does not calculate the remaining balance.

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

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

     remaining balance = sum of 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)}

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

• Tax codes, which apply simple flat taxes.

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

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

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

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

To configure taxation in an ECE runtime environment:

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

2. Expand the ECE Configuration node.

3. Expand charging.taxation.

4. Expand Operations.

5. Click addTaxDetails.

6. Specify values for the following parameters:

   Note:

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

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

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

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

   • taxRate: Enter the tax rate to apply.

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

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

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

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

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

• Whether the customer has insufficient funds

• Whether the customer has an inactive account

• Whether the customer is roaming or not roaming

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

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

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

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

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

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

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

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

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

   See "Creating Redirection Rules".

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

3. Expand the ECE Configuration node.

4. Expand charging.redirectionConfiguration.

5. Expand Attributes.

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

   The default value is an empty string.

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

   ECE begins using the redirection-rule configuration at runtime.

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

   Note:

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

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.

{business_profile([name:"POSTPAID"])} == "true" )

{request_attribute([name:"3GPP-IMSI-MCC-MNC"])} 

{request_attribute([name:"CELL_ID"])} == "1234")

 (
     (@productType == 'DATA')
     AND
     ( {request_attribute(name:"GGSN-MCC-MNC-
        3GPP"])} == "1234")
) => [redirect_type:"URL",redirect_address:"myDataTopUpRedirect.com"]

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.

The following is an example of redirection rules.

"( (@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.

ECE supports the match factor in discounting.

To enable the match factor in ECE:

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

2. Expand the ECE Configuration node.

3. Expand charging.server.

4. Expand Attributes.

5. Set the matchFactorEnabled attribute to true.

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.