1 About Policy Controller

This chapter provides an overview of Oracle Communication Policy Controller and explains its capabilities and components.

Understanding What Policy Controller Does

Policy Controller is a sub-product of Oracle Communications Service Broker that you use to manage Quality of Service (QoS), optimize high bandwidth traffic, and enforce usage quotes levels for subscribers. Policy Controller is a Policy and Charging Rule Function (PCRF) product that makes business policy decisions as defined by the 3GPP TS 23.203 v9.9.0 (2011-06) specification.

Policy Controller offers real-time control over the way you allocate and charge for network capacity and services. You can easily expand and change these allocations and charging schemes as your product line of IP-based products changes.

Policy Controller includes the Policy Designer interface that you can use to graphically:

Specify the charging and policy details for your product offerings. These products define how broadband resources are allocated among your subscribers, and what you will charge for them.
Create rules that Policy Controller uses to select broadband products for your subscribers. These rules define how broadband resources are allocated among your subscribers, and under what conditions.

Policy Controller then interprets these rules and applies them to the charging and policy details and passes these decisions on to your Policy Control Enforcement Function (PCEF) for enforcement. Policy Controller can update these decisions during data flow as the data flow itself causes conditions change and new rules and QoS levels to apply.

You can traffic highly-customized pricing plans for your services based on guaranteed maximum and minimum bandwidth levels. Your customers then choose the plan that best fits their needs and budgets. You can change these offerings quickly, and use Policy Controller to offer targeted promotions customized to individual subscribers (such as a deal on their birthday).

Policy Controller is based on the 3GPP standard and is Release 9 compliant. For details on the exact specifications supported, see "Policy Controller Specification Compliance".

Policy Controller Hardware and Software Requirements

This section lists the additional components that your Policy Controller implementation requires:

There are no special hardware requirements; above and beyond those required by Service Broker. For details see the discussion on hardware requirements in Oracle Communications Service Broker Installation Guide.
Obtain a PCEF to enforce Policy Controller policy decisions. For details, see your PCEF product documentation.
Obtain a BBERF to connect to your IP-CAN, and handle policy signal flow.
Obtain a Diameter charging server to charge your subscribers for services (if not using Oracle Communications BRM).

Understanding Policy Controller Terms

You need to understand the following term when using Policy Controller:

Application Function (AF): AFs are the services that you provide to your subscribers and (generally) charge for. Policy Controller communicates with your AFs using the Diameter Rx protocol.
Bearer Binding and Event Reporting Function (BBERF): Provides user plane traffic handling as defined in the 3GPP TS 23.203 v9.9.0 (2011-06) specification. Your BBERF is responsible for: bearer binding, uplink bearer binding verification, event reporting to the PCRF, and service date flow detection.
Charging Profiles: Charging profiles specify charging information for a Policy Profile. They reference the Rating Groups and Service IDs that you have set up in your charging engine.
Policy and Charging Rule Function (PCRF): PCRF is the policy control decision engine defined in the 3GPP TS 23.203 v9.9.0 (2011-06) specification. Policy Controller is the Oracle Communications Service Broker PCRF product.
Policy Control and Charging (PCC) Rules: See Policy Profile.
Policy Control Enforcement Function (PCEF): PCEF is the policy enforcement engine that you set up to accept the policy decisions from Policy Controller. Your PCEF accepts policy decisions from Policy Controller and enforces those decisions. Policy Controller communicates with your PCEF by using the Diameter Gx protocol.
Policy Profile: Policy Profiles are the Policy Controller implementations of PCC rules as defined in the 3GPP TS 23.203 v9.9.0 (2011-06) specification. They specify the Quality of Service and Charging Profiles that determine the level of service and charging details to use. Policy Profiles also include a Charging-Rule-Name AVP that identifies the Policy Profile for activation and deactivation.
Predefined PCC Rules: Predefined PCC rules are rules that are stored in the PCEF. Policy Controller refers to these rules as static rules.
Quality of Service (QoS) Profiles: QoS profiles specify maximum or minimum service bandwidth limits to use for a Policy profile. QoS profiles determine how much bandwidth a subscriber is entitled to.

Note:

Rule nomenclature for PCRFs can be confusing. This document refers to three types of rules that Oracle's Policy Controller uses:

