21 Configuring Policy-Driven Charging

You can implement policy-driven charging in Oracle Communications Elastic Charging Engine (ECE).

Caution:

Deploying policy-driven charging for 5G events requires a cloud native deployment of ECE and BRM components. 5G PCF can be used only on an ECE cloud native system.

Topics in this document:

• About Policy-Driven Charging

• Configuring Policy-Driven Charging

• Configuring Breach Tolerance for Policy-Tier Thresholds

• About Integrating Policy Clients with ECE

• About the ECE Sy and Sp Interface

• About Calculating Maximum Authorization for Policy-Driven Charging Sessions

• Configuring ECE to Reject Spending Limit Requests Without Counters

• About the Policy Management API

About Policy-Driven Charging

Policy-driven charging enables you to track a subscriber's service usage and, based on that usage, change the customer's quality of service (QoS) during online charging.

For example, a subscriber purchases a package for a specific QoS to download video content. The subscriber chooses from one of many packages that you have configured with gradations in the QoS based on usage amounts in MBs, such as 100-150, 150-200, and 200-250 MBs. When the subscriber starts downloading video content from the network, you can track the number of MBs the subscriber downloads during the session. When the downloaded quantity crosses the upper threshold set for the selected QoS (for example, 150 MBs), you can use BRM's policy-driven charging to make a seamless change in the policy set for the subscriber's (video downloading) session on the network and allow a shift in the QoS from the current to the next level.

ECE supports policy-driven charging. Policy-driven charging implements network, customer, and service policies that service providers can use to improve customer experience and efficiently use network resources. Service providers can use policies for various reasons, such as controlling data usage, setting QoS, allocating bandwidth to each service, enforcing parental controls, implementing charging rules, and so on.

When you integrate Policy and Charging Rules Function (PCRF) policy clients with ECE, ECE acts as the Subscriber Profile Repository (SPR) because it stores the customer profile information used by the PCRF. ECE offers a combined Sp and Sy interface, which the PCRF uses to retrieve customer preferences and policy counter information.

Policies can be service and network aware. You can create network-aware policies for specific access technologies where the network condition can dynamically alter prices. You can develop service-aware policies to control how a customer consumes network resources.

ECE exposes the following information in its in-memory data grid to policy clients (such as Diameter Gateway or your third-party network mediation software for online charging) to support policy-driven charging. 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 policy specification (offer profiles in BRM) in PDC. ECE loads this information into its data grid when it loads pricing data from PDC.

• Policy counter information

  The Sy interface of the ECE Java policy API transfers policy counter information from ECE to the policy client. 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 a subscriber downloads. 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 of the ECE Java policy API. For example, they could retrieve:

  • A customer's charging-related information (for example, if the customer purchased a Gold, Platinum, or Bronze package)

  • A customer's preferred channel for receiving notifications (for example, email or SMS)

  • A customer's language

To support policy-driven charging, ECE publishes policy notifications. Policy specifications can store threshold definitions for specific balances. ECE can use the threshold definitions to post notifications when thresholds are breached (SpendingLimit notifications). When a subscriber's preferences change, ECE publishes notifications with the new or altered preference information (SubscriberPreference notifications). ECE sends notifications to the JMS notification queue. The policy client 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 charge offers that have active policy sessions. When the policy client (such as Diameter Gateway) initiates policy sessions, it subscribes to receive the policy notifications on behalf of the PCRF.

When a customer purchases a new charge offer, the PCRF re-queries the policy label and policy counter (Sy data) to subscribe to the additional counters associated with the new charge offer.

About Group-Based Policy-Driven Charging

ECE supports group-based policy-driven charging where a policy counter is shared by a group of users, enabling the PCRF to define rules for a group of users.

Group-based policy-driven charging in ECE works as follows:

• The owner of a discount sharing group shares a policy counter.

• A shared discount offer is used to impact the shared policy counter.

• The shared discount is associated with a policy specification that defines policy counter thresholds.

• When a policy threshold is breached, ECE generates a notification for all users in the group.

Policy-Driven Charging Example

The following is an example of how ECE supports policy-driven charging:

• A service provider allows a customer to download 300 MBs of data per month at a normal QoS.

• The customer's counter for data downloaded resets at the beginning of each month.

• The service provider defines policy thresholds in a policy specification in PDC with the label names normal-QoS and low-QoS. These policy threshold labels are also stored in ECE.

• The service provider configures the PCRF with a policy rule that defines what action to take based on the labels defined in the policy specification. The rule determines what action to take when the customer reaches 300 MBs of data before the end of the month.

• The PCRF rule uses the label names normal-QoS and low-QoS as follows:

  If (status_label=normal-QoS) (Bandwidth=10 Mbps)
  If (status_label=low-QoS) (Bandwidth=128 kbps)

