How Diameter routing for policy can become a differentiator when offering VoLTE services?
This blog post was written by Peter Nas, Senior Solution Architect, F5 In a discussion around the added-value of a Diameter Routing Agent (DRA) in a VoLTE deployment, I was asked the following questions and would like to share my response: How does the PCRF (Policy and Charging Rules Function) make decisions around policies? Are all policies defined per subscriber, or are some policies defined per bearer (e.g. default bearer, regardless of the identity of the subscriber)? Does the PCRF collect the subscriber-related policies from the subscriber’s HSS (Home Subscriber Server) record? PCRFs are very conducive to contain a combination of general policies and subscriber-specific policies, all depending on how an operator wants to use them (assuming these PCRFs are the kind that have wide flexibility). For example, you could have a default policy for a bearer, access-type (RAT is 3G, 4g, and onwards) location, or other parameters, plus the subscriber-specific parameters depending on the HSS profile (e.g. the services and options that the subscriber has opted for), and all on top of the subscriber’s quota or other variables. We have seen that OTT providers could register a certain subscriber as a premium user of their OTT video service (or any other service), which guarantees the subscriber the highest quality-of-service (QoS) possible. Obviously, this service level would be accompanied by the appropriate charging level when he/she wants to download or interact with a video or any other service from that OTT provider. A VoLTE scenario is perfect for this example. If you are a VoLTE subscriber, you deserve to receive the highest quality of voice. But what happens if during the VoLTE call, the same subscriber requests another IMS-based service? In that case, the operator may want to assign a dedicated bearer for that specific service, enforce session binding, and manage the QoS if the bearer is shared (this is the PCRF’s role). Otherwise, the quality of service of the VoLTE call would probably deteriorate. All of the above scenarios involve a mixture of PCRF profiles, in addition to information on the network state, type of access, type of device, in home network or roaming, if an OTT provider is involved, and other parameters. Obviously, there are many factors involved, both network related and subscriber specific which a Diameter Routing Agent (DRA) can manage and ensure that the information is transmitted to and from the PCRF assigned to the subscriber for the particular session. Finally, I believe more and more operators are beginning to use PCRFs to differentiate themselves from competitors, and not “just” for cost reduction. Ensuring that the PCRF receives the right information, and transmits the information back to the Policy and Charging Enforcement Function (PCEF) to apply the policies is the critical role of signaling (mainly Diameter signaling but not limited to). Therefore, a DRA with gateway functionalities, such as the F5 Traffix Signaling Delivery Controller (SDC) is the key enabler to benefit from cost reduction and competitive differentiation in many VoLTE scenarios.Diameter request timeout on the Traffix SDC
If no 'Routing Resend Tries' or 'Routing Resend Wait Time' are set at the Diameter SDC component level and there is no 'Request timeout' value in the Peer Profile and there is no 'Server error handling script' assigned to the Routing rule. When will the request timeout when the server does not respond? and what error code will be returned to the Client? Retransmits and heartbeats are still being performed at transport layer, also Diameter watchdog is still being exchanged, so Server peer is still reachable, it just didn't send an answer.