Policy and Charging Rules Function

Here we provide an overview of the Tango Policy and Charging Rules Function (PCRF) operations. Typical operational flows are also described. The section contains the following sections:

  • Introduction

  • Defining Policy Rules

  • iAX PCC Rules Generation

  • Usage Tracking

  • Tango PCEF Adaptor

  • Dynamic Pricing Service

  • User Experience Management



The core function of a Policy and Charging Control (iAX PCC) platform is the generation of rules that enforce policy and charging control on a PCEF.

The PCRF uses the following inputs to generate policy and charging control rules:

  • Data session parameters from the PCEF over the Gx interface

  • Application and media information from Application Functions over the Rx interface

  • Subscriber profile information from a third-party SPR or the Tango SPCM

  • PCRF rules configuration data from the PCC database

As well as the PCC rules, event triggers are installed on the PCEF to track certain events such as location change and usage monitors are installed to track data usage by subscribers. Usage monitors and event triggers may cause a change in PCC rules.

The PCC rules generation process is illustrated later in this section.

In addition to these functions, the PCRF allows you to configure the following low-level parameters which are used in the rules generation process:

  • Quality of Service (QoS) - The QoS parameters define the uplink and downlink rates that can be applied to various service profiles and are used by the PCRF to set the quality of service in specified scenarios.

  • Location - The location parameters define specific locations in which a particular quality of service, service list and charging control may be applied. Network locations can also be defined for specific networks.

  • Service Flows - The service flows allows you to define the services that are used in the PCRF. Each service can be assigned as a downlink, uplink or bidirectional service.

  • Charging - The charging profiles allow you to define and manage the charging parameters such as charging method, metering method and rating groups, which can be applied to specific services.

  • Application - The application profiles allow you to specify how applications interact with the PCRF by controlling what media types are allowed for specific applications and what QoS level is applied to each media type.

  • Time - The time profiles allow you to manage specific time periods during which a particular QoS, service list or charging control is applied.

  • APN - The Access Point Name (APN) profiles allow you to manage special APNs for which a particular QoS, service list and charging control is applied. The APN to be used by a particular subscriber is determined by the SPCM.



Defining Policy Rules

Policy Control Rules are defined on the PCRF using the web based PMI GUI and stored in the database.

The following parameters can be defined for each rule:

  • IP quintuple filter lists - for service flows

  • QoS parameters - including maximum upstream and downstream speeds

  • Charging parameters - online/offline charging, etc.

  • Location lists - cell ID list and SGSN source IP

  • Location rates - for bill-shock control

  • Time-bands - using detailed time expressions

  • APN lists

In the case where multiple PCC rules could be applied, rule precedence is taken into account. A default rule is defined as a catch all in the case where a subscriber may not exist in the SPR database, or if no applicable rule can be found.



iAX PCC Rules Generation

PCC Rules Generation Process

The PCRF uses the following inputs to generate Policy and Charging Control rules:

  • Data session parameters from the PCEF over the Gx interface

  • Application and media information from Application Functions over the Rx interface

  • Subscriber profile information from a third-party SPR or the Tango SPCM

  • PCRF rules configuration data from the database

As well as the PCC rules, event triggers are installed on the PCEF to track certain events such as location change. Usage monitors are installed to track data usage by subscribers. Usage monitors and event triggers may cause a change in PCC rules.

Data Session Parameters (from GGSN/PCEF)

The following parameters are passed from data session (GGSN/PCEF) to the PCRF and used as part of the rules generation process:

  • MSISDN

  • IMSI

  • Bearer Identifier

  • Access Point Name (APN)

  • SGSN Address

  • Requested QoS

  • QoS Negotiation Flags

  • Location Information

  • Usage Information

Application Parameters

The following parameters are passed from an Application Function (AF) to the PCRF and used as part of the rules generation process:

  • Application Identifier

  • Flow Descriptions

  • Media Type and Context

  • Maximum QoS

Subscriber Profile Information

The following parameters are passed from the Tango Subscriber Policy and Charging Manager (SPCM) to the PCRF and used as part of the rules generation process:

  • Allowed Data Services

  • Allowed QoS

  • Charging Parameters

  • Location Information

  • Time-bands

  • Usage Tracking Parameters

  • APNs

  • DPS Parameters

Rules Configuration

The following rules configuration parameters are passed from the database to the PCRF and used as part of the rules generation process:

  • IP Quintuple Filter Lists (for service flows)

  • QoS Parameters

  • Charging Parameters (e.g. rating-group tables)

  • Location Parameters (e.g. cell IDs, SGSN addresses)

  • Location Rates (e.g. for bill-shock control)

  • Time Bands (e.g. Peak/Off-Peak)

  • APN Lists

