Practical Performance Analysis of CSFB and VoLTE

IEEE P

roof

IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY 1

Practical Performance Analyses of Circuit-SwitchedFallback and Voice Over LTE

1

2

Ayman Elnashar, Mohamed A. El-Saidny, and Mohamed Mahmoud3

Abstract—The Internet Protocol (IP) Multimedia Subsystem4(IMS) is a framework for delivering all-IP-based services. Voice5via IMS has been defined as a possible solution from Third-6Generation Partnership Project (3GPP) Release 5, prior to long-7term evolution (LTE). However, the cost and immediate need for8IMS services prevented operators from migration to IMS-based9services, particularly with the wide presence of circuit-switched10(CS) services offered in Global System for Mobile Communica-11tions (GSM) and Universal Mobile Telecommunications System12(UMTS) networks. CS fallback (CSFB), which was introduced13in 3GPP Release 8, enables the support of voice service without14IMS. This is the common deployed scenario for many exiting LTE15networks. Voice over LTE (VoLTE) is compulsory to offer rich16communication services (RCS) via IMS, in addition to improving17the performance of the already deployed CSFB voice solution.18However, CSFB and VoLTE are still deployed concurrently, where19operators can gradually roll out an LTE/IMS system, while still20supporting 2G/3G fallback mechanism. It is, therefore, important21to benchmark the performance of both solutions, highlight the22deployment challenges, and study the impacts on the end-user23experience. This paper provides performance analysis, deploy-24ment challenges, and comparisons between these voice solutions.25This paper presents practical performance analysis, including26end-to-end assessment of call setup delay under different radio27conditions, main challenges impacting the in-call performance, as28well as performance aspects of Single Radio Voice Call Continuity29(SRVCC) and its evolution releases.30

Index Terms—Circuit-switched fallback (CSFB), enhanced31SRVCC (eSRVCC), Evolved Universal Terrestrial Access Network32(E-UTRAN), Internet Protocol (IP) Multimedia Subsystem (IMS),33long-term evolution (LTE), Single Radio Voice Call Continuity34(SRVCC), UMTS, voice over IP (VoIP), voice over LTE (VoLTE).35

I. INTRODUCTION36

37 THE INTERNET Protocol (IP) Multimedia Subsystem38

(IMS) is an all-IP system designed to assist mobile op-39

erators deliver next-generation interactive and interoperable40

services, cost effectively, and over an architecture providing the41

flexibility of the Internet [1], [2]. Although IMS was initiated42

in the Third-Generation Partnership Project (3GPP) since early43

releases (Release 5), it has yet to be widely implemented. The44

main reason is the use of the well-established 2G/3G circuit-45

Manuscript received November 8, 2015; revised March 8, 2016; acceptedApril 25, 2016. The review of this paper was coordinated by Dr. F. Gunnarsson.

A. Elnashar and M. Mahmoud are with Emirates Integrated Telecommu-nications Company, Dubai, UAE (e-mail: [email protected]; [email protected]).

