options for providing voice over lte and their impact on the gsm/umts network

S T R A T E G I C W H I T E P A P E R

Although the current LTE buzz is centered on data traffic, most GSM/UMTS MSPs are also

planning to provide wireless broadband voice services as LTE is introduced to GSM/UMTS

networks or shortly thereafter. How to provide voice over LTE is, however, not always

clear and a topic that is being heavily debated in the wireless industry: is there one best

option, or are certain options better suited to some MSPs than others? Three current

options — CS fallback, VoLGA, and VoIMS — are evaluated based on how they work, the

types of services they support, and network-implementation requirements. The implication

of the options and option combinations for roaming are also considered. Recommendations

are provided about which options are best suited as operators evolve to end-to-end LTE

and all-IP networks.

Options for Providing Voice over LTE and Their Impact on the GSM/UMTS Network

Table of contents

1 1.Introduction

1 2.ChangingmarketconditionsandLTE

3 3.OptionsforprovidingvoiceoverLTE

3 3.1 CS fallback

5 3.2 VoLGA

8 3.3 VoIMS

15 4.ComparisonofoptionsforvoiceoverLTE

15 4.1 Network-implementation requirements

16 4.2 Performance

17 5.VoiceoverLTEandroaming

18 6.Recommendations

19 6.1 CS fallback

19 6.2 VoLGA

19 6.3 VoIMS

20 7.Conclusion

21 8.Abbreviations

22 9.Contacts

22 10.References

Options for Providing Voice over LTE and Their Impact on the GSM/UMTS Network | Strategic White Paper 1

1. Introduction

Long Term Evolution (LTE) is fast approaching: Verizon Wireless and TeliaSonera recently announced LTE contract awards, NTT DOCOMO and Telefónica are already well underway with their LTE trials, and others, such as China Mobile and Vodafone, have made their LTE trial intentions public. The first commercial deployments and an increasing number of trials are expected in 2009.

Why all this interest? LTE, a set of enhancements to Universal Mobile Telecommunications System (UMTS), is being developed to provide the necessary bandwidth and quality of service (QoS) for the delivery of data-intensive applications, such as Multimedia Messaging Service (MMS) and mobile TV. LTE — the Evolved Packet System (EPS), which encompasses the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) and Evolved Packet Core (EPC) — promises to deliver higher throughput, lower latency, and larger bandwidth over a simple, flat IP architecture. LTE offers mobile service providers (MSPs) an avenue to profitably deliver next-generation wireless broadband services with an improved user experience at a reduced cost per megabit. In addition, LTE is being developed to seamlessly interoperate with all existing networks.

Global System for Mobile Communications (GSM)/UMTS MSPs have started or are about to start implementing LTE networks. Although their first consideration is data, voice is not far behind. However, how to provide voice over LTE is currently being heavily debated in the wireless industry. No matter how voice services are implemented, the LTE network must be efficient and cost-effective for both voice and data.

Is there one “best” option for delivering voice over LTE, or are certain options better suited to some MSPs than others? More specifically, what is the best choice for a GSM, UMTS or converged wireline/wireless operator? To help MSPs answer these questions, this paper examines the current options — circuit-switched (CS) fallback, Voice over LTE via Generic Access (VoLGA), and Voice over IP Multimedia Subsystem (VoIMS) — being proposed for the delivery of voice and other CS services — for example, Unstructured Supplementary Service Data (USSD), supplementary services, Customized Applications for Mobile network Enhanced Logic (CAMEL), Short Message Service (SMS), and CS data — over LTE, as well as their impact on the GSM/UMTS network. We evaluate and present recommendations about each option based on:

• How the option works

• Types of services supported

• Requirements for network implementation

• Advantages and disadvantages

With a better understanding of the options and their impact on GSM/UMTS networks, operators will be able to make more informed decisions and pick the options that are best suited to their networks when the time comes to implement voice over LTE.

2. Changing market conditions and LTE

What current market conditions are driving operators toward LTE? The answer is simple: the number of data subscribers and data usage per subscriber are exploding. FierceMobileContent reports that by the end of 2008, AT&T experienced 12 consecutive quarters of wireless data growth above 50 percent. Even in the midst of a weak economy, AT&T announced a year-over-year 38.6 percent increase in wireless data revenue for Q1 2009 while Verizon Wireless claimed 56.2 percent wireless data growth during the same period. According to projections by Ovum, mobile-broadband data will generate revenues of 139.7 billion United States dollars by 2014: an increase of 456 percent over 2008 (see Figure 1).

Options for Providing Voice over LTE and Their Impact on the GSM/UMTS Network | Strategic White Paper2

Changes in the way we communicate are fueling this explosion. Millennials, the demographic cohort with birth dates ranging from the mid 1970s to the early 1990s, are redefining the way consumers interact in both social and business settings. Millenials intuitively and rapidly adapt to new services and devices. They text, download music and videos, play games, and use social networking sites such as Facebook and MySpace to stay socially connected. With their high Internet content consumption, members of this group more than double the average subscriber’s mobile data usage. Moreover, as Millennials enter adulthood and the workforce, they are also changing the way enterprises communicate.

Rapid changes in wireless devices, enabling anytime/anywhere multimedia communications, have also played a major role in the data explosion. Some wireless devices are being integrated with cameras, video recorders, iPods and media players. Others, such as e-book readers, are not being integrated and are customized to deliver a high quality of experience for only one particular application. All these devices are simplifying multimedia communications, enabling it to flourish.

According to Ovum, the number of mobile broadband users will increase 1024 percent between 2008 and 2014. However, user growth will far outpace revenue growth, with revenue growing at just 44 percent of the rate of user growth from 2008 to 2014. Moreover, this growth is being driven by low average revenue per user (ARPU) consumers, not higher ARPU enterprise users (see Figure 2). MSPs are worried about these changing market conditions.

Figure 2. Mobile-broadband user-growth and ARPU projections

LTE is being heralded as the future technology to help MSPs successfully transform their networks to meet tomorrow’s communications demands. With this new technology, operators will have the high bandwidth and low latency necessary to offer increasingly complex data services, to differentiate services and remain competitive, all at a lower cost per megabit. LTE promises to be a more efficient, cost-effective network for both voice and data services.

Figure 1. Mobile-broadband data-revenue projections


3. Options for providing voice over LTE

Although the current buzz is centered on using LTE for data only, most MSPs are also planning to provide voice services as LTE is introduced into the network, if not at launch then sometime shortly thereafter. Some GSM/UMTS operators are planning to initially deploy LTE to cover high traffic areas or data hot spots, complementing High Speed Packet Access (HSPA)/Evolved High Speed Packet Access (HSPA+) and Enhanced Data rates for GSM Evolution (EDGE) coverage. Others are planning to introduce LTE in rural areas first to supplement EDGE. However, no matter where the operator begins, LTE will gradually be phased in throughout the whole network. For LTE to be successful during this phased deployment, operators must ensure voice service continuity with minimal service disruptions as subscribers roam between the LTE and GSM/UMTS networks.

Three options have been proposed for providing voice services as LTE is introduced into the network:

• CS fallback

• VoLGA

• VoIMS

3.1CSfallbackCS fallback supports voice services for LTE by reusing the GSM/UMTS network, as shown in Figure 3. Mobile devices, normally camped on the LTE network for data services, are forced to fall back to the legacy network when subscribers want to use CS services, such as voice, CAMEL services, and Group 3 Fax (G3 Fax). This option offers complete services and feature transparency by enabling MSPs to leverage their existing GSM/UMTS network for the delivery of CS services, including prepaid and post-paid billing.