Output From the PCRF to PCEF

Once the PCRF has taken the inputs and processed them, the following is sent to the PCEF:

  • Event Triggers

  • Usage Monitor Information

  • List of Policy and Charging Control Rules which may contain:

    • Plan Name

    • Plan Type

    • Rule Name

    • Precedence

    • Service Identifier

    • Service Status (enabled/disabled)

    • Service Flow Filter(s)

    • QoS Parameters

    • Charging Parameters

    • Discount Rate



PCC Rules Generation Call Flow

The diagram below shows a typical rules generation call flow.

PolicyControlFlow
  • When a new data session is established, a request is sent to the SPR or Tango SPCM for subscriber information.

  • The subscriber profile information is returned to the PCRF where the initial PCC rules are determined.

  • The initial PCC rules are installed on the PCEF.

  • When the data session is terminated, a rules termination message is sent to the PCRF.

  • The PCRF sends a cancellation for the subscriber to the SPR or Tango SPCM.

  • The SPCM/SPR sends a cancellation response to the PCRF.



Session IP Resolver

The PCRF rules handler contains a UE IP resolver IDL which returns the MSISDN of the subscriber based on the UE IP address assigned to the subscriber for a data session. The resolver also returns other data session parameters such as user location and PCRF session status. The returned MSISDN can then be used to query the SPCM for subscriber account and data plan information. This allows subscriber information to be determined on a redirected web portal which might only have the UE IP address available as subscriber information.


Usage Tracking

UsageTrackingCallFlow

At the start of a session the PCRF retrieves information about the subscriber profile from the SPCM. Included in this information are usage-keys which allow the PCRF to correlate data usage reports from the PCEF back to the SPCM. This enables the SPCM to track total usage per subscriber. The PCRF generates a list of PCC rules. A usage monitor is applied to each rule which allows data-usage to be categorised as it is being tracked, e.g. roaming usage can be tracked separately to domestic usage.

The usage monitors on the PCEF will return a usage report when the amount of data granted by the SPC/PCRF is consumed by the end-user. The PCRF maps this usage report to an SPCM usage key and returns a corresponding usage report to the SPCM. The SPCM can subsequently apply usage thresholds to trigger actions such as a QoS downgrade or an SMS alert.



Granted Service Units

gsu flow

The usage monitor includes the tracking of Granted Service Units (GSUs) which are defined per plan definition in your PMI configuration. This first starts at the beginning of a data session and again when the usage report update is received.

To find this on the PMI, go to Policy > SPCM > Plan Definition > Subscriber Plans Within an existing plan definition or when creating a new one, go to thesection entitled “Maximum usage allowed between usage reports”, where you can set the slider to the maximum GSU.

Though a maximum GSU is configured, say for example 100mb or 10% of a plan, the SPCM dynamically sends GSUs back to the PCRF based off any rules defined such as a notification threshold or data usage warning. So, if the subscriber is only 20mb or 2% away from the rule,the GSU sent to the PCRF will be that 20mb or 2% and not the maximum GSU.



Tango PCEF Adaptor

In cases where an operator’s network does not have a PCEF, the optional Tango PCEF Adaptor can be supplied which is designed to work with the Tango PCRF and Tango GTP data proxy.

The following diagram shows an overview of how the Tango PCEF Adaptor integrates into the network.

PCEF Adaptor Network Overview

It is assumed that the network already contains an existing Serving GPRS Support Node (SGSN), Gateway GPRS Support Node (GGSN) and an online charging system (OCS).

Key Features

The following is a list of the key features supported by the Tango PCEF Adaptor and what the Tango PCEF Adaptor can provide:

  • Rating Groups: The PCRF can assign a rating group for a data session. This rating group is used to select a table of rates in the adaptor which are passed to the data proxy. These rates apply to the traffic classes identified by the data proxy.

  • Quality of Service: The Quality of Service (QoS) may be modified at the start of a data session by the PCRF, if QoS negotiation is supported by the data network.

  • Usage Monitoring: The overall usage for a data session can be monitored and reported to the PCRF using the monitoring key specified by the PCRF. Only one monitoring key may be used per data session at any given time. This allows the usage to be accumulated for each subscriber based on, for example, APN, roaming or not roaming, location (if this is provided by the data network), peak or off-peak, etc.

  • Data Plan Support: Because usage is reported to the PCRF and rates can be set by the PCRF, Data Plans can be implemented in the PCRF. For example, a subscriber can purchase a 2GB data plan with a validity period of 1 month.

  • Bill Shock Control: Because usage can be tracked by the PCRF, a number of standardPCC services, such as bill shock, can be provided.

In addition to the features listed above, the following standard data proxy features are also available:

In many cases, these features can not be directly controlled by the PCRF.
  • Volume or duration based rating.

  • Traffic analysis and classification rules may be used in the data proxy. In particular, WAP or HTTP flows can be identified using lists of URLs configured in the data proxy.

  • Selected traffic classes can be blocked using configuration on the data proxy, but this cannot be controlled by the PCRF.

  • The data session may be blocked with redirected DNS and HTTP traffic. Different server IP addresses and URLs can be configured depending on the charging cause code, APN or subscriber type.

  • A variety of charging interfaces is supported, including Diameter “Gy”.

  • The data proxy generates data session CDRs, which include the usage per traffic class.

  • Advanced deep packet inspection (DPI) using pattern matching, behavioural, statistical and heuristic analysis is an optional feature of the data proxy.

  • The data proxy has configurable policies which determine what should happen in various failure conditions.



Dynamic Pricing Service

The PCRF rules handler supports DPS for data. DPS can be enabled at the subscriber or plan level via the PMI. If DPS is enabled for a subscriber then the PCRF will perform a DPS lookup to determine real time pricing and discounts for that subscriber.

DPS settings made at plan level take precedence over DPS settings made at subscriber level, so DPS is available to subscribers with a DPS-enabled plan regardless of suscriber-level DPS settings. As a result, suscriber opt-in/opt-out is not supported for DPS.

PCRF supports the following functions in relation to DPS:

Request Discount Rate from DPS

The PCRF rules handers sends a request to the DPS in the following situations:

  • During initial profile request if subscriber has subscribed to DPS or has a DPS enabled plan.

  • When profile update notification is received from SPCM and the subscriber has subscribed to DPS or has a DPS enabled plan.

  • When user changes location cell-id/lac and the event is reported to PCRF.

  • When a revalidation timeout event is reported to the PCRF.

  • The PCRF will request revalidation at the same intervals as the DPS discount rates are configured.

If an error is returned from the DPS or a timeout occurs waiting for a response, then no discount will be applied to the subscribers plans.

Indicate Discount Rate To PCEF For Pay-per-use Plans

When a discount rate is returned from DPS, the discount rate must be reported to the PCEF for all pay-per-use plans which have DPS enabled or for all subscribers pay-per-use plans if the subscriber is DPS enabled.

  • For plans generating dynamic rules, the discount rate is supplied via the Gx Diameter Interface.

  • For plans generating static or base rules, the discount rate is supplied by appending the rate to the rule name, e.g. FACEBOOK_20. This rule name must be setup on the PCEF.

  • If a monitoring key is also needed (e.g. to support billshock feature), then the discount rate must also be appended to the monitoring key so that the monitoring key is unique to each rule name.

The hex value of the discount rate is appended to the monitoring key, i.e. if the monitoring key is 05DE and the discount rate is 30%, then the final key is 05DE1E, where 1E is the hex representation of 30.

Apply Discount to Reported Usage for Bundle Plans

When a discount rate is returned from the DPS, the discount must be applied to the reported usage for all bundle plans which have DPS enabled or for all subscriber bundle plans if the subscriber is DPS enabled.

  • The discount is removed from the reported usage before sending on to the SPCM.

  • The reportUsage message between the PCRF rules handler and the SPCM includes the discount rate and type. The discount type is either (0) None, (1) Fixed - referring to the existing plan metering discount or (3) Dynamic - referring to a DPS discount.

A discount is typically updated during a session but this is configurable. If the operator does not want an applied discount updated during a session then the following steps will occur.

  1. At the start of the session if DPS is found (subscriber has a DPS plan or has DPSuseat subscription level) then the DPS discount is looked up.

  2. If the discount is available and not 0% then that value is set as the applied discount.

  3. If there is no discount or 0% discount then on the usual triggers we check for DPS, and if DPS found for what ever reason, a DPS discount is looked up, and a value > 0 becomes the applied discount.

  4. If DPS becomes inactive (e.g. location changed and DPS was for old location) then the PCRF will stop applying the DPS applied discount.

  5. If DPS becomes active (e.g. location changed and DPS is for new location) then the PCRF will apply the DPS applied discount it has remembered.

  6. If DPS is no longer available (e.g. plan expired) then the applied discount is reset.

  7. If DPS is acquired/found again (i.e. plan renewal, or new purchase) the PCRF will look up the new DPS discount and a value > 0 becomes the applied discount.



User Experience Managment

The User Experience Management (UEM) feature facilitates an upgrade or downgrade of service experience per plan relative to the historical cell load percentage.