M. A. El-Saidny is with MediaTek, Dubai, UAE (e-mail: [email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TVT.2016.2560962

switched (CS) networks offering voice and other CS services. 46

Network operators need to invest to deploy a complete IMS- 47

based network consisting of multiple core network elements. 48

An IMS client also needs to be incorporated on the user 49

equipment (UE) to interact with the network. Various key 50

telephony functions should be supported with the IMS core 51

network and IMS client on the UE to ensure satisfactory cus- 52

tomer telephony experience. Therefore, the IMS deployment 53

requires major investment from operators, network vendors, 54

and device manufacturers. Both the long-term evolution (LTE) 55

device and the network need to support various features across 56

the LTE protocol stack to ensure satisfactory voice over LTE 57

(VoLTE) performance. Some features are also need to ensure 58

optimum LTE system capacity for large numbers of VoLTE 59

users. Moreover, Single Radio Voice Call Continuity (SRVCC) 60

provides an interim solution for handing over VoLTE call to 61

legacy 2G/3G networks. 62

On the other hand, circuit-switched fallback (CSFB) to 2G/3G 63

networks has been widely deployed as an interim voice solution 64

within the deployed LTE packet-switched (PS) networks. As AQ165

soon as the UE originates or receives a voice call, the eNodeB 66

(eNB) will redirect the UE to Universal Mobile Telecommu- 67

nications System (UMTS) or Global System for Mobile Com- 68

munications (GSM) network, depending on the configuration 69

and underlying coverage [3]. Therefore, the CSFB architecture 70

requires interworking between the evolved packet core (EPC) 71

and the 2G/3G CS core network. Specifically, it requires the 72

SGi interface between the mobility management entity (MME) 73

in the EPC and the mobile switching center (MSC) in the 2G/3G 74

CS core network [4]. The requirements to minimize the number 75

of interfaces between the core networks, as well as reusing the 76

air interface of the existing 3G/2G for the voice calls, have 77

accelerated the CSFB deployment, and therefore, it has been 78

adopted as the first choice for voice with LTE. However, with 79

the rapid spread of LTE deployment worldwide, there is a need 80

for a framework that enables subscribers to access a range 81

of multimedia services without fallback to the legacy 2G/3G 82

systems. There is also a growing motivation to compete with 83

over-the-top (OTT) voice-over-IP (VoIP) services, which have 84

fragmented the value-added services using cross platforms and 85

technologies. This also restricted the capability for the mobile 86

operators to provide only access and dump pipe, while OTT 87

services are indirectly being subsidized. 88

Voice is a real-time service with tight delay requirements; 89

thus, it requires a robust underlying radio network to ensure 90

an optimal user experience. VoLTE requires end-to-end quality 91

of service (QoS) to be supported at all layers from the device 92

through the radio network up to the core network and including 93

0018-9545 © 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

IEEE P

roof

2 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY

interaction with the IMS core. This is needed to ensure robust94

signaling performance and optimal voice quality in the presence95

of other data traffic (particularly in loaded scenarios). These96

factors add strict requirements to the LTE network for enabling97

VoLTE as a voice solution to the end user [3]. 3GPP has adopted98

GSMA IR.92 IMS profile for voice and SMS [5] and GSMA99

IR.94 IMS profile for conversational video [6] to provide high-100

quality IMS-based telephony services over LTE radio access.101

The profiles define optimal sets of existing 3GPP-specified102

functionalities that all industry stakeholders, including network103

vendors, service providers, and handset manufacturers, can use104

to offer compatible LTE voice/video solutions.105

The performance of CSFB, VoLTE, and SRVCC are key106

elements to guarantee good voice experience within the LTE107

network [7]–[11], particularly that a mix of VoLTE and CSFB108

devices can coexist in the same LTE network. The CSFB109

performance based on redirection has been analyzed in [8] for110

3GPP Release 8 and Release 9 and compared with UMTS.111

The analysis in [8] shows that, on average, mobile-terminated112

(MT) or mobile-originated (MO) call setup delay for CSFB113

from LTE to UMTS is around 1 s greater than legacy UMTS114

CS calls. A delayed-return approach was proposed in [9] to115

minimize the effect of CSFB by 60%, by which the UE is kept116

in UMTS without returning to LTE if there is no active data117

session. A limited access transfer algorithm that reduces the118

number of ping-pong between LTE and UMTS in an SRVCC119

call is proposed in [10], by which the large access transfer traffic120

delay can be improved. VoLTE in call performance has been121

evaluated in commercial networks, in terms of audio quality122

and call reliability, in [11].123

The focus of this study is the call setup delay for CSFB124

and VoLTE and SRVCC performance, in terms of voice inter-125

ruption. The contribution in this paper is in three folds. First,126

the CSFB call flow and relevant call setup key performance127

indicators (KPIs) are established and analyzed in detail forAQ2 128

the redirection and PS handover strategies. The call setup129

KPIs for different strategies (basic Release-9 redirection, en-130

hanced Release-9 redirection, and PS handover with/without131

gap measurements) are evaluated along with the associated132

performance and challenges. The second contribution is the133

analysis of the VoLTE call setup delay in a comparative manner134

with CSFB. The relevant VoLTE KPIs are established and135

analyzed at different scenarios, including near-cell, far-cell, and136

mobility conditions. The third contribution is the analysis of137

the enhanced SRVCC (eSRVCC) performance and its relevant138

KPIs, while being compared to delays associated with LTE139

intrafrequency handover. All analyses in this paper are based140

on commercial LTE/HSPA+ networks. The best practices and141

optimization techniques for CSFB, VoLTE, and eSRVCC are142

provided based on live network performance and the targeted143

end-user experience. In this paper, we use the terms LTE and144

Evolved Universal Terrestrial Access Network (E-UTRAN),AQ3 145

interchangeably, as well as UMTS and Universal Terrestrial146

Access Network (UTRAN).147

The remainder of this paper is organized as follows. The148

call flows and call setup delay KPIs for CSFB and VoLTE are149

described and established in Sections II and III, respectively.150

eSRVCC and its deployment aspects are analyzed in Section IV.151

TABLE ICSFB DEPLOYMENT STRATEGIES

Performance analyses of CSFB, VoLTE, and eSRVCC are 152

provided in Section V. The conclusions are summarized in 153

Section VI. 154

II. CIRCUIT-SWITCHED FALLBACK CALL FLOW AND 155

RELEVANT KEY PERFORMANCE INDICATORS 156

Various methods are specified in 3GPP to handle CSFB 157

from LTE to UMTS once a voice call is initiated [3], [7], 158

[12]. The CSFB to UTRAN can be executed by two methods. 159

The first method is “Redirection” based, in which upon an 160

initiation of a voice call, the E-UTRAN radio resource control 161

(RRC) layer releases the UE from LTE and redirects it by the 162

same message to the other radio access technology (RAT) to AQ4163

handle the voice call, while the PS data session is interrupted 164

until the data session is reinitiated on the target RAT. The 165

second method is “PS Handover” based, where a PS handover 166

from E-UTRAN to the target RAT (UTRAN in this paper) is 167

initiated by the eNB to handle the voice call, while the PS data 168

session can partially remain uninterrupted until the handover 169

is completed. Both mechanisms are applicable for MT or MO 170

calls, while the UE is in RRC idle or connected mode. There 171

are a number of improvements and flavors in the “Redirection” 172

mechanism targeting enhanced voice call setup delay and PS 173

interruption time [12]. The most common CSFB mechanisms 174

are summarized in Table I. Each type is typically deployed 175

based on the network and device capabilities. Several methods 176

can be deployed together to address device capabilities. 177

Fig. 1 illustrates the call signaling flow for two CSFB mech- 178

anisms, i.e., RRC redirection and PS handover [3]. For CSFB 179

with RRC redirection, the call is initiated, and the UE sends an 180

extended service request (ESR). The redirection method works 181

by releasing the RRC connection, while the UE is camped on 182

an LTE cell. The RRC release message indicates the specific 183

frequency and RAT information for the UE to be redirected 184

IEEE P

roof

ELNASHAR et al.: PRACTICAL PERFORMANCE ANALYSES OF CSFB AND VOLTE 3

Fig. 1. MO CSFB from E-UTRAN connected mode to UTRAN.

after the release. The device can then search for any cell on the185

redirection frequency and RAT, acquires the targeted RAT and186

frequency, and then initiates a normal CS call setup procedure.187

Step 8 in Fig. 1 indicates the concept of CSFB redirection188

occurrence as part of the RRC connection release in LTE.189

CSFB redirection is typically performed with no prior inter-190

RAT (IRAT) measurements on the targeted system. Therefore,191

steps 4–7 are optional. Initiating a CSFB call with or without192

IRAT measurements depends on the deployment strategy. The193

measurement-based redirection may help in achieving load194

sharing between multiple 3G frequency carriers during the195

CSFB procedure. However, achieving this kind of load sharing196

at a cell level within the same 3G frequency carrier is subject197

to the CSFB mechanism. Release-8 redirection is restricted to198

deliver the UE to the targeted frequency of the RAT (not the199

cell), whereas Release 9 provides the flexibility to indicate both200

cell and frequency carrier information. Hence, load sharing at201

the cell level cannot be achieved with Release 8, even if the UE202

is able to measure and report the best cell within one carrier.203

This limits the use case of deploying a measurement-based204

Release-8 CSFB redirection strategy.205

For Release-8 CSFB, the UE performs a full search to acquire206

any cell on the redirected RAT [e.g., if the redirection to UMTS,207

the UE will search the full 512 primarily scrambling codes208

(PSCs) on the redirected frequency]. After the RRC release209

message is received, the UE directly moves to UMTS idle mode210

and reads the system information blocks (SIBs), as shown in211

step 11. The SIBs are continuously broadcasted by the cell,212

allowing the UE to know the initial configurations of the cell’s213

parameters. Compared to UMTS-only CS calls, the entire SIB214

reading prior to call setup is not required, as the UE would have215

previously decoded them when initially camped on the cell.216

Therefore, the main challenge of the redirection method is the217

call setup delay due to SIB reading. To overcome this burden,218

deferred measurement control reading (DMCR) is introduced.219

This feature allows the UE to skip reading nonmandatory SIBs220

(such as SIBs 11/12/19, or any of their extensions) during221

the CS call setup. Therefore, the UE will read the mandatory222

SIBs, such as 1, 3, 5, and 7 in step 11. This further reduces223

the delays coming from reading all of the SIBs. However, for224

DMCR to work efficiently, the UE needs to read SIB 3, to225

understand whether the DMCR is supported in the cell or not.226

Therefore, SIB scheduling optimization in a deployed network227

is still required, where the UMTS radio network controller228

TABLE IIKPIS IMPACTING CSFB CALL SETUP LATENCY

(RNC) shall ensure that SIB 3 is scheduled to the UE as soon as 229

possible. On the other side, UMTS SIB tunneling is introduced 230

during the redirection process from LTE to UMTS [12]. In this 231

mechanism, a list of PSCs is defined in the LTE RRC release 232

message, with a container that includes the associated SIBs for 233

each cell. 234

The second mechanism is the CSFB with PS handover, which 235

is denoted as PSHO and shown also in Fig. 1. In the PSHO 236

procedure, the target cell is prepared before the fallback to 237

UTRAN is triggered. The device can camp on the target cell 238

directly in UTRAN connected mode (i.e., Cell_DCH). During 239

the execution of the handover procedure, the eNB typically 240

configures the UE to perform IRAT measurements within a 241

specified gap duration (i.e., a tune-away mechanism for the 242

UE to measure another RAT while camped on LTE, which is 243

specified by a gap repetition every 40 or 80 ms and a duration 244

of 6 ms). Alternatively, the PSHO can be triggered blindly 245

where a neighbor relation is defined between the UTRAN and 246

E-UTRAN systems. The PSHO is helpful for the CSFB strategy 247

when the PS data session is active. In this case, the PS radio 248

bearer is established earlier during the handover procedure, 249

which helps to minimize the PS data interruption time during 250

the transition to the other RAT, i.e., a benefit that can be visible 251

over the redirection case. 252

The CSFB call setup latency can be derived from the time 253

from when the ESR message is sent until the ALERTING mes- 254

sage is received. This applies for any kind of CSFB, whether 255

being a redirection or PSHO. Additionally, the CSFB call setup 256

delay is further categorized into several KPIs to measure the 257

factors that contribute to the call setup delay. Table II illustrates 258

these KPIs and calculation methodologies. 259

III. VOICE OVER LONG-TERM EVOLUTION CALL FLOW 260

AND RELEVANT KEY PERFORMANCE INDICATORS 261

One of the significant changes introduced in LTE is that, 262

when the mobile device connects to the network, it also im- 263

plicitly gets an IP address, which is known as the evolved 264

IEEE P

roof


Fig. 2. EPS bearers during VoLTE call and at call end.

packet system (EPS) default radio bearer (DRB). With theAQ5 265

default EPS bearer activation, the packet call is established at266

the same time when the UE attaches to EPS, i.e., always on.267

Although, the default DRB is enough for the downlink (DL) and268

uplink (UL) data transfer in an EPS network, it comes with no269

guaranteed QoS. For real-time applications such as voice, QoS270

is needed particularly on the air interface. To exploit the service271

differentiation, LTE has also introduced another EPS bearer272

known as “Dedicated EPS Data Bearer,” which is initiated for273

any additional data radio bearer. To guarantee the voice quality,274

the IP voice traffic needs to be carried over guaranteed bit rate275

(GBR) bearers with QoS class identifier (QCI = 1). The default276

bearer is a non-GBR bearer (i.e., with QCI = 9) and is used for277

the best effort PS traffic [3]. The network resources associated278

with the VoLTE voice GBR bearer must be allocated, when this279

bearer is established, and can be released once the voice call280

is ended. Additionally, another bearer is needed to ensure that281

the IMS signaling part is transmitted with a different QoS. As282

a VoLTE call is initiated on a different access point name, then283

the IMS signaling shall be mapped into a different QCI. The284

common configuration to transport the IMS signaling uses a285

default EPS bearer with QCI = 5.286

For a VoLTE-capable device, the UE shall be configured with287

the proper EPS bearers to transport LTE signaling and data,288

IMS signaling, and media traffic. The LTE signaling messages289

are mapped to the preallocated signaling radio bearers (SRBs).290

Therefore, a VoLTE-capable UE must support the following:291

SRB1 + SRB2 + 4 × AM (Acknowledge Mode) DRB + 1 ×292

UM (Unacknowledged Mode) DRB [5], [13]. Fig. 2 illustrates293

an example of the configurations and mapping for each EPS294

bearer during a VoLTE call across different LTE layers. The295

DRBs can be further mapped into layer-3 radio link control296

(RLC) as AM or UM modes. The eNB links the choice of the297

RLC mode to a certain QCI to maintain the desired QoS. The298

RLC AM mode ensures an in-sequence delivery of the packets299

subject to delay sensitivity (such as the PS data and LTE/IMS300

signaling), whereas the RLC UM mode provides a reduction301

in processing time and overhead, which is suitable for VoLTE302

media packets.303

Session initiation protocol (SIP) is utilized in IMS to manage304

all aspects of a session, including creation, modification, and305

termination. The UE and the network act as client and server306

using a standard set of requests, which is answered by a307

standard set of responses. The IMS in client and server must308

Fig. 3. VoLTE to VoLTE call setup flow with QoS-aware devices, precondi-tions enabled, and network-initiated QoS.

support the SIP precondition framework, as specified in [5]. 309

Through an exchange of messages, both the originator and the 310

terminator devices are aware of any preconditions associated 311

with a specific session and their current status. The session 312

description protocol (SDP) is utilized within the SIP message to 313

enable the characteristics of a session and the associated media 314

to be specified. SDP is referred to as an offer/answer model, in 315

which the client proposes a set of characteristics to which the 316

server responds. There is no guarantee that the answer contains 317

the same characteristics as the offer. 318

To initiate a VoLTE call, as illustrated in Fig. 3, the UE 319

sends a SIP INVITE with SDP information. The SDP infor- 320

mation carries the media QoS requirement for the audio and its 321

source transport address. The source of the transport address 322

information for the IMS signaling bearer can be determined 323

from the SIP INVITE. The terminating UE responds with a SIP 324

100 TRYING, acknowledging that the SIP INVITE is received 325

successfully. Now, the MT UE sends the 183 Session Progress 326

message that includes the SDP answer [to indicate the selected 327

codec, i.e., a set of wideband or narrowband adaptive multirate 328

(AMR)]. The IMS server then triggers the setup of a dedicated 329

bearer to carry the voice call payload for both MO and MT UEs. 330

The MO UE sends a provisional acknowledgement to the MT 331

UE via the IMS core network to confirm that codec selection 332

is completed. Once the establishment of the media dedicated 333

bearer for the originating UE is complete, it sends a SIP Update 334

to the terminating UE, to indicate that resource reservation 335

has been also completed. Upon reception of the SIP Update, 336

the terminating UE generates a user alert and responds with a 337

200-OK (for the SIP Update message). The terminating UE 338

then sends a 180 Ringing SIP message to the originating UE, 339

which triggers a ring-back tone to the originator. The terminat- 340

ing UE then sends a 200-OK for the original SIP INVITE, and 341

after this point, the voice call path can be considered as fully 342

established. 343

The VoLTE call setup delay can be estimated from SIP 344

INVITE to SIP 180 Ringing messages. It is important to mea- 345

sure the perceived delay after the user answers the call. This 346

is because the VoLTE call can experience an inactivity stage 347

that triggers RRC state transition to idle while the call is being 348

setup (VoLTE is a data session). Hence, we add the additional 349

delay from when SIP 200-OK is sent until the user receives 350

the first DL packet. Table III illustrates the VoLTE-related KPIs 351

IEEE P

roof


TABLE IIIKPIS IMPACTING VOLTE CALL SETUP LATENCY

Fig. 4. SRVCC standard evolution in 3GPP.

and their methods of calculations. The main reason to include352

the first DL packet after call setup is to check a unique issue353

in VoLTE that is not there in CSFB or legacy CS calls. The354

VoLTE SIP messages are all IP, and hence, the eNB does not355

sniff the actual SIP message content. Therefore, if the MT party356

takes a long time to answer the call, then the MO can go to idle357

mode due to the expiry of user-inactivity timer (i.e., no more358

data activity that moves the UE from connected to idle mode).359

IV. SINGLE RADIO VOICE CALL CONTINUITY360

LTE is completely based on the PS domain; therefore, the361

voice services are provided using a VoIP platform such as IMS.362

Most of the LTE introduction strategy is based on gradual ex-363

pansion based on traffic load and capacity forecast. Therefore,364

if LTE coverage is not available, a handover is necessary to365

2G/3G CS networks to maintain the voice call. This entails366

a handover of a PS-based VoIP call to a CS-based voice call367

in a 2G/3G network. 3GPP introduced the SRVCC feature368

to support seamless handovers between PS VoIP calls and369

CS voice calls [14]. SRVCC combines optimized handovers370

defined between LTE and legacy 2G/3G networks, and voice371

call continuity is defined in the IMS core network [15]. SRVCC372

requires the UE to support the ability to transmit and receive373

on two networks (PS and CS based) simultaneously. SRVCC374

went through different stages in the standard to reduce the voice375

interruption time that impacts the user experience, as well as376

improving the call setup success rate at different stages of the377

VoLTE call. As illustrated in Fig. 4, 3GPP has started with378

the support of SRVCC in Release 8/9 and then enhanced the379

mechanism to support eSRVCC in Release 10 [16]. The main 380

target of the eSRVCC is to reduce the voice interruption during 381

the intertechnology handover. eSRVCC targets an interruption 382

of < 300 ms. Most of the LTE networks will introduce VoLTE 383

over Release-10 devices only to offer better user experience 384

using eSRVCC. This is controlled from a provisioning and 385

handset perspective. Therefore, in this analysis, we will assess 386

the eSRVCC only. 387

Moreover, an important SRVCC feature to allow PS to CS 388

SRVCC access transfer of a call in the alerting phase, which 389

is referred to as aSRVCC, is introduced [17]. As illustrated 390

in Fig. 3, aSRVCC refers to a SIP session for which existing 391

dialogs created by the SIP INVITE request initiating the session 392

are early dialogs and the final SIP response is not received yet 393

while SIP 180 (Ringing) response has already been received 394

in existing early dialogs [16]. In addition, the SRVCC proce- 395

dure for both video calls (vSRVCC) and the reverse SRVCC 396

from UTRAN/GSM EDGE Radio Access Network (GERAN) AQ6397

systems to E-UTRAN system (rSRVCC) are introduced in 398

Release 11, as indicated in Fig. 4. 399

Release 10 specifies support for PS to CS SRVCC access 400

transfer of a call in the alerting phase [16]. However, this 401

release has not provided the support for PS to CS SRVCC 402

access transfer of a call in the pre-alerting phase [e.g., after the 403

SRVCC UE has received a SIP 183 (Session Progress) response 404

containing the SDP answer and before the SIP 180 (Ringing) 405

response has been received]. If the UE receives early media or 406

announcements from the network in the pre-alerting phase, the 407

network will not perform SRVCC of the IMS session in the 408

pre-alerting phase, and this will impact the user experience. To 409

address this case, PS to CS SRVCC of originating call in the 410

pre-alerting phase has been specified in Release 12 [17], [18], 411

which is referred to as bSRVCC, as illustrated in Fig. 4. 412

In this paper, we will analyze the eSRVCC. The main idea of 413

eSRVCC scheme is to anchor a VoIP call (media session) on an 414

IMS network element, which is near the local end, so that only 415

the branch of the anchor point to the local end needs to be mod- 416

ified, without the need for modifications on the remote end, and 417

thus can shorten the handover delay during the session transfer. 418

To support eSRVCC, two new IMS entities are introduced 419

to the anchor media session: access transfer control function 420

and access transfer gateway (ATGW). Adopting the ATGW 421

avoids the path switching between the LTE and 2G/3G media 422

gateways for the terminating UE, when the IMS originating UE 423

is transferring the IMS VoLTE call from PS to CS. From an 424

LTE signaling point of view, the eSRVCC works similar to the 425

PSHO call flow described in Fig. 1. The PSHO steps from 4 to 426

14 in Fig. 1 apply in the same manner on the eSRVCC call flow 427

during the handover from LTE to UMTS while the VoLTE call 428

is active. 429

V. PERFORMANCE ANALYSIS 430

In this paper, the CSFB and VoLTE performance are assessed 431

in terms of two perspectives as follows: 432433

1) Call setup performance 434

The focus is on the MO side, where the user can 435

perceive the main delays from the call establishment. 436

IEEE P

roof


Therefore, mobile-to-mobile (M2M) calls, either CSFB437

to CSFB or VoLTE to VoLTE, are assessed in this paper.438

The M2M call test case is chosen to provide an end-to-end439

call setup delay that closely matches the user’s experience440

with high-end smartphones.441

2) VoLTE in-call mobility performance when LTE coverage442