Figure 3. Network implementation of CS fallback

3.1.1 How CS fallback works

RegistrationFor this option to work, a CS fallback-enabled device must register on both the LTE and GSM/UMTS networks, to insure that both networks are aware of its presence and location. However, the user equipment (UE) does not have to perform two registration procedures because the Mobile Management

MME

RNS

GSM/UMTS network

HSS EvolvedPacket

Core (EPC)

Circuitcore

PDN GW

MGW

Call server

S5/S8

S1-mme

A interface

IuCS

SGs

S1u

S11

S6a

Services

BSS

SGW

LTE network

E-UTRAN


Entity (MME), the key control node for the LTE network, efficiently performs a combined registration when the user terminal attaches to the LTE network. Registration on the GSM/UMTS network is triggered by an MME-initiated location update over the SGs interface to the mobile switching center (MSC). The Location Area ID (LAI), required for the location update, is calculated from its LTE equivalent, the Tracking Area ID (TAI).

Call origination and terminationFor call origination, the UE sends a service request with the CS fallback indicator to the MME, instructing it to perform a CS fallback. The MME then requests the Evolved Node B (eNode B) to redirect the mobile device to the GSM/UMTS network. To determine the target GSM/UMTS cell to which the UE should be moved, the eNode B may either solicit measurements from the mobile terminal or use its existing information about preconfigured cells. When the target cell has been identified, the eNode B triggers a cell change to the GSM/UMTS network by sending a Radio Resource Control (RRC) message to the UE. The mobile then moves to the new cell and performs a radio resource connection using the legacy procedures. In addition, before the call originates, a location update may be necessary if the LAI of the new cell differs from the one stored in the UE.

Fallback for call termination works in a similar fashion as for call origination. When a call comes in for the mobile device, the MSC sends a page request over the SGs interface to the MME. In return, the MME pages the mobile device in the LTE network with the core-network domain indicator set to CS in the paging message, indicating that the CS network originated the page. The eNode Bs to be paged are determined from the MME list of TAIs for the mobile device or from the location information sent in the MSC paging message.

When the mobile device responds with a service request that has a CS-fallback indicator, the MME instructs the eNode B to move the mobile device to the GSM/UMTS network by sending an initial UE context setup message. The eNode B determines which cell the mobile device should be moved to, in the same manner as with call origination, and then directs the UE to retune to the new cell. If the location area of the new cell differs from the one stored in the mobile device, a location update must be performed before the mobile device responds to the page to establish the call connection.

If the user has an active LTE data session when a voice call is initiated, the data session may be handed over to the GSM/UMTS network or dropped, depending on the characteristics of the network. If the fallback network is UMTS, the E-UTRAN will perform a packet-switched (PS) handover (PSHO), enabling the data session to continue during the duration of the voice call. However, if the fallback network is GSM, a PSHO may only occur if the GSM network as well as the user device supports Dual Transfer Mode (DTM), which enables voice and data calls to be handled simultaneously. Otherwise, the data session is suspended for the duration of the voice call.

At the completion of the call or CS service, the mobile device is moved back to the E-UTRAN, where LTE service is resumed if it was suspended during the CS session.

SMSThe mobile device does not have to fall back to the CS network when sending or receiving SMS messages. The MSC simply forwards the SMS to the MME using the SGs interface. When the subscriber originates a text message, the UE sends it to the MME, which then forwards it to the MSC over the SGs interface.

3.1.2 Network implementation of CS fallback

Terminals used for CS fallback must be able access the LTE as well as the GSM/UMTS networks. Although no changes are required to the 3rd Generation Partnership Project (3GPP) TS 24.008 client used for the GSM/UMTS network, enhancements must be added for CS fallback. Specifically, the mobile devices need to support the combined EPS/International Mobile Subscriber Identity (IMSI) attach, detach, and location-update procedures as well as the CS fallback and SMS procedures.


The network implementation of CS fallback requires enhancements to the MME, E-UTRAN, and MSC. The MME must not only support the SGs interface to the MSC, but also certain MSC procedures such as IMSI attach/detach, location update, and paging. In addition, the MME must be enhanced to support the CS-fallback SMS procedures as defined by 3GPP TS 23.272. The E-UTRAN must be upgraded to redirect the user device to the most suitable GSM/UMTS cell when CS services are required. The E-UTRAN must also be enhanced to forward page requests and SMS to the UE.

In the legacy network, the MSCs in the LTE coverage area must be upgraded to support CS fallback. Required enhancements include support for:

• SGs interface to the MME

• Simultaneous paging on the A, Iu, and SGs interfaces

• Sending and receiving SMS over the SGs interface

The operator must ensure that the capacity of the MSCs and radio access networks (RANS), over-laying LTE coverage, is sufficient to accommodate the increased traffic load from the LTE network.

CS fallback requires some network-engineering considerations. LTE coverage areas must be engi-neered to overlap with that of the GSM/UMTS network to allow LTE subscribers to easily retune or hand over to the GSM/UMTS network for voice services. In addition, LTE tracking areas must be configured geographically similar to the location areas used in the GSM/UMTS network because the MME uses the TAI to derive the LAI used by the GSM/UMTS network.

3.1.3 Pros and cons of CS fallback

CS fallback extends the life of the GSM/UMTS network by enabling it to provide voice services for the LTE network. GSM/UMTS components such as MSCs, CS service platforms, operations sup-port systems (OSSs), and prepaid/post-paid billing systems are all reused, ensuring a fast and quality rollout of voice services for LTE. No new network elements need to be added, and required upgrades to existing network nodes are relatively minor compared to the other options. CS fallback changes to the MSC are not complicated because the SGs interface was purposely based on the Gs interface that is currently used between the MSC and Serving GPRS Support Node (SGSN). Handsets reuse the GSM/UMTS client with only a few added enhancements for CS fallback.

Another benefit of CS fallback is that it provides complete service and feature transparency with the GSM/UMTS network because the LTE subscriber is redirected to the GSM/UMTS network for all CS services.

Conversely, CS fallback is quite signaling-intensive and fallback may take a while to complete, with estimates placing it at about 500 ms. In addition, this delay may be increased if the mobile device must conduct measurements to find a suitable GSM/UMTS cell to use and must then perform a location update before being able to originate or answer a call. This call setup delay may be enough to be noticed by some LTE subscribers.

Another disadvantage of CS fallback is that, while CS fallback supports concurrent voice and data on hand-downs to UMTS and GSM with DTM, CS fallback does not support concurrent voice and data when handing down to a GSM network without DTM: the PS session is simply suspended.

3.2VoLGAVoLGA provides voice services for LTE access by leveraging the operator’s existing GSM/UMTS voice core, including the MSCs and all existing OSSs. This option, based on 3GPP TS 23.879 option 2, with further development by the VoLGA Forum, uses a new dedicated Interworking Function (IWF), also known as VoLGA Access Network Controller (VANC), to interwork the LTE and GSM/UMTS networks. Inserted between the EPS and MSC, the VANC provides an LTE overlay access pipe from the terminal to the MSC. Circuit-Switched Non-Access Signaling (CS NAS) from


the terminal, used for second-generation/third generation (2G/3G) call set-up, along with the CS voice stream, is transported transparently over the LTE data bearer to the VANC, where it is interworked to the A or Iu interface for transport to the GSM/UMTS MSC (see Figure 4).

Figure 4. Network implementation of VoLGA

3.2.1 How VoLGA works

