VoLTE in IMS

The year 2015 is definitely a year of VoLTE. VoLTE is everywhere and operators are rolling out as crazy. There are plenty of articles describing how the LTE or LTE-A do work. We’ll put the LTE Packet Core part aside and take a look on the IMS related VoLTE architecture and VoLTE call flows.

S-CSCF also invokes Application Servers (TAS, IPSMGW) based on rules (IFCs) received from the HSS.

The IMS Core however doesn’t know anything about Voice or SMS service. That is a task for Application servers. The Application Server for voice and video telephony is called TAS – Telephony Application Server or MMTel AS – Multimedia Telephony AS.

In a nutshell TAS is what makes the VoLTE enhancements on top of the pure VoIP.

VoLTE specification also defines SMS interworking. To support SMS over SIP we have a dedicated Application Server called IPSMGW. In more detail it is described in IPSMGW – Transport Level Interworking post.

IMS Core and Application Servers don’t have any persistent storage. All the information about subscribers and their services is stored in HSS (Home Subscriber Server). The communication between HSS and I/S-CSCF or TAS makes use of Diameter protocol.

Other IMS elements are:

MRF – Media Resource Function

Can be used as a media mixer or as a media server for playing of tones and announcements.

MGCF – Media Gateway Control Function

MGCF is used for the breakout to and from CS network. Usually the MGCF and MGW – Media GW is a part of enhanced MSC.

BGCF – Breakout Gateway Control Function

BGCF might be used in case when S-CSCF is not able to find the routing based on ENUM/DNS (e.g. PSTN number). Usually it is a part of IMS Core (along with S-CSCF and I-CSCF).

The IMS definition is very broad and flexible. GSMA VoLTE standard restricts it and defines what services are mandatory and how we should implement them. E.g. it defines how to implement Emergency Services, SRVCC, Roaming, SMS interworking, etc. In our post we will go through the basic LTE to LTE callflow.

IMS Network for T1 Operators

VoLTE Call Flow

We said that S-CSCF is a heart of the IMS. The TAS (MMTel) is the brain. There are always at least two telephony application servers and two S-CSCFs involved on a path from originator to recipient. One which applies originating and one which applies terminating services.

VoLTE Call-Flow

What particular services will be applied is driven by the configuration of a TAS/MMTel and by subscriber and non-subscriber data which is stored in HSS.

Before a subscriber can place or receive any call, he has to register himself in the IMS network. We went through the registration in several posts (Registration, How to read tcpdump – Registration). Once the user is successfully registered, the S-CSCF is able to route the incoming calls to the user. This S-CSCF also knows which TAS did the 3rd party registration and maintains a binding between the IMPU (public user identity) and the TAS. This information is a part of the user’s context.

When a subscriber (Johan) wants to initiate a new call he sends a SIP INVITE message to the recipient (Rory). The basic flow looks like this:

VoLTE SIP signalling

VoLTE subscribers use SIP protocol in order to negotiate the parameters of a multimedia (RTP) session. The SIP signalling also allows the IMS network to secure sufficient resources for the requested Quality of Service.

In IMS the SIP INVITE message is firstly sent to P-CSCF which was assigned to the user during the registration. The P-CSCF has a binding with the S-CSCF which is responsible for the originator.

The S-CSCF routes the SIP INVITE to the O-TAS which applies originating services (e.g. Outgoing Call Barring, triggering of playing announcements, Conferencing, etc.) and can modify the recipient’s address (based on translation rules, ENUM response, CAMEL triggering, etc.) Remember that TAS acts as a B2BUA and can change any SIP header including the Call-ID.

From O-TAS the SIP INVITE is sent back to the S-CSCF of the originator. The S-CSCF finds a routing to the network of the recipient (e.g. with help of DNS or ENUM). In our case (recipient is registered in IMS) S-CSCF forwards the message to I-CSCF in the terminating network.

Finally the T-TAS forwards the SIP INVITE to the S-CSCF of the recipient. The S-CSCF knows which P-CSCF maintains a dialog with the recipient.

When the recipient receives the SIP INVITE he will respond and the response backtracks all the way to the originator.

VoLTE Call Flow (LTE-LTE Call)

Please note, so far we have been talking about logical flow. Physically the O-TAS and T-TAS can be just one server (e.g. originator and recipient are both registered on the same S-CSCF, using the same A-SBC).

Via SDP the originator and recipient exchange IP addresses (223.112.161.118) and ports (23448) for the media stream (RTP) and sets of supported codecs (AMR-WB, AMR, DTFM – telephone-event,..). There are many more parameters, for now it is important that once originator and recipient know the IP:Port and codecs to be used, they can start to communicate over the RTP protocol.

SDP Exchange

Later when one of the call parties wants to close the RTP stream (hang-up), the client sends a SIP BYE message. After the 200 OK response the session is finished.

VoLTE Network Architecture

Maybe you ask why is the signalling so complex? That is because the IMS is very general. E.g. in case of roaming this simple scenario can go across four different IMS networks:

VoLTE Call with Roaming

Although currently nearly no operators support IMS-based roaming and mostly they are not connected to any other IMS networks at all, still the network architecture can be quite complicated. Operators have multiple sites and there can be several different types of sites (E.g. Access site, Core IMS site, Maintenance Site, Failover Site, RCS Site, …)