See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/261310234

Supporting Voice over LTE: Solutions,

Architectures, and Protocols

Conference Paper · July 2013

DOI: 10.1109/ICCCN.2013.6614200

CITATIONS READS

0 135

6 authors, including:

Christopher Jasson Casey Srivatsan Rajagopalan

Texas A&M University Qualcomm
7 PUBLICATIONS 7 CITATIONS 1 PUBLICATION 0 CITATIONS

SEE PROFILE SEE PROFILE

Alex Sprintson Walt Magnussen

Texas A&M University Texas A&M University
102 PUBLICATIONS 2,017 CITATIONS 9 PUBLICATIONS 15 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Christopher Jasson Casey on 05 February 2015.

The user has requested enhancement of the downloaded file.

 Supporting Voice over LTE: Solutions,
Architectures, and Protocols
Jasson Casey, Srivatsan Rajagopalan, Muxi Yan, Graham Booker, Alex Sprintson, and Walt Magnussen
Abstract—Modern cellular networks are expected to support
both voice and a growing volume of data traffic. The rapid
growth in data traffic has promoted network operators to move
to Long Term Evolution (LTE), a 4th generation of wireless
network infrastructure. However, LTE architecture does not
support native circuit switching services and relies on the IP
Multimedia Subsystem (IMS) for supporting voice and Short
Messaging Service (SMS). Unfortunately, the uptake of IMS has
not been as rapid as expected and deployments of IMS cores
have been limited. This poses a major issue for operators who
wish to deploy LTE in the near future. In particular, voice
and SMS drive a majority of service provider revenue, who are
concerned with voice quality, call continuity, and reliable SMS
delivery in deployed LTE networks. In this paper we analyze
several contending approaches to delivering voice services over
LTE networks. Each approach will be illustrated with sequence
diagrams to explain how voice and SMS services are rendered.
We compare the proposed solutions in terms of complexity, cost,
features, and interoperability.
I. I NTRODUCTION
Voice and Short Messaging Service (SMS) are the primary
sources of revenue for wireless operators; however, the data
traffic is consuming most of the bandwidth. This trend is new,
and the disparity between data and voice bandwidth consump-
tion is expected to grow. This has forced operators to plan on
deploying a 4th generation of wireless network infrastructure,
based on packet switching. However, this new architecture
does not natively support voice or SMS delivery. Operators
are now faced with evaluating, selecting, and implementing
one of several competing strategies to deliver voice and SMS
over this new network architecture.
Most of the recent growth in data traffic can be attributed
to the rapid uptake and usage of smart phones and tablets.
Cellular broadband usage has far outpaced all expectations,
resulting in an increasing demand on network operators. Out-
ages of cellular networks are now regularly in the media. To
alleviate the current network strain, the network operators are
deploying more radio towers, establishing a denser footprint,
and using 3G offload strategies in high density areas with Wi-
Fi technology.
As data usage eclipses voice on the cellular networks, it
makes sense to re-architect the network with a focus on data
traffic; preserving the existing revenue of voice and SMS.
A vast majority of network operators and telecommunication
Jasson Casey, Muxi Yan, Alex Sprintson, Graham Booker, and Walt
Magnussen are with Texas A&M University, College Station, TX, email
{jasson.casey,mxyan,gbooker,spalex,wmagnussen}@tamu.edu. Srivatsan Ra-
jagopalan is with Qualcomm Incorporated, San Diego, CA, email: srivat-
sanr@qualcomm.com
vendors have decided to deploy Long Term Evolution (LTE),
as specified by the 3rd Generation Partnership Project (3GPP)
in Release 8, to support this new trend in cellular usage. LTE
is based on packet switching, and leverages the flexibility and
interoperability offered by the Internet Protocol (IP).
IP Multimedia Subsystem (IMS) is a reference architecture
that was specified by 3GPP to support a rich set of multimedia
services delivered over a Packet Switched (PS) network. The
IMS specifications outline a rich collection of functional
elements and interactions in support of a wide variety of
multimedia services. IMS was originally intended to carry
the voice traffic of 3G networks; however, no major IMS
deployment activity has commenced to date.
Deploying LTE networks poses several major challenges.
First, LTE only provides packet based access to mobile
devices, with no native support for Circuit Switched (CS)
network access. As a result, voice calls and SMS messaging,
which are a major source of revenue for network operators,
are not natively supported by LTE. Second, as many operators
quickly move to LTE, LTE deployment outpaces the deploy-
ment of IMS. As a result, certain operators are currently faced
with the possibility of deploying LTE access networks without
IMS cores. This is acceptable for some operators who wish
to primarily offer mobile data access; however, a majority
of carriers want to provide access to their primary revenue
applications such as voice and SMS. This presents an inversion
of service for traditional wireless applications such as voice
and SMS. Operators without a IMS voice architecture cannot
serve LTE based mobile devices with voice or SMS.
Solution overview. CSFB is a proposal by the 3GPP
standards body that implies LTE radio coverage would always
overlap with legacy radio access. Whenever voice services are
necessary the User Equipment (UE) and network would work
together through LTE to decide to ‘Fallback’ to the legacy
radio network for CS access. VoLGA is a proposal by an
industry led forum that aims to let the UE establish tunnels
over LTE that will emulate a CS connection to a legacy Mobile
Switching Center (MSC). IMS defines a Session Initiation
Protocol (SIP) based multimedia delivery solution that works
over PS networks. VoLTE is a subset of IMS that focuses on
voice and SMS interactions at key points in the network. Over-
the-Top solutions are quite similar to Voice over IP (VoIP)
services offered over the Internet independent of broadband
providers. Finally, there are certain vendors that believe a more
proprietary approach to serve legacy/circuit voice applications
is appropriate.
Supporting Voice over LTE has been discussed in the
previous works (e.g., [1], [2]), but the discussion was limitted
 Acronym Description Acronym Description
