VoLTE End To End Architecture (MPI0124-000-010)

Innovating Telecoms Training
VoLTE End to End Architecture
Reference Document
www.mpirical.com
Reference Document
MPI0124-000-010 © Mpirical Limited, 2020 i

Mpirical classes have been developed in accordance with the technical specifications
published by the 3GPP. As such the 3GPP have granted Mpirical Limited the right to use the
3GPP logo to identify specifications, compliant products and services.
First published by Mpirical Limited in 2017

© Mpirical Limited, 2020
All rights reserved. No part of this book or accompanying software may be reproduced or
transmitted in any form by any means, electronic, mechanical, photocopying, recording, or
otherwise without the prior written consent of the publisher. Although every precaution has
been taken in the preparation of this book the publisher assumes no responsibility for errors
and omissions. Nor is any liability assumed for damages resulting from the use of the
information contained within.
ii © Mpirical Limited, 2020 MPI0124-000-010

Contents
Test Deploying VoLTE ........................................................................................... 7

1.1 VoLTE High Level Network Architecture ....................................................... 8
1.2 VoLTE Standardization.................................................................................. 9
LTE Access Network ........................................................................................... 10
IMS Call Control Network .................................................................................... 12
3.1 IMS Requirements ...................................................................................... 12
3.2 IMS Architecture .......................................................................................... 13
3.3 Call Session Control Functions ................................................................... 15
3.4 Additional IMS Network Elements ............................................................... 17
3.5 IMS Deployment Options ............................................................................ 21
PCC Architecture ................................................................................................. 24
4.1 PCC Network Nodes ................................................................................... 25
End to End VoLTE Architecture ........................................................................... 26
Glossary ............................................................................................ 29
MPI0124-000-010 © Mpirical Limited, 2020 iii

iv © Mpirical Limited, 2020 MPI0124-000-010

Figures
Figure 1 LTE and VoLTE Deployments ......................................................................... 7

Figure 2 Global Distribution of VoLTE (GSMA) ............................................................. 7
Figure 3 IMS Call Control .............................................................................................. 8
Figure 4 VoLTE High Level Network Architecture ......................................................... 8
Figure 5 VoLTE Standardization (GSMA IR.92) .......................................................... 10
Figure 6 LTE Network Architecture.............................................................................. 11
Figure 7 Interfaces and Associated Protocols ............................................................. 11

Figure 8 IMS Call Control Network .............................................................................. 12
Figure 9 IMS Requirements ........................................................................................ 12
Figure 10 IMS Network Architecture............................................................................ 13

Figure 11 IMS Control Plane Protocols ....................................................................... 14
Figure 12 User Plane Protocols .................................................................................. 14
Figure 13 P-CSCF Responsibilities ............................................................................. 15

Figure 14 I-CSCF Responsibilities .............................................................................. 16
Figure 15 S-CSCF Responsibilities ............................................................................. 16
Figure 16 Media Path Using ATGws ........................................................................... 17

Figure 17 Home Subscriber Server ............................................................................. 18
Figure 18 VoLTE Application Servers .......................................................................... 18
Figure 19 SBC Key Functions ..................................................................................... 19

Figure 20 SBC Deployment Scenarios ....................................................................... 21
Figure 21 SBC Logical Roles ...................................................................................... 21
Figure 22 IMS Implementation Options ....................................................................... 22
Figure 23 Application Services Centralization ............................................................. 22
Figure 24 Hub and Spoke Deployment ....................................................................... 23
Figure 25 3rd Party Hosted .......................................................................................... 23
Figure 26 VoLTE in a Box ............................................................................................ 23
Figure 27 IMS in a Box ................................................................................................ 24
Figure 28 Edge Controlled IMS ................................................................................... 24

Figure 29 PCC Architecture......................................................................................... 25
Figure 30 End to End VoLTE Architecture ................................................................... 27
MPI0124-000-010 © Mpirical Limited, 2020 v

vi © Mpirical Limited, 2020 MPI0124-000-010

Test Deploying VoLTE

Although the first LTE network was deployed in 2009, it was three years later
in 2012 that the first VoLTE network was commercially launched (by SK
Telecom). Since then, LTE has been deployed on a worldwide basis, with over
600 service providers now operating a 4G LTE network (this figure will
eventually reach close to 800). As more and more service providers migrate
their voice services to IP based VoLTE, the number of global VoLTE
deployments continues to increase steadily (see Figure 1). In June 2015, the
South Korean government announced that its three main operators had
launched a fully interconnected VoLTE service.
Number of global commercial deployments
800 LTE
700
600
500
400
VoLTE
300
200
100
5G
0
2009 2010 2011 2012 2013 2014 2015 2016 2017 2019 2019 2020
Figure 1 LTE and VoLTE Deployments
Figure 2 is a map taken from the GSMA (GSM Association) which highlights
the global distribution of VoLTE (as of mid 2017). Note also that although
South Korea was the first country to support VoLTE interconnect between
service providers, other countries have now followed suit.
Figure 2 Global Distribution of VoLTE (GSMA)
MPI0124-000-010 © Mpirical Limited, 2020 7

Despite the global success of LTE, it is important to remember that the service
control framework behind VoLTE, namely the IMS (IP Multimedia Subsystem),
is not limited to using LTE as the signalling and
media transport network; already, numerous
providers are deploying voice services over Wi-
Fi using the same IMS call control network as
their VoLTE service. Moreover, as 5G begins to
be commercially available, the same IMS call
control network can potentially utilize the IP
based 5G access network.
Figure 3 IMS Call Control
1.1 VoLTE High Level Network Architecture

Part of the reason for many service providers delaying the deployment of
VoLTE can be attributed to the potential cost and complexity associated with
the service. Figure 4 outlines the high level architectural requirements.
Figure 4 VoLTE High Level Network Architecture
LTE Access Network

