PCRF Pools and Sub-Pools Concepts and Terminology
This section describes some basic Policy DRA PCRF Pools and Sub-Pools concepts, and includes useful acronyms and terminology.
Related Topics
PCRF Pools
A PCRF Pool (one or more) is a set of PCRFs able to provide policy control for a specific set of services. Creating multiple pools requires that Policy DRA has the ability to select the pool to which a new-binding CCR-I belongs.
Note:
Enabling the PCRF Pool function is a one-time operation used to begin a transition period from pre-PCRF Pool processing to PCRF Pool processing. After the function is enabled, it cannot be disabled.Although the concept of a PCRF pool might appear to be a network-wide concept, PCRF pools configuration is done on a Policy DRA site-by-site basis. Policy DRAs in different sites must be able to have different PCRF Pool Selection configurations.
When deploying multiple PCRF pools, each pool supports either different policy-based services or different versions of the same policy based services. Each PCRF pool has a set of DSR Policy DRA peers that are a part of the pool.
As shown in Figure 3-1, there is a many to one relationship between APNs and PCRF pools. New sessions for the same IMSI can come from multiple APNs and map to the same PCRF Pool.
Figure 3-1 Relationship between APNs and PCRF Pools

Figure 3-2 illustrates the relationship between IMSIs and PCRF pool. The same IMSI must be able to have active bindings to multiple PCRF pools.
Figure 3-2 Relationship between IMSIs and PCRF Pools

Figure 3-3 illustrates multiple PCRF pools, each supporting a different service. In this example, PCRF pool 1 might be dedicated to policy control over the usage of enterprise data services and PCRF pool 2 might be dedicated to policy control over the usage of consumer data services. It is possible to deploy their policy control capabilities in this way to better enable capacity management of the two PCRF pools.
Figure 3-3 Multiple PCRF Pools

PCRF Pooling Modes
Routing used by PCRF Pooling depends on the Pool Mode. In Single Pool Mode, all binding capable session initiation request messages are routed to the Default PCRF Pool, regardless of the PCRF Pool mapped to the APN received in the request. The Default PCRF Pool is created automatically. This PCRF Pool is mapped to a Peer Route Table at every DSR site. In Single Pool Mode, all new binding capable session creation requests are routed to the default PCRF pool defined by a Peer Route Table at each DSR site.
In Multi Pool Mode, binding dependent session creation request messages, if required to correlate using MSISDN or IMSI keys, must include an APN. If an APN is not included in the requests, a Default APN is configured to be used to look up bindings using MSISDN or IMSI. The Default APN is used to operate PCRF Pooling in Multi Pool Mode but have a specific set of binding dependent interface equipment that initiate policy Diameter messages for subscribers for which the binding capable sessions were created using a single APN without including that APN in the binding dependent request message.
In Multi Pool Mode, binding dependent session creation request messages, if required to correlate using IPv4 or IPv6 addresses, need not include an APN in the request. The Default APN is also not used for binding correlation using IP addresses.
PCRF Sub-Pools
Note:
Sub-pool rules are not applicable while operating in Single Pool mode.PCRF Sub-Pools configuration is an optional procedure. PCRF Sub-Pools are used to divert a controlled amount of traffic from a PCRF Pool to a subset of the PCRFs in that pool. This allows new PCRF capabilities or policies to be tested on a portion of the policy signaling prior to using them for the entire network.
Specification of what policy signaling should be routed to the PCRF Sub-Pool is accomplished by configuring PCRF Sub-Pool Selection Rules. Each rule specifies the PCRF Pool that is being subdivided and the Origin-Host of the PCEF, or PCEFs, whose traffic should be routed to the Sub-Pool. If no match is found in the PCRF Sub-Pool Selection Rules, then the original PCRF Pool, selected using the APN, is used for routing. Like PCRF Pool routing, Sub-Pool routing applies only to new bindings.
Figure 3-4 illustrates the concept of PCRF sub-pools. In this figure, there are multiple versions of PCRF Pool 1. This might be necessary when deploying a new version of a PCRF policy-based service and you need to target a subset of the overall sessions for that service to a PCRF running the new version of the PCRF Pools. All other sessions would be routed to the PCRF pool supporting the older version of the policy-based service.
A PCRF Sub-Pool is differentiated by the PCEF from which CCR-I messages originate. As such, PCRF sub-pools support requires adding origin-host to the selection criteria for identifying the PCRF pool.
Figure 3-4 Multiple PCRF Versions in a PCRF Pool

