H-DRA

Home Diameter Routing Agent

Core Network →
Introduced in Rel-8

H-DRA is a Diameter routing node in the home network that routes signaling messages between network functions based on subscriber identity and realm for scalable core network operations.

Category
Core Network
Introduced
Rel-8
Where
Core Network › Evolved Packet Core
Specifications
1 specs
H-DRA Description Purpose Related Classification Detected Changes Specifications

Description

The Home Diameter Routing Agent (H-DRA) is a specialized network function defined within the 3GPP Policy and Charging Control (PCC) architecture. It operates as a stateful Diameter routing node specifically within the boundaries of a subscriber's home network. The Diameter protocol is the primary signaling protocol used in LTE and 5G core networks for functions like authentication (AAA), policy control, and charging. The H-DRA's core function is to receive Diameter requests, inspect key attributes within the messages—primarily the User-Name (IMSI) and Destination-Realm—and route them to the correct destination network function, such as the Home Subscriber Server (HSS), Policy and Charging Rules Function (PCRF), or Online Charging System (OCS).

Architecturally, the H-DRA sits in the signaling path between Diameter clients (like the MME, SGSN, or P-CSCF) and Diameter servers (like the HSS or PCRF). It maintains a binding cache or routing table that maps subscriber identities (e.g., IMSI) to the specific server instance currently serving that subscriber. This is crucial for maintaining session state and ensuring that all related Diameter messages for a given subscriber session are routed to the same server instance, a requirement for functions like policy sessions. The H-DRA uses the Realm-Based Routing Table, configured with network operator policies, to determine the next hop for messages when a direct binding does not exist.

In operation, when a Diameter request (e.g., a Credit-Control-Request from a P-GW to an OCS) arrives at the H-DRA, it first checks if a binding for that subscriber and application exists. If it does, it forwards the message to the recorded server. If not, it performs realm-based routing, often involving a Diameter Redirect Agent (DRA) or using static configuration, to find the appropriate server. Once the initial message establishes a session, the H-DRA creates a binding entry. All subsequent messages for that session will use this binding for direct routing, reducing latency and lookup overhead. The H-DRA also provides load balancing across multiple instances of a server type (e.g., a pool of PCRFs) and offers resilience by re-routing traffic if a server fails.

Purpose & Motivation

The H-DRA was introduced to solve the signaling scalability and complexity challenges that emerged with the all-IP Evolved Packet Core (EPC) in 3GPP Release 8. As networks moved to distributed, cloud-based architectures with numerous instances of core network functions, direct point-to-point Diameter connections became unmanageable. This created a mesh of connections that was difficult to scale, secure, and maintain. The H-DRA provides a centralized routing layer that decouples Diameter clients from servers.

Its creation was motivated by the need for efficient subscriber-aware routing. Without a DRA, every network function would need to know the address of every possible server for every subscriber, which is impractical in large, dynamic networks. The H-DRA introduces a level of indirection that simplifies network topology, hides server deployment details, and enables advanced features like load balancing and geographic redundancy. It is a key enabler for network function virtualization (NFV) by allowing server instances to be added or removed without reconfiguring every client. It also plays a critical role in inter-operator scenarios (via the I-DRA) by providing a secure gateway for Diameter signaling between different carrier networks.

Classification

Part ofPCRF
Related approachesHSSOCS

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (3 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-15.

Rel-15 1 change

In Release 15, the H-DRA function saw enhancements related to Diameter race condition handling for Gx-based applications, ensuring more reliable session binding and PCRF selection. These clarifications were introduced to manage scenarios where multiple simultaneous signaling events could create conflicts during IP-CAN session establishment or modification. The updates aimed to solidify procedures for maintaining aligned PCC and QoS rules across network elements, particularly in roaming scenarios involving V-PCRF and H-PCRF interactions.

  • Clarifications on Diameter race condition TS 29.213CR0711
Rel-17 1 change

In Release 17, the H-DRA function was enhanced to support PCRF control of MPS for DTS, as indicated by the new CR title. This addition builds upon the existing framework where the PCRF manages policy and charging by linking Gx sessions with Gateway Control Sessions and handling S9 session procedures for roaming. The update specifically integrates control for this new capability within the established Diameter routing and session binding mechanisms.

  • PCRF control of MPS for DTS TS 29.213CR0743
Rel-19 1 change

In Release 19, the enhancement for the H-DRA function introduced a new condition for the PCRF to detect a PCEF failure in time. This addition specifically relates to the existing PCRF Failure and Restoration procedure used when a PCEF needs to contact a restarted PCRF. The update provides a more defined mechanism within the Gx session handling for the PCRF to identify such failures promptly.

  • Add a new condition for the PCRF detecting PCEF failure in time TS 29.213CR0751

Explore further

Broader topics and technologies where H-DRA plays a role.

Defining Specifications

3GPP specifications that define or reference H-DRA, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 29.213 vj20 PCC Signalling Flows and QoS Mapping Rel-19