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
4 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY
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
ELNASHAR et al.: PRACTICAL PERFORMANCE ANALYSES OF CSFB AND VOLTE 5
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
6 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY
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
ELNASHAR et al.: PRACTICAL PERFORMANCE ANALYSES OF CSFB AND VOLTE 7
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
8 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY
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
ELNASHAR et al.: PRACTICAL PERFORMANCE ANALYSES OF CSFB AND VOLTE 9
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
10 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY
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
ELNASHAR et al.: PRACTICAL PERFORMANCE ANALYSES OF CSFB AND VOLTE 11
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
12 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY
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