degrades and a VoIP call is active443

CSFB in-call performance assessment is not discussed444

in this paper because the voice call falls back to UMTS445

and the performance afterward becomes similar to that in446

legacy UMTS-only voice calls.447

The data are processed from field measurements with a large448

sample size (i.e., 100 CSFB/VoLTE calls for each scenario), and449

results were averaged over two different LTE access networks450

from two different suppliers and two smartphones. The perfor-451

mance testing is conducted in collocated (i.e., same physical452

sites) LTE/HSPA+ commercial networks. The LTE is deployed453

with 1800 MHz (20-MHz channel) and UMTS with 2100 MHz454

(2 × 5 MHz). The different CSFB scenarios listed in Table I are455

tested in the same exact cluster after modifying the scenarios’456

relevant parameters (i.e., change is done in the RNC for 3G-457

related parameters and in eNB for LTE-related parameters such458

as SIB tunneling). The VoLTE testing is conducted in the same459

cluster with the same device supporting all CSFB strategies460

and VoLTE (Release-10 device). The KPIs are derived from the461

device side through postprocessing scripts of the collected logs.462

A. CSFB Performance Analysis463

Several challenges are typically raised when CSFB is de-464

ployed in a network: a) CSFB call setup delay; b) CSFB setup465

success rate; c) data packet delay during the fallback; d) how466

