VoLTE in IMS

Posted on March 6, 2015 by realtimecommunication.info

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

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:[email protected]
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!

VOLTE
ARCHITECTURE

VOLTE: VOICE OVER LTE

VoIP call support over an LTE network requires IMS support. When a UE
with an active VoIP call leaves LTE coverage to an area with only 1xRTT
coverage, the call can be seamlessly handed over from the LTE-IMS to the
1xRTT CS domain. Call continuity from IMS to the CS domain is maintained
with the help of Single Radio Voice Call Continuity (SRVCC) anchoring.
EUTRAN: Evolved UMTS Terrestrial Radio Access GERAN: GSM/EDGE Radio Acces
Network Network

MME: Mobility Management Entity HSS：Home Subscriber Server

SGSN: Serving GPRS Support Node UE: User Equipment

PCRF：Policy and Charging Rule

UTRAN: Universal Terrestrial Radio Access Network
Function

VoLTE and IMS :

 The IP Multimedia Subsystem (IMS) is an architectural framework for
delivering Internet Protocol (IP) multimedia services.
 IMS uses protocols that enable sending voice, data, and video
between communication devices of IP addressable data networks.
A minimum feature set of IMS is required to support VoIP over LTE
 Includes support for call waiting, conference calling, etc.
 Uses Session Initiation Protocol (SIP) for call setup
 AMR is the default codec
 Supports SMS over IP
VoLTE Architecture
The VoLTE logical architecture is based on the 3GPP defined architecture
and principles for VoLTE UE, Long Term Evolution (LTE), Evolved Packet
Core network (EPC), and the IMS Core Network.

It consists of the following functions:

 VoLTE UE: The VoLTE UE contains

functionality to access the LTE RAN and the
EPC to allow mobile broadband connectivity.
An embedded IMS stack and VoLTE IMS
application are required to access VoLTE
services.
  Radio Access Network. The Evolved Universal
Terrestrial Radio Access Network (E-UTRAN);
this is often referred to as Long Term
Evolution (LTE). LTE radio capabilities for FDD
LTE only, TDD LTE only, or both FDD and TDD
LTE are applicable for VoLTE.
 Core Network. The Evolved Packet Core (EPC).
 IMS Core Network. The IMS Core Network
within the VoLTE architecture provides the
service layer for providing Multimedia
Telephony.
eNodeB Function:
 The EUTRAN consists of a single node, the eNodeB that interfaces
with the UE.
 The eNodeB hosts the Physical (PHY), Medium Access Control
(MAC), Radio Link Control (RLC), and Packet Data Convergence
Protocol (PDCP) layers that include the functionality of user-plane
header-compression and encryption.
 It also offers Radio Resource Control (RRC) functionality
corresponding to the control plane.
 It performs many functions including radio resource management,
admission control, scheduling, enforcement of negotiated UL QoS,
cell information broadcast, ciphering/deciphering of user and control
plane data, and compression/decompression of DL/UL user plane
packet headers.
MME (Mobility Management Entity):
 The Mobility Management Entity (MME) is the key control-node for
the LTE access network.
 It is responsible for idle mode UE tracking and paging procedures
including retransmissions.
 It is involved in the bearer activation/deactivation process and is also
responsible for choosing the SGW for the UE at the initial attach and
 at the time of intra-LTE handover involving Core Network node
relocation.
 It is responsible for authenticating the user (in conjunction with the
HSS).
 The NAS (Non-Access Stratum) signalling terminates at the MME
which is also responsible for the generation and allocation of
temporary identities to
the UEs.
 The MME validates the permission of the UE to camp on the service
provider’s PLMN and enforces UE roaming restrictions.
 The MME is the termination point in the network for
ciphering/integrity protection for NAS signalling and handles security
key management.
 Lawful interception of signalling is also a function provided by the
MME.
 The MME provides the control plane function for mobility between
LTE and 2G/3G access networks and interfaces with the home HSS
for roaming UEs.
SGW (Serving Gateway):
 The SGW routes and forwards user data packets, while also acting
as the mobility anchor for the user plane during inter-eNodeB
handovers and as the anchor for mobility between LTE and other
3GPP technologies (terminating the S4 interface and relaying the
traffic between 2G/3G systems and PGW).
 For idle state UEs, the SGW terminates the DL data path and
triggers paging when the DL data arrives for the UE.
 It manages and stores UE contexts and performs replication of the
user traffic in case of lawful interception.
 The SGW and PGW functions could be realized as a single network
element.
PGW (Packet Data Network Gateway):
 The PGW provides connectivity between the UE and external packet