RegistrationA subscriber must first be registered on the LTE network and for VoLGA service before he/she can place or receive voice calls on a VoLGA-enabled terminal. After obtaining connectivity to the assigned VoLGA PDN, the user terminal performs the VANC discovery procedure to obtain the IP addresses of the VoLGA security gateway and the VANC that it will use for VoLGA registration. The user terminal then establishes a secure tunnel to the security gateway followed by a Transmission Control Protocol (TCP) connection to the VANC before attempting to register. A successful registration results in VANC authorization of the VoLGA signaling flow for the mobile device and maintenance of the established secure tunnel and TCP connection for the duration of the registration.

Call origination and terminationBefore a mobile device can use any CS service, such as originating or terminating a voice call, it must first establish a dedicated Generic Access - Circuit-Switched Resources (GA-CSR) signaling connection to the VANC, which is then used for the exchange of GA-CSR messages between the two. These messages transport encapsulated CS NAS signaling, used for mobile-to-MSC communications, over the EPS bearer.

Upon call origination, the UE requests service by sending an encapsulated CM service request message to the VANC, which then forwards the request to the MSC using the A or Iu interface. If it has

MME

RNS

GSM/UMTS network

HSS

EvolvedPacket

Core (EPC)

Circuitcore

PDN GW

MGW

Call server

S5/S8

Sv

SGi Z1

Z1

S1-mme

A interface

IuCS

IuCS or A interface

S1u

S11

S6a

D’ Wm

Services

BSS

AAA server

SGW

LTE network

E-UTRAN

VANC withSeGW


not already done so, the MSC authenticates the mobile device and authorizes it to use the network. A set-up message is then sent from the mobile device to the MSC via the VANC, instructing the MSC to originate a call. Upon receipt of the set-up message, the MSC instructs the VANC to establish the call-bearer connection. The VANC assigns resources to the call and sends the handset the necessary information it needs to establish the uplink Real Time Protocol (RTP) path. Once the path is established, the VANC completes the call bearer set-up by establishing the downlink connection. The MSC then notifies the mobile device that the called party is ringing and, upon answer, establishes a two-way audio connection to complete the call origination.

When a call arrives at the MSC for a VoLGA subscriber, the MSC pages the mobile device via the VANC. The mobile device establishes a dedicated GA-CSR connection and sends back a page response. If it has not already done so, the MSC authenticates the mobile device and authorizes it to use the network, before initiating call set-up. The VANC is instructed to set up the RTP streams between itself and the mobile device just as with call origination. When the voice bearer has been established, the mobile device rings the subscriber and sends back an alerting message to the MSC via the VANC. The MSC then notifies the calling party by sending it an alerting message. Upon answer, the mobile device sends a connect message via the VANC to the MSC, which it then forwards to the calling party, before establishing a two-way audio connection to complete the call termination.

LTE-to-GSM/UMTS handoversVoLGA supports handovers from LTE to the GSM/UMTS network. When the E-UTRAN detects the need for a handover based on measurement reports received from the mobile device, it sends a handover-required message to the MME, initiating the process. The MME, in turn, informs the VANC that a handover is required by sending it a Single Radio Voice Call Continuity (SRVCC) PS-to-CS request message over the Sv interface. The VANC converts this request into a CS hand-over request and sends it to the MSC, instructing it to prepare for handover. When preparations are complete, the MSC informs the VANC that it is ready for handover. The VANC notifies the MME, which then commands the UE, via the E-UTRAN, to hand over to the GSM EDGE Radio Access Network (GERAN)/UMTS Terrestrial Radio Access Network (UTRAN). With completion of the handover, the VANC clears all resources used by the call and instructs the MME to do the same by sending an SRVCC PS-to-CS complete notification. At this point, the VANC may also deregister the UE and release the VoLGA signaling bearer.

If a data session is concurrently active with the voice call, it may be handed over to the GSM/UMTS network or suspended, depending on the characteristics of the network. If the handover is to UMTS, the E-UTRAN also performs a PS handover, enabling the data session to continue along with the CS voice call. However, if the handover is to GSM, a PS handover only occurs if the GSM network as well as the terminal supports DTM. Otherwise, the data session is suspended.

SMSSMS works in a similar manner as call originations and terminations. The UE first establishes a dedicated GA-CSR signaling connection to the VANC, over which it requests SMS service or responds to an SMS page sent by the MSC via the VANC. As with call set-up, SMS messages are also encapsulated in the GA-CSR messages for transport over the EPS bearer.

3.2.2 Network implementation of VoLGA

Terminals used for VoLGA must be able to access the LTE as well as the GSM/UMTS networks. As with CS fallback, no changes are required to the 3GPP TS 24.008 client, but specific support must be added for VoLGA and SRVCC. These devices must be able to transport CS NAS signaling as well as the CS voice stream over the EPS bearers — that is, over an IP connection. VoLGA-enabled terminals must also be able to determine if the serving network supports VoLGA services and to negotiate use of the A or Iu interface for MSC communications. In addition, VoLGA-enabled terminals must support VANC discovery and registration as well as handovers from the LTE network to GSM/UMTS, reusing the SRVCC mechanism as specified for the EPS.


VoLGA network implementation requires three new network elements:

• VANC– At the heart of the VoLGA network implementation, interworking the VoLGA-enabled terminals that access the EPS network via LTE to the CS services provided by the GSM/UMTS network

• Securitygateway– May or may not be integrated with the VANC; terminates a secure, remote-access tunnel from the user device and provides authentication, encryption and integrity protection for the signaling traffic

• Authentication,authorizationandaccounting(AAA)server– Used for user-equipment authentication, which is performed after the user device has established a secure tunnel to the security gateway

The impact of VoLGA on the EPS network is minimal. To enable handovers from the LTE network to GSM/UMTS, the E-UTRAN and the MME both must support SRVCC according to 3GPP TS 23.216. The MME must also support the Sv interface to the VANC. VoLGA requires no additional functionality on the Serving Gateway (SGW) and PDN gateway (PDN GW).

VoLGA support requires no changes to the GSM/UMTS MSC. Because the VANC is perceived as a base station controller (BSC)/radio network controller (RNC) by the GSM/UMTS MSC, VoLGA service delivery is transparent to the CS network. However, all VoLGA-enabled MSCs must be resized to accommodate the increased traffic load from the additional A or Iu interfaces.

3.2.3 Pros and cons of VoLGA

A major benefit of VoLGA is that it enables MSPs to quickly start offering voice services with LTE access by leveraging operators’ existing GSM/UMTS voice core assets with no required upgrades. Operators do not have to introduce IMS to the network or make the resulting changes to back-office support systems, such as billing, subscriber management and customer care. Instead, VoLGA delivers the same stable and proven CS services used in the GSM/UMTS network to LTE with a seamless user experience. VoLGA also provides excellent LTE-to-GSM/UMTS handovers because it is CS-based.

Like CS fallback, VoLGA offers complete CS service transparency between the LTE and GSM/UMTS networks. However, VoLGA offloads voice traffic from the GSM/UMTS access network to LTE, whereas CS fallback does not. VoLGA also supports simultaneous LTE data and CS voice as well as faster call set-up times because the user device stays within the LTE domain.

A major disadvantage of VoLGA is that standards have not been accepted by 3GPP. Although the standards are progressing in the VoLGA Forum, there is no guarantee that it will eventually be adapted by 3GPP. If VoLGA fails to be accepted at large by the wireless industry, VoLGA-enabled terminals and network equipment may be slow coming to market. In addition, operators deploying multivendor-based VoLGA solutions may experience more interoperability issues than if they deploy 3GPP-compliant solutions.

