The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
CPS Diameter Routing Agent (vDRA) is the functional element in a network that routes messages to the destination node based on routing algorithms.
CPS vDRA is primarily responsible for routing messages and sending responses back to the origin node.
CPS vDRA is compliant with IETF RFC 3588 and 3GPP 29.212 and 29.213 message AVPs.
DRA performs the following functions in the network:
Peer Aggregation:
Provides an aggregation point to eliminate full mesh of endpoint peer connections.
Addition of endpoint does not require reconfiguration of endpoints. Requires only the configuration of a new endpoint on DRA.
Intelligent Routing:
Provides intelligent load balancing behavior for endpoints (PGW, AF).
Endpoints typically only route to primary/secondary peer connections.
Route requests to servers (PCRF, OCS) based on content of Diameter AVPs (Called-Station-ID, IPv4 Address, IPv6 Address and IMSI-APN combined).
Weighted routing of requests to diameter servers (PCRF, OCS).
Binding:
Route requests for related diameter sessions to the same Diameter server (PCRF, OCS). For example, DRA binds Gx and Rx to the same IP session using the framed IPs.
Relay:
DRA provides mechanism to relay request to another DRA. In certain cases, when route for the request is found on a remote DRA, the request is relayed to the remote DRA.
The following figure illustrates the components of CPS vDRA architecture.
DRA Director is stateless node. DRA Director has diameter stack running on it, which connects to the external network functions (for example, PCEF, PCRF, AF). DRA Director receives request messages from origin peer, applies routing algorithm, forwards messages to the destination peer. DRA Director then gets answer messages for the requests, which are forwarded back to the origin peer.
DRA Processor is also stateless node that interacts with session and binding databases in the persistence tier to store session and bindings.
DRA Database is used to store bindings and sessions, with MongoDB database running on them. DRA Database uses application based client sharding to distribute data among multiple databases. MongoDB replicates data across multiple databases within the replica set to provide high availability.
Each of these tiers can be scaled horizontally by deploying more virtual machines.
CPS vDRA can be deployed as IMS or Policy or a combination of both.
Policy DRA is a functional element that supports Gx, Rx, Gy, Sy, and Sd diameter interfaces.
Policy DRA has a binding function that ensures diameter messages for Gx and Rx sessions for the same IP-CAN session are routed to the same PCRF when multiple and separately addressable PCRFs have been deployed.
IMS DRA is a functional element that supports many diameter interfaces including S6a/S6d, S6b, Sh, Cx, SLh, SLg, SWm, SWx, SWa, and STa.
IMS DRA supports SLF-based routing to ensure Diameter messages are routed to an HSS and AAA server that can provide service for a UE based on a subscriber key (that is, IMSI or MSISDN).
Combination DRA is a functional element that supports both Policy DRA and IMS DRA functionality.
Feedback