fast to camp back on LTE after voice call is released. The third467

factor is of slightly less importance because the smartphone468

user receiving or making a CS call is expected not to pay469

attention to the data session being partially interrupted in the470

background during the fallback process. The fourth factor is471

typically driven by the deployment strategy in the network;472

either camp back on LTE using cell reselection procedure or473

network-based fast return to LTE. In this paper, we benchmark474

the first and fourth factors, and we discuss the aspects related to475

improving the third factor.476

As shown from the CSFB call flow in Fig. 1, the process of477

CSFB can take different stages, where each contributes expo-478

nentially to the call setup delay. Unlike the call setup performed479

in UMTS-only calls, the fallback mechanism requires steps that480

are adding extra delays to the call setup. Therefore, it is quite481

challenging to ensure the same user experience between CSFB482

and legacy CS voice calls. Fig. 5 provides the average along483

with median, 90th, and 10th percentiles for CSFB KPIs defined484

in Table II for the different scenarios defined in Table I.485

Fig. 5 demonstrates that the fourth scenario (S4) (i.e., PSHO486

without measurements) experiences the lowest call setup delay.487

The redirection with SIB tunneling scenario (S3) is ranked488

number 2 after S4. It is also noted that the performance of the489

PSHO with measurement scenario (S5) is worst than the S4490

scenario. The PSHO without measurements scenario performs491

the best in call setup delay due to factors, such as the UE does492

Fig. 5. CSFB call setup delay performance in mobility: MO side.

not decode the SIBs, as well as notable reductions in non- 493

access stratum (NAS) end-to-end signaling between UE and 494

core network when establishing the CS call setup. The UE is 495

not required to decode the SIBs because the UE directly enters 496

the 3G dedicated channel in connected mode (Cell_DCH state) 497

and, hence, the cell parameters can be later conveyed to the 498

UE through the dedicated RRC messages. The NAS end-to-end 499

delay in PSHO is generally lower than other scenarios because 500

the UE is assigned the PS data bearer in the handover message 501

itself, and this reduces the delay of establishing the PS bearer 502

afterward. The time observed between ESR and handover 503

command in S5 is higher than the blind redirection/handover 504

cases. This is related to the need of configuring the UE with 505

3G neighbors and IRAT measurements prior to the handover 506

preparation by the eNB, which is not required in the blind 507

redirection/handover scenarios. In all cases, the average time 508

to tune to UTRAN after the redirection or PSHO command is 509

about ∼45 ms. 510

Nevertheless, the blind PSHO mechanism can impact the 511

call setup stability and, accordingly, the CSFB call setup suc- 512

cess rate. Specifically, call setup failures can happen in a fast 513

changing RF environment or if the neighbor cell targeted for a 514

blind handover is loaded [i.e., low EcNo ≤ −18 dB with good 515

received signal code power (RSCP) ≥ −90 dBm]. Therefore, if 516

this strategy is adopted, a careful optimization of the neighbor 517

relation is needed, particularly that LTE and UMTS are typi- 518

cally deployed in different bands (such as LTE1800 MHz and 519

UMTS2100 MHz). This may lead to different RF propagation 520

characteristics at the cell edge. In this scenario, a neighbor 521

relation becomes harder to maintain when the reference signal 522

received power (RSRP) of LTE1800 at the cell edge is better 523

than the collocated UMTS2100 RSCP [3], [19]. 524

On the other hand, the redirection with SIB tunneling (S3) 525

reduces the call setup delay because the SIBs are broadcasted 526

to the UE through the RRC connection release. As soon as the 527

UE goes into 3G idle mode, it acquires the SIBs directly from 528

the RRC message, and hence, the UE would only need to search 529

for the suitable cell/frequency indicated by the RRC release 530

message and then performs the cell selection procedure. The 531

same concern about call stability needs to be considered here. 532

Similar to PSHO without measurements, the SIB tunneling 533

CSFB works in a way where multiple neighbors (cell ID and 534

carrier frequency) must be defined in the RRC release message. 535

IEEE P

roof


Once the UE falls down to 3G idle mode on the specified carrier,536

the UE would select the best cell, from its own search, and537

then see if the best cell was part of the neighbors list in RRC538

redirection to skip those SIBs. If the best cell is not among this539

list, then the UE is required to read all of the SIBs and proceed540

with the CSFB call setup. Hence, if the neighbor relation is541

not carefully optimized, the SIB tunneling mechanism may542

potentially produce similar call setup delays similar to Release543

CSFB strategies [3].544

The redirection procedure with basic functions (S1) performs545

the worst because the UE decodes all of the mandatory SIBs.546

However, the same strategy with an enhanced SIB scheduling547

(S2) improves the SIB decoding stage. This is because the548

SIB periodicities of those mandatory SIBs (i.e., SIB 1, SIB 3,549

SIB 5, and SIB 7) are scheduled with lower intervals. In this550

scenario, the SIB periodicity of SIB 3 is reduced from 1280 to551

160 ms, and SIB 1/5 periods from 640 to 320 ms, while keeping552

SIB 7 as 160 ms. As a result, the UE would quickly acquire553

those SIBs and then moves directly to the RRC connection554

setup stage. The S1 and S2 scenarios can be more stable in555

terms of CSFB success rate (compared to S3, S4, and S5)556

because the UE would typically select the best cell out of the ex-557

plored 512 scrambling codes, when the specific cell is not558

defined for the UE within the RRC release message (only the559

frequency carrier is specified).560