VoLGA also offers a somewhat complicated architecture and signaling scheme because it introduces three new network elements: the VANC, security gateway, and AAA server. The required terminal modifications are also more extensive than those required for CS fallback.

Finally, VoLGA does not support advanced blended IMS services, which are viewed as a differentiator for LTE.

3.3VoIMSViewed as the long-term, strategic solution for LTE, VoIMS uses IMS call control as defined by 3GPP TS 23.228 for LTE voice-services delivery. IMS provides legacy voice services, such as basic voice orig-ination/termination, calling line identification, and supplementary services, as well as value-added,


advanced multimedia services such as video sharing by supporting media additions and subtractions at any time during the call. Moreover, VoIMS is expected to be widely deployed, assuring coverage for LTE subscribers whether at home or roaming. Figure 5 shows the basic network implementation.

Figure 5. Network implementation of VoIMS

GSM/UMTS CS service continuity is implemented with the aid of IMS Centralized Services (ICS) and SRVCC, which ensures service continuity and feature transparency for subscribers roaming between a LTE network without complete national coverage and a nationwide GSM/UMTS network. Optionally, as shown in Figure 6 and avoiding the use of ICS and SRVCC, HSPA+ enables the implementation of VoIMS with UMTS PS access, allowing voice, data and multimedia services to be carried simultaneously over the same PS-domain IP connection. VoIMS implemented with both LTE and HSPA+ enables end-to-end IP concurrent voice and data multimedia services as well as seamless mobility between the LTE and UMTS networks with the use of PS handovers and handbacks.

Figure 6. VoIMS for UMTS PS voice-services delivery

MME

PCRF

HSS IMScoreEvolved

PacketCore (EPC)

PDN GW

MGW

CSCF

TAS

ISC

Sh

Mg

S6a

S5/S8

SGi

RxS1-mme

S1u

S11 Gx

Cx

MGCF

SGW

LTE network

E-UTRAN

MME

RNS

UMTS network

PCRF

HSS IMScoreEvolved

PacketCore (EPC)

PDN GW

MGW

CSCF

TAS

ISC

Sh

Mg

S6a

S4

S3

S5/S8

SGi

RxS1-mme

Giinterface

IuPS

Indirecttunnel

Directtunnel

S1u

S11

S12 (if direct tunnel)

Gx

Cx

MGCF

SGSN GGSN

SGW

Packetcore

LTE network

E-UTRAN


In the case of GSM/UMTS CS-service continuity, ICS ensures that VoIMS users experience the same, consistent voice services whether they are on the LTE or GSM/UMTS network, by transparently connecting the GSM/UMTS access network to IMS call control via CS bearers. SRVCC provides network-controlled handovers for efficient call continuity, eliminating the need for UEs to simultaneously attach to two different access networks.

There are two ways of implementing ICS: MSC or UE-based. With MSC-based ICS, the MSC acts as a Session Initiation Protocol (SIP) user agent for the UE, interworking the CS signaling used for MSC-to-UE communications to SIP, which is used for MSC-to-IMS communications. With UE-based ICS, the ICS function is supported directly by the UE using a dedicated client in the mobile device itself.

UE-based ICS implements IMS call control for GSM/UMTS access with SIP signaling between the UE and the IMS core, carried over the existing transport capabilities of the GSM/UMTS network. For networks that support simultaneous PS and CS services, the IP connection is provided by the legacy packet core as per the Gm reference point, as shown in Figure 7.

Figure 7. VoIMS implementation using Gm reference point

Otherwise, ICS SIP signaling is transported over the USSD control stream as per the I1 reference point, as shown in Figure 8. This version of ICS will be standardized in 3GPP IMS Release 9. The MSC manages CS-bearer establishment for the transport of the voice stream.

MME

RNS

UMTS network

PCRF

HSS SCC andSRVCC AS

IMScore

EvolvedPacket

Core (EPC)

Circuitcore

PDN GW

MGW

MGW

Call server

LTE network

E-UTRAN

CSCF

TAS

ISC

ISC

Sh

Mg

ShS6a

S5/S8SGi

Rx

S1-mme

IuCS

ISUP

Giinterface

Gm referencepoint betweenUE and CSCFIuPS

S1u

S11 Gx

Cx

Sv

MGCF

Services

CSCFSGSN

SGW

Packetcore

CS bearer pathbetween UE and IMS


Figure 8. VoIMS implementation using I1 over USSD

UE-based ICS is considered more deployable than its MSC-based counterpart. The MSC-based method requires a significant investment by MSPs for ICS upgrades to all MSCs in their network. In addition, to support roaming, all MSCs in their roaming partners’ network must also be upgraded. In contrast, only the handsets must be upgraded in a UE-based network. Because coverage is not limited to only ICS-enabled MSCs, service can be spread across a wider geographical footprint, and UE-based ICS supports ICS services even when the subscriber is roaming.

For these reasons, and because the USSD method will not be standardized until 3GPP IMS Release 9, this paper only describes a UE-based ICS model and the Gm-interface implementation method.

3.3.1 How VoIMS works

RegistrationVoIMS-enabled UEs, whether using the LTE or UMTS PS access networks, always register on the IMS network and receive all data and voice services from IMS. This is also the case for VoIMS/ICS/SRVCC-enabled UEs using the LTE or GSM/UMTS CS access networks. For ICS and SRVCC-enabled UEs, ICS and SRVCC indicators are also included in the registration message. The ICS indicator no-tifies both the Serving - Call Session Control Function (S-CSCF) and the Service Centralization and Continuity Application Server (SCC AS) that the UE possesses ICS capabilities, while the SRVCC indicator informs the eNode B and MME that the UE is capable of performing SRVCC handovers.

Session/call origination and terminationWhen a mobile device originates or terminates a voice session on the IMS network using LTE or UMTS PS access, the session is set up according the standard originating or terminating IMS procedure, as described in 3GPP TS 23.228. For voice calls involving a VoIMS/ICS-enabled UE, the S-CSCF also inserts the SCC AS into the IMS session path to provide ICS.

MME

RAN

GSM/UMTS network

PCRF

HSS CSCF

IMScore

EvolvedPacket

Core (EPC)

Circuitcore

PDN GW

MGW

MGW

Call server

LTE network

E-UTRAN

SCC andSRVCC AS

TAS

ISCISC

Sh

Mg

ShS6a

S5/S8SGi

Rx

S1-mme

IuCS

ISUP

I1/USSD betweenUE and CSCF

CS bearer pathbetween UE and IMS

S1u

S11 Gx

Cx

Sv

MGCF

HLR

SGW


For ICS-based session origination in the GSM/UMTS CS network, the ICS-enabled UE first sets up a service-control signaling path to the SCC AS via the legacy packet core and the Gm interface and then a CS bearer-control signaling path to the MSC, using standard CS legacy-network procedures. The SCC AS combines the SIP signaling received over the Gm interface with a description of the bearer established via the CS network to form the CS-access leg of the session. Using SIP signaling on behalf of the UE, the SCC AS then establishes the remote IMS leg of the session and presents it to the CSCF for standard IMS handling.

For session termination to an ICS-enabled UE in the GSM/UMTS network, the SCC AS selects a con-tact address from the pool of registered addresses it contains for the UE, followed by the access network to be used for the session delivery. The IMS terminating session is then initiated toward the UE’s selected contact address, with the indicator set to “CS bearer”. Upon receiving the invite message, the ICS-enabled UE originates a CS call to the SCC AS using its associated directory number. In the same manner as with session origination, the SCC AS combines SIP signaling with the description of the CS bearer to establish the CS leg of the session termination. Using SIP signaling on behalf of the UE, the SCC AS then establishes the IMS leg of the session and presents it to the CSCF for standard IMS handling.