BGCF Breakout Gateway Control Function NAS Non Access Stratum
CS Circuit Switched NNI Network to Network Interface
CSCF Call Session Control Functions P-CSCF Proxy CSCF
CSFB Circuit Switched Fall Back PDN-GW Packet Data Network Gateway
DHCP Dynamic Host Configuration Protocol PS Packet Switched
DL Downlink PSTN Public Switched Telephone Network
DTMF Dual-Tone Multi-Frequency RRC Radio Resource Control
EIR Equipment Identity Register RTP Realtime Transport Protocol
eNB Evolved NodeB S-GW Serving Gateway
GA-CSR Generic Access - Circuit Switched Resource S1AP S1 Application Protocol
GA-RC Generic Access - Resource Control SCTP Stream Control Transmission Protocol
GA-RRC Generic Access - Radio Resource Control SDP Session Description Protocol
GAN Generic Access Network SGW Signaling Gateway
GERAN GSM EDGE Radio Access Network SIP Session Initiation Protocol
GSMA GSM Association SIP-AS SIP Application Server
GTPv1-U GPRS Tunneling Protocol Version 1 User SLF Service Location Function
GTPv2-C Evolved GPRS Tunneling Protocol version 2 Control SMS Short Messaging Service
HSS Home Subscriber Server UE User Equipment
IMS IP Multimedia Subsystem UL Uplink
IP Internet Protocol UMA Unlicensed Mobile Access
LTE Long Term Evolution UMTS Universal Mobile Telecommunications System
MGCF Media Gateway Control Function UNI User to Network Interface
MGW Media Gateway UTRAN UMTS Terrestrial Radio Access Network
MME Mobility Management Element VANC VoLGA Access Network Controller
MRFC Media Resource Function Controller VoIP Voice over IP
MRFP Media Resource Function Processor VoLGA Voice over LTE via GAN
MSC Mobile Switching Center VoLTE Voice over LTE

TABLE I
ACRONYMS

UE
to special cases and no comprehansive performance analysis LTE-Uu
MAC/RLC/PDCP/RRC
MAC/RLC/PDCP/IP
was presented. The goal of this paper is to describe the LTE-Uu eNodeB
S1-U
SGW
MAC/RLC/PDCP/RRC IP/UDP/GTPv1-U/IP
basic operation of these contending approaches that deliver MAC/RLC/PDCP/IP
X2
S5
legacy circuit based voice services to a LTE based architecture. IP/SCTP/X1AP
IP/UDP/GTPv1-U/IP
S11
IP/UDP/GTPv2-C
S1-C IP/UDP/GTPv1-U/IP
Each approach will be explored through sequence diagrams; eNodeB IP/SCTP/S1AP
IP/UDP/GTPv2-C

S4
explaining how the basic voice services are rendered. We also S1-C
IP/SCTP/S1AP
IP/UDP/GTPv2-C
PDN GW
compare and contrast each solution with its alternatives. For MME S3
SGSN
IP/UDP/GTPv2-C
convenience, Table I lists all acronyms used in this paper. S6a 2.5/3G
Network
SGi
IP
IP/SCTP/DIAMETER S10
IP/UDP/GTPv2-C
II. BACKGROUND HSS
S13
IP/SCTP/DIAMETER Internet
MME
A. LTE
EIR
LTE is a wireless networking technology designed to pro-
vide subscribers with a secure high performance wireless
Fig. 1. LTE Architecture and Protocols
network experience. The primary assumption of LTE is that
all subscriber applications will use IP. LTE is described in
many specifications across thousands of pages; however, most their reference point names. This figure also details the actual
of the details of LTE can be distilled into three basic concepts: protocols being used over these reference points in an effort
managing subscribers (or UE), managing bearer tunnels, and to be clear about their nature. The following paragraphs will
using bearer tunnels. Because LTE is an IP-only network, the describe how the three main functions of LTE are carried out
primary job of the network is to provide IP packet delivery for by the LTE network elements depicted in Figure 1.
the UE; this is the job of a bearer tunnel. The UE uses bearer
tunnels to send and receive IP packets while moving through NAS
RRC S1AP
and between LTE networks. Bearer tunnels are adjusted to PDCP SCTP
follow the UE as it moves through and between networks UE RLC IP MME
eNB
to always ensure a path for packet delivery. Finally, the UE MAC
Layer 2
must authenticate, authorize, and register themselves with the PHY Layer 1
network in order to be tracked, create, and use these bearer
tunnels.
Fig. 2. UE to MME Control Signaling
The 3GPP defines functional element protocol interactions
as interfaces or reference points. These interfaces are typically
given names of the form: S1, X2, S11, etc. Figure 1 depicts The Mobility Management Element (MME) authenticates,
the functional elements of a LTE architecture and displays authorizes, and manages subscriber UE registrations. The