When the customer reaches the 300 MB data quota, the PCRF makes a policy decision to configure the Policy and Charging Enforcement Function (PCEF) so that the data transfer speed is set to 128 kilobits per second, downgraded from 10 megabits per second. The PCEF enforces this decision by changing the data transfer speed on the network switch.

Configuring Policy-Driven Charging

ECE supports in-session notifications for policy-driven charging by publishing asynchronous external notifications during a policy session. Policy clients, such as Diameter Gateway or HTTP Gateway, consume the data in these notifications for sending in-session notifications to the PCRF.

About ECE and Policy Clients

To support policy-driven charging, ECE offers a policy management API. Policy clients can use the API to retrieve data relevant to policy enforcement from its data grid.

Policy-driven charging in ECE is based on the PCRF, defined in the 3GPP TS 23.203 v9.9.0 specification. The PCRF integrates with ECE through your online network mediation software.

ECE exposes its in-memory cache so that your online network mediation software can retrieve policy counter information and policy-related subscriber preference information. ECE publishes notifications containing the policy information, and your online network mediation software uses the notifications to send the information to the PCRF for evaluation.

Figure 21-1 illustrates how ECE fits into a charging system that implements policy-driven charging.

Figure 21-1 ECE and Policy Client Integration

Description of "Figure 21-1 ECE and Policy Client Integration"

How ECE Processes Policy Requests for Online Network Mediation System

The following procedure describes how ECE processes requests for policy-driven charging from your online network mediation software (or from Diameter Gateway).

1. A customer starts to use a service, which initiates a network session.

   For example, the customer turns on a mobile phone that connects to a wireless network.

2. At the start of the network session, the PCEF obtains a policy configuration from the PCRF.

   The PCEF uses the Gx interface to get the policy configuration for the network session.

3. The PCRF requests policy counters and subscriber preferences from your online network mediation software (or Diameter Gateway).

   The PCRF uses the Diameter Sy/Sp interface.

4. Your online network mediation software (or Diameter Gateway) initiates a policy session with ECE that does the following:

   • Requests policy counter and status label information.

     Requests the policy counters for a specific charge offer and subscribes to receive notifications when the values of the policy counter information change.

   • Requests policy-related subscriber preferences by doing one of the following:

     • Retrieves the value for a specified set of subscriber preferences and subscribes to receive notifications when the values of the preferences change during the policy session.

     • Retrieves only the values for a specified set of subscriber preferences and does not subscribe to receive notifications when the values of the preferences change during the policy session.

   Your online network mediation software (or Diameter Gateway) uses the PolicySessionRequest ECE Java combined Sy/Sp (implemented as Sh) interface, which uses the SubscribeNotificationRequest procedure and the UserDataRequest procedure.

5. ECE sends a policy response to your online network mediation software (or to Diameter Gateway), which does the following:

   • Indicates whether the request succeeded or failed and provides a list of reasons supporting the response.

   • Sends the status of the policy counters for the specified service. If the service is not specified, returns the information for all services:

     • Sends the policy specification (offer profile) name configured for the service.

     • Sends the status label associated with the policy counter.

     • Sends an effective time for the values of the policy counters. After the effective time expires, the PCRF is expected to send another request for policy counter and status label information (send another SpendingLimitReportRequest).

     • Sends the label name of the next probable status that applies after the effective time expires. For example, Medium_QoS.

     • Sends the delay interval. The PCRF can use the delay interval and the effective time to determine when to query for the policy counters again.

     ECE uses the SpendingLimitReportResponse procedure of the ECE Java Sy interface.

   • Sends the subscriber preferences.

     ECE uses the SubscribeNotificationResponse procedure of the ECE Java Sp interface.

6. The PCRF rules engine interprets the information and installs a policy on the PCEF, which the PCEF enforces.

7. A charging session is established, and the PCEF sends a Ro message to your online network mediation software (or Diameter Gateway).

8. Your online network mediation software (or Diameter Gateway) initiates a charging session with ECE.

9. ECE publishes policy notifications for the following:

   • Changes to the policy counter status for the policy counters the PCRF subscribed for (Sy data) at the beginning of the policy session.

   • Changes to the subscriber preferences the PCRF subscribed for (Sp data), if any, at the beginning of the policy session.

10. Your online network mediation software (or Diameter Gateway) consumes the policy notifications and sends the data to the PCRF.

11. As the charging session continues, ECE performs credit control functions: rates events, authorizes usage events only if adequate balance is available, administers threshold checks based on the current balance and consumed reservation of the customer balance.

12. When ECE detects a policy threshold breach during the charging session, it publishes a policy notification to the JMS notification queue containing the policy counter's new status. Your online network mediation software (or Diameter Gateway) sends the data to the PCRF.

    The customer balance change that causes the policy threshold breach could occur as a result of any of the following:

    • Usage requests coming from the network mediation system

    • Update requests coming from BRM (a subscription activity in the customer management system)

    • Top-ups coming from top-up systems

    Note:

    If ECE detects multiple breaches during a session, it sends notifications sequentially. That is, it sends a notification for the first breach. Then, ECE waits for an acknowledgment from PCRF that it has received the notification before sending the subsequent breach notification.