HandoversLTE to UMTS PS handoversLTE to UMTS PS handovers provide excellent handovers between the two networks, with voice and data calls being simultaneously handed over. Because a voice call is kept as Voice over IP (VoIP) under IMS control, the call can be quickly and seamlessly handed over without the need to use SRVCC. The handover is initiated by the eNode B when it sends a request to the MME to establish resources in the target RNC, SGSN and SGW. The MME only needs to coordinate and perform a PS handover. Because both the voice and non-voice sessions are over PS, there is no separate CS session to hand over. One of two methods may be used to set up the path:

• Direct tunnel from the SGW to the RNC via an S12 interface

• Indirect tunnel from the SGW to the SGSN to the RNC, as shown in Figure 6

After selecting/reserving the path and the radio access bearer (RAB) in the UMTS PS network, the MME commands the handover. The eNode B then instructs the UE to hand over to the target cell in the UMTS network. Upon successful completion of the handover, the RNC sends a completion message to the SGSN, which in turn sends it to the MME.

SRVCC-based handoversSRVCC enables calls to be seamlessly handed over from the LTE to the GSM/UMTS access network, while session/call control remains in IMS. SRVCC handovers are triggered by the E-UTRAN based on the measurement reports it receives from SRVCC-enabled UEs. When a handover is required, the E-UTRAN requests the MME to initiate a handover to the target cell. The MME then separates out the voice bearer from the non-voice bearers and starts the handover procedure with both the MSC and SGSN.

Upon receipt of handover notification, the MSC instructs the target Radio Network Subsystem (RNS) to prepare for the handover by allocating the necessary resources. When the resources have been reserved, the MSC initiates the IMS session transfer to the CS domain. Standard IMS service-continuity procedures are executed in the IMS domain according to 3GPP TS 23.292 and TS 23.237. When complete, the CSCF switches the VoIP call to the CS access leg that has been established for the handover. The MSC then informs the MME that it is ready for the handover to proceed.

If the UE has simultaneous PS and CS sessions, the SGSN also requests the RNS to allocate resources. After the RNS has coordinated the CS and PS relocation request and assigned the required resources, it notifies the SGSN, which then notifies the MME that it is also ready for the handover.


The MME synchronizes the CS and PS relocations and instructs the E-UTRAN to hand over. The UE then hands over to the RNS when instructed to do so by the E-UTRAN. Upon detecting that the handover has occurred, the RNS informs the MSC and SGSN that the handover is complete, signaling to the MSC to connect the call. Both the MSC and SGSN then notify the MME that the handover has been successfully completed.

As already stated, if a PS session is concurrently active with the voice session, it is also handed over to the GSM/UMTS network, but only if the legacy network supports it. If the handover is to UMTS, the E-UTRAN performs a PS handover, enabling the data session to continue along with the CS voice call. However, if the handover is to GSM, a PS handover may only occur if the GSM network and the UE support DTM. Otherwise, the data session is suspended.

SMSSMS delivery to a UE in the LTE/IMS network requires the use of the IP Short Message Gateway (IP-SM-GW), as defined by 3GPP TS 23.204 Release 7. This gateway is required for SMS message delivery between the SMS Center and any IP-based UE. When the IP-SM-GW receives a message from the SMS Center, it forwards it to the CSCF, which in turn delivers it to the UE. If the UE is roaming in the GSM/UMTS network, the CSCF uses the Gm interface for message delivery.

Because the IP-SM-GW may deliver SMS messages using the IMS, PS or CS domains, the UE receives its SMS on the IMS, UMTS or GSM network. The IP-SM-GW attempts SMS delivery in the order set by the operator policy and/or user preferences. For example, the IP-SM-GW may first attempt SMS delivery on the LTE/IMS network, followed by the packet core, and finally by the circuit core.

3.3.2 Network implementation of VoIMS

VoIMS with LTE access only VoIMS network implementation requires the deployment of the IMS core — CSCF, Telephony Ap-plication Server (TAS), and other components — if not already present in the network, along with all necessary changes to the back-office systems. VoIMS terminals must also support the IMS mobile client.

In addition, an IP-SM-GW is required for the support of SMS. An upgrade may also be necessary to the Home Subscriber Server (HSS) to support the presence of the new IP-SM-GW in the network.

VoIMS with LTE and UMTS PS access Implementation of VoIMS with both LTE and UMTS PS access requires upgrades to the UTRANs in the GSM/UMTS network and may also require an upgrade to the SGSNs if the indirect tunneling method is used.

The UTRAN not only requires an upgrade to 3GPP Release 8, but must also support Robust Header Compression (ROHC) and a radio allocation process that offers semi-persistent scheduling. The UTRAN must also support the S12 interface between the RNC and SGW used for the direct tunneling method.

The SGSN must also be upgraded to 3GPP Release 8 to support the S4 interface to the SGW. This interface is used for the indirect tunneling method.

VoIMS with ICS and SRVCCFor VoIMS implemented with ICS and SRVCC, the terminals must also support the ICS and SRVCC clients. ICS enhancements include support for establishing the service-control signaling path used for SCC AS communications and the bearer-control path used to set up the CS bearer through the CS domain, as well as support for selecting the access domain for session originations and terminations. For SRVCC, the terminal must be able to indicate to the EPS that SRVCC is to be used for handovers to the GSM/UMTS network.


On the IMS network, VoIMS implementation with ICS and SRVCC requires the addition of two IMS application servers: SCC AS and SRVCC AS. These may be separate servers or combined into one server. For VoIMS GSM support, the SCC AS along with the MSC and Home Location Register (HLR) must support USSD.

SRVCC also requires upgrades to the E-UTRAN, MME and HSS in the LTE network. The E-UTRAN and HSS require relatively minor upgrades to support the SRVCC parameters. The MME requires more extensive work because it must separate voice from non-voice PS bearers, initiate the SRVCC handover procedure to the target MSC over the Sv interface, and coordinate the CS and PS hand-overs when both are performed together.

On the GSM/UMTS network, a Media Gateway Control Function (MGCF) that can optionally be integrated with the MSC is required for the establishment of IMS interconnections. To support SRVCC handovers, the MSC must be upgraded with the Sv interface and must support coordination of the SRVCC relocation and session transfer procedures. Upon successful relocation, the MSC must also be able to automatically register the UE with the HLR. The HLR may also need upgrading to support the new IP-SM-GW in the network.

3.3.3 Pros and cons of VoIMS

Globally accepted as the end-goal solution for the support of voice services over LTE, VoIMS completely utilizes the LTE/IMS network, delivering the full operational cost savings of using a flat, all-IP network. VoIMS offers conversational services and enables MSPs to introduce new revenue-generating, advanced voice and data blended services. A good example is the GSM Association (GSMA) Rich Communication Suite (RCS), which includes applications such as image and video sharing, presence, chat, and network address book. In addition, service providers have the potential to offer converged fixed and mobile services on their wireline and wireless networks using VoIMS.

If an MSP has also implemented VoIMS with UMTS PS, PSHOs between the LTE and UMTS networks will likely be smoother than those provided by SRVCC. In addition, because this imple-mentation supports LTE-to-UMTS handovers and handbacks, UMTS is well-suited for handling small coverage holes in the LTE network. VoIMS implemented with LTE and UMTS PS access provides excellent concurrent voice and data handovers because both voice and data are handled over a single PS domain.

