Supporting Voice over LTE: Solutions ... - Semantic Scholar

5 downloads 391 Views 1MB Size Report
jagopalan is with Qualcomm Incorporated, San Diego, CA, email: srivat- [email protected] vendors have decided to deploy Long Term Evolution (LTE),.
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 consumption 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. Outages 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 WiFi 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 Rajagopalan is with Qualcomm Incorporated, San Diego, CA, email: [email protected]

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 deployment 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. Overthe-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 BGCF CS CSCF CSFB DHCP DL DTMF EIR eNB GA-CSR GA-RC GA-RRC GAN GERAN GSMA GTPv1-U GTPv2-C HSS IMS IP LTE MGCF MGW MME MRFC MRFP MSC

Description Breakout Gateway Control Function Circuit Switched Call Session Control Functions Circuit Switched Fall Back Dynamic Host Configuration Protocol Downlink Dual-Tone Multi-Frequency Equipment Identity Register Evolved NodeB Generic Access - Circuit Switched Resource Generic Access - Resource Control Generic Access - Radio Resource Control Generic Access Network GSM EDGE Radio Access Network GSM Association GPRS Tunneling Protocol Version 1 User Evolved GPRS Tunneling Protocol version 2 Control Home Subscriber Server IP Multimedia Subsystem Internet Protocol Long Term Evolution Media Gateway Control Function Media Gateway Mobility Management Element Media Resource Function Controller Media Resource Function Processor Mobile Switching Center

Acronym NAS NNI P-CSCF PDN-GW PS PSTN RRC RTP S-GW S1AP SCTP SDP SGW SIP SIP-AS SLF SMS UE UL UMA UMTS UNI UTRAN VANC VoIP VoLGA VoLTE

Description Non Access Stratum Network to Network Interface Proxy CSCF Packet Data Network Gateway Packet Switched Public Switched Telephone Network Radio Resource Control Realtime Transport Protocol Serving Gateway S1 Application Protocol Stream Control Transmission Protocol Session Description Protocol Signaling Gateway Session Initiation Protocol SIP Application Server Service Location Function Short Messaging Service User Equipment Uplink Unlicensed Mobile Access Universal Mobile Telecommunications System User to Network Interface UMTS Terrestrial Radio Access Network VoLGA Access Network Controller Voice over IP Voice over LTE via GAN Voice over LTE

TABLE I ACRONYMS

to special cases and no comprehansive performance analysis was presented. The goal of this paper is to describe the basic operation of these contending approaches that deliver legacy circuit based voice services to a LTE based architecture. Each approach will be explored through sequence diagrams; explaining how the basic voice services are rendered. We also compare and contrast each solution with its alternatives. For convenience, Table I lists all acronyms used in this paper. II. BACKGROUND

UE LTE-Uu MAC/RLC/PDCP/RRC MAC/RLC/PDCP/IP LTE-Uu MAC/RLC/PDCP/RRC MAC/RLC/PDCP/IP

S1-U IP/UDP/GTPv1-U/IP

eNodeB

X2 IP/SCTP/X1AP IP/UDP/GTPv1-U/IP S1-C IP/SCTP/S1AP

eNodeB

S5 IP/UDP/GTPv2-C IP/UDP/GTPv1-U/IP

S11 IP/UDP/GTPv2-C

S4 IP/UDP/GTPv2-C

S1-C IP/SCTP/S1AP

PDN GW MME

S6a IP/SCTP/DIAMETER

S3 IP/UDP/GTPv2-C

SGSN 2.5/3G Network

S10 IP/UDP/GTPv2-C

S13 IP/SCTP/DIAMETER

HSS

SGW

SGi IP

Internet

MME

