mag, voice call handover mechanisms in next-generation 3gpp systems

IEEE Communications Magazine • February 200946 0163-6804/09/$25.00 © 2009 IEEE

INTRODUCTION

As the wireless industry makes its way to thenext generation of mobile communication sys-tems, it is important to engineer solutions thatenable seamless integration of the emergingfourth-generation (4G) technologies within thecurrently deployed 2G/3G infrastructures. This isimportant because, in most cases, the second-and third-generation (2G/3G) systems providethe solid ground on which the next-generationsystems will be built, and will continue providingthe main revenue stream for operators for sever-al years along the migration path to 4G. Theintegration of emerging access and core tech-nologies within the existing 2G/3G networks(e.g., code-division multiple access [CDMA],Global System for Mobile Communications[GSM], General Packet Radio Service [GPRS],and Universal Mobile Telecommunications Sys-tem [UMTS]) can enable a smooth evolution

path, and progressively scale network capacityand service innovation in a economically effi-cient way. The integrated system is characterizedby a heterogeneous architecture (i.e., supportingdiverse radio access networks) capable of provid-ing mobile broadband services in strategic geo-graphic areas and ensuring the “best connection”of users at any place, anytime. However, suchintegration requires us to address a vast range ofinteroperability and migration issues that arisefrom the need to support seamless mobilityacross new and legacy radio access technologies,and migrate the legacy services to new radioaccesses. As an example, consider a user that ini-tiates a voice call inside a 4G hotspot. This callis carried out over the 4G access network withvoice over IP (VoIP) technologies; but as theuser goes out of 4G coverage, the call needs tobe sustained and seamlessly handed over to the“umbrella” 2G/3G access network, which typical-ly provides a much wider radio footprint.

It may also happen that voice services are notinitially supported over 4G access (e.g., in orderto eliminate the cost of deploying VoIP-basedservices), in which case the user would have tobe handed over to the overlay 2G/3G accessright after the call request is made. In this casethe 2G/3G access is used as a fallback access thatsupports the legacy services when they are notyet available in the 4G access. All these require-ments create the need for voice call handovermechanisms from the emerging 4G access tech-nologies to the legacy 2G/3G access technolo-gies.

In this article we focus on such voice callhandover mechanisms and address in particularthe voice call handover mechanisms in the next-generation Third Generation Partnership Pro-gram (3GPP) networks, which typically takeplace between the evolved 3GPP radio accessnetwork (evolved UMTS terrestrial radio accessnetwork [E-UTRAN] [1]) and the legacy3GPP/3GPP2 radio access networks,UTRAN/GERAN and CDMA2000 1xRTT. Inthis context we present and explain the technicaldetails of three different voice call handovermechanisms, which aim at addressing three dif-ferent deployment scenarios of next-generation

ABSTRACT

The evolved 3GPP system is a hybrid mobilenetwork architecture supporting several radioaccess technologies and several mobility mecha-nisms. In this article we briefly review the archi-tecture and key components of this system, withparticular emphasis on how it can support voicecall mobility in several deployment scenarios.First, we present the so-called single-radio voicecall continuity mechanisms that enable mid-callhandover of VoIP calls from E-UTRAN accessto the legacy UTRAN/GERAN or 1xRTTaccess. Then we focus on deployment scenariosthat do not support voice services on E-UTRANand present the so-called fallback mechanismsthat enable handover from E-UTRAN toUTRAN/GERAN or 1xRTT at the beginning ofa voice call. Finally, we address the application-layer voice call handover mechanisms enabled bythe IP multimedia subsystem. Our conclusion isthat the next generation of 3GPP systems arehighly sophisticated mobile communication sys-tems that support extended voice call mobilitymechanisms, capable of addressing all commer-cial deployment needs.

LTE — 3GPP RELEASE 8

Apostolis K. Salkintzis, Motorola

Mike Hammer, Cisco

Itsuma Tanaka, NTT DOCOMO

Curt Wong, Nokia Siemens Networks

Voice Call Handover Mechanisms inNext-Generation 3GPP Systems

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 46

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

IEEE Communications Magazine • February 2009 47

3GPP systems. First we present handover mech-anisms that enable mid-call handover of VoIPcalls from E-UTRAN access to the legacyUTRAN/GERAN or 1xRTT access (note thatE-UTRAN access is sometimes also referred toas 4G access). These mechanisms are particular-ly important in deployment scenarios wherevoice services are supported on E-UTRAN (asexplained later, E-UTRAN supports only IP-based services) but, due to limited E-UTRANcoverage, handover to UTRAN/GERAN or1xRTT is necessary to maintain seamless voiceservices over wider geographical areas. Second,we focus on deployment scenarios that do notsupport voice services on E-UTRAN. This most-ly targets initial deployments of evolved 3GPPsystems, in which voice services are not yetmigrated to E-UTRAN (i.e., not supported yetover IP). For those scenarios, we present the keyaspects of a voice call handover mechanism thatenables handover from E-UTRAN to UTRAN/GERAN or 1xRTT at the beginning of a voicecall. The handover is triggered by the arrival ofan originating or terminating voice call, whichcan only be served on UTRAN/GERAN or1xRTT access and in the traditional circuit-switched (CS) domain [2]. We then addressvoice call handover mechanisms enabled by theIP multimedia subsystem (IMS). Such mecha-nisms mostly target deployment scenarios inwhich voice services are supported on E-UTRAN and non-3GPP-defined radio accesses,such as WLAN and WiMAX, and there is also aneed to support voice continuity across these

radio accesses. It is also assumed that in suchdeployments there are no transport layer mecha-nisms (e.g., based on mobile IP and its deriva-tives) that can meet the voice continuityrequirements. We also provide some backgroundmaterial in the next section, where we presentthe key aspects of the next-generation 3GPP sys-tems, and introduce the fundamental networkelements and interfaces. Finally, we wrap up ourdiscussion by providing a number of concludingremarks.

AN OVERVIEW OF NEXT-GENERATION 3GPP SYSTEMS

To provide some background material for ourfurther discussion, we present here a shortoverview of the evolved (or next-generation)3GPP systems. Readers interested in moredetails on the evolved 3GPP systems are referredto the 3GPP specifications [1–5] and other arti-cles in this Feature Topic.