With VoIMS implemented with ICS and SRVCC, the subscriber experiences the same voice services on the LTE or GSM/UMTS network: he/she has a single directory number, dialing plan, voice mail, set of subscriber services, and so on. Moreover, VoIMS implemented with ICS and SRVCC enables operators to introduce advanced blended services that are transparent to the access network.

However, VoIMS requires a sizable investment in the LTE network because the MSP needs to deploy the IMS core — CSCF, TAS, and other components — as well as the IP-SM-GW. The HSS may also require an upgrade for IP-SM-GW support.

If VoIMS is also being deployed with ICS and SRVCC, the SCC and SRVCC ASs are required as well as SRVCC upgrades to the E-UTRAN and MME. In legacy networks, the implementation of ICS and SRVCC requires the deployment of an MGCF and upgrades to all MSCs bordering the LTE/IMS networks for support of the Sv interface. An HLR upgrade may also be necessary to support the IP-SM-GW.

Because SRVCC signaling is complicated, LTE subscribers may experience a possible break in the voice stream when a session/call is handed down to the GSM/UMTS network. However, SRVCC performance can likely be optimized over time.


4. Comparison of options for voice over LTE

To best answer how these options compare to each other, each option must be analyzed according to:

• Network-implementation requirements

• Performance

4.1Network-implementationrequirementsTable 1 provides a summary of the requirements for network implementation of the voice over LTE options.

Table 1. Voice over LTE options: network-implementation comparison

REQUIREMENT CS FALLBACK VoLGA VoIMS

VoIMS LTE VoIMS UMTS PS VoIMS GSM/UMTS CS (ICS AND SRVCC)

New network equipment None • VANC• Security gateway• AAA server

• IMS core• IP-SM-GW

• IMS core• IP-SM-GW

• IMS core• IP-SM-GW• SCC and SRVCC AS• MGCF

Legacy network upgrades All MSCs overlaying LTE coverage

None None • UTRAN• SGSN for indirect

tunneling method

• Only MSCs at LTE edge

• HLR

EPS and/or IMS upgrades • E-UTRAN• MME

• E-UTRAN• MME

• HSS • HSS • E-UTRAN• MME• HSS

3GPP compliance for IOT ease Yes No• Standards advanced

by VoLGA Forum

Yes Yes Yes

Terminal changes Likely small• CS-fallback support

Likely substantial• VoLGA support• SRVCC support

Likely small• IMS client

Likely small• IMS client

Likely substantial• IMS client• ICS support• SRVCC support

LTE and GSM/UMTS coverage engineering considerations

• Requires LTE and GSM/UMTS coverage overlap

• Similar configuration for tracking and location areas

None None None None

IOT – interoperability testing

4.1.1 CS fallback

The network implementation of CS fallback is relatively simple, requiring a comparatively low level of investment. With CS fallback, no new network nodes are required: just an upgrade to all MSCs serving the LTE network area as well as upgrades to the E-UTRAN and MME. In addition, when the LTE network is deployed, its coverage area must be engineered to overlap with that of the GSM/UMTS network. Terminal changes for CS fallback are also minor, making this option relatively easy to implement.

4.1.2 VoLGA

Implementation of VoLGA is more complicated than CS fallback and likely requires a larger invest-ment. Although there are no changes to the legacy voice core, VoLGA requires the deployment of new network nodes: the VANC, security gateway, and AAA server. Upgrades are required on both the E-UTRAN and MME. Changes required to UE to support VoLGA are also likely larger than those required for CS fallback.

Another factor to consider is that the VoLGA standard is only being advanced by the VoLGA Forum because it is currently blocked in 3GPP. If this standard fails to be accepted at large by the wireless industry, VoLGA-enabled terminals and network equipment may be slow to market. In addition, an


operator deploying a multivendor-based VoLGA solution may experience more interoperability issues than if deploying a 3GPP-compliant solution.

4.1.3 VoIMS

The implementation of VoIMS requires a larger investment and network changes than the other options: the IMS core, if not already present in the operator’s network — such as for UMTS GSMA RCS or wireline voice services — needs to be deployed along with all necessary changes to the back-office systems. In addition, an IP-SM-GW is required for SMS support.

An upgrade to the UTRAN is required if VoIMS is to also be deployed with UMTS PS access. In addition, if indirect tunneling is to be used, the SGSN requires an upgrade to 3GPP Release 8.

If VoIMS is being implemented with ICS and SRVCC, new SCC and SRVCC AS network nodes must also be deployed along with upgrades to both the E-UTRAN and MME. On the legacy network, if an MGCF is not already present, it must be deployed and upgrades made to all MSCs at the edge of the LTE network to support SRVCC. The HLR may also require an upgrade to support the addition of the new IP-SM-GW in the network.

Because VoIMS is the end goal for LTE, not an interim solution like CS fallback or VoLGA, an investment in it is largely future-safe and will serve the operator well for many years to come.

4.2PerformanceTable 2 provides a summary of performance factors for the voice over LTE options.

Table 2. Voice over LTE options: performance comparison

PERFORMANCE FACTOR CS FALLBACK VoLGA VoIMS

VoIMS LTE VoIMS UMTS PS VoIMS GSM/UMTS CS (ICS AND SRVCC)

Network providing voice services GSM/UMTS GSM/UMTS IMS IMS IMS

Network providing voice radio coverage GSM/UMTS LTE LTE UMTS GSM/UMTS

Network providing SMS GSM/UMTS, but user remains on the LTE network

GSM/UMTS, but user remains on the LTE network

LTE/IMS network LTE/IMS network LTE/IMS network

Quality of voice call set-up Some delay Excellent Excellent Excellent Excellent

Quality of LTE-to-GSM/UMTS voice handovers

N/A Excellent – CS based N/A Excellent, PS-based Possible break in voice stream with SRVCC handover

Support for in-call handbacks No No No Yes Yes: 3GPP Release 10

Support for concurrent voice and data • No for GSM• Yes for UMTS

Yes Yes Yes Yes

Support for advanced services No No Yes Yes Yes

Operational benefit of flat all-IP network

No: LTE access and IMS not used

Partial: uses LTE access, but not IMS

Yes Partial: uses IMS, but UMTS PS access

Partial: uses IMS, but GSM/UMTS access

4.2.1 CS fallback

CS fallback is a relatively simple, 3GPP-based solution to temporarily provide voices services over LTE, reusing the GSM/UMTS voice core and access. Users are handed down to the legacy network for all call originations and terminations. SMS, on the other hand, uses the LTE network whenever it is available so that no fallback is required. CS fallback is simple but does not benefit from the operational efficiencies of an LTE network. Users may notice the additional delay associated with voice call set-up. In addition, CS fallback does not support advanced blended services or concurrent voice and data services for GSM networks without DTM.


4.2.2 VoLGA

VoLGA is more complicated than CS fallback: it relies on the legacy GSM/UMTS CS core to provide voice services as does CS fallback, but it leverages LTE PS access, eliminating the need to fall back to the GSM/UMTS network with the associated call set-up delay. Using LTE access also enables VoLGA to support concurrent voice and data services, providing the operational benefits of a flat IP architec-ture. However, because IMS is not used, VoLGA does not fully realize the benefits of an all-IP network.

Because VoLGA uses the CS-based handover capabilities of legacy MSCs, it provides excellent voice handovers between LTE and GSM/UMTS networks. VoLGA also supports voice service transparency between these networks. However, transparency is only supported for conversational services, not for advanced blended services such as those supported by IMS.

4.2.3 VoIMS

