Peter Nas, Senior Solution Architect, F5 Networks

Peter Nas, Senior Solution Architect, F5 Networks

This article was written by Peter Nas, Senior Solution Architect for the Traffix SDC, F5 Networks

Operators have begun to get more and more serious around deploying VoLTE (Voice over LTE) in their networks. Since the announcements of VoLTE services from some Korean and US operators, others, particularly in Asia, North America and EMEA, have launched or are about to launch VoLTE (see GSA announcement of 17th Sep 2014: 71 operators in 36 countries investing in VoLTE deployments, studies or trials, 10 operators commercially launched HD voice using VoLTE). More often than not, operators use a Diameter Routing Agent (DRA) to support correct routing and control of the Diameter signaling related to VoLTE.

Basic session binding

In 3GPP, a DRA is defined for session binding in IP-CAN sessions (equivalent to PDP context in 3G) towards a PCRF server. This was designed for multiple Diameter sessions in VoLTE in order to control the LTE and the IMS parts of the VoLTE service. To maintain an efficient and scalable network rollout, it is important that the LTE parts of an IMS VoLTE call, together with the IMS parts, are controlled by one and the same PCRF (server). Similarly, consistent policy rules need to be applied to the session that are related to the same VoLTE call. Let’s explore in some more detail what needs to be managed by the same PCRF server and why.

When using a VoLTE-enabled device, the mobile subscriber first needs to register to the network and establish the default data bearer to exchange data with the network or applications. This is followed by the authentication and authorization procedures, and mobility management communication between an MME and the HSS where the subscriber profile is stored. (Incidentally, the signaling for these procedures typically uses the Diameter S6a interface that is also often routed with help of a DRA).

Now this device can establish the always-on LTE default user data bearer. In order to do so the device communicates with the PGW and establishes a user data session. For that user data session, in this case still the default bearer, the PGW needs to contact the PCRF via the Diameter Gx interface and receive the policy and charging rules for this customer’s data session.

Once the policies have been exchanged and applied by the PGW and sometimes there are other involved PCEFs (Policy and Charging Enforcement Function), the mobile user can either use Internet services via the established default bearer or in our scenario, opts to continue to establish a VoLTE call.

To do so the VoLTE application on the handset will communicate (via SIP, over the established default LTE bearer) with the IMS network and its embedded VoLTE application server. First a SIP signaling bearer needs to be established after policy for that bearer is applied. To apply the policy, the IMS’s P-CSCF needs to communicate via the Diameter Rx interface with a PCRF server. Actually, it needs to communicate with the same PCRF server that was already involved in managing the related LTE default bearer.

This is exactly where the added-value of a DRA’s session binding functionality becomes necessary, because the DRA has to search its memory for the same PCRF server that was used in the Gx session for that specific customer (e.g. specific IMSI and session ID). It has to match the unique and related information in the Rx signaling in order to make the same routing decision and end up at the same PCRF server.

The relevant IMS information is the Framed-IP address because IMSIs are not usually required in IMS. A smart DRA has stored in its memory the association between an IMSI and Session-ID plus the Framed-IP address used by the device. If now that same Framed-IP address shows up in an IMS Diameter Rx message, a match can be made and the same routing decision can be applied.

Now once the Diameter Gx for the LTE part and the Diameter Rx for the IMS part are bound to the same PCRF server we are almost there. Next comes the exchange and application of the policy and charging rules for the SIP Signaling bearer.

And now we can move to the third key component of the VoLTE call and that is the SIP signaled voice. For voice signaling, the same PCRF server needs to be addressed, and the related IMS signaling is again exchanged via the Diameter Rx interface. Finally, once the policies and charging have been exchanged and applied, the VoLTE call can be made successfully.

If there is a need for changing the policy or charging rules (for instance, if a customer reaches a certain threshold), than the same PCRF server can communicate via Gx to the LTE’s PCEFs and via Rx to the involved IMS elements like the P-CSCF. In this way, the various sessions that are related to the same VoLTE service are managed consistently. Also when the VoLTE call is terminated the various sessions need to be released, except for the LTE default bearer, and the correlation between the LTE and IMS part of this VoLTE call can be cancelled.

Stay tuned to read about more added value of a DRA in a VoLTE deployment in Part II.



Peter Nas serves as Senior Solution Architect at F5 Networks and draws from more than 20 years of telecom experience to advise operators how to leverage Diameter signaling solutions to enable the optimal LTE experience. Peter joined F5 with the company’s acquisition of Traffix where he was responsible for global business development.  Prior to joining Traffix, he worked at Tekelec focusing on market development for Diameter and SIP routing. In his days before Tekelec, he served as Core Network Engineering Manager at a prominent mobile operator in the Netherlands. 

Comments on: "Why do you need a Diameter Routing Agent in a VoLTE deployment? (Part I)" (2)

  1. Hello Peter. Thank you for the detialed explanation.
    Can you shed some light on the way PCRF decides about policies?
    Are all policies defined per-subscriber, or are some policies defined per bearer (e.g. default bearer, regardless of who the subscriber is)
    Does the PCRFcollect the subscriber-related policies from the subscriber’s HSS record? Can you give 2-3 examples for policies?


    • peter@f5 said:

      Hi Shlomo, thanks for your question.
      I would say that PCRFs are very suitable to have a combination of general policies and subscriber-specific policies, all depending on how an operator wants to use it (assuming he deployed PCRFs that have great flexibility, and there are plenty of them).
      For instance you could have a default policy for a bearer, access-type (RAT is 3G, 4G, etc.), location, etc. and on top of that have subscriber specific treatment depending on the HSS profile (eg the services and options the subscriber has registered) but also depending on his quota or other variables. For instance we observe that OTT players could have registered a certain subscriber as a premium user of their OTT video service (or any other service) and this specific subscriber needs to get highest QoS and modified charging type when he/she wants to download/interact with a video/service from that specific OTT player. You can imagine that if you are a VoLTE subscriber you want to be able to enjoy high quality voice but also if that same customer, during the VoLTE call, is requsting another (IMS based) service you might want to assign a dedicated bearer for that specific service and/or manage the QoS if the bearer is shared (PCRF’s role)
      All of that is mixture of PCRF profiles combined with network state, type of access used, type of device used, roaming or not, what status with an OTT player, etc. So all together a lot of information (network related but also subscriber specific) that DRAs can manage to be exchanged AND make sure it ends up with the right PCRF that is assigned to this customer (for this session).

      Last but not least: I believe more and more operators start to use PCRFs to be able to differentiate themselves from competition (and not ‘just’ for cost reduction). Making sure the PCRF gets the right information but also getting it back to the PCEF to apply the policies… that’s all signaling (mostly Diameter but not limited to that… so a DRA with gateway functionalities as well is THE enabler).

      Hope this answers your question?

      Greetings, Peter

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Tag Cloud

%d bloggers like this: