This chapter describes the charging scenarios supported by Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).
You can use ECE to perform online charging only, offline charging only, or both online charging and offline charging when used within a convergent charging system.
See the following topics for information about the charging scenarios ECE supports:
ECE charges network events based on various attributes and the pricing components associated with them. See "About Usage-Charging Attributes" and "About Pricing Components".
ECE supports various rate types when charging network events. See "About Rating" for more information.
The ECE SDK includes sample programs that demonstrate how mediation system client applications call the ECE APIs for supported charging scenarios. See the discussion of using ECE developer tools in BRM Elastic Charging Engine System Administrator's Guide for information about the sample programs.
ECE supports the following charging scenarios for online charging of network events as defined by 3GPP standards:
Event-based charging:
Event charging with unit reservation (ECUR)
Immediate event charging (IEC)
Session-based charging:
Session charging with unit reservation (SCUR), including:
Reverse rating
Charge distribution
Advice of Charge (AoC)
Additional capabilities include:
Alterations (typically called discounts in Billing and Revenue Management (BRM))
Distributions
Advice of Promotion (AoP)
Taxation
Final Unit Indicator (can be used to support in-session top-ups)
ECE provides a Java interface for online charging of network events.
ECE provides a Java interface for supporting operations from policy and control network mechanisms (the policy and charging rules function (PCRF)). For the discussion of policy-related charging, see "About Policy-Driven Charging".
ECE supports the following charging scenarios for offline charging of network events:
Event-based charging
Additional capabilities include:
Alterations
Taxation
When the BRM server performs customer management and billing transactions, it stores the results in the BRM database. To enable ECE to rate usage events properly, all customer data updates made in the BRM database must also be made in the ECE cache.
The updates are applied to the ECE cache synchronously (in real time) as follows:
The BRM server performs the transaction and then sends the updates in business events to ECE through External Manager (EM) Gateway.
EM Gateway processes the business events and then informs the BRM server whether the ECE cache update was successful.
One of the following occurs:
If the cache update succeeds, the updates are saved to the BRM database.
If the cache update fails, the database updates are rolled back.
Because both the database and the cache are updated within the same transaction, no lag time occurs, and the BRM and ECE data remains synchronized whether the cache update succeeds or fails.
To enable synchronous customer data updates, see the discussion about enabling real-time synchronization of BRM and ECE customer data updates in BRM Elastic Charging Engine Implementation Guide.
Attributes affect how ECE implements rating. Attributes can be associated with the event, the customer, or the product.
ECE can rate network events differently based on the following attributes:
Chargeable-event-rating attributes
Customer-rating attributes
Product-rating attributes
For example, a customer-rating attribute can be a customer's birth date where you provide free text messages to customers on their birthday.
Chargeable-event-rating attributes must be defined in your event definition so that ECE identifies them as attributes that drive rating.
Customer and product attributes that drive rating in ECE at runtime are ECE customer model attributes. These attributes are defined in Oracle Communications Pricing Design Center (PDC) when you perform event definition in PDC so that you can define pricing rules based on them.
Pricing components are the rates that ECE uses for charging. Pricing components are defined in PDC. ECE uses the pricing components to configure the value of a chargeable event received from the network. See the PDC Help for instructions on how to create pricing components for ECE.
ECE supports Advice of Promotion as a system-level configuration; it is not configurable in PDC. See "About Advice of Promotion" for more information.
To calculate charges and discounts during rating at runtime, ECE uses configuration data and pricing component data defined in PDC. ECE can use attributes from the chargeable event received from the network, attributes from the customer data received from BRM, and attributes from the product data received from BRM for determining what rate to apply.
ECE supports various rates for determining the value of a chargeable event. You define rates in PDC, including the following:
Zero rate
Flat rate
Tiered rate
Threshold rate
Zone-based rate
Time-based rate
Day-based rate
Special day-based rate
See the PDC Help for descriptions of the preceding rate types and how to define them in your ECE pricing components.
At runtime, ECE can perform reverse rating for session-based charging. See "About Reverse Rating" for more information.
You can rerate ECE-rated events if required. Rerating events can be required for various reasons. For example, if one of your existing charge offers was replaced between the last and next billing cycles.
See the discussion about rerating in the BRM documentation for information about rerating in the BRM charging system.
Rerating is initiated in BRM when you run the BRM pin_rerate utility. The pin_rerate utility sends rerate jobs to ECE for events that were originally rated by ECE.
ECE supports concurrent rating in which ECE can continue to rate a customer's real-time usage events while performing rerating on that customer's account. ECE can also apply top-ups that come in from third-party top-up systems while performing rerating on that customer's account.
A usage request that comes from the network when the customer is in rerating is called a concurrent request. Authorization requests and reauthorization requests (for concurrent requests) are processed and the results are returned to the network mediation software program, even when rerating is occurring for that customer.
Concurrent rating applies to ECE usage-event processing. ECE reprocesses any concurrent request received when the customer is in rerating mode. Balances for the customer that have been modified due to BRM rerating are recalculated again in ECE so the balances are synchronized.
The following summarizes the overall process for rerating ECE-rated events in a BRM charging system:
In BRM, the system administrator runs pin_rerate to create rerating jobs for rerating specified accounts.
BRM locks the customer accounts in BRM and sends a prepare-to-rerate message to ECE through the BRM Advanced Queuing (AQ) database queue.
Note:
pin_rerate sends all rerating messages to ECE by sending business events through the BRM Account Synchronization Data Manager (DM). The rerating messages are converted to update requests by EM Gateway and are sent to ECE through Customer Updater like any other update request. Update requests for rerating messages are referred to as charging requests.ECE marks the customers that are part of the prepare-to-rerate request with an in-rerating status and pushes rated events for those customers from the Oracle NoSQL database to BRM so that balances in ECE and BRM are synchronized before rerating starts.
ECE uses the Acknowledgment Queue to send an acknowledgment that rerating can be initiated and BRM initiates the rerating process.
BRM sends the events to be rerated through EM Gateway to be rated by ECE.
The customer's balances are not affected for the events rated through EM Gateway.
BRM sends rerating requests to ECE containing the balance impacts to sponsoring accounts (for charge distribution) as a result of rerating accounts.
ECE rerates a customer's usage events according to the rerating requests.
If ECE receives concurrent requests, such as concurrent usage requests or concurrent top-up requests, it rates usage and applies top-ups for the concurrent requests accordingly.
When the rerate job is complete in BRM, BRM sends a message to ECE through the BRM AQ database queue.
ECE performs necessary balance updates and backouts and synchronizes the balances for customers that were in the rerating requests.
For charge distribution scenarios (charge sharing in BRM), events for customers that were not in the rerating job, but who share discounts or charges with customers who were in the rerating job, are processed further so that balances are applied correctly.
After ECE rerates the events, ECE sends the charging results to BRM by generating call details record (CDR) files for Rated Event (RE) Loader to load in the BRM database.
ECE generates an acknowledgment that rerating is complete and sends it to BRM through the Acknowledgment Queue.
BRM stores all subscription events that occur in the BRM system until rerating is complete. After rerating, BRM sends the subscription events to ECE as update requests through Customer Updater. Likewise, ECE stores all concurrent-request events that occur in the ECE system until rerating is complete.
If ECE cannot rerate events for a customer, ECE sends a notification to BRM using BRM Gateway. BRM uses the information in the notification to create a rerate job for that customer. If the process of rerating fails during the rerating process, ECE logs messages in the Customer Updater log file.
ECE moves failed rerating requests from Customer Updater to the suspense queue. See the discussion of handling failed update requests from BRM in ECE System Administrator's Guide for information about handling failed events in the suspense queue.
ECE supports the 3GPP Advice of Charge (AoC) supplementary service by which customers can be informed about the cost for a requested service either in monetary format or non-monetary format. AoC may be provided at the beginning of a session, during a session, or at the end of a session.
To support AoC, ECE calculates the cost of using a service and relays that information back to the network mediation software program which can then pass the message on to the customer.
For information about configuring AoC in ECE, see the discussion of usage-charging configuration in BRM Elastic Charging Engine System Administrator's Guide.
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 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, then the AoP is 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 software program, 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 of 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 software program 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 the discussion of usage-charging configuration in BRM Elastic Charging Engine Implementation Guide for information about how to configure AoP.
Note the following details about AoP:
AoP is not configurable in PDC.
AoP is a systemwide configuration (it is not configured on a per-charge-offer basis).
By default, AoP gives advice based on time.
When applying AoP, ECE uses the 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 a different discount offer applies to the future offset time period, AoP may advise a promotion when none exists or may not advise a promotion when one is available.
When using AoP, ensure that your rate plans have tiered consumption configured accurately so as to prevent a credit breach of non-currency balance elements.
ECE supports multiple-service credit control (MSCC) requests in which a Diameter application performs credit control for multiple services within the same session.
An MSCC request is a list of sub-requests that are targeted to the same customer and share the same operation type and session ID but individually apply to different products.
When ECE receives MSCC requests, it assigns a different session ID to each of its sub-requests. Doing this enables ECE to distinguish one sub-request from another when looking up the active session associated with each sub-request.
An MSCC request results in an MSCC response containing a sub-response for each sub-request. Each sub-response contains status indicating whether the sub-request succeeded or failed.
When ECE saves rated event information for MSCC requests in the Oracle NoSQL database, note the following points:
Rated event information is saved for each sub-request.
The NoSQL key for the rated event is based on the session ID that ECE assigned (not based on the original MSCC request session ID).
The ECE session ID in the Oracle NoSQL database is a composite of the original usage request's session ID, the product type, and the user identity, separated by underscore characters. For example:
Original MSCC request ID: 1313b2ab-d51e-4545-8bba-25c731daf10b
Usage request's product type: VOICE
Usage request's user identity: 650123555
ECE session ID: 1313b2ab-d51e-4545-8bba-25c731daf10b_VOICE_650123555
MSCC support applies to usage requests and query requests.
MSCC support does not include support for rating groups (Rating-Group attribute-value pair (AVP)), credit pools (G-S-U-Pool-Reference AVP where units of the service type are pooled in a credit pool) and credit control (as described in section 5.1.2 of IETF RFC 4006).
Refer to the SampleMultipleServicesLauncher sample program in the ECE SDK for an example of how to send MSCC requests to ECE. For more information, see the discussion about the ECE sample programs in BRM Elastic Charging Engine Implementation Guide.
For event-based charging, the usage request is for usage that was rendered in a single operation. The usage request can be received before usage, during usage, or after the occurrence of the usage. The data for event-based requests typically maps to the ECE Debit, Refund, Balance_Query, and Price_Enquiry charging operation types.
For session-based charging, the usage request submitted by the online mediation system are usage reports for a session. The online mediation system uses the START, INTERIM, and STOP accounting data, which maps to the ECE Initiate, Update, and Terminate operation types.
To enable BRM to recognize revenue generated during online network sessions, ECE must create rated events and send them to BRM.
By default, ECE generates a rated event for a network session only when the session is ended by a Diameter terminate operation.
Some sessions, however, such as data streaming, last days, weeks, or even months. If you do not want to wait until the end of a lengthy session to recognize revenue for the part of the session that subscribers have already consumed, you can configure ECE to generate a rated event whenever a Diameter update operation occurs during a network session. Such events are called midsession rated events.
Midsession rated events enable BRM to recognize revenue incrementally during long network sessions, preventing large amounts of unrated usage and unrecognized revenue from accumulating. They also enable you to show subscribers their running balance throughout a session.
Each midsession rated event:
Is considered a separate record by downstream processes, such as rerating (treated as individual sessions) and invoicing (treated as individual records on itemized invoices).
Marks the end of a subsession of the network session. For the subsequent subsession, the network session's volume and duration counters are reset to 0. Therefore, if you enable this feature, do not base your pricing on cumulative volume or duration across a network session.
Contains a reference to the network session ID and to the update operation in which it was created.
To configure ECE to generate midsession rated events, see the discussion about configuring ECE to generate midsession rated events in BRM Elastic Charging Engine Implementation Guide.
ECE supports the following discounting capabilities:
Note:
Discounts is a BRM term. In ECE, they are typically referred to as alterations.Note:
Alterations are always capped to a maximum of one hundred percent of charges.Percentage discounts
Fixed amount discounts
Tiered discounts
Threshold-based discounts
Discount increments (beats)
Support for parallel (original charge), sequential (remaining charge), and quantity (cascading) discount modes
Discount priorities
Charge offers and discount offers have a priority assigned to them. When an event is rated, ECE applies the offers in the order of priority.
ECE stores the current view of the customer balance in the charging system. The active customer balances are updated in real time when usage-request transactions occur in Elastic Charging Server.
ECE publishes rated event information (the charging result of usage-request processing). Other applications in the charging system that also store customer balances use the rated event information to update their customer balances. ECE publishes rated event information to the Oracle NoSQL database.
Customer balance data is kept current by Customer Updater, which synchronizes data from BRM to ECE when activity to the customer account in BRM can impact the correctness of ECE balance data. For example:
Rating and discounting in ECE result in balance impacts that must be reflected in the BRM database. For example, if a discount results in the reduction of a free minutes balance, that change must be reflected in the BRM database so that the balance can be displayed accurately in Customer Center. These updates are made in the BRM database by RE Loader when it loads rated event CDRs into BRM.
Activity in the BRM database affects balances used in ECE rating. For example, a customer might purchase a discount that provides 500 free minutes or a customer service representative (CSR) could post a debit to a balance. These balance changes must be reflected in the balance managed in ECE. When these balance changes occur, BRM uses the Account Synchronization DM to send the balance impact to ECE. ECE uses Customer Updater to load the balance impact into ECE caches.
ECE supports charge distribution (referred to as charge sharing in BRM).
ECE can support billing systems that enable sharing groups: customers that share discounts or charges with other customers. For example, ECE supports discount sharing groups and charge sharing groups defined in BRM.
Alteration and charge sharing agreements between customers enables discount and charge sharing to be applied in the ECE rating module. ECE supports discount sharing and charge sharing at account level and also at product level. ECE supports only products to participate in an alteration or charge sharing agreement.
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. Reservation validity specifies how long a session can continue before the client must ask for a reauthorization of resources for further usage.
ECE sends a reservation expiration back to the network mediation client. Reservation expiration specifies how long a session can continue before the client must report the consumed usage to ECE (report the used service units).
For information about configuring the reservation validity and reservation expiration values that ECE sends back to the network mediation client, see the discussion of configuring charging business rules in BRM Elastic Charging Engine Implementation Guide.
The balance item's first usage in the balance impact sets the validity. When ECE receives a usage request for which a customer first uses a balance item, the validity start time is set to the session start time of the request.
When a first usage balance item's validity period is set, the validity period must be updated in the BRM database also. BRM Gateway uses the notification framework to send the information to BRM. When a first usage validity is initialized, ECE generates the FirstUsageValidityInitializationEvent service event. BRM Gateway uses the service event and triggers the opcode on BRM to update the validity of the balance item in the BRM database.
ECE can grant balance impacts during rating that have a validity mode set to first usage. For example, you could create a charge offer that includes these balance impacts:
Debit 5 cents per minute if there are no included minutes.
Credit 1 minute for each minute paid at 5 cents per minute. These minutes are valid on first usage.
In this example, the charges occur as follows:
A subscriber has used up all his included minutes and is being charged 5 cents per minute.
After 10 minutes, the subscriber terminates the call. The subscriber is granted 10 minutes.
The next call that the subscriber makes uses the 10 free minutes, granted as first-usage balance impacts.
You can also grant first-usage balance impacts by using a discount. For example, you could create:
A charge offer that charges 5 cents per minute
A discount that credits one SMS message for each called minute
In this example, the charges occur as follows:
A subscriber makes a 10-minute call.
The subscriber terminates the call. The subscriber is granted 10 SMS messages, valid at first usage, with a validity end date after 30 days.
For more information about creating product offerings, see the PDC documentation.
Reverse rating means that ECE uses the customer's credit limit to calculate the amount of usage the customer can afford for a requested service before the service is delivered. For online session-based charging, ECE supports reverse rating. For event-based charging, ECE supports reverse rating for debit requests.
ECE performs reverse rating as follows:
ECE receives a usage request of the Initiate, Update, or Debit operation type for a requested resource quantity.
ECE calculates the charges for the usage request based on the product offering associated with the customer. A product offering represents the products available to your customers and the price of those products.
When the rated result of the charge calculation is applied to the balance of the customer, the impact on the balance exceeds the customer's credit limit for the requested resource quantity.
ECE determines the quantity of balance element that can be authorized based on the customer's credit limit and returns the quantity in the usage response to the network mediation software program.
When ECE performs reverse rating for a service in which events are rated by using multiple ratable usage metrics (RUMs), you can configure rounding options. See the discussion of reverse rating when rating is based on multiple RUMs in BRM Elastic Charging Engine Implementation Guide for details. ECE can also round up the results of its maximum quantity calculations to the nearest whole number.
ECE supports policy-driven charging. Policy-driven charging implements network, customer, and service policies that can be used by service providers for improving customer experience and for making efficient use of network resources. Service providers can use policies for various reasons, such as to control data usage, set quality of service (QoS), allocate amounts of bandwidth to each service, enforce parental controls, implement charging rules, and so on.
Policies can be service and network aware. Network-aware policies can be created for specific access technologies where the network condition can dynamically alter prices. Service aware policies can be created to provide control over how a customer consumes network resources.
ECE supports policy-driven charging based on PCRF, defined in the 3GPP TS 23.203 v9.9.0 (2011-06) specification.
To support policy-driven charging, ECE exposes the following information in its in-memory data grid to policy clients, such as network mediation software programs. Policy clients use the ECE policy management APIs to retrieve the information and send it to the PCRF:
Policy label information
Policy enforcement programs on the PCRF use policy labels such as status labels. For example, a QoS label might be defined as normal-QoS or low-QoS as shown below:
<policy_label>
<label>Basic Subscription</label>
<resource_code>MBU</resource_name>
<resource_id>100012</resource_id>
<unit>megabyte</unit>
<tiers>
<tier>
<range_start>0</range_start>
<range_end>300</range_end>
<status_label>normal-QoS</status_label>
</tier>
<tier> <range_start>301</range_start>
<status_label>low-QoS</status_label>
</tiers>
</policy_label>
</policy_labels>
Policy label information is stored in the offer profile object in BRM. ECE extracts this information into its data grid when it extracts customer data from BRM and sends the status label information to the PCRF program when requested.
Note:
The offer profile is a reusable pricing object. You create offer profiles in BRM and you associate offer profiles with charge offers and discount offers in PDC using provisioning tags. The label name defined in the offer profile is set as a parameter in the customer account.Policy counter information
The Sy interface of the ECE Java policy API transfers policy counter information from ECE to policy clients; it provides policy counter status reporting and policy counter status change notifications.
Policy counters track a customer's usage of a service. For example, ECE tracks how many megabytes of data a subscriber has downloaded. The policy client retrieves the policy counters from ECE and sends them to the PCRF for evaluation.
Subscriber preferences information
ECE stores subscriber preferences associated with how the customer would like to receive policy notifications. Policy clients can retrieve this data from ECE using the Sp interface (implemented as Sh) of the ECE Java policy API. Subscriber preferences such as the following can be sent to the PCRF:
Customer's charging-related information (for example, if the customer purchased a Gold, Platinum, or Bronze package)
Customer's preferred channel for receiving notifications (for example, email or SMS)
Customer's language
To support policy-driven charging, ECE publishes policy notifications. Offer profiles can store threshold definitions for specific resources. ECE can use the threshold definitions to publish notifications when thresholds are breached (SpendingLimit notifications). Also, when the subscriber preferences of a customer changes, ECE publishes notifications with the new or changed preference information (SubscriberPreference notifications). ECE sends notifications to the JMS notification queue. The policy client, such as Diameter Gateway, listens on the queue and uses the data in the notifications to send Sy and Sp messages to the PCRF.
ECE publishes policy notifications only for products that have active policy sessions. When the policy client initiates policy sessions, it subscribes for receiving the policy notifications on behalf of the PCRF.
When a customer purchases a new product, the PCRF will query the policy label and policy counter (Sy data) again so that it can subscribe for the additional counters associated with the new product.
For more information about policy notifications, see "About Notifications Used by Policy Clients".
For an overview of how ECE processes policy sessions requests, see "How ECE Processes Policy Requests for Online Network Mediation Software".
For information about the ECE policy management API, see the discussion about integrating policy clients with ECE in BRM Elastic Charging Engine Implementation Guide.
ECE supports subscription products and member products (referred to as subscription services and member services in BRM). ECE can rate usage for customers' subscriptions.
See the discussion about managing customer's subscription-level services in the BRM documentation for information about setting up services to track and rate usage and create bills for customers' subscriptions.
For online charging, ECE aligns with the Diameter Credit Control Application (DCCA) defined in RFC 4006 in support of event charging with unit reservation (ECUR).
For online charging, ECE aligns with the DCCA defined in RFC 4006 in support of session charging with unit reservation (SCUR).
For online charging, ECE aligns with the DCCA defined in RFC 4006 in support of immediate event charging (IEC). For IEC, usage request are for a direct debit operation. The direct debiting operation may be carried out before the service is delivered.
ECE supports server-initiated reauthorization requests (RARs).
ECE can perform server-initiated reauthorization during an ongoing session. This enables you to update a session in response to changes that occur to a customer's product offerings or balance (for example, a change to a charge offer or to a Friends and Family promotion). When ECE notifies the network, the network sends a reauthorization request, and, if there is a change in the charge, ECE can base the reauthorization on the new charge.
A server-initiated reauthorization can be triggered from the following conditions:
Changes to offers, such as the creation, modification, or deletion of a subscriber's charge offer or alteration offer.
Changes to balances that affect rating (for example, a resource that expires mid-session, a resource that becomes available from a top-up, or changes to the customer balance due to an accounts receivable action).
Changes to promotions, such as changes to Friends and Family or a Special Day offer.
Changes to charge sharing or alteration sharing groups. For example, a new member is added to the group or a member is removed mid-session.
For example:
A subscriber is in a call session. The subscriber adds the called number of that session to a Friends and Family list.
Because a Friends and Family discount might change the charge amount, ECE sends a request to the network.
In response, the network sends a reauthorization request.
ECE sends a reauthorization, using the Friends and Family charge amount.
Note:
A reauthorization request is not triggered by a top-up or by rerating when resources are added to a sharing group owner's account.To configure server-initiated reauthorization, you enable asynchronous RAR notifications. You also set the offerEligibilitySelectionMode variable of the charging.server MBean. For more information about configuring server-initiated reauthorization, see the discussion about configuring run-time options in BRM Elastic Charging Engine Implementation Guide.
ECE supports a fixed-rate tax (a flat-rate taxation also known as GST or VAT).
You can apply a tax on both charges and alterations (discounts).
Tax rates are configurable through ECE business parameter configurations; the tax codes created in BRM should be configured again in ECE. You can use the configuration service to configure taxation parameters. You are required to set mandatory parameters for taxation to work in the ECE run-time environment. See the discussion of usage-charging configuration in BRM Elastic Charging Engine Implementation Guide for instructions on configuring taxation.
ECE does not support jurisdiction-based taxation.
ECE can apply pricing based on a subscriber's participation in a closed user group.
The closed user group must be on the same operator network.
Operators can set up closed user groups at the customer level or at the product level or both. Customers become a member of a closed user group when they purchase an offer that has a closed-user-group profile associated to it.
Special rates for closed user groups are determined through a custom rule and generic selector that you configure in charge offers. When ECE receives a request to initiate a calling session between two members of the same closed user group, ECE evaluates the charges based on the generic selector's custom-rule configuration and determines the price accordingly.
When the called and the calling customers have more than one closed user group in common, ECE applies the same closed-user-group pricing (the same rate or discount) regardless of the group. To configure different rates for different groups, you can use ECE pre-rating extensions. The customer profile data of both the calling customer and the called customer is accessible to the ECE pre-rating extension.
For information about setting up a custom rule for closed-user-group calls, see the discussion about configuring closed user groups in PDC User's Guide.
For information about verifying that closed-user-group calls are processed by ECE during testing, see the discussion about testing charging scenarios in BRM Elastic Charging Engine Implementation Guide.
ECE can assign balance impacts for the same event to different bill items based on rules you configure.
By configuring how balance impacts are assigned to bill items, operators have flexibility in classifying usage into different bill item categories (or buckets). For example, if an operator defines custom bill items for international and national calls, the usage for each type of call can be accounted for as required in separate bill items.
To assign balance impacts to different bill items, ECE evaluates an item type selector rule at run time to derive which item types to assign balance impacts to. The item type selector rule is an expression that can reference any of, or a combination of, the following attributes:
Event attributes
Attributes of the charging result
Item type selector rules are contained in item type selectors. For information about setting up item type selectors, see the discussion about configuring item type selectors in PDC User's Guide.
Typically, ECE receives usage requests during the same accounting cycle in which the usage occurred. However, some usage requests are received after the end of the accounting cycle in which the usage occurred. These requests are called delayed usage requests.
If you configured delayed billing in BRM, you can configure ECE to process delayed usage requests for the accounting cycle in which the usage occurred if the usage requests are received within the delay tolerance interval that you specify. This extends the item assignment for that accounting cycle by the specified interval so that the associated rated events are assigned to the current open bill item. Any delayed usage request received after the specified interval is processed only for the next accounting cycle and the associated rated event is assigned to the next open bill item.
To decide which accounting cycle the delayed usage request belongs to, ECE considers the following dates:
The date when the usage occurred.
The current system date.
The date when the current accounting cycle ends. This is called the next accounting cycle date.
The delay tolerance interval, which is the number of days after the current accounting cycle ends during which delayed usage requests are processed for the current accounting cycle. This interval must be less than the delayed billing interval (the value of the config_billing_delay entry in the BRM_home/sys/cm/pin.conf file).
For example, consider the following dates:
The usage occurred on October 23.
The current system date is October 26.
The next accounting cycle date is October 25.
The delay tolerance interval is 4 days (October 25 through October 28).
In this case, if the usage request is received on October 26, the usage request is processed for the current accounting cycle because it is received within the delay tolerance interval. If the usage request is received on or after October 29, which is after the delay tolerance interval, the usage request is assigned to the next accounting cycle.
To enable ECE to process delayed usage requests for the accounting cycle in which the corresponding usage occurred, see the discussion about configuring item assignment in ECE for BRM in BRM Elastic Charging Engine Implementation Guide.
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. ECE can be configured to send service portal addresses back to credit-control clients in its usage response. Credit-control clients use the information for redirecting a session (often referred to as redirection) to the service portal applicable to the business scenario.
Redirection is used primarily when the subscriber no longer has a balance available to continue the session without a top-up. The redirection can occur at the last leg of an ongoing session where no more balance is available or at any subsequent requests for which no balance is available (for example, the account is in a recharge-only state). Redirection is also used for user scenarios where the subscriber has an inactive account.
When the credit-control client receives the Final-Unit-Indication in the CCA 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 in ECE, then ECE indicates a Final-Unit-Action of TERMINATE in the usage response.
For information about configuring ECE for redirecting a session to a service portal, see the discussion about configuring business rules for charging in BRM Elastic Charging Engine Implementation Guide.