MME to UE control signaling protocol layers are depicted
in Figure 2. The MME and UE communicate using the Non
Access Stratum (NAS) protocol [3], which is routed between
the MME and UE through the Evolved NodeB (eNB). The
eNB is the smart radio base station that is used in the
LTE architecture. The eNB uses the S1 Application Protocol
(S1AP) [4] to signal with the MME and carry NAS messages
to and from the MME. S1AP is carried over a Stream Control
Transmission Protocol (SCTP) [5] connection between the
eNB and the MME. The eNB uses the Radio Resource
Control (RRC) protocol [6] signal the UE and to carry NAS
messages to and from the UE over the air interface. The
Home Subscriber Server (HSS) is a database used by the
MME to retrieve subscriber credentials and store relevant UE
information. The MME and HSS interaction takes place using
the DIAMETER protocol [7] over a SCTP connection. The
MME can perform authorization on the equipment itself by
querying the Equipment Identity Register (EIR) in a similar
manner as interacting with the HSS.
The MME is responsible for creating and managing bearer
tunnels on behalf of the UE as it moves through the network.
Bearer tunnels map the UE across a specific radio bearer to
a eNB, then through a GPRS Tunneling Protocol Version 1
User (GTPv1-U) [8] tunnel from the eNB to a specific Serving
Gateway (S-GW), and then to a terminating Packet Data
Network Gateway (PDN-GW). As the UE moves through the
network the bearer tunnel will need to shift to new eNBs and
S-GWs in order to maintain a connection. The MME manages
bearer tunnels through the eNB using the S1AP protocol,
and through the S-GW using the Evolved GPRS Tunneling
Protocol version 2 Control (GTPv2-C) [9] over UDP. GTPv2-
C messages are proxied by the S-GW to the PDN-GW to
manage bearer tunnel termination.
Finally, UE IP traffic is carried over the bearer tunnel,
which connects the UE and the PDN-GW. This IP traffic is
encapsulated in the GTPv1-U protocol. The eNB will take
traffic from a radio bearer and place it into the appropriate
GTPv1-U tunnel over UDP, which will then be forwarded to
the S-GW. The S-GW will forward it to the appropriate PDW-
GW, where it will be de-encapsulated and routed. The reverse
flow follows a similar procedure. This tunnel provides the UE
with a static interface for IP traffic even as the device moves
through the deployed LTE network.
B. IMS Architecture
IMS is a reference architecture developed by the 3GPP
organization to support IP based multimedia sessions. The
core of IMS is based on SIP, and Realtime Transport Protocol
(RTP). Devices can register their presence with the IMS
network, receive messaging based on specific event types they
subscribe to, and initiate and receive real-time multimedia
sessions (voice session, video session, etc). IMS defines spe-
cific processes for establishing subscriber authenticity, ses-
sion routing, inter-carrier routing, inter-carrier-roaming, inter-
carrier charging, and per session based QoS.
The IMS architecture’s functional decomposition is repre-
sented in Figure 3. The core of a IMS network is powered
MRFC
SIP-AS
MRFP
P-CSCF
HSS
S-CSCF SGW
Provider
Network SLF
I-CSCF
MGCF
PSTN
BFCF
MGW
Fig. 3. IMS architecture
by Call Session Control Functions (CSCF). These servers
provide a series of SIP services such as: registration, authenti-
cation, signaling message compression, and service routing.
The Subscriber Location Function (SLF) and HSS provide
registry and location based lookups for the architecture as
a whole. The Breakout Gateway Control Function (BGCF),
Media Gateway Control Function (MGCF), Signaling Gateway
(SGW), and Media Gateway (MGW) provide a IP interface to
and from the Public Switched Telephone Network (PSTN).
The Media Resource Function Controller (MRFC) and Media
Resource Function Processor (MRFP) provide media resources
for Dual-Tone Multi-Frequency (DTMF) capture/generation,
audio mixing, transcoding, audio recording, etc. Finally, the
SIP Application Server (SIP-AS) provides the ability to define
custom services through a API [10].
IMS was originally intended to be the voice signaling and
delivery platform for IP capable networks such as Universal
Mobile Telecommunications System (UMTS) and LTE. How-
ever, deployment of the IMS architecture has not become a
reality. The IMS architecture is complicated and deployment
requires a substantial investment in network equipment, op-
erational knowledge, and time. Because UMTS can still use
CS based voice, the additional cost of IMS to deliver voice
services has not been seen as a justifiable expense. However,
LTE provides no CS facilities and forces the issue of voice
support.
III. S OLUTION L ANDSCAPE
IMS has been the default solution to provide voice and
SMS services over any IP network (LTE included); however,
due to availability, complexity, and familiarity with IMS,
network operators are investigating alternative solutions for
LTE network deployments. These alternative solutions include:
CSFB, VoLGA, VoLTE, and Over-the-Top.
A. CSFB
Circuit Switched Fallback defines a mechanism for mobile
devices to use the legacy network for voice traffic in place of
an IMS architecture [11]. Mobile calls will take place over a
existing 2.5G (GSM EDGE Radio Access Network - GERAN)
or 3G (UMTS Terrestrial Radio Access Network - UTRAN)
network instead of over LTE.
 UE eNB
