Skip Headers
Oracle® Communications Service Broker Policy Controller Implementation Guide
Release 6.1

Part Number E29455-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 About Policy Controller

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

Policy Controller is a Policy and Charging Rules Function (PCRF) product that makes business policy decisions as defined by the 3GPP TS 23.203 v9.9.0 (2011-06) specification.

What Policy Controller Does

You use Oracle Communications Policy Controller to shape your subscriber's service data flow. It is a decision engine with a graphical interface that you use to specify minimum and maximum bandwidth limitations, charging information, and any application redirection instructions. Policy Controller is aware of each subscriber's services, devices, subscriber profile repository (SPR) information, and online charging system (OCS) information. Consequently, you can offer subscribers a highly personalized data experience.

Policy Controller enables you to closely control how you charge subscribers for data and bandwidth consumption based on combinations of subscriber, device, and customer profile data. You specify this traffic shaping data when you create profiles which set Quality of Service (QoS) limits, charging information, and/or application redirection information. These profiles are the equivalent of the “PCC rules” defined in the 3GPP 23.203 v9.9.0 (2011-06) specification. Your profiles define exact QoS limits and link them to charging information already set in your online charging system to influence subscriber data consumption. You can have any number of profiles, and a default profile is available in case no other profiles apply.

Once your traffic shaping profiles are defined, you create Policy Controller rules that dynamically decide which profiles to apply to a subscriber at the start of each session. Your rules can use input from a variety of sources, such as subscriber profile information, the applications themselves, and so on. Policy Controller can revaluate the profile selection decisions as subscriber and network information changes dynamically. These decisions are then passed on to your Policy Charging and Enforcement Function (PCEF) which enforces these decisions.

Policy Controller includes the Policy Designer graphical interface that you use to create these profiles and rules. Figure 1-1 shows the Policy Designer Policy and Charging Profiles tab with some example profiles defined.

Figure 1-1 Policy Designer Policy And Charging Control Profile Tab

Surrounding text describes Figure 1-1 .

After you have created profiles and the rules that select them, Policy Controller applies the appropriate profiles to individual subscribers each time they start a session. Policy Controller does this by evaluating all of the rules you have created and using them to decide which profiles apply to the individual subscriber. As the session continues, Policy Controller reevaluates the rules based on new input from your other PCRF entities, such as your Subscriber Profile Repository (SPR), OCS, PCEF, or application functions (AFs). If the reevaluation causes a change in the services or bandwidth levels that a subscriber is entitled do, Policy Controller informs your PCEF for enforcement. A common reevaluation example is changing service QoS limits when a subscriber reaches a usage threshold.

As your product line changes, you can easily expand or change the profiles that specify the QoS and charging information in your profiles, and the rules that decide which subscribers are entitled to those profiles. This flexibility enables you to taylor your products to the specific usage habits, needs, and budgets of your subscribers.

Figure 1-2 shows how Policy Controller makes decisions about which profiles each subscribers is entitled to. This figure shows the various entities that offer input to the Policy Controller decision making process.

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

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

Your PCEF (or Traffic Detection Function (TDF)) enforces the decisions that Policy Controllers makes. For example, the PCEF directs the AF to change a level of service, and directs the charging engine to charge for those services.

If your PCEF already contains PCC rules that you want to use, you can add them to Policy Controller as predefined PCC profiles. Predefined PCC profiles are abbreviated PCC profiles that reference the existing PCC rule by name.

Policy Controller supports these profiles (the equivalents of PCC rules) that shape your service data flows:

The Policy Controller design enables you to create highly-customized sets of decision criteria to apply to your subscribers. The simplest example is creating PCC profiles (say, gold silver, and bronze) that index QoS limits to the monthly charges your subscribers pay. Policy Controller enables you to create highly-customized pricing plans for your services that give you the flexibility to provide special deals, exceptions, and promotions that take effect and expire whenever you choose.

After creating PCC and ADC profiles, you create Policy Controller rules that select the profiles to apply to subscriber service data flow. Policy Controller rules are if-then statements that can use information (AVPs) from a variety of Diameter reference points, including:

Policy Controller takes information from these various sources, interprets the information using the rules you created, and decides which profiles apply to individual subscribers.

Figure 1-3 shows the Policy Designer Rules tab that you use to create rules, with some example rule information. See "About the Policy Designer Interface" for more information.

Figure 1-3 Policy Designer Rules tab

Surrounding text describes Figure 1-3 .

See "Strategies for Creating Rules" for example rules that illustrate the various approaches available for applying PCC and ADC profiles to your subscribers. See "Creating Rules and Rulesets" for instructions on how to create rules.

Policy Controller obtains subscriber profile and charging information from these supported SPR/OCSs:

Policy Controller supports Offline charging through the PCEF, but the nature of offline charging prevents an offline charging system from updating Policy Controller dynamically. See "Configuring Subscriber Profile and Charging Information" for details on configuring an SPR/OCS.

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

Once you deploy a deployment, Policy Controller interprets the rules in the rulesets it contains, makes decisions regarding the QoS limits, charging information, and application redirection, and passed them on to your PCEF for enforcement.

Policy Controller also provides SMS messaging and redirection capabilities within a session. You can configure rules that send subscribers an SMS message, or redirect them to a URL of your choice when they meet the conditions you set. The SMS or target URL can contain any content that your implementation requires. These features are popular for “bill shock” prevention by using them to alert subscribers to diminishing balances and prompt them to add resources. You can also offer targeted promotions customized to individual subscribers (such as a deal on their birthday).

By default Policy Controller accepts all Diameter AVPs for the Diameter reference points it supports. You can also add support for any custom AVPs that your PCEF, AF, or other policy node uses, and use the AVPs in Policy Controller rules.

Policy Controller is based on the 3GPP standard and is Release 9 compliant. See Oracle Communications Service Broker Policy Controller Protocol Implementation Conformance Statement for details on the specifications supported.

About Policy Controller Scalability

Policy Controller uses a highly-available built-in coherence infrastructure based on the Oracle Coherence technology that you use to easily and quickly add capability. You configure coherence each time you create a domain, and your data is automatically replicated, and sessions remain persistent. For details, see the discussions about scaling the deployment in Service Broker Installation Guide and the discussion about clusters in Service Broker Administrator's Guide.

About Policy Controller Terms

You must understand the following terms when using Policy Controller:

Application Detection and Control (ADC) Profile

A Policy Controller entity that specifies QoS limits and any redirection instructions for service data flow originating with a specific application. You define activation and deactivation time limits for each ADC profile.

Application Function (AF)

AFs are the applications, or 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.

Deployment

A collection of profiles, rules, and lists of values that work together as a logical unit. Policy Controller enables you to work on these entities as a set and then save them as a .rap file for later work. You can also send deployment files to someone else to work on, and then import them back in to your Policy Designer. The currently active deployment is the set of profiles, rules, and supporting data that is open and being edited in Policy Designer.

Dynamic Profiles

You specify the details of dynamic profiles using Policy Designer and store these profiles in Policy Controller. If a profile is not dynamic, then it is predefined.

Policy and Charging Rules Function (PCRF)

PCRF is a policy control decision engine defined in the 3GPP TS 23.203 v9.9.0 (2011-06) specification. Policy Controller is the Oracle Communications PCRF product.

Facts

Objects that rules reason on. These facts are predefined, however you can define your own local facts to use within a deployment.

List of Values

Originally called bucketsets, list of values are frequently used data values that you use in rules, such as days of the week. You can create your own lists of values as needed.

PCC Rule

See PCC 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.

PCC Profile

PCC 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 Quality of Service (QoS) limits and charging information. You define activation and deactivation time limits for each PCC profile.

Predefined Profiles

Predefined profiles reference PCC rules that are already defined and stored in your PCEF. Policy Controller references these rules by naming them in abbreviated PCC or ADC profiles called predefined profiles.

Rule

Policy Controller rules are if-then statements that Policy Controller uses to decide which PCC or ADC profiles to apply to a subscriber. You create rules by using the Policy Designer Rules tab.

Ruleset

Rulesets contain a set of rules. Rulesets are intended for you to group logically related rules for convenient management.

Traffic Detection Function (TDF)

A PCEF enhanced with ADC. A software entity that sorts or filters traffic based on its packet or datagram content (service data flow). A TDF can redirect, gate, block, or shape traffic by application, or permit it to pass it unrestricted. See "Application Detection and Control (ADC) Profile" for details on ADC profiles..

About the Policy Controller Architecture

This section explains how Policy Controller relates to the other entities in your PCEF implementation and introduces you to the Policy Controller back end components.

Architecture Overview

Figure 1-4 shows the software components that interact with Policy Controller.

Figure 1-4 Policy Controller Implementation Components

Description of Figure 1-4 follows
Description of "Figure 1-4 Policy Controller Implementation Components"

About the Policy Controller Back End Components

The Policy Controller back end entities are listed in Table 1-1. You configure these entities as part of setting up Policy Controller and Policy Designer.

Table 1-1 Service Controller Entities that Policy Controller Uses

Service Broker Entity Policy Controller Usage

Domains

Policy Controller requires that you create a domain for the processing and signaling servers to run in. Your domains may be clustered. You create a domain or domains as part of installing and configuring Policy Controller.

See Service Broker Installation Guide for information on domains.

Processing Server

Policy Controller is executed one or more processing servers which are part of a domain.

See Service Broker Concepts Guide for background information on processing servers and domains.