A. LTE LTE is a wireless networking technology designed to provide subscribers with a secure high performance wireless 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 of the details of LTE can be distilled into three basic concepts: managing subscribers (or UE), managing bearer tunnels, and using bearer tunnels. Because LTE is an IP-only network, the primary job of the network is to provide IP packet delivery for the UE; this is the job of a bearer tunnel. The UE uses bearer tunnels to send and receive IP packets while moving through and between LTE networks. Bearer tunnels are adjusted to follow the UE as it moves through and between networks to always ensure a path for packet delivery. Finally, the UE must authenticate, authorize, and register themselves with the network in order to be tracked, create, and use these bearer tunnels. 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 functional elements of a LTE architecture and displays

EIR

Fig. 1.

LTE Architecture and Protocols

their reference point names. This figure also details the actual protocols being used over these reference points in an effort to be clear about their nature. The following paragraphs will describe how the three main functions of LTE are carried out by the LTE network elements depicted in Figure 1. NAS

UE

RRC PDCP RLC MAC PHY

Fig. 2.

eNB

S1AP SCTP IP

MME

Layer 2 Layer 1

UE to MME Control Signaling

The Mobility Management Element (MME) authenticates, 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. GTPv2C 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 PDWGW, 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 specific processes for establishing subscriber authenticity, session routing, inter-carrier routing, inter-carrier-roaming, intercarrier charging, and per session based QoS. The IMS architecture’s functional decomposition is represented in Figure 3. The core of a IMS network is powered

MRFC

SIP-AS

MRFP P-CSCF

HSS SGW

S-CSCF Provider Network

SLF PSTN MGCF

I-CSCF

BFCF MGW

Fig. 3.

IMS architecture

by Call Session Control Functions (CSCF). These servers provide a series of SIP services such as: registration, authentication, 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. However, deployment of the IMS architecture has not become a reality. The IMS architecture is complicated and deployment requires a substantial investment in network equipment, operational 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

MME

S-GW

P-GW

MCS/VLR

HSS

UE

eNB

MME

RNS

MSC/VLR

SGSN

S-GW

Extended Service Request

RA preamble

UE Context Modification Request

RA Response RRC Connection Establishment

UE Context Modification Response

RRC Connection Setup

RRC Connection Release

RRC Connection Setup Complete

S1 UE Context Release Request

Attach Request Identity Request

S1 UE Context Release Command

Identity Response

Release Access Bearers Request Release Access Bearers Response

S1 UE Context Release Complete

Authentication / Security

Random Access

Update Location Request

RRC Connection Request

Update Location Response

RRC Connection Setup

Create Session Request Create Session Request

RRC Connection Setup Complete

Create Session Response Create Session Response Location Update Request

CM Service Request

CM Service 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 Attach Complete

Modify Bearer Request Modify Bearer Response

UE

eNB

MME

RNS

MSC/VLR

SGSN

S-GW

Paging Request

CS Service Notification Extended Service Request

UE Context Modification Request

Fig. 4.

Combined EPS/IMSI attach procedure

UE Context Modification Response RRC Connection Release

A mobile device will connect to the LTE network in the same way as a standard LTE UE, but it will use a combined attach procedure and its capabilities will advertise CS fallback. The MME will then signal a location update to an MSC in the legacy GERAN or UTRAN network, which will hold the location of the mobile device in terms of CS services. The MSC and MME will serve as a bridge between the legacy and LTE networks. In our work we investigated the data flow of CSFB in three scenarios: UE attachment, UE originated phone call and UE 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. 1) UE Attachment: In CSFB mechanism, when UE requests to attach to EPS network, it performs a combined EPS/IMSI attach procedure. The purpose of the combined attach is to register UE at both EPS network and the legacy network. At the time of registration, UE who supports CSFB would send an attach request to EPS network with an indication that CSFB is used. When performing EPS attachment, EPS network receiving this indication should send message to the legacy network to inform that UE is connected to legacy network as well. The sequence diagram of combined EPS/IMSI attach procedure is shown in Figure 4. It can bee seen that this procedure is much the same as EPS attach procedure except that Mobility Management Entity (MME) sends Location Update Request to Mobile Switching Center (MSC)/Visitor Location Register (VLR) to attach UE to legacy network. 2) Mobile originating call: At the time when UE gives a call, it could either perform a PS handover or RRC release with redirection to legacy network. The difference between these two methods is that if PS handover is supported, it allows continuity for PS sessions when fallback. Here we only consider the sequence of fallback to UTRAN network without PS handover supported, which is the most common scenario.