The PSHO with measurements (S5) in this study was exer-561

cised with three preconfigured UMTS frequency carriers with a562

total of 32 UMTS neighbors on each carrier. This effectively563

means that the device needs to measure all neighbor cells564

before reporting the measurement values to the eNB as part of565

even B1 evaluation (i.e., IRAT neighbor becomes better than566

a configurable threshold). This adds a significant delay to the567

stage between the ESR and the handover to 3G command. In568

average, each carrier with 32 neighbors would require ∼600 ms569

to complete the measurement phase and then start the evalu-570

ation of event B1 to update the eNB about the measured 3G571

cell signal level that assists in triggering the handover to the572

strongest cell. With a number of 3G neighbors ≤ 10, the UE573

can complete the measurements within ∼300 ms while camped574

on LTE. Therefore, if PSHO with measurement strategy (S5)575

is chosen for CSFB deployment, it is essential to optimize576

the neighbor list and the number of frequency carriers to be577

measured within the LTE gap. This strategy impacts not only578

on the CSFB setup delay but also the VoLTE eSRVCC delay,579

which is discussed later here. The eSRVCC follows a similar580

mechanism to PSHO with measurements. Therefore, applying581

an optimum optimization on the neighbor list and speeding up582

the measurements can improve the CSFB setup latency and the583

VoLTE eSRVCC mechanisms.584

Once the CSFB call is terminated, it is important to measure585

how fast the UE camp back on the LTE system. Several methods586

can be utilized to camp back on LTE after CSFB call release:587

1) using cell reselection mechanism or 2) using fast return to588

LTE. The cell reselection alone does not guarantee the fast589

returning to LTE. This is because the UE may not directly move590

to idle/paging channel (Cell_PCH) states where the reselection591

can be initiated. Therefore, the fast return to LTE (FRTL) allows592

the RNC to redirect the UE from UMTS to LTE after CSFB593

TABLE IVCAMPING ON LTE AFTER CSFB CALL RELEASE

call is released. In this mechanism, the RNC sends the RRC 594

connection release message with the redirection information to 595

the LTE network. The FRTL can be deployed with measure- 596

ments or as a blind redirection. The most common mechanism 597

deployed now is the blind redirection due to implementation 598

simplicity. 599

Table IV illustrates the time delay from when CSFB call is 600

released until the UE successfully camps back on LTE. The 601

delays shown in the table are estimated with the three common 602

methods described earlier. These methods apply to any CSFB, 603

regardless of which strategy is used (redirection or PSHO). 604

The delays in this table are calculated starting from when the 605

UE releases the CSFB call until the tracking area update is 606

completed between the UE and the EPC. 607

The results in Table IV indicate that the fast-return method 608

with blind redirection provides a faster way to camp back 609

on LTE, which positively improves the end-user experience. 610

The fast return with measurements experiences higher delay 611

to camp back on LTE because the UE would need sufficient 612

time to measure the LTE cells during the 3G compressed mode 613

before reporting the best cell to trigger a redirection to LTE. 614

The drawback of using the blind redirection to LTE is that the 615

UE may remain unreachable if it tries to camp on the LTE 616

network while the LTE coverage is weak. However, this can 617

be handled if the fast return is triggered by the RNC, where 618

there is a neighbor relation with the current serving UMTS cell. 619

Additionally, there are some protection mechanisms defined in 620

[20] that allow the UE to camp back on UMTS within a certain 621

timer if no suitable cells are found on LTE. 622

To conclude the observations here, the choice of a specific 623

CSFB deployment strategy is vital. While each strategy has 624

its own pros and cons, a mix of strategies is considered as a 625

recommended option. We should consider that since not all 626

devices support PSHO. Therefore, the CSFB with redirection 627

shall still be considered as an option. When this strategy is 628

deployed, it is preferred to follow the implementation of re- 629

ducing SIB periodicity. Even in networks with a majority of 630

PSHO-based devices, a mix between redirection and PSHO 631

is still needed. This is typically needed in the case when the 632

CSFB call is triggered without PS activity. In this scenario, it 633

is important to segregate the usage of PSHO from redirection, 634

depending on whether the PS data are active or not (i.e., can 635

be simply indicated if CSFB initiated from idle or connected 636

mode). This is to avoid establishing the PS radio access bearer 637

(RAB) unnecessarily, once falling back to UMTS when PS data AQ7638

are not present. This implementation would allow a more stable 639

call setup and in-call performance by avoiding a 3G multi-RAB 640

call (simultaneous CS+PS), which reduces the footprint of CS 641

coverage. Additionally, the redirection can also be used as an 642

exceptional handling of anomalies to the PSHO fallback. In 643

IEEE P

roof


Fig. 6. VoLTE call setup delay performance: MO side.

this scenario, the UE can be notified to do a redirection, if644

the PSHO is not triggered. More specifically, if the UE does645

not report a suitable UMTS cell during the gap measurements646

within a specified duration, the eNB can then autonomously647

redirect the UE to a predefined RAT and RF frequency. Once648

this timer is expired and there is no cell reported by the UE649

(i.e., due to the lack of 3G coverage for example), the eNB650

can trigger a redirection procedure to another RAT (e.g., GSM).651

This, however, means an additional delay incurred by the user652

that is bounded by this timer threshold.653

B. VoLTE Performance Analysis654

As discussed in the VoLTE call flow in Fig. 3, the VoLTE call655

setup experiences different stages, where each stage contributes656

to the call setup latency. Since the VoLTE call will remain on657

the LTE network, it is important to asses the call setup under658

different radio conditions. Three scenarios are considered to659

analyze the VoLTE call setup delay: near-cell stationary, far-660

cell stationary, and mobility scenario. The near-cell condition661

is performed with the RSRP of around−70 dBm (SINR = 22),662

and the far cell is conducted at the RSRP of around −110 dBm663

(SINR = 8). The mobility test is conducted in the same cluster664

of CSFB and with a typically loaded commercial LTE network,665

where average RSRP = −81 dBm and average SINR = 18.666

Fig. 6 summarizes the average call setup delay KPIs for667

VoLTE call setup in different RF conditions using the KPIs668

explained in Table III, with focus on VoLTE to VoLTE call669

setup. The data are calculated from field measurements with670

a large sample size (i.e., 100 calls for each RF scenario).671

Compared to the CSFB strategy, the call setup delay for VoLTE672

calls is lower than CSFB under all RF condition scenarios. This673

is expected since the VoLTE call setup is conducted within the674

same radio access network and there is no need to fall back to675

UMTS at the call setup stage. Additionally, the signaling speed676

in LTE on the radio interface is faster than that in 3G and with677

fewer signaling messages needed to establish the call.678

In the far-cell stationary and the mobility scenarios, the call679

setup delays are mainly observed when the MT side misses680

the paging message. The maximum observed VoLTE call setup681

delay when the MT misses the first paging attempt is 11.5 s.682

If the MT is in LTE idle mode and the MO side initiates a683

call, the EPC pages the MT for an incoming call. If the MT684

misses the first page due to RF conditions as in far-cell or685

mobility scenarios, the MO perceives a higher setup delay at 686

the stage V1, as defined in Table III. Typically, the MO will not 687

be assigned the dedicated bearer with QCI = 1 unless the MT 688

starts establishing the call and sends SIP: 183 Session Progress. 689

Based on the paging repetition timer in the core network and 690

the idle discontinuous reception (DRX) cycle length [21], the 691

repaging may impose an additional time that contributes to the 692

total call setup delay. The repaging mechanism and the interval 693

between each paging attempt are important for reducing this 694

delay. Since the VoLTE call is treated as a PS call, the network 695

parameters typically need to relax the repaging mechanism to 696

save the paging resources. This is beneficial for the paging 697

dimensioning of PS call; however, it can increase the VoLTE 698

call setup delay, as explained. Therefore, The retuning of the 699

paging mechanism is recommended to ensure a good VoLTE 700

call setup delay in the weak RF conditions. In LTE network 701

with VoLTE support, the repaging mechanism can be increased 702

to three repaging attempts with an interval of 3–4 s between 703

each attempt. 704

Another factor that impacts the call setup delays is the effect 705

of the inactivity timer settings [21]. The inactivity timer con- 706

trols how long the UE is allowed to remain in LTE connected 707

