Concepts and Terminology

Policy DRA upgrading incorporates new services or new PCRF infrastructure without disturbing existing services. In releases prior to 5.1, a binding was a mapping between an IMSI and a single PCRF. After a binding existed, all sessions for that IMSI are routed to the bound PCRF. Upgrading to PCRF Pooling allows for multiple bindings to exist for a single IMSI, one for each PCRF pool.

When the release that supports PCRF Pooling is installed, a PCRF Pool called "Default" is automatically created. This PCRF Pool cannot be deleted. It allows backwards compatibility with prior releases in which there was only one logical group of PCRFs, which could be thought of as a single PCRF Pool. When a network is upgraded that already has Policy DRA activated, all configured APNs are mapped to the Default PCRF Pool. The Default PCRF Pool is in turn mapped to whatever PRT table was defined to handle new bindings in the prior release.

Upgrading to a release of Policy DRA that supports PCRF Pools or PCRF Sub-Pools, requires that the Default pool must point to the PRT used for routing of new binding requests prior to the upgrade. The Default PCRF Pool is mapped to the PRT defined to manage new bindings in the prior release.

A graceful upgrade ensures the following:
Note: Migration from the pre-PCRF Pools pSBR database to the PCRF Pools pSBR database must be finished prior to upgrading beyond DSR 5.1.

Enabling PCRF Pooling

PCRF Pooling configuration can be performed before or after enabling PCRF Pooling with no unexpected behavior.

If PCRF Pooling is enabled with no configuration changes, the Policy DRA behavior will be the same as prior to PCRF Pooling being enabled (assuming that all APNs were already configured). If PCRF Pooling is configured prior to enabling PCRF Pooling, existing bindings are honored until they are released normally. Only new bindings will be routed according to the PCRF Pooling behavior.

The following rules apply to PCRF Pooling enablement:
  • When upgrading the Policy DRA application, all existing binding and session database entries are maintained.
  • When upgrading to a version of the Policy DRA application that supports PCRF Pools, the default PCRF pool must be defined.
  • When upgrading to a version of the Policy DRA application that supports PCRF Pools, all existing APNs must be mapped to the default pool.
  • When upgrading to a version of the Policy DRA application that supports PCRF Pools, the default pool must point to the PRT table used for routing of new-binding requests prior to the upgrade.
  • When upgrading to a version of the Policy DRA application that supports the PCRF pool feature prior to the PCRF Pool feature being enabled, the PCRF pool feature shall not be enabled as a result of the upgrade procedure.
  • Upgrade procedures from the Policy DRA version 4.1.5 to version 6.0 or later must ensure that the migration from the pre PCRF Pools pSBR database to the PCRF Pools pSBR database has finished prior to starting the upgrade.

Policy DRA Before and After PCRF Pooling Upgrade

The following figure illustrates the main differences between P-DRA before and after PCRF Pooling.

PCRF Pooling Effects on Policy DRA

See PCRF Pools for a description of the major differences between PCRF Pooling and non-pooling functionality.

Terminology for Upgrading Policy DRA

The following table shows a list of some common Policy DRA acronyms related to upgrading.

Upgrading Policy DRA Terminology
Acronym/Term Description
Enabling PCRF Pool Feature Enabling the PCRF Pool Feature is a one-time operation used to begin a transition period from pre PCRF Pool processing to PCRF Pool processing. This is a one-time operation and, once enabled, the PCRF Pool feature can no longer be disabled.
Graceful upgrade The ability to accomodate upgrades for PCRF Pooling functionality without disruption of existing configurations.
Migration Period For customers upgrading from a release prior to DSR 5.1 Policy DRA, a migration occurs from the IMSI-only binding table to a table that supports a binding per IMSI-APN combination. In order to avoid Split Bindings, bindings existing in the IMSI only table are honored until they naturally terminate. As existing IMSI-only bindings naturally terminate, they are replaced with IMSI-APN bindings. Once all IMSI-only bindings are gone, the migration period is complete. This data migration also applies to alternate key tables (MSISDN, IPv4 Address and IPv6 Address).
New-Binding CCR-I A CCR-I request for a specific IMSI, APN combination that occurs when there is not an existing binding SBR record for the IMSI+APN. In this case, a new binding is created for the IMSI+APN.