S1 UE Context Release Request

S1 UE Context Release Command

Release Access Bearers Request Release Access Bearers Response

S1 UE Context Release Complete Random Access RRC Connection Request RRC Connection Setup RRC Connection Setup Complete

Paging Response

Paging Response CS call establishment procedure

Fig. 6.

Mobile terminating call procedure

The sequence diagram is given by Figure 5. Observe that this procedure is in four phases: 1) UE sends Extended Service Request to inform MME of the call; 2) EPS network releases RRC connection and all radio resources with UE; 3) UE creates RRC connection with the legacy network; 4) Call procedure in CS domain is performed to make the phone call. 3) Mobile terminating call: Mobile terminating call is much the same as mobile originating call. The only difference is that mobile terminating call procedure is triggered by the network, so there will be some notifications, such as paging message, to UE. When UE receives these notifications, it performs the same action as that in mobile originating call. Sequence diagram is given by Figure 6. 4) SMS: Receiving SMS messages do not require a fallback to the legacy network. The paging requests are forwarded through the LTE network in the same manner of the call, but instead of the UE transitioning to the legacy network to complete the request, it establishes a service request over the LTE network to the MME, and the message is forwarded from the MSC to the MME over the SGs interface, which is then forwarded to the UE over NAS. A mobile originated SMS

messages also involves a service request over the LTE network to the MME. The SMS is sent to the MME over NAS, which forwards the message to the MSC over the SGs interface, where the message is routed over the legacy network, and the report is send back via the reverse path.

EAP-AKA authentication procedure

UE VANC Discovery

EPS

DHCP

DNS

SeGW

VANC

AAA

HSS/ HLR

UE attaches to EPS UE obtains connectivity to VoLGA PDN DNS Query (SeGW Domain Name) DNS Response

B. VoLGA IKE_SA_INIT

VoLGA proposes to let a legacy MSC provide voice and SMS services to LTE UEs through either a GERAN A interface or UTRAN Iu-CS interface. This concept originates with Unlicensed Mobile Access (UMA). UMA was developed to support 2.5G/3G network extension using Wi-Fi as network access. Handsets that supported Wi-Fi would establish a IPSec ESP tunnel to a tunnel terminator in a service provider network that is directly connected to the legacy MSC. The tunnel terminator would also provide some interworking functionality to allow these IP based endpoints to appear as if they were connecting to the MSC using legacy interfaces. UMA was submitted and accepted as a standard in the 3GPP standards body and was renamed Generic Access Network (GAN) for Release 6. VoLGA was designed to have minimal impact on existing networks; however, it does require special support in the UE and the introduction of the VoLGA Access Network Controller (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 map voice traffic between the UE and MSC. The VANC performs authentication and authorization on incoming IPSec ESP tunnels using an authentication, authorization and accounting (AAA) server via the Wm interface. The VANC can connect to a GERAN network’s MSC using the A interface, or a UTRAN network’s MSC using the Iu-CS interface. Also, the VANC has the ability to interact with the LTE network and request QoS for VoLGA voice calls. Our work investigates the data flow of VoLGA in the following three scenarios: VoLGA registration, mobile originating call and mobile terminating call. The data flows are given in the following subsections respectively. 1) VoLGA registration: When a mobile device is powered on and detects a LTE network, it first registers with the Mobility Management Entity (MME). Then the MME procures 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 VoLGAenabled 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 connectivity 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.

IKE_SA_INIT IKE_AUTH (NAI on Idi, no AUTH included) Select AAA Server EAP Response Identity (NAI on IMSI)

EAP Request/AKA Challenge (RAND, AUTN, MAC, Next ID)

