Go to primary content
Diameter Signaling Router Policy and Charging Application
Release 8.2
E89000
Go To Table Of Contents
Contents

Previous
Previous
Next
Next

Subscriber Identification and Binding

Policy sessions can be established using multiple Diameter interfaces such as Gx, Gxx, Gx-Prime, Rx and S9. A session can be characterized as binding-capable or binding-dependent, depending on whether or not a binding can be created over it.
  • Gx, Gxx and S9 interfaces are binding-capable
  • Rx, Rx over S9, and Gx-Prime interfaces are binding-dependent
A session over a binding-capable interface will be eligible to establish a binding to a PCRF, while a session over a binding-dependent interface will rely on an existing binding to a PCRF but cannot create a new binding by itself.

In order for the Policy DRA to route all messages from a subscriber (perhaps through multiple interfaces and devices) to the same PCRF, the Policy DRA should be able to identify the subscriber by the information in the incoming Diameter Request messages. One subscriber can be associated with multiple Subscriber Ids depending on the access networks and device types used. The Subscriber Ids are also called Subscriber Keys or keys. Messages that can cause creation of a subscriber-PCRF binding are required to contain the subscriber’s device IMSI, whuch can be used to uniquely identify the subscriber. IMSI is referred to as the subscriber Anchor Key in the SBR Binding database.

Session initiating messages may also contain additional information to identify the subscriber. This information, which may include an MSISDN, an IPv4 address, or an IPv6 address prefix, is referred to as subscriber Alternate Keys. Database records with Alternate Keys are always established by binding-capable sessions, and can be used to identify the subscriber in binding-dependent sessions. For example, a Gx CCR-I message must contain the IMSI Anchor Key under normal circumstance, and may also contain an MSISDN, an IPv4 address, and an IPv6 address. After a binding is established between the subscriber and a PCRF, binding-dependent sessions containing one or more of the subscriber keys can be routed to the PCRF using an Alternate Key.

In Figure 4-6, a Gx CCR-I message created 3 subscriber keys: one Anchor Key and two Alternate Keys, all bound to a PCRF called PCRF5. When a binding-dependent Rx session (AAR message) is created containing only IP addresses with no Anchor Key, the Policy DRA functionality looks up the IPv4 address of the subscriber and is able to relate it to the same PCRF because the Gx session had defined those IP addresses.

Figure 4-6 Subscriber Key Usage

Alternate Keys can be configured with a priority (values 1 through 5, where 1 is the highest Priority (IMSI, IPv4, IPv6, or MSISDN). This improves the chances of finding the data in the Diameter message and the chances of finding the Alternate Key in the Binding database. Table 4-2 illustrates an example Binding Key configuration with priorities assigned to each key.IMSI, IPv4, IPv6, or MSISDN

Table 4-2 Example Key Priority Configuration

Priority Key Type
1 IMSI
2 IPv4
3 MSISDN
4 IPv6
5 <Not configured>
The example configuration in Table 4-2 will affect how the keys are searched in the Diameter message for binding-dependent session initiating messages:
  1. After the IMSI, the Framed-IP-Address AVP will be looked for first in the incoming Diameter Request message.
  2. If the AVP is found, the Policy SBR database is searched for a binding with IPv4 address.
  3. If the Framed-IP-Address AVP is not found, a Subscription-Id AVP containing an MSISDN will be looked for.
  4. If the Subscription-Id AVP with an MSISDN is found, look for a binding with that MSISDN.
  5. If a Subscription-Id AVP containing an MSISDN is not found, then no Alternate Keys are present in the message and no Alternate Key records will be created by the application.
Only the configured subscriber keys will be searched for. For example, an incoming Diameter message contains a MSISDN in the Subscription-ID AVP, but MSISDN is not configured in the priority configuration, the Policy DRA functionality will NOT look for MSISDN or use it in the Binding database.