As part of Release 8 of the 3GPP specifica-tions, 3GPP has been studying and specifying anevolved packet system (EPS) under the SystemArchitecture Evolution (SAE) work item [2].The EPS is composed of a new radio access net-work, called E-UTRAN [1], and a new all-IPcore network, called evolved packet core (EPC)[3, 4]. The EPC can be considered an evolutionof the legacy GPRS architecture with additionalfeatures to improve performance, supportingbroadband E-UTRAN access, PMIPv6 mobility,

nn

Figure 1. Simplified architecture of the evolved 3GPP network.

EPC: Evolved packet coreS-GW: Serving gateway

P-GW: PDN gatewayMME: Mobility management entity

ePDG: Enhanced packet data gatewayPCRF: Policy and charging rules function

HSS: Home subscriber serverAAA: Authentication, authorization, accounting

MME

S-GW

PCRFePDG

P-GW

E

2G/3G 3GPP core

Gn

S3

S11

S4

S5

S1-AP

S1-U

S6aGxc

GxbGxa

STaS103

S101

Userequipment(UE)

Gx

S2b

S2aSWn

Gi

SGi

3GPP EPC

MSCMSC

SGSN GGSN

lu-cs

lu-ps

A/lu-cs

Gb/lu-ps

UTRAN

GERAN

E-UTRAN

CDMA2000HRPD

WiMAX

Legacycircuit-switched

services

Packet datanetwork(s)e.g. IMS,

Internet, etc.

WLAN

AAA/HSS



IEEE Communications Magazine • February 200948

and integration with non-3GPP radio technolo-gies such as wireless LAN (WLAN),CDMA2000, and WiMAX. As shown in Fig. 1,the evolved 3GPP network is virtually composedof an evolved version of the legacy 2G/3G net-work (with the well-known UTRAN/GERANradio accesses) and the EPC, which supports E-UTRAN access and integration with a range ofnon-3GPP accesses. Note that for simplicity allnetwork interfaces are not shown in Fig. 1. Theinterfaces relevant to the voice call handovermechanisms are presented and discussed in sub-sequent sections.

As shown in Fig. 1, a number of diverseaccess networks, such as CDMA2000, WLAN,WiMAX, GERAN, UTRAN, and E-UTRAN,are connected to a common core network (theEPC) based on IP technology through differentinterfaces. All 3GPP-specific access technologiesare connected through the serving gateway (S-GW), while all non-3GPP specific access tech-nologies are typically connected through thepacket data network gateway (P-GW) or evolvedpacket data gateway (ePDG), which providesextra security functionality for untrusted accesstechnologies (e.g., legacy WLANs with no strongbuilt-in security features). The S-GW acts as amobility anchor for mobility within 3GPP-specif-ic access technologies, and also relays trafficbetween the legacy serving GPRS support node(SGSN) accesses and the P-GW. For E-UTRAN,the S-GW is directly connected to it through theS1 interface, while the SGSN is the intermediatenode when GERAN/UTRAN is used. It isimportant to mention that a mobility manage-ment entity (MME) is also incorporated in thearchitecture for handling control functions suchas authentication, security, and mobility in idlemode.

For access to EPC through WLAN,CDMA2000 HRPD, or WiMAX [3], differentdata paths are used. HRPD and WiMAX areconsidered trusted non-3GPP accesses and aredirectly connected to a P-GW through the S2ainterface, which is used particularly for trustednon-3GPP accesses. On the other hand, aWLAN considered as untrusted access (e.g.,because it may not deploy any strong securitymeasures) connects to the ePDG and then to aP-GW through the S2b interface. In this casethe ePDG serves as a virtual private network(VPN) gateway and provides extra securitymechanisms for EPC access. All data pathsfrom the access networks are combined at theP-GW, which incorporates functionality such aspacket filtering, QoS policing, interception,charging, and IP address allocation, and routestraffic over SGi to an external packet data net-work (e.g., for Internet access) or the operator’sinternal IP network for accessing packet servicesprovided by the operator. Apart from the net-work entities handling data traffic, EPC alsocontains network control entities for keepinguser subscription information (home subscriberserver [HSS]), determining the identity andprivileges of a user and tracking his/her activi-ties (access, authorization, and accounting[AAA] server), and enforcing charging and QoSpolicies through a policy and charging rulesfunction (PCRF).

SINGLE-RADIOVOICE CALL CONTINUITY

Especially in the first days of E-UTRAN deploy-ment, coverage will be limited and available onlyin scattered strategic locations, where wirelessbroadband services are most needed. Therefore,in order to provide seamless continuity of voiceservices in wide geographical areas, it is impor-tant for the next generation of 3GPP systems toseamlessly hand over voice calls between E-UTRAN [1] and UTRAN/GERAN coverageareas. Although this is not a new requirement(e.g., similar voice continuity requirements existbetween UTRAN and GERAN, and betweenCDMA2000 1xRTT and HRPD), in this casethere are new challenges we have to face. First,voice calls on E-UTRAN can only be carried outvia IP-based technologies and therefore are pro-vided as IMS-based services. On the contrary,voice calls on UTRAN and GERAN are typical-ly carried out with conventional CS technologiesand therefore are provided as CS domain ser-vices. This creates the need to transfer and con-tinue voice calls between two different servicedomains, CS and IMS. Second, the voice callsneed to be transferred across service domainsand radio access technologies with so-called sin-gle-radio mobile terminals, that is, mobile termi-nals that cannot support simultaneous signalingon both E-UTRAN and UTRAN/GERAN radioaccesses. This is a key requirement because E-UTRAN and UTRAN/GERAN radio channelsmay be deployed on the same or neighboringfrequency bands; having mobile terminals simul-taneously active on both radio channels presentssevere technical challenges for the design of thephysical layer. This requirement for single-radiomobile terminals makes the use of existing dual-radio voice call transfer mechanisms (e.g., mech-anisms specified in 3GPP TS 23.206 [6])infeasible for voice call continuity between E-UTRAN and UTRAN/GERAN access.

Below we present and explain the single-radio solutions recently standardized by 3GPPfor enabling voice call continuity between E-UTRAN and UTRAN/GERAN, and between E-UTRAN and CDMA2000 1xRTT (the stage 2specification can be found in [7]). We primarilyfocus on voice call handover in the directionfrom E-UTRAN to UTRAN/GERAN and fromE-UTRAN to CDMA2000 1xRTT, since this isconsidered much more important (due to thelimited E-UTRAN coverage) than the otherdirection of handover. For this reason, only thisdirection of handover is also supported by thecurrent standards [7].

