PCA Assumptions and Limitations

PCA has the following assumptions and limitations:

Assumptions

• For the P-DRA function, the anchor key that identifies all subscribers in the PCA network is the IMSI, while MSISDN is the key that identifies the subscribers for the OC-DRA Function
• All Gx and Gxx session initiating Diameter messages will always include the IMSI. The only exception is emergency calls from devices with no SIM card (UICC-less).
• Messages sharing a common Diameter Session-Id will never arrive out of sequence.
• PCRF/OCS names and client names start with characters that can be used to identify which PCA DSR hosts the primary connection to that equipment. This greatly simplifies routing configuration for the PCA network. The network can be configured to work without such a naming convention, but routing setup and maintenance will be unnecessarily complex.
• The PCA Gx-Prime interface support feature is backward compatible and functions whether or not PCRF pooling is available.

Limitations

• When a PCRF is selected for a new subscriber binding, a simple round-robin selection mechanism is employed. PCA PCRF selections can be overridden by DSR routing configuration. When PCRF selections are overridden by DSR, weighted load distribution can also be used.
• PCA does not support the 3GPP mechanism to redirect Policy Clients to a PCRF.
• PCA does not support growth of SBR resources. A PCA system can be configured at the time of function enablement to be as small as 3 servers, or as large as 8 PCA mated pairs of 3 enclosures each, but once the number of SBR(B) server groups per network and the number of SBR(S) server groups per mated pair is chosen at the time of function enablement, neither growth nor de-growth is supported without first disabling the functions. Disabling functions requires a total network-wide outage for PCA. (Additional mated pairs can, however, be added to grow the PCA network provided that the new mated pairs have the same number of session SBR server groups as the existing mated pairs.)
• Quota pooling is not supported. Quota pooling is a feature that would allow a number of subscribers to share a common pool of resources for policy decisions. For example, a family plan where all members of the family share access to resources such as bandwidth. PCA has no mechanism for identifying members of a quota pool such that their sessions could all be routed to the same PCRF.
• The P-DRA function supports only two of the Diameter Subscription-Id types: END_USER_IMSI (for IMSI) and END_USER_E164 (for MSISDN). Any other Subscription-Id type is ignored.
• PCA evenly distributes new sessions across the Session Policy SBR Server Groups at the mated pair, regardless of the physical location of the Active server. This results in ~50% of session accesses traversing the WAN between the mated pair sites. For mated triplet deployments having an even distribution of Session SBR server groups, ~66⅔% of session accesses traverse the WAN between mated sites.
• In cases of Regionalized OCS deployments, where the Requests are routed to an OC-DRA on a remote DSR, RBAR may have to be invoked for subsequent Requests (CCR-U/Ts) as well. If MSISDN is not present in CCR-U/T messages, regionalized routing cannot be supported.
• Enabling/disabling the OC-DRA functionality or P-DRA functionality on a per site basis or on a per NE basis while enabling both at the NOAM is not supported.
• For customers upgrading from P-DRA to PCA, the customer team must ensure that there is enough spare capacity available in the session SBRs to support the additional online charging sessions.
• The P-DRA function will reject any binding capable session initiation request after the binding migration period if: (a) the message has no APN (i.e. Called-Station-Id AVP), or has an APN that is not configured in PCA, and (b) PCRF Pooling is enabled. The specifications point out a case in which a Gxx session initiation request could be sent with no APN, which will not work for PCRF Pooling
  Note: This condition is not really considered a limitation, but it is important to understand how Policy DRA handles alternate keys. If more than one binding capable session initiation request is received having the same alternate key value, the alternate key is bound to the PCRF that the last received request having that key was bound to. For example, if CCR-I #1 arrives with IMSI X and IPv4 address a.b.c.d and is bound to PCRF A, then CCR-I #2 arrives with IMSI Y and the same IPv4 address and is bound to PCRF B, this will cause IPv4 address a.b.c.d to be bound to PCRF B
• RBAR currently cannot extract the MSISDN from the User-Name AVP, but can extract it from other AVPs. If there is need to support regionalized routing for CCRs with MSISDN stored in the User-Name AVP, the Diameter Mediation feature will have to be used to extract the MSISDN from the User-Name AVP and include it in an AVP that is supported by RBAR.
• OC-DRA extracts the subscriber's identity from the session initiation request (CCR-I) for the purpose of including it with the session state information stored at the Session SBR when session state is required to be maintained. OC-DRA does not extract the MSISDN or perform number conditioning when the subscriber's identity is retrieved in a format other than E.164 (i.e., MSISDN) such as SIP URI, TEL URI or NAI. The subscriber's identity is stored in the format in which it is retrieved from the Request.
• The following known error conditions exist could result in a split binding condition:
  1. A binding sessionRef is removed as a result of the Suspect Binding mechanism, but the actual Diameter session survived the PCRF inaccessibility. This condition is expected to be rare because for a Diameter session to survive the PCRF inaccessibility, there would have to be no signaling attempted for the session during the outage and the PCRF would have to maintain session state over the outage.
  2. A binding sessionRef was removed due to being discovered in an Early state for longer than the Maximum Early Binding Lifetime, but the actual Diameter session was successfully established. This condition is expected to be rare because the binding record is explicitly updated to Final when the master session succeeds or slave polling succeeds. This condition should only result from software errors or SBR congestion causing database update requests to be discarded.
  3. An attempt was made to create a binding-capable session record, but the attempt failed, which triggered a Session Integrity session teardown. However, this mechanism cannot succeed if no session record exists and topology hiding was in use for the policy client that tried to create the session (for example, because the resulting CCR-T cannot be routed to a topology hidden PCRF). This condition is unlikely to cause a split binding because PCA will request that the policy client tear down the session. If the policy client complies, the PCRF will have a hung session that must be audited out. If the policy client declines to tear down the session, a split binding could occur.