Leonardo Zanoni Pedrini
Telecom Consultant at Telefônica Brasil (Telefônica | Vivo)

All Articles by Leonardo Zanoni Pedrini

3. VoLTE – Voice over LTE

Everything we have seen so far is based on the making of voice call in the legacy network. But as we have seen these are 'temporary' solutions until the 'final' solution - VoLTE - is available.

And the final LTE voice solution (Voice over IP, or more specifically VoLTE) uses the IMS backbone. An example of network topology supporting VoLTE is shown in the following figure.

To make voice calls, LTE networks need to have an IMS. When the first LTE networks appeared, they had no IMS, and without IMS, it was not possible to make any calls to any PSTN or CS.

We have spoken of the IMS before, but let's remember.

3.1. IMS – IP Multimedia Subsystem

IMS is a backbone (network) at the application level, which works on top of other wireless networks and not just the LTE (as 3G, 2G, Wi-Fi and others).

Its concept is quite broad, and to understand it with all its entities, possibilities, interfaces, protocols, and possibilities is an extremely difficult task, even for the most experienced in the subject.

The IMS is not new: it already existed before the LTE (as well as other entities, such as the EPC PRCF, which also is not new!).

Its complete specification consists of thousands and thousands of 3GPP standards. But let's try to understand in a simpler way than that found there.

As its name suggests (IP Multimedia Services), IMS offers several multimedia IP services, including VoIP (Voice over IP). In IMS, voice is just 'another' service!

IMS brings together voice features such as authentication, service authorization, call control, routing, and interoperability with PSTN, billing, additional services and VAS.

None of these exist in the EPC: this is the reason why the pure EPC without IMS cannot process a voice call.

In other words, for VoLTE, access is made by the SAE (eUTRAN + EPC), while voice service lies in the IMS.

An analogy we can do is to consider the IMS being a car. And the LTE voice, as our shuttle service (to go from one place to another).

• We can buy a very basic car - Basic 1.0 engine, wheels, steering wheel and other minimum parts: yes, we can go from one place to another.

• Or we can buy a 'connected' car - ultra modern, powerful, tetra-fuel, with all the safety features, ABS, Air bag, connected to the Internet, etc. we also go from one place to another ... but we can make several other things as well!

That's more or less what happens with the IMS. It is used in conjunction with the LTE network to support voice: both full IMS implementation and also the minimum IMS suggested implementation for Voice over LTE.

But the telecommunications industry would rather not invest in a full IMS, or at least did not have sufficient reason to do it immediately. And for the adoption of the simpler IMS voice solution, appear the VoLTE initiative, which specifies a minimum set of features, and selects a simple choice when multiple options exist for certain features.

However, not all of these features are required for delivery of basic voice services by the LTE network.

So let's illustrate with a diagram (extremely simple) the implementation of a voice in IMS (VoLTE).

• Let's assume that we will make a VoLTE call with a CS network whatsoever, for example the PSTN (Public Switch Telephony Network).

• And consider in the IMS only two simple elements, one for the control plane (with signaling) and one for the user plane (with voice).

• And the entry being the SAE, or LTE network.

• In IMS, the control element would be a SIP server (soon we will talk about SIP - for now just understand that when we have a call request to this server, it sets up the call.); and the user element would be a Media Gateway.

In comparison with the legacy networks, the SIP Server is equivalent to the MSC in the mobile network topology and the media gateway is equivalent to a typical Media Gateway on any network topology, which is common in virtually any voice network to handle calls.

The above concept is valid, but in practice the IMS consists of much more entities, as seen below.

Note: Not all possible/existing entities and interfaces

are shown in the figure.

Let's quickly see a little about these key elements.

Note: Do not worry or try to understand everything now about these elements.

Remember that our goal here is not that.

Anyway, it's worth a read.

The MGCF (Media Gateway Controller Function) is the control element that communicates with other PSTN networks. It is significant because it has to inter-networking function: can speak SIP, can speak ISUP, and can speak other signaling protocols.

The IM-MGW (IM Media Gateway) is the element that takes care of voice functions for example making protocol translation required to support the call. More specifically between the Real Time Transport Protocol (RTP) to analog format or basic PCM in the CS network and vice versa.