VOICE CALL TRANSFER FROME-UTRAN TO UTRAN/GERAN

Figure 2a shows the architecture that enablessingle-radio voice call continuity (SR-VCC)between the E-UTRAN and conventionalUTRAN and GERAN radio networks [7]. Thisarchitecture is based on the IMS and requires allvoice calls initiated on E-UTRAN to beanchored in IMS (a later section explains howthis is done). The architecture also requires at

In order to provide

seamless continuity

of voice services in

wide geographical

areas, it is important

for the next

generation of 3GPP

systems to seamlessly

handover voice calls

between E-UTRAN

and UTRAN/GERAN

coverage areas.




least one mobile switching center (MSC) serverin the traditional CS domain to be enhancedwith interworking functionality and a new inter-face, called Sv. Such an enhanced MSC server isreferred to as “MSC server enhanced for SR-VCC”; when combined with a standard mediagateway (MGW), it is referred to as “MSCenhanced for SR-VCC.” In addition, the MMEin the EPC (discussed previously) requires addi-tional functionality to support the Sv interface

and the associated SR-VCC procedures, whichare further explained below.

Although the solution for SR-VCC was origi-nally required to enable the handover of oneongoing voice call from E-UTRAN to UTRANor GERAN, during the standardization processit was enhanced to further facilitate the hand-over of potential non-voice sessions that mightbe active in parallel with the voice call. To betterexplain this, we show in Fig. 2a user equipment

nn

Figure 2. a) Architecture for single-radio VCC between E-UTRAN and UTRAN/GERAN; b) messageflow diagram for voice and non-voice single-radio handover from E-UTRAN to UTRAN or GERAN (withdual transfer mode capability).

Non-voice path before handover

IP multimediasubsystem

(IMS)

S3

S4

Sv

E

D

S6a

S11

S5 SGi

S1-U

lu-cs

lu-ps

A or lu-csGb or lu-ps

Userequipment(UE)

MSC

2G/3G 3GPP core

MME

MSCenhancedfor SR-VCCSGSN

S-GW P-GW

3GPP EPC

UTRAN

GERAN

Non-voice path after handover to GERANVoice path before handoverVoice path after handover to GERAN

E-UTRAN

HSS

1. Measurement reports

2. Handover required

Voice path before handover

Handover decision

UE MMEE-UTRANEnhanced

MSCGERAN or

UTRANRemote

endMSC SGSN S-GW/P-GW IMS

3a. Request reservation of PS resources

4. Initiation of session transfer (STN-SR)

Voice packets from remote end are forwarded to enhanced MSC

3b. Request reservation of CS resources

3c. PS resources reserved

3d. CS resources reserved

7a. PS handover complete

8. CS handover complete

Voice path after handover completion

7b. Update bearer

5. Handover command

MME splits voice bearers fromnon-voice bearers and initiatestheir relocation towards theMSC and SGSN, respectively.

IMS session transferprocedures

UE moves to GERAN

6. HO detection

Although the

solution for SR-VCC

was originally

required to enable

the handover of one

ongoing voice call

from E-UTRAN to

UTRAN or GERAN,

during the standard-

ization process it was

enhanced to further

facilitate the

handover of

potential non-voice

sessions that might

be active in parallel

with the voice call.

SALKINTZIS LAYOUT 1/19/09 2:46 PM 9



(UE) that has a voice session and a non-voicesession (say, a video streaming session) active inE-UTRAN. We assume that both sessions areenabled by IMS, so the data flows of these ses-sions (indicated with the double-head arrows)enter the IMS cloud. When the UE goes out ofE-UTRAN coverage, the SR-VCC procedure istriggered to relocate all data flows to (say) aGERAN radio cell. In the example shown in Fig.2a, this cell is not controlled by the MSCenhanced for SR-VCC, so another MSC isinvolved (however, this is not always the case).The voice session is relocated from the P-GW tothe MSC enhanced for SR-VCC and the non-voice session is relocated from the S1-U inter-face to the S4 interface and then to GERANthrough the SGSN. In this example the GERANradio access supports simultaneous access tovoice and non-voice (GPRS) services. To meetthe seamless voice transfer requirements (i.e.,make the voice transfer imperceptible to theuser), this handover process should create voiceinterruption of no more than a few hundreds ofmilliseconds. For the non-voice session(s), how-ever, seamless transfer cannot be guaranteedgiven the limited data bandwidth offered byUTRAN/GERAN compared to the broadbanddata capabilities of E-UTRAN. Therefore,although non-voice session(s) can be transferredand continue in the UTRAN/GERAN packet-switched domain, there is no guarantee that thetransfer would be seamless and the quality ofservice sustained after the transfer.

The SR-VCC solution is further explainedbelow with the aid of the message flow diagramillustrated in Fig. 2b. In this example diagramthe UE is initially in E-UTRAN and has activevoice and non-voice sessions in parallel. Thevoice session is anchored in IMS and terminatesat the remote end, which is a traditional publicswitched telephony network (PSTN) phone;thus, IMS/PSTN interworking functionality isinvoked. At the top of the diagram, the path ofthe voice flow is illustrated, which goes throughthe appropriate (IMS/PSTN) interworking func-tions in the IMS subsystem and is then routed tothe UE via P-GW, S-GW, and E-UTRAN (notethat for convenience the S-GW and P-GW areshown in the same box). A similar flow pathcould be traversed by the non-voice session,although this is not shown in Fig. 2b for simplici-ty. At the end of the flow diagram the voice andnon-voice sessions are transferred, and continuein a GERAN or UTRAN cell.

During its active voice session the UE takesinter-radio access technology (inter-RAT) mea-surements; that is, it measures the signal strengthand quality of the neighbor UTRAN and/orGERAN channels. The list of available inter-RAT channels is regularly transmitted in the sys-tem information of the serving E-UTRAN cell.The UE transmits inter-RAT measurementreports as well as measurement reports for thecurrently selected E-UTRAN cell (step 1 in Fig.2b), which are typically input to the handoverdecision algorithms. Apart from the measure-ment reports, the serving E-UTRAN cell knows:• If the UE is SR-VCC-capable (this informa-

tion comes from the MME during attach-ment or handover)

• If the neighbor UTRAN/GERAN cells cansupport VoIP

• If the UE has an active voice callBased on this information, the serving E-

