PCA Assumptions and Limitations

PCA has numerous 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.
• A complete suspect binding and session removal from the network (not only from the binding and session SBRs) requires the involvement of the policy clients with corresponding actions in response to PCA's RAR requests. PCA has no control on a policy client's behavior. When a PCEF receieves a Gx RAR with Session-Release-Cause AVP, it is expected to send:
  • A RAA (2001 Result Code AVP value) in response to the RAR
  • A GX CCR-T to terminate the GX session

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.
• 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 (for example, 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 (for example, 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 known error conditions could result in a split binding condition are:
  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.
• Site redundancy that occurs while an SBR Re-Mating migration is in progress is not supported.
• A binding is associated with a subscriber key (IMSI) that is used to route the request Diameter message to a specific PCRF. If a request message contains multiple subscriber keys (MSISDN, IPv4, and IPv6), then all associated keys are part of the suspect binding removal procedure.
• In some specific situations, a Binding Capable Session can be established without an IMSI value. In such scenarios, additional Sessions may be established and routed using the alternate keys from the original Binding Capable session without an IMSI. If a Diameter message fails and matches the Suspect Binding Removal Rules, the original Session is removed immediately, regardless of the Remove Immediately attribute value of the matching rule.