13. The PCRF evaluates the new policy counter values and the associated policy status labels and installs a new policy configuration on the PCEF.

    The new policy is established dynamically during the charging session.

14. The customer stops using his service, which ends the network session.

15. Your online network mediation software (or Diameter Gateway) terminates the charging session with ECE.

16. Your online network mediation software (or Diameter Gateway) terminates the policy session with ECE.

Configuring Breach Tolerance for Policy-Tier Thresholds

In policy-driven charging, policy-tier thresholds must be crossed to trigger the implementation of business rules, such as reduced QoS for subscribers who download excessive data.

For policy tier thresholds, BRM cannot authorize an amount above the threshold, even if the subscriber's credit balances are sufficient to cover the charges. Instead, BRM authorizes the remaining balance up to the policy threshold but does not send an FUI. Therefore, only about 80 percent of the remaining balance is available. The session ends when the remaining balance becomes so small that the service can no longer be supported.

To enable subscribers to continue using a service as they near a policy tier threshold, you must configure a breach tolerance for the threshold. When the threshold is crossed, the service continues under a new business rule, such as lower QoS for larger download totals.

For example, suppose the network sends a usage request for 200 MB, but adding that to a subscriber's current 1.9 GB policy counter balance will cause the balance to breach a 2 GB policy tier threshold. In this case, BRM does one of the following:

• Without Breach Tolerance: If a breach tolerance is not configured, BRM makes only about 80 MB available to prevent the usage from exceeding the policy tier threshold. The session ends when usage reduces the 80 MB balance to the point that the remaining balance cannot support the service.

• With Breach Tolerance: If a breach tolerance of 100 or more MB is configured, BRM authorizes the entire 200 MB request. This enables the subscriber's usage to cross the 2 GB policy tier threshold by 100 MB. As soon as the policy tier threshold is crossed, a change in the quality of service is triggered, and the service continues under the new policy.

You can set a breach tolerance for each balance element used in a policy counter. You decide what tolerance value is appropriate for your business needs.

To configure a tolerance for policy-tier threshold breaches:

1. Before charging servers are started, open ECE_home/config/management/charging-settings.xml and uncomment the following lines:

   <toleranceConfigMappingGroup  config-class="java.util.ArrayList">
             <toleranceConfig
      config-class="oracle.communication.brm.charging.appconfiguration.
      beans.policy.ToleranceConfig"
                  balanceElementId="12345" tolerance="1.25"/>
   
            <toleranceConfig
      config-class="oracle.communication.brm.charging.appconfiguration.
      beans.policy.ToleranceConfig"
                   balanceElementId="34567" tolerance="3"/>
    </toleranceConfigMappingGroup>

2. Save the file.

3. On the driver machine, change directory to the ECE_home/bin directory.

4. Start Elastic Charging Controller (ECC):

   ./ecc

5. Start your charging servers:

   start server

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

7. Expand the ECE Configuration node.

8. Expand charging.policyConfig.

9. Expand Operations.

10. Select setPolicyTolerance.

11. For each balance element (policy counter) to which policy specifications apply in your system, do the following:

    1. Specify values for the following parameters:

       • beid: Enter the balance element ID of the balance element.

       • tolerance: Enter the RUM units allowed to exceed the authorized usage quantity that ECE returns to the network for a specified charging session. The value must be greater than 0. Base it on your business needs.

         Your customers can use all balances and exceed their policy-tier threshold limits by the specified number of RUM units.

    2. Click the setPolicyTolerance button.

About Integrating Policy Clients with ECE

Policy clients such as Diameter Gateway integrate with ECE by using the ECE policy APIs.

The policy client uses the ECE policy Sy interface to retrieve policy counter information from ECE. The policy client, in turn, sends the policy counter information to the PCRF using its Diameter Sy interface. As part of initiating a policy Sy session with ECE, the policy client subscribes for receiving notifications that contain the policy counter information.

The policy client uses the ECE policy Sp interface to retrieve customer preferences information from ECE. The policy client, in turn, sends the customer preferences information to the PCRF using its Diameter Sp interface. As part of initiating a policy Sp session with ECE, the policy client subscribes for receiving notifications that contain the customer preferences information.

About the ECE Sy and Sp Interface

To support policy-driven charging, ECE offers policy management APIs. The ECE Sy interface enables policy clients to subscribe for and retrieve spending limit information about policy counters from ECE. The ECE Sp interface enables policy clients to subscribe for and retrieve customer preference information relevant to policy enforcement from ECE.