mode without any data activity. If data activity becomes inactive 708

within this timer, the eNB requests the UE to move to idle mode 709

to save resources and to reduce the device battery consumption. 710

This timer is typically chosen to be 5–10 s in data-centric LTE 711

network deployment, i.e., only data with voice via CSFB. Once 712

VoLTE is deployed, the setting of this timer impacts the overall 713

VoLTE call setup delay. The inactivity timer setting can lead 714

to higher call setup delays that are perceived by both the MT 715

and MO sides. During a VoLTE call initiation, the inactivity 716

timer can kick in if there is no SIP activity for the duration of 717

this timer. For example, if the MT takes few extra seconds to 718

establish the VoLTE call (i.e., call not immediately answered 719

by the MT user), no SIP response is sent to the IMS to be 720

forwarded to the MO. As a result, the MO would not detect any 721

data activity, and accordingly, the eNB moves the MO into idle 722

mode while the call is being established. Once the SIP response 723

becomes available, the EPC pages the MO device again as it is 724

in idle mode. Therefore, moving the MO to idle mode during 725

the SIP inactivity period leads to extra paging to transmit SIP 726

responses and establish the VoLTE call setup. Moreover, there is 727

a risk that the MO can miss the paging message, if it is in weak 728

RF condition, which can also cause call setup failures. This is a 729

drawback that needs to be addressed by the industry as the MO 730

should remain active while the VoLTE call is being established. 731

A workaround solution may be implemented from the UE side, 732

but it is preferred to have a consistent feature from 3GPP. 733

We observed an average of 1.3 s of an extra VoLTE call 734

setup delay due to the impact of the inactivity timer. Therefore, 735

we can enable the connected-state DRX (C-DRX) feature and 736

increase the inactivity timer. This feature allows the UE to stay 737

in LTE connected mode for a longer period and, at the same 738

time, improves the device battery consumption without the need 739

to push the UE directly to idle mode for a short period of data 740

inactivity [21]. Nonetheless, retuning the C-DRX parameters 741

is required for VoLTE services to avoid additional interpacket 742

delay and increasing jitters. Table V provides the recommended 743

IEEE P

roof


TABLE VDRX PARAMETERS FOR VOLTE AND PS DATA

C-DRX parameters for VoLTE services (QCI = 1) and PS data744

services (QCI = 9) [21]. The C-DRX parameters for QCI = 9745

remain the same as in [21], where a practical methodology to746

estimate the optimum C-DRX parameters that extend the bat-747

tery life with slightly higher packet latencies was presented. OnAQ8 748

the other hand, the VoLTE C-DRX parameters recommended749

in Table V are estimated to reduce the latencies and there-750

fore improve VoIP audio performance. A detailed analysis for751

C-DRX parameter tuning for PS services can be found in [21].752

A similar practical procedure is exploited to obtain the optimum753

C-DRX parameters for VoLTE services with QCI = 1.754

As indicated in Table V, the C-DRX mechanism for VoLTE is755

deployed with a long DRX cycle of 40 ms, which is appropriate756

for the VoLTE voice coder (vocoder) packets that are typically757

generated over an interval of 20 ms. During talk spurts, the758

incoming VoIP audio frames are typically placed in buffer759

(dejitter buffer) and then processed by the IMS stack, ensuring760

a minimum perceived delay to the end user (i.e., mouth-to-761

ear delay). Although the vocoder packets flow every 20 ms,762

a long DRX cycle of 40 ms is still suitable to the end-to-end763

audio delay, where two packets can be bundled over 40 ms764

and processed in the same sequence without impacting the end-765

user experience. Both PS data and VoLTE C-DRX parameter766

settings are configured to coexist in the same eNB. More specif-767

ically, if the ongoing call is data-only (only QCI = 9 service is768

activated), then the C-DRX parameters for this service can be769

sent by the eNB to the UE. Once the VoLTE call is initiated770

with QCI = 1, the C-DRX parameters for this service are resent771

to the UE through the RRC messages. The process to switch772

between different C-DRX parameters is dynamic and adopted773

by 3GPP [22]. Typically, there are multiple active bearers, and774

the C-DRX parameters related to the QCI with highest priority775

(QCI = 1 in this case) are selected and sent to the UE.776

The last experiment is performed to benchmark the VoLTE-777

to-3G and 3G-to-3G call setup latencies and to compare them778

with the VoLTE to VoLTE demonstrated in Fig. 6. Testing779

devices are located in the same location during the testing, and780

call setup delays are calculated at different RSRP/RSCP values781

from near cell (i.e.,−80 dB) to edge of coverage (i.e.,−120 dB).782

As shown in Fig. 7, the VoLTE-to-3G call setup latency is783

higher than that in VoLTE to VoLTE, even under the near-cell784

condition, but better than CSFB call setup delay. The VoLTE-785

Fig. 7. Call setup delay performance for VoLTE-to-3G and 3G-to-3G calls:MO side.

to-3G call can experience higher delays due to the CS part of 786

the call. In general, the VoLTE-to-VoLTE and the VoLTE-to- 787

3G calls, as shown in Figs. 6 and 7, respectively, confirm the 788

VoLTE introduction added value, in terms of better call setup 789

delay, particularly when compared with the 3G-to-3G voice 790

calls at different RF conditions. It is interesting to see that 791

the call setup delay starts to increase significantly when RSRP 792

decreases beyond −110 dBm. Therefore, it is recommended 793

to design the link budget for VoLTE services to be within the 794

RSRP of −110 dB to ensure minimum call setup performance. 795

C. eSRVCC Performance Analysis 796

To benchmark the overall eSRVCC performance, we start 797

first with evaluating the voice interruption during LTE intrafre- 798

quency handover. The LTE intrafrequency handover occurs 799

when the VoLTE UE is moving between different cells within 800

the same network inside the LTE coverage area. This is calcu- 801

lated from the last DL/UL voice packet received on the source 802

LTE cell to the first DL/UL voice packet received on the target 803

LTE cell. This KPI is calculated for LTE cells deployed with X2 804

interface [3]. The eSRVCC voice interruption time is calculated 805

from the last DL/UL voice packet received on the source LTE 806

cell to the first DL/UL voice packet received on the target 807

UTRAN cell. On the other side, we evaluate the impact of 808

the signaling delay on the overall voice packet latency. The 809

signaling delay in LTE intrafrequency handover is calculated 810

from the handover command received by the UE (i.e., RRC 811

Reconfiguration Message) until the UE sends the handover 812

complete (i.e., RRC Reconfiguration Complete Message). The 813

eSRVCC signaling delay is derived from the handover com- 814

mand (i.e., Mobility From EUTRA Command) until the hand- 815

over complete sent by the UE. Fig. 8 illustrates the UL/DL 816

voice interruption and signaling delay in mobility conditions 817

for both eSRVCC to UTRAN and LTE intrafrequency handover 818

for two different operators. The results are obtained from field 819

testing with voice activity of 100%. To accurately measure the 820

interruption time, we generated 100% real-time protocol (RTP) AQ9821

packets, where each RTP packet corresponds to a 20-ms voice 822

frame. Therefore, we have connected the testing device with a 823

source of voice loopback to generate UL and DL RTP packets 824

continuously. By this setup, we will ensure that the measured 825

interruption is accurate. Otherwise, the measured values may be 826

IEEE P

roof


Fig. 8. eSRVCC and LTE intrafrequency voice interruption time.

inaccurate with a typical voice activity factor of ∼50%. In this827

scenario and during the intrafrequency handover or eSRVCC,828

the voice interruption delays may include silent indicators (that829

are generated every 160 ms). The target is to see if the voice830

interruption during eSRVCC (IRAT handover) is within the831

3GPP requirements (i.e., 300 ms), as well as to compare it with832

voice interruption during LTE intrafrequency handovers. As833

shown in Fig. 8, it is obvious that the eSRVCC experiences834

higher voice interruption and signaling delay than the LTE835

intrafrequency handover case. This is due to the change in radio836

access and the extra requirements of the routing of the voice837

packets within different core networks. However, it is observed838

that the voice interruption fits within the expected 300-ms delay839

[16] for both operators. The accepted voice interruption of840

300-ms range is within the mouth-to-ear delay, indicating an841

