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 flows.

Voice over LTE service specified in GSMA IR.92. If you think it seriously with VoLTE, don’t waste your time on any blog and read the VoLTE Service Description and Implementation Guide. On the other hand real beginners can try our VoLTE Illustrated: Beginners Guide.

The very basic architecture of IMS for VoLTE can look like this:

VoLTE network architecture – simplified

During the LTE attach procedure VoLTE client receives IP address of P-CSCF.

• P-CSCF (Proxy Call Session Control Function)
  • An entry point for IMS signalling. It is directly connected to the VoLTE device (UE) over SIP protocol.
  • P-CSCF maintains the security associations between itself and the UE.

The P-CSCF is usually a part of A-SBC.

• A-SBC (Access Session Border Controller)
  • Provides connectivity for two or more IP networks, including IPv4 and IPv6 interworking, NAT traversal, etc.
  • Implements Security features, e.g. DoS, DDoS attack prevention, Topology Hiding, Encryption, CAC, ..
  • Communicates with access network (e.g. LTE) and is responsible for QoS
  • Handles Media Services, provides transcoding if needed

For the end-2-end signalling (voice call setup) we use SIP protocol. The multimedia then goes out-of-band using RTP protocol.

The heart of IMS network is IMS Core. It consists of often collocated I/S-CSCF, which cares about authentication, session routing and management.

• I-CSCF (Interrogating Call Session Control Function)
  • I-CSCF provides a Location service. That means that for each subscriber (or public service) I-CSCF is able to locate the right S-CSCF.
  • I-CSCF also represents IMS network to peers. E.g. for peer networks the I-CSCF is the first point of contact.
• S-CSCF (Serving Call Session Control Function) 
  • The S-CSCF is responsible for basic IMS services.  It is a SIP server providing session set-up, session tear-down, session control and routing functions.
  • S-CSCF acts as SIP Registrar – stores the binding between Public User Identity (e.g. sip uri or tel uri) and its actual point of presence (Contact IP address) and maintains user registration status. During VoLTE registration procedure S-CSCF performs user authentication.
  • 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.

• Telephony Application Server (TAS) 
  • The application server responsible for all the services as address normalization, call diverting, call forwarding, barring, etc.
  • 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.

I-CSCF will locate the S-CSCF which handles the context for the recipient. S-CSCF triggers T-TAS for terminating services (e.g. Incoming Call Barring, Call Forwading, etc.)

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).

VoLTE Flow on one site

SIP routing of VoLTE call in IMS is in more details discussed in SIP Illustrated 5: SIP Session Routing.

In order to establish the media path the body of the SIP INVITE and other signaling messages carries Session Description Protocol (SDP) data.

v=0
o=volte-0-349-1 0346136471fad35443 1660635443 IN IP4 223.112.161.118
s=SS VOIP
i=A VoLTE Session
c=IN IP4 223.112.161.118
t=0 0
m=audio 23448 RTP/AVP 116 118 111 110 8 0
a=msi:xyz@223.112.161.118
a=rtpmap:116 AMR-WB/16000
a=fmtp:116 mode-change-capability=2;max-red=220
a=rtpmap:118 AMR/8000
a=fmtp:118 mode-change-capability=2;max-red=220
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000

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.

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, …)

VoLTE architecture for multiple sites.

Now we know the very basic LTE-LTE flow. More detail information about VoLTE are described in VoLTE flows – close encounters.

SIP headers and routing is then explained in SIP Illustrated: SIP by sip.

Basic VoLTE validation procedures are described at Validating VoLTE document.

Other posts related to VoLTE:

• IMS from 10.000 feet
• SIP Illustrated: SIP by sip
• VoLTE Flows – Basics – presentation
• VoLTE Flows and CS Network – presentation
• VoLTE Illustrated: Beginners Guide
• Multimedia in VoLTE
• At your service..

• IP-SM-GW Transport Level Interworking
• Ut interface – what is it for?

• VoLTE Policy Control Summary
• P-Early-Media – You are running low on credit!
• It is about quality!
• Mind the coverage hole!