VoIMS is the strategic, end-goal solution for providing voice over LTE. Even if MSPs first choose to deploy CS fallback or VoLGA, they must eventually upgrade to VoIMS to gain the full advantage of the LTE network. VoIMS not only supports concurrent voice and data, enabling the offering of advanced, multimedia services that are capable of generating new revenue streams for MSPs, but also delivers the full operational cost savings of using a flat, all-IP network. VoLGA supports excellent LTE-to-UMTS PS-based handovers and handbacks if the operator chooses to implement VoIMS with UMTS. Expected to be widely deployed, VoLGA ensures global coverage for LTE subscribers whether at home or roaming. While more complex than the other two options, VoIMS delivers the most benefits and its investment is largely future-safe.

When implemented with ICS and SRVCC, VoIMS provides feature transparency and service continuity between LTE and GSM/UMTS CS networks, making it well-suited for operators who run LTE networks without complete national coverage. With SRVCC and 3GPP Release 8, handovers are supported from LTE to the GSM/UMTS network, and handbacks are supported with 3GPP Release 10. Although SRVCC signaling is rather complicated, its performance will likely improve over time.

5. Voice over LTE and roaming

Another factor to consider when evaluating options for the delivery of voice services over LTE is the implication for roaming. For a roamer to receive voice services while on an LTE network, both the UE and the visited network must support the same options for providing voice. For example, if the mobile device only supports VoIMS, the visited LTE network must also support VoIMS for the roamer to be able to originate a call.

A UE may support one or more options for providing voice services over LTE, but the option it uses when attaching to the LTE network is governed in the following order by:

• UE capabilities

• User’s HSS subscription information

• Operator’s policy

The operator’s policy is provisioned in the network and downloaded to the UE during its initial set-up. The policy determines the order of the options with which the UE attempts to attach and later register on the LTE network and allows the operator to block options that are supported by the UE but not by the network.

For example, if a terminal is programmed to first attempt to use VoIMS and then CS fallback, it first tries to register on the LTE network using VoIMS. If registration is successful, VoIMS services are activated and no other options are attempted. If registration fails, the terminal reattempts to attach with CS fallback. If both of these options fail, no other attempts are made because only the VoIMS and CS fallback options were specified by the operator’s policy.


Table 3 specifies the option used for voice-services delivery over LTE according to the option combinations supported by both the UE and visited LTE network. If the UE or LTE network both support only one option, the number of potential LTE roaming partners to provide voice services to roamers may be limited. However, when both the UE and LTE network support two out of the three available options, the number of potential roaming partners nearly doubles.

Table 3. Voice over LTE options and roaming

OPTIONS SUPPORTED BY UE (IN PRIORITIZED ORDER)

OPTIONS SUPPORTED BY VISITED LTE NETWORK (IN PRIORITIZED ORDER)

CSFB VoLGA VoLGA + CSFB VoIMS + VOLGA VoIMS VoIMS + CSFB

CSFB CSFB – CSFB – – CSFB

VoLGA – VoLGA VoLGA VoLGA – –

VoLGA + CSFB CSFB VoLGA VoLGA VoLGA – CSFB

VoIMS + VoLGA – VoLGA VoLGA VoIMS VoIMS VoIMS

VoIMS – – – VoIMS VoIMS VoIMS

VoIMS + CSFB CSFB – CSFB VoIMS VoIMS VoIMS

CSFB – CS fallback

If VoLGA fails to gain the acceptance of 3GPP, many LTE operators will likely choose not to support it on their networks, severely limiting the number of potential LTE roaming partners for operators supporting only VoLGA or VoLGA along with another option on their UEs.

What happens when the UE attempts all the allowable options for voice-services delivery while roaming on a LTE network and they all fail? Does the UE stay on the LTE network and receive no voice services, or does it then reselect a GSM/UMTS cell and receive voice services over the GSM/UMTS network? The answer depends on whether the UE is set to be voice or data centric. If the UE is operator provisioned to be data centric, it remains on the LTE network. Otherwise, it attaches and receives voice services from the GSM/UMTS.

6. Recommendations

Table 4 summarizes recommendations of options for providing voice over LTE depending on the type of operator.

Table 4. Voice over LTE: recommendations for different operator types

OPERATOR TYPE CS FALLBACK VoLGA VoIMS

VoIMS LTE VoIMS UMTS PS VOIMS GSM/UMTS CS (ICS AND SRVCC)

Operator with LTE network with complete national coverage

√

GSM operator starting to deploy LTE √ √ √

UMTS operator starting to deploy LTE √ √ √ √

Operator planning to deploy UMTS VoIMS √ √

Operator with GSM/UMTS and CDMA networks √ √ √

Operator with wireline and wireless networks √ √ √

Operator offering UMA/GAN services √

Operator offering or planning to offer advanced IMS services

√ √ √

CDMA – Code Division Multiple Access


6.1CSfallbackGenerally speaking, for operators planning on an early launch of LTE for data services, CS fallback provides a good, low-cost, interim voice solution until IMS can be deployed. In addition, CS fallback is ideal for MSPs with good UMTS coverage because it supports the PS handovers required for concurrent voice and data services.

6.2VoLGAVoLGA offers another interim option for MSPs that want to leverage their legacy voice core to quickly launch LTE voice. VoLGA postpones IMS deployment, along with the changes it necessitates to the back-office systems, until after the launch of LTE. At the same time, the LTE access network can be used for voice services delivery.

VoLGA is an especially good choice for GSM MSPs with limited UMTS coverage. Because VoLGA uses the LTE access network, it can support simultaneous voice and data services, overcoming the GSM service limitation of CS fallback.

If an operator has currently deployed Unlicensed Mobile Access (UMA)/Generic Access Network (GAN), VoLGA may be a suitable option for voice over LTE. Network implementation is similar, allowing operators to leverage skill sets developed with UMA deployment and operations, and some UMA network equipment, such as the AAA server and security gateway, may be reused for VoLGA.

6.3VoIMSVoIMS, the only end-goal solution for providing voice over LTE, may be deployed initially as LTE is introduced or later as a network evolution of a CS fallback or VoLGA interim solution. VoIMS may be deployed with:

• LTE access only

• LTE and UMTS PS access

• LTE and GSM/UMTS CS access

• LTE, UMTS PS, and GSM/UMTS CS access

We recommend that VoIMS be used with LTE access only when LTE coverage is sufficient. This normally requires access to a radio band below 1 GHz and is therefore only likely for operators that have either obtained digital dividend spectrum or are planning to replace their GSM systems in the 850 MHz or 900 MHz band. In the United States and Canada, the Advanced Wireless Spectrum (AWS) may also provide sufficient LTE coverage because it was only recently auctioned and may not be well deployed with UMTS.

For operators running LTE networks without complete national coverage, we recommend that VoIMS be deployed with LTE access and UMTS PS access, with HSPA+ coverage filling in LTE gaps. The advantage of this implementation method is that it enables excellent simultaneous voice and data PS-based handovers and handbacks between the two networks. Where HSPA+ is not available, we recommend that VoIMS be deployed with LTE and GSM/UMTS CS access, using SRVCC and UE-based ICS to ensure service continuity and feature transparency between the operator’s LTE and GSM/UMTS networks.

VoIMS is also a good choice for operators that plan to deploy advanced multimedia services, such as RCS.

VoIMS gives operators with wireless and wireline networks the opportunity to offer converged fixed and mobile services, thereby increasing revenue and reducing subscriber churn. VoIMS is also a good option for MSPs with both GSM/UMTS and CDMA networks because IMS offers convergence between fixed and wireless as well as between different wireless access technologies.