A subscription profile key is added to the plan PCC profile and this key indicates the level of user experience adjustment to be allowed. The historic cell load information is retrieved via a DPS lookup and this information combined with the subscription profile information enables a service upgrade or downgrade to be implemented at the appropriate level.

  • UEM is only applied where the IP-CAN-Type is 3GPP-EPS.

  • If a PCC profile has either a Service, QoS or Charging Profile then it cannot have a subscription profile.

  • Time, Device and Location Profiles can be configured in conjunction with the susbscription profile key.

  • If two or more plans exist and each have a subscription profile key, then the subscription profile key from the highest priority plan will be used and all others are set to inactive.

  • If a PCC profile has a Time profile and a subscription profile, timing will be implemented via setting the re-validation time and not via activation times.



PCRF Hotswap

PCRF Session Hotswap

The PCRF Hotswap feature allows a Gx session on a failed PCRF to be picked up and handled by another PCRF to support continuous service for the subscriber.

The PCRF Hotswap feature:

  • Detects when a PCRF instance fails.

  • Re-routes incoming Gx messages for that session to another PCRF instance.

  • Saves the PCRF’s session context to an external store.

  • Restores the session on the new PCRF instance.

  • Transfers information about the Gx session between the primary and secondary PCRF.

Session Context Store (SCS)/Generic Db

The session context data is backed up to an external store in the case of PCRF failure; records will be stored, updated and deleted in the SCS. Session data includes Gx parameters from the PCRF rules handler, rules and monitor keys installed on the PCEF and other miscellaneous session data values.



Discount Schedule

The Discount Schedule (DS) feature allows a subscriber to select an hour of the day for which they wish to avail of a configured discount.

The operator configures the schedule on the PMI via the DS Web Service, which runs as a managed process under Process Manager (PM) control.

The discount schedule contains the hours of each day of the week for which a particular discount percentage applies. The subscriber selects a discount hour via the USSD menu.

When a subscriber opens a data session during their selected hour, the PCRF rules handler checks if the subscriber has an active DS plan. If the check is successful, the PCRF sends a request to the DS service to get the subscriber’s current DS discount. If the DS returns an OK response and a discount value, this discount is applied to usage reported for any plans the subscriber is using.

For data bundle plans, the discount is applied to the usage reported from the PCEF before it is sent to the SPCM.

For pay-per-use plans, the discount is appended to the rule name for predefined rules or specified in the Discount-Rate proprietary AVP in the Charging-Rule-Definition AVP for dynamic rules.

A subscriber may change their discount hour at any time but they may only use one discount hour on any day. If the subscriber has already used their discount hour that day, any change to the discount hour will only begin to apply on the following day.



Graceful Shutdown

You can gracefully shutdown the PCRF Rules Handler by setting it to run in an OFFLINE mode using the SE interface. In OFFLINE mode it does the following:

  • rejects any new session requests

  • terminates any existing session

  • continues to process usage reports until all sessions are terminated

When moved to ONLINE, it does the following:

  • stops the session terminations

  • allows new sessions to be started again

The batch size and interval at which active sessions are terminated when in OFFLINE mode are configurable, as is the interval at which the number of busy instances is checked and output.The shutdown process works as follows:

  1. On starting up the PCRF rules handler, the diameter state manager state machine will be initialized as with other state machines.

  2. When the Gx session, Rx session and rules handler service logic state machines initialize, each registers callbacks with the state manager to obtain the maximum number of instances, the number of busy instances, and check if an instance is busy. Only the Gx session state machine enables shutdowns when registering the callbacks as this is the entry point for Gx sessions in the PCRF and terminating a session here will trigger the session to be terminated in the rules handler service logic and the Rx session.

  3. When the PCRF needs to be shut down for an upgrade, the operator sends an SE message to the diameter state manager state machine instructing it to go offline (set the stopSessions parameter to 1).

    1. This both stops new sessions and triggers the shutdown of all existing sessions in batches, as configured.

    2. In each interval, the diameter state machine sends a shutdown message to any busy instances of state machines that enabled shutdowns when registering their callbacks. In the case of the PCRF, this only entails the Gx session state machine.

    3. The Gx state machine must handle the shutdown message by requesting that the session be terminated on the PCEF. This triggers a CCR-T from the PCEF to the PCRF, which will terminate the session as required.

    4. While shutting down active sessions, the diameter state machine also checks the number of still busy instances on each of the registered state machine at the configured interval and outputs the result to the pm.log file. This informs the operator when all sessions have been terminated. The checking of busy instances can be enabled or disabled for the Gx session, Rx session, and rules handler service logic state machines as required.

    5. At any point, the PCRF can be returned to ONLINE mode through a request to the diameter state manager. This stops the process of terminating existing sessions and also allows new sessions be started

  4. The current state and the number of busy and maximum instances in each of the registered state machines can be checked at any time by sending a request to the diameter state manager.