Processing Phases

On a system that is upgraded to PCRF Pooling, consider the following phases (note the dependencies):

System upgraded, but PCRF Pooling not yet enabled
PCRF Pooling enabled and database migration in progress (this is applicable if you have upgraded from a prior release where Policy DRA was activated)
PCRF Pooling enabled and database migration completed (this phase is equivalent to a new install with PCRF Pooling and is applicable if you have upgraded from a prior release where Policy DRA was activated)

System Ungraded, but PCRF Pooling Not Yet Enabled

After and during the upgrade, but prior to enabling PCRF Pooling, no behavior changes from the prior release.

All signaling business logic from the prior release is still used.
All PCRF Pooling data can be safely configured without affecting ongoing signaling.
All bindings and sessions are maintained over the upgrade.
All new bindings are created in the old binding tables.
APN to PCRF Pool mappings are not yet used.
The APN present in session initiation requests is ignored except for the purpose of establishing the proper Stale Session Lifetime as was done in the prior release.
All sessions with the same binding key are routed to the same PCRF.

PCRF Pooling Enabled and Database Migration in Progress

PCRF Pooling functionality is enabled from the NOAMP GUI at Policy DRA > Configuration > Network-Wide Options by checking Enable PCRF Pooling. PCRF Pooling can only be enabled after all servers in the network have been successfully upgraded to the release supporting PCRF Pooling and the upgrade has been accepted on all servers. The GUI will not allow PCRF Pooling to be enabled until this state has been achieved.

After PCRF Pooling is enabled, the following occurs:

Binding capable session initiation requests arriving with no APN, or an APN that is not configured in Policy DRA > Configuration > Access Point Names, are responded to using the Diameter error response configured for the Missing Or Unconfigured APN condition at Policy DRA > Configuration > Error Codes.
Note: This does not apply if a binding exists for the IMSI prior to enabling PCRF Pooling. In that case, the signaling will succeed even with no APN.
PCRF Pool selection occurs.
The binding database is consulted to determine if a suitable existing binding should be used as follows:
- If there is a binding in the IMSI-Only table for the IMSI, that binding is used, else
- If there is a binding in the IMSI+APN table for the IMSI and APN, that binding is used, else
- If there is a binding in the IMSI+APN table for the IMSI and PCRF Pool, that binding is used, else
- Create a new binding.
If a new binding is necessary, it is created using the new IMSI+APN table, and includes the IMSI, APN, and PCRF Pool.
If a new binding was created, the Policy DRA application asks the routing layer to route using the PRT table mapped to the selected PCRF Pool or Sub-Pool.
If an existing binding was selected, the Policy DRA application asks the routing layer to route using the PRT precedence as follows:
- PRT associated with the ingress Peer Node, OR
- PRT associated with the Diameter application-id, OR
- The Default PRT, OR finally
- Connections associated with the egress Peer Node
When a binding-capable session is successfully established (for example, by success response from PCRF):
- The PCRF that answered is written to the binding such that all subsequent requests that match the binding are routed to the same PCRF.
- See The Binding Database.
Old and new tables for IMSI, IPv4, IPv6, and MSISDN are all audited during the migration period.

PCRF Pooling Enabled and Database Migration Completed

After there are no more records in the old binding tables (ImsiAnchorKey, MsisdnAlternateKey, Ipv4AlternateKey, and Ipv6AlternateKey), the migration period is considered to be complete. Note that because these tables are partitioned across a number of binding pSBR server groups, each server group makes the determination independently as to whether migration has completed. There is no global indicator that shows that migration has completed across the entire binding database.

After migration has completed for a binding pSBR server group:

All new bindings are created in the IMSI+APN, MSISDN+APN, and the new IP Address tables (ImsiApnAnchorKey, MsisdnApnAlternateKey, Ipv4AlternateKeyV2, and Ipv6AlternateKeyV2).
Early Binding Master sessions are explicitly updated when they become Final; there is no more implicit transition to Final.
All Early Binding polling occurs at the binding database, eliminating the need to route an Early Binding Slave Diameter request to the mated pair of the Early Binding Master session with the PDRA-Early-Binding AVP included.
Binding dependent session initiation requests using MSISDN as correlation key must include a configure APN, or binding correlation for the MSISDN key will fail.
Auditing of the IMSI-Only, MSISDN-Only, and old IP Address tables ceases.
Memory for the portion of the database owned by that server group for the IMSI-Only, MSISDN-Only, and old IP Address tables (actually, the old DB Part fragments) is freed.