UTRAN cell decides when an SR-VCC hand-over is required and selects the target UTRANor GERAN cell (which in this case can supportonly voice services in the traditional CS domain).When this decision is taken, the E-UTRANsends a Handover Required message (step 2) tothe MME with some information indicating thatSR-VCC handover is required.

This information is necessary in the MME inorder to decide what type of handover to exe-cute; in this case it will be a handover toward theCS domain and a handover toward the packet-switched (PS) domain. In turn, the MME sepa-rates the active voice bearer of the UE from itsactive non-voice bearer(s) and initiates twohandover procedures in parallel: one to handover the non-voice bearer(s) to the PS domainand another to hand over the voice bearer to theCS domain of the 2G/3G core. These proceduresare typically executed in parallel, but for thesake of presentation, Fig. 2b shows them insequence: first the PS handover and then the CShandover. Step 3a is used for preparing the non-voice resources in the PS domain according tothe standard relocation procedures specified in3GPP TS 23.060 [5]. Also, step 3b is used forpreparing the voice resources in the CS domainaccording to the relocation procedures in 3GPPTS 23.060 [5] and the inter-MSC handover pro-cedures in 3GPP TS 23.008. Note that in theexample message flow of Fig. 2b, E-UTRANdecided to transfer the voice and non-voice ses-sions of the UE to a neighbor GERAN cell,which supports both PS and CS services in paral-lel (also called dual transfer mode [DTM]). ThisGERAN cell is also connected to a legacy MSC(i.e., not enhanced for SR-VCC), which does notinterface directly with the MME, so the voicehandover signaling must pass through an MSCenhanced for SR-VCC and an inter-MSC hand-over must be carried out between the MSCenhanced for SR-VCC and the legacy MSC.

Message 4 is a key step in the handover pro-cedure and merits further explanation. This mes-sage is merely a new voice call request (e.g., anISUP IAM) toward a special number, called ses-sion transfer number for SR-VCC (STN-SR).This call request is routed to a special applica-tion server in the IMS subsystem, called servicecentralization and continuity application server(SCC AS), which then correlates the receivedSTN-SR with an active IMS voice session, in thiscase with the voice session between UE and theremote end (see 3GPP TS 23.237 [8] and a sec-tion in this article for further details). The recep-tion of a new call request for STN-SR is a signalfor SCC AS that the associated IMS voice ses-sion needs to be redirected to a new endpoint(in this case to the MSC enhanced for SR-VCC);therefore, it triggers the IMS session transferprocedures specified in 3GPP TS 23.237 [8].Note that for each UE, a dedicated STN-SRnumber is configured in the HSS, and the MSCenhanced for SR-VCC receives this numberfrom the MME (in step 3b), which receives thisnumber from the HSS during the UE’s initial

During the execution

of the IMS session

transfer procedure,

the Remote End is

updated with new

Session Description

Protocol (SDP)

contact details (e.g.,

with a SIP re-INVITE

message) and

subsequent down-

stream voice packets

are forwarded to the

MSC enhanced for

SR-VCC.

SALKINTZIS LAYOUT 1/19/09 2:46 PM 0



attachment to EPC. During the execution of theIMS session transfer procedure, the remote endis updated with new Session Description Proto-col (SDP) contact details (e.g., with a SessionInitiation Protocol [SIP] re-INVITE message),and subsequent downstream voice packets areforwarded to the MSC enhanced for SR-VCC(more correctly, to the MGW associated withthis MSC).

After both PS and CS resource preparation iscompleted (steps 3c and 3b, respectively), theMME responds to the Handover Required mes-sage received in step 2 with a Handover Com-mand, which is then transmitted to UE in step 5.This command includes information describingthe CS and PS resources allocated for the UE(e.g., the target GERAN cell identity, carrierfrequency, traffic channel specification). Afterthis step, the UE moves to the indicated targetGERAN cell and uses conventional GERANhandover completion procedures. In step 6 theUE is detected in the target GERAN cell, and insteps 7 and 8 the PS and CS relocation/handoverprocedures are completed, respectively. Afterstep 7b the non-voice bearers are switched fromthe S1-U interface to the S4 interface, and afterstep 8 the voice bearer is fully re-establishedwith a new access leg in the GERAN CS domain.Note that the voice gap created by the handoverprocedure starts from the execution of the IMSsession transfer procedures to the completion ofstep 8 and is expected to last a few hundreds ofmilliseconds.

VOICE CALL TRANSFER FROME-UTRAN TO CDMA2000 1XRTT

Figure 3a shows the architecture that enablesSR-VCC between the E-UTRAN and CDMA1xRTT radio networks. This architecturerequires a 1xCS interworking solution (IWS)function in the traditional 3GPP2 CS domain tointerwork with EPS via a new interface, calledS102. The 1xCS IWS enables UE to communi-cate with the 1xRTT MSC while it is connectedto the EPC via E-UTRAN. From SR-VCC per-spective, this mechanism minimizes the voicegap by allowing the UE to establish the targetCS access leg while it is still on the E-UTRANaccess, prior to the actual handover to 1xRTTaccess. The MME in the EPC (discussed previ-ously) requires additional functionality to sup-port the S102 interface and mainly functions as asignaling relay station between the UE and 1xCSIWS.

This architecture was designed to handle onlythe voice part of an IMS session [7]. The trans-fer of a non-voice component is not specified(different from SRVCC to UTRAN/GERAN).

This SR-VCC solution is further explainedbelow with the aid of the simplified messageflow diagram illustrated in Fig. 3b. In this exam-ple diagram the UE is initially in E-UTRAN andhas an active IMS voice session. The voice ses-sion terminates at the remote end, which may bea traditional PSTN phone.

Similar to the SR-VCC for 3GPP system, theVoIP/IMS path is initially established over E-UTRAN. When E-UTRAN detects the need forSR-VCC to 1xRTT handover, it sends a signal-

ing message, including the necessary 1x parame-ters (e.g., 3G1x overhead parameters, RANDvalue) to the UE to start the 1xRTT SR-VCCprocedure (steps 1–2, Fig. 3b). In step 3 the UEstarts the 1x SR-VCC procedure with the 1xRTTMSC (based on 3GPP2 X.S0042-0 [9]). This isdone by establishing a signaling tunnel via EPCand 1xCS IWS. When the 1xRTT MSC hasreceived a positive acknowledgment from the1xRTT radio for traffic allocation and from theIMS for successful domain transfer, it returns anIS-41 handoff message to the UE (similar to thehandover command) via the established signal-ing tunnel (step 5). Upon receiving this message,the UE then performs the handover to 1xRTTaccess and continues to transmit voice via thatsystem. The voice bearer path is no longer car-ried by the EPC. E-UTRAN requests the MMEto release the UE context (step 6). The MMEcompletes this procedure by requesting the S-GW to suspend the EPS bearer, step 7. (I.e., S1-U bearers are released for all EPS bearers andthe voice bearer is deactivated. The non-GBRbearers are preserved and marked as suspendedin the S-GW). Upon receipt of downlink datathe S-GW should not send a downlink data noti-fication message to the MME.

