3GPP Diameter Routing Agent (DRA)

In 3GPP TS 29.213 V11.1.0 we can find the definition of the Diameter Routing Agent. The DRA (Diameter Routing Agent) is a functional element that ensures that all Diameter sessions established over the Gx, S9, Gxx, Rx and for unsolicited application reporting, the Sd reference points for a certain IP-CAN session reach the same PCRF when multiple and separately addressable PCRFs have been deployed in a Diameter realm. The DRA is not required in a network that deploys a single PCRF per Diameter realm. This situation is now very common. Usually, in an operator’s network we can see more than one PCRF per Diameter realm. The DRA keeps status of the assigned PCRF for a certain UE and IP-CAN session across all reference points, e.g. Gx, Gxx, S9, Rx and for unsolicited application reporting, the Sd interfaces.

The Diameter clients of the DRA, i.e. AF, PCEF, BBERF and PCRF in roaming scenarios, will support all the procedures required to properly interoperate with the DRA in both the proxy and redirect modes. The proxy mode includes two variants.

Variant 1: Proxy agent based on the standard Diameter proxy agent functionality – All the messages need to go through the DRA.

Variant 2: Proxy agent based on the standard Diameter proxy agent functionality – Session establishment messages always go through the DRA. Gx, Gxx and S9 session termination messages always go through the DRA. All other messages bypass the DRA.

 

Redirect DRA
A DRA implemented as a Diameter Redirect Agent will redirect the received Diameter request message by carrying out the procedures defined in section 6.1.7 of IETF RFC 3588. The Client will use the value within the Redirect-Host AVP of the redirect response in order to obtain the PCRF identity. The DRA may provide the Redirect-Host-Usage AVP in the redirect response to provide a hint to the Client about how the cached route table entry created from the Redirect-Host AVP is to be used as described in section 6.13 of IETF RFC 3588.

Sample DRA flow establishing a Diameter Session in non-roaming case with Redirect DRA:

1. A Client receives an external trigger (e.g., IP-CAN session establishment request) that requires the establishment of a Diameter session with a PCRF.
2. A Diameter Establishment request (e.g., a Diameter CCR sent by PGW to indicate establishment of an IP-CAN session) with user information (e.g., UE-NAI) is sent by the Client and received by the DRA (redirect).
3. The DRA (redirect) stores the user information (e.g., UE-NAI) and checks whether an active DRA binding exists. If not, the DRA creates a dynamic DRA binding (assignment of a PCRF node per UE or per IP-CAN session); if the DRA (redirect) find there has been a DRA binding for the user, the DRA will select the PCRF from the binding for the client.
4. The DRA (redirect) sends a Diameter Answer indicating redirection. The target PCRF identity is included in the Redirect-Host AVP.
5. The Client re-sends the Diameter Establishment Request of step 2 to the target PCRF.
6. PCRF-1 returns a Diameter Answer to the Client.

 

Proxy DRA
When the DRA receives a request from a client, it will check whether it has already selected a PCRF for the UE or the UE’s IP-CAN session; if it does have a PCRF already selected for that UE or UE’s IP-CAN session, it will proxy the request to the corresponding PCRF. If the request is an IP-CAN session termination or gateway control session termination, the DRA will check whether PCRF routing information will be removed.

Sample DRA flow establishing a Diameter Session in non-roaming case with Proxy DRA:

Establishment of Diameter sessions using DRA (proxy):
1. A Client receives an external trigger (e.g. IP-CAN session establishment request) that requires the establishment of a Diameter session with a PCRF.
2. A Diameter Request (e.g. a Diameter CCR sent by PGW to indicate establishment of an IP-CAN session) is sent by the Client and received by a DRA (proxy).
3. The DRA (proxy) stores the user information (e.g. UE-NAI) and checks whether an active DRA binding exists.  If not, the DRA creates a dynamic DRA binding (assignment of a PCRF node per UE or per IP-CAN session).
4. The DRA (proxy) proxies the Diameter Request to the target PCRF. The proxied Diameter Request maintains the same Session-Id AVP value.
5. PCRF-1 returns a Diameter Answer to the DRA (proxy).
6. DRA (proxy) proxies the Diameter Answer to the Client. The proxied Diameter Answer maintains the same Session-Id AVP value.
7. If PA2 option is implemented, the Client uses the Origin-Host AVP value provided in the Diameter Answer of step 6. This value is the identity of the target PCRF. The client populates the Destination-Host AVP with this address and sends any subsequent Diameter messages directly to this PCRF bypassing the DRA (proxy).

Jerzy Seweryn, Software Engineer
www.computaris.com | www.professional-trainings.net