To begin, we should ask what are the intended functionalities of a Diameter Routing Agent (DRA) and a Policy Charging & Rules Function (PCRF).
A PCRF is the Policy Decision Point (PDP) virtually cut-and-pasted into IMS and afterwards taken by the 3GPP who awarded it with a new acronym based on the older concept of policy based networking. It is a place where business rules are merged with network actor information (in the case of mobile, subscribers). It acts as a centralized engine for deploying policy to enforcement points in a specific, limited domain (in the case of mobile, usually a MSC, APN, or geographic region). In theory, upstream from the PCRF the business rules themselves are stored in a rules base (the SPR), and the user information is stored in a directory (the HSS or UPSF) and the execution of the policy (rules+user+context) is done downstream by policy enforcement points. However, this theory isn’t always strictly translated to practice.
A DRA is a message switching engine that acts on a peer-to-peer network to perform proxy, translation, routing, and relay actions against messages. This is analogous to how the packet switching engine in a network element performs proxy, translation, routing, and relay actions against Ethernet/IP frames (L2-4) but it is performed on the L7 Diameter message in the context of the named interface application.
It is deployed as a strategic point of control to direct Diameter message delivery in the EPC and IMS control plane; facilitates message-proxy, horizontal scaling for control plane elements that cannot scale (load balancing); provides virtual end-points to secure and simplify external communications (virtual servers /DEA); enhances interoperability by performing translation (interop fix-up); bridges between 3GPP and Web 2.0 messaging and architectures; and creates mechanisms for the capture, distribution of, and action on information contained in messages across domains or subsystems in the EPC and IMS (the message switching stratum).
So, given those definitions, should the function of a DRA be separate from the PCRF function?
Put another way, operators who are content to become commoditized dumb pipes shouldn’t deploy embedded DRA functionality in their EPC functional elements, because they aren’t going to operationalize or monetize their networks with policy based networking driven product offerings. All they really need is a Diameter stack with a static configuration to maximize the fixed configuration economics required for commodity access providers.
Conversely, operators that do intend to pursue value above connectivity should invest in a message switching stratum, because they cannot currently deploy the DevOps apparatus required to tame the operational complexity associated with managing embedded DRA elements in a high capacity dynamic heterogeneous network to deliver policy based offerings that customers will pay extra for (because such an apparatus does not currently exist). Vendors and system integrators will maximize their short-term revenue by selling integrated DRA function at premium rate. And by doing so, they ensure that functional systems are forced to scale in the least cost-effective way as traffic increases. However, they do so with the risk that their solution will be pre-maturely re-evaluated when the need to deploy a message switching stratum arises.