You use the Policy Designer Rule Editor to create rules that set conditions for service access. Policy Controller uses these rules in your policy decisions to select Policy Profiles. This document refers to these rules as simply “rules.”
PCC Rules defined in the 3GPP TS 23.203 v9.9.0 specification are implemented as Policy Profiles in Policy Controller.
Policy Profiles themselves require an entry in a Rule field. This rule is either the name of a static rule or base rule, or the value of the Charging-Rule-Name Diameter Gx AVP (Code 1005) from the 3GPP TS 29.212 specification, depending on the type of Policy Profile.

Understanding How Policy Controller Works

Policy Controller is a decision engine. It communicates with your other policy control entities, such as PCEFs, application functions, and Operational Support Systems/Business Support Systems which enforce the bandwidth restrictions and perform charging. You can also decide to let your PCEF to store the charging and policy information using predefined PCC rules. Figure 1-1 shows the various entities that offer input to the Policy Controller decision making process.

Figure 1-1 Overview of the Policy Controller Decision Making Process

Description of "Figure 1-1 Overview of the Policy Controller Decision Making Process"

You can create highly-customized pricing plans for your services based on guaranteed maximum and minimum bandwidth levels. Your customers then choose the plan that fits their needs and budget. You can change these offerings quickly, and also use Policy Controller to offer “on the fly” promotions, or promotions customized to individual subscribers.

Policy Controller is service- and subscriber profile-aware, so you can offer highly customized services based on service or profile parameters. For example you could offer special deals only good on each subscriber's birthday.

Once Policy Controller makes its decisions, it passes them on to your PCEF to implement. Your PCEF is the entity that directs the AF to changes the level of service and charging engine to charge for those services.

Figure 1-2 shows the software components of a Policy Controller implementation.

Figure 1-2 Policy Controller Architecture Overview

Description of "Figure 1-2 Policy Controller Architecture Overview"

Figure 1-3 shows the call flow of a typical Policy Controller session. The call flow helps you understand the Policy Controller components and its features.

Figure 1-3 Typical Policy Controller Call Flow

Description of "Figure 1-3 Typical Policy Controller Call Flow"

Understanding Policy Designer

Policy Controller includes the Policy Designer interface that you use to:

Create Policy Profiles that your PCEF implements as PCC rules.
Create Charging Profiles that contain charging information for the services in a Policy Profile.
Create Quality of Service Profiles that specify the bandwidth levels that a subscriber is entitled to for a Policy Profile.
Associate Policy Profiles with Charging Profiles and Quality of Service Profiles.
Create rules that decide which Policy Profiles to apply to which subscribers.

Figure 1-4 shows the Profile Editor tab of the Policy Designer that you can use to create Policy Profiles and associate them with Charging and QoS Profiles. The Policy Designer shows three tabs: Deployments, Rule Editor and Profile Editor. The Policies subtab is shown displayed with a variety of Policy Profiles, one per row.

Figure 1-4 The Policy Designer User Interface

The web-based Policy Designer interface is closely related to its Oracle Business Rules (OBR) predecessor. Your personnel can change business rules from any web browser without stopping business processes.

Note:

The Policy Designer interface is incompatible with the stand-alone Administration Console. You can not run them both on the same Service Broker implementation.

Using Rules to Select Policy Profiles

The heart of the Policy Controller feature is the Policy Designer Rule Editor tab that you can use to create rules that select (or reselect) Policy Profiles. These rules are tests to decide whether a subscriber is entitled to the bandwidth capabilities and limits in a specific Policy Profile. Each rule takes the form of an if-then statement (or collection of if-then statements).

Rules can be session- or event-based. Policy Controller is based on deep packet inspection (DPI) so it also allows service data flow traffic gating; you can allow or disallow certain kinds of service data flow based on its origin.

The Rule Editor tab contains an extensive set of data and functions to use in your if-then statements. Typically these rules are reinterpreted occasionally as a session progresses and subscribers consume services.

If you need to create multiple rules that use the same if statement, it is considerably more efficient to create a fact out of the if statement and then reference the fact in those rules.

Using Policy Profiles to Set Bandwidth and Charging Levels

Using the Policy Designer, you create Policy and Charging Profiles that set bandwidth limits and charging instructions. Once you have created profiles that correspond to your products, you create rules to decide which subscribers are entitled to those policies (products). Rules can be simple or complex; they act on:

Application and media information from the AF.
Internal rule configurations (other Policy Profiles).
Subscriber information from the SPR.
Information such as event triggers from the PCEF.

There are two ways for the Policy Controller to send information to the PCEF:

Pull (solicited provisioning). Sending Policy Profiles in response to a request from the PCEF. The request is answered in a CCA message.
Push (unsolicited provisioning). Sending Policy Profiles to the PCEF based on new data. To do this the Policy Controller includes the profiles in an RA-request message. No CCR/CCA messages are triggered by this request.