The following sections describe each interface:

• About the ECE Sy Interface

• About the ECE Sp Interface

ECE also supports a combined ECE Sy and Sp interface that enables policy clients to retrieve and subscribe for both types of information in one policy session. A combined ECE Sy and Sp interface reduces the number of messages between ECE and policy clients. See "About a Combined ECE Sy and Sp Interface" for information.

About the ECE Sy Interface

ECE supports the Sy interface which is used by the PCRF to retrieve policy counter information. To support the Sy interface, ECE offers the following ECE Sy procedure and notification:

• Spending Limit Report Request

  Policy clients such as Diameter Gateway use this procedure to request the status of policy counters available in ECE and to subscribe and unsubscribe (for the PCRF) to updates of ECE policy counters.

• SpendingLimit Notification

  ECE uses this notification to report statuses of requested policy counters for one or more services and also report the results of request processing.

  The policy client transfers the status information to the PCRF.

About the ECE Sp Interface

ECE supports the Sp interface which is used by the PCRF to query customer preferences. To support the Sp interface, ECE offers the following ECE Sp procedures:

• Subscribe Notification Request

  Policy clients such as Diameter Gateway use this procedure to retrieve customer preferences and to subscribe and unsubscribe (for the PCRF) to updates of customer preference data changes.

  The customer preferences can include the following:

  • Customer's allowed services

  • Customer's allowed Quality of Service (QoS)

  • Customer's preferred channel for receiving notifications (such as receiving an SMS or email)

  • Customer's preferred language

• Subscribe Notification Response

  ECE uses this procedure to report customer-preference data updates to the policy client subscribed for the notification.

• User Data Request

  Policy clients use the User Data Request procedure only to retrieve subscriber preferences without subscribing for receiving notifications when the preferences change.

• User Data Response

  ECE uses this procedure to send subscriber-preference data to the policy client.

The policy client transfers customer preference data to the PCRF.

Querying for Extended Subscriber Preference Information in Sp Query

The PCRF can also query extended information about customers and services. The policy client, such as Diameter Gateway, uses the ECE policy Sp query procedure to retrieve extended customer and service information.

To retrieve extended information from ECE using the policy Sp query request, you must configure the extended service and customer information in ECE.

To configure the query for extended service and customer information:

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.policyConfig.

4. Expand Operations.

5. Select setDsl.

6. Do the following for each type of service or customer you want the policy client to query:

   1. For the alias parameter, replace String with the alias for the extended information to use in the policy query request.

      Configured aliases are included in the policy query request.

   2. For the dsl parameter, replace String with the DSL to use to retrieve the information from ECE in the following format:

      gettype([product|customer]/attribute with arguments)

      For example:

      getObject(product/lifeCycleStateName)

   3. Click the setDsl button.

      This creates a mapping between the extended information alias with the DSL used to retrieve the extended information from customers and services.

About a Combined ECE Sy and Sp Interface

ECE supports combining its ECE Sp and Sy interfaces by offering the following procedures:

• Policy Session Request

  Policy clients, such as Diameter Gateway, use this procedure for retrieving Sp and Sy information and subscribing or unsubscribing (for the PCRF) to receiving updates to Sp and Sy data. This request is a combination of the Spending Limit Report Request and the Subscribe Notification Request.

• Policy Session Response

  ECE uses this procedure to report the information requested by the Policy Session Request and provide results of request processing.

  The policy client transfers the information to the PCRF.

About Calculating Maximum Authorization for Policy-Driven Charging Sessions

For policy-driven charging sessions, ECE readjusts the requested quota based on the following data:

• Current balance

• Used reservation across all parallel sessions

• Nearest threshold in the policy specification

For example, consider this situation:

• Current balance: 80 MB

• Used reservation across all parallel sessions (iPhone, video, computer): 35 MB

• Nearest threshold in the policy specification: 140 MB

Under those conditions, if ECE receives an authorization request for an additional 30 MB, that request exceeds the 140 MB threshold by 5 MB (80 MB + 35 MB + 30 MB = 145 MB). Therefore, unless a breach tolerance of 5 MB or more is configured, ECE authorizes only 25 MG.

Configuring ECE to Reject Spending Limit Requests Without Counters

For Sy subscriptions, you can configure ECE to reject a Spending Limit Request (SLR) if there are no policy counters available for the subscriber.

To configure ECE to reject SLRs when no policy counters are available:

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.policyConfig.

4. Expand Attributes.

5. Set the syRejectNoCounters attribute to true.

About the Policy Management API

To use the policy management API, clients call the submitPolicy API with PolicyRequest.

For details about the policy management API, see the documentation for oracle.communication.brm.charging.brs, oracle.communication.brm.charging.messages.policy, and oracle.communication.brm.charging.messages.query (for user data request/response information) in Elastic Charging Engine Java API Reference.