RA preamble
RA Response
RRC Connection Establishment
RRC Connection Setup
RRC Connection Setup Complete
Attach Request
Identity Request
Identity Response
Authentication / Security
MME S-GW P-GW
Update Location Request
Update Location Response
Create Session Request
Create Session Request
Create Session Response
MCS/VLR HSS UE eNB MME RNS MSC/VLR SGSN S-GW
Extended Service Request
UE Context Modification Request
UE Context Modification Response
RRC Connection Release
S1 UE Context Release Request
Release Access Bearers Request
Release Access Bearers Response
S1 UE Context Release Command
S1 UE Context Release Complete
Random Access
RRC Connection Request
RRC Connection Setup
RRC Connection Setup Complete

Create Session Response CM Service Request

CM Service Request
Location Update Request
CS call establishment procedure
Location update in CS domain

Location Update Accept

RRC Connection Init. Context Setup ( Attach Accept )
Reconfiguration Fig. 5. Mobile originating call procedure
RRC Connection Reconfig Complete
Init. Context Setup Complete
Modify Bearer Request
UE eNB MME RNS MSC/VLR SGSN S-GW
Attach Complete
CS Service Notification Paging Request
Modify Bearer Response
Extended Service Request
UE Context Modification Request
Fig. 4. Combined EPS/IMSI attach procedure
UE Context Modification Response
RRC Connection Release
S1 UE Context Release Request
A mobile device will connect to the LTE network in the Release Access Bearers Request
Release Access Bearers Response
same way as a standard LTE UE, but it will use a combined S1 UE Context Release Command
S1 UE Context Release Complete
attach procedure and its capabilities will advertise CS fallback.
Random Access
The MME will then signal a location update to an MSC in RRC Connection Request
the legacy GERAN or UTRAN network, which will hold the RRC Connection Setup

location of the mobile device in terms of CS services. The RRC Connection Setup Complete

MSC and MME will serve as a bridge between the legacy and Paging Response Paging Response
LTE networks. CS call establishment procedure

In our work we investigated the data flow of CSFB in three

scenarios: UE attachment, UE originated phone call and UE
Fig. 6. Mobile terminating call procedure
terminated phone call. In each scenario, we consider the most
basic configuration and mandatory messages. The information
sequences are given in the following subsections respectively. The sequence diagram is given by Figure 5. Observe that
1) UE Attachment: In CSFB mechanism, when UE requests this procedure is in four phases:
to attach to EPS network, it performs a combined EPS/IMSI 1) UE sends Extended Service Request to inform MME of
attach procedure. The purpose of the combined attach is to the call;
register UE at both EPS network and the legacy network. 2) EPS network releases RRC connection and all radio
At the time of registration, UE who supports CSFB would resources with UE;
send an attach request to EPS network with an indication 3) UE creates RRC connection with the legacy network;
that CSFB is used. When performing EPS attachment, EPS 4) Call procedure in CS domain is performed to make the
network receiving this indication should send message to the phone call.
legacy network to inform that UE is connected to legacy 3) Mobile terminating call: Mobile terminating call is
network as well. much the same as mobile originating call. The only difference
The sequence diagram of combined EPS/IMSI attach proce- is that mobile terminating call procedure is triggered by the
dure is shown in Figure 4. It can bee seen that this procedure is network, so there will be some notifications, such as paging
much the same as EPS attach procedure except that Mobility message, to UE. When UE receives these notifications, it
Management Entity (MME) sends Location Update Request performs the same action as that in mobile originating call.
to Mobile Switching Center (MSC)/Visitor Location Register Sequence diagram is given by Figure 6.
(VLR) to attach UE to legacy network. 4) SMS: Receiving SMS messages do not require a fallback
2) Mobile originating call: At the time when UE gives a to the legacy network. The paging requests are forwarded
call, it could either perform a PS handover or RRC release through the LTE network in the same manner of the call,
with redirection to legacy network. The difference between but instead of the UE transitioning to the legacy network to
these two methods is that if PS handover is supported, it complete the request, it establishes a service request over the
allows continuity for PS sessions when fallback. Here we only LTE network to the MME, and the message is forwarded from
consider the sequence of fallback to UTRAN network without the MSC to the MME over the SGs interface, which is then
PS handover supported, which is the most common scenario. forwarded to the UE over NAS. A mobile originated SMS
messages also involves a service request over the LTE network EAP-AKA authentication procedure

to the MME. The SMS is sent to the MME over NAS, which UE EPS DHCP DNS SeGW VANC AAA
HSS/
HLR
forwards the message to the MSC over the SGs interface, VANC
Discovery UE attaches to EPS

where the message is routed over the legacy network, and UE obtains connectivity to VoLGA PDN

the report is send back via the reverse path. DNS Query (SeGW Domain Name)
DNS Response

B. VoLGA
IKE_SA_INIT