data networks.
 It provides the entry and exit point of traffic for the UE.
 A UE may have simultaneous connectivity with more than one PGW
for accessing multiple Packet Data Networks.
 The PGW performs policy enforcement, packet filtering for each
user, charging support, lawful interception and packet screening.
  The SGW and PGW functions could be realized as a single network
element.

HSS (Home Subscriber Server):

 The HSS is a network database that holds both static and dynamic
data elements related to subscribers.
 The HSS provides user profile information to the MME and IMS core
during UE attach and IMS registration.
PCRF (Policy Charging and Rules Function):
 The PCRF provides policy control decisions and flow-based charging
controls.
 The PCRF determines how a service data flow shall be treated in the
enforcement function (PGW in this case) and ensure that the user
plane traffic mapping and treatment is in accordance with the user’s
profile.

IMS :

 A default bearer is set up for IMS signaling streams when the UE

attaches to the network.
 After the UE initiates a call, SIP signaling streams for call connection
is transmitted over the default bearer through the P-GW to the IMS
Core.
  A dedicated bearer for IMS voice media streams is set up during call
connection.
 Voice media streams of the calling and called parties are transmitted
over the dedicated bearer
IMS is the control infrastructure for
supporting next-generation IP Multimedia
Services and consists of many separate
elements.
P-CSCF (Proxy Call Session Control Function):
 The P-CSCF is the initial point of contact for session signalling for
the IMS-enabled VoLTE UE.
 The P-CSCF behaves as a SIP proxy by forwarding SIP messages
between the UE and the IMS Core Network, maintains the security
associations between itself and the VoLTE UE, and incorporates the
Application Function aspect of PCC to enable binding of the IMS
session with the bearer for applying dynamic policy and receiving
notifications of bearer level events.
 The P-CSCF may be implemented in an Access Session Border
Controller which may also incorporate the IMS-ALG/IMS-AGW.
I-CSCF (Interrogating Call Session Control
Function):
 The I-CSCF is the contact point within an operator’s network for all
connections destined to a user of that network.
 On IMS registration, it interrogates the HSS to determine which
suitable S-CSCF to route the request for registration.
 For mobile terminating calls, it interrogates the HSS to determine
which S-CSCF the user is registered on.
S-CSCF (Serving Call Session Control
Function):
 The S-CSCF provides session set-up, session tear-down, session
control and routing functions.
  It generates records for billing purposes for all sessions under its
control, and invokes Application Servers based on IFCs received
from the HSS.
 The S-CSCF acts as SIP registrar for VoLTE UEs that the HSS and I-
CSCF assign to it.
 It queries the HSS for the applicable subscriber profiles and handles
calls involving these end points once they have been registered.
Telephony Application Server (TAS):
 The TAS is an IMS Application Server providing support for a
minimum set of mandatory MultiMedia Telephony (MMTel) services
as defined by 3GPP e.g. supplementary service functionality, and
profiled within GSMA PRD IR.92
MRF (Media Resource Function)
 The MRF is a common media resource function, for use by IMS
Application Servers and I/SCSCFs, to provide media plane
processing independent of application types,
IBCF/TrGW (Interconnection Border Control
Function/Transition Gateway)
 The IBCF/TrGW is responsible for the control/media plane at the
network interconnect point to other PMNs.
 The IBCF/TrGW may be implemented in an Interconnect Session
Border Controller.
BGCF (Breakout Gateway Control Function
 The BGCF is responsible for determining the next hop for routing of
SIP messages.
 This determination is based on information received within the
SIP/SDP and routing configuration data (which can be internal
configuration data or ENUM/DNS lookup).
 For CS Domain terminations, the BGCF determines the network in
which CS domain breakout is to occur and selects the appropriate
MGCF.
 For terminations in peer IMS networks, the BGCF selects the
appropriate IBCF to handle the interconnect to the peer IMS domain.
 The BGCF may also provide directives to the MGCF/IBCF on which
Interconnect or next network to select.
  Such directives may be given by the inclusion of a routeing header
pointing to the next network ingress node.


Difference between CSFB and VoLTE UE call

procedure :
CSFB UE ‐ LTE access selected :
 Detect available network
 Attach to the EPC and CS network over LTE
 Setup Internet APN and do some browsing
 Paging/call preparation between UE and MSC over LTE
 Place a call/receive a call
VoLTE UE ‐ LTE access selected:
 Detect available network
 Attach to the LTE network
 Setup IMS APN and find P‐CSCF(s)
 Register in IMS
 Place a call/receive a call (keeping current LTE access)