overall user satisfaction with the conversational quality.842

eSRVCC requires the same level of optimizations discussed843

in PSHO CSFB to improve its performance. Reducing the844

time needed to measure 3G cells in LTE can improve the845

conversational quality, as it will expedite the handover while846

the LTE coverage is degrading. However, the major concern847

becomes the reliability of the eSRVCC handover. Considering848

a quick handover to 3G improves the time to leave a degrading849

LTE coverage quickly, but it must also ensure that the 3G850

cell quality is acceptable to proceed with the voice call until851

another handover occurs in 3G. This requires careful handover852

optimizations at both ends: in LTE prior to the handover and in853

3G after the handover.854

We can observe a difference in the eSRVCC performance be-855

tween the two operators in Fig. 8, while the LTE intrafrequency856

handover is very much similar. Operator 2 experiences higher857

signaling delay (still within acceptable range) but better voice858

interruption on UL and DL. This indicates that the network859

can be optimized from the EPS network side (MME to eNB860

to UE) to handle signaling delays, but still, the IMS is a key861

factor to voice interruption on the media side (not signaling862

only impacts the interruption time). From the signaling side,AQ10 863

operator 1 is optimized to trigger inter-RAT handover with less864

delays (better parameters and less delays between MME and865

eNB). The IMS in operator 2 seems to be more optimized in866

the delays related to PS–CS path switching, compared with867

that in operator 1, although the EPS side of operator 1 is868

more optimized compared to that of operator 2. Therefore, it869

is important to handle and optimize the voice interruption from870

an EPS and IMS prospective.871

It has been observed from field testing that, if the 3G network 872

maps an SRB over the HSPA channel during the handover, 873

the measurement control message can be delivered to the UE 874

as quickly as within 500 ms, allowing the addition of another 875

strong 3G cell sooner. However, when the SRB is mapped into 876

Release-99 DCH channels, the SRB rate is typically lower, 877

such as 3.4 or 13.6 kb/s. The low SRB rate leads to a slower 878

delivery of the 3G intrafrequency neighbor list to the UE and 879

can cause radio link failure in 3G right after the eSRVCC. 880

We measured the time taken from the eSRVCC complete (i.e., 881

handover complete sent by UE) to the first measurement control 882

message carrying the 3G neighbor to be within ∼2 s, with SRB 883

mapped to DCH. This delay can impact the overall eSRVCC 884

success rate and reduce the reliability of such intersystem hand- 885

overs. Therefore, we need to retune fundamental 3G handover 886

reporting and operations to secure better eSRVCC performance 887

for VoLTE calls. The tuning and optimization of eSRVCC is one 888

of the major challenges to deploy a successful VoLTE service. 889

Similar challenges can also occur in the case of call setup. 890

As discussed before, the SRVCC can occur at the alerting 891

or pre-alerting phase of the VoLTE call. The main issue of 892

initiating SRVCC during VoLTE call setup is that the eNB is 893

not aware of the session phase status, i.e., alerting, pre-alerting, 894

or post-alerting. The eNB determines that a UE is running a 895

voice service, if the eNB detects a service with the QCI = 1 896

running on the UE. As QCI = 1 is typically established before 897

the 180 Ringing, then the eNB can instruct the UE to do IRAT 898

measurements and triggers SRVCC while the call setup has not 899

been completed. 900

Since the IMS and MSC may not support the aSRVCC or 901

bSRVCC procedures, the call setup will fail in this scenario. 902

The failure symptom is that the MSC cannot proceed with the 903

SRVCC at alerting or pre-alerting phase and, hence, would send 904

a “Disconnect” message to the UE, as soon as it falls back to 905

3G or 2G system after the SRVCC is completed. There are two 906

problematic scenarios in SRVCC during VoLTE call setup (at 907

alerting or pre-alerting phase): 1) The UE supports any of these 908

two features (a/bSRVCC), but the IMS does not support any of 909

them; 2) the IMS supports any of these features, but the UE does 910

not support any of them. In both scenarios, SIP messages are 911

transparent to the eNB, and hence, it cannot delay the SRVCC 912

procedure if either UE or IMS does not support a/bSRVCC. So- 913

lutions are not yet widely available in EPS for these scenarios, 914

and hence, it is important to validate these scenarios in early 915

stages of VoLTE deployment. The situation becomes worst with 916

the mix of devices in the network since both of these features 917

are introduced in two different 3GPP releases. One workaround 918

by delaying the SRVCC procedure after QCI = 1 is established 919

for a fixed duration of time. However, this can lead to call drops, 920

instead of call setup failure, if the LTE signal degrades quickly 921

after the call setup and SRVCC has yet to be initiated based on 922

this fixed timer solution. Another workaround by considering 923

the MSC detects that the a/bSRVCC are not supported and 924

the procedure cannot be completed, and hence, the MSC can 925

request to cancel the SRVCC procedure itself and avoid further 926

failures until the call has been successfully established. Finally, 927

parameter optimization can be done to relax the SRVCC trigger, 928

but the tradeoff can hit the VoLTE in-call performance, where 929

IEEE P

roof


more call drops can occur with relaxed SRVCC parameters.930

Therefore, adjusting SRVCC thresholds can be done in a smart931

way to accommodate both cases that greatly impact the VoLTE932

KPIs: call drops due to delayed SRVCC or call setup failure due933

to faster SRVCC.934

VI. CONCLUSION935

In this paper, we have analyzed the different aspects of936

the voice solutions offered by the LTE system, i.e., CSFB,937

VoLTE, and SRVCC. All of the presented results are based938

on commercial live LTE/HSPA+ networks. The KPIs defined939

in this paper are adopted to evaluate the CSFB and VoLTE940

call setup delay, and then, several techniques are discussed941

to improve the overall call setup delay and voice interruption942

during eSRVCC.943

The CSFB call flow and relevant call setup KPIs are estab-944

lished and evaluated. The call setup KPIs for different scenarios945

were analyzed. Based on the detailed field testing and analysis,946

the best CSFB method is the blind PSHO, which minimizes947

the radio delays to move from LTE to UMTS and reduces the948

core network delays to establish the CS call, given that the PS949

bearer is activated during the handover itself. The PSHO with950

measurements minimizes the core network delays, but it can951

potentially increase the air interface delays due to the need952

to measure the 3G cells prior to the handover. This paper has953

highlighted some key techniques to reduce call setup delay and954

improve the PSHO with measurements. Moreover, this paper955

provides techniques to improve CSFB call setup delay.956

In addition, the VoLTE call setup delay is analyzed in a957

similar manner. The relevant VoLTE KPIs are established and958

evaluated at different radio conditions, including near-cell, far-959

cell, and mobility scenarios. It is demonstrated that VoLTE960

provides a better end-user experience, in terms of call setup961

delay. The VoLTE call setup delay and success rate can still962

be further improved by adopting the techniques discussed in963

this paper, including paging repetition, retuning of inactivity964

timers, and enabling the C-DRX mechanism with a modified965

set of parameters targeting a lower packet latency.966

The eSRVCC performance in terms of voice interruption967

time during the IRAT handover to UTRAN has been analyzed968

and compared to the interruption time of LTE intrafrequency969

handover. The eSRVCC voice interruption is worse than the970

LTE intrafrequency interruption by ∼200 ms, but this is still971

within the accepted range for acceptable audio quality i.e.,972

300 ms. This paper provided several techniques to improve the973

voice interruption and the handover success rate for the974

eSRVCC. Future work includes VoLTE voice quality and in-call975

performance, including a detailed evaluation of in-call jitter,976

delays, packet loss error rate, and quality with concurrent PS977

and VoLTE calls.978

REFERENCES979

[1] Service Requirements for the Internet Protocol (IP) Multimedia Core980Network Subsystem (IMS), 3GPP TS 22.228 V12.9.0, 2015.981

[2] IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Ser-982vice and Supplementary Services; Stage 1 (Release 9), 3GPP TS 22.173983V9.5.0, Mar. 2010.984

[3] A. Elnashar, Design, Deployment, and Performance of 4G-LTE Net-985works: A Practical Approach. New York, NY, USA: Wiley, May 2014.986

[4] Mobility Management Entity (MME)—Visitor Location Register (VLR) 987SGs Interface Specification, 3GPP TS 29.118 V10.13.0, Jun. 2014. 988