The LTE access network performs the role of packet
transport, ensuring that the call signalling associated with
setting up the call and then the subsequent voice packets
are handled appropriately. It is important to remember that
signalling and voice are two different traffic types:
 Call signalling is in the form of SIP (Session Initiation
Protocol). A series of SIP messages will be
exchanged on an end to end basis in order to
establish and subsequently tear down the call. It is
important from both a user experience and billing
perspective that these messages are not delayed
and are not dropped.
8 © Mpirical Limited, 2020 MPI0124-000-010

 Voice packets are in the form of RTP (Real time Transport Protocol).
Minimizing delay for voice packets is essential, however it is possible
to drop packets without degrading the call (as long as it is not a
consecutive group of packets). This is due to the fact that an individual
voice packet carries a very small sample (typically 20ms) of actual
voice.
IP Multimedia Subsystem
The IMS provides call control services, in that when a VoLTE subscriber
wishes to make a call, they will send SIP signalling towards the IMS. The IMS
will process this SIP signalling and ultimately ensure the call gets set up
towards the correct recipient.
 If the call is from a VoLTE user to a VoLTE user, all of the call control
will be handled by the IMS and call control signalling will be SIP on an
end to end basis.
 If the call is from a VoLTE user to a subscriber on legacy voice,
including emergency services support, the IMS will interact with the
legacy voice network, which may involve converting the SIP signalling
into a different call control protocol appropriate to the legacy network.
Before using the VoLTE service, the IMS must also handle the subscriber’s
registration process.
Policy and Charging Control
PCC (Policy and Charging Control) acts as the gateway between the SIP
based session signalling related to the IMS, and the LTE based signalling
which is used to establish bearers.
In order to make or receive a call, SIP signalling must be sent to the IMS via
the LTE network using the Default bearer. In turn, a Dedicated Bearer must
then be established to support the voice packets. The problem is that the LTE
network does not read the SIP signalling; from the perspective of LTE, SIP is
just user data that the LTE network will dutifully transport from the mobile to
the IMS. Therefore, the IMS will take session level information from the SIP
signalling and supply it to the PCC architecture. In turn, PCC will use this
information to ensure the correct resources are established in the LTE
network in order to support the call.
1.2 VoLTE Standardization

VoLTE as a standard1 was introduced by the GSMA as “IMS Profile for Voice
and SMS” (in which the term “VoLTE” is actually used
very infrequently). The standard itself is a framework
document which defines how an IMS based telephony
service can be supported over an LTE based RAN.
The document defines a profile which identifies a
minimum mandatory set of features that the mobile
and the network must support. All of the features
mandated are defined in various 3GPP or IETF
(Internet Engineering Task Force) specifications (over
seventy 3GPP specifications are referenced in the
IR.92 specification). At a high level, the features covered include (outlined in
Figure 5):
 IMS based capabilities and supplementary services for telephony.
1
GSMA IR.92 – IMS Profile for Voice and SMS

 Real time media negotiation, transport and codecs.

 LTE radio and EPC capabilities.
 Functionality that is relevant across the protocol stack and subsystems.
Protocol
Media
IMS Aspects LTE Aspects Stacks and
Aspects
Subsystems
GSMA IR92 – IMS Profile for Voice and SMS
User to
Interconnect
Network Roaming NNI
NNI
Interface
Figure 5 VoLTE Standardization (GSMA IR.92)
Consequently, the VoLTE specifications are focused on 3 main areas:

 UNI (User to Network Interface) - found between the subscriber device
and the service provider’s network.
 R-NNI (Roaming - Network to Network Interface) - used when the
subscriber is not connected to their home network.
 I-NNI (Interconnect - Network to Network Interface) - used between the
networks of two parties making a call.
A complete list of all the 3GPP/IETF specifications used to support VoLTE is provided in GSMA
IR.92.
LTE Access Network

The network elements which feature as part of a typical LTE deployment are
outlined in Figure 6. These elements include:
 UE (User Equipment) - responsible for interacting with the E-UTRAN
(Evolved - Universal Terrestrial Radio Access Network) and EPC
(Evolved Packet Core) via the LTE Air Interface. The UE must support
a number of features in order to be classed as VoLTE compliant. These
features include an IMS compatible SIP client, support for the AMR
(Adaptive Multi Rate) codec, support for ROHC (Robust Header
Compression) and support for IMS security procedures.
 eNB (Evolved Node B) - responsible for management of the LTE Air
Interface, including scheduling, security and handovers. For VoLTE, the
eNB must ensure a GBR (Guaranteed Bit Rate) bearer is available
across the air interface in order to provide the correct QoS for the voice
stream.
 S-GW (Serving Gateway) - supports E-UTRAN to EPC connectivity for
user plane traffic such as web browsing or VoLTE calls (as such, the S-
GW is a potential point for lawful intercept of VoLTE calls). As the
subscriber is handed over from one cell to another, user plane
connectivity on the S1-U (between the eNB and the S-GW) must be
switched as part of the handover process.
 PDN-GW (Packet Data Network Gateway) or P-GW - supports EPC to
PDN (Packet Data Network) connectivity (examples of a PDN for
VoLTE would be the IMS). Particularly with respect to VoLTE, the PDN-
GW will often house the PCEF (Policy and Charging Enforcement

Function), which is part of the PCC framework. Hence, bearer
establishment for VoLTE calls and also billing is focused at the PDN-
GW. The PDN-GW is also a potential point for lawful intercept.
 MME (Mobility Management Entity) - this controls and monitors the
mobility of the subscriber down to the granularity of a cell if the mobile
is engaging with the network. If the mobile is Idle, accuracy is down to
a Tracking Area (a group of cells) or a Tracking Area List (a collection of
tracking areas which the mobile is allowed to enter without informing
the network). The MME will also control the subscriber’s attachment
and detachment to/from the network through interaction with HSS and
will also be involved in the establishment of LTE bearers. For
Emergency Services support in VoLTE, the MME is responsible for
acquiring location information from the LTE access network.
 HSS (Home Subscriber Server) - a central repository of subscriber
information. For LTE, the HSS will identify to which APNs (Access Point
Name) the subscriber is allowed to connect eg Internet, IMS, Corporate
VPN, etc. For each APN, the HSS will also hold a QoS profile
determining exactly which level of QoS is permissible for each APN
connection.
Figure 6 LTE Network Architecture
Although the LTE network architecture depicted in Figure 6 would support

VoLTE, the addition of the ePDG (evolved Packet Data Gateway) is included
due to its role in the support of VoWi-Fi (Voice over Wi-Fi) services.
Figure 7 outlines the protocols found on the reference points annotated in
Figure 6.
Figure 7 Interfaces and Associated Protocols

IMS Call Control Network

Despite the fact that the IMS (IP Multimedia Subsystem) was introduced over
fifteen years ago, it has only been in recent years that IMS networks have
begun to be deployed by telecoms service providers (in any significant
numbers). This rise in popularity of IMS can largely be attributed to the roll-out
of VoLTE services, and to a lesser extent GSMA RCS (Rich Communication
Services)2.
HSS
IP Multimedia
Subsystem
IP Access
CSCF
Network
UE PSTN
Figure 8 IMS Call Control Network
IMS is a service management framework; it is essentially an architecture

which facilitates service delivery to a subscriber. In order to request services,
subscriber devices must have IP connectivity, whether this is through LTE
(Long Term Evolution) in the case of VoLTE, or potentially GPRS (General
Packet Radio Service), Wi-Fi, etc. As such, setting up a service eg making a
voice call will see the subscriber’s device sending SIP signalling to the IMS,
which in turn will ensure that the signalling is sent onward to another
subscriber, or perhaps an Application Server of some description eg
Voicemail. This concept is illustrated in Figure 8. One point to note is that all
signalling and resultant services are transported across the IP access
network.
3.1 IMS Requirements

The IMS (IP Multimedia Subsystem) was introduced into mobile networks as
part of Release 5 of the 3GPP specifications, and was subsequently
enhanced through further releases of the specifications. As a subset of the PS
domain, the IMS has some very specific requirements. These are outlined in
Figure 9:
Access
independence
Service while Service based on
roaming capabilities
IP Multimedia
Subsystem
Security, privacy
Negotiable QoS and
authentication
Service to
multiple
terminals
Figure 9 IMS Requirements
2
Rich Communication Suite 6.0 Advanced Communications Services and Client Specification

 Access Independence - access to IMS based services should be

independent of how the terminal obtained an IP connection. This may
be through access such as LTE, Wi-Fi, GPRS, LAN, xDSL etc.
 Roaming - assuming roaming agreements are in place, subscribers
should be able to roam into foreign networks and still be able to
negotiate QoS and receive their service as if they were in their home
network. Service delivery may be provided by the home or serving
network.
 QoS - QoS (Quality of Service) may be negotiated at session
establishment as well as during the session by the service provider and
the user. In the case of VoLTE, QoS should be at least as good as that
achieved by the traditional CS domain.
 Security - IMS services should provide strong security mechanisms
which are comparable with the current security offered by packet and
circuit switched services.
 Terminal Features - multiple terminals should be able to associate with
a single IMS service subscription, therefore aiding the concept of
seamless mobility. This is based on a subscriber’s IMPU (IMS Public
User Identity) being associated with multiple terminals simultaneously.
Likewise, the IMS needs to be able to route sessions towards the
identified subscriber based on the terminal and network’s capability and
also the subscriber preference.
3.2 IMS Architecture

IMS is based on an open architecture; the 3GPP (3rd Generation Partnership
Project) clearly define3 the various network elements of the IMS and how they
interact with one another. The key nodes required in an IMS solution for
VoLTE are outlined in Figure 10.
HSS
TAS
I Cx Cx
S
CSCF CSCF
IS C
Mw
ISC
To P-GW Mw
Mw Mw SCC
SG ATCF
i
P Mw Iq
To PCRF CSCF
ATGw
Rx
To P-GW
Gm C A N Mb
IP-
Figure 10 IMS Network Architecture
Control Plane Protocols

In the IMS the majority of control signalling is based on an established
protocol termed SIP (Session Initiation Protocol), which is standardized by the
IETF (Internet Engineering Task Force). Any time a subscriber initiates a
session, SIP signalling is exchanged between the subscriber device and the
IMS. Depending on the session requested, that SIP signalling may also leave
3
3GPP TS 23.228 - IP Multimedia Subsystem (IMS); Stage 2

the IMS destined for the IMS of a different service provider or alternatively,
towards a compatible SIP network potentially hosted on the Internet.
In addition to SIP, another control plane protocol found in the IMS is Diameter,
which is a AAA protocol found on a number of interfaces in the core network
(as a general rule, HSS interaction and PCC (Policy and Charging Control)
interaction is based on Diameter).
H.248 (also commonly termed MEGACO) is also used as a control protocol in
the IMS but like Diameter, is only encountered on a handful of interfaces; in
Figure 10, the Iq interface is based on H.248.
For service configuration, HTTP (Hypertext Transfer Protocol) is used on the
Ut interface (not shown in Figure 10). The Ut interface is based on XCAP
(XML Configuration Access Protocol), which in turn utilises HTTP.
MSRP (Message Session Relay Protocol) may potentially be encountered in
order to support next generation messaging services.
Finally, DNS (Domain Name System) is a crucial protocol found in any IMS
implementation which supports features such as load balancing across
multiple instances of CSCFs, as well as ENUM (e.164 to SIP URI Mapping).
SIP Establishment and Teardown of VoLTE Calls
HTTP
IMS Services Configuration
(XCAP)
Supporting Authentication , Authorization and

Diameter
Accounting
Instant Messaging MSRP
H.248
Media Gateway Control
(MEGACO)
DNS
SIP address to Telephone Number Mapping
(ENUM)
Figure 11 IMS Control Plane Protocols
User Plane
While SIP will be used as the standardized interface to control service delivery
and service mobility, the application data (eg voice packets in the case of
VoLTE) will be varied. The common factor is the use of IP for transport but
apart from this, the payload of the IP datagram is largely dependent on the
service. For example, VoLTE and ViLTE (Video over LTE) use RTP (Real time
Transport Protocol), whereas an IPTV service could use MPEG (Moving
Picture Experts Group) transport. Messaging services can utilize MSRP and
FTP (File Transfer Protocol) sessions can also be established in order to
transfer files.
RTP MPEG MSRP FTP

(VoLTE and ViLTE ) (IPTV) (Messaging) (File Transfer )
Figure 12 User Plane Protocols

3.3 Call Session Control Functions

The CSCF (Call Session Control Function) is an example of a SIP proxy,
whose primary responsibility is the suitable routing of SIP messages. In the
IMS, several examples of CSCF exist, each with subtly different
responsibilities over and above SIP routing.
Proxy CSCF
Figure 13 P-CSCF Responsibilities
The P-CSCF (Proxy Call Session Control Function) is the first SIP signalling
interface between the UE (User Equipment) and the IMS, regardless of
whether the user is on the home network or roaming. In this role it is
responsible for supporting a mobile subscriber’s requests for services
including:
 Routing - the P-CSCF must route SIP signalling towards the S-CSCF
(Serving - Call Session Control Function) that the user is registered
with. This may be directly or via an I-CSCF (Interrogating Call Session
Control Function), which would be the case in a roaming scenario.
Likewise, any SIP signalling destined to the IMS subscriber must be
forwarded appropriately by the P-CSCF. Although the P-CSCF will not
change the Request URI in the SIP INVITE, it may add information to
the SIP signalling. This includes information associated with the routing
path of the SIP message, the access network used by the subscriber,
billing information and security information.
 Security - the P-CSCF is responsible for establishing two security
associations with the user. These are based on the requirements of
“ipsec-3gpp” with a separate security association being put in place for
both uplink and downlink signalling. In addition, to protect the integrity
of the network, the P-CSCF will append an indication if signalling
messages passed from the user were successfully integrity protected.
 It should be noted that security in the IMS is a service provider
specific choice. It is quite possible that the P-CSCF has no
security role, particularly if SBCs (Session Border Controllers) are
used in the network.
 PCC Interaction - for VoLTE services, the P-CSCF will support the
Diameter based Rx interface in order to supply session related
information (extracted from SIP signalling) to the PCRF (Policy and
Charging Rules Function).
Interrogating CSCF
The I-CSCF (Interrogating Call Session Control Function) handles signalling
arriving at the edge of the home network’s IMS. The I-CSCF can also format

signalling leaving the IMS which is destined for roaming subscribers. The
functions performed by the I-CSCF include:
Figure 14 I-CSCF Responsibilities

 S-CSCF Assignment - the I-CSCF, during the Registration process,
assigns a S-CSCF to the end user. This process is done through
interaction with the HSS during registration.
 S-CSCF Resolution - in order to support session establishment, the I-
CSCF is capable of interrogating the HSS in order to discover the S-
CSCF that has already been assigned to the subscriber in a previous
registration.
 Routing - as the I-CSCF resides at the edge of the IMS it is responsible
for routing inbound signalling from other IMS or SIP networks to the
appropriate S-CSCF in the home network. In addition, the I-CSCF can
also be used to route SIP signalling to roaming users, via the P-CSCF
of the visited network. This concept of border control can also be
carried out by the IBCF (Interconnection Border Control Function).
 Billing - like the P-CSCF, the I-CSCF records billable events, which
may be used in the generation of CDRs (Charging Data Records).
Serving CSCF
The S-CSCF (Serving - Call Session Control Function) controls the session
between the UE and the services that it is accessing. This relates to both
mobile originated and mobile terminated sessions. Moreover, in supporting
the session, the S-CSCF will interact with one or more Application Servers
that will provide the service logic which will ultimately dictate how services are
delivered to the user. Roles of the S-CSCF include:
Figure 15 S-CSCF Responsibilities

 Authentication - the initial Registration message is termed
“unprotected”, as this message starts the Authentication process, and
hence at this point the user is not trusted by the IMS. The
authentication process uses the services of SIP to transport the
authentication parameters between the user and the S-CSCF.

However, the actual algorithms and variables are derived from the
same process used within the UMTS AKA (Authentication and Key
Agreement) process.
 Registration - in terms of the Registration process, the S-CSCF acts as
the SIP Registrar for users who have been assigned to it through the
initial Registration process. Consequently, address bindings between
the user’s address of record and their contact address will be stored in
a database that can be accessed by the S-CSCF. Subsequent
registrations triggered by refresh timers indicated in the Expires field of
the initial registration confirmation message will also terminate at the
S-CSCF.
 Billing and Routing - the S-CSCF is a prime location for the generation
of CDRs, since all SIP signalling associated with a subscriber will pass
through the S-CSCF assigned to them. Likewise, one of the key
functions of the S-CSCF is the routing of SIP signalling to Application
Servers, P-CSCFs or I-CSCFs, depending on the scenario.
3.4 Additional IMS Network Elements

Access Transfer Control Function and Gateway
In order to support SR-VCC (Single Radio - Voice Call Continuity), the IMS
network will contain an ATCF (Access Transfer Control Function) and ATGw
(Access Transfer Gateway). The ATCF lies on the SIP signalling path for
VoLTE call establishment and ensures that media streams being established
as part of a VoLTE call are anchored at the ATGw. This anchoring of the
media stream allows the SR-VCC handover procedure to be optimized,
reducing potential delays in the handover process (due to the fact that when
handing from 4G to 2G/3G access, the media path switch is on a local basis
as opposed to end to end).
The ATGw performs an anchoring function; whilst the subscriber is on 4G,
they will send and receive voice packets to/from the ATGw during a VoLTE
call. The media path for a VoLTE call using ATGws is outlined in Figure 16
(although depending on the scenario, it’s possible only a single ATGw may be
used).
In an operational network, it is likely that the functionality of the ATCF and
ATGw is part of the P-CSCF or an SBC.
ATCF ATCF
ATGw ATGw
Voice Voice Voice
UE “A” Leg “B” Leg UE
Figure 16 Media Path Using ATGws
Note that pre-release 10 networks will not utilise an ATCF or ATGw.
Home Subscriber Server

The HSS is the master database for the IMS, comparable to the HLR (Home
Location Register) but holding IMS subscriber related information. While
logically it is viewed as one entity, in practice it is made up of several physical

databases depending on the number of subscribers and the extent of the

services that need to be supported. In normal operation, the S-CSCF, I-CSCF
and various Application Servers will regularly access the HSS during the IMS
Registration and Service Establishment processes in order to access
subscriber profile information. As a result, the HSS holds variables and
identities for the support, establishment and maintenance of calls and
sessions made by subscribers.
Any interaction with the HSS is achieved through the exchange of Diameter
messages rather than SIP. Diameter is a AAA (Authentication, Authorization
and Accounting) protocol which is the successor to the widely used RADIUS
(Remote Authentication Dial In User Service) AAA protocol.
In the case of the LTE access network for VoLTE, the MME will also
communicate with the HSS however, this will be in support of EPS related
procedures such as Network Attach.
AS
S
CSCF HSS
I
CSCF
Interaction with IMS

entities based on Diameter
Figure 17 Home Subscriber Server
Many service providers have adopted a unified approach to their subscriber

databases, whereby all subscriber information is stored in a centralized
database. This removes the siloed approach for subscriber databases from
the network and hence saves money.
VoLTE Application Servers

For VoLTE, two Application Servers are required; the SCC (Service
Centralization and Continuity) Application Server and the TAS (Telephony
Application Server). The two network elements are routinely collocated in one
physical piece of hardware. Figure 18 shows that in a regular VoLTE to VoLTE
call, the SCC AS and the TAS are invoked for both the Calling Party and
Called Party legs of the call.
MO MT
ICS and Supplementary Supplementary ICS and
SR-VCC Services Services SR-VCC
SCC TAS TAS SCC
IP Multimedia IP Multimedia
Subsystem Subsystem
UE UE
“A” Leg “B” Leg
Figure 18 VoLTE Application Servers

Service Centralization and Continuity Application Server

As part of the VoLTE service, two techniques are frequently deployed by
service providers, each of which are managed through the deployment of an
SCC AS:
 ICS (IMS Centralized Services) - the aim of ICS is to provide consistent
services to the subscriber regardless of the attached access network
type. As such, a subscriber can switch between the CS and PS access,
yet still receive a consistent voice service. To achieve this, all originated
and terminated voice sessions, whether initiated on PS or CS access,
are anchored at the SCC AS (from a signalling perspective). With this
approach, all call control is managed by the IMS.
 SR-VCC - this allow the transfer of an active voice call from 4G access
to 2G/3G access as part of a coordinated handover process facilitated
by the MME and an MSC-S (Mobile Switching Centre - Server) in the
CS core network. The SCC-AS is informed of any handover procedures
in order to continue supporting ICS.
Telephony Application Server
The TAS was introduced as part of the 3GPP MMTel4 specification, which
standardizes how, using the IMS, multimedia conversational communication
can be established between two endpoints. With respect to VoLTE as a
multimedia communication service, the TAS will manage the supplementary
services that are normally associated with a voice service, such as OIR
(Originating Identification Restriction), CDIV (Communication Diversion) and
CB (Communication Barring). Therefore, as part of a VoLTE to VoLTE call
procedure, a TAS will be invoked for the Calling and Called party to ensure
that the correct supplementary services are invoked for each leg of the call.
Session Border Controllers

Real life deployments of VoIP architectures based on the likes of SIP have
revealed a number of shortfalls, ranging from NAT (Network Address
Translation) traversal issues to significant security considerations. For service
providers, these shortfalls are obviously unacceptable but unfortunately,
evolving a standardized protocol to enable it to overcome these issues is a
lengthy process. As a result, for VoLTE networks service providers routinely
deploy SBCs (Session Border Controller) to overcome a variety of problems,
as outlined in Figure 19. A common alternative name for the SBC is SBG
(Session Border Gateway), but the naming convention is often dependent on
the vendor.
Media
Topology Hiding
Management
SBC
Interoperability NAT Traversal
Access Control and

Media Encryption
QoS Enforcement
Figure 19 SBC Key Functions
4
3GPP TS 24.173 - IMS multimedia telephony communication service and supplementary services

The following paragraphs describe in greater detail the various roles a SBC
may be responsible for:
Topology Hiding
Topology hiding is a security function which is applied to signalling traffic
leaving the relative security of the service provider’s network. In essence, SIP
headers can contain a number of fields which can potentially reveal
information about the internal architecture of the service provider’s network,
typically in the form of addressing associated with the subscriber or SIP
proxies in the network. The SBC will remove this addressing information prior
to the SIP signalling being passed to a potentially insecure network. Topology
Hiding is a function of the IBCF (Interconnection Border Control Function) or I-
CSCF within the standard IMS architecture, each of which are logical roles
which the SBC may deployed to conduct.
Media Management
Signalling and resultant media traffic may take different routes through a
network, with media potentially not passing through the service provider’s
network at all. This may be undesirable from a media traffic management
perspective, since the service provider may want to enforce the use of
particular codecs, provide a point for lawful intercept or implement specialized
billing models. As such, media streams can be directed through the SBC to
allow the SBC to provide these media management facilities. This is an
example the SBC adopting the role of an MRF (Multimedia Resource
Function) or ATCF/ATGw.
Interoperability
In terms of signalling and media interoperability between VoIP service
providers, problems can arise for a whole host of reasons. Typically, these
problems are in the form of incompatibility issues such as IPv4 to IPv6
conversion, networks implementing different SIP versions eg IETF vs 3GPP or
even networks employing different signalling protocols altogether eg SIP vs
H.323. The SBC can be used to overcome these interoperability issues.
NAT Traversal
The SIP INVITE is used to establish a VoIP call within a SIP environment. The
INVITE contains IP and Port addressing information which will pass through
NAT unchanged, meaning that the recipient of the INVITE will potentially be
supplied with private, unusable addressing information for the media stream.
The SBC will actively amend SIP signalling with usable IP addressing in order
to overcome this, usually acting as a “man in the middle” for the media
stream.
Access Control and QoS Enforcement
The SBC acts as an ALG (Application Level Gateway) in order to filter
potentially malicious SIP traffic entering the network. As part of this role, traffic
can also be filtered to support access control, which allows the service
provider to determine who is permitted to use the network to establish calls. In
addition, traffic can also be monitored for QoS Enforcement purposes, with
the SBC potentially restricting the number of calls being established, in order
to avoid detrimentally affecting calls already in progress.
Media Encryption
Although media is typically not encrypted across the service provider’s
network, there may be a requirement to encrypt / decrypt media traffic as it

leaves or enters other networks. As such, the SBC can carry out this function,
employing protocols such as SRTP (Secure Real time Transport Protocol),
which in turn employs AES (Advanced Encryption Standard).
SBC Deployment
The term SBC does not belong to any one particular standard, since the SBC
is a non-standardized device whose features are largely dependent on the
manufacturer. An SBC will typically be deployed in one of two scenarios, both
of which involve the SBC being positioned at the border of the service
provider’s network. Figure 20 highlights the two predominant deployment
scenarios; an A-SBC (Access - Session Border Controller) or I-SBC
(Interconnect - Session Border Controller).
A I
SBC SBC
Access Network Service Provider Peer IMS/SIP

eg IP-CAN IMS Network Service Provider
Access SBC Interconnect SBC
Figure 20 SBC Deployment Scenarios
In terms of peering and interconnect, the SBC acts as a focal point for
signalling and potentially media that flows from the service provider’s network
to a peer VoIP service provider. This may be in order to support
interoperability or possibly QoS Enforcement.
Conversely, an SBC deployed in the Access scenario is designed to handle
signalling and media flowing between the VoIP service provider’s network and
an access network such as an Enterprise VoIP network or residential
customers.
In each case, when an SBC is positioned in a service provider’s network, it
usually assumes several logically separate roles within the same box. The
logical roles an SBC may perform is outlined in Figure 21 (this is often termed
“Edge Controlled IMS” due to the fact that the SBC is performing a multitude
of key roles).
P-CSCF I-CSCF S-CSCF
BGCF ATCF IBCF
ATGw IM-MGW MRFP
Figure 21 SBC Logical Roles
3.5 IMS Deployment Options

Fundamentally, the functional implementation of an IMS deployment can be
significantly different to the actual physical implementation that the service
provider utilizes. The reason is largely attributed to cost; there are several
implementation options which can reduce the cost associated with a full blown
IMS deployment, as outlined in Figure 22. Geographic and Physical

consolidation options are not necessarily mutually exclusive - the service

provider may choose to adopt a mixture of implementation options.
Application
Geographic
Services Hub and Spoke 3 rd Party Hosted
Consolidation
Centralization
Physical Edge Controlled

VoLTE in a Box IMS in a Box
Consolidation IMS
Figure 22 IMS Implementation Options
Geographic Consolidation
Application Services Centralization
Application
Servers
Centralized
Network
Local IMS Multiple IMS

Networks networks can utilize
AS the same centralized
Application Servers
HSS
I
A-SBC
I-SBC
Access CSCF Interconnect
Network
P S
CSCF CSCF
Figure 23 Application Services Centralization
This approach centres around the Application Servers used by a service

provider. In essence, although the service provider will deploy their own IMS,
some of the Application Servers used are hosted by a 3rd party in a
centralized network. Other IMS networks can use the same centralized
Application Servers, which means that the service offered by the AS will be
consistent across multiple IMS networks.
Hub and Spoke
With a Hub and Spoke architecture, a centralized Group Operations network
operating on a global or regional basis will host the core IMS. Local
operations running national networks will then utilize this IMS core. In order to
support local/country regulations, an A-SBC (Access – Session Border
Controller) and a local HSS may be implemented (often for Lawful Intercept or
network monitoring).

National Group
Operations Operations
National A-SBC
Access
Network AS
HSS
I
A-SBC
I-SBC
National A-SBC
Network
P S
CSCF CSCF
National A-SBC
Access
Network
HSS
Figure 24 Hub and Spoke Deployment
3rd Party Hosted

Similar in concept to Hub and Spoke, a 3rd Party Hosted deployment will see
different service providers utilize a 3rd party IMS network. Essentially, IMS
functionality is outsourced to the 3rd party. Once again, HSS and A-SBC may
be retained in the individual service provider networks.
Different 3rd Party

Operators IMS
Service A-SBC
Access AS
Provider A
HSS
I
A-SBC
I-SBC
Service A-SBC
Provider B
P S
CSCF CSCF
Service A-SBC
Access
Provider C
HSS
Figure 25 3rd Party Hosted
Physical Consolidation
VoLTE in a Box
HSS
I VoLTE In a Box
CSCF
Access A-SBC I-SBC
S Interconnect
Network CSCF
P AS
CSCF
Figure 26 VoLTE in a Box

With this physical consolidation approach, all the IMS and VoLTE functionality
required by the service provider is part of a “one box” solution. This eases
deployment complexity significantly, although for future scalability it is prudent
to ensure the device will interoperate with other IMS elements.
IMS in a Box
AS AS
HSS
I IMS in a Box
CSCF
Access A-SBC I-SBC
Interconnect
Network S
CSCF
P
CSCF
Figure 27 IMS in a Box
Almost identical to a VoLTE in a Box solution, the difference with an IMS in a

Box solution is the lack of AS functionality within the box.
Edge Controlled IMS
Edge Controlled IMS solutions rely on the fact that the SBC is capable of
performing a number of IMS related functions. In this respect, the SBC may
conduct P-CSCF and I-CSCF functions, as well as Policy Control, MRF
(Multimedia Resource Function), ATCF (Access Transfer Control Function)
and MGW (Media Gateway) tasks (see Figure 21). In this architecture, the S-
CSCF continues to conduct its authentication and service brokering role.
AS
IMS HSS IMS
Network Network
Access A-SBC I-SBC
Edge Edge Interconnect
Network
S
CSCF
P I
CSCF CSCF
Figure 28 Edge Controlled IMS
PCC Architecture
PCC5 was introduced before VoLTE, largely as a means to have very granular
control of the IP traffic flowing across the service provider’s network. PCC
allows the service provider to implement different service profiles for different
customers, and bill appropriately for the service delivery. For VoLTE, PCC
provides a critical link between the LTE bearer network and the IMS service
control network.
Figure 29 outlines the basic PCC architecture required for VoLTE, including all
nodes and associated interfaces.
5
3GPP TS 23.203 - Policy and charging control architecture

Figure 29 PCC Architecture
4.1 PCC Network Nodes

Policy and Charging Rules Function
The PCRF (Policy and Charging Rules Function) creates “PCC rules” which
define how a particular IP traffic flow can be detected (through identification of
IP addresses, ports etc), what level of QoS (relating to the QCI value in LTE)
must be applied to that flow and the associated charging information. In the
context of VoLTE, this traffic flow would be the voice packets associated with
a call.
PCC Rules are created through interaction with the AF (Application Function)
and the SPR (Subscription Profile Repository), allowing the PCRF to
determine whether or not a particular flow is authorized in the first instance.
Policy and Charging Enforcement Function
Co-located with the PDN-GW, the PCEF (Policy and Charging Enforcement
Function) is responsible for filtering traffic within the IP-CAN based on PCC
rules provided by the PCRF. As such, the PCEF is responsible for ensuring IP
traffic flows are treated with the appropriate QoS within the LTE network, in
addition to ensuring that billing information is passed to online/offline charging
as appropriate.
Application Function
An AF (Application Function) is capable of generating triggers in the form of
Diameter AAR (Authorization Authentication Request) messages in order to
cause the PCRF to dynamically create a PCC rule.
In the case of the 3GPP IMS (IP Multimedia Subsystem), an example of an
AF is the P-CSCF (Proxy - Call Session Control Function), although the AF
could also potentially be a 3rd party application server. During IMS session
establishment, the AF will take information from the SIP (Session Initiation
Protocol) signalling and pass it to the PCRF in order for the appropriate PCC
rule to be formulated. For VoLTE, this information would include parameters
such as IP addressing, ports, media type, media format, bandwidth
requirements etc, all of which will be pertinent to the media streams which are
attempting to be established for the call.

Subscription Profile Repository

The SPR (Subscription Profile Repository) provides a similar role to the HSS
(Home Subscriber Server) in terms of providing subscriber information to
relevant network nodes. In the case of the SPR, subscriber information is
provided to the PCRF in order to allow the PCRF to ascertain who is allowed
to access the IP-CAN and what kind of QoS they are permitted to request on
a per service basis. Information provided by the SPR would include the
subscriber’s allowed services, guaranteed bandwidth QoS level and charging
related information.
Charging Servers
Charging servers include the OCS (Online Charging Server) and OFCS
(Offline Charging Server). The Diameter based Gy and Gz connect the PCEF
to the OCS and OFCS respectively. Although billing information may
potentially be generated for all sessions and events, this may not necessarily
be reflected in the subscriber’s tariff/bill.
End to End VoLTE Architecture

Figure 30 shows an end to end view of the architecture required for VoLTE,
including LTE, PCC and IMS. It should be noted that the diagram depicts each
VoLTE mobile utilizing separate LTE, PCC and IMS nodes. Although this is
possible (particularly in the case of a cross network call), it is equally likely
that some nodes in the end to end picture would be shared by both the Calling
and Called Party. Moreover, Figure 30 only accommodates a VoLTE to VoLTE
call scenario; additional elements would be required for PSTN interworking.

MPI0124-000-010
HSS DNS
PDN SCC
MME SG
i
I Cx Cx
HSS PDN S
GW CSCF CSCF
S6
a
PCEF ISC
SG
S1 i Mw
1 S-GW S5
Gx ISC
Mw
S1 Mw ATCF TAS
-M
ME
PCRF
Mw
-U
S1
P Mw
Rx I
CSCF
CSCF
Mb
eNB Iq
Uu
Cx
Gm ATGw HSS
Mw
© Mpirical Limited, 2020

Cx
Mb
ISC
S TAS
MME Mb
HSS PDN CSCF
GW ATGw
S6
a
ISC
PCEF SG
i
S1
1 S-GW S5 Iq Mw SCC
Figure 30 End to End VoLTE Architecture

S1 Gx
-M
ME
ATCF
PCRF
-U
S1
Mw
P
Rx
CSCF
eNB
Uu
Gm
27

Glossary
AAA (Authentication, Authorization and I-SBC (Interconnect – Session Border

Accounting) Controller)
AAR (Authorization Authentication MGW (Media Gateway)
Request) MME (Mobility Management Entity)
AES (Advanced Encryption Standard) MPEG (Moving Picture Experts Group)
AF (Application Function) MRF (Multimedia Resource Function)
AKA (Authentication and Key Agreement) MSC-S (Mobile Switching Centre –
AMR (Adaptive Multi Rate) Server)
A-SBC (Access – Session Border MSRP (Message Session Relay Protocol)
Controller) OCS (Online Charging Server)
A-SBC (Access Session Border OFCS (Offline Charging Server)
Controller) OIR (Originating Identification Restriction)
ATCF (Access Transfer Control Function) PCC (Policy and Charging Control)
ATGw (Access Transfer Gateway) PCEF (Policy and Charging Enforcement
CB (Communication Barring) Function)
CDIV (Communication Diversion) PCRF (Policy and Charging Rules
CDRs (Charging Data Records) Function)
eNB (Evolved Node B) P-CSCF (Proxy - Call Session Control
ENUM (e.164 to SIP URI Mapping) Function)
EPC (Evolved Packet Core) PDN-GW (Packet Data Network Gateway)
ePDG (evolved Packet Data Gateway QoS (Quality of Service)
E-UTRAN (Evolved - Universal Terrestrial RADIUS (Remote Authentication Dial In
Radio Access Network) User Service)
FTP (File Transfer Protocol) RCS (Rich Communication Services)
GBR (Guaranteed Bit Rate) R-NNI (Roaming - Network to Network
GSMA (GSM Association) Interface)
HLR (Home Location Register) ROHC (Robust Header Compression)
HSS (Home Subscriber Server) RTP (Real time Transport Protocol)
IBCF (Interconnection Border Control SBG (Session Border Gateway)
Function) SCC (Service Centralization and
ICS (IMS Centralized Services) Continuity)
I-CSCF (Interrogating Call Session S-CSCF (Serving - Call Session Control
Control Function) Function)
IETF (Internet Engineering Task Force) S-GW (Serving Gateway)
IMPU (IMS Public User Identity) SIP (Session Initiation Protocol)
IMS (IP Multimedia Subsystem) SPR (Subscription Profile Repository)
I-NNI (Interconnect - Network to Network SRTP (Secure Real time Transport
Interface) Protocol)

SR-VCC (Single Radio – Voice Call ViLTE (Video over LTE)

Continuity) VoWi-Fi (Voice over Wi-Fi)
TAS (Telephony Application Server) XCAP (XML Configuration Access
UE (User Equipment) Protocol)
UNI (User to Network Interface)

Innovating Telecoms Training
Contact Us
Tel: +44 (0) 1524 844669
Email: enquiries@mpirical.com
www.mpirical.com

VoLTE End To End Architecture (MPI0124-000-010)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VoLTE End To End Architecture (MPI0124-000-010)

Uploaded by

Copyright:

Available Formats

Innovating Telecoms Training

VoLTE End to End Architecture

VoLTE End to End Architecture

MPI0124-000-010 © Mpirical Limited, 2020 i

First published by Mpirical Limited in 2017

ii © Mpirical Limited, 2020 MPI0124-000-010

Test Deploying VoLTE ........................................................................................... 7

Glossary ............................................................................................ 29

MPI0124-000-010 © Mpirical Limited, 2020 iii

iv © Mpirical Limited, 2020 MPI0124-000-010

Figure 1 LTE and VoLTE Deployments ......................................................................... 7

Figure 7 Interfaces and Associated Protocols ............................................................. 11

Figure 10 IMS Network Architecture............................................................................ 13

Figure 13 P-CSCF Responsibilities ............................................................................. 15

Figure 16 Media Path Using ATGws ........................................................................... 17

Figure 19 SBC Key Functions ..................................................................................... 19

Figure 28 Edge Controlled IMS ................................................................................... 24

MPI0124-000-010 © Mpirical Limited, 2020 v

vi © Mpirical Limited, 2020 MPI0124-000-010

Test Deploying VoLTE

Figure 1 LTE and VoLTE Deployments

Figure 2 Global Distribution of VoLTE (GSMA)

MPI0124-000-010 © Mpirical Limited, 2020 7

Figure 3 IMS Call Control

1.1 VoLTE High Level Network Architecture

Figure 4 VoLTE High Level Network Architecture

LTE Access Network

8 © Mpirical Limited, 2020 MPI0124-000-010

1.2 VoLTE Standardization

MPI0124-000-010 © Mpirical Limited, 2020 9

 Real time media negotiation, transport and codecs.

GSMA IR92 – IMS Profile for Voice and SMS

Figure 5 VoLTE Standardization (GSMA IR.92)

Consequently, the VoLTE specifications are focused on 3 main areas:

LTE Access Network

GW will often house the PCEF (Policy and Charging Enforcement

Figure 6 LTE Network Architecture

Although the LTE network architecture depicted in Figure 6 would support

Figure 7 Interfaces and Associated Protocols

MPI0124-000-010 © Mpirical Limited, 2020 11

IMS Call Control Network

Figure 8 IMS Call Control Network

IMS is a service management framework; it is essentially an architecture

3.1 IMS Requirements

Figure 9 IMS Requirements

12 © Mpirical Limited, 2020 MPI0124-000-010

 Access Independence - access to IMS based services should be

3.2 IMS Architecture

Figure 10 IMS Network Architecture

Control Plane Protocols

MPI0124-000-010 © Mpirical Limited, 2020 13

SIP Establishment and Teardown of VoLTE Calls

Supporting Authentication , Authorization and

Instant Messaging MSRP

Figure 11 IMS Control Plane Protocols

RTP MPEG MSRP FTP

Figure 12 User Plane Protocols

14 © Mpirical Limited, 2020 MPI0124-000-010

3.3 Call Session Control Functions

Figure 13 P-CSCF Responsibilities

MPI0124-000-010 © Mpirical Limited, 2020 15

Figure 14 I-CSCF Responsibilities

Figure 15 S-CSCF Responsibilities