VoLGA proposes to let a legacy MSC provide voice and IKE_SA_INIT

IKE_AUTH (NAI on Idi, no AUTH included)
SMS services to LTE UEs through either a GERAN A Select AAA
Server
interface or UTRAN Iu-CS interface. This concept originates EAP Response Identity
(NAI on IMSI)
with Unlicensed Mobile Access (UMA). UMA was developed Send AUTH
Info (IMSI)

to support 2.5G/3G network extension using Wi-Fi as network Response

(AUTH vectors)
EAP Request/AKA Challenge
access. Handsets that supported Wi-Fi would establish a IPSec EAP Request/AKA Challenge
(RAND, AUTN, MAC, Next ID)
(RAND, AUTN, MAC, Next ID)
ESP tunnel to a tunnel terminator in a service provider network Run UMTS
Algorithms
that is directly connected to the legacy MSC. The tunnel and verify
AUTN
terminator would also provide some interworking functionality EAP Response/AKA Challenge
(RES, MAC)
EAP Response/AKA Challenge
to allow these IP based endpoints to appear as if they were (RES, MAC)

connecting to the MSC using legacy interfaces. UMA was Check MAC
and
verify RES
submitted and accepted as a standard in the 3GPP standards EAP Success + keying
material
body and was renamed Generic Access Network (GAN) for EAP Success

Release 6. Complete IKEv2 Signaling

VoLGA was designed to have minimal impact on existing VoLGA

Registration
networks; however, it does require special support in the UE
and the introduction of the VoLGA Access Network Controller Fig. 7. VoLGA EAP-AKA procedure
(VANC) [12]. The primary responsibilities of the VANC are:
terminate IPSec ESP tunnels from the UEs, provide NAS
signaling delivery between the UE and MSC, and establish and
VoLGA Registration Procedure
map voice traffic between the UE and MSC. The VANC per-
forms authentication and authorization on incoming IPSec ESP
UE EPS/GPRS SeGW DNS VANC HOSF(s)
tunnels using an authentication, authorization and accounting
1. Establish secure tunnel to SeGW
(AAA) server via the Wm interface. The VANC can connect to
a GERAN network’s MSC using the A interface, or a UTRAN 2a. DNS Query (VANC Domain Name)

network’s MSC using the Iu-CS interface. Also, the VANC has 2b. DNS Response

the ability to interact with the LTE network and request QoS 3. Establish TCP connection to VANC

for VoLGA voice calls. 4. GA-RC REGISTER REQUEST (UTRAN/E-UTRAN cell info, IMSI, GAN Classmark, ...)

Our work investigates the data flow of VoLGA in the follow- 5a. Activate dedicated bearer for signaling

ing three scenarios: VoLGA registration, mobile originating 5b. GA-RC REGISTER ACCEPT (“VoLGA System Information”)
call and mobile terminating call. The data flows are given in 5c.
VANC-UE Binding Req
the following subsections respectively.
VANC-UE Binding Res
1) VoLGA registration: When a mobile device is powered
on and detects a LTE network, it first registers with the 6. GA-RC REGISTER REJECT (Reject Cause)

Mobility Management Entity (MME). Then the MME procures 7. GA-RC REGISTER REDIRECT (VANC Address)

subscriber related details by contacting the Home Location

Register / Home Subscriber Server (HLR/HSS) over the S6a
interface. Once registered on the LTE network, the VoLGA-
enabled user terminal, based on operator policy, proceeds to
select the Packet Data Network (default or VoLGA-specific
PDN) that the UE will use for VoLGA service. With connec-
tivity established to the assigned PDN, the UE performs the
VANC discovery procedure as shown in Figure 7. This way
it acquires the IP addresses of the VoLGA security gateway
(SeGW) and initializes the Internet Key Exchange Version 2
(IKEv2) authentication procedure. The SeGW, which may or
may not be integrated with the VANC, terminates a secure
remote-access tunnel from the UE and selects an AAA server
for UE authentication. It informs the UE of a successful
authentication with the EAP Success message.
Fig. 8. VoLGA registration procedure
Once the Secure Association between the UE and SeGW is
complete, the UE can continue with the VoLGA registration
procedure, which is depicted in Figure 8. The UE resolves the
IP address of its VANC, establishes a secure IPSec tunnel to
it over the LTE core network and over the SGi interface. It
then establishes a TCP connection to carry several signaling
protocols: GA-RC, GA-CSR, and GA-RRC. The VANC may
accept, reject or redirect the UE to another VANC (depending
on the UE’s location, load balancing or roaming condition).
Generic Access - Resource Control (GA-RC) is used to
manage UE registrations with the VoLGA service, negotiate
 GA-RC/CSR/RRC messages. A UE originated call will request service with a
TCP UL Direct Transfer (GSM/UMTS CM Service Request) to the
IP VANC, which then forwards this request to the MSC over the
IPSec ESP A- or Iu- interface for this user. If it has not already done so,
UE VANC the MSC will authenticate the user and activates ciphering.
UDP
IP The mobile device then sends a Setup message to the
MSC via the VANC, providing details on the call, its bearer
Layer 2
Layer 1
capability and supported codecs. The MSC acknowledges
this through the Call Proceeding message, instructing the
Fig. 9. VoLGA Signaling
VANC to establish the circuit-switched bearer connection.
The VANC translates this into an Activate Channel message,
assigns resources to the call and then prepares the UE for
Mobile Originated Call
exchange of IP packets containing voice data. Once the mobile
is prepared through an uplink Real Time Protocol (RTP) path,
UE E-UTRAN MME S-GW P-GW PCRF VANC MSC