VOICE CALL HANDLING WITHFALLBACK TO 2G/3G

As discussed before, in some initial deploymentsof evolved 3GPP systems there will be no sup-port of voice services on E-UTRAN. In suchdeployments, however, it is still necessary thatusers on E-UTRAN be able to participate invoice calls. This can be achieved by conducting aso-called fallback to a legacy 2G/3G access net-work that supports traditional voice services(e.g., UTRAN, GERAN, or CDMA2000 1xRTT)at the moment a voice call is requested. Thisfallback is effectively a service-based handovermechanism, a handover triggered by a servicerequest, which in this case is a request for anoriginating or terminating voice call. After theuser falls back to 2G/3G access, standard CSvoice call setup procedures are used to establishthe voice call in the CS domain. This techniqueof falling back to the 2G/3G CS domain forvoice services is considered an interim solutionthat can fill the gap between the initial E-UTRAN deployment and the introduction ofvoice and other IP services over E-UTRAN.

The fallback to the 2G/3G CS domain (or CSfallback for short) is enabled by the followingcharacteristics:• Mobility management is combined with EPS

mobility management.• Paging request for terminating calls are

delivered to the UE via EPS.• 2G/3G is used for paging responses and fur-

ther call handling as well as for all originat-ing calls.Figure 4a shows the architecture that enables

CS fallback to the UTRAN/GERAN CS domain.Note that although this figure concentrates onfallback to UTRAN/GERAN, a similar architec-ture can also be used for fallback to CDMA20001xRTT access. Details for both architectures as

In some initial

deployments of

evolved 3GPP

systems there will be

no support of voice

services on E-UTRAN.

In such deployments

however it is still

necessary that users

on E-UTRAN be able

to participate in

voice calls. This can

be achieved by

conducting a so-

called fallback to a

legacy 2G/3G access

network.




well as fallback procedures can be found in3GPP TS 23.272 [10].

The architecture connects the mobile switch-ing center (MSC) and MME via the new SGsinterface. This interface is based on the Gs inter-face, which connects the MSC and SGSN, andwas introduced in order to reuse the concept ofcombined mobility management between the CSand PS domains [5]. To combine the mobilitymanagement between E-UTRAN and 2G/3G,there is need for a mapping mechanism thatmaps between E-UTRAN tracking areas and2G/3G location areas. When the UE moves toE-UTRAN, its 2G/3G location area must also beupdated so that incoming calls can be correctlydelivered to the UE. The mapping of tracking/location areas is performed by the MME, andthe combined mobility management procedures(e.g., combined attached [5]) are reused as muchas possible to minimize the impact on the MSC.

Figure 4b illustrates an example message flow

diagram showing how CS fallback is conductedin order to facilitate a mobile originating call. Inthis example diagram the UE is initially in E-UTRAN and has active IP packet connection.The UE has attached to the MME in EPC andto an MSC in the 2G/3G CS domain by conduct-ing a combined EPS/IMS Attach procedure [5].It is assumed also that the target 2G/3G accesssupports simultaneous PS and CS services. Thefollowing procedure takes place when UE andthe network are not configured to use IMS. IfUE is configured to use IMS voice or IMS SMSservices and is registered to IMS, it shall initiatecalls via IMS, even if it is attached to the 2G/3GCS domain.

When UE decides to make a mobile originat-ing call, the UE sends a Service Request mes-sage with a CS fallback indication to the MME(step 1) so that the MME can initiate therequired handover procedures. If CS fallback isallowed for the UE, the MME sends a message

nn

Figure 3. a) Architecture for single-radio VCC between E-UTRAN and 3GPP2 1x RTT CS; b) simplifiedmessage flow diagram for voice session handover from E-UTRAN to 3GPP2 1xRTT CS access.

UE

1. Measurement reports Voice path before handover

MME 1xRTTMSC

S-GW/P-GWE-UTRAN 1xCS

IWS1xRTT

CS access IMS Remoteend

E-UTRAN

IP multimediasubsystem

(IMS)

1xRTTCS access

Userequipment(UE)

2. Handover request (start 1x SRVCC)

3. Start SRVCC (MEID, 1xOrigination (VDN)...)

6. Release UE context7. Suspend EPS bearer

4. Initiate domain transfer4. Domain transfer successful5. 1x Handoff CMD

Voice path after handover completion

HSS

HLR1xRTTMSC

1xCSIWS

MME

S-GW

S1-U

P-GW

3GPP EPC

Voice path before handoverVoice path after handover to 1xRTT

MAP

A1

A1

S102

S6a

S11

S5 SGi

3GPP2 core

Handover decision

UE moves to 1xRTTHO detection

1xRTT traffic allocation3GPP2 VCC

Voice call transferprocedures

The architecture

connects the Mobile

Switching Center

and the Mobility

Management Entity

via the new SGs

interface. This inter-

face is based on the

Gs interface which

connects MSC and

Serving GPRS

Support Node and

was introduced to

reuse the concept of

combined mobility

management

between the CS and

PS domains.




(step 2) that instructs the eNB to transfer theUE to a neighboring UTRAN/GERAN cell.Before the eNB does so, it may request someradio measurement reports from the UE inorder to discover the best target UTRAN/GERAN cell (step 2b). In turn, a standard PShandover procedure is initiated (step 3) in

which PS resources are first reserved in the tar-get UTRAN/GERAN cell and then a handovercommand is sent to the UE to instruct it tomove to the target UTRAN/GERAN cell. Whenfallback to UTRAN/GERAN is successful, theUE sends a standard CM Service Request mes-sage to the MSC to request call establishment

nn

Figure 4. a) Simplified architecture of 3GPP CS Fallback; b) mobile originating call for CS fallback, UE in active mode; c) mobile ter-minated call for CS fallback, UE in active mode.

Userequipment(UE)

S1-U

S5 SGi

S11