To incrementally add service to a new version of the PCRF, PCRF pool configuration would progress:
- PCRF Pool 1 is defined with the set of APNs that are to be routed to that PCRF pool.
- When a new version of the PCRF in Pool 1 is installed, the configuration is modified to have all new bindings from a specific subset of PCEFs route to the new PCRF in sub-pool 1. CCR-Is received from the remainder of the PCEFs are configured to continue to route to PCRF Pool 1.
- Over time, the configuration can be modified to so that bindings from other PCEFs will be routed to sub-pool 1. Alternatively, the sub-pool rule can be removed, resulting in all PCRF instances being part of the PCRF Pool.
- After the new version of the PCRF is proven confirmed, the configuration is modified so that all CCR-Is are routed to PCRF Pool 1.
Figure 3-5 shows example routing scenarios using PCRF Pools and Sub-Pools.
Figure 3-5 PCRF Pools and Sub-Pools Routing Scenarios

Planning for PCRF Sub-Pooling
To plan for PCRF Sub-Pooling, consider:
- Identify the PCRF (or PCRFs) on which the new functionality is to be proven. The PCRF could be an existing PCRF already in a pool, or a new PCRF not yet assigned to a PCRF Pool.
- Determine which PCRF Pool the PCRF belongs to.
- This can be accomplished by examining routing data at the mated pair of DSRs that have connections to the PCRFs.
- It is possible, though unlikely, that a PCRF could exist in more than one PCRF Pool.
- Determine which APNs map to the PCRF Pool.
- This can be accomplished by examining the Access Point Names at the NOAM.
- Filtering can be used to display only APNs that are mapped to the PCRF Pool of interest.
- Determine which PCEFs use the APNs.
- Determine which PCEFs host names you want to route signaling to the PCRF Sub-Pool that will contain the PCRFs. Use caution not to overwhelm the PCRFs planned for the Sub-Pool by routing more signaling than they can reasonably support.
Session Binding
IMSI and MSISDN bindings always include an APN. IP address bindings do not include APN. In Multi Pool Mode, the APN is used to select the PCRF Pool for new bindings. In Single Pool Mode, the Default PCRF Pool is always used for new bindings.
Policy Sessions
There are two broad categories of Policy sessions: binding-dependent and binding-capable.
A binding-dependent session is a Policy session that cannot cause a binding to be created, and cannot be created unless a binding exists. Binding dependent session creation requests contain binding keys by which the subscriber's binding can be found. This process is called binding correlation. In Multi Pool Mode, if binding correlation is to be performed using IMSI or MSISDN keys, an APN must also be present in the binding dependent session creation request. In Single Pool Mode, binding correlation using IMSI or MSISDN need not include an APN. Binding correlation using IPv4 or IPv6 addresses never requires an APN in the binding dependent session creation request.
A binding capable session is a policy session that is allowed to cause a new binding to be created for a subscriber and APN. Binding capable session initiation requests must include both IMSI and APN. In Multi Pool Mode, new bindings for a subscriber are distributed across PCRFs in the PCRF Pool assigned to the APN provided in the session creation request. In Single Pool Mode, new bindings for a subscriber are distributed across PCRFs in the Default PCRF Pool, regardless of the PCRF Pool assigned to the APN in the session initiation request. Binding capable session initiation requests may also create alternate keys by which the subscriber may be identified. These alternate keys include MSISDN, IPv4 address, or IPv6 address. The binding of a subscriber and APN remains intact as long as the subscriber has at least one binding capable Diameter session for that binding.
Binding-capable sessions are created by Gx, Gxx, or the S9 versions of Gx and Gxx interfaces. If a CCR-I message arrives for a Binding Capable Interface, Policy DRA checks for an existing binding for the IMSI and APN in the message.
Binding data is accessible from anywhere in the network. Session data is scoped to a mated pair, and is only accessible from that mated pair.
Policy DRA Terminology
Table 3-1 shows a list of some Policy DRA terms and their meanings as they apply to this document.
Table 3-1 Policy DRA Terminology
Term | Meaning |
---|---|
Ambiguous Rules | Two rules are ambiguous if they have equal priority, different conditions, different PCRF Pools, and a best-match cannot be determined for a single binding-capable request. |
Binding | A mapping in the Policy DRA from an IMSI and APN to a PCRF for the purpose of routing policy Diameter signaling. Once a binding exists for an IMSI and APN, all policy Diameter sessions with that IMSI and APN are routed to the bound PCRF. A binding ceases to exist when the last Diameter session for that IMSI and APN is terminated. See also PCRF Pool Binding. |
Binding-dependent Session | A specific PCRF peer to which sessions can be bound. A PCRF pool consists of multiple PCRF instances. |
Condition Operator | A logical operator used to compare the Condition Parameter with the Condition Value. Only the Origin-Host parameter is supported in this release. Operators supported for Origin-Host are: Equals, Starts With, and Ends With. |
Condition Parameter | The binding-capable session initiation request AVP to be used for PCRF Sub-Pool selection. The only supported Condition Parameters is Origin-Host. |
Condition Value | The value of the Condition Parameter to be matched using the Condition Operator. For example, in the Condition Origin-Host Starts With abc, abc is the Condition Value. |
Conflicting Rules | Two rules conflict if everything in the rules is the same except for the PCRF Pool. |
Duplicate Rules | Rules are duplicates if everything (Origin-Host operators and values, Priority, PCRF Pool, and PCRF Sub-Pool) in the two rules is the same. |
Early Binding | An Early Binding is a binding for which a session initiation request has been received, but no session initiation answer has been received. The PCRF for an Early Binding in unknown. A given IMSI-APN combination can have only one early binding. The Early Binding serializes binding creation attempts for a given IMSI and APN. Subsequent session initiation requests for an IMSI-APN combination for which an Early Binding exists are held until the Early Binding becomes a Final Binding. |
Early Binding Master | A binding-capable session initiation request that creates a new Early Binding is referred to as the Early Binding Master for that binding. A given Early Binding can have only one master. The term master is used to convey that no subsequent binding-capable session initiation requests for that binding can be routed until the master session is successfully answered by a PCRF. |
Early Binding Slave | A binding-capable session initiation request that matches an Early Binding is referred to as an Early Binding Slave for that binding. There may be multiple slaves for a given Early Binding. The term slave is used to convey that the slave session request must wait for the master session request to be completed before it can be routed. |
Existing-Binding CCR-I | A CCR-I request for a specific IMSI, APN combination that occurs when there is an Existing-Binding CCR-I binding SBR record for the IMSI+APN. In this case, the existing binding for the IMSI+APN is used to route the CCR-I request. |
Final Binding | A Final Binding is a binding for which the PCRF is known because the PCRF sent a success answer in response to the session initiation request. When a binding-capable session initiation success answer is received, an Early Binding is explicitly marked as a Final Binding. |
IPcan Session | A connection to the Enhanced Packet Core. |
Migration Period | For customers upgrading from DSR 4.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). |
Non-Specific Binding Correlation Key | A binding correlation key value that may be specified in more than one binding-capable session initiation request is considered to be a non-specific binding correlation key. Non-Specific Binding Correlation Keys are generally associated with the subscriber vs. being associated with a particular session. IMSI and MSISDN are examples of non-specific binding correlation keys because multiple sessions may exist concurrently with the same IMSI or MSISDN value. IPv4 and IPv6 addresses are not non-specific because each binding-capable session is expected to have its own unique key value. (Note: There is a chance that Gx and Gxx sessions for the same IMSI could include the same IP addresses, but in this case the Gx and Gxx sessions are expected to have the same APN and should be routed to the same PCRF.) |
PCRF Instance | A specific PCRF peer to which sessions can be bound. A PCRF pool consists of multiple PCRF instances. |
PCRF Pool | A logical grouping of PCRFs intended to provide policy decisions for subscribers associated with a particular APN. Policy DRA supports 7 PCRF Pools per Policy DRA Network. A PCRF Pool is selected using the configured mapping between the APN and the PCRF Pool. More than one APN may point to the same PCRF Pool. |
PCRF Pool Binding | For a given IMSI, if no binding exists for the APN present in the binding-capable session initiation request, the request must be routed to the same PCRF bound to another APN that maps to the same PCRF Pool, if one exists. For example, if APN X and APN Y both map to PCRF Pool Maple and there is already a final binding for APN X, a binding-capable session for APN Y must route to the same PCRF that APN X is bound to. |
PCRF Sub-Pool | A logical sub-division of a PCRF Pool selected by Origin-Host. PCRF Sub-Pools can be used to selectively route policy traffic to a set of PCRFs for the purpose of proving in new PCRF capabilities. More than one PCRF Sub-Pool Selection Rule may point to the same PCRF Sub-Pool. |
PCRF Sub-Pool Selection Rule | A rule that defines a mapping from PCRF Pool and Origin-Host to PCRF Sub-Pool. A set of values that must be matched against AVP values in a binding-capable session initiation request for the purpose of selecting a PCRF Sub-Pool. The number of PCRF Sub-Pool Selection Rules per PCRF Pool is limited to 10. |
Primary PCRF Pool | A PCRF Pool that is mapped to an APN, as opposed to a PCRF Sub-Pool, which is mapped to a PCRF Pool and an Origin-Host. |
Redundant Rules | Rules are redundant if the PCRF Sub-Pools are the same and a request matching the more specific rule always matches the less specific rule. Redundancy does not include the default rule. The PCRF Sub-Pool Selection Rules GUI does not prevent creation of redundant rules since the PCRF Sub-Pool is the same, leaving no ambiguity. |
Rule Condition | Each PCRF Sub-Pool Selection Rule consists of a condition made up of a parameter (Origin-Host), an operator, and a value, for example Origin-Host Equals pcef015.tklc.com. |
Rule Matching | Rule matching is the process of finding the best match among the configured PCRF Sub-Pool Selection Rules for a given binding-capable session initiation request. Rule matching occurs on the DA-MP that processes the binding-capable session initiation request. |
Rule Priority | Each PCRF Sub-Pool Selection Rule has a priority value from 1 to 99, with 1 being the highest priority. The Rule Priority allows the user to give preference to one rule over another, regardless of which rule might be the best match. |
Split Binding | A Split Binding is defined as a situation in which a given subscriber has more than one binding for the same APN. Note: Split bindings would be created by addition of more specific PCRF Pool selection criteria. For example: Adding an explicit APN to PCRF Pool mapping when the -Unrecognized- APN mapping was previously being used. Adding a more specific PCRF Sub-Pool Selection Rule. Policy DRA prevents Split Bindings by always honoring existing bindings for an IMSI-APN combination. The presence of an existing binding for the IMSI-APN combination overrides the rule-based PCRF Pool selection. Prevention of Split Bindings is necessary to avoid having two PCRFs delivering possibly conflicting rules to one PCEF. Added benefit is avoidance of ambiguity in binding correlation for non-specific binding keys. |
Suspect Binding | A Suspect Binding is a Binding for which Diameter messaging to a PCRF has detected a Rule Match. Once a Rule Match has been detected, all Bindings for the subscriber(IMSI) to the PCRF are considered Suspect. It is possible for a subscriber (IMSI) to have both Suspect and non-Suspect Bindings. |