VoLTE Project Report

Ministre de lenseignement Ministre de la poste et des
suprieur et de la recherche technologies de linformation et de la

scientifique communication
Institut National des

Tlcommunications et des

Technologies de lInformation et de

la Communication
Projet de Fin dEtude pour lobtention du
Diplme dIngnieur dEtat
En Tlcommunications.
Thme:
Voice over LTE (VoLTE)
Prsent par :
Mr. Mohamed Zakaria KOUNINEF
Mr. Abed TAYEB
Encadr par :
Mr. O.KAID OMAR
Prsident : Mr.S.Niar
Examinateurs : Mr.A.ROUMANE
Mr.A.MAZOUZI
Promotion : IGE 35
Anne Universitaire : 2014- 2015

DEDICATION
I am satisfied for finishing my work. Firstly I
thank god most powerful, who facilitate things for
me and put me in a good condition. I also send my
special thanks to:- - All my family My Father, My
Mother, brothers and Sisters. To all my friends - To
all who helps me in one way or another during the
realization of this project. -To all who participate
during my presentation of this projects. -To the
president and its cabinet for their acceptance in
examining and evaluating my project. - To my
tutor for its advice and everything he gave to me.

Table Of Contents
Abstract ........................................................................................................................6
CHAPTER 1. LTE Architecture .................................................................................8
1.1 Introduction .......................................................................................................8
1.2 LTE Architecture ...............................................................................................8
1.2.1 UE (User Equipment): ................................................................................8
1.2.2 Radio Access Network: ..............................................................................9
1.2.2.1 eNodeB ................................................................................................9
1.2.3 Core Network. The Evolved Packet Core (EPC): ....................................9
1.2.3.1 Mobility Management Entity (MME) .................................................9
1.2.3.2 SGW (Serving Gateway): ..................................................................10
1.2.3.3 PGW (Packet Data Network Gateway): ............................................10
1.2.3.4 HSS (Home Subscriber Server): .......................................................11
CHAPTER 2. SOLUTIONS FOR SUPPORTING VOICE OVER LTE .................12
2.1 INTRODUCTION ...........................................................................................12
2.2 Voice Over LTE ..............................................................................................13
VoLTE problem .....................................................................................................15
2.3 VoLTE Interface Description ........................................................................15
2.4 Solutions for VoLTE .......................................................................................20
2.4.1 Circuit switched Fallback ........................................................................20
2.4.2 VoLGA - Voice over LTE via Generic Access .............................24
2.4.3 IP Multimedia Subsystem IMS ..................................................26
History of IMS ....................................................................................................27
2.4.3.1 VoLTE with IMS Architecture .....................................................28
2.4.3.1.1 The role of Call Session Control Function (CSCF) ......................29
2.4.3.1.2 Session Border Gateway (SBG) ....................................................31
2.4.3.1.3 MMTel Application Server (MTAS) .............................................31
1
Table Of Contents
2.4.3.1.4 Media Resource System (MRS) ....................................................32

2.4.3.1.5 Home Subscriber Server (HSS) .....................................................33
2.4.3.1.6 Media Gateway Control Function (MGCF) ..................................33
2.4.3.1.7 Media Gateway (MGW) ................................................................34
2.4.4 Key protocols used in the IMS network ..............................................34
2.4.4.1 Session Initiation Protocol (SIP) .......................................................34
2.4.4.2 Diameter the Authentication, Authorization, and Accounting
protocol 36
2.4.4.3 H.248 media control protocols ..........................................................36
2.4.4.4 IPv6 ....................................................................................................36
2.4.5 Basic VoLTE UE to VoLTE UE Voice Call Establishment
Originating Side ..................................................................................................37
Terminating Side.................................................................................................42
2.5 Voice over IP (VoIP) ......................................................................................46
2.6 Quality of Service (QoS) ................................................................................47
2.6.1 General .....................................................................................................47
2.6.2 Standardized QCI characteristics ............................................................47
Chapter 3. Test Plan & Services ................................................................................53
3.1 Introduction .................................................................................................53
3.2 Presentation of the tools ..............................................................................53
3.3 Test methodology and making traces: ........................................................54
3.4 Services .......................................................................................................56
3.4.1 Attach and registration .........................................................................56
3.4.2 Re-registration ......................................................................................57
3.4.3 Deregistration .......................................................................................57
3.4.4 Originating call.....................................................................................57
3.4.5 Originating Identity Presentation (OIP) ..............................................59
3.4.6 Originating Identity Restriction (OIR) ................................................60
2
Table Of Contents
Originating Idententity Register (OIR) ..............................................................61

3.4.7 Communication Waiting CW ..............................................................61
3.4.8 Communication Hold ...........................................................................64
3.4.9 Communication Barring (CB) .............................................................65
Out-going Call Barring (OCB) ...........................................................................66
Incoming Call Barring (ICB) ..............................................................................67
3.4.10 Communication Forwarding Unconditional (CFU) ...........................68
3.4.11 Call Forwarding Busy ..........................................................................69
3.4.12 Communication Forwarding on No Reply ..........................................70
3.4.13 Conference Call ....................................................................................71
Conclusion...... 72
References ..73
Definition of terms ..76
3
List Of Figures
Figure 1: LTE Architecture .........................................................................................8

Figure 2: Architecture For Circuit Switched FallBack ............................................21
Figure 3: VoLTE with IMS Architecture ..................................................................28
Figure 4: Basic VoLTE UE to VoLTE UE Voice Call Establishment Originating
Side.............................................................................................................................37
Figure 5: Basic VoLTE UE to VoLTE UE Voice Call Establishment Terminating
Side.............................................................................................................................43
Figure 6: Standardized QCI characteristics for client/server ....................................48
4
List Of Tables
Tableau 1: Standardized QCI characteristics ............................................................49

Tableau 2: Registration Test ......................................................................................56
Tableau 3: Re-registration Test .................................................................................57
Tableau 4: Deregistration Test ..................................................................................57
Tableau 5: Basic Call Test .........................................................................................58
Tableau 6: OIP Test ...................................................................................................60
Tableau 7: OIR Test...................................................................................................61
Tableau 8: Call Wating Test ......................................................................................63
Tableau 9: Communication Hold ..............................................................................65
Tableau 10: Out-going Call Barring Test..................................................................66
Tableau 11: Incoming Call Barring Test ...................................................................67
Tableau 12: CFU Test................................................................................................68
Tableau 13: CFB Test ................................................................................................69
Tableau 14: CFNRy Test ...........................................................................................70
Tableau 15: Conference Call .....................................................................................71
5
Voice Over LTE
Abstract
Long Term Evolution (LTE) is the latest high speed mobile broadband
technology that is gaining widespread attention due to its high data rates and
improved Quality of Service (QoS). Initially, LTE was seen as a technology for
supporting high speed data, but there is a growing interest in the industry to support
voice over LTE. The support of voice over LTE has lot of challenges owing to the
fact that both voice and data traffic are to be carried over the same radio and core
networks. The optimum usage of resources in the radio network is of high
importance as there is a growing need to improve the capacity at reduced cost. The
transport network is another key area that needs to be carefully planned according
to the capacity of the radio network. Differentiation and scheduling of resources in
the transport network plays a key role in guaranteeing good end to end performance
for both voice and data services.
In this project we will discuss Voice over LTE solutions but especially
Voice over LTE using IMS (IP Multimedia Subsystem).
It was agreed in the GSMA in February 2010 that voice services over LTE (VoLTE)
shall use the IMS platform standardized by the 3GPP with a view to maximizing
international interoperability. We describe the background behind the adoption of
VoLTE using IMS, the contents of the VoLTE profile which is a technical
specification drafted by the GSMA for VoLTE implementation and, the technical
details of IMS registration and voice call origination procedures which form the basics
of VoLTE.
Since both LTE and Evolved Packet Core (EPC, which is a core network
accommodating LTE) are All-IP networks for offering high-speed mobile, it is
inevitable that voice services broadband and multimedia services provided over
LTE which is the subject of this article adopt an IP-based system.
The GSM Association (GSMA), an industry organization, has conducted studies
on Voice over LTE (VoLTE) using the IP Multimedia Subsystem (IMS)
platform - IMS being a system standardized by the 3GPP for IP-based multimedia
services - as a means to provide voice services over LTE, and a document called
VoLTE Profile has been drawn up which specifies a set of minimum required
functions.
6
Voice Over LTE
GSMA
The GSM Association (GSMA, or Group Special Mobile Association),

formed in 1995, is an association of mobile operators and related companies
devoted to supporting the standardizing, deployment and promotion of the GSM
mobile telephone system.
The GSMA organizes the largest annual event in the mobile industry, the GSMA
Mobile World Congress, in addition to smaller, targeted events GSMA Mobile
World Congress Shanghai and the GSMA Mobile 360 Series.
The GSMA represents the interests of mobile operators worldwide, uniting nearly
800 operators with more than 250 companies in the broader mobile ecosystem,
including handset and device makers, software companies, equipment providers
and Internet companies, as well as organizations in adjacent industry sectors.
It traces its history back to the Bonn declaration by the Ministers of Germany, UK,
France and Italy in May 1987 that called for the drawing up of a MoU to be ready
by September 1987 for the signature of European mobile operators. The GSM MoU
was the idea of Stephen Temple, a senior official in the UK Department of Trade
and Industry. 13 mobile network operators from 12 countries signed the GSM MoU
on 7 September 1987 in Copenhagen. The original copy is held by the GSM
Association and was described later by Sir Christopher Gent, former CEO of
Vodafone, as the most important document in mobile radio history. The "GSM
MoU Association" was created in 1995 by the signatories.
Telecoms.com called it "one of the most powerful trade associations in the world,
lobbying governments on everything from tax policy to pricing strategy.
7
CHAPTER
1 LTE ARCHITECTURE
CHAPTER 1. LTE Architecture
1.1 Introduction
In this chapter we will see just an overview about LTE architecture and
description about User Equipment, E-UTRAN (Evolved-Universal Terrestrial
Radio Acces Network) and EPC (Evolved Packet Core).
1.2 LTE Architecture
Figure 1: LTE Architecture
1.2.1 UE (User Equipment): The 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.
8
CHAPTER 1.LTE Architecture
The User Equipment that is used to connect to the EPC, in the figure
above this is an LTE capable UE accessing EPS via the LTE-Uu radio
interface. Other access technologies may also be supported by the UE.
1.2.2 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.
1.2.2.1 eNodeB
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/decompress- ion of DL/UL user plane packet
headers.
1.2.3 Core Network. The Evolved Packet Core (EPC):
The EPC network plays an important role. EPC nodes shall handle user
attach and bearer creation for IMS signaling and voice media. EPC network also
provide information to IMS network in order to build up network provided location
information.
1.2.3.1 Mobility Management Entity (MME)
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
9
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) signaling 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 providers PMN and enforces UE roaming restrictions. The MME is the
termination point in the network for ciphering/integrity protection for NAS
signaling and handles security key management.
Lawful interception of signaling 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.
The MMEs are connected to the eNBs over the S1AP interface, the EPG
provides the SGW function over S11 interface and the HSS is provided over the
S6a interface.
1.2.3.2 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.
1.2.3.3 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
10
PGW functions could be realized as a single network element.
1.2.3.4 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.
11
CHAPTER
2 SOLUTIONS FOR SUPPORTING VOICE OVER LTE
CHAPTER 2. SOLUTIONS FOR SUPPORTING VOICE OVER

LTE
2.1 INTRODUCTION
LTE (Long Term Evolution) is the next-generation mobile technology that

delivers true all-IP communications. Mobile operators understand the benefit of
converging voice, messaging and video onto a single common IP infrastructure to
reduce costs and enables them to launch innovative new applications and services
to drive new revenues. There is a global commitment with 196 operators in 75
countries investing in LTE1 and almost 100 LTE user devices announced in early
2011.
The deployment of LTE is accelerating as it is now becoming the fastest

developing mobile system technology to date. The lower cost of operation (about
20X cheaper to carry voice over 4G than 2G), new devices (such as smart phones
and tablets), and the new services being demanded (such as video, content sharing
and voice collaboration) have lead Mobile Operators to focus on LTE as part of
their business strategy. In addition, it provides a response to the competitive threats
of the over the top players (OTT) such as Skype/Microsoft or Google, who seek
greater subscriber control via core voice, video and messaging service offerings.
There is a significant market opportunity that is very attractive to OTT players to
provide voice, video and messaging.2
In 2013, voice revenue will still account for 61% of all mobile service revenue
(Source: GSMA). However, there is a challenge for operators in that LTE is an all-
IP mobile network with new solutions and network transformation required to
support communication services over LTE. A single technology with open
standards and a common interface is needed to ensure global scale implementation
and universal connectivity.
Voice and SMS over LTE (VoLTE) has emerged and been adopted by global LTE
operators as the GSMA standard to address the end-to-end voice and SMS
ecosystem and 94% will deploy IMS for VoLTE3. This opens a wide window of
12
CHAPTER 2. SOLUTION FOR SUPPORTING VOICE OVER LTE
opportunities for operators to use voice core transformation as a starting point for
innovative services possible with high speed, low latency LTE pipe.
2.2 Voice Over LTE
Voice over LTE or VoLTE is a GSMA profile of the standards definition for
the delivery of services currently provided via Circuit Switch networks - mainly
voice and SMS - over the Packet Switched only network of LTE, leveraging the
core network IP Multimedia Sub-System (IMS). When mobile networks deploy
LTE radio access technology, conformity to the VoLTE profile provides operators
with assurance of interworking between their LTE network and the devices that
connect to it, as well as providing for the expected user experience of voice Multi-
Media Telephony service and SMS. In combination with Policy Control, IMS
provides for the required QoS appropriate for voice service using LTE radio access
technology, thereby providing the user experience of voice calls that subscribers
expect. Moreover, VoLTE is designed to fully integrate with the existing user
experience that is currently implemented with circuit switched voice devices, and
therefore whether the call is a circuit switched call or a VoLTE call is transparent to
the end user (including when moving in and out of LTE coverage) and is dependent
only on which radio access technology to which the user is attached. At the same
time, using new, wideband codecs can provide higher voice quality and enhance the
user experience.
VoLTE is in accordance with 3GPP specifications and additional profiling is

defined within GSMA Permanent Reference Documents.
GSMA PRD IR.92 defines the UNI for IMS voice and SMS. It defines a profile
that identifies a minimum mandatory set of features which are defined in 3GPP
specifications that a wireless device (UE) and network are required to implement in
order to guarantee an interoperable, high quality IMS-based voice telephony
service over LTE.
Even with the fast rise of web and data services in mobile networks, voice
and SMS services still generate around 70 percent of total operator revenues
globally. With these revenues at stake, LTE operators must have a path to provide
high-quality, toll-grade voice services natively on LTE networks. Unlike previous
mobile systems, LTE is designed as a packet switched all-IP system; it does not
13
include a separate circuit-switched domain currently used for voice and SMS
services in 3G networks.
Additionally, there is a technology requirement to allow mobile operators to move
beyond basic voice and texting. For several years, OTT application providers have
delivered very popular voice, video, messaging, and location services that are
shifting consumers attention and usage. Skype and GoogleTalk have nearly a
billion registered users world-wide. Apple has sold countless iPhones and iPads,
many of which are capable of FaceTime video-calling.
With VoLTE (GSMA VoLTE IR.92 specification, based on global 3GPP

standards), mobile operators can deliver a new conversation experience of enriched
voice, enlivened video, and intuitive messaging. VoLTE unlocks these richer
conversation services and lays a foundation for operators to offer them with
telecom-grade quality using well-define quality of service (QoS) mechanisms.
VoLTE is based on the multimedia telephony (MMTel) service, which is the
standardized IMS-based (IP Multimedia Subsystem) VoIP service designed to
replace existing circuit-switched voice. Rich Communications Services (RCS)
marketed under by GSMA, complements VoLTE and provides definition for:
Enhanced phonebook: service capabilities and enhanced contacts

information such as presence and service discovery
Enhanced messaging: enables a large variety of messaging options

including chat, emoticons, location share, and file sharing
Enriched calls: enables multimedia content sharing during a voice call,

video call, and video sharing With VoLTE, operators can:
o Simultaneously deliver data with high-definition (HD) quality voice
o Create attractive communication services, blending mobile voice

with video, converged IP messaging, the web, and social networking
o Harmonize todays fragmented communications
o Benefit from LTEs improved spectral efficiency
o Quickly re-farm 2G and 3G spectrum to LTE for capacity gains
14
VoLTE problem
In mobile broadband networks like LTE, the high performance of the radio
network can be realized with proper scheduling of resources for different types of
services. But proper scheduling of resources in the radio network alone is not
sufficient to guarantee a good end to end performance. During periods of high
congestion, packet losses might occur in the transport network which can reduce
the overall performance of the service that is offered to the user. Hence, the
transport network between the radio and core networks is another area which needs
proper dimensioning and scheduling of resources for various types of services. The
transport network is not aware of the QoS architecture of LTE. This implies that the
various bearers that are used to classify the services in LTE domain needs to be
mapped to IP based QoS techniques.
The Differentiated services architecture (Diffserv) which is commonly used in IP
based networks is used to classify the various types of services in the LTE transport
network. The Diffserv architecture needs to be integrated with the LTE QoS
architecture to guarantee good end to end performance. The scheduling of resources
in the transport network is another area which needs proper attention as the choice
of scheduling algorithms is pivotal for optimum usage of resources. There are
various scheduling strategies like Weighted Fair scheduling, Strict Priority
scheduling and Weighted Round Robin scheduling that are used to schedule the
packets based on the priority of each type of service. For real time traffic like VoIP,
the role of the classification and scheduling strategies is of paramount importance
as they play a crucial role in guaranteeing the end to end quality of service to the
users. During periods of congestion, real time services like VoIP can be severely
impacted if there is a marginal increase in the end to end delay between VoIP
packets or there is a packet loss in the transport network.
2.3 VoLTE Interface Description

The main interfaces of the VoLTE architecture are defined by 3GPP and are
described below. Further information can be viewed in 3GPP TS 23.002 [1].
LTE-Uu Interface (UE eNodeB)
LTE-Uu is the radio interface between the eNodeB and the User Equipment. It is
defined in 3GPP TS 36.300 [2]. series of documents.
15
S1-MME Interface (UE MME)
S1-MME is the control plane interface between EUTRAN and MME. The
protocols used over this interface are the Non-access stratum protocols (NAS)
defined in 3GPP TS 24.301 [3]..
S1AP Interface (eNodeB MME)
S1AP is the S1 application protocol between the EUTRAN and MME and is
S1-U Interface (eNodeB SGW)
S1-U is the interface between EUTRAN and the S-GW for per-bearer user plane
tunneling and inter-eNodeB path switching during handover. The transport protocol
over this interface is GPRS Tunneling Protocol-User plane (GTPv1-U) defined in
3GPP TS 29.281 [5]..
X2 Interface (eNodeB eNodeB)
X2 is the interface between eNodeB and is used for X2-based Handover and some
Self-Organizing Network (SON) capabilities. The signaling protocol (X2
Application Protocol) , the user plane (GTPv1-U) is defined in 3GPP TS 29.281
[5]..
S5 Interface (SGW PGW)
The S5 interface provides user plane tunneling and tunnel management between
SGW and PGW. The SGW and PGW may be realized as a single network element
in which case the S5 interface is not exposed. The control plane protocol (GTPv2-
C) is defined in 3GPP TS 29.274 [31] and the user plane protocol (GTPv1-U) is
S6a Interface (HSS MME)
The interface enables the transfer of subscription and authentication data for
authenticating/authorizing user access. The protocol used on the S6a interface is
Diameter and is defined in 3GPP TS 29.272 [6]..
S9 Interface (H-PCRF V-PCRF)
16
The S9 interface provides policy and charging rules and QoS information between
the Home PMN and the Visited PMN in order to support PCC roaming related
functions. The protocol used on the S9 interface is Diameter. The S9 interface is
optional and deployed by bilateral agreement between the Home and Visited
Operators. The policy and charging rules for roaming subscribers may be realized
by local configuration data in the Visited PCRF. However, for completeness, S9
interaction is shown for all appropriate flows in this document.
S10 Interface (MME MME)
The S10 interface provides for MME MME information transfer and is used to
enable MME relocation. The protocol used on the S10 interface is GPRS Tunneling
Protocol-Control plane (GTPv2-C) and is defined in 3GPP TS 29.274 [7]..
S11 Interface (MME SGW)
The S11 interface is between the MME and S-GW to support mobility and bearer
management. The protocol used on the S11 interface is GPRS Tunnelling Protocol-
Control plane (GTPv2-C) and is defined in 3GPP TS 29.274 [7]..
Gx Interface (PCRF PGW)
The Gx interface is between the PCRF and the PGW, allowing the PCRF direct
control over the policy enforcement functions of the PGW. The protocol used on
the Gx interface is Diameter and is defined in 3GPP TS 29.212 [8]..
Rx Interface (PCRF P-CSCF)
The Rx interface is between the appropriate Application Function (the P-CSCF in

the case of VoLTE) and the PCRF allowing the Application Function to request the
application of an appropriate policy for a session. The protocol used on the Rx
interface is Diameter and is defined in 3GPP TS 29.214 [9]..
SGi Interface (PGW P-CSCF)
The SGi interface is between the PGW and the P-CSCF within the IMS Network.
The Gm reference point from the UE to P-CSCF is tunnelled within SGi for
VoLTE services. SGi is IP-based and is defined within 3GPP TS 29.061 [10]..
Cx Interface (I/S-CSCF HSS)
17
The Cx interface is between the I/S CSCF and HSS to enable IMS registration and
passing of subscriber data to the S-CSCF. The protocol used on the Cx interface is
Diameter and is defined in 3GPP TS 29.229 [11]..
Sh Interface (VoLTE MTAS HSS)
The Sh interface is between the VoLTE Application Server and HSS to enable
service and subscriber related information to be passed to the Application Server or
stored in the HSS. The protocol used on the Sh interface is Diameter and is defined
in 3GPP TS 29.328 [33] [12]. and 3GPP TS 29.329 [13].
Gm Interface (UE P-CSCF)
The Gm interface is between the UE and the P-CSCF and enables connectivity
between the UE and the IMS network for registration, authentication, encryption,
and session control. The protocol used on the Gm interface is SIP/SDP and is
defined within 3GPP TS 24.229 [14].and profiled within GSMA PRD IR.92 [15]..
Ut Interface (UE MTAS)
The Ut interface is between the UE and the MTAS and allows user configuration of
the supplementary services specified for VoLTE service. The protocol used on the
Ut interface is XCAP and is defined in 3GPP TS 24.623 [16]..
Mx Interface (x-CSCF IBCF)
The Mx interface is between CSCF and IBCF used for the interworking with
another IMS network. The protocols used on the Mx interface are SIP and SDP and
are defined in 3GPP TS 24.229 [14].
Mw Interface (x-CSCF x-CSCF)
The Mx interface is between a x-CSCF and another x-CSCF within the IMS core
network (e.g. P-CSCF to I/S-CSCF). The protocols used on the Mw interface are
SIP and SDP and are defined in 3GPP TS 24.229 [14]..
Mg Interface (xCSCF MGCF)
18
The Mg reference point allows the MGCF to forward incoming SIP/SDP messages
that the MGCF has interworked from the CS Network to the CSCF. The protocols
used on the Mg interface are SIP and SDP and are defined in 3GPP TS 24.229
[14]..
Mi Interface (S-CSCF BGCF)
The Mi reference point allows the Serving CSCF to forward the SIP/SDP messages
to the Breakout Gateway Control Function for the purpose of MGCF selection for
interworking with CS networks. The protocols used on the Mi interface are SIP and
SDP and are defined in 3GPP TS 24.229 [14]..
Mj Interface (BGCF MGCF)
The Mj reference point allows the Breakout Gateway Control Function to exchange
SIP/SDP messages with the BGCF for the purpose of interworking with CS
networks. The protocols used on the Mj interface are SIP and SDP and are defined
in 3GPP TS 24.229 [14]..
ISC Interface (S-CSCF MTAS)
The ISC interface is between S-CSCF and Telephony Application Server and is
used to interact with the MMTel supplementary services implemented on the
MTAS. The protocol used on the ISC interface is SIP and is defined in 3GPP TS
24.229[14].
Mr Interface (S-CSCF MRS)
The Mr interface is between the S-CSCF and the MRS to allow interaction with the
media resource for specific supplementary services (e.g. conference call). The
protocol used on the Mr interface is SIP/SDP and is defined in 3GPP TS 24.229
[14].
Mr Interface (MTAS MRS)
The Mr' interface is between the Telephony Application Server and the MRS to
allow interaction with the media resource for specific supplementary services (e.g.
conference call). The protocol used on the Mr' interface is SIP/SDP and is defined
in 3GPP TS 24.229 [14].
Cr Interface (MTAS MRS)
19
The Cr interface is between the Telephony Application Servers and the MRS. And
is used for sending/receiving XML encoded media service requires (Cr) which are
served by the MRS. The protocol is defined in 3GPP TS 24.229 [14], 3GPP TS
24.147 [17], and 3GPP TS 24.247 [18].
2.4 Solutions for VoLTE
For supporting Voice Over LTE we have many solutions and we will see
some of them
Circuit Switched Fallback

VoLGA
Voice over IMS.
2.4.1 Circuit switched Fallback
LTE technology supports packet based services only; however 3GPP does
specifies fallback for circuit switched services as well. To achieve this LTE
architecture and network nodes require additional functionality, this blog is an
attempt to provide overview for same.
In LTE architecture, the circuit switched (CS) fallback in EPS enables the
provisioning of voice and traditional CS-domain services. To provide these services
LTE reuses CS infrastructure when the UE is served by E UTRAN.
Circuit Switched Fall Back, CSFB is the preferred choice of many operators
around the world to handle voice calls in LTE environment not forever, but at
least for the start. LTE is an all IP network and voice has been traditionally carried
by carriers in TDM environment and hence the need. Till the time all IP
technologies evolve to handle all of the existing services offered by voice carriers,
as well as brand new innovative voice based products economically as well as
ecologically fitting in the network environment, CSFB is expected to fill in the gap.
So what is CSFB? Simply stated voice calls are handed over (fallback) to overlay
3G/2G environment instead of handling them in LTE. As could be expected,
therefore, an interface needs to be extended between the All IP core network of
LTE to TDM world of CS domain i.e., between MME and MSC an interface
called SGs which employs use of SGs Application Part protocol to help in
20
coordinating any Voice, SMS and CS related Supplementary Services call

functions.
Figure 2: Architecture For Circuit Switched FallBack
The SGs interface delivers paging messages that inform the mobile device of an
incoming call. The call itself, however, is not delivered over the LTE interface and
the mobile device has to fall back to a GSM or UMTS network where a circuit-
switched connection is then established for the call. This method of delivering
voice calls is therefore referred to as CS (circuit-switched) fallback and is executed
as follows.
The Preparation Phase
When the GSM/UMTS/LTE-capable device first connects to the EPS (that is, to
LTE), it indicates to the network that it wants to perform a combined attach. In
practice, this means that it requests the network to also register its presence in the
2G/3G circuit-switched network.
Registration of the mobile in the 2G/3G network is performed on behalf of the
mobile device by the MME. From the MSC point of view, the MME acts as an
SGSN. To the MSC, the mobile device seems to be attached to the 2G/3G network
via an SGSN by performing a combined circuit-switched/packet-switched location
update.
For registration in the network, the MME has to inform the MSC of the 2G/3G
Location Area Identity (LAI) in which the mobile device is currently theoretically
located. Since this is only a theoretical value, it has to be computed out of the
21
Tracking Area Identity (TAI), which is the corresponding identifier in LTE. In

practice, this creates a dependency between the TAI and the LAI, that is, the
location areas that describe a group of base stations in 2G/3G and LTE must be
configured in a geographically similar way for the fallback to work later on.
The Execution Phase: Mobile-Terminated Call
When a circuit-switched call for a subscriber arrives at the MSC, it signals the
incoming call via the SGs interface to the MME, which is, in its eyes, a 2G or 3G
SGSN. From here, the notification is forwarded to the mobile device. From the
MSC point of view, this is a legacy procedure that already exists.
If the mobile is in RRC Connected state, the MME can forward the request
immediately. If the mobile wants to receive the call, it signals to the MME that it
would like to be handed over to the 2G or 3G network in which it can receive the
call. The MME then informs the eNode-B that the mobile has to be handed over to
the 2G/3G network.
Since there might still be an ongoing IP data transfer at the time of the handover,
the standard contains two options on how to proceed: Either the data transfer is
suspended or the packet-switched connection is handed over to the 2G/3G network.
This is possible only for UMTS as most 2G networks are not able to handle voice
and data connections simultaneously.
If the mobile is in RRC Idle state when the voice call is signaled, the MME has to
page the mobile device to reestablish radio contact. Once contact has been
reestablished, it forwards the information about the call. Since there is no ongoing
data transfer at this time, no handover of the IP connection is required as the mobile
can reestablish the packet-switched connection by itself once it is in the 2G/3G
network.
The eNodeB-B has the possibility to request 2G/3G measurements from the
device to have a better idea as to which cell to hand over the mobile to, or it can do
so blindly by sending it information about a preconfigured cell.
Once the mobile device is in the 2G or 3G cell, it answers to the initial paging via
the legacy cell. In case the MME has made a mistake and the legacy cell is in a
location area different from where the device was registered in the preparation
phase, the specification also contains a mechanism to first perform a location
update and then reroute the waiting voice call inside the same MSC or even to an
entirely different MSC.
22
The Execution Phase: Mobile-Originated Call
This procedure is similar to the mobile-terminated example above. The difference

is that no paging is sent by the network, unlike in the case of an incoming call, and
there is no paging response to the
MSC after the device is in the legacy cell.
SMS and Call-Independent Supplementary Services (CISS)
For receiving SMS text messages, the mobile device can remain in the LTE
network as the text message is forwarded by the MSC to the MME via the SGs
interface and from there via RRC signaling over the LTE radio network to the
mobile device. Sending text messages works in a similar way and hence there is
also no need to fall back to a legacy network.
For call-independent supplementary services (CISS) such as changing call
forwarding configuration, checking prepaid balance via USSD messaging, etc., a
fallback to the legacy network is required.
While only the support of the SGs interface has to be added to the circuit-
switched core network, the solution is relatively simple to implement. However,
there are a number of significant drawbacks.
These include
The fallback to a GSM or UMTS network takes several seconds, which needs to
be added to an already increased call setup time compared to fixed-line networks.
This has a negative impact on the overall user experience compared to fixed-line
networks and mobile voice calls established in GSM or UMTS networks.
If a GSM network is used for the voice call, no packet-switched services can be
used during the conversation as most GSM networks do not support the dual
transfer mode (DTM) functionality for simultaneous voice and data transmission.
In addition, even if DTM is supported, data rates will be very low compared to
those in the LTE network.
If a UMTS network is used for a voice call, it is optionally possible to move an
ongoing data session from LTE to UMTS during the fallback procedure. However,
this takes additional time.
After the voice call, the mobile device has to return to the LTE network that again
consumes many seconds, during which time no data transfers can take place.
23
The CSFB Problems

An immediate problem with CSFB is that operators are faced with making
additional capital investment in their legacy core network. CSFB, as defined in
3GPP TS 23.272, introduces the new SGs interface between CSFB enabled MSCs
and LTE MMEs and hence an MSC upgrade is a prerequisite to introducing CSFB;
unless MSC pooling is used this upgrade potentially must be to all MSCs in the
network.
CSFB also introduces ongoing operational complexity as to minimize the
likelihood of roaming retry the TA (Tracking Area) to LA (Location Area)
mapping needs to be maintained in the MME. This mapping is required as it is used
by the MME to attempt to predict which MSC a UE would attach if CSFB were
invoked in the event of a mobile terminating call. This mapping needs to be as
accurate as possible; however, some operators state that it is impossible to maintain
an accurate TA-LA mapping and as such impossible to avoid roaming retry with its
detrimental impact on customer experience. Furthermore, roaming retry is not
widely supported in networks and introducing support would be yet another
investment in the legacy core network
2.4.2 VoLGA - Voice over LTE via Generic Access
The VoLGA service resembles the 3GPP Generic Access Network (GAN).
GAN provides a controller node - the GAN controller (GANC) - inserted

between the IP access network (i.e., the EPS) and the 3GPP core network. The
GAN provides an overlay access between the terminal and the CS core without
requiring specific enhancements or support in the network it traverses. This
provides a terminal with a 'virtual' connection to the core network already deployed
by an operator. The terminal and network thus reuse most of the existing
mechanisms, deployment and operational aspects.
According VoLGA specifications, the aim of VoLGA is to make traditional

GSM/UMTS circuit switched (CS) services available to UEs accessing the EPS
network via E-UTRAN.
GAN services and goals are reused in VoLGA wherever beneficial, and no re-
invention of existing functionality shall occur.
24
VoLGA supports two modes of operation:
VoLGA A-mode
VoLGA Iu-mode
VoLGA A-mode supports an extension of GSM CS services that is achieved by

tunneling Non Access Stratum (NAS) protocols between the UE and the Core
Network over EPS bearers and the A interface to the MSC.
VoLGA Iu-mode supports an extension of UMTS CS services that is achieved by

tunneling Non Access Stratum (NAS) protocols between the UE and the Core
Network over EPS bearers and the Iu-CS interface to the MSC.
VoLGA Overview
VoLGA as described in the VoLGA Stage 2 specification. The only new network
element introduced is the Voice over Long-Term Evolution via Generic Access
Network Controller (VANC).
On the LTE side, the VANC connects to the PDN-GW via the standard SGi
interface. Both signaling and user data traffic (i.e. the voice packets) are transported
over this interface. From an LTE core network point of view, the VANC looks like
any other IP-based external node and IP packets exchanged between a wireless
device and the VANC are transparently forwarded through the core network.
On the circuit-switched network side, the GSM A-interface or the UMTS Iu-
interface is used to connect the VANC to a GSM MSC. As the A- and Iu interfaces
are used without any enhancements, the MSCs are not aware that the mobile
devices are not directly connected via their respective radio networks but are
instead connected over LTE. As a result, no changes are required on these network
nodes to support voice, SMS and other services over the LTE network.
Although there had been talks about another approach for CS Fallback by
VoLGA which does not require any enhancement in existing CS elements like
MSC but for VoLGA another set of additional nodes are needed.
25
2.4.3 IP Multimedia Subsystem IMS
The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem

(IMS) is an architectural framework for delivering IP multimedia services.
Historically, mobile phones have provided voice call services over a switched-
circuit-style network, rather than strictly over an IP packet-switched network.
Alternative methods of delivering voice or other multimedia services over IP have
become available on smartphones (e.g. VoIP or Skype), but they have not become
standardized across the industry. IMS is an architectural framework to provide such
standardization.
IMS was originally designed by the wireless standards body 3rd Generation
Partnership Project (3GPP), as a part of the vision for evolving mobile networks
beyond GSM. Its original formulation (3GPP Rel-5) represented an approach to
delivering "Internet services" over GPRS. This vision was later updated by 3GPP,
3GPP2 and ETSI TISPAN by requiring support of networks other than GPRS, such
as Wireless LAN, CDMA2000 and fixed lines.
To ease the integration with the Internet, IMS uses IETF protocols wherever
possible, e.g., SIP (Session Initiation Protocol). According to the 3GPP, IMS is not
intended to standardize applications, but rather to aid the access of multimedia and
voice applications from wireless and wireline terminals, i.e., to create a form of
fixed-mobile convergence (FMC). This is done by having a horizontal control layer
that isolates the access network from the service layer. From a logical architecture
perspective, services need not have their own control functions, as the control layer
is a common horizontal layer. However in implementation this does not necessarily
map into greater reduced cost and complexity.
Alternative and overlapping technologies for access and provisioning of services

across wired and wireless networks include combinations of Generic Access
Network, soft switches and "naked" SIP.
Since it is becoming increasingly easier to access content and contacts using

mechanisms outside the control of traditional wireless/fixed operators, the interest
of IMS is being challenged.
An example of a global standard based on IMS is MMTel.
26
History of IMS
IMS was originally defined by an industry forum called 3G.IP, formed in 1999.
3G.IP developed the initial IMS architecture, which was brought to the 3rd
Generation Partnership Project (3GPP), as part of their standardization work for 3G
mobile phone systems in UMTS networks. It first appeared in Release 5 (evolution
from 2G to 3G networks), when SIP-based multimedia was added. Support for the
older GSM and GPRS networks was also provided.[3]
3GPP2 (a different organization from 3GPP) based their CDMA2000

Multimedia Domain (MMD) on 3GPP IMS, adding support for CDMA2000.
3GPP release 6 added interworking with WLAN, inter-operability between IMS

using different IP-connectivity networks, routing group identities, multiple
registration and forking, presence, speech recognition and speech-enabled services
(Push to talk).
3GPP release 7 added support for fixed networks by working together with
TISPAN release R1.1, the function of AGCF (access gateway control function) and
PES (PSTN emulation service) are introduced to the wire-line network for the sake
of inheritance of services which can be provided in PSTN network. AGCF works as
a bridge interconnecting the IMS networks and the Megaco/H.248 networks.
Megaco/H.248 networks offers the possibility to connect terminals of the old
legacy networks to the new generation of networks based on IP networks. AGCF
acts a SIP User agent towards the IMS and performs the role of P-CSCF. SIP User
Agent functionality is included in the AGCF, and not on the customer device but in
the network itself.
Also added voice call continuity between circuit switching and packet switching
domain (VCC), fixed broadband connection to the IMS, interworking with non-
IMS networks, policy and charging control (PCC), emergency sessions.
27
2.4.3.1 VoLTE with IMS Architecture
Figure 3: VoLTE with IMS Architecture
For VoLTE over IMS some changes are made in the EPC
The MME have to be configured
- Indication of IMS Emergency Service and IMS Voice Service availability to

UE
The PLMN configuration in the MME must be modified to indicate that this PLMN
supports VoIP and emergency services for either authenticated UEs or all UEs.
- Indication of IMS Voice service availability to UE

MME is configured for sending to UE the indication of whether to support IMS
voice service or not. It is configured based on geographical areas (GA) for the IMSI
number series.
Evolved Packet Gateway (EPG)
The EPG implements the SGW and PGW functionality in EPC network.
Functions
28
setup of network initiated dedicated bearer

When a UE activates a session towards IMS, P-CSCF contact the
PCRF via Rx interface supplying QoS session requirement in the
form of Session Description Protocol (SDP) information. After the
policy rules for the session are evaluated based on input from the P-
CSCF, the PCRF then asks the EPG via the Gx interface to create a
dedicated bearer. The bearer QoS parameters are QCI, ARP, GBR,
MRB and they are all sent to PGW from the PCRF. The PGW then
initiates the creation of the dedicated bearer
Gating control
The IP filters associated with a dynamic charging rule defines a gate

in EPG PGW. The status of the gate is provided by the PCRF in the
policy decision and it determines whether user traffic matching the
filter is authorized. If the gate is open, the traffic authorized and
allowed to pass. If the gate is closed, the traffic is unauthorized and
dropped.
P-CSCF discovery
When the UE attach to the IMS PDN, the UE usually receives two P-
CSCF addresses, one primary and one secondary from the EPG.
Those addresses are included in the protocol configuration. P-CSCF
addresses are provided from a list of up 10 P-CSCF addresses
configurable in the IMS PDN in the EPG. To provide load sharing the
EPG selects the P-CSCFs addresses in a round-robin manner.
2.4.3.1.1 The role of Call Session Control Function (CSCF)
The Call Session Control function (CSCF) is the heart of the IMS
architecture and is used to process SIP signaling. The main function of the CSCF is
to provide session control for terminals and applications using the IMS network.
Session control includes the secure routing of the SIP messages, subsequent
monitoring of the SIP sessions and communicating with the policy architecture to
support media authorization. It has also the responsibility for interacting with the
HSS. As shown in (Figure 2) CSCF can play three different roles: Serving-,
29
Interrogating and Proxy- Call Session Control Function (S-, I- and P-CSCF).
In AT VoLTE solution only the I-CSCF, the S-CSCF and the BGCF
functions of the CSCF will be used in the solution. The P-CSCF function will be
provided by the SBG.
The Interrogating CSCF (I-CSCF) is the contact point within the home
network.
I-CSCF performs the following functions:
Assigns a S-CSCF to a users registration request

Assigns a S-CSCF to handle a request for an unregistered user
Obtains the S-CSCF address from HSS for a registered user
Forwards SIP requests destined to a Public Service Identity PSI and
Wildcard Public Service Identity wPSI hosted by application servers
directly to the application server.
The Serving CSCF (S-CSCF) performs the session control services for the
UE. It maintains a session state for support of the services. S-CSCF performs the
following functions:
Acts as a registrar according RFC3261 at registration

Notify subscribers about registration changes
Session control for the registered users sessions
Handles SIP requests and services them internally or forwards them on
Interaction with application servers
The Break-Out Gateway Control Function, BGCF is the logical entity within
the IMS network that
- Manages the sessions initiated in the IMS network and terminated in

PSTN/PLMN network
- Forwards the SIP request to the Algerie Telecom TSS national Media
Gateway Control Function (MGCF) for calls towards the PSTN/PLMN and
TSS international in case of international calls.
30
- The CSCF should support an extended Rf interface for reporting the

control plane information and generating Accounting Charging Records
(ACRs).
2.4.3.1.2 Session Border Gateway (SBG)
The SBG is a High-performance carrier-class session controller product. The

SBG provides the ability to correlate all signaling and media streams (such as audio
and video) that pass the network borders, hence providing a comprehensive suite of
functions required to access and interconnect IP core domains (ex:IMS) and other
IP networks with preserves security, privacy, and quality of service.
The SBG ensures network security, bandwidth fraud protection, technology

hiding, Quality of Service (QoS), service level agreements hosted NAT/FW
traversal, address, port translation, and IP version interworking. Furthermore, the
SBG enables access network connection admission control, and functionality for
handling geographical redundancy of other nodes. SBG can also control and initiate
transcoding of voice media streams from one codec to another, to allow calls
between UEs with incompatible codec support to be successful.
SBG is the controlling node for the BGF, via H.248 over the Ia interface.
SBG and BGF transcoding is invoked in VoLTE calls when a common codec
between A and B subscribers is not possible. This is the case in AT for call between
VoLTE and wireline. SBG performs codec negotiation and informs about the
selected codecs to BGF over the Ia-interface (proactive transcoding). When
selected codecs are different on the incoming and outgoing side of the BGF, it will
perform transcoding between indicated codecs.
2.4.3.1.3 MMTel Application Server (MTAS)
MTAS is Ericssons application server for multimedia Telephony. It

provides multimedia telephony service and supplementary services according to
3GPP and GSMA standards for VoLTE.
Ericsson MTAS consists of several functional components described below.
- Session control and service interaction
31
MMTel AS is involved in the both originating and terminating MMTel

signaling sessions and acts as SIP Back-to-Back User Agent.
- Services
All services logic of MMTel AS is abstracted from the supporting functions
like subscriber data handling, media handling and charging. Each services, like for
example Communication hold and communication diversion, is implemented in a
separate functional component. The service invocation layer handles in which order
each service is invoked.
- Subscriber data handler

The main purpose of subscriber data handling in MTAS is to fetch the
subscription data relevant for MTASs services from the HSS and cache it so that is
available when needed by the services.
- Media Handler
MTAS is a pure signaling node therefore it doesnt handle any media streams.
For media control, it uses its internal Media Resources Function Control (MRFC)
to control the external MRFP provides by MRS HW through H.248 protocol.
Media handling operations are invoked by request from MTAS services.
2.4.3.1.4 Media Resource System (MRS)
Media Resource System (MRS) is a high performance carrier class product,

which provides the converged media plane functionality in IMS networks, In AT
VoLTE MRS HW supports BGF and MRFP functionalities and deployed on three
sites Algiers, Oran and Constantine.
The BGF provides the security and policy control for the media plane
between IMS core and access network.
The BGF is controlled by the Session Gateway Controller (SGC) of SBG

over a text based H.248 interface (Iq interface).
The Multimedia Resource Function Processor (MRFP) provides media

services in IMS networks such as announcements, audio and video conferencing
and media processing.
32
The MRFP is controlled by MTAS over H.248 protocol (Mp interface).
2.4.3.1.5 Home Subscriber Server (HSS)
HSS provides user mobility management, session establishment procedures,

authentication, and user traffic protection and authorization support for IMS.
HSS nodes have been already deployed for EPC/LTE and running ESM and AVG
modules. Additionally HSS will be extended to support ISM and SDA modules to
support VoLTE users subscriptions and services.
IMS subscription Manager (ISM) module

The ISM module keeps the appropriate mapping between the private identity
identifying the VoLTE user and the public user and the public identities used for
sessions. The ISM module also handles the user charging Identity for IMS
accounting.
The ISM module defines service profiles that can be shared among all users, thus
reducing provisioning work to define services.
Subscription Data Access (SDA) module

The SDA module provides application layer support.
The SDA module offers IMS user data to the applications according to procedures
defined in 3GPP specifications. Application servers can read IMS user data in the
HSS through the Sh interface. This includes but not limits to IMS Public Identity,
IMS user state, S-CSCF name, Initial filter criteria and charging information.
SDA module allows the storage of application-specific data. These transparent data
are understood syntactically but not semantically by HSS. It is data that an AS may
store in HSS to support its service logic. Application servers can read and update
information in the SDA module through the Sh interface.
2.4.3.1.6 Media Gateway Control Function (MGCF)
The Media Gateway Control Function (MGCF) is the central node of the
33
PSTN gateway. The MGCF is responsible for controlling the media resources used
when traffic needs to flow between networks using different media, typically
between a Time Division Multiplexing (TDM) network and an IP-based network. It
interacts with: the call and session control functions using SIP; the control plane of
the GSTN using ISUP; and with the Media Gateway using the H.248 protocol.
2.4.3.1.7 Media Gateway (MGW)
The Media Gateway (MGW), controlled by the MGCF using H.248, is

responsible for providing the interworking of media flows between different
networks. It provides interworking between the different media transport formats,
RTP/UDP/IP and TDM, as well as media transcoding of voice and video, if
required.
2.4.4 Key protocols used in the IMS network
2.4.4.1 Session Initiation Protocol (SIP)
SIP is the main signaling protocol used in IMS networks. It was

developed by the IETF and was selected by 3GPP as a standard for IMS in Release
5. The function of SIP is to establish, modify and terminate multimedia sessions
with medias such as voice, video and chat over IP networks, where the media
delivery part is handled separately.
In SIP there is just one single protocol, which works end-to-end and supports
the establishment and termination of user location, user availability, user capability,
session set-up and session management. SIP is also designed to enable additional
multimedia sessions and participants to be dynamically added or removed from a
session. These are the major reasons SIP has been selected in IMS; it is also
considered to be flexible and secure.
SIP has a number of capabilities :

Session control for multimedia sessions (multimedia session may be
voice, video, data or whatever session). An example of a data session is a chat
34
session. SIP enables establishing, modifying and terminating a multimedia session.

A session may be started with the audio media only and be modified to support
audio and video (video-telephony).
-like architecture : The extensive capabilities
provided by the existing IN architecture can be supported by SIP to enable the
introduction of enhanced services such as customized ring back tone, IP Centrex,
SIP trunking, Rich communications suite, etc.
the SIP protocol. Examples of supplementary services are call forward, call
transfer, call hold, calling line identity presentation, calling line identity restriction,
call completion on busy subscriber, conferencing. In a PSTN network, ISUP
signaling protocol provides supplementary services.
exchange short text messages in real time, in contrast to E-mail that is a store an
forward communication, well suited for large messages and attachments. While
some E-mail may take considerable time to reach the destination, instant messages
are transferred in real time and are well suited for interactive. The advantage of
using SIP for presence and instant messaging lies in the common infrastructure
with many other communication services.
one of the unique features of SIP and is basically a by-product of the similarity of
SIP with HTTP and SMTP. By redirecting incoming calls to any of the user
devices, users can be reachable irrespective of location and device. Service
mobility means that the user can get his services from any registration point even
when he is in a visited network. The services follow the user movement. Session
mobility means that the session can be moved from one network to another
network. For example a 4G user may start his VoIP session with 4G coverage
which continues in 2G or 3G where a circuit switched domain need to handle that
call.
information: SIP carries all the information
to authenticate and charge the user.
However, the following capabilities are not supported by SIP:
session control protocol and not a bearer control protocol.
amounts of data. It is designed to transport small amounts of data required to setup
35
multimedia communications. Small amounts of data not related to call setup, such
as short text messages for instant messaging are also well suited for SIP.
established. For example, it is not designed to exercise floor control in conference

sessions. Extra control protocols are required.
by the mobile packet switched domain.
2.4.4.2 Diameter the Authentication, Authorization, and

Accounting protocol
Diameter, a development of the current RADIUS protocol, was chosen as

the policy support and Accounting, Authentication, Authorization (AAA) protocol
for IMS. Diameter is used by the S-CSCF, I-CSCF and the SIP application servers
in the Service Layer, and in their exchanges with the HSS containing the user and
subscriber information. Compared with RADIUS, Diameter has improved transport
it uses Transmission Control Protocol (TCP) or Stream Control Transmission
Protocol (SCTP), and not UDP, as transport improved proxy, enhanced session
control and higher security.
2.4.4.3 H.248 media control protocols
H.248 is a control protocol used between media control functions and media
resources. Examples of nodes with media control functions are the Media Gateway
Control Function (MGCF) and Media Resource Function Controller (MRFC).
Typical media resources are the Media Gateway and Media Resource Function
Processor (MRFP).
2.4.4.4 IPv6
Internet Protocol version 6 (IPv6) is a network-layer IP standard used by

devices to exchange data across a packet-switched network. It follows IPv4 as the
second version of the Internet Protocol to be formally adopted for general use.
Originally, IMS was specified to use IPv6; however, with 3GPP Release 6, IMS
does provide support for IPv4 and private address scheme. This means that even
though IMS is expected to drive the adoption of IPv6, it is not dependent on IPv6
availability in order to be successfully launched.
36

Originating Side
A VoLTE UE, shall perform call establishment by using the IMS network.
The IMS Signalling shall be sent over the default bearer, and a new dedicated
bearer shall be dynamically established for the voice traffic
Figure 4: Basic VoLTE UE to VoLTE UE Voice Call Establishment Originating

Side
NOTE: The Diameter Agent has not been included in this message sequence,
although Diameter messages shall route via the Diameter Agent.
NOTE: The figure shows the PCRF being invoked only once on receipt of the of
the SDP answer (uplink & downlink configuration); this is sufficient if the UE is
37
using preconditions as mandated in GSMA IR.92. It is also possible to invoke the

PCRF twice, i.e. on receipt of both the SDP Offer (downlink configuration) and
SDP Answer (uplink configuration). Both options are valid - see 3GPP TS 29.213
annex B.
NOTE: This figure shows a double offer/answer exchange supporting preconditions

and utilising the segmented status type as defined in RFC 3312 and described in
3GPP TS 24.229 clauses 5.1.3 and 6.1.2.
NOTE: The PRACK and 200 OK (PRACK) messages also traverse through the AS
but this is not shown.
Detailed Description
When a VoLTE UE originates a voice call from LTE, it executes the normal mobile
origination procedure as defined in 3GPP TS 23.228 [5] section 5.6.2.
The VoLTE UE initiates a SIP INVITE request, containing the SDP offer with IMS
media capabilities as specified in GSMA PRD IR.92 [54] section 3. The SDP offer
shall contain the AMR Narrowband codec, and it is recommended that the AMR
Wideband codec is included to provide support for HD Voice and shall indicate
that local preconditions for QoS are desired but not yet met, using the segmented
status type (as defined in RFC 3312 [70]) and that the media stream is set to
inactive as described in 3GPP TS 24.229 ([9]) clause 6.1.2 The desired QOS for the
remote end are set to none as the originating UE is unaware of the QOS
requirements at the terminating side. The request is sent to the P-CSCF that was
discovered during the registration procedure. The INVITE request contains:-
Within the Contact header and the P-Preferred-Service header, the IMS
Communication Service Identifier's (ICSI) for IMS Multimedia Telephony:-
urn:urn-7:3gpp-service.ims.icsi.mmtel
The IMS Public User Identity of the calling-party in one of the forms below:-
Alphanumeric SIP-URI: e.g. user@example.com
MSISDN as a SIP-URI: e.g. sip:+213471004578@djaweb.com;user=phone
MSISDN as Tel-URI: e.g. tel:+213471004578
o P-Access-Network-Info with:-
access-type= 3GPP-E-UTRAN-FDD or 3GPP-E-UTRAN-TDD
UTRAN-cell-id-3gpp parameter
38
Request-URI set to the SIP-URI or tel-URI of the called-party.

Within the Supported header, the P-Early-Media, 100rel& precondition option
tags are present. The timer option tag may also be present when SIP keep-alives
are supported.
etc.
The P-CSCF adds the P-Charging-Vector header and forwards the SIP INVITE to
the S-CSCF that was identified during the registration process.
If an IMS-ALG/AGW is deployed, then the P-CSCF will also invoke the IMS-
AGW over the Iq reference point to provide appropriate resources in the media
plane. The IMS-AGW is an IP-IP GW and serves as a border element in the media
plane in an IMS network at the access side. .
The P-CSCF forwards the SIP INVITE to the S-CSCF The offered SDP address
shall reflect the media pin-hole created in the IMS-AGW if applicable.
The S-CSCF receives the SIP INVITE from the P-CSCF, and invokes any VoLTE
services as triggered by the initial filter criteria within the subscriber profile that
was received during the IMS Registration. The S-CSCF checks the P-Preferred-
Service header in the SIP INVITE (e.g. MMTel ICSI) and verifies that the user is
authorised for the service by validating against the subscribed services that were
retrieved in the service profile during IMS Registration (Core Network Service
Authorisation Service ID). If the MMTel ICSI is not in the subscribed services,
the INVITE request shall be rejected (403 Forbidden). If validated, the S-CSCF
then adds the ICSI into the P-Asserted-Service header, and removes the P-
Preferred-Service header. Due to service logic within the user profile, and the
identification of the call as a VoLTE call (i.e. MMTel ICSI), the S-CSCF shall
route the SIP INVITE to the MTAS at this point to invoke VoLTE supplementary
services. The MTAS invokes any supplementary service logic and routes the SIP
INVITE to the S-CSCF. The S-CSCF determines that the Called-Party is within the
home network (i.e. ENUM/DNS lookup/internal configuration) and routes the SIP
INVITE to the I-CSCF to determine the terminating S-CSCF of the Called-Party.
The called party's VoLTE UE will return an SDP answer in a SIP 183 Progress
message. The SDP answer should contain only one codec and indicates that
preconditions are also desired but not yet met at the terminating end and that a
confirmation should be sent when QOS preconditions have been met at the
39
originating side and that the media stream is inactive. This message is received by
the S-CSCF and forwarded to the P-CSCF. The P-CSCF uses the SDP answer to
configure the IMS-AGW if deployed.
In addition, the P-CSCF analyses the SDP in the SDP Answer and sends the
Authorize/Authenticate-Request message to the PCRF with the related service
information (IP address, port numbers, information on media-type). The PCRF
authorises the request and associates the service information with the stored
subscription related information containing the information about the allowed
service(s), QoS information and PCC Rules information. The PCRF identifies the
affected IP-CAN session (e.g. default bearer) that has been established during the
LTE Attach procedure, and initiates a Re-Auth-Request to the PGW to initiate the
creation of a dedicated bearer for voice with the related QoS parameters (QCI=1,
ARP) and the related traffic flow template. The PCRF shall also subscribe to
modifications related to the dedicated bearer in the PGW (e.g. indication of release
of Bearer, etc.).
The PGW acknowledges the Re-Auth-Request to the PCRF, which then

acknowledges the Authorize/Authenticate-Request message sent from the P-CSCF.
At this point the IMS SIP session and the dedicated bearer used for voice are bound
together via PCC.
The PGW sends the Create Bearer Request to the SGW to create the dedicated
bearer for VoLTE media. This message contains the dedicated bearer identity,
Linked Bearer Identity to identify the associated default bearer, the traffic flow
template, and the associated QoS parameters (QCI=1, ARP, GBR and MBR), etc.
The SGW sends the request to the MME.
The MME sends a Bearer Setup Request message to the eNodeB with the dedicated
bearer identity, Linked Bearer Identity, the traffic flow template, and the associated
QoS parameters in order to activate the dedicated bearer for voice traffic.
The eNodeB maps the QoS parameters to those required for the radio bearer, and
then signals a RRC Connection Reconfiguration to the UE. The UE stores the
dedicated bearer identity and links the dedicated bearer to the default bearer
indicated by the Linked EPS Bearer Identity. The UE binds the TFT and associated
QoS parameters to the dedicated bearer, and acknowledges the request to the
eNodeB, which then acknowledges the Bearer Request Setup to the MME.
40
The MME sends the Create Bearer Response message to the SGW to acknowledge
the bearer activation. The message includes the dedicated bearer identity and User
Location Information (ECGI). This is then forwarded to the PGW.
The P-CSCF forwards the SIP 183 Progress response to the VoLTE UE. This
message shall also utilize 100rel and the originating UE shall generate a PRACK
which is transited to the terminating side of the call with an associated 200 OK
(PRACK) being received.
The VoLTE UE shall reserve internal resources to reflect the SDP answer and shall
confirm resource reservation by sending a SIP UPDATE message with a new SDP
Offer confirming the selected codec, that local preconditions have been met at the
originating end (due to the establishment of the dedicated bearer) and that the
media stream is now set to active. The UPDATE message is forwarded via the P-
CSCF and S-CSCF to the terminating leg of the call. Note that if the SDP Answer
in the 183 Progress message contained more than one voice codec, then the UE
would ensure only a single codec from that multiple list was included in the new
Offer in the UPDATE message (as described in clause 6.1.2. of 3GPP TS 24.229.
The 200 OK (UPDATE) response is received from the terminating leg of the call
containing the SDP answer containing a single voice codec and confirming that
preconditions are also met at the terminating side and that the media stream is
active. This message is passed onto the originating UE via the S-CSCF and P-
CSCF.
As preconditions have been met, the terminating UE is now alerted and shall send a
SIP 180 (Ringing) response that is received by the S-CSCF and onto the P-CSCF
and originating UE.
The P-Early-Media header is not present in the SIP 180 Ringing message and so the
UE will generate local ring tone to the subscriber. This message shall not utilize
100rel as there is no SDP within the message.
When the called party's VoLTE UE has answered the call, it sends a 200 OK to the
calling party VoLTE UE. This is received by the S-CSCF and forwarded to the P-
CSCF. The P-CSCF invokes the PCRF with an AAA message to enable both the
uplink and downlink of the dedicated bearer. In turn the PCRF invokes the P-GW
with a RAR message to enable the media flows at the P-GW. The P-CSCF (IMS-
41
ALG) invokes the IMS-AGW (if deployed) to ensure that duplex media can be
conveyed via IMS-AGW at this point.
The P-CSCF forwards the SIP 200 OK (INVITE) to the VoLTE UE.
The VoLTE UE receives the 200 OK, and sends a SIP ACK message to
acknowledge that the call has been established.
At this stage, the VoLTE UE has a call established with voice traffic sent over the
dedicated bearer and via the IMS-AGW. The IMS Signalling is sent over the
default bearer. Support of Robust Header Compression is mandated and described
in GSMA PRD IR.92.

Terminating Side
A VoLTE UE shall receive a call via IMS network. The IMS Signalling shall
be sent over the default bearer, and a new dedicated bearer is established by the
network for the voice traffic.
42
Figure 5: Basic VoLTE UE to VoLTE UE Voice Call Establishment Terminating

Side
When a VoLTE UE receives an incoming voice call request, it executes the normal
mobile termination procedure.
The S-CSCF receives a SIP INVITE containing an SDP Offer with IMS media
capabilities as specified in GSMA PRD IR.92 section 3. The SDP offer shall
contain the AMR Narrowband codec, and optionally the AMR Wideband codec.
The SDP indicates that preconditions are applicable and that QOS preconditions are
desired but not yet reserved at the originating side. The media stream is set to
inactive.
The S-CSCF invokes any VoLTE services as triggered by the initial filter criteria
within the subscriber profile that was received during the IMS Registration. The S-
43
CSCF shall route the SIP INVITE to the MTAS at this point to invoke VoLTE
supplementary services. The MTAS invokes any supplementary service logic and
routes the SIP INVITE to the S-CSCF. The S-CSCF routes the SIP INVITE to the
terminating P-CSCF that was associated to the subscriber during IMS registration.
If an IMS-ALG/AGW is deployed, then the P-CSCF (IMS-ALG) invokes the IMS-

AGW to reserve resources for the media connection. In this event, the SDP address
in the INVITE is over-written to reflect the media pin-hole created on the IMS-
AGW.
The P-CSCF forwards the SIP INVITE to the VoLTE UE. When the VoLTE UE
receives the SIP INVITE it shall allocate resources for the call and select one voice
codec from the SDP Offer (as described in section 6.1.3 of 3GPP TS 24.229 ([9]).
The UE shall send a SIP 183 Progress response containing the SDP Answer. The
message shall indicate that 100rel is required. The SDP Answer indicates that QOS
preconditions are desired but not yet met at the terminating side of the call. In
addition, the SDP shall indicate that the originating side should confirm when its
local QOS preconditions have been met.
On receipt of the SIP 183 Progress message, the P-CSCF updates the IMS-AGW if
applicable with the SDP answer from the UE and sends the
Authorize/Authenticate-Request message to the PCRF with the related updated
service information (IP address, port numbers, information on media-type). The
PCRF authorises the request and associates the service information to the stored
subscription related information containing the information about the allowed
service(s), QoS information and PCC Rules information. The PCRF identifies the
affected IP-CAN session (e.g. default bearer) that has been established during the
LTE Attach procedure, and initiates a Re-Auth-Request to the PGW to initiate the
creation of a dedicated bearer for voice with the related QoS parameters (QCI=1,
ARP) and the related traffic flow template. The PCRF shall also subscribe to
modifications related to the dedicated bearer in the PGW (e.g. Loss of Bearer,
Indication of release of Bearer, etc.).
The PGW acknowledges the Re-Auth-Request to the PCRF, which then

acknowledges the Authorize/Authenticate-Request message sent from the P-CSCF.
At this point the IMS SIP session and the dedicated bearer used for voice are bound
together via PCC.
44
The PGW sends the Create Bearer Request to the SGW to create the dedicated
bearer for VoLTE media. This message contains the dedicated bearer identity,
Linked Bearer Identity to identify the associated default bearer, the traffic flow
template, and the associated QoS parameters (QCI=1, ARP, GBR and MBR), etc.
The SGW sends the request to the MME.
The MME sends a Bearer Setup Request message to the eNodeB with the dedicated
bearer identity, Linked Bearer Identity, the traffic flow template, and the associated
QoS parameters in order to activate the dedicated bearer for voice traffic.
The eNodeB maps the QoS parameters to those required for the radio bearer, and
then signals a RRC Connection Reconfiguration to the UE. The UE stores the
dedicated bearer identity and links the dedicated bearer to the default bearer
indicated by the Linked EPS Bearer Identity. The UE binds the TFT and associated
QoS parameters to the dedicated bearer, and acknowledges the request to the
eNodeB, which then acknowledges the Bearer Request Setup to the MME.
The MME sends the Create Bearer Response message to the SGW to acknowledge
the bearer activation. The message includes the dedicated bearer identity and User
Location Information (ECGI). This is then forwarded to the PGW.
On receipt of the AAA response from the PCRF, the P-CSCF will convey the SIP
183 Progress (SDP) message to the S-CSCF. The contained SDP reflects the
address of the media pin hole in the IMS-AGW if applicable.
The PRACK message is transited from the originating side of the call.
The terminating side sends a 200 OK (PRACK) in response to the PRACK.
A second SDP Offer is now received from the originating leg of the call in a SIP
UPDATE message indicating that preconditions have been met at the originating
side and that the media stream is active.
The UPDATE is passed to the UE via the S-CSCF and P-CSCF. The UE sends a
200 OK (UPDATE) response containing a SDP Answer confirming that QOS
preconditions are also satisfied at the terminating side (due to the establishment of
the dedicated bearer) and that the media stream is active. The 200 OK (UPDATE)
message is sent to the originating leg of the call via the P-CSCF and S-CSCF.
45
As preconditions are now met at both ends, the UE will alert the user and send a
SIP 180 Ringing response. This message does not contain SDP and so will not
utilize 100rel. The P-Early-Media header is not present in this message.
The SIP 180 Ringing response is sent to the originating leg via the P-CSCF and S-
CSCF.
When the call is answered, the VoLTE UE shall send a SIP 200 OK (INVITE)
message to the P-CSCF.
The P-CSCF invokes the PCRF with an AAA message to enable both the uplink
and downlink of the dedicated bearer to reflect the SDP exchange. In turn the
PCRF invokes the P-GW with a RAR message to enable the media flows at the P-
GW.
The P-CSCF (IMS-ALG) shall also invoke the IMS-AGW to if applicable ensure
that duplex media can traverse the IMS-AGW.
The 200 OK is forwarded to the S-CSCF and then to the originating side of the call.
At this stage, the VoLTE UE has a call established with voice traffic sent over the
dedicated bearer via the IMS-AGW. The IMS Signalling is sent over the default
bearer. Support of Robust Header Compression is mandated and described in
GSMA PRD IR.92.
2.5 Voice over IP (VoIP)
VOIP or Voice over Internet Protocol (IP) is a telephony system that provides voice
telephone calls over IP data networks. The main feature of this IP-based technology
is that it sends conversations as data (or IP) packets over the Internet.
Currently, it is playing a vital role in replacing today's (TDM-based) telephony

infrastructure. This advanced telephony brings benefits to both consumers as well
as enterprise (or commercial) customers. The main reason for migrating to VOIP is
to reduce the (residential and commercial) voice communication cost.
VoIP and IP telephony are becoming increasingly popular with large corporations
and consumers alike. For many people, Internet Protocol (IP) is more than just a
way to transport data, it's also a tool that simplifies and streamlines a wide range of
46
business applications. Telephony is the most obvious example. VoIP or voice over
IP is also the foundation for more advanced unified communications applications
including Web and video conferencing.
2.6 Quality of Service (QoS)
2.6.1 General
The service level (i.e., per SDF or per SDF aggregate) QoS parameters are
QCI, ARP, GBR, and MBR.
Each Service Data Flow (SDF) is associated with one and only one QoS Class
Identifier (QCI). For the same IP-CAN session multiple SDFs with the same QCI
and ARP can be treated as a single traffic aggregate which is referred to as an SDF
aggregate. An SDF is a special case of an SDF aggregate. The QCI is scalar that is
used as a reference to node specific parameters that control packet forwarding
treatment (e.g. scheduling weights, admission thresholds, queue management
thresholds, link layer protocol configuration, etc.) and that have been pre-
configured by the operator owning the node (e.g. eNodeB).
2.6.2 Standardized QCI characteristics

This clause specifies standardized characteristics associated with
standardized QCI values. The characteristics describe the packet forwarding
treatment that an SDF aggregate receives edge-to-edge between the UE and the
PCEF (see figure below) in terms of the following performance characteristics:
1- Resource Type (GBR or Non-GBR);
2- Priority;
3- Packet Delay Budget;
4- Packet Error Loss Rate.
47
Figure 6: Standardized QCI characteristics for client/server

3
The standardized characteristics are not signalled on any interface. They

should be understood as guidelines for the pre-configuration of node specific
parameters for each QCI. The goal of standardizing a QCI with corresponding
characteristics is to ensure that applications / services mapped to that QCI receive
the same minimum level of QoS in multi-vendor network deployments and in case
of roaming. A standardized QCI and corresponding characteristics is independent
of the UE's current access (3GPP or Non-3GPP).
The one-to-one mapping of standardized QCI values to standardized
characteristics is captured in the Table below:
48
QCI Resource Priority Packet Packet Example Services

Type Level Delay Error Loss
Rate
Budget
(NOTE 2)
-2
1 2 100 ms 10 Conversational Voice
(NOTE 3) (NOTE 1)
-3
2 4 150 ms 10 Conversational Video (Live
(NOTE2) (NOTE 1) Streaming)
-3
3 3 50 ms 10 Real Time Gaming
GBR
(NOTE 3) (NOTE 1)
-6
4 5 300 ms 10 Non-Conversational Video
(NOTE 3) (NOTE 1) (Buffered Streaming)
-2
65 0.7 75 ms 10 Mission Critical user plane Push
(NOTE 9) (NOTE 7, To Talk voice (e.g.,
NOTE 8) MCPTT)
-2
66 2 100 ms 10 Non-Mission-Critical user plane
(NOTE 7, Push To Talk voice
NOTE 8)
-6
5 1 100 ms 10 IMS Signalling
(NOTE 3) (NOTE 1)
-6
6 6 300 ms 10 Video (Buffered Streaming)
(NOTE 4) (NOTE 1) TCP-based (e.g., www, e-mail,
Non-GBR chat, ftp, p2p file
sharing, progressive video, etc.)
-3
7 7 100 ms 10 Voice,
(NOTE 3) (NOTE 1) Video (Live Streaming)
Interactive Gaming
8 8 Video (Buffered Streaming)
-6
(NOTE 5) 300 ms 10 TCP-based (e.g., www, e-mail,
9 9 (NOTE 1) chat, ftp, p2p file sharing,
(NOTE 6) progressive video, etc.)
-6
69 0.5 60 ms 10 Mission Critical delay sensitive
(NOTE 9) (NOTE 7) signalling (e.g., MCPTT
signalling)
-6
70 5.5 200 ms 10 Mission Critical Data (e.g.
(NOTE 7) example services are the
same as QCI 6/8/9)
Tableau 1: Standardized QCI characteristics
49
NOTE 1: A delay of 20 ms for the delay between a PCEF and a radio base station
should be subtracted from a given PDB to derive the packet delay budget
that applies to the radio interface. This delay is the average between the
case where the PCEF is located "close" to the radio base station (roughly
10 ms) and the case where the PCEF is located "far" from the radio base
station, e.g. in case of roaming with home routed traffic (the oneway
packet delay between Europe and the US west coast is roughly 50 ms).
The average takes into account that roaming is a less typical scenario. It
is expected that subtracting this average delay of 20 ms from a given
PDB will lead to desired end-to-end performance in most typical cases.
Also, note that the PDB defines an upper bound. Actual packet delays -
in particular for GBR traffic - should typically be lower than the PDB
specified for a QCI as long as the UE has sufficient radio channel
quality.
NOTE 2: The rate of non-congestion related packet losses that may occur between
a radio base station and a PCEF should be regarded to be negligible. A
PELR value specified for a standardized QCI therefore applies
completely to the radio interface between a UE and radio base station.
NOTE 3: This QCI is typically associated with an operator controlled service, i.e., a
service where the SDF aggregate's uplink / downlink packet filters are
known at the point in time when the SDF aggregate is authorized. In case
of E-UTRAN this is the point in time when a corresponding dedicated
EPS bearer is established / modified.
NOTE 4: If the network supports Multimedia Priority Services (MPS) then this
QCI could be used for the prioritization of non-real-time data (i.e. most
typically TCP-based services/applications) of MPS subscribers.
NOTE 5: This QCI could be used for a dedicated "premium bearer" (e.g. associated
with premium content) for any subscriber / subscriber group. Also in this
case, the SDF aggregate's uplink / downlink packet filters are known at
the point in time when the SDF aggregate is authorized. Alternatively,
this QCI could be used for the default bearer of a UE/PDN for "premium
subscribers".
NOTE 6: This QCI is typically used for the default bearer of a UE/PDN for non-
privileged subscribers. Note that AMBR can be used as a "tool" to
provide subscriber differentiation between subscriber groups connected
to the same PDN with the same QCI on the default bearer.
50
NOTE 7: For Mission Critical services, it may be assumed that the PCEF is located
"close" to the radio base station (roughly 10 ms) and is not normally used
in a long distance, home routed roaming situation. Hence delay of 10 ms
for the delay between a PCEF and a radio base station should be
subtracted from this PDB to derive the packet delay budget that applies
to the radio interface.
The Resource Type determines if dedicated network resources related to a

service or bearer level Guaranteed Bit Rate (GBR) value are permanently allocated
(e.g. by an admission control function in a radio base station). GBR SDF
aggregates are therefore typically authorized "on demand" which requires dynamic
policy and charging control. A Non GBR SDF aggregate may be pre-authorized
through static policy and charging control.
The Packet Delay Budget (PDB) defines an upper bound for the time that a packet
may be delayed between the UE and the PCEF. For a certain QCI the value of the
PDB is the same in uplink and downlink. The purpose of the PDB is to
support the configuration of scheduling and link layer functions (e.g. the setting of
scheduling priority weights and HARQ target operating points). The PDB shall be
interpreted as a maximum delay with a confidence level of 98 percent.
Services using a Non-GBR QCI should be prepared to experience congestion

related packet drops, and 98 percent of the packets that have not been dropped due
to congestion should not experience a delay exceeding the QCI's PDB. This may
for example occur during traffic load peaks or when the UE becomes coverage
limited. See Annex J for details.
Packets that have not been dropped due to congestion may still be subject to non-
congestion related packet losses.
Services using a GBR QCI and sending at a rate smaller than or equal to
GBR can in general assume that congestion related packet drops will not occur, and
98 percent of the packets shall not experience a delay exceeding the QCI's PDB.
Exceptions (e.g. transient link outages) can always occur in a radio access system
which may then lead to congestion related packet drops even for services using a
GBR QCI and sending at a rate smaller than or equal to GBR. Packets that have not
been dropped due to congestion may still be subject to non-congestion related
packet losses.
51
Every QCI (GBR and Non-GBR) is associated with a Priority level (see
Table abouve). The lowest Priority level value corresponds to the highest Priority.
The Priority levels shall be used to differentiate between SDF aggregates of the
same UE, and it shall also be used to differentiate between SDF aggregates from
different UEs. Via its QCI an SDF aggregate is associated with a Priority level and
a PDB. Scheduling between different SDF aggregates shall primarily be based on
the PDB. If the target set by the PDB can no longer be met for one or more SDF
aggregate(s) across all UEs that have sufficient radio channel quality then Priority
shall be used as follows: in this case a scheduler shall meet the PDB of an SDF
aggregate on Priority level N in preference to meeting the PDB of SDF aggregates
on next Priority level greater than N until the priority N SDF aggregate's GBR (in
case of a GBR SDF aggregate) has been satisfied.
52
CHAPTER
3 Test plan & Services
Chapter 3. Test Plan & Services
3.1 Introduction
The multimedia communication network based on IMS and the standard of

multimedia telephony (MMTel) which provides support for voice over LTE as well
as a set of services telephone basic. IMS/MMTel makes modular multimedia
functions so that users can add or remove services during a communication session.
Operators can provide virtually any service that adds value to the user. The solution
of voice over LTE for Algeria Telecom implements basic telephony services. These
services are a subset of the services offered by standard MMTel MTAS. The subset
was created on the basis of the Algeria Telecom requirements and basic voice
service.
3.2 Presentation of the tools
To test the telephone services of voice over LTE (VoLTE) we need hardware and
software tools which are :
Hardware: Modem 4G (CPE) and phone.
Software:
Xming
Xming This is free software, It integrates a software ssh and X11 graphical server
allowing both to connect to a server via ssh and manage the graphical display of
server applications on a remote workstation * nix, without the need for large
amounts of hard drive space.
Wireshark
It is a network management tool to capture the data stream over a network for
analysis.
By examining the contents of packages, their origin and destination addresses that
crosses the network and the ports.
53
CHAPTER 3. Test Plan & Services
SecureCRT
It is a file transfer means that gives us the tools we need to increase the safety and
efficiency of exchange operations and to synchronize the server. It allows to collect
more easily when transfers fail by automatically resuming multi-file transfers
interrupted.
Procedure: Save steps SecureCRT and SecureFX with integrated. Establish
connections with shared keys and sessions of the host server. Sessions and current
settings reduce repeated steps.
3.3 Test methodology and making traces:
In order to capture the traces that show the routing of packets when establishing a
call or activate one of the telephone services, it must precede the following steps:
a) Connect the computer to O & M network (server) then choose an IP address that
will be specific and different from others.
b) Install the software Xming to gain access to the remote server is done via SSH to
transmit only the display windows through the network guidelines in order to
optimize data transfers that are very well fast.
c) Log on to the server traces "SecureCRSecureFXPortable" with the IP address of

the traces Server as followings:
d) Activate the X11 authentication option to establish a connection with graphic

interface.
54
e) Launch Xming.
f) Execute this command "root @ tracesrv: ~ # wireshark & 'to launch wireshark
which allows us to take a network capture is a photo on a time period that passes
over the network.
g) Select the interfaces: eth1 and eth2 as follows:
h) Collect the traces from the trace of an FTP server using FileZilla client.
55
3.4 Services
3.4.1 Attach and registration
1- The terminal attaches to the E.UTRAN and EPC network. The UE

authenticates towards the EPC network using EPS-AKA. The UE has assigned a
default APN from which an IP address is assigned to the UE and a default bearer is
established. During the attach procedures, a VoLTE UE will not indicate any
specific APN.
2- The UE will check if the IMS APN was setup as part of the initial attach.
Note that it is generally not recommended to have the IMS APN as default APN.
3- If the default APN is not used for SIP signaling, the UE establishes a new
EPS bearer for the IMS APN for SIP signaling.
4- The UE registers in the IMS network using the P-CSCF address provided
from EPC when setting up the IMS APN. The UE is authenticated using IMS-AKA
in IMS.
5- The UE subscribes to IMS registration events.
Registration
Objective To verify that the Subscriber can register correctly when it accesses
the network.
Predefined 1. the Subscriber A data exist on the SSH.

conditions 2. the Subscriber A is not registered.
Test Procedures Expected Results

1. A Subscriber initiates a registration 1. The registration is successful.
request.
2. Query information from Subscriber A

to S-CSCF. Parameter IMPU should 2. The S-CSCF has information about
Subscriber A, and the status of the
be introduced, as
sip:+213471004578@djaweb.com. Subscriber is registered.
Tableau 2: Registration Test
56
3.4.2 Re-registration
Objective To verify that the Subscriber may register again with success.
Predefined 1. the Subscriber A data exist on the HSS.

conditions 2. the Subscriber has registered successfully.

1. Keep the Subscriber A terminal in the 1. the re-registration is successful.
saved state to expire registration and
launch an application for
reinstatement.
2. Query information from Subscriber A 2. the S-CSCF has information from

to S-CSCF. Parameter IMPU should Subscriber A, and the status of the
be introduced, as Subscriber is registered.
sip:+213471004578@djaweb.com.
Tableau 3: Re-registration Test

3.4.3 Deregistration
Objective To verify that the Subscriber can be de - register successfully.
Predefined 1. the Subscriber A data exist on the HSS.

conditions 2. the Subscriber has registered successfully.

1 Subscriber A initiates a request for 1. the record of successful.
deregistration.
2. query information from Subscriber A to

S-CSCF. Parameter IMPU should be 2. the status of the Subscriber A in S-CSCF
introduced, as is unregistered.
sip:+213471004578@djaweb.com.
Tableau 4: Deregistration Test

3.4.4 Originating call
1- The user initiates a call. If the UE is not already in active mode, the UE re-
establishes the bearers by performing a service request.
57
2- The UE sends an INVITE request to IMS to establish an IMS session with

another subscriber.
3 During the SIP negotiation, when receiving the SDP answer. IMS performs a
resource allocation request toward EPC for the media being negotiated, (end to end
precondition setup)
4. The EPC associates the received service data flows to an existing IP-CAN
session and creates a set of polity rules for the media negotiated, which triggers the
PGW to create a new dedicated bearer for each media type being negotiated. As an
example, for a voice call, one bearer will be created.
5. The called subscriber answers the call and replies with a SIP 200 OK. The
session setup is completed.
6. RTP media between the session participants is interchanged.
7. Any of the session participants can release the session by sending a SIP BYE
message. The resources for media are released, and IMS indicates EPC to release
the dedicated media bearer(s).
Basic Call
Objective To verify the call can be established successfully between two

subscribers IMS
Predefined 1 Subscriber A and Subscriber B belong to the same domain.

conditions 2. The Subscriber A and B are registered in the IMS network
successfully.
3. Customers A and B are both resting State.

1. A dials B. 1. B rings.
2. B responds to the call. Check the 2. The call is established successfully

speech in both directions.
3. A releases the call.

3. The call is released.
Tableau 5: Basic Call Test
58
Terminating call
1- The IMS network receives a terminating request to establish an IMS session

towards a served subscriber. The IMS process the request internally.
2- The IMS network sends a SIP INVITE requests to the served subscriber.
3- EPC tries to route the call towards the UE. If the UE is not in active mode,
the network will page the UE to trigger the UE to perform a service request to
restore its bearers so that the call setup can be routed to the terminal.
4- The VoLTE UE receives the SIP INVITE requests and the session
establishment continues.
5 During the SIP negotiation, when receiving the SDP answer. IMS performs a
resource allocation request toward EPC for the media being negotiated.
5- The EPC associates the received service data flows to an existing IP-CAN
session and creates a set of policy rules for the media negotiated, which triggers the
PGW to create a new dedicated bearer for each media type being negotiated. As an
example, for a voice call one bearer will be created, for a voice and video call, two
bearers will be created.
6- The called subscriber answers the call and replies with a SIP 200 OK. The
session setup is completed.
7- RTP media between the session participants is interchanged.
8- Any of the session participants can release the session by sending a SIP BYE
message. The resources from media are released, and IMS indicates EPC to release
the EPC releases, i.e. the dedicated media bearer is terminated.
3.4.5 Originating Identity Presentation (OIP)
Originating Identity Presentation (OIP) presents the originating user's identity to

the terminating users. The OIP feature is executed on behalf of the terminating user
and is invoked on the terminating MTAS.
The main case for OIP is that the terminating user has OIP and then no actions are
performed in the MTAS unless the originating user had requested for identity
restriction.
59
If privacy is requested by the originating user. OIP service will update headers
based on the level of privacy required, "header" or "user". The "id" level of privacy
is handled by the P.CSCF before the request is sent towards the terminating UE.
If the served user has deactivated the OIP service to. OIP anonymizes the From
header field and removed all the PAI. Privacy and User level headers.
Originating Idententity Presentation (OIP)
Objective To verify service supplementary submission of the caller's number is

ok.
Predefined 1. MTAS and the IMS core work normally.

conditions 2. A and B are IMS users who have configured
3. Subscribers A and B were recorded by MTAS.

1.A call B 1. We can see the number
Tableau 6: OIP Test
3.4.6 Originating Identity Restriction (OIR)
OIR enables to restrict the originating user's identity from being presented to the
terminating users. MTAS responsibility is to indicate in the signaling that the
originating user wants to restrict the presentation of the identity.
The OIR service is executed on behalf of the originating user and in the originating
MTAS.
OIR enables to restrict the originating user's identity from being presented to the
terminating users. MTAS responsibility is to indicate in the signaling that the
originating user wants to restrict the presentation of the identity. The OIR service is
executed on behalf of the originating user and in the originating MTAS.
The main case for OIR is that the originating user has OIR active, in one of the
three modes, with the service settings indicating the level of restriction. The
originating MTAS will in this case add Privacy SIP header values in accordance
60
with the originating users service settings in order to request privacy. The actual
privacy enforcement is handled in the terminating network by terminating MTAS
and P-CSCF. The restriction is controlled in Operator Subscription Service Level
configuration during user provisioning.
Originating Idententity Register (OIR)
Objective To check the permanent restriction of caller ID mode.

Predefined 1 A and B are IMS that have been identified and successfully
conditions registered subscribers.

[Authorization] [Authorization]
1 check if the Subscriber is allowed to use 1-2. Verification is successful.

the RTI service. [Execution]
2. check if the B Subscriber is allowed to 3.A means an announcement indicating

use the ICB service. that the activation of the service is
successful with success.
[Execution]
4. A hear the ring-back tone, B phone
3. the A subscriber dials the code (* 83 #) rings, and A name is not displayed on the
to enable the permanent restriction of phone from B.
caller ID service.
5. A talk with B.
4 A calls B.
6. the call is released.
5 B answers the phone.
6. A hangs up.
Tableau 7: OIR Test
3.4.7 Communication Waiting CW
The Communication Waiting (CW) service allows a user to be notified of incoming

calls when they are involved in other communication sessions.
If CW has been used for a served user, the CW function will start an alerting timer
according to Algerie Telecom's input.
61
The called party who is involved in other session will receive a CW indication, and
it's up to the called party's UE and user how to process, i.e. generate a tone, accept,
reject, etc.
Upon receipt of a final response or expiry of the alerting timer, the CW timer is
stopped.
The served user may make use of the HOLD service in order to place an existing
session on hold while the waiting communication is answered.
Call flow for Communication Waiting scenario is shown below.
Pre-requisite: The VoLTE UE is on an ongoing IMS session.
1- The IMS network receives a terminating request to establish an IMS session for
the served UE. The UE receives the INVITE and if the call waiting services is
enabled in the UE, the UE notifies the user that there is an incoming call.
2- The IMS establishes a new Rx session with the PCRF for the 2nd call. IMS
indicates the information is preliminary.
3- As the second session has the same properties as the existing EPC reuses the
existing dedicated bearer, but adds the additional resource (bandwidth) needed
for the media of the new session. Note that this EPC bearer handling is the
Ericsson recommended method.
4- The user decides to accept the new incoming call and answers it; UE sets the
ongoing session on hold and accepts the second session.
5- The session setup is completed for the new incoming call
6- The IMS requests to update the resources in the EPC for the second session to
allow the media
7- The EPC bearer is updated to allow the media for the connection. The filters for
the bearer are also updated.
8- The user communicates with the new caller.
9- The user releases the 2nd call. A SIP BYE is sent to IMS to release the session.
10- The IMS releases the resources requested from EPC as a result of the BYE.
11- As the same dedicated bearer was used for the two calls, the dedicated bearer is
updated to release the specific resources for the released call, and any filters.
12- The user requests to resume the 1st session. A SIP re-INVI TE or UPDATE is
sent to activate the media stream.
13- The IMS requests to restore resources in the EPC for the 1 st session.
62
14- The dedicated bearer resources are updated with the information for the 1 st
session, and the filters are also updated to allow the media for the 1st session.
15- The user releases the first call.
Call Waiting
Objective To check the service of call waiting .
Predefined 1. A, B and C are subscribers IMS that have been defined and
conditions recorded on the IMS network.
2.

[Activation] [Activation]
1. A activate the CW with *58# 1. CW is activated.
[Execution] [Execution]
2. A calls B. 2. the call between A and B is normal.
3. C calls A 3.A hears call tone.
4. A responds to the call of C by pressing 4. the call between A and C is normal, B

'R + 2 '. hears the announcement of call waiting.
5.A press 'R + 2' to change the held. 5. A and B communicate and C hears the
announcement
6. A hangs up the call.
6. The call ends.
Tableau 8: Call Wating Test
If A wanted to hang up the first call, he could do that by pressing R+1.
If A wanted to reject the communication waiting call he could do that by pressing

R+0.
A deactivate the CW by pressing #58#.
63
3.4.8 Communication Hold
The HOLD function is invoked in an established session by UPDATE or RE-

INVITE.
Hold tone/announcement is provided by Algerie Telecom as a media file to be

stored and played by MRFP (MRS).
Call flow for Communication Hold and resume scenario.
Pro-requisite An IMS session has been established and Is ongoing
1. The user requests to put the ongoing call on hold. A SIP re-INVITE or UPDATE
is sent to inactivate the media stream.
2 The IMS updates the EPC with the change of media state to held state
3. The EPC closes the gates In PGW for the media. Note though that RTCP will
still be allowed to be sent.
4 The EPC bearer is updated
5. The UE does not send media nor receives from the network. At this time, the UE may
place another call, using the procedures of previous sections.
6. The user requests to resume the call previously put on hold . A SIP re-INVITE or UPDATE
is sent to activate the media stream.
7. The IMS updates the EPC with the change of media state to active state.
8. The EPC opens the gates in PGW for the media.
9. The EPC bearer is updated.
10. The media can now be sent in both directions.
Objective To check the service of call waiting.
Predefined 1. A and B are subscribers IMS that have been defined and recorded
conditions on the IMS network.
64

1.A calls B 1. A communicates with B.
2.A press R to Hold B 2. B hears the announcement.
3.after 2minutes the hold will end if A 3. communication between A and B is

doesnt end it before. normal.
Tableau 9: Communication Hold
3.4.9 Communication Barring (CB)
The Communication Barring (CB) is a rule-based service. The rules are fetched
from the HSS via Sh and evaluated by the function that determines if the
communication shall be barred or not.
If the communication is barred then the indication is sent to the caller. The
indication is sent as SIP response.
ICB and OCB are triggered for both registered and unregistered users; there is no
difference in the execution due to the registration state.
The CB service can be configured in two levels:
- Operator Subscription Service Level and

- User Subscription Service Level.
3.4.9.1 Outgoing Communication Barring (OCB)
Outgoing Communication Barring (OCB) rejects outgoing communications that

fulfill certain provisioned or configured conditions on behalf of the originating
user.
For an initial INVITE. OCB is executed on the originating MTAS Below is

examples of OCB rules that could be configured per user subscription, in Algerie
Telecom VoLTE:
Barring of All Outgoing Calls

Barring of Outgoing International Calls
Barring of Outgoing Calls to Mobile
65
Announcement could be played to the served user according to Algerie Telecom

request.
Out-going Call Barring (OCB)
Objective To check the outgoing calls barring service.
Predefined 1 A and B are subscribers IMS that have been defined and registered

1. check if the Subscriber is allowed to use 1. the verification is successful.

CBO. [Activation]
[Activation] 2. A hears an announcement indicating

that the activation of the service is
2. A composed "* 541234 * 0" to activate successful with success.
the outgoing call barring service.
[Query] [Query]
3. A composed * #54 # to interrogate the 3. A means an announcement indicating

incoming call barring service. that the service is enabled. [Execution] 4
[Execution] means a tone end call.
4. A calls B. 5. The call is released.
5. A hang up. [Disable]
[Disable] 6. B hears an announcement indicating that

disabling the service is successful.
6.B composed * 541234 * 4 # to disable
the CBO service.
Tableau 10: Out-going Call Barring Test
3.4.9.2 Incoming Call Barring (ICB)
Incoming Communication Barring (ICB) rejects incoming communications that fulfill

certain provisioned or configured conditions on behalf of the terminating user.
66
For an initial INVITE, ICB is executed on the terminating MTAS.
Announcement could be played to the originating user according to AT request
The incoming communication is rejected by a SIP response with result code 603 (Decline)
Incoming Call Barring (ICB)
Objective To check the incoming call barring service.
Predefined 1. A and B are subscribers IMS that have been defined and registered

1. check if the B Subscriber is allowed to 1. the verification is successful.

use the CBI service. [Activation]
[Activation] 2. B means an announcement indicating

2.B composed "* 440 #" to enable the successful with success.
incoming call barring service.
[Query]
[Query]
3. B means an announcement indicating
3. B compound * #440 # to interrogate the
that the service is enabled.
incoming call barring service.
[Execution] [Execution]
4. A calls B. 4. the appeal does not pass to B, (A) means

an end-of-call tone.
5A hangs up.
5. the call is released. [Disable]
[Disable]
6. B means an announcement indicating
6. B composed #440 # to disable the CBI that disabling the service is successful.
service.
Tableau 11: Incoming Call Barring Test
67
3.4.10 Communication Forwarding Unconditional (CFU)
Objective To check the unconditional call forwarding service.
Predefined 1 A, B, and C are subscribers IMS that have been defined and
conditions registered on the IMS network.
2 standardization of IMPU destination of CFU in international

format.


use the CFU service.
[Activation]
[Activation]
2. B hears an announcement indicating that
2. B composed "' * 57 * + C number for the activation of the service is successful
active unconditional call forwarding with success.
service."
[Query]
[Query]
3. B compound * #57 # to query the the service is enabled.
unconditional call forwarding service.
[Execution]
[Execution]
4. The call is transferred to v.
4. A calls B.
5. The call between A and C is normal.
5. C answers the phone.
6. The call is released.
6. hangs up.
[Disable]
[Disable]
7. B composed #57 to deactivate disabling the service is successful.
unconditional call forwarding service.
Tableau 12: CFU Test
68
3.4.11 Call Forwarding Busy
Objective To check the call forwarding busy service.
Predefined 1 A, B, C and D are subscribers IMS that have been defined and
2 standardization of IMPU destination of CFB in international

format.


use the CSFB service. [Activation]
[Activation] 2.B hears an announcement indicating that

the activation of the service is made with
2. B composed "* 67 * + C" to activate success.
busy call forwarding service.
[Query]
[Query]
3. B compound * #67 # to query the call the service is enabled.
forwarding busy service.
[Execution]
[Execution]
4. calling between B and D is normal.
4. B calls D.
5. the call is transferred to C.
5. A calls B.
6. The call between A and C is normal.
6. C answers the phone.
7. the call between A and C is released
7.A hangs up normally.
8. B hangs up. 8. the call between B and D is released.
[Disable] [Disable]
9. B composed #67 # to deactivate the call 9. B hears an announcement indicating that

forwarding busy service. disabling the service is successful.
Tableau 13: CFB Test
69
3.4.12 Communication Forwarding on No Reply
Objective To check the call unanswered forwarding service.
Predefined 1 A, B and C are subscribers IMS that have been defined and
2 standardization of IMPU CFNRy destination in international

format.


use the service CFNRy. [Activation]
[Activation] 2. B means an announcement indicating

2. B composed "* 61 * + C number" to successful with success.
enable the call unanswered forwarding
service. [Query]
[Query] 3. B means an announcement indicating

that the service is enabled.
3. B compound * #61 # to query the call
unanswered forwarding service. [Execution]
[Execution]
4. the call is transferred to C.
4. A calls B. The B terminal sounds, but B 5. the call between A and C is normal.
does not answer until the ringer expires 5.
C answers the phone. 6. the call is released.
[Deactivation]
6. A hangs up.
[Deactivation] 7. B means an announcement indicating

that disabling the service is successful.
7. B compound #61 # to disable the call
unanswered forwarding service.
Tableau 14: CFNRy Test
70
3.4.13 Conference Call
Objective To check the service of conference with a master.
Predefined 1 A, B and C are subscribers IMS that have been defined and
2. Normalization of the IMPU of the destinations of the conference in

international format.

1. check if the Subscriber is allowed to use 1. the verification is successful.

the conferencing service. [Execution]
[Execution]
2. the call between A and B is normal.
2. A calls B.
3.A means another call tone.
3. C calls
4. the call between A and C is normal, B
4. A responds to the call of C by pressing means the announcement of call waiting.
'R + 2 '.
5. A press 'R + 3' to establish a conference

5. A, B and C communicating all together
between the three parties.
6. The conference between the 3 parties
6. A hangs up the call. shall be released.
Tableau 15: Conference Call
71
CONCLUSION
When we talk about Voice over LTE we know directly that IMS IP
Multimedia Subsystem is the key of this technology and will be deployed by
operator to ensure Voice over IP and convergence between all technologies.
IMS is the future architecture for IP multimedia telephony. It has been

defined by operators that want to continue to deliver telephony services when their
legacy networks are replaced by an IP network.
IMS is both a challenge and an opportunity as the foundation for the telephony,
applications and services businesses over the coming decade.
72
References
Document
Ref Number Title
[1] 3GPP TS 23.002 Network Architecture
[2] 3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and
Evolved Universal Terrestrial Radio Access Network (E-

UTRAN); Overall description; Stage 2
Non-Access-Stratum (NAS) protocol for Evolved Packet
System
[3] 3GPP TS 24.301
(NAS) protocol for Evolved Packet System
Evolved Universal Terrestrial Radio Access Network (E-

[4] 3GPP TS 36.413 UTRAN); s1 Application Protocol (S1AP)
General Packet Radio System (GPRS) Tunnelling Protocol

[5] 3GPP TS 29.281 User plane (GTPv1-U)
Evolved Packet System (EPS); Mobility Management Entity

[6] 3GPP TS 29.272
nterfaces based on Diameter protocol
3GPP Evolved Packet System (EPS); Evolved General Packet

[7] 3GPP TS 29.274 Radio Service (GPRS) Tunnelling Protocol for Control plane
(GTPv2-C); Stage 3
Policy and Charging Control (PCC); Reference points

[8] 3GPP TS 29.212
Policy and charging control over Rx reference point

[9] 3GPP TS 29.214
73
References
Interworking between the Public Land Mobile Network

(PLMN)
[10] 3GPP TS 29.061 supporting packet based services and Packet Data Networks
(PDN)
Cx and Dx interfaces based on the Diameter protocol;

Protocol
[11] 3GPP TS 29.229
details
IP Multimedia (IM) Subsystem Sh interface; Signalling flows

[12] 3GPP TS 29.328 and message contents
Sh interface based on the Diameter protocol; Protocol details

[13] 3GPP TS 24.604
IP multimedia call control protocol based on Session

Initiation
[14] 3GPP TS 24.229 Protocol (SIP) and Session Description Protocol (SDP); Stage
3
GSMA PRD IR.92

[15] GSMA PRD IR.92
Originating Identification Presentation (OIP) and Originating

[16] 3GPP TS 24.623 Protocol (XCAP) over the Ut interface for Manipulating
Supplementary Services
Terminating Identification Presentation (TIP) and

Terminating
Identification Restriction (TIR) using IP Multimedia (IM)
[17] 3GPP TS 24.147 Core
Network (CN) subsystem; Protocol specification
Communication HOLD (HOLD) using IP Multimedia (IM)

Core
[18] 3GPP TS 24.247
Network (CN) subsystem; Protocol specification
74
References
Anonymous Communication Rejection (ACR) and

Communication
[19] IETF RFC 3550 Barring (CB) using IP Multimedia (IM) Core Network (CN)
subsystem; Protocol specification
Ericsson Confidential documents.
GSMA VoLTE Service Description and Implementation Guidelines
3GPP TS 23.203 Policy and charging control architecture
75
DEFINITION OF TERMS
Term Description
3GPP 3rd Generation Partnership Project
A-SBC Access Session Border Controller
AMR Adaptive Multi-Rate
AMR-WB Adaptive Multi-Rate Wideband
API Application Programming Interface
BGCF Border Gateway Control Function
APN Access Point Name
ARP Allocation and Retention Priority
AS Application Server
CW Call Waiting
DiffServ Differentiated Services
DL DownLink
DNS Domain Name System
DSCP DiffServ Code Point
e2e end to end
EPC Evolved Packet Core
EPS Evolved Packet System
ESM EPS Session Management
76
DEFINITION OF TERMS
Evolved Universal Terrestrial Access

E-UTRAN Network
FDD Frequency Division Duplex
GBR Guaranteed Bit Rate
GPRS General Packet Radio Service
GSM Global System for Mobile communications
GTP GPRS Tunnelling Protocol
HLR Home Location Register
HPMN Home Public Mobile Network
HSS Home Subscriber Server
I-CSCF Interrogating Call Session Control Function
I-SBC Interconnect Session Border Controller
IBCF Interconnection Border Control Function
IETF Internet Engineering Task Force
IM IP Multimedia
IM-GW IP Media Gateway
IMEI International Mobile Equipment Identity
IMS IP Multimedia Subsystem
77
DEFINITION OF TERMS
IMS-AKA IMS Authentication and Key Agreement
IMS-AGW IMS Access Gateway
IMS-ALG IMS Application Level Gateway
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IP-CAN IP-Connectivity Access Network
IPsec IP Security
IPX IP Packet Exchange
ISIM IM Services Identity Module
LTE Long Term Evolution
MAC Medium Access Control
MGCF Media Gateway Control Function
MME Mobility Management Entity
MMTel Multimedia Telephony
MRS Media Resource System
MSC Mobile Switching Centre
MSISDN Mobile Subscriber ISDN Number
NAT Network Address Translation
OIP Originating Identification Presentation
OIR Originating Identification Restriction
78
DEFINITION OF TERMS
P-CSCF Proxy Call Session Control Function
PCC Policy and Charging Control
PCEF Policy and Charging Enforcement Function
PCRF Policy Charging and Rules Function
PDN Packet Data Network
PGW Packet Data Network Gateway
PLMN Public Land Mobile Network
PMN Public Mobile Network
PS Packet Switched
QCI QoS Class Identifier
QoS Quality of Service
RLC Radio Link Control
RRC Radio Resource Control
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
S-CSCF Serving Call Session Control Function
SAE System Architecture Evolution
SBC Session Border Controller
SDP Session Description Protocol
SGW Serving Gateway
79
DEFINITION OF TERMS
SGSN Serving GPRS Support Node
SIGCOMP Signalling Compression
SIP Session Initiation Protocol
SIP-I SIP with encapsulated ISUP
SMS Short Message Service
MTAS Multimedia Telephony Application Server
TAI Tracking Area Identity
TDD Time Division Duplex
TDM Time Division Multiplexing
UDP User Datagram Protocol
UE User Equipment
UL Uplink
ULI User Location Information
Universal Mobile Telecommunications

UMTS System
UNI User to Network Interface
USIM Universal Subscriber Identity Module
UTRAN Universal Terrestrial Access Network
VLR Visitor Location Register
VoLTE Voice over LTE
VPMN Visited Public Mobile Network
80

VoLTE Project Report

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

VoLTE Project Report

Загружено:

Авторское право:

Доступные форматы

Ministre de lenseignement Ministre de la poste et des

suprieur et de la recherche technologies de linformation et de la

Institut National des

Projet de Fin dEtude pour lobtention du

Diplme dIngnieur dEtat

Mr. Mohamed Zakaria KOUNINEF

Mr. Abed TAYEB

Mr. O.KAID OMAR

Anne Universitaire : 2014- 2015

I am satisfied for finishing my work. Firstly I

thank god most powerful, who facilitate things for

me and put me in a good condition. I also send my

special thanks to:- - All my family My Father, My

Mother, brothers and Sisters. To all my friends - To

all who helps me in one way or another during the

realization of this project. -To all who participate

during my presentation of this projects. -To the

president and its cabinet for their acceptance in

examining and evaluating my project. - To my

tutor for its advice and everything he gave to me.

2.4.3.1.4 Media Resource System (MRS) ....................................................32

Originating Idententity Register (OIR) ..............................................................61

Definition of terms ..76

Figure 1: LTE Architecture .........................................................................................8

Tableau 1: Standardized QCI characteristics ............................................................49

The GSM Association (GSMA, or Group Special Mobile Association),

CHAPTER 1. LTE Architecture

1.2 LTE Architecture

Figure 1: LTE Architecture

1.2.1 UE (User Equipment): The UE contains functionality to access

1.2.2 Radio Access Network: The Evolved Universal Terrestrial

1.2.3 Core Network. The Evolved Packet Core (EPC):

1.2.3.1 Mobility Management Entity (MME)

1.2.3.2 SGW (Serving Gateway):

1.2.3.3 PGW (Packet Data Network Gateway):

PGW functions could be realized as a single network element.

1.2.3.4 HSS (Home Subscriber Server):

CHAPTER 2. SOLUTIONS FOR SUPPORTING VOICE OVER

LTE (Long Term Evolution) is the next-generation mobile technology that

The deployment of LTE is accelerating as it is now becoming the fastest

2.2 Voice Over LTE

VoLTE is in accordance with 3GPP specifications and additional profiling is

With VoLTE (GSMA VoLTE IR.92 specification, based on global 3GPP

Enhanced phonebook: service capabilities and enhanced contacts

Enhanced messaging: enables a large variety of messaging options

Enriched calls: enables multimedia content sharing during a voice call,

o Simultaneously deliver data with high-definition (HD) quality voice

o Create attractive communication services, blending mobile voice

o Harmonize todays fragmented communications

o Benefit from LTEs improved spectral efficiency

o Quickly re-farm 2G and 3G spectrum to LTE for capacity gains

2.3 VoLTE Interface Description

LTE-Uu Interface (UE eNodeB)

S1-MME Interface (UE MME)

S1AP Interface (eNodeB MME)

S1-U Interface (eNodeB SGW)

X2 Interface (eNodeB eNodeB)

S5 Interface (SGW PGW)

S6a Interface (HSS MME)

S9 Interface (H-PCRF V-PCRF)

S10 Interface (MME MME)

S11 Interface (MME SGW)

Gx Interface (PCRF PGW)