Signaling Servers

Policy Controllers uses signaling servers (SSUs) to connect to external entities such as:

  • The Diameter SSU to configure charging, and route traffic to your PCEF and AFs.

  • The BRM SSU, if you use BRM as an SPR/OCS.

  • The SMPP SSU to add SMS capability to your rules.

You create these SSUs as part of installing and configuring Policy Controller.

See Service Broker Concepts Guide for background information on signaling servers and SSUs, and see the Service Broker Signaling Server Units Configuration Guide for instructions on configuring individual SSUs.

Administration Console

You use the Administration Console user interface for a a variety of Policy Controller configuration tasks. See Service Broker Administrator's Guide for details on using the Administration Console.

Subscriber Profile Repository (SPR) and online charging system (OCS)

You have these options for using an SPR/OCS to store and retrieve subscriber profile and charging information:

  • The local Policy Controller SPR.

  • The Oracle Communications Billing and Revenue Management SPR/OCS capabilities.

  • A third-party SPR/OCS using Web-based connectivity.

  • A third-party SPR/OCS using Diameter-based connectivity.

You will select and configure an SPR while installing and configuring Policy Controller. See "Configuring Subscriber Profile and Charging Information" for details on configuring connections to these SRPS.


About the Policy Designer Interface

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

Figure 1-5 shows the Policy Charging and Control Profile tab of the Policy Designer that you use to create PCC profiles. You then create rulesets to apply them to subscriber traffic. The Policy Designer shows these tabs: Policy and Charging Control Profiles, Application and Detection and Control Profiles, Rules, and Deployments. The Policy Charging and Control Profile subtab is shown displayed with a few PCC profiles, one per row.

Figure 1-5 The Policy Designer User Interface

This figure is described in the surrounding text.

Using Policy Designer your personnel can change business rules from any Web browser without stopping business processes.

About Creating PCC Profiles to Set Bandwidth and Charging Levels

You use the Policy Designer Policy and Charging Control (PCC) tab to create PCC profiles that specify the bandwidth limit and charging aspects of products that you sell to customers. A simple example is creating “Gold,” “Silver,” and “Bronze” PCC profiles to specify tiered levels of bandwidth that each have a different fee. Gold would be the fastest, and you charge the most for it. Silver would have slower speeds, but also cost less, and Bronze is the economy option that allows the slowest speeds, but costs the least. You can specify QoS minimum or maximum limits any way that your implementation requires. Policy Controller rules probe subscriber data when a session is started and dynamically decides which PCC profiles to apply. The PCC profile selection can change as the subscriber data changes during the session.

PCC profiles generally contain information about a specific service, but they are flexible and you can create one that applies to all services. If the PCC profile does not contain QoS or charging specifics then your PCEF must provide that information.

Keep rule flexibility in mind when planning your PCC profiles. Once you have created profiles that correspond to your products, you can create rules to decide which subscribers are entitled to those profiles. Rules can be simple or complex; they act on information from these Diameter reference points:

  • Application and media information from the AF

  • Internal rule configurations (other PCC profiles)

  • Subscriber information from the SPR

  • Information such as event triggers from the PCEF

  • Charging information from an OCS

  • Information from other PCRFs

  • Information from the BBERF

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

  • Pull (solicited provisioning). Sending PCC profiles in response to a CCR request message from the PCEF. The request is answered in a CCA message.

  • Push (unsolicited provisioning). Sending PCC profiles to the PCEF based on new data. To do this the Policy Controller includes the profiles in an RA-request message instead of using CCR/CCA messages.

Your rules can also use the event triggers specified in 3GPP TS 23.203 for pull provisioning. Event triggers are convenient shortcuts that your rules can use to apply profiles based on a subscriber's current location, credit status, Connectivity Access Network changes, and other common events. Policy Controller includes some default triggers and you can define additional triggers that your implementation requires.

About Creating ADC Profiles to Manage Application Traffic

You use the Policy Designer Application Detection and Control Profiles tab to create ADC profiles to set bandwidth limits for, and optionally redirect specific applications. ADC takes advantage for the Deep Packet Inspection (DPI) capabilities that TDFs offer to target specific applications for bandwidth limits or redirection.

ADC profiles use the same bandwidth limiting features that PCC profiles do. See "Creating an ADC Profile" for details.

You can redirect subscriber service data flow to an IP address or URL You can redirect traffic for any reason that your implementation requires, such as “parental control“ type restrictions. This setting also overrules any PCEF settings.

See "Creating an ADC Profile" for details on redirecting application traffic.

About the Policy Controller Session Call Flow

Figure 1-6 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-6 Typical Policy Controller Call Flow

Description of Figure 1-6 follows
Description of "Figure 1-6 Typical Policy Controller Call Flow"