S6a

DSGsS3

S4

Gb or lu-ps

A or lu-cs

lu-ps

lu-cs

Packet datanetwork

(e.g. Internet)

E-UTRAN

UTRAN

GERAN

2G/3G 3GPP core

MSCenhancedfor CSFB

MME

S-GW

Non-voice path before handover

P-GW

3GPP EPC

SGSN

Non-voice after handover to GERAN Voice path after handover to GERAN

HSS

UE MME SGSN

IP-packet path before handover

S-GW/P-GWE-UTRAN

1a. Service request

UTRAN/GERAN

EnhancedMSC

4a. SABM (with CM service request)4b. Complete layer 3 information with CM service request)4c. UA (with CM service request)

5b. Service reject 5a. Service reject If theMSC ischanged

2a. S1-AP message

2b. Optional measurement report solicitation

UE moves to 2G/3G

3. Packet-switched handover

5c. Location area update

If therouting areais changed

9. Routing area update procedure

6. CS call establishment procedure

Voice path after handover

IP packet path after handover

7a. Forward relocation complete7b. Forward relocation complete ack

8a. Update PDP context request

8b. Update PDP context response

UE E-UTRANUTRAN/GERAN

S-GW/P-GWSGSN

1a. PagingIP-packet path before handover

MME

1b. Paging

3a. S1-AP message

2a. Service request

5a. SABM (with paging response)

5c. UA (with paging response)

6b. RRC release

8a. Forward relocation complete8b. Forward relocation complete ack

9a. Update PDP context request9b. Update PDP context response

Voice path after handover

IP packet path after handover

6a. Connection reject If theMSC ischanged

2b. CS page reject

5b. Complete layer 3 information (with paging response)

EnhancedMSC

3b. Optional measurement report solicitation

6c. Location area update and roaming retry

If theroutingarea ischanged

10. Routing area update procedure

7. CS call establishment procedure

UE moves to 2G/3G4. Packet switched handover




(steps 4a–4c). In some cases (see [5] for details),the CM Service Request may be sent to an MSCother than the MSC with which the UE was reg-istered in E-UTRAN. In this case, the new MSCrejects the originating call request and a loca-tion update procedure is performed (steps5a–5c) followed by another CM Service Requestand the normal voice call establishment proce-dures (step 6).

In parallel with voice call establishment, thePS handover (initiated in step 3) between SGSNand S-GW/PGW is completed (steps 7a–7b), andthe active PS bearers are switched to UTRAN/GERAN access after the update PSP contextprocedure is finished (Steps 8a, 8b). Finally, atypical routing area update can be performedwhen the UE detects that it is now in a differentrouting area (step 9).

Figure 4c shows how CS fallback works formobile terminating calls. In this example dia-

gram, the UE is initially in E-UTRAN and hasan active data connection, and the target accesssupports simultaneous support of PS and CS ser-vices.

When there is an incoming call request, therequest is first routed to the MSC/VLR inwhich the UE is registered through combinedCS fallback attach or combined tracking areaupdate procedures. When the MSC/VLRreceives the incoming call request, it sends apaging message to the MME over the SGs inter-face (step 1a). The MME then forwards thispaging message to the UE over E-UTRANaccess (step 1b). This paging message is anNAS message that can securely carry a caller’sID. By informing the user of the caller’s IDprior to fallback, the user can decide whetherto accept CS fallback to legacy access for voicecalls. This caller ID notification over a pagingmessage is introduced especially for CS fallback

nn

Figure 5. a) IMS service continuity architecture based around the SCC-AS; and b) simplified messageflow diagram for voice call transfer with IMS service continuity mechanisms.

UE GERAN

Signaling path prior to transfer

Voice (and data) path prior to transfer

Additional signaling path following transfer

Voice path following transfer

Signaling path:Packet-based

Setup STN-SR INVITE (STN, SDP-MGW/MSC) INVITE

CSCFs PSTN/ISDNnetwork

SCCAS

STI-1allocatedto PS path

STI-2allocated

to CS path

MGCFMGW

RemoteISDN

phone

WLAN EPCMSC withIMS centralized

servicesWLAN CS

IP multimedia subsystemCall session control functionSession initiation protocolMedia gateway controllerHome subscriber serverAuthentication, authorization,accountingThird party call control

IMS:CSCF:SIP:MGC:HSS: AAA:

3PCC:

Public switched telephone netorkCircuit switchService switching pointMobile switching centerPrivate branch exchangeHome location registerApplication serverService centralization and continuity

PSTN: CS: SSP: MSC: PBX: HLR: AS: SCC:

IMS components

MGCSCC-AS(3PCC)

MGC Circuitswitch

Remote leg

I/S/P-CSCF

IMSphone

CSphone

I/S-CSCF

AAA/HSS/HLR

P-CSCF

(a)

(b)

Userequipment

(UE)

Possiblecomboof types

PSTNphonePSTN PSTN

SSP

2Gphone2G 2G

MSC

3Gphone3G 3G

MSC

4GphoneEPS 4G

access

SIPclientEnterprise SIP

IP-PBX

SIPclientWiMAX WiMAX

ASN

SIPclientWiFi WiFi

AP

Access leg

Re-INVITE

Re-INVITE(remote, SDP-MGW/MSC)

PTSN/ISDN legis unchanged

Circuit-based

Media path:Packet-basedTDM Circuit

IMS was designed to

enable intelligent,

IP-based services,

and features to be

located in the

evolved 3GPP

network. One key

aspect focused on

here is the ability to

maintain services

even when the user

is moving across

different access

networks and

terminal types.




to avoid unwanted fallback, especially when auser is engaged in fast data services over E-UTRAN.

Similar to mobile originated calls, PS hand-over and CS fallback are triggered by sending aService Request message to the MME (Step2a). If the user rejects incoming call requestbefore fallback, the MME returns a reject mes-sage to the MSC (Step 2b). When UE moves to2G/3G, UE sends a paging response to theMSC (steps 5a–5c). The paging response can berejected by the MSC if the UE is sending it tothe wrong MSC, and location area update istriggered. Location area update also triggersthe originating MSC to redirect the call to thecorrect MSC by means of an existing roamingretry procedure (steps 6a–6c). When a pagingresponse is successfully returned to the correctMSC, the CS call establishment proceduretakes place (step 7). PS handover is also com-pleted in a similar way, as explained in the pre-vious section.

IMS-BASEDVOICE CALL CONTINUITY

