The Binding Database

The Binding database consists of 4 tables: one Anchor Key table and three Alternate Key tables. Each binding table record maintains a list of one or more binding-capable sessions that contain a reference to the binding key. These sessions are referred to using a Session Reference (SessionRef) instance, which is just a shorter means of identifying a session (shorter than a Diameter Session Id string).

The more permanent keys (IMSI and MSISDN) can be referenced by more than one binding-capable session. These keys will not be removed until the last binding-capable session that included the key is terminated.

The transient keys (IP Addresses), on the other hand, can be referenced only by a single binding-capable session.

The metadata captured by IDIH for the PCA includes the results of each query that PCA makes to the binding database and the associated result. Whenever the result of a database query is captured in PCA metadata, it will include the identity of the specific server that generated the response.

Anchor Key

Because binding capable sessions can originate from different places in the network at nearly the same time, it is necessary to serialize the requests to prevent both from being assigned to different PCRFs. Serialization is accomplished by requiring that binding capable session origination messages (i.e. CCR-I) always contain an IMSI and that the IMSI is always used for creation of new bindings

See Error Codes.

Alternate Keys

Alternate Keys provide different ways to identify a subscriber. Alternate Keys are created by binding-capable sessions and used by binding-dependent sessions.

For example, a UE attached to a binding-dependent interface like Rx might not have access to the subscriber’s IMSI, but might have an IPv6 address that has been temporarily assigned to the subscriber. This IPv6 Alternate Key can be used to find the subscriber binding and the correct PCRF to route the Rx or Gx-Prime request to, only if that IPv6 Alternate Key record was previously created by a binding-capable session.

Alternate Keys are optional. If all interfaces have access to the IMSI, or Anchor Key, there is no need to create or use Alternate Keys. Alternate Keys are created when they are present in the binding-capable session creation message (CCR-I) and they are assigned a P-DRA Binding Key Priority.

If a binding-capable session initiation message includes multiple Alternate Keys that are also assigned with a Binding Key Priority, all of those Alternate Keys will be created when the binding-capable session is established. When a binding-dependent session creation message arrives, which Alternate Key will be used to find the binding depends to some degree on configuration.

P-DRA allows the handling of Alternate Keys to be configured. The configuration defines which Alternate Keys should be used, and the Priority order in which to use them. (Assignment of Priorities must be consecutive, without skipping a number between two other numbers.)

Table 1 illustrates an example configuration of Alternate Keys. Key types are assigned to the Priority values 1 through 4, where 1 is the highest Priority (IMSI, IPv4, IPv6, or MSISDN). If a particular type of key is not used, that key need not be assigned to a Priority. In the example, IPv4 is not being used as an Alternate Key, meaning that even if a Framed-IP-Address is present in the binding-capable session initiation message, no IPv4 key will be created.

Example of a Binding Key Priority Configuration
Priority	Key
1	IMSI
2	IPv6
3	MSISDN
4	<Not Configured>

The Priority order defines the order in which P-DRA looks for a given key type in a binding-dependent session initiating message. In the example in Table 1, P-A will look for keys in the following order and AVP:

IMSI: Subscription-Id AVP with Subscription-Id-Type of END_USER_IMSI
IPv6 Address: Framed-IPv6-Prefix AVP (only high order 64 bits used)
MSISDN: Subscription-Id AVP with Subscription-Id-Type of END_USER_E164

For each key found in the message and assigned a Binding Key Priority, P-DRA will attempt to find a binding record in the corresponding binding database table. If a key is not present, P-A will skip to the next highest Priority key type. Some keys can have more than one instance in a Diameter message, but only the first instance of a given key type will be used in the binding search.

If no configured key is present in the Diameter message, an error response is returned to the originator.
If keys are present in the Diameter message, but no corresponding binding is found, an error is returned to the originator. The configurable "Binding Not Found" error condition is used. See Error Codes.