GA-CSR REQUEST
an Assignment Response message is sent to the MSC. Once
GA-CSR REQUEST ACCEPT a call is established with the other party, the MSC notifies the
GA-CSR REQUEST REJECT
GA-CSR-
DEDICATED
UE through the Alerting (called party is ringing) and Connect
GA-CSR UPLINK DIRECT TRANSFER
(CM Service Request)
Complete L3 Info (called party has answered) messages. Upon acknowledgement
(CM Service Request)
from the mobile device, a two-way connection is in place for
GA-CSR UL DIRECT TXR (Setup)
GA-CSR DL DIRECT TXR (Call Proceeding) voice conversation and this completes the call origination.
Assignment Request

GA-CSR ACTIVATE CHANNEL

(call resources)
Activate
Voice bearer is handled outside of the context of the IPSec
dedicated
GA-CSR ACTIVATE CHANNEL ACK
IP-CAN session bearer for connection between the UE and MSC. The UE and VANC will
modification request user data
send and receive voice bearer using RTP. Voice is queued and
PCRF requested Ack

Create
IP-CAN session
modification
framed at both the VANC and UE into RTP packets, which
(begin)
Create
Dedicated
Dedicated
Bearer are forwarded to the negotiated UDP port and IP addresses.
Request
Bearer
Setup
Bearer
Request These address and port combinations are negotiated during the
RRC Connection Request
Reconfiguration
RRC Connection
Activate Channel sequence between the VANC and UE. The
Reconfiguration
Complete
Bearer
Setup Create
VANC will then switch voice traffic between MSC’s circuit
Response Dedicated
Bearer
Create
Dedicated
and UE’s RTP flows.
Response PCRF requested
Bearer
Response
IP-CAN session
modification Notification of
3) Mobile Terminating Call: Termination calls are sup-
(end) bearer level
event
Ack
ported in a similar manner except for the addition of the
GA-CSR ACTIVATE CHANNEL COMPLETE
Assignment
Paging message. From the MSC point of view, there is no
Response
GA-CSR DL DIRECT TXR (Alerting) connection established to the UE. So the MSC sends a paging
GA-CSR DL DIRECT TXR (Connect)
GA-CSR UL DIRECT TXR (Connect Ack)
message to the VANC, which is seen just as a GSM Base
Voice traffic (via dedicated bearer)
Station Controller (BSC) or UMTS Radio Network Controller
(RNC). From the LTE network viewpoint, the paging message
Fig. 10. VoLGA mobile originating call procedure
sent through the IPSec tunnel is not visible. Both GA-CSR and
GA-RRC support a paging request, which is used to indicate
an inbound service request. The mobile device establishes
the UE’s operational mode, and provide keep-alives for the a dedicated GA-CSR connection and sends back a paging
UE. A UE negotiates its operational mode so it can integrate response. If it has not already done so, the MSC authenticates
with a MSC in GERAN A-mode, UTRAN Iu-CS mode, or the mobile device and then authorizes it to use the network.
both. Generic Access - Circuit Switched Resource (GA-CSR) The rest proceeds in the much the same way as call origination.
allows for interworking with GERAN, while Generic Access 4) Short Message Service (SMS): SMS messages can be
- Radio Resource Control (GA-RRC) allows for interworking handled in the VoLGA architecture through embedding of
with UTRAN. Both GA-CSR and GA-RRC messages are legacy SMS messages in Direct Transfer messages.
used to establish voice bearers, tunnel NAS messages, and
interwork with MSC signaling. Figure 9 depicts the signaling C. VoLTE
stack between a UE and the VANC server [13]. VoLTE is a initiative led by the GSM Association (GSMA)
2) Mobile Originating Call: Figure 10 shows the signaling that aims to define exactly how an LTE operator deploys
exchange to establish a mobile originated voice call over LTE. IMS to carry voice traffic. The initiative plans to develop
Once a UE is registered with the VoLGA network, it can specifications that clearly outline three types of IMS voice
request a dedicated signaling connection with the MSC using interactions: User to Network Interface (UNI), Network to
either GA-CSR or GA-RRC depending on the negotiated mode Network Interface (NNI), and a roaming interface. These
of operation. Once a connection exists, CS-NAS messages specifications would provide a clear list of IMS features that
can be tunneled between the MSC and the UE over the EPS must be supported in order to provide a acceptable voice
bearer using Uplink (UL) and Downlink (DL) Direct Transfer service. The UNI interface is addressed through the IR92
 Mobile Terminated Call availability of system level API access on handsets. Also, this