VoIMS is also an excellent option for operators that have already implemented some IMS services in their network. Some or all equipment can be reused along with the IMS implementation and operational skill sets that have been developed.

7. Conclusion

This paper has presented three options for providing voices services as LTE is introduced in the network: CS fallback, VoLGA, and VoIMS. We have examined and evaluated each option based on how it works, the types of services it supports, and network implementation requirements. We have also evaluated the implication of the options and option combinations for roaming.

Each option has advantages and disadvantages, and there is no “right” option for all. MSPs must consider the following factors when choosing an option or option combination that is best suited for their network:

• Timing of the LTE network launch: near or far future

• LTE coverage: complete or partial national coverage

• Type of network currently deployed: GSM, UMTS, fixed/mobile converged, GSM/UMTS/CDMA converged, UMA, or IMS

• Planned network upgrades to UMTS, VoIMS with UMTS HSPA+, or other technologies

• Timing for the introduction of new advanced multimedia services

• Decision to implement an interim solution or go straight to the end-goal solution

• Voice over LTE options/option combinations of roaming partners

By gaining an in-depth understanding of each option along with its impact on the GSM/UMTS network, MSPs are better equipped to make informed decisions for the delivery of voice services as LTE is introduced into their networks.

Alcatel-Lucent is uniquely positioned to be the committed partner of choice as operators evolve their 2G/3G networks to LTE. With the most comprehensive portfolio of telecommunications products and services in the industry, Alcatel-Lucent has the expertise, products, services, and global reach that have won us a leadership role in the LTE evolution. Specifically, we provide:

• Global LTE offer with service continuity and integration for 2G/3G networks, leveraging our unique expertise in 2G/3G standards, LTE trial leadership with major operators, and active participation in leading LTE organizations and forums

• Unmatched end-to-end LTE solution that leverages our market leadership in next-generation IP transformation and service delivery, recognized expertise in packet transport, industry leadership in IMS service delivery platforms, next-generation wireless access technologies, and Alcatel-Lucent Bell Labs innovations, such as self-optimized networks, next-generation multiple-input multiple-output (MIMO), and ambient network

• A broad and open ecosystem of compelling devices and applications


8. Abbreviations

2G second generation

3G third generation

3GPP 3rd Generation Partnership Project

AAA authentication, authorization and accounting

ARPU average revenue per user

AWS Advanced Wireless Spectrum

BSC Base Station Controller

BSS Base Station System

CAMEL Customized Applications for Mobile network Enhanced Logic

CDMA Code Division Multiple Access

CS circuit-switched

CS NAS Circuit Switched Non-Access Signaling

CSCF Call Session Control Function

CSFB CS fallback

DTM Dual Transfer Mode

EDGE Enhanced Data rates for GSM Evolution

EPC Evolved Packet Core

EPS Evolved Packet System

eNode B Evolved Node B

E-UTRAN Evolved UTRAN

G3 Fax Group 3 Fax

GA-CSR Generic Access - Circuit-Switched Resources

GAN Generic Access Network

GERAN GSM EDGE Radio Access Network

GGSN Gateway GPRS Support Node

GSM Global System for Mobile Communications

GSMA GSM Association

HLR Home Location Register

HSPA High Speed Packet Access

HSPA+ Evolved High Speed Packet Access

HSS Home Subscriber Server

ICS IMS Centralized Services

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IOT interoperability testing

IP Internet Protocol

IP-SM-GW IP Short Message Gateway

ISC IMS Service Continuity

IWF Interworking Function

LAI Location Area ID

LTE Long Term Evolution

MGCF Media Gateway Control Function

MGW Media Gateway

MIMO multiple-input multiple-output

MME Mobility Management Entity

MMS Multimedia Messaging Service

MSC Mobile Switching Center

MSP mobile service provider

OSS operations support system

PCRF Policing and Charging Rules Function

PDN packet data network

PDN GW PDN Gateway

PS packet-switched

PSHO PS handover

QoS quality of service

RAB radio access bearer

RAN radio access network

RCS Rich Communication Suite

RNC radio network controller

RNS Radio Network Subsystem

ROHC Robust Header Compression

RRC Radio Resource Control

RTP Real Time Protocol

S-CSCF Serving - Call Session Control Function

SCC AS Service Centralization and Continuity Application Server

SGSN Serving GPRS Support Node

SGW Serving Gateway

SIP Session Initiation Protocol

SMS Short Message Service

SRVCC Single Radio Voice Call Continuity

SRVCC AS SRVCC Application Server

S-CSCF Serving - Call Session Control Function

TAI Tracking Area ID

TAS Telephony Application Server

TCP Transmission Control Protocol

UE user equipment

UMA Unlicensed Mobile Access

UMTS Universal Mobile Telecommunications System

USSD Unstructured Supplementary Service Data

UTRAN UMTS Terrestrial Radio Access Network

VANC VoLGA Access Network Controller

VoIMS Voice over IMS

VoIP Voice over IP

VoLGA Voice over LTE via Generic Access


9. Contacts

For more information on Alcatel-Lucent LTE, IMS, and Mobile NGN solutions, please visit www.alcatel-lucent.com or contact your Customer Team representative.

You can also contact Alcatel-Lucent Marketing or Public Relations:

• Sofia Flores: Wireless Product Marketing, [email protected] +1 972 477 0410

• Christine De Monfreid: Public Relations, [email protected] +33 1 3077 5914

10. References

[1] Ankeny, Jason. AT&T Reports Q4 Mobile Data Revenues of $3.1 Billion. FierceMobileContent, January 28, 2009.

http://www.fiercemobilecontent.com/story/t-reports-q4-mobile-data-revenues-3-1-billion/2009-01-28?utm_medium=rss&utm_source=rss&cmp-id=OTC-RSS-FMC0

[2] Ankeny, Jason. AT&T Posts 38.6% wireless data revenue growth in Q1. FierceMobileContent, April 22, 2009.

http://www.fiercemobilecontent.com/story/t-posts-38-6-wireless-data-revenue-growth-q1/2009-04-22

[3] Mackenzie, Michele, and Steven Hartley. Mobilebroadbandgrowthforecast,2008–2014.Ovum, April 3, 2009.

[4] Marek, Sue. Verizon data revenue tops $3.6 billion in 1Q. FierceMobileContent, April 27, 2009.

http://www.fiercemobilecontent.com/story/verizon-data-revenue-tops-3-6-billion-1q/2009-04-27

[5] 3GPP (http://www.3gpp.org/Specification-Numbering)

• TS 23.204: Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2

• TS 23.216: Single Radio Voice Call Continuity (SRVCC); Stage 2

• TS 23.221:Architectural requirements

• TS 23.228: IP Multimedia Subsystem (IMS); Stage 2

• TS 23.237: IP Multimedia Subsystem (IMS) Service Continuity; Stage 2

• TS 23.272: Circuit Switched (CS) Fallback in Evolved Packet System (EPS); Stage 2

• TS 23.292: IP Multimedia Subsystem (IMS) centralized services; Stage 2

• TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

• TR 23.879: Study on Circuit Switched (CS) domain services over evolved Packet Switched (PS) access

[6] VoLGA (http://www.volga-forum.com/volgaSpecifications.php)

• Voice over LTE via Generic Access; Requirements Specification; Phase 1. VoLGA Forum, June 2009.

• Voice over LTE via Generic Access; Stage 2 Specification; Phase 1. VolGA Forum, August 24, 2009.

www.alcatel-lucent.com Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein. Copyright © 2009 Alcatel-Lucent. All rights reserved. CPG1649091001 (11)

options for providing voice over lte and their impact on the gsm/umts network

Technology