Sessions

In this context, a Session represents a Diameter session for a policy interface (Gx, Gxx, Gx-Prime, S9, or Rx). P-DRA maintains session state for a variety of reasons:

• Subscriber identifiers used for bindings are created and destroyed as a result of Diameter Requests sent in the context of a Diameter session. In other words, subscriber identifiers are created by binding-capable session-initiating messages and removed by session-termination messages.
• If Topology Hiding is Enabled for a binding-dependent session, the bound PCRF is stored in the session state because binding keys are not guaranteed to exist in all Requests within a Diameter session.

  Note:

  When topology hiding does not apply, the session state is not maintained for binding-dependent sessions.

There are two broad categories of Policy sessions:

Binding-capable sessions

A binding-capable session is a Policy session that is allowed to cause a new binding to be created for a subscriber.

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. If a binding exists, the CCR-I is routed to the bound PCRF.

Binding-capable sessions create and destroy alternate keys as the sessions are created and terminated.

Policy DRA APN-based PCRF Pool selection modifies the Policy DRA application logic to inspect the contents of binding-generating Gx CCR-I messages to select the type of PCRF to which the CCR-I messages are to be routed. This gives Policy DRA the ability to support service-specific PCRF sets. The APN used by the UE to connect to the network is used to determine the PCRF pool. The Origin-Host of the PCEF sending the CCR-I can then be used to select a PCRF sub-pool.

If additional subscriber identifiers, or Alternate Keys, are present in the CCR-I and configured in Policy DRA, and then Configuration, and then Binding Key Priority, binding records are created for each Alternate Key present in the CCR-I. For example, a binding-capable CCR-I may include a MSISDN and IPv4 and IPv6 addresses in addition to the IMSI. These Alternate Keys exist as long as the session exists.

Binding-dependent sessions

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 sessions are created by Rx, Gx-Prime, or the S9 version of Rx binding-dependent session initiation request messages. If a binding dependent session initiation request message arrives for a Binding Dependent Interface, Policy DRA checks for an existing binding using a key in the binding dependent session initiation request message.

• If a binding is found, the AAR is routed to the bound PCRF.
• If no binding is found, Policy DRA answers the binding dependent session initiation request using an AAA with the error code configured for the Binding Not Found error condition.

Binding-dependent sessions can use Alternate Keys when locating a binding, but can neither create nor destroy Alternate Key Binding records.

The Policy DRA generally does not need to save session state for binding-dependent sessions. The exception is when the PCRF name is being topology hidden from the Policy Client. When Topology Hiding applies, the bound PCRF name is stored in the session. Storage of the PCRF name is necessary for several reasons:

• If the Policy Client cannot learn the PCRF name from the AAA message because of the Topology Hiding.
• In-session messages (such as STR) are not guaranteed to include a subscriber identifier that could be used to look up the binding again.