[5] “IR.92 IMS profile for voice and SMS, version 7.0,” Groupe Speciale 989Mobile Assoc. (GSMA), London, U.K., Mar. 3, 2013. 990

[6] “IR.94 IMS profile for conversational video service version 5.0,” Groupe 991Speciale Mobile Assoc. (GSMA), London, U.K., Mar. 4, 2013. 992

[7] Architectural Requirements, 3GPP TS 23.221 V10.0.0, Mar. 2011. 993[8] J. E. Vargas Bautista et al., “Performance of CS fallback from LTE to 994

UMTS,” IEEE Commun. Mag., vol. 51, no. 9, pp. 136–143, Sep. 2013. 995[9] R.-H. Liou, Y.-B. Lin, Y. C. Sung, P.-C. Liu, and C. Wietfeld, “Perfor- 996

mance of CS fallback for long term evolution mobile network,” IEEE 997Trans. Veh. Technol., vol. 63, no. 8, pp. 3977–3984, Oct. 2014. 998

[10] Y.-B. Lin, “Performance evaluation of LTE eSRVCC with limited access 999transfers,” IEEE Trans. Wireless Commun., vol. 13, no. 5, pp. 2402–2411, 1000May 2014. 1001

[11] Y. J. Jia et al., “Performance characterization and call reliability di- 1002agnosis support for voice over LTE,” in Proc. ACM Mobicom, 2015, 1003pp. 452–463. 1004

[12] Circuit Switched (CS) Fallback in Evolved Packet System (EPS), 3GPP TS 100523.272 V10.3.1, Apr. 2011. 1006

[13] IP Multimedia Call Control Protocol Based on Session Initiation Protocol 1007(SIP) and Session Description Protocol (SDP), 3GPP TS 24.299 V8.12.0, 1008Jun. 2010. 1009

[14] Voice Call Continuity (VCC) Between Circuit Switched (CS) and IP Mul- 1010timedia Subsystem (IMS); Stage 2, 3GPP TS 23.206, 2007. 1011

[15] Single Radio Voice Call Continuity (SRVCC), 3GPP TS 23.216, 2008. 1012[16] Single Radio Voice Call Continuity (SRVCC) Enhancements, 3GPP TR 1013

23.856 V10.0.0, Sep. 2010. 1014[17] IP Multimedia (IM) Core Network (CN) Subsystem IP Multimedia Subsys- 1015

tem (IMS) Service Continuity; Stage 3, 3GPP TS 24.237 V12.7.1, 2015. 1016[18] Mobile Radio Interface Layer 3 Specification; Core Network Protocols; 1017

Stage 3, 3GPP TS 24.008 V12.7.0, 2014. 1018[19] A. Elnashar and M. A. El-Saidny, “Looking at LTE in practice: A perfor- 1019

mance analysis of the LTE system based on field test results,” IEEE Veh. 1020Technol. Mag., vol. 8, no. 3, pp. 81–92, Sep. 2013. 1021

[20] Radio Resource Control (RRC); Protocol Specification, 3GPP TS 25.331 1022V10.18.0, 2014. 1023

[21] A. Elnashar and M. A. El-Saidny, “Extending the battery life of smart- 1024phones and tablets: A practical approach to optimizing the LTE network,” 1025IEEE Veh. Technol. Mag., vol. 9, no. 2, pp. 38–49, Jun. 2014. 1026

[22] Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource 1027Control (RRC); Protocol Specification, 3GPP TS 36.331, 2013. 1028

Ayman Elnashar received the B.S. degree in 1029electrical engineering from Alexandria University, 1030Alexandria, Egypt, in 1995 and the M.Sc. and Ph.D. 1031degrees in electrical communications engineering 1032from Mansoura University, Mansoura, Egypt, in 10331999 and 2005, respectively. 1034

He has more than 18 years of experience in 1035the telecommunications industry, including 2G/3G/ 1036HSPA+/LTE, Wi-Fi, wireless networks, and Internet 1037of Things (IoT). He was part of three major mobile 1038startups (Orange, Egypt; Mobily, Saudi Arabia; and 1039

“du,” UAE) and has held key leadership positions. He is currently the Senior 1040Director of Wireless Networks, Terminals, and IoT with the Emirates Integrated 1041Telecommunications Company “du,” Dubai, UAE. He is in charge of mobile 1042and fixed wireless networks, terminals, and IoT. He is responsible for strategy 1043and innovation, design and planning, performance and optimization, and imple- 1044mentation of mobile, wireless, and IoT networks and devices. He is the founder 1045of the Terminal Innovation Laboratory for end-to-end testing, validation, and 1046benchmarking of mobile terminals. He managed and directed the evolution, 1047evaluation, and introduction of mobile broadband networks (HSPA+/LTE). 1048Prior to this, he was with Mobily, Saudi Arabia, from June 2005 to January 10492008, as Head of Projects. He played a key role in contributing to the launch and 1050success of the mobile HSPA+ network of Mobily, Saudi Arabia, in 2006. From 1051March 2000 to June 2005, he was with Orange, Egypt, where he was responsi- 1052ble for the operation of the mobile network. He published more than 20 articles 1053in the wireless communications arena in highly ranked journals. He is the 1054main author of Design, Deployment, and Performance of 4G-LTE Networks: A 1055Practical Approach (Wiley, May 2014). His research interests include practical 1056performance analysis of cellular systems; mobile network planning, design, 1057and optimization; digital signal processing for wireless communications; multi- 1058user detection; smart antennas; multiple-input multiple-output (MIMO); and 1059robust adaptive detection and beamforming. He is currently working on LTE- 1060Advanced Pro and fifth-generation (5G) evolution, including massive MIMO, 1061millimeter-wave, 3-D beamforming, and new 5G waveforms. 1062

IEEE P

roof


Mohamed A. El-Saidny received the B.Sc. de-1063gree in computer engineering and the M.Sc. degree1064in electrical engineering from The University of1065Alabama in Huntsville, Huntsville, AL, USA, in10662002 and 2004, respectively.1067

He is currently a Senior Regional Account Man-1068ager with MediaTek, Dubai, UAE. He is a leading1069technical expert in wireless communication systems1070for modem chipsets and network design. He is1071driving a team responsible for the technology evo-1072lution and the alignment of the network operators1073

to the device and chipset roadmaps/products in Third-, Fourth-, and Fifth-1074Generation (3G, 4G, and 5G). His main focus is on expanding MediaTek1075technologies and technical expertise with mobile network operators world-1076wide. Prior to MediaTek, he was with Qualcomm CDMA Technology, Inc.,1077San Diego, CA, USA. He later moved to mobile network design in Qualcomm’s1078Corporate Engineering Services Division, Dubai, UAE. With Qualcomm, he1079was responsible for performance evaluation and analysis of the UMTS and1080long-term evolution (LTE) system solutions for user equipment. He developed1081and implemented system studies to optimize the performance of various1082UMTS and LTE algorithms, including cell reselection, handover, cell search1083and paging, circuit-switched fallback, connected-state discontinuous reception1084(C-DRX), inter-radio access technology, voice over LTE/IP Multimedia Sub-1085systems, carrier aggregation, and multiband load-balancing techniques. He1086is the inventor of numerous patents in code-division multiple-access and1087frequency-division multiple-access systems and the coauthor of Design, De-1088ployment and Performance of 4G-LTE Networks: A Practical Approach1089(Wiley), in addition to contributions to 3G Partnership Project (3GPP) al-1090gorithms. He has published several international research papers in IEEE1091COMMUNICATIONS MAGAZINE, IEEE VEHICULAR TECHNOLOGY MAGA-1092ZINE, and several IEEE TRANSACTIONS. His current research interest is on10935G evolution and gap analysis in 5G requirements compared to 4G deployment1094challenges in the areas of physical layer, high-reliable/low-latency systems, and1095waveform design concepts.1096

Mohamed Mahmoud received the B.S. degree in 1097electrical communications engineering from Ain 1098Shams University, Cairo, Egypt, in 1998. 1099

He is currently a Manager of Terminals and 1100Performance with the Emirates Integrated Telecom- 1101munications Company “du,” Dubai, UAE. He is re- 1102sponsible for testing and validation of new terminals 1103and new features. 1104