Event triggers from the PCEF are often used as catalysts for push provisioning. For example, you can create rules that change behavior based on a subscriber's current location, credit status, Connectivity Access Network changes, and so on.

Policy Profiles contain information about a specific service and may also contain:

A Quality of Service Profile containing bandwidth levels and limits for the subscriber/service.
A Charging Profile with charging and rating information for the subscriber/service.

Policy Profiles generally contain information about a specific service, but they are flexible and you could create one that applies to all services. Whether you choose to include a Quality of Service Profile, a Charging Profile, or both depends on your implementation's requirements. If the Policy Profile does not contain a Quality of Service Profile or Charging Profile then your PCEF must provide that information.

The 3GPP TS 23.203 specification makes a distinction between static and dynamic PCC rules. You can create either static or dynamic Policy Profiles by using the Policy Designer. You specify the static/dynamic status when you create the profile, and you can reverse that decision later if you need to. You reference a static rule by adding the rule name and checking the Static box when you create a Policy Profile.

About Limiting Subscriber Bandwidth

You can use Policy Controller to limit the level of service that a subscriber may access. At its simplest, you can limit upload or download bandwidth to maximum or minimum bits per second rates. More complex scenarios include granting a subscriber access to multiple services, and establishing service-based consequences if they use more than their monthly allotment of bandwidth.

You can limit Subscriber bandwidth using combinations of the following metrics:

Subscriber ID.
Service.
Content - For example, type of data such as video download or voice conversation.
Time-of-day.
Timezone.
Location - For example, local or roaming.
UE (User Equipment) - For example, some devices are allowed and others not.
Access network type such as WiMax or GPRS.
Life cycle state - For example you might degrade service for subscribers with suspended accounts.

About Guaranteeing Minimum Subscriber Bandwidth

Quality of Service (QoS) level guarantees that a subscriber's bandwidth never goes below a threshold that you specify. You can use the following parameters to set a QoS level:

Duration of session or event.
Type of Service.
Time-of-day.
Type of UE.
Location.

Using Multi-service Products

Policy Controller can create policies that are valid for all services, or per-service. Managing bandwidth per service allows you to offer multi-service plans that subscribers can use simultaneously. If services compete for bandwidth, you can control their behavior by setting different priorities for those services and selecting use options for keeping them within the bandwidth thresholds you set. For example, if two services compete for the same bandwidth you can terminate one, or throttle its bandwidth back, or simply offer to provide the same bandwidth for both at a higher cost.

Policy Controller can also create policies that are valid for all services.

These profiles are optional. You can specify this information using rules and rulesets that you create using the Policy Designer

You have the following options for modifying services that exceed their thresholds:

Remove access to the service.
Change the cost of service.
Throttle one or more services of a plan.
Block a specific UE device.

Using Subscriber Profile Information to Change Service Offerings

Policy Controller uses Service Broker Subscriber Store to retrieve the subscriber profile information listed in "About Limiting Subscriber Bandwidth". You can use any of these subscriber profile fields in your rules to create custom service offerings for each individual subscriber. For example you could offer a special service valid only on each subscriber's birthday. You can extend the default subscriber profile as needed to store and obtain the information your services require.

For more information on the Subscriber Store see Oracle Communications Service Broker Subscriber Store User's Guide.

Putting it all Together

To use Policy Controller, first follow the instructions in "Configuring Service Broker for Policy Controller" to install and set up your policy implementation. Then you are ready to start the Policy Designer user interface. Once it's started, follow the instructions in "Specifying Service and Charging Information with Policy Profiles" and "Creating Rules and Rulesets" to create:

Policy Profiles that define the bandwidth capabilities and limitations. Including:
- PCC Policy Profiles that specify the limits and capabilities.
- Charging Profiles that specify how much to charge for the specified bandwidth.
Rules that select the Policy Profiles for a subscriber to use.

Policy Controller Specification Compliance

Policy Controller adheres to the specifications listed in Table 1-1.

Table 1-1 Policy Controller Diameter-based Protocol Interfaces

Standard	Title
3GPP TS 23.203 v9.9.0 (2011-06)	3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 9).
3GPP 29.214 v9.8.0 (2011-09)	3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Rx reference point (Release 9).
3GPP TS 29.212 v9.7.0 (2011-06)	3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).

Requests for rules have mandatory and optional Attribute Value Pairs (AVPs). See "Policy Controller Protocol Reference" for information on the supported and mandatory Diameter Rx and Gx AVPs.