As mentioned before, voice call continuity mech-anisms in the evolved 3GPP system are also pro-vided by the IMS [11]. The IMS is a servicecontrol subsystem in the evolved 3GPP architec-ture (Fig. 1) and is based on SIP defined by theInternet Engineering Task Force (IETF) in RFC3261 and many related RFCs. IMS was designedto enable intelligent IP-based services and fea-tures to be located in the evolved 3GPP net-work. One key aspect focused on here is theability to maintain services even when the user ismoving across different access networks and ter-minal types.

The IMS specifications (e.g., 3GPP TS 23.228[11]) define the functionality of IMS compo-nents, including various types of call session con-trol functions (CSCFs) and application servers,which take advantage of SIP procedures to regis-ter users with IMS, and originate, terminate,transfer, and release multimedia sessions.Because voice is still the key service for serviceproviders, the first service continuity solutionwith IMS was designed to enable voice call con-tinuity (VCC) between a conventional accessnetwork supporting CS voice (e.g., GSM, UMTS,CDMA2000 1xRTT) and a VoIP access network(e.g., a WLAN). This was defined in 3GPP TS23.206 [6] as part of 3GPP specifications Release7. The second solution, service centralizationand continuity (SCC), defined in 3GPP TS23.237 [8] and 3GPP TS 23.292 [12], expands theVCC solution, and provides enhanced call trans-fer functionality and service centralization in theIMS. There is a common architectural theme, asshown in Fig. 5a.

Figure 5b shows an example of a mobileuser’s voice call being transferred from WLANaccess to GERAN CS domain access usingIMS service continuity procedures. One of thebenefits of using the IMS to transfer voice callsis that the same service continuity procedurescan be used no matter what the source and tar-get accesses are. Hence, although Fig. 5b shows

WLAN and GERAN as the source and targetaccess technologies, respectively, it is equallyapplicable to any other source and target accesstechnologies. In some cases (e.g., when theunderlying transport network cannot supportvoice transfer between two specific access tech-nologies) the IMS service continuity proce-dures are the only means to enable such voicetransfer.

Figure 5b considers an example where amobile device (UE) has a multimedia sessionwith a fixed device (remote ISDN phone). Atthe top of the figure, the path followed by sig-naling (SIP) messages and the path followed byuser traffic (voice and data) are shown. Notethat the signaling path needs to go through theSCC application sserver (SCC AS) [8], which isthe element that effectively enables sessiontransfer by using third-party call control (3PCC)procedures. In particular, the SCC AS splits thesession between the UE and the remote ISDNphone into two parts (or legs): one part betweenthe UE and SCC AS (called the access leg), andanother part between the SCC AS and remoteISDN phone (called the remote leg). This split isperformed when the multimedia session is initi-ated. The SCC AS terminates the original ses-sion request (say from the UE) and initiates anew session toward the remote ISDN phone. Bydoing so, the SCC AS appears as a third partybetween the UE and remote ISDN phone thatcontrols the call between them (hence the termthird-party call control).

As opposed to other handover mechanisms(e.g., the SR-VCC discussed previously), in allIMS service continuity mechanisms it is the UEthat makes handover decisions based on precon-figured operator policies, user preferences, andthe availability of neighbor access technologies.One operator policy could, for example, indicatethat GERAN CS has higher preference thanWLAN for voice sessions, so when the UE usesWLAN and discovers an available GERANaccess in its vicinity, it will try to transfer itsongoing voice and other sessions to GERANaccess.

When the UE makes the handover decision,it sends a standard CS Setup message to a spe-cial destination number, called a session transfernumber (STN), which causes the Setup messagesto be translated to a corresponding SIP INVITEmessage, and then routed to the SCC AS. Notethat the Setup message and the translatedINVITE message going to the SCC-AS create athird signaling leg (UE-CS to SCC) in additionto the existing access leg (UE-WLAN to SCC)and remote leg (SCC to remote ISDN phone).After receiving the INVITE message from theMSC enhanced with IMS centralized services[12], the SCC-AS generates the re-INVITE tothe MGCF, which updates the remote leg at theMGW to point to the MSC (with IMS central-ized services) rather than the UE’s WLAN IPaddress. Therefore, the voice media from theremote leg MGW is redirected to the MSC. Thepath of the voice media component after the ses-sion transfer is shown at the bottom of Fig. 5b.Note that in this example, if there are othermedia components (in addition to voice) activebetween the UE and the remove ISDN phone,

The SCC AS

terminates the

original session

request (say from

UE) and initiates a

new session towards

the Remote ISDN

phone. By doing so,

the SCC AS appears

as a third-party

between UE and

Remote ISDN phone,

which controls the

call between them

(hence, the term

third-party call

control).




they will either be released after voice is trans-ferred to GERAN CS domain or continue overthe WLAN. Of course, the latter case requiresdual-radio capabilities in the UE (i.e., capabilityto operate simultaneously on the WLAN andGERAN radio access.)

CONCLUSIONSThe next generation of 3GPP systems support anew wireless broadband radio access technologycalled E-UTRAN, and a vast range of mobilitymechanisms that facilitate many deployment sce-narios and support a flexible evolutionary pathtoward 4G mobile systems. Since E-UTRANcoverage will initially be limited compared to thecoverage of legacy radio technologies (UTRAN,GERAN, CDMA2000, etc.), many differenthandover mechanisms have been standardizedby 3GPP in order to enable ubiquitous voice callservices in many deployment scenarios and sup-port service continuity across a wide range ofradio environments. In this article we presentand explain these handover mechanisms, andidentify the key motivation behind them. It isshown that when voice services are supportedover E-UTRAN, the so-called SR-VCC mecha-nisms [7] can be used to seamlessly hand overvoice calls to legacy radio technologies such asUTRAN, GERAN, and 1xRTT. On the otherhand, when no voice services are supported overE-UTRAN, CS fallback mechanisms [10] can beused to transfer the user to a legacy radio accessthat supports conventional voice services overthe CS domain. Finally, we explain the applica-tion-layer handover mechanisms supported bythe IMS, which can facilitate additional voicecall continuity scenarios, especially when no ver-tical (or intersystem) mobility is supported bythe network layer [8, 12]. All these handovermechanisms allow the next generation of 3GPPsystems to support sophisticated voice call conti-nuity in all commercial deployments.

REFERENCES[1] 3GPP TS 36.300 v8.6.0, “Evolved Universal Terrestrial