The HSS (Home Subscriber Server) is an element that also exists in the LTE EPC (although appeared first in IMS), and its functions are similar.

The MRF (Media Resource Function) provides many services related to voice, such as conferences, announcements, voice recognition and so on. It is always divided into two parts, the MRFP (Media Resource Function Processor), for media streams, and the MRFC (Media Resource Function Controller) that functions basically as an RTP 'mixer'.

An important concept, and that's worth stand out here is the Proxy, for example to make filters, identify where the users come from, the cases of roaming, etc. Remember that we are talking about an IP network. Instead of the users to speak directly with the SIP server, they use the proxy.

The CSCF (Call Session Control Function) has some variations.

• Proxy-CSCF (P-CSCF) among other tasks provides QoS information related to the LTE network. Access an AF to voice service, and provides the control functions 'policy' and 'charging' to the PCRF.

• Interrogator-CSCF (I-CSCF) is an interrogator and the

• Serving-CSCF (S-CSCF): the CSCF server acts as a central node.

The BGCF (Border Gateway Control Function) functions as a routing table and acts to help the S-CSCF. It has basically routing decisions.

As we speak, the IMS voice is a 'service' - the IMS is a services 'facilitator'. The IMS services are provided through AS (Application Servers).

One such application is the voice. And there are also video services, conference, etc.

In fact, sometimes the AS are not considered as part of IMS (when we understand the IMS as a CORE).

And in IMS, the standard AS for voice is the MMTel (Multimedia Telephony Service), sometimes called MTAS (Multimedia Telephony Application Server).

The SBC (Session Border Controller) is an element of the edges of the IMS to control signaling and often the media streams involved in calls.

The S-CSCF will be responsible for call routing depending on where the other user (the other party) are:

• A SBG (Session Border Gateway) if the other party is in IP domain;

• A MGC/MGW if the other party is in the CS domain (PSTN/PLMN).

IBCF and TrGW are not shown in our figure, but are respectively the control and user plane for other IMS networks, other SIP networks in general. They are similar to the MGCF/IM-MGW - the requirements for reaching one or another type of network are different, so also have separate parts for performing the same functions but with different networks.

3.2. SIP – Session Initiation Protocol

To support telephone signaling between the LTE network and telephone networks, the IMS uses SIP (Session Initiation Protocol). SIP is a standard protocol for establishing voice calls over IP networks.

The code is open, and uses the 'request-response' model to allow communication sessions.

There is a set of standard commands that can be used to initiate, manage and terminate calls between two SIP devices.

The SIP has been adopted by IMS standardization as the protocol to allow signaling between telephone networks and VoIP networks.

SIP is text-based and was developed - in the 90s - in order to be simple and efficient, just like the HTTP protocol (in fact, was inspired by HTTP and other protocols such as SMTP).

A good analogy is to compare the SIP with HTTP.

You probably can understand well the HTTP interaction principle, which allows audio connection, text, video and other elements on a web page. With SIP is pretty much the same thing: it allows the establishment, management and calls endings (or sessions) for IP multi-users without knowing the content of the call. A session can be a simple telephone call between two users, or a multi-user multimedia conference.

Both (SIP and HTTP) take the control of the application to the end user, regardless of the transport protocol (SIP is a control protocol in the application layer), so there is no need for switching centers/servers.

The SIP however is not a resource reservation protocol, and has nothing to do with QoS.

To try to understand it better, let's see a simplified example for a voice call establishment process using IMS platform and SIP signaling.

• Initially, the UE sends a SIP message like 'Invite', containing the description of one or more measures for the voice session (Initial SDP - Session Description Protocol - Offer).

• Then the P-CSCF forwards this same message to the S-CSCF (which has been identified during the registration process).

• All going well, the termination network will have sent a message of type 'offer response' to the S-CSCF, and this sends this message to the P-CSCF, authorizing the allocation of the resources necessary for this session.

• Finally, the P-CSCF forwards the 'offer response' message back to the UE, which confirms the receipt of the 'offer response' message and the resource reservation is started.

This is a very simplified example of how you can be getting (origination) of a voice service by the UE, via IMS.

Several other diagrams exist, with far more complex scenarios, but the basic idea can be seen above, and extended if necessary.

Now seeing the case where an initially established call on IMS has to be 'transferred'.