UE E-UTRAN MME S-GW P-GW PCRF VANC MSC
technique requires double bandwidth for every active call. LTE
Paging providers can provide enhanced QoS for selected VoIP vendors
GA-CSR PAGING REQUEST
GA-CSR PAGING RESPONSE
by defining any flow to the VoIP vendor’s network address
GA-CSR-
DEDICATED
range would receive a dedicated bearer with QoS via the LTE’s
Complete L3 Info
(Paging Response)
PDN-GW and/or PCRF capabilities.
GA-CSR DOWNLINK DIRECT TRANSFER (Setup)
GA-CSR UL DIRECT TRANSFER (Call Confirmed) Activate IV. S OLUTION C OMPARISON
Assignment dedicated
Request bearer for
GA-CSR ACTIVATE CHANNEL user data
(Setup
There are currently four architectures that can provide
GA-CSR ACTIVATE CHANNEL ACK
IP-CAN session
modification request
RTP
Stream) voice and SMS services over a LTE network: Over-The-Top,
PCRF requested Ack VoLGA, CSFB, and VoLTE. Each solution presents different
IP-CAN session
Create
Dedicated
modification
(begin)
operational and technical tradeoffs.
Create
Bearer
Dedicated
Request
Bearer Bearer

RRC Connection
Setup Request A. Comparison of CSFB with VoLGA
Request
Reconfiguration
RRC Connection
Reconfiguration
Here we present our methdology for comparing CSFB and
Bearer
Complete
Setup
Response
Create
Dedicated
Create
VoLGA. We observe that both CSFB and VoLGA are trying to
Bearer
Response
Dedicated
Bearer
PCRF requested
IP-CAN session
integrate with the 2.5G/3G environment to make voice calls.
Response
modification Notification
(end) of bearer
So they both engage in circuit switching call procedure at
level event
Ack some point of their signaling sequence, which we view as
Assignment
Response a synchronization point. Without loss in generality, we say
GA-CSR UL DIRECT TRANSFER (Alerting) that the signaling in both strategies is the same after this
GA-CSR UL DIRECT TRANSFER (Connect)
GA-CSR DL DIRECT TRANSFER (Connect Ack) synchronization point. Therefore, the real difference of the two
Voice traffic (via dedicated bearer)
strategies is the signals before circuit switching call procedure
starts in legacy network. In this comparison we only take
Fig. 11. VoLGA mobile terminating call procedure into account signals before this point, which are sufficient for
comparing difference between performances of two strategies.
specification that the GSMA published in March of 2010 [14]. Since entities in the specifications are all logical entities,
The organization plans on releasing a NNI interface by mid- we do not know in advance what the exact latency of commu-
2010, and a roaming interface by the beginning of 2011. nication between them is. For example, the MME and HSS
The UNI specification presents a set of concrete require- could be either in the same phisical device or separate in two
ments on IMS elements for a VoLTE architecture. For sig- physical devices. Thus in our work we focus on performance
naling the UE must support registration, origination, and analysis with respect to the number of RTTs it takes for
termination as specified in the main IMS SIP specification communication between two logical entities in the procedures
[10]. Signaling compression must be used between the UE above.
and the Proxy CSCF (P-CSCF), and it mandates a list of Procedure CSFB VoLGA
supplementary services (Hold, Message Waiting Indicator, Attach EPS attach EPS attach
etc). It requires the support of ‘Preconditions’ through the + 1 RTT MME-MCS + EPA-AKA authen-
SIP Requires header. This header allows SIP devices to + CS domain Lo- tication
negotiate required SIP features during signaling interaction. cation Update proce- ( = 1 RTT UE-DNS
It gives further requirements on specific Session Description dure + 3 RTT UE-SeGW
Protocol (SDP) offer/answer sequences, RTP profiles, and + 2 RTT SeGW-
RTCP usages. Generally, the UNI specification dictates a list AAA Server
of mandatory compliance sections from 3GPP specifications + 1 RTT AAA-HSS
and outlines how certain features are to be used. + 2 RTT UE-VANC
+ 1 RTT VANC-
D. Over The Top HOSF )
Finally, any VoIP vendor can provide ‘Over-the-Top’ voice Mobile 1 RTT UE-MME 2.5 RTT UE-VANC
service to any LTE network user. The VoIP vendor would Origi- + 1 RTT eNB-MME
treat the network no differently than any other IP access nating + 1.5 RTT UE-RNS
medium. This solution would prohibit itself from supporting Call + Random Access
native handoff with legacy radio network such as GERAN and Procedure
UTRAN. Handoff is possible through ‘Tromboning’, which is Mobile 1.5 RTT UE-MME 1.5 RTT UE-VANC
establishment of a default PSTN call-leg for non-LTE roaming, Termi- + 1 RTT eNB-MEE
and a secondary VoIP call leg for LTE roaming. An AS will nating + 1.5 RTT UE-RNS
then switch media between the call legs based on the current Call + Random Access
location of the UE. But this technique is limited due to the Procedure
B. Comparison of all four architectures
Simultaneous V&D
Handoff
Overlap
IMS/VoLTE X X X X
CSFB X X * X
VoLGA X X X X
Over The Top X** X X X X
If packet handoff is supported
* Tromboning solution with 2 call legs
TABLE II
VOICE S OLUTIONS C OMPARISON
Each solution discussed above presents different operational
and technical tradeoffs.
Using an ‘Over-the-Top’ VoIP service is the simplest mech-
anism to delivery voice to a LTE subscriber. The LTE operator
is only required to install a VoIP client in the UE. The LTE
operator could even configure the LTE network to provide
protected QoS service to these VoIP calls using existing LTE
flow classification mechanisms. There is no obvious way of
delivering traditional SMS in this architecture. Also, handoff
to circuit only wireless networks is possible, but circuitous.
This architecture is useful for a sedentary subscriber base that
lives within the existing LTE coverage area.
VoLGA seems to be the best compromise between simplic-
ity, operational cost, and leveraging legacy voice and SMS
services. VoLGA requires UE support and the introduction
of the VANC network element. The LTE network can be
configured to provide protected QoS service to VoLGA calls
using flow classification. This solution maximizes a operator’s
investment in network equipment and operational knowledge
by reusing the GERAN/UTRAN network architecture.
CSFB is a interesting approach for serving voice and SMS
on a LTE network. CSFB requires a continuous overlap of
GERAN/UTRAN and LTE coverage. Its primary mechanism
works by forcing a fallback to one of these legacy radio
technologies for call origination and termination. While it is
possible to have simultaneous voice calls and data sessions
with CSFB, it is not clear that it will be practical. CSFB does
not require introduction of new network equipment, but does
require enhancements in the UE, MME, SGSN, and MSC to
support properly. CSFB can not function without the presence
of a fallback network that overlaps with LTE coverage, this
makes it suspect as a serious long term candidate for voice
and SMS delivery over LTE.
VoLTE is a specification that defines how to use IMS to
carry voice and SMS over the LTE network. VoLTE requires
the operator to deploy a VoLTE compliant IMS architecture.
This is unlikely to be a challenge for vendors as they have been
building IMS equipment for some time now. However, the
NNI and roaming specification of VoLTE are not expected to
View publication stats
be complete till the beginning of 2011. It will take some time
for interoperability to be established between vendors upon
Modify Network Elements
completion of the VoLTE specifications. This means VoLTE
New Network Elements
will be the last solution to the game as LTE deployments have
started in 2010.
V. C ONCLUSION
UE Support
Wireless broadband adoption and usage is growing beyond
all expectations of operators and network equipment manu-
facturers. This growth has caused severe strain on the existing
X X
2.5/3G wireless infrastructure, forcing carriers to deploy Wi-Fi
X X
X X based offload solutions in dense areas and upgrade their core
X with LTE. LTE will now be deployed before there are obvious
solutions for carrying the bulk of cellular revenue bearing
traffic (voice and SMS). There are several solutions being
proposed to solve this problem: CSFB, VoLGA, VoLTE, and
Over-The-Top. Over-The-Top is the simplest solution; how-
ever, it is limited in its mobile capabilities. VoLGA presents
a good compromise for providing a traditional mobile voice
and SMS experience over LTE while maximizing a carriers
investment and knowledge of their traditional CS based MSCs.
CSFB is a bridging strategy the uses legacy radio coverage
to provide voice and SMS that cannot exist without 2.5/3G
coverage coexisting with LTE. VoLTE represents a simplified
version of IMS and establishes a new call control architecture
that would allow the eventual decommissioning of 2.5/3G
voice and SMS infrastructure.
R EFERENCES
[1] V. Paisal, “Seamless voice over lte,” in Internet Multimedia Services
Architecture and Application(IMSAA), 2010 IEEE 4th International
Conference on, dec. 2010, pp. 1–5.
[2] M. Poikselkä, H. Holma, J. Hongisto, J. Kallio, and A. Toskala, Voice
Over Lte (Volte). Wiley, 2012.
[3] “Non-Access Stratum (NAS) protocol for Evolved Packet System (EPS);
Stage 3 (Release 9),” 3GPP, TS 24.301 V9.2.0.
[4] “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP) (Release 9),” 3GPP, TS 36.413 V9.1.0.
[5] R. Stewart, Ed., “Stream Control Transmission Protocol – RFC No.
4960,” Internet RFC, September 2007.
[6] “Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource
Control (RRC) Protocol Specification,” 3GPP, TS 36.331 V9.1.0.
[7] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, “Diamter
Base Protocol,” IETF RFC 3588.
[8] “General Packet Radio System (GPRS) Tunneling Protocol User Plane
(GTPv1-U) (Release 9),” 3GPP, TS 29.281 V9.2.0.
[9] “Evolved General Packet Radio Service (GPRS) Tunneling Protocol
for Control plane (GTPv2-C); Stage 3 (Release 9),” 3GPP, TS 29.274
V9.2.0.
[10] “IP Multimedia Call Control Protocol Based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release
9),” 3GPP, TS 24.229 V9.3.1, December 2009.
[11] “Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage
2 (Release 9),” 3GPP, TS 24.229 V9.3.1, December 2009.
[12] “Study on Circuit Switched (CS) domain services over evolved Packet
Switched (PS) access,” 3GPP, TS 23.879 V9.0.0.
[13] “Voice over LTE via Generic Access; Stage 2 Specification; Phase 1,”
VoLGA Forum, Stage 2 V1.6.0.
[14] “IMS Profile for Voice and SMS,” GSM Association, GSMA PRD IR.92.