Radio Access (E-UTRA) and Evolved Universal TerrestrialRadio Access Network (E-UTRAN); Overall Description;Stage 2,” Rel. 8, Sept. 2008.

[2] 3GPP TS 23.002 v8.3.0, “Network Architecture” Rel. 8,Sept. 2008.

[3] 3GPP TS 23.402 v8.3.0, “3GPP System Architecture Evo-lution: Architecture Enhancements for Non-3GPPAccesses,” Rel. 8, Sept. 2008.

[4] 3GPP TS 23.401 v8.3.0, “General Packet Radio Service (GPRS)Enhancements for Evolved Universal Terrestrial Radio AccessNetwork (E-UTRAN) Access,” Rel. 8, Sept. 2008.

[5] 3GPP TS 23.060 v8.2.0, “General Packet Radio Service(GPRS); Service Description; Stage 2,” Rel. 8, Sept. 2008.

[6] 3GPP TS 23.206 v7.6.0, “Voice Call Continuity (VCC)between Circuit Switched (CS) and IP Multimedia Sub-system (IMS); Stage 2,” Rel. 7, Mar. 2008.

[7] 3GPP TS 23.216 v8.1.0, “Single Radio Voice Call Conti-nuity (SRVCC); Stage 2,” Rel. 8, Sept. 2008.

[8] 3GPP TS 23.237 v8.1.0, “IP Multimedia Subsystem (IMS)Service Continuity; Stage 2,” Rel. 8, Sept. 2008.

[9] 3GPP2 X.S0042-0, “Voice Call Continuity between IMSand Circuit Switched System.”

[10] 3GPP TS 23.272 v8.1.0, “Circuit Switched Fallback inEvolved Packet System; Stage 2,” Rel. 8, Sept. 2008.

[11] 3GPP TS 23.228 v8.6.0, “IP Multimedia Subsystem(IMS); Stage 2,” Rel. 8, Sept. 2008.

[12] 3GPP TS 23.292 v8.1.0, “IP Multimedia Subsystem(IMS) Centralized Services; Stage 2,” Rel. 8, Sept. 2008.

ADDITIONAL READING[1] A. K. Salkintzis, N. Passas, and D. Skyrianoglou, “On the

Support of Voice Call Continuity Across UMTS andWireless LANs,” Wireless Commun. Mobile Comp. J.,2007.

BIOGRAPHIESAPOSTOLIS K. SALKINTZIS [SM‘04] ([email protected])received his Diploma (honors) and Ph.D. degree from theDepartment of Electrical and Computer Engineering, Dem-ocritus University of Thrace, Xanthi, Greece. In 1999 hewas a sessional lecturer at the Department of Electrical andComputer Engineering, University of British Columbia,Canada, and from October 1998 to December 1999 he wasalso a post-doctoral fellow in the same department. During1999 he was also a visiting fellow at the Advanced SystemsInstitute of British Columbia, Canada. During 2000 he waswith the Institute of Space Applications and Remote Sens-ing (ISARS) of the National Observatory of Athens, Greece.Since 1999 he has been with Motorola Inc. working on thedesign and standardization of wireless communication net-works, focusing in particular on UMTS, WLANs LTE, WiMAX,and TETRA. He has many pending and granted patents, haspublished more than 65 papers in referreed journals andconferences, and is a co-author and editor of two books inthe areas of Mobile Internet and Mobile Multimedia tech-nologies. He is an editor of IEEE Wireless Communicationsand Journal of Advances in Multimedia, and has served aslead guest editor for a number of special issues of IEEEWireless Communications, IEEE Communications Magazine,and others. His primary research activities lie in the areasof wireless communications and mobile networking, andparticularly on seamless mobility in heterogeneous net-works, IP multimedia over mobile networks, and mobilenetwork architectures and protocols. He is an active partici-pant and contributor in 3GPP and chair of the Quality ofService Interest Group (QoSIG) of IEEE Multimedia Commu-nications Technical Committee. He is also a member of theTechnical Chamber of Greece.

MIKE HAMMER ([email protected]) received his B.S. degreein electrical engineering from the University of Dayton,Ohio, and his M.B.A. from the Florida Institute of Technol-ogy. He completed electrical engineering graduate course-work at the U.S. Air Force Institute of Technology, andreceived his M.S.E.E. from George Mason University. Cur-rently, he represents Cisco Systems at the WiMAX Forumand ATIS, with a focus on mobility and VoIP architectures,and previously SIP-related product development. Prior tothat he was a Booz, Allen, and Hamilton consultant help-ing U.S. law enforcement create lawful intercept architec-ture and standards for digital and mobile networks, as wellas helping the Department of Defense on Defense Messag-ing System requirements, electronic commerce, and PKIcapabilities. Before that, as an U.S. Army officer, heplanned missile tests, managed the migration of the ArmyEuropean Telephone System from analog to digital,planned the first Internet for U.S. Army Europe, then creat-ed and taught the first data networking courses for theU.S. Army Computer Science School. His interest is in con-vergence of wireline and wireless technologies and migra-tion of circuit-based networks to packet-based systems.

ITSUMA TANAKA received a degree (M.Eng.) from ImperialCollege London, United Kingdom. In 2004 he joined NTTDOCOMO, Inc. and has been involved in many mobile ser-vices and architecture design projects. Since 2007 he hasbeen an active participant and contributor in 3GPP SA2,focusing in particular on UMTS and SAE. He is a rapporteurof various 3GPP work items. He is a member of IEICE.

CURT WONG is currently in the role of specialist at NokiaSiemens Networks, Redmond, Washington. He has beenwith Nokia since 1995 working in several different rolesand technologies. His primary focus has been in the areasof wireless technologies and system level developments,with emphasis on the infrastructure side of cellular net-works. His current activities and involvement are mainly onvoices services over LTE, including IMS, emergency aspects,and interworking with legacy 2G and 3G networks. He isan active participant in and contributor to 3GPP standards.He has a B.S. in electrical engineering from the Universityof Texas at Austin and an M.S. in telecommunications fromSouthern Methodist University, Dallas, Texas.

Since E-UTRAN

coverage will initially

be limited compared

to the coverage of

the legacy radio

technologies, many

different handover

mechanisms have

been standardized

by 3GPP in order to

enable ubiquitous

voice call services in

many deployment

scenarios.



mag, voice call handover mechanisms in next-generation 3gpp systems

Documents