In this section:

Overview

The 3rd Generation Partnership Project (3GPP) states that a Diameter Routing Agent (DRA) is capable of binding a user’s information to a Policy and Charging Rules Function (PCRF) after the establishment of a session. This requirement guarantees that all policy related information regarding a specific user activity (such as a call) is handled by the same PCRF.

The DSC allows the deployment of multiple PCRFs (regardless of quantity or manufacturer) within a network (see the following figure). This capability provides the following:

  • options to deploy multiple PCRFs

    • allows distribution of services

    • scalable capacity

  • flexible deployment models

    • full support for PCRF elements acting in either load sharing or active/standby redundancy models.

    • makes sure that messages regarding a user session are routed consistently to the same PCRF.

DRA Interfaces

 
DRA functionality with a routing database of session IDs is not always required. Some PCRF and PCEF vendors do not require the use of session routing because their systems are running hot standby, or they are already sharing all transaction information between mates.

For more information about session binding in the DSC, refer to Configuring Server Pools.

IPCAN Sessions

Note

IPCAN DRA functionality is available on the DSC 8000 and the DSC SWe (KVM, VMware, or OpenStack).

An IP Connectivity Access Network (IPCAN) session can be thought of as the User Equipment (UE) to Packet Data Network (PDN) connection. This is a logical connection, and many elements contribute to its implementation.  A PCRF is one of the network entities responsible for managing IPCAN sessions. A PCRF keeps track of the state of each IPCAN session that it manages. A UE can have more than one established IPCAN session. For example, if the UE is communicating with more than one PDN at a time, such as, the public internet and the IMS network for voice conferencing. The DSC attempts to route all messages pertaining to a UE to the same PCRF. This specifically means that all messages for an IPCAN session go to the same PCRF, but allows the DSC to correlate information with some applications where the binding can otherwise be unclear.

There are two network makeups under consideration:

  • Long-term Evolution (LTE):  UE -> Evolved Node B (eNB) -> Serving Gateway (SGW) -> Packet Data Network Gateway (PGW) -> PDN

  • 3G (or lesser): UE -> NodeB/Base/[other access] -> Bearer Binding and Event Reporting Function (BBERF) -> PGW -> PDN

In both cases, the Gx interface between P-GW and PCRF is used. In the second case, the Gxx interface between the BBERF and PCRF is also required.

The PGW, which is also the Policy Control Enforcement Function (PCEF) or rules enforcement, is notified on the establishment of a UE to IPCAN connection. It creates a Gx session with a PCRF. In the LTE case, this Gx session is established first, while in the other case a Gxx session from the BBERF is first.

When that Gx session is established, other network entities can make requests related to the IPCAN session.

In the DSC SWe, the IPCAN DRA feature can also enable the redundancy of IPCAN DRA state data between DSC systems that are in geographically distant sites. Geo-redundancy occurs in a database cluster, and DRA state data replicates across the four nodes in the database cluster. When there is either a node failure or an inter-node communication failure, the database cluster is not impacted.

Note

Ribbon Customer Service collaborates with the customer to set up the database and configure the cluster.

Geo-redudant IPCAN DRA on the DSC SWe

Geo-redundancy, supported and enabled by default on the DSC SWe (with KVM, VMWare, and OpenStack), occurs in a database cluster that is composed of two data centers, where each data center contains two nodes. DRA state data is replicated across the four nodes. The database cluster is not impacted when there is a node failure or an inter-node communication failure. When a node rejoins the database cluster, the DRA state data synchronizes across the four nodes based on the recent timestamp. 

 The Database Cluster Malfunction critical alarm (3156 databaseClusterMalfunction) is raised in the following scenarios:

  • One or more nodes are unreachable after a VM host failure, a database deficiency, or an inter-node communication failure. The alarm clears when the unreachable nodes or databases become reachable (3157 databaseClusterFunction).
  • The database cluster shows a deficiency and/or a mismatch between its current status and the information that the user provides for the cluster configuration. The alarm clears when the cluster is repaired [(that is when the current status of the cluster matches the provided configuration information) (3157 databaseClusterFunction)].

Diameter Sessions

Diameter Session Binding is used in networks with multiple servers performing the same function. One example is where the network operator wants messages with the same Diameter Session-Id Attribute Value Pair (AVP) to go to the same server, and another example is two Online Charging System (OCS) Servers.

Diameter Session binding is configured in the DSC by creating a Server Pool object with the pertinent application IDs served by the server pool and the Diameter IDs of the server, and by setting the Session Binding attribute to the session.

Session Database

The logic of performing session binding lookups is split between the DSC routing functionality and its internal database agent. The DSC first identifies the type of message and the type of binding required, based on Server Pool configuration, and then queries its internal database for the required destination.

The session database is stored on CPU database cards, each with dual hard drives on each DSC node.