EAP Request/AKA Challenge (RAND, AUTN, MAC, Next ID)

Send AUTH Info (IMSI) Response (AUTH vectors)

Run UMTS Algorithms and verify AUTN EAP Response/AKA Challenge (RES, MAC) EAP Response/AKA Challenge (RES, MAC) Check MAC and verify RES EAP Success + keying material EAP Success Complete IKEv2 Signaling VoLGA Registration

Fig. 7.

VoLGA EAP-AKA procedure

VoLGA Registration Procedure

UE

EPS/GPRS

SeGW

DNS

VANC

HOSF(s)

1. Establish secure tunnel to SeGW 2a. DNS Query (VANC Domain Name) 2b. DNS Response 3. Establish TCP connection to VANC 4. GA-RC REGISTER REQUEST (UTRAN/E-UTRAN cell info, IMSI, GAN Classmark, ...) 5a. Activate dedicated bearer for signaling 5b. GA-RC REGISTER ACCEPT (“VoLGA System Information”) 5c. VANC-UE Binding Req VANC-UE Binding Res 6. GA-RC REGISTER REJECT (Reject Cause) 7. GA-RC REGISTER REDIRECT (VANC Address)

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 TCP IP IPSec ESP UDP

UE

VANC

IP Layer 2 Layer 1 Fig. 9.

VoLGA Signaling

Mobile Originated Call

UE

E-UTRAN

MME

S-GW

P-GW

PCRF

VANC

MSC

GA-CSR REQUEST GA-CSR REQUEST ACCEPT GA-CSR REQUEST REJECT GA-CSRDEDICATED

GA-CSR UPLINK DIRECT TRANSFER (CM Service Request)

Complete L3 Info (CM Service Request)

GA-CSR UL DIRECT TXR (Setup) GA-CSR DL DIRECT TXR (Call Proceeding) Assignment Request (call resources) Activate dedicated bearer for user data

GA-CSR ACTIVATE CHANNEL GA-CSR ACTIVATE CHANNEL ACK

RRC Connection Reconfiguration RRC Connection Reconfiguration Complete

Bearer Setup Request

Bearer Setup Response

Create Dedicated Bearer Request

Create Dedicated Bearer Response

Create Dedicated Bearer Request

Create Dedicated Bearer Response

IP-CAN session modification request PCRF requested IP-CAN session modification (begin)

Ack

PCRF requested IP-CAN session modification Notification of (end) bearer level event Ack

GA-CSR ACTIVATE CHANNEL COMPLETE Assignment Response GA-CSR DL DIRECT TXR (Alerting) GA-CSR DL DIRECT TXR (Connect) GA-CSR UL DIRECT TXR (Connect Ack) Voice traffic (via dedicated bearer)

Fig. 10.

VoLGA mobile originating call procedure

the UE’s operational mode, and provide keep-alives for the UE. A UE negotiates its operational mode so it can integrate with a MSC in GERAN A-mode, UTRAN Iu-CS mode, or both. Generic Access - Circuit Switched Resource (GA-CSR) allows for interworking with GERAN, while Generic Access - Radio Resource Control (GA-RRC) allows for interworking with UTRAN. Both GA-CSR and GA-RRC messages are used to establish voice bearers, tunnel NAS messages, and interwork with MSC signaling. Figure 9 depicts the signaling stack between a UE and the VANC server [13]. 2) Mobile Originating Call: Figure 10 shows the signaling exchange to establish a mobile originated voice call over LTE. Once a UE is registered with the VoLGA network, it can request a dedicated signaling connection with the MSC using either GA-CSR or GA-RRC depending on the negotiated mode of operation. Once a connection exists, CS-NAS messages can be tunneled between the MSC and the UE over the EPS bearer using Uplink (UL) and Downlink (DL) Direct Transfer

messages. A UE originated call will request service with a UL Direct Transfer (GSM/UMTS CM Service Request) to the VANC, which then forwards this request to the MSC over the A- or Iu- interface for this user. If it has not already done so, the MSC will authenticate the user and activates ciphering. The mobile device then sends a Setup message to the MSC via the VANC, providing details on the call, its bearer capability and supported codecs. The MSC acknowledges this through the Call Proceeding message, instructing the 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 exchange of IP packets containing voice data. Once the mobile is prepared through an uplink Real Time Protocol (RTP) path, an Assignment Response message is sent to the MSC. Once a call is established with the other party, the MSC notifies the UE through the Alerting (called party is ringing) and Connect (called party has answered) messages. Upon acknowledgement from the mobile device, a two-way connection is in place for voice conversation and this completes the call origination. Voice bearer is handled outside of the context of the IPSec connection between the UE and MSC. The UE and VANC will send and receive voice bearer using RTP. Voice is queued and framed at both the VANC and UE into RTP packets, which are forwarded to the negotiated UDP port and IP addresses. These address and port combinations are negotiated during the Activate Channel sequence between the VANC and UE. The VANC will then switch voice traffic between MSC’s circuit and UE’s RTP flows. 3) Mobile Terminating Call: Termination calls are supported in a similar manner except for the addition of the Paging message. From the MSC point of view, there is no connection established to the UE. So the MSC sends a paging message to the VANC, which is seen just as a GSM Base Station Controller (BSC) or UMTS Radio Network Controller (RNC). From the LTE network viewpoint, the paging message 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 a dedicated GA-CSR connection and sends back a paging response. If it has not already done so, the MSC authenticates the mobile device and then authorizes it to use the network. The rest proceeds in the much the same way as call origination. 4) Short Message Service (SMS): SMS messages can be handled in the VoLGA architecture through embedding of legacy SMS messages in Direct Transfer messages. C. VoLTE VoLTE is a initiative led by the GSM Association (GSMA) that aims to define exactly how an LTE operator deploys IMS to carry voice traffic. The initiative plans to develop specifications that clearly outline three types of IMS voice interactions: User to Network Interface (UNI), Network to Network Interface (NNI), and a roaming interface. These specifications would provide a clear list of IMS features that must be supported in order to provide a acceptable voice service. The UNI interface is addressed through the IR92

Mobile Terminated Call

UE

E-UTRAN

MME

S-GW

P-GW

PCRF

VANC

MSC Paging

GA-CSR PAGING REQUEST GA-CSR PAGING RESPONSE GA-CSRDEDICATED Complete L3 Info (Paging Response)

availability of system level API access on handsets. Also, this technique requires double bandwidth for every active call. LTE providers can provide enhanced QoS for selected VoIP vendors by defining any flow to the VoIP vendor’s network address range would receive a dedicated bearer with QoS via the LTE’s PDN-GW and/or PCRF capabilities.

GA-CSR DOWNLINK DIRECT TRANSFER (Setup) GA-CSR UL DIRECT TRANSFER (Call Confirmed) Assignment Request GA-CSR ACTIVATE CHANNEL GA-CSR ACTIVATE CHANNEL ACK

RRC Connection Reconfiguration RRC Connection Reconfiguration Complete

Bearer Setup Request

Bearer Setup Response

Create Dedicated Bearer Request

Create Dedicated Bearer Response

Create Dedicated Bearer Request

Create Dedicated Bearer Response

IP-CAN session modification request PCRF requested IP-CAN session modification (begin)

Activate dedicated bearer for user data (Setup RTP Stream)

Ack

There are currently four architectures that can provide voice and SMS services over a LTE network: Over-The-Top, VoLGA, CSFB, and VoLTE. Each solution presents different operational and technical tradeoffs. A. Comparison of CSFB with VoLGA

PCRF requested IP-CAN session modification Notification (end) of bearer level event Ack Assignment Response

GA-CSR UL DIRECT TRANSFER (Alerting) GA-CSR UL DIRECT TRANSFER (Connect) GA-CSR DL DIRECT TRANSFER (Connect Ack) Voice traffic (via dedicated bearer)

Fig. 11.

IV. S OLUTION C OMPARISON

VoLGA mobile terminating call procedure

specification that the GSMA published in March of 2010 [14]. The organization plans on releasing a NNI interface by mid2010, and a roaming interface by the beginning of 2011. The UNI specification presents a set of concrete requirements on IMS elements for a VoLTE architecture. For signaling the UE must support registration, origination, and termination as specified in the main IMS SIP specification [10]. Signaling compression must be used between the UE and the Proxy CSCF (P-CSCF), and it mandates a list of supplementary services (Hold, Message Waiting Indicator, etc). It requires the support of ‘Preconditions’ through the SIP Requires header. This header allows SIP devices to negotiate required SIP features during signaling interaction. It gives further requirements on specific Session Description Protocol (SDP) offer/answer sequences, RTP profiles, and RTCP usages. Generally, the UNI specification dictates a list of mandatory compliance sections from 3GPP specifications and outlines how certain features are to be used.

Here we present our methdology for comparing CSFB and VoLGA. We observe that both CSFB and VoLGA are trying to integrate with the 2.5G/3G environment to make voice calls. So they both engage in circuit switching call procedure at some point of their signaling sequence, which we view as a synchronization point. Without loss in generality, we say that the signaling in both strategies is the same after this synchronization point. Therefore, the real difference of the two strategies is the signals before circuit switching call procedure starts in legacy network. In this comparison we only take into account signals before this point, which are sufficient for comparing difference between performances of two strategies. Since entities in the specifications are all logical entities, we do not know in advance what the exact latency of communication between them is. For example, the MME and HSS could be either in the same phisical device or separate in two physical devices. Thus in our work we focus on performance analysis with respect to the number of RTTs it takes for communication between two logical entities in the procedures above. Procedure Attach

CSFB EPS attach + 1 RTT MME-MCS + CS domain Location Update procedure

Mobile Originating Call

1 RTT UE-MME + 1 RTT eNB-MME + 1.5 RTT UE-RNS + Random Access Procedure 1.5 RTT UE-MME + 1 RTT eNB-MEE + 1.5 RTT UE-RNS + Random Access Procedure

D. Over The Top Finally, any VoIP vendor can provide ‘Over-the-Top’ voice service to any LTE network user. The VoIP vendor would treat the network no differently than any other IP access medium. This solution would prohibit itself from supporting native handoff with legacy radio network such as GERAN and UTRAN. Handoff is possible through ‘Tromboning’, which is establishment of a default PSTN call-leg for non-LTE roaming, and a secondary VoIP call leg for LTE roaming. An AS will then switch media between the call legs based on the current location of the UE. But this technique is limited due to the

Mobile Terminating Call

VoLGA EPS attach + EPA-AKA authentication ( = 1 RTT UE-DNS + 3 RTT UE-SeGW + 2 RTT SeGWAAA Server + 1 RTT AAA-HSS + 2 RTT UE-VANC + 1 RTT VANCHOSF ) 2.5 RTT UE-VANC

1.5 RTT UE-VANC

IMS/VoLTE X X X X X CSFB X X * X X VoLGA X X X X X Over The Top X** X X X X If packet handoff is supported * Tromboning solution with 2 call legs

Modify Network Elements

New Network Elements

UE Support

Simultaneous V&D

Overlap

Handoff

B. Comparison of all four architectures

X X X X

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 mechanism 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 simplicity, 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

be complete till the beginning of 2011. It will take some time for interoperability to be established between vendors upon completion of the VoLTE specifications. This means VoLTE will be the last solution to the game as LTE deployments have started in 2010. V. C ONCLUSION Wireless broadband adoption and usage is growing beyond all expectations of operators and network equipment manufacturers. This growth has caused severe strain on the existing 2.5/3G wireless infrastructure, forcing carriers to deploy Wi-Fi based offload solutions in dense areas